ns-3-model-library - Bulutta Çevrimiçi

Program:

ADI

ns-3-model kitaplığı - ns-3 Model Kitaplığı

Bu ns-3 Model Kütüphane belgeler. ns-3 projesi için birincil belgeler
beş biçimde mevcuttur:

· ns-3 Doxygen: Simülatörün genel API'lerinin dokümantasyonu

· Eğitim, Kılavuz ve Model Kitaplığı (bu belge) için son serbest ve
geliştirme ağaç

· ns-3 wiki

Bu belgede yazılı reStructuredText için Sfenks ve içinde tutulur
belge/modeller ns-3'ün kaynak kodunun dizini.

ORGANİZASYON

Bu kılavuz, aşağıdakiler için belgeleri derler: ns-3 sağlayan modeller ve destekleyici yazılımlar
kullanıcıların ağ simülasyonları oluşturmasını sağlar. arasında ayrım yapmak önemlidir modüller
ve modelleri:

· ns-3 yazılım ayrı olarak düzenlenmiştir modüller her biri ayrı olarak inşa edilmiş
yazılım kitaplığı. Bireysel ns-3 programları, ihtiyaç duydukları modülleri (kütüphaneleri) bağlayabilir
simülasyonlarını yürütmek.

· ns-3 modelleri gerçek dünyadaki nesnelerin, protokollerin, cihazların vb. soyut temsilleridir.

An ns-3 modül birden fazla modelden oluşabilir (örneğin, Internet modül
hem TCP hem de UDP için modeller içerir). Genel olarak, ns-3 modelleri birden fazla alana yayılmaz.
Ancak yazılım modülleri.

Bu kılavuz, aşağıdakilerin modelleri hakkında belgeler sağlar: ns-3. Diğer iki tamamlayıcı
modellerle ilgili dokümantasyon kaynakları:

· Model API'leri, programlama perspektifinden aşağıdakiler kullanılarak belgelenmiştir: Doxygen. doksijen
ns-3 modelleri için mevcuttur on the proje ağ sunucu.

· NS ns-3 çekirdek geliştirici kılavuzunda belgelenmiştir. ns-3 modeller kullanır
öznitelikler, varsayılan değerler, rastgele sayılar, test gibi çekirdeğin olanakları
çerçeveler, vb. ana ağ yer Kılavuzun kopyalarını bulmak için

Son olarak, çeşitli yönleri hakkında ek belgeler ns-3 üzerinde var olabilir proje
wiki.

Model kitaplığı belgelerinin nasıl yazılacağına dair örnek bir taslak, aşağıdaki komut yürütülerek bulunabilir:
modül oluştur.py program ve dosyada oluşturulan şablona bakarak
yeni-modül/belge/yeni-modül.rst.

$ cd kaynağı
$ ./create-module.py yeni modül

Bu belgenin geri kalanı modül adına göre alfabetik olarak düzenlenmiştir.

Eğer yeni iseniz ns-3, öncelikle aşağıdaki ağ modülü hakkında bilgi almak isteyebilirsiniz.
simülatör için bazı temel modeller içerir. Paket modeli, modeller
düğümler, net gibi nesneler için farklı adres biçimleri ve soyut temel sınıflar
cihazlar, kanallar, prizler ve uygulamalar burada tartışılmaktadır.

ANİMASYON

Animasyon, ağ simülasyonu için önemli bir araçtır. Sırasında ns-3 içermez
varsayılan grafik animasyon aracı, şu anda animasyon sağlamanın iki yolu var, yani
PyViz yöntemini veya NetAnim yöntemini kullanarak. PyViz yöntemi şurada açıklanmıştır:
http://www.nsnam.org/wiki/PyViz.

NetAnim yöntemini burada kısaca anlatacağız.

NetAnim
NetAnim, oluşturulan bir izleme dosyasını kullanan bağımsız, Qt4 tabanlı bir yazılım yürütülebilir dosyasıdır.
sırasında ns-3 topolojiyi görüntülemek ve paket akışını canlandırmak için simülasyon
düğümleri.
[image] Kablolu bağlantılarda paket animasyonu örneği.UNINDENT

Ayrıca NetAnim, meta verileri görüntülemek için tablolar gibi kullanışlı özellikler de sağlar.
Aşağıdaki resimdeki gibi paketlerin
[image] Protokol filtreleriyle paket meta verileri için bir tablo örneği.UNINDENT

Bir mobil düğümün yörüngesini görselleştirmenin bir yolu
[image] Bir mobil düğümün yörüngesine bir örnek.UNINDENT

Zamanın çeşitli noktalarında birden çok düğümün yönlendirme tablolarını görüntülemenin bir yolu
[resim]

Birden çok düğümle ilişkili sayaçları grafik veya tablo olarak görüntülemenin bir yolu
[resim]
[resim]

Paket gönderme ve alma olaylarının zaman çizelgesini görüntülemenin bir yolu
[resim]

metodoloji
ns3::AnimationInterface sınıfı, izleme XML dosyasının oluşturulmasından sorumludur.
AnimationInterface, düğümler arasındaki paket akışlarını izlemek için izleme altyapısını kullanır.
AnimationInterface, kendisini tx ve rx olayları için bir izleme kancası olarak kaydeder.
simülasyon başlar. Bir paket iletim veya alım için programlandığında,
AnimationInterface'de karşılık gelen tx ve rx izleme kancaları çağrılır. rx kancaya takıldığında
çağrılırsa, AnimationInterface bir paketin aralarında bulunduğu iki uç noktanın farkında olacaktır.
aktı ve bu bilgiyi izleme dosyasına XML formatında ekler.
karşılık gelen tx ve rx zaman damgaları. XML formatı daha sonraki bir bölümde tartışılacaktır.
AnimationInterface'in bir paketi yalnızca rx izlemesi varsa kaydettiğini unutmamak önemlidir.
kancalar denir. Her tx olayı bir rx olayı ile eşleştirilmelidir.

İndirilmesi NetAnim
NetAnim halihazırda mevcut değilse, ns-3 indirdiğiniz paketi, yapabilirsiniz
Aşağıdaki:

Lütfen Mercurial'ı yüklediğinizden emin olun. NetAnim'in en son sürümü şu şekilde olabilir:
aşağıdaki komutla mercurial kullanılarak indirildi:

$ hg klonu http://code.nsnam.org/netanim

bina NetAnim
Önkoşullar
NetAnim'i oluşturmak için Qt4 (4.7 ve üzeri) gereklidir. Bu, aşağıdakiler kullanılarak elde edilebilir
yollar:

Debian/Ubuntu Linux dağıtımları için:

$ apt-get qt4-dev-tools'u kurun

Red Hat/Fedora tabanlı dağıtım için:

$ yum qt4 yükleyin
$ yum yükleme qt4-devel

Mac/OSX için bkz. http://qt.nokia.com/downloads/

İnşa etmek adımlar
NetAnim'i oluşturmak için aşağıdaki komutları kullanın:

$ cd netanım
$ temizlemek
$ qmake NetAnim.pro (MAC Kullanıcıları için: qmake -spec macx-g++ NetAnim.pro)
Yap $

Not: qmake, bazı sistemlerde "qmake-qt4" olabilir

Bu, aynı dizinde "NetAnim" adlı bir yürütülebilir dosya oluşturmalıdır:

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

kullanım
NetAnim'i kullanmak iki adımlı bir işlemdir

Adım 1: Simülasyon sırasında kullanarak animasyon XML izleme dosyasını oluşturun
"ns3::AnimationInterface" ns-3 kod tabanı.

Adım 2: Çevrimdışı Qt1 tabanlı animatör ile Adım 4'de oluşturulan XML izleme dosyasını yükleyin
NetAnim adında.

adım 1: Oluşturmak XML animasyon iz dosya
"Src/netanim" altındaki "AnimationInterface" sınıfı, temel ns-3 kaynakları izlemek
XML biçiminde zaman damgalı bir ASCII dosyası oluşturun.

Örnekler src/netanim/examples altında bulunur Örnek:

$ ./waf -d hata ayıklama yapılandırma --enable-examples
$ ./waf -- "dambıl animasyonunu" çalıştır

Yukarıdakiler bir XML dosyası dambıl-animation.xml oluşturacaktır.

Zorunlu
1. Programınızın wscript'inin "netanim" modülünü içerdiğinden emin olun. Böyle bir örnek
wscript, src/netanim/examples/wscript konumunda.

2. Test programınıza [#include "ns3/netanim-module.h"] başlığını ekleyin

3. İfadeyi ekleyin

AnimationInterface animasyonu ("animation.xml"); // burada "animation.xml" herhangi bir rastgele dosya adıdır

[ns-3.13'ten önceki sürümler için ayrıca "anim.SetXMLOutput()" satırını kullanmanız gerekir.
XML modu ve ayrıca anim.StartAnimation();] kullanın

İsteğe bağlı
Aşağıdakiler isteğe bağlı ancak faydalı adımlardır:

// Aşama 1
anim.SetMobilityPollInterval (Saniye (1));

AnimationInterface, varsayılan olarak her 250 ms'de bir tüm düğümlerin konumunu kaydeder. bu
yukarıdaki ifade, AnimationInterface'in verileri kaydettiği periyodik aralığı belirler.
tüm düğümlerin konumu. Düğümlerin çok az hareket etmesi bekleniyorsa,
büyük XML dosyalarından kaçınmak için yüksek mobilite anket aralığı.

// Aşama 2
anim.SetConstantPosition (Ptr< Node > n, double x, double y);

AnimationInterface, tüm düğümlerin konumunun ayarlanmasını gerektirir. İçinde ns-3 bu tarafından yapılır
ilişkili bir MobilityModel ayarlama. "SetConstantPosition", xy'yi ayarlamanın hızlı bir yoludur
Durağan bir düğümün koordinatları.

// Aşama 3
animasyon.SetStartTime (saniye(150)); ve anim.SetStopTime (saniye(150));

AnimationInterface, büyük XML dosyaları oluşturabilir. Yukarıdaki ifadeler pencereyi kısıtlar
AnimationInterface'in izleme yaptığı arasında. Pencereyi kısıtlamak yalnızca odaklanmaya yarar
simülasyonun ilgili bölümlerinde ve yönetilebilir şekilde küçük XML dosyaları oluşturmada

// Aşama 4
AnimationInterface animasyonu ("animation.xml", 50000);

Yukarıdaki oluşturucuyu kullanmak, her animasyon XML izleme dosyasının yalnızca 50000'e sahip olmasını sağlar.
paketler. Örneğin, AnimationInterface yukarıdakileri kullanarak 150000 paket yakalarsa
yapıcı yakalamayı 3 dosyaya böler

· animasyon.xml - 1-50000 paket aralığını içerir

· animasyon.xml-1 - 50001-100000 paket aralığını içerir

· animasyon.xml-2 - 100001-150000 paket aralığını içerir

// Aşama 5
anim.EnablePacketMetadata (doğru);

Yukarıdaki ifadeyle, AnimationInterface, her paketin meta verilerini,
xml izleme dosyası. Metadata, NetAnim tarafından daha iyi istatistik ve filtre sağlamak için kullanılabilir,
TCP sıra numarası gibi paket hakkında bazı kısa bilgiler sağlamanın yanı sıra
veya paket animasyonu sırasında kaynak ve hedef IP adresi.

DİKKAT: Bu özelliğin etkinleştirilmesi, daha büyük XML izleme dosyalarına neden olur. Lütfen yapma
Wimax bağlantılarını kullanırken bu özelliği etkinleştirin.

// Aşama 6
anim.UpdateNodeDescription (5, "Erişim noktası");

Yukarıdaki ifadeyle, AnimationInterface "Erişim noktası" metnini düğüm 5'e atar.

// Aşama 7
anim.UpdateNodeSize (6, 1.5, 1.5);

Yukarıdaki ifadeyle, AnimationInterface, düğüm boyutunu 1.5 ile ölçeklenecek şekilde ayarlar. NetAnim
grafik görünümünü topolojinin sınırlarına uyacak şekilde otomatik olarak ölçeklendirir. Bunun anlamı
NetAnim, bir düğümün boyutunu anormal şekilde çok yüksek veya çok düşük ölçekleyebilir. kullanma
AnimationInterface::UpdateNodeSize, NetAnim'deki varsayılan ölçeklemenin üzerine yazmanıza olanak tanır
ve kendi özel ölçeğinizi kullanın.

// Aşama 8
anim.UpdateNodeCounter (89, 7, 3.4);

Yukarıdaki ifadeyle, AnimationInterface, sayacı Id == 89 ile ilişkili olarak ayarlar.
7 değerine sahip Düğüm 3.4 ile. Id 89 olan sayaç kullanılarak elde edilir
AnimationInterface::AddNodeCounter. Bunun için örnek bir kullanım
src/netanim/examples/resources_demo.cc.

adım 2: yükleme the XML in NetAnim
1. NetAnim'in oluşturulduğunu varsayarak, NetAnim'i başlatmak için "./NetAnim" komutunu kullanın. Lütfen
NetAnim mevcut değilse "NetAnim Oluşturma" bölümünü inceleyin.

2. NetAnim açıldığında, sol üst köşedeki Dosya aç düğmesine tıklayın,
Adım 1 sırasında oluşturulan XML dosyası.

3. Animasyonu başlatmak için yeşil oynat düğmesine basın.

İşte bunu gösteren bir video http://www.youtube.com/watch?v=tz_hUuNwFD'ler

wiki
"NetAnim" kurulumuna ilişkin ayrıntılı talimatlar, SSS'ler ve XML izleme dosyasının yüklenmesi için
(daha önce bahsedilen) NetAnim kullanarak lütfen aşağıdakilere bakın: http://www.nsnam.org/wiki/NetAnim

ANTEN MODÜL

Tasarım belgeleme
Genel Bakış
Anten modülü şunları sağlar:

1. Modelleme için bir arayüz sağlayan yeni bir temel sınıf (AntennaModel).
bir antenin radyasyon modeli;

2. her biri radyasyon modelini modelleyen bu temel sınıftan türetilen bir sınıflar kümesi
farklı anten türleri.

AntenModeli
Anten Modeli, [Balanis]'te benimsenen ve Şekil'de gösterilen koordinat sistemini kullanır.
Koordinat sistem of the AntenModeli. Bu sistem kartezyenin çevrilmesiyle elde edilir.
ns-3 MobilityModel tarafından kullanılan yeni orijine o koordinat sistemi
antenin konumu ve ardından her genel p noktasının koordinatlarının dönüştürülmesi
kartezyen koordinatlardan (x,y,z) küresel koordinatlara (r, heta,hi) uzay.
Anten modeli, radyal bileşen r'yi ihmal eder ve yalnızca açı bileşenlerini dikkate alır.
(heta, merhaba).
Bir anten radyasyon modeli daha sonra matematiksel bir fonksiyon g(heta, hi) olarak ifade edilir.
olası her yön için kazancı (dB cinsinden) döndüren grrightarrow thcal{R}
iletim/alım. Tüm açılar radyan cinsinden ifade edilir.
[image] AntennaModel.UNINDENT'in koordinat sistemi

Sağlanan modelleri
Bu bölümde, içinde yer alan anten radyasyon modeli modellerini açıklıyoruz.
anten modülü.

İzotropikAntenModel
Bu anten radyasyon modeli modeli, tüm yönler için üniter bir kazanç (0 dB) sağlar.

KosinüsAntenModel
Bu [Chunjian]'da açıklanan kosinüs modelidir: anten kazancı şu şekilde belirlenir:

selam_{0}
antenin azimut yönüdür (yani, maksimum kazanç yönü) ve
üstel

istenen 3dB ışın genişliğini hi_{3dB} belirler.
Bu radyasyon modelinin eğim açısı heta'dan bağımsız olduğuna dikkat edin.

[Chunjian] modeli ile sınıfta uygulanan model arasındaki büyük fark
CosineAntennaModel, yalnızca eleman faktörünün (yani, yukarıda açıklananlar) olmasıdır.
formüller) dikkate alınır. Aslında, [Chunjian] ayrıca ek bir anten dizisini de düşündü.
faktör İkincisinin hariç tutulmasının nedeni, ortalama kullanıcının
bir dizi faktörü eklemeden belirli bir ışın genişliğini tam olarak belirtmek isteyecektir.
pratikte sonucun etkin ışın genişliğini değiştirecek olan ikinci aşama
radyasyon deseni.

ParabolikAntenModeli
Bu model, ana lob radyasyon modelinin parabolik yaklaşımına dayanmaktadır. o
genellikle bir hücrenin radyasyon modelini modellemek için hücresel sistem bağlamında kullanılır
sektör, örneğin [R4-092042a] ve [Calcev]'e bakın. dB cinsinden anten kazancı belirlenir
olarak:

selam_{0}
antenin azimut yönüdür (yani, maksimum kazanç yönü),
merhaba_{3dB}
3 dB ışın genişliğidir ve A_{max} antenin dB cinsinden maksimum zayıflamasıdır. Not
bu radyasyon modeli, eğim açısı heta'dan bağımsızdır.

[Balanis]
CA Balanis, "Anten Teorisi - Analiz ve Tasarım", Wiley, 2. Baskı.

[Çunjian]
Li Chunjian, "Üç Sektörlü WCDMA Sistemleri için Verimli Anten Modelleri", Master of
Bilim Tezi, Chalmers Teknoloji Üniversitesi, Göteborg, İsveç, 2003

[Kalev]
George Calcev ve Matt Dillon, "CDMA Ağlarında Anten Eğim Kontrolü", Proc. nın-nin
2. Yıllık Uluslararası Kablosuz İnternet Konferansı (WICON), 2006

[R4-092042a]
3GPP TSG RAN WG4 (Radyo) Toplantı #51, R4-092042, Simülasyon varsayımları ve
FDD HeNB RF gereksinimleri için parametreler.

kullanıcı Dökümanlar
Modüle edilen anten, tüm kablosuz teknolojiler ve fiziksel katman ile kullanılabilir.
destekleyen modellerdir. Şu anda bu, fiziksel katman modellerini içerir.
SpectrumPhy. Ayrıntılar için lütfen bu modellerin her birinin belgelerine bakın.

Test yapmak Dökümanlar
Bu bölümde, doğrulayan anten modülüyle birlikte verilen test takımlarını açıklıyoruz.
onun doğru işlevselliği.

Açılar
birim test paketi açıları Angles sınıfının doğru şekilde oluşturulduğunu doğrular.
3B kartezyen koordinatlardan mevcut yöntemlere göre doğru dönüştürme
(tek bir vektörden ve bir çift vektörden yapı). Her yöntem için birkaç
değerleri karşılaştıran test durumları sağlanır (merhaba,
heta) kurucu tarafından bilinen referans değerlere göre belirlenir. Her biri için test geçerse
değerlerin 10^{-10} toleransa kadar referansa eşit olması durumunda
sayısal hatalar için

DerecelerToRadyanlar
birim test paketi derece-radyan yöntemlerin doğrulandığını doğrular. DerecelerToRadyanlar ve
RadyanlarToDereceler bir dizi bilinen referans değerlerle karşılaştırarak düzgün çalışın
test vakaları. Karşılaştırma 10^{-10} toleransa eşitse her test durumu başarılı olur
hangi sayısal hataları açıklar.

İzotropikAntenModel
birim test paketi izotropik-anten-modeli olup olmadığını kontrol eder İzotropikAntenModel sınıf
düzgün çalışır, yani yönden bağımsız olarak her zaman 0dB kazanç verir.

KosinüsAntenModel
birim test paketi kosinüs-anten-modeli olup olmadığını kontrol eder KosinüsAntenModel sınıf çalışmaları
düzgün bir şekilde. Hesaplanan anten kazanç değerini kontrol eden birkaç test durumu sağlanmıştır.
farklı yönlerde ve oryantasyonun farklı değerleri için referans kazancı
ve ışın genişliği. Referans kazancı elle hesaplanır. Her test durumu, aşağıdaki durumlarda geçer:
dB cinsinden referans kazancı, tarafından döndürülen değere eşittir KosinüsAntenModel bir içeri
0.001 toleransı, hesaplama için yapılan yaklaşıklığı hesaba katar.
referans değerleri.

ParabolikAntenModeli
birim test paketi parabolik-anten-modeli olup olmadığını kontrol eder ParabolikAntenModeli sınıf
düzgün çalışır. Anten kazanç değerini kontrol eden birkaç test durumu sağlanmıştır
farklı yönlerde ve oryantasyonun farklı değerleri için hesaplanan
maksimum zayıflama ve ışın genişliği. Referans kazancı elle hesaplanır. Her test
dB cinsinden referans kazancı tarafından döndürülen değere eşitse durum geçer.
ParabolikAntenModeli yaklaşık olarak hesaplanan 0.001'lik bir tolerans dahilinde
referans değerlerinin hesaplanması için yapılır.

AD HOC TALEP ÜZERİNE MESAFE VEKTÖR (AODV)

Bu model, Ad Hoc İsteğe Bağlı Mesafe Vektörünün temel belirtimini uygular
(AODV) protokolü. Uygulamaya dayanmaktadır RFC 3561.

Model, ITTP RAS'tan Elena Buchatskaia ve Pavel Boyko tarafından yazılmıştır ve temel alınmıştır.
CMU/MONARCH grubu tarafından geliştirilen ve Samir tarafından optimize edilen ve ayarlanan ns-2 AODV modeli
Das ve Mahesh Marina, Cincinnati Üniversitesi ve ayrıca AODV-UU uygulaması hakkında
Uppsala Üniversitesi'nden Erik Nordström.

Model Tanım
AODV modelinin kaynak kodu dizinde bulunur kaynak/aodv.

Tasarım
Sınıf ns3::aodv::Yönlendirme Protokolü hizmet paketi değişiminin tüm işlevlerini uygular
ve miras alır ns3::Ipv4Yönlendirme Protokolü. Temel sınıf iki sanal işlevi tanımlar
paket yönlendirme ve iletme için. İlki, ns3::aodv::RotaÇıkışı, için kullanılır
yerel kaynaklı paketler ve ikincisi, ns3::aodv::RouteInput, için kullanılır
alınan paketleri iletmek ve/veya teslim etmek.

Protokol işlemi birçok ayarlanabilir parametreye bağlıdır. Bunun için parametreler
işlevsellik özellikleridir ns3::aodv::Yönlendirme Protokolü. Parametre varsayılan değerleri
RFC'den alınır ve aşağıdaki gibi etkinleştirme/devre dışı bırakma protokol özelliklerine izin verir:
HELLO mesajlarının yayınlanması, veri paketlerinin yayınlanması vb.

AODV talep üzerine rotaları keşfeder. Bu nedenle, AODV modeli tüm paketleri arabelleğe alırken, bir
rota istek paketi (RREQ) dağıtılır. Bir paket kuyruğu uygulanır
aodv-rqueue.cc. Pakete akıllı bir işaretçi, ns3::Ipv4RoutingProtocol::ErrorCallback,
ns3::Ipv4RoutingProtocol::UnicastForwardCallback, ve IP başlığı bu dosyada saklanır.
sıra. Paket kuyruğu, eski paketlerin çöp toplamasını ve bir kuyruk boyutunu uygular.
sınırı.

Yönlendirme tablosu uygulaması, eski girdilerin ve durumun çöp toplamasını destekler
standartta tanımlanan makine. STL harita kapsayıcısı olarak uygulanır. Anahtar bir
hedef IP adresi.

Protokol işleminin bazı öğeleri RFC'de açıklanmamıştır. Bu unsurlar genel olarak
farklı OSI model katmanlarının işbirliği ile ilgilidir. Model aşağıdakileri kullanır
Sezgisel:

· Bu AODV uygulaması, tek yönlü bağlantıların varlığını algılayabilir ve bunlardan kaçınabilir
Eğer gerekliyse. Modelin RREQ aldığı düğüm bir komşu ise, neden
tek yönlü bir bağlantı olsun. Bu buluşsal yöntem AODV-UU uygulamasından alınmıştır ve
devre dışı bırakılmalıdır.

· Protokolün çalışması büyük ölçüde kopuk bağlantı algılama mekanizmasına bağlıdır. model
bu tür iki buluşsal yöntemi uygular. İlk olarak, bu uygulama HELLO mesajlarını destekler.
Ancak HELLO mesajları, bir kablosuz ağda komşu algılamayı gerçekleştirmenin iyi bir yolu değildir.
ortam (en azından 802.11 üzerinden değil). Bu nedenle, kişi kötü performans yaşayabilir
kablosuz üzerinden çalışırken. Bunun birkaç nedeni vardır: 1) HELLO mesajları
yayınlandı. 802.11'de yayın, genellikle tek noktaya yayından daha düşük bir bit hızında yapılır.
bu nedenle HELLO mesajları tek noktaya yayın verilerinden daha uzağa gidebilir. 2) MERHABA mesajları küçüktür,
bu nedenle veri aktarımlarından daha az bit hatalarına eğilimlidir ve 3) Yayın aktarımları
tek noktaya yayın iletimlerinden farklı olarak çift yönlü olmaları garanti edilmez. İkincisi, kullandığımız
mümkün olduğunda katman 2 geri bildirimi. Çerçeve iletimi durumunda bağlantının kopmuş olduğu kabul edilir.
tüm yeniden denemeler için bir iletim hatasıyla sonuçlanır. Bu mekanizma, aktif
bağlantılar ve ilk yöntemden daha hızlı çalışır.

2. katman geri bildirim uygulaması, TxErrBaşlığı izleme kaynağı, şu anda
yalnızca AdhocWifiMac'te desteklenir.

kapsam ve Sınırlamalar
Model yalnızca IPv4 içindir. Aşağıdaki isteğe bağlı protokol optimizasyonları,
uygulandı:

1. Genişleyen halka arama.

2. Yerel bağlantı onarımı.

3. RREP, RREQ ve HELLO mesaj uzantıları.

Bu teknikler, IP başlığına doğrudan erişim gerektirir, bu da şu iddiayla çelişir:
AODV'nin UDP üzerinden çalıştığı AODV RFC. Bu model, basitlik için UDP kullanır ve
belirli protokol optimizasyonlarını uygulama yeteneği. Model düşük katman ham kullanmıyor
taşınabilir olmadıkları için prizler.

gelecek İş
Açıklanmış bir plan yok.

Referanslar
kullanım
Örnekler
Yardımcılar
Özellikler
İzleme
Günlüğü
Uyarılar
Onaylama
birim testleri
Daha büyük ölçekli performans testleri

UYGULAMALAR

Yer Tutucu bölüm

KÖPRÜ NET CİHAZI

Yer Tutucu bölüm

Bridge NetDevice kullanımına ilişkin bazı örnekler şurada bulunabilir: örnekler/csma/ dizin.

BRİT ENTEGRASYON

Bu model, Boston Üniversitesi Temsilcisi İnterneti olan BRITE'a bir arayüz uygular.
Topoloji Oluşturucu [1]. BRITE, gerçekçi internet oluşturmak için standart bir araçtır
topolojiler. Burada açıklanan ns-3 modeli, kolaylaştırmak için bir yardımcı sınıf sağlar.
BRITE yapılandırma dosyalarını kullanarak ns-3'e özgü topolojiler oluşturma. BRITE,
ns-3 BriteTopolgyHelper sınıfında düğümler ve kenarlar olarak depolanan orijinal grafik. İçinde
BRITE'ın ns-3 entegrasyonu, jeneratör bir topoloji oluşturur ve ardından erişim sağlar
oluşturulan her AS için yaprak düğümlerine. ns-3 kullanıcıları, daha fazla özel topolojiler ekleyebilir
bu yaprak düğümleri ya manuel olarak oluşturarak ya da içinde sağlanan topoloji üreteçlerini kullanarak
ns-3.

BRITE'ta kullanılabilen üç ana topoloji türü vardır: Yönlendirici, AS ve
AS ve Router'ın bir kombinasyonu olan hiyerarşik. ns-3 amaçları için
simülasyon, en kullanışlı olanı muhtemelen Yönlendirici ve Hiyerarşiktir. Yönlendirici seviyesi
Waxman modeli veya Barabasi-Albert modeli kullanılarak topolojiler oluşturulabilir. Her biri
model, topoloji oluşturmayı etkileyen farklı parametrelere sahiptir. Düz yönlendirici topolojileri için,
tüm düğümler aynı AS'de kabul edilir.

BRITE Hiyerarşik topolojiler iki seviye içerir. Birincisi AS seviyesidir. Bu seviye
Waxman modeli veya Barabasi-Albert modeli kullanılarak da oluşturulabilir.
Daha sonra AS topolojisindeki her düğüm için yönlendirici düzeyinde bir topoloji oluşturulur. Bunlar
yönlendirici düzeyinde topolojiler, yine Waxman modelini veya Barbasi-Albert modelini kullanabilir.
BRITE, AS seviyesi tarafından belirtilen bu ayrı yönlendirici topolojilerini birbirine bağlar.
topoloji. Hiyerarşik topoloji oluşturulduktan sonra, düzleştirilir ve büyük bir
yönlendirici düzeyinde topoloji.

Daha fazla bilgi BRITE kullanım kılavuzunda bulunabilir:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

Model Tanım
Model, harici bir BRITE kitaplığı oluşturmaya ve ardından bazı ns-3 oluşturmaya dayanır.
kütüphaneye seslenen yardımcılar. ns-3 yardımcılarının kaynak kodu şurada bulunur:
rehber kaynak/brite/yardımcı.

Tasarım
BRITE topolojisini oluşturmak için ns-3 yardımcıları harici BRITE kitaplığına seslenir ve
standart bir BRITE yapılandırma dosyası kullanarak, BRITE kodu, düğümleri olan bir grafik oluşturur ve
Bu yapılandırma dosyasına göre kenarlar. Lütfen BRITE belgelerine veya
daha iyi anlamak için src/brite/examples/conf_files içindeki örnek yapılandırma dosyaları
BRITE yapılandırma seçenekleri. BRITE tarafından oluşturulan grafik ns-3'e döndürülür ve bir ns-3
grafiğin uygulanması inşa edilmiştir. Kullanıcı için her AS için yaprak düğümleri mevcuttur
özel topolojiler eklemek veya doğrudan ns-3 uygulamalarını yüklemek için.

Referanslar
[1] Alberto Medina, Anukool Lakhina, İbrahim Matta ve John Byers. BRITE: Bir Yaklaşım
Evrensel Topoloji Üretimi. Uluslararası Çalıştay Bildirilerinde
Bilgisayar ve Telekomünikasyon Sistemlerinin Modellenmesi, Analizi ve Simülasyonu - MASKOTLAR
'01, Cincinnati, Ohio, Ağustos 2001.

kullanım
BRITE arayüzünün temel kullanımını görmek için brite-jenerik-örneğe başvurulabilir. İçinde
Özet olarak, BriteTopologyHelper, bir BRITE iletilerek arayüz noktası olarak kullanılır.
yapılandırma dosyası. Yapılandırma dosyasıyla birlikte bir BRITE formatlı rastgele tohum dosyası
ayrıca aktarılabilir. Bir tohum dosyası aktarılmazsa, yardımcı bir tohum oluşturur
ns-3'ün UniformRandomVariable'ını kullanan dosya. Topoloji BRITE tarafından oluşturulduktan sonra,
BuildBriteTopology(), ns-3 temsilini oluşturmak için çağrılır. Sonraki IP Adresi
AssignIpv4Addresses() veya AssignIpv6Addresses() kullanılarak topolojiye atanır. o
topolojideki her noktadan noktaya bağlantının yeni bir bağlantı olarak ele alınacağına dikkat edilmelidir.
ağ bu nedenle IPV4 için büyük miktarda veri israfını önlemek için a /30 alt ağı kullanılmalıdır.
kullanılabilir adres alanı.

Örnek BRITE yapılandırma dosyaları /src/brite/examples/conf_files/ içinde bulunabilir.
ASBarbasi ve ASWaxman, yalnızca AS topolojilerinin örnekleridir. RTBarabası ve RTWaxman
dosyalar yalnızca yönlendirici topolojilerinin örnekleridir. Sonunda TD_ASBarabasi_RTWaxman
yapılandırma dosyası, Barabasi-Albert'i kullanan bir Hiyerarşik topoloji örneğidir.
AS düzeyi için model ve yönlendirici düzeyindeki topolojilerin her biri için Waxman modeli.
Bu dosyalarda kullanılan BRITE parametreleriyle ilgili bilgiler BRITE kullanıcısında bulunabilir.
manuel.

bina BRİT Entegrasyonu
İlk adım, ns-3'e özel BRITE deposunu indirmek ve oluşturmaktır:

$ hg klonu http://code.nsnam.org/BRITE
$ cd BRITE
Yap $

Bu, BRITE'ı oluşturacak ve BRITE dizini içinde libbrite.so adlı bir kitaplık oluşturacaktır.

BRITE başarıyla oluşturulduktan sonra, ns-3'ü BRITE desteğiyle yapılandırmaya devam ediyoruz.
ns-3 dizininize değiştirin:

$ ./wafconfig --with-brite=/your/path/to/brite/source --enable-examples

'BRITE Entegrasyonu'nun yanında 'etkin' yazdığından emin olun. Olmazsa, o zaman bir şey vardır
ters gitti. Ya yukarıdaki adımları izleyerek BRITE kurmayı unuttunuz ya da
ns-3, BRITE dizininizi bulamadı.

Ardından, ns-3'ü oluşturun:

$ ./waf

Örnekler
BRITE entegrasyon çalışmasını gösteren bir örnek için:

$ ./waf -- 'brite-jenerik-örnek' çalıştır

Ayrıntılı parametre etkinleştirildiğinde, örnek düğümü ve kenarı yazdıracaktır.
standart BRITE çıktısına benzer bir formatta bilgi. başka birçok var
confFile, tracing ve nix dahil olmak üzere aşağıda açıklanan komut satırı parametreleri:

confDosya
Bir BRITE yapılandırma dosyası. Birçok farklı BRITE yapılandırma dosyası örneği
src/brite/examples/conf_files dizininde bulunur, örneğin,
RTBarabasi20.conf ve RTWaxman.conf. Lütfen conf_files dizinine bakın
daha fazla örnek için.

izleme
Ascii izlemeyi etkinleştirir.

reddetmek Nix-vektör yönlendirmesini etkinleştirir. Genel yönlendirme varsayılan olarak kullanılır.

Genel BRITE örneği, python bağlamalarını varsayarak pyviz kullanarak görselleştirmeyi de destekler.
ns-3'te etkinleştirilir:

$ ./waf -- brite-jenerik-örnek çalıştır --vis

BRITE içeren simülasyonlar MPI ile de kullanılabilir. MPI örneklerinin toplam sayısı
düğümleri atamak için bir modulo bölmenin kullanıldığı BRITE topoloji yardımcısına iletilir
her AS için bir MPI örneğine. src/brite/examples içinde bir örnek bulunabilir:

$ mpirun -np 2 ./waf --run brite-MPI-örnek

ns-3 ile MPI kurulumu hakkında bilgi için lütfen ns-3 MPI belgelerine bakın.

BİNALAR MODÜL

cd .. şunları içerir:: replace.txt

Tasarım belgeleme
Genel Bakış
Binalar modülü şunları sağlar:

1. yeni bir sınıf (bina) simülasyonda bir binanın varlığını modelleyen
senaryo;

2. yeni bir sınıf (MobiliteBina Bilgisi) konumu, boyutu ve
Simüle edilen alanda bulunan binaların özellikleri ve yerleşime izin verir.
bu binaların içindeki düğümlerin;

3. en kullanışlı pathloss modellerinin tanımını içeren bir kapsayıcı sınıfı ve
denilen karşılık gelen değişkenler BinalarYayılmaKayıpModel.

4. yeni bir yayılma modeli (HibritBinalarYayılmaKayıpModel) ile çalışmak
fenomenini modellemeye izin veren, yeni tanıtılan hareketlilik modeli
binaların varlığında iç/dış mekan yayılımı.

5. Yalnızca Okumura Hata ile çalışan basitleştirilmiş bir model (OhBinalarYayılmaKayıpModeli)
mevcudiyetinde iç/dış mekan yayılımı olgusunu göz önünde bulundurarak
binalar.

Modeller LTE düşünülerek tasarlanmıştır, ancak uygulamaları aslında
herhangi bir LTE'ye özgü koddan bağımsızdır ve diğer ns-3 kablosuz ile kullanılabilir
teknolojileri de (örneğin, wifi, wimax).

The HibritBinalarYayılmaKayıpModel dahil edilen yol kaybı modeli, bir
farklı durumları taklit etmek için iyi bilinen birkaç pathloss modelinin kombinasyonu
kentsel, banliyö ve açık alanlar gibi çevresel senaryolar. Ayrıca, model
hem dış hem de iç mekan iç ve dış iletişimin dahil edilmesi gerektiğini düşünür
çünkü HeNB bina içinde veya dışında kurulabilir. iç mekan olması durumunda
iletişim, model ayrıca bina tipini dış mekanda <-> iç mekanda da dikkate almalıdır.
duvar penetrasyon kayıpları gibi bazı genel kriterlere göre iletişim
ortak malzemeler; dahası, dahili için bazı genel yapılandırmaları içerir.
iç mekan iletişiminde duvarlar.

The OhBinalarYayılmaKayıpModeli basitleştirmek için pathloss modeli oluşturulmuştur.
önceki, bir modelden diğerine geçiş için eşikleri kaldırıyor. Bunu yapmak için
mevcut olandan yalnızca bir yayılım modeli kullanılmıştır (yani, Okumura
Hata). Modelde hala binanın varlığı dikkate alınmaktadır; bu nedenle tüm
bina tipi ile ilgili yukarıdaki hususlar hala geçerlidir. Aynısı
beri çevresel senaryoyu ve sıklığı ilgilendiren hususlar dikkate alınabilir.
her ikisi de dikkate alınan modelin parametreleridir.

The bina sınıf
Model, adı verilen belirli bir sınıfı içerir. bina ns3 içeren kutu için sınıf
binanın boyutunu tanımlar. özelliklerini hayata geçirmek için
yol kaybı modelleri dahil, bina class aşağıdaki öznitelikleri destekler:

· bina tipi:

· Konut (varsayılan değer)

· Ofis

· Reklam

· dış duvar tipi

· Odun

· BetonWithWindows (varsayılan değer)

· Penceresiz Beton

· Taş bloklar

· kat sayısı (varsayılan değer 1, bu yalnızca zemin kat anlamına gelir)

· x eksenindeki oda sayısı (varsayılan değer 1)

· y eksenindeki oda sayısı (varsayılan değer 1)

Yapı sınıfı aşağıdaki varsayımlara dayanmaktadır:

· bir bina dikdörtgen paralel yüzlü olarak temsil edilir (yani bir kutu)

· duvarlar x, y ve z eksenine paraleldir

· bir bina, aşağıdaki parametrelerle tanımlanan bir oda ızgarasına bölünmüştür:

· kat sayısı

· x ekseni boyunca oda sayısı

· y ekseni boyunca oda sayısı

· z ekseni dikey eksendir, yani artan z ekseni için kat sayıları artar
değerlerimiz

· x ve y oda endeksleri 1'den başlar ve x ve y ekseni boyunca artar
sırasıyla

· bir binadaki tüm odalar eşit büyüklükte

The MobiliteBina Bilgisi sınıf
The MobiliteBina Bilgisi ns3 sınıfından miras alan sınıf nesne, sorumlu olan
bina ile ilgili olarak bir düğümün konumu hakkında bilgi muhafaza etmek. bu
tarafından yönetilen bilgi MobiliteBina Bilgisi olduğu:

· düğümün kapalı mı yoksa açık mı olduğu

· kapalı ise:

· düğümün hangi binada olduğu

· düğümün hangi odada konumlandığı (x, y ve kat oda indeksleri)

Sınıf MobiliteBina Bilgisi tarafından kullanılır BinalarYayılmaKayıpModel sınıf, hangi
ns3 sınıfından miras alır Yayılma KaybıModeli ve yol kaybı hesaplamasını yönetir
düğümlerin konumlarına göre tek bileşenler ve bunların bileşimi. Dahası,
ana yoldaki engellerden kaynaklanan kayıp olan gölgelemeyi de uygular.
(yani bitki örtüsü, binalar vb.).

Şunu belirtmek gerekir ki, MobiliteBina Bilgisi başka herhangi bir yayılma modeli tarafından kullanılabilir.
Ancak, bu yazının yazıldığı tarihteki bilgilere dayanarak, yalnızca aşağıda tanımlananlar
bina modülü, sistemin getirdiği kısıtlamaları dikkate alacak şekilde tasarlanmıştır.
binalar.
g
ItuR1238Yayılma KaybıModeli
Bu sınıf, ITU'ya dayalı binaya bağlı bir iç mekan yayılma kaybı modelini uygular.
P.1238 modeg{, bina türünden (örneğin konut, ofis ve
ticari)ia Analitik ifade aşağıda verilmiştir.
nr
{r
aa
nerede: tamam. : güç kaybı
N = tr}kimlik bilgisi \ 30 ve ofis \ 22 ve ticari\nd{dizi}
katsayı [dB]
iyiyim.
L_f = t }yan \ 15+4(n-1) ve ofis \ 6+3(n-1) ve ticari\nd{dizi}
{l
n : baz istasyonu ile mobil arasındaki kat sayısı (n 1)
l2
f : frekans [MHz]
}&
d : mesafe (d > 1) [m]
n
BinalarPropag&ationLossModeli
BuildingsPropagationLossModel, binaya bağlı ek bir dizi
farklı yol kaybı mantıklarını uygulamak için kullanılan yol kaybı modeli öğeleri. Bunlar
pathloss model öğeleri aşağıdaki alt bölümlerde açıklanmıştır.

dış Duvar Kayıp (EWL)
Bu bileşen, içeriden dışarıya doğru duvarlardan penetrasyon kaybını modeller.
iletişim ve tersi. Değerler [cost231] modelinden alınmıştır.

· Ahşap ~ 4 dB

· Pencereli beton (metalize edilmemiş) ~ 7 dB

· Penceresiz beton ~ 15 dB (COST10'de 20 ile 231 arasındadır)

· Taş bloklar ~ 12 dB

İç Duvarlar Kayıp (IWL)
Bu bileşen, içeriden içeriye iletişimde meydana gelen penetrasyon kaybını modeller.
aynı bina içinde. Toplam kayıp, her bir dahili
duvarın sabit bir penetrasyon kaybı L_{siw} vardır ve duvarların sayısına yaklaşık olarak
verici arasındaki manhattan mesafesi (oda sayısı olarak) ile nüfuz edilir.
ve alıcı. Ayrıntılı olarak, x_1, y_1, x_2, y_2, x boyunca oda numarasını göstersin ve
sırasıyla kullanıcı 1 ve 2 için y ekseni; toplam kayıp L_{IWL} şu şekilde hesaplanır:

Yükseklik Kazanç Model (HG)
Bu bileşen, verici cihazın bir zemin üzerinde olması nedeniyle kazancı modellemektedir.
yer üstünde. Literatürde [turkmani] bu kazanç yaklaşık 2 dB olarak değerlendirilmiştir.
kat başına. Bu kazanç, tüm iç ve dış iletişimlere uygulanabilir ve
tersine.

Gölgeleme Model
Gölgeleme, değişken standartlı bir log-normal dağılıma göre modellenmiştir.
MobilityModel'in göreli konumunun (iç veya dış) fonksiyonu olarak sapma
ilgili durumlar. Her MobilityModel çifti için rastgele bir değer çekilir ve kalır
tüm simülasyon boyunca bu çift için sabit. Böylece model uygun
yalnızca statik düğümler.

Model, dB cinsinden gölgeleme kaybının ortalamasının her zaman 0 olduğunu kabul eder.
model, standart sapmanın üç olası değerini ayrıntılı olarak dikkate alır:
ok X_thrm{O}
· dış mekan (m_shadowingSigmaDış Mekan, varsayılan değer 7 dB)
N(_thrm{O}, ma_thrm{O}^2).
ok X_thrm{I}
· kapalı (m_shadowingSigmaİç Mekan, varsayılan değer 10 dB)
N(_thrm{I}, ma_thrm{I}^2).
okçu
· dış duvar penetrasyonu (m_shadowingSigmaDuvar Duvarları, varsayılan değer 5 dB)
X_thrm{W} N(_thrm{W}, ma_thrm{W}^2)

Simülatör, düğümlere göre her aktif bağlantı için bir gölgeleme değeri üretir.
bağlantı iletim için ilk kez kullanıldığında konumlandırın. dan iletilmesi durumunda
dış düğümlerden iç mekan düğümlerine ve tam tersi, standart sapma (ma_thrm{IO})
standardın ikinci dereceden değerlerinin toplamının karekökü olarak hesaplanmalıdır.
dış düğümler ve dış duvarların penetrasyonu için olan sapma durumunda sapma. Bu
gölgelemeyi oluşturan bileşenlerin birbirinden bağımsız olması nedeniyle
diğer; bu nedenle, iki bağımsız sayının toplamından kaynaklanan bir dağılımın varyansı
normal olanlar varyansların toplamıdır.

Yol kaybı mantıkları
Aşağıda, tarafından uygulanan farklı pathloss mantığını açıklıyoruz.
BuildingsPropagationLossModel'den devralma.

HibritBinalarYayılmaKayıpModel
The HibritBinalarYayılmaKayıpModel dahil edilen yol kaybı modeli, bir
Farklı dış mekanları taklit etmek için iyi bilinen birkaç pathloss modelinin kombinasyonu ve
iç mekan senaryolarının yanı sıra iç mekandan dış mekana ve dış mekandan iç mekana senaryolar. Detayda,
sınıf HibritBinalarYayılmaKayıpModel aşağıdaki pathloss modellerini entegre eder:

· OkumuraHataPropagationLossModel (OH) (> 2.3 GHz frekanslarında
Kun2600MhzYayılmaKayıpModeli)

· ItuR1411LosPropagationLossModel ve ItuR1411NlosOverRooftopPropagationLossModel
(I1411)

· ItuR1238Yayılma KaybıModeli (I1238)

· BuildingsPropagationLossModel'in yol kaybı öğeleri (EWL, HG, IWL)

Aşağıdaki sözde kod, farklı pathloss model öğelerinin nasıl tanımlandığını gösterir.
yukarıdakiler entegre edilmiştir HibritBinalarYayılmaKayıpModel:

if (txNode dış mekanda)
sonra
if (rxNode dış mekanda)
sonra
if (mesafe > 1 km)
sonra
if (rxNode veya txNode çatının altındaysa)
sonra
L = I1411
başka
L = OH
başka
L = I1411
başka (rxNode kapalı)
if (mesafe > 1 km)
sonra
if (rxNode veya txNode çatının altındaysa)
L = I1411 + EWL + HG
başka
L = OH + EWL + HG
başka
L = I1411 + EWL + HG
başka (txNode kapalı)
if (rxNode kapalı)
sonra
eğer (aynı bina)
sonra
L = I1238 + IWL
başka
L = I1411 + 2*EWL
başka (rxNode dış mekandır)
if (mesafe > 1 km)
sonra
if (rxNode veya txNode çatının altındaysa)
sonra
L = I1411 + EWL + HG
başka
L = OH + EWL + HG
başka
L = I1411 + EWL

Çatı seviyesinin altındaki iki düğüm arasındaki iletişim durumunda,
mesafe 1 km'den büyükse, OH özellikle
makro hücreler ve dolayısıyla çatı seviyesinin üzerindeki antenler için tasarlanmıştır.

ITU-R P.1411 modeli için hem LOS hem de NLoS versiyonlarını dikkate alıyoruz. Özellikle, biz
Ayarlanabilir bir eşik değerinden daha kısa olan mesafeler için LoS yayılımını dikkate alır
(m_itu1411NlosEşik). NLoS yayılımı durumunda, çatı üstü model
hem makro BS hem de SC'yi modellemek için dikkate alınmıştır. NLoS'da birden fazla olması durumunda
ortalama sokak genişliği gibi senaryoya bağlı parametreler dahil edilmiştir,
oryantasyon, vb. Bu tür parametrelerin değerleri, aşağıdakilere göre uygun şekilde ayarlanmalıdır.
Uygulanan senaryo, model doğal olarak değerlerini hesaplamaz. herhangi bir durumda
değerleri sağlanır, mobil ve BS yüksekliği dışında standart olanlar kullanılır,
bunun yerine bütünlükleri doğrudan kodda test edilir (yani,
sıfırdan büyük). Aşağıda bileşenlerinin ifadelerini veriyoruz.
modeli.

Ayrıca farklı yayılma modellerinin (OH, I1411, I1238 ile birlikte
varyantları) HybridBuildingsPropagationLossModel'deki süreksizliklere neden olabilir.
mesafeye göre yol kaybı. Niteliklerin uygun şekilde ayarlanması (özellikle
mesafe eşiği öznitelikleri) bu süreksizlikleri önleyebilir. Ancak, o zamandan beri
her modelin davranışı diğer birkaç parametreye bağlıdır (frekans, düğüm yüksekliği, vb.),
tüm süreksizlikleri önleyebilecek bu eşiklerin varsayılan bir değeri yoktur.
olası konfigürasyonlar Bu nedenle, bu parametrelerin uygun bir şekilde ayarlanması kullanıcıya bırakılmıştır.
kullanıcı.

OhBinalarYayılmaKayıpModeli
The OhBinalarYayılmaKayıpModeli sınıf, sorunu çözmek için basit bir araç olarak oluşturuldu.
süreksizlik problemleri HibritBinalarYayılmaKayıpModel yapmadan
senaryoya özel parametre ayarı. Çözüm, yalnızca bir yayılma kaybı kullanmaktır.
model (yani Okumura Hata), yol kaybı mantığının yapısını korurken
diğer yol kaybı bileşenlerinin hesaplanması (duvar penetrasyon kayıpları gibi). sonuç
süreksizlik içermeyen bir model (duvarlardan kaynaklananlar hariç), ancak bu daha az
binalar ve dış/iç mekan kullanıcıları ile genel bir senaryo için genel olarak gerçekçi, örn.
çünkü Okumura Hata ne iç mekan iletişimi için ne de dış mekan iletişimi için uygun değildir.
çatı seviyesinin altındaki iletişim.

Ayrıntılı olarak, sınıf OhBinalarYayılmaKayıpModeli aşağıdaki pathloss'u entegre eder
modeller:

· OkumuraHataYayılma KaybıModeli (OH)

· BuildingsPropagationLossModel'in yol kaybı öğeleri (EWL, HG, IWL)

Aşağıdaki sözde kod, farklı pathloss model öğelerinin nasıl tanımlandığını gösterir.
yukarıdakiler entegre edilmiştir OhBinalarYayılmaKayıpModeli:

if (txNode dış mekanda)
sonra
if (rxNode dış mekanda)
sonra
L = OH
başka (rxNode kapalı)
L = OH + EWL
başka (txNode kapalı)
if (rxNode kapalı)
sonra
eğer (aynı bina)
sonra
L = OH + IWL
başka
L = OH + 2*EWL
başka (rxNode dış mekandır)
L = OH + EWL

OhBuildingsPropagationLossModel'in saygıyla ilgili önemli bir basitleştirme olduğunu not ediyoruz.
OH'nin her zaman kullanılması nedeniyle HybridBuildingsPropagationLossModel'e. Bu iken
bazı senaryolarda (özellikle çatı altında ve kapalı mekanlarda) daha az doğru bir model verir,
etkileyen pathloss süreksizlikleri sorununu etkin bir şekilde önler.
HibritBinalarYayılmaKayıpModeli.

kullanıcı Dökümanlar
Ne kadar için kullanım binalar in a simülasyon
Bu bölümde, bir simülasyon içinde bina modelinin temel kullanımını açıklıyoruz.
programı.

Dahil the başlıkları
Bunu simülasyon programınızın başına ekleyin:

#Dahil etmek

oluşturmak a bina
Örnek olarak, bir konut 10 x 20 x 10 bina oluşturalım:

çift ​​x_min = 0.0;
çift ​​x_maks = 10.0;
çift ​​y_min = 0.0;
çift ​​y_max = 20.0;
çift ​​z_min = 0.0;
çift ​​z_max = 10.0;
Ptr b = OluşturNesne ();
b->Sınırları Ayarla (Kutu (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Bina::Konut);
b->SetExtWallsType (Bina::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRoomsX (3);
b->Odaları AyarlaY (2);

Bu bina üç kata ve eşit büyüklükte 3 x 2 iç ızgaraya sahiptir.

GridBuildingAllocator yardımcı sınıfı da kolayca bir dizi oluşturmak için kullanılabilir.
dikdörtgen bir ızgara üzerine yerleştirilmiş aynı özelliklere sahip binalar. İşte bir örnek
nasıl kullanılacağı hakkında:

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 ("Yükseklik", 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->Oluştur (6);

Bu, her biri 3 x 2 x 6 m boyutlarında, içinde 7 x 13 oda bulunan 6 binadan oluşan 2x4'lik bir ızgara oluşturacaktır.
2 kat; binalar hem x hem de y ekseninde 3 m aralıklarla yerleştirilmiştir.

Kurmak düğümler ve hareketlilik modelleri
Düğümler ve mobilite modelleri her zamanki gibi yapılandırılmıştır, ancak bunları
ek bir çağrıya ihtiyacınız olan bina modeli BinalarYardımcısı::Yükle(), izin vermek için
hareketlilik modeli, binalara göre konumlarına ilişkin bilgileri içerir. Burada
Bir örnek:

MobiliteYardımcı mobilite;
hareketlilik.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobilite.Install (ueNodes);
BuildingsHelper::Kur (ueNodes);

Herhangi bir hareketlilik modelinin kullanılabileceği belirtilmelidir. Ancak, kullanıcıya tavsiye edilir.
kullanılan hareketlilik modelinin davranışının,
Binaların varlığı. Örneğin, bütün üzerinde basit bir rastgele hareketlilik kullanmak
Binaların bulunduğu simülasyon alanı, düğümlerin kolayca içeri ve dışarı hareket etmesine neden olabilir.
duvarların varlığından bağımsız olarak binalar.

yer biraz düğümler
Aşağıda açıklanan çeşitli yöntemleri kullanarak simülasyonunuza düğümler yerleştirebilirsiniz.
takip etme.

miras konumlandırma yöntemleri
Simülasyona düğüm yerleştirmek için herhangi bir eski ns-3 konumlandırma yöntemi kullanılabilir. bu
önemli bir ek adım, örneğin, düğümleri şu şekilde manuel olarak yerleştirebilirsiniz:

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

MobiliteYardımcı mobilite;
hareketlilik.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobilite.Install (ueNodes);
BuildingsHelper::Kur (ueNodes);
mm0->SetPosition (Vektör (5.0, 5.0, 1.5));
mm1->SetPosition (Vektör (30.0, 40.0, 1.5));

Alternatif olarak, mevcut herhangi bir PositionAllocator sınıfını kullanabilirsiniz. koordinatları
düğüm, dış mekanda mı yoksa iç mekanda mı yerleştirileceğini ve iç mekanda ise hangi
bina ve oda yerleştirilir.

Binaya özel konumlandırma yöntemleri
Düğümü özel konumlara yerleştirmek için aşağıdaki konum ayırıcı sınıfları mevcuttur
binalarla ilgili olarak:

· RandomBuildingPositionAyırıcı: Rastgele bir pozisyon seçerek her bir pozisyonu tahsis edin.
tüm binaların listesinden inşa etmek ve ardından rastgele bir pozisyon seçmek
bina.

· RastgeleOdaKonumAlıcısı: Rastgele bir oda seçerek her bir pozisyonu tahsis edin.
tüm binalardaki odaların listesi ve ardından rastgele bir konum seçerek
oda.

· Aynı Oda Pozisyonu Ayırıcı: Belirli bir NodeContainer'ı sırayla ve her biri için yürür
düğüm, o düğümün aynı odasında rastgele yeni bir konum tahsis eder.

· SabitOda KonumuAlıcısı: Alanda eşit olarak dağıtılmış rastgele bir konum oluşturun.
seçilen bir binanın içindeki seçilmiş bir odanın hacmi.

Yapmak the Hareketlilik Model Tutarlı
Hatırlatma: binaları her kullandığınızda, biz yaptıktan sonra aşağıdaki komutu vermeniz gerekir.
tüm düğümleri ve binaları simülasyona yerleştirdi:

BuildingsHelper::MakeMobilityModelConsistent ();

Bu komut, tüm düğümlerin ve tüm binaların listelerini gözden geçirecek, aşağıdakileri belirleyecektir:
her kullanıcı iç mekanda veya dış mekanda, iç mekanda ise binayı da belirleyecektir.
kullanıcının bulunduğu yer ve bina içindeki ilgili kat ve numara.

Bina bilincine sahip yol kaybı model
Binaları ve düğümleri bir simülasyona yerleştirdikten sonra, binaya duyarlı bir
bir simülasyondaki yol kaybı modeli, tam olarak herhangi bir normal yol kaybını kullandığınız şekilde
modeli. Bunun nasıl yapılacağı, düşündüğünüz kablosuz modüle özeldir (lte,
wifi, wimax, vb.), bu nedenle lütfen belirli özellikler için o modelin belgelerine bakın.
talimatları.

Ana yapılandırılabilir öznitelikleri
The bina sınıf aşağıdaki yapılandırılabilir parametrelere sahiptir:

· bina tipi: Konut, Ofis ve Ticari.

· dış duvar tipi: Wood, ConcreteWithWindows, ConcreteWithoutWindows ve StoneBlocks.

· bina sınırları: a kutu bina sınırları ile sınıf.

· kat sayısı.

· x ekseni ve y eksenindeki oda sayısı (odalar yalnızca ızgara şeklinde yerleştirilebilir).

The BinaMobiliteKayıpModel ns3 öznitelik sistemiyle yapılandırılabilen parametre
sınırla temsil edilir (dize sınırlar) sağlayarak simülasyon alanının kutu sınıf
alan sınırları ile. Ayrıca, metotları aracılığıyla aşağıdaki parametreler de belirlenebilir:
yapılandırılmış:

· düğümün yerleştirildiği kat sayısı (varsayılan 0).

· odalar ızgarasındaki konum.

The BinaYayılmaKayıpModeli sınıf aşağıdaki yapılandırılabilir parametrelere sahiptir
öznitelik sistemi ile yapılandırılabilir:

· Sıklık: referans frekansı (varsayılan 2160 MHz), frekansı ayarlayarak
dalga boyu buna göre otomatik olarak ayarlanır ve bunun tersi de geçerlidir).

· Lambda: dalga boyu (yukarıdaki frekans dikkate alındığında 0.139 metre).

· GölgeSigmaAçık Hava: dış mekan düğümleri için gölgelemenin standart sapması (varsayılan
7.0).

· GölgeSigmaİç Mekan: iç mekan düğümleri için gölgelemenin standart sapması (varsayılan
8.0).

· ShadowSigmaExtDuvarlar: dış duvarlardan kaynaklanan gölgelemenin standart sapması
dış mekandan iç mekana iletişim için penetrasyon (varsayılan 5.0).

· çatı katı: metre cinsinden binanın çatı katının seviyesi (varsayılan 20 metre).

· Los2NlosThr: görüş hattı ile anahtarlama noktası arasındaki mesafenin değeri
metre cinsinden görüş hattı olmayan yayılma modeli (varsayılan 200 metre).

· ITU1411MesafeThr: kısa menzil arasındaki anahtarlama noktasının mesafesinin değeri
(ITU 1211) iletişim ve uzun menzilli (Okumura Hata) metre cinsinden (varsayılan 200 metre).

· MinMesafe: değerlendirme için iki düğüm arasındaki metre cinsinden minimum mesafe
yol kaybı (bu eşikten önce ihmal edilebilir olarak kabul edilir) (varsayılan 0.5 metre).

· çevre: Urban, SubUrban ve OpenAreas arasındaki çevre senaryosu (varsayılan
Kentsel).

· ŞehirBoyutu: şehrin Küçük, Orta, Büyük (varsayılan Büyük) arasındaki boyutu.

Hibrit modu kullanmak için kullanılacak sınıf,
HibritBinaHareketlilikKayıpModel, uygun pathloss modelinin seçilmesine izin verir
tasarım bölümünde sunulan yol kaybı mantığına göre. Ancak bu çözüm
pathloss modeli anahtarlama noktalarının süreksizlikler gösterebilmesi sorununa sahiptir.
modelin farklı özelliklerine Bu, belirli şartlara göre
senaryoda, anahtarlama için kullanılan eşiğin uygun şekilde ayarlanması gerekir. basit
OhBinaHareketlilikKayıpModel sadece Okumura Hata modelini kullanarak bu sorunun üstesinden gelin ve
duvar penetrasyon kayıpları

Test yapmak Dökümanlar
Genel Bakış
ns-3 Building Pathloss modülünü test etmek ve doğrulamak için bazı test paketleri sağlanmıştır.
ns-3 test çerçevesi ile entegre edilmiştir. Bunları çalıştırmak için,
simülatörün bu şekilde oluşturulması:

$ ./wafconfig --enable-tests --enable-modules=binalar
$ ./test.py

Yukarıdakiler sadece binalar modülüne ait test takımlarını değil, aynı zamanda
binalar modülünün bağlı olduğu diğer tüm ns-3 modüllerine ait olanlar. Görmek
test çerçevesi hakkında genel bilgiler için ns-3 kılavuzu.

HTML formatında daha detaylı bir raporu şu şekilde alabilirsiniz:

$ ./test.py -w sonuçlar.html

Yukarıdaki komut çalıştırıldıktan sonra, her test için ayrıntılı sonucu açarak görüntüleyebilirsiniz.
Dosya sonuçlar.html bir web tarayıcısı ile.

Bu komutu kullanarak her bir test takımını ayrı ayrı çalıştırabilirsiniz:

$ ./test.py -s test takımı-adı

Hakkında daha fazla bilgi için test.py ve ns-3 test çerçevesi için lütfen ns-3'e bakın
manuel.

Tanım of the test suit
BinalarYardımcı test
test takımı bina yardımcısı yöntemin olup olmadığını kontrol eder
BinalarHelper::MakeAllInstancesConsistent () düzgün çalışıyor, yani
BuildingsHelper, düğümlerin açık mı yoksa kapalı mı olduğunu ve kapalı mı olduğunu bulmada başarılıdır.
doğru bina, oda ve katta bulunduklarını Birkaç test vakası
farklı binalar (farklı büyüklük, konum, odalar ve katlara sahip) ile sağlanan ve
farklı düğüm konumları. Her düğüm doğru bir şekilde yerleştirilmişse test başarılı olur.

BinaKonumAlıcısı test
test takımı bina-konum-tahsis edici bunu kontrol eden iki test senaryosu
sırasıyla RandomRoomPositionAllocator ve SameRoomPositionAllocator düzgün çalışıyor. Her biri
test senaryoları, bilinen koordinatlarda tek bir 2x3x2 oda binasını (toplam 12 oda) içerir ve
sırasıyla 24 ve 48 düğüm. Her iki test de, her birine tahsis edilen düğüm sayısının
oda beklenendir ve düğümlerin konumu da doğrudur.

Binalar Yol kaybı testleri
test takımı binalar-yol kaybı-modeli karşılaştıran farklı birim testleri sağlar.
önceden belirlenmiş senaryolarda bina yol kaybı modülünün beklenen sonuçları
Octave komut dosyasıyla çevrimdışı olarak elde edilen hesaplanmış değerler
(test/referans/binalar-pathloss.m). İki değerin olması durumunda testler başarılı olarak kabul edilir.
tipik kullanımı için uygun görülen 0.1 toleransa eşittir.
pathloss değerleri (dB cinsindendir).

Aşağıda ele alınan senaryoları detaylandırdık, seçimleri şu şekilde yapılmıştır:
geniş olası yol kaybı mantık kombinasyonlarını kapsar. Yol kaybı mantığı sonuçları
bu nedenle dolaylı olarak test edilmiştir.

test #1 okumura Hata
Bu testte standart Okumura Hata modelini test ediyoruz; bu nedenle hem eNB hem de UE yerleştirilir
2000 m mesafede dışarıda. Kullanılan frekans E-UTRA bandı #5'tir;
869 MHz'e karşılık gelir (bkz. Tablo 5.5-1, 36.101). Test aynı zamanda doğrulamayı da içerir.
alan uzantılarının (yani kentsel, banliyö ve açık alanlar) ve şehir büyüklüğünün
(küçük, orta ve büyük).

test #2 MALİYET231 Model
Bu test, COST231 modelini doğrulamayı amaçlamaktadır. Test Okumura'ya benzer
Hata bir, kullanılan frekansın EUTRA bandı #1 (2140 MHz) olması ve testin
Model nedeniyle kentsel senaryolarda sadece büyük ve küçük şehirler için gerçekleştirilebilmektedir.
sınırlamalar.

test #3 2.6 GHz model
Bu test, 2.6 GHz Kun modelini doğrular. Test, aşağıdakiler dışında Okumura Hata'ya benzer:
frekansın EUTRA bandı #7 (2620 MHz) olduğunu ve testin yalnızca
kentsel senaryo.

test #4 İTÜ1411 LoS model
Bu test, sokak içinde görüş hattı olması durumunda ITU1411 modelini doğrulamayı amaçlamaktadır.
kanyon iletimleri. Bu durumda UE, eNB'den 100 metre uzağa yerleştirilir, çünkü
LoS ve NLoS arasında geçiş eşiği varsayılan değere bırakılır (yani, 200 m.).

test #5 İTÜ1411 NLoS model
Bu test, üzerinde görüş hattı olmaması durumunda ITU1411 modelini doğrulamayı amaçlamaktadır.
çatı iletimleri. Bu durumda UE, eNB'den 900 metre uzağa yerleştirilir.
LoS ve NLoS arasında geçiş yapma eşiğinin üzerinde olma sırası varsayılan değere bırakılır
(yani, 200 m.).

test #6 ITUP1238 model
Bu test, iç mekan iletimleri durumunda ITUP1238 modelini doğrulamayı amaçlamaktadır. İçinde
bu durumda hem UE hem de eNB, duvarlardan yapılmış bir konut binasına yerleştirilmiştir.
pencereli beton. Ue, ikinci katta yer almaktadır ve 30 metre uzaklıktadır.
birinci katta yer alan eNB.

test #7 Dış Aydınlatma -> İç Aydınlatma ile okumura Hata model
Bu test, büyük mesafeler için dış mekandan iç mekana aktarımları doğrular. Bu durumda
UE, pencereli beton duvarlı bir konut binasına yerleştirilir ve
dış mekan eNB'den 2000 metre mesafe.

test #8 Dış Aydınlatma -> İç Aydınlatma ile İTÜ1411 model
Bu test, kısa mesafeler için dış mekandan iç mekana aktarımları doğrular. Bu durumda
UE, pencereleri ve betondan yapılmış duvarları olan bir konut binasına yerleştirilir ve
dış mekan eNB'den 100 metre mesafe.

test #9 İç Aydınlatma -> Dış Aydınlatma ile İTÜ1411 model
Bu test, çok kısa mesafeler için dış mekandan iç mekana aktarımları doğrular. Bunda
eNB'nin duvarları metalden yapılmış bir konut binasının ikinci katına yerleştirilmesi durumunda
pencereli beton ve dış mekan UE'sinden 100 metre mesafe (yani, LoS
iletişim). Bu nedenle yükseklik kazanımı, pathloss değerlendirmesine dahil edilmelidir.

test #10 İç Aydınlatma -> Dış Aydınlatma ile İTÜ1411 model
Bu test, kısa mesafeler için dış mekandan iç mekana aktarımları doğrular. Bu durumda
eNB, duvarları metalden yapılmış bir konut binasının ikinci katına yerleştirilmiştir.
pencereli beton ve dış mekan UE'den 500 metre mesafe (yani, NLoS
iletişim). Bu nedenle yükseklik kazanımı, pathloss değerlendirmesine dahil edilmelidir.

Binalar Gölgeleme test
test takımı binalar-gölgeleme-testi istatistiksel doğrulamayı amaçlayan bir birim testidir.
tarafından uygulanan gölgeleme modelinin dağılımı BinalarYol KaybıModel. gölgeleme
ortalama = 0 ve değişken standartlı normal dağılıma göre modellenmiştir
sapma ma, literatürde yaygın olarak kullanılan modellere göre. Üç test durumu
sağlanan, iç, dış ve iç-dış iletişim durumlarını kapsar.
Her bir test durumu, farklı çiftler için 1000 farklı gölgeleme örneği üretir.
Belirli bir senaryoda MobilityModel örnekleri. Gölgeleme değerleri çıkarılarak elde edilir
tarafından döndürülen toplam kayıp değerinden HibritBinalarYol Modeli yol kaybı bileşeni
bu sabittir ve her bir test durumu için önceden belirlenmiştir. Test, numunenin
gölgeleme değerlerinin ortalama ve örnek varyansı %99 güven aralığı içindedir
örnek ortalaması ve örnek varyansı. Test ayrıca gölgeleme değerlerinin
aynı MobilityModel örneği çifti için ardışık zamanlarda döndürülen sabittir.

Referanslar
[türkmani]
Turkmani AMD, JD Parson ve DG Lewis, "Binalara radyo yayılımı
441, 900 ve 1400 MHz", Proc. of 4th Int. Land Mobile Radio, 1987.

TIKLAYINIZ MODÜLER ROUTER ENTEGRASYON

Click, yapılandırılabilir yönlendiriciler oluşturmak için bir yazılım mimarisidir. Farklı kullanarak
Öğeler olarak adlandırılan paket işleme birimlerinin kombinasyonları için bir Tıklama yönlendiricisi yapılabilir.
belirli bir tür işlevsellik gerçekleştirir. Bu esneklik aşağıdakiler için iyi bir platform sağlar:
farklı protokolleri test etme ve deneme.

Model Tanım
Click modelinin kaynak kodu dizinde bulunur kaynak/tıklama.

Tasarım
ns-3'ün tasarımı, aşağıdaki nedenlerden dolayı Click ile entegrasyon için çok uygundur:

· ns-3'teki paketler, yığında yukarı/aşağı hareket ettikçe serileştirilir/seri hale getirilir. Bu izin verir
Click'e ve Click'ten iletilecek ns-3 paketleri oldukları gibi.

· Bu aynı zamanda her türlü ns-3 trafik oluşturucunun ve taşımanın kolayca çalışması gerektiği anlamına gelir.
tıklayın.

· Click'i bir Ipv4RoutingProtocol örneği olarak uygulamaya çalışarak,
ns-3 kodunun LL ve MAC katmanında önemli değişiklikler.

Tasarım amacı, ns-3-tıklamalı genel API'yi, kullanıcının
düğüme yalnızca bir Ipv4ClickRouting örneği eklemesi ve her bir Tıklama düğümünü bilgilendirmesi gerekir
Kullanacağı Click yapılandırma dosyasının (.click dosyası)

Bu model, arayüzü Click Modüler Yönlendiriciye uygular ve şunları sağlar:
Bir düğümün harici yönlendirme için Click kullanmasına izin vermek için Ipv4ClickRouting sınıfı. normalden farklı
Ipv4RoutingProtocol alt türleri, Ipv4ClickRouting bir RouteInput() yöntemi kullanmaz, ancak
bunun yerine uygun arabirimde bir paket alır ve buna göre işler. Not
Click for öğesini kullanmak için Click grafiğinizde bir yönlendirme tablosu tipi öğeye sahip olmanız gerektiğini
dış yönlendirme. Bu, kendisinden devralınan RouteOutput() işlevi için gereklidir.
Ipv4RoutingProtocol. Ayrıca, Tıklama tabanlı bir düğüm, farklı türde bir L3 kullanır.
Ipv4L3Protocol'un kısaltılmış bir sürümü olan Ipv4L3ClickProtocol formu.
Ipv4L3ClickProtocol, yığından geçen paketleri aşağıdakiler için Ipv4ClickRouting'e geçirir:
işleme.

Gelişen a Simülatör API için izin vermek ns-3 için etkileşim ile Tıkla
API'nin çoğu zaten iyi tanımlanmıştır, bu da Click'in
simülatör (bir Düğümün Kimliği, bir Arayüz Kimliği vb. gibi). çoğunu koruyarak
yöntemleri, aynı için ns-3'e özgü yeni uygulamalar yazmak mümkün olmalıdır.
işlevsellik.

Bu nedenle, ns-3 ile Click entegrasyonu için, Ipv4ClickRouting adlı bir sınıf,
Click ile etkileşim. Aynı kodu şurada bulabilirsiniz:
kaynak/tıklama/model/ipv4-tıklama yönlendirme.{cc,h}.

Paket el kapalı arasında ns-3 ve Tıkla
ns-3 ve Click arasında meydana gelebilecek dört çeşit paket aktarımı vardır.

· L4'ten L3'e

· L3'ten L4'e

· L3'ten L2'e

· L2'ten L3'e

Bunun üstesinden gelmek için, Ipv4L3ClickProtocol'un sadeleştirilmiş bir versiyonu olan IpvXNUMXLXNUMXClickProtocol'u uyguluyoruz.
Ipv4L3Protokol. Ipv4L3ClickProtocol, paketleri Ipv4ClickRouting'e ve IpvXNUMXClickRouting'den geçirir
Yönlendirmeyi gerçekleştirmek için uygun şekilde.

kapsam ve Sınırlamalar
· Mevcut durumunda, NS-3 Tıklama Entegrasyonu yalnızca L3 ile kullanımla sınırlıdır,
NS-3, L2'yi işlemek için. Şu anda Click MAC desteğini de eklemek için çalışıyoruz. Bkz.
Tıklama grafiklerinizi buna göre tasarladığınızdan emin olmak için kullanım bölümü.

· Ayrıca, ns-3-click yalnızca kullanıcı düzeyindeki öğelerle çalışacaktır. tam listesi
elemanlar şurada mevcuttur http://read.cs.ucla.edu/click/elements. sahip olan elementler
Yanlarında belirtilen 'all', 'userlevel' veya 'ns' kullanılabilir.

· Şu an itibariyle, Click için ns-3 arayüzü yalnızca Ipv4'tür. Ipv6 desteği ekleyeceğiz
gelecek.

Referanslar
· Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti ve M. Frans Kaashoek. bu
modüler yönlendiriciye tıklayın. Bilgisayar Sistemlerinde ACM İşlemleri 18(3), Ağustos 2000, sayfalar
263-297.

· Lalith Suresh P. ve Ruben Merz. Ns-3-click: ns-3 için modüler yönlendirici entegrasyonunu tıklayın.
Proc. 3rd International ICST Workshop on NS-3 (WNS3), Barselona, ​​İspanya. Mart,
2011

· Michael Neufeld, Ashish Jain ve Dirk Grunwald. Nsclick: köprüleme ağ simülasyonu
ve dağıtım. MSWiM '02: Modelleme üzerine 5. ACM uluslararası çalıştayının bildirileri
kablosuz ve mobil sistemlerin analizi ve simülasyonu, 2002, Atlanta, Georgia, ABD.
http://doi.acm.org/10.1145/570758.570772

kullanım
bina Tıkla
İlk adım, github deposundan Click'i klonlamak ve oluşturmaktır:

$ git klonu https://github.com/kohler/click
$ cd tıklama/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
Yap $

Click'i Wifi ile kullanmayı düşünmüyorsanız --enable-wifi bayrağı atlanabilir. *
Not: Bir 'make install' yapmanız gerekmez.

Click başarıyla oluşturulduktan sonra, ns-3 dizinine geçin ve ns-3'ü yapılandırın
Click Entegrasyon desteği ile:

$ ./waf yapılandırma --enable-examples --enable-tests --with-nsclick=/path/to/click/source

İpucu: ns-3'ün üzerine bir dizini yüklediyseniz (örneğin ns-3-allinone'da olduğu gibi)
dizin) ve dizinin adı 'tık' (veya dizine sembolik bir bağlantı)
'click' olarak adlandırılır), o zaman --with-nsclick belirteci gerekli değildir; ns-3 yapısı
sistem dizini başarıyla bulacaktır.

'NS-3 Click Integration Support'un yanında 'etkin' yazıyorsa, gitmeye hazırsınız demektir.
Not: Modüler ns-3 çalıştırılıyorsa, tüm ns-3 tıklamalarını çalıştırmak için gereken minimum modül seti
örnekler wifi, csma ve config-store'dur.

Ardından, örneklerden birini çalıştırmayı deneyin:

$ ./waf -- nsclick-simple-lan'ı çalıştır

Ardından, nsclick-simple-lan-0-0.pcap olarak adlandırılan, elde edilen .pcap izlerini görüntüleyebilirsiniz.
ve nsclick-simple-lan-0-1.pcap.

Tıkla grafik talimatlar
Tıklama grafiğinizi oluştururken aşağıdakiler akılda tutulmalıdır:

· Yalnızca kullanıcı düzeyindeki öğeler kullanılabilir.

· FromDevice ve ToDevice öğelerini FromSimDevice ile değiştirmeniz gerekecek ve
ToSimDevice öğeleri.

· Çekirdeğe paketler ToSimDevice(tap0,IP) kullanılarak gönderilir.

· Herhangi bir düğüm için, çekirdeğe/çekirdeğe paket gönderen/alınan aygıta isim verilir.
'tap0'. Kalan arayüzler eth0, eth1 ve benzeri olarak adlandırılmalıdır (
Wi-Fi kullanarak). Lütfen cihaz numaralandırmasının 0'dan başlaması gerektiğini unutmayın. Gelecekte bu
kullanıcıların Click dosyalarındaki cihazları istedikleri gibi adlandırabilmeleri için esnek hale getirilecek.

· Bir yönlendirme tablosu öğesi zorunludur. Yönlendirme tablosu öğesinin OUTport'ları,
paketin içinden geçeceği cihazın arayüz numarasına karşılık gelir.
sonunda gönderilir. Bu kuralı ihlal etmek gerçekten garip paket izlerine yol açacaktır.
Bu yönlendirme tablosu öğesinin adı daha sonra Ipv4ClickRouting protokolüne iletilmelidir.
simülasyon parametresi olarak nesne. Ayrıntılar için Tıklama örneklerine bakın.

· Mevcut uygulama, Click'i ns-3 işleme ile temel olarak L3 işlevselliğiyle bırakır
L2. Yakında Click'te de MAC protokollerinin kullanımını desteklemek için çalışmaya başlayacağız.
Bu, şu andan itibaren Click'in Wifi'ye özgü öğelerinin ns-3 ile kullanılamayacağı anlamına gelir.

Hata ayıklama Paket Akışları itibaren Tıkla
Tıklama grafiğindeki herhangi bir noktadan Yazdır (‐
http://read.cs.ucla.edu/click/elements/print) öğesi ve güzel baskı için türevleri
paket içeriği. Ayrıca, bir ağ üzerinden akan paketlerin pcap izlerini oluşturabilirsiniz.
ToDump'ı kullanarak grafiği tıklayın (http://read.cs.ucla.edu/click/elements/todump) öğesi olarak
kuyu. Örneğin:

myarp sorgulayıcı
-> Yazdır(fromarpquery,64)
-> ToDump(out_arpquery,PER_NODE 1)
-> çıkış;

ve ... ArpQuerier'den akan paketlerin içeriğini yazdıracak, ardından bir
Tıklamayı kullanan her düğüm için 'out_arpquery' son ekine sahip olacak pcap izleme dosyası
Dosyaları, paketleri 'ethout' üzerine göndermeden önce.

Yardımcı
Bir düğümün Click'i çalıştırması için en kolay yol ClickInternetStackHelper'ı kullanmaktır.
simülasyon komut dosyanızdaki sınıf. Örneğin:

ClickInternetStackHelper tıklaması;
click.SetClickFile (myNodeContainer, "nsclick-simple-lan.click");
click.SetRoutingTableElement (myNodeContainer, "u/rt");
tıklayın.Kur (myNodeContainer);

İçindeki örnek komut dosyaları kaynak/tıklama/örnekler/ içinde Tıklama tabanlı düğümlerin kullanımını göstermek
farklı senaryolar. Yardımcı kaynak içeride bulunabilir
kaynak/tıklama/yardımcı/tıklama-internet-yığın-yardımcısı.{h,cc}

Örnekler
Aşağıdaki örneklerde bulunabilecek şekilde yazılmıştır. kaynak/tıklama/örnekler/:

· nsclick-simple-lan.cc ve nsclick-raw-wlan.cc: Bir
Sırasıyla Csma ve Wifi kullanarak Click olmadan normal ns-3 düğümü. Ayrıca gösterir
Orijinal nsclick uygulamasının yaptığı bir şey olan Click'in üstünde TCP kullanımı
NS-2 başaramadı.

· nsclick-udp-client-server-csma.cc ve nsclick-udp-client-server-wifi.cc: 3 düğümlü LAN
(sırasıyla Csma ve Wifi) burada 2 Tıklama tabanlı düğümler bir UDP istemcisi çalıştırır,
paketleri bir UDP sunucusu çalıştıran üçüncü bir Tıklama tabanlı düğüme gönderir.

· nsclick-routing.cc: Tek Tıklama tabanlı düğüm, üçüncü bir düğüm aracılığıyla bir başkasıyla iletişim kurar.
bir IP yönlendirici görevi görür (IP yönlendirici Tıklama yapılandırmasını kullanarak). Bu gösterir
Click kullanarak yönlendirme.

Scriptler içinde mevcuttur /konf/ için Tıklama dosyaları oluşturmanıza izin veren
bazı yaygın senaryolar. Kullanılan IP Yönlendirici nsclick yönlendirme.cc dan oluşturuldu
make-ip-conf.pl dosyasıdır ve ns-3-click ile çalışmak üzere biraz uyarlanmıştır.

Onaylama
Bu model şu şekilde test edilmiştir:

· Ipv4ClickRouting'in içindekileri doğrulamak için birim testleri yazılmıştır. Bu olabilir
içinde bulunan src/click/ipv4-click-routing-test.cc. Bu testler, yöntemlerin uygulanıp uygulanmadığını doğrular.
Cihaz adından kimliğe, cihaz adından IP Adresine kadar olan Ipv4ClickRouting içinde
ve aygıt adı bağlamalarından Mac Adresi beklendiği gibi çalışır.

· Örnekler, Click'i gerçek simülasyon senaryolarıyla test etmek için kullanılmıştır. Bunlar olabilir
içinde bulunan kaynak/tıklama/örnekler/. Bu testler aşağıdakileri kapsar: farklı
Click, TCP/UDP üzerindeki aktarım türleri, Click düğümlerinin iletişim kurup kuramayacağı
Click tabanlı olmayan düğümler, Click düğümlerinin Click kullanarak birbirleriyle iletişim kurup kuramayacakları
paketleri statik yönlendirme kullanarak yönlendirmek için.

· Click Csma, Wifi ve Noktadan Noktaya cihazlarla test edilmiştir. Kullanım talimatları
önceki bölümde mevcuttur.

CSMA NET CİHAZI

Bu, Csma model doxygen'i tamamlamak için CSMA NetDevice bölümüne giriştir.

Genel Bakış of the CSMA model
The ns-3 CSMA cihazı, Ethernet ruhu içinde basit bir veri yolu ağını modeller. Ona rağmen
kurabileceğiniz veya satın alabileceğiniz herhangi bir gerçek fiziksel ağı modellemez, bazı
çok kullanışlı işlevsellik.

Genellikle bir veri yolu ağı denilince akla Ethernet veya IEEE 802.3 gelir. Ethernet
CSMA/CD'yi kullanır (Üssel olarak Çarpışma Algılamalı Taşıyıcı Sense Çoklu Erişim
paylaşılan iletim ortamı için rekabet etmek için artan geri çekilme. bu ns-3 CSMA cihazı
küresel olarak kullanılabilir kanalın doğasını kullanarak bu sürecin yalnızca bir bölümünü modeller
anlık (ışıktan daha hızlı) taşıyıcı algısı ve öncelik tabanlı çarpışma sağlamak
"kaçınma." Ethernet anlamında çarpışmalar asla olmaz ve bu nedenle ns-3 CSMA cihazı
çarpışma algılamayı modellemez ve sürmekte olan herhangi bir aktarım "sıkışmaz".

CSMA tabaka Model
Katmanlı iletişimi tanımlamak için kullanılan bir dizi kural vardır.
Literatürde ve ders kitaplarında mimariler. En yaygın katmanlama modeli,
ISO yedi katman referans modeli. Bu görünümde CsmaNetDevice ve CsmaChannel çifti
en alttaki iki katmanı kaplar -- fiziksel (birinci katman) ve veri bağlantısında (ikinci katman)
pozisyonlar. Bir diğer önemli referans modeli, RFC 1122, "Gereksinimler
İnternet Ana Bilgisayarları için -- İletişim Katmanları." Bu görünümde CsmaNetDevice ve
CsmaChannel çifti en alt katmanı, yani bağlantı katmanını kaplar. Görünüşte de var
ders kitaplarında ve literatürde bulunan sonsuz sayıda alternatif tanım. Biz
LLC, MAC, MII'den bahseden IEEE 802 standartlarında kullanılan adlandırma kurallarını benimsemek
ve PHY katmanlama. Bu kısaltmalar şu şekilde tanımlanır:

· LLC: Mantıksal Bağlantı Kontrolü;

· MAC: Medya Erişim Kontrolü;

· MII: Medyadan Bağımsız Arayüz;

· PHY: Fiziksel Katman.

Bu durumda İyi ve MAC OSI veri bağlantısı katmanının alt katmanlarıdır ve MII ve PHY
OSI fiziksel katmanının alt katmanlarıdır.

CSMA cihazının "üst" kısmı, ağ katmanından veriye geçişi tanımlar.
bağlantı katmanı. Bu geçiş, daha yüksek katmanlar tarafından ya çağrılarak gerçekleştirilir:
CsmaNetDevice::Send veya CsmaNetDevice::SendFrom.

IEEE 802.3 standartlarının aksine, CSMA'da kesin olarak belirlenmiş bir PHY yoktur.
tel türleri, sinyaller veya pin çıkışları anlamında model. "alt" arayüzü
CsmaNetDevice görüldüğü gibi bir tür Medyadan Bağımsız Arayüz (MII) olarak düşünülebilir.
"Hızlı Ethernet" (IEEE 802.3u) spesifikasyonlarında. Bu MII arayüzü bir
CsmaChannel'da ilgili medyadan bağımsız arayüz. bulamayacaksın
10BASE-T veya 1000BASE-LX PHY eşdeğeri.

CsmaNetDevice, medyadan bağımsız bir arabirim aracılığıyla CsmaChannel'ı çağırır. Var
Yöntemi kullanarak kanala "kabloları kıpırdatmaya" ne zaman başlayacağını söylemek için tanımlanan yöntem
CsmaChannel::TransmitStart ve kanala aktarım işleminin ne zaman olduğunu söyleyen bir yöntem
yapılır ve kanal "tel" boyunca son biti yaymaya başlamalıdır:
CsmaChannel::TransmitEnd.

TransmitEnd yöntemi yürütüldüğünde, kanal tek bir tekdüze sinyal modelleyecektir.
ortamdaki yayılma gecikmesi ve paketin başlıklarını cihazların her birine iletir
pakete CsmaNetDevice::Receive yöntemiyle eklenir.

Cihaz ortamından bağımsız arayüzde "COL" e karşılık gelen bir "pin" vardır.
(çarpışma). Kanalın durumu, CsmaChannel::GetState çağrılarak algılanabilir. Her biri
cihaz, göndermeye başlamadan önce bu "pin"e bakacak ve uygun geri çekilmeyi gerçekleştirecektir.
operasyonlar gerekirse.

Düzgün bir şekilde alınan paketler, bir CsmaNetDevice aracılığıyla daha yüksek seviyelere iletilir.
geri arama mekanizması. Geri arama işlevi, üst katman tarafından başlatılır (net
aygıt bağlı) CsmaNetDevice::SetReceiveCallback kullanılarak ve "uygun" olduğunda çağrılır
paketi protokolde yukarı iletmek için ağ cihazı tarafından bir paketin alınması
yığını.

CSMA Telegram Kanal Model
CsmaChannel sınıfı, gerçek iletim ortamını modeller. için sabit bir sınır yoktur
kanala bağlı cihaz sayısı. CsmaChannel, bir veri hızı ve bir
"DataRate" ve "Delay" öznitelikleri aracılığıyla erişilebilen ışık hızı gecikmesi
sırasıyla. Kanala sağlanan veri hızı, kanal tarafından kullanılan veri hızlarını ayarlamak için kullanılır.
kanala bağlı CSMA cihazlarının verici bölümleri. başka yolu yok
cihazlarda veri hızlarını bağımsız olarak ayarlayın. Veri hızı yalnızca hesaplamak için kullanıldığından
gecikme süresi, üzerinde herhangi bir sınırlama yoktur (değeri tutan veri türü dışında)
CSMA kanallarının ve cihazlarının çalışabileceği hız; ve herhangi bir kısıtlamaya dayalı olarak hiçbir kısıtlama
PHY özellikleri.

CsmaChannel'ın üç durumu vardır, IDLE, İLETİM ve YAYILMA. Bu üç devlet
kanaldaki tüm cihazlar tarafından anlık olarak "görülür". Bununla demek istediğimiz, eğer biri
cihaz benzetilmiş bir iletimi başlatır veya bitirir, kanaldaki tüm cihazlar hemen
durumundaki değişikliğin farkındadır. Bir cihazın bir IDLE
çarpışma alanında fiziksel olarak daha uzaktaki başka bir cihaz olabilir
kanaldan diğerine yayılmayan ilişkili sinyallerle iletmeye başladı
cihazlar. Böylece CsmaChannel modelinde çarpışma algılamaya gerek kalmaz ve
hiçbir şekilde uygulanmadı.

Adından da anlaşılacağı gibi, modelin Taşıyıcı Duyusu yönüne sahibiz. Beri
simülatör tek iş parçacıklıdır, ortak kanala erişim,
simülatör. Bu, kanal için rekabet etmek için deterministik bir mekanizma sağlar. bu
kanal tahsis edildi (durumdan geçiş IDLE belirtmek İLETİM) ilk gelene
Ilk verilen esastır. Kanal her zaman üç durumlu bir süreçten geçer:

BOŞTA -> İLETİM -> YAYILMA -> BOŞTA

The İLETİM durum, kaynak ağ cihazının gerçekte olduğu süreyi modeller
teldeki sinyalleri kıpırdatmak. bu YAYILMA durum, son bitten sonraki zamanı modeller
sinyal kabloyu "uzak uca" yayarken gönderildi.

geçiş İLETİM devlet bir çağrı tarafından yönlendirilir
Paketi ileten ağ aygıtı tarafından çağrılan CsmaChannel::TransmitStart. O
bir çağrı ile iletimi sonlandırmak o cihazın sorumluluğundadır.
Geçen süreyi yansıtan uygun simülasyon zamanında CsmaChannel::TransmitEnd
tüm paket bitlerini kabloya koymak için. TransmitEnd çağrıldığında, kanal
tek bir ışık hızı gecikmesine karşılık gelen bir olayı programlar. Bu gecikme için geçerlidir
kanaldaki tüm net cihazlar aynı şekilde. İçinde simetrik bir merkez düşünebilirsiniz.
paket bitleri merkezi bir konuma yayılır ve ardından eşit uzunluktaki kabloları
kanaldaki diğer cihazlar. Tek "ışık hızı" gecikmesi daha sonra şuna karşılık gelir:
için gereken süre: 1) kablosu aracılığıyla bir CsmaNetDevice cihazından yayılan bir sinyal
göbeğe; artı 2) hub'ın paketi bir bağlantı noktasından dışarı iletmesi için geçen süre; artı
3) söz konusu sinyalin hedef ağa yayılması için geçen süre
cihaz.

CsmaChannel, paketin tüm cihazlara iletilmesi için bir yayın ortamı modeller
yayılım süresinin sonunda kanalda (kaynak dahil). O
gönderen cihazın bir paket alıp almadığını belirleme sorumluluğu
kanal üzerinden yayın.

CsmaChannel aşağıdaki Nitelikleri sağlar:

· DataRate: Bağlı cihazlarda paket iletimi için bit hızı;

· Gecikme: Kanal için ışık iletim gecikmesinin hızı.

CSMA Ağ cihaz Model
CSMA ağ cihazı bir şekilde bir Ethernet cihazı gibi görünür. CsmaNetDevice
aşağıdaki Nitelikleri sağlar:

· Adres: Cihazın Mac48Adresi;

· SendEnable: Doğruysa paket iletimini etkinleştirin;

· ReceiveEnable: Doğruysa paket alımını etkinleştirin;

· EncapsulationMode: Kullanılacak bağlantı katmanı kapsülleme türü;

· RxErrorModel: Alma hatası modeli;

· TxQueue: Cihaz tarafından kullanılan iletim kuyruğu;

· InterframeGap: İsteğe bağlı "kareler" arasında bekleme süresi;

· Rx: Alınan paketler için bir izleme kaynağı;

· Drop: Bırakılan paketler için bir izleme kaynağı.

CsmaNetDevice, bir "alma hatası modeli" atamasını destekler. Bu bir
Bağlantıdaki veri bozulmasını simüle etmek için kullanılan ErrorModel nesnesi.

CsmaNetDevice üzerinden gönderilen paketler, her zaman iletim kuyruğu aracılığıyla şu adrese yönlendirilir:
ağ üzerinden gönderilen paketler için bir izleme kancası sağlar. Bu iletim kuyruğu ayarlanabilir
(öznitelik aracılığıyla) farklı kuyruk stratejilerini modellemek için.

Ayrıca özniteliğe göre yapılandırılabilir, cihaz tarafından kullanılan kapsülleme yöntemidir. Her
paket, hedef ve kaynak MAC adreslerini içeren bir EthernetHeader alır ve
bir uzunluk/tür alanı. Her paket ayrıca FCS'yi içeren bir EthernetTrailer alır.
Paketteki veriler farklı şekillerde kapsüllenebilir.

Varsayılan olarak veya "EncapsulationMode" özniteliği "Dix" olarak ayarlandığında, kapsülleme
DEC, Intel, Xerox standardına göre. Buna bazen EthernetII çerçeveleme denir
ve tanıdık hedef MAC, kaynak MAC, EtherType, Data, CRC formatıdır.

"EncapsulationMode" özniteliği "Llc" olarak ayarlanmışsa, kapsülleme LLC SNAP tarafından yapılır. İçinde
bu durumda, EtherType'ı (IP veya ARP) içeren bir SNAP başlığı eklenir.

Uygulanan diğer kapsülleme modları IP_ARP'dir ("EncapsulationMode"u "IpArp" olarak ayarlayın)
Ethernet başlığının uzunluk tipinin protokol numarasını aldığı
paket; veya ETHERNET_V1 ("EncapsulationMode"u "EthernetV1" olarak ayarlayın) uzunluk tipi
Ethernet başlığının paketinin uzunluğunu alır. Bir "Ham" kapsülleme modu
tanımlanmış ancak uygulanmamış -- RAW modunun kullanılması bir onayla sonuçlanır.

Bir kanaldaki tüm ağ cihazlarının aşağıdakiler için aynı kapsülleme moduna ayarlanması gerektiğini unutmayın.
doğru sonuçlar. Kapsülleme modu alıcıda algılanmaz.

CsmaNetDevice, aşağıdaki durumlarda yürütülen rastgele bir üstel geri alma algoritması uygular:
kanalın meşgul olduğu belirlendi (İLETİM or YAYILMA) cihaz istediğinde
yaymaya başlamak için. Bu, pow'a (2, yeniden deneme) kadar rastgele bir gecikmeyle sonuçlanır - 1
yeniden denemeden önce mikrosaniye. Varsayılan maksimum yeniden deneme sayısı 1000'dir.

kullanma the CsmaNetDevice
CSMA ağ cihazları ve kanalları tipik olarak aşağıdakiler kullanılarak oluşturulur ve yapılandırılır:
ilişkili CsmaYardımcı nesne. Çeşitli ns-3 cihaz yardımcıları genellikle benzer şekilde çalışır
şekilde ve bunların kullanımı örnek programlarımızın çoğunda görülmektedir.

İlgilenilen kavramsal model, içine ağ bağladığınız çıplak bir bilgisayar "kabuğu" modelidir.
cihazlar. Çıplak bilgisayarlar bir kullanılarak oluşturulur DüğümKonteyner yardımcı. sen sadece bunu sor
kadar çok bilgisayar oluşturmak için yardımcı (biz onlara Nodes ) ağınızda ihtiyacınız olduğu gibi:

NodeContainer csmaNodes;
csmaNodes.Create (nCsmaNodes);

Düğümlerinizi aldıktan sonra, bir örnek oluşturmanız gerekir. CsmaYardımcı ve istediğiniz özellikleri ayarlayın
değiştirmek isteyebilir.:

CsmaYardımcı csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
csma.SetChannelAttribute ("Gecikme", TimeValue (NanoSaniye (6560)));

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

Nitelikler ayarlandıktan sonra geriye sadece cihazları oluşturmak ve bunları yüklemektir.
gerekli düğümler ve cihazları bir CSMA kanalı kullanarak birbirine bağlamak için. Biz ne zaman
net cihazları oluşturun, gelecekte kullanmanıza izin vermek için bunları bir kapsayıcıya ekliyoruz.
Bunların hepsi sadece bir satır kod alır.:

NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

Sonuçlanabileceğinden, bu Nitelikleri değiştirmeyi dikkatlice düşünmenizi öneririz.
kullanıcıları şaşırtan davranış. Buna izin veriyoruz çünkü esnekliğin önemli olduğuna inanıyoruz.
Nitelikleri değiştirmenin olası şaşırtıcı etkisine bir örnek olarak, şunu göz önünde bulundurun:
Aşağıdaki:

Mtu Niteliği, cihaza Maksimum İletim Birimini gösterir. bu boyut
cihazın gönderebileceği en büyük Protokol Veri Biriminin (PDU) Bu Özellik varsayılanları
1500 bayta kadardır ve RFC 894'te bulunan bir sayıya karşılık gelir, "
IP Datagramlarının Ethernet Ağları Üzerinden İletimi." Sayı aslında şuradan türetilmiştir:
10Base5 (tam özellikli Ethernet) ağları için maksimum paket boyutu -- 1518 bayt. Eğer sen
Ethernet paketleri (18 bayt) için DIX kapsülleme ek yükünü çıkarın, sonunda bir
1500 baytlık maksimum olası veri boyutu (MTU). Ayrıca, IEEE için MTU'nun
802.3 ağları 1492 bayttır. Bunun nedeni, LLC/SNAP kapsüllemesinin fazladan sekiz
pakete ek yük baytları. Her iki durumda da, temel ağ donanımı
1518 bayt ile sınırlıdır, ancak kapsülleme farklı olduğundan MTU farklıdır.

Mtu Özniteliğini 1500 baytta bırakır ve kapsülleme modu Özniteliğini değiştirirse
Llc için sonuç, LLC/SNAP ile 1500 bayt PDU'ları kapsülleyen bir ağ olacaktır.
1526 baytlık paketlerle sonuçlanan çerçeveleme. Bu, birçok ağda yasa dışı olurdu, ancak
bunu yapmanıza izin veriyoruz. Bu, oldukça ince bir şekilde yansıtmayan bir simülasyonla sonuçlanır.
gerçek bir cihaz 1526 baytlık bir paket göndermekten kaçınacağından beklediğiniz şey.

Ayrıca jumbo çerçeveler (1500 < MTU <= 9000 bayt) ve süper jumbo (MTU > 9000) vardır.
bayt) IEEE tarafından resmi olarak onaylanmayan ancak bazılarında mevcut olan çerçeveler
yüksek hızlı (Gigabit) ağlar ve NIC'ler. CSMA modelinde,
kapsülleme modu Dix'e ve Mtu'yu 64000 bayta ayarlayın - ilişkili bir
CsmaChannel DataRate saniyede 10 megabitte bırakıldı (kesinlikle Gigabit Ethernet değil).
Bu, esasen, 1980'lerin vampir vuruşlu tarzından yapılmış bir Ethernet anahtarını modelleyecektir.
Süper jumbo datagramları destekleyen 10Base5 ağları;
şimdiye kadar yapılmıştı, yapılmaması da muhtemel değil; ancak sizin için oldukça kolay
Yapılandır.

CSMA'nın gerçekte neyi modellediğine ve nasıl modellediğine ilişkin varsayımlar konusunda dikkatli olun.
yapılandırma (Nitelikler), gerçeklikten önemli ölçüde uzaklaşmanıza izin verebilir.

CSMA İzleme
Gibi tüm ns-3 CSMA Modeli bir dizi izleme kaynağı sağlar. Bu izler
kaynaklar kendi özel izleme kodunuzu kullanarak bağlanabilir veya yardımcımızı kullanabilirsiniz
belirttiğiniz cihazlarda etkinleştirilecek izlemeyi düzenlemek için işlevler.

Üst seviye (MAC) Çengeller
Ağ cihazında izleme açısından, birkaç ilginç nokta var.
izleme kancaları takmak için. Diğer simülatörlerden miras alınan bir kural, paketlerin
bağlı ağlara iletilmek üzere hedeflenen, tek bir "iletim kuyruğundan" geçer.
ağ cihazı. Paket akışında bu noktada izleme kancaları sağlıyoruz;
(soyut olarak) yalnızca ağdan veri bağlantı katmanına bir geçişe ve onları çağırın
toplu olarak cihaz MAC kancaları.

İletim için CSMA net cihazına bir paket gönderildiğinde, her zaman
sırayı ilet. CsmaNetDevice içindeki iletim kuyruğu, Queue'dan devralır ve bu nedenle
üç izleme kaynağını devralır:

· Bir Enqueue işlem kaynağı (bkz. Queue::m_traceEnqueue);

· Bir Dequeue işlem kaynağı (bkz. Queue::m_traceDequeue);

· Bir Bırakma işlemi kaynağı (bkz. Kuyruk::m_traceDrop).

CsmaNetDevice için üst düzey (MAC) izleme kancaları, aslında tam olarak bu üç
cihazın tek iletim kuyruğundaki izleme kaynakları.

m_traceEnqueue olayı, iletim kuyruğuna bir paket yerleştirildiğinde tetiklenir. Bu
CsmaNetDevice::Send veya CsmaNetDevice::SendFrom'un bir
bir paketi iletim için kuyruğa almak için daha yüksek katman.

m_traceDequeue olayı, iletim kuyruğundan bir paket kaldırıldığında tetiklenir.
İletim kuyruğundan gelen kuyruklar üç durumda gerçekleşebilir: 1) Temelde yatan
CsmaNetDevice::Send veya CsmaNetDevice::SendFrom çağrıldığında kanal boşta, bir
paket iletim kuyruğundan çıkarılır ve hemen iletilir; 2) Eğer
altta yatan kanal boştaysa, bir paket kuyruğa alınabilir ve anında iletilebilir.
iletim tam kesmesine çok benzeyen dahili TransmitCompleteEvent
servis rutini; veya 3) bir zaman aşımı varsa, rastgele üstel geri çekilme işleyicisinden
algılandı.

Durum (3), bir paketin gönderilemiyorsa iletim kuyruğundan çıkarıldığını ifade eder.
geri çekilme kurallarına göre iletilir. Bunun olacağını anlamak önemlidir.
Kuyruğa Alınmış paket olarak görünür ve paketin hatalı olduğunu varsaymak kolaydır.
iletim kuyruğundan geçtiği için iletilir. Aslında, bir paket aslında
bu durumda net cihaz tarafından düştü. Bu davranışın nedeni,
Queue Drop olayının tanımı. m_traceDrop olayı, tanımı gereği, bir
paket dolu olduğu için iletim kuyruğunda kuyruğa alınamaz. Bu olay sadece patlar
kuyruk doluysa ve CsmaChannel'ın olduğunu belirtmek için bu olayı aşırı yüklemezsek
"tam."

Alt düzey (PHY) Çengeller
Üst seviyedeki iz kancalarına benzer şekilde, alt kısımda da iz kancaları mevcuttur.
net aygıtın seviyeleri. Bunlara PHY kancaları diyoruz. Bu olaylar cihazdan ateşlenir
doğrudan CsmaChannel ile konuşan yöntemler.

İzleme kaynağı m_dropTrace, aygıt tarafından bırakılan bir paketi belirtmek için çağrılır.
Bu iki durumda olur: Birincisi, ağ cihazının alma tarafı etkinleştirilmemişse
(bkz. CsmaNetDevice::m_receiveEnable ve ilişkili "ReceiveEnable" özniteliği).

m_dropTrace ayrıca, bir paketin bozuk olarak atıldığını belirtmek için kullanılır.
alma hatası modeli kullanılır (bkz. CsmaNetDevice::m_receiveErrorModel ve ilgili
"ReceiveErrorModel" özniteliği).

Diğer düşük seviyeli izleme kaynağı, kabul edilen bir paketin alınmasıyla tetiklenir (bkz.
CsmaNetDevice::m_rxTrace). Yayın için hedeflenmişse bir paket kabul edilir.
adresi, bir çok noktaya yayın adresi veya net cihaza atanan MAC adresi.

ÖZET
ns3 CSMA modeli, Ethernet benzeri bir ağın basitleştirilmiş bir modelidir. bir
Carrier-Sense işlevi ve paylaşılan bir ortama Çoklu Erişime izin verir. O değil
ortamın durumunun herkes arasında anında paylaşılması anlamında fiziksel
cihazlar. Bu, bu modelde herhangi bir çarpışma tespitinin gerekli olmadığı ve hiçbirinin gerekli olmadığı anlamına gelir.
uygulanmaktadır. Zaten ortamda bir paket "sıkışması" asla olmayacak. Erişim
paylaşılan kanal, simülatör tarafından belirlendiği üzere ilk gelenin kullanım önceliği vardır
zamanlayıcı. Küresel duruma bakılarak kanalın meşgul olduğu belirlenirse, bir
rastgele üstel geri çekilme gerçekleştirilir ve yeniden denenir.

Ns-3 Nitelikleri, cihazda çeşitli parametreleri ayarlamak için bir mekanizma sağlar ve
adresler, kapsülleme modları ve hata modeli seçimi gibi kanal. İzleme kancaları
alışılagelmiş şekilde, bir vericiye karşılık gelen bir dizi üst seviye kanca ile sağlanır.
kuyruk ve ASCII izlemede kullanılır; ve ayrıca pcap izlemede kullanılan bir dizi alt seviye kanca.

ns-3 CsmaChannel ve CsmaNetDevice herhangi bir ağı modellemese de,
inşa edebilir veya satın alabilir, bize bazı yararlı işlevler sağlar. Malısın,
ancak bunun açıkça Ethernet veya herhangi bir IEEE 802.3 çeşidi olmadığını anlayın.
ilginç alt küme.

VERİ KOLEKSİYON

Bu bölümde, aşağıdakileri sağlayan ns-3 Veri Toplama Çerçevesi (DCF) açıklanmaktadır.
simülatördeki modeller tarafından oluşturulan verileri elde etme, çevrimiçi olarak gerçekleştirme yetenekleri
indirgeme ve veri işleme ve ham veya dönüştürülmüş verileri çeşitli çıktılara dönüştürme
biçimleri.

Çerçeve şu anda herhangi bir harici sisteme dayanmayan bağımsız ns-3 çalıştırmalarını desteklemektedir.
program yürütme kontrolü. DCF tarafından sağlanan nesneler, ns-3 iz
Veri işlemeyi etkinleştirmek için kaynaklar.

Sınıfların kaynak kodu dizinde bulunur kaynak/istatistikler.

Bu bölüm aşağıdaki gibi düzenlenmiştir. İlk olarak, mimariye genel bir bakış
sunuldu. Daha sonra bu sınıfların yardımcıları sunulur; bu ilk tedavi
birçok kullanım durumu için veri toplama çerçevesinin temel kullanımına izin vermelidir. Kullanıcılar
Mevcut yardımcıların kapsamı dışında çıktı üretmek isteyen veya oluşturmak isteyenler
kendi veri toplama nesneleri, devam eden bölümün geri kalanını okumalıdır.
tüm temel DCF nesne türleri hakkında ayrıntılı bilgi verir ve düşük seviyeli kodlama sağlar
örnekleri.

Tasarım
DCF üç temel sınıftan oluşur:

· Sonda olan simülasyon verilerinin çıktısını enstrümantal etmek ve kontrol etmek için bir mekanizmadır.
ilginç olayları izlemek için kullanılır. Bir veya daha fazla şeklinde çıktı üretir. ns-3
iz kaynakları. Prob nesneleri bir veya daha fazla ize bağlanır lavabolar (aranan
Koleksiyonerler), numuneleri çevrimiçi olarak işleyen ve bunları çıktı için hazırlayan.

· Kolektör bir veya daha fazla Probe nesnesi tarafından oluşturulan verileri tüketir. gerçekleştirir
normalleştirme, indirgeme ve hesaplama gibi veriler üzerinde dönüşümler
temel istatistikler. Toplayıcı nesneler, doğrudan çıktısı olan verileri üretmez.
ns-3 çalıştırma; bunun yerine, verileri aşağı akış olarak adlandırılan başka bir nesne türüne verirler.
Toplayıcı, bu işlevi yerine getirir. Tipik olarak, Toplayıcılar verilerini
koleksiyoncuların seri olarak zincirlenmesine izin veren iz kaynakları formu da.

· Toplayıcı bir Araştırma ve Toplayıcı ağı tarafından toplanan verilerin son noktasıdır.
Toplayıcının temel sorumluluğu, verileri ve bunlara karşılık gelen verileri düzenlemektir.
meta verileri, düz metin dosyaları, elektronik tablo dosyaları veya
veritabanları.

Bu sınıfların üçü de kendilerini dinamik olarak açma veya kapatma yeteneği sağlar.
bir simülasyon boyunca.

herhangi bir bağımsız ns-3 DCF kullanan simülasyon çalıştırması tipik olarak en az bir
yukarıdaki üç sınıfın her birinin örneği.
[image] Veri Toplama Çerçevesine genel bakış.UNINDENT

Veri işlemenin genel akışı şu şekilde gösterilmektedir: Veri Koleksiyon iskelet genel bakış.
Sol tarafta bir koşu ns-3 simülasyon tasvir edilmiştir. çalıştırma sırasında
simülasyon, veriler, izleme kaynakları veya başka yollarla modeller tarafından sağlanır.
Diyagram, verileri almak için sondaların bu izleme kaynaklarına bağlanabileceğini gösterir.
zaman uyumsuz olarak veya problar veri için yoklayabilir. Veriler daha sonra bir toplayıcı nesneye iletilir
bu verileri dönüştürür. Son olarak, çıkışlara bir toplayıcı bağlanabilir.
toplayıcı, araziler, dosyalar veya veritabanları oluşturmak için.
[image] Veri Toplama Çerçevesi toplama.UNINDENT

Yukarıdaki şeklin bir varyasyonu şurada verilmiştir: Veri Koleksiyon iskelet toplanma.
Bu ikinci şekil, DCF nesnelerinin bir şekilde birbirine zincirlenebileceğini göstermektedir.
aşağı akış nesnelerinin birden fazla yukarı akış nesnesinden girdi alması. Figür
kavramsal olarak, birden fazla probun tek bir proba beslenen çıktı üretebileceğini gösterir.
kolektör; örnek olarak, iki sayacın oranını veren bir toplayıcı
tipik olarak her bir sayaç verisini ayrı sondalardan alır. Birden fazla koleksiyoncu da
(adından da anlaşılacağı gibi) bir dizi veri toplayabilen tek bir toplayıcıya besleme
tek bir arsa, dosya veya veritabanına dahil edilmek üzere akışlar.

Veri Koleksiyon Yardımcılar
Veri toplama çerçevesinin tam esnekliği, ara bağlantı ile sağlanır.
sondalar, toplayıcılar ve toplayıcılar. Tüm bu ara bağlantıların gerçekleştirilmesi,
kullanıcı programlarında birçok yapılandırma ifadesi. Kullanım kolaylığı için, en yaygın olanlardan bazıları
işlemler yardımcı işlevlerde birleştirilebilir ve kapsüllenebilir. Ek olarak, bazı
içeren ifadeler ns-3 izleme kaynakları, sınırlamalar nedeniyle Python bağlamalarına sahip değildir.
bağlamalar.

Veri Koleksiyon Yardımcılar Genel Bakış
Bu bölümde, aşağıdakiler için oluşturulmuş bazı yardımcı sınıflara genel bir bakış sunuyoruz.
bazı yaygın kullanım durumları için veri toplama çerçevesinin yapılandırmasını kolaylaştırır. bu
yardımcılar, kullanıcıların C++'larında yalnızca birkaç ifadeyle ortak işlemler oluşturmasına izin verir veya
Python programları. Ancak, bu kullanım kolaylığı önemli ölçüde daha az maliyetle gelir.
düşük seviyeli konfigürasyonun sağlayabileceğinden daha fazla esneklik ve açıkça kodlama ihtiyacı
yardımcılara yeni Prob türleri için destek (aşağıda açıklanan bir sorunu çözmek için).

Mevcut yardımcılara vurgu, verileri dıştan sıralamaktır. ns-3 kaynakları izlemek
gnuplot grafikleri veya metin dosyaları, yüksek derecede çıktı özelleştirmesi veya istatistiksel olmadan
işleme (başlangıçta). Ayrıca, kullanım, mevcut prob tipleriyle sınırlıdır.
ns-3. Bu belgenin sonraki bölümlerinde, yeni oluşturma hakkında daha ayrıntılı bilgi verilecektir.
Prob türleri ve ayrıca Probları, Toplayıcıları ve Toplayıcıları birbirine bağlamayla ilgili ayrıntılar
özel düzenlemelerde.

Bugüne kadar iki Veri Toplama yardımcısı uygulandı:

· GnuplotYardımcısı

· Dosya Yardımcısı

GnuplotYardımcısı
GnuplotHelper, gnuplots yapmak için kullanılan çıktı dosyalarını üretmek için bir yardımcı sınıftır. bu
genel amaç, kullanıcıların dışa aktarılan verilerden hızlı bir şekilde grafikler oluşturmasını sağlamaktır.
in ns-3 iz kaynakları. Varsayılan olarak, minimum miktarda veri dönüşümü gerçekleştirilir;
amaç, olabildiğince az (varsayılan) yapılandırma ifadesi içeren grafikler oluşturmaktır.
mümkün.

GnuplotYardımcısı Genel Bakış
GnuplotHelper, simülasyonun sonunda 3 farklı dosya oluşturacaktır:

· Boşlukla ayrılmış bir gnuplot veri dosyası

· Bir gnuplot kontrol dosyası

· Gnuplot'u oluşturmak için bir kabuk betiği

Grafikler oluşturmak için gereken iki yapılandırma ifadesi vardır. İlk
ifadesi grafiği yapılandırır (dosya adı, başlık, göstergeler ve çıktı türü; çıktının
belirtilmemişse varsayılanları PNG olarak yazın):

void ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::string &başlık,
const std::string &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

İkinci ifade, ilgili izleme kaynağını bağlar:

void PlotProbe (const std::string &typeId,
const std::string &yol,
const std::string &probeTraceSource,
const std::string &başlık);

Argümanlar aşağıdaki gibidir:

· typeId: ns-3 Probun Tip Kimliği

· yol: içindeki yol ns-3 bir veya daha fazla izleme kaynağına yapılandırma ad alanı

· probeTraceSource: Probun hangi çıktısının (kendisi bir izleme kaynağının) çizilmesi gerektiği

· başlık: Veri kümeleri ile ilişkilendirilecek başlık (gnuplot açıklamasında)

Yukarıdaki PlotProbe'un bir varyantı, kontrol eden beşinci bir isteğe bağlı argüman belirtmektir.
arsada anahtar (efsane) nereye yerleştirilir.

Tamamen işlenmiş bir örnek ( yedinci.cc) aşağıda gösterilmiştir:

// gnuplot yardımcısını oluşturun.
GnuplotHelper arsaHelper;

// Grafiği yapılandırın.
// Grafiği yapılandırın. İlk argüman dosya adı önekidir.
// oluşturulan çıktı dosyaları için. İkinci, üçüncü ve dördüncü
// argümanlar sırasıyla çizim başlığı, x ekseni ve y ekseni etiketleridir
plotHelper.ConfigurePlot ("yedinci paket bayt sayısı",
"Paket Bayt Sayısı ve Zaman",
"Zaman (Saniye)",
"Paket Bayt Sayısı",
"png");

// Araştırma türünü, izleme kaynağı yolunu (yapılandırma ad alanında) belirtin ve
// çizim için çıktı izleme kaynağı ("OutputBytes") araştırın. dördüncü argüman
// grafik üzerindeki veri serisi etiketinin adını belirtir. Son
// argüman, anahtarın nereye yerleştirilmesi gerektiğini belirterek çizimi biçimlendirir.
arsaHelper.PlotProbe (probeType,
izYol,
"Çıktı Baytları",
"Paket Bayt Sayısı",
GnuplotAggregator::KEY_BELOW);

Bu örnekte, prob tipi ve izyolu aşağıdaki gibidir (IPv4 için):

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

probeType, bu yardımcının çalışması için bir anahtar parametredir. Bu TypeId kayıtlı olmalıdır
sistemde ve Sondanın izleme havuzundaki imza, izlemeninkiyle eşleşmelidir.
Bağlandığı kaynak. Prob türleri, bir dizi veri türü için önceden tanımlanmıştır
tekabül ns-3 izlenen değerler ve aşağıdakiler gibi birkaç başka izleme kaynağı imzası için
'Tx' izleme kaynağı ns3::Ipv4L3Protokol sınıf.

Belirtilen izleme kaynağı yolunun joker karakterler içerebileceğini unutmayın. Bu durumda çoklu
veri kümeleri tek bir grafik üzerine çizilir; eşleşen her yol için bir tane.

Üretilen ana çıktı üç dosya olacaktır:

yedinci-paket-byte-count.dat
yedinci-paket-byte-count.plt
yedinci-paket-byte-count.sh

Bu noktada, kullanıcılar daha fazla özelleştirme için .plt dosyasını elle düzenleyebilir veya
sadece gnuplot üzerinden çalıştırın. Koşma sh yedinci-paket-byte-count.sh sadece arsa çalıştırır
aşağıda gösterildiği gibi gnuplot aracılığıyla.
[image] 2-D Gnuplot Seventh.cc tarafından düzenlendi Örnek..UNINDENT

Anahtar unsurların (efsane, başlık, lejant yerleşimi, xlabel, ylabel,
ve veri yolu) tümü arsaya yerleştirilir. İki maç olduğu için
sağlanan yapılandırma yolu, iki veri serisi gösterilir:

· Paket Bayt Sayısı-0, /NodeList/0/$ns3::Ipv4L3Protocol/Tx'e karşılık gelir

· Paket Bayt Sayısı-1, /NodeList/1/$ns3::Ipv4L3Protocol/Tx'e karşılık gelir

GnuplotYardımcısı YapılandırmaPlot
GnuplotHelper'ın YapılandırmaPlot() işlevi, grafikleri yapılandırmak için kullanılabilir.

Aşağıdaki prototipe sahiptir:

void ConfigurePlot (const std::string &outputFileNameWithoutExtension,
const std::string &başlık,
const std::string &xLegend,
const std::string &yLegend,
const std::string &terminalType = ".png");

Aşağıdaki argümanlara sahiptir:

┌──────────────────────────────────────────── ────────────────┐
│Argüman │ Açıklama │
├──────────────────────────────────────────── ────────────────┤
│outputFileNameWithoutExtension │ gnuplot ile ilgili dosyaların adı │
│ │ uzantısız yaz. │
├──────────────────────────────────────────── ────────────────┤
│title │ için kullanılacak başlık dizesini çizin │
│ │ bu arsa. │
└──────────────────────────────────────────── ────────────────┘

│xLegend │ x yatay efsanesi │
│ │ ekseni. │
├──────────────────────────────────────────── ────────────────┤
│yLegend │ y dikeyinin efsanesi │
│ │ ekseni. │
├──────────────────────────────────────────── ────────────────┤
│terminalType │ │ için terminal tipi ayar dizesi
│ │ çıktı. Varsayılan terminal │
│ │ türü "png"dir. │
└──────────────────────────────────────────── ────────────────┘

GnuplotHelper'ın YapılandırmaPlot() işlev bunun için çizimle ilgili parametreleri yapılandırır
adında boşlukla ayrılmış bir gnuplot veri dosyası oluşturacak şekilde gnuplot yardımcısı
outputFileNameWithoutExtension + ".dat", adlı bir gnuplot kontrol dosyası
outputFileNameWithoutExtension + ".plt" ve adlı gnuplot'u oluşturmak için bir kabuk betiği
outputFileNameWithoutExtension + ".sh".

Bu işlevin nasıl kullanılacağına ilişkin bir örnek, yedinci.cc yukarıda açıklanan kod
nerede kullanıldı:

plotHelper.ConfigurePlot ("yedinci paket bayt sayısı",
"Paket Bayt Sayısı ve Zaman",
"Zaman (Saniye)",
"Paket Bayt Sayısı",
"png");

GnuplotYardımcısı Arsa Araştırması
GnuplotHelper'ın Arsa Araştırması() işlevi, problar tarafından oluşturulan değerleri çizmek için kullanılabilir.

Aşağıdaki prototipe sahiptir:

void PlotProbe (const std::string &typeId,
const std::string &yol,
const std::string &probeTraceSource,
const std::string &başlık,
enum GnuplotAggregator::KeyLocation keyLocation = GnuplotAggregator::KEY_INSIDE);

Aşağıdaki argümanlara sahiptir:

┌──────────────────────────────────────────── ───┐
│Argüman │ Açıklama │
├──────────────────────────────────────────── ───┤
│typeId │ Probun tip kimliği │
│ │ bu yardımcı tarafından oluşturuldu. │
├──────────────────────────────────────────── ───┤
│yol │ İzlemeye erişmek için yapılandırma yolu │
│ │ kaynak. │
├──────────────────────────────────────────── ───┤
│probeTraceSource │ Prob izleme kaynağı │
│ │ erişim. │
├──────────────────────────────────────────── ───┤
│başlık │ İlişkilendirilecek başlık │
│ │ bu veri seti │
├──────────────────────────────────────────── ───┤
│keyLocation │ Anahtarın │ içindeki konumu
│ │ arsa. Varsayılan konum │
│ │ içeride. │
└──────────────────────────────────────────── ───┘

GnuplotHelper'ın Arsa Araştırması() işlevi, çengel tarafından oluşturulan bir veri kümesini çizer. ns-3
yardımcı tarafından oluşturulan bir araştırmayla kaynağı izleme ve ardından
probTraceSource. Veri kümesi sağlanan başlığa sahip olacak ve aşağıdakilerden oluşacaktır:
her zaman damgasında 'newValue'.

Bir joker karakter olduğu için yapılandırma yolunda sistemde birden fazla eşleşme varsa, o zaman
her maç için bir veri seti çizilecektir. Veri kümesi başlıkları,
yapılandırma yolundaki joker karakterlerin her biri için boşluklarla ayrılmış eşleşen karakterler. İçin
örneğin, önerilen veri kümesi başlığı "bayt" dizesiyse ve iki joker karakter varsa
yolda, "bytes-0 0" veya "bytes-12 9" gibi veri kümesi başlıkları şu şekilde mümkün olacaktır:
çizilen veri kümeleri için etiketler.

Bu işlevin nasıl kullanılacağına ilişkin bir örnek, yedinci.cc yukarıda açıklanan kod
kullanıldığı yerde (değişken ikame ile):

plotHelper.PlotProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Çıktı Baytları",
"Paket Bayt Sayısı",
GnuplotAggregator::KEY_BELOW);

Diğer Örnekler
gnuplot Yardımcı Örnek E-posta
Bundan biraz daha basit bir örnek yedinci.cc örnek şurada bulunabilir
src/stats/examples/gnuplot-helper-example.cc. Aşağıdaki 2-D gnuplot kullanılarak oluşturuldu
örnek.
[image] 2-D Gnuplot Oluşturan gnuplot-helper-example.cc Örnek..UNINDENT

Bu örnekte, sayacını bir değere göre artıran bir Emitter nesnesi vardır.
Poisson işlemi ve ardından sayacın değerini bir izleme kaynağı olarak yayar.

Ptr yayıcı = CreateObject ();
İsimler::Add ("/İsimler/Yayıcı", verici);

Aşağıda kullanılan yolda joker karakter olmadığından, yalnızca 1 veri akışının olduğunu unutmayın.
arsada çizilmiştir. Grafikteki bu tek veri akışı basitçe "Yayıcı Sayısı" olarak etiketlenir,
Yolda joker karakterler olup olmadığını göreceğiniz gibi ekstra sonekler olmadan.

// gnuplot yardımcısını oluşturun.
GnuplotHelper arsaHelper;

// Grafiği yapılandırın.
plotHelper.ConfigurePlot ("gnuplot-yardımcı-örnek",
"Yayıcı Sayımlarına Karşı Zaman",
"Zaman (Saniye)",
"Yayıcı Sayısı",
"png");

// Prob tarafından üretilen değerleri çizin. Sağladığımız yol
// izin kaynağının belirsizliğini gidermeye yardımcı olur.
plotHelper.PlotProbe ("ns3::Uinteger32Probe",
"/İsimler/Yayıcı/Sayaç",
"Çıktı",
"Yayıcı Sayısı",
GnuplotAggregator::KEY_INSIDE);

Dosya Yardımcısı
FileHelper, veri değerlerini bir dosyaya koymak için kullanılan bir yardımcı sınıftır. Genel amaç
kullanıcıların dışa aktarılan verilerden hızla biçimlendirilmiş metin dosyaları oluşturmasını sağlamak için
in ns-3 iz kaynakları. Varsayılan olarak, minimum miktarda veri dönüşümü gerçekleştirilir;
amaç, olabildiğince az (varsayılan) yapılandırma ifadesi içeren dosyalar oluşturmaktır.
mümkün.

Dosya Yardımcısı Genel Bakış
FileHelper, simülasyonun sonunda 1 veya daha fazla metin dosyası oluşturacaktır.

FileHelper, 4 farklı türde metin dosyası oluşturabilir:

· Biçimlendirilmiş

· Boşluk ayrılmış (varsayılan)

· Virgülle ayrılmış

· Sekme ayrılmış

Biçimlendirilmiş dosyalar, C-tarzı biçim dizgilerini ve sprintf() işlevini kullanarak bunların çıktısını alır.
Yazılmakta olan dosyadaki değerler.

Adlandırılmış 2 sütun biçimlendirilmiş değer içeren aşağıdaki metin dosyası
yedinci paket bayt sayısı-0.txt eklenmiş daha fazla yeni kod kullanılarak oluşturuldu.
orijinal ns-3 Eğitim örneğinin kodu. Bu dosyanın yalnızca ilk 10 satırı gösteriliyor
kısalık için burada.

Zaman (Saniye) = 1.000e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.004e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.004e+00 Paket Bayt Sayısı = 576
Zaman (Saniye) = 1.009e+00 Paket Bayt Sayısı = 576
Zaman (Saniye) = 1.009e+00 Paket Bayt Sayısı = 576
Zaman (Saniye) = 1.015e+00 Paket Bayt Sayısı = 512
Zaman (Saniye) = 1.017e+00 Paket Bayt Sayısı = 576
Zaman (Saniye) = 1.017e+00 Paket Bayt Sayısı = 544
Zaman (Saniye) = 1.025e+00 Paket Bayt Sayısı = 576
Zaman (Saniye) = 1.025e+00 Paket Bayt Sayısı = 544

Kendi ID’n ile mağazalarını oluştur

Adlandırılmış 2 sütun biçimlendirilmiş değer içeren aşağıdaki farklı metin dosyası
yedinci paket bayt sayısı-1.txt eklenmiş olan aynı yeni kod kullanılarak da oluşturuldu.
Orijinal ns-3 Eğitim örneğinin kodu. Bu dosyanın yalnızca ilk 10 satırı gösteriliyor
kısalık için burada.

Zaman (Saniye) = 1.002e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.007e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.013e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.020e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.028e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.036e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.045e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.053e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.061e+00 Paket Bayt Sayısı = 40
Zaman (Saniye) = 1.069e+00 Paket Bayt Sayısı = 40

Kendi ID’n ile mağazalarını oluştur

İki metin dosyasını oluşturmak için eklenen yeni kod aşağıdadır. hakkında daha fazla bilgi
bu API daha sonraki bir bölümde ele alınacaktır.

Yolda joker karakter için 2 eşleşme olduğundan, 2 ayrı metin dosyası olduğunu unutmayın.
Biz oluşturduk. "seventh-packet-byte-count-0.txt" adlı ilk metin dosyası,
"0" ile değiştirilen "*" ile joker karakter eşleşmesine karşılık gelir. İkinci metin dosyası,
"yedinci-paket-bayt-sayısı-1.txt" olarak adlandırılan, joker karakter eşleşmesine karşılık gelir.
"*", "1" ile değiştirilir. Ayrıca, işlev çağrısının YazmaSondası() verecek
Joker karakterler içeren bir yol için eşleşme yoksa hata mesajı.

// Dosya yardımcısını oluşturun.
DosyaYardımcısı dosyaYardımcısı;

// Yazılacak dosyayı yapılandırın.
fileHelper.ConfigureFile ("yedinci paket bayt sayısı",
FileAggregator::FORMATTED);

// Bu biçimlendirilmiş çıktı dosyası için etiketleri ayarlayın.
fileHelper.Set2dFormat ("Zaman (Saniye) = %.3e\tPacket Bayt Sayısı = %.0f");

// Prob tarafından üretilen değerleri yazın.
fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Çıkış Baytları");

Dosya Yardımcısı Yapılandırma Dosyası
FileHelper'ın Yapılandırma Dosyası() işlevi, metin dosyalarını yapılandırmak için kullanılabilir.

Aşağıdaki prototipe sahiptir:

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

Aşağıdaki argümanlara sahiptir:

┌──────────────────────────────────────────── ────────────────┐
│Argüman │ Açıklama │
├──────────────────────────────────────────── ────────────────┤
│outputFileNameWithoutExtension │ Yazılacak çıktı dosyasının adı │
│ │ uzantısız. │
├──────────────────────────────────────────── ────────────────┤
│fileType │ Yazılacak dosya türü. │
│ │ varsayılan dosya türü boşluktur │
│ │ ayrıldı. │
└──────────────────────────────────────────── ────────────────┘

FileHelper'ın Yapılandırma Dosyası() işlevi, metin dosyasıyla ilgili parametreleri yapılandırır.
dosya yardımcısı, böylece outputFileNameWithoutExtension plus adlı bir dosya oluşturacaktır.
joker karakter eşleşmelerinden olası ekstra bilgiler artı değerler olarak yazdırılan ".txt"
fileType tarafından belirtilir. Varsayılan dosya türü boşlukla ayrılmıştır.

Bu işlevin nasıl kullanılacağına ilişkin bir örnek, yedinci.cc yukarıda açıklanan kod
nerede kullanıldı:

fileHelper.ConfigureFile ("yedinci paket bayt sayısı",
FileAggregator::FORMATTED);

Dosya Yardımcısı Yazma Sondası
FileHelper'ın YazmaSondası() fonksiyon, problar tarafından üretilen değerleri yazmak için kullanılabilir.
metin dosyaları.

Aşağıdaki prototipe sahiptir:

void WriteProbe (const std::string &typeId,
const std::string &yol,
const std::string &probeTraceSource);

Aşağıdaki argümanlara sahiptir:

┌──────────────────────────────────────────── ───┐
│Argüman │ Açıklama │
├──────────────────────────────────────────── ───┤
│typeId │ Olacak probun tip kimliği │
│ │ oluşturuldu. │
├──────────────────────────────────────────── ───┤
│yol │ İzlemeye erişmek için yapılandırma yolu │
│ │ kaynak. │
├──────────────────────────────────────────── ───┤
│probeTraceSource │ Prob izleme kaynağı │
│ │ erişim. │
└──────────────────────────────────────────── ───┘

FileHelper'ın YazmaSondası() işlevi, çengel tarafından oluşturulan çıktı metin dosyaları oluşturur.
Yardımcı tarafından oluşturulan bir prob ile ns-3 izleme kaynağı ve ardından değerlerin
probTraceSource. Çıktı dosyası adları, üye değişkeninde depolanan metne sahip olacaktır.
m_outputFileNameWithoutExtension artı ".txt" ve her birinde 'newValue'dan oluşacaktır
zaman damgası.

Bir joker karakter olduğu için yapılandırma yolunda sistemde birden fazla eşleşme varsa, o zaman
her eşleşme için bir çıktı dosyası oluşturulacaktır. Çıktı dosyası adları şunları içerecektir:
m_outputFileNameWithoutExtension içindeki metin artı her biri için eşleşen karakterler
tirelerle ayrılmış yapılandırma yolunda joker karakterler ve ".txt". Örneğin, eğer değer
m_outputFileNameWithoutExtension içinde "paket bayt sayısı" dizesidir ve iki tane vardır
yoldaki joker karakterleri, ardından "packet-byte-count-0-0.txt" gibi dosya adlarının çıktısını alın veya
Oluşturulacak dosyalar için "packet-byte-count-12-9.txt" isimlendirmesi mümkün olacaktır.

Bu işlevin nasıl kullanılacağına ilişkin bir örnek, yedinci.cc yukarıda açıklanan kod
nerede kullanıldı:

fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"Çıkış Baytları");

Diğer Örnekler
fileto Yardımcı Örnek E-posta
Bundan biraz daha basit bir örnek yedinci.cc örnek şurada bulunabilir
src/stats/examples/dosya-yardımcı-ornek.cc. Bu örnek yalnızca FileHelper'ı kullanır.

Adlandırılmış 2 sütun biçimlendirilmiş değer içeren aşağıdaki metin dosyası dosya-yardımcı-örnek.txt
örnek kullanılarak oluşturulmuştur. için bu dosyanın yalnızca ilk 10 satırı burada gösterilir.
kısalık.

Zaman (Saniye) = 0.203 Sayı = 1
Zaman (Saniye) = 0.702 Sayı = 2
Zaman (Saniye) = 1.404 Sayı = 3
Zaman (Saniye) = 2.368 Sayı = 4
Zaman (Saniye) = 3.364 Sayı = 5
Zaman (Saniye) = 3.579 Sayı = 6
Zaman (Saniye) = 5.873 Sayı = 7
Zaman (Saniye) = 6.410 Sayı = 8
Zaman (Saniye) = 6.472 Sayı = 9
Kendi ID’n ile mağazalarını oluştur

Bu örnekte, sayacını bir değere göre artıran bir Emitter nesnesi vardır.
Poisson işlemi ve ardından sayacın değerini bir izleme kaynağı olarak yayar.

Ptr yayıcı = CreateObject ();
İsimler::Add ("/İsimler/Yayıcı", verici);

Aşağıda kullanılan yolda joker karakter olmadığından, yalnızca 1 metin dosyasının olduğunu unutmayın.
yaratıldı. Bu tek metin dosyası, fazladan bir şey olmadan basitçe "file-helper-example.txt" olarak adlandırılır.
Yolda joker karakterler olup olmadığını göreceğiniz gibi son ekler.

// Dosya yardımcısını oluşturun.
DosyaYardımcısı dosyaYardımcısı;

// Yazılacak dosyayı yapılandırın.
fileHelper.ConfigureFile ("dosya yardımcı örneği",
FileAggregator::FORMATTED);

// Bu biçimlendirilmiş çıktı dosyası için etiketleri ayarlayın.
fileHelper.Set2dFormat ("Zaman (Saniye) = %.3e\tCount = %.0f");

// Prob tarafından üretilen değerleri yazın. Biz yol
// izlemenin kaynağının belirsizliğini gidermeye yardımcı olur.
fileHelper.WriteProbe ("ns3::Uinteger32Probe",
"/İsimler/Yayıcı/Sayaç",
"Çıktı");

kapsam ve Sınırlamalar
Şu anda yalnızca bu Sondalar uygulandı ve GnuplotHelper'a bağlandı ve
FileHelper'a:

· Boole Probu

· Çift Sonda

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· Zaman Sondası

· Paket Sondası

· ApplicationPacketProbe

· Ipv4PacketProbe

Bu nedenle, bu Sondalar, kullanılabilecek tek TypeId'lerdir. Arsa Araştırması() ve
YazmaSondası().

Sonraki birkaç bölümde, temel nesne türlerinin (Sonda, Toplayıcı,
ve Toplayıcı) daha ayrıntılı olarak ve kullanılarak nasıl birbirine bağlanabileceklerini gösterin.
alt düzey API.

Sondalar
Bu bölüm, Probe sınıfı tarafından bir kullanıcıya sağlanan işlevlerin ayrıntılarını verir. ns-3
simülasyon ve bunların bir programda nasıl kodlanacağına dair örnekler verir. Bu bölüm içindir
ile simülasyonlar geliştirmekle ilgilenen kullanıcılar ns-3 araçları ve Verileri kullanma
Probe sınıfının bir parçası olduğu Collection Framework ile veri çıktısı üretmek için
onların simülasyonunun sonuçları.

Sonda Genel Bakış
Bir Probe nesnesinin, simülasyondan değerleri olan bir değişkene bağlanması gerekiyor.
deney boyunca kullanıcıyla alakalıdır. Sonda ne olduğunu kaydedecek
simülasyon boyunca değişken tarafından üstlenilen değerler ve bu verileri başka bir
Veri Toplama Çerçevesi üyesi. Bu bölümün kapsamı dışında olmakla birlikte
Prob çıktısını ürettikten sonra ne olacağını tartışın, şunu söylemek yeterlidir:
simülasyonun sonunda, kullanıcı hangi değerlerin olduğu hakkında ayrıntılı bilgiye sahip olacaktır.
simülasyon sırasında incelenen değişkenin içinde saklanır.

Tipik olarak, bir Prob, bir ns-3 iz kaynağı. Bu şekilde, her zaman
izleme kaynağı yeni bir değeri dışa aktarır, Sonda değeri tüketir (ve aşağı akış yönünde dışa aktarır)
kendi izleme kaynağı aracılığıyla başka bir nesneye).

Sonda, iz kaynakları üzerinde bir tür filtre olarak düşünülebilir. ana nedenleri
muhtemelen doğrudan bir izleme kaynağına bağlanmak yerine bir Sondaya bağlanmak aşağıdaki gibidir:

· Simülasyon sırasında problar dinamik olarak açılıp kapatılabilir. Olanak vermek()
ve Devre dışı bırakmak(). Örneğin, veri çıkışı, işlem sırasında kapatılabilir.
simülasyon ısınma aşaması.

· Sondalar, daha karmaşık verilerden değerleri çıkarmak için veriler üzerinde işlemler gerçekleştirebilir.
yapılar; örneğin, alınan bir ns3::Packet'ten paket boyutu değerinin çıktısını almak.

· Sondalar, ns3::Config ad alanına bir ad kaydeder (kullanarak İsimler::Ekle ()) böylece diğer
nesneler onlara atıfta bulunabilir.

· Sondalar, birinin bir Sondayı ada göre manipüle etmesine izin veren statik bir yöntem sağlar, örneğin
ns2measure'da ne yapılır [Cic06]

Stat::put ("my_metric", ID, örnek);

Yukarıdaki ns3measure kodunun ns-2 eşdeğeri, örn.

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

Yaratılış
Soyut bir temel olduğu için bir Probe temel sınıf nesnesinin oluşturulamayacağını unutmayın.
sınıf, yani uygulanmayan saf sanal işlevlere sahiptir. bir nesne
Probe sınıfının bir alt sınıfı olan DoubleProbe tipi, göstermek için burada oluşturulacaktır.
ne yapılması gerekiyor.

Biri, akıllı işaretçi sınıfını (Ptr) kullanarak dinamik bellekte bir DoubleProbe bildirir. ). İle
Akıllı işaretçilerle dinamik bellekte bir DoubleProbe oluşturun, yalnızca
ns-3 yöntem Nesne Oluştur():

Ptr myprobe = CreateObject ();

Yukarıdaki bildirim, öznitelikleri için varsayılan değerleri kullanarak DoubleProbes oluşturur.
DoubleProbe sınıfında dört öznitelik vardır; temel sınıf nesnesinde iki
DataCollectionObject ve Probe temel sınıfındaki iki tane:

· "Ad" (DataCollectionObject), bir StringValue

· "Etkin" (DataCollectionObject), bir BooleanValue

· "Başlat" (Sonda), bir TimeValue

· "Dur" (Sonda), bir TimeValue

Aşağıdaki yöntemi kullanarak nesne oluşturma sırasında bu tür öznitelikleri ayarlayabilirsiniz:

Ptr myprobe = CreateObjectWithAttributes (
"Ad", StringValue ("sondam"),
"Etkin", BooleanValue (yanlış),
"Başlat", TimeValue (Saniye (100.0)),
"Dur", TimeValue (Saniye (1000.0)));

Başlatma ve Durdurma, Sondanın hareket aralığını belirleyen Zaman değişkenleridir. bu
Prob, yalnızca Simülasyonun geçerli saati bunun içindeyse verileri çıkaracaktır.
Aralık. Dur için 0 saniyelik özel zaman değeri bu özelliği devre dışı bırakacaktır (örn.
tüm simülasyon için Probu açık tutun). Etkin, Probu açan veya
kapalıdır ve Araştırmanın verileri dışa aktarabilmesi için true olarak ayarlanmalıdır. Ad, nesnenin adıdır
DCF çerçevesinde.

İçe ve ihracat veri
ns-3 izleme kaynakları güçlü bir şekilde yazılmıştır, bu nedenle Probları bir ize bağlama mekanizmaları
kaynak ve verileri dışa aktarmak için alt sınıflarına aittir. Örneğin, varsayılan
dağıtımı ns-3 bir ize bağlanmak için tasarlanmış bir DoubleProbe sınıfı sağlar
çift ​​değeri dışa aktaran kaynak. DoubleProbe'un çalışmasını daha sonra detaylandıracağız ve
sonra diğer Probe sınıflarının kullanıcı tarafından nasıl tanımlanabileceğini tartışın.

Çift Sonda Genel Bakış
DoubleProbe, çift değerli bir ns-3 izleme kaynağı ve kendisi bir
farklı çift değerli ns-3 iz kaynağı.

Aşağıdaki kod, çizilen src/stats/examples/double-probe-example.cc, temel gösterir
DoubleProbe'u bir Sayacı araştırdığı bir simülasyona yerleştirme işlemleri
bir emitör nesnesi (sınıf Yayıcı) tarafından dışa aktarılır.

Ptr yayıcı = CreateObject ();
İsimler::Add ("/İsimler/Yayıcı", verici);
Kendi ID’n ile mağazalarını oluştur

Ptr prob1 = CreateObject ();

// Probu emitörün Sayacına bağlayın
bool bağlı = probe1->ConnectByObject ("Sayaç", verici);

Aşağıdaki kod, aynı emitör nesnesi tarafından dışa aktarılan aynı Sayacı araştırıyor. Bu
Ancak DoubleProbe, yapılandırma ad alanında bir yol kullanıyor.
bağ. Vericinin, sonra yapılandırma ad alanına kendisini kaydettiğini unutmayın.
yaratıldı; aksi takdirde ConnectByPath çalışmaz.

Ptr prob2 = CreateObject ();

// Not, burada hiçbir dönüş değeri kontrol edilmez
probe2->ConnectByPath ("/İsimler/Verici/Sayaç");

Aşağıda gösterilen, gösterilen bir sonraki DoubleProbe, içindeki yolunu kullanarak değerini ayarlayacaktır.
yapılandırma ad alanı. Bu sefer DoubleProbe'un kendisini
oluşturulduktan sonra yapılandırma ad alanı.

Ptr prob3 = CreateObject ();
probe3->AyarAdı ("Statik ErişimliProbe");

// config veritabanına eklemeliyiz
Names::Add ("/Names/Probes", prob3->GetName (), prob3);

Yayıcının Count() işlevi artık bu DoubleProbe değerini şu şekilde ayarlayabilir:
aşağıdaki gibidir:

geçersiz
Verici:: Sayım (geçersiz)
{
Kendi ID’n ile mağazalarını oluştur
m_sayıcı += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
Kendi ID’n ile mağazalarını oluştur
}

Yukarıdaki örnek, Sondayı çağıran kodun nasıl açık bir koda sahip olması gerekmediğini gösterir.
Araştırmaya başvurur, ancak değer ayarını Yapılandırma ad alanı aracılığıyla yönlendirebilir.
Bu, işlevsellik açısından şuna benzer: Durum :: Koy ns2measure paper tarafından tanıtılan yöntem
[Cic06] ve kullanıcıların geçici olarak aşağıdakiler gibi Prob ifadeleri eklemesine izin verir: printf ifadeleri
mevcut içinde ns-3 modeller. DoubleProbe'u bu modda kullanabilmek için
bunun gibi bir örnek, 2 şey gerekliydi:

1. istatistik modülü başlık dosyası örnek .cc dosyasına dahil edildi

2. örnek, wscript dosyasındaki stats modülüne bağımlı hale getirildi.

Başka yerlere başka Sondalar eklemek için benzer şeyler yapılması gerekir. ns-3
kod tabanı.

DoubleProbe değerleri, DoubleProbe::SetValue() işlevi kullanılarak da ayarlanabilir,
DoubleProbe değerleri işlev kullanılarak elde edilebilirken
DoubleProbe::GetValue().

DoubleProbe, "Çıktı" izleme kaynağındaki çift değerleri dışa aktarır; aşağı akış nesnesi
buna aşağıdaki gibi bir izleme havuzunu (NotifyViaProbe) bağlayabilir:

bağlı = prob1->TraceConnect ("Çıktı", prob1->GetName (), MakeCallback (&NotifyViaProbe));

Diğer sondalar
DoubleProbe'un yanı sıra aşağıdaki Problar da mevcuttur:

· Uinteger8Probe bir ns-3 bir uint8_t dışa aktaran izleme kaynağı.

· Uinteger16Probe bir ns-3 bir uint16_t dışa aktaran izleme kaynağı.

· Uinteger32Probe bir ns-3 bir uint32_t dışa aktaran izleme kaynağı.

· PacketProbe bir ns-3 bir paketi dışa aktaran izleme kaynağı.

· ApplicationPacketProbe bir ns-3 bir paketi ve bir soketi dışa aktaran izleme kaynağı
adres.

· Ipv4PacketProbe bir ns-3 bir paketi, bir IPv4 nesnesini dışa aktaran izleme kaynağı ve
bir arayüz.

Oluşturma yeni Sonda türleri
Yeni bir Prob tipi oluşturmak için aşağıdaki adımları uygulamanız gerekir:

· Yeni Probe sınıfınızın Probe temel sınıfından türetildiğinden emin olun.

· Yeni Probe sınıfınızın aşağıdakilerden miras aldığı saf sanal işlevlerin olduğundan emin olun.
Prob temel sınıfı uygulanır.

· Türüne en yakın izleme kaynağı kullanan mevcut bir Probe sınıfını bulun.
Probunuzun kullanacağı iz kaynağı türü.

· Mevcut Probe sınıfının başlık dosyasını (.h) ve uygulama dosyasını (.cc) ikiye kopyalayın
yeni Probunuzla eşleşen adlara sahip yeni dosyalar.

· Kopyalanan dosyalardaki türleri, argümanları ve değişkenleri uygun olanlarla değiştirin.
Probunuz için yazın.

· Kodu derlemek ve istediğiniz gibi davranmak için gerekli değişiklikleri yapın
gibi.

Örnekler
Burada iki örnek ayrıntılı olarak tartışılacaktır:

· Çift Sonda Örneği

· IPv4 Paket Grafiği Örneği

Çift Sonda Örnek E-posta
Çift sonda örneği daha önce tartışılmıştı. Örnek program bulunabilir
in src/stats/examples/double-probe-example.cc. Bu programda neler olduğunu özetlemek gerekirse,
Poisson sürecine göre artan bir sayacı dışa aktaran bir emitör var.
Özellikle, veri yaymanın iki yolu gösterilmiştir:

1. bir Sondaya bağlı izlenen bir değişken aracılığıyla:

izlenen değer m_counter; // normalde bu tamsayı tipi olurdu

2. değeri ikinci bir Sondaya gönderilen bir sayaç aracılığıyla, adı ile atıfta bulunulur.
Yapılandırma sistemi:

geçersiz
Verici:: Sayım (geçersiz)
{
NS_LOG_FUNCTION (bu);
NS_LOG_DEBUG ("Sayma " << Simulator::Now ().GetSeconds ());
m_sayıcı += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
Simulator::Schedule (Saniye (m_var->GetValue ())), &Emitter::Count, this);
}

Sondaya daha dikkatli bakalım. Problar değerlerini çoklu olarak alabilir
yollar:

1. Sondanın izleme kaynağına doğrudan erişmesi ve ona bir izleme havuzu bağlamasıyla

2. Prob, yapılandırma ad alanı aracılığıyla izleme kaynağına erişerek ve bir
ona batmanın izini sür

3. Arama kodu ile Prob'u açıkça çağırarak Değer Ayarla() yöntem

4. arama koduyla açıkça arama DeğerByYolunu Ayarla
("/path/through/Config/namespace", ...)

İlk iki tekniğin en yaygın olması bekleniyor. Ayrıca örnekte,
tipik olarak yapıldığı gibi, normal bir geri arama işlevinin takılması gösterilir. ns-3. Bu
geri arama işlevi, bir Sonda nesnesi ile ilişkili değil. Bu duruma aşağıda 0) diyeceğiz.

// Bu, ham bir işlevi izleme kaynağına bağlamayı test eden bir işlevdir
geçersiz
NotifyViaTraceSource (std::string bağlamı, çift eskiVal, çift yeniVal)
{
NS_LOG_DEBUG ("bağlam: " << bağlam << " eski " << eskiDeğer << " yeni " << yeniDeğer);
}

İlk olarak, emitörün ayarlanması gerekir:

Ptr yayıcı = CreateObject ();
İsimler::Add ("/İsimler/Yayıcı", verici);

// Verici nesnesi bir ns-3 düğümüyle ilişkili değil, bu nedenle
// otomatik olarak başlamaz, bu yüzden bunu kendimiz yapmalıyız
Simulator::Schedule (Saniye (0.0), &Verici::Başlat, yayıcı);

Çeşitli DoubleProbe'lar, aşağıda gösterildiği gibi örnekteki emitör ile etkileşime girer.

Durum 0):

// Aşağıdaki, prob olmadan tipik işlevselliği gösterir
// (bir izleme kaynağına bir havuz işlevi bağlayın)
//
bağlı = emiter->TraceConnect ("Sayaç", "örnek bağlam", MakeCallback (&NotifyViaTraceSource));
NS_ASSERT_MSG (bağlı, "İzleme kaynağı bağlı değil");

dava 1):

//
// Probe1 doğrudan Verici izleme kaynak nesnesine bağlanacak
//

// prob1, Verici izleme kaynağına bağlanacak
Ptr prob1 = CreateObject ();
// sondanın adı, izlemede bağlamı olarak kullanılabilir
probe1->SetName ("ObjectProbe");

// Probu emitörün Sayacına bağlayın
bağlı = prob1->ConnectByObject ("Sayaç", verici);
NS_ASSERT_MSG (bağlı, "İzleme kaynağı prob1'e bağlı değil");

dava 2):

//
// Probe2, Emitter izleme kaynak nesnesine şu şekilde bağlanacaktır:
// Config veritabanında yol adıyla erişim
//

// Başka bir benzer araştırma oluştur; bu, bir Yapılandırma yolu aracılığıyla bağlanacaktır
Ptr prob2 = CreateObject ();
probe2->SetName ("PathProbe");

// Not, burada hiçbir dönüş değeri kontrol edilmez
probe2->ConnectByPath ("/İsimler/Verici/Sayaç");

durum 4) (durum 3 bu örnekte gösterilmemiştir):

//
// Prob3, emitör tarafından doğrudan
// statik yöntem SetValueByPath().
//
Ptr prob3 = CreateObject ();
probe3->AyarAdı ("Statik ErişimliProbe");
// config veritabanına eklemeliyiz
Names::Add ("/Names/Probes", prob3->GetName (), prob3);

Ve son olarak, örnek, çıktı üretmek için probların nasıl bağlanabileceğini gösterir:

// Probun kendisi çıktı üretmelidir. Sağladığımız bağlam
// bu araştırma için (bu durumda, araştırma adı) belirsizliği gidermeye yardımcı olacaktır
// izlemenin kaynağı
bağlı = probe3->TraceConnect ("Çıkış",
"/Adlar/Sondalar/Statik Erişimli Araştırma/Çıktı",
MakeCallback (&NotifyViaProbe));
NS_ASSERT_MSG (bağlı, "İz kaynağı .. prob3 Çıkışına bağlı değil");

Aşağıdaki geri arama, açıklama amacıyla bu örnekte Sondaya bağlanmıştır;
normalde, Sonda bir Collector nesnesine bağlanır.

// Bu, onu prob çıkışına bağlamayı test eden bir fonksiyondur
geçersiz
NotifyViaProbe (std::string bağlamı, çift eskiVal, çift yeniVal)
{
NS_LOG_DEBUG ("bağlam: " << bağlam << " eski " << eskiDeğer << " yeni " << yeniDeğer);
}

IPv4 Paket Arsa Örnek E-posta
IPv4 paket çizim örneği, beşinci.cc örneğine dayanmaktadır. ns-3 öğretici. O
bulunabilir src/stats/examples/ipv4-packet-plot-example.cc.

düğüm 0 düğüm 1
+----------------+ +-----------------+
| ns-3 TCP | | ns-3 TCP |
+----------------+ +-----------------+
| 10.1.1.1 | | 10.1.1.2 |
+----------------+ +-----------------+
| noktadan noktaya | | noktadan noktaya |
+----------------+ +-----------------+
| |
------------------------------------+

Prob'ların değerleri paketten çıkarabileceğini gösterdiği için, sadece Probe'a bakacağız.
yapılar (bu durumda paketler) ve bu değerleri izleme kaynağı çıktıları olarak rapor edin.
aynı tür verileri geçmekten daha iyidir.

Bu örneğin belgelerinde daha sonra açıklanacak olan başka yönleri de vardır.
Dışa aktarılan iki veri türü paketin kendisidir (Çıktı) ve bir sayı
paketteki bayt sayısı (Çıktı Baytları).

TipKimliği
Ipv4PacketProbe::GetTypeId ()
{
statik TypeId tid = TypeId ("ns3::Ipv4PacketProbe")
.SetParent ()
.Yapıcı Ekle ()
.AddTraceSource ("Çıktı",
"Paket artı IPv4 nesnesi ve bu araştırma için çıktı görevi gören arabirimi",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_output))
.AddTraceSource ("OutputBytes",
"Paketteki bayt sayısı",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_outputBytes))
;
dönüş tid;
}

Sondanın izleme havuzu bir paket aldığında, Sonda etkinleştirilirse, çıkış verir
paket onun üzerinde Çıktı izleme kaynağı, ancak aynı zamanda üzerindeki bayt sayısını da çıkaracaktır.
Çıktı Baytları iz kaynağı.

geçersiz
Ipv4PacketProbe::TraceSink (Ptr paket, Ptr ipv4, uint4_t arayüzü)
{
NS_LOG_FUNCTION (bu << paket << ipv4 << arabirimi);
if (Etkinleştirildi ())
{
m_packet = paket;
m_ipv4 = ipv4;
m_interface = arayüz;
m_output (paket, ipv4, arayüz);

uint32_t packageSizeNew = paket->GetSize();
m_outputBytes (m_packetSizeOld, packageSizeNew);
m_packetSizeOld = packageSizeNew;
}
}

Referanslar
[Cic06]
Claudio Cicconetti, Enzo Mingozzi, Giovanni Stea, "Bir Entegre Çerçeve
ns2 ile Etkili Veri Toplama ve İstatistiksel Analiz Sağlama, Workshop on
ns-2 (WNS2), Pisa, İtalya, Ekim 2006.

Koleksiyonerler
Bu bölüm, Collector tarafından sağlanan işlevlerin ayrıntılarını veren bir yer tutucudur.
bir sınıfa ns-3 simülasyon ve bunların bir programda nasıl kodlanacağına dair örnekler verir.

Not: ns-3.18 itibariyle, Collectors hala geliştirme aşamasındadır ve henüz bir parçası olarak sağlanmamıştır.
çerçevenin.

toplayıcılar
Bu bölüm, Toplayıcı sınıfı tarafından bir kullanıcıya sağlanan işlevlerin ayrıntılarını verir. ns-3
simülasyon. Bu bölüm, aşağıdakilerle simülasyonlar geliştirmekle ilgilenen kullanıcılar içindir.
ns-3 araçları ve Toplayıcı sınıfının bir parçası olduğu Veri Toplama Çerçevesini kullanma
parçası, simülasyon sonuçlarıyla veri çıktısı üretmek.

Toplayıcı Genel Bakış
Bir Toplayıcı nesnesinin, bir veya daha fazla izleme kaynağına bağlanması gerekir.
girdi almak. Toplayıcılar, ağ tarafından toplanan verilerin son noktasıdır.
Simülasyon sırasında Problar ve Toplayıcılar. Bunları almak Toplayıcının işidir.
değerleri ve bunları düz metin dosyaları gibi nihai çıktı biçimlerine dönüştürmek,
elektronik tablo dosyaları, grafikler veya veritabanları.

Tipik olarak, bir toplayıcı bir veya daha fazla Toplayıcıya bağlıdır. Bu şekilde, her zaman
Toplayıcıların izleme kaynakları yeni değerleri dışa aktarır, Toplayıcı değeri işleyebilir ve böylece
sonra veri değerlerinin bulunacağı nihai çıktı formatında kullanılabileceği
simülasyon.

Toplayıcılar hakkında aşağıdakilere dikkat edin:

· Toplayıcılar, çağrılarla simülasyon sırasında dinamik olarak açılıp kapatılabilir.
Olanak vermek() ve Devre dışı bırakmak(). Örneğin, verilerin toplanması sırasında kapatılabilir.
simülasyon ısınma aşaması, yani bu değerler finale dahil edilmeyecektir.
çıkış ortamı

· Toplayıcılar, geri aramalar yoluyla Toplayıcılardan veri alır. Bir Koleksiyoncu ilişkilendirildiğinde
bir toplayıcıya, Toplayıcının izini oluşturmak için TraceConnect çağrısı yapılır
geri arama olarak lavabo yöntemi.

Bugüne kadar iki Toplayıcı uygulandı:

· GnuplotToplayıcı

· Dosya Toplayıcı

GnuplotToplayıcı
GnuplotAggregator, gnuplots yapmak için kullanılan çıktı dosyalarını üretir.

GnuplotAggregator, simülasyonun sonunda 3 farklı dosya oluşturacaktır:

· Boşlukla ayrılmış bir gnuplot veri dosyası

· Bir gnuplot kontrol dosyası

· Gnuplot'u oluşturmak için bir kabuk betiği

Yaratılış
Ne yapılması gerektiğini göstermek için burada GnuplotAggregator türünde bir nesne oluşturulacaktır.

Biri, akıllı işaretçi sınıfını kullanarak dinamik bellekte bir GnuplotAggregator bildirir
(Ptr ). Akıllı işaretçilerle dinamik bellekte bir GnuplotAggregator oluşturmak için
araması gerekiyor ns-3 yöntem Nesne Oluştur(). Aşağıdaki kod gelen
src/stats/examples/gnuplot-toplayıcı-example.cc bunun nasıl yapılacağını gösterir:

string fileNameWithoutExtension = "gnuplot-toplayıcı";

// Bir toplayıcı oluşturun.
Ptr toplayıcı =
CreateObject (fileNameWithoutExtension);

Yapıcı için ilk argüman, fileNameWithoutExtension, dosyanın adıdır.
gnuplot ile ilgili dosyaları hiçbir uzantı olmadan yazabilirsiniz. Bu GnuplotAggregator bir
"gnuplot-aggregator.dat" adlı boşlukla ayrılmış gnuplot veri dosyası, bir gnuplot kontrol dosyası
"gnuplot-aggregator.plt" adlı ve + adlı gnuplot'u oluşturmak için bir kabuk betiği
"gnuplot-aggregator.sh".

Oluşturulan gnuplot, anahtarına 4 farklı konumda sahip olabilir:

· Anahtar yok

· Arsa içindeki anahtar (varsayılan)

· Arsa üzerinde anahtar

· Arsanın altındaki anahtar

Aşağıdaki gnuplot anahtar konumu numaralandırma değerlerinin anahtarın konumunu belirtmesine izin verilir:

enum AnahtarKonumu {
ANAHTAR YOK,
KEY_INSIDE,
KEY_YUKARIDA,
KEY_BELOW
};

İçerideki varsayılan konumun yerine aşağıdaki anahtarın olması istendiyse, o zaman
aşağıdakileri yapabilirsin.

toplayıcı->SetKeyLocation(GnuplotAggregator::KEY_BELOW);

Örnekler
Bir örnek burada ayrıntılı olarak tartışılacaktır:

· Gnuplot Toplayıcı Örneği

gnuplot Toplayıcı Örnek E-posta
GnuplotAggregator'ı çalıştıran bir örnek şurada bulunabilir:
src/stats/examples/gnuplot-toplayıcı-example.cc.

Aşağıdaki 2-D gnuplot, örnek kullanılarak oluşturulmuştur.
[image] 2-D Gnuplot Oluşturan gnuplot-aggregator-example.cc Örnek..UNINDENT

Örnekteki bu kod, tartışıldığı gibi GnuplotAggregator'ın nasıl oluşturulacağını gösterir.
yukarıdaki.

geçersiz Create2dPlot ()
{
namespace std kullanarak;

string fileNameWithoutExtension = "gnuplot-toplayıcı";
string plotTitle = "Gnuplot Toplayıcı Grafiği";
string plotXAxisHeading = "Zaman (saniye)";
string plotYAxisHeading = "Çift Değerler";
string plotDatasetLabel = "Veri Değerleri";
string datasetContext = "Veri Kümesi/Bağlam/Dize";

// Bir toplayıcı oluşturun.
Ptr toplayıcı =
CreateObject (fileNameWithoutExtension);

2 boyutlu veri kümesi dahil olmak üzere çeşitli GnuplotAggregator öznitelikleri ayarlanır.
çizildi.

// Toplayıcının özelliklerini ayarlayın.
toplayıcı->SetTerminal ("png");
toplayıcı->SetTitle (plotTitle);
toplayıcı->SetLegend (plotXAxisHeading, plotYAxisHeading);

// Toplayıcıya bir veri seti ekleyin.
toplayıcı->Add2dDataset (datasetContext, plotDatasetLabel);

// toplayıcı açık olmalı
toplayıcı->Etkinleştir ();

Daha sonra 2-D değerleri hesaplanır ve her biri ayrı ayrı cihaza yazılır.
GnuplotAggregator kullanarak Yaz2d() fonksiyonu.

çift ​​zamanlı;
çift ​​değer;

// 2 boyutlu veri kümesini oluşturun.
için (zaman = -5.0; zaman <= +5.0; zaman += 1.0)
{
// 2 boyutlu eğriyi hesapla
//
/ / 2
// değer = zaman .
//
değer = zaman * zaman;

// Bu noktayı arsaya ekleyin.
toplayıcı->Write2d (datasetContext, zaman, değer);
}

// Toplayıcı için veri günlüğünü devre dışı bırak.
toplayıcı->Devre Dışı Bırak ();
}

Dosya Toplayıcı
FileAggregator, aldığı değerleri bir dosyaya gönderir.

FileAggregator 4 farklı türde dosya oluşturabilir:

· Biçimlendirilmiş

· Boşluk ayrılmış (varsayılan)

· Virgülle ayrılmış

· Sekme ayrılmış

Biçimlendirilmiş dosyalar, C-tarzı biçim dizgilerini ve sprintf() işlevini kullanarak bunların çıktısını alır.
Yazılmakta olan dosyadaki değerler.

Yaratılış
Ne yapılması gerektiğini göstermek için burada FileAggregator türünde bir nesne oluşturulacaktır.

Biri, akıllı işaretçi sınıfını (Ptr) kullanarak dinamik bellekte bir FileAggregator bildirir. ).
Akıllı işaretçilerle dinamik bellekte bir FileAggregator oluşturmak için, birinin araması yeterlidir
the ns-3 yöntem CreateObject. Aşağıdaki kod gelen
src/stats/examples/file-toplayıcı-example.cc bunun nasıl yapılacağını gösterir:

string fileName = "dosya-toplayıcı-biçimlendirilmiş-değerler.txt";

// Biçimlendirilmiş değerlere sahip olacak bir toplayıcı oluşturun.
Ptr toplayıcı =
CreateObject (fileName, FileAggregator::FORMATTED);

Yapıcı için ilk argüman, dosya adı, yazılacak dosyanın adıdır; en
ikinci argüman, fileType, yazılacak dosya türüdür. Bu FileAggregator bir
tarafından belirtilen şekilde yazdırılan değerleriyle birlikte "file-aggregator-formatted-values.txt" adlı dosya
fileType, yani bu durumda biçimlendirilmiş.

Aşağıdaki dosya türü numaralandırma değerlerine izin verilir:

numaralandırma Dosya Türü {
BİÇİMLENDİRİLMİŞ,
SPACE_SEPARATED,
VİRGÜLLE AYRILMIŞ,
TAB_SEPARATED
};

Örnekler
Bir örnek burada ayrıntılı olarak tartışılacaktır:

· Dosya Toplayıcı Örneği

fileto Toplayıcı Örnek E-posta
FileAggregator'ı çalıştıran bir örnek şurada bulunabilir:
src/stats/examples/file-toplayıcı-example.cc.

Virgülle ayrılmış 2 sütunlu değer içeren aşağıdaki metin dosyası,
örnek.

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

Örnekteki bu kod, FileAggregator'ın tartışıldığı gibi nasıl oluşturulacağını gösterir.
yukarıdaki.

geçersiz CreateCommaSeparatedFile ()
{
namespace std kullanarak;

string fileName = "file-toplayıcı-virgül-separated.txt";
string datasetContext = "Veri Kümesi/Bağlam/Dize";

// Bir toplayıcı oluşturun.
Ptr toplayıcı =
CreateObject (fileName, FileAggregator::COMMA_SEPARATED);

FileAggregator öznitelikleri ayarlanır.

// toplayıcı açık olmalı
toplayıcı->Etkinleştir ();

Daha sonra 2-D değerleri hesaplanır ve her biri ayrı ayrı cihaza yazılır.
kullanarak FileAggregator Yaz2d() fonksiyonu.

çift ​​zamanlı;
çift ​​değer;

// 2 boyutlu veri kümesini oluşturun.
için (zaman = -5.0; zaman <= +5.0; zaman += 1.0)
{
// 2 boyutlu eğriyi hesapla
//
/ / 2
// değer = zaman .
//
değer = zaman * zaman;

// Bu noktayı arsaya ekleyin.
toplayıcı->Write2d (datasetContext, zaman, değer);
}

// Toplayıcı için veri günlüğünü devre dışı bırak.
toplayıcı->Devre Dışı Bırak ();
}

2 sütun biçimlendirilmiş değer içeren aşağıdaki metin dosyası da
örnek.

Zaman = -5.000e+00 Değer = 25
Zaman = -4.000e+00 Değer = 16
Zaman = -3.000e+00 Değer = 9
Zaman = -2.000e+00 Değer = 4
Zaman = -1.000e+00 Değer = 1
Zaman = 0.000e+00 Değer = 0
Zaman = 1.000e+00 Değer = 1
Zaman = 2.000e+00 Değer = 4
Zaman = 3.000e+00 Değer = 9
Zaman = 4.000e+00 Değer = 16
Zaman = 5.000e+00 Değer = 25

Örnekteki bu kod, FileAggregator'ın tartışıldığı gibi nasıl oluşturulacağını gösterir.
yukarıdaki.

geçersiz CreateFormattedFile ()
{
namespace std kullanarak;

string fileName = "dosya-toplayıcı-biçimlendirilmiş-değerler.txt";
string datasetContext = "Veri Kümesi/Bağlam/Dize";

// Biçimlendirilmiş değerlere sahip olacak bir toplayıcı oluşturun.
Ptr toplayıcı =
CreateObject (fileName, FileAggregator::FORMATTED);

Kullanılacak C stili biçim dizesi de dahil olmak üzere FileAggregator öznitelikleri ayarlanır.

// Değerlerin biçimini ayarlayın.
toplayıcı->Set2dFormat ("Zaman = %.3e\tValue = %.0f");

// toplayıcı açık olmalı
toplayıcı->Etkinleştir ();

Daha sonra 2-D değerleri hesaplanır ve her biri ayrı ayrı cihaza yazılır.
kullanarak FileAggregator Yaz2d() fonksiyonu.

çift ​​zamanlı;
çift ​​değer;

// 2 boyutlu veri kümesini oluşturun.
için (zaman = -5.0; zaman <= +5.0; zaman += 1.0)
{
// 2 boyutlu eğriyi hesapla
//
/ / 2
// değer = zaman .
//
değer = zaman * zaman;

// Bu noktayı arsaya ekleyin.
toplayıcı->Write2d (datasetContext, zaman, değer);
}

// Toplayıcı için veri günlüğünü devre dışı bırak.
toplayıcı->Devre Dışı Bırak ();
}

Adaptörleri
Bu bölüm, Adapter sınıfı tarafından bir kullanıcıya sağlanan işlevlerin ayrıntılarını verir. ns-3
simülasyon. Bu bölüm, aşağıdakilerle simülasyonlar geliştirmekle ilgilenen kullanıcılar içindir.
ns-3 Araçlar ve Adapter sınıfının bir parçası olduğu Veri Toplama Çerçevesini kullanmak,
simülasyonlarının sonuçlarıyla veri çıktısı üretmek.

Not: 'adaptör' terimi aynı zamanda 'adaptör' olarak da yazılabilir; yazım hizalamasını seçtik
C++ standardı ile.

Adaptör Genel Bakış
Farklı DCF nesneleri türleri arasında bağlantı kurmak için bir Adaptör kullanılır.

Bugüne kadar bir Adaptör uygulandı:

· TimeSeriesAdaptör

Zaman Dizi Adaptör
TimeSeriesAdaptor, Probların herhangi bir şeye ihtiyaç duymadan doğrudan Toplayıcılara bağlanmasına izin verir.
Arada toplayıcı.

Uygulanan DCF yardımcılarının her ikisi de problama yapmak için TimeSeriesAdaptor'ları kullanır.
farklı türlerdeki değerler ve mevcut zamanın çıktısı artı her ikisi de dönüştürülen değer
çiftler için.

TimeSeriesAdaptor sınıfının rolü, ham değeri alan bir bağdaştırıcının rolüdür.
farklı türlerdeki verileri araştırır ve iki çift değerden oluşan bir demet verir. Birincisi bir
farklı çözünürlüklere (örneğin Saniye, Milisaniye, vb.) ayarlanabilen zaman damgası
gelecek, ancak şu anda Saniye olarak kodlanmış. İkincisi, bir
çift ​​olmayan değerden çift değere (muhtemelen hassasiyet kaybıyla).

Kapsam/Sınırlamalar
Bu bölümde, Veri Toplama Çerçevesinin kapsamı ve sınırlamaları tartışılmaktadır.

Şu anda, DCF'de yalnızca bu Sondalar uygulanmıştır:

· Boole Probu

· Çift Sonda

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· Zaman Sondası

· Paket Sondası

· ApplicationPacketProbe

· Ipv4PacketProbe

Şu anda, bir BasicStatsCollector altında olmasına rağmen DCF'de hiçbir Toplayıcı mevcut değildir.
gelişme.

Şu anda DCF'de yalnızca şu Toplayıcılar uygulanmıştır:

· GnuplotToplayıcı

· Dosya Toplayıcı

Şu anda yalnızca bu Bağdaştırıcı DCF'de uygulanmıştır:

Zaman Serisi Adaptörü.

gelecek İş
Bu bölüm, Veri Toplama Çerçevesi üzerinde gelecekte yapılacak çalışmaları tartışmaktadır.

İşte hala yapılması gereken bazı şeyler:

· Daha fazla iz kaynağı bağlayın ns-3 simülatörden daha fazla değer elde etmek için kod.

· Şu anda olduğundan daha fazla Prob türü uygulayın.

· Mevcut tek 2-D Toplayıcı BasicStatsCollector'dan daha fazlasını uygulayın.

· Daha fazla Toplayıcı uygulayın.

· Adaptörlerden daha fazlasını uygulayın.

DSDV YÖNLENDİRME

Hedef Sıralı Mesafe Vektörü (DSDV) yönlendirme protokolü proaktiftir,
Charles E. Perkins ve Pravin tarafından geliştirilen MANET'ler için tabloya dayalı yönlendirme protokolü
1994 yılında Bhagwat. Güzergah seçiminde metrik olarak atlama sayısını kullanır.

Bu model tarafından geliştirilmiştir the Esnek Ağlar araştırma Grup Kansas Üniversitesi'nde. A
bu modelle ilgili kağıt şu adreste var: Re-Tweet URL.

DSDV Yönlendirme Genel Bakış
DSDV Yönlendirme Tablosu: Her düğüm, sahip olduğu diğer tüm düğümleri listeleyen bir tablo tutacaktır.
ya doğrudan ya da bazı komşular aracılığıyla bilinir. Her düğümün tek bir girişi vardır.
yönlendirme tablosu. Giriş, düğümün bilinen son IP adresi hakkında bilgi içerecektir.
sıra numarası ve o düğüme ulaşmak için atlama sayısı. Bu ayrıntılarla birlikte tablo
ayrıca hedef düğüme ulaşmak için nexthop komşusunu takip eder, zaman damgası
o düğüm için alınan son güncelleme.

DSDV güncelleme mesajı üç alandan oluşur: Hedef Adres, Sıra Numarası ve
Atlama sayısı.

Her düğüm, DSDV güncellemelerini göndermek için 2 mekanizma kullanır. Bunlar,

1.

Periyodik Güncellemeler
Her m_periodicUpdateInterval(varsayılan:15s) sonrasında periyodik güncellemeler gönderilir.
Bu güncellemede düğüm, tüm yönlendirme tablosunu yayınlar.

2.

Tetik Güncellemeler
Tetikleyici Güncellemeler, periyodik güncellemeler arasındaki küçük güncellemelerdir. Bu güncellemeler
bir düğüm, yapısında bir değişikliğe neden olan bir DSDV paketi aldığında gönderilir.
yönlendirme tablosu. Orijinal makale, hangi değişikliğin ne zaman olacağını açıkça belirtmedi.
Tabloda bir DSDV güncellemesi gönderilmelidir. Geçerli uygulama gönderir
yönlendirme tablosundaki değişiklikten bağımsız olarak bir güncelleme çıkarır.

Güncellemeler, belirli bir düğümün metriğine göre kabul edilir. ilk faktör
Bir güncellemenin kabulünü belirleyen sıra numarasıdır. Güncellemeyi kabul etmesi gerekiyor
güncelleme mesajının sıra numarası metrikten bağımsız olarak daha yüksekse. Eğer
aynı sıra numarasına sahip güncelleme alınır, ardından en az metrikli güncelleme (hopCount)
öncelik verilir.

Son derece hareketli senaryolarda, rota dalgalanmaları olasılığı yüksektir, bu nedenle
metrikte değişiklik olan bir güncellemenin olmayacağı ağırlıklı uzlaşma süresi kavramı
komşulara duyurulur. Düğüm, yerleşmediğinden emin olmak için yerleşme zamanını bekler.
güncellemeyi göndermeden önce eski komşusundan güncellemeyi alın.

Mevcut uygulama, DSDV'nin yukarıdaki tüm özelliklerini kapsar. Akım
uygulamanın ayrıca, hiçbir yolu olmayan paketleri arabelleğe almak için bir istek kuyruğu vardır.
varış noktası. Varsayılan, hedef başına en fazla 5 paketi arabelleğe alacak şekilde ayarlanmıştır.

Referanslar
Makalenin Bağlantısı: http://portal.acm.org/citation.cfm?doid=190314.190336

DSR YÖNLENDİRME

Dinamik Kaynak Yönlendirme (DSR) protokolü, özel olarak tasarlanmış reaktif bir yönlendirme protokolüdür.
mobil düğümlerin çok sekmeli kablosuz ad hoc ağlarında kullanım için.

Bu model tarafından geliştirilmiştir the Esnek Ağlar araştırma Grup Kansas Üniversitesi'nde.

DSR Yönlendirme Genel Bakış
Bu model, Dinamik Kaynak Yönlendirme (DSR) protokolünün temel özelliklerini uygular.
Uygulamaya dayalıdır RFC 4728, RFC'de bazı uzantılar ve değişikliklerle
özellikleri.

DSR, isteğe bağlı bir davranışla çalışır. Bu nedenle, DSR modelimiz tüm paketleri arabelleğe alırken bir
rota istek paketi (RREQ) dağıtılır. Bir paket arabelleği uyguluyoruz
dsr-rsendbuff.cc. Paket kuyruğu, eski paketlerin çöp toplama işlemini gerçekleştirir ve
kuyruk boyutu sınırı. Paket gönderme arabelleğinden gönderildiğinde, sıraya alınır.
sonraki atlama onayı için bakım tamponu.

Bakım arabelleği daha sonra önceden gönderilmiş paketleri arabelleğe alır ve
paket teslimi bildirimi. Protokol işlemi büyük ölçüde kopuk bağlantıya bağlıdır
algılama mekanizması. RFC'ye dayalı olarak önerilen üç buluşsal yöntemi şu şekilde uyguluyoruz:
aşağıdaki gibidir:

İlk olarak, mümkün olduğunda bağlantı katmanı geri bildirimini kullanırız, bu aynı zamanda en hızlı mekanizmadır.
bu üç bağlantı hatalarını tespit etmek için. Çerçeve iletimi durumunda bir bağlantı kopmuş olarak kabul edilir.
tüm yeniden denemeler için bir iletim hatasıyla sonuçlanır. Bu mekanizma, aktif
bağlantılar ve yokluğundan çok daha hızlı çalışır. DSR, bağlantı katmanını algılayabilir
iletim hatası ve bozuk olarak bildirin. Rotaların yeniden hesaplanması tetiklenecek
ihtiyaç duyulduğunda. Kullanıcı bağlantı katmanı onayı kullanmak istemiyorsa, tarafından ayarlanabilir.
"dsr-routing.cc" içinde "LinkAcknowledgment" özniteliğini false olarak ayarlamak.

İkinci olarak, mümkün olduğunda pasif onaylama kullanılmalıdır. düğüm açılır
kendisi için hedeflenmemiş paketleri alabildiği "rastgele" alma modu ve
düğüm, bu veri paketinin hedefine teslim edilmesini sağladığında, işlemi iptal eder.
pasif onay zamanlayıcısı.

Son olarak, bir paketin alındığını bildirmek için bir ağ katmanı kabul şeması kullanıyoruz. Rota
istek paketi onaylanmayacak veya yeniden iletilmeyecektir.

Rota Önbelleği uygulaması, eski girdilerin ve durumun çöp toplamasını destekler
standartta tanımlandığı gibi makine. STL harita kapsayıcısı olarak uygulanır. anahtar
hedef IP adresi.

DSR, IP başlığına doğrudan erişimle çalışır ve ağ ile aktarım arasında çalışır
katman. Paket taşıma katmanından gönderildiğinde kendisini DSR ve DSR'ye iletir.
başlık eklenir.

İki önbelleğe alma mekanizmamız var: yol önbelleği ve bağlantı önbelleği. Yol önbelleği bütünü kaydeder
önbellekteki yol. Yollar, atlama sayısına göre sıralanır ve bir yol
kullanılamıyor, bir sonraki yola geçiyoruz. Bağlantı önbelleği biraz daha iyi
farklı alt yollar kullanması ve Uygulamalı Bağlantı Önbelleğini kullanması anlamında tasarım
Dijsktra algoritması ve bu kısım Song Luan tarafından uygulanmaktadır.[e-posta korumalı]>.

Aşağıdaki isteğe bağlı protokol optimizasyonları uygulanmaz:

· Akış durumu

· İlk Atlama Harici (F), Son Atlama Harici (L) bayrakları

· Bilinmeyen DSR seçeneklerini işleme

·

İki türleri of hata başlıklar:

1. akış durumu desteklenmiyor seçeneği

2. desteklenmeyen seçenek (simülasyonda olmayacak)

DSR güncelleştirme in ns-3.17
Başlangıçta Ptr'de "TxErrHeader" kullandık bir iletim hatasını belirtmek için
bağlantı katmanındaki belirli bir paket, ancak, o zamandan beri tam olarak doğru çalışmıyordu.
paket düştü, bu başlık izleme dosyasına kaydedilmedi. Biz bir
bağlantı katmanı bildirim mekanizmasının uygulanmasında farklı yol. içine bakıyoruz
paket alma olayını bularak dosyayı takip edin. Veriler için bir alma olayı bulursak
paket, başarılı veri teslimi için gösterge olarak sayarız.

yararlı parametreler
+------------------------------------------ +----------------------- -------------+-------------+
| parametre | Açıklama | Varsayılan |
+=========================+====================== ==============+==============+
| MaxSendBuffLen | Yapılabilecek maksimum paket sayısı | 64 |
| | gönderme arabelleğinde saklanabilir | |
+------------------------------------------ +----------------------- -------------+-------------+
| MaxSendBuffTime | Paketlerin sıraya alınabileceği maksimum süre | saniye(30) |
| | gönderme arabelleğinde | |
+------------------------------------------ +----------------------- -------------+-------------+
| MaxMaintLen | Yapılabilecek maksimum paket sayısı | 50 |
| | bakım tamponunda saklanabilir | |
+------------------------------------------ +----------------------- -------------+-------------+
| MaxMaintTime | Paketlerin sıraya alınabileceği maksimum süre | saniye(30) |
| | bakım tamponunda | |
+------------------------------------------ +----------------------- -------------+-------------+
| MaxCacheLen | Maksimum rota girişi sayısı | 64 |
| | rota önbelleğinde saklanabilen bilgiler | |
+------------------------------------------ +----------------------- -------------+-------------+
| RotaÖnbellekZaman Aşımı | Rota önbelleğinin alabileceği maksimum süre | saniye(300)|
| | rota önbelleğinde sıraya alın | |
+------------------------------------------ +----------------------- -------------+-------------+
| RreqRetries | Maksimum yeniden iletim sayısı | 16 |
| | rota keşfi talebi için | |
+------------------------------------------ +----------------------- -------------+-------------+
| Önbellek Türü | Bağlantı Önbelleğini kullanın veya Yol Önbelleğini kullanın | "LinkCache" |
| | | |
+------------------------------------------ +----------------------- -------------+-------------+
| BağlantıTeşekkür | Bağlantı katmanı onayını etkinleştir | doğru |
| | mekanizma | |
+------------------------------------------ +----------------------- -------------+-------------+

Uygulama değişiklik
·

The DsrFsBaşlığı vardır katma 3 alanlar: mesaj tip, kaynak id, hedef id, ve bunlar
değişiklikler bir tek için rötuş

1. Mesaj tipi, kontrol paketinden veri paketini tanımlamak için kullanılır.

2. kaynak kimliği, elimizde olduğundan beri veri paketinin gerçek kaynağını tanımlamak için kullanılır.
paketi hop-by-hop ile teslim etmek için ipv4header gerçek
kaynak ve hedef ip adresi gerektiği gibi

3. hedef kimliği yukarıdakiyle aynı nedenden dolayıdır

· Yönlendirme Yanıt başlığı DSR RFC'de sözcük hizalı değil, içinde sözcük hizalı olarak değiştirin
uygulama

· DSR, taşıma ve ağ protokolü arasında bir şim başlığı olarak çalışır, kendi
yönlendirme mekanizması, paket iletimini atlamalı dağıtıma değiştiriyoruz, bu nedenle
paket teslimini bildirmek için dsr sabit başlığına iki alan ekledik

akım Rota Önbellek uygulama
Bu uygulama, uygulanması basit olan ve döngüsüz olmasını sağlayan "yol önbelleği"ni kullandı
yollar:

· yol önbelleğinin otomatik sona erme politikası vardır

· önbellek belirli bir hedef için birden çok rota girişini kaydeder ve girişleri sıralar
atlama sayılarına dayalı

· MaxEntriesEachDst, tek bir giriş için kaydedilen maksimum girişleri değiştirmek üzere ayarlanabilir.
hedef

· bir hedef için birden fazla rota eklerken, rota aşağıdakilere göre karşılaştırılır:
atlama sayısı ve sona erme süresi, daha az atlama sayısı veya nispeten yeni rota olan
ayrıcalıklı

· Gelecekteki uygulama, başka bir olasılık olarak "bağlantı önbelleği" içerebilir

DSR talimatlar
DSR'yi yönlendirme protokolü olarak çalıştırırken aşağıdakiler akılda tutulmalıdır:

· NodeTraversalTime, iki komşu düğümü geçmek için geçen süredir ve
iletim aralığına uyacak şekilde seçilmiş

· PassiveAckTimeout, bakım arabelleğindeki bir paketin pasif için bekleme süresidir.
alındı, normalde NodeTraversalTime'ın iki katı olarak ayarlanır

· RouteCacheTimeout, düğümlerin hızı arttığında daha küçük bir değere ayarlanmalıdır.
Varsayılan değer 300s'dir.

Yardımcı
DSR'yi çalıştıran bir düğüme sahip olmak için en kolay yol, DsrHelper ve DsrMainHelpers'ı kullanmaktır.
simülasyon komut dosyanızda. Örneğin:

DsrYardımcı dsr;
DsrMainHelper dsrMain;
dsrMain.Install (dsr, adhocNodes);

İçindeki örnek komut dosyaları kaynak/dsr/örnekler/ DSR tabanlı düğümlerin kullanımını göstermek
farklı senaryolar. Yardımcı kaynak içeride bulunabilir
kaynak/dsr/yardımcı/dsr-ana yardımcı.{h,cc} ve kaynak/dsr/yardımcı/dsr-yardımcı.{h,cc}

Örnekler
Örnek şurada bulunabilir: kaynak/dsr/örnekler/:

· dsr.cc, geleneksel bir MANET ortamında yönlendirme protokolü olarak DSR'yi kullanır[3].

DSR, aynı zamanda, yönlendirme karşılaştırma durumunda da oluşturulmuştur. örnekler/yönlendirme/:

· manet-yönlendirme-karşılaştırma.cc yerleşik MANET yönlendirme protokollerine sahip bir karşılaştırma durumudur ve
kendi sonuçlarını üretebilir.

Onaylama
Bu model şu şekilde test edilmiştir:

· DSR'nin içini doğrulamak için birim testleri yazılmıştır. Bu bulunabilir
src/dsr/test/dsr-test-suite.cc. Bu testler, DSR modülü içindeki yöntemlerin olup olmadığını doğrular.
paket arabelleği ile ilgilenen başlıklar doğru çalışır.

· [3]'e benzer simülasyon durumları test edilmiştir ve karşılaştırılabilir sonuçlara sahiptir.

· manet-routing-compare.cc, DSR'yi diğer üç yönlendirme ile karşılaştırmak için kullanıldı
protokolleri.

Bu sonuçlarla ilgili 3 yılında ns-2011 Çalıştayında bir bildiri sunuldu.

Sınırlamalar
Model tam olarak uyumlu değil RFC 4728. Örnek olarak, Dsr sabit boyutlu başlığı vardır
uzatılmıştır ve RFC spesifikasyonundan dört okect daha uzundur. Sonuç olarak,
DSR başlıklarının kodu Wireshark tarafından doğru şekilde çözülemez.

Modelin RFC ile tam uyumlu olması gelecek için planlanmıştır.

Referanslar
[1] Orijinal kağıt: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

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

[3] Broch'un karşılaştırma makalesi: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

öykünme GENEL BAKIŞ

ns-3 test ortamı ve sanal makine ortamlarına entegrasyon için tasarlanmıştır. Biz
iki tür ağ cihazı sağlayarak bu ihtiyacı karşılamıştır. İlk tür cihaz
bir dosya tanımlayıcı ağ aygıtıdır (FdNetCihazı), yapabilen genel bir cihaz türüdür.
bir dosya tanıtıcısından okuma ve yazma. Bu dosya tanıtıcıyı farklı dosyalarla ilişkilendirerek
Host sistemindeki şeyler, farklı yetenekler sağlanabilir. Örneğin,
FdNetDevice, öykünme sağlamak için temeldeki bir paket soketiyle ilişkilendirilebilir
yetenekler. Bu izin verir ns-3 "gerçek" bir ağ üzerinde veri göndermek için simülasyonlar. İkinci
denilen tür Musluk NetCihaz "gerçek" bir ev sahibinin bir toplantıya katılmasına izin verir ns-3 simülasyon olarak
simüle edilmiş düğümlerden biri olsaydı. Bir ns-3 simülasyon herhangi bir ile inşa edilebilir
simüle edilmiş veya taklit edilmiş cihazların kombinasyonu.

Not: ns-3.17'den önce, öykünme yeteneği adı verilen özel bir cihaz tarafından sağlanıyordu.
an koşucu devekuşu NetCihaz; en koşucu devekuşu NetDevice ile değiştirildi FdNetCihazı.

Desteklemek istediğimiz kullanım durumlarından biri test ortamıdır. Bir somut örnek
bu tür bir ortam ORBIT test ortamıdır. ORBIT bir laboratuvar öykünücüsü/saha denemesidir
400 802.11 radyo düğümünden oluşan iki boyutlu bir ızgara olarak düzenlenmiş ağ. ile entegre ediyoruz
ORBIT, yüklemek ve çalıştırmak için "görüntüleme" sürecini kullanarak ns-3 ORBIT üzerinde simülasyonlar
dizi. bizimkileri kullanabiliriz EmuFdNetCihaz donanımı test ortamında sürmek için
kullanarak sonuçları toplayın ns-3 izleme ve günlüğe kaydetme işlevleri veya yerel
ORBIT veri toplama teknikleri. Görmek http://www.orbit-lab.org/ ORBIT ile ilgili ayrıntılar için
test yatağı.

Bu tür bir simülasyon aşağıdaki şekilde gösterilmiştir:
[image] Testbed Emülasyonunun Örnek Uygulaması..UNINDENT

Her biri bir "global" alt kümesini çalıştıran ayrı ana bilgisayarlar olduğunu görebilirsiniz.
simülasyon. yerine ns-3 ana bilgisayarları birbirine bağlayan kanal, gerçek donanım kullanıyoruz
test yatağı tarafından sağlanır. Bu izin verir ns-3 bağlı uygulamalar ve protokol yığınları
gerçek donanım üzerinden iletişim kurmak için simülasyon düğümü.

Bu yapılandırmanın birincil kullanımının tekrarlanabilir oluşturmak olmasını bekliyoruz.
tümünü içeren gerçek dünya ağ ortamında deneysel sonuçlar ns-3
izleme, günlüğe kaydetme, görselleştirme ve istatistik toplama araçları.

Esasen ters bir konfigürasyon olarak görülebilecek olanda, "gerçek" makinelere izin veriyoruz.
entegre etmek için yerel uygulamaları ve protokol yığınlarını çalıştıran ns-3 simülasyon.
Bu, gerçek bir makineye bağlı büyük ağların simülasyonunu sağlar ve ayrıca
sanallaştırmayı sağlar. Bu tür bir simülasyon aşağıdaki şekilde gösterilmiştir:
[image] Öykünülmüş kanalın uygulamaya genel bakışı..UNINDENT

Burada, çalışan bir dizi sanal makineye sahip tek bir ana bilgisayar olduğunu göreceksiniz.
üstünde. Bir ns-3 simülasyon, ortasında gösterilen sanal makinede çalışırken gösterilir.
figür. Bu simülasyon, ilişkili bir dizi düğüme sahiptir. ns-3 uygulamalar ve
biriyle konuşan protokol yığınları ns-3 yerel simülasyon yoluyla kanal ns-3 net
cihazlar.

Ayrıca şeklin en solunda ve en sağında gösterilen iki sanal makine vardır.
Bu VM'ler, yerel (Linux) uygulamaları ve protokol yığınlarını çalıştırıyor. sanal makine
simülasyona bir Linux Tap ağ cihazı ile bağlanır. için kullanıcı modu işleyicisi
Dokunma cihazı simülasyonda somutlaştırılır ve bir proxy düğümüne eklenir.
simülasyondaki yerel VM'yi temsil eder. Bu işleyiciler, üzerinde Tap cihazlarına izin verir.
yerel VM'ler varmış gibi davranacak ns-3 simülasyon sanal makinesindeki net cihazlar. Bu, içinde
çevirmek, yerel VM'lerdeki yerel yazılım ve protokol takımlarının buna inanmasına izin verir.
onlar simüle bağlı ns-3 kanalı.

Bu ortam için tipik kullanım durumunun, aşağıdakilerin davranışını analiz etmek olacağını umuyoruz.
büyük simülasyonların varlığında yerel uygulamalar ve protokol paketleri ns-3
ağlar.

fileto Tanımlayıcı NetCihaz
The kaynak/fd-net-aygıtı modül sağlar FdNetCihazı okuyabilen ve sınıf
kullanıcı tarafından sağlanan bir dosya tanımlayıcı kullanarak trafik yazın. Bu dosya tanımlayıcısı olabilir
bir TAP cihazıyla, ham bir soketle, üreten/tüketen bir kullanıcı alanı süreciyle ilişkili
trafik, vb. Kullanıcı, harici trafiğin nasıl oluşturulacağını tanımlama konusunda tam özgürlüğe sahiptir ve
ns-3 trafik tüketilir.

Bir simülasyonu harici trafikle ilişkilendirmek için farklı mekanizmalar şu yollarla sağlanabilir:
yardımcı sınıflar Üç özel yardımcı sağlanır:

· EmuFdNetDeviceHelper ( ns-3 ana bilgisayarda fiziksel bir cihaz bulunan cihaz
makine)

· TapFdNetDeviceHelper (ns-3 cihazını bir dokunuştan dosya tanımlayıcıyla ilişkilendirmek için
ana makinedeki cihaz)

· PlanteLabFdNetDeviceHelper (PlanetLab düğümlerinde musluk cihazlarının oluşturulmasını otomatikleştirmek için,
etkinleştirme ns-3 kullanarak İnternet üzerinden trafik gönderip alabilen simülasyonlar
PlanetLab kaynağı.

Model Tanım
Bu modülün kaynak kodu dizinde bulunur kaynak/fd-net-aygıtı.

FdNetDevice özel bir türdür. ns-3 Bir dosyaya gelen ve giden trafiği okuyan NetDevice
tanımlayıcı. Diğer bir deyişle, çerçeveler yazan saf simülasyon NetDevice nesnelerinin aksine ve
simüle edilmiş bir kanaldan, bu FdNetDevice çerçeveleri simülasyondan bir dosyaya yönlendirir
tanımlayıcı. Dosya tanımlayıcı, bir Linux TUN/TAP cihazıyla, bir soketle,
veya bir kullanıcı-alanı sürecine.

Bir dosya tanıtıcı sağlamak bu cihazın kullanıcısına kalmıştır. dosya türü
sağlanan tanımlayıcı neyin modellendiğini belirler. Örneğin, eğer dosya
tanımlayıcı, ana makinedeki bir WiFi kartına ham bir yuva sağlar, aygıt
modellenen bir WiFi cihazıdır.

Aşağıya bakan cihazın kavramsal "tepesinden", simüle edilmiş düğüme şöyle görünür:
48-bit IEEE MAC adresini destekleyen, köprülenebilen, yayını destekleyen ve
IPv4 ARP veya IPv6 Komşu Keşfi kullanır, ancak bu öznitelikler bir
kullanım durumu bazında.

Tasarım
FdNetDevice uygulaması, aşağıdakilerden genişletilmiş bir okuyucu nesnesini kullanır. FdOkuyucu
sınıfında ns-3 kaynak/çekirdek ana iş parçacığından ayrı bir iş parçacığı yöneten modül ns-3
dosya tanıtıcısından gelen trafiği okumak için yürütme iş parçacığı.

çağrılması üzerine Cihazı Başlat yöntemi, okuyucu nesnesi başlatılır ve
okuma ipliği. Cihaz başlatılmadan önce, bir dosya tanımlayıcının önceden
FdNetDevice ile SetFileDescriptor çağırma.

Dosya tanımlayıcının oluşturulması ve yapılandırılması birkaç yardımcıya bırakılabilir,
aşağıda daha ayrıntılı olarak açıklanmıştır. Bu yapıldığında, çağrı SetFileDescriptor is
yardımcının sorumluluğundadır ve doğrudan kullanıcı tarafından çağrılmamalıdır.

Dosya tanımlayıcıdan gelen bir çerçeveyi okuduktan sonra, okuyucu çerçeveyi
the geri arama al görevi çerçevenin alımını programlamak olan yöntem,
cihaz olarak ns-3 simülasyon olayı. Yeni çerçeve okuyucu iş parçacığından geçirildiğinden
Ana ns-3 simülasyon iş parçacığı, iş parçacığı güvenliği sorunları kullanılarak önlenir
ProgramWithContext normal yerine ara Çizelge aramak.

Gelen veri hızı çok yüksek olduğunda zamanlayıcıyı bunaltmaktan kaçınmak için, bir
sayaç, halihazırda alınması planlanan çerçeve sayısıyla birlikte tutulur.
cihaz. Bu sayaç tarafından verilen değere ulaşırsa RxQueueBoyutu özniteliği
aygıt, ardından yeni çerçeve sessizce bırakılacaktır.

Cihaz tarafından yeni çerçevenin fiili alımı, programlandığında gerçekleşir. FordwarUp
yöntem simülatör tarafından çağrılır. Bu yöntem, bir yerden yeni bir çerçeve gelmiş gibi davranır.
cihaza bağlı kanal. Cihaz daha sonra herhangi bir katmanı kaldırarak çerçeveyi açar.
2 başlık ve düğümün üst ağ yığın katmanlarına iletir. bu İleri Yukarı
yöntemi, tarafından tanımlanan çerçeve kapsülleme türüne göre çerçeve başlıklarını kaldıracaktır.
the KapsüllemeModu özniteliği ve bir IP paketi ileten alma geri aramasını çağırın.

Dosya tanıtıcısı bir
IFF_NO_PI bayrağı ayarlanmadan oluşturulan TAP cihazı. Bu ekstra başlık
kaldırılırsa KapsüllemeModu DIXPI değerine ayarlanır.

Ters yönde, simülasyon içinde üretilen ve dışarı gönderilen paketler
cihaz üzerinden aktarılacaktır. Gönder sırayla çağıracak olan yöntem
Gönderen yöntem. İkinci yöntem, gerekli katman 2 başlıklarını ekleyecektir ve basitçe
yeni oluşturulan çerçeveyi dosya tanıtıcısına yazın.

kapsam ve Sınırlamalar
Bu cihazın kullanıcıları, dosya boyunca akış denetimi olmadığı konusunda uyarılır.
öykünme modunda kullanırken tanımlayıcı sınırı. Yani, bir Linux sisteminde, eğer
ağ paketlerini yazma hızı, temeldeki fiziksel aygıtın kapasitesini aşıyor.
paketleri arabelleğe alın, önlemek için yazma uygulamasına kadar geri basınç uygulanacaktır.
yerel paket kaybı Dosya tanımlayıcı arabiriminde böyle bir akış denetimi sağlanmaz,
bu nedenle kullanıcılar bu sınırlamanın farkında olmalıdır.

Daha önce açıklandığı gibi, RxQueueSize özniteliği, alınabilecek paketlerin sayısını sınırlar.
cihaz tarafından alınmayı bekliyor. Dosya tanıtıcısından okunan çerçeveler,
bekleyen paketlerin sayısı maksimumda ise sessizce bırakılacaktır.

Aygıtın mtu'su varsayılan olarak Ethernet II MTU değerine ayarlanır. Ancak yardımcıların
ağ arayüzünün özelliklerini yansıtmak için mtu'yu doğru değere ayarlamak için
dosya tanımlayıcı ile ilişkilendirilir. Herhangi bir yardımcı kullanılmazsa, sorumluluğu
cihaz için doğru mtu değerini ayarlamak kullanıcıya düşer. okunan boyut
dosya tanımlayıcı okuyucudaki arabellek, dosyadaki mtu değerine ayarlanır. Cihazı Başlat yöntemi.

FdNetDevice sınıfı şu anda üç kapsülleme modunu destekler, Ethernet II için DIX
çerçeveler, 802.2 LLC/SNAP çerçeveleri için LLC ve ek bir Ethernet II çerçeveleri için DIXPI
TAP PI başlığı. Bu, dosya tanıtıcıdan geçen trafiğin
Ethernet II uyumlu. Bir FdNetDevice'i kablosuz bir arayüze eklemek şu şekilde mümkündür:
sürücü, soket API'sine Ethernet II çerçeveleri sağladığı sürece. ilişkilendirmek için unutmayın
ad-hoc modunda bir kablosuz karta bir FdNetDevice, cihazın MAC adresi ayarlanmalıdır
gerçek kart MAC adresine, aksi takdirde gelen trafik sahte bir MAC adresi olacaktır.
sürücü tarafından atılır.

Daha önce belirtildiği gibi, fd-net-device modülü ile birlikte üç yardımcı sağlanır. Her biri
bireysel yardımcı (dosya tanımlayıcı türü) platform sınırlamalarına sahip olabilir. Örneğin,
iş parçacığı, gerçek zamanlı simülasyon modu ve TUN/TAP cihazları oluşturma yeteneği
sağlanan yardımcıları kullanmanın ön koşulları. Bu modlar için destek şurada bulunabilir:
çıktısı WAF yapılandırmak adım, örneğin:

Threading Primitives : etkin
Gerçek Zamanlı Simülatör: etkin
Öykünülmüş Ağ Aygıtı: etkin
Köprü'ye dokunun: etkin

Test ederken şunu belirtmek önemlidir. FdNetCihazı bir üst sınır bulduk
1 Mb/sn'lik 60 Gb Ethernet bağlantıları kullanılırken TCP verimi için sınır. Bu sınır en
muhtemelen testlere dahil olan bilgisayarların işlem gücünden kaynaklanmaktadır.

kullanım
Bu tür bir cihazın kullanım modeli, yardımcıları olan diğer net cihazlara benzer.
düğüm işaretçilerine veya düğüm kapsayıcılarına yüklenen. Baz kullanırken FdNetDeviceYardımcısı
dosya tanıtıcısını kendisi oluşturmaktan ve ayarlamaktan kullanıcı sorumludur.

FdNetDeviceHelper fd;
NetDeviceContainer cihazları = fd.Install (düğümler);

// dosya tanımlayıcı oluşturma
Kendi ID’n ile mağazalarını oluştur

cihaz->SetFileDescriptor (fd);

En yaygın olarak, ana bilgisayar sistemiyle etkileşim kurmak için bir FdNetDevice kullanılacaktır. Bu durumlarda
kullanıcının gerçek zamanlı öykünme modunda çalıştırmak isteyeceği neredeyse kesindir ve
sağlama toplamı hesaplamalarını etkinleştirin. Tipik program ifadeleri aşağıdaki gibidir:

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

Bir Linux ana bilgisayar sistemiyle etkileşime giren bir deney kurmanın en kolay yolu, kullanıcı
the koşucu devekuşu ve Musluk yardımcılar. Bu yardımcı uygulamaların belki de en sıra dışı kısmı
bazı kodların süper kullanıcı izinleriyle yürütülmesi gerekliliği ile ilgilidir.
Kullanıcıyı tüm simülasyonu kök olarak yürütmeye zorlamak yerine, küçük bir
Kök olarak çalışan ve gerekli tüm yüksek izinli soketleri çalıştıran "creator" programı.
"Yaratıcı" programlar için doğru ayrıcalıkları ayarlamanın en kolay yolu,
--enable-sudo gerçekleştirirken bayrak WAF yapılandırmak.

Her ikisi için de benzer bir şey yapıyoruz koşucu devekuşu ve Musluk cihazlar. Üst düzey görüş şu ki
the DosyaTanımlayıcısı Oluştur yöntem yerel bir süreçler arası (Unix) soket, çatallar ve
küçük oluşturma programını yürütür. Suid root olarak çalışan küçük program,
ham soket ve ham soket dosya tanımlayıcısını Unix soketi üzerinden geri gönderir.
parametre olarak kendisine iletilir. Ham soket bir kontrol mesajı olarak iletilir (bazen
SCM_RIGHTS türünde yardımcı veriler olarak adlandırılır).

Yardımcılar
EmuFdNetDeviceYardımcısı
EmuFdNetDeviceHelper, temel alınan bir fiziksel cihaza ham bir soket oluşturur ve
FdNetDevice'e soket tanımlayıcısını sağlar. Bu, ns-3 simülasyon
ana bilgisayardaki bir ağ cihazından çerçeveleri okuyun ve çerçeveleri yazın.

Öykünme yardımcısı, simüle edilmiş bir ns-3 düğüm
gerçek düğümlerden oluşan ağ.

+----------------------+ +--------------------------+
| ev sahibi 1 | | ev sahibi 2 |
+----------------------+ +--------------------------+
| ns-3 simülasyonu | | |
+---------------------+ | Linux |
| ns-3 Düğümü | | Ağ Yığını |
| +----------------- | | +----------------- |
| | ns-3 TCP | | | | TCP | |
| +----------------- | | +----------------- |
| | ns-3 IP | | | | IP | |
| +----------------- | | +----------------- |
| | FdNetAygıtı | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + ETERNET + |
| | ham soket | | | | | |
|--+----------------+--| | +----------------- |
| | et0 | | | | et0 | |
+-------+------+-------+ +-------+------+-------+

10.1.1.11 10.1.1.12

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

Bu yardımcı, işlevselliğin yerini alır. EmuNetCihazı içinde bulunan ns-3 ns-3.17'den önce,
bu tür bir cihazı FdNetDevice'in ortak çerçevesine getirerek. bu
EmuNetCihazı bu yeni yardımcı lehine reddedildi.

Cihaz, simülasyon ağ trafiğini ayırmak için MAC sahtekarlığı yapmak üzere yapılandırılmıştır.
ana bilgisayara ve ana bilgisayardan akabilecek diğer ağ trafiğinden.

Bu yardımcı, simülasyonun üzerinde bulunduğu ana bilgisayarın bulunduğu bir test ortamı durumunda kullanılabilir.
çalışan, test ortamı donanımını çalıştıran özel bir ilgi arabirimine sahiptir. Yapabilirdin
ayrıca bu özel arayüzü karışık moda ayarlamanız ve uygun bir
cihaz adı için ns-3 simülasyon. Ek olarak, segmentasyonun donanımsal olarak boşaltılması ve
sağlama toplamları devre dışı bırakılmalıdır.

Yardımcı yalnızca temel arabirim çalışır durumdaysa ve karışık moddaysa çalışır. paketler
cihaz üzerinden gönderilecek, ancak MAC sahtekarlığı kullanıyoruz. MAC adresleri
olarak Organizasyonel Olarak Benzersiz Tanımlayıcı (OUI) 00:00:00 kullanılarak oluşturulur (varsayılan olarak).
temel. Bu satıcı kodu herhangi bir kuruluşa atanmamıştır ve bu nedenle
herhangi bir gerçek donanım.

Bu MAC adreslerini kullanmanın sizin için uygun olup olmadığına karar vermek her zaman kullanıcıya kalmıştır.
ağ ve başka hiçbir şeyle çakışmaz (böyle kullanan başka bir simülasyon dahil)
cihazlar) ağınızdaki. Öykünülmüş FdNetDevice yapılandırmasını kullanıyorsanız
ayrı simülasyonlar için, global MAC adresi atama sorunlarını dikkate almalı ve
MAC adresleri tüm simülasyonlarda benzersizdir. Öykünülmüş ağ aygıtı,
verilen MAC adresi Adres özniteliği, böylece bunu manuel olarak yapabilirsiniz. Daha büyük için
simülasyonlar için, MAC adresi tahsis işlevinde OUI'yi ayarlamak isteyebilirsiniz.

çağırmadan önce kurmak yönteminde doğru cihaz adı yapılandırılmalıdır.
kullanarak yardımcı CihazAdı Ayarla yöntem. Hangisini tanımlamak için cihaz adı gereklidir?
ham soketi açmak için fiziksel cihaz kullanılmalıdır.

EmuFdNetDeviceHelper emu;
emu.SetDeviceName (cihazAdı);
NetDeviceContainer cihazları = emu.Install (düğüm);
Ptr cihaz = cihazlar.Al (0);
device->SetAttribute ("Adres", Mac48AddressValue (Mac48Address::Allocate ()));

FdNetDeviceHelper'a dokunun
Tap cihazı, cihazın bir ucunun göründüğü gibi göründüğü özel bir Linux cihazı türüdür.
çekirdek sanal bir net_device olarak, diğer uç ise bir dosya tanımlayıcı olarak sağlanır.
Kullanıcı alanı. Bu dosya tanımlayıcı FdNetDevice'e geçirilebilir. Gönderilen paketler
çekirdek tarafından TAP aygıtı FdNetDevice içinde görünecektir. ns-3.

Kullanıcılar, TAP cihazlarının bu kullanımının, aşağıdakiler tarafından sağlanandan farklı olduğunu unutmamalıdır.
TapBridge NetDevice şurada bulundu: src/musluk köprüsü. Bu yardımcıdaki model aşağıdaki gibidir:

----------------------------------------------------+
| ev sahibi |
----------------------------------------------------+
| ns-3 simülasyonu | |
+---------------------+ |
| ns-3 Düğümü | |
| +----------------- | |
| | ns-3 TCP | | |
| +----------------- | |
| | ns-3 IP | | |
| +----------------- | |
| | FdNetAygıtı | | |
|--+-----+--+ +------+ |
| | TAP | | et0 | |
| +--------+ +------+ |
| 192.168.0.1 | |
+------------------------------------------|-----+
|
|
------------ (İnternet) -----

Yukarıda, yapılandırma, ana bilgisayarın trafiği iletebilmesini gerektirir.
Simülasyon tarafından internete oluşturulur.

TapBridge'deki model (başka bir modülde) aşağıdaki gibidir:

+-------+
| Linux |
| ev sahibi | +----------+
| ------ | | hayalet |
| uygulamalar | | düğüm |
| ------ | | -------- |
| yığın | | IP | +----------+
| ------ | | yığın | | düğüm |
| DOKUN | |==========| | -------- |
| cihaz | <----- IPC ------> | dokunun | | IP |
+-------+ | köprü | | yığın |
| -------- | | -------- |
| ns-3 | | ns-3 |
| ağ | | ağ |
| cihaz | | cihaz |
+------------+ +---------+
|| ||
+------------------------------------------
| ns-3 kanal |
+------------------------------------------

Yukarıda, paketler bunun yerine çapraz ns-3 NetDevices ve Kanallar.

Bu örnek için kullanım modeli, kullanıcının MAC adresini ayarlaması ve ya (veya
her ikisi de) cihazdaki IPv4 ve IPv6 adresleri ve maskeleri ve gerekirse PI başlığı.
Örneğin:

TapFdNetDeviceHelper yardımcısı;
helper.SetDeviceName (cihazAdı);
yardımcı.SetModePi (modPi);
helper.SetTapIpv4Address (tapIp);
yardımcı.SetTapIpv4Mask (tapMask);
Kendi ID’n ile mağazalarını oluştur
helper.Install (düğüm);

PlanetLabFdNetDeviceYardımcısı
PlanetLab, birbirine bağlı düğümlerden oluşan dünya çapında dağıtılmış bir ağ test ortamıdır.
İnternet. kullanarak PlanetLab düğümlerinde ns-3 simülasyonlarını çalıştırma
PlanetLabFdNetDeviceHelper, ns-3 tarafından oluşturulan simüle edilmiş trafiğin doğrudan
internet. Bu kurulum, ns-3 İnternet protokollerini veya diğer gelecekleri doğrulamak için faydalı olabilir.
ns-3'te uygulanan protokoller.

PlanetLab düğümlerini kullanarak deneyler yapmak için bir PlanetLab hesabına sahip olmak gerekir. Sadece
PlanetLab ortak kurumlarının üyeleri bu tür hesapları alabilir ( daha fazla bilgi için
ziyaret etmek http://www.planet-lab.org/ or http://www.planet-lab.eu ). Hesap bir kez
elde edilen bir PlanetLab dilim deneylerin yapılabilmesi için talep edilmelidir. Bir dilim
bir grup PlanetLab kullanıcısıyla ilgili bir deney birimini temsil eder ve ilişkilendirilebilir
farklı PlanetLab düğümlerindeki sanal makinelere. Dilimler eklenerek de özelleştirilebilir
yapılandırma etiketleri (bu, PlanetLab yöneticileri tarafından yapılır).

PlanetLabFdNetDeviceHelper, belirli kullanarak PlanetLab düğümlerinde TAP cihazları oluşturur.
PlanetLab mekanizmaları (yani vsys sistemi) ve TAP cihazını bir
ns-3'te FdNetDevice. Bu yardımcı tarafından sağlanan işlevsellik buna benzer
FdTapNetDeviceHelper tarafından sağlanan, ancak aşağıdakileri oluşturmak için temel mekanizmalar
TAP cihazı farklıdır.

----------------------------------------------------+
| PlanetLab sunucusu |
----------------------------------------------------+
| ns-3 simülasyonu | |
+---------------------+ |
| ns-3 Düğümü | |
| +----------------- | |
| | ns-3 TCP | | |
| +----------------- | |
| | ns-3 IP | | |
| +----------------- | |
| | FdNetAygıtı | | |
|--+-----+--+ +------+ |
| | TAP | | et0 | |
| +--------+ +------+ |
| 192.168.0.1 | |
+------------------------------------------|-----+
|
|
------------ (İnternet) -----

TAP cihazlarına özel IPv4 adresleri atayabilmek için hesap sahipleri,
talep etmeli vsys_vnet etiketi PlanetLab yöneticileri tarafından dilimlerine eklenecek.
vsys_vnet etiketi, özel ağ segmentiyle ilişkilendirilir ve yalnızca bu segmentteki adresler
segmenti deneylerde kullanılabilir.

Bu yardımcı ile bir TAP cihazı oluşturmak için kullanılan sözdizimi,
daha önce açıklanan yardımcılar:

PlanetLabFdNetDeviceHelper yardımcısı;
helper.SetTapIpAddress (tapIp);
yardımcı.SetTapMask (tapMask);
Kendi ID’n ile mağazalarını oluştur
helper.Install (düğüm);

PlanetLab düğümleri Fedora tabanlı bir dağıtıma sahiptir, bu nedenle ns-3 aşağıdaki şekilde kurulabilir:
ns-3 Linux kurulumu için talimatlar.

Özellikler
The FdNetCihazı bir dizi nitelik sağlar:

· Adres: Cihazın MAC adresi

· Ana Sayfa: Cihaz iş parçacığını döndürmek için simülasyon başlangıç ​​zamanı

· dur: Cihaz iş parçacığını durdurmak için simülasyon başlangıç ​​zamanı

· KapsüllemeModu: Bağlantı katmanı kapsülleme formatı

·

RxQueueBoyutu: The tampon boyut of the okumak kuyruk on the dosya açıklayıcısı
iş parçacığı (varsayılan 1000 paket)

Ana Sayfa ve dur kullanıcı sınırlamak istemediği sürece normalde belirtilmesi gerekmez.
Bu cihazın aktif olduğu süre. Adres bir tür benzersiz olarak ayarlanması gerekiyor
Simülasyon diğer gerçek cihazlarla bir şekilde etkileşime girecekse MAC adresi
gerçek MAC adresleri. Tipik kod:

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

Çıktı
Ascii ve PCAP izleme, diğerine benzer şekilde sağlanır ns-3 NetDevice türleri,
yardımcılar, örneğin (örneğin):

:: EmuFdNetDeviceHelper emu; NetDeviceContainer cihazları = emu.Install (düğüm);
emu.EnablePcap ("emu-ping", cihaz, doğru);

Mac düzeyindeki NetDevice izleme kaynaklarının standart seti sağlanır.

· MaxTx: İzleme kaynağı tetiklendiğinde ns-3 cihaza gönderilecek yeni bir çerçeve sağlar

· MaxTxDrop: Dosya tanımlayıcıya yazma başarısız olursa kaynağı izle

· MaxPromiscRx: Geçerli bir Mac çerçevesi alındığında

· MaksRx: Bu aygıt için geçerli bir Mac çerçevesi alındığında

· Sniffer: Rastgele olmayan paket dinleyicisi

· PromiscSniffer: Rastgele paket dinleyicisi (tcpdump benzeri izler için)

Örnekler
Birkaç örnek verilmiştir:

· kukla-network.cc: Bu basit örnek, iki düğüm oluşturur ve bunları bir düğümle birbirine bağlar.
Dosya tanımlayıcılarını soket çiftinden FdNetDevice'e geçirerek Unix borusu
ilgili düğümlerin nesneleri.

· gerçek zamanlı-kukla-ağ.cc: Dummy-network.cc ile aynı, ancak gerçek zamanlı simülatörü kullanıyor
varsayılan yerine uygulama.

· fd2fd-onoff.cc: Bu örnek, içinde FdNetDevice'in verimini ölçmeyi amaçlamaktadır.
saf bir simülasyon. Bu amaçla iki FdNetDevices, farklı düğümlere bağlı, ancak
aynı simülasyon, bir soket çifti kullanılarak bağlanır. TCP trafiği bir
doyurucu veri hızı.

· fd-emu-onoff.cc: Bu örnek, FdNetDevice'in verimini ölçmeyi amaçlamaktadır.
simüle edilmiş cihazı gerçek bir cihaza eklemek için EmuFdNetDeviceHelper'ı kullanırken
ana makine. Bu, kanalı TCP trafiği ile doyurarak elde edilir.

· fd-emu-ping.cc: Bu örnek, bir ağ üzerinden ICMP trafiği göndermek için EmuFdNetDeviceHelper'ı kullanır.
gerçek kanal.

· fd-emu-udp-echo.cc: Bu örnek, üzerinden UDP trafiği göndermek için EmuFdNetDeviceHelper'ı kullanır.
gerçek bir kanal

· fd-planetlab-ping.cc: Bu örnek, ICMP göndermek için bir denemenin nasıl kurulacağını gösterir.
bir PlanetLab düğümünden İnternet'e trafik.

· fd-tap-ping.cc: Bu örnek, bir ağ üzerinden ICMP trafiği göndermek için TapFdNetDeviceHelper'ı kullanır.
gerçek kanal.

Musluk NetCihaz
Tap NetDevice, bir ana bilgisayar sisteminin veya sanal makinelerin birbirleriyle etkileşime girmesine izin vermek için kullanılabilir.
bir simülasyon.

TapKöprü Model Genel Bakış
Tap Bridge, "gerçek" internet ana bilgisayarlarını (veya daha doğrusu ana bilgisayarları) entegre etmek için tasarlanmıştır.
Tun/Tap cihazlarını destekleyen) ns-3 simülasyonlarına dönüştürün. Amaç, onu bir
"gerçek" ana bilgisayar düğümü, yerel aygıt olarak bir ns-3 ağ aygıtına sahiptir. kavramı
"gerçek ana bilgisayar", "gerçek ana bilgisayar" kullanılarak sanallaştırılabileceğinden biraz kaygandır.
VMware, VirtualBox veya OpenVZ gibi hazır teknolojiler.

Özünde, bir ns-3 net cihazının giriş ve çıkışlarını bağlı olduğumuz için
Bir Linux Tap net cihazının giriş ve çıkışlarına, biz bu düzenlemeye Tap Bridge diyoruz.

Bu cihazın kullanıcılara sunulan üç temel çalışma modu vardır. Temel
işlevsellik esasen aynıdır, ancak modlar aşağıdakilerle ilgili ayrıntılarda farklıdır:
düzenlemenin nasıl oluşturulduğu ve yapılandırıldığı; ve hangi cihazlar hangi tarafta yaşayabilir?
köprü.

Bu üç modu ConfigureLocal, UseLocal ve UseBridge modları olarak adlandırıyoruz. İlk
Deve vaka modu tanımlayıcısındaki "kelime", oluşturma sorumluluğunun kimde olduğunu gösterir.
ve muslukları yapılandırma. Örneğin, ConfigureLocal modundaki "Yapılandır"
musluğu yapılandırma sorumluluğu TapBridge'e aittir. KullanımdaYerel
modu ve UseBridge modlarında, "Kullan" öneki TapBridge'den "Kullan" istendiğini gösterir.
mevcut bir yapılandırma.

Başka bir deyişle, ConfigureLocal modunda, TapBridge oluşturma sorumluluğuna sahiptir.
ve TAP cihazlarının yapılandırılması. UseBridge veya UseLocal modlarında, kullanıcı bir
yapılandırma ve TapBridge bu yapılandırmaya uyum sağlar.

TapKöprü Yerel Yapılandır Moda
ConfigureLocal modunda, musluk cihazının konfigürasyonu ns-3'tür.
konfigürasyon merkezli. Yapılandırma bilgileri ns-3'teki bir cihazdan alınır
simülasyon ve ns-3 öznitelikleriyle eşleşen bir musluk cihazı otomatik olarak oluşturulur. İçinde
bu durumda, bir Linux bilgisayarı doğrudan bir bilgisayara bağlıymış gibi görünür.
simüle edilmiş ns-3 ağı.

Bu, aşağıda gösterilmiştir:

+-------+
| Linux |
| ev sahibi | +----------+
| ------ | | hayalet |
| uygulamalar | | düğüm |
| ------ | | -------- |
| yığın | | IP | +----------+
| ------ | | yığın | | düğüm |
| DOKUN | |==========| | -------- |
| cihaz | <----- IPC ------> | dokunun | | IP |
+-------+ | köprü | | yığın |
| -------- | | -------- |
| ns-3 | | ns-3 |
| ağ | | ağ |
| cihaz | | cihaz |
+------------+ +---------+
|| ||
+------------------------------------------
| ns-3 kanal |
+------------------------------------------

Bu durumda, "hayalet düğüm"deki "ns-3 net cihazı", sanki gerçekmiş gibi görünür.
Linux ana bilgisayarındaki TAP cihazının değiştirilmesi. ns-3 simülasyonu, TAP cihazını
temel Linux işletim sistemi ve TAP cihazının IP ve MAC adreslerini eşleşecek şekilde yapılandırır
simüle edilmiş ns-3 net cihazına atanan değerler. Yukarıda gösterilen "IPC" bağlantısı,
temel işletim sisteminde ağ musluk mekanizması. Tüm düzenleme geleneksel olarak hareket eder
köprü; ancak aynı paylaşılan MAC ve IP'ye sahip olan cihazlar arasında bir köprü
adresleri.

Burada, kullanıcının sisteme özel herhangi bir yapılandırma bilgisi sağlaması gerekmemektedir.
musluk. ns-3 tarafından varsayılanlarına göre bir musluk cihazı oluşturulacak ve yapılandırılacaktır ve
musluk cihazının adı, aşağıdakilere göre temel alınan işletim sistemi tarafından atanacaktır.
varsayılanları.

Kullanıcının oluşturulan musluk cihazına erişme gereksinimi varsa, isteğe bağlı olarak
bir "AygıtAdı" özniteliği sağlayın. Bu durumda, oluşturulan OS musluk cihazı adlandırılacaktır.
buna göre.

ConfigureLocal modu, Tap Bridge'in varsayılan çalışma modudur.

TapKöprü KullanımYerel Moda
UseLocal modu, ConfigureLocal moduna oldukça benzer. önemli fark
mod adından da anlaşılacağı gibi, TapBridge mevcut bir musluk cihazını "Kullanacak"
kullanıcı tarafından önceden oluşturulmuş ve yapılandırılmıştır. Bu mod, özellikle bir
sanallaştırma şeması otomatik olarak musluk cihazları oluşturur ve sağlamak için ns-3 kullanılır
bu cihazlar için simüle edilmiş ağlar.

+-------+
| Linux |
| ev sahibi | +----------+
| ------ | | hayalet |
| uygulamalar | | düğüm |
| ------ | | -------- |
| yığın | | IP | +----------+
| ------ | | yığın | | düğüm |
| DOKUN | |==========| | -------- |
| cihaz | <----- IPC ------> | dokunun | | IP |
| MAC X | | köprü | | yığın |
+-------+ | -------- | | -------- |
| ns-3 | | ns-3 |
| ağ | | ağ |
| cihaz | | cihaz |
| MAC Y | | MAK Z |
+------------+ +---------+
|| ||
+------------------------------------------
| ns-3 kanal |
+------------------------------------------

Bu durumda, "Tap cihazının" (MAC X) önceden yapılandırılmış MAC adresi,
yukarıdaki resimde gösterilen köprülü "ns-3 net cihazı" (MAC Y) ile aynıdır. İçinde
SendFrom()'u (özellikle kablosuz) desteklemeyen ns-3 net cihazlarına köprü yapmak için
STA düğümleri) yalnızca bir Linux cihazının (bir benzersiz MAC adresiyle)
-- burada X), IPC bağlantısı boyunca akan trafiği oluşturur. Bunun nedeni, MAC
IPC bağlantısı üzerindeki trafiğin adresleri "sahte" olacak veya görünür hale gelecek şekilde değiştirilecektir.
Linux ve ns-3 aynı adrese sahipler. Yani, Linux'tan hareket eden trafik
ns-3 hayalet düğümünün ana bilgisayarının MAC adresi X'ten Y'ye değiştirilir ve trafik
Linux ana bilgisayarına giden hayalet düğümün MAC adresi Y'den X'e değiştirilir.
cihazlar arasında bire bir yazışma var, sadece bir MAC kaynağı olabilir
Linux tarafından akıyor. Bu, Linux'un birden fazla ağ aygıtıyla köprü kurduğu anlamına gelir.
eklenenler UseLocal moduyla uyumlu değil.

UseLocal modunda, kullanıcının tamamen bir musluk cihazı oluşturması ve yapılandırması beklenir
gibi bir şey kullanarak ns-3 simülasyonunun kapsamı dışında:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 hw eter 08:00:2e:00:00:01
$ sudo ifconfig tap0 10.1.1.1 ağ maskesi 255.255.255.0 yukarı

Kullanıcı, TapBridge'e neler olup bittiğini anlatmak için ya doğrudan
TapBridge veya TapBridgeHelper, "AygıtAdı" özelliği aracılığıyla. durumunda
yukarıdaki yapılandırmada, "AygıtAdı" özniteliği "tap0" ve "Mod" olarak ayarlanır
öznitelik "UseLocal" olarak ayarlanacaktır.

Bu mod için özel bir kullanım durumu OpenVZ ortamındadır. orada mümkün
"Donanım Düğümü" üzerinde bir Tap cihazı oluşturmak ve onu Sanal Özel Sunucuya taşımak için.
TapBridge mevcut bir musluk cihazını kullanabiliyorsa,
bu ortamda bir işletim sistemi köprüsünün yükü.

TapKöprü KullanımKöprü Moda
Linux ağına aşina olanlar için en basit mod UseBridge modudur. Tekrar,
"Kullan" öneki, TapBridge'in mevcut bir konfigürasyonu kullanacağını gösterir.
Bu durumda, TapBridge bir Linux köprüsünü mantıksal olarak ns-3'e genişletecektir.

Bu, aşağıda gösterilmiştir:

+--------+
| Linux | +---------+
| ------- | | hayalet |
| uygulamalar | | düğüm |
| ------- | | -------- |
| yığın | | IP | +----------+
| ------- | +-------+ | yığın | | düğüm |
| sanal | | TAP | |==========| | -------- |
| Cihaz | | Cihaz | <---- IPC -----> | dokunun | | IP |
+--------+ +-------+ | köprü | | yığın |
|| || | -------- | | -------- |
+------------------+ | ns-3 | | ns-3 |
| OS (brctl) Köprüsü | | ağ | | ağ |
+--------------------+ | cihaz | | cihaz |
+------------+ +---------+
|| ||
+------------------------------------------
| ns-3 kanal |
+------------------------------------------

Bu durumda, Linux uygulamaları, protokolleri vb. çalıştıran bir bilgisayar bir bilgisayara bağlanır.
ns-3 ağı, Linux ana bilgisayarına TAP'ın
cihaz, Linux köprüsüne katılan gerçek bir ağ cihazıdır.

ns-3 simülasyonunda, her bir TAP Aygıtıyla eşleşmesi için bir TapBridge oluşturulur. adı
TAP Aygıtı, "AygıtAdı" özniteliği kullanılarak Tap Bridge'e atanır. TapKöprü
daha sonra işletim sistemi köprüsünü ns-3 net cihazını kapsayacak şekilde mantıksal olarak genişletir.

Bu mod, bir işletim sistemi köprüsünü mantıksal olarak genişlettiğinden, bilgisayarda birçok Linux ağ cihazı olabilir.
köprünün ns-3 olmayan tarafı. Bu nedenle, herhangi bir köprüdeki bir ağ aygıtı gibi, ns-3 ağ
cihaz muhtemelen birçok kaynak adresiyle ilgilenmelidir. Bu nedenle, ns-3 cihazları
olması için SendFrom()'u (NetDevice::SupportsSendFrom() true döndürmeli) destekler.
UseBridge modunda kullanım için yapılandırılmış.

Kullanıcının köprüyü yapılandırmak için aşağıdakine benzer bir şey yapması beklenir.
ve ns-3'ün tamamen dışına dokunun:

$ sudo brctl addbr köprüm
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw eter 00:00:00:00:00:01
$ sudo ifconfig mytap 0.0.0.0 yukarı
$ sudo brctl addif mybridge mytap
$ sudo brctl addif köprüm ...
$ sudo ifconfig mybridge 10.1.1.1 ağ maskesi 255.255.255.0 yukarı

Kullanıcı, TapBridge'e neler olup bittiğini anlatmak için ya doğrudan
TapBridge veya TapBridgeHelper, "AygıtAdı" özelliği aracılığıyla. durumunda
yukarıdaki yapılandırmada, "AygıtAdı" özniteliği "mytap" ve "Mod" olarak ayarlanır
öznitelik "UseBridge" olarak ayarlanacaktır.

Bu mod, özellikle sanallaştırmanın yapılandırıldığı durumlarda kullanışlıdır.
sanal ana bilgisayarlar başka bir sistem tarafından belirlenebilir ve ns-3'e uyacak şekilde değiştirilemez.
Örneğin, belirli bir VM şeması, sanal "vethx" veya "vmnetx" cihazları oluşturabilir.
sanal ana bilgisayarlara yerel görünür. Bu tür sistemlere bağlanmak için,
ana sistemde manuel olarak TAP cihazları oluşturun ve bu TAP cihazlarını
mevcut (VM) sanal cihazlar. Bu durumda Tap Bridge'in görevi,
bir ns-3 net cihazına katılmak için köprü.

TapKöprü Yerel Yapılandır Çalışma
ConfigureLocal modunda, TapBridge ve dolayısıyla ilişkili ns-3 net cihazı görünür
herhangi bir keyfi "eth0" veya "ath0" gibi bir ağ aygıtı olarak Linux ana bilgisayarına
görünebilir. TAP cihazının oluşturulması ve konfigürasyonu ns-3 tarafından yapılır.
simülasyon ve kullanıcı tarafından herhangi bir manuel konfigürasyon gerekli değildir. IP adresleri, MAC
oluşturulan TAP cihazları için adresler, ağ geçitleri vb. simülasyondan çıkarılır
ns-3 cihazının yapılandırmasını ve TapBridge Niteliklerini sorgulayarak kendisi.

MAC adresleri Linux tarafında ve ns-3 tarafında aynı olduğundan, kullanabiliriz
Tüm ns-3 ağ cihazlarında bulunan ns-3 cihazında Send(). MAC'den beri
adresler aynıdır, rastgele geri aramayı
taraf almak. Bu nedenle, ağ aygıtı türlerinde herhangi bir kısıtlama yoktur.
ConfigureLocal modunda kullanılabilir.

TapBridge, bir ns-3 simülasyonunda kanalsız bir ağ aygıtı olarak görünür. Bu cihaz
kendisiyle ilişkilendirilmiş bir IP adresine sahip olmamalıdır, ancak köprülü (ns-3) ağ cihazı
bir IP adresi var. Bunun bir ns-3 BridgeNetDevice (veya bir
genel olarak geleneksel köprü), köprü bağlantı noktalarının IP adreslerine sahip olmamasını talep eden,
ancak köprü cihazının kendisinin bir IP adresine sahip olmasına izin verir.

Ana bilgisayar, bir simülasyonda bir tane içeren "hayalet" bir düğüm olarak görünecektir.
Köprülenen her NetDevice için TapBridge. Bir simülasyon perspektifinden,
Bir hayalet düğüm ile diğer herhangi bir düğüm arasındaki tek fark, bir hayalet düğümün varlığı olacaktır.
TapBridge cihazları. Ancak, TapBridge'in varlığının ekranı etkilediğini unutmayın.
ağ aygıtının hayalet düğümün IP yığınına bağlanması.

Adres bilgilerinin ve ns-3 cihazlarının konfigürasyonu herhangi bir şekilde değiştirilmez.
TapBridge var. Bir TapBridge, ns-3'ten adresleme bilgilerini alacaktır.
bağlı olduğu ağ aygıtı ("köprülenmiş" ağ aygıtı) ve bu bilgileri
TAP cihazını gerçek ana bilgisayarda oluşturun ve yapılandırın.

Bunun sonucu, örneğin standart ping'in kullanılabileceği bir durumdur.
simüle edilmiş bir ns-3 düğümüne ping atmak için gerçek bir ana bilgisayarda yardımcı program. Doğru rotalar eklenirse
internet ana bilgisayarı (bunun gelecekteki ns-3 sürümlerinde otomatik olarak yapılması bekleniyor),
ns-3'teki yönlendirme sistemleri, simüle edilmiş ns-3'te paketlerin doğru şekilde yönlendirilmesini sağlayacaktır.
ağlar. Bunun bir örneği için, aşağıdaki örnek programa bakın, tap-wifi-dumbbell.cc
ns-3 dağılımı.

Tap Bridge, bir Linux ana bilgisayarı ile bir ns-3 arasında bir yerde bir tür gri bir dünyada yaşıyor
köprü cihazı. Linux perspektifinden, bu kod, aşağıdakiler için kullanıcı modu işleyicisi olarak görünür.
bir TAP ağ cihazı. ConfigureLocal modunda, bu Tap cihazı otomatik olarak
ns-3 simülasyonu. Linux ana bilgisayarı otomatik olarak oluşturulan bunlardan birine yazdığında
/dev/tap cihazları, yazma işlemi ns-3 dünyasında yaşayan TapBridge'e yönlendirilir;
ve bu açıdan bakıldığında, Linux'ta paket yazma, Tap'ta okunan bir paket haline gelir.
Köprü. Başka bir deyişle, bir Linux işlemi, bir musluk cihazına bir paket yazar ve bu paket
tarafından alındığı bir ns-3 işlemine ağ musluk mekanizması tarafından yönlendirilir.
TapBridge orada bir okuma işlemi sonucunda. TapBridge daha sonra paketi
köprülendiği ns-3 net aygıtı; ve bu nedenle Linux ana bilgisayarı gibi görünüyor
doğrudan bir ns-3 ağ aygıtı aracılığıyla bir ns-3 ağına bir paket gönderdi.

Diğer yönde, Tap'a bağlı ns-3 net cihazı tarafından alınan bir paket
Bridge, TapBridge'e bir geri arama yoluyla gönderilir. TapBridge daha sonra bunu alır
paketler ve ağ dokunma mekanizmasını kullanarak ana bilgisayara geri yazar. Bu yazıya
aygıt, Linux ana bilgisayarına bir ağ aygıtına bir paket gelmiş gibi görünecektir; ve
bu nedenle, bir simülasyon sırasında ns-3 net cihazı tarafından alınan bir paket ortaya çıkmış gibi
gerçek bir Linux ağ cihazında.

Sonuç olarak, Tap Bridge, bir Linux ana bilgisayarındaki bir musluk cihazını köprüler gibi görünüyor.
simülasyonda bir ns-3 net cihazına "gerçek dünya". Çünkü TAP cihazı ve
köprülü ns-3 net cihazı aynı MAC adresine sahip ve ağ musluğu IPC bağlantısı değil
dışsallaştırıldığında, bu özel köprü türü, bir ns-3 ağ cihazının
aslında Linux ana bilgisayarına yüklendi.

Bunu ns-3 tarafında uygulamak için simülasyonda bir "hayalet düğüme" ihtiyacımız var.
köprülü ns-3 net cihazını ve TapBridge'i tutun. Bu düğüm aslında yapmamalı
Simülasyondaki başka herhangi bir şey, işi basitçe net cihazın görünmesini sağlamak olduğundan
Linux. Bu sadece keyfi bir politika değil, çünkü:

· Hayalet düğümdeki daha yüksek katmanlardan TapBridge'e gönderilen bitler (TapBridge kullanarak
Gönderme yöntemi) tamamen yok sayılır. TapBridge, kendisi herhangi bir bağlantıya bağlı değildir.
ağ, ne Linux'ta ne de ns-3'te. üzerinden asla veri gönderemez veya alamazsınız.
Hayalet düğümden TapBridge.

· Köprülü ns-3 net cihazının geri araması ns-3 düğümünden kesilir ve
Tap Bridge'e yeniden bağlandı. Köprülü bir cihaz tarafından alınan tüm veriler daha sonra gönderilecektir
Linux ana bilgisayarına ve düğüm tarafından alınmayacaktır. bakış açısından
hayalet düğüm, bu cihaz üzerinden gönderebilirsiniz ama asla alamazsınız.

Tabii ki, tüm konuları anlarsanız, kendi kaderinizin kontrolünü elinize alabilirsiniz.
ve ne istersen yap -- hayalet düğümü kullanmanı aktif olarak engellemiyoruz.
karar verdiğin herhangi bir şey. Ghost üzerinde tipik ns-3 işlemlerini yapabileceksiniz.
isterseniz düğüm atın. Örneğin internet yığını orada olmalı ve üzerinde çalışır durumda olmalıdır.
IP adresi atamasına ve global yönlendirmeye katılmak için bu düğüm. Yine de,
Yukarıda belirtildiği gibi, herhangi bir TapBridge veya bağlantılı köprülü ağ cihazlarıyla konuşan arayüzler
tamamen çalışmayacaktır. Ne yaptığınızı tam olarak anlarsanız, kurabilirsiniz.
hayalet düğümdeki diğer arayüzler ve cihazlar ve bunları kullanın; ya da yararlanın
trafik jeneratörleri oluşturmak için köprülü cihazların operasyonel gönderme tarafı. biz genellikle
bu düğüme Linux ana bilgisayarının bir hayaleti gibi davranmanızı ve onu kendi haline bırakmanızı öneririz,
gerçi.

TapKöprü KullanımYerel Moda Çalışma
Yukarıda açıklandığı gibi, TapBridge "gerçek" dünyadan dünyaya bir köprü görevi görür.
simüle ns-3 dünyası. ConfigureLocal modunda, IP'den bu yana hayat kolaydır.
Tap cihazının adresi, ns-3 cihazının IP adresiyle ve cihazın MAC adresiyle eşleşir.
Tap cihazı, ns-3 cihazının MAC adresiyle eşleşir; ve bire bir var
cihazlar arasındaki ilişki.

Bir Tap cihazı harici olarak yapılandırıldığında işler biraz karmaşıktır.
ns-3 net cihazından farklı MAC adresi. Bununla başa çıkmanın geleneksel yolu
fark, paketleri almak için köprülü cihazda karışık modu kullanmaktır.
farklı MAC adresine yönlendirilir ve bunları Linux'a iletir. hareket etmek için
diğer şekilde paketler, geleneksel çözüm, arayanın şunları yapmasına izin veren SendFrom()'dur
"Sahtekarlık" yapın veya kaynak MAC adresini farklı Linux MAC adresiyle eşleşecek şekilde değiştirin.

Linux Sanal Makineleri arasında köprü kurabilmek için özel bir gereksinimimiz var.
kablosuz STA düğümleri. Ne yazık ki, 802.11 spesifikasyonu bunu yapmak için iyi bir yol sağlamıyor.
SendFrom()'u uygulayın, bu yüzden bu soruna geçici bir çözüm bulmalıyız.

Bu amaçla, Tap Bridge'in UseLocal modunu sağladık. Bu mod size
soruna tek bir ağ cihazıyla köprü oluşturuyormuş gibi yaklaşın. Bir tek
Linux tarafında izin verilen adres TapBridge'de hatırlanır ve gelen tüm paketler
Linux tarafından ns-3 cihazı MAC kaynağı kullanılarak ns-3 tarafında tekrarlanır
adres. ns-3 tarafından gelen tüm paketler, kullanılarak Linux tarafından tekrarlanır.
hatırlanan MAC adresi. Bu, ns-3 cihaz tarafında Send() kullanmamıza izin verir.
tüm ns-3 net cihazlarında mevcuttur.

UseLocal modu, oluşturma ve oluşturma dışında ConfigureLocal moduyla aynıdır.
musluk cihazının konfigürasyonu ve MAC adresi sahtekarlığı.

TapKöprü KullanımKöprü Çalışma
ConfigureLocal modu bölümünde açıklandığı gibi, Linux ana bilgisayarı aşağıdakilerden birine yazdığında
/dev/tap devices, yazma işlemi ns-3 dünyasında yaşayan TapBridge'e yönlendirilir.
UseBridge modu durumunda, bu paketlerin ns-3'te gönderilmesi gerekecektir.
ağ, Linux köprüsüne katılan bir cihaza gönderilmiş gibi. Bu şu anlama gelir
köprülü aygıtta SendFrom() yöntemini çağırma ve kaynak MAC adresini sağlama
pakette bulundu.

Diğer yönde, bir ns-3 net cihazı tarafından alınan bir paket, geri arama yoluyla
TapBridge'i seçin. Amaç ns-3'ü köprülemek olduğundan, bu karışık modda yapılmalıdır.
net cihazını, TAP cihazının bir parçası olduğu OS (brctl) köprüsüne yerleştirin.

Bu nedenlerden dolayı, yalnızca SendFrom()'u destekleyen ve bağlanılabilir bir bağlantıya sahip ns-3 net cihazları
rastgele alma geri aramasının UseBridge moduna katılmasına izin verilir TapBridge
konfigürasyonları.

Musluk Köprü Telegram Kanal Model
Tap Bridge ile ilişkilendirilmiş kanal modeli yok. Aslında niyet etmek
gerçek internet ana bilgisayarının köprülü ağın kanalına bağlı olduğu anlaşılıyor
cihaz.

Musluk Köprü İzleme Model
Çoğu ns-3 cihazının aksine, TapBridge herhangi bir standart izleme kaynağı sağlamaz. Bu
çünkü köprü, esasen bir işlev çağrısı uzaklıkta olan bir aracıdır.
köprülü cihaz. Köprülü cihazdaki izleme kancalarının
çoğu kullanıcı için yeterli,

kullanma the TapKöprü
Çoğu kullanıcının TapBridge cihazıyla aşağıdakiler aracılığıyla etkileşime girmesini bekliyoruz.
BridgeHelper'a dokunun. CSMA veya Wifi gibi diğer yardımcı sınıfların kullanıcıları,
orada kullanılan deyimlerle rahat.

ENERJİ ÇERÇEVE

Enerji tüketimi, kablosuz cihazlar ve kablosuz ağ araştırmacıları için önemli bir sorundur
genellikle bir düğümdeki veya genel ağdaki enerji tüketimini araştırmak gerekir.
ns-3'te ağ simülasyonları çalıştırma. Bu, enerji tüketimini desteklemek için ns-3 gerektirir
modelleme. Ayrıca, yakıt hücreleri ve enerji süpürme gibi kavramlar
ortaya çıkan bu etkileri içeren düşük güçlü kablosuz cihazlar için uygun
teknolojilerin simülasyonlara dönüştürülmesi, çeşitli enerji kaynaklarının modellenmesi için destek gerektirir.
ns-3. ns-3 Enerji Çerçevesi, enerji tüketimi, enerji kaynağı için temel sağlar
ve enerji hasadı modellemesi.

Model Tanım
Enerji Çerçevesi için kaynak kodu şu anda şu adreste: kaynak/enerji.

Tasarım
ns-3 Enerji Çerçevesi 3 bölümden oluşur: Enerji Kaynağı, Cihaz Enerji Modeli ve
Enerji Harvester. Çerçeve uygulamaya konulur. kaynak/enerji/modeller klasör.

Enerji Kaynak
Enerji Kaynağı, her bir düğümdeki güç kaynağını temsil eder. Bir düğümde bir veya daha fazla olabilir
enerji kaynakları ve her bir enerji kaynağı birden fazla cihaz enerji modeline bağlanabilir.
Bir enerji kaynağının bir cihaz enerji modeline bağlanması, ilgili cihazın
kaynaktan güç çeker. Enerji Kaynağının temel işlevi,
düğümdeki cihazlar için enerji. Enerji Kaynağından enerji tamamen çekildiğinde,
her cihazın bu olaya tepki verebilmesi için düğümdeki cihazları bilgilendirir. Daha öte,
her düğüm, kalan enerji veya
enerji oranı (pil seviyesi). Bu, enerji farkında protokollerin uygulanmasını sağlar
ns-3'te.

Piller gibi çok çeşitli güç kaynaklarını modellemek için, Enerji Kaynağının
Bu sarf malzemelerinin özelliklerini yakalayabilecektir. 2 önemli var
pratik pillerle ilgili özellikler veya etkiler:

oran Kapasite Efekt
Akım çekişi nominal değerden yüksek olduğunda pil ömrünün azalması
pilin.

Tedavi Süreci Efekt
Pil, deşarj ve deşarj arasında değiştiğinde pil ömrünün artması
boşta kalma durumları.

Oran Kapasite Etkisini dahil etmek için, Enerji Kaynağı,
enerji tüketimini hesaplamak için aynı düğümdeki tüm cihazlar. Ayrıca, çoklu
Enerji Hasat Makineleri, enerjisini yenilemek için Enerji Kaynağına bağlanabilir.
Enerji Kaynağı periyodik olarak tüm cihazları ve enerji toplayıcıları aynı anda yoklar.
toplam akım tahliyesini ve dolayısıyla enerji tüketimini hesaplamak için düğüm. ne zaman bir cihaz
durumu değiştirirse, ilgili Cihaz Enerji Modeli bu durumu Enerji Kaynağına bildirecektir.
değişim ve yeni toplam akım çekimi hesaplanacaktır. Benzer şekilde, her Enerji Harvester
güncelleme, bağlı Enerji Kaynağında bir güncellemeyi tetikler.

Energy Source temel sınıfı, aygıtların (Aygıt Enerji Modeli nesneleri) bir listesini tutar ve
belirli Enerji Kaynağını kullanan enerji toplayıcılar (Enerji Harvester nesneleri)
güç kaynağı olarak. Enerji tamamen boşaldığında, Enerji Kaynağı tüm
Bu listedeki cihazlar. Daha sonra her cihaz, bu olayı bağımsız olarak ele alabilir.
elektrik kesintisi durumunda izlenmesi gereken istenen davranış.

cihaz Enerji Model
Cihaz Enerji Modeli, düğümde kurulu bir cihazın enerji tüketim modelidir.
Her aygıtın bir dizi sayıya sahip olduğu varsayıldığı durum tabanlı bir model olarak tasarlanmıştır.
durumlar ve her durum bir güç tüketimi değeri ile ilişkilendirilir. Her ne zaman devlet
cihaz değişirse, ilgili Cihaz Enerji Modeli Enerji Kaynağına aşağıdakileri bildirecektir.
cihazın yeni akım çekimi. Enerji Kaynağı daha sonra yeni toplamı hesaplayacaktır.
mevcut çekiş ve kalan enerjiyi güncelleyin.

Cihaz Enerji Modeli, sınırlı sayıda enerjiye sahip olmayan cihazlar için de kullanılabilir.
devletler. Örneğin elektrikli bir araçta motorun akım çekişi belirlenir.
hızıyla. Aracın hızı belirli bir aralıkta sürekli değerler alabildiğinden,
bir dizi ayrık çalışma durumu tanımlamak mümkün değildir. Ancak dönüştürülerek
doğrudan akıma hız değeri, aynı Cihaz Enerji Modeli API'leri seti hala
Kullan

Enerji Biçerdöver
Enerji toplayıcı, çevreden enerji toplayan unsurları temsil eder ve
bağlı olduğu Enerji Kaynağını yeniden şarj edin. Enerji hasat makinesi şunları içerir:
gerçek enerji toplama cihazının (örneğin bir güneş paneli) tam olarak uygulanması ve
çevre (örneğin, güneş radyasyonu). Bu, bir enerjinin uygulanmasında
biçerdöver, çevrenin enerji katkısı ve ek enerji
dönüşüm verimliliği gibi enerji hasat cihazının gereksinimleri ve
cihazın dahili güç tüketiminin birlikte modellenmesi gerekir.

Kablosuz internet radyo Enerji Model
WiFi Radyo Enerji Modeli, bir Wifi net cihazının enerji tüketim modelidir. BT
PHY katmanının mevcut durumlarının her biri için bir durum sağlar: Idle, CcaBusy, Tx, Rx,
Kanal Anahtarı, Uyku. Bu tür durumların her biri, bir değer (Amper cinsinden) ile ilişkilidir.
geçerli çekiliş (ilgili özellik adları için aşağıya bakın). Wifi Radyo Enerji Modeli
PHY Dinleyici, her Wifi PHY durumundan haberdar olmak için Wifi PHY'ye kayıtlıdır.
geçiş. Her geçişte, önceki durumda tüketilen enerji hesaplanır ve
kalan enerjisinin güncellenmesi için enerji kaynağına bilgi verilir.

Wifi Tx Akım Modeli, şu andaki çekilişi hesaplama imkanı verir.
birkaç durumda gözlemlendiği gibi, nominal tx gücünün (dBm cinsinden) bir fonksiyonu olarak iletim durumu
deneysel ölçümler. Bu amaçla Wifi Radyo Enerji Modeli PHY Dinleyici
mevcut çerçeveyi iletmek için kullanılan nominal tx gücünden haberdar edilir ve böyle bir
Tx'deki mevcut çekilişi güncellemekle ilgilenen Wifi Tx Mevcut Modeline değer
durum. Bu nedenle, Wifi Uzak İstasyon olsa bile enerji tüketimi doğru bir şekilde hesaplanır.
Yönetici, kare başına güç kontrolü gerçekleştirir. Şu anda Doğrusal Wifi Tx Akım Modeli
tx akımını doğrusal bir fonksiyon olarak hesaplayan uygulandı (parametrelere göre
(kullanıcı tarafından belirlenebilen) nominal tx gücünün dBm cinsinden değeri.

Wifi Radyo Enerji Modeli, çağrılan bir geri aramayı belirtme imkanı sunar
enerji kaynağı tükendiğinde. Wifi açıkken böyle bir geri arama belirtilmemişse
Modeli bir cihaza yüklemek için Radyo Enerji Model Yardımcısı kullanılır, bir geri arama
dolaylı olarak Wifi PHY'nin UYKU moduna alınması için yapılmıştır (dolayısıyla hiçbir çerçeve
Daha sonra iletilen veya alınan) enerji kaynağı tükendiğinde. Aynı şekilde,
enerji kaynağı yeniden şarj edildiğinde (ki bu
enerji kaynağına bir enerji hasat makinesinin bağlanması durumunda ortaya çıkabilir). eğer böyle bir
Yüklemek için Wifi Radyo Enerji Model Yardımcısı kullanıldığında geri arama belirtilmez.
bir cihazda modellendiğinde, Wifi PHY'nin cihazdan yeniden başlatılması için dolaylı olarak bir geri arama yapılır
Enerji kaynağı yeniden şarj edildiğinde UYKU modu.

gelecek İş
Cihaz Enerji Modelleri için diğer PHY katman modelleri için destek eklemeyi planlıyoruz.
WiMAX gibi ns-3'te sağlanır ve diğer olmayanların enerji tüketimlerini modellemek için
genel bir sensör ve bir CPU gibi iletişim cihazları. Enerji Kaynakları için,
Süperkapasitör ve Nikel-Metal gibi yeni Enerji Kaynakları türlerini dahil etmeyi planlamak
Hidrit (Ni-MH) pil. Energy Harvesters için bir enerji uygulamayı planlıyoruz.
Enerji kaynaklarını bir tabloda tanımlanan güç seviyelerine göre yeniden şarj eden hasat makinesi.
gerçek ölçümlerin kullanıcı tarafından özelleştirilebilir veri seti.

Referanslar
[1] ns-2 Enerji modeli:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu, S. Nabar ve R. Poovendran. Ağ Simülatörü 3 için Bir Enerji Çerçevesi
(ns-3)

[3] M. Handy ve D. Timmermann. Doğru bir şekilde mobil kablosuz ağların simülasyonu
doğrusal olmayan pil etkilerinin modellenmesi. Proc. Uygulamalı Simülasyon ve Modelleme
(ASM), 2003.

[4] DN Rakhmatov ve SB Vrudhula. Kullanım için analitik yüksek seviyeli bir pil modeli
taşınabilir elektronik sistemlerin enerji yönetimi. Proc. IEEE/ACM International'ın
Bilgisayar Destekli Tasarım Konferansı (ICCAD'01), sayfa 488-493, Kasım 2001.

[5] DN Rakhmatov, SB Vrudhula ve DA Wallach. için pil ömrü tahmini
enerji bilinçli bilgi işlem. Proc. 2002 Uluslararası Düşük Güç Sempozyumu
Elektronik ve Tasarım (ISLPED'02), sayfa 154-159, 2002.

[6] C. Tapparello, H. Ayetullahi ve W. Heinzelman. için Enerji Çerçevesinin Genişletilmesi
Ağ Simülatörü 3 (ns-3). ns-3 (WNS3) Çalıştayı, Poster Oturumu, Atlanta, GA,
AMERİKA BİRLEŞİK DEVLETLERİ. Mayıs 2014.

kullanım
ns-3 kullanıcılarının tipik olarak Enerji Çerçevesi ile etkileşime girmesinin ana yolu,
yardımcı API ve çerçevenin herkese açık olarak görülebilen özellikleri aracılığıyla. yardımcı
API şurada tanımlanmıştır: kaynak/enerji/yardımcı/*.h.

Enerji çerçevesini kullanmak için kullanıcının düğüm için bir Enerji Kaynağı kurması gerekir.
ilgili olarak, ağ cihazları için ilgili Cihaz Enerji Modeli ve eğer varsa
gerekliyse, bir veya daha fazla Energy Harvester. Enerji Kaynağı (nesneler)
Enerji Kaynağı Yardımcısı tarafından her düğüm. Düğüm başına birden fazla enerji kaynağına izin vermek için,
bir kaynak nesneyi doğrudan bir araya getirmek yerine bir Enerji Kaynağı Konteynerini topluyoruz.

Energy Source nesnesi, Device Energy Model ve Energy Harvester nesnelerinin bir listesini tutar.
kaynağı güç kaynağı olarak kullanmak. Cihaz Enerji Modeli nesneleri cihaza kurulur.
Cihaz Enerji Modeli Yardımcısı tarafından Enerji Kaynağı, Energy Harvester nesnesi ise
Energy Harvester Helper tarafından yüklenir. Kullanıcı Cihaz Enerji Modeli nesnelerine erişebilir
Bireyin enerji tüketim bilgilerini elde etmek için Enerji Kaynağı nesnesi aracılığıyla
cihazlar. Ayrıca, kullanıcı toplamak için Energy Harvester nesnelerine erişebilir.
mevcut hasat edilebilir güç ve hasat edilen toplam enerji ile ilgili bilgiler
biçerdöver.

Örnekler
Örnek dizinler, kaynak/örnekler/enerji ve örnekler/enerji, bazı temel kodlar içerir
çerçevenin nasıl kurulacağını gösterir.

Yardımcılar
Enerji Kaynak Yardımcı
Energy Source nesneleri için temel yardımcı sınıf, bu yardımcı Agregates Energy Source nesnesi
bir düğüme. Bu sınıfın alt uygulaması, gerçek Energy Source nesnesini oluşturur.

cihaz Enerji Model Yardımcı
Cihaz Enerji Modeli nesneleri için temel yardımcı sınıf, bu yardımcı Cihaz Enerjisini ekler
Nesneleri Enerji Kaynağı nesnelerine modelleyin. Bu sınıfın alt uygulaması,
gerçek Cihaz Enerji Modeli nesnesi.

Enerji Hasat Yardımcı
Energy Harvester nesneleri için temel yardımcı sınıf, bu yardımcı Energy Harvester'ı ekler
nesneleri Enerji Kaynağı nesnelerine Bu sınıfın alt uygulaması, gerçek
Enerji Harvester nesnesi.

Özellikler
Nitelikler Enerji Kaynakları, Cihazlar, Enerji Modelleri ve Enerji Hasat Makineleri arasında farklılık gösterir
uygulamalar, lütfen ayrıntılar için belirli alt sınıfa bakın.

Basic Enerji Kaynak
· TemelEnerjiKaynağıİlkEnerjiJ: Temel enerji kaynağında depolanan başlangıç ​​enerjisi.

· TemelEnerjiTedarikVoltajV: Temel enerji kaynağı için başlangıç ​​besleme gerilimi.

· PeriyodikEnerji Güncelleme Aralığı: Ardışık iki periyodik enerji güncellemesi arasındaki süre.

RV pil Model
· RvBatteryModelPeriyodikEnerji Güncelleme Aralığı: RV akü modeli örnekleme aralığı.

· RvAküModeliAçıkDevreVoltaj: RV akü modeli açık devre voltajı.

· RvPilModeliKesmeVoltaj: RV akü modeli kesme gerilimi.

· RvBatteryModelAlphaDeğeri: RV akü modeli alfa değeri.

· RvBatteryModelBetaDeğeri: RV akü modeli beta değeri.

· RvPilModeliNumOfTerms: Pil tahmini için sonsuz toplamın terim sayısı
seviye.

Kablosuz internet radyo Enerji Model
· BoşAkımA: Amper cinsinden varsayılan radyo Boşta akımı.

· CcaMeşgulMevcutA: Amper cinsinden varsayılan radyo CCA Meşgul Durumu akımı.

· TxCurrentA: Amper cinsinden radyo Tx akımı.

· RxCurrentA: Amper cinsinden radyo Rx akımı.

· AnahtarlamaAkımıA: Amper cinsinden varsayılan radyo Kanal Anahtarı akımı.

· UykuMevcutA: Amper cinsinden radyo Uyku akımı.

· TxCurrentModeli: Ekli tx mevcut modeline bir işaretçi.

Basic Enerji Biçerdöver
· PeriyodikHarvestedPowerUpdateInterval: İki ardışık periyodik güncelleme arasındaki süre
hasat edilen güç.

· Hasat EdilebilirGüç: Sağlanan güç miktarını temsil eden rastgele değişkenler
enerji hasat makinesi tarafından.

İzleme
İzlenen değerler Enerji Kaynakları, Cihazlar Enerji Modelleri ve Enerji Hasat Makineleri arasında farklılık gösterir
uygulamalar, lütfen ayrıntılar için belirli alt sınıfa bakın.

Basic Enerji Kaynak
· Kalan Enerji: BasicEnergySource'da kalan enerji.

RV pil Model
· RvPilModelPilSeviyesi: RV akü modeli pil seviyesi.

· RvPilModelPilÖmür Boyu: RV pil modeli pil ömrü.

Kablosuz internet radyo Enerji Model
· ToplamEnerji Tüketimi: Telsiz cihazının toplam enerji tüketimi.

Basic Enerji Biçerdöver
· Hasat Gücü: BasicEnergyHarvester tarafından sağlanan mevcut güç.

· ToplamEnerjiHasat: BasicEnergyHarvester tarafından toplanan toplam enerji.

Onaylama
Enerji Çerçevesinin gerçek cihazlarla karşılaştırılması yapılmamıştır. Akım
Enerji Çerçevesinin uygulanması, hesaplama hataları için sayısal olarak kontrol edilir. bu
RV pil modeli, sonuçların orijinalinde sunulanlarla karşılaştırılmasıyla doğrulanır.
RV pil model kağıdı.

AKIŞI MONITOR

Model Tanım
Yeni modülün kaynak kodu dizinde bulunur kaynak/akış monitörü.

Akış İzleme modülünün amacı, bileşenlerin performansını ölçmek için esnek bir sistem sağlamaktır.
ağ protokolleri. Modül, takip etmek için ağ düğümlerine kurulu probları kullanır.
düğümler tarafından değiştirilen paketler ve bir dizi parametreyi ölçecektir. paketler
ait oldukları akışa göre bölünür, burada her akış,
probun özellikleri (örneğin, IP için bir akış, aynı özelliklere sahip paketler olarak tanımlanır)
{protokol, kaynak (IP, bağlantı noktası), hedef (IP, bağlantı noktası)} tanımlama grubu.

Her akış için toplanan istatistikler XML formatında dışa aktarılabilir. Ayrıca,
kullanıcı, her bir akış hakkında belirli istatistikler talep etmek için doğrudan sondalara erişebilir.

Tasarım
Flow Monitor modülü modüler bir şekilde tasarlanmıştır. Alt sınıflama ile genişletilebilir
ns3::Akış Sondası ve ns3::FlowSınıflandırıcı.

Tam modül tasarımı [FlowMonitor]'da açıklanmıştır.

kapsam ve Sınırlamalar
Şu anda IPv4 ve IPv6 için problar ve sınıflandırıcılar mevcuttur.

Her araştırma paketleri dört noktada sınıflandıracaktır:

· Bir paket gönderildiğinde (SendOutgoing IPv[4,6] izleri)

· Bir paket iletildiğinde (UnicastForward IPv[4,6] izleri)

· Bir paket alındığında (LocalDeliver IPv[4,6] izleri)

· Bir paket düştüğünde (IPv[4,6] izlerini bırak)

Paketler IP düzeyinde izlendiğinden, L4 protokollerinden kaynaklanan herhangi bir yeniden iletim
(örneğin, TCP) sonda tarafından yeni bir paket olarak görülecektir.

Pakete bir Etiket eklenecektir (ns3::Ipv[4,6]FlowProbeEtiketi). Etiket temel taşıyacak
paketin verileri, paketin sınıflandırılması için kullanışlıdır.

Şu ana kadar sadece L4 (TCP, UDP) paketlerinin sınıflandırıldığının altı çizilmelidir. Dahası,
sadece tek noktaya yayın paketleri sınıflandırılacaktır. Bu sınırlamalar gelecekte kaldırılabilir.

Her akış için toplanan veriler şunlardır:

· timeFirstTxPacket: akıştaki ilk paket iletildiğinde;

· timeLastTxPacket: akıştaki son paketin iletildiği zaman;

· timeFirstRxPacket: akıştaki ilk paket bir uç düğüm tarafından alındığında;

· timeLastRxPacket: akıştaki son paket alındığında;

· delaySum: akışın alınan tüm paketleri için tüm uçtan uca gecikmelerin toplamı;

· jitterSum: tümü için tüm uçtan uca gecikme jitter (gecikme değişimi) değerlerinin toplamı
içinde tanımlandığı gibi, akışın alınan paketleri RFC 3393;

· txBytes, txPackets: akış için iletilen toplam bayt / paket sayısı;

· rxBytes, rxPackets: akış için alınan toplam bayt/paket sayısı;

· LostPackets: Kaybolduğu varsayılan toplam paket sayısı (10'dan fazla rapor edilmez)
saniye);

· timesForwarded: bir paketin bildirildiği üzere iletilme sayısı;

· delayHistogram, jitterHistogram, packageSizeHistogram: gecikme için histogram versiyonları,
sırasıyla titreşim ve paket boyutları;

· packagesDropped, bytesDropped: kayıp paketlerin ve baytların sayısı, buna göre bölünür.
kayıp neden kodu (araştırmada tanımlanmıştır).

Probların IP başlıkları dahil olmak üzere paket baytlarını ölçtüğünü belirtmekte fayda var.
L2 başlıkları ölçüye dahil değildir.

Bu istatistikler, istek üzerine XML biçiminde yazılacaktır (bkz. Kullanım bölümü).

Referanslar
[Akış Monitörü]

G. Carneiro, P. Fortuna ve M. Ricardo. 2009. FlowMonitor: bir ağ izleme çerçevesi
ağ simülatörü 3 (NS-3) için. Dördüncü Uluslararası ICST Bildirilerinde
Performans Değerlendirme Metodolojileri ve Araçları Konferansı (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

kullanım
Modül kullanımı son derece basittir. Yardımcı her şeyle ilgilenecek.

Tipik kullanım:

// Akış monitörü
Ptr akış Monitörü;
FlowMonitorYardımcısı akışYardımcısı;
flowMonitor = flowHelper.InstallAll();

Simülatör::Dur (Saniye(stop_time));
Simülatör::Çalıştır ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", true, true);

the SerileştirmeToXmlDosyası () fonksiyon 2. ve 3. parametreler sırasıyla
histogramları ve prob başına ayrıntılı istatistikleri etkinleştirin/devre dışı bırakın.

Diğer olası alternatifler Doxygen belgelerinde bulunabilir.

Yardımcılar
Yardımcı API, normal yardımcıların kalıp kullanımını takip eder. Yardımcı aracılığıyla yapabilirsiniz
monitörü düğümlere kurun, monitör özelliklerini ayarlayın ve istatistikleri yazdırın.

Önemli bir şey şudur: ns3::FlowMonitorYardımcısı içinde yalnızca bir kez somutlaştırılmalıdır.
ana.

Özellikler
Modül aşağıdaki özellikleri sağlar: ns3::Akış Monitörü:

· MaxPerHopDelay (Süre, varsayılan 10s): Dikkate alınması gereken maksimum atlama başına gecikme;

· Başlangıç ​​Zamanı (Zaman, varsayılan 0s): İzlemenin başladığı zaman;

· DelayBinWidth (çift, varsayılan 0.001): Gecikme histogramında kullanılan genişlik;

· JitterBinWidth (çift, varsayılan 0.001): Titreşim histogramında kullanılan genişlik;

· PacketSizeBinWidth (double, varsayılan 20.0): packageSize histogramında kullanılan genişlik;

· FlowInterruptionsBinWidth (double, varsayılan 0.25):
akış Kesintileri histogramı;

· FlowInterruptionsMinTime (çift, varsayılan 0.5): Varışlar arası minimum süre
akış kesintisi olarak kabul edilir.

Çıktı
Ana model çıktısı, akış istatistikleri hakkında XML formatlı bir rapordur. Bir örnek:




























Çıktı, 10.1.3.1'den 10.1.2.2'ye kadar bir TCP akışı tarafından üretildi.

İndeks 2 probunun şundan daha fazla paket ve daha fazla bayt rapor ettiğini belirtmekte fayda var.
diğer problemler. Paketler IP'de parçalandığı için bu tamamen normal bir davranıştır.
bu düğümdeki seviye.

Ayrıca alıcı düğümün araştırmasının (indeks 4)
Parçalar, yeniden birleştirme sondalama noktasından önce yapıldığından.

Örnekler
Örnekler şurada yer almaktadır: src/akış monitörü/örnekler.

Ayrıca, aşağıdaki örnekler akış izleme modülünü kullanır:

· örnekler/matris-topoloji/matris-topoloji.cc

· örnekler/yönlendirme/manet-yönlendirme-karşılaştırma.cc

· örnekler/yönlendirme/simple-global-routing.cc

· örnekler/tcp/tcp-variants-comparison.cc

· örnekler/kablosuz/multirate.cc

· örnekler/kablosuz/wifi-hidden-terminal.cc

Sorun giderme
Birden fazla tanımlamayın ns3::FlowMonitorYardımcısı simülasyonda.

Onaylama
Referanslardaki makale, bir modül doğrulamasının tam bir tanımını içerir.
ağ testi.

Histogramın doğru işlevselliğini sağlamak için testler sağlanır.

İNTERNET MODELLER

Internet Yığın
Internet yığın toplanma
çıplak bir sınıf Düğüm olduğu gibi çok kullanışlı değil; diğer nesneler buna toplanmalıdır
yararlı düğüm işlevselliği sağlar.

The ns-3 kaynak kodu dizini kaynak/internet TCP/IPv4'ün uygulanmasını sağlar ve
IPv6 ile ilgili bileşenler. Bunlar arasında IPv4, ARP, UDP, TCP, IPv6, Komşu Keşfi ve
diğer ilgili protokoller.

İnternet Düğümleri, Düğüm sınıfının alt sınıfları değildir; onlar sadece sahip olan Düğümlerdir.
onlara toplanmış bir grup IP ile ilgili nesne. Elle veya bir araçla bir araya getirilebilirler.
yardımcı fonksiyon InternetStackHelper::Yükle () hangi tüm düğümlere aşağıdakileri yapar
argüman olarak geçti:

geçersiz
InternetStackHelper::Yükle (Ptr düğüm) sabit
{
if (m_ipv4Etkin)
{
/* IPv4 yığını */
if (düğüm->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): Toplama "
"mevcut bir Ipv4 nesnesine sahip bir düğüme bir InternetStack");
dönmek;
}

CreateAndAggregateObjectFromTypeId (düğüm, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (düğüm, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (düğüm, "ns3::Icmpv4L4Protocol");
// Yönlendirmeyi ayarla
Ptr ipv4 = düğüm->GetObject ();
Ptr ipv4Routing = m_routing->Oluştur (düğüm);
ipv4->SetRoutingProtocol (ipv4Routing);
}

if (m_ipv6Etkin)
{
/* IPv6 yığını */
if (düğüm->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): Toplama "
"mevcut bir Ipv6 nesnesine sahip bir düğüme bir InternetStack");
dönmek;
}

CreateAndAggregateObjectFromTypeId (düğüm, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (düğüm, "ns3::Icmpv6L4Protocol");
// Yönlendirmeyi ayarla
Ptr ipv6 = düğüm->GetObject ();
Ptr ipv6Routing = m_routingv6->Oluştur (düğüm);
ipv6->SetRoutingProtocol (ipv6Routing);

/* IPv6 uzantılarını ve seçeneklerini kaydet */
ipv6->RegisterExtensions();
ipv6->RegisterOptions();
}

eğer (m_ipv4Enabled || m_ipv6Enabled)
{
/* UDP ve TCP yığınları */
CreateAndAggregateObjectFromTypeId (düğüm, "ns3::UdpL4Protocol");
düğüm->AggregateObject (m_tcpFactory.Create ());
Ptr fabrika = CreateObject ();
düğüm->AggregateObject (fabrika);
}
}

Birden çok uygulamanın bulunduğu durumlarda ns-3 (TCP, IP yönlendirme), bu nesneler tarafından eklenir
bir fabrika nesnesi (TCP) veya bir yönlendirme yardımcısı (m_routing) tarafından.

Yönlendirme protokolünün bu işlevin dışında yapılandırıldığını ve ayarlandığını unutmayın. Varsayılan olarak,
aşağıdaki protokoller eklenir:

geçersiz InternetStackHelper::Initialize ()
{
SetTcp ("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper staticRouting;
Ipv4GlobalRoutingHelper globalRouting;
Ipv4ListRoutingYardımcı listesiYönlendirme;
Ipv6ListRoutingYardımcı listesiRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add (statikYönlendirme, 0);
listRouting.Add (globalRouting, -10);
listRoutingv6.Add (statikRoutingv6, 0);
SetRoutingHelper (listRouting);
SetRoutingHelper (listRoutingv6);
}

Varsayılan olarak, IPv4 ve IPv6 etkinleştirilmiştir.

Internet Düğüm yapı
IP özellikli bir Düğüm (bir ns-3 Bir veya daha fazla IP yığınına sahip olmak için toplamayla artırılan düğüm)
aşağıdaki iç yapıya sahiptir.

Katman-3 protokolleri
En alt katmanda, NetDevices'in üzerinde oturan "katman 3" protokolleri bulunur.
IPv4, IPv6, ARP vb. Sınıf Ipv4L3Protokol olan bir uygulama sınıfıdır
genel arayüz tipik olarak sınıftır iPv4, ancak Ipv4L3Protocol genel API'si de kullanılıyor
şu anda dahili olarak.

Ipv4L3Protocol sınıfında, aşağıda açıklanan bir yöntem Teslim almak ():

/ **
* Alt katman, L3Demux::Lookup çağrıldıktan sonra bu yöntemi çağırır.
* ARP alt sınıfının, bunun hangi NetDevice'den geldiğini bilmesi gerekir.
* paket geliyor:
* - NetDevice ARP önbelleği başına uygulayın
* - arp yanıtlarını doğru cihaza geri gönder
*/
geçersiz Alma (Ptr cihaz, Ptr p, uint16_t protokolü,
const Adres &from, const Adres &to, NetDevice::PacketType packageType);

İlk olarak, şunu unutmayın: Teslim almak () fonksiyonun ReceiveCallback ile eşleşen bir imzası var
sınıfta Düğüm. Bu işlev işaretçisi, şu durumlarda Düğümün protokol işleyicisine eklenir:
Arayüz ekle () denir. Gerçek kayıt, aşağıdaki gibi bir ifade ile yapılır.
aşağıdaki gibidir:

RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Al, ipv4),
Ipv4L3Protokol::PROT_NUMBER, 0);

Ipv4L3Protocol nesnesi, Düğümde toplanır; sadece bir tane böyle Ipv4L3Protocol var
nesne. Ipv4L3Protocol'a gönderilecek bir paketi olan daha yüksek katman protokolleri
nesne arayabilir GetObject () aşağıdaki gibi bir işaretçi elde etmek için:

Ptr ipv4 = m_node->GetObject ();
eğer (ipv4 != 0)
{
ipv4->Gönder (paket, saddr, Daddr, PROT_NUMBER);
}

Bu sınıf, yararlandığımız iki tekniği güzel bir şekilde gösterir. ns-3 nesneleri birbirine bağlamak için:
geri aramalar ve nesne toplama.

IPv4 yönlendirmesi, bir paketin yerel düğüm için olduğunu belirlediğinde, onu yukarı iletir.
yığın. Bu, aşağıdaki işlevle yapılır:

geçersiz
Ipv4L3Protocol::LocalDeliver (Ptr paket, Ipv4Header const&ip, uint32_t iif)

İlk adım, IP protokol numarasına göre doğru Ipv4L4Protocol nesnesini bulmaktır.
Örneğin, TCP, demux'da protokol numarası 6 olarak kayıtlıdır. Almak()
Ipv4L4Protocol üzerinde işlev (örneğin TcpL4Protokol::Al denir.

Henüz Ipv4Interface sınıfını tanıtmadık. Temel olarak, her NetDevice eşleştirilmiştir.
bu tür bir cihazın IPv4 temsili ile. Linux'ta bu sınıf IPv4Arayüzü kabaca
karşılık gelir yapı cihazda; asıl amaç adres-aile sağlamak
bir arayüz hakkında belirli bilgiler (adresler).

Gönderilen, alınan ve kaybolan paketleri izlemek için tüm sınıfların uygun izleri vardır.
Kullanıcıların, bir paketin bırakılıp bırakılmadığını (ve nerede) olduğunu öğrenmek için bunları kullanmaları teşvik edilir. A
Yaygın bir hata, paketleri gönderirken yerel kuyrukların etkilerini unutmaktır, örn.
ARP kuyruğu. Bu, özellikle jumbo paketler veya paket patlamaları gönderirken kafa karıştırıcı olabilir.
UDP'yi kullanarak. ARP önbellek bekleyen kuyruğu sınırlıdır (3 veri birimi) ve IP paketleri
parçalanmış, ARP önbellek kuyruğu boyutunu kolayca aşırı doldurabilir. Bu durumlarda işe yarar
ARP önbellek bekleyen boyutunu uygun bir değere yükseltin, örneğin:

Config::SetDefault ("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3));

IPv6 uygulaması benzer bir mimariyi takip eder. Çift yığınlı düğümler (bir
hem IPv4 hem de IPv6) desteği, bir IPv6 soketinin IPv4 bağlantılarını bir
standart çift yığınlı sistem yapar. Bir IPv6 uç noktasını bağlı ve dinleyen bir soket,
bir IPv4 bağlantısı alır ve uzak adresi IPv4 eşlemeli bir adres olarak döndürür.
IPV6_V6ONLY soket seçeneği için destek şu anda mevcut değil.

Katman-4 protokolleri ve soketler
Daha sonra taşıma protokollerinin, soketlerin ve uygulamaların nasıl birbirine bağlandığını açıklayacağız. İçinde
Özetle, her taşıma protokolü uygulaması bir soket fabrikasıdır. bir uygulama
yeni bir sokete ihtiyacı var

Örneğin, bir UDP soketi oluşturmak için bir uygulama, aşağıdaki gibi bir kod parçacığını kullanır:
Aşağıdaki:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket();
m_socket->Bind (m_local_address);
Kendi ID’n ile mağazalarını oluştur

Yukarıdakiler, UDP soket fabrikasına bir işaretçi almak için düğümü sorgulayacak, bir tane oluşturacaktır.
bu tür bir soket ve soketi, C-tabanlı soketler API'sine benzer bir API ile kullanacak, örneğin
as Bağlantı Kurun () ve Gönder (). Adrese geçti bağlamak (), Bağlantı Kurun ()ya da Gönder ()
fonksiyonlar bir olabilir IPv4Adresi, IPv6Adresiya da Adres. Eğer bir Adres geçirilir ve
dışında bir şey içerir IPv4Adresi or IPv6Adresi, bu işlevler bir
hata. NS bağlamak (geçersiz) ve bağlama6 (geçersiz) işlevler "0.0.0.0" ve "::" öğelerine bağlanır
respectivamente.

Soket ayrıca belirli bir NetDevice'a da bağlanabilir. BindToNetDevice
(Ptr ağ cihazı) fonksiyonu. BindToNetDevice (Ptr ağ cihazı) bağlayacak
soketi "0.0.0.0" ve "::" (çağırmaya eşdeğer) bağlamak () ve bağlama6 (), sürece
soket zaten belirli bir adrese bağlı. Özetlemek, doğru sıra
olduğu:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);
Kendi ID’n ile mağazalarını oluştur

ya da alışveriş sepetinize tıklayın:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket();
m_socket->Bind (m_local_address);
m_socket->BindToNetDevice (n_netDevice);
Kendi ID’n ile mağazalarını oluştur

Aşağıdakiler bir hata oluşturur:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);
m_socket->Bind (m_local_address);
Kendi ID’n ile mağazalarını oluştur

başlıklı bölüme bakın ns-3 Daha fazla bilgi için soketler.

Şimdiye kadar bir soket fabrikasını tanımladık (örn. sınıf UDP) ve olabilecek bir soket
uzmanlaşmış (örneğin, sınıf UdpSocket). ile ilgili birkaç anahtar nesne daha vardır.
bir paketi bir veya daha fazla alıcı sokete demultipleks etme özel görevi. Anahtar
bu görevdeki nesne sınıftır Ipv4EndPointDemux. Bu çoğullayıcı, nesnelerini depolar.
sınıf IPv4Bitiş Noktası. Bu sınıf, adresleme/bağlantı noktası demetini (yerel bağlantı noktası, yerel bağlantı noktası) tutar.
Soketle ilişkili adres, hedef bağlantı noktası, hedef adres) ve bir alıcı
geri aramak. Bu geri arama, soket tarafından kaydedilen bir alma işlevine sahiptir. bu
Arama () Ipv4EndPointDemux işlevi, Ipv4EndPoint nesnelerinin bir listesini döndürür (
birden fazla soket paketle eşleşebileceğinden bir liste olabilir). 4. katman protokolü kopyaları
paketi her Ipv4EndPoint'e gönderir ve İleri Yukarı () daha sonra çağıran yöntem
Teslim almak () soket tarafından kaydedilen fonksiyon.

Gerçek sistemlerde sockets API ile çalışırken ortaya çıkan bir sorun,
bir tür G/Ç kullanarak bir soketten okumayı yönetin (örn.
asenkron, ...). ns-3 soket G/Ç için eşzamansız bir model uygular; uygulama
okunmaya hazır alınan verilerden haberdar edilecek bir geri arama ayarlar ve geri arama
veri mevcut olduğunda taşıma protokolü tarafından çağrılır. Bu geri arama şu şekilde belirtilir:
aşağıdaki gibidir:

void Socket::SetRecvCallback (Geri Arama ,
Ptr ,
const Adres&> alınanVeriler);

Alınan veriler Paket veri arabelleğinde iletilir. Örnek bir kullanım
sınıf PaketSink:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this));

Özetlemek gerekirse, dahili olarak UDP uygulaması şu şekilde organize edilmiştir:

· A UdpImpl UDP soket fabrikası işlevselliğini uygulayan sınıf

· A UdpL4Protokol soketten bağımsız protokol mantığını uygulayan sınıf

· A UdpSocketImpl UDP'nin sokete özgü yönlerini uygulayan sınıf

· denilen bir sınıf IPv4Bitiş Noktası adresleme demetini (yerel bağlantı noktası, yerel adres,
Soketle ilişkili hedef bağlantı noktası, hedef adres) ve bir alma
soket için geri arama.

IP özellikli düğüm arayüzler
IP özellikli Düğümün uygulama ayrıntılarının çoğu veya dahili nesnelerin kendileri
nesneler, simülatör genel API'sinde gösterilmez. Bu, farklı
uygulamalar; örneğin, yerelin değiştirilmesi ns-3 portlanmış TCP/IP yığını olan modeller
kodu.

Tüm bu nesnelerin C++ genel API'leri şurada bulunur: kaynak/ağ dizin,
başlıca dahil:

· adres.h

· soket.h

· düğüm.h

· paket.h

Bunlar tipik olarak, kullanılan varsayılan değerleri uygulayan temel sınıf nesneleridir.
uygulama, durum değişkenlerini, ana bilgisayar özniteliklerini almak/ayarlamak için erişim yöntemlerini uygulayın ve
gibi müşterilere maruz kalan herkese açık yöntemleri uygulamak Yuva Oluştur.

Örnek E-posta yol of a paket
Bu iki şekil, paketlerin İnternet üzerinden nasıl aktığını gösteren örnek bir yığın izini göstermektedir.
Düğüm nesneleri.
[image] Bir paketin yolunu gönder..UNINDENT
[image] Bir paketin alma yolu..UNINDENT

IPv4
Yer Tutucu bölüm

IPv6
Bu bölüm aşağıdakileri açıklar: ns-3 IPv6 modeli yetenekleri ve sınırlamaları ile birlikte
kullanım ve örnekler.

IPv6 model tanım
IPv6 modeli, Linux uygulamasından sonra gevşek bir yapıya sahiptir; uygulama
IPv6'nın bazı özellikleri simülasyon çalışmaları için fazla ilgi çekici olmadığından tamamlanmamıştır ve
IPv6'nın bazı özellikleri henüz modellenmemiştir. ns-3.

temel sınıf iPv6 sınıf, genel bir API tanımlarken Ipv6L3Protokol gerçek mi
Protokolü uygulayan sınıf. IPv6 yığını tarafından kullanılan gerçek sınıflar bulunur
esas olarak dizinde kaynak/internet.

IPv6'nın uygulanması aşağıdaki dosyalarda bulunur:

kaynak/internet/model/icmpv6-başlığı.{cc,h}
kaynak/internet/model/icmpv6-l4-protokol.{cc,h}
kaynak/internet/model/ipv6.{cc,h}
kaynak/internet/model/ipv6-adres-oluşturucu.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
kaynak/internet/model/ipv6 uç noktası.{cc,h}
kaynak/internet/model/ipv6-bitiş noktası-demux.{cc,h}
kaynak/internet/model/ipv6 uzantısı.{cc,h}
kaynak/internet/model/ipv6-uzantı-demux.{cc,h}
kaynak/internet/model/ipv6-uzantı-başlığı.{cc,h}
kaynak/internet/model/ipv6 başlığı.{cc,h}
kaynak/internet/model/ipv6-arayüz.{cc,h}
kaynak/internet/model/ipv6-arayüz-adresi.{cc,h}
kaynak/internet/model/ipv6-l3 protokolü.{cc,h}
kaynak/internet/model/ipv6-list-yönlendirme.{cc,h}
kaynak/internet/model/ipv6 seçeneği.{cc,h}
kaynak/internet/model/ipv6-seçenek-demux.{cc,h}
kaynak/internet/model/ipv6-seçenek-başlığı.{cc,h}
kaynak/internet/model/ipv6-paket-bilgi etiketi.{cc,h}
kaynak/internet/model/ipv6-pmtu-önbellek.{cc,h}
kaynak/internet/model/ipv6-ham-soket-fabrika.{cc,h}
kaynak/internet/model/ipv6-ham-soket-fabrika-impl.{cc,h}
kaynak/internet/model/ipv6-ham-soket-impl.{cc,h}
kaynak/internet/model/ipv6 yolu.{cc,h}
kaynak/internet/model/ipv6-yönlendirme protokolü.{cc,h}
kaynak/internet/model/ipv6-yönlendirme tablosu girişi.{cc,h}
kaynak/internet/model/ipv6-statik yönlendirme.{cc,h}
kaynak/internet/model/ndisc-önbellek.{cc,h}
kaynak/ağ/utils/inet6-soket-adresi.{cc,h}
kaynak/ağ/utils/ipv6 adresi.{cc,h}

Ayrıca bazı yardımcılar IPv6 ile ilgilidir:

kaynak/internet/yardımcı/internet yığını yardımcısı.{cc,h}
kaynak/internet/yardımcı/ipv6-adres-yardımcısı.{cc,h}
kaynak/internet/yardımcı/ipv6-arayüz-kapsayıcı.{cc,h}
kaynak/internet/yardımcı/ipv6-list-yönlendirme-yardımcısı.{cc,h}
kaynak/internet/yardımcı/ipv6-yönlendirme-yardımcısı.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

Model dosyaları kabaca ayrılabilir:

· protokol modelleri (örn. ipv6, ipv6-l3-protokol, icmpv6-l4-protokol, vb.)

· yönlendirme modelleri (yani adında 'yönlendirme' olan herhangi bir şey)

· Soketler ve arabirimler (örn. ipv6-ham-soket, ipv6-arayüz, ipv6-uç noktası, vb.)

· adresle ilgili şeyler

· başlıklar, seçenek başlıkları, uzantı başlıkları vb.

· aksesuar sınıfları (örneğin, ndisc-cache)

kullanım
Aşağıdaki açıklama, örnek kodda bulunan tipik yardımcıların kullanımına dayanmaktadır.

IPv6'nın bir düğümde etkinleştirilmesi gerekmez. mevcut olana otomatik olarak eklenir
İnternet Yığını yüklendikten sonra protokoller.

Için değil IPv6'yı IPv4 ile birlikte kurun, kullanmak mümkündür
ns3::InternetStackYardımcısı yöntem SetIpv6StackInstall (bool etkinleştirme) yüklemeden önce
Düğümlerde InternetStack.

Yalnızca IPv6 ağına sahip olmanın (yani, IPv4 yığınını bir düğüme kurmamanın) bir
kullanmalı ns3::InternetStackYardımcısı yöntem SetIpv4StackInstall (bool etkinleştirme) önce
yığın kurulumu.

Örnek olarak, aşağıdaki kodda düğüm 0 hem IPv4 hem de IPv6'ya sahip olacaktır, yalnızca düğüm 1
Yalnızca IPv6 ve düğüm 2 IPv4:

NodeContainer n;
n.Oluştur (3);

InternetStackHelper interneti;
Yalnızca InternetStackHelper internetV4;
Yalnızca InternetStackHelper internetV6;

internetV4only.SetIpv6StackInstall (yanlış);
internetV6only.SetIpv4StackInstall (yanlış);

internet.Yükle (n.Get (0));
internetV6only.Install (n.Get (1));
internetV4only.Install (n.Get (2));

IPv6 adresleri atama
IPv6'yı bir ağ üzerinde kullanmak için yapılacak ilk şey IPv6 adreslerinin atanmasıdır.

Herhangi bir IPv6 etkin ns-3 düğümde en az bir NetDevice olacaktır: ns3::LoopbackNetDevice.
Geri döngü aygıt adresi :: 1. Diğer tüm NetDevices bir veya daha fazla IPv6'ya sahip olacaktır.
adresler:

· Bir bağlantı yerel adresi: fe80::arayüz ID, Burada arayüzey ID türetilmiştir
NetDevice MAC adresi.

· Sıfır veya daha fazla global adres, örn. 2001: db8 :: 1.

Tipik olarak, bir arayüzdeki ilk adres, global ile bağlantı-yerel adres olacaktır.
adres(ler) aşağıdaki gibidir.

IPv6 genel adresleri şunlar olabilir:

· manuel olarak atanmış

· otomatik oluşturuldu

ns-3 her iki yöntemi de kullanabilir ve bunun sonuçlarını anlamak oldukça önemlidir.
her ikisi de.

El ile atanmış IPv6 adresler
Bu muhtemelen en kolay ve en çok kullanılan yöntemdir. Örnek olarak:

Ptr n0 =OluşturNesne ();
Ptr n1 =OluşturNesne ();
NodeContainer ağı (n0, n1);
CsmaYardımcı csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("IPv6 Adreslerini Ata.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Adresi ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign (ndc);

Bu yöntem, düğümlere iki global IPv6 adresi ekleyecektir. IPv6 için her zamanki gibi,
tüm düğümlerin ayrıca bir yerel bağlantı adresi olacaktır. Tipik olarak bir bilgisayardaki ilk adres
arabirim, genel adres(ler) aşağıdaki gibi olacak şekilde yerel bağlantı olacaktır.
olanlar.

Genel adreslerin MAC adresinden türetileceğini unutmayın. Sonuç olarak,
benzer adreslere sahip olmayı bekliyoruz 2001:db8::200:ff:fe00:1.

Bir düğüme birden fazla global adres atamak için yukarıdakileri tekrarlamak mümkündür.
Ancak, nedeniyle IPv6AdresiYardımcısı singleton doğası, kişi önce tüm
bir ağın adreslerini seçin, ardından ağ tabanını değiştirin (Temel Ayarla), ardından yeni bir atama yapın.

Alternatif olarak, bir düğüme belirli bir adres atamak da mümkündür:

Ptr n0 =OluşturNesne ();
NodeContainer ağı (n0);
CsmaYardımcı csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("Özel Olarak Bir IPv6 Adresi Atayın.");
Ipv6AddressHelper ipv6;
Ptr cihaz = ndc.Get (0);
Ptr düğüm = cihaz->GetNode();
Ptr ipv6proto = düğüm->GetObject ();
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (aygıt);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

Otomatik oluşturuldu IPv6 adresler
Bu, sınıf tarafından uygulanan RADVD protokolüne güvenerek gerçekleştirilir. radvd. At
zaman bu uygulama için bir yardımcı yoktur ve kullanımı oldukça zordur (bkz.
örnekler/ipv6/radvd.cc).

Bu yöntemi kullandıktan sonra, düğümler dinamik olarak (örn. simülasyon sırasında) kazanacaktır.
RADVD yapılandırmasına göre bir (veya daha fazla) genel adres(ler). Bu adresler
RADVD tarafından duyurulan öneki ve düğümün EUI-64'ünü temel alacaktır.

rastgele oluşturulmuş IPv6 adresler
IPv6 gerçek düğümleri, gizliliği korumak için rastgele oluşturulmuş adresleri kullanacak olsa da, ns-3 yok
Bu yeteneğe sahip DEĞİLDİR. Bu özellik şu ana kadar ilginç olarak kabul edilmedi.
simülasyon.

çift Adres Bulma (BABA)
DAD gerçekleştirecek olan düğümler (bir Icmpv6L4Protokol bağlanmak). Üzerine
ancak bir DAD alan düğümler buna tepki vermeyecektir. Olduğu gibi: DAD reaksiyonu eksik yani
uzak. Ana neden, rasgele oluşturulmuş adres yeteneğinin eksik olmasına dayanır. Dahası,
beri ns-3 düğümler genellikle iyi davranır, burada herhangi bir Yinelenen Adres olmamalıdır.
Bu, gerçek dünyaya entegre edilmiş sorunlardan kaçınmak için gelecekte değiştirilebilir.
simülasyonlar.

Ev Sahibi ve yönlendirici davranış in IPv6 ve ns-3
IPv6'da arasında net bir ayrım vardır. yönlendiriciler ve ana. Tahmin edilebileceği gibi,
ana bilgisayarlar düşerken yönlendiriciler paketleri bir arabirimden başka bir arabirime iletebilir
paketler onlara yönlendirilmez.

Ne yazık ki, bu ayrımdan etkilenen tek şey yönlendirme değildir ve
örneğin bir arayüzden gelen paketleri iletmek için iletme kendi kendine ince ayarlanmış olabilir.
ve paketleri başka bir arayüzden bırakın.

In ns-3 bir düğüm, bir ev sahibi varsayılan olarak. Değiştirmenin iki ana yolu vardır
bu davranış:

· kullanma ns3::Ipv6InterfaceContainer SetForwarding(uint32_t) i, bool yönlendirici) nerede i olduğunu
kapsayıcıdaki arayüz dizini.

· Değiştirme ns3::IPv6 nitelik IPForward.

Simülasyon sırasında ikisinden biri kullanılabilir.

İnce taneli bir kurulum kullanılarak gerçekleştirilebilir ns3::Ipv6Arayüzü Yönlendirmeyi ayarla (bool
ileri); bu, davranışı arayüz bazında değiştirmeye izin verir.

Düğüm çapında yapılandırmanın yalnızca etkinleştirmek/devre dışı bırakmak için uygun bir yöntem olarak hizmet ettiğini unutmayın.
the ns3::Ipv6Arayüzü özel ayar. Yönlendirme ile bir düğüme eklenen bir Ipv6Interface
etkinleştirildiğinde de iletme olarak ayarlanacaktır. Bir düğüm olduğunda bu gerçekten önemlidir.
Simülasyon sırasında eklenen arayüzler.

Göre ns3::Ipv6Arayüzü iletim durumu, aşağıdakiler olur:

· Yönlendirme KAPALI

· Düğüm, Yönlendirici Taleplerine CEVAP VERMEZ

· Düğüm Yönlendirici Reklamına tepki verecek

· Düğüm periyodik olarak Yönlendirici Talebi gönderir

· Yönlendirme protokolleri, düğüme yönlendirilmemiş paketleri DÜŞÜRMELİDİR

· Yönlendirme AÇIK

· Düğüm, Yönlendirici Taleplerine yanıt verecektir

· Düğüm Yönlendirici Reklamına tepki VERMEZ

· Düğüm Yönlendirici Talebi GÖNDERMEYECEK

· Yönlendirme protokolleri paketleri iletmek ZORUNDADIR

Davranış ip-sysctl.txt ile eşleşiyor (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) aradaki farkla
Ezoterik ayarları kullanarak davranışı geçersiz kılmak mümkün değildir (örneğin, iletme ancak
yönlendirici reklamlarını kabul et, accept_ra=2 veya ilet, ama yönlendirici isteklerini gönder
yönlendirme = 2).

Paket iletmenin etkilerini dikkatlice düşünün. Örnek olarak, bir düğüm DEĞİL
frowarding kapalı bir arayüzden ICMPv6 PACKET_TOO_BIG mesajları gönderin. Bu
tamamen normal, çünkü Yönlendirme protokolü paketi denemeden önce bırakacaktır.
ilet.

Yardımcılar
Tipik olarak IPv6 kurulumunda kullanılan yardımcılar şunlardır:

· ns3::InternetStackYardımcısı

· ns3::Ipv6AdresiYardımcısı

· ns3::Ipv6InterfaceContainer

Kullanım, ilgili IPv4 durumuyla neredeyse aynıdır, örneğin:

NodeContainer n;
n.Oluştur (4);

NS_LOG_INFO ("IPv6 İnternet Yığını Oluştur");
Internet Yığın Yardımcısı internetv6;
internetv6.Yükle (n);

NS_LOG_INFO ("Kanal oluştur.");
CsmaYardımcı csma;
NetDeviceContainer d = csma.Install (n);

NS_LOG_INFO ("Ağlar oluşturun ve IPv6 Adresleri atayın.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Adresi ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

Ek olarak, ortak bir görev, düğümlerden birinde iletmeyi etkinleştirmek ve bir
diğer düğümlerde ona doğru varsayılan rota, örneğin:

iic.SetForwarding (0, doğru);
iic.SetDefaultRouteInAllNodes (0);

Bu, düğümde iletmeyi etkinleştirir 0 ve varsayılan bir rota kuracak
ns3::Ipv6StatikYönlendirme diğer tüm düğümlerde. Bunun bunu gerektirdiğini unutmayın
Ipv6StaticRouting, düğümlerde bulunur.

IPv6 yönlendirme yardımcıları, kullanıcının belirli görevler üzerinde belirli görevleri gerçekleştirmesini sağlar.
yönlendirme algoritması ve yönlendirme tablolarını yazdırmak için.

Özellikler
Sınıfta birçok ns-3 IPv6 uygulaması öznitelikler içerir. En kullanışlı olanlar:

· ns3::IPv6

· IPForward, boole, varsayılan yanlış. IP iletmeyi herkes için küresel olarak etkinleştirin veya devre dışı bırakın
mevcut ve gelecekteki IPv6 cihazları.

· MtuKeşfet, boolean, varsayılan doğru. Devre dışı bırakılırsa, her arabirimin MTU'su olacaktır
1280 bayta ayarlandı.

· ns3::Ipv6L3Protokol

· VarsayılanTtl, uint8_t, varsayılan 64. Tüm giden paketlerde varsayılan olarak ayarlanan TTL değeri
bu düğümde oluşturulur.

· SendIcmpv6Yönlendirme, boolean, varsayılan doğru. Uygun olduğunda ICMPv6 Yönlendirmesini gönderin.

· ns3::Icmpv6L4Protokol

· DAD, boolean, varsayılan doğru. Daima DAD (Yinelenen Adres Algılama) kontrolü yapın.

· ns3::NdiscÖnbellek

· ÇözümlenmemişKuyrukBoyutu, uint32_t, varsayılan 3. Bir NA bekleyen paketler için kuyruğun boyutu
cevap.

Çıktı
IPv6 yığını, bazı yararlı izleme kaynakları sağlar:

· ns3::Ipv6L3Protokol

· Tx, IPv6 paketini giden arayüze gönder.

· Rx, Gelen arayüzden IPv6 paketi alın.

· Damla, IPv6 paketini bırakın.

· ns3::IPv6Uzantısı

· Damla, IPv6 paketini bırakın.

En son izleme kaynağı, bir paket, kendisini engelleyen bilinmeyen bir seçenek içerdiğinde oluşturulur.
işleme.

Aklında bulunsun ns3::NdiscÖnbellek paketleri de bırakabilir ve bir izde oturum açmazlar
kaynak (henüz). Bu, gönderilen/alınan paket sayaçlarında biraz karışıklığa neden olabilir.

Advanced kullanım
IPv6 maksimum transmisyon birim (MTU) ve parçalanma
ns-3 NetDevices, MTU'yu L2 benzetilmiş Aygıta göre tanımlar. IPv6 bunu gerektirir
minimum MTU 1280 bayttır, bu nedenle tüm NetDevices'ın en azından bunu desteklemesi gerekir
MTU. Bu bağlantı-MTU'dur.

Bir kaynak-hedef yolunda farklı MTU'ları desteklemek için, ns-3 IPv6 modeli
parçalama gerçekleştirin. Bu, paketten daha büyük bir paket alınarak tetiklenebilir.
L4 protokollerinden (UDP, TCP, vb.) veya bir ICMPv6 PACKET_TOO_BIG alarak link-MTU
İleti. Model, aşağıdaki dikkate değer istisnalar dışında RFC 1981'i taklit eder:

· L4 protokolleri Path MTU değişikliğinden haberdar değil

· TCP, Segment Boyutunu Path-MTU'ya göre değiştiremez.

Her iki sınırlama da zamanı gelince kaldırılacaktır.

Path-MTU önbelleği şu anda kaynak-hedef IPv6 adreslerine dayanmaktadır. Daha öte
sınıflandırmalar (örneğin, akış etiketi) mümkündür ancak henüz uygulanmamıştır.

Path-MTU varsayılan geçerlilik süresi 10 dakikadır. Önbellek girişi sona erdikten sonra,
Path-MTU bilgisi kaldırılır ve bir sonraki paket (sonunda) yeni bir ICMPv6'yı tetikler.
PACKET_TOO_BIG mesajı. 1) bunun RFC spesifikasyonu ile tutarlı olduğunu ve 2) olduğunu unutmayın.
L4 protokolleri, paketlerin yeniden iletilmesinden sorumludur.

Örnekler
IPv6 için örnekler dizindedir. örnekler/ipv6. Bu örnekler en çok
parçalanma, yönlendirme vb. gibi ilginç IPv6 özellikleri.

Ayrıca, çoğu TCP ve UDP örneği, örnekler/udp, örnekler/tcp, vb. var
IPv6 yerine IPv4 kullanmak için komut satırı seçeneği.

Sorun giderme
Kullanırken kaçınılması gereken birkaç tuzak var ns-3 IPv6.

Yönlendirme döngüler
IPv6 için mevcut olan tek (şimdiye kadar) yönlendirme şeması ns3::Ipv6StatikYönlendirme,
varsayılan yönlendirici manuel olarak kurulmalıdır. Bir ağda iki veya daha fazla yönlendirici olduğunda
(örneğin, düğüm A ve düğüm B), yardımcı işlevi kullanmaktan kaçının SetDefaultRouteInAllNodes için
birden fazla yönlendirici.

Sonuç, A'da B'ye varsayılan bir rota ve varsayılan bir rota işaretlemesi kurmak olacaktır.
B'de A'ya, bir döngü oluşturarak.

Küresel adres kaçak
IPv6'daki adreslerin global tanım olarak. IPv6'yı bir
öykünme ns-3 yeteneği, her ne pahasına olursa olsun küresel İnternet'e yönelik sızıntıyı önlemek.
Sızıntıyı önlemek için harici bir güvenlik duvarı kurulması tavsiye edilir.

2001:DB8::/32 adresleri
IPv6 standardı (RFC 3849), aşağıdakileri tanımlar: 2001:DB8::/32 için adres sınıfı belgeleme.
Bu kılavuz bu kuralı kullanır. Ancak bu sınıftaki adresler yalnızca
bir belge ve yönlendiriciler bunları atmalıdır.

Onaylama
IPv6 protokolleri, gerçek uygulamalara karşı henüz kapsamlı bir şekilde doğrulanmamıştır.
Gerçek testler, esas olarak .pcap izleme dosyalarının Wireshark ile kontrol edilmesini içerir.
ve sonuçlar olumlu.

Yönlendirme genel bakış
ns-3 geleneksel yönlendirme yaklaşımlarını ve protokollerini desteklemek, bağlantı noktalarını desteklemek için tasarlanmıştır.
açık kaynak yönlendirme uygulamaları ve alışılmışın dışında yönlendirme araştırmalarını kolaylaştırmak
teknikler. Genel yönlendirme mimarisi aşağıda açıklanmıştır. Yönlendirme mimari.
Kablolu topolojiler için global yönlendirmenin nasıl yapılandırılacağı hakkında bilgi almak isteyen kullanıcılar,
okumak Küresel merkezi yönlendirme. Tek noktaya yayın yönlendirme protokolleri şurada açıklanmıştır: Tek noktaya yayın
yönlendirme. Çok noktaya yayın yönlendirmesi şurada belgelenmiştir: Multicast yönlendirme.

Yönlendirme mimari
[image] Yönlendirmeye genel bakış.UNINDENT

Genel Bakış of yönlendirme Ipv4 için genel yönlendirme mimarisini gösterir. Anahtar nesneler
Ipv4L3Protocol, Ipv4RoutingProtocol(s) (tüm yönlendirme/iletme işlemlerinin yapıldığı bir sınıf
Ipv4L3Protocol'dan yetkilendirilmiş) ve Ipv4Route(s).

Ipv4L3Protocol, simülasyonda kendisine eklenmiş en az bir Ipv4RoutingProtocol'a sahip olmalıdır
kurulum zamanı. Bu, açıkça Ipv4::SetRoutingProtocol() çağrılarak yapılır.

Soyut temel sınıf Ipv4RoutingProtocol(), aşağıdakilerden oluşan minimal bir arabirim bildirir:
iki yöntemden oluşur: RouteOutput () ve RouteInput (). çıkış yapan paketler için
bir ana bilgisayar, aktarım protokolü Ipv4RoutingProtocol nesnesi için Ipv4'ü sorgulayacaktır.
arabirim ve Ipv4RoutingProtocol::RouteOutput () aracılığıyla bir rota isteyecektir. Bir Ptr
Ipv4Route nesnesi döndürülür. Bu, Linux'taki bir dst_cache girişine benzer. bu
Ipv4Route, orada ikinci bir aramayı önlemek için Ipv4L3Protocol'a taşınır. Yine de,
bazı durumlarda (örn. Ipv4 ham soketleri) doğrudan RouteOutput()'a çağrı yapılmasını gerektirir.
Ipv4L3Protokol.

Yönlendirme veya teslimat için gelen paketler için aşağıdaki adımlar gerçekleşir.
Ipv4L3Protocol::Receive(), Ipv4RoutingProtocol::RouteInput()'u çağırır. Bu geçer
Ipv4RoutingProtocol nesnesine paket sahipliği. İlişkili dört geri arama var
bu çağrı ile:

· YerelTeslim

· Tek Noktaya Yayın İleri

· Çok Noktaya Yayın İleri

· Hata

Ipv4RoutingProtocol, sonunda her paket için bu geri aramalardan birini çağırmalıdır.
için sorumluluk alır. Temel olarak giriş yönlendirme işlemi şu şekilde çalışır:
Linux.
[image] Ipv4Routing uzmanlığı..UNINDENT

Bu genel mimari, aşağıdakiler dahil olmak üzere farklı yönlendirme yaklaşımlarını desteklemek için tasarlanmıştır:
(gelecekte) Linux benzeri bir politika tabanlı yönlendirme uygulaması, proaktif ve
simülasyon kullanıcısı için isteğe bağlı yönlendirme protokolleri ve basit yönlendirme protokolleri
yönlendirmeyi gerçekten umursamıyor.

IPv4Yönlendirme uzmanlaşma. çoklu yönlendirme protokollerinin bundan nasıl türetildiğini gösterir
temel sınıf. Ipv4ListRouting sınıfı (uygulama sınıfı Ipv4ListRoutingImpl) şunları sağlar:
mevcut liste yönlendirme yaklaşımı ns-3. API'si temel sınıfla aynıdır
Birden çok öncelikli yönlendirme protokolü ekleme yeteneği dışında Ipv4Routing
(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

Bu yönlendirme protokollerinin ayrıntıları aşağıda açıklanmıştır. Tek noktaya yayın yönlendirme. Şimdilik,
ilk olarak, küresel olarak amaçlanan temel bir tek noktaya yayın yönlendirme yeteneği ile başlayacağız.
umursamayan simülasyon kullanıcıları için t=0 simülasyon zamanında yönlendirme tabloları oluşturun
dinamik yönlendirme

Küresel merkezi yönlendirme
Küresel merkezi yönlendirme bazen "Tanrı" yönlendirmesi olarak adlandırılır; bu özel
simülasyon topolojisinde yürüyen ve en kısa yol algoritmasını çalıştıran uygulama ve
her düğümün yönlendirme tablolarını doldurur. Gerçek bir protokol ek yükü yok (simüle edilmiş bağlantılarda)
bu yaklaşımla gerçekleşir. Birkaç kısıtlaması var:

· Telli Sadece: Kablosuz ağlarda kullanılmak üzere tasarlanmamıştır.

· Tek noktaya yayın Sadece: Çok noktaya yayın yapmaz.

· Ölçeklenebilirlik: Bunun büyük topolojilerdeki (örneğin 1000 düğüm) bazı kullanıcıları şunu fark ettiler:
mevcut uygulama çok ölçeklenebilir değil. Küresel merkezi yönlendirme
hesaplamaları ve çalışma zamanı performansını azaltmak için gelecekte değiştirilir.

Şu anda, hem noktadan noktaya hem de paylaşımlı ağ üzerinden küresel merkezi IPv4 tek noktaya yayın yönlendirmesi
(CSMA) bağlantıları desteklenir.

Varsayılan olarak, kullanırken ns-3 yardımcı API ve varsayılan InternetStackHelper, global
Düğüme yönlendirme yeteneği eklenecek ve global yönlendirme
Statik rotalardan daha düşük önceliğe sahip yönlendirme protokolü (yani, kullanıcılar rota ekleyebilir
Ipv4StaticRouting API aracılığıyla ve global tarafından bulunan rotalara göre öncelikli olacaklardır.
yönlendirme).

Küresel Tek noktaya yayın Yönlendirme API
Genel API çok az. Kullanıcı komut dosyaları şunları içerir:

#include "ns3/internet-module.h"

Varsayılan InternetStackHelper kullanılıyorsa, genel yönlendirme örneği
her düğümde toplanır. IP adresleri yapılandırıldıktan sonra aşağıdaki işlev çağrısı
Ipv4 arayüzüne sahip tüm düğümlerin yönlendirme tabloları almasına neden olur
GlobalRouteManager tarafından otomatik olarak girilir:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Not: Wifi NetDevice'in çalışacağını ancak herhangi bir kablosuz efekt almadığını hatırlatan bir hatırlatma
hesaba katmak. Kablosuz için, aşağıda açıklanan OLSR dinamik yönlendirmesini öneririz.

kullanılarak bir simülasyonun ortasında bu fonksiyonu tekrar çağırmak mümkündür.
aşağıdaki ek kamu işlevi:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

eski tabloları temizleyen, düğümleri yeni arayüz bilgileri için sorgulayan ve
yolları yeniden oluşturur.

Örneğin, bu zamanlama çağrısı, tabloların 5 saniyede yeniden oluşturulmasına neden olacaktır:

Simulator::Schedule (Saniye (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

Davranışı yöneten iki özellik vardır. İlk olarak
Ipv4GlobalRouting::RandomEcmpRouting. true olarak ayarlanırsa, paketler rastgele yönlendirilir.
eşit maliyetli çok yollu yollar. False (varsayılan) olarak ayarlanırsa, yalnızca bir rota tutarlıdır
Kullanılmış. İkincisi, Ipv4GlobalRouting::RespondToInterfaceEvents'dir. true olarak ayarlanırsa,
Arayüz bildirim olayları (yukarı/aşağı veya
adres ekle/kaldır). Yanlış (varsayılan) olarak ayarlanırsa, kullanıcı manuel olarak kullanmadıkça yönlendirme bozulabilir.
bu tür olaylardan sonra RecomputeRoutingTables()'ı çağırır. Varsayılan, korumak için false olarak ayarlanmıştır
miras ns-3 program davranışı.

Küresel Yönlendirme Uygulama
Bu bölüm, bunun nasıl uygulandığını önemseyen okuyucular içindir. bir singleton
nesne (GlobalRouteManager), her düğümdeki statik yolları doldurmaktan sorumludur,
bu düğümün genel Ipv4 API'sini kullanarak. Topolojideki her bir düğümü bir
"globalRouter" arayüzü. Bulunursa, bir "bağlantı" elde etmek için o arayüzün API'sini kullanır.
yönlendirici için durum reklamı (LSA)". Bağlantı Durumu Reklamları OSPF'de kullanılır
yönlendirme ve biçimlendirmelerini takip ediyoruz.

Tüm bu hesaplamaların paketler akmadan önce yapıldığını not etmek önemlidir.
ağda. Özellikle, değiş tokuş edilen hiçbir ek yük veya kontrol paketi yoktur.
Bu uygulamayı kullanırken. Bunun yerine, bu global rota yöneticisi sadece
gerekli bilgileri oluşturmak ve her bir düğümün yönlendirme tablosunu yapılandırmak için düğümler.

GlobalRouteManager, bir bağlantı durumu veritabanını, tüm sistemden toplanan LSA'larla doldurur.
topoloji. Ardından, topolojideki her yönlendirici için GlobalRouteManager, OSPF'yi yürütür.
veritabanında önce en kısa yol (SPF) hesaplaması yapar ve üzerindeki yönlendirme tablolarını doldurur.
her düğüm.

bataklık (http://www.quagga.net) OSPF uygulaması temel olarak kullanılmıştır.
yönlendirme hesaplama mantığı. Mevcut bir OSPF SPF uygulamasını takip etmenin bir faydası,
OSPF'nin tüm yaygın ağ türleri için bağlantı durumu reklamlarını zaten tanımlamış olması
sol:

· noktadan noktaya (seri bağlantılar)

· noktadan çok noktaya (Frame Relay, özel kablosuz)

· yayın dışı çoklu erişim (ATM)

· yayın (Ethernet)

Bu nedenle, bu diğer bağlantı türlerini etkinleştirmenin şimdi daha kolay olacağını düşünüyoruz.
temel OSPF SPF çerçevesinin yerinde olduğunu.

Şu anda IPv4 noktadan noktaya, numaralandırılmış bağlantıların yanı sıra paylaşılan yayınları da yönetebiliyoruz.
(CSMA) bağlantıları. Eşit maliyetli çok yol da desteklenir. Her ne kadar kablosuz bağlantı türleri
uygulama tarafından destekleniyorsa, bu uygulamanın doğası gereği, herhangi bir
kanal etkileri dikkate alınmayacak ve yönlendirme tabloları her düğümün
aynı paylaşılan kanaldaki diğer tüm düğümlerden erişilebilir (yani işlem görecektir)
bir yayın CSMA bağlantısı gibi).

GlobalRouteManager, önce düğümler listesinde gezinir ve bir GlobalRouter toplar.
her birine aşağıdaki gibi arayüz:

typedef std::vektör < Ptr >::yineleyici Yineleyici;
for (Yineleyici i = NodeList::Begin (); i != NodeList::End (); i++)
{
Ptr düğüm = *i;
Ptr globalRouter = CreateObject (düğüm);
düğüm->AggregateObject (globalRouter);
}

Bu arayüz daha sonra sorgulanır ve her biri için bir Bağlantı Durumu Bildirisi oluşturmak için kullanılır.
yönlendirici ve bu bağlantı durumu veritabanı, OSPF en kısa yol hesaplama mantığına beslenir.
Ipv4 API nihayet rotaları kendileri doldurmak için kullanılır.

Tek noktaya yayın yönlendirme
Şu anda IPv4 için tanımlanmış yedi ve IPv6 için üç tek noktaya yayın yönlendirme protokolü vardır:

· sınıf Ipv4StaticRouting (hem tek noktaya hem de çok noktaya yayını kapsar)

· IPv4 Optimize Edilmiş Bağlantı Durumu Yönlendirmesi (OLSR) (bir MANET protokolü RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (bir MANET protokolü RFC 3561)

· IPv4 Hedef Sıralı Mesafe Vektörü (DSDV) (bir MANET protokolü)

· IPv4 Dinamik Kaynak Yönlendirme (DSR) (bir MANET protokolü)

· sınıf Ipv4ListRouting (öncelikli bir yönlendirme protokolleri listesini depolamak için kullanılır)

· sınıf Ipv4GlobalRouting (eğer varsa, global rota yöneticisi tarafından hesaplanan rotaları depolamak için kullanılır)
kullanılan)

· sınıf Ipv4NixVectorRouting (depolayan küresel yönlendirmenin daha verimli bir sürümü
paket başlık alanındaki kaynak yolları)

· sınıf Ipv6ListRouting (öncelikli bir yönlendirme protokolleri listesini depolamak için kullanılır)

· sınıf Ipv6StaticRouting

· class RipNg - IPv6 RIPng protokolü (RFC 2080)

Gelecekte, bu mimari birinin Linux benzeri bir uygulama yapmasına da izin vermelidir.
yönlendirme önbelleği veya bir Click modüler yönlendirici ile uygulama, ancak bunlar kapsam dışında
şimdilik.

IPv[4,6]ListYönlendirme
Bu bölüm mevcut varsayılanı açıklar ns-3 IPv[4,6]Yönlendirme Protokolü. Tipik,
kullanıcı alanında çoklu yönlendirme protokolleri desteklenir ve tek bir
çekirdekte yönlendirme tablosu. şu anda ns-3, uygulama bunun yerine izin verir
kendi yönlendirme durumlarını oluşturmak/saklamak için çoklu yönlendirme protokolleri ve IP
uygulama, bu yönlendirme protokollerinin her birini sorgulayacaktır (belirlenen bir sırayla
simülasyon yazarı) bir rota bulunana kadar.

Bu yaklaşımı seçtik, çünkü bu, birbirinden farklı öğelerin entegrasyonunu daha iyi kolaylaştırabilir.
Yazmayı tek bir tabloya koordine etmek zor olabilecek yönlendirme yaklaşımları,
hedef IP adresinden (örneğin, kaynak yönlendirme) daha fazla bilginin olduğu yaklaşımlar
paketlerin olması gereken bir sonraki atlama ve isteğe bağlı yönlendirme yaklaşımlarını belirlemek için kullanılır.
önbelleğe alındı.

Ipv[4,6]4ListRouting::AddRoutingProtocol
Ipv4ListRouting ve Ipv6ListRouting sınıfları, saf bir sanal işlev bildirimi sağlar
birinin bir yönlendirme protokolü eklemesine izin veren yöntem için:

void AddRoutingProtocol (Ptr yönlendirmeProtokol,
int16_t önceliği);

void AddRoutingProtocol (Ptr yönlendirmeProtokol,
int16_t önceliği);

Bu yöntemler sırasıyla Ipv4ListRoutingImpl sınıfına ve sınıfa göre uygulanır.
İnternet modülünde Ipv6ListRoutingImpl.

Yukarıdaki öncelik değişkeni, yönlendirme protokollerinin içinde bulunduğu önceliği yönetir.
sokuldu. Bunun imzalı bir int olduğuna dikkat edin. Varsayılan olarak ns-3, yardımcı sınıflar
bir Ipv[4,6]ListRoutingImpl nesnesinin örneğini oluşturun ve buna bir Ipv[4,6]StaticRoutingImpl ekleyin
nesne önceliği sıfır. Dahili olarak, bir Ipv[4,6]RoutingProtocols listesi saklanır ve
ve yönlendirme protokollerinin her birine, görmek için azalan öncelik sırasına göre başvurulur.
bir eşleşme bulunup bulunmadığı. Bu nedenle, Ipv4RoutingProtocol'unuzun önceliğe sahip olmasını istiyorsanız
statik yönlendirmeden daha düşükse, 0'dan daha düşük önceliğe sahip olarak ekleyin; Örneğin:

Ptr myRoutingProto = CreateObject ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

RouteOutput() veya RouteInput() çağrıları üzerine, liste yönlendirme nesnesi listeyi arayacaktır.
Bir rota bulunana kadar öncelik sırasına göre yönlendirme protokollerinin Bu tür yönlendirme protokolü
uygun geri aramayı başlatacak ve başka yönlendirme protokolü aranmayacaktır.

Optimize Edilmiş Link Eyalet Yönlendirme (OLSR)
Bu IPv4 yönlendirme protokolü, orijinal olarak ns-2 için OLSR-UM uygulamasından taşınmıştır.
Uygulama src/olsr dizininde bulunur ve örnek bir komut dosyası
örnekler/basit noktadan noktaya-olsr.cc.

Tipik olarak, OLSR, bir ana programda, yükleyen bir OlsrHelper sınıfı kullanılarak etkinleştirilir.
OLSR'yi bir Ipv4ListRoutingProtocol nesnesine dönüştürün. Aşağıdaki örnek komutlar etkinleştirecek
OLSR, diğer bazı yönlendirme yardımcı nesneleri ile birlikte bu yardımcı sınıfı kullanan bir simülasyonda.
10'ın staticRouting önceliğinden önce öncelik değeri 0'un ayarlanması, şu anlama gelir:
Düğümün statik yönlendirme tablosundan önceki bir rota için OLSR'ye danışılacaktır.:

DüğümKonteyner c:
Kendi ID’n ile mağazalarını oluştur
// OLSR'yi etkinleştir
NS_LOG_INFO ("OLSR Yönlendirmesini Etkinleştirme.");
OlsrYardımcı olsr;

Ipv4StaticRoutingHelper staticRouting;

Ipv4ListRoutingHelper listesi;
list.Add (statik Yönlendirme, 0);
list.Add (olsr, 10);

InternetStackHelper interneti;
internet.SetRoutingHelper (liste);
internet.Kur (c);

Kurulduktan sonra, OLSR "ana arabirimi" SetMainInterface() komutuyla ayarlanabilir.
Kullanıcı bir ana adres belirtmezse, protokol ilk birincil IP'yi seçecektir.
bulduğu adresi, önce geridöngü arabirimini ve ardından bir sonraki
Ipv4 arabirim dizini sırasına göre geri döngü olmayan arabirim bulundu. geridöngü adresi
127.0.0.1 seçilmedi. Ek olarak, bir dizi protokol sabiti tanımlanmıştır.
olsr-yönlendirme-protokol.cc.

Olsr, Object::Start() çağrısına dayalı olarak simülasyonun sıfır zamanında başlatılır.
sonunda OlsrRoutingProtocol::DoStart()'ı çağırır. Not: kullanıcının başlamasına izin veren bir yama
ve protokolü diğer zamanlarda durdurmak memnuniyetle karşılanacaktır.

Şu anda OLSR, bir Ipv4ListRouting nesnesiyle kullanımla sınırlıdır ve yanıt vermemektedir.
bir cihazın IP adresindeki dinamik değişiklikler veya bağlantı yukarı/aşağı bildirimleri; yani topoloji
değişiklikler, kablosuz bir kanal üzerinden bağlantı kaybı/kazanımından kaynaklanır.

RIPng
Bu IPv6 yönlendirme protokolü (RFC 2080) iyi bilinen RIPv1 ve RIPv2'nin evrimidir.
(görmek RFC 1058 ve RFC 1723) IPv4 için yönlendirme protokolleri.

Protokol çok basittir ve normalde düz, basit ağ için uygundur.
topolojileri.

RIPng, güçlü bir şekilde RIPv1 ve RIPv2'ye dayanmaktadır ve aynı hedeflere sahiptir ve
sınırlamalar. Özellikle, RIP, metriği 16'ya eşit veya daha büyük olan herhangi bir rotayı dikkate alır.
ulaşılmaz olarak Sonuç olarak, maksimum atlama sayısı ağın daha az olması gerektiğidir.
15'ten fazla (yönlendirici sayısı ayarlanmamış). Kullanıcılar okumaya teşvik edilir RFC 2080 ve RFC
1058 RIPng davranışını ve sınırlamalarını tam olarak anlamak için.

Yönlendirme yakınsama
RIPng bir Mesafe-Vektör algoritması kullanır ve rotalar aşağıdakilere göre güncellenir.
Bellman-Ford algoritması (bazen Ford-Fulkerson algoritması olarak da bilinir). Algoritmanın bir
yakınsama zamanı O(|V|*|E|) burada |V| ve |E| köşe sayısı (yönlendiriciler) ve
sırasıyla kenarlar (bağlar). Yakınsama süresinin sayı olduğu vurgulanmalıdır.
Algoritmadaki adımların sayısı ve her adım bir mesajla tetiklenir. Tetiklendiğinden beri
Güncellemeler (yani, bir rota değiştirildiğinde) 1-5 saniyelik bir bekleme süresine sahiptir, topoloji
sabitlenmesi için biraz zamana ihtiyaç vardır.

Kullanıcılar, yönlendirme tablolarının yapımı sırasında yönlendiricilerin düşebileceğini bilmelidir.
paketler. Veri trafiği, yalnızca RIPng'nin oluşturulmasına izin verecek kadar uzun bir süre sonra gönderilmelidir.
ağ topolojisi. Genellikle 80 saniye, optimalin altında bir değere sahip olmak için yeterli olmalıdır (ancak
çalışma) yönlendirme kurulumu. Bu, rotaları en fazla yaymak için gereken süreyi içerir.
Tetiklenen Güncellemeler ile uzak yönlendirici (16 atlama).

Ağ topolojisi değiştirilirse (örneğin bir bağlantı bozulursa), kurtarma süresi
oldukça yüksektir ve ilk kurulum süresinden bile daha yüksek olabilir. Ayrıca, ağ
topoloji kurtarma, Bölünmüş Ufuklama stratejisinden etkilenir.

Örnek örnekler/yönlendirme/ripng-simple-network.cc hem ağ kurulumunu hem de
ağ kurtarma aşamaları.

Bölünmüş Ufuk
Split Horizon, yönlendirme kararsızlığını önlemek için bir stratejidir. Üç seçenek mümkündür:

· Bölünmüş Ufuk Yok

· Bölünmüş Ufuk

· Zehir Ters

İlk durumda, rotaların tüm yönlendirici arayüzlerinde duyurulur. Saniyede
durumda, yönlendiriciler, öğrenildiği arabirimde bir rotanın reklamını yapmaz.
Poison Reverse, öğrenildiği arayüzde rotanın reklamını yapacak, ancak
16 (sonsuz) bir metrik ile. Üç tekniğin tam bir analizi için, bkz. RFC
1058, bölüm 2.2.

Örnek ripng-simple-network.cc RFC'de açıklanan ağ topolojisine dayalıdır,
ancak orada anlatılan etkiyi göstermez.

Bunun nedeni, bir yönlendirici olduğunda
bir rotayı geçersiz kılar, rotanın erişilemezliğini hemen yayar, böylece
RFC'de açıklanan sorunların çoğunu önleme.

Bununla birlikte, karmaşık topolojilerde, rota kararsızlığı fenomenine sahip olmak hala mümkündür.
bir bağlantı hatasından sonra RFC'de açıklanana benzer. Sonuç olarak, tüm
Split Horizon ile ilgili düşünceler geçerliliğini koruyor.

Varsayılan yolları
RIPng protokolü kurulmalıdır bir tek yönlendiriciler üzerinde. Sonuç olarak, düğümler bilmeyecek
varsayılan yönlendirici nedir.

Bu sınırlamanın üstesinden gelmek için, kullanıcılar varsayılan rotayı manuel olarak kurmalıdır (örn.
Ipv6StaticRouting'e başvurarak) veya RADVd kullanarak. RADVd şurada mevcuttur: ns-3 içinde
Uygulamalar modülü ve şiddetle tavsiye edilir.

Protokol parametreler ve seçenekleri
RIPng ns-3 uygulama, rota ile ilişkili tüm zamanlayıcıları değiştirmeye izin verir
güncellemeler ve rotalar ömür boyu.

Ayrıca, kullanıcılar arayüz metriklerini düğüm bazında değiştirebilirler.

Bölünmüş Ufuklama türü (rotaların geri yayılmasını önlemek için) bir
"bölünmüş ufuk yok", "bölünmüş ufuk" ve "zehir" seçenekleriyle düğüm başına temel
ters". Bkz. RFC 2080 daha fazla ayrıntı için ve RFC 1058 hakkında tam bir tartışma için
Bölünmüş ufuk stratejileri.

Sınırlamalar
Sonraki Atlama seçeneği için destek yoktur (RFC 2080, Bölüm 2.1.1). Sonraki Atlama
seçeneği, bir ağdaki tüm yönlendiricilerde RIPng çalıştırılmadığında kullanışlıdır. Destek
çünkü bu seçenek gelecekte düşünülebilir.

CIDR önek toplama desteği yoktur. Sonuç olarak, hem yönlendirme tabloları hem de
rota reklamları gerekenden daha büyük olabilir. Önek toplaması şuraya eklenebilir:
gelecek.

Multicast yönlendirme
Bir düğüme statik bir çok noktaya yayın yolu eklemek için aşağıdaki işlev kullanılır:

geçersiz
Ipv4StaticRouting::AddMulticastRoute (Ipv4Address kaynağı,
IPv4Adres grubu,
uint32_t girdiArayüz,
standart::vektör çıktıArayüzleri);

Bir çok noktaya yayın yolu, bir kaynak IP adresi, bir çok noktaya yayın grubu ve bir giriş belirtmelidir.
koşullar olarak ağ arabirimi dizini ve bir çıktı ağ arabirimi vektörü sağlar
koşullara uyan paketlerin gönderildiği dizinler.

Tipik olarak iki ana çok noktaya yayın rotası türü vardır: birinci tür rotalar kullanılır
yönlendirme sırasında. Tüm koşullar açıkça sağlanmalıdır. İkinci tür
yollar, paketleri yerel bir düğümden almak için kullanılır. Fark girişte
arayüz. Yönlendirme yolları her zaman belirtilmiş bir açık giriş arayüzüne sahip olacaktır.
Bir düğümden çıkan rotalar, her zaman giriş arayüzünü, tarafından belirtilen bir joker karaktere ayarlar.
dizin Ipv4RoutingProtocol::IF_INDEX_ANY.

Yerel bir düğümün dışındaki rotalar için, kaynak ve çok noktaya yayın grubunda kullanılabilir.
adresler. Ipv4Adresleri için kullanılan joker karakter, şu adresten döndürülen adrestir:
Ipv4Address::GetAny () -- genellikle "0.0.0.0". Bir joker karakterin kullanılması, birinin belirtmesine izin verir
değişen derecelerde varsayılan davranış.

Örneğin, kaynak adresini bir joker karakter yapmak, ancak çok noktaya yayın grubundan çıkmak
belirli birinin (birden çok arabirime sahip bir düğüm olması durumunda) farklı oluşturmasına izin verir.
Her çok noktaya yayın grubu için farklı çıkış arabirimleri kullanan yollar.

Köken ve çok noktaya yayın adresleri joker karakterlerse, esasen bir
birden çok arabirime iletebilen varsayılan çok noktaya yayın adresi. Bunu şununla karşılaştır
tek bir çıkış arabirimi belirtmekle sınırlı gerçek varsayılan çok noktaya yayın adresi
diğer sistemlerdeki mevcut işlevsellik ile uyumluluk için.

Başka bir komut, varsayılan çok noktaya yayın yolunu ayarlar:

geçersiz
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t OutputInterface);

Bu, SetDefaultRoute tek noktaya yayın sürümünün çok noktaya yayın eşdeğeridir. biz söyleriz
yönlendirme sistemi, belirli bir rotanın bir hedef çok noktaya yayına gitmesi durumunda ne yapılması gerektiği
grup bulunamadı. Sistem, umut içinde paketleri belirtilen arabirimden dışarı iletir.
"orada bir şey" paketin nasıl yönlendirileceğini daha iyi bilir. Bu yöntem sadece kullanılır
başlangıçta bir ana bilgisayardan paket gönderirken. Varsayılan çok noktaya yayın yoluna danışılmaz
yönlendirme sırasında -- bu durumda AddMulticastRoute kullanılarak kesin yollar belirtilmelidir.

Temelde bazı varlıklara paketler gönderdiğimiz için, ne yapacağımızı daha iyi bilebileceğini düşündüğümüz için,
Origin adresi gibi "inceliklere" dikkat etmiyoruz, endişelenmiyoruz.
birden fazla arabirimi iletme. Varsayılan çok noktaya yayın yolu ayarlanmışsa, döndürülür
Kökenden veya çok noktaya yayın grubundan bağımsız olarak LookupStatic'ten seçilen rota olarak
başka bir belirli rota bulunamadı.

Son olarak, çok noktaya yayını almak ve kaldırmak için bir dizi ek işlev sağlanmıştır.
rotalar:

uint32_t GetNMulticastRoutes (geçersiz) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (geçersiz) const;

bool RemoveMulticastRoute (Ipv4Address kaynağı,
IPv4Adres grubu,
uint32_t inputInterface);

void RemoveMulticastRoute (uint32_t dizini);

TCP modelleri in ns-3
Bu bölümde, mevcut TCP modelleri açıklanmaktadır. ns-3.

genel destek için TCP
ns-3 birden çok TCP uygulamasını desteklemek için yazılmıştır. Uygulamalar miras alınır
birkaç yaygın başlık sınıfı kaynak/ağ dizin, böylece kullanıcı kodu değiş tokuş edebilir
komut dosyalarında minimum değişiklikle uygulamalar.

İki önemli soyut temel sınıf vardır:

· sınıf TcpSocket: Bu tanımlıdır kaynak/internet/model/tcp-soket.{cc,h}. Bu sınıf
farklı platformlarda yeniden kullanılabilen TcpSocket özniteliklerini barındırmak için mevcuttur.
uygulamalar. Örneğin, öznitelik İlkCwnd herhangi biri için kullanılabilir
sınıftan türetilen uygulamalar TcpSocket.

· sınıf TcpSocketFabrika: Bu, katman-4 protokol örneği tarafından TCP oluşturmak için kullanılır
doğru tipte prizler.

Şu anda mevcut olan üç TCP uygulaması vardır. ns-3.

· ns-3 için yerel olarak uygulanan bir TCP

· destek ağ Simulation beşik (MGK)

· için destek direkt Kod yürütme (DCE)

Şunu da belirtmek gerekir ki, sanal makineleri çeşitli yöntemlerle birleştirme ns-3
bazı ek TCP uygulamalarını da sağlar, ancak bunlar kapsam dışındadır.
bu bölüm.

ns-3 TCP
ns-3.10 sürümüne kadar, ns-3 gelen TCP modelinin bir bağlantı noktasını içeriyordu GTNet'ler. Bu
uygulama, ns-3.10 için Adriam Tam tarafından büyük ölçüde yeniden yazılmıştır. Model tam bir
TCP, çift yönlüdür ve bağlantı kurulumunu modellemeye ve kapatmaya çalışır.
mantık.

TCP'nin uygulanması aşağıdaki dosyalarda bulunur:

kaynak/internet/model/tcp-başlığı.{cc,h}
kaynak/internet/model/tcp-l4 protokolü.{cc,h}
kaynak/internet/model/tcp-soket-fabrika-impl.{cc,h}
kaynak/internet/model/tcp-soket tabanı.{cc,h}
kaynak/internet/model/tcp-tx-arabelleği.{cc,h}
kaynak/internet/model/tcp-rx-arabelleği.{cc,h}
kaynak/internet/model/tcp-rfc793.{cc,h}
kaynak/internet/model/tcp-tahoe.{cc,h}
kaynak/internet/model/tcp-reno.{cc,h}
kaynak/internet/model/tcp-westwood.{cc,h}
kaynak/internet/model/tcp-newreno.{cc,h}
kaynak/internet/model/rtt tahmincisi.{cc,h}
kaynak/ağ/model/sıra numarası.{cc,h}

TCP tıkanıklık kontrolünün farklı varyantları, ortak tabanın alt sınıflanmasıyla desteklenir
sınıf TcpSocketBase. Dahil olmak üzere çeşitli varyantlar desteklenir RFC 793 (tıkanıklık yok
kontrol), Tahoe, Reno, Westwood, Westwood+ ve NewReno. NewReno varsayılan olarak kullanılır. Görmek
kullanılan varsayılan TCP varyantının nasıl değiştirileceği hakkında bu belgenin Kullanım bölümü
simülasyon.

kullanım
Çoğu durumda, TCP kullanımı, uygulama katmanında ns-3
Hangi tür priz fabrikasının kullanılacağını uygulama.

içinde tanımlanan yardımcı işlevleri kullanma kaynak/uygulamalar/yardımcı ve kaynak/ağ/yardımcı, İşte
bir TCP alıcısı nasıl oluşturulur:

// Bu paketleri almak için yıldız "hub" üzerinde bir paket havuzu oluşturun
uint16_t bağlantı noktası = 50000;
Adres lavaboLocalAddress(InetSocketAddress (Ipv4Address::GetAny (), bağlantı noktası));
PacketSinkHelper lavaboHelper ("ns3::TcpSocketFactory", lavaboLocalAddress);
ApplicationContainer lavaboApp = lavaboHelper.Install (serverNode);
sinkApp.Start (Saniye (1.0));
sinkApp.Stop (Saniye (10.0));

Benzer şekilde, aşağıdaki kod parçası, OnOffApplication trafik kaynağını TCP kullanacak şekilde yapılandırır:

// TCP'yi sunucuya göndermek için OnOff uygulamalarını oluşturun
OnOffHelper clientHelper ("ns3::TcpSocketFactory", Adres ());

Dikkatli okuyucu, soyut bir tabanın TypeId'sini belirttiğimizi yukarıda not edecektir.
sınıf TcpSocketFabrika. Senaryo nasıl anlatıyor ns-3 yerli istediğini ns-3 TCP
vs. başka biri mi? Düğüme internet yığınları eklendiğinde, varsayılan TCP
düğümde toplanan uygulama, ns-3 TCP. Bu geçersiz kılınabilir
Aşağıda Network Simulation Cradle'ı kullanırken gösteriyoruz. Bu nedenle, varsayılan olarak, ns-3
yardımcı API, bir İnternet yığınıyla düğümlere toplanan TCP, yerel ns-3
TCP.

TCP davranışını yapılandırmak için, bir dizi parametre, ns-3
nitelik sistemi. Bunlar belgede Doxygen
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> sınıf için TcpSocket. Için
örneğin, maksimum segment boyutu ayarlanabilir bir niteliktir.

İnternet yığını ile ilgili nesneler oluşturulmadan önce varsayılan soket türünü ayarlamak için
simülasyon programının en üstüne aşağıdaki ifadeyi koyabilir:

Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

Gerçek sokete bir işaretçiye sahip olmak isteyen kullanıcılar için (böylece soket işlemleri
Bind(), soket seçeneklerinin ayarlanması vb. soket bazında yapılabilir), Tcp soketleri
kullanılarak oluşturulacak Soket::CreateSocket() yöntem. TypeId aktarıldı
CreateSocket() türünde olmalıdır ns3::SocketFactory, bu nedenle temeldeki soketi yapılandırma
type, temel alınan TcpL4Protocol ile ilişkili özniteliği çevirerek yapılmalıdır.
nesne. Buna ulaşmanın en kolay yolu, öznitelik yapılandırması olacaktır.
sistem. Aşağıdaki örnekte, sıfırıncı değeri almak için "n0n1" Düğüm kapsayıcısına erişilir.
öğesi ve bu düğümde bir soket oluşturulur:

// Soketi oluştur ve bağla...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));
Ptr yerelSocket =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Yukarıda, düğüm numarası için "*" joker karakteri öznitelik yapılandırma sistemine iletilir,
böylece tüm düğümlerdeki gelecekteki tüm soketler, yalnızca 'n0n1.Get (0)' düğümünde değil, Tahoe'ya ayarlanır.
Bunu yalnızca belirtilen düğümle sınırlamak isterse, şöyle bir şey yapması gerekir:

// Soketi oluştur ve bağla...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream düğüm kimliği;
nodeId << n0n1.Get (0)->GetId ();
std::string spesifikNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (belirliNode, TypeIdValue (tid));
Ptr yerelSocket =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

Bir TCP soketi oluşturulduktan sonra, kişi geleneksel soket mantığını takip etmek isteyecek ve ya
connect() ve send() (bir TCP istemcisi için) veya bind(), listen() ve kabul() (bir TCP için)
sunucu). Soketlerin nasıl kullanıldığına ilişkin bir inceleme için Sockets-API'lere bakın. ns-3.

Onaylama
Birkaç TCP doğrulama testi sonucu şu adreste bulunabilir: wiki Kanal bunu anlatan
uygulanması.

akım sınırlamaları
· SACK desteklenmiyor

ağ Simulation beşik
The ağ Simulation beşik (MGK) gerçek dünya ağ kodunu sarmak için bir çerçevedir
simülatörlere dönüştürerek, gerçek dünyadaki davranışların çok az ekstra maliyetle simülasyonuna izin verir. Bu
çalışma, aynı ağ ile bir test ağı kullanılarak durumları karşılaştırarak doğrulanmıştır.
Simülatördeki durumlar. Bugüne kadar, NSC'nin üretebildiği gösterilmiştir.
son derece doğru sonuçlar. NSC, dört gerçek dünya yığınını destekler: FreeBSD, OpenBSD, lwIP
ve Linux. Ağ yığınlarının hiçbirinin elle değiştirilmemesine vurgu yapılmıştır. Değil
herhangi birinin ağ protokolü uygulamalarında tek bir kod satırı değiştirildi
yukarıdaki dört yığın. Ancak, programlı olarak değiştirmek için özel bir C ayrıştırıcı oluşturuldu
kaynak kodu.

NSC daha önce ns-2 ve OMNeT++ eklendi ve ns-3 Eylül ayında
2008 (ns-3.2 sürümü). Bu bölüm aşağıdakileri açıklar: ns-3 NSC limanı ve nasıl kullanılacağı.

Bir dereceye kadar, NSC'nin yerini, Linux çekirdeği desteği almıştır. direkt Kod
infaz (DCE). Bununla birlikte, NSC, fırında inşa sistemi aracılığıyla hala kullanılabilir. MGK
Linux çekirdekleri 2.6.18 ve 2.6.26'yı destekler, ancak çekirdeğin daha yeni sürümleri henüz kurulmamıştır.
portlu.

Önkoşullar
Şu anda, NSC test edilmiş ve şu platformlarda çalıştığı gösterilmiştir: Linux i386 ve Linux
x86-64. NSC, powerpc'yi desteklemez. FreeBSD veya OS X'te kullanım desteklenmez (ancak
çalışabilir).

NSC oluşturmak, esnek ve bizon paketlerini gerektirir.

yapılandırma ve İndirilmesi
ns-3.17 veya sonrasında, NSC ya kendi deposundan ayrı olarak indirilmelidir,
veya kullanırken indirirken fırında inşa etmek sistem of ns-3.

ns-3.17 veya sonraki sürümler için, fırında pişirme kullanılırken, NSC'yi bir
"allinone" yapılandırması, örneğin:

$ cd fırında
$ python bake.py -e ns-allinone-3.19 yapılandır
$ python bake.py indir
$ python bake.py yapı

Yayımlanmış bir sürüm yerine, ns-3 geliştirme sürümü belirtilerek kullanılabilir.
"ns-3-allinone" ile yukarıdaki yapılandırma adımına geçin.

NSC ayrıca şu adresten indirilebilir: onun indir yer Mercurial'ı kullanarak:

$ hg klonu https://secure.wand.net.nz/mercurial/nsc

ns-3.17 sürümünden önce, NSC allinone tarball'a dahil edildi ve serbest bırakıldı
sürümün ayrıca indirilmesine gerek yoktu.

bina ve doğrulayarak
NSC, fırında yapım sürecinin bir parçası olarak oluşturulabilir; alternatif olarak, bir kişi tarafından NSC oluşturulabilir
kendi yapı sistemini kullanarak; Örneğin:

$ cd nsc-dev
$ piton scons.py

NSC, manuel olarak veya fırınlama sistemi aracılığıyla oluşturulduktan sonra, ns-3
kaynak dizini ve aşağıdaki yapılandırmayı çalıştırmayı deneyin:

$ ./waf yapılandır

NSC daha önce waf tarafından kurulmuş ve bulunmuşsa, şunu göreceksiniz:

Ağ Simülasyon Yuvası: etkin

NSC bulunamadıysa, şunları göreceksiniz:

Ağ Simülasyonu Yuvası: etkinleştirilmedi (NSC bulunamadı (bkz. --with-nsc seçeneği))

Bu durumda, NSC kitaplıklarına göreli veya mutlak yolu iletmelisiniz.
"--with-nsc" yapılandırma seçeneği; Örneğin

$ ./waf --with-nsc=/path/to/my/nsc/directory'yi yapılandırın

Her Ticaretçi İçin Mükemmellik ns-3 kullanarak, ns-3.17 sürümünden önceki sürümler build.py ns-3-allinone'da komut dosyası
dizini, platform desteklemediği sürece NSC varsayılan olarak oluşturulacaktır. İle
oluştururken açıkça devre dışı bırakın ns-3, yazın:

$ ./waf yapılandırma --enable-examples --enable-tests --disable-nsc

waf NSC'yi algılarsa, bina ns-3 NSC ile waf ile aynı şekilde gerçekleştirilir.
o olmadan. Bir kere ns-3 oluşturuldu, aşağıdaki test paketini çalıştırmayı deneyin:

$ ./test.py -s ns3-tcp-birlikte çalışabilirlik

NSC başarıyla oluşturulduysa, sonuçlarda aşağıdaki test görünmelidir:

PASS TestSuite ns3-tcp-birlikte çalışabilirlik

Bu, NSC'nin kullanıma hazır olduğunu onaylar.

kullanım
Birkaç örnek dosya var. Denemek:

$ ./waf -- tcp-nsc-zoo'yu çalıştır
$ ./waf -- tcp-nsc-lfn'yi çalıştır

Bu örnekler bazı .pcap tarafından incelenebilen dizininizdeki dosyalar
tcpdump veya wireshark.

şuna bir bakalım örnekler/tcp/tcp-nsc-zoo.cc bazı tipik kullanımlar için dosya. Nasıl yaptı
yerel kullanmaktan farklı ns-3 TCP? NSC kullanırken bir ana yapılandırma satırı vardır
ve ns-3 ayarlanması gereken yardımcı API:

İnternet Yığını Yardımcısı internet Yığını;

internetStack.SetNscStack ("liblinux2.6.26.so");
// bu, 0 ve 1 düğümlerini NSC'lerin Linux 2.6.26 yığınına değiştirir.
internetStack.Install (n.Al(0));
internetStack.Install (n.Al(1));

Anahtar çizgi şudur: Nsc Yığınını Ayarla. Bu, InternetStack yardımcısına toplamasını söyler
yerel yerine NSC TCP örnekleri ns-3 Kalan düğümlere TCP. Bu önemli
bu fonksiyonun çağrılması önce çağırmak Düzenlemek() işlevi, yukarıda gösterildiği gibi.

Hangi yığınlar kullanılabilir? Şu anda, odak noktası Linux 2.6.18 ve Linux olmuştur.
için 2.6.26 yığın ns-3. Hangi yığınların oluşturulduğunu görmek için aşağıdaki bulguyu uygulayabilirsiniz.
komut ns-3 üst düzey dizin:

$ nsc -name "*.so" -f tipini bul
nsc/linux-2.6.18/liblinux2.6.18.so
nsc/linux-2.6.26/liblinux2.6.26.so

Bu bize liblinux2.6.18.so kitaplık adını geçebileceğimizi veya
liblinux2.6.26.so yukarıdaki yapılandırma adımına.

Yığın yapılandırma
NSC TCP, TCP yuvaları arasında ortak olan aynı yapılandırma özniteliklerini paylaşır.
yukarıda açıklanan ve belgelenen Doxygen

Ek olarak, NSC TCP, birçok yapılandırma değişkenini ns-3 öznitelikleri
sistemi aracılığıyla, bir sysctl-gibi arayüz. İçinde örnekler/tcp/tcp-nsc-hayvanat bahçesi örneğin, görebilirsiniz
aşağıdaki yapılandırma:

// bu, düğüm 1'deki TCP SACK, wscale ve zaman damgalarını devre dışı bırakır (öznitelikler
sysctl değerlerini temsil eder).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
StringValue ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
StringValue ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
StringValue ("0"));

Bu ek yapılandırma değişkenleri yerel olarak kullanılamaz ns-3 TCP.

Ayrıca, TCP öznitelikleri için varsayılan değerlerin şuna dikkat edin: ns-3 TCP, nsc TCP'den farklı olabilir
uygulama. özellikle ns-3:

1. TCP varsayılan MSS'si 536'dır.

2. TCP Gecikmeli Onay sayısı 2'dir.

Bu nedenle, nsc kullanılarak elde edilen sonuçlar arasında karşılaştırma yaparken ve ns-3 TCP, bakım
bu değerlerin uygun şekilde ayarlandığından emin olmak için alınmalıdır. Görmek
Bir örnek için /examples/tcp/tcp-nsc-comparision.cc.

MGK API
Bu alt bölüm, NSC'nin sunduğu API'yi açıklar. ns-3 veya başka bir simülatör. MGK
API'sini, içinde tanımlanan bir dizi sınıf şeklinde sağlar.
sim/sim_interface.h nsc dizininde.

· INetStack INetStack, işletim sistemi ağı için 'düşük seviye' işlemleri içerir
yığın, örneğin ağ yığınından gelen ve ağ yığınına giriş ve çıkış işlevleri (bunu şu şekilde düşünün:
'ağ sürücüsü arayüzü'. Yeni TCP veya UDP yuvaları oluşturma işlevleri de vardır.

· ISendCallback Bu, ağa bir paket gönderilmesi gerektiğinde NSC tarafından çağrılır.
Bu simülatör, paketi simülatöre yeniden enjekte etmek için bu geri aramayı kullanmalıdır.
gerçek veriler hedefine iletilebilir/yönlendirilebilir, burada sonunda
Receive()'a teslim edildi (ve sonunda alıcılara NSC örneğine
INetStack->if_receive() ).

· INetStreamSocket Bu, belirli bir bağlantı uç noktasını tanımlayan yapıdır (dosya
tanımlayıcı). Bu uç noktada çalışmak için yöntemler içerir, örneğin bağlan, bağlantıyı kes,
kabul et, dinle, send_data/read_data, ...

· IInterruptGeri Arama Bu, NSC tarafından her seferinde çağrılan uyandırma geri aramasını içerir.
ilgi çekici bir şey olur. Wakeup()'ı işletim sisteminin bir yedeği olarak düşünün.
sistem uyandırma işlevi: İşletim sistemi, bir işlemi ne zaman uyandırırsa,
bir işlemin tamamlanmasını bekliyordu (örneğin, sırasında TCP el sıkışması)
connect()), NSC, simülatörün durumu kontrol etmesine izin vermek için wakeup() geri çağrısını başlatır
bağlantı uç noktalarındaki değişiklikler.

ns-3 uygulama
The ns-3 uygulama, yukarıdaki NSC API'sini kullanır ve aşağıdaki gibi uygulanır.

Üç ana kısım şunlardır:

· ns3::NscTcpL4Protokol: Ipv4L4Protocol'un bir alt sınıfı (ve iki nsc sınıfı: ISendCallback
ve IInterruptCallback)

· ns3::NscTcpSocketImpl: TcpSocket'ın bir alt sınıfı

· ns3::NscTcpSocketFactoryImpl: yeni NSC soketleri oluşturmak için bir fabrika

kaynak/internet/model/nsc-tcp-l4-protokolü ana sınıftır. Başlatma üzerine, bir
kullanılacak nsc ağ yığını (dlopen() aracılığıyla). Bu sınıfın her örneği farklı bir
yığın. Kullanılacak yığın (=paylaşılan kitaplık) SetNscLibrary() yöntemi kullanılarak ayarlanır (bu noktada
zaman, internet yığını yardımcısı aracılığıyla dolaylı olarak çağrılır). nsc yığını daha sonra kurulur
buna göre (zamanlayıcılar vb.). NscTcpL4Protocol::Receive() işlevi paketi teslim eder.
sonraki işlemler için nsc yığınına alır (tam bir tcp/ip paketi olmalıdır). İle
paket gönderebilmek için bu sınıf nsc send_callback yöntemini uygular. Bu method
nsc yığını ağa bir paket göndermek istediğinde nsc tarafından çağrılır. Onun
argümanlar, tam bir TCP/IP paketi ve bir uzunluk değeri içeren ham bir arabellektir. Bu
bu nedenle yöntem, ham verileri bir Ptr'ye dönüştürmek zorundadır. tarafından kullanılabilir ns-3. Amacıyla
çeşitli ipv4 başlık sorunlarından kaçının, nsc ip başlığı dahil değildir. Bunun yerine, tcp
başlık ve gerçek yük, Ptr'ye konur , bundan sonra Paket
paketi göndermek için katman 3'e aktarılır (başka bir özel işleme gerek yoktur)
gönderme kodu yolunda).

Bu sınıf çağırır ns3::NscTcpSocketImpl hem nsc wakeup() geri çağrısından hem de
Alma yolu (muhtemelen kuyruğa alınmış verilerin gönderilmek üzere planlandığından emin olmak için).

kaynak/internet/model/nsc-tcp-soket-impl nsc soket arabirimini uygular. Her örnek
kendi nscTcpSocket'ına sahiptir. Send() olan veriler, nsc yığınına şu yolla iletilecektir:
m_nscTcpSocket->send_data(). (ve nsc-tcp-l4 için değil, karşılaştırıldığında bu en büyük farktır.
için ns-3 TCP). Sınıf ayrıca Send() olan verileri temel alınandan önce kuyruğa alır.
tanımlayıcı KURULDU durumuna girdi. Bu sınıf nsc-tcp-l4'ten çağrılır.
nsc-tcp-l4 wakeup() geri çağrısı nsc tarafından çağrıldığında. nsc-tcp-socket-impl sonra
mevcut bağlantı durumunu (SYN_SENT, ESTABLISHED, LISTEN...) ve programları kontrol eder
gerektiği gibi uygun geri aramalar, örneğin bir DİNLE soketi, yeni bir
bağlantı kabul edilmelidir, KURULAN bir soket, bekleyen verileri yazmak için planlar,
bir okuma geri araması planlayın, vb.

Bunu not et ns3::NscTcpSocketImpl nsc-tcp ile doğrudan etkileşime girmez: bunun yerine veriler
nsc'ye yönlendirildi. nsc-tcp, uyandırma geri çağrısı yapıldığında bir düğümün nsc-tcp-soketlerini çağırır.
nsc tarafından çağrılır.

Sınırlamalar
· NSC yalnızca tek arabirimli düğümlerde çalışır; çok arayüzlü bir düğümde çalıştırmaya çalışmak
program hatasına neden olur.

· Cygwin ve OS X PPC desteklenmez; OS X Intel desteklenmez ancak çalışabilir

· NSC'nin Linux olmayan yığınları şu durumlarda desteklenmez: ns-3

· Tüm soket API geri aramaları desteklenmez

Daha fazla bilgi için bkz: Re-Tweet wiki Kanal.

kodel kuyruk uygulama in ns-3
Bu bölüm, CoDel ([Nic12], [Nic14]) kuyruk uygulamasını açıklamaktadır. ns-3.

Kathleen Nichols ve Van Jacobson tarafından tampon şişkinliğine bir çözüm olarak geliştirildi [Buf14]
CoDel (Kontrollü Gecikme Yönetimi), bir paketin
paket düşüşleri hakkında karar vermek için bekleme süresi (kuyruktaki süre).

Model Tanım
CoDel modelinin kaynak kodu dizinde bulunur. kaynak/internet/model ve
2 dosyadan oluşur codel-sıra.h ve codel-sıra.cc bir CoDelQueue sınıfı ve bir
yardımcı CoDelTimestampTag sınıfı. Kod şuraya taşındı: ns-3 Andrew McGregor tarafından
Dave Täht ve Eric Dumazet tarafından uygulanan Linux çekirdek kodu.

· sınıf KodSırası: Bu sınıf, ana CoDel algoritmasını uygular:

· CoDelQueue::DoEnqueue (): Bu rutin, bir paketi önceki geçerli zamanla etiketler.
sıraya itiyor. Zaman damgası etiketi tarafından kullanılır CoDelQueue::DoDequeue() için
paketin bekleme süresini hesaplayın. Paket geldiğinde kuyruk doluysa, bu
rutin paketi bırakacak ve sıra taşması nedeniyle düşme sayısını kaydedecektir,
hangi depolanır m_dropOverLimit.

· CoDelQueue::Drop olmalı (): Bu rutin CoDelQueue::DoDequeue()yardımcı rutin
Bu, bir paketin bırakılıp bırakılmayacağını, bekleme süresine bağlı olarak belirler.
Konaklama süresi yukarı çıkarsa m_hedef ve en azından sürekli olarak yukarıda kalır
m_aralığı, rutin geri döner gerçek paketi bırakmanın uygun olduğunu gösterir.
Aksi halde döner yanlış.

· CoDelQueue::DoDequeue (): Bu rutin, gerçek paket düşüşünü aşağıdakilere dayalı olarak gerçekleştirir:
CoDelQueue::Drop olmalı ()'nin dönüş değeri ve bir sonraki düşüşü planlar.

· sınıf CoDelZaman DamgasıEtiketi: Bu sınıf, bir paket için zaman damgası etiketlemesini uygular. Bu
etiketi, paketin bekleme süresini (zaman arasındaki fark) hesaplamak için kullanılır.
paketin kuyruğa alınması ve kuyruğa itilme süresi).

2 şube var CoDelQueue::DoDequeue ():

1. Kuyruk şu anda bırakma durumundaysa, bu, bekleme süresinin sona erdiği anlamına gelir.
yukarıda kaldı m_hedef daha fazlası için m_aralığı, rutin uygun olup olmadığını belirler
bırakma durumunu bırakın veya bir sonraki damla zamanı. Ne zaman CoDelQueue::Drop olmalı ()
İade yanlış, kuyruk bırakma durumundan çıkabilir (set m_dropping için yanlış).
Aksi takdirde, kuyruk sürekli olarak paketleri bırakır ve bir sonraki bırakma zamanını günceller.
(m_dropSonraki) aşağıdaki koşullardan biri sağlanana kadar:

1. Kuyruk boştur, bunun üzerine sıra bırakma durumundan çıkar ve çıkar
CoDelQueue::Drop olmalı () rutin;

2. CoDelQueue::Drop olmalı () İade yanlış (yani bekleme süresi aşağıya iner
m_hedef) kuyruğun bırakma durumundan ayrıldığı;

3. Bir sonraki düşüşün zamanı henüz gelmedi (m_dropSonraki şimdiki zamandan daha az) üzerine
kuyruk, durumu tekrar kontrol etmek için bir sonraki paketin kuyruğa alınmasını bekler.

2. Kuyruk bırakma durumunda değilse, rutin bırakma durumuna girer ve
eğer ilk paketi bırak CoDelQueue::Drop olmalı () İade gerçek (geçici demek
zaman yukarıda gitti m_hedef en azından m_aralığı ilk kez veya gitti
kuyruk bırakma durumundan ayrıldıktan sonra tekrar yukarıda).

Referanslar
[Nic12]

K. Nichols ve V. Jacobson, Controlling Queue Delay, ACM Queue, Vol. 10 Sayı 5, Mayıs 2012.
Şu adresten çevrimiçi olarak bulunabilir: http://queue.acm.org/detail.cfm? id = 2209336.

[Nic14]

K. Nichols ve V. Jacobson, İnternet Taslak: Kontrollü Gecikme Aktif Kuyruk Yönetimi,
Mart 2014. Şu adreste çevrimiçi olarak mevcuttur:
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Buf14]
Bufferbloat.net. Şu adreste çevrimiçi olarak mevcuttur: http://www.bufferbloat.net/.

Özellikler
CoDelQueue sınıfının sahip olduğu temel nitelikler şunları içerir:

· Modu: CoDel çalışma modu (BYTES, PAKETLER veya ILLEGAL). Varsayılan mod BYTES'dir.

· MaxPacket'ler: Kuyruğun tutabileceği maksimum paket sayısı. Varsayılan değer
1000 paket olan DEFAULT_CODEL_LIMIT.

· Maks Bayt: Kuyruğun tutabileceği maksimum bayt sayısı. Varsayılan değer 1500 *
1500 * 1000 bayt olan DEFAULT_CODEL_LIMIT.

· MinByte: CoDel algoritması minbayt parametresi. Varsayılan değer 1500 bayttır.

· Aralık: Sürgülü minimum pencere. Varsayılan değer 100 ms'dir.

· Hedef: CoDel algoritması hedef kuyruk gecikmesi. Varsayılan değer 5 ms'dir.

Örnekler
İlk örnek codel-vs-droptail-basic-test.cc bulunan kaynak/internet/örnekler. Karşı
dosyayı çalıştırın (aşağıdaki ilk çağrı mevcut komut satırı seçeneklerini gösterir):

$ ./waf --run "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --run "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

Önceki komutlardan beklenen çıktı iki dosyadır: codel.pcap dosya ve
cwndCoDel.tr (ASCII izleme) dosyası .pcap dosyası, wireshark veya
tcptrace:

$ tcptrace -l -r -n -W codel.pcap

İkinci örnek codel-vs-droptail-asimetric.cc bulunan kaynak/internet/örnekler.
Bu örnek, tipik bir kablolu modem dağıtım senaryosunu modellemeyi amaçlamaktadır. çalıştırmak için
Dosya:

$ ./waf --run "codel-vs-droptail-asimetrik --PrintHelp"
$ ./waf --run codel-vs-droptail-asimetrik

Önceki komutlardan beklenen çıktı altı pcap dosyasıdır:

· codel-vs-droptail-asimetrik-CoDel-server-lan.pcap

· codel-vs-droptail-asimetrik-CoDel-router-wan.pcap

· codel-vs-droptail-asimetrik-CoDel-router-lan.pcap

· codel-vs-droptail-asimetrik-CoDel-cmts-wan.pcap

· codel-vs-droptail-asimetrik-CoDel-cmts-lan.pcap

· codel-vs-droptail-asimetrik-CoDel-host-lan.pcap

Bir öznitelik dosyası:

· codel-vs-droptail-asimetrik-CoDel.attr

Beş ASCII izleme dosyası:

· codel-vs-droptail-asimetrik-CoDel-drop.tr

· codel-vs-droptail-asimetrik-CoDel-drop-state.tr

· codel-vs-droptail-asimetrik-CoDel-sojourn.tr

· codel-vs-droptail-asimetrik-CoDel-length.tr

· codel-vs-droptail-asimetrik-CoDel-cwnd.tr

Onaylama
CoDel modeli kullanılarak test edilir CoDelQueueTest Suite içinde tanımlanan sınıf
src/internet/test/codel-queue-test-suite.cc. Paket 5 test senaryosu içerir:

· Test 1: İlk test, sıraya alma/sıralamayı düşürme olmadan kontrol eder ve
CoDel öznitelikleri doğru şekilde ayarlanabilir.

· Test 2: İkinci test, kuyruğa taşma nedeniyle oluşan düşüşleri kontrol eder.

· Test 3: Üçüncü test, NewtonStep() aritmetiğini Linux'un açık bağlantı noktasına karşı kontrol eder
uygulama

· Test 4: Dördüncü test, ControlLaw()'ı açık Linux bağlantı noktasına karşı kontrol eder
uygulama

· Test 5: Beşinci test, CoDel'e göre sıraya alma/sıralamayı düşürme ile kontrol eder
algoritma

Test paketi aşağıdaki komutlar kullanılarak çalıştırılabilir:

$ ./waf yapılandırma --enable-examples --enable-tests
$ ./waf yapı
$ ./test.py -s kodel sırası

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-queue"
Sayfa sonu

DÜŞÜK ORAN KABLOSUZ KİŞİSEL ALAN AĞ (LR-WPAN)

Bu bölüm, düşük hızlı, kablosuz bağlantı için ns-3 modellerinin uygulanmasını açıklar.
IEEE standardı 802.15.4 (2006) tarafından belirtildiği gibi kişisel alan ağı (LR-WPAN).

Model Tanım
lr-wpan modülünün kaynak kodu dizinde bulunur kaynak/lr-wpan.

Tasarım
Model tasarımı, mimari açıdan standardı yakından takip eder.
[image] lr-wpan modellerinin mimarisi ve kapsamı.UNINDENT

Şekildeki gri alanlar (IEEE Std. 3-802.15.4, Şekil 2006.'den uyarlanmıştır)
modelin kapsamı.

Nicola Baldo'dan Spectrum NetDevice, uygulamanın temelidir.

Uygulama ayrıca Zheng ve Lee tarafından geliştirilen ns-2 modellerinden ödünç almayı planlıyor.
gelecekte.

API'ler
API'ler, ns-3 adlandırma kuralları ve deyimler için uyarlanmış standardı yakından takip eder. bu
API'ler, aşağıda gösterildiği gibi hizmet ilkelleri kavramı etrafında düzenlenmiştir.
Şekil 14, IEEE Std'den uyarlanmıştır. 802.15.4-2006.
[image] Hizmet ilkelleri.UNINDENT

API'ler, dört kavramsal hizmet ve hizmet erişim noktası (SAP) etrafında düzenlenmiştir:

· MAC veri servisi (MCPS)

· MAC yönetim hizmeti (MLME)

· PHY veri servisi (PD)

· PHY yönetim hizmeti (PLME)

Genel olarak, ilkeller aşağıdaki gibi standartlaştırılır (örn. IEEE Bölüm 7.1.1.1.1).
802.15.4-2006):

MCPS-DATA.request (
SrcAddrModu,
DstAddrModu,
DstPANID,
DstAddr,
msduUzunluk,
msdu,
msduTutucu,
TxSeçenekler,
Güvenlik seviyesi,
Anahtar KimliğiModu,
AnahtarKaynak,
KeyIndex
)

Bu, ns-3 sınıfları ve aşağıdaki gibi yöntemlerle eşlenir:

yapı McpsDataRequestParameters
{
uint8_t m_srcAddrModu;
uint8_t m_dstAddrModu;
Kendi ID’n ile mağazalarını oluştur
};

geçersiz
LrWpanMac::McpsDataRequest (McpsDataRequestParameters parametreleri)
{
Kendi ID’n ile mağazalarını oluştur
}

MAC
Şu anda MAC, işaret vermeden yuvasız CSMA/CA varyantını uygular. Şu anda
koordinatörler ve ilgili API'ler için destek yoktur.

Uygulanan MAC, Contiki'nin NullMAC'sine benzer, yani uyku özelliği olmayan bir MAC.
Telsizin her zaman aktif (alıcı veya verici), tamamen kapalı olduğu varsayılır.
aşağı. CCA gerçekleştirilirken çerçeve alımı devre dışı bırakılmaz.

Desteklenen ana API, veri aktarım API'sidir (McpsDataRequest/Indication/Confirm).
Stc 802.15.4-2006'ya göre CSMA/CA, bölüm 7.5.1.4 desteklenir. Çerçeve alımı ve
Std 802.15.4-2006 uyarınca reddetme, bölüm 7.5.6.2 dahil olmak üzere desteklenir
kabuller. Sadece kısa adresleme tamamen uygulandı. Çeşitli iz kaynakları
desteklenir ve izleme kaynakları havuzlara bağlanabilir.

PHY
Fiziksel katman bileşenleri, bir Phy modeli, bir hata oranı modeli ve bir kayıptan oluşur.
modeli. Hata oranı modeli şu anda IEEE 802.15.4 2.4 GHz için hata oranını modellemektedir.
OQPSK için AWGN kanalı; model açıklaması IEEE Std 802.15.4-2006'da bulunabilir,
bölüm E.4.1.7. Phy modeli SpectrumPhy'yi temel alır ve spesifikasyonu takip eder
IEEE Std 6-802.15.4'nın 2006. bölümünde açıklanmıştır. PHY hizmet özelliklerini modeller,
PPDU biçimleri, PHY sabitleri ve PIB öznitelikleri. Şu anda yalnızca iletimi destekliyor
bölüm 2.4'e göre 6.5.3.1 GHz'de belirtilen güç spektral yoğunluk maskesi. gürültü gücü
yoğunluk, frekans bantları boyunca eşit olarak dağılmış termal gürültü olduğunu varsayar. Kayıp
model, mevcut tüm basit (spektrum dışı phy) kayıp modellerini tam olarak kullanabilir. Phy modeli
mevcut tek spektrum kanal modelini kullanır. Fiziksel katman paket üzerinde modellenmiştir.
düzeyi, yani giriş/SFD algılaması yapılmaz. ile paket alımı başlatılacaktır.
SNR -5 dB'den fazlaysa, önsözün ilk biti (modellenmemiş), bkz.
IEEE Std 802.15.4-2006, ek E, Şekil E.2. Paketin alınması sonra sona erecek
paket tamamen iletildi. Alım sırasında gelen diğer paketler eklenecektir.
girişime/gürültüye.

Şu anda alıcı hassasiyeti -106.58 dBm'lik sabit bir değere ayarlanmıştır. Bu
bu sinyal için 1 baytlık referans paketleri için %20'lik bir paket hata oranına karşılık gelir
güç, IEEE Std 802.15.4-2006, bölüm 6.1.7'ye göre. Gelecekte sağlayacağımız
hassasiyeti farklı değerlere değiştirmek için destek.
[image] Paket hata oranı ve sinyal gücü.UNINDENT

NetCihaz
Diğer teknoloji profillerinin (6LoWPAN ve ZigBee gibi)
kendi NetDevice sınıflarını yazarlarsa, kapsülleyen temel bir LrWpanNetDevice sağlanır.
jenerik bir LrWpan cihazı yaratmanın ve şeyleri birbirine bağlamanın ortak işlemleri.

kapsam ve Sınırlamalar
Bu belgenin gelecekteki sürümleri, Ek D'ye benzer bir PICS proforma içerecektir.
IEEE 802.15.4-2006. Mevcut vurgu, 802.15.4 işleminin slotsuz modu üzerindedir.
Zigbee'de kullanım içindir ve kapsam, temel ile tek bir modun (CSMA/CA) etkinleştirilmesiyle sınırlıdır.
veri aktarım yetenekleri. PAN koordinatörleri ile ilişkilendirme henüz desteklenmemektedir ve
genişletilmiş adresleme kullanımı. Girişim AWGN olarak modellenmiştir ancak bu şu anda değildir
iyice test edilmiştir.

NetDevice Tx kuyruğu sınırlı değildir, yani kuyruk nedeniyle paketler asla düşürülmez.
dolu hale geliyor. Aşırı iletim yeniden denemeleri veya kanal erişimi nedeniyle düşebilirler
hatası.

Referanslar
· Kablosuz Ortam Erişim Kontrolü (MAC) ve Fiziksel Katman (PHY) Özellikleri
Düşük Oranlı Kablosuz Kişisel Alan Ağları (WPAN), IEEE Computer Society, IEEE Std
802.15.4-2006, 8 Eylül 2006.

·

J. Zheng ve Myung J. Lee, "IEEE 802.15.4'ün kapsamlı bir performans çalışması", Sensör
Ağ İşlemleri, IEEE Press, Wiley Interscience, Bölüm 4, s. 218-237, 2006.

kullanım
etkinleştirilmesi lr-wpan
Ekle lr-wpan ns-3 ile oluşturulmuş modüller listesine.

Yardımcı
Yardımcı, diğer aygıt yardımcılarından sonra modellenir. Özellikle, izleme (ascii ve
pcap) benzer şekilde etkinleştirilir ve tüm lr-wpan günlük bileşenlerinin etkinleştirilmesi gerçekleştirilir
benzer şekilde. Yardımcının kullanımı şu şekilde örneklenmiştir: örnekler/lr-wpan-data.cc. asci için
izleme, gönderme ve alma izleri Mac katmanına bağlanır.

Bu yardımcı kullanıldığında kanala eklenen varsayılan yayılma kaybı modeli,
Varsayılan parametrelerle LogDistancePropagationLossModel.

Örnekler
Aşağıdaki örneklerde bulunabilecek şekilde yazılmıştır. kaynak/lr-wpan/örnekler/:

· lr-wpan-data.cc: Uçtan uca veri aktarımını gösteren basit bir örnek.

· lr-wpan-hata-mesafe-plot.cc: Paket başarısının varyasyonlarını çizmek için bir örnek
mesafenin bir fonksiyonu olarak oran.

· lr-wpan-hata-model-plot.cc: Phy'yi test etmek için bir örnek.

· lr-wpan-paket-print.cc: MAC başlık alanlarını yazdırmak için bir örnek.

· lr-wpan-phy-testi.cc: Phy'yi test etmek için bir örnek.

Özellikle modül, çok basitleştirilmiş uçtan uca bir veri aktarım senaryosu sağlar,
Uygulanan lr-wpan-data.cc. Şekil, tetiklenen bir dizi olayı göstermektedir.
MAC, üst katmandan bir DataRequest aldığında. Clear Channel'ı çağırır
PHY'den gelen değerlendirme (CCA) ve başarılı olursa çerçeveyi PHY'ye gönderir.
kanal üzerinden iletilir ve eş düğümde bir DataIndication ile sonuçlanır.
[image] Uçtan uca basit LR-WPAN veri aktarımı için veri örneği.UNINDENT

Örnek lr-wpan-hata-mesafe-plot.cc paket başarı oranını (PSR) bir
varsayılan LogDistance yayılma kaybı modelini ve
802.15.4 hata modeli. Kanal (varsayılan 11), paket boyutu (varsayılan 20 bayt) ve
iletim gücü (varsayılan 0 dBm) komut satırı argümanları ile değiştirilebilir. program
adlı bir dosya çıktısı verir 802.15.4-psr-mesafe.plt. Bu dosyayı gnuplot'a yüklemek, bir
dosya 802.15.4-psr-mesafe.epspdf veya diğer formatlara dönüştürülebilir. bu
varsayılan çıktı aşağıda gösterilmiştir.
[image] Programın varsayılan çıktısı lr-wpan-hata-mesafe-plot.cc.UNENDENT

Testler
Aşağıdaki testler yazılmıştır, bunlar içinde bulunabilir: kaynak/lr-wpan/testler/:

· lr-wpan-ack-testi.cc: Teşekkür belgelerinin kullanıldığını ve verildiğini kontrol edin.
doğru sipariş.

· lr-wpan-çarpışma-testi.cc: Parazitli paketlerin doğru alımını test edin ve
çarpışmalar

· lr-wpan-hata-model-test.cc: Hata modelinin tahmin edilebilir değerler verdiğini kontrol edin.

· lr-wpan-paket-test.cc: 802.15.4 MAC başlık/römork sınıflarını test edin

· lr-wpan-pd-plme-sap-test.cc: PLME ve PD SAP'yi IEEE 802.15.4 uyarınca test edin

· lr-wpan-spektrum-değer-yardımcı-testi.cc: Güç arasındaki dönüşümü test edin.
(skaler bir miktar olarak ifade edilir) ve spektral güç ve tekrar geri, %25'e düşer
olası kanallar ve giriş güçleri aralığında tolerans.

Onaylama
Model, gerçek donanıma karşı doğrulanmadı. hata modeli olmuştur
IEEE Std 802.15.4-2006, bölüm E.4.1.7'deki verilerle doğrulanmıştır (Şekil E.2). bu
MAC davranışı (CSMA geri çekilmesi), beklenen davranışa karşı elle doğrulandı. bu
aşağıdaki grafik, hata modeli doğrulamasının bir örneğidir ve çalıştırılarak yeniden üretilebilir.
lr-wpan-hata-model-plot.cc:
[image] Programın varsayılan çıktısı lr-wpan-hata-model-plot.cc.UNENDENT

LTE MODÜL

Tasarım Dökümanlar
Genel Bakış
LTE-EPC simülasyon modeline genel bir bakış şekilde gösterilmiştir. Genel Bakış of the
LTE-EPC simülasyon model. İki ana bileşen vardır:

· LTE Modeli. Bu model, LTE Radyo Protokolü yığınını (RRC, PDCP, RLC, MAC,
PHY). Bu varlıklar tamamen UE ve eNB düğümlerinde bulunur.

· EPC Modeli. Bu modeller, çekirdek ağ arayüzlerini, protokolleri ve varlıkları içerir.
Bu varlıklar ve protokoller SGW, PGW ve MME düğümlerinde bulunur ve kısmen
eNB düğümleri içinde.
[image] LTE-EPC simülasyon modeline genel bakış.UNINDENT

Tasarım Kriterler
LTE Model
LTE modeli, LTE'nin aşağıdaki yönlerinin değerlendirilmesini desteklemek için tasarlanmıştır.
sistemleri:

· Radyo Kaynak Yönetimi

· QoS uyumlu Paket Planlama

· Hücreler Arası Girişim Koordinasyonu

· Dinamik Spektrum Erişimi

LTE sistemlerini doğru bir şekilde izin vermeye yetecek bir ayrıntı düzeyinde modellemek için
Yukarıda belirtilen hususların değerlendirilmesi, aşağıdaki gereksinimler
düşünülen:

1. Radyo düzeyinde, modelin ayrıntı düzeyi en azından
Kaynak Bloğu (RB). Aslında bu, kaynak için kullanılan temel birimdir.
tahsis. Bu minimum ayrıntı düzeyi olmadan modelleme yapmak mümkün değildir.
doğru paket zamanlaması ve hücreler arası parazit. Bunun nedeni, çünkü
paket planlaması RB bazında yapılır, bir eNB yalnızca bir alt kümede iletim yapabilir
mevcut tüm RB'lerin, dolayısıyla yalnızca şu RB'lerde diğer eNB'lere müdahale edilmesi
iletiyor. Bu gereksinimin bir sistemin benimsenmesini dışladığını unutmayın.
sadece kaynak tahsisini değerlendiren seviye simülasyon yaklaşımı
çağrı/taşıyıcı kurulumunun ayrıntı düzeyi.

2. Simülatör, onlarca eNB ve yüzlerce Kullanıcı Ekipmanına (UE) kadar ölçeklendirilmelidir.
Bu, bağlantı seviyesi bir simülatörün, yani radyosu
arayüz, sembol seviyesine kadar bir ayrıntı düzeyi ile modellenmiştir. Bunun nedeni
bir sembol seviyesi modeline sahip olmak, tüm PHY katman sinyalini uygulamak gerekir
muazzam hesaplama karmaşıklığı simülasyonu ciddi şekilde sınırlayan işleme. Aslında,
bağlantı seviyesi simülatörleri normalde tek bir eNB ve bir veya birkaç UE ile sınırlıdır.

3. Simülasyon içinde farklı hücreleri yapılandırmak mümkün olmalıdır, böylece
farklı taşıyıcı frekansları ve sistem bant genişlikleri kullanırlar. tarafından kullanılan bant genişliği
Dinamik spektrumu desteklemek için farklı hücrelerin üst üste gelmesine izin verilmelidir.
[Ofcom2600MHz] ve [RealWireless] içinde açıklananlar gibi lisanslama çözümleri.
Girişim hesaplaması bu durumu uygun şekilde ele almalıdır.

4. LTE standardını daha fazla temsil etmenin yanı sıra mümkün olduğunca yakın olmak
gerçek dünya uygulamalarına göre, simülatör MAC Zamanlayıcı API'sini desteklemelidir
FemtoForum [FFAPI] tarafından yayınlandı. Bu arayüzün şu kişiler tarafından kullanılması bekleniyor:
zamanlama ve Radyo Kaynağının uygulanması için femtocell üreticileri
Yönetim (RRM) algoritmaları. Bu arayüz için destek sunarak
simülatör, LTE ekipman satıcılarının ve operatörlerinin test etmelerini mümkün kılıyoruz.
simülatif ortam, gerçek bir ortamda konuşlandırılacak olan algoritmaların tamamen aynısıdır.
sistem.

5. LTE simülasyon modeli, aşağıda tanımlanan API'nin kendi uygulamasını içermelidir.
[FFAPI]. Satıcıya özgü ile ne ikili ne de veri yapısı uyumluluğu
aynı arayüzün uygulamaları bekleniyor; dolayısıyla, bir uyumluluk katmanı
ile satıcıya özel bir MAC zamanlayıcı kullanılacağı zaman araya yerleştirilmelidir.
simülatör. Bu gereksinim, simülatörün bağımsız olmasına izin vermek için gereklidir.
bu arayüz belirtiminin satıcıya özel uygulamalarından. not ediyoruz
[FFAPI] yalnızca mantıksal bir belirtimdir ve uygulanması (örn.
belirli bir programlama diline) satıcılara bırakılır.

6. Model, üst taraf tarafından IP paketlerinin iletimini simüle etmek için kullanılacaktır.
katmanlar. Bu itibarla, LTE'de Programlama ve
Radyo Kaynak Yönetimi, doğrudan IP paketleriyle değil, RLC ile çalışır
tarafından yapılan IP paketlerinin segmentasyonu ve birleştirilmesi ile elde edilen PDU'lar.
RLC varlıkları. Bu nedenle, RLC katmanının bu işlevsellikleri modellenmelidir.
doğru.

EPC Model
EPC modelinin temel amacı, uçtan uca simülasyon için araçlar sağlamaktır.
LTE modeli üzerinden IP bağlantısı. Bu amaçla, aralarındaki bağlantıyı destekler.
birden çok eNB'nin bir radyo erişim ağı aracılığıyla İnternet'e bağlanması
Şekilde gösterildiği gibi tek SGW/PGW düğümü Genel Bakış of the LTE-EPC simülasyon model.

EPC modeli için aşağıdaki tasarım seçimleri yapılmıştır:

1. Desteklenen tek Paket Veri Ağı (PDN) türü IPv4'tür.

2. SGW ve PGW işlevsel varlıkları, tek bir düğüm içinde uygulanır;
dolayısıyla SGW/PGW düğümü olarak anılır.

3. SGW'ler arası hareketliliğe sahip senaryolar ilgi çekici değildir. Bu nedenle, tek bir SGW/PGW
düğüm tüm simülasyon senaryolarında bulunacak

4. EPC modeli için bir gereklilik, uçtan uca simüle etmek için kullanılabilmesidir.
gerçekçi uygulamaların performansı. Bu nedenle, ile kullanmak mümkün olmalıdır
EPC, TCP veya UDP üzerinde çalışan herhangi bir normal ns-3 uygulamasını model alır.

5. Diğer bir gereklilik, ağ topolojilerinin simüle edilmesi olasılığıdır.
bazıları bir ana taşıyıcı ile donatılmış olabilecek birden fazla eNB'nin varlığı
sınırlı yeteneklerle bağlantı. Bu tür senaryoları simüle etmek için kullanıcı
eNB'ler ve SGW/PGW arasında kullanılan veri düzlemi protokolleri modellenmelidir.
doğru.

6. Tek bir UE'nin farklı uygulamalarla farklı uygulamaları kullanması mümkün olmalıdır.
QoS profilleri. Bu nedenle, her UE için birden fazla EPS taşıyıcısı desteklenmelidir. Bu
içinde UE'de yapılan IP üzerinden TCP/UDP trafiğinin gerekli sınıflandırmasını içerir.
yukarı bağlantıda ve aşağı bağlantıda PGW'de.

7. EPC modelinin odak noktası esas olarak EPC veri düzlemidir. doğru modelleme
EPC kontrol düzlemi şimdilik bir gereklilik değildir; bu nedenle,
gerekli kontrol düzlemi etkileşimleri basitleştirilmiş bir şekilde modellenebilir.
aracılığıyla farklı simülasyon nesneleri arasındaki doğrudan etkileşimden yararlanarak
sağlanan yardımcı nesneler.

8. EPC modelinin odak noktası, ECM bağlantılı modda aktif kullanıcıların simülasyonlarıdır.
Bu nedenle, yalnızca ECM boş modu için geçerli olan tüm işlevler (özellikle,
izleme alanı güncelleme ve sayfalama) hiç modellenmemiştir.

9. Model, iki araç arasında X2 tabanlı bir geçiş gerçekleştirme olanağına izin vermelidir.
eNB'ler.

mimari
LTE Model
UE mimari
UE'nin LTE radyo protokolü yığın modelinin mimarisi şu şekilde temsil edilir:
rakamlar LTE radyo protokol yığın mimari için the UE on the veri düzlem ve LTE radyo
protokol yığın mimari için the UE on the kontrol düzlem sırasıyla vurgulayan
veri düzlemi ve kontrol düzlemi.
[image] Veri düzleminde UE için LTE radyo protokolü yığın mimarisi.UNINDENT
[image] Kontrol düzleminde UE için LTE radyo protokolü yığın mimarisi.UNINDENT

UE'nin PHY/kanal modelinin mimarisi şekilde temsil edilmektedir. PHY ve
kanal model mimari için the UE.
[image] UE.UNINDENT için PHY ve kanal modeli mimarisi

eNB mimari
eNB'nin LTE radyo protokolü yığın modelinin mimarisi şu şekilde temsil edilir:
rakamlar LTE radyo protokol yığın mimari için the eNB on the veri düzlem ve LTE radyo
protokol yığın mimari için the eNB on the kontrol düzlem sırasıyla vurgulayan
veri düzlemi ve kontrol düzlemi.
[image] Veri düzlemindeki eNB için LTE radyo protokolü yığın mimarisi.UNINDENT
[image] Kontrol düzlemindeki eNB için LTE radyo protokolü yığın mimarisi.UNINDENT

eNB'nin PHY/kanal modelinin mimarisi şekilde temsil edilmektedir. PHY ve
kanal model mimari için the eNB.
[image] eNB.UNINDENT için PHY ve kanal modeli mimarisi

EPC Model
EPC veri düzlem
Şekilde LTE-EPC veri düzlem protokol yığın, uçtan uca LTE-EPC verilerini temsil ediyoruz
simülatörde modellendiği gibi düzlem protokol yığını. Şekilden de anlaşılıyor
veri düzlemi modelinde sunulan en büyük sadeleştirme,
S5 ihtiyacını ortadan kaldıran tek bir SGW/PGW düğümünde SGW ve PGW işlevselliği
veya 8GPP tarafından belirtilen S3 arayüzleri. Öte yandan, hem S1-U protokol yığını için
ve LTE radyo protokolü yığını, 3GPP tarafından belirtilen tüm protokol katmanları mevcuttur.
[image] LTE-EPC veri düzlemi protokol yığını.UNINDENT

EPC kontrol düzlem
Kontrol düzlemi modelinin uygulanmasının mimarisi şekilde gösterilmiştir. EPC
kontrol model. Açıkça modellenen kontrol arayüzleri S1-AP, X2-AP'dir.
ve S11 arayüzleri.

S1-AP ve S11 arayüzlerinin basitleştirilmiş bir şekilde modellendiğini not ediyoruz.
varlıklar arasındaki etkileşimi modellemek için sadece bir çift arayüz sınıfı kullanarak
farklı düğümlerde bulunur (S1-AP arayüzü için eNB ve MME ve MME ve
S11 arayüzü için SGW). Pratikte, bu, bunların ilkellerinin
arabirimler, iki nesne arasındaki doğrudan işlev çağrısına eşlenir. Diğer yandan
X2-AP arayüzü, bir X2 bağlantısı üzerinden gönderilen protokol veri birimleri kullanılarak modelleniyor
(noktadan noktaya bağlantı olarak modellenmiştir); bu nedenle X2-AP arayüz modeli daha çok
gerçekçi.
[image] EPC kontrol modeli.UNINDENT

Telegram Kanal ve Yayılma
Kanal modelleme amaçları için LTE modülü, Spektrum Kanalı sağlanan arayüz
Spektrum modülü tarafından. Bu yazının yazıldığı sırada, bu tür arayüzün iki uygulaması
mevcut: SingleModelSpektrumKanal ve Çoklu Model Spektrum Kanalıve LTE
modülün kullanılmasını gerektirir. Çoklu Model Spektrum Kanalı düzgün çalışabilmek için. Bu
farklı frekans ve bant genişliği yapılandırmalarını destekleme ihtiyacından kaynaklanmaktadır. Herşey
tarafından desteklenen yayılma modelleri Çoklu Model Spektrum Kanalı içinde kullanılabilir
LTE modülü.

Kullanım of the Binalar model ile LTE
LTE modülüyle birlikte kullanılması önerilen yayılma modeli, tarafından sağlanan modeldir.
Aslında LTE ile özel olarak tasarlanmış Binalar modülü (ancak
diğer kablosuz teknolojilerle de kullanılır). Lütfen belgelerine bakın
Sağladığı yayılma modeli hakkında genel bilgiler için Binalar modülü.

Bu bölümde, özellikle aşağıdaki durumlarda geçerli olan bazı hususları vurgulayacağız.
Binalar modülü, LTE modülü ile birlikte kullanılır.

Aşağıdakilerde kullanılan adlandırma kuralı şöyle olacaktır:

· Kullanıcı ekipmanı: UE

· Makro Baz İstasyonu: MBS

· Küçük hücreli Baz İstasyonu (örn. pico/femtocell): SC

LTE modülü yalnızca FDD'yi dikkate alır ve aşağı bağlantı ve yukarı bağlantı yayılımını uygular
ayrı ayrı. Sonuç olarak, aşağıdaki pathloss hesaplamaları yapılır:

· MBS <-> UE (iç ve dış mekan)

· SC (iç ve dış mekan) <-> UE (iç ve dış mekan)

LTE modeli aşağıdaki yol kaybı hesaplamalarını sağlamaz:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

Binalar modeli, düğümün gerçek türünü bilmiyor; yani farkında değil
bir verici düğümünün bir UE, bir MBS veya bir SC olup olmadığı. Bunun yerine, Binalar modeli yalnızca
düğümün konumu hakkında: iç ve dış mekan olup olmadığı ve z ekseni nedir
çatı katına saygı. Sonuç olarak, dış mekana yerleştirilen bir eNB düğümü için ve
çatı seviyesinin üzerinde bir z-koordinatında, MBS'ye özgü yayılım modelleri şöyle olacaktır:
Binalar modülü tarafından kullanılır. Tersine, dış mekana ancak ekranın altına yerleştirilmiş bir eNB için
çatı katında veya iç mekanda, pico ve femtocell'lerin tipik yayılma modelleri kullanılacaktır.

En az bir iç düğüm içeren iletişim için, karşılık gelen duvar penetrasyonu
kayıplar Binalar modeli ile hesaplanacaktır. Bu, aşağıdaki kullanım durumlarını kapsar:

· MBS <-> iç mekan UE

· dış mekan SC <-> iç mekan UE

· iç mekan SC <-> iç mekan UE

· iç mekan SC <-> dış mekan UE

Gerçek modellerle ilgili ayrıntılar için lütfen Binalar modülünün belgelerine bakın.
her durumda kullanılır.

solan Model
LTE modülü, sırasında geliştirilenden türetilen iz tabanlı bir sönümleme modeli içerir.
GSoC 2010 [Piro2011]. Bu modelin temel özelliği,
simülasyon çalışma zamanı sırasında solma değerlendirmesi, hesaplanan izlere dayalıdır. Bu
simülatörün hesaplama karmaşıklığını sınırlamak için yapılır. Öte yandan, ihtiyacı
izleri saklamak için devasa yapılar; bu nedenle, sayısı arasında bir değiş tokuş
olası parametreler ve bellek doluluğu bulunmalıdır. En önemlileri:

· kullanıcıların hızı: kullanıcılar arasındaki bağıl hız (Doppler frekansını etkiler;
dönüşler, sönümlemenin zaman-varyans özelliğini etkiler)

· musluk sayısı (ve bağıl güç): dikkate alınan çoklu yolların sayısı,
sönümlemenin frekans özelliğini etkiler.

· izin zaman ayrıntı düzeyi: izin örnekleme zamanı.

· izin frekans ayrıntı düzeyi: değerlendirilecek frekanstaki değerlerin sayısı.

· iz uzunluğu: ideal olarak simülasyon süresi kadar büyüktür, pencereleme ile azaltılabilir
mekanizması.

· kullanıcı sayısı: kullanılacak bağımsız izleme sayısı (ideal olarak
kullanıcı).

Matematiksel kanal yayılım modeli ile ilgili olarak, tarafından sağlanan modeli öneriyoruz.
the rayleighchan Matlab'ın işlevi, kabul görmüş bir kanal sağladığı için
Hem zaman hem de frekans alanında modelleme. Daha fazla bilgi için okuyucu,
[matematik çalışmaları] olarak anılır.

Simülatör bir matlab betiği sağlar
(src/lte/model/fading-traces/fading-trace-generator.m) dayalı izler oluşturmak için
simülatör tarafından kullanılan biçim. Ayrıntılı olarak, rayleighchan ile oluşturulan kanal nesnesi
fonksiyonu elde etmek için ayrık zamanlı bir darbe sinyalini filtrelemek için kullanılır.
kanal dürtü yanıtı. Filtreleme, farklı TTI için tekrarlanır, böylece
sonraki zamanla ilişkili kanal yanıtları (TTI başına bir tane). Kanal yanıtı daha sonra
ile işlenmiş pwelch güç spektral yoğunluk değerlerini elde etme işlevi,
daha sonra simülatör modeliyle uyumlu uygun formatta bir dosyaya kaydedilir.

Değişken sayısı oldukça fazla olduğu için hepsini göz önünde bulundurarak izler oluşturun.
büyük boyutta çok sayıda iz üretebilir. Bu hususta değerlendirdiğimiz
3GPP sönümleme yayılma koşullarına dayalı parametrelerin aşağıdaki varsayımları
(bkz. [TS2] Ek B.36104):

· kullanıcıların hızı: tipik olarak yalnızca birkaç ayrık değer dikkate alınır, yani:

· Yaya senaryoları için 0 ve 3 km/s

· Araç senaryoları için 30 ve 60 km/s

· Kentsel senaryolar için 0, 3, 30 ve 60

· kanal tıklamaları: normalde sadece sınırlı sayıda kanal tıklaması dikkate alınır,
örneğin, [TS2] Ek B.36104'de üç modelden bahsedilmiştir.

· zaman ayrıntı düzeyi: TTI başına bir sönümleme değerine ihtiyacımız var, yani her 1 ms'de bir (çünkü bu
ns-3 LTE PHY modelinin zamanında ayrıntı düzeyi).

· frekans ayrıntı düzeyi: RB başına bir sönümleme değerine ihtiyacımız var (bu frekans
ns-3 LTE modeli tarafından kullanılan spektrum modelinin ayrıntı düzeyi).

· izin uzunluğu: simülatör, uygulanan pencereleme mekanizmasını içerir
GSoC 2011 sırasında, her pencere izlemenin bir penceresini almaktan oluşur.
rastgele bir şekilde uzunluk.

· kullanıcı başına sönümleme süreci: kullanıcılar aynı sönümleme izini paylaşır, ancak her kullanıcı için bir
izlemedeki farklı başlangıç ​​noktası rastgele alınır. Bu seçim yapıldı
kullanıcı başına bir solma izi sağlama ihtiyacını ortadan kaldırır.

Düşündüğümüz parametrelere göre, aşağıdaki formül ayrıntılı olarak ifade eder:
solma izlerinin toplam boyutu S_{iz}:

burada S_{örnek}, örneğin bayt cinsinden boyutudur (örneğin, çift kesinlik durumunda 8,
4, kayan nokta kesinliği durumunda), N_{RB}, dikkate alınacak RB sayısı veya RB kümesidir,
T_{iz}, izin toplam uzunluğudur, T_{örnek}, izin zaman çözünürlüğüdür
(1 ms) ve N_{senaryolar}, istenen sönümleme senaryolarının sayısıdır (örn.
farklı kanal muslukları ve kullanıcı hız değerlerinin kombinasyonları). izleri sağlıyoruz
3 farklı senaryo için, Ek B.2'de tanımlanan her musluk konfigürasyonu için bir tane
[TS36104]:

· Yaya: Düğümlerin hızı saatte 3 km'dir.

· Araç: Düğümlerin hızı saatte 60 km'dir.

· Kentsel: düğümlerin hızı saatte 3 km'dir.

dolayısıyla N_{senaryolar} = 3. Tüm izlerde T_{trace} = 10 s ve RB_{NUM} = 100 bulunur. Bu sonuç
toplam 24 MB baytlık izde.

antenler
dayalı olmak SpektrumPhy, LTE PHY modeli, ns-3 aracılığıyla anten modellemesini destekler
AntenModeli sınıf. Bu nedenle, bu sınıfa dayalı herhangi bir model, herhangi bir eNB veya
UE örneği. Örneğin, kullanımı KosinüsAntenModel bir eNB cihazıyla ilişkili
bir makro baz istasyonunun bir sektörünü modellemeye izin verir. Varsayılan olarak, İzotropikAntenModel
hem eNB'ler hem de UE'ler için kullanılır.

PHY
Genel Bakış
Bu LTE simülatöründe sağlanan fiziksel katman modeli,
[Piro2011], aşağıdaki değişikliklerle. Model artık hücreler arası
girişim hesaplaması ve her iki paket de dahil olmak üzere yukarı bağlantı trafiğinin simülasyonu
iletim ve CQI üretimi.

Alt çerçeve Structure
Alt çerçeve, Şekilde açıklandığı gibi kontrol ve veri bölümüne bölünmüştür. LTE alt çerçeve
bölünme..
[image] LTE alt çerçeve bölümü..UNINDENT

RB'ye dayalı simülatörün ayrıntı düzeyi göz önüne alındığında, kontrol ve referans
sinyalizasyon sonuç olarak bu kısıtlama dikkate alınarak modellenmelidir. Göre
standart [TS36211], aşağı bağlantı kontrol çerçevesi her alt çerçevenin başlangıcında başlar
ve tüm sistem bant genişliği boyunca üç sembole kadar sürer, burada gerçek
süre, Fiziksel Kontrol Formatı Gösterge Kanalı (PCFICH) tarafından sağlanır. bu
Tahsisle ilgili bilgiler daha sonra kalan kaynakta şu tarihe kadar eşleştirilir:
Fiziksel Aşağı Bağlantı Kontrol Kanalında PCFICH tarafından tanımlanan süre
(PDCCH). Bir PDCCH, Downlink Control Information (DCI) adı verilen tek bir mesajı taşır.
zamanlayıcının bir kaynak için kaynak tahsisini belirttiği MAC katmanından gelen
belirli kullanıcı PCFICH ve PDCCH, kontrolün iletimi ile modellenmiştir.
mevcut bütünü kapsayan 3/14 milisaniyelik sabit bir sürenin çerçevesi
zamanlayıcı, kontrol bölgesinin boyutunu tahmin etmediğinden bant genişliği. Bu
tek bir iletim bloğunun tüm kontrol çerçevesini sabit bir
mevcut tüm RB'ler arasında güç (yani, PDSCH için kullanılan). Buna göre
özelliği, bu iletim aynı zamanda Referans Sinyali için değerli bir desteği temsil eder.
(RS). Bu, her TTI'nin şu andan itibaren girişim senaryosunun bir değerlendirmesine sahip olmasına izin verir:
tüm eNB'ler (eşzamanlı olarak) kontrol çerçevesini ilgili
kullanılabilir bant genişlikleri Modelin güç artırmayı içermediğini not ediyoruz, çünkü
kanal tahmininin uygulanan modelinde herhangi bir gelişmeyi yansıtmamaktadır.

Sondaj Referans Sinyali (SRS), aşağı bağlantı kontrol çerçevesine benzer şekilde modellenmiştir.
SRS, tüm sistemde periyodik olarak alt çerçevenin son sembolüne yerleştirilir.
Bant genişliği. RRC modülü, dinamik olarak atamak için bir algoritma içerir.
göre bir eNB'ye eklenen gerçek UE sayısının fonksiyonu olarak periyodiklik
UE'ye özgü prosedür (bkz. [TS8.2] Bölüm 36213).

MAC için Telegram Kanal geciktirmek
Gerçek MAC ve PHY uygulamalarının gecikmesini modellemek için, PHY modeli bir
TTI katlarında (1ms) MAC-kanal gecikmesi. Hem veri hem de kontrol iletimi
paketler bu miktar kadar geciktirilir.

CQI geribesleme
CQI geri bildiriminin oluşturulması, [FFAPI]'de belirtilenlere göre yapılır. İçinde
ayrıntılı olarak, periyodik geniş bant CQI'nin (yani, tek bir
kullanımdaki tüm RB'leri temsil ettiği kabul edilen kanal durumu) ve bant içi CQI'leri (yani, bir
her RB için kanal durumunu temsil eden değer kümesi).

Raporlanacak CQI indeksi, önce bir SINR ölçümü ve ardından
bu SINR ölçümünü, onu eşleyecek olan Uyarlamalı Modülasyon ve Kodlamayı geçmek
CQI indeksi.

Aşağı bağlantıda, CQI geri beslemesini oluşturmak için kullanılan SINR iki farklı şekilde hesaplanabilir.
yollar:

1. Ctrl yöntem: SINR, referanstan gelen sinyal gücü birleştirilerek hesaplanır.
sinyaller (simülasyonda PDCCH'ye eşdeğerdir) ve parazit
PDCCH'den güç. Bu yaklaşım, herhangi bir komşu eNB'nin bir
bu eNB'nin gerçekte herhangi bir PDSCH gerçekleştirip gerçekleştirmediğine bakılmaksızın
iletim ve nihai müdahale için kullanılan güç ve RB'lerden bağımsız olarak
PDSCH yayınları.

2. Karışık yöntem: SINR, referanstan gelen sinyal gücü birleştirilerek hesaplanır.
sinyaller (simülasyonda PDCCH'ye eşdeğerdir) ve parazit
PDSCH'den güç. Bu yaklaşım, yalnızca
PDSCH üzerinde aktif olarak veri ileten komşu eNB'ler ve
farklı seviyelerde farklı parazit miktarlarını hesaba katan bant içi CQI'ler üretir.
Gerçek girişim seviyesine göre RB'ler. PDSCH olmaması durumunda
iletim herhangi bir eNB tarafından gerçekleştirilirse, bu yöntem parazitin
sıfır, yani SINR yalnızca sinyalin gürültüye oranı olarak hesaplanacaktır.

Bu iki CQI oluşturma yaklaşımı arasında geçiş yapmak için, LteHelper::UsePdschForCqiGeneration
yapılandırılması gerekiyor: ilk yaklaşım için false ve ikinci yaklaşım için true (true is
varsayılan değer):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (true));

Yukarı bağlantıda iki tür CQI uygulanır:

· SRS tabanlı, UE'ler tarafından periyodik olarak gönderilir.

· PUSCH tabanlı, gerçek iletilen verilerden hesaplanmıştır.

Zamanlayıcı arayüzü, çağrılan bir öznitelik sistemi içerir. UlCqiFiltre yönetmek için
CQI'lerin doğasına göre ayrıntılı olarak filtrelenmesi:

· SRS_UL_CQI yalnızca SRS tabanlı CQI'leri depolamak için.

· PUSCH_UL_CQI yalnızca PUSCH tabanlı CQI'leri saklamak için.

· ALL_UL_CQI alınan tüm CQI'leri saklamak için.

Unutulmamalıdır ki, FfMacZamanlayıcı sadece arayüzü sağlar ve meseledir
bu öznitelikleri yönetmek için kodu dahil etmek için gerçek zamanlayıcı uygulamasının
(bu konuda daha fazla bilgi için zamanlayıcı ile ilgili bölüme bakın).

Girişim Model
PHY modeli, iyi bilinen Gauss girişim modellerine dayanmaktadır.
enterferans sinyallerinin güçleri (doğrusal birimlerde) belirlemek için birlikte toplanır
genel girişim gücü.

Şekil dizi diyagramı Dizi diyagram of the PHY girişim hesaplama
prosedür SINR'yi hesaplamak için enterferans sinyallerinin nasıl işlendiğini ve SINR'nin nasıl yapıldığını gösterir.
daha sonra CQI geri bildiriminin üretilmesi için kullanılır.
[image] PHY girişim hesaplama prosedürünün sıra diyagramı.UNINDENT

LTE Spektrum Model
LTE'de eNB'ler ve UE'ler tarafından radyo spektrumunun kullanımı [TS36101]'de açıklanmıştır. İçinde
simülatör, radyo spektrumu kullanımı aşağıdaki gibi modellenmiştir. f_c LTE Mutlak değerini göstersin
100 kHz'de taşıyıcı frekansını tanımlayan Radyo Frekansı Kanal Numarası
raster; ayrıca, B sayısındaki İletim Bant Genişliği Yapılandırması olsun.
Kaynak Blokları. Simülasyonda kullanılan her çift (f_c,B) için karşılık gelen bir
Spec-spectrum-module tarafından sağlanan işlevselliği kullanarak SpectrumModel. kullanarak model
[Baldo2009]'da açıklanan Spektrum çerçevesi. f_c ve B her biri için yapılandırılabilir
simülasyonda somutlaştırılan eNB; bu nedenle, her eNB farklı bir spektrum modeli kullanabilir.
Her UE, bağlı olduğu eNB'nin spektrum modelini otomatik olarak kullanacaktır. Kullanmak
[Baldo2009]'da açıklanan MultiModelSpectrumChannel, kullanan eNB'ler arasındaki parazit
farklı spektrum modelleri uygun şekilde hesaplanmıştır. Bu, dinamik simülasyonu sağlar
örneğin spektrum lisanslama politikaları gibi spektrum erişim politikaları
[Ofcom2600MHz]'de tartışılmıştır.

Veri PHY Hata Model
Simülatör, veri düzleminin (yani, PDSCH ve PUSCH) bir hata modelini içerir.
standart bağlantı-sistem eşleme (LSM) tekniklerine. Seçim ile uyumlu
OFDMA radyo iletim teknolojisinin standart sistem simülasyon metodolojisi. Sayesinde
LSM, iyi bir doğruluk seviyesini koruyabilir ve aynı zamanda
hesaplama karmaşıklığı artar. Tek bağlantı katmanının eşlenmesine dayanır.
Sisteme bağlantı seviyesi simülatörleri aracılığıyla elde edilen performans (bizim durumumuzda ağ)
simülatörler. Özellikle bağlantı, performans oluşturmak için katman simülatörü kullanılır.
genellikle kod bloğu hata oranı açısından, bir PHY katmanı perspektifinden tek bir bağlantının
(BLER), belirli statik koşullar altında. LSM, bu parametrelerin daha fazla
daha fazla bağlantıya sahip olduğumuz sistem/ağ simülatörlerine özgü karmaşık senaryolar,
girişim ve "renkli" kanal yayılım fenomeni (örneğin, frekans seçici
solma).

Bunu yapmak için Viyana LTE Simülatörü [ViennaLteSim] kullanıldı.
bağlantı katmanı performansının çıkarılması ve Karşılıklı Bilgiye Dayalı Etkili SINR
(MIESM) Signet tarafından yakın zamanda yayınlanan çalışmanın bir bölümünü kullanan LSM eşleme işlevi olarak
Padua Üniversitesi [PaduaPEM] Grubu.

MİİZM
Kabul edilen özel LSM yöntemi, karşılıklı bir bilginin kullanımına dayalıdır.
genellikle kodlanmış bit başına karşılıklı bilgi olarak adlandırılan metrik (MIB veya MMIB
katları MIB'lerin bir ortalaması söz konusudur). Başka bir seçenek tarafından temsil edilecektir
Üstel ESM (EESM); ancak, son çalışmalar MIESM'in EESM'den daha iyi performans gösterdiğini göstermektedir.
doğruluk açısından [LozanoCost].
[image] MIESM hesaplama prosedürü şeması.UNINDENT

Karşılıklı bilgi (MI), takımyıldız haritalamasına bağlıdır ve
semboller üzerinden MI değerlendirilerek taşıma bloğu (TB) bazında hesaplanır ve
alt taşıyıcı. Ancak bu, bir ağ simülatörü için çok karmaşık olacaktır. Dolayısıyla, ülkemizde
uygulama, RB içinde düz bir kanal yanıtı olarak kabul edilmiştir; bu yüzden
Bir TB'nin genel MI'si, TB'de kullanılan her bir RB için değerlendirilen MI'nın ortalaması alınarak hesaplanır.
Ayrıntılı olarak, uygulanan şema Şekilde gösterilmektedir. MİİZM bilişimsel prosedür
diyagram, modelin her RB için MI değerini değerlendirerek başladığını gördüğümüz yerde,
şekilde SINR örnekleri ile temsil edilmektedir. Daha sonra eşdeğer MI başına değerlendirilir
MI değerlerinin ortalamasını alarak TB bazında. Son olarak, bu tarihten itibaren bir adım daha atılmalıdır.
bağlantı düzeyi simülatörü, bağlantının performansını blok hata oranı açısından döndürür
(BLER), blokların kod olduğu ek beyaz guass gürültüsü (AWGN) kanalında
bloklar (CB'ler) turbo kodlayıcı tarafından bağımsız olarak kodlanır/kodları çözülür. Bu konuda
gerçek CB boyutunu tahmin etmek için standart 3GPP segmentasyon şeması kullanılmıştır
([TS5.1.2] bölüm 36212'de açıklanmıştır). Bu şema, TB'yi N_{K_-} olarak böler
K_- boyutundaki bloklar ve K_+ boyutundaki N_{K+} blokları. Bu nedenle genel TB BLER (TBLER)
olarak ifade edilebilir

burada CBLER_i, bağlantı seviyesi simülatörüne göre elde ettiğim CB'nin BLER'idir
CB BLER eğrileri. CBLER_i'yi tahmin etmek için MI değerlendirmesi uygulandı
[wimaxEmd] içinde tanımlanan sayısal yaklaşımına göre. Ayrıca, azaltmak için
hesaplamanın karmaşıklığı, yaklaşıklık aramaya dönüştürülmüştür
tablolar. Ayrıntılı olarak, AWGN'ye yaklaşmak için Gauss kümülatif modeli kullanılmıştır.
Standart AWGN'ye yakın bir uyum sağlayan üç parametreli BLER eğrileri
performanslar, formülde:

x TB'nin MI'sidir, b_{ECR} "geçiş merkezini" temsil eder ve c_{ECR}
her biri için Gauss kümülatif dağılımının "geçiş genişliği" ile ilgili
Kanala göre gerçek aktarım hızı olan Efektif Kod Hızı (ECR)
kodlama ve MCS. Düşündüğümüz modelin hesaplama karmaşıklığını sınırlamak için
olası ECR'lerin yalnızca bir alt kümesi aslında potansiyel olarak 5076 olası ECR'ye sahip olurduk
(yani, 27 MCS ve 188 CB boyutu). Bu bağlamda, CB boyutlarını bazılarıyla sınırlayacağız.
temsili değerler (yani, 40, 140, 160, 256, 512, 1024, 2048, 4032, 6144),
diğerleri, gerçeğe yaklaşan en kötüsü kullanılacaktır (yani, daha küçük CB
gerçek olana göre mevcut boyut değeri). Bu seçim, tipik
CB boyutunun BLER'i güçlü bir şekilde etkilemediği turbo kodlarının performansı.
Bununla birlikte, 1000 bitten küçük CB boyutları için etkinin olabileceği not edilmelidir.
ilgili (yani, 2 dB'ye kadar); bu nedenle, bu dengesiz örnekleme aralığını
gerektiğinde daha fazla hassasiyete sahip olmak. Bu davranış rakamlarla doğrulanır
Annes Bölümünde sunulmuştur.

BLER eğriler
Bu bağlamda, [PaduaPEM] içinde elde edilen eğrilerin bir kısmını yeniden kullandık. Detaylı olarak, biz
geliştiricilerin desteğiyle CB BLER eğrilerine CB boyutu bağımlılığını tanıttı
[PaduaPEM] ve LTE Viyana Simülatörü. Aslında, piyasaya sürülen modül,
bağlantı katmanı performansı yalnızca MCS'lerle ilgili olanlar için (yani, belirli bir sabit ECR ile). İçinde
detay her biri için yeni hata oranı eğrileri bir simülasyon kampanyası ile değerlendirildi
AWGN gürültülü tek bir bağlantı ve 104 CB boyutu için bağlantı katmanı simülatörü ile,
140, 256, 512, 1024, 2048, 4032 ve 6144. Bu eğriler Gauss ile haritalanmıştır.
karşılık gelenleri elde etmek için yukarıda sunulan kümülatif model formülü b_{ECR} ve
c_{ECR} parametreleri.

Bağlantı seviyesi simülatörü ile elde edilen tüm MCS'lerin BLER performansı,
Gauss'a karşılık gelen eşlemeleriyle birlikte aşağıdaki rakamlar (mavi çizgiler)
kümülatif dağılım (kırmızı kesikli çizgiler).
[image] MCS 1, 2, 3 ve 4..UNINDENT için BLER
[image] MCS 5, 6, 7 ve 8..UNINDENT için BLER
[image] MCS 9, 10, 11 ve 12..UNINDENT için BLER
[image] MCS 13, 14, 15 ve 16..UNINDENT için BLER
[image] MCS 17, 17, 19 ve 20..UNINDENT için BLER
[image] MCS 21, 22, 23 ve 24..UNINDENT için BLER
[image] MCS 25, 26, 27 ve 28..UNINDENT için BLER
[image] MCS 29..UNINDENT için BLER

Entegrasyonu of the BLER eğrileri in the ns-3 LTE modül
Uygulanan model, yakın zamanda LTE PHY Hata Modelinin LSM eğrilerini kullanır.
Signet Group [PaduaPEM] tarafından ns3 topluluğunda yayınlandı ve oluşturulan yenileri
farklı CB boyutları için. bu LteSpectrumPhy sınıf, TB BLER'in değerlendirilmesinden sorumludur
tarafından sağlanan yöntemler sayesinde LteMiErrorModel sorumlu olan sınıf,
TB BLER'nin RB, MCS ve MCS başına algılanan SINR vektörüne göre değerlendirilmesi
CB'lerde TB'nin segmentasyonunu uygun şekilde modellemek için boyut. Elde etmek üzere
algılanan SINR vektörü iki örneğini LtePemSinrChunkİşlemci (çocuğu
LteChunk İşlemci fiziksel hata performansı elde etmek için SINR'yi değerlendirmeye adanmış)
UE uydu bağlantısına ve eNB yukarı bağlantısına eklendi LteSpectrumPhy değerlendirmek için modüller
sırasıyla PDSCH (UE tarafı) ve ULSCH (eNB tarafı) hata modeli dağılımı.

Model ayarlanarak sıfır kayıplı bir kanalla çalışmak için devre dışı bırakılabilir. Pem Etkin
özniteliği LteSpectrumPhy sınıf (varsayılan olarak etkindir). Buna göre yapılabilir
standart ns3 öznitelik sistemi prosedürüne, yani:

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (yanlış));

Control Kanallar PHY Hata Model
Simülatör, aşağı bağlantı kontrol kanalları (PCFICH ve PDCCH) için hata modelini içerir,
uplink'te olduğu varsayılır ve hatasız ideal bir kanaldır. Model aşağıdakilere dayanmaktadır:
Frekans seçiciliğin etkilerini dikkate almak için daha önce sunulan MIESM yaklaşımı
kontrol kanallarının çoğu mevcut tüm bant genişliğini kapsadığından kanal.

PCFICH + PDCCH Hata Model
Bu kanalların hata dağılımı için benimsenen model, bir değerlendirmeye dayanmaktadır.
4GPP'nin RAN3'ünde yürütülen ve farklı satıcıların
PCFICH'in PDCCH ile birlikte demodülasyon performansı. Bunun nedeni şudur:
PCFICH, gerçek boyutun UE'lere iletilmesinden sorumlu kanaldır.
PDCCH (1 ve 3 sembol arasında uzanır); bu nedenle doğru kod çözme
DCI'ler her ikisinin de doğru yorumlanmasına bağlıdır. 3GPP'de bu sorun var
hücre kenarı performansının iyileştirilmesi için değerlendirilmiştir [FujitsuWhitePaper], burada
komşu hücreler arasındaki girişim, sinyal bozulması nedeniyle nispeten yüksek olabilir. A
benzer sorun, femto-hücre senaryosunda ve daha genel olarak HetNet'te bildirimler olmuştur.
darboğazın esas olarak PCFICH kanalı olarak tespit edildiği senaryolar [Bharucha2011],
aynı hizmet alanında çok sayıda eNB'nin konuşlandırılması durumunda, bu kanal çarpışabilir.
frekansta, PDCCH kanalının da doğru tespitini imkansız hale getirir.

Simülatörde, alım sırasında algılanan SINR, aşağıdakilere göre tahmin edilmiştir.
PCFICH'in hata dağılımını değerlendirmek için yukarıda sunulan MIESM modeli ve
PDCCH. Ayrıntılı olarak, tüm RB'lerin SINR örnekleri MI değerlendirmesine dahil edilir.
kontrol çerçevesi ile ilişkilendirilir ve bu değerlere göre etkin SINR (eSINR)
MI değerlendirme sürecini tersine çevirerek elde edilir. Unutulmamalıdır ki, durumda
MIMO iletimi, hem PCFICH hem de PDCCH, her zaman iletim çeşitliliği modunu şu şekilde kullanır:
standart tarafından tanımlanır. eSINR'a göre kod çözme hatası algılandı
olasılık [R4-081920]'de sunulan sonuçların fonksiyonu olarak tahmin edilebilir. Durumunda
bir hata oluşur, DCI'lar atılır ve bu nedenle UE,
muhabir Tbs, bu nedenle kayıp.

MIMO Model
Hem verici hem de alıcı tarafında birden fazla antenin kullanılması olarak bilinen
çoklu giriş ve çoklu çıkış (MIMO), literatürde iyi çalışılmış bir problemdir.
geçmiş yıllar. Çalışmaların çoğu, analitik olarak elde edilen kazancın değerlendirilmesine odaklanmaktadır.
kapasite açısından farklı MIMO şemaları olabilir; ancak birileri de sağlar
alınan güç [CatreuxMIMO] cinsinden kazanç bilgisi.

Yukarıdaki hususlara göre, dikkate alınarak daha esnek bir model elde edilebilir.
MIMO şemalarının sisteme istatistiksel bir bakış açısıyla getirdiği kazanç. Olarak
Daha önce vurgulanan [CatreuxMIMO], birkaç MIMO çözümünün istatistiksel kazancını sunar
antenler arasında korelasyon olmaması durumunda SISO'ya göre. Çalışmada
kazanç, SINR çıkışının kümülatif dağılım fonksiyonu (CDF) olarak sunulur.
SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE ve MIMO-ZF şemalarını ilgilendiren konular.
Sonuçları detaylandırarak, çıktı SINR dağılımı bir
dikkate alınan şemanın fonksiyonu olarak farklı ortalama ve varyansa sahip log-normal.
Ancak, varyanslar çok farklı değildir ve yaklaşık olarak bire eşittirler.
SISO modunun gölgeleme bileşenine zaten dahil edilmiştir.
BinalarYayılmaKayıpModel, detayda:

· SISO: = 13.5 ve ma = 20 [dB].

· MIMO-Alamouti: = 17.7 ve ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 ve ma = 16.6 [dB].

· MIMO-OSIC-MMSE: = 12.6 ve ma = 15.5 [dB].

· MIMO-ZF: = 10.3 ve ma = 12.6 [dB].

Bu nedenle PHY katmanı, alıcı tarafından algılanan kazanç olarak MIMO modelini uygular.
SISO kullanılarak elde edilene göre bir MIMO şeması kullanırken. Dikkat ederiz ki, bunlar
MIMO'daki antenler arasında hiçbir korelasyonun olmadığı bir duruma atıfta bulunulan kazançlar
şema; bu nedenle, yol korelasyonu nedeniyle bozulmayı modellemeyin.

UE PHY Ölçümler Model
[TS36214]'e göre, UE, eNB'lerin bir dizi ölçümünü rapor etmelidir.
cihaz şunları algılayabilir: alınan referans sinyali (RSRP) ve
referans sinyali alınan kalite (RSRQ). Birincisi, alınan gücün bir ölçüsüdür.
belirli bir eNB, ikincisi ayrıca kanal paraziti ve termal gürültü içerir.
UE, ölçümleri hücrenin fiziksel hücre kimliği (PCI) ile birlikte rapor etmelidir.
hücre. RS'nin alınması sırasında hem RSRP hem de RSRQ ölçümleri yapılır,
PCI, Birincil Senkronizasyon Sinyali (PSS) ile elde edilirken. PSS gönderilir
eNB tarafından her 5 alt çerçeve ve alt çerçeve 1 ve 6'da ayrıntılı olarak. Gerçek sistemlerde, yalnızca
504 farklı PCI mevcuttur ve bu nedenle yakındaki iki eNB'nin
aynı PCI; ancak simülatörde simülasyon meta verilerini kullanarak PCI'ları modelliyoruz ve
65535'e kadar farklı PCI, böylece 65535'ten daha az olması koşuluyla PCI çakışmaları önlenir
eNB'ler aynı senaryoda simüle edilir.

[TS36133] 9.1.4 ve 9.1.7 bölümlerine göre, RSRP, dBm cinsinden PHY katmanı tarafından rapor edilir
dB cinsinden RSRQ iken. RSRP ve RSRQ değerleri, üst katmanlara şu şekilde sağlanır:
C-PHY SAP (aracılığıyla UeÖlçümlerParametreler struct) içinde tanımlandığı gibi her 200 ms'de bir
[TS36331]. Katman 1 filtreleme, toplanan tüm ölçümlerin ortalaması alınarak gerçekleştirilir.
son pencere yuvası sırasında. Raporlamanın periyodikliği araştırma için ayarlanabilir
yoluyla amaçlar LteUePhy::UeMeasurementsFilterPeriod özniteliği.

RSRP ve RSRQ formülleri, PHY varsayımı dikkate alınarak basitleştirilebilir.
RB içinde kanalın düz olduğu katman, en iyi doğruluk seviyesi. Aslında, bu
bir RB içindeki tüm RE'lerin aynı güce sahip olduğu anlamına gelir, bu nedenle:

burada P(k,m), RB k içindeki RE m'nin sinyal gücünü temsil eder;
önce, aynı RB içinde sabittir ve P(k'ye eşittir), M, taşıyan RE'lerin sayısıdır.
bir RB'deki RS ve K, RB'lerin sayısıdır. Unutulmamalıdır ki P(k) ve genel olarak tüm
bu bölümde tanımlanan güçler, simülatörde RB'nin PSD'sinden elde edilir.
(Şirket tarafından sağlanan LteInterferencePowerChunkİşlemci), detayda:

burada PSD_{RB}(k), RB k'nin güç spektral yoğunluğudur, 180000, Hz cinsinden bant genişliğidir
RB ve 12, bir OFDM sembolündeki RB başına RE sayısıdır. Benzer şekilde, RSSI için biz
var

burada S, bir RB'de RS taşıyan OFDM sembollerinin sayısıdır ve R, RE'lerin sayısıdır.
OFDM sembolünde (2'ye sabitlenmiş) bir RS taşırken, P(k,s,r), I(k,s,r) ve N(k,s,r)
sırasıyla hizmet veren hücrenin algılanan gücünü, girişim gücünü ve
s sembolünde RE r'nin gürültü gücü. RSRP'ye gelince, bir RB içindeki ölçümler
PHY modeline göre her zaman kendi aralarında eşittir; bu nedenle P(k,s,r) = P(k),
I(k,s,r) = I(k) ve N(k,s,r) = N(k), bu, RSSI'nin şu şekilde hesaplanabileceğini gösterir:

PHY alım zinciri uygulamasının kısıtlamalarını göz önünde bulundurarak ve
hesaplama karmaşıklığı seviyesini düşük tutmak, yalnızca RSRP için doğrudan elde edilebilir
tüm hücreler. Bunun nedeni şudur: LteSpectrumPhy değerlendirmek için tasarlanmıştır.
girişim yalnızca hizmet veren eNB'nin sinyaline ilişkindir. Bu, PHY'nin
katman, hizmet veren eNB ile güç sinyalleri bilgilerini yönetmek için optimize edilmiştir.
referans. Ancak, komşu hücre i'nin RSRP ve RSRQ'su akım tarafından çıkarılabilir.
hizmet veren hücre j'nin aşağıda ayrıntıları verilen mevcut bilgileri:

RSRP_i, komşu hücre i'nin RSRP'sidir, P_i(k) herhangi bir RE'de algılanan güçtür
RB k içinde, K, RB'lerin toplam sayısıdır, RSSI_i, komşu hücre i'nin RSSI'sidir.
UE j hücresine bağlandığında (ki bu, alınan tüm güçlerin toplamı olduğundan,
RSSI_j ile çakışır), I_j(k), RB k'nin herhangi bir RE'sinde UE tarafından algılanan toplam girişimdir
i hücresine eklendiğinde ( LteInterferencePowerChunkİşlemci), P_j(k)
RB k ve N'nin herhangi bir RE'sinde j hücresinin algılanan gücü, güç gürültüsü spektralidir
herhangi bir RE'deki yoğunluk. Değerlendirilen RSRQ'nun geçerli olması durumunda örnek geçerli olarak kabul edilir.
Yukarıdaki LteUePhy::RsrqUeMeasEşik özniteliği.

HARQ
Uygulanan HARQ şeması, birleştirilmiş artımlı artıklık (IR) çözümlerine dayanmaktadır.
sürekli bir veri akışı sağlamak için birden fazla dur ve bekle işlemi ile. Ayrıntılı olarak,
benimsenen çözüm, yumuşak birleştirme melez IR Her Şey Dahil artımlı fazlalık (olarak da adlandırılır
IR Tip II), bu, yeniden iletimlerin yalnızca yeni bilgiler içerdiğini ima eder.
öncekilere. HARQ'nun kaynak tahsis algoritması uygulandı
ilgili zamanlayıcı sınıfları içinde (yani, RrFfMacZamanlayıcı ve PfFfMacZamanlayıcı,
daha fazla bilgi için ilgili bölümlerine bakın), kod çözme kısmı ise
HARQ uygulandı LteSpectrumPhy ve LteHarqPhy olacak sınıflar
bu bölümde detaylandırılmıştır.

Standarda göre, UL yeniden iletimleri senkronizedir ve bu nedenle
orijinal iletimden sonra 7 ms tahsis edildi. Öte yandan, DL için bunlar
asenkron ve bu nedenle 7 ms'den başlayarak daha esnek bir şekilde tahsis edilebilir ve
bu, belirli bir zamanlayıcı uygulaması meselesidir. HARQ süreçleri davranışı
Şekilde gösterilen: ref:incir-harq-süreçler-şeması.

MAC katmanında, zamanlayıcıda bulunan HARQ varlığı kontrolden sorumludur.
hem yeni paketler oluşturmak hem de yeniden iletimleri yönetmek için 8 HARQ süreci
DL ve UL. Zamanlayıcı, eNB ve UE PHY katmanlarından HARQ geri bildirimini toplar
(sırasıyla UL ve DL bağlantısı için) FF API temel öğeleri aracılığıyla
SchedUlTriggerReq ve SchedUlTriggerReq. HARQ geri bildirimine ve RLC'ye göre
arabellek durumu, zamanlayıcı, her iki yeniden iletimi içeren bir dizi DCI oluşturur.
HARQ blokları hatalı ve yeni iletimler aldı, genel olarak
önceki. Bu konuda, zamanlayıcı, aşağıdaki durumlarda bir kısıtlamayı dikkate almalıdır.
HARQ yeniden iletimleri için kaynak tahsis ederken, aynı modülasyon sırasını kullanmalıdır.
ilk iletim girişimi (yani, [0..9]'da MCS için QPSK, [16..10]'da MCS için 16QAM
ve [64..17]'de MCS için 28QAM). Bu kısıtlama, oranın belirtilmesinden kaynaklanmaktadır.
algoritmanın modülasyon sırasını sabitlediği 3GPP standardındaki [TS36212] eşleştirici
artıklık sürümlerinin farklı bloklarını oluşturmak.

PHY Hata Modeli modeli (yani, LteMiErrorModel daha önce sunulan sınıf)
parametrelerinin olduğu [wimaxEmd] uyarınca IR HARQ dikkate alınarak genişletildi.
Yeniden iletim durumunda MIESM eşlemesi için AWGN eğrileri eşlemesi şu şekilde verilir:

burada X orijinal bilgi bitlerinin sayısıdır, C_i kodlanmış bitlerin sayısıdır, M_i
toplam q yeniden iletim sayısı üzerinden alınan HARQ bloğu başına karşılıklı bilgiler.
Bu nedenle, hata modeli ile hata olasılığını döndürebilmek için
simülatörde uygulanan R_{eff} ve MI_{I eff} değerini değerlendirir ve değeri döndürür
aynı modülasyonun ECR'sinin hata olasılığının en yakın düşük oranı ile
R_{eff}. HARQ yeniden iletimlerinin etkisini değerlendirmek için yeni bir dizi eğri
orijinal MCS için kullanılan standarda göre entegre edilmiştir. yeni eğriler
bir modülasyonun en muhafazakar MCS'sinin kullanıldığı durumları kapsamaya yöneliktir
bu, standart MCS'lerden birine göre daha düşük R_{eff} üretimi anlamına gelir. Bu konuda
1, 2 ve 3 yeniden iletimler için eğriler, 10 ve 17 için değerlendirilmiştir.
MCS 0, üretilen kod hızı zaten olduğundan yalnızca ilk yeniden iletimi düşündük
çok muhafazakar (yani, 0.04) ve alım için yeterince sağlam bir hata oranı döndürür
(yani, BLER'nin gerilemesi -18 dB civarındadır). Unutulmamalıdır ki,
ilk TB iletiminin boyutunun tüm bilgi bitlerini içerdiği varsayılmıştır.
kodlanmak; bu nedenle X, bir HARQ işleminden gönderilen ilk TB'nin boyutuna eşittir. bu
model, kod sözcüklerinde nihai eşlik bitlerinin varlığının zaten mevcut olduğunu varsayar.
bağlantı seviyesi eğrilerinde dikkate alınır. Bu, minimum R_{eff} olur olmaz
ulaşılan model, daha fazla parite aktarımı nedeniyle kazancı içermiyor
bit.
[image] HARQ, LTE.UNINDENT'te davranışı işler

HARQ bloklarının kod çözülmesini yönetmeye ayrılmış HARQ bölümü,
içinde uygulanan LteHarqPhy ve LteSpectrumPhy sınıflar. Birincisi sorumlu
her aktif proses için HARQ bilgilerinin muhafaza edilmesi. İkincisi ile etkileşime girer
LteMiErrorModel alınan blokların doğruluğunu değerlendirmek için sınıf ve şunları içerir
zamanlayıcıdaki HARQ varlığıyla iletişim kurmaktan sorumlu mesajlaşma algoritması
kod çözme işleminin sonucudur. Bu mesajlar,
dlInfoListElement DL için ve ulInfoListElement UL için ve PUCCH aracılığıyla gönderilir ve
PHICH, kendi varsayımlarına göre ideal bir hatasız model ile sırasıyla
uygulama. HARQ ve LTE protokol yığını arasındaki yinelemenin bir taslağı
Şekilde temsil edilmektedir: referans:incir-harq-mimari.

Son olarak, HARQ motoru hem MAC hem de PHY katmanında her zaman aktiftir; ancak, durumunda
zamanlayıcı HARQ'u desteklemiyor sistem HARQ ile çalışmaya devam edecek
işlevler engellendi (yani, arabellekler dolduruldu ancak kullanılmadı). Bu uygulama
karakteristik, HARQ'dan önce uygulanan zamanlayıcılarla geriye dönük uyumluluk sağlar
entegrasyon.
[image] HARQ ve LTE protokol yığını arasındaki etkileşim.UNINDENT

MAC
Kaynak Tahsis Model
Şimdi LTE'de kaynak tahsisinin nasıl ele alındığını kısaca açıklayarak, bunun nasıl olduğunu açıklıyoruz.
simülatörde modellenmiştir. Zamanlayıcı, belirli yapıları oluşturmaktan sorumludur.
denilen Veri Control işaret (DCI) daha sonra eNB'nin PHY'si tarafından iletilir.
alt çerçeve başına kaynak tahsisi hakkında onları bilgilendirmek için bağlı UE'ler
temel. Bunu uydu-yer bağı yönünde yaparken, programlayıcının bazı özel bilgileri doldurması gerekir.
Modülasyon ve Kodlama gibi tüm bilgileri içeren DCI yapısının alanları
Kullanılacak Şema (MCS), MAC Aktarım Bloğu (TB) boyutu ve ayırma bit eşlemi
hangi RB'lerin eNB tarafından her kullanıcıya iletilen verileri içereceğini tanımlar.

Kaynakların fiziksel RB'lere eşlenmesi için bir lokalize haritalama yaklaşma (bkz.
[Sesia2009], Bölüm 9.2.2.1); bu nedenle belirli bir alt çerçevede her RB her zaman
her iki yuvada da aynı kullanıcı. Tahsis bit eşlemi farklı biçimlerde kodlanabilir; içinde
bu uygulamayı değerlendirdik Tahsis Menşei 0 göre [TS36213]'te tanımlanan
RB'lerin belirlenen farklı büyüklükteki Kaynak Blok Gruplarında (RBG) gruplandırıldığı
kullanımdaki İletim Bant Genişliği Yapılandırmasının bir işlevi olarak.

Belirli bant genişliği değerleri için, grup boyutu bir olmadığı için tüm RB'ler kullanılamaz.
grubun ortak böleni. Bu, örneğin bant genişliğinin eşit olduğu durumdur.
25 RB'lik bir RBG boyutuyla sonuçlanan 2 RB ve dolayısıyla 1 RB sonuçlanmaz
adreslenebilir. Yukarı bağlantıda DCI'lerin formatı farklıdır, çünkü sadece bitişik RB'ler
SC-FDMA modülasyonu nedeniyle kullanılabilir. Sonuç olarak, tüm RB'ler şu şekilde tahsis edilebilir:
bant genişliği yapılandırmasından bağımsız olarak eNB.

Adaptif Modülasyon ve kodlama
Simülatör, iki Uyarlamalı Modülasyon ve Kodlama (AMC) modeli sağlar: biri
GSoC modeli [Piro2011] ve bir tanesi fiziksel hata modeline dayalıdır (
aşağıdaki bölümler).

Önceki model, [Piro2011]'de açıklanan modelin değiştirilmiş bir versiyonudur.
[Seo2004]'den esinlenilmiştir. Versiyonumuz aşağıda açıklanmıştır. belirteyim
genel kullanıcı ve mma_i'nin SINR olmasına izin verin. i kullanıcısının spektral verimini \ta_i alıyoruz
aşağıdaki denklemleri kullanarak:

[R1-081483]'te açıklanan prosedür, karşılık gelen MCS şemasını almak için kullanılır. bu
spektral verimlilik, kanal kalite göstergesine (CQI) dayalı olarak nicelenir, yuvarlanır
en düşük değerdir ve ilgili MCS şemasına eşlenir.

Son olarak, [R1-081483] içindeki MCS indeksi arasında bazı tutarsızlıklar olduğunu not ediyoruz.
ve standart tarafından belirtilen: [TS36213] Tablo 7.1.7.1-1, MCS indeksinin
0'dan 31'e gider ve 0 geçerli bir MCS şeması gibi görünür (TB boyutu 0 değildir), ancak
[R1-081483] ilk faydalı MCS indeksi 1'dir.
standart [R1-1]'de rapor edilen indeksten 081483 çıkarmamız gerekiyor.

Alternatif model, bu simülatör için geliştirilen fiziksel hata modeline dayanmaktadır.
ve aşağıdaki alt bölümlerde açıklanmıştır. Bu şema MCS seçimini uyarlayabilir
belirli CQI raporuna göre gerçek PHY katman performansına. Göre
tanımları, modülasyonlu tek bir PDSCH TB olduğunda bir CQI indeksi atanır.
[TS7.2.3] tablo 1-36213'deki CQI indeksine karşılık gelen kodlama şeması ve kod hızı
0.1'den daha düşük bir hata olasılığı ile alınabilir. Geniş bant CQI'ler durumunda,
referans TB, aşağıdakilere dayalı bir referansa sahip olmak için mevcut tüm RBG'leri içerir.
tüm mevcut kaynaklar; alt bant CQI'leri için referans TB, RBG'ler olarak boyutlandırılır.

Transfer Engellemek model
Simülatör tarafından sağlanan MAC Taşıma Bloklarının (TB'ler) modeli şu şekilde basitleştirilmiştir:
3GPP spesifikasyonlarına göre. Özellikle, simülatöre özgü bir sınıf
(PacketBurst), simülatörün eşdeğerini elde etmek için MAC SDU'ları toplamak için kullanılır.
karşılık gelen uygulama karmaşıklığı olmadan bir TB'nin. çoğullanması
RLC katmanına giden ve giden farklı mantıksal kanallar özel bir paket kullanılarak gerçekleştirilir
kısmen eşdeğer olan bir işlevsellik gerçekleştiren etiketi (LteRadioBearerTag)
3GPP tarafından belirtilen MAC başlıklarınınki.

The FemtoForum MAC Zamanlayıcı arayüzey
Bu bölüm, LTE MAC Zamanlayıcı Arayüzünün ns-3'e özel sürümünü açıklar
FemtoForum [FFAPI] tarafından yayınlanan spesifikasyon.

FemtoForum MAC Zamanlayıcı Arayüzünün [FFAPI] ns-3'e özel sürümünü uyguladık
bir dizi C++ soyut sınıf olarak; özellikle, her ilkel bir C++'a çevrilir
Belirli bir sınıfın yöntemi. Dönem uygulanan burada benimsenen aynı anlamla kullanılır
[FFAPI] içinde ve dolayısıyla mantıksal arabirimi çevirme sürecini ifade eder
belirli bir programlama dilinin belirtimi. [FFAPI] içindeki ilkeller gruplandırılmıştır
iki grupta: zamanlayıcı yapılandırmasıyla ilgilenen CSCHED ilkelleri ve
Zamanlayıcının yürütülmesiyle ilgilenen SCHED ilkelleri. Ayrıca, [FFAPI]
iki farklı türden ilkelleri tanımlar: REQ türündekiler MAC'den
Zamanlayıcı ve IND/CNF türündekiler, zamanlayıcıdan MAC'a gider. Bunları çevirmek için
özelliklerini C++'a dönüştürmek için Service'i uygulayan aşağıdaki soyut sınıfları tanımlarız.
İlkelleri yayınlamak için kullanılacak Erişim Noktaları (SAP'ler):

· NS FfMacSchedSapSağlayıcı sınıf, SCHED'e karşılık gelen tüm C++ yöntemlerini tanımlar
REQ tipi ilkeller;

· NS FfMacSchedSapKullanıcı sınıf, SCHED'e karşılık gelen tüm C++ yöntemlerini tanımlar
CNF/IND tipi ilkeller;

· NS FfMacCschedSapSağlayıcı class, karşılık gelen tüm C++ yöntemlerini tanımlar.
REQ türünde CSCHED temel öğeleri;

· NS FfMacCschedSapKullanıcı class, CSCHED'e karşılık gelen tüm C++ yöntemlerini tanımlar.
CNF/IND tipi ilkeller;

MAC Zamanlayıcı arayüzünde yer alan 3 blok vardır: Kontrol bloğu, Alt çerçeve bloğu
ve Zamanlayıcı bloğu. Bu blokların her biri, MAC Zamanlayıcı arayüzünün bir bölümünü sağlar.
Aşağıdaki şekil, bloklar ile uygulamamızda tanımlanan SAP'ler arasındaki ilişkiyi göstermektedir.
MAC Zamanlayıcı Arayüzünün uygulanması.
[resim]

Yukarıdaki ilkelere ek olarak, aşağıdaki tasarım seçimleri yapılmıştır:

· MAC Zamanlayıcı arabirim sınıflarının tanımı, adlandırma kurallarını takip eder
arasında ns-3 Kodlama Stili. Özellikle, aşağıdakiler için CamelCase sözleşmesini takip ediyoruz:
ilkel isimler Örneğin, ilkel CSCHED_CELL_CONFIG_REQ tercüme edildi
CschedCellConfigReq içinde ns-3 kodu.

· İlkel parametreler için aynı adlandırma kuralları izlenir. olarak
ilkel parametreler sınıfların üye değişkenleridir, ayrıca bir
m_.

· Veri yapılarında vektörlerin ve listelerin kullanımıyla ilgili olarak, [FFAPI]'nin bir
hemen hemen C odaklı API. Ancak, ns-3'te C++'ın kullanıldığı ve bunun
C dizilerinin kullanımı önerilmez, STL vektörlerini kullandık (standart::vektör) için
olarak C dizilerini kullanmak yerine MAC Zamanlayıcı Arayüzünün uygulanması
[FFAPI]'nin yazıldığı şekilde dolaylı olarak önerilmiştir.

· C++'da kurucu ve yıkıcılara sahip üyelerin içeri girmesine izin verilmez. sendikalar. Bu nedenle tüm
olduğu söylenen veri yapıları sendikalar [FFAPI]'de şu şekilde tanımlanmıştır:
yapılar bizim kodumuzda.

Aşağıdaki şekil, MAC Zamanlayıcı Arayüzünün eNB içinde nasıl kullanıldığını gösterir.
[resim]

Hem CSCHED SAP hem de SCHED SAP'nin Kullanıcı tarafı, eNB MAC içinde uygulanır,
yani dosyada lte-enb-mac.cc. eNB MAC, farklı zamanlayıcılarla kullanılabilir
değişiklik yapılmadan uygulanması. Aynı şekil aynı zamanda örnek olarak
Round Robin Zamanlayıcı uygulandı: eNB'nin MAC'si Round Robin ile etkileşim kurmak için
programlayıcı, SCHED SAP ve CSCHED SAP arayüzlerinin Sağlayıcı tarafını uygular. A
benzer bir yaklaşım, diğer zamanlayıcıları uygulamak için de kullanılabilir. Her birinin açıklaması
LTE simülasyon modülümüzün bir parçası olarak sağladığımız zamanlayıcı uygulamalarının
aşağıdaki alt bölümlerde verilmiştir.

yuvarlak narbülbülü (RR) Zamanlayıcı
Round Robin (RR) zamanlayıcı muhtemelen literatürde bulunan en basit planlayıcıdır.
Mevcut kaynakları aktif akışlar, yani mantıksal akışlar arasında bölerek çalışır.
boş olmayan bir RLC kuyruğuna sahip kanallar. RBG'lerin sayısı belirtilenden büyükse
aktif akış sayısı, tüm akışlar aynı alt çerçevede tahsis edilebilir. Aksi takdirde, eğer
aktif akışların sayısı, RBG'lerin sayısından fazladır, tüm akışlar
belirli bir alt çerçevede planlanmış; daha sonra, bir sonraki alt çerçevede tahsisat başlar
tahsis edilmeyen son akış. Her kullanıcı için benimsenecek MCS yapılır
alınan geniş bant CQI'lere göre.

HARQ ile ilgili olarak, RR uyarlanabilir olmayan sürümü uygular, bu da şu anlama gelir:
yeniden iletim denemelerini tahsis etmek için RR, aynı tahsis konfigürasyonunu kullanır.
orijinal blok, bu aynı RBG'leri ve MCS'yi korumak anlamına gelir. için ayrılan UE'ler
HARQ yeniden iletimleri, yeni verilerin iletimi için dikkate alınmaz.
aynı TTI'da mevcut bir iletim fırsatı. Son olarak, HARQ ile devre dışı bırakılabilir
Eski test senaryoları ve kod ile geriye dönük uyumluluğu korumak için ns3 nitelik sistemi,
detayda:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (yanlış));

Programlayıcı, yer-uydu bağı CQI'lerinin filtrelenmesini, doğasına göre aşağıdakilerle uygular:
UlCqiFiltre nitelik, ayrıntılı olarak:

· SRS_UL_CQI: dahili özniteliklerde yalnızca SRS tabanlı CQI depolanır.

· PUSCH_UL_CQI: dahili özniteliklerde yalnızca PUSCH tabanlı CQI depolanır.

· ALL_UL_CQI: tüm CQI'ler aynı dahili öznitelikte saklanır (yani, son CQI
alınan, doğasından bağımsız olarak saklanır).

Orantılı Zayıf (KF) Zamanlayıcı
Orantılı Fuar (PF) planlayıcısı [Sesia2009], bir kullanıcıyı
anlık kanal kalitesi, kendi ortalama kanal durumuna göre yüksektir.
zaman. i,j genel kullanıcıları göstersin; t alt çerçeve indeksi ve k kaynak olsun
blok indeksi; M_{i,k}(t) neye göre k kaynak bloğunda i kullanıcısı tarafından MCS kullanılabilir olsun
AMC modeli tarafından rapor edilmiştir (bkz. Adaptif Modülasyon ve kodlama); son olarak, S(M, B) olsun
B sayısının bir kaynak olduğu durum için [TS36213]'te tanımlandığı gibi bit cinsinden TB boyutu
bloklar kullanılır. Kaynak blok grubundaki i kullanıcısı için bit/s cinsinden ulaşılabilir R_{i}(k,t) oranı
t alt çerçevesindeki k, şu şekilde tanımlanır

au, TTI süresidir. Her t alt çerçevesinin başlangıcında, her RBG bir
belirli kullanıcı Ayrıntılı olarak, t zamanında RBG k'nin atandığı 144}_{k}(t) indeksi
olarak belirlenir

burada T_{j}(t), j kullanıcısı tarafından algılanan geçmiş çıktı performansıdır. Göre
yukarıdaki zamanlama algoritması, bir kullanıcı farklı RBG'lere atanabilir,
kanalın mevcut durumuna ve geçmişe bağlı olarak bitişik veya değil
çıktı performansı T_{j}(t). İkincisi, t alt çerçevesinin sonunda belirlenir.
aşağıdaki üstel hareketli ortalama yaklaşımını kullanarak:

burada lpha, üstel hareketin zaman sabitidir (alt çerçeve sayısı olarak).
ortalama ve 384s alt çerçevede i kullanıcısı tarafından elde edilen gerçek verim. 360
aşağıdaki prosedüre göre ölçülür. İlk önce MCS 840 j'yi belirliyoruz:

sonra toplam 936 j sayısını belirleriz:

nerede |

HARQ ile ilgili olarak, PF uyarlanabilir olmayan sürümü uygular, bu da şu anlama gelir:
yeniden iletim denemelerini tahsis etmek, zamanlayıcı aynı tahsisi kullanır
aynı RBG'leri ve MCS'yi korumak anlamına gelen orijinal bloğun konfigürasyonu. UE'ler
HARQ yeniden iletimleri için tahsis edilenler, yeni iletimler için dikkate alınmaz.
aynı TTI'da mevcut bir iletim fırsatına sahip olmaları durumunda veriler. Son olarak, HARQ
eski ile geriye dönük uyumluluğu korumak için ns3 öznitelik sistemi ile devre dışı bırakılabilir
ayrıntılı olarak test durumları ve kodu:

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (yanlış));

Maksimum çıktı (MT) Zamanlayıcı
Maksimum Verim (MT) planlayıcısı [FCapo2012] genel verimi en üst düzeye çıkarmayı amaçlar
eNB'nin. Her bir RB'yi, kullanıcıya maksimum ulaşılabilir oranı elde edebilecek şekilde tahsis eder.
Mevcut TTI. Şu anda, NS-3'teki MT zamanlayıcısının iki sürümü vardır: frekans alanı
(FDMT) ve zaman alanı (TDMT). FDMT'de her TTI, MAC zamanlayıcısı RBG'leri UE'ye tahsis eder
alt bant CQI tarafından hesaplanan en yüksek ulaşılabilir orana sahip olan. TDMT'de her TTI, MAC
programlayıcı, geniş bant CQI tarafından hesaplanan ulaşılabilir en yüksek orana sahip bir UE seçer.
Daha sonra MAC programlayıcı tüm RBG'leri mevcut TTI'da bu UE'ye tahsis eder. hesaplanması
FDMT ve TDMT'deki ulaşılabilir oran, PF'deki ile aynıdır. i,j jenerik göstersin
kullanıcılar; t alt çerçeve indeksi ve k kaynak blok indeksi olsun; M_{i,k}(t) olsun
AMC modeli tarafından bildirilenlere göre k kaynak bloğunda i kullanıcısı tarafından kullanılabilen MCS (bkz.
Adaptif Modülasyon ve kodlama); son olarak, S(M, B) 'de tanımlandığı gibi bit cinsinden TB boyutu olsun.
[TS36213] B sayısı kaynak bloğunun kullanıldığı durum için. ulaşılabilir oran
t alt çerçevesindeki k kaynak bloğundaki i kullanıcısı için bit/s cinsinden R_{i}(k,t) şu şekilde tanımlanır:

au, TTI süresidir. Her t alt çerçevesinin başlangıcında, her RB bir
belirli kullanıcı Ayrıntılı olarak, t zamanında RB k'nin atandığı 144}_{k}(t) indeksi
olarak belirlenir

Aynı ulaşılabilir orana sahip birkaç UE olduğunda, mevcut uygulama her zaman
komut dosyasında oluşturulan ilk UE'yi seçer. MT, hücre verimini maksimize edebilmesine rağmen,
kötü kanal durumundaki UE'lere adalet sağlayamaz.

çıktı için Ortalama (TTA) Zamanlayıcı
Ortalama Verimlilik (TTA) planlayıcısı [FCapo2012] bir ara ürün olarak kabul edilebilir.
MT ve PF arasında. TTA'da kullanılan metrik şu şekilde hesaplanır:

Burada, bit/s cinsinden R_{i}(k,t), k kaynak bloğundaki i kullanıcısı için ulaşılabilir hızı temsil eder.
alt çerçeve Hesaplama yöntemi MT ve PF'de zaten gösterilmiştir. Bu arada, R_{i}(t)
bit/s, t alt çerçevesinde i için ulaşılabilir oranı temsil eder. Bu ikisi arasındaki fark
Ulaşılabilir oranlar, MCS'nin nasıl elde edileceğidir. R_{i}(k,t) için MCS, alt bant CQI tarafından hesaplanırken
R_{i}(t), geniş bant CQI ile hesaplanır. TTA zamanlayıcı yalnızca sıklıkta uygulanabilir
etki alanı (FD) çünkü belirli RBG'nin ulaşılabilir oranı yalnızca FD ile ilgilidir
zamanlama.

Kör Ortalama çıktı Zamanlayıcı
Kör Ortalama Verimlilik planlayıcısı [FCapo2012], herkese eşit verim sağlamayı amaçlamaktadır.
eNB altındaki UE'ler. TTA'da kullanılan metrik şu şekilde hesaplanır:

burada T_{j}(t), j kullanıcısı tarafından algılanan geçmiş çıktı performansıdır ve şu şekilde olabilir:
PF zamanlayıcıda aynı yöntemle hesaplanır. Zaman alanında kör ortalama verim
(TD-BET), programlayıcı en büyük öncelik metriğine sahip UE'yi seçer ve tüm RBG'leri tahsis eder.
bu UE'ye. Öte yandan, frekans alanında kör ortalama verim (FD-BET),
her TTI'da, programlayıcı ilk önce en düşük pastAverageThroughput'a (en büyük
öncelik metriği). Daha sonra programlayıcı bu UE'ye bir RBG atar, bekleneni hesaplar
bu UE'nin verimi ve bunu geçmiş ortalama verim T_{j}(t) ile karşılaştırmak için kullanır.
diğer UE'ler. Zamanlayıcı, beklenene kadar RBG'yi bu UE'ye tahsis etmeye devam eder.
verim, tüm UE'lerin geçmiş ortalama verimi T_{j}(t) arasında en küçük olanı değildir. O zamanlar
zamanlayıcı, en düşük geçmişe sahip yeni bir UE için RBG'yi tahsis etmek için aynı yolu kullanacaktır.
tüm RBG'ler UE'lere tahsis edilene kadar ortalama verim T_{j}(t). Bunun arkasındaki ilke
şudur ki, her TTI'da zamanlayıcı, aralarında eşit verim elde etmek için en iyi şekilde çalışır.
tüm UE'ler.

Simge Banka Zayıf Kuyruk Zamanlayıcı
Token Bank Fair Queue (TBFQ), sızdıran kovadan türetilen QoS farkında bir zamanlayıcıdır.
mekanizma. TBFQ'da, i kullanıcısının trafik akışı aşağıdaki parametrelerle karakterize edilir:

· t_{i}: paket varış hızı (bayt/sn)

· r_{i}: belirteç oluşturma hızı (bayt/sn)

· p_{i}: belirteç havuzu boyutu (bayt)

· E_{i}: Jetondan ödünç alınan veya jetona verilen jeton sayısını kaydeden sayaç
akışa göre sıra i ; E_{i} sıfırdan küçük olabilir

Her K bayt verisi, k jeton tüketir. Ayrıca, TBFQ, paylaşılan bir belirteç bankası (B) tutar.
Farklı akışlar arasındaki trafiği dengeler. Belirteç oluşturma oranı r_{i} şundan büyükse:
paket varış oranı t_{i}, ardından jeton havuzundan taşan jetonlar jetona eklenir
banka ve E_{i} aynı miktarda artırılır. Aksi takdirde, akışı geri çekmem gerekiyor
öncelik metriği frac{E_{i}}{r_{i}} ve E_{i} temel alınarak belirteç bankasından belirteçler
azaldı. Açıkçası, kullanıcı token bankasına daha fazla katkıda bulunur, daha yüksek önceliğe sahiptir.
jeton ödünç almak; Öte yandan, kullanıcı bankadan daha fazla token ödünç alır ve daha düşük
jetonları çekmeye devam etme önceliği. Bu nedenle, birden fazla kullanıcının sahip olması durumunda
aynı belirteç oluşturma hızı, trafik hızı ve belirteç havuzu boyutu, kullanıcı daha yüksek sorunlardan muzdariptir
müdahalenin bankadan jeton ödünç almak için daha fazla fırsatı vardır. Ayrıca, TBFQ polis
verimi sınırlamak için belirteç oluşturma oranını ayarlayarak trafiği. Bunlara ek olarak,
TBFQ ayrıca her akış için aşağıdaki üç parametreyi korur:

· Borç limiti d_{i}: E_{i} bu eşiğin altına düşerse, kullanıcı i daha fazla jeton ödünç alamam
bankadan. Bu, kötü niyetli UE'nin çok fazla jeton ödünç almasını önlemek içindir.

· Kredi limiti c_{i}: tek seferde bankadan ödünç alabileceğim maksimum token UE sayısı
Zaman.

· Kredi eşiği C: E_{i} borç limitine ulaştığında, UE bankada C jetonlarını saklamalıyım
bankadan daha fazla jeton ödünç almak için.

NS-3'teki LTE, iki TBFQ planlayıcı sürümüne sahiptir: frekans alanı TBFQ (FD-TBFQ) ve zaman
etki alanı TBFQ (TD-TBFQ). FD-TBFQ'da, programlayıcı her zaman en yüksek metrik ve
UE'nin RLC arabelleğinde paket kalmayana kadar RBG'yi en yüksek alt bant CQI ile tahsis eder
veya tüm RBG'ler tahsis edilir [FABokhari2009]. TD-TBFQ'da, maksimum ile UE seçildikten sonra
metrik, geniş bant CQI [WKWong2004] kullanarak tüm RBG'leri bu UE'ye tahsis eder.

öncelik set Zamanlayıcı
Öncelik kümesi planlayıcısı (PSS), zaman alanını (TD) ve
frekans alanı (FD) paket programlama işlemlerini tek bir programlayıcıda [GMonghal2008]. BT
belirli bir Hedef Bit Hızı (TBR) ile UE'ler arasındaki adaleti kontrol eder.

TD zamanlayıcı bölümünde, PSS önce boş olmayan RLC arabelleğine sahip UE'leri seçer ve ardından bunları böler.
TBR'ye göre iki set halinde:

· set 1: Geçmiş ortalama verimi TBR'den küçük olan UE; TD zamanlayıcı hesaplar
Kör Eşit Verimlilik (BET) stilindeki öncelik metrikleri:

· küme 2: geçmiş ortalama verimi TBR'den daha büyük (veya eşit) olan UE; TD zamanlayıcı
öncelik metriğini Orantılı Fuar (PF) stilinde hesaplar:

1. sete ait UE'ler 2. settekilerden daha yüksek önceliğe sahiptir. Ardından PSS seçim yapacaktır.
İki kümede en yüksek metriğe sahip N_{mux} UE'ler ve bu UE'leri FD planlayıcıya iletir. PSS'de,
FD planlayıcı, RBG k'yi, seçilen metriği maksimum yapan UE n'ye tahsis eder. İki PF zamanlayıcı
PF zamanlayıcıda kullanılır:

· Orantılı Fuar planlı (PFsch)

· Ortalamaya Girişim Üzerinden Taşıyıcı (CoIta)

burada Tsch_{j}(t), j kullanıcısı tarafından algılanan benzer geçmiş çıktı performansıdır.
fark, yalnızca i-th kullanıcısına gerçekten hizmet verildiğinde güncellenmesidir. CoI[j,k] bir
UE j'nin RBG k üzerindeki SINR tahmini. Hem PFsch hem de CoIta, FD'yi ayırmak içindir
TD zamanlayıcıdan metrik. Ek olarak, PSS FD planlayıcı ayrıca bir ağırlık metriği W[n] sağlar
düşük sayıda UE olması durumunda adaleti kontrol etmeye yardımcı olmak için.

burada T_{j}(t), j kullanıcısı tarafından algılanan geçmiş çıktı performansıdır. Bu nedenle, üzerinde
RBG k, FD programlayıcı, frekansın çarpımını maksimize eden UE j'yi seçer
alan metriği (Msch, MCoI) ağırlık W[n]. Bu strateji, iş hacmini garanti edecek
düşük kaliteli UE, TBR'ye yönelir.

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (yanlış));

Programlayıcı, yer-uydu bağı CQI'lerinin filtrelenmesini, doğasına göre aşağıdakilerle uygular:
UlCqiFiltre nitelik, ayrıntılı olarak:

· SRS_UL_CQI: dahili özniteliklerde yalnızca SRS tabanlı CQI depolanır.

· PUSCH_UL_CQI: dahili özniteliklerde yalnızca PUSCH tabanlı CQI depolanır.

· ALL_UL_CQI: tüm CQI'ler aynı dahili öznitelikte saklanır (yani, son CQI
alınan, doğasından bağımsız olarak saklanır).

Telegram Kanal ve QoS Farkında Zamanlayıcı
Kanal ve QoS Aware (CQA) Zamanlayıcı [Bbojovic2014], bir LTE MAC aşağı bağlantı programlamasıdır
hat başı (HOL) gecikmesini, GBR parametrelerini ve kanalı dikkate alan algoritma
farklı alt bantlarda kalite. CQA planlayıcısı, ortak TD ve FD planlamasını temel alır.

TD'de (her TTI'da) CQA planlayıcı, kullanıcıları önceliğe göre gruplandırır. Amacı
gruplama, ilk önce en yüksek HOL'ye sahip akışları dikkate almak için FD zamanlamasını uygulamaktır.
gecikme. j=1,...,N kullanıcısı için gruplandırma metriği m_{td} şu şekilde tanımlanır:

burada d_{hol}^{j}(t) j akışının HOL gecikmesinin mevcut değeridir ve g bir gruplandırmadır
grupların ayrıntı düzeyini belirleyen parametre, yani
FD çizelgeleme yinelemesinde dikkate alınacaktır.

TD yinelemesinde seçilen akış grupları, FD zamanlamasına iletilir
m_{td} metriğinin en yüksek değerine sahip akışlardan başlayarak tüm RBG'ler
ilgili TTI'da atanır. FD'de, her RBG k=1,...,K için CQA planlayıcısı
mevcut RBG'yi, kullandığımız FD metriğinin maksimum değerine sahip olan j kullanıcısına atar.
aşağıdaki şekilde tanımlayın:

burada m_{GBR}^j(t) aşağıdaki gibi hesaplanır:

burada GBR^j, j akışının EPS taşıyıcısında belirtilen bit hızıdır, rie R j ( ) sps havalandırılmış iş hacmidir.
hareketli bir ortalama ile hesaplanır, r^{j}(t), t zamanında elde edilen çıktıdır,
ve lpha öyle bir katsayıdır ki 0 lpha ..sp m_{ca}^{(k,j)}(t) için iki
farklı metrikler: m_{pf}^{(k,j)}(t) ve m_{ff}^{(k,j)}(t). m_{pf} Orantılı
Aşağıdaki şekilde tanımlanan adil metrik:

burada R_e^{(k,j)}(t), RBG k üzerinden j kullanıcısının tahmini ulaşılabilir verimidir
kanalı eşleyen Uyarlamalı Modülasyon ve Kodlama (AMC) şemasıyla hesaplanır
bit cinsinden taşıma bloğu boyutuna kalite göstergesi (CQI) değeri.

Düşündüğümüz diğer kanal bilinirliği metriği, şu bölümde önerilen m_{ff}'dir.
[GMonghal2008] ve kullanıcı için RBG k üzerinden frekans seçici sönümleme kazançlarını temsil eder
j ve aşağıdaki şekilde hesaplanır:

burada CQI^{(k,j)}(t), k-th RBG için j kullanıcısından en son bildirilen CQI değeridir.

Kullanıcı, özniteliği ayarlayarak m_{pf} veya m_{ff} kullanılıp kullanılmayacağını seçebilir.
ns3::CqaFfMacScheduler::CqaMetric sırasıyla "CqaPf" or "CqaFf".

Rasgele giriş
LTE modeli, bazı basitleştirmelere dayanan Rastgele Erişim prosedürünün bir modelini içerir.
mesajların ve sinyallerin her biri için aşağıda ayrıntıları verilen varsayımlar
teknik özelliklerde [TS36321] açıklanmıştır.

· Rasgele giriş (KURBAĞA) önsöz: gerçek LTE sistemlerinde bu bir Zadoff-Chu'ya karşılık gelir
Mevcut ve PRACH yuvalarında gönderilen çeşitli formatlardan birini kullanan (ZC) dizisi
hangi prensipte PUSCH ile örtüşebilir. PRACH Yapılandırma Dizini 14:
varsayılır, yani başlangıçlar herhangi bir sistem çerçeve numarasına ve alt çerçeve numarasına gönderilebilir.
RA önsözü, LteControlMessage sınıfı kullanılarak, yani ideal olarak modellenmiştir.
herhangi bir radyo kaynağı tüketmeyen mesaj. Önsözün çarpışması
aynı hücrede birden fazla UE tarafından iletim, bir protokol kullanılarak modellenir
girişim modeli, yani iki veya daha fazla özdeş giriş
aynı TTI'da aynı hücre, bu özdeş girişlerden hiçbiri tarafından alınmayacaktır.
eNB. Bu çarpışma modeli dışında hiçbir hata modeli ile ilişkilendirilmemiştir.
bir RA önsözünün alınması.

· Rasgele giriş yanıt (RAR): gerçek LTE sistemlerinde bu, gönderilen özel bir MAC PDU'dur.
DL-SCH. MAC kontrol elemanları simülatörde doğru bir şekilde modellenmediğinden
(yalnızca RLC ve üzeri PDU'lar vardır), RAR bir LteControlMessage olarak modellenmiştir.
herhangi bir radyo kaynağı tüketmeyin. Yine de, RA prosedürü sırasında LteEnbMac
FF MAC kullanarak RAR için kaynakların tahsisini planlayıcıdan talep etme
Zamanlayıcı ilkel SCHED_DL_RACH_INFO_REQ. Bu nedenle, gelişmiş bir zamanlayıcı
uygulama (şu anda mevcut değil) için radyo kaynakları tahsis edebilir
RAR, böylece, radyo kaynaklarının iletimi için Telsiz Kaynaklarının tüketimini modellemektedir.
rar.

· Mesaj 3: gerçek LTE sistemlerinde, bu, belirtilen kaynaklar üzerinden gönderilen bir RLC TM SDU'dur
RAR'daki UL Grant'te. Simülatörde bu, gerçek bir RLC TM RLC olarak modellenmiştir.
UL kaynakları, çağrı üzerine planlayıcı tarafından tahsis edilen PDU
SCHED_DL_RACH_INFO_REQ.

· çekişme çözüm (CR): gerçek LTE sisteminde, CR aşamasına hitap etmek için gereklidir.
iki veya daha fazla UE'nin aynı TTI içinde aynı RA girişini gönderdiği ve eNB'nin
çarpışmaya rağmen bu önsözü saptayabilir. Bu olay olmadığı için
RA girişlerinin alınması için kullanılan protokol girişim modeli nedeniyle oluşur,
CR aşaması simülatörde modellenmemiştir, yani CR MAC CE hiçbir zaman simülatör tarafından gönderilmez.
eNB ve UE'ler, RAR'ın alınması üzerine RA'nın başarılı olduğunu düşünür. Olarak
sonuç olarak, CR MAC CE'nin iletimi için tüketilen radyo kaynakları,
modellenmemiş.

şekil Dizi diyagram of the çekişme temelli MAC Rasgele giriş prosedür ve Dizi
diyagram of the Tartışmaya dayalı olmayan MAC Rasgele giriş prosedür sırayı gösterir
sırasıyla çekişme tabanlı ve çekişme tabanlı olmayan MAC rasgele erişim diyagramları
MAC ve diğer varlıklar arasındaki etkileşimleri vurgulayan prosedür.
[image] Çekişme tabanlı MAC Rastgele Erişim prosedürünün sıra diyagramı.UNINDENT
[görüntü] Çekişmeye dayalı olmayan MAC Rastgele Erişiminin sıra diyagramı
prosedür.UNINDENT

RLC
Genel Bakış
RLC varlığı, 3GPP teknik spesifikasyonunda [TS36322] belirtilir ve şunları içerir:
üç farklı RLC türü: Şeffaf Mod (TM), Onaysız Mod (UM) ve
Onaylanan Mod (AM). Simülatör, bu varlıkların her biri için bir model içerir

RLC varlıkları, üst PDCP katmanına ve MAC'a RLC hizmet arayüzünü sağlar.
alt MAC katmanına hizmet arayüzü. RLC varlıkları PDCP hizmet arayüzünü kullanır
üst PDCP katmanından ve alt MAC katmanından MAC hizmet arayüzünden.

şekil Uygulama Model of PDCP, RLC ve MAC kişiler ve SAP'ler gösterir
RLC varlıklarının uygulama modeli ve diğer tüm varlıklarla ilişkisi
ve protokol yığınındaki hizmetler.
[image] PDCP, RLC ve MAC varlıklarının ve SAPs.UNINDENT'in Uygulama Modeli

Hizmet Arayüzler
RLC Hizmet arayüzey
RLC hizmet arabirimi iki bölüme ayrılmıştır:

· NS RlcSapSağlayıcı kısım RLC katmanı tarafından sağlanır ve üst PDCP katmanı tarafından kullanılır
ve

· NS RlcSapKullanıcı kısmı üst PDCP katmanı tarafından sağlanır ve RLC katmanı tarafından kullanılır.

Hem UM hem de AM RLC varlıkları, aynı RLC hizmet arabirimini üst kısma sağlar.
PDCP katmanı.

RLC Hizmet Primitives
Aşağıdaki liste, RLC hizmeti tarafından hangi hizmet temel öğelerinin sağlandığını belirtir.
arayüzler:

· RlcSapProvider::TransmitPdcpPdu

· PDCP varlığı, alt RLC varlığına bir PDCP PDU göndermek için bu ilkel öğeyi kullanır.
verici eşinde

· RlcSapUser::ReceivePdcpPdu

· RLC varlığı, üst PDCP varlığına bir PDCP PDU göndermek için bu ilkel öğeyi kullanır.
alıcı akranda

MAC Hizmet arayüzey
MAC servis arayüzü iki bölüme ayrılmıştır:

· NS MacSapSağlayıcı kısmı MAC katmanı tarafından sağlanır ve üst RLC katmanı tarafından kullanılır
ve

· NS MacSapKullanıcı kısmı üst RLC katmanı tarafından sağlanır ve MAC katmanı tarafından kullanılır.

MAC Hizmet Primitives
Aşağıdaki liste, MAC hizmeti tarafından hangi hizmet ilkelerinin sağlandığını belirtir.
arayüzler:

· MacSapProvider::TransmitPdu

· RLC varlığı, aşağıdaki MAC varlığına bir RLC PDU göndermek için bu ilkel öğeyi kullanır.
verici eş

· MacSapProvider::ReportBufferStatus

· RLC varlığı, MAC varlığına bekleyen dosya boyutunu bildirmek için bu ilkel öğeyi kullanır.
verici eşindeki arabellekler

· MacSapUser::NotifyTxOpportunity

· MAC varlığı, RLC varlığına bir iletimi bildirmek için bu ilkel öğeyi kullanır.
fırsat

· MacSapUser::ReceivePdu

· MAC varlığı, üst RLC varlığına bir RLC PDU göndermek için bu ilkel öğeyi kullanır.
alıcı akranda

AM RLC
Onay Modu (AM) RLC varlığında veri aktarımının işlenmesi açıklanmıştır
[TS5.1.3] bölüm 36322'te. Bu bölümde, bazı ayrıntıları açıklıyoruz
RLC varlığının uygulanması.

tamponlar için the iletmek operasyonlar
AM RLC varlığı uygulamamız, aktarım işlemleri için 3 arabellek tutar:

· transmisyon Tampon: RLC SDU kuyruğudur. AM RLC varlığı bir SDU aldığında
Üst PDCP varlığından ilkel TransmitPdcpPdu hizmetinde, onu sıraya koyar
İletim Tamponunda. RLC arabellek boyutuna bir sınır koyduk ve sessizce
arabellek dolduğunda SDU'ları bırakın.

· İletilen PDUlar Tampon: kendisi için bir iletilen RLC PDU'ların sırasıdır.
ACK/NACK henüz alınmadı. AM RLC varlığı MAC'a bir PDU gönderdiğinde
varlık, ayrıca iletilen PDU'nun bir kopyasını İletilen PDU'ların Arabelleğine koyar.

· tekrarlamak Tampon: için düşünülen RLC PDU'ların sırasıdır.
yeniden iletim (yani, NACK'lendiler). AM RLC varlığı, bu PDU'yu
Yeniden İletim Arabelleği, İletilen Tampondan bir PDU'yu yeniden ilettiğinde.

Iletmek operasyonlar in downlink
Aşağıdaki sıra şeması, farklı varlıklar (RRC,
Veri gerçekleştirmek için aşağı bağlantıdaki eNB'nin PDCP, AM RLC, MAC ve MAC zamanlayıcısı)
iletişim.

şekil Dizi diyagram of veri SUK transmisyon in downlink üst katmanların nasıl olduğunu gösterir
veri PDU'larını ve veri akışının farklı kuruluşlar/hizmetler tarafından nasıl işlendiğini
LTE protokol yığını.
[image] Aşağı bağlantıdaki veri PDU iletiminin sıra diyagramı.UNINDENT

PDCP varlığı şunları çağırır: İletim_PDCP_PDU hizmet ilkel bir veri göndermek için
PDU. AM RLC varlığı, bu hizmet ilkelini AM verilerine göre işler.
[TS5.1.3] bölüm 36322'te tanımlanan transfer prosedürleri.

Zaman İletim_PDCP_PDU hizmet ilkel çağrılır, AM RLC varlığı şunları gerçekleştirir:
aşağıdaki işlemler:

· Veri SDU'sunu İletim Arabelleğine koyun.

· Tamponların boyutunu hesaplayın (tamponların boyutunun nasıl hesaplanacağı
sonra açıklanmıştır).

· Ara Report_Buffer_Status için eNB MAC varlığının hizmet ilkesi
AM RLC varlığının arabelleklerinin boyutlarını eNB MAC varlığına bildirin. Sonra
eNB MAC varlığı, MAC zamanlayıcıdaki arabellek durumunu şu şekilde günceller:
FF MAC Zamanlayıcı API'sinin SchedDlRlcBufferReq hizmeti ilkel öğesi.

Daha sonra, MAC zamanlayıcı bazı verilerin gönderilebileceğine karar verdiğinde, MAC varlığı
bunu RLC varlığına bildirir, yani Notify_Tx_Opportunity hizmet ilkel,
daha sonra AM RLC varlığı aşağıdakileri yapar:

· Sistemdeki SDU'ları bölümlere ayırarak ve/veya birleştirerek tek bir veri PDU'su oluşturun.
İletim Tamponu.

· Veri PDU'sunu İletim Tamponundan İletilen PDU Tamponuna taşıyın.

· Durum değişkenlerini [TS5.1.3.1.1] bölüm 36322'e göre güncelleyin.

· Ara İletim_PDU Veri PDU'sunu MAC varlığına göndermek için ilkel.

tekrarlamak in downlink
Şekil dizi diyagramı Dizi diyagram of veri SUK Yeniden iletim in downlink
farklı varlıklar (AM RLC, MAC ve MAC planlayıcı) arasındaki etkileşimleri gösterir.
veri PDU'larının AM RLC varlığı tarafından yeniden iletilmesi gerektiğinde aşağı bağlantıdaki eNB.
[image] Aşağı bağlantıda veri PDU yeniden iletiminin sıra diyagramı.UNINDENT

Gönderen AM RLC varlığı, eş AM RLC varlığından STATUS PDU'ları alabilir.
DURUM PDU'ları [TS5.3.2] bölüm 36322'ye göre gönderilir ve
alım [TS5.2.1] bölüm 36322'e göre yapılır.

Bir veri PDU'ları İletilen PDU Tamponundan yeniden iletildiğinde, aynı zamanda
Yeniden İletim Tamponu.

Iletmek operasyonlar in uplink
Şekil dizi diyagramı Dizi diyagram of veri SUK transmisyon in uplink gösterileri
UE'nin farklı varlıkları (RRC, PDCP, RLC ve MAC) ve
Veri PDU'ları üst katmanlar tarafından gönderildiğinde, yukarı bağlantıda eNB (MAC ve Zamanlayıcı).
[image] Uplink.UNINDENT'te veri PDU iletiminin sıra diyagramı

Downlink'teki dizi diyagramına benzer; temel fark şu ki, bu
Report_Buffer_Status'un UE MAC'den eNB'deki MAC Zamanlayıcıya gönderilmesi durumunda
kontrol kanalını kullanarak havadan.

tekrarlamak in uplink
Şekil dizi diyagramı Dizi diyagram of veri SUK Yeniden iletim in uplink gösterileri
UE'nin farklı varlıkları (AM RLC ve MAC) ve eNB arasındaki etkileşimler
(MAC), veri PDU'larının AM RLC varlığı tarafından yeniden iletilmesi gerektiğinde yukarı bağlantıda.
[image] Yukarı bağlantıda veri PDU yeniden iletiminin sıra diyagramı.UNINDENT

Hesaplama of the tampon boyut
İletim Tamponu, RLC SDU'ları içerir. Bir RLC PDU, bir veya daha fazla SDU segmenti artı bir
RLC başlığı. Bir RLC PDU'nun RLC başlığının boyutu, SDU sayısına bağlıdır
PDU'nun içerdiği segmentler.

3GPP standardı ([TS6.1.3.1] bölüm 36321), yukarı bağlantı için,
RLC ve MAC başlıkları, bir parçası olarak rapor edilecek arabellek boyutunda dikkate alınmaz.
Tampon Durum Raporu. Aşağı bağlantı için davranış belirtilmemiştir. Hiç biri
[FFAPI] nasıl yapılacağını belirtir. RLC modelimiz, hesaplamanın
aşağı bağlantıdaki arabellek boyutu, tam olarak yukarı bağlantıdaki gibi yapılır, yani dikkate alınmaz
RLC ve MAC başlık boyutu.

Bu seçimin MAC zamanlayıcı ile birlikte çalışmayı etkilediğini not ediyoruz, çünkü
cevap Notify_Tx_Opportunity hizmet ilkel, RLC'nin bir
RLC ek yükü dahil olmak üzere MAC tarafından talep edilen boyuttan daha büyük olmayan PDU. Dolayısıyla gereksiz
(örneğin) MAC tam olarak eşit bir iletimi bildirirse parçalanma meydana gelebilir.
daha önce RLC tarafından rapor edilen arabellek boyutu. Zamanlayıcı'ya bırakıldığını varsayıyoruz
iletim boyutunun seçimi için akıllı stratejiler uygulamak
Sonunda gereksiz parçalanmanın verimsizliğinden kaçınmak için fırsat.

birbirine bağlama ve Bölünme
AM RLC varlığı, her iletim için tam olarak bir RLC PDU oluşturur ve gönderir
iletim fırsatı tarafından bildirilen boyuttan daha küçük olsa bile.
Yani örneğin, bir DURUM PDU gönderilecekse, o zaman sadece bu PDU gönderilecektir.
iletim fırsatı.

AM RLC varlığının SDU kuyruğu için segmentasyon ve birleştirme aynı
felsefesi UM RLC varlığının aynı prosedürleriyle aynıdır ancak yeni durum değişkenleri vardır
(bkz. [TS36322] bölüm 7.1) yalnızca AM RLC varlığında bulunur.

3GPP özelliklerine göre,
Yeniden İletim Tamponu.

yeniden segmentasyon
AM RLC varlığının mevcut modeli,
yeniden iletim tamponu. Bunun yerine, AM RLC varlığı, yeterince büyük bir
iletim fırsatı.

desteksiz Özellikler
Aşağıdaki [TS36322] prosedürlerini desteklemiyoruz:

· “RLC SDU'nun başarılı teslimatının bir göstergesini gönderin” (Bkz. bölüm 5.1.3.1.1)

· “Üst katmanlara maksimum yeniden aktarıma ulaşıldığını belirtin” (Bkz.
5.2.1)

· “SDU ıskarta prosedürleri” (Bkz. bölüm 5.3)

· “Yeniden kuruluş prosedürü” (Bkz. bölüm 5.4)

AM RLC varlığı için RLC SAP'nin ek temel öğelerinin hiçbirini desteklemiyoruz. İçinde
belirli:

· PDCP tarafından bildirilen hiçbir SDU iptali yok

· AM RLC varlığı tarafından PDCP varlığına başarılı / başarısız teslimat bildirimi yok

UM RLC
Bu bölümde Unacknowledge Mode (UM) RLC varlığının uygulamasını açıklıyoruz.

Iletmek operasyonlar in downlink
UM RLC'nin iletim işlemleri, daha önce AM RLC'ninkilere benzerdir.
Bölümde açıklanan Iletmek operasyonlar in downlink, şu farkla, aşağıdaki
[TS36322]'nin spesifikasyonları, yeniden iletim gerçekleştirilmez ve DURUM yok
PDU'lar.

Iletmek operasyonlar in uplink
Yukarı bağlantıdaki iletim işlemleri, ana bağlantı ile aşağı bağlantınınkine benzerdir.
Report_Buffer_Status'un UE MAC'den MAC Zamanlayıcı'ya gönderilmesi arasındaki fark
eNB, kontrol kanalını kullanarak havadan.

Hesaplama of the tampon boyut
UM RLC için arabellek boyutunun hesaplanması, aynı yaklaşım kullanılarak yapılır.
AM RLC, lütfen bölüme bakın Hesaplama of the tampon boyut karşılık gelen için
açıklama.

TM RLC
Bu bölümde Şeffaf Mod (TM) RLC varlığının uygulamasını açıklıyoruz.

Iletmek operasyonlar in downlink
Simülatörde, TM RLC üst katmanlara aynı hizmet arayüzünü sağlamaya devam eder.
AM ve UM RLC varlıkları tarafından PDCP katmanına sağlanır; pratikte bu arayüz
RLC SDU'larının iletimi için bir RRC varlığı (bir PDCP varlığı değil) tarafından kullanılır. Bu seçim
TM RLC'nin üst katmanlara sunduğu hizmetlerin motive edilmesi,
[TS36322]'ye göre, UM ve AM RLC varlıkları tarafından aşağıdakilere sağlananların bir alt kümesidir.
PDCP katmanı; bu nedenle, basitlik için aynı arayüzü yeniden kullandık.

Aşağı bağlantıdaki iletim işlemleri aşağıdaki gibi gerçekleştirilir. Ne zaman
İletim_PDCP_PDU hizmet ilkel üst katmanlar tarafından çağrılır, TM RLC
Aşağıdaki:

· SDU'yu İletim Tamponuna yerleştirin

· İletim Tamponunun boyutunu hesaplayın

· ara Report_Buffer_Status eNB MAC varlığının hizmet ilkesi

Daha sonra, MAC zamanlayıcı bazı verilerin mantıksal olarak gönderilebileceğine karar verdiğinde,
TM RLC varlığının ait olduğu kanal, MAC varlığı bunu TM RLC'ye bildirir.
arayarak varlık Notify_Tx_Opportunity hizmet ilkel. Bunun alınması üzerine
ilkel, TM RLC varlığı aşağıdakileri yapar:

· TX fırsatının boyutu, fırsatın boyutundan büyük veya ona eşitse
İletim Tamponunda hat başı SDU

· Hat başı SDU'yu İletim Tamponundan ayırın

· herhangi bir RLC başlığı olmadan tamamen bu SDU'yu içeren bir RLC PDU oluşturun

· Ara İletim_PDU RLC PDU'yu MAC varlığına göndermek için ilkel.

Iletmek operasyonlar in uplink
Yukarı bağlantıdaki iletim işlemleri, ana bağlantı ile aşağı bağlantınınkine benzerdir.
UL atamasından da bir iletim fırsatının doğabileceği fark
Açık bir Tampon Durum Raporu olmadan Rastgele Erişim prosedürünün bir parçası olarak HİBE
TM RLC varlığı tarafından verilir.

Hesaplama of the tampon boyut
[TS36322] spesifikasyonlarına göre, TM RLC, PDU'lara herhangi bir RLC başlığı eklemez
aktarılıyor. Bu nedenle, MAC katmanına bildirilen arabellek boyutu
iletim arabelleğindeki tüm paketlerin boyutunun basitçe toplanmasıyla hesaplanır, böylece
MAC'a tam arabellek boyutunu bildirmek.

SM RLC
3GPP'den sonra modellenen AM, UM ve TM uygulamalarına ek olarak
Özellikler, Doygunluk Modu (SM) olarak adlandırılan basitleştirilmiş bir RLC modeli sağlanır.
RLC. Bu RLC modeli, herhangi bir üst katmandan (PDCP gibi) PDU'ları kabul etmez; daha doğrusu
SM RLC, bildirime yanıt olarak RLC PDU'ların üretilmesiyle ilgilenir.
MAC tarafından bildirilen iletim fırsatları. Başka bir deyişle, SM RLC simüle eder
doygunluk koşulları, yani, RLC arabelleğinin her zaman dolu olduğunu varsayar ve
zamanlayıcı tarafından her bildirildiğinde yeni bir PDU oluşturun.

SM RLC, yalnızca LTE Radyo modelinin kullanıldığı basitleştirilmiş simülasyon senaryoları için kullanılır.
EPC olmadan ve dolayısıyla herhangi bir IP ağ desteği olmadan kullanılır. şunu not ediyoruz,
SM RLC gerçekçi olmayan bir trafik modeli olmasına rağmen, yine de doğru
farklı (gerçek zamanlı olmayan) QoS'ye ait çoklu akışlara sahip senaryoların simülasyonu
sınıflar, farklı zamanlayıcılar tarafından elde edilen QoS performansını test etmek için. Bu
göre iletim kaynaklarını atamak Zamanlayıcının görevi olduğundan yapılmalıdır.
belirtilen her Telsiz Taşıyıcısının özellikleri (örn. Garantili Bit Hızı)
simülasyon programı içindeki her Taşıyıcının tanımı üzerine.

Gecikme kısıtlamaları olan gerçek zamanlı QoS trafiğiyle çalışmak üzere tasarlanmış planlayıcılara gelince,
SM RLC muhtemelen uygun bir seçim değildir. Bunun nedeni, fiilin yokluğudur.
RLC SDU'lar (buffer Status Reports'un yapay üretimiyle değiştirilir)
Planlayıcıya anlamlı hat başı gecikme bilgisi sağlamak mümkündür;
genellikle gerçek zamanlı zamanlama politikalarının uygulanması için tercih edilen ölçüttür.
trafik akışı. Bu tür programlayıcıların simülasyonu ve test edilmesi için kullanılması tavsiye edilir.
bunun yerine UM veya AM RLC modelleri.

PDCP
PDCP Model Genel Bakış
PDCP varlığının belirtimi için referans belge [TS36323]'dir. Saygıyla
Bu spesifikasyona göre, simülatörde uygulanan PDCP modeli yalnızca
aşağıdaki özellikler:

· veri aktarımı (kullanıcı düzlemi veya kontrol düzlemi);

· PDCP SN'lerinin bakımı;

· SN statüsünün aktarılması (devirden sonra kullanım için);

Aşağıdaki özellikler şu anda desteklenmemektedir:

· ROHC protokolünü kullanarak IP veri akışlarının başlık sıkıştırması ve açması;

· alt katmanların yeniden kurulmasında üst katman PDU'larının sıralı teslimi;

· için alt katmanların yeniden kurulmasında alt katman SDU'larının çifte ortadan kaldırılması
RLC AM'de haritalanmış radyo taşıyıcıları;

· kullanıcı düzlemi verilerinin ve kontrol düzlemi verilerinin şifrelenmesi ve deşifre edilmesi;

· kontrol düzlemi verilerinin bütünlüğünün korunması ve bütünlüğünün doğrulanması;

· zamanlayıcı tabanlı atma;

· yinelenen atma.

PDCP Hizmet arayüzey
PDCP hizmet arayüzü iki bölüme ayrılmıştır:

· NS PdcpSapSağlayıcı kısmı PDCP katmanı tarafından sağlanır ve üst katman tarafından kullanılır
ve

· NS PdcpSapKullanıcı kısmı üst katman tarafından sağlanır ve PDCP katmanı tarafından kullanılır.

PDCP Hizmet Primitives
Aşağıdaki liste, PDCP hizmeti tarafından hangi hizmet temel öğelerinin sağlandığını belirtir.
arayüzler:

· PdcpSapSağlayıcı::TransmitPdcpSdu

· RRC varlığı, alt PDCP varlığına bir RRC PDU göndermek için bu ilkel öğeyi kullanır.
verici eşinde

· PdcpSapKullanıcı::ReceivePdcpSdu

· PDCP varlığı, üst RRC varlığına bir RRC PDU göndermek için bu ilkel öğeyi kullanır.
alıcı akranda

RRC
Özellikler
Simülatörde uygulanan RRC modeli aşağıdaki işlevleri sağlar:

· Sistem Bilgisinin oluşturulması (eNB'de) ve yorumlanması (UE'de)
özellikle Ana Bilgi Bloğu ve bu yazının yazıldığı sırada yalnızca Sistem
Bilgi Bloğu Tip 1 ve 2)

· ilk hücre seçimi

· RRC bağlantı kurma prosedürü

· Aşağıdaki kullanım durumlarını destekleyen RRC yeniden yapılandırma prosedürü: + yeniden yapılandırma
SRS konfigürasyon indeksi + PHY TX modunun (MIMO) yeniden konfigürasyonu +
UE ölçümlerinin yeniden yapılandırılması + veri radyo taşıyıcı kurulumu + devir teslimi

· RRC bağlantısının yeniden kurulması, aşağıdaki kullanım durumlarını destekler: + devir

mimari
RRC modeli aşağıdaki bileşenlere ayrılmıştır:

· RRC kuruluşları LteUeRrc ve LteEnbRrcdevlet makinelerini uygulayan
sırasıyla UE ve eNB'deki RRC varlıkları;

· RRC SAP'leri LteUeRrcSapSağlayıcı, LteUeRrcSapKullanıcı, LteEnbRrcSapSağlayıcı,
LteEnbRrcSapKullanıcıRRC varlıklarının RRC mesajları göndermesine ve almasına izin veren ve
bilgi öğeleri;

· RRC protokol sınıfları LteUeRrcProtocolİdeal, LteEnbRrcProtocolİdeal,
LteUeRrcProtocolGerçek, LteEnbRrcProtocolGerçekiçin iki farklı model uygulayan
RRC mesajlarının iletimi.

Ek olarak, RRC bileşenleri, geri kalanlarla etkileşim kurmak için çeşitli diğer SAP'leri kullanır.
protokol yığını. Kullanılan tüm SAP'lerin bir temsili,
rakamlar LTE radyo protokol yığın mimari için the UE on the veri düzlem, LTE radyo
protokol yığın mimari için the UE on the kontrol düzlem, LTE radyo protokol yığın
mimari için the eNB on the veri düzlem ve LTE radyo protokol yığın mimari için
the eNB on the kontrol düzlem.

UE RRC Eyalet makine
Şekilde UE RRC Eyalet makine RRC UE'de uygulanan durum makinesini temsil ediyoruz
varlık.
[image] UE RRC Durum Makinesi.UNINDENT

Durumların çoğunun geçici olduğu, yani UE bir kez bir duruma geçtiğinde not edilmelidir.
BAĞLANTI durumlarının hiçbirinde, hiçbir zaman BOŞ durumlarından herhangi birine geri dönmeyecektir. Bu seçim
aşağıdaki nedenlerle yapılır:

· bölümde tartışıldığı gibi Tasarım Kriterler, LTE-EPC simülasyonunun odak noktası
model CONNECTED modunda

· bölümde tartışıldığı gibi, radyo bağlantısı hatası şu anda modellenmemiştir radyo Link
Başarısızlık, bu nedenle bir UE, radyo bağlantı hatası nedeniyle BOŞTA kalamaz

· RRC bağlantı sürümü şu anda ne EPC ne de NAS tarafından hiçbir zaman tetiklenmemektedir.

Yine de, IDLE durumlarını açıkça modellemeyi seçtik, çünkü:

· Gerekli bir özellik olan devir için gerçekçi bir UE RRC konfigürasyonu gereklidir,
ve daha temiz bir uygulamaya sahip olmak için aynı UE RRC'yi kullanmak mantıklıdır
ilk bağlantı kurulumu için de yapılandırma

· gelecekte bekleme modu hücre seçiminin uygulanmasını kolaylaştırır, bu da bir
son derece arzu edilen özellik

B İÇİNDE RRC Eyalet makine
eNB RRC, hücreye bağlı her UE için durumu korur. bir
uygulama açısından, her bir UE'nin durumu,
UeManager sınıfı. Durum makinesi Şekilde temsil edilmektedir. B İÇİNDE RRC Eyalet makine için her
UE.
[image] Her UE.UNINDENT için ENB RRC Durum Makinesi

Ilk Hücre seçim
İlk hücre seçimi, henüz UE tarafından gerçekleştirilen bir BOŞ mod prosedürüdür.
kamp kurdu veya bir eNodeB'ye bağlı. Prosedürün amacı uygun bir hücre bulmaktır.
ve hücresel ağa erişmek için ona bağlayın.

Şekilde gösterildiği gibi tipik olarak simülasyonun başlangıcında yapılır. Örnek ishal of
ilk hücre seçim in UE ve zamanlama of ilgili olaylar aşağıda. üzerindeki zaman diyagramı
sol taraf, ilk hücre seçiminin ilk denemede başarılı olduğu durumu göstermektedir,
sağ taraftaki diyagram ilk denemede başarısız olduğu durum içindir ve
ikinci denemede başarılı ol. Zamanlama, gerçek RRC protokol modelinin kullanıldığını varsayar (bkz. RRC
protokol modelleri) ve iletim hatası yok.
[image] UE'de ilk hücre seçiminin örnek çalışmaları ve ilgili zamanlama
olaylar.UNINDENT

İşlevsellik, [TS3]'deki gibi 36300GPP BOŞTA modu özelliklerine dayanmaktadır.
[TS36304] ve [TS36331]. Ancak, BOŞTA modunun düzgün bir şekilde uygulanması hala eksik
simülatörde, bu nedenle birkaç basitleştirici varsayımı saklı tutuyoruz:

· çoklu taşıyıcı frekansı desteklenmez;

· birden fazla Kamu Kara Mobil Ağı (PLMN) kimliği (yani çoklu ağ
operatörler) desteklenmez;

· RSRQ ölçümleri kullanılmaz;

· saklanan bilgi hücresi seçimi desteklenmez;

· "Herhangi Bir Hücre Seçimi" durumu ve kabul edilebilir bir hücreye kamp yapmak desteklenmez;

· bir hücreyi engellenmiş veya ayrılmış olarak işaretlemek desteklenmez;

· hücre yeniden seçimi desteklenmez, dolayısıyla UE'nin bir yerde kamp yapması mümkün değildir.
ilk kamp yerleştirildikten sonra farklı hücre; ve

· UE'nin Kapalı Abone Grubu (CSG) beyaz listesi yalnızca bir CSG kimliği içerir.

Ayrıca, ilk hücre seçiminin yalnızca EPC etkin simülasyonlar için mevcut olduğunu unutmayın.
Yalnızca LTE simülasyonları, manuel bağlantı yöntemini kullanmalıdır. Bkz. bölüm
farklılıkları hakkında daha fazla bilgi için Kullanıcı Belgelerinin sec-network-ek
kullanımda.

Sonraki alt bölümler, ilk hücre seçiminin farklı kısımlarını kapsar, yani hücre arama,
yayın of sistem bilgi, ve hücre seçim değerlendirme.

Hücre Ara
Hücre arama, çevreleyen hücreleri tespit etmeyi ve alınan sinyalin gücünü ölçmeyi amaçlar.
bu hücrelerin her birinden Bu hücrelerden biri, UE'nin sisteme katılmak için giriş noktası olacaktır.
hücresel ağ.

Ölçümler, Katman 1 filtrelemesi ile ortalaması alınan alınan PSS'nin RSRP'sine dayanmaktadır.
ve daha önce bölümde daha ayrıntılı olarak açıklandığı gibi PHY katmanı tarafından gerçekleştirilir. UE PHY
Ölçümler Model. PSS, eNodeB tarafından merkezi 72 alt taşıyıcısı üzerinden iletilir.
DL kanalı (Bölüm 5.1.7.3 [TS36300]), bu nedenle hücre aramayı bir DL kullanarak çalışacak şekilde modelliyoruz.
6 RB bant genişliği. Şu anda RSRQ ölçümlerinin mevcut olmadığını unutmayın.
simülasyonda. Sonuç olarak, LteUePhy::RsrqUeMeasEşik nitelik değil
hücre araması sırasında uygulayın.

Ölçülen RSRP'yi kullanarak, PHY varlığı tespit edilen hücrelerin bir listesini oluşturabilir,
her biri karşılık gelen hücre kimliği ve ortalama RSRP ile. Bu liste periyodik olarak itilir
CPHY SAP aracılığıyla RRC varlığına bir ölçüm raporu olarak gönderir.

RRC varlığı raporu inceler ve en güçlü RSRP'ye sahip hücreyi seçer.
[TS5.2.3.1] Bölüm 36304'de de belirtilmiştir. Sonra PHY varlığına geri talimat verir.
bu belirli hücreye senkronize edin. Hücrenin gerçek çalışma bant genişliği hala
şu anda bilinmiyor, bu nedenle PHY varlığı yalnızca 6 RB'lik minimum bant genişliğini dinler.
Bununla birlikte, PHY varlığı bu sistemden sistem yayın mesajını alabilecektir.
özellikle bir sonraki alt bölümün konusu olan eNodeB.

Yayın yapmak of sistem Bilgi
Sistem bilgi blokları, eNodeB tarafından UE'lere önceden tanımlanmış zaman aralıklarında yayınlanır,
[TS5.2.1.2] Bölüm 36331'den uyarlanmıştır. Desteklenen sistem bilgi blokları şunlardır:

·

usta Bilgi Engellemek (MIB)
Hücre sırasında oluşturulan PHY katmanıyla ilgili parametreleri içerir
radyo çerçevesinin başında her 10 ms'de bir yapılandırma ve yayınlama
kontrol mesajı.

·

sistem Bilgi Engellemek Menşei 1 (SIB1)
Her 20 ms'de bir yayınlanan ağ erişimiyle ilgili bilgileri içerir.
radyo çerçevesinin ortasında bir kontrol mesajı olarak. Manuel ekte kullanılmaz
yöntem. UE, SIB1'i alabilmesi için önce MIB kodunu çözmüş olmalıdır.

·

sistem Bilgi Engellemek Menşei 2 (SIB2)
RRC protokolü aracılığıyla iletilmek üzere programlanmış UL ve RACH ile ilgili ayarları içerir
hücre konfigürasyonundan 16 ms sonra ve ardından her 80 ms'de bir tekrar eder (yapılandırılabilir
içinden LteEnbRrc::SystemInformationPeriyodiklik bağlanmak. UE kamp kurmalı
SIB2'sini alabilmek için bir hücreye.

Sistem bilgilerinin alınması, UE'nin yaşam döngüsünde ilerlemesi için esastır. MIB
UE'nin 6 RB'lik ilk DL bant genişliğini fiili işletime yükseltmesini sağlar
ağın bant genişliği. SIB1, hücre seçimi için gerekli bilgileri sağlar
değerlendirme (bir sonraki bölümde açıklanmıştır). Ve son olarak, UE tamamlanmadan önce SIB2 gereklidir.
CONNECTED durumuna geçmesine izin verilir.

Hücre seçim Değerlendirme
UE RRC, üretilen ölçüm raporunu inceler. Hücre Ara ve hücre erişimi
SIB1 tarafından sağlanan bilgiler. Belirli bir hücre için her iki bilgi de mevcut olduğunda,
UE değerlendirme sürecini tetikler. Bu sürecin amacı, olup olmadığını belirlemektir.
hücre kamp yapmaya uygun bir hücredir.

Değerlendirme süreci, [TS5.2.3.2] Bölüm 36304'nin biraz basitleştirilmiş bir versiyonudur.
Aşağıdaki kriterlerden oluşur:

· Rx seviyesi kriteri; ve

· kapalı abone grubu (CSG) kriteri.

İlk kriter olan Rx seviyesi, hücrenin ölçülen RSRP Q_{rxlevmeas}'ına dayanır.
kriteri geçmek için gerekli minimum Q_{rxlevmin} değerinden yüksek olmalıdır:

burada Q_{rxlevmin}, her eNodeB tarafından belirlenir ve UE tarafından SIB1'den elde edilebilir.

Son kriter olan CSG, adı verilen doğru-yanlış parametresinin bir kombinasyonudur. CSG
belirti ve basit bir sayı CSG kimlik. Temel kural, UE'nin kamp yapmamasıdır.
Farklı bir CSG kimliğine sahip eNodeB. Ancak bu kural yalnızca CSG göstergesi olduğunda uygulanır.
gerçek olarak değerlendirilir. Daha fazla ayrıntı, Kullanıcının Sekme-ağ-bağlantısı bölümünde verilmiştir.
Belgeler.

Hücre yukarıdaki kriterlerin tümünü geçtiğinde, hücre olarak kabul edilir. uygun. Daha sonra UE
bunun için kamplar (IDLE_CAMPED_NORMALDE durum).

Bundan sonra, üst katman UE'den BAĞLANTI moduna girmesini isteyebilir. Lütfen bölüme bakın
RRC bağ kuruluş bununla ilgili ayrıntılar için.

Öte yandan, hücre CSG kriterini geçemediğinde hücre etiketlenir.
as kabul edilebilir (Bölüm 10.1.1.1 [TS36300]). Bu durumda, RRC kuruluşu PHY'ye
en güçlü ikinci hücreye senkronize etmek ve ilk hücre seçimini tekrarlamak için varlık
bu hücreyi kullanan prosedür. Uygun hücre bulunmadığı sürece, UE bunları tekrarlayacaktır.
Kabul edilebilir olarak tanımlanan hücrelerden kaçınırken adımlar.

radyo Kabul Control
Radyo Kabul Kontrolü, eNB RRC'nin bir RRC BAĞLANTISINA yanıt vermesiyle desteklenir
UE tarafından bir RRC CONNECTION SETUP mesajı veya bir RRC ile gönderilen REQUEST mesajı
Yeni UE'nin kabul edilip edilmeyeceğine bağlı olarak CONNECTION REJECT mesajı. İçinde
mevcut uygulamada, davranış, boole niteliği tarafından belirlenir
ns3::LteEnbRrc::AdmitRrcConnectionRequest. Şu anda Radyo Giriş Kontrolü yok
yeni bir bağlantının kabul edilip edilmeyeceğine dinamik olarak karar veren algoritma.

radyo taşıyıcı yapılandırma
RRC'de telsiz kurulumuna ilişkin bazı uygulama seçimleri yapılmıştır.
taşıyıcılar:

· üç Mantıksal Kanal Grubu (mevcut dört adetten) yukarı bağlantı arabelleği için yapılandırılmıştır
durum raporu amaçları, aşağıdaki politikaya göre:

· LCG 0, radyo taşıyıcılarına sinyal göndermek içindir

· LCG 1, GBR veri radyo taşıyıcıları içindir

· LCG 2, GBR olmayan veri radyo taşıyıcıları içindir

radyo Link Başarısızlık
Bu aşamada RRC yalnızca BAĞLANTI modunu desteklediğinden, Radyo Bağlantı Hatası (RLF)
işlenmemiş. Bunun nedeni, RLF'nin olası sonuçlarından birinin (RRC
yeniden kuruluş başarısız) RRC CONNECTED'den ayrılarak NAS'a RRC'yi bildirir.
bağlantı hatası. RLF'nin düzgün bir şekilde modellenebilmesi için RRC IDLE modunun desteklenmesi gerekir,
özellikle boş modda hücre (yeniden) seçimi dahil.

Mevcut modelle, kötü bağlantı kalitesi yaşayan ve performans göstermeyen bir UE
devir (örneğin, komşu hücre olmaması, devir devre dışı olması, devir eşikleri nedeniyle)
yanlış yapılandırılmış) yalnızca aynı eNB ile ilişkili kalacak ve zamanlayıcı duracaktır
iletişim için ona kaynak tahsis etmek.

UE RRC Ölçümler Model
UE RRC ölçümler destek
UE RRC varlığı, UE ölçümleri için destek sağlar; özellikle, uygular
[TS5.5] Bölüm 36331'te açıklanan prosedürler, aşağıdaki basitleştirmelerle birlikte
varsayımlar:

· yalnızca E-UTRA frekans içi ölçümler desteklenir, bu da şu anlama gelir:

· Simülasyon sırasında yalnızca bir ölçüm nesnesi kullanılır;

· Ölçümleri gerçekleştirmek için ölçüm boşluklarına gerek yoktur;

· Olay B1 ve B2 uygulanmadı;

· sadece raporGüçlüHücreler amaç desteklenirken, raporCGI ve
raporGüçlüHücrelerForSON amaçlar desteklenmez;

· s-Ölçü desteklenmiyor;

· Taşıyıcı toplama LTE modülü tarafından desteklenmediğinden, aşağıdakiler
UE ölçümlerindeki varsayımlar geçerlidir:

· ikincil hücre kavramı yok (Hücre);

· birincil hücre (PC hücresi) sadece hizmet veren hücre anlamına gelir;

· Olay A6 uygulanmadı;

· tetikleme süresinin hıza bağlı ölçeklendirmesi ([TS5.5.6.2] Bölüm 36331)
destekledi.

Genel dizayn
Model şu konsepte dayanmaktadır: UE ölçümler tüketiciolabilen bir varlık olan
UE ölçüm raporları sağlamak için bir eNodeB RRC varlığı isteyin. Tüketiciler,
örnek, Teslim et algoritmaUE ölçümüne dayalı olarak devir kararını hesaplayan
raporlar. Test senaryoları ve kullanıcı programları da tüketici olabilir. Figür ilişki
arasında UE ölçümler ve onun tüketiciler bu varlıklar arasındaki ilişkiyi gösterir.
[image] UE ölçümleri ve tüketicileri arasındaki ilişki.UNINDENT

RRC düzeyindeki tüm UE ölçümleri işlevi 4 ana bölüme ayrılmıştır:

1. Ölçüm yapılandırması (kullanan LteUeRrc::ApplyMeasConfig)

2. Ölçümlerin yapılması (kullanan LteUeRrc::DoReportUeMeasurements)

3. Ölçüm raporu tetikleme ( LteUeRrc::MeasurementRaporTetikleme)

4. Ölçüm raporlaması (şirket tarafından yönetilir) LteUeRrc::SendMeasurementRaporu)

Aşağıdaki bölümlerde yukarıdaki parçaların her biri açıklanacaktır.

Ölçüm yapılandırma
Bir eNodeB RRC varlığı, yapılandırma parametrelerini şu adrese göndererek UE ölçümlerini yapılandırır:
UE RRC varlığı. Bu parametre seti, Ölçüm Yapılandırması Bilgi
RRC Bağlantı Yeniden Yapılandırma mesajının (IE) öğesi (RRC bağ
yeniden yapılandırma).

eNodeB RRC varlığı, içinde açıklanan yapılandırma parametrelerini ve prosedürleri uygular.
[TS5.5.2] Bölüm 36331, aşağıdaki basitleştirici varsayımla:

· yapılandırma (yani ekleme, değiştirme ve kaldırma) yalnızca
simülasyon başlar;

· eNodeB'ye bağlı tüm UE'ler aynı şekilde yapılandırılacaktır, yani
belirli UE için belirli ölçümü yapılandırma desteği; ve

· PCI ve E-UTRAN arasında bire bir eşleme olduğu varsayılır
Küresel Hücre Tanımlayıcısı (EGCI). Bu, PCI modelleme varsayımlarıyla tutarlıdır
tarif edilmek UE PHY Ölçümler Model.

Buradaki eNodeB RRC örneği, tüketiciler ve müşteriler arasında bir aracı görevi görür.
ekli UE'ler. Simülasyonun başlangıcında, her tüketici eNodeB RRC'yi sağlar.
örneğin, gereken UE ölçüm konfigürasyonu ile. Bundan sonra, eNodeB
RRC, konfigürasyonu bağlı UE'lere dağıtır.

Kullanıcılar, çeşitli yöntemler kullanarak ölçüm yapılandırmasını özelleştirebilir. Bakınız
Açıklama için Kullanıcı Dokümantasyonunun bölüm sec-configure-ue-ölçümleri
bu yöntemler.

Gösteri ölçümler
UE RRC, UE PHY'den periyodik olarak hem RSRP hem de RSRQ ölçümlerini alır.
tarif edilmek UE PHY Ölçümler Model. tabaka 3 süzme bunlara uygulanacak
alınan ölçümler Filtrelemenin uygulanması, Bölüm 5.5.3.2'yi takip eder.
[TS36331]:

nerede:

· M_n, fiziksel katmandan alınan en son ölçüm sonucudur;

· F_n, güncellenmiş filtrelenmiş ölçüm sonucudur;

· F_{n-1} eski filtrelenmiş ölçüm sonucudur, burada F_0 = M_1 (yani ilk
ölçüm filtrelenmez); ve

· a = (ac{1}{2})^{ac{k}{4}}, burada k yapılandırılabilir filtre katsayısı tarafından sağlanan
the MiktarYapılandırma;

k = 4 varsayılan değerdir, ancak ayarlanarak yapılandırılabilir. RsrpFiltre Katsayısı ve
RsrqFilter Katsayısı nitelikler LteEnbRrc.

Bu nedenle k = 0, Katman 3 filtrelemesini devre dışı bırakacaktır. Öte yandan, geçmiş ölçümler
daha büyük k değeri kullanılarak filtreleme sonuçları üzerinde daha fazla etki verilebilir.

Ölçüm raporlama tetikleme
Bu bölümde, UE RRC, aktif ölçüm konfigürasyonu listesini gözden geçirecek ve
Tetikleme koşulunun Bölüm 5.5.4'e göre karşılanıp karşılanmadığını kontrol edin.
[TS36331]. Tüm aktif ölçümlerden en az bir tetikleme koşulu olduğunda
konfigürasyon yerine getirildiğinde, ölçüm raporlama prosedürü (bir sonraki
alt bölümü) başlatılacaktır.

3GPP iki tür tanımlar tetik türü: periyodik ve olaya dayalı. Şu anda, sadece
olaya dayalı kriter desteklenir. Seçilebilecek çeşitli etkinlikler vardır.
aşağıdaki tabloda kısaca açıklanmıştır:

Liste of destekli olaya dayalı tetikleme kriterleri
┌────────────────────────────────────────┐
│Ad │ Açıklama │
├────────────────────────────────────────┤
│Olay A1 │ Hizmet veren hücre │'den daha iyi olur
│ │ eşik │
├────────────────────────────────────────┤
│Olay A2 │ Hizmet veren hücre │ değerinden daha kötü hale geliyor
│ │ eşik │
├────────────────────────────────────────┤
│Olay A3 │ Komşu olur ofset dB │
│ │ hücreye hizmet etmekten daha iyi │
├────────────────────────────────────────┤
│Event A4 │ Komşu │'den daha iyi olur
│ │ eşik │
└────────────────────────────────────────┘

│Event A5 │ Sunum şundan daha kötü hale geliyor │
│ │ eşik1 VE komşu olur │
│ │ daha iyi eşik2 │
└────────────────────────────────────────┘

Olay tabanlı bir tetikleyicide kontrol edilmesi gereken iki ana koşul şunlardır: girme koşul ve
the ayrılma koşul. Bu ikisi hakkında daha fazla ayrıntı Bölüm 5.5.4'te bulunabilir.
[TS36331].

Olaya dayalı bir tetikleyici, histerezis tanıtılarak daha fazla yapılandırılabilir ve
tetikleme zamanı. gecikme (Hys) giriş ve çıkış arasındaki mesafeyi tanımlar.
dB cinsinden koşullar. Benzer şekilde, tetikleme zamanı hem girişte hem de çıkışta gecikme sağlar
koşullar, ancak bir zaman birimi olarak.

The periyodik raporlama tetikleyici türü desteklenmez, ancak davranışı kolayca
olay tabanlı bir tetikleyici kullanılarak elde edilir. Bu, ölçümü yapılandırarak yapılabilir.
giriş koşulu her zaman yerine getirilecek şekilde, örneğin
A1 Olayının sıfıra eşiği (minimum seviye). Sonuç olarak, ölçüm raporları
tarafından belirlendiği gibi her zaman her belirli aralıkta tetiklenecektir. raporAralığı
içindeki alan LteRrcSap::ReportConfigEutra, bu nedenle aynı davranışı üreten
periyodik raporlama.

3GPP spesifikasyonlarına göre bir sınırlama olarak, mevcut model desteklemiyor
herhangi bir hücreye özgü yapılandırma. Bu konfigürasyon parametreleri ölçümde tanımlanır
nesne. Sonuç olarak, tetikleme sürecine bir kara hücre listesi eklemek
desteklenmiyor. Ayrıca, hücreye özgü ofset (yani, Olay A3, A4'teki O_{cn} ve O_{cp},
ve A5) de desteklenmez. sıfıra eşit değer her zaman yerine varsayılır
Onları.

Ölçüm raporlama
Bu kısım, UE RRC varlığından ölçüm raporunun
eNodeB varlığına RRC protokolü aracılığıyla hizmet vermek. Çeşitli basitleştirici varsayımlar benimsenmiştir:

· rapor Tutarı is değil uygulanabilir (yani her zaman sonsuz olduğu varsayılır);

· ölçüm raporlarında, raporMiktar her zaman olduğu varsayılır HEMyani ikisi de
RSRP ve RSRQ her zaman raporlanır. tetikleyiciMiktar.

Teslim et
RRC modeli, X2 tabanlı geçişi çağırarak BAĞLANTILI modda UE mobilitesini destekler
prosedür. Model, Bölüm 10.1.2.1'e dayalı olarak intra-EUTRAN ve intra-frekanstır.
[TS36300].

Bu bölüm, bir devir teslimi tetikleme sürecine odaklanmaktadır. Devir teslim yürütme
Prosedürün kendisi Bölümde ele alınmıştır. X2.

Devir teslim prosedürünü tetiklemenin iki yolu vardır:

· açıkça (veya manuel olarak) simülasyon programı tarafından programlanarak tetiklenir.
yöntemin yürütülmesi LteEnbRrc::SendHandoverRequestYa da

· otomatik olarak UE ölçümlerine dayalı olarak eNodeB RRC varlığı tarafından tetiklenir ve
seçilen geçiş algoritmasına göre.

Kullanıcı Belgelerinin sec-x2 tabanlı devir teslimi bölümü, kullanıma ilişkin bazı örnekler sağlar
simülasyonda hem açık hem de otomatik geçiş tetikleyicileri. Bir sonraki alt bölüm
tasarım özelliklerini açıklayarak otomatik yönteme daha yakından bakın.
geçiş algoritma arayüzü ve mevcut geçiş algoritmaları.

Teslim et algoritma
3GPP LTE'de aktarım aşağıdaki özelliklere sahiptir:

·

UE destekli
UE, ağa ölçüm raporları biçiminde girdi sağlar. Bu
tarafından işlenir UE RRC Ölçümler Model.

·

Ağ kontrollü
Ağ (yani kaynak eNodeB ve hedef eNodeB) ne zaman yapılacağına karar verir.
devri tetikler ve yürütülmesini denetler.

The teslim et algoritma eNodeB kaynağında çalışır ve geçiş yapmaktan sorumludur
kararlar "otomatik" bir şekilde. aracılığıyla bir eNodeB RRC örneği ile etkileşime girer.
Teslim et Yönetim SAP arayüz. Bu ilişkiler Şekil XNUMX'de gösterilmektedir.
ilişki arasında UE ölçümler ve onun tüketiciler önceki bölümden.

Geçiş algoritması arayüzü aşağıdaki yöntemlerden oluşur:

·

AddUeMeasReportConfigForHandover
(Handover Algorithm -> eNodeB RRC) Handover algoritması tarafından istekte bulunmak için kullanılır.
eNodeB RRC varlığından alınan ölçüm raporları, istenen
raporlama yapılandırması. Yapılandırma gelecekteki tüm
bağlı UE'ler.

·

RaporUeMeas
(eNodeB RRC -> Devir Algoritması) Yapılandırılan UE ölçümlerine göre
daha erken AddUeMeasReportConfigForHandover, UE ölçüm raporları sunabilir
eNodeB'ye. eNodeB RRC varlığı, RaporUeMeas arayüz
bu ölçüm raporlarını aktarma algoritmasına iletin.

·

Devir Tetikleyici
(Handover Algorithm -> eNodeB RRC) Ölçüm raporlarını inceledikten sonra
(ancak zorunlu değil), devir algoritması bir devir bildirebilir. Bu
yöntemi, eNodeB RRC varlığını bu karar hakkında bilgilendirmek için kullanılır.
ardından devir teslim prosedürünü başlatmak için ilerleyin.

için bir not AddUeMeasReportConfigForHandover. Yöntem şu değeri döndürür: ölçüm kimliği
(ölçüm kimliği) yeni oluşturulan ölçüm konfigürasyonunun. tipik olarak bir
devir algoritması bu benzersiz sayıyı saklar. içinde yararlı olabilir RaporUeMeas
yöntemi, örneğin birden fazla konfigürasyon istendiğinde ve geçiş
Algoritmanın, gelen raporları yapılandırmaya göre ayırt etmesi gerekir.
onları tetikledi.

Bir alt sınıf yazılarak bir geçiş algoritması uygulanır. LteHandoverAlgoritması
soyut üst sınıf ve yukarıda belirtilen SAP arayüz yöntemlerinin her birinin uygulanması.
Kullanıcılar bu şekilde kendi geçiş algoritmalarını geliştirebilir ve daha sonra herhangi bir simülasyonda kullanabilirler.
Kullanıcının sec-x2 tabanlı devri bölümünde belirtilen adımları izleyerek
Belgeler.

Alternatif olarak, kullanıcılar sağlanan 3 yerleşik geçiş algoritmasından birini kullanmayı seçebilir.
LTE modülü tarafından: işlemsiz, A2-A4-RSRQ ve en güçlü hücre aktarım algoritması. Bunlar
simülasyonlarda kullanılmaya hazır veya bir devir teslim uygulamasına örnek olarak alınabilir
algoritma. Bu yerleşik algoritmaların her biri, aşağıdakilerin her birinde ele alınmıştır.
alt bölümler.

ameliyatsız teslim et algoritma
The işlemsiz teslim et algoritma (NoOpHandoverAlgoritması sınıf) mümkün olan en basit olanıdır
geçiş algoritmasının uygulanması. Temelde hiçbir şey yapmaz, yani herhangi bir arama yapmaz.
Devir Teslim Yönetimi SAP arayüz yöntemlerinin. Kullanıcılar bu geçiş algoritmasını seçebilir
simülasyonlarında otomatik geçiş tetiklemesini devre dışı bırakmak isterlerse.

A2-A4-RSRQ teslim et algoritma
The A2-A4-RSRQ teslim et algoritma varsayılan geçişin işlevselliğini sağlar
orijinal olarak LENA M6'da bulunan (ns-3.18) algoritma, Handover Management SAP'ye taşındı
olarak arayüz A2A4RsrqHandoverAlgoritması sınıf.

Adından da anlaşılacağı gibi, algoritma Alınan Referans Sinyal Kalitesini (RSRQ) kullanır.
Olay A2 ve Olay A4'ten alınan ölçümler. Böylece, algoritma 2 ekleyecektir
ilgili eNodeB RRC örneğine ölçüm yapılandırması. Amaçlanan kullanımları
aşağıdaki gibi tarif edilmiştir:

· Etkinlikler A2 (hizmet veren hücrenin RSRQ'su şundan daha kötü hale gelir: eşik) belirtmek için kaldıraçlıdır
UE'nin düşük sinyal kalitesi yaşadığı ve bir geçişten fayda sağlayabileceği.

· Etkinlikler A4 (komşu hücrenin RSRQ'su şundan daha iyi olur: eşik) algılamak için kullanılır
komşu hücreler ve karşılık gelen RSRQ'larını bağlı her UE'den alır;
daha sonra algoritma tarafından dahili olarak saklanır. Varsayılan olarak, algoritma yapılandırır
Tetikleme ölçütünün her zaman doğru olması için çok düşük bir eşiğe sahip A4 Olayı.

şekil A2-A4-RSRQ teslim et algoritma aşağıda bu prosedür özetlenmektedir.
[resim] A2-A4-RSRQ geçiş algoritması.UNINDENT

Algoritma davranışını ayarlamak için iki özellik ayarlanabilir:

·

Hizmet Hücresi Eşiği
The eşik A2 Olayı için, yani bir UE'nin RSRQ değeri bundan daha düşük olmalıdır
devir teslim için dikkate alınması gereken eşik.

·

KomşuHücre Ofseti
The ofset UE'nin daha iyi sinyal kalitesi almasını sağlamayı amaçlayan
devir teslimden sonra. Komşu bir hücre, hedef hücre olarak kabul edilir.
yalnızca RSRQ'su hizmet veren hücrenin RSRQ'sundan miktar olarak daha yüksekse devir
Bu ofset.

Her iki özniteliğin değeri, RSRQ aralığı olarak ifade edilir ([TS9.1.7] Bölüm 36133),
0 ile 34 arasında bir tam sayıdır ve 0, en düşük RSRQ'dur.

Güçlü hücre teslim et algoritma
The güçlü hücre teslim et algoritmaveya bazen olarak da bilinir geleneksel güç kelimesini seçerim
bütçe (PBGT) algoritma, referans olarak [Dimou2009] kullanılarak geliştirilmiştir. fikir şu ki
her UE'ye mümkün olan en iyi Referans Sinyali Alınan Gücü (RSRP) sağlar. Bu
daha iyi bir hücre (yani daha güçlü RSRP'ye sahip) olduğu anda bir devir gerçekleştirerek yapılır.
algılandı.

Etkinlikler A3 (komşu hücrenin RSRP'si, hizmet veren hücrenin RSRP'sinden daha iyi olur) seçilir.
bu kavramı gerçekleştirin. bu A3RsrpHandoverAlgoritması sınıfın sonucudur
uygulama. Aktarım, UE için ölçümdeki en iyi hücreye tetiklenir
rapor.

Bu algoritmayı kullanan bir simülasyon, genellikle masa tenisi geçişine karşı daha savunmasızdır.
(kısa bir süre içinde önceki eNodeB kaynağına ardışık geçiş),
özellikle ne zaman solan Model etkin. Bu sorun genellikle şu şekilde çözülür:
devir teslimine belirli bir gecikme getirilmesi. Algoritma bunu dahil ederek yapar
UE'ye histerezis ve tetikleme süresi parametreleri ([TS6.3.5] Bölüm 36331)
ölçüm konfigürasyonu.

gecikme (aka devir marjı), RSRP ile ilgili olarak devir teslimini geciktirir. değer
dB olarak ifade edilir, 0 ile 15 dB arasında değişir ve 0.5 dB doğruluğa sahiptir, örneğin bir giriş
2.7 dB değeri 2.5 dB'ye yuvarlanır.

Öte yandan, tetikleme zamanı zaman açısından devir teslimini geciktirir. 3GPP 16'yı tanımlar
tetikleme süresi için geçerli değerler (tümü milisaniye cinsinden): 0, 40, 64, 80, 100, 128, 160, 256,
320, 480, 512, 640, 1024, 1280, 2560 ve 5120.

Histerezis ve tetikleme süresi arasındaki fark Şekil'de gösterilmektedir. Efekt of
gecikme ve tetikleme zamanı in güçlü hücre teslim et algoritma Aşağıda, alınan
itibaren lena-x2-devir teslim önlemleri örnek. Hizmet veren hücrenin algılanan RSRP'sini gösterir.
ve hücrelerin sınırından geçerek hareket eden bir UE tarafından komşu bir hücre.
[resim] En güçlü hücre geçişinde histerezis ve tetikleme süresinin etkisi
algoritma.UNENDENT

Varsayılan olarak, algoritma 3.0 dB'lik bir histerezis ve 256 ms'lik tetikleme süresi kullanır.
Bu değerler, gecikme ve Tetikleme Zamanı özellikleri
A3RsrpHandoverAlgoritması sınıf.

komşu ilişki
LTE modülü basitleştirilmiş bir Otomatik komşu ilişki (ANR) işlevi. Bu
tarafından ele alındı LteAnr ANR aracılığıyla bir eNodeB RRC örneğiyle etkileşime giren sınıf
SAP arayüzü.

komşu ilişki tablo
ANR bir komşu ilişki tablo (NRT), Bölümdeki açıklamaya benzer
[TS22.3.2]'ün 36300a'sı. Tablodaki her girişe bir ad verilir. komşu ilişki (NR) ve
aşağıdaki boole alanlarını içeren algılanan bir komşu hücreyi temsil eder:

·

Yok hayır Kaldır
NR'nin değil NRT'den çıkarılmalıdır. Bu gerçek by
kullanıcı tarafından sağlanan NR için varsayılan ve yanlış aksi takdirde.

·

Yok hayır X2 NR'nin değil başlatmak için bir X2 arabirimi kullanın
hedef hücreye ebeveynlik yapan eNodeB'ye yönelik prosedürler. Bu yanlış by
kullanıcı tarafından sağlanan NR için varsayılan ve gerçek aksi takdirde.

·

Yok hayır HO NR'nin değil devir nedenleriyle eNodeB tarafından kullanılabilir.
Bu gerçek çoğu durumda, NR'nin hem kullanıcı tarafından sağlandığı hem de
ağ algılandı.

Her NR girişi, aşağıdaki özelliklerden en az birine sahip olabilir:

·

kullanıcı tarafından sağlanan
Bu tip NR, simülasyon kullanıcısı tarafından talimat verildiği şekilde oluşturulur. Örneğin,
kullanıcı tarafından başlatılan bir X2 kurulumu üzerine otomatik olarak bir NR oluşturulur
2 eNodeB arasındaki bağlantı, örneğin Bölüm'de açıklandığı gibi
sec-x2 tabanlı aktarım. Kullanıcı tarafından sağlanan bir NR oluşturmanın başka bir yolu da
Komşu İlişkisi Ekle açıkça işlev görür.

·

Ağ algılandı
Bu tür NR, simülasyon sırasında otomatik olarak oluşturulur.
yakındaki bir hücrenin keşfi.

ANR, ağ tarafından algılanan NR'yi otomatik olarak oluşturmak için UE ölçümlerini kullanır. İçinde
başka bir deyişle ANR, Şekil'de gösterildiği gibi UE ölçümlerinin bir tüketicisidir. ilişki
arasında UE ölçümler ve onun tüketiciler. RSRQ ve Event A4 (komşu daha iyi hale gelir)
göre eşik) raporlama yapılandırması için kullanılır. Varsayılan Olay A4 eşik
mümkün olan en düşük değere, yani maksimum algılama kapasitesine ayarlanmıştır, ancak şu şekilde değiştirilebilir:
ayarlamak Eşik niteliği LteAnr sınıf. A2-A4-RSRQ aktarımının
algoritması da benzer bir raporlama yapılandırması kullanır. Benzerliğe rağmen, ne zaman
hem ANR hem de bu geçiş algoritması eNodeB'de etkindir, ayrı raporlama kullanırlar
konfigürasyonu.

Ayrıca X2 arayüzünün otomatik kurulumunun desteklenmediğini unutmayın. sebebi bu
the Yok hayır X2 ve Yok hayır HO alanlar, ağ tarafından algılanan ancak kullanıcı tarafından algılanmayan bir NR'de doğrudur.

Rol of ANR in Simulation
ANR SAP arabirimi, ANR ve eNodeB RRC arasındaki iletişim araçlarını sağlar. Bazı
arabirim işlevleri, eNodeB RRC tarafından aşağıda gösterildiği gibi NRT ile etkileşim kurmak için kullanılır:

·

Komşu İlişkisi Ekle
(eNodeB RRC -> ANR) NRT'ye kullanıcı tarafından sağlanan yeni bir NR girişi ekleyin.

·

GetNoRemove
(eNodeB RRC -> ANR) değerini alın Yok hayır Kaldır NR girişinin alanı
verilen hücre kimliği.

·

GetNoHo
(eNodeB RRC -> ANR) değerini alın Yok hayır HO verilen bir NR girişinin alanı
hücre kimliği.

·

GetNoX2
(eNodeB RRC -> ANR) değerini alın Yok hayır X2 verilen bir NR girişinin alanı
hücre kimliği.

ANR'nin bir UE ölçüm tüketicisi olarak rolünü desteklemek için başka arayüz işlevleri mevcuttur.
aşağıda listelendiği gibi:

·

AddUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) ANR tarafından kullanıcıdan ölçüm raporları istemek için kullanılır.
eNodeB RRC varlığı, istenen raporlama yapılandırmasını geçirerek. bu
yapılandırma gelecekteki tüm ekli UE'lere uygulanacaktır.

·

RaporUeMeas
(eNodeB RRC -> ANR) Daha önce yapılandırılan UE ölçümlerine göre
AddUeMeasReportConfigForAnrUE, ölçüm raporlarını eNodeB'ye gönderebilir.
eNodeB RRC varlığı, RaporUeMeas bunları iletmek için arayüz
ANR'ye ölçüm raporları.

için lütfen ilgili API belgelerine bakın. LteAnrSap Daha fazla ayrıntı için sınıf
kullanım ve gerekli parametreler hakkında.

ANR, eNodeB RRC bulut sunucusu tarafından aşağıdakileri takip etmek için bir veri yapısı olarak kullanılır:
Yakındaki komşu hücrelerin durumu. ANR ayrıca eNodeB RRC örneğinin şunları yapmasına yardımcı olur:
komşu bir hücreye aktarma prosedürünün yürütülmesinin mümkün olup olmadığını belirleyin.
Bu, eNodeB RRC'nin yalnızca bir devir teslim prosedürüne izin vereceği gerçeğiyle gerçekleştirilir.
hedef hücrenin NR girişi her ikisine de sahipse olur Yok hayır HO ve Yok hayır X2 alanlar yanlış.

ANR, simülasyondaki her eNodeB örneğinde varsayılan olarak etkindir. Devre dışı bırakılabilir
ayarlayarak AnrEtkin öznitelik LteHelper sınıfa yanlış.

RRC dizi diyagramlar
Bu bölümde, en önemli RRC'yi açıklayan bazı dizi diyagramları sunuyoruz.
prosedürler modellenmektedir.

RRC bağ kuruluş
şekil Dizi diyagram of the RRC Komunite Kuruluş prosedür RRC'nin nasıl olduğunu gösterir
Bağlantı Kurulum prosedürü, RRC katmanının rolünü vurgulayarak modellenmiştir.
hem UE hem de eNB'nin yanı sıra diğer katmanlarla etkileşim.
[resim] RRC Bağlantı Kurulumu prosedürünün sıralama şeması.UNINDENT

Bu prosedürle ilgili, aşağıda listelenen birkaç zaman aşımı vardır.
tablo Zamanlayıcılar in RRC bağ kuruluş prosedür. Bu zamanlayıcılardan herhangi birinin süresi dolmuşsa,
RRC bağlantı kurma prosedürü başarısızlıkla sonlandırıldı. bu durumda,
üst katman (UE NAS), tamamlanana kadar prosedürü hemen yeniden denemeye çalışacaktır.
Başarıyla.

Zamanlayıcılar in RRC bağ kuruluş prosedür
┌vet, ┌ derecede ┌cılık üver ütle ─────────────┬─────────┬─────────────────
│Ad │ Konum │ Zamanlayıcı başlar │ Zamanlayıcı durur │ Varsayılan │ Zamanlayıcı olduğunda │
│ │ │ │ │ süre │ süresi doldu │
├vet, ├´art ve üve Harika bir ────────────┼─────────────────────────────
│Connection │ eNodeB RRC │ Yeni UE içeriği │ RRC Al │ 15 ms │ UE'yi Kaldır │
│istek │ │ eklendi │ BAĞLANTI │ │ içerik │
│zaman aşımı │ │ │ TALEP │ │ │
├vet, ├´art ve üve Harika bir ────────────┼─────────────────────────────
│Bağlantı │ UE RRC │ RRC Gönder │ RRC Al │ 100 ms │ UE MAC Sıfırla │
│zaman aşımı (T300 │ │ BAĞLANTI │ BAĞLANTI │ │ │
│zamanlayıcı) │ │ TALEP │ KURULUM veya │ │ │
│ │ │ │ REDDETMEK │ │ │
├vet, ├´art ve üve Harika bir ────────────┼─────────────────────────────
│Bağlantı │ eNodeB RRC │ RRC Gönder │ RRC Al │ 100 ms │ UE'yi Kaldır │
│kurulum zaman aşımı │ │ BAĞLANTI │ BAĞLANTI │ │ içerik │
│ │ │ KURULUM │ KURULUM TAMAMLANDI │ │ │
├vet, ├´art ve üve Harika bir ────────────┼─────────────────────────────
│Connection │ eNodeB RRC │ RRC Gönder │ Asla │ 30 ms │ UE'yi Kaldır │
│reddedildi │ │ BAĞLANTI │ │ │ bağlam │
│zaman aşımı │ │ REDDETMEK │ │ │ │
└vet, └ derecede └cılık üver ütle ─────────────┴──────────┴────────────────┘

RRC bağ yeniden yapılandırma
şekil Dizi diyagram of the RRC Komunite Yeniden yapılandırma prosedür RRC'nin nasıl olduğunu gösterir
Bağlantı Yeniden Yapılandırma prosedürü, MobilityControlInfo'nun olduğu durum için modellenmiştir.
sağlanmaz, yani devir teslim yapılmaz.
[resim] RRC Bağlantısını Yeniden Yapılandırma prosedürünün sıralama şeması.UNINDENT

şekil Dizi diyagram of the RRC Komunite Yeniden yapılandırma prosedür için the teslim et
dava RRC Bağlantı Yeniden Yapılandırma prosedürünün durum için nasıl modellendiğini gösterir
MobilityControlInfo'nun sağlandığı yer, yani devir teslimin gerçekleştirileceği yer. Belirtildiği gibi
[TS36331] içinde, Sonra alma the teslim et mesaj the UE girişimleri için erişim the hedef
hücre at the ilk mevcut RACH fırsat göre için Rasgele giriş kaynak seçim
tanımlı in [TS36321]_, yani the teslim et is asenkron. Sonuç olarak, ne zaman Ayrılacak
a adanmış önsöz için the rasgele erişim in the hedef hücre, E-UTRA -ecek sağlamak it is
mevcut itibaren the ilk RACH fırsat the UE eğer yalnızca sığınmacı statüleri sona erdirilmemişse, kalıcı oturma iznine kullanın. üzerine başarılı tamamlama of the
devretmek, the UE gönderir a mesaj Kullanılmış için onaylamak the devretmek. Rastgele olduğuna dikkat edin
Bu durumda erişim prosedürü çekişme tabanlı değildir, dolayısıyla gerçek bir LTE sisteminde
kurulan RRC bağlantısında kullanılandan biraz farklıdır. Ayrıca, RA'nın
Başlangıç ​​Kimliği, X2 Aktarım Talebinde bulunan Aktarım Komutu yoluyla bildirilir
Hedef eNB'den kaynak eNB'ye gönderilen ACK mesajı; özellikle, önsöz
MobilityControlInfo'nun bir parçası olan RACH-ConfigDedicated IE'ye dahildir.
[resim] için RRC Bağlantı Yeniden Yapılandırma prosedürünün sıralama diyagramı
Devir teslim davası.UNINDENT

RRC protokol modelleri
Önceden tahmin edildiği gibi, şanzıman için iki farklı model sunuyoruz ve
RRC mesajlarının alınması: Ideal ve Gerçek. Bunların her biri, birinde açıklanmıştır.
aşağıdaki alt bölümler.

Ideal RRC protokol model
Bu modele göre sınıflarda uygulanan ve LteUeRrcProtocolİdeal ve
LteEnbRrcProtocolİdeal, tüm RRC mesajları ve bilgi öğeleri arasında iletilir
eNB ve UE'yi ideal bir şekilde, radyo kaynaklarını tüketmeden ve
hatalar. Uygulama açısından bakıldığında, bu, RRC verilerini ileterek elde edilir.
alt katmanları dahil etmeden doğrudan UE ve eNB RRC varlıkları arasında yapı
(PDCP, RLC, MAC, zamanlayıcı).

Gerçek RRC protokol model
Bu model sınıflarda uygulanmaktadır. LteUeRrcProtocolGerçek ve LteEnbRrcProtocolGerçek
ve gerçek LTE'de yaygın olarak gerçekleştirilen RRC PDU'ların iletimini modellemeyi amaçlar.
sistemler. Özellikle:

· Gönderilen her RRC mesajı için, ASN.1'den sonra gerçek bir RRC PDU oluşturulur.
[TS36331]'de belirtilen RRC PDU'ların ve bilgi öğelerinin (IE'ler) kodlanması. Bazı
PDU'da yer alan IE'lere göre sadeleştirme yapılır, yani yalnızca
Simülasyon amaçları için yararlı olan IE'ler dahil edilmiştir. Detaylı liste için lütfen
içinde tanımlanan IE'lere bakın lte-rrc-sap.h ve [TS36331] ile karşılaştırın.

· kodlanmış RRC PDU'lar, Sinyal Radyo Taşıyıcılarına gönderilir ve aynı şartlara tabidir.
veri iletişimleri için kullanılan iletim modellemesi, dolayısıyla planlama, radyo
kaynak tüketimi, kanal hataları, gecikmeler, yeniden iletimler vb.

Sinyal radyo taşıyıcı model
Şimdi için kullanılan Signaling Radio Bearer modelini açıklıyoruz. Gerçek RRC protokolü
modeli.

· SRB0 mesajlar (CCCH üzerinden):

· RrcConnection İsteği: gerçek LTE sistemlerinde bu, üzerinden gönderilen bir RLC TM SDU'dur
RAR'da UL Hibesinde belirtilen kaynaklar (UL DCI'larda değil); nedeni şu ki
C-RNTI henüz bu aşamada bilinmiyor. Simülatörde, bu gerçek olarak modellenmiştir.
UL kaynakları çağrı üzerine program tarafından tahsis edilen RLC TM RLC PDU
SCHED_DL_RACH_INFO_REQ.

· RrcConnection Kurulumu: simülatörde bu, gerçek LTE sistemlerinde olduğu gibi uygulanır,
yani, normal bir UL DCI tarafından belirtilen kaynaklar üzerinden gönderilen bir RLC TM SDU ile,
olan RLC TM örneği tarafından tetiklenen SCHED_DL_RLC_BUFFER_REQ ile tahsis edilmiştir.
LCID 0'a (CCCH) eşlendi.

· SRB1 mesajlar (DCCH üzerinden):

· Simülatörde modellenen tüm SRB1 mesajları (örn. RrcConnectionTamamlandı)
gerçek LTE sistemlerinde olduğu gibi uygulanır, yani RLC AM üzerinden gönderilen gerçek bir RLC SDU ile
Arabellek Durum Raporları yoluyla tahsis edilen DL kaynaklarını kullanma. RLC modeline bakın
ayrıntılar için belgeler.

· SRB2 mesajlar (DCCH üzerinden):

· [TS36331]'e göre, "SRB1 is için RRC mesajları (hangi eğer yalnızca sığınmacı statüleri sona erdirilmemişse, kalıcı oturma iznine dahil a
piggybacked NAS İleti) as iyi as için NAS mesajları önceki için the kuruluş
of SRB2, herşey kullanma DCCH mantıksal kanal", halbuki "SRB2 is için NAS mesajları
kullanma DCCH mantıksal kanal" ve "SRB2 vardır a düşük öncelikli göre SRB1 ve is
her zaman yapılandırılmış by E-UTRAN sonra güvenlik etkinleştirme". Modelleme
güvenlikle ilgili hususlar, LTE simülasyon modelinin bir gerekliliği değildir,
bu nedenle her zaman SRB1'i kullanırız ve asla SRB2'yi etkinleştirmeyiz.

asn.1 kodlama of RRC IE'ler
Tüm Ue/Enb SAP Kullanıcıları/Sağlayıcıları için ortak olan, RRC SAP'de tanımlanan mesajlar taşınır.
bir Ue/Enb'ye/Enb'den şeffaf bir kapta. Farklı kodlama formatı
Bilgi Öğeleri, hizalanmamış ASN.36331 kuralları kullanılarak [TS1]'de belirtilmiştir.
varyant. Ns3/Lte'deki uygulama aşağıdaki sınıflara bölünmüştür:

· Asn1Header : Temel ASN türlerinin kodlamasını / kodunu çözmesini içerir

· RrcAsn1Header : Asn1Header'ı devralır ve ortak kodlama / kod çözme içerir
[TS36331]'de tanımlanan IE'ler

· Rrc'ye özgü mesajlar/IE'ler sınıfları : RRC'de tanımlanan mesajların her biri için bir sınıf
SAP başlığı

Asn1Başlık sınıf - Uygulama of baz asn.1 türleri
Bu sınıf, kullanılan ASN.1 türlerini Serileştirme/Serialize etme yöntemlerini uygular.
[TS36331], ITU-T X.691'deki paketlenmiş kodlama kurallarına göre. Düşünülen türler
şunlardır:

· Boolean : bir boole değeri tek bir bit kullanır (1=true, 0=false).

· Tamsayı : kısıtlanmış bir tamsayı (tanımlanmış minimum ve maksimum değerlerle) minimum değeri kullanır
aralığını (maks-min+1) kodlamak için bit miktarı.

· Bitstring : bir bistring, serileştirme arabelleğine azar azar kopyalanacaktır.

· Octetstring : şu anda kullanılmıyor.

· Dizi : dizi, isteğe bağlı ve
varsayılan alanlar. Ayrıca, uzantı işaretçisinin varlığını gösteren bir bit ekler.

· Sequence...Of : type...of dizisi, dizinin elemanlarının sayısını kodlar
bir tamsayı olarak (sonraki elemanların daha sonra kodlanması gerekecektir).

· Seçim : seçim kümesindeki öğelerden hangisinin kodlandığını gösterir.

· Numaralandırma : arasında hangi değerin kullanıldığını gösteren bir tamsayı olarak serileştirilir.
numaralandırmadakiler, numaralandırmadaki öğelerin sayısı üst olarak
ciltli.

· Boş : serileştirme işlevi tanımlanmış olmasına rağmen boş değer kodlanmamıştır
şartname ve uygulama arasında daha net bir harita sağlamak için.

Sınıf, ns-3 Başlığından miras alır, ancak Deserialize() işlevi saf sanal olarak bildirilir,
bu nedenle miras alınan sınıflar onu uygulamak zorunda. Bunun nedeni, seri hale getirmenin
her biri farklı bilgiler içeren RRC mesajlarındaki öğeleri alın
elemanları.

Ek olarak, belirli bir türün/mesajın sonuç bayt uzunluğunun
isteğe bağlı alanların varlığına göre ve optimize edilmiş kodlama nedeniyle değişebilir.
Bu nedenle, serileştirilmiş bitler, PreSerialize() işlevi kullanılarak işlenecek ve
m_serializationResult Buffer ile sonuçlanır. Bir ns3 arabelleğinde okuma/yazma yöntemleri şu şekildedir:
bayt bazında tanımlanan seri hale getirme bitleri m_serializationPendingBits içinde depolanır
öznitelik, 8 bit ayarlanana ve tampon yineleyiciye yazılabilene kadar. Sonunda, ne zaman
Serialize() çağrılırken, m_serializationResult özniteliğinin içeriği kopyalanacak
Buffer::Iterator parametresine

RrcAsn1Başlık : ortak IE'ler
Bazı Bilgi Öğeleri birkaç RRC mesajı için kullanıldığından, bu sınıf
aşağıdaki ortak IE'leri uygular:

· SrbToAddModList

· DrbToAddModList

· Mantıksal Kanal Yapılandırması

· RadioResourceConfigAdanmış

· PhysicalConfigAdanmış

· Sistem BilgileriBlockType1

· Sistem BilgileriBlockType2

· RadioResourceConfigCommonSIB

Rrc özel mesajlar/IE'ler sınıflar
Aşağıdaki RRC SAP uygulanmıştır:

· RrcConnectionRequest

· RrcConnectionSetup

· RrcConnectionSetupTamamlandı

· RrcConnectionYeniden Yapılandırma

· RrcConnectionYeniden YapılandırmaTamamlandı

· Devir TeslimHazırlıkBilgisi

· RrcConnectionYeniden Kurulum İsteği

· RrcConnectionYeniden Kurulum

· RrcConnectionYeniden KurulumTamamlandı

· RrcConnectionYeniden KurulumReddet

· RrcConnectionRelease

NAS
LTE-EPC modelinin odak noktası, EMM'ye karşılık gelen NAS Aktif durumudur.
Kayıtlı, ECM bağlı ve RRC bağlı. Bundan dolayı aşağıdaki
sadeleştirmeler yapılır:

· EMM ve ECM açıkça modellenmemiştir; bunun yerine, UE'deki NAS varlığı
eşdeğer olan eylemleri gerçekleştirmek için doğrudan MME ile etkileşim kurun (brüt
basitleştirmeler) UE'yi EMM Bağlı ve ECM Bağlı durumlarına almak;

· NAS ayrıca üstten gelen çoklayıcı yukarı bağlantı veri paketleriyle de ilgilenir.
Traffic Flow Template sınıflandırıcısını kullanarak katmanları uygun EPS taşıyıcısına yerleştirin
(TftSınıflandırıcı).

· NAS, PLMN ve CSG seçimini desteklemiyor

· NAS, bekleme modunda herhangi bir konum güncelleme/çağrılama prosedürünü desteklemez

şekil Dizi diyagram of the iliştirmek prosedür basitleştirilmiş NAS modelinin nasıl olduğunu gösterir
ekleme prosedürünü uygular. Hem varsayılan hem de nihai ayrılmış EPS'nin
taşıyıcılar bu prosedürün bir parçası olarak etkinleştirilir.
[resim] Ekleme prosedürünün sıralama şeması.UNINDENT

S1
S1-U
S1-U arayüzü, veri paketlerini kapsülleyerek gerçekçi bir şekilde modellenmiştir.
Gerçek LTE-EPC sistemlerinde olduğu gibi GTP/UDP/IP. Karşılık gelen protokol yığını şu şekilde gösterilir:
şekil LTE-EPC veri düzlem protokol yığın. Şekilde görüldüğü gibi iki farklı
IP ağı katmanları. Birincisi, uçtan uca bilgi sağlayan uçtan uca katmandır.
kullanıcılara bağlantı; bu katmanlar UE'leri, PGW'yi ve uzak ana bilgisayarı içerir
(nihai internet yönlendiricileri ve aradaki ana bilgisayarlar dahil), ancak eNB'yi içermez.
Varsayılan olarak, UE'lere 4/7.0.0.0 ağında genel bir IPv8 adresi atanır ve PGW
tüm UE'ler tarafından internete erişim için ağ geçidi olarak kullanılan 7.0.0.1 adresini alır.

IP ağının ikinci katmanı, EPC yerel alan ağıdır. Bu, tüm eNB'leri içerir.
düğümleri ve SGW/PGW düğümü. Bu ağ, noktadan noktaya bağlantılar kümesi olarak uygulanmaktadır.
her eNB'yi SGW/PGW düğümüne bağlayan; bu nedenle, SGW/PGW'nin bir dizi
her biri farklı bir eNB'ye bağlantı sağlayan noktadan noktaya cihazlar. Varsayılan olarak bir
Her bir noktadan noktaya bağlantıya 10.xyz/30 alt ağı atanır (bir /30 alt ağı, en küçük
iki farklı ana bilgisayar adresine izin veren alt ağ).

3GPP tarafından belirtildiği gibi, uçtan uca IP iletişimleri, yerel EPC IP üzerinden tünellenir
GTP/UDP/IP kullanan ağ. Aşağıda, bu tünellemenin nasıl uygulandığını açıklıyoruz.
EPC modelinde. Açıklama, uçtan uca veri akışını tartışarak yapılır.
paketler.
[resim] İnternet ile UE.UNINDENT arasındaki aşağı bağlantıdaki veri akışı

Başlangıç ​​olarak, Şekil'de gösterilen aşağı bağlantı durumunu ele alıyoruz. Veri
akış in the downlink arasında the Internet ve the UE. Downlink Ipv4 paketleri
genel bir uzak ana bilgisayardan üretilir ve UE cihazından birine adreslenir. İnternet
yönlendirme, paketin SGW/PGW'nin genel NetDevice'ine iletilmesiyle ilgilenecektir.
internete bağlı düğüm (bu, 3GPP'ye göre Gi arayüzüdür)
terminoloji). SGW/PGW, ağ geçidi IP'si atanan bir VirtualNetDevice'e sahiptir.
UE alt ağının adresi; bu nedenle, statik yönlendirme kuralları gelen paketin
internetten bu VirtualNetDevice aracılığıyla yönlendirilecek. Böyle bir cihaz başlar
GTP/UDP/IP tünelleme prosedürü, paketi özel bir uygulamaya ileterek
EpcSgwPgwApplication olarak adlandırılan SGW/PGW düğümü. Bu uygulama,
aşağıdaki işlemler:

1. IP'ye bakarak UE'nin bağlı olduğu eNB düğümünü belirler.
hedef adresi (UE'nin adresidir);

2. Paketi Trafik Akışı Şablonlarını (TFT'ler) kullanarak hangisine göndereceğini belirlemek için sınıflandırır.
EPS Taşıyıcısına aittir. EPS taşıyıcılarının S1-U Taşıyıcılarına bire bir eşlemesi vardır, yani
bu işlem, GTP-U Tünel Bitiş Noktası Tanımlayıcısını (TEID) döndürür.
paket aittir;

3. ilgili GTP-U protokol başlığını pakete ekler;

4. Son olarak, paketi bir UDP soketi üzerinden S1-U noktadan noktaya gönderir.
NetDevice, UE'nin bağlı olduğu eNB'ye adreslenir.

Sonuç olarak, yeni eklenen IP, UDP ve GTP başlıklarına sahip uçtan uca IP paketi
yerel olarak alınıp teslim edildiği eNB'ye S1 bağlantılarından biri aracılığıyla gönderilir
(en dıştaki IP başlığının hedef adresi eNB IP adresiyle eşleştiği için). bu
yerel dağıtım işlemi, paketi bir UDP soketi aracılığıyla özel bir sunucuya iletecektir.
EpcEnbApplication adlı uygulama. Bu uygulama daha sonra aşağıdakileri gerçekleştirir
operasyonlar:

1. GTP başlığını kaldırır ve içinde bulunan TEID'yi alır;

2. S1-U taşıyıcıları ve Radyo Taşıyıcıları (ki bunlar
bir 3GPP gereksinimidir), paketin gönderileceği Taşıyıcı Kimliğini (BID) belirler.
aittir;

3. BID'i EpsBearerTag adı verilen özel bir etikete kaydeder.
paket;

4. paketi ham bir paket aracılığıyla eNB düğümünün LteEnbNetDevice cihazına iletir
soket

Bu noktada paketin en dıştaki başlığının uçtan uca IP başlığı olduğuna dikkat edin,
çünkü S1 protokol yığınının IP/UDP/GTP başlıkları zaten çıkarılmıştır. Üzerine
paketin EpcEnbApplication'dan alınması durumunda, LteEnbNetDevice
EpsBearerTag'den BID ve BID'ye dayalı olarak Radio Bearer örneğini belirleyecektir
(ve karşılık gelen PDCP ve RLC protokol örnekleri)
LTE radyo arabirimi üzerinden UE'ye paket. Son olarak, UE'nin LteUeNetDevice'i
paketi alır ve yerel olarak IP protokol yığınına iletir, bu da sırayla
aşağı bağlantının uç noktası olan UE'nin uygulamasına teslim edin
iletişim.
[resim] UE ile internet arasındaki yukarı bağlantıdaki veri akışı.UNINDENT

Yukarı bağlantı durumu Şekil'de tasvir edilmiştir. Veri akış in the uplink arasında the UE ve
the Internet. Uplink IP paketleri, UE içindeki jenerik bir uygulama tarafından üretilir,
ve yerel TCP/IP yığını tarafından UE'nin LteUeNetDevice cihazına iletilir. bu
LteUeNetDevice daha sonra aşağıdaki işlemleri gerçekleştirir:

1. TFT'leri kullanarak paketi sınıflandırır ve paketin gönderileceği Radyo Taşıyıcısını belirler.
paket ait (ve karşılık gelen RBID);

2. giriş noktası olan karşılık gelen PDCP protokolü örneğini tanımlar.
bu paket için LTE Radyo Protokolü yığını;

3. paketi LTE Radyo Protokol yığını üzerinden eNB'ye gönderir.

eNB, paketi LteEnbNetDevice aracılığıyla alır. Tek bir PDCP ve RLC olduğundan
her Radyo Taşıyıcısı için protokol örneği, LteEnbNetDevice BID'yi belirleyebilir
paketin. Bu BID daha sonra bir EpsBearerTag'e kaydedilir ve bu
paket. LteEnbNetDevice daha sonra paketi bir ham ağ üzerinden EpcEnbApplication'a iletir.
paket soketi.

Paketi aldıktan sonra, EpcEnbApplication aşağıdaki işlemleri gerçekleştirir:

1. BID'yi paketteki EpsBearerTag'den alır;

2. üzerinde yararlanarak karşılık gelen EPS Taşıyıcı örneğini ve GTP-U TEID'yi belirler.
S1-U taşıyıcıları ve Radyo Taşıyıcıları arasında bire bir eşleme;

3. önceden belirlenen TEID dahil olmak üzere pakete bir GTP-U başlığı ekler;

4. paketi S1-U'ya bağlı UDP soketi aracılığıyla SGW/PGW düğümüne gönderir.
noktadan noktaya ağ cihazı.

Bu noktada paket, S1-U IP, UDP ve GTP başlıklarını içerir.
orijinal uçtan uca IP başlığı. Paket karşılık gelen S1-U tarafından alındığında
SGW/PGW düğümünün noktadan noktaya NetDevice, yerel olarak teslim edilir (hedef olarak
en dıştaki IP başlığının adresi, noktadan noktaya ağ aygıtının adresiyle eşleşir).
Yerel teslim işlemi, paketi EpcSgwPgwApplication'a
karşılık gelen UDP soketi. EpcSgwPgwApplication daha sonra GTP başlığını kaldırır ve iletir
paketi VirtualNetDevice'e gönderin. Bu noktada, paketin en dıştaki başlığı
uçtan uca IP başlığı. Dolayısıyla, bu başlıktaki hedef adres bir uzak adres ise
İnternette barındırılan paket, ilgili NetDevice aracılığıyla internete gönderilir.
SGW/PGW'nin. Paketin başka bir UE'ye adreslenmesi durumunda, IP yığını
SGW/PGW, paketi tekrar VirtualNetDevice'e yönlendirecek ve paket
hedef UE'ye ulaşmak için alt bağlantı teslim süreci aracılığıyla.

EPS Bearer QoS'nin S1-U bağlantılarında uygulanmadığına dikkat edin;
bağlantı bant genişliğinin aşırı sağlanması, tümünün QoS gereksinimlerini karşılamak için yeterlidir.
taşıyıcılar

S1AP
S1-AP arabirimi, eNB ile MME arasında kontrol düzlemi etkileşimi sağlar. İçinde
simülatör, bu arayüz ideal bir şekilde modellenmiştir ve aralarında doğrudan etkileşim vardır.
S1AP mesajlarının kodlamasını fiilen uygulamadan eNB ve MME nesneleri
ve [TS36413]'te belirtilen ve fiilen herhangi bir PDU iletmeden bilgi öğeleri
herhangi bir bağlantıda.

Modellenen S1-AP ilkelleri şunlardır:

· İLK UE MESAJI

· İLK BAĞLAM KURULUM İSTEĞİ

· İLK BAĞLAM KURULUMU TEPKİSİ

· YOL DEĞİŞTİRME İSTEĞİ

· YOL DEĞİŞTİRME İSTEĞİ ONAYI

X2
X2 arabirimi iki eNB'yi [TS36420] birbirine bağlar. Mantıksal bir bakış açısından, X2
arayüz, iki eNB arasında noktadan noktaya bir arayüzdür. Gerçek bir E-UTRAN'da,
mantıksal noktadan noktaya arabirim, fiziksel bir bağlantının yokluğunda bile uygulanabilir olmalıdır.
iki eNB arasında doğrudan bağlantı. Simülatörde uygulanan X2 modelinde,
X2 arayüzü, iki eNB arasında noktadan noktaya bir bağlantıdır. Noktadan noktaya bir cihaz
hem eNB'lerde oluşturulur hem de iki noktadan noktaya cihaz noktadan noktaya bağlanır
bağlantı.

X2 arabiriminin LENA'nın genel mimarisine nasıl uyduğunun bir temsili için
Simülasyon modelinde, okuyucu şekle yönlendirilir. Genel Bakış of the LTE-EPC simülasyon
model.

Simülatörde uygulanan X2 arayüzü,
Mobilite Yönetimi işlevi [TS36423] için aşağıdaki temel prosedürler:

· Devir Teslim Talebi prosedürü

· Devir Teslim Talebi Onay prosedürü

· SN Durum Aktarım prosedürü

· UE Bağlam Yayınlama prosedürü

Bu prosedürler, X2 tabanlı aktarımda yer alır. detaylı bulabilirsiniz
[TS10.1.2.1] bölüm 36300'de geçişin açıklaması. Simülatörün
model şu anda yalnızca sorunsuz teslim et Bölüm 2.6.3.1'de tanımlandığı gibi
[Sesia2009]; özellikle, kayıpsız teslim et Bölüm 2.6.3.2'de açıklandığı gibi
[Sesia2009] bu yazının yazıldığı tarihte desteklenmemektedir.

şekil Dizi diyagram of the X2 tabanlı teslim et etkileşimi aşağıda gösterilmektedir.
simülatördeki X2 modelinin varlıkları. Gölgeli etiketler,
UE veya eNodeB başka bir RRC durumuna geçiş.
[resim] X2 tabanlı geçişin sıralama şeması.UNINDENT

Şekil aynı zamanda geçiş prosedüründeki iki zamanlayıcıyı da göstermektedir: teslim et ayrılma
kronometre eNodeB kaynağı tarafından korunurken, teslim et birleştirme kronometre hedef tarafından
eNodeB. Zamanlayıcıların süresi,
Devir TeslimAyrılmaZaman AşımıSüresi ve Devir TeslimKatılmaZaman AşımıSüresi özellikleri
bu LteEnbRrc örnekler. Bu zamanlayıcılardan birinin süresi dolduğunda, geçiş prosedürü
başarısız sayılır.

Bununla birlikte, LTE'nin mevcut sürümünde geçiş hatasının uygun şekilde ele alınması yoktur.
modül. Aktarma hatasını önlemek için kullanıcılar simülasyonu uygun şekilde ayarlamalıdır,
aksi halde beklenmeyen davranışlar meydana gelebilir. Lütfen Bölüme bakın
bununla ilgili bazı ipuçları için Kullanıcı Dokümantasyonunun sec-tuning-devr-simülasyonu
madde.

X2 modeli, aşağıdakilerden hizmetleri kullanan bir varlıktır:

· X2 arayüzleri,

· Noktadan noktaya cihazların üzerinde Soket olarak uygulanmaktadır.

· X2-C ve X2-U arayüzleri aracılığıyla X2 mesajları göndermek/almak için kullanılırlar.
(yani noktadan noktaya bağlantıya bağlı noktadan noktaya cihaz)
eş eNB.

· S1 uygulaması.

· Şu anda EpcEnbApplication'dır.

· X2'nin Temel Prosedürleri için gerekli olan bazı bilgileri almak için kullanılır.
mesajları.

ve aşağıdakilere hizmet sağlar:

· RRC varlığı (X2 SAP)

· RRC mesajlarını göndermek/almak için. X2 varlığı, RRC mesajını şeffaf olarak gönderir.
X2 mesajındaki kapsayıcı. Bu RRC mesajı UE'ye gönderilir.

şekil Uygulama Model of X2 varlık ve SAP'ler X2'nin uygulama modelini gösterir
varlık ve onun protokoldeki diğer tüm varlıklar ve hizmetlerle olan ilişkisi
yığını.
[resim] X2 varlığı ve SAPs.UNINDENT'in Uygulama Modeli

RRC kuruluşu devir teslim prosedürünün başlatılmasını yönetir. Bu yapılır
eNB RRC varlığının Aktarım Yönetimi alt modülü. Hedef eNB bazı performanslar gösterebilir.
Kabul Kontrol prosedürleri. Bu, Kabul Kontrolü alt modülünde yapılır.
Başlangıçta, bu alt modül herhangi bir geçiş talebini kabul edecektir.

X2 arayüzler
X2 modeli iki arayüz içerir:

· X2-C arayüzü. Kontrol arayüzüdür ve X2-AP PDU'ları göndermek için kullanılır.
(yani temel prosedürler).

· X2-U arayüzü. Var olduğunda taşıyıcı verilerini göndermek için kullanılır. DL nakliye.

şekil X2 arayüzey protokol yığınlar X2-U arabiriminin protokol yığınlarını gösterir ve
Simülatörde modellenen X2-C arayüzü.
[resim] X2 arayüzü protokol yığınları.UNINDENT

X2-C
X2-C arayüzü, X2 arayüzünün kontrol kısmıdır ve göndermek için kullanılır.
X2-AP PDU'lar (yani temel prosedürler).

Orijinal X2 arayüzü kontrol düzlemi protokol yığınında, aktarım olarak SCTP kullanılır.
protokolü ancak şu anda SCTP protokolü ns-3 simülatöründe modellenmemiştir ve
uygulama proje kapsamı dışındadır. Datagram olarak UDP protokolü kullanılır.
SCTP protokolü yerine yönlendirilmiş protokol.

X2-U
X2-U arabirimi, taşıyıcı verilerini göndermek için kullanılır. DL nakliye süresince
X2 tabanlı aktarım prosedürünün yürütülmesi. S1-U için yapılanlara benzer şekilde
arayüz, veri paketleri bu üzerinden gönderilirken GTP/UDP/IP üzerinden kapsüllenir
arayüz. EPS Taşıyıcı QoS'nin X2-U bağlantılarında uygulanmadığına dikkat edin.
bağlantı bant genişliğinin aşırı sağlanmasının QoS gereksinimlerini karşılamak için yeterli olduğunu
tüm taşıyıcıların.

X2 Hizmet arayüzey
X2 hizmet arabirimi, X2'nin mesajlarını göndermek ve almak için RRC varlığı tarafından kullanılır.
prosedürler. İki bölüme ayrılmıştır:

· NS EpcX2Sap Sağlayıcı kısmı, X2 varlığı tarafından sağlanır ve RRC varlığı tarafından kullanılır ve

· NS EpcX2Sap Kullanıcısı kısmı, RRC varlığı tarafından sağlanır ve RRC varlığı tarafından kullanılır.

X2-C modelimizde desteklenen ilkel öğeler aşağıda açıklanmıştır.
alt bölümler.

X2-C ilkel için teslim et infaz
X2 tabanlı geçiş için aşağıdaki ilkel öğeler kullanılır:

· DEVİR TALEBİ

· DEVİR İSTEĞİ ACK

· DEVİR HAZIRLIK HATASI

· SN DURUM AKTARIMI

· UE BAĞLAM YAYINI

yukarıdaki tüm ilkel öğeler, şu anda uygulanmakta olan RRC modeli tarafından kullanılır.
devir teslim prosedürünün hazırlanması ve yürütülmesi. Kullanımları RRC ile etkileşime girer
durum makinesi; bu nedenle, en azından kod özelleştirme için kullanılmaları amaçlanmamıştır.
RRC durum makinesini değiştirmek istenmediği sürece.

X2-C SON ilkel
Kendi Kendini Organize Eden Ağı (SON) uygulamak için aşağıdaki ilkel öğeler kullanılabilir
işlevler:

· YÜK BİLGİSİ

· KAYNAK DURUMU GÜNCELLEME

mevcut RRC modelinin aslında bu ilkelleri kullanmadığına dikkat edin, bunlar dahil edilmiştir.
modelde sadece RRC mantığında yer alan SON algoritmalarını geliştirmeyi mümkün kılmak için
onlardan yararlanan.

İlk örnek olarak, burada ilkel yük bilgisinin nasıl kullanılabileceğini gösteriyoruz. Farz ediyoruz
LteEnbRrc'nin aşağıdaki yeni üye değişkenleri içerecek şekilde değiştirildiği:

std::vektör
m_currentUlInterferenceOverloadIndicationList;
std::vektör
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

bu değişkenlerin türlerinin ayrıntılı bir açıklaması için dosyaya başvurmanızı öneririz.
epc-x2-sap.h, ilgili doxygen belgeleri ve buradaki referanslar
3GPP TS 36.423'ün ilgili bölümleri. Şimdi, çalışma zamanında bu değişkenlerin
belirtilen spesifikasyonları takiben anlamlı değerlere ayarlanmıştır. O zaman yapabilirsin
bir yük göndermek için LteEnbRrc sınıf uygulamasında aşağıdaki kodu ekleyin
bilgi ilkel:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicationList = m_currentUlInterferenceOverloadIndicationList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams parametreleri;
params.targetCellId = hücreKimliği;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (paramlar);

Yukarıdaki kod, kaynak eNB'nin mesajı göndermesine izin verir. yöntem
LteEnbRrc::DoRecvLoadInformation hedef eNB mesajı aldığında aranacaktır.
Bu nedenle, yük bilgilerinin istenen şekilde işlenmesi bu kapsamda gerçekleştirilmelidir.
yöntemi.

Aşağıdaki ikinci örnekte, kaynak durum güncelleme ilkelinin nasıl kullanıldığını gösteriyoruz.
LteEnbRrc'nin aşağıdaki yeni üyeyi içerecek şekilde değiştirildiğini varsayıyoruz
değişken:

EpcX2Sap::CellMeasurementResultItem m_cmri;

öncekine benzer şekilde, atıfta bulunduğumuz epc-x2-sap.h ve ayrıntılı bilgi için buradaki referanslar
Bu değişken türü hakkında bilgi. Yine, değişkenin zaten var olduğunu varsayıyoruz.
anlamlı bir değere ayarlayın. Ardından, göndermek için aşağıdaki kodu ekleyebilirsiniz.
kaynak durum güncellemesi:

EpcX2Sap::ResourceStatusUpdateParams parametreleri;
params.targetCellId = hücreKimliği;
params.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate (paramlar);

Gibi bir yöntem eEnbRrc::DoRecvResourceStatusUpdate hedef eNB aldığında çağrılacak
kaynak durumu güncelleme mesajı. Bu mesajın istenen işlenmesi,
bu nedenle bu yöntem içinde uygulanacaktır.

Son olarak, uygun değerlerin ayarlanması ve işlenmesinin
yukarıda açıklanan ilkel öğelere iletilen değişkenin SON'a özgü olduğu kabul edilir
algoritma uygulanmaktadır ve bu nedenle bu dokümantasyon kapsamında değildir.

desteksiz ilkel
Radyo Bağlantı Arızası göstergesi ve
Devir Teslim Raporu bu aşamada desteklenmez.

S11
S11 arabirimi, SGW ile MME arasında kontrol düzlemi etkileşimi sağlar.
[TS2]'te belirtilen GTPv29274-C protokolü. Simülatörde, bu arayüz bir
SGW ve MME nesneleri arasında doğrudan etkileşim ile ideal moda, olmadan
aslında mesajların kodlamasını uygulamak ve aslında herhangi bir şey iletmeden
Herhangi bir bağlantıda PDU.

Modellenen S11 ilkelleri şunlardır:

· OTURUM İSTEĞİ OLUŞTUR

· OTURUM YANITINI OLUŞTUR

· HAMİL İSTEĞİNİ DEĞİŞTİRİN

· TAŞIYICI TEPKİSİNİ DEĞİŞTİRİN

Bu ilkel öğelerden ilk ikisi, ilk UE eki üzerine kullanılır.
S1-U taşıyıcılarının oluşturulması; diğer ikisi geçiş sırasında geçiş yapmak için kullanılır.
tarafından alımın bir sonucu olarak kaynak eNB'den hedef eNB'ye S1-U taşıyıcıları
bir PATH SWITCH REQUEST S1-AP mesajının MME'si.

Power Control
Bu bölüm, Downlink ve Uplink Güç Kontrolünün ns-3 uygulamasını açıklamaktadır.

downlink Power Control
Frekans Yeniden Kullanım Algoritmalarından bazıları Downlink Güç Kontrolü gerektirdiğinden, bu özellik
ayrıca ns-3'te uygulandı.
[resim] Downlink Güç Kontrolünün dizi diyagramı.UNINDENT

şekil Dizi diyagram of downlink Power Control ayarın sıra diyagramını gösterir
UE için aşağı bağlantı P_A değeri, RRC ile diğer arasındaki etkileşimleri vurgular
varlıklar. FR algoritması, UE için P_A değerlerini değiştirmek üzere RRC'yi tetikler. Ardından RRC başlar
UE'yi yeni yapılandırma hakkında bilgilendirmek için RrcConnectionReconfiguration işlevi. Sonrasında
başarılı RrcConnectionReconfiguration, RRC, UE için P_A değerini çağırarak ayarlayabilir
CphySap'ten SetPa işlevi, değer, P_A değerlerini içeren yeni m_paMap haritasına kaydedilir
eNb tarafından sunulan her UE için.

LteEnbPhy yeni alt çerçeve başlattığında, DCI kontrol mesajları, vektörünü almak için işlenir.
kullanılan RB'ler Artık GeneratePowerAllocationMap(uint16_t rnti, int rbId) işlevi de
isminde. Bu işlev, UE için P_A değerini kontrol eder, her RB için güç üretir ve onu depolar.
m_dlPowerAllocationMap. Sonra bu harita tarafından kullanılır
Ptr oluşturmak için CreateTxPowerSpectralDensityWithPowerAllocation işlevi
txPsd.

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) eklendi.
RrcConnectionReconfiguration'da kullanılan LteRrcSap::PhysicalConfigDedicated yapı
proses.

Uplink Power Control
Yukarı bağlantı güç kontrolü, farklı yukarı bağlantı fiziksel bağlantılarının iletim gücünü kontrol eder.
kanallar. Bu işlevsellik, 3GPP TS 36.213 bölüm 5'te açıklanmaktadır.

Uplink Güç Kontrolü varsayılan olarak etkindir ve öznitelik sistemi tarafından devre dışı bırakılabilir:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (yanlış));

İki Uplink Güç Kontrolü mekanizması uygulanmaktadır:

· Açık Döngü Yukarı Bağlantı Güç Kontrolü: UE iletim gücü,
aşağı bağlantı yol kaybı ve kanal konfigürasyonu

· Kapalı Döngü Uplink Güç Kontrolü: Açık Döngüde olduğu gibi, ek olarak eNB, UE'yi kontrol edebilir
açık İletim Gücü Kontrolü TPC komutları aracılığıyla iletim gücü
aşağı bağlantıda iletilir.

Bu iki mekanizma tipi arasında geçiş yapmak için parametre değiştirilmelidir:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (doğru));

Varsayılan olarak, Kapalı Çevrim Güç Kontrolü etkindir.

İki modları of Kapalı döngü Uplink Power Control vardır Mevcut:

· Mutlak mod: TxPower, mutlak TPC değerleriyle hesaplanır

· Birikimli mod: TxPower, birikmiş TPC değerleriyle hesaplanır

Bu iki mod arasında geçiş yapmak için parametre değiştirilmelidir:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (doğru));

Varsayılan olarak, Biriktirme Modu etkindir ve DL-DCI'daki TPC komutları, herkes tarafından ayarlanır.
zamanlayıcılar 1'e, Birikim Modunda 0 değerine eşlenen değer.

Uplink Power Control için PUŞ
Bir Fiziksel Yukarı Bağlantı Paylaşımlı Kanalı (PUSCH) için UE İletim gücünün ayarı
iletim aşağıdaki gibi tanımlanır:

· UE, hizmet veren hücre c için eşzamanlı bir PUCCH olmadan PUSCH iletirse, o zaman
alt çerçeve i'deki PUSCH iletimi için UE iletim gücü P_{PUSCH,c}(i)
servis hücresi c şu şekilde verilir:

· UE, hizmet veren hücre c için PUCCH ile eş zamanlı olarak PUSCH iletirse, o zaman UE
alt çerçeve i'deki PUSCH iletimi için iletim gücü P_{PUSCH,c}(i)
servis hücresi c şu şekilde verilir:

PUCCH için Uplink Güç Kontrolü uygulanmadığından, bu durum uygulanmaz
gibi.

· UE, hizmet veren c hücresi için PUSCH göndermiyorsa,
PUSCH için DCI formatı 3/3A ile alınan TPC komutu, UE, UE'nin
alt çerçeve i'deki PUSCH iletimi için iletim gücü P_{PUSCH,c}(i)
hizmet veren hücre c şu şekilde hesaplanır:

nerede:

· P_{CMAX,c}(i), 3GPP 36.101'de tanımlanan yapılandırılmış UE iletim gücüdür. Masa
6.2.2-1 c hücresine hizmet için i alt çerçevesinde ve {P}_{CMAX,c}(i) lineer değerdir
P_{CMAX,c}(i)'nin. P_{CMAX,c}(i) için varsayılan değer 23 dBm'dir

· M_{PUSCH,c}(i), PUSCH kaynak atamasının şu şekilde ifade edilen bant genişliğidir:
i alt çerçevesi ve c hücresi için geçerli olan kaynak bloğu sayısı.

· P_{O_PUSCH,c}(j), bir bileşenin toplamından oluşan bir parametredir
P_{O_NOMINAL_PUSCH,c}(j), j={0,1} ve bir bileşen için daha yüksek katmanlardan sağlandı
P_{O_UE_PUSCH,c}(j), c hücresi için j={0,1} için üst katmanlar tarafından sağlanır.
SIB2 mesajının bu iki bileşeni taşıyacak şekilde genişletilmesi gerekiyor, ancak şu anda
öznitelik sistemi aracılığıyla ayarlanabilirler:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::SetDefault ("ns3::LteUePowerControl::PoUePusch", IntegerValue (7));

· lpha_{c} (j), ightinForelj=3 için daha yüksek katmanlar tarafından sağlanan 2 bitlik bir parametredir,
t 0,1, 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9'de j=1, lpha_c için
lpha_{c} (j) = 1. Bu parametre, öznitelik sistemi tarafından yapılandırılabilir:

Config::SetDefault ("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c}, c hücresine hizmet vermek için UE'de hesaplanan aşağı bağlantı yol kaybı tahminidir
dB ve PL_{c} = referenceSignalPower – daha yüksek katman filtreli RSRP, burada
referenceSignalPower, daha yüksek katmanlar ve RSRP tarafından sağlanır. referansSignalPower
SIB2 mesajında ​​sağlanır

· ve koşul durumu uygulanır.

· f_{c}(i), Kapalı Çevrim Güç Kontrolünün bileşenidir. Mevcut PUSCH gücüdür.
hizmet veren hücre için kontrol ayarlama durumu c.

Biriktirme Modu etkinleştirilirse f_{c}(i) şu şekilde verilir:

burada: elta_{PUSCH,c}, TPC komutu olarak da adlandırılan bir düzeltme değeridir
ve DCI ile PDCCH'ye dahildir; elta_{PUSCH,c}(i - K_{PUSCH}) sinyali verildi
Alt çerçevede hücre c'ye hizmet vermek için DCI ile PDCCH/EPDCCH (i - K_{PUSCH}); K_{İTME} =
FDD için 4.

UE, c hücresine hizmet vermek için P_{CMAX,c}(i)'ye ulaştıysa, pozitif TPC komutları
hizmet veren c hücresi birikmez. UE minimum güce ulaştıysa, negatif
TPC komutları birikmez. Minimum UE gücü TS36.101'de tanımlanmıştır
bölüm 6.2.3. Varsayılan değer -40 dBm'dir.

Biriktirme Modu etkinleştirilmemişse f_{c}(i) şu şekilde verilir:

burada: elta_{PUSCH,c}, TPC komutu olarak da adlandırılan bir düzeltme değeridir
ve DCI ile PDCCH'ye dahildir; elta_{PUSCH,c}(i - K_{PUSCH}) sinyali verildi
Alt çerçevede hücre c'ye hizmet vermek için DCI ile PDCCH/EPDCCH (i - K_{PUSCH}); K_{İTME} =
FDD için 4.

DCI formatında 0/3/4 TPC Komut Alanının mutlak ve birikmiş olarak eşlenmesi
elta_{PUSCH,c} değerleri TS36.231 bölüm 5.1.1.1'de tanımlanmıştır Tablo 5.1.1.1-2

Uplink Power Control için PUÇ
Tüm yer-uydu hattı kontrol mesajları ideal mesajlar olduğundan ve herhangi bir radyoyu tüketmediğinden
kaynakları, PUCCH için Uplink Güç Kontrolü gerekli değildir ve uygulanmaz.

Uplink Power Control için SRS
i alt çerçevesinde iletilen SRS için UE İletim gücü P_{SRS} ayarı
hizmet veren hücre c şu şekilde tanımlanır:

nerede:

· P_{CMAX,c}(i), 3GPP 36.101'de tanımlanan yapılandırılmış UE iletim gücüdür. Masa
6.2.2-1. P_{CMAX,c}(i) için varsayılan değer 23 dBm'dir

· P_{SRS_OFFSET,c}(m), m=0,1 için daha yüksek katmanlar tarafından yarı statik olarak yapılandırılmıştır.
hizmet veren hücre c . SRS iletimi için tetikleme tipi 0, ardından m=0,1 ve SRS için
tetikleme tipi 1 verildiğinde iletim, ardından m=1. K_{s} = 0 için P_Srs_Offset_Value
denklem ile hesaplanır:

Bu parametre, öznitelik sistemi tarafından yapılandırılabilir:

Config::SetDefault ("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c}, hizmet veren hücre için i alt çerçevesindeki SRS iletiminin bant genişliğidir
c, kaynak bloğu sayısı olarak ifade edilir. Mevcut uygulamada SRS gönderilir
tüm UL bant genişliği boyunca.

· f_{c}(i), c hücresine hizmet vermek için geçerli PUSCH güç kontrolü ayarlama durumudur,
tanımlandığı gibi Uplink Power Control için PUŞ

· P_{O_PUSCH,c}(j) ve lpha_{c}(j), içinde tanımlandığı gibi parametrelerdir. Uplink Power
Control için PUŞ, burada j = 1 .

kesirli Sıklık Yeniden
Genel Bakış
Bu bölümde, Kesirli Frekans Yeniden Kullanım algoritmaları için ns-3 desteği açıklanmaktadır. Tüm
uygulanan algoritmalar [ASHamza2013]'te açıklanmıştır. Şu anda 7 FR algoritması
uygulandı:

· ns3::LteFrNoOpAlgoritma

· ns3::LteFrHardAlgoritma

· ns3::LteFrStrictAlgoritma

· ns3::LteFrSoftAlgoritma

· ns3::LteFfrSoftAlgoritma

· ns3::LteFfrGelişmişAlgoritma

· ns3::LteFfrDistributedAlgoritma

Yeni LteFfrAlgorithm sınıfı oluşturuldu ve Frekans Yeniden Kullanımı için soyut bir sınıftır.
algoritmaların uygulanması. Ayrıca FR-Scheduler ve FR-RRC arasında iki yeni SAP eklendi.
[resim] FR algoritması ile Programlamanın sıralama diyagramı.UNINDENT

şekil Dizi diyagram of Çizelgeleme ile FR algoritma dizi diyagramını gösterir
FR algoritması ile zamanlama işlemi. Çizelgeleme sürecinin başlangıcında, zamanlayıcı
FR kuruluşundan mevcut RBG'leri ister. Uygulamaya göre FR, tüm RBG'leri döndürür
hücrede kullanılabilir veya politikasına göre filtreleyin. Sonra biraz atamaya çalışırken
RBG'den UE'ye, zamanlayıcı FR varlığına bu UE için bu RBG'ye izin verilip verilmediğini sorar. FR döndüğünde
true, programlayıcı başka bir RBG'yi kontrol etmiyorsa, programlayıcı bu RBG'yi bu UE'ye atayabilir
bu UE için. Yine FR yanıtı, uygulamaya ve UE'ye uygulanan politikaya bağlıdır.

destekli FR algoritmalar
Yok hayır Sıklık Yeniden
NoOp FR algoritması (LteFrNoOpAlgorithm sınıfı), Tam Frekans Yeniden Kullanımının uygulanmasıdır
bu, aynı ağın eNB'leri arasında hiçbir frekans bölümlemesinin yapılmadığı anlamına gelir
(frekans yeniden kullanım faktörü, FRF 1'e eşittir). eNB'ler tüm sistem bant genişliğini kullanır ve iletir
tüm RBG'ler üzerinde tek tip güç ile. Bu en basit şemadır ve temel yoldur.
bir LTE ağının işletilmesi. Bu şema, yüksek tepe veri hızına ulaşılmasını sağlar. Ancak
Öte yandan, komşu hücrelerden gelen yoğun girişim seviyeleri nedeniyle, hücre kenarı
kullanıcı performansı büyük ölçüde sınırlıdır.

şekil Her Şey Dahil Sıklık Yeniden plan aşağıda Tam için frekans ve güç planı sunulmaktadır
Frekans Yeniden Kullanım şeması.
[resim] Tam Frekans Yeniden Kullanım şeması.UNINDENT

ns-3'te, NoOp FR algoritması her zaman planlayıcının tam bant genişliğini kullanmasına izin verir ve
tüm UE'ler herhangi bir RBG'yi kullanabilir. Basitçe yeni bir şey yapmaz (yani eNB'yi sınırlamaz)
bant genişliği, FR algoritması devre dışı), FrAlgorithm'in en basit uygulamasıdır.
class ve varsayılan olarak eNb'de kuruludur.

Zor Sıklık Yeniden
Sabit Frekans Yeniden Kullanım algoritması, azaltmayı sağlayan en basit şemayı sağlar.
hücreler arası girişim seviyesi. Bu şemada, tüm frekans bant genişliği bölünür
birkaç (tipik olarak 3, 4 veya 7) ayrık alt bant. Bitişik eNB'ler farklı
alt bant. Frekans yeniden kullanım faktörü, alt bantların sayısına eşittir. Bu şema şunları sağlar:
hücre kenarındaki ICI'yi önemli ölçüde azaltır, böylece hücre kullanıcılarının performansı artar.
Ancak, her eNB'nin tüm bant genişliğinin yalnızca bir bölümünü kullanması nedeniyle, en yüksek veri hızı
seviyesi ayrıca yeniden kullanım faktörüne eşit olan faktör kadar azaltılır.

şekil Zor Sıklık Yeniden plan aşağıda Zor için frekans ve güç planı sunulmaktadır
Frekans Yeniden Kullanım şeması.
[resim] Sabit Frekans Yeniden Kullanım şeması.UNINDENT

Bizim uygulamamızda, Sabit FR algoritması yalnızca eNB için kullanılabilen RBG'lerin vektörüne sahiptir.
ve zamanlama işlevleri sırasında MAC Zamanlayıcıya iletin. Zamanlayıcı sorduğunda, RBG
belirli UE için izin verilirse, her zaman doğru döndürür.

Sıkı Sıklık Yeniden
Kesin Frekans Yeniden Kullanım şeması, Tam ve Sabit Frekans Yeniden Kullanım şemalarının birleşimidir. BT
sistem bant genişliğini farklı olacak iki parçaya bölmekten oluşur
frekans yeniden kullanımı Sistem bant genişliğinin ortak bir alt bandı, her bir hücrenin iç kısmında kullanılır.
(frekans yeniden kullanımı-1), bant genişliğinin diğer kısmı ise
oluşturmak için sabit frekans yeniden kullanımında (frekans yeniden kullanımı-N, N>1) olduğu gibi komşu eNB'ler
her sektörde düşük hücreler arası girişim düzeyine sahip bir alt bant. Merkez UE'ler
tamamen yeniden kullanılan frekans yığınları ile verilirken, ortogonal yığınlara sahip hücre kenarındaki UE'ler.
Bu, bir hücredeki iç UE'lerin, diğer hücreden gelen uç UE'lerle herhangi bir spektrumu paylaşmadığı anlamına gelir.
her ikisi için girişimi azaltan ikinci hücre. Fark edilebileceği gibi, Strict FR bir
toplam N + 1 alt bant ve 1 ile 3 arasında ortada RFR elde edilmesini sağlar.

şekil Sıkı Sıklık Yeniden plan Aşağıda Strict için frekans ve güç planı sunulmaktadır
Hücre kenarı yeniden kullanım faktörü N = 3 olan Frekans Yeniden Kullanım şeması.
[resim] Katı Frekans Yeniden Kullanım şeması.UNINDENT

Uygulamamızda, Strict FR algoritmasının her bir alt bant için bir tane olmak üzere iki haritası vardır. eğer UE
özel alt bant içinde sunulabilir, RNTI m_privateSubBandUe haritasına eklenir. Eğer
UE, ortak alt bant içinde sunulabilir, RNTI'si m_commonSubBandUe haritasına eklenir.
Sıkı FR algoritmasının, hangi alt bant UE'nin sunulması gerektiğine karar vermesi gerekir. kullanır
RRB tarafından sağlanan UE ölçümleri ve bunları sinyal kalitesi eşiğiyle karşılaştırın (bu
parametre, öznitelik mekanizması tarafından kolayca ayarlanabilir). Eşik üzerinde etkisi vardır
iç hücre yarıçapı oranı.

Yumuşak Sıklık Yeniden
Yumuşak Frekans Yeniden Kullanım (SFR) şemasında, her eNb tüm sistem bant genişliği üzerinden iletir,
ancak iki alt bant vardır, UE'ler içinde farklı güç seviyelerinde hizmet verilir. O zamandan beri
hücre merkezi UE'ler, bant genişliğini komşu hücrelerle paylaşırlar, genellikle daha düşük hızlarda iletirler.
hücre kenarındaki UE'lerden daha fazla güç seviyesi. SFR, Strict FR'den daha fazla bant genişliği verimlidir,
çünkü tüm sistem bant genişliğini kullanır, ancak aynı zamanda her ikisinde de daha fazla parazite neden olur.
hücre içi ve kenar kullanıcıları.

SFR şemasının iki olası versiyonu vardır:

· İlk versiyonda, hücre kenarı UE'ler için ayrılan alt bant,
hücre merkezi UE'leri, ancak azaltılmış güç seviyesiyle ve yalnızca
hücre kenarı UE'ler. Hücre merkezi alt bandı yalnızca merkez UE'ler tarafından kullanılabilir. Figür
Yumuşak Sıklık Yeniden plan versiyon 1 aşağıda frekans ve güç planı sunulmaktadır
Esnek Frekans Yeniden Kullanım şemasının bu versiyonu.
[resim] Esnek Frekans Yeniden Kullanım şeması sürüm 1.UNINDENT

· İkinci versiyonda, hücre merkezi UE'lerinin hücre kenarı alt bandına erişimi yoktur. İçinde
bu şekilde, her bir hücre tüm sistem bant genişliğini kullanırken,
Komşu hücrelere müdahale. Öte yandan, daha düşük ICI seviyesi
hücre kenarı, daha düşük spektrum kullanımı pahasına elde edilir. Figür Yumuşak
Sıklık Yeniden plan versiyon 2 aşağıda bunun için frekans ve güç planı sunulmaktadır
Esnek Frekans Yeniden Kullanım şemasının sürümü.
[resim] Esnek Frekans Yeniden Kullanım şeması sürüm 2.UNINDENT

SFR algoritması iki haritayı korur. UE'ye daha düşük güç seviyesinde hizmet verilmesi gerekiyorsa,
RNTI, m_lowPowerSubBandUe haritasına eklenir. UE'ye daha yüksek güçle hizmet verilmesi gerekiyorsa
düzeyinde, RNTI'si m_highPowerSubBandUe haritasına eklenir. Hangi güç seviyesine karar vermek için
UE sunulmalıdır SFR algoritması UE ölçümlerini kullanır ve bunları karşılaştırır
eşik. İç için sinyal kalitesi eşiği ve PdschConfigDedicated (yani P_A değeri)
ve dış alan nitelikler sistemi tarafından yapılandırılabilir. SFR, Downlink Gücünü kullanır
Burada açıklanan kontrol.

Yumuşak kesirli Sıklık Yeniden
Yumuşak Kesirli Frekans Yeniden Kullanımı (SFFR), Katı ve Yumuşak Frekansın bir kombinasyonudur
Şemaları yeniden kullanın. Strict FR ise dış bölge için ayrılan alt bantları kullanmaz.
bitişik hücrelerde, yumuşak FFR bu alt bantları düşük iletim gücüne sahip iç UE'ler için kullanır. Gibi
Sonuç olarak, SFFR, SFR gibi, yüksek iletim gücü seviyesi ve düşük
güç seviyesi iletir. Soft FR ve Strict FR'den farklı olarak Soft FFR, ortak
iç kullanıcıların verimini artırabilen alt bant.

şekil Yumuşak kesirli kesirli Sıklık Yeniden plan Aşağıda frekans ve
Yumuşak Kesirli Frekansın Yeniden Kullanımı için güç planı.
[resim] Yumuşak Kesirli Kesirli Frekans Yeniden Kullanım şeması.UNINDENT

geliştirilmiş kesirli Sıklık Yeniden
[ZXie2009]'da açıklanan Geliştirilmiş Kesirli Frekans Yeniden Kullanımı (EFFR), 3 hücre tipini tanımlar
bir hücresel sistemdeki doğrudan komşu hücreler için ve her hücre tipi için rezervler
adlı tüm frekans bandının bir parçası Birincil Bölüm, farklı tip hücreler arasında hangisi
ortogonal olmalıdır. Kalan alt kanallar, ikincil Bölüm.
Birincil Bölüm bir hücre tipinin aynı zamanda bir parçasıdır. ikincil Segmentler
diğer iki hücre tipine aittir. Her hücre kendi alt kanallarının tümünü işgal edebilir. Birincil
Bölüm isteğe bağlı olarak, oysa alt kanalların yalnızca bir kısmı ikincil Bölüm kullanılabilir
girişime duyarlı bir şekilde bu hücre tarafından. Birincil Bölüm her hücre bölünür
bir yeniden kullanım-3 parçasına ve yeniden-1 parçasına. Yeniden kullanım-1 kısmı, tüm hücre türleri tarafından yeniden kullanılabilir
sistemde, yeniden kullanım-3 kısmı ise yalnızca aynı türden diğer kişiler tarafından özel olarak yeniden kullanılabilir.
hücreler (yani yeniden kullanım-3 alt kanalları, doğrudan komşu hücreler tarafından yeniden kullanılamaz). Açık
the ikincil Bölüm hücre misafir gibi davranır ve ikincil alt kanalları işgal eder.
doğrudan komşu hücrelere ait birincil alt kanalları fiilen yeniden kullanın, böylece
yeniden kullanım ikincil Bölüm her hücre tarafından iki kurala uymalıdır:

· kullanmadan önce izleyin

· SINR tahminine dayalı olarak kaynakların yeniden kullanımı

Her hücre her zaman her ikincil alt kanalı dinler. Ve işgalden önce,
toplanan kanal kalite bilgilerine (CQI) göre SINR değerlendirmesi yapar ve
yeniden kullanım için en iyi tahmin değerlerine sahip kaynakları seçer. RBG için CQI değeri yukarıda ise
bazı kullanıcılar için yapılandırılmış eşik, bu kullanıcı için iletim bu kullanılarak gerçekleştirilebilir
RBG.

[ZXie2009]'da planlama süreci açıklanmaktadır, üç adımdan ve iki
zamanlama politikaları Halihazırda uygulanan planlayıcıların hiçbiri buna izin vermediğinden
davranış, bazı basitleştirmeler uygulandı. Bizim uygulamamızda yeniden kullanım-1 alt kanalları şunları yapabilir:
yalnızca hücre merkezi kullanıcıları tarafından kullanılabilir. Yeniden kullanım-3 alt kanalları uç kullanıcılar tarafından kullanılabilir ve yalnızca
uç kullanıcı yoksa, hücre merkezi kullanıcıları için iletim yeniden kullanım-3'te sunulabilir
alt kanallar.

şekil geliştirilmiş kesirli kesirli Sıklık Yeniden plan Aşağıda frekans ve
Gelişmiş Kesirli Frekans Yeniden Kullanımı için güç planı.
[resim] Gelişmiş Kesirli Kesirli Frekans Yeniden Kullanım şeması.UNINDENT

Dağıtılmış kesirli Sıklık Yeniden
Bu Dağıtılmış Kesirli Frekans Yeniden Kullanım Algoritması [DKimura2012]'de sunulmuştur. BT
kullanıcı dağıtımına odaklanarak hücre kenarı alt bantlarını otomatik olarak optimize eder (
özellikle, alma gücü dağıtımı). Bu algoritma uyarlamalı olarak RB'leri aşağıdakiler için seçer:
bitişik hücrelerden gelen koordinasyon bilgilerine dayalı olarak hücre kenarı alt bandı ve bildirimleri
kenar alt bandında kullanmak için seçtiği RB'ler olan bitişik hücrelerin baz istasyonları.
Her bir hücrenin baz istasyonu, alınan bilgileri ve aşağıdaki denklemi kullanır.
her RB için hücre-kenar bandı metriğini A_{k} hesapla.

burada J, bir dizi komşu hücredir, X_{j,k}=0,1, j'inci komşu hücreden gelen RNTP'dir.
j'inci komşu hücredeki k'inci RB hücre kenarı olarak kullanıldığında 1 değerini alır.
alt bant ve aksi takdirde 0. w_{j} sembolü, komşu j hücresine göre ağırlığı belirtir,
yani, sinyalin gücü arasındaki farkın olduğu kullanıcı sayısı
hizmet veren i hücresinden alınan sinyalin gücü ve komşu hücreden alınan sinyalin gücü
j hücresi bir eşik değerinden (yani, hücre kenarına yakın kullanıcı sayısı) küçüktür.
hizmet hücresi). Büyük bir alınan güç farkı, i.
hücre, j'inci hücreden güçlü girişime maruz kalır.

A_{k} metriğinin en küçük olduğu RB'nin aşağıdakilerden en az etkilendiği kabul edilir
başka bir hücreden müdahale Hizmet veren hücre, yapılandırılan sayıda RB'yi şu şekilde seçer:
A_{k} artan sırada hücre kenarı alt bandı. Sonuç olarak, içinde küçük olan RB'ler
bitişik baz istasyonlarından yüksek parazit alan hücre ucu kullanıcılarının sayısı
Seçilen.

Güncellenen RNTP daha sonra tüm komşu hücrelere gönderilir. Anlamsızdan kaçınmak için
hücre kenar bandı seçiminin salınımı, bir baz istasyonu başka bir bazdan gelen bir RNTP'yi yok sayar
baz istasyonundan daha büyük hücre kimliğine sahip istasyon.

Bu işlemin tüm hücrelerde tekrarlanması, RB'lerin hücre kenarındaki alanlara tahsis edilmesini sağlar.
sistem üzerinden optimize edilmek ve kullanıcı dağılımındaki değişikliklere göre uyarlanmak.

şekil Dizi diyagram of Dağıtılmış Sıklık Yeniden plan aşağıda sırayı sunar
Dağıtılmış Kesirli Frekans Yeniden Kullanım Şemasının diyagramı.
[resim] Dağıtılmış Frekans Yeniden Kullanım Planının dizi diyagramı.UNINDENT

Yardımcılar
Simülasyonları kurmak ve çeşitli bileşenleri yapılandırmak için iki yardımcı nesne kullanılır.
Bu nesneler:

· LteHelper, LTE radyo erişim ağının yapılandırmasını şu şekilde halleder:
EPS taşıyıcılarının kurulumunu ve serbest bırakılmasını koordine etmenin yanı sıra. bu LteHelper sınıf
hem API tanımını hem de uygulamasını sağlar.

· EpcYardımcı, Gelişmiş Paket Çekirdeğinin yapılandırmasıyla ilgilenir. bu
EpcYardımcı class, yalnızca API tanımını sağlayan soyut bir temel sınıftır; the
uygulama, farklı EPC'lere izin vermek için alt sınıflara devredilmiştir.
ağ modelleri.

kullanarak basit bir yalnızca LTE simülasyonları oluşturmak mümkündür. LteHelper tek başına veya
her ikisini de kullanarak eksiksiz LTE-EPC simülasyonları oluşturun LteHelper ve EpcYardımcı. her ikisi de
yardımcılar kullanılır, efendi-köle tarzında etkileşime girerler, LteHelper Usta olmak
doğrudan kullanıcı programıyla etkileşime giren ve EpcYardımcı "kaputun altında" çalışmak
tarafından çağrılan açık yöntemler üzerine EPC'yi yapılandırın. LteHelper. Kesin etkileşimler
Şekilde görüntülenen Dizi diyagram of the etkileşim arasında LteHelper ve
EpcYardımcı.
[resim] LteHelper ve EpcHelper.UNINDENT arasındaki etkileşimin sıralama diyagramı

kullanıcı Dökümanlar
Olayın Arka Planı
Okuyucunun jenerik çalıştırmak için ns-3 simülatörünün nasıl kullanılacağına zaten aşina olduğunu varsayıyoruz.
simülasyon programları. Durum böyle değilse, okuyucunun danışmasını şiddetle tavsiye ederiz.
[ns3öğretici].

kullanım Genel Bakış
ns-3 LTE modeli, LTE ağlarının simülasyonuna izin veren bir yazılım kütüphanesidir.
isteğe bağlı olarak Evolved Packet Core (EPC) dahil. Bu tür gerçekleştirme süreci
simülasyonlar tipik olarak aşağıdaki adımları içerir:

1. Tanımlama the senaryo simüle edilecek

2. Yazmak a simülasyon program istenen senaryoyu yeniden yaratan
topoloji/mimari. Bu, kullanılarak ns-3 LTE model kitaplığına erişilerek yapılır.
ns3::LteHelper API tanımlanmış src/lte/helper/lte-helper.h.

3. Belirtmek yapılandırma parametreler için kullanılan nesnelerin
simülasyon. Bu, girdi dosyaları kullanılarak yapılabilir (üzerinden ns3::ConfigStore) Veya
doğrudan simülasyon programı içinde.

4. yapılandırma the İstediğiniz çıktı simülatör tarafından üretilecek

5. koşmak simülasyon.

Tüm bu yönler aşağıdaki bölümlerde uygulamalı olarak açıklanacaktır.
örnekleri.

Basic simülasyon program
İşte sadece LTE simülasyonu yapmak için gereken minimum simülasyon programı
(EPC'siz).

1. İlk standart:

#katmak
#katmak
#katmak
#katmak

ns3 ad alanını kullanma;

int ana (int argc, karakter *argv[])
{
// simülasyon programının geri kalanı aşağıdaki gibidir

2. Bir LteHelper nesne:

puan lteHelper = Nesne Oluştur ();

Bu, bazı yaygın nesneleri (örn., Kanal nesnesi) başlatacak ve
eNB'leri ve UE'leri ekleme ve yapılandırma yöntemleri.

3. yaratmak Düğüm eNB(ler) ve UE'ler için nesneler:

NodeContainer enbNode'lar;
enbNodes.Create (1);
NodeContainer ueNode'lar;
ueNodes.Create (2);

Bu noktada yukarıdaki Düğüm örneklerinin hala bir LTE protokolüne sahip olmadığını unutmayın.
yüklü yığın; onlar sadece boş düğümler.

4. Tüm düğümler için Mobilite modelini yapılandırın:

MobiliteYardımcı mobilite;
hareketlilik.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
hareketlilik.Yükle (enbNodes);
hareketlilik.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobilite.Install (ueNodes);

Yukarıdaki, tüm düğümleri (0,0,0) koordinatlarına yerleştirecektir. Lütfen şuraya bakın:
kendi konumunuzu nasıl ayarlayacağınıza veya yapılandıracağınıza ilişkin ns-3 mobilite modelinin belgeleri
düğüm hareketi.

5. eNB'lere bir LTE protokol yığını kurun:

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. UE'lere bir LTE protokol yığını kurun:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. UE'leri bir eNB'ye takın. Bu, her UE'yi eNB'ye göre yapılandıracaktır.
yapılandırın ve aralarında bir RRC bağlantısı oluşturun:

lteHelper->Attach (ueDevs, enbDevs.Get (0));

8. Her bir UE ile bağlı olduğu eNB arasında bir veri radyo taşıyıcısını etkinleştirin:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer taşıyıcı (q);
lteHelper->ActivateDataRadioBearer (ueDevs, taşıyıcı);

bu yöntem ayrıca o taşıyıcı için iki doygunluk trafik oluşturucusunu etkinleştirir, biri
yukarı bağlantıda ve bir aşağı bağlantıda.

9. Durdurma zamanını ayarlayın:

Simülatör::Dur (Saniye (0.005));

Bu gereklidir, aksi takdirde simülasyon sonsuza kadar sürer, çünkü (diğerlerinin yanı sıra)
alt çerçeve başlangıcı olayı tekrar tekrar planlanır ve ns-3 simülatörü programlayıcı
dolayısıyla olaylar asla bitmez.

10. Simülasyonu çalıştırın:

Simülatör::Çalıştır ();

11. Temizleme ve çıkış:

Simülatör::Yok Et ();
0 dönmek;
}

Simülasyon programlarının nasıl derleneceği ve çalıştırılacağı konusunda lütfen [ns3tutorial]'a bakın.

yapılandırma of LTE model parametreler
İlgili tüm LTE modeli parametreleri, ns-3 öznitelik sistemi aracılığıyla yönetilir.
Tüm uygulamalar hakkında ayrıntılı bilgi için lütfen [ns3tutorial] ve [ns3manual]'a bakın.
bunu yapmak için olası yöntemler (çevresel değişkenler, C++ API, GtkConfigStore...).

Aşağıda, giriş dosyalarını kullanarak nasıl yapılacağını kısaca özetliyoruz.
ns-3 ConfigStore. Her şeyden önce, simülasyonunuza aşağıdakileri koymanız gerekir.
programı, hemen ardından ana () başlar:

Komut satırı cmd'si;
cmd.Ayrıştır (argc, argv);
ConfigStore girişiConfig;
inputConfig.ConfigureDefaults ();
// komut satırından varsayılan değerleri geçersiz kılabilmeniz için tekrar ayrıştırın
cmd.Ayrıştır (argc, argv);

yukarıdakilerin çalışması için, şunları da yaptığınızdan emin olun: #Dahil etmek "ns3/config-store.h". Şimdi bir oluştur
adlı metin dosyası (örneğin) input-defaults.txt yeni varsayılan değerlerin belirtilmesi
bazı özellikler için kullanmak istiyorsunuz:

varsayılan ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
varsayılan ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
varsayılan ns3::LteEnbNetDevice::UlBandwidth "25"
varsayılan ns3::LteEnbNetDevice::DlBandwidth "25"
varsayılan ns3::LteEnbNetDevice::DlEarfcn "100"
varsayılan ns3::LteEnbNetDevice::UlEarfcn "18100"
varsayılan ns3::LteUePhy::TxPower "10"
varsayılan ns3::LteUePhy::Noise Figure "9"
varsayılan ns3::LteEnbPhy::TxPower "30"
varsayılan ns3::LteEnbPhy::Noise Figure "5"

Diyelim ki simülasyon programınızın adı src/lte/examples/lte-sim-ile-giriş, Yapabilirsiniz
şimdi bu ayarları aşağıdaki şekilde simülasyon programına iletin:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lte-sim-with-input

Ayrıca, aşağıdaki komutla bir şablon girdi dosyası oluşturabilirsiniz:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Kaydet --ns3::ConfigStore::FileFormat=RawText" --run src/lte/examples/lte-sim-with-input

yukarıdakilerin dosyaya ekleneceğini unutmayın input-defaults.txt herşey varsayılan değerler
LTE olmayan çok sayıda dahil olmak üzere, simülatörün kendi yapınıza kayıtlıdır.
Öznitellikler.

yapılandırma LTE MAC Zamanlayıcı
Kullanıcının burada seçebileceği birkaç LTE MAC zamanlayıcı türü vardır. Kullanıcı aşağıdakileri kullanabilir
zamanlayıcı tipini tanımlayan kodlar:

puan lteHelper = Nesne Oluştur ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // FD-MT zamanlayıcı
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // TD-MT zamanlayıcı
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // TTA zamanlayıcı
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // FD-BET zamanlayıcı
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // TD-BET zamanlayıcı
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // FD-TBFQ zamanlayıcı
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // TD-TBFQ zamanlayıcı
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); //PSS planlayıcı

TBFQ ve PSS, diğer zamanlayıcılardan daha fazla parametreye sahiptir. Kullanıcılar bu parametreleri tanımlayabilir
şu şekilde:

* TBFQ zamanlayıcı::

puan lteHelper = Nesne Oluştur ();
lteHelper->SetSchedulerAttribute("BorçLimit", IntegerValue(yourvalue)); // varsayılan değer -625000 bayt (-5Mb)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(yourvalue)); // varsayılan değer 625000 bayt (5Mb)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(yourvalue)); // varsayılan değer 1 bayt
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(yourvalue)); // varsayılan değer 0

* PSS zamanlayıcı::

puan lteHelper = Nesne Oluştur ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(yourvalue)); // TD zamanlayıcı tarafından seçilen maksimum UE sayısı
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // PSS'de PF zamanlayıcı türü

TBFQ'da borç limiti ve kredi limitinin varsayılan değerleri -5Mb ve 5Mb olarak ayarlanmıştır.
sırasıyla kağıt temelinde [FABokhari2009]. Mevcut uygulama dikkate almıyor
kredi eşiği (C = 0). PSS'de, kullanıcı nMux'u tanımlamazsa, PSS bu değeri olarak ayarlayacaktır.
toplam UE'nin yarısı. Varsayılan FD zamanlayıcısı PFsch'dir.

Ek olarak, TBFQ'da belirteç oluşturma hızı ve PSS'de hedef bit hızının olması gerekir.
epc taşıyıcı QoS'de Garanti Bit Hızı (GBR) veya Maksimum Bit Hızı (MBR) tarafından yapılandırılmış
parametreler. Kullanıcılar hem downlinkte hem de downlinkte GBR ve MBR tanımlamak için aşağıdaki kodları kullanabilirler.
yukarı bağlantı:

puan lteHelper = Nesne Oluştur ();
enum EpsBearer::Qci q = EpsBearer::yourvalue; // Qci tipini tanımla
GbrQosInformation qos;
qos.gbrDl = değeriniz; // Aşağı bağlantı GBR'si
qos.gbrUl = değeriniz; // Yukarı bağlantı GBR
qos.mbrDl = değeriniz; // Aşağı bağlantı MBR'si
qos.mbrUl = değeriniz; // Yukarı bağlantı MBR'si
EpsBearer taşıyıcı (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, taşıyıcı, EpcTft::Default ());

PSS'de TBR, taşıyıcı seviye QoS parametrelerinde GBR'den elde edilir. TBFQ'da belirteç oluşturma
oranı, taşıyıcı seviyesi QoS parametrelerindeki MBR ayarından elde edilir, bu nedenle
tutarlı bir şekilde yapılandırılması gerekir. Sabit bit hızı (CBR) trafiği için önerilir
MBR'yi GBR olarak ayarlamak için. Varyans bit hızı (VBR) trafiği için MBR k kez ayarlanması önerilir
en yüksek trafik oranını karşılamak için GBR'den daha büyük. Mevcut uygulamada, k
kağıda dayalı olarak üçe ayarlayın [FABokhari2009]. Ayrıca, TBFQ'nun mevcut sürümü
MBR ve GBR'de RLC başlığını ve PDCP başlığı uzunluğunu göz önünde bulundurun. TBFQ'daki diğer bir parametre ise
paket varış hızı Bu parametre programlayıcı içinde hesaplanır ve geçmişe eşittir.
PF zamanlayıcıda kullanılan ortalama verim.

LTE-EPC modelinin birçok yararlı özelliği aşağıda açıklanacaktır.
alt bölümler. Yine de, ayette açıkça belirtilmeyen birçok özellik vardır.
tasarım veya kullanıcı belgeleri, ancak ns-3 özniteliği kullanılarak açıkça belgelenenler
sistem. Belirli bir nesnenin özniteliklerinin bir listesini aşağıdakilerle birlikte kolayca yazdırabilirsiniz:
açıklamaları ve varsayılan değer geçişi --PrintAttributes= bir simülasyon programına,
bunun gibi:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

Bunun gibi diğer LTE ve EPC nesneleri ile de deneyebilirsiniz:

./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"

Simulation Çıktı
ns-3 LTE modeli şu anda PHY, MAC, RLC ve PDCP seviyesinin dosyaya çıktısını desteklemektedir.
Temel Performans Göstergeleri (KPI'lar). Aşağıdaki şekilde etkinleştirebilirsiniz:

puan lteHelper = Nesne Oluştur ();

// tüm simülasyon senaryosunu burada yapılandırın...

lteHelper->EnablePhyTraces ();
lteHelper->EnableMacTraces ();
lteHelper->EnableRlcTraces ();
lteHelper->EnablePdcpTraces ();

Simülatör::Çalıştır ();

RLC ve PDCP KPI'ları, bir zaman aralığında hesaplanır ve ASCII dosyalarında depolanır;
RLC KPI'ları ve ikisi PDCP KPI'ları için, her durumda bir yukarı bağlantı ve bir aşağı bağlantı için. Zaman
aralık süresi, öznitelik kullanılarak kontrol edilebilir
ns3::RadioBearerStatsCalculator::EpochDuration.

RLC KPI dosyalarının sütunları aşağıdaki gibidir (yukarı bağlantı ve aşağı bağlantı için aynıdır):

1. Simülasyonun başlangıcından bu yana saniye cinsinden ölçüm aralığının başlama zamanı

2. simülasyonun başlangıcından bu yana saniye cinsinden ölçüm aralığının bitiş zamanı

3. Hücre Kimliği

4. benzersiz UE Kimliği (IMSI)

5. hücreye özgü UE Kimliği (RNTI)

6. Mantıksal Kanal Kimliği

7. İletilen RLC PDU sayısı

8. Aktarılan toplam bayt sayısı.

9. Alınan RLC PDU sayısı

10. Alınan toplam bayt sayısı

11. Saniye cinsinden ortalama RLC PDU gecikmesi

12. RLC PDU gecikmesinin standart sapması

13. RLC PDU gecikmesinin minimum değeri

14. RLC PDU gecikmesinin maksimum değeri

15. Bayt cinsinden ortalama RLC PDU boyutu

16. RLC PDU boyutunun standart sapması

17. Minimum RLC PDU boyutu

18. Maksimum RLC PDU boyutu

Benzer şekilde, PDCP KPI dosyalarının sütunları aşağıdaki gibidir (yine yukarı bağlantı için aynı
ve aşağı bağlantı):

1. Simülasyonun başlangıcından bu yana saniye cinsinden ölçüm aralığının başlama zamanı

2. simülasyonun başlangıcından bu yana saniye cinsinden ölçüm aralığının bitiş zamanı

3. Hücre Kimliği

4. benzersiz UE Kimliği (IMSI)

5. hücreye özgü UE Kimliği (RNTI)

6. Mantıksal Kanal Kimliği

7. İletilen PDCP PDU sayısı

8. Aktarılan toplam bayt sayısı.

9. Alınan PDCP PDU sayısı

10. Alınan toplam bayt sayısı

11. Saniye cinsinden ortalama PDCP PDU gecikmesi

12. PDCP PDU gecikmesinin standart sapması

13. PDCP PDU gecikmesinin minimum değeri

14. PDCP PDU gecikmesinin maksimum değeri

15. Bayt cinsinden ortalama PDCP PDU boyutu

16. PDCP PDU boyutunun standart sapması

17. Minimum PDCP PDU boyutu

18. Maksimum PDCP PDU boyutu

MAC KPI'ları temel olarak planlayıcı tarafından raporlanan kaynak tahsisinin bir izidir.
her alt çerçevenin başlangıcı. ASCII dosyalarında saklanırlar. Aşağı bağlantı MAC KPI'ları için
biçimi aşağıdaki gibidir:

1. Tahsisatın programlayıcı tarafından gösterildiği saniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4. Çerçeve numarası

5. Alt çerçeve numarası

6. hücreye özgü UE Kimliği (RNTI)

7. TB 1'in MCS'si

8. TB 1 boyutu

9. TB 2'nin MCS'si (mevcut değilse 0)

10. TB 2 boyutu (yoksa 0)

yukarı bağlantı MAC KPI'ları için format şu şekildedir:

1. Tahsisatın programlayıcı tarafından gösterildiği saniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4. Çerçeve numarası

5. Alt çerçeve numarası

6. hücreye özgü UE Kimliği (RNTI)

7. TB'nin MCS'si

8. tüberküloz boyutu

MAC KPI çıktısı için kullanılan dosyaların adları, ns-3 öznitelikleriyle özelleştirilebilir.
ns3::MacStatsCalculator::DlOutputFilename ve ns3::MacStatsCalculator::UlOutputFilename.

PHY KPI'ları, nitelikler aracılığıyla yapılandırılabilen yedi farklı dosyaya dağıtılır

1. ns3::PhyStatsCalculator::DlRsrpSinrDosyaadı

2. ns3::PhyStatsCalculator::UeSinrDosyaadı

3. ns3::PhyStatsCalculator::InterferenceFilename

4. ns3::PhyStatsCalculator::DlTxOutputFilename

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

RSRP/SINR dosyasında aşağıdaki içerik mevcuttur:

1. Tahsisatın programlayıcı tarafından gösterildiği saniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4. LCV

5. Aşağı bağlantı SINR'sinin tüm RB'leri üzerinden lineer birimlerde lineer ortalama

UE SINR dosyasındaki içerikler şunlardır:

1. Tahsisatın programlayıcı tarafından gösterildiği saniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4. UE için lineer birimlerde yukarı bağlantı SINR'si

Girişim dosya adında içerik şöyledir:

1. Tahsisatın programlayıcı tarafından gösterildiği saniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. RB başına girişim değerleri listesi

UL ve DL iletim dosyalarında dahil edilen parametreler şunlardır:

1. Milisaniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4.RNTI

5. İletim katmanı

6. MU

7. TB'nin boyutu

8. Fazlalık versiyonu

9. Yeni Veri Göstergesi bayrağı

Ve son olarak, UL ve DL alım dosyalarında dahil edilen parametreler şunlardır:

1. Milisaniye cinsinden simülasyon süresi

2. Hücre Kimliği

3. benzersiz UE Kimliği (IMSI)

4.RNTI

5. İletim Modu

6. İletim katmanı

7. MU

8. TB'nin boyutu

9. Fazlalık versiyonu

10. Yeni Veri Göstergesi bayrağı

11. TB alımında doğruluk

solan Iz kullanım
Bu bölümde, LTE simülasyonlarında solma izlerinin nasıl kullanılacağını açıklayacağız.

solan İzler nesil
Sağlanan özel bir matlab komut dosyası kullanarak solma izleri oluşturmak mümkündür.
kod (/lte/model/fading-traces/fading-trace-generator.m). Bu komut dosyası zaten içeriyor
üç 3GPP senaryosu için tipik bağlantı yapılandırmaları (örn. yaya, araç ve
[TS2] Ek B.36104'de tanımlandığı gibi kentsel); ancak kullanıcılar ayrıca kendi
belirli yapılandırmalar. Yapılandırılabilir parametrelerin listesi,
Aşağıdaki:

· fc : kullanımdaki frekans (doppler hızının hesaplanmasını etkiler).

· v_km_h : kullanıcıların hızı

· izleme süresi : izin toplam uzunluğunun saniye cinsinden süresi.

· numRB'ler : değerlendirilecek kaynak bloğunun numarası.

· etiket : oluşturulan dosyaya uygulanacak etiket.

Oluşturulan dosya, matris biçiminde düzenlenmiş ASCII biçimli gerçek değerleri içerir:
her satır farklı bir RB'ye karşılık gelir ve her sütun farklı bir RB'ye karşılık gelir
zamansal solma iz örneği.

ns-3 LTE modülünün herhangi bir solma izleme dosyasıyla çalışabileceğine dikkat edilmelidir.
yukarıda açıklanan ASCII formatıyla uyumludur. Bu nedenle, diğer harici araçlar
örneğin diğer simülatörler veya
deneysel cihazlar.

solan İzler kullanım
Bir solma izi kullanırken, izin doğru bir şekilde belirtilmesi çok önemlidir.
Simülasyondaki parametreler, böylece sönümleme modeli onu doğru bir şekilde yükleyebilir ve kullanabilir. bu
yapılandırılacak parametreler şunlardır:

· İz Dosyaadı : yüklenecek izlemenin adı (mutlak yol veya göreli yol
wrt simülasyon programının yürütüldüğü yol);

· İzleme Uzunluğu : saniye cinsinden izleme süresi;

· Numune Sayısı : numune sayısı;

· Pencere boyutu : saniye cinsinden solma örnekleme penceresinin boyutu;

Solma izinin örnekleme aralığının 1 ms olması gerektiğini vurgulamak önemlidir.
veya daha büyük ve ikinci durumda olması için 1 ms'nin tam sayı katı olması gerekir.
Fading modülü tarafından doğru şekilde işlenir.

Matlab betiğinin varsayılan yapılandırması, 10 saniye uzunluğunda bir izleme sağlar.
10,000 örnek (yani, TTI=1ms başına 1 örnek) ve 0.5 saniyelik bir pencere boyutunda kullanılır
genlik. Bunlar aynı zamanda yukarıda kullanılan parametrelerin varsayılan değerleridir.
simülatör; bu nedenle solma izinin onlara uyması durumunda oturmalarından kaçınılabilir.

Soldurma modülünü (varsayılan olarak etkin olmayan) etkinleştirmek için aşağıdaki kod
simülasyon programına dahil edilmelidir:

puan lteHelper = Nesne Oluştur ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

Ve parametreleri ayarlamak için:

lteHelper->SetFadingModelAttribute ("TraceFilename", StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength", TimeValue (Saniye (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("WindowSize", TimeValue (Saniye (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum", UintegerValue (100));

Unutulmamalıdır ki, İz Dosyaadı varsayılan bir değeri yoktur, bu nedenle
her zaman açıkça ayarlanmalıdır.

Simülatör, yerel olarak aşağıdakilere göre üretilen üç solma izi sağlar:
[TS2] Ek B.36104'de tanımlanan konfigürasyonlar. Bu izler şu adreste mevcuttur:
dosya src/lte/model/fading-traces/). Bu izlerden bir alıntı şu şekilde temsil edilir:
aşağıdaki rakamlar.
[resim: Fading trace 3 kmph] [resim]
bir yaya senaryosu için simülatör (hız 3 kmph)..UNINDENT
[resim: Fading trace 60 kmph] [resim]
bir araç senaryosu için simülatör (hız 60 kmph)..UNINDENT
[resim: Fading trace 3 kmph] [resim]
kentsel bir senaryo için simülatör (hız 3 kmph)..UNINDENT

Hareketlilik Model ile Binalar
Şimdi binalar modelinin nasıl kullanılacağını örneklerle açıklıyoruz (özellikle
MobiliteBina Bilgisi ve BinaYayılımModeli sınıflar) bir ns-3 simülasyonunda
Binaları ve iç mekan düğümlerini içeren bir LTE simülasyon senaryosu kurmak için program.

1. Dahil edilecek başlık dosyaları:

#katmak
#katmak
#katmak

2. Pathloss model seçimi:

puan lteHelper = Nesne Oluştur ();

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::BuildingsPropagationLossModel"));

3. EUTRA Bant Seçimi

Yayılma modelinin çalışma frekansının seçimi,
ilgili bölümde açıklandığı gibi standart ns-3 öznitelik sistemi ("Yapılandırma
LTE modeli parametreleri") örneğin DlEarfcn ve UlEarfcn parametreleri aracılığıyla:

lteHelper->SetEnbDeviceAttribute ("DlEarfcn", UintegerValue (100));
lteHelper->SetEnbDeviceAttribute ("UlEarfcn", UintegerValue (18100));

tarafından kullanılan frekansı yapılandırmak için başka araçların kullanılmasına dikkat edilmelidir.
yayılım modeli (yani ilgili BuildingsPropagationLossModel'in yapılandırılması)
doğrudan öznitelikler) frekans tanımında çakışmalar oluşturabilir.
simülasyon sırasında modüller ve bu nedenle tavsiye edilmez.

1. Mobilite modeli seçimi:

MobiliteYardımcı mobilite;
hareketlilik.SetMobilityModel ("ns3::ConstantPositionMobilityModel");

Herhangi bir mobilite modelinin kullanılabileceğine dikkat edilmelidir.

2. Bina oluşturma:

çift ​​x_min = 0.0;
çift ​​x_maks = 10.0;
çift ​​y_min = 0.0;
çift ​​y_max = 20.0;
çift ​​z_min = 0.0;
çift ​​z_max = 10.0;
Ptr b = OluşturNesne ();
b->Sınırları Ayarla (Kutu (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Bina::Konut);
b->SetExtWallsType (Bina::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRoomsX (3);
b->Odaları AyarlaY (2);

Bu, 10 x 20 metrelik bir tabana ve
Dış duvarları beton pencereli 10 metre; binanın üç
katlar ve eşit büyüklükte odalardan oluşan 3 x 2 dahili ızgaraya sahiptir.

3. Düğüm oluşturma ve konumlandırma:

ueNodes.Create (2);
mobilite.Install (ueNodes);
BuildingsHelper::Kur (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0)->GetObject ();
Ptr mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (Vektör (5.0, 5.0, 1.5));
mm1->SetPosition (Vektör (30.0, 40.0, 1.5));

4. Bina ve mobilite modeli yapılandırmasını sonlandırın:

BuildingsHelper::MakeMobilityModelConsistent ();

belgelerine bakın binalar Daha detaylı bilgi için modül.

PHY Hata Model
Fiziksel hata modeli, veri hatası modeli ve aşağı bağlantı kontrol hatasından oluşur
model, her ikisi de varsayılan olarak etkindir. Bunları ns3 ile devre dışı bırakmak mümkündür.
öznitelik sistemi, ayrıntılı olarak:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (yanlış));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (yanlış));

MIMO Model
Bu alt bölümde MIMO parametrelerinin nasıl yapılandırılacağını gösteriyoruz. LTE 7 tip tanımlar
iletim modları:

· İletim Modu 1: SISO.

· İletim Modu 2: MIMO Tx Çeşitliliği.

· İletim Modu 3: MIMO Mekansal Çokluk Açık Çevrim.

· İletim Modu 4: MIMO Mekansal Çokluk Kapalı Çevrim.

· İletim Modu 5: MIMO Çoklu Kullanıcı.

· İletim Modu 6: Daha yakın döngü tek katmanlı ön kodlama.

· İletim Modu 7: Tek anten bağlantı noktası 5.

Uygulanan modele göre, simülatör ilk üç iletim modunu içerir.
türleri. Varsayılan, İletim Modu 1'dir (SISO). Varsayılanı değiştirmek için
Kullanılacak İletim Modu, öznitelik Varsayılan İletim Modu arasında LteEnbRrc yapabilmek
aşağıda gösterildiği gibi kullanılmalıdır:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // SISO
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // MIMO Tx çeşitliliği (1 katman)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // MIMO Mekansal Çokluk (2 katman)

Simülasyon sırasında belirli bir kullanıcının iletim modunu değiştirmek için belirli bir
arayüz her iki standart planlayıcıda da uygulanmıştır:

void TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

Bu yöntem hem iletim modu karar motorunu geliştirmek için kullanılabilir (örn.
iletim modunun kanal durumuna ve/veya kullanıcının durumuna göre optimize edilmesi
gereksinimler) ve simülasyon komut dosyasından manuel geçiş için. İkinci durumda,
anahtarlama aşağıda gösterildiği gibi yapılabilir:

Puan lteEnbDev = enbDevs.Get (0)->GetObject ();
İşaretçiDeğer değeri;
enbNetDev->GetAttribute ("FfMacScheduler", ptrval);
Puan rrsched = ptrval.Get ();
Simulator::Schedule (Saniye (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

Son olarak, uygulanan model farklı MIMO modellerine göre yeniden yapılandırılabilir.
kazanç değerlerinin güncellenmesi (tek kısıtlama, kazancın sabit olması gerektiğidir.
simülasyon çalışma zamanı ve katmanlar için ortak). Her İletim Modunun kazancı şu şekilde olabilir:
standart ns3 öznitelik sistemine göre değiştirildi, burada öznitelikler:
TxMode1Kazanç, TxMode2Kazanç, TxMode3Kazanç, TxMode4Kazanç, TxMode5Kazanç, TxMode6Kazanç ve
TxMode7Kazanç. yalnızca varsayılan olarak TxMode1Kazanç, TxMode2Kazanç ve TxMode3Kazanç anlamlı olmak
_[CatreuxMIMO] tarafından türetilen değerlerdir (yani, sırasıyla 0.0, 4.2 ve -2.8
dB).

Kullanım of AntenModeli
Modellemek için belirli bir AntennaModel'i bir eNB cihazıyla nasıl ilişkilendireceğimizi gösteriyoruz.
bir makro eNB'nin sektörü. Bu amaçla, kullanımı uygundur. KosinüsAntenModel
ns-3 anten modülü tarafından sağlanır. eNB'nin konfigürasyonu,
LteHelper örneğinin oluşturulmasından hemen önce EnbNetDevice, gösterildiği gibi
Aşağıdaki:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute ("Yönlendirme", DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("Beamwidth", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute ("MaxGain", DoubleValue (0.0));

yukarıdaki kod, 60 derece ışın genişliğine sahip bir anten modeli oluşturacaktır.
X ekseni. Oryantasyon, X ekseninden derece cinsinden ölçülür, örneğin bir oryantasyon
90, Y ekseni boyunca işaret eder ve -90 yönlendirmesi negatifi gösterir
Y ekseni boyunca yön. Hüzme genişliği -3 dB huzme genişliğidir, örneğin 60 derecelik bir açı için
ışın genişliği m açısında anten kazancı
Oryantasyon yönünden 30 derece -3 dB'dir.

Çok sektörlü bir site oluşturmak için aynı yere yerleştirilmiş farklı ns-3 düğümleri oluşturmanız gerekir.
pozisyon ve ayrı yapılandırmak için EnbNetDevice farklı anten yönelimleri ile
her düğümde yüklü

radyo çevre Haritalar
Sınıfı kullanarak RadioEnvironmentMapHelper bir dosyaya bir Radyo çıktısı almak mümkündür
Ortam Haritası (REM), örn.
En güçlü eNB'ye göre aşağı bağlantıdaki sinyal-gürültü oranı
her noktada sinyal REM'in veri için mi yoksa
kontrol kanalı. Ayrıca kullanıcı, kendisi için REM'in üretileceği RbId'yi ayarlayabilir. Varsayılan RbId
-1'dir, bu, REM'in tüm cihazlardan ortalama Sinyal-gürültü oranıyla üretileceği anlamına gelir.
RB'ler.

Bunun için simülasyon programınıza aşağıdaki kodu eklemeniz yeterlidir.
bitiş, Simulator::Run () çağrısından hemen önce:

Puan remHelper = YaratObject ();
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 (doğru));
remHelper->SetAttribute ("RbId", IntegerValue (10));
remHelper->Yükle ();

Niteliklerini yapılandırarak RadioEnvironmentMapHelper yukarıda gösterildiği gibi nesneyi
oluşturulacak REM'in parametrelerini ayarlayabilir. Her birinin
RadioEnvironmentMapHelper örnek yalnızca bir REM oluşturabilir; daha fazla üretmek istiyorsanız
REM'lerde her REM için ayrı bir örnek oluşturmanız gerekir.

REM neslinin özellikle çok zorlu olduğunu unutmayın:

· çalışma zamanı bellek tüketimi piksel başına yaklaşık 5KB'dir. Örneğin, bir REM
500x500 çözünürlükte yaklaşık 1.25 GB bellek gerekir ve çözünürlük
1000x1000 yaklaşık 5 GB'a ihtiyaç duyacaktır (bu sırada normal bir bilgisayar için çok fazla)
yazı). Bu sorunun üstesinden gelmek için REM birbirini takip eden adımlarla oluşturulur.
değeri tarafından belirlenen en fazla sayıda pikselin değerlendirilmesi adımı
nitelik RadioEnvironmentMapHelper::MaxPointsPerIteration.

· simülasyonun başında bir REM oluşturursanız, simülasyonun hızı yavaşlayacaktır.
simülasyonun geri kalanının yürütülmesi. Bir program için REM oluşturmak istiyorsanız
ve simülasyon sonucunu elde etmek için aynı programı kullanın, bir eklemeniz önerilir.
REM'in oluşturulmasına veya tamamının çalıştırılmasına olanak sağlayan komut satırı anahtarı
simülasyon. Bu amaçla bir özelliğin olduğunu unutmayın.
RadioEnvironmentMapHelper::StopWhenDone (varsayılan: doğru) bu,
REM oluşturulduktan hemen sonra simülasyonun durması.

REM, aşağıdaki formatta bir ASCII dosyasında saklanır:

· 1. sütun x koordinatıdır

· 2. sütun y koordinatıdır

· 3. sütun z koordinatıdır

· sütun 4 doğrusal birimler cinsinden SINR'dir

REM'i çizmenize olanak tanıyan minimal bir gnuplot betiği aşağıda verilmiştir:

görünüm haritasını ayarlayın;
xlabel "X"i ayarla
"Y" etiketini ayarla
"SINR (dB)" etiketini ayarlayın
ayarsız anahtar
resimle ($1):($2):(10*log10($4)) kullanarak "rem.out" grafiğini çizin

Örnek olarak örnek programla elde edilebilecek REM'i burada bulabilirsiniz
lena-çift şerit, ortak kanal dağıtımında üç sektörlü bir LTE makro hücresini gösterir.
bazı konut femto hücreleri iki apartman bloğuna rastgele yerleştirildi.
[image] lena-çift şerit örneğinden elde edilen REM.UNINDENT

Lena-dual-stripe örnek programının aynı zamanda gnuplot uyumlu çıktı ürettiğini unutmayın.
UE ve eNB düğümlerinin yanı sıra UE ve eNB düğümlerinin konumları hakkında bilgi içeren dosyalar
Dosyalarda sırasıyla binalar ues.txt, enbs.txt ve binalar.txt. Bunlar olabilir
gnuplot kullanırken kolayca dahil edilebilir. Örneğin, gnuplot betiğinizin
(örneğin, yukarıda açıklanan minimal gnuplot betiği) adlı bir dosyaya kaydedilir.
my_plot_script, aşağıdaki komutu çalıştırmak UE'lerin, eNB'lerin ve
REM'in üstündeki binalar:

gnuplot -p enbs.txt ues.txt binalar.txt my_plot_script

AMC Model ve CQI Hesaplama
Simülatör, MCS'lerin seçimiyle ilgili iki olası şema sunmaktadır.
ve buna bağlı olarak CQI'lerin oluşturulması. Bunlardan ilki GSoC modülünü temel alıyor
[Piro2011] ve RB esasına göre çalışır. Bu model ns3 özelliğiyle etkinleştirilebilir
sistemi aşağıdaki şekilde sunulmaktadır:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

Fiziksel hata modeline dayalı çözüm şu şekilde kontrol edilebilir:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

Son olarak gerekli verimlilik PiroEW2010 AMC modülü sayesinde ayarlanabilir
Ber özellik (), örneğin:

Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));

Evolved Paket çekirdek (EPC)
Şimdi EPC'yi simüle etmeye olanak tanıyan bir simülasyon programının nasıl yazılacağını açıklıyoruz.
LTE radyo erişim ağına ek olarak. EPC kullanımı IPv4 ağının kullanılmasına olanak tanır
LTE cihazlarıyla. Yani normal ns-3 uygulamalarını kullanabileceksiniz
ve LTE üzerinden IPv4 üzerinden soketler ve ayrıca bir LTE ağını başka herhangi bir IPv4'e bağlamak için
Simülasyonunuzda sahip olabileceğiniz ağ.

Her şeyden önce, buna ek olarak LteHelper daha önce tanıttığımız Basic simülasyon
program, ek bir tane kullanmanız gerekir EpcYardımcı oluşturmayla ilgilenecek sınıf
EPC varlıkları ve ağ topolojisi. kullanamayacağınızı unutmayın EpcYardımcı doğrudan olduğu gibi
soyut bir temel sınıftır; bunun yerine alt sınıflarından birini kullanmanız gerekir;
farklı EPC topolojisi uygulamaları sağlar. Bu örnekte ele alacağız
PointToPointEpcHelperNoktadan noktaya bağlantılara dayalı bir EPC uygulayan. Kullanmak için,
öncelikle bu kodu simülasyon programınıza eklemeniz gerekir:

puan lteHelper = Nesne Oluştur ();
Ptr epcHelper = CreateObject ();

Ardından LTE yardımcısına EPC'nin kullanılacağını söylemeniz gerekir:

lteHelper->SetEpcHelper (epcHelper);

LTE yardımcısının uygun EPC'yi tetiklemesi için yukarıdaki adım gereklidir
yeni bir eNB'nin kurulması gibi bazı önemli konfigürasyonlara uygun konfigürasyon
veya simülasyona UE eklenir veya bir EPS taşıyıcısı oluşturulur. EPC yardımcısı şunları yapacaktır:
S1 bağlantısı oluşturma ve S1 taşıyıcısı gibi gerekli ayarları otomatik olarak halledin
kurmak. Bütün bunlar kullanıcının müdahalesi olmadan yapılacaktır.

çağrı lteHelper->SetEpcHelper (epcHelper) EPC kullanımına olanak sağlar ve yan
herhangi bir yeniliğin etkisi LteEnbRrc Yaratılan şey şu özelliklere sahip olacak: EpsBearerToRlcMapping
öznitelik olarak ayarlandı RLC_UM_ALWAYS yerine RLC_SM_ALWAYS ikincisi varsayılan ise;
aksi takdirde, özellik değişmeyecektir (örneğin, varsayılanı olarak değiştirdiyseniz)
RLC_AM_ALWAYS, dokunulmayacak).

Unutulmamalıdır ki, EpcYardımcı ayrıca otomatik olarak PGW düğümünü oluşturacak ve
LTE radyo erişim ağından gelen/a giden trafiği düzgün bir şekilde yönetebilecek şekilde yapılandırın.
Yine de PGW'yi diğer IPv4 ağlarına bağlamak için bazı açık kodlar eklemeniz gerekir (örn.
internet). Burada tek bir uzak ana bilgisayarın nasıl bağlanacağına ilişkin çok basit bir örnek verilmiştir.
noktadan noktaya bağlantı yoluyla PGW:

Ptr pgw = epcHelper->GetPgwNode ();

// Tek bir RemoteHost oluşturun
NodeContainer RemoteHostContainer;
RemoteHostContainer.Create (1);
Ptr RemoteHost = RemoteHostContainer.Get (0);
InternetStackHelper interneti;
internet.Install (remoteHostContainer);

// İnterneti oluştur
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate", DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("Gecikme", TimeValue (Saniye (0.010)));
NetDeviceContainer internetDevices = p2ph.Install (pgw, RemoteHost);
Ipv4AddressHelper ipv4h;
ipv4h.SetBase ("1.0.0.0", "255.0.0.0");
Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices);
// arayüz 0 localhost'tur, 1 p2p cihazıdır
Ipv4Address RemoteHostAddr = internetIpIfaces.GetAddress (1);

Uzak ana bilgisayarın LTE UE'lere ulaşabilmesi için rotaların belirlenmesi önemlidir. Bir yolu
bunu yapmak, şu gerçeği kullanmaktır: PointToPointEpcHelper varsayılan olarak atayacak
LTE UE'lere 7.0.0.0 ağındaki bir IP adresi. Bunu akılda tutarak şunları yapmak yeterlidir:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr RemoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
RemoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

Şimdi devam etmeli ve önceki bölümlerde açıklandığı gibi LTE eNB'leri ve UE'leri oluşturmalısınız.
Elbette yol kaybı ve sönümlenme modelleri gibi diğer LTE özelliklerini de yapılandırabilirsiniz. Sağ
UE'leri oluşturduktan sonra bunları IP ağı için de yapılandırmanız gerekir. Bu bitti
aşağıdaki gibi. UE ve eNodeB düğümleri için aşağıdaki gibi bir kapsayıcınız olduğunu varsayıyoruz:

NodeContainer ueNode'lar;
NodeContainer enbNode'lar;

Yalnızca LTE simülasyonunu yapılandırmak için normalde şöyle bir şey yaparsınız:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Ekle (ueLteDevs, enbLteDevs.Get (0));

UE'leri IP ağı için yapılandırmak amacıyla ek olarak şunu yapmanız gerekir:
bu:

// IP yığınını UE'lere yüklüyoruz
InternetStackHelper interneti;
internet.Install (ueNodes);

// UE'lere IP adresi atayın
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr ue = ueNodes.Get (u);
Ptr ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// UE için varsayılan ağ geçidini ayarlayın
Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}

Taşıyıcıların aktivasyonu, yapılana göre biraz farklı bir şekilde yapılır.
Yalnızca LTE simülasyonu için. İlk olarak ActivateDataRadioBearer yöntemi kullanılmamalıdır.
EPC kullanıldığında. İkincisi, EPC kullanıldığında varsayılan EPS taşıyıcısı etkinleştirilecektir
LteHelper::Attach () öğesini çağırdığınızda otomatik olarak. Üçüncüsü, özel kurulum yapmak istiyorsanız
EPS taşıyıcısını kullanıyorsanız, bunu LteHelper::ActivateDedicatedEpsBearer () yöntemini kullanarak yapabilirsiniz. Bu
yöntemi parametre olarak Trafik Akış Şablonunu (TFT) alır; bu yapı,
özel EPS taşıyıcısına eşlenecek trafik türünü tanımlar. İşte bir
UE'de iletişim kuran bir uygulama için özel bir taşıyıcının nasıl kurulacağına ilişkin örnek
liman 1234:

Ptr tft = Oluştur ();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->Ekle (pf);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

elbette özel EpsBearer ve EpcTft yapılandırmalarını kullanabilirsiniz, lütfen
bunun nasıl yapılacağına dair doxygen belgeleri.

Son olarak, uzaktan kumandayla iletişim kuran LTE UE düğümlerine uygulamalar yükleyebilirsiniz.
internet üzerinden uygulamalar. Bu, olağan ns-3 prosedürleri izlenerek yapılır.
Tek bir RemoteHost ile basit örneğimizi takip ederek, downlink'in nasıl kurulacağını burada bulabilirsiniz
uzak ana bilgisayardaki bir UdpClient uygulaması ve ana bilgisayardaki bir PacketSink ile iletişim
LTE UE (önceki kod parçacıklarıyla aynı değişken adlarını kullanarak)

uint16_t dlPort = 1234;
PacketSinkHelper packageSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), dlPort));
ApplicationContainer sunucusuApps = packageSinkHelper.Install (ue);
serverApps.Start (Saniye (0.01));
UdpClientHelper istemcisi (ueIpIface.GetAddress (0), dlPort);
ApplicationContainer clientApps = client.Install (remoteHost);
clientApps.Start (Saniye (0.01));

Bu kadar! Artık simülasyonunuza her zamanki gibi başlayabilirsiniz:

Simülatör::Dur (Saniye (10.0));
Simülatör::Çalıştır ();

kullanma the EPC ile öykünme kip
Önceki bölümde eNB'ler ve eNB'ler arasındaki bağlantı için PointToPoint bağlantılarını kullandık.
SGW (S1-U arayüzü) ve eNB'ler arasında (X2-U ve X2-C arayüzleri). LTE modülü
PointToPoint bağlantıları yerine öykünülmüş bağlantıların kullanılmasını destekler. Bu sadece şu şekilde elde edilir:
yaratılmasının yerine LteHelper ve EpcYardımcı aşağıdaki kodla:

puan lteHelper = Nesne Oluştur ();
Ptr epcHelper = CreateObject ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Başlat ();

nitelikler ns3::EmuEpcHelper::sgwDeviceName ve ns3::EmuEpcHelper::enbDeviceName vardır
S1-U, X2-U ve X2-C'yi taşımak için kullanılan cihazların adını ayarlamak için kullanılır
sırasıyla SGW ve eNB'deki arayüzler. Şimdi bunun nasıl yapıldığını göstereceğiz.
örnek programı çalıştırdığımız yer lena-basit-epc-emu iki sanal kullanma
Ethernet arayüzleri.

Öncelikle ns-3'ü uygun şekilde oluşturuyoruz:

# yapılandır
./waf yapılandırma --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# inşa etmek
./waff

Daha sonra iki adet sanal ethernet arayüzü kuruyoruz ve trafiğe bakmak için Wireshark'ı başlatıyoruz.
geçiyor:

# not: root olmanız gerekiyor

# iki eşleştirilmiş veth cihazı oluşturun
ip bağlantısı ad ekle veth0 türü veth eş adı veth1
ip bağlantı gösterisi

# karışık modu etkinleştir
ip bağlantısı veth0 promisc'i açık olarak ayarla
ip bağlantısı veth1 promisc'i açık olarak ayarla

# arayüzleri aç
ip bağlantısı veth0'ı kurdu
ip bağlantısı veth1'ı kurdu

#wireshark'ı başlatın ve veth0'da yakalama yapın
tellerhark &

Artık örnek programı simüle edilmiş saatle çalıştırabiliriz:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

Wireshark'ı kullanarak, önce ARP çözünürlüğünü görmelisiniz, ardından bazı GTP paketleri her ikisini de değiştirmiştir.
Yukarı bağlantı ve aşağı bağlantıda.

Örnek programın varsayılan ayarı 1 eNB ve 1UE'dir. Bunu aracılığıyla değiştirebilirsiniz
komut satırı parametreleri, örneğin:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

Mevcut parametrelerin bir listesini almak için:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

Gerçek zamanlı saatle çalıştırmak için: Varsayılan hata ayıklama yapısının aşağıdakiler için çok yavaş olduğu ortaya çıktı:
gerçek zamanlı. BestEffort moduyla gerçek zaman kısıtlamalarını yumuşatmak iyi bir fikir değildir:
bir şeyler ters gidebilir (örn. ARP başarısız olabilir) ve eğer öyleyse hiçbir veri paketi alamazsınız
dışarı. Bu nedenle, iyi bir donanıma ve statik olarak bağlantılı optimize edilmiş bir yapıya ihtiyacınız var.
modüller:

./waf yapılandırma -d optimize edilmiş --enable-static --enable-modules=lte --enable-examples --enable-sudo

Daha sonra örnek programı şu şekilde çalıştırın:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

programın devam edememesi durumunda sonlandırılmasına neden olacak HardLimit ayarına dikkat edin
gerçek zamanlı olarak.

Bu bölümde açıklanan yaklaşım her türlü ağ cihazıyla kullanılabilir. İçin
Örneğin, [Baldo2014], taklit edilmiş bir LTE-EPC ağını bir ağ üzerinden çalıştırmak için nasıl kullanıldığını açıklamaktadır.
gerçek çok katmanlı paket optik taşıma ağı.

ağ Ek dosya
Bölümdeki temel örnekte gösterildiği gibi Basic simülasyon programUE'yi bir UE'ye bağlamak
eNodeB çağrılarak yapılır LteHelper::Ekle fonksiyonu.

Ağa bağlanmanın 2 olası yolu vardır. İlk yöntem, "Manuel" bir,
ikincisi daha fazlasına sahipken "otomatik" bunu anlayın. Her biri kapsanacak
bu bölüm.

Manuel haciz
Bu yöntem, LteHelper::Ekle yukarıda bahsedilen fonksiyon. Tek şey bu oldu
LTE modülünün önceki sürümlerinde mevcut olan ağ bağlantısı yöntemi. Tipik olarak
simülasyon başlamadan önce çağrılır:

lteHelper->Ekle (ueDevs, enbDev); // bir veya daha fazla UE'yi tek bir eNodeB'ye ekleyin

LteHelper::InstallEnbDevice ve LteHelper::InstallUeDevice işlevler çağrılmış olmalı
takmadan önce. EPC'nin etkin olduğu bir simülasyonda IPv4'ün düzgün bir şekilde olması da gerekir
UE'de önceden yüklenmiştir.

Bu yöntem çok basittir ancak tam olarak hangi UE'nin hangisine ait olduğunu bilmenizi gerektirir.
Simülasyon başlamadan önce eNodeB. UE başlangıç ​​konumu ayarlandığında bu zor olabilir.
simülasyon komut dosyası tarafından rastgele belirlenir.

UE ve eNodeB arasındaki mesafeyi seçmek için bir kriter olarak seçilebilir.
uygun hücre. Oldukça basittir (en azından simülatörün bakış açısından) ve
bazen pratik. Ancak bazen mesafenin bir anlam ifade etmediğini belirtmek önemlidir.
tek doğru kriter Örneğin, eNodeB anten yönlülüğü şu şekilde olmalıdır:
da düşünüldü. Bunun yanı sıra kanalın durumu da dikkate alınmalıdır.
solma veya gölgelenme etkisi varsa dalgalanabilir. Bu türlerde
durumlarda ağ bağlantısı yalnızca mesafeye dayandırılmamalıdır.

Gerçek hayatta UE belirli kriterleri otomatik olarak değerlendirecek ve en iyi hücreyi seçecektir.
Kullanıcının manuel müdahalesine gerek kalmadan takın. Açıkçası durum böyle değil
Re-Tweet LteHelper::Ekle işlev. Diğer ağa bağlanma yöntemi daha fazlasını kullanır "otomatik"
Daha sonra açıklanacağı gibi ağ bağlantısına yaklaşım.

Otomatik haciz kullanma boş kip hücre seçim prosedür
Alınan sinyalin gücü, en iyiyi seçmek için kullanılan standart kriterdir.
bağlanacak hücre. Bu kriterin kullanımı şu şekilde uygulanır: ilk hücre seçim
işlemin başka bir sürümünü çağırarak çağrılabilir. LteHelper::Ekle
işlevi, aşağıda gösterildiği gibi:

lteHelper->Ekle (ueDevs); // bir veya daha fazla UE'yi en güçlü hücreye ekleyin

Manuel yöntemin farkı, hedef eNodeB'nin belirtilmemiş olmasıdır.
prosedür, aşağıdakiler de dahil olmak üzere çeşitli kriterlere dayalı olarak UE'ler için en iyi hücreyi bulacaktır:
Alınan sinyalin gücü (RSRP).

Yöntem çağrıldıktan sonra UE, komşu hücreleri ölçmek için biraz zaman harcayacaktır.
ve sonra en iyisine bağlanmaya çalışın. Daha fazla ayrıntıyı bölümde bulabilirsiniz
Tasarım Belgelerinin ikinci-başlangıç-hücre-seçimi.

Bu yöntemin yalnızca EPC'nin etkin olduğu simülasyonlarda çalıştığını unutmamak önemlidir. Yalnızca LTE
simülasyonlar manuel bağlantı yöntemine başvurmalıdır.

Kapalı Abone grup
İlk hücre seçimi sürecinin ilginç bir kullanım durumu, bir simülasyon oluşturmaktır.
Kapalı Abone Grubu (CSG) içeren ortam.

Örneğin, belirli bir eNodeB, genellikle femtocell gibi daha küçük bir versiyon,
özel bir mal sahibine (örn. ev veya iş yeri), yalnızca bazı UE'lere erişim izni verir.
daha önce sahibi tarafından kaydedilmiştir. eNodeB ve kayıtlı UE'lerin tamamı
CSG'yi oluşturun.

Erişim kısıtlaması, CSG üyelerinin aynı CSG ile "etiketlenmesi" yoluyla simüle edilebilir
İD. Bu, hem eNodeB hem de UE'deki nitelikler aracılığıyla yapılır; örneğin
takip etme LteHelper fonksiyonlar:

// aşağıdaki eNodeB'leri CSG kimliği 1 ve CSG göstergesi etkin olacak şekilde etiketleyin
lteHelper->SetEnbDeviceAttribute ("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication", BooleanValue (true));

// bir veya daha fazla UE'yi CSG kimliği 1 ile etiketleyin
lteHelper->SetUeDeviceAttribute ("CsgId", UintegerValue (1));

// eNodeB'leri ve UE'leri kurun
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

Ardından UE'lerde ilk hücre seçimi prosedürünü etkinleştirin:

lteHelper->Ekle (csgUeDevs);

Bu gereklidir çünkü CSG kısıtlaması yalnızca otomatik ağ yöntemiyle çalışır
ekleme, ancak manuel yöntemde değil.

eNodeB'nin CSG göstergesinin false (varsayılan değer) olarak ayarlanmasının,
kısıtlamayı devre dışı bırakın, yani herhangi bir UE bu eNodeB'ye bağlanabilir.

yapılandırma UE ölçümler
Bir simülasyondaki aktif UE ölçüm konfigürasyonu seçilenler tarafından belirlenir.
devir algoritması gibi "tüketiciler" olarak adlandırılır. Kullanıcılar kendi yapılandırmalarını ekleyebilir
eylemdir ve bunu yapmanın birkaç yolu vardır:

1. eNodeB RRC varlığında doğrudan konfigürasyon;

2. mevcut devir algoritmasının yapılandırılması; Ve

3. Yeni bir devir teslim algoritması geliştirmek.

Bu bölümde yalnızca ilk yöntem ele alınacaktır. İkinci yöntem kapsamındadır. Otomatik
teslim et tetikleyebilirÜçüncü yöntem ise Bölüm'de ayrıntılı olarak açıklanmaktadır.
Tasarım Dokümantasyonunun saniye-devir-algoritması.

eNodeB RRC'de doğrudan konfigürasyon aşağıdaki şekilde çalışır. Kullanıcı yeni bir tane oluşturarak başlar
LteRrcSap::ReportConfigEutra örneğine gidin ve bunu LteEnbRrc::AddUeMeasReportConfig
işlev. İşlev şunu döndürecektir: ölçüm kimliği (ölçüm kimliği) benzersizdir.
eNodeB örneğindeki konfigürasyonun referansı. Bu işlev daha önce çağrılmalıdır
simülasyon başlar. Ölçüm konfigürasyonu, bağlı tüm UE'lerde aktif olacaktır.
simülasyon süresince eNodeB. Simülasyon sırasında kullanıcı şunları yapabilir:
UE'ler tarafından üretilen ölçüm raporlarını mevcut verileri dinleyerek yakalayın
LteEnbRrc::RecvMeasurementReport iz kaynağı.

Yapı RaporConfigEutra 3GPP spesifikasyonuna uygundur. tanımı
yapısı ve her üye alanı [TS6.3.5] Bölüm 36331'te bulunabilir.

Aşağıdaki kod örneği, Olay A1 RSRP ölçümünü, içindeki her eNodeB için yapılandırır.
konteyner devs:

LteRrcSap::ReportConfigEutra yapılandırması;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
yapılandırma.threshold1.range = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

std::vektör ölçümIdList;

NetDeviceContainer::Yineleyici;
for (it = devs.Begin (); it != devs.End (); it++)
{
Ptr geliştirici = *o;
Ptr enbDev = dev->GetObject ();
Ptr enbRrc = enbDev->GetRrc ();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back (measId); // oluşturulan ölçüm kimliğini hatırla

enbRrc->TraceConnect ("RecvMeasurementReport",
"bağlam",
MakeCallback (&RecvMeasurementReportCallback));
}

Eşiklerin aralık olarak ifade edildiğini unutmayın. Yukarıdaki örnekte RSRP için 41 aralığı
-100 dBm'ye karşılık gelir. Aralık formatından ve aralık formatına dönüşüm Bölümden kaynaklanmaktadır.
[TS9.1.4]'ün 9.1.7 ve 36133'si. EutranÖlçümHaritalama sınıfta birkaç statik var
Bu amaçla kullanılabilecek işlevler.

İlgili geri çağırma işlevi aşağıdakine benzer bir tanıma sahip olacaktır:

geçersiz
RecvMeasurementReportCallback (std::string bağlamı,
uint64_t imsi,
uint16_t hücre kimliği,
uint16_t rnti,
LteRrcSap::MeasurementReport measReport);

Bu yöntem, geri çağırma işlevini UE ölçümlerinin tüketicisi olarak kaydedecektir. İçinde
Simülasyonda birden fazla tüketicinin bulunması durumu (örneğin devir algoritması),
diğer tüketicilere yönelik ölçümler de bu geri aramayla yakalanacak
işlev. Kullanıcılar, ölçüm kimliği alanı içerisinde yer alan
LteRrcSap::ÖlçümRaporu hangi ölçümün yapıldığını söylemek için geri çağırma fonksiyonunun argümanı
yapılandırma raporu tetikledi.

Genel olarak bu mekanizma, bir tüketicinin farkında olmadan diğerine müdahale etmesini engeller.
tüketicinin raporlama yapılandırması.

Yalnızca raporlama yapılandırması bölümünün (ör. LteRrcSap::ReportConfigEutra) of
UE ölçümleri parametresi tüketicilerin yapılandırması için açıktır, diğer parçalar ise
gizli tutulur. Frekans içi sınırlama, bu API'nin arkasındaki ana motivasyondur
uygulama kararı:

· sadece bir tane var, kesin ve kesin ölçüm nesne, dolayısıyla yok
yapılandırmanız gerekiyor;

· ölçüm kimlikler birebir görüşme olduğu için gizli tutuluyor
raporlama konfigürasyonu ile ölçüm kimliği arasında eşleme, dolayısıyla yeni bir
yeni bir raporlama yapılandırması oluşturulduğunda ölçüm kimliği otomatik olarak ayarlanır
yaratıldı;

· miktar yapılandırma başka bir yerde yapılandırılmıştır, bkz. saniye-performans-ölçümleri; Ve

· ölçüm boşluklar desteklenmez çünkü yalnızca frekanslar arası için geçerlidir
ayarlar;

X2 tabanlı teslim et
3GPP tarafından tanımlandığı gibi devir, bir UE'nin hizmet veren hücresini değiştirmeye yönelik bir prosedürdür.
BAĞLI mod. Sürece dahil olan iki eNodeB'ye genellikle kaynak
eNodeB ve hedef eNodeB.

Simülasyonda X2 tabanlı geçişin yürütülmesini sağlamak için iki tane vardır
karşılanması gereken gereksinimler. Öncelikle simülasyonda EPC etkinleştirilmelidir (bkz. Evolved
Paket çekirdek (EPC)).

İkinci olarak, iki eNodeB arasında bir X2 arayüzü yapılandırılmalıdır.
simülasyon programı içerisinde açıkça yapılır:

lteHelper->AddX2Interface (enbNodes);

nerede enbNode'lar bir DüğümKonteyner aralarında X2'nin bulunduğu iki eNodeB'yi içerir
arayüzü yapılandırılacaktır. Kapta ikiden fazla eNodeB varsa işlev
konteynerdeki her eNodeB çifti arasında bir X2 arayüzü oluşturacaktır.

Son olarak, hedef eNodeB'nin X2 HANDOVER REQUEST'e "açık" olarak yapılandırılması gerekir. Her
eNodeB varsayılan olarak açıktır, dolayısıyla çoğu durumda ekstra talimata gerek yoktur. Ancak kullanıcılar
boolean niteliğini ayarlayarak eNodeB'yi "kapalı" olarak ayarlayabilir
LteEnbRrc::AdmitHandoverRequest için yanlış. Örnek olarak şunu çalıştırabilirsiniz: lena-x2-devir
özniteliği şu şekilde programlayın ve ayarlayın:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

Yukarıdaki üç gereklilik yerine getirildikten sonra devir işlemi başlatılabilir.
manuel veya otomatik olarak. Her biri aşağıdaki alt bölümlerde sunulacaktır.

Manuel teslim et tetikleyebilir
Devir teslim olayı, simülasyon programı içerisinde bir zamanlama planlanarak "manuel olarak" tetiklenebilir.
açık devir teslim olayı. LteHelper nesne için uygun bir yöntem sağlar.
bir devir teslim etkinliğinin planlanması. Örnek olarak şunu varsayalım ueLteDevs bir
NetCihazKonteyner teslim edilecek UE'yi içeren ve enbLteDevs is
bir diğeri NetCihazKonteyner kaynağı ve hedef eNB'yi içerir. Daha sonra devir teslim
0.1 saniyede şu şekilde programlanabilir:

lteHelper->HandoverRequest (Saniye (0.100),
ueLteDevs.Get (0),
enbLteDevs.Get (0),
enbLteDevs.Get (1));

UE'nin halihazırda kaynak eNB'ye bağlı olması gerektiğini unutmayın, aksi takdirde simülasyon
bir hata mesajıyla sonlandırılacaktır.

Tam kaynak kodunu içeren bir örnek için lütfen bkz. lena-x2-devir örnek
programı.

Otomatik teslim et tetikleyebilir
Devir işlemi prosedürü aynı zamanda UE'nin hizmet veren eNodeB'si tarafından "otomatik olarak" tetiklenebilir.
Tetikleyicinin arkasındaki mantık, şu anda aktif olan aktarma algoritmasına bağlıdır.
eNodeB RRC varlığı. Kullanıcılar kullanılacak devir algoritmasını seçip yapılandırabilir
Bu bölümde kısaca açıklanacak olan simülasyonda. Kullanıcılar şunları da tercih edebilir:
Bölüm'de açıklandığı gibi kendi devir algoritması uygulamalarını yazın
Tasarım Dokümantasyonunun saniye-devir-algoritması.

Bir devir teslim algoritmasının seçilmesi şu yolla yapılır: LteHelper nesne ve onun
SetHandoverAlgorithmType aşağıda gösterildiği gibi yöntem:

puan lteHelper = Nesne Oluştur ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

Seçilen devir algoritması aynı zamanda çeşitli yapılandırılabilir özellikler de sağlayabilir;
aşağıdaki gibi ayarlanabilir:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold",
TamsayıDeğeri (30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset",
TamsayıDeğeri (1));

LTE modülünde üç devir teslim algoritması seçeneği bulunmaktadır. A2-A4-RSRQ
devir algoritması (şu şekilde adlandırılır) ns3::A2A4RsrqHandoverAlgoritması) varsayılan seçenektir ve
kullanımı yukarıda zaten gösterilmiştir.

Başka bir seçenek de güçlü hücre devir algoritması (şu şekilde adlandırılır)
ns3::A3RsrpHandoverAlgoritması), aşağıdaki kodla seçilebilir ve yapılandırılabilir:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("Histerezis",
DoubleValue (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger",
Zaman Değeri (MiliSaniye (256)));

Son seçenek, adı verilen özel bir seçenektir. işlemsiz temel olarak devir teslim algoritması
otomatik devir tetikleyicisini devre dışı bırakır. Bu, örneğin manuel olarak
Devir teslim tetikleyicisi, tüm devir kararlarında özel bir kontrole ihtiyaç duyar. Hiç yok
yapılandırılabilir nitelikler. Kullanımı aşağıdaki gibidir:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

Her bir devir algoritmasının karar politikası ve nitelikleri hakkında daha fazla bilgi için,
lütfen Bölüm sek devir teslim algoritmasındaki ilgili alt bölümlere bakın.
Tasarım Dokümantasyonu.

Son olarak, InstallEnbDevice fonksiyonu LteHelper bir örneğini başlatacak
her eNodeB cihazı için seçilen devir algoritması. Başka bir deyişle, seçtiğinizden emin olun.
Aşağıdaki kod satırında sonlandırmadan önce sağ devir algoritmasını kullanın:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

Otomatik devir tetikleyiciyi kullanmanın tam kaynak kodunu içeren örnek şurada bulunabilir:
lena-x2-devir teslim önlemleri örnek program.

Ayar simülasyon ile teslim et
Tasarım Dokümantasyonunda belirtildiği gibi, devir teslim modelinin mevcut uygulaması,
Devir teslim hatası meydana geldiğinde öngörülemeyen davranışlar ortaya çıkar. Bu alt bölümde şunlara odaklanılacaktır:
kullanıcıların devir teslimi kullanmayı planlıyorlarsa dikkate almaları gereken adımlar
simülasyonlar.

Devir teslim başarısızlığının ele alacağımız ana nedeni iletim hatasıdır
Bir devir prosedürünün yürütülmesi sırasında devir ile ilgili sinyal mesajları. Gibi
Tasarım Dokümantasyonundan Şekil fig-x2-tabanlı-devir-sıra-diyagramında açıkça görüldüğü gibi,
birçoğu var ve farklı arayüzler ve protokoller kullanıyorlar. Uğruna
Basitlik açısından, X2 arayüzünün (kaynak eNodeB ile kaynak eNodeB arasında) olduğunu güvenle varsayabiliriz.
hedef eNodeB) ve S1 arayüzü (hedef eNodeB ile SGW/PGW arasında) oldukça
stabil. Bu nedenle dikkatimizi RRC protokolüne (UE ile AB arasındaki) odaklayacağız.
eNodeB'ler) ve normalde hava yoluyla iletilen Rastgele Erişim prosedürü
ve kanal durumunun bozulmasına karşı hassastır.

İletim hatasını azaltmak için genel bir ipucu: sağlamak yüksek yeterli SINR her seviyede seviye
UE. Bu, ağ topolojisinin uygun şekilde planlanmasıyla yapılabilir. en aza indirir ağ
kapsama delik. Topolojinin bilinen bir kapsama deliği varsa UE yapılandırılmalıdır
o bölgeye girmemek.

Akılda tutulması gereken bir diğer yaklaşım ise önlemek çok geç teslimler. Başka bir deyişle devir teslim
UE'nin SINR'si çok düşük hale gelmeden önce gerçekleşmelidir, aksi takdirde UE alımda başarısız olabilir
eNodeB kaynağından devir komutu. Devir teslim algoritmaları kontrol etme araçlarına sahiptir
Devir teslim kararının ne kadar erken veya geç verildiği. Örneğin A2-A4-RSRQ devir algoritması
Devir teslime daha erken karar verilmesini sağlamak için daha yüksek bir eşikle yapılandırılabilir. Benzer şekilde,
En güçlü hücre aktarma algoritmasında daha küçük histerezis ve/veya daha kısa tetikleme süresi
genellikle daha erken devir teslimle sonuçlanır. Bunlara uygun değerleri bulmak için
parametrelerde dikkate alınması gereken faktörlerden biri UE hareket hızıdır.
Genel olarak daha hızlı hareket eden bir UE, devir işleminin daha erken gerçekleştirilmesini gerektirir. Biraz araştırma
Çalışma [Lee2010]'da olduğu gibi önerilen değerleri önermiştir.

Yukarıdaki ipuçları normal simülasyon kullanımlarında yeterli olacaktır, ancak bazı özel durumlarda
İhtiyaçlar ortaya çıktığında aşırı bir önlem dikkate alınabilir. Örneğin, kullanıcılar
düşünebilir devre dışı bırakma the kanal hata modelleri. Bu, herkesin
devirle ilgili sinyal mesajları, ne olursa olsun başarıyla iletilecektir.
mesafe ve kanal durumu. Ancak bu aynı zamanda diğer tüm verileri veya kontrolü de etkileyecektir.
istenmeyen bir yan etki olabilecek devirle ilgili olmayan paketler. Aksi takdirde yapabilir
şu şekilde yapılabilir:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (yanlış));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (yanlış));

Yukarıdaki kodu kullanarak hem kontrol hem de veri kanallarında hata modelini devre dışı bırakıyoruz ve
her iki yönde de (aşağı bağlantı ve yukarı bağlantı). Devir teslimle ilgili olduğundan bu gereklidir
Sinyalizasyon mesajları bu kanallar kullanılarak iletilir. Bir istisna,
simülasyon ideal RRC protokolünü kullanır. Bu durumda yalnızca Rastgele Erişim prosedürü uygulanır.
değerlendirilmeye bırakıldı. Prosedür kontrol mesajlarından oluşur, bu nedenle yalnızca
Kontrol kanalının hata modelini devre dışı bırakmak için.

Teslim et ayak sesleri
RRC modeli, özellikle LteEnbRrc ve LteUeRrc bazı yararlı nesneler sağlar
başlangıçta çağrılmaları için bazı özel işlevlere bağlanabilen izler
ve hem UE hem de eNB tarafında devir yürütme aşamasının sonu. Örnek olarak,
Simülasyon programınızda aşağıdaki yöntemleri bildirebilirsiniz:

geçersiz
NotifyHandoverStartUe (std::string bağlamı,
uint64_t imsi,
uint16_t hücre kimliği,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now (.GetSeconds () << " " << bağlam
<< " UE IMSI " << imsi
<< ": önceden CellId'ye bağlanıldı " << cellId
<< " RNTI ile " << rnti
<< ", CellId'e geçiş yapılıyor " << targetCellId
<< std::endl;
}

geçersiz
NotifyHandoverEndOkUe (std::string bağlamı,
uint64_t imsi,
uint16_t hücre kimliği,
uint16_t rnti)
{
std::cout << Simulator::Now (.GetSeconds () << " " << bağlam
<< " UE IMSI " << imsi
<< ": CellId'ye başarıyla geçiş " << cellId
<< " RNTI ile " << rnti
<< std::endl;
}

geçersiz
NotifyHandoverStartEnb (std::string bağlamı,
uint64_t imsi,
uint16_t hücre kimliği,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now (.GetSeconds () << " " << bağlam
<< " eNB Hücre Kimliği " << hücre Kimliği
<< ": UE'nin devrini IMSI ile başlat " << imsi
<< " RNTI " << rnti
<< " - CellId " << targetCellId
<< std::endl;
}

geçersiz
NotifyHandoverEndOkEnb (std::string bağlamı,
uint64_t imsi,
uint16_t hücre kimliği,
uint16_t rnti)
{
std::cout << Simulator::Now (.GetSeconds () << " " << bağlam
<< " eNB Hücre Kimliği " << hücre Kimliği
<< ": IMSI ile UE'nin devri tamamlandı " << imsi
<< " RNTI " << rnti
<< std::endl;
}

Daha sonra bu yöntemleri karşılık gelen izleme kaynaklarına şu şekilde bağlayabilirsiniz:

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));

Örnek program src/lte/examples/lena-x2-handover.cc yukarıdakilerin hepsinin nasıl olduğunu gösterir
Talimatlar bir simülasyon programına entegre edilebilir. Programı şu şekilde çalıştırabilirsiniz:

./waf --run lena-x2-handover

ve özel devir izleme kancaları tarafından yazdırılan mesajların çıktısını alacaktır. Sırayla
ek olarak bazı anlamlı günlük bilgilerini görselleştirin, programı şu şekilde çalıştırabilirsiniz:
bu:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --run lena-x2-handover

Sıklık Yeniden Algoritmalar
Bu bölümde LTE içerisinde eNb'de Frekans Yeniden Kullanım Algoritmalarının nasıl kullanılacağını anlatacağız.
simülasyonlar. Yapılandırmanın iki olası yolu vardır. İlk yaklaşım,
"manuel" olan, yapılandırılması için daha fazla parametre gerektirir, ancak kullanıcının FR'yi yapılandırmasına izin verir
Algoritmayı ihtiyaç duyduğu şekilde kullanın. İkinci yaklaşım daha "otomatiktir". Bu çok uygun,
çünkü her FR algoritması için aynıdır, böylece kullanıcı FR algoritmasını çok hızlı bir şekilde değiştirebilir.
Yalnızca FR algoritmasının türü değiştiriliyor. Bir dezavantajı "otomatik" yaklaşımın yalnızca
Her algoritma için sınırlı konfigürasyon seti, bu da onu daha az esnek kılar, ancak
çoğu durumda yeterlidir.

Bu iki yaklaşım aşağıdaki alt bölümde daha ayrıntılı olarak açıklanacaktır.

Kullanıcı Frekans Yeniden Kullanım algoritmasını yapılandırmazsa, varsayılan algoritma (örn. LteFrNoOpAlgorithm)
eNb'de kuruludur. FR algoritması devre dışı bırakılmış gibi davranır.

Bahsedilmesi gereken bir şey, uygulanan FR algoritmalarının çoğunun
hücre bant genişliği 15 RB'den büyük veya eşit. Bu sınırlama, gereklilikten kaynaklanmaktadır.
iletim için UE'ye en az üç sürekli RB'nin atanması gerekir.

Manuel yapılandırma
Frekans yeniden kullanım algoritması simülasyon programı içerisinde "manuel olarak" yapılandırılabilir.
FR algoritmasının türünü ve tüm özelliklerini ayarlama. Şu anda yedi FR algoritması bulunmaktadır.
uygulandı:

· ns3::LteFrNoOpAlgoritma

· ns3::LteFrHardAlgoritma

· ns3::LteFrStrictAlgoritma

· ns3::LteFrSoftAlgoritma

· ns3::LteFfrSoftAlgoritma

· ns3::LteFfrGelişmişAlgoritma

· ns3::LteFfrDistributedAlgoritma

Bir FR algoritmasının seçilmesi şu yolla yapılır: LteHelper nesne ve onun SetFfrAlgorithmType
aşağıda gösterildiği gibi yöntem:

puan lteHelper = Nesne Oluştur ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

Uygulanan her FR algoritması çeşitli yapılandırılabilir özellikler sağlar. Kullanıcılar yok
UL ve DL bant genişliği yapılandırmasına önem vermek, çünkü bu işlem sırasında otomatik olarak yapılır.
hücre konfigürasyonu. FR algoritmasının bant genişliğini değiştirmek için gerekli değerleri yapılandırın.
LteEnbNetDevice:

uint8_t bant genişliği = 100;
lteHelper->SetEnbDeviceAttribute ("DlBandwidth", UintegerValue (bant genişliği));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth", UintegerValue (bant genişliği));

Şimdi her bir FR algoritmasının konfigürasyonu açıklanacaktır.

Zor Sıklık Yeniden Algoritma
Tasarım Dokümantasyonunun sec-fr-hard-algoritması bölümünde açıklandığı gibi
ns3::LteFrHardAlgoritma bir alt bant kullanır. Bu alt bandı yapılandırmak için kullanıcının belirtmesi gerekir
RB sayısı cinsinden DL ve UL için ofset ve bant genişliği.

Sabit Frekansın Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· DlSubBandOffset: Kaynak Blok Grubu Sayısında Downlink Dengelemesi

· DlSubBant genişliği: Sayı olarak Downlink İletim Alt Bant Genişliği Yapılandırması
Kaynak Blok Grupları

· UlSubBandOfseti: Kaynak Blok Grubu Sayısında Yukarı Bağlantı Dengesi

· UlSubBant genişliği: Kaynak Sayısında Uplink İletim Alt Bant Genişliği Yapılandırması
Blok Grupları

LteFrHardAlgorithm'in örnek yapılandırması aşağıdaki şekilde yapılabilir:

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));

Yukarıdaki örnekte eNB'nin DL ve UL'de yalnızca 8'den 16'ya kadar RB'leri kullanmasına izin verilirken tüm hücre
bant genişliği 25'tir.

Sıkı Sıklık Yeniden Algoritma
Katı Frekans Yeniden Kullanım Algoritması iki alt bant kullanır: her hücre için ortak bir tane ve her hücre için ortak bir tane
özel. Ayrıca UE'nin hangi alt bant içinde olduğuna karar vermek için gerekli olan RSRQ eşiği de vardır.
servis edilmelidir. Üstelik bu alt bantlardaki güç aktarımı farklı olabilir.

Katı Frekans Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· UlOrtakAlt Bant Genişliği: Kaynak Sayısında Uplink Ortak Alt Bant Genişliği Yapılandırması
Blok Grupları

· UlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Uplink Kenar Alt Bant Ofseti

· UlEdgeSubBant Genişliği: Kaynak Sayısında Uplink Kenar Alt Bant Genişliği Yapılandırması
Blok Grupları

· DlOrtakAlt Bant Genişliği: Sayı olarak Downlink Ortak Alt Bant Genişliği Yapılandırması
Kaynak Blok Grupları

· DlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Downlink Kenar Alt Bant Ofseti

· DlEdgeSub Bant Genişliği: Kaynak Sayısında Downlink Edge Alt Bant Genişliği Yapılandırması
Blok Grupları

· RsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir.
kenar alt bandı

· MerkezGüçOfseti: PdschConfigDedicated::Orta alt bant için Pa değeri, varsayılan değer
dB0

· EdgePowerOffset: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer dB0

· MerkezAreaTpc: Merkez alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· EdgeAreaTpc: Kenar bölgesindeki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

Aşağıdaki örnek, eNB'nin 0 ila 6 arasındaki RB'leri ortak alt bant olarak ve 12 ila 18 arasındaki RB'leri ortak alt bant olarak kullanmasına izin verir.
DL ve UL'de özel alt bant, RSRQ eşiği 20 dB, merkez alandaki güç eşittir
LteEnbPhy::TxPower - 3dB, kenar alanındaki güç eşittir 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));

Yumuşak Sıklık Yeniden Algoritma
Yumuşak Frekans Yeniden Kullanım Algoritması ile eNb, hücre bant genişliğinin tamamını kullanır, ancak iki tane vardır:
UE'ler içindeki alt bantlara farklı güç seviyelerinde hizmet verilir.

Yumuşak Frekans Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· UlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Uplink Kenar Alt Bant Ofseti

· UlEdgeSubBant Genişliği: Kaynak Sayısında Uplink Kenar Alt Bant Genişliği Yapılandırması
Blok Grupları

· DlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Downlink Kenar Alt Bant Ofseti

· DlEdgeSub Bant Genişliği: Kaynak Sayısında Downlink Edge Alt Bant Genişliği Yapılandırması
Blok Grupları

· AllowCenterUeUseEdgeSubBand: Eğer gerçek merkez UE'ler kenar alt bant RBG'lerini alabiliyorsa,
aksi halde kenar alt bandına yalnızca kenar UE'ler için izin verilir, varsayılan değer true'dur

· RsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir.
kenar alt bandı

· MerkezGüçOfseti: PdschConfigDedicated::Orta alt bant için Pa değeri, varsayılan değer
dB0

· EdgePowerOffset: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer dB0

· MerkezAreaTpc: Merkez alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· EdgeAreaTpc: Kenar bölgesindeki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

Aşağıdaki örnek, hücre kenarı UE'leri tarafından kullanılacak 8'den 16'ya kadar RB'leri yapılandırır ve bu alt bant
hücre merkezi kullanıcıları için mevcut değildir. RSRQ eşiği 20 dB'dir, orta alandaki güç eşittir
LteEnbPhy::TxPower, kenar alanındaki güç eşittir 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));

Yumuşak kesirli Sıklık Yeniden Algoritma
Yumuşak Kesirli Frekansın Yeniden Kullanımı (SFFR) üç alt bant kullanır: merkez, orta (ortak) ve
kenar. Kullanıcının bunlardan yalnızca ikisini yapılandırması gerekir: ortak ve uç. Merkez alt bant olacak
kalan bant genişliğinden oluşur. Her alt bant farklı şekilde sunulabilir
Iletim gücü. Üç alt bant olduğundan iki RSRQ eşiğinin belirlenmesi gerekir.
yapılandırılmıştır.

Yumuşak Kesirli Frekans Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· UlOrtakAlt Bant Genişliği: Kaynak Sayısında Uplink Ortak Alt Bant Genişliği Yapılandırması
Blok Grupları

· UlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Uplink Kenar Alt Bant Ofseti

· UlEdgeSubBant Genişliği: Kaynak Sayısında Uplink Kenar Alt Bant Genişliği Yapılandırması
Blok Grupları

· DlOrtakAlt Bant Genişliği: Sayı olarak Downlink Ortak Alt Bant Genişliği Yapılandırması
Kaynak Blok Grupları

· DlEdgeSubBandOffset: Kaynak Blok Grubu Sayısında Downlink Kenar Alt Bant Ofseti

· DlEdgeSub Bant Genişliği: Kaynak Sayısında Downlink Edge Alt Bant Genişliği Yapılandırması
Blok Grupları

· MerkezRsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir
orta alt bantta

· EdgeRsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir
kenar alt bandında

· MerkezAlanGüçOfseti: PdschConfigDedicated::Orta alt bant için Pa değeri, varsayılan
değer dB0

· Orta Alan Güç Dengesi: Orta alt bant için PdschConfigDedicated::Pa değeri, varsayılan
değer dB0

· EdgeAreaPowerOffset: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer
dB0

· MerkezAreaTpc: Merkez alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· MediumAreaTpc: Orta alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· EdgeAreaTpc: Kenar bölgesindeki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

Aşağıdaki örnekte 0'dan 6'ya kadar olan RB'ler ortak (orta) alt bant olarak kullanılacaktır; 6'dan XNUMX'ya kadar olan RB'ler ortak (orta) alt bant olarak kullanılacaktır.
12 kenar alt bant olarak kullanılacak ve 12'den 24'e kadar olan RB'ler merkez alt bant olarak kullanılacaktır (bu
kalan RB'lerden oluşur). Merkez ve orta alan arasındaki RSRQ eşiği 28 dB,
Orta ve kenar alanı arasındaki RSRQ eşiği 18 dB'dir. Merkez alandaki güç eşittir
LteEnbPhy::TxPower - 3dB, orta alandaki güç eşittir LteEnbPhy::TxPower + 3dB, güç girişi
kenar alanı eşittir 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));

geliştirilmiş kesirli Sıklık Yeniden Algoritma
Gelişmiş Kesirli Frekansın Yeniden Kullanımı (EFFR), her hücre için sistem bant genişliğinin bir kısmını ayırır
(tipik olarak 3 hücre tipi vardır ve her biri sistem bant genişliğinin 1/3'ünü alır). Daha sonra bir kısmı
olarak kullanılan bu alt bant genişliği Birincil Bölüm yeniden kullanım faktörü 3 ile ve ikincil Bölüm
yeniden kullanım faktörü 1 ile. Kullanıcının hücre alt bant genişliğinin ofsetini (DL ve UL için) yapılandırması gerekir.
RB sayısı olarak kullanılacak RB sayısı Birincil Bölüm ve RB sayısı
olarak kullanılacak ikincil Bölüm. Birincil Bölüm hücre tarafından istenildiği zaman kullanılır, ancak RB'ler
ikincil Bölüm yalnızca bu UE'den gelen CQI geri bildiriminin daha yüksek olması durumunda UE'ye atanabilir
yapılandırılmış CQI eşiğinden daha yüksek bir değer. UE, RSRQ'su düşük olduğunda uç UE olarak kabul edilir
göre RsrqEşik.

Her eNb'nin diğer hücre türlerinin Birincil ve İkincil'in nerede olduğunu bilmesi gerektiğinden,
yapılandırmanın her hücre için aynı olduğunu ve yalnızca alt bant genişliğini varsayarak bunları hesaplayın
ofsetler farklıdır. Bu nedenle mevcut sistem bant genişliğini eşit olarak bölmek önemlidir.
her hücreye aynı Birincil ve İkincil Segment konfigürasyonunu uygulayın.

Gelişmiş Kesirli Frekans Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· UlSubBandOfseti: Kaynak Bloğu sayısı cinsinden bu hücre için Yukarı Bağlantı Alt Bant Ofseti
Gruplar

· UlReuse3Alt Bant Genişliği: Kaynak Sayısında Uplink Yeniden Kullanım 3 Alt Bant Genişliği Yapılandırması
Blok Grupları

· UlReuse1Alt Bant Genişliği: Kaynak Sayısında Uplink Yeniden Kullanım 1 Alt Bant Genişliği Yapılandırması
Blok Grupları

· DlSubBandOffset: Kaynak Bloğu sayısı cinsinden bu hücre için Downlink Alt Bant Ofseti
Gruplar

· DlReuse3Alt Bant Genişliği: Downlink Sayısında 3 Alt Bant Genişliği Yapılandırmasını Yeniden Kullanın
Kaynak Blok Grupları

· DlReuse1Alt Bant Genişliği: Downlink Sayısında 1 Alt Bant Genişliği Yapılandırmasını Yeniden Kullanın
Kaynak Blok Grupları

· RsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir.
kenar alt bandı

· MerkezAlanGüçOfseti: PdschConfigDedicated::Orta alt bant için Pa değeri, varsayılan
değer dB0

· EdgeAreaPowerOffset: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer
dB0

· DlCqiEşik: RBG için DL-CQI bu eşikten yüksekse iletim
RBG'de mümkün

· UlCqiEşik: RBG için UL-CQI bu eşikten yüksekse iletim
RBG'de mümkün

· MerkezAreaTpc: Merkez alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· EdgeAreaTpc: Kenar bölgesindeki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

Aşağıdaki örnekte DL ve UL'deki ofset 0 RB'dir, 4 RB kullanılacaktır Birincil Bölüm ve
ikincil Bölüm. Merkez ve kenar alanı arasındaki RSRQ eşiği 25 dB'dir. DL ve UL CQI
eşikler 10 değerine ayarlanmıştır. Orta alandaki güç eşittir LteEnbPhy::TxPower - 6dB,
kenar alanındaki güç eşittir 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));

Dağıtılmış kesirli Sıklık Yeniden Algoritma
Dağıtılmış Kesirli Frekansın Yeniden Kullanımı, tüm eNB'ler arasında X2 arayüzü gerektirir
Kurulmuş. X2 arayüzleri yalnızca EPC yapılandırıldığında kurulabilir, dolayısıyla bu FFR şeması
yalnızca EPC senaryolarıyla kullanılabilir.

Dağıtılmış Kesirli Frekans Yeniden Kullanım Algoritması ile eNb, hücre bant genişliğinin tamamını kullanır ve
iki alt bant olabilir: merkez alt bant ve kenar alt bant. Bu alt bantlar içerisinde UE'ler
farklı güç seviyelerinde servis edilebilir. Algoritma, hücre kenarı için RB'leri uyarlamalı olarak seçer
bitişik hücrelerden gelen koordinasyon bilgilerine (yani RNTP) dayanarak alt bant ve bildirimde bulunur
kenar alt bandında kullanmak üzere seçtiği RB'leri bitişik hücrelerin baz istasyonları. Eğer
Hücrede kenar UE olarak sınıflandırılan UE yoktur; eNB, kenar alt bandı olarak herhangi bir RB'yi kullanmayacaktır.

Dağıtılmış Kesirli Frekans Yeniden Kullanım Algoritması aşağıdaki özellikleri sağlar:

· HesaplamaAralığı: Kenar alt bandının hesaplanması arasındaki zaman aralığı, Varsayılan
değer 1 saniye

· RsrqEşik: RSRQ'su bu eşikten daha kötüyse UE'ye hizmet verilmelidir.
kenar alt bandı

· RsrpFark Eşiği: Alınan sinyalin gücü arasındaki fark
UE tarafından hizmet veren hücreden ve bitişik hücreden alınan sinyalin gücü
hücre RsrpDifferenceThreshold değerinden küçükse, hücre ağırlığı artırılır

· MerkezGüçOfseti: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer
dB0

· EdgePowerOffset: Kenar alt bandı için PdschConfigDedicated::Pa değeri, varsayılan değer dB0

· KenarRbNum: Kenar alt bandında kullanılabilecek RB sayısı

· MerkezAreaTpc: Merkez alandaki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

· EdgeAreaTpc: Kenar bölgesindeki UE'ler için DL-DCI'da ayarlanacak TPC değeri, Mutlak
modu kullanıldığında, varsayılan değer 1, TS1 Tablo 36.213-5.1.1.1'ye göre -2 ile eşlenir.

Aşağıdaki örnekte hesaplama aralığı 500 ms'dir. Merkez ve kenar arasındaki RSRQ eşiği
alanı 25'tir. RSRP Fark Eşiği 5 olarak ayarlanmıştır. DL ve UL'de 6 RB kullanılacaktır.
kenar alt bandındaki her hücre. Merkez alandaki güç eşittir LteEnbPhy::TxPower - 0dB, güç
kenar alanı eşittir LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("CalculationInterval", TimeValue(MiliSaniye(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));

Otomatik yapılandırma
Frekansın Yeniden Kullanımı algoritmaları, yalnızca ayarlanarak daha "otomatik" bir şekilde de yapılandırılabilir.
bant genişliği ve FrCellTypeId. FR örneğinin başlatılması sırasında, yapılandırma
bant genişliğini ayarlayın ve FrCellTypeId konfigürasyon tablosundan alınacaktır. Bu önemli
yalnızca alt bantların yapılandırılacağını, eşiklerin ve iletim gücünün
varsayılan değerler. İsteyen eşikleri ve iletim gücünü gösterildiği gibi değiştirebilir.
önceki alt bölümde.

Üç FrCellTypeId vardır: 1, 2, 3üç farklı konfigürasyona karşılık gelen
her bant genişliği için. Üç konfigürasyon, farklı konfigürasyonlara sahip olmanızı sağlar
altıgen eNB düzeninde komşu hücreler. Kullanıcının daha farklı olması gerekiyorsa
Komşu hücreler için yapılandırma gerekiyorsa, manuel yapılandırmayı kullanması gerekir.

Aşağıdaki örnekte otomatik FR algoritması yapılandırması gösterilmektedir:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0));

Uplink Power Control
Uplink Güç Kontrolü işlevi varsayılan olarak etkindir. Kullanıcı ayarlayarak bunu devre dışı bırakabilir
boole niteliği ns3::LteUePhy::EnableUplinkPowerControl doğru.

Kullanıcı Açık Döngü Güç Kontrolü ve Kapalı Döngü Güç Kontrolü mekanizmaları arasında geçiş yapabilir
boolean niteliğini ayarlayarak ns3::LteUePowerControl::ClosedLoop. Varsayılan olarak Kapalı
Biriktirme Moduyla Döngü Güç Kontrolü etkinleştirilir.

Yol kaybı, Uplink Güç Kontrolünün temel bileşenidir. Aradaki fark olarak hesaplanır
filtrelenmiş RSRP ve ReferenceSignalPower parametresi. ReferenceSignalPower SIB2 ile gönderilir.

Uplink Güç Kontrolünde mevcut olan özellikler:

· Kapalı Döngü: eğer gerçek Kapalı Döngü Uplink Güç Kontrolü modu etkinse ve Açık Döngü
Güç Kontrolü aksi takdirde varsayılan değer yanlıştır

· Biriktirme Etkin: eğer gerçek Toplama Modu etkinse ve Mutlak mod
aksi takdirde varsayılan değer false'tur

· Alfa: yol kaybı telafi faktörü, varsayılan değer 1.0'dır

· Pcmin: minimum UE TxPower, varsayılan değer -40 dBm'dir

· Pcmaks: maksimum UE TxPower, varsayılan değer 23 dBm'dir

· PoNominalPush: Bu parametrenin daha üst katmanlar tarafından ayarlanması gerekiyor, ancak şu anda buna ihtiyaç var
öznitelik sistemi tarafından yapılandırılacak olası değerler (-126 ...) aralığındaki tam sayılardır.
24), Varsayılan değer -80'dir

· PoUePusch: Bu parametrenin daha üst katmanlar tarafından ayarlanması gerekir, ancak şu anda ayarlanması gerekiyor
öznitelik sistemi tarafından yapılandırılabilir, olası değerler (-8 ... 7) aralığındaki tam sayılardır,
Varsayılan değer 0'dır

· PsrsOfset: Bu parametrenin daha üst katmanlar tarafından ayarlanması gerekir, ancak şu anda ayarlanması gerekiyor
öznitelik sistemi tarafından yapılandırılabilir, olası değerler (0 ... 15) aralığındaki tam sayılardır,
Varsayılan değer 7'dir, P_Srs_Offset_Value = 0'ı veren şey

İzlemeli değerlerimiz in Uplink Power Kontrol:

· RaporPuschTxPower: PUSCH için mevcut UE TxPower

· RaporPucchTxPower: PUCCH için mevcut UE TxPower

· RaporSrsTxPower: SRS için mevcut UE TxPower

Örnek konfigürasyon aşağıda sunulmuştur:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (true));
Config::SetDefault ("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (doğru));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (doğru));

Örnek olarak, kullanıcı lena-uplink-power-control programına göz atabilir ve çalıştırabilir.

Örnekler Programlar
Rehber src/lte/örnekler/ nasıl yapılacağını gösteren bazı örnek simülasyon programları içerir.
Farklı LTE senaryolarını simüle edin.

Referans senaryolar
Çok sayıda referans LTE simülasyon senaryosu mevcuttur.
edebiyat. İşte bunlardan bazılarını listeliyoruz:

· [TR2]'ün A.36814 bölümünde belirtilen sistem simülasyon senaryoları.

· Örnekte kısmen uygulanan çift şeritli model [R4-092042]
program src/lte/examples/lena-dual-stripe.cc. Bu örnek programda pek çok özellik bulunmaktadır
karşılık gelen genel değerleri değiştirerek özelleştirilebilen yapılandırılabilir parametreler
değişkenler. Tüm bu global değişkenlerin bir listesini almak için şu komutu çalıştırabilirsiniz:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

Aşağıdaki alt bölümde, aşağıdakileri kullanarak bir simülasyon kampanyası yürütme örneği sunulmaktadır:
bu örnek program.

Teslim et simülasyon kampanya
Bu alt bölümde, kullanarak bir simülasyon kampanyası yürütmenin bir örneğini göstereceğiz.
LTE modülü ns-3. Kampanyanın amacı her birinin etkisini karşılaştırmaktır.
LTE modülünün yerleşik devir algoritması.

Kampanyada kullanılacak lena-çift şerit örnek program. İlk önce, şunları değiştirmeliyiz
İhtiyacımız olan çıktıyı üreten örnek program. Bu süreçte üretmek istiyoruz
devir sayısı, kullanıcı ortalama verimi ve ortalama SINR.

Devir sayısı kaç kez sayılarak elde edilebilir? Devir BitişTamam
Teslim et ayak sesleri kovuldu. Daha sonra, kullanıcı ortalama verimi etkinleştirilerek elde edilebilir.
RLC Simulation Çıktı. Son olarak, PHY simülasyonu etkinleştirilerek SINR elde edilebilir.
çıktı. Aşağıdaki örnek kod parçacığı, yukarıdakileri elde etmenin olası bir yolunu göstermektedir:

geçersiz
NotifyHandoverEndOkUe (std::string bağlamı, uint64_t imsi,
uint16_t hücre kimliği, uint16_t rnti)
{
std::cout << "Devir IMSI " << imsi << std::endl;
}

int
ana (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 (Saniye (0)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (Seconds (simTime)));

Simülatör::Çalıştır ();
Simülatör::Yok Et ();
0 dönmek;
}

Daha sonra programın parametrelerini simülasyon ihtiyaçlarımıza uyacak şekilde yapılandırmamız gerekir. Biz
simülasyonumuzda aşağıdaki varsayımları arıyoruz:

· Altıgen şeklinde konuşlandırılmış üç sektörlü makro eNodeB'lerin (yani 7 makro hücre) 21 bölgesi
Siteler arası 500 m mesafeli yerleşim planı.

· Rağmen lena-çift şerit başlangıçta iki katmanlı (makro hücre ve
femtocell) simülasyonu, simülasyonumuzu tek katmanlı (makrosel) olarak basitleştireceğiz
yalnızca simülasyon.

· UE'ler sitelere rastgele dağıtılır ve ağa otomatik olarak bağlanır
Bekleme modu hücre seçimini kullanma. Bundan sonra UE simülasyon ortamında dolaşacak
60 km/saat hareket hızıyla.

· 50 saniyelik simülasyon süresi, yani UE'ler bazı tetiklemeleri tetikleyecek kadar uzağa gitmiş olabilir
devir teslimler.

· 46 dBm makrohücre Tx gücü ve 10 dBm UE Tx gücü.

· X2 aktarma prosedürü etkinleştirilmesini gerektirdiğinden EPC modu kullanılacaktır.

· Her ikisi de 5 MHz bant genişliğinde, TCP protokolünü kullanan tam arabellek aşağı bağlantı ve yukarı bağlantı trafiği
ve Orantılı Fuar planlayıcısı.

· İdeal RRC protokolü.

tablo lena-çift şerit parametre yapılandırma için teslim et kampanya aşağıda nasıl yaptığımızı gösteriyor
parametrelerini yapılandırın lena-çift şerit Yukarıdaki varsayımlara ulaşmak için.

lena-çift şerit parametre yapılandırma için teslim et kampanya
┌───────────────────┬─────────┬───────── ────────── ───────┐
│Parametre adı │ Değer │ Açıklama │
├───────────────────┼─────────┼───────── ────────── ───────┤
│simTime │ 50 │ 50 saniye simülasyon │
│ │ │ süre │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nBloklar │ 0 │ Apartmanın devre dışı bırakılması │
│ │ │ binalar ve femto hücreler │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nMacroEnbSites │ 7 │ Makrohücre sayısı │
│ │ │ siteler (her sitede 3 │ vardır)
│ │ │ hücreler) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│nMacroEnbSitesX │ 2 │ Makro hücre siteleri │
│ │ │ 2-3-2 │ şeklinde konumlandırılmalıdır
│ │ │ oluşumu │
├───────────────────┼─────────┼───────── ────────── ───────┤
│Siteler Arası Mesafe │ 500 │ 500 m arası mesafe │
│ │ │ bitişik makrohücre bölgeleri │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroEnbTxPowerDbm │ 46 │ Her biri için 46 dBm Tx gücü │
│ │ │ makrohücre │
├───────────────────┼─────────┼───────── ────────── ───────┤
│epc │ 1 │ EPC modunu etkinleştirin │
└───────────────────┴─────────┴───────── ────────── ───────┘

│epcDl │ 1 │ Tam arabellek DL'yi etkinleştir │
│ │ │ trafik │
├───────────────────┼─────────┼───────── ────────── ───────┤
│epcUl │ 1 │ Tam arabellek UL'yi etkinleştir │
│ │ │ trafik │
├───────────────────┼─────────┼───────── ────────── ───────┤
│useUdp │ 0 │ UDP trafiğini devre dışı bırakın ve │
│ │ │ bunun yerine TCP'yi etkinleştirin │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroUeDensity │ 0.00002 │ UE sayısını belirler │
│ │ │ (│ cinsinden 48 UE anlamına gelir)
│ │ │ simülasyonumuz) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│dış mekanUeMinSpeed ​​│ 16.6667 │ Minimum UE hareketi │
│ │ │ m/s cinsinden hız (60 km/saat) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ Maksimum UE hareketi │
│ │ │ m/s cinsinden hız (60 km/saat) │
├───────────────────┼─────────┼───────── ────────── ───────┤
│macroEnbBant genişliği │ 25 │ 5 MHz DL ve UL │
│ │ │ bant genişliği │
├───────────────────┼─────────┼───────── ────────── ───────┤
│generateRem │ 1 │ (İsteğe bağlı) Çizim için │
│ │ │ Radyo Ortamı │
│ │ │ Harita │
└───────────────────┴─────────┴───────── ────────── ───────┘

Gerekli varsayımlardan bazıları parametre olarak mevcut değildir. lena-çift şerit. içinde
bu durumda, Tabloda gösterildiği gibi varsayılan nitelikleri geçersiz kılarız. ağır basan varsayılan
öznitelikleri için teslim et kampanya altında.

ağır basan varsayılan öznitelikleri için teslim et kampanya
┌─────────────────────────────────────── ────────── ────┬────────────────────────────────┬── ────────── ──────────────┐
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::HandoverAlgorithm │ ns3::NoOpHandoverAlgoritması, │ Devir teslim seçimi │
│ │ ns3::A3RsrpHandoverAlgoritması, │ algoritma │
│ │ ns3::A2A4RsrqHandoverAlgoritması │ │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::Scheduler │ ns3::PfFfMacScheduler │ Orantılı Fuar │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ DL RLC için dosya adı │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ UL RLC için dosya adı │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrFilename │ -DlRsrpSinrStats.txt │ DL PHY için dosya adı │
├─────────────────────────────────────── ────────── ────┼────────────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ UL PHY için dosya adı │
└─────────────────────────────────────── ────────── ────┴────────────────────────────────┴── ────────── ──────────────┘

ns-3 Yapılandırma değerlerini bir simülasyona aktarmak için birçok yol sağlar. Bunda
örnek olarak komut satırı argümanlarını kullanacağız. Temel olarak şunu ekleyerek yapılır:
parametreler ve bunların değerleri WAF her bir simülasyonu başlatırken arayın. Bu yüzden
the WAF 3 simülasyonumuzu çağırmaya yönelik çağrılar aşağıdaki gibi görünecektir:

$ ./waf --run = "lena-çift şeritli
--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=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=op-DlRsrpSinrStats.txt yok
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > işlemsiz.txt

$ ./waf --run = "lena-çift şeritli
--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-çift şeritli
--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

İcraya ilişkin bazı notlar:

· Bazı argümanların zaten aynı oldukları için belirtilmediğine dikkat edin.
varsayılan değerler. Ayrıca devir algoritmalarını her birinin kendi varsayılan ayarlarında tutuyoruz.

· Simülasyon çıktısının dosya adlarını not edin, örneğin RLC izleri ve PHY izleri, çünkü biz
bir sonraki simülasyon çalıştırmasında bunların üzerine yazılmadığından emin olmanız gerekir. Bunda
örneğin, komut satırı argümanlarını kullanarak adları tek tek belirtiriz.

· --RngRun=1 sondaki argüman, tarafından kullanılan çalıştırma numarasını ayarlamak için kullanılır.
Simülasyonda kullanılan rastgele sayı üreteci. Aynı simülasyonları yeniden çalıştırıyoruz
farklı RngRun değerler, dolayısıyla aynı şeyin birkaç bağımsız kopyasını oluşturur
simülasyonlar. Daha sonra bu kopyalardan elde edilen sonuçların ortalamasını alırız.
bazı istatistiksel güven.

· Bir tane ekleyebiliriz --generateRem=1 oluşturmak için gerekli dosyaları oluşturmak için argüman
simülasyonun Radyo Ortam Haritası (REM). Sonuç Şekildir REM elde
itibaren a simülasyon in teslim et kampanya aşağıda takip edilerek üretilebilecek olan
Bölümde açıklanan adımlar radyo çevre Haritalar. Bu şekil aynı zamanda şunu da göstermektedir:
kullanarak bir simülasyonun başlangıcında eNodeB'lerin ve UE'lerin konumu RngRun = 1. Diğer
değerleri RngRun farklı UE konumu üretebilir.
[image] Devir kampanyasındaki bir simülasyondan elde edilen REM.UNINDENT

Saatlerce süren çalışmanın ardından simülasyon kampanyası sonunda sona erecek. Daha sonra yapacağız
Anlamlı bir sonuç elde etmek için üretilen simülasyon çıktısı üzerinde bazı son işlemler gerçekleştirin
bilgi ondan çıkar.

Bu örnekte, verim ve SINR verilerinin işlenmesine yardımcı olmak için GNU Octave'ı kullanıyoruz.
aşağıdaki örnek GNU Octave betiğinde gösterildiği gibi:

% RxBytes 10. sütundur
DlRxBytes = yük ("op-DlRlcStats.txt yok") (:,10);
DlAverageThroughputKbps = toplam (DlRxBytes) * 8/1000/50

% RxBytes 10. sütundur
UlRxBytes = load ("op-UlRlcStats.txt yok") (:,10);
UlAverageThroughputKbps = toplam (UlRxBytes) * 8/1000/50

% Sinr 6. sütundur
DlSinr = yük ("op-DlRsrpSinrStats.txt yok") (:,6);
% NaN değerlerini ortadan kaldırır
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (ortalama (DlSinr)) % dB'ye dönüştürür

% Sinr 5. sütundur
UlSinr = yük ("op-UlSinrStats.txt yok") (:,5);
% NaN değerlerini ortadan kaldırır
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (ortalama (UlSinr)) % dB'ye dönüştürür

Devir sayısına gelince, devir sayısını saymak için basit kabuk komut dosyası kullanabiliriz.
günlük dosyasında "Handover" dizesinin oluşumları:

$ grep "Devir" no-op.txt | tuvalet -l

tablo ÇIKTILAR of teslim et kampanya aşağıda işimiz bittikten sonraki istatistiklerin tamamı gösteriliyor
her simülasyon çalıştırmasında son işlemlerle. Gösterilen değerler ortalamadır
elde edilen sonuçların RngRun 1, 2, 3 ve 4.

ÇIKTILAR of teslim et kampanya
┌────────────────────┬────────────┬───── ────────┬─ ───────────────┐
│İstatistikler │ Ameliyatsız │ A2-A4-RSRQ │ En güçlü hücre │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Ortalama DL sistemi │ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│çıktı │ │ │ │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Ortalama UL sistemi │ 4 kbps │ 095 kbps │ 5 kbps │
│çıktı │ │ │ │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Ortalama DL SINR │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Ortalama UL SINR │ 9.54 dB │ 81.57 dB │ 79.65 dB │
├────────────────────┼────────────┼───── ────────┼─ ───────────────┤
│Devir sayısı │ 0 │ 0.05694 │ 0.04771 │
│UE başına saniye başına │ │ │ │
└────────────────────┴────────────┴───── ────────┴─ ───────────────┘

Sonuçlar, bir mobilite simülasyonunda bir devir algoritmasına sahip olmanın her ikisini de iyileştirdiğini göstermektedir.
kullanıcı verimini ve SINR'yi önemli ölçüde düşürdü. İkisi arasında çok az fark var
Bu kampanya senaryosunda devir algoritmaları. Onları görmek ilginç olurdu
Ev eNodeB dağıtımı senaryoları gibi farklı senaryolardaki performans.

Sıklık Yeniden örnekler
Frekans Yeniden Kullanım Algoritmalarının işlevselliğini gösteren iki örnek vardır.

lena-frekans-yeniden kullanım üçgen düzeninde 3 eNB'nin basit bir örneğidir. 3 hücre var
Bu üçgenin merkezinde yer alan kenar UE'ler ve 3 hücre merkezi UE (biri yakın)
her eNB). Kullanıcı ayrıca rastgele konumlandırılan UE'lerin sayısını da belirtebilir. FR algoritması
eNB'lere kuruludur ve her eNB'nin farklı FrCellTypeId'si vardır; bu, her eNB'nin kullandığı anlamına gelir
farklı FR konfigürasyonu. Kullanıcı çalıştırabilir lena-frekans-yeniden kullanım 6 farklı FR ile
algoritmalar: NoOp, Hard FR, Strict FR, Soft FR, Soft FFR ve Enhanced FFR. Senaryoyu çalıştırmak için
Dağıtılmış FFR algoritması ile kullanıcı şunu kullanmalıdır: lena-dağıtılmış-ffr. Bu iki örnek
çok benzerdir ancak Dağıtılmış FFR'nin kullanılması için EPC'nin kullanılması gerektiğinden bölünmüşlerdir,
ve diğer algoritmalar bunu yapmaz.

Koşmak lena-frekans-yeniden kullanım Farklı Frekans Yeniden Kullanım algoritmaları ile kullanıcının
varsayılan özniteliği geçersiz kılarak FR algoritmasını belirtin ns3::LteHelper::FfrAlgoritma.
Çalıştırılacak örnek komut lena-frekans-yeniden kullanım Soft FR algoritması ile aşağıda sunulmuştur:

$ ./waf --run "lena-frekans-yeniden kullanım --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

Bu örneklere REM ve spektrum analizörü izi oluşturma işlevi eklenmiştir.
Kullanıcı ayarlayarak bunun oluşturulmasını etkinleştirebilir üretRem ve createSpectrumTrace
Öznitellikler.

Veri kanalında RB 1 için REM oluşturma komutu lena-frekans-yeniden kullanım ile senaryo
Soft FR algoritması aşağıda sunulmuştur:

$ ./waf --run "lena-frekans-yeniden kullanım --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

Soft FR için Radyo Ortam Haritası Şekilde gösterilmektedir. REM için RB 1 elde itibaren
lena-frekans-yeniden kullanım örnek ile Yumuşak FR algoritma etkin.
[image] RB 1 için REM'den elde edildi lena-frekans-yeniden kullanım Soft FR algoritmalı örnek
etkin.UNINDENT

Spektrum izi oluşturma komutu lena-frekans-yeniden kullanım Soft FFR ile senaryo
algoritma aşağıda sunulmuştur (Spektrum Analizörü konumunun içeride yapılandırılması gerekir)
senaryo):

$ ./waf --run "lena-frekans-yeniden kullanım --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

Örnek spektrum analizörü izi şekilde gösterilmektedir Spektrum analizör iz elde
itibaren lena-frekans-yeniden kullanım örnek ile Yumuşak FFR algoritma sağladı. Spektrum analizör oldu
bulunan gerek eNB ile FrCellTypeId 2.. Görüldüğü gibi farklı veri kanalı alt bantları
kontrol kanalı ise farklı güç seviyeleriyle (konfigürasyona göre) gönderilir.
tüm sistem bant genişliği boyunca eşit güçle iletilir.
[image] Spektrum Analizörü izi şuradan elde edildi: lena-frekans-yeniden kullanım Yumuşak FFR ile örnek
algoritma etkinleştirildi. Spektrum Analizörünün FrCellTypeId 2..UNINDENT ile eNB'ye ihtiyacı olduğu belirlendi

lena-çift şerit tüm makrolarda yüklü Frekans Yeniden Kullanım algoritmaları ile de çalıştırılabilir
eNB. Kullanıcının varsayılan özniteliği geçersiz kılarak FR algoritmasını belirtmesi gerekir
ns3::LteHelper::FfrAlgoritma. Çalıştırılacak örnek komut lena-çift şerit Sert FR ile
algoritma aşağıda sunulmuştur:

$ ./waf --run = "lena-çift şeritli
--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=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=op-DlRsrpSinrStats.txt yok
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > işlemsiz.txt

Veri kanalındaki RB 1 için REM oluşturmaya yönelik örnek komut lena-çift şerit senaryo
Hard FR algoritması ile aşağıda sunulmuştur:

$ ./waf --run = "lena-çift şeritli
--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=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=op-DlRsrpSinrStats.txt yok
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

RB 1, 10 ve 20 için Radyo Çevre Haritaları oluşturuldu lena-çift şerit ile senaryo
Sabit Frekansın Yeniden Kullanımı algoritması aşağıdaki şekillerde sunulmaktadır. Bu RB seçildi
çünkü her biri farklı FR hücre tipi tarafından kullanılıyor.
[image] RB 1 için REM'den elde edildi lena-çift şerit Hard FR algoritması ile simülasyon
etkin.UNINDENT
[image] RB 10 için REM'den elde edildi lena-çift şerit Hard FR algoritması ile simülasyon
etkin.UNINDENT
[image] RB 20 için REM'den elde edildi lena-çift şerit Hard FR algoritması ile simülasyon
etkin.UNINDENT

Sorun giderme ve hata ayıklama ipuçları
Pek çok kullanıcı, ns-3 kullanıcılarının e-posta listesine, örneğin neden herhangi bir e-posta alamadıklarını soran gönderiler gönderir.
simülasyonlarında trafik var veya belki sadece yukarı bağlantı var ancak aşağı bağlantı trafiği yok, vb. Çoğu durumda
Bu durumda kullanıcı simülasyon programındaki bir hatadır. İşte hata ayıklamak için bazı ipuçları
Programı çalıştırın ve sorunun nedenini bulun.

Genel yaklaşım, ilgili verilerin günlüğe kaydedilmesini seçici ve aşamalı olarak etkinleştirmektir.
LTE modülü bileşenleri, her aktivasyonda çıktının beklendiği gibi olduğunu belirtir. İçinde
detay:

· öncelikle kontrol düzlemini, özellikle de RRC bağlantı kurulumunu kontrol edin
LteUeRrc ve LteEnbRrc günlük bileşenlerini etkinleştirerek prosedür

· ardından günlüğü etkinleştirerek veri düzlemindeki paket iletimlerini kontrol edin
LteUeNetDevice ve EpcSgwPgwApplication bileşenlerini, ardından EpcEnbApplication'ı ve ardından
LTE radyo yığınında (PDCP, RLC, MAC ve son olarak PHY) aşağı doğru hareket etmek. Bütün bunlar sana kadar
paketlerin nerede işlendiğini / iletildiğini bulun.

Test yapmak Dökümanlar
Genel Bakış
Ns-3 LTE modülünü test etmek ve doğrulamak için çeşitli test paketleri sağlanmıştır:
ns-3 test çerçevesiyle entegre edilmiştir. Bunları çalıştırmak için yapılandırmanız gerekir.
simülatörün bu şekilde oluşturulması:

$ ./waf yapılandırma --enable-tests --enable-modules=lte --enable-examples
$ ./test.py

Yukarıdakiler yalnızca LTE modülüne ait test paketlerini değil aynı zamanda bunları da çalıştıracaktır.
LTE modülünün bağlı olduğu diğer tüm ns-3 modüllerine aittir. ns-3'e bakın
Test çerçevesi hakkında genel bilgiler için kılavuz.

HTML formatında daha detaylı bir raporu şu şekilde alabilirsiniz:

$ ./test.py -w sonuçlar.html

Yukarıdaki komut çalıştırıldıktan sonra, her test için ayrıntılı sonucu açarak görüntüleyebilirsiniz.
Dosya sonuçlar.html bir web tarayıcısı ile.

Bu komutu kullanarak her bir test takımını ayrı ayrı çalıştırabilirsiniz:

$ ./test.py -s test takımı-adı

Hakkında daha fazla bilgi için test.py ve ns-3 test çerçevesi için lütfen ns-3'e bakın
manuel.

Tanım of the test suit
birim Testler
SINR hesaplama in the downlink
test takımı lte-downlink-sinr aşağı bağlantıdaki SINR hesaplamasının gerçekleştirilip gerçekleştirilmediğini kontrol eder
doğru şekilde. Aşağı bağlantıdaki SINR, verilere atanan her RB için hesaplanır
dikkate alınan eNB'den amaçlanan sinyalin gücünün,
gürültü gücünün toplamı artı aynı RB üzerinde diğer eNB'lerden gelen tüm iletimlerin toplamı
(parazit sinyalleri):

Genel olarak farklı sinyaller farklı zaman dilimlerinde aktif olabilir. Bir tanım yapıyoruz
yığın bir olayın başlangıcı veya bitişi türünden herhangi iki olay arasındaki zaman aralığı olarak
dalga biçimi. Başka bir deyişle, bir yığın, bir dizi öğenin bulunduğu bir zaman aralığını tanımlar.
aktif dalga formları değişmez. i genel parça olsun, T_i onun süresi ve
thm{SINR_i} yukarıdaki denklemle hesaplanan SINR'sidir. Ortalamanın hesaplanması
SINR rieme
Test paketi, yukarıdaki hesaplamanın simülatörde doğru şekilde gerçekleştirilip gerçekleştirilmediğini kontrol eder.
Test vektörleri, yukarıdakileri uygulayan bir Octave komut dosyasıyla çevrimdışı olarak elde edilir.
denklemdir ve bu, bir dizi rastgele iletilen sinyali ve girişimi yeniden yaratır.
Bir UE'nin bir eNB'den gelen bir sinyalin kodunu çözmeye çalıştığı bir senaryoyu taklit eden sinyaller
diğer eNB'lerin müdahalesiyle karşı karşıya. Hesaplanan değerler eşitse test başarılı olur
test vektörü 10^{-7} tolerans dahilindedir. Tolerans, aşağıdakileri hesaba katmak içindir:
kayan nokta aritmetiğine özgü yaklaşım hataları.

SINR hesaplama in the Uplink
test takımı lte-uplink-sinr uplink'teki SINR hesaplamasının gerçekleştirilip gerçekleştirilmediğini kontrol eder
doğru şekilde. Bu test paketi şununla aynıdır: lte-downlink-sinr önceki bölümde anlatılmıştı
bölümünde, hem sinyal hem de girişimden farklı olarak şimdi atıfta bulunulmaktadır.
UE'ler tarafından iletimler ve eNB tarafından alım gerçekleştirilir. Bu test paketi
taklit etmek için bir dizi rastgele iletilen sinyali ve girişim sinyalini yeniden oluşturur.
bir eNB'nin aynı anda birden fazla UE'den gelen sinyalin kodunu çözmeye çalıştığı senaryo (
eNB hücresindekiler) diğer UE'lerin (ait olanlar) müdahalesiyle karşı karşıya kalırken
diğer hücrelere).

Test vektörleri özel bir Octave komut dosyasıyla elde edilir. Eğer test geçerse
hesaplanan değerler 10^{-7} tolerans dahilinde test vektörüne eşittir;
aşağı bağlantı SINR testi, kayan nokta aritmetik yaklaşım sorunlarıyla ilgilenir.

E-UTRA kesin radyo Sıklık Telegram Kanal Numara (EARFCN)
test takımı lte-earfcn tarafından kullanılan taşıyıcı frekansı kontrol eder.
LteSpectrumValueHelper sınıfı (LTE spektrum modelini uygulayan) şu şekilde yapılır:
E-UTRA Mutlak Radyo Frekansı Kanal Numarasının olduğu [TS36101] ile uyumluluk
(EARFCN) tanımlanır. Bu test paketinin test vektörü bir dizi EARFCN değerinden oluşur
ve spesifikasyona göre elle hesaplanan karşılık gelen taşıyıcı frekansı
[TS36101]. LteSpectrumValueHelper tarafından döndürülen taşıyıcı frekansı şu olursa test başarılı olur:
test vektöründeki her öğe için bilinen değerle aynıdır.

sistem Testler
Dedicated taşıyıcı etkisizleştirme Testler
'Lte-test-deactivate-bearer' test paketi, tek EnodeB ve Üç ile test senaryosu oluşturur
UE'ler. Her UE, aynı taşıyıcıya sahip bir Varsayılan ve bir Özel EPS taşıyıcısından oluşur
spesifikasyonu ancak farklı ARP ile. Test Senaryosu Akışı şu şekildedir: UE Ekle -> Oluştur
Varsayılan+Atanmış Taşıyıcı -> Atanmış taşıyıcılardan birini devre dışı bırakın

Test senaryosu ayrıca taşıyıcı kimliği 2'ye (LCID=BearerId+2) sahip özel taşıyıcıyı devre dışı bırakır.
İlk UE (UE_ID=1) Kullanıcı, aşağıdakileri kullanarak taşıyıcının devre dışı bırakılmasını belirli bir zaman gecikmesinden sonra programlayabilir:
Simulator::Schedule () yöntemi.

Test senaryosunun yürütülmesi sona erdiğinde DlRlcStats.txt ve UlRlcStats.txt oluşturulacaktır. Anahtar
İstatistiklerde kontrol edilmesi gereken alanlar şunlardır:

|
Başlat | sonu | Hücre Kimliği | IMSI | RNTI | LCDID | TxBytes | RxBytes |

Test senaryosu üç dönemde yürütülür. 1) İlk Epoch'ta (0.04s-1.04s) Tüm UE'ler ve
karşılık gelen taşıyıcılar eklenir
ve tahsis edilmiş taşıyıcılar üzerinden paket akışı etkinleştirildi.

2. İkinci Epoch'ta (1.04s-2.04s), taşıyıcının devre dışı bırakılması başlatılır, böylece Kullanıcı görebilir
diğer taşıyıcılara kıyasla UE_ID=1 ve LCID=4 üzerinde nispeten daha az sayıda TxByte.

3. Üçüncü Epoch'ta (2.04s-3.04s), UE_ID=1 ve LCID=4'ün taşıyıcının devre dışı bırakılmasından bu yana
tamamlandığında kullanıcı LCID=4 ile ilgili herhangi bir günlük kaydı görmeyecektir.

Test senaryosu ancak ve ancak 1) IMSI=1 ve LCID=4'ün üçüncü dönemde tamamen kaldırılması durumunda başarılı olur 2)
IMSI=1 ve LCID=4'e karşılık gelen TxBytes ve RxBytes'ta hiçbir paket görülmedi. Yukarıdaki ise
kriter, başarısız olduğu düşünülen test durumuyla eşleşmiyor

Adaptif Modülasyon ve kodlama Testler
test takımı lte-link-adaptasyonu bir senaryoyu yeniden yaratan sistem testleri sağlar.
tek eNB ve tek bir UE. Farklı durumlara karşılık gelen farklı test senaryoları oluşturulur
UE tarafından algılanan SNR değerleri. Testin amacı, her test senaryosunda
seçilen MCS bilinen bazı referans değerlerine karşılık gelir. Bu referans değerleri elde edilir
Octave'da yeniden uygulayarak (bkz. src/lte/test/reference/lte_amc.m)'de açıklanan model
Spektral verimliliğin hesaplanması ve belirlenmesi için bölüm sec-lte-amc
[R1-081483] içindeki tablolara manuel olarak bakarak karşılık gelen MCS indeksini bulun. Sonuç
test vektörü Şekilde gösterilmektedir test vektör için Adaptif Modülasyon ve kodlama.

Simülatör tarafından kullanılan MCS, izleme çıktısı alınarak ölçülür.
4 ms sonra zamanlayıcı tarafından üretilir (bu, programdaki ilk gecikmeyi hesaba katmak için gereklidir).
CQI raporlaması). Simülatör tarafından hesaplanan SINR ayrıca aşağıdaki formül kullanılarak elde edilir:
LteChunk İşlemci arayüz. Aşağıdaki koşulların her ikisi de sağlanırsa test başarılı olur
memnun:

1. Simülatör tarafından hesaplanan SINR, test vektörünün SNR'sine karşılık gelir.
10^{-7}'lik mutlak tolerans;

2. Simülatör tarafından kullanılan MCS indeksi, testteki indekse tam olarak karşılık gelir
vektör.
[image] Uyarlanabilir Modülasyon ve Kodlama için test vektörü.UNINDENT

hücreler arası Girişim Testler
test takımı lte girişimi hücreler arası iletişimi yeniden yaratan sistem testleri sağlar
her biri kendisine bağlı tek bir UE'ye sahip olan ve
Hem aşağı bağlantıda hem de yukarı bağlantıda Uyarlanabilir Modülasyon ve Kodlama. Topolojisi
Senaryo Şekilde gösterilmektedir Topoloji için the hücreler arası girişim test. d_1
parametresi her bir UE'nin bağlı olduğu eNB'ye olan mesafesini temsil ederken d_2
parametre girişim mesafesini temsil eder. Senaryo topolojisinin şu şekilde olduğunu not ediyoruz:
girişim mesafesinin yukarı bağlantı ve aşağı bağlantı için aynı olduğu; yine de gerçek
Farklı yayılma kayıpları nedeniyle algılanan girişim gücü farklı olacaktır.
Yukarı bağlantı ve aşağı bağlantı bantlarında. d_1 değiştirilerek farklı test durumları elde edilir ve
d_2 parametreleri.
[image] Hücreler arası girişim testi için topoloji.UNINDENT

Test vektörleri özel bir oktav komut dosyası kullanılarak elde edilir (şu adreste mevcuttur):
src/lte/test/reference/lte_link_budget_interference.m), bağlantı bütçesini sağlayan
her test senaryosunun topolojisine karşılık gelen hesaplamalar (parazit dahil),
ve elde edilen SINR ve spektral verimliliğin çıktısını verir. İkincisi daha sonra kullanılır
belirlemek (için benimsenen prosedürün aynısını kullanarak) Adaptif Modülasyon ve kodlama Testler. Biz
test vektörünün yukarı bağlantı ve aşağı bağlantı için ayrı değerler içerdiğine dikkat edin.

UE Ölçümler Testler
test takımı lte-ue-ölçümleri hücreler arası iletişimi yeniden yaratan sistem testleri sağlar
için tanımlananla aynı girişim senaryosu lte girişimi test odası.
Ancak bu testte test edilecek miktarlar RSRP ve RSRQ ile temsil edilir.
UE tarafından yığının iki farklı noktasında gerçekleştirilen ölçümler: kaynak,
UE PHY katmanıdır ve hedef, yani eNB RRC'dir.

Test vektörleri, özel bir oktav komut dosyası kullanılarak elde edilir (şu adreste mevcuttur):
src/lte/test/reference/lte-ue-measurements.m), bağlantı bütçesi hesaplamalarını yapan
(parazit dahil) her test durumunun topolojisine karşılık gelir ve
sonuçta ortaya çıkan RSRP ve RSRQ. Elde edilen değerler daha sonra doğruluğu kontrol etmek için kullanılır.
PHY katmanındaki UE Ölçümleri. Bundan sonra 3GPP'ye göre dönüştürülmeleri gerekir.
eNB RRC düzeyinde doğruluğunun kontrol edilmesi amacıyla biçimlendirme.

UE ölçüm yapılandırma testleri
Daha önce bahsedilen test paketinin yanı sıra, UE'yi test etmek için 3 test paketi daha vardır
ölçümler: lte-ue-ölçümler-parçalı-1, lte-ue-ölçümler-parçalı-2, ve
lte-ue-ölçümler-devir. Bu test paketleri daha çok raporlama tetikleyicisine odaklanmıştır
prosedür, yani olaya dayalı tetiklemenin uygulanmasının doğruluğu
Kriterler burada doğrulanır.

Daha spesifik olarak, testler şunları doğrular: zamanlama ve içerik her ölçüm raporunun
eNodeB tarafından alındı. Her test senaryosu bağımsız bir LTE simülasyonudur ve test senaryosu
Ölçüm rapor(lar)ı yalnızca belirlenen zamanda oluşuyorsa ve doğru sonuçları gösteriyorsa geçer
RSRP düzeyi (RSRQ şu anda doğrulanmadı).

Parçalı yapılandırma
Parçalı konfigürasyon, belirli bir UE ölçüm konfigürasyonunu test etmeyi amaçlar.
simülasyon komut dosyası, ilgili ölçüm konfigürasyonunu UE'ye ayarlayacaktır;
simülasyon boyunca aktif olacaktır.

Referans değerleri elle önceden hesaplandığından, çeşitli varsayımlar yapılır.
simülasyonu basitleştirin. Öncelikle kanal sadece yol kaybı modelinden etkilenir (bu modelde
durumunda Friis modeli kullanılır). İkinci olarak ideal RRC protokolü kullanılır ve katman 3
filtreleme devre dışı bırakılır. Son olarak UE, 4 ile XNUMX arasında önceden tanımlanmış bir hareket modelinde hareket eder.
Şekilde gösterildiği gibi farklı noktalar UE hareket iz boyunca the simülasyon in
parçalı yapılandırma altında. Bu nedenle ölçülen RSRP'deki dalgalanma şu şekilde olabilir:
daha kolay belirlenir.
[image] Parçalı konfigürasyonda simülasyon boyunca UE hareket izi.UNINDENT

Arkasındaki motivasyon "ışınlanma" önceden tanımlanmış noktalar arasına tanıtmaktır
Giriş veya çıkışın tetiklenmesini garanti edecek RSRP düzeyinde ciddi değişiklik
test edilen olayın durumu. Köklü değişiklikler gerçekleştirilerek test,
daha kısa süre.

şekil Ölçülü LCV iz of an örnek Etkinlikler A1 test dava in parçalı yapılandırma
aşağıda, PHY katmanı tarafından katman 1 filtrelemesinden sonra ölçülen RSRP'yi göstermektedir.
parçalı konfigürasyonlu simülasyon. Katman 3 filtreleme devre dışı bırakıldığı için bunlar
raporlama tetikleyicisini değerlendirmek için UE RRC örneği tarafından kullanılan tam değerlerdir
prosedür. Değerlerin varsayılan olarak her 200 ms'de bir yenilendiğine dikkat edin.
PHY katmanı ölçümleri raporunun filtreleme süresi. Şekil aynı zamanda ne zaman olduğunu da gösterir.
Olay A1'in örnek bir örneğinin giriş ve çıkış koşulları (hizmet veren hücre,
simülasyon sırasında eşikten daha iyi) meydana gelir.
[image] Örnek Olay A1 test senaryosunun parçalı olarak ölçülen RSRP izi
yapılandırma.UNINDENT

Her raporlama kriteri farklı eşik/denklik ile birkaç kez test edilir
parametreler. Bazı test senaryoları ayrıca gecikmeyi ve tetiklenme süresini de hesaba katar.
şekil Ölçülü LCV iz of an örnek Etkinlikler A1 ile gecikme test dava in parçalı
yapılandırma Olay A1 testinin başka bir örneğinde histerezisin etkisini göstermektedir.
[image] Histerezis test senaryosu içeren örnek Olay A1'in ölçülen RSRP izi
parçalı konfigürasyon.UNINDENT

Parçalı konfigürasyon, UE ölçümlerinin iki test paketinde kullanılır. Birincisi
lte-ue-ölçümler-parçalı-1, bundan böyle 1 UE'yi simüle eden Parçalı test #1 ve
1 eNodeB. Diğeri ise lte-ue-ölçümler-parçalı-21 UE ve 2 eNodeB'ye sahip olan
simülasyonda.

Parçalı test #1, bağımlı olmayan olaya dayalı kriterleri test etmeyi amaçlamaktadır.
Komşu bir hücrenin varlığı hakkında. Bu kriterler Olay A1 ve A2'yi içerir.
diğer olaylar da hâlâ düzgün çalıştıklarını doğrulamak için kısa süreliğine test edilir
(her ne kadar hiçbir şey bildirmese de) herhangi bir komşu hücrenin yokluğunda. Masa UE
ölçümler test senaryolar kullanma parçalı yapılandırma #1 aşağıda senaryolar listelenmektedir
parçalı test #1'de test edildi.

UE ölçümler test senaryolar kullanma parçalı yapılandırma #1
┌───────┬───────────┬──────────────────┬ ────────── ──┬─────────────────┐
│Test # │ Raporlama │ Eşik/Ofset │ Histerezis │ Tetikleme Süresi │
│ │ Kriterler │ │ │ │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│1 │ Olay A1 │ Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│2 │ Olay A1 │ Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│3 │ Olay A1 │ Normal │ Hayır │ Kısa │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│4 │ Olay A1 │ Normal │ Hayır │ Uzun │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│5 │ Olay A1 │ Normal │ Hayır │ Süper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│6 │ Olay A1 │ Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│7 │ Olay A1 │ Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│8 │ Olay A2 │ Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│9 │ Olay A2 │ Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│10 │ Olay A2 │ Normal │ Hayır │ Kısa │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│11 │ Olay A2 │ Normal │ Hayır │ Uzun │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│12 │ Olay A2 │ Normal │ Hayır │ Süper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│13 │ Olay A2 │ Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│14 │ Olay A2 │ Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│15 │ Olay A3 │ Sıfır │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│16 │ Olay A4 │ Normal │ Hayır │ Hayır │
└───────┴───────────┴──────────────────┴ ────────── ──┴─────────────────┘

│17 │ Olay A5 │ Normal-Normal │ Hayır │ Hayır │
└───────┴───────────┴──────────────────┴ ────────── ──┴─────────────────┘

Olay A3, A4 ve A5 gibi diğer olaylar komşu hücrenin ölçümlerine bağlıdır, dolayısıyla
Parçalı test #2'de daha kapsamlı bir şekilde test edilirler. Simülasyon düğümleri bir yere yerleştirir.
düz bir çizgi çizin ve UE'ye talimat verin "zıplamak" Parçalı test #1'dekine benzer şekilde.
Simülasyonda devir devre dışı bırakıldığından, hizmet veren hücrelerin ve komşu hücrelerin rolü
simülasyon sırasında geçiş yapmayın. Masa UE ölçümler test senaryolar kullanma parçalı
yapılandırma #2 aşağıda Parçalı test #2'de test edilen senaryolar listelenmektedir.

UE ölçümler test senaryolar kullanma parçalı yapılandırma #2
┌───────┬───────────┬──────────────────┬ ────────── ──┬─────────────────┐
│Test # │ Raporlama │ Eşik/Ofset │ Histerezis │ Tetikleme Süresi │
│ │ Kriterler │ │ │ │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│1 │ Olay A1 │ Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│2 │ Olay A1 │ Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│3 │ Olay A1 │ Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│4 │ Olay A1 │ Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│5 │ Olay A2 │ Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│6 │ Olay A2 │ Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│7 │ Olay A2 │ Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│8 │ Olay A2 │ Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│9 │ Olay A3 │ Olumlu │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│10 │ Olay A3 │ Sıfır │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│11 │ Olay A3 │ Sıfır │ Hayır │ Kısa │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│12 │ Olay A3 │ Sıfır │ Hayır │ Süper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│13 │ Olay A3 │ Sıfır │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│14 │ Olay A3 │ Olumsuz │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│15 │ Olay A4 │ Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│16 │ Olay A4 │ Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│17 │ Olay A4 │ Normal │ Hayır │ Kısa │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│18 │ Olay A4 │ Normal │ Hayır │ Süper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│19 │ Olay A4 │ Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│20 │ Olay A4 │ Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│21 │ Olay A5 │ Düşük-Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│22 │ Olay A5 │ Düşük-Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│23 │ Olay A5 │ Düşük-Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│24 │ Olay A5 │ Normal-Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│25 │ Olay A5 │ Normal-Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│26 │ Olay A5 │ Normal-Normal │ Yok │ Kısa │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│27 │ Olay A5 │ Normal-Normal │ Hayır │ Süper │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│28 │ Olay A5 │ Normal-Normal │ Evet │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│29 │ Olay A5 │ Normal-Yüksek │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│30 │ Olay A5 │ Yüksek-Düşük │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│31 │ Olay A5 │ Yüksek-Normal │ Hayır │ Hayır │
├───────┼───────────┼──────────────────┼ ────────── ──┼─────────────────┤
│32 │ Olay A5 │ Yüksek-Yüksek │ Hayır │ Hayır │
└───────┴───────────┴──────────────────┴ ────────── ──┴─────────────────┘

Tetiklenmeye kadar geçen süreye sahip testlerle ilgili bir not: 3 farklı değer kullanılarak test edilirler.
tetiklenme süresi: kısa (rapor aralığından daha kısa), ve kazandırdı (filtreden daha kısa
200 ms ölçüm süresi) ve Süper (200 ms'den uzun). İlk ikisi bunu sağlar
tetiklenmeye kadar geçen süre değerlendirmesi her zaman PHY'den alınan en son ölçüm raporlarını kullanır
katman. Sonuncusu, tetikleme iptaline kadar geçen sürenin doğrulanmasından sorumlu olsa da,
örneğin PHY'den gelen bir ölçüm raporu giriş/çıkış koşulunun olmadığını gösterdiğinde
İlk tetik tetiklenmeden önce artık doğru.

Teslim et yapılandırma
Devir yapılandırmasının amacı, UE ölçümünün geçerli olup olmadığını doğrulamaktır.
Başarılı bir devir işlemi gerçekleştikten sonra yapılandırma düzgün şekilde güncellenir. Bunun için
Bu amaçla simülasyon, farklı UE ölçümlerine sahip 2 eNodeB oluşturacaktır.
konfigürasyon ve UE bir hücreden diğerine aktarım gerçekleştirecektir. UE olacak
2 eNodeB arasında düz bir çizgi üzerinde yer alır ve devir işlemi başlatılır
manuel olarak. Her simülasyonun süresi 2 saniyedir (son test durumu hariç) ve
devir teslim simülasyonun tam yarısında tetiklenir.

The lte-ue-ölçümler-devir test paketi çeşitli konfigürasyon türlerini kapsar
farklılıklar. Bunlardan ilki rapor aralığındaki farktır; örneğin ilk eNodeB
480 ms rapor aralığı ile yapılandırılmışken, ikinci eNodeB 240 ms ile yapılandırılmıştır
rapor aralığı. Bu nedenle, UE ikinci hücreye devir işlemini gerçekleştirdiğinde, yeni
rapor aralığı geçerli olmalıdır. Parçalı konfigürasyonda olduğu gibi, zamanlama ve
eNodeB tarafından alınan her ölçüm raporunun içeriği doğrulanacaktır.

Test paketinin kapsadığı diğer farklılık türleri olay ve
eşik/ofset farklılıkları. Masa UE ölçümler test senaryolar kullanma teslim et
yapılandırma aşağıda test edilen senaryolar listelenmektedir.

UE ölçümler test senaryolar kullanma teslim et yapılandırma
──────────────────────────────────────────── ────────────────────
Test # Test Konusu İlk Devir Sonrası
Yapılandırma Yapılandırması
──────────────────────────────────────────── ────────────────────
1 Rapor aralığı 480 ms 240 ms
──────────────────────────────────────────── ────────────────────
2 Rapor aralığı 120 ms 640 ms
──────────────────────────────────────────── ────────────────────
3 Olay Olay A1 Olay A2
──────────────────────────────────────────── ────────────────────
4 Olay Olay A2 Olay A1
──────────────────────────────────────────── ────────────────────
5 Olay Olay A3 Olay A4
──────────────────────────────────────────── ────────────────────
6 Olay Olay A4 Olay A3
──────────────────────────────────────────── ────────────────────
7 Olay Olay A2 Olay A3
──────────────────────────────────────────── ────────────────────
8 Olay Olay A3 Olay A2
──────────────────────────────────────────── ────────────────────
9 Olay Olay A4 Olay A5
──────────────────────────────────────────── ────────────────────
10 Olay Olay A5 Olay A4
──────────────────────────────────────────── ────────────────────
11 Eşik/ofset RSRP aralığı 52 RSRP aralığı 56
(Olay A1) (Olay A1)
──────────────────────────────────────────── ────────────────────
12 Eşik/ofset RSRP aralığı 52 RSRP aralığı 56
(Olay A2) (Olay A2)
──────────────────────────────────────────── ────────────────────
13 Eşik/ofset A3 ofseti -30 A3 ofseti +30
(Olay A3) (Olay A3)
──────────────────────────────────────────── ────────────────────
14 Eşik/ofset RSRP aralığı 52 RSRP aralığı 56
(Olay A4) (Olay A4)
──────────────────────────────────────────── ────────────────────
15 Eşik/ofset RSRP aralığı 52-52 RSRP aralığı 56-56
(Olay A5) (Olay A5)
──────────────────────────────────────────── ────────────────────
16 Tetikleme süresi 1024 ms 100 ms
──────────────────────────────────────────── ────────────────────
17 Tetikleme süresi 1024 ms 640 ms
┌───────┬──────────────────┬──────────── ─────────┬ ─────────────────────┐
│ │ │ │ │
İkili dosya (standart giriş) eşleşmeleri

Onworks.net hizmetlerini kullanarak ns-3-model-library'yi çevrimiçi kullanın