MOBILITATEA IN RETELELE WIRELESS

1
 1. INTRODUCERE

In etapa actuală şi în perspectiva dezvoltării ulterioare a telecomunicaţiilor, devine

evident că o singură reţea nu poate oferi serviciile cerute de abonaţii care utilizează în prezent o
gamă largă de echipamente de telecomunicaţii.
Din această cauză, scopul urmărit în zilele noastre este de a asigura o mobilitate cât mai
mare pentru abonaţi, mobilitate care necesită atribuirea unor identificatori personali universali
(IPU) abonaţilor, independent de reţeaua de acces (access network – AN) şi de echipamentul de
comunicaţie.
Identificatorii IPU vor deveni in viitor parte integrală a sistemelor de comunicaţii
personale, astfel încât să asigure acoperirea serviciilor de comunicaţie, din ce in ce mai
complexe, cerute de abonaţii unor reţele heterogene şi care utilizează o gamă largă de
echipamente de telecomunicaţii.
In acest context, principala problemă care trebuie soluţionată este urmărirea eficientă a
abonaţilor mobili şi obţinerea informaţiilor despre localizarea lor, utilizând IPU. Acest proces
este cunoscut sub denumirea de Managementul mobilităţii (MM).
Managementul mobilităţii conţine două componente: managementul localizării şi
managementul procesului de handoff, care, la rândul lor se împart în managementul intra-sistem
(micromobilitate) şi, respectiv, managementul inter-sisteme (macromaobilitate). În cadrul
micromobilităţii (în interiorul aceluiaşi sistem), tehnicile managementului mobilităţii sunt bazate
pe interfeţe şi protocoale de reţea asemănătoare. Macromobilitatea se referă la faptul că
terminalele mobile (Mobile Terminal — MT) se deplasează între diferite reţele utilizând
protocoale, tehnologii sau diferiţi furnizori de servicii.
In reţelele wireless, localizarea abonaţilor este urmărita prin intermediul unor baze de
date în care este memorat profilul actualizat continuu al abonatului mobil. Un astfel de profil
conţine nu numai informaţiile despre localizarea curentă a abonatului, dar şi informaţii despre
serviciile oferite acestuia de către reţea (de exemplu, taxarea şi autentificarea). Aria de acoperire
a unei reţele este împărţită în arii de înregistrare (registration area- RA), fiecărei RA fiindu-i
asociată o bază de date locală.

2
 2. MANAGEMENTUL LOCALIZĂRII

Managementul localizării este un proces în două etape, care permite reţelei să descopere
localizarea utilizatorului pentru livrarea apelului, aşa cum se arată în figura.1.

Fig.2.1 Aplicaţiile managementului localizării

Cele două operaţii de bază în Managementul localizării sunt actualizarea localizării şi

determinarea localizării unui abonat mobil. In momentul în care un utilizator se deplasează
dincolo de graniţele unei RA, reţeaua actualizează informaţiile despre localizarea sa în bazele de
date asociate. In momentul în care un abonat iniţiază un apel, utilizând identificatorul
chematului, reţeaua interoghează bazele de date relevante, pentru a obţine localizarea curentă a
acestuia, precum şi alte informaţii despre serviciile la care acesta are acces.
Performanţele managementului mobilităţii pot fi îmbunătăţite în viitor, prin utilizarea
unor replici ale profilului abonatului, care pot fi memorate în diferite locaţii în reţea. Aceste
tehnici de replicare asigură obţinerea mai rapidă a informaţiilor despre profilul utilizatorului,
reducând costurile căutării şi întârzierile, având însă dezavantajul că replicile trebuie actualizate
ori de câte ori apar modificări în profil.
Din această cauză, tehnicile de replicare se aplică numai dacă beneficiile replicării sunt
mai mari decât dezavantajele apariţiei unei suprasarcini de trafic.

3
 In fig.2.2 este prezentată arhitectura unei reţele wireless.

Fig.2.2. Arhitectura unei reţele wireless

Aria de acoperire este divizată în mai multe RA, fiecărei RA fiindu-i asociate anumite
baze de date (database-DB). O arie de înregistrare este divizată în continuare în celule, fiecare
celulă fiind acoperită de o staţie de bază. Terminalele mobile comunică cu staţiile de bază prin
intermediul unor link-uri wireless. Staţiile de bază din cadrul aceleiaşi RA sunt alocate unui
centru de comutaţie (Mobile Switching Centre-MSC), care este cel mai important element al
infrastructurii unei reţele wireless. Semnalizările dintre MSC şi DB sunt realizate prin
intermediul protocolului SS7.

Profilul utilizatorului
Profilul utilizatorului conţine următoarele informaţii:
- informaţiile de localizare – adresa MSC-ului curent;
- numărul de rutare temporar.
Acest număr de rutare temporar este cunoscut sub denumirea de Temporary Local Directory
Number (TLDN) – în IS-41 şi Mobile Station Roaming Number (MSRN) în GSM.
- informaţiile de stare – descriu starea terminalului mobil (de exemplu, un terminal mobil
se poate afla într-una din stările: busy, idle sau power-off)
- informaţiile despre servicii – includ tot ceea ce este necesar pentru a stabili o conexiune
(taxare, autentificare, căsuţă vocală, opţiuni de redirecţionare a apelului, calitatea cerută a serviciilor,
etc.).
Informaţiile despre servicii sunt utilizate nu numai pentru a autentifica un utilizator, dar şi
pentru ca reţeaua să personalizeze serviciile de comunicaţie, conform preferinţelor abonaţilor.

4
 3. MANAGEMENTUL PROCESULUI DE HANDOFF

Managementul procesului de handoff permite reţelei să menţină o conexiune între

utilizatori, în timp ce MT-ul continuă să se deplaseze şi să-şi modifice AP-ul (punctul de acces)
la reţea.
Managementul procesului de handoff implică trei etape. Prima etapă este iniţierea
handoff-ului, în care necesitatea acestuia este identificată fie de către utilizator, fie de către reţea,
datorită modificării condiţiilor în cadrul acesteia. A două etapa consta în apariţia unor noi
conexiuni, pentru care reţeaua trebuie să găsească noi resurse pentru realizarea procesului de
handoff şi să realizeze operaţii suplimentare de rutare. În cazul NCHO (Network-Controlled
Handoff) sau MAHO (Mobile-Asşisted Handoff), reţeaua asigura o nouă conexiune, găsind noi
resurse pentru procesul de handoff şi îndeplineşte şi alte operaţii suplimentare de rutare. In
cazulMCHO (Mobile Controlled HandOff), terminalul găseşte resurse pe care reţeaua trebuie sa
le aprobe. Ultima etapă este reprezentată de controlul fluxului de date, caz în care trecerea de la o
conexiune la alta, se realizează conform acordului stabilit apriori asupra serviciilor oferite de cele
două reţele implicate. Aplicaţiile pentru managementul procesului de handoff sunt prezentate în
figura.3.1.

Managemen
tul procesului
de handoff

Generarea Controlul
Initializare conexiunii fluxului de
date

Deplasarea Alocarea
utilizatorulu resurselor Secventiere
i

Starea retelei Dirijarea Multicast

conexiunii

Fig. 3.1. Aplicaţiile managementului procesului de handoff

Managementul procesului de handoff include două condiţii: handoff ”-ul intra-celular şi

handoff-ul inter-celular. Handoff-ul intra-celular are loc atunci când utilizatorii se deplasează în
interiorul unei celule şi are loc atenuarea semnalului sub un prag predefinit, ceea ce impune
transferul apelului utilizatorului către un nou canal radio, de putere apropiată, din cadrul aceleiaşi
staţii de bază (Base Station — BS). Handoff -ul inter-celular se întâlneşte atunci când un

5
utilizator se deplasează către o celulă adiacentă şi toate conexiunile terminalului trebuie să fie
transferate la o nouă BS. În timpul desfăşurării procesului de handoff, terminalul poate să se
conecteze simultan la mai multe BS-uri şi din această cauză să utilizeze diferite semanlizari..
Acest lucru se numeste soft handoff . Pe de altă parte, dacă terminalul rămâne conectat la o
singură BS, eliminând conexiunea cu BS anterioară (imediat după sau înaintea stabilirii
conexiunii cu BS de destinaţie) se vorbeşte de procesul numit hard handoff . Cercetarea, în ceea
ce priveşte managementul procesului de handoff , implică probleme precum: prelucrarea
eficientă a pachetelor, minimizarea traficului de semnalizare în reţea, optimizarea rutelor pentru
fiecare conexiune, reatribuirea eficientă a benzii, evaluarea metodelor existente pentru
standardizarea şi îmbunătăţirea calităţii serviciilor pentru conexiunile “wireless”.

6
 4. TEHNICILE DE MANAGEMENT AL MOBILITĂŢII
(MOBILITY MANAGEMENT TECHNIQUES – MMT)

Cele două aspecte ale MMT sunt :

- înregistrarea/paging-ul ;
- actualizarea bazei de date/ căutarea abonatului mobil.
Problema înregistrarii/paging-ului se referă la managementul mobilităţii pe scară redusa
(când se actualizează informaţiile de localizare şi cum se transmite semnalul de paging),
principala sa dificultate fiind dată de incertitudinea localizării (exista o diferenţă de timp între
ultima localizare înregistrată a utilizatorului şi localizarea curentă a acestuia). Procedurile de
înregistrare a localizării şi de paging consumă resursele reţelei wireless.
Problema actualizării bazei de date/ căutării abonatului mobil se referă la managementul
mobilităţii pe scară largă (unde se memorează şi de unde se extrage profilul utilizatorului).
Deşi operează la niveluri diferite, între cele două probleme există şi asemanări. De
exemplu, ambele depind de abonatul chemător şi de caracteristicile de mobilitate.
Se pune problema unde trebuie memorată informaţia de localizare. Pentru a micşora
costurile operaţiei de căutare a localizării, informaţiile despre localizarea unui abonat ar trebui
memorate în fiecare nod al reţelei. Totuşi, în momentul în care acesta se deplasează, toate
nodurile ar trebui informate, ceea ce ar conduce la costuri mari pentru procedurile de căutare.
Se adoptă soluţia unor baze de date centralizate, de tipul HLR (Home Location Register).
HLR-urilre au asociate nişte HLA (Home Location Areas). IPU-ul unui utilizator i are
încorporata adresa HLR-ului asociat. Când utilizatorul i se deplasează, HLR-ul se actualizează
corespunzator. In mod similar, când i este apelat, HLR îi accesează profilul.
Pentru a nu accesa mereu un HLR îndepărtat, se introduc registrele VLR (Visited
Location Register), care acoperă zona pe care abonatul o vizitează.
Exista numeroase MMT. Mullender a creat modelul Distributed Match-making.
Acest model presupune că pentru orice nod din reţea se definesc două mulţimi de noduri
P(v) şi Q(v), astfel încât P(v)∩Q(v’)#0 pentru fiecare pereche ordonată (v, v’). Cu această
constrângere de potrivire (matching), s-au facut îmbunătăţiri ale modelului. De exemplu, o
variantă încearcă să minimizeze media |P(v)| + |Q(v)| pentru toate perechile (v, v’). Se presupune
că utilizatorul i se deplasează către nodul v. Este necesar să actualizeze informaţiile de localizare
pentru toate nodurile P(v). Când apare un apel iniţiat în nodul v’ către abonatul i, reţeaua trebuie
să interogheze toate nodurile din Q(v’). Deoarece P(v)∩Q(v’)#0, este garantat că reţeaua va
obţine informaţia despre ultima localizare a utilizatorului i. Chiar dacă unele informaţii din Q(v’)
sunt neactualizate, cu ajutorul unor marcaje de timp, se poate descoperi ultima localizare. Dacă
se limitează P(v)∩Q(v’)=1, această strategie se poate reprezenta printr-o matrice de intalniri, R,
unde P(v)∩Q(v’)={rij}.

7
Fig.4.1. Exemplul 1: R1-structura de difuzare

Fig.4.2. Exemplul 2 : R2- structura centralizată

Fig.4.3. Exemplul 3 : R3 – structura ierarhică

Există două probleme în proiectarea R3.

8
 In primul rând, definirea mulţimilor P şi Q nu include nici o referire la limita distanţelor.
In exemplul dat, distanţa dintre nodurile 3 şi 4 poate sa nu fie mai mare decât cea dintre
nodurile 2 şi 3, dar în timp ce primele se întâlnesc în nodul 9, ultimile se întâlnesc în nodul 7.
care este situat cu un nivel mai jos decât 9.
In al doilea rând, fiind cel mai sus în ierarhie, nodul 9 aparţine tuturor mulţimilor P şi Q.
Cu toate acestea, comunicaţiile între nodurile 2 şi 3 nu ar trebui sa implice nodul 9, deoarece 7
este cel mai mic predecesor comun (CMPC) (dar totuşi este implicat!). In concluzie, R3 nu ţine
cont de avantajul distanţei.
S-a realizat o îmbunătăţire a algoritmului, denumită m-regional matching (corespondenţa
regională), care defineşte mulţimile P(v) şi Q(v) astfel încât P(v)∩Q(v’)#0, dacă nodurile v şi v’
se află la o distanţă ≤m unul de celălalt. S-a construit astfel o ierarhie cu i niveluri, Pi(v) şi Qi(v),
acoperind întreaga vecinătate a distanţei 2i de la nodul v. Prin căutarea progresivă într-o arie din
ce in ce mai mare a abonatului apelat, acesta poate fi găsit în nivelurile mai joase din ierarhie şi
astfel utilizând avantajul localizării, se reduc costurile de semnalizare.
Problema procedurii de actualizare ramâne însă: ea este apelată până când actualizarea
datelor se realizează pe toate nivelurile superioare ale ierarhiei. Pentru a evita actualizarea în
nivelurile superioare ale ierarhiei (dacă nu este necesar), s-a propus un algoritm care să permită
plasarea unui pointer la locaţia precedentă şi să se realizeze actualizarea numai pentru ultimele
logd niveluri (dacă între locaţia precedentă şi cea curentă se află distanţa d).

Fig.4.4. Structura ierarhică bazată pe corespondenţa regionala

In acest algoritm care se bazează pe utilizarea pointerilor, se modifică şi procedura de

căutare: utilizând pointerul întors de funcţia de căutare a abonatului apelat, se urmăreşte
pointerul către ultimul nivel unde se află memorat profilul utilizatorului.
O simplificare a unor astfel de ierarhii, este cea reprezentată de structura de tip arbore,
care menţine constrângerile de distanţă, numai în interiorul subarborelui, în timp ce nodurile
subarborilor adiacenţi trebuie să se intâlnească într-un CMPC.

9
 5. MANAGEMENTUL MOBILITĂŢII IN REŢELELE
PLMN

Standardele pentru strategiile managementului localizării pentru reţelele PLMN sunt IS-
41 şi GSM MAP şi necesită ca fiecare MT să-şi înregistreze periodic localizarea faţă de reţea.
Schemele pentru managementul localizării în ceea ce priveşte reţelele PLMN, sunt bazate
pe o ierarhie de date, cu două niveluri, astfel încât două tipuri baze de date ale reţelei, Home
Location Register — HLR şi Visitor Location Register — VLR, sunt implicate în urmărirea unui
MT. În general, există un HLR pentru fiecare reţea astfel încât utilizatorul este în permanenţă
asociat cu HLR-ul din reţeaua sa. Informaţii specifice fiecărui utilizator, cum sunt cele legate de
tipul serviciilor subscrise şi cele despre locaţie, sunt stocate în profilul său situat în HLR.
Numărul VLR-urilor şi amplasarea lor variază de la o reţea la alta. Fiecare VLR memorează
informaţiile terminalelor mobile (din HLR) care vizitează zona asociată.
Funcţiile de management ale reţelei, cum ar fi prelucrarea apelurilor şi înregistrarea
localizării, sunt realizate prin schimbul de mesaje de semnalizare prin intermediul unei reţele de
semnalizare. Este utilizat sistemul de semnalizare 7 (Signaling System 7 — SS7). Centrul de
comutaţie din reţelele PLMN este cunoscut sub numele de centru de comutaţie mobilă (Mobile
Switching Center — MSC). Figura.6 prezintă reţeaua de semnalizare SS7 care conectează HLR-
ul, VLR-urile şi MSC-urile într-o reţea PLMN de bază. Punctele de transfer ale semnalelor
(Signal Transfer Points — STPs) sunt responsabile pentru dirijarea mesajelor de semnalizare în
interiorul reţelei SS7. Din motive de siguranţă, STP-urile sunt instalate în perechi.
HLR HLR-Home Location Register
MSC-Mobile Switching Center
STP-Signal Transfer Point
VLR-Visitor Location Register
STP

STP

VLR
MSC

Fig.5.1. Reţeaua de semnalizare SS7

Managementului localizării în reţelele PLMN foloseşte două standarde: EIA/TIA IS-41

(Electronic and Telephone Industry Associations Interim Standard 41) şi GSM MAP (Global
System for Mobile Communication Mobile Application Part). Standardul IS-41 (Interim
Standard 41 ) este utilizat în mod obişnuit, în America de Nord pentru sistemul de telefonie
mobilă avansată (Advanced Mobile Phone System — AMPS), IS-54, IS-136 şi pentru reţelele
sistemului de comunicaţii personale (Personal Access communication System — PACS); în timp
ce standardul GSM MAP este utilizat de cele mai multe ori în Europa pentru GSM şi DCS-1800
(Digital Cellular System-1800) şi reţelele PCS-1900 (Personal Communication Service-1900).
Ambele standarde sunt bazate pe ierarhia bazelor de date pe două niveluri.

10
 După cum s-a menţionat anterior, managementul localizării include două sarcini majore:
actualizarea localizării (update) şi livrarea apelurilor (descrisă în figura.2). Pentru reţelele
PLMN, procedurile de înregistrare a localizării actualizează locaţia bazelor de date (HLR-ul şi
VLR-urile) şi autentifică MT-ul atunci când informaţia actualizata a localizării acestuia este
disponibilă. Procedura de livrare a apelurilor localizează MT-ul pe baza informaţiilor disponibile
în HLR şi VLR-uri în momentul iniţierii unui apel către un MT. Strategiile managementului
localizării pentru standardele IS-41 şi GSM MAP sunt similare. Cele două standarde au multe în
comun, deşi standardul GSM MAP este destinat promovării mobilităţii personale şi permiterii
furnizorilor de reţea să selecteze utilizatorii. În paragraful ce urmează este prezentat standardul
IS-41.

5.1. Actualizarea localizării

Procedura de actualizare a localizării implică autentificarea utilizatorului şi în cazul

GSM, mutarea profilului acestuia din VLR-ul precedent în VLR-ul curent, precum şi modificarea
in HLR a adreselor celor două VLR-uri. Semnalizările pentru autentificare şi actualizarea bazei
de date pot fi combinate. In particular, fiecare RA difuzează identificatorul său de locaţie
printrun canal comun de semnalizare. Monitorizând aceste semnale, un terminal mobil poate
detecta orice traversare a graniţei a unei RA.
Când un MT intră într-o RA, dacă noua RA aparţine aceluiaşi VLR ca şi vechea LA,
înregistrarea în VLR este actualizată cu înregistrarea ID-ului noii RA. Altfel, dacă noua LA
aparţine unui VLR diferit, este necesar un număr de paşi suplimentari pentru:
i). înregistrarea MT-ului în noul VLR ;
ii). actualizarea HLR-ului pentru înregistrarea ID-ul noului VLR ;
iii). ştergerea MT-ului din vechiul VLR de servire.

Figura.5.2 prezintă procedurile de înregistrare a localizării atunci când un MT se

deplasează într-o nouă RA. Etapele urmărite în realizarea acestei proceduri sunt:
1). MT-ul intră în noua RA şi transmite către noua BS, un mesaj de actualizare a
localizării.
2). BS trimite mesajul de actualizare a localizării mai departe către MSC, care la rândul
său transmite o cerere de înregistrare VLR-ului asociat.
3). VLR-ul işi actualizează localizarea MT-ului. Dacă noua RA aparţine unui VLR diferit,
noul VLR determină adresa HLR-ului MT-ului corespunzător din numărul de identificare mobilă
(Mobile Identification Number — MIN). Acesta este obţinut printr-o procedură de căutare într-un
tabel denumit GTT — Global Title Translation. Apoi noul VLR trimite către HLR un mesaj de
înregistrare a localizării; altfel, înregistrarea localizării este completă.
4). HLR-ul realizeaza procedurile solicitate pentru autentificarea MT-ului şi înregistrează
ID-ul noului VLR. Apoi HLR-ul trimite VLR-ului, un mesaj de confirmare a înregistrării.

11
 Fig.5.2. Procedurile de înregistrare a localizării

5). HLR-ul trimite vechiului VLR, un mesaj de ştergere a înregistrării.

6). Vechiul VLR şterge înregistrarea MT-ului şi trimite HLR-ului un mesaj de confirmare
a ştergerii.
În funcţie de distanţa dintre locaţia curentă şi cea originară a MT-ului, în etapele 3, 4, 5 şi
6, mesajul de semnalizare trebuie să treacă prin câteva STP-uri intermediare înainte de a ajunge
la destinaţie.

5.2 Căutarea localizării

Procesul implica două etape importante:

i). determinarea VLR-ului asociat MT-ului chemat;
ii). localizarea celulelor vizitate de MT-ul chemat. Localizarea VLR-ului asociat MT-ului
implică următoarele proceduri de căutare a bazelor de date (proceduri prezentate în figura.8):
1). MT-ul chemător trimite MSC-ului asociat MT-ului, un semnal de iniţiere a apelului,
prin intermediul unei BS apropiate.
2). MSC-ul determină adresa HLR-ului asociat MT-ului chemat printr-un GTT şi trimite
HLR-ului, un mesaj de solicitare a localizării (Location Request).

12
 3). HLR-ul determină VLR-ul asociat MT-ului chemat şi trimite VLR-ului un mesaj de
solicitare a rutei (Route Request). Acest VLR trimite mai departe un mesaj către MSC-ul asociat
MT-ului.
4). MSC-ul alocă MT-ului, un identificator temporar numit Număr Temporar al
Directorului Local (Temporary Local Directory Number — TLDN) şi trimite HLR-ului, un
răspuns împreună cu acest identificator temporar.
5). HLR-ul trimite această informaţie, mai departe la MSC-ul asociat MT-ului chemator.
6). MSC-ul chemator solicită MSC-ului chemat, un mesaj de Call Setup, prin intermediul
reţelei SS7.

HLR MSC-Mobile Switching Center

HLR-Home Location Register
VLR-Visitor Location Register

(2) (3)
(5) (4)

VLR VLR
MSC (6) > MSC

(1) MT chemător

MT chemat BTS
BTS

Fig.5.3. Procedurile de livrare a apelurilor

Procedura descrisă permite reţelei să stabilească o conexiune de la MT-ul chemător la

MSC-ul asociat MT-ului chemat. Deoarece fiecare MSC este asociat unei RA şi pentru că în
fiecare RA sunt mai multe celule, este necesar un mecanism pentru a determina locaţia celulei
MT-ului apelat. În reţelele PLMN, aceasta se realizează prin intermediul procedurii de paging
sau alertingş astfel încât semnalele de căutare sunt difuzate tuturor celulelor din RA asociate
MT-ului chemat. In momentul recepţionării semnalului de căutare, MT-ul trimite un răspuns, care
permite MSC-ului să determine celula în care se află acesta. Deoarece numărul MT-urilor creşte,
transmiterea semnalelor de căutare către toate celule dintr-o RA atunci când se recepţionează un
apel, poate să conducă la o suprasarcină de trafic.
Adresa HLR-ului este necesară în ambele proceduri: actualizare a localizării şi căutare a
localizării. Procedura de actualizare a localizării necesită adresa HLR-ului asociat abonatului
care se deplasează, iar procedura de căutare necesită adresa HLR-ului asociat chematului. Prima

