Sunteți pe pagina 1din 16

UNIVERSITATEA POLITEHNICA din BUCURETI

Facultatea de Electronic, Telecomunicaii i Tehnologia Informaiei

Proiect 3

Analiza HandOver-ului n LTE

Oancea Ana Maria Grupa 443C

Bucureti 2014

Cuprins

1.

Introducere n LTE ...................................................................................................................1 1.1 Arhitectura LTE ............................................................................................................................1 1.2 Specificaii LTE .............................................................................................................................3 Procedura de HO n LTE..........................................................................................................3 2.1 Algoritmul procedurii de HO pe interfaa X2 n LTE ....................................................................3 2.2 Algoritmul procedurii de HO pe interfaa S1 n LTE .....................................................................6 2.3 Declanarea procedurii de HO........................................................................................................8

2.

3.

Simularea procedurii de HO ....................................................................................................9 3.1 Simulatorul de reea .......................................................................................................................9 3.2 Instalarea simulatorului de reea NS-3 ........................................................................................10

3.3 Procedura de HO............................................................................................................. 11


4. Bibliografie ...............................................................................................................................14

Analiza HandOver-ului n LTE


1. Introducere n LTE

LTE (Long Term Evolution) reprezint evoluia tehnologiei comunicaiilor mobile celulare spre o reea IP full broadcast i este introdus n 3GPP Release 8. Scopul acestui proiect 3GPP este de a dezvolta sistemul UMTS (Universal Mobile Telecommunications System). Proiectul ofer o experien mbuntit utilizatorului i o tehnologie simplificat pentru urmtoarea generaie de reele mobile de tip broadband. Oamenii de tiin i inginerii de design de la mai mult de 60 de operatori, vnztori i institute de cercetare i-au unit forele pentru a realiza aceast standardizare n mediile de acces radio. O mare parte din 3GPP Release 8 va fi orientat spre modernizarea tehnologiei de comunicaii UMTS la 4G, precum i crearea unui sistem de arhitectur all-IP (bazat doar pe IP). 1.1 Arhitectura LTE Spre deosebire de arhitectura UMTS, arhitectura LTE conine un singur tip de nod numit eNodeB. Acesta preia funciile suportate de NodeB i RNC prezente n UMTS i, n plus, se ocup i de managementul resurselor radio. Arhitecturile celor dou tehnologii, UMTS i LTE sunt prezentate n figura 1.1.

Fig. 1.1 Arhitectura UMTS i LTE

Arhitectura simplificat a reelei LTE este prezentat n figura 1.2, ilustrat mai jos.

Fig. 1.2 Arhitectura reelei LTE simplificat

Dup cum se observ i n figura 1.2, eNodeB-urile interacioneaz ntre ele prin interfaa X2 ce faciliteaz att transferul informaiei utile, ct i semnalizarea necesar. Schimbul de informaie dintre eNodeB-uri i Core Network este facilitat de interfaa S1 ce face legtura ntre eNodeB i PDN-Gw (Packet Data Network Gateway). Core Network-ul n LTE se numete EPC (Evolved Packet Core). Aceast arhitectur redus faciliteaz reducerea considerabil a latenei att n ceea ce privete transmisia pachetelor de date, ct i faza de setup a conexiunii. Mai mult, cu aceast arhitectur, costurile de operare sunt reduse.

1.2 Specificaii LTE Printre caracteristicile tehnologiei LTE se numr transferul n downlink (legtura descendent) cu o rat de pn la 100 Mb/s, transferul n uplink cu o rat de pn la 50 Mb/s i asigurare QoS (Quality of Service) ce permite o laten a transferului mai mic de 5 ms n reeaua de acces radio (RAN Radio Access Network). Tehnologia LTE are abilitatea de a gestiona mobile ce se deplaseaz rapid i suport broadcast i multicast. LTE suport benzi ale purttoarei scalabile de la 1,4 MHz pn la 20 MHz. n LTE, metodele de multiplexare folosite sunt diferite n DL (downlink) fa de cele folosite n UL (uplink). Dac n DL multiplexarea se face n frecvene multiple ortogonale, i anume OFDMA (Ortogonal Frequency Division Multiple Access), n UL multiplexarea se face prin SC-FDMA (Single Carrier Frequency Division Multiple Access). 2. Procedura de HandOver n LTE

