Tehnologia i arhitectura reelei LTE

- Planificatoare de resurse pentru reelele LTE ( LTE schedulers )

- Proiect cercetare semestrul II -

Coordonator:
Prof. Dr.Ing. erban Obreja

Student
Cosmin Tudorache
Master: TSAC II

Cuprins

1.
2.
3.
4.
5.
6.
7.
8.
9.

Descrierea tehnica a unei retele LTE

Arhitectura retelei LTE
Arhitectura protocoalelor LTE
Planificatorul la nivel MAC
Implementarea planificatoarelor de trafic folosind platform de simulare NS3 LTE LENA
Modelul EPC
Planificatorul Round Robin
Simularea unei retele LTE in NS3
Exemplu de simulare pentru planificatorul LTE

1. Descrierea tehnic a unei retele LTE

LTE este a patra generaie (4G) a reelelor de comunicaii celulare, care a fost proiectata
de o organizaie de standardizare numita Third Generation Partnership Project (3GPP), fiind
cunoscuta ca 3GPP Long Term Evolution. LTE a evoluat de la bine-cunoscutul 3G-Universal
Mobile Telecommunication System (UMTS), care, la rndul su, a evoluat de la dominantul 2G
2G Global Systems for Mobile Communications.
LTE a fost dezvoltat pentru a ndeplini nevoia unei reele de telecomunicaii in a suporta
cererea mare pentru traficul de date a serviciilor ce ocupa o lime de band ridicata. O
msurtoare a traficului de voce i de date n reelele de telecomunicaii mobile din ntreaga lume
realizata de Ericsson a artat c vocea nu mai era serviciul dominant n sistemele de comunicaii
mobile.

Figura 1: Msurtoare a traficului de voce i de date n reelele de telecomunicaii mobile

din ntreaga lume, in perioada

Figura urmatoare prezinta evolutia sistemelor de telecomunicatii celulare:

Figure 2: Evolutia sistemelor de telecomunicatii celulare

2. Arhitectura retelei LTE

Sistemele de comunicaii mobile tradiionale (1G, 2G) au fost construite pentru a permite,
n principal, traficul de voce; prin urmare, s-au bazat pe tehnologia cu comutare de circuite. Ca
urmare a dezvoltarii internetului, utilizatorii de telefoane mobile au dorit ca device-urile lor le
permita accesul la aplicaii bazate pe IP. Prin urmare, urmtoarele evoluii ale sistemelor de
comunicaii mobile, cum ar fi GPRS, EDGE i UMTS 3G au permis comunicaii cu comutare de
pachete. Odat cu dezvoltarea continu a aplicaiilor mobile i cererea mare pentru serviciile de
date, evoluia de la UMTS 3G la 4G LTE se efectueaz n conformitate cu viziunea c viitoarea
reea de acces radio ar fi bazata pe tehnologiile cu comutare de pachete.
Figura urmatoare prezinta evolutia arhitecturii reelei GSM i UMTS in arhitectura LTE.
Exist evoluii n ambele reele de acces radio, cu noua interfa radio (SAE - System
architecture evolution) i reea core care este capabila de a permite att de voce, cat si servicii de
date pe o infrastructura ce permite doar comutare de pachete.

Figure 3 Evolutia arhitecturii sistemului de la GSM si UMTS la LTE

n figura de mai sus se pot vedea principalele blocurile ale arhitecturii LTE, inclusiv
echipamentul utilizatorului UE (User Equipment), Evolved-UMTS Terrestrial Radio Access
Network (E-UTRAN), Evolved Packet Core - reeaua EPC i domeniul serviciilor.
Conjunctia dintre SAE i LTE a introdus termenul de Evolved Packet System (EPS) n
sistemele de comunicaii 4G. Reelele de acces radio EPS i reeaua core se bazeaz pe un
mecanism de schimb de pachete. Intreaga arhitectura a unei retele LTE este prezentata in figura
urmatoare:

Figure 4: Arhitectura retelei LTE

Echipamentul utilizatorului: de obicei echipamentul utilizatorului este dispozitivul

portabil care accept LTE pentru a permite accesul acestuia la serviciile de voce i de date. UE
conine SIM-ul pentru identificarea si autentificarea utilizatorului, cat si pentru a obine cheile de
securitate pentru protecia transmisiei prin interfaa radio. UE ofer interfaa cu utilizatorul final,
astfel nct aplicaiile client, cum ar fi VoIP, pot fi utilizate pentru a configura un apel vocal.
E-UTRAN: reeaua de acces LTE, E-UTRAN, este formata din una sau mai multe
eNodeB-uri, care sunt utilizate pentru a asigura transmisia i recepia de semnale pe interfaa
radio. EnodeB-ul mosteneste functionalitatile att ale RNC-ului, cat i NodeB-ului din
arhitecturile UMTS si RAN. Practic, eNodeB-ul implementeaz modularea i demodulare
semnalelor, codificarea i decodificarea canalului de comunicatie, controlul resurselor radio i
gestionarea mobilitii. EnodeB-ul , de asemenea, actioneaza ca o punte de nivel 2 ntre UE i
EPC. Funcionalitile eNodeB-ului sunt reprezentate n figura urmatoare:

Figura 5: Conexiunile eNodeB-ului cu alte noduri logice i principalele functii

Evolved Packet Core Network (EPC): dup cum ii spune numele, EPC este format
doar dintr-un domeniu IP cu comutare de pachete. Aceasta arhitectura ajut la mbuntirea att
a serviciilor de timp real , cat si cele non-real-time prin facilitarea conexiunii IP end-to-end de la
UE la orice dispozitiv din reea. n comparatie cu 3GPP, EPC cuprinde urmtoarele entiti:
- Mobility Management Entity (MME): MME-ul este considerat principalul element
de control, fiind folosit pentru a procesa semnalizarea i funciile de control ntre UE i EPC.
Figura urmatoare prezint principalele funcii ale MME-ului n legatura cu alte noduri din EPC.

Figure 6: Conexiunele MME-ului cu alte noduri logice si principalele functii oferite

Dup cum se poate observa, resursele de reea i de gestionarea mobilitii sunt
principalele funcii ale MME-ului. n plus, acesta ofer autentificare si securitate, colectand
informaiile utilizatorului de la HSS.
Serving Gateway (S-GW): funcia principal a S-GW-ului este de a susine mobilitatea
UE-ului, atunci cnd utilizatorul se deplaseaz de la un eNodeB la altul, sau n cazul n care UE
ncearc s lucreze n corelaie cu reele de comunicare 3GPP. Mai mult, S-GW-ul este utilizat
pentru a stoca temporar pachetele utilizatorului atunci cnd acesta efectueaz transfeul de la un
eNodeB la altele.
Packet Data Network Gateway (P-GW): P-GW-ul este responsabil pentru crearea de
comunicare IP end-to-end prin furnizarea de adrese IP la UEs, acionand ca un punct terminal
pentru livrarea pachetelor de date ale utilizatorilor. P-GW-ul ofera, de asemenea, caracteristici de
aplicare a politicii i parametrilor QoS pentru fiecare utilizator n funcie de alocarea resurselor.
Principalele funcii ale P-GW-ului sunt rezumate in figura urmatoare:

Figure 7: Conexiunile P-GW-ului cu alte noduri logice si principalele functii oferite

Policy and Charging Rules Function (PCRF): PCRF-ul ofera politicile de control si
acces pentru utilizatorii retelei prin determinarea accesului la resurse i limitarea utilizarii
acestora n funcie de profil. PCRF-ul se conecteaz cu serviciile IMS (IP Multimedia Subsystem), prin intermediul interfeei RX, pentru a asigura accesul utilizatorilor la IMS.
Principalele funcii ale PCRF-ului sunt prezentate in figura urmatoare:

Figure 8: Conexiunile PCRF-ului cu alte noduri logice si principalele functii oferite

Domeniul serviciilor ofer o mapare logic la un set diferit de servicii ce se includ n
cadrul sub-sistemului Multimedia IP (IMS). Tipul de servicii poate fi clasificat n principal dup
cum urmeaz:
servicii IMS: IMS-ul este o maina de servicii pe care operatorul o poate utiliza
pentru a furniza servicii folosind Session Initiation Protocol (SIP).
servicii Non-IMS: servicii de streaming video furnizate de pe un server de
streaming.
Alte servicii care nu sunt furnizate de operatorul de reea mobil: serviciile
furnizate prin intermediul internetului , precum serverele web ce permit navigarea in internet.
Home Subscription Server (HSS) : HSS-ul este de obicei o baz de date care stocheaz
profiluri de utilizator i actualizeaz informaiile abonatiilor, facilitand generarea de informaii
de securitate de la utilizator. HSS poate fi considerat o combinaie intre Home Location Register
(HLR) i Authentication Center (AuC).

3. Arhitectura protocoalelor LTE

Arhitectura protocoalelor LTE poate fi mprit n dou pri principale:
- planul de control: furnizeaza mesaje i proceduri pentru a sprijini fiecare
interfa in efectuarea funciile oferite
- planul de utilizator: poart datele de utilizatorului retelei.

Stiva de protocoale pentru planul de control ntre UE i MME este reprezentat

urmatoare:

Figura 9: Stiva de protocoale a planului de control