13
este considerată o activitate interna a reţelei şi adresa HLR-ului poate fi codată într-un
identificator privat al utilizatorului (ID, de exemplu, IMSI în GSM). In procedura de căutare,
adresa HLR-ului abonatului chemat este codată într-un ID public.

Limitări ale utilizarii HLR/VLR

Există 3 limitări majore ale utilizării HLR/VLR.

In primul rând, căutarea localizării începe prin interogarea HLR-ului asociat abonatului
chemat, chiar şi în situaţiile în care chemătorul şi chematul se află în vecinătate, iar HLR-ul
abonatului chemat se află la mare distanţă.
In al doilea rând, HLR/VLR nu pot face faţă unui mare număr de utilizatori, deoarece
sunt baze de date centralizate şi pot apare congestii în jurul lor.
In al treilea rând, HLR/VLR utilizează numărul geografic al abonatului pentru gasirea
HLR-ului asociat. Numerele geografice leagă însă un utilizator de o anumita reţea şi o locaţie
geografică, deci nu pot suporta un IPU.
Performanţele HLR/VLR pot fi îmbunătăţite prin reducerea costurilor celor două
proceduri. Dacă un abonat nu primeşte multe apeluri, actualizarea HLR-ului asociat poate fi
întârziată prin menţinerea pointerului la VLR-ul anterior, sau schimbând între ele HLR-ul şi
VLR-ul (astfel se micşorează costurile procedurii de actualizare). Dacă abonatul chemat nu se
deplasează frecvent, interogarea HLR-ului sau poate fi evitată prin plasarea profilului său în
VLR-ul curent, sau plasând pointrul de localizare între HLR şi VLR.
Tehnica de replicare a profilurilor în PLMN este utilizată pentru a se asigura că toate
profilurile sunt actualizate când abonatul se deplasează.

5.3 Arhitectura bazelor de date centralizate

Arhitectura bazei de date dinamic ierarhizată

Prima arhitectură a bazelor de date (DB) centralizate este arhitectura dinamică
ierarhizată.. Fiecare MT are o configuraţie unică a pointer-ului şi exista trei tipuri de pointeri de
locaţie:
● un pointer local (local pointer) - este memorat în DB asociată MT-ului şi indică MSC-
ul curent asociat MT-ului;
● un pointer denumit direct remote pointer- este memorat în DB îndepărtată şi indică
MSC-ul curent asociat MT-ului;
● un pointer denumit indirect remote pointer - este memorat în DB îndepărtată şi indică
DB curentă asociata MT-ului.
În plus, HLR-ul asociat MT-ului poate fi configurat să memoreze un pointer atât către
fiecare dintre DB, cât şi către MSC-ul asociat MT-ului.

Memoria cache asociată abonaţilor mobili

Ideea de bază pentru strategia de alocare a memoriei cache corespunzătoare localizării

fiecărui utilizator, este aceea că volumul de semnalizare şi traficul de acces la baza de date

14
pentru localizarea unui MT, pot fi reduse prin menţinerea într-o memorie cache a informaţiilor de
localizare în cadrul unui STP apropiat. În momentul în care MT-ul este accesat prin intermediul
STP-ului, în memoria cache se va insera ID-ul acestui MT, precum şi adresa VLR-ului asociat.
Când un alt apel este iniţiat pentru un MT, STP-ul verifică mai întâi dacă există vreo înregistrare
pentru terminal, în memoria cache. Dacă nu există nicio intrare pentru MT-ul existent, se vor
aplica procedurile descrise anterior. Dacă există o astfel de înregistrare, STP-ul va interoga VLR-
ul specificat în memoria cache. Dacă MT-ul se află încă în zona aceluiaşi VLR, MT-ul este găsit.
Dacă MT-ul s-a deplasat deja către o altă locaţie care nu este ascociată aceluiaşi VLR, MT-ul nu
este gasit şi din nou se vor aplica procedurile prezentate anterior. Când un apel este iniţiat de
terminalul mobil MT1 către terminalul mobil MT2, aşa cum se observă în figura 5.3, sistemul
poate localiza MT2 utilizând informaţiile din memoria cache asociata STP1. Ca urmare, MT2
este localizat cu succes, fără interogarea HLR-ului asociat terminalului mobil MT2. Se defineşte
raportul apel local/mobilitate (Local Call-to-Mobility Ratio — LCMR) ca fiind media numărului
de apeluri de la un STP la un MT, raportată la media numărului de schimbări de VLR pe care le
face utilizatorul în unitatea de timp.

Înregistrările memoriei
“cache" pentru MT2

MT2 → VLR2

STP2
>

STP1

VLR2 MSC2

VLR1 MSC1

MT2

MT1

Fig.5.3. Schema de alocare a memoriei cache corespunzătoare localizării fiecarui utilizator

Utilizarea pointerilor

Ideea de bază a strategiei utilizării pointeri-lor este aceea că în loc de a informa HLR-ul
de fiecare dată când MT-ul se deplasează într-o zonă care aparţine unui VLR diferit, se poate seta
un pointer de la vechiul VLR către noul VLR. Când este iniţiat un apel pentru MT, reţeaua
localizează MT-ul prin determinarea, în primul rând, a VLR-ului de la începutul lanţului de

15
pointeri şi apoi urmăreşte pointerii până la VLR-ul curent asociat MT-ului. Pentru a minimiza
întârzierea produsă în procesul de localizare a unui MT, lungimea lanţului de pointeri este
limitată la o valoare maximă, predefinită, K. Când lungimea lanţului de pointeri ajunge la
valoarea K, la următoarea deplasare, schimbarea localizării trebuie raportată HLR-ului. In figura
5.5 este descrisă această strategie. Pointerii sunt setati de la VLR1 la VLR2 şi de la VLR2 la
VLR3, dupa cum MT-ul se deplasează de la MSC1 la MSC2 şi, respectiv, de la MSC2 la MSC3.
Pentru K=2, lanţul de pointeri nu poate fi extins mai departe. O deplasare suplimentară de la
MSC3 la MSC4 va necesita înregistrarea localizării in HLR. Pointerii originali sunt şterşi şi
HLR-ul înregistrează ID-ul VLR-ului curent asociat MT-ului. S-a demonstrat că această schemă
nu duce întotdeauna la o reducere a costurilor, deoarece ea depinde de mobilitate, de parametrii
de recepţionare a apelurilor şi de valoarea K..

HLR

MSC1 MSC2 MSC3 MSC4

X > X >
VLR1 VLR3 VLR4

>

Fig.5.5. Strategia “pointer”-ului de expediere

Baze de date locale (Local Anchor)

În ceea ce priveşte schema de ancorare locală, traficul de semnalizare datorat înregistrării