Scopul HandOver-ului este a asigura continuitatea unui serviciu folosit de UE (User Equipment) atunci cnd acesta din urm se afl n micare. n LTE Exist 3 categorii de HO (HandOver) : Inter eNodeB HO HO n cadrul reelei LTE ntre dou eNodeB-uri distincte; Intra eNodeB HO HO n cadrul aceluiai eNodeB (ntre celule diferite); Inter RAT (Radio Access Technology) HO HO din cadrul reelei LTE ntr-o reea cu o tehnologie diferit. Procedura de HO este transparent pentru utilizator, fiind o procedur controlat de reea i asistat de UE. n continuare, vor fi dezvoltate dou proceduri de HO, n funcie de interfeele utilizate n procedur. Astefel, din acest punct de vedere, exist dou tipuri de HO: HO bazat pe interfaa X2; HO bazat pe interfaa S1. 2.1 Algoritmul procedurii de HO pe interfaa X2 n LTE Procedura de HO este iniiat de un raport de msurtori (measurement report) care este trimis prin protocolul RRC (Radio Resource Control). Dup recepia raportului de msurtori, algoritmul de HO va decide dac se va iniia sau nu procedura de HO. Procedura de HO este compus din urmtoarele funcii: Msurtori; Filtrarea msurtorilor; Raportul msurtorilor realizate; Algoritmul de Hard HO; Execuia HO-ului.

Procedura de HO este prezentat, n diferite stadii, n figura urmtoare, figura 2.1

Fig. 2.1 Procedura de HO O descriere detaliat a semnalizrilor din cadrul procedurii se gsete n figura 2.2. n continuare, sunt descrii paii ilustrai n imaginea menionat. 1. UE trimite un raport de msurtori bazat pe configuraia setat de eNodeB. Acest raport conine i informaii despre celulele vecine. n prezent, msurtorile cu privire la semnalul provenit de la celulele vecine sunt bazate pe capacitatea UE de a detecta celulele vecine i nu pe o list cu celule vecine furnizat de reea. 2. eNodeB-ul analizeaz msurtorile rezultate i decide dac este necesar procedura de HO. Dac aceasta este necesar, eNodeB-ul surs alege cea mai bun celul dintre cele prezente n raportul de msurtori pentru a deveni celula destinaie n procedura de HO. 3. eNodeB-ul surs realizeaz o legtur cu eNodeB-ul destinaie. Aceast legtur se realizeaz prin mesajul HANDOVER REQUEST trimis pe interfaa X2. 4. eNodeB-ul destinaie verific dac are resursele necesare pentru a i le aloca UE-ului ce trebuie s realizeze HO-ul. Verificarea se realizeaz prin procedura Admission Control. 5. Dac eNodeB-ul destinaie decide c are resurse disponibile, acesta ncepe s pregteasc resursele radio. n acelai timp, i trimite eNodeB-ului surs mesajul HANDOVER REQUEST ACKNOWLEDGE prin aceeai interfa X2. Mesajul conine un mesaj RRC (RRCConnectionReconfiguration) pe care eNodeB-ul surs trebuie s l redirecioneze ctre UE. RRCConnectionReconfiguration conine parametrii de securitate necesari UE-ului de a se conecta la eNodeB-ul destinaie. n mesajul HANDOVER REQUEST ACKNOWLEDGE este indicat i un tunel de transfer al datelor. 6. eNodeB-ul surs redirecioneaz mesajul RRCConnectionReconfiguration ctre UE. Imediat ce mesajul este trimis, eNodeB-ul surs trimite pachetele ce trebuiau trimise n DL prin interfaa X2, ctre eNodeB-ul destinaie. Cnd UE-ul primete mesajul, se detaeaz de celula surs.

Fig. 2.2 Semnalizri HO X2