n figura de mai sus, regiunea de culoare gri a stivei indic nivelul de acces. Stratul
superior este unul non-acces (NAS- Non Access Stratum), fiind alcatuit din protocolul EPS
Mobility Management (MEM) i protocolul EPS Session Management (ESM). Primul este
responsabil pentru manipularea mobilitatii UE-ului n cadrul sistemului, n timp ce al doilea este
folosit pentru a se ocupa de managementul purtatoarei ntre UE i MME (n plus la E-UTRAN
procedurile de management ale purtatoarei).
Protocoalele interfetei radio sunt :
Radio Resource Control (RRC): Acest protocol este in controlul utilizarii
resurselor radio. Administreaza semnalizarea UE-urilor i conexiunilor de date si include funcii
pentru transfer (handover).
Packet Data Convergence Protocol (PDCP): Principalele funcii ale PDCP sunt
compresia antetului IP (UP), criptarea i protectia integritatii (numai CP).
Radio Link Control (RLC): Protocolul RLC este responsabil pentru segmentarea
i concatenarea a PDCP-PDUs pentru transmisia pe interfaa radio. Efectueaz, de asemenea, o
corectare a erorilor (ARQ- Automatic Repeat Request).
Medium Access Control (MAC): Nivelul MAC este responsabil pentru
programarea datelor n funcie de prioriti i multiplexarea acestora blocuri de transport la nivel
1. Nivelul MAC ofer, de asemenea, de corectare a erorilor (Hybrid ARQ).
Physical Layer (PHY): Aceasta este nivelul 1 LTE-Uu, interfata radio, care are
grij de funciile nivelului DS-CDMA.
Toate pachetele IP pentru un UE sunt ncapsulate ntr-un protocol-EPC specific,
formandu-se tuneluri ntre P-GW i eNodeB pentru transmiterea la UE. Protocoalele planului de
utilizator pentru transmiterea pachetelor de date sunt prezentate n urmatoarea figura:

Figura 10: Stiva de protocoale a planului de utilizator

Protocoalele interfetei radio la nivel acces sunt aceleai ca si la planul de control. Exist
insa dou protocoale adiionale, dupa cum urmeaz:
GPRS Tunnelling Protocol, planul de utilizator (GTP-U): GTP-U este utilizat atunci
cnd S5/S8 este bazat pe GTP. GTP-U formeaz tunelul GTP-U care este utilizat pentru a trimite
pachete IP pentru utilizatorul final, pachete ce aparin unui purttor EPS. Este folosit n interfa
S1-U i este utilizat n S5/S8 daca CP folosete GTP-C.
Generic Routing Encapsulation (GRE): GRE este folosit n interfaa S5/S8 mpreun cu
PMIP. GRE formeaz un tunel IP pentru a transporta toate datele care aparin unei conexiuni
UE- anumit PDN. GRE este folosit direct in partea superioara a nivelului IP, UDP-ul nefiind
utilizat
Infrastructura de reea LTE include toate dispozitivele hardware i protocoalele software
care au fost explicate anterior. n special, aceasta trebuie s conin reeaua radio LTE, care ofer
acces radio direct la dispozitivele UEs. Infrastructura de reea LTE interconecteaz UEs prin
asigurarea de conexiuni prin intermediul reelei radio LTE i mentinerea unei conexiuni la P-GW.

4. Planificatorul la nivel MAC

Nivelul MAC , n special planificatorul MAC este cel care este responsabil de atribuirea
blocului de resurse pentru utilizatori. Planificatorul MAC determina cnd i ct de multe blocuri
de resurse ar trebui s fie alocate pentru un anumit utilizatorilor, fiind bazat pe diferiti algoritmi
de alocare a resurselor. Prin urmare, planificatorul MAC joac un rol cheie n performana
sistemului.
Pentru LTE, 3GPP a definit o serie de valori standard QCI care reflect anumite seturi de
parametri QoS care pot fi atribuite la fluxurile de trafic prin activarea purttorii respective i

integrarea fluxurilor de trafic pentru aceste purttori. Deoarece QCI este un cmp de 8-bii,
acesta poate fi extins pentru a oferi 255 de seturi diferite de QoS.
Pentru planificarea resurselor fizice, planificatorul va verifica mai nti toate fluxurile
active, cele care au ca date ce trebuie transferate n buffer-ul RLC. Dac acest flux este activ,
atunci planificatorul verific eticheta de prioritate atribuita acestui flux. Bazat pe eticheta de
prioritate, planificatorul calculeaz metricile astfel nct cea mai mica mica valoare a tag-ului va
avea cea mai mare prioritate, respectiv metrica cea mai mare. Pe baza metricilor calculate,
planificatorul ia decizia de alocare a resurselor.
Pe downlink, LTE utilizeaza Orthogonal Frequency Division Multiple Access (OFDMA),
pentru a permite mai multor utilizatori sa imparta aceeai lime de band. Ideea din spatele
OFDMA este de a mpri un flux mare de date n mai multe fluxuri de date, ce pot fi transmise
de un numr mare de purttori. Fiecare purttoarea este modulat la o rat simbol sczut,
purtand un simbol al formatului modulatiei, cum ar fi Quadrature Phase-Shift Keying (QPSK),
16-QAM (quadrature amplitude modulation) sau 64-QAM pentru LTE. Aceste sub-purtatoare
sunt ortogonale, pentru a permite suprapunerea n domeniul de frecven, suprapunere foarte
benefic n termen de economisire a limii de band.

Figura 11: Suprapunerea sub-purtatorilor in OFDMA

Cu OFDMA, mai muli utilizatori pot partaja aceeai resurs att n frecven, cat i in
domeniul timp. n LTE, resursele retelei sunt mprite n mai multe blocuri de resurse msurate
n timp i domeniul frecven aa cum este ilustrat n figura urmatoare:

Figura 12: Alocarea resursepor pentur utilizatori folosind OFDMA

Din moment ce aceast cercetare are ca scop de a gsi o soluie care poate asigura cea
mai bun performan in prioritizarea traficului, trebuie s ne concentrm pe algoritmul de
planificare implementat la nivelul MAC.
n general , exist patru principali factori-cheie de design care ar trebui luati n
considerare in proiectarea mecanismelor de alocare a resurselor, dup cum urmeaz:
Complexitatea i scalabilitate: planificatorul de pachete LTE trebuie s ia
decizia de alocare la fiecare TTI(time transmission interval-1ms) . Prin urmare, complexitatea i
scalabilitatea sunt cerine fundamentale pentru limitarea timpului de procesare i utilizarea
memoriei. Folosind o complex procesare peste toate combinaiile posibile ar fi prea scump, n
termen de costuri de calcul i de timp. Fie N i R numrul de utilizatori activi n TTI-ul curent;
planificatorul trebuie s calculeze M = N * R metrici la fiecare TTI. Acest lucru asigur cerina
de scalabilitate, datorit dependenei liniare cu privire la numrul de blocuri de resurse i
utilizatori
eficien spectral : unul dintre obiectivele principale ale sistemului este de a
realiza utilizarea eficient a resurselor radio . De exemplu ,eficiena spectral poate fi atinsa prin
interogarea utilizatorilor care intalnesc cea mai bun calitate a canalului.
Corectitudine : corectitudine este o cerin major care ar trebui s fie luata n
considerare pentru a garanta eficienta minim utilizatorilor c intalnesc condiii de calitate
scazuta a canalului de transmisie
furnizarea QoS: QoS este o caracteristic major n arhitecturile full IP.
Constrngerile QoS pot varia n funcie de aplicaie i de obicei sunt mapate ntr-o serie de
parametri : rata de bii minima garantata, ntrzierea maxima oferita i rata de pierdere a
pachetelor (PLR-packet loss rate)
n scopul acestei cercetari, deoarece ar trebui s fie garantate diferite valori ale traficului
in functie de informatia transmisa, QoS este unul din cei mai importanti factori. Planificatorul de
pachete LTE ar trebui s acorde prioritate mai mare fluxurilor de date ce au nevoie de o prioritate
mai mare. Figura urmatoare ilustreaz o vedere generica a planificatorului MAC, care ia n
considerare informatiile din coada de downlink, informatiile calitatii canalului i o masuratoare a
traficului pentru luarea deciziei de alocare a resurselor.

Figura 13: Vizualizarea generica ca planificatorului MAC LTE

De fapt, exist mai multi algoritmi de planificare la nivel MAC care difer ntre ei in
functie de parametrii de intrare, obiective i servicii. Aceste modele de planificare pot fi
clasificate n cinci grupe majore: dependente de canalul de transmisie; dependente de canalul de
transmisie/independente de QoS; dependente de canalul de transmisie si de QoS; suport VoIP i
dependente de energia consumata.
Pentru primele dou grupuri , exist unele politici bine-cunoscute de planificare, cum ar
fi FIFO, Round Robin ( RR ) , Blind Egal Throughput, Weighted Fair Queuing care sunt
independente de canalul de transmisie; Maximum Throughput ( MT ) , Proportional Fair
Scheduler ( PF ) , Throughput de Averange ( TTA ) , Joint time and frequency domain
schedulers, Delay Sensitivity i Buffer-aware Schedulers care sunt dependente de canalul de
transmisie si independente de QoS. Avantajul mecanismelor de planificare independente de
canalui de transmisie este faptul ca acestea au un nivel ridicat de simplitate deoarece acestea nu
iau n considerare nici condiiile de canal , nici parametrii QoS n decizia de planificare.
Avantajul planificatoarelor dependente de canalul de transmisie/independente de QoS este, n
principal, eficien spectral , deoarece condiiile canalului radio sunt luate n considerare.
Pentru o mai buna planificare a traficului, trebuia luata in considerare folosirea
mecanismelor dependente de canalul de transmisie si de QoS. n LTE , QoS este asociat cu