localizării, se reduce prin eliminarea necesităţii de a raporta HLR-ului modificarea localizării. Un
VLR apropiat MT-ului este selectat ca fiind baza locală (Local Anchor- LA). În locul transmiterii
mesajuuil de înregistrare către HLR, modificările localizării sunt raportate LA. Deoarece aceasta
este situată aproape de MT, costul de semnalizare suportat la înregistrarea localizării este redus.
HLR-ul menţine un pointer către LA.. Când un apel este recepţionat, HLR-ul interoghează LA a
MT-ului care, la randul său, interoghează VLR-ul asociat pentru a obţine o adresa de rutare către
MT-ul apelat. In figura 5.6 presupunând că LA a terminalului mobil MT1 este VLR1, schimbarea
localizării îi este raportată lui VLR1 (în locul HLR-ului) în momentul în care MT1 se deplasează
de la VLR2 la VLR3. Se introduc două scheme de alocare a LA pentru un MT: alocarea statică
şi respectiv, dinamică a unei LA. În ceea ce priveşte alocarea statică, VLR-ul asociat al MT-ului
devine LA în timpul recepţionării ultimului apel. LA se schimbă când se recepţionează următorul
apel. Ancorarea locală statică elimină complet necesitatea informării HLR-ului despre
modificările localizării. Însă, asemănător strategiilor de alocare a memoriei cache şi a pointeri-
lor, alocarea statică poate să nu ducă mereu la îmbunătăţirea performanţelor. Într-un mod similar,
ancorarea locală dinamică modifica LA la VLR-ul asociat atunci când soseşte un apel. Totuşi,
reţeaua continu[ sa ia decizii referitoare la modificarea LA asociată MT-ului după fiecare
deplasare, pe baza mobilităţii şi a parametrilor apelurilor recepţionate.

16
 HLR

MSC1 MSC3 MSC4

X >
VLR1 VLR2 VLR3

> MT1

Ancora locală
pentru MT1

Fig.5.6. Schema utlizării LA

5.4. Arhitectura bazelor de date distribuite

5.4.1. Arhitectura complet ditribuita

MMT ierarhică dispune bazele de date în structuri arborescente. De la radacină în jos,

bazele de date de pe fiecare nivel al ierarhiei formează partiţii din ce în mai fine ale ariei de
acoperire.
Fiecare bază de date din nodurile frunză serveşte o RA individuală şi memorează
informaţiile curente ale abonatului care se află în roaming în RA. O bază de date care nu se află
într-un nod frunză, memorează un pointer (IPU+ID-ul bazei de date) pentru fiecare utilizator care
se află în aria de acoperire a uneia dintre bazele de date descendente.
Cele două niveluri HLR/VLR ale arhitecturii bazei de date sunt înlocuite de un număr
mare de baze de date. Aceste baze de date au o organizare arborescentă. MT-urile sunt asociate
bazelor de date de pe nivelul inferior (noduri frunză) şi fiecare bază de date conţine informaţia
localizării a MT-urilor care se află în subarborele respectiv.
Având în vedere faptul că un terminal mobil MT1 este amplasat în zona de locaţie LA1,
există o înregistrare pentru MT1 în fiecare bază de date de-a lungul căii de la locaţia curentă
până la rădăcina arborelui. Înregistrarile în bazele de date, pentru MT1 sunt prezentate în figura
5.7..

17
 D

>
>
>

>
>
>

B
>
>
>

A
>

MT1 RA1 MT2

Fig.5.7. Distribuirea ierarhică a arborelui bazată pe arhitectura bazei de date

Când un apel este iniţiat, reţeaua localizează MT-ul apelat urmărind înregistrarile în
bazele de date. Spre exemplu, dacă un apel pentru MT1 este iniţiat de MT2 (aşa cum se poate
observa în figură), cererea de apel este primită de nodul A. Întrucât baza de date a nodului A nu
are înregistrare pentru MT1, cererea de apel este expediată către nodul B şi aşa mai departe.
Când cererea ajunge, în cele din urmă, la nodul D, se găseşte o intrare pentru MT1 şi locaţia
pentru MT1 este determinată după o altă vizualizare a bazei de date a arborelui (lucru vizibil în
figură). Când un MT se deplasează într-o RA care aparţine bazei de date a unei frunze diferite,
baza de date corespunzătoare este actualizată pentru a indica locaţia corectă a MT-ului. Prin
comparaţie cu schema bazată pe o arhitectură a bazei de date centralizate, cum este schema
standardului IS-41, schema localizării distribuite reduce distanţa parcursă de mesajele de
semnalizare. Totuşi, această schemă duce la o creştere a numărului de actualizări ale bazelor de
date şi a cererilor şi, astfel, cresc întârzierile apărute la înregistrarea localizării şi la livrarea
apelurilor.

Partiţionarea

Schema de partiţionare este introdusă pentru arhitectura complet distribuită. Ţinând cont
de faptul că modelul de mobilitate a MT-urilor variază între locaţii, partiţionările pot fi generate
prin gruparea serverelor de localizare între care MT-urile se deplasează mai frecvent. Pe baza
schemei de partiţionare, înregistrarea localizării se face numai când MT-ul intră într-o partiţie.
Figura 5.8 prezintă partiţiile unei reţele particulare PLMN. Partiţia P2 este alcătuită din cinci
servere de localizare, care au cel puţin un predecesor comun, server-ul de localizare LS2. Când
MT-ul se deplsează în interiorul partiţiei P2, server-ul de localizare LS2 este actualizat indicând
faptul că MT-ul se află în subarborele său. Nu are loc nicio înregistrare a localizării în momentul
în care MT-ul se deplasează către un alt server de localizare din interiorul aceleiaşi partiţii.
Această schemă minimizează numărul înregistrărilor de localizări în zonele în care rata
de mobilitate a MT-urilor este ridicată
.

18
 LS1 LS2 LS3

Partiţia P1 Partiţia P2 Partiţia P3

Fig.5.8. Schemă de partiţionare

5.4.2 Arhitecturi ierarhizate

Se introduce o altă arhitectură pentru o bază de date distribuită, similară cu arhitectura

complet distribuita, prezentată anterior. În acest caz, MT-urile pot fi amplasate în orice nod al
ierarhiei arborelui (nu se limitează la nodurile frunză). Deoarece rădăcina arborelui conţine o
bază de date, nu este necesar ca şi celelalte noduri să aibă, la rândul lor, baze de date. Aceste
baze de date memoreaza pointeri pentru MT-uri. Dacă MT se află într-un subarbore al unei baze
de date, în această bază de date este setat un pointer care indică următoarea bază de date de-a
lungul rutei către MT. Dacă nu există nici o bază de date de-a lungul acestei rute, pointerul indică
nodul în care se află MT-ul. Când un apel către un MT este iniţiat de la un nod din arbore, MT-ul
apelat poate fi localizat urmărind pointerii către MT. Figura 5.9 prezintă modul de operare al
acestei strategii. Un apel este iniţiat la nodul A şi MT-ul apelat este amplasat în nodul B. Calea
pentru căutarea MT-ului apelat este aratată în figura 5.9. Dacă se ajunge la o bază de date, care
nu conţine un pointer pentru un MT apelat, este interogată următoarea bază de date aflată de-a
lungul rutei către rădăcină.
Ţinând cont de parametrii sistemului, cum ar fi rata de deplasare între ariile de localizare,
se introduce o metodă pentru determinarea localizării bazei de date care reduce numărul
accesului aceastei baze de date şi al actualizărilor.

Actualizarea ierarhizată a localizării

Cand un abonat i se deplasează din RA X către RA Y, reţeaua nu numai că muta profilul
utilizatorului din DB(X) in DB(Y), dar şi actualizează pointerii de localizare, prin crearea
pointerilor curenti de localizare de la DB(Y) la CMPC-ul dintre DB(X) şi DB(Y), precum şi prin
stergerea pointerului de localizare anterior, dintre CMPC şi DB(X). ↑DB(i) este pointerul de
localizare al utilizatorului i la DB.

19
Utilizatorul i iniţiază cererea de actualizare a localizării in MSC(Y).

DB <- DB(Y)
DBn <- parinte(DB)
while ↑DB(n, i)=0 do
↑DB(n, i)<-DB{creaza pointer-ul de localizare la DBn pentru utilizatorul i}
DB <- DBn
DBn <-parinte(DB)
end {DBn este CMPC (DB(X), DB(Y))
DB0 <- ↑DB(n,i)
↑DB(n,i) <-DB
while ↑DB(0,i)#0 do
DB <-↑DB(o,i)
↑DB(0,i)=0 {sterge pointerul pentru i}
DBo <-DB{Dbo este DB(X)}
end
Transferă profilul utilizatorului de la DB(X) la DB(Y)

Bază de date
>

>

>
Nod fără bază de date
>
>
>

>
>

B A

MT chemat MT chemător

Fig.5.9. Baze de date ierarhizate

20
 Fig.5.10. Actualizarea ierarhizată a localizării

Căutarea ierarhizată a localizării

DB(j) este baza de date din nodul frunză în care chemătorul j se află la momentul curent.
Cand abonatul j apeleaza pe i, reţeaua interoghează DB(j) pentru a obţine informaţiile din
profilul lui i. Dacă nu este gasit, DB(j) propagă cererea de căutare pe nivelurile superioare, către
CMPC (DB(j), DB(i)), prima baza de date care conţine pointerul de localizare al lui i.
Cererea de căutare se propagă apoi în jos, urmărind pointerul de localizare al
chemătorului, către DB(i), unde este memorat profilul său.

Cererea de căutare a localizării pentru abonatul i este iniţiată de MSC(j).

DB <- DB(j)
repeat
DB <-parinte(DB)
interoghează DB despre abonatul i
pana cand se gaseste {DB este CMPC(DB(j), DB(i)}
while ↑DB(i)#0 do

DB <-↑DB(i){se urmareste pointerul de localizare pentru abonatul i}

end
Se returneaza profilul lui i către DB(j)

21
 Fig. 5.11. Căutarea ierarhizată a localizării

Avantajele MMT ierarhice

O structură ierarhică prezintă avantajul că informaţia de localizare este distribuită şi nu

există congestii în reţea. Deasemenea se poate afla localizarea din apelul abonatului şi din
modelul de mobilitate. Deoarece utilizatorii tind să apeleze şi să se deplaseze în zone geografice
adiacente, în cele mai multe cazuri semnalizarea implică nivelurile joase ale structurii, în timp ce
apelurile (mai putin intâlnite) la distanţe mari şi deplasările la distanţe mari implică nivelurile
superioare. Căutarea unui utilizator în ierarhie se face după ID-ul său, care nu mai este geografic,
deci poate fi IPU.
Această structură se poate îmbunătăţi prin utilizarea pointerilor de direcţionare şi a
tehnicii de replicare a profilurilor.

Actualizarea localizării utilizând tehnica de replicare

Fiecare actualizare a localizării are loc în toate bazele de date r  R. Actualizarea se

poate face unicast sau multicast.
Fie v baza de date în care se iniţiază actualizarea.
In unicast, fiecare baza de date r  R este actualizată separat, cu costul c(v, r), costul
total fiind ∑c(v, r).
In multicast, arborele Steiner minimal (MST- arborele Steiner conţine un număr V de
noduri, interconectate printr-un graf de lungime minimă; se pot introduce şi noduri sau arce
suplimentare, pentru a se reduce lungimea conexiunilor), care acoperă mulţimea de baze de date
din R şi v, este traversat pentru a ajunge la toate bazele de date v  R. Costul toatal este costul
MST (RU{v}). Prin multicast se actualizează nu numai baza date r, dar şi toate replicile din
bazele de date de pe calea dintre v şi r.
Ce se poate replica?
In unele structuri s-a considerat că este suficient sa fie replicată adresa bazei de date
curente (VLR in HLR/VLR sau nodul frunză în MMT ierarhică), deoarece numărul temporar de
rutare este valid numai pentru iniţierea apelului (e volatil). Această implică însă o căutare a
localizării aditională, pornind din baza de date curentă, pentru a obţine informaţia de rutare. Dacă

22
chemătorul şi chematul se află la distanţă, se reduce numai numărul de căutări, dar ni şi costurile
reţelei.
De aceea, s-a considerat că este mult mai bine sa fie memorată adresa MSC-ului asociat
abonatului. Numărul temporar de rutare nu este necesar până când MSC-ul nu a recepţionat
apelul şi e gata să stabilească conexiunea către chemat. Se elimina astfel căutarea aditională şi se
reduce costul de reţea.

Fig.5.12. Modelul sistemului

Fig. 5.13. Procedura de căutare cu aplicarea tehnicii de replicare; v este cea mai apropiată replică
a lui v, astfel încât costul este c(v, v) =minr R(c(v, v))

23
Fig.5.14. Procedura de actualizare cu aplicarea tehnicii de replicare

24
 6. MANAGEMENTUL MOBILITĂŢII IN REŢELELE
AD HOC

Evolutia sistemelor de comunicaţii fără fir a condus la necesitatea detaşării rapide şi

independente a utilizatorilor mobili. Din moment ce nodurile sunt mobile, topologia reţelei se
poate schimba rapid în timp. Deci, reţeaua este descentralizată, astfel că toate activităţile reţelei,
inclusiv decoperirea topologiei şi livrarea mesajelor trebuie executate de către noduri, iar
funcţiile ruterelor vor fi încorporate nodurilor mobile.
Topologia de bază a unei reţele fără fir este prezentată în figura 6.1.

Fig. 6.1. – Schema unei reţele ad hoc

Nodurile dintr-o reţea fără fir se recunosc între ele şi stabilesc comunicaţia. În forma cea
mai simplă, staţiile comunică direct între ele, fără ca toată comunicaţia să fie coordonată in mod
centralizat.
Reţele e ad hoc sunt create dinamic şi menţinute de nodurile individuale din reţea.
Reţelele ad hoc nu necesită o arhitectură prestabilită din motive de realizare a comunicaţiei şi nu
se bazează pe nici un tip de infrastructură cablată.
Reţelele ad hoc pot fi folosite cu succes în timpul conferinţelor sau în interiorul unui
campus, pentru a facilita transferul de date între utilizatori sau pentru a lucra online cu anumite
date partajate. Pe scurt, în reţelele ad hoc, conectivitatea dintre noduri şi topologia reţelei poate
varia foarte mult. Pe langă acest lucru, nodurile mobile au o rază de transmitere limitată, ceea ce
reprezintă un motiv pentru ca reţelele ad hoc să suporte aşa-numitele căi multi-hop. Acest lucru
înseamnă că pachetele pot fi dirijate prin noduri intermediare, cu scopul de a ajunge la noduri
care nu sunt în interiorul ariei de transmisie a nodului-sursă. De aceea, toate nodurile trebuie sa
funcţioneze ca noduri de graniţă pentru reţea, dar şi ca rutere. Un alt motiv pentru utilizarea
rutării multi-hop este economisirea puterii dispozitivelor care functionează cu baterii limitate.
Aplicatiile reţelelor ad hoc portabile în misiunile de salvare şi in situaţii localizate în zone cu
teren accidentat a devenit din ce în ce mai comună. Exemplele de reţele ad hoc:

25
  Operaţii ale echipelor de salvare – Membrii echipelor de salvare trebuie să comunice
constant în timpul unei misiuni de salvare pentru a putea face schimb de informaţii utile.
 Zone fără o infrastrucuraă dezvoltată pentru telecomunicaţii – în aceste zone se pot forma
reţele ad hoc cu costuri mici, cu consum mic de timp şi energie.
De asemenea, scenariile reţelelor militare nu se pot baza pe o conectivitate centralizată şi
organizată şi de aceea pot fi concepute ca aplicaţii ale reţelelor ad hoc mobile.
Există deci o multitudine de aplicaţii ale acestor reţelelor ad hoc mobile, pornind de la
reţelele mici, statice cu constrângeri de putere, până la reţelele mari, mobile, dinamice.
Implementarea protocoalelor de reţea pentru aceste reţele este o problemă complexă.
Reţelelor ad hoc mobile le sunt necesari algoritmi distribuiţi conform cu topologia acestor
reţele pentru programarea link-urilor şi rutare. Totuşi, determinarea rutării pe căile viabile şi
livrării mesajelor într-un mediu descentralizat, unde topologia reţelei fluctuează nu este o
problemă bine definită.
În procesul de proiectare trebuie să se ia in considerare faptul că cea mai scurtă cale
(bazată pe funcţia de costul alocat) de la sursă la destinaţie nu este neaparat ruta optimă, ca într-o
reţea statică, ci trebuie analizaţi şi factori cum ar fi: calitatea legăturilor fără fir, pierderile de
propagare, fadingul, interferenţele dintre staţiile mobile, sau schimbările de topologie a reţelei.
Reţeaua ar trebui să aibă capacitatea de a atenua aceste efecte. Mai mult decât atât, în reţelele
militare, securitatea, latenţa, autenticitatea şi refacerea link-urilor întrerupte sunt probleme
importante. Reţelele militare sunt proiectate să menţină o probabilitate scăzută de interceptare
sau o probabilitate scăzută de detecţie. Astfel, se preferă ca puterea semnalelor transmise de
noduri sa fie cat mai mică, iar frecvenţa să fie cât mai aleatoare
Pentru reţelele ad hoc există două tipuri de arhitecturi: cu un nivel şi ierarhică.. Reţelele
care se bazează pe arhitectura cu un nivel necesită ca fiecare nod mobil să participe la
transmiterea şi primirea de pachete în funcţie de schema de rutare implementată. Reţelele care se
bazează pe o arhitectură ierarhică folosesc o abordare pe niveluri. Nivelul inferior conţine noduri
mobile grupate în reţele mai mici. Un singur membru din fiecare grup se comportă ca un
gateway către nivelul imediat următor. Împreună, nodurile mobile care sunt gateway-uri,
formează următorul nivel..

Evaluarea unui protocol în reţelele ad hoc trebuie să ţină seama de condiţiile reale de
trafic: capacitatea buffer-elor de memorare a mesajelor, modelele reprezentative de trafic,
deplasările mobilelor în mediul real. Intr-o reţea ad hoc nodurile nu au informaţii apriori despre
topologia reţelei din jurul lor, ci trebuie s-o descopere.

6.1. Modele de mobilitate

Un model al mobilităţii vehiculelor trebuie să redea deplasarea cât mai reală a acestora.
Modificările vitezelor şi ale direcţiilor poate avea loc, însă numai după anumite intervale de
timp.
A. Din punct de vedere al nodurilor implicate, modelele de mobilitate sunt de două
tipuri :
1. Modele ale mobilităţii individuale
2. Modele ale mobilităţii de grup

26
 1.Modele ale mobilităţii individuale :
Aceste modele sunt asociate nodurilor mobile a căror deplasare este independentă de a
celorlalte. Exemple de astfel de modele :
a. Deplasarea aleatoare : un model simplu, bazat pe utilizarea unor viteze şi direcţii de
deplasare aleatoare.
b. Deplasarea aleatoare cu pauze : un model care include pauze între modificările de
direcţie sau viteză.
c. Direcţie aleatoare : un model care forţează nodurile mobile să se deplaseze către
graniţele zonei de simulare înainte de a se modifica direcţia sau viteza.
d. Zone de simulare nelimitate (fără graniţe) : un model care converteşte zona
bidimensionalaă de simulare într-o zonă toroidală.
e. Modelul  Gauss-Markov : model care utilizează unul dintre parametri pentru a varia
gradul de neuniformitate în modelele de mobilitate
f. Varianta probabilistică a modelului de deplasare aleatoare : un model care utilizează
o mulţime de probabilitaţi pentru a determina următoarea poziţie a nodului mobil.
g. Modelul asociat unei zone urbane : model asociat unei zone urbane, care reprezintă
străzile unui oraş.

2. Modele ale mobilităţii de grup :

a. Modelele de mobilitate Sanchez: coloană, de urmărire şi tip comunitate nomadă
b. Modelul RPGM
c. Modelul de mobilitate limitat la o anumita zonă: fiecărui grup dintr-o anumită regiune i
se alocă o zonă
d. Modelul de mobiliatate cu suprapuneri de grupuri: se admite existenţa mai multor
grupuri în aceeaşi zonă, fiecare cu caracteristicile sale de mobilitate

B. Din punct de vedere al modului de deplasare a nodurilor mobile, modelele de

mobilitate se clasifica în :

1. Modelul determinist
Acest model descrie cel mai previzibil model de mobilitate şi este cel mai simplu dintre toate
modelele. De exemplu, dacă nodurile mobile se deplasează în linie dreaptă, deviaţia vectorilor de
direcţie asociaţi cu oricare 2 poziţii va fi 0. Un exemplu îil constituie un scenariu de trafic urban,
în care viteza mobilelor este restricţionată şi direcţia de deplasare este predefinită, astfel încât
acestea se deplasează în linie dreaptă sau cotesc doar la semafoare.

27
 Fig.6.2. Modelul de mobilitate determinist

2. Modelul semideterminist
Acest model presupune că deşi nodurile individuale nu au o direcţie specificată, ele
urmează totuşi un model general, de tip coloană. De aceea este denumit şi Model Coloană. In
acest caz, deviaţia între vectorii de direcţie asociati la două poziţtii poate varia între -90 şi 90,
depinzând de laţimea coloanei (deviaţia φ)

Fig. 6.3. Modelul coloană

28
 Fig. 6.4. Deplasarea mobilelor în modelul coloană

Deviaţia semnifică raportul de non-determinism (cu cât este mai mare deviaţia medie, cu atât
mai imprevizibil este modelul de mobilitate.

3. Modelul aleator
Se consideraă modelul prezentat în fig.6.5. Se observă că deplasarea mobilelor este fara
memorie, fiind complet independentă de deplasările anterioare ale acestora şi deci fără a necesita
stabilirea unor limite pentru deviaţiile maxime ale noilor deplasări faţă de cele anterioare.
Deplasarea mobilelor este în acest caz, complet imprevizibilă.

Fig.6.5. Deplasarea mobilelor în modelul aleator

Modele de mobilitate pentru reţelele mobile ad-hoc

Există mai multe tipuri de modele. Pentru unele modele de mobilitate, deplasarea nodurilor
poate fi afectată de istoricul deplasărilor anterioare. Astfel, există:

29
 - modele dependente de timp;
- modele dependente de spaţiu.
O alta clasa de modele sunt cele la care se ţine seama de restricţiile geografice, în care
deplasarea nodurilor este limitată de străzi, clădiri, obstacole.

Fig.6.6. Clasificarea modelelor de mobilitate

Modelul de mobilitate aleatoare

In acest model, nodurile se deplasează în mod aleator şi liber, fără restricţii. Destinaţia, viteza
şi direcţia sunt alese aleator şi independent de acţiunile celorlalte noduri.

Modelul de mobilitate aleatoare cu pauze

In acest model, fiecare nod se îndreaptă către destinaţie cu o viteză constantă, aleasă în mod
uniform şi aleator în intervalul [0, Vmax]. Viteza şi direcţia unui nod sunt alese independent de
acţiunile altor noduri. In momentul în care mobilul ajunge la o anumită destinaţie, se opreşte
pentru o perioadă Tpause.
Pentru acest model, Vmax şi Tpause sunt cei doi parametri importanţi, care determină modelul
de mobilitate al nodurilor. Dacă Vmax este mic şi Tpause este mare, topologia reţelei ad hoc
devine relativ stabilă.
Pe de altă parte, dacă nodurile se deplasează repede (Vmax e mare) şi Tpause e mic, topologia
devine foarte dinamica. Prin varierea celor doi parametri se pot obţine diferite scenarii cu
diferite niveluri de viteze ale nodurilor. Un factor mai important decât viteza individulă este
viteza relativă a două noduri care determină dacă link-ul dintre ele se întrerupe sau se formează.
O îmbunătăţire a modelului propune ca metrica modelului de mobilitate să fie viteza nodurilor.
Măsura vitezei relative dintre nodurile i şi j este:
RS (i, j, t) = |Vi(t)-Vj(t)|

30
 Fig.6.7. Modelul de mobilitate aleatoare cu pauze

In care |i,j| este numărul asociat unei perechi de noduri, iar n este numărul de noduri din
aria de simulare.

A.Modele de mobilitate dependente de timp

Mobilitatea nodurilor este limitată de legile fizice ale acceleraţiei, viteza şi rata
schimbărilor de direcţie. Deci, viteza curentă a unui nod mobil poate depinde de viteza sa
anterioară. Un exemplu de astfel de model este modelul Gauss-Markov.
In acest model se presupune că viteza nodurilor mobile va fi corelată în timp şi modelată
ca un proces stochastic Gauss-Markov. Intr-un model bidimensional, acesta poate fi reprezentat
de ecuaţiile:
Vt   Vt 1  (1   ) 1   2 Wt 1 (1)
x y T x y T
unde Vt = [vt , vt ] şi Vt-1 = [vt-1 , vt-1 ] sunt vitezele la momentul t şi respectiv
t-1. Wt-1 = [wt-1x, wt-1y]T este un proces aleator Gaussian necorelat cu varianţa σ2 şi   [ x ,  y ] ,
v  [v x , v y ] şi   [ x ,  y ] sunt vectorii care reprezintă nivelul de memorie, media aşsimptotică
şi deviaţia standard asimptotica. Pentru simplitate, ecuaţia (1) poate fi reprezentată într-un plan
bidirecţional, astfel :
vtx  vtx1  (1   )v x   x 1   2 wtx1 (2)
vty  vty1  (1   )v y   x
1   2 wty1

In momentul în care un nod ajunge la graniţele zonei de simulare, direcţia de deplasare

este schimbată cu 180, pentru ca nodurile să ramână în interiorul graniţelor.
Din aceste ecuaţii se observă că Vt = [vtx, vty]T al mobilului la momentul t este dependent
de viteza Vt-1 = [vt-1x, vt-1y]T la momentul t-1. Deci modelul Gauss-Markov este un model
dependent temporar.
 este parametrul care reflectă gradul de hazard în modelul Gauss-Markov.
1. Dacă modelul este fără memorie - =0, ecuaţiiile anterioare devin:
vtx  v x   x wtx1 (3)

31
 vty  v y   y wty1
unde viteza nodului mobil la momentul t este determinată numai de v  [v x , v y ] şi de variabila
aleatoare gaussiană Wt = [wt-1x, wt-1y]T . Modelul descris de aceste ecuaţiii este cel cu deplasare
aleatoare cu pauze.

2. Dacă modelul are o memorie puternică - =1, ecuaţiiile devin:

x
vtx  vt 1 (4)
y
vty  vt 1

unde viteza nodului la momentul t este exact aceeaşi ca la momentul anterior.

3. Dacă modelul Gauss-Markov are memorie incompleta- 0<<1, viteza curentă este
dependentă atât de viteza la momentul t-1, Vt-1 = [vt-1x, vt-1y]T, cât şi de noua variabilă aleatoare
gaussiană Wt = [wt-1x, wt-1y]T.

B. Modele dependente de spaţiu

Mobilitatea unui nod poate fi influenţată de nodurile învecinate. Datorita faptului că

vitezele diferitelor noduri sunt corelate în spaţiu, vom denumi aceste modele Dependenţa
spatială a vitezelor. Un exemplu este Modelul de mobilitate asociat unui grup cu punct de
referinţă (RPGM- Reference Point Group Mobility Model).

Modelul RPGM
In acest model, fiecare grup are un centru, care este fie un centru logic, fie un nod leader
de grup. Fiecare grup are un leader şi un număr oarecare de membri. Deplasarea leader-ului de
grup determină modelul de mobilitate al întregului grup.

Leader-ul de grup

Deplasarea leader-ului de grup la momentul t poate fi reprezentată de vectorul de mişcare

Vgroup t. Acesta descrie nu numai mişcarea leader-ului de grup, dar şi mişcarea generală a
întregului grup. Deplasarea fiecărui membru al grupului deviază cu un anumit grad faţă de cea a
întregului grup. Vectorul Vgroup t poate fi ales aleator sau poate fi proiectat în funcţie de anumite
căi predefinite.

Membri grupului
Deplasarea membrilor grupului este afectată de deplasarea leader-ului de grup. Pentru
fiecare nod, modelul de mobilitate alocă un punct de referinţă, care urmează deplasarea
grupului. Formal, vectorul de mişcare al unui membru i al grupului la momentul t, Vgrup t, poate fi
descris ca:
V it = Vgrupt + RMit

unde RMit este un vector aleator care reprezintă deviaţia unui membru i al grupului faţă de
propriul său punct de referinţă. Acest vector este un proces aleator independent distribuit identic

32
în intervalul [0, rmax] unde rmax este deviaţia maximă acceptată şi a cărui direcţie este uniform
distribuită în intervalul [0, 2π]

Fig. 6.8. Deplasarea nodurilor în modelul RPGM

RPGM este capabil să reprezinte diferite scenarii de mobilitate:

- Modelul mobilităţii zonale: întreaga arie este împărţită în câteva regiuni adiacente.
Fiecare regiune este ocupată exclusiv de un grup.
- Modelul cu zone de mobilitate care se intersectează – diferite grupuri cu diferite
modele de mobilitate în aceeaşi zonă, deplasările acestor grupuri intersectându-se.
- Modelul de tip conferinţă: zona de simulare este împărţită în mai multe regiuni şi
unor grupuri le este permisă deplasarea între regiuni.

6.2. Protocoale de rutare proactive, reactive şi hibride

Clasificarea protocoalelor de rutare in reţelele ad hoc se realizează în funcţie de modul în

care informaţiile de rutare sunt obţinute şi menţinute în nodurile mobile. In funcţie de aceasta,
protocoalele se împart în: proactive, reactive şi hibride.

1. Protocoalele proactive sunt cunoscute şi sub denumirea protocoale de rutare

pe baza de tabel. Utilizând un protocol proactiv, nodurile mobile dintr-o reţea ad hoc formează
în mod continuu rute către toate nodurile la care se poate ajunge, încercând să asigure în acelaşi
timp o informaţie de rutare actualizată. Din această cauză, un nod sursă poate să primească o cale
de rutare imediat ce o solicită. In cadrul protocoalelor proactive, toate nodurile trebuie sa asigure
o imagine completă despre topologia reţelei. Când are loc o modificare în cadrul topologiei, toate
nodurile trebuie informate. Cele mai multe protocoale proactive propuse pentru reţelele ad hoc
au preluat structura şi caracteristicile algoritmilor utilizaţi în reţelele cu fir. Protocoalele utilizate
in reţelele ad hoc actualizează continuu starea reţelei şi menţin rutele indiferent dacă este trafic
sau nu, astfel încât rezultă o suprasarcina de trafic pentru a menţine actualizate informaţiile
despre topologia reţelei.
2. Protocoalele de rutare reactive sunt cunoscute şi sub denumirea de protocoale
reactive la cerere. In acest tip de protocoale, căile de rutare sunt căutate numai atunci când este
nevoie de ele. Procedura de descoperire a unei rute se încheie fie când ruta este gasită, fie când
nu există nici o rută disponibilă, după examinarea tuturor permutărilor de rute. Intr-o reţea ad
hoc, rutele active pot fi deconectate datorită mobilităţii nodurilor. De aceea, mentenanţa rutelor

33
 este un obiectiv important al protocoalelor reactive. In comparaţie cu alte protocoale pentru
reţelele ad hoc, sarcina de trafic de control este mai mică, ceea ce constituie un avantaj.
Dezavantajul acestui protocol constă în faptul că la nivelul nodurilor sursă se înregistrează
întârzieri destul de mari pentru căutarea rutelor, înainte de transmiterea mai departe a pachetelor.
Exemple de astfel de protocoale: Dynamic Source Routing (DSR) şi Ad Hoc On-Demand
Distance Vector (AODV).
3. Protocoalele hibride combină avantajele protocoalelor proactive cu ale celor
reactive, diminuând dezavantajele lor. Acest tip de protocoale se utilizează în special în
arhitecturile ierarhice de reţele. Astfel, în unele niveluri sunt utilizate protocoale proactive, în
timp ce în altele sunt utilizate protocoale reactive.
Exemple de astfel de protocoale : Zone Routing Protocol (ZRP), Zone-Based
Hierarchical Link State (ZHLS), Hybrid Ad Hoc Routing Protocol (HARP).

Structura task-urilor de rutare

O alta metodă de clasificare a protocoalelor se bazează pe rolul pe care nodurile le

au în procesul de rutare. Intr-un protocol de rutare uniform, toate nodurile mobile au acelaşi rol,
importanţă şi funcţionalitate. Exemple de protocoale de rutare uniforme: WRP, DSR, AODV,
DSDV.
Intr-un protocol neuniform de rutare, nodurile au funcţii de control şi rutare
diferite. In mod obişnuit, algoritmii distribuiţi sunt utilizaţi pentru selectarea acestor noduri
speciale. In unele cazuri, protocoalele neuniforme sunt utilizate în reţelele cu structură ierarhică,
pentru a facilita organizarea şi controlul nodurilor.
Protocoalele de rutare neuniforme se împart în trei categorii:
- de rutare ierarhică pe zone;
- rutare ierarhică pe clustere;
- rutare pe baza unui nod central.

1. In protocoalele de rutare ierarhică pe zone, sunt utilizaţi diferiţi algoritmi de construire a

zonelor, pentru organizarea nodurilor. De exemplu, unii algoritmi de construire a zonelor
utilizează informaţiile geografice. Nodurile mobile din aceeaşi zonă au informaţii despre cum să
ajungă de la unul la altul, cu costuri mai mici decât cele necesare menţinerii informaţiei de
rutare pentru toate nodurile din întreaga reţea. In unele protocoale anumite noduri funcţionează
ca porţi (gateway) pentru comunicaţiile interzonale. Exemple de astfel de protocoale: ZRP şi
ZHLS.
2. Protocoalele de rutare ierarhică pe clustere utilizează algoritmi speciali de selectare a
nodurilor de control al cluster-elor. Nodurile mobile sunt grupate în clustere, iar nodurile de
control (clusterhead) au funcţia de control şi de rutare pentru celelalte noduri din cluster.
Exemplu: Clusterhead Gateway Switch Routing (CGSR). Anumite astfel de protocoale se aplică
pentru structurile de cluster pe mai multe niveluri, de exemplu HSR (Hierachical State Routing).
3. In protocoalele de rutare bazate pe nodurile centrale, nodurile critice sunt selectate dinamic,
pentru a compune structura reţelei. Aceste noduri au funcţii speciale, ca de exemplu construirea
căilor de rutare şi control, precum şi controlul propagării pachetelor de date. Exemplu: Core-
Extraction Distributed Ad Hoc Routing (CEDAR).

Selectarea metricilor de reţea pentru rutare

34
 Metricile utilizate pentru construirea căilor de rutare sunt utilizate pentru clasificarea
protocoalelor de rutare în reţelele ad hoc. Multe protocoale utilizează ca metrică numărul de
hop-uri. Dacă există mai multe căi de rutare disponibile, va fi selectată calea cu numărul minim
de hopuri. Dacă toate link-urile wireless din reţea au aceeaşi probabilitate de eşec, căile de rutare
mai scurte sunt mai stabile decât cele lungi şi evident, se reduce suprasarcina de trafic şi
coliziunea pachetelor. Astfel, pentru a asigura stabilitatea unui link, este foarte importantă etapa
de construcţie a rutelor. De exemplu, Associatively Based Routing (ABR) şi Signal Stability-
Based Routing (SSR) utilizează stabilitatea link-ului sau puterea semnalului ca metrică pentru
procesul de rutare.
Aplicaţiile mobile pot avea cerinţe diferite în ceea ce priveşte gradul QoS. Astfel, QoS
poate constitui metrica utilizată în rutarea pachetelor şi transmiterea lor mai departe în reţelele
ad hoc.

Evaluarea topologiei, destinaţiei şi a localizării pentru rutare

Intr-un protocol de rutare pe baza topologiei, nodurile colectează informaţiile despre

topologia reţelei pentru a lua deciziile de rutare.
Intr-un protocol de rutare pe baza destinaţiei, un nod trebuie sa cunoască numai
următorul hop de-a lungul căii de rutare în momentul în care trebuie să trimită mai departe un
pachet de date. De exemplu, DSR este un protocol de rutare pe baza topologiei, iar AODV şi
DSDV sunt protocoale de rutare pe baza destinaţiei.
In protocoalele de rutare bazate pe localizare, relaţia dintre pozitia nodului sursă şi cea a
nodului destinaţie, împreună cu mobilitatea nodului, pot fi folosite în descoperirea rutei şi
trimiterea mai departe a pachetelor. Schemele existente pentru rutarea pe baza localizării sunt de
două tipuri. In primul, nodurile mobile trimit pachete doar pe baza informaţiilor de localizare, iar
în al doilea, se utilizează atât informaţiile despre localizare, cât şi cele despre topologie.
Exemplu: Location-Aided Routing (LAR) şi Distance Routing Effect Algorithm for Mobility
(DREAM).

6.2.1. Protocoale de rutare proactive

6.2.1.1. Wireless Routing Protocol (WRP)

WRP este un protocol proactiv unicast utilizat în reţelele ad hoc. Utilizând WRP, fiecare
nod mobil memorează o tabelă a distanţelor, una a rutelor, una a costurilor link-urilor şi o listă
a mesajelor retransmise (MRL- Message Retransmisşion List). O înregistrare în tabela de rutare
conţine distanţa către nodul destinaţie, predecesorul şi succesorul său de-a lungul căii spre
destinţie, şi un indicator al stării (o cale sinplă, o buclă, sau invalidă). Un nod mobil crează o
înregistrare pentru fiecare vecin în tabela costrurilor link-urilor. O înregistrare conţine costul
link-ului de conectare la nodul vecin, precum şi numărul de mesaje recepţionate fără erori de la
acel vecin.
In WRP, nodurile mobile schimbă tabele de rutare cu vecinii lor, utilizând mesaje de
actualizare. Aceste mesaje pot fi trimise periodic sau ori de câte ori are loc o modificare. MRL
conţine informaţii despre vecinii care nu au confirmat un mesaj de actualizare. Dacă este cazul,
mesajele de actualizare sunt retransmise către vecinul respectiv. Dacă nu există nici o modificare

35
 în tabela de rutare de la ultima actualizare, unui nod i se cere să transmită un mesaj Hello pentru
a asigura conectivitatea. Odată recepţionat mesajul de actualizare, nodul modifică tabela
distanţelor şi cauta căi de rutare mai bune, pe baza informaţiilor actualizate.
Un protocol de rutare proactiv are o scalabilitate redusă şi nu se utilizează pentru reţele
ad hoc de mari dimensiuni.
Pentru a descrie WRP, se construieşte pentru reţeaua respectivă un graf neorientat, G(V,
E), unde V este mulţimea nodurilor şi E este mulţimea arcelor. Fiecare nod reprezintă un ruter şi
este o unitate de calcul, cuprinzând un procesor, o memorie locală şi buffere de intrare/ieşire de
capacitate nelimitată. Toate mesajele recepţionate (transmise) de un nod sunt memorate într-un
buffer de intrare (ieşire) şi procesate în ordine FIFO. Link-urile de comunicaţie în reţea sunt
proiectate astfel încât toate mesajele de actualizare sunt recepţionate în ordinea în care au fost
transmise. In momentul în care un link este întrerupt, înregistrarea corespunzatoare în tabelele de
distanţe şi de rutare este marcată cu ∞. Căderea unui nod este modelată prin iîntreruperea
simultană a tuturor link-urilor incidente în acel nod.
WRP operează la nivelul superior al protocolului MAC al reţelei wireless. Asigurarea
unor transmisii fiabile este asigurată prin existen-a retransmisiilor de date. Dupa recepţionarea
unui mesaj fără erori, unui nod i se cere sa transmită un pachet de confirmare (ACK) pozitivă.
Pentru a se asigura conectivitatea cu un vecin, în momentul în care nu există ACK sau mesaje de
actualizare recente, se transmit periodic mesaje de actualizare a vecinilor (fără actualizări în
tabela de rutare). Intervalul de timp intre două astfel de mesaje se numeşte interval Hello.

Informaţiile memorate la nivelul nodurilor

Pentru a asigura rutarea, fiecare nod memeorează o tabelă a distanţelor, una a rutelor,
una a costurilor asociate link-urilor şi un MRL.
Tabela distanţelor pentru nodul i este o matrice care conţine, pentru fiecare destinaţie j şi
pentru fiecare vecin al lui i (de exemplu, k), distanţa până la j (Dijk) şi predecesorul (pijk) raportat
la k.
Tabela de rutare a nodului i este un vector care conţine câte o înregistrare pentru fiecare
destinaţie cunoscută j, care specifică următoarele:
- identificatorul destinaţiei;
- distanţa pana la destinaţie (Dij);
- predecesorul de pe calea cea mai scurtă selectată către j (pij);
- succesorul (sij) de pe calea cea mai scurtă selectată către j;
- un marker (tagji) utilizat pentru actualizarea tabelei de rutare; specifică dacă înregistrarea
corespunde unei căi simple (tagji=corect) sau unei bucle (tagji=eroare), sau unei destinaţii care n-a
fost încă marcată (tagji=nul).
Tabela costurilor asociate link-urilor nodului i memorează costurilor transferurilor de
informaţie prin fiecare vecin k, precum şi numărul intevalelor temporare care au trecut de când
nodul i a recepţionat un mesaj fără erori de la nodul k. Costul unui link care s-a întrerupt este
considerat egal cu ∞. Costul unui link poate fi considerat egal cu 1 şi este egal cu numărul de hop-
uri, sau întarzierea de-a lungul link-ului plus o valoare constantă. Costul unui link de la i la k se
notează cu lik.
MRL specifică una sau mai multe înregistrari, unde cea de-a m-a înregistrare conţine:
- numărul de secvenţă al mesajului actualizat;

36
 - un contor de retransmisii care este decrementat ori de câte ori nodul i transmite un nou
mesaj de actualizare;
- un flag de ACK care specifică dacă nodul k a confirmat mesajul de actualizare în urma
retransmisiei;
- lista actualizarilor transmisă în mesajul de actualizare.
Toate aceste informaţii permit nodului i să selecteze actualizările (din mesajul de actualizare)
care trebuie retransmise şi să determine vecinii cărora trebuie să le ceară confirmările acestor
retransmisii.

Informaţiile schimbate între noduri

In WRP, nodurile schimbă între ele mesaje de actualizare a tabelelor de rutare, care se propagă
numai de la un anumit nod, către vecinii săi.
Un astfel de mesaj conţine următoarele informaţii:
- identificatorul nodului sursă;
- un număr de secvenţă alocat de către nodul sursă;
- o listă cu 0 sau mai multe actualizari sau cu confirmări ale mesajelor de actualizare.
Un mesaj de actualizare specifică destinaţia, distanţa până la destinaţie şi un predecesor al
nodului-destinaţie; un ACK specifică sursa şi numărul de secevenţă al mesajului de actualizare care
este confirmat.
- o listă de răspunsuri cu 0 sau mai multe noduri care trebuie să trimită un ACK pentru
mesajul de actualizare.
Lista de răspunsuri a mesajului de actualizare este utilizată pentru a evita situaţia în care unui
vecin i se cere să transmită mai multe ACK-uri pentru acelaşi mesaj de actualizare, numai pentru că
alt vecin al nodului sursă nu a transmis confirmarea.
Prima transmitere a unui mesaj de actualizare trebuie să le ceară tuturor vecinilor să transmită un
ACK şi acest lucru este realizat printr-o adresă cu toţi biţii “1”. Când mesajul nu conţine nici un fel
de actualizări, este transmisă o adresă cu toţi biţii egali cu “0”. Acest ultim tip de adresă este utilizat
ca un mesaj Hello.

6.2.1.2. Protocolul DSDV (Destination-Sequenced Distance Vector)

DSDV este un protocol de rutare proactiv, unicast, pentru reţelele mobile ad hoc.
In tabelele de rutare utilizate de DSDV, întegistrările memorează următorul hop către
destinaţie, metrica costurilor pentru calea de rutare către destinaţie şi un număr de secvenţă
pentru destinaţie. Numerele de secvenţă sunt utilizate în DSDV pentru a deosebi rutele vechi
de cele noi şi a evita formarea buclelor.
Actualizarea rutelor în DSDV poate fi determinată fie de expirarea unor intervale
temporare, fie de apariţia unui nou eveniment. Există două moduri de a transmite actualizarea
tabelei de rutare în DSDV:
- includerea în întregime a tabelei în mesajul de actualizare;
- transmiterea numai a acelor informaţii care s-au modificat de la ultima
transmisie.

37
 In DSDV fiecare nod i memorează pentru fiecare destinaţie z o mulţime a distanţelor
{d }, unde j  {vecinii nodului i}. Nodul i tratează nodul k, ca pe următorul hop, pentru un
z
ij
pachet destinat nodului x, dacă dxik= min { dxij}. Pentru a menţine actualizate estimările
distanţelor, fiecare nod monitorizează costurile link-urilor sale de ieşire şi difuzează periodic
vecinilor săi, estimările curente ale celor mai scurte distanţe către fiecare nod din reţea.
Avantajele utilizării acestui algoritm sunt: simplitatea implementarii şi dimensiunea mică
a memoriei necesare. Dezavantajul său constă în crearea unor bucle de durată mică sau mare.
Cauza acestor bucle de rutare este determinată de faptul că nodurile îşi selectează hop-urile
următoare într-un mod distribuit, bazat pe informaţii care pot fi neactualizate şi deci,
incorecte.
In DSDV datele difizate de către fiecare nod conţin numărul său de secevenţă, precum şi
următoarele informaţii pentru fiecare nouă ruta:
- adresa destinaţiei;
- numărul de hop-uri cerute până la destinaţie;
- numărul de secvenţă asociat informaţiei recepţionate de către nodul destinaţie.
Rutele cu cele mai recente numere de secvenţă vor fi preferate în luarea deciziilor
viitoare de rutare.

6.2.2. Protocoale de rutare reactive

6.2.2.1. Protocolul AODV (Ad Hoc On-Demand Distance Vector

Routing)

Ca şi la alte protocoale de rutare reactive, gasirea unei rute se bazează pe un algoritm

ciclic care difuzează cererea de căutare în întreaga reţea şi primeşte o replică unicast continând
căile descoperite. Ca şi DSDV, AODV se bazează pe utilizarea numerelor de secvenţă, pentru
evitarea buclelor şi pentru descoperirea celei mai recente căi de rutare. In AODV, nodurile
memorează o tabelă de rutare în care se memorează informaţia de rutare către hop-ul următor.
Fiecare înregistrare din tabela de rutare are asociat un timp de memorare. Dacă o ruta nu a fost
utilizata în acest interval de timp, ruta expiră. Altfel, de fiecare dată când ruta este utilizată,
timpul de memorare este actualizat, astfel încât ruta să nu fie ştearsă.
Când un nod sursă are de transmis pachete de date, mai întâi verifică dacă nu există deja
o ruta stabilită către destinaţia selectată. Dacă nu există o astfel de rută, va ini-ţia o procedură de
descoprire a rutei, prin crearea unui pachet RREQ (Route REQuest). In acest pachet va înscrie
adresa IP a nodului destinaţie, ultimul număr de secvenţă cunoscut, adresa IP a sursei şi
numărul său de secvenţă curent. RREQ conţine deasemenea un contor de hop-uri, iniţializat cu 0
şi un RREQ ID. Acesta este un contor asociat fiecărui nod, care este incrementat ori de câte ori
nodul iniţiază o nouă RREQ. Astfel, adresa IP a nodului sursă împreună cu RREQ ID definesc în
mod unic o RREQ şi poate fi utilizată pentru a detecta duplicatele. Dupa crearea acestui mesaj,
sursa difuzează RREQ către nodurile învecinate.
In momentul în care un nod vecin primeşte o RREQ, crează o rută inversă către sursă.
Nodul de la care a recepţionat RREQ este următorul hop către nodul sursă iar contorul de hop-uri
din RREQ este incrementat. Dacă nu gaseşte nici o rută validă către destinaţie, va redifuza
RREQ către vecinii săi, cu incrementarea contorului de hop-uri. Astfel RREQ va inunda reţeaua
în căutarea unei rute către destinaţie. Fig.6.9 ilustrează acest proces de inundare.

38
 Fig.6.9. Descoperirea şi menţinerea rutelor in AODV

In momentul în care un nod primeşte RREQ, va verifica dacă are o rută neexpirată către
destinaţie. Dacă are o astfel de rută, va trimite un mesaj de reply indicând ruta. Înregistrarea din
tabelul de rutare pentru destinaţie, trebuie să fie un număr de secvenţă corespunzator, care este
mai mare sau egal cu cel din RREQ:
Dseqrt ≥ DseqRREQ
Cât timp se menţine această condiţie înregistrarea destinaţiei din tabela de rutare este cel
puţin la fel de recentă ca şi ultima rută cunoscută de nodul sursă către destinaţia selectată. Odata
îndeplinită această condiţie, nodul va crea un mesaj Route REPly (RREP). RREP conţine adresa
IP a nodului sursă, a celui de destinaţie, precum şi numărul de secvenţă din tabela de rutare.
Contorul de hop-uri din RREP este setat ca fiind egal cu distanţa până la destinaţie. Dacă însuşi
nodul destinaţie crează RREP, contorul de hop-uri este iniţializat cu 0. Dupa crearea acestuia,
nodul îl trimite în mod unicast către urmatorul hop, către sursă.
Odata stabilită ruta, ea trebuie menţinută atâta timp cât este nevoie. O rută care a fost
recent utilizată pentru transmiterea pachetelor este denumită rută activa. Datorita mobilităţii
nodurilor, este foarte probabil ca link-urile de-a lungul rutei să se desfiinţeze.Dacă un astfel de
link face parte dintr-o rută activă, el trebuie refăcut cât mai repede, pentru a se evita pierderea de
pachete. Când apare această problemă pentru un link dintr-o rută activă, nodul de la capătul
acelui link (de lânga nodul sursă) va invalida rutele către fiecare dintre destinaţiile din tabela sa
de rutare.Va crea apoi un mesaj RERR (Route ERRor). In acest mesaj vor fi incluse toate
destinaţiile care sunt inaccesibile datorita desfiinţării acelui link. Dupa crearea acestui mesaj, îl
va difuza şi către toate nodurile vecine care utilizau acel link. Acestea vor invalida rutele care nu
se mai pot folosi şi vor crea propriile lor mesaje RERR către vecinii care utilizau acel link.
Astfel, RERR va parcurge calea inversă către nodul sursă.
Pentru AODV s-au facut şi anumite optimizări.
1. Pentru a îmbunătăţi performanţele protocolului şi a reduce suprasarcina de trafic,
nodurile sursă vor putea utiliza un cerc extins de căutare pentru rutele către destinaţie.
Propagarea RREQ este controlată prin modificarea valorii TTL (Time_To_Live) asociată fiecărui
pachet. Căutarea rutei în reţea se realizează acum. pe suprafeţe mari. Dacă ruta către destinaţie
este gasită local, se evită inundarea cu mesaje a reţelei.
2. O altă optimizare constă în refacerea locală a link-urilor din rutele active. Astfel, în loc
de a trimite mesajul RERR către nodul sursă, nodul de la capătul link-ului va încerca să-l refacă.
Dacă operaţia reuşeşte, se vor pierde mai puţine pachete, deoarece refacerea durează mai puţin
timp.Dacă operaţia nu reuşeşte, un mesaj RERR va fi trimis către nodul sursă aşa cum s-a
menţionat.

39
 3. AODV conţine şi anumite trăsături particulare, care permit operarea în scenarii bine
determinate. Astfel, dacă în procesul descoperirii rutei, răspund numai nodurile intermediare şi
nodul destinaţie nu recepţionează nici o copie a RREQ, destinaţia nu va trebui sa aibă o rută către
nodul sursă. Dacă este necesară o comunicaţie bidirecţională cu nodul destinaţie, lipsa acestei
rute de la destinaţie către sursă poate crea probleme. De aceea, AODV defineşte o RREP
gratuită care poate fi trimisă către nodul destinaţie când RREP este creat de un nod intermediar.
Acest mesaj informează nodul destinaţie de ruta către sursă, ca şi cum nodul destinaţie ar fi
realizat descoperirea rutei. Un alt tip de mesaj este RREP-ACK. Când apare posibilitatea de a
exista link-uri unidirecţionale în reţea, RREP-ACK sunt utilizate pentru a se asigura că pe
următorul hop s-a recepţionat RREP. Dacă un RREP-ACK nu este recepţionat, se utilizează liste
negre care indică link-urile unidirecţionale, astfel încât ele să nu mai fie utilizate în viitor în
procedurile de descoperire a rutelor. AODV permite folosirea mesajelor Hello pentru
monitorizarea conectivitaţii între nodurile vecine.
Formatul mesajelor
a. Mesajul RREQ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip |J|R|G|D|U| Rezervat |Contor hop-uri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa IP a destinaţiei |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numărul de secvenţa al destinaţiei |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+
| Sursa adresei IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sursa numărului de secvenţă |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

b. Mesajul RREP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip |R|A| Rezervat |Prefix Sz|Contor hop-uri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa IP a destinaţiei |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numărul de secvenţă al destinaţiei |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sursa adresei IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timpul de viaţă |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

40
 c. Mesajul RERR

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip |N| Rezervat | Contor dest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa IP a destinaţiei inaccesibile (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numărul de secvenţă al destinaţiei inaccesibile (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Adrese IP aditionale ale destinaţiilor inaccesibile (dacă e |
| necesar) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Numere de secvenţă aditionale ale destinaţiilor inaccesibile |
|(dacă e necesar) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2.2.2. Protocolul DSR (Dynamic Source Routing)

Ca şi AODV, DSR este un protocol de rutare reactiv. Există însă anumite diferenţe în
comparaţie cu AODV. In primul rând, rutarea este controlată de nodul sursă (pachetele de date
nu mai sunt transmise de la un hop la altul). Pachetele de date conţin rutele care specifică strict
fiecare nod de la sursă la destinaţie. Pachetele RREQ şi RREP acumulează rutele de la un nod
sursă, astfel încât, odata ruta descoperită, ea este “invaţată” şi utilizată în rutările viitoare.
Fig.6.10 ilustrează procedura de descoperire a rutelor.

41
 Fig.6.10. Descoperirea rutelor în DSR

Nodul sursă înscrie adresa IP a destinaţiei, precum şi propria sa adresă în RREQ. Astfel, în
timpul parcurgerii reţelei de către RREQ, calea se va memora în acest mesaj. In momentul în
care un nod intermediar primeşte RREQ, va actualiza înregistrarile în tabela de rutare pentru
fiecare nod de pe ruta parcursă de la sursă (nu numai pentru nodul sursă).
Când unul dintre nodurile care are o rută către destinaţie recepţionează RREQ, va
răspunde prin crearea unui mesaj RREP. Dacă nodul este chiar destinaţia, va înscrie ruta
acumulată în RREQ în RREP. Altfel, dacă este un nod intermediar, va concatena propria sa rută
către destinaţie rutei acumulate în RREQ şi o va înregistra în RREP. In ambele scenarii, mesajul
conţine ruta completă dintre sursă şi destinaţie. Deoarece nodurile intermediare recepţionează şi
procesează mesajele RREP, ele pot crea sau actualiza înregistrari în tabela de rutare pentru
fiecare dintre nodurile aflate de-a lungul rutei.
DSR utilizează o memorie cache pentru înregistrarea rutelor. Aceasta permite înregistrarea
şi menţinerea unor rute multiple către o destinaţie, asigurând astfel o rutare multicale. In
momentul în care o rută către destinaţie este distrusă, sursa poate utiliza o ruta alternativă din
memoria cache, dacă este disponibilă, fără a mai fi necesar un nou proces de descoperire a rutei.
In mod similar, dacă este distrus un link care aparţine unei rute, nodul de la capătul rutei va apela
o procedura de reconstituire a rutei, încercând să găsească o nouă cale în memoria sa cache.
Totuşi, chiar şi atunci când ruta a fost reconstituită, un mesaj RERR trebuie trimis sursei, pentru
a o informa despre acest eveniment.
O altă caracteristică importantă a protocolului DSR este că înregistrarile din memoria
cache nu au timp de viaţă limitat. O rută înregistrată în memorie va fi menţinută până când este
distrusă. Nodurile DSR au opţiunea de ascultare ilegală, ceea ce înseamnă că pot recepţiona şi
procesa pachetele de date şi control care nu le sunt adresate la nivel MAC. Prin această operaţie,
nodurile DSR vor putea “învăţa” noi rute (rute gratuite), către alte destinaţii din reţea. Pentru a
reduce suprasarcina de trafic, DSR permite ca starea fluxului de date să fie stabilită în nodurile
intermediare. Aceasta permite transmiterea mai departe a pachetelor (hop-by-hop), tot sub
controlul nodului sursă.

Formatul header-ului pentru opţiunile DSR

DSR utilizează un header special pentru informaţiile de control care pot fi incluse în
oricare dintre pachetele IP. Acest header conţine un cadru de dimensiune fixă, de 4 octeţi, urmat

42
 de o secvenţă de zerouri sau mai multe opţiuni DSR. Terminarea secvenţei de opţiuni DSR este
dată de lungimea totala specificată în header. Dacă un alt header urmează după opţiunile DSR în
pachetul respectiv, lungimea totală a tuturor opţiunilor DSR trebuie să fie un multiplu de 4 octeţi.
Această cerinţă asigură alinierea header-elor în pachet.

Partea fixă a header-ului pentru opţiunile DSR

Acest cadru are urmatorul format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Urmat. Header |F| Rezervat |Dimenşiune pachet opţiuni |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Opţiuni .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Următorul header – câmpul are 8 biţi; identifică tipul header-ului care urmează după
opţiunile DSR. Dacă nu urmează nici un alt header, are valoarea 59, care semnifică Nu există
nici un header următor
F – flag, care trebuie setat 0; este egal cu 1 numai în pachetele DSR de date (0 în
header-ele pachetelor de opţiuni DSR)
Rezervat – câmp setat 0 şi ignorat la recepţie
Dimensiune pachet opţiuni – defineşte lungimea totala a opţiunilor DSR din pachetul
respectiv (fără câmpul fix de 4 octeţi)
Opţiuni – câmp de dimensiune variabilă (specificată în Dimensiune pachet opţiuni);
conţine una sau mai multe opţiuni.

Fiecărui tip de opţiune DSR îi este alocat un cod (Option Type Code), de 3 biti, care
permite unui nod ce nu procesează opţiunea respectivă, să realizeze următoarele prelucrări :
- în funcţie de valoarea bitului cel mai semnificativ, va răspunde sau nu cu un mesaj RERR
de tipul Opţiunea-nu-este-suportată (cu exceptia cazului în care o astfel de RERR nu trebuie
trimis ca răspuns pachetului RREQ)
- următorii 2 biţi indică modul în care nodul trebuie să proceseze pachetul respectiv:
- 00 – ignora opţiunea
- 01 – retrage opţiunea
- 10 – marchează opţiunea
- 11 – elimină pachtul
Când biţii sunt 00, nodul respectiv va ignora opţiunea şi va continua procesarea.
Când biţii sunt 01, nodul va retrage opţiunea din pachet şi va continua procesarea, ca şi
în cazul în care aceasta n-ar fi fost inclusa în pachet.
Când biţii sunt 10, nodul va seta cel mai semnificativ bit care urmează câmpului
Dimensiune pachet opţiuni, va ignora opţiunea şi va continua procesarea.
Când biţii sunt 11, nodul va elimina pachetul.

In DSR sunt definite următoarele opţiuni:

- Route Request
- Route Reply

43
- Route Error
- Acknowledgement Request
- Acknowledgement option
- DSR Source Route
- Pad1
- PadN

a. Opţiunea Route Request

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip opţiune | Dimenşiune | Identificator |
| | pachet opt | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa nodului din RREQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Câmpuri IP:
Adresa sursei – setată de nodul care a iniţiat transmiterea pachetului (nodurile
intermediare nu trebuie să modifice acest câmp)
Adresa destinaţiei
Limita numărului de hop-uri (setată de la 1 la 255)

Câmpuri din RREQ

Tip opţiune – nodurile pentru care acest camp este neidentificabil, vor ignora opţiunea
Dimensiune pachet opţiuni – întreg de 8 biţi; dimensiunea, în octeţi, excluzând Tip
opţiune şi Dimensiune pachet opţiuni, trebuie să fie de (4*n)+6, unde n este numărul de adrese
din RREQ.
Identificator – o valoare unică generată de nodul care a trimis RREQ; nodurile care
iniţiază o RREQ generează o valoare nouă a identificatorului pentru fiecare RREQ (de exemplu,
pe baza contorului de numere de secvenţă pentru toate RREQ iniţiate de nod).

44
 Această valoare permite nodului care recepţionează mesajul să determine dacă acesta
este nou, sau o copie recentă; dacă valoarea identificatorului va fi gasită în tabela RREQ, nodul
va elimina mesajul RREQ.
Adresele [1..n]
Adresa[i] este adresa Ipv4 a nodului i înregistrată în RREQ. Adresa sursei din header-ul
IP nu trebuie listată în câmpurile Adresa[i]. Adresa[i] este adresa Ipv4 a primului nod aflat după
nodul sursă. Numărul adreselor este indicat în Dimensiune pachet opţiuni (n= (Dimensiune
pachet opţiuni-6)/4). Fiecare nod care transmite mai departe RREQ îşi va adauga propria adresă
acestei liste, incrementând Dimensiune pachet opţiuni cu 4 octeţi.

b. Opţiunea Route Reply

Formatul RREP este următorul:

Câmpuri IP
Adresa sursei – setată cu adresa nodului care trimite RREP
Adresa destinaţiei – adresa nodului sursă al rutei (copiată din Adresa sursei din RREQ)
Câmpurile din RREP
Dimensiune pachet opţiuni – egal cu (4*n)+1, unde n este numărul de adrese din RREP
Ultimul hop extern (L) – setat pentru a indica faptul că ultimul hop din RREP (de la link-
ul de la adresa[n-1] la adresa[n] ) este o cale arbitrară dintr-o reţea externă celei DSR; ruta exactă
din afara reţelei DSR nu este reprezentată în RREP
Rezervat – este setat cu 0 şi ignorat la recepţie
Adresele [1..n] – constituie ruta care trebuie returnată sursei prin RREP. Ruta indică o
secvenţă de hop-uri, cu originea în nodul sursă specificat în Adresa destinaţiei din câmpul IP al
header-ului pachetului RREP, prin fiecare din nodurile Adresa[i] în ordinea listată în RREP.
Numărul de adrese este n= (Dimensiune pachet opţiuni-1/4. O opţiune RREP poate apare o dată
sau de mai multe ori în header-ul opţiunilor DSR.

45
 c. Opţiunea Source Route
Formatul SR este următorul:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip opţiune | Dimenşiune |F|L|Rezervat|Salvat|Seg ramase |
| pachet opt | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[2] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa[n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dimensiune pachet opţiuni – setat la valoarea (n*4) + 2, unde n este numărul de adrese din
câmpurile de adresă.
Primul hop extern (F) – indică faptul că primul hop specificat de opţiunea SR este o cale
arbitrară într-o reţea externă celei DSR
Ultimul hop extern (L) – indică faptul că ultimul hop specificat de opţiunea SR este o cale
arbitrară într-o reţea externă celei DSR
Salvat – un întreg de 4 biţi, fără semn, contorizează de câte ori pachetul a fost salvat în
timpul rutării DSR
Seg rămase – specifică numărul de segmente rămase (numărul de noduri intermediare care
mai trebuie vizitate înainte de a ajunge la destinaţie)
Adresele[1..n] – specifică secvenţa de adrese de-a lungul rutei. Numărul de adrese este dat
în Dimensiune pachet opţiuni (n=( Dimensiune pachet opţiuni-2)/4)

d. Opţiunea Route Error

Formatul RERR este următorul:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tip opţiune |Dimenşiune |Tip Eroare |Rezervat|Salvat|
| pachet opt | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa sursa eroare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresa destinaţie eroare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Informaţii specifice de tip .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

46
 Tip opţiune – trebuie setat cu 10, plus mărimea oricărei informaţii specifice de tip din
RERR
Tip eroare – există următoarele valori:
1 – nod inaccesibil
2 – flux de date care nu poate fi suportat de conexiune
3 – opţiune care nu poate fi suportată de conexiune
Salvat – copiat din câmpul similar din opţiunea Source Route. Contorul total Salvat
este derivat din câmpul Salvat al opţiunii RERR date şi din cel al precedentelor din pachet:
contorul Salvat este suma, pentru fiecare opţiune RERR: 1+câmpul Salvat al opţiunii RERR date
Adresă sursă eroare – adresa nodului care a iniţiat RERR
Adresă destinaţie eroare – adresa nodului căruia trebuie să i se transmită RERR.
Informaţii specifice de tip – specifică tipul erorii din RERR

6.2.2. Protocolul OLSR (Optimized Link State Routing protocol)

OLSR este un protocol proiectat pentru reţelele mobile ad hoc. Este un protocol proactiv,
care operează pe baza unei tabele de rutare, schimbând informaţii despre topologia reţelei la
intervale regulate de timp. Fiecare nod selectează o mulţime dintre nodurile sale vecine, ca MPR
(MultiPoint Relays). In OLSR, numai nodurile selectate ca MPR sunt responsabile pentru
transmiterea mai departe a traficului de control. Utilizarea MPR asigură un mecanism eficient
pentru controlul inundării cu pachete de date a reţelei, prin reducerea numărului de transmisii
necesare. Astfel, singura cerinţă a protocolului OLSR de a asigura rutele cele mai scurte către
toate destinaţiile, se poate asigura prin transmiterea informaţiilor despre starea link-urilor de
către nodurile dintr-o mulţime MPR către selectorul lor MPR. Un nod selectează nodurile MPR
asociate dintre vecinii săi simetrici (cu link bidirecţional) aflaţi la distanţa de 1 –hop.
OLSR este proiectat să opereze independent de existenţa altor protocoale. Este utilizat în
special în reţelele mari şi dense, unde opţiunea existenţei MPR îi asigură o eficienţă maximă. De
asemenea este foarte potrivit pentru reţelele cu un trafic aleator şi sporadic între un număr mare
de noduri.
OLSR poate optimiza reacţia la modificările din topologia reţelei, prin reducerea
intervalului maxim la care se transmit mesajele de control periodice.
Protocolul nu necesită transmisii foarte fiabile ale mesajelor de control: fiecare nod
transmite periodic mesaje de control şi deci, poate suporta o anumita proporţie de mesaje
pierdute din totalul celor transmise. De asemenea, OLSR nu necesită o livrare secvenţială a
pachetelor de date. Fiecare mesaj de control conţine un număr de secvenţă, care este incrementat
pentru fiecare pachet de date.

6.2.3.1. Funcţiile de bază

Protocolul este definit în Request For Comment(RFC) 3626.
In RFC3626 sunt specificate atât funcţiile de bază ale OLSR care sunt întotdeauna
necesare pentru ca protocolul să opereze în mod corect, cât şi un set de funcţii auxiliare.
Funcţiile auxiliare oferă facilitaţi suplimentare, care pot fi aplicabile în anumite scenarii,
ca de exemplu, în cazul în care un nod asigură conexiunea unei reţele MANET cu un alt tip de
reţea.

47
 Protocolul permite implementarea de noduri heterogene (de exemplu, noduri care pun în
aplicare diferite submulţimi ale funcţiilor auxiliare, care să coexiste în reţea).
Protocolul OLSR nu rutează trafic, el fiind conceput pentru întreţinerea şi menţinerea
tabelei de rutare utilizată pentru dirijarea pachetelor (astfel de protocoale sunt de obicei
menţionate în continuare ca protocoale de rutare).

6.2.3.1.1. Adresarea Nodurilor

OLSR utilizează o adresă IP ca unic identificator al nodurilor din reţea. Deoarece OLSR
este conceput pentru noduri cu interfeţe de comunicaţie multiple, fiecare nod trebuie să aleagă o
adresă IP care va fi considerată adresa sa principala.
OLSR poate utiliza atât adrese IPv4, cât şi IPv6. Diferenţele dintre IPv4 şi IPv6 sunt:
- dimensiunea adreselor IP transmisă în mesajele de control;
- dimensiunea minimă a mesajelor şi adresa utilizată ca destinaţie pentru traficul de
control.

6.2.3.1.2.Multipoint Relaying

OLSR utilizează inundarea cu pachete pentru a difuza informaţii despre topologie în

întreaga reţea. Inundarea înseamna că toate nodurile retransmit pachetele recepţionate. Pentru a
evita buclele, se utilizează un număr de secvenţă. Acest număr de secvenţă este înregistrat de
nodurile care primesc pachetul, pentru a se asigura că
pachetele sunt retransmise doar o singură data. În cazul în care un nod primeşte un pachet cu un
număr de ordine mai mic sau egal cu ultima înregistrare a pachetului, acesta nu va fi retransmis.
Numărul de retransmisii folosind inundarea tradiţională este n-1, unde n este numărul de
noduri din reţea. În cazul nostru (Fig.6.9), acesta va fi 24. Această tehnică de inundare poate
beneficia în continuare de optimizări.
Conceptul de retransmitere multipunct, utilizat în OLSR, constă în reducerea numărului
de retransmisii duplicat în timpul difuzării unui pachet. Această tehnica restrânge mulţimea de
noduri care retransmit un pachet de la toate nodurile, la o submulţime a acestor noduri.
Dimensiunea acestui subgrup depinde de topologia reţelei.
Tehnica se bazează pe selectarea vecinilor ca relee multipunct (MPR). Fiecare nod
calculează propria sa mulţime de MPR, ca o submulţime a nodurilor sale vecine şi simetrice, cu
proprietatea că toţi vecinii de 2 hopuri să poată fi ajunşi printr-un MPR. Acest lucru înseamnă că
pentru fiecare nod n din reţea, care poate fi ajuns de la nodul local prin cel puţin două hopuri
simetrice, trebuie să existe un MPR m, astfel încât n are un link simetric la m şi m este un vecin
simetric al nodului local.

48
 Fig.6.11.Inundarea cu un pachet Fig. 6.12. Inundarea cu un pachet într-o
într-o reţea wireless reţea wireless multihop de la nodul
central cu ajutorul MPR(negru).

OLSR permite ca nodurile să-şi anunţe disponibilitatea lor de a acţiona ca MPR pentru
vecini. 8 niveluri de disponibilitate sunt definite, de la cel mai mic WILL_NEVER(0), care
indică faptul că acest nod nu trebuie niciodată să fie ales ca MPR, la cel mai înalt
WILL_NEVER(7) care indică faptul că acest nod trebuie să fie întotdeauna ales ca un MPR.;
mesajele de disponibilitate se difuzează prin intermediul mesajelor Hello şi aceste informaţii
trebuie să fie luate în considerare când se calculează MPR.

6.2.3.1.3. Biblioteci de informaţii

Protocolul OLSR presupune existenţa unor baze de date şi informaţii. Aceste baze de
date sunt actualizate pe baza prelucrării mesajelor de control primite şi a
informaţiilor memorate şi utilizate atunci când se generează astfel de mesaje.

Multiple Interface Association Information Base

Acest set de date conţine informaţii despre nodurile care utilizează mai multe interfeţe de
comunicaţii. Toate adresele interfeţelor sunt memorate în această bază de date.

Link Set
Această informaţie este memorată pentru a determina starea link-urilor către vecini. Este
singura bază de date care nu operează pe baza adresei principale, deoarece se referă la link-uri
specifice interfaţă-interfaţă.

Neighbor Set

49
 Toate înregistrarile legate de vecinii situati la distanţa de 1-hop sunt memorate în această
bază de date. Datele sunt actualizate în mod dinamic, pe baza pe informaţiilor din Link Set. Sunt
memoraţi atât vecinii simetrici, cât şi cei asimetrici.

2-hop Neighbor Set

Toate nodurile, fără a include nodul local, care poate fi ajunse printr-un vecin situat la o
distanţă de 1-hop, sunt memorate în această bază de date. Trebuie observat că mulţimea
nodurilor de 2-hop-uri poate conţine noduri memorate în Neighbor Set.

MPR Set
Toate MPR selectate de către nodul local sunt memorate în această bază de date.

MPR Selector Set

Toţi vecinii care au ales această nod ca MPR sunt memoraţi în această bază de date.

Topology Information Base

Această bază de date conţine informaţii despre toate stările link-urilor, informaţii primite de la
toate nodurile din domeniul de rutare al OLSR

Duplicate set
Această bază de date conţine informaţii despre mesajele recent prelucrate şi transmise .
Pentru a se putea verifica dacă un mesaj a fost deja retransmis, există o memorie cache a
mesajelor prelucrate şi transmise recent. Datele memorate reprezintă informaţia minimă
necesară pentru a identifica mesajul. Acest lucru înseamnă că actualul conţinut al mesajelor nu
este memorat, fiind reţinute doar adresa nodului sursă, tipul mesajului şi numărul de secvenţă.
Aceste date sunt memorate pentru o durată de timp constantă DUP_HOLD_TIME , de
aproximativ 30 sec. Fiecare mesaj primit, care este procesat de către nodul local este înregistrat
în mulţimea duplicatelor. În cazul în care mesajul este retransmis, înregistrarea în memorie este
actualizată în consecinţă, specificându-se interfeţele prin care a fost transmis mesajul. Pe baza
interogării memoriei duplicatelor, un nod poate urmări mesajele deja procesate şi deja
retransmise pentru fiecare interfaţă de bază.
Expirări de timp
Cele mai multe informaţii memorate în bazele de date specificate anterior, au un timp de
expirare specificat. Acesta indică intervalul de timp în care informaţiile înregistrate pot fi
considerate valabile. Valoarea sa este stabilită în funcţie de un termen de valabilitate descărcat
din mesajul care a fost utilizat ultima dată pentru actualizarea datelor. Utilizarea acestui timp
permite transmiterea de mesaje individuale pentru toate nodurile din reţea. Toate înregistrarile
din baza de date sunt şterse atunci când nu mai sunt valabile, conform cu timpul de expirare
stabilit. Astfel de înregistrări se spune că sunt timed out.
Traficul de control
RFC specifică faptul că mesajele de trafic de control trebuie transmise când se utilizează
IPv4, dar nu se specifică adresa de difuzare. Dacă atunci când se utilizează IPv6, nu există o

50
adresă de difuzare, chiar dacă nu se specificată în RFC, se consideră implicit că trebuie utilizată
o adresă multicast.

6.2.3.1.4. Formatul pachetului

Formatul pachetelor transmise cu ajutorul protocolului OLSR, este:

Fig.6.13. Pachetul OLSR.

Câmpurile din antetul pachetului OLSR sunt:

Lungime pachet - lungimea în octeţi a întregului pachet, inclusiv antetul.

Număr secvenţă pachet - un număr de secvenţă incrementat cu 1 de fiecare dată când un nou
pachet OLSR este transmis de nodul sursă. Un Packet Sequence Number este memorat separat
pentru fiecare interfaţă, astfel că pachetele transmise printr-o interfaţă sunt contorizate
secvenţial.

Tip mesaj - un număr întreg care identifică tipul acestui mesaj. Tipurile de mesaje de la 0-127
sunt rezervate de OLSR, în timp ce spaţiul 128-255 este considerat privat şi poate fi folosit
pentru extensii viitoare ale protocolului.

Vtime - acest câmp indică pentru cât timp, după recepţie, un nod va decide că informaţiile
conţinute în mesaj sunt valide. Intervalul de timp este reprezentat într-un format mantisă-
exponent.

51
Dimensiune mesaj - dimensiunea acestui mesaj, inclusiv antetul mesajului (în octeţi).

Adresa nodului sursă – adresa principală a nodului sursă

Time_To_Live (TTL)- numărul maxim de hopuri admis pentru retransmiterea acestui mesaj.
Folosind acest parametru se poate controla inundarea reţelei.

Număr hop-uri - numărul de retransmisii pentru mesajul respectiv.

Număr secvenţă mesaj - un număr de ordine care este incrementat de fiecare dată când un nou
mesaj OLSR este transmis de către nodul sursă.

6.2.3.1.5. Transmiterea pachetelor de trafic OLSR

OLSR specifică un algoritm implicit de retransmitere care foloseşte informaţia OLSR

pentru difuzarea pachetelor. Există însă şi posibilitatea ca operatorii de reţea să imlementeze
reguli proprii de retransmitere a mesajelor.
Toate mesajele recepţionate care transportă un tip de mesaj necunoscut de către nodul
local, trebuie să fie retransmise în conformitate cu algoritmul implicit, care este definit astfel:
1. Dacă link-ul pe care a ajuns mesajul nu este considerat simetric, mesajul este eliminat.
Pentru a verifica starea link-ului, este interogată mulţimea Link Set.
2. În cazul în care TTL transportat în antetul mesajului este 0, mesajul este eliminat.
3. În cazul în care mesajul curent a fost deja retransmis, mesajul este eliminat. Pentru a
verifica dacă a fost deja transmis, este interogată mulţimea Duplicate Set.
4. Dacă expeditorul mesajului din ultimul hop (care nu este neapărat sursa), a ales acest
nod ca un MPR, atunci mesajul este transmis mai departe. Dacă nu, mesajul este eliminat. Pentru
a verifica acest lucru, este interogat selectorul MPR.
5. În cazul în care mesajul trebuie retransmis mai departe, TTL-ul mesajului este
decrementat cu 1 şi număratorul de hop-uri al mesajului este incrementat cu 1 înainte de
difuzarea mesajului prin toate interfeţele.

52
 Fig.6.14. Nodul A a selectat nodulurile negre ca MPR

Folosind aceeaşi topologie ca şi în figura 6.11, un posibil calcul al MPR ar putea

conduce la determinarea nodurilor negre din fig.6.12 ca MPR selectate de nodul centru. După
cum se poate vedea, în cazul în care nodul din centru vrea să difuzeze un mesaj în întreaga reţea,
se vor realiza 4 retransmisii (folosind MPR), spre deosebire de 24 folosind inundarea
tradiţională.

Forward jitter (jitter pentru retransmisie)

Pentru a evita coliziunile din cauza retransmiterii sincronizate, se introduce un jitter.
Acesta reprezintă un interval de timp mic, ales aleatoriu, în care mesajul trebuie memorat
înainte de a fi retransmis.
Când se utilizează acest mod de retransmitere, coliziunea dintre mesaje va avea totuşi loc
destul de des, deoarece mai multe mesaje care urmează să fie transmise pot ajunge în intervalul
de timp de memorare. Atunci când într-o reţea se întâmplă acest lucru, mesajele sunt memorate
într-o stivă, în cadrul aceluiaşi pachet OLSR.

Optimizarea mulţimii link-urilor

Datorită modului de selectare a MPR, numai nodurile care sunt alese ca MPR de către
unul sau mai mulţi vecini, trebuie să declare starea link-urilor lor. De fapt, aceste noduri trebuie
să declare doar MPR selectoare în mesajele de difuzare a starii link-urilor. Atunci când aceste
informaţii sunt difuzate către toate nodurile din MANET, toate nodurile vor avea destul de multe
informaţii pentru a calcula cea mai scurta cale de rutare către toate terminalele. Într-o topologie
ca în figura 6.15, numai nodurile selectate ca MPR (noduri gri) de unul sau mai mulţi vecini vor
transmite mesaje de stare. Se poate vedea că aceste informaţii, împreună cu alţi algoritmi de
detectare a vecinilor, vor fi suficiente pentru o înţelegere deplină a topologiei.

53
 Fig.6.15. Exemplu de rutare OLSR

6.2.3.1.6. Folosirea interfeţelor multiple

Nodurile implicate în rutarea OLSR pot conţine mai multe adrese IP, ceea ce înseamnă că
ele pot realiza operaţii de rutare pe mai multe interfeţe de comunicaţii, folosind identificatori
multiplii. Mesajele Multiple Interface Declaration (MID) sunt folosite pentru a difuza informaţii
despre nodurile multi-IP. Un mesaj MID este doar o listă de adrese utilizate de interfeţe prin care
se transmit mesaje OLSR. Formatul mesajului MID este afişat în figura 6.16. Datele sunt
transmise ca parte a unui mesaj OLSR, ca în figura 6.11.

Fig.6.16. Mesajul OLSR MID

La recepţionarea unui mesaj MID, nodul îşi actualizează Multiple Interface Association
Information Base, conform informaţiei transmise în mesaj. Toate interfeţele OLSR din mesajul
MID sunt înregistrate în adresa principală a nodului sursă. In momentul adaugării unei rute unui
nod, OLSR va stabili şi rutele către adresele celorlalte interfeţe.

Fig.6.17. O
sesiune tipică de
descoperire a
vecinilor folosind
mesaje HELLO

Toate nodurile
care realizează
rutari OLSR pe mai

54
mult de o singură interfaţă, vor genera mesaje MID, la intervale de timp regulate. Mesajele MID
trebuie să fie difuzate în întreaga reţea prin algoritmul implicit de retransmitere al protocolului.

6.2.3.1.7. Detectarea vecinilor

OLSR necesită un mecanism pentru a detecta vecinii şi starea link-ului. In acest scop,
mesajele Hello sunt emise la intervale regulate de timp. O versiune foarte simplificată a
procedurii de descoperire vecinilor, utilizând mesaje Hello, este prezentată în figura 6.15. Prima
dată, A trimite un mesaj Hello fără informaţii. B recepţionează acest mesaj şi memorează pe A,
ca un vecin asimetric, datorită faptului că nu poate găsi propria adresă în mesajul Hello. B trimite
apoi un mesaj Hello declarând A ca vecin asimetric. Cand A recepţionează acest mesaj, îşi
gaseşte propria adresă şi înregistrează pe B, ca vecin simetric. De data aceasta, A include B în
mesajul său Hello pe ca îl trimite şi B înregistrează A ca vecin simetric după primirea mesajului
Hello. Dar mesajele Hello sunt utilizate şi în alte scopuri. Ele sunt generate şi transmise tuturor
vecinilor de un hop pentru a realiza detectarea link-urilor, a vecinilor de două hop-uri şi a
selectorului MPR.
In mesajele Hello nodurile transmit informaţii despre toate link-urile şi toti vecinii
cunoscuţi. Sunt deasemenea declarate tipurile nodurilor vecine. Acestea includ in declaraţii
nodurile MPR selectate. Legăturile şi nodurile vecine memorate sunt grupate după tip, pentru
optimizarea folosirii memoriei. Este foarte important de observat că mesajele Hello sunt generate
pe baza adreselor interfeţelor. Aceasta datorită faptului că mesajele Hello sunt folosite pentru
detectarea link-urilor, care pot necesita utilizarea unor adrese diferite de cea principală. Formatul
mesajului Hello este prezentat în fig.6.16. Acest mesaj este inclus ca parte componentă în
mesajul OLSR. Cei 8 biţi ai codului link-ului conţin informaţii atât despre link-ul către nodul
vecin, cât şi despre tipul vecinului. Tipul legăturii descrie starea link-ului, iar tipul vecinului
descrie starea nodurilor vecine, inclusiv informaţii despre MPR. Un link poate fi considerat
asimetric, în timp ce vecinul este simetric, în cazul în care există mai multe link-uri către acest
nod vecin.

55
Fig.6.18. Mesajul OLSR Hello

56
Codul link-ului are structura prezentată în figura 6.17.

Fig.6.19. Cei 8 biţi ai câmpului Cod link

6.2.3.1.8. Detectarea link-urilor

Starea link-urilor este memorată pentru a avea informaţiile actualizate despre legăturile
existente între un nod şi vecinii săi. În mesajele Hello, un nod transmite toate informaţiile despre
link-uri către vecinii săi, prin interfaţa prin care este difuzat mesajul Hello. Atunci când se
declară link-urile, se folosesc adresele IP ale interfeţelor curente care alcătuiesc legăturile
utilizate. Atunci când declararea stării vecinilor este indisponibilă prin interfaţa pe care se
transmite mesajul Hello, este utilizată adresa principală a nodului vecin.

Fig.6.20. Detectarea link-urilor

Nodurile A şi B au interfeţe multiple. B utilizează adresa B1 ca adresa sa principală.

Nodurile D şi C au interfeţe unice (D1 şi C1).

Într-un scenariu similar celui descris în fig. 6.18, A ar trimite următoarele informaţii în
mesajul sau Hello pe interfaţa a1:

mesaj prin interfaţa a1

57
 - link-ul curent şi starea nodului vecin pentru d1

- link-ul curent şi starea nodului vecin pentru c1

- starea actuală a nodului vecin pentru adresa principală a nodului B, care este b1

Când construieşte un mesaj Hello pentru a fi transmis prin a2, nodul A va include
următoarele informaţii:

- starea curentă a nodului vecin pentru d1

- starea curentă a nodului vecin pentru c1
- link-ul curent şi starea nodului vecin pentru b2
Dupa recepţionarea unui mesaj Hello de la un vecin, un nod verifică dacă mesajul Hello
conţine adresa IP a interfeţei prin care mesajul a fost primit.
Starea link-ului este actualizată astfel:
- în cazul în care nu există înregistrari ale link-ului pentru perechea (IP a sursei, IP a
interfeţei de recepţie), atunci este creată o astfel de înregistrare. IP-ul sursei este descărcat din
antetul IP al pachetului primit. Ori de câte ori o înregistrare a link-ului este creată, va fi creată şi
o înregistrare corespunzătoare a nodului vecin, precum şi în cazul în care nu există o astfel de
înregistrare.
- un timer pentru contorizarea timpului de asimetrie (TA) este apoi actualizat în funcţie
de timpul de valabilitate primit. Acest timer decide care este intervalul de timp în care link-ul
trebuie să fie considerat asimetric, în cazul în care timpul în care a fost considerat simetric
expiră.
-dacă adresa interfeţei de la receptie se găsesşe în mesajul Hello primit, timer-ul pentru
contorizarea timpului de simetrie (TS) este actualizat şi starea link-ului este actualizată de
asemenea, dacă este necesar.
Starea înregistrărilor nodurilor vecine asociate acestui link este de asemenea actualizată,
dacă este necesar.

6.2.4. Protocoale de rutare geografice

6.2.4.1. Protocolul LAR (Location-Aided Routing)

Protocolul LAR este un protocol reactiv care utilizează coordonatele geografice pentru a
direcţiona mesajele RREQ către localizarea cunoscută a destinaţiei. Protocolul defineşte două
zone:
- zona probabilă;
- zona cerută.

58
 Zona probabilă este acea suprafaţă în care se află nodul destinaţie cu cea mai mare
probabilitate. Pentru a calcula această suprafaţă, sursa trebuie să cunoască localizarea precedentă
a destinaţiei, la momentul to şi să estimeze viteza v a nodului destinaţie la momentul to. Dacă se
notează cu t1 momentul curent, zona posibilă poate fi aproximată cu un cerc de rază v(t1-to), cu
centrul în D.
Zona cerută este acea suprafaţă în care trebuie să se transmită RREQ. Pentru a avea cea
mai mare probabilitate de a gasi nodul destinaţie, această zonă se defineşte ca fiind cel mai mic
dreptunghi care conţine atât zona probabilă, cât şi nodul sursă. Fig.6.21 ilustrează un exemplu
care cuprinde ambele zone.

Fig. 6.21. Zonele de acoperire ale protocolului LAR

In momentul în care un nod sursă cere o rută către o anumita destinaţie, va crea un mesaj
RREQ către acea destinaţie. Dacă sursa a utilizat recent o rută către acea destinaţie, va calcula
cele două zone şi va înregistra coordonatele graniţelor zonei cerute în mesajul RREQ.
Dacă nodul sursă nu are nicio informaţie apriori despre destinaţie, nu va putea calcula cele
două zone. In acest caz, algoritmul va apela procedura de inundare a reţelei cu mesaje de
descoperire a rutei.
In momentul în care un nod recepţionează un mesaj RREQ, va determina mai întâi dacă se
află în zona cerută definită în RREQ. Deoarece fiecare nod îşi cunoaşte coordonatele geografice,
poate să realizeze foarte simplu acest test. Dacă nodul nu se află în zona cerută, nu va procesa
pachetul. Altfel, dacă se află în acea zonă, îl va procesa şi îl va difuza sau va trimite RREP
(depinde dacă are sau nu o rută către destinaţie).
Dimensiunea zonei de cerere se stabilesţe ţinând seama atât de suprasarcina de trafic (să
fie cât mai mică), cât şi de probabilitatea de a gasi nodul destinaţie (sa fie cât mai mare).
In protocolul LAR a fost proiectată şi o a două metodă de determinare a zonei cerute. In
loc de a calcula o arie dreptunghiulara, sursa înregistrează în RREQ distanţa până la locaţia
anterioară a destinaţiei, împreună cu coordonatele localizării anterioare a destinaţiei. In
momentul în care nodurile vecine recepţionează RREQ, ele vor calcula distanţa lor faţă de
destinaţie (DISTi) şi o vor compara cu distanţa de la sursă la destinaţie înscrisă în RREQ
(DISTs). Pentru un parametru δ, dacă DISTs+δ≥DISTi, atunci nodul i procesează cererea. Când
nodul va trimite mai departe pachetul, va înlocui DISTs din RREQ cu DISTi. Dacă
DISTs+δ<DISTi, nodul va descărca RREQ. In practică, se consideră δ=0. Prin utilizarea acestei
metode, nodurile forţează RREQ să înainteze în reţea către locaţia estimată a destinaţiei.

59
 In ambele metode, se previne inundarea reţelei cu mesaje RREQ, deoarece transmiterea
este limitată la zonele estimate să se afle pe calea spre destinaţie.

6.2.4.2. Protocolul de rutare ZRP (Zone Routing Protocol)

Protocolul ZRP integreaza caracteristicile protocoalelor proactive cu ale celor reactive. In

jurul fiecărui nod, ZRP defineţte o zonă a cărei rază se măsoară în număr de hop-uri. Fiecare nod
utilizează rutarea proactivă în interiorul acestei zone şi pe cea reactivă în afara ei. Astfel, un nod
are definite rutele către toate nodurile din interiorul zonei sale. Când un nod trebuie să transmită
pachete de date către o anumita destinaţie, va verifica existenţa unei rute în tabela sa de rutare.
Dacă nodul destinaţie se afla în interiorul zonei, se va gasi ruta în tabela de rutare, altfel se va
începe o procedura de descoperire a rutei. Fig. 6.28 ilustrează conceptul zonal. Raza zonei este în
acest caz egală cu 2 hop-uri.
Pentru rutarea intrazonala, ZRP defineşte protocolul IARP (Intrazone Routing Protocol).
IARP este un protocol la nivel de link, care menţine informaţiile actualizate pentru toate nodurile
din zonă. Pentru un nod dat X, se definesc nodurile periferice ale lui X, ca fiind acele noduri
pentru care distanţa minimă faţă de X este egală cu raza zonei. In fig.6.28 nodurile periferice ale
lui S sunt A, B, C şi D. Aceste noduri au un rol important în descoperirea reactivă a rutelor.
ZRP utilizează protocolul IERP (Interzone Routing Protocol) pentru gasirea rutelor în
afara zonei specificate. Pentru descoperirea rutei se defineşte noţiunea de bordercasting (difuzare
la nivelul graniţei). Odată ce nodul sursă a determinat că destinaţia nu se află în zona sa, el va
difuza prin bordercast un mesaj de căutare către nodurile sale periferice. Acest mesaj va fi
distribuit către nodurile periferice utilizând arborii construiţi în topologia intrazonală. Dupa
recepţionarea mesajului, nodurile periferice vor verifica dacă destinaţia se află în zona lor. Dacă
destinaţia nu se află în acea zonă, ele vor difuza mesajul de căutare către nodurile lor periferice.
Procesul continuă până când destinaţia este descoperită sau până când întreaga reţea este
cercetată.

Fig. 6.22. Raza zonei ZRP

60
 Fig.6.22 ilustrează o astfel de procedură. Nodul S iniţiază procedura de căutare a
destinaţiei X. Utilizând IARP, determină că X nu se află în interiorul zonei. Astfel, va difuza
mesajul, prin bordercast, către nodurile sale periferice. In figură, cercul punctat reprezintă zona
nodului S. Nodurile periferice verifică la rândul lor propriile lor zone şi dacă nu găsesc
destinaţia, difuzează mesajul către nodurile periferice. Se observă că nodul G descoperă X în
interiorul zonei sale, şi va trimite RREP către nodul S.
Pentru a îmbunătăţi eficienţa procedurii de căutare, va fi utilizat un algoritm de procesare
cu o întârziere aleatoare a cererilor. Prin aşteptarea unui interval aleator între recepţia cererii şi
transmiterea ei mai departe, se reduce numărul coliziunilor şi deci se îmbunătăţesc performanţele
protocolului. In ZRP sunt definite şi alte optimizări pentru reducerea suprasarcinii de trafic. De
exemplu, se utilizează întreruperea transmiterii cererilor de căutare pentru zonele în care s-a mai
realizat căutarea aceleiaşi destinaţii.
A fost creată şi o nouă variantă a lui ZRP, ZRPv2, care diferă faţă de protocolul original
prin modul în care se realizează procedura de bordercasting. In ambele versiuni descoperirea
rutei este iniţiată de cererea nodului sursă, după care urmează construirea arborilor către nodurile
sale periferice neacoperite. Un nod neacoperit este acela care nu aparţine zonei de rutare a unui
nod care deja a recepţionat o cerere. Când aceşti vecini recepţionează cererea, vor construi arbori
către propiile lor noduri periferice (nu ale sursei ca în varianta originală) şi vor transmite mesajul
către arborii lor vecini, prin bordercast. Procedura continuă până când destinaţia e gasită sau este
descoperit un nod cu o rută actualizată către destinaţie. In acest moment se trimite un mesaj
unicast RREP.
ZRP este un protocol simplu, datorită modului hop-by-hop de implementare. Deasemenea,
se elimină necesitatea existenţei unei zone extinse de căutare a rutei.

Fig. 6.23.Exemplu de descoperire a rutei în ZRP

61
 7. MANAGEMENTUL MOBILITĂŢII IN REŢELELE
WIRELESS ATM

Managementul mobilităţii pentru reţelele WATM (Wireless Asynchronous Transfer Mode)

tratează un domeniu extins, de la mobilitatea bazată pe resurse disponibile pe scară largă, la cea
bazata pe resurse limitate şi relativ nesigure pe canalul wireless. De aceea, este necesară
investigarea unor aspecte importante precum întârzierea livrării mesajelor, rutarea şi calitatea
serviciilor (Quality-of-Services — QoS).

7.1 Managementul localizării

După cum se arată în figura 7.1, protocoalele propuse pentru WATM realizează
managementul localizării utilizând trei tehnici: servere de localizare, anunţarea localizării, şi
paging-ul terminalelor.
Serverele de localizare se referă la utilizarea bazelor de date pentru a memora punctele de
conectare ale MT-urilor la reţea. Procesele de memorare şi de căutare a MT pot genera o
suprasarcină de trafic datorită semnalizărilor şi operaţiilor de interogare.
Anunţarea localizăriii evită utilizarea bazelor de date prin transmiterea informaţiei de
localizare în reţea prin intermediul unor mesaje de difuzare.
Paging-ul terminalelor este utilizat pentru a localiza MT-urile din zona de acoperire.

62
 Fig.7.1. Managementul localizării în WATM

7.1.1 Utilizarea serverelor de localizare

După cum s-a menţionat anterior, serverele de localizare sunt baze de date folosite pentru
stocarea şi căutarea unei înregistrări a poziţiei actuale a mobilului. Ele necesită operaţii de
interogare, precum şi protocoale de semnalizare pentru memorare şi căutare. Aceste protocoale
utilizează standardele IS-41/GSM MAP.

Baze de date pe două niveluri

Această arhitectura utilizează baze de date bi-nivel care sunt distribuite în întreaga reţea
(fig. 7.2.). Zonele — similare RA-urilor din PLMN — sunt controlate de un manager de zonă.
Acesta — similar Mobility Service Control Point — MSCP din reţelele wireless — controlează
procedurile de actualizare a localizării în zona respectivă. Nivelul de bază (HLR) al bazei de date
corespunzătoare zonei, stochează informaţiile de localizare a MT-urilor care sunt
înregistrate permanent în acea zonă, în timp ce nivelul secund (VLR) memorează informaţia
privind localizarea MT-urilor care vizitează zona de bază (o zonă în care este înregistrat în
permanenţă).
Procesul de actualizare a localizării este acelaşi ca şi în cazul reţelelor PLMN , cu
excepţia faptului că un VLR nu aparţine mai multor RA-uri. Un VLR trebuie să fie dedicat fiecărei
zone şi să înregistreze doar MT-urilor din zona respectivă. La intrarea într-o zonă nouă, MT-ul

63
detectează identitatea acesteia, difuzată de BS-uri. Înregistrarea se desfaşoară în următoarele
etape:

1). MT-ul transmite o cerere de înregistrare noului MSCP, conţinând numărul de

identificare a utilizatorului (UID), date de autentificare şi identitatea zonei precedente.

2). MSCP-ul curent determină zona de bază a MT-ului, din identitatea zonei precedente.

3). MSCP-ul curent şi cel de bază, autentifică utilizatorul şi

îi actualizează profilul de bază cu informaţii despre noua localizare.

4). Zona de bază trimite către zona curentă o copie a profilului; aceasta memorează
profilul abonatului în nivelul VLR al bazei sale de date.

5). MSCP-ul curent trimite un mesaj către zona precedentă şi astfel profilul utilizatorului
este şters din VLR-ul acesteia.

Fig.7.2. Baze de date pe două niveluri

Livrarea apelului este realizată prin rutarea (dirijarea) apelului către ultima zonă
cunoscută. Dacă MT-ul s-a deplasat şi a fost eliminat, apelul este redirecţionat imediat către zona
de bază. HLR-ul zonei de bază este interogat despre actualizarea actuala a MT-ului, care este
expediată apoi către centrul de comutaţie. Acesta are posibilitatea să stabilească ulterior o
conexiune către centrul de comutaţie curent al MT-ului.
Avantajul utilizării bazelor de date cu două niveluri este acela că se utilizează un număr
mic de interogări — necesită cel mult două căutări ale MT-ului chemat în bazele de date (pentru
fiecare apel de intrare). Totuşi, utilizarea unui HLR centralizat poate cauza creşterea traficului de

64
semnalizare şi întârzieri datorită stabilirii unor conexiuni inutile dacă MT-ul realizează mai multe
deplasări localizate într-un interval de timp mai mare.

Ierarhia registrelor de localizare

Schema registrelor de localizare distribuie serverele prin întreaga arhitectură ierarhică

PNNI (Private Network-to-Network Interface), aşa cum se poate observa în figura 7.3. Procedura
PNNI este bazată pe o ierarhie de perechi de grupuri, fiecare grup fiind alcătuit dintr-o mulţime
de comutatoare ATM. Fiecare comutator se poate conecta la un alt comutator în cadrul grupului
din care face parte. Comutatoarele speciale, destinate ca leader de grup pot, de asemenea, să se
conecteze la un leader de rang mai mare în grupul părinte. Fiecare grup are propria bază de date,
sau registrul de locaţie (Location Register — LR), folosit pentru a memora informaţiile de
localizare pe fiecare dintre MT-urile alocate.
Organizarea PNNI permite reţelei să realizeze rutarea către MT fără să ceară nodurilor
părinte informaţii exacte despre localizare. Doar grupul de pe nivelul cel mai de jos trebuie să
înregistreze locaţia exactă, şi numărul actualizarilor LR-ului, făcând apoi corespondenţa cu
nivelul de mobilitate al MT-ului. De exemplu, un apel care este iniţiat către un MT localizat în
zona comutatorului A.2.2 din fig.7.3 este prima data dirijat către limita superioară a grupului şi
către comutatorul A. Grupul A poate, apoi să dirijeze apelul către fiul său, de pe nivelul A.x,
către comutatorul A.2. În cele din urmă, apelul este dirijat de A.2 către nivelul cel mai de jos,
către comutatorul A.2.2, care realizează conexiunea la MT.
Astfel, pentru deplasarea în interiorul grupului A.2, procedura de actualizare a localizării
este apelată doar la LR-ul acelui grup. Totuşi, o deplasare de la grupul B.1 la grupul A.2 necesită
înregistrarea localizării unei zone mai mari şi menţinerea LR-ului de adrese (home LR) pentru a
memora un pointer către poziţia actuală a părintelui asociat MT-ului. Pentru a limita traficul de
semnalizare pentru deplasările pe scară largă, la nivelul minim necesar, au fost implementaţi doi
parametri care limitează domeniul de aplicare, S şi L. Parametrul S indică un grup de pe un nivel
mai înalt pentru limitarea înregistrărilor LR, în timp ce parametrul L indică grupul inferior. În
fig.7.3, nivelul S curent este nivelul 1, iar nivelul L este nivelul 2.

65
 Fig. 7.3. Schema LR-urilor pentru reţeua WATM

Când MT-ul efectuează actualizarile localizării prin trimiterea unui mesaj de notificare a
înregistrării către noua BS, acest mesaj este retransmis către comutator. Acesta stochează
informaţia de localizare a MT-ului în LR-ul grupului. Când MT-ul porneşte sau se opreşte
(powers on or off), acest mesaj este retransmis către nivelurile superioare ale ierarhiei până când
ajunge la limita pre-setată, S. Registrul de pe nivelul S înregistrează localizarea şi apoi
retransmite mesajul către LR-ul de bază al MT-ului. Pentru deplasarea din poziţia B.1.2 în poziţia
A.2.2, procedura de înregistrare este următoarea:
1). MT-ul transmite un mesaj de notificare a înregistrării către noua BS/ noul comutator.
2). Noul comutator memorează MT-ul în LR-ul grupului.
3).Grupul retransmite informaţia de localizare către LR-urile de pe nivelurile
superioare, până când întâlneşte primul predecesor comun al grupului anterior şi al celui curent.
4). În exemplul prezentat, nivelul anterior S nu este un predecesor comun, astfel încât un
nou nivel S este indicat şi informaţia despre localizare este transmisă către noul nivel S, nivelul 0.
5). LR-ul de baza al MT-ului — stabilit la grupul A.x — este notificat ca fiind noul nivel
S pentru MT-ul respectiv.
După ce actualizările sunt complete, noul comutator trimite un mesaj de verificare către
comutatorul anterior, astfel încât fosta locaţie să poată fi ştearsă din LR-uri.
Livrarea apelului este mai puţin complicată pentru această metodă, datorită organizării
ierarhice. Un apel de intrare poate fi rutat către ultimul grup sau comutator cunoscut, prin LR-ul
nivelului S. Dacă mobilul s-a deplasat, ultimul comutator cunoscut transmite o cerere de
localizare interogând LR-urile de pe nivelurile superioare până când adresa finală a mobilului
este recunoscută de LR-ul în care este memorat un pointer către poziţia curentă a mobilului.

