Tehnologia și arhitectura rețelei LTE [631584]

Tehnologia și arhitectura rețelei LTE
– Planificatoar e de resurse pentru reț elele LTE –
( LTE schedulers )
– Proiect cercetare semestrul II –

Coordonator: Student: [anonimizat] . Șerban Obreja Cosmin Tudorache

Master: TSAC II

Cuprins

1. Descrierea tehnica a unei retele LTE
2. Arhitectura retelei LTE
3. Arhitectura protocoalelor LTE
4. Planificatorul la nivel MAC
5. Implementarea planificatoarelor de trafic folosind platformă de simulare NS3 LTE LENA
6. Modelul EPC
7. Planificatorul Round Robin
8. Simularea unei retele LTE in NS3
9. Exemplu de simulare pentru planificatorul LTE

1. Descrierea tehnică a unei retele LTE

LTE este a patra generație (4G) a rețelelor de comunicații celulare , care a fost proiectat a
de o organizație de standardizare numit a Third Generation Partnership Project (3GPP) , fiind
cunoscut a ca 3GPP Long Term Evolution . LTE a evoluat de la bine-cunoscut ul 3G-Universal
Mobile Telecommunication System (UMTS), care, la rândul său, a evoluat de la dominant ul 2G
2G Global Systems for Mobile Communications.
LTE a fost dezvoltat pentru a îndeplini nevoia unei rețele de telecomunicați i in a suporta
cererea mare pentru traficul de date a servicii lor ce ocupa o lățime de bandă ridicata . O
măsură toare a traficului de voce și de date în rețelele de telecomunicații mobile din întreaga lume
realizat a de Ericsson a arătat că vocea nu mai era serviciul dominant în sistemele de comunicații
mobile .

Figura 1: Măsurătoare a traficului de voce și de date în rețelele de telecomunicații 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