purttorea i QCI(QoS Class Identifier) . Purttorea poate fi privita ca o combinaie a mai multor
cerine QoS ce sunt indicate de numrul QCI . Fiecare QCI este caracterizat de prioritate,
intrzierea pachetelor i rat acceptabil a pierderilor de pachete . Eticheta QCI pentru o
purttoare determin modul n care este manipulata n eNodeB . Tabelul urmator rezum valorile
de baz ale QCI-ului pentru definite niveluri de trafic ale retelei LTE . GBR (Guaranteed Bit
Rate) implic faptul c resursa dedicat retelei va fi alocata permanent atunci cnd se stabilete
acest tip de purttor.

Tabel 1: QoS Class Identifiers (QCIs) in LTE

Valorile QCI au fost definite iniial pentru a susine comunicaiile human-to-human; ca
urmare, n afar de semnalizare IMS, traficul de voce a fost asociat cu cea mai mare prioritate.
Cu toate acestea, atunci cnd se cere o mai mare prioritate pentru un anumit tip de trafic, se pot
redefini valorile QCI cu maxim prioritate atribuita acelui tip de trafic. Deoarece QCI este un
cmp de 8 bii, se poate genera 255 de valori diferite, care sunt suficiente pentru operator pentru
a specifica diferite tipuri de trafic.
5. Implementarea planificatoarelor de trafic folosind platform de simulare NS3 LTE
LENA
NS3 este un simulator de retele open-source, orientata n primul rnd pentru cercetare i
scopuri educaionale. Ca i predecesorul su NS2 , NS3 se bazeaz pe C++ pentru punerea n
aplicare a modelelor de simulare. Simularile retelelor n NS3 pot fi implementate doar in C++,
precum si Python. Un dezavantaj al NS3 este c acesta nu este compatibil cu versiunile
anterioare; unele simulari realizate in NS2 au fost doar portate in NS3.
Core-ul simularii NS3 ofera sprijin atat pentru retele IP i non-IP . Cu toate acestea,
marea majoritate a utilizatorilor si se concentreaza pe simulari wireless/IP care implic modele

de Wi-Fi, WiMAX sau LTE la nivelurile 1 i 2, precum i o varietate de protocoale de rutare

statice sau dinamice, cum ar fi OLSR i AODV pentru aplicaii bazate pe IP.
n cazul n care un simulator nu respect cu strictee un model de sistem real, acesta
devine foarte dificil in compararea rezultatelor i validarea modelului simulat. NS3 ncearc s
evite aproximri excesive de modele , astfel nct s aib module care pot fi refolosite n mod
eficient. Precum un PC care trebuie umplut cu hardware-ul i software-ul necesar, un nod n NS3
are nevoie de unul sau mai multe NIC-uri, care urmeaz s fie instalate, de crearea unei stive de
protocole IP i de pornirea unor aplicaii superioare.
Desi NS3 este un instrument de simulare foarte puternic, unele caracteristici i modele nu
sunt pe deplin complete i nu functioneaza in parametrii optimi, iar utilizatorii sunt rugai s se
adapteze nevoilor lor la caracteristicile implementate efectiv, sau de a extinde NS3 pe cont
propriu. Un lucru foarte bun despre software-ul open source este posibilitatea de a clona un
proiect i ncepe propria ramur, modificarea codului i adugarea de caracteristici. Ca urmare a
acestei noi idei experimentale, experimentul LTE numit LENA a fost dezvoltat de ctre CTTC.
Aceast ramur experimental se bazeaz pe dezvoltarea in NS3 a unui model mbuntit
pentru LTE, in comparatie cu cel original.

Figura 14: Arhitectura modelului de simulare LTE-EPC

Acest model include stiva de protocoale radio LTE (RRC, PDCP, RLC, MAC, PHY).
Aceste entiti au reedina n ntregime n cadrul UE-urilor i eNB-urilor. Modelul LENA LTE a
fost conceput pentru a sprijini evaluarea gestionarii resurselor radio, a planificarii de pachete,
coordonarea interferenei inter-celulare i accesul dinamic asupra spectrului. Pentru a permite o
evaluare corect a acestor aspecte, LENA a fost modelat lund n considerare urmtoarele
condiii:
La nivel radio , granularitatea modelului ar trebui s fie cel puin egal cu cea a unui
RB(resource block), care este unitatea fundamental utilizat pentru alocarea resurselor.
Planificarea pachetelor se face pe o baz RB-ului, astfel nct un eNB poate transmite doar pe un
subset a RB-urilor disponibile, care pot s interfereze cu alte eNB-uri ce transmit informatie pe

aceleai RB-uri; fara o astfel de granularitate ar fi imposibil de evitat interferenele intercelulare,

fiind imposibilia si planificarea de pachete. Acest lucru duce la adoptarea unei abordri de
simulare la nivel de sistem , care evalueaz alocarea de resurse doar la granularitatea stabilirii
conexiunii apel / purttor
Simulatorul fost destinat s permita zeci de eNB-uri i sute de UEs: aceasta exclude
utilizarea unui simulator la nivel de legtur fizica, n care interfeele radio sunt modelate cu o
granularitate pn la nivelul simbol, conducand la o complexitate de calcul foarte mare datorit
necesitatii de a implementa procesarea totala a semnalului de la nivel fizic (PHY) . De fapt ,
simulatoare la nivel de legtur sunt limitate n mod normal la un singur eNB i unul sau cteva
UEs .
Mai mult de o celul s-a considerat a fi prezenta ntr-o simulare,fiecare din acestea
trebuind s fie configurabila cu proprii ei parametrii, inclusiv frecvene purttoare; n plus
diferite limi de band utilizate de diferite eNB-uri trebuie lsate s se suprapun, sprijinind
astfel utilizarea unui spectru dinamic;
Pentru a fi ct mai aproape de implementrile reale, simulatorul ar trebui s utilizeze
planificatorul MAC API publicat de FemtoForum . Aceast interfa este utilizata de ctre
productori pentru punerea n aplicare a planificarii traficului i a algoritmilor de manangement
ai resurselor radio (RRM- Radio Resource Management), astfel nct productorii vor putea testa
echipamentele lor ntr-un scenariu stimulativ folosind aceleai algoritmi pe care i-ar folosi ntrun mediu real . API FemtoForum este doar o specificaie logica , iar punerea sa n aplicare este
lsat la aprecierea vendorilor. n LENA , modelul de simulare LTE are propria implementare a
API n C++.
Simulatorul ar trebui s fie utilizat pentru a reproduce fluxurile de pachete IP, dar cum
n planificarea resurselor LTE i in gestionarea resursemor radio nu funcioneaz direct cu
pachete IP, se foloseste mai degrab RLC-PDU, obinute prin segmentarea i nlnuirea de
pachete IP generate de entitile RLC. Astfel, funcionalitile RLC trebuie s fie modelate foarte
precis .
6. Modelul EPC
Acest model include interfeele reelei core, protocoalele i entitile utilizate la acest
nivel. Aceste entiti i protocoale se utilizeaza n nodurile S-GW, P-GW, MME i parial n
nodurile eNB. Funciile S-GW si P-GW sunt coninute ntr-un singur nod S-GW/P-GW, care
elimin necesitatea interfeelor S5 sau S8 specificate de 3GPP . Pe de alt parte, att pentru stiva
de protocoale S1-U, cat i pentru stiva de protocoale radio LTE, specificatiile date de 3GPP sunt
prezente.
Modelul EPC are mai multe criterii de proiectare :
singurul tip de PDN (packet data network) este IPv4 ;
funciile S-GW i P-GW sunt ncapsulate ntr -un singur nod, menionat ca nod
S-GW/P-GW ;
mobilitatea inter-celulara nu este pus n aplicare, prin urmare doar un singur
nod S-GW/P-GW este definit ;
orice standard in NS3 ce functioneaza peste TCP/UDP trebuie s lucreze cu
EPC, utilizandu-se astfel EPC pentru a simula performanele end-to-end ale unor aplicaii reale;

 este posibila definirea mai multor eNB-uri, fiecare dintre acestea cu propria
conexiune de backhaul, cu diferite capaciti; prin urmare, protocoalele planului de date ntre
eNBS i S-GW/P-GW trebuiesc modelate foarte precis;
este posibil ca un singur UE sa utiliezea diferite aplicaii cu cerine QoS diferite ,
astfel nct mai multe purtatoare EPS trebuie s fie
o modelare exacta a planului de date EPC este un scop principal, n timp ce
planul de control EPC este dezvoltat ntr-un mod simplist;
obiectivul principal pentru simulrile EPC este managementul utilizatorilor
activi n modul ECM , astfel nct toate funcionalitile care sunt relevante doar pentru ECM n
modul inactiv nu sunt modelate in totalitate
Modelul ar trebui s permit posibilitatea de a efectua un transfer pe interfata
X2 ntre dou eNB-uri
Figura urmatoare prezinta stiva protocoalelor LTE-EPC in planul de date asa cum a fost
implementata n modelul LENA simulat.

Figure 15: Stiva de protocoale LTE-EPC in planul de date

7. Planificatorul Round Robin

Planificatorul Round Robin (RR) mparte resursele retelei ntre fluxurile active, si anume
intre acele canale logice care au coada RLC nevida. n cazul n care numrul grupului de resurse
bloc (RBG- Resurse Block Group) este mai mare dect numrul de fluxuri active, tot debitul pot
fi alocat n aceeai sub-cadru. Altfel, dac numrul de fluxuri active este mai mare dect numrul