66
Apoi cererea este trimisă către LR-ul nivelului L al acelui grup, care transmite informaţia despre
localizare înapoi la comutatorul chemător.
În final, dacă cererea ajunge la nivelul S înainte să fie recunoscută de un LR, LR-ul
nivelului S expediază direct cererea de localizare către comutatorul de bază. Deoarece LR-ul de
bază urmăreşte deplasările mobilului pe nivelul S, comutatorul de bază poate retransmite direct
cererea de localizare către comutatorul corespunzător de pe nivelul S, ale cărui LR-uri
memorează pointerii către poziţia curentă a grupului asociat MT-ului.

7.1.2. Anunţarea localizării

Deşi metoda servere-lor de localizare prezintă avantajul simplităţii, al flexibilităţii şi al

costurilor scăzute, este încă necsar un trafic important de semnalizare şi interogare a bazelor de
date. Această suprasarcină de trafic poate fi redusă prin utilizarea anunţării localizării (Location
Advertisement). Pentru WATM, această se referă la informarea nodurilor reţelei despre locaţia
curentă a MT-ului.
Prima metodă, Mobile PNNI, utilizează arhitectura PNNI descrisă anterior prin eliminarea
LR-urilor şi beneficiază de avantajul unui mecanism de difuzare internă.
A două metodă, destinaţia fixă cu arbori de conexiune virtuală (Destination Rooted
Virtual Connection Trees), anunţă informaţia despre locaţie prin intermediul căilor virtuale.
Cea de-a treia metodă, decizia localizării integrate (Integrated Location Resolution)
extinde semnalizările din reţeaua ATM, cu informaţii despre localizare care se referă la
determinarea precisă a localizării în procesul de stabilire a conexiunii.