7. eNodeB-ul surs i trimite eNodeB-ului destinaie un mesaj SEQUENCE NUMBER STATUS TRANSFER prin interfaa X2. Acest mesaj este folosit pentru a transfera numrul de secven PDCP (Packet Data Convergence Protocol) ctre eNodeB-ul destinaie. 8. UE folosete parametrii primii pentru a realiza sincronizarea cu celula destinaie. 9. UE confirm eNodeB-ului destinaie c HO s-a realizat cu succes prin mesajul RRCConnectionReconfigurationComplete. Dup primirea confirmrii, eNodeB-ul destinaie ncepe s trimit pachetele primite de la eNodeB-ul surs ctre UE. 10. Dup ce UE confirm primirea pachetelor, eNodeB-ul destinaie trimite un mesaj PATH SWITCH REQUEST ctre MME (Mobility Management Entity) pe interfaa S1. Prin acest mesaj se anun MME-ul c UE i-a schimbat locaia. 11. Dup primirea mesajului PATH SWITCH REQUEST, MME-ul trimite un mesaj USER PLANE UPDATE REQUEST ctre S-Gw/PDN-Gw prin interfaa S11. Cnd unitatea S-Gw/PDN-Gw primete cererea, aceasta schimb calea de date a UE de la eNodeB-ul surs la eNodeB-ul destinaie. 5

12. Ulterior, S-Gw/PDN-Gw trimite mesajul USER PLANE UPDATE RESPONSE ctre MME pe interfaa S11 prin care afirm c s-a schimbat calea de date cu succes. 13. MME-ul confirm cererea eNodeB-ului destinaie prin interfaa S1. 14. eNodeB-ul destinaie notific eNodeB-ul surs, prin interfaa X2, c procedura de HO s-a realizat cu succes. 15. Cnd eNodeB-ul surs primete mesajul UE CONTEXT RELEASE, acesta elibereaz resursele rezervate pentru UE. Resursele sunt rezervate pn n acest moment pentru cazul n care procedura de HO eueaz. 2.2 Algoritmul procedurii de HO pe interfaa S1 n LTE Un HO pe interfaa S1 este necesar n cazul n care o alt unitate MME va fi responsabil de UE dup realizarea HO-ului. De asemenea, un astfel de HO poate fi iniiat i n cazul n care, din diferite motive, nu exist o interfa X2 ntre eNodeB-urile care particip la HO. n figura 2.3 este prezentat o variant simplificat a acestei proceduri.

Fig. 2.3 Procedura de HO

O descriere detaliat a semnalizrilor din cadrul procedurii se gsete n figura 2.4. n continuare, sunt descrii paii ilustrai n imaginea menionat.

Fig. 2.4 Semnalizri HO S1 1. UE trimite un raport de msurtori bazat pe configuraia setat de eNodeB. 2. eNodeB-ul surs decide faptul c trebuie iniiat procedura de HO. Observ c nu exist o interfa X2 ntre acesta i eNodeB-ul destinaie, astfel, iniiaz un HO asistat de MME. 3. eNodeB-ul surs trimite ctre MME un mesaj prin care i cere asistarea la HO. Acest mesaj menioneaz i informaii precum disponibilitatea unei interfee X2 i identitile eNodeB-ului destinaie i a zonei destinaie, TAI (Tracking Area Identity). TAI-ul destinaie este folosit de MME pentru a determina dac trebuie sau nu s se schimbe unitatea MME. Existena unei interfee X2 este folositoare n cazul n care trebuie schimbat MME-ul, deoarece datele pot fi trimise prin aceast interfa. 4. Unitatea MME trimite eNodeB-ului destinaie mesajul HO REQUEST ce conine informaii despre purttoarele necesare pentru transferul datelor i a semnalizrilor i posibile restricii ale procedurii de HO. 7