de RBGs, nu toate fluxurile pot fi programate ntr-un anumit sub-cadru; apoi, n urmtoarul subcadru de alocarea va ncepe de la ultimul flux care nu a fost alocat. Schema de modulare i
codare (MCS-Modulation and Coding Scheme), care urmeaz s fie adoptata pentru fiecare
utilizator se realizeaza n funcie de indicatia de banda data de CQI (Channel Quality Indication)
Figura urmatoare arat cum se utilizeaz interfeele Round Robin n eNodeB:

Figura 16: Interfata de planificare implementata in modelul de simulare

Exist 3 blocuri implicate n cadrul planificatorului MAC: blocul de control, blocul subcadru i blocul planificator. Primitivele din planificatorul MAC sunt grupate n dou grupe:
primitivele CSCHED, care se ocup cu configuraia planificatorului i primitivele SCHED, care
se ocup cu executia planificatorului.
Planificatorul Round Robin va atribui metricile pentru diferite fluxuri active bazat pe
eticheta de prioritate n aa fel nct fluxul cu valoarea prioritatii cea mai mic va avea cele mai
mari metrici. ntr-un sub-cadru, fluxurile cu cele mai mari valori ale metricii vor fi alocate
primului RBG(resource source group).

8. Simularea unei retele LTE in NS3

Modelul folosit ofer o implementare de baz a echipamentelor LTE, incluzand si modele
de propagare, precum si nivelele 1 si 2 ale retelei LTE (PHY si MAC). Datorit complexitii
standardului LTE, la momentul de fata nu este nc posibil simularea unei reele LTE complete.
In figura urmatoare este prezentata diagrama UML a principalelor clase de functii utilizate in
simularea retele LTE.

n definirea unui model particular wireless bazat pe framework-ul NS3::Spectrum, prima

etapa este caracterizata de definirea:
1. unui set de frecvene/canale pentru a utiliza nivelul fizic
2. semnalul generat la nivel fizic(PHY) i transportat prin canalul de transmisie
n acest scop, versiunile corespunztoare ale clasei Spectrum trebuie s fie dezvoltate cu
scopul de a defini poriuni ale spectrului de frecvene radio utilizate de tehnologia luata n
considerare, precum i granularitatea de reprezentare a lor. Astfel, se pot considera dou instante
Spectrumseparate, una pentru uplink (UL) i una pentru downlink (DL), cu scopul de a modela
spectrul asociat n care reteaua LTE opereaz n funcie de modul de divizare in frecventa (FDDFrequency Division Duplex). n prezent, modulul propus ofera un model de spectru, astfel: 19291980 MHz pentru UL i 2110-2170 MHz pentru DL. Clasa Spectrum este conceputa pentru a
descrie un set de sub-canale utilizate pentru transmisie. Deoarece n LTE resursele radio sunt
mprite n sub-canale de 180 kHz, se poate alege aceasta frecventa ca granularitate a modelului.
Mai mult dect att , clasa LteSpectrumValueHelper a fost dezvoltata pentru a face mai uora
crearea valorilor spectrului, corespunzatoare un anumit semnal, lund n considerare setul de
subcanale folosite pentru transmisie. n timpul simulrii , nivelul fizic utilizeaz aceast clas
pentru a crea instane SpectrumValue care reprezint densitatea de putere spectral (PSD-Power
Spectral Density) att pentru semnal, cat i zgomot . n interfata fizica au fost definite clasele de
baz SpectrumChannel i SpectrumPhy . Cel mai important rol al acestor clase este transmiterea
si receptia semnalelor.
Clasele UeLtePhy i EnbLtePhy reprezint stratul fizic al dispozitivelor UE i eNB. Ele
se motenesc din clasa LtePhy , care ofer funciile lor. Pentru a administra separat legaturile de
uplink i downlink, nivelul fizic al LTE a fost conceput ca un container de dou subsisteme
diferite de band de baz.Fiecare dintre aceste subsisteme este modelat de clasa LteSpectrumPhy,
care este apoi divizata n clasele UeLteSpectrumPhy i EnbLteSpectrumPhy. Modul de acces
FDD definete un set diferit de subcanale, att pentru uplink i downlink. O list a subcanale
disponibile pentru uplink i downlink sunt stocate n m_listOfUplinkSubchannel i
m_listOfDownlinkSubchannel, membre ale clasei LtePhy. Trebuie mentionat ca aceste seturi de
sub-canale trebuie s fie definite la nceputul simulrii. SendPacket( ) este punctul de intrare in
nivelul fizic, ocupandu-se de transmiterea pachetelor de pe canal. UE i eNB folosesc diferite
interfee fizice pentru transmiterea pachete.
Totodata, nivelul fizic este responsabil pentru transmiterea i primirea mesajelor de
control. n acest sens, se poate observa c modulul propus are ca obiectiv modelarea transmiterii
doar a datelor de utilizator. Ca urmare , pentru a limita complexitatea simulatorului i , prin
urmare, timpul de simulare, un canal de control ideal poate fi implementat. Acest lucru nseamn
c mesajele de control schimbate intre nodurile nu sunt atasate canalului i modelului de
propagare, i, prin urmare, ele sunt ntotdeauna primite n mod corect. Din punct de vedere al
implementrii, nivelul fizic livreaz mesajul la destinaie n mod direct. Un mesaj de control este
trimis folosind functia SendIdealControlMessage a clasei LtePhy . Functia
ReceiveIdealControlMessage a clasei LtePhy se ocup de primirea mesajului de control . n
funcie de tipul de mesaj , acesta ofer mesajul ctre entitatea adecvata pentru procesare.
Clasa EnbLtePhy modeleaza nivelul fizic al eNB-ului. Prima sarcin a acestei clase este
s se ocupe de transmiterea i recepionarea semnalelor de catre eNB. In acest sens, procedura de
transmitere se efectueaz prin StartTx (), functie downlink a clasei EnbSpectrumPhy, n timp ce
procedura de recepie este realizat de StartRx (), functie uplink a clasei EnbSpectrumPhy. La
sfritul recepiei, interfaa fizica:

1. estimeaz SINR-ul semnalului recepionat

2. ofer pachetele recepionate catredispozitiv.
Menionm faptul c nici o functie de control a erorilor nu este implementat n prezent;
Cu toate acestea, avnd n vedere c adaptarea legturii este modelata cu precizie, absena unei
functii de control a eroarii are un impact foarte limitat asupra acurateei de ansamblu a modelului.
Conform descrierii LTE, n domeniul timp resursele radio sunt atribuite la fiecare transmisie
intervalului de timp (TTI), care are o durat de 1 ms; 10 TTIs consecutive formeaza un cadru
LTE. Nivelul fizic al eNB-ului ocup nceputul i sfritul a dou cadre i sub-cadre, folosind
funciile StartFrame, StartSub-Frame, StopFrame i StopSubFrame. Se poate mentiona faptul
c funcia StartSubFrame declaneaz att functiile de planificare uplink i downlink.
Clasa UeLtePhy modeleaza nicelul fizic al UE-urilor. Aa cum am anticipat, ntr-un
sistem OFDMA/SC-FDMA de obicei doar un subset din resursele spectrului disponibil, att n
DL, cat i UL, este atribuit n mod normal la un UE la un moment dat. Alocarea se efectueaz de
ctre planificatorul MAC al eNB-ului pe un TTI. Pentru a pune n aplicare aceast alocare de
resurse per-utilizator, se folosesc variabilele m_subChannelsForTransmission i
m_subChannelsForReception din clasa LtePhy. Primul descrie o list de sub-canale uplink
atribuite de ctre planificatorul uplink pentru transmiterea pachetelor prin canalul direct. Cea de
a doua, n schimb, descrie o list de sub-canale alocate de planificatorul de pachete downlink
pentru transmitere. Aceste variabile sunt actualizate n fiecare TTI, n conformitate cu deciziile
de planificare. Atunci cnd UE-ul trebuie s transmit un pachet, acesta solicit
UeLtePhy::SendPacket (); aceasta la rndul su, ofer aceste pachete catre StartTx () ce apartine
instantei de uplink LTESpectrumPhy a UE, care are in vedere de dou sarcini: in primul rnd, se
creeaz instana SpectrumValue, care modeleaza semnalul ce va fi transmis, asumandu-si fiecare
sub-canal utilizat pentru transmisie. n acest scop, se folosete componenta
LteSpectrumValueHelper, lundu-se n considerare informaiile curpinse de variabila
m_subChannelsForTransmission, stocate n clasa UeLtePhy. n al doilea rnd, UE apeleaza
SpectrumChannel::StartTx () pentru a simula efectiv transmiterea semnalului pe canal.
Procedura de primire este efectuat de ctre StartRx () ce apartine instantei downlink
LTESpectrumPhy. La finalul procedurii de recepie, interfaa fizica:
1. calculeaz SINR-ul semnalului recepionat
2. transfer aceste valori la nivelul MAC pentru crearea feedback CQI
3. furnizeaz toate pachetele primite echipamentului destinatie
Modelul ce simuleaza pierderea propagarii(propagation loss model) propus pentru
interfaa E-UTRAN este alctuit din patru componente diferite: path loss, shadowing, multipath
i penetration loss, care sunt puse n inplementate folosind clasele PathLossModel,
JakesFadingLossModel, ShadowingLossModel i PenetrationLossModel. Toate aceste clase
sunt motenite din clasa DiscreteTimeLossModel, care ofer functii i variabile pentru toate
modelele de simulare a pierderii propagarii. Datorit naturii canalului depente de timp, toate
modelele ar trebui s fie actualizate periodic. n special, variabila m_samplingPeriod, definita n
clasa DiscreteTimeLossModel, descrie intervalul dintre dou actualizri consecutive ale
modelului. Aceast valoare ar trebui s fie stabilite lundu-se n considerare timpul de coeren a
canalului. Clasa ChannelRealization pune n aplicare o realizare a modelului de propagare
pentru o pereche UE-eNB, actionand ca un invelis pentru instantele tuturor componentelor
modelului de simulare a pierderilor. Clasa LteSpectrumPropagationLoss cuprinde toate funciile
modelului ce simuleaza pierderile prin propagare pentru un anumit spectru dat. Stocheaz toate