7.1.2.1.Mobile PNNI
Schema utilizează proceduri de notificare a reţelei PNNI pentru realizarea înregistrării în
mod automat, pentru urmărire şi localizare. Protocolul PNNI solicită schimbul pachetelor despre
starea topologiei PNNI (PNNI Topology State Packets — PTSPs) între comutatoarele ATM din
acelaşi grup, între leader-ul unui grup şi grupurile de pe nivelurile superioare şi inferioare.
PTSPs este generată de leader-i de grup şi conţine informaţii despre topologia grupului şi traficul
dintre perechile de comutatoare. În plus, această topologie conţine informaţii despre
accesibilitate (adresă şi informaţii despre grupul părinte).
Procedura de înregistrare este realizată fără a utiliza baze de date, deoarece informaţia
despre localizare se află în aceste pachete PTSP. În schimb, unui mobil îi este alocat un
comutator de bază care stabileşte ruta către comutatorul curent al respectivului mobil. Tabela de
rutare este actualizată ori de câte ori mobilul este pornit/oprit sau când se deplasează către un
nou comutator. In plus, comutatorul de bază este responsabil pentru anunţarea noii locaţii a
mobilului, prin actualizarea informaţiilor despre accesibilitate în pachetele PTSP.
Procedurile de înregistrare şi de actualizare sunt prezentate în fig.7.4:
1). Mobilul trimite un mesaj de înregistrare către comutatorul de bază.
2). Comutatorul de bază şi actualul leader de grup transmit noua informaţie despre
localizare în pachetele PTSP.

