ns-3-modelbibliotheek - Online in de cloud

PROGRAMMA:

NAAM

ns-3-modelbibliotheek - ns-3-modelbibliotheek

Dit is de ns-3 Model Bibliotheek documentatie. Primaire documentatie voor het ns-3-project
is beschikbaar in vijf vormen:

· ns-3 zuurstofoxy: Documentatie van de openbare API's van de simulator

· Zelfstudie, handleiding en modelbibliotheek (deze document) voor de laatste los en
ontwikkeling boom

· ns-3 wiki

Dit document is geschreven in reStructuredText voor Sfinx en wordt onderhouden in de
doc/modellen directory van de broncode van ns-3.

ORGANISATIE

Deze handleiding stelt documentatie samen voor ns-3 modellen en ondersteunende software die het mogelijk maken
gebruikers om netwerksimulaties te bouwen. Het is belangrijk om onderscheid te maken tussen modules
en modellen:

· ns-3 software is georganiseerd in afzonderlijke modules die elk afzonderlijk zijn gebouwd
software bibliotheek. Individuele ns-3-programma's kunnen de modules (bibliotheken) die ze nodig hebben, koppelen
om hun simulatie uit te voeren.

· ns-3 modellen zijn abstracte representaties van real-world objecten, protocollen, apparaten, etc.

An ns-3 module kan uit meer dan één model bestaan ​​(bijvoorbeeld de internet module
bevat modellen voor zowel TCP als UDP). Over het algemeen omvatten ns-3-modellen niet meerdere
softwaremodules wel.

Deze handleiding bevat documentatie over de modellen van ns-3. Het is een aanvulling op twee andere
documentatiebronnen betreffende modellen:

· de model-API's zijn gedocumenteerd, vanuit programmeerperspectief, met behulp van zuurstofoxy. zuurstof
voor ns-3 modellen is beschikbaar on the project web server.

· de ns-3 core is gedocumenteerd in de handleiding voor ontwikkelaars. ns-3 modellen maken gebruik van de
voorzieningen van de kern, zoals attributen, standaardwaarden, random numbers, test
kaders, enz. Raadpleeg de hoofd- web website om kopieën van de handleiding te vinden.

Tot slot aanvullende documentatie over verschillende aspecten van ns-3 kan bestaan ​​op de project
wiki.

Een voorbeeldoverzicht van het schrijven van modelbibliotheekdocumentatie kan worden gevonden door het
create-module.py programma en kijken naar de sjabloon die in het bestand is gemaakt
nieuwe-module/doc/nieuwe-module.rst.

$ cd src
$ ./create-module.py nieuwe-module

De rest van dit document is alfabetisch geordend op modulenaam.

Als je nieuw bent bij ns-3, wilt u misschien eerst hieronder lezen over de netwerkmodule, welke
bevat enkele fundamentele modellen voor de simulator. Het pakketmodel, modellen voor
verschillende adresformaten en abstracte basisklassen voor objecten zoals knooppunten, net
daar komen apparaten, kanalen, sockets en applicaties aan bod.

ANIMATION

Animatie is een belangrijk hulpmiddel voor netwerksimulatie. Terwijl ns-3 bevat geen
standaard grafische animatietool, hebben we momenteel twee manieren om animatie aan te bieden, namelijk
met behulp van de PyViz-methode of de NetAnim-methode. De PyViz-methode wordt beschreven in
http://www.nsnam.org/wiki/PyViz.

We zullen de NetAnim-methode hier kort beschrijven.

NetAnim
NetAnim is een op zichzelf staand, op Qt4 gebaseerd uitvoerbaar softwarebestand dat gebruikmaakt van een gegenereerd traceerbestand
tijdens een ns-3 simulatie om de topologie weer te geven en de pakketstroom ertussen te animeren
knooppunten.
[afbeelding] Een voorbeeld van pakketanimatie op bedrade links.UNINDENT

Daarnaast biedt NetAnim ook handige functies zoals tabellen om metadata weer te geven
van pakketten zoals de afbeelding hieronder
[afbeelding] Een voorbeeld van tabellen voor pakketmetadata met protocolfilters.UNINDENT

Een manier om het traject van een mobiel knooppunt te visualiseren
[afbeelding] Een voorbeeld van het traject van een mobiel knooppunt.UNINDENT

Een manier om de routeringstabellen van meerdere knooppunten op verschillende tijdstippen weer te geven
[foto]

Een manier om tellers die aan meerdere knooppunten zijn gekoppeld weer te geven als een grafiek of een tabel
[foto]
[foto]

Een manier om de tijdlijn van pakketverzend- en ontvangstgebeurtenissen te bekijken
[foto]

Methodologie
De klasse ns3::AnimationInterface is verantwoordelijk voor het maken van het traceer XML-bestand.
AnimationInterface gebruikt de traceringsinfrastructuur om pakketstromen tussen knooppunten te volgen.
AnimationInterface registreert zichzelf als een traceerhaak voor tx- en rx-gebeurtenissen vóór de
simulatie begint. Wanneer een pakket is gepland voor verzending of ontvangst, wordt het
corresponderende tx en rx trace hooks in AnimationInterface worden aangeroepen. Wanneer de rx haakt
worden aangeroepen, zal AnimationInterface op de hoogte zijn van de twee eindpunten waartussen een pakket
is gestroomd en voegt deze informatie toe aan het traceerbestand, in XML-indeling, samen met het
overeenkomstige tx- en rx-tijdstempels. Het XML-formaat wordt later besproken.
Het is belangrijk op te merken dat AnimationInterface alleen een pakket registreert als de rx trace
haken worden genoemd. Elke tx-gebeurtenis moet gepaard gaan met een rx-gebeurtenis.

Downloaden NetAnim
Als NetAnim nog niet beschikbaar is in de ns-3 pakket dat u hebt gedownload, kunt u het
volgende:

Zorg ervoor dat u mercurial hebt geïnstalleerd. De nieuwste versie van NetAnim kan zijn
gedownload met mercurial met de volgende opdracht:

$ hg-kloon http://code.nsnam.org/netanim

Gebouw NetAnim
Voorwaarden
Qt4 (4.7 en hoger) is vereist om NetAnim te bouwen. Dit kan worden verkregen met behulp van het volgende
manieren:

Voor Debian/Ubuntu Linux-distributies:

$ apt-get install qt4-dev-tools

Voor op Red Hat/Fedora gebaseerde distributie:

$ yum installeer qt4
$ jammie installeer qt4-devel

Voor Mac/OSX, zie http://qt.nokia.com/downloads/

Bouw stappen
Gebruik de volgende opdrachten om NetAnim te bouwen:

$ cd netanim
$ maak schoon
$ qmake NetAnim.pro (voor MAC-gebruikers: qmake -spec macx-g++ NetAnim.pro)
$ Make

Opmerking: qmake kan in sommige systemen "qmake-qt4" zijn

Dit zou een uitvoerbaar bestand met de naam "NetAnim" in dezelfde map moeten maken:

$ls -l NetAnim
-rwxr-xr-x 1 john john 390395 2012-05-22 08:32 NetAnim

Gebruik
Het gebruik van NetAnim is een proces in twee stappen

Stap 1: Genereer het animatie-XML-traceerbestand tijdens simulatie met behulp van
"ns3::AnimationInterface" in de ns-3 codebasis.

Stap 2: Laad het XML-traceerbestand gegenereerd in stap 1 met de offline op Qt4 gebaseerde animator
genaamd NetAnim.

Stap voor 1: Genereer een XML animatie opsporen filet
De klasse "AnimationInterface" onder "src/netanim" gebruikt onderliggende ns-3 bronnen traceren
maak een ASCII-bestand met tijdstempel in XML-indeling.

Voorbeelden zijn te vinden onder src/netanim/examples Voorbeeld:

$ ./waf -d debug configure --enable-voorbeelden
$ ./waf --run "halter-animatie"

Het bovenstaande maakt een XML-bestand dumbbell-animation.xml aan

Verplicht
1. Zorg ervoor dat het wscript van uw programma de module "netanim" bevat. Een voorbeeld van zo'n
wscript staat op src/netanim/examples/wscript.

2. Neem de header [#include "ns3/netanim-module.h"] op in je testprogramma

3. Voeg de verklaring toe

AnimationInterface anim ("animatie.xml"); // waarbij "animation.xml" een willekeurige bestandsnaam is

[voor versies vóór ns-3.13 moet u ook de regel "anim.SetXMLOutput() gebruiken om de
XML-modus en gebruik ook anim.StartAnimation();]

optioneel
De volgende zijn optionele maar nuttige stappen:

// Stap 1
anim.SetMobilityPollInterval (seconden (1));

AnimationInterface registreert standaard elke 250 ms de positie van alle knooppunten. De
verklaring hierboven stelt het periodieke interval in waarmee AnimationInterface de
positie van alle knooppunten. Als de nodes naar verwachting weinig zullen bewegen, is het handig om in te stellen
een poll-interval met hoge mobiliteit om grote XML-bestanden te vermijden.

// Stap 2
anim.SetConstantPosition (Ptr< Knooppunt > n, dubbel x, dubbel y);

AnimationInterface vereist dat de positie van alle knooppunten wordt ingesteld. In ns-3 dit wordt gedaan door
het instellen van een bijbehorend MobilityModel. "SetConstantPosition" is een snelle manier om de xy in te stellen
coördinaten van een knooppunt dat stilstaat.

// Stap 3
animatie.SetStartTime (seconden(150)); en animatie.SetStopTime (seconden(150));

AnimationInterface kan grote XML-bestanden genereren. De bovenstaande verklaringen beperken het venster
waartussen AnimationInterface tracering doet. Het beperken van het venster dient alleen om scherp te stellen
op relevante delen van de simulatie en het maken van beheersbare kleine XML-bestanden

// Stap 4
AnimationInterface-anim ("animation.xml", 50000);

Het gebruik van de bovenstaande constructor zorgt ervoor dat elk XML-traceerbestand voor animaties slechts 50000
pakketten. Als AnimationInterface bijvoorbeeld 150000 pakketten vastlegt, gebruikt u het bovenstaande
constructor splitst de opname in 3 bestanden

· animatie.xml - bevat het pakketbereik 1-50000

· animatie.xml-1 - bevat het pakketbereik 50001-100000

· animatie.xml-2 - bevat het pakketbereik 100001-150000

// Stap 5
anim.EnablePacketMetadata (waar);

Met de bovenstaande verklaring registreert AnimationInterface de metadata van elk pakket in de
xml-tracebestand. Metadata kunnen door NetAnim worden gebruikt om betere statistieken en filters te bieden,
samen met wat korte informatie over het pakket, zoals het TCP-volgnummer
of bron- en bestemmings-IP-adres tijdens pakketanimatie.

LET OP: Als u deze functie inschakelt, krijgt u grotere XML-traceerbestanden. Doe alstublieft niet
schakel deze functie in wanneer u Wimax-links gebruikt.

// Stap 6
anim.UpdateNodeDescription (5, "Toegangspunt");

Met de bovenstaande verklaring wijst AnimationInterface de tekst "Access-point" toe aan knooppunt 5.

// Stap 7
anime.UpdateNodeSize (6, 1.5, 1.5);

Met de bovenstaande verklaring stelt AnimationInterface de knooppuntgrootte in op schaal met 1.5. NetAnim
schaalt automatisch de grafische weergave om te passen bij de grenzen van de topologie. Dit betekent
dat NetAnim de grootte van een knooppunt abnormaal te hoog of te laag kan schalen. Gebruik makend van
AnimationInterface::UpdateNodeSize stelt u in staat om de standaard schaling in NetAnim te overschrijven
en gebruik uw eigen aangepaste schaal.

// Stap 8
anime.UpdateNodeCounter (89, 7, 3.4);

Met de bovenstaande verklaring stelt AnimationInterface de teller in met Id == 89, geassocieerd
met Knooppunt 7 met de waarde 3.4. De teller met Id 89 wordt verkregen met behulp van
AnimationInterface::AddNodeCounter. Een voorbeeldgebruik hiervoor is in
src/netanim/examples/resources_demo.cc.

Stap voor 2: het laden the XML in NetAnim
1. Ervan uitgaande dat NetAnim is gebouwd, gebruikt u het commando "./NetAnim" om NetAnim te starten. Alsjeblieft
bekijk de sectie "NetAnim bouwen" als NetAnim niet beschikbaar is.

2. Wanneer NetAnim is geopend, klikt u op de knop Bestand openen in de linkerbovenhoek en selecteert u
het XML-bestand dat tijdens stap 1 is gegenereerd.

3. Druk op de groene afspeelknop om de animatie te starten.

Hier is een video die dit illustreert http://www.youtube.com/watch?v=tz_hUuNwFDs

wiki
Voor gedetailleerde instructies over het installeren van "NetAnim", veelgestelde vragen en het laden van het XML-traceerbestand
(eerder vermeld) met behulp van NetAnim verwijzen wij u naar: http://www.nsnam.org/wiki/NetAnim

ANTENNE MODULE

Design documentatie
Overzicht
De antennemodule biedt:

1. een nieuwe basisklasse (AntennaModel) die een interface biedt voor het modelleren van de
stralingspatroon van een antenne;

2. een set klassen afgeleid van deze basisklasse die elk het stralingspatroon modelleren
van verschillende soorten antennes.

AntenneModel
Het antennemodel gebruikt het coördinatensysteem dat is overgenomen in [Balanis] en is afgebeeld in figuur
Coördineren system of the AntenneModel. Dit systeem wordt verkregen door de cartesiaanse vertaling te maken
coördinatensysteem gebruikt door het ns-3 MobilityModel naar de nieuwe oorsprong o, wat de
locatie van de antenne, en vervolgens de coördinaten van elk generiek punt p van transformeren
de ruimte van cartesische coördinaten (x,y,z) naar sferische coördinaten (r,heta,hi).
Het antennemodel verwaarloost de radiale component r en houdt alleen rekening met de hoekcomponenten
(heta, hoi).
Een antennestralingspatroon wordt dan uitgedrukt als een wiskundige functie g(heta, hi)
grightarrow thcal{R} die de versterking (in dB) retourneert voor elke mogelijke richting van
verzending/ontvangst. Alle hoeken worden uitgedrukt in radialen.
[afbeelding] Coördinatensysteem van het AntennaModel.UNINDENT

mits modellen
In deze sectie beschrijven we de antennestralingspatroonmodellen die hierin zijn opgenomen
de antennemodule.

IsotroopAntenneModel
Dit antennestralingspatroonmodel biedt een unitaire versterking (0 dB) voor alle richtingen.

CosinusAntenneModel
Dit is het cosinusmodel beschreven in [Chunjian]: de antenneversterking wordt bepaald als:

waar hallo_{0}
is de azimutale oriëntatie van de antenne (dwz de richting van maximale versterking) en de
exponentiële

bepaalt de gewenste 3dB bundelbreedte hi_{3dB}.
Merk op dat dit stralingspatroon onafhankelijk is van de hellingshoek heta.

Een groot verschil tussen het model van [Chunjian] en het model dat in de klas is geïmplementeerd
CosineAntennaModel is dat alleen de elementfactor (dat wil zeggen, wat beschreven is door het bovenstaande
formules) wordt overwogen. In feite overwoog [Chunjian] ook een extra antenne-array
factor. De reden waarom dit laatste is uitgesloten is dat we verwachten dat de gemiddelde gebruiker dat doet
zou een bepaalde bundelbreedte exact willen specificeren, zonder een arrayfactor toe te voegen bij a
laatste fase die in de praktijk de effectieve bundelbreedte van het resulterende zou veranderen
stralingspatroon.

ParaboolAntenneModel
Dit model is gebaseerd op de parabolische benadering van het stralingspatroon van de hoofdlob. Het
wordt vaak gebruikt in de context van een cellulair systeem om het stralingspatroon van een cel te modelleren
sector, zie bijvoorbeeld [R4-092042a] en [Calcev]. De antenneversterking in dB wordt bepaald
als:

waar hallo_{0}
is de azimutale oriëntatie van de antenne (dwz de richting van maximale versterking),
hoi_{3dB}
is de bundelbreedte van 3 dB en A_{max} is de maximale demping in dB van de antenne. Opmerking
dat dit stralingspatroon onafhankelijk is van de hellingshoek heta.

[Balanis]
CA Balanis, "Antennetheorie - analyse en ontwerp", Wiley, 2e ed.

[Chunjiaans]
Li Chunjian, "Efficiënte antennepatronen voor WCDMA-systemen met drie sectoren", Master of
Wetenschapsscriptie, Chalmers University of Technology, Göteborg, Zweden, 2003

[Calcev]
George Calcev en Matt Dillon, "Antenna Tilt Control in CDMA Networks", in Proc. van
de 2e jaarlijkse internationale draadloze internetconferentie (WICON), 2006

[R4-092042a]
3GPP TSG RAN WG4 (Radio) Meeting #51, R4-092042, Simulatie-aannames en
parameters voor FDD HeNB RF-vereisten.

Gebruiker Documentatie
De antennemodule kan worden gebruikt met alle draadloze technologieën en fysieke lagen
modellen die dit ondersteunen. Momenteel omvat dit de fysieke laagmodellen op basis van de
SpectrumPhy. Raadpleeg de documentatie van elk van deze modellen voor details.

Testen Documentatie
In dit gedeelte beschrijven we de testsuites die bij de antennemodule worden geleverd die verifiëren
de juiste functionaliteit.

Angles
De unit-testsuite hoeken controleert of de klasse Angles correct is opgebouwd door
correcte conversie van 3D cartesiaanse coördinaten volgens de beschikbare methoden
(constructie uit een enkele vector en uit een paar vectoren). Voor elke methode meerdere
er zijn testgevallen beschikbaar die de waarden vergelijken (hi,
heta) bepaald door de constructor tot bekende referentiewaarden. De test slaagt als voor elk
geval de waarden gelijk zijn aan de referentie tot een tolerantie van 10^{-10} die goed is
voor numerieke fouten.

GradenNaarRadianen
De unit-testsuite graden-radialen verifieert dat de methoden GradenNaarRadianen en
RadialenNaarGraden goed werken door te vergelijken met bekende referentiewaarden in een aantal
test gevallen. Elke testcase slaagt als de vergelijking gelijk is tot een tolerantie van 10^{-10}
wat numerieke fouten verklaart.

IsotroopAntenneModel
De unit-testsuite isotroop-antenne-model controleert of de IsotroopAntenneModel klasse
werkt naar behoren, dwz retourneert altijd een versterking van 0 dB, ongeacht de richting.

CosinusAntenneModel
De unit-testsuite cosinus-antenne-model controleert of de CosinusAntenneModel klasse werkt
op de juiste manier. Er zijn verschillende testcases beschikbaar die controleren of de antenneversterkingswaarde is berekend
in verschillende richtingen en voor verschillende waarden van de oriëntatie, de referentieversterking
en de bundelbreedte. De referentieversterking wordt met de hand berekend. Elke testcase slaagt als de
referentieversterking in dB is gelijk aan de waarde geretourneerd door CosinusAntenneModel binnen een
tolerantie van 0.001, wat goed is voor de benadering die is gedaan voor de berekening van de
referentiewaarden.

ParaboolAntenneModel
De unit-testsuite parabolisch-antenne-model controleert of de ParaboolAntenneModel klasse
werkt naar behoren. Er zijn verschillende testcases beschikbaar die de waarde van de antenneversterking controleren
berekend in verschillende richtingen en voor verschillende waarden van de oriëntatie, de
maximale demping en de bundelbreedte. De referentieversterking wordt met de hand berekend. Elke proef
geval slaagt als de referentieversterking in dB gelijk is aan de waarde geretourneerd door
ParaboolAntenneModel binnen een tolerantie van 0.001, wat de benadering verklaart
gedaan voor de berekening van de referentiewaarden.

AD HOC OP AANVRAAG AFSTAND VECTOR (AODV)

Dit model implementeert de basisspecificatie van de Ad Hoc On-Demand Distance Vector
(AODV) protocol. De uitvoering is gebaseerd op RFC 3561.

Het model is geschreven door Elena Buchatskaia en Pavel Boyko van ITTP RAS en is gebaseerd op
het ns-2 AODV-model ontwikkeld door de CMU/MONARCH-groep en geoptimaliseerd en afgestemd door Samir
Das en Mahesh Marina, University of Cincinnati, en ook over de AODV-UU-implementatie door
Erik Nordström van de Universiteit van Uppsala.

Model Beschrijving
De broncode voor het AODV-model bevindt zich in de directory src/aodv.

Design
Klasse ns3::aodv::Routingprotocol implementeert alle functionaliteit van servicepakketuitwisseling
en erft van ns3::Ipv4Routingprotocol. De basisklasse definieert twee virtuele functies
voor het routeren en doorsturen van pakketten. De eerste, ns3::aodv::RouteUitvoer, is gebruikt voor
lokaal afkomstige pakketten, en de tweede, ns3::aodv::Route-invoer, is gebruikt voor
het doorsturen en/of afleveren van ontvangen pakketten.

Protocolwerking is afhankelijk van veel instelbare parameters. Parameters hiervoor
functionaliteit zijn attributen van ns3::aodv::Routingprotocol. De standaardwaarden van parameters zijn
ontleend aan de RFC en staan ​​de in-/uitschakelen van protocolfuncties toe, zoals
het uitzenden van HELLO-berichten, het uitzenden van datapakketten enzovoort.

AODV ontdekt routes op aanvraag. Daarom buffert het AODV-model alle pakketten terwijl a
route request packet (RREQ) wordt verspreid. Er is een pakketwachtrij geïmplementeerd
aodv-rqueue.cc. Een slimme aanwijzer naar het pakket, ns3::Ipv4RoutingProtocol::ErrorCallback,
ns3::Ipv4RoutingProtocol::UnicastForwardCallback, en de IP-header worden hierin opgeslagen
wachtrij. De pakketwachtrij implementeert het opschonen van oude pakketten en een wachtrijgrootte
limit.

De routeringstabelimplementatie ondersteunt het opschonen van oude vermeldingen en statussen
machine, gedefinieerd in de norm. Het is geïmplementeerd als een STL-kaartcontainer. De sleutel is een
Bestemming IP Adres.

Sommige elementen van de werking van het protocol worden niet beschreven in de RFC. Deze elementen in het algemeen
betrekking hebben op de samenwerking van verschillende OSI-modellagen. Het model maakt gebruik van het volgende
heuristieken:

· Deze AODV-implementatie kan de aanwezigheid van unidirectionele links detecteren en deze vermijden
indien nodig. Als het knooppunt waarvoor het model een RREQ ontvangt een buur is, kan dit de oorzaak zijn
een eenrichtingsverbinding zijn. Deze heuristiek is afkomstig uit de AODV-UU-implementatie en kan
uitgeschakeld zijn.

· De werking van het protocol is sterk afhankelijk van het detectiemechanisme voor verbroken verbindingen. Het model
implementeert twee van dergelijke heuristieken. Ten eerste ondersteunt deze implementatie HELLO-berichten.
HALLO-berichten zijn echter geen goede manier om draadloze detectie van buren uit te voeren
omgeving (in ieder geval niet meer dan 802.11). Daarom kan men slechte prestaties ervaren
wanneer u draadloos werkt. Hier zijn verschillende redenen voor: 1) HELLO-berichten zijn
uitgezonden. In 802.11 gebeurt uitzenden vaak met een lagere bitsnelheid dan unicasting,
dus HELLO-berichten kunnen verder reiken dan unicast-gegevens. 2) HELLO-berichten zijn klein,
dus minder vatbaar voor bitfouten dan datatransmissies, en 3) Broadcast-transmissies
zijn niet gegarandeerd bidirectioneel, in tegenstelling tot unicast-uitzendingen. Ten tweede gebruiken we
laag 2 feedback indien mogelijk. Link wordt als verbroken beschouwd als frametransmissie
resulteert in een transmissiefout voor alle nieuwe pogingen. Dit mechanisme is bedoeld voor actief
links en werkt sneller dan de eerste methode.

De feedbackimplementatie van laag 2 is gebaseerd op de TxErrHeader traceerbron, momenteel
alleen ondersteund in AdhocWifiMac.

strekking en Beperkingen
Het model is alleen voor IPv4. De volgende optionele protocoloptimalisaties zijn dat niet
geïmplementeerd:

1. Ringzoeken uitbreiden.

2. Lokale linkreparatie.

3. RREP-, RREQ- en HELLO-berichtextensies.

Deze technieken vereisen directe toegang tot de IP-header, wat in tegenspraak is met de bewering van
de AODV RFC die AODV via UDP werkt. Dit model gebruikt UDP voor de eenvoud, waardoor de
mogelijkheid om bepaalde protocoloptimalisaties te implementeren. Het model maakt geen gebruik van low layer raw
stopcontacten omdat ze niet draagbaar zijn.

toekomst Werk met
Geen aangekondigde plannen.

Referenties
Gebruik
Voorbeelden
helpers
Attributen
Tracing
Logging
Voorbehoud
Validatie
Eenheid testen
Grotere schaal prestatie testen

Toepassingen

Placeholder hoofdstuk

BRUG NETTOESTEL

Placeholder hoofdstuk

Enkele voorbeelden van het gebruik van Bridge NetDevice zijn te vinden in voorbeelden/csma/ directory.

BRIT INTEGRATIE

Dit model implementeert een interface naar BRITE, de Boston University Representative Internet
Topologiegenerator [1]. BRITE is een standaard tool voor het genereren van realistisch internet
topologieën. Het ns-3-model, hierin beschreven, biedt een hulpklasse om te faciliteren
het genereren van ns-3-specifieke topologieën met behulp van BRITE-configuratiebestanden. BRITE bouwt de
originele grafiek die is opgeslagen als knooppunten en randen in de ns-3 BriteTopolgyHelper-klasse. In
de ns-3 integratie van BRITE, de generator genereert een topologie en geeft vervolgens toegang
naar bladknooppunten voor elke gegenereerde AS. ns-3 gebruikers kunnen dan aangepaste topologieën aan koppelen
deze bladknooppunten door ze handmatig te maken of door de meegeleverde topologiegeneratoren te gebruiken
ns-3.

Er zijn drie hoofdtypen topologieën beschikbaar in BRITE: Router, AS en
Hiërarchisch, een combinatie van AS en router. Voor de toepassing van ns-3
simulatie, de meest bruikbare zijn waarschijnlijk router en hiërarchisch. Router niveau
topologieën worden gegenereerd met behulp van het Waxman-model of het Barabasi-Albert-model. Elk
model heeft verschillende parameters die van invloed zijn op het maken van de topologie. Voor platte routertopologieën,
alle knooppunten worden geacht zich in hetzelfde AS te bevinden.

BRITE hiërarchische topologieën bevatten twee niveaus. De eerste is het AS-niveau. Dit niveau
kan ook worden gemaakt met behulp van het Waxman-model of het Barabasi-Albert-model.
Vervolgens wordt voor elk knooppunt in de AS-topologie een topologie op routerniveau geconstrueerd. Deze
topologieën op routerniveau kunnen opnieuw het Waxman-model of het Barbasi-Albert-model gebruiken.
BRITE verbindt deze afzonderlijke routertopologieën met elkaar zoals gespecificeerd door het AS-niveau
topologie. Zodra de hiërarchische topologie is opgebouwd, wordt deze afgevlakt tot een grote
topologie op routerniveau.

Meer informatie vindt u in de BRITE-gebruikershandleiding:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

Model Beschrijving
Het model is gebaseerd op het bouwen van een externe BRITE-bibliotheek en vervolgens het bouwen van wat ns-3
helpers die naar de bibliotheek roepen. De broncode voor de ns-3-helpers bevindt zich in de
directory src/brite/helper.

Design
Om de BRITE-topologie te genereren, roepen ns-3-helpers naar de externe BRITE-bibliotheek, en
met behulp van een standaard BRITE-configuratiebestand bouwt de BRITE-code een grafiek op met knooppunten en
randen volgens dit configuratiebestand. Raadpleeg de BRITE-documentatie of de
voorbeeldconfiguratiebestanden in src/brite/examples/conf_files om een ​​beter begrip van te krijgen
BRITE-configuratieopties. De door BRITE gebouwde grafiek wordt teruggegeven aan ns-3 en een ns-3
implementatie van de grafiek is gebouwd. Bladknooppunten voor elke AS zijn beschikbaar voor de gebruiker
om aangepaste topologieën aan te sluiten of ns-3-applicaties rechtstreeks te installeren.

Referenties
[1] Alberto Medina, Anukool Lakhina, Ibrahim Matta en John Byers. BRITE: Een benadering van
Generatie van universele topologie. In Proceedings van de internationale workshop over
Modellering, analyse en simulatie van computer- en telecommunicatiesystemen - MASCOTS
'01, Cincinnati, Ohio, augustus 2001.

Gebruik
Er kan naar het brite-generieke voorbeeld worden verwezen om het basisgebruik van de BRITE-interface te bekijken. In
samenvatting, de BriteTopologyHelper wordt gebruikt als het interfacepunt door een BRITE door te geven
configuratiebestand. Samen met het configuratiebestand een willekeurig seed-bestand in BRITE-indeling
kan ook worden doorgegeven. Als een seed-bestand niet wordt doorgegeven, maakt de helper een seed
bestand met behulp van ns-3's UniformRandomVariable. Zodra de topologie is gegenereerd door BRITE,
BuildBriteTopology() wordt aangeroepen om de ns-3-representatie te maken. Het volgende IP-adres kan zijn
toegewezen aan de topologie met behulp van AssignIpv4Addresses() of AssignIpv6Addresses(). Het
Houd er rekening mee dat elke point-to-point-link in de topologie als een nieuwe zal worden behandeld
netwerk daarom moet voor IPV4 een /30 subnet worden gebruikt om te voorkomen dat er een grote hoeveelheid wordt verspild
de beschikbare adresruimte.

Voorbeelden van BRITE-configuratiebestanden zijn te vinden in /src/brite/examples/conf_files/.
ASBarbasi en ASWaxman zijn voorbeelden van alleen AS-topologieën. De RTBarabasi en RTWaxman
bestanden zijn voorbeelden van router-only topologieën. Eindelijk de TD_ASBarabasi_RTWaxman
configuratiebestand is een voorbeeld van een hiërarchische topologie die gebruikmaakt van de Barabasi-Albert
model voor het AS-niveau en het Waxman-model voor elk van de topologieën op routerniveau.
Informatie over de BRITE-parameters die in deze bestanden worden gebruikt, is te vinden in de BRITE-gebruiker
manual.

Gebouw BRIT Integratie
De eerste stap is het downloaden en bouwen van de ns-3-specifieke BRITE-repository:

$ hg-kloon http://code.nsnam.org/BRITE
$cd BRITE
$ Make

Dit zal BRITE bouwen en een bibliotheek creëren, libbrite.so, binnen de BRITE-directory.

Nadat BRITE met succes is gebouwd, gaan we verder met het configureren van ns-3 met BRITE-ondersteuning.
Ga naar uw ns-3-directory:

$ ./waf configure --with-brite=/uw/pad/naar/brite/source --enable-examples

Zorg ervoor dat er 'enabled' staat naast 'BRITE Integration'. Als dat niet het geval is, dan is er iets
mis gegaan. Of je bent vergeten om eerst BRITE te bouwen door de bovenstaande stappen te volgen, of
ns-3 kon uw BRITE-directory niet vinden.

Bouw vervolgens ns-3:

$ ./waf

Voorbeelden
Voor een voorbeeld van een BRITE-integratierun:

$ ./waf --run 'brite-generieke-voorbeeld'

Door de uitgebreide parameter in te schakelen, zal het voorbeeld het knooppunt en de rand afdrukken
informatie in een vergelijkbaar formaat als standaard BRITE-uitvoer. Er zijn er nog veel meer
opdrachtregelparameters inclusief confFile, tracering en nix, hieronder beschreven:

confBestand
Een BRITE-configuratiebestand. Veel verschillende voorbeelden van BRITE-configuratiebestanden
bestaan ​​in de map src/brite/examples/conf_files, bijvoorbeeld
RTBarabasi20.conf en RTWaxman.conf. Raadpleeg de map conf_files
voor meer voorbeelden.

tracing
Maakt ascii-tracering mogelijk.

nix Maakt nix-vectorroutering mogelijk. Standaard wordt globale routering gebruikt.

Het generieke BRITE-voorbeeld ondersteunt ook visualisatie met behulp van pyviz, uitgaande van python-bindingen
in ns-3 zijn ingeschakeld:

$ ./waf --run brite-generieke-voorbeeld --vis

Simulaties met BRITE kunnen ook worden gebruikt met MPI. Het totale aantal MPI-exemplaren
wordt doorgegeven aan de BRITE-topologiehelper waar een modulo divide wordt gebruikt om de knooppunten toe te wijzen
voor elke AS naar een MPI-instantie. Een voorbeeld is te vinden in src/brite/examples:

$ mpirun -np 2 ./waf --run brite-MPI-voorbeeld

Raadpleeg de ns-3 MPI-documentatie voor informatie over het instellen van MPI met ns-3.

GEBOUWEN MODULE

cd .. inclusief:: vervang.txt

Design documentatie
Overzicht
De module Gebouwen biedt:

1. een nieuwe klas (Gebouw) die de aanwezigheid van een gebouw in een simulatie modelleert
scenario;

2. een nieuwe klas (MobiliteitGebouwInfo) waarmee u de locatie, grootte en
kenmerken van gebouwen aanwezig in het gesimuleerde gebied, en maakt de plaatsing mogelijk
van knooppunten binnen die gebouwen;

3. een containerklasse met de definitie van de meest bruikbare pathloss-modellen en de
corresponderende variabelen genoemd GebouwenVoortplantingVerliesModel.

4. een nieuw vermeerderingsmodel (HybridBuildingsPropagationLossModel) werken met de
mobiliteitsmodel dat zojuist is geïntroduceerd, waarmee het fenomeen van kan worden gemodelleerd
voortplanting binnen/buiten in de aanwezigheid van gebouwen.

5. een vereenvoudigd model dat alleen werkt met Okumura Hata (OhBuildingsPropagationLossModel)
rekening houdend met het fenomeen van voortplanting binnen/buiten in de aanwezigheid van
gebouwen.

De modellen zijn ontworpen met LTE in het achterhoofd, hoewel de implementatie dat wel is
onafhankelijk van elke LTE-specifieke code en kan worden gebruikt met andere ns-3 wireless
technologieën (bijvoorbeeld wifi, wimax).

De HybridBuildingsPropagationLossModel opgenomen pathloss-model wordt verkregen via een
combinatie van verschillende bekende pathloss-modellen om verschillende na te bootsen
milieuscenario's zoals stedelijke, voorstedelijke en open gebieden. Bovendien het model
is van mening dat zowel binnen als buiten communicatie binnen en buiten moet worden opgenomen
aangezien HeNB zowel binnen als buiten het gebouw kan worden geïnstalleerd. In het geval van binnen
communicatie, het model moet ook rekening houden met het type gebouw buiten <-> binnen
communicatie volgens enkele algemene criteria, zoals de muurpenetratieverliezen van
de gemeenschappelijke materialen; bovendien bevat het een algemene configuratie voor de interne
muren in binnencommunicatie.

De OhBuildingsPropagationLossModel pathloss-model is gemaakt om de
vorige verwijderde de drempels voor het overstappen van het ene model naar het andere. Om dit te doen
er is slechts één vermeerderingsmodel gebruikt van het beschikbare model (dwz de Okumura
Hata). In het model wordt nog steeds rekening gehouden met de aanwezigheid van bebouwing; dus alle
bovenstaande overwegingen met betrekking tot het gebouwtype zijn nog steeds geldig. Hetzelfde
kan worden afgewogen wat het milieuscenario en de frequentie sindsdien betreffen
beide zijn parameters van het beschouwde model.

De Gebouw klasse
Het model bevat een specifieke klasse genaamd Gebouw die een ns3 bevat Box camera's les voor
bepalen van de afmetingen van het gebouw. Om de kenmerken van de
inbegrepen pathloss-modellen, de Gebouw class ondersteunt de volgende attributen:

· type gebouw:

· Residentieel (standaardwaarde)

· Kantoor

· Reclame

· type buitenmuren

· Hout

· ConcreteWithWindows (standaardwaarde)

· BetonZonderRamen

· Steenblokken

· aantal verdiepingen (standaardwaarde 1, wat betekent alleen begane grond)

· aantal kamers in x-as (standaardwaarde 1)

· aantal kamers in y-as (standaardwaarde 1)

De klasse Building is gebaseerd op de volgende aannames:

· een gebouw wordt weergegeven als een rechthoekig parallellepipedum (dwz een doos)

· de muren zijn evenwijdig aan de x-, y- en z-as

· een gebouw is opgedeeld in een raster van kamers, geïdentificeerd aan de hand van de volgende parameters:

· aantal verdiepingen

· aantal kamers langs de x-as

· aantal kamers langs de y-as

· de z-as is de verticale as, dwz, verdiepingsnummers nemen toe voor toenemende z-as
waarden

· de x- en y-ruimte-indices beginnen bij 1 en nemen toe langs de x- en y-as
respectievelijk

· alle kamers in een gebouw zijn even groot

De MobiliteitGebouwInfo klasse
De MobiliteitGebouwInfo klasse, die overerft van de ns3-klasse Object, heeft de leiding over
het bijhouden van informatie over de positie van een knooppunt ten opzichte van een gebouw. De
informatie beheerd door MobiliteitGebouwInfo is:

· of het knooppunt binnen of buiten is

· indien binnen:

· in welk gebouw het knooppunt zich bevindt

· in welke kamer de node zich bevindt (x-, y- en vloerruimte-indices)

De klas MobiliteitGebouwInfo wordt gebruikt door GebouwenVoortplantingVerliesModel klasse, die
erft van de ns3-klasse VoortplantingLossModel en beheert de pathloss-berekening van
de afzonderlijke componenten en hun samenstelling volgens de posities van de knooppunten. Bovendien,
het implementeert ook de schaduwwerking, dat wil zeggen het verlies als gevolg van obstakels op het hoofdpad
(dwz vegetatie, gebouwen, enz.).

Opgemerkt moet worden dat, MobiliteitGebouwInfo kan door elk ander voortplantingsmodel worden gebruikt.
Echter, op basis van de informatie op het moment van schrijven, zijn alleen degene gedefinieerd in
de bouwmodule is ontworpen om rekening te houden met de beperkingen die door de
gebouwen.
g
ItuR1238PropagationLossModel
Deze klasse vormt een aanvulling op een gebouwafhankelijk voortplantingsverliesmodel binnenshuis op basis van de ITU
P.1238 modeg{ die verliezen omvat als gevolg van het type gebouw (d.w.z. woningen, kantoren en
commercial)ia De analytische uitdrukking wordt hieronder gegeven.
nr
{r
aa
waar: goed. : stroomuitval
N = tr}sidentieel \ 30 & kantoor \ 22 & commercieel\nd{array}
coëfficiënt [dB]
goed.
L_f = t }sidentieel \ 15+4(n-1) & kantoor \ 6+3(n-1) & commercieel\nd{array}
{l
n : aantal verdiepingen tussen basisstation en mobiel (n 1)
l2
f : frequentie [MHz]
}&
d : afstand (waarbij d > 1) [m]
n
GebouwenPropag&ationLossModel
Het BuildingsPropagationLossModel biedt een extra set gebouwafhankelijke
pathloss-modelelementen die worden gebruikt om verschillende pathloss-logica's te implementeren. Deze
Pathloss-modelelementen worden beschreven in de volgende subparagrafen.

Extern Gevel Verlies (EWL)
Dit onderdeel modelleert het penetratieverlies door muren voor binnen naar buiten
communicatie en vice versa. De waarden zijn ontleend aan het [cost231]-model.

· Hout ~ 4 dB

· Beton met ramen (niet gemetalliseerd) ~ 7 dB

· Beton zonder ramen ~ 15 dB (overspanning tussen 10 en 20 in COST231)

· Steenblokken ~ 12 dB

Intern Muren Verlies (IWL)
Dit onderdeel modelleert het penetratieverlies dat optreedt bij communicatie van binnen naar binnen
binnen hetzelfde gebouw. Het totale verlies wordt berekend in de veronderstelling dat elk afzonderlijk intern
muur heeft een constant penetratieverlies L_{siw}, en benadert het aantal muren dat
worden gepenetreerd met de manhattan-afstand (in aantal kamers) tussen de zender
en de ontvanger. Stel in detail x_1, y_1, x_2, y_2 het kamernummer langs de x en
y-as respectievelijk voor gebruiker 1 en 2; het totale verlies L_{IWL} wordt berekend als

Lengte Krijgen Model (HG)
Dit component modelleert de winst doordat het zendapparaat zich op een vloer bevindt
boven de grond. In de literatuur [turkmani] is deze winst geschat op ongeveer 2 dB
per verdieping. Deze winst kan worden toegepast op alle communicatie binnen en buiten
vice versa.

schaduwing Model
De schaduwvorming is gemodelleerd volgens een lognormale verdeling met variabele standaard
afwijking als functie van de relatieve positie (binnen of buiten) van het MobiliteitsModel
gevallen betrokken. Voor elk paar MobiliteitsModellen wordt één willekeurige waarde getrokken, die blijft staan
constant voor dat paar tijdens de hele simulatie. Het model is dus geschikt voor
alleen statische knooppunten.

Het model gaat ervan uit dat het gemiddelde van het schaduwverlies in dB altijd 0 is
variantie, beschouwt het model drie mogelijke waarden van standaarddeviatie, in detail:
pijl-rechts X_thrm{O}
· buitenshuis (m_shadowingSigmaBuiten, standaardwaarde van 7 dB)
N(_thrm{O}, ma_thrm{O}^2).
pijltje X_thrm{I}
· binnen (m_shadowingSigmaIndoor, standaardwaarde van 10 dB)
N(_thrm{I}, ma_thrm{I}^2).
rechtse pijl
· buitenmuren doordringen (m_shadowingSigmaExtWalls, standaardwaarde 5 dB)
X_thrm{W} N(_thrm{W}, ma_thrm{W}^2)

De simulator genereert een schaduwwaarde per elke actieve link volgens de knooppunten
positie de eerste keer dat de link wordt gebruikt om te verzenden. In het geval van uitzendingen van
buitenknooppunten naar binnenknooppunten, en vice versa, de standaarddeviatie (ma_thrm{IO}) moet
worden berekend als de vierkantswortel van de som van de kwadratische waarden van de norm
afwijking in het geval van buitenknopen en die voor de penetratie van de buitenmuren. Dit is
vanwege het feit dat de componenten die de schaduw produceren onafhankelijk van elkaar zijn
ander; daarom is de variantie van een verdeling als gevolg van de som van twee onafhankelijk
normale is de som van de varianties.

Padverlies logica's
Hieronder beschrijven we de verschillende pathloss-logica die wordt geïmplementeerd door
overnemen van BuildingsPropagationLossModel.

HybridBuildingsPropagationLossModel
De HybridBuildingsPropagationLossModel opgenomen pathloss-model wordt verkregen via een
combinatie van verschillende bekende pathloss-modellen om verschillende buiten- en tuinpaden na te bootsen
scenario's voor binnen, maar ook scenario's van binnen naar buiten en van buiten naar binnen. In detail,
de klas HybridBuildingsPropagationLossModel integreert de volgende pathloss-modellen:

· OkumuraHataPropagationLossModel (OH) (bij frequenties > 2.3 GHz vervangen door
Kun2600MhzPropagationLossModel)

· ItuR1411LosPropagationLossModel en ItuR1411NlosOverRooftopPropagationLossModel
(I1411)

· ItuR1238PropagationLossModel (I1238)

· de pathloss-elementen van het BuildingsPropagationLossModel (EWL, HG, IWL)

De volgende pseudocode illustreert hoe de verschillende pathloss-modelelementen worden beschreven
hierboven zijn geïntegreerd in HybridBuildingsPropagationLossModel:

als (txNode buiten is)
harte
als (rxNode buiten is)
harte
als (afstand > 1 km)
harte
als (rxNode of txNode zich onder het dak bevindt)
harte
L = I1411
anders
L = OH
anders
L = I1411
anders (rxNode is binnen)
als (afstand > 1 km)
harte
als (rxNode of txNode zich onder het dak bevindt)
L = I1411 + EWL + HG
anders
L = OH + EWL + HG
anders
L = I1411 + EWL + HG
anders (txNode is binnen)
als (rxNode binnen is)
harte
als (hetzelfde gebouw)
harte
L = I1238 + IWL
anders
L = I1411 + 2*EWL
anders (rxNode is buiten)
als (afstand > 1 km)
harte
als (rxNode of txNode zich onder het dak bevindt)
harte
L = I1411 + EWL + HG
anders
L = OH + EWL + HG
anders
L = I1411 + EWL

We merken op dat, voor het geval van communicatie tussen twee knooppunten onder dakniveau met
afstand groter is dan 1 km, beschouwen we nog steeds het I1411-model, aangezien OH specifiek is
ontworpen voor macrocellen en dus voor antennes boven het dakniveau.

Voor het ITU-R P.1411-model beschouwen we zowel de LOS- als de NLoS-versie. In het bijzonder wij
houdt rekening met de LoS-voortplanting voor afstanden die korter zijn dan een instelbare drempel
(m_itu1411NlosDrempel). In het geval van NLoS-voortplanting, is het over het dak-model
in overweging genomen voor het modelleren van zowel macro BS als SC. In geval op NLoS meerdere
parameters die afhankelijk zijn van het scenario zijn opgenomen, zoals gemiddelde straatbreedte,
oriëntatie, enz. De waarden van dergelijke parameters moeten correct worden ingesteld volgens de
scenario geïmplementeerd, berekent het model hun waarden niet native. Voor het geval dat
waarden worden verstrekt, worden de standaardwaarden gebruikt, afgezien van de hoogte van de mobiel en BS,
die in plaats daarvan hun integriteit rechtstreeks in de code wordt getest (dat wil zeggen, ze moeten zijn
groter dan nul). Hieronder geven we de uitdrukkingen van de componenten van de
model.

We merken ook op dat het gebruik van verschillende voortplantingsmodellen (OH, I1411, I1238 met hun
varianten) in HybridBuildingsPropagationLossModel kan leiden tot onderbrekingen van de
pathloss met betrekking tot afstand. Een goede afstemming van de attributen (vooral de
attributen voor afstandsdrempels) kunnen deze discontinuïteiten vermijden. Echter sinds de
gedrag van elk model hangt af van verschillende andere parameters (frequentie, knooppunthoogte, enz.),
er is geen standaardwaarde van deze drempels die de discontinuïteiten in het geheel kan vermijden
mogelijke configuraties. Daarom wordt een passende afstemming van deze parameters overgelaten aan de
gebruiker.

OhBuildingsPropagationLossModel
De OhBuildingsPropagationLossModel class is gemaakt als een eenvoudig middel om de
discontinuïteitsproblemen van HybridBuildingsPropagationLossModel zonder te doen
scenariospecifieke parameterafstemming. De oplossing is om slechts één voortplantingsverlies te gebruiken
model (dwz Okumura Hata), met behoud van de structuur van de pathloss-logica voor de
berekening van andere padverliescomponenten (zoals muurpenetratieverliezen). Het resultaat is
een model dat vrij is van discontinuïteiten (behalve die door muren), maar dat is minder
realistisch totaal voor een generiek scenario met gebouwen en buiten-/binnengebruikers, bijv.
omdat Okumura Hata niet geschikt is voor communicatie binnenshuis of buitenshuis
communicatie onder dakniveau.

In detail, de klas OhBuildingsPropagationLossModel integreert het volgende pathloss
modellen:

· OkumuraHataPropagationLossModel (OH)

· de pathloss-elementen van het BuildingsPropagationLossModel (EWL, HG, IWL)

De volgende pseudocode illustreert hoe de verschillende pathloss-modelelementen worden beschreven
hierboven zijn geïntegreerd in OhBuildingsPropagationLossModel:

als (txNode buiten is)
harte
als (rxNode buiten is)
harte
L = OH
anders (rxNode is binnen)
L = OH + EWL
anders (txNode is binnen)
als (rxNode binnen is)
harte
als (hetzelfde gebouw)
harte
L = OH + IWL
anders
L = OH + 2*EWL
anders (rxNode is buiten)
L = OH + EWL

We merken op dat OhBuildingsPropagationLossModel een aanzienlijke vereenvoudiging is met respect
naar HybridBuildingsPropagationLossModel, omdat OH altijd wordt gebruikt. Terwijl dit
geeft in sommige scenario's (vooral onder het dak en binnen) een minder nauwkeurig model
vermijdt effectief het probleem van pathloss-discontinuïteiten die van invloed zijn
HybridBuildingsPropagationLossModel.

Gebruiker Documentatie
Hoe naar . gebouwen in a simulatie
In deze sectie leggen we het basisgebruik van het gebouwenmodel binnen een simulatie uit
programma.

omvatten the headers
Voeg dit toe aan het begin van je simulatieprogramma:

#erbij betrekken

creëren a bouwt
Laten we als voorbeeld een residentieel gebouw van 10 x 20 x 10 maken:

dubbel x_min = 0.0;
dubbel x_max = 10.0;
dubbel y_min = 0.0;
dubbel y_max = 20.0;
dubbele z_min = 0.0;
dubbele z_max = 10.0;
Ptr b = CreëerObject ();
b -> Grenzen instellen (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Gebouw::Residentieel);
b->SetExtWallsType (Gebouw::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRoomsX (3);
b->SetNRoomsY (2);

Dit gebouw heeft drie verdiepingen en een intern raster van 3 x 2 kamers van gelijke grootte.

De hulpklasse GridBuildingAllocator is ook beschikbaar om eenvoudig een set van te maken
gebouwen met identieke kenmerken geplaatst op een rechthoekig raster. Hier is een voorbeeld
van hoe het te gebruiken:

Ptr gridBuildingAllocator;
gridBuildingAllocator = CreateObject ();
gridBuildingAllocator->SetAttribute ("GridWidth", UintegerValue (3));
gridBuildingAllocator->SetAttribute ("LengthX", DoubleValue (7));
gridBuildingAllocator->SetAttribute ("LengthY", DoubleValue (13));
gridBuildingAllocator->SetAttribute ("DeltaX", DoubleValue (3));
gridBuildingAllocator->SetAttribute ("DeltaY", DoubleValue (3));
gridBuildingAllocator->SetAttribute ("Hoogte", DoubleValue (6));
gridBuildingAllocator->SetBuildingAttribute ("NRoomsX", UintegerValue (2));
gridBuildingAllocator->SetBuildingAttribute ("NRoomsY", UintegerValue (4));
gridBuildingAllocator->SetBuildingAttribute ("NFloors", UintegerValue (2));
gridBuildingAllocator->SetAttribute ("MinX", DoubleValue (0));
gridBuildingAllocator->SetAttribute ("MinY", DoubleValue (0));
gridBuildingAllocator->Maken (6);

Hierdoor ontstaat een 3x2 raster van 6 gebouwen, elk 7 x 13 x 6 m met 2 x 4 kamers binnen en
2 verdiepingen; de gebouwen staan ​​op zowel de x- als de y-as 3 m uit elkaar.

Setup knooppunten en mobiliteit modellen
Nodes en mobiliteitsmodellen worden zoals gewoonlijk geconfigureerd, maar om ze te gebruiken met de
gebouwenmodel waarvoor u een extra oproep nodig heeft GebouwenHelper::Install(), om te laten
het mobiliteitsmodel bevat de informatie over hun positie ten opzichte van de gebouwen. Hier is
Een voorbeeld:

MobilityHelper mobiliteit;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobiliteit.Installeren (ueNodes);
GebouwenHelper::Installeren (ueNodes);

Opgemerkt moet worden dat elk mobiliteitsmodel kan worden gebruikt. De gebruiker wordt echter aangeraden dit te doen
zorg ervoor dat het gedrag van het gebruikte mobiliteitsmodel consistent is met de
aanwezigheid van gebouwen. Bijvoorbeeld door een simpele willekeurige mobiliteit over het geheel te gebruiken
simulatiegebied in aanwezigheid van gebouwen kan er gemakkelijk toe leiden dat nodes in en uit bewegen
gebouwen, ongeacht de aanwezigheid van muren.

plaats sommige knooppunten
U kunt knooppunten in uw simulatie plaatsen met behulp van verschillende methoden, die worden beschreven in de
in aansluiting op.

Nalatenschap positionering methoden
Elke bestaande ns-3 positioneringsmethode kan worden gebruikt om een ​​knooppunt in de simulatie te plaatsen. De
belangrijke aanvullende stap is om bijvoorbeeld nodes handmatig als volgt te plaatsen:

Ptr mm0 = enbNodes.Get (0)->GetObject ();
Ptr mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

MobilityHelper mobiliteit;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobiliteit.Installeren (ueNodes);
GebouwenHelper::Installeren (ueNodes);
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

U kunt ook elke bestaande klasse PositionAllocator gebruiken. De coördinaten van de
node zal bepalen of het buiten of binnen wordt geplaatst en, indien binnen, waarin
gebouw en kamer waarin het is geplaatst.

Gebouwspecifiek positionering methoden
De volgende positietoewijzerklassen zijn beschikbaar om knooppunten op speciale posities te plaatsen
met betrekking tot gebouwen:

· WillekeurigeBuildingPositionAllocator: Wijs elke positie toe door willekeurig een te kiezen
bouwen uit de lijst met alle gebouwen en vervolgens willekeurig een positie binnenin kiezen
het gebouw.

· RandomRoomPositionAllocator: Wijs elke positie toe door willekeurig een kamer te kiezen
de lijst met kamers in alle gebouwen en vervolgens willekeurig een positie kiezen binnen de
kamer.

· SameRoomPositionAllocator: Loopt een gegeven NodeContainer opeenvolgend en voor elk
node wijst willekeurig een nieuwe positie toe in dezelfde kamer van die node.

· FixedRoomPositionAllocator: Genereer een willekeurige positie gelijkmatig verdeeld in de
volume van een gekozen kamer in een gekozen gebouw.

Merk the Mobiliteit Model Consistent
belangrijk: wanneer je gebouwen gebruikt, moet je het volgende commando geven nadat we
hebben alle knooppunten en gebouwen in de simulatie geplaatst:

GebouwenHelper::MakeMobilityModelConsistent ();

Dit commando doorloopt de lijsten van alle knooppunten en van alle gebouwen, bepaal voor
elke gebruiker of het binnen of buiten is, en als het binnen is, zal het ook het gebouw bepalen
waar de gebruiker zich bevindt en de bijbehorende verdieping en het nummer in het gebouw.

Bouwbewust padverlies model
Nadat je gebouwen en knooppunten in een simulatie hebt geplaatst, kun je een gebouwbewust
pathloss-model in een simulatie precies op dezelfde manier waarop u een regulier padverlies zou gebruiken
model. Hoe u dit doet, is specifiek voor de draadloze module die u overweegt (lte,
wifi, wimax, enz.), dus raadpleeg de documentatie van dat model voor specifieke informatie
instructies.

Hoofd configureerbaar attributen
De Gebouw class heeft de volgende configureerbare parameters:

· type gebouw: residentieel, kantoor en commercieel.

· type buitenmuren: Hout, BetonMetVensters, BetonZonderVensters en SteenBlokken.

· bouwgrenzen: a Box camera's klasse met de bouwgrenzen.

· aantal verdiepingen.

· aantal kamers in x-as en y-as (kamers kunnen alleen in een raster worden geplaatst).

De GebouwMobiliteitVerliesModel parameter configureerbaar met het ns3-attribuutsysteem is
vertegenwoordigd door de grens (string bounds) van het simulatiegebied door a Box camera's klasse
met de gebiedsgrenzen. Bovendien kunnen door middel van zijn methoden de volgende parameters zijn
geconfigureerd:

· het nummer van de verdieping waarop de node is geplaatst (standaard 0).

· de positie in het kamersraster.

De BuildingPropagationLossModel class heeft de volgende configureerbare parameters
configureerbaar met het attributensysteem:

· Frequentie: referentiefrequentie (standaard 2160 MHz), merk op dat door de frequentie in te stellen
de golflengte wordt dienovereenkomstig automatisch ingesteld en omgekeerd).

· Lambda: de golflengte (0.139 meter, rekening houdend met de bovenstaande frequentie).

· ShadowSigma Outdoor: de standaarddeviatie van de schaduwvorming voor buitenknooppunten (default
7.0).

· SchaduwSigmaIndoor: de standaarddeviatie van de schaduwvorming voor binnenknooppunten (default
8.0).

· ShadowSigmaExtWalls: de standaarddeviatie van de schaduwwerking door buitenmuren
penetratie voor communicatie van buiten naar binnen (standaard 5.0).

· Dakniveau: het niveau van het dak van het gebouw in meters (standaard 20 meter).

· Los2NlosThr: de waarde van de afstand van het schakelpunt tussen zichtlijn en
non-line-of-sight propagatiemodel in meters (standaard 200 meter).

· ITU1411AfstandDr: de waarde van de afstand van het schakelpunt tussen korte afstand
(ITU 1211) communicatie en lange afstand (Okumura Hata) in meters (standaard 200 meter).

· MinAfstand: de minimale afstand in meters tussen twee knooppunten voor het evalueren van de
padverlies (verwaarloosbaar geacht vóór deze drempel) (standaard 0.5 meter).

· Milieu: het omgevingsscenario tussen Urban, SubUrban en OpenAreas (standaard
Stedelijk).

· StadSize: de dimensie van de stad tussen Small, Medium, Large (standaard Groot).

Om de hybride modus te gebruiken, is de te gebruiken klasse de
HybrideBuildingMobilityLossModel, waarmee het juiste pathloss-model kan worden geselecteerd
volgens de pathloss-logica die in het ontwerphoofdstuk wordt gepresenteerd. Echter deze oplossing
heeft het probleem dat de schakelpunten van het pathloss-model discontinuïteiten kunnen opleveren
aan de verschillende kenmerken van het model. Dit houdt in dat volgens de specifieke
scenario, moet de drempel die wordt gebruikt voor het overstappen goed worden afgestemd. Het simpele
OhBouwMobiliteitVerliesModel los dit probleem op door alleen het Okumura Hata-model te gebruiken en
de muurpenetratieverliezen.

Testen Documentatie
Overzicht
Om de ns-3 Building Pathloss-module te testen en te valideren, zijn er enkele testsuites beschikbaar
zijn geïntegreerd met het ns-3 testraamwerk. Om ze uit te voeren, moet u het
bouw de simulator op deze manier:

$ ./waf configure --enable-tests --enable-modules=gebouwen
$ ./test.py

Bovenstaande zal niet alleen de testsuites draaien die bij de gebouwenmodule horen, maar ook
die behoren tot alle andere ns-3-modules waarvan de gebouwenmodule afhankelijk is. Zien
de ns-3 handleiding voor generieke informatie over het toetsingskader.

U kunt op deze manier een meer gedetailleerd rapport in HTML-indeling krijgen:

$ ./test.py -w resultaten.html

Nadat de bovenstaande opdracht is uitgevoerd, kunt u het gedetailleerde resultaat voor elke test bekijken door te openen
het bestand resultaten.html met een webbrowser.

U kunt elke testsuite afzonderlijk uitvoeren met deze opdracht:

$ ./test.py -s naam testsuite

Voor meer informatie over test.py en het ns-3 toetsingskader, zie de ns-3
manual.

Beschrijving of the proef suites
GebouwenHelper proef
De testsuite gebouwen-helper controleert of de methode
GebouwenHelper::MakeAllInstancesConsistent () goed werkt, dat wil zeggen dat de
BuildingsHelper is succesvol in het lokaliseren of knooppunten binnen of buiten zijn, en binnen
dat ze zich in het juiste gebouw, kamer en verdieping bevinden. Er zijn verschillende testgevallen
voorzien van verschillende gebouwen (met verschillende grootte, positie, kamers en verdiepingen) en
verschillende knooppuntposities. De test slaagt als elk knooppunt correct is geplaatst.

GebouwPositionAllocator proef
De testsuite gebouw-positie-toewijzer voorzien van twee testcases die dat controleren
respectievelijk RandomRoomPositionAllocator en SameRoomPositionAllocator werken naar behoren. Elk
testgevallen hebben betrekking op een enkel gebouw van 2x3x2 kamers (totaal 12 kamers) op bekende coördinaten en
respectievelijk 24 en 48 knopen. Beide tests controleren of het aantal knooppunten dat in elk is toegewezen
kamer de verwachte is en dat de positie van de knooppunten ook correct is.

Gebouwen Padverlies testen
De testsuite gebouwen-pathloss-model biedt verschillende eenheidstests die de
verwachte resultaten van de module pathloss gebouwen in specifieke scenario's met pre
berekende waarden offline verkregen met een Octave-script
(test/referentie/buildings-pathloss.m). De tests worden als geslaagd beschouwd als de twee waarden
zijn gelijk tot een tolerantie van 0.1, wat geschikt wordt geacht voor het typische gebruik van
pathloss-waarden (die in dB zijn).

Hieronder hebben we de overwogen scenario's gedetailleerd beschreven, waarvoor hun selectie is gedaan
die het brede scala aan mogelijke logische combinaties van pathloss dekt. De pathloss-logica resulteert
daarom impliciet getest.

test #1 Okumura fout
In deze test testen we het standaard Okumura Hata model; daarom zijn zowel eNB als UE geplaatst
buiten op een afstand van 2000 m. De gebruikte frequentie is de E-UTRA-band #5, die
komen overeen met 869 MHz (zie tabel 5.5-1 van 36.101). De test omvat ook de validatie
van de gebiedsuitbreidingen (dwz stedelijke, voorstedelijke en open gebieden) en van de grootte van de stad
(klein, middelgroot en groot).

test #2 KOSTEN231 Model
Deze test is gericht op het valideren van het COST231-model. De test is vergelijkbaar met de Okumura
Hata one, behalve dat de gebruikte frequentie de EUTRA-band #1 (2140 MHz) is en dat de test
kan vanwege het model alleen worden uitgevoerd voor grote en kleine steden in stedelijke scenario's
beperkingen.

test #3 2.6 GHz model
Deze test valideert het 2.6 GHz Kun-model. De test is vergelijkbaar met Okumura Hata one behalve
dat de frequentie de EUTRA-band #7 (2620 MHz) is en dat de test alleen kan worden uitgevoerd in
stedelijk scenario.

test #4 ITU1411 LoS model
Deze test is bedoeld om het ITU1411-model te valideren in geval van zichtlijn binnen de straat
canyons transmissies. In dit geval wordt de UE sindsdien op 100 meter van de eNB geplaatst
de drempel voor het schakelen tussen LoS en NLoS wordt op standaard één gelaten (dwz 200 m.).

test #5 ITU1411 NLoS model
Deze test is bedoeld om het ITU1411-model te valideren in geval van niet-zichtlijn over de
transmissies op het dak. In dit geval wordt de UE geplaatst op 900 meter ver van de eNB, in
om boven de drempel te komen voor het schakelen tussen LoS en NLoS wordt overgelaten aan standaard één
(dwz 200 meter).

test #6 ITUP1238 model
Deze test is bedoeld om het ITUP1238-model te valideren in het geval van uitzendingen binnenshuis. In
in dit geval zijn zowel de UE als de eNB geplaatst in een woongebouw met muren gemaakt van
beton met ramen. Ue bevindt zich op de tweede verdieping en bevindt zich op 30 meter afstand
de eNB, welke op de eerste verdieping is geplaatst.

test #7 Buiten -> Binnen met Okumura fout model
Deze test valideert de transmissies van buiten naar binnen voor grote afstanden. In dit geval
de UE is geplaatst in een woongebouw met muur van beton met ramen en
afstanden 2000 meter van de buiten eNB.

test #8 Buiten -> Binnen met ITU1411 model
Deze test valideert de overdracht van buiten naar binnen voor korte afstanden. In dit geval
de UE is geplaatst in een woongebouw met muren van beton met ramen en
afstanden 100 meter van de buiten eNB.

test #9 Binnen -> Buiten met ITU1411 model
Deze test valideert de transmissies van buiten naar binnen voor zeer korte afstanden. In deze
case de eNB is geplaatst op de tweede verdieping van een woongebouw met muren gemaakt van
beton met ramen en afstanden van 100 meter van de buiten-UE (dwz LoS
communicatie). Daarom moet de hoogtewinst worden meegenomen in de pathloss-evaluatie.

test #10 Binnen -> Buiten met ITU1411 model
Deze test valideert de overdracht van buiten naar binnen voor korte afstanden. In dit geval
de eNB is geplaatst op de tweede verdieping van een woongebouw met muren gemaakt van
beton met ramen en afstanden van 500 meter van de buiten-UE (dwz NLoS
communicatie). Daarom moet de hoogtewinst worden meegenomen in de pathloss-evaluatie.

Gebouwen schaduwing test
De testsuite gebouwen-schaduwtest is een eenheidstest bedoeld om de statistiek te verifiëren
distributie van het schaduwmodel geïmplementeerd door GebouwenPathlossModel. De schaduwwerking
is gemodelleerd volgens een normale verdeling met gemiddelde = 0 en variabele standaard
afwijking ma, volgens in de literatuur gebruikelijke modellen. Drie testgevallen zijn
verstrekt, die de gevallen van binnen-, buiten- en binnen-naar-buitencommunicatie dekken.
Elke testcase genereert 1000 verschillende schaduwmonsters voor verschillende paren
MobilityModel-instanties in een bepaald scenario. Schaduwwaarden worden verkregen door aftrekken
van de totale verlieswaarde geretourneerd door HybridBuildingsPathlossModel de padverliescomponent
die constant en vooraf bepaald is voor elke testcase. De test verifieert dat het monster
gemiddelde en steekproefvariantie van de schaduwwaarden vallen binnen het betrouwbaarheidsinterval van 99%
van het steekproefgemiddelde en de steekproefvariantie. De test verifieert ook dat de schaduwwaarden
die op opeenvolgende tijdstippen wordt geretourneerd voor hetzelfde paar MobilityModel-instanties, is constant.

Referenties
[Turksman]
Turkmani AMD, JD Parson en DG Lewis, "Radiovoortplanting in gebouwen op
441, 900 en 1400 MHz", in Proc. van 4th Int. Conference on Land Mobile Radio, 1987.

KLIK MODULAR ROUTER INTEGRATIE

Click is een softwarearchitectuur voor het bouwen van configureerbare routers. Door verschillende te gebruiken
combinaties van pakketverwerkingseenheden die elementen worden genoemd, kan een Click-router worden gemaakt
een bepaald soort functionaliteit uitvoeren. Deze flexibiliteit biedt een goed platform voor
testen en experimenteren met verschillende protocollen.

Model Beschrijving
De broncode voor het Click-model bevindt zich in de directory src/klik.

Design
Het ontwerp van ns-3 is zeer geschikt voor integratie met Click vanwege de volgende redenen:

· Pakketten in ns-3 worden geserialiseerd/gedeserialiseerd terwijl ze omhoog/omlaag in de stapel gaan. Dit maakt het mogelijk
ns-3 pakketten die moeten worden doorgegeven aan en van Click zoals ze zijn.

· Dit betekent ook dat elke vorm van ns-3 verkeersgenerator en transport gemakkelijk zou moeten werken
bovenop Klik.

· Door te streven naar het implementeren van click als een Ipv4RoutingProtocol-instantie, kunnen we dit voorkomen
significante wijzigingen in de LL- en MAC-laag van de ns-3-code.

Het doel van het ontwerp was om de ns-3-click openbare API eenvoudig genoeg te maken zodat de gebruiker
hoeft alleen maar een Ipv4ClickRouting-instantie aan het knooppunt toe te voegen en elk klikknooppunt te informeren
van het Click-configuratiebestand (.click-bestand) dat het gaat gebruiken.

Dit model implementeert de interface naar de Click Modular Router en biedt de
Ipv4ClickRouting-klasse om toe te staan ​​dat een knooppunt Click gebruikt voor externe routering. In tegenstelling tot normaal
Ipv4RoutingProtocol-subtypen, Ipv4ClickRouting gebruikt geen RouteInput()-methode, maar
ontvangt in plaats daarvan een pakket op de juiste interface en verwerkt het dienovereenkomstig. Opmerking
dat u een routeringstabeltype-element in uw Click-grafiek nodig hebt om Click for te gebruiken
externe routering. Dit is nodig voor de functie RouteOutput() die is geërfd van
Ipv4RoutingProtocol. Bovendien gebruikt een op klikken gebaseerd knooppunt een ander soort L3 in de
vorm van Ipv4L3ClickProtocol, een ingekorte versie van Ipv4L3Protocol.
Ipv4L3ClickProtocol geeft pakketten die door de stack gaan door aan Ipv4ClickRouting voor
processing.

Het ontwikkelen van a Simulator API naar toelaten ns-3 naar interactie met Klik
Een groot deel van de API is al goed gedefinieerd, waardoor Click naar informatie kan zoeken
de simulator (zoals een Node's ID, een Interface ID enzovoort). Door het grootste deel van de
methoden, zou het mogelijk moeten zijn om hiervoor nieuwe implementaties te schrijven die specifiek zijn voor ns-3
functionaliteit.

Daarom zal voor de Click-integratie met ns-3 een klasse met de naam Ipv4ClickRouting de
interactie met Klik. De code hiervoor is te vinden in
src/click/model/ipv4-click-routing.{cc,h}.

Pakket hand korting tussen ns-3 en Klik
Er zijn vier soorten pakketoverdrachten die kunnen optreden tussen ns-3 en Click.

· L4 tot L3

· L3 tot L4

· L3 tot L2

· L2 tot L3

Om dit te verhelpen, implementeren we Ipv4L3ClickProtocol, een uitgeklede versie van
Ipv4L3-protocol. Ipv4L3ClickProtocol geeft pakketten door van en naar Ipv4ClickRouting
geschikt om routering uit te voeren.

strekking en Beperkingen
· In de huidige staat is de NS-3 Click-integratie beperkt tot alleen gebruik met L3, verlaten
NS-3 om L2 aan te kunnen. We werken momenteel aan het toevoegen van Click MAC-ondersteuning. Zie de
gebruiksgedeelte om ervoor te zorgen dat u uw Click-grafieken dienovereenkomstig ontwerpt.

· Bovendien werkt ns-3-click alleen met elementen op gebruikersniveau. De volledige lijst van
elementen zijn verkrijgbaar bij http://read.cs.ucla.edu/click/elements. Elementen die hebben
'all', 'userlevel' of 'ns' die ernaast staan ​​mogen gebruikt worden.

· Vanaf nu is de ns-3-interface voor Click alleen IPv4. We zullen Ipv6-ondersteuning toevoegen
de toekomst.

Referenties
· Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti en M. Frans Kaashoek. De
klik modulaire router. ACM-transacties op computersystemen 18(3), augustus 2000, pagina's
263-297.

· Lalith Suresh P., en Ruben Merz. Ns-3-klik: klik op modulaire routerintegratie voor ns-3.
In proc. van de 3e internationale ICST-workshop over NS-3 (WNS3), Barcelona, ​​Spanje. Maart,
2011.

· Michael Neufeld, Ashish Jain en Dirk Grunwald. Nsclick: netwerksimulatie overbruggen
en inzet. MSWiM '02: Proceedings van de 5e ACM internationale workshop over modelleren
analyse en simulatie van draadloze en mobiele systemen, 2002, Atlanta, Georgia, VS.
http://doi.acm.org/10.1145/570758.570772

Gebruik
Gebouw Klik
De eerste stap is om Click te klonen vanuit de github-repository en het te bouwen:

$ git kloon https://github.com/kohler/click
$ cd klik/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
$ Make

De vlag --enable-wifi kan worden overgeslagen als u niet van plan bent Click with Wifi te gebruiken. *
Let op: U hoeft geen 'make install' uit te voeren.

Zodra Click met succes is gebouwd, gaat u naar de ns-3-directory en configureert u ns-3
met Click Integration-ondersteuning:

$ ./waf configure --enable-examples --enable-tests --with-nsclick=/pad/naar/klik/bron

Hint: als u één map boven ns-3 hebt geïnstalleerd (zoals in de ns-3-allinone
directory), en de naam van de directory is 'click' (of een symbolische link naar de directory
heet 'click'), dan is de --with-nsclick specificatie niet nodig; de ns-3 build
systeem zal de directory succesvol vinden.

Als er 'ingeschakeld' staat naast 'NS-3 Click Integration Support', dan ben je klaar om te gaan.
Opmerking: als u modulaire ns-3 uitvoert, is de minimale set modules vereist om alle ns-3-click uit te voeren
voorbeelden zijn wifi, csma en config-store.

Probeer vervolgens een van de voorbeelden uit te voeren:

$ ./waf --voer nsclick-simple-lan uit

U kunt dan de resulterende .pcap-sporen bekijken, die nsclick-simple-lan-0-0.pcap heten
en nsclick-simple-lan-0-1.pcap.

Klik Diagram Bereidingswijze
Houd rekening met het volgende bij het maken van uw klikgrafiek:

· Alleen elementen op gebruikersniveau kunnen worden gebruikt.

· U moet de elementen FromDevice en ToDevice vervangen door FromSimDevice en
ToSimDevice-elementen.

· Pakketten naar de kernel worden verzonden met behulp van ToSimDevice (tap0,IP).

· Voor elk knooppunt wordt het apparaat genoemd dat pakketten naar/van de kernel verzendt/ontvangt
'tik0'. De overige interfaces zouden eth0, eth1 enzovoort moeten heten (zelfs als je
wifi gebruiken). Houd er rekening mee dat de apparaatnummering vanaf 0 moet beginnen. In de toekomst zal dit
wordt flexibel gemaakt, zodat gebruikers apparaten in hun Click-bestand een naam kunnen geven die ze willen.

· Een routeringstabelelement is verplicht. De OUTports van het routeringstabelelement moeten
komen overeen met het interfacenummer van het apparaat waar het pakket doorheen gaat
uiteindelijk worden uitgezonden. Het overtreden van deze regel zal leiden tot echt rare pakketsporen.
De naam van dit routeringstabelelement moet vervolgens worden doorgegeven aan het Ipv4ClickRouting-protocol
object als simulatieparameter. Zie de Klikvoorbeelden voor details.

· De huidige implementatie laat Click achter met voornamelijk L3-functionaliteit, met ns-3-afhandeling
L2. We zullen binnenkort beginnen met het ondersteunen van het gebruik van MAC-protocollen op Click.
Dit betekent dat vanaf nu de wifi-specifieke elementen van Click niet kunnen worden gebruikt met ns-3.

Debugging Pakket Stromen van Klik
Vanaf elk punt in een Click-grafiek kunt u de Print (‐
http://read.cs.ucla.edu/click/elements/print) element en zijn varianten voor mooie afdrukken
van de pakketinhoud. Bovendien kunt u pcap-sporen genereren van pakketten die door een
Klik grafiek met behulp van de ToDump (http://read.cs.ucla.edu/click/elements/todump) element als
Goed. Bijvoorbeeld:

mijnarpquerier
-> Afdrukken(vanarpquery,64)
-> ToDump(out_arpquery,PER_NODE 1)
-> uitroeien;

en ... drukt de inhoud af van pakketten die uit de ArpQuerier stromen en genereert vervolgens een
pcap-traceerbestand met het achtervoegsel 'out_arpquery' voor elk knooppunt dat de Click
bestand, voordat pakketten naar 'ethout' worden geduwd.

Helper
Om een ​​knooppunt Click te laten uitvoeren, zou de gemakkelijkste manier zijn om de ClickInternetStackHelper te gebruiken
class in uw simulatiescript. Bijvoorbeeld:

Klik op InternetStackHelper klik;
click.SetClickFile (myNodeContainer, "nsclick-simple-lan.click");
klik.SetRoutingTableElement (myNodeContainer, "u/rt");
klik.Installeer (myNodeContainer);

De voorbeeldscripts binnenin src/klik/voorbeelden/ demonstreren het gebruik van op klikken gebaseerde knooppunten in
verschillende scenario's. De helperbron is binnenin te vinden
src/click/helper/click-internet-stack-helper.{h,cc}

Voorbeelden
De volgende voorbeelden zijn geschreven, die te vinden zijn in src/klik/voorbeelden/:

· nsclick-simple-lan.cc en nsclick-raw-wlan.cc: een op klikken gebaseerd knooppunt dat communiceert met een
normaal ns-3-knooppunt zonder klik, met respectievelijk Csma en Wifi. Het demonstreert ook
het gebruik van TCP bovenop Click, iets waar de originele nsclick-implementatie voor was
NS-2 kon niet bereiken.

· nsclick-udp-client-server-csma.cc en nsclick-udp-client-server-wifi.cc: een LAN met 3 knooppunten
(respectievelijk Csma en Wifi) waarbij 2 op klikken gebaseerde knooppunten een UDP-client uitvoeren, die verzendt
pakketten naar een derde op klikken gebaseerde node waarop een UDP-server draait.

· nsclick-routing.cc: Een op klikken gebaseerd knooppunt communiceert met een ander via een derde knooppunt dat
fungeert als een IP-router (met behulp van de IP-router Click-configuratie). Dit demonstreert
routering met behulp van Click.

Scripts zijn beschikbaar binnen /conf/ waarmee u Click-bestanden kunt genereren voor
enkele veelvoorkomende scenario's. De IP-router die wordt gebruikt in nsclick-routing.cc werd gegenereerd uit de
make-ip-conf.pl bestand en enigszins aangepast om met ns-3-click te werken.

Validatie
Dit model is als volgt getest:

· Er zijn unit tests geschreven om de internals van Ipv4ClickRouting te verifiëren. Dit kan zijn
gevonden in src/click/ipv4-click-routing-test.cc. Deze tests verifiëren of de methoden
binnen Ipv4ClickRouting die te maken hebben met apparaatnaam naar ID, IP-adres van apparaatnaam
en Mac-adres van apparaatnaambindingen werken zoals verwacht.

· De voorbeelden zijn gebruikt om Click te testen met daadwerkelijke simulatiescenario's. Deze kunnen zijn
gevonden in src/klik/voorbeelden/. Deze tests hebben betrekking op het volgende: het gebruik van verschillende
soorten transporten bovenop Click, TCP/UDP, of Click nodes mee kunnen communiceren
niet-Click-gebaseerde knooppunten, of Click-knooppunten met elkaar kunnen communiceren via Click
om pakketten te routeren met behulp van statische routering.

· Click is getest met Csma-, Wifi- en Point-to-Point-apparaten. Gebruiksinstructies zijn
beschikbaar in het voorgaande gedeelte.

CSMA NETTOESTEL

Dit is de inleiding tot het hoofdstuk CSMA NetDevice, als aanvulling op het Csma-model doxygen.

Overzicht of the CSMA model
De ns-3 CSMA-apparaat modelleert een eenvoudig busnetwerk in de geest van Ethernet. Hoewel het
modelleert geen echt fysiek netwerk dat u ooit zou kunnen bouwen of kopen, het biedt er wel enkele
zeer nuttige functionaliteit.

Als je aan een busnetwerk denkt, denk je meestal aan Ethernet of IEEE 802.3. Ethernet
maakt gebruik van CSMA/CD (Carrier Sense Multiple Access with Collision Detection met exponentieel
steeds meer achterstand in de strijd om het gedeelde transmissiemedium. De ns-3 CSMA-apparaat
modelleert slechts een deel van dit proces, gebruikmakend van de aard van het wereldwijd beschikbare kanaal
om onmiddellijk (sneller dan licht) dragerdetectie en op prioriteit gebaseerde botsingen te bieden
"vermijding." Botsingen in de zin van Ethernet gebeuren nooit en dus ook de ns-3 CSMA-apparaat
modelleert geen botsingsdetectie, noch zal een lopende transmissie worden "vastgelopen".

CSMA Verschillende Lagen Model
Er zijn een aantal conventies in gebruik om gelaagde communicatie te beschrijven
architecturen in de literatuur en in leerboeken. Het meest voorkomende gelaagdheidsmodel is het
ISO zevenlaags referentiemodel. In deze weergave het paar CsmaNetDevice en CsmaChannel
beslaat de onderste twee lagen: de fysieke (laag één) en de datalink (laag twee)
posities. Een ander belangrijk referentiemodel is dat gespecificeerd in RFC 1122, "Requirements
voor internethosts - communicatielagen." In deze weergave zijn de CsmaNetDevice en
Het CsmaChannel-paar beslaat de onderste laag: de linklaag. Er is ook sprake van een schijnbaar
eindeloze litanie van alternatieve beschrijvingen gevonden in schoolboeken en in de literatuur. Wij
de naamgevingsconventies overnemen die worden gebruikt in de IEEE 802-standaarden die spreken van LLC, MAC, MII
en PHY-laagjes. Deze acroniemen worden gedefinieerd als:

· LLC: logische linkcontrole;

· MAC: Mediatoegangscontrole;

· MII: media-onafhankelijke interface;

· PHY: Fysieke laag.

In dit geval de LLC en MAC-adres zijn sublagen van de OSI-datalinklaag en de MII en PHY
zijn sublagen van de fysieke OSI-laag.

De "bovenkant" van het CSMA-apparaat definieert de overgang van de netwerklaag naar de data
linklaag. Deze overgang wordt uitgevoerd door hogere lagen door een van beide aan te roepen
CsmaNetDevice::Send of CsmaNetDevice::SendFrom.

In tegenstelling tot de IEEE 802.3-standaarden bestaat er in de CSMA geen nauwkeurig gespecificeerde PHY
model in de zin van draadtypen, signalen of pinouts. De "onderste" interface van het
CsmaNetDevice kan worden gezien als een soort Media Independent Interface (MII).
in de "Fast Ethernet" (IEEE 802.3u) specificaties. Deze MII-interface past in een
overeenkomstige media-onafhankelijke interface op het CsmaChannel. Je zult de
equivalent van een 10BASE-T of een 1000BASE-LX PHY.

Het CsmaNetDevice roept het CsmaChannel aan via een media-onafhankelijke interface. Er is een
methode gedefinieerd om het kanaal te vertellen wanneer het moet beginnen met "wiebelen met de draden" met behulp van de methode
CsmaChannel::TransmitStart, en een methode om het kanaal te vertellen wanneer het transmissieproces plaatsvindt
is klaar en het kanaal zou het laatste bit over de "draad" moeten gaan verspreiden:
CsmaChannel::TransmitEnd.

Wanneer de TransmitEnd-methode wordt uitgevoerd, zal het kanaal een enkel uniform signaal modelleren
voortplantingsvertraging in het medium en het bezorgen van pakketten van het pakket aan elk van de apparaten
gekoppeld aan het pakket via de CsmaNetDevice::Receive-methode.

Er is een "pin" in de media-onafhankelijke interface van het apparaat die overeenkomt met "COL"
(botsing). De status van het kanaal kan worden waargenomen door CsmaChannel::GetState aan te roepen. Elk
het apparaat zal naar deze "pin" kijken voordat het verzenden begint en zal een passende back-off uitvoeren
operaties indien nodig.

Correct ontvangen pakketten worden vanaf het CsmaNetDevice naar hogere niveaus doorgestuurd via een
terugbelmechanisme. De callback-functie wordt geïnitialiseerd door de hogere laag (wanneer de net
apparaat is aangesloten) met behulp van CsmaNetDevice::SetReceiveCallback en wordt aangeroepen na "juiste"
ontvangst van een pakket door het netapparaat om het pakket via het protocol door te sturen
stack.

CSMA Kanaal Model
De klasse CsmaChannel modelleert het eigenlijke transmissiemedium. Er is geen vaste limiet voor
het aantal apparaten dat op het kanaal is aangesloten. De CsmaChannel modelleert een datasnelheid en een
lichtsnelheidsvertraging die toegankelijk is via de attributen "DataRate" en "Delay"
respectievelijk. De datasnelheid die aan het kanaal wordt geleverd, wordt gebruikt om de datasnelheden in te stellen die worden gebruikt
de zendersecties van de CSMA-apparaten die op het kanaal zijn aangesloten. Er is geen manier om dat te doen
onafhankelijk ingestelde datasnelheden in de apparaten. Omdat de datasnelheid alleen wordt gebruikt om te berekenen
een vertragingstijd, is er geen beperking (behalve door het gegevenstype dat de waarde bevat).
de snelheid waarmee CSMA-kanalen en apparaten kunnen werken; en geen beperking op basis van enige beperking
soort PHY-kenmerken.

Het CsmaChannel heeft drie statussen: IDLE, VERZENDEN en PROPAGEREN. Deze drie staten
worden onmiddellijk "gezien" door alle apparaten op het kanaal. Hiermee bedoelen we dat als één
apparaat een gesimuleerde transmissie begint of beëindigt, zijn alle apparaten op het kanaal dat per direct
bewust van de staatsverandering. Er is geen tijd waarin één apparaat een IDLE
kanaal terwijl een ander apparaat zich fysiek verder weg in het botsingsdomein bevindt
begonnen met zenden terwijl de bijbehorende signalen zich niet via het kanaal naar het andere voortplantten
apparaten. Er is dus geen noodzaak voor botsingsdetectie in het CsmaChannel-model, en dat is ook zo
op geen enkele manier uitgevoerd.

We hebben, zoals de naam al aangeeft, een Carrier Sense-aspect in het model. Sinds de
simulator is single-threaded, toegang tot het gemeenschappelijke kanaal wordt geserialiseerd door de
simulator. Dit biedt een deterministisch mechanisme om voor het kanaal te strijden. De
kanaal is toegewezen (overgegaan van state IDLE te vermelden VERZENDEN) op basis van wie het eerst komt
op basis van het eerst maalt. Het kanaal doorloopt altijd een proces met drie toestanden:

IDLE -> ZENDEN -> PROPAGEREN -> IDLE

De VERZENDEN state modelleert de tijd gedurende welke het bronnetapparaat zich daadwerkelijk bevindt
het wiebelen van de signalen op de draad. De PROPAGEREN state modelleert de tijd na het laatste bit
werd verzonden, wanneer het signaal zich langs de draad naar het "verre uiteinde" voortplant.

De overgang naar de VERZENDEN staat wordt gedreven door een oproep tot
CsmaChannel::TransmitStart die wordt aangeroepen door het netwerkapparaat dat het pakket verzendt. Het
Het is de verantwoordelijkheid van dat apparaat om de transmissie te beëindigen met een oproep naar
CsmaChannel::TransmitEnd op het juiste simulatietijdstip dat de verstreken tijd weerspiegelt
om alle pakketbits op de draad te plaatsen. Wanneer TransmitEnd wordt aangeroepen, wordt het kanaal
plant een gebeurtenis die overeenkomt met een enkele lichtsnelheidsvertraging. Deze vertraging geldt voor
alle netapparaten op het kanaal identiek. Je kunt hierbij denken aan een symmetrische hub waarin
de pakketbits planten zich voort naar een centrale locatie en gaan vervolgens terug naar kabels van gelijke lengte
de andere apparaten op het kanaal. De enkele "lichtsnelheid"-vertraging komt dan overeen met
de tijd die nodig is voor: 1) een signaal om zich via de kabel van één CsmaNetDevice te verspreiden
naar de hub; plus 2) de tijd die de hub nodig heeft om het pakket via een poort door te sturen; plus
3) de tijd die het signaal in kwestie nodig heeft om zich naar het bestemmingsnet te verspreiden
stuurt.

De CsmaChannel modelleert een uitzendmedium, zodat het pakket op alle apparaten wordt afgeleverd
op het kanaal (inclusief de bron) aan het einde van de voortplantingstijd. Het is de
verantwoordelijkheid van het verzendende apparaat om te bepalen of het al dan niet een pakket ontvangt
uitgezonden via het kanaal.

Het CsmaChannel biedt de volgende attributen:

· DataRate: de bitsnelheid voor pakketoverdracht op aangesloten apparaten;

· Vertraging: de snelheid van de lichttransmissievertraging voor het kanaal.

CSMA Netto Apparaat Model
Het CSMA-netwerkapparaat lijkt enigszins op een Ethernet-apparaat. Het CsmaNet-apparaat
biedt de volgende attributen:

· Adres: het Mac48-adres van het apparaat;

· SendEnable: schakel pakketverzending in indien waar;

· ReceiverEnable: schakel pakketontvangst in indien waar;

· EncapsulationMode: type inkapseling van de linklaag dat moet worden gebruikt;

· RxErrorModel: het ontvangstfoutmodel;

· TxQueue: de verzendwachtrij die door het apparaat wordt gebruikt;

· InterframeGap: de optionele tijd om te wachten tussen "frames";

· Rx: een traceringsbron voor ontvangen pakketten;

· Drop: een traceringsbron voor verwijderde pakketten.

Het CsmaNetDevice ondersteunt de toewijzing van een "ontvangstfoutmodel". Dit is een
ErrorModel-object dat wordt gebruikt om gegevensbeschadiging op de link te simuleren.

Pakketten die via het CsmaNetDevice worden verzonden, worden altijd via de verzendwachtrij gerouteerd
een traceerhaak bieden voor pakketten die via het netwerk worden verzonden. Deze verzendwachtrij kan worden ingesteld
(via attribuut) om verschillende wachtrijstrategieën te modelleren.

Ook configureerbaar per attribuut is de inkapselingsmethode die door het apparaat wordt gebruikt. Elk
pakket krijgt een EthernetHeader die de bestemmings- en bron-MAC-adressen bevat, en
een lengte/type-veld. Elk pakket krijgt ook een EthernetTrailer waarin de FCS is opgenomen.
Gegevens in het pakket kunnen op verschillende manieren worden ingekapseld.

Standaard, of door het kenmerk "EncapsulationMode" in te stellen op "Dix", is de inkapseling
volgens de DEC-, Intel-, Xerox-standaard. Dit wordt ook wel EthernetII-framing genoemd
en is het bekende bestemmings-MAC, bron-MAC, EtherType, Data, CRC-formaat.

Als het kenmerk "EncapsulationMode" is ingesteld op "Llc", vindt de inkapseling plaats via LLC SNAP. In
In dit geval wordt een SNAP-header toegevoegd die het EtherType (IP of ARP) bevat.

De andere geïmplementeerde inkapselingsmodi zijn IP_ARP (stel "EncapsulationMode" in op "IpArp")
waarin het lengtetype van de Ethernet-header het protocolnummer van de ontvangt
pakket; of ETHERNET_V1 (stel "EncapsulationMode" in op "EthernetV1") waarin het lengtetype
van de Ethernet-header ontvangt de lengte van het pakket. Er is sprake van een "ruwe" inkapselingsmodus
gedefinieerd maar niet geïmplementeerd - gebruik van de RAW-modus resulteert in een bewering.

Houd er rekening mee dat alle netwerkapparaten op een kanaal op dezelfde inkapselingsmodus moeten worden ingesteld
correcte resultaten. De inkapselingsmodus wordt niet waargenomen bij de ontvanger.

Het CsmaNetDevice implementeert een willekeurig exponentieel uitstelalgoritme dat wordt uitgevoerd als
het kanaal is vastbesloten bezet te zijn (VERZENDEN or PROPAGEREN) wanneer het apparaat dat wil
om te beginnen met propageren. Dit resulteert in een willekeurige vertraging van maximaal pow (2, nieuwe pogingen) - 1
microseconden voordat er opnieuw wordt geprobeerd. Het standaard maximale aantal nieuwe pogingen is 1000.

gebruik the CsmaNet-apparaat
De CSMA-netapparaten en -kanalen worden doorgaans gemaakt en geconfigureerd met behulp van de
geassocieerd CsmaHelper voorwerp. De verschillen ns-3 apparaathelpers werken over het algemeen op dezelfde manier
manier, en het gebruik ervan is terug te vinden in veel van onze voorbeeldprogramma’s.

Het conceptuele model dat van belang is, is dat van een kale computerschil waarin je een net aansluit
apparaten. De kale computers zijn gemaakt met behulp van een KnooppuntContainer helper. Je vraagt ​​dit gewoon
helper om zoveel mogelijk computers te maken (we noemen ze Nodes) zoals u nodig heeft op uw netwerk:

NodeContainer csmaNodes;
csmaNodes.Create (nCsmaNodes);

Zodra u uw knooppunten heeft, moet u een instantiëren CsmaHelper en stel eventuele attributen in
wil misschien veranderen.:

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100 Mbps"));
csma.SetChannelAttribute ("Vertraging", Tijdwaarde (NanoSeconds (6560)));

csma.SetDeviceAttribute ("EncapsulationMode", StringValue ("Dix"));
csma.SetDeviceAttribute ("FrameSize", UintegerValue (2000));

Zodra de attributen zijn ingesteld, hoeft u alleen nog maar de apparaten aan te maken en erop te installeren
de vereiste knooppunten, en om de apparaten met elkaar te verbinden via een CSMA-kanaal. Wanneer we
maak de netto-apparaten, we voegen ze toe aan een container zodat u ze in de toekomst kunt gebruiken.
Dit kost allemaal slechts één regel code:

NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

We raden u aan goed na te denken over het wijzigen van deze kenmerken, omdat dit kan leiden tot
gedrag dat gebruikers verrast. Wij staan ​​dit toe omdat wij flexibiliteit belangrijk vinden.
Als voorbeeld van een mogelijk verrassend effect van het veranderen van attributen, beschouw de
volgende:

Het Mtu-kenmerk geeft de maximale transmissie-eenheid naar het apparaat aan. Dit is de maat
van de grootste Protocol Data Unit (PDU) die het apparaat kan verzenden. Dit kenmerk is standaard ingesteld
tot 1500 bytes en komt overeen met een getal gevonden in RFC 894, "A Standard for the
Verzending van IP-datagrammen via Ethernet-netwerken." Het nummer is feitelijk afgeleid van
de maximale pakketgrootte voor 10Base5-netwerken (full-spec Ethernet) - 1518 bytes. als jij
trek DIX-inkapselingsoverhead af voor Ethernet-pakketten (18 bytes) en je krijgt uiteindelijk a
maximaal mogelijke gegevensgrootte (MTU) van 1500 bytes. Je kunt ook vinden dat de MTU voor IEEE
802.3-netwerken zijn 1492 bytes. Dit komt omdat LLC/SNAP-inkapseling een extra acht toevoegt
bytes overhead voor het pakket. In beide gevallen is het de onderliggende netwerkhardware
beperkt tot 1518 bytes, maar de MTU is anders omdat de inkapseling anders is.

Als men het Mtu-kenmerk op 1500 bytes laat staan ​​en het kenmerk van de inkapselingsmodus wijzigt
voor LLC zal het resultaat een netwerk zijn dat PDU's van 1500 bytes met LLC/SNAP omvat
framing resulterend in pakketten van 1526 bytes. Dit zou in veel netwerken illegaal zijn, maar
Wij staan ​​u toe dit te doen. Dit resulteert in een simulatie die heel subtiel niet weerspiegelt
wat je zou verwachten, aangezien een echt apparaat er niet in slaagt een pakket van 1526 bytes te verzenden.

Er bestaan ​​ook jumboframes (1500 <MTU <= 9000 bytes) en super-jumbo (MTU > 9000 bytes)
bytes) frames die niet officieel zijn goedgekeurd door IEEE, maar in sommige gevallen wel beschikbaar zijn
hogesnelheidsnetwerken (Gigabit) en NIC's. In het CSMA-model zou men de
inkapselingsmodus ingesteld op Dix, en stel de Mtu in op 64000 bytes - ook al is er een bijbehorende
CsmaChannel DataRate bleef op 10 megabits per seconde (zeker niet Gigabit Ethernet).
Dit zou in essentie een Ethernet-switch modelleren, gemaakt in de vampier-afgeluisterde jaren 1980-stijl
10Base5-netwerken die super-jumbo datagrammen ondersteunen, wat zeker niet iets is
is ooit gemaakt en zal waarschijnlijk ook nooit worden gemaakt; het is echter vrij eenvoudig voor u om dat te doen
configureren.

Wees voorzichtig met aannames over wat CSMA feitelijk modelleert en hoe
configuratie (Attributen) kan ervoor zorgen dat u aanzienlijk afwijkt van de werkelijkheid.

CSMA Tracing
Net als alle ns-3 apparaten biedt het CSMA-model een aantal traceringsbronnen. Deze sporen
bronnen kunnen worden gekoppeld met behulp van uw eigen aangepaste traceercode, of u kunt onze helper gebruiken
functies om ervoor te zorgen dat tracering wordt ingeschakeld op de apparaten die u opgeeft.

Bovenste niveau (MAC) haken
Vanuit het oogpunt van tracering in het netapparaat zijn er verschillende interessante punten
om spoorhaken in te voegen. Een conventie die is geërfd van andere simulators is dat pakketten
bestemd voor verzending naar aangesloten netwerken passeren een enkele "verzendwachtrij" in
het netapparaat. We bieden traceerhaken op dit punt in de pakketstroom, wat overeenkomt
(abstract) alleen naar een overgang van de netwerk- naar de datalinklaag, en noem ze
gezamenlijk haakt het apparaat MAC.

Wanneer een pakket voor verzending naar het CSMA-netapparaat wordt verzonden, gaat het altijd via de
wachtrij verzenden. De verzendwachtrij in het CsmaNetDevice erft van Queue, en daarom
erft drie sporenbronnen:

· Een bron voor een Enqueue-bewerking (zie Queue::m_traceEnqueue);

· Een bron van dequeue-bewerking (zie Queue::m_traceDequeue);

· Een bron voor verwijderingsbewerkingen (zie Wachtrij::m_traceDrop).

De traceerhaken op het hoogste niveau (MAC) voor het CsmaNetDevice zijn in feite precies deze drie
traceer bronnen op de enkele verzendwachtrij van het apparaat.

De gebeurtenis m_traceEnqueue wordt geactiveerd wanneer een pakket in de verzendwachtrij wordt geplaatst. Dit
gebeurt op het moment dat CsmaNetDevice::Send of CsmaNetDevice::SendFrom wordt aangeroepen door een
hogere laag om een ​​pakket in de wachtrij te zetten voor verzending.

De gebeurtenis m_traceDequeue wordt geactiveerd wanneer een pakket uit de verzendwachtrij wordt verwijderd.
Het verwijderen van wachtrijen uit de verzendwachtrij kan in drie situaties voorkomen: 1) Als het onderliggende
kanaal is inactief wanneer CsmaNetDevice::Send of CsmaNetDevice::SendFrom wordt aangeroepen, een
pakket wordt uit de verzendwachtrij gehaald en onmiddellijk verzonden; 2) Als de
het onderliggende kanaal inactief is, kan een pakket uit de wachtrij worden gehaald en onmiddellijk worden verzonden in een
interne TransmitCompleteEvent die ongeveer hetzelfde functioneert als een complete transmissie-interrupt
onderhoudsroutine; of 3) van de willekeurige exponentiële backoff-handler als er een time-out is
gedetecteerd.

Geval (3) houdt in dat een pakket uit de verzendwachtrij wordt gehaald als dit niet mogelijk is
verzonden volgens de uitstelregels. Het is belangrijk om te begrijpen dat dit zo zal zijn
verschijnen als een uit de wachtrij gehaald pakket en het is gemakkelijk om ten onrechte aan te nemen dat het pakket dat wel was
verzonden sinds het door de verzendwachtrij is gegaan. In feite is een pakket eigenlijk
in dit geval door het netapparaat verwijderd. De reden voor dit gedrag is te wijten aan de
definitie van de Queue Drop-gebeurtenis. De m_traceDrop-gebeurtenis wordt per definitie geactiveerd wanneer a
pakket kan niet in de verzendwachtrij worden geplaatst omdat deze vol is. Deze gebeurtenis wordt alleen geactiveerd
als de wachtrij vol is en we deze gebeurtenis niet overbelasten om aan te geven dat de CsmaChannel dat wel is
"vol."

Lager niveau (PHY) haken
Net als bij de traceerhaken op het bovenste niveau, zijn er traceerhaken beschikbaar op het lagere niveau
niveaus van het nettoapparaat. Wij noemen dit de PHY-haken. Deze gebeurtenissen worden vanaf het apparaat geactiveerd
methoden die rechtstreeks met het CsmaChannel communiceren.

De traceringsbron m_dropTrace wordt aangeroepen om een ​​pakket aan te geven dat door het apparaat is verwijderd.
Dit gebeurt in twee gevallen: Ten eerste als de ontvangstzijde van het netwerkapparaat niet is ingeschakeld
(zie CsmaNetDevice::m_receiveEnable en het bijbehorende attribuut "ReceiveEnable").

De m_dropTrace wordt ook gebruikt om aan te geven dat een pakket als corrupt is weggegooid als a
ontvangen foutmodel wordt gebruikt (zie CsmaNetDevice::m_receiveErrorModel en het bijbehorende
attribuut "ReceiveErrorModel").

De andere traceringsbron op laag niveau wordt geactiveerd bij ontvangst van een geaccepteerd pakket (zie
CsmaNetDevice::m_rxTrace). Een pakket wordt geaccepteerd als het bestemd is voor de uitzending
adres, een multicast-adres of het MAC-adres dat aan het netwerkapparaat is toegewezen.

Samenvatting
Het ns3 CSMA-model is een simplistisch model van een Ethernet-achtig netwerk. Het ondersteunt een
Carrier-Sense-functie en maakt meerdere toegang tot een gedeeld medium mogelijk. Het is niet
fysiek in de zin dat de toestand van het medium onmiddellijk door iedereen wordt gedeeld
apparaten. Dit betekent dat er in dit model geen botsingsdetectie nodig is en ook geen
is geïmplementeerd. Er zal nooit sprake zijn van een "storing" van een pakket dat al op het medium staat. Toegang tot
voor het gedeelde kanaal geldt: wie het eerst komt, het eerst maalt, zoals bepaald door de simulator
planner. Als wordt vastgesteld dat het kanaal bezet is door naar de mondiale toestand te kijken, a
Er wordt een willekeurige exponentiële uitstel uitgevoerd en er wordt een nieuwe poging ondernomen.

Ns-3-attributen bieden een mechanisme voor het instellen van verschillende parameters in het apparaat en
kanaal zoals adressen, inkapselingsmodi en selectie van foutmodellen. Traceerhaken zijn dat wel
op de gebruikelijke wijze voorzien van een stel haken op het hoogste niveau die overeenkomen met een uitzending
wachtrij en gebruikt bij ASCII-tracering; en ook een set haken op een lager niveau die worden gebruikt bij pcap-tracing.

Hoewel de ns-3 CsmaChannel en CsmaNetDevice geen enkel soort netwerk modelleren
zou kunnen bouwen of kopen, biedt het ons wel een aantal nuttige functionaliteiten. Je zou moeten,
Begrijp echter dat het expliciet geen Ethernet of een andere vorm van IEEE 802.3 is, maar een
interessante deelverzameling.

GEGEVENS COLLECTIE

Dit hoofdstuk beschrijft het ns-3 Data Collection Framework (DCF), dat hierin voorziet
mogelijkheden om gegevens te verkrijgen die zijn gegenereerd door modellen in de simulator, om online uit te voeren
reductie en gegevensverwerking, en om onbewerkte of getransformeerde gegevens om te zetten in verschillende output
formaten.

Het raamwerk ondersteunt momenteel stand-alone ns-3-runs die niet afhankelijk zijn van een externe
controle van de uitvoering van het programma. De door de DCF ter beschikking gestelde objecten mogen worden vastgehaakt ns-3 opsporen
bronnen om gegevensverwerking mogelijk te maken.

De broncode voor de klassen bevindt zich in de directory src/statistieken.

Dit hoofdstuk is als volgt opgebouwd. Eerst wordt een overzicht van de architectuur gegeven
gepresenteerd. Vervolgens worden de helpers voor deze klassen voorgesteld; deze eerste behandeling
zou basisgebruik van het raamwerk voor gegevensverzameling voor veel gebruikssituaties mogelijk moeten maken. Gebruikers die
output willen produceren buiten het bereik van de huidige helpers, of die willen creëren
hun eigen gegevensverzamelingsobjecten, zouden de rest van het hoofdstuk moeten lezen, dat gaat
in detail over alle standaard DCF-objecttypen en biedt codering op laag niveau
voorbeelden.

Design
De DCF bestaat uit drie basisklassen:

· Sonde is een mechanisme om de uitvoer van simulatiegegevens te instrumenteren en te regelen
gebruikt om interessante gebeurtenissen te volgen. Het produceert uitvoer in de vorm van een of meer ns-3
bronnen traceren. Probe-objecten zijn gekoppeld aan een of meer sporen wastafels (Zogenaamde
Verzamelaars), die monsters online verwerken en voorbereiden voor uitvoer.

· Verzamelaar verbruikt de gegevens die zijn gegenereerd door een of meer Probe-objecten. Het presteert
transformaties op de gegevens, zoals normalisatie, reductie en de berekening van
basisstatistieken. Collector-objecten produceren geen gegevens die rechtstreeks worden uitgevoerd door het
ns-3 rennen; in plaats daarvan voeren ze gegevens stroomafwaarts uit naar een ander type object, genaamd
Aggregator, die die functie vervult. Meestal voeren verzamelaars hun gegevens uit in
ook de vorm van sporenbronnen, waardoor collectoren in serie kunnen worden geketend.

· Aggregator is het eindpunt van de gegevens die zijn verzameld door een netwerk van Probes en Collectors.
De belangrijkste verantwoordelijkheid van de aggregator is het ordenen van gegevens en hun correspondentie
metadata, in verschillende uitvoerformaten zoals platte tekstbestanden, spreadsheetbestanden of
databases.

Alle drie deze klassen bieden de mogelijkheid om zichzelf dynamisch in of uit te schakelen
tijdens een simulatie.

Elke zelfstandige ns-3 simulatierun die de DCF gebruikt, zal er doorgaans minstens één maken
exemplaar van elk van de drie bovenstaande klassen.
[afbeelding] Overzicht gegevensverzamelingskader.UNINDENT

De totale stroom van gegevensverwerking wordt weergegeven in Data Collectie Kader overzicht.
Aan de linkerkant een rennende ns-3 simulatie is afgebeeld. Tijdens het runnen van de
simulatie worden gegevens beschikbaar gesteld door modellen via sporenbronnen of op andere manieren.
Het diagram laat zien dat sondes kunnen worden aangesloten op deze traceerbronnen om gegevens te ontvangen
asynchroon, of sondes kunnen gegevens opvragen. De gegevens worden vervolgens doorgegeven aan een verzamelobject
die de gegevens transformeert. Tenslotte kan een aggregator worden aangesloten op de uitgangen van de
collector, om plots, bestanden of databases te genereren.
[afbeelding] Data Collection Framework-aggregatie.UNINDENT

Een variatie op de bovenstaande figuur wordt gegeven in Data Collectie Kader aggregatie.
Deze tweede figuur illustreert dat de DCF-objecten op een bepaalde manier aan elkaar kunnen worden geketend
dat stroomafwaartse objecten invoer ontvangen van meerdere stroomopwaartse objecten. Het figuur
laat conceptueel zien dat meerdere sondes uitvoer kunnen genereren die in één sonde wordt ingevoerd
verzamelaar; een collector die een verhouding van twee tellers uitvoert, zou dat bijvoorbeeld doen
verkrijg typisch elke tellergegevens van afzonderlijke sondes. Meerdere verzamelaars kunnen ook
invoer in een enkele aggregator, die (zoals de naam al aangeeft) een aantal gegevens kan verzamelen
streams voor opname in een enkele plot, bestand of database.

Data Collectie helpers
De volledige flexibiliteit van het raamwerk voor gegevensverzameling wordt geboden door de onderlinge verbinding
van sondes, verzamelaars en aggregators. Het uitvoeren van al deze onderlinge verbindingen leidt tot
veel configuratie-instructies in gebruikersprogramma's. Voor gebruiksgemak, enkele van de meest voorkomende
bewerkingen kunnen worden gecombineerd en ingekapseld in helperfuncties. Daarnaast enkele
verklaringen met betrekking tot ns-3 traceerbronnen hebben geen Python-bindingen vanwege beperkingen in
de bindingen.

Data Collectie helpers Overzicht
In deze sectie geven we een overzicht van enkele helperklassen die zijn gemaakt voor
vergemakkelijk de configuratie van het raamwerk voor gegevensverzameling voor enkele veelvoorkomende gebruikssituaties. De
helpers stellen gebruikers in staat om gemeenschappelijke bewerkingen te vormen met slechts een paar instructies in hun C ++ of
Python-programma's. Maar dit gebruiksgemak gaat ten koste van aanzienlijk minder
flexibiliteit dan configuratie op laag niveau kan bieden, en de noodzaak om expliciet te coderen
ondersteuning voor nieuwe sondetypen in de helpers (om een ​​hieronder beschreven probleem te omzeilen).

De nadruk bij de huidige helpers ligt op het verzamelen van gegevens ns-3 bronnen opsporen
gnuplot-plots of tekstbestanden, zonder een hoge mate van uitvoeraanpassing of statistiek
verwerking (aanvankelijk). Ook is het gebruik beperkt tot de beschikbare sondetypes
ns-3. Latere secties van deze documentatie gaan dieper in op het maken van nieuwe
Sondetypes, evenals details over het aan elkaar koppelen van sondes, verzamelaars en aggregators
in arrangementen op maat.

Tot op heden zijn er twee helpers voor gegevensverzameling geïmplementeerd:

· GnuplotHelper

· Bestandshelper

GnuplotHelper
De GnuplotHelper is een hulpklasse voor het produceren van uitvoerbestanden die worden gebruikt om gnuplots te maken. De
Het algemene doel is om gebruikers de mogelijkheid te bieden om snel grafieken te maken van geëxporteerde gegevens
in ns-3 bronnen traceren. Standaard wordt een minimale hoeveelheid gegevenstransformatie uitgevoerd;
het doel is om plots te genereren met zo min mogelijk (standaard) configuratie-instructies
mogelijk.

GnuplotHelper Overzicht
De GnuplotHelper zal aan het einde van de simulatie 3 verschillende bestanden aanmaken:

· Een door spaties gescheiden gnuplot-gegevensbestand

· Een gnuplot-controlebestand

· Een shellscript om de gnuplot te genereren

Er zijn twee configuratie-instructies die nodig zijn om plots te produceren. De eerste
instructie configureert de plot (bestandsnaam, titel, legenda's en uitvoertype, waarbij de uitvoer
typ standaard naar PNG indien niet gespecificeerd):

void ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::tekenreeks &titel,
const std::tekenreeks &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

De tweede verklaring haakt de traceerbron van belang:

void PlotProbe (const std::string &typeId,
const std::tekenreeks &pad,
const std::string &probeTraceSource,
const std::tekenreeks &titel);

De argumenten zijn als volgt:

· typeId: De ns-3 TypeId van de sonde

· pad: Het pad in de ns-3 configuratienaamruimte naar een of meer traceerbronnen

· probeTraceSource: Welke uitvoer van de sonde (zelf een traceerbron) moet worden geplot

· titel: de titel die aan de dataset(s) moet worden gekoppeld (in de gnuplot-legenda)

Een variant op de bovenstaande PlotProbe is het specificeren van een vijfde optioneel argument dat controleert
waar in de plot de sleutel (legenda) is geplaatst.

Een volledig uitgewerkt voorbeeld (van zevende.cc) wordt hieronder weergegeven:

// Maak de gnuplot-helper.
GnuplotHelper plotHelper;

// Configureer de plot.
// Configureer de plot. Het eerste argument is het voorvoegsel van de bestandsnaam
// voor de gegenereerde uitvoerbestanden. De tweede, derde en vierde
// argumenten zijn respectievelijk de plottitel, x-as en y-as labels
plotHelper.ConfigurePlot ("zevende-packet-byte-count",
"Pakketbytetelling vs. tijd",
"Tijd (seconden)",
"Aantal pakketbytes",
"png");

// Specificeer het sondetype, het traceerbronpad (in de configuratienaamruimte) en
// probe output trace source ("OutputBytes") om te plotten. Het vierde argument
// specificeert de naam van het gegevensreekslabel op de plot. De laatste
// argument maakt de plot op door op te geven waar de sleutel moet worden geplaatst.
plotHelper.PlotProbe (probeType,
tracePad,
"Uitvoerbytes",
"Aantal pakketbytes",
GnuplotAggregator::KEY_BELOW);

In dit voorbeeld is de probeType en tracePath zijn als volgt (voor IPv4):

probeType = "ns3::Ipv4PacketProbe";
tracePath = "/NodeList/*/$ns3::Ipv4L3Protocol/Tx";

Het probeType is een sleutelparameter om deze helper te laten werken. Dit TypeId moet worden geregistreerd
in het systeem en de handtekening op de trace-sink van de sonde moet overeenkomen met die van de trace
bron waaraan het is gekoppeld. Sondetypen zijn vooraf gedefinieerd voor een aantal gegevenstypen
overeenkomstig met ns-3 getraceerde waarden, en voor een paar andere traceerbronhandtekeningen zoals
de 'Tx' traceerbron van ns3::Ipv4L3-protocol klasse.

Houd er rekening mee dat het opgegeven traceerbronpad jokertekens kan bevatten. In dit geval meerdere
datasets worden geplot op één plot; één voor elk overeenkomend pad.

De geproduceerde hoofduitvoer bestaat uit drie bestanden:

zevende-packet-byte-count.dat
zevende-packet-byte-count.plt
zevende-packet-byte-count.sh

Op dit moment kunnen gebruikers het .plt-bestand met de hand bewerken voor verdere aanpassingen, of
voer het gewoon door gnuplot. Rennen sh zevende-packet-byte-count.sh voert gewoon de plot uit
via gnuplot, zoals hieronder weergegeven.
[afbeelding] 2-D Gnuplot Gemaakt door zevende.cc Voorbeeld..UNINDENT

Het is te zien dat de belangrijkste elementen (legenda, titel, plaatsing van legenda, xlabel, ylabel,
en pad voor de gegevens) worden allemaal op de plot geplaatst. Omdat er twee wedstrijden waren voor de
configuratiepad beschikbaar, worden de twee gegevensreeksen weergegeven:

· Packet Byte Count-0 komt overeen met /NodeList/0/$ns3::Ipv4L3Protocol/Tx

· Packet Byte Count-1 komt overeen met /NodeList/1/$ns3::Ipv4L3Protocol/Tx

GnuplotHelper ConfigureerPlot
De GnuplotHelper's ConfigureerPlot() functie kan worden gebruikt om plots te configureren.

Het heeft het volgende prototype:

void ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::tekenreeks &titel,
const std::tekenreeks &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

Het heeft de volgende argumenten:

┌───────────────────────────────┬─────── ────────── ─────────────────┐
│Argument │ Beschrijving │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│outputFileNameWithoutExtension │ Naam van gnuplot-gerelateerde bestanden naar │
│ │ schrijven zonder extensie. │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│titel │ Plottitelreeks om te gebruiken voor │
│ │ dit perceel. │
└───────────────────────────────┴─────── ────────── ─────────────────┘

│xLegend │ De legenda voor de x horizontaal │
│ │ as. │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│yLegend │ De legenda voor de y-verticaal │
│ │ as. │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│terminalType │ Instelreeks voor terminaltype voor │
│ │ uitvoer. De standaardterminal │
│ │ type is "png". │
└───────────────────────────────┴─────── ────────── ─────────────────┘

De GnuplotHelper's ConfigureerPlot() functie configureert hiervoor plotgerelateerde parameters
gnuplot-helper zodat het een door spaties gescheiden gnuplot-gegevensbestand met de naam
outputFileNameWithoutExtension + ".dat", een gnuplot-besturingsbestand met de naam
outputFileNameWithoutExtension + ".plt", en een shellscript om de gnuplot named
outputFileNameWithoutExtension + ".sh".

Een voorbeeld van het gebruik van deze functie is te zien in de zevende.cc hierboven beschreven code
waar het als volgt werd gebruikt:

plotHelper.ConfigurePlot ("zevende-packet-byte-count",
"Pakketbytetelling vs. tijd",
"Tijd (seconden)",
"Aantal pakketbytes",
"png");

GnuplotHelper Plot Probe
De GnuplotHelper's PlotProbe() functie kan worden gebruikt om waarden uit te zetten die zijn gegenereerd door sondes.

Het heeft het volgende prototype:

void PlotProbe (const std::string &typeId,
const std::tekenreeks &pad,
const std::string &probeTraceSource,
const std::tekenreeks &titel,
enum GnuplotAggregator::KeyLocation keyLocation = GnuplotAggregator::KEY_INSIDE);

Het heeft de volgende argumenten:

┌─────────────────┬───────────────────── ────────── ───┐
│Argument │ Beschrijving │
├─────────────────┼───────────────────── ────────── ───┤
│typeId │ De type-ID voor de sonde │
│ │ gemaakt door deze helper. │
├─────────────────┼───────────────────── ────────── ───┤
│pad │ Configuratiepad voor toegang tot de tracering │
│ │ bron. │
├─────────────────┼───────────────────── ────────── ───┤
│probeTraceSource │ De sondetraceerbron naar │
│ │ toegang. │
├─────────────────┼───────────────────── ────────── ───┤
│titel │ De titel die moet worden gekoppeld aan │
│ │ deze dataset │
├─────────────────┼───────────────────── ────────── ───┤
│keyLocation │ De locatie van de sleutel in de │
│ │ plot. De standaardlocatie is │
│ │ binnen. │
└─────────────────┴───────────────────── ────────── ───┘

De GnuplotHelper's PlotProbe() functie plot een dataset die is gegenereerd door de ns-3
traceer de bron met een sonde die door de helper is gemaakt en plot vervolgens de waarden van de
probeTraceSource. De dataset krijgt de opgegeven titel en bestaat uit de
'newValue' bij elke tijdstempel.

Als het configuratiepad meer dan één overeenkomst heeft in het systeem omdat er een jokerteken is, dan
voor elke match wordt één dataset geplot. De titels van de dataset krijgen het achtervoegsel
overeenkomende tekens voor elk van de jokertekens in het configuratiepad, gescheiden door spaties. Voor
als de titel van de voorgestelde dataset bijvoorbeeld de tekenreeks "bytes" is en er twee jokertekens zijn
in het pad, dan zijn datasettitels zoals "bytes-0 0" of "bytes-12 9" mogelijk als
labels voor de datasets die worden geplot.

Een voorbeeld van het gebruik van deze functie is te zien in de zevende.cc hierboven beschreven code
waar het als volgt werd gebruikt (met variabele vervanging):

plotHelper.PlotProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Uitvoerbytes",
"Aantal pakketbytes",
GnuplotAggregator::KEY_BELOW);

Overige Voorbeelden
gnuplot Helper Voorbeeld
Een iets eenvoudiger voorbeeld dan de zevende.cc voorbeeld is te vinden in
src/stats/examples/gnuplot-helper-example.cc. De volgende 2D-gnuplot is gemaakt met behulp van
het voorbeeld.
[afbeelding] 2-D Gnuplot Gemaakt door gnuplot-helper-example.cc Voorbeeld..UNINDENT

In dit voorbeeld is er een Emitter-object dat zijn teller verhoogt volgens a
Poisson-proces en zendt vervolgens de waarde van de teller uit als een traceerbron.

Ptr zender = CreateObject ();
Namen::Toevoegen ("/Namen/Zender", zender);

Merk op dat omdat er geen jokertekens in het onderstaande pad zijn gebruikt, er slechts 1 datastroom was
getekend in het perceel. Deze enkele datastroom in de plot wordt simpelweg "Emitter Count" genoemd,
zonder extra achtervoegsels zoals men zou zien als er wildcards in het pad waren.

// Maak de gnuplot-helper.
GnuplotHelper plotHelper;

// Configureer de plot.
plotHelper.ConfigurePlot ("gnuplot-helper-voorbeeld",
"Emittertellingen vs. tijd",
"Tijd (seconden)",
"Aantal zenders",
"png");

// Zet de waarden uit die door de sonde zijn gegenereerd. Het pad dat we bieden
// helpt bij het ondubbelzinnig maken van de bron van het spoor.
plotHelper.PlotProbe ("ns3::Uinteger32Probe",
"/Namen/Zender/Teller",
"Uitvoer",
"Aantal zenders",
GnuplotAggregator::KEY_INSIDE);

Bestandshelper
De FileHelper is een hulpklasse die wordt gebruikt om gegevenswaarden in een bestand te plaatsen. Het algemene doel is
om gebruikers de mogelijkheid te bieden om snel opgemaakte tekstbestanden te maken van geëxporteerde gegevens
in ns-3 bronnen traceren. Standaard wordt een minimale hoeveelheid gegevenstransformatie uitgevoerd;
het doel is om bestanden te genereren met zo weinig (standaard) configuratie-instructies als
mogelijk.

Bestandshelper Overzicht
De FileHelper zal aan het einde van de simulatie 1 of meer tekstbestanden aanmaken.

De FileHelper kan 4 verschillende soorten tekstbestanden aanmaken:

· Geformatteerd

· Spatie gescheiden (standaard)

· Kommagescheiden

· Tab gescheiden

Geformatteerde bestanden gebruiken tekenreeksen in C-stijl en de functie sprintf() om hun bestanden af ​​te drukken
waarden in het bestand dat wordt geschreven.

Het volgende tekstbestand met 2 kolommen met opgemaakte waarden met de naam
zevende-packet-byte-count-0.txt is gemaakt met behulp van meer nieuwe code die is toegevoegd aan de
origineel ns-3 De code van het zelfstudievoorbeeld. Alleen de eerste 10 regels van dit bestand worden getoond
hier kortheidshalve.

Tijd (seconden) = 1.000e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.004e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.004e+00 Aantal pakketbytes = 576
Tijd (seconden) = 1.009e+00 Aantal pakketbytes = 576
Tijd (seconden) = 1.009e+00 Aantal pakketbytes = 576
Tijd (seconden) = 1.015e+00 Aantal pakketbytes = 512
Tijd (seconden) = 1.017e+00 Aantal pakketbytes = 576
Tijd (seconden) = 1.017e+00 Aantal pakketbytes = 544
Tijd (seconden) = 1.025e+00 Aantal pakketbytes = 576
Tijd (seconden) = 1.025e+00 Aantal pakketbytes = 544

...

Het volgende verschillende tekstbestand met 2 kolommen met opgemaakte waarden met de naam
zevende-packet-byte-count-1.txt is ook gemaakt met dezelfde nieuwe code waaraan is toegevoegd
het origineel ns-3 De code van het zelfstudievoorbeeld. Alleen de eerste 10 regels van dit bestand worden getoond
hier kortheidshalve.

Tijd (seconden) = 1.002e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.007e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.013e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.020e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.028e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.036e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.045e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.053e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.061e+00 Aantal pakketbytes = 40
Tijd (seconden) = 1.069e+00 Aantal pakketbytes = 40

...

De nieuwe code die is toegevoegd om de twee tekstbestanden te produceren, staat hieronder. Meer details over
deze API wordt in een later gedeelte behandeld.

Merk op dat omdat er 2 overeenkomsten waren voor het jokerteken in het pad, 2 afzonderlijke tekstbestanden
werden gecreëerd. Het eerste tekstbestand, genaamd "seventh-packet-byte-count-0.txt",
komt overeen met de jokertekenovereenkomst waarbij de "*" is vervangen door "0". Het tweede tekstbestand,
met de naam "seventh-packet-byte-count-1.txt", komt overeen met de jokertekenovereenkomst met
de "*" vervangen door "1". Merk ook op dat de functie call to SchrijfProbe() zal een geven
foutmelding als er geen overeenkomsten zijn voor een pad dat jokertekens bevat.

// Maak de bestandshelper.
BestandsHelper bestandHelper;

// Configureer het te schrijven bestand.
fileHelper.ConfigureFile ("zevende-packet-byte-count",
FileAggregator::GEFORMATEERD);

// Stel de labels in voor dit geformatteerde uitvoerbestand.
fileHelper.Set2dFormat ("Tijd (seconden) = %.3e\tPacket Byte Count = %.0f");

// Schrijf de waarden die door de sonde zijn gegenereerd.
fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Uitvoerbytes");

Bestandshelper ConfigureerBestand
De FileHelper's ConfigureerBestand() functie kan worden gebruikt om tekstbestanden te configureren.

Het heeft het volgende prototype:

ongeldig ConfigureFile (const std::string &outputFileNameWithoutExtension,
enum FileAggregator::FileType fileType = FileAggregator::SPACE_SEPARATED);

Het heeft de volgende argumenten:

┌───────────────────────────────┬─────── ────────── ─────────────────┐
│Argument │ Beschrijving │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│outputFileNameWithoutExtension │ Naam van uitvoerbestand om te schrijven │
│ │ zonder verlenging. │
├───────────────────────────────┼─────── ────────── ─────────────────┤
│fileType │ Type bestand om te schrijven. De │
│ │ standaard type bestand is ruimte │
│ │ gescheiden. │
└───────────────────────────────┴─────── ────────── ─────────────────┘

De FileHelper's ConfigureerBestand() functie configureert tekstbestand gerelateerde parameters voor de
file helper zodat het een bestand met de naam outputFileNameWithoutExtension plus aanmaakt
mogelijke extra informatie van wildcard-overeenkomsten plus ".txt" met waarden afgedrukt als
gespecificeerd door bestandstype. Het standaard bestandstype is door spaties gescheiden.

Een voorbeeld van het gebruik van deze functie is te zien in de zevende.cc hierboven beschreven code
waar het als volgt werd gebruikt:

fileHelper.ConfigureFile ("zevende-packet-byte-count",
FileAggregator::GEFORMATEERD);

Bestandshelper Schrijf Probe
De FileHelper's SchrijfProbe() functie kan worden gebruikt om waarden gegenereerd door sondes naar te schrijven
tekst bestanden.

Het heeft het volgende prototype:

leegte WriteProbe (const std::string &typeId,
const std::tekenreeks &pad,
const std::string &probeTraceSource);

Het heeft de volgende argumenten:

┌─────────────────┬───────────────────── ────────── ───┐
│Argument │ Beschrijving │
├─────────────────┼───────────────────── ────────── ───┤
│typeId │ Het type-ID voor de sonde die moet zijn │
│ │ gemaakt. │
├─────────────────┼───────────────────── ────────── ───┤
│pad │ Configuratiepad voor toegang tot de tracering │
│ │ bron. │
├─────────────────┼───────────────────── ────────── ───┤
│probeTraceSource │ De sondetraceerbron naar │
│ │ toegang. │
└─────────────────┴───────────────────── ────────── ───┘

De FileHelper's SchrijfProbe() functie maakt uitvoertekstbestanden die zijn gegenereerd door de
ns-3 traceerbron met een sonde gemaakt door de helper, en schrijf vervolgens de waarden van de
probeTraceSource. De namen van de uitvoerbestanden hebben de tekst opgeslagen in de lidvariabele
m_outputFileNameWithoutExtension plus ".txt", en zal bestaan ​​uit de 'newValue' bij elke
tijdstempel.

Als het configuratiepad meer dan één overeenkomst heeft in het systeem omdat er een jokerteken is, dan
er wordt één uitvoerbestand voor elke match gemaakt. De uitvoerbestandsnamen bevatten de
tekst in m_outputFileNameWithoutExtension plus de overeenkomende tekens voor elk van de
jokertekens in het configuratiepad, gescheiden door streepjes, plus ".txt". Als de waarde bijvoorbeeld
in m_outputFileNameWithoutExtension is de string "packet-byte-count", en er zijn twee
jokertekens in het pad en voer vervolgens bestandsnamen uit zoals "packet-byte-count-0-0.txt" of
"packet-byte-count-12-9.txt" zal mogelijk zijn als namen voor de bestanden die zullen worden aangemaakt.

Een voorbeeld van het gebruik van deze functie is te zien in de zevende.cc hierboven beschreven code
waar het als volgt werd gebruikt:

fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Uitvoerbytes");

Overige Voorbeelden
Dien in Helper Voorbeeld
Een iets eenvoudiger voorbeeld dan de zevende.cc voorbeeld is te vinden in
src/stats/examples/file-helper-example.cc. Dit voorbeeld gebruikt alleen de FileHelper.

Het volgende tekstbestand met 2 kolommen met opgemaakte waarden met de naam bestand-helper-voorbeeld.txt
is gemaakt aan de hand van het voorbeeld. Alleen de eerste 10 regels van dit bestand worden hier getoond voor
beknoptheid.

Tijd (seconden) = 0.203 Telling = 1
Tijd (seconden) = 0.702 Telling = 2
Tijd (seconden) = 1.404 Telling = 3
Tijd (seconden) = 2.368 Telling = 4
Tijd (seconden) = 3.364 Telling = 5
Tijd (seconden) = 3.579 Telling = 6
Tijd (seconden) = 5.873 Telling = 7
Tijd (seconden) = 6.410 Telling = 8
Tijd (seconden) = 6.472 Telling = 9
...

In dit voorbeeld is er een Emitter-object dat zijn teller verhoogt volgens a
Poisson-proces en zendt vervolgens de waarde van de teller uit als een traceerbron.

Ptr zender = CreateObject ();
Namen::Toevoegen ("/Namen/Zender", zender);

Merk op dat er slechts 1 tekstbestand was omdat er geen jokertekens in het onderstaande pad staan
gemaakt. Dit enkele tekstbestand heet simpelweg "file-helper-example.txt", zonder extra's
achtervoegsels zoals u zou zien als er wildcards in het pad waren.

// Maak de bestandshelper.
BestandsHelper bestandHelper;

// Configureer het te schrijven bestand.
fileHelper.ConfigureFile ("file-helper-voorbeeld",
FileAggregator::GEFORMATEERD);

// Stel de labels in voor dit geformatteerde uitvoerbestand.
fileHelper.Set2dFormat ("Tijd (seconden) = %.3e\tCount = %.0f");

// Schrijf de waarden die door de sonde zijn gegenereerd. Het pad dat wij
// biedt hulp bij het ondubbelzinnig maken van de bron van het spoor.
fileHelper.WriteProbe ("ns3::Uinteger32Probe",
"/Namen/Zender/Teller",
"Uitvoer");

strekking en Beperkingen
Momenteel zijn alleen deze sondes geïmplementeerd en verbonden met de GnuplotHelper en
naar de FileHelper:

· Booleaanse sonde

· Dubbele sonde

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TijdProbe

· PakketProbe

· ApplicationPacketProbe

· IPv4PacketProbe

Deze sondes zijn daarom de enige TypeIds die beschikbaar zijn om in te gebruiken PlotProbe() en
SchrijfProbe().

In de volgende paragrafen behandelen we elk van de fundamentele objecttypen (Probe, Collector,
en Aggregator) in meer detail en laat zien hoe ze met elkaar kunnen worden verbonden
API op lager niveau.

Probes
In deze sectie worden de functionaliteiten beschreven die door de Probe-klasse worden geleverd aan een ns-3
simulatie, en geeft voorbeelden over hoe ze in een programma kunnen worden gecodeerd. Dit gedeelte is bedoeld voor
gebruikers die geïnteresseerd zijn in het ontwikkelen van simulaties met de ns-3 hulpmiddelen en het gebruik van de gegevens
Collection Framework, waarvan de klasse Probe deel uitmaakt, om gegevensuitvoer mee te genereren
de resultaten van hun simulatie.

Sonde Overzicht
Een Probe-object wordt verondersteld te zijn verbonden met een variabele uit de simulatie waarvan de waarden
tijdens het experiment relevant zijn voor de gebruiker. De sonde zal opnemen wat er was
waarden aangenomen door de variabele tijdens de simulatie en geef dergelijke gegevens door aan een andere
lid van het Data Collection Framework. Hoewel het buiten het bereik van deze sectie valt om
bespreken wat er gebeurt nadat de sonde zijn uitvoer heeft geproduceerd, is het voldoende om te zeggen dat, door
aan het einde van de simulatie heeft de gebruiker gedetailleerde informatie over welke waarden waren
opgeslagen in de variabele die tijdens de simulatie wordt onderzocht.

Meestal wordt een sonde aangesloten op een ns-3 spoor bron. Op deze manier, wanneer de
traceerbron exporteert een nieuwe waarde, de probe gebruikt de waarde (en exporteert deze stroomafwaarts
naar een ander object via zijn eigen traceerbron).

De sonde kan worden gezien als een soort filter op sporenbronnen. De belangrijkste redenen voor
mogelijk koppelen aan een sonde in plaats van rechtstreeks aan een traceerbron zijn als volgt:

· Probes kunnen dynamisch worden in- en uitgeschakeld tijdens de simulatie met oproepen naar Inschakelen()
en Uitzetten(). Het uitvoeren van gegevens kan bijvoorbeeld worden uitgeschakeld tijdens de
simulatie opwarmfase.

· Sondes kunnen bewerkingen op de gegevens uitvoeren om waarden uit meer gecompliceerde gegevens te extraheren
structuren; bijvoorbeeld het uitvoeren van de waarde van de pakketgrootte van een ontvangen ns3::pakket.

· Probes registreren een naam in de ns3::Config-naamruimte (met behulp van Namen::Toevoegen ()) zodat andere
objecten kunnen ernaar verwijzen.

· Probes bieden een statische methode waarmee men een Probe op naam kan manipuleren, zoals
wat wordt er gedaan in ns2measure [Cic06]

Stat::put ("my_metric", ID, voorbeeld);

Het ns-3-equivalent van de bovenstaande ns2measure-code is bijvoorbeeld

DoubleProbe::SetValueByPath ("/path/to/probe", voorbeeld);

Creatie
Merk op dat een Probe-basisklasseobject niet kan worden gemaakt omdat het een abstracte basis is
klasse, dwz het heeft pure virtuele functies die niet zijn geïmplementeerd. Een voorwerp van
type DoubleProbe, een subklasse van de klasse Probe, wordt hier gemaakt om te laten zien
wat gedaan moet worden.

Men declareert een DoubleProbe in dynamisch geheugen met behulp van de slimme pointerklasse (Ptr ). Naar
creëer een DoubleProbe in dynamisch geheugen met slimme pointers, je hoeft alleen maar de
ns-3 methode CreëerObject():

Ptr mijnsonde = CreateObject ();

De bovenstaande declaratie maakt DoubleProbes met de standaardwaarden voor de attributen.
Er zijn vier attributen in de klasse DoubleProbe; twee in het object van de basisklasse
DataCollectionObject, en twee in de Probe-basisklasse:

· "Naam" (DataCollectionObject), een StringValue

· "Ingeschakeld" (DataCollectionObject), een Booleaanse waarde

· "Start" (sonde), een tijdwaarde

· "Stop" (sonde), een tijdwaarde

Men kan dergelijke attributen instellen bij het maken van objecten door de volgende methode te gebruiken:

Ptr mijnsonde = CreateObjectWithAttributes (
"Naam", StringValue ("mijnprobe"),
"Ingeschakeld", Booleaanse Waarde (false),
"Start", tijdwaarde (seconden (100.0)),
"Stop", tijdwaarde (seconden (1000.0)));

Start en Stop zijn tijdvariabelen die het actie-interval van de sonde bepalen. De
De sonde voert alleen gegevens uit als de huidige tijd van de simulatie daarbinnen ligt
interval. De speciale tijdswaarde van 0 seconden voor Stop zal dit attribuut uitschakelen (bijv
houd de sonde aan gedurende de hele simulatie). Ingeschakeld is een vlag die de sonde inschakelt of
uit, en moet zijn ingesteld op waar om de sonde gegevens te laten exporteren. De naam is de naam van het object
in het DCF-kader.

Importeren en exporteren gegevens
ns-3 traceerbronnen zijn sterk getypeerd, dus de mechanismen voor het koppelen van sondes aan een spoor
bron en voor het exporteren van gegevens behoren tot zijn subklassen. Bijvoorbeeld de standaard
distributie van ns-3 biedt een klasse DoubleProbe die is ontworpen om aan een trace te koppelen
bron die een dubbele waarde exporteert. We zullen vervolgens de werking van de DoubleProbe gedetailleerd beschrijven, en
bespreek vervolgens hoe andere Probe-klassen door de gebruiker kunnen worden gedefinieerd.

Dubbele sonde Overzicht
De DoubleProbe maakt verbinding met een dubbele waarde ns-3 traceerbron en exporteert zelf een
verschillende dubbele waarde ns-3 spoor bron.

De volgende code, ontleend aan src/stats/examples/double-probe-example.cc, toont de basis
bewerkingen van het loodsen van de DoubleProbe in een simulatie, waar het een teller onderzoekt
geëxporteerd door een emitterobject (klasse Emitter).

Ptr zender = CreateObject ();
Namen::Toevoegen ("/Namen/Zender", zender);
...

Ptr probe1 = CreateObject ();

// Sluit de sonde aan op de teller van de zender
bool connected = probe1->ConnectByObject ("Teller", zender);

De volgende code onderzoekt dezelfde teller die is geëxporteerd door hetzelfde emitterobject. Dit
DoubleProbe gebruikt echter een pad in de configuratienaamruimte om het
verbinding. Merk op dat de zender zichzelf daarna registreerde in de configuratienaamruimte
het was gemaakt; anders zou ConnectByPath niet werken.

Ptr probe2 = CreateObject ();

// Let op, hier wordt geen retourwaarde gecontroleerd
probe2->ConnectByPath ("/Namen/Emitter/Teller");

De volgende weergegeven DoubleProbe die hieronder wordt weergegeven, heeft een waarde die wordt ingesteld met behulp van het pad naar binnen
de configuratienaamruimte. Merk op dat deze keer de DoubleProbe zichzelf registreerde in de
configuratienaamruimte nadat deze is gemaakt.

Ptr probe3 = CreateObject ();
probe3->SetName ("StaticallyAccessedProbe");

// We moeten het toevoegen aan de configuratiedatabase
Namen::Toevoegen ("/Namen/Probes", probe3->GetName (), probe3);

De functie Count() van de zender kan nu de waarde voor deze DoubleProbe instellen als
volgt:

komen te vervallen
Emitter::Count (ongeldig)
{
...
m_teller += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
...
}

Het bovenstaande voorbeeld laat zien hoe de code die de Probe aanroept geen expliciete code hoeft te hebben
verwijzing naar de Probe, maar kan de waarde-instelling sturen via de Config-naamruimte.
Dit is qua functionaliteit vergelijkbaar met de Stat::Zet methode geïntroduceerd door ns2measure paper
[Cic06], en stelt gebruikers in staat om tijdelijk Probe-statements zoals printf verklaringen
binnen bestaande ns-3 modellen. Let op om de DoubleProbe hierin te kunnen gebruiken
voorbeeld als dit, 2 dingen waren nodig:

1. het headerbestand van de stats-module is opgenomen in het voorbeeld .cc-bestand

2. het voorbeeld is afhankelijk gemaakt van de stats-module in zijn wscript-bestand.

Analoge dingen moeten worden gedaan om andere sondes op andere plaatsen in het systeem toe te voegen ns-3
codebasis.

De waarden voor de DoubleProbe kunnen ook worden ingesteld met de functie DoubleProbe::SetValue(),
terwijl de waarden voor de DoubleProbe kunnen worden verkregen met behulp van de functie
DoubleProbe::GetValue().

De DoubleProbe exporteert dubbele waarden in zijn traceerbron "Uitvoer"; een stroomafwaarts object
kan hier als volgt een trace-sink (NotifyViaProbe) aan koppelen:

connected = probe1->TraceConnect ("Uitvoer", probe1->GetName (), MakeCallback (&NotifyViaProbe));

Overige probes
Naast de DoubleProbe zijn de volgende Probes ook verkrijgbaar:

· Uinteger8Probe maakt verbinding met een ns-3 traceerbron exporteert een uint8_t.

· Uinteger16Probe maakt verbinding met een ns-3 traceerbron exporteert een uint16_t.

· Uinteger32Probe maakt verbinding met een ns-3 traceerbron exporteert een uint32_t.

· PacketProbe maakt verbinding met een ns-3 traceerbron die een pakket exporteert.

· ApplicationPacketProbe maakt verbinding met een ns-3 traceerbron die een pakket en een socket exporteert
adres.

· Ipv4PacketProbe maakt verbinding met een ns-3 traceerbron die een pakket, een IPv4-object en
een interface.

Wij creëren nieuwe Sonde types
Om een ​​nieuw sondetype te maken, moet u de volgende stappen uitvoeren:

· Zorg ervoor dat uw nieuwe Probe-klasse is afgeleid van de Probe-basisklasse.

· Zorg ervoor dat de puur virtuele functies die uw nieuwe Probe-klasse overneemt van de
Probe-basisklasse is geïmplementeerd.

· Zoek een bestaande Probe-klasse die een traceerbron gebruikt die qua type het dichtst bij de
type traceerbron die uw sonde gaat gebruiken.

· Kopieer het headerbestand (.h) en het implementatiebestand (.cc) van die bestaande Probe-klasse naar twee
nieuwe bestanden met namen die overeenkomen met uw nieuwe sonde.

· Vervang de typen, argumenten en variabelen in de gekopieerde bestanden door de juiste
typ voor uw sonde.

· Breng de nodige wijzigingen aan om de code te laten compileren en ervoor te zorgen dat deze zich gedraagt ​​zoals u zou doen
wilt.

Voorbeelden
Twee voorbeelden zullen hier in detail worden besproken:

· Voorbeeld van dubbele sonde

· Voorbeeld van IPv4-pakketplot

Dubbel Sonde Voorbeeld
Het voorbeeld van de dubbele sonde is eerder besproken. Het voorbeeldprogramma is te vinden
in src/stats/examples/double-probe-example.cc. Om samen te vatten wat er in dit programma gebeurt,
er is een emitter die een teller exporteert die oploopt volgens een Poisson-proces.
Er worden met name twee manieren getoond om gegevens uit te zenden:

1. via een getraceerde variabele gekoppeld aan één sonde:

Getraceerde waarde m_teller; // normaal zou dit een geheel getal zijn

2. via een teller waarvan de waarde wordt gepost naar een tweede sonde, waarnaar wordt verwezen met zijn naam in
het Config-systeem:

komen te vervallen
Emitter::Count (ongeldig)
{
NS_LOG_FUNCTION (deze);
NS_LOG_DEBUG ("Tellen bij " << Simulator::Now ().GetSeconds ());
m_teller += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
Simulator::Schedule (Seconden (m_var->GetValue ()), &Emitter::Count, dit);
}

Laten we de Probe eens wat nauwkeuriger bekijken. Sondes kunnen hun waarden in een veelvoud ontvangen
manieren:

1. doordat de sonde rechtstreeks toegang krijgt tot de traceerbron en er een traceer-sink op aansluit

2. door de sonde toegang te krijgen tot de traceerbron via de configuratienaamruimte en verbinding te maken met een
spoor er naar toe

3. door de aanroepende code expliciet de Probe's aan te roepen Waarde instellen() methode

4. door de aanroepcode expliciet aan te roepen SetValueByPath
("/path/through/Config/naamruimte", ...)

De eerste twee technieken zullen naar verwachting de meest voorkomende zijn. Ook in het voorbeeld, de
hooking van een normale callback-functie wordt weergegeven, zoals meestal wordt gedaan in ns-3. Deze
callback-functie is niet gekoppeld aan een Probe-object. We noemen dit geval 0) hieronder.

// Dit is een functie om het koppelen van een onbewerkte functie aan de traceerbron te testen
komen te vervallen
NotifyViaTraceSource (std::string context, dubbele oldVal, dubbele newVal)
{
NS_LOG_DEBUG ("context:" << context << "oud" << oldVal << "nieuw" << newVal);
}

Eerst moet de zender worden ingesteld:

Ptr zender = CreateObject ();
Namen::Toevoegen ("/Namen/Zender", zender);

// Het Emitter-object is niet gekoppeld aan een ns-3-knooppunt, dus
// het wordt niet automatisch gestart, dus we moeten dit zelf doen
Simulator::Schedule (seconden (0.0), &Emitter::Start, zender);

De verschillende DoubleProbes werken samen met de zender in het voorbeeld zoals hieronder getoond.

Geval 0):

// Het onderstaande toont typische functionaliteit zonder een sonde
// (verbind een sink-functie met een traceerbron)
//
connected = emitter->TraceConnect ("Teller", "voorbeeldcontext", MakeCallback (&NotifyViaTraceSource));
NS_ASSERT_MSG (verbonden, "Traceerbron niet verbonden");

zaak 1):

//
// Probe1 wordt rechtstreeks gekoppeld aan het Emitter-traceerbronobject
//

// probe1 wordt gekoppeld aan de Emitter-traceerbron
Ptr probe1 = CreateObject ();
// de naam van de sonde kan dienen als context in de tracering
probe1->SetName ("ObjectProbe");

// Sluit de sonde aan op de teller van de zender
connected = probe1->ConnectByObject ("Teller", zender);
NS_ASSERT_MSG (verbonden, "Traceerbron niet verbonden met probe1");

zaak 2):

//
// Probe2 wordt gekoppeld aan het Emitter-traceerbronobject door
// toegang krijgen via padnaam in de Config-database
//

// Maak nog een vergelijkbare sonde; dit zal aansluiten via een Config-pad
Ptr probe2 = CreateObject ();
probe2->SetName ("PathProbe");

// Let op, hier wordt geen retourwaarde gecontroleerd
probe2->ConnectByPath ("/Namen/Emitter/Teller");

geval 4) (geval 3 wordt in dit voorbeeld niet getoond):

//
// Probe3 wordt door de zender rechtstreeks via de
// statische methode SetValueByPath().
//
Ptr probe3 = CreateObject ();
probe3->SetName ("StaticallyAccessedProbe");
// We moeten het toevoegen aan de configuratiedatabase
Namen::Toevoegen ("/Namen/Probes", probe3->GetName (), probe3);

En tot slot laat het voorbeeld zien hoe de sondes kunnen worden gekoppeld om uitvoer te genereren:

// De sonde zelf zou uitvoer moeten genereren. De context die we bieden
// naar deze sonde (in dit geval de naam van de sonde) zal helpen om ondubbelzinnig te maken
// de bron van het spoor
connected = probe3->TraceConnect ("Uitvoer",
"/Namen/Probes/StaticallyAccessedProbe/Uitvoer",
MakeCallback (&NotifyViaProbe));
NS_ASSERT_MSG (verbonden, "Traceerbron niet .. verbonden met probe3-uitgang");

De volgende callback is in dit voorbeeld gekoppeld aan de Probe voor illustratieve doeleinden;
normaal gesproken zou de Probe aan een Collector-object zijn gekoppeld.

// Dit is een functie om te testen of deze aan de sonde-uitgang is gekoppeld
komen te vervallen
NotifyViaProbe (std::string context, dubbele oldVal, dubbele newVal)
{
NS_LOG_DEBUG ("context:" << context << "oud" << oldVal << "nieuw" << newVal);
}

IPv4 Pakket Plot Voorbeeld
Het IPv4-pakketplotvoorbeeld is gebaseerd op het vijfde.cc-voorbeeld uit de ns-3 Zelfstudie. Het
is te vinden in src/stats/examples/ipv4-packet-plot-example.cc.

knooppunt 0 knooppunt 1
+++++ +++
| ns-3TCP | | ns-3TCP |
+++++ +++
| 10.1.1.1 | | 10.1.1.2 |
+++++ +++
| punt naar punt | | punt naar punt |
+++++ +++
| |
+-------+

We kijken alleen naar de sonde, omdat deze illustreert dat sondes ook waarden uit kunnen pakken
structuren (in dit geval pakketten) en rapporteer die waarden eerder als uitvoer van traceerbronnen
dan alleen hetzelfde type gegevens door te geven.

Er zijn andere aspecten van dit voorbeeld die later in de documentatie worden uitgelegd.
De twee typen gegevens die worden geëxporteerd, zijn het pakket zelf (uitgang) en een telling van de
aantal bytes in het pakket (uitvoerbytes).

TypeId
Ipv4PacketProbe::GetTypeId ()
{
statisch TypeId tid = TypeId ("ns3::Ipv4PacketProbe")
.SetOuder ()
.Constructor toevoegen ()
.AddTraceSource ("Uitvoer",
"Het pakket plus zijn IPv4-object en interface die dienen als uitvoer voor deze sonde",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_output))
.AddTraceSource ("UitvoerBytes",
"Het aantal bytes in het pakket",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_outputBytes))
;
tijd teruggeven;
}

Wanneer de trace-sink van de sonde een pakket ontvangt en de sonde is ingeschakeld, wordt het uitgevoerd
het pakje erop uitgang trace-bron, maar het zal ook het aantal bytes op het
uitvoerbytes spoor bron.

komen te vervallen
Ipv4PacketProbe::TraceSink (Ptr pakket, Ptr ipv4, uint4_t-interface)
{
NS_LOG_FUNCTION (dit << pakket << ipv4 << interface);
als (IsIngeschakeld ())
{
m_pakket = pakket;
m_ipv4 = ipv4;
m_interface = interface;
m_output (pakket, ipv4, interface);

uint32_t packetSizeNew = pakket->GetSize ();
m_outputBytes (m_packetSizeOld, packetSizeNew);
m_packetSizeOld = pakketSizeNew;
}
}

Referenties
[Cic06]
Claudio Cicconetti, Enzo Mingozzi, Giovanni Stea, "Een geïntegreerd raamwerk voor
Effectieve gegevensverzameling en statistische analyse mogelijk maken met ns2, Workshop op
ns-2 (WNS2), Pisa, Italië, oktober 2006.

Verzamelaars
Deze sectie is een tijdelijke aanduiding om de functionaliteiten van de Collector te beschrijven
klas naar een ns-3 simulatie, en geeft voorbeelden over hoe ze in een programma kunnen worden gecodeerd.

Opmerking: Vanaf ns-3.18 zijn Collectors nog in ontwikkeling en nog niet als onderdeel geleverd
van het kader.

aggregators
In deze sectie worden de functionaliteiten beschreven die door de klasse Aggregator worden geleverd aan een ns-3
simulatie. Deze sectie is bedoeld voor gebruikers die geïnteresseerd zijn in het ontwikkelen van simulaties met de
ns-3 tools en het gebruik van het Data Collection Framework, waarvan de klasse Aggregator een
deel, om gegevensuitvoer te genereren met de resultaten van hun simulatie.

Aggregator Overzicht
Een Aggregator-object wordt verondersteld te worden gekoppeld aan een of meer traceerbronnen om dit te kunnen doen
invoer ontvangen. Aggregators zijn het eindpunt van de gegevens die door het netwerk van worden verzameld
Probes en Collectors tijdens de simulatie. Het is de taak van de aggregator om deze te nemen
waarden en zet ze om in hun uiteindelijke uitvoerformaat, zoals platte tekstbestanden,
spreadsheetbestanden, plots of databases.

Meestal is een aggregator verbonden met een of meer Collectors. Op deze manier, wanneer dan ook
de traceerbronnen van de Collectors exporteren nieuwe waarden, de aggregator kan de waarde zo verwerken
dat het kan worden gebruikt in het uiteindelijke uitvoerformaat waar de gegevenswaarden zich zullen bevinden na de
simulatie.

Let op het volgende over aggregators:

· Aggregators kunnen dynamisch worden in- en uitgeschakeld tijdens de simulatie met oproepen naar
Inschakelen() en Uitzetten(). Het samenvoegen van gegevens kan bijvoorbeeld worden uitgeschakeld tijdens
de simulatie-opwarmfase, wat betekent dat die waarden niet worden opgenomen in de finale
uitgangsmedium.

· Aggregators ontvangen gegevens van Collectors via callbacks. Wanneer een Collector is gekoppeld
naar een aggregator wordt TraceConnect aangeroepen om de tracering van de aggregator tot stand te brengen
sink-methode als callback.

Tot op heden zijn er twee aggregators geïmplementeerd:

· GnuplotAggregator

· BestandAggregator

GnuplotAggregator
De GnuplotAggregator produceert uitvoerbestanden die worden gebruikt om gnuplots te maken.

De GnuplotAggregator zal aan het einde van de simulatie 3 verschillende bestanden aanmaken:

· Een door spaties gescheiden gnuplot-gegevensbestand

· Een gnuplot-controlebestand

· Een shellscript om de gnuplot te genereren

Creatie
Hier wordt een object van het type GnuplotAggregator gemaakt om te laten zien wat er moet gebeuren.

Men declareert een GnuplotAggregator in dynamisch geheugen door gebruik te maken van de klasse smart pointer
(Ptr ). Om een ​​GnuplotAggregator in dynamisch geheugen met slimme aanwijzers te maken, is er maar één
moet bellen ns-3 methode CreëerObject(). De volgende code van
src/stats/examples/gnuplot-aggregator-example.cc laat zien hoe je dit doet:

string fileNameWithoutExtension = "gnuplot-aggregator";

// Maak een aggregator.
Ptr aggregator =
CreateObject (bestandsnaamZonderExtensie);

Het eerste argument voor de constructor, fileNameWithoutExtension, is de naam van het
gnuplot gerelateerde bestanden te schrijven zonder extensie. Deze GnuplotAggregator zal een
door spaties gescheiden gnuplot-gegevensbestand met de naam "gnuplot-aggregator.dat", een gnuplot-besturingsbestand
genaamd "gnuplot-aggregator.plt", en een shellscript om de gnuplot genaamd + te genereren
"gnuplot-aggregator.sh".

De gnuplot die wordt gemaakt, kan zijn sleutel op 4 verschillende locaties hebben:

· Geen sleutel

· Sleutel binnen de plot (de standaard)

· Toets boven de plot

· Toets onder de plot

De volgende opsommingswaarden voor de sleutellocatie van gnuplot zijn toegestaan ​​om de positie van de sleutel te specificeren:

enum sleutellocatie {
GEEN SLEUTEL,
KEY_INSIDE,
KEY_BOVEN,
SLEUTEL_BELOW
};

Als het gewenst was om de onderstaande sleutel te hebben in plaats van de standaardpositie van binnen, dan
je zou het volgende kunnen doen.

aggregator->SetKeyLocation(GnuplotAggregator::KEY_BELOW);

Voorbeelden
Een voorbeeld zal hier in detail worden besproken:

· Gnuplot Aggregator-voorbeeld

gnuplot Aggregator Voorbeeld
Een voorbeeld dat de GnuplotAggregator uitoefent, is te vinden in
src/stats/examples/gnuplot-aggregator-example.cc.

De volgende 2D-gnuplot is gemaakt aan de hand van het voorbeeld.
[afbeelding] 2-D Gnuplot Gemaakt door gnuplot-aggregator-example.cc Voorbeeld..UNINDENT

Deze code uit het voorbeeld laat zien hoe de GnuplotAggregator te bouwen zoals besproken
bovenstaand.

leegte Create2dPlot ()
{
namespace std; gebruiken;

string fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "Gnuplot Aggregator-plot";
string plotXAxisHeading = "Tijd (seconden)";
tekenreeks plotYAxisHeading = "Dubbele waarden";
string plotDatasetLabel = "Gegevenswaarden";
string datasetContext = "Dataset/Context/String";

// Maak een aggregator.
Ptr aggregator =
CreateObject (bestandsnaamZonderExtensie);

Er zijn verschillende GnuplotAggregator-attributen ingesteld, inclusief de 2D-dataset die zal worden
geplot.

// Stel de eigenschappen van de aggregator in.
aggregator->SetTerminal ("png");
aggregator->SetTitle (plotTitle);
aggregator->SetLegend (plotXAxisHeading, plotYAxisHeading);

// Voeg een dataset toe aan de aggregator.
aggregator->Add2dDataset (datasetContext, plotDatasetLabel);

// aggregator moet zijn ingeschakeld
aggregator->Inschakelen ();

Vervolgens worden de 2D-waarden berekend en wordt elke waarde afzonderlijk naar de
GnuplotAggregator met behulp van de Schrijf2d() functie.

dubbele tijd;
dubbele waarde;

// Maak de 2D-gegevensset.
voor (tijd = -5.0; tijd <= +5.0; tijd += 1.0)
{
// Bereken de 2D-kromme
//
// 2
// waarde = tijd .
//
waarde = tijd * tijd;

// Voeg dit punt toe aan de plot.
aggregator->Write2d (datasetContext, tijd, waarde);
}

// Schakel het loggen van gegevens voor de aggregator uit.
aggregator->Uitschakelen ();
}

BestandAggregator
De FileAggregator stuurt de ontvangen waarden naar een bestand.

De FileAggregator kan 4 verschillende soorten bestanden aanmaken:

· Geformatteerd

· Spatie gescheiden (standaard)

· Kommagescheiden

· Tab gescheiden

Geformatteerde bestanden gebruiken tekenreeksen in C-stijl en de functie sprintf() om hun bestanden af ​​te drukken
waarden in het bestand dat wordt geschreven.

Creatie
Hier wordt een object van het type FileAggregator gemaakt om te laten zien wat er moet gebeuren.

Men declareert een FileAggregator in dynamisch geheugen met behulp van de slimme pointerklasse (Ptr ).
Om een ​​FileAggregator in dynamisch geheugen met slimme pointers te maken, hoef je alleen maar te bellen
the ns-3 methode CreateObject. De volgende code van
src/stats/examples/file-aggregator-example.cc laat zien hoe je dit doet:

tekenreeks bestandsnaam = "file-aggregator-formatted-values.txt";

// Maak een aggregator met geformatteerde waarden.
Ptr aggregator =
CreateObject (bestandsnaam, bestandsaggregator::FORMATTED);

Het eerste argument voor de constructor, bestandsnaam, is de naam van het te schrijven bestand; de
tweede argument, bestandstype, is het type bestand dat moet worden geschreven. Deze FileAggregator maakt een
bestand met de naam "file-aggregator-formatted-values.txt" met de waarden afgedrukt zoals gespecificeerd door
fileType, dwz in dit geval geformatteerd.

De volgende opsommingswaarden van het bestandstype zijn toegestaan:

opsomming bestandstype {
GEFORMATTEERD,
SPACE_SEPARATED,
KOMMAGESCHEIDEN,
TAB_SEPARATED
};

Voorbeelden
Een voorbeeld zal hier in detail worden besproken:

· Voorbeeld van bestandsaggregator

Dien in Aggregator Voorbeeld
Een voorbeeld dat de FileAggregator oefent, is te vinden in
src/stats/examples/file-aggregator-example.cc.

Het volgende tekstbestand met 2 kolommen met waarden gescheiden door komma's is gemaakt met behulp van de
voorbeeld.

-5,25
-4,16
-3,9
-2,4
-1,1
0,0
1,1
2,4
3,9
4,16
5,25

Deze code uit het voorbeeld laat zien hoe je de FileAggregator opbouwt zoals besproken
bovenstaand.

void CreateCommaSeparatedFile ()
{
namespace std; gebruiken;

string fileName = "file-aggregator-comma-separated.txt";
string datasetContext = "Dataset/Context/String";

// Maak een aggregator.
Ptr aggregator =
CreateObject (bestandsnaam, bestandsaggregator::COMMA_SEPARATED);

FileAggregator-kenmerken zijn ingesteld.

// aggregator moet zijn ingeschakeld
aggregator->Inschakelen ();

Vervolgens worden de 2D-waarden berekend en wordt elke waarde afzonderlijk naar de
FileAggregator met behulp van de Schrijf2d() functie.

dubbele tijd;
dubbele waarde;

// Maak de 2D-gegevensset.
voor (tijd = -5.0; tijd <= +5.0; tijd += 1.0)
{
// Bereken de 2D-kromme
//
// 2
// waarde = tijd .
//
waarde = tijd * tijd;

// Voeg dit punt toe aan de plot.
aggregator->Write2d (datasetContext, tijd, waarde);
}

// Schakel het loggen van gegevens voor de aggregator uit.
aggregator->Uitschakelen ();
}

Het volgende tekstbestand met 2 kolommen met opgemaakte waarden is ook gemaakt met behulp van de
voorbeeld.

Tijd = -5.000e+00 Waarde = 25
Tijd = -4.000e+00 Waarde = 16
Tijd = -3.000e+00 Waarde = 9
Tijd = -2.000e+00 Waarde = 4
Tijd = -1.000e+00 Waarde = 1
Tijd = 0.000e+00 Waarde = 0
Tijd = 1.000e+00 Waarde = 1
Tijd = 2.000e+00 Waarde = 4
Tijd = 3.000e+00 Waarde = 9
Tijd = 4.000e+00 Waarde = 16
Tijd = 5.000e+00 Waarde = 25

Deze code uit het voorbeeld laat zien hoe je de FileAggregator opbouwt zoals besproken
bovenstaand.

leegte CreateFormattedFile ()
{
namespace std; gebruiken;

tekenreeks bestandsnaam = "file-aggregator-formatted-values.txt";
string datasetContext = "Dataset/Context/String";

// Maak een aggregator met geformatteerde waarden.
Ptr aggregator =
CreateObject (bestandsnaam, bestandsaggregator::FORMATTED);

FileAggregator-attributen zijn ingesteld, inclusief de C-stijl formaattekenreeks die moet worden gebruikt.

// Stel het formaat voor de waarden in.
aggregator->Set2dFormat ("Tijd = %.3e\tWaarde = %.0f");

// aggregator moet zijn ingeschakeld
aggregator->Inschakelen ();

Vervolgens worden de 2D-waarden berekend en wordt elke waarde afzonderlijk naar de
FileAggregator met behulp van de Schrijf2d() functie.

dubbele tijd;
dubbele waarde;

// Maak de 2D-gegevensset.
voor (tijd = -5.0; tijd <= +5.0; tijd += 1.0)
{
// Bereken de 2D-kromme
//
// 2
// waarde = tijd .
//
waarde = tijd * tijd;

// Voeg dit punt toe aan de plot.
aggregator->Write2d (datasetContext, tijd, waarde);
}

// Schakel het loggen van gegevens voor de aggregator uit.
aggregator->Uitschakelen ();
}

Adapters
In deze sectie worden de functionaliteiten beschreven die door de klasse Adapter worden geleverd aan een ns-3
simulatie. Deze sectie is bedoeld voor gebruikers die geïnteresseerd zijn in het ontwikkelen van simulaties met de
ns-3 tools en met behulp van het Data Collection Framework, waarvan de klasse Adapter deel uitmaakt,
om gegevensuitvoer te genereren met de resultaten van hun simulatie.

Opmerking: de term 'adapter' kan ook worden gespeld als 'adapter'; we kozen voor de spelling uitgelijnd
met de C++-standaard.

Adapter Overzicht
Een adapter wordt gebruikt om verbindingen te maken tussen verschillende typen DCF-objecten.

Tot op heden is er één adapter geïmplementeerd:

· TimeSeries-adapter

Tijd -Series Adapter
Met de TimeSeriesAdaptor kunnen Probes rechtstreeks verbinding maken met Aggregators zonder dat er een nodig is
Verzamelaar tussendoor.

Beide geïmplementeerde DCF-helpers gebruiken TimeSeriesAdaptors om gesondeerd te worden
waarden van verschillende typen en voer de huidige tijd uit plus de waarde met beide geconverteerd
om te verdubbelen.

De rol van de TimeSeriesAdaptor-klasse is die van een adapter, die onbewerkt gewaardeerd is
sonde gegevens van verschillende typen en voert een tuple van twee dubbele waarden uit. De eerste is een
tijdstempel, die kan worden ingesteld op verschillende resoluties (bijvoorbeeld seconden, milliseconden, enz.) in
de toekomst, maar die momenteel hard gecodeerd is in Seconden. De tweede is de omzetting van a
niet-dubbele waarde naar een dubbele waarde (eventueel met verlies van precisie).

Reikwijdte/beperkingen
In dit gedeelte worden de reikwijdte en beperkingen van het Data Collection Framework besproken.

Momenteel zijn alleen deze Probes geïmplementeerd in DCF:

· Booleaanse sonde

· Dubbele sonde

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TijdProbe

· PakketProbe

· ApplicationPacketProbe

· IPv4PacketProbe

Momenteel zijn er geen Collectors beschikbaar in de DCF, hoewel er een BasicStatsCollector is
ontwikkeling.

Momenteel zijn alleen deze aggregators geïmplementeerd in DCF:

· GnuplotAggregator

· BestandAggregator

Momenteel is alleen deze adapter geïmplementeerd in DCF:

Tijdreeksadapter.

toekomst Werk met
In dit gedeelte wordt ingegaan op de toekomstige werkzaamheden aan het kader voor gegevensverzameling.

Hier zijn enkele dingen die nog moeten gebeuren:

· Sluit meer sporenbronnen aan ns-3 code om meer waarden uit de simulator te halen.

· Implementeer meer soorten Probes dan er momenteel zijn.

· Implementeer meer dan alleen de enkele huidige 2-D Collector, BasicStatsCollector.

· Implementeer meer aggregators.

· Implementeer meer dan alleen adapters.

DSDV ROUTING

Destination-Sequenced Distance Vector (DSDV)-routeringsprotocol is een proactief,
tabelgestuurd routeringsprotocol voor MANET's ontwikkeld door Charles E. Perkins en Pravin
Bhagwat in 1994. Het gebruikt het aantal hoppen als maatstaf bij de routeselectie.

Dit model is ontwikkeld door the ResiliNets onderzoek groep aan de Universiteit van Kansas. A
papier over dit model bestaat op dit URL.

DSDV Routing Overzicht
DSDV-routeringstabel: elk knooppunt houdt een tabel bij met alle andere knooppunten die het heeft
rechtstreeks of via enkele buren bekend. Elk knooppunt heeft één vermelding in de
routeringstabel. De invoer bevat informatie over het laatst bekende IP-adres van het knooppunt
volgnummer en het aantal hops om dat knooppunt te bereiken. Samen met deze details de tafel
houdt ook de volgende hop-buurman bij om het bestemmingsknooppunt te bereiken, de tijdstempel van
de laatste update die voor dat knooppunt is ontvangen.

Het DSDV-updatebericht bestaat uit drie velden: Bestemmingsadres, Volgnummer en
Hoptelling.

Elk knooppunt gebruikt twee mechanismen om de DSDV-updates te verzenden. Zij zijn,

1.

Periodiek updates
Periodieke updates worden verzonden na elke m_periodicUpdateInterval(default:15s).
In deze update zendt het knooppunt zijn volledige routeringstabel uit.

2.

Trigger updates
Triggerupdates zijn kleine updates tussen de periodieke updates in. Deze updates
worden verzonden wanneer een knooppunt een DSDV-pakket ontvangt dat een verandering in zijn node heeft veroorzaakt
routeringstabel. Het originele document vermeldde niet duidelijk wanneer voor welke verandering
in de tabel moet een DSDV-update worden verzonden. De huidige implementatie verzendt
een update uit, ongeacht de wijziging in de routeringstabel.

De updates worden geaccepteerd op basis van de statistiek voor een bepaald knooppunt. De eerste factor
bepalend voor de acceptatie van een update is het volgnummer. Het moet de update accepteren
als het volgnummer van het updatebericht hoger is, ongeacht de metriek. Als de
update met hetzelfde volgnummer wordt ontvangen, dan wordt de update met de minste statistiek (hopCount)
krijgt voorrang.

In zeer mobiele scenario's is er een grote kans op routeschommelingen, dus we hebben de
concept van gewogen afwikkelingstijd waarbij een update met verandering in de metriek niet zal plaatsvinden
aangekondigd bij de buren. Het knooppunt wacht op de bezinkingstijd om er zeker van te zijn dat dit niet het geval is
de update van zijn oude buurman ontvangen voordat hij die update verstuurt.

De huidige implementatie omvat alle bovengenoemde kenmerken van DSDV. De huidige
De implementatie heeft ook een verzoekwachtrij om pakketten te bufferen waar geen routes naartoe bestaan
bestemming. De standaardinstelling is ingesteld op het bufferen van maximaal 5 pakketten per bestemming.

Referenties
Link naar het papier: http://portal.acm.org/citation.cfm?doïde=190314.190336

DSR ROUTING

Dynamic Source Routing (DSR)-protocol is een reactief routeringsprotocol dat speciaal is ontworpen
voor gebruik in multi-hop draadloze ad-hocnetwerken van mobiele knooppunten.

Dit model is ontwikkeld door the ResiliNets onderzoek groep aan de Universiteit van Kansas.

DSR Routing Overzicht
Dit model implementeert de basisspecificatie van het Dynamic Source Routing (DSR)-protocol.
De uitvoering is gebaseerd op RFC 4728, met enkele uitbreidingen en aanpassingen aan de RFC
specificaties.

DSR werkt op basis van on-demand gedrag. Daarom buffert ons DSR-model alle pakketten terwijl a
routeverzoekpakket (RREQ) wordt verspreid. We implementeren een pakketbuffer in
dsr-rsendbuff.cc. De pakketwachtrij implementeert het opschonen van oude pakketten en a
limiet voor wachtrijgrootte. Wanneer het pakket vanuit de verzendbuffer wordt verzonden, wordt het in de wachtrij geplaatst
onderhoudsbuffer voor bevestiging van de volgende hop.

De onderhoudsbuffer buffert vervolgens de reeds verzonden pakketten en wacht op de
melding van pakketbezorging. De werking van het protocol is sterk afhankelijk van een verbroken verbinding
detectie mechanisme. We implementeren de drie aanbevolen heuristieken op basis van de RFC als
volgt:

Ten eerste gebruiken we waar mogelijk linklaagfeedback, wat ook het snelste mechanisme is
deze drie om verbindingsfouten te detecteren. Een link wordt als verbroken beschouwd als er sprake is van frametransmissie
resulteert in een transmissiefout voor alle nieuwe pogingen. Dit mechanisme is bedoeld voor actief
linkt en werkt veel sneller dan wanneer deze er niet is. DSR kan de linklaag detecteren
transmissiefout en meld dit als defect. Er wordt een herberekening van routes geactiveerd
wanneer nodig. Als de gebruiker geen linklaagbevestiging wil gebruiken, kan dit worden afgestemd met
het kenmerk "LinkAcknowledgment" instellen op false in "dsr-routing.cc".

Ten tweede moet waar mogelijk gebruik worden gemaakt van passieve erkenning. Het knooppunt wordt ingeschakeld
"promiscue" ontvangstmodus, waarin het pakketten kan ontvangen die niet voor zichzelf bestemd zijn, en
wanneer het knooppunt de bezorging van dat datapakket op zijn bestemming verzekert, annuleert het de
passieve bevestigingstimer.

Ten slotte gebruiken we een netwerklaagbevestigingsschema om de ontvangst van een pakket te melden. Route
verzoekpakket wordt niet bevestigd of opnieuw verzonden.

De Route Cache-implementatie ondersteunt het verzamelen van oude vermeldingen en statussen
machine, zoals gedefinieerd in de norm. Het wordt geïmplementeerd als een STL-kaartcontainer. De sleutel is de
Bestemming IP Adres.

DSR werkt met directe toegang tot de IP-header en werkt tussen netwerk en transport
laag. Wanneer een pakket wordt verzonden vanaf de transportlaag, geeft het zichzelf door aan DSR en DSR
koptekst is toegevoegd.

We hebben twee cachingmechanismen: padcache en linkcache. De padcache slaat het geheel op
pad in de cache. De paden worden gesorteerd op basis van het aantal hops en wanneer er één pad is
niet kan worden gebruikt, gaan we naar het volgende pad. De linkcache is iets beter
ontwerp in de zin dat het verschillende subpaden gebruikt en gebruikmaakt van Implemented Link Cache
Dijsktra-algoritme, en dit deel wordt geïmplementeerd door Song Luan[e-mail beveiligd]>.

De volgende optionele protocoloptimalisaties zijn niet geïmplementeerd:

· Stroomstatus

· Eerste hop extern (F), laatste hop extern (L) vlaggen

· Omgaan met onbekende DSR-opties

·

Twee types of fout koppen:

1. optie stroomstatus niet ondersteund

2. niet-ondersteunde optie (gaat niet gebeuren in simulatie)

DSR -update in ns-3.17
Oorspronkelijk gebruikten we "TxErrHeader" in Ptr om de transmissiefout van a aan te geven
specifiek pakket in de linklaag, maar sindsdien werkte het niet helemaal correct
het pakket is verwijderd, deze header is niet opgenomen in het traceringsbestand. Wij gebruikten a
ander pad bij het implementeren van het meldingsmechanisme op de linklaag. Wij kijken in de
trace-bestand door de pakketontvangstgebeurtenis te vinden. Als we één ontvangstgebeurtenis voor de gegevens vinden
pakket, we beschouwen dat als de indicator voor succesvolle gegevenslevering.

Nuttig parameters
+----------------------- +---------------------- ------------+------------+
| Parameter | Beschrijving | Standaard |
+==========================+===================== ==============+=============+
| MaxSendBuffLen | Maximaal aantal pakketten dat | 64 |
| | worden opgeslagen in verzendbuffer | |
+----------------------- +---------------------- ------------+------------+
| MaxSendBuffTime | Maximale tijd dat pakketten in de wachtrij kunnen worden geplaatst | seconden(30) |
| | in de verzendbuffer | |
+----------------------- +---------------------- ------------+------------+
| MaxMaintLen | Maximaal aantal pakketten dat | 50 |
| | worden opgeslagen in onderhoudsbuffer | |
+----------------------- +---------------------- ------------+------------+
| MaxMaintTime | Maximale tijd dat pakketten in de wachtrij kunnen worden geplaatst | seconden(30) |
| | in onderhoudsbuffer | |
+----------------------- +---------------------- ------------+------------+
| MaxCacheLen | Maximaal aantal route-invoeren | 64 |
| | die kan worden opgeslagen in routecache | |
+----------------------- +---------------------- ------------+------------+
| RouteCacheTimeout | Maximale tijd die de routecache kan | seconden(300) |
| | in de wachtrij staan ​​in routecache | |
+----------------------- +---------------------- ------------+------------+
| RreqRetries | Maximaal aantal hertransmissies | 16 |
| | voor aanvraag ontdekking van een route | |
+----------------------- +---------------------- ------------+------------+
| CacheType | Gebruik Link Cache of gebruik Path Cache | "LinkCache" |
| | | |
+----------------------- +---------------------- ------------+------------+
| LinkBevestiging | Bevestiging van linklaag inschakelen | Waar |
| | mechanisme | |
+----------------------- +---------------------- ------------+------------+

Implementatie wijziging
·

De DsrFsHeader heeft toegevoegd 3 gebieden: bericht type, (bron) id bestemming id en deze
veranderingen Slechts voor nabewerking

1. Het berichttype wordt gebruikt om het datapakket te identificeren van het besturingspakket

2. bron-ID wordt gebruikt om de echte bron van het datapakket te identificeren, aangezien we dat hebben gedaan
om het pakket hop voor hop af te leveren en de ipv4header draagt ​​niet de echte
bron- en bestemmings-IP-adres indien nodig

3. Bestemmings-ID is om dezelfde reden als hierboven

· De header van het routeantwoord is niet woorduitgelijnd in DSR RFC. Wijzig deze in woorduitgelijnd
uitvoering

· DSR werkt als een shim-header tussen transport- en netwerkprotocol, het heeft zijn eigen header nodig
doorstuurmechanisme, we veranderen de pakketoverdracht naar hop-voor-hop-levering, dus
we hebben twee velden toegevoegd in de dsr vaste header om de pakketbezorging te melden

Actueel weg cache uitvoering
Deze implementatie maakte gebruik van "path cache", wat eenvoudig te implementeren is en lusvrij garandeert
paden:

· de padcache heeft een automatisch vervalbeleid

· de cache slaat meerdere route-items op voor een bepaalde bestemming en sorteert de items
gebaseerd op hopaantallen

· de MaxEntriesEachDst kan worden afgestemd om het maximale aantal opgeslagen items voor een single te wijzigen
bestemming

· bij het toevoegen van meerdere routes voor één bestemming wordt de route vergeleken op basis van
hoptelling en vervaltijd, degene met minder hoptelling of een relatief nieuwe route
begunstigd

· Toekomstige implementatie kan "link cache" als een andere mogelijkheid omvatten

DSR Bereidingswijze
Houd rekening met het volgende als u DSR als routeringsprotocol uitvoert:

· NodeTraversalTime is de tijd die nodig is om twee aangrenzende knooppunten te doorkruisen en dat zou ook zo moeten zijn
gekozen om binnen het zendbereik te passen

· PassiveAckTimeout is de tijd die een pakket in de onderhoudsbuffer wacht op passief
bevestiging, normaal gesproken ingesteld als twee keer NodeTraversalTime

· RouteCacheTimeout moet een kleinere waarde krijgen als de snelheid van de knooppunten hoger wordt.
De standaardwaarde is 300s.

Helper
Om een ​​knooppunt DSR te laten uitvoeren, is de eenvoudigste manier het gebruik van de DsrHelper en DsrMainHelpers
in uw simulatiescript. Bijvoorbeeld:

DsrHelper dsr;
DsrMainHelper dsrMain;
dsrMain.Install (dsr, adhocNodes);

De voorbeeldscripts binnenin src/dsr/voorbeelden/ demonstreer het gebruik van op DSR gebaseerde knooppunten
verschillende scenario's. De helperbron is binnenin te vinden
src/dsr/helper/dsr-main-helper.{h,cc} en src/dsr/helper/dsr-helper.{h,cc}

Voorbeelden
Het voorbeeld is te vinden in src/dsr/voorbeelden/:

· dsr.cc gebruikt DSR als routeringsprotocol binnen een traditionele MANETs-omgeving[3].

DSR is ook ingebouwd in het routeringsvergelijkingsgeval voorbeelden/routing/:

· manet-routing-compare.cc is een vergelijkingsgeval met ingebouwde MANET-routeringsprotocollen en
kan zijn eigen resultaten genereren.

Validatie
Dit model is als volgt getest:

· Er zijn unit-tests geschreven om de interne werking van DSR te verifiëren. Deze is te vinden in
src/dsr/test/dsr-test-suite.cc. Deze tests verifiëren of de methoden in de DSR-module
die omgaan met pakketbuffer, headers werken correct.

· Simulatiegevallen vergelijkbaar met [3] zijn getest en hebben vergelijkbare resultaten.

· manet-routing-compare.cc is gebruikt om DSR te vergelijken met drie andere routes
protocols.

Tijdens de Workshop on ns-3 in 2011 werd over deze resultaten een paper gepresenteerd.

Beperkingen
Het model voldoet niet volledig RFC 4728. Dsr heeft bijvoorbeeld een header met een vaste grootte
is uitgebreid en is vier octecten langer dan de RFC-specificatie. Als gevolg hiervan
de DSR-headers kunnen niet correct worden gedecodeerd door Wireshark.

Het model dat volledig voldoet aan de RFC is gepland voor de toekomst.

Referenties
[1] Origineel papier: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

[2] RFC4728 http://www6.ietf.org/rfc/rfc4728.txt

[3] Broch's vergelijkingsartikel: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

EMULATIE Overzicht

ns-3 is ontworpen voor integratie in testbed- en virtuele machine-omgevingen. Wij
hebben aan deze behoefte voldaan door twee soorten internetapparaten aan te bieden. Het eerste soort apparaat
is een bestandsdescriptor-netapparaat (FdNet-apparaat), wat een generiek apparaattype is dat dat wel kan
lezen en schrijven vanuit een bestandsdescriptor. Door deze bestandsdescriptor te associëren met verschillende
dingen op het hostsysteem, er kunnen verschillende mogelijkheden worden geboden. Bijvoorbeeld de
FdNetDevice kan worden gekoppeld aan een onderliggende pakketsocket om emulatie mogelijk te maken
mogelijkheden. Dit maakt het mogelijk ns-3 simulaties om gegevens over een "echt" netwerk te verzenden. De seconde
soort, genaamd a Tik Netapparaat staat een "echte" gastheer toe om deel te nemen aan een ns-3 simulatie als
als het een van de gesimuleerde knooppunten was. Een ns-3 simulatie kan met elk worden geconstrueerd
combinatie van gesimuleerde of geëmuleerde apparaten.

Opmerking: Vóór ns-3.17 werd de emulatiemogelijkheid geleverd door een speciaal apparaat genaamd
an emoe Netapparaat; de emoe NetDevice is vervangen door de FdNet-apparaat.

Eén van de use-cases die we willen ondersteunen is die van een testbed. Een concreet voorbeeld van een
Een dergelijke omgeving is het ORBIT-testbed. ORBIT is een laboratoriumemulator/veldproef
netwerk gerangschikt als een tweedimensionaal raster van 400 802.11-radioknooppunten. Wij integreren met
ORBIT door hun "imaging" -proces te gebruiken om te laden en uit te voeren ns-3 simulaties op de ORBIT
reeks. Wij kunnen onze gebruiken EmuFdNet-apparaat om de hardware in het testbed aan te sturen en dat kunnen we
verzamel resultaten met behulp van de ns-3 tracerings- en logboekfuncties, of de native
ORBIT-technieken voor gegevensverzameling. Zien http://www.orbit-lab.org/ voor meer informatie over de ORBIT
testbed.

Een dergelijke simulatie wordt weergegeven in de volgende figuur:
[afbeelding] Voorbeeldimplementatie van Testbed-emulatie..UNINDENT

Je kunt zien dat er afzonderlijke hosts zijn, die elk een subset van een "algemene" host beheren
simulatie. In plaats van een ns-3 kanaal dat de hosts verbindt, we gebruiken echte hardware
geleverd door het testbed. Dit maakt het mogelijk ns-3 applicaties en protocolstacks gekoppeld aan a
simulatieknooppunt om via echte hardware te communiceren.

We verwachten dat het primaire gebruik van deze configuratie het genereren van herhaalbare gegevens zal zijn
experimentele resultaten in een echte netwerkomgeving die alle ns-3
tools voor tracering, logboekregistratie, visualisatie en het verzamelen van statistieken.

In wat in wezen als een omgekeerde configuratie kan worden beschouwd, staan ​​we 'echte' machines toe
het uitvoeren van native applicaties en protocolstacks om te integreren met een ns-3 simulatie.
Dit maakt de simulatie mogelijk van grote netwerken die zijn verbonden met een echte machine, en ook
maakt virtualisatie mogelijk. Een dergelijke simulatie wordt weergegeven in de volgende figuur:
[image] Implementatieoverzicht van geëmuleerd kanaal..UNINDENT

Hier ziet u dat er één host is waarop een aantal virtuele machines draaien
ben ermee bezig. Een ns-3 simulatie wordt getoond in de virtuele machine die in het midden wordt weergegeven
het figuur. Deze simulatie heeft een aantal knooppunten met bijbehorende ns-3 toepassingen en
protocolstacks die praten met een ns-3 kanaal via native gesimuleerd ns-3 net
toestellen.

Er zijn ook twee virtuele machines uiterst links en uiterst rechts in de figuur weergegeven.
Deze VM's draaien native (Linux) applicaties en protocolstacks. De VM is
verbonden met de simulatie door een Linux Tap net-apparaat. De gebruikersmodushandler voor de
Het tapapparaat wordt in de simulatie geïnstantieerd en aan een proxyknooppunt gekoppeld
vertegenwoordigt de native VM in de simulatie. Met deze handlers kunnen de Tap-apparaten op de
native VM's moeten zich gedragen alsof ze dat wel zijn ns-3 net-apparaten in de simulatie-VM. Dit in
zorgt ervoor dat de native software en protocolsuites in de native VM’s dat kunnen geloven
ze zijn verbonden met het gesimuleerde ns-3 kanaal.

We verwachten dat de typische use case voor deze omgeving het analyseren van het gedrag van
native applicaties en protocolsuites in de aanwezigheid van grote gesimuleerde ns-3
netwerken.

Dien in descriptor Netapparaat
De src/fd-net-apparaat module biedt de FdNet-apparaat klasse, die kan lezen en
schrijf verkeer met behulp van een bestandsdescriptor die door de gebruiker wordt verstrekt. Deze bestandsbeschrijving kan
geassocieerd met een TAP-apparaat, met een onbewerkte socket, met een gebruikersruimteproces dat genereert/consumeert
verkeer, etc. De gebruiker heeft de volledige vrijheid om te definiëren hoe extern verkeer wordt gegenereerd en
ns-3 verkeer wordt verbruikt.

Er kunnen verschillende mechanismen worden aangeboden om een ​​simulatie aan extern verkeer te koppelen
helper klassen. Er zijn drie specifieke helpers beschikbaar:

· EmuFdNetDeviceHelper (om de ns-3 apparaat met een fysiek apparaat in de host
machine)

· TapFdNetDeviceHelper (om het ns-3-apparaat met één tik te koppelen aan de bestandsbeschrijving
apparaat op de hostmachine)

· PlanteLabFdNetDeviceHelper (om het aanmaken van tapapparaten in PlanetLab-knooppunten te automatiseren,
waardoor ns-3 simulaties die verkeer via internet kunnen verzenden en ontvangen
PlanetLab-bron.

Model Beschrijving
De broncode voor deze module bevindt zich in de directory src/fd-net-apparaat.

Het FdNetDevice is een speciaal type ns-3 NetDevice dat verkeer van en naar een bestand leest
beschrijving. Dat wil zeggen, in tegenstelling tot pure simulatie-NetDevice-objecten die frames schrijven naar en
vanuit een gesimuleerd kanaal stuurt dit FdNetDevice frames uit de simulatie naar een bestand
beschrijving. De bestandsdescriptor kan worden gekoppeld aan een Linux TUN/TAP-apparaat, aan een socket,
of naar een gebruikersruimteproces.

Het is aan de gebruiker van dit apparaat om een ​​bestandsbeschrijving op te geven. Het type bestand
de descriptor die wordt verstrekt, bepaalt wat er wordt gemodelleerd. Als het bestand bijvoorbeeld
descriptor biedt een onbewerkte socket voor een WiFi-kaart op de hostmachine, waarbij het apparaat is
gemodelleerd is een WiFi-apparaat.

Vanaf de conceptuele "bovenkant" van het apparaat, naar beneden kijkend, lijkt het op het gesimuleerde knooppunt
een apparaat dat een 48-bits IEEE MAC-adres ondersteunt dat kan worden overbrugd, uitzending ondersteunt en
maakt gebruik van IPv4 ARP of IPv6 Neighbor Discovery, hoewel deze attributen kunnen worden afgestemd op a
per gebruiksgeval.

Design
De FdNetDevice-implementatie maakt gebruik van een reader-object, uitgebreid van de FdReader
klasse in de ns-3 src/kern module, die een aparte thread beheert van de main ns-3
uitvoeringsthread, om verkeer van de bestandsdescriptor te lezen.

Bij een beroep op de StartApparaat methode, wordt het reader-object geïnitialiseerd en start de
draadje lezen. Voordat het apparaat start, moet er eerder een bestandsdescriptor aan worden gekoppeld
het FdNet-apparaat met de SetFileDescriptor aanroeping.

Het aanmaken en configureren van de bestandsdescriptor kan aan een aantal helpers worden overgelaten,
hieronder in meer detail beschreven. Wanneer dit is gebeurd, wordt de aanroep van SetFileDescriptor is
verantwoordelijkheid van de helper en mag niet rechtstreeks door de gebruiker worden ingeroepen.

Bij het lezen van een binnenkomend frame uit de bestandsdescriptor, zal de lezer het frame doorgeven
the Terugbellen ontvangen methode, wiens taak het is om de ontvangst van het frame door de
apparaat als een ns-3 simulatie evenement. Omdat het nieuwe frame van de lezerthread wordt doorgegeven naar
de belangrijkste ns-3 simulatiethread, worden thread-veiligheidsproblemen vermeden door gebruik te maken van de
SchemaMetContext bellen in plaats van de reguliere Plan noemen.

Om te voorkomen dat de planner wordt overweldigd wanneer de inkomende gegevenssnelheid te hoog is, a
De teller wordt bijgehouden met het aantal frames dat momenteel volgens de planning zal worden ontvangen
het apparaat. Als deze teller de waarde bereikt die wordt gegeven door de RxQueueSize attribuut in het
apparaat, waarna het nieuwe frame stil wordt verwijderd.

De daadwerkelijke ontvangst van het nieuwe frame door het apparaat vindt plaats op het geplande tijdstip FordwarUp
methode wordt aangeroepen door de simulator. Deze methode werkt alsof er een nieuw frame is aangekomen van a
kanaal dat aan het apparaat is gekoppeld. Het apparaat ontkapt vervolgens het frame en verwijdert eventuele lagen
2 headers, en stuurt deze door naar de bovenste netwerkstapellagen van het knooppunt. De VooruitOmhoog
methode verwijdert de frameheaders, volgens het frame-inkapselingstype gedefinieerd door
the Inkapselingsmodus attribuut en roep de ontvangst-callback op waarbij een IP-pakket wordt doorgegeven.

Er kan een extra header, de PI-header, aanwezig zijn wanneer de bestandsdescriptor aan een
TAP-apparaat dat is gemaakt zonder de vlag IFF_NO_PI in te stellen. Deze extra header is
verwijderd als Inkapselingsmodus is ingesteld op de DIXPI-waarde.

In de tegenovergestelde richting worden pakketten gegenereerd binnen de simulatie die worden verzonden
via het apparaat, wordt doorgegeven aan de stuur methode, die op zijn beurt de
VerzendenVan methode. De laatste methode voegt eenvoudigweg de benodigde laag 2-headers toe
schrijf het nieuw gemaakte frame naar de bestandsdescriptor.

strekking en Beperkingen
Gebruikers van dit apparaat worden gewaarschuwd dat er geen stroomcontrole over het bestand plaatsvindt
descriptorgrens, bij gebruik in de emulatiemodus. Dat wil zeggen, in een Linux-systeem, als de
snelheid van het schrijven van netwerkpakketten overtreft het vermogen van het onderliggende fysieke apparaat om dat te doen
buffer de pakketten, tegendruk tot aan de schrijftoepassing zal worden toegepast om dit te voorkomen
lokaal pakketverlies. Er is geen dergelijke stroomcontrole beschikbaar via de bestandsdescriptorinterface,
gebruikers moeten zich dus bewust zijn van deze beperking.

Zoals eerder uitgelegd, beperkt het RxQueueSize-attribuut het aantal pakketten dat kan zijn
in afwachting van ontvangst door het apparaat. Frames worden gelezen uit de bestandsdescriptor terwijl het
het aantal wachtende pakketten het maximum bereikt, wordt stilzwijgend verwijderd.

De mtu van het apparaat is standaard ingesteld op de Ethernet II MTU-waarde. Er worden echter helpers verondersteld
om de mtu op de juiste waarde in te stellen om de kenmerken van de netwerkinterface weer te geven
gekoppeld aan de bestandsdescriptor. Als er geen helper wordt ingezet, dan is de verantwoordelijkheid van
het instellen van de juiste mtu-waarde voor het apparaat valt terug naar de gebruiker. De grootte van het gelezene
buffer op de bestandsdescriptorlezer is ingesteld op de mtu-waarde in het StartApparaat methode.

De klasse FdNetDevice ondersteunt momenteel drie inkapselingsmodi, DIX voor Ethernet II
frames, LLC voor 802.2 LLC/SNAP-frames en DIXPI voor Ethernet II-frames met een extra
TAP PI-header. Dit betekent dat er naar verwachting verkeer door de bestandsdescriptor zal gaan
Ethernet II-compatibel. Het aansluiten van een FdNetDevice op een draadloze interface is mogelijk als
zolang het stuurprogramma Ethernet II-frames levert aan de socket-API. Let op: associëren
een FdNetDevice naar een draadloze kaart in ad-hocmodus, moet het MAC-adres van het apparaat worden ingesteld
naar het echte MAC-adres van de kaart, anders zal al het binnenkomende verkeer een vals MAC-adres zijn
door de bestuurder weggegooid.

Zoals eerder vermeld, worden er drie helpers meegeleverd met de fd-net-device-module. Elk
individuele helper (type bestandsdescriptor) kan platformbeperkingen hebben. Bijvoorbeeld,
threading, real-time simulatiemodus en de mogelijkheid om TUN/TAP-apparaten te maken zijn dat wel
voorwaarden voor het gebruik van de aangeboden helpers. Ondersteuning voor deze modi is te vinden in de
uitgang van de waf configureer stap, bijvoorbeeld:

Threading-primitieven: ingeschakeld
Realtimesimulator: ingeschakeld
Geëmuleerd netwerkapparaat: ingeschakeld
Tik op Bridge: ingeschakeld

Het is belangrijk om te vermelden dat tijdens het testen van de FdNet-apparaat we hebben een bovengrens gevonden
limiet voor TCP-doorvoer bij gebruik van 1Gb Ethernet-verbindingen van 60Mbps. Deze limiet is het hoogst
waarschijnlijk vanwege de verwerkingskracht van de computers die bij de tests betrokken waren.

Gebruik
Het gebruikspatroon voor dit type apparaat is vergelijkbaar met dat van andere internetapparaten met helpers
die worden geïnstalleerd op knooppuntaanwijzers of knooppuntcontainers. Bij gebruik van de basis FdNetDeviceHelper
de gebruiker is zelf verantwoordelijk voor het aanmaken en instellen van de bestandsdescriptor.

FdNetDeviceHelperfd;
NetDeviceContainer-apparaten = fd.Install (knooppunten);

// genereren van bestandsdescriptors
...

apparaat->SetFileDescriptor (fd);

Meestal wordt een FdNetDevice gebruikt voor interactie met het hostsysteem. In deze gevallen
het is vrijwel zeker dat de gebruiker in real-time emulatiemodus wil werken, en dat ook
controlesomberekeningen mogelijk maken. De typische programma-instructies zijn als volgt:

GlobalValue::Bind ("SimulatorImplementationType", StringValue ("ns3::RealtimeSimulatorImpl"));
GlobalValue::Bind ("ChecksumEnabled", BooleanValue (waar));

De eenvoudigste manier om een ​​experiment op te zetten dat samenwerkt met een Linux-hostsysteem, is door gebruik te maken van de gebruiker
the emoe en Tik helpers. Misschien wel het meest ongebruikelijke onderdeel van deze helperimplementaties
heeft betrekking op de vereiste voor het uitvoeren van een deel van de code met superuser-machtigingen.
In plaats van de gebruiker te dwingen de hele simulatie als root uit te voeren, bieden we een klein
"creator"-programma dat als root draait en alle vereiste sockets met hoge toestemming doet.
De eenvoudigste manier om de juiste rechten in te stellen voor de "creator"-programma's is door de
--enable-sudo vlag tijdens het optreden waf configureer.

We doen iets soortgelijks voor beide emoe en Tik apparaten. De visie op hoog niveau is dat
the CreateFileDescriptor methode creëert een lokale interprocess (Unix) socket, forks en
voert het kleine creatieprogramma uit. Het kleine programma, dat als suid root draait, maakt een
raw socket en stuurt de raw socket-bestandsdescriptor terug via de Unix-socket
als parameter doorgegeven. De onbewerkte socket wordt doorgegeven als een controlebericht (soms
aanvullende gegevens genoemd) van het type SCM_RIGHTS.

helpers
EmuFdNetDeviceHelper
De EmuFdNetDeviceHelper creëert een onbewerkte socket voor een onderliggend fysiek apparaat, en
levert de socketdescriptor voor het FdNetDevice. Hierdoor kan de ns-3 simulatie aan
frames lezen van en frames schrijven naar een netwerkapparaat op de host.

De emulatiehelper maakt het mogelijk om op transparante wijze een gesimuleerde te integreren ns-3 knooppunt in een
netwerk bestaande uit echte knooppunten.

+--------------------+ +----------------------+
| gastheer 1 | | gastheer 2 |
+--------------------+ +----------------------+
| ns-3-simulatie | | |
+---------------------+ | Linux |
| ns-3 knooppunt | | Netwerkstapel |
| +----------------+ | | +----------------+ |
| | ns-3TCP | | | | TCP | |
| +----------------+ | | +----------------+ |
| | ns-3 IP | | | | IP | |
| +----------------+ | | +----------------+ |
| | FdNet-apparaat | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + ETHERNET + |
| | ruwe socket | | | | | |
|--+----------------+--| | +----------------+ |
| | eth0 | | | | eth0 | |
+-------+------+-------+ +--------+-----+-------+

10.1.1.11 10.1.1.12

| |
+---------------------------+

Deze helper vervangt de functionaliteit van de EmuNet-apparaat gevonden in ns-3 vóór ns-3.17,
door dit type apparaat in het gemeenschappelijke raamwerk van het FdNetDevice te brengen. De
EmuNet-apparaat werd afgekeurd ten gunste van deze nieuwe helper.

Het apparaat is geconfigureerd om MAC-spoofing uit te voeren om het simulatienetwerkverkeer te scheiden
van ander netwerkverkeer dat mogelijk van en naar de host stroomt.

Men kan deze helper gebruiken in een testbedsituatie waarbij de host waarop de simulatie zich bevindt
hardlopen heeft een specifieke interessante interface die de testbedhardware aanstuurt. Je zou
moeten deze specifieke interface ook in de promiscue modus zetten en een passende interface bieden
apparaatnaam naar de ns-3 simulatie. Bovendien wordt hardware-offloading van segmentatie en
controlesommen moeten worden uitgeschakeld.

De helper werkt alleen als de onderliggende interface actief is en in de promiscue modus staat. Pakketten
worden via het apparaat verzonden, maar we gebruiken MAC-spoofing. De MAC-adressen zullen zijn
gegenereerd (standaard) met behulp van de Organizationally Unique Identifier (OUI) 00:00:00 als een
baseren. Deze leverancierscode is aan geen enkele organisatie toegewezen en mag er dus niet mee conflicteren
elke echte hardware.

Het is altijd aan de gebruiker om te bepalen of het gebruik van deze MAC-adressen voor u goed is
netwerk en zal niet conflicteren met iets anders (inclusief een andere simulatie die dergelijke
apparaten) op uw netwerk. Als u de geëmuleerde FdNetDevice-configuratie gebruikt in
afzonderlijke simulaties, moet u rekening houden met algemene problemen met de toewijzing van MAC-adressen en ervoor zorgen
dat MAC-adressen uniek zijn in alle simulaties. Het geëmuleerde netwerkapparaat respecteert de
MAC-adres opgegeven in de Adres attribuut, zodat u dit handmatig kunt doen. Voor groter
simulaties, wilt u wellicht de OUI instellen in de MAC-adrestoewijzingsfunctie.

Alvorens een beroep te doen op de Install methode moet de juiste apparaatnaam worden geconfigureerd op de
hulp die gebruik maakt van de Stel apparaatnaam in methode. De apparaatnaam is vereist om te identificeren welke
Er moet een fysiek apparaat worden gebruikt om de onbewerkte socket te openen.

EmuFdNetDeviceHelper emu;
emu.SetDeviceName (apparaatnaam);
NetDeviceContainer-apparaten = emu.Install (knooppunt);
Ptr apparaat = apparaten.Get (0);
device->SetAttribute ("Adres", Mac48AddressValue (Mac48Address::Toewijzen ()));

Tik opFdNetDeviceHelper
Een Tap-apparaat is een speciaal type Linux-apparaat waarbij het ene uiteinde van het apparaat lijkt te zijn
de kernel als een virtueel net_device, en het andere uiteinde wordt geleverd als bestandsdescriptor
gebruikersruimte. Deze bestandsdescriptor kan worden doorgegeven aan het FdNetDevice. Pakketten doorgestuurd naar
het TAP-apparaat bij de kernel zal verschijnen in het FdNetDevice in ns-3.

Gebruikers moeten er rekening mee houden dat dit gebruik van TAP-apparaten anders is dan dat van de
TapBridge NetDevice gevonden in src/tap-bridge. Het model in deze helper is als volgt:

+----------------------------------+
| gastheer |
+----------------------------------+
| ns-3-simulatie | |
+---------------------+ |
| ns-3 knooppunt | |
| +----------------+ | |
| | ns-3TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNet-apparaat | | |
|--+----------------+--+ +------+ |
| | TIK | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-----------------------------|-----+
|
|
------------ (Internet) -----

In het bovenstaande vereist de configuratie dat de host verkeer kan doorsturen
gegenereerd door de simulatie op internet.

Het model in TapBridge (in een andere module) is als volgt:

+--------+
| Linux |
| gastheer | +----------+
| ------ | | geest |
| apps | | knooppunt |
| ------ | | -------- |
| stapel | | IP | +----------+
| ------ | | stapel | | knooppunt |
| TIK | |==========| | -------- |
| apparaat | <-----IPC ------> | tik op | | IP |
+--------+ | brug | | stapel |
| -------- | | -------- |
| ns-3 | | ns-3 |
| netto | | netto |
| apparaat | | apparaat |
+----------+ +----------+
|| ||
+------------+
| ns-3 kanaal |
+------------+

In het bovenstaande doorlopen pakketten in plaats daarvan ns-3 Netapparaten en kanalen.

Het gebruikspatroon voor dit voorbeeld is dat de gebruiker het MAC-adres instelt en (of
beide) de IPv4- en IPv6-adressen en -maskers op het apparaat, en indien nodig de PI-header.
Bijvoorbeeld:

TapFdNetDeviceHelper-helper;
helper.SetDeviceName (apparaatnaam);
helper.SetModePi (modePi);
helper.SetTapIpv4Address (tapIp);
helper.SetTapIpv4Mask (tapMask);
...
helper.Installeren (knooppunt);

PlanetLabFdNetDeviceHelper
PlanetLab is een wereldwijd gedistribueerd netwerktestbed bestaande uit knooppunten die zijn verbonden met de
Internet. Het uitvoeren van ns-3-simulaties in PlanetLab-knooppunten met behulp van de
PlanetLabFdNetDeviceHelper maakt het mogelijk om gesimuleerd verkeer gegenereerd door ns-3 rechtstreeks naar te sturen
het internet. Deze opstelling kan handig zijn om ns-3 internetprotocollen of andere toekomstige protocollen te valideren
protocollen geïmplementeerd in ns-3.

Om experimenten uit te voeren met PlanetLab-knooppunten is een PlanetLab-account vereist. Alleen
leden van partnerinstellingen van PlanetLab kunnen dergelijke accounts verkrijgen (voor meer informatie
bezoek http://www.planet-lab.org/ or http://www.planet-lab.eu ). Zodra de rekening is
verkregen, een PlanetLab plak moeten worden aangevraagd om experimenten uit te kunnen voeren. Een snee
vertegenwoordigt een experimenteenheid die verband houdt met een groep PlanetLab-gebruikers en kan worden geassocieerd
naar virtuele machines in verschillende PlanetLab-knooppunten. Segmenten kunnen ook worden aangepast door ze toe te voegen
configuratietags eraan toe (dit wordt gedaan door PlanetLab-beheerders).

De PlanetLabFdNetDeviceHelper maakt TAP-apparaten op PlanetLab-knooppunten met behulp van specifieke
PlanetLab-mechanismen (dwz het vsys-systeem), en koppelt het TAP-apparaat aan a
FdNet-apparaat in ns-3. De functionaliteit van deze helper is vergelijkbaar met die
geleverd door de FdTapNetDeviceHelper, behalve dat de onderliggende mechanismen om de
TAP-apparaat is anders.

+----------------------------------+
| PlanetLab-host |
+----------------------------------+
| ns-3-simulatie | |
+---------------------+ |
| ns-3 knooppunt | |
| +----------------+ | |
| | ns-3TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNet-apparaat | | |
|--+----------------+--+ +------+ |
| | TIK | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-----------------------------|-----+
|
|
------------ (Internet) -----

Om privé IPv4-adressen aan de TAP-apparaten te kunnen toewijzen, kunnen accounthouders
moet de aanvragen vsys_vnet tag die door PlanetLab-beheerders aan hun segment moet worden toegevoegd.
De vsys_vnet-tag is gekoppeld aan het particuliere netwerksegment en alleen aan adressen daarvan
segment kan worden gebruikt in experimenten.

De syntaxis die wordt gebruikt om met deze helper een TAP-apparaat te maken, is vergelijkbaar met die voor de
eerder beschreven helpers:

PlanetLabFdNetDeviceHelper-helper;
helper.SetTapIpAddress (tapIp);
helper.SetTapMask (tapMask);
...
helper.Installeren (knooppunt);

PlanetLab-knooppunten hebben een op Fedora gebaseerde distributie, dus ns-3 kan worden geïnstalleerd volgens de
instructies voor ns-3 Linux-installatie.

Attributen
De FdNet-apparaat biedt een aantal kenmerken:

· Adres: Het MAC-adres van het apparaat

· Start: de starttijd van de simulatie om de apparaatthread op te starten

· stop: de starttijd van de simulatie om de apparaatthread te stoppen

· Inkapselingsmodus: Link-layer inkapselingsformaat

·

RxWachtrijgrootte: De buffer grootte of the dit artikel lezen queue on the filet descriptor
draad (standaard van 1000 pakketten)

Start en stop hoeven normaal gesproken niet te worden opgegeven, tenzij de gebruiker de
tijd gedurende welke dit apparaat actief is. Adres moet op een soort uniek worden ingesteld
MAC-adres als de simulatie op de een of andere manier interactie zal hebben met andere echte apparaten
echte MAC-adressen. Typische code:

device->SetAttribute ("Adres", Mac48AddressValue (Mac48Address::Toewijzen ()));

uitgang
Ascii- en PCAP-tracering worden op dezelfde manier aangeboden als de andere ns-3 NetDevice-typen, via de
helpers, zoals (bijvoorbeeld):

:: EmuFdNetDeviceHelper emu; NetDeviceContainer-apparaten = emu.Install (knooppunt);
emu.EnablePcap ("emu-ping", apparaat, waar);

De standaardset NetDevice-traceerbronnen op Mac-niveau wordt meegeleverd.

· MaxTx: Traceringsbron geactiveerd wanneer ns-3 voorziet het apparaat van een nieuw frame om te verzenden

· MaxTxDrop: Traceer de bron als het schrijven naar de bestandsdescriptor mislukt

· MaxPromiscRx: Wanneer een geldig Mac-frame wordt ontvangen

· MaxRx: Wanneer een geldig Mac-frame wordt ontvangen voor dit apparaat

· sniffer: Niet-promiscue pakketsniffer

· PromiscSniffer: Promiscue pakketsniffer (voor tcpdump-achtige sporen)

Voorbeelden
Er worden verschillende voorbeelden gegeven:

· dummy-netwerk.cc: Dit eenvoudige voorbeeld creëert twee knooppunten en verbindt deze met a
Unix-pipe door de bestandsdescriptors van het socketpaar door te geven aan het FdNetDevice
objecten van de respectieve knooppunten.

· realtime-dummy-netwerk.cc: Hetzelfde als dummy-network.cc maar gebruikt de real-time simulator
implementatie in plaats van de standaardversie.

· fd2fd-onoff.cc: Dit voorbeeld is bedoeld voor het meten van de doorvoer van het FdNetDevice in
een pure simulatie. Voor dit doeleinde zijn er twee FdNetDevices, aangesloten op verschillende knooppunten, maar in
dezelfde simulatie, zijn verbonden met behulp van een socketpaar. TCP-verkeer wordt verzonden op een
verzadigende datasnelheid.

· fd-emu-onoff.cc: Dit voorbeeld is gericht op het meten van de doorvoer van het FdNetDevice
bij gebruik van de EmuFdNetDeviceHelper om het gesimuleerde apparaat aan een echt apparaat te koppelen
de hostmachine. Dit wordt bereikt door het kanaal te verzadigen met TCP-verkeer.

· fd-emu-ping.cc: In dit voorbeeld wordt de EmuFdNetDeviceHelper gebruikt om ICMP-verkeer te verzenden via een
echt kanaal.

· fd-emu-udp-echo.cc: In dit voorbeeld wordt de EmuFdNetDeviceHelper gebruikt om UDP-verkeer over te sturen
een echt kanaal.

· fd-planetlab-ping.cc: Dit voorbeeld laat zien hoe u een experiment opzet om ICMP te verzenden
verkeer van een PlanetLab-knooppunt naar internet.

· fd-tap-ping.cc: In dit voorbeeld wordt de TapFdNetDeviceHelper gebruikt om ICMP-verkeer te verzenden via een
echt kanaal.

Tik Netapparaat
Het Tap NetDevice kan worden gebruikt om interactie met een hostsysteem of virtuele machines mogelijk te maken
een simulatie.

Tik op Brug Model Overzicht
De Tap Bridge is ontworpen om "echte" internethosts (of beter gezegd, hosts) te integreren
die Tun/Tap-apparaten ondersteunen) in ns-3-simulaties. Het doel is om het te laten lijken op een
"echt" hostknooppunt in die zin dat het een ns-3 net-apparaat als lokaal apparaat heeft. Het concept van een
"echte host" is een beetje ingewikkeld, aangezien de "echte host" feitelijk kan worden gevirtualiseerd met behulp van
direct beschikbare technologieën zoals VMware, VirtualBox of OpenVZ.

Omdat we in wezen de in- en uitgangen van een ns-3 net-apparaat verbinden met de
ingangen en uitgangen van een Linux Tap-netapparaat, noemen we deze opstelling een Tap Bridge.

Er zijn drie basisbedieningsmodi van dit apparaat beschikbaar voor gebruikers. Basis
functionaliteit is in wezen identiek, maar de modi verschillen qua details
hoe de regeling tot stand komt en geconfigureerd wordt; en welke apparaten aan welke kant kunnen leven
de brug.

We noemen deze drie modi de ConfigureLocal-, UseLocal- en UseBridge-modi. De eerste
'woord' in de kameelgevalmodus-ID geeft aan wie de verantwoordelijkheid heeft voor het maken
en het configureren van de kranen. De "Configure" in de ConfigureLocal-modus geeft bijvoorbeeld aan
dat het de TapBridge is die verantwoordelijk is voor het configureren van de kraan. In UseLocal
modus en UseBridge-modi geeft het voorvoegsel "Gebruik" aan dat de TapBridge wordt gevraagd om "Gebruik" te gebruiken
een bestaande configuratie.

Met andere woorden: in de ConfigureLocal-modus is de TapBridge verantwoordelijk voor het creëren
en het configureren van de TAP-apparaten. In de UseBridge- of UseLocal-modus levert de gebruiker een
configuratie en de TapBridge past zich aan die configuratie aan.

Tik op Brug Configureer Lokaal Mode
In de ConfigureLocal-modus is de configuratie van het tapapparaat ns-3
configuratiegericht. Configuratie-informatie wordt overgenomen van een apparaat in de ns-3
simulatie en er wordt automatisch een tapapparaat gemaakt dat overeenkomt met de ns-3-attributen. In
In dit geval wordt een Linux-computer weergegeven alsof deze rechtstreeks is aangesloten op een
gesimuleerd ns-3-netwerk.

Dit wordt hieronder geïllustreerd:

+--------+
| Linux |
| gastheer | +----------+
| ------ | | geest |
| apps | | knooppunt |
| ------ | | -------- |
| stapel | | IP | +----------+
| ------ | | stapel | | knooppunt |
| TIK | |==========| | -------- |
| apparaat | <-----IPC ------> | tik op | | IP |
+--------+ | brug | | stapel |
| -------- | | -------- |
| ns-3 | | ns-3 |
| netto | | netto |
| apparaat | | apparaat |
+----------+ +----------+
|| ||
+------------+
| ns-3 kanaal |
+------------+

In dit geval verschijnt het "ns-3 net device" in het "ghost node" alsof dit werkelijk het geval is
het vervangen van het TAP-apparaat in de Linux-host. Bij de ns-3-simulatie wordt het TAP-apparaat ingeschakeld
het onderliggende Linux-besturingssysteem en configureert de IP- en MAC-adressen van het TAP-apparaat zodat ze overeenkomen
de waarden die zijn toegewezen aan het gesimuleerde ns-3 net-apparaat. De hierboven getoonde "IPC"-link is de
netwerktapmechanisme in het onderliggende besturingssysteem. Het hele arrangement werkt als een conventioneel arrangement
brug; maar een brug tussen apparaten die toevallig dezelfde gedeelde MAC en IP hebben
adressen.

Hier hoeft de gebruiker geen configuratie-informatie op te geven die specifiek is voor de
kraan. Er wordt door ns-3 een tapapparaat gemaakt en geconfigureerd volgens de standaardinstellingen, en
aan het tapapparaat wordt de naam toegewezen door het onderliggende besturingssysteem
zijn standaardinstellingen.

Als de gebruiker toegang nodig heeft tot het aangemaakte tapapparaat, kan hij of zij dit optioneel doen
geef een kenmerk 'DeviceName' op. In dit geval krijgt het aangemaakte OS-tapapparaat een naam
overeenkomstig.

De ConfigureLocal-modus is de standaardbedieningsmodus van de Tap Bridge.

Tik op Brug Gebruik Lokaal Mode
De UseLocal-modus lijkt veel op de ConfigureLocal-modus. Het significante verschil
is, zoals de naam van de modus aangeeft, de TapBridge een bestaand tapapparaat gaat "gebruiken".
eerder gemaakt en geconfigureerd door de gebruiker. Deze modus is vooral handig wanneer a
virtualisatieschema creëert automatisch tapapparaten en daarvoor wordt ns-3 gebruikt
gesimuleerde netwerken voor die apparaten.

+--------+
| Linux |
| gastheer | +----------+
| ------ | | geest |
| apps | | knooppunt |
| ------ | | -------- |
| stapel | | IP | +----------+
| ------ | | stapel | | knooppunt |
| TIK | |==========| | -------- |
| apparaat | <-----IPC ------> | tik op | | IP |
| MAC X | | brug | | stapel |
+--------+ | -------- | | -------- |
| ns-3 | | ns-3 |
| netto | | netto |
| apparaat | | apparaat |
| MAC Y | | MAC Z |
+----------+ +----------+
|| ||
+------------+
| ns-3 kanaal |
+------------+

In dit geval zal het vooraf geconfigureerde MAC-adres van het "Tap device" (MAC X) niet het
hetzelfde als dat van het overbrugde "ns-3 net device" (MAC Y) getoond in de bovenstaande afbeelding. In
om een ​​brug te maken naar ns-3 net-apparaten die SendFrom() niet ondersteunen (vooral draadloos
STA-nodes) stellen wij de eis dat slechts één Linux-apparaat (met één uniek MAC-adres
-- hier X) genereert verkeer dat over de IPC-link stroomt. Dit komt omdat de MAC
adressen van verkeer via de IPC-link zullen worden "vervalst" of gewijzigd zodat dit lijkt
Linux en ns-3 dat ze hetzelfde adres hebben. Dat wil zeggen, verkeer dat zich van Linux verplaatst
host naar het ns-3 spookknooppunt zal het MAC-adres veranderen van X in Y en het verkeer van
het MAC-adres van het spookknooppunt naar de Linux-host zal worden gewijzigd van Y in X. Sindsdien
er is een één-op-één-correspondentie tussen apparaten, er kan slechts één MAC-bron zijn
die van de Linux-kant vloeit. Dit betekent dat Linux een brug vormt met meer dan één netapparaat
toegevoegd zijn incompatibel met de UseLocal-modus.

In de UseLocal-modus wordt van de gebruiker verwacht dat hij een tapapparaat volledig maakt en configureert
buiten het bereik van de ns-3-simulatie met behulp van zoiets als:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 hw ether 08:00:2e:00:00:01
$ sudo ifconfig tap0 10.1.1.1 netmasker 255.255.255.0 omhoog

Om de TapBridge te vertellen wat er aan de hand is, gaat de gebruiker rechtstreeks naar de
TapBridge of via de TapBridgeHelper, het attribuut "DeviceName". In het geval van de
configuratie hierboven, zou het kenmerk "DeviceName" worden ingesteld op "tap0" en de "Modus"
attribuut zou worden ingesteld op "UseLocal".

Een specifiek gebruiksscenario voor deze modus is in de OpenVZ-omgeving. Daar is het mogelijk
om een ​​Tap-apparaat op de "Hardware Node" te maken en deze naar een Virtual Private Server te verplaatsen.
Als de TapBridge een bestaand tapapparaat kan gebruiken, is het mogelijk om dit te vermijden
overhead van een OS-bridge in die omgeving.

Tik op Brug Gebruik Bridge Mode
De eenvoudigste modus voor degenen die bekend zijn met Linux-netwerken is de UseBridge-modus. Opnieuw,
het voorvoegsel "Gebruik" geeft aan dat de TapBridge een bestaande configuratie gaat gebruiken.
In dit geval zal de TapBridge logischerwijs een Linux-bridge uitbreiden naar ns-3.

Dit wordt hieronder geïllustreerd:

+---------+
| Linux | +----------+
| ------- | | geest |
| apps | | knooppunt |
| ------- | | -------- |
| stapel | | IP | +----------+
| ------- | +--------+ | stapel | | knooppunt |
| Virtueel | | TIK | |==========| | -------- |
| Apparaat | | Apparaat | | tik op | | IP |
+---------+ +--------+ | brug | | stapel |
|| || | -------- | | -------- |
+--------------------+ | ns-3 | | ns-3 |
| OS (brctl) Brug | | netto | | netto |
+--------------------+ | apparaat | | apparaat |
+----------+ +----------+
|| ||
+------------+
| ns-3 kanaal |
+------------+

In dit geval is een computer waarop Linux-applicaties, protocollen, enz. draaien, aangesloten op een
ns-3 gesimuleerde netwerk zodanig dat het voor de Linux-host lijkt alsof de TAP
apparaat is een echt netwerkapparaat dat deelneemt aan de Linux-bridge.

In de ns-3-simulatie wordt een TapBridge gemaakt die bij elk TAP-apparaat past. De naam van de
TAP-apparaat wordt aan de Tap Bridge toegewezen met behulp van het attribuut "DeviceName". De Tapbrug
breidt vervolgens logischerwijs de OS-bridge uit om het ns-3 net-apparaat te omvatten.

Omdat deze modus op logische wijze een OS-bridge uitbreidt, kunnen er veel Linux-netapparaten op de
niet-ns-3 zijde van de brug. Daarom is het ns-3 net, net als een netapparaat op elke bridge
apparaat moet omgaan met de mogelijk vele bronadressen. NS-3-apparaten moeten dat dus wel doen
ondersteuning SendFrom() (NetDevice::SupportsSendFrom() moet true retourneren) om
geconfigureerd voor gebruik in UseBridge-modus.

Er wordt verwacht dat de gebruiker zoiets als het volgende zal doen om de bridge te configureren
en tik geheel buiten ns-3:

$ sudo brctl addbr mybridge
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw ether 00:00:00:00:00:01
$ sudo ifconfig mytap 0.0.0.0 hoger
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge ...
$ sudo ifconfig mybridge 10.1.1.1 netmasker 255.255.255.0 omhoog

Om de TapBridge te vertellen wat er aan de hand is, gaat de gebruiker rechtstreeks naar de
TapBridge of via de TapBridgeHelper, het attribuut "DeviceName". In het geval van de
configuratie hierboven, zou het kenmerk "DeviceName" worden ingesteld op "mytap" en de "Modus"
attribuut zou worden ingesteld op "UseBridge".

Deze modus is vooral handig in het geval van virtualisatie waarbij de configuratie van
de virtuele hosts kunnen worden gedicteerd door een ander systeem en kunnen niet worden gewijzigd om bij ns-3 te passen.
Een bepaald VM-schema kan bijvoorbeeld virtuele "vethx"- of "vmnetx"-apparaten creëren die
lokaal lijken op virtuele hosts. Om verbinding te maken met dergelijke systemen, zou dit nodig zijn
maak handmatig TAP-apparaten aan op het hostsysteem en koppel deze TAP-apparaten aan de
bestaande (VM) virtuele apparaten. De taak van de Tap Bridge is in dit geval het verlengen van de
bridge om verbinding te maken met een ns-3 net-apparaat.

Tik op Brug Configureer Lokaal Werking
In de ConfigureLocal-modus verschijnt de TapBridge en dus het bijbehorende ns-3 net-apparaat
naar de Linux-hostcomputer als een netwerkapparaat, net als elke willekeurige "eth0" of "ath0"
kan verschijnen. Het aanmaken en configureren van het TAP-apparaat gebeurt door de ns-3
simulatie en er is geen handmatige configuratie vereist door de gebruiker. De IP-adressen, MAC
adressen, gateways enz. voor aangemaakte TAP-apparaten worden uit de simulatie gehaald
zichzelf door de configuratie van het ns-3-apparaat en de TapBridge-attributen op te vragen.

Omdat de MAC-adressen aan de Linux-kant en de ns-3-kant identiek zijn, kunnen we gebruiken
Send() op het ns-3-apparaat dat beschikbaar is op alle ns-3 net-apparaten. Sinds de MAC
adressen zijn identiek, er is geen vereiste om de promiscue terugbelactie op de
kant ontvangen. Daarom zijn er geen beperkingen op de soorten internetapparaten
bruikbaar in ConfigureLocal-modus.

De TapBridge verschijnt voor een ns-3-simulatie als een kanaalloos netapparaat. Dit apparaat
Er mag geen IP-adres aan zijn gekoppeld, maar het overbrugde (ns-3) netwerkapparaat moet dat wel doen
een IP-adres hebben. Houd er rekening mee dat dit het omgekeerde is van een ns-3 BridgeNetDevice (of een
conventionele bridge in het algemeen) die eist dat de bridge-poorten geen IP-adressen hebben,
maar staat toe dat het bridge-apparaat zelf een IP-adres heeft.

De hostcomputer zal in een simulatie verschijnen als een "spook"-knooppunt dat er een bevat
TapBridge voor elk NetDevice dat wordt overbrugd. Vanuit het perspectief van een simulatie,
het enige verschil tussen een spookknooppunt en elk ander knooppunt is de aanwezigheid van de
TapBridge-apparaten. Houd er echter rekening mee dat de aanwezigheid van de TapBridge wel invloed heeft op de
connectiviteit van het netapparaat met de IP-stack van het spookknooppunt.

De configuratie van adresinformatie en de ns-3-apparaten wordt op geen enkele manier gewijzigd als:
TapBridge is aanwezig. Een TapBridge haalt de adresseringsinformatie op van de ns-3
netapparaat waarmee het is verbonden (het "overbrugde" netapparaat) en gebruikt die informatie
maak en configureer het TAP-apparaat op de echte host.

Het eindresultaat hiervan is een situatie waarin men bijvoorbeeld de standaard ping kan gebruiken
hulpprogramma op een echte host om een ​​gesimuleerd ns-3-knooppunt te pingen. Als de juiste routes zijn toegevoegd aan de
internethost (dit wordt naar verwachting automatisch gedaan in toekomstige ns-3-releases), de
routeringssystemen in ns-3 zullen een correcte routering van de pakketten over gesimuleerde ns-3 mogelijk maken
netwerken. Voor een voorbeeld hiervan zie het voorbeeldprogramma tap-wifi-dumbbell.cc in de
ns-3 distributie.

De Tap Bridge leeft in een soort grijze wereld ergens tussen een Linux-host en een ns-3
brug apparaat. Vanuit Linux-perspectief verschijnt deze code als de handler voor de gebruikersmodus
een TAP net-apparaat. In de ConfigureLocal-modus wordt dit Tap-apparaat automatisch aangemaakt door de
ns-3-simulatie. Wanneer de Linux-host naar een van deze schrijft, wordt deze automatisch aangemaakt
/dev/tap devices, het schrijven wordt omgeleid naar de TapBridge die in de ns-3-wereld leeft;
en vanuit dit perspectief wordt het schrijven van pakketten op Linux een pakket dat wordt gelezen in de Tap
Brug. Met andere woorden: een Linux-proces schrijft een pakket naar een tapapparaat en dit pakket
wordt door het netwerktapmechanisme omgeleid naar een ns-3-proces waar het wordt ontvangen door de
TapBridge als resultaat van een leesoperatie daar. De TapBridge schrijft vervolgens het pakket naar
het ns-3 net-apparaat waarmee het is overbrugd; en daarom lijkt het alsof de Linux-host
een pakket rechtstreeks via een ns-3-netapparaat naar een ns-3-netwerk verzonden.

In de andere richting wordt een pakket ontvangen door het ns-3-netapparaat dat op de Tap is aangesloten
Bridge wordt via een terugbelverzoek naar de TapBridge verzonden. De TapBridge neemt dat dan over
pakket en schrijft het terug naar de host met behulp van het netwerktapmechanisme. Dit schrijven naar de
het apparaat zal voor de Linux-host verschijnen alsof er een pakket op een netapparaat is aangekomen; En
dus alsof er een pakket is verschenen dat door het ns-3 net-apparaat is ontvangen tijdens een simulatie
op een echt Linux-netapparaat.

Het resultaat is dat de Tap Bridge een tapapparaat lijkt te overbruggen op een Linux-host in de
"echte wereld" naar een ns-3 net-apparaat in de simulatie. Omdat het TAP-apparaat en de
bridged ns-3 net-apparaat heeft hetzelfde MAC-adres en de netwerktap-IPC-link is dat niet
extern gemaakt, laat dit specifieke soort brug het lijken alsof het een ns-3 net-apparaat is
daadwerkelijk geïnstalleerd op de Linux-host.

Om dit aan de ns-3-kant te implementeren, hebben we in de simulatie een "ghost node" nodig
houd het overbrugde ns-3 net-apparaat en de TapBridge vast. Dit knooppunt zou dat eigenlijk niet moeten doen
al het andere in de simulatie, omdat het simpelweg de taak is om het internetapparaat erin te laten verschijnen
Linux. Dit is niet zomaar willekeurig beleid, maar omdat:

· Bits die vanuit hogere lagen in het spookknooppunt naar de TapBridge worden verzonden (met behulp van de TapBridge
Verzendmethode) worden volledig genegeerd. De TapBridge is zelf met geen enkele verbinding verbonden
netwerk, noch in Linux, noch in ns-3. U kunt nooit gegevens verzenden of ontvangen via een
TapBridge vanaf het spookknooppunt.

· De ontvangst-callback van het overbrugde ns-3 net-apparaat is losgekoppeld van het ns-3-knooppunt en
opnieuw verbonden met de Tap Bridge. Alle gegevens die door een gekoppeld apparaat worden ontvangen, worden vervolgens verzonden
naar de Linux-host en wordt niet ontvangen door het knooppunt. Vanuit het perspectief van de
ghost node, je kunt dit apparaat verzenden, maar je kunt nooit ontvangen.

Als u alle kwesties begrijpt, kunt u natuurlijk uw eigen lot in handen nemen
en doe wat je wilt - we voorkomen niet actief dat je het spookknooppunt gebruikt
alles wat je besluit. U kunt typische ns-3-bewerkingen op de geest uitvoeren
knooppunt als u dat wenst. De internetstack moet er bijvoorbeeld zijn en functioneel zijn
dat knooppunt om deel te nemen aan de toewijzing van IP-adressen en de globale routering. Echter,
zoals hierboven vermeld, interfaces die communiceren met TapBridge of bijbehorende overbrugde netwerkapparaten
zal niet volledig werken. Als u precies begrijpt wat u doet, kunt u het instellen
andere interfaces en apparaten op het spookknooppunt en deze gebruiken; of profiteer van de
operationele zendzijde van de overbrugde apparaten om verkeersgeneratoren te creëren. Wij in het algemeen
raad aan dat je dit knooppunt behandelt als een geest van de Linux-host en het aan zichzelf overlaat,
dat wel.

Tik op Brug Gebruik Lokaal Mode Werking
Zoals hierboven beschreven fungeert de TapBridge als een brug van de ‘echte’ wereld naar de wereld
gesimuleerde ns-3-wereld. In het geval van de ConfigureLocal-modus is het leven eenvoudig sinds het IP-adres
adres van het Tap-apparaat komt overeen met het IP-adres van het ns-3-apparaat en het MAC-adres van
het Tap-apparaat komt overeen met het MAC-adres van het ns-3-apparaat; en er is een één-op-één
relatie tussen de apparaten.

Het wordt enigszins ingewikkeld als een Tap-apparaat extern is geconfigureerd met een
ander MAC-adres dan het ns-3 net-apparaat. De conventionele manier om hiermee om te gaan
Een ander verschil is het gebruik van de promiscue modus in het overbrugde apparaat om pakketten te ontvangen
bestemd voor het andere MAC-adres en stuur ze door naar Linux. Om te bewegen
pakketten de andere kant op, de conventionele oplossing is SendFrom() waarmee een beller dit kan doen
"spoof" of wijzig het bron-MAC-adres zodat het overeenkomt met het andere Linux MAC-adres.

We hebben een specifieke vereiste om virtuele Linux-machines te kunnen overbruggen
draadloze STA-knooppunten. Helaas bieden de 802.11-specificaties geen goede manier om dit te doen
implementeer SendFrom(), dus we moeten dat probleem omzeilen.

Hiervoor hebben we de UseLocal-modus van de Tap Bridge geleverd. Deze modus maakt het mogelijk
benader het probleem alsof u een brug maakt met één enkel netapparaat. Een
het toegestane adres aan de Linux-kant wordt onthouden in de TapBridge en alle pakketten komen eraan
vanaf de Linux-kant worden herhaald aan de ns-3-kant met behulp van de MAC-bron van het ns-3-apparaat
adres. Alle pakketten die binnenkomen vanaf de ns-3-kant worden herhaald via de Linux-kant
het onthouden MAC-adres. Hierdoor kunnen we Send() gebruiken op de ns-3-apparaatzijde
beschikbaar op alle ns-3 net-apparaten.

De UseLocal-modus is identiek aan de ConfigureLocal-modus, met uitzondering van het maken en
configuratie van het tapapparaat en spoofing van het MAC-adres.

Tik op Brug Gebruik Bridge Werking
Zoals beschreven in de sectie ConfigureLocal-modus, wanneer de Linux-host naar een van de
/dev/tap devices wordt het schrijven omgeleid naar de TapBridge die in de ns-3-wereld leeft.
In het geval van de UseBridge-modus moeten deze pakketten op de ns-3 worden verzonden
netwerk alsof ze zijn verzonden op een apparaat dat deelneemt aan de Linux-bridge. Dit betekent
het aanroepen van de SendFrom()-methode op het overbrugde apparaat en het opgeven van het bron-MAC-adres
gevonden in het pakket.

In de andere richting wordt een pakket dat wordt ontvangen door een ns-3 net-apparaat via terugbellen aangehaakt
de TapBridge. Dit moet in promiscue modus worden gedaan, aangezien het doel is om de ns-3 te overbruggen
net-apparaat op de OS-brug (brctl) waarvan het TAP-apparaat deel uitmaakt.

Om deze redenen zijn alleen ns-3 net-apparaten die SendFrom() ondersteunen en een hookable
promiscue terugbellen mogen deelnemen aan de UseBridge-modus TapBridge
configuraties.

Tik Brug Kanaal Model
Er is geen kanaalmodel gekoppeld aan de Tap Bridge. In feite is het de bedoeling om te maken
het lijkt erop dat de echte internethost is verbonden met het kanaal van het overbrugde net
stuurt.

Tik Brug Tracing Model
In tegenstelling tot de meeste ns-3-apparaten biedt de TapBridge geen standaard traceerbronnen. Dit
komt omdat de brug een tussenpersoon is waarvan in wezen één functieaanroep verwijderd is
het overbrugde apparaat. We verwachten dat de traceerhaken in het overbrugde apparaat zullen zijn
voldoende voor de meeste gebruikers,

gebruik the Tik op Brug
We verwachten dat de meeste gebruikers via het TapBridge-apparaat zullen communiceren
Tik opBridgeHelper. Gebruikers van andere helperklassen, zoals CSMA of Wifi, zouden dat wel moeten zijn
op zijn gemak met de daar gebruikte idiomen.

ENERGIE KADER

Energieverbruik is een belangrijk probleem voor draadloze apparaten en onderzoekers van draadloze netwerken
moeten vaak het energieverbruik op een knooppunt of in het totale netwerk onderzoeken
netwerksimulaties uitvoeren in ns-3. Hiervoor is ns-3 nodig om het energieverbruik te ondersteunen
modellering. Verder worden concepten als brandstofcellen en energieopruiming steeds populairder
haalbaar voor draadloze apparaten met een laag vermogen, waarbij het effect van deze opkomst wordt meegenomen
technologieën in simulaties vereist ondersteuning voor het modelleren van diverse energiebronnen in
ns-3. Het ns-3 Energy Framework biedt de basis voor energieverbruik, energiebron
en energie-oogstmodellering.

Model Beschrijving
De broncode voor het Energy Framework bevindt zich momenteel op: src/energie.

Design
Het ns-3 Energy Framework bestaat uit 3 delen: Energiebron, Apparaatenergiemodel en
Energie oogster. Het raamwerk wordt geïmplementeerd in de src/energie/modellen map.

Energie bron
De Energiebron vertegenwoordigt de stroomvoorziening op elk knooppunt. Een knooppunt kan er een of meer hebben
energiebronnen, en elke energiebron kan worden aangesloten op de energiemodellen van meerdere apparaten.
Het aansluiten van een energiebron op een energiemodel van een apparaat impliceert dat het bijbehorende apparaat
haalt stroom uit de bron. De basisfunctionaliteit van de Energiebron is het leveren van energie
energie voor apparaten op het knooppunt. Wanneer de energie volledig uit de energiebron is gehaald,
het waarschuwt de apparaten op het knooppunt zodat elk apparaat op deze gebeurtenis kan reageren. Verder,
elk knooppunt heeft toegang tot de energiebronobjecten voor informatie zoals de resterende energie of
energiefractie (batterijniveau). Dit maakt de implementatie van energiebewuste protocollen mogelijk
in ns-3.

Om een ​​breed scala aan voedingen, zoals batterijen, te kunnen modelleren, moet de Energiebron dat wel doen
in staat zijn de kenmerken van deze benodigdheden vast te leggen. Er zijn er 2 belangrijk
kenmerken of effecten gerelateerd aan praktische batterijen:

tarief Inhoud Effect
Verkorting van de levensduur van de batterij wanneer het stroomverbruik hoger is dan de nominale waarde
van de batterij.

Herstel Effect
Verlenging van de levensduur van de batterij wanneer de batterij afwisselend ontlaadt en ontlaadt
inactieve toestanden.

Om het Rate Capacity Effect te integreren, gebruikt de Energiebron stroomafname
alle apparaten op hetzelfde knooppunt om het energieverbruik te berekenen. Bovendien meerdere
Energy Harvesters kunnen op de Energiebron worden aangesloten om de energie ervan aan te vullen.
De Energiebron ondervraagt ​​periodiek alle apparaten en energieoogsters
knooppunt om de totale stroomafname en daarmee het energieverbruik te berekenen. Wanneer een apparaat
van status verandert, zal het bijbehorende apparaatenergiemodel de energiebron hiervan op de hoogte stellen
verandering en het nieuwe totale stroomverbruik wordt berekend. Hetzelfde geldt voor elke Energy Harvester
update activeert een update van de aangesloten energiebron.

De basisklasse Energiebron houdt een lijst bij van apparaten (Device Energy Model-objecten) en
energieoogsters (Energy Harvester-objecten) die de specifieke energiebron gebruiken
als stroomvoorziening. Wanneer de energie volledig is opgebruikt, zal de Energiebron iedereen hiervan op de hoogte stellen
apparaten op deze lijst. Elk apparaat kan deze gebeurtenis vervolgens onafhankelijk afhandelen, op basis van de
gewenst gedrag dat moet worden gevolgd bij stroomuitval.

Apparaat Energie Model
Het Device Energy Model is het energieverbruikmodel van een apparaat dat op het knooppunt is geïnstalleerd.
Het is ontworpen als een statusgebaseerd model waarbij wordt aangenomen dat elk apparaat een aantal heeft
staten, en elke staat is gekoppeld aan een stroomverbruikswaarde. Wanneer de staat van
het apparaat verandert, zal het overeenkomstige apparaatenergiemodel de energiebron hiervan op de hoogte stellen
het nieuwe stroomverbruik van het apparaat. De Energiebron berekent dan het nieuwe totaal
stroomverbruik en update de resterende energie.

Het Device Energy Model kan ook worden gebruikt voor apparaten die geen eindig aantal hebben
staten. Bij een elektrisch voertuig wordt bijvoorbeeld het stroomverbruik van de motor bepaald
door zijn snelheid. Omdat de snelheid van het voertuig binnen een bepaald bereik continue waarden kan aannemen,
het is onhaalbaar om een ​​reeks discrete werkingstoestanden te definiëren. Echter door te converteren
de snelheidswaarde direct in stroom omzetten, dezelfde set Device Energy Model API's kan nog steeds
worden gebruikt.

Energie Oogster
De energieoogster vertegenwoordigt de elementen die energie uit de omgeving oogsten en
laad de energiebron op waarmee deze is verbonden. De energieoogster omvat de
volledige implementatie van het eigenlijke apparaat voor het oogsten van energie (bijvoorbeeld een zonnepaneel) en
de omgeving (bijvoorbeeld de zonnestraling). Dit betekent dat bij het implementeren van een energie
oogstmachine, de energiebijdrage van de omgeving en de extra energie
vereisten van het energieoogstapparaat, zoals de conversie-efficiëntie en de
het interne energieverbruik van het apparaat moet gezamenlijk worden gemodelleerd.

WiFi Radio Energie Model
Het WiFi Radio Energy Model is het energieverbruiksmodel van een Wifi-netapparaat. Het
biedt een status voor elk van de beschikbare staten van de PHY-laag: Idle, CcaBusy, Tx, Rx,
Kanaalschakelaar, slaap. Elk van deze toestanden is geassocieerd met een waarde (in Ampère) van de
huidige trekking (zie hieronder voor de bijbehorende attribuutnamen). Een Wifi-radio-energiemodel
PHY De luisteraar is geregistreerd bij de Wifi PHY om op de hoogte te worden gehouden van elke Wifi PHY-status
overgang. Bij elke transitie wordt de verbruikte energie in de vorige toestand berekend
de energiebron wordt op de hoogte gesteld om de resterende energie bij te werken.

Het Wifi Tx Current Model geeft de mogelijkheid om de stroomafname in de te berekenen
zendstatus als functie van het nominale TX-vermogen (in dBm), zoals waargenomen in verschillende
experimentele metingen. Voor dit doel is het Wifi Radio Energy Model PHY Listener bedoeld
op de hoogte gebracht van het nominale tx-vermogen dat wordt gebruikt om het huidige frame te verzenden en een dergelijke doorgeeft
waarde aan het Wifi Tx Current Model dat zorgt voor het bijwerken van de huidige trekking in de Tx
staat. Daarom wordt het energieverbruik correct berekend, zelfs als het Wifi Remote Station is ingeschakeld
Manager voert energiebeheer per frame uit. Momenteel is er een lineair Wifi Tx-huidig ​​model
geïmplementeerd die de tx-stroom berekent als een lineaire functie (volgens parameters
dat door de gebruiker kan worden gespecificeerd) van het nominale tx-vermogen in dBm.

Het Wifi Radio Energy Model biedt de mogelijkheid om een ​​callback op te geven die wordt aangeroepen
wanneer de energiebron uitgeput is. Als een dergelijke terugbelactie niet is opgegeven wanneer de Wifi
Radio Energy Model Helper wordt gebruikt om het model op een apparaat te installeren, er wordt teruggebeld
impliciet zo gemaakt dat de Wifi PHY in de SLEEP-modus wordt gezet (dus geen frame).
verzonden noch achteraf ontvangen) wanneer de energiebron is uitgeput. Zo is het ook
Het is mogelijk om een ​​callback te specificeren die wordt aangeroepen wanneer de energiebron wordt opgeladen (welke
kan gebeuren als er een energie-oogster op de energiebron is aangesloten). Als een dergelijke
terugbellen is niet gespecificeerd wanneer de Wifi Radio Energy Model Helper wordt gebruikt om de
model op een apparaat wordt er impliciet teruggebeld zodat de Wifi PHY wordt hervat vanaf de
SLEEP-modus wanneer de energiebron is opgeladen.

toekomst Werk met
Voor Device Energy Models zijn we van plan ondersteuning voor andere PHY-laagmodellen op te nemen
aangeboden in ns-3 zoals WiMAX, en om het energieverbruik van andere niet-apparaten te modelleren
communicerende apparaten, zoals een generieke sensor en een CPU. Voor energiebronnen zijn wij dat wel
van plan om nieuwe soorten energiebronnen op te nemen, zoals supercondensator en nikkelmetaal
Hydridebatterij (Ni-MH). Voor de Energy Harvesters zijn we van plan een energiesysteem te implementeren
oogstmachine die de energiebronnen oplaadt volgens de vermogensniveaus gedefinieerd in a
door de gebruiker aanpasbare dataset van echte metingen.

Referenties
[1] ns-2 Energiemodel:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu, S. Nabar en R. Poovendran. Een energiekader voor de netwerksimulator 3
(ns-3).

[3] M. Handy en D. Timmermann. Simulatie van mobiele draadloze netwerken met nauwkeurige
modellering van niet-lineaire batterij-effecten. In Proc. van toegepaste simulatie en modellering
(ASM), 2003.

[4] D. N. Rakhmatov en S. B. Vrudhula. Een analytisch hoog-niveau batterijmodel voor gebruik in
energiebeheer van draagbare elektronische systemen. In Proc. van IEEE/ACM International
Conferentie over Computer Aided Design (ICCAD'01), pagina's 488-493, november 2001.

[5] D.N. Rakhmatov, S.B. Vrudhula en D.A. Wallach. Voorspelling van de levensduur van de batterij voor
energiebewust computergebruik. In Proc. van het Internationale Symposium over Laag Vermogen van 2002
Elektronica en design (ISLPED'02), pagina's 154-159, 2002.

[6] C. Tapparello, H. Ayatollahi en W. Heinzelman. Uitbreiding van het Energiekader voor
Netwerksimulator 3 (ns-3). Workshop over ns-3 (WNS3), Postersessie, Atlanta, GA,
VERENIGDE STATEN VAN AMERIKA. Mei 2014.

Gebruik
De belangrijkste manier waarop ns-3-gebruikers doorgaans met het Energiekader zullen communiceren, is via
de helper-API en via de publiekelijk zichtbare attributen van het raamwerk. De helper
API is gedefinieerd in src/energie/helper/*.h.

Om het energieframework te kunnen gebruiken, moet de gebruiker een energiebron voor het knooppunt installeren
van belang, het overeenkomstige Device Energy Model voor de netwerkapparaten en, indien
nodig, de een of meer Energy Harvesters. Energiebron (objecten) worden samengevoegd
elk knooppunt door de Energiebronhelper. Om meerdere energiebronnen per knooppunt mogelijk te maken,
we aggregeren een energiebroncontainer in plaats van direct een bronobject te aggregeren.

Het object Energiebron houdt een lijst bij van de objecten Apparaatenergiemodel en Energieoogster
waarbij de bron als voeding wordt gebruikt. Device Energy Model-objecten worden op het apparaat geïnstalleerd
Energiebron door de Device Energy Model Helper, terwijl het Energy Harvester-object dat is
geïnstalleerd door de Energy Harvester Helper. De gebruiker heeft toegang tot de Device Energy Model-objecten
via het object Energiebron om informatie over het energieverbruik van een individu te verkrijgen
apparaten. Bovendien heeft de gebruiker toegang tot de Energy Harvester-objecten om deze te verzamelen
informatie over het huidige oogstbare vermogen en de totale energie die wordt geoogst door de
oogstmachine.

Voorbeelden
De voorbeeldmappen, src/voorbeelden/energie en voorbeelden/energie, bevatten een aantal basiscodes
dat laat zien hoe het raamwerk moet worden opgezet.

helpers
Energie bron Helper
Basishelperklasse voor Energiebronobjecten. Deze helper verzamelt het Energiebronobject
op een knooppunt. De onderliggende implementatie van deze klasse creëert het daadwerkelijke object Energiebron.

Apparaat Energie Model Helper
Basishelperklasse voor Device Energy Model-objecten, deze helper voegt Device Energy toe
Modelleer objecten op energiebronobjecten. De onderliggende implementatie van deze klasse creëert de
feitelijk Device Energy Model-object.

Energie oogst Helper
Basishelperklasse voor Energy Harvester-objecten, deze helper voegt Energy Harvester toe
objecten op Energiebronobjecten. De kindimplementatie van deze klasse creëert de actual
Energy Harvester-object.

Attributen
Kenmerken verschillen tussen energiebronnen, apparaten, energiemodellen en energieoogsters
implementaties, kijk dan naar de specifieke kindklasse voor details.

Basic Energie bron
· BasisEnergiebronInitiëleEnergieJ: Initiële energie opgeslagen in de basisenergiebron.

· BasisEnergievoorzieningSpanningV: Initiële voedingsspanning voor basisenergiebron.

· PeriodiekeEnergieUpdateInterval: Tijd tussen twee opeenvolgende periodieke energie-updates.

RV accu Model
· RvBatteryModelPeriodiekeEnergieUpdateInterval: Bemonsteringsinterval voor RV-batterijmodel.

· RvBatterijModelOpen CircuitSpanning: Open circuit spanning RV-accumodel.

· RvBatteryModelCutoffVoltage: Uitschakelspanning model RV-accu.

· RvBatteryModelAlphaValue: Alpha-waarde model camperbatterij.

· RvBatteryModelBetaValue: Bètawaarde van model camperbatterij.

· RvBatteryModelNumOfTerms: het aantal termen van de oneindige som voor het schatten van de batterij
niveau.

WiFi Radio Energie Model
· Inactieve stroomA: De standaard stationairstroom van de radio in Ampère.

· CcaBezetHuidigeA: De standaard radio CCA Busy State-stroom in Ampère.

· TxHuidigeA: De radio Tx-stroom in Ampère.

· RxHuidigeA: De radio Rx-stroom in Ampère.

· SchakelstroomA: De standaard radiokanaalschakelaarstroom in Ampère.

· SlaapHuidigeA: De radio Slaapstroom in Ampere.

· TxCurrentModel: Een verwijzing naar het bijgevoegde huidige TX-model.

Basic Energie Oogster
· PeriodiekGeoogstVermogenUpdateInterval: Tijd tussen twee opeenvolgende periodieke updates van
de geoogste kracht.

· Oogstbare kracht: Willekeurige variabelen die de hoeveelheid geleverde stroom vertegenwoordigen
door de energie-oogster.

Tracing
Getraceerde waarden verschillen tussen energiebronnen, apparaten, energiemodellen en energieoogsters
implementaties, kijk dan naar de specifieke kindklasse voor details.

Basic Energie bron
· Resterende Energie: Resterende energie bij BasicEnergySource.

RV accu Model
· RvBatteryModelBatterijniveau: Batterijniveau camperbatterijmodel.

· RvBatteryModelBatterijLevensduur: Levensduur van de batterij van het RV-batterijmodel.

WiFi Radio Energie Model
· Totaal energieverbruik: Totaal energieverbruik van het radioapparaat.

Basic Energie Oogster
· Geoogste kracht: Huidig ​​vermogen geleverd door de BasicEnergyHarvester.

· Totale energie geoogst: Totale energie geoogst door de BasicEnergyHarvester.

Validatie
Er is geen vergelijking van het Energiekader met daadwerkelijke apparaten uitgevoerd. Huidig
implementatie van het Energiekader wordt numeriek gecontroleerd op rekenfouten. De
Het RV-batterijmodel wordt gevalideerd door de resultaten te vergelijken met wat in het origineel werd gepresenteerd
Modelpapier voor camperbatterijen.

STROMEN MONITOR

Model Beschrijving
De broncode voor de nieuwe module bevindt zich in de directory src/flow-monitor.

Het doel van de Flow Monitor-module is om een ​​flexibel systeem te bieden om de prestaties van te meten
netwerkprotocollen. De module maakt gebruik van sondes, geïnstalleerd in netwerkknooppunten, om de
pakketten die door de knooppunten worden uitgewisseld, en het zal een aantal parameters meten. Pakketten zijn
verdeeld volgens de stroom waartoe ze behoren, waarbij elke stroom wordt gedefinieerd volgens de
de kenmerken van de probe (voor IP wordt een stroom bijvoorbeeld gedefinieerd als de pakketten met hetzelfde
{protocol, bron (IP, poort), bestemming (IP, poort)} tupel.

De statistieken die voor elke stroom worden verzameld, kunnen in XML-formaat worden geëxporteerd. Bovendien is de
De gebruiker heeft rechtstreeks toegang tot de sondes om specifieke statistieken over elke stroom op te vragen.

Design
De Flow Monitor-module is modulair ontworpen. Het kan worden uitgebreid door subclassificatie
ns3::FlowProbe en ns3::FlowClassifier.

Het volledige moduleontwerp wordt beschreven in [FlowMonitor]

strekking en Beperkingen
Momenteel zijn er probes en classifiers beschikbaar voor IPv4 en IPv6.

Elke probe classificeert pakketten in vier punten:

· Wanneer een pakket wordt verzonden (SendOutgoing IPv[4,6]-traceringen)

· Wanneer een pakket wordt doorgestuurd (UnicastForward IPv[4,6]-traceringen)

· Wanneer een pakket wordt ontvangen (LocalDeliver IPv[4,6]-traceringen)

· Wanneer een pakket wordt verwijderd (IPv[4,6]-traceringen verwijderen)

Omdat de pakketten op IP-niveau worden gevolgd, wordt elke hertransmissie veroorzaakt door L4-protocollen
(bijvoorbeeld TCP) zal door de probe worden gezien als een nieuw pakket.

Er wordt een tag aan het pakket toegevoegd (ns3::Ipv[4,6]FlowProbeTag). De tag zal basic dragen
pakketgegevens, nuttig voor de classificatie van het pakket.

Er moet worden benadrukt dat tot nu toe alleen L4-pakketten (TCP, UDP) zijn geclassificeerd. Bovendien,
alleen unicast-pakketten worden geclassificeerd. Deze beperkingen kunnen in de toekomst worden opgeheven.

De voor elke stroom verzamelde gegevens zijn:

· timeFirstTxPacket: wanneer het eerste pakket in de stroom werd verzonden;

· timeLastTxPacket: wanneer het laatste pakket in de stroom is verzonden;

· timeFirstRxPacket: wanneer het eerste pakket in de stroom werd ontvangen door een eindknooppunt;

· timeLastRxPacket: wanneer het laatste pakket in de stroom werd ontvangen;

· delaySum: de som van alle end-to-end vertragingen voor alle ontvangen pakketten van de stroom;

· jitterSum: de som van alle end-to-end delay jitter (vertragingsvariatie) waarden voor iedereen
ontvangen pakketten van de stroom, zoals gedefinieerd in RFC 3393;

· txBytes, txPackets: totaal aantal verzonden bytes/pakketten voor de stroom;

· rxBytes, rxPackets: totaal aantal ontvangen bytes/pakketten voor de stroom;

· lostPackets: totaal aantal pakketten waarvan wordt aangenomen dat ze verloren zijn gegaan (niet gerapporteerd boven de 10
seconden);

· timesForwarded: het aantal keren dat een pakket naar verluidt is doorgestuurd;

· delayHistogram, jitterHistogram, packetSizeHistogram: histogramversies voor de vertraging,
respectievelijk jitter en pakketgroottes;

· packetsDropped, bytesDropped: het aantal verloren pakketten en bytes, verdeeld volgens
de code voor de reden van verlies (gedefinieerd in de probe).

Het is de moeite waard erop te wijzen dat de probes de pakketbytes meten, inclusief IP-headers.
De L2-headers zijn niet opgenomen in de maatregel.

Deze statistieken worden op verzoek in XML-vorm geschreven (zie het gedeelte Gebruik).

Referenties
[Stroommonitor]

G. Carneiro, P. Fortuna en M. Ricardo. 2009. FlowMonitor: een raamwerk voor netwerkmonitoring
voor de netwerksimulator 3 (NS-3). In Proceedings van de Vierde Internationale ICST
Conferentie over methodologieën en hulpmiddelen voor prestatie-evaluatie (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

Gebruik
Het gebruik van de module is uiterst eenvoudig. De helper regelt alles.

Het typische gebruik is:

// Stroommonitor
Ptr flowMonitor;
FlowMonitorHelper flowHelper;
flowMonitor = flowHelper.InstallAll();

Simulator::Stop (Seconden(stop_time));
Simulator::Uitvoeren ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", waar, waar);

the SerializeToXmlFile () functie 2e en 3e parameters worden respectievelijk gebruikt
activeer/deactiveer de histogrammen en de gedetailleerde statistieken per sonde.

Andere mogelijke alternatieven zijn te vinden in de Doxygen-documentatie.

helpers
De helper-API volgt het patroongebruik van normale helpers. Via de helper kan dat
installeer de monitor in de knooppunten, stel de monitorattributen in en druk de statistieken af.

Eén belangrijk ding is: de ns3::FlowMonitorHelper mag slechts één keer worden geïnstantieerd in de
hoofd.

Attributen
De module biedt de volgende attributen in ns3::FlowMonitor:

· MaxPerHopDelay (Tijd, standaard 10s): de maximale vertraging per hop waarmee rekening moet worden gehouden;

· StartTime (Tijd, standaard 0s): Het tijdstip waarop de monitoring start;

· DelayBinWidth (dubbel, standaard 0.001): de breedte die wordt gebruikt in het vertragingshistogram;

· JitterBinWidth (dubbel, standaard 0.001): de breedte die wordt gebruikt in het jitterhistogram;

· PacketSizeBinWidth (dubbel, standaard 20.0): de breedte die wordt gebruikt in het packetSize-histogram;

· FlowInterruptionsBinWidth (dubbel, standaard 0.25): de breedte die wordt gebruikt in de
flowInterrupties-histogram;

· FlowInterruptionsMinTime (dubbel, standaard 0.5): de minimale tijd tussen aankomsten
beschouwd als een stroomonderbreking.

uitgang
De belangrijkste modeluitvoer is een XML-geformatteerd rapport over stroomstatistieken. Een voorbeeld is:




























De uitvoer is gegenereerd door een TCP-stroom van 10.1.3.1 naar 10.1.2.2.

Het is de moeite waard om op te merken dat de index 2-sonde meer pakketten en meer bytes rapporteert dan
de andere problemen. Dat is een volkomen normaal gedrag, aangezien pakketten op IP gefragmenteerd zijn
niveau in dat knooppunt.

Er moet ook worden opgemerkt dat de probe van het ontvangende knooppunt (index 4) de
fragmenten, omdat de hermontage vóór het sondeerpunt plaatsvindt.

Voorbeelden
De voorbeelden bevinden zich in src/flow-monitor/voorbeelden.

Bovendien gebruiken de volgende voorbeelden de flowmonitormodule:

· voorbeelden/matrix-topologie/matrix-topologie.cc

· voorbeelden/routing/manet-routing-compare.cc

· voorbeelden/routing/simple-global-routing.cc

· voorbeelden/tcp/tcp-varianten-vergelijking.cc

· voorbeelden/draadloos/multirate.cc

· voorbeelden/draadloos/wifi-verborgen-terminal.cc

Troubleshooting
Definieer er niet meer dan één ns3::FlowMonitorHelper in de simulatie.

Validatie
Het artikel in de referenties bevat een volledige beschrijving van de modulevalidatie tegen a
netwerk testen.

Er zijn tests beschikbaar om te garanderen dat het histogram correct functioneert.

INTERNET MODELLEN

Internet Opstapelen
Internet stack aggregatie
Een kale klasse Knooppunt is niet erg nuttig zoals het is; andere objecten moeten eraan worden geaggregeerd
bieden nuttige knooppuntfunctionaliteit.

De ns-3 broncodemap src/internet biedt implementatie van TCP/IPv4- en
IPv6-gerelateerde componenten. Deze omvatten IPv4, ARP, UDP, TCP, IPv6, Neighbor Discovery en
andere gerelateerde protocollen.

Internetknooppunten zijn geen subklassen van klasse Node; het zijn eenvoudigweg knooppunten die een
een aantal IP-gerelateerde objecten die daaraan zijn samengevoegd. Ze kunnen met de hand in elkaar worden gezet, of via een
helper functie InternetStackHelper::Installeren () wat het volgende doet voor alle knooppunten
doorgegeven als argumenten:

komen te vervallen
InternetStackHelper::Install (Ptr knooppunt) const
{
als (m_ipv4Enabled)
{
/* IPv4-stack */
if (knooppunt->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): Aggregeren "
"een InternetStack naar een knooppunt met een bestaand IPv4-object");
terug te keren;
}

CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::Icmpv4L4Protocol");
// Routering instellen
Ptr ipv4 = knooppunt->GetObject ();
Ptr ipv4Routing = m_routing->Maken (knooppunt);
ipv4->SetRoutingProtocol (ipv4Routing);
}

als (m_ipv6Enabled)
{
/* IPv6-stack */
if (knooppunt->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): Aggregeren "
"een InternetStack naar een knooppunt met een bestaand IPv6-object");
terug te keren;
}

CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::Icmpv6L4Protocol");
// Routering instellen
Ptr ipv6 = knooppunt->GetObject ();
Ptr ipv6Routing = m_routingv6->Maken (knooppunt);
ipv6->SetRoutingProtocol (ipv6Routing);

/* registreer IPv6-extensies en -opties */
ipv6->RegistreerExtensies ();
ipv6->Registreeropties ();
}

als (m_ipv4Enabled || m_ipv6Enabled)
{
/* UDP- en TCP-stacks */
CreateAndAggregateObjectFromTypeId (knooppunt, "ns3::UdpL4Protocol");
knooppunt->AggregateObject (m_tcpFactory.Create ());
Ptr fabriek = CreateObject ();
knooppunt->AggregateObject (fabriek);
}
}

Waar meerdere implementaties bestaan ns-3 (TCP, IP-routering), deze objecten worden toegevoegd door
een fabrieksobject (TCP) of door een routeringshelper (m_routing).

Houd er rekening mee dat het routeringsprotocol buiten deze functie wordt geconfigureerd en ingesteld. Standaard,
de volgende protocollen worden toegevoegd:

void InternetStackHelper::Initialiseren ()
{
SetTcp ("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper statischeRouting;
Ipv4GlobalRoutingHelper globalRouting;
Ipv4ListRoutingHelperlijstRouting;
Ipv6ListRoutingHelperlijstRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add (staticRouting, 0);
listRouting.Add (globalRouting, -10);
listRoutingv6.Add (staticRoutingv6, 0);
SetRoutingHelper (lijstRouting);
SetRoutingHelper (listRoutingv6);
}

Standaard zijn IPv4 en IPv6 ingeschakeld.

Internet Knooppunt structuur
Een IP-compatibel knooppunt (een ns-3 Knooppunt aangevuld door aggregatie om een ​​of meer IP-stacks te hebben)
heeft de volgende interne structuur.

Layer-3 protocollen
Op de laagste laag, boven de NetDevices, bevinden zich de "laag 3"-protocollen, inclusief
IPv4, IPv6, ARP enzovoort. De klas Ipv4L3-protocol is een implementatieklasse waarvan
openbare interface is doorgaans klasse Ipv4, maar de openbare API Ipv4L3Protocol wordt ook gebruikt
intern momenteel.

In klasse Ipv4L3Protocol is één hieronder beschreven methode Ontvangen ():

/ **
* De lagere laag roept deze methode aan na het aanroepen van L3Demux::Lookup
* De ARP-subklasse moet weten vanaf welk NetDevice dit is
*pakket komt naar:
* - implementeer een ARP-cache per NetDevice
* - stuur arp-antwoorden terug op het juiste apparaat
*/
void Receiver( Ptr apparaat, Ptr p, uint16_t protocol,
const Adres &from, const Adres &to, NetDevice::PacketType packetType);

Merk allereerst op dat de Ontvangen () functie heeft een overeenkomende handtekening met de ReceiverCallback
in de klas Knooppunt. Deze functieaanwijzer wordt ingevoegd in de protocolhandler van het knooppunt wanneer
Interface toevoegen () wordt genoemd. De daadwerkelijke registratie gebeurt met een verklaring zoals
volgt:

RegisterProtocolHandler (MakeCallback (&Ipv4Protocol::Ontvangen, ipv4),
Ipv4L3Protocol::PROT_NUMBER, 0);

Het Ipv4L3Protocol-object wordt samengevoegd met het knooppunt; er is maar één zo'n Ipv4L3Protocol
voorwerp. Protocollen van een hogere laag die een pakket hebben dat naar het Ipv4L3Protocol moet worden verzonden
object kan bellen GetObject () om een ​​pointer te verkrijgen, als volgt:

Ptr ipv4 = m_node->GetObject ();
als (ipv4 != 0)
{
ipv4->Verzenden (pakket, saddr, daddr, PROT_NUMBER);
}

Deze klasse demonstreert mooi twee technieken waarin we exploiteren ns-3 objecten aan elkaar binden:
callbacks en objectaggregatie.

Zodra IPv4-routering heeft vastgesteld dat een pakket voor het lokale knooppunt bestemd is, wordt het doorgestuurd
de stapel. Dit gebeurt met de volgende functie:

komen te vervallen
Ipv4L3Protocol::LocalDeliver (Ptr pakket, Ipv4Header const&ip, uint32_t iif)

De eerste stap is het vinden van het juiste Ipv4L4Protocol-object, gebaseerd op het IP-protocolnummer.
TCP wordt bijvoorbeeld in de demux geregistreerd als protocolnummer 6. Tenslotte wordt de Ontvangen()
functie op het Ipv4L4Protocol (zoals TcpL4Protocol::Ontvangen wordt genoemd.

We hebben de klasse Ipv4Interface nog niet geïntroduceerd. In principe is elk NetDevice gekoppeld
met een IPv4-weergave van een dergelijk apparaat. In Linux, deze klasse IPv4Interface ruw
komt overeen met de struct in_apparaat; het belangrijkste doel is om adres-familie te verstrekken
specifieke informatie (adressen) over een interface.

Alle klassen hebben de juiste sporen om verzonden, ontvangen en verloren pakketten te volgen.
De gebruikers worden aangemoedigd om ze te gebruiken om erachter te komen of (en waar) een pakket is gedropt. A
Een veelgemaakte fout is het vergeten van de effecten van lokale wachtrijen bij het verzenden van pakketten, bijvoorbeeld de
ARP-wachtrij. Dit kan vooral verwarrend zijn bij het verzenden van jumbopakketten of pakketbursts
met behulp van UDP. De wachtwachtrij voor de ARP-cache is beperkt (3 datagrammen) en IP-pakketten kunnen dat ook zijn
gefragmenteerd, waardoor de wachtrijgrootte van de ARP-cache gemakkelijk te vol raakt. In die gevallen is het nuttig om
verhoog de ARP-cache in afwachting van de grootte tot een juiste waarde, bijvoorbeeld:

Config::SetDefault ("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3));

De IPv6-implementatie volgt een vergelijkbare architectuur. Dual-gestapelde knooppunten (één met
ondersteuning voor zowel IPv4 als IPv6) zorgt ervoor dat een IPv6-socket IPv4-verbindingen kan ontvangen als een
standaard dual-stacked systeem doet dat wel. Een socket gebonden en luisteren naar een IPv6-eindpunt kan
ontvangt een IPv4-verbinding en retourneert het externe adres als een IPv4-toegewezen adres.
Ondersteuning voor de socketoptie IPV6_V6ONLY bestaat momenteel niet.

Layer-4 protocollen en stopcontacten
Vervolgens beschrijven we hoe de transportprotocollen, sockets en applicaties met elkaar verbonden zijn. In
Kortom, elke implementatie van het transportprotocol is een socketfabriek. Een applicatie die
heeft een nieuw stopcontact nodig

Om bijvoorbeeld een UDP-socket te maken, gebruikt een applicatie een codefragment zoals de
volgende:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Binden (m_local_address);
...

Het bovenstaande zal het knooppunt ondervragen om een ​​verwijzing naar de UDP-socketfabriek te krijgen, en er een maken
zo'n socket, en zal de socket gebruiken met een API die vergelijkbaar is met de C-gebaseerde sockets API, such
as Connect () en stuur (). Het adres is doorgegeven aan de binder (), Connect ()of stuur ()
functies kunnen zijn: a IPv4-adres, IPv6-adresof Adres. Als een Adres wordt doorgegeven en
bevat iets anders dan een IPv4-adres or IPv6-adres, deze functies retourneren een
fout. De binder (leegte) en Binden6 (leegte) functies binden aan "0.0.0.0" en "::"
respectievelijk.

De socket kan ook aan een specifiek NetDevice worden gekoppeld via de BindToNetDevice
(Ptr netapparaat) functie. BindToNetDevice (Ptr netapparaat) zal binden
de socket naar "0.0.0.0" en "::" (gelijk aan bellen binder () en Binden6 (), Tenzij de
socket is al gebonden aan een specifiek adres. Kortom, de juiste volgorde
is:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
...

of:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Binden (m_local_address);
m_socket->BindToNetDevice (n_netDevice);
...

Het volgende geeft een foutmelding:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
m_socket->Binden (m_local_address);
...

Zie het hoofdstuk over ns-3 stopcontacten voor meer informatie.

Tot nu toe hebben wij een stopcontactenfabriek beschreven (bijv. klasse udp) en een stopcontact, dat kan zijn
gespecialiseerd (bijv. klasse UdpSocket). Er zijn nog een paar belangrijke objecten die verband houden met de
gespecialiseerde taak voor het demultiplexen van een pakket naar een of meer ontvangende sockets. De sleutel
object in deze taak is klasse Ipv4EndPointDemux. Deze demultiplexer slaat objecten op van
klasse IPv4EndPoint. Deze klasse bevat de adresserings-/poorttupel (lokale poort, lokaal
adres, bestemmingspoort, bestemmingsadres) geassocieerd met de socket, en een ontvangst
Bel terug. Deze ontvangst-callback heeft een ontvangstfunctie die wordt geregistreerd door de socket. De
Lookup () functie naar Ipv4EndPointDemux retourneert een lijst met Ipv4EndPoint-objecten (er kunnen
een lijst zijn, aangezien meer dan één socket met het pakket kan overeenkomen). De laag-4-protocolkopieën
het pakket naar elk Ipv4EndPoint en roept het aan VooruitOmhoog () methode, die vervolgens de
Ontvangen () functie geregistreerd door de socket.

Een probleem dat zich voordoet bij het werken met de sockets API op echte systemen is de noodzaak om dat te doen
beheer het lezen vanaf een socket, met behulp van een soort I/O (bijvoorbeeld blokkerend, niet-blokkerend,
asynchroon, ...). ns-3 implementeert een asynchroon model voor socket I/O; de applicatie
stelt een callback in om op de hoogte te worden gesteld van ontvangen gegevens die klaar zijn om te worden gelezen, en de callback is
aangeroepen door het transportprotocol wanneer gegevens beschikbaar zijn. Deze callback wordt gespecificeerd als
volgt:

void Socket::SetRecvCallback (Callback,
Ptr,
const adres&> ontvangen gegevens);

De ontvangen gegevens worden overgebracht naar de pakketgegevensbuffer. Een voorbeeldgebruik is binnen
klasse PacketSink:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, dit));

Samenvattend is de UDP-implementatie intern als volgt georganiseerd:

· A UdpImpl klasse die de UDP-socketfabrieksfunctionaliteit implementeert

· A UdpL4-protocol klasse die de protocollogica implementeert die socket-onafhankelijk is

· A UdpSocketImpl klasse die socket-specifieke aspecten van UDP implementeert

· een klas genaamd IPv4EndPoint waarin de adresseringstupel wordt opgeslagen (lokale poort, lokaal adres,
bestemmingspoort, bestemmingsadres) geassocieerd met de socket, en een ontvangst
terugbellen voor de socket.

IP-compatibel knooppunt interfaces
Veel van de implementatiedetails, of interne objecten zelf, van IP-compatibele Node
objecten worden niet weergegeven in de openbare API van de simulator. Dit maakt verschillende mogelijk
implementaties; bijvoorbeeld het vervangen van de inheemse ns-3 modellen met geporteerde TCP/IP-stack
code.

De openbare C++-API's van al deze objecten zijn te vinden in de src/netwerk adresboek,
waaronder voornamelijk:

· adres.h

· stopcontact.h

· knooppunt.h

· pakket.h

Dit zijn doorgaans basisklasseobjecten die de standaardwaarden implementeren die worden gebruikt in de
implementatie, toegangsmethoden implementeren om statusvariabelen, hostattributen op te halen/in te stellen, en
implementeer openbaar beschikbare methoden die aan klanten worden blootgesteld, zoals MaakSocket.

Voorbeeld pad of a pakket
Deze twee figuren tonen een voorbeeld van een stacktrace van hoe pakketten door het internet stromen
Knooppuntobjecten.
[image] Verzendpad van een pakket..UNINDENT
[image] Ontvangstpad van een pakket..UNINDENT

IPv4
Placeholder hoofdstuk

IPv6
Dit hoofdstuk beschrijft de ns-3 De mogelijkheden en beperkingen van het IPv6-model, samen met de bijbehorende
gebruik en voorbeelden.

IPv6 model beschrijving
Het IPv6-model is losjes gebaseerd op de Linux-implementatie; de uitvoering is
niet compleet omdat sommige kenmerken van IPv6 niet van groot belang zijn voor simulatiestudies
Sommige functies van IPv6 zijn eenvoudigweg nog niet in het model opgenomen ns-3.

De basisklasse Ipv6 definieert een generieke API, terwijl de class Ipv6L3-protocol is de werkelijke
klasse die het protocol implementeert. De daadwerkelijke klassen die door de IPv6-stack worden gebruikt, bevinden zich
voornamelijk in de directory src/internet.

De implementatie van IPv6 is opgenomen in de volgende bestanden:

src/internet/model/icmpv6-header.{cc,h}
src/internet/model/icmpv6-l4-protocol.{cc,h}
src/internet/model/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
src/internet/model/ipv6-eindpunt.{cc,h}
src/internet/model/ipv6-end-point-demux.{cc,h}
src/internet/model/ipv6-extensie.{cc,h}
src/internet/model/ipv6-extension-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/model/ipv6-header.{cc,h}
src/internet/model/ipv6-interface.{cc,h}
src/internet/model/ipv6-interface-adres.{cc,h}
src/internet/model/ipv6-l3-protocol.{cc,h}
src/internet/model/ipv6-list-routing.{cc,h}
src/internet/model/ipv6-optie.{cc,h}
src/internet/model/ipv6-option-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-cache.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/internet/model/ipv6-route.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/model/ndisc-cache.{cc,h}
src/netwerk/utils/inet6-socket-adres.{cc,h}
src/netwerk/utils/ipv6-adres.{cc,h}

Ook zijn er enkele helpers betrokken bij IPv6:

src/internet/helper/internet-stack-helper.{cc,h}
src/internet/helper/ipv6-adres-helper.{cc,h}
src/internet/helper/ipv6-interface-container.{cc,h}
src/internet/helper/ipv6-list-routing-helper.{cc,h}
src/internet/helper/ipv6-routing-helper.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

De modelbestanden zijn grofweg onder te verdelen in:

· protocolmodellen (bijvoorbeeld ipv6, ipv6-l3-protocol, icmpv6-l4-protocol, enz.)

· routeringsmodellen (d.w.z. alles met 'routing' in de naam)

· sockets en interfaces (bijvoorbeeld ipv6-raw-socket, ipv6-interface, ipv6-eindpunt, enz.)

· adresgerelateerde zaken

· headers, optieheaders, extensieheaders, enz.

· accessoireklassen (bijv. ndisc-cache)

Gebruik
De volgende beschrijving is gebaseerd op het gebruik van de typische helpers uit de voorbeeldcode.

IPv6 hoeft niet geactiveerd te worden in een knooppunt. het wordt automatisch toegevoegd aan het beschikbare
protocollen zodra de Internet Stack is geïnstalleerd.

Om te niet IPv6 installeren samen met IPv4, het is mogelijk om te gebruiken
ns3::InternetStackHelper methode SetIpv6StackInstall (boel inschakelen) voordat u de installeert
InternetStack in de knooppunten.

Houd er rekening mee dat als u een netwerk wilt hebben dat alleen IPv6 bevat (dat wil zeggen: als u de IPv4-stack niet in een knooppunt wilt installeren),
zou gebruiken ns3::InternetStackHelper methode SetIpv4StackInstall (boel inschakelen) voor de
stapel installatie.

In de volgende code heeft knooppunt 0 bijvoorbeeld zowel IPv4 als IPv6, alleen knooppunt 1
Alleen IPv6 en knooppunt 2 IPv4:

KnooppuntContainer n;
n.Creëer (3);

InternetStackHelper internet;
InternetStackHelper internetV4only;
InternetStackHelper internetV6only;

internetV4only.SetIpv6StackInstall (onwaar);
internetV6only.SetIpv4StackInstall (onwaar);

internet.Installeren (n.Get (0));
internetV6only.Install (n.Get (1));
internetV4only.Install (n.Get (2));

IPv6 adressen toewijzing
Om IPv6 op een netwerk te gebruiken, moet u eerst IPv6-adressen toewijzen.

Elke IPv6-compatibel ns-3 node zal ten minste één NetDevice hebben: de ns3::LoopbackNetDevice.
Het loopback-apparaatadres is :: 1. Alle andere NetDevices zullen een of meer IPv6 hebben
adressen:

· Eén link-local adres: fe80::interface ID, Waar interface ID is afgeleid van de
NetDevice MAC-adres.

· Nul of meer globale adressen, bijvoorbeeld 2001: DB8 :: 1.

Normaal gesproken zal het eerste adres op een interface het link-local adres zijn, met het globale adres
adres(sen) zijn de volgende.

Globale IPv6-adressen kunnen zijn:

· handmatig toegewezen

· automatisch gegenereerd

ns-3 kan beide methoden gebruiken, en het is heel belangrijk om de implicaties ervan te begrijpen
beide.

Handmatig toegewezen IPv6 adressen
Dit is waarschijnlijk de gemakkelijkste en meest gebruikte methode. Als voorbeeld:

Ptr n0 = CreëerObject ();
Ptr n1 = CreëerObject ();
NodeContainer netto (n0, n1);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("IPv6-adressen toewijzen.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Toewijzen (ndc);

Deze methode voegt twee globale IPv6-adressen toe aan de knooppunten. Houd er rekening mee dat, zoals gebruikelijk voor IPv6,
alle knooppunten zullen ook een link-local adres hebben. Meestal is het eerste adres op een
interface zal de link-locale interface zijn, waarbij de globale adres(sen) de volgende zijn
degenen.

Merk op dat de globale adressen zullen worden afgeleid van het MAC-adres. Als gevolg hiervan
verwacht adressen te hebben die vergelijkbaar zijn met 2001:db8::200:ff:fe00:1.

Het is mogelijk om het bovenstaande te herhalen om meer dan één globaal adres aan een knooppunt toe te wijzen.
Echter, vanwege de IPv6AddressHelper singleton aard, moet men eerst alle
adressen van een netwerk en wijzig vervolgens de netwerkbasis (SetBase), doe dan een nieuwe opdracht.

Als alternatief is het mogelijk om een ​​specifiek adres aan een knooppunt toe te wijzen:

Ptr n0 = CreëerObject ();
NodeContainer netto (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("Specifiek een IPv6-adres toewijzen.");
Ipv6AddressHelper ipv6;
Ptr apparaat = ndc.Get (0);
Ptr knooppunt = apparaat->GetNode ();
Ptr ipv6proto = knooppunt->GetObject ();
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (apparaat);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

Automatisch gegenereerd IPv6 adressen
Dit wordt bereikt door te vertrouwen op het RADVD-protocol, geïmplementeerd door de klas Radvd. Op
de tijd dat er geen helper is voor deze toepassing, en het gebruik nogal moeilijk is (zie
voorbeelden/ipv6/radvd.cc).

Bij gebruik van deze methode zullen de knooppunten dynamisch verwerven (dat wil zeggen tijdens de simulatie)
één (of meer) globale adres(sen) volgens de RADVD-configuratie. Deze adressen
zal gebaseerd zijn op het door RADVD aangekondigde voorvoegsel en de EUI-64 van het knooppunt.

Willekeurig gegenereerd IPv6 adressen
Terwijl echte IPv6-knooppunten willekeurig gegenereerde adressen zullen gebruiken om de privacy te beschermen, ns-3 doet
NIET over deze mogelijkheid beschikken. Deze functie wordt tot nu toe niet als interessant beschouwd
simulatie.

duplicaat Adres Opsporing (DAD)
Knooppunten voeren DAD uit (het kan worden uitgeschakeld met behulp van een Icmpv6L4Protocol attribuut). Bij
ontvangen van een DAD, zullen knooppunten er echter niet op reageren. Zoals het is: de DAD-reactie is dus onvolledig
ver. De belangrijkste reden is afhankelijk van de ontbrekende mogelijkheid tot willekeurig gegenereerde adressen. Bovendien,
sinds ns-3 knooppunten zullen zich doorgaans goed gedragen, er mag geen dubbel adres zijn.
Dit kan in de toekomst worden gewijzigd om problemen met de integratie in de echte wereld te voorkomen
simulaties.

gastheer en router gedrag in IPv6 en ns-3
In IPv6 is er een duidelijk onderscheid tussen routers en hosts. Zoals je zou verwachten,
Routers kunnen pakketten van een interface naar een andere interface doorsturen, terwijl hosts wegvallen
pakketten die niet naar hen zijn gericht.

Helaas is doorsturen niet het enige waarop dit onderscheid van invloed is
het doorsturen zelf kan worden verfijnd, bijvoorbeeld om pakketten door te sturen die binnenkomen vanaf een interface
en pakketten van een andere interface laten vallen.

In ns-3 een knooppunt is geconfigureerd als een gastheer standaard. Er zijn twee belangrijke manieren om te veranderen
dit gedrag:

· Gebruik makend van ns3::Ipv6InterfaceContainer SetForwarding(uint32_t i, bool router) WAAR i is de
interface-index in de container.

· Het wijzigen van de ns3::Ipv6 attribuut IPForward.

Beide kunnen tijdens de simulatie worden gebruikt.

Een fijnmazige opstelling kan worden bereikt door gebruik te maken van ns3::Ipv6Interface Doorsturen instellen (boel
vooruit); waarmee het gedrag per interface kan worden gewijzigd.

Houd er rekening mee dat de knooppuntbrede configuratie alleen dient als een handige methode om in/uit te schakelen
the ns3::Ipv6Interface specifieke instelling. Een IPv6Interface toegevoegd aan een knooppunt met forwarding
ingeschakeld, wordt ook ingesteld op doorsturen. Dit is erg belangrijk als een knooppunt dat heeft
interfaces toegevoegd tijdens de simulatie.

Volgens de ns3::Ipv6Interface doorstuurstatus gebeurt het volgende:

· Doorsturen UIT

· Het knooppunt zal NIET reageren op routerverzoeken

· Het knooppunt reageert op Router Advertising

· Het knooppunt verzendt periodiek een Router Solicitation

· Routeringsprotocollen MOETEN pakketten DROPPEN die niet naar het knooppunt zijn gestuurd

· Doorsturen AAN

· Het knooppunt zal reageren op Router Solicitation

· Het knooppunt reageert NIET op Router Advertising

· Het knooppunt verzendt GEEN routerverzoek

· Routeringsprotocollen MOETEN pakketten doorsturen

Het gedrag komt overeen met ip-sysctl.txt (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) met het verschil dat
het is niet mogelijk om het gedrag te onderdrukken met behulp van esoterische instellingen (bijvoorbeeld doorsturen maar
accepteer routeradvertenties, accept_ra=2 of doorsturen, maar stuur routerverzoeken
doorsturen=2).

Denk zorgvuldig na over de implicaties van het doorsturen van pakketten. Een knooppunt zal dit bijvoorbeeld NIET doen
ICMPv6 PACKET_TOO_BIG-berichten verzenden vanaf een interface waarop frowarding is uitgeschakeld. Dit is
volkomen normaal, omdat het Routing-protocol het pakket zal laten vallen voordat het dit probeert
doorsturen.

helpers
De helpers die doorgaans worden gebruikt bij het instellen van IPv6 zijn:

· ns3::InternetStackHelper

· ns3::Ipv6AddressHelper

· ns3::Ipv6InterfaceContainer

Het gebruik is vrijwel identiek aan het overeenkomstige IPv4-geval, bijvoorbeeld:

KnooppuntContainer n;
n.Creëer (4);

NS_LOG_INFO ("IPv6-internetstack maken");
InternetStackHelper internetv6;
internetv6.Installeren (n);

NS_LOG_INFO ("Kanalen maken.");
CsmaHelper csma;
NetDeviceContainer d = csma.Install (n);

NS_LOG_INFO ("Creëer netwerken en wijs IPv6-adressen toe.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Toewijzen (d);

Bovendien is een veel voorkomende taak het inschakelen van doorsturen op een van de knooppunten en het instellen van een
standaardroute ernaartoe in de andere knooppunten, bijvoorbeeld:

iic.SetForwarding (0, waar);
iic.SetDefaultRouteInAllNodes (0);

Hierdoor wordt doorsturen op het knooppunt mogelijk gemaakt 0 en zal een standaardroute instellen
ns3::Ipv6StatischeRouting op alle andere knooppunten. Merk op dat dit dit vereist
Ipv6StaticRouting is aanwezig in de knooppunten.

De IPv6-routeringshelpers stellen de gebruiker in staat specifieke taken op het specifieke uit te voeren
routeringsalgoritme en om de routeringstabellen af ​​te drukken.

Attributen
Veel lessen in de ns-3 IPv6-implementatie bevat attributen. De handigste zijn:

· ns3::Ipv6

· IPForward, boolean, standaard false. Schakel IP-forwarding voor iedereen globaal in of uit
huidige en toekomstige IPv6-apparaten.

· MtuOntdek, boolean, standaard waar. Indien uitgeschakeld, heeft elke interface zijn eigen MTU
ingesteld op 1280 bytes.

· ns3::Ipv6L3-protocol

· StandaardTtl, uint8_t, standaard 64. De TTL-waarde die standaard is ingesteld op alle uitgaande pakketten
op dit knooppunt gegenereerd.

· VerzendIcmpv6Redirect, boolean, standaard waar. Verzend indien nodig de ICMPv6-omleiding.

· ns3::Icmpv6L4Protocol

· DAD, boolean, standaard waar. Voer altijd een DAD-controle (Duplicate Address Detection) uit.

· ns3::NdiscCache

· Onopgeloste wachtrijgrootte, uint32_t, standaard 3. Grootte van de wachtrij voor pakketten in afwachting van een NA
antwoord.

uitgang
De IPv6-stack biedt enkele nuttige traceringsbronnen:

· ns3::Ipv6L3-protocol

· Tx, Verzend IPv6-pakket naar uitgaande interface.

· Rx, Ontvang IPv6-pakket van inkomende interface.

· Val, Laat IPv6-pakket vallen.

· ns3::Ipv6-extensie

· Val, Laat IPv6-pakket vallen.

De nieuwste traceringsbron wordt gegenereerd wanneer een pakket een onbekende optie bevat die zijn pakket blokkeert
processing.

Hou daar rekening mee ns3::NdiscCache kunnen ook pakketten laten vallen, en ze worden niet geregistreerd in een trace
bron (nog). Dit kan enige verwarring veroorzaken in de tellers van verzonden/ontvangen pakketten.

Geavanceerd Gebruik
IPv6 maximaal transmissie eenheid (MTU) en fragmentatie
ns-3 NetDevices definiëren de MTU volgens het L2-gesimuleerde apparaat. IPv6 vereist dat
de minimale MTU is 1280 bytes, dus alle NetDevices moeten dit minimaal ondersteunen
MTU. Dit is de link-MTU.

Om verschillende MTU's in een bron-bestemmingspad te ondersteunen, ns-3 IPv6-model kan
fragmentatie uitvoeren. Dit kan worden geactiveerd door het ontvangen van een pakket dat groter is dan de
link-MTU van de L4-protocollen (UDP, TCP, enz.), of door een ICMPv6 PACKET_TOO_BIG te ontvangen
bericht. Het model bootst RFC 1981 na, met de volgende opmerkelijke uitzonderingen:

· L4-protocollen worden niet geïnformeerd over de pad-MTU-wijziging

· TCP kan de segmentgrootte niet wijzigen volgens de Path-MTU.

Beide beperkingen zullen te zijner tijd worden opgeheven.

De Path-MTU-cache is momenteel gebaseerd op de IPv6-adressen van de bronbestemming. Verder
classificaties (bijv. stroomlabel) zijn mogelijk, maar nog niet geïmplementeerd.

De standaardgeldigheidstijd van Path-MTU is 10 minuten. Nadat het cache-item is verlopen, wordt het
Pad-MTU-informatie wordt verwijderd en het volgende pakket zal (uiteindelijk) een nieuwe ICMPv6 activeren
PACKET_TOO_BIG bericht. Merk op dat 1) dit consistent is met de RFC-specificatie en 2)
L4-protocollen zijn verantwoordelijk voor het opnieuw verzenden van de pakketten.

Voorbeelden
De voorbeelden voor IPv6 staan ​​in de directory voorbeelden/ipv6. Deze voorbeelden richten zich het meest op
interessante IPv6-eigenaardigheden, zoals fragmentatie, omleiding enzovoort.

Bovendien bevinden de meeste TCP- en UDP-voorbeelden zich in voorbeelden/udp, voorbeelden/tcp, enz. hebben een
opdrachtregeloptie om IPv6 te gebruiken in plaats van IPv4.

Troubleshooting
Er zijn slechts een paar valkuilen die u tijdens het gebruik moet vermijden ns-3 IPv6.

Routing loops
Omdat het enige (tot nu toe) routeringsschema dat beschikbaar is voor IPv6 is ns3::Ipv6StatischeRouting,
standaardrouter moet handmatig worden ingesteld. Wanneer er twee of meer routers in een netwerk zijn
(bijvoorbeeld knooppunt A en knooppunt B), vermijd het gebruik van de helperfunctie SetDefaultRouteInAllNodes voor
meer dan één router.

Het gevolg zou zijn dat er een standaardroute naar B in A wordt geïnstalleerd en een standaardroute die wijst
naar A in B, waardoor een lus ontstaat.

Globaal adres lekkage
Onthoud dat adressen in IPv6 dat wel zijn globaal per definitie. Bij gebruik van IPv6 met een
wedijver ns-3 vermogen, koste wat kost het weglekken naar het mondiale internet te voorkomen.
Het is raadzaam om een ​​externe firewall in te stellen om lekkage te voorkomen.

2001:DB8::/32 adressen
IPv6-standaard (RFC 3849) definieert de 2001:DB8::/32 adresklasse voor de documentatie.
Deze handleiding maakt gebruik van deze conventie. De adressen in deze klasse zijn echter alleen bruikbaar in
een document, en routers moeten ze weggooien.

Validatie
De IPv6-protocollen zijn nog niet uitgebreid gevalideerd tegen echte implementaties.
De daadwerkelijke tests omvatten voornamelijk het uitvoeren van controles van de .pcap-traceerbestanden met Wireshark,
en de resultaten zijn positief.

Routing overzicht
ns-3 is bedoeld ter ondersteuning van traditionele routeringsbenaderingen en -protocollen, ondersteuning van poorten van
open source routing-implementaties en faciliteer onderzoek naar onorthodoxe routing
technieken. De algemene routeringsarchitectuur wordt hieronder beschreven in Routing architectuur.
Gebruikers die alleen maar willen lezen hoe ze globale routering voor bekabelde topologieën kunnen configureren, kunnen dat doen
dit artikel lezen Globaal gecentraliseerde routing. Unicast-routeringsprotocollen worden beschreven in unicast
routing. Multicast-routing is gedocumenteerd in multicast routing.

Routing architectuur
[image] Overzicht van routing.UNINDENT

Overzicht of routing toont de algemene routeringsarchitectuur voor IPv4. De belangrijkste objecten zijn
Ipv4L3Protocol, Ipv4RoutingProtocol(s) (een klasse waarnaar alle routering/doorsturen is uitgevoerd
gedelegeerd vanuit Ipv4L3Protocol) en Ipv4Route(s).

Aan Ipv4L3Protocol moet tijdens de simulatie ten minste één Ipv4RoutingProtocol zijn toegevoegd
installatie tijd. Dit wordt expliciet gedaan door Ipv4::SetRoutingProtocol () aan te roepen.

De abstracte basisklasse Ipv4RoutingProtocol () declareert een minimale interface, bestaande uit
van twee methoden: RouteOutput () en RouteInput (). Voor pakketten die uitgaan van
een host, zal het transportprotocol Ipv4 opvragen voor het Ipv4RoutingProtocol-object
interface, en zal een route aanvragen via Ipv4RoutingProtocol::RouteOutput (). Een Ptr naar
Ipv4Route-object wordt geretourneerd. Dit is analoog aan een dst_cache-item in Linux. De
Ipv4Route wordt overgebracht naar het Ipv4L3Protocol om een ​​tweede zoekopdracht daar te voorkomen. Echter,
in sommige gevallen (bijv. Ipv4 raw-sockets) is een rechtstreekse aanroep van RouteOutput() vereist
IPv4L3-protocol.

Voor pakketten die binnenkomend worden ontvangen voor doorzending of bezorging, vinden de volgende stappen plaats.
Ipv4L3Protocol::Receive() roept Ipv4RoutingProtocol::RouteInput() aan. Deze passeert de
pakketeigendom aan het Ipv4RoutingProtocol-object. Er zijn vier terugbelverzoeken gekoppeld
met deze oproep:

· LokaalBezorgd

· UnicastForward

· MulticastForward

· Fout

Het Ipv4RoutingProtocol moet uiteindelijk een van deze callbacks aanroepen voor elk pakket dat dat doet
het neemt de verantwoordelijkheid voor. Dit is eigenlijk hoe het invoerrouteringsproces werkt
Linux.
[afbeelding] Ipv4Routing-specialisatie..UNINDENT

Deze algemene architectuur is ontworpen om verschillende routeringsbenaderingen te ondersteunen, waaronder
(in de toekomst) een Linux-achtige, op beleid gebaseerde routeringsimplementatie, proactief en
routeringsprotocollen op aanvraag en eenvoudige routeringsprotocollen voor de simulatiegebruiker
het gaat niet echt om de routering.

IPv4Routing specialisatie. illustreert hoe meerdere routeringsprotocollen hieruit voortkomen
basisklasse. Een klasse Ipv4ListRouting (implementatieklasse Ipv4ListRoutingImpl) biedt
de bestaande lijstrouteringsaanpak in ns-3. De API is hetzelfde als de basisklasse
Ipv4Routing, behalve de mogelijkheid om meerdere geprioriteerde routeringsprotocollen toe te voegen
(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

De details van deze routeringsprotocollen worden hieronder beschreven in unicast routing. Voor nu,
we zullen eerst beginnen met een basisfunctionaliteit voor unicast-routering die wereldwijd bedoeld is
bouw routeringstabellen op simulatietijd t=0 voor simulatiegebruikers die er niets om geven
dynamische routering.

Globaal gecentraliseerde routing
Mondiale gecentraliseerde routering wordt soms "God"-routering genoemd; het is een bijzonder
implementatie die de simulatietopologie bewandelt en een kortste pad-algoritme uitvoert, en
vult de routeringstabellen van elk knooppunt in. Geen daadwerkelijke protocoloverhead (op de gesimuleerde links)
wordt gemaakt met deze aanpak. Er zijn wel enkele beperkingen:

· Bedraad Alleen: Het is niet bedoeld voor gebruik in draadloze netwerken.

· unicast Alleen: Het doet geen multicast.

· schaalbaarheid: Sommige gebruikers hiervan op grote topologieën (bijvoorbeeld 1000 knooppunten) hebben dat opgemerkt
de huidige implementatie is niet erg schaalbaar. De mondiale gecentraliseerde routering zal dat zijn
in de toekomst aangepast om berekeningen en runtime-prestaties te verminderen.

Momenteel is er sprake van mondiale gecentraliseerde IPv4-unicast-routing, zowel point-to-point als gedeeld
(CSMA)-koppelingen worden ondersteund.

Standaard wordt bij gebruik van de ns-3 helper API en de standaard InternetStackHelper, globaal
routeringsmogelijkheden worden aan het knooppunt toegevoegd, en globale routering wordt ingevoegd als a
routeringsprotocol met een lagere prioriteit dan de statische routes (dat wil zeggen dat gebruikers routes kunnen invoegen
via Ipv4StaticRouting API en ze zullen voorrang hebben op routes gevonden door global
routering).

Globaal unicast Routing API
De openbare API is zeer minimaal. Gebruikersscripts omvatten het volgende:

#include "ns3/internet-module.h"

Als de standaard InternetStackHelper wordt gebruikt, zal er een exemplaar van globale routering zijn
geaggregeerd naar elk knooppunt. Nadat IP-adressen zijn geconfigureerd, wordt de volgende functieaanroep uitgevoerd
zorgt ervoor dat alle knooppunten met een Ipv4-interface doorstuurtabellen ontvangen
automatisch ingevoerd door de GlobalRouteManager:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Opmerking: Een herinnering dat het wifi-NetDevice zal werken, maar geen draadloze effecten heeft
rekening houden. Voor draadloos raden wij de hieronder beschreven dynamische OLSR-routering aan.

Het is mogelijk om deze functie tijdens een simulatie opnieuw aan te roepen met behulp van de
volgende aanvullende publieke functie:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

die de oude tabellen leegmaakt, de knooppunten opvraagt ​​voor nieuwe interface-informatie, en
herbouwt de routes.

Deze planningsoproep zorgt er bijvoorbeeld voor dat de tabellen na 5 seconden opnieuw worden opgebouwd:

Simulator::Schema (Seconden (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

Er zijn twee kenmerken die het gedrag bepalen. De eerste is
Ipv4GlobalRouting::RandomEcmpRouting. Indien ingesteld op true, worden pakketten willekeurig doorgestuurd
multipath-routes met gelijke kosten. Indien ingesteld op false (standaard), is slechts één route consistent
gebruikt. De tweede is Ipv4GlobalRouting::RespondToInterfaceEvents. Indien ingesteld op waar,
de globale routes dynamisch opnieuw berekenen na Interface-meldingsgebeurtenissen (omhoog/omlaag, of
adres toevoegen/verwijderen). Indien ingesteld op false (standaard), kan de routering worden verbroken, tenzij de gebruiker dit handmatig doet
roept RecomputeRoutingTables() aan na dergelijke gebeurtenissen. De standaardwaarde is ingesteld op false om te behouden
nalatenschap ns-3 programma gedrag.

Globaal Routing Implementatie
Deze sectie is bedoeld voor lezers die geïnteresseerd zijn in de manier waarop dit wordt geïmplementeerd. Een singleton
object (GlobalRouteManager) is verantwoordelijk voor het vullen van de statische routes op elk knooppunt,
met behulp van de openbare IPv4-API van dat knooppunt. Het vraagt ​​elk knooppunt in de topologie naar a
"globalRouter"-interface. Indien gevonden, gebruikt het de API van die interface om een ​​"link
state-advertentie (LSA)" voor de router. Link State-advertenties worden gebruikt in OSPF
routing, en we volgen hun opmaak.

Het is belangrijk op te merken dat al deze berekeningen worden uitgevoerd voordat pakketten stromen
in het netwerk. Er worden met name geen overhead- of controlepakketten uitgewisseld
bij gebruik van deze implementatie. In plaats daarvan loopt deze wereldwijde routemanager alleen maar door de lijst met
knooppunten om de benodigde informatie op te bouwen en de routeringstabel van elk knooppunt te configureren.

De GlobalRouteManager vult een linkstatusdatabase met LSA's verzameld uit het geheel
topologie. Vervolgens voert de GlobalRouteManager voor elke router in de topologie de OSPF uit
SPF-berekening (kortste pad eerst) in de database en vult de routeringstabellen in
elk knooppunt.

De quagga (http://www.quagga.net) OSPF-implementatie werd gebruikt als basis voor de
routeringsberekeningslogica. Een voordeel van het volgen van een bestaande OSPF SPF-implementatie is
dat OSPF al linkstatusadvertenties heeft gedefinieerd voor alle gangbare netwerktypen
links:

· point-to-point (seriële verbindingen)

· point-to-multipoint (Frame Relay, ad hoc draadloos)

· niet-uitgezonden meervoudige toegang (ATM)

· uitzending (Ethernet)

Daarom denken we dat het nu eenvoudiger zal zijn om deze andere linktypen in te schakelen
dat het onderliggende OSPF SPF-framework aanwezig is.

Momenteel kunnen we IPv4 point-to-point, genummerde links en gedeelde uitzendingen verwerken
(CSMA)-koppelingen. Multipath met gelijke kosten wordt ook ondersteund. Hoewel typen draadloze verbindingen dat wel zijn
ondersteund door de implementatie. Houd er rekening mee dat vanwege de aard van deze implementatie eventuele
kanaaleffecten worden niet in aanmerking genomen en de routeringstabellen gaan ervan uit dat elk knooppunt
op hetzelfde gedeelde kanaal is bereikbaar vanaf elk ander knooppunt (dat wil zeggen dat het wordt behandeld
zoals een uitgezonden CSMA-link).

De GlobalRouteManager doorloopt eerst de lijst met knooppunten en voegt een GlobalRouter samen
interface voor elk ervan als volgt:

typedef std::vector < Ptr >::iterator Iterator;
for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
{
Ptr knooppunt = *i;
Ptr globalRouter = CreateObject (knooppunt);
knooppunt->AggregateObject (globalRouter);
}

Deze interface wordt later opgevraagd en gebruikt om voor elke interface een Link State Advertising te genereren
router, en deze linkstatusdatabase wordt ingevoerd in de OSPF-berekeningslogica voor het kortste pad.
De IPv4 API wordt uiteindelijk gebruikt om de routes zelf te vullen.

unicast routing
Er zijn momenteel zeven unicast-routeringsprotocollen gedefinieerd voor IPv4 en drie voor IPv6:

· klasse Ipv4StaticRouting (zowel unicast als multicast)

· IPv4 Optimized Link State Routing (OLSR) (een MANET-protocol gedefinieerd in RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (een MANET-protocol gedefinieerd in RFC 3561)

· IPv4 Destination Sequenced Distance Vector (DSDV) (een MANET-protocol)

· IPv4 Dynamic Source Routing (DSR) (een MANET-protocol)

· klasse Ipv4ListRouting (gebruikt om een ​​geprioriteerde lijst met routeringsprotocollen op te slaan)

· klasse Ipv4GlobalRouting (gebruikt om routes op te slaan die zijn berekend door de globale routemanager, indien
dat wordt gebruikt)

· klasse Ipv4NixVectorRouting (een efficiëntere versie van globale routering die opslaat
bronroutes in een pakketkopveld)

· klasse Ipv6ListRouting (gebruikt om een ​​geprioriteerde lijst met routeringsprotocollen op te slaan)

· klasse IPv6StaticRouting

· klasse RipNg - het IPv6 RIPng-protocol (RFC 2080)

In de toekomst zou deze architectuur iemand ook in staat moeten stellen een Linux-achtige te implementeren
implementatie met routing cache, of een modulaire Click-router, maar die vallen buiten de reikwijdte
voor nu.

Ipv[4,6]LijstRouting
In dit gedeelte wordt de huidige standaard beschreven ns-3 Ipv[4,6]Routingprotocol. Typisch,
meerdere routeringsprotocollen worden ondersteund in de gebruikersruimte en coördineren om er één te schrijven
doorstuurtabel in de kernel. Momenteel binnen ns-3, de implementatie maakt dit in plaats daarvan mogelijk
meerdere routeringsprotocollen om hun eigen routeringsstatus en het IP-adres op te bouwen/te behouden
implementatie zal elk van deze routeringsprotocollen opvragen (in een bepaalde volgorde bepaald door
de auteur van de simulatie) totdat er een route is gevonden.

We hebben voor deze aanpak gekozen omdat deze de integratie van ongelijksoortige organisaties beter kan vergemakkelijken
routeringsbenaderingen die moeilijk kunnen zijn om het schrijven naar een enkele tabel te coördineren,
benaderingen waarbij er meer informatie is dan het doel-IP-adres (bijvoorbeeld bronroutering).
gebruikt om de volgende hop te bepalen, en on-demand routing-benaderingen waar pakketten moeten zijn
in de cache opgeslagen.

Ipv[4,6]4ListRouting::AddRoutingProtocol
Klassen Ipv4ListRouting en Ipv6ListRouting bieden een pure virtuele functiedeclaratie
voor de methode waarmee je een routeringsprotocol kunt toevoegen:

void AddRoutingProtocol (Ptr routingProtocol,
int16_t prioriteit);

void AddRoutingProtocol (Ptr routingProtocol,
int16_t prioriteit);

Deze methoden worden respectievelijk per klasse Ipv4ListRoutingImpl en per klasse geïmplementeerd
Ipv6ListRoutingImpl in de internetmodule.

De prioriteitsvariabele hierboven regelt de prioriteit waarin de routeringsprotocollen zich bevinden
ingevoegd. Merk op dat het een ondertekende int is. Standaard in ns-3, de helperklassen wel
een Ipv[4,6]ListRoutingImpl-object instantiëren en daaraan een Ipv[4,6]StaticRoutingImpl toevoegen
object op prioriteit nul. Intern wordt een lijst met Ipv[4,6]RoutingProtocols opgeslagen, en
en de routeringsprotocollen worden elk geraadpleegd in afnemende volgorde van prioriteit
of er een match is gevonden. Daarom, als u wilt dat uw Ipv4RoutingProtocol voorrang heeft
lager dan de statische routing, voeg deze in met een prioriteit kleiner dan 0; bijvoorbeeld:

Ptr myRoutingProto = CreateObject ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

Bij aanroepen van RouteOutput() of RouteInput() doorzoekt het lijstrouteringsobject de lijst
van routeringsprotocollen, in volgorde van prioriteit, totdat er een route is gevonden. Zo'n routeringsprotocol
zal de juiste callback oproepen en er zullen geen verdere routeringsprotocollen worden doorzocht.

Geoptimaliseerde Link Land Routing (OLSR)
Dit IPv4-routeringsprotocol is oorspronkelijk overgenomen van de OLSR-UM-implementatie voor ns-2.
De implementatie is te vinden in de map src/olsr en er is een voorbeeldscript aanwezig
voorbeelden/eenvoudig-punt-tot-punt-olsr.cc.

Normaal gesproken wordt OLSR in een hoofdprogramma ingeschakeld door gebruik te maken van een OlsrHelper-klasse die wordt geïnstalleerd
OLSR naar een Ipv4ListRoutingProtocol-object. De volgende voorbeeldopdrachten worden ingeschakeld
OLSR in een simulatie waarbij deze helperklasse wordt gebruikt samen met enkele andere routeringshelperobjecten.
De instelling van prioriteitswaarde 10, vóór de staticRouting-prioriteit van 0, betekent dat
OLSR zal worden geraadpleegd voor een route vóór de statische routeringstabel van het knooppunt.:

KnooppuntContainer c:
...
// OLSR inschakelen
NS_LOG_INFO ("OLSR-routering inschakelen.");
OlsrHelper olsr;

Ipv4StaticRoutingHelper statischeRouting;

Ipv4ListRoutingHelper-lijst;
lijst.Toevoegen (staticRouting, 0);
lijst.Toevoegen (olsr, 10);

InternetStackHelper internet;
internet.SetRoutingHelper (lijst);
internet.Installeren (c);

Eenmaal geïnstalleerd, kan de OLSR "hoofdinterface" worden ingesteld met de opdracht SetMainInterface().
Als de gebruiker geen hoofdadres opgeeft, selecteert het protocol het eerste primaire IP-adres
adres dat het vindt, waarbij eerst de loopback-interface wordt gestart en dan de volgende
niet-loopback-interface gevonden, in volgorde van Ipv4-interface-index. Het loopback-adres van
127.0.0.1 is niet geselecteerd. Bovendien zijn er een aantal protocolconstanten gedefinieerd in
olsr-routing-protocol.cc.

Olsr wordt gestart op tijdstip nul van de simulatie, gebaseerd op een aanroep van Object::Start() that
roept uiteindelijk OlsrRoutingProtocol::DoStart() aan. Let op: een patch waarmee de gebruiker kan starten
en het protocol op andere momenten stopzetten zou welkom zijn.

Momenteel is OLSR beperkt tot gebruik met een Ipv4ListRouting-object en reageert het niet op
dynamische wijzigingen in het IP-adres van een apparaat of koppelingsmeldingen; dat wil zeggen de topologie
veranderingen zijn het gevolg van verlies/winst van connectiviteit via een draadloos kanaal.

RIPng
Dit IPv6-routeringsprotocol (RFC 2080) is de evolutie van de bekende RIPv1 en RIPv2
(Zie RFC 1058 en RFC 1723) routeringsprotocollen voor IPv4.

Het protocol is heel eenvoudig en is normaal gesproken geschikt voor een plat, eenvoudig netwerk
topologieën.

RIPng is sterk gebaseerd op RIPv1 en RIPv2 en heeft dezelfde doelen
beperkingen. RIP houdt in het bijzonder rekening met elke route met een statistiek gelijk aan of groter dan 16
als onbereikbaar. Als gevolg hiervan moet het maximale aantal hops in het netwerk kleiner zijn
dan 15 (het aantal routers is niet ingesteld). Gebruikers worden aangemoedigd om te lezen RFC 2080 en RFC
1058 om het RIPng-gedrag en de beperkingen volledig te begrijpen.

Routing convergentie
RIPng maakt gebruik van een Distance-Vector-algoritme en routes worden bijgewerkt volgens de
Bellman-Ford-algoritme (ook wel bekend als Ford-Fulkerson-algoritme). Het algoritme heeft een
convergentietijd van O(|V|*|E|) waarbij |V| en |E| zijn het aantal hoekpunten (routers) en
randen (links) respectievelijk. Er moet worden benadrukt dat de convergentietijd het getal is
bestaat uit stappen in het algoritme, en elke stap wordt geactiveerd door een bericht. Sinds geactiveerd
Updates (dwz wanneer een route wordt gewijzigd) hebben een cooldown van 1-5 seconden, de toplogie kan dat wel
enige tijd nodig om te stabiliseren.

Gebruikers moeten zich ervan bewust zijn dat tijdens het bouwen van routeringstabellen de routers kunnen uitvallen
pakketten. Dataverkeer mag pas worden verzonden na een tijd die lang genoeg is om RIPng te laten bouwen
de netwerktopologie. Normaal gesproken zou 80 seconden voldoende moeten zijn om een ​​suboptimale (maar
werken) routeringsinstellingen. Dit omvat de tijd die nodig is om de routes maximaal te verspreiden
verre router (16 hops) met geactiveerde updates.

Als de netwerktopologie wordt gewijzigd (bijvoorbeeld als een verbinding wordt verbroken), kan de hersteltijd hetzelfde zijn
vrij hoog, en het kan zelfs hoger zijn dan de initiële insteltijd. Bovendien: het netwerk
topologieherstel wordt beïnvloed door de Split Horizoning-strategie.

Het voorbeeld voorbeelden/routing/ripng-simple-network.cc toont zowel de netwerkinstellingen als
netwerkherstelfasen.

Split Horizonnen
Split Horizon is een strategie om routeringsinstabiliteit te voorkomen. Er zijn drie opties mogelijk:

· Geen gesplitste horizon

· Gespleten horizon

· Gif achteruit

In het eerste geval worden routes op alle interfaces van de router geadverteerd. In de seconde
In dat geval zullen routers geen route adverteren op de interface waarvan deze is geleerd.
Poison Reverse zal de route adverteren op de interface waarvan deze is geleerd, maar
met een metriek van 16 (oneindig). Voor een volledige analyse van de drie technieken, zie RFC
1058, sectie 2.2.

Het voorbeeld ripng-simple-network.cc is gebaseerd op de netwerktopologie beschreven in de RFC,
maar het vertoont niet het daar beschreven effect.

De reden zijn de geactiveerde updates, samen met het feit dat wanneer een router
Als een route ongeldig wordt verklaard, wordt de onbereikbaarheid van de route onmiddellijk doorgegeven
het voorkomen van de meeste problemen die in de RFC worden beschreven.

Bij complexe toplogieën is het echter nog steeds mogelijk dat er sprake is van route-instabiliteitsverschijnselen
vergelijkbaar met degene die wordt beschreven in de RFC na een verbindingsfout. Als gevolg hiervan zijn alle
overwegingen over Split Horizon blijven geldig.

Standaard wegen
Het RIPng-protocol moet zijn geïnstalleerd Slechts op routers. Als gevolg hiervan zullen de knooppunten het niet weten
wat is de standaardrouter.

Om deze beperking te omzeilen, moeten gebruikers de standaardroute handmatig installeren (bijv.
door gebruik te maken van Ipv6StaticRouting), of door RADVd te gebruiken. RADVd is beschikbaar in ns-3 in de
Applicaties-module, en dit wordt sterk aanbevolen.

Protocol parameters en opties
De RIPng ns-3 implementatie maakt het mogelijk om alle timers die aan de route zijn gekoppeld, te wijzigen
updates en routeslevensduur.

Bovendien kunnen gebruikers de interfacestatistieken per knooppunt wijzigen.

Het type Split Horizoning (om terugpropagatie van routes te voorkomen) kan worden geselecteerd op a
per knooppunt, waarbij de keuzes "geen gesplitste horizon", "gesplitste horizon" en "gif" zijn
omgekeerd". Zie RFC 2080 voor meer details, en RFC 1058 voor een volledige discussie over de
gesplitste horizonstrategieën.

Beperkingen
Er is geen ondersteuning voor de Next Hop-optie (RFC 2080, paragraaf 2.1.1). De volgende hop
Deze optie is handig wanneer RIPng niet op alle routers in een netwerk wordt uitgevoerd. Steun
want deze optie kan in de toekomst worden overwogen.

Er is geen ondersteuning voor aggregatie van CIDR-voorvoegsels. Als gevolg hiervan worden zowel routeringstabellen als
routeadvertenties kunnen groter zijn dan nodig. Voorvoegselaggregatie kan worden toegevoegd in de
toekomst.

multicast routing
De volgende functie wordt gebruikt om een ​​statische multicastroute aan een knooppunt toe te voegen:

komen te vervallen
Ipv4StaticRouting::AddMulticastRoute (oorsprong Ipv4Address,
IPv4Address-groep,
uint32_t inputInterface,
std::vector outputInterfaces);

Een multicastroute moet een oorsprongs-IP-adres, een multicastgroep en een ingang specificeren
netwerkinterface-index als voorwaarden en een vector voor de uitvoernetwerkinterface bieden
indices waarover pakketten die aan de voorwaarden voldoen, worden verzonden.

Er zijn doorgaans twee hoofdtypen multicastroutes: routes van de eerste soort worden gebruikt
tijdens het doorsturen. Alle voorwaarden moeten expliciet worden vermeld. De tweede soort
routes worden gebruikt om pakketten van een lokaal knooppunt te halen. Het verschil zit in de invoer
koppel. Voor routes voor doorsturen wordt altijd een expliciete invoerinterface gespecificeerd.
Routes buiten een knooppunt zullen de invoerinterface altijd instellen op een jokerteken dat is opgegeven door de
index Ipv4RoutingProtocol::IF_INDEX_ANY.

Voor routes buiten een lokaal knooppunt kunnen wildcards worden gebruikt in de origin- en multicast-groep
adressen. Het jokerteken dat wordt gebruikt voor Ipv4Adressen is het adres dat wordt geretourneerd
Ipv4Address::GetAny () -- meestal "0.0.0.0". Door gebruik te maken van een jokerteken kan men specificeren
standaardgedrag in verschillende mate.

U kunt bijvoorbeeld het herkomstadres een jokerteken maken, maar de multicastgroep verlaten
specific maakt het mogelijk (in het geval van een knooppunt met meerdere interfaces) om verschillende te creëren
routes met verschillende uitvoerinterfaces voor elke multicastgroep.

Als de oorsprong- en multicast-adressen jokertekens zijn gemaakt, hebt u in wezen een
standaard multicast-adres dat kan doorsturen naar meerdere interfaces. Vergelijk dit met de
feitelijk standaard multicast-adres dat beperkt is tot het specificeren van een enkele uitvoerinterface
voor compatibiliteit met bestaande functionaliteit in andere systemen.

Een ander commando stelt de standaard multicast-route in:

komen te vervallen
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t outputInterface);

Dit is het multicast-equivalent van de unicast-versie SetDefaultRoute. Wij vertellen het
routeringssysteem wat te doen in het geval dat een specifieke route naar een multicastbestemming gaat
groep wordt niet gevonden. Het systeem stuurt in de hoop pakketten door via de opgegeven interface
dat "iets daarbuiten" beter weet hoe het pakket moet worden gerouteerd. Deze methode wordt alleen gebruikt
bij het aanvankelijk verzenden van pakketten vanaf een host. De standaard multicastroute wordt niet geraadpleegd
tijdens het doorsturen - in dat geval moeten exacte routes worden opgegeven met AddMulticastRoute.

Omdat we in principe pakketten sturen naar een entiteit waarvan we denken dat die beter weet wat te doen,
we besteden geen aandacht aan ‘subtiliteiten’ zoals het herkomstadres, en we maken ons daar ook geen zorgen over
meerdere interfaces doorsturen. Als de standaard multicastroute is ingesteld, wordt deze geretourneerd
als de geselecteerde route van LookupStatic, ongeacht de oorsprong of multicast-groep
er is geen andere specifieke route gevonden.

Tenslotte zijn er nog een aantal extra functies voorzien om multicast op te halen en te verwijderen
trajecten:

uint32_t GetNMulticastRoutes (ongeldig) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (ongeldig) const;

bool RemoveMulticastRoute (oorsprong Ipv4Address,
IPv4Address-groep,
uint32_t inputInterface);

void RemoveMulticastRoute (uint32_t index);

TCP modellen in ns-3
In dit hoofdstuk worden de TCP-modellen beschreven die beschikbaar zijn in ns-3.

Algemeen ondersteuning voor TCP
ns-3 is geschreven om meerdere TCP-implementaties te ondersteunen. De implementaties erven van
een paar algemene headerklassen in de src/netwerk directory, zodat de gebruikerscode kan worden uitgewisseld
implementaties met minimale wijzigingen in de scripts.

Er zijn twee belangrijke abstracte basisklassen:

· klas TCPSocket: Dit is gedefinieerd in src/internet/model/tcp-socket.{cc,h}. Deze klas
bestaat voor het hosten van TcpSocket-kenmerken die op verschillende manieren kunnen worden hergebruikt
implementaties. Het attribuut bijvoorbeeld InitialCwnd kan worden gebruikt voor elk van de
implementaties die voortkomen uit klasse TCPSocket.

· klas TcpSocketFactory: Dit wordt gebruikt door de laag-4-protocolinstantie om TCP te maken
stopcontacten van het juiste type.

Er zijn momenteel drie implementaties van TCP beschikbaar ns-3.

· een native geïmplementeerd TCP voor ns-3

· ondersteuning voor de Netwerk Simulatie Wieg (NSC)

· ondersteuning voor Direct Code Executie (DCE)

Er moet ook worden vermeld dat verschillende manieren om virtuele machines te combineren met ns-3
stelt ook een aantal aanvullende TCP-implementaties beschikbaar, maar die vallen buiten het bereik ervan
dit hoofdstuk.

ns-3 TCP
Tot de release van ns-3.10, ns-3 bevatte een poort van het TCP-model van GTNetS. Deze
de implementatie werd substantieel herschreven door Adriam Tam voor ns-3.10. Het model is een volledige
TCP, in die zin dat het bidirectioneel is en probeert het opzetten en sluiten van de verbinding te modelleren
logica.

De implementatie van TCP is opgenomen in de volgende bestanden:

src/internet/model/tcp-header.{cc,h}
src/internet/model/tcp-l4-protocol.{cc,h}
src/internet/model/tcp-socket-factory-impl.{cc,h}
src/internet/model/tcp-socket-base.{cc,h}
src/internet/model/tcp-tx-buffer.{cc,h}
src/internet/model/tcp-rx-buffer.{cc,h}
src/internet/model/tcp-rfc793.{cc,h}
src/internet/model/tcp-tahoe.{cc,h}
src/internet/model/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/internet/model/tcp-newreno.{cc,h}
src/internet/model/rtt-schatter.{cc,h}
src/netwerk/model/volgnummer.{cc,h}

Verschillende varianten van TCP-congestiecontrole worden ondersteund door de gemeenschappelijke basis in een subklasse te plaatsen
klasse TcpSocketBase. Er worden verschillende varianten ondersteund, waaronder RFC 793 (geen drukte
controle), Tahoe, Reno, Westwood, Westwood+ en NewReno. Standaard wordt NewReno gebruikt. Zien
het gedeelte Gebruik van dit document voor informatie over het wijzigen van de standaard TCP-variant die wordt gebruikt
simulatie.

Gebruik
In veel gevallen wordt het gebruik van TCP ingesteld op de applicatielaag door de ns-3
toepassing welk soort socketfabriek moet worden gebruikt.

Met behulp van de helperfuncties die zijn gedefinieerd in src/applicaties/helper en src/netwerk/helper, hier
is hoe je een TCP-ontvanger zou maken:

// Maak een pakket-sink op de ster-hub om deze pakketten te ontvangen
uint16_t poort = 50000;
Adres sinkLocalAddress(InetSocketAddress (Ipv4Address::GetAny (), poort));
PacketSinkHelper sinkHelper ("ns3::TcpSocketFactory", sinkLocalAddress);
ApplicationContainer sinkApp = sinkHelper.Install (serverNode);
sinkApp.Start (Seconden (1.0));
sinkApp.Stop (Seconden (10.0));

Op dezelfde manier configureert het onderstaande fragment de OnOffApplication-verkeersbron om TCP te gebruiken:

// Maak de OnOff-applicaties om TCP naar de server te verzenden
OnOffHelper clientHelper ("ns3::TcpSocketFactory", Adres ());

De zorgvuldige lezer zal hierboven opmerken dat we de TypeId van een abstracte basis hebben gespecificeerd
klasse TcpSocketFactory. Hoe vertelt het script ns-3 dat het de inboorling wil ns-3 TCP
versus een andere? Welnu, wanneer internetstacks aan het knooppunt worden toegevoegd, wordt de standaard TCP
implementatie die is geaggregeerd naar het knooppunt is de ns-3 TCP. Dit kan worden overschreven als
we laten hieronder zien wanneer u Network Simulation Cradle gebruikt. Dus standaard, bij gebruik van de ns-3
helper-API, de TCP die wordt samengevoegd tot knooppunten met een internetstack, is de native ns-3
TCP.

Om het gedrag van TCP te configureren, worden een aantal parameters geëxporteerd via de ns-3
attribuutsysteem. Deze zijn gedocumenteerd in de zuurstofoxy
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> voor de les TCPSocket. Voor
De maximale segmentgrootte is bijvoorbeeld een instelbaar attribuut.

Om het standaard sockettype in te stellen voordat er internetstack-gerelateerde objecten worden gemaakt, één
kan de volgende verklaring bovenaan het simulatieprogramma plaatsen:

Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

Voor gebruikers die een verwijzing naar de daadwerkelijke socket willen hebben (zodat socketbewerkingen zoals
Bind(), socketopties instellen, etc. kunnen per socket worden gedaan), Tcp-sockets kunnen
worden gemaakt met behulp van de Socket::CreateSocket() methode. De TypeId doorgegeven aan
CreateSocket() moet van het type zijn ns3::SocketFactory, dus het configureren van de onderliggende socket
type moet worden gedaan door het attribuut te verdraaien dat is gekoppeld aan het onderliggende TcpL4Protocol
voorwerp. De eenvoudigste manier om dit te bereiken is via de attribuutconfiguratie
systeem. In het onderstaande voorbeeld wordt de knooppuntcontainer "n0n1" benaderd om de nulde te verkrijgen
element, en er wordt een socket gemaakt op dit knooppunt:

// Maak en bind de socket...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));
Ptr lokaleSocket =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Hierboven wordt de jokerteken "*" voor knooppuntnummer doorgegeven aan het attribuutconfiguratiesysteem,
zodat alle toekomstige sockets op alle knooppunten worden ingesteld op Tahoe, en niet alleen op knooppunt 'n0n1.Get (0)'.
Als je het wilt beperken tot alleen het opgegeven knooppunt, zou je zoiets moeten doen als:

// Maak en bind de socket...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream nodeId;
knooppuntId << n0n1.Get (0) -> GetId ();
std::string specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (specificNode, TypeIdValue (tid));
Ptr lokaleSocket =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Zodra een TCP-socket is gemaakt, wil men de conventionele socketlogica volgen en geen van beide
connect() en send() (voor een TCP-client) of bind(), luister() en accept() (voor een TCP
server). Zie Sockets-API's voor een overzicht van hoe sockets worden gebruikt ns-3.

Validatie
Verschillende TCP-validatietestresultaten zijn te vinden in de wiki pagina dit beschrijft
implementatie.

Actueel beperkingen
· SACK wordt niet ondersteund

Netwerk Simulatie Wieg
De Netwerk Simulatie Wieg (NSC) is een raamwerk voor het verpakken van echte netwerkcode
in simulatoren, waardoor simulatie van gedrag in de echte wereld tegen weinig extra kosten mogelijk wordt. Dit
het werk is gevalideerd door situaties met behulp van een testnetwerk met hetzelfde te vergelijken
situaties in de simulator. Tot nu toe is gebleken dat de NSC in staat is te produceren
uiterst nauwkeurige resultaten. NSC ondersteunt vier real-world stacks: FreeBSD, OpenBSD, lwIP
en Linux. Er is nadruk gelegd op het niet handmatig wijzigen van de netwerkstacks. Niet
er is één regel code gewijzigd in de netwerkprotocolimplementaties van een van deze
de bovenstaande vier stapels. Er is echter een aangepaste C-parser gebouwd om programmatisch te veranderen
broncode.

NSC is eerder geporteerd naar ns-2 en OMNeT++, en werd toegevoegd ns-3 september
2008 (ns-3.2-versie). In dit gedeelte worden de ns-3 poort van NSC en hoe u deze kunt gebruiken.

Tot op zekere hoogte is NSC vervangen door de Linux-kernelondersteuning daarin Direct Code
Uitvoering (DCE). NSC is echter nog steeds beschikbaar via het bake-build-systeem. NSC
ondersteunt Linux-kernels 2.6.18 en 2.6.26, maar nieuwere versies van de kernel zijn niet beschikbaar
geporteerd.

Voorwaarden
Momenteel is NSC getest en gebleken dat het werkt op deze platforms: Linux i386 en Linux
x86-64. NSC ondersteunt geen powerpc. Gebruik op FreeBSD of OS X wordt niet ondersteund (hoewel het
kan werken).

Voor het bouwen van NSC zijn de pakketten flex en bison nodig.

configureren en Downloaden
Vanaf ns-3.17 of later moet NSC afzonderlijk worden gedownload vanuit zijn eigen repository,
of downloaden bij gebruik van de bakken bouw system of ns-3.

Voor ns-3.17 of latere releases moet men bij gebruik van bake NSC configureren als onderdeel van een
"allinone"-configuratie, zoals:

$ cd bakken
$ python bake.py configure -e ns-allinone-3.19
$ python bake.py downloaden
$ python bake.py build

In plaats van een vrijgegeven versie kan men de ns-3 ontwikkelversie gebruiken door dit op te geven
"ns-3-allinone" naar de configuratiestap hierboven.

NSC kan ook worden gedownload van haar Download website Mercurial gebruiken:

$ hg-kloon https://secure.wand.net.nz/mercurial/nsc

Vóór de release van ns-3.17 was NSC opgenomen in de allinone tarball en de uitgebrachte
versie hoefde niet afzonderlijk te worden gedownload.

Gebouw en valideren
NSC kan worden gebouwd als onderdeel van het bakproces; als alternatief kan men NSC bouwen door
zichzelf met behulp van zijn bouwsysteem; bijvoorbeeld:

$ cd nsc-dev
$ python scons.py

Zodra NSC handmatig of via het baksysteem is gebouwd, schakelt u over naar de ns-3
source-map en probeer de volgende configuratie uit te voeren:

$./waf configureren

Als NSC eerder is gebouwd en gevonden door waf, ziet u het volgende:

Netwerksimulatiehouder: ingeschakeld

Als NSC niet is gevonden, ziet u:

Network Simulation Cradle: niet ingeschakeld (NSC niet gevonden (zie optie --with-nsc))

In dit geval moet u het relatieve of absolute pad doorgeven aan de NSC-bibliotheken met de
"--with-nsc" configuratieoptie; bijv

$ ./waf configure --with-nsc=/pad/naar/mijn/nsc/directory

Voor ns-3 releases vóór de ns-3.17-release, met behulp van de bouwen.py script in ns-3-allinone
directory, wordt NSC standaard gebouwd, tenzij het platform dit niet ondersteunt. Naar
schakel het expliciet uit tijdens het bouwen ns-3, type:

$ ./waf configure --enable-examples --enable-tests --disable-nsc

Als Waf NSC detecteert, dan bouwen ns-3 met NSC wordt op dezelfde manier uitgevoerd met waf als
zonder het. Eenmaal ns-3 is gebouwd, probeer dan de volgende testsuite uit te voeren:

$ ./test.py -s ns3-tcp-interoperabiliteit

Als NSC met succes is gebouwd, zou de volgende test in de resultaten moeten verschijnen:

PASS TestSuite ns3-tcp-interoperabiliteit

Dit bevestigt dat NSC klaar is voor gebruik.

Gebruik
Er zijn een paar voorbeeldbestanden. Poging:

$ ./waf --voer tcp-nsc-zoo uit
$ ./waf --voer tcp-nsc-lfn uit

Deze voorbeelden zullen er een paar opleveren .pkap bestanden in uw map, die kunnen worden onderzocht door
tcpdump of wireshark.

Laten we eens kijken naar de voorbeelden/tcp/tcp-nsc-zoo.cc bestand voor typisch gebruik. Hoe doet het
verschillen van het gebruik van native ns-3 TCP? Er is één hoofdconfiguratieregel bij gebruik van NSC
en ns-3 helper-API, die moet worden ingesteld:

InternetStackHelper internetStack;

internetStack.SetNscStack ("liblinux2.6.26.so");
// hierdoor worden knooppunten 0 en 1 overgeschakeld naar NSC's Linux 2.6.26-stack.
internetStack.Install (n.Verkrijg(0));
internetStack.Install (n.Verkrijg(1));

De belangrijkste lijn is de SetNscStack. Dit vertelt de InternetStack-helper om te aggregeren
exemplaren van NSC TCP in plaats van native ns-3 TCP naar de overige knooppunten. Het is belangrijk
dat deze functie wordt aangeroepen vaardigheden bellen met de Installeren() functie, zoals hierboven weergegeven.

Welke stapels zijn beschikbaar voor gebruik? Momenteel ligt de focus op Linux 2.6.18 en Linux
2.6.26 stapels voor ns-3. Om te zien welke stapels er zijn gebouwd, kunt u de volgende zoekopdracht uitvoeren
commando bij de ns-3 map op het hoogste niveau:

$ find nsc -naam "*.so" -type f
nsc/linux-2.6.18/liblinux2.6.18.so
nsc/linux-2.6.26/liblinux2.6.26.so

Dit vertelt ons dat we de bibliotheeknaam liblinux2.6.18.so of
liblinux2.6.26.so naar de bovenstaande configuratiestap.

Opstapelen configuratie
NSC TCP deelt dezelfde configuratiekenmerken die gemeenschappelijk zijn voor TCP-sockets, zoals
hierboven beschreven en gedocumenteerd in zuurstofoxy

Bovendien exporteert NSC TCP veel configuratievariabelen naar het ns-3 attributen
systeem, via een sysctl-achtige interface. In de voorbeelden/tcp/tcp-nsc-zoo je kunt het bijvoorbeeld zien
de volgende configuratie:

// hierdoor worden TCP SACK, wscale en tijdstempels op knooppunt 1 uitgeschakeld (de attributen
vertegenwoordigen sysctl-waarden).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
Tekenreekswaarde ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
Tekenreekswaarde ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
Tekenreekswaarde ("0"));

Deze aanvullende configuratievariabelen zijn niet beschikbaar voor native ns-3 TCP.

Houd er ook rekening mee dat standaardwaarden voor TCP-kenmerken in ns-3 TCP kan verschillen van nsc TCP
implementatie. Specifiek binnen ns-3:

1. TCP-standaard MSS is 536

2. Aantal TCP-vertraagde bevestigingen is 2

Daarom moet u bij het maken van vergelijkingen tussen resultaten verkregen met behulp van nsc en ns-3 TCP, zorg
moet worden genomen om ervoor te zorgen dat deze waarden correct worden ingesteld. Zien
/examples/tcp/tcp-nsc-comparision.cc voor een voorbeeld.

NSC API
In deze subsectie wordt de API beschreven waaraan NSC presenteert ns-3 of een andere simulator. NSC
biedt zijn API aan in de vorm van een aantal klassen die zijn gedefinieerd in
sim/sim_interface.h in de nsc-directory.

· INetStack INetStack bevat de 'low level'-bewerkingen voor het besturingssysteemnetwerk
stack, bijvoorbeeld in- en uitvoerfuncties van en naar de netwerkstack (beschouw dit als de
'netwerkstuurprogramma-interface'. Er zijn ook functies om nieuwe TCP- of UDP-sockets te maken.

· ISendCallback Dit wordt door NSC aangeroepen wanneer een pakket naar het netwerk moet worden verzonden.
Deze simulator zou deze callback moeten gebruiken om het pakket opnieuw in de simulator te injecteren
de daadwerkelijke gegevens kunnen worden afgeleverd/gerouteerd naar hun bestemming, waar ze uiteindelijk zullen zijn
overgedragen aan Receiver() (en uiteindelijk terug naar de NSC-instantie van de ontvanger via
INetStack->if_receive() ).

· INetStreamSocket Dit is de structuur die een bepaald verbindingseindpunt definieert (file
beschrijving). Het bevat methoden om op dit eindpunt te werken, bijvoorbeeld verbinden, ontkoppelen,
accepteren, luisteren, data verzenden/data lezen, ...

· IOnderbrekenTerugbellen Dit bevat de wakeup callback, die wanneer dan ook door NSC wordt aangeroepen
er gebeurt iets interessants. Beschouw wakeup() als een vervanging van het operating
systemen wakeup-functie: wanneer het besturingssysteem een ​​proces zou wekken dat dat wel heeft gedaan
gewacht tot een bewerking is voltooid (bijvoorbeeld de TCP-handshake tijdens
connect()), roept NSC de wakeup() callback aan zodat de simulator de status kan controleren
veranderingen in de verbindingseindpunten.

ns-3 uitvoering
De ns-3 implementatie maakt gebruik van de bovenstaande NSC API en wordt als volgt geïmplementeerd.

De drie belangrijkste onderdelen zijn:

· ns3::NscTcpL4Protocol: een subklasse van Ipv4L4Protocol (en twee nsc-klassen: ISendCallback
en IInterruptCallback)

· ns3::NscTcpSocketImpl: een subklasse van TcpSocket

· ns3::NscTcpSocketFactoryImpl: een fabriek om nieuwe NSC-sockets te maken

src/internet/model/nsc-tcp-l4-protocol is de hoofdklasse. Bij initialisatie laadt het een
nsc-netwerkstack die moet worden gebruikt (via dlopen()). Elke instantie van deze klasse kan een andere gebruiken
stapel. De te gebruiken stapel (=gedeelde bibliotheek) wordt ingesteld met behulp van de SetNscLibrary()-methode (op this
tijd wordt het indirect aangeroepen via de internetstackhelper). Vervolgens wordt de nsc-stack ingesteld
dienovereenkomstig (timers enz.). De functie NscTcpL4Protocol::Receive() overhandigt het pakket
ontvangt (moet een compleet tcp/ip-pakket zijn) naar de nsc-stack voor verdere verwerking. Naar
pakketten kan verzenden, implementeert deze klasse de nsc send_callback-methode. Deze methode
wordt aangeroepen door nsc wanneer de nsc-stack een pakket naar het netwerk wil sturen. Zijn
argumenten zijn een onbewerkte buffer, die een compleet TCP/IP-pakket bevat, en een lengtewaarde. Dit
methode moet daarom de ruwe gegevens omzetten naar een Ptr bruikbaar door ns-3. Om te
vermijd verschillende ipv4-headerproblemen, de nsc ip-header is niet inbegrepen. In plaats daarvan wordt de tcp
header en de daadwerkelijke payload worden in de Ptr geplaatst , hierna is het pakket
doorgegeven aan laag 3 voor het verzenden van het pakket (er is geen verdere speciale behandeling nodig).
in het verzendcodepad).

Deze klas roept ns3::NscTcpSocketImpl zowel van de nsc wakeup() callback als van de
Ontvangstpad (om ervoor te zorgen dat mogelijk in de wachtrij geplaatste gegevens zijn gepland voor verzending).

src/internet/model/nsc-tcp-socket-impl implementeert de nsc-socketinterface. Elke instantie
heeft zijn eigen nscTcpSocket. Gegevens die Send() zijn, worden via
m_nscTcpSocket->send_data(). (en niet voor nsc-tcp-l4, dit is het grootste verschil vergeleken
naar ns-3 TCP). De klasse plaatst ook gegevens in de wachtrij die Send() zijn vóór de onderliggende waarde
descriptor heeft de status GEVESTIGD. Deze klasse wordt aangeroepen vanuit nsc-tcp-l4
klasse, wanneer de nsc-tcp-l4 wakeup() callback wordt aangeroepen door nsc. nsc-tcp-socket-impl dan
controleert de huidige verbindingsstatus (SYN_SENT, ESTABLISHED, LISTEN...) en planningen
passende callbacks indien nodig, bijvoorbeeld een LISTEN-socket plant Accept in om te zien of er een nieuwe is
verbinding moet worden geaccepteerd, een GEVESTIGDE socket plant alle openstaande gegevens voor schrijven,
een lees-callback plannen, enz.

Merk op dat ns3::NscTcpSocketImpl heeft geen directe interactie met nsc-tcp: in plaats daarvan zijn data dat wel
doorverwezen naar nsc. nsc-tcp roept de nsc-tcp-sockets van een knooppunt aan wanneer de wakeup-callback is
ingeroepen door nsc.

Beperkingen
· NSC werkt alleen op knooppunten met één interface; proberen het uit te voeren op een knooppunt met meerdere interfaces
zal een programmafout veroorzaken.

· Cygwin en OS X PPC worden niet ondersteund; OS X Intel wordt niet ondersteund, maar werkt mogelijk wel

· De niet-Linux-stacks van NSC worden niet ondersteund ns-3

· Niet alle socket-API-callbacks worden ondersteund

Voor meer informatie, zie dit wiki pagina.

Codeel queue uitvoering in ns-3
Dit hoofdstuk beschrijft de CoDel ([Nic12], [Nic14]) wachtrij-implementatie in ns-3.

Ontwikkeld door Kathleen Nichols en Van Jacobson als oplossing voor de bufferbloat [Buf14]
Probleem: CoDel (Controlled Delay Management) is een wachtrijdiscipline die gebruikmaakt van pakketten
verblijftijd (tijd in wachtrij) om beslissingen te nemen over pakketdroppings.

Model Beschrijving
De broncode voor het CoDel-model bevindt zich in de directory src/internet/model en
bestaat uit 2 bestanden codel-queue.h en codel-queue.cc het definiëren van een CoDelQueue-klasse en a
helper CoDelTimestampTag-klasse. De code is geporteerd naar ns-3 door Andrew McGregor gebaseerd op
Linux-kernelcode geïmplementeerd door Dave Täht en Eric Dumazet.

· klas CoDelQueue: Deze klasse implementeert het belangrijkste CoDel-algoritme:

· CoDelQueue::DoEnqueue (): Deze routine tagt een pakket met de huidige tijd ervoor
door het in de wachtrij te duwen. De tijdstempeltag wordt gebruikt door CoDelQueue::DoDequeue() naar
bereken de verblijftijd van het pakket. Als de wachtrij vol is bij aankomst van het pakket, is dit het geval
routine zal het pakket laten vallen en het aantal druppels registreren als gevolg van overloop in de wachtrij,
waarin wordt opgeslagen m_dropOverLimit.

· CoDelQueue::ShouldDrop (): Deze routine is CoDelQueue::DoDequeue()'s helperroutine
dat bepaalt of een pakket al dan niet moet worden gedropt op basis van de verblijftijd.
Als de verblijftijd boven gaat m_doel en blijft tenminste continu boven
m_interval, keert de routine terug waar wat aangeeft dat het OK is om het pakket te laten vallen.
Anders keert het terug vals.

· CoDelQueue::DoDequeue (): Deze routine voert de daadwerkelijke pakketafgifte uit op basis van
CoDelQueue::ShouldDrop ()'s retourwaarde en plant de volgende drop.

· klas CoDelTimestampTag: Deze klasse implementeert de tijdstempeltagging voor een pakket. Dit
tag wordt gebruikt om de verblijftijd van het pakket te berekenen (het verschil tussen de tijd waarop het pakket verblijft).
pakket uit de wachtrij wordt gehaald en het tijdstip waarop het in de wachtrij wordt geplaatst).

Er zijn 2 vestigingen CoDelQueue::DoDequeue ():

1. Als de wachtrij zich momenteel in de status 'dropping' bevindt, wat betekent dat de verblijftijd is verstreken
boven gebleven m_doel voor meer dan m_interval, bepaalt de routine of dit oké is
verlaat de drop-status of het is tijd voor de volgende drop. Wanneer CoDelQueue::ShouldDrop ()
Retourneren vals, kan de wachtrij uit de drop-status komen (set m_dropping naar vals).
Anders laat de wachtrij voortdurend pakketten vallen en wordt de tijd voor de volgende aflevering bijgewerkt
(m_dropNext) totdat aan een van de volgende voorwaarden is voldaan:

1. De wachtrij is leeg, waarna de wachtrij de drop-status verlaat en wordt afgesloten
CoDelQueue::ShouldDrop () routine;

2. CoDelQueue::ShouldDrop () Retourneren vals (wat betekent dat de verblijfstijd hieronder gaat
m_doel) waarop de wachtrij de drop-status verlaat;

3. Het is nog geen tijd voor de volgende druppel (m_dropNext is minder dan de huidige tijd).
waarbij de wachtrij wacht op de volgende pakketuitwachting om de toestand opnieuw te controleren.

2. Als de wachtrij zich niet in de drop-status bevindt, gaat de routine in de drop-status en
laat het eerste pakket vallen als CoDelQueue::ShouldDrop () Retourneren waar (wat het verblijf betekent
de tijd is boven gegaan m_doel voor ten minste m_interval voor de eerste keer of het is weg
weer hierboven nadat de wachtrij de drop-status heeft verlaten).

Referenties
[Nic12]

K. Nichols en V. Jacobson, Controlling Queue Delay, ACM Queue, Vol. 10 nr. 5, mei 2012.
Online beschikbaar op http://queue.acm.org/detail.cfm?id=2209336.

[Nic14]

K. Nichols en V. Jacobson, Internet-Draft: gecontroleerde vertraging Actief wachtrijbeheer,
Maart 2014. Online beschikbaar op
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Buf14]
Bufferbloat.net. Online verkrijgbaar op http://www.bufferbloat.net/.

Attributen
De belangrijkste kenmerken van de CoDelQueue-klasse zijn onder meer:

· Mode: CoDel-bedrijfsmodus (BYTES, PACKETS of ILLEGAL). De standaardmodus is BYTES.

· MaxPakketten: Het maximale aantal pakketten dat de wachtrij kan bevatten. De standaardwaarde is
DEFAULT_CODEL_LIMIT, wat 1000 pakketten is.

· MaxBytes: Het maximale aantal bytes dat de wachtrij kan bevatten. De standaardwaarde is 1500 *
DEFAULT_CODEL_LIMIT, wat 1500 * 1000 bytes is.

· MinBytes: De minbytes-parameter van het CoDel-algoritme. De standaardwaarde is 1500 bytes.

· Interval: Het minimale schuifraam. De standaardwaarde is 100 ms.

· Doel: Het CoDel-algoritme richt zich op wachtrijvertraging. De standaardwaarde is 5 ms.

Voorbeelden
Het eerste voorbeeld is codel-vs-droptail-basic-test.cc in src/internet/voorbeelden. naar
voer het bestand uit (de eerste aanroep hieronder toont de beschikbare opdrachtregelopties):

$ ./waf --run "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --run "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

De verwachte uitvoer van de vorige opdrachten bestaat uit twee bestanden: codel.pcap file en
cwndCoDel.tr (ASCII trace)-bestand Het .pcap-bestand kan worden geanalyseerd met behulp van wireshark of
tcptrace:

$ tcptrace -l -r -n -W codel.pcap

Het tweede voorbeeld is codel-vs-droptail-asymmetrisch.cc in src/internet/voorbeelden.
Dit voorbeeld is bedoeld om een ​​typisch implementatiescenario voor een kabelmodem te modelleren. Om de
file:

$ ./waf --run "codel-vs-droptail-assymetrische --PrintHelp"
$ ./waf --voer codel-vs-droptail-asymmetrisch uit

De verwachte uitvoer van de vorige opdrachten is zes pcap-bestanden:

· codel-vs-droptail-asymmetrisch-CoDel-server-lan.pcap

· codel-vs-droptail-asymmetrische-CoDel-router-wan.pcap

· codel-vs-droptail-asymmetrisch-CoDel-router-lan.pcap

· codel-vs-droptail-asymmetrisch-CoDel-cmts-wan.pcap

· codel-vs-droptail-asymmetrisch-CoDel-cmts-lan.pcap

· codel-vs-droptail-asymmetrische-CoDel-host-lan.pcap

Eén attribuutbestand:

· codel-vs-droptail-asymmetrisch-CoDel.attr

Vijf ASCII-traceerbestanden:

· codel-vs-droptail-asymmetrisch-CoDel-drop.tr

· codel-vs-droptail-asymmetrische-CoDel-drop-state.tr

· codel-vs-droptail-asymmetrisch-CoDel-sojourn.tr

· codel-vs-droptail-asymmetrisch-CoDel-length.tr

· codel-vs-droptail-asymmetrisch-CoDel-cwnd.tr

Validatie
Het CoDel-model wordt getest met behulp van CoDelQueueTestSuite klasse gedefinieerd in
src/internet/test/codel-queue-test-suite.cc. De suite bevat 5 testcases:

· Test 1: De eerste test controleert de enqueue/dequeue zonder druppels en zorgt ervoor dat dit gebeurt
CoDel-attributen kunnen correct worden ingesteld.

· Test 2: Bij de tweede test wordt de wachtrij gecontroleerd op druppels als gevolg van overflow in de wachtrij.

· Test 3: De derde test controleert de rekenkunde van NewtonStep() aan de hand van de expliciete poort van Linux
uitvoering

· Test 4: De vierde test controleert ControlLaw() aan de hand van de expliciete poort van Linux
uitvoering

· Test 5: De vijfde test controleert de enqueue/dequeue met druppels volgens CoDel
algoritme

De testsuite kan worden uitgevoerd met behulp van de volgende opdrachten:

$ ./waf configure --enable-examples --enable-tests
$ ./waf bouwen
$ ./test.py -s codel-wachtrij

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-wachtrij"
Pagina-einde

LAGE WAARDERING WIRELESS PERSOONLIJKE GEBIED NETWERK (LR-WPAN)

Dit hoofdstuk beschrijft de implementatie van ns-3-modellen voor draadloze netwerken met lage snelheid
personal area network (LR-WPAN) zoals gespecificeerd door IEEE-standaard 802.15.4 (2006).

Model Beschrijving
De broncode voor de lr-wpan-module bevindt zich in de directory src/lr-wpan.

Design
Het modelontwerp volgt vanuit architectonisch oogpunt nauwgezet de standaard.
[afbeelding] Architectuur en reikwijdte van lr-wpan-modellen.UNINDENT

De grijze gebieden in de figuur (aangepast uit figuur 3 van IEEE Std. 802.15.4-2006) tonen de
reikwijdte van het model.

Het Spectrum NetDevice van Nicola Baldo vormt de basis voor de implementatie.

De implementatie is ook van plan om te lenen van de ns-2-modellen ontwikkeld door Zheng en Lee
te verwijzen in de toekomst.

APIs
De API's volgen nauwgezet de standaard, aangepast voor ns-3 naamgevingsconventies en idiomen. De
API's zijn georganiseerd rond het concept van serviceprimitieven, zoals hieronder wordt weergegeven
figuur aangepast van figuur 14 van IEEE Std. 802.15.4-2006.
[afbeelding] Serviceprimitieven.UNINDENT

De API's zijn georganiseerd rond vier conceptuele services en service access points (SAP):

· MAC-dataservice (MCPS)

· MAC-beheerservice (MLME)

· PHY-dataservice (PD)

· PHY-beheerservice (PLME)

Over het algemeen zijn primitieven als volgt gestandaardiseerd (bijv. Sec 7.1.1.1.1 van IEEE
802.15.4-2006)::

MCPS-DATA.verzoek (
SrcAddrModus,
DstAddrModus,
DstPANId,
DstAddr,
msduLengte,
msdu,
msduHandle,
TxOpties,
Beveiligings niveau,
KeyIdModus,
Sleutelbron,
SleutelIndex
)

Dit verwijst naar ns-3-klassen en -methoden zoals::

struct McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

komen te vervallen
LrWpanMac::McpsDataRequest (McpsDataRequestParameters-parameters)
{
...
}

MAC-adres
De MAC implementeert momenteel de unslotted CSMA/CA-variant, zonder beaconing. Momenteel
er is geen ondersteuning voor coördinatoren en de bijbehorende API’s.

De geïmplementeerde MAC is vergelijkbaar met Contiki's NullMAC, dwz een MAC zonder slaapfuncties.
Er wordt aangenomen dat de radio altijd actief is (ontvangen of zenden), of volledig gesloten is
omlaag. Frame-ontvangst wordt niet uitgeschakeld tijdens het uitvoeren van de CCA.

De belangrijkste ondersteunde API is de API voor gegevensoverdracht (McpsDataRequest/Indication/Confirm).
CSMA/CA volgens Stc 802.15.4-2006, sectie 7.5.1.4 wordt ondersteund. Frame-ontvangst en
afwijzing volgens Std 802.15.4-2006, sectie 7.5.6.2 wordt ondersteund, inclusief
erkenningen. Alleen korte adressering volledig geïmplementeerd. Er zijn verschillende sporenbronnen
ondersteund, en traceerbronnen kunnen aan sinks worden gekoppeld.

PHY
De componenten van de fysieke laag bestaan ​​uit een Phy-model, een foutenpercentagemodel en een verlies
model. Het foutenpercentagemodel modelleert momenteel het foutenpercentage voor IEEE 802.15.4 2.4 GHz
AWGN-kanaal voor OQPSK; de modelbeschrijving is te vinden in IEEE Std 802.15.4-2006,
sectie E.4.1.7. Het Phy-model is gebaseerd op SpectrumPhy en volgt de specificaties
beschreven in sectie 6 van IEEE Std 802.15.4-2006. Het modelleert de PHY-servicespecificaties,
PPDU-formaten, PHY-constanten en PIB-attributen. Het ondersteunt momenteel alleen het verzenden
spectrale vermogensdichtheidsmasker gespecificeerd in 2.4 GHz per sectie 6.5.3.1. De geluidskracht
dichtheid gaat uit van gelijkmatig verdeelde thermische ruis over de frequentiebanden. Het verlies
model kan alle bestaande eenvoudige (niet-spectrumfysische) verliesmodellen volledig benutten. Het Phy-model
maakt gebruik van het bestaande single spectrum channel-model. De fysieke laag is gemodelleerd op pakketbasis
niveau, dat wil zeggen dat er geen preambule/SFD-detectie wordt uitgevoerd. Er wordt gestart met pakketontvangst
het eerste bit van de preambule (die niet is gemodelleerd), als de SNR meer dan -5 dB is, zie
IEEE Std 802.15.4-2006, bijlage E, figuur E.2. De ontvangst van het pakket eindigt daarna
het pakket werd volledig verzonden. Andere pakketten die tijdens de ontvangst binnenkomen, zullen optellen
aan de interferentie/ruis.

Momenteel is de ontvangergevoeligheid ingesteld op een vaste waarde van -106.58 dBm. Dit
komt overeen met een pakketfoutpercentage van 1% voor referentiepakketten van 20 bytes voor dit signaal
vermogen, volgens IEEE Std 802.15.4-2006, sectie 6.1.7. In de toekomst zullen wij voorzien
ondersteuning voor het wijzigen van de gevoeligheid voor verschillende waarden.
[image] Pakketfoutpercentage versus signaalvermogen.UNINDENT

Netapparaat
Hoewel verwacht wordt dat andere technologieprofielen (zoals 6LoWPAN en ZigBee) dat wel zullen doen
hun eigen NetDevice-klassen schrijven, wordt er een basis LrWpanNetDevice meegeleverd, die inkapselt
de algemene handelingen van het maken van een generiek LrWpan-apparaat en het aan elkaar koppelen van dingen.

strekking en Beperkingen
Toekomstige versies van dit document zullen een PICS-proforma bevatten die vergelijkbaar is met bijlage D van
IEEE 802.15.4-2006. De huidige nadruk ligt op de unslotted-modus van 802.15.4-werking
voor gebruik in Zigbee, en de reikwijdte is beperkt tot het inschakelen van een enkele modus (CSMA/CA) met basic
mogelijkheden voor gegevensoverdracht. Associatie met PAN-coördinatoren wordt nog niet ondersteund
het gebruik van uitgebreide adressering. Interferentie wordt gemodelleerd als AWGN, maar dit is momenteel niet het geval
grondig getest.

De NetDevice Tx-wachtrij is niet beperkt, dat wil zeggen dat pakketten nooit worden verwijderd vanwege een wachtrij
vol raken. Ze kunnen worden verwijderd als gevolg van overmatige transmissiepogingen of kanaaltoegang
mislukking.

Referenties
· Specificaties voor draadloos mediumtoegangscontrole (MAC) en fysieke laag (PHY).
Low-Rate Wireless Personal Area Networks (WPAN's), IEEE Computer Society, IEEE Std
802.15.4-2006, 8 september 2006.

·

J. Zheng en Myung J. Lee, "Een uitgebreid prestatieonderzoek van IEEE 802.15.4", Sensor
Network Operations, IEEE Press, Wiley Interscience, Hoofdstuk 4, pp. 218-237, 2006.

Gebruik
inschakelen lr-wpan
Toevoegen lr-wpan naar de lijst met modules gebouwd met ns-3.

Helper
De helper heeft het patroon van andere apparaathelpers. Met name tracering (ASCII en
pcap) wordt op dezelfde manier ingeschakeld en alle lr-wpan logcomponenten worden ingeschakeld
op dezelfde manier. Het gebruik van de helper wordt geïllustreerd in voorbeelden/lr-wpan-data.cc. Voor asci
tracering, de zend- en ontvangstsporen zijn gekoppeld aan de Mac-laag.

Het standaard propagatieverliesmodel dat aan het kanaal wordt toegevoegd, wanneer deze helper wordt gebruikt, is de
LogDistancePropagationLossModel met standaardparameters.

Voorbeelden
De volgende voorbeelden zijn geschreven, die te vinden zijn in src/lr-wpan/voorbeelden/:

· lr-wpan-data.cc: Een eenvoudig voorbeeld van end-to-end gegevensoverdracht.

· lr-wpan-fout-afstand-plot.cc: Een voorbeeld om variaties van het pakketsucces in kaart te brengen
verhouding als functie van de afstand.

· lr-wpan-error-model-plot.cc: Een voorbeeld om de fy te testen.

· lr-wpan-packet-print.cc: Een voorbeeld om de MAC-headervelden af ​​te drukken.

· lr-wpan-phy-test.cc: Een voorbeeld om de fy te testen.

In het bijzonder maakt de module een zeer vereenvoudigd end-to-end scenario voor gegevensoverdracht mogelijk,
geïmplementeerd in lr-wpan-data.cc. De figuur toont een reeks gebeurtenissen die worden geactiveerd
wanneer de MAC een DataRequest ontvangt van de hogere laag. Het roept een Clear Channel op
Assessment (CCA) van de PHY, en indien succesvol, stuurt het frame naar de PHY waar het zich bevindt
wordt via het kanaal verzonden en resulteert in een DataIndication op het peer-knooppunt.
[image] Gegevensvoorbeeld voor eenvoudige LR-WPAN-gegevensoverdracht end-to-end.UNINDENT

Het voorbeeld lr-wpan-fout-afstand-plot.cc plot de pakketsuccesratio (PSR) als a
functie van de afstand, met behulp van het standaard LogDistance-propagatieverliesmodel en de
802.15.4-foutmodel. Het kanaal (standaard 11), pakketgrootte (standaard 20 bytes) en
het zendvermogen (standaard 0 dBm) kan worden gevarieerd via opdrachtregelargumenten. Het programma
voert een bestand uit met de naam 802.15.4-psr-afstand.plt. Het laden van dit bestand in gnuplot levert a
filet 802.15.4-psr-afstand.eps, die kan worden geconverteerd naar pdf of andere formaten. De
standaarduitvoer wordt hieronder weergegeven.
[image] Standaarduitvoer van het programma lr-wpan-fout-afstand-plot.cc.ONINDENT

Tests
De volgende tests zijn geschreven, deze zijn te vinden in src/lr-wpan/tests/:

· lr-wpan-ack-test.cc: Controleer of bevestigingen worden gebruikt en uitgegeven in de
correcte volgorde.

· lr-wpan-collision-test.cc: Test de correcte ontvangst van pakketten met interferentie en
botsingen.

· lr-wpan-error-model-test.cc: Controleer of het foutmodel voorspelbare waarden geeft.

· lr-wpan-packet-test.cc: Test de 802.15.4 MAC-header/trailer-klassen

· lr-wpan-pd-plme-sap-test.cc: Test de PLME en PD SAP volgens IEEE 802.15.4

· lr-wpan-spectrumwaarde-helper-test.cc: Test dat de conversie tussen stroom
(uitgedrukt als een scalaire grootheid) en spectraal vermogen, en weer terug, valt binnen een straal van 25%
tolerantie over het hele bereik van mogelijke kanalen en ingangsvermogens.

Validatie
Het model is niet gevalideerd met echte hardware. Het foutenmodel is geweest
gevalideerd op basis van de gegevens in IEEE Std 802.15.4-2006, sectie E.4.1.7 (Figuur E.2). De
MAC-gedrag (CSMA-backoff) is handmatig gevalideerd aan de hand van verwacht gedrag. De
Onderstaande grafiek is een voorbeeld van de validatie van het foutmodel en kan worden gereproduceerd door het uit te voeren
lr-wpan-error-model-plot.cc:
[image] Standaarduitvoer van het programma lr-wpan-error-model-plot.cc.ONINDENT

LTE MODULE

Design Documentatie
Overzicht
Een overzicht van het LTE-EPC-simulatiemodel is weergegeven in de figuur Overzicht of the
LTE-EPC simulatie model. Er zijn twee hoofdcomponenten:

· het LTE-model. Dit model bevat de LTE Radio Protocol-stack (RRC, PDCP, RLC, MAC,
PHY). Deze entiteiten bevinden zich volledig binnen de UE- en de eNB-knooppunten.

· het EPC-model. Dit model omvat kernnetwerkinterfaces, protocollen en entiteiten.
Deze entiteiten en protocollen bevinden zich gedeeltelijk in de SGW-, PGW- en MME-knooppunten
binnen de eNB-knooppunten.
[afbeelding] Overzicht van het LTE-EPC-simulatiemodel.UNINDENT

Design criteria
LTE Model
Het LTE-model is ontworpen om de evaluatie van de volgende aspecten van LTE te ondersteunen
systemen:

· Beheer van radiobronnen

· QoS-bewuste pakketplanning

· Intercelinterferentiecoördinatie

· Dynamische spectrumtoegang

Om LTE-systemen te modelleren tot een detailniveau dat voldoende is om een ​​correctie mogelijk te maken
evaluatie van de bovengenoemde aspecten, zijn de volgende eisen gesteld
beschouwd:

1. Op radioniveau moet de granulariteit van het model minimaal die van het model zijn
Bronblok (RB). In feite is dit de fundamentele eenheid die wordt gebruikt voor hulpbronnen
toewijzing. Zonder dit minimale granulariteitsniveau is het niet mogelijk om te modelleren
nauwkeurige pakketplanning en interferentie tussen cellen. De reden is dat, sinds
pakketplanning gebeurt per RB, een eNB verzendt mogelijk alleen op een subset
van alle beschikbare RB's, en interfereert dus alleen met andere eNB's op die RB's waar
het is aan het zenden. Merk op dat deze vereiste de adoptie van een systeem uitsluit
simulatiebenadering op niveau, die de toewijzing van middelen alleen evalueert op het niveau van de
granulariteit van de vaststelling van de oproep/drager.

2. De simulator moet worden opgeschaald naar tientallen eNB's en honderden gebruikersapparatuur (UE's).
Dit sluit het gebruik uit van een linkniveausimulator, dat wil zeggen een simulator waarvan de radio
interface is gemodelleerd met een granulariteit tot op symboolniveau. Dit komt omdat
Als u een symboolniveaumodel heeft, is het noodzakelijk om alle PHY-laagsignalen te implementeren
verwerking, waarvan de enorme rekencomplexiteit de simulatie ernstig beperkt. In werkelijkheid,
Simulators op linkniveau zijn normaal gesproken beperkt tot een enkele eNB en een of enkele UE's.

3. Binnen de simulatie moet het mogelijk zijn om verschillende cellen zo te configureren
ze gebruiken verschillende draaggolffrequenties en systeembandbreedtes. De bandbreedte die wordt gebruikt door
verschillende cellen moeten elkaar kunnen overlappen, om het dynamische spectrum te ondersteunen
licentieoplossingen zoals beschreven in [Ofcom2600MHz] en [RealWireless].
De berekening van interferentie zou dit geval op passende wijze moeten behandelen.

4. Representatiever zijn voor de LTE-standaard en er zo dicht mogelijk bij aansluiten
voor implementaties in de echte wereld zou de simulator de MAC Scheduler API moeten ondersteunen
gepubliceerd door het FemtoForum [FFAPI]. Deze interface zal naar verwachting worden gebruikt door
femtocell-fabrikanten voor de implementatie van planning en radiobronnen
Managementalgoritmen (RRM). Door ondersteuning voor deze interface te introduceren in de
simulator maken we het voor leveranciers en operators van LTE-apparatuur mogelijk om te testen in een
simulatieomgeving precies dezelfde algoritmen die in een echte omgeving zouden worden ingezet
systeem.

5. Het LTE-simulatiemodel moet een eigen implementatie bevatten van de API die is gedefinieerd in
[FFAPI]. Noch binaire noch datastructuurcompatibiliteit met leverancierspecifiek
implementaties van dezelfde interface worden verwacht; vandaar een compatibiliteitslaag
moet worden tussengevoegd wanneer een leverancierspecifieke MAC-planner moet worden gebruikt met de
simulator. Deze vereiste is nodig om de simulator onafhankelijk te laten zijn
van leverancierspecifieke implementaties van deze interfacespecificatie. We noteren dat
[FFAPI] is alleen een logische specificatie en de implementatie ervan (bijv. vertaling
voor een specifieke programmeertaal) wordt overgelaten aan de leveranciers.

6. Het model moet worden gebruikt om de transmissie van IP-pakketten door het hoger onderwijs te simuleren
lagen. In dit verband wordt er rekening mee gehouden dat bij LTE de Scheduling en
Radio Resource Management werkt niet rechtstreeks met IP-pakketten, maar eerder met RLC
PDU's, die worden verkregen door segmentatie en aaneenschakeling van IP-pakketten, uitgevoerd door de
RLC-entiteiten. Daarom moeten deze functionaliteiten van de RLC-laag worden gemodelleerd
nauwkeurig.

EPC Model
Het hoofddoel van het EPC-model is het verschaffen van middelen voor de simulatie van end-to-end
IP-connectiviteit via het LTE-model. Om dit doel te bereiken ondersteunt het de onderlinge verbinding van
meerdere UE's met internet, via een radiotoegangsnetwerk van meerdere eNB's die zijn aangesloten op een
enkel SGW/PGW-knooppunt, zoals weergegeven in figuur Overzicht of the LTE-EPC simulatie model.

Voor het EPC-model zijn de volgende ontwerpkeuzes gemaakt:

1. Het enige ondersteunde Packet Data Network (PDN)-type is IPv4.

2. De functionele entiteiten SGW en PGW worden geïmplementeerd binnen één enkel knooppunt
vandaar het SGW/PGW-knooppunt genoemd.

3. De scenario's met inter-SGW-mobiliteit zijn niet van belang. Eén SGW/PGW dus
node zal aanwezig zijn in alle simulatiescenario's

4. Een vereiste aan het EPC-model is dat hiermee end-to-end kan worden gesimuleerd
prestaties van realistische toepassingen. Daarom zou het mogelijk moeten zijn om met de
EPC-model voor elke reguliere ns-3-applicatie die bovenop TCP of UDP werkt.

5. Een andere vereiste is de mogelijkheid om netwerktopologieën te simuleren met de
aanwezigheid van meerdere eNB's, waarvan sommige mogelijk zijn uitgerust met een backhaul
verbinding met beperkte mogelijkheden. Om dergelijke scenario's te simuleren, moet de gebruiker
datavlakprotocollen die worden gebruikt tussen de eNB's en de SGW/PGW moeten worden gemodelleerd
nauwkeurig.

6. Het zou voor één enkele UE mogelijk moeten zijn om verschillende applicaties met verschillende applicaties te gebruiken
QoS-profielen. Daarom moeten voor elke UE meerdere EPS-dragers worden ondersteund. Dit
omvat de noodzakelijke classificatie van TCP/UDP-verkeer over IP gedaan op de UE in
de uplink en bij de PGW in de downlink.

7. De focus van het EPC-model ligt voornamelijk op het EPC-datavlak. Het nauwkeurig modelleren van
het EPC-controlevlak is voorlopig geen vereiste; vandaar de
noodzakelijke interacties op het besturingsvlak kunnen op een vereenvoudigde manier worden gemodelleerd door
gebruikmakend van directe interactie tussen de verschillende simulatieobjecten via de
voorzien van hulpobjecten.

8. De focus van het EPC-model ligt op simulaties van actieve gebruikers in de ECM-verbonden modus.
Daarom is alle functionaliteit die alleen relevant is voor de ECM-inactieve modus (in het bijzonder
update van het trackinggebied en paging) worden helemaal niet gemodelleerd.

9. Het model moet de mogelijkheid bieden om een ​​op X2 gebaseerde overdracht tussen twee uit te voeren
eNB's.

Architectuur
LTE Model
UE architectuur
De architectuur van het LTE-radioprotocolstapelmodel van de UE wordt weergegeven in de
cijfers LTE radio protocol stack architectuur voor the UE on the gegevens vliegtuig en LTE radio
protocol stack architectuur voor the UE on the onder controle te houden vliegtuig die respectievelijk benadrukken
het datavlak en het besturingsvlak.
[image] LTE-radioprotocolstackarchitectuur voor de UE op het datavlak.UNINDENT
[image] LTE-radioprotocolstackarchitectuur voor de UE op het besturingsvlak.UNINDENT

De architectuur van het PHY/kanaalmodel van de UE wordt weergegeven in de figuur PHY en
kanaal model architectuur voor the UE.
[afbeelding] PHY en kanaalmodelarchitectuur voor de UE.UNINDENT

eNB architectuur
De architectuur van het LTE-radioprotocolstackmodel van de eNB wordt weergegeven in de
cijfers LTE radio protocol stack architectuur voor the eNB on the gegevens vliegtuig en LTE radio
protocol stack architectuur voor the eNB on the onder controle te houden vliegtuig die respectievelijk benadrukken
het datavlak en het besturingsvlak.
[image] LTE-radioprotocolstackarchitectuur voor de eNB op het datavlak.UNINDENT
[image] LTE-radioprotocolstackarchitectuur voor de eNB op het besturingsvlak.UNINDENT

De architectuur van het PHY/kanaalmodel van de eNB wordt in figuur weergegeven PHY en
kanaal model architectuur voor the eNB.
[afbeelding] PHY en kanaalmodelarchitectuur voor de eNB.UNINDENT

EPC Model
EPC gegevens vliegtuig
In figuur LTE-EPC gegevens vliegtuig protocol stackvertegenwoordigen we de end-to-end LTE-EPC-gegevens
plane protocolstack zoals deze in de simulator is gemodelleerd. Uit de figuur blijkt het
dat de grootste vereenvoudiging die in het datavlakmodel is geïntroduceerd, de opname van de
SGW- en PGW-functionaliteit binnen één enkel SGW/PGW-knooppunt, waardoor de S5 niet meer nodig is
of S8-interfaces gespecificeerd door 3GPP. Aan de andere kant, voor zowel de S1-U-protocolstack
en de LTE-radioprotocolstapel zijn alle door 3GPP gespecificeerde protocollagen aanwezig.
[afbeelding] LTE-EPC dataplane protocolstack.UNINDENT

EPC onder controle te houden vliegtuig
De architectuur van de implementatie van het besturingsvlakmodel wordt weergegeven in de figuur EPC
onder controle te houden model. De besturingsinterfaces die expliciet worden gemodelleerd zijn de S1-AP, de X2-AP
en de S11-interfaces.

We merken op dat de S1-AP- en de S11-interfaces op een vereenvoudigde manier zijn gemodelleerd
door slechts één paar interfaceklassen te gebruiken om de interactie tussen entiteiten te modelleren
bevinden zich op verschillende knooppunten (de eNB en de MME voor de S1-AP-interface, en de MME en
de SGW voor de S11-interface). In de praktijk betekent dit dat de primitieven hiervan
interfaces worden toegewezen aan een directe functieaanroep tussen de twee objecten. Op de andere
In de eerste plaats wordt de X2-AP-interface gemodelleerd met behulp van protocolgegevenseenheden die via een X2-link worden verzonden
(gemodelleerd als een point-to-point-link); om deze reden is het X2-AP-interfacemodel meer
realistisch.
[afbeelding] EPC-controlemodel.UNINDENT

Kanaal en Voortplanting
Voor kanaalmodelleringsdoeleinden gebruikt de LTE-module de Spectrumkanaal interface voorzien
door de spectrummodule. Op het moment van schrijven zijn er twee implementaties van een dergelijke interface
zijn beschikbaar: SingleModelSpectrumkanaal en MultiModelSpectrumkanaalen de LTE
module vereist het gebruik van de MultiModelSpectrumkanaal om goed te kunnen werken. Dit
is vanwege de noodzaak om verschillende frequentie- en bandbreedteconfiguraties te ondersteunen. Alle
de voortplantingsmodellen die worden ondersteund door MultiModelSpectrumkanaal kan gebruikt worden binnen de
LTE-module.

Te gebruiken of the Gebouwen model met LTE
Het aanbevolen propagatiemodel dat met de LTE-module moet worden gebruikt, is het model dat wordt geleverd door
de module Gebouwen, die in feite specifiek met LTE is ontworpen (hoewel dat mogelijk is).
ook gebruikt met andere draadloze technologieën). Raadpleeg de documentatie van de
Gebouwenmodule voor algemene informatie over het voortplantingsmodel dat het biedt.

In deze sectie zullen we enkele overwegingen belichten die specifiek van toepassing zijn wanneer de
De gebouwenmodule wordt samen met de LTE-module gebruikt.

De naamgevingsconventie die in het volgende wordt gebruikt, is:

· Gebruikersapparatuur: UE

· Macrobasisstation: MBS

· Basisstation voor kleine cellen (bijv. pico/femtocell): SC

De LTE-module houdt alleen rekening met FDD en implementeert downlink- en uplink-propagatie
afzonderlijk. Als gevolg hiervan worden de volgende padverliesberekeningen uitgevoerd

· MBS <-> UE (binnen en buiten)

· SC (binnen en buiten) <-> UE (binnen en buiten)

Het LTE-model biedt niet de volgende padverliesberekeningen:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

Het Gebouwenmodel kent het werkelijke type knooppunt niet; dat wil zeggen, het is zich er niet van bewust
of een zenderknooppunt een UE, een MBS of een SC is. Integendeel, het Gebouwenmodel geeft er alleen maar om
over de positie van het knooppunt: of het binnen en buiten is, en wat is de z-as
respect voor het dakniveau. Als gevolg hiervan is het voor een eNB-knooppunt dat buiten wordt geplaatst en
op een z-coördinaat boven het dakniveau zullen de propagatiemodellen typisch zijn voor MBS
gebruikt door de module Gebouwen. Omgekeerd geldt dit voor een eNB die buiten maar onder de grond wordt geplaatst
Op het dak of binnen zullen de voortplantingsmodellen die typisch zijn voor pico- en femtocellen worden gebruikt.

Voor communicatie waarbij ten minste één binnenknooppunt betrokken is, de overeenkomstige muurdoorvoer
verliezen worden berekend door het Gebouwenmodel. Dit omvat de volgende gebruiksscenario's:

· MBS <-> binnen UE

· buiten SC <-> binnen UE

· binnen SC <-> binnen UE

· binnen SC <-> buiten UE

Raadpleeg de documentatie van de module Gebouwen voor details over de daadwerkelijke modellen
in elk geval gebruikt.

Fading Model
De LTE-module bevat een op traces gebaseerd fading-model dat is afgeleid van het model dat is ontwikkeld tijdens
de GSoC 2010 [Piro2011]. Het belangrijkste kenmerk van dit model is het feit dat de
De evaluatie van de vervaging tijdens de looptijd van de simulatie is gebaseerd op per berekende sporen. Dit is
gedaan om de computationele complexiteit van de simulator te beperken. Aan de andere kant is het nodig
enorme structuren voor het opslaan van de sporen; daarom een ​​afweging tussen het aantal
mogelijke parameters en de geheugenbezetting moeten worden gevonden. De belangrijkste zijn:

· gebruikerssnelheid: relatieve snelheid tussen gebruikers (beïnvloedt de Doppler-frequentie, die in
beurten beïnvloeden de tijdsvariantie-eigenschap van de fading)

· aantal tikken (en relatieve kracht): aantal beschouwde meervoudige paden, welke
beïnvloedt de frequentie-eigenschap van de fading.

· tijdgranulariteit van het spoor: bemonsteringstijd van het spoor.

· frequentiegranulariteit van het spoor: aantal waarden in frequentie dat moet worden geëvalueerd.

· lengte van het spoor: idealiter zo groot als de simulatietijd, kan worden verminderd door venstering
mechanisme.

· aantal gebruikers: aantal onafhankelijke traces dat moet worden gebruikt (idealiter één trace per
gebruiker).

Met betrekking tot het wiskundige kanaalvoortplantingsmodel stellen wij het model voor dat wordt gegeven door
the Rayleighchan functie van Matlab, omdat het een goed geaccepteerd kanaal biedt
modellering zowel in tijd- als frequentiedomein. Voor meer informatie, de lezer is
verwezen naar [wiskunde].

De simulator biedt een matlab-script
(src/lte/model/fading-traces/fading-trace-generator.m) voor het genereren van sporen op basis van de
formaat dat door de simulator wordt gebruikt. In detail het kanaalobject gemaakt met de Rayleighchan
functie wordt gebruikt voor het filteren van een discreet tijdsimpulssignaal om de
kanaal impulsrespons. Het filteren wordt herhaald voor verschillende TTI's, waardoor er opbrengst ontstaat
daaropvolgende tijdsgecorreleerde kanaalreacties (één per TTI). De kanaalreactie is dan
verwerkt met de pwelch functie voor het verkrijgen van de spectrale vermogensdichtheidswaarden, die
worden vervolgens opgeslagen in een bestand met het juiste formaat dat compatibel is met het simulatormodel.

Omdat het aantal variabelen behoorlijk hoog is, kunt u sporen genereren door ze allemaal te overwegen
zou een groot aantal sporen van enorme omvang kunnen produceren. In dit verband hebben wij nagedacht over de
volgende aannames van de parameters gebaseerd op de 3GPP-fadingvoortplantingsomstandigheden
(zie bijlage B.2 van [TS36104]):

· gebruikerssnelheid: doorgaans worden slechts enkele discrete waarden in aanmerking genomen, dwz:

· 0 en 3 km/u voor voetgangersscenario's

· 30 en 60 km/u voor voertuigscenario's

· 0, 3, 30 en 60 voor stedelijke scenario's

· kanaaltaps: er wordt normaal gesproken slechts rekening gehouden met een beperkt aantal sets kanaaltaps,
Er worden bijvoorbeeld drie modellen genoemd in bijlage B.2 van [TS36104].

· tijdgranulariteit: we hebben één fadingwaarde per TTI nodig, dwz elke 1 ms (aangezien dit de
granulariteit in de tijd van het ns-3 LTE PHY-model).

· frequentiegranulariteit: we hebben één fadingwaarde per RB nodig (wat de frequentie is).
granulariteit van het spectrummodel dat wordt gebruikt door het ns-3 LTE-model).

· lengte van het spoor: de simulator omvat het geïmplementeerde venstermechanisme
tijdens de GSoC 2011, die bestaat uit het oppakken van een venster van het spoor van elk venster
lengte op willekeurige wijze.

· vervagingsproces per gebruiker: gebruikers delen hetzelfde vervagingspoor, maar voor elke gebruiker
Er wordt willekeurig een ander startpunt in de trace opgepikt. Deze keuze is gemaakt
vermijd de noodzaak om één vervaagtracering per gebruiker aan te bieden.

Volgens de parameters die we hebben overwogen, drukt de volgende formule in detail uit:
totale grootte S_{sporen} van de vervagende sporen:

waarbij S_{sample} de grootte in bytes van de sample is (bijvoorbeeld 8 in het geval van dubbele precisie,
4 in geval van float-precisie), N_{RB} is het aantal RB's of een reeks RB's waarmee rekening moet worden gehouden,
T_{trace} is de totale lengte van de trace, T_{sample} is de tijdresolutie van de trace
(1 ms), en N_{scenarios} is het aantal gewenste fade-scenario's (dat wil zeggen
combinaties van verschillende sets kanaaltaps en gebruikerssnelheidswaarden). Wij zorgen voor sporen
voor 3 verschillende scenario's één voor elke kraanconfiguratie gedefinieerd in bijlage B.2 van
[TS36104]:

· Voetganger: met knooppuntsnelheid van 3 km/u.

· Voertuig: met een knooppuntsnelheid van 60 km/u.

· Stedelijk: met knooppuntensnelheid van 3 km/u.

vandaar N_{scenarios} = 3. Alle sporen hebben T_{trace} = 10 s en RB_{NUM} = 100. Dit resulteert
in totaal 24 MB bytes aan sporen.

Antennes
Gebaseerd zijn op de SpectrumPhyondersteunt het LTE PHY-model antennemodellering via de ns-3
AntenneModel klas. Daarom kan elk model op basis van deze klasse worden geassocieerd met elke eNB of
UE-instantie. Bijvoorbeeld het gebruik van de CosinusAntenneModel gekoppeld aan een eNB-apparaat
maakt het mogelijk om één sector van een macrobasisstation te modelleren. Standaard is de IsotroopAntenneModel
wordt gebruikt voor zowel eNB's als UE's.

PHY
Overzicht
Het fysieke laagmodel dat in deze LTE-simulator wordt aangeboden, is gebaseerd op het model dat wordt beschreven in
[Piro2011], met de volgende wijzigingen. Het model omvat nu de intercel
interferentieberekening en de simulatie van uplinkverkeer, inclusief beide pakketten
transmissie en CQI-generatie.

subframe Structuur
Het subframe is verdeeld in een besturings- en datagedeelte, zoals beschreven in figuur LTE subframe
afdeling..
[afbeelding] LTE-subframeverdeling..UNINDENT

Gezien de granulariteit van de simulator op basis van RB, de besturing en de referentie
signalering moet bijgevolg worden gemodelleerd met inachtneming van deze beperking. Volgens de
standaard [TS36211], begint het downlink-besturingsframe aan het begin van elk subframe
en duurt maximaal drie symbolen over de gehele systeembandbreedte, waarbij de werkelijke
De duur wordt geleverd door het Physical Control Format Indicator Channel (PCFICH). De
informatie over de toewijzing wordt vervolgens in kaart gebracht in de resterende hulpbron tot aan de
duur gedefinieerd door de PCFICH, in het zogenaamde Physical Downlink Control Channel
(PDCCH). Een PDCCH transporteert een enkel bericht genaamd Downlink Control Information (DCI)
afkomstig van de MAC-laag, waar de planner de resourcetoewijzing voor a
specifieke gebruiker. De PCFICH en PDCCH worden gemodelleerd met de overdracht van de besturing
frame met een vaste duur van 3/14 milliseconden, verspreid over het gehele beschikbare frame
bandbreedte, omdat de planner de grootte van het controlegebied niet schat. Dit
houdt in dat een enkel transmissieblok het gehele besturingsframe modelleert met een vaste
vermogen (dwz het vermogen dat wordt gebruikt voor de PDSCH) over alle beschikbare RB's. Volgens dit
Deze transmissie vertegenwoordigt ook een waardevolle ondersteuning voor het referentiesignaal
(RS). Dit maakt het mogelijk om elke TTI sindsdien een evaluatie te geven van het interferentiescenario
alle eNB zenden (tegelijkertijd) het besturingsframe over de respectievelijke
beschikbare bandbreedtes. We merken op dat het model sindsdien geen vermogensversterking omvat
het weerspiegelt geen enkele verbetering in het geïmplementeerde model voor de kanaalschatting.

Het Sounding Reference Signal (SRS) is op soortgelijke wijze gemodelleerd als het downlink-besturingsframe.
Het SRS wordt periodiek in het laatste symbool van het subframe van het hele systeem geplaatst
bandbreedte. De RRC-module bevat al een algoritme voor het dynamisch toewijzen van de
periodiciteit als functie van het feitelijke aantal UE's dat aan een eNB is gekoppeld volgens de
UE-specifieke procedure (zie sectie 8.2 van [TS36213]).

MAC-adres naar Kanaal vertraging
Om de latentie van echte MAC- en PHY-implementaties te modelleren, simuleert het PHY-model a
MAC-naar-kanaalvertraging in veelvouden van TTI's (1 ms). De overdracht van zowel gegevens als controle
pakketten worden met dit bedrag vertraagd.

CQI feedback
Het genereren van CQI-feedback gebeurt overeenkomstig de specificaties in [FFAPI]. In
detail hebben we gekeken naar het genereren van periodieke breedband-CQI (dat wil zeggen, een enkele waarde van
kanaalstatus die representatief wordt geacht voor alle gebruikte RB's) en inband-CQI's (d.w.z. a
een reeks waarden die de kanaalstatus voor elke RB vertegenwoordigen).

De te rapporteren CQI-index wordt verkregen door eerst een SINR-meting te verkrijgen en daarna
het doorgeven van deze SINR-meting aan de Adaptieve Modulatie en Codering, die deze zal toewijzen aan de
CQI-index.

Bij downlink kan de SINR die wordt gebruikt om CQI-feedback te genereren op twee verschillende manieren worden berekend
manieren:

1. Ctrl methode: SINR wordt berekend door het signaalvermogen van de referentie te combineren
signalen (die in de simulatie equivalent zijn aan de PDCCH) en de interferentie
stroom van de PDCCH. Deze aanpak resulteert in het beschouwen van elke aangrenzende eNB als een
interferentie, ongeacht of deze eNB daadwerkelijk een PDSCH uitvoert
transmissie, en ongeacht het vermogen en de RB's die worden gebruikt voor eventuele interferentie
PDSCH-transmissies.

2. Gemengd methode: SINR wordt berekend door het signaalvermogen van de referentie te combineren
signalen (die in de simulatie equivalent zijn aan de PDCCH) en de interferentie
stroom van de PDSCH. Deze aanpak heeft tot gevolg dat alleen degenen als interferenties worden beschouwd
naburige eNB's die actief gegevens verzenden op de PDSCH, en dit mogelijk maken
inband-CQI's genereren die rekening houden met verschillende hoeveelheden interferentie op verschillende apparaten
RB's volgens het werkelijke interferentieniveau. In het geval dat er geen PDSCH
transmissie wordt uitgevoerd door een eNB, deze methode gaat ervan uit dat er sprake is van interferentie
nul, dat wil zeggen dat de SINR alleen wordt berekend als de verhouding tussen signaal en ruis.

Om te schakelen tussen deze twee benaderingen voor het genereren van CQI, LteHelper::GebruikPdschForCqiGeneration
moet worden geconfigureerd: false voor de eerste benadering en true voor de tweede benadering (true is
standaardwaarde):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (true));

Bij uplink worden twee soorten CQI's geïmplementeerd:

· Op basis van SRS, periodiek verzonden door de EU's.

· PUSCH-gebaseerd, berekend op basis van de daadwerkelijk verzonden gegevens.

De plannerinterface bevat een genaamd attribuutsysteem UlCqiFilter voor het beheren van de
filtering van de CQI's op basis van hun aard, in detail:

· SRS_UL_CQI voor het opslaan van alleen op SRS gebaseerde CQI's.

· PUSCH_UL_CQI voor het opslaan van alleen op PUSCH gebaseerde CQI's.

· ALL_UL_CQI voor het opslaan van alle ontvangen CQI's.

Opgemerkt moet worden dat de FfMacScheduler biedt alleen de interface en het is materie
van de daadwerkelijke implementatie van de planner om de code voor het beheer van deze attributen op te nemen
(zie de sectie over de planner voor meer informatie hierover).

Storing Model
Het PHY-model is gebaseerd op de bekende Gaussiaanse interferentiemodellen
de krachten van interfererende signalen (in lineaire eenheden) worden bij elkaar opgeteld om te bepalen
het totale interferentievermogen.

Het sequentiediagram van figuur Volgorde diagram of the PHY storing berekening
procedures laat zien hoe interfererende signalen worden verwerkt om de SINR te berekenen, en hoe SINR
wordt vervolgens gebruikt voor het genereren van CQI-feedback.
[afbeelding] Volgordediagram van de PHY-interferentieberekeningsprocedure.UNINDENT

LTE Spectrum Model
Het gebruik van het radiospectrum door eNB's en UE's in LTE wordt beschreven in [TS36101]. In de
In de simulator wordt het gebruik van het radiospectrum als volgt gemodelleerd. Laat f_c het LTE Absolute aanduiden
Radiofrequentiekanaalnummer, dat de draaggolffrequentie op 100 kHz identificeert
raster; laat bovendien B de transmissiebandbreedteconfiguratie in aantal zijn
Bronblokken. Voor elk paar (f_c,B) dat in de simulatie wordt gebruikt, definiëren we een overeenkomstig paar
SpectrumModel met behulp van de functionaliteit van de sec-spectrum-module . model gebruiken
het Spectrum-framework beschreven in [Baldo2009]. f_c en B kunnen voor elk worden geconfigureerd
eNB geïnstantieerd in de simulatie; daarom kan elke eNB een ander spectrummodel gebruiken.
Elke UE zal automatisch het spectrummodel gebruiken van de eNB waaraan deze is gekoppeld. De ... gebruiken
MultiModelSpectrumChannel beschreven in [Baldo2009], de interferentie tussen eNB's die gebruik maken van
Er wordt op de juiste wijze rekening gehouden met verschillende spectrummodellen. Dit maakt het mogelijk om dynamiek te simuleren
spectrumtoegangsbeleid, zoals bijvoorbeeld het spectrumlicentiebeleid
besproken in [Ofcom2600MHz].

Data PHY Fout Model
De simulator omvat een foutmodel van het datavlak (dwz PDSCH en PUSCH) overeenkomstig
aan de standaard link-to-system mapping (LSM) technieken. De keuze sluit aan bij de
standaardsysteemsimulatiemethodologie van OFDMA-radiotransmissietechnologie. Dankzij
Met LSM zijn we in staat een goed nauwkeurigheidsniveau te behouden en tegelijkertijd de nauwkeurigheid te beperken
De rekencomplexiteit neemt toe. Het is gebaseerd op het in kaart brengen van een enkele linklaag
prestatie verkregen door middel van link-level simulators met het systeem (in ons geval netwerk)
simulatoren. Met name de lagensimulator wordt gebruikt voor het genereren van de performance
van een enkele link vanuit het perspectief van een PHY-laag, meestal in termen van codeblokfoutenpercentage
(BLER), onder specifieke statische omstandigheden. LSM maakt het gebruik van deze parameters in meer gevallen mogelijk
complexe scenario's, typisch voor systeem-/netwerksimulators, waarbij we meer links hebben,
interferentie en "gekleurde" kanaalvoortplantingsverschijnselen (bijv. frequentieselectief).
vervagen).

Om dit te doen is de Vienna LTE Simulator [ViennaLteSim] gebruikt voor wat betreft de
extractie van de prestaties van de linklaag en de op wederzijdse informatie gebaseerde effectieve SINR
(MIESM) als LSM-mappingfunctie met behulp van een deel van het werk dat onlangs door de Signet is gepubliceerd
Groep van de Universiteit van Padua [PaduaPEM].

MIESM
De specifieke LSM-methode die wordt toegepast, is die gebaseerd op het gebruik van wederzijdse informatie
metriek, gewoonlijk de wederzijdse informatie per gecodeerd bit genoemd (MIB of MMIB wanneer
er is sprake van een gemiddelde van meerdere MIB's). Een andere optie zou worden vertegenwoordigd door de
Exponentieel ESM (EESM); Recente onderzoeken tonen echter aan dat MIESM beter presteert dan EESM
termen van nauwkeurigheid [LozanoCost].
[afbeelding] MIESM computationeel procedurediagram.UNINDENT

De wederzijdse informatie (MI) is afhankelijk van de constellatiekartering en kan dat ook zijn
berekend per transportblok (TB), door de MI te evalueren over de symbolen en de
onderdrager. Voor een netwerksimulator zou dit echter te complex zijn. Daarom in onze
implementatie van een vlakke kanaalrespons binnen de RB is overwogen; Daarom, de
De totale MI van een tuberculose wordt berekend door het gemiddelde te nemen van de MI die is geëvalueerd per elke RB die in de tuberculose wordt gebruikt.
In detail wordt het geïmplementeerde schema weergegeven in figuur MIESM computationeel procedures
diagram, waar we zien dat het model begint met het evalueren van de MI-waarde voor elke RB,
weergegeven in de figuur door de SINR-monsters. Vervolgens wordt de equivalente MI geëvalueerd per
TB-basis door de MI-waarden te middelen. Ten slotte moet er nog een stap verder worden gezet sinds de
linkniveausimulator retourneert de prestaties van de link in termen van blokfoutpercentage
(BLER) in een Addive White Guassian Noise (AWGN)-kanaal, waarbij de blokken de code vormen
blokken (CB's) die onafhankelijk worden gecodeerd/gedecodeerd door de turbo-encoder. Over deze kwestie heeft de
Het standaard 3GPP-segmentatieschema is gebruikt voor het schatten van de werkelijke CB-omvang
(beschreven in sectie 5.1.2 van [TS36212]). Dit schema verdeelt de TB in N_{K_-}
blokken van maat K_- en N_{K+} blokken van maat K_+. Daarom is de algehele TB BLER (TBLER)
kan worden uitgedrukt als

waarbij de CBLER_i de BLER is van de CBi verkregen volgens de linkniveausimulator
CB BLER-curven. Voor het schatten van de CBLER_i is de MI-evaluatie geïmplementeerd
volgens de numerieke benadering gedefinieerd in [wimaxEmd]. Bovendien voor het verminderen
Vanwege de complexiteit van de berekening is de benadering omgezet in opzoeken
tafels. In detail is het Gaussiaanse cumulatieve model gebruikt voor het benaderen van de AWGN
BLER-curven met drie parameters die nauw aansluiten bij de standaard AWGN
optredens, in formule:

waarbij x de MI van de TB is, vertegenwoordigt b_{ECR} het "overgangscentrum" en c_{ECR} is
gerelateerd aan de "overgangsbreedte" van de Gaussiaanse cumulatieve verdeling voor elk
Effectieve codesnelheid (ECR), de werkelijke transmissiesnelheid volgens het kanaal
codering en MCS. Om de computationele complexiteit van het model dat we hebben overwogen te beperken
slechts een subset van de mogelijke ECR's, in feite zouden we potentieel 5076 mogelijke ECR's hebben
(dwz 27 MCS's en 188 CB-maten). Wat dit betreft zullen we de CB-maten tot enkele beperken
representatieve waarden (dwz 40, 140, 160, 256, 512, 1024, 2048, 4032, 6144), terwijl voor
bij de andere zal de slechtste die de echte benadert, worden gebruikt (dwz de kleinere CB
beschikbare maatwaarde ten opzichte van de echte). Deze keuze is afgestemd op het typische
prestaties van turbocodes, waarbij de CB-grootte geen sterke invloed heeft op de BLER.
Er moet echter worden opgemerkt dat dit effect wel eens kan optreden bij CB-groottes kleiner dan 1000 bits
relevant (dwz tot 2 dB); daarom nemen we dit onevenwichtige bemonsteringsinterval over
met meer precisie waar dat nodig is. Dit gedrag wordt bevestigd door de cijfers
gepresenteerd in de Annes-sectie.

BLER Curves
In dit opzicht hebben we een deel van de curven verkregen binnen [PaduaPEM] hergebruikt. In detail: wij
introduceerde de afhankelijkheid van de CB-grootte in de CB BLER-curven met de steun van de ontwikkelaars
van [PaduaPEM] en van de LTE Vienna Simulator. In feite biedt de vrijgegeven module de
linklaagprestaties alleen voor wat de MCS's betreft (dat wil zeggen, met een bepaalde vaste ECR). In
detail van de nieuwe foutenpercentagecurven voor elk is geëvalueerd met een simulatiecampagne
met de linklagensimulator voor een enkele link met AWGN-ruis en voor CB-grootte van 104,
140, 256, 512, 1024, 2048, 4032 en 6144. Deze curven zijn in kaart gebracht met de Gaussiaanse
cumulatieve modelformule hierboven gepresenteerd voor het verkrijgen van de correspondenten b_{ECR} en
c_{ECR}-parameters.

De BLER-prestaties van alle MCS verkregen met de linkniveausimulator worden uitgezet in de
volgende figuren (blauwe lijnen) samen met hun overeenkomstige mapping naar de Gaussiaanse
cumulatieve verdeling (rode stippellijnen).
[afbeelding] BLER voor MCS 1, 2, 3 en 4..UNINDENT
[afbeelding] BLER voor MCS 5, 6, 7 en 8..UNINDENT
[afbeelding] BLER voor MCS 9, 10, 11 en 12..UNINDENT
[afbeelding] BLER voor MCS 13, 14, 15 en 16..UNINDENT
[afbeelding] BLER voor MCS 17, 17, 19 en 20..UNINDENT
[afbeelding] BLER voor MCS 21, 22, 23 en 24..UNINDENT
[afbeelding] BLER voor MCS 25, 26, 27 en 28..UNINDENT
[afbeelding] BLER voor MCS 29..UNINDENT

Integratie of the BLER curves in the ns-3 LTE module
Het geïmplementeerde model maakt gebruik van de curven voor de LSM van het recente LTE PHY Error Model
vrijgegeven in de ns3-gemeenschap door de Signet Group [PaduaPEM] en de nieuwe gegenereerd
voor verschillende CB-maten. De LteSpectrumPhy klasse is verantwoordelijk voor de evaluatie van de TB BLER
dankzij de methoden van de LteMiErrorModel klasse, die de leiding heeft
het evalueren van de TB BLER volgens de vector van de waargenomen SINR per RB, de MCS en
de omvang om de segmentatie van de tuberculose in CB’s goed te kunnen modelleren. Om te verkrijgen
de vector van de waargenomen SINR twee exemplaren van LtePemSinrChunkProcessor (kind van
LteChunkProcessor gewijd aan het evalueren van de SINR voor het verkrijgen van fysieke foutprestaties)
zijn gekoppeld aan UE downlink en eNB uplink LteSpectrumPhy modules voor het evalueren van de
foutmodelverdeling van respectievelijk PDSCH (UE-zijde) en ULSCH (eNB-zijde).

Het model kan worden uitgeschakeld voor het werken met een kanaal zonder verliezen door de instelling PemIngeschakeld
attribuut van de LteSpectrumPhy klasse (standaard is actief). Dit kan volgens
aan de standaard ns3 attribuutsysteemprocedure, dat wil zeggen:

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

Controle Kanalen PHY Fout Model
De simulator bevat het foutmodel voor downlink-besturingskanalen (PCFICH en PDCCH),
terwijl bij uplink wordt aangenomen dat het een ideaal foutvrij kanaal is. Het model is gebaseerd op de
De eerder gepresenteerde MIESM-benadering voor het overwegen van de effecten van frequentieselectief
kanaal, aangezien de meeste besturingskanalen de gehele beschikbare bandbreedte bestrijken.

PCFICH + PDCCH Fout Model
Het model dat is aangenomen voor de foutverdeling van deze kanalen is gebaseerd op een evaluatie
studie uitgevoerd in de RAN4 van 3GPP, waar verschillende leveranciers de
demodulatieprestaties van de PCFICH samen met PDCCH. Dit komt door het feit dat
de PCFICH is het kanaal dat verantwoordelijk is voor het communiceren naar de UE's van de werkelijke dimensie ervan
de PDCCH (die tussen 1 en 3 symbolen omvat); daarom de juiste decodering van
de DCI's zijn afhankelijk van de juiste interpretatie van beide. In 3GPP heeft dit probleem
zijn geëvalueerd voor het verbeteren van de celrandprestaties [FujitsuWhitePaper], waar de
interferentie tussen naburige cellen kan relatief hoog zijn als gevolg van signaalverslechtering. A
een soortgelijk probleem is opgemerkt in het femtocelscenario en, meer in het algemeen, in HetNet
scenario's is het knelpunt voornamelijk gedetecteerd als het PCFICH-kanaal [Bharucha2011],
wanneer er veel eNB's in hetzelfde verzorgingsgebied worden ingezet, kan dit kanaal botsen
in frequentie, waardoor ook de correcte detectie van het PDCCH-kanaal onmogelijk wordt.

In de simulator is de tijdens de ontvangst waargenomen SINR geschat op basis van
het hierboven gepresenteerde MIESM-model om de foutverdeling van PCFICH te evalueren en
PDCCH. In detail worden de SINR-monsters van alle RB's opgenomen in de evaluatie van de MI
geassocieerd met het controleframe en, volgens deze waarden, de effectieve SINR (eSINR)
wordt verkregen door het MI-evaluatieproces om te keren. Opgemerkt moet worden dat in het geval van
MIMO-transmissie, zowel PCFICH als de PDCCH gebruiken altijd de zenddiversiteitsmodus als
gedefinieerd door de standaard. Volgens de eSINR werd de decoderingsfout waargenomen
De waarschijnlijkheid kan worden geschat als functie van de resultaten gepresenteerd in [R4-081920]. In geval dat
er een fout optreedt, worden de DCI's weggegooid en daarom kan de UE de
correspondent Tbs, daardoor verloren.

MIMO Model
Het gebruik van meerdere antennes zowel aan de zender- als aan de ontvangerzijde, bekend als
multiple-input en multiple-output (MIMO), is een probleem dat in de literatuur goed is bestudeerd
de afgelopen jaren. Het meeste werk concentreert zich op het analytisch evalueren van de winst die de onderneming oplevert
verschillende MIMO-schema's zouden qua capaciteit kunnen hebben; Maar iemand biedt ook
informatie over de winst in termen van ontvangen vermogen [CatreuxMIMO].

Volgens de bovenstaande overwegingen kan een flexibeler model worden verkregen
de winst die MIMO-schema's vanuit statistisch oogpunt in het systeem opleveren. Als
Zoals eerder benadrukt, presenteert [CatreuxMIMO] de statistische winst van verschillende MIMO-oplossingen
met betrekking tot de SISO-versie in geval van geen correlatie tussen de antennes. In het werk de
versterking wordt gepresenteerd als de cumulatieve distributiefunctie (CDF) van de uitgangs-SINR voor
wat betreft SISO-, MIMO-Alamouti-, MIMO-MMSE-, MIMO-OSIC-MMSE- en MIMO-ZF-schema's.
Bij het uitwerken van de resultaten kan de output-SINR-verdeling worden benaderd met a
log-normale waarde met een ander gemiddelde en een andere variantie als functie van het beschouwde schema.
De varianties zijn echter niet zo verschillend en zijn ongeveer gelijk aan die ene
van de SISO-modus die al is opgenomen in de schaduwcomponent van de
GebouwenVoortplantingVerliesModel, in detail:

· SISO: = 13.5 en ma = 20 [dB].

· MIMO-Alamouti: = 17.7 en ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 en ma = 16.6 [dB].

· MIMO-OSIC-MMSE: = 12.6 en ma = 15.5 [dB].

· MIMO-ZF: = 10.3 en ma = 12.6 [dB].

Daarom implementeert de PHY-laag het MIMO-model als de door de ontvanger waargenomen versterking
bij gebruik van een MIMO-schema met betrekking tot het schema verkregen met SISO one. Wij merken op dat deze
winsten verwezen naar een geval waarin er geen correlatie bestaat tussen de antennes in MIMO
schema; modelleer daarom geen degradatie als gevolg van padcorrelatie.

UE PHY Afmetingen Model
Volgens [TS36214] moet de UE een reeks metingen van de eNB's rapporteren die de
apparaat kan waarnemen: het ontvangen referentiesignaal (RSRP) en het
ontvangen referentiesignaalkwaliteit (RSRQ). De eerste is een maatstaf voor de ontvangen kracht van
een specifieke eNB, terwijl deze laatste ook kanaalinterferentie en thermische ruis omvat.
De UE moet de metingen samen met de fysieke celidentiteit (PCI) van de
cel. Zowel de RSRP- als de RSRQ-metingen worden uitgevoerd tijdens de ontvangst van de RS,
terwijl de PCI wordt verkregen met het Primary Synchronization Signal (PSS). De PSS wordt verzonden
door de eNB elk 5 subframes en in detail in de subframes 1 en 6. In echte systemen alleen
Er zijn 504 verschillende PCI's beschikbaar, en daarom kan het voorkomen dat twee nabijgelegen eNB's de
dezelfde PCI; In de simulator modelleren we echter PCI's met behulp van simulatie-metagegevens, en dat staan ​​we ook toe
tot 65535 verschillende PCI's, waardoor PCI-botsingen worden vermeden, op voorwaarde dat minder dan 65535
eNB's worden in hetzelfde scenario gesimuleerd.

Volgens [TS36133] secties 9.1.4 en 9.1.7 wordt RSRP gerapporteerd door de PHY-laag in dBm
terwijl RSRQ in dB. De waarden van RSRP en RSRQ worden aan hogere lagen verstrekt via de
C-PHY SAP (via UeMeasurementsParameters struct) elke 200 ms zoals gedefinieerd in
[TS36331]. Laag 1-filtering wordt uitgevoerd door het middelen van alle verzamelde metingen
tijdens het laatste vensterslot. Voor onderzoek kan de periodiciteit van de rapportage worden aangepast
doeleinden door middel van de LteUePhy::UeMetingenFilterPeriode attribuut.

De formules van de RSRP en RSRQ kunnen worden vereenvoudigd gezien de aanname van de PHY
laag dat het kanaal vlak is binnen de RB, het hoogste nauwkeurigheidsniveau. In feite dit
impliceert dat alle RE's binnen een RB dezelfde macht hebben, daarom:

waarbij P(k,m) het signaalvermogen van de RE m binnen de RB k vertegenwoordigt, zoals waargenomen
eerder, is constant binnen dezelfde RB en gelijk aan P(k), M is het aantal RE's dat draagt
de RS in een RB en K is het aantal RB's. Opgemerkt moet worden dat P(k), en in het algemeen alles
de in deze paragraaf gedefinieerde bevoegdheden worden in de simulator verkregen uit de PSD van de RB
(die wordt aangeboden door de LteInterferencePowerChunkProcessor), in detail:

waarbij PSD_{RB}(k) de spectrale vermogensdichtheid van de RB k is, 180000 is de bandbreedte in Hz
van de RB en 12 is het aantal RE's per RB in een OFDM-symbool. Op dezelfde manier, voor RSSI wij
hebben

waarbij S het aantal OFDM-symbolen is die RS in een RB dragen en R het aantal RE's is
met een RS in een OFDM-symbool (vastgesteld op 2), terwijl P(k,s,r), I(k,s,r) en N(k,s,r)
vertegenwoordigen respectievelijk de waargenomen kracht van de bedienende cel, de interferentiekracht en
het ruisvermogen van de RE r in symbool s. Wat RSRP betreft, zijn de metingen binnen een RB dat wel
is altijd gelijk onder elkaar volgens het PHY-model; daarom P(k,s,r) = P(k),
I(k,s,r) = I(k) en N(k,s,r) = N(k), wat impliceert dat de RSSI als volgt kan worden berekend:

Gezien de beperkingen van de implementatie van de PHY-opvangketen, en om dat te doen
het niveau van de rekencomplexiteit laag te houden, waarvoor alleen RSRP rechtstreeks kan worden verkregen
alle cellen. Dit komt door het feit dat LteSpectrumPhy is ontworpen voor het evalueren van de
interferentie alleen met betrekking tot het signaal van de bedienende eNB. Dit impliceert dat de PHY
laag is geoptimaliseerd voor het beheren van de informatie over stroomsignalen met de dienende eNB als a
referentie. RSRP en RSRQ van buurcel i kunnen echter door de stroom worden geëxtraheerd
beschikbare informatie over de bedienende cel j, zoals hieronder beschreven:

waarbij RSRP_i de RSRP is van de buurcel i, is P_i(k) het waargenomen vermogen bij elke RE
binnen de RB k is K het totale aantal RB's, RSSI_i is de RSSI van de buurcel i
wanneer de UE is gekoppeld aan cel j (wat, aangezien het de som is van alle ontvangen krachten,
valt samen met RSSI_j), I_j(k) is de totale interferentie waargenomen door UE in elke RE van RB k
wanneer gehecht aan cel i (verkregen door de LteInterferencePowerChunkProcessor), P_j(k) is
het waargenomen vermogen van cel j in elke RE van de RB k en N is het spectrale vermogenruis
dichtheid in elke RE. Het monster wordt als geldig beschouwd als de geëvalueerde RSRQ is
boven de LteUePhy::RsrqUeMeasdrempel attribuut.

HARQ
Het geïmplementeerde HARQ-schema is gebaseerd op een combinatie van incrementele redundantie (IR)-oplossingen
met meerdere stop-en-wacht-processen om een ​​continue gegevensstroom mogelijk te maken. In detail: de
gekozen oplossing is de zacht combineren hybride IR Vol incrementele overtolligheid (ook wel genoemd
IR Type II), wat impliceert dat de heruitzendingen alleen nieuwe informatie bevatten
naar de vorige. Het resourcetoewijzingsalgoritme van de HARQ is geïmplementeerd
binnen de respectieve plannerklassen (dwz RrFfMacScheduler en PfFfMacScheduler,
raadpleeg de overeenkomstige secties voor meer informatie), terwijl het decoderingsgedeelte van de
HARQ is geïmplementeerd in de LteSpectrumPhy en LteHarqPhy klassen die zullen zijn
beschreven in dit gedeelte.

Volgens de standaard zijn de UL-hertransmissies synchroon en daarom ook
toegewezen 7 ms na de oorspronkelijke verzending. Aan de andere kant, voor de DL, zijn ze dat wel
asynchroon en kan daarom flexibeler worden toegewezen vanaf 7 ms en
het is een kwestie van de specifieke implementatie van de planner. Het gedrag van de HARQ-processen is
afgebeeld in Figuur:ref:fig-harq-processen-schema.

Op de MAC-laag is de HARQ-entiteit die zich in de planner bevindt, verantwoordelijk voor de controle
de 8 HARQ-processen voor het genereren van nieuwe pakketten en het beheren van de hertransmissies beide
de DL en de UL. De planner verzamelt de HARQ-feedback van eNB- en UE PHY-lagen
(respectievelijk voor UL- en DL-verbinding) door middel van de FF API-primitieven
SchedUlTriggerReq en SchedUlTriggerReq. Volgens de HARQ-feedback en de RLC
bufferstatus genereert de planner een set DCI's, inclusief beide hertransmissies van
HARQ-blokken ontvingen over het algemeen foutieve en nieuwe transmissies, waarbij prioriteit werd gegeven aan de
voormalig. Wat dit betreft moet de planner rekening houden met één beperking wanneer
Bij het toewijzen van de bron voor HARQ-heruitzendingen moet dezelfde modulatievolgorde worden gebruikt
de eerste transmissiepoging (dwz QPSK voor MCS in [0..9], 16QAM voor MCS in [10..16]
en 64QAM voor MCS in [17..28]). Deze beperking vloeit voort uit de specificatie van het tarief
matcher in de 3GPP-standaard [TS36212], waarbij het algoritme de modulatievolgorde voor
het genereren van de verschillende blokken van de redundantieversies.

Het PHY Error Model-model (dat wil zeggen de LteMiErrorModel klasse die al eerder is gepresenteerd) heeft
is uitgebreid voor het overwegen van IR HARQ volgens [wimaxEmd], waar de parameters voor
de AWGN-curven in kaart brengen voor MIESM-kaarten in het geval van hertransmissies worden gegeven door:

waarbij X het aantal originele informatiebits is, C_i het aantal gecodeerde bits is, en M_i
de wederzijdse informatie per HARQ-blok ontvangen over het totale aantal q-hertransmissies.
Daarom om met het foutenmodel de foutkans te kunnen retourneren
geïmplementeerd in de simulator evalueert de R_{eff} en de MI_{I eff} en retourneert de waarde
van de foutkans van de ECR van dezelfde modulatie met het dichtstbijzijnde lagere tarief ten opzichte van
de R_{eff}. Om het effect van HARQ-hertransmissies in overweging te nemen, zijn er nieuwe reeksen curven gebruikt
zijn geïntegreerd met respect voor de standaard die werd gebruikt voor de originele MCS. De nieuwe bochten
zijn bedoeld voor de gevallen waarin de meest conservatieve MCS van een modulatie wordt gebruikt
wat impliceert dat R_{eff} lager moet worden gegenereerd dan die van standaard MCS's. Op dit
ongeacht de curven voor 1, 2 en 3 hertransmissies zijn geëvalueerd voor 10 en 17. Voor
MCS 0 hebben we alleen als de eerste heruitzending beschouwd, aangezien de geproduceerde codesnelheid al is
zeer conservatief (dwz 0.04) en retourneert een foutenpercentage dat voldoende robuust is voor de ontvangst
(dwz de neergang van de BLER concentreert zich rond -18 dB). Opgemerkt moet worden dat de
Er is aangenomen dat de grootte van de eerste TB-transmissie alle informatiebits bevat
gecodeerd zijn; daarom is X gelijk aan de grootte van de eerste TB die door een HARQ-proces wordt verzonden. De
model gaat ervan uit dat de uiteindelijke aanwezigheid van pariteitsbits in de codewoorden al aanwezig is
beschouwd in de linkniveaucurven. Dit houdt in dat zodra het minimum R_{eff} is
het model bereikt, omvat niet de winst als gevolg van de transmissie van verdere paring
bits.
[afbeelding] HARQ verwerkt gedrag in LTE.UNINDENT

Het deel van HARQ dat gewijd was aan het beheren van de decodering van de HARQ-blokken is geweest
geïmplementeerd in de LteHarqPhy en LteSpectrumPhy klassen. Eerstgenoemde heeft de leiding
het bijhouden van de HARQ-informatie voor elk actief proces. Deze laatste heeft interactie met
LteMiErrorModel klasse voor het evalueren van de juistheid van de ontvangen en opgenomen blokken
het berichtenalgoritme dat verantwoordelijk is voor de communicatie met de HARQ-entiteit in de planner
het resultaat van de decodificaties. Deze berichten zijn ingekapseld in de
dlInfoListElement voor DL ​​en ulInfoListElement voor UL en verzonden via de PUCCH en de
PHICH respectievelijk met een ideaal foutvrij model volgens de aannames in hun
implementatie. Een schets van de iteratie tussen HARQ en LTE-protocolstapel in
weergegeven in figuur:ref:fig-harq-architectuur.

Ten slotte is de HARQ-engine altijd actief, zowel op de MAC- als op de PHY-laag; echter in het geval van
de planner ondersteunt HARQ niet, het systeem blijft met de HARQ werken
functies geblokkeerd (dwz buffers zijn gevuld maar niet gebruikt). Deze implementatie
kenmerk geeft achterwaartse compatibiliteit met planners die vóór HARQ zijn geïmplementeerd
integratie.
[afbeelding] Interactie tussen HARQ en LTE-protocolstack.UNINDENT

MAC-adres
Middelen Toewijzing Model
We beschrijven nu kort hoe de toewijzing van middelen wordt afgehandeld in LTE, en verduidelijken hoe dit in zijn werk gaat
gemodelleerd in de simulator. De planner is verantwoordelijk voor het genereren van specifieke structuren
Dit betekent dat we onszelf en onze geliefden praktisch vergiftigen. Data Controle aanwijzing (DCI) die vervolgens door de PHY van de eNB worden verzonden
de verbonden UE's, om hen te informeren over de toewijzing van bronnen per subframe
basis. Door dit in de downlink-richting te doen, moet de planner een aantal specifieke gegevens invullen
velden van de DCI-structuur met alle informatie, zoals: de modulatie en codering
Het te gebruiken schema (MCS), de grootte van het MAC Transport Block (TB) en de toewijzingsbitmap
die identificeert welke RB's de gegevens zullen bevatten die door de eNB aan elke gebruiker worden verzonden.

Voor het in kaart brengen van hulpbronnen aan fysieke RB's gebruiken we a gelokaliseerde in kaart brengen aanpak (zie
[Sesia2009], paragraaf 9.2.2.1); daarom wordt in een bepaald subframe altijd elke RB toegewezen
dezelfde gebruiker in beide slots. De toewijzingsbitmap kan in verschillende formaten worden gecodeerd; in
Bij deze implementatie hebben we rekening gehouden met de Toewijzing Type 0 gedefinieerd in [TS36213], volgens
waaraan de RB's zijn gegroepeerd in Resource Block Groups (RBG) van verschillende vastgestelde grootte
als functie van de gebruikte transmissiebandbreedteconfiguratie.

Voor bepaalde bandbreedtewaarden zijn niet alle RB's bruikbaar, aangezien de groepsgrootte niet a is
gemeenschappelijke deler van de groep. Dit is bijvoorbeeld het geval als de bandbreedte gelijk is aan
25 RB's, wat resulteert in een RBG-grootte van 2 RB's, en daarom zal 1 RB niet resulteren
adresseerbaar. Bij uplink is het formaat van de DCI's anders, omdat alleen aangrenzende RB's dat kunnen
worden gebruikt vanwege de SC-FDMA-modulatie. Als gevolg hiervan kunnen alle RB's worden toegewezen door
de eNB, ongeacht de bandbreedteconfiguratie.

Adaptieve Modulatie en codering
De simulator biedt twee Adaptive Modulation and Coding (AMC)-modellen: één gebaseerd op de
GSoC-model [Piro2011] en één gebaseerd op het fysieke foutenmodel (beschreven in de
volgende secties).

Het eerstgenoemde model is een aangepaste versie van het model beschreven in [Piro2011], dat op zijn beurt
is geïnspireerd op [Seo2004]. Onze versie wordt hieronder beschreven. Laat ik de
generieke gebruiker, en laat mma_i zijn SINR zijn. We krijgen de spectrale efficiëntie \ta_i van gebruiker i
met behulp van de volgende vergelijkingen:

De procedure beschreven in [R1-081483] wordt gebruikt om het overeenkomstige MCS-schema te verkrijgen. De
De spectrale efficiëntie wordt gekwantificeerd op basis van de kanaalkwaliteitsindicator (CQI), afgerond op
de laagste waarde, en wordt toegewezen aan het overeenkomstige MCS-schema.

Ten slotte merken we op dat er enkele discrepanties zijn tussen de MCS-index in [R1-081483]
en dat wordt aangegeven door de standaard: [TS36213] Tabel 7.1.7.1-1 zegt dat de MCS-index
gaat van 0 tot 31, en 0 lijkt een geldig MCS-schema te zijn (TB-grootte is niet 0), maar in
[R1-081483] de eerste bruikbare MCS-index is 1. Om dus de waarde te krijgen zoals bedoeld door de
standaard moeten we 1 aftrekken van de index gerapporteerd in [R1-081483].

Het alternatieve model is gebaseerd op het fysieke foutenmodel dat voor deze simulator is ontwikkeld
en uitgelegd in de volgende paragrafen. Met dit schema kan de MCS-selectie worden aangepast
met de daadwerkelijke prestaties van de PHY-laag volgens het specifieke CQI-rapport. Volgens
hun definitie, een CQI-index wordt toegewezen wanneer een enkele PDSCH TB met de modulatie
coderingsschema en codesnelheid komen overeen met die CQI-index in tabel 7.2.3-1 van [TS36213]
kan worden ontvangen met een foutkans kleiner dan 0.1. In het geval van breedband-CQI's wordt de
referentie TB omvat alle RBG's die beschikbaar zijn om een ​​referentie te hebben op basis van de
alle beschikbare middelen; terwijl voor subband-CQI's de referentie-TB de grootte heeft van de RBG's.

Vervoer Block model
Het model van de MAC Transport Blocks (TB's) dat door de simulator wordt geleverd, is vereenvoudigd
met betrekking tot de 3GPP-specificaties. In het bijzonder een simulatorspecifieke klasse
(PacketBurst) wordt gebruikt om MAC SDU's samen te voegen om het equivalent van de simulator te bereiken
van een TB, zonder de bijbehorende implementatiecomplexiteit. Het multiplexen van
verschillende logische kanalen van en naar de RLC-laag worden uitgevoerd met behulp van een speciaal pakket
tag (LteRadioBearerTag), die een functionaliteit uitvoert die gedeeltelijk gelijkwaardig is aan
die van de MAC-headers gespecificeerd door 3GPP.

De FemtoForum MAC-adres Scheduler Interface
In dit gedeelte wordt de ns-3-specifieke versie van de LTE MAC Scheduler Interface beschreven
Specificatie gepubliceerd door het FemtoForum [FFAPI].

We hebben de ns-3-specifieke versie van de FemtoForum MAC Scheduler Interface [FFAPI] geïmplementeerd
als een set abstracte C++-klassen; in het bijzonder wordt elke primitief vertaald naar een C++
methode van een bepaalde klasse. De voorwaarde geïmplementeerd hier wordt gebruikt met dezelfde betekenis
in [FFAPI], en verwijst daarom naar het proces van het vertalen van de logische interface
specificatie voor een bepaalde programmeertaal. De primitieven in [FFAPI] zijn gegroepeerd
in twee groepen: de CSCHED-primitieven, die zich bezighouden met de configuratie van de planner, en de
SCHED-primitieven, die zich bezighouden met de uitvoering van de planner. Verder [FFAPI]
definieert primitieven van twee verschillende soorten: die van het type REQ gaan van de MAC naar de
Scheduler, en die van het type IND/CNF gaan van de planner naar de MAC. Om deze te vertalen
kenmerken in C++ definiëren we de volgende abstracte klassen die Service implementeren
Toegangspunten (SAP's) die moeten worden gebruikt om de primitieven uit te geven:

· de FfMacSchedSapProvider klasse definieert alle C++-methoden die overeenkomen met SCHED
primitieven van het type REQ;

· de FfMacSchedSapGebruiker klasse definieert alle C++-methoden die overeenkomen met SCHED
primitieven van het type CNF/IND;

· de FfMacCschedSapProvider klasse definieert alle C++-methoden die ermee corresponderen
CSCHED-primitieven van het type REQ;

· de FfMacCschedSapGebruiker klasse definieert alle C++-methoden die overeenkomen met CSCHED
primitieven van het type CNF/IND;

Er zijn 3 blokken betrokken bij de MAC Scheduler-interface: besturingsblok, subframeblok
en Scheduler-blok. Elk van deze blokken vormt een deel van de MAC Scheduler-interface.
De onderstaande afbeelding toont de relatie tussen de blokken en de SAP's die in ons zijn gedefinieerd
implementatie van de MAC Scheduler-interface.
[foto]

Naast bovenstaande uitgangspunten zijn de volgende ontwerpkeuzes gemaakt:

· De definitie van de MAC Scheduler-interfaceklassen volgt de naamgevingsconventies
van de ns-3 Coderingsstijl. In het bijzonder volgen we de CamelCase-conventie voor de
primitieve namen. De primitief bijvoorbeeld CSCHED_CELL_CONFIG_REQ is vertaald naar
CschedCellConfigReq in de ns-3 code.

· Dezelfde naamgevingsconventies worden gevolgd voor de primitieve parameters. Zoals de
primitieve parameters zijn lidvariabelen van klassen, ze worden ook voorafgegaan door a
m_.

· met betrekking tot het gebruik van vectoren en lijsten in datastructuren merken we op dat [FFAPI] a
vrijwel C-georiënteerde API. Echter, van mening dat C++ wordt gebruikt in ns-3, en dat
het gebruik van C-arrays wordt afgeraden, we gebruikten STL-vectoren (standaard::vector) voor de
implementatie van de MAC Scheduler Interface, in plaats van C-arrays te gebruiken als
impliciet gesuggereerd door de manier waarop [FFAPI] is geschreven.

· In C++ zijn leden met constructors en destructors niet toegestaan vakbonden. Vandaar allemaal
die datastructuren waarvan wordt gezegd dat ze dat zijn vakbonden in [FFAPI] zijn gedefinieerd als
structuren in onze code.

Onderstaande figuur laat zien hoe de MAC Scheduler Interface binnen de eNB wordt gebruikt.
[foto]

De gebruikerskant van zowel de CSCHED SAP als de SCHED SAP wordt geïmplementeerd binnen de eNB MAC,
dat wil zeggen, in het bestand lte-enb-mac.cc. De eNB MAC kan met verschillende planners worden gebruikt
implementaties zonder aanpassingen. Dezelfde figuur laat als voorbeeld ook zien hoe de
Round Robin Scheduler is geïmplementeerd: om te communiceren met de MAC van de eNB, de Round Robin
planner implementeert de Provider-kant van de SCHED SAP- en CSCHED SAP-interfaces. A
Een vergelijkbare aanpak kan ook worden gebruikt om andere planners te implementeren. Een beschrijving van elk
van de planner-implementaties die wij leveren als onderdeel van onze LTE-simulatiemodule is
beschreven in de volgende subsecties.

Ronde roodborstje (RR) Scheduler
De Round Robin (RR)-planner is waarschijnlijk de eenvoudigste planner die in de literatuur wordt gevonden.
Het werkt door de beschikbare bronnen te verdelen over de actieve stromen, dat wil zeggen de logische stromen
kanalen die een niet-lege RLC-wachtrij hebben. Als het aantal RBG’s groter is dan de
aantal actieve stromen, kunnen alle stromen in hetzelfde subframe worden toegewezen. Anders, als
het aantal actieve stromen is groter dan het aantal RBG’s, niet alle stromen kunnen dat zijn
gepland in een bepaald subframe; vervolgens zal in het volgende subframe de toewijzing beginnen
de laatste stroom die niet is toegewezen. Het MCS dat voor elke gebruiker moet worden aangenomen, is klaar
volgens de ontvangen breedband-CQI's.

Voor wat betreft de HARQ implementeert RR de niet-adaptieve versie, wat impliceert dat in
het toewijzen van de hertransmissiepogingen RR gebruikt dezelfde toewijzingsconfiguratie als de
originele blok, wat betekent dat dezelfde RBG's en MCS behouden blijven. UE's waarvoor zijn toegewezen
HARQ-hertransmissies komen niet in aanmerking voor de transmissie van nieuwe gegevens, indien dit wel het geval is
een transmissiemogelijkheid die beschikbaar is in dezelfde TTI. Ten slotte kan HARQ worden uitgeschakeld met
ns3-attribuutsysteem voor het behouden van achterwaartse compatibiliteit met oude testgevallen en code,
in detail:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (false));

De planner implementeert het filteren van de uplink-CQI's op basis van hun aard
UlCqiFilter attribuut, in detail:

· SRS_UL_CQI: alleen op SRS gebaseerde CQI worden opgeslagen in de interne attributen.

· PUSCH_UL_CQI: alleen op PUSCH gebaseerde CQI worden opgeslagen in de interne attributen.

· ALL_UL_CQI: alle CQI's worden opgeslagen in hetzelfde interne attribuut (dat wil zeggen, de laatste CQI
ontvangen wordt onafhankelijk van zijn aard opgeslagen).

Proportioneel Eerlijk (FP) Scheduler
De Proportional Fair (PF)-planner [Sesia2009] werkt door een gebruiker te plannen wanneer deze
De momentane kanaalkwaliteit is hoog in verhouding tot de eigen gemiddelde kanaalconditie
tijd. Laat i,j generieke gebruikers aanduiden; laat t de subframe-index zijn, en k de hulpbron
blokindex; laat M_{i,k}(t) MCS zijn die bruikbaar is door gebruiker i op bronblok k, afhankelijk van wat
gerapporteerd door het AMC-model (zie Adaptieve Modulatie en codering); Laat tenslotte S(M, B) zijn
de TB-grootte in bits zoals gedefinieerd in [TS36213] voor het geval waarin een bronnummer B aanwezig is
blokken wordt gebruikt. De haalbare snelheid R_{i}(k,t) in bit/s voor gebruiker i in de resourceblokgroep
k op subframe t wordt gedefinieerd als

waarbij au de TTI-duur is. Aan het begin van elk subframe t wordt elke RBG toegewezen aan a
bepaalde gebruiker. In detail is de index 144}_{k}(t) waaraan RBG k is toegewezen op tijdstip t
bepaald als

waarbij T_{j}(t) de door de gebruiker j waargenomen prestatie in het verleden is. Volgens
Met het bovenstaande planningsalgoritme kan een gebruiker aan verschillende RBG's worden toegewezen
al dan niet aangrenzend, afhankelijk van de huidige toestand van het kanaal en het verleden
doorvoerprestaties T_{j}(t). Dit laatste wordt bepaald aan het einde van het subframe t
met behulp van de volgende exponentiële voortschrijdend-gemiddeldebenadering:

waarbij lpha de tijdconstante is (in aantal subframes) van de exponentiële beweging
gemiddelde, en 384s de daadwerkelijke doorvoer die door gebruiker i in het subframe t is bereikt. 360 wel
gemeten volgens de volgende procedure. Eerst bepalen we de MCS 840 j:

dan bepalen we het totaal aantal 936 j:

waar |

Voor wat betreft de HARQ implementeert PF de niet-adaptieve versie, wat impliceert dat in
Bij het toewijzen van de hertransmissiepogingen gebruikt de planner dezelfde toewijzing
configuratie van het oorspronkelijke blok, wat betekent dat dezelfde RBG's en MCS behouden blijven. UE's
die zijn toegewezen voor HARQ-heruitzendingen worden niet in aanmerking genomen voor de uitzending van nieuwe
gegevens indien zij in dezelfde TTI over een transmissiemogelijkheid beschikken. Tenslotte HARQ
kan worden uitgeschakeld met het ns3-attribuutsysteem om achterwaartse compatibiliteit met oud te behouden
testgevallen en code, in detail:

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

maximaal Doorvoer (MT) Scheduler
De Maximum Throughput (MT) planner [FCapo2012] heeft tot doel de algehele doorvoer te maximaliseren
van eNB. Het wijst elke RB toe aan de gebruiker die het maximaal haalbare tarief kan bereiken
de huidige TTI. Momenteel heeft MT-planner in NS-3 twee versies: frequentiedomein
(FDMT) en tijddomein (TDMT). In FDMT wijst elke TTI-, MAC-planner RBG's toe aan de UE
die het hoogst haalbare tarief heeft, berekend door subband CQI. In TDMT is elke TTI, MAC
de planner selecteert één UE met de hoogst haalbare snelheid, berekend door breedband-CQI.
Vervolgens wijst de MAC-planner alle RBG's toe aan deze UE in de huidige TTI. De berekening van
Het haalbare tarief in FDMT en TDMT is hetzelfde als dat in PF. Laat i,j generiek aanduiden
gebruikers; laat t de subframe-index zijn, en k de bronblokindex; laat M_{i,k}(t) zijn
MCS bruikbaar door gebruiker i op bronblok k volgens wat gerapporteerd wordt door het AMC-model (zie
Adaptieve Modulatie en codering); Laat ten slotte S(M, B) de TB-grootte in bits zijn, zoals gedefinieerd in
[TS36213] voor het geval waarin een aantal B-bronblokken wordt gebruikt. Het haalbare tarief
R_{i}(k,t) in bit/s voor gebruiker i op bronblok k op subframe t wordt gedefinieerd als

waarbij au de TTI-duur is. Aan het begin van elk subframe t wordt elke RB toegewezen aan a
bepaalde gebruiker. In detail is de index 144}_{k}(t) waaraan RB k is toegewezen op tijdstip t
bepaald als

Wanneer er meerdere UE's zijn met hetzelfde haalbare percentage, altijd de huidige implementatie
selecteert de eerste UE die in een script is gemaakt. Hoewel MT de celdoorvoer kan maximaliseren, is dit wel het geval
kan geen eerlijkheid bieden aan UE's in slechte kanaalconditie.

Doorvoer naar Gemiddelde (TTA) Scheduler
De Throughput to Average (TTA) planner [FCapo2012] kan als tussenproduct worden beschouwd
tussen MT en PF. De in TTA gebruikte statistiek wordt als volgt berekend:

Hier vertegenwoordigt R_{i}(k,t) in bit/s de haalbare snelheid voor gebruiker i op bronblok k op
subframe t. De berekeningsmethode wordt al weergegeven in MT en PF. Ondertussen R_{i}(t) binnen
bit/s staat voor de haalbare snelheid voor i op subframe t. Het verschil tussen die twee
haalbare tarieven is hoe u MCS kunt krijgen. Voor R_{i}(k,t) wordt MCS berekend door subband CQI while
R_{i}(t) wordt berekend door breedband-CQI. TTA-planner kan alleen in frequentie worden geïmplementeerd
domein (FD) omdat het haalbare percentage van een bepaalde RBG alleen gerelateerd is aan FD
het roosteren.

Blind Gemiddelde Doorvoer Scheduler
De Blind Average Throughput-planner [FCapo2012] heeft tot doel iedereen gelijke doorvoer te bieden
UE's onder eNB. De in TTA gebruikte statistiek wordt als volgt berekend:

waarbij T_{j}(t) de doorvoerprestatie uit het verleden is, waargenomen door gebruiker j en kan zijn
berekend met dezelfde methode in de PF-planner. In het tijddomein blinde gemiddelde doorvoer
(TD-BET), selecteert de planner de UE met de grootste prioriteitsmetriek en wijst alle RBG's toe
naar deze EU. Aan de andere kant, in het frequentiedomein blinde gemiddelde doorvoer (FD-BET),
elke TTI selecteert de planner eerst één UE met de laagste pastAverageThroughput (grootste
prioriteitsmetriek). Vervolgens wijst de planner één RBG toe aan deze UE en berekent de verwachte waarde
doorvoer van deze UE en gebruikt deze om te vergelijken met de gemiddelde doorvoer in het verleden T_{j}(t) van
andere EU's. De planner blijft RBG aan deze UE toewijzen totdat dit wordt verwacht
de doorvoer is niet de kleinste onder de gemiddelde doorvoer T_{j}(t) van alle UE. Dan
de planner zal op dezelfde manier RBG toewijzen aan een nieuwe UE met het laagste verleden
gemiddelde doorvoer T_{j}(t) totdat alle RBG's zijn toegewezen aan UE's. Het principe hierachter
is dat de planner bij elke TTI zijn best doet om een ​​gelijke doorvoersnelheid onder de teams te bereiken
alle UE's.

Token Bank Eerlijk Queue Scheduler
Token Bank Fair Queue (TBFQ) is een QoS-bewuste planner die voortkomt uit de lekkende bucket
mechanisme. In TBFQ wordt een verkeersstroom van gebruiker i gekenmerkt door de volgende parameters:

· t_{i}: aankomstsnelheid van pakketten (byte/sec)

· r_{i}: snelheid voor het genereren van tokens (byte/sec)

· p_{i}: tokenpoolgrootte (byte)

· E_{i}: teller die het aantal tokens registreert dat is geleend van of aan het token is gegeven
bank per stroom i; E_{i} kan kleiner zijn dan nul

Elke K bytes data verbruikt k tokens. Ook onderhoudt TBFQ een gedeelde tokenbank (B).
breng het verkeer in evenwicht tussen verschillende stromen. Als de tokengeneratiesnelheid r_{i} groter is dan
pakketaankomstsnelheid t_{i}, waarna tokens die overlopen uit de tokenpool, aan het token worden toegevoegd
bank, en E_{i} wordt met hetzelfde bedrag verhoogd. Anders moet flow i zich terugtrekken
tokens van tokenbank gebaseerd op een prioriteitsstatistiek frac{E_{i}}{r_{i}}, en E_{i} is
afgenomen. Het is duidelijk dat de gebruiker meer bijdraagt ​​aan de tokenbank en daar een hogere prioriteit aan heeft
penningen lenen; aan de andere kant leent de gebruiker meer tokens van de bank en heeft hij minder
prioriteit om door te gaan met het opnemen van tokens. Daarom, in het geval dat meerdere gebruikers de
dezelfde snelheid voor het genereren van tokens, verkeerssnelheid en tokenpoolgrootte, de gebruiker heeft last van een hogere snelheid
interferentie heeft meer mogelijkheden om tokens van de bank te lenen. Bovendien kan TBFQ toezicht houden
het verkeer door de tokengeneratiesnelheid in te stellen om de doorvoer te beperken. Aanvullend,
TBFQ onderhoudt ook de volgende drie parameters voor elke stroom:

· Schuldlimiet d_{i}: als E_{i} onder deze drempel komt, kan gebruiker i geen tokens meer lenen
van bank. Dit is bedoeld om te voorkomen dat kwaadwillende UE te veel tokens leent.

· Kredietlimiet c_{i}: het maximale aantal tokens UE i dat ik in één keer van de bank kan lenen
tijd.

· Kredietdrempel C: zodra E_{i} de schuldlimiet bereikt, moet UE i C-tokens opslaan bij de bank
om verder een token van de bank te lenen.

LTE in NS-3 heeft twee versies van de TBFQ-planner: frequentiedomein TBFQ (FD-TBFQ) en tijd
domein TBFQ (TD-TBFQ). In FD-TBFQ selecteert de planner altijd UE met de hoogste statistiek en
wijst RBG toe met de hoogste subband-CQI totdat er geen pakketten meer zijn in de RLC-buffer van UE
of alle RBG's worden toegewezen [FABokhari2009]. In TD-TBFQ, na het selecteren van UE met maximum
Metriek wijst het alle RBG's toe aan deze UE met behulp van breedband-CQI [WKWong2004].

Prioriteit Zet de Scheduler
Priority Set Scheduler (PSS) is een QoS-bewuste planner die tijddomein (TD) en
frequentiedomein (FD) pakketplanningsbewerkingen in één planner [GMonghal2008]. Het
controleert de eerlijkheid tussen UE's door een gespecificeerde Target Bit Rate (TBR).

In het TD-plannergedeelte selecteert PSS eerst UE's met een niet-lege RLC-buffer en verdeelt ze vervolgens
in twee sets op basis van de TBR:

· set 1: UE waarvan de gemiddelde doorvoer in het verleden kleiner is dan TBR; TD-planner berekent
hun prioriteitsstatistiek in Blind Equal Throughput (BET)-stijl:

· set 2: UE waarvan de gemiddelde doorvoer in het verleden groter (of gelijk) is dan TBR; TD-planner
berekent hun prioriteitsmetriek in Proportional Fair (PF)-stijl:

UE's uit set 1 hebben een hogere prioriteit dan die uit set 2. Vervolgens zal PSS selecteren
N_{mux} UE's met de hoogste statistiek in twee sets en stuur deze UE door naar de FD-planner. Bij PSS,
De FD-planner wijst RBG k toe aan UE n die de gekozen metriek maximaliseert. Twee PF-planners
worden gebruikt in de PF-planner:

· Proportioneel Fair gepland (PFsch)

· Drager boven interferentie met het gemiddelde (CoIta)

waarbij Tsch_{j}(t) een vergelijkbare doorvoerprestatie uit het verleden is, waargenomen door gebruiker j, met de
verschil dat het alleen wordt bijgewerkt wanneer de i-de gebruiker daadwerkelijk wordt bediend. CoI[j,k] is een
schatting van de SINR op de RBG k van UE j. Zowel PFsch als CoIta zijn bedoeld voor het ontkoppelen van FD
statistiek van TD-planner. Daarnaast biedt de PSS FD-planner ook een gewichtsmetriek W[n]
voor het helpen controleren van de eerlijkheid in het geval van een laag aantal EU's.

waarbij T_{j}(t) de doorvoerprestatie uit het verleden is, waargenomen door de gebruiker j . Daarom op
RBG k, de FD-planner selecteert de UE j die het product van de frequentie maximaliseert
domeinmetriek (Msch, MCoI) op basis van gewicht W[n]. Deze strategie garandeert de doorvoer van
UE van lagere kwaliteit neigen naar de TBR.

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

De planner implementeert het filteren van de uplink-CQI's op basis van hun aard
UlCqiFilter attribuut, in detail:

· SRS_UL_CQI: alleen op SRS gebaseerde CQI worden opgeslagen in de interne attributen.

· PUSCH_UL_CQI: alleen op PUSCH gebaseerde CQI worden opgeslagen in de interne attributen.

· ALL_UL_CQI: alle CQI's worden opgeslagen in hetzelfde interne attribuut (dat wil zeggen, de laatste CQI
ontvangen wordt onafhankelijk van zijn aard opgeslagen).

Kanaal en QoS Bewust Scheduler
De Channel and QoS Aware (CQA) Scheduler [Bbojovic2014] is een LTE MAC-downlinkplanning
algoritme dat rekening houdt met de Head of Line (HOL)-vertraging, de GBR-parameters en het kanaal
kwaliteit over verschillende subbanden. De CQA-planner is gebaseerd op gezamenlijke TD- en FD-planning.

In de TD (bij elke TTI) groepeert de CQA-planner gebruikers op prioriteit. Het doel van
groepering is bedoeld om de FD-planning af te dwingen, waarbij eerst de stromen met de hoogste HOL in aanmerking worden genomen
vertraging. De groeperingsmetriek m_{td} voor gebruiker j=1,...,N wordt op de volgende manier gedefinieerd:

waarbij d_{hol}^{j}(t) de huidige waarde is van de HOL-vertraging van stroom j, en g een groepering is
parameter die de granulariteit van de groepen bepaalt, dwz het aantal stromen dat
zal worden meegenomen in de FD-planningsiteratie.

De groepen stromen die in de TD-iteratie zijn geselecteerd, worden doorgestuurd naar de FD-planning
beginnend bij de stromen met de hoogste waarde van de m_{td}-metriek totdat alle RBG's dat zijn
toegewezen in de overeenkomstige TTI. In de FD is voor elke RBG k=1,...,K de CQA-planner
wijst de huidige RBG toe aan gebruiker j die de maximale waarde heeft van de FD-metriek die we hebben
definieer op de volgende manier:

waarbij m_{GBR}^j(t) als volgt wordt berekend:

waarbij GBR^j de bitsnelheid is die is gespecificeerd in de EPS-drager van de stroom j, rie R j ( ) shps aerageerde doorvoer die
wordt berekend met een voortschrijdend gemiddelde, r^{j}(t) is de doorvoer die op tijdstip t is bereikt,
en lpha is een coëfficiënt zodat 0 lpha ..sp Voor m_{ca}^{(k,j)}(t) beschouwen we twee
verschillende statistieken: m_{pf}^{(k,j)}(t) en m_{ff}^{(k,j)}(t). m_{pf} is proportioneel
Eerlijke maatstaf die als volgt wordt gedefinieerd:

waarbij R_e^{(k,j)}(t) de geschatte haalbare doorvoer van gebruiker j over RBG k is
berekend door het Adaptive Modulation and Coding (AMC)-schema dat het kanaal in kaart brengt
kwaliteitsindicator (CQI)-waarde voor de transportblokgrootte in bits.

De andere kanaalbekendheidsstatistiek die we overwegen is m_{ff}, die wordt voorgesteld in
[GMonghal2008] en vertegenwoordigt de frequentieselectieve fadingversterking ten opzichte van RBG k voor de gebruiker
j en wordt op de volgende manier berekend:

waarbij CQI^{(k,j)}(t) de laatst gerapporteerde CQI-waarde is van gebruiker j voor de k-de RBG.

De gebruiker kan selecteren of m_{pf} of m_{ff} wordt gebruikt door het attribuut in te stellen
ns3::CqaFfMacScheduler::CqaMetric respectievelijk aan "CqaPf" or "CqaFf".

Random Toegang tot
Het LTE-model bevat een model van de Random Access-procedure, gebaseerd op enkele vereenvoudigingen
aannames, die hieronder voor elk van de berichten en signalen worden beschreven
beschreven in de specificaties [TS36321].

· Random Toegang tot (KIKKER) preambule: in echte LTE-systemen komt dit overeen met een Zadoff-Chu
(ZC)-reeks met behulp van een van de verschillende formaten die beschikbaar zijn en worden verzonden in de PRACH-slots
die in principe met PUSCH zouden kunnen overlappen. PRACH-configuratie-index 14 is
Er wordt aangenomen dat preambules kunnen worden verzonden op elk systeemframenummer en subframenummer.
De RA-preambule wordt gemodelleerd met behulp van de klasse LteControlMessage, dwz als een ideaal
bericht dat geen radiobronnen verbruikt. De botsing van de preambule
transmissie door meerdere UE's in dezelfde cel worden gemodelleerd met behulp van een protocol
interferentiemodel, dat wil zeggen wanneer twee of meer identieke preambules worden verzonden
dezelfde cel op dezelfde TTI, zal geen van deze identieke preambules worden ontvangen
de eNB. Behalve dit botsingsmodel is er geen foutenmodel geassocieerd met de
ontvangst van een RA-preambule.

· Random Toegang tot antwoord (RAR): bij echte LTE-systemen is dit een speciale MAC PDU die wordt doorgestuurd
de DL-SCH. Omdat MAC-besturingselementen in de simulator niet nauwkeurig worden gemodelleerd
(alleen RLC en hogere PDU's zijn dat), de RAR wordt gemodelleerd als een LteControlMessage die dat wel doet
verbruiken geen radiobronnen. Toch zal de LteEnbMac dat tijdens de RA-procedure wel doen
verzoek aan de planner om de toewijzing van bronnen voor de RAR met behulp van de FF MAC
Planner primitief SCHED_DL_RACH_INFO_REQ. Daarom een ​​verbeterde planner
implementatie (momenteel niet beschikbaar) zou radiobronnen kunnen toewijzen voor de
RAR, waardoor het verbruik van radiobronnen voor de transmissie van de
ARR.

· Bericht 3: in echte LTE-systemen is dit een RLC TM SDU die via de opgegeven bronnen wordt verzonden
in de UL Grant in de RAR. In de simulator wordt dit gemodelleerd als een echte RLC TM RLC
PDU waarvan de UL-bronnen bij oproep door de planner worden toegewezen
SCHED_DL_RACH_INFO_REQ.

· bewering Resolutie (CR): in een echt LTE-systeem is de CR-fase nodig om de problemen aan te pakken
geval waarin twee of meer UE dezelfde RA-preambule in dezelfde TTI stuurden, en de eNB dat wel was
ondanks de botsing deze preambule kon detecteren. Omdat dit evenement dat niet doet
optreden als gevolg van het protocolinterferentiemodel dat wordt gebruikt voor de ontvangst van RA-preambules,
de CR-fase wordt niet gemodelleerd in de simulator, dwz de CR MAC CE wordt nooit verzonden
de eNB en de EU's beschouwen de RA als succesvol bij ontvangst van de RAR. Als een
bijgevolg zijn de radiobronnen die worden verbruikt voor de transmissie van de CR MAC CE
niet gemodelleerd.

Figuur Volgorde diagram of the Op controverse gebaseerd MAC-adres Random Toegang tot procedures en Volgorde
diagram of the Niet op conflicten gebaseerd MAC-adres Random Toegang tot procedures toont de volgorde
diagrammen van respectievelijk de op conflicten gebaseerde en niet-op conflicten gebaseerde willekeurige MAC-toegang
procedure, waarbij de interacties tussen de MAC en de andere entiteiten worden benadrukt.
[afbeelding] Volgordediagram van de op contentie gebaseerde MAC Random Access-procedure.UNINDENT
[afbeelding] Volgordediagram van de niet-conflictgebaseerde MAC Random Access
procedure.UNINDENT

RLC
Overzicht
De RLC-entiteit wordt gespecificeerd in de technische specificatie van 3GPP [TS36322] en omvat:
drie verschillende soorten RLC: Transparent Mode (TM), Unacknowledge Mode (UM) en
Bevestigde modus (AM). De simulator bevat één model voor elk van deze entiteiten

De RLC-entiteiten verschaffen de RLC-service-interface voor de bovenste PDCP-laag en de MAC
service-interface naar de onderste MAC-laag. De RLC-entiteiten gebruiken de PDCP-service-interface
van de bovenste PDCP-laag en de MAC-service-interface van de onderste MAC-laag.

Figuur Implementatie Model of PDCP, RLC en MAC-adres entiteiten en SAP's toont de
implementatiemodel van de RLC-entiteiten en de relatie ervan met alle andere entiteiten
en services in de protocolstack.
[afbeelding] Implementatiemodel van PDCP-, RLC- en MAC-entiteiten en SAP's.UNINDENT

Service interfaces
RLC Service Interface
De RLC-service-interface is verdeeld in twee delen:

· de RlcSapProvider een deel wordt geleverd door de RLC-laag en gebruikt door de bovenste PDCP-laag
en

· de RlcSapGebruiker een deel wordt geleverd door de bovenste PDCP-laag en gebruikt door de RLC-laag.

Zowel de UM- als de AM RLC-entiteiten bieden dezelfde RLC-service-interface naar het hogere niveau
PDCP-laag.

RLC Service Primitieven
De volgende lijst geeft aan welke serviceprimitieven door de RLC-service worden geleverd
interfaces:

· RlcSapProvider::VerzendPdcpPdu

· De PDCP-entiteit gebruikt deze primitief om een ​​PDCP-PDU naar de lagere RLC-entiteit te sturen
in de zenderpeer

· RlcSapGebruiker::ReceivePdcpPdu

· De RLC-entiteit gebruikt deze primitief om een ​​PDCP-PDU naar de bovenste PDCP-entiteit te sturen
in de ontvanger-peer

MAC-adres Service Interface
De MAC-service-interface is verdeeld in twee delen:

· de MacSapProvider een deel wordt geleverd door de MAC-laag en gebruikt door de bovenste RLC-laag
en

· de MacSap-gebruiker een deel wordt geleverd door de bovenste RLC-laag en gebruikt door de MAC-laag.

MAC-adres Service Primitieven
De volgende lijst geeft aan welke serviceprimitieven door de MAC-service worden geleverd
interfaces:

· MacSapProvider::TransmitPdu

· De RLC-entiteit gebruikt deze primitief om een ​​RLC PDU naar de lagere MAC-entiteit te sturen
de zender-peer

· MacSapProvider::ReportBufferStatus

· De RLC-entiteit gebruikt deze primitief om de MAC-entiteit de omvang van de aanvraag te rapporteren
buffers in de zenderpeer

· MacSapGebruiker::NotifyTxOpportunity

· De MAC-entiteit gebruikt deze primitief om de RLC-entiteit een transmissie te melden
kansen

· MacSapGebruiker::ReceivePdu

· De MAC-entiteit gebruikt deze primitief om een ​​RLC PDU naar de bovenste RLC-entiteit te sturen
in de ontvanger-peer

AM RLC
De verwerking van de gegevensoverdracht in de Acknowledge Mode (AM) RLC-entiteit wordt uitgelegd
in sectie 5.1.3 van [TS36322]. In deze sectie beschrijven we enkele details van de
implementatie van de RLC-entiteit.

buffers voor the overdragen operaties
Onze implementatie van de AM RLC-entiteit onderhoudt 3 buffers voor de verzendbewerkingen:

· transmissie Buffer: het is de RLC SDU-wachtrij. Wanneer de AM RLC-entiteit een SDU ontvangt
in de TransmitPdcpPdu-serviceprimitief van de bovenste PDCP-entiteit wordt deze in de wachtrij geplaatst
in de transmissiebuffer. We hebben een limiet gesteld aan de RLC-buffergrootte en dat gewoon in stilte
laat SDU's vallen als de buffer vol is.

· Overgedragen PDU's Buffer: het is de wachtrij van verzonden RLC PDU's waarvoor een
ACK/NACK is nog niet ontvangen. Wanneer de AM RLC-entiteit een PDU naar de MAC stuurt
entiteit, plaatst deze ook een kopie van de verzonden PDU in de verzonden PDU-buffer.

· heruitzending Buffer: het is de wachtrij van RLC PDU's waarvoor in aanmerking komt
doorgifte (dat wil zeggen, ze zijn NACKed). De AM RLC-entiteit verplaatst deze PDU naar de
Hertransmissiebuffer, wanneer deze een PDU opnieuw verzendt vanuit de verzonden buffer.

Overbrengen operaties in downlink
Het volgende sequentiediagram toont de interacties tussen de verschillende entiteiten (RRC,
PDCP, AM RLC, MAC en MAC-planner) van de eNB in ​​de downlink om gegevens uit te voeren
communicatie.

Figuur Volgorde diagram of gegevens PDU transmissie in downlink laat zien hoe de bovenste lagen
gegevens-PDU's verzenden en hoe de gegevensstroom wordt verwerkt door de verschillende entiteiten/diensten van
de LTE-protocolstack.
[afbeelding] Volgordediagram van data-PDU-transmissie in downlink.UNINDENT

De PDCP-entiteit roept de Verzend_PDCP_PDU service primitief om gegevens te verzenden
PDU. De AM RLC-entiteit verwerkt deze dienstprimitief volgens de AM-gegevens
overdrachtsprocedures gedefinieerd in sectie 5.1.3 van [TS36322].

Wanneer de Verzend_PDCP_PDU serviceprimitief wordt aangeroepen, voert de AM RLC-entiteit de opdracht uit
volgende bewerkingen:

· Plaats de gegevens-SDU in de transmissiebuffer.

· Bereken de grootte van de buffers (hoe de grootte van de buffers wordt berekend zal zijn).
achteraf uitgelegd).

· Bel de Rapport_Buffer_Status service primitief van de eNB MAC-entiteit om dit te doen
de eNB MAC-entiteit op de hoogte stellen van de omvang van de buffers van de AM RLC-entiteit. Dan de
eNB MAC-entiteit werkt de bufferstatus in de MAC-planner bij met behulp van de
SchedDlRlcBufferReq-serviceprimitief van de FF MAC Scheduler API.

Daarna, wanneer de MAC-planner besluit dat bepaalde gegevens kunnen worden verzonden, wordt de MAC-entiteit
meldt dit aan de RLC-entiteit, dat wil zeggen dat het de Notify_Tx_Opportunity dienst primitief,
Vervolgens doet de AM RLC-entiteit het volgende:

· Creëer één data-PDU door de SDU's in de segmenten en/of aaneen te schakelen
Transmissiebuffer.

· Verplaats de gegevens-PDU van de transmissiebuffer naar de verzonden PDU-buffer.

· Update statusvariabelen volgens paragraaf 5.1.3.1.1 van [TS36322].

· Bel de Verzend_PDU primitief om de data-PDU naar de MAC-entiteit te sturen.

heruitzending in downlink
Het sequentiediagram van figuur Volgorde diagram of gegevens PDU doorgifte in downlink
toont de interacties tussen de verschillende entiteiten (AM RLC, MAC en MAC-planner) van
de eNB in ​​downlink wanneer data-PDU's opnieuw moeten worden verzonden door de AM RLC-entiteit.
[afbeelding] Volgordediagram van gegevens-PDU-hertransmissie in downlink.UNINDENT

De verzendende AM RLC-entiteit kan STATUS PDU's ontvangen van de gelijkwaardige AM RLC-entiteit.
STATUS-PDU's worden verzonden overeenkomstig sectie 5.3.2 van [TS36322] en de verwerking van
ontvangst vindt plaats volgens sectie 5.2.1 van [TS36322].

Wanneer een data-PDU opnieuw wordt verzonden vanuit de verzonden PDU-buffer, wordt deze ook verplaatst naar
de hertransmissiebuffer.

Overbrengen operaties in uplink
Het sequentiediagram van figuur Volgorde diagram of gegevens PDU transmissie in uplink shows
de interacties tussen de verschillende entiteiten van de UE (RRC, PDCP, RLC en MAC) en de
eNB (MAC en Scheduler) in uplink wanneer data-PDU's door de bovenste lagen worden verzonden.
[afbeelding] Volgordediagram van data-PDU-transmissie in uplink.UNINDENT

Het is vergelijkbaar met het sequentiediagram in downlink; het belangrijkste verschil is dat hierin
In dat geval wordt de Report_Buffer_Status verzonden van de UE MAC naar de MAC Scheduler in de eNB
via de lucht met behulp van het controlekanaal.

heruitzending in uplink
Het sequentiediagram van figuur Volgorde diagram of gegevens PDU doorgifte in uplink shows
de interacties tussen de verschillende entiteiten van de UE (AM RLC en MAC) en de eNB
(MAC) in uplink wanneer data-PDU's opnieuw moeten worden verzonden door de AM RLC-entiteit.
[afbeelding] Volgordediagram van gegevens-PDU-hertransmissie in uplink.UNINDENT

Berekening of the buffer grootte
De transmissiebuffer bevat RLC SDU's. Een RLC PDU bestaat uit een of meer SDU-segmenten plus een
RLC-kop. De grootte van de RLC-header van één RLC PDU is afhankelijk van het aantal SDU
segmenten die de PDU bevat.

De 3GPP-standaard (sectie 6.1.3.1 van [TS36321]) zegt duidelijk dat voor de uplink de
RLC- en MAC-headers worden niet meegenomen in de buffergrootte waarvan gerapporteerd moet worden
het bufferstatusrapport. Voor de downlink is het gedrag niet gespecificeerd. Geen van beide
[FFAPI] geeft aan hoe dit moet worden gedaan. Ons RLC-model werkt door aan te nemen dat de berekening van
de buffergrootte in de downlink wordt precies zo gedaan als in de uplink, dwz zonder rekening te houden
de RLC- en MAC-headergrootte.

We merken op dat deze keuze invloed heeft op de samenwerking met de MAC-planner, aangezien in
reactie op de Notify_Tx_Opportunity service primitief, wordt verwacht dat de RLC een
PDU van niet meer dan de door de MAC gevraagde grootte, inclusief RLC-overhead. Onnodig dus
fragmentatie kan optreden als (bijvoorbeeld) de MAC een transmissie meldt die exact gelijk is aan
de buffergrootte die eerder door de RLC werd gerapporteerd. We gaan ervan uit dat dit aan de Scheduler wordt overgelaten
slimme strategieën implementeren voor de selectie van de omvang van de transmissie
kansen te benutten, om uiteindelijk de inefficiëntie van onnodige fragmentatie te voorkomen.

Aaneenschakeling en Segmentatie
De AM RLC-entiteit genereert en verzendt voor elke transmissie precies één RLC PDU
mogelijkheid, ook al is deze kleiner dan de omvang die door de transmissiemogelijkheid wordt gerapporteerd.
Als er bijvoorbeeld een STATUS-PDU moet worden verzonden, wordt alleen deze PDU daarin verzonden
transmissie mogelijkheid.

De segmentatie en aaneenschakeling voor de SDU-wachtrij van de AM RLC-entiteit volgt hetzelfde
filosofie als dezelfde procedures van de UM RLC-entiteit, maar er zijn nieuwe statusvariabelen
(zie [TS36322] sectie 7.1) alleen aanwezig in de AM RLC-entiteit.

Opgemerkt wordt dat er volgens de 3GPP-specificaties geen aaneenschakeling is voor de
Buffer voor hertransmissie.

Opnieuw segmenteren
Het huidige model van de AM RLC-entiteit ondersteunt de hersegmentatie van de
hertransmissiebuffer. In plaats daarvan wacht de AM RLC-entiteit gewoon op een voldoende groot bedrag
transmissie mogelijkheid.

niet gesteund functionaliteiten
We ondersteunen de volgende procedures van [TS36322] niet:

· “Stuur een indicatie van succesvolle levering van RLC SDU” (zie sectie 5.1.3.1.1)

· “Geef aan de bovenste lagen aan dat de maximale hertransmissie is bereikt” (zie sectie
5.2.1)

· “SDU-wegwerpprocedures” (zie paragraaf 5.3)

· “Herstelprocedure” (zie rubriek 5.4)

We ondersteunen geen van de aanvullende primitieven van RLC SAP voor AM RLC-entiteit. In
bijzonder:

· geen SDU-teruggooi gemeld door PDCP

· geen melding van succesvolle/mislukte levering door AM RLC-entiteit aan PDCP-entiteit

UM RLC
In deze sectie beschrijven we de implementatie van de RLC-entiteit Unacknowledge Mode (UM).

Overbrengen operaties in downlink
De zendoperaties van de UM RLC zijn vergelijkbaar met die van de AM RLC voorheen
beschreven in Sectie Overbrengen operaties in downlink, met het verschil dat, volgend
de specificaties van [TS36322], wordt er geen hertransmissie uitgevoerd en is er geen STATUS
PDU's.

Overbrengen operaties in uplink
De zendbewerkingen in de uplink zijn vergelijkbaar met die van de downlink, met de hoofdverbinding
verschil dat de Report_Buffer_Status wordt verzonden van de UE MAC naar de MAC Scheduler
de eNB via de ether met behulp van het besturingskanaal.

Berekening of the buffer grootte
De berekening van de buffergrootte voor de UM RLC wordt gedaan met behulp van dezelfde aanpak als de
AM RLC, zie sectie Berekening of the buffer grootte voor de overeenkomstige
Beschrijving.

TM RLC
In deze sectie beschrijven we de implementatie van de Transparent Mode (TM) RLC-entiteit.

Overbrengen operaties in downlink
In de simulator biedt de TM RLC nog steeds dezelfde service-interface aan de bovenste lagen
geleverd door de AM- en UM RLC-entiteiten aan de PDCP-laag; in de praktijk is deze interface dat wel
gebruikt door een RRC-entiteit (geen PDCP-entiteit) voor de overdracht van RLC SDU's. Deze keuze is
gemotiveerd door het feit dat de diensten die door de TM RLC aan de bovenste lagen worden geleverd,
volgens [TS36322], is een subset van de entiteiten die door de UM- en AM RLC-entiteiten aan de
PDCP-laag; daarom hebben we voor de eenvoud dezelfde interface hergebruikt.

De verzendbewerkingen in de downlink worden als volgt uitgevoerd. Wanneer de
Verzend_PDCP_PDU service primitief wordt aangeroepen door de bovenste lagen, de TM RLC doet het
volgende:

· plaats de SDU in de transmissiebuffer

· bereken de grootte van de transmissiebuffer

· bel de Rapport_Buffer_Status serviceprimitief van de eNB MAC-entiteit

Daarna, wanneer de MAC-planner besluit dat sommige gegevens door de logische kunnen worden verzonden
kanaal waartoe de TM RLC-entiteit behoort, meldt de MAC-entiteit dit aan de TM RLC
entiteit door te bellen naar de Notify_Tx_Opportunity dienst primitief. Na ontvangst hiervan
primitief, doet de TM RLC-entiteit het volgende:

· als de TX-mogelijkheid een omvang heeft die groter is dan of gelijk is aan de omvang van de
hoofd-of-line SDU in de transmissiebuffer

· Haal de hoofd-SDU uit de transmissiebuffer

· maak één RLC PDU die geheel die SDU bevat, zonder enige RLC-header

· Bel de Verzend_PDU primitief om de RLC PDU naar de MAC-entiteit te sturen.

Overbrengen operaties in uplink
De zendbewerkingen in de uplink zijn vergelijkbaar met die van de downlink, met de hoofdverbinding
met dit verschil dat ook uit de opdracht van de UB een transmissiemogelijkheid kan voortvloeien
GRANT als onderdeel van de Random Access-procedure, zonder expliciet bufferstatusrapport
uitgegeven door de TM RLC-entiteit.

Berekening of the buffer grootte
Volgens de specificaties [TS36322] voegt de TM RLC geen RLC-header toe aan de PDU's
wordt verzonden. Hierdoor is de buffergrootte die aan de MAC-laag wordt gerapporteerd gelijk
eenvoudigweg berekend door de grootte van alle pakketten in de transmissiebuffer op te tellen
het doorgeven aan de MAC van de exacte buffergrootte.

SM RLC
Naast de AM-, UM- en TM-implementaties die zijn gemodelleerd naar de 3GPP
specificaties is er een vereenvoudigd RLC-model beschikbaar, genaamd Saturation Mode (SM)
RLC. Dit RLC-model accepteert geen PDU's van een bovenstaande laag (zoals PDCP); eerder de
SM RLC verzorgt het genereren van RLC PDU's naar aanleiding van de melding van
transmissiemogelijkheden gemeld door de MAC. Met andere woorden, de SM RLC simuleert
verzadigingsomstandigheden, dwz er wordt van uitgegaan dat de RLC-buffer altijd vol is en dat ook kan
een nieuwe PDU genereren wanneer de planner hiervan op de hoogte wordt gesteld.

De SM RLC wordt gebruikt voor vereenvoudigde simulatiescenario's waarin alleen het LTE Radio-model wordt gebruikt
wordt gebruikt, zonder de EPC en dus zonder enige IP-netwerkondersteuning. We noteren dat,
Hoewel de SM RLC een onrealistisch verkeersmodel is, is er nog steeds ruimte voor het juiste verkeersmodel
simulatie van scenario's met meerdere stromen die tot verschillende (niet-realtime) QoS behoren
klassen, om de QoS-prestaties te testen die door verschillende planners worden verkregen. Dit kan
omdat het de taak van de Scheduler is om transmissiebronnen toe te wijzen op basis van
de kenmerken (bijvoorbeeld gegarandeerde bitsnelheid) van elke radiodrager, die zijn gespecificeerd
op basis van de definitie van elke drager binnen het simulatieprogramma.

Wat betreft planners die zijn ontworpen om te werken met realtime QoS-verkeer dat vertragingsbeperkingen kent,
de SM RLC is waarschijnlijk geen geschikte keuze. Dit komt door het ontbreken van feitelijk
RLC SDU's (vervangen door de kunstmatige generatie van bufferstatusrapporten) maken dit niet mogelijk
Het is mogelijk om de Scheduler te voorzien van betekenisvolle informatie over vertragingen in de hoofdlijn
vaak de voorkeursmaatstaf voor de implementatie van planningsbeleid voor realtime
verkeersstromen. Voor het simuleren en testen van dergelijke planners is het raadzaam om gebruik te maken van
in plaats daarvan de UM- of de AM RLC-modellen.

PDCP
PDCP Model Overzicht
Het referentiedocument voor de specificatie van de PDCP-entiteit is [TS36323]. Met respect
Volgens deze specificatie ondersteunt het PDCP-model dat in de simulator is geïmplementeerd alleen de
volgende kenmerken:

· overdracht van gegevens (gebruikersvlak of besturingsvlak);

· onderhoud van PDCP SN's;

· overdracht van SN-status (voor gebruik bij overdracht);

De volgende functies worden momenteel niet ondersteund:

· headercompressie en decompressie van IP-gegevensstromen met behulp van het ROHC-protocol;

· achtereenvolgende levering van PDU's van de bovenste laag bij het herstel van de onderste lagen;

· dubbele eliminatie van SDU's uit de lagere lagen bij het herstel van lagere lagen voor
radiodragers in kaart gebracht op RLC AM;

· het coderen en ontcijferen van gebruikers- en besturingsgegevens;

· integriteitsbescherming en integriteitsverificatie van control plane-gegevens;

· op timer gebaseerd weggooien;

· duplicaat weggooien.

PDCP Service Interface
De PDCP-service-interface is verdeeld in twee delen:

· de PdcpSapProvider een deel wordt geleverd door de PDCP-laag en gebruikt door de bovenste laag
en

· de PdcpSapgebruiker een deel wordt geleverd door de bovenste laag en gebruikt door de PDCP-laag.

PDCP Service Primitieven
De volgende lijst geeft aan welke serviceprimitieven door de PDCP-service worden geleverd
interfaces:

· PdcpSapProvider::PdcpSdu verzenden

· De RRC-entiteit gebruikt deze primitief om een ​​RRC-PDU naar de lagere PDCP-entiteit te sturen
in de zenderpeer

· PdcpSapGebruiker::OntvangPdcpSdu

· De PDCP-entiteit gebruikt deze primitief om een ​​RRC PDU naar de bovenste RRC-entiteit te sturen
in de ontvanger-peer

RRC
Kenmerken
Het in de simulator geïmplementeerde RRC-model biedt de volgende functionaliteit:

· genereren (bij de eNB) en interpretatie (bij de UE) van systeeminformatie (in
met name het Masterinformatieblok en, op het moment van schrijven, alleen System
Informatieblok type 1 en 2)

· initiële celselectie

· Procedure voor het tot stand brengen van een RRC-verbinding

· RRC-herconfiguratieprocedure, ter ondersteuning van de volgende gebruiksscenario's: + herconfiguratie
van de SRS-configuratie-index + herconfiguratie van de PHY TX-modus (MIMO) +
herconfiguratie van UE-metingen + instellen van gegevensradiodrager + overdracht

· Herstel van de RRC-verbinding, ter ondersteuning van de volgende gebruiksscenario's: + overdracht

Architectuur
Het RRC-model is onderverdeeld in de volgende componenten:

· de RRC-entiteiten LteUeRrc en LteEnbRrc, die de staatsmachines van de implementeren
RRC-entiteiten bij respectievelijk de UE en de eNB;

· de RRC SAP's LteUeRrcSapProvider, LteUeRrcSapGebruiker, LteEnbRrcSapProvider,
LteEnbRrcSapUser, waarmee de RRC-entiteiten RRC-berichten kunnen verzenden en ontvangen
informatie-elementen;

· de RRC-protocolklassen LteUeRrcProtocolIdeal, LteEnbRrcProtocolIdeal,
LteUeRrcProtocolReal, LteEnbRrcProtocolReal, die twee verschillende modellen implementeren voor
de verzending van RRC-berichten.

Bovendien gebruiken de RRC-componenten verschillende andere SAP's om met de rest te communiceren
van de protocolstack. Een weergave van alle SAP's die worden gebruikt, vindt u in de
cijfers LTE radio protocol stack architectuur voor the UE on the gegevens vliegtuig, LTE radio
protocol stack architectuur voor the UE on the onder controle te houden vliegtuig, LTE radio protocol stack
architectuur voor the eNB on the gegevens vliegtuig en LTE radio protocol stack architectuur voor
the eNB on the onder controle te houden vliegtuig.

UE RRC Land Machine
In figuur UE RRC Land Machine we vertegenwoordigen de toestandsmachine zoals geïmplementeerd in de RRC UE
entiteit.
[afbeelding] UE RRC State Machine.UNINDENT

Opgemerkt moet worden dat de meeste staten van voorbijgaande aard zijn, dat wil zeggen zodra de EU er één wordt
van de CONNECTED-staten zal het nooit meer terugkeren naar een van de IDLE-staten. Deze keuze
wordt gedaan om de volgende redenen:

· zoals besproken in de sectie Design criteria, de focus van de LTE-EPC-simulatie
het model staat in de VERBONDEN-modus

· Het falen van een radioverbinding wordt momenteel niet gemodelleerd, zoals besproken in de sectie Radio Link
Storing, dus een UE kan niet IDLE gaan vanwege een mislukte radioverbinding

· Het vrijgeven van de RRC-verbinding wordt momenteel nooit geactiveerd, noch door de EPC, noch door de NAS

Toch hebben we ervoor gekozen om de IDLE-toestanden expliciet te modelleren, omdat:

· er is een realistische UE RRC-configuratie nodig voor overdracht, wat een vereiste functie is,
en voor een schonere implementatie is het zinvol om dezelfde UE RRC te gebruiken
configuratie ook voor het tot stand brengen van de eerste verbinding

· het maakt het eenvoudiger om in de toekomst celselectie in de inactieve modus te implementeren, wat a
zeer wenselijke eigenschap

ENB RRC Land Machine
De eNB RRC houdt de status bij van elke UE die aan de cel is gekoppeld. Van een
Vanuit het oogpunt van implementatie is de status van elke UE vervat in een exemplaar van de
UeManager-klasse. De toestandsmachine wordt weergegeven in figuur ENB RRC Land Machine voor elk
UE.
[image] ENB RRC State Machine voor elke UE.UNINDENT

Eerste Cel Selectie
De initiële celselectie is een procedure in de IDLE-modus, die door UE wordt uitgevoerd wanneer dit nog niet het geval is
gekampeerd of verbonden met een eNodeB. Het doel van de procedure is het vinden van een geschikte cel
en maak er verbinding mee om toegang te krijgen tot het mobiele netwerk.

Dit gebeurt doorgaans aan het begin van de simulatie, zoals weergegeven in figuur Sample loopt of
eerste cel selectie in UE en timing of verwant EVENTS onderstaand. Het tijddiagram op de
linkerkant illustreert het geval waarin de initiële celselectie bij de eerste poging slaagt,
terwijl het diagram aan de rechterkant bedoeld is voor het geval dat het bij de eerste poging mislukt
succes bij de tweede poging. De timing veronderstelt het gebruik van een echt RRC-protocolmodel (zie RRC
protocol modellen) en geen transmissiefout.
[afbeelding] Voorbeeldruns van initiële celselectie in UE en timing van gerelateerde
evenementen.UNINDENT

De functionaliteit is gebaseerd op 3GPP IDLE-modusspecificaties, zoals in [TS36300],
[TS36304] en [TS36331]. Een goede implementatie van de IDLE-modus ontbreekt echter nog steeds
in de simulator, dus we reserveren een aantal vereenvoudigende aannames:

· meerdere draaggolffrequenties worden niet ondersteund;

· meerdere PLMN-identiteiten (Public Land Mobile Network) (dwz meerdere netwerken).
operators) wordt niet ondersteund;

· RSRQ-metingen worden niet gebruikt;

· selectie van opgeslagen informatiecellen wordt niet ondersteund;

· De status "Elke celselectie" en kamperen naar een acceptabele cel worden niet ondersteund;

· het markeren van een cel als geblokkeerd of gereserveerd wordt niet ondersteund;

· celherselectie wordt niet ondersteund, daarom is het voor UE niet mogelijk om naar a te kamperen
andere cel nadat het eerste kamp is geplaatst; En

· De witte lijst van de Closed Subscriber Group (CSG) van UE bevat slechts één CSG-identiteit.

Houd er ook rekening mee dat de initiële celselectie alleen beschikbaar is voor EPC-compatibele simulaties.
Voor LTE-simulaties moet de handmatige bevestigingsmethode worden gebruikt. Zie sectie
sec-network-attachment van de gebruikersdocumentatie voor meer informatie over de verschillen
in gebruik.

De volgende subsecties behandelen verschillende delen van de initiële celselectie, namelijk cel search,
uitzenden of system informatie en cel selectie evaluatie.

Cel Zoek
Celzoeken heeft tot doel omliggende cellen te detecteren en de sterkte van het ontvangen signaal te meten
van elk van deze cellen. Eén van deze cellen zal het toegangspunt van de UE worden om zich bij de EU aan te sluiten
cellulair netwerk.

De metingen zijn gebaseerd op de RSRP van de ontvangen PSS, gemiddeld door laag 1-filtering,
en uitgevoerd door de PHY-laag, zoals eerder in meer detail beschreven in sectie UE PHY
Afmetingen Model. PSS wordt door eNodeB verzonden via de centrale 72 subdragers van de
DL-kanaal (Sectie 5.1.7.3 [TS36300]), daarom modelleren we het zoeken naar cellen om te werken met behulp van een DL
bandbreedte van 6 RB's. Houd er rekening mee dat metingen van RSRQ op dit moment niet beschikbaar zijn
bij simulatie. Als gevolg hiervan is de LteUePhy::RsrqUeMeasdrempel attribuut niet
toepassen tijdens het zoeken naar cellen.

Door de gemeten RSRP te gebruiken, kan de PHY-entiteit een lijst met gedetecteerde cellen genereren,
elk met de bijbehorende cel-ID en gemiddelde RSRP. Deze lijst wordt periodiek gepusht
via CPHY SAP naar de RRC-entiteit als meetrapport.

De RRC-entiteit inspecteert het rapport en kiest eenvoudigweg de cel met de sterkste RSRP, zoals
ook aangegeven in sectie 5.2.3.1 van [TS36304]. Vervolgens instrueert het de PHY-entiteit terug te sturen
synchroniseren met deze specifieke cel. De werkelijke operationele bandbreedte van de cel is nog steeds
op dit moment onbekend, dus de PHY-entiteit luistert alleen naar de minimale bandbreedte van 6 RB's.
Niettemin kan de PHY-entiteit hiervan een systeemomroepbericht ontvangen
specifieke eNodeB, het onderwerp van de volgende subsectie.

Uitzending of Systeem Info
Systeeminformatieblokken worden door eNodeB met vooraf gedefinieerde tijdsintervallen naar UE's uitgezonden,
aangepast van sectie 5.2.1.2 van [TS36331]. De ondersteunde systeeminformatieblokken zijn:

·

Master Info Block (MIB)
Bevat parameters die verband houden met de PHY-laag, gegenereerd tijdens cel
configuratie en elke 10 ms uitgezonden aan het begin van het radioframe als een
controle bericht.

·

Systeem Info Block Type 1 (SIB1)
Bevat informatie over netwerktoegang, elke 20 ms uitgezonden op het
midden van het radioframe als controlebericht. Niet gebruikt bij handmatige bevestiging
methode. UE moet MIB hebben gedecodeerd voordat het SIB1 kan ontvangen.

·

Systeem Info Block Type 2 (SIB2)
Bevat UL- en RACH-gerelateerde instellingen, gepland voor verzending via het RRC-protocol
op 16 ms na celconfiguratie, en wordt vervolgens elke 80 ms herhaald (configureerbaar
door LteEnbRrc::SystemInformationPeriodiciteit attribuut. UE moet kamperen
naar een cel om zijn SIB2 te kunnen ontvangen.

De ontvangst van systeeminformatie is van fundamenteel belang voor de vooruitgang van UE in zijn levenscyclus. MIB
stelt de UE in staat de initiële DL-bandbreedte van 6 RB's te vergroten tot de daadwerkelijke werking
bandbreedte van het netwerk. SIB1 biedt informatie die nodig is voor celselectie
evaluatie (uitgelegd in de volgende paragraaf). En ten slotte is SIB2 vereist voordat de UE dat is
mag overschakelen naar de status VERBONDEN.

Cel Selectie Evaluatie
UE RRC beoordeelt het meetrapport dat is geproduceerd in Cel Zoek en de celtoegang
informatie verstrekt door SIB1. Zodra beide informatie beschikbaar is voor een specifieke cel, wordt de
UE activeert het evaluatieproces. Het doel van dit proces is om vast te stellen of
de cel is een geschikte cel om in te kamperen.

Het evaluatieproces is een enigszins vereenvoudigde versie van paragraaf 5.2.3.2 van [TS36304].
Het bestaat uit de volgende criteria:

· Rx-niveaucriterium; En

· criterium voor gesloten abonneegroepen (CSG).

Het eerste criterium, Rx-niveau, is gebaseerd op de gemeten RSRP Q_{rxlevmeas} van de cel, die
moet hoger zijn dan een vereist minimum Q_{rxlevmin} om aan het criterium te voldoen:

waarbij Q_{rxlevmin} wordt bepaald door elke eNodeB en kan worden verkregen door UE van SIB1.

Het laatste criterium, CSG, wordt een combinatie van een true-or-false parameter genoemd CSG
aanwijzing en een eenvoudig getal CSG identiteit. De basisregel is dat de UE niet zal kamperen
eNodeB met een andere CSG-identiteit. Maar deze regel wordt alleen gehandhaafd bij indicatie van CSG
wordt als waar gewaardeerd. Meer details vindt u in Sectie sec-netwerkbijlage van de Gebruiker
Documentatie.

Wanneer de cel aan alle bovenstaande criteria voldoet, wordt de cel beschouwd als geschikt. Dan EU
kampt er naartoe (IDLE_CAMPED_NORMALLY staat).

Hierna kan de bovenste laag UE verzoeken om naar de CONNECTED-modus te gaan. Raadpleeg sectie
RRC versterken etablissement voor details hierover.

Aan de andere kant, als de cel niet aan het CSG-criterium voldoet, wordt de cel gelabeld
as aanvaardbaar (Paragraaf 10.1.1.1 [TS36300]). In dit geval zal de RRC-entiteit de PHY hiervan op de hoogte stellen
entiteit om te synchroniseren met de op een na sterkste cel en herhaal de initiële celselectie
procedure met behulp van die cel. Zolang er geen geschikte cel wordt gevonden, zal de UE deze herhalen
stappen terwijl cellen worden vermeden die als acceptabel zijn geïdentificeerd.

Radio Toelating Controle
Radiotoelatingscontrole wordt ondersteund doordat de eNB RRC antwoordt op een RRC-VERBINDING
REQUEST-bericht verzonden door de UE met een RRC CONNECTION SETUP-bericht of een RRC
CONNECTION REJECT-bericht, afhankelijk van of de nieuwe UE moet worden toegelaten of niet. In
Bij de huidige implementatie wordt het gedrag bepaald door het Booleaanse attribuut
ns3::LteEnbRrc::AdmitRrcConnectionRequest. Er is momenteel geen radiotoelatingscontrole
algoritme dat dynamisch beslist of een nieuwe verbinding wordt toegelaten of niet.

Radio Toonder Configuratie
In het RRC zijn enkele implementatiekeuzes gemaakt met betrekking tot de inrichting van radio
dragers:

· drie logische kanaalgroepen (van de vier beschikbare) zijn geconfigureerd voor uplinkbuffer
statusrapportdoeleinden, volgens het volgende beleid:

· LCG 0 is voor het signaleren van radiodragers

· LCG 1 is voor GBR-dataradiodragers

· LCG 2 is voor niet-GBR dataradiodragers

Radio Link Storing
Omdat de RRC in dit stadium alleen de CONNECTED-modus ondersteunt, is Radio Link Failure (RLF) dat wel
niet afgehandeld. De reden is dat een van de mogelijke uitkomsten van RLF (wanneer RRC
herstel is niet succesvol) is om RRC VERBONDEN te laten en de NAS op de hoogte te stellen van de RRC
verbindingsfout. Om RLF goed te kunnen modelleren, moet de RRC IDLE-modus worden ondersteund,
inclusief in het bijzonder cel(her)selectie in de inactieve modus.

Met het huidige model een UE die een slechte linkkwaliteit ervaart en die niet presteert
overdracht (vanwege bijvoorbeeld geen aangrenzende cellen, overdracht uitgeschakeld, overdrachtsdrempels).
verkeerd geconfigureerd) blijft gewoon gekoppeld aan dezelfde eNB en de planner stopt
het toewijzen van middelen voor communicatie.

UE RRC Afmetingen Model
UE RRC maten ondersteuning
De UE RRC-entiteit biedt ondersteuning voor UE-metingen; in het bijzonder implementeert het de
procedures beschreven in sectie 5.5 van [TS36331], met de volgende vereenvoudiging
veronderstellingen:

· alleen E-UTRA intrafrequentiemetingen worden ondersteund, wat impliceert:

· tijdens de simulatie wordt slechts één meetobject gebruikt;

· meetopeningen zijn niet nodig om de metingen uit te voeren;

· Gebeurtenis B1 en B2 zijn niet geïmplementeerd;

· alleen rapportSterksteCellen doel wordt ondersteund, terwijl rapportCGI en
rapportStrongestCellsForSON doeleinden worden niet ondersteund;

· s-maat wordt niet ondersteund;

· aangezien carrieraggregatie niet wordt ondersteund door de LTE-module, het volgende
aannames in UE-metingen gelden:

· geen idee van secundaire cel (SCel);

· primaire cel (PCel) betekent simpelweg het dienen van de cel;

· Gebeurtenis A6 is niet geïmplementeerd;

· snelheidsafhankelijke schaling van tijd tot trigger (paragraaf 5.5.6.2 van [TS36331]) is niet
ondersteund.

globaal om mooie tassen te ontwerpen
Het model is gebaseerd op het concept van UE maten consument, een entiteit die dat wel kan
een eNodeB RRC-entiteit verzoeken om UE-meetrapporten te verstrekken. Consumenten zijn bijv
voorbeeld, Overhandigen algoritme, die de overdrachtsbeslissing berekent op basis van UE-meting
rapporten. Testgevallen en gebruikersprogramma's kunnen ook consumenten worden. Figuur Verhouding
tussen UE maten en haar consumenten geeft de relatie tussen deze entiteiten weer.
[image] Relatie tussen UE-metingen en zijn consumenten.UNINDENT

De gehele UE-metingsfunctie op RRC-niveau is verdeeld in 4 hoofdonderdelen:

1. Meetconfiguratie (afgehandeld door LteUeRrc::ApplyMeasConfig)

2. Uitvoeren van metingen (verzorgd door LteUeRrc::DoReportUeMeasurements)

3. Triggering meetrapport (afhandeld door LteUeRrc::MeasurementReportTriggering)

4. Meetrapportage (verzorgd door LteUeRrc::SendMeasurementReport)

In de volgende paragrafen wordt elk van de bovenstaande onderdelen beschreven.

maat configuratie
Een eNodeB RRC-entiteit configureert UE-metingen door de configuratieparameters te verzenden naar
de UE RRC-entiteit. Deze set parameters wordt gedefinieerd binnen de MeasConfig Info
Element (IE) van het RRC Connection Reconfiguration-bericht (RRC versterken
herconfiguratie).

De eNodeB RRC-entiteit implementeert de configuratieparameters en procedures die worden beschreven in
Paragraaf 5.5.2 van [TS36331], met de volgende vereenvoudigende aanname:

· configuratie (dwz toevoegen, wijzigen en verwijderen) kan alleen worden gedaan vóór de
simulatie begint;

· alle UE's die zijn aangesloten op de eNodeB zullen op dezelfde manier worden geconfigureerd, dwz er is geen
ondersteuning voor het configureren van specifieke metingen voor specifieke UE; En

· er wordt aangenomen dat er een één-op-één mapping bestaat tussen de PCI en de E-UTRAN
Globale celidentificatie (EGCI). Dit komt overeen met de aannames van het PCI-model
beschreven in UE PHY Afmetingen Model.

De eNodeB RRC-instantie fungeert hier als tussenpersoon tussen de consumenten en de
bijgevoegde UE's. Aan het begin van de simulatie verstrekt elke consument de eNodeB RRC
exemplaar met de UE-metingsconfiguratie die daarvoor nodig is. Daarna wordt de eNodeB
RRC distribueert de configuratie naar aangesloten UE's.

Gebruikers kunnen de meetconfiguratie op verschillende manieren aanpassen. Raadpleeg alstublieft
Sectie sec-configure-ue-measurements van de gebruikersdocumentatie voor de beschrijving van
deze methoden.

Uitvoerend maten
UE RRC ontvangt op periodieke basis zowel RSRP- als RSRQ-metingen van UE PHY, zoals
beschreven in UE PHY Afmetingen Model. Verschillende Lagen 3 filtering zullen hierop worden toegepast
metingen ontvangen. De implementatie van de filtering volgt Sectie 5.5.3.2 van
[TS36331]:

waar:

· M_n is het laatst ontvangen meetresultaat van de fysieke laag;

· F_n is het bijgewerkte gefilterde meetresultaat;

· F_{n-1} is het oude gefilterde meetresultaat, waarbij F_0 = M_1 (dwz het eerste
meting wordt niet gefilterd); En

· a = (ac{1}{2})^{ac{k}{4}}, waarbij k de configureerbare is filterCoëfficiënt door
the AantalConfig;

k = 4 is de standaardwaarde, maar kan worden geconfigureerd door de in te stellen RsrpFilterCoëfficiënt en
RsrqFilterCoëfficiënt attributen in LteEnbRrc.

Daarom zal k = 0 Laag 3-filtering uitschakelen. Aan de andere kant kunnen metingen uit het verleden dat wel doen
meer invloed krijgen op de filterresultaten door een grotere waarde van k te gebruiken.

maat rapportage triggering
In dit deel doorloopt UE RRC de lijst met actieve meetconfiguraties en
controleer of aan de activeringsvoorwaarde is voldaan overeenkomstig paragraaf 5.5.4 van
[TS36331]. Wanneer ten minste één triggerconditie van alle actieve metingen aanwezig is
configuratie is voltooid, wordt de meetrapportageprocedure (beschreven in de volgende paragraaf) uitgevoerd
subsectie) zal worden gestart.

3GPP definieert twee soorten triggerType: periodiek en op gebeurtenissen gebaseerd. Op dit moment alleen
op gebeurtenissen gebaseerd criterium wordt ondersteund. Er zijn verschillende evenementen waaruit geselecteerd kan worden
worden kort beschreven in de onderstaande tabel:

Lijst of ondersteund op gebeurtenissen gebaseerd triggering criteria
┌─────────┬────────────────────────────── ────┐
│Naam │ Beschrijving │
├─────────┼────────────────────────────── ────┤
│Gebeurtenis A1 │ Bedienende cel wordt beter dan │
│ drempel │
├─────────┼────────────────────────────── ────┤
│Gebeurtenis A2 │ Bedienende cel wordt slechter dan │
│ drempel │
├─────────┼────────────────────────────── ────┤
│Gebeurtenis A3 │ Buurman wordt compenseren dB│
│ │ beter dan het bedienen van cel │
├─────────┼────────────────────────────── ────┤
│Gebeurtenis A4 │ Buurman wordt beter dan │
│ drempel │
└─────────┴────────────────────────────── ────┘

│Gebeurtenis A5 │ Serveren wordt slechter dan │
│ drempel 1 EN buurman wordt │
│ │ beter dan drempel 2 │
└─────────┴────────────────────────────── ────┘

Twee belangrijke voorwaarden die moeten worden gecontroleerd bij een op gebeurtenissen gebaseerde trigger zijn de het invoeren van voorwaarde en
the verlaten voorwaarde. Meer details over deze twee kunt u vinden in paragraaf 5.5.4 van
[TS36331].

Een op gebeurtenissen gebaseerde trigger kan verder worden geconfigureerd door hysteresis en te introduceren
tijd tot trigger. hysteresis (Hys) definieert de afstand tussen binnenkomen en vertrekken
omstandigheden in dB. Op dezelfde manier, tijd tot trigger introduceert vertraging bij zowel binnenkomst als vertrek
omstandigheden, maar als een tijdseenheid.

De periodiek Het type rapportagetrigger wordt niet ondersteund, maar het gedrag ervan kan eenvoudig zijn
verkregen door gebruik te maken van een op gebeurtenissen gebaseerde trigger. Dit kunt u doen door de meting te configureren
zodanig dat altijd aan de intreevoorwaarde wordt voldaan, bijvoorbeeld door het instellen van de
drempel van gebeurtenis A1 op nul (het minimumniveau). Als gevolg hiervan rapporteert de meting
wordt altijd geactiveerd op elk bepaald interval, zoals bepaald door de rapportInterval
veld binnen LteRrcSap::ReportConfigEutra, waardoor hetzelfde gedrag ontstaat als
periodieke rapportage.

Als beperking met betrekking tot de 3GPP-specificaties ondersteunt het huidige model dit niet
elke celspecifieke configuratie. Deze configuratieparameters worden tijdens de meting gedefinieerd
voorwerp. Als gevolg hiervan wordt een lijst met zwarte cellen opgenomen in het triggerproces
wordt niet ondersteund. Bovendien kan celspecifieke offset (dat wil zeggen O_{cn} en O_{cp} in gebeurtenis A3, A4,
en A5) worden ook niet ondersteund. In plaats van wordt altijd de waarde gelijk aan nul aangenomen
Hen.

maat rapportage
Dit deel behandelt de indiening van het meetrapport van de UE RRC-entiteit naar de
bedient eNodeB-entiteit via het RRC-protocol. Er zijn verschillende vereenvoudigende aannames aangenomen:

· rapportBedrag is niet van toepassing (dwz er wordt altijd van uitgegaan dat deze oneindig is);

· in meetrapporten wordt de rapportAantal wordt altijd verondersteld zo te zijn BEIDE, dat wil zeggen, beide
RSRP en RSRQ worden altijd gerapporteerd, ongeacht de triggerhoeveelheid.

Overhandigen
Het RRC-model ondersteunt UE-mobiliteit in CONNECTED-modus door de op X2 gebaseerde handover aan te roepen
procedure. Het model is intra-EUTRAN en intrafrequentie, zoals gebaseerd op paragraaf 10.1.2.1 van
[TS36300].

In dit gedeelte wordt aandacht besteed aan het proces van het activeren van een overdracht. De uitvoering van de overdracht
procedure zelf wordt behandeld in Sectie X2.

Er zijn twee manieren om de overdrachtsprocedure te activeren:

· uitdrukkelijk (of handmatig) geactiveerd door het simulatieprogramma door een planning te maken
uitvoering van de methode LteEnbRrc::SendHandoverRequest; of

· webmaster. geactiveerd door de eNodeB RRC-entiteit op basis van UE-metingen en
volgens het geselecteerde overdrachtsalgoritme.

Sectie sec-x2-based-handover van de gebruikersdocumentatie biedt enkele voorbeelden van het gebruik
zowel expliciete als automatische overdrachttriggers in simulatie. De volgende subsectie zal dat doen
bekijk de automatische methode nader door de ontwerpaspecten van de te beschrijven
interface voor overdrachtsalgoritmen en de beschikbare overdrachtsalgoritmen.

Overhandigen algoritme
Overdracht in 3GPP LTE heeft de volgende eigenschappen:

·

UE-geassisteerd
De UE levert input aan het netwerk in de vorm van meetrapporten. Dit
wordt afgehandeld door de UE RRC Afmetingen Model.

·

Netwerkgestuurd
Het netwerk (dat wil zeggen de bron-eNodeB en de doel-eNodeB) beslist wanneer dit gebeurt
activeert de overdracht en houdt toezicht op de uitvoering ervan.

De overhandigen algoritme opereert bij de bron-eNodeB en is verantwoordelijk voor de overdracht
beslissingen op een “automatische” manier. Het communiceert met een eNodeB RRC-instantie via de
Overhandigen beheer SAP koppel. Deze relaties worden geïllustreerd in figuur
Verhouding tussen UE maten en haar consumenten uit het vorige gedeelte.

De overdrachtsalgoritme-interface bestaat uit de volgende methoden:

·

AddUeMeasReportConfigForHandover
(Handover-algoritme -> eNodeB RRC) Wordt gebruikt door het overdrachtsalgoritme dat wordt aangevraagd
meetrapporten van de eNodeB RRC-entiteit, door de gewenste door te geven
rapportageconfiguratie. De configuratie wordt op alle toekomstige toepassingen toegepast
bijgevoegde UE's.

·

RapportUeMeas
(eNodeB RRC -> Handover-algoritme) Gebaseerd op de geconfigureerde UE-metingen
eerder in AddUeMeasReportConfigForHandover, mag UE meetrapporten indienen
naar de eNodeB. De eNodeB RRC-entiteit gebruikt de RapportUeMeas interface naar
stuur deze meetrapporten door naar het overdrachtsalgoritme.

·

TriggerOverdracht
(Handover-algoritme -> eNodeB RRC) Na bestudering van de meetrapporten
(maar niet noodzakelijkerwijs), kan het overdrachtsalgoritme een overdracht declareren. Dit
Er wordt een methode gebruikt om de eNodeB RRC-entiteit op de hoogte te stellen van deze beslissing
ga vervolgens verder met de overdrachtsprocedure.

Eén opmerking voor de AddUeMeasReportConfigForHandover. De methode retourneert de meetId
(meetidentiteit) van de nieuw aangemaakte meetconfiguratie. Typisch een
het overdrachtsalgoritme zou dit unieke nummer opslaan. Het kan nuttig zijn in de RapportUeMeas
methode, bijvoorbeeld wanneer meer dan één configuratie is aangevraagd en de overdracht
algoritme moet binnenkomende rapporten differentiëren op basis van de configuratie die dat biedt
heeft ze geactiveerd.

Een overdrachtsalgoritme wordt geïmplementeerd door een subklasse van de te schrijven LteHandover-algoritme
abstracte superklasse en het implementeren van elk van de bovengenoemde SAP-interfacemethoden.
Gebruikers kunnen op deze manier hun eigen overdrachtsalgoritme ontwikkelen en dit vervolgens in elke simulatie gebruiken
door de stappen te volgen die zijn beschreven in Sectie sec-x2-gebaseerde-overdracht van de Gebruiker
Documentatie.

Als alternatief kunnen gebruikers ervoor kiezen om een ​​van de drie ingebouwde handover-algoritmen te gebruiken
door de LTE-module: no-op, A2-A4-RSRQ en het sterkste algoritme voor celoverdracht. Zij zijn
klaar om te worden gebruikt in simulaties of kan worden genomen als voorbeeld van het implementeren van een overdracht
algoritme. Elk van deze ingebouwde algoritmen wordt in elk van de volgende artikelen behandeld
onderafdelingen.

Nee-op overhandigen algoritme
De nee-op overhandigen algoritme (NoOpHandoverAlgoritme klasse) is het eenvoudigst mogelijk
implementatie van het overdrachtsalgoritme. Het doet feitelijk niets, dwz het roept niets op
van de Handover Management SAP-interfacemethoden. Gebruikers kunnen dit overdrachtsalgoritme kiezen
als ze de automatische overdrachttrigger in hun simulatie willen uitschakelen.

A2-A4-RSRQ overhandigen algoritme
De A2-A4-RSRQ overhandigen algoritme biedt de functionaliteit van de standaardoverdracht
algoritme oorspronkelijk opgenomen in LENA M6 (ns-3.18), geporteerd naar Handover Management SAP
interface als de A2A4RsrqOverdrachtsalgoritme klasse.

Zoals de naam al aangeeft, maakt het algoritme gebruik van de Reference Signal Ontvangen Kwaliteit (RSRQ)
metingen verkregen van Event A2 en Event A4. Het algoritme zal dus 2 toevoegen
meetconfiguratie naar de overeenkomstige eNodeB RRC-instantie. Het beoogde gebruik ervan is
als volgt omschreven:

· Gebeurtenis A2 (de RSRQ van de cel wordt slechter dan drempel) wordt gebruikt om aan te geven
dat de UE een slechte signaalkwaliteit ervaart en baat kan hebben bij een handover.

· Gebeurtenis A4 (de RSRQ van de buurcel wordt beter dan drempel) wordt gebruikt om te detecteren
naburige cellen en verwerven hun overeenkomstige RSRQ van elke aangesloten UE, die
worden vervolgens intern opgeslagen door het algoritme. Standaard wordt het algoritme geconfigureerd
Gebeurtenis A4 met een zeer lage drempel, zodat de triggercriteria altijd waar zijn.

Figuur A2-A4-RSRQ overhandigen algoritme hieronder vat deze procedure samen.
[afbeelding] A2-A4-RSRQ overdrachtsalgoritme.UNINDENT

Er kunnen twee attributen worden ingesteld om het gedrag van het algoritme af te stemmen:

·

ServingCellThreshold
De drempel voor gebeurtenis A2, dwz dat een UE een RSRQ moet hebben die lager is dan dit
drempel die in aanmerking moet worden genomen voor een overdracht.

·

BuurCelOffset
De compenseren dat tot doel heeft ervoor te zorgen dat de UE een betere signaalkwaliteit zou ontvangen
na de overdracht. Een naburige cel wordt beschouwd als een doelcel voor de
alleen overdragen als de RSRQ ervan een bepaald bedrag hoger is dan de RSRQ van de dienende cel
deze compenseren.

De waarde van beide attributen wordt uitgedrukt als RSRQ-bereik (paragraaf 9.1.7 van [TS36133]),
dat is een geheel getal tussen 0 en 34, met 0 als de laagste RSRQ.

Sterkste cel overhandigen algoritme
De sterkste cel overhandigen algoritme, of ook wel bekend als de traditioneel energie
begroting (PBGT) algoritme, is ontwikkeld met [Dimou2009] als referentie. Het idee is om
elke UE voorzien van het best mogelijke referentiesignaal ontvangen vermogen (RSRP). Dit is
gedaan door een overdracht uit te voeren zodra er een betere cel (dat wil zeggen met een sterkere RSRP) is
gedetecteerd.

Gebeurtenis A3 (de RSRP van de buurcel wordt beter dan de RSRP van de dienende cel) wordt gekozen
dit concept realiseren. De A3RsrpHandoverAlgoritme klasse is het resultaat van de
implementatie. Er wordt een overdracht van de UE aan de beste cel in de meting geactiveerd
melden.

Een simulatie die dit algoritme gebruikt, is doorgaans kwetsbaarder voor pingpongoverdracht
(opeenvolgende overdracht naar de vorige bron-eNodeB binnen korte tijd),
vooral wanneer de Fading Model is ingeschakeld. Dit probleem wordt doorgaans aangepakt door
het introduceren van een zekere vertraging bij de overdracht. Het algoritme doet dit door op te nemen
hysterese en time-to-trigger-parameters (paragraaf 6.3.5 van [TS36331]) naar de UE
metingen configuratie.

hysteresis (ook wel overdrachtsmarge genoemd) vertraagt ​​de overdracht met betrekking tot RSRP. De waarde is
uitgedrukt in dB, varieert van 0 tot 15 dB en heeft een nauwkeurigheid van 0.5 dB, bijvoorbeeld een ingangssignaal
waarde van 2.7 dB wordt afgerond naar 2.5 dB.

Daarnaast is tijd tot trigger vertraagt ​​de overdracht qua tijd. 3GPP definieert er 16
geldige waarden voor tijd tot trigger (allemaal in milliseconden): 0, 40, 64, 80, 100, 128, 160, 256,
320, 480, 512, 640, 1024, 1280, 2560 en 5120.

Het verschil tussen hysterese en time-to-trigger wordt geïllustreerd in figuur Effect of
hysteresis en tijd tot trigger in sterkste cel overhandigen algoritme hieronder, die is genomen
aan de hand van de lena-x2-overdrachtsmaatregelen voorbeeld. Het geeft de waargenomen RSRP van de bedienende cel weer
en een naburige cel door een UE die langs de grens van de cellen beweegt.
[afbeelding] Effect van hysteresis en time-to-trigger bij de sterkste celoverdracht
algoritme.UNINDENT

Standaard gebruikt het algoritme een hysteresis van 3.0 dB en een time-to-trigger van 256 ms.
Deze waarden kunnen worden afgestemd via de hysteresis en Tijd tot trigger attributen van de
A3RsrpHandoverAlgoritme klasse.

buur Relatie
LTE-module ondersteunt een vereenvoudigde Automatisch buur Relatie (ANR)-functie. Dit is
behandeld door de LteAnr klasse, die via de ANR communiceert met een eNodeB RRC-instantie
SAP-interface.

buur Relatie tafel
De ANR beschikt over een buur Relatie tafel (NRT), vergelijkbaar met de beschrijving in paragraaf
22.3.2a van [TS36300]. Elke invoer in de tabel wordt a genoemd buur Relatie (NR) en
vertegenwoordigt een gedetecteerde aangrenzende cel, die de volgende Booleaanse velden bevat:

·

Nee verwijderen
Geeft aan dat de NR dit zal doen niet verwijderd worden uit de NRT. Dit is waar by
standaard voor door de gebruiker opgegeven NR en vals anders.

·

Nee X2 Geeft aan dat de NR dit zal doen niet gebruik een X2-interface om te starten
procedures richting de eNodeB die de doelcel opvoedt. Dit is vals by
standaard voor door de gebruiker opgegeven NR, en waar anders.

·

Nee HO Geeft aan dat de NR dit zal doen niet worden gebruikt door de eNodeB voor overdrachtsredenen.
Dit is waar in de meeste gevallen, behalve wanneer de NR zowel door de gebruiker als
netwerk gedetecteerd.

Elke NR-invoer kan ten minste één van de volgende eigenschappen hebben:

·

Door gebruiker verstrekt
Dit type NR wordt gemaakt volgens de instructies van de simulatiegebruiker. Bijvoorbeeld,
er wordt automatisch een NR aangemaakt bij een door de gebruiker geïnitieerde oprichting van X2
verbinding tussen 2 eNodeB's, bijvoorbeeld zoals beschreven in paragraaf
sec-x2-gebaseerde overdracht. Een andere manier om een ​​door de gebruiker opgegeven NR te maken, is door de
Buurrelatie toevoegen expliciet functioneren.

·

Netwerk gedetecteerd
Dit type NR wordt tijdens de simulatie automatisch aangemaakt als resultaat van
de ontdekking van een nabijgelegen cel.

Om automatisch door het netwerk gedetecteerde NR te creëren, maakt ANR gebruik van UE-metingen. In
met andere woorden, ANR is een consument van UE-metingen, zoals weergegeven in figuur Verhouding
tussen UE maten en haar consumenten. RSRQ en Gebeurtenis A4 (buurman wordt beter
neem contact drempel) worden gebruikt voor de rapportageconfiguratie. De standaardgebeurtenis A4 drempel
is ingesteld op het laagst mogelijke, dat wil zeggen maximale detectievermogen, maar kan worden gewijzigd door
het instellen van de Drempel kenmerk van LteAnr klas. Houd er rekening mee dat de A2-A4-RSRQ-overdracht plaatsvindt
algoritme maakt ook gebruik van een vergelijkbare rapportageconfiguratie. Ondanks de gelijkenis, wanneer
zowel ANR als dit overdrachtsalgoritme zijn actief in de eNodeB, ze gebruiken afzonderlijke rapportage
configuratie.

Houd er ook rekening mee dat automatische installatie van de X2-interface niet wordt ondersteund. Dit is de reden waarom
the Nee X2 en Nee HO velden zijn waar in een door het netwerk gedetecteerde maar niet door de gebruiker gedetecteerde NR.

Rol of ANR in Simulatie
De ANR SAP-interface biedt de communicatiemiddelen tussen ANR en eNodeB RRC. Sommige
interfacefuncties worden door eNodeB RRC gebruikt om te communiceren met de NRT, zoals hieronder weergegeven:

·

Buurrelatie toevoegen
(eNodeB RRC -> ANR) Voeg een nieuwe, door de gebruiker verstrekte NR-invoer toe aan de NRT.

·

GetNoRemove
(eNodeB RRC -> ANR) Haal de waarde op van Nee verwijderen veld van een NR-invoer van de
gegeven cel-ID.

·

OntvangNeeHo
(eNodeB RRC -> ANR) Haal de waarde op van Nee HO veld van een NR-invoer van het gegeven
cel-ID.

·

GetNoX2
(eNodeB RRC -> ANR) Haal de waarde op van Nee X2 veld van een NR-invoer van het gegeven
cel-ID.

Er bestaan ​​andere interfacefuncties om de rol van ANR als consument van UE-metingen te ondersteunen,
zoals hieronder vermeld:

·

AddUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) Wordt door de ANR gebruikt om meetrapporten op te vragen bij de
eNodeB RRC-entiteit, door de gewenste rapportageconfiguratie door te geven. De
configuratie wordt toegepast op alle toekomstige gekoppelde UE's.

·

RapportUeMeas
(eNodeB RRC -> ANR) Gebaseerd op de eerder geconfigureerde UE-metingen
AddUeMeasReportConfigForAnr, kan UE meetrapporten indienen bij de eNodeB.
De eNodeB RRC-entiteit gebruikt de RapportUeMeas interface om deze door te sturen
meetrapporten aan het ANR.

Raadpleeg de bijbehorende API-documentatie voor LteAnrSap klasse voor meer details
over het gebruik en de vereiste parameters.

De ANR wordt door de eNodeB RRC-instantie gebruikt als een gegevensstructuur om de gegevens bij te houden
situatie van nabijgelegen naburige cellen. De ANR helpt ook de eNodeB RRC-instantie hierbij
bepalen of het mogelijk is een overdrachtsprocedure uit te voeren naar een naburige cel.
Dit wordt gerealiseerd door het feit dat eNodeB RRC alleen een overdrachtsprocedure toestaat
gebeuren als de NR-invoer van de doelcel beide heeft Nee HO en Nee X2 velden ingesteld vals.

ANR is standaard ingeschakeld in elk eNodeB-exemplaar in de simulatie. Het kan worden uitgeschakeld
door het instellen van de AnrEnabled attribuut in LteHelper klasse vals.

RRC volgorde diagrammen
In deze sectie bieden we enkele sequentiediagrammen die de belangrijkste RRC verklaren
procedures worden gemodelleerd.

RRC versterken etablissement
Figuur Volgorde diagram of the RRC Aansluiting etablissement procedures laat zien hoe de RRC
De procedure voor het tot stand brengen van de verbinding is gemodelleerd, waarbij de rol van de RRC-laag wordt benadrukt
zowel de UE als de eNB, evenals de interactie met de andere lagen.
[afbeelding] Volgordediagram van de procedure voor het tot stand brengen van de RRC-verbinding.UNINDENT

Er zijn verschillende time-outs gerelateerd aan deze procedure, die hieronder worden vermeld
tafel Timers in RRC versterken etablissement procedures. Als een van deze timers is verlopen,
de procedure voor het tot stand brengen van de RRC-verbinding is mislukt. In dit geval is de
bovenste laag (UE NAS) zal onmiddellijk proberen de procedure opnieuw uit te voeren totdat deze is voltooid
succes.

Timers in RRC versterken etablissement procedures
┌───────────────┬────────────┬─────────── ─────┬─── ─────────────┬──────────┬──────────────── ┐
│Naam │ Locatie │ Timer start │ Timer stopt │ Standaard │ Wanneer timer │
│ │ │ │ │ duur │ verlopen │
├───────────────┼────────────┼─────────── ─────┼─── ─────────────┼──────────┼──────────────── ┤
│Verbinding │ eNodeB RRC │ Nieuwe UE-context │ RRC ontvangen │ 15 ms │ UE verwijderen │
│verzoek │ │ toegevoegd │ VERBINDING │ │ context │
│time-out │ │ │ VERZOEK │ │ │
├───────────────┼────────────┼─────────── ─────┼─── ─────────────┼──────────┼──────────────── ┤
│Verbinding │ UE RRC │ RRC verzenden │ RRC ontvangen │ 100 ms │ UE MAC resetten │
│time-out (T300 │ │ VERBINDING │ VERBINDING │ │ │
│timer) │ │ AANVRAAG │ INSTELLING of │ │ │
│ │ │ │ WEIGEREN │ │ │
├───────────────┼────────────┼─────────── ─────┼─── ─────────────┼──────────┼──────────────── ┤
│Verbinding │ eNodeB RRC │ RRC verzenden │ RRC ontvangen │ 100 ms │ UE verwijderen │
│time-out instellen │ │ VERBINDING │ VERBINDING │ │ context │
│ │ │ INSTELLING │ INSTELLING VOLTOOID │ │ │
├───────────────┼────────────┼─────────── ─────┼─── ─────────────┼──────────┼──────────────── ┤
│Verbinding │ eNodeB RRC │ RRC verzenden │ Nooit │ 30 ms │ UE verwijderen │
│afgewezen │ │ VERBINDING │ │ │ context │
│time-out │ │ WEIGEREN │ │ │ │
└───────────────┴────────────┴─────────── ─────┴─── ─────────────┴──────────┴──────────────── ┘

RRC versterken herconfiguratie
Figuur Volgorde diagram of the RRC Aansluiting Herindeling procedures laat zien hoe de RRC
De procedure voor het opnieuw configureren van de verbinding is gemodelleerd voor het geval waarin MobilityControlInfo aanwezig is
niet verstrekt, dat wil zeggen dat de overdracht niet wordt uitgevoerd.
[afbeelding] Volgordediagram van de RRC-verbindingsherconfiguratieprocedure.UNINDENT

Figuur Volgorde diagram of the RRC Aansluiting Herindeling procedures voor the overhandigen
geval laat zien hoe de procedure voor het opnieuw configureren van de RRC-verbinding voor dit geval is gemodelleerd
waar MobilityControlInfo wordt aangeboden, dwz dat de overdracht moet worden uitgevoerd. Zoals aangegeven
in [TS36331], Na ontvangende the overhandigen bericht, the UE pogingen naar toegang the doel
cel at the eerste Beschikbaar RACH per gelegenheid volgens naar Random Toegang tot hulpbron selectie
gedefinieerd in [TS36321]_, dat wil zeggen the overhandigen is asynchroon. Bijgevolg wanneer toewijzen
a toegewijd aan preambule voor the willekeurige toegang in the doel cel, E-UTRA zal verzekeren it is
Beschikbaar van the eerste RACH per gelegenheid the UE mei gebruikt. Op geslaagd voltooiing of the
overhandigen, the UE verzendt a bericht gebruikt naar bevestigen the overhandigen. Merk op dat de willekeurige
De toegangsprocedure is in dit geval niet op conflicten gebaseerd, dus in een echt LTE-systeem wel
verschilt enigszins van degene die wordt gebruikt bij het tot stand brengen van de RRC-verbinding. Merk ook op dat de RA
Preambule-ID wordt gesignaleerd via het overdrachtscommando dat is opgenomen in het X2-overdrachtsverzoek
ACK-bericht verzonden van de doel-eNB naar de bron-eNB; in het bijzonder is de preambule
opgenomen in de RACH-ConfigDedicated IE die deel uitmaakt van MobilityControlInfo.
[afbeelding] Volgordediagram van de RRC-verbindingsherconfiguratieprocedure voor de
overdrachtszaak.UNINDENT

RRC protocol modellen
Zoals eerder verwacht, bieden we twee verschillende modellen voor de transmissie en
ontvangst van RRC-berichten: Ideal en Real. Elk van hen wordt beschreven in een van de
volgende subsecties.

Ideal RRC protocol model
Volgens dit model, geïmplementeerd in de klassen en LteUeRrcProtocolIdeal en
LteEnbRrcProtocolIdealworden alle RRC-berichten en informatie-elementen verzonden tussen
de eNB en de UE op een ideale manier, zonder radiobronnen te verbruiken en zonder
fouten. Vanuit implementatieoogpunt wordt dit bereikt door de RRC-gegevens door te geven
structuur rechtstreeks tussen de UE- en eNB RRC-entiteiten, zonder de lagere lagen erbij te betrekken
(PDCP, RLC, MAC, planner).

Real RRC protocol model
Dit model wordt in de klassen geïmplementeerd LteUeRrcProtocolReal en LteEnbRrcProtocolReal
en is gericht op het modelleren van de transmissie van RRC PDU's zoals gewoonlijk uitgevoerd in echte LTE
systemen. In het bijzonder:

· voor elk RRC-bericht dat wordt verzonden, wordt een echte RRC-PDU gemaakt na ASN.1
codering van RRC PDU's en informatie-elementen (IE's) gespecificeerd in [TS36331]. Sommige
Er worden vereenvoudigingen aangebracht met betrekking tot de IE's die zijn opgenomen in de PDU, dat wil zeggen alleen die
IE's die nuttig zijn voor simulatiedoeleinden zijn inbegrepen. Voor een gedetailleerde lijst, alstublieft
zie de IE's gedefinieerd in lte-rrc-sap.h en vergelijk met [TS36331].

· de gecodeerde RRC PDU's worden verzonden op signaleringsradiodragers en zijn hieraan onderworpen
transmissiemodellering gebruikt voor datacommunicatie, dus inclusief planning, radio
verbruik van hulpbronnen, kanaalfouten, vertragingen, hertransmissies, enz.

signalering Radio Toonder model
We beschrijven nu het Signaling Radio Bearer-model dat wordt gebruikt voor de Real RRC-protocol
model.

· SRB0 berichten (via CCCH):

· RrcConnectionRequest: in echte LTE-systemen is dit een RLC TM SDU die wordt verzonden
middelen gespecificeerd in de UL Grant in de RAR (niet in UL DCI's); de reden is dat
C-RNTI is in dit stadium nog niet bekend. In de simulator wordt dit gemodelleerd als een werkelijkheid
RLC TM RLC PDU waarvan de UL-bronnen worden toegewezen volgens het schema bij het oproepen ervan
SCHED_DL_RACH_INFO_REQ.

· RrcVerbindingInstelling: in de simulator wordt dit geïmplementeerd zoals in echte LTE-systemen,
dat wil zeggen, met een RLC TM SDU verzonden via bronnen aangegeven door een reguliere UL DCI,
toegewezen met SCHED_DL_RLC_BUFFER_REQ geactiveerd door de RLC TM-instantie
toegewezen aan LCID 0 (de CCCH).

· SRB1 berichten (via DCCH):

· Alle SRB1-berichten gemodelleerd in de simulator (bijv. RrcVerbindingVoltooid) zijn
geïmplementeerd zoals in echte LTE-systemen, dwz met een echte RLC SDU verzonden via RLC AM
met behulp van DL-bronnen die zijn toegewezen via bufferstatusrapporten. Zie het RLC-model
documentatie voor details.

· SRB2 berichten (via DCCH):

· Volgens [TS36331]: "SRB1 is voor RRC berichten (welke mei omvatten a
meeliften NAS bericht) as well as voor NAS berichten voorafgaand naar the etablissement
of SRB2, allen gebruik DCCH logisch kanaal", terwijl "SRB2 is voor NAS berichten,
gebruik DCCH logisch kanaal"En"SRB2 heeft a lagere prioriteit neem contact SRB1 en is
altijd geconfigureerd by E-UTRAN na veiligheid activering". Modellering
beveiligingsgerelateerde aspecten zijn geen vereiste van het LTE-simulatiemodel,
daarom gebruiken we altijd SRB1 en activeren we nooit SRB2.

ASN.1 codering of RRC IE's
De berichten die zijn gedefinieerd in RRC SAP en die gemeenschappelijk zijn voor alle Ue/Enb SAP-gebruikers/providers, worden getransporteerd
in een transparante container van/naar een Ue/Enb. Het coderingsformaat voor de verschillende
Informatie-elementen worden gespecificeerd in [TS36331], waarbij gebruik wordt gemaakt van ASN.1-regels in de niet-uitgelijnde versie
variant. De implementatie in Ns3/Lte is onderverdeeld in de volgende klassen:

· Asn1Header: Bevat de codering/decodering van basis-ASN-typen

· RrcAsn1Header: neemt Asn1Header over en bevat de codering/decodering van gemeenschappelijke
IE's gedefinieerd in [TS36331]

· Rrc-specifieke berichten/IEs-klassen: een klasse voor elk van de berichten gedefinieerd in RRC
SAP-koptekst

Asn1Header klasse - Implementatie of baseren ASN.1 types
Deze klasse implementeert de methoden voor het serialiseren/deserialiseren van de ASN.1-typen die worden gebruikt
[TS36331], volgens de verpakte coderingsregels in ITU-T X.691. De soorten die in aanmerking komen
zijn:

· Boolean: een Booleaanse waarde gebruikt één enkele bit (1=waar, 0=onwaar).

· Geheel getal: een beperkt geheel getal (met gedefinieerde min- en max-waarden) gebruikt het minimum
aantal bits om het bereik te coderen (max-min+1).

· Bitstring: een bistring wordt bit voor bit naar de serialisatiebuffer gekopieerd.

· Octetstring: wordt momenteel niet gebruikt.

· Volgorde: de reeks genereert een preambule die de aanwezigheid van optionele en aangeeft
standaardvelden. Het voegt ook een stukje toe dat de aanwezigheid van een extensiemarkering aangeeft.

· Sequence...Of: de sequence...van het type codeert het aantal elementen van de sequence
als een geheel getal (de daaropvolgende elementen moeten achteraf worden gecodeerd).

· Keuze: geeft aan welk element uit de keuzeset wordt gecodeerd.

· Opsomming: wordt geserialiseerd als een geheel getal dat aangeeft welke waarde wordt gebruikt
degenen in de opsomming, met het aantal elementen in de opsomming als bovenste
gebonden.

· Null: de nulwaarde is niet gecodeerd, hoewel de serialisatiefunctie ervan is gedefinieerd
om een ​​duidelijker overzicht te bieden tussen specificatie en implementatie.

De klasse erft van ns-3 Header, maar de functie Deserialize() wordt puur virtueel verklaard,
dus erfde klassen die het moesten implementeren. De reden is dat deserialisatie dat wel zal doen
haal de elementen in RRC-berichten op, die elk verschillende informatie bevatten
elementen.

Bovendien moet worden opgemerkt dat de resulterende bytelengte van een specifiek type/bericht
kan variëren afhankelijk van de aanwezigheid van optionele velden en vanwege de geoptimaliseerde codering.
Daarom zullen de geserialiseerde bits worden verwerkt met behulp van de functie PreSerialize(), waarbij de
resultaat in m_serializationResult Buffer. Zoals de methoden om te lezen/schrijven in een ns3-buffer zijn
gedefinieerd op bytebasis, worden de serialisatiebits opgeslagen in m_serializationPendingBits
attribuut, totdat de 8 bits zijn ingesteld en naar de bufferiterator kunnen worden geschreven. Eindelijk, wanneer
Door Serialize() aan te roepen, wordt de inhoud van het m_serializationResult-attribuut gekopieerd
naar Buffer::Iterator-parameter

RrcAsn1Header : Gemeen IE's
Omdat sommige informatie-elementen worden gebruikt voor verschillende RRC-berichten, is deze klasse
implementeert de volgende algemene IE's:

· SrbToAddModList

· DrbToAddModList

· LogicalChannelConfig

· RadioResourceConfigDedicated

· PhysicalConfig specifiek

· SysteemInformatieBlokType1

· SysteemInformatieBlokType2

· RadioResourceConfigCommonSIB

Rrc specifiek berichten/IE's klassen
De volgende RRC SAP zijn geïmplementeerd:

· RrcConnectionRequest

· RrcVerbindingInstelling

· RrcConnectionSetupVoltooid

· RrcConnectionHerconfiguratie

· RrcConnectionHerconfiguratievoltooid

· OverdrachtVoorbereidingInfo

· RrcConnectionReestablishmentRequest

· RrcConnectionHerstel

· RrcVerbindingHerstel voltooid

· RrcConnectionReestablishmentReject

· RrcConnectionRelease

NAS
De focus van het LTE-EPC-model ligt op de NAS Active-status, die overeenkomt met EMM
Geregistreerd, ECM aangesloten en RRC aangesloten. Daarom het volgende
vereenvoudigingen worden gemaakt:

· EMM en ECM worden niet expliciet gemodelleerd; in plaats daarvan zal de NAS-entiteit in de UE dat doen
rechtstreeks communiceren met de MME om acties uit te voeren die gelijkwaardig zijn (met bruto
vereenvoudigingen) om de UE naar de staten EMM Connected en ECM Connected te brengen;

· De NAS zorgt ook voor het multiplexen van uplink-datapakketten die van bovenaf komen
lagen in de juiste EPS-drager met behulp van de Traffic Flow Template-classifier
(TftClassifier).

· de NAS ondersteunt geen PLMN- en CSG-selectie

· de NAS ondersteunt geen enkele locatie-update/paging-procedure in de inactieve modus

Figuur Volgorde diagram of the hechten procedures laat zien hoe het vereenvoudigde NAS-model
implementeert de bijlageprocedure. Houd er rekening mee dat zowel de standaard als de eventuele speciale EPS
dragers worden geactiveerd als onderdeel van deze procedure.
[afbeelding] Volgordediagram van de bijlageprocedure.UNINDENT

S1
S1-U
De S1-U-interface is op een realistische manier gemodelleerd door datapakketten in te kapselen
GTP/UDP/IP, zoals gedaan in echte LTE-EPC-systemen. De bijbehorende protocolstapel wordt weergegeven in
Figuur LTE-EPC gegevens vliegtuig protocol stack. Zoals weergegeven in de afbeelding zijn er twee verschillende
lagen van IP-netwerken. De eerste is de end-to-end-laag, die end-to-end biedt
connectiviteit met de gebruikers; deze lagen omvatten de UE's, de PGW en de externe host
(inclusief eventuele internetrouters en hosts ertussen), maar hierbij is de eNB niet betrokken.
Standaard krijgen UE's een openbaar IPv4-adres toegewezen in het 7.0.0.0/8-netwerk, en de PGW
krijgt het adres 7.0.0.1, dat door alle UE's wordt gebruikt als gateway om internet te bereiken.

De tweede laag van IP-netwerken is het EPC Local Area Network. Dit betreft alle eNB
knooppunten en het SGW/PGW-knooppunt. Dit netwerk is geïmplementeerd als een reeks point-to-point-verbindingen
die elke eNB verbinden met het SGW/PGW-knooppunt; de SGW/PGW heeft dus een set van
point-to-point-apparaten, die elk connectiviteit bieden met een andere eNB. Standaard is een
Aan elke point-to-point-verbinding wordt 10.xyz/30-subnet toegewezen (een /30-subnet is het kleinste
subnet dat twee verschillende hostadressen mogelijk maakt).

Zoals gespecificeerd door 3GPP, wordt de end-to-end IP-communicatie getunneld via het lokale EPC IP
netwerk met behulp van GTP/UDP/IP. Hieronder leggen we uit hoe deze tunneling wordt geïmplementeerd
in het EPC-model. De uitleg wordt gedaan door de end-to-end datastroom te bespreken
pakketten.
[image] Gegevensstroom in de downlink tussen internet en de UE.UNINDENT

Om te beginnen beschouwen we het geval van de downlink, weergegeven in figuur Data
stroom in the downlink tussen the internet en the UE. Downlink IPv4-pakketten zijn dat wel
gegenereerd door een generieke externe host en geadresseerd aan een van de UE-apparaten. Internet
routing zorgt voor het doorsturen van het pakket naar het generieke NetDevice van de SGW/PGW
knooppunt dat is verbonden met internet (dit is de Gi-interface volgens 3GPP
terminologie). De SGW/PGW heeft een VirtualNetDevice waaraan het gateway-IP is toegewezen
adres van het UE-subnet; Daarom zullen statische routeringsregels het binnenkomende pakket veroorzaken
van internet om via dit VirtualNetDevice te worden gerouteerd. Een dergelijk apparaat start de
GTP/UDP/IP-tunnelingprocedure, door het pakket door te sturen naar een speciale applicatie in
het SGW/PGW-knooppunt dat EpcSgwPgwApplication wordt genoemd. Deze applicatie doet de
volgende bewerkingen:

1. het bepaalt het eNB-knooppunt waaraan de UE is gekoppeld, door naar het IP-adres te kijken
bestemmingsadres (dit is het adres van de UE);

2. het classificeert het pakket met behulp van Traffic Flow Templates (TFT's) om te identificeren waarnaar
EPS-drager, het hoort erbij. EPS-dragers hebben een één-op-één-toewijzing aan S1-U-dragers, dus
deze bewerking retourneert de GTP-U Tunnel Endpoint Identifier (TEID) waarnaar de
pakket behoort;

3. het voegt de corresponderende GTP-U-protocolheader toe aan het pakket;

4. Ten slotte verzendt het het pakket via een UDP-socket naar de S1-U point-to-point
NetDevice, geadresseerd aan de eNB waaraan de UE is gekoppeld.

Als gevolg hiervan is het end-to-end IP-pakket met nieuw toegevoegde IP-, UDP- en GTP-headers dat wel
via een van de S1-links naar de eNB verzonden, waar het lokaal wordt ontvangen en afgeleverd
(aangezien het bestemmingsadres van de buitenste IP-header overeenkomt met het eNB IP-adres). De
Het lokale bezorgproces stuurt het pakket via een UDP-socket door naar een speciale
toepassing genaamd EpcEnbApplication. Deze applicatie voert vervolgens het volgende uit
activiteiten:

1. het verwijdert de GTP-header en haalt de TEID op die daarin is opgenomen;

2. gebruik maken van de één-op-één mapping tussen S1-U-dragers en radiodragers (welke
is een 3GPP-vereiste), het bepaalt de Bearer ID (BID) waarnaar het pakket verwijst
behoort;

3. het registreert het BID in een speciale tag genaamd EpsBearerTag, die wordt toegevoegd aan de
pakket;

4. het stuurt het pakket via een onbewerkt pakket door naar het LteEnbNetDevice van het eNB-knooppunt
stopcontact

Merk op dat op dit punt de buitenste header van het pakket de end-to-end IP-header is,
omdat de IP/UDP/GTP-headers van de S1-protocolstack al zijn verwijderd. Bij
ontvangst van het pakket van de EpcEnbApplication, zal het LteEnbNetDevice het
BID van de EpsBearerTag, en op basis van het BID wordt de Radio Bearer-instantie bepaald
(en de overeenkomstige PDCP- en RLC-protocolinstanties) die vervolgens worden gebruikt om de
pakket naar de UE via de LTE-radio-interface. Ten slotte zal het LteUeNetDevice van de UE dat doen
het pakket ontvangen en lokaal afleveren bij de IP-protocolstack, die dit op zijn beurt zal doen
bezorg het aan de applicatie van de UE, wat het eindpunt is van de downlink
communicatie.
[image] Gegevensstroom in de uplink tussen de UE en het internet.UNINDENT

Het geval van de uplink is weergegeven in figuur Data stroom in the uplink tussen the UE en
the internet. Uplink IP-pakketten worden gegenereerd door een generieke applicatie binnen de UE,
en doorgestuurd door de lokale TCP/IP-stack naar het LteUeNetDevice van de UE. De
LteUeNetDevice voert vervolgens de volgende bewerkingen uit:

1. het classificeert het pakket met behulp van TFT's en bepaalt de radiodrager waarnaar de
pakket behoort (en de bijbehorende RBID);

2. het identificeert de corresponderende PDCP-protocolinstantie, die het toegangspunt is
de LTE Radio Protocol-stack voor dit pakket;

3. het verzendt het pakket naar de eNB via de LTE Radio Protocol-stack.

De eNB ontvangt het pakket via zijn LteEnbNetDevice. Omdat er één PDCP en RLC is
protocolinstantie voor elke radiodrager kan het LteEnbNetDevice de BID bepalen
van het pakket. Dit BID wordt vervolgens vastgelegd op een EpsBearerTag, die wordt toegevoegd aan de
pakket. Het LteEnbNetDevice stuurt het pakket vervolgens via een raw
pakketaansluiting.

Na ontvangst van het pakket voert de EpcEnbApplication de volgende bewerkingen uit:

1. het haalt de BID op uit de EpsBearerTag in het pakket;

2. het bepaalt de overeenkomstige EPS Bearer-instantie en GTP-U TEID door gebruik te maken van
de één-op-één mapping tussen S1-U-dragers en radiodragers;

3. het voegt een GTP-U-header toe aan het pakket, inclusief de eerder bepaalde TEID;

4. het stuurt het pakket naar het SGW/PGW-knooppunt via de UDP-socket die is aangesloten op de S1-U
point-to-point-netapparaat.

Op dit punt bevat het pakket de S1-U IP-, UDP- en GTP-headers naast de
originele end-to-end IP-header. Wanneer het pakket wordt ontvangen door de overeenkomstige S1-U
point-to-point NetDevice van het SGW/PGW-knooppunt, wordt het lokaal geleverd (als de bestemming
adres van de buitenste IP-header komt overeen met het adres van het point-to-point-netapparaat).
Het lokale bezorgproces stuurt het pakket door naar de EpcSgwPgwApplication via de
overeenkomstige UDP-socket. De EpcSgwPgwApplication verwijdert vervolgens de GTP-header en stuurt deze door
het pakket naar het VirtualNetDevice. Op dit punt is de buitenste header van het pakket de
end-to-end IP-header. Als het bestemmingsadres binnen deze header dus een extern adres is
host op internet, wordt het pakket via het bijbehorende NetDevice naar internet verzonden
van de SGW/PGW. In het geval dat het pakket aan een andere UE is geadresseerd, wordt de IP-stack van
de SGW/PGW zal het pakket opnieuw omleiden naar het VirtualNetDevice, en het pakket zal verdwijnen
via het downlink-leveringsproces om de bestemming UE te bereiken.

Houd er rekening mee dat de EPS Bearer QoS niet wordt afgedwongen op de S1-U-koppelingen; er wordt aangenomen dat de
overprovisioning van de verbindingsbandbreedte is voldoende om aan de QoS-vereisten van iedereen te voldoen
dragers.

S1AP
De S1-AP-interface biedt besturingsvlakinteractie tussen de eNB en de MME. In de
simulator is deze interface op een ideale manier gemodelleerd, met directe interactie tussen
de eNB en de MME maken bezwaar, zonder de codering van S1AP-berichten daadwerkelijk te implementeren
en informatie-elementen gespecificeerd in [TS36413] en zonder daadwerkelijk een PDU te verzenden
op welke link dan ook.

De S1-AP-primitieven die worden gemodelleerd zijn:

· EERSTE UE-BERICHT

· EERSTE VERZOEK VOOR CONTEXTINSTELLING

· INITIËLE CONTEXT-INSTELLINGSANTWOORD

· VERZOEK PADSCHAKELAAR

· PADSCHAKELAAR VERZOEK BEVESTIGING

X2
De X2-interface verbindt twee eNB's [TS36420]. Vanuit logisch oogpunt is de X2
interface is een point-to-point interface tussen de twee eNB's. In een echte E-UTRAN is de
Een logische point-to-point-interface zou haalbaar moeten zijn, zelfs als er geen fysieke interface aanwezig is
directe verbinding tussen de twee eNB's. In het X2-model dat in de simulator is geïmplementeerd, is de
De X2-interface is een point-to-point-verbinding tussen de twee eNB's. Een point-to-point-apparaat is dat wel
gemaakt in beide eNB's en de twee point-to-point-apparaten zijn aangesloten op de point-to-point
link.

Voor een weergave van hoe de X2-interface past in de algemene architectuur van de LENA
simulatiemodel wordt de lezer verwezen naar de figuur Overzicht of the LTE-EPC simulatie
model.

De in de simulator geïmplementeerde X2-interface biedt een gedetailleerde implementatie van de
volgende elementaire procedures van de functionaliteit Mobiliteitsbeheer [TS36423]:

· Procedure voor overdrachtsverzoeken

· Procedure voor ontvangstbevestiging van overdrachtsverzoek

· SN-statusoverdrachtprocedure

· UE-contextvrijgaveprocedure

Deze procedures zijn betrokken bij de op X2 gebaseerde overdracht. U kunt de gedetailleerde vinden
beschrijving van de overdracht in sectie 10.1.2.1 van [TS36300]. We merken op dat de simulator
model ondersteunt momenteel alleen de naadloos overhandigen zoals gedefinieerd in paragraaf 2.6.3.1 van
[Sesia2009]; in het bijzonder, verliesvrije overhandigen zoals beschreven in paragraaf 2.6.3.2 van
[Sesia2009] wordt op het moment van schrijven niet ondersteund.

Figuur Volgorde diagram of the X2-gebaseerd overhandigen Hieronder ziet u de interactie van de
entiteiten van het X2-model in de simulator. De gearceerde labels geven de momenten aan waarop de
UE- of eNodeB-overgang naar een andere RRC-status.
[afbeelding] Volgordediagram van de op X2 gebaseerde handover.UNINDENT

De figuur toont ook twee timers binnen de overdrachtsprocedure: de overhandigen verlaten
timer wordt onderhouden door de bron eNodeB, terwijl de overhandigen aansluiting timer door het doel
eNodeB. De duur van de timers kan worden geconfigureerd in de
OverdrachtLeavingTimeoutDuration en OverdrachtJoiningTimeoutDuur attributen van de
degenen LteEnbRrc exemplaren. Wanneer een van deze timers afloopt, wordt de overdrachtsprocedure gestart
wordt als mislukt beschouwd.

Er is echter geen goede afhandeling van overdrachtsfouten in de huidige versie van LTE
module. Gebruikers moeten de simulatie goed afstemmen om mislukte overdracht te voorkomen.
Anders kan er onverwacht gedrag optreden. Raadpleeg sectie
sec-tuning-handover-simulation van de gebruikersdocumentatie voor enkele tips hierover
er toe doen.

Het X2-model is een entiteit die diensten gebruikt van:

· de X2-interfaces,

· Ze zijn geïmplementeerd als Sockets bovenop de point-to-point-apparaten.

· Ze worden gebruikt om X2-berichten te verzenden/ontvangen via de X2-C- en X2-U-interfaces
(dwz het point-to-point-apparaat dat is aangesloten op de point-to-point-verbinding) naar de
peer-eNB.

· de S1-applicatie.

· Momenteel is dit de EpcEnbApplication.

· Het wordt gebruikt om wat informatie te verkrijgen die nodig is voor de elementaire procedures van de X2
berichten.

en het levert diensten aan:

· de RRC-entiteit (X2 SAP)

· om RRC-berichten te verzenden/ontvangen. De X2-entiteit verzendt het RRC-bericht als transparant
container in het X2-bericht. Dit RRC-bericht wordt naar de UE verzonden.

Figuur Implementatie Model of X2 entiteit en SAP's toont het implementatiemodel van de X2
entiteit en de relatie ervan met alle andere entiteiten en diensten in het protocol
stack.
[image] Implementatiemodel van X2-entiteit en SAPs.UNINDENT

De RRC-entiteit beheert de start van de overdrachtsprocedure. Dit gebeurt in de
Submodule Overdrachtsbeheer van de eNB RRC-entiteit. De doel-eNB kan enkele dingen uitvoeren
Toegangscontroleprocedures. Dit gebeurt in de deelmodule Toelatingscontrole.
In eerste instantie accepteert deze submodule elk overdrachtsverzoek.

X2 interfaces
Het X2-model bevat twee interfaces:

· de X2-C-interface. Het is de besturingsinterface en wordt gebruikt om de X2-AP PDU's te verzenden
(dwz de elementaire procedures).

· de X2-U-interface. Het wordt gebruikt om de dragergegevens te verzenden wanneer die er zijn DL expeditie.

Figuur X2 interface protocol stacks toont de protocolstacks van de X2-U-interface en
X2-C-interface gemodelleerd in de simulator.
[afbeelding] X2-interfaceprotocolstacks.UNINDENT

X2-C
De X2-C-interface is het besturingsgedeelte van de X2-interface en wordt gebruikt voor het verzenden van de
X2-AP PDU's (dwz de elementaire procedures).

In de originele protocolstapel van het X2-interfacebesturingsvlak wordt SCTP gebruikt als transport
protocol, maar momenteel is het SCTP-protocol niet gemodelleerd in de ns-3-simulator en zijn
De uitvoering ervan valt buiten de scope van het project. Het UDP-protocol wordt gebruikt als datagram
georiënteerd protocol in plaats van het SCTP-protocol.

X2-U
De X2-U-interface wordt gebruikt om de dragergegevens te verzenden wanneer die er zijn DL expeditie tijdens de
uitvoering van de op X2 gebaseerde overdrachtsprocedure. Vergelijkbaar met wat er voor de S1-U is gedaan
interface worden datapakketten ingekapseld via GTP/UDP/IP wanneer ze hierover worden verzonden
koppel. Houd er rekening mee dat de EPS Bearer QoS niet wordt afgedwongen op de X2-U-koppelingen, zo wordt aangenomen
dat de overprovisioning van de verbindingsbandbreedte voldoende is om aan de QoS-vereisten te voldoen
van alle dragers.

X2 Service Interface
De X2-serviceinterface wordt door de RRC-entiteit gebruikt om berichten van de X2 te verzenden en te ontvangen
procedures. Het is verdeeld in twee delen:

· de EpcX2SapProvider een deel wordt geleverd door de X2-entiteit en gebruikt door de RRC-entiteit en

· de EpcX2Sapgebruiker een deel wordt geleverd door de RRC-entiteit en gebruikt door de RRC-entiteit.

De primitieven die worden ondersteund in ons X2-C-model worden hieronder beschreven
onderafdelingen.

X2-C primitieven voor overhandigen uitvoering
De volgende primitieven worden gebruikt voor de op X2 gebaseerde overdracht:

· OVERDRACHTSVERZOEK

· OVERDRACHTSVERZOEK BEVESTIGING

· VOORBEREIDING VAN DE OVERDRACHT IS MISLUKT

· SN-STATUSOVERDRACHT

· UE CONTEXT-VRIJGAVE

alle bovenstaande primitieven worden gebruikt door het momenteel geïmplementeerde RRC-model tijdens de
voorbereiding en uitvoering van de overdrachtsprocedure. Hun gebruik staat in wisselwerking met de RRC
staatsmachine; daarom zijn ze in ieder geval niet bedoeld om te worden gebruikt voor het aanpassen van code
tenzij het gewenst is om de RRC-statusmachine te wijzigen.

X2-C ITS primitieven
De volgende primitieven kunnen worden gebruikt om Self-Organized Network (SON) te implementeren
functionaliteiten:

· INFORMATIE LADEN

· BRONSTATUS-UPDATE

Merk op dat het huidige RRC-model deze primitieven niet daadwerkelijk gebruikt; ze zijn inbegrepen
in het model alleen maar om het mogelijk te maken om SON-algoritmen te ontwikkelen die zijn opgenomen in de RRC-logica
die er gebruik van maken.

Als eerste voorbeeld laten we hier zien hoe de belastinginformatieprimitief kan worden gebruikt. Wij nemen aan
dat de LteEnbRrc is gewijzigd om de volgende nieuwe lidvariabelen op te nemen:

std::vector
m_currentUlInterferenceOverloadIndicationList;
std::vector
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

voor een gedetailleerde beschrijving van het type van deze variabelen raden wij u aan het bestand te raadplegen
epc-x2-sap.h, de bijbehorende doxygen-documentatie en de verwijzingen daarin naar de
relevante secties van 3GPP TS 36.423. Neem nu aan dat deze variabelen dit tijdens runtime hebben gedaan
ingesteld op zinvolle waarden volgens de zojuist genoemde specificaties. Dan kunt u
voeg de volgende code toe in de LteEnbRrc-klasse-implementatie om een ​​lading te verzenden
informatie primitief:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicationList = m_currentUlInterferenceOverloadIndicationList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams params;
params.targetCellId = celId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (params);

Met de bovenstaande code kan de bron-eNB het bericht verzenden. De methode
LteEnbRrc::DoRecvLoadInformation zal worden gebeld wanneer de doel-eNB het bericht ontvangt.
De gewenste verwerking van de belastingsinformatie dient daarom daarin te worden gerealiseerd
methode.

In het volgende tweede voorbeeld laten we zien hoe de primitief voor het bijwerken van de resourcestatus wordt gebruikt.
We gaan ervan uit dat de LteEnbRrc is gewijzigd om het volgende nieuwe lid op te nemen
variabele:

EpcX2Sap::CellMeasurementResultItem m_cmri;

vergelijkbaar met voorheen, verwijzen we naar epc-x2-sap.h en de referenties daarin voor details
informatie over dit variabeletype. We gaan er opnieuw van uit dat de variabele al is geweest
ingesteld op een betekenisvolle waarde. Vervolgens kunt u de volgende code toevoegen om een
update van de bronstatus:

EpcX2Sap::ResourceStatusUpdateParams params;
params.targetCellId = celId;
params.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate (parameters);

Werkwijze eEnbRrc::DoRecvResourceStatusUpdate zal worden opgeroepen wanneer de doel-eNB ontvangt
het updatebericht voor de resourcestatus. De gewenste verwerking van dit bericht moet
daarom binnen die methode worden geïmplementeerd.

Ten slotte merken we op dat het instellen en verwerken van de juiste waarden voor de
variabele doorgegeven aan de hierboven beschreven primitieven wordt geacht specifiek te zijn voor de SON
algoritme dat wordt geïmplementeerd en valt daarom niet onder deze documentatie.

niet gesteund primitieven
Mobiliteit Robuustheid Optimalisatieprimitieven zoals Radio Link Failure-indicatie en
Overdrachtsrapport wordt in dit stadium niet ondersteund.

S11
De S11-interface biedt besturingsvlakinteractie tussen de SGW en de MME met behulp van de
GTPv2-C-protocol gespecificeerd in [TS29274]. In de simulator wordt deze interface gemodelleerd in een
ideale mode, met directe interactie tussen de SGW- en de MME-objecten, zonder
het feitelijk implementeren van de codering van de berichten en zonder deze daadwerkelijk te verzenden
PDU op elke link.

De S11-primitieven die worden gemodelleerd zijn:

· CREËER SESSIEVERZOEK

· CREËER SESSIERESPONS

· WIJZIG HET VERZOEK AAN TOONDER

· WIJZIG DE REACTIE VAN DE DRAGER

Van deze primitieven worden de eerste twee gebruikt bij de initiële UE-koppeling voor de
oprichting van de S1-U-dragers; de andere twee worden tijdens de overdracht gebruikt om te wisselen
S1-U-dragers van de bron-eNB naar de doel-eNB als gevolg van de ontvangst door
de MME van een PATH SWITCH REQUEST S1-AP-bericht.

Power Controle
In deze sectie wordt de ns-3-implementatie van Downlink en Uplink Power Control beschreven.

downlink Power Controle
Omdat sommige algoritmen voor frequentiehergebruik downlink-vermogensregeling vereisen, was deze functie dat wel
ook geïmplementeerd in ns-3.
[afbeelding] Volgordediagram van Downlink Power Control.UNINDENT

Figuur Volgorde diagram of downlink Power Controle toont het volgordediagram van de instelling
downlink P_A-waarde voor UE, waarbij de interacties tussen de RRC en de andere worden benadrukt
entiteiten. FR-algoritme activeert RRC om P_A-waarden voor UE te wijzigen. Dan begint RRC
RrcConnectionReconfiguration-functie om UE te informeren over nieuwe configuratie. Na
succesvolle RrcConnectionReconfiguration, RRC kan de P_A-waarde voor UE instellen door aan te roepen
functie SetPa van CphySap, waarde wordt opgeslagen in de nieuwe kaart m_paMap die P_A-waarden bevat
voor elke UE die door eNb wordt bediend.

Wanneer LteEnbPhy een nieuw subframe start, worden DCI-besturingsberichten verwerkt om de vector op te halen
gebruikte RB's. Nu is ook de functie GeneratePowerAllocationMap (uint16_t rnti, int rbId) ook
genaamd. Deze functie controleert de P_A-waarde voor UE, genereert stroom voor elke RB en slaat deze op
m_dlPowerAllocationMap. Dan wordt deze kaart gebruikt door
CreateTxPowerSpectralDensityWithPowerAllocation-functie om Ptr
txPsd.

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) is toegevoegd in
LteRrcSap::PhysicalConfigDedicated struct, die wordt gebruikt in RrcConnectionReconfiguration
proces.

Uplink Power Controle
Uplink-vermogensregeling regelt het zendvermogen van de verschillende uplink-fysiek
kanalen. Deze functionaliteit wordt beschreven in 3GPP TS 36.213 sectie 5.

Uplink Power Control is standaard ingeschakeld en kan worden uitgeschakeld via het attribuutsysteem:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (false));

Er zijn twee Uplink Power Control-mechanismen geïmplementeerd:

· Open Loop Uplink Power Control: het UE-zendvermogen is afhankelijk van de schatting ervan
het downlinkpadverlies en de kanaalconfiguratie

· Closed Loop Uplink Power Control: net als bij Open Loop kan eNB bovendien de UE besturen
zendvermogen door middel van expliciete Transmit Power Control TPC-opdrachten
verzonden in de downlink.

Om tussen deze twee typen mechanismen te schakelen, moet men de parameter wijzigen:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));

Standaard is Closed Loop Power Control ingeschakeld.

Twee modi of Gesloten Ringleiding Uplink Power Controle zijn beschikbaar:

· Absolute modus: TxPower wordt berekend met absolute TPC-waarden

· Accumulatieve modus: TxPower wordt berekend met geaccumuleerde TPC-waarden

Om tussen deze twee modi te schakelen, moet u de parameter wijzigen:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

Standaard is de accumulatiemodus ingeschakeld en worden TPC-opdrachten in DL-DCI door iedereen ingesteld
planners op 1, wat wordt toegewezen aan de waarde 0 in de accumulatiemodus.

Uplink Power Controle voor PUSCH
De instelling van het UE-zendvermogen voor een fysiek uplink gedeeld kanaal (PUSCH)
transmissie wordt als volgt gedefinieerd:

· Als de UE PUSCH verzendt zonder een gelijktijdige PUCCH voor de bedienende cel c, dan
het UE-zendvermogen P_{PUSCH,c}(i) voor PUSCH-transmissie in subframe i voor de
dienende cel c wordt gegeven door:

· Als de UE PUSCH gelijktijdig met PUCCH verzendt voor de bedienende cel c, dan is de UE
zendvermogen P_{PUSCH,c}(i) voor de PUSCH-transmissie in subframe i voor de
dienende cel c wordt gegeven door:

Aangezien Uplink Power Control voor PUCCH niet is geïmplementeerd, is dit geval niet geïmplementeerd
.

· Als de UE geen PUSCH verzendt voor de bedienende cel c, voor de accumulatie van
TPC-opdracht ontvangen met DCI-formaat 3/3A voor PUSCH, zal de UE aannemen dat de UE
zendvermogen P_{PUSCH,c}(i) voor de PUSCH-transmissie in subframe i voor de
dienende cel c wordt berekend door

waar:

· P_{CMAX,c}(i) is het geconfigureerde UE-zendvermogen gedefinieerd in 3GPP 36.101. Tafel
6.2.2-1 in subframe i voor het bedienen van cel c en {P}_{CMAX,c}(i) is de lineaire waarde
van P_{CMAX,c}(i). Standaardwaarde voor P_{CMAX,c}(i) is 23 dBm

· M_{PUSCH,c}(i) is de bandbreedte van de PUSCH-brontoewijzing, uitgedrukt in
aantal hulpbronblokken geldig voor subframe i en bedienende cel c.

· P_{O_PUSCH,c}(j) is een parameter die bestaat uit de som van een component
P_{O_NOMINAL_PUSCH,c}(j) geleverd door hogere lagen voor j={0,1} en een component
P_{O_UE_PUSCH,c}(j) geleverd door hogere lagen voor j={0,1} voor het bedienen van cel c.
Het SIB2-bericht moet worden uitgebreid om deze twee componenten te kunnen bevatten, maar momenteel
ze kunnen worden ingesteld via het attribuutsysteem:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::SetDefault ("ns3::LteUePowerControl::PoUePusch", IntegerValue (7));

· lpha_{c} (j) is een 3-bits parameter die door hogere lagen wordt geleverd voor ightinForelj=2,
Voor j=0,1, lpha_c in t 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1
lpha_{c} (j) = 1. Deze parameter kan worden geconfigureerd via attribuutsysteem:

Config::SetDefault ("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c} is de schatting van het padverlies van de downlink, berekend in de UE voor het bedienen van cel c
in dB en PL_{c} = referenceSignalPower – hogere laag gefilterde RSRP, waarbij
referenceSignalPower wordt geleverd door hogere lagen en RSRP. referentieSignalPower
wordt verstrekt in het SIB2-bericht

· en cond case is geïmplementeerd.

· f_{c}(i) is onderdeel van Closed Loop Power Control. Het is de huidige PUSCH-kracht
controle-aanpassingsstatus voor bedienende cel c.

Als de accumulatiemodus is ingeschakeld, wordt f_{c}(i) gegeven door:

waarbij: elta_{PUSCH,c} een correctiewaarde is, ook wel een TPC-commando genoemd
en is opgenomen in PDCCH met DCI; elta_{PUSCH,c}(i - K_{PUSCH}) werd ingeschakeld
PDCCH/EPDCCH met DCI voor het bedienen van cel c op subframe (i - K_{PUSCH}); K_{PUSCH} =
4 voor FDD.

Als UE P_{CMAX,c}(i) heeft bereikt voor het bedienen van cel c, positieve TPC-opdrachten voor
serveercel c worden niet geaccumuleerd. Als UE het minimale vermogen heeft bereikt, negatief
TPC-opdrachten worden niet verzameld. Het minimale UE-vermogen is gedefinieerd in TS36.101
sectie 6.2.3. Standaardwaarde is -40 dBm.

Als de accumulatiemodus niet is ingeschakeld, wordt f_{c}(i) gegeven door:

waarbij: elta_{PUSCH,c} een correctiewaarde is, ook wel een TPC-commando genoemd
en is opgenomen in PDCCH met DCI; elta_{PUSCH,c}(i - K_{PUSCH}) werd ingeschakeld
PDCCH/EPDCCH met DCI voor het bedienen van cel c op subframe (i - K_{PUSCH}); K_{PUSCH} =
4 voor FDD.

Toewijzing van TPC-opdrachtveld in DCI-formaat 0/3/4 naar absoluut en geaccumuleerd
elta_{PUSCH,c}-waarden zijn gedefinieerd in TS36.231 sectie 5.1.1.1 Tabel 5.1.1.1-2

Uplink Power Controle voor PUCCH
Omdat alle uplink-controleberichten ideale berichten zijn en geen radio verbruiken
bronnen is Uplink Power Control voor PUCCH niet nodig en wordt niet geïmplementeerd.

Uplink Power Controle voor SRS
De instelling van het UE-zendvermogen P_{SRS} voor de SRS die op subframe i wordt verzonden
dienende cel c wordt gedefinieerd door

waar:

· P_{CMAX,c}(i) is het geconfigureerde UE-zendvermogen gedefinieerd in 3GPP 36.101. Tafel
6.2.2-1. Standaardwaarde voor P_{CMAX,c}(i) is 23 dBm

· P_{SRS_OFFSET,c}(m) wordt semi-statisch geconfigureerd door hogere lagen voor m=0,1 voor
serveercel c. Voor SRS-transmissie gegeven triggertype 0, dan m=0,1 en voor SRS
transmissie gegeven triggertype 1 en dan m=1. Voor K_{s} = 0 is P_Srs_Offset_Value
berekend met vergelijking:

Deze parameter kan worden geconfigureerd per attribuutsysteem:

Config::SetDefault ("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c} is de bandbreedte van de SRS-transmissie in subframe i voor het bedienen van de cel
c uitgedrukt in aantal resourceblokken. In de huidige implementatie wordt SRS verzonden
over de gehele UL-bandbreedte.

· f_{c}(i) is de huidige PUSCH-vermogensregelingsstatus voor het bedienen van cel c,
zoals gedefinieerd in Uplink Power Controle voor PUSCH

· P_{O_PUSCH,c}(j) en lpha_{c}(j) zijn parameters zoals gedefinieerd in Uplink Power
Controle voor PUSCH, waarbij j = 1 .

Fractioneel Frequentie visfuik
Overzicht
In dit gedeelte wordt de ns-3-ondersteuning voor algoritmen voor fractioneel frequentiehergebruik beschreven. Alle
geïmplementeerde algoritmen worden beschreven in [ASHamza2013]. Momenteel zijn er 7 FR-algoritmen
geïmplementeerd:

· ns3::LteFrNoOpAlgoritme

· ns3::LteFrHardAlgoritme

· ns3::LteFrStrictAlgoritme

· ns3::LteFrSoftAlgoritme

· ns3::LteFfrSoftAlgoritme

· ns3::LteFfrVerbeterd algoritme

· ns3::LteFfrDistributedAlgoritme

Er is een nieuwe LteFfrAlgorithm-klasse gemaakt en het is een abstracte klasse voor frequentiehergebruik
implementatie van algoritmen. Ook zijn er twee nieuwe SAP's tussen FR-Scheduler en FR-RRC toegevoegd.
[afbeelding] Volgordediagram van planning met FR-algoritme.UNINDENT

Figuur Volgorde diagram of Scheduling met FR algoritme toont het sequentiediagram van
planningsproces met FR-algoritme. In het begin van het planningsproces, planner
vraagt ​​FR-entiteit naar beschikbare RBG's. Volgens de implementatie retourneert FR alle RBG's
beschikbaar in cel of filter ze op basis van het beleid. Toen ik er een paar probeerde toe te wijzen
RBG naar UE, planner vraagt ​​FR-entiteit of deze RBG is toegestaan ​​voor deze UE. Wanneer FR terugkeert
waar, de planner kan deze RBG aan deze UE toewijzen, als dat niet het geval is, controleert de planner een andere RBG
voor deze EU. Ook hier hangt de FR-reactie af van de implementatie en het beleid dat op UE wordt toegepast.

ondersteunde FR algoritmen
Nee Frequentie visfuik
Het NoOp FR-algoritme (LteFrNoOpAlgorithm-klasse) is een implementatie van Full Frequency Reuse
Dit betekent dat er geen frequentiepartitionering wordt uitgevoerd tussen eNB's van hetzelfde netwerk
(frequentiehergebruikfactor, FRF is gelijk aan 1). eNBs gebruikt de volledige systeembandbreedte en -overdracht
met uniforme macht over alle RBG's. Het is het eenvoudigste schema en de basismanier van
exploiteren van een LTE-netwerk. Dit schema maakt het mogelijk om de hoge piekdatasnelheid te bereiken. Maar
aan de andere kant, vanwege de hoge interferentieniveaus van naburige cellen, celrand
de gebruikersprestaties zijn zeer beperkt.

Figuur Vol Frequentie visfuik schema hieronder vindt u de frequentie en het energieplan voor Volledig
Frequentiehergebruikschema.
[image] Schema voor volledig frequentiehergebruik.UNINDENT

In ns-3 staat het NoOp FR-algoritme de planner altijd toe om de volledige bandbreedte te gebruiken en staat dit toe
alle UE's om elke RBG te gebruiken. Het doet eenvoudigweg niets nieuws (dwz het beperkt de eNB niet
bandbreedte, FR-algoritme is uitgeschakeld), is dit de eenvoudigste implementatie van FrAlgorithm
class en wordt standaard in eNb geïnstalleerd.

Hard Frequentie visfuik
Het Hard Frequency Reuse-algoritme biedt het eenvoudigste schema dat reductie mogelijk maakt
interferentieniveau tussen cellen. In dit schema wordt de gehele frequentiebandbreedte verdeeld
weinig (meestal 3, 4 of 7) onsamenhangende subbanden. Aangrenzende eNB's worden toegewezen met verschillende
subband. De frequentiehergebruikfactor is gelijk aan het aantal subbanden. Dit schema maakt het mogelijk
Verminder ICI aan de celrand aanzienlijk, waardoor de prestaties van mobiele gebruikers worden verbeterd.
Maar vanwege het feit dat elke eNB slechts een deel van de gehele bandbreedte gebruikt, ontstaat er een piekdatasnelheid
het niveau wordt tevens verlaagd met de factor gelijk aan de hergebruikfactor.

Figuur Hard Frequentie visfuik schema hieronder vindt u de frequentie en het energieplan voor Hard
Frequentiehergebruikschema.
[afbeelding] Hergebruikschema voor harde frequenties.UNINDENT

In onze implementatie heeft het Hard FR-algoritme alleen vector van RBG's beschikbaar voor eNB
en geef het door aan MAC Scheduler tijdens planningsfuncties. Wanneer de planner vraagt ​​of RBG dat is
toegestaan ​​voor specifieke UE retourneert het altijd waar.

Streng Frequentie visfuik
Het Strict Frequency Reuse-schema is een combinatie van Full en Hard Frequency Reuse-schema's. Het
bestaat uit het verdelen van de systeembandbreedte in twee delen, die verschillend zullen zijn
frequentie hergebruik. In elk celinterieur wordt één gemeenschappelijke subband van de systeembandbreedte gebruikt
(frequentiehergebruik-1), terwijl het andere deel van de bandbreedte wordt verdeeld over de
naburige eNB's zoals bij hergebruik van harde frequenties (frequentiehergebruik-N, N>1), om te creëren
één subband met een laag interferentieniveau tussen de cellen in elke sector. Centrum UE's zullen dat zijn
verleend met de volledig hergebruikte frequentiebrokken, terwijl celrand-UE's met orthogonale brokken.
Het betekent dat interne UE's van één cel geen enkel spectrum delen met rand-UE's van
tweede cel, wat de interferentie voor beide vermindert. Zoals u kunt zien, vereist Strict FR a
totaal van N + 1 subbanden, en maakt het mogelijk om RFR in het midden tussen 1 en 3 te bereiken.

Figuur Streng Frequentie visfuik schema hieronder vindt u de frequentie en het energieplan voor Strict
Frequentiehergebruikschema met een celrandhergebruikfactor van N = 3.
[afbeelding] Strenge regeling voor hergebruik van frequenties.UNINDENT

In onze implementatie heeft het Strict FR-algoritme twee kaarten, één voor elke subband. Als EU
kan worden bediend binnen een privé-subband, wordt de RNTI ervan toegevoegd aan de m_privateSubBandUe-kaart. Als
UE kan worden bediend binnen de gemeenschappelijke subband, de RNTI ervan wordt toegevoegd aan de m_commonSubBandUe-kaart.
Een strikt FR-algoritme moet beslissen binnen welke subband UE moet worden bediend. Het gebruikt
UE-metingen geleverd door RRB en vergelijk deze met de signaalkwaliteitsdrempel (dit
parameter kan eenvoudig worden afgestemd via het attribuutmechanisme). Drempel heeft invloed op
verhouding tussen binnen- en celradius.

Soft /Pastel Frequentie visfuik
In het Soft Frequency Reuse (SFR)-schema zendt elke eNb over de gehele systeembandbreedte,
maar er zijn twee subbanden, binnen UE's worden ze met verschillende vermogensniveaus bediend. Sinds
celcentrum-UE's delen de bandbreedte met aangrenzende cellen, ze zenden meestal op een lagere snelheid
energieniveau dan de celrand-UE's. SFR is bandbreedte-efficiënter dan Strict FR,
omdat het de volledige systeembandbreedte gebruikt, maar het resulteert ook in meer interferentie voor beide
celinterieur en randgebruikers.

Er zijn twee mogelijke versies van het SFR-schema:

· In de eerste versie kan de subband die specifiek is bedoeld voor de celrand-UE's ook worden gebruikt
de celcentrum-UE's, maar met een lager energieniveau en alleen als deze niet bezet zijn
de celrand-UE's. De celcentrum-subband is alleen beschikbaar voor de centrale UE's. Figuur
Soft /Pastel Frequentie visfuik schema versie 1 hieronder vindt u de frequentie en het energieplan voor
deze versie van het Soft Frequency Reuse-schema.
[afbeelding] Soft Frequency Reuse-schema versie 1.UNINDENT

· In de tweede versie hebben celcentrum-UE's geen toegang tot de celrand-subband. In
Op deze manier kan elke cel de volledige systeembandbreedte gebruiken en tegelijkertijd de bandbreedte verminderen
interferentie met de cellen van de buren. Aan de andere kant, een lager ICI-niveau op de
celrand wordt bereikt ten koste van een lager spectrumgebruik. Figuur Soft /Pastel
Frequentie visfuik schema versie 2 hieronder vindt u hiervoor de frequentie en het energieplan
versie van het Soft Frequency Reuse-schema.
[afbeelding] Soft Frequency Reuse-schema versie 2.UNINDENT

Het SFR-algoritme onderhoudt twee kaarten. Als UE met een lager vermogensniveau moet worden geserveerd, is dat het geval
RNTI is toegevoegd aan de m_lowPowerSubBandUe-kaart. Als UE met meer macht moet worden bediend
niveau, wordt de RNTI toegevoegd aan de m_highPowerSubBandUe-kaart. Om te beslissen met welk vermogensniveau
UE moet worden bediend. Het SFR-algoritme maakt gebruik van UE-metingen en vergelijkt deze met
drempelwaarde. Signaalkwaliteitsdrempel en PdschConfigDedicated (dwz P_A-waarde) voor binnen
en buitengebied kunnen worden geconfigureerd via het attributensysteem. SFR maakt gebruik van Downlink Power
Controle hier beschreven.

Soft /Pastel Fractioneel Frequentie visfuik
Soft Fractional Frequency Reuse (SFFR) is een combinatie van Strict en Soft Frequency
Hergebruikschema's. Hoewel Strict FR geen gebruik maakt van de subbanden die zijn toegewezen aan de buitenste regio in de
aangrenzende cellen gebruikt zachte FFR deze subbanden voor de binnenste UE's met een laag zendvermogen. Als
Als resultaat gebruikt de SFFR, net als SFR, de subband met een hoog zendvermogensniveau en met een laag zendvermogen
zendvermogensniveau. In tegenstelling tot de Soft FR en net als Strict FR, gebruikt de Soft FFR de gemeenschappelijke
subband die de doorvoer van de interne gebruikers kan verbeteren.

Figuur Soft /Pastel Fractioneel Fractioneel Frequentie visfuik schema hieronder presenteert frequentie en
energieplan voor hergebruik van zachte fractionele frequenties.
[afbeelding] Zacht fractioneel Fractioneel frequentiehergebruikschema.UNINDENT

Verbeterde Fractioneel Frequentie visfuik
Enhanced Fractional Frequency Reuse (EFFR), beschreven in [ZXie2009], definieert 3 celtypen
voor direct aangrenzende cellen in een cellulair systeem, en reserves voor elk celtype a
deel van de gehele genoemde frequentieband Primair Segment, die tussen verschillende typen cellen
moet orthogonaal zijn. De overige subkanalen vormen de Secundair Segment. De
Primair Segment van een celtype is tegelijkertijd een onderdeel van de Secundair Segmenten
behorend tot de andere twee celtypen. Elke cel kan alle subkanalen van zijn cel bezetten Primair
Segment naar believen, terwijl slechts een deel van de subkanalen in de Secundair Segment kan worden gebruikt
door deze cel op een interferentiebewuste manier Primair Segment van elke cel is verdeeld
in een hergebruik-3 deel en hergebruik-1 deel. Het hergebruik-1 deel kan door alle typen cellen worden hergebruikt
in het systeem, terwijl het hergebruik-3-onderdeel uitsluitend kan worden hergebruikt door een ander, hetzelfde type
cellen (dwz de hergebruik-3 subkanalen kunnen niet worden hergebruikt door direct aangrenzende cellen). Op
the Secundair Segment cel fungeert als gast, en het bezetten van secundaire subkanalen is dat ook
feitelijk de primaire subkanalen die tot de direct aangrenzende cellen behoren, hergebruiken
hergebruiken op de Secundair Segment door elke cel moet voldoen aan twee regels:

· controleren vóór gebruik

· hergebruik van hulpbronnen op basis van SINR-schatting

Elke cel luistert voortdurend naar elk secundair subkanaal. En vóór de bezetting, het
maakt SINR-evaluatie op basis van de verzamelde kanaalkwaliteitsinformatie (CQI) en
kiest middelen met de beste schattingswaarden voor hergebruik. Als de CQI-waarde voor RBG hoger is
geconfigureerde drempel voor een bepaalde gebruiker, kan verzending voor deze gebruiker hiermee worden uitgevoerd
RBG.

In [ZXie2009] wordt het planningsproces beschreven, dat bestaat uit drie stappen en twee
het plannen van beleid. Omdat geen van de momenteel geïmplementeerde planners dit mogelijk maakt
gedrag werd enige vereenvoudiging toegepast. In onze implementatie kunnen hergebruik-1 subkanalen dat wel
mag alleen worden gebruikt door gebruikers van mobiele centra. Reuse-3-subkanalen kunnen alleen door edge-gebruikers worden gebruikt
als er geen edge-gebruiker is, kan de transmissie voor gebruikers van celcentra worden aangeboden in hergebruik-3
subkanalen.

Figuur Verbeterde Fractioneel Fractioneel Frequentie visfuik schema hieronder presenteert frequentie en
energieplan voor verbeterd fractioneel frequentiehergebruik.
[afbeelding] Verbeterd fractioneel fractioneel frequentiehergebruikschema.UNINDENT

Distributed Fractioneel Frequentie visfuik
Dit gedistribueerde algoritme voor hergebruik van fractionele frequenties werd gepresenteerd in [DKimura2012]. Het
optimaliseert automatisch celrand-subbanden door zich te concentreren op gebruikersdistributie (in
in het bijzonder de distributie van ontvangstvermogen). Dit algoritme selecteert adaptief RB's voor
celrand-subband op basis van coördinatie-informatie van aangrenzende cellen en waarschuwt
de basisstations van de aangrenzende cellen, welke RB's zijn geselecteerd om te gebruiken in de randsubband.
Het basisstation van elke cel gebruikt de ontvangen informatie en de volgende vergelijking
bereken celrandbandmetriek A_{k} voor elke RB.

waar J een set buurcellen is, is X_{j,k}=0,1 de RNTP van de j-de buurcel.
Er is een waarde van 1 nodig als de k-de RB in de j-de buurcel wordt gebruikt als celrand
subband en anders 0. Het symbool w_{j} geeft het gewicht aan ten opzichte van aangrenzende cel j,
dat wil zeggen het aantal gebruikers waarvoor het verschil tussen de kracht van het signaal
ontvangen van de bedienende cel i en de kracht van het signaal ontvangen van de aangrenzende cel
cel j is kleiner dan een drempelwaarde (dat wil zeggen, het aantal gebruikers nabij de celrand in de
servicecel). Een groot ontvangen machtsverschil betekent dat mobiele gebruikers in de i-de zitten
cel ondervindt sterke interferentie van de j-de cel.

De RB waarvoor de metriek A_{k} het kleinst is, wordt geacht er het minst door te worden beïnvloed
interferentie van een andere cel. De dienende cel selecteert een geconfigureerd aantal RB's als
celrand-subband in oplopende volgorde van A_{k}. Als gevolg hiervan zijn de RB's waarin een kleine
aantal mobiele edge-gebruikers ontvangt hoge interferentie van aangrenzende basisstations
gekozen.

De bijgewerkte RNTP wordt vervolgens naar alle aangrenzende cellen verzonden. Om het zinloze te vermijden
oscillatie van celrandbandselectie negeert een basisstation een RNTP van een andere basis
station dat een grotere cel-ID heeft dan het basisstation.

Door dit proces over alle cellen te herhalen, kunnen RB's aan celrandgebieden worden toegewezen
te optimaliseren via het systeem en aan te passen aan veranderingen in de gebruikersdistributie.

Figuur Volgorde diagram of Distributed Frequentie visfuik schema hieronder geeft de volgorde weer
diagram van het gedistribueerde fractionele frequentiehergebruikschema.
[afbeelding] Volgordediagram van Distributed Frequency Reuse Scheme.UNINDENT

helpers
Er worden twee helperobjecten gebruikt om simulaties op te zetten en de verschillende componenten te configureren.
Deze objecten zijn:

· LteHelper, dat zorgt voor de configuratie van het LTE-radiotoegangsnetwerk, zoals
evenals het coördineren van de installatie en vrijgave van EPS-dragers. De LteHelper klasse
biedt zowel de API-definitie als de implementatie ervan.

· EpcHelper, die zorgt voor de configuratie van de Evolved Packet Core. De
EpcHelper class is een abstracte basisklasse die alleen de API-definitie biedt; de
de implementatie wordt gedelegeerd aan onderliggende klassen om verschillende EPC mogelijk te maken
netwerk modellen.

Het is mogelijk om eenvoudige LTE-only simulaties te maken door gebruik te maken van LteHelper alleen, of tegen
creëer complete LTE-EPC-simulaties door beide te gebruiken LteHelper en EpcHelper. Wanneer beiden
Er worden helpers gebruikt, ze gaan op een meester-slaaf-manier met elkaar om LteHelper de Meester zijn
dat rechtstreeks samenwerkt met het gebruikersprogramma, en EpcHelper "onder de motorkap" werken
configureer de EPC op basis van expliciete methoden die worden aangeroepen door LteHelper. De exacte interacties zijn
weergegeven in de figuur Volgorde diagram of the wisselwerking tussen LteHelper en
EpcHelper.
[afbeelding] Volgordediagram van de interactie tussen LteHelper en EpcHelper.UNINDENT

Gebruiker Documentatie
Achtergrond
We gaan ervan uit dat de lezer al bekend is met het gebruik van de ns-3-simulator om generieke programma's uit te voeren
simulatie programma's. Als dit niet het geval is, raden wij de lezer ten zeerste aan om dit te raadplegen
[ns3tutorial].

Gebruik Overzicht
Het ns-3 LTE-model is een softwarebibliotheek die de simulatie van LTE-netwerken mogelijk maakt,
optioneel inclusief de Evolved Packet Core (EPC). Het proces om zoiets uit te voeren
simulaties omvatten doorgaans de volgende stappen:

1. Definiëren van the scenario gesimuleerd worden

2. Schrijven a simulatie programma waarmee het gewenste scenario wordt nagebootst
topologie/architectuur. Dit wordt gedaan door toegang te krijgen tot de ns-3 LTE-modelbibliotheek met behulp van de
ns3::LteHelper API gedefinieerd in src/lte/helper/lte-helper.h.

3. Specificeren configuratie parameters van de objecten die worden gebruikt voor de
simulatie. Dit kan gedaan worden met behulp van invoerbestanden (via de ns3::ConfigStore) Of
direct binnen het simulatieprogramma.

4. Configure the gewenste uitvoer geproduceerd door de simulator

5. lopen de simulatie.

Al deze aspecten worden in de volgende paragrafen aan de hand van praktische oefeningen toegelicht
voorbeelden.

Basic simulatie programma
Hier is het minimale simulatieprogramma dat nodig is om een ​​LTE-only simulatie uit te voeren
(zonder EPC).

1. Oorspronkelijke standaard:

#erbij betrekken
#erbij betrekken
#erbij betrekken
#erbij betrekken

naamruimte ns3 gebruiken;

int hoofd (int argc, char *argv[])
{
// de rest van het simulatieprogramma volgt

2. Maak een LteHelper voorwerp:

Ptr lteHelper = CreateObject ();

Hierdoor worden enkele algemene objecten geïnstantieerd (bijvoorbeeld het Channel-object) en wordt de
methoden om eNB's en UE's toe te voegen en te configureren.

3. creëren Knooppunt objecten voor de eNB(s) en de UE’s:

NodeContainer enbNodes;
enbNodes.Create (1);
NodeContainer ueNodes;
ueNodes.Create (2);

Houd er rekening mee dat de bovenstaande knooppuntinstanties op dit moment nog steeds geen LTE-protocol hebben
stapel geïnstalleerd; het zijn gewoon lege knooppunten.

4. Configureer het mobiliteitsmodel voor alle knooppunten:

MobilityHelper mobiliteit;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobiliteit.Installeren (enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobiliteit.Installeren (ueNodes);

Het bovenstaande plaatst alle knooppunten op de coördinaten (0,0,0). Raadpleeg de
documentatie van het ns-3 mobiliteitsmodel voor hoe u uw eigen positie kunt bepalen of configureren
knooppunt beweging.

5. Installeer een LTE-protocolstack op de eNB(s):

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. Installeer een LTE-protocolstack op de UE's:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. Sluit de UE's aan op een eNB. Hierdoor wordt elke UE geconfigureerd volgens de eNB
configuratie en maak er een RRC-verbinding tussen:

lteHelper->Bijvoegen (ueDevs, enbDevs.Get (0));

8. Activeer een gegevensradiodrager tussen elke UE en de eNB waaraan deze is gekoppeld:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer-drager (q);
lteHelper->ActivateDataRadioBearer (ueDevs, drager);

deze methode activeert ook twee generatoren voor verzadigingsverkeer voor die drager, één
in uplink en één in downlink.

9. Stel de stoptijd in:

Simulator::Stop (Seconden (0.005));

Dit is nodig, anders duurt de simulatie eeuwig, omdat (onder andere) de
start-of-subframe-gebeurtenis wordt herhaaldelijk gepland, en de ns-3-simulatorplanner zal dat ook doen
dus nooit zonder evenementen.

10. Voer de simulatie uit:

Simulator::Uitvoeren ();

11. Opruimen en afsluiten:

Simulator::Vernietigen ();
0 terug;
}

Raadpleeg [ns3tutorial] voor het compileren en uitvoeren van simulatieprogramma's.

Configuratie of LTE model parameters
Alle relevante LTE-modelparameters worden beheerd via het ns-3-attributensysteem.
Raadpleeg de [ns3tutorial] en [ns3manual] voor gedetailleerde informatie over alle
mogelijke methoden om dit te doen (omgevingsvariabelen, C++ API, GtkConfigStore...).

Hieronder vatten we kort samen hoe u dit kunt doen met behulp van invoerbestanden samen met
de ns-3 ConfigStore. Allereerst moet u het volgende in uw simulatie plaatsen
programma, direct daarna hoofd- () begint:

Opdrachtregel cmd;
cmd.Parse (argc, argv);
ConfigStore invoerConfig;
inputConfig.ConfigureDefaults ();
// opnieuw parseren, zodat u de standaardwaarden vanaf de opdrachtregel kunt overschrijven
cmd.Parse (argc, argv);

Om het bovenstaande te laten werken, moet u ervoor zorgen dat u dat ook doet #include "ns3/config-store.h". Maak nu een
tekstbestand met de naam (bijvoorbeeld) invoer-defaults.txt het specificeren van de nieuwe standaardwaarden die
die u voor bepaalde attributen wilt gebruiken:

standaard ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
standaard ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
standaard ns3::LteEnbNetDevice::UlBandbreedte "25"
standaard ns3::LteEnbNetDevice::DlBandbreedte "25"
standaard ns3::LteEnbNetDevice::DlEarfcn "100"
standaard ns3::LteEnbNetDevice::UlEarfcn "18100"
standaard ns3::LteUePhy::TxPower "10"
standaard ns3::LteUePhy::NoiseFiguur "9"
standaard ns3::LteEnbPhy::TxPower "30"
standaard ns3::LteEnbPhy::NoiseFiguur "5"

Stel dat uw simulatieprogramma wordt aangeroepen src/lte/examples/lte-sim-with-input, Kunt u
geef deze instellingen nu op de volgende manier door aan het simulatieprogramma:

./waf --command-template="%s --ns3::ConfigStore::Bestandsnaam=input-defaults.txt --ns3::ConfigStore::Mode=Laden --ns3::ConfigStore::FileFormat=RawText" --voer src/lte/examples/lte-sim-with-input uit

Bovendien kunt u met het volgende commando een sjablooninvoerbestand genereren:

./waf --command-template="%s --ns3::ConfigStore::Bestandsnaam=input-defaults.txt --ns3::ConfigStore::Mode=Opslaan --ns3::ConfigStore::FileFormat=RawText" --voer src/lte/examples/lte-sim-with-input uit

merk op dat het bovenstaande in het bestand wordt geplaatst invoer-defaults.txt allen de standaardwaarden die
zijn geregistreerd in uw specifieke versie van de simulator, inclusief veel niet-LTE
attributen.

Configure LTE MAC-adres Scheduler
Er zijn verschillende soorten LTE MAC-plannergebruikers die hier kunnen kiezen. Gebruiker kan het volgende gebruiken
codes om het plannertype te definiëren:

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // FD-MT-planner
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // TD-MT-planner
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // TTA-planner
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // FD-BET-planner
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // TD-BET-planner
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // FD-TBFQ-planner
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // TD-TBFQ-planner
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); //PSS-planner

TBFQ en PSS hebben meer parameters dan andere planners. Gebruikers kunnen deze parameters definiëren
op de volgende manier:

* TBFQ-planner::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(uwwaarde)); // standaardwaarde -625000 bytes (-5Mb)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(uwwaarde)); // standaardwaarde 625000 bytes (5Mb)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(uwwaarde)); // standaardwaarde 1 byte
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(uwwaarde)); // standaardwaarde 0

* PSS-planner::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(uwwaarde)); // het maximale aantal UE geselecteerd door TD-planner
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // PF-plannertype in PSS

In TBFQ zijn de standaardwaarden van de schuldlimiet en de kredietlimiet ingesteld op -5Mb en 5Mb
respectievelijk gebaseerd op papier [FABokhari2009]. De huidige implementatie houdt geen rekening mee
kredietdrempel (C = 0). Als de gebruiker in PSS nMux niet definieert, zal PSS deze waarde instellen op
de helft van de totale EU. De standaard FD-planner is PFsch.

Bovendien moeten de tokengeneratiesnelheid in TBFQ en de doelbitsnelheid in PSS hetzelfde zijn
geconfigureerd door Guarantee Bit Rate (GBR) of Maximum Bit Rate (MBR) in epc-drager QoS
parameters. Gebruikers kunnen de volgende codes gebruiken om GBR en MBR te definiëren in zowel downlink- als
uplink:

Ptr lteHelper = CreateObject ();
enum EpsBearer::Qci q = EpsBearer::uwwaarde; // definieer Qci-type
GbrQosInformatie qos;
qos.gbrDl = jouwwaarde; // Downlink GBR
qos.gbrUl = jouwwaarde; // Uplink GBR
qos.mbrDl = jouwwaarde; // Downlink-MBR
qos.mbrUl = jouwwaarde; // Uplink-MBR
EpsBearer-drager (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, bearer, EpcTft::Default ());

Bij PSS wordt TBR verkregen van GBR in QoS-parameters op dragerniveau. In TBFQ, tokengeneratie
snelheid wordt verkregen uit de MBR-instelling in QoS-parameters op dragerniveau, die daarom
moet consistent worden geconfigureerd. Voor verkeer met constante bitsnelheid (CBR) wordt dit aanbevolen
om MBR in te stellen op GBR. Voor Variance Bit Rate (VBR)-verkeer wordt aanbevolen om MBR k-tijden in te stellen
groter dan GBR om de piekverkeerssnelheid te dekken. In de huidige implementatie is k dat
op basis van papier ingesteld op drie [FABokhari2009]. Bovendien doet de huidige versie van TBFQ dat niet
houd rekening met de lengte van de RLC-header en PDCP-header in MBR en GBR. Een andere parameter in TBFQ is
aankomstsnelheid van pakketten. Deze parameter wordt berekend binnen de planner en is gelijk aan het verleden
gemiddelde doorvoer die wordt gebruikt in de PF-planner.

Veel nuttige kenmerken van het LTE-EPC-model zullen hieronder worden beschreven
onderafdelingen. Toch zijn er veel kenmerken die niet expliciet worden vermeld in de
ontwerp- of gebruikersdocumentatie, maar die duidelijk zijn gedocumenteerd met behulp van het ns-3-attribuut
systeem. U kunt eenvoudig een lijst met de kenmerken van een bepaald object afdrukken
hun beschrijving en standaardwaarde worden doorgegeven --PrintAttributen= naar een simulatieprogramma,
soortgelijk:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

Je kunt het ook met andere LTE- en EPC-objecten proberen, zoals dit:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

Simulatie uitgang
Het ns-3 LTE-model ondersteunt momenteel de uitvoer naar bestand van PHY-, MAC-, RLC- en PDCP-niveau
Key Performance Indicators (KPI's). Je kunt het op de volgende manier inschakelen:

Ptr lteHelper = CreateObject ();

// configureer hier het volledige simulatiescenario...

lteHelper->EnablePhyTraces ();
lteHelper->MacTraces inschakelen ();
lteHelper->EnableRlcTraces ();
lteHelper->EnablePdcpTraces ();

Simulator::Uitvoeren ();

RLC- en PDCP-KPI's worden berekend over een tijdsinterval en opgeslagen in ASCII-bestanden, twee voor
RLC KPI’s en twee voor PDCP KPI’s, telkens één voor uplink en één voor downlink. De tijd
De intervalduur kan worden geregeld met behulp van het attribuut
ns3::RadioBearerStatsCalculator::EpochDuur.

De kolommen van de RLC KPI-bestanden zijn als volgt (hetzelfde voor uplink en downlink):

1. starttijd van het meetinterval in seconden sinds het begin van de simulatie

2. Eindtijd van het meetinterval in seconden sinds het begin van de simulatie

3. Mobiele ID

4. unieke UE-ID (IMSI)

5. celspecifieke UE ID (RNTI)

6. Logisch kanaal-ID

7. Aantal verzonden RLC PDU's

8. Totaal aantal verzonden bytes.

9. Aantal ontvangen RLC PDU's

10. Totaal ontvangen bytes

11. Gemiddelde RLC PDU-vertraging in seconden

12. Standaardafwijking van de RLC PDU-vertraging

13. Minimumwaarde van de RLC PDU-vertraging

14. Maximale waarde van de RLC PDU-vertraging

15. Gemiddelde RLC PDU-grootte, in bytes

16. Standaardafwijking van de RLC PDU-grootte

17. Minimale RLC PDU-grootte

18. Maximale RLC PDU-grootte

Op dezelfde manier zijn de kolommen van de PDCP KPI-bestanden als volgt (opnieuw hetzelfde voor uplink
en downlink):

1. starttijd van het meetinterval in seconden sinds het begin van de simulatie

2. Eindtijd van het meetinterval in seconden sinds het begin van de simulatie

3. Mobiele ID

4. unieke UE-ID (IMSI)

5. celspecifieke UE ID (RNTI)

6. Logisch kanaal-ID

7. Aantal verzonden PDCP PDU's

8. Totaal aantal verzonden bytes.

9. Aantal ontvangen PDCP PDU's

10. Totaal ontvangen bytes

11. Gemiddelde PDCP PDU-vertraging in seconden

12. Standaardafwijking van de PDCP PDU-vertraging

13. Minimumwaarde van de PDCP PDU-vertraging

14. Maximale waarde van de PDCP PDU-vertraging

15. Gemiddelde PDCP PDU-grootte, in bytes

16. Standaardafwijking van de PDCP PDU-grootte

17. Minimale PDCP PDU-grootte

18. Maximale PDCP PDU-grootte

MAC-KPI's zijn in feite een spoor van de resourcetoewijzing die door de planner wordt gerapporteerd
het begin van elk subframe. Ze worden opgeslagen in ASCII-bestanden. Voor downlink MAC KPI's is de
formaat is het volgende:

1. Simulatietijd in seconden waarop de toewijzing door de planner wordt aangegeven

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. Framenummer

5. Subframenummer

6. celspecifieke UE ID (RNTI)

7. MCS van tuberculose 1

8. grootte van TB 1

9. MCS van TB 2 (0 indien niet aanwezig)

10. grootte van TB 2 (0 indien niet aanwezig)

terwijl voor uplink MAC KPI's het formaat is:

1. Simulatietijd in seconden waarop de toewijzing door de planner wordt aangegeven

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. Framenummer

5. Subframenummer

6. celspecifieke UE ID (RNTI)

7. MCS van tuberculose

8. grootte van tuberculose

De namen van de bestanden die worden gebruikt voor MAC KPI-uitvoer kunnen worden aangepast via de ns-3-attributen
ns3::MacStatsCalculator::DlOutputBestandsnaam en ns3::MacStatsCalculator::UlOutputBestandsnaam.

PHY KPI's worden verdeeld in zeven verschillende bestanden, configureerbaar via de attributen

1. ns3::PhyStatsCalculator::DlRsrpSinrBestandsnaam

2. ns3::PhyStatsCalculator::UeSinrBestandsnaam

3. ns3::PhyStatsCalculator::InterferentieBestandsnaam

4. ns3::PhyStatsCalculator::DlTxOutputBestandsnaam

5. ns3::PhyStatsCalculator::UlTxOutputBestandsnaam

6. ns3::PhyStatsCalculator::DlRxOutputBestandsnaam

7. ns3::PhyStatsCalculator::UlRxOutputBestandsnaam

In het RSRP/SINR-bestand is de volgende inhoud beschikbaar:

1. Simulatietijd in seconden waarop de toewijzing door de planner wordt aangegeven

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. Adviesprijs

5. Lineair gemiddelde over alle RB's van de downlink-SINR in lineaire eenheden

De inhoud van het UE SINR-bestand is:

1. Simulatietijd in seconden waarop de toewijzing door de planner wordt aangegeven

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. uplink-SINR in lineaire eenheden voor de UE

In de interferentiebestandsnaam is de inhoud:

1. Simulatietijd in seconden waarop de toewijzing door de planner wordt aangegeven

2. Mobiele ID

3. Lijst met interferentiewaarden per RB

In UL- en DL-transmissiebestanden zijn de opgenomen parameters:

1. Simulatietijd in milliseconden

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. RNTI

5. Transmissielaag

6. MCS

7. grootte van de tuberculose

8. Redundantieversie

9. Nieuwe gegevensindicatorvlag

En ten slotte zijn de opgenomen parameters in UL- en DL-ontvangstbestanden:

1. Simulatietijd in milliseconden

2. Mobiele ID

3. unieke UE-ID (IMSI)

4. RNTI

5. Transmissiemodus

6. Transmissielaag

7. MCS

8. grootte van de tuberculose

9. Redundantieversie

10. Nieuwe gegevensindicatorvlag

11. Correctheid bij de ontvangst van de TB

Fading Opsporen Gebruik
In deze sectie beschrijven we hoe u fading-traces kunt gebruiken binnen LTE-simulaties.

Fading sporen Generatie
Het is mogelijk om vervagende sporen te genereren met behulp van een speciaal meegeleverde matlab-script
de code (/lte/model/fading-traces/fading-trace-generator.m). Dit script bevat al
de typische tapconfiguraties voor drie 3GPP-scenario's (dwz voetgangers, voertuigen en
stedelijk zoals gedefinieerd in bijlage B.2 van [TS36104]); gebruikers kunnen echter ook hun eigen
specifieke configuraties. De lijst met configureerbare parameters vindt u in de
volgende:

· fc : de gebruikte frequentie (deze beïnvloedt de berekening van de dopplersnelheid).

· v_km_h : de snelheid van de gebruikers

· traceDuur : de duur in seconden van de totale lengte van de trace.

· aantalRB's : het nummer van het resourceblok dat moet worden geëvalueerd.

· label : de tag die moet worden toegepast op het gegenereerde bestand.

Het gegenereerde bestand bevat reële waarden in ASCII-indeling, georganiseerd op matrixwijze:
elke rij komt overeen met een andere RB, en elke kolom komt overeen met een andere
temporeel vervagend spoormonster.

Opgemerkt moet worden dat de ns-3 LTE-module met elk vervagend traceerbestand kan werken
dat voldoet aan het hierboven beschreven ASCII-formaat. Daarom kunnen andere externe hulpmiddelen dat ook zijn
gebruikt om aangepaste vervagingssporen te genereren, zoals bijvoorbeeld andere simulators of
experimentele apparaten.

Fading sporen Gebruik
Wanneer u een vervagend spoor gebruikt, is het van het allergrootste belang dat u het spoor correct specificeert
parameters in de simulatie, zodat het fading-model het correct kan laden en gebruiken. De
te configureren parameters zijn:

· TraceBestandsnaam : de naam van de trace die moet worden geladen (absoluut pad of relatief pad
wrt het pad vanwaar het simulatieprogramma wordt uitgevoerd);

· TraceLengte : de traceduur in seconden;

· MonstersNum : het aantal monsters;

· Venstergrootte : de grootte van het vervagende bemonsteringsvenster in seconden;

Het is belangrijk om te benadrukken dat het bemonsteringsinterval van het vervagende spoor 1 ms moet zijn
of groter, en in het laatste geval moet het een geheel veelvoud van 1 ms zijn
correct verwerkt door de fadingmodule.

De standaardconfiguratie van het matlab-script biedt een trace van 10 seconden lang
10,000 samples (dwz 1 sample per TTI=1ms) en gebruikt met een venstergrootte van 0.5 seconde
amplitude. Dit zijn ook de standaardwaarden van de bovenstaande parameters die worden gebruikt in de
simulator; daarom kan hun instelling worden vermeden als het vervagende spoor ze respecteert.

Om de fading-module (die standaard niet actief is) te activeren, de volgende code
moeten in het simulatieprogramma worden opgenomen:

Ptr lteHelper = CreateObject ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

En voor het instellen van de parameters:

lteHelper->SetFadingModelAttribute ("TraceFilename", StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength", TimeValue (Seconden (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("WindowSize", TimeValue (Seconden (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum", UintegerValue (100));

Opgemerkt moet worden dat, TraceBestandsnaam heeft geen standaardwaarde, daarom moet dit wel
altijd expliciet worden ingesteld.

De simulator biedt standaard drie vervagingssporen die zijn gegenereerd volgens de
configuraties gedefinieerd in bijlage B.2 van [TS36104]. Deze sporen zijn beschikbaar in de
map src/lte/model/fading-traces/). Een uittreksel van deze sporen is weergegeven in de
volgende cijfers.
[afbeelding: vervagend spoor 3 km/u] [afbeelding] Fragment van het vervagend spoor opgenomen in de
simulator voor een voetgangersscenario (snelheid van 3 km/u)..UNINDENT
[afbeelding: vervagend spoor 60 km/u] [afbeelding] Fragment van het vervagend spoor opgenomen in de
simulator voor een voertuigscenario (snelheid van 60 km/u)..UNINDENT
[afbeelding: vervagend spoor 3 km/u] [afbeelding] Fragment van het vervagend spoor opgenomen in de
simulator voor een stedelijk scenario (snelheid van 3 km/u)..UNINDENT

Mobiliteit Model met Gebouwen
We leggen nu aan de hand van voorbeelden uit hoe u het gebouwenmodel kunt gebruiken (in het bijzonder de
MobiliteitGebouwInfo en BuildingPropagationModel klassen) in een ns-3-simulatie
programma om een ​​LTE-simulatiescenario op te zetten dat gebouwen en binnenknooppunten omvat.

1. Op te nemen headerbestanden:

#erbij betrekken
#erbij betrekken
#erbij betrekken

2. Pathloss-modelselectie:

Ptr lteHelper = CreateObject ();

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::BuildingsPropagationLossModel"));

3. EUTRA-bandselectie

De selectie van de werkfrequentie van het voortplantingsmodel moet worden gedaan met de
standaard ns-3 attribuutsysteem zoals beschreven in de overeenkomstige sectie ("Configuratie van
LTE-modelparameters") door middel van de DlEarfcn- en UlEarfcn-parameters, bijvoorbeeld:

lteHelper->SetEnbDeviceAttribute ("DlEarfcn", UintegerValue (100));
lteHelper->SetEnbDeviceAttribute ("UlEarfcn", UintegerValue (18100));

Opgemerkt moet worden dat het gebruik van andere middelen om de frequentie te configureren die door de
propagatiemodel (dat wil zeggen, het configureren van het overeenkomstige BuildingsPropagationLossModel
attributen rechtstreeks) kan conflicten veroorzaken in de frequentiedefinitie in de
modules tijdens de simulatie, en wordt daarom niet geadviseerd.

1. Selectie van mobiliteitsmodellen:

MobilityHelper mobiliteit;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");

Opgemerkt moet worden dat elk mobiliteitsmodel kan worden gebruikt.

2. Gebouwcreatie:

dubbel x_min = 0.0;
dubbel x_max = 10.0;
dubbel y_min = 0.0;
dubbel y_max = 20.0;
dubbele z_min = 0.0;
dubbele z_max = 10.0;
Ptr b = CreëerObject ();
b -> Grenzen instellen (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Gebouw::Residentieel);
b->SetExtWallsType (Gebouw::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRoomsX (3);
b->SetNRoomsY (2);

Hierdoor ontstaat een woongebouw met een basis van 10 x 20 meter en een hoogte van
10 meter waarvan de buitenmuren van beton zijn met ramen; het gebouw heeft er drie
verdiepingen en heeft een intern raster van 3 x 2 kamers van gelijke grootte.

3. Creatie en positionering van knooppunten:

ueNodes.Create (2);
mobiliteit.Installeren (ueNodes);
GebouwenHelper::Installeren (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0)->GetObject ();
Ptr mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (Vector (5.0, 5.0, 1.5));
mm1->SetPosition (Vector (30.0, 40.0, 1.5));

4. Voltooi de configuratie van het gebouw- en mobiliteitsmodel:

GebouwenHelper::MakeMobilityModelConsistent ();

Zie de documentatie van de gebouwen module voor meer gedetailleerde informatie.

PHY Fout Model
Het fysieke foutmodel bestaat uit het datafoutmodel en de downlinkbesturingsfout
model, beide standaard actief. Het is mogelijk om ze te deactiveren met de ns3
attribuutsysteem, in detail:

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

MIMO Model
In deze subsectie illustreren we hoe u de MIMO-parameters configureert. LTE definieert 7 typen
van transmissiemodi:

· Transmissiemodus 1: SISO.

· Transmissiemodus 2: MIMO Tx-diversiteit.

· Transmissiemodus 3: MIMO ruimtelijke multiplexiteit open lus.

· Transmissiemodus 4: MIMO ruimtelijke multiplexiteit gesloten lus.

· Transmissiemodus 5: MIMO meerdere gebruikers.

· Transmissiemodus 6: enkellaagse precodering met nauwere lus.

· Transmissiemodus 7: enkele antennepoort 5.

Afhankelijk van het geïmplementeerde model omvat de simulator de eerste drie transmissiemodi
soorten. De standaardinstelling is Transmissiemodus 1 (SISO). Om de standaard te wijzigen
Transmissiemodus die moet worden gebruikt, het attribuut Standaardtransmissiemodus van de LteEnbRrc blikje
worden gebruikt, zoals hieronder weergegeven:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // SISO
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // MIMO Tx-diversiteit (1 laag)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // MIMO ruimtelijke multiplexiteit (2 lagen)

Voor het wijzigen van de transmissiemodus van een bepaalde gebruiker tijdens de simulatie van een specifiek
interface is geïmplementeerd in beide standaardplanners:

ongeldige TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

Deze methode kan zowel worden gebruikt voor het ontwikkelen van een beslissingsmachine voor de transmissiemodus (dat wil zeggen, voor
het optimaliseren van de transmissiemodus volgens de kanaalconditie en/of die van de gebruiker
vereisten) en voor het handmatig overschakelen van een simulatiescript. In het laatste geval is de
U kunt schakelen zoals hieronder weergegeven:

Ptr lteEnbDev = enbDevs.Get (0)->GetObject ();
PointerValue ptrval;
enbNetDev->GetAttribute ("FfMacScheduler", ptrval);
Ptr rrsched = ptrval.Get ();
Simulator::Schedule (Seconden (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

Ten slotte kan het geïmplementeerde model opnieuw worden geconfigureerd volgens verschillende MIMO-modellen
het bijwerken van de versterkingswaarden (de enige beperking is dat de versterking constant moet zijn tijdens het afspelen).
simulatieruntime en gemeenschappelijk voor de lagen). De versterking van elke transmissiemodus kan zijn
gewijzigd volgens het standaard ns3-attributensysteem, waarbij de attributen zijn:
TxMode1Versterking, TxMode2Versterking, TxMode3Versterking, TxMode4Versterking, TxMode5Versterking, TxMode6Versterking en
TxMode7Versterking. Alleen standaard TxMode1Versterking, TxMode2Versterking en TxMode3Versterking een betekenisvolle hebben
waarde, dat zijn degene die zijn afgeleid door _[CatreuxMIMO] (dwz respectievelijk 0.0, 4.2 en -2.8
dB).

Te gebruiken of AntenneModel
We laten nu zien hoe u een bepaald AntenneModel koppelt aan een eNB-apparaat om a te modelleren
sector van een macro-eNB. Voor dit doel is het handig om de CosinusAntenneModel
geleverd door de ns-3 antennemodule. De configuratie van de eNB gebeurt via de
LteHelper bijvoorbeeld vlak vóór de oprichting van de EnbNet-apparaat, zoals weergegeven in de
volgende:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute ("Oriëntatie", DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("Beamwidth", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute ("MaxGain", DoubleValue (0.0));

de bovenstaande code genereert een antennemodel met een straalbreedte van 60 graden die in de richting wijst
de X-as. De oriëntatie wordt gemeten in graden vanaf de X-as, bijvoorbeeld een oriëntatie
van 90 zou langs de Y-as wijzen, en een oriëntatie van -90 zou negatief wijzen
richting langs de Y-as. De bundelbreedte is de -3 dB bundelbreedte, bijvoorbeeld voor een hoek van 60 graden
bundelbreedte die de antenne krijgt onder een hoek van m
30 graden vanuit de oriëntatierichting is -3 dB.

Om een ​​site met meerdere sectoren te creëren, moet u verschillende ns-3-knooppunten maken die op dezelfde plek zijn geplaatst
positie, en om afzonderlijk te configureren EnbNet-apparaat met verschillende antenne-oriëntaties
op elk knooppunt geïnstalleerd.

Radio Milieu Maps
Door gebruik te maken van de klas RadioMilieuMapHelper het is mogelijk om een ​​radio naar een bestand uit te voeren
Environment Map (REM), dwz een uniform 2D-raster van waarden die de
Signaal-ruisverhouding in de downlink ten opzichte van de eNB die het sterkst is
signaal op elk punt. Het is mogelijk om te specificeren of REM moet worden gegenereerd voor gegevens of
controle kanaal. Ook kan de gebruiker de RbId instellen waarvoor REM wordt gegenereerd. Standaard RbId
is -1, wat betekent dat REM wordt gegenereerd met een gemiddelde signaal-ruisverhouding van iedereen
RB's.

Om dit te doen, hoeft u alleen maar de volgende code aan uw simulatieprogramma toe te voegen richting de
end, vlak voor de aanroep van Simulator::Run ():

Ptr remHelper = CreëerObject ();
remHelper->SetAttribute ("ChannelPath", StringValue ("/ChannelList/0"));
remHelper->SetAttribute ("OutputFile", StringValue ("rem.out"));
remHelper->SetAttribute ("XMin", DoubleValue (-400.0));
remHelper->SetAttribute ("XMax", DoubleValue (400.0));
remHelper->SetAttribute ("XRes", UintegerValue (100));
remHelper->SetAttribute ("YMin", DoubleValue (-300.0));
remHelper->SetAttribute ("YMax", DoubleValue (300.0));
remHelper->SetAttribute ("YRes", UintegerValue (75));
remHelper->SetAttribute ("Z", DoubleValue (0.0));
remHelper->SetAttribute ("UseDataChannel", BooleanValue (true));
remHelper->SetAttribute ("RbId", IntegerValue (10));
remHelper->Installeren ();

Door de attributen van de RadioMilieuMapHelper object zoals hierboven weergegeven, u
kan de parameters van de te genereren REM afstemmen. Merk op dat elk
RadioMilieuMapHelper instance kan slechts één REM genereren; als je meer wilt genereren
REM's, moet u voor elke REM één afzonderlijk exemplaar maken.

Merk op dat de REM-generatie zeer veeleisend is, met name:

· het runtime-geheugenverbruik bedraagt ​​ongeveer 5 KB per pixel. Bijvoorbeeld een REM
met een resolutie van 500x500 zou ongeveer 1.25 GB geheugen nodig zijn, en een resolutie van
1000x1000 zou ongeveer 5 GB nodig hebben (te veel voor een gewone pc op het moment van dit artikel).
schrijven). Om dit probleem op te lossen, wordt de REM bij elke stap gegenereerd
stap waarbij maximaal een aantal pixels wordt geëvalueerd, bepaald door de waarde van de
attribuut RadioEnvironmentMapHelper::MaxPointsPerIteration.

· als u aan het begin van een simulatie een REM genereert, zal dit de snelheid vertragen
uitvoering van de rest van de simulatie. Als u een REM voor een programma wilt genereren
en ook hetzelfde programma gebruiken om een ​​simulatieresultaat te krijgen, wordt aanbevolen om een
opdrachtregelschakelaar waarmee u de REM kunt genereren of de volledige versie kunt uitvoeren
simulatie. Houd er hiervoor rekening mee dat er een attribuut is
RadioEnvironmentMapHelper::StopWhenDone (standaard: waar) waardoor de
simulatie stopt direct nadat de REM is gegenereerd.

De REM wordt opgeslagen in een ASCII-bestand in het volgende formaat:

· kolom 1 is de x-coördinaat

· kolom 2 is de y-coördinaat

· kolom 3 is de z-coördinaat

· kolom 4 is de SINR in lineaire eenheden

Hieronder vindt u een minimaal gnuplot-script waarmee u de REM kunt plotten:

kaart bekijken instellen;
xlabel "X" instellen
stel ylabel "Y" in
cblabel "SINR (dB)" instellen
uitgeschakelde sleutel
plot "rem.out" met ($1):($2):(10*log10($4)) met afbeelding

Als voorbeeld is hier de REM die kan worden verkregen met het voorbeeldprogramma
lena-dual-stripe, die een LTE-macrocel met drie sectoren toont in een co-channel-implementatie met
enkele residentiële femtocellen werden willekeurig ingezet in twee appartementenblokken.
[afbeelding] REM verkregen uit het voorbeeld van lena-dual-stripe.UNINDENT

Merk op dat het lena-dual-stripe voorbeeldprogramma ook gnuplot-compatibele uitvoer genereert
bestanden met informatie over de posities van de UE- en eNB-knooppunten en van
de gebouwen, respectievelijk in de bestanden ues.txt, enbs.txt en gebouwen.txt​ Deze kunnen
gemakkelijk worden opgenomen bij het gebruik van gnuplot. Ervan uitgaande dat uw gnuplot-script
(bijvoorbeeld het minimale gnuplot-script dat hierboven is beschreven) wordt opgeslagen in een bestand met de naam
mijn_plot_script, zou het uitvoeren van de volgende opdracht de locatie van UE's, eNB's en
gebouwen bovenop de REM:

gnuplot -p enbs.txt ues.txt gebouwen.txt mijn_plot_script

AMC Model en CQI Berekening
De simulator biedt twee mogelijke schema's voor wat betreft de selectie van de MCS's
en dienovereenkomstig het genereren van de CQI's. De eerste is gebaseerd op de GSoC-module
[Piro2011] en werkt op RB-basis. Dit model kan worden geactiveerd met het ns3 attribuut
systeem, zoals hieronder weergegeven:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

Terwijl de oplossing op basis van het fysieke foutenmodel kan worden beheerd met:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

Ten slotte is de vereiste efficiëntie van de PiroEW2010 AMC-module kan worden afgestemd dankzij de
Ber attribuut (), bijvoorbeeld:

Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));

Evolved Pakket Kern (EPC)
We leggen nu uit hoe je een simulatieprogramma schrijft waarmee je de EPC in kunt simuleren
aanvulling op het LTE-radiotoegangsnetwerk. Het gebruik van EPC maakt het mogelijk om IPv4-netwerken te gebruiken
met LTE-apparaten. Met andere woorden, u kunt de reguliere ns-3-applicaties gebruiken
en stopcontacten via IPv4 via LTE, en ook om een ​​LTE-netwerk met elk ander IPv4-netwerk te verbinden
netwerk dat u mogelijk in uw simulatie heeft.

Allereerst, naast LteHelper die we al hebben geïntroduceerd Basic simulatie
programma, moet u een extra gebruiken EpcHelper klasse, die voor het creëren zorgt
de EPC-entiteiten en netwerktopologie. Houd er rekening mee dat u deze niet kunt gebruiken EpcHelper direct, zoals het
is een abstracte basisklasse; in plaats daarvan moet u een van de onderliggende klassen gebruiken, namelijk
bieden verschillende EPC-topologie-implementaties. In dit voorbeeld zullen we overwegen
PointToPointEpcHelper, dat een EPC implementeert op basis van point-to-point-koppelingen. Om het te gebruiken,
u moet eerst deze code in uw simulatieprogramma invoegen:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreëerObject ();

Vervolgens moet u de LTE-helper vertellen dat de EPC zal worden gebruikt:

lteHelper->SetEpcHelper (epcHelper);

de bovenstaande stap is nodig zodat de LTE-helper de juiste EPC zal activeren
configuratie in overeenstemming met een aantal belangrijke configuraties, zoals bij een nieuwe eNB
of UE wordt aan de simulatie toegevoegd, of er wordt een EPS-drager gemaakt. De EPC-helper wel
zorg automatisch voor de noodzakelijke instellingen, zoals het maken van een S1-link en een S1-drager
opgericht. Dit alles gebeurt zonder tussenkomst van de gebruiker.

het roepen lteHelper->SetEpcHelper (epcHelper) maakt het gebruik van EPC mogelijk, en heeft de kant
effect dat er iets nieuws is LteEnbRrc dat is gemaakt, zal de EpsBearerToRlcMapping
attribuut ingesteld op RLC_UM_ALWAYS in plaats van RLC_SM_ALWAYS als dit laatste de standaard was;
anders wordt het attribuut niet gewijzigd (als u bijvoorbeeld de standaardwaarde hebt gewijzigd in
RLC_AM_ALWAYS, het zal niet worden aangeraakt).

Opgemerkt moet worden dat de EpcHelper zal ook automatisch het PGW-knooppunt aanmaken en
configureer het zo dat het verkeer van/naar het LTE-radiotoegangsnetwerk goed kan verwerken.
Toch moet u expliciete code toevoegen om de PGW met andere IPv4-netwerken te verbinden (bijv.
het internet). Hier is een heel eenvoudig voorbeeld van hoe u een enkele externe host kunt verbinden
de PGW via een point-to-point verbinding:

Ptr pgw = epcHelper->GetPgwNode ();

// Maak een enkele RemoteHost
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr remoteHost = remoteHostContainer.Get (0);
InternetStackHelper internet;
internet.Installeren (remoteHostContainer);

// Creëer het internet
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("Vertraging", Tijdwaarde (Seconden (0.010)));
NetDeviceContainer internetDevices = p2ph.Install (pgw, remoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase ("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetapparaten);
// interface 0 is localhost, 1 is het p2p-apparaat
Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);

Het is belangrijk om routes op te geven zodat de externe host LTE UE's kan bereiken. Eén manier van
Dit doen we door gebruik te maken van het feit dat de PointToPointEpcHelper wordt standaard toegewezen
voor LTE UE's een IP-adres in het 7.0.0.0-netwerk. Met dit in gedachten volstaat het om het volgende te doen:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

Nu moet u doorgaan met het maken van LTE eNB's en UE's, zoals uitgelegd in de vorige secties.
Uiteraard kun je ook andere LTE-aspecten configureren, zoals pathloss- en fading-modellen. Rechts
nadat u de UE's hebt gemaakt, moet u deze ook configureren voor IP-netwerken. Dit is gedaan
als volgt. We gaan ervan uit dat u een container voor UE- en eNodeB-knooppunten als deze heeft:

NodeContainer ueNodes;
NodeContainer enbNodes;

om een ​​LTE-only simulatie te configureren, zou je normaal gesproken zoiets als dit doen:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Bijvoegen (ueLteDevs, enbLteDevs.Get (0));

Om de UE's voor IP-netwerken te configureren, hoeft u alleen nog maar het volgende te doen
deze:

// we installeren de IP-stack op de UE's
InternetStackHelper internet;
internet.Installeren (ueNodes);

// wijs een IP-adres toe aan UE's
voor (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr ue = ueNodes.Get (u);
Ptr ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// stel de standaardgateway voor de UE in
Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}

De activering van dragers gebeurt op een enigszins andere manier dan wat er wordt gedaan
voor een LTE-only simulatie. Ten eerste mag de methode ActivateDataRadioBearer niet worden gebruikt
wanneer de EPC wordt gebruikt. Ten tweede, wanneer EPC wordt gebruikt, wordt de standaard EPS-drager geactiveerd
automatisch wanneer u LteHelper::Attach () aanroept. Ten derde, als u een dedicated
EPS-drager, kunt u dit doen met behulp van de methode LteHelper::ActivateDedicatedEpsBearer (). Dit
methode neemt als parameter de Traffic Flow Template (TFT), wat een structuur is die
identificeert het type verkeer dat wordt toegewezen aan de speciale EPS-drager. Hier is een
voorbeeld voor het instellen van een speciale drager voor een applicatie op de UE die communiceert
poort 1234:

Ptr tft = Maken ();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->Toevoegen (pf);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

U kunt uiteraard aangepaste EpsBearer- en EpcTft-configuraties gebruiken, raadpleeg hiervoor de
doxygen-documentatie voor hoe u dit moet doen.

Ten slotte kunt u applicaties installeren op de LTE UE-knooppunten die communiceren met externe
toepassingen via internet. Dit gebeurt volgens de gebruikelijke ns-3-procedures.
In navolging van ons eenvoudige voorbeeld met een enkele remoteHost, ziet u hoe u de downlink instelt
communicatie, met een UdpClient-toepassing op de externe host en een PacketSink op de
LTE UE (met dezelfde variabelenamen als de vorige codefragmenten)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), dlPort));
ApplicationContainer serverApps = packetSinkHelper.Install (ue);
serverApps.Start (Seconden (0.01));
UdpClientHelper-client (ueIpIface.GetAddress (0), dlPort);
ApplicationContainer clientApps = client.Install (remoteHost);
clientApps.Start (Seconden (0.01));

Dat is alles! U kunt nu uw simulatie zoals gewoonlijk starten:

Simulator::Stop (Seconden (10.0));
Simulator::Uitvoeren ();

gebruik the EPC met wedijver mode
In de vorige sectie hebben we PointToPoint-koppelingen gebruikt voor de verbinding tussen de eNB's en
de SGW (S1-U-interface) en onder eNB's (X2-U- en X2-C-interfaces). De LTE-module
ondersteunt het gebruik van geëmuleerde links in plaats van PointToPoint-links. Dit wordt bereikt door gewoon
ter vervanging van de creatie van LteHelper en EpcHelper met de volgende code:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreëerObject ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Initialiseren ();

De attributen ns3::EmuEpcHelper::sgwDeviceName en ns3::EmuEpcHelper::enbApparaatnaam zijn
wordt gebruikt om de naam in te stellen van de apparaten die worden gebruikt voor het transport van de S1-U, X2-U en X2-C
interfaces bij respectievelijk de SGW en de eNB. Hoe dit in zijn werk gaat, laten we nu zien in een
voorbeeld waarin we het voorbeeldprogramma uitvoeren lena-simple-epc-emu met behulp van twee virtuele
ethernet-interfaces.

Allereerst bouwen we ns-3 op de juiste manier:

# configureren
./waf configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# bouwen
./waff

Vervolgens stellen we twee virtuele ethernetinterfaces in en starten we Wireshark om naar het verkeer te kijken
doorgaan:

#opmerking: je moet root zijn

# maak twee gekoppelde veth-apparaten
ip-link naam toevoegen veth0 type veth peernaam veth1
ip linkshow

# promiscue modus inschakelen
ip-link ingesteld veth0 promisc aan
ip-link ingesteld veth1 promisc aan

# breng interfaces naar voren
ip-link veth0 ingesteld
ip-link veth1 ingesteld

# start wireshark en leg vast op veth0
draadhaai &

We kunnen nu het voorbeeldprogramma uitvoeren met de gesimuleerde klok:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

Als u Wireshark gebruikt, zou u eerst de ARP-resolutie moeten zien, waarna sommige GTP-pakketten beide uitwisselden
in uplink en downlink.

De standaardinstelling van het voorbeeldprogramma is 1 eNB en 1UE. U kunt dit wijzigen via
opdrachtregelparameters, bijvoorbeeld:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

Om een ​​lijst met de beschikbare parameters te krijgen:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

Om met de realtime klok te werken: het blijkt dat de standaard debug-build te traag is
echte tijd. Het is geen goed idee om de realtimebeperkingen te verzachten met de BestEffort-modus:
Er kan iets misgaan (bijvoorbeeld ARP kan falen) en als dat zo is, krijgt u geen datapakketten
uit. Je hebt dus fatsoenlijke hardware nodig en de geoptimaliseerde build met statisch gekoppelde
modulen:

./waf configure -d geoptimaliseerd --enable-static --enable-modules=lte --enable-examples --enable-sudo

Voer vervolgens het voorbeeldprogramma als volgt uit:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

let op de HardLimit-instelling, die ervoor zorgt dat het programma wordt beëindigd als het het niet kan bijhouden
met realtime.

De aanpak die in deze sectie wordt beschreven, kan met elk type netwerkapparaat worden gebruikt. Voor
[Baldo2014] beschrijft bijvoorbeeld hoe het werd gebruikt om een ​​geëmuleerd LTE-EPC-netwerk over een
een echt meerlaags pakket-optisch transportnetwerk.

Netwerk Gehechtheid
Zoals weergegeven in het basisvoorbeeld in sectie Basic simulatie programma, waarbij een UE aan een
eNodeB wordt gedaan door te bellen LteHelper::Bijvoegen functie.

Er zijn 2 mogelijke manieren om verbinding te maken met een netwerk. De eerste methode is de "handmatig" een,
terwijl de tweede er meer heeft "automatisch" zin er in. Elk van hen zal worden behandeld
deze sectie.

Handleiding gehechtheid
Deze methode gebruikt de LteHelper::Bijvoegen bovengenoemde functie. Het is de enige geweest
beschikbare netwerkverbindingsmethode in eerdere versies van de LTE-module. Typisch zo
aangeroepen voordat de simulatie begint:

lteHelper->Bijvoegen (ueDevs, enbDev); // koppel een of meer UE's aan een enkele eNodeB

LteHelper::InstallEnbDevice en LteHelper::InstallUeDevice functies moeten zijn aangeroepen
voordat u het bevestigt. Bij een EPC-compatibele simulatie is het ook vereist om over IPv4 te beschikken
vooraf geïnstalleerd in de UE.

Deze methode is heel eenvoudig, maar vereist dat u precies weet welke UE bij welke hoort
eNodeB voordat de simulatie begint. Dit kan moeilijk zijn als de beginpositie van de UE dat is
willekeurig bepaald door het simulatiescript.

Men kan de afstand tussen de UE en de eNodeB kiezen als criterium voor het selecteren van de
geschikte cel. Het is vrij eenvoudig (althans vanuit het oogpunt van de simulator) en
soms praktisch. Maar het is belangrijk op te merken dat afstand soms geen verschil maakt
één juist criterium. De richtingsgevoeligheid van de eNodeB-antenne zou bijvoorbeeld moeten zijn
eveneens overwogen. Daarnaast moet men ook rekening houden met de kanaalconditie,
die kunnen fluctueren als er sprake is van vervaging of schaduwvorming. Bij dit soort
In sommige gevallen mag netwerkverbinding niet alleen op afstand worden gebaseerd.

In het echte leven zal UE automatisch bepaalde criteria evalueren en de beste cel selecteren
bevestigen, zonder handmatige tussenkomst van de gebruiker. Uiteraard is dit niet het geval bij
dit LteHelper::Bijvoegen functie. De andere netwerkverbindingsmethode gebruikt meer "automatisch"
benadering van netwerkkoppeling, zoals hierna zal worden beschreven.

Automatisch gehechtheid gebruik Idle mode cel selectie procedures
De sterkte van het ontvangen signaal is het standaardcriterium dat wordt gebruikt om het beste te selecteren
cel om aan te hechten. Het gebruik van dit criterium is geïmplementeerd in de eerste cel selectie
proces, dat kan worden aangeroepen door een andere versie van het LteHelper::Bijvoegen
functie, zoals hieronder weergegeven:

lteHelper->Bijvoegen (ueDevs); // bevestig een of meer UE's aan een sterkste cel

Het verschil met de handmatige methode is dat de bestemming-eNodeB niet is gespecificeerd. De
procedure zal de beste cel voor de EU's vinden, gebaseerd op verschillende criteria, waaronder de
sterkte van het ontvangen signaal (RSRP).

Nadat de methode is aangeroepen, zal de UE enige tijd besteden aan het meten van de aangrenzende cellen,
en probeer je dan aan de beste te hechten. Meer details vindt u in sectie
sec-initiële-celselectie van de ontwerpdocumentatie.

Het is belangrijk op te merken dat deze methode alleen werkt in EPC-compatibele simulaties. Alleen LTE
simulaties moeten hun toevlucht nemen tot de handmatige bevestigingsmethode.

Gesloten Abonnee Groep
Een interessant gebruiksvoorbeeld van het initiële celselectieproces is het opzetten van een simulatie
omgeving met Closed Subscriber Group (CSG).

Een bepaalde eNodeB, meestal een kleinere versie zoals femtocell, zou er bijvoorbeeld bij kunnen horen
aan een particuliere eigenaar (bijvoorbeeld een huishouden of bedrijf), waardoor alleen toegang wordt verleend tot bepaalde EU's
zijn eerder geregistreerd door de eigenaar. De eNodeB en de geregistreerde UE's samen
een CSG vormen.

De toegangsbeperking kan worden gesimuleerd door de CSG-leden te "labelen" met dezelfde CSG
ID KAART. Dit gebeurt via de attributen in zowel eNodeB als UE, bijvoorbeeld met behulp van de
volgend LteHelper functies:

// label de volgende eNodeB's met CSG-identiteit 1 en CSG-indicatie ingeschakeld
lteHelper->SetEnbDeviceAttribute ("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication", BooleanValue (true));

// label een of meer UE's met CSG-identiteit 1
lteHelper->SetUeDeviceAttribute ("CsgId", UintegerValue (1));

// installeer de eNodeB's en UE's
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

Schakel vervolgens de initiële celselectieprocedure in op de UE's:

lteHelper->Bijvoegen (csgUeDevs);

Dit is nodig omdat de CSG-beperking alleen werkt bij automatische netwerkmethode
bijlage, maar niet in de handmatige methode.

Houd er rekening mee dat het instellen van de CSG-indicatie van een eNodeB als false (de standaardwaarde) dit wel zal doen
schakel de beperking uit, dat wil zeggen dat alle UE's verbinding kunnen maken met deze eNodeB.

Configure UE maten
De actieve UE-meetconfiguratie in een simulatie wordt bepaald door de geselecteerde UE-meetconfiguratie
‘consumenten’ genoemd, zoals het overdrachtsalgoritme. Gebruikers kunnen hun eigen configuratie toevoegen
actie, en er zijn verschillende manieren om dit te doen:

1. directe configuratie in eNodeB RRC-entiteit;

2. configureren van bestaand overdrachtsalgoritme; En

3. het ontwikkelen van een nieuw overdrachtsalgoritme.

In dit gedeelte wordt alleen de eerste methode behandeld. De tweede methode wordt behandeld in Automatisch
overhandigen leiden, terwijl de derde methode in paragraaf uitgebreid wordt uitgelegd
sec-handover-algoritme van de ontwerpdocumentatie.

Directe configuratie in eNodeB RRC werkt als volgt. De gebruiker begint met het maken van een nieuw
LteRrcSap::ReportConfigEutra exemplaar en geef het door aan de LteEnbRrc::AddUeMeasReportConfig
functie. De functie retourneert de meetId (meetidentiteit) die uniek is
referentie van de configuratie in het eNodeB-exemplaar. Deze functie moet eerder worden aangeroepen
de simulatie begint. De meetconfiguratie zal actief zijn in alle aangesloten UE's
de eNodeB gedurende de gehele duur van de simulatie. Tijdens de simulatie kan de gebruiker
de door de EU's geproduceerde meetrapporten vastleggen door naar het bestaande te luisteren
LteEnbRrc::RecvMeasurementReport spoor bron.

De structuur ReportConfigEutra is in overeenstemming met de 3GPP-specificatie. Definitie van de
structuur en elk lidveld kunt u vinden in Sectie 6.3.5 van [TS36331].

Het onderstaande codevoorbeeld configureert de RSRP-meting van gebeurtenis A1 voor elke eNodeB binnen de
houder devs:

LteRrcSap::ReportConfigEutra-configuratie;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
config.threshold1.bereik = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

std::vector measIdList;

NetDeviceContainer::Iterator it;
for (it = devs.Begin (); it != devs.End (); it++)
{
Ptr dev = *het;
Ptr enbDev = dev->GetObject ();
Ptr enbRrc = enbDev->GetRrc ();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back (measId); // onthoud de gemaakte measId

enbRrc->TraceConnect ("RecvMeasurementReport",
"context",
MakeCallback (&RecvMeasurementReportCallback));
}

Houd er rekening mee dat drempels worden uitgedrukt als bereik. In het bovenstaande voorbeeld is het bereik 41 voor RSRP
komt overeen met -100 dBm. De conversie van en naar het bereikformaat komt door Section
9.1.4 en 9.1.7 van [TS36133]. De EutranMeasurementMapping klasse heeft verschillende statische
functies die hiervoor kunnen worden gebruikt.

De overeenkomstige callback-functie zou een soortgelijke definitie hebben als hieronder:

komen te vervallen
RecvMeasurementReportCallback (std::stringcontext,
uint64_t imsi,
uint16_t celId,
uint16_t rnti,
LteRrcSap::MeasurementReport measReport);

Deze methode registreert de callback-functie als consument van UE-metingen. In de
geval waarin er meer dan één consument in de simulatie aanwezig is (bijv. overdrachtsalgoritme),
bij deze terugbelactie worden ook de metingen bestemd voor andere consumenten vastgelegd
functie. Gebruikers kunnen gebruik maken van de meetId veld, opgenomen in de
LteRrcSap::Meetrapport argument van de callback-functie, om te vertellen welke meting
configuratie heeft het rapport geactiveerd.

Over het algemeen voorkomt dit mechanisme dat de ene consument onbewust ingrijpt bij de andere
rapportageconfiguratie van de consument.

Houd er rekening mee dat alleen het rapportageconfiguratiegedeelte (bijv LteRrcSap::ReportConfigEutra) van
de parameter UE-metingen staat open voor consumenten om te configureren, terwijl de andere delen
worden verborgen gehouden. De intrafrequentiebeperking is de belangrijkste motivatie achter deze API
uitvoeringsbesluit:

· er is er maar één, ondubbelzinnig en definitief maat object, dus er is geen
moet het configureren;

· maat identiteiten worden verborgen gehouden vanwege het feit dat er één-op-één is
mapping tussen rapportageconfiguratie en meetidentiteit, dus een nieuwe
meetidentiteit wordt automatisch ingesteld wanneer er een nieuwe rapportageconfiguratie is
gemaakt;

· hoeveelheid configuratie is elders geconfigureerd, zie sec-performing-metingen; En

· maat hiaten worden niet ondersteund, omdat dit alleen van toepassing is op interfrequenties
instellingen;

X2-gebaseerd overhandigen
Zoals gedefinieerd door 3GPP, is overdracht een procedure voor het wijzigen van de bedienende cel van een UE in
VERBONDEN modus. De twee eNodeB's die bij het proces betrokken zijn, worden doorgaans de (bron)
eNodeB en doel eNodeB.

Om de uitvoering van op X2 gebaseerde handover in simulatie mogelijk te maken, zijn er twee
eisen waaraan moet worden voldaan. Ten eerste moet EPC ingeschakeld zijn in de simulatie (zie Evolved
Pakket Kern (EPC)).

Ten tweede moet er een X2-interface worden geconfigureerd tussen de twee eNodeB's, wat zo moet zijn
expliciet gedaan binnen het simulatieprogramma:

lteHelper->AddX2Interface (enbNodes);

WAAR enbNodes is een KnooppuntContainer die de twee eNodeB's bevat waartussen de X2
interface moet worden geconfigureerd. Als de container meer dan twee eNodeB's heeft, wordt de functie
zal een X2-interface creëren tussen elk paar eNodeB's in de container.

Ten slotte moet het doel-eNodeB worden geconfigureerd als "open" voor X2 HANDOVER REQUEST. Elk
eNodeB is standaard geopend, dus in de meeste gevallen is er geen extra instructie nodig. Echter, gebruikers
kan de eNodeB op "gesloten" zetten door het booleaanse attribuut in te stellen
LteEnbRrc::AdmitHandoverRequest naar vals. U kunt bijvoorbeeld de lena-x2-overhandiging
programma en stel het attribuut op deze manier in:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

Nadat aan de bovenstaande drie vereisten is voldaan, kan de overdrachtsprocedure worden geactiveerd
handmatig of automatisch. Ze zullen allemaal in de volgende subsecties worden gepresenteerd.

Handleiding overhandigen leiden
De overdrachtsgebeurtenis kan "handmatig" worden geactiveerd binnen het simulatieprogramma door een
expliciete overdrachtsgebeurtenis. De LteHelper object biedt een handige methode voor het
het plannen van een overdrachtsevenement. Laten we dat als voorbeeld aannemen ueLteDevs is een
NetDeviceContainer waarin de UE staat die moet worden overgedragen, en dat enbLteDevs is
ander NetDeviceContainer die de bron- en de doel-eNB bevat. Dan een overdracht
op 0.1s kan als volgt worden gepland:

lteHelper->HandoverRequest (seconden (0.100),
ueLteDevs.Get (0),
enbLteDevs.Get (0),
enbLteDevs.Get (1));

Merk op dat de UE al verbonden moet zijn met de bron-eNB, anders zal de simulatie plaatsvinden
wordt afgesloten met een foutmelding.

Voor een voorbeeld met volledige broncode verwijzen wij u naar de lena-x2-overhandiging voorbeeld
programma.

Automatisch overhandigen leiden
De overdrachtsprocedure kan ook "automatisch" worden geactiveerd door het bedienende eNodeB van de UE.
De logica achter de trigger hangt af van het overdrachtsalgoritme dat momenteel actief is in de
eNodeB RRC-entiteit. Gebruikers kunnen het gebruikte overdrachtsalgoritme selecteren en configureren
in de simulatie, die kort in deze sectie zal worden uitgelegd. Gebruikers kunnen er ook voor kiezen
schrijven hun eigen implementatie van het overdrachtsalgoritme, zoals beschreven in sectie
sec-handover-algoritme van de ontwerpdocumentatie.

Het selecteren van een overdrachtsalgoritme gebeurt via de LteHelper voorwerp en zijn
SetHandoverAlgorithmType methode zoals hieronder weergegeven:

Ptr lteHelper = CreateObject ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

Het geselecteerde overdrachtsalgoritme kan ook verschillende configureerbare attributen verschaffen
kan als volgt worden ingesteld:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold",
UintegerWaarde (30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset",
UintegerWaarde (1));

Er zijn drie opties voor het overdrachtsalgoritme opgenomen in de LTE-module. De A2-A4-RSRQ
overdrachtsalgoritme (genaamd als ns3::A2A4RsrqHandoveralgoritme) is de standaardoptie, en
het gebruik is hierboven al weergegeven.

Een andere optie is de sterkste cel overdrachtsalgoritme (genaamd als
ns3::A3RsrpHandoveralgoritme), die kan worden geselecteerd en geconfigureerd met de volgende code:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("Hysteresis",
Dubbele Waarde (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger",
Tijdwaarde (milliseconden (256)));

De laatste optie is een speciale, genaamd de nee-op overdrachtsalgoritme, dat in feite
schakelt de automatische overdrachttrigger uit. Dit is bijvoorbeeld handig in gevallen waarin handmatig
overdrachtstriggers hebben een exclusieve controle nodig over alle overdrachtsbeslissingen. Het heeft er geen
configureerbare attributen. Het gebruik is als volgt:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

Voor meer informatie over het beslissingsbeleid van elk overdrachtsalgoritme en hun attributen,
Raadpleeg de respectieve subsecties in Sectie sec-handover-algoritme van de
Ontwerpdocumentatie.

Ten slotte InstalleerEnbDevice functie van LteHelper zal één exemplaar van de instantiëren
geselecteerd overdrachtsalgoritme voor elk eNodeB-apparaat. Met andere woorden: zorg ervoor dat u selecteert
het juiste handover-algoritme voordat het wordt afgerond in de volgende coderegel:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

Een voorbeeld met de volledige broncode van het gebruik van automatische overdrachttrigger kunt u vinden in de
lena-x2-overdrachtsmaatregelen voorbeeld programma.

Stemming simulatie met overhandigen
Zoals vermeld in de ontwerpdocumentatie kan de huidige implementatie van het overdrachtsmodel dit wel doen
Onvoorspelbaar gedrag veroorzaken wanneer de overdracht mislukt. In deze subparagraaf zal de nadruk liggen
de stappen waarmee gebruikers rekening moeten houden als ze van plan zijn handover te gebruiken in hun
simulaties.

De belangrijkste oorzaak van het mislukken van de overdracht die we zullen aanpakken, is de fout bij het verzenden
met overdracht verband houdende signaleringsberichten tijdens de uitvoering van een overdrachtsprocedure. Als
blijkt uit het figuur fig-x2-gebaseerde-handover-seq-diagram uit de ontwerpdocumentatie,
er zijn er veel en ze gebruiken verschillende interfaces en protocollen. In het belang van
eenvoud kunnen we veilig aannemen dat de X2-interface (tussen de bron-eNodeB en de
doel-eNodeB) en de S1-interface (tussen de doel-eNodeB en de SGW/PGW) zijn behoorlijk
stal. Daarom zullen we onze aandacht richten op het RRC-protocol (tussen de UE en de
eNodeBs) en de Random Access-procedure, die normaal gesproken via de lucht worden verzonden
en gevoelig voor verslechtering van de kanaalconditie.

Een algemene tip om transmissiefouten te verminderen is om verzekeren hoog genoeg ZIN niveau in elke
UE. Dit kan worden gedaan door een goede planning van de netwerktopologie minimaliseert netwerk
dekking gat. Als de topologie een bekend dekkingsgat heeft, moet de UE worden geconfigureerd
om niet naar dat gebied te gaan.

Een andere aanpak om in gedachten te houden is om vermijd te laat overdrachten. Met andere woorden, overdracht
moet gebeuren voordat de SINR van de UE te laag wordt, anders kan de UE mogelijk niet ontvangen
het overdrachtscommando van de bron-eNodeB. Overdrachtsalgoritmen hebben de middelen om te controleren
hoe vroeg of laat een overdrachtsbeslissing wordt genomen. Bijvoorbeeld het A2-A4-RSRQ-overdrachtsalgoritme
kan worden geconfigureerd met een hogere drempel, zodat er eerder tot een overdracht kan worden besloten. Op dezelfde manier,
kleinere hysteresis en/of kortere triggertijd in het sterkste celoverdrachtsalgoritme
resulteert doorgaans in een eerdere overdracht. Om hiervoor de juiste waarden te vinden
parameters, is een van de factoren waarmee rekening moet worden gehouden de bewegingssnelheid van de UE.
Over het algemeen vereist een sneller bewegende UE dat de overdracht eerder wordt uitgevoerd. Wat onderzoek
werk heeft aanbevolen waarden voorgesteld, zoals in [Lee2010].

De bovenstaande tips zouden voldoende moeten zijn bij normaal simulatiegebruik, maar in dit geval iets speciaals
Als er behoeften ontstaan, kan een extreme maatregel in overweging worden genomen. Gebruikers bijvoorbeeld
kan overwegen uitschakelen the kanaal fout modellen. Dit zal ervoor zorgen dat alles
overdrachtsgerelateerde signaleringsberichten zullen succesvol worden verzonden, ongeacht
afstand en kanaalconditie. Het heeft echter ook invloed op alle andere gegevens of controles
pakketten die geen verband houden met overdracht, wat een ongewenst neveneffect kan zijn. Anders kan het
als volgt gebeuren:

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

Door de bovenstaande code te gebruiken, schakelen we het foutmodel uit in zowel de besturings- als de datakanalen
in beide richtingen (downlink en uplink). Dit is nodig omdat dit verband houdt met de overdracht
Via deze kanalen worden signaleringsberichten verzonden. Een uitzondering is wanneer de
simulatie maakt gebruik van het ideale RRC-protocol. In dit geval is alleen de Random Access-procedure van toepassing
overgelaten om te worden overwogen. De procedure bestaat uit controleberichten, daarom hebben we alleen maar nodig
om het foutmodel van het besturingskanaal uit te schakelen.

Overhandigen voetstappen
Het RRC-model, in het bijzonder het LteEnbRrc en LteUeRrc objecten, bieden wat nuttigs
sporen die kunnen worden gekoppeld aan een aantal aangepaste functies, zodat ze bij het starten worden aangeroepen
en het einde van de uitvoeringsfase van de overdracht aan zowel de UE- als de eNB-zijde. Als voorbeeld, binnen
uw simulatieprogramma kunt u de volgende methoden declareren:

komen te vervallen
NotifyHandoverStartUe (std::stringcontext,
uint64_t imsi,
uint16_t celId,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Nu ().GetSeconds () << " " << context
<< " UE IMSI " << imsi
<< ": eerder verbonden met CellId " << cellId
<< " met RNTI " << rnti
<< ", wordt overgedragen aan CellId " << targetCellId
<< std::endl;
}

komen te vervallen
NotifyHandoverEndOkUe (std::stringcontext,
uint64_t imsi,
uint16_t celId,
uint16_t rnti)
{
std::cout << Simulator::Nu ().GetSeconds () << " " << context
<< " UE IMSI " << imsi
<< ": succesvolle overdracht naar CellId " << cellId
<< " met RNTI " << rnti
<< std::endl;
}

komen te vervallen
NotifyHandoverStartEnb (std::stringcontext,
uint64_t imsi,
uint16_t celId,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Nu ().GetSeconds () << " " << context
<< " eNB CellId " << celId
<< ": start de overdracht van UE met IMSI " << imsi
<< "RNTI" <<rnti
<< " naar CellId " << doelCellId
<< std::endl;
}

komen te vervallen
NotifyHandoverEndOkEnb (std::stringcontext,
uint64_t imsi,
uint16_t celId,
uint16_t rnti)
{
std::cout << Simulator::Nu ().GetSeconds () << " " << context
<< " eNB CellId " << celId
<< ": voltooide overdracht van UE met IMSI " << imsi
<< "RNTI" <<rnti
<< std::endl;
}

Vervolgens kunt u deze methoden als volgt aan de overeenkomstige traceringsbronnen koppelen:

Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartUe));
Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

Het voorbeeldprogramma src/lte/examples/lena-x2-handover.cc illustreert hoe het bovenstaande allemaal werkt
instructies kunnen worden geïntegreerd in een simulatieprogramma. U kunt het programma als volgt uitvoeren:

./waf --voer lena-x2-handover uit

en het zal de berichten uitvoeren die zijn afgedrukt door de aangepaste handover-trace hooks. In volgorde
visualiseer bovendien wat zinvolle loginformatie, u kunt het programma als volgt uitvoeren
deze:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --voer lena-x2-handover uit

Frequentie visfuik Algoritmen
In deze sectie beschrijven we hoe u algoritmen voor frequentiehergebruik in eNb binnen LTE kunt gebruiken
simulaties. Er zijn twee mogelijke manieren van configuratie. De eerste benadering is de
"handmatige", er moeten meer parameters worden geconfigureerd, maar de gebruiker kan FR configureren
algoritme zoals hij/zij nodig heeft. De tweede benadering is meer "automatisch". Het is erg handig,
omdat dit voor elk FR-algoritme hetzelfde is, zodat de gebruiker zeer snel van FR-algoritme kan wisselen
alleen het type FR-algoritme wijzigen. Een nadeel is dat er alleen gebruik wordt gemaakt van een "automatische" aanpak
beperkte set configuraties voor elk algoritme, wat het minder flexibel maakt, maar dat is het wel
voor de meeste gevallen voldoende.

Deze twee benaderingen zullen in de volgende subparagraaf nader worden beschreven.

Als de gebruiker het Frequency Reuse-algoritme niet configureert, is dit standaard één (dat wil zeggen LteFrNoOpAlgorithm)
is geïnstalleerd in eNb. Het werkt alsof het FR-algoritme is uitgeschakeld.

Eén ding dat moet worden vermeld, is dat de meeste geïmplementeerde FR-algoritmen ermee werken
celbandbreedte groter of gelijk aan 15 RBs. Deze beperking wordt veroorzaakt door de eis dat
er moeten ten minste drie continue RB's aan UE worden toegewezen voor verzending.

Handleiding configuratie
Het frequentiehergebruikalgoritme kan "handmatig" worden geconfigureerd binnen het simulatieprogramma door
instellingstype van het FR-algoritme en al zijn attributen. Momenteel zijn er zeven FR-algoritmen
geïmplementeerd:

· ns3::LteFrNoOpAlgoritme

· ns3::LteFrHardAlgoritme

· ns3::LteFrStrictAlgoritme

· ns3::LteFrSoftAlgoritme

· ns3::LteFfrSoftAlgoritme

· ns3::LteFfrVerbeterd algoritme

· ns3::LteFfrDistributedAlgoritme

Het selecteren van een FR-algoritme gebeurt via de LteHelper voorwerp en zijn SetFfrAlgoritmeType
methode zoals hieronder weergegeven:

Ptr lteHelper = CreateObject ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

Elk geïmplementeerd FR-algoritme biedt verschillende configureerbare attributen. Gebruikers hebben dat niet
om zich zorgen te maken over de configuratie van de UL- en DL-bandbreedte, omdat dit automatisch gebeurt tijdens
celconfiguratie. Om de bandbreedte voor het FR-algoritme te wijzigen, configureert u de vereiste waarden voor
LteEnbNet-apparaat:

uint8_t bandbreedte = 100;
lteHelper->SetEnbDeviceAttribute ("DlBandwidth", UintegerValue (bandbreedte));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth", UintegerValue (bandbreedte));

Nu zal elke FR-algoritmeconfiguratie worden beschreven.

Hard Frequentie visfuik Algoritme
Zoals beschreven in sectie sec-fr-hard-algoritme van de ontwerpdocumentatie
ns3::LteFrHardAlgoritme gebruikt één subband. Om deze subband te configureren, moet de gebruiker dit specificeren
offset en bandbreedte voor DL ​​en UL in aantal RB's.

Het algoritme voor hergebruik van harde frequenties biedt de volgende kenmerken:

· DlSubBandOffset: Downlink-compensatie in aantal resourceblokgroepen

· DlSub-bandbreedte: Downlink transmissie-subbandbreedteconfiguratie in aantal
Resourceblokgroepen

· UlSubBandOffset: Uplink-compensatie in aantal resourceblokgroepen

· UlSub-bandbreedte: Uplink transmissie-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

Voorbeeldconfiguratie van LteFrHardAlgorithm kan op de volgende manier worden gedaan:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlSubBandwidth", UintegerValue (8));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

In het bovenstaande voorbeeld kan eNB alleen RB's van 8 tot 16 in DL en UL gebruiken, terwijl hele cellen
bandbreedte bedraagt ​​25.

Streng Frequentie visfuik Algoritme
Het Strict Frequency Reuse Algorithm maakt gebruik van twee subbanden: één gemeenschappelijk voor elke cel en één
privaat. Er is ook een RSRQ-drempel, die nodig is om te beslissen binnen welke subband UE
moet worden geserveerd. Bovendien kan de vermogensoverdracht in deze subbanden verschillend zijn.

Het strikte frequentiehergebruikalgoritme biedt de volgende kenmerken:

· UlCommonSub-bandbreedte: Uplink gemeenschappelijke subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· UlEdgeSubBandOffset: Uplink Edge SubBand Offset in aantal resourceblokgroepen

· UlEdgeSub-bandbreedte: Uplink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· DlGemeenschappelijke subbandbreedte: Downlink gemeenschappelijke subbandbreedteconfiguratie in aantal
Resourceblokgroepen

· DlEdgeSubBandOffset: Downlink Edge SubBand Offset in aantal resourceblokgroepen

· DlEdgeSub-bandbreedte: Downlink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· Rsrqdrempel: Als de RSRQ van slechter is dan deze drempel, moet UE worden geserveerd
rand subband

· CenterPowerOffset: PdschConfigDedicated::Pa-waarde voor middelste subband, standaardwaarde
dB0

· EdgePowerOffset: PdschConfigDedicated::Pa-waarde voor edge-subband, standaardwaarde dB0

· CenterAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het middengebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· EdgeAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het randgebied, Absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

Met het onderstaande voorbeeld kan eNB RB's van 0 tot 6 gebruiken als gewone subband en van 12 tot 18 als
privé-subband in DL en UL, RSRQ-drempel is 20 dB, vermogen in middengebied gelijk
LteEnbPhy::TxPower - 3dB, het vermogen in het randgebied is gelijk LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrStrictAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaTpc", UintegerValue (1));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaTpc", UintegerValue (2));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Soft /Pastel Frequentie visfuik Algoritme
Met het Soft Frequency Reuse Algorithm gebruikt eNb de volledige celbandbreedte, maar er zijn er twee
subbanden, binnen UE's worden bediend met verschillende vermogensniveaus.

Het zachte frequentiehergebruikalgoritme biedt de volgende kenmerken:

· UlEdgeSubBandOffset: Uplink Edge SubBand Offset in aantal resourceblokgroepen

· UlEdgeSub-bandbreedte: Uplink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· DlEdgeSubBandOffset: Downlink Edge SubBand Offset in aantal resourceblokgroepen

· DlEdgeSub-bandbreedte: Downlink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· AllowCenterUeUseEdgeSubBand: Als echte centrum-UE's kunnen ontvangen op rand-subband-RBG's,
anders is de randsubband alleen toegestaan ​​voor rand-UE's, de standaardwaarde is waar

· Rsrqdrempel: Als de RSRQ van slechter is dan deze drempel, moet UE worden geserveerd
rand subband

· CenterPowerOffset: PdschConfigDedicated::Pa-waarde voor middelste subband, standaardwaarde
dB0

· EdgePowerOffset: PdschConfigDedicated::Pa-waarde voor edge-subband, standaardwaarde dB0

· CenterAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het middengebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· EdgeAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het randgebied, Absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

Het onderstaande voorbeeld configureert RB's van 8 tot 16 voor gebruik door celrand-UE's en deze subband is
niet beschikbaar voor gebruikers van celcentra. De RSRQ-drempel is 20 dB, het vermogen in het middengebied is gelijk
LteEnbPhy::TxPower, het vermogen in het randgebied is gelijk LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (8));
lteHelper->SetFfrAlgorithmAttribute ("AllowCenterUeUseEdgeSubBand", BooleanValue (false));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Soft /Pastel Fractioneel Frequentie visfuik Algoritme
Soft Fractional Frequency Reuse (SFFR) gebruikt drie subbanden: midden, medium (gemeenschappelijk) en
rand. De gebruiker hoeft er slechts twee te configureren: common en edge. Centrale subband zal dat zijn
samengesteld uit de resterende bandbreedte. Elke subband kan met verschillende worden bediend
zendvermogen. Omdat er drie subbanden zijn, moeten er twee RSRQ-drempels zijn
geconfigureerd.

Het zachte fractionele frequentiehergebruikalgoritme biedt de volgende kenmerken:

· UlCommonSub-bandbreedte: Uplink gemeenschappelijke subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· UlEdgeSubBandOffset: Uplink Edge SubBand Offset in aantal resourceblokgroepen

· UlEdgeSub-bandbreedte: Uplink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· DlGemeenschappelijke subbandbreedte: Downlink gemeenschappelijke subbandbreedteconfiguratie in aantal
Resourceblokgroepen

· DlEdgeSubBandOffset: Downlink Edge SubBand Offset in aantal resourceblokgroepen

· DlEdgeSub-bandbreedte: Downlink Edge-subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· CentrumRsrqThreshold: Als de RSRQ van slechter is dan deze drempelwaarde, moet UE worden geserveerd
in middelgrote subband

· EdgeRsrqdrempel: Als de RSRQ van slechter is dan deze drempelwaarde, moet UE worden geserveerd
in de randsubband

· CenterAreaPowerOffset: PdschConfigDedicated::Pa-waarde voor middelste subband, standaard
waarde dB0

· MediumAreaPowerOffset: PdschConfigDedicated::Pa-waarde voor medium subband, standaard
waarde dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::Pa-waarde voor randsubband, standaardwaarde
dB0

· CenterAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het middengebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· MediumAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in middelgroot gebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· EdgeAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het randgebied, Absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

In het onderstaande voorbeeld worden RB's van 0 tot 6 gebruikt als gewone (medium) subband, RB's van 6 tot
12 zal worden gebruikt als randsubband en RB's van 12 tot 24 zullen worden gebruikt als centrale subband (het
is samengesteld uit de overige RB’s). RSRQ-drempel tussen midden- en middengebied is 28 dB,
RSRQ-drempel tussen midden- en randgebied is 18 dB. Het vermogen in het middengebied is gelijk
LteEnbPhy::TxPower - 3dB, vermogen op middelgroot gebied is gelijk LteEnbPhy::TxPower + 3dB, macht in
randgebied gelijk LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType ("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute ("UlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlCommonSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("DlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute ("UlEdgeSubBandwidth", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterRsrqThreshold", UintegerValue (28));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRsrqThreshold", UintegerValue (18));
lteHelper->SetFfrAlgorithmAttribute ("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_3));
lteHelper->SetFfrAlgorithmAttribute ("MediumAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Verbeterde Fractioneel Frequentie visfuik Algoritme
Enhanced Fractional Frequency Reuse (EFFR) reserveert een deel van de systeembandbreedte voor elke cel
(doorgaans zijn er 3 celtypen en krijgt elk 1/3 van de systeembandbreedte). Dan een deel van
deze subbandbreedte die het gebruikte als Primair Segment met hergebruikfactor 3 en als Secundair Segment
met hergebruikfactor 1. De gebruiker moet de offset van de celsubbandbreedte configureren (voor DL ​​en UL).
in aantal RB, aantal RB dat zal worden gebruikt als Primair Segment en aantal RB welke
zal worden gebruikt als Secundair Segment. Primair Segment wordt door de cel naar believen gebruikt, maar RB's van
Secundair Segment kan alleen aan UE worden toegewezen als de CQI-feedback van deze UE hoger is
waarde dan de geconfigureerde CQI-drempel. UE wordt beschouwd als rand UE wanneer de RSRQ lager is
neem contact Rsrqdrempel.

Omdat elke eNb moet weten waar de primaire en secundaire cellen van andere celtypen zijn, zal hij dat ook doen
bereken ze, ervan uitgaande dat de configuratie voor elke cel hetzelfde is en alleen voor de subbandbreedte
compensaties zijn verschillend. Het is dus belangrijk om de beschikbare systeembandbreedte gelijkmatig te verdelen
elke cel en pas daarop dezelfde configuratie van primaire en secundaire segmenten toe.

Verbeterd fractioneel frequentiehergebruikalgoritme biedt de volgende kenmerken:

· UlSubBandOffset: Uplink SubBand Offset voor deze cel in aantal resourceblokken
Groepen

· UlReuse3Sub-bandbreedte: Uplink hergebruik 3 subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· UlReuse1Sub-bandbreedte: Uplink hergebruik 1 subbandbreedteconfiguratie in aantal bronnen
Groepen blokkeren

· DlSubBandOffset: Downlink SubBand Offset voor deze cel in aantal resourceblokken
Groepen

· DlHergebruik3Sub-bandbreedte: Downlink hergebruik 3 subbandbreedteconfiguratie in aantal
Resourceblokgroepen

· DlHergebruik1Sub-bandbreedte: Downlink hergebruik 1 subbandbreedteconfiguratie in aantal
Resourceblokgroepen

· Rsrqdrempel: Als de RSRQ van slechter is dan deze drempel, moet UE worden geserveerd
rand subband

· CenterAreaPowerOffset: PdschConfigDedicated::Pa-waarde voor middelste subband, standaard
waarde dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::Pa-waarde voor randsubband, standaardwaarde
dB0

· DlCqidrempel: Als de DL-CQI voor RBG hoger is dan deze drempel, wordt er verzonden
op RBG is mogelijk

· UlCqidrempel: Als de UL-CQI voor RBG hoger is dan deze drempel, wordt er verzonden
op RBG is mogelijk

· CenterAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het middengebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· EdgeAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het randgebied, Absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

In het onderstaande voorbeeld is de offset in DL en UL 0 RB, waarbij 4 RB wordt gebruikt Primair Segment en
Secundair Segment. RSRQ-drempel tussen midden- en randgebied is 25 dB. DL en UL CQI
drempels zijn ingesteld op de waarde 10. Het vermogen in het middengebied is gelijk LteEnbPhy::TxPower - 6dB,
macht in randgebied is gelijk LteEnbPhy::TxPower + 0dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrEnhancedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute("DlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("UlCqiThreshold", UintegerValue (10));
lteHelper->SetFfrAlgorithmAttribute("CenterAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB_6));
lteHelper->SetFfrAlgorithmAttribute("EdgeAreaPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute("UlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("UlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("UlReuse1SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlSubBandOffset", UintegerValue (0));
lteHelper->SetFfrAlgorithmAttribute("DlReuse3SubBandwidth", UintegerValue (4));
lteHelper->SetFfrAlgorithmAttribute("DlReuse1SubBandwidth", UintegerValue (4));

Distributed Fractioneel Frequentie visfuik Algoritme
Voor gedistribueerd fractioneel frequentiehergebruik is een X2-interface tussen alle eNB's vereist
geïnstalleerd. X2-interfaces kunnen alleen worden geïnstalleerd als EPC is geconfigureerd, dus dit FFR-schema
kan alleen worden gebruikt met EPC-scenario's.

Met het Distributed Fractional Frequency Reuse Algorithm gebruikt eNb de gehele celbandbreedte en
er kunnen twee subbanden zijn: middensubband en randsubband. Binnen deze subbanden zijn UE's
kan op verschillende vermogensniveaus worden geserveerd. Algoritme selecteert adaptief RB's voor celrand
sub-band op basis van coördinatie-informatie (dwz RNTP) van aangrenzende cellen en meldt
de basisstations van de aangrenzende cellen, welke RB's zijn geselecteerd om te gebruiken in de randsubband. Als
er zijn geen UE's geclassificeerd als rand-UE in de cel, eNB zal geen RB's gebruiken als rand-subband.

Het gedistribueerde algoritme voor hergebruik van fractionele frequentie biedt de volgende kenmerken:

· Berekeningsinterval: Tijdsinterval tussen berekening van Edge-subband, standaard
waarde 1 seconde

· Rsrqdrempel: Als de RSRQ van slechter is dan deze drempel, moet UE worden geserveerd
rand subband

· RsrpVerschildrempel: Als het verschil tussen de kracht van het ontvangen signaal
door UE van de bedienende cel en de kracht van het signaal ontvangen van de aangrenzende cel
cel kleiner is dan een RsrpDifferenceThreshold-waarde, wordt het celgewicht verhoogd

· CenterPowerOffset: PdschConfigDedicated::Pa-waarde voor randsubband, standaardwaarde
dB0

· EdgePowerOffset: PdschConfigDedicated::Pa-waarde voor edge-subband, standaardwaarde dB0

· RandRbNum: Aantal RB dat kan worden gebruikt in de randsubband

· CenterAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het middengebied, absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

· EdgeAreaTpc: TPC-waarde die wordt ingesteld in DL-DCI voor UE's in het randgebied, Absoluut
modus wordt gebruikt, standaardwaarde 1 wordt toegewezen aan -1 volgens TS36.213 Tabel 5.1.1.1-2

In het onderstaande voorbeeld is het berekeningsinterval 500 ms. RSRQ-drempel tussen midden en rand
gebied is 25. RSRP-verschildrempel is ingesteld op 5. In DL en UL wordt RB gebruikt door
elke cel in de randsubband. Het vermogen in het middengebied is gelijk LteEnbPhy::TxPower - 0dB, kracht
in randgebied gelijk LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("CalculationInterval", TimeValue(MilliSeconden(500)));
lteHelper->SetFfrAlgorithmAttribute ("RsrqThreshold", UintegerValue (25));
lteHelper->SetFfrAlgorithmAttribute ("RsrpDifferenceThreshold", UintegerValue (5));
lteHelper->SetFfrAlgorithmAttribute ("EdgeRbNum", UintegerValue (6));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset",
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));

Automatisch configuratie
Algoritmen voor frequentiehergebruik kunnen ook op een meer ‘automatische’ manier worden geconfigureerd door alleen instellingen in te stellen
de bandbreedte en FrCellTypeId. Tijdens de initialisatie van het FR-exemplaar wordt configuratie voor
stel de bandbreedte in en FrCellTypeId wordt uit de configuratietabel gehaald. Het is belangrijk
dat alleen subbanden zullen worden geconfigureerd, drempels en zendvermogen zullen worden ingesteld
standaard waarden. Als iemand dat wil, kan hij/zij de drempels en het zendvermogen naar wens wijzigen
in de vorige subsectie.

Er zijn drie FrCellTypeId: 1, 2, 3, die overeenkomen met drie verschillende configuraties
voor elke bandbreedte. Drie configuraties maken het mogelijk om verschillende configuraties in te voeren
aangrenzende cellen in zeshoekige eNB-indeling. Als de gebruiker meer verschillende nodig heeft
configuratie voor aangrenzende cellen, moet hij/zij handmatige configuratie gebruiken.

Het onderstaande voorbeeld toont de automatische FR-algoritmeconfiguratie:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Uplink Power Controle
De Uplink Power Control-functionaliteit is standaard ingeschakeld. De gebruiker kan dit uitschakelen door in te stellen
het Booleaanse attribuut ns3::LteUePhy::UplinkPowerControl inschakelen naar waar.

De gebruiker kan schakelen tussen Open Loop Power Control- en Closed Loop Power Control-mechanismen
door het booleaanse attribuut in te stellen ns3::LteUePowerControl::Gesloten lus. Standaard gesloten
Loop Power Control met accumulatiemodus is ingeschakeld.

Padverlies is een belangrijk onderdeel van Uplink Power Control. Het wordt berekend als het verschil tussen
gefilterde RSRP- en ReferenceSignalPower-parameter. ReferenceSignalPower wordt verzonden met SIB2.

Kenmerken beschikbaar in Uplink Power Control:

· Gesloten kring: indien waar Closed Loop Uplink Power Control-modus is ingeschakeld en Open Loop
Power Control, anders is de standaardwaarde false

· AccumulatieIngeschakeld: als de echte accumulatiemodus is ingeschakeld en de absolute modus
anders is de standaardwaarde false

· Alpha: de padverliescompensatiefactor, standaardwaarde is 1.0

· PCmin: minimale UE TxPower, standaardwaarde is -40 dBm

· Pcmax: maximale UE TxPower, standaardwaarde is 23 dBm

· PoNominaalPusch: deze parameter zou door hogere lagen moeten worden ingesteld, maar momenteel is dit nodig
te configureren per attribuutsysteem, mogelijke waarden zijn gehele getallen binnen het bereik (-126 ...
24), de standaardwaarde is -80

· PoUePusch: deze parameter zou door hogere lagen moeten worden ingesteld, maar momenteel is dat nodig
worden geconfigureerd door een attribuutsysteem, mogelijke waarden zijn gehele getallen binnen het bereik (-8 ... 7),
Standaardwaarde is 0

· PsrsOffset: deze parameter zou door hogere lagen moeten worden ingesteld, maar momenteel is dat nodig
worden geconfigureerd door een attribuutsysteem, mogelijke waarden zijn gehele getallen binnen het bereik (0 ... 15),
De standaardwaarde is 7, wat P_Srs_Offset_Value = 0 oplevert

Getraceerd waarden in Uplink Power Controle:

· RapportPuschTxPower: Huidige UE TxPower voor PUSCH

· RapportPucchTxPower: Huidige UE TxPower voor PUCCH

· RapportSrsTxPower: Huidige UE TxPower voor SRS

Voorbeeldconfiguratie wordt hieronder weergegeven:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (true));
Config::SetDefault ("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

De gebruiker kan bijvoorbeeld een kijkje nemen en het lena-uplink-power-control programma uitvoeren.

Voorbeelden Programma's
De map src/lte/voorbeelden/ bevat enkele voorbeeldsimulatieprogramma's die laten zien hoe dat moet
simuleer verschillende LTE-scenario's.

Referentie scenario's
Er is een groot aantal referentie-LTE-simulatiescenario's te vinden in de
literatuur. Hier noemen we er enkele:

· De systeemsimulatiescenario's genoemd in sectie A.2 van [TR36814].

· Het dual stripe-model [R4-092042], dat gedeeltelijk is geïmplementeerd in het voorbeeld
programma src/lte/examples/lena-dual-stripe.cc. Dit voorbeeldprogramma bevat veel
configureerbare parameters die kunnen worden aangepast door de overeenkomstige globale parameters te wijzigen
variabelen. Om een ​​lijst van al deze globale variabelen te krijgen, kunt u deze opdracht uitvoeren:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

In de volgende subsectie wordt een voorbeeld gegeven van het uitvoeren van een simulatiecampagne met behulp van
dit voorbeeldprogramma.

Overhandigen simulatie campagne
In deze paragraaf laten we een voorbeeld zien van het uitvoeren van een simulatiecampagne met behulp van
de LTE-module van ns-3. Het doel van de campagne is om het effect van beide te vergelijken
ingebouwd handover-algoritme van de LTE-module.

De campagne zal gebruik maken van de lena-dubbele streep voorbeeld programma. Eerst moeten we de
voorbeeldprogramma om de uitvoer te produceren die we nodig hebben. Bij deze gelegenheid willen we produceren
het aantal overdrachten, de gemiddelde doorvoer van de gebruiker en de gemiddelde SINR.

Het aantal overdrachten kan worden verkregen door het aantal keren te tellen OverdrachtEindeOk
Overhandigen voetstappen wordt ontslagen. Vervolgens kan de gemiddelde doorvoer van de gebruiker worden verkregen door de
RLC Simulatie uitgang. Ten slotte kan SINR worden verkregen door de PHY-simulatie in te schakelen
uitgang. Het volgende voorbeeldcodefragment toont een mogelijke manier om het bovenstaande te verkrijgen:

komen te vervallen
NotifyHandoverEndOkUe (std::string context, uint64_t imsi,
uint16_t celId, uint16_t rnti)
{
std::cout << "Overdracht IMSI" << imsi << std::endl;
}

int
hoofd (int argc, char *argv[])
{
/***SNIP ***/

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces ();
lteHelper->EnableRlcTraces ();
Ptr rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime", TimeValue (Seconden (0)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Seconden (simTime)));

Simulator::Uitvoeren ();
Simulator::Vernietigen ();
0 terug;
}

Vervolgens moeten we de parameters van het programma configureren om aan onze simulatiebehoeften te voldoen. Wij
zijn op zoek naar de volgende aannames in onze simulatie:

· 7 locaties met uit drie sectoren bestaande macro-eNodeB's (dwz 21 macrocellen) ingezet in zeshoekige
lay-out met een onderlinge afstand van 500 m.

· Hoewel lena-dubbele streep is oorspronkelijk bedoeld voor een two-tier (macrocell en
femtocell) simulatie, zullen we onze simulatie vereenvoudigen tot one-tier (macrocell)
alleen simulatie.

· UE's worden willekeurig over de locaties verdeeld en worden automatisch aan het netwerk gekoppeld
met behulp van celselectie in de standby-stand. Daarna zal UE door de simulatieomgeving dwalen
met een bewegingssnelheid van 60 km/u.

· Simulatieduur van 50 seconden, dus UE's zouden ver genoeg hebben gereisd om er enkele te activeren
overdrachten.

· 46 dBm macrocell Tx-vermogen en 10 dBm UE Tx-vermogen.

· De EPC-modus wordt gebruikt omdat de X2-overdrachtsprocedure vereist dat deze is ingeschakeld.

· Downlink- en uplink-verkeer met volledige buffer, beide in een bandbreedte van 5 MHz, met behulp van het TCP-protocol
en proportionele eerlijke planner.

· Ideaal RRC-protocol.

tafel lena-dubbele streep parameter configuratie voor overhandigen campagne hieronder laat zien hoe wij
configureer de parameters van lena-dubbele streep om bovenstaande aannames te verwezenlijken.

lena-dubbele streep parameter configuratie voor overhandigen campagne
┌───────────────────┬─────────┬────────── ───────── ───────┐
│Parameternaam │ Waarde │ Beschrijving │
├───────────────────┼─────────┼────────── ───────── ───────┤
│simTime │ 50 │ 50 seconden simulatie │
│ │ │ duur │
├───────────────────┼─────────┼────────── ───────── ───────┤
│nBlokken │ 0 │ Appartement uitschakelen │
│ │ │ gebouwen en femtocellen │
├───────────────────┼─────────┼────────── ───────── ───────┤
│nMacroEnbSites │ 7 │ Aantal macrocellen │
│ │ │ locaties (elke site heeft 3 │
│ │ │ cellen) │
├───────────────────┼─────────┼────────── ───────── ───────┤
│nMacroEnbSitesX │ 2 │ De macrocelsites zullen │
│ │ │ gepositioneerd zijn in een 2-3-2 │
│ │ │ vorming │
├───────────────────┼─────────┼────────── ───────── ───────┤
│interSiteDistance │ 500 │ 500 m afstand tussen │
│ │ │ aangrenzende macrocellocaties │
├───────────────────┼─────────┼────────── ───────── ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 dBm Tx-vermogen voor elke │
│ │ │ macrocel │
├───────────────────┼─────────┼────────── ───────── ───────┤
│epc │ 1 │ EPC-modus inschakelen │
└───────────────────┴─────────┴────────── ───────── ───────┘

│epcDl │ 1 │ Volledige buffer DL inschakelen │
│ │ │ verkeer │
├───────────────────┼─────────┼────────── ───────── ───────┤
│epcUl │ 1 │ Volledige buffer UL inschakelen │
│ │ │ verkeer │
├───────────────────┼─────────┼────────── ───────── ───────┤
│useUdp │ 0 │ Schakel UDP-verkeer uit en │
│ │ │ schakel in plaats daarvan TCP in │
├───────────────────┼─────────┼────────── ───────── ───────┤
│macroUeDensity │ 0.00002 │ Bepaalt het aantal UE's │
│ │ │ (vertaalt naar 48 UE's in │
│ │ │ onze simulatie) │
├───────────────────┼─────────┼────────── ───────── ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ Minimale UE-beweging │
│ │ │ snelheid in m/s (60 km/u) │
├───────────────────┼─────────┼────────── ───────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ Maximale UE-beweging │
│ │ │ snelheid in m/s (60 km/u) │
├───────────────────┼─────────┼────────── ───────── ───────┤
│macroEnbBandbreedte │ 25 │ 5 MHz DL en UL │
│ │ │ bandbreedte │
├───────────────────┼─────────┼────────── ───────── ───────┤
│generateRem │ 1 │ (Optioneel) Voor plotten │
│ │ │ de radioomgeving │
│ │ │ Kaart │
└───────────────────┴─────────┴────────── ───────── ───────┘

Sommige van de vereiste aannames zijn niet beschikbaar als parameters lena-dubbele streep. in
In dit geval overschrijven we de standaardkenmerken, zoals weergegeven in de tabel Dwingend verzuim
attributen voor overhandigen campagne hieronder.

Dwingend verzuim attributen voor overhandigen campagne
┌──────────────────────────────────────── ───────── ────┬────────────────────────────────┬─── ───────── ──────────────┐
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::LteHelper::HandoverAlgoritme │ ns3::NoOpHandoverAlgoritme, │ Keuze van overdracht │
│ ns3::A3RsrpHandoveralgoritme, │ algoritme │
│ ns3::A2A4RsrqHandoveralgoritme │
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::LteHelper::Scheduler │ ns3::PfFfMacScheduler │ Proportioneel Redelijk │
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputBestandsnaam │ -DlRlcStats.txt │ Bestandsnaam voor DL ​​RLC │
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputBestandsnaam │ -UlRlcStats.txt │ Bestandsnaam voor UL RLC │
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrBestandsnaam │ -DlRsrpSinrStats.txt │ Bestandsnaam voor DL ​​PHY │
├──────────────────────────────────────── ───────── ────┼────────────────────────────────┼─── ───────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrBestandsnaam │ -UlSinrStats.txt │ Bestandsnaam voor UL PHY │
└──────────────────────────────────────── ───────── ────┴────────────────────────────────┴─── ───────── ──────────────┘

ns-3 biedt vele manieren om configuratiewaarden door te geven aan een simulatie. In deze
We zullen bijvoorbeeld de opdrachtregelargumenten gebruiken. Het wordt in principe gedaan door het toevoegen van de
parameters en hun waarden aan de waf bellen bij het starten van elke individuele simulatie. Dus
the waf oproepen voor het aanroepen van onze 3 simulaties zouden er als volgt uitzien:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=geen-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=geen-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=geen-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=geen-op-UlSinrStats.txt
--RngRun=1" > geen-op.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A3RsrpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a3-rsrp-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a3-rsrp-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

Enkele opmerkingen over de uitvoering:

· Merk op dat sommige argumenten niet zijn gespecificeerd omdat ze al hetzelfde zijn als de
standaard waarden. We houden ook de overdrachtsalgoritmen op hun eigen standaardinstellingen.

· Let op de bestandsnamen van de simulatie-uitvoer, bijvoorbeeld RLC-traces en PHY-traces, omdat we
Zorg ervoor dat ze niet worden overschreven door de volgende simulatierun. In deze
We specificeren de namen bijvoorbeeld één voor één met behulp van de opdrachtregelargumenten.

· De --RngRun=1 argument aan het einde wordt gebruikt voor het instellen van het runnummer dat wordt gebruikt door de
generator voor willekeurige getallen die in de simulatie wordt gebruikt. We voeren dezelfde simulaties opnieuw uit met
anders RngRun waarden, waardoor er verschillende onafhankelijke replicaties van hetzelfde ontstaan
simulaties. Vervolgens berekenen we het gemiddelde van de resultaten die uit deze replicaties zijn verkregen
enig statistisch vertrouwen.

· We kunnen een toevoegen --genereerRem=1 argument om de bestanden te genereren die nodig zijn voor het genereren
de Radio Environment Map (REM) van de simulatie. Het resultaat is Figuur REM verkregen
van a simulatie in overhandigen campagne hieronder, die kan worden geproduceerd door het volgen van de
stappen beschreven in Sectie Radio Milieu Maps. Deze figuur toont ook de
positie van eNodeB's en UE's aan het begin van een simulatie met behulp van RngRun = 1. anders
waarden van RngRun kan een ander UE-standpunt opleveren.
[afbeelding] REM verkregen uit een simulatie in de overdrachtscampagne.UNINDENT

Na urenlang rennen zal de simulatiecampagne uiteindelijk eindigen. Vervolgens zullen we dat doen
voer enige nabewerking uit op de geproduceerde simulatie-uitvoer om betekenisvolle resultaten te verkrijgen
informatie eruit.

In dit voorbeeld gebruiken we GNU Octave om de verwerking van doorvoer- en SINR-gegevens te ondersteunen,
zoals gedemonstreerd in een voorbeeld van een GNU Octave-script hieronder:

% RxBytes is de 10e kolom
DlRxBytes = laden ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = som (DlRxBytes) * 8/1000/50

% RxBytes is de 10e kolom
UlRxBytes = laden ("no-op-UlRlcStats.txt") (:,10);
UlAverageThroughputKbps = som (UlRxBytes) * 8/1000/50

% Sinr is de 6e kolom
DlSinr = laden ("no-op-DlRsrpSinrStats.txt") (:,6);
% elimineert NaN-waarden
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (gemiddelde (DlSinr)) % omgezet naar dB

% Sinr is de 5e kolom
UlSinr = laden ("no-op-UlSinrStats.txt") (:,5);
% elimineert NaN-waarden
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (gemiddelde (UlSinr)) % omgezet naar dB

Wat het aantal overdrachten betreft, kunnen we eenvoudige shell-scripting gebruiken om het aantal te tellen
voorkomens van de tekenreeks "Handover" in het logbestand:

$ grep "Overdracht" no-op.txt | wc -l

tafel Resultaten of overhandigen campagne hieronder ziet u de volledige statistieken nadat we klaar zijn
met nabewerking bij elke individuele simulatierun. De weergegeven waarden zijn het gemiddelde
van de resultaten verkregen uit RngRun van 1, 2, 3 en 4.

Resultaten of overhandigen campagne
┌────────────────────┬────────────┬────── ───────┬─ ───────────────┐
│Statistieken │ Geen operatie │ A2-A4-RSRQ │ Sterkste cel │
├────────────────────┼────────────┼────── ───────┼─ ───────────────┤
│Gemiddeld DL-systeem │ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│doorvoer │ │ │ │
├────────────────────┼────────────┼────── ───────┼─ ───────────────┤
│Gemiddeld UL-systeem │ 4 kbps │ 095 kbps │ 5 kbps │
│doorvoer │ │ │ │
├────────────────────┼────────────┼────── ───────┼─ ───────────────┤
│Gemiddelde DL SINR │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├────────────────────┼────────────┼────── ───────┼─ ───────────────┤
│Gemiddelde UL SINR │ 9.54 dB │ 81.57 dB │ 79.65 dB │
├────────────────────┼────────────┼────── ───────┼─ ───────────────┤
│Aantal overdrachten │ 0 │ 0.05694 │ 0.04771 │
│per UE per seconde │ │ │ │
└────────────────────┴────────────┴────── ───────┴─ ───────────────┘

De resultaten laten zien dat het hebben van een overdrachtsalgoritme in een mobiliteitssimulatie beide verbetert
gebruikersdoorvoer en SINR aanzienlijk. Er is weinig verschil tussen de twee
overdrachtsalgoritmen in dit campagnescenario. Het zou interessant zijn om hun te zien
prestaties in verschillende scenario's, zoals scenario's met thuis-eNodeBs-implementatie.

Frequentie visfuik voorbeelden
Er zijn twee voorbeelden die de functionaliteit van frequentiehergebruikalgoritmen laten zien.

lena-frequentie-hergebruik is een eenvoudig voorbeeld met 3 eNB's in driehoekige lay-out. Er zijn 3 cellen
rand-UE's, die zich in het midden van deze driehoek bevinden, en 3 celcentrum-UE's (één dichtbij
elke eNB). De gebruiker kan ook het aantal willekeurig gelokaliseerde UE's opgeven. FR-algoritme is
geïnstalleerd in eNB's en elke eNB heeft een andere FrCellTypeId, wat betekent dat elke eNB gebruikt
verschillende FR-configuratie. Gebruiker kan rennen lena-frequentie-hergebruik met 6 verschillende FR
algoritmen: NoOp, Hard FR, Strict FR, Soft FR, Soft FFR en Enhanced FFR. Scenario uitvoeren
met het gedistribueerde FFR-algoritme dat de gebruiker moet gebruiken lena-gedistribueerd-ffr. Deze twee voorbeelden
lijken erg op elkaar, maar ze zijn opgesplitst omdat gedistribueerde FFR vereist dat EPC wordt gebruikt,
en andere algoritmen niet.

Rennen lena-frequentie-hergebruik met verschillende algoritmen voor frequentiehergebruik moet de gebruiker dat doen
specificeer het FR-algoritme door het standaardkenmerk te overschrijven ns3::LteHelper::FfrAlgoritme.
Voorbeeldopdracht om uit te voeren lena-frequentie-hergebruik met Soft FR-algoritme wordt hieronder weergegeven:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

In deze voorbeelden is functionaliteit voor het genereren van REM en spectrumanalysatortracering toegevoegd.
De gebruiker kan het genereren ervan inschakelen door in te stellen genererenRem en SpectrumTrace genereren
attributen.

Commando om REM te genereren voor RB 1 in datakanaal van lena-frequentie-hergebruik scenario met
Het Soft FR-algoritme wordt hieronder weergegeven:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

Radioomgevingskaart voor Soft FR wordt weergegeven in figuur REM voor RB 1 verkregen van
lena-frequentie-hergebruik voorbeeld met Soft /Pastel FR algoritme ingeschakeld.
[afbeelding] REM voor RB 1 verkregen van lena-frequentie-hergebruik voorbeeld met Soft FR-algoritme
ingeschakeld.UNINDENT

Commando om spectrumtracering te genereren lena-frequentie-hergebruik scenario met zachte FFR
algoritme wordt hieronder weergegeven (de positie van de spectrumanalysator moet binnenin worden geconfigureerd).
script):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

Een voorbeeld van een spectrumanalysatortrace wordt weergegeven in de figuur Spectrum Analyzer opsporen verkregen
van lena-frequentie-hergebruik voorbeeld met Soft /Pastel FFR algoritme ingeschakeld. Spectrum Analyzer was
gelegen genoodzaakt bent eNB met FrCellTypeId 2.. Zoals te zien zijn, verschillende datakanaalsubbanden
worden verzonden met een ander vermogensniveau (afhankelijk van de configuratie), terwijl het stuurkanaal dat wel is
verzonden met uniform vermogen over de gehele systeembandbreedte.
[afbeelding] Spectrumanalyzer-trace verkregen van lena-frequentie-hergebruik bijvoorbeeld met Zachte FFR
algoritme ingeschakeld. Spectrum Analyzer is gelokaliseerd met eNB met FrCellTypeId 2..UNINDENT

lena-dubbele streep kan ook worden uitgevoerd met algoritmen voor frequentiehergebruik die in alle macro's zijn geïnstalleerd
eNB. De gebruiker moet het FR-algoritme opgeven door het standaardkenmerk te overschrijven
ns3::LteHelper::FfrAlgoritme. Voorbeeldopdracht om uit te voeren lena-dubbele streep met harde FR
algoritme wordt hieronder weergegeven:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=geen-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=geen-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=geen-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=geen-op-UlSinrStats.txt
--RngRun=1" > geen-op.txt

Voorbeeldopdracht om REM voor RB 1 in datakanaal te genereren lena-dubbele streep scenario
met Hard FR-algoritme wordt hieronder weergegeven:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=geen-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=geen-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=geen-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=geen-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > geen-op.txt

Radioomgevingskaarten voor RB 1, 10 en 20 gegenereerd op basis van lena-dubbele streep scenario met
Het algoritme voor hergebruik van harde frequenties wordt weergegeven in de onderstaande figuren. Deze RB zijn geselecteerd
omdat ze allemaal door een ander FR-celtype worden gebruikt.
[afbeelding] REM voor RB 1 verkregen van lena-dubbele streep simulatie met Hard FR-algoritme
ingeschakeld.UNINDENT
[afbeelding] REM voor RB 10 verkregen van lena-dubbele streep simulatie met Hard FR-algoritme
ingeschakeld.UNINDENT
[afbeelding] REM voor RB 20 verkregen van lena-dubbele streep simulatie met Hard FR-algoritme
ingeschakeld.UNINDENT

Troubleshooting en debugging tips
Veel gebruikers posten op de ns-3-users mailinglijst en vragen bijvoorbeeld waarom ze niets ontvangen
verkeer in hun simulatie, of misschien alleen uplink maar geen downlinkverkeer, enz. In de meeste gevallen
In deze gevallen is het een bug in het gebruikerssimulatieprogramma. Hier volgen enkele tips voor het debuggen van de
programma en ontdek de oorzaak van het probleem.

De algemene aanpak is om selectief en stapsgewijs het loggen van relevante gegevens mogelijk te maken
LTE-modulecomponenten, die bij elke activering controleren of de uitvoer is zoals verwacht. In
detail:

· controleer eerst het besturingsvlak, in het bijzonder de totstandkoming van de RRC-verbinding
procedure, door de logcomponenten LteUeRrc en LteEnbRrc in te schakelen

· controleer vervolgens de pakkettransmissies op het datavlak, te beginnen met het inschakelen van het logbestand
componenten LteUeNetDevice en de EpcSgwPgwApplication, dan EpcEnbApplication, dan
naar beneden gaan in de LTE-radiostack (PDCP, RLC, MAC en ten slotte PHY). Dit alles tot jij
Zoek waar pakketten niet meer worden verwerkt/doorgestuurd.

Testen Documentatie
Overzicht
Om de ns-3 LTE-module te testen en te valideren, zijn er verschillende testsuites beschikbaar
geïntegreerd met het ns-3-testframework. Om ze uit te voeren, moet u de
bouw de simulator op deze manier:

$ ./waf configure --enable-tests --enable-modules=lte --enable-examples
$ ./test.py

Het bovenstaande zal niet alleen de testsuites uitvoeren die bij de LTE-module horen, maar ook die
behorend tot alle andere ns-3-modules waarvan de LTE-module afhankelijk is. Zie de ns-3
handleiding voor algemene informatie over het toetsingskader.

U kunt op deze manier een meer gedetailleerd rapport in HTML-indeling krijgen:

$ ./test.py -w resultaten.html

Nadat de bovenstaande opdracht is uitgevoerd, kunt u het gedetailleerde resultaat voor elke test bekijken door te openen
het bestand resultaten.html met een webbrowser.

U kunt elke testsuite afzonderlijk uitvoeren met deze opdracht:

$ ./test.py -s naam testsuite

Voor meer informatie over test.py en het ns-3 toetsingskader, zie de ns-3
manual.

Beschrijving of the proef suites
Eenheid Tests
ZIN berekening in the downlink
De testsuite Lte-downlink-sinr controleert of de SINR-berekening in de downlink wordt uitgevoerd
correct. De SINR in de downlink wordt berekend voor elke RB die aan gegevens is toegewezen
transmissies door het vermogen van het beoogde signaal van de beschouwde eNB te delen door de
som van het ruisvermogen plus alle transmissies op dezelfde RB afkomstig van andere eNB's
(de stoorsignalen):

Over het algemeen kunnen verschillende signalen actief zijn gedurende verschillende tijdsperioden. Wij definiëren een
brok als het tijdsinterval tussen twee gebeurtenissen van het type begin of einde van a
golfvorm. Met andere woorden, een chunk identificeert een tijdsinterval gedurende welke de set van
actieve golfvormen veranderen niet. Laat i het generieke deel zijn, T_i de duur ervan en
thrm{SINR_i} is de SINR, berekend met de bovenstaande vergelijking. De berekening van het gemiddelde
SINR rieme
De testsuite controleert of bovenstaande berekening correct wordt uitgevoerd in de simulator.
De testvectoren worden offline verkregen door een Octave-script dat het bovenstaande implementeert
vergelijking, en dat bootst een aantal willekeurig verzonden signalen en interferentie na
signalen die een scenario nabootsen waarin een UE een signaal van een eNB probeert te decoderen
geconfronteerd met interferentie van andere eNB's. De test is geslaagd als de berekende waarden gelijk zijn aan
de testvector binnen een tolerantie van 10^{-7}. De tolerantie is bedoeld om rekening te houden met de
benaderingsfouten die typisch zijn voor drijvende-kommaberekeningen.

ZIN berekening in the Uplink
De testsuite Lte-uplink-sinr controleert of de SINR-berekening in de uplink wordt uitgevoerd
correct. Deze testsuite is identiek aan Lte-downlink-sinr beschreven in het voorgaande
sectie, met het verschil waar zowel het signaal als de interferentie nu naar verwijzen
transmissies door de UE's, en ontvangst wordt uitgevoerd door de eNB. Deze testsuite
reconstrueert een aantal willekeurig verzonden signalen en interferentiesignalen om a
scenario waarin een eNB het signaal van meerdere UE's tegelijkertijd probeert te decoderen (de
degenen in de cel van de eNB) terwijl ze te maken krijgen met interferentie van andere EU's (degenen die erbij horen).
naar andere cellen).

De testvectoren worden verkregen door een speciaal Octave-script. De test is geslaagd als de
berekende waarden zijn gelijk aan de testvector binnen een tolerantie van 10^{-7} wat, zoals voor
de downlink SINR-test behandelt problemen met de rekenkundige benadering van drijvende komma.

E-UTRA absoluut Radio Frequentie Kanaal Telefoon Nummer (EARFCN)
De testsuite lte-earfcn controleert of de draaggolffrequentie die door de
De LteSpectrumValueHelper-klasse (die het LTE-spectrummodel implementeert) wordt gedaan in
overeenstemming met [TS36101], waar het E-UTRA absolute radiofrequentiekanaalnummer staat
(EARFCN) is gedefinieerd. De testvector voor deze testsuite omvat een reeks EARFCN-waarden
en de overeenkomstige draaggolffrequentie die met de hand wordt berekend volgens de specificatie van
[TS36101]. De test is geslaagd als de door LteSpectrumValueHelper geretourneerde draaggolffrequentie dat is
hetzelfde als de bekende waarde voor elk element in de testvector.

Systeem Tests
Toegewijd Toonder deactivatie Tests
De testsuite 'lte-test-deactivate-bearer' creëert testcases met enkele EnodeB en Three
UE's. Elke UE bestaat uit één standaard- en één speciale EPS-drager met dezelfde drager
specificatie maar met verschillende ARP. De testcasestroom is als volgt: UE bijvoegen -> Maken
Standaard + Toegewijde drager -> Deactiveer een van de speciale dragers

Testcase deactiveert verder de specifieke drager met drager-ID 2 (LCID=BearerId+2) van
Eerste UE (UE_ID=1) De gebruiker kan de deactivering van de drager plannen na een specifieke tijdsvertraging met behulp van
Simulator::Schedule ()-methode.

Zodra de uitvoering van de testcase is beëindigd, worden DlRlcStats.txt en UlRlcStats.txt aangemaakt. Sleutel
velden die moeten worden gecontroleerd in de statistieken zijn:

|
Begin | einde | Cel-ID | IMSI | RNTI | LCID | TxBytes | RxBytes |

Testcase wordt uitgevoerd in drie tijdperken. 1) In het eerste tijdperk (0.04s-1.04s) Alle UE's en
overeenkomstige dragers worden gehecht
en pakketstroom over de geactiveerde specifieke dragers.

2. In het tweede tijdperk (1.04s-2.04s) wordt de dragerdeactivering geïnstantieerd, zodat de gebruiker kan zien
relatief minder aantal TxBytes op UE_ID=1 en LCID=4 vergeleken met andere dragers.

3. In het derde tijdperk (2.04s-3.04s) sinds de deactivering van de drager van UE_ID=1 en LCID=4 is
voltooid, ziet de gebruiker geen logboekregistratie gerelateerd aan LCID=4.

Testgeval slaagt als en slechts als 1) IMSI=1 en LCID=4 volledig verwijderd in derde tijdperk 2)
Geen pakketten gezien in TxBytes en RxBytes die overeenkomen met IMSI=1 en LCID=4 Indien hierboven
criterium komt niet overeen met de testcase die als mislukt wordt beschouwd

Adaptieve Modulatie en codering Tests
De testsuite lte-link-aanpassing biedt systeemtests waarmee een scenario wordt nagebootst met een
enkele eNB en een enkele UE. Er worden verschillende testgevallen gemaakt die overeenkomen met verschillende
SNR-waarden waargenomen door de UE. Het doel van de test is om te controleren of in elk testgeval de
de gekozen MCS komt overeen met enkele bekende referentiewaarden. Deze referentiewaarden worden verkregen
door opnieuw te implementeren in Octave (zie src/lte/test/reference/lte_amc.m) het model beschreven in
Sectie sec-lte-amc voor het berekenen van de spectrale efficiëntie en het bepalen van de
overeenkomstige MCS-index door handmatig de tabellen op te zoeken in [R1-081483]. Het resultaat
testvector wordt weergegeven in figuur test vector voor Adaptieve Modulatie en codering.

De MCS die door de simulator wordt gebruikt, wordt gemeten door de traceringsoutput te verkrijgen
geproduceerd door de planner na 4 ms (dit is nodig om rekening te houden met de aanvankelijke vertraging in
CQI-rapportage). De SINR die door de simulator wordt berekend, wordt ook verkregen met behulp van de
LteChunkProcessor koppel. De test is geslaagd als aan beide volgende voorwaarden is voldaan
tevreden:

1. de door de simulator berekende SINR komt overeen met de SNR van de testvector binnenin
een absolute tolerantie van 10^{-7};

2. de door de simulator gebruikte MCS-index komt exact overeen met die in de test
vector.
[afbeelding] Testvector voor adaptieve modulatie en codering.UNINDENT

Intercel Storing Tests
De testsuite Lte-interferentie biedt systeemtests die een intercel opnieuw creëren
interferentiescenario met twee eNB's, waaraan elk een enkele UE is gekoppeld en die gebruik maken van
Adaptieve modulatie en codering, zowel in de downlink als in de uplink. De topologie van de
scenario wordt weergegeven in figuur topologie voor the intercel storing proef. De d_1
parameter vertegenwoordigt de afstand van elke UE tot de eNB waaraan deze is bevestigd, terwijl de d_2
parameter vertegenwoordigt de interferentieafstand. We merken op dat de scenariotopologie zo is
dat de interferentieafstand hetzelfde is voor uplink en downlink; toch: de werkelijkheid
Het waargenomen interferentievermogen zal anders zijn vanwege het verschillende voortplantingsverlies
in de uplink- en downlinkbanden. Verschillende testgevallen worden verkregen door de d_1 en te variëren
d_2-parameters.
[afbeelding] Topologie voor de intercelinterferentietest.UNINDENT

De testvectoren worden verkregen door gebruik te maken van een speciaal octaafscript (beschikbaar in
src/lte/test/reference/lte_link_budget_interference.m), die het linkbudget doet
berekeningen (inclusief interferentie) die overeenkomen met de topologie van elk testgeval,
en voert de resulterende SINR en spectrale efficiëntie uit. Dat laatste is dan gewend
bepalen (met behulp van dezelfde procedure als voor Adaptieve Modulatie en codering Tests. Wij
merk op dat de testvector afzonderlijke waarden bevat voor uplink en downlink.

UE Afmetingen Tests
De testsuite Lte-ue-metingen biedt systeemtests die een intercel opnieuw creëren
interferentiescenario identiek aan het scenario waarvoor gedefinieerd Lte-interferentie test pak.
Bij deze test worden de te testen hoeveelheden echter weergegeven door RSRP en RSRQ
metingen uitgevoerd door de UE op twee verschillende punten van de stapel: de bron, die
is de UE PHY-laag en de bestemming, dat wil zeggen de eNB RRC.

De testvectoren worden verkregen door gebruik te maken van een speciaal octaafscript (beschikbaar in
src/lte/test/reference/lte-ue-measurements.m), die de koppelingsbudgetberekeningen uitvoert
(inclusief interferentie) die overeenkomt met de topologie van elk testgeval, en voert de
resulterende RSRP en RSRQ. De verkregen waarden worden vervolgens gebruikt om de juistheid ervan te controleren
de UE-metingen op de PHY-laag. Daarna moeten ze worden omgezet volgens 3GPP
opmaak met als doel de juistheid ervan op eNB RRC-niveau te controleren.

UE maat configuratie testen
Naast de eerder genoemde testsuite zijn er nog 3 andere testsuites voor het testen van UE
afmetingen: Lte-ue-metingen-stuksgewijs-1, Lte-ue-metingen-stuksgewijs-2 en
Lte-ue-metingen-overdracht. Deze testsuites zijn meer gericht op de rapportagetrigger
procedure, dat wil zeggen de juistheid van de implementatie van de op gebeurtenissen gebaseerde triggering
criteria worden hier geverifieerd.

Meer specifiek verifiëren de tests de timing en content van elk meetrapport
ontvangen door eNodeB. Elke testcase is een op zichzelf staande LTE-simulatie en de testcase zal dat ook zijn
geslaagd als meetrapport(en) alleen op het voorgeschreven tijdstip verschijnt en de juiste blijkt
niveau van RSRP (RSRQ is momenteel niet geverifieerd).

stuksgewijs configuratie
De stuksgewijze configuratie heeft tot doel een bepaalde UE-metingsconfiguratie te testen. De
simulatiescript zal de corresponderende meetconfiguratie instellen voor de UE, die
zal tijdens de simulatie actief zijn.

Omdat de referentiewaarden vooraf met de hand worden berekend, worden er verschillende aannames gedaan
vereenvoudig de simulatie. Ten eerste wordt het kanaal alleen beïnvloed door het padverliesmodel (in dit geval
In dit geval wordt het Friis-model gebruikt). Ten tweede wordt het ideale RRC-protocol gebruikt, en laag 3
filteren is uitgeschakeld. Tenslotte beweegt de UE in een vooraf gedefinieerd bewegingspatroon tussen 4
verschillende plekken, zoals weergegeven in figuur UE beweging opsporen overal the simulatie in
stuksgewijs configuratie onderstaand. Daarom kan de fluctuatie van de gemeten RSRP zijn
gemakkelijker bepaald.
[afbeelding] UE-bewegingsspoor tijdens de simulatie in stuksgewijs configuratie.UNINDENT

De motivatie achter de "teleporteren" tussen de vooraf gedefinieerde plekken is te introduceren
drastische verandering van het RSRP-niveau, wat het triggeren van binnenkomen of verlaten garandeert
toestand van de geteste gebeurtenis. Door drastische veranderingen door te voeren kan de test binnenin uitgevoerd worden
kortere tijd.

Figuur Afgemeten adviesprijs opsporen of an voorbeeld Gebeurtenis A1 proef geval in stuksgewijs configuratie
Hieronder ziet u de gemeten RSRP na laag 1-filtering door de PHY-laag tijdens de
simulatie met een stuksgewijs configuratie. Omdat laag 3-filtering is uitgeschakeld, worden deze
zijn de exacte waarden die door de UE RRC-instantie worden gebruikt om de rapportagetrigger te evalueren
procedure. Merk op dat de waarden elke 200 ms worden vernieuwd, wat de standaard is
filterperiode van het PHY-laagmetingsrapport. De figuur toont ook het tijdstip waarop
het betreden en verlaten van de voorwaarden van een voorbeeldinstantie van gebeurtenis A1 (serverende cel wordt
beter dan drempelwaarde) optreden tijdens de simulatie.
[afbeelding] Gemeten RSRP-trace van een voorbeeld van een Event A1-testcase in stukjes
configuratie.UNINDENT

Elk rapportagecriterium wordt meerdere keren getest met verschillende drempels/offsets
parameters. Sommige testscenario's houden ook rekening met hysteresis en time-to-trigger.
Figuur Afgemeten adviesprijs opsporen of an voorbeeld Gebeurtenis A1 met hysteresis proef geval in stuksgewijs
configuratie toont het effect van hysteresis in een ander voorbeeld van de Event A1-test.
[afbeelding] Gemeten RSRP-trace van een voorbeeldgebeurtenis A1 met hysteresistestgeval in
stuksgewijs configuratie.UNINDENT

Stuksgewijze configuratie wordt gebruikt in twee testreeksen van UE-metingen. De eerste is
Lte-ue-metingen-stuksgewijs-1, voortaan Piecewise test #1, die 1 UE en simuleert
1 eNodeB. De andere wel Lte-ue-metingen-stuksgewijs-2, die 1 UE en 2 eNodeB's heeft
in de simulatie.

Stuksgewijze test #1 is bedoeld om de op gebeurtenissen gebaseerde criteria te testen die niet afhankelijk zijn
over het bestaan ​​van een naburige cel. Deze criteria omvatten gebeurtenis A1 en A2. De
andere evenementen worden ook kort getest om te verifiëren dat ze nog steeds correct werken
(hoewel er niets wordt gerapporteerd) bij afwezigheid van een naburige cel. Tafel UE
maten proef scenario's gebruik stuksgewijs configuratie #1 Hieronder staan ​​de scenario's vermeld
getest in stuksgewijs test #1.

UE maten proef scenario's gebruik stuksgewijs configuratie #1
┌───────┬───────────┬──────────────────┬─ ───────── ──┬─────────────────┐
│Testnr. │ Rapportage │ Drempel/offset │ Hysteresis │ Tijd tot trigger │
│ │ Criteria │ │ │ │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│1 │ Gebeurtenis A1 │ Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│2 │ Gebeurtenis A1 │ Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│3 │ Gebeurtenis A1 │ Normaal │ Nee │ Kort │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│4 │ Gebeurtenis A1 │ Normaal │ Nee │ Lang │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│5 │ Gebeurtenis A1 │ Normaal │ Nee │ Super │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│6 │ Gebeurtenis A1 │ Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│7 │ Gebeurtenis A1 │ Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│8 │ Gebeurtenis A2 │ Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│9 │ Gebeurtenis A2 │ Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│10 │ Gebeurtenis A2 │ Normaal │ Nee │ Kort │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│11 │ Gebeurtenis A2 │ Normaal │ Nee │ Lang │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│12 │ Gebeurtenis A2 │ Normaal │ Nee │ Super │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│13 │ Gebeurtenis A2 │ Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│14 │ Gebeurtenis A2 │ Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│15 │ Gebeurtenis A3 │ Nul │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│16 │ Gebeurtenis A4 │ Normaal │ Nee │ Nee │
└───────┴───────────┴──────────────────┴─ ───────── ──┴─────────────────┘

│17 │ Gebeurtenis A5 │ Normaal-Normaal │ Nee │ Nee │
└───────┴───────────┴──────────────────┴─ ───────── ──┴─────────────────┘

Andere gebeurtenissen, zoals gebeurtenis A3, A4 en A5, zijn dus afhankelijk van metingen van de aangrenzende cel
ze worden grondiger getest in Piecewise-test #2. De simulatie plaatst de knooppunten op a
rechte lijn en instrueer de UE om dat te doen "springen" op een vergelijkbare manier als in Piecewise-test nr. 1.
Overdracht is uitgeschakeld in de simulatie, dus de rol van bedienende en aangrenzende cellen is dat ook
niet schakelen tijdens de simulatie. Tafel UE maten proef scenario's gebruik stuksgewijs
configuratie #2 Hieronder staan ​​de scenario's vermeld die zijn getest in Piecewise-test #2.

UE maten proef scenario's gebruik stuksgewijs configuratie #2
┌───────┬───────────┬──────────────────┬─ ───────── ──┬─────────────────┐
│Testnr. │ Rapportage │ Drempel/offset │ Hysteresis │ Tijd tot trigger │
│ │ Criteria │ │ │ │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│1 │ Gebeurtenis A1 │ Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│2 │ Gebeurtenis A1 │ Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│3 │ Gebeurtenis A1 │ Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│4 │ Gebeurtenis A1 │ Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│5 │ Gebeurtenis A2 │ Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│6 │ Gebeurtenis A2 │ Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│7 │ Gebeurtenis A2 │ Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│8 │ Gebeurtenis A2 │ Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│9 │ Gebeurtenis A3 │ Positief │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│10 │ Gebeurtenis A3 │ Nul │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│11 │ Gebeurtenis A3 │ Nul │ Nee │ Kort │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│12 │ Gebeurtenis A3 │ Nul │ Nee │ Super │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│13 │ Gebeurtenis A3 │ Nul │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│14 │ Gebeurtenis A3 │ Negatief │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│15 │ Gebeurtenis A4 │ Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│16 │ Gebeurtenis A4 │ Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│17 │ Gebeurtenis A4 │ Normaal │ Nee │ Kort │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│18 │ Gebeurtenis A4 │ Normaal │ Nee │ Super │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│19 │ Gebeurtenis A4 │ Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│20 │ Gebeurtenis A4 │ Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│21 │ Gebeurtenis A5 │ Laag-Laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│22 │ Gebeurtenis A5 │ Laag-Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│23 │ Gebeurtenis A5 │ Laag-Hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│24 │ Gebeurtenis A5 │ Normaal-laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│25 │ Gebeurtenis A5 │ Normaal-Normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│26 │ Gebeurtenis A5 │ Normaal-Normaal │ Nee │ Kort │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│27 │ Gebeurtenis A5 │ Normaal-Normaal │ Nee │ Super │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│28 │ Gebeurtenis A5 │ Normaal-Normaal │ Ja │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│29 │ Gebeurtenis A5 │ Normaal-hoog │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│30 │ Gebeurtenis A5 │ Hoog-laag │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│31 │ Gebeurtenis A5 │ Hoog-normaal │ Nee │ Nee │
├───────┼───────────┼──────────────────┼─ ───────── ──┼─────────────────┤
│32 │ Gebeurtenis A5 │ Hoog-Hoog │ Nee │ Nee │
└───────┴───────────┴──────────────────┴─ ───────── ──┴─────────────────┘

Een opmerking over de tests met time-to-trigger, ze worden getest met 3 verschillende waarden van
tijd tot trigger: kort (korter dan rapportinterval), lang (korter dan het filter
meetperiode van 200 ms), en super (langer dan 200 ms). De eerste twee zorgen daarvoor
time-to-trigger evaluatie gebruik altijd de meest recente meetrapporten ontvangen van PHY
laag. Terwijl de laatste verantwoordelijk is voor het verifiëren van de annulering van de time-to-trigger, voor
bijvoorbeeld wanneer uit een meetrapport van PHY blijkt dat de in-/uitstapconditie nee is
langer waar voordat de eerste trigger wordt afgevuurd.

Overhandigen configuratie
Het doel van de overdrachtsconfiguratie is om te verifiëren of er een UE-meting is
configuratie wordt correct bijgewerkt nadat een succesvolle overdracht heeft plaatsgevonden. Voor deze
Voor dit doel zal de simulatie 2 eNodeB's construeren met verschillende UE-metingen
configuratie, en de UE zal overdracht van de ene cel naar de andere uitvoeren. De EU zal dat zijn
zich op een rechte lijn tussen de 2 eNodeB's bevindt, en de overdracht zal worden aangeroepen
handmatig. De duur van elke simulatie is 2 seconden (behalve het laatste testgeval) en de
de overdracht wordt precies halverwege de simulatie geactiveerd.

De Lte-ue-metingen-overdracht testsuite omvat verschillende soorten configuraties
verschillen. De eerste is het verschil in rapportinterval, bijvoorbeeld de eerste eNodeB
geconfigureerd met een rapportinterval van 480 ms, terwijl de tweede eNodeB is geconfigureerd met 240 ms
rapportinterval. Daarom, toen de UE overdracht naar de tweede cel uitvoerde, werd de new
rapportinterval moet van kracht worden. Net als bij de stuksgewijs configuratie, zijn de timing en de
De inhoud van elk door de eNodeB ontvangen meetrapport wordt geverifieerd.

Andere typen verschillen die in de testsuite aan de orde komen, zijn verschillen in gebeurtenis en
verschillen in drempel/offset. Tafel UE maten proef scenario's gebruik overhandigen
configuratie hieronder vindt u de geteste scenario's.

UE maten proef scenario's gebruik overhandigen configuratie
──────────────────────────────────────── ────────── ──────────────────────
Test # Testonderwerp Eerste post-overdracht
Configuratie Configuratie
──────────────────────────────────────── ────────── ──────────────────────
1 Rapportinterval 480 ms 240 ms
──────────────────────────────────────── ────────── ──────────────────────
2 Rapportinterval 120 ms 640 ms
──────────────────────────────────────── ────────── ──────────────────────
3 Gebeurtenis Gebeurtenis A1 Gebeurtenis A2
──────────────────────────────────────── ────────── ──────────────────────
4 Gebeurtenis Gebeurtenis A2 Gebeurtenis A1
──────────────────────────────────────── ────────── ──────────────────────
5 Gebeurtenis Gebeurtenis A3 Gebeurtenis A4
──────────────────────────────────────── ────────── ──────────────────────
6 Gebeurtenis Gebeurtenis A4 Gebeurtenis A3
──────────────────────────────────────── ────────── ──────────────────────
7 Gebeurtenis Gebeurtenis A2 Gebeurtenis A3
──────────────────────────────────────── ────────── ──────────────────────
8 Gebeurtenis Gebeurtenis A3 Gebeurtenis A2
──────────────────────────────────────── ────────── ──────────────────────
9 Gebeurtenis Gebeurtenis A4 Gebeurtenis A5
──────────────────────────────────────── ────────── ──────────────────────
10 Gebeurtenis Gebeurtenis A5 Gebeurtenis A4
──────────────────────────────────────── ────────── ──────────────────────
11 Drempel/offset RSRP-bereik 52 RSRP-bereik 56
(Gebeurtenis A1) (Gebeurtenis A1)
──────────────────────────────────────── ────────── ──────────────────────
12 Drempel/offset RSRP-bereik 52 RSRP-bereik 56
(Gebeurtenis A2) (Gebeurtenis A2)
──────────────────────────────────────── ────────── ──────────────────────
13 Drempel/offset A3-offset -30 A3-offset +30
(Gebeurtenis A3) (Gebeurtenis A3)
──────────────────────────────────────── ────────── ──────────────────────
14 Drempel/offset RSRP-bereik 52 RSRP-bereik 56
(Gebeurtenis A4) (Gebeurtenis A4)
──────────────────────────────────────── ────────── ──────────────────────
15 Drempel/offset RSRP-bereik 52-52 RSRP-bereik 56-56
(Gebeurtenis A5) (Gebeurtenis A5)
──────────────────────────────────────── ────────── ──────────────────────
16 Tijd tot trigger 1024 ms 100 ms
──────────────────────────────────────── ────────── ──────────────────────
17 Tijd tot trigger 1024 ms 640 ms
┌───────┬──────────────────┬───────────── ────────┬ ─────────────────────┐
│ │ │ │ │
Binair bestand (standaardinvoer) komt overeen

Gebruik de ns-3-modelbibliotheek online met behulp van onworks.net-services