obiectele ChannelRealization ntr-un container std::map, unde fiecare realizare este identificata
prin pinteri la modelele de mobilitate ale perechii de noduri la care se refer. nainte de livrarea
pachetelor transmise catre toate instanele fizice atasate, SpectrumChannel utilizeaz functia
CalcRxPowerSpectralDensity () ce apartine clasei LteSpectrumPropagationLoss pentru
calcularea densitatii spectrale de putere a semnalului.
Dispozitivul LTE, modelat de clasa LteNetDevice, implementeaz clasa NetDevice
furnizata de NS-3. Pentru efectuarea tuturor functiilor dispozitivelor din NS3, aceasta conine i
gestioneaz principalele entiti ale stivei de protocoale e-UTRAN, precum RRC, RLC, MAC i
PHY. O multime de clase dedicate, UeLteNetDevice i EnbLteNetDevice, motenesc de la
LteNetDevice i implementeaza functiile specific a UE-ului i eNB-ului.
Deoarece cele mai multe dintre funcii sunt legate de eNB, implementarea UE-urilor este
simpla. UE stocheaz informaii despre eNB-ul la care adera; n acest scop, o variabil
m_targetEnb a fost definita. Aceast variabil ar trebui s fie stabilit la nceputul simulrii, prin
utilizarea functiei SetTargetEnb (). Aceasta este utilizat pentru a implementa canalul de control
amintit anterior.
eNB-ul are un rol esential in implementarea retelei e-UTRAN. Cea mai important
sarcin a eNB-ului este Managementul Resurselor Radio (RRM), care este efectuat
programatorul de resurse. eNB-ul foloseste componenta UE Manager pentru a gestiona UE-urile
n diverse operaii. In primul rand, folosind UE Manager, eNB invata toate UE-urile nregistrate.
Pentru fiecare dintre acestea, UE Record este creat i stocat n UE Manager. Este important de
retinut c UE Record este utilizat pentru a stoca informaii despre cele mai recente feedback-uri
CQI trimise de UE. Aceste informaii sunt utilizate de ctre planificatorul de pachete pentru a
aloca resurse pentru UE-urilor, lund n considerare condiiile canalului de transmisie.
n LTE, fluxurile de trafic ntre UE i eNB sunt grupate n entiti logice numite
purtatoare care sunt identificate de cerinele QoS corespunztoare.Clasa RadioBearerInstance
modeleaza purttoarea radio stabilita ntre UE i eNB, fiind stocata n variabila m_direction.
Fiecare purttor de radio este identificat printr-o pereche socket, de exemplu, sursa i destinaia
adresei IP, tipul de protocol de transport, precum i sursa si portul de destinatie. n scopul de a
gestiona aceast informaie, se va alege utilizarea clasei IpcsClassiferRecord. Clasa
BearerQoSParameters a fost conceputa pentru a reprezenta cerinele QoS asociate fiecrei
purttoare. Este o structur de date care deine parametrii ce caracterizeaz purtatoarele: (i)
m_bearerType, care descrie tipul purttoarei radio; (ii) clasa QoS m_qci care identific diferite
tratamente ce pot fi adoptate pentru fiecarepurtatoare; (iii) valoarea garantata a ratei de bit m_gbr,
care reprezint rata de bit a unei purtatoare GBR i (iv) m_mbr ce reprezint rata minim de bit
oferita purtatoarei GBR.
Entitatea RRC (Radio Resource Control) este implementata de clasa RrcEntity i ofer
doar funcionalitatea de gestionare a purtatoarei radio. Functia Classify a entitii RRC realizeaz
clasificarea pachetelor care vin de la un nivel superior la purtatoarea corespunzatoare. Aceast
clasificare se bazeaz pe informaiile furnizate de clas IpcsClassiferRecord. Clasa MacQueue
implementeaz coada MAC unde sunt stocate toate pachetele ce proven de la nivelul aplicaie i
care aparin unui anumite purtatoare radio. Clasa MacQueue implementeaz o politica de
management de tip First In First Out (FIFO). Interaciunea dintre MAC i purtatoarea radio este
asigurat de ctre entitatea RLC, care este implementata de clasa RlcEntity.
Clasa PacketScheduler definete interfaa pentru implementarea planificatorului MAC.
Planificatoarele de downlink si uplink implementate sunt introduse in eNB, prin stabilirea
variabilelor m_downlikScheduler i m_uplinkScheduler ale componentei EnbMacEntity.

Entitatea MAC, implementata de clasa MacEntity, ofer o interfa ntre dispozitiv i

nivelul fizic, att pentru UE, cat i eNB, iar clasa IdealControlMessage ofer suport pentru
simularea de mesaje de control generice pentru a fi trimise pe canalul de control; aceast clas va
fi extins pentru a pune n aplicare orice tip de mesaje de control. De exemplu, pentru a trimite
feedback CQI precum i informaii de control PDCCH, dou clase dedicate, i anume
CqiControlMessage i PdcchControlMessage, au fost dezvoltate.
9. Exemplu de simulare pentru planificatorul LTE
#include <iostream>
#include <sstream>
#include <string>
#include <ns3/object.h>
#include <ns3/spectrum-interference.h>
#include <ns3/spectrum-error-model.h>
#include <ns3/log.h>
#include <ns3/test.h>
#include <ns3/simulator.h>
#include <ns3/packet.h>
#include <ns3/ptr.h>
#include "ns3/radio-bearer-stats-calculator.h"
#include <ns3/constant-position-mobility-model.h>
#include <ns3/eps-bearer.h>
#include <ns3/node-container.h>
#include <ns3/mobility-helper.h>
#include <ns3/net-device-container.h>
#include <ns3/lte-ue-net-device.h>
#include <ns3/lte-enb-net-device.h>
#include <ns3/lte-ue-rrc.h>
#include <ns3/lte-helper.h>
#include "ns3/string.h"
#include "ns3/double.h"
#include <ns3/lte-enb-phy.h>
#include <ns3/lte-ue-phy.h>
#include <ns3/boolean.h>
#include <ns3/enum.h>
#include "ns3/point-to-point-epc-helper.h"
#include "ns3/network-module.h"
#include "ns3/ipv4-global-routing-helper.h"
#include "ns3/internet-module.h"
#include "ns3/applications-module.h"
#include "ns3/point-to-point-helper.h"
#include "lte-test-cqa-ff-mac-scheduler.h"
NS_LOG_COMPONENT_DEFINE ("LenaTestCqaFfMacScheduler");

using namespace ns3;