5. Dac eNodeB-ul destinaie apreciaz c are resursele necesare pentru HO, rezerv resurse pentru UE. Apoi, eNodeB-ul destinaie trimite o ntiinare (HO REQUEST ACKNOWLEDGE) ctre MME. 6. MME-ul trimite unitii S-Gw/PDN-Gw o cerere pentru crearea unui tunel indirect de transmitere a datelor ntre eNodeB-uri. 7. S-Gw/PDN-Gw confirm crearea unui astfel de tunel. 8. Unitatea MME trimite mesajul HANDOVER COMMAND ctre eNodeB-ul surs. 9. eNodeB-ul surs trimite mesajul RRCConnectionReconfiguration cu mobilityControlInformation ctre UE. 10. Dup ce trimite mesajul de HANDOVER COMMAND ctre UE, eNodeB-ul surs trimite ctre MME starea de transfer a eNodeB-ului (PDCP). 11. Aceast informaie este transmis mai departe ctre eNodeB-ul destinaie. 12. UE realizeaz sincronizarea cu celula destinaie. 13. Pentru a anuna eNodeB-ul surs de faptul c procedura de HO s-a ncheiat cu succes, UE trimite mesajul RRCConnectionReconfigurationComplete ctre eNodeB-ul destinaie. 14. Imediat ce eNodeB-ul destinaie constat c UE s-a ataat cu succes, acesta notific MME-ul. 15. La primirea mesajului HANDOVER NOTIFY, MME-ul seteaz un timer de eliberare a resurselor. Cnd acest timer expir, MME-ul va elibera resursele de la eNodeB-ul surs. Aceast aciune se realizeaz prin paii 19-20 care nu vor fi detaliai. 16. MME-ul trimite o notificare ctre S-Gw/PDN-Gw. Scopul acestei notificri este de a schimba calea UE ctre eNodeB-ul destinaie. 17. S-Gw/PDN-Gw schimb calea i confirm modificarea.

2.3 Declanarea procedurii de HO Procedura de HO este declanat la UE pe baza unor factori definii de reea. i anume, un set de factori de declanare este semnalat ctre UE. Unul dintre aceti factori poart numele de HO hysteresis, iar cellalt se numete TTT (Time To Trigger). n raportul de msurtori trimis periodic de UE se gsesc informaii despre nivelul semnalului radio (reprezentat de parametrul RSRP) i calitatea acestuia (reprezentat de paramentrul RSRQ). n cazul n care algoritmul de HO se bazeaz pe valori ale parametrul ui RSRP, procedura de HO este declanat cnd valoarea parametrului RSRP al unei celule vecine este mai mare dect valoarea aceluiai parametru al celulei curente cu un numr de dB egal cu o valoare HO hysteresis. Aceast condiie trebuie s fie satisfcute pe o perioad de timp egal cu TTT.

Fig. 2.5 Declanarea procedurii de HO

n figura 2.5 este prezentat un exemplu de declanare a procedurii de HO. n acest exemplu, se realizeaz procedura de HO de la celula A ctre celula B. Se observ c abia dup ndeplinirea simultan a ambelor condiii date de HO hysteresis i de TTT, se declaneaz HO-ul.

3. Simularea procedurii de HandOver 3.1 Simulatorul de reea NS (Network Simulator) este numele unei serii de simulatoare de reea bazate pe evenimente discrete. n seria NS exist urmtoarele simulatoare: NS-1, NS2, NS-3. NS-2 este un simulator de reea care i-a stabilizat poziia ca fiind standardul simulatoarelor de reea deoarece are foarte multe librrii i foarte muli au participat la dezvoltarea sa. Organizaii non-profit au contribuit cu componente n librriile sale i s-a demonstrat c modul de dezvoltare NS-2 a fost un succes. Cu toate acestea, din cauza unor limitri de design, a fost nevoie s se dezvolte succesorul su, NS-3. Totui, NS-3 nu este doar o versiune actualizat a NS-2. Au fost reimplementate mai multe mecanisme bazate pe experiene reuite sau mai puin reuite ale NS-2. NS-3 este un software gratuit, oferit public sub licena GNU GPLv2 pentru activiti precum cercetare, dezvoltare, activiti didactice, etc. Scopul proiectului NS-3 este de a crea un mediu de simulare deschis pentru cercetarea n domeniul reelelor care va fi preferat n interiorul comunitii de cercetare. Deoarece procesul de a crea un simulator de reea care s conin un numr suficient de modele de nalt calitate validate, testate i ntreinute 9