Sisteme le de comunicații mobile tradițional e (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 dezvoltar ii internetului , utilizatorii de telefoane mobile au dorit ca device -urile lor le
permita accesul la a plicații bazate pe IP. Prin urmare , următoarele evoluții ale sistemelor de
comunicații mobile , cum ar fi GPRS , EDGE și UMTS 3G au permis comunicații cu comutare de
pachete . Odată cu dezvoltarea continuă a aplicațiilor mobile și cererea mare pentru serviciile de
date, evoluția de la UMTS 3G la 4G LTE se efectuează în conformitate cu viziunea că viitoarea
rețea de acces radio ar fi bazat a pe tehnologiile cu comutare de pachete .
Figura urmatoare prezinta evolutia arhitecturii rețelei GSM și UMTS in arhitectura LTE.
Există evoluții în ambele rețele de acces radio, cu noua interfață radio (SAE – System
architecture evolution ) și rețea core care este capabil a de a permite atât 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 – rețeaua EPC și domeniul serviciilor .
Conjunctia dintre SAE și LTE a introdus termenul de Evolved Packet System (EPS) în
sistemele de comunicații 4G. Rețelele de acces radio EPS și rețeaua 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

Echipament ul utilizatorului : de obicei echipamentul utilizator ului este dispozitivul
portabil care acceptă LTE pentru a permite accesul acestuia la serviciile de voce și de date . UE
conține SIM-ul pentru identificarea si autentificarea utilizatorului , cat si pentru a obține cheile de
securitate pentru prote cția transmisi ei prin interfața radio . UE oferă interfața cu utilizatorul final,
astfel încât aplicațiile client , cum ar fi VoIP , pot fi utilizat e pentru a configura un apel vocal .
E-UTRAN : rețeaua de acces LTE , E-UTRAN , este format a din una sau mai multe
eNodeB -uri, care sunt utilizate pentru a asigura transmisia și recepția de semnale pe interfața
radio . EnodeB -ul mosteneste functionalit atile atât ale RNC -ului, cat și NodeB -ului din
arhitecturile UMTS si RAN . Practic , eNodeB -ul implementează modulare a și demodulare
semnalelor , codificare a și decodificare a canalului de comunicatie , controlul resurselor radio și
gestionare a mobilității . EnodeB -ul , de asemenea, actioneaza ca o punte de nivel 2 între UE și
EPC. Funcționalitățile eNodeB -ului sunt reprezentat e î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 îmbunătățirea atât
a serviciilor de timp real , cat si cele n on-real-time prin facilitarea conexiunii IP end-to-end de la
UE la orice dispozitiv din rețea . În comparatie cu 3GPP , EPC cuprinde următoarele entități :

– Mobility Management Entity (MME): MME -ul este considerat principalul element
de control, fiind folosit pentru a procesa semnalizare a și funcții le de control între UE și EPC.
Figura urmatoare prezintă principalele funcții 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 rețea și de gestionare a mobilității sunt
principalele funcții ale MME -ului. În plus , acesta oferă autentificare si securitate , colectand
informații le utilizator ului de la HSS.
Serving Gateway (S-GW): funcția principală a S-GW-ului este de a susține mobilitatea
UE-ului, atunci când utilizatorul se deplasează de la un eNodeB la altul , sau în cazul în care UE
încearcă să lucreze în corelație cu rețele de comunicare 3GPP . Mai mult, S-GW-ul este utilizat
pentru a stoca temporar pachetele utilizator ului atunci când 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, acționand ca un punct terminal
pentru livrarea pachete lor de date ale utilizator ilor. P-GW-ul ofera, de asemenea , caracteristici de
aplicare a politicii și parametri lor QoS pentru fiecare utilizator în funcție de alocarea resurselor .
Principalele funcții 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 politici le de control si
acces pentru utilizatorii retelei p rin determinarea acces ului la resurse și limitarea utilizarii
acestora în funcție de profi l. PCRF -ul se conectează cu servicii le IMS (IP Multimedia Sub –
system) , prin intermediul interfeței RX, pentru a asigura accesul utilizatorilor la IMS.
Principalele funcții 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 mașina” 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 rețea 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ă informațiile abonatiilor , facilit and generarea de informații
de securitate de la utilizator . HSS poate fi considerat o combinație intre Home Location Register
(HLR) și Authentication Center (AuC).

3. Arhitectura protoco alelor LTE

Arhitectura protoco alelor LTE poate fi împărțită în două părți principale :
– planul de control : furnizeaza mesaje și proceduri pentru a sprijini fiecare
interfață in efectua rea funcțiile oferite
– planul de utiliz ator: poartă datele de utilizator ului 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 mobilitat ii UE-ului în cadrul sistemului , în timp ce al doilea este
folosit pentru a se ocup a 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 semnalizare a UE -urilor și conexiunilor de date si include funcții
pentru transfer (handover) .
 Packet Data Convergence Protocol (PDCP): Principalele funcții ale PDCP sunt
compresia antetului IP (UP), criptare a și protectia integritatii (numai CP).
 Radio Link Control (RLC): Protocolul RLC este responsabil pentru segmentarea
și concatenarea a PDCP -PDU s pentru transmisi a pe interfaț a radio. E fectuează, de asemenea, o
corectare a erorilor (ARQ – Automatic Repeat Request ).
 Medium Access Control (MAC): Nivelul MAC este responsabil pentru
programarea datelor în funcție de priorități și multiplexare a acestora blocuri de transport la nivel
1. Nivelul MAC oferă, de as emenea, de corectare a erorilor (Hybrid ARQ ).
 Physical Layer (PHY): Aceasta este nivelul 1 LTE -Uu, interfata radio, care are
grijă de funcții le nivelului DS-CDMA.

Toate pachetele IP pentru un UE sunt încapsulat e într-un protocol -EPC specific ,
formandu -se tuneluri între P-GW și eNodeB pentru transmiterea la UE . Protocoalele planului de
utilizator pentru transmitere a pachetelor de date sunt prezentate în urmatoarea figura:

Figura 10: S tiva de protocoale a planului de utilizator
Protocoalele interf etei radio la nivel acces sunt aceleași ca si la planul de control . Există
insa două protocoale adiționale , dupa cum urmează :
 GPRS Tunnelling Protocol , planul de utilizator (GTP -U): GTP -U este utilizat atunci
când S5/S8 este bazat pe GTP . GTP -U formează tunel ul GTP -U care este utilizat pentru a trimite
pachete IP pentru utilizatorul final , pachete ce aparțin unui purtător EPS. Este folosit în interfață
S1-U și este utilizat în S5/S8 daca CP folosește GTP -C.
 Generic Routing Encapsulation (GRE): GRE este folosit în interfața S5/S8 împreună cu
PMIP . GRE formează un tunel IP pentru a transporta toate datele care aparțin unei conexiun i
UE- anumit PDN . GRE este folosit direct in partea superioara a nivelului IP, UDP -ul nefiind
utilizat

Infrastructura de rețea LTE include toate dispozitivele hardware și protocoalele software
care au fost explicate anterior . În special, aceasta trebuie să conțină rețeaua radio LTE, care oferă
acces radio direct la dispozitivele U Es. Infrastructu ra de rețea LTE interconectează UEs prin
asigurarea de conexiuni pr in intermediul rețelei radio LTE și mentinerea unei conexiun i 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 când și cât de multe blocuri
de resurse ar trebui să fie alocate pentr u un anumit utilizatorilor , fiind bazat pe diferiti algoritmi
de alo care a resurs elor. Prin urmare , planificatorul MAC jo acă un rol cheie în performanț a
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 purtătorii respective și

integrarea fluxurilor de trafic pentru aceste purtători . Deoarece QCI este un câmp de 8 -biți,
acesta poate fi extins pentru a oferi 255 de seturi diferite de QoS .
Pentru planificarea resurse lor fizice , planificatorul va verifica mai întâi 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 atribuit a acestui flux. Bazat pe eticheta de
prioritate , planificatorul calculează metricile astfel încât 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 decizi a de alocare a resurselor .
Pe downlink , LTE utiliz eaza Orthogonal Frequency Division Multiple Access (OFDMA),
pentru a permite mai multor utilizatori sa imparta aceeași lățime de bandă . Ideea din spatele
OFDMA este de a împărți un flux mare de date în mai multe fluxuri de date , ce pot fi transmise
de un număr mare de purtători . Fiecare purtătoarea este modulată la o rată simbol scăzută ,
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 lățim ii de bandă .

Figur a 11: Suprapunerea sub -purtatorilor in OFDMA

Cu OFDMA , mai mulți utilizatori pot partaja aceeași resursă atât în frecvență , cat și in
domeniul timp . În LTE, resursele retelei sunt împărțite în mai multe blocuri de resurse măsurate
în timp și domeniul frecvență așa cum este ilustrat în figura urmatoare:

Figur a 12: Alocarea resursepor pentur utilizatori folosind OFDMA

Din moment ce această cercetare are ca scop de a găsi o soluție care poate asigura cea
mai bună performanță in prioritizare a traficului, trebuie să ne concentrăm pe algoritmul de
planificare imp lementat la nivelul MAC.
În general , există patru principal i factori -cheie de design care ar trebui luat i în
considerare in proiectarea mecanismelor de alocare a resurselor , după cum ur mează:
 Complexitatea și scalabilitate : planificatorul de pachete LTE trebuie să ia
decizia de alocare la fiecare TTI (time transmission interval -1ms) . Prin urmare , complexitate a și
scalabilitate a sunt cerințe fundamentale pentru limitarea timpului de procesare și utilizarea
memorie i. Folosind o complexă procesare peste toate combinațiile posibile ar fi prea scump, în
termen d e costuri de calcul și de timp . Fie N și R numărul de utilizatori activi în TTI -ul curent;
planificatorul trebuie să calculeze M = N * R metrici la fiecare TTI . Acest lucru asigură cerința
de scalabilitate , datorită dependenț ei liniar e cu privire la numărul de bloc uri de resurse și
utilizatori
 eficiență spectrală : unul di ntre obiectivele principale ale sistemului este de a
realiza utilizarea eficientă a resurselor radio . De exemplu ,eficiența spectrală poate fi atinsa prin
interogarea utilizatori lor care intalnesc cea mai bună calitate a canalului.
 Corectitudine : corectitudine este o cerință majoră care ar trebui să fie luat a în
considera re pentru a garanta eficienta minimă utilizatorilor că intalnesc condiții de calitate
scazuta a canal ului de transmisie
 furnizarea QoS: QoS este o caracteristi că majoră în arhitecturi le full IP .
Constrângeri le QoS pot varia în funcție de aplicație și de obicei sunt mapate într -o serie de
parametri : rata de biți minim a garantat a, întârzierea maxima oferita și rata de pierdere a
pachetelor ( PLR-packet loss rate )
În scopul acestei cercetari , deoarece ar trebui să fie garantat e diferite valori ale traficului
in functie de informatia transmisa , QoS este unul din cei mai important i factor i. 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 generi ca ca planificatorului MAC LTE

De fapt , există mai multi algoritmi de planificare la nivel MAC care diferă în tre ei in
functie de parametr ii 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 p lanificare, 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 . Avanta jul 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 condițiile de canal , nici parametri i QoS în decizia de planificare.
Avantaj ul planif icatoarelor dependente de canalul de transmisie/independente de QoS este, în
principal , eficiență spectrală , deoarece condițiile canal ului radio sunt luate în considerare .
Pentru o mai buna planificare a tra ficului, trebuia luata in considerare folosirea
mecanismelor dependente de canalul de transmisie si de QoS . În LTE , QoS este asociat cu

purtător ea și QCI(QoS Class Identifier) . Purtător ea poate fi privit a ca o combinație a mai multor
cerințe QoS c e sunt indicate de numărul QCI . Fiecare QCI este carac terizat de prioritate,
intârziere a pachete lor și rată acceptabilă a pierderi lor de pachete . Eticheta QCI pentru o
purtătoare determină modul în care este manipulat a î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 alocat a permanent atunci când se s tabilește
acest tip de purtător .

Tabel 1: QoS Class Identifiers (QCIs) in LTE

Valorile QCI au fost definite inițial pentru a susține comunicațiile 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 când se cere o mai mare prioritate pentru un anumit tip de tra fic, se pot
redefini valorile QCI cu maximă prioritate atribuita acelui tip de trafic . Deoarece QCI este un
câmp de 8 biți , 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, orientat a în primul rând pentru cercetare și
scopuri educaționale . Ca și predecesorul său 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 doa r portate in NS3.
Core -ul simularii NS3 ofera sprijin atat pentru retele IP și non-IP . Cu toate acestea ,
marea m ajoritate a utilizatorilor săi se concentre aza pe simulari wireless /IP care implică modele

de Wi -Fi, WiMAX sau LTE la nivelurile 1 și 2, precu m și o varietate de protocoale de rutare
statice sau dinamice , cum ar fi OLSR și AODV pentru aplicații bazate pe IP .
În cazul în care un simulator nu respectă cu st rictețe un model de sistem real , acesta
devine foarte dificil in compararea rezultatelor și validarea modelului simulat . NS3 încearcă să
evite aproximări excesive de modele , astfel încât să aibă module care po t 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 instalat e, de crearea unei stive de
protocol e IP și de pornirea unor aplicații superioare.
Desi NS3 este un instrument de simulare foarte puternic , unele caracteristici și modele nu
sunt pe deplin complet e și nu functioneaza in parametrii optimi , iar utilizatorii sunt rugați 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 adăugarea de caracteristici . Ca urmare a
acestei noi idei experimentale , experimentul LTE numit LENA a fost dezvoltat de către CTTC .
Această ramură experimentală se bazează pe dezvoltare a in NS3 a unui model îmbunătățit
pentru LTE, in comparatie cu cel origina l.

Figur a 14: Arhitectura modelului de simulare LTE -EPC

Acest model include stiva de protocoale radio LTE (RRC, PDCP , RLC , MAC , PHY ).
Aceste entități au reședința în întregime în cadrul UE-urilor și eNB-urilor . Modelul LENA LTE a
fost conceput pentru a sprijini evaluarea gestionar ii resurselor radio , a planificarii de pachete ,
coordonare a interferenț ei inter-celul are și acces ul dinamic asupra spectru lui. Pentru a permite o
evaluare corectă a acestor aspecte , LENA a fost modelat luând în considerare următoarele
condiții :
 La nivel radio , granularitatea modelul ui ar trebui să fie cel puțin egală cu cea a unui
RB(resource block), care este unitatea fundamentală utilizată pentru alocarea resurselor .
Planificarea pachet elor se face pe o bază RB -ului, astfel încât un eNB poate transmite doar pe un
subset a RB-urilor disponibile , care pot să interfereze cu alte eNB-uri ce transmit in formatie pe

aceleași RB -uri; fara o astfel de granularitate ar fi imposibil de evitat interferenț ele intercelulare,
fiind imposibilia si planificarea de pachete . Acest lucru duce la adoptarea unei abordări de
simulare la nivel de sistem , care evaluează al ocarea de resurse doar la granularitatea stabilirii
conexiunii apel / purtător
 Simulator ul fost destinat să permita zeci de eNB -uri și sute de UEs : aceasta exclude
utilizarea unui simulator la nivel de legătură fizica , în care interfețele radio sunt modelate cu o
granu laritate până la nivelul simbol , conducand la o complexitate de calcul foarte mare datorită
necesitat ii de a implementa procesarea totala a semnalului de la nivel fizic (PHY) . De fapt ,
simulatoare la nivel de legătură sunt limitate în mod normal la un singur eN B și un ul sau câteva
UEs .
 Mai mult de o celulă s -a considerat a fi prezent a într -o simulare,fiecare din acestea
trebuind să fie configurabil a cu proprii ei parametrii , inclusiv frecvențe purtătoare; în plus
diferite lățimi de b andă utilizate de diferite eNB-uri trebuie lăsat e să se suprapună , sprijinind
astfel utilizarea unui spectru dinamic ;
 Pentru a fi cât mai aproape de implementări le reale , simulatorul ar trebui să utilizeze
planificatorul MAC API publicat de FemtoForum . Această interfață este utilizat a de către
producători pentru punerea în aplicare a p lanificarii traficului și a algoritmilor de manangement
ai resurselor radio (RRM – Radio Resource Management) , astfel încât producătorii vor putea testa
echipamentele lor î ntr-un scenariu stimulativ folosind aceleași algor itmi pe care i -ar folosi într –
un mediu real . API FemtoForum este doar o specificație logic a , iar punerea sa în aplicare este
lăsată la aprecierea vendorilor . În LENA , modelul de simulare LTE are propri a implementare a
API în C++ .
 Simulatorul ar trebu i să fie utilizat pentru a reproduce fluxurile de pachete IP , dar cum
în planificarea resurselor LTE și in gestionarea resursemor radio nu funcționează direct cu
pachete IP, se foloseste mai degrabă RLC -PDU , obținut e prin segmentarea și înlănțuire a de
pachete IP generate de entitățile RLC . Astfel, funcționalități le RLC trebuie să fie modelate foarte
precis .

6. Modelul EPC

Acest model include interfețele rețelei core , protocoale le și entități le utilizate la acest
nivel . Aceste entități și protocoale se utilizeaza în nodurile S -GW, P -GW, MME și parțial în
nodurile eNB. Funcțiile S-GW si P-GW sunt conținute într -un singur nod S -GW/ P-GW, care
elimină necesitatea interfețelor S5 sau S8 specifi cate de 3GPP . Pe de altă parte , atât pentru stiva
de protocoale S1 -U, cat și pentru stiva de protocoale radio LTE, specifica tiile date de 3GPP sunt
prezente .
Modelul EPC are mai multe criterii de proiectare :
 singurul tip de PDN (packet data network) este IPv4 ;
 funcți ile S-GW și P -GW sunt încapsulate într -un singur nod , menționat ca nod
S-GW/ P-GW ;
 mobilitatea inter -celulara nu este pusă în aplicare, prin urmare doar un sing ur
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 pentr u a simula performanț ele end-to-end ale unor aplicații real e;

 este posibila definirea mai mult or eNB-uri, fiecare dintre acestea cu propria
conexiune de backhaul, cu diferite capacități ; prin urmare, protocoale le planului de date între
eNBS ș i S-GW/P -GW trebuiesc modelat e foarte precis ;
 este posibil ca un singur UE sa utilieze a diferite aplicații cu cerințe QoS di ferite ,
astfel încât mai multe purtatoare EPS trebuie să fie
 o model are exacta a planului de date EPC este un scop principal , în timp ce
planul de control EPC este dezv oltat într -un mod s implist ;
 obiectivul principal pentru simulări le EPC este managementul utilizatori lor
activi în modul ECM , astfel încât toate funcțio nalitățile 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
implementat a î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 numărul grupului de resurse
bloc (RBG – Resurse Block Group ) este mai mare decât numărul de fluxuri activ e, tot debitul pot
fi alocat în aceeași sub-cadru. Altfel , dacă numărul de fluxuri active este mai mare decât numărul

de RBGs , nu toate fluxurile pot fi programate într-un anumit sub-cadru ; apoi, în următoar ul sub-
cadru de alocare a va începe de la ultim ul flux care nu a fost alocat . Schema de m odulare și
codare (MCS -Modulation and Coding Scheme ), care urmează să fie adoptat a pentru fiecare
utilizator se realizeaza în funcție de indicatia de banda data de CQI (Channel Quality Indication)

Figura urmatoare arată cum se utilizează interfețe le 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 sub-
cadru și blocul planificator . Primitivele din planificatorul MAC sunt grupate în două grupe :
primitivele CSCHED , care se ocupă cu configurația planificatorului și primitivele SCHED , care
se ocupă cu executia planificatorului .
Planificatorul Round Robin va atribui metricile pentru diferite fluxuri activ e bazat pe
eticheta de prioritate în așa fel încât 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ă complexității
standardului LTE, la momentul de fata nu este încă posibilă simularea unei rețele LTE complet e.
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 , prim a
etapa este caracterizata de d efinirea:
1. unui set de frecvențe/ canale pentru a utiliza nivelul fizic
2. semnalul generat la nivel fizic( PHY ) și transportat prin canalul de transmisie
În acest scop , versiunile corespunzătoare ale clasei Spectrum trebuie să fie dezvoltate cu
scopul de a defini porțiuni ale spectrului de frecvențe rad io utilizate de tehnologia luata în
considerare , precum și granularitatea de reprezentare a lor. Astfel, se pot conside ra două instante
Spectrum separate, un a pentru uplink (UL ) și un a pentru downlink (DL) , cu scopul de a modela
spectrul asociat în care reteaua LTE operează în funcție de modul de diviza re in frecventa (FDD –
Frequency Division Duplex). În prezent , mod ulul propus ofera un model de spectru, astfel: 1929 –
1980 MHz pentru UL și 2110 -2170 MHz pentru DL . Clasa Spectrum este conceput a pentru a
descrie un set de sub -canale utilizate pentru transmisie. Deoarece în LTE resursele radio sunt
împărțite în sub -canale de 180 kHz, se poate alege aceasta frecventa ca granularitate a modelului .
Mai mult decât atât , c lasa LteSpectrumValue Helper a fost dezvoltat a pentru a face mai ușor a
crearea valorilor spectrului, corespun zatoare un anumit semnal , luând în considerare setul de
subcanale folosite pentru transmisie . În timpul simulării , nivelul fizic utilizează această clasă
pentru a crea instanțe SpectrumValue care reprezintă d ensitatea de putere spectrală (PSD -Power
Spectral Density ) atât pentru semnal , cat și zgomot . În interf ata fizica au fost definit e clasele de
bază SpectrumChannel și SpectrumPhy . Cel mai important rol al acestor cla se este transmiterea
si receptia semnale lor.
Clasele UeLtePhy și EnbLtePhy reprezintă stratul fizic al dispozitivelor UE și eNB. Ele
se moștenesc din clasa LtePhy , care oferă funcți ile lor . Pentru a administra separat legaturile de
uplink și downlink , nivelul fizic al LTE a fost conceput ca un container de două subsistem e
diferite de bandă de bază .Fiecare dintre aceste subsisteme este mo delat de clasa LteSpectrumPhy ,
care este apoi divizata în clasele UeLteSpectrumPhy și EnbLteSpectrumPhy . Modul de acces
FDD definește un set difer it de subcanale , atât pentru upl ink și downlink. O listă a sub canale
disponibile pentru uplin k ș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 simulării . SendPacket ( ) este punctul de intrare in
nivel ul fizic, ocupandu -se de tran smiterea pachetelor de pe canal . UE și eNB folosesc diferite
interfețe fizice pentru transmite rea pachete .
Totodata, nivelul fizic este responsabil pentru transmiterea ș i primirea mesajelor de
control . În acest se ns, se poate observa că modulul propus are ca obiectiv modelarea transmiter ii
doar a datelor de utilizator . Ca urmare , pentru a limita complexitatea simulator ului ș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 întotd eauna primite în mod corect . Din pu nct de vedere al
implementării, nivelul fizic livrează mesa jul la destinație în mod di rect. 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
funcție de tipul de mesaj , acesta oferă mesajul către entita tea adecvat a pentru procesare .
Clasa EnbLtePhy modeleaza nivelul fizic al eNB-ului. Prima sarcină a acestei clase este
să se ocupe de transmiterea și recepționarea semnalelor de catre e NB. In acest sens, procedura de
transmitere se efectuează prin StartTx (), functie downlink a clasei EnbSpectrumPhy , în timp ce
procedura de recepție este realizată de StartRx ( ), functie uplink a clasei EnbSpectrumPhy . La
sfârșitul recepție i, interfața fizica:

1. estimează SINR -ul semnalului recepționat
2. oferă pachetele recepționate catre dispozitiv.
Menționăm faptul că nici o functie de control a erorilor nu este implementată în prezent;
Cu toate acestea, având în vedere că adaptarea legăturii este modelat a cu precizie, absența unei
functii de control a eroari i are un impact foarte limitat asupra acurateței de ansamblu a modelului.
Conform descrierii LT E, în domeniul timp resursele radio sunt atribuite la fiecare transmisie
intervalului de t imp (TTI), care are o durată de 1 ms; 10 TTIs consecutive formeaza un c adru
LTE. Nivelu l fizic al eNB-ului ocupă începutul și sfârșitul a două cadre și sub -cadre, folosind
funciile StartFrame , StartSub -Frame , StopFrame și StopSubFrame . Se poate mentiona faptul
că funcția StartSubFrame declanșează atât functiile de planificare uplink și downlink .
Clasa UeLtePhy modeleaza nicelul fizic al UE-urilor . Așa cum am anticipat, într -un
sistem OFDMA /SC-FDMA de obicei doar un subset din resursele spectrului disponibil, atât în
DL, cat și UL , este atribuit în mod normal la un UE la un moment dat. Alocarea se efectuează de
către planificatorul MAC al eNB-ului pe un TTI. Pentru a pune în aplicare această alocare de
resurse per-utilizator, se foloses c variabilele m_subChannelsF orTransmission și
m_subChannelsF orReception din clasa LtePhy . Primul descrie o listă de sub -canale uplink
atribuite de către planificatorul uplink pentru transmiterea pachetelor prin canalul direct. Cea de
a doua, în schimb, descrie o listă de sub -canale alocate de planificatorul de pach ete downlink
pentru transmitere . Aceste variabile sunt actualizate în fiecare TTI, în conformitate cu deciziile
de planificare. Atunci când UE -ul trebuie să transmită un p achet, acesta solicită
UeLtePhy ::SendPacket () ; aceasta la râ ndul său, oferă aceste pachete catre StartTx () ce apartine
instantei de uplink LTESpectrumPhy a UE, care are in vedere de două sarcini: i n primul rând, se
creează instanța SpectrumValue , care modele aza semnalul ce va fi transmis, asum andu -si fiecare
sub-canal utilizat pentru tr ansmisi e. În acest scop, se foloseș te componenta
LteSpectrumValue Helper , luându -se în considerare informațiile curpinse de variabila
m_subChannelsF orTransmission , stocate în clasa UeLtePhy . În al doilea râ nd, UE apeleaza
SpectrumChannel:: StartTx () pentru a simula efectiv transmiterea semnalului pe canal.
Procedura de primire este efectuată de către StartRx () ce apartine instantei downlink
LTE SpectrumPhy . La finalul procedurii de recepție, interfața fizica:
1. calculează SINR -ul semnalului recepționat
2. transferă aceste valori la nivelul MAC pentru crearea feedback CQI
3. furni zează toate pachetele primite echipamentului destinatie

Modelul ce simuleaza pierderea propagarii(propagation loss model) propus pentru
interfața E -UTRAN este alcătuit 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 moșten ite din clasa Discrete TimeLossModel , care oferă functii și variabile pentru toate
modelele de simulare a pierderii propagarii . Datorită naturii canal ului depent e de timp, toate
modelele ar trebui să fie actualizate pe riodic. În special, variabila m_samplingPeriod , definit a în
clasa DiscreteTimeLossModel , descrie intervalul dintre două actualizări consecutive ale
modelului. Această valoare ar trebui să fie stabilite luându -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 fu ncțiile
modelului ce simuleaza pierderile prin propagare pentru un anumit spectru dat. S tochează toate

obiectele ChannelRealization într-un container std::map , unde fiecare realizare este identificat a
prin pinteri la modelele de mobilitate ale perechii de noduri la care se referă. Înainte de livrarea
pachetelor transmise catre toate instanțele fizice atasate , SpectrumChannel utilizează functia
CalcRxPowerSpectralDensity () ce apartine clasei LteSpectrumPropagationLoss pentru
calcul area densitat ii spectral e de putere a semnalului.
Dispozitivul LTE, model at de clasa LteNetDevice , implementează clasa NetDevice
furnizata de NS -3. Pentru efectuarea tuturor functiilor dispozitivelor din NS3, aceasta conține și
gestionează principalele entități ale stiv ei de protocoale e-UTRAN, precum RRC, RLC, MAC și
PHY. O multime de clase dedicate , UeLteNetDevice și EnbLteNetDevice , moștenesc de la
LteNetDevice și implementeaza functiile specific a UE -ului și eNB-ului.
Deoarece cele ma i multe dintre funcți i sunt legate de eNB, implementarea UE-urilor este
simpl a. UE stochează informații despre eNB -ul la care adera ; în acest scop, o variabilă
m_targetEnb a fost definit a. Această variabilă ar trebui să fie stabilit la începutul simulării, prin
utilizarea functiei SetT argetEnb () . 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 M anagementu l Resurselor Radio (RRM), care este efectu at
programatorul de resurse . eNB-ul foloseste componenta UE Manager pentru a gestiona UE -urile
în diverse operații . 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 informații despre cele mai recente feedback -uri
CQI trimise de UE. Aceste informații sunt utilizate de către planificatorul de pachete pentru a
aloca resurse pentru UE -urilor , luând în considerare condițiile canalului de transmisie .
În LTE, fluxurile de trafic între UE și eNB sunt grupate în entități logice numite
purtatoare care sunt identificate de cerințele QoS core spunzătoare. Clasa RadioBearerInstance
modeleaza p urtăto area r adio stabilit a între UE și eNB , fiind stocat a în variabila m_direction .
Fiecare purtător de radio este identificat printr -o pereche socket, de exemplu, sursa și destinația
adres ei IP, tipul de protocol de transport, precum și sursa si portul de destinatie. În scopul de a
gestiona această informație, se va alege utilizarea clasei IpcsClassiferRecord . Clasa
BearerQoSParameters a fost conceput a pentru a reprezenta cerințele QoS asocia te fiecăr ei
purtăto are. Este o structură de date care deține parametri i ce caracterizează purtatoarele : (i)
m_bearerType , care descrie tipul purtăto arei radio ; (ii) clasa QoS m_qci care identifică d iferite
tratament e ce pot fi adoptate pentru fiecarepurtatoare; (iii) valoarea garantat a a ratei de bi t m_gbr ,
care reprezintă rata de bit a unei purtatoare GBR și (iv) m_mbr c e reprezintă rata minimă de bit
oferita purtatoarei GBR.
Entitatea RRC (Radio Resource Control) este implementat a de clasa RrcEntity și oferă
doar funcționalitatea de gestionare a purtatoarei radio . Functia Classify a entității RRC realizează
clasificarea pachetelor care vin de la un nivel superior la purtatoarea corespunzatoare. A ceastă
clasificare se bazează pe informațiil e furnizate de clasă IpcsClassif erRecord . Clasa MacQueue
implementează coada MAC unde sunt stocate toate pachetele ce proven de la nivelul aplicație și
care aparțin unui anumit e purtatoare radio . Clasa MacQueue implementează o pol itica de
management de tip First In First Out (FIFO ). Interacțiunea dintre MAC și purtatoarea radio este
asigurată de către entitatea RLC, care este implementat a de clasa RlcEntity .
Clasa PacketScheduler definește interfața pentru implementarea planificatorului MAC .
Planificatoarele de downlink si uplink implementate sunt introduse in eNB, prin stabilirea
variabilelor m_downlikScheduler și m_up linkScheduler ale componentei EnbMacEntity .

Entitatea MAC, implementat a de clasa MacEntity , oferă o interfață între dispozitiv și
nivelul fizic, atât pentru UE , cat și eNB, iar c lasa 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 aplic are orice tip de mesaje de control. De exemplu, pentru a trimite
feedback CQI precum și informații 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>
#includ e <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
// Toto l 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 < 219600 0 -> 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,20 0,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 t ime = 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 -> through put = 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), Tes tCase::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, othe rwise, 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 heade r + 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 LenaC qaFfMacSchedulerTestCase1
(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
// Tot ol 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 en forcing 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 LenaCqaF fMacSchedulerTestCase1
(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, int erval = 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 fro m 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);
packetSiz e2.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 TT I 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,packet Size2,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 t hroughput 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 l enaTestCqaFfMacSchedulerSuite;

// ––––– 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, di stance " << 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)
{
}

LenaCqaFf MacSchedulerTestCase1::~LenaCqaFfMacSchedulerTestCase1 ()

{
}

void
LenaCqaFfMacSchedulerTestCase1::DoRun (void)
{
NS_LOG_FUNCTION (this << GetName ());

if (!m_errorModelEnabled)
{
Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnab led", 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 si ngle RemoteHost
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr<Node> remoteHost = remoteHostContainer.Get (0);
InternetStackHelper internet;
internet.Install (remoteHostContainer);

// Create the Internet
PointToPointH elper 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<LteEnb Phy> 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> uePh y = 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, enbD evs.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; // b it/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", I netSocketAddress
(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 packe ts 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 << " u ser(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::st ring
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.Crea te (1);
Ptr<Node> remoteHost = remoteHostContainer.Get (0);
InternetStackHelper internet;
internet.Install (remoteHostContainer);

// Create the Internet
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("10 0Gb/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;
Node Container ueNodes;
enbNodes.Create (1);
ueNodes.Create (m_nUser);

// Install Mobility Model
MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (enbNodes);
mobility.SetMobilityModel ("n s3::ConstantPositionMobilityModel");
mobility.Install (ueNodes);

// Create Devices and install them in the Nodes (eNB and UE)
NetDeviceContainer enbDevs;
NetDeviceContainer ueDevs;
lteHelper ->SetSchedulerType ("ns3::CqaFfMacScheduler");
enbDev s = 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<Co nstantPositionMobilityModel> ();
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 ("TxPow er", 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> ueSt aticRouting = 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, c onsidering 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::UdpSocketF actory", 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 (Second s (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 ->EnableRlcTrace s ();
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 << " dis t " << 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_E Q_TOL ((double)dlDataRxed.at (i) / statsDuration,
m_estThrCqaDl.at (i), m_estThrCqaDl.at (i) * tolerance, " Unfair Throughput!");
}

Simulator::Destroy ();}