LenaTestCqaFfMacSchedulerSuite::LenaTestCqaFfMacSchedulerSuite ()
: TestSuite ("lte-cqa-ff-mac-scheduler", SYSTEM)
{
NS_LOG_INFO ("creating LenaTestCqaFfMacSchedulerSuite");
bool errorModel = false;
// General config
// Traffic: UDP traffic with fixed rate
// Token generation rate = traffic rate
// RLC header length = 2 bytes, PDCP header = 2 bytes
// Simulation time = 1.0 sec
// Throughput in this file is calculated in RLC layer
//Test Case 1: homogeneous flow test in CQA (same distance)
// DOWNLINK -> DISTANCE 0 -> MCS 28 -> Itbs 26 (from table 7.1.7.2.1-1 of 36.2 13)
// Traffic info
// UDP traffic: payload size = 200 bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 232000 byte/rate
// Totol bandwidth: 24 PRB at Itbs 26 -> 2196 -> 2196000 byte/sec
// 1 user -> 232000 * 1 = 232000 < 2196000 -> throughput = 232000 byte/sec
// 3 user -> 232000 * 3 = 696000 < 2196000 -> througphut = 232000 byte/sec
// 6 user -> 232000 * 6 = 139200 < 2196000 -> throughput = 232000 byte/sec
// 12 user -> 232000 * 12 = 2784000 > 2196000 -> throughput = 2196000 / 12 = 183000
byte/sec
// UPLINK -> DISTANCE 0 -> MCS 28 -> Itbs 26 (from table 7.1.7.2.1-1 of 36.2 13)
// 1 user -> 25 PRB at Itbs 26 -> 2292 -> 2292000 > 232000 -> throughput = 232000 bytes/sec
// 3 users -> 8 PRB at Itbs 26 -> 749 -> 749000 > 232000 -> throughput = 232000 bytes/sec
// 6 users -> 4 PRB at Itbs 26 -> 373 -> 373000 > 232000 -> throughput = 232000 bytes/sec
// 12 users -> 2 PRB at Itbs 26 -> 185 -> 185000 < 232000 -> throughput = 185000 bytes/sec
AddTestCase (new LenaCqaFfMacSchedulerTestCase1 (1,0,232000,232000,200,1,errorModel),
TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1 (3,0,232000,232000,200,1,errorModel),
TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1 (6,0,232000,232000,200,1,errorModel),
TestCase::EXTENSIVE);
//AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(12,0,183000,185000,200,1,errorModel));// simulation time = 1.5, otherwise, ul test will fail
// DOWNLINK - DISTANCE 4800 -> MCS 22 -> Itbs 20 (from table 7.1.7.2.1-1 of 36.213)
// Traffic info
// UDP traffic: payload size = 200 bytes, interval = 1 ms

// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 232000 byte/rate
// Totol bandwidth: 24 PRB at Itbs 20 -> 1383 -> 1383000 byte/sec
// 1 user -> 903000 * 1 = 232000 < 1383000 -> throughput = 232000 byte/sec
// 3 user -> 232000 * 3 = 696000 < 1383000 -> througphut = 232000 byte/sec
// 6 user -> 232000 * 6 = 139200 > 1383000 -> throughput = 1383000 / 6 = 230500 byte/sec
// 12 user -> 232000 * 12 = 2784000 > 1383000 -> throughput = 1383000 / 12 = 115250
byte/sec
// UPLINK - DISTANCE 4800 -> MCS 14 -> Itbs 13 (from table 7.1.7.2.1-1 of 36.213)
// 1 user -> 25 PRB at Itbs 13 -> 807 -> 807000 > 232000 -> throughput = 232000 bytes/sec
// 3 users -> 8 PRB at Itbs 13 -> 253 -> 253000 > 232000 -> throughput = 232000 bytes/sec
// 6 users -> 4 PRB at Itbs 13 -> 125 -> 125000 < 232000 -> throughput = 125000 bytes/sec
// after the patch enforcing min 3 PRBs per UE:
// 12 users -> 3 PRB at Itbs 13 -> 93 bytes * 8/12 UE/TTI -> 62000 < 232000 -> throughput =
62000 bytes/sec
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(1,4800,232000,232000,200,1,errorModel), TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(3,4800,232000,232000,200,1,errorModel), TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(6,4800,230500,125000,200,1,errorModel), TestCase::EXTENSIVE);
//AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(12,4800,115250,62000,200,1,errorModel)); // simulation time = 1.5, otherwise, ul test will fail
// DOWNLINK - DISTANCE 6000 -> MCS 20 -> Itbs 18 (from table 7.1.7.2.1-1 of 36.213)
// Traffic info
// UDP traffic: payload size = 200 bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 232000 byte/rate
// Totol bandwidth: 24 PRB at Itbs 18 -> 1191 -> 1191000 byte/sec
// 1 user -> 903000 * 1 = 232000 < 1191000 -> throughput = 232000 byte/sec
// 3 user -> 232000 * 3 = 696000 < 1191000 -> througphut = 232000 byte/sec
// 6 user -> 232000 * 6 = 1392000 > 1191000 -> throughput = 1191000 / 6 = 198500 byte/sec
// 12 user -> 232000 * 12 = 2784000 > 1191000 -> throughput = 1191000 / 12 = 99250
byte/sec
// UPLINK - DISTANCE 6000 -> MCS 12 -> Itbs 11 (from table 7.1.7.2.1-1 of 36.213)
// 1 user -> 25 PRB at Itbs 11 -> 621 -> 621000 > 232000 -> throughput = 232000 bytes/sec
// 3 users -> 8 PRB at Itbs 11 -> 201 -> 201000 < 232000 -> throughput = 201000 bytes/sec
// 6 users -> 4 PRB at Itbs 11 -> 97 -> 97000 < 232000 -> throughput = 97000 bytes/sec
// after the patch enforcing min 3 PRBs per UE:
// 12 users -> 3 PRB at Itbs 11 -> 73 bytes * 8/12 UE/TTI -> 48667 < 232000 -> throughput =
48667 bytes/sec
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(1,6000,232000,232000,200,1,errorModel), TestCase::EXTENSIVE);

AddTestCase (new LenaCqaFfMacSchedulerTestCase1

(3,6000,232000,201000,200,1,errorModel), TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(6,6000,198500,97000,200,1,errorModel), TestCase::EXTENSIVE);
//AddTestCase (new LenaCqaFfMacSchedulerTestCase1 (12,6000,99250,48667,200,1,
errorModel)); // simulation time = 1.5, otherwise, ul test will fail
// DOWNLINK - DISTANCE 10000 -> MCS 14 -> Itbs 13 (from table 7.1.7.2.1-1 of 36.213)
// Traffic info
// UDP traffic: payload size = 200 bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 232000 byte/rate
// Totol bandwidth: 24 PRB at Itbs 13 -> 775 -> 775000 byte/sec
// 1 user -> 903000 * 1 = 232000 < 775000 -> throughput = 232000 byte/sec
// 3 user -> 232000 * 3 = 696000 > 775000 -> througphut = 232000 byte/sec
// 6 user -> 232000 * 6 = 139200 > 775000 -> throughput = 775000 / 6 = 129166 byte/sec
// 12 user -> 232000 * 12 = 2784000 > 775000 -> throughput = 775000 / 12 = 64583 byte/sec
// UPLINK - DISTANCE 10000 -> MCS 8 -> Itbs 8 (from table 7.1.7.2.1-1 of 36.213)
// 1 user -> 24 PRB at Itbs 8 -> 437 -> 437000 > 232000 -> throughput = 232000 bytes/sec
// 3 users -> 8 PRB at Itbs 8 -> 137 -> 137000 < 232000 -> throughput = 137000 bytes/sec
// 6 users -> 4 PRB at Itbs 8 -> 67 -> 67000 < 232000 -> throughput = 67000 bytes/sec
// after the patch enforcing min 3 PRBs per UE:
// 12 users -> 3 PRB at Itbs 8 -> 49 bytes * 8/12 UE/TTI -> 32667 < 232000 -> throughput =
32667 bytes/sec
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(1,10000,232000,232000,200,1,errorModel), TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(3,10000,232000,137000,200,1,errorModel), TestCase::EXTENSIVE);
AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(6,10000,129166,67000,200,1,errorModel), TestCase::EXTENSIVE);
//AddTestCase (new LenaCqaFfMacSchedulerTestCase1
(12,10000,64583,32667,200,1,errorModel));// simulation time = 1.5, otherwise, ul test will fail
// Test Case 2: homogeneous flow test in CQA (different distance)
// Traffic1 info
// UDP traffic: payload size = 100 bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 132000 byte/rate
// Maximum throughput = 4 / ( 1/2196000 + 1/1191000 + 1/1383000 + 1/775000 ) = 1209046
byte/s
// 132000 * 4 = 528000 < 1209046 -> estimated throughput in downlink = 132000 byte/sec
std::vector<uint16_t> dist1;
dist1.push_back (0);
// User 0 distance --> MCS 28
dist1.push_back (4800); // User 1 distance --> MCS 22
dist1.push_back (6000); // User 2 distance --> MCS 20
dist1.push_back (10000); // User 3 distance --> MCS 14

std::vector<uint16_t> packetSize1;
packetSize1.push_back (100);
packetSize1.push_back (100);
packetSize1.push_back (100);
packetSize1.push_back (100);
std::vector<uint32_t> estThrCqaDl1;
estThrCqaDl1.push_back (132000); // User 0 estimated TTI throughput from CQA
estThrCqaDl1.push_back (132000); // User 1 estimated TTI throughput from CQA
estThrCqaDl1.push_back (132000); // User 2 estimated TTI throughput from CQA
estThrCqaDl1.push_back (132000); // User 3 estimated TTI throughput from CQA
AddTestCase (new LenaCqaFfMacSchedulerTestCase2
(dist1,estThrCqaDl1,packetSize1,1,errorModel), TestCase::QUICK);
// Traffic2 info
// UDP traffic: payload size = 200 bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> 232000 byte/rate
// Maximum throughput = 4 / ( 1/2196000 + 1/1191000 + 1/1383000 + 1/775000 ) = 1209046
byte/s
// 232000 * 4 = 928000 < 1209046 -> estimated throughput in downlink = 928000 / 4 = 230000
byte/sec
std::vector<uint16_t> dist2;
dist2.push_back (0);
// User 0 distance --> MCS 28
dist2.push_back (4800); // User 1 distance --> MCS 22
dist2.push_back (6000); // User 2 distance --> MCS 20
dist2.push_back (10000); // User 3 distance --> MCS 14
std::vector<uint16_t> packetSize2;
packetSize2.push_back (200);
packetSize2.push_back (200);
packetSize2.push_back (200);
packetSize2.push_back (200);
std::vector<uint32_t> estThrCqaDl2;
estThrCqaDl2.push_back (230000); // User 0 estimated TTI throughput from CQA
estThrCqaDl2.push_back (230000); // User 1 estimated TTI throughput from CQA
estThrCqaDl2.push_back (230000); // User 2 estimated TTI throughput from CQA
estThrCqaDl2.push_back (230000); // User 3 estimated TTI throughput from CQA
AddTestCase (new LenaCqaFfMacSchedulerTestCase2
(dist2,estThrCqaDl2,packetSize2,1,errorModel), TestCase::QUICK);
// Test Case 3: heterogeneous flow test in CQA
// UDP traffic: payload size = [100,200,300] bytes, interval = 1 ms
// UDP rate in scheduler: (payload + RLC header + PDCP header + IP header + UDP header)
* 1000 byte/sec -> [132000, 232000, 332000] byte/rate
// Maximum throughput = 3 / ( 1/2196000 + 1/1191000 + 1/1383000) = 1486569 byte/s
// 132000 + 232000 + 332000 = 696000 < 1486569 -> estimated throughput in downlink =
[132000, 232000, 332000] byte/sec