permanent presupune un volum mare de munc, proiectul NS-3 este rspndit ntr-o comunitate mare de utilizatori i dezvoltatori. Simulatorul NS-3 este folosit pentru cercetarea att n domeniul reelelor bazate pe IP ct i n domeniul reelelor care nu sunt bazate pe IP. Totui, cea mai mare parte a utilizatorilor se concentreaz pe simulrile wireless/IP care includ modele pentru Wi-Fi, WiMAX sau LTE. 3.2 Instalarea simulatorului de reea NS-3 n acest subcapitol se va prezenta o metod de instalare a simulatorului NS-3 pe o versiune a sistemului de operare Ubuntu, bazat pe Linux. Pentru nceput sunt instalate nite pachete necesare pentru rularea optim a simulatorului. Unele dintre aceste pachete sunt opionale, n funcie de tipul simulrilor necesare. Pentru a instala aceste pachete, vor fi rulate n terminalul sistemului de operare urmtoarele comenzi, ilustrate n figura 3.1.

Fig. 3.1 Pachete utilizate de NS-3

n continuare se va instala simulatorul folosind metoda tarball (denumire ce deriv din extensia arhivelor specifice programelor instalate n Ubuntu, .tar.gz). Tot n terminal se vor da comenzi pentru crearea unui director n care se va descrca arhiva ce conine simulatorul, dezarhivarea acesteia i instalarea propriu-zis. Comenzile sunt afiate n figura 3.2.

10

Fig. 3.2 Instalare NS-3 Pentru a vizualiza simulrile pe o interfa grafic, se va folosi tool -ul NetAnim. Pentru instalarea acestuia, se folosesc comenzile de mai jos.

Fig. 3.3 Instalare NetAnim

3.3 Procedura de HandOver Simularea procedurii de HO pentru NS-3 a fost realizat n cadrul proiectului LENA. Produsele dezvoltate n cadrul acestui proiect sunt open-source, orientate pe simularea reelelor LTE/EPC care permit furnizorilor de echipamente s proiecteze i s testeze algoritmii i soluiile proprii n fiiere de forma SON (Self Organized Network). Codul surs dezvoltat de LENA pentru aceast simulare se gsete n Anexa 1 cu mici modificri adugate pentru a obine inferfaa grafic de tip animaie ce va fi vizualizat n NetAnim. Pentru nceput, se ruleaz codul dintr-un document cu extrensia .cc cu ajutorul comenzii ./waf --run file_name, scris n terminal. Execuia acestei comenzi se poate vizualiza i n figura 3.4, ilustrat mai jos. n documentul ho.cc se gsete codul prezentat n Anexa 1.

11

Fig. 3.4 Rularea codului de HO Cu modificrile fcute pentru a folosi NetAnim, rularea codului genereaz i un fiier cu extensia .xml. Acest fiier .xml se va ncrca n programul NetAnim, iar prin apsarea butonului Play se va vizualiza animaia generat. Mai jos pot fi observate cteva imagini din cadrul acestei animaii.

Fig. 3.5 Animaie

12

Fig. 3.6 Animaie

Fig. 3.7 Animaie

13

4. Bibliografie [1] http://en.wikipedia.org/wiki/LTE_(telecommunication) [2] http://www.teletopix.org/4g-lte/types-of-handover-in-lte/ [3] http://www.teletopix.org/4g-lte/handover-algorithm-and-procedure-in-lte/ [4] Handover within 3GPP LTE: Design Principles and Performance, Ericsson Research [5] Performance of Handover in Long Term Evolution, Atte Helenius [6] http://www.nsnam.org/overview/what-is-ns-3/ [7] http://en.wikipedia.org/wiki/Ns_(simulator) [8] http://networks.cttc.es/mobile-networks/software-tools/lena/ [9] http://www.nsnam.org/wiki/NetAnim

14

S-ar putea să vă placă și