67
 Fig, 7.4. Mobile PNNI extins

Comutatorul de bază trebuie să trimită un mesaj către comutatorul precedent pentru a

începe expedierea pachetelor. Odată ce informaţia despre accesibilitate a avut timp să se
propage, comutatorul anterior este înştiinţat să oprească expedierea pachetelor.
Deoarece în reţelele PNNI se identifică doar grupurile perechi de tipul părinte al
terminalelor, există şi un algoritm extins pentru Mobile PNNI care include o schemă pentru
difuzarea localizării exacte a mobilului în reţea, dar doar pentru un singur nivel.
Dacă un MT se deplasează către un comutator nou în aceeaşi zonă cu a comutatorului său
de bază, locaţia exactă este trimisă la comutatorul de bază, fără a fi necesar un trafic suplimentar
de semnalizare. Comutatoarele aflate în afara zonei recepţionează doar informaţia referitoare la
grupul părinte al terminalului, şi pot folosi această informaţie pentru a dirija apelurile în
conformitate cu metoda Location Registers Scheme. Până când informaţiile de actualizare se
propagă în întreaga vecinătate, mobilul trebuie să trimită comutatorului anterior informaţia
despre noua localizare, astfel încat conexiunile sale să poate fi transmise mai departe.
Dacă un MT se deplasează către un comutator nou care nu se află în zona sa de bază,
mobilul trebuie să îşi înregistreze noua locaţie în comutatorul de bază, pentru memorare şi
actualizare.
Stadiul livrării apelului pentru Mobile PNNI extins nu necesită setări apriori ale
conexiunii. Un apel din aceeaşi vecinătate poate fi dirijat imediat către comutatorul corect,
asigurat de ultimele actualizări.

7.1.2.2. Destination Rooted Virtual Connection Tree

Această arhitectura este prezentată în fig. 7.5, fiind constituită dintr-o mulţime a staţiilor
de baza portabile (PBSs) conectate prin căi virtuale ce alcatuiesc un arbore de conexiune. PBS-

68
urile au posibilităţi de comutare şi memorare limitate. Arborii se bazează pe indicaţiile de
mobilitate oferite de MT. Fiecare PBS memorează o listă a deplasărilor MT din zona sa de
acoperire.
Procesul de înregistrare, prezentat în figura. 7.5, începe în cazul de pornire/oprire, sau
când MT-ul se deplasează într-o noua zonă. Când MT-ul este pornit sau oprit, el trimite un mesaj
către PBS-ul său curent. PBS adaugă sau şterge MT-ul din lista sa. Totuşi, când MT-ul se
deplasează în zona unei noi PBS, noua PBS trebuie să trimită un mesaj de ştergere a înregistrării
MT-ului, către vechea PBS şi apoi să introducă în lista sa curentă informaţia referitoare la
identitatea MT-ului.
Livrarea apelului constă în anunţarea identităţii MT-ului prin difuzarea unui mesaj de la
PBS-ul terminalului chemător. Nu este necesar nici un fel de semnal de paging la nivelul
interfeţei-aer. PBS-ul local răspunde şi iniţiază procedurile de conectare. Dacă nu există nici un
răspuns, conexiunea este respinsă pe baza presupunerii că MT-ul nu este înregistrat. Pentru
comunicaţia mobil-fix, PBS-ul se comportă ca un comutator care are o tabelă de rutare pentru
terminalele fixe.

PBS

Celula de graniţă

Mesaj de
înregistrare

Poziţia anterioara
a MT-ului
MT
Înregistrarea
mesajului

Fig.7.5. Destination Rooted Virtual Connection Tree

7.1.2.3. Decizia localizării integrate (Integrated Location Resolution)

Schema integrată modifică operaţiile de semnalizare în procesul de stabilire a apelului

ATM, pentru a include indicaţii despre locaţia curentă a terminalelor chemate. În această schemă,
MT-ului îi este alocat un comutator de bază care controloează toate informaţiile despre poziţia
actuală a mobilului in reţea. Când MT-ul se deplasează din zona acoperită de comutatorul de
bază, trebuie să-şi înregistreze, mai întâi, localizarea în noul comutator. Apoi, acest comutator
trebuie să informeze comutatorul de baza al MT-ului în legătură cu noua adresă. Astfel, operaţia

69
de actualizare a localizării este alcătuită dintr-o serie de actualizări transmise până la comutatorul
de bază al MT-ului.
In etapa de livrare a apelurilor, toate cererile de apel iniţiale sunt dirijate imediat către
comutatorul de bază al MT-ului printr-un mesaj de SETUP a conexiunii. Deoarece schema
presupune că se utilizează drept comutator de bază pentru fiecare MT, un comutator ME-ATM
(un comutator care asigură protocoale pentru funcţiile de comutare şi semnalizare pentru
conexiunile ATM, împreună cu managementul mobilităţii şi al localizării; aceste funcţii pot fi
implementate în servere care se află fizic la depărtare, dar conexiunea logică are loc în ME-
ATM), mesajul de SETUP poate include un flag care indică faptul că pe rută se află un comutator
ME-ATM. Totuşi, deoarece terminalul chemător nu ştie dacă apelatul este mobil sau nu, pot
exista oricare din următoarele condiţii:
1). Terminalul chemat este static, sau un terminal fix care este în permanenţă conectat la
comutatorul său de bază.
2). Terminalul apelat este mobil, dar la momentul curent este conectat la comutatorul său
de bază.
3). Terminalul apelat este mobil, dar la momentul curent este în afara zonei acoperită de
comutatorul său de bază.
La frontiera NNI/UNI (Network-to-Network Interface/User-to-Network Inteface) a
terminalului chemat, comutatorul de origine trebuie să determine starea curentă a terminalului.
Dacă terminalul chemat este fix, comutatorul de bază trimite un mesaj de conexiune
(CONNECT) către comutatorul care a iniţiat conexiunea. Dacă terminalul chemat este un mobil
ataşat la comutatorul său de origine, acesta trimite un mesaj CONNECT către comutatorul care a
iniţiat conexiunea şi care identifică de asemenea, conexiunea ca fiind mobilă pentru oricare dintr
comutatoarele intermediare. Acest lucru permite oricărui comutator ME-ATM de pe rută să fie
pregătit pentru posibilele handoff’-uri.