std::vector<uint16_t> dist3;
dist3.push_back (0); // User 0 distance --> MCS 28
dist3.push_back (4800); // User 1 distance --> MCS 22
dist3.push_back (6000); // User 2 distance --> MCS 20
std::vector<uint16_t> packetSize3;
packetSize3.push_back (100);
packetSize3.push_back (200);
packetSize3.push_back (300);
std::vector<uint32_t> estThrCqaDl3;
estThrCqaDl3.push_back (132000); // User 0 estimated TTI throughput from CQA
estThrCqaDl3.push_back (232000); // User 1 estimated TTI throughput from CQA
estThrCqaDl3.push_back (332000); // User 2 estimated TTI throughput from CQA
AddTestCase (new LenaCqaFfMacSchedulerTestCase2
(dist3,estThrCqaDl3,packetSize3,1,errorModel), TestCase::QUICK);
}
static LenaTestCqaFfMacSchedulerSuite lenaTestCqaFfMacSchedulerSuite;
// --------------- T E S T - C A S E # 1 ------------------------------

std::string
LenaCqaFfMacSchedulerTestCase1::BuildNameString (uint16_t nUser, uint16_t dist)
{
std::ostringstream oss;
oss << nUser << " UEs, distance " << dist << " m";
return oss.str ();
}

LenaCqaFfMacSchedulerTestCase1::LenaCqaFfMacSchedulerTestCase1 (uint16_t nUser,

uint16_t dist, double thrRefDl, double thrRefUl, uint16_t packetSize, uint16_t interval,bool
errorModelEnabled)
: TestCase (BuildNameString (nUser, dist)),
m_nUser (nUser),
m_dist (dist),
m_packetSize (packetSize),
m_interval (interval),
m_thrRefDl (thrRefDl),
m_thrRefUl (thrRefUl),
m_errorModelEnabled (errorModelEnabled)
{
}
LenaCqaFfMacSchedulerTestCase1::~LenaCqaFfMacSchedulerTestCase1 ()

{
}
void
LenaCqaFfMacSchedulerTestCase1::DoRun (void)
{
NS_LOG_FUNCTION (this << GetName ());
if (!m_errorModelEnabled)
{
Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));
}
Config::SetDefault ("ns3::LteHelper::UseIdealRrc", BooleanValue (true));
Ptr<LteHelper> lteHelper = CreateObject<LteHelper> ();
Ptr<PointToPointEpcHelper> epcHelper = CreateObject<PointToPointEpcHelper> ();
lteHelper->SetEpcHelper (epcHelper);
//LogComponentEnable ("CqaFfMacScheduler", LOG_DEBUG);
Ptr<Node> pgw = epcHelper->GetPgwNode ();
// Create a single RemoteHost
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr<Node> remoteHost = remoteHostContainer.Get (0);
InternetStackHelper internet;
internet.Install (remoteHostContainer);
// Create the Internet
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("Delay", TimeValue (Seconds (0.001)));
NetDeviceContainer internetDevices = p2ph.Install (pgw, remoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase ("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices);
// interface 0 is localhost, 1 is the p2p device
Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);
Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr<Ipv4StaticRouting> remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting
(remoteHost->GetObject<Ipv4> ());

remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask

("255.0.0.0"), 1);
//Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));
//Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));
//Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
//Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));
//Config::SetDefault ("ns3::LteEnbRrc::EpsBearerToRlcMapping", EnumValue
(LteHelper::RLC_UM_ALWAYS));
// LogComponentDisableAll (LOG_LEVEL_ALL);
//LogComponentEnable ("LenaTestCqaFfMacCheduler", LOG_LEVEL_ALL);
lteHelper->SetAttribute ("PathlossModel", StringValue
("ns3::FriisSpectrumPropagationLossModel"));
// Create Nodes: eNodeB and UE
NodeContainer enbNodes;
NodeContainer ueNodes;
enbNodes.Create (1);
ueNodes.Create (m_nUser);
// Install Mobility Model
MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (ueNodes);
// Create Devices and install them in the Nodes (eNB and UE)
NetDeviceContainer enbDevs;
NetDeviceContainer ueDevs;
lteHelper->SetSchedulerType ("ns3::CqaFfMacScheduler");
enbDevs = lteHelper->InstallEnbDevice (enbNodes);
ueDevs = lteHelper->InstallUeDevice (ueNodes);

Ptr<LteEnbNetDevice> lteEnbDev = enbDevs.Get (0)->GetObject<LteEnbNetDevice> ();

Ptr<LteEnbPhy> enbPhy = lteEnbDev->GetPhy ();
enbPhy->SetAttribute ("TxPower", DoubleValue (30.0));
enbPhy->SetAttribute ("NoiseFigure", DoubleValue (5.0));
// Set UEs' position and power
for (int i = 0; i < m_nUser; i++)
{

Ptr<ConstantPositionMobilityModel> mm = ueNodes.Get (i)>GetObject<ConstantPositionMobilityModel> ();

mm->SetPosition (Vector (m_dist, 0.0, 0.0));
Ptr<LteUeNetDevice> lteUeDev = ueDevs.Get (i)->GetObject<LteUeNetDevice> ();
Ptr<LteUePhy> uePhy = lteUeDev->GetPhy ();
uePhy->SetAttribute ("TxPower", DoubleValue (23.0));
uePhy->SetAttribute ("NoiseFigure", DoubleValue (9.0));
}
// Install the IP stack on the UEs
internet.Install (ueNodes);
Ipv4InterfaceContainer ueIpIface;
ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueDevs));
// Assign IP address to UEs
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr<Node> ueNode = ueNodes.Get (u);
// Set the default gateway for the UE
Ptr<Ipv4StaticRouting> ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ueNode>GetObject<Ipv4> ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}
// Attach a UE to a eNB
lteHelper->Attach (ueDevs, enbDevs.Get (0));
// Activate an EPS bearer on all UEs
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr<NetDevice> ueDevice = ueDevs.Get (u);
GbrQosInformation qos;
qos.gbrDl = (m_packetSize + 32) * (1000 / m_interval) * 8; // bit/s, considering IP, UDP,
RLC, PDCP header size
qos.gbrUl = (m_packetSize + 32) * (1000 / m_interval) * 8;
qos.mbrDl = 0;
qos.mbrUl = 0;
enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer bearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevice, bearer, EpcTft::Default ());
}
// Install downlind and uplink applications
uint16_t dlPort = 1234;
uint16_t ulPort = 2000;

PacketSinkHelper dlPacketSinkHelper ("ns3::UdpSocketFactory", InetSocketAddress

(Ipv4Address::GetAny (), dlPort));
PacketSinkHelper ulPacketSinkHelper ("ns3::UdpSocketFactory", InetSocketAddress
(Ipv4Address::GetAny (), ulPort));
ApplicationContainer clientApps;
ApplicationContainer serverApps;
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
++ulPort;
serverApps.Add (dlPacketSinkHelper.Install (ueNodes.Get (u))); // receive packets from
remotehost
serverApps.Add (ulPacketSinkHelper.Install (remoteHost)); // receive packets from UEs
UdpClientHelper dlClient (ueIpIface.GetAddress (u), dlPort); // uplink packets generator
dlClient.SetAttribute ("Interval", TimeValue (MilliSeconds (m_interval)));
dlClient.SetAttribute ("MaxPackets", UintegerValue (1000000));
dlClient.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
UdpClientHelper ulClient (remoteHostAddr, ulPort);
// downlink packets generator
ulClient.SetAttribute ("Interval", TimeValue (MilliSeconds (m_interval)));
ulClient.SetAttribute ("MaxPackets", UintegerValue (1000000));
ulClient.SetAttribute ("PacketSize", UintegerValue (m_packetSize));
clientApps.Add (dlClient.Install (remoteHost));
clientApps.Add (ulClient.Install (ueNodes.Get (u)));
}
serverApps.Start (Seconds (0.030));
clientApps.Start (Seconds (0.030));
double statsStartTime = 0.04; // need to allow for RRC connection establishment + SRS
double statsDuration = 0.5;
double tolerance = 0.1;
Simulator::Stop (Seconds (statsStartTime + statsDuration - 0.0001));
lteHelper->EnableRlcTraces ();
lteHelper->EnableMacTraces ();
Ptr<RadioBearerStatsCalculator> rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime", TimeValue (Seconds (statsStartTime)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Seconds (statsDuration)));
Simulator::Run ();
/**
* Check that the downlink assignation is done in a "token bank fair queue" manner
*/