Fig. 7.6. Integrated Location Resolution

70
 Schema de livrare a apelurilor pentru un MT care este în momentul curent, în afara zonei
acoperite de comutatorul său de baza, este prezentată în fig. 7.6.
1). Terminalul chemător trimite un mesaj de SETUP a conexiunii către comutatorul de
bază al MT-ului.
2). Comutatorul de bază determină faptul că terminalul este în afara zonei de origine.
3). Comutatorul de bază al MT-ului trimite un mesaj de RELEASE comutatorului care a
iniţiat conexiunea. Acest mesaj trebuie să indice adresa curentă, de deplasare a MT-ului şi, de
asemenea, să identifice conexiunea ca fiind mobilă.
4). Un comutator (A) de pe calea de SETUP stabileşte o nouă cale pentru conexiunea la
MT şi trimite un nou mesaj de SETUP către adresa de deplasare a MT-ului. Acest nou mesaj
trebuie să includă adresa de bază a MT-ului.
5). Îmbunătăţirea comutatoarelor cu noi tehnici de asigurare a mobilităţii pe această nouă
cale poate asigura realizarea viitoarelor handoff-uri.

7.1.3. Paging-ul terminalelor

Viteza de paging clasifică deplasarea MT-urilor în clase de viteză. Clasa este apoi
utilizată pentru a genera o zonă de paging — o listă a celulelor care urmează sa fie apelate.
Clasele de viteză pot fi obţinute în două moduri.
In primul caz se utilizează o înregistrare pe baza distanţei, în care MT-ul se înregistrează
ori de câte ori distanţa de la ultima celulă înregistrată depăseşte o valoare de prag. Clasa de
viteză poate fi formată apoi prin utilizarea acestei valori de prag divizată cu timpul dintre două
acţiuni de înregistrare consecutive. Apoi este determinată viteza medie pentru MT.
Cealaltă metodă de a găsi clasa de viteză a unui mobil este de a valorifica rezultatele
procedurii de înregistrare a deplasărilor. Această procedură contorizează numărul de traversari
ale celulei de către MT. Odată depăşita valoarea de prag pentru acest contor, MT-ul trebuie
înregistrat. Numărul deplasărilor divizat cu timpul dintre două înregistrări şi multiplicat cu o
unitate de timp pentru viteză (Velocity Time Unit) va determina clasa de viteza.
Când sistemul doreşte să iniţieze un apel către un MT aflat in standby, sistemul trebuie să
interogheze un server al localizării. Server-ul oferă profilul deplasărilor MT-ului, pe baza
opţiunilor prezentate anterior: indexul clasei de viteză a MT-ului, ultima locaţie cunoscută a
acestuia, şi ultimul timp de înregistrare. Apoi, sistemul utilizează aceste informaţii pentru a
calcula distanţa maximă pe care MT-ul ar fi putut să o parcurgă în condiţiile acestor constrângeri.
În final, posibilele celule care se găsesc în limita distanţei maxime reprezintă primul grup care va
fi supus procesului de paging.

7.2. Managementul handoff-urilor

Managementul handoff-ului controlează procesul de menţinere a fiecărei conexiuni la un

anumit nivel al QoS-ului odată cu deplasările MT-ului în zone cu diferite QoS. După cum se
prezintă în fig.7.7, protocoalele de management al handoff-urilor pot fi grupate în patru categorii:
- redirijare cu stabilirea unei conexiuni complete (Full Connection Re-routing- FCRR);
- extinderea rutei (Route Augmentation-RA);

71
- redirijare cu stabilirea unei conexiuni parţiale (Partial Connection Re-routing-PCRR);
- redirijare cu stabilirea unei conexiuni multicast (Multicast Connection Re-routing-
MCRR).
Redirijarea cu stabilirea unei conexiuni complete (Full Connection Re-routing) menţine
conexiunea prin stabilirea unei rute complet noi pentru fiecare handoff— ca şi cum ar fi un apel
nou. Extinderea rutei (Route Augmentation) extinde conexiunea originală printr-un hop la
următoarea locaţie a MT-ului. Redirijarea cu stabilirea unei conexiuni parţiale (Partial
Connection Re-routing) restabileşte anumite segmente ale conexiunii originale, păstrând restul.
În cele din urmă, redirijarea cu stabilirea unei conexiuni multicast (Multicast Connection Re-
routing) combină cele trei tehnici precedente, dar include menţinerea unor conexiuni pentru
posibile handoff-uri, pentru a asigura conexiunea originală şi a reduce astfel timpul de detectare a
unei noi rute.

Fig. 7.7. Managementul handoff-urilor în reţelele WATM

7.2.1. Redirijarea cu stabilirea unei conexiuni complete (Full

Connection Re-routing)

Această metodă este cea mai bună şi cea mai simplă tehnică de redirijare, întrucât toate
VC (Virtual Circuits)-urile de pe calea de conexiune de la sursă la comutatorul anterior sunt
libere. Apoi, noile VC-uri sunt stabilite de la sursă către noul comutator; ele pot fi implementate
prin tratarea conexiunii ca un apel nou primit, sau prin folosirea elementelor de reţea care
realizează funcţiile de mobilitate pentru acea conexiune, independent de comutatoare.

72
 Redirijarea cu stabilirea unei conexiuni complete prin intermediul dispozitivelor de
interconectare

Algoritmul redirijării cu stabilirea unei conexiuni complete prin intermediul

dispozitivelor de interconectare (InterWorking Devices — IWDs), controlează handoff-urile prin
utilizarea procesoarelor externe care separă unitaţile de management al mobilităţii de reţeaua
fixă. Câteva dintre IWD.uri sunt plasate în reţeaua fixă — un dispozitiv IWD corespunde fiecărui
comutator aşa cum se arată în fig.7.8a. Comutatoarele controlează mai multe BS-uri şi asigură
conexiunea la reţeaua fixă. O conexiune care se extinde de la terminalul de origine la
comutatorul său local, este dirijată în reţea şi se încheie la terminalul mobil prin comutatorul
acestuia, dar toate handoff-urile sunt realizate prin IWD-uri.
Procedurile pentru redirijarea cu stabilirea unei conexiuni complete sunt prezentate în fig.
7.8a şi b.
1). După înregistrare, MT-ul informează comutatorul destinaţie despre identitatea
conexiunii de origine, incluzând un identificator unic pentru acea conexiune şi NSAP (Network
Service Access Point adress)-ul vechiului IWD.
2). Apoi, comutatorul destinaţie trimite către IWD-ul său, mesajul de cerere a handoff-
ului.
3). IWD-ul de destinaţie trimite mai departe cererea către IWD-ul precedent. Acest mesaj
este trimis prin intermediul identificatorilor IWD şi prin ID-ul conexiunii.
4). IWD-ul chemător şi IWD-ul destinaţie determină o nouă conexiune către MT.
5). Pentru a elibera calea originală, IWD-ul chemător trimite un mesaj de eliberare mai
departe pe vechea rută, către vechiul comutator.

7.2.2. Extinderea rutei (Route Augmentation)

Extinderea rutei nu duce la obţinerea unei rute optime, dar asigură un nivel de simplitate
şi rapiditate care poate reduce întârzierile din procesul de handoff şi costurile semnalizărilor.

73
 IWD
chemator

Switch
chemator

Nod chemator
4j3j
5j

IWD IWD
destinatie 3j anterior
MT 4j
BS (2)
Switch Switch 5j
destinatie anterior

(1)

(2)

Nod destinatie
Nod anterior

BS MT

(a)

74
 Fig.7.8. Algoritmul redirijării cu stabilirea unei conexiuni complete prin intermediul
dispozitivelor de interconectare
(a) Arhitectura sistemului(b) Fluxul semnalelor de redirijare a conexiunii (c) Fluxul semnalelor
pentru conexiunea extinsă.

Extinderea rutei prin intermediul dispozitivelor de interconectare

În acest caz, conexiunea MT-ului care se extinde de la terminalul de origine până la

comutatorul său local, este dirijată în reţea şi se incheie la teminalul mobil prin comutatorul
asociat mobilului. Procesul de handoff utilizează IWD-urile locale care să dirijeze conexiunea.
Descrierea procedurii de handoff corespunzătoare arhitecturii IWD-urilor şi fluxulului de
semnale, prezentată în fig.7.8a şi c este următoarea:
1). Din nou, MT-ul informează comutatorul destinaţie despre conexiunea de origine,
incluzând un identificator unic pentru conexiune şi NSAP-ul precedentului IWD. Acesta
identifică IWD-ul precedent ca IWD local.
2). Comutatorul destinaţie trimite mesajul de cerere de handoff către IWD-ul său.
3). IWD-ul destinaţie trimite o cerere redirecţionată către IWD-ul precedent.
4). IWD-ul precedent răspunde prin continuarea conexiunii VC-ului la IWD-ul destinaţie.
IWD-ul destinaţie poate notifica comutatorul să seteze o nouă conexiune către MT.
5). În final, comutatorul precedent eliberează conexiunile precedente către MT.
Tehnicile de redirijare cu stabilirea unei conexiuni complete stabilesc o rută optimă, cu
dezavantajul creşterii costurilor de semnalizare şi ale managementului resurselor. Tehnica de
extindere a rutei simplifică procesul, dar poate deveni foarte ineficientă dacă rutarea începe sa
creeze bucle.

75
 7.2.3. Redirijarea cu stabilirea parţială a conexiunii (Partial Connexion
Re-routing)

Prin această tehnică se încearcă să se dirijeze conexiunea într-un mod mai eficient, prin
păstrarea unor porţiuni din ruta originală, pentru managementul resurselor şi simplitate şi
redirijarea altor porţiuni, pentru un rezultat optim.

Algoritmul celui mai apropiat nod comun

Acest algoritm (Nearest Common Node Re-routing — NCNR) dirijează conxiunile

conform cu RA. Handoff-ul din interiorul RA-ului constituie o actualizare a tabelei VC. Pentru
handoff-ul dintre zone, algoritmul încearcă să stabilească o conexiune către cel mai apropiat nod
al reţelei WATM care este comun ambelor zone implicate în procesul de handoff. În topologia de
tip arbore, punctul comun este punctul din care pornesc două ramuri. Într-o ierarhie, punctul
comun al celor două zone este nodul de pe un nivel superior care foloseşte căi diferite pentru a
accesa fiecare zonă.
Procesul de handoff de la zona A la zona B începe la MSCP-ul zonei A care caută un link
direct între cele două RA-uri. Dacă fiecare zonă este un părinte pentru o alta, zona părinte
funcţionează ca o zonă locală pentru procesul de handoff. Ambele zone, A şi B participă la
conexiunea către MT, până când link-ul radio completează transferul. Apoi, dacă A este
părintele, A devine un comutator ATM pentru calea de conexiune. Dacă B este părintele, B
şterge A de pe calea de conexiune.
Dacă A şi B nu sunt direct legate, handoff-ul, ilustrat în fig.7.9 are următoarele etape:
1). MSCP-ul MT–ului transmite un mesaj de start pentru procesul de handoff către
terminalul chemător. Acest mesaj include adresele ATM ale MT-ului, comutatorului de
destinaţie, şi comutatorului anterior.
2). Fiecare comutator de pe această cale foloseşte adresa ATM pentru a determina dacă
este NCN (Nearest Common Node) (NCN-ul va avea 3 porturi de ieşire pentru 3 adrese).
3). Deoarece se repetă pasul anterior până când este determinat NCN-ul, comutatorul care
se recunoaşte ca fiind NCN opreşte scest proces prin setarea bitului NCN în mesajul de start al
handoff-ului.
4). NCN-ul iniţiază conexiunea către zona de destinaţie prin trimiterea unui mesaj de
redirijare către comutatoarele de pe acea rută.
Zona de destinaţie primeşte mesajul de redirijare şi transmite un mesaj de confirmare
către zona anterioară, încheind astfel procesul de redirijare. NCN-ul trimite datele de conexiune
către ambele zone, A şi B, până când procesul de handoff este complet. Ulterior, NCN-ul şterge
conexiunea la A.

76
 Fig. 7.9. Algoritmul NCN

Algoritmul conexiunii hibride

Algoritmul conexiunii hibride începe cu deplasarea MT-ului într-o regiune de
suprapunere a zonelor de acoperire, în care se primesc semnale de la noua BS. BS-ul destinaţie
trebuie să determine dacă handoff-ul este intra-cluster sau inter-cluster. Un cluster reprezintă o
mulţime de BS-uri conectate la un cluster comutator comun. Dacă handoff-ul este intra-cluster,
comutatorul poate funcţiona ca un “switch cross over” (COS)-realizează o comutatţie
încrucişată. În caz contrar, trebuie iniţiat un proces de descoperire a COS-ului. Această procedură
este arătată în fig.7.10:
1). MT-ul trimite la BS vechi, un mesaj de atenţionare asupra unui posibil handoff.
2). BS precedent trimite la BS destinaţie un mesaj de iniţiere a handoff-ului (conţinând
lista de conexiuni a MT-ului).
3). Switch-ul cross over(COS) este determinat.
4). Sunt setate rute parţiale de la COS la BS destinaţie.

77
 Fig.7.10. Procedura de redirijare a conexiunii hibride

Când MT-ul părăseşte regiunea de suprapunere şi intră complet în noua regiune, noua
cale este stabilită. MT-ul poate trimite un mesaj prin care să-şi anunte prezenţa la BS şi BS poate
trimite o redirecţionare către COS, pentru a deveni o parte din noua rută. În final, COS anunţă
vechea BS să deconecteze vechile rute parţiale. Pentru procesul de handoff, datorat deteriorării
link-ului, câteva celule se vor pierde până când MT-ul detectează defecţiunea. Apoi, procesul de
memorare în cazul MT şi COS este folosit pentru recâştigarea conexiunii corespunzătoare pentru
handoff.
Redirijarea cu stabilirea unei conexiuni parţiale oferă o utilizare mai bună a resurselor,
prin reducerea semnalizărilor, dar necesită algoritmi pentru transportul datelor, pentru procesul
de memorare şi pentru secvenţierea celulelor. De asemenea, necesită evaluarea NCN-ului/COS-
ului.

Redirijarea cu stabilirea unei conexiuni multicast

Această metodă combină ideile discutate anterior într-un mod hibrid, dar introduce, de
asemenea, ideea menţinerii conexiunilor pentru un potenţial handoff, pe lângă cele originale.
Astfel, timpul pentru selectarea unei rute se micşorează, deoarece sunt deja mai multe
disponibile.

78
Algoritmul care utilizează arbori de conexiune virtuală

Această metodă se bazează pe o structură ierarhică a nodurilor de comutaţie ataşate

reţelei fixe, prin link-uri extinse către BS-uri. Rădăcina arborelui este un nod fix de comutare
conectat la structura reţelei, în timp ce nodurile frunză sunt chiar BS-urile. Fiecărei conexiuni
mobile îi este alocat un set de numere ale conexiunilor viruale (Virtual Connection Numbers —
VCNs) care sunt utilizate pentru identificarea unui set de cai de la rădăcină la una dintre
“frunze”. Doar o singură rută este operaţională la un moment dat. Apoi apelul se stabileşte de la
MT-ul ataşat nodului frunză, prin rădăcina arborelui, către reţeaua fixă sau către rădăcina unui alt
arbore de conexiuni.
Este analizat procesul de handoff pentru două cazuri:
- handoff în cadrul aceluiaşi arbore (fig.7.11) şi
- handoff între arbori.
1). MT-ul transmite celule cu un nou VCN, corespunzătoare rutei stabilite anterior pentru
BS de destinaţie.
2). BS de destinaţie activează ruta VCN prin utilizarea lui în transmiterea pachetelor de la
MT la rădăcina arborelui.
3). Când celulele ajung la rădăcină cu un nou VCN, tabela de rutare a comutatorului
rădăcină este actualizată cu locaţia noii BS a MT-ului. Aceste celule pot fi dirijate apoi către MT
prin noua cale.
ATM Backbone
Rădăcina arborelui de conexiune virtuală

(3)
Actualizarea tabelei (2)
de rutare

(2)

“Switch”-ul “Switch”-ul
anterior destinaţie

(2)
(1)

BS MT

Fig.7.11. Algoritmul arborelui de conexiune virtuală

Pentru handoff-ul dintre arbori, conexiunea mobilului ajunge la graniţa arborelui şi este
necesar să-l părăsească. MT-ul trebuie să ceară permisiunea noului arbore de conectare, ca şi cum
ar fi un apel nou, de intrare în reţea.

79
 Utilizând această metodă, conexiunile MT-urilor în interiorul unei regiuni geografice sau
a unui arbore, pot fi transmise la oricare altă BS din acea zonă, fără a implica procesorul reţelei.
Cu cât regiunea este mai mare, cu atât probabilitatea ca mobilul să rămână în acel domeniu pe
durata apelului, este mai mare.

80
 8. MANAGEMENTUL MOBILITĂŢII îN UMTS

8.1. Introducere

Cea de a treia generaţie de sisteme de comunicaţii mobile, UMTS (Universal Mobile

Telecommunications System) reprezintă succesorul GSM-ului şi conţine două parţi:
- serviciile de comutare a circuitelor (Circuit Switched – CS);
- serviciile de comutare a pachetelor (Packet Switched – PS).
In CS se realizează managementul apelurilor vocale, iar în PS cel al conexiunilor de date (de
exemplu între un utilizator mobil şi reţeaua Internet).
UMTS a fost proiectată pentru a asigura un acces global al abonaţilor la serviciile oferite de
reţea, precum şi pentru a oferi un serviciu de roaming la nivel mondial. In acest scop, UTRAN
(UMTS Radio Access Network) a fost concepută cu mai multe niveluri ierarhice. Nivelurile
superioare acoperă zone geografice întinse, în timp ce nivelurile inferioare acoperă suprafeţe mai
mici, dar cu o densitate mai mare a staţiilor mobile care încearcă să acceseze reţeaua. De
asemenea, pot asigura mai repede link-uri de la abonaţii mobili către reţea, decât nivelurile
superioare. Intregul sistem este conectat şi integrat cu PSTN şi PDN (Public Data Network).
Sunt planificate următoarele niveluri:
- sisteme prin satelit – acoperă întreaga suprafaţă a planetei (chiar şi în zona mărilor şi
oceanelor, sau a suprafeţelor nelocuite, este posibil accesul la reţea);
- infrastructura UTRAN este terestră şi conţine de asemenea mai multe niveluri şi celule:
- nivelul macro: aceste celule acoperă zone întinse cu regiuni în care numărul
staţiilor mobile care acccesează reţeaua este foarte mic;
- nivelul micro: acoperă zone în care numărul staţiilor mobile care accesează
reţeaua este mare (de ex: metropole); sunt acoperite zone cu suprafaţă mică,
pentru a asigura o capacitate suficientă pentru toţi abonaţii din acea regiune;
- nivelul pico: o astfel de celulă este localizată de obicei în interiorul clădirilor mari,
pentru a se asigura un acces rapid şi de o bună calitate a abonaţilor la reţea.

81
 Fig.8.1. Integrarea UMTS cu reţelele fixe

8.2. Arhitectura UMTS

Reţeaua UMTS este structurată în trei părţi:

- Echipamentul utilizatorului (User Equipment- UE) – care se conectează la UTRAN prin
link-uri radio wireless, la una sau mai multe celule (spre deosebire de GSM, este posibil
să existe link-uri la mai multe celule în acelaşi timp).
- UTRAN – este alcatuită din noduri Bs (echivalente cu BTS din GSM) care sunt conectate
la Radio Network Controllers (RNC – echivalente cu BSC din GSM); RNC-urile sunt
conectate între ele, precum şi la Core Network, prin ATM.
- Core Network (CN) – este conectată cu alte reţele, ca de exemplu: PSTN, Internet, alte
reţele mobile, etc. Are rolul de a ruta traficul, de autentificare, urmărire a localizării, etc.
CN este alcatuită din două parţi: CS şi PS.

82
 Fig. 8.2. Arhitectura UMTS

8.2.1. Echipamentul utilizatorului (UE)

UE poate fi un telefon mobil, un PDA (Personal Digital Assistant), sau un notebook. UE

se conectează la UTRAN prin interfaţa radio Uu, pe baza tehnologiei WCDMA. UE este alcatuit
din două parţi:
- echipamentul mobil – este echipamentul hardware, care nu poate utiliza singur serviciile
UMTS;
- cardul UMTS (USIM-Card – UMTS Subscriber Identity Module-Card) – care conţine
toate datele necesare pentru autentificare şi obţinere a accesului la reţeaua UMTS; spre
deosebire de SIM-ul din GSM (care avea 8kB-32kB de memorie) în USIM se pot
memora câţiva Mb de date personale.

8.2.2. UTRAN

UTRAN este responsabilă, printre altele, de managementul resurselor radio: controlul

puterii, suportul pentru diferite tipuri de handoff şi de asemenea, controlul şi managementul
handoff-urilor.
UTRAN este alcatuită din noduri Bs şi RNC. Cele mai multe noduri Bs asigură controlul
a trei celule. Un grup de noduri Bs sunt conectate prin interfata Iub, la un RNC, printr-o reţea
ATM. Un RNC la care este conectat un nod Bs, este denumit Controlling RNC (CRNC) al
acestui nod Bs. Un RNC împreună cu toate nodurile Bs conectate la el, este denumit Radio
Network Subsystem (RNS).
Un nod Bs operează la nivelul fizic şi nivel reţea şi transmite datele la CRNC. De
asemenea, măsoară calitatea şi puterea semnalelor pe link-ul radio către UE, raportându-le în
acelaşi timp şi CRNC-ului., care poate să reacţioneze pe baza acestor informaţii: de exemplu, sa

83
reducă sau să mărească puterea semnalelor la nodul B şi/sau la UE. RNC-ul alocă de asemenea
un cod W-CDMA pentru link-ul
radio de la UE la nodul B, astfel
încât datele de la un anumit UE să
poată fi extrase dintre datele
transmise de către toate
echipamentele UE şi nodurile Bs
din zonă. RNC-ul este responsabil
şi pentru handoff-urile dintre
diferite RNS-uri, controlul
resurselor radio, etc. Pentru a
asigura un handoff soft, RNC-urile
sunt conectate între ele prin
interfeţe Iur, prin intermediul
reţelelor ATM. De asemenea, sunt
conectate la CN, prin interfeţe Iu-
Cs, sau Iu-PS.

Fig.8.3. Arhitectura UTRAN

8.2.3. CN

Core Network este alcatuită din două parţi: CS şi PS.

CS are următoarele componente:

- MSC (Mobile Switching Center) – este un nod de comutaţie care rutează datele CS în
interiorul şi în exteriorul propriei reţele, prin intermediul Gateway Mobile Switching
Center (GMSC). Un MSC controlează toate RNC-urile care sunt conectate prin interfeţe
Iu-CS. MSC-ul este conectat la mai multe baze de date (ca de exemplu – HLR) şi asigură
managementul mobilităţii pentru echipamentele CS. De obicei (în funcţie de
dimensiunea reţelei), există mai multe MSC-uri într-o reţea UMTS.
- Gateway Mobile Switching Center (GMSC) – este conectată la MSC şi interconectează
propria UMTS cu alte reţele cu comutarea CS (PSTN, ISDN). Intr-o reţea UMTS pot fi
mai multe GMSC-uri.
- Visitor Location Register(VLR) – un VLR este, de obicei, alocat la fiecare MSC. VLR
memorează temporar datele pentru asigurarea securităţii, autentificării şi identificării
tuturor abonaţilor asociaţi MSC-ului. Unele date sunt copiate din HLR.
- Transcoder Rate Adapter Unit (TRAU) – este un gateway între RNC şi MSC, realizând
conversia formatului Adaptive MultiRate (AMR) în Pulse Code Modulation 30 (PCM30)
şi invers pentru semnalul vocal. Acest lucru este necesar deoarece CN şi UTRAN
utilizează diferite formate. Intr-o reţea UMTS pot exista mai multe TRAU.

84
 PS are următoarele componenente:

- Serving GPRS Support Node (SGSN) – este similar cu MSC-ul din CS; are rolul de a
dirija pachetele de date în propria
reţea UMTS, dar şi în afara ei, prin
intermediul Gateway GPRS Support
Node (GGSN). De asemenea asigură
managementul mai multor RNC-uri
conectate prin interfeţe Iu-PS, având
şi link-uri către bazele de date (de
ex., HLR). SGSN asigură şi
autentificarea abonaţilor mobili,
precum şi controlul mobilităţii.

De obicei, există mai multe

SGSN-uri într-o reţea UMTS.
- Serving GPRS Support Node
(SGSN))- este similar cu GMSC din
CS; interconectează reţeaua UMTS
cu alte reţele PS (Internet sau
reţelele X.25), fiind conectat la
SGSN. Pot exista mai multe GGSN
într-o reţea UMTS.

Fig.8.4. Arhitectura PS

Cele două domenii, PS şi CS, au şi elemente comune, cel mai important fiind Home
Location Register (HLR)/Authentication Center (AuC), care este o bază de date în care se
memorează datele relativ stabile ale abonaţilor: informaţiile de securitate şi criptare, numărul
de telefon, serviciile accesibile (prin contract) utilizatorului.

8.3. Handoff-ul în UMTS

Dupa cum s-a menţionat anterior, spre deosebire de GSM, în UMTS toate UE utilizează
întotdeauna aceeaşi frecvenţă. Fiecărei perechi de echipamente care comunică i se alocă un
cod, astfel încât datele acestora pot fi extrase dintre cele transmise de către toate UE. In mod
normal, se realizează un soft handoff. In timpul unui handoff, un UE se conectează la mai
multe celule. Dacă este necesar, o conexiune la o celulă este eliberată după ce una sau mai
multe conexiuni la alte celule au fost deja stabilite. Etapa realizării unui handoff poate dura
un timp îndelungat. La limită, poate dura atâta timp cât conexiunea este activă, în funcţie de
poziţia UE.
Există mai multe cazuri de handoff în UMTS. Aceste cazuri descriu diferitele poziţii
posibile ale unui UE, organizarea celulelor, precum şi nodurile responsabile (Bs, RNC, etc.)

85
din UTRAN aflate lângă aceste localizări. Aceste cazuri, diferite de hard handoff, au loc în
mod frecvent în UMTS:
- Soft handoff (intra nod Bs/intra RNS): acest tip de handoff se realizează dacă UE se
deplasează către o celula alocată altui nod Bs şi ambele noduri Bs aparţin aceluiaşi RNS,
ceea ce înseamnă că sunt conectate şi controlate de acelaşi RNC.
- Soft handoff (inter noduri Bs/intra RNS): acest tip de handoff se realizează dacă UE se
deplasează dintr-o celula acoperită de un nod Bs în altă celulă corespunzatoare unui alt
nod Bs şi ambele noduri aparţin aceluiaşi RNS, ceea ce înseamnă că sunt conectate şi
controlate de acelaşi RNC.
- Soft handoff (inter noduri Bs/inter
RNS/intra SGSN): dacă UE se
deplasează dintr-o celula acoperită de un
nod Bs într-o altă celulă
corespunzatoare unui alt nod Bs, care
aparţine unui RNS diferit, handoff-ul se
numeşte soft handoff (intra RNC).
- Soft handoff (inter noduri Bs/inter
RNS/inter SGSN): în acest caz, UE se
deplasează dintr-o celula acoperită de un
nod Bs într-o alta celula corespunzătoare
unui alt nod Bs, care aparţine unui RNS
diferit. Nodurile Bs sunt conectate la diferite RNC-uri care, la rândul lor, sunt de
asemenea conectate la SGSN-uri diferite. In acest caz, UE trebuie realocat noului SGSN.
- Hard handoff: un hard handoff (handoff inter-frecvente) este necesar numai dacă
schimbarea frecvenţelor se datorează altor cauze, sau dacă interfaţa Iur nu există între
două RNC-uri în cazul uni soft handoff (inter noduri Bs/inter RNS-uri). O cauză a
modificării frecvenţelor poate fi, de exemplu, schimbarea nivelului celulei UMTS, de la o
macro-celula la o zonă controlată prin satelit, sau o modificare a tehnologiei de acces
radio (de la UMTS la WLAN sau GSM). Un hard handoff are loc destul de rar şi diferă
destul de mult de tipurile de handoff prezentate anterior.

8.3.1. Macro-diversitatea

Codurile utilizate în WCDMA de diferitele perechi de staţii mobile sunt aproape

ortogonale, deoarece nu există suficiente coduri complet ortogonale pentru toate UE. Aceste
coduri aproape ortogonale sunt utilizate pentru staţiile mobile localizate în celule diferite,
pentru a menţine cât mai ortogonale posibil codurile utilizate în cadrul unei celule sau în
celulele vecine.
Dacă un UE este localizat în zona de suprapunere a două celule A şi B şi se află la o
distanţă mare de nodul Bs al celulei A, la care este conectat, atunci UE şi nodul Bs trebuie sa
transmită semnalele cu un nivel de putere ridicat (fig.8.5.). Atunci semnalele radio ale UE (şi
ale nodului Bs din celula A) pot ajunge la distanţă mare în celula B. In celula B sunt
localizate UE cu coduri mai puţin ortogonale decât cele utilizate de UE-ul conectat la celula
A. Aceste UE-uri din celula B şi nodul Bs din celula B nu pot filtra datele transmise de UE-ul
situat la graniţa celulei A deoarece codurile sunt aproape similare (numai aproape
ortogonale) şi semnalul din afara celulei A are o putere prea mare. Pentru a compensa aceast

86
fenomen, UE-urile şi nodul Bs din celula B vor mări nivelul de putere al semnalelor
transmise, ceea ce va perturba UE-urile şi nodul Bs din celula A, care vor mări din nou
nivelul de putere, conducând la interferenţă. Creşterea nivelului de putere este realizată până
când UE-urile nu vor mai putea realiza acest lucru. UE-urile au un nivel limitat al puterii
transmise (125 mW pentru telefoanele mobile din clasa 4). Nodurile Bs au de asemenea, un
nivel de putere limitat. Dacă există prea multe UE-uri într-o astfel de zonă de suprapunere,
nodurile Bs vor reduce dimensiunea celulelor lor.

Fig. 8.5. UE conectat la celula A

Pentru a rezolva această problemă, un UE se poate conecta în acelaşi timp la mai multe
celule, chiar dacă acestea aparţin diferitelor noduri Bs sau RNS.
In acest caz, UE poate corecta unele dintre erorile de transmisie, prin compararea datelor
recepţionate de la diverse celule. Ambele celule transmit aceleaşi date, dar codate cu coduri
diferite.
UTRAN poate corecta unele dintre erorile de transmisie prin compararea datelor
recepţionate de diferitele celule de la UE (fig.8.6). Astfel, nivelurile puterii de transmisie de
la UE şi nodul Bs se pot reduce (deoarece erorile de transmisie se pot reduce în modul
menţionat anterior). Această soluţie a fost denumită macrodiversitate sau
microdiversitate, dacă celulele implicate aparţin aceluiaşi nod Bs. Menţinerea mai multor
conexiuni, către diferite celule, este posibilă deoarece toate celulele utilizează aceeaşi
frecvenţă (în GSM acest lucru este mai complicat, deoarece celulele utilizează frecvenţe
diferite). Fig.8.6. UE conectat la mai multe celule

Această tehnică este utilizată pentru soft handoff-ul din UMTS, deoarece într-un soft
handoff link-urile radio către celulele înspre care se deplasează UE sunt adăugate şi (ulterior)
sunt eliminate, cand UE se deplasează din aceste celule. Un UE poate fi implicat într-un
proces de handoff, cu mai multe link-uri radio, pentru un interval de timp mare, sau chiar pe
întreaga durată când link-ul este activ şi se transmit date.

87
 9.3.2. Managementul mobilităţii şi controlul resurselor radio

Figura 9.7. prezintă planul de control al managementului mobilităţii în UMTS între UE-
UTRAN şi UTRAN-CN.

Fig.8.7. Managementul mobilităţii in UMTS

Deasupra nivelului Radio Link Control (RLC) se află Radio Resource Control (RRC).
Acesta are rolul de a asigura conexiuni fiabile între UE şi UTRAN şi în special să
realizeze managementul resurselor radio, fiind de asemenea implicat şi în procesul de
handoff.
Signal Connection Control Part (SCCP) şi Radio Access Network Application Part
(RANAP) asigură managementul conexiunilor dintre UTRAN şi CN. RANAP realizează în
acelaşi timp şi transferul semnalizărilor pentru managementul mobilităţii între CN şi UE.
Aceste semnale nu sunt interpretate de UTRAN. De asemenea, controlează şi realocarea
RNC-urilor, RAB-urilor (Radio Access Bearer –serviciile pentru transferul datelor
utilizatorilor între UE şi CN). Deasupra acestor niveluri, UMTS Mobility Management
(UMM) asigură funcţiile de management al mobilităţii. Pentru a urmări localizarea unui UE,
în cadrul UTRAN sunt definite mai multe grupuri geografice:
- Location Area (LA): acoperă unul sau mai multe RNS-uri; o LA poate acoperi zona mai
multor RNS-uri dacă RNC-ul corespunzător se află sub controlul aceluiaşi SGSN
- Routing Area (RA): o RA este o submulţime a LA; acoperă un singur RNS sau chiar o
submulţime a RNS
- UTRAN RA (URA): o URA este o submulţime a unei RA; acoperă numai câteva noduri
Bs al unui RNS.

88
Fig. 8.8.
Grupuri
geografice în UTRAN

LA-urile sunt utilizate numai în domeniul CS, iar RA în domeniul PS. RA-ul în care este
localizat UE-ul este urmărit de CN (prin intermediul SGSN). In cazul unei conexiuni RRC
active, URA-ul curent în care este localizat UE-ul este urmărit de UTRAN. Dacă UE este
conectat la o celulă, UTRAN va urmări chiar şi această celulă în care este localizat UE-ul.
Un UE este conectat la o celulă, dacă există o conexiune activă RRC şi Packet Data
Units (PDA) este transmis, astfel încât timer-ul care măsoară durata de inactivitate să nu expire.
Dacă într-un interval mai mare de timp nu se transmite nici un PDA, timer-ul expiră şi UE pierde
conexiunea cu celula. UE va fi urmărit din nou, la nivel URA, numai de către UTRAN. In tabelul
urmator se prezintă diferite zone şi nodurile UMTS de care sunt urmărite:

8.3.3. Softer Handoff (intra nod Bs/intra RNS)

Acest tip de handoff este realizat dacă UE se deplasează dintr-o celula în alta, ambele
aparţinând aceluiaşi nod Bs.
Un rake receiver în UE procesează cele două semnale recepţionate de UE de la cele două
antene conectate la acelaşi nod Bs. Se utilizează o metodă stohastică, denumită raportul maxim
de combinare, pentru a minimiza probabilitatea de transmisie cu erori. Nodul Bs combină de
asemenea cele două semnale recepţionate de la UE de două antene cu un rake receiver; utilizează
aceeaşi metoda stohastică pentru a reduce probabilitatea apariţiei erorilor. Cu ajutorul acestei
tehnici, microdiversitatea poate fi în întregime asigurată de un singur nod Bs.

89
 Se estimează că aproximativ 5-15% din totalul conexiunilor UMTS pot fi în condiţiile
unui softer handoff.
Figura 8.8 prezintă succesiunea link-urilor în cazul unui handoff intra nod Bs/intra RNS.
1. Când CRNC decide, pe baza măsuratorilor efectuate de UE, să stabilească un alt link
radio, va trimite mesajul Radio Link Setup Request către nodul Bs. Acesta va începe să
recepţioneze imediat date prin noua antenă.
2. Dupa alocarea resurselor solicitate, nodul Bs trimite mesajul Radio Link Setup
Response către CRNC.
3. Dupa obţinerea sincronizării (prin interfaţa Uu a noii antene, către UE), nodul Bs
anunţă CRNC prin mesajul Radio Link Restore Indication; apoi, nodul Bs va începe să trimita
datele către UE prin intermediul noii antene.
4. CRNC trimite mesajul Active Set Update (RL additional), prin canalul DCCH
(Dedicated Control Channel) cu cea mai noua informaţie de conectare, care UE.
5. UE actualizează setul activ şi confirmă această operaţie prin mesajul Active Set Update
Complete, printr-un canal DCCH; noul link radio este adăugat şi utilizat pentru transmiterea şi
receptia semnalelor radio.
In figura 9.9 este prezentată succesiunea de mesaje pentru ştergerea unui link radio în
situaţia intra nod Bs/intra RNS.

Fig.8.9. Ştergerea unui link radio în situaţia intra nod Bs/intra RNS

1. In momentul în care CRNC decide, pe baza rezultatelor măsuratorilor de la UE, să

şteargă un link radio, va trimite mesajul Active Set Update (RL deletion) către UE prin DCCH.
Astfel, tipul actualizării şi parametri IP ai celulei sunt de asemenea transmişi.
2. După dezactivarea link-ului, UE trimite mesajul Active Set Update Complete către
CRNC prin DCCH.
3. Apoi, CRNC trimite mesajul Radio Link Deletion Request către nodul Bs şi eliberează
resursele vechiului link.
4. După încheierea transmisiei şi recepţiei şi eliberarea resurselor, nodul Bs informează
CRNC prin trimiterea mesajului Radio Link Deletion Response. Link-ul radio este eliberat.

90
 8.3.4. Soft Handoff (inter noduri Bs/intra RNS)

Un soft handoff (inter noduri Bs/intra RNS) este realizat în momentul în care UE se
deplasează dintr-o celulă acoperită de un nod Bs într-o altă celulă acoperită de un alt nod Bs şi
ambele noduri Bs se află sub controlul aceluiaşi RNC (ceea ce înseamnă că aparţin aceluiaşi
RNS. Datele către CN sunt transmise prin interfaţa Iu-PS către RNC. UE recepţionează semnalul
radio de la două noduri Bs diferite, codate cu două coduri diferite şi utilizează un receptor rake
pentru a combina aceste semnale cu un raport maxim de combinare.
RNC primeşte semnalul de la UE de la două noduri Bs diferite. Deoarece RNC
controlează mai multe noduri Bs, nu are un receptor rake pentru a combina semnalele şi a reduce
probabilitatea de apariţie a erorilor de transmisie. RNC utlizează combinarea selectivă pentru a
filtra erorile de transmisie. Fiecare pachet al unuia dintre link-
urile UE-nod Bs are un câmp de calitate în header. RNC
controlează această informaţie în fiecare pachet pe care îl
recepţionează de la unul dintre nodurile Bs şi retransmite
pachetul în cele mai bune condiţii de calitate către CN (prin
interfaţa Iu-PS). Figura 8.11 prezintă diagrama schimbului de
mesaje în cazul adăugării unui link radio în situaţia unui
handoff inter noduri Bs/intra RNS.
1. In momentul în care CRNC decide, pe baza
rezultatelor măsuratorilor de la UE, să stabilească un nou link
radio, trimite mesajul Radio Link Setup Request către noul nod
Bs; acesta va începe să primească imediat date de la UE.
2. După alocarea resurselor solicitate, noul nod Bs va
trimite mesajul Radio Link Setup Response către CRNC,
incluzând descrierea noii
conexiuni stabilite la nivel transport.
3. CRNC setează suportul de transport Iub. Fig. 8.10. Soft handoff (inter
noduri
Acesta include identitatea de asociere ATM, pentru Bs/intra RNS)
asocierea suportului de transport Iub cu DCH
(Dedicated Channel).
4. După obţinerea sincronizării (pentru uplink) prin interfaţa Uu, nodul Bs informează
CRNC prin mesajul Radio link Restore Indication.
5. Nodul Bs sincronizează suprturile de transport deja existente cu cel nou, prin schimbul
de mesaje Downlink Synchronization şi Uplink Synchronization, cu CRNC. Noul nod Bs începe
să trimită date către UE.
6. CRNC trimite mesajul Active Set Update (RL addition) prin DCCH cu cea mai noua
informaţie despre conexiune, către UE.

91
 Fig.8.11.Adăugarea unui link radio în cazul unui handoff inter noduri Bs/intra RNS

7. UE actualizează setul activ şi confirmă acest lucru prin trimiterea unui mesaj Active
Set Update Complete prin DCCH. Sunt de asemenea transmise actualizarea tipului şi
paremetrilor celulei.
In figura 8.12 este prezentat schimbul de mesaje în cazul ştergerii unui link radio.
1. In momentul în care CRNC decide, pe baza rezultatelor măsuratorilor de la UE, să
elibereze un link radio, trimite mesajul Active Set Update (RL deletion) către UE, prin DCCH.
Sunt de asemenea transmise actualizarea tipului şi paremetrilor celulei.
2. După dezactivarea link-ului, UE trimite mesajul Active Set Update Complete către
CRNC.

Fig. 8.12. Ştergerea unui link radio în cazul unui handoff inter noduri Bs/intra RNS

92
 8.3.5. Soft Handoff (inter noduri Bs/inter RNS/intra SGSN)

3. CRNC trimite mesajul Radio Link Deletion Request către nodul Bs (eliminat) şi
eliberează resursele alocate vechiului link radio.
4. După terminarea transmisiei şi recepţiei şi eliberarea resurselor, vechiul nod Bs
informează CRNC prin trimiterea unui mesaj Radio Link Deletion Response.
5. După recepţionarea acestei informaţii, CRNC indică eliberarea suportului de transport
Iub. Link-ul radio este liber
Dacă UE se deplasează de la un nod Bs
către un alt nod Bs care aparţine unui alt RNs,
handoff-ul se numeşte soft handoff (inter noduri
Bs/inter RNS/intra SGSN).
In acest caz, RNC-l care trimite datele la
SGSN este denumit Serving RNC (SRNC).
Celălalt RNC este denumit Drift RNC (DRNC-
DRNC de direcţie). DRNC dirijează în mod
transparent datele recepţionate către SRNC.
SRNC utilizează combinarea selectivă pentru a
retransmite pachetele îin condiţii de cea mai bună
calitate către CN (prin interfaţa Iu-PS). Selecţia
combinată este utilizată în loc de combinarea cu
raport maxim, deoarece RNC-urile nu pot efectua
calculele complicate necesare în această metodă.
Numai SRNC-ul are o conexiune către CN.
Când UE se deplasează prea departe de
SRNC, este necesară realocarea SRNC. Fig. 8.13. Soft handoff (inter noduri
Bs/inter RNS/intra SGSN)
DRNC devine SRNC şi invers.
Figura 8.14 ilustrează etapele prin care este realizată adăugarea unui link radio inter
noduri Bs/inter RNS.

1. In momentul în care SRNC decide, pe baza rezultatelor măsuratorilor de la UE să

stabilească un alt link radio, trimite mesajul Radio Link Setup Request către DRNC, pentru a
solicita resursele radio. Dacă aceasta este prima conexiune la UE prin acest DRNC, se va stabili
o conexiune Iur între SRNC şi DRNC. Parametri purtătorului radio şi ai canalului fizic sunt
semnalizaţi către DRNC.
2. Dacă resursele radio sunt disponibile, DRNC transmite mesajul Radio Link Setup
Request către nodul Bs (DRNC) împreună cu parametri corespunzători. Nodul Bs (DRNC)
începe imdiat să recepţioneze date de la UE.

93
 Fig. 8.14. Adăugarea unui link radio în cazul unui handoff inter noduri Bs/inter RNS/intra
SGSN

3. După alocarea resurselor solicitate, nodul Bs (DRNC) trimite mesajul Radio Link
Setup Response către DRNC împreună cu informaţiile despre suporturile de transport ATM.
4. DRNC trimite mesajul Radio Link Setup Response către SRNC care include
desrcrierea conexiunilor recent stabilite de pe
nivelul transport.

5.SRNC setează Iur şi Iub, ceea ce va include identitatea de asociere ATM (pentru
asocierea Iub cu DCH); operaţia se va efectua pentru fiecare Iur şi Iub.
6. După obţinerea sincronizării prin interfaţa Uu, nodul Bs (DRNC) va notifica DRNC
prin mesajul Radio Link Restore Indication. Apoi DRNC va trimite acest mesaj către SRNC.
7. Nodul Bs (DRNC) sincronizează suporturile de transport deja existente cu cel nou,
prin schimbul de mesaje Downlink synchronization şi Uplink synchronization cu SRNC. Nodul
Bs (DRNC) începe să trimită date către UE.
8. SRNC trimite mesajul Active Set Update (RL addition) prin canalul Dedicated Control
Channel (DCCH), cu cea mai actualizată informaţie de conectare, către UE.
9. UE actualizează setul activ şi confirmă acest lucru prin trimiterea mesajului Active Set
Update Complete către SRNC, prin canalul DCCH. Noul link radio este adăugat pentru a
recepţiona şi a trimite semnale.
In fig. 8.17 este prezentată diagrama schimbului de mesaje în cazul inter noduri Bs/inter
RNS/inter SGSN. In acest caz, etapele sunt identice, cu excepţia 2-4, 9 şi 11. Ele nu au fost
tratate în acest caz, deoarece ambele RNC-uri sunt controlate de acelaşi SGSN (SGSN1=SGSN2
în fig. 8.17).
In fig. 8.15 este descrisă eliminarea unui link radio.

94
 1.In momentul în care SRNC decide, pe baza rezultatelor măsuratorilor efectuate de UE,
să elimine unul dintre link-urile radio, trimite mesajul Active Set Update (RL deletion către UE,
prin DCCH. Sunt de asemenea transmise tipul actualizat şi parametri celulei.
2. După dezactivarea link-ului, UE trimite mesajul Active Set Update Complete către
SRNC, prin DCCH.
3. SRNC solicită DRNC să elibereze resursele vechiului link radio, prin trimiterea
mesajului Radio Link Deletion Request.
4. DRNC trimite mesajul Radio Link Deletion Request către nodul Bs (DRNC).
5. După încheierea transmisiei şi recepţiei şi eliberarea resurselor, nodul Bs (DRNC)
informează DRNC prin trimiterea unui mesaj Radio Link Deletion Response.
6. DRNC trimite de asemenea un mesaj Radio Link Deletion Response către SRNC.
7. După recepţia acestei informaţii, SRNC iniţiază eliberarea Iur şi Iub. Link-ul radio este
eliminat.

Fig. 8.15. Ştergerea unui link radio în cazul unui handoff inter noduri Bs/inter RNS/intra
SGSN

95