NS_LOG_INFO ("DL - Test with " << m_nUser << " user(s) at distance " << m_dist);
std::vector <uint64_t> dlDataRxed;
for (int i = 0; i < m_nUser; i++)
{
// get the imsi
uint64_t imsi = ueDevs.Get (i)->GetObject<LteUeNetDevice> ()->GetImsi ();
// get the lcId
uint8_t lcId = 4;
uint64_t data = rlcStats->GetDlRxData (imsi, lcId);
dlDataRxed.push_back (data);
NS_LOG_INFO ("\tUser " << i << " imsi " << imsi << " bytes rxed " <<
(double)dlDataRxed.at (i) << " thr " << (double)dlDataRxed.at (i) / statsDuration << " ref " <<
m_thrRefDl);
}
for (int i = 0; i < m_nUser; i++)
{
NS_TEST_ASSERT_MSG_EQ_TOL ((double)dlDataRxed.at (i) / statsDuration,
m_thrRefDl, m_thrRefDl * tolerance, " Unfair Throughput!");
}
/**
* Check that the uplink assignation is done in a "round robin" manner
*/
NS_LOG_INFO ("UL - Test with " << m_nUser << " user(s) at distance " << m_dist);
std::vector <uint64_t> ulDataRxed;
for (int i = 0; i < m_nUser; i++)
{
// get the imsi
uint64_t imsi = ueDevs.Get (i)->GetObject<LteUeNetDevice> ()->GetImsi ();
// get the lcId
uint8_t lcId = 4;
ulDataRxed.push_back (rlcStats->GetUlRxData (imsi, lcId));
NS_LOG_INFO ("\tUser " << i << " imsi " << imsi << " bytes rxed " <<
(double)ulDataRxed.at (i) << " thr " << (double)ulDataRxed.at (i) / statsDuration << " ref " <<
m_thrRefUl);
}
for (int i = 0; i < m_nUser; i++)
{
NS_TEST_ASSERT_MSG_EQ_TOL ((double)ulDataRxed.at (i) / statsDuration,
m_thrRefUl, m_thrRefUl * tolerance, " Unfair Throughput!");
}
Simulator::Destroy ();

// --------------- T E S T - C A S E # 2 ------------------------------

std::string
LenaCqaFfMacSchedulerTestCase2::BuildNameString (uint16_t nUser, std::vector<uint16_t>
dist)
{
std::ostringstream oss;
oss << "distances (m) = [ " ;
for (std::vector<uint16_t>::iterator it = dist.begin (); it != dist.end (); ++it)
{
oss << *it << " ";
}
oss << "]";
return oss.str ();
}

LenaCqaFfMacSchedulerTestCase2::LenaCqaFfMacSchedulerTestCase2 (std::vector<uint16_t>
dist, std::vector<uint32_t> estThrCqaDl, std::vector<uint16_t> packetSize, uint16_t interval,bool
errorModelEnabled)
: TestCase (BuildNameString (dist.size (), dist)),
m_nUser (dist.size ()),
m_dist (dist),
m_packetSize (packetSize),
m_interval (interval),
m_estThrCqaDl (estThrCqaDl),
m_errorModelEnabled (errorModelEnabled)
{
}
LenaCqaFfMacSchedulerTestCase2::~LenaCqaFfMacSchedulerTestCase2 ()
{
}
void
LenaCqaFfMacSchedulerTestCase2::DoRun (void)
{
if (!m_errorModelEnabled)
{

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));
}
Config::SetDefault ("ns3::LteHelper::UseIdealRrc", BooleanValue (true));

Ptr<LteHelper> lteHelper = CreateObject<LteHelper> ();

Ptr<PointToPointEpcHelper> epcHelper = CreateObject<PointToPointEpcHelper> ();
lteHelper->SetEpcHelper (epcHelper);
Ptr<Node> pgw = epcHelper->GetPgwNode ();
// Create a single RemoteHost
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr<Node> remoteHost = remoteHostContainer.Get (0);
InternetStackHelper internet;
internet.Install (remoteHostContainer);
// Create the Internet
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("Delay", TimeValue (Seconds (0.001)));
NetDeviceContainer internetDevices = p2ph.Install (pgw, remoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase ("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices);
// interface 0 is localhost, 1 is the p2p device
Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);
Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr<Ipv4StaticRouting> remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting
(remoteHost->GetObject<Ipv4> ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask
("255.0.0.0"), 1);

// LogComponentDisableAll (LOG_LEVEL_ALL);
//LogComponentEnable ("LenaTestCqaFfMacCheduler", LOG_LEVEL_ALL);
lteHelper->SetAttribute ("PathlossModel", StringValue
("ns3::FriisSpectrumPropagationLossModel"));
// Create Nodes: eNodeB and UE

NodeContainer enbNodes;
NodeContainer ueNodes;
enbNodes.Create (1);
ueNodes.Create (m_nUser);
// Install Mobility Model
MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (ueNodes);
// Create Devices and install them in the Nodes (eNB and UE)
NetDeviceContainer enbDevs;
NetDeviceContainer ueDevs;
lteHelper->SetSchedulerType ("ns3::CqaFfMacScheduler");
enbDevs = lteHelper->InstallEnbDevice (enbNodes);
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr<LteEnbNetDevice> lteEnbDev = enbDevs.Get (0)->GetObject<LteEnbNetDevice> ();
Ptr<LteEnbPhy> enbPhy = lteEnbDev->GetPhy ();
enbPhy->SetAttribute ("TxPower", DoubleValue (30.0));
enbPhy->SetAttribute ("NoiseFigure", DoubleValue (5.0));
// Set UEs' position and power
for (int i = 0; i < m_nUser; i++)
{
Ptr<ConstantPositionMobilityModel> mm = ueNodes.Get (i)>GetObject<ConstantPositionMobilityModel> ();
mm->SetPosition (Vector (m_dist.at (i), 0.0, 0.0));
Ptr<LteUeNetDevice> lteUeDev = ueDevs.Get (i)->GetObject<LteUeNetDevice> ();
Ptr<LteUePhy> uePhy = lteUeDev->GetPhy ();
uePhy->SetAttribute ("TxPower", DoubleValue (23.0));
uePhy->SetAttribute ("NoiseFigure", DoubleValue (9.0));
}
// Install the IP stack on the UEs
internet.Install (ueNodes);
Ipv4InterfaceContainer ueIpIface;
ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueDevs));
// Assign IP address to UEs
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr<Node> ueNode = ueNodes.Get (u);
// Set the default gateway for the UE

Ptr<Ipv4StaticRouting> ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ueNode>GetObject<Ipv4> ());

ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}
// Attach a UE to a eNB
lteHelper->Attach (ueDevs, enbDevs.Get (0));
// Activate an EPS bearer on all UEs
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr<NetDevice> ueDevice = ueDevs.Get (u);
GbrQosInformation qos;
qos.gbrDl = (m_packetSize.at (u) + 32) * (1000 / m_interval) * 8; // bit/s, considering IP,
UDP, RLC, PDCP header size
qos.gbrUl = (m_packetSize.at (u) + 32) * (1000 / m_interval) * 8;
qos.mbrDl = qos.gbrDl;
qos.mbrUl = qos.gbrUl;
enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer bearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevice, bearer, EpcTft::Default ());
}

// Install downlind and uplink applications

uint16_t dlPort = 1234;
uint16_t ulPort = 2000;
PacketSinkHelper dlPacketSinkHelper ("ns3::UdpSocketFactory", InetSocketAddress
(Ipv4Address::GetAny (), dlPort));
PacketSinkHelper ulPacketSinkHelper ("ns3::UdpSocketFactory", InetSocketAddress
(Ipv4Address::GetAny (), ulPort));
ApplicationContainer clientApps;
ApplicationContainer serverApps;
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
++ulPort;
serverApps.Add (dlPacketSinkHelper.Install (ueNodes.Get (u))); // receive packets from
remotehost
serverApps.Add (ulPacketSinkHelper.Install (remoteHost)); // receive packets from UEs
UdpClientHelper dlClient (ueIpIface.GetAddress (u), dlPort); // uplink packets generator
dlClient.SetAttribute ("Interval", TimeValue (MilliSeconds (m_interval)));
dlClient.SetAttribute ("MaxPackets", UintegerValue (1000000));
dlClient.SetAttribute ("PacketSize", UintegerValue (m_packetSize.at (u)));

UdpClientHelper ulClient (remoteHostAddr, ulPort);

// downlink packets generator
ulClient.SetAttribute ("Interval", TimeValue (MilliSeconds (m_interval)));
ulClient.SetAttribute ("MaxPackets", UintegerValue (1000000));
ulClient.SetAttribute ("PacketSize", UintegerValue (m_packetSize.at (u)));
clientApps.Add (dlClient.Install (remoteHost));
clientApps.Add (ulClient.Install (ueNodes.Get (u)));
}
serverApps.Start (Seconds (0.030));
clientApps.Start (Seconds (0.030));
double statsStartTime = 0.04; // need to allow for RRC connection establishment + SRS
double statsDuration = 0.5;
double tolerance = 0.1;
Simulator::Stop (Seconds (statsStartTime + statsDuration - 0.0001));
lteHelper->EnableRlcTraces ();
Ptr<RadioBearerStatsCalculator> rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime", TimeValue (Seconds (statsStartTime)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Seconds (statsDuration)));
Simulator::Run ();
/**
* Check that the downlink assignation is done in a "token bank fair queue" manner
*/
NS_LOG_INFO ("DL - Test with " << m_nUser << " user(s)");
std::vector <uint64_t> dlDataRxed;
for (int i = 0; i < m_nUser; i++)
{
// get the imsi
uint64_t imsi = ueDevs.Get (i)->GetObject<LteUeNetDevice> ()->GetImsi ();
// get the lcId
uint8_t lcId = 4;
dlDataRxed.push_back (rlcStats->GetDlRxData (imsi, lcId));
NS_LOG_INFO ("\tUser " << i << " dist " << m_dist.at (i) << " imsi " << imsi << " bytes
rxed " << (double)dlDataRxed.at (i) << " thr " << (double)dlDataRxed.at (i) / statsDuration << "
ref " << m_estThrCqaDl.at (i));
}
for (int i = 0; i < m_nUser; i++)
{
NS_TEST_ASSERT_MSG_EQ_TOL ((double)dlDataRxed.at (i) / statsDuration,
m_estThrCqaDl.at (i), m_estThrCqaDl.at (i) * tolerance, " Unfair Throughput!");
}
Simulator::Destroy ();}