ns-3-model-library - آنلاین در ابر

برنامه:

نام

ns-3-model-library - ns-3 Model Library

این است ns-3 مدل کتابخانه مستندات. اسناد اولیه برای پروژه ns-3
به پنج شکل موجود است:

· ns-3 اکسیژن: مستندسازی APIهای عمومی شبیه ساز

· آموزش، راهنما، و کتابخانه مدل (این سند) برای آخرین آزاد و
توسعه درخت

· ns-3 ویکی

این سند در نوشته شده است restructuredText برای مجسمه ابوالهول و در آن نگهداری می شود
سند/مدل دایرکتوری کد منبع ns-3.

سازمان

این راهنما اسناد را برای ns-3 مدل ها و نرم افزارهای پشتیبان که فعال می کنند
کاربران برای ساخت شبیه سازی شبکه مهم است که بین آنها تمایز قائل شویم ماژول ها
و مدل:

· ns-3 نرم افزار به صورت جداگانه سازماندهی شده است ماژول ها که هر کدام به صورت جداگانه ساخته شده اند
کتابخانه نرم افزار برنامه های فردی ns-3 می توانند ماژول ها (کتابخانه ها) مورد نیاز خود را پیوند دهند
برای انجام شبیه سازی آنها

· ns-3 مدل نمایش های انتزاعی از اشیاء، پروتکل ها، دستگاه ها و غیره در دنیای واقعی هستند.

An ns-3 ماژول ممکن است از بیش از یک مدل (به عنوان مثال، اینترنت واحد
شامل مدل هایی برای TCP و UDP است). به طور کلی، مدل‌های ns-3 چندتایی را پوشش نمی‌دهند
با این حال، ماژول های نرم افزاری.

این راهنما مستنداتی را در مورد مدل های ارائه می دهد ns-3. این مکمل دو مورد دیگر است
منابع مستند در مورد مدل ها:

· APIهای مدل، از منظر برنامه نویسی، با استفاده از مستندسازی می شوند اکسیژن. داکسیژن
برای مدل های ns-3 موجود است on la پروژه وب سرور.

· ns-3 هسته در کتابچه راهنمای توسعه دهنده مستند شده است. ns-3 مدل ها از
امکانات هسته، مانند ویژگی ها، مقادیر پیش فرض، اعداد تصادفی، تست
چارچوب ها، و غیره. مشورت کنید اصلی وب سایت برای پیدا کردن کپی از راهنما

در نهایت، اسناد اضافی در مورد جنبه های مختلف ns-3 ممکن است بر روی وجود داشته باشد پروژه
ویکی.

یک طرح کلی از نحوه نوشتن اسناد کتابخانه مدل را می توان با اجرای آن پیدا کرد
create-module.py برنامه و نگاه کردن به قالب ایجاد شده در فایل
new-module/doc/new-module.rst.

$ سی دی src
$ ./create-module.py new-module

بقیه این سند بر اساس نام ماژول بر اساس حروف الفبا سازماندهی شده است.

اگر شما تازه به ns-3، ممکن است ابتدا بخواهید در زیر در مورد ماژول شبکه بخوانید که
شامل چند مدل اساسی برای شبیه ساز است. مدل بسته، مدل برای
فرمت های مختلف آدرس و کلاس های پایه انتزاعی برای اشیایی مانند گره ها، net
دستگاه ها، کانال ها، سوکت ها و برنامه ها در آنجا مورد بحث قرار می گیرند.

انیمیشن

انیمیشن ابزار مهمی برای شبیه سازی شبکه است. در حالی که ns-3 حاوی a نیست
ابزار پیش فرض انیمیشن گرافیکی، ما در حال حاضر دو راه برای ارائه انیمیشن داریم، یعنی
با استفاده از روش PyViz یا روش NetAnim. روش PyViz در شرح داده شده است
http://www.nsnam.org/wiki/PyViz.

در اینجا روش NetAnim را به اختصار شرح می دهیم.

NetAnim
NetAnim یک نرم افزار اجرایی مستقل و مبتنی بر Qt4 است که از یک فایل ردیابی تولید شده استفاده می کند.
در طول یک ns-3 شبیه سازی برای نمایش توپولوژی و متحرک سازی جریان بسته بین
گره ها
[تصویر] نمونه ای از انیمیشن بسته در پیوندهای سیمی.UNINDENT

علاوه بر این، NetAnim همچنین ویژگی های مفیدی مانند جداول برای نمایش متا داده ها را ارائه می دهد
بسته هایی مانند تصویر زیر
[تصویر] نمونه ای از جداول برای فراداده بسته با فیلترهای پروتکل.UNINDENT

راهی برای تجسم مسیر یک گره متحرک
[تصویر] نمونه ای از مسیر یک گره متحرک.UNINDENT

راهی برای نمایش جداول مسیریابی چندین گره در مقاطع مختلف زمانی
[تصویر]

راهی برای نمایش شمارنده های مرتبط با چندین گره به صورت نمودار یا جدول
[تصویر]
[تصویر]

راهی برای مشاهده جدول زمانی رویدادهای ارسال و دریافت بسته
[تصویر]

روش شناسی
کلاس ns3::AnimationInterface مسئول ایجاد فایل trace XML است.
AnimationInterface از زیرساخت ردیابی برای ردیابی جریان بسته بین گره ها استفاده می کند.
AnimationInterface خود را به عنوان یک قلاب ردیابی برای رویدادهای tx و rx قبل از ثبت می کند
شبیه سازی آغاز می شود هنگامی که یک بسته برای ارسال یا دریافت برنامه ریزی شده است،
قلاب های مربوط به ردیابی tx و rx در AnimationInterface نامیده می شوند. هنگامی که rx قلاب می شود
AnimationInterface از دو نقطه پایانی که بسته بین آنها وجود دارد آگاه خواهد بود
جریان یافته است، و این اطلاعات را به فایل ردیابی، در قالب XML به همراه فایل اضافه می کند
مهرهای زمانی tx و rx مربوطه. قالب XML در بخش بعدی مورد بحث قرار خواهد گرفت.
توجه به این نکته ضروری است که AnimationInterface یک بسته را فقط در صورتی ضبط می کند که ردیابی rx باشد
قلاب نامیده می شود. هر رویداد tx باید با یک رویداد rx مطابقت داشته باشد.

دانلود NetAnim
اگر NetAnim در حال حاضر در دسترس نیست ns-3 بسته ای که دانلود کردید، می توانید این کار را انجام دهید
زیر است:

لطفا مطمئن شوید که مرکوریال را نصب کرده اید. آخرین نسخه NetAnim می تواند باشد
با استفاده از مرکوریال با دستور زیر دانلود می شود:

کلون دلار جیوه http://code.nsnam.org/netanim

بنا NetAnim
پیش نیازها
Qt4 (4.7 و بالاتر) برای ساخت NetAnim مورد نیاز است. این را می توان با استفاده از موارد زیر بدست آورد
راه ها:

برای توزیع های Debian/Ubuntu Linux:

$ apt-get نصب qt4-dev-tools

برای توزیع مبتنی بر Red Hat/Fedora:

$ yum نصب qt4
$ yum نصب qt4-devel

برای Mac/OSX، نگاه کنید http://qt.nokia.com/downloads/

ساختن مراحل
برای ساخت NetAnim از دستورات زیر استفاده کنید:

$ سی دی netanim
$ تمیز کردن
$ qmake NetAnim.pro (برای کاربران MAC: qmake -spec macx-g++ NetAnim.pro)
$ ساخت

توجه: qmake می تواند در برخی از سیستم ها "qmake-qt4" باشد

این باید یک فایل اجرایی به نام "NetAnim" در همان دایرکتوری ایجاد کند:

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

استفاده
استفاده از NetAnim یک فرآیند دو مرحله ای است

مرحله 1: فایل ردیابی XML انیمیشن را در طول شبیه سازی با استفاده از آن ایجاد کنید
"ns3::AnimationInterface" در ns-3 پایه کد

مرحله 2: فایل ردیابی XML ایجاد شده در مرحله 1 را با انیماتور آفلاین مبتنی بر Qt4 بارگیری کنید
به نام NetAnim.

گام 1: تولید XML انیمیشن رد پرونده
کلاس "AnimationInterface" در زیر "src/netanim" از زیرین استفاده می کند ns-3 ردیابی منابع به
یک فایل ASCII مهر زمانی در قالب XML بسازید.

نمونه ها در زیر src/netanim/examples یافت می شوند. مثال:

$ ./waf -d debug configure --enable-examples
$ ./waf -- run "dumbbell-animation"

موارد فوق یک فایل XML dumbbell-animation.xml ایجاد می کند

اجباری
1. مطمئن شوید که wscript برنامه شما شامل ماژول "netanim" باشد. نمونه ای از این قبیل
wscript در src/netanim/examples/wscript قرار دارد.

2. هدر [#include "ns3/netanim-module.h"] را در برنامه آزمایشی خود قرار دهید

3. بیانیه را اضافه کنید

AnimationInterface anim ("animation.xml"); // که در آن "animation.xml" هر نام فایل دلخواه است

[برای نسخه‌های قبل از ns-3.13 نیز باید از خط «anim.SetXMLOutput() برای تنظیم
حالت XML و همچنین از anim.StartAnimation();]

اختیاری
مراحل زیر اختیاری اما مفید هستند:

// مرحله 1
anim.SetMobilityPollInterval (ثانیه (1));

AnimationInterface موقعیت تمام گره ها را هر 250 میلی ثانیه به صورت پیش فرض ثبت می کند. را
بیانیه بالا بازه تناوبی را که AnimationInterface در آن ثبت می کند را تعیین می کند
موقعیت همه گره ها اگر انتظار می رود گره ها حرکت بسیار کمی داشته باشند، تنظیم آن مفید است
فاصله نظرسنجی با تحرک بالا برای جلوگیری از فایل های XML بزرگ.

// مرحله 2
anim.SetConstantPosition (Ptr< Node > n, double x, double y);

AnimationInterface مستلزم این است که موقعیت همه گره ها تنظیم شود. که در ns-3 این کار توسط
تنظیم MobilityModel مرتبط "SetConstantPosition" راهی سریع برای تنظیم xy است
مختصات یک گره که ساکن است.

// مرحله 3
anim.SetStartTime (ثانیه(150))؛ و anim.SetStopTime (ثانیه(150))؛

AnimationInterface می تواند فایل های XML بزرگ تولید کند. عبارات بالا پنجره را محدود می کند
AnimationInterface بین آن ردیابی انجام می دهد. محدود کردن پنجره فقط برای تمرکز است
در بخش های مرتبط شبیه سازی و ایجاد فایل های XML کوچک قابل مدیریت

// مرحله 4
AnimationInterface anim ("animation.xml"، 50000)؛

استفاده از سازنده فوق تضمین می کند که هر فایل ردیابی XML انیمیشن فقط 50000 دارد
بسته ها به عنوان مثال، اگر AnimationInterface 150000 بسته را ضبط کند، با استفاده از موارد فوق
سازنده ضبط را به 3 فایل تقسیم می کند

· animation.xml - شامل محدوده بسته 1-50000

· animation.xml-1 - حاوی محدوده بسته 50001-100000

· animation.xml-2 - حاوی محدوده بسته 100001-150000

// مرحله 5
anim.EnablePacketMetadata (درست)؛

با عبارت فوق، AnimationInterface متا داده های هر بسته را در آن ثبت می کند
فایل ردیابی xml. NetAnim می تواند از متادیتا برای ارائه آمار و فیلتر بهتر استفاده کند.
همراه با ارائه اطلاعات مختصری در مورد بسته مانند شماره توالی TCP
یا آدرس IP مبدا و مقصد در طول انیمیشن بسته.

احتیاط: فعال کردن این ویژگی باعث ایجاد فایل‌های ردیابی XML بزرگ‌تر می‌شود. لطفا نه
هنگام استفاده از پیوندهای وایمکس، این ویژگی را فعال کنید.

// مرحله 6
anim.UpdateNodeDescription (5، "نقطه دسترسی");

با دستور بالا، AnimationInterface متن "Access-point" را به گره 5 اختصاص می دهد.

// مرحله 7
anim.UpdateNodeSize (6، 1.5، 1.5);

با دستور بالا، AnimationInterface اندازه گره را 1.5 تنظیم می کند. NetAnim
به طور خودکار نمای گرافیکی را برای تناسب با مرزهای توپولوژی مقیاس می کند. این یعنی
که NetAnim، می تواند به طور غیرعادی اندازه یک گره را خیلی زیاد یا خیلی کم مقیاس کند. استفاده كردن
AnimationInterface::UpdateNodeSize به شما امکان می دهد مقیاس پیش فرض را در NetAnim بازنویسی کنید.
و از مقیاس سفارشی خود استفاده کنید.

// مرحله 8
anim.updatenodecounter (89 ، 7 ، 3.4) ؛

با دستور بالا، AnimationInterface شمارنده را با Id == 89 تنظیم می کند
با نود 7 با مقدار 3.4. شمارنده با شناسه 89 با استفاده از آن به دست می آید
AnimationInterface::AddNodeCounter. یک مثال استفاده برای این در است
src/netanim/examples/resources_demo.cc.

گام 2: بار la XML in NetAnim
1. با فرض اینکه NetAnim ساخته شده است، از دستور "./NetAnim" برای راه اندازی NetAnim استفاده کنید. لطفا
اگر NetAnim در دسترس نیست، بخش "Building NetAnim" را مرور کنید.

2. وقتی NetAnim باز شد، روی دکمه باز کردن فایل در گوشه سمت چپ بالا کلیک کنید، انتخاب کنید.
فایل XML تولید شده در مرحله 1.

3. دکمه سبز بازی را بزنید تا انیمیشن شروع شود.

در اینجا یک ویدیو نشان دهنده این موضوع است http://www.youtube.com/watch?v=tz_hUuNwFDs

ویکی
برای دستورالعمل های دقیق در مورد نصب "NetAnim"، سوالات متداول و بارگیری فایل ردیابی XML
(که قبلا ذکر شد) با استفاده از NetAnim لطفاً مراجعه کنید: http://www.nsnam.org/wiki/NetAnim

ANTENNA MODULE

طرح مستندات
بررسی اجمالی
ماژول آنتن ارائه می دهد:

1. یک کلاس پایه جدید (AntennaModel) که یک رابط برای مدل‌سازی فراهم می‌کند
الگوی تشعشع آنتن؛

2. مجموعه ای از کلاس های مشتق شده از این کلاس پایه که هر کدام الگوی تابش را مدل می کنند
انواع آنتن

آنتن مدل
AntennaModel از سیستم مختصاتی استفاده می کند که در [بالانیس] و در شکل نشان داده شده است
هماهنگ كردن سیستم of la آنتن مدل. این سیستم با ترجمه دکارتی به دست می آید
سیستم مختصات مورد استفاده توسط ns-3 MobilityModel به مبدا جدید o که همان است
مکان آنتن، و سپس تبدیل مختصات هر نقطه عمومی p از
فاصله از مختصات دکارتی (x,y,z) به مختصات کروی (r, heta,hi).
مدل آنتن از مولفه شعاعی r غافل شده و فقط مولفه های زاویه را در نظر می گیرد
(هتا، سلام).
سپس یک الگوی تابش آنتن به عنوان یک تابع ریاضی g (هتا، hi) بیان می شود.
grightarrow thcal{R} که بهره (بر حسب دسی بل) را برای هر جهت ممکن برمی گرداند
انتقال / دریافت همه زوایا بر حسب رادیان بیان می شوند.
[تصویر] سیستم مختصات AntennaModel.UNINDENT

ارائه مدل
در این بخش مدل‌های الگوی تابش آنتن را که در داخل گنجانده شده‌اند، توضیح می‌دهیم
ماژول آنتن

مدل آنتن ایزوتروپیک
این مدل الگوی تابش آنتن یک بهره واحد (0 دسی بل) را برای همه جهت ها ارائه می دهد.

CosineAntennaModel
این مدل کسینوس توصیف شده در [چونجیان] است: بهره آنتن به صورت زیر تعیین می شود:

کجا سلام_{0}
جهت گیری ازیموتال آنتن (یعنی جهت حداکثر بهره آن) و
نمایی

پهنای پرتو 3dB مورد نظر hi_{3dB} را تعیین می کند.
توجه داشته باشید که این الگوی تابش مستقل از زاویه تمایل تا است.

تفاوت عمده بین مدل [چنجیان] و مدل پیاده‌سازی شده در کلاس
CosineAntennaModel فقط عامل عنصر است (یعنی آنچه در بالا توضیح داده شد
فرمول ها) در نظر گرفته شده است. در واقع، [چونجیان] یک آرایه آنتن اضافی را نیز در نظر گرفت
عامل. دلیل حذف دومی این است که انتظار داریم کاربر معمولی باشد
می‌خواهد یک پهنای پرتوی معین را دقیقاً مشخص کند، بدون افزودن ضریب آرایه در a
مرحله آخر که در عمل پهنای پرتو موثر حاصل را تغییر می دهد
الگو انتشار.

Parabolic AntennaModel
این مدل بر اساس تقریب سهموی الگوی تابش لوب اصلی است. آی تی
اغلب در زمینه سیستم سلولی برای مدل سازی الگوی تابش یک سلول استفاده می شود
بخش، به عنوان مثال [R4-092042a] و [Calcev] را ببینید. بهره آنتن بر حسب دسی بل تعیین می شود
عنوان:

کجا سلام_{0}
جهت گیری ازیموتال آنتن است (یعنی جهت حداکثر بهره آن)،
سلام_{3dB}
پهنای پرتو 3 دسی بل آن است و A_{max} حداکثر تضعیف در دسی بل آنتن است. توجه داشته باشید
که این الگوی تابش مستقل از زاویه تمایل تا است.

[بالانیس]
CA Balanis، "نظریه آنتن - تجزیه و تحلیل و طراحی"، Wiley، ویرایش دوم.

[چونجیان]
لی چونجیان، "الگوهای آنتن کارآمد برای سیستم های سه بخش WCDMA"، کارشناسی ارشد
پایان نامه علمی، دانشگاه صنعتی چالمرز، گوتبورگ، سوئد، 2003

[Calcev]
جورج کالسو و مت دیلون، "کنترل شیب آنتن در شبکه های CDMA"، در Proc. از
دومین کنفرانس سالانه بین المللی اینترنت بی سیم (WICON)، 2

[R4-092042a]
3GPP TSG RAN WG4 (رادیو) جلسه شماره 51، R4-092042، مفروضات شبیه سازی و
پارامترهای مورد نیاز FDD HeNB RF

کاربر مستندات
ماژول آنتن را می توان با تمام فناوری های بی سیم و لایه فیزیکی استفاده کرد
مدل هایی که از آن پشتیبانی می کنند. در حال حاضر، این شامل مدل های لایه فیزیکی بر اساس
SpectrumPhy. لطفا برای جزئیات بیشتر به مستندات هر یک از این مدل ها مراجعه کنید.

تست مستندات
در این بخش، مجموعه‌های آزمایشی همراه با ماژول آنتن را که تأیید می‌کنند، توضیح می‌دهیم
عملکرد صحیح آن

زوایای
مجموعه تست واحد زاویه بررسی می کند که کلاس Angles به درستی توسط
تبدیل صحیح از مختصات دکارتی سه بعدی با توجه به روش های موجود
(ساخت از یک بردار واحد و از یک جفت بردار). برای هر روش، چندین
موارد آزمایشی ارائه شده است که مقادیر (سلام،
تا) توسط سازنده به مقادیر مرجع شناخته شده تعیین می شود. اگر برای هر کدام آزمون قبول می شود
در صورتی که مقادیر برابر با مرجع تا تلورانس 10^{-10} هستند که به حساب می آید
برای خطاهای عددی

درجه تا رادیان
مجموعه تست واحد درجه-رادیان تایید می کند که روش ها درجه تا رادیان و
RadiansToDegrees با مقایسه با مقادیر مرجع شناخته شده در تعدادی از به درستی کار می کند
موارد آزمون. در صورتی که مقایسه تا تلورانس 10 ^{-10} برابر باشد، هر مورد آزمایشی می‌گذرد.
که خطاهای عددی را محاسبه می کند.

مدل آنتن ایزوتروپیک
مجموعه تست واحد همسانگرد-آنتن-مدل بررسی می کند که مدل آنتن ایزوتروپیک کلاس
به درستی کار می کند، به عنوان مثال، بدون توجه به جهت، همیشه یک بهره 0dB را برمی گرداند.

CosineAntennaModel
مجموعه تست واحد کسینوس-آنتن-مدل بررسی می کند که CosineAntennaModel کارهای کلاسی
به درستی. چندین مورد تست ارائه شده است که مقدار افزایش آنتن محاسبه شده را بررسی می کند
در جهات مختلف و برای مقادیر مختلف جهت، بهره مرجع
و پهنای پرتو سود مرجع با دست محاسبه می شود. هر مورد آزمایشی در صورتی که
بهره مرجع در دسی بل برابر با مقدار بازگشتی است CosineAntennaModel در یک
تحمل 0.001، که تقریب انجام شده برای محاسبه
مقادیر مرجع

Parabolic AntennaModel
مجموعه تست واحد پارابولیک-آنتن-مدل بررسی می کند که Parabolic AntennaModel کلاس
به درستی کار می کند. چندین مورد تست ارائه شده است که مقدار افزایش آنتن را بررسی می کند
محاسبه شده در جهات مختلف و برای مقادیر مختلف جهت،
حداکثر تضعیف و پهنای پرتو سود مرجع با دست محاسبه می شود. هر تست
در صورتی که بهره مرجع در دسی بل برابر با مقدار بازگشتی باشد، case عبور می کند
Parabolic AntennaModel در تلورانس 0.001، که تقریب را به حساب می آورد
برای محاسبه مقادیر مرجع انجام می شود.

AD HOC بر اساس تقاضا فاصله بردار (AODV)

این مدل مشخصات پایه بردار فاصله زمانی مورد تقاضا را پیاده سازی می کند
پروتکل (AODV). اجرا بر اساس RFC 3561.

این مدل توسط Elena Buchatskaia و Pavel Boyko از ITTP RAS نوشته شده است و بر اساس
مدل ns-2 AODV توسعه یافته توسط گروه CMU/MONARCH و بهینه سازی و تنظیم شده توسط سمیر
داس و ماهش مارینا، دانشگاه سینسیناتی، و همچنین در مورد اجرای AODV-UU توسط
اریک نوردستروم از دانشگاه اوپسالا.

مدل توضیحات:
کد منبع مدل AODV در فهرست موجود است src/aodv.

طرح
طبقه ns3::aodv::پروتکل مسیریابی تمام عملکردهای تبادل بسته سرویس را پیاده سازی می کند
و ارث می برد ns3:: پروتکل مسیریابی IPv4. کلاس پایه دو تابع مجازی را تعریف می کند
برای مسیریابی و ارسال بسته ها اولی، ns3::aodv::RouteOutput، استفاده شده برای
بسته های منشا محلی، و دومی، ns3::aodv::RouteInput، استفاده شده برای
ارسال و/یا تحویل بسته های دریافتی

عملکرد پروتکل به بسیاری از پارامترهای قابل تنظیم بستگی دارد. پارامترهایی برای این
عملکرد ویژگی های هستند ns3::aodv::پروتکل مسیریابی. مقادیر پیش فرض پارامتر هستند
از RFC گرفته شده و به ویژگی های پروتکل فعال/غیرفعال، مانند
پخش پیام های HELLO، پخش بسته های داده و غیره.

AODV مسیرها را در صورت تقاضا کشف می کند. بنابراین، مدل AODV تمام بسته ها را بافر می کند در حالی که a
بسته درخواست مسیر (RREQ) منتشر می شود. یک صف بسته در پیاده سازی می شود
aodv-rqueue.cc. یک اشاره گر هوشمند به بسته، ns3::Ipv4RoutingProtocol::ErrorCallback,
ns3::Ipv4RoutingProtocol::UnicastForwardCallback، و هدر IP در این ذخیره می شود
صف صف بسته جمع آوری زباله از بسته های قدیمی و اندازه صف را پیاده سازی می کند
حد.

پیاده سازی جدول مسیریابی از جمع آوری زباله ورودی های قدیمی و وضعیت پشتیبانی می کند
ماشین، تعریف شده در استاندارد. به عنوان یک کانتینر نقشه STL پیاده سازی شده است. کلید یک است
نشانی آی پی مقصد.

برخی از عناصر عملیات پروتکل در RFC توضیح داده نشده اند. این عناصر به طور کلی
نگرانی از همکاری لایه های مختلف مدل OSI. مدل از موارد زیر استفاده می کند
اکتشافی:

· این پیاده سازی AODV می تواند وجود پیوندهای یک طرفه را تشخیص دهد و از آنها اجتناب کند
در صورت لزوم اگر گره ای که مدل برای آن یک RREQ دریافت می کند همسایه باشد، ممکن است علت
یک پیوند یک طرفه باشد این اکتشافی از اجرای AODV-UU گرفته شده است و می تواند
از کار افتاده باشد.

· عملکرد پروتکل به شدت به مکانیسم تشخیص لینک شکسته بستگی دارد. مدل
دو چنین اکتشافی را پیاده سازی می کند. اول، این پیاده سازی از پیام های HELLO پشتیبانی می کند.
با این حال، پیام های HELLO راه خوبی برای انجام سنجش همسایه در بی سیم نیستند
محیط (حداقل نه بیش از 802.11). بنابراین، فرد ممکن است عملکرد بدی را تجربه کند
هنگام اجرا از طریق بی سیم دلایل مختلفی برای این وجود دارد: 1) پیام های HELLO هستند
پخش شد. در 802.11، پخش اغلب با نرخ بیت پایین‌تری نسبت به پخش واحد انجام می‌شود.
بنابراین پیام های HELLO می توانند فراتر از داده های unicast حرکت کنند. 2) پیام های HELLO کوچک هستند،
بنابراین کمتر مستعد خطاهای بیتی نسبت به انتقال داده‌ها است، و 3) انتقال‌های پخش
بر خلاف ارسال های تک پخشی، دو طرفه بودن آنها تضمین نمی شود. دوم، ما استفاده می کنیم
بازخورد لایه 2 در صورت امکان. در صورت انتقال فریم، پیوند خراب در نظر گرفته می شود
منجر به شکست انتقال برای همه تلاش های مجدد می شود. این مکانیسم برای فعال در نظر گرفته شده است
پیوند می دهد و سریعتر از روش اول کار می کند.

اجرای بازخورد لایه 2 متکی است TxErrHeader منبع ردیابی، در حال حاضر
فقط در AdhocWifiMac پشتیبانی می شود.

حوزه و محدودیت ها
این مدل فقط برای IPv4 است. بهینه سازی پروتکل اختیاری زیر نیست
اجرا شده:

1. گسترش جستجوی حلقه.

2. تعمیر لینک محلی.

3. پسوند پیام RREP، RREQ و HELLO.

این تکنیک ها نیاز به دسترسی مستقیم به هدر IP دارند که با ادعای مطرح شده در تناقض است
AODV RFC که AODV روی UDP کار می کند. این مدل برای سادگی از UDP استفاده می کند و مانع از کار می شود
توانایی پیاده سازی بهینه سازی پروتکل های خاص مدل از لایه کم خام استفاده نمی کند
سوکت ها چون قابل حمل نیستند.

آینده مهاجرت کاری
هیچ برنامه ای اعلام نشده

منابع
استفاده
مثال ها
یاران
خواص
ردیابی
ورود به سیستم
هشدارهای
اعتبار
واحد تست
در مقیاس بزرگتر کارایی تست

کاربردها

حفره یا سوراخ فصل

بریج NetDEVICE

حفره یا سوراخ فصل

برخی از نمونه‌های استفاده از Bridge NetDevice را می‌توان در اینجا یافت نمونه‌ها/csma/ دایرکتوری.

BRITE ادغام

این مدل یک رابط برای BRITE، اینترنت نماینده دانشگاه بوستون، پیاده سازی می کند
ژنراتور توپولوژی [1]. BRITE یک ابزار استاندارد برای تولید اینترنت واقعی است
توپولوژی ها مدل ns-3 که در اینجا توضیح داده شده است، یک کلاس کمکی برای تسهیل فراهم می کند
ایجاد توپولوژی های خاص ns-3 با استفاده از فایل های پیکربندی BRITE. BRITE را می سازد
گراف اصلی که به عنوان گره ها و لبه ها در کلاس ns-3 BriteTopolgyHelper ذخیره می شود. که در
با ادغام ns-3 BRITE، ژنراتور یک توپولوژی تولید می کند و سپس دسترسی را فراهم می کند
به گره های برگ برای هر AS تولید شده. کاربران ns-3 می توانند توپولوژی های سفارشی را به آن متصل کنند
این گره های برگ یا با ایجاد آنها به صورت دستی یا با استفاده از ژنراتورهای توپولوژی ارائه شده در
ns-3.

سه نوع توپولوژی اصلی در BRITE وجود دارد: روتر، AS و
سلسله مراتبی که ترکیبی از AS و روتر است. برای اهداف ns-3
شبیه سازی، احتمالاً مفیدترین آنها Router و Hierarchical هستند. سطح روتر
توپولوژی ها با استفاده از مدل Waxman یا مدل Barabasi-Albert تولید می شوند. هر یک
مدل دارای پارامترهای مختلفی است که بر ایجاد توپولوژی تأثیر می گذارد. برای توپولوژی های مسطح روتر،
همه گره ها در یک AS در نظر گرفته می شوند.

توپولوژی های سلسله مراتبی BRITE شامل دو سطح است. اولین مورد سطح AS است. این سطح
همچنین می توان با استفاده از مدل Waxman یا مدل Barabasi-Albert ایجاد کرد.
سپس برای هر گره در توپولوژی AS، یک توپولوژی سطح روتر ساخته می شود. اینها
توپولوژی های سطح روتر دوباره می توانند از مدل Waxman یا مدل Barbasi-Albert استفاده کنند.
BRITE این توپولوژی های مسیریاب جداگانه را همانطور که توسط سطح AS مشخص شده است به هم متصل می کند
توپولوژی هنگامی که توپولوژی سلسله مراتبی ساخته شد، به یک بزرگ مسطح می شود
توپولوژی سطح روتر

اطلاعات بیشتر را می توان در کتابچه راهنمای کاربر BRITE یافت:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

مدل توضیحات:
این مدل بر ساخت یک کتابخانه خارجی BRITE و سپس ساختن مقداری ns-3 متکی است
یاورانی که به کتابخانه زنگ می زنند. کد منبع برای کمک کنندگان ns-3 در
فهرست راهنما src/brite/helper.

طرح
برای تولید توپولوژی BRITE، کمک کنندگان ns-3 به کتابخانه خارجی BRITE فراخوانی می کنند و
با استفاده از یک فایل پیکربندی استاندارد BRITE، کد BRITE یک نمودار با گره ها و
لبه ها مطابق این فایل پیکربندی. لطفاً مستندات BRITE یا به را ببینید
نمونه فایل های پیکربندی در src/brite/examples/conf_files برای درک بهتر
گزینه های پیکربندی BRITE نمودار ساخته شده توسط BRITE به ns-3 و یک ns-3 برگردانده می شود
پیاده سازی نمودار ساخته شده است. گره های برگ برای هر AS برای کاربر در دسترس است
برای پیوست کردن توپولوژی های سفارشی یا نصب مستقیم برنامه های ns-3.

منابع
[1] آلبرتو مدینا، آنوکول لاخینا، ابراهیم ماتا و جان بایرز. BRITE: رویکردی به
نسل توپولوژی جهانی در مجموعه مقالات کارگاه بین المللی در
مدلسازی، تحلیل و شبیه سازی سیستم های کامپیوتری و مخابراتی- ماسکوت
'01، سینسیناتی، اوهایو، اوت 2001.

استفاده
برای مشاهده استفاده اولیه از رابط BRITE می توان به مثال brite-generic اشاره کرد. که در
به طور خلاصه، BriteTopologyHelper به عنوان نقطه رابط با عبور در یک BRITE استفاده می شود
فایل پیکربندی. همراه با فایل پیکربندی، یک فایل بذر تصادفی با فرمت BRITE
همچنین می‌تواند ارسال شود. اگر فایل seed در آن ارسال نشود، Helper یک seed ایجاد می‌کند
فایل با استفاده از UniformRandomVariable ns-3. هنگامی که توپولوژی توسط BRITE تولید شد،
BuildBriteTopology() برای ایجاد نمایش ns-3 فراخوانی می شود. آدرس IP بعدی می تواند باشد
با استفاده از AssignIpv4Addresses() یا AssignIpv6Addresses() به توپولوژی اختصاص داده می شود. آی تی
لازم به ذکر است که هر پیوند نقطه به نقطه در توپولوژی به عنوان یک پیوند جدید در نظر گرفته می شود
بنابراین برای IPV4 باید از یک زیرشبکه /30 برای جلوگیری از هدر رفتن مقدار زیادی استفاده شود
فضای آدرس موجود

نمونه فایل های پیکربندی BRITE را می توان در /src/brite/examples/conf_files/ یافت.
ASBarbasi و ASWaxman نمونه هایی از توپولوژی های AS هستند. RTBarabasi و RTWaxman
فایل ها نمونه هایی از توپولوژی های روتر هستند. در نهایت TD_ASBarabasi_RTWaxman
فایل پیکربندی نمونه ای از توپولوژی سلسله مراتبی است که از Barabasi-Albert استفاده می کند
مدل برای سطح AS و مدل Waxman برای هر یک از توپولوژی های سطح روتر.
اطلاعات مربوط به پارامترهای BRITE مورد استفاده در این فایل ها را می توان در کاربر BRITE یافت
کتابچه راهنمای.

بنا BRITE ادغام
اولین قدم دانلود و ساخت مخزن BRITE خاص ns-3 است:

کلون دلار جیوه http://code.nsnam.org/BRITE
$ سی دی BRITE
$ ساخت

با این کار BRITE ساخته می شود و یک کتابخانه به نام libbrite.so در دایرکتوری BRITE ایجاد می شود.

هنگامی که BRITE با موفقیت ساخته شد، ما به پیکربندی ns-3 با پشتیبانی BRITE ادامه می دهیم.
به دایرکتوری ns-3 خود تغییر دهید:

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

اطمینان حاصل کنید که در کنار "BRITE Integration" عبارت "enabled" نوشته شده است. اگر اینطور نیست، پس چیزی دارد
اشتباه رفت یا فراموش کرده اید ابتدا BRITE را طبق مراحل بالا بسازید، یا
ns-3 نتوانست دایرکتوری BRITE شما را پیدا کند.

بعد، ns-3 را بسازید:

$./waf

مثال ها
برای مثال اجرای اجرای ادغام BRITE:

$ ./waf --run 'brite-generic-example'

با فعال کردن پارامتر verbose، مثال گره و لبه را چاپ می کند
اطلاعات در قالبی مشابه با خروجی استاندارد BRITE. بسیاری دیگر وجود دارد
پارامترهای خط فرمان شامل confFile، tracing و nix که در زیر توضیح داده شده است:

confFile
یک فایل پیکربندی BRITE. نمونه های مختلف فایل پیکربندی BRITE
برای مثال، در دایرکتوری src/brite/examples/conf_files وجود دارد،
RTBarabasi20.conf و RTWaxman.conf. لطفاً به دایرکتوری conf_files مراجعه کنید
برای مثالهای بیشتر

ردیابی
ردیابی ascii را فعال می کند.

هیچ کس مسیریابی nix-vector را فعال می کند. مسیریابی جهانی به طور پیش فرض استفاده می شود.

مثال عمومی BRITE همچنین از تجسم با استفاده از pyviz با فرض اتصالات پایتون پشتیبانی می کند
در ns-3 فعال هستند:

$ ./waf --run brite-generic-example --vis

شبیه سازی های مربوط به BRITE را نیز می توان با MPI استفاده کرد. تعداد کل نمونه های MPI
به کمک کننده توپولوژی BRITE منتقل می شود که در آن از یک تقسیم مدول برای تخصیص گره ها استفاده می شود
برای هر AS به یک نمونه MPI. یک مثال را می توان در src/brite/examples یافت:

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

لطفاً برای اطلاعات در مورد تنظیم MPI با ns-3 به مستندات ns-3 MPI مراجعه کنید.

ساختمانها MODULE

سی دی .. عبارتند از:: replace.txt

طرح مستندات
بررسی اجمالی
ماژول Buildings ارائه می دهد:

1. کلاس جدید (بنا) که حضور یک ساختمان را در یک شبیه سازی مدل می کند
سناریو؛

2. کلاس جدید (MobilityBuildingInfo) که امکان تعیین مکان، اندازه و
ویژگی‌های ساختمان‌های موجود در منطقه شبیه‌سازی شده و امکان قرارگیری را فراهم می‌کند
گره های داخل آن ساختمان ها؛

3. یک کلاس ظرف با تعریف مفیدترین مدل های pathloss و
متغیرهای متناظر نامیده می شوند BuildingsPropagationLossModel.

4. یک مدل انتشار جدید (ساختمانهای ترکیبی PropagationLossModel) کار با
مدل تحرک به تازگی معرفی شده است که امکان مدل سازی پدیده را فراهم می کند
تکثیر در فضای باز/داخلی در حضور ساختمان ها.

5. یک مدل ساده که فقط با Okumura Hata کار می کند (OhBuildingsPropagationLossModel)
با توجه به پدیده تکثیر داخل/خارجی در حضور
ساختمانها

مدل‌ها با در نظر گرفتن LTE طراحی شده‌اند، اگرچه پیاده‌سازی آنها در واقع است
مستقل از هر کد خاص LTE، و می تواند با دیگر بی سیم ns-3 استفاده شود
فن آوری ها نیز (به عنوان مثال، وای فای، وایمکس).

La ساختمانهای ترکیبی PropagationLossModel مدل pathloss گنجانده شده از طریق a به دست می آید
ترکیبی از چندین مدل شناخته شده pathloss به منظور تقلید متفاوت
سناریوهای محیطی مانند مناطق شهری، برون شهری و باز. علاوه بر این، مدل
در نظر می گیرد که هم در فضای باز و هم در فضای داخلی ارتباطات داخلی و خارجی باید گنجانده شود
از آنجایی که HeNB ممکن است در داخل ساختمان و یا در خارج نصب شود. در مورد داخلی
ارتباط، مدل باید نوع ساختمان در فضای باز <-> داخلی را نیز در نظر بگیرد
ارتباط بر اساس برخی معیارهای عمومی مانند تلفات نفوذ دیوار
مواد رایج؛ علاوه بر این شامل برخی از تنظیمات کلی برای داخلی است
دیوارها در ارتباطات داخلی

La OhBuildingsPropagationLossModel مدل pathloss برای ساده سازی ایجاد شده است
قبلی که آستانه های تغییر از یک مدل به مدل دیگر را حذف می کند. برای انجام این کار
از آن فقط یک مدل انتشار از مدل موجود (یعنی Okumura) استفاده شده است
هاتا). وجود ساختمان همچنان در مدل در نظر گرفته شده است. بنابراین همه
ملاحظات فوق در مورد نوع ساختمان همچنان معتبر است. همینطور
از آن زمان می‌توان به سناریو و فرکانس محیطی توجه کرد
هر دوی آنها پارامترهای مدل در نظر گرفته شده هستند.

La بنا کلاس
مدل شامل یک کلاس خاص به نام بنا که حاوی ns3 است جعبه کلاس برای
تعیین ابعاد ساختمان به منظور پیاده سازی ویژگی های
مدل های pathloss شامل، بنا کلاس از ویژگی های زیر پشتیبانی می کند:

· نوع ساختمان:

· مسکونی (مقدار پیش فرض)

· دفتر

· تجاری

· نوع دیوارهای خارجی

· چوب

· ConcreteWithWindows (مقدار پیش فرض)

· ConcreteWithoutWindows

· StoneBlocks

· تعداد طبقات (مقدار پیش فرض 1، که به معنی فقط طبقه همکف است)

· تعداد اتاق ها در محور x (مقدار پیش فرض 1)

· تعداد اتاق ها در محور y (مقدار پیش فرض 1)

کلاس ساختمان بر اساس مفروضات زیر است:

یک ساختمان به صورت یک متوازی الاضلاع مستطیل شکل (یعنی یک جعبه) نشان داده می شود.

· دیوارها با محور x، y و z موازی هستند

یک ساختمان به شبکه ای از اتاق ها تقسیم می شود که با پارامترهای زیر مشخص می شود:

· تعداد طبقات

تعداد اتاق ها در امتداد محور x

تعداد اتاق ها در امتداد محور y

· محور z، محور عمودی است، به عنوان مثال، تعداد طبقات برای افزایش محور z افزایش می یابد
ارزش

· شاخص های اتاق x و y از 1 شروع می شوند و در امتداد محور x و y افزایش می یابند
به ترتیب

· تمام اتاق های یک ساختمان دارای اندازه مساوی هستند

La MobilityBuildingInfo کلاس
La MobilityBuildingInfo کلاس که از کلاس ns3 به ارث می رسد شیء، عهده دار است
حفظ اطلاعات در مورد موقعیت یک گره نسبت به ساختمان. در
اطلاعات مدیریت شده توسط MobilityBuildingInfo است:

· آیا گره داخلی یا خارجی است

· اگر داخل ساختمان است:

· گره در کدام ساختمان قرار دارد

· گره در کدام اتاق قرار دارد (شاخص های x، y و اتاق طبقه)

کلاس MobilityBuildingInfo توسط استفاده می شود BuildingsPropagationLossModel کلاس، که
از کلاس ns3 به ارث می برد PropagationLossModel و محاسبات مسیر عبور را مدیریت می کند
اجزای منفرد و ترکیب آنها با توجه به موقعیت گره ها. علاوه بر این،
سایه زنی را نیز اجرا می کند، یعنی ضرر ناشی از موانع در مسیر اصلی
(یعنی پوشش گیاهی، ساختمان ها و غیره).

لازم به ذکر است که، MobilityBuildingInfo می تواند توسط هر مدل انتشار دیگری استفاده شود.
با این حال، بر اساس اطلاعات در زمان نگارش این مقاله، تنها مواردی که در آن تعریف شده است
ماژول ساختمان برای در نظر گرفتن محدودیت های معرفی شده توسط
ساختمانها
g
ItuR1238PropagationLossModel
این کلاس یک مدل تلفات انتشار داخلی وابسته به ساختمان را بر اساس ITU پیاده‌سازی می‌کند
P.1238 modeg{ که شامل تلفات ناشی از نوع ساختمان (یعنی مسکونی، اداری و
تجاری)ia عبارت تحلیلی در زیر آورده شده است.
nr
{r
aa
کجا: خوب باش : از دست دادن قدرت
N = tr}مسکونی \ 30 و اداری \ 22 و تجاری\nd{آرایه}
ضریب [dB]
خوب
L_f = t }مسکونی \ 15+4(n-1) و اداری \ 6+3(n-1) و تجاری\nd{آرایه}
{l
n : تعداد طبقات بین ایستگاه پایه و موبایل (n 1)
l2
f: فرکانس [MHz]
}&
d : فاصله (که d > 1) [m]
n
BuildingsPropag&&ationLossModel
BuildingsPropagationLossModel مجموعه دیگری از موارد وابسته به ساختمان را فراهم می کند
عناصر مدل pathloss که برای پیاده سازی منطق های مختلف pathloss استفاده می شوند. اینها
عناصر مدل pathloss در بخش‌های فرعی زیر توضیح داده شده‌اند.

خارجی دیوار زیان (EWL)
این جزء افت نفوذ از طریق دیوارها را برای فضای داخلی به بیرون مدل می کند
ارتباطات و بالعکس مقادیر از مدل [cost231] گرفته شده است.

· چوب ~ 4 دسی بل

· بتن با پنجره (فلزی نشده) ~ 7 دسی بل

· بتن بدون پنجره ~ 15 دسی بل (بین 10 تا 20 در COST231)

· بلوک های سنگی ~ 12 دسی بل

داخلی دیوار زیان (IWL)
این مؤلفه افت نفوذ رخ داده در ارتباطات داخلی به داخل را مدل می کند
در داخل همان ساختمان مجموع زیان با فرض اینکه هر داخلی واحد محاسبه می شود
دیوار دارای افت نفوذ ثابت L_{siw} و تقریبی تعداد دیوارهایی است که
با فاصله منهتن (به تعداد اتاق) بین فرستنده نفوذ می کنند
و گیرنده در جزئیات، اجازه دهید x_1، y_1، x_2، y_2 عدد اتاق را در امتداد x نشان دهند و
محور y به ترتیب برای کاربر 1 و 2. کل ضرر L_{IWL} به صورت محاسبه می شود

ارتفاع افزایش مدل (HG)
این مولفه به دلیل اینکه دستگاه فرستنده روی یک طبقه قرار دارد، بهره را مدلسازی می کند
بالای سطح زمین. در ادبیات [ترکمانی] این افزایش حدود 2 دسی بل ارزیابی شده است
در هر طبقه این بهره را می توان برای تمام ارتباطات داخلی به بیرون و
برعکس

سایه مدل
سایه با توجه به یک توزیع log-normal با استاندارد متغیر مدل‌سازی می‌شود
انحراف به عنوان تابعی از موقعیت نسبی (داخلی یا بیرونی) MobilityModel
موارد درگیر یک مقدار تصادفی برای هر جفت MobilityModels ترسیم می شود و باقی می ماند
ثابت برای آن جفت در طول کل شبیه سازی. بنابراین، مدل مناسب برای
فقط گره های استاتیک

مدل در نظر می گیرد که میانگین از دست دادن سایه در دسی بل همیشه 0 است
واریانس، مدل سه مقدار احتمالی انحراف معیار را با جزئیات در نظر می گیرد:
تیرماهی X_thrm{O}
· فضای باز (m_shadowingSigmaOutdoor، مقدار پیش فرض 7 دسی بل)
N(_thrm{O}، ma_thrm{O}^2).
تیرماهی X_thrm{I}
· داخل ساختمان (m_shadowingsigmaindoor، مقدار پیش فرض 10 دسی بل)
N(_thrm{I}، ma_thrm{I}^2).
تیر نورانی
· نفوذ دیوارهای خارجی (m_shadowingSigmaExtWalls، مقدار پیش فرض 5 دسی بل)
X_thrm{W} N(_thrm{W}، ma_thrm{W}^2)

شبیه ساز یک مقدار سایه برای هر پیوند فعال با توجه به گره ها تولید می کند.
اولین باری که از پیوند برای انتقال استفاده می شود، قرار دهید. در صورت ارسال از
گره های خارجی به گره های داخلی، و بالعکس، انحراف استاندارد (ma_thrm{IO}) باید
به عنوان جذر مجموع مقادیر درجه دوم استاندارد محاسبه شود
انحراف در مورد گره های بیرونی و یکی برای نفوذ دیوارهای خارجی. این هست
با توجه به اینکه اجزای ایجاد کننده سایه از هر یک مستقل هستند
دیگر؛ بنابراین، واریانس یک توزیع حاصل از مجموع دو مستقل
نرمال مجموع واریانس ها است.

راه گم کرده منطق ها
در ادامه، منطق مسیرهای مختلف پیاده‌سازی شده توسط را شرح می‌دهیم
به ارث بردن از BuildingsPropagationLossModel.

ساختمانهای ترکیبی PropagationLossModel
La ساختمانهای ترکیبی PropagationLossModel مدل pathloss گنجانده شده از طریق a به دست می آید
ترکیبی از چندین مدل شناخته شده pathloss به منظور تقلید از فضای باز و
سناریوهای داخلی، و همچنین سناریوهای داخلی به بیرون و خارج از منزل به داخل. به تفصیل،
کلاس ساختمانهای ترکیبی PropagationLossModel مدل های pathloss زیر را ادغام می کند:

· OkumuraHataPropagationLossModel (OH) (در فرکانس های > 2.3 گیگاهرتز جایگزین شده توسط
Kun2600MhzPropagationLossModel)

· ItuR1411LosPropagationLossModel و ItuR1411NlosOverRooftopPropagationLossModel
(I1411)

· ItuR1238PropagationLossModel (I1238)

· عناصر تلفات BuildingsPropagationLossModel (EWL, HG, IWL)

شبه کد زیر نحوه توصیف عناصر مختلف مدل گذر را نشان می دهد
بالا در ادغام شده اند ساختمانهای ترکیبی PropagationLossModel:

اگر (txNode در فضای باز است)
سپس
اگر (rxNode در فضای باز است)
سپس
اگر (فاصله > 1 کیلومتر)
سپس
اگر (rxNode یا txNode زیر پشت بام باشد)
سپس
L = I1411
دیگر
L = OH
دیگر
L = I1411
else (rxNode داخلی است)
اگر (فاصله > 1 کیلومتر)
سپس
اگر (rxNode یا txNode زیر پشت بام باشد)
L = I1411 + EWL + HG
دیگر
L = OH + EWL + HG
دیگر
L = I1411 + EWL + HG
else (txNode داخلی است)
اگر (rxNode داخلی است)
سپس
اگر (همان ساختمان)
سپس
L = I1238 + IWL
دیگر
L = I1411 + 2 *EWL
else (rxNode در فضای باز است)
اگر (فاصله > 1 کیلومتر)
سپس
اگر (rxNode یا txNode زیر پشت بام باشد)
سپس
L = I1411 + EWL + HG
دیگر
L = OH + EWL + HG
دیگر
L = I1411 + EWL

ما توجه می کنیم که برای مورد ارتباط بین دو گره زیر سطح پشت بام با
فاصله بیشتر از 1 کیلومتر است، ما هنوز مدل I1411 را در نظر می گیریم، زیرا OH به طور خاص است
برای سلول های ماکرو و در نتیجه برای آنتن های بالاتر از سطح سقف طراحی شده است.

برای مدل ITU-R P.1411 ما هر دو نسخه LOS و NLoS را در نظر می گیریم. به ویژه، ما
انتشار LoS را برای فواصل کوتاه در نظر می گیرد که از آستانه قابل تنظیم کوتاه شده است
(m_itu1411NlosThreshold). در مورد انتشار NLoS، مدل بالای پشت بام است
برای مدلسازی BS و SC کلان در نظر گرفته شده است. در مورد NLoS چند
پارامترهای وابسته به سناریو گنجانده شده است، مانند میانگین عرض خیابان،
جهت گیری، و غیره. مقادیر چنین پارامترهایی باید به درستی با توجه به تنظیم شوند
در سناریوی اجرا شده، مدل به صورت بومی مقادیر آنها را محاسبه نمی کند. در هر صورت
مقادیر ارائه شده است، مقادیر استاندارد استفاده می شود، جدا از ارتفاع موبایل و BS،
که در عوض یکپارچگی آنها مستقیماً در کد آزمایش می شود (یعنی باید باشند
بزرگتر از صفر). در ادامه عبارات اجزای the را بیان می کنیم
مدل.

همچنین توجه داریم که استفاده از مدل‌های انتشار مختلف (OH, I1411, I1238 با آنها
انواع) در HybridBuildingsPropagationLossModel می تواند منجر به ناپیوستگی در
مسافت با توجه به فاصله تنظیم مناسب ویژگی ها (به ویژه
ویژگی های آستانه فاصله) می توانند از این ناپیوستگی ها جلوگیری کنند. با این حال، از آنجایی که
رفتار هر مدل به چندین پارامتر دیگر (فرکانس، ارتفاع گره و غیره) بستگی دارد.
هیچ مقدار پیش فرضی از این آستانه ها وجود ندارد که بتواند از ناپیوستگی ها در همه جلوگیری کند
تنظیمات ممکن از این رو، تنظیم مناسب این پارامترها به آن واگذار شده است
کاربر می باشد.

OhBuildingsPropagationLossModel
La OhBuildingsPropagationLossModel کلاس به عنوان یک وسیله ساده برای حل ایجاد شده است
مشکلات ناپیوستگی از ساختمانهای ترکیبی PropagationLossModel بدون انجام دادن
تنظیم پارامتر سناریو خاص راه حل این است که فقط از یک افت انتشار استفاده کنید
مدل (به عنوان مثال، Okumura Hata)، در حالی که حفظ ساختار منطق pathloss برای
محاسبه سایر اجزای تلفات مسیر (مانند تلفات نفوذ دیوار). نتیجه این است
مدلی که عاری از ناپیوستگی است (به جز موارد ناشی از دیوارها)، اما کمتر است
به طور کلی واقع بینانه برای یک سناریوی عمومی با ساختمان ها و کاربران فضای باز/داخلی، به عنوان مثال،
زیرا Okumura Hata نه برای ارتباطات داخلی و نه برای فضای باز مناسب نیست
ارتباطات زیر سطح پشت بام

در جزئیات، کلاس OhBuildingsPropagationLossModel مسیر زیر را ادغام می کند
مدل ها:

· okumurahatapropagationlossmodel (OH)

· عناصر تلفات BuildingsPropagationLossModel (EWL, HG, IWL)

شبه کد زیر نحوه توصیف عناصر مختلف مدل گذر را نشان می دهد
بالا در ادغام شده اند OhBuildingsPropagationLossModel:

اگر (txNode در فضای باز است)
سپس
اگر (rxNode در فضای باز است)
سپس
L = OH
else (rxNode داخلی است)
L = OH + EWL
else (txNode داخلی است)
اگر (rxNode داخلی است)
سپس
اگر (همان ساختمان)
سپس
L = OH + IWL
دیگر
L = OH + 2 *EWL
else (rxNode در فضای باز است)
L = OH + EWL

توجه داریم که OhBuildingsPropagationLossModel یک ساده سازی قابل توجه است
به HybridBuildingsPropagationLossModel، با توجه به این واقعیت که OH همیشه استفاده می شود. در حالی که این
در برخی سناریوها (مخصوصاً در زیر پشت بام و داخل ساختمان)، مدلی با دقت کمتر ارائه می دهد
به طور موثر از موضوع ناپیوستگی های مسیری که تأثیر می گذارد جلوگیری می کند
ساختمانهای ترکیبی PropagationLossModel.

کاربر مستندات
چگونه به استفاده کنید ساختمان in a شبیه سازی
در این بخش، کاربرد اصلی مدل ساختمان ها در یک شبیه سازی را توضیح می دهیم
برنامه است.

شامل la هدر
این را در ابتدای برنامه شبیه سازی خود اضافه کنید:

#عبارتند از

ساختن a ساختمان
به عنوان مثال، اجازه دهید یک ساختمان مسکونی 10×20×10 ایجاد کنیم:

x_min دو برابر = 0.0;
دو برابر x_max = 10.0;
دو برابر y_min = 0.0;
دو برابر y_max = 20.0;
z_min دو برابر = 0.0;
z_max دو برابر = 10.0;
Ptr b = CreateObject ()
b->SetBoundaries (جعبه (x_min، x_max، y_min، y_max، z_min، z_max));
b->SetBuildingType (ساختمان::مسکونی);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3)؛
b->SetNRoomsX (3);
b->SetNRoomsY (2);

این ساختمان دارای سه طبقه و یک شبکه داخلی 3×2 از اتاق های مساوی است.

کلاس کمکی GridBuildingAllocator نیز برای ایجاد آسان مجموعه ای در دسترس است
ساختمان هایی با ویژگی های یکسان که روی یک شبکه مستطیلی قرار گرفته اند. در اینجا یک مثال است
نحوه استفاده از آن:

Ptr gridBuildingAlocator;
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 ("Height"، 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->Create (6);

این یک شبکه 3×2 از 6 ساختمان ایجاد می کند که هر کدام 7×13×6 متر با 2×4 اتاق در داخل و
2 فورس؛ فاصله ساختمان ها در هر دو محور x و y 3 متر است.

برپایی گره و تحرک مدل
گره ها و مدل های تحرک طبق معمول پیکربندی می شوند، اما به منظور استفاده از آنها با
مدل ساختمان ها که نیاز به تماس اضافی دارید BuildingsHelper::Install()، به طوری که اجازه دهید
مدل تحرک شامل اطلاعات موقعیت آنها در ساختمانها می باشد. اینجاست
یک مثال:

MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);

لازم به ذکر است که می توان از هر مدل حرکتی استفاده کرد. با این حال، به کاربر توصیه می شود
مطمئن شوید که رفتار مدل تحرک مورد استفاده با آن مطابقت دارد
حضور ساختمان ها به عنوان مثال، استفاده از یک تحرک تصادفی ساده در کل
منطقه شبیه سازی در حضور ساختمان ها ممکن است به راحتی منجر به حرکت گره به داخل و خارج شود
ساختمان ها، صرف نظر از وجود دیوارها.

محل برخی از گره
شما می توانید گره ها را با استفاده از چندین روش در شبیه سازی خود قرار دهید که در این روش توضیح داده شده است
ذیل.

میراث تثبیت موقعیت روش
برای قرار دادن گره در شبیه سازی می توان از هر روش موقعیت یابی قدیمی ns-3 استفاده کرد. در
مرحله مهم اضافی این است که به عنوان مثال، می توانید گره ها را به صورت دستی مانند زیر قرار دهید:

Ptr mm0 = enbNodes.Get (0)->GetObject ()
Ptr mm1 = enbNodes.Get (1)->GetObject ()
mm0->SetPosition (بردار (5.0، 5.0، 1.5));
mm1->SetPosition (بردار (30.0، 40.0، 1.5));

MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);
mm0->SetPosition (بردار (5.0، 5.0، 1.5));
mm1->SetPosition (بردار (30.0، 40.0، 1.5));

از طرف دیگر، می توانید از هر کلاس PositionAllocator موجود استفاده کنید. مختصات از
گره تعیین می کند که آیا در فضای باز یا سرپوشیده قرار می گیرد و اگر داخل آن باشد، در کدام قسمت قرار می گیرد
ساختمان و اتاق آن قرار داده شده است.

مخصوص ساختمان تثبیت موقعیت روش
کلاس های تخصیص دهنده موقعیت زیر برای قرار دادن گره در موقعیت های خاص در دسترس هستند
در رابطه با ساختمان ها:

· RandomBuildingPositionAlocator: هر موقعیت را با انتخاب تصادفی a اختصاص دهید
ساختن از لیست تمام ساختمان ها، و سپس به طور تصادفی موقعیتی را در داخل انتخاب کنید
ساختمان.

· RandomRoomPositionAlocator: هر موقعیت را با انتخاب تصادفی یک اتاق از آن اختصاص دهید
لیست اتاق ها در تمام ساختمان ها، و سپس به طور تصادفی یک موقعیت در داخل را انتخاب کنید
اتاق

· SameRoomPositionAlocator: یک NodeContainer معین را به صورت متوالی و برای هر کدام پیاده‌روی می‌کند
گره موقعیت جدیدی را به طور تصادفی در همان اتاق آن گره اختصاص می دهد.

· اتاق ثابت Allocator: ایجاد یک موقعیت تصادفی به طور یکنواخت در
حجم یک اتاق انتخاب شده در داخل یک ساختمان انتخاب شده

ساخت la تحرک مدل استوار
مهم: هر زمان که از ساختمان ها استفاده می کنید بعد از ما باید دستور زیر را صادر کنید
تمام گره ها و ساختمان ها را در شبیه سازی قرار داده اند:

BuildingsHelper::MakeMobilityModelConsistent ();

این دستور از طریق لیست تمام گره ها و تمام ساختمان ها، تعیین می کند
هر کاربر اگر داخل یا خارج باشد و اگر داخل باشد ساختمان داخل را نیز مشخص می کند
که کاربر در آن قرار دارد و طبقه و شماره مربوطه در داخل ساختمان.

ساختمان آگاه راه گم کرده مدل
بعد از اینکه ساختمان ها و گره ها را در یک شبیه سازی قرار دادید، می توانید از ساختمان آگاه استفاده کنید
مدل pathloss در یک شبیه سازی دقیقاً به همان روشی که از هر فقدان مسیر معمولی استفاده می کنید
مدل. نحوه انجام این کار مخصوص ماژول بی سیمی است که در نظر دارید (lte,
وای فای، وایمکس، و غیره)، بنابراین لطفاً به مستندات آن مدل مراجعه کنید
دستورالعمل.

اصلی قابل تنظیم خواص
La بنا کلاس دارای پارامترهای قابل تنظیم زیر است:

· نوع ساختمان: مسکونی، اداری و تجاری.

· نوع دیوارهای خارجی: چوب، بتن با پنجره، بتن بدون پنجره و بلوک سنگی.

· محدوده ساختمان: الف جعبه کلاس با محدوده ساختمان

· تعداد طبقات.

تعداد اتاق ها در محور x و y (اتاق ها را می توان فقط به صورت شبکه ای قرار داد).

La BuildingMobilityLossModel پارامتر قابل تنظیم با سیستم ویژگی ns3 است
نشان داده شده توسط کران (رشته محدودیت ها) ناحیه شبیه سازی با ارائه a جعبه کلاس
با محدوده منطقه علاوه بر این، با استفاده از روش آن می توان پارامترهای زیر را تعیین کرد
پیکربندی شده:

· تعداد طبقه ای که گره قرار می گیرد (پیش فرض 0).

· موقعیت در شبکه اتاق ها.

La BuildingPropagationLossModel کلاس دارای پارامترهای قابل تنظیم زیر است
قابل تنظیم با سیستم ویژگی:

· فرکانس: فرکانس مرجع (پیش فرض 2160 مگاهرتز)، توجه داشته باشید که با تنظیم فرکانس
طول موج بر این اساس به طور خودکار تنظیم می شود و بالعکس).

· یازدهمین حرف الفبای یونانی: طول موج (0.139 متر با توجه به فرکانس فوق).

· ShadowSigmaOutdoor: انحراف استاندارد سایه برای گره های فضای باز (پیش فرض
7.0).

· ShadowSigmaIndoor: انحراف استاندارد سایه برای گره های داخلی (پیش فرض
8.0).

· ShadowSigmaExtWalls: انحراف معیار سایه زنی ناشی از دیوارهای خارجی
نفوذ برای ارتباطات فضای باز به داخل (پیش فرض 5.0).

· سطح پشت بام: سطح پشت بام ساختمان بر حسب متر (پیش فرض 20 متر).

· Los2NlosThr: مقدار فاصله نقطه سوئیچ بین خط دید و
مدل انتشار غیر خط دید بر حسب متر (پیش فرض 200 متر).

· ITU1411 DistanceThr: مقدار فاصله نقطه سوئیچ بین برد کوتاه
(ITU 1211) ارتباطات و برد بلند (Okumura Hata) بر حسب متر (پیش فرض 200 متر).

· حداقل فاصله: حداقل فاصله بر حسب متر بین دو گره برای ارزیابی
مسیر عبوری (قبل از این آستانه قابل چشم پوشی در نظر گرفته می شود) (پیش فرض 0.5 متر).

· محیط: سناریوی محیطی بین Urban، Suburban و Open Areas (پیش‌فرض
شهری).

· CitySize: بعد شهر در بین Small, Medium, Large (پیش فرض Large).

به منظور استفاده از حالت ترکیبی، کلاس مورد استفاده عبارت است از
HybridBuildingMobilityLossModel، که امکان انتخاب مدل مسیر مناسب را فراهم می کند
با توجه به منطق pathloss ارائه شده در فصل طراحی. با این حال، این راه حل
این مشکل وجود دارد که نقاط سوئیچینگ مدل کاستی ممکن است ناپیوستگی هایی را ایجاد کنند
به ویژگی های مختلف مدل این نشان می دهد که با توجه به خاص
در این سناریو، آستانه مورد استفاده برای سوئیچینگ باید به درستی تنظیم شود. ساده
OhBuildingMobilityLossModel تنها با استفاده از مدل Okumura Hata بر این مشکل غلبه کنید
تلفات نفوذ دیوار

تست مستندات
بررسی اجمالی
برای تست و اعتبار سنجی ماژول ns-3 Building Pathloss چند مجموعه تست ارائه شده است که
با چارچوب تست ns-3 یکپارچه شده اند. برای اجرای آنها باید پیکربندی را انجام دهید
ساخت شبیه ساز به این صورت:

$ ./waf پیکربندی --enable-tests --enable-modules=buildings
$ ./test.py

موارد فوق نه تنها مجموعه‌های آزمایشی متعلق به ماژول ساختمان‌ها را اجرا می‌کنند، بلکه آن را نیز اجرا می‌کنند
آنهایی که متعلق به همه ماژول های دیگر ns-3 هستند که ماژول ساختمان ها به آنها وابسته است. دیدن
کتابچه راهنمای ns-3 برای اطلاعات عمومی در مورد چارچوب تست.

از این طریق می توانید گزارش دقیق تری را در قالب HTML دریافت کنید:

$ ./test.py -w results.html

پس از اجرای دستور بالا، می توانید با باز کردن، نتیجه دقیق هر تست را مشاهده کنید
فایل results.html با مرورگر وب

با استفاده از این دستور می توانید هر مجموعه آزمایشی را جداگانه اجرا کنید:

$ ./test.py -s test-suite-name

برای اطلاعات بیشتر در مورد test.py و چارچوب تست ns-3، لطفاً به ns-3 مراجعه کنید
کتابچه راهنمای.

توضیحات: of la آزمون سوئیت ها
BuildingsHelper آزمون
مجموعه تست ساختمان ها کمک کننده بررسی می کند که روش
BuildingsHelper::MakeAllInstancesConsistent () به درستی کار می کند، به عنوان مثال، که
BuildingsHelper در مکان یابی موفق است که گره ها در فضای باز یا داخلی هستند و اگر داخل هستند
که در ساختمان، اتاق و طبقه صحیح قرار دارند. چند مورد تست هستند
با ساختمان های مختلف (دارای اندازه، موقعیت، اتاق ها و طبقات متفاوت) و
موقعیت های مختلف گره اگر هر گره به درستی قرار گرفته باشد، تست انجام می شود.

BuildingPositionAlocator آزمون
مجموعه تست ساختمان-موقعیت-تخصیص دهنده دارای دو مورد تست است که آن را بررسی می کند
به ترتیب RandomRoomPositionAllocator و SameRoomPositionAllocator به درستی کار می کنند. هر یک
موارد تست شامل یک ساختمان اتاقی 2×3×2 (در مجموع 12 اتاق) با مختصات مشخص و
به ترتیب 24 و 48 گره. هر دو تست بررسی می‌کنند که تعداد گره‌های تخصیص داده شده در هر کدام
اتاق مورد انتظار است و موقعیت گره ها نیز درست است.

ساختمان راه گم کرده تست
مجموعه تست ساختمان ها-مدل-مسیر تست‌های واحد متفاوتی را ارائه می‌کند که با هم مقایسه می‌کنند
نتایج مورد انتظار از ماژول آسیب ساختمان در سناریوهای خاص با پیش
مقادیر محاسبه شده به صورت آفلاین با یک اسکریپت Octave به دست آمده است
(تست/مرجع/ساختمان-pathloss.m). در صورتی که این دو مقدار، تست ها قبول شده باشند
برابر با تلورانس 0.1 هستند که برای استفاده معمولی مناسب تلقی می شود
مقادیر pathloss (که بر حسب دسی بل هستند).

در ادامه به تفصیل سناریوهای در نظر گرفته شده، انتخاب آنها انجام شده است
پوشش مجموعه گسترده ای از ترکیبات منطقی ممکن گذر. نتیجه منطق مسیر گذر
بنابراین به طور ضمنی آزمایش شده است.

تست #1 اوکومورا هاتا
در این تست ما مدل استاندارد Okumura Hata را آزمایش می کنیم. بنابراین هر دو eNB و UE قرار می گیرند
بیرون در فاصله 2000 متری. فرکانس مورد استفاده باند شماره 5 E-UTRA است که
مربوط به 869 مگاهرتز است (جدول 5.5-1 از 36.101 را ببینید). این آزمون شامل اعتبار سنجی نیز می شود
از گسترش مناطق (یعنی مناطق شهری، حومه و باز) و اندازه شهر
(کوچک، متوسط ​​و بزرگ).

تست #2 COST231 مدل
این آزمایش با هدف اعتبارسنجی مدل COST231 انجام شده است. این تست مشابه Okumura است
هاتا یک، با این تفاوت که فرکانس استفاده شده باند EUTRA شماره 1 (2140 مگاهرتز) است و این تست
تنها برای شهرهای بزرگ و کوچک در سناریوهای شهری به دلیل مدل قابل اجرا می باشد
محدودیت ها.

تست #3 2.6 گیگاهرتز مدل
این تست مدل 2.6 گیگاهرتز Kun را تایید می کند. آزمون مشابه Okumura Hata یکی است به جز
که فرکانس باند EUTRA شماره 7 (2620 مگاهرتز) است و آزمایش فقط در
سناریوی شهری

تست #4 ITU1411 LoS مدل
این آزمایش با هدف اعتبارسنجی مدل ITU1411 در مورد خط دید در خیابان انجام می شود
انتقال دره ها در این مورد UE در 100 متری eNB قرار می گیرد، زیرا
آستانه تغییر بین LoS و NLoS به یک پیش فرض (یعنی 200 متر) باقی می ماند.

تست #5 ITU1411 NLoS مدل
این آزمایش با هدف اعتبارسنجی مدل ITU1411 در صورت عدم دید از روی آن انجام شده است
گیربکس های پشت بام در این مورد UE در فاصله 900 متری از eNB قرار می گیرد
منظور بالاتر از آستانه برای جابجایی بین LoS و NLoS به حالت پیش فرض رها می شود
(یعنی 200 متر).

تست #6 ITUP1238 مدل
این آزمایش با هدف اعتبارسنجی مدل ITUP1238 در مورد گیربکس های داخلی انجام می شود. که در
در این مورد هم UE و هم eNB در یک ساختمان مسکونی با دیوارهای ساخته شده قرار می گیرند
بتنی با پنجره Ue در طبقه دوم قرار دارد و 30 متر فاصله دارد
eNB که در طبقه اول قرار دارد.

تست #7 خارج از منزل -> داخلی با اوکومورا هاتا مدل
این تست گیربکس های بیرون به داخل را برای فواصل زیاد تایید می کند. در این مورد
UE در یک ساختمان مسکونی با دیوار ساخته شده از بتنی با پنجره ها و
فاصله 2000 متری از eNB در فضای باز.

تست #8 خارج از منزل -> داخلی با ITU1411 مدل
این تست گیربکس های بیرون به داخل را برای فواصل کوتاه تایید می کند. در این مورد
UE در یک ساختمان مسکونی با دیوارهای ساخته شده از بتون با پنجره و
فاصله 100 متری از eNB در فضای باز.

تست #9 داخلی -> خارج از منزل با ITU1411 مدل
این تست گیربکس های بیرون به داخل را برای فواصل بسیار کوتاه تایید می کند. در این
مورد eNB در طبقه دوم یک ساختمان مسکونی با دیوارهای ساخته شده از قرار داده شده است
بتن با پنجره ها و فاصله 100 متری از UE در فضای باز (یعنی LoS
ارتباط). بنابراین افزایش ارتفاع باید در ارزیابی مسیر عبوری لحاظ شود.

تست #10 داخلی -> خارج از منزل با ITU1411 مدل
این تست گیربکس های بیرون به داخل را برای فواصل کوتاه تایید می کند. در این مورد
eNB در طبقه دوم یک ساختمان مسکونی با دیوارهایی ساخته شده است
بتنی با پنجره ها و فواصل 500 متری از UE در فضای باز (یعنی NLoS
ارتباط). بنابراین افزایش ارتفاع باید در ارزیابی مسیر عبوری لحاظ شود.

ساختمان سایه تست
مجموعه تست ساختمانها-سایه-آزمون یک آزمون واحد است که برای تأیید آماری در نظر گرفته شده است
توزیع مدل سایه اجرا شده توسط BuildingsPathlossModel. سایه زدن
بر اساس توزیع نرمال با میانگین = 0 و استاندارد متغیر مدل شده است
انحراف ma، با توجه به مدل های رایج در ادبیات استفاده می شود. سه مورد تست هستند
ارائه شده است که موارد ارتباطات داخلی، خارجی و داخلی به بیرون را پوشش می دهد.
هر مورد آزمایشی 1000 نمونه سایه متفاوت برای جفت های مختلف تولید می کند
موارد MobilityModel در یک سناریوی معین. مقادیر سایه با تفریق به دست می آیند
از کل ارزش زیان برگشتی توسط HybridBuildingsPathlossModel جزء از دست دادن مسیر
که برای هر مورد آزمایشی ثابت و از پیش تعیین شده است. آزمایش تأیید می کند که نمونه
میانگین و واریانس نمونه مقادیر سایه‌زنی در بازه اطمینان 99 درصد قرار می‌گیرد
از میانگین نمونه و واریانس نمونه. این تست همچنین ارزش سایه‌زنی را تأیید می‌کند
در زمان‌های متوالی برای یک جفت نمونه MobilityModel ثابت است.

منابع
[ترکمانی]
ترکمانی AMD، JD Parson و DG Lewis، "انتشار رادیویی در ساختمان ها در
441، 900 و 1400 مگاهرتز، در جلسه چهارمین کنفرانس بین المللی رادیو موبایل زمین، 4.

کلیک کنید مدولار روتر ادغام

Click یک معماری نرم افزاری برای ساخت روترهای قابل تنظیم است. با استفاده از متفاوت
ترکیبی از واحدهای پردازش بسته به نام عناصر، یک روتر کلیک می تواند ساخته شود
نوع خاصی از عملکرد را انجام دهد. این انعطاف پذیری بستر خوبی را برای
آزمایش و آزمایش با پروتکل های مختلف.

مدل توضیحات:
کد منبع برای مدل Click در فهرست موجود است src/کلیک کنید.

طرح
طراحی ns-3 به دلایل زیر برای ادغام با Click مناسب است:

· بسته های موجود در ns-3 در حین حرکت به سمت بالا/پایین پشته سریالی/آسیالیزه می شوند. این اجازه می دهد
بسته های ns-3 برای ارسال به و از روی کلیک همانطور که هستند.

· این همچنین به این معنی است که هر نوع مولد ترافیک و حمل و نقل ns-3 باید به راحتی کار کند
در بالای کلیک کنید.

· با تلاش برای پیاده سازی کلیک به عنوان یک نمونه Ipv4RoutingProtocol، می توانیم اجتناب کنیم
تغییرات قابل توجهی در لایه LL و MAC کد ns-3.

هدف طراحی این بود که API عمومی ns-3-click به اندازه کافی ساده باشد تا کاربر
فقط باید یک نمونه Ipv4ClickRouting را به گره اضافه کند و به هر گره Click اطلاع دهد.
از فایل پیکربندی کلیک (فایل کلیک) که قرار است استفاده شود.

این مدل اینترفیس را به روتر ماژولار کلیک پیاده سازی کرده و آن را فراهم می کند
کلاس Ipv4ClickRouting به یک گره اجازه می دهد از Click برای مسیریابی خارجی استفاده کند. بر خلاف معمولی
انواع فرعی Ipv4RoutingProtocol، Ipv4ClickRouting از روش RouteInput() استفاده نمی کند، اما
در عوض، بسته ای را در رابط مناسب دریافت می کند و بر اساس آن پردازش می کند. توجه داشته باشید
که برای استفاده از Click for باید یک عنصر از نوع جدول مسیریابی در نمودار کلیک خود داشته باشید
مسیریابی خارجی این مورد نیاز تابع RouteOutput() است که از آن به ارث رسیده است
پروتکل Ipv4Routing. علاوه بر این، یک گره مبتنی بر کلیک از نوع دیگری از L3 در
فرم Ipv4L3ClickProtocol، که نسخه کوتاه شده Ipv4L3Protocol است.
Ipv4L3ClickProtocol روی بسته هایی که از پشته عبور می کنند به Ipv4ClickRouting برای
در حال پردازش.

در حال توسعه a شبیه ساز API به اجازه دادن ns-3 به تعامل با کلیک کنید
بسیاری از API در حال حاضر به خوبی تعریف شده است، که به کلیک اجازه می دهد اطلاعات را از آن بررسی کند
شبیه ساز (مانند شناسه گره، شناسه رابط و غیره). با حفظ بسیاری از
روش‌ها، باید بتوان پیاده‌سازی‌های جدید مخصوص ns-3 را برای آن نوشت
عملکرد.

بنابراین، برای ادغام Click با ns-3، کلاسی به نام Ipv4ClickRouting،
تعامل با کلیک کد مربوط به همان را می توان در پیدا کرد
src/click/model/ipv4-click-routing.{cc,h}.

بسته دست خاموش میان ns-3 و کلیک کنید
چهار نوع انتقال بسته وجود دارد که می تواند بین ns-3 و Click رخ دهد.

· L4 تا L3

· L3 تا L4

· L3 تا L2

· L2 تا L3

برای غلبه بر این مشکل، ما Ipv4L3ClickProtocol را پیاده سازی کردیم، یک نسخه حذف شده از
پروتکل Ipv4L3. Ipv4L3ClickProtocol بسته ها را به و از Ipv4ClickRouting ارسال می کند
مناسب برای انجام مسیریابی

حوزه و محدودیت ها
· در حالت فعلی، یکپارچه سازی کلیک NS-3 برای استفاده فقط با L3 محدود شده است
NS-3 برای رسیدگی به L2. ما در حال حاضر روی اضافه کردن پشتیبانی Click MAC نیز کار می کنیم. را ببینید
بخش استفاده برای اطمینان از اینکه نمودارهای کلیک خود را مطابق با آن طراحی کرده اید.

علاوه بر این، ns-3-click فقط با عناصر سطح کاربر کار می کند. لیست کامل از
عناصر در دسترس هستند http://read.cs.ucla.edu/click/elements. عناصری که دارند
ممکن است از «همه»، «سطح کاربر» یا «ns» ذکر شده در کنار آنها استفاده شود.

· در حال حاضر، رابط ns-3 برای کلیک فقط Ipv4 است. ما پشتیبانی Ipv6 را اضافه خواهیم کرد
آینده.

منابع
· ادی کوهلر، رابرت موریس، بنجی چن، جان جانوتی و ام. فرانس کاشوک. را
روتر مدولار را کلیک کنید. معاملات ACM در سیستم های کامپیوتری 18(3)، اوت 2000، صفحات
263 297.

· لالیث سورش پی، و روبن مرز. Ns-3-click: روی ادغام روتر مدولار برای ns-3 کلیک کنید.
در Proc. سومین کارگاه بین المللی ICST در NS-3 (WNS3)، بارسلون، اسپانیا. مارس،
2011.

· مایکل نوفلد، اشیش جین و دیرک گرونوالد. Nsclick: شبیه سازی شبکه پل زدن
و استقرار MSWiM '02: مجموعه مقالات پنجمین کارگاه بین المللی ACM در مورد مدل سازی
تجزیه و تحلیل و شبیه سازی سیستم های بی سیم و سیار، 2002، آتلانتا، جورجیا، ایالات متحده آمریکا.
http://doi.acm.org/10.1145/570758.570772

استفاده
بنا کلیک کنید
اولین قدم این است که کلیک را از مخزن github کلون کنید و آن را بسازید:

$ git clone https://github.com/kohler/click
$ cd کلیک/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
$ ساخت

اگر قصد ندارید از Click with Wifi استفاده کنید، پرچم --enable-wifi ممکن است نادیده گرفته شود. *
توجه: نیازی به انجام "make install" ندارید.

هنگامی که Click با موفقیت ساخته شد، به دایرکتوری ns-3 بروید و ns-3 را پیکربندی کنید
با پشتیبانی از یکپارچه سازی کلیک کنید:

$ ./waf configure --enable-examples --enable-tests --with-nsclick=/path/to/click/source

نکته: اگر روی یک دایرکتوری بالای ns-3 (مانند ns-3-allinone نصب شده) کلیک کرده باشید
دایرکتوری)، و نام دایرکتوری «کلیک» (یا یک پیوند نمادین به دایرکتوری) است
'click' نامیده می شود)، سپس مشخص کننده --with-nsclick ضروری نیست. ساخت ns-3
سیستم با موفقیت دایرکتوری را پیدا می کند.

اگر در کنار «پشتیبانی از یکپارچگی کلیک NS-3» عبارت «فعال» نوشته شده باشد، پس شما آماده هستید.
توجه: در صورت اجرای ماژولار ns-3، حداقل مجموعه ماژول های مورد نیاز برای اجرای همه ns-3 کلیک کنید.
مثال های wifi، csma و config-store است.

در مرحله بعد، یکی از مثال ها را اجرا کنید:

$ ./waf -- nsclick-simple-lan را اجرا کنید

سپس می توانید ردیابی های pcap. حاصل را مشاهده کنید که nsclick-simple-lan-0-0.pcap نامیده می شوند.
و nsclick-simple-lan-0-1.pcap.

کلیک کنید گراف دستورالعمل ها
هنگام ساخت نمودار کلیک باید موارد زیر را در نظر داشته باشید:

· فقط عناصر سطح کاربر را می توان استفاده کرد.

· شما باید عناصر FromDevice و ToDevice را با FromSimDevice و جایگزین کنید
عناصر ToSimDevice.

· بسته ها به هسته با استفاده از ToSimDevice (tap0، IP) ارسال می شوند.

· برای هر گره، دستگاهی که بسته ها را به/از هسته می فرستد/دریافت می کند، نامگذاری می شود.
'tap0'. رابط‌های باقی‌مانده باید eth0، eth1 و غیره نام‌گذاری شوند (حتی اگر شما هستید
با استفاده از وای فای). لطفا توجه داشته باشید که شماره گذاری دستگاه باید از 0 شروع شود. در آینده، این
انعطاف پذیر خواهد بود به طوری که کاربران می توانند دستگاه ها را در فایل کلیک خود به دلخواه نام گذاری کنند.

· عنصر جدول مسیریابی اجباری است. OUTport های عنصر جدول مسیریابی باید
مربوط به شماره رابط دستگاهی است که بسته از طریق آن انجام می شود
در نهایت فرستاده شود نقض این قانون منجر به ردیابی بسته های واقعاً عجیب می شود.
نام این عنصر جدول مسیریابی باید به پروتکل Ipv4ClickRouting منتقل شود
شی به عنوان پارامتر شبیه سازی برای جزئیات بیشتر به مثال های کلیک کنید.

· اجرای کنونی کلیک را با قابلیت L3 عمدتاً با مدیریت ns-3 می گذارد
L2. ما به زودی برای پشتیبانی از استفاده از پروتکل های MAC در کلیک نیز شروع به کار خواهیم کرد.
این بدان معنی است که از هم اکنون، عناصر خاص وای فای Click را نمی توان با ns-3 استفاده کرد.

اشکال زدایی بسته جریانها از جانب کلیک کنید
از هر نقطه در نمودار کلیک، می توانید از چاپ استفاده کنید (-
http://read.cs.ucla.edu/click/elements/print) عنصر و انواع آن برای چاپ زیبا
از محتویات بسته علاوه بر این، شما می توانید ردپای pcap از بسته هایی که از طریق a جریان می یابند ایجاد کنید
با استفاده از ToDump روی نمودار کلیک کنید (http://read.cs.ucla.edu/click/elements/todump) عنصر به عنوان
خوب. برای مثال:

myarpquerier
-> چاپ (fromarpquery,64)
-> ToDump (out_arpquery، PER_NODE 1)
-> ethout;

و ... محتویات بسته هایی را که از ArpQuerier خارج می شوند چاپ می کند، سپس یک
فایل ردیابی pcap که دارای پسوند «out_arpquery» است، برای هر گره با استفاده از کلیک
فایل، قبل از فشار دادن بسته ها به 'ethout'.

کمک کننده
برای اجرای یک گره Click، ساده ترین راه استفاده از ClickInternetStackHelper است.
کلاس در اسکریپت شبیه سازی شما برای مثال:

ClickInternetStackHelper کلیک کنید.
click.SetClickFile (myNodeContainer، "nsclick-simple-lan.click");
click.SetRoutingTableElement (myNodeContainer، "u/rt");
click.Install (myNodeContainer)؛

نمونه اسکریپت های داخل src/click/examples/ نشان دادن استفاده از گره های مبتنی بر کلیک در
سناریوهای مختلف منبع کمکی را می توان در داخل یافت
src/click/helper/click-internet-stack-helper.{h,cc}

مثال ها
نمونه های زیر نوشته شده است که می توان آنها را در src/click/examples/:

· nsclick-simple-lan.cc و nsclick-raw-wlan.cc: یک گره مبتنی بر کلیک که با یک
گره معمولی ns-3 بدون کلیک، به ترتیب با استفاده از Csma و Wifi. همچنین نشان می دهد
استفاده از TCP در بالای کلیک، چیزی که اجرای nsclick اصلی برای آن است
NS-2 نتوانست به دست آورد.

· nsclick-udp-client-server-csma.cc و nsclick-udp-client-server-wifi.cc: یک شبکه LAN 3 گره
(به ترتیب Csma و Wifi) که در آن 2 گره مبتنی بر کلیک یک سرویس گیرنده UDP را اجرا می کنند که ارسال می کند
بسته ها را به گره سوم مبتنی بر کلیک که یک سرور UDP را اجرا می کند.

· nsclick-routing.cc: گره مبتنی بر یک کلیک از طریق یک گره سوم با گره دیگری ارتباط برقرار می کند.
به عنوان روتر IP عمل می کند (با استفاده از تنظیمات کلیک کنید روتر IP). این نشان می دهد
مسیریابی با استفاده از کلیک.

اسکریپت ها در داخل موجود هستند /conf/ که به شما امکان می دهد فایل های Click را برای آن تولید کنید
برخی از سناریوهای رایج روتر IP مورد استفاده در nsclick-routing.cc از تولید شد
فایل make-ip-conf.pl و کمی برای کار با ns-3-click سازگار شده است.

اعتبار
این مدل به صورت زیر تست شده است:

· تست های واحد برای تأیید داخلی Ipv4ClickRouting نوشته شده است. این میتواند باشد
موجود در src/click/ipv4-click-routing-test.cc. این تست ها بررسی می کنند که آیا روش ها
داخل Ipv4ClickRouting که با نام دستگاه به شناسه، آدرس IP از نام دستگاه سروکار دارد
و مک آدرس از اتصالات نام دستگاه همانطور که انتظار می رود کار می کنند.

· از مثال ها برای تست کلیک با سناریوهای شبیه سازی واقعی استفاده شده است. اینها می توانند باشند
موجود در src/click/examples/. این تست ها موارد زیر را پوشش می دهند: استفاده از انواع مختلف
انواع انتقال در بالای کلیک، TCP/UDP، چه گره های کلیک بتوانند با آن ارتباط برقرار کنند
گره های غیر مبتنی بر کلیک، اینکه آیا گره های Click می توانند با استفاده از کلیک با یکدیگر ارتباط برقرار کنند
برای مسیریابی بسته ها با استفاده از مسیریابی استاتیک.

· کلیک با دستگاه های Csma، Wifi و Point-to-Point تست شده است. دستورالعمل استفاده هستند
موجود در بخش قبل

CSMA NetDEVICE

این مقدمه فصل CSMA NetDevice است که مکمل داکسیژن مدل Csma است.

بررسی اجمالی of la CSMA مدل
La ns-3 دستگاه CSMA یک شبکه اتوبوس ساده را با روح اترنت مدل می کند. هرچند آن
هیچ شبکه فیزیکی واقعی را که بتوانید بسازید یا بخرید مدل نمی کند، برخی از آن ها را ارائه می دهد
عملکرد بسیار مفید

معمولاً وقتی به یک شبکه گذرگاهی اترنت یا IEEE 802.3 فکر می کنید به ذهن می رسد. شبکه محلی کابلی
از CSMA/CD (Carrier Sense Multiple Access with Collision Detection با نمایی استفاده می کند.
افزایش عقب نشینی برای مبارزه برای رسانه انتقال مشترک. در ns-3 دستگاه CSMA
تنها بخشی از این فرآیند را با استفاده از ماهیت کانال موجود در سطح جهانی مدل می کند
برای ایجاد حس حامل آنی (سریعتر از نور) و برخورد مبتنی بر اولویت
"اجتناب." برخورد در مفهوم اترنت هرگز اتفاق نمی افتد و بنابراین ns-3 دستگاه CSMA
تشخیص برخورد را مدل نمی کند، و هیچ انتقالی که در حال انجام است "جمد" نمی شود.

CSMA لایه مدل
تعدادی از قراردادها برای توصیف ارتباطات لایه ای استفاده می شود
معماری در ادبیات و کتب درسی رایج ترین مدل لایه بندی است
مدل مرجع هفت لایه ISO. در این نمای جفت CsmaNetDevice و CsmaChannel
پایین ترین دو لایه را اشغال می کند - در قسمت فیزیکی (لایه یک) و پیوند داده (لایه دو)
موقعیت ها مدل مرجع مهم دیگر مدلی است که توسط RFC 1122، "نیازها
برای میزبان های اینترنت -- لایه های ارتباطی." در این دیدگاه CsmaNetDevice و
جفت CsmaChannel پایین ترین لایه - لایه پیوند را اشغال می کند. به ظاهر هم وجود دارد
انبوهی بی پایان از توصیف های جایگزین موجود در کتاب های درسی و ادبیات. ما
قوانین نامگذاری مورد استفاده در استانداردهای IEEE 802 را که از LLC، MAC، MII صحبت می کنند، بپذیرید.
و لایه بندی PHY. این کلمات اختصاری به این صورت تعریف می شوند:

· LLC: کنترل پیوند منطقی.

· MAC: کنترل دسترسی به رسانه.

· MII: رابط مستقل رسانه.

· PHY: لایه فیزیکی.

در این مورد LLC و MAC زیر لایه های لایه پیوند داده OSI و MII و PHY
زیر لایه های لایه فیزیکی OSI هستند.

"بالا" دستگاه CSMA انتقال از لایه شبکه به داده را تعریف می کند
لایه پیوند این انتقال توسط لایه های بالاتر با فراخوانی هر یک انجام می شود
CsmaNetDevice::Send یا CsmaNetDevice::SendFrom.

برخلاف استانداردهای IEEE 802.3، هیچ PHY مشخصی در CSMA وجود ندارد.
مدل به معنای انواع سیم، سیگنال یا پین اوت. رابط "پایین" از
CsmaNetDevice را می توان به عنوان نوعی رابط مستقل رسانه (MII) در نظر گرفت
در مشخصات "Fast Ethernet" (IEEE 802.3u). این رابط MII در یک جا می شود
رابط مستقل رسانه مربوطه در CsmaChannel. شما را پیدا نخواهید کرد
معادل 10BASE-T یا 1000BASE-LX PHY.

CsmaNetDevice CsmaChannel را از طریق یک رابط مستقل رسانه ای فراخوانی می کند. وجود دارد
روشی تعریف شده است تا به کانال بگوید چه زمانی باید با استفاده از روش شروع به "تکان دادن سیم ها" کند
CsmaChannel::TransmitStart و روشی برای اطلاع از کانال در زمان فرآیند انتقال
انجام می شود و کانال باید انتشار آخرین بیت را در سراسر "سیم" آغاز کند:
CsmaChannel::TransmitEnd.

هنگامی که روش TransmitEnd اجرا می شود، کانال یک سیگنال یکنواخت واحد را مدل می کند
تأخیر انتشار در محیط و تحویل کوپه های بسته به هر یک از دستگاه ها
از طریق روش CsmaNetDevice::Receive به بسته متصل می شود.

یک "پین" در رابط مستقل رسانه دستگاه مربوط به "COL" وجود دارد.
(برخورد). وضعیت کانال ممکن است با تماس با CsmaChannel::GetState احساس شود. هر یک
دستگاه قبل از شروع ارسال به این "پین" نگاه می کند و عقب نشینی مناسب را انجام می دهد
عملیات در صورت نیاز

بسته های دریافت شده به درستی از طریق a به سطوح بالاتر از CsmaNetDevice ارسال می شوند
مکانیسم تماس برگشتی تابع callback توسط لایه بالاتر (هنگامی که شبکه است) مقداردهی اولیه می شود
دستگاه متصل شده است) با استفاده از CsmaNetDevice::SetReceiveCallback و پس از "مناسب" فراخوانی می شود
دریافت یک بسته توسط دستگاه شبکه به منظور ارسال بسته به پروتکل
پشته.

CSMA کانال مدل
کلاس CsmaChannel رسانه انتقال واقعی را مدل می کند. هیچ محدودیت ثابتی برای وجود ندارد
تعداد دستگاه های متصل به کانال CsmaChannel یک نرخ داده و a را مدل می کند
تاخیر سرعت نور که از طریق ویژگی های "DataRate" و "Delay" قابل دسترسی است.
به ترتیب. نرخ داده ارائه شده به کانال برای تنظیم نرخ داده استفاده شده توسط استفاده می شود
بخش های فرستنده دستگاه های CSMA متصل به کانال. هیچ راهی وجود ندارد
به طور مستقل نرخ داده را در دستگاه ها تنظیم کنید. از آنجایی که نرخ داده فقط برای محاسبه استفاده می شود
یک زمان تاخیر، هیچ محدودیتی (به جز نوع داده ای که مقدار را نگه می دارد) وجود ندارد
سرعتی که کانال ها و دستگاه های CSMA می توانند با آن کار کنند. و هیچ محدودیتی بر اساس هیچ
نوع ویژگی های PHY

CsmaChannel دارای سه حالت است، IDLE, انتقال و تکثیر. این سه حالت
بلافاصله توسط تمام دستگاه های موجود در کانال "دیده" می شوند. منظور ما این است که اگر یکی
دستگاه یک انتقال شبیه سازی شده را شروع یا پایان می دهد، همه دستگاه های موجود در کانال هستند بلافاصله
از تغییر حالت آگاه است. هیچ زمانی وجود ندارد که در طی آن یک دستگاه ممکن است یک را ببیند IDLE
کانال در حالی که دستگاه دیگری از نظر فیزیکی دورتر در حوزه برخورد ممکن است داشته باشد
شروع به ارسال با سیگنال های مرتبط که از کانال به کانال دیگر منتشر نمی شود
دستگاه ها بنابراین نیازی به تشخیص برخورد در مدل CsmaChannel نیست و همینطور است
به هیچ وجه اجرا نمی شود.

همانطور که از نام آن مشخص است، یک جنبه Carrier Sense برای مدل داریم. از آنجا که
شبیه ساز تک رشته ای است، دسترسی به کانال مشترک توسط
شبیه ساز این یک مکانیسم قطعی برای رقابت برای کانال فراهم می کند. در
کانال تخصیص داده شده است (انتقال از حالت IDLE بیان کند انتقال) با اولین مراجعه
اولین خدمت کانال همیشه از یک فرآیند سه حالته عبور می کند:

IDLE -> TRANSMITTING -> Propagating -> IDLE

La انتقال state زمانی را مدل می کند که در طی آن دستگاه شبکه منبع واقعاً وجود دارد
تکان دادن سیگنال های روی سیم در تکثیر مدل های حالت زمان بعد از آخرین بیت
هنگامی که سیگنال در سیم تا "انتهای دور" منتشر می شود، ارسال شد.

انتقال به انتقال حالت توسط تماس به هدایت می شود
CsmaChannel::TransmitStart که توسط دستگاه شبکه ای که بسته را ارسال می کند فراخوانی می شود. آی تی
وظیفه آن دستگاه است که انتقال را با یک تماس به پایان برساند
CsmaChannel::TransmitEnd در زمان شبیه سازی مناسب که زمان سپری شده را منعکس می کند
برای قرار دادن تمام بیت های بسته روی سیم. هنگامی که TransmitEnd فراخوانی می شود، کانال
یک رویداد مربوط به یک تاخیر سرعت نور را برنامه ریزی می کند. این تاخیر برای
همه دستگاه های شبکه در کانال یکسان هستند. می توانید به یک هاب متقارن فکر کنید که در آن
بیت‌های بسته به یک مکان مرکزی منتشر می‌شوند و سپس کابل‌های طول مساوی را خارج می‌کنند
سایر دستگاه های موجود در کانال تنها تاخیر "سرعت نور" مربوط می شود
زمان لازم برای: 1) انتشار سیگنال از یک دستگاه CsmaNet از طریق کابل آن
به هاب؛ به علاوه 2) مدت زمانی که هاب برای ارسال بسته به خارج از یک پورت طول می کشد. به علاوه
3) مدت زمانی که طول می کشد تا سیگنال مورد نظر به شبکه مقصد منتشر شود
دستگاه.

CsmaChannel یک رسانه پخش را مدل سازی می کند تا بسته به همه دستگاه ها تحویل داده شود
در کانال (از جمله منبع) در پایان زمان انتشار. آن است
مسئولیت دستگاه فرستنده برای تعیین اینکه آیا یک بسته را دریافت می کند یا خیر
از طریق کانال پخش می شود

CsmaChannel ویژگی های زیر را ارائه می دهد:

· DataRate: نرخ بیت برای انتقال بسته در دستگاه های متصل.

· تاخیر: سرعت تاخیر انتقال نور برای کانال.

CSMA خالص دستگاه مدل
دستگاه شبکه CSMA تا حدودی شبیه یک دستگاه اترنت به نظر می رسد. دستگاه CsmaNet
ویژگی های زیر را ارائه می دهد:

· آدرس: Mac48Address دستگاه.

· SendEnable: در صورت صحت، انتقال بسته را فعال کنید.

· ReceiveEnable: در صورت درست بودن، دریافت بسته را فعال کنید.

· EncapsulationMode: نوع پوشش لایه پیوند برای استفاده.

· RxErrorModel: مدل خطای دریافت.

· TxQueue: صف ارسال استفاده شده توسط دستگاه.

· InterframeGap: زمان اختیاری برای انتظار بین "فریم ها".

· Rx: منبع ردیابی برای بسته های دریافتی.

· Drop: یک منبع ردیابی برای بسته های رها شده.

CsmaNetDevice از تخصیص "مدل خطای دریافت" پشتیبانی می کند. این یک
شی ErrorModel که برای شبیه سازی خرابی داده ها در پیوند استفاده می شود.

بسته های ارسال شده از طریق CsmaNetDevice همیشه از طریق صف ارسال به آن هدایت می شوند
یک قلاب ردیابی برای بسته های ارسال شده از طریق شبکه فراهم کنید. این صف ارسال را می توان تنظیم کرد
(از طریق ویژگی) برای مدل سازی استراتژی های مختلف صف.

همچنین روش کپسولاسیون مورد استفاده توسط دستگاه قابل تنظیم بر اساس ویژگی است. هر
بسته یک EthernetHeader دریافت می کند که شامل آدرس های MAC مقصد و مبدا و
یک فیلد طول/نوع هر بسته همچنین یک EthernetTrailer دریافت می کند که شامل FCS است.
داده های موجود در بسته ممکن است به روش های مختلف کپسوله شوند.

به‌طور پیش‌فرض، یا با تنظیم ویژگی «EncapsulationMode» روی «Dix»، کپسوله‌سازی به صورت
طبق استاندارد DEC، Intel، زیراکس. گاهی اوقات به این قاب بندی EthernetII گفته می شود
و مقصد آشنا MAC، منبع MAC، EtherType، داده، فرمت CRC است.

اگر ویژگی "EncapsulationMode" روی "Llc" تنظیم شود، کپسوله سازی توسط LLC SNAP انجام می شود. که در
در این مورد، یک هدر SNAP اضافه می شود که حاوی EtherType (IP یا ARP) است.

سایر حالت‌های کپسوله‌سازی پیاده‌سازی شده IP_ARP هستند ("EncapsulationMode" را روی "IpArp" تنظیم کنید)
که در آن نوع طول هدر اترنت شماره پروتکل را دریافت می کند
بسته؛ یا ETHERNET_V1 (تنظیم "EncapsulationMode" به "EthernetV1") که در آن نوع طول
هدر اترنت طول بسته را دریافت می کند. یک حالت کپسوله سازی "خام" است
تعریف شده اما اجرا نشده -- استفاده از حالت RAW منجر به یک ادعا می شود.

توجه داشته باشید که تمام دستگاه های شبکه در یک کانال باید روی یک حالت کپسوله سازی تنظیم شوند
نتایج صحیح حالت کپسوله سازی در گیرنده حس نمی شود.

CsmaNetDevice یک الگوریتم عقبگرد نمایی تصادفی را پیاده سازی می کند که اگر اجرا شود
کانال شلوغ است (انتقال or انتشار) زمانی که دستگاه بخواهد
برای شروع تکثیر این منجر به تاخیر تصادفی تا پاو (2، تلاش مجدد) - 1 می شود
میکروثانیه قبل از تلاش مجدد. حداکثر تعداد دفعات تکرار پیش فرض 1000 است.

با استفاده از la CsmaNetDevice
دستگاه‌ها و کانال‌های شبکه CSMA معمولاً با استفاده از آن ایجاد و پیکربندی می‌شوند
مرتبط است CsmaHelper هدف - شی. مختلف ns-3 کمک‌کنندگان دستگاه معمولاً در موارد مشابه کار می‌کنند
روش، و استفاده از آنها در بسیاری از برنامه های نمونه ما دیده می شود.

مدل مفهومی مورد علاقه یک "پوسته" کامپیوتری است که شبکه را به آن وصل می کنید
دستگاه ها کامپیوترهای خالی با استفاده از a ایجاد می شوند NodeContainer یاور. فقط اینو بپرس
کمک کننده برای ایجاد تعداد زیادی رایانه (ما آنها را می نامیم گره ها) همانطور که در شبکه خود نیاز دارید:

NodeContainer csmaNodes;
csmaNodes.Create (nCsmaNodes);

هنگامی که گره های خود را دارید، باید a را نمونه سازی کنید CsmaHelper و هر ویژگی را برای شما تنظیم کنید
ممکن است بخواهد تغییر کند.:

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate"، StringValue ("100Mbps"));
csma.SetChannelAttribute ("تاخیر"، TimeValue (NanoSeconds (6560)));

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

پس از تنظیم ویژگی ها، تنها چیزی که باقی می ماند این است که دستگاه ها را ایجاد کرده و آنها را نصب کنید
گره های مورد نیاز، و برای اتصال دستگاه ها به یکدیگر با استفاده از یک کانال CSMA. هنگامی که ما
دستگاه های شبکه را ایجاد کنید، آنها را به یک ظرف اضافه می کنیم تا به شما امکان استفاده از آنها در آینده را بدهیم.
این همه فقط یک خط کد را می گیرد.:

NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

توصیه می کنیم در مورد تغییر این ویژگی ها با دقت فکر کنید، زیرا ممکن است منجر به تغییر آن شود
رفتاری که کاربران را شگفت زده می کند. ما این اجازه را می دهیم زیرا معتقدیم انعطاف پذیری مهم است.
به عنوان مثالی از تأثیر احتمالاً شگفت‌انگیز تغییر ویژگی‌ها، این را در نظر بگیرید
زیر است:

ویژگی Mtu حداکثر واحد انتقال را به دستگاه نشان می دهد. این اندازه است
از بزرگترین واحد داده پروتکل (PDU) که ​​دستگاه می تواند ارسال کند. این ویژگی پیش‌فرض است
به 1500 بایت و مطابق با عدد موجود در RFC 894، "استانداردی برای
انتقال دیتاگرام های IP از طریق شبکه های اترنت." این عدد در واقع از آن مشتق شده است
حداکثر اندازه بسته برای شبکه های 10Base5 (اترنت با مشخصات کامل) -- 1518 بایت. اگر شما
از سربار کپسوله سازی DIX برای بسته های اترنت (18 بایت) کم کنید.
حداکثر اندازه داده ممکن (MTU) 1500 بایت. همچنین می توان دریافت که MTU برای IEEE
802.3 شبکه 1492 بایت است. این به این دلیل است که کپسوله سازی LLC/SNAP هشت مورد اضافی را اضافه می کند
بایت سربار به بسته. در هر دو مورد، سخت افزار زیربنایی شبکه است
محدود به 1518 بایت است، اما MTU متفاوت است زیرا کپسوله سازی متفاوت است.

اگر یکی از ویژگی Mtu را در 1500 بایت رها کند و ویژگی حالت کپسوله‌سازی را تغییر دهد.
به Llc، نتیجه شبکه ای خواهد بود که PDU های 1500 بایتی را با LLC/SNAP محصور می کند.
فریم بندی که منجر به بسته های 1526 بایتی می شود. این امر در بسیاری از شبکه ها غیرقانونی خواهد بود، اما
ما به شما اجازه انجام این کار را می دهیم. این منجر به شبیه‌سازی می‌شود که به طور کاملاً نامحسوس منعکس نمی‌شود
چیزی که ممکن است انتظار داشته باشید زیرا یک دستگاه واقعی از ارسال یک بسته 1526 بایتی خودداری می کند.

همچنین فریم های جامبو (1500 < MTU <= 9000 بایت) و سوپر جامبو (MTU > 9000) وجود دارد.
بایت ها) فریم هایی که به طور رسمی توسط IEEE تایید نشده اند اما در برخی از آنها موجود است
شبکه های پرسرعت (گیگابیت) و NIC. در مدل CSMA، می توان آن را ترک کرد
حالت کپسوله‌سازی را روی Dix تنظیم کنید و Mtu را روی 64000 بایت تنظیم کنید - حتی اگر یک
CsmaChannel DataRate روی 10 مگابیت در ثانیه باقی ماند (مطمئناً اترنت گیگابیتی نیست).
این در اصل یک سوئیچ اترنت ساخته شده از سبک دهه 1980 توسط خون آشام ها را مدل می کند
شبکه‌های 10Base5 که از دیتاگرام‌های فوق‌جنگی پشتیبانی می‌کنند، که مطمئناً چیزی نیست
هرگز ساخته شده است، و نه به احتمال زیاد هرگز ساخته شده است. با این حال آن را برای شما بسیار آسان است
پیکربندی کنید.

مراقب فرضیات مربوط به اینکه CSMA واقعاً چه چیزی را مدلسازی می کند و چگونه است، باشید
پیکربندی (ویژگی ها) ممکن است به شما اجازه دهد تا به میزان قابل توجهی از واقعیت فاصله بگیرید.

CSMA ردیابی
مثل همه ns-3 دستگاه‌ها، مدل CSMA تعدادی منبع ردیابی را فراهم می‌کند. این ردیابی
منابع را می توان با استفاده از کد ردیابی سفارشی خود قلاب کرد، یا می توانید از راهنما ما استفاده کنید
توابع برای تنظیم برای فعال کردن ردیابی در دستگاه هایی که شما مشخص می کنید.

مرحله بالاتر (مک) قلاب
از نظر ردیابی در دستگاه نت چند نکته جالب وجود دارد
برای وارد کردن قلاب های ردیابی قراردادی که از دیگر شبیه سازها به ارث رسیده است، بسته ها است
برای انتقال به شبکه های متصل از یک "صف ارسال" منفرد عبور می کند
دستگاه نت ما قلاب های ردیابی را در این نقطه در جریان بسته ارائه می دهیم که مطابقت دارد
(به صورت انتزاعی) فقط به انتقال از شبکه به لایه پیوند داده، و آنها را فراخوانی کنید
در مجموع دستگاه MAC قلاب می کند.

هنگامی که یک بسته برای انتقال به دستگاه شبکه CSMA ارسال می شود، همیشه از طریق آن عبور می کند
صف انتقال صف ارسال در CsmaNetDevice از Queue به ارث می رسد و بنابراین
سه منبع ردیابی را به ارث می برد:

· منبع عملیات Enqueue (به صف::m_traceEnqueue مراجعه کنید).

· منبع عملیات Dequeue (به صف::m_traceDequeue مراجعه کنید).

· منبع عملیات Drop (به صف::m_traceDrop مراجعه کنید).

قلاب های ردیابی سطح بالایی (MAC) برای CsmaNetDevice، در واقع دقیقاً این سه هستند.
منابع ردیابی در صف انتقال واحد دستگاه.

رویداد m_traceEnqueue زمانی فعال می شود که یک بسته در صف ارسال قرار می گیرد. این
زمانی اتفاق می افتد که CsmaNetDevice::Send یا CsmaNetDevice::SendFrom توسط یک
لایه بالاتر برای صف بندی یک بسته برای انتقال.

رویداد m_traceDequeue زمانی فعال می شود که بسته ای از صف ارسال حذف شود.
Dequeues از صف ارسال می تواند در سه وضعیت رخ دهد: 1) اگر زمینه
هنگامی که CsmaNetDevice::Send یا CsmaNetDevice::SendFrom فراخوانی شود، کانال بیکار است،
بسته از صف ارسال خارج می شود و بلافاصله ارسال می شود. 2) اگر
کانال زیربنایی غیرفعال است، یک بسته ممکن است از صف خارج شود و بلافاصله در یک ارسال شود
TransmitCompleteEvent داخلی که مانند یک وقفه کامل انتقال عمل می کند
روال خدمات؛ یا 3) از کنترل کننده عقب نشینی نمایی تصادفی در صورت وجود وقفه
شناسایی شده.

مورد (3) دلالت بر این دارد که یک بسته در صورت عدم امکان از صف ارسال خارج می شود.
طبق قوانین عقب نشینی منتقل می شود. مهم است که درک کنیم که این خواهد بود
به عنوان یک بسته Dequeued ظاهر می شود و به راحتی می توان به اشتباه فرض کرد که بسته بود
از آنجایی که از صف ارسال عبور کرده است منتقل می شود. در واقع، یک بسته در واقع است
در این مورد توسط دستگاه نت رها شده است. دلیل این رفتار به دلیل
تعریف رویداد Queue Drop. رویداد m_traceDrop طبق تعریف زمانی که a
بسته را نمی توان در صف ارسال قرار داد زیرا پر است. این رویداد فقط آتش می گیرد
اگر صف پر باشد و این رویداد را بیش از حد بارگذاری نکنیم تا نشان دهیم که CsmaChannel است
"پر شده."

سطح پایین تر (PHY) قلاب
مشابه قلاب های ردیابی سطح بالایی، قلاب های ردیابی در قسمت پایینی موجود هستند
سطوح دستگاه شبکه ما اینها را قلاب های PHY می نامیم. این رویدادها از دستگاه شلیک می شوند
روش هایی که مستقیماً با CsmaChannel صحبت می کنند.

منبع ردیابی m_dropTrace برای نشان دادن بسته ای که توسط دستگاه رها شده است فراخوانی می شود.
این در دو مورد اتفاق می افتد: اول، اگر سمت گیرنده دستگاه نت فعال نباشد
(به CsmaNetDevice::m_receiveEnable و ویژگی مرتبط "ReceiveEnable" مراجعه کنید).

m_dropTrace همچنین برای نشان دادن اینکه یک بسته به عنوان خراب حذف شده است استفاده می شود
مدل خطای دریافت استفاده می شود (به CsmaNetDevice::m_receiveErrorModel و موارد مرتبط مراجعه کنید
ویژگی "ReceiveErrorModel").

منبع ردیابی سطح پایین دیگر با دریافت بسته پذیرفته شده فعال می شود (نگاه کنید به
CsmaNetDevice::m_rxTrace). بسته ای پذیرفته می شود که برای پخش باشد
آدرس، یک آدرس چندپخشی یا به آدرس MAC اختصاص داده شده به دستگاه نت.

خلاصه
مدل ns3 CSMA یک مدل ساده از یک شبکه اترنت مانند است. از a پشتیبانی می کند
عملکرد Carrier-Sense و امکان دسترسی چندگانه به یک رسانه مشترک را فراهم می کند. این نیست
فیزیکی به این معنا که حالت رسانه فوراً بین همه تقسیم می شود
دستگاه ها این بدان معنی است که در این مدل نیازی به تشخیص برخورد نیست و هیچ
اجرا می شود. هرگز "جمع" یک بسته در حال حاضر در رسانه وجود نخواهد داشت. دسترسی به
کانال به اشتراک‌گذاشته‌شده به‌صورتی که توسط شبیه‌ساز تعیین می‌شود، بر اساس اولویت اول است
زمانبندی اگر مشخص شد که کانال با نگاه کردن به وضعیت جهانی مشغول است، الف
عقب نشینی نمایی تصادفی انجام می شود و سعی مجدد انجام می شود.

ویژگی های Ns-3 مکانیزمی برای تنظیم پارامترهای مختلف در دستگاه و
کانال هایی مانند آدرس ها، حالت های کپسوله سازی و انتخاب مدل خطا. قلاب های ردیابی هستند
به روش معمول با مجموعه ای از قلاب های سطح بالایی مطابق با یک انتقال ارائه می شود
صف و در ردیابی ASCII استفاده می شود. و همچنین مجموعه ای از قلاب های سطح پایین تر مورد استفاده در ردیابی pcap.

اگرچه ns-3 CsmaChannel و CsmaNetDevice هیچ نوع شبکه ای را برای شما مدل نمی کند
می تواند بسازد یا بخرد، برخی از عملکردهای مفید را در اختیار ما قرار می دهد. تو باید،
با این حال، بدانید که صراحتاً اترنت یا هر طعمی از IEEE 802.3 نیست، بلکه یک
زیر مجموعه جالب

داده ها مجموعه

این فصل چارچوب جمع آوری داده های ns-3 (DCF) را شرح می دهد که ارائه می کند
قابلیت به دست آوردن داده های تولید شده توسط مدل ها در شبیه ساز، برای انجام آنلاین
کاهش و پردازش داده‌ها، و داده‌های خام یا تبدیل‌شده را به خروجی‌های مختلف هدایت می‌کنند
فرمت.

این چارچوب در حال حاضر از اجراهای مستقل ns-3 پشتیبانی می کند که به هیچ خارجی متکی نیستند
کنترل اجرای برنامه اشیاء ارائه شده توسط DCF ممکن است به آنها متصل شوند ns-3 رد
منابعی برای فعال کردن پردازش داده ها

کد منبع کلاس ها در دایرکتوری موجود است src/stats.

این فصل به شرح زیر سازماندهی شده است. ابتدا مروری بر معماری است
ارایه شده. در ادامه، کمک کنندگان این کلاس ها ارائه می شوند. این درمان اولیه
باید اجازه استفاده اساسی از چارچوب جمع آوری داده ها را برای بسیاری از موارد استفاده بدهد. کاربرانی که
مایل به تولید خروجی خارج از محدوده کمک های فعلی هستند، یا کسانی که مایل به ایجاد هستند
اشیاء جمع آوری داده های خود، باید بقیه فصل را که ادامه می دهد، بخوانند
به جزئیات در مورد تمام انواع شی DCF اساسی و کدگذاری سطح پایین ارائه می دهد
مثال ها.

طرح
DCF از سه کلاس اصلی تشکیل شده است:

· کاوشگر مکانیزمی برای ابزار دقیق و کنترل خروجی داده های شبیه سازی است
برای نظارت بر رویدادهای جالب استفاده می شود. خروجی را به شکل یک یا چند تولید می کند ns-3
منابع ردیابی اشیاء کاوشگر به یک یا چند اثر متصل می شوند غرق (به نام
جمع کننده ها) که نمونه ها را به صورت آنلاین پردازش کرده و آنها را برای خروجی آماده می کند.

· جمع کننده داده های تولید شده توسط یک یا چند شی Probe را مصرف می کند. اجرا می کند
تبدیل‌های روی داده‌ها، مانند عادی‌سازی، کاهش و محاسبه
آمار اولیه اشیاء جمع‌آوری داده‌ای را تولید نمی‌کنند که مستقیماً توسط آن خروجی شود
ns-3 اجرا؛ در عوض، آنها داده ها را در پایین دست به نوع دیگری از شی به نام خارج می کنند
جمع کننده، که آن عملکرد را انجام می دهد. به طور معمول، گردآورنده ها داده های خود را در خروجی قرار می دهند
شکل منابع ردیابی نیز وجود دارد که به کلکسیونرها اجازه می دهد به صورت زنجیره ای زنجیره شوند.

· جمع کننده نقطه پایانی داده های جمع آوری شده توسط شبکه ای از پروب ها و گردآورندگان است.
مسئولیت اصلی Aggregator جمع آوری داده ها و مربوط به آنها است
ابرداده، به فرمت های خروجی مختلف مانند فایل های متنی ساده، فایل های صفحه گسترده یا
پایگاه های داده

هر سه این کلاس ها این قابلیت را دارند که به صورت پویا خود را روشن یا خاموش کنند
در طول یک شبیه سازی

هر مستقل ns-3 اجرای شبیه‌سازی که از DCF استفاده می‌کند معمولاً حداقل یکی را ایجاد می‌کند
نمونه ای از هر یک از سه کلاس بالا.
[تصویر] نمای کلی چارچوب مجموعه داده ها.UNINDENT

جریان کلی پردازش داده ها به تصویر کشیده شده است داده ها مجموعه چارچوب مروری.
در سمت چپ، دویدن ns-3 شبیه سازی به تصویر کشیده شده است. در جریان اجرای
شبیه‌سازی، داده‌ها توسط مدل‌ها از طریق منابع ردیابی یا از طریق ابزارهای دیگر در دسترس قرار می‌گیرند.
این نمودار نشان می دهد که کاوشگرها می توانند به این منابع ردیابی برای دریافت داده متصل شوند
به صورت ناهمزمان، یا کاوشگرها می توانند برای داده ها نظرسنجی کنند. سپس داده ها به یک شی جمع کننده ارسال می شود
که داده ها را تبدیل می کند. در نهایت می توان یک جمع کننده را به خروجی ها متصل کرد
جمع کننده، برای تولید نمودارها، فایل ها یا پایگاه های داده.
[تصویر] گردآوری چارچوب مجموعه داده ها.UNINDENT

یک تغییر در شکل بالا در ارائه شده است داده ها مجموعه چارچوب تجمع.
این شکل دوم نشان می دهد که اشیاء DCF ممکن است به روشی به هم زنجیر شوند
که اشیاء پایین دست ورودی را از چندین شیء بالادست می گیرند. شکل
به طور مفهومی نشان می دهد که چندین پروب ممکن است خروجی تولید کنند که به یک واحد تغذیه می شود
جمع کننده به عنوان مثال، کلکتوری که نسبت دو شمارنده را خروجی می دهد
به طور معمول هر داده شمارنده را از پروب های جداگانه بدست می آورند. چندین کلکسیونر نیز می توانند
به یک جمع‌کننده منفرد تغذیه می‌شود، که (همانطور که از نامش پیداست) ممکن است تعدادی داده جمع‌آوری کند
جریان ها برای گنجاندن در یک طرح، فایل یا پایگاه داده واحد.

داده ها مجموعه یاران
انعطاف‌پذیری کامل چارچوب جمع‌آوری داده‌ها توسط اتصال متقابل ارائه می‌شود
کاوشگرها، کلکتورها و تجمیع کننده ها. انجام تمامی این ارتباطات متقابل منجر به
بسیاری از دستورات پیکربندی در برنامه های کاربر. برای سهولت استفاده، برخی از رایج ترین
عملیات را می توان ترکیب کرد و در توابع کمکی محصور کرد. علاوه بر این، برخی از
اظهارات مربوط به ns-3 منابع ردیابی به دلیل محدودیت‌های موجود، اتصال پایتون ندارند
اتصالات

داده ها مجموعه یاران بررسی اجمالی
در این بخش، مروری بر برخی از کلاس‌های کمکی که برای آن ایجاد شده‌اند، ارائه می‌کنیم
پیکربندی چارچوب جمع آوری داده ها را برای برخی موارد استفاده رایج آسان می کند. را
کمک‌کننده‌ها به کاربران اجازه می‌دهند تا عملیات مشترک را تنها با چند عبارت در C++ یا خود شکل دهند
برنامه های پایتون اما، این سهولت استفاده با هزینه بسیار کمتری همراه است
انعطاف پذیری نسبت به پیکربندی سطح پایین و نیاز به کدنویسی صریح
پشتیبانی از انواع جدید Probe در Helperها (برای حل مشکلی که در زیر توضیح داده شده است).

تأکید بر کمک‌کنندگان کنونی این است که داده‌ها را خارج کنند ns-3 ردیابی منابع به
نمودارهای gnuplot یا فایل های متنی، بدون درجه بالایی از سفارشی سازی خروجی یا آماری
پردازش (در ابتدا). همچنین، استفاده به انواع کاوشگر موجود در آن محدود می شود
ns-3. بخش‌های بعدی این مستندات به جزئیات بیشتری در مورد ایجاد موارد جدید می‌پردازد
انواع کاوشگر، و همچنین جزئیات مربوط به قلاب کردن پروب ها، جمع کننده ها و جمع کننده ها
در ترتیبات سفارشی

تا به امروز، دو کمک کننده جمع آوری داده ها پیاده سازی شده است:

· GnuplotHelper

· FileHelper

GnuplotHelper
GnuplotHelper یک کلاس کمکی برای تولید فایل های خروجی است که برای ساخت gnuplot استفاده می شود. در
هدف کلی این است که این توانایی را برای کاربران فراهم کند که به سرعت نمودارهایی را از داده های صادر شده ایجاد کنند
in ns-3 منابع ردیابی به طور پیش فرض، حداقل مقدار تغییر داده انجام می شود.
هدف این است که نمودارهایی با تعداد کمی از دستورات پیکربندی (پیش‌فرض) تولید کنیم
امکان پذیر است.

GnuplotHelper بررسی اجمالی
GnuplotHelper 3 فایل مختلف را در پایان شبیه سازی ایجاد می کند:

· فایل داده gnuplot با فاصله از هم جدا شده است

· یک فایل کنترل gnuplot

· یک پوسته اسکریپت برای تولید gnuplot

دو دستور پیکربندی وجود دارد که برای تولید نمودارها مورد نیاز است. اولین
بیانیه نمودار را پیکربندی می کند (نام فایل، عنوان، افسانه ها و نوع خروجی، جایی که خروجی
پیش فرض را به PNG تایپ کنید اگر مشخص نیست):

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

بیانیه دوم منبع ردیابی علاقه را قلاب می کند:

void PlotProbe (const std::string &typeId,
const std:: رشته و مسیر،
const std::string &probeTraceSource،
const std::string &title);

استدلال ها به شرح زیر است:

· typeId: The ns-3 TypeId پروب

· مسیر: مسیر در ns-3 پیکربندی فضای نام برای یک یا چند منبع ردیابی

· probeTraceSource: کدام خروجی پروب (که خود منبع ردیابی است) باید رسم شود

· عنوان: عنوان مرتبط با مجموعه داده(های) (در افسانه gnuplot)

یک نوع در PlotProbe بالا برای تعیین آرگومان اختیاری پنجم است که کنترل می کند
جایی که در طرح کلید (افسانه) قرار می گیرد.

یک مثال کاملاً کار شده (از سی سی هفتم) در زیر نشان داده شده است:

// کمک کننده gnuplot را ایجاد کنید.
gnuplothelper plothelper ؛

// طرح را پیکربندی کنید.
// طرح را پیکربندی کنید. اولین آرگومان پیشوند نام فایل است
// برای فایل های خروجی تولید شده. دوم و سوم و چهارم
// آرگومان ها به ترتیب عنوان طرح، محور x و محور y هستند.
plotHelper.ConfigurePlot ("seventh-packet-byte-count"،
"تعداد بایت بسته در برابر زمان"،
"زمان (ثانیه)"،
"تعداد بایت بسته"،
"png")؛

// نوع پروب، مسیر منبع ردیابی (در فضای نام پیکربندی) و
// کاوش منبع ردیابی خروجی ("OutputBytes") برای رسم. برهان چهارم
// نام برچسب سری داده را در نمودار مشخص می کند. آخرین
// آرگومان طرح را با تعیین محل قرار دادن کلید قالب بندی می کند.
plotHelper.PlotProbe (probeType,
TracePath،
"OutputBytes"،
"تعداد بایت بسته"،
GnuplotAggregator::KEY_BELOW);

در این مثال ، probeType و tracePath به شرح زیر است (برای IPv4):

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

probeType یک پارامتر کلیدی برای کار این کمک کننده است. این TypeId باید ثبت شود
در سیستم، و امضای روی سینک ردیابی کاوشگر باید با امضای ردیابی مطابقت داشته باشد
منبعی که به آن وصل شده است. انواع پروب برای تعدادی از انواع داده از پیش تعریف شده است
مربوط به ns-3 مقادیر ردیابی شده، و برای چند امضای منبع ردیابی دیگر مانند
منبع ردیابی 'Tx' ns3::پروتکل IPv4L3 کلاس.

توجه داشته باشید که مسیر منبع ردیابی مشخص شده ممکن است دارای حروف عام باشد. در این مورد، متعدد
مجموعه داده ها در یک نمودار رسم می شوند. یکی برای هر مسیر منطبق

خروجی اصلی تولید شده سه فایل خواهد بود:

هفتم بسته-بایت-count.dat
هفتم بسته-بایت-count.plt
هفتم بسته-بایت-count.sh

در این مرحله، کاربران می توانند فایل .plt را برای سفارشی سازی های بیشتر به صورت دستی ویرایش کنند یا
فقط آن را از طریق gnuplot اجرا کنید. در حال دویدن sh هفتم بسته-بایت-count.sh به سادگی طرح را اجرا می کند
از طریق gnuplot، همانطور که در زیر نشان داده شده است.
[تصویر] Gnuplot دوبعدی ایجاد شده توسط sixth.cc مثال..UNINDENT

مشاهده می شود که عناصر کلیدی (افسانه، عنوان، مکان افسانه، xlabel، ylabel،
و مسیر برای داده ها) همگی در نمودار قرار می گیرند. از آنجایی که دو مسابقه به
مسیر پیکربندی ارائه شده، دو سری داده نشان داده شده است:

· Packet Byte Count-0 مربوط به /NodeList/0/$ns3::Ipv4L3Protocol/Tx است

· Packet Byte Count-1 مربوط به /NodeList/1/$ns3::Ipv4L3Protocol/Tx است

GnuplotHelper ConfigurePlot
GnuplotHelper's ConfigurePlot() تابع را می توان برای پیکربندی نمودارها استفاده کرد.

نمونه اولیه زیر را دارد:

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

دارای استدلال های زیر است:

┌¬**************************الم ─────────────────┐
│برهان │ شرح │
├¬**************************الم ─────────────────┤
│outputFileNameWithoutExtension │ نام فایل های مرتبط gnuplot به │
│ │ بدون پسوند بنویسید. │
├¬**************************الم ─────────────────┤
│title │ رشته عنوان را برای استفاده برای │ رسم کنید
│ │ این طرح. │
└¬**************************الم ─────────────────┘

│xLegend │ افسانه برای x افقی │
│ │ محور. │
├¬**************************الم ─────────────────┤
│yLegend │ افسانه برای y عمودی │
│ │ محور. │
├¬**************************الم ─────────────────┤
│terminalType │ رشته تنظیم نوع ترمینال برای │
│ │ خروجی. ترمینال پیش فرض │
نوع │ │ "png" است. │
└¬**************************الم ─────────────────┘

GnuplotHelper's ConfigurePlot() تابع پارامترهای مربوط به نمودار را برای این پیکربندی می کند
کمک کننده gnuplot به طوری که یک فایل داده gnuplot با فاصله از هم به نام ایجاد می کند
outputFileNameWithoutExtension + ".dat"، یک فایل کنترلی gnuplot با نام
outputFileNameWithoutExtension + ".plt" و یک اسکریپت پوسته برای تولید gnuplot با نام
outputFileNameWithoutExtension + ".sh".

نمونه ای از نحوه استفاده از این تابع را می توان در قسمت مشاهده کرد سی سی هفتم کد توضیح داده شده در بالا
جایی که به صورت زیر استفاده شد:

plotHelper.ConfigurePlot ("seventh-packet-byte-count"،
"تعداد بایت بسته در برابر زمان"،
"زمان (ثانیه)"،
"تعداد بایت بسته"،
"png")؛

GnuplotHelper PlotProbe
GnuplotHelper's PlotProbe() تابع را می توان برای رسم مقادیر تولید شده توسط پروب ها استفاده کرد.

نمونه اولیه زیر را دارد:

void PlotProbe (const std::string &typeId,
const std:: رشته و مسیر،
const std::string &probeTraceSource،
const std::string &title,
enum GnuplotAggregator::KeyLocation keyLocation = GnuplotAggregator::KEY_INSIDE);

دارای استدلال های زیر است:

┌──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┐
│برهان │ شرح │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│typeId │ شناسه نوع پروب │
│ │ ایجاد شده توسط این یاور. │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
مسیر │ مسیر پیکربندی برای دسترسی به ردیابی │
│ │ منبع. │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│probeTraceSource │ منبع ردیابی کاوشگر به │
│ │ دسترسی. │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│title │ عنوانی که باید به │ مرتبط شود
│ │ این مجموعه داده │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│keyLocation │ محل کلید در │
│ │ طرح. مکان پیش فرض │ است
│ │ داخل. │
└──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┘

GnuplotHelper's PlotProbe() تابع یک مجموعه داده تولید شده با قلاب کردن را ترسیم می کند ns-3
منبع ردیابی با کاوشگر ایجاد شده توسط کمک کننده، و سپس رسم مقادیر از
probeTraceSource. مجموعه داده دارای عنوان ارائه شده خواهد بود و از
"newValue" در هر مهر زمانی.

اگر مسیر پیکربندی بیش از یک تطبیق در سیستم داشته باشد زیرا یک علامت عام وجود دارد، پس
یک مجموعه داده برای هر تطابق رسم خواهد شد. عناوین مجموعه داده ها با پسوند عبارت خواهند بود
کاراکترهای همسان برای هر یک از حروف عام در مسیر پیکربندی، که با فاصله از هم جدا شده اند. برای
به عنوان مثال، اگر عنوان مجموعه داده پیشنهادی رشته "بایت" باشد، و دو علامت عام وجود دارد
در مسیر، عناوین مجموعه داده مانند "bytes-0 0" یا "bytes-12 9" به عنوان امکان پذیر خواهد بود.
برچسب ها برای مجموعه داده هایی که رسم می شوند.

نمونه ای از نحوه استفاده از این تابع را می توان در قسمت مشاهده کرد سی سی هفتم کد توضیح داده شده در بالا
جایی که از آن (با جایگزینی متغیر) به صورت زیر استفاده شد:

plotHelper.PlotProbe ("ns3::Ipv4PacketProbe"،
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx"،
"OutputBytes"،
"تعداد بایت بسته"،
GnuplotAggregator::KEY_BELOW);

دیگر مثال ها
گنوپلو کمک کننده مثال
مثال کمی ساده تر از سی سی هفتم مثال را می توان در یافت
src/stats/examples/gnuplot-helper-example.cc. gnuplot 2 بعدی زیر با استفاده از آن ایجاد شد
مثال.
[تصویر] Gnuplot دو بعدی ایجاد شده توسط gnuplot-helper-example.cc مثال..UNINDENT

در این مثال، یک شی Emitter وجود دارد که شمارنده خود را مطابق a افزایش می دهد
پواسون را پردازش می کند و سپس مقدار شمارنده را به عنوان منبع ردیابی منتشر می کند.

Ptr Emitter = CreateObject ()
نام ها::افزودن ("/Names/Emitter", emitter);

توجه داشته باشید که از آنجایی که در مسیر استفاده شده در زیر هیچ علامت عام وجود ندارد، تنها 1 جریان داده وجود دارد
در طرح ترسیم شده است. این جریان داده منفرد در نمودار به سادگی با عنوان "Emitter Count" شناخته می شود.
بدون پسوند اضافی مانند one will see if wildcards در مسیر وجود دارد.

// کمک کننده gnuplot را ایجاد کنید.
gnuplothelper plothelper ؛

// طرح را پیکربندی کنید.
plotHelper.ConfigurePlot ("gnuplot-helper-example"،
"تعداد امیتر در مقابل زمان"،
"زمان (ثانیه)"،
"تعداد امیتر"،
"png")؛

// مقادیر تولید شده توسط پروب را رسم کنید. مسیری که ما فراهم می کنیم
// به ابهام‌زدایی از منبع ردیابی کمک می‌کند.
plotHelper.PlotProbe ("ns3::Uinteger32Probe"،
"/Names/Emitter/Counter"
"خروجی"،
"تعداد امیتر"،
GnuplotAggregator::KEY_INSIDE);

FileHelper
FileHelper یک کلاس کمکی است که برای قرار دادن مقادیر داده در یک فایل استفاده می شود. هدف کلی است
این امکان را برای کاربران فراهم می کند تا به سرعت فایل های متنی فرمت شده را از داده های صادر شده بسازند
in ns-3 منابع ردیابی به طور پیش فرض، حداقل مقدار تغییر داده انجام می شود.
هدف این است که فایل‌هایی با همان تعداد (پیش‌فرض) دستورات پیکربندی تولید شود
امکان پذیر است.

FileHelper بررسی اجمالی
FileHelper 1 یا چند فایل متنی را در پایان شبیه سازی ایجاد می کند.

FileHelper می تواند 4 نوع مختلف فایل متنی ایجاد کند:

· فرمت شده

· فاصله جدا شده (پیش فرض)

· جدا شده با ویرگول

· برگه جدا شده است

فایل‌های فرمت‌شده از رشته‌های قالب C و تابع sprintf() برای چاپ آنها استفاده می‌کنند
مقادیر موجود در فایل در حال نوشتن

فایل متنی زیر با 2 ستون از مقادیر قالب بندی شده نامگذاری شده است
هفتم بسته-بایت-count-0.txt با استفاده از کدهای جدید بیشتری که به آن اضافه شده بود ایجاد شد
اصلی ns-3 کد نمونه آموزشی فقط 10 خط اول این فایل نشان داده شده است
اینجا برای اختصار

زمان (ثانیه) = 1.000e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.004e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.004e+00 بسته تعداد بایت = 576
زمان (ثانیه) = 1.009e+00 بسته تعداد بایت = 576
زمان (ثانیه) = 1.009e+00 بسته تعداد بایت = 576
زمان (ثانیه) = 1.015e+00 بسته تعداد بایت = 512
زمان (ثانیه) = 1.017e+00 بسته تعداد بایت = 576
زمان (ثانیه) = 1.017e+00 بسته تعداد بایت = 544
زمان (ثانیه) = 1.025e+00 بسته تعداد بایت = 576
زمان (ثانیه) = 1.025e+00 بسته تعداد بایت = 544

...

فایل متنی مختلف زیر با 2 ستون از مقادیر قالب بندی شده نامگذاری شده است
هفتم بسته-بایت-count-1.txt همچنین با استفاده از همان کد جدیدی که به آن اضافه شد ایجاد شد
اصلی ns-3 کد نمونه آموزشی فقط 10 خط اول این فایل نشان داده شده است
اینجا برای اختصار

زمان (ثانیه) = 1.002e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.007e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.013e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.020e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.028e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.036e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.045e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.053e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.061e+00 بسته تعداد بایت = 40
زمان (ثانیه) = 1.069e+00 بسته تعداد بایت = 40

...

کد جدیدی که برای تولید دو فایل متنی اضافه شده است در زیر آمده است. جزئیات بیشتر در مورد
این API در بخش بعدی پوشش داده خواهد شد.

توجه داشته باشید که به دلیل وجود 2 مطابقت برای علامت عام در مسیر، 2 فایل متنی جداگانه وجود دارد
ایجاد شدند. اولین فایل متنی که "seventh-packet-byte-count-0.txt" نام دارد.
مربوط به تطابق حروف با علامت "*" جایگزین شده با "0" است. فایل متنی دوم،
که "seventh-packet-byte-count-1.txt" نامگذاری شده است، مربوط به تطابق وایلدکارت با
"*" با "1" جایگزین شد. همچنین توجه داشته باشید که تابع به WriteProbe() خواهد داد
اگر مسیری که دارای حروف عام است مطابقت نداشته باشد، پیام خطا می دهد.

// راهنما فایل را ایجاد کنید.
FileHelper fileHelper;

// فایلی را که باید نوشته شود پیکربندی کنید.
fileHelper.ConfigureFile ("seventh-packet-byte-count",
FileAggregator::FORMATTED);

// برچسب ها را برای این فایل خروجی فرمت شده تنظیم کنید.
fileHelper.Set2dFormat ("زمان (ثانیه) = %.3e\tPacket Byte Count = %.0f");

// مقادیر تولید شده توسط پروب را بنویسید.
fileHelper.WriteProbe ("ns3::Ipv4PacketProbe"،
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx"،
"OutputBytes")؛

FileHelper ConfigureFile
FileHelper's ConfigureFile() تابع را می توان برای پیکربندی فایل های متنی استفاده کرد.

نمونه اولیه زیر را دارد:

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

دارای استدلال های زیر است:

┌¬**************************الم ─────────────────┐
│برهان │ شرح │
├¬**************************الم ─────────────────┤
│outputFileNameWithoutExtension │ نام فایل خروجی برای نوشتن │
│ │ بدون تمدید. │
├¬**************************الم ─────────────────┤
│fileType │ نوع فایل برای نوشتن. │
│ │ نوع پیش فرض فایل space │ است
│ │ جدا شد. │
└¬**************************الم ─────────────────┘

FileHelper's ConfigureFile() تابع پارامترهای مربوط به فایل متنی را برای
کمک کننده فایل به طوری که فایلی به نام outputFileNameWithoutExtension plus ایجاد می کند.
اطلاعات اضافی ممکن از موارد منطبق با حروف عام به اضافه "txt." با مقادیر چاپ شده به عنوان
توسط fileType مشخص شده است. نوع فایل پیش‌فرض با فاصله جدا شده است.

نمونه ای از نحوه استفاده از این تابع را می توان در قسمت مشاهده کرد سی سی هفتم کد توضیح داده شده در بالا
جایی که به صورت زیر استفاده شد:

fileHelper.ConfigureFile ("seventh-packet-byte-count",
FileAggregator::FORMATTED);

FileHelper WriteProbe
FileHelper's WriteProbe() تابع می تواند برای نوشتن مقادیر تولید شده توسط پروب ها استفاده شود
فایل های متنی

نمونه اولیه زیر را دارد:

void WriteProbe (const std::string &typeId,
const std:: رشته و مسیر،
const std::string &probeTraceSource);

دارای استدلال های زیر است:

┌──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┐
│برهان │ شرح │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│typeId │ شناسه نوع پروب که │ باشد
│ │ ایجاد شد. │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
مسیر │ مسیر پیکربندی برای دسترسی به ردیابی │
│ │ منبع. │
├──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┤
│probeTraceSource │ منبع ردیابی کاوشگر به │
│ │ دسترسی. │
└──────────────────────────────── ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ───┘

FileHelper's WriteProbe() تابع فایل های متنی خروجی تولید شده با قلاب کردن را ایجاد می کند
منبع ردیابی ns-3 با یک کاوشگر ایجاد شده توسط کمک کننده، و سپس نوشتن مقادیر از
probeTraceSource. نام فایل های خروجی دارای متن ذخیره شده در متغیر عضو خواهد بود
m_outputFileNameWithoutExtension به اضافه "txt." و از "newValue" در هر یک تشکیل می شود
مهر زمانی

اگر مسیر پیکربندی بیش از یک تطبیق در سیستم داشته باشد زیرا یک علامت عام وجود دارد، پس
یک فایل خروجی برای هر مسابقه ایجاد خواهد شد. نام فایل های خروجی شامل
متن در m_outputFileNameWithoutExtension به اضافه کاراکترهای همسان برای هر یک از
حروف عام در مسیر پیکربندی، جدا شده با خط تیره، به اضافه ".txt". به عنوان مثال، اگر مقدار
در m_outputFileNameWithoutExtension رشته "packet-byte-count" است و دو عدد وجود دارد
علامت های عام در مسیر، سپس نام فایل های خروجی مانند "packet-byte-count-0-0.txt" یا
"packet-byte-count-12-9.txt" به عنوان نام فایل هایی که ایجاد خواهند شد امکان پذیر خواهد بود.

نمونه ای از نحوه استفاده از این تابع را می توان در قسمت مشاهده کرد سی سی هفتم کد توضیح داده شده در بالا
جایی که به صورت زیر استفاده شد:

fileHelper.WriteProbe ("ns3::Ipv4PacketProbe"،
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx"،
"OutputBytes")؛

دیگر مثال ها
پرونده کمک کننده مثال
مثال کمی ساده تر از سی سی هفتم مثال را می توان در یافت
src/stats/examples/file-helper-example.cc. این مثال فقط از FileHelper استفاده می کند.

فایل متنی زیر با 2 ستون از مقادیر قالب بندی شده نامگذاری شده است file-helper-example.txt
با استفاده از مثال ایجاد شد. فقط 10 خط اول این فایل در اینجا نشان داده شده است
اختصار.

زمان (ثانیه) = 0.203 تعداد = 1
زمان (ثانیه) = 0.702 تعداد = 2
زمان (ثانیه) = 1.404 تعداد = 3
زمان (ثانیه) = 2.368 تعداد = 4
زمان (ثانیه) = 3.364 تعداد = 5
زمان (ثانیه) = 3.579 تعداد = 6
زمان (ثانیه) = 5.873 تعداد = 7
زمان (ثانیه) = 6.410 تعداد = 8
زمان (ثانیه) = 6.472 تعداد = 9
...

در این مثال، یک شی Emitter وجود دارد که شمارنده خود را مطابق a افزایش می دهد
پواسون را پردازش می کند و سپس مقدار شمارنده را به عنوان منبع ردیابی منتشر می کند.

Ptr Emitter = CreateObject ()
نام ها::افزودن ("/Names/Emitter", emitter);

توجه داشته باشید که به دلیل اینکه در مسیر استفاده شده در زیر هیچ علامت عام وجود ندارد، تنها 1 فایل متنی وجود دارد
ایجاد شده. این فایل متنی به سادگی "file-helper-example.txt" نامیده می شود، بدون هیچ اضافی
پسوندهایی مانند شما می بینید که اگر علامت های عام در مسیر وجود داشته باشد.

// راهنما فایل را ایجاد کنید.
FileHelper fileHelper;

// فایلی را که باید نوشته شود پیکربندی کنید.
fileHelper.ConfigureFile ("file-helper-example"،
FileAggregator::FORMATTED);

// برچسب ها را برای این فایل خروجی فرمت شده تنظیم کنید.
fileHelper.Set2dFormat ("زمان (ثانیه) = %.3e\tCount = %.0f");

// مقادیر تولید شده توسط پروب را بنویسید. مسیری که ما
// ارائه به ابهام‌زدایی از منبع ردیابی کمک می‌کند.
fileHelper.WriteProbe ("ns3::Uinteger32Probe"،
"/Names/Emitter/Counter"
"خروجی")؛

حوزه و محدودیت ها
در حال حاضر فقط این Probes پیاده سازی شده و به GnuplotHelper وصل شده اند
به FileHelper:

· BooleanProbe

· DoubleProbe

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TimeProbe

· PacketProbe

· ApplicationPacketProbe

· Ipv4PacketProbe

بنابراین، این پروب ها تنها TypeId های موجود برای استفاده هستند PlotProbe() و
WriteProbe().

در چند بخش بعدی، هر یک از انواع شیء اساسی (کاوشگر، جمع‌آور،
و Aggregator) با جزئیات بیشتر، و نشان می دهد که چگونه می توان آنها را با استفاده از یکدیگر متصل کرد
API سطح پایین تر

پروب ها
این بخش عملکردهای ارائه شده توسط کلاس Probe را توضیح می دهد ns-3
شبیه سازی، و مثال هایی در مورد نحوه کدنویسی آنها در یک برنامه ارائه می دهد. این بخش برای
کاربران علاقه مند به توسعه شبیه سازی با ns-3 ابزارها و استفاده از داده ها
مجموعه چارچوب، که کلاس Probe بخشی از آن است، برای تولید خروجی داده با آن
نتایج شبیه سازی آنها

کاوشگر بررسی اجمالی
یک شی Probe قرار است به متغیری از شبیه سازی متصل شود که مقادیر آن
در طول آزمایش به کاربر مربوط است. کاوشگر آنچه بود را ضبط خواهد کرد
مقادیری که در طول شبیه سازی توسط متغیر در نظر گرفته شده و چنین داده هایی را به دیگری منتقل می کند
عضو چارچوب جمع آوری داده ها در حالی که خارج از محدوده این بخش به
بحث کنید که پس از تولید خروجی کاوشگر چه اتفاقی می افتد، کافی است بگوییم که توسط
در پایان شبیه سازی، کاربر اطلاعات دقیقی در مورد مقادیری خواهد داشت
درون متغیری که در حین شبیه سازی کاوش می شود ذخیره می شود.

به طور معمول، یک Probe به یک متصل است ns-3 منبع ردیابی به این ترتیب، هر زمان که
منبع ردیابی یک مقدار جدید صادر می کند، Probe ارزش را مصرف می کند (و آن را به پایین دست صادر می کند
به یک شی دیگر از طریق منبع ردیابی خود).

کاوشگر را می توان به عنوان نوعی فیلتر بر روی منابع ردیابی در نظر گرفت. دلایل اصلی برای
اتصال احتمالی به کاوشگر به جای مستقیم به منبع ردیابی به شرح زیر است:

· پروب ها ممکن است به صورت پویا در طول شبیه سازی با تماس به روشن و خاموش شوند فعال کردن()
و غیر فعال کردن(). به عنوان مثال، خروجی داده ها ممکن است در طول مدت خاموش شود
فاز گرم کردن شبیه سازی

کاوشگرها ممکن است عملیاتی را روی داده ها انجام دهند تا مقادیر پیچیده تر را استخراج کنند
سازه های؛ به عنوان مثال، خروجی مقدار اندازه بسته از یک بسته دریافتی ns3::.

پروب ها یک نام را در فضای نام ns3::Config ثبت می کنند (با استفاده از نام ها::افزودن ()) به طوری که دیگر
اشیاء ممکن است به آنها اشاره کنند.

· کاوشگرها یک روش ثابت را ارائه می دهند که به شخص اجازه می دهد یک پروب را با نام دستکاری کند، مانند
آنچه در ns2measure انجام می شود [Cic06]

Stat::put ("my_metric"، ID، نمونه)؛

معادل ns-3 کد ns2measure فوق، به عنوان مثال است

DoubleProbe::SetValueByPath ("/path/to/probe"، نمونه);

ایجاد
توجه داشته باشید که یک شی کلاس پایه Probe نمی تواند ایجاد شود زیرا یک پایه انتزاعی است
class، یعنی توابع مجازی خالص دارد که پیاده سازی نشده اند. یک شی از
نوع DoubleProbe، که زیر کلاس کلاس Probe است، در اینجا ایجاد می شود تا نشان داده شود
چه باید انجام شود.

یک DoubleProbe در حافظه پویا با استفاده از کلاس اشاره گر هوشمند (Ptr ). به
یک DoubleProbe در حافظه پویا با اشاره گرهای هوشمند ایجاد کنید، فقط باید آن را فراخوانی کنید
ns-3 روش CreateObject():

Ptr myprobe = CreateObject ()

اعلان بالا DoubleProbes را با استفاده از مقادیر پیش‌فرض برای ویژگی‌های خود ایجاد می‌کند.
چهار ویژگی در کلاس DoubleProbe وجود دارد. دو در شی کلاس پایه
DataCollectionObject و دو در کلاس پایه Probe:

· "Name" (DataCollectionObject)، یک StringValue

· "Enabled" (DataCollectionObject)، یک مقدار Boolean

· "شروع" (پروب)، یک مقدار زمانی

· "توقف" (پروب)، یک مقدار زمانی

با استفاده از روش زیر می توان چنین ویژگی هایی را در ایجاد شیء تنظیم کرد:

Ptr myprobe = CreateObjectWithAttributes (
"Name"، StringValue ("myprobe")،
"فعال"، BooleanValue (نادرست)،
"شروع"، TimeValue (ثانیه (100.0))،
"Stop"، TimeValue (ثانیه (1000.0)))؛

شروع و توقف متغیرهای زمانی هستند که فاصله عمل پروب را تعیین می کنند. در
کاوشگر تنها در صورتی داده خروجی خواهد داد که زمان فعلی شبیه سازی در داخل آن باشد
فاصله مقدار زمانی ویژه 0 ثانیه برای Stop این ویژگی را غیرفعال می کند (یعنی
Probe را برای کل شبیه سازی روشن نگه دارید). فعال پرچمی است که Probe را روشن یا روشن می کند
خاموش است و باید روی true تنظیم شود تا Probe بتواند داده ها را صادر کند. Name نام شیء است
در چارچوب DCF

واردات و صادرات داده ها
ns-3 منابع ردیابی به شدت تایپ می شوند، بنابراین مکانیسم های قلاب کردن پروب ها به یک ردیابی است
منبع و برای صادر کردن داده ها به زیر کلاس های آن تعلق دارد. به عنوان مثال، پیش فرض
توزیع ns-3 یک کلاس DoubleProbe را ارائه می دهد که برای قلاب کردن یک ردیابی طراحی شده است
منبع صادر کننده یک مقدار دو برابر است. در ادامه جزئیات عملکرد DoubleProbe و
سپس در مورد چگونگی تعریف سایر کلاس های Probe توسط کاربر بحث کنید.

DoubleProbe بررسی اجمالی
DoubleProbe به یک با ارزش دوگانه متصل می شود ns-3 منبع ردیابی، و خود صادرات الف
متفاوت با ارزش دوگانه ns-3 منبع ردیابی

کد زیر برگرفته از src/stats/examples/double-probe-example.cc، پایه را نشان می دهد
عملیات لوله کشی DoubleProbe در یک شبیه سازی، جایی که در حال کاوش یک شمارنده است
صادر شده توسط یک شی امیتر (کلاس Emitter).

Ptr Emitter = CreateObject ()
نام ها::افزودن ("/Names/Emitter", emitter);
...

Ptr probe1 = CreateObject ()

// پروب را به شمارنده امیتر وصل کنید
bool connect = probe1->ConnectByObject ("Counter"، emitter);

کد زیر همان شمارنده صادر شده توسط همان شی امیتر را بررسی می کند. این
با این حال، DoubleProbe از یک مسیر در فضای نام پیکربندی برای ایجاد آن استفاده می کند
ارتباط. توجه داشته باشید که امیتر خود را در فضای نام پیکربندی بعد از آن ثبت کرده است
بوجود آمد؛ در غیر این صورت، ConnectByPath کار نخواهد کرد.

Ptr probe2 = CreateObject ()

// توجه داشته باشید، هیچ مقدار بازگشتی در اینجا بررسی نمی شود
probe2->ConnectByPath ("/Names/Emitter/Counter");

DoubleProbe بعدی که در زیر نشان داده شده است، مقدار آن را با استفاده از مسیر خود تنظیم می کند
فضای نام پیکربندی توجه داشته باشید که این بار DoubleProbe خود را در
فضای نام پیکربندی پس از ایجاد آن.

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

// باید آن را به پایگاه داده پیکربندی اضافه کنیم
نام ها::افزودن ("/Names/Probes", probe3->GetName ()، probe3);

تابع Count() امیتر اکنون می تواند مقدار این DoubleProbe را به عنوان تنظیم کند
به شرح زیر است:

از درجه اعتبار ساقط
Emitter::Count (باطل)
{
...
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe"، m_counter);
...
}

مثال بالا نشان می‌دهد که چگونه کدی که Probe را فراخوانی می‌کند نیازی به صریح بودن ندارد
به Probe اشاره می کند، اما می تواند تنظیم مقدار را از طریق فضای نام Config هدایت کند.
این از نظر عملکرد مشابه است آمار::قرار دهید روش معرفی شده توسط کاغذ ns2measure
[Cic06]، و به کاربران اجازه می دهد تا به طور موقت عباراتی مانند Probe را وارد کنند printf اظهارات
در داخل موجود ns-3 مدل ها. توجه داشته باشید که برای اینکه بتوانید از DoubleProbe در این مورد استفاده کنید
به عنوان مثال، 2 چیز لازم بود:

1. فایل هدر ماژول آمار در فایل مثال .cc گنجانده شده است

2. مثال به ماژول آمار در فایل wscript آن وابسته است.

کارهای مشابهی باید انجام شود تا پروب های دیگر در جاهای دیگر اضافه شود ns-3
پایه کد

مقادیر DoubleProbe را نیز می توان با استفاده از تابع DoubleProbe::SetValue() تنظیم کرد.
در حالی که مقادیر DoubleProbe را می توان با استفاده از تابع بدست آورد
DoubleProbe::GetValue().

DoubleProbe مقادیر دو برابری را در منبع ردیابی "Output" خود صادر می کند. یک شی پایین دست
می تواند یک ردیابی سینک (NotifyViaProbe) را به صورت زیر به آن قلاب کند:

متصل = probe1->TraceConnect ("خروجی"، probe1->GetName ()، MakeCallback (&NotifyViaProbe));

دیگر کاوشگرها
علاوه بر DoubleProbe، پروب های زیر نیز موجود است:

· Uinteger8Probe به یک متصل می شود ns-3 منبع ردیابی صادر کننده uint8_t.

· Uinteger16Probe به یک متصل می شود ns-3 منبع ردیابی صادر کننده uint16_t.

· Uinteger32Probe به یک متصل می شود ns-3 منبع ردیابی صادر کننده uint32_t.

· PacketProbe به یک متصل می شود ns-3 منبع ردیابی صادر کننده یک بسته

· ApplicationPacketProbe به یک متصل می شود ns-3 منبع ردیابی صادر کننده یک بسته و یک سوکت
نشانی.

· Ipv4PacketProbe به یک متصل می شود ns-3 منبع ردیابی صادر کننده یک بسته، یک شی IPv4 و
یک رابط

ایجاد جدید کاوشگر انواع
برای ایجاد یک نوع Probe جدید، باید مراحل زیر را انجام دهید:

· مطمئن شوید که کلاس Probe جدید شما از کلاس پایه Probe مشتق شده است.

· مطمئن شوید که توابع مجازی خالصی که کلاس Probe جدید شما از آن به ارث می برد
کلاس پایه پروب پیاده سازی شده است.

· یک کلاس Probe موجود را پیدا کنید که از یک منبع ردیابی استفاده می کند که از نظر نوع نزدیک به آن است
نوع منبع ردیابی که کاوشگر شما از آن استفاده خواهد کرد.

فایل هدر (.h) و فایل پیاده سازی (.cc) کلاس Probe موجود را در دو کپی کنید
فایل های جدید با نام های مطابق با Probe جدید شما.

· انواع، آرگومان ها و متغیرهای موجود در فایل های کپی شده را با موارد مناسب جایگزین کنید
برای پروب خود تایپ کنید

· اصلاحات لازم را انجام دهید تا کد کامپایل شود و آنطور که می خواهید رفتار کند
مانند.

مثال ها
در اینجا دو مثال به تفصیل مورد بحث قرار خواهد گرفت:

· نمونه دو پروب

· نمونه طرح بسته IPv4

دوبار کاوشگر مثال
مثال کاوشگر دوگانه قبلاً مورد بحث قرار گرفته است. برنامه نمونه را می توان یافت
in src/stats/examples/double-probe-example.cc. برای خلاصه کردن آنچه در این برنامه رخ می دهد،
یک قطره چکان وجود دارد که شمارنده ای را صادر می کند که طبق فرآیند پواسون افزایش می یابد.
به طور خاص، دو روش برای انتشار داده نشان داده شده است:

1. از طریق یک متغیر ردیابی شده که به یک Probe متصل است:

TracedValue m_counter; // معمولاً این نوع عدد صحیح است

2. از طریق یک شمارنده که مقدار آن به یک Probe دوم که با نام آن در ارجاع داده می شود، ارسال می شود
سیستم پیکربندی:

از درجه اعتبار ساقط
Emitter::Count (باطل)
{
NS_LOG_FUNCTION (این)؛
NS_LOG_DEBUG ("شمارش در " << شبیه ساز::اکنون ().GetSeconds ());
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe"، m_counter);
Simulator::Schedule (Seconds (m_var->GetValue ())، &Emitter::Count, this);
}

بیایید با دقت بیشتری به Probe نگاه کنیم. پروب ها می توانند مقادیر خود را به صورت چندگانه دریافت کنند
راه ها:

1. توسط Probe که مستقیماً به منبع ردیابی دسترسی پیدا می کند و یک سینک ردیابی را به آن متصل می کند

2. توسط Probe دسترسی به منبع ردیابی از طریق فضای نام پیکربندی و اتصال a
ردیابی به آن

3. توسط کد فراخوانی که صریحاً Probe را فراخوانی می کند SetValue() روش

4. توسط کد فراخوان به صراحت تماس می گیرد SetValueByPath
("/path/through/Config/namespace"، ...)

انتظار می رود دو تکنیک اول رایج ترین باشند. همچنین در مثال،
قلاب کردن یک تابع برگشت به تماس معمولی نشان داده شده است، همانطور که معمولا در انجام می شود ns-3. این
تابع callback با یک شی Probe مرتبط نیست. در زیر این مورد را 0) می نامیم.

// این تابعی برای آزمایش اتصال یک تابع خام به منبع ردیابی است
از درجه اعتبار ساقط
NotifyViaTraceSource (std:: زمینه رشته، double oldVal، double newVal)
{
NS_LOG_DEBUG ("context: " << context << " قدیمی " << oldVal << " new " << newVal);
}

ابتدا، امیتر باید راه اندازی شود:

Ptr Emitter = CreateObject ()
نام ها::افزودن ("/Names/Emitter", emitter);

// شی Emitter با گره ns-3 مرتبط نیست، بنابراین
// به طور خودکار شروع نمی شود، بنابراین باید خودمان این کار را انجام دهیم
شبیه ساز::زمان بندی (ثانیه (0.0)، و فرستنده::شروع، امیتر)؛

در مثال زیر، DoubleProbes های مختلف با امیتر تعامل دارند.

مورد 0):

// در زیر عملکرد معمولی بدون پروب نشان داده شده است
// (یک تابع سینک را به یک منبع ردیابی متصل کنید)
//
متصل = emitter->TraceConnect ("Counter"، "Sample context"، MakeCallback (&NotifyViaTraceSource));
NS_ASSERT_MSG (متصل، "منبع ردیابی متصل نیست")؛

مورد 1):

//
// Probe1 مستقیماً به شی منبع ردیابی Emitter متصل می شود
//

// probe1 به منبع ردیابی Emitter متصل می شود
Ptr probe1 = CreateObject ()
// نام کاوشگر می تواند به عنوان زمینه آن در ردیابی باشد
probe1->SetName ("ObjectProbe");

// پروب را به شمارنده امیتر وصل کنید
connect = probe1->ConnectByObject ("Counter"، Emitter);
NS_ASSERT_MSG (متصل، "منبع ردیابی به probe1 متصل نیست")؛

مورد 2):

//
// Probe2 به شی منبع ردیابی Emitter متصل می شود
// دسترسی به آن با نام مسیر در پایگاه داده پیکربندی
//

// یک پروب مشابه دیگر ایجاد کنید. این از طریق یک مسیر Config متصل می شود
Ptr probe2 = CreateObject ()
probe2->SetName ("PathProbe");

// توجه داشته باشید، هیچ مقدار بازگشتی در اینجا بررسی نمی شود
probe2->ConnectByPath ("/Names/Emitter/Counter");

مورد 4) (مورد 3 در این مثال نشان داده نشده است):

//
// Probe3 توسط امیتر مستقیماً از طریق فراخوانی می شود
// متد استاتیک SetValueByPath().
//
Ptr probe3 = CreateObject ()
probe3->SetName ("StaticallyAccessedProbe");
// باید آن را به پایگاه داده پیکربندی اضافه کنیم
نام ها::افزودن ("/Names/Probes", probe3->GetName ()، probe3);

و در نهایت، مثال نشان می دهد که چگونه می توان پروب ها را برای تولید خروجی قلاب کرد:

// خود پروب باید خروجی تولید کند. زمینه ای که ما ارائه می کنیم
// به این کاوشگر (در این مورد، نام پروب) به رفع ابهام کمک خواهد کرد
// منبع ردیابی
متصل = probe3->TraceConnect ("خروجی"،
"/Names/Probes/StaticallyAccessedProbe/Output"،
MakeCallback (&NotifyViaProbe))؛
NS_ASSERT_MSG (متصل شد، "منبع ردیابی .. متصل به خروجی probe3 نیست");

پاسخ تماس زیر در این مثال برای اهداف توضیحی به Probe متصل شده است.
به طور معمول، کاوشگر به یک شی جمع کننده متصل می شود.

// این تابعی برای آزمایش اتصال آن به خروجی پروب است
از درجه اعتبار ساقط
NotifyViaProbe (std:: زمینه رشته، double oldVal، double newVal)
{
NS_LOG_DEBUG ("context: " << context << " قدیمی " << oldVal << " new " << newVal);
}

IPv4 بسته طرح مثال
نمونه طرح بسته IPv4 بر اساس مثال fifth.cc از ns-3 آموزش. آی تی
را می توان در یافت src/stats/examples/ipv4-packet-plot-example.cc.

گره 0 گره 1
+----------------+ +----------------+
| ns-3 TCP | | ns-3 TCP |
+----------------+ +----------------+
| 10.1.1.1 | | 10.1.1.2 |
+----------------+ +----------------+
| نقطه به نقطه | | نقطه به نقطه |
+----------------+ +----------------+
| |
+----------------------+

ما فقط به Probe نگاه می کنیم، زیرا نشان می دهد که Probes ممکن است مقادیر را نیز از بسته بندی باز کند
ساختارها (در این مورد، بسته ها) و آن مقادیر را به عنوان خروجی منبع ردیابی گزارش می دهند
نه صرفاً از طریق همان نوع داده عبور کنید.

جنبه های دیگری از این مثال وجود دارد که در ادامه در مستندات توضیح داده خواهد شد.
دو نوع داده ای که صادر می شود خود بسته است (تولید) و تعدادی از
تعداد بایت های بسته (خروجی بایت).

TypeId
Ipv4PacketProbe::GetTypeId ()
{
static TypeId tid = TypeId ("ns3::Ipv4PacketProbe")
SetParent ()
.AddConstructor ()
.AddTraceSource ( "خروجی"،
"بسته به علاوه شی IPv4 و رابط آن که به عنوان خروجی برای این کاوشگر عمل می کند"
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_output))
.AddTraceSource ( "OutputBytes"،
"تعداد بایت های بسته"،
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_outputBytes))
;
برگرد
}

هنگامی که سینک ردیابی کاوشگر یک بسته دریافت می کند، اگر Probe فعال باشد، خروجی خواهد داشت.
بسته روی آن تولید منبع ردیابی است، اما تعداد بایت های موجود در آن را نیز خروجی می دهد
خروجی بایت منبع ردیابی

از درجه اعتبار ساقط
Ipv4PacketProbe::TraceSink (Ptr بسته، Ptr رابط ipv4، uint4_t)
{
NS_LOG_FUNCTION (این << بسته << واسط ipv4 <<);
اگر (Enabled ())
{
m_packet = بسته;
m_ipv4 = ipv4;
m_interface = رابط;
m_output (بسته، ipv4، رابط)؛

uint32_t packetSizeNew = packet->GetSize ();
m_outputBytes (m_packetSizeOld، packetSizeNew)؛
m_packetSizeOld = packetSizeNew;
}
}

منابع
[Cic06]
Claudio Cicconetti، Enzo Mingozzi، Giovanni Stea، "یک چارچوب یکپارچه برای
فعال کردن جمع‌آوری مؤثر داده‌ها و تجزیه و تحلیل آماری با ns2، Workshop on
ns-2 (WNS2)، پیزا، ایتالیا، اکتبر 2006.

جمع کننده ها
این بخش یک مکان نگهدار برای جزئیات عملکردهای ارائه شده توسط مجموعه است
کلاس به یک ns-3 شبیه سازی، و مثال هایی در مورد نحوه کدنویسی آنها در یک برنامه ارائه می دهد.

توجه داشته باشید: از ns-3.18، کلکتورها هنوز در حال توسعه هستند و هنوز به عنوان بخشی ارائه نشده اند
از چارچوب

جمع کننده ها
این بخش به جزئیات عملکردهای ارائه شده توسط کلاس Aggregator به یک اشاره می کند ns-3
شبیه سازی. این بخش برای کاربران علاقه مند به توسعه شبیه سازی با
ns-3 ابزارها و با استفاده از Data Collection Framework که کلاس Aggregator a است
بخش، برای تولید خروجی داده با نتایج شبیه سازی خود.

جمع کننده بررسی اجمالی
یک شی Aggregator قرار است به یک یا چند منبع ردیابی متصل شود تا بتواند
دریافت ورودی تجمیع کننده ها نقطه پایانی داده های جمع آوری شده توسط شبکه هستند
پروب ها و جمع کننده ها در طول شبیه سازی. این وظیفه جمع کننده است که اینها را بگیرد
مقادیر و تبدیل آنها به فرمت خروجی نهایی خود مانند فایل های متنی ساده،
فایل های صفحه گسترده، نمودارها یا پایگاه های داده.

به طور معمول، یک جمع کننده به یک یا چند کلکتور متصل است. به این ترتیب هر زمان که
منابع ردیابی کلکتورها مقادیر جدیدی را صادر می کنند، Aggregator می تواند ارزش را پردازش کند
که می توان از آن در فرمت خروجی نهایی استفاده کرد که در آن مقادیر داده ها بعد از آن قرار می گیرند
شبیه سازی.

در مورد Aggregators به ​​نکات زیر توجه کنید:

· ممکن است در طول شبیه سازی با فراخوانی، جمع آوری کننده ها به صورت پویا روشن و خاموش شوند
فعال کردن() و غیر فعال کردن(). به عنوان مثال، جمع آوری داده ها ممکن است در طول مدت خاموش شود
مرحله گرم کردن شبیه سازی، به این معنی که این مقادیر در نهایی گنجانده نمی شوند
رسانه خروجی

· تجمیع کننده ها داده ها را از گردآورنده ها از طریق callback دریافت می کنند. هنگامی که یک کلکتور مرتبط است
برای جمع‌آوری، تماسی با TraceConnect برقرار می‌شود تا ردیابی Aggregator را ایجاد کند.
روش سینک به عنوان یک تماس.

تا به امروز، دو Aggregator پیاده سازی شده است:

· GnuplotAggregator

· FileAggregator

GnuplotAggregator
GnuplotAggregator فایل های خروجی مورد استفاده برای ساخت gnuplot را تولید می کند.

GnuplotAggregator 3 فایل مختلف را در پایان شبیه سازی ایجاد می کند:

· فایل داده gnuplot با فاصله از هم جدا شده است

· یک فایل کنترل gnuplot

· یک پوسته اسکریپت برای تولید gnuplot

ایجاد
یک شی از نوع GnuplotAggregator در اینجا ایجاد می شود تا نشان دهد چه کاری باید انجام شود.

یک GnuplotAggregator در حافظه پویا با استفاده از کلاس اشاره گر هوشمند اعلام می کند
(Ptr ). برای ایجاد یک GnuplotAggregator در حافظه پویا با اشاره گرهای هوشمند، کافی است
نیاز به تماس دارد ns-3 روش CreateObject(). کد زیر از
src/stats/examples/gnuplot-aggregator-example.cc نحوه انجام این کار را نشان می دهد:

string fileNameWithoutExtension = "gnuplot-aggregator";

// یک جمع کننده ایجاد کنید.
Ptr جمع کننده =
CreateObject (fileNameWithoutExtension)؛

اولین آرگومان سازنده، fileNameWithoutExtension، نام آن است
فایل های مرتبط gnuplot برای نوشتن بدون پسوند. این GnuplotAggregator یک را ایجاد می کند
فایل داده gnuplot جدا شده با فاصله با نام "gnuplot-aggregator.dat"، یک فایل کنترل gnuplot
با نام "gnuplot-aggregator.plt" و یک اسکریپت پوسته برای تولید gnuplot با نام +
"gnuplot-aggregator.sh".

gnuplot ایجاد شده می تواند کلید خود را در 4 مکان مختلف داشته باشد:

· بدون کلید

· کلید داخل طرح (پیش فرض)

· کلید بالای طرح

· کلید زیر طرح

مقادیر enum مکان کلید gnuplot زیر برای تعیین موقعیت کلید مجاز هستند:

enum مکان کلید {
NO_KEY،
KEY_INSIDE،
KEY_ABOVE،
KEY_BELOW
};

اگر می خواستید به جای موقعیت پیش فرض داخل، کلید زیر را داشته باشید، پس
می توانید موارد زیر را انجام دهید

aggregator->SetKeyLocation(GnuplotAggregator::KEY_BELOW);

مثال ها
یک مثال در اینجا به تفصیل مورد بحث قرار خواهد گرفت:

· نمونه Gnuplot Aggregator

گنوپلو جمع کننده مثال
نمونه ای که GnuplotAggregator را تمرین می کند را می توان در آن یافت
src/stats/examples/gnuplot-aggregator-example.cc.

gnuplot 2 بعدی زیر با استفاده از مثال ایجاد شد.
[تصویر] Gnuplot دو بعدی ایجاد شده توسط gnuplot-aggregator-example.cc مثال..UNINDENT

این کد از مثال نحوه ساخت GnuplotAggregator را همانطور که در مورد آن بحث شد نشان می دهد
در بالا.

void Create2dPlot ()
{
استفاده از namespace std؛

string fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "نقشه جمع کننده Gnuplot";
string plotXAxisHeading = "زمان (ثانیه)";
string plotYAxisHeading = "مقدارهای دوگانه";
string plotDatasetLabel = "مقادیر داده";
string databaseContext = "مجموعه داده/مطابق/رشته";

// یک جمع کننده ایجاد کنید.
Ptr جمع کننده =
CreateObject (fileNameWithoutExtension)؛

ویژگی های مختلف GnuplotAggregator از جمله مجموعه داده 2 بعدی که خواهد بود تنظیم شده است
ترسیم شده است.

// ویژگی های جمع کننده را تنظیم کنید.
aggregator->SetTerminal ("png");
aggregator->SetTitle (plotTitle);
aggregator->SetLegend (plotXAxisHeading، plotYAxisHeading)؛

// یک مجموعه داده به جمع کننده اضافه کنید.
aggregator->Add2dDataset (datasetContext، plotDatasetLabel);

// aggregator باید روشن باشد
aggregator->Enable ();

در مرحله بعد، مقادیر 2-D محاسبه می شوند و هر یک به صورت جداگانه در آن نوشته می شود
GnuplotAggregator با استفاده از Write2d() تابع.

زمان دو برابر؛
ارزش دو برابر؛

// مجموعه داده دو بعدی را ایجاد کنید.
برای (زمان = -5.0؛ زمان <= +5.0؛ زمان += 1.0)
{
// منحنی دو بعدی را محاسبه کنید
//
// 2
// ارزش = زمان .
//
ارزش = زمان * زمان;

// این نقطه را به طرح اضافه کنید.
aggregator->Write2d (datasetContext، زمان، مقدار).
}

// غیرفعال کردن گزارش گیری داده ها برای جمع کننده.
aggregator->Disable ();
}

FileAggregator
FileAggregator مقادیر دریافتی خود را به یک فایل ارسال می کند.

FileAggregator می تواند 4 نوع مختلف فایل ایجاد کند:

· فرمت شده

· فاصله جدا شده (پیش فرض)

· جدا شده با ویرگول

· برگه جدا شده است

فایل‌های فرمت‌شده از رشته‌های قالب C و تابع sprintf() برای چاپ آنها استفاده می‌کنند
مقادیر موجود در فایل در حال نوشتن

ایجاد
یک شی از نوع FileAggregator در اینجا ایجاد می شود تا نشان دهد چه کاری باید انجام شود.

یک FileAggregator در حافظه پویا با استفاده از کلاس اشاره گر هوشمند (Ptr ).
برای ایجاد یک FileAggregator در حافظه پویا با اشاره گرهای هوشمند، فقط باید تماس بگیرید
la ns-3 روش CreateObject. کد زیر از
src/stats/نمونه ها/پرونده-همگرایی-مثال.CC نحوه انجام این کار را نشان می دهد:

string fileName = "file-aggregator-formatted-values.txt";

// یک جمع کننده ایجاد کنید که دارای مقادیر فرمت شده باشد.
Ptr جمع کننده =
CreateObject (نام فایل، FileAggregator::FORMATTED);

اولین آرگومان سازنده، نام فایل، نام فایلی است که باید بنویسد. را
آرگومان دوم، fileType، نوع فایلی برای نوشتن است. این FileAggregator یک را ایجاد می کند
فایلی با نام "file-aggregator-formatted-values.txt" و مقادیر آن همانطور که توسط
fileType، یعنی فرمت شده در این مورد.

مقادیر enum نوع فایل زیر مجاز است:

enum نوع فایل {
فرمت شده،
SPACE_SEPARATED،
جدا شده با ویرگول،
TAB_SEPARATED
};

مثال ها
یک مثال در اینجا به تفصیل مورد بحث قرار خواهد گرفت:

· مثال جمع آوری فایل

پرونده جمع کننده مثال
نمونه ای که FileAggregator را تمرین می کند را می توان در آن یافت
src/stats/نمونه ها/پرونده-همگرایی-مثال.CC.

فایل متنی زیر با 2 ستون از مقادیر جدا شده با کاما با استفاده از
مثال.

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

این کد از مثال نحوه ساخت FileAggregator را همانطور که در مورد آن بحث شد نشان می دهد
در بالا.

void CreateCommaSeparatedFile ()
{
استفاده از namespace std؛

string fileName = "file-aggregator-comma-separated.txt";
string databaseContext = "مجموعه داده/مطابق/رشته";

// یک جمع کننده ایجاد کنید.
Ptr جمع کننده =
CreateObject (نام فایل، FileAggregator::COMMA_SEPARATED);

ویژگی های FileAggregator تنظیم شده است.

// aggregator باید روشن باشد
aggregator->Enable ();

در مرحله بعد، مقادیر 2-D محاسبه می شوند و هر یک به صورت جداگانه در آن نوشته می شود
FileAggregator با استفاده از Write2d() تابع.

زمان دو برابر؛
ارزش دو برابر؛

// مجموعه داده دو بعدی را ایجاد کنید.
برای (زمان = -5.0؛ زمان <= +5.0؛ زمان += 1.0)
{
// منحنی دو بعدی را محاسبه کنید
//
// 2
// ارزش = زمان .
//
ارزش = زمان * زمان;

// این نقطه را به طرح اضافه کنید.
aggregator->Write2d (datasetContext، زمان، مقدار).
}

// غیرفعال کردن گزارش گیری داده ها برای جمع کننده.
aggregator->Disable ();
}

فایل متنی زیر با 2 ستون مقادیر فرمت شده نیز با استفاده از
مثال.

زمان = -5.000e+00 مقدار = 25
زمان = -4.000e+00 مقدار = 16
زمان = -3.000e+00 مقدار = 9
زمان = -2.000e+00 مقدار = 4
زمان = -1.000e+00 مقدار = 1
زمان = 0.000e+00 مقدار = 0
زمان = 1.000e+00 مقدار = 1
زمان = 2.000e+00 مقدار = 4
زمان = 3.000e+00 مقدار = 9
زمان = 4.000e+00 مقدار = 16
زمان = 5.000e+00 مقدار = 25

این کد از مثال نحوه ساخت FileAggregator را همانطور که در مورد آن بحث شد نشان می دهد
در بالا.

void CreateFormattedFile ()
{
استفاده از namespace std؛

string fileName = "file-aggregator-formatted-values.txt";
string databaseContext = "مجموعه داده/مطابق/رشته";

// یک جمع کننده ایجاد کنید که دارای مقادیر فرمت شده باشد.
Ptr جمع کننده =
CreateObject (نام فایل، FileAggregator::FORMATTED);

ویژگی های FileAggregator، از جمله رشته فرمت C-style برای استفاده، تنظیم شده است.

// قالب را برای مقادیر تنظیم کنید.
aggregator->Set2dFormat ("Time = %.3e\tValue = %.0f");

// aggregator باید روشن باشد
aggregator->Enable ();

در مرحله بعد، مقادیر 2-D محاسبه می شوند و هر یک به صورت جداگانه در آن نوشته می شود
FileAggregator با استفاده از Write2d() تابع.

زمان دو برابر؛
ارزش دو برابر؛

// مجموعه داده دو بعدی را ایجاد کنید.
برای (زمان = -5.0؛ زمان <= +5.0؛ زمان += 1.0)
{
// منحنی دو بعدی را محاسبه کنید
//
// 2
// ارزش = زمان .
//
ارزش = زمان * زمان;

// این نقطه را به طرح اضافه کنید.
aggregator->Write2d (datasetContext، زمان، مقدار).
}

// غیرفعال کردن گزارش گیری داده ها برای جمع کننده.
aggregator->Disable ();
}

آداپتورها
این بخش به جزئیات عملکردهای ارائه شده توسط کلاس Adapter به an ns-3
شبیه سازی. این بخش برای کاربران علاقه مند به توسعه شبیه سازی با
ns-3 ابزارها و با استفاده از Data Collection Framework که کلاس Adapter بخشی از آن است،
برای تولید خروجی داده با نتایج شبیه سازی خود.

توجه: عبارت "آداپتور" ممکن است "آداپتور" نیز نوشته شود. ما املای تراز را انتخاب کردیم
با استاندارد C++

آداپتور بررسی اجمالی
یک آداپتور برای ایجاد ارتباط بین انواع مختلف اشیاء DCF استفاده می شود.

تا به امروز، یک آداپتور پیاده سازی شده است:

· TimeSeriesAdaptor

زمان سلسله آداپتور
TimeSeriesAdaptor به Probes اجازه می دهد تا بدون نیاز به هیچ کدام مستقیماً به Aggregator متصل شوند
کلکسیونر در بین

هر دو کمک کننده DCF پیاده سازی شده از TimeSeriesAdaptors برای بررسی استفاده می کنند.
مقادیر انواع مختلف و خروجی زمان فعلی به اضافه مقدار با هر دو تبدیل شده است
دو برابر شدن

نقش کلاس TimeSeriesAdaptor نقش یک آداپتور است که ارزش خام را دریافت می کند.
داده‌های کاوشگر از انواع مختلف و خروجی دو مقدار دو برابری را ارائه می‌دهد. اولی الف است
مهر زمانی، که ممکن است روی وضوح های مختلف (مثلاً ثانیه، میلی ثانیه و غیره) تنظیم شود
آینده اما در حال حاضر به ثانیه هاردکد شده است. دوم تبدیل الف است
مقدار غیر دو برابر به یک مقدار دو برابر (احتمالا با از دست دادن دقت).

محدوده/محدودیت ها
این بخش دامنه و محدودیت های چارچوب جمع آوری داده ها را مورد بحث قرار می دهد.

در حال حاضر، فقط این پروب ها در DCF پیاده سازی شده اند:

· BooleanProbe

· DoubleProbe

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TimeProbe

· PacketProbe

· ApplicationPacketProbe

· Ipv4PacketProbe

در حال حاضر، هیچ مجموعه‌ای در DCF موجود نیست، اگرچه BasicStatsCollector زیر است.
توسعه است.

در حال حاضر، فقط این Aggregatorها در DCF پیاده سازی شده اند:

· GnuplotAggregator

· FileAggregator

در حال حاضر فقط این آداپتور در DCF پیاده سازی شده است:

آداپتور سری زمانی

آینده مهاجرت کاری
این بخش در مورد کارهای آتی که باید روی چارچوب جمع آوری داده ها انجام شود بحث می کند.

در اینجا مواردی وجود دارد که هنوز باید انجام شوند:

· منابع ردیابی بیشتری را به آن متصل کنید ns-3 کد برای دریافت مقادیر بیشتر از شبیه ساز.

· انواع بیشتری از پروب ها را نسبت به آنچه در حال حاضر وجود دارد، اجرا کنید.

· اجرای بیش از تنها جمع کننده 2 بعدی فعلی، BasicStatsCollector.

· اجرای بیشتر Aggregators.

· بیش از آداپتورها را پیاده سازی کنید.

DSDV راه رفتن

پروتکل مسیریابی Destination-Sequence Distance Vector (DSDV) یک پروتکل فعال است،
پروتکل مسیریابی مبتنی بر جدول برای MANET که توسط چارلز ای. پرکینز و پروین توسعه یافته است
Bhagwat در سال 1994. از تعداد پرش به عنوان متریک در انتخاب مسیر استفاده می کند.

این مدل توسط la ResiliNets تحقیق گروه در دانشگاه کانزاس آ
کاغذ در این مدل وجود دارد در این URL.

DSDV مسیریابی بررسی اجمالی
جدول مسیریابی DSDV: هر گره جدولی را حفظ می کند که تمام گره های دیگر خود را فهرست می کند
به طور مستقیم یا از طریق برخی از همسایگان شناخته شده است. هر گره یک ورودی دارد
جدول مسیریابی ورودی دارای اطلاعاتی در مورد آدرس IP گره است که آخرین بار شناخته شده است
شماره دنباله و تعداد پرش برای رسیدن به آن گره. همراه با این جزئیات جدول
همچنین همسایه nexthop را برای رسیدن به گره مقصد، مهر زمانی، پیگیری می کند
آخرین به روز رسانی دریافت شده برای آن گره.

پیام به روز رسانی DSDV از سه قسمت آدرس مقصد، شماره ترتیب و
هاپ کانت

هر گره از 2 مکانیسم برای ارسال به روز رسانی های DSDV استفاده می کند. آن ها هستند،

1.

تناوبی به روز رسانی
به روز رسانی های دوره ای پس از هر m_periodicUpdateInterval (پیش فرض: 15 ثانیه) ارسال می شود.
در این به روز رسانی گره کل جدول مسیریابی خود را پخش می کند.

2.

ماشه به روز رسانی
Trigger Updates به‌روزرسانی‌های کوچکی در بین به‌روزرسانی‌های دوره‌ای هستند. این به روز رسانی ها
هر زمان که یک گره بسته DSDV را دریافت کرد که باعث تغییر در آن شد، ارسال می شوند
جدول مسیریابی مقاله اصلی به وضوح اشاره ای به زمان برای چه تغییری نکرده است
در جدول باید یک به روز رسانی DSDV ارسال شود. پیاده سازی فعلی ارسال می کند
بدون در نظر گرفتن تغییر در جدول مسیریابی، یک به روز رسانی را انجام دهید.

به روز رسانی ها بر اساس متریک برای یک گره خاص پذیرفته می شوند. اولین عامل
تعیین پذیرش یک به روز رسانی شماره ترتیب است. باید آپدیت را بپذیرد
اگر شماره توالی پیام به روز رسانی صرف نظر از متریک بالاتر باشد. اگر
به روز رسانی با همان شماره دنباله دریافت می شود، سپس به روز رسانی با حداقل متریک (hopCount)
اولویت داده شده است.

در سناریوهای بسیار متحرک، شانس زیادی برای نوسانات مسیر وجود دارد، بنابراین ما آن را داریم
مفهوم زمان تسویه وزنی که در آن به روز رسانی با تغییر در متریک وجود نخواهد داشت
برای همسایه ها تبلیغ می شود گره منتظر زمان ته نشینی می ماند تا مطمئن شود که انجام نشده است
قبل از ارسال آن به روز رسانی را از همسایه قدیمی خود دریافت کنید.

پیاده سازی فعلی تمام ویژگی های فوق DSDV را پوشش می دهد. جاری
پیاده سازی همچنین دارای یک صف درخواست برای بافر بسته هایی است که هیچ مسیری به آن ندارند
مقصد به طور پیش فرض تنظیم شده است تا حداکثر 5 بسته در هر مقصد بافر شود.

منابع
پیوند به مقاله: http://portal.acm.org/citation.cfm?doid=190314.190336

DSR راه رفتن

پروتکل مسیریابی منبع دینامیک (DSR) یک پروتکل مسیریابی واکنشی است که به طور خاص طراحی شده است
برای استفاده در شبکه های چند هاپ بی سیم ad hoc گره های تلفن همراه.

این مدل توسط la ResiliNets تحقیق گروه در دانشگاه کانزاس

DSR مسیریابی بررسی اجمالی
این مدل مشخصات پایه پروتکل مسیریابی منبع دینامیک (DSR) را پیاده سازی می کند.
اجرا بر اساس RFC 4728، با برخی پسوندها و تغییرات در RFC
مشخصات.

DSR بر اساس یک رفتار درخواستی عمل می کند. بنابراین، مدل DSR ما تمام بسته ها را بافر می کند در حالی که a
بسته درخواست مسیر (RREQ) منتشر می شود. ما یک بسته بافر را در آن پیاده سازی می کنیم
dsr-rsendbuff.cc. صف بسته جمع آوری زباله از بسته های قدیمی و a
محدودیت اندازه صف هنگامی که بسته از بافر ارسال خارج می شود، در صف قرار می گیرد
بافر نگهداری برای تایید پرش بعدی.

سپس بافر تعمیر و نگهداری بسته های ارسال شده را بافر می کند و منتظر می ماند
اطلاع رسانی تحویل بسته عملکرد پروتکل به شدت به پیوند شکسته بستگی دارد
مکانیسم تشخیص ما سه اکتشافی توصیه شده مبتنی بر RFC را اجرا می کنیم
به شرح زیر است:

اول، ما در صورت امکان از بازخورد لایه پیوند استفاده می کنیم که سریع ترین مکانیسم نیز می باشد
این سه برای تشخیص خطاهای لینک. در صورت انتقال فریم، یک پیوند خراب در نظر گرفته می شود
منجر به شکست انتقال برای همه تلاش های مجدد می شود. این مکانیسم برای فعال در نظر گرفته شده است
پیوند می دهد و بسیار سریعتر از زمان غیبت آن کار می کند. DSR قادر به تشخیص لایه پیوند است
خرابی انتقال و اعلام کنید که خراب است. محاسبه مجدد مسیرها آغاز خواهد شد
در موقع لزوم. اگر کاربر نمی خواهد از تایید لایه پیوند استفاده کند، می توان آن را تنظیم کرد
تنظیم ویژگی "LinkAcknowledgment" روی false در "dsr-routing.cc".

دوم، تا جایی که ممکن است باید از تصدیق غیرفعال استفاده شود. گره روشن می شود
حالت دریافت "بی بند و بار"، که در آن می تواند بسته هایی را دریافت کند که برای خودش تعیین نشده اند، و
هنگامی که گره از تحویل آن بسته داده به مقصد اطمینان می دهد، آن را لغو می کند
تایمر تایید غیرفعال

در آخر، ما از یک طرح تایید لایه شبکه برای اطلاع از دریافت یک بسته استفاده می کنیم. مسیر
بسته درخواست تایید یا ارسال مجدد نخواهد شد.

اجرای Route Cache از جمع آوری زباله ورودی های قدیمی و وضعیت پشتیبانی می کند
ماشین، همانطور که در استاندارد تعریف شده است. به عنوان یک کانتینر نقشه STL پیاده سازی می شود. کلید این است
نشانی آی پی مقصد.

DSR با دسترسی مستقیم به هدر IP عمل می کند و بین شبکه و حمل و نقل عمل می کند
لایه. هنگامی که بسته از لایه انتقال به بیرون ارسال می شود، خود به DSR و DSR منتقل می شود
هدر ضمیمه شده است

ما دو مکانیسم کش داریم: کش مسیر و کش پیوند. کش مسیر کل را ذخیره می کند
مسیر در حافظه پنهان مسیرها بر اساس تعداد پرش و هر زمان که یک مسیر باشد مرتب می شوند
قابل استفاده نیست، به مسیر بعدی تغییر می کنیم. کش پیوند کمی بهتر است
طراحی به این معنا که از مسیرهای فرعی مختلفی استفاده می کند و از Implemented Link Cache استفاده می کند
الگوریتم Dijsktra و این قسمت توسط Song Luan پیاده سازی شده استlsuper@mail.ustc.edu.cn>.

بهینه‌سازی‌های پروتکل اختیاری زیر پیاده‌سازی نشده‌اند:

· وضعیت جریان

· پرچم های اولین هاپ خارجی (F)، آخرین هاپ خارجی (L).

· مدیریت گزینه های ناشناخته DSR

·

دو انواع of خطا سرصفحه ها:

1. حالت جریان گزینه پشتیبانی نمی شود

2. گزینه پشتیبانی نشده (در شبیه سازی اتفاق نمی افتد)

DSR به روز رسانی in ns-3.17
ما در ابتدا از "TxErrHeader" در Ptr استفاده کردیم برای نشان دادن خطای انتقال a
بسته خاص در لایه پیوند، با این حال، از آن زمان به بعد به درستی کار نمی کرد
بسته حذف شد، این هدر در فایل ردیابی ثبت نشد. عادت داشتیم الف
مسیرهای مختلف در پیاده سازی مکانیسم اطلاع رسانی لایه پیوند. ما به
ردیابی فایل با یافتن رویداد دریافت بسته. اگر یک رویداد دریافت برای داده ها پیدا کنیم
بسته، ما آن را به عنوان شاخصی برای تحویل موفقیت آمیز داده در نظر می گیریم.

مفید پارامترهای
+------------------------------------------------- -------------+--------------+
| پارامتر | توضیحات | پیش فرض |
+=========================+====================== ==============+=============+
| MaxSendBuffLen | حداکثر تعداد بسته هایی که می توانند | 64 |
| | ذخیره شود در بافر ارسال | |
+------------------------------------------------- -------------+--------------+
| MaxSendBuffTime | بسته های حداکثر زمان را می توان در صف قرار داد | ثانیه(30) |
| | در بافر ارسال | |
+------------------------------------------------- -------------+--------------+
| MaxMaintLen | حداکثر تعداد بسته هایی که می توانند | 50 |
| | در بافر نگهداری ذخیره شود | |
+------------------------------------------------- -------------+--------------+
| MaxMaintTime | بسته های حداکثر زمان را می توان در صف قرار داد | ثانیه(30) |
| | در بافر نگهداری | |
+------------------------------------------------- -------------+--------------+
| MaxCacheLen | حداکثر تعداد ورودی مسیر | 64 |
| | قابل ذخیره در روت کش | |
+------------------------------------------------- -------------+--------------+
| RouteCacheTimeout | حداکثر زمانی که کش مسیر می تواند | ثانیه(300)|
| | در کش مسیر در صف قرار گیرند | |
+------------------------------------------------- -------------+--------------+
| RreqRetries | حداکثر تعداد ارسال مجدد | 16 |
| | برای درخواست کشف یک مسیر | |
+------------------------------------------------- -------------+--------------+
| نوع کش | از Link Cache استفاده کنید یا از Path Cache | "لینک کش" |
| | | |
+------------------------------------------------- -------------+--------------+
| LinkAcknowledgment | فعال کردن تایید لایه پیوند | درسته |
| | مکانیزم | |
+------------------------------------------------- -------------+--------------+

پیاده سازی اصلاح
·

La DsrFsHeader است اضافه 3 زمینه های: پیام نوع، منبع شناسه، مقصد شناسه، و اینها
تغییرات فقط برای پردازش پس از

1. نوع پیام برای شناسایی بسته داده از بسته کنترل استفاده می شود

2. شناسه منبع برای شناسایی منبع واقعی بسته داده استفاده می شود زیرا ما داریم
برای تحویل بسته هاپ به هاپ و ipv4header واقعی را حمل نمی کند
آدرس IP مبدا و مقصد در صورت نیاز

3. شناسه مقصد به همان دلیل بالا است

· سرصفحه Route Reply در DSR RFC با کلمه تراز نشده است، آن را به کلمه تراز شده در تغییر دهید
پیاده سازی

· DSR به عنوان یک هدر شیم بین انتقال و پروتکل شبکه کار می کند، به پروتکل خود نیاز دارد
مکانیسم حمل و نقل، ما در حال تغییر انتقال بسته به تحویل هاپ به هاپ هستیم، بنابراین
ما دو فیلد در هدر ثابت dsr اضافه کردیم تا تحویل بسته را مطلع کنیم

جاری مسیر مخزن پیاده سازی
این پیاده‌سازی از «مسیر کش» استفاده می‌کند که پیاده‌سازی آن ساده است و بدون حلقه تضمین می‌کند
راه ها:

· کش مسیر دارای خط مشی انقضای خودکار است

· حافظه نهان چندین ورودی مسیر را برای یک مقصد خاص ذخیره می کند و ورودی ها را مرتب می کند
بر اساس تعداد پرش

· MaxEntriesEachDst را می توان تنظیم کرد تا حداکثر ورودی های ذخیره شده برای یک واحد را تغییر دهد
مقصد

· هنگام اضافه کردن مسیرهای متعدد برای یک مقصد، مسیر بر اساس مقایسه می شود
تعداد پرش و زمان انقضا، یکی با تعداد پرش کمتر یا مسیر نسبتاً جدید است
موفق

· اجرای آینده ممکن است شامل "کش پیوند" به عنوان یک امکان دیگر باشد

DSR دستورالعمل ها
هنگام اجرای DSR به عنوان پروتکل مسیریابی باید موارد زیر را در نظر داشت:

· NodeTraversalTime زمانی است که برای عبور از دو گره همسایه لازم است و باید باشد
متناسب با محدوده انتقال انتخاب شده است

· PassiveAckTimeout زمانی است که یک بسته در بافر تعمیر و نگهداری منتظر غیرفعال است
Acknowledgment، معمولاً به عنوان دو بار NodeTraversalTime تنظیم می شود

RouteCacheTimeout زمانی که سرعت گره ها بیشتر می شود باید مقدار کمتری تنظیم شود.
مقدار پیش فرض 300 ثانیه است.

کمک کننده
برای اجرای یک گره DSR، ساده ترین راه استفاده از DsrHelper و DsrMainHelpers است.
در اسکریپت شبیه سازی شما برای مثال:

DsrHelper dsr;
DsrMainHelper dsrMain;
dsrMain.Install (dsr، adhocNodes)؛

نمونه اسکریپت های داخل src/dsr/examples/ استفاده از گره های مبتنی بر DSR را نشان می دهد
سناریوهای مختلف منبع کمکی را می توان در داخل یافت
src/dsr/helper/dsr-main-helper.{h,cc} و src/dsr/helper/dsr-helper.{h,cc}

مثال ها
مثال را می توان در یافت src/dsr/examples/:

· dsr.cc از DSR به عنوان پروتکل مسیریابی در محیط سنتی MANETs استفاده می کند[3].

DSR همچنین در مورد مقایسه مسیریابی در ساخته شده است نمونه‌ها/مسیریابی/:

· manet-routing-compare.cc یک مورد مقایسه با پروتکل های مسیریابی داخلی MANET و
می تواند نتایج خود را ایجاد کند.

اعتبار
این مدل به صورت زیر تست شده است:

· تست های واحد برای تأیید داخلی DSR نوشته شده است. این را می توان در یافت
src/dsr/test/dsr-test-suite.cc. این تست ها بررسی می کنند که آیا روش های داخل ماژول DSR وجود دارد یا خیر
که با بافر بسته سروکار دارند، هدرها به درستی کار می کنند.

· موارد شبیه سازی مشابه [3] آزمایش شده اند و نتایج قابل مقایسه ای دارند.

· manet-routing-compare.cc برای مقایسه DSR با سه مسیریابی دیگر استفاده شده است.
پروتکل ها

مقاله ای در مورد این نتایج در کارگاه آموزشی ns-3 در سال 2011 ارائه شد.

محدودیت ها
این مدل به طور کامل مطابقت ندارد RFC 4728. به عنوان مثال، هدر اندازه ثابت Dsr دارد
تمدید شده است و چهار اکتکت بیشتر از مشخصات RFC است. به عنوان یک نتیجه،
هدرهای DSR را نمی توان به درستی توسط Wireshark رمزگشایی کرد.

مطابقت کامل مدل با RFC برای آینده برنامه ریزی شده است.

منابع
[1] مقاله اصلی: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

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

[3] مقاله مقایسه بروش: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

شبیه سازی بررسی اجمالی

ns-3 برای ادغام در محیط های تست و ماشین مجازی طراحی شده است. ما
با ارائه دو نوع دستگاه شبکه به این نیاز پرداخته اند. اولین نوع دستگاه
یک دستگاه شبکه توصیفگر فایل است (FdNetDevice) که یک نوع دستگاه عمومی است که می تواند
خواندن و نوشتن از یک توصیفگر فایل با مرتبط کردن این توصیفگر فایل با موارد مختلف
چیزهایی در سیستم میزبان، قابلیت های مختلفی را می توان ارائه کرد. به عنوان مثال،
FdNetDevice را می توان با یک سوکت بسته زیرین برای ارائه شبیه سازی مرتبط کرد
توانایی ها. این اجازه می دهد ns-3 شبیه سازی برای ارسال داده ها در یک شبکه "واقعی". دومین
مهربان، به نام a شیر NetDevice به یک میزبان "واقعی" اجازه می دهد تا در یک ns-3 شبیه سازی به عنوان
اگر یکی از گره های شبیه سازی شده باشد. یک ns-3 شبیه سازی ممکن است با هر کدام ساخته شود
ترکیبی از دستگاه های شبیه سازی شده یا شبیه سازی شده

توجه داشته باشید: قبل از ns-3.17، قابلیت شبیه سازی توسط دستگاه خاصی به نام ارائه می شد
an شترمرغ استرالیایی NetDevice; را شترمرغ استرالیایی NetDevice جایگزین شده است FdNetDevice.

یکی از موارد استفاده ای که ما می خواهیم از آن پشتیبانی کنیم، یک بستر آزمایشی است. یک مثال عینی از یک
محیطی از این دست، بستر آزمایش ORBIT است. ORBIT یک شبیه ساز آزمایشگاهی / آزمایش میدانی است
شبکه به عنوان یک شبکه دو بعدی از 400 گره رادیویی 802.11 مرتب شده است. ما ادغام می شویم
ORBIT با استفاده از فرآیند "تصویربرداری" خود برای بارگیری و اجرا ns-3 شبیه سازی در ORBIT
آرایه. ما می توانیم از خود استفاده کنیم EmuFdNetDevice برای رانندگی سخت افزار در بستر آزمایش و ما می توانیم
جمع آوری نتایج یا با استفاده از ns-3 توابع ردیابی و ورود به سیستم، یا بومی
تکنیک های گردآوری داده های ORBIT دیدن http://www.orbit-lab.org/ برای جزئیات در مورد ORBIT
تست شده

شبیه سازی از این نوع در شکل زیر نشان داده شده است:
[تصویر] نمونه اجرای شبیه سازی بستر آزمایشی..UNINDENT

می توانید ببینید که میزبان های جداگانه ای وجود دارد که هر کدام زیرمجموعه ای از یک "جهانی" را اجرا می کنند.
شبیه سازی. به جای یک ns-3 کانال اتصال میزبان، ما از سخت افزار واقعی استفاده می کنیم
توسط بستر آزمایش ارائه شده است. این اجازه می دهد ns-3 برنامه ها و پشته های پروتکل متصل به a
گره شبیه سازی برای برقراری ارتباط از طریق سخت افزار واقعی.

ما انتظار داریم که استفاده اولیه برای این پیکربندی تولید تکرارپذیر باشد
نتایج تجربی در یک محیط شبکه دنیای واقعی که شامل همه موارد است ns-3
ابزارهای ردیابی، ثبت، تجسم و جمع آوری آمار.

در چیزی که می توان اساساً به عنوان یک پیکربندی معکوس در نظر گرفت، ما به ماشین های "واقعی" اجازه می دهیم
اجرای برنامه های بومی و پشته های پروتکل برای ادغام با یک ns-3 شبیه سازی.
این امکان شبیه سازی شبکه های بزرگ متصل به یک ماشین واقعی و همچنین
مجازی سازی را فعال می کند. شبیه سازی از این نوع در شکل زیر نشان داده شده است:
[تصویر] نمای کلی پیاده سازی کانال شبیه سازی شده..UNINDENT

در اینجا خواهید دید که یک هاست با تعدادی ماشین مجازی در حال اجرا است
بر روی آن. یک ns-3 شبیه سازی در حال اجرا در ماشین مجازی نشان داده شده در مرکز نشان داده شده است
شکل. این شبیه سازی دارای تعدادی گره همراه است ns-3 برنامه ها و
پشته های پروتکلی که با یک صحبت می کنند ns-3 کانال از طریق شبیه سازی بومی ns-3 خالص
دستگاه ها.

همچنین دو ماشین مجازی در سمت چپ و سمت راست شکل نشان داده شده است.
این VM ها برنامه های بومی (لینوکس) و پشته های پروتکل را اجرا می کنند. VM است
توسط یک دستگاه لینوکس Tap net به شبیه سازی متصل شده است. کنترل کننده حالت کاربر برای
دستگاه Tap در شبیه سازی نمونه سازی شده و به یک گره پروکسی متصل می شود
VM بومی را در شبیه سازی نشان می دهد. این دسته‌ها به دستگاه‌های Tap اجازه می‌دهند بر روی
ماشین های مجازی بومی طوری رفتار کنند که انگار هستند ns-3 دستگاه های شبکه در VM شبیه سازی این، در
به نوبه خود، به نرم افزارهای بومی و مجموعه های پروتکل در ماشین های مجازی بومی اجازه می دهد تا این را باور کنند
آنها به شبیه سازی متصل هستند ns-3 کانال.

ما انتظار داریم که مورد استفاده معمول برای این محیط تجزیه و تحلیل رفتار باشد
برنامه های بومی و مجموعه های پروتکل در حضور شبیه سازی های بزرگ ns-3
شبکه های.

پرونده توصیفگر NetDevice
La src/fd-net-device ماژول را فراهم می کند FdNetDevice کلاس، که قادر به خواندن و
با استفاده از یک توصیفگر فایل ارائه شده توسط کاربر، ترافیک را بنویسید. این توصیفگر فایل می تواند باشد
به یک دستگاه TAP، به یک سوکت خام، به یک فرآیند تولید/مصرف فضای کاربر مرتبط است
ترافیک و غیره کاربر آزادی کامل دارد تا نحوه تولید ترافیک خارجی را تعریف کند
ns-3 ترافیک مصرف می شود

مکانیسم‌های مختلفی برای مرتبط کردن یک شبیه‌سازی به ترافیک خارجی می‌تواند از طریق آن ارائه شود
کلاس های کمکی سه کمک کننده خاص ارائه شده است:

· EmuFdNetDeviceHelper (برای مرتبط کردن ns-3 دستگاه با یک دستگاه فیزیکی در میزبان
دستگاه)

· TapFdNetDeviceHelper (برای مرتبط کردن دستگاه ns-3 با توصیفگر فایل از یک ضربه
دستگاه در دستگاه میزبان)

· PlanteLabFdNetDeviceHelper (برای خودکارسازی ایجاد دستگاه های ضربه ای در گره های PlanetLab،
را قادر می سازد ns-3 شبیه سازی هایی که می توانند ترافیک را از طریق اینترنت با استفاده از اینترنت ارسال و دریافت کنند
منبع PlanetLab

مدل توضیحات:
کد منبع این ماژول در فهرست موجود است src/fd-net-device.

FdNetDevice یک نوع خاص است ns-3 NetDevice که ترافیک به یک فایل و از آن را می خواند
توصیف کننده یعنی برخلاف اشیاء NetDevice شبیه سازی خالص که فریم ها را به و می نویسند
از یک کانال شبیه سازی شده، این FdNetDevice فریم ها را از شبیه سازی به یک فایل هدایت می کند
توصیف کننده توصیفگر فایل ممکن است به یک دستگاه لینوکس TUN/TAP، به یک سوکت مرتبط باشد،
یا به یک فرآیند فضای کاربر.

تهیه توصیفگر فایل به عهده کاربر این دستگاه است. نوع فایل
توصیفگر ارائه شده تعیین می کند که چه چیزی مدل می شود. به عنوان مثال، اگر فایل
توصیفگر یک سوکت خام به یک کارت وای فای در دستگاه میزبان فراهم می کند، دستگاه موجود است
مدل شده یک دستگاه WiFi است.

از "بالای" مفهومی دستگاه که به پایین نگاه می کند، به گره شبیه سازی شده شبیه است
دستگاهی که از یک آدرس MAC IEEE 48 بیتی پشتیبانی می کند که می تواند بریج شود، از پخش پشتیبانی می کند و
از IPv4 ARP یا IPv6 Neighbor Discovery استفاده می کند، اگرچه این ویژگی ها را می توان روی a تنظیم کرد
بر اساس هر مورد.

طرح
پیاده سازی FdNetDevice از یک شیء خواننده استفاده می کند که از آن گسترش یافته است FdReader
کلاس در ns-3 src/core ماژول، که یک موضوع مجزا از اصلی را مدیریت می کند ns-3
رشته اجرا، به منظور خواندن ترافیک از توصیفگر فایل.

با فراخوانی از StartDevice در روش، شی Reader مقداردهی اولیه می شود و شروع می کند
نخ خواندن قبل از شروع دستگاه، یک توصیفگر فایل باید قبلاً به آن مرتبط شود
FdNetDevice با SetFileDescriptor فراخوانی

ایجاد و پیکربندی توصیفگر فایل را می توان به تعدادی از کمک کنندگان واگذار کرد.
در زیر با جزئیات بیشتر توضیح داده شده است. وقتی این کار انجام شد، فراخوانی از SetFileDescriptor is
مسئولیت کمک کننده است و نباید مستقیماً توسط کاربر مورد استناد قرار گیرد.

با خواندن یک فریم ورودی از توصیفگر فایل، خواننده فریم را به آن ارسال می کند
la Receive Callback روشی که وظیفه آن برنامه ریزی برای دریافت فریم است
دستگاه به عنوان یک ns-3 رویداد شبیه سازی از آنجایی که فریم جدید از نخ خواننده به
اصلی ns-3 با استفاده از نخ شبیه سازی، از مسائل ایمنی نخ جلوگیری می شود
ScheduleWithContext به جای معمولی تماس بگیرید برنامه زنگ زدن.

به منظور جلوگیری از تحت فشار قرار دادن زمانبندی زمانی که نرخ داده های دریافتی بسیار بالا است، الف
شمارنده با تعداد فریم هایی که در حال حاضر برنامه ریزی شده است توسط آنها دریافت شود نگهداری می شود
دستگاه اگر این شمارنده به مقدار داده شده توسط عدد برسد RxQueueSize ویژگی در
دستگاه، سپس قاب جدید بی‌صدا رها می‌شود.

دریافت واقعی قاب جدید توسط دستگاه زمانی اتفاق می افتد که برنامه ریزی شده باشد FordwarUp
روش توسط شبیه ساز فراخوانی می شود. این روش طوری عمل می کند که انگار یک فریم جدید از a وارد شده است
کانال متصل به دستگاه سپس دستگاه قاب را کپسوله می‌کند و هر لایه را از بین می‌برد
2 سرصفحه، و آن را به لایه های پشته شبکه بالایی گره ارسال می کند. در ForwardUp
این روش هدرهای فریم را با توجه به نوع کپسوله سازی قاب که توسط آن تعریف شده است حذف می کند
la حالت Encapsulation ویژگی، و فراخوانی دریافت تماس را با ارسال یک بسته IP فراخوانی کنید.

یک هدر اضافی، هدر PI، می تواند زمانی وجود داشته باشد که توصیفگر فایل به a مرتبط شود
دستگاه TAP که بدون تنظیم پرچم IFF_NO_PI ایجاد شده است. این هدر اضافی است
حذف شده اگر حالت Encapsulation روی مقدار DIXPI تنظیم شده است.

در جهت مخالف، بسته هایی در داخل شبیه سازی تولید می شوند که به بیرون ارسال می شوند
از طریق دستگاه، به ارسال روش، که به نوبه خود فراخوانی می کند
ارسال از روش. روش دوم هدرهای لایه 2 لازم را به سادگی اضافه می کند
فریم جدید ایجاد شده را در توصیفگر فایل بنویسید.

حوزه و محدودیت ها
به کاربران این دستگاه هشدار داده می شود که کنترل جریان در سراسر فایل وجود ندارد
مرز توصیفگر، هنگام استفاده در حالت شبیه سازی. یعنی در یک سیستم لینوکس، اگر
سرعت نوشتن بسته های شبکه از توانایی دستگاه فیزیکی زیرین بیشتر است
بسته ها را بافر کنید، برای جلوگیری از فشار برگشتی تا برنامه نوشتن اعمال می شود
از دست دادن بسته محلی چنین کنترل جریانی در رابط توصیفگر فایل ارائه نمی شود،
بنابراین کاربران باید از این محدودیت آگاه باشند.

همانطور که قبلا توضیح داده شد، ویژگی RxQueueSize تعداد بسته هایی را که می تواند وجود داشته باشد را محدود می کند
در انتظار دریافت توسط دستگاه فریم ها از توصیف کننده فایل خوانده می شوند در حالی که
تعداد بسته های معلق در حداکثر خود است بی سر و صدا حذف خواهد شد.

mtu دستگاه روی مقدار Ethernet II MTU پیش‌فرض است. با این حال، مددکاران فرض می شود
برای تنظیم mtu روی مقدار مناسب برای منعکس کردن ویژگی های رابط شبکه
مرتبط با توصیفگر فایل اگر از کمکی استفاده نمی شود، مسئولیت آن بر عهده می گیرد
تنظیم مقدار صحیح mtu برای دستگاه به کاربر برمی گردد. اندازه خوانده شده
بافر در خواننده توصیفگر فایل روی مقدار mtu در تنظیم شده است StartDevice روش.

کلاس FdNetDevice در حال حاضر از سه حالت کپسوله سازی، DIX برای اترنت II پشتیبانی می کند
فریم‌ها، LLC برای فریم‌های 802.2 LLC/SNAP، و DIXPI برای فریم‌های اترنت II با فریم‌های اضافی
هدر TAP PI. این به این معنی است که انتظار می رود ترافیک در حال عبور از توصیفگر فایل باشد
سازگار با اترنت II اتصال FdNetDevice به یک رابط بی سیم امکان پذیر است
تا زمانی که درایور فریم های اترنت II را به سوکت API ارائه دهد. توجه داشته باشید که برای ارتباط
یک FdNetDevice به یک کارت بی سیم در حالت ad-hoc، آدرس MAC دستگاه باید تنظیم شود
به آدرس MAC کارت واقعی، در غیر این صورت هر ترافیک ورودی یک آدرس مک جعلی خواهد بود
توسط راننده دور انداخته شد

همانطور که قبلا ذکر شد، سه کمک کننده با ماژول fd-net-device ارائه شده است. هر یک
کمک کننده فردی (نوع توصیفگر فایل) ممکن است محدودیت های پلت فرم داشته باشد. برای مثال،
threading، حالت شبیه سازی بلادرنگ و قابلیت ایجاد دستگاه های TUN/TAP هستند
پیش نیازهای استفاده از کمک های ارائه شده پشتیبانی از این حالت ها را می توان در
خروجی از واف پیکربندی مرحله، به عنوان مثال:

Threading Primitives: فعال است
شبیه ساز زمان واقعی: فعال است
دستگاه شبکه شبیه سازی شده: فعال است
روی Bridge ضربه بزنید: فعال است

ذکر این نکته ضروری است که در حین تست FdNetDevice ما یک کران بالایی پیدا کرده ایم
در هنگام استفاده از پیوندهای اترنت 1 گیگابایتی با سرعت 60 مگابیت در ثانیه، توان پردازش TCP را محدود کنید. این حد بیشتر است
احتمالاً به دلیل قدرت پردازش رایانه های درگیر در آزمایشات است.

استفاده
الگوی استفاده از این نوع دستگاه ها مشابه سایر دستگاه های نت دارای کمکی است
که به گره اشاره گر یا کانتینر گره نصب می شود. هنگام استفاده از پایه FdNetDeviceHelper
کاربر مسئول ایجاد و تنظیم توصیفگر فایل توسط خودش است.

FdNetDeviceHelper fd;
دستگاه های NetDeviceContainer = fd.Install (node);

// تولید توصیفگر فایل
...

device->SetFileDescriptor (fd)؛

معمولاً یک FdNetDevice برای تعامل با سیستم میزبان استفاده می شود. در این موارد
تقریباً مطمئن است که کاربر می خواهد در حالت شبیه سازی بلادرنگ اجرا شود و به
محاسبات جمع چک را فعال کنید عبارات معمول برنامه به شرح زیر است:

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

ساده‌ترین راه برای راه‌اندازی آزمایشی که با سیستم میزبان لینوکس در تعامل است، کاربر است
la شترمرغ استرالیایی و شیر کمک کنندگان شاید غیرعادی ترین بخش این پیاده سازی های کمکی باشد
به الزام برای اجرای برخی از کدها با مجوزهای فوق کاربر مربوط می شود.
به جای اینکه کاربر را مجبور کنیم که کل شبیه سازی را به صورت روت اجرا کند، یک کوچک ارائه می دهیم
برنامه "creator" که به صورت روت اجرا می شود و هر سوکت با مجوز بالا را انجام می دهد.
ساده ترین راه برای تنظیم امتیازات مناسب برای برنامه های "خالق"، فعال کردن
--enable-sudo هنگام اجرا پرچم گذاری کنید واف پیکربندی.

ما یک کار مشابه برای هر دو انجام می دهیم شترمرغ استرالیایی و شیر دستگاه ها دیدگاه سطح بالا این است که
la CreateFileDescriptor متد یک سوکت داخلی (یونیکس)، فورک ها و
برنامه ایجاد کوچک را اجرا می کند. برنامه کوچک، که به عنوان ریشه suid اجرا می شود، یک را ایجاد می کند
سوکت خام و توصیفگر فایل سوکت خام را روی سوکت یونیکس که
به عنوان پارامتر به آن منتقل می شود. سوکت خام به عنوان یک پیام کنترل ارسال می شود (گاهی اوقات
داده های جانبی نامیده می شود) از نوع SCM_RIGHTS.

یاران
EmuFdNetDeviceHelper
EmuFdNetDeviceHelper یک سوکت خام به یک دستگاه فیزیکی زیرین ایجاد می کند و
توصیفگر سوکت را برای FdNetDevice فراهم می کند. این اجازه می دهد تا ns-3 شبیه سازی به
خواندن فریم ها و نوشتن فریم ها در یک دستگاه شبکه در میزبان.

کمک کننده شبیه سازی اجازه ادغام شفاف یک شبیه سازی شده را می دهد ns-3 گره به a
شبکه متشکل از گره های واقعی

+----------------------+ +---------------------+
| میزبان 1 | | میزبان 2 |
+----------------------+ +---------------------+
| شبیه سازی ns-3 | | |
+----------------------+ | لینوکس |
| ns-3 گره | | پشته شبکه |
| +----------------+ | | +----------------+ |
| | ns-3 TCP | | | | TCP | |
| +----------------+ | | +----------------+ |
| | ns-3 IP | | | | IP | |
| +----------------+ | | +----------------+ |
| | FdNetDevice | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + اترنت + |
| | سوکت خام | | | | | |
|--+----------------+--| | +----------------+ |
| | eth0 | | | | eth0 | |
+-------+------+-------+ +---------------------+

10.1.1.11 10.1.1.12

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

این کمکی جایگزین عملکرد EmuNetDevice موجود در ns-3 قبل از ns-3.17،
با وارد کردن این نوع دستگاه به چارچوب مشترک FdNetDevice. در
EmuNetDevice به نفع این یاور جدید منسوخ شد.

دستگاه به گونه ای پیکربندی شده است که جعل MAC را برای جداسازی ترافیک شبکه شبیه سازی انجام دهد
از سایر ترافیک شبکه ای که ممکن است به هاست و از میزبان جریان داشته باشد.

می توان از این کمک کننده در یک موقعیت بستر آزمایشی استفاده کرد که میزبانی که شبیه سازی روی آن قرار دارد
در حال اجرا دارای یک رابط خاص مورد علاقه است که سخت افزار بستر آزمایش را هدایت می کند. شما می خواهید
همچنین باید این رابط خاص را در حالت بی‌وقفه تنظیم کنید و یک مناسب ارائه دهید
نام دستگاه به ns-3 شبیه سازی. علاوه بر این، تخلیه سخت افزاری از بخش بندی و
چک جمع ها باید غیرفعال شوند.

کمک کننده فقط در صورتی کار می کند که رابط زیربنایی فعال باشد و در حالت بی بند و باری باشد. بسته ها
از طریق دستگاه ارسال خواهد شد، اما ما از جعل MAC استفاده می کنیم. آدرس های MAC خواهد بود
تولید شده (به طور پیش فرض) با استفاده از شناسه منحصر به فرد سازمانی (OUI) 00:00:00 به عنوان یک
پایه. این کد فروشنده به هیچ سازمانی اختصاص داده نشده است و بنابراین نباید با آن تضاد داشته باشد
هر سخت افزار واقعی

این همیشه به عهده کاربر است که تشخیص دهد استفاده از این آدرس های MAC برای شما مشکلی ندارد
شبکه و با هیچ چیز دیگری (از جمله شبیه سازی دیگری با استفاده از آن) در تضاد نخواهد بود
دستگاه ها) در شبکه شما. اگر از پیکربندی شبیه سازی شده FdNetDevice استفاده می کنید
شبیه سازی های جداگانه، باید مسائل مربوط به انتساب آدرس MAC را در نظر بگیرید و اطمینان حاصل کنید
آدرس های MAC در تمام شبیه سازی ها منحصر به فرد هستند. دستگاه شبکه شبیه سازی شده به آن احترام می گذارد
آدرس MAC ارائه شده در نشانی: ویژگی بنابراین می توانید این کار را به صورت دستی انجام دهید. برای بزرگتر
شبیه سازی، ممکن است بخواهید OUI را در تابع تخصیص آدرس MAC تنظیم کنید.

قبل از فراخوانی نصب روش، نام دستگاه صحیح باید بر روی پیکربندی شود
کمک کننده با استفاده از SetDeviceName روش. نام دستگاه برای شناسایی مورد نیاز است
برای باز کردن سوکت خام باید از دستگاه فیزیکی استفاده شود.

EmuFdNetDeviceHelper emu;
emu.SetDeviceName (DeviceName);
دستگاه های NetDeviceContainer = emu.Install (node);
Ptr دستگاه = دستگاه. دریافت (0);
device->SetAttribute ("Address"، Mac48AddressValue (Mac48Address::Allocate ()));

TapFdNetDeviceHelper را بزنید
دستگاه Tap نوع خاصی از دستگاه لینوکس است که یک انتهای دستگاه به نظر می رسد
هسته به عنوان یک net_device مجازی، و انتهای دیگر به عنوان یک توصیف کننده فایل ارائه می شود
فضای کاربری این توصیفگر فایل را می توان به FdNetDevice ارسال کرد. بسته های ارسال شده به
دستگاه TAP توسط هسته در FdNetDevice در نمایش داده می شود ns-3.

کاربران باید توجه داشته باشند که این استفاده از دستگاه‌های TAP با استفاده از دستگاه‌های TAP متفاوت است
TapBridge NetDevice در یافت شد src/tap-bridge. مدل این کمک کننده به شرح زیر است:

+-------------------------------------+
| میزبان |
+-------------------------------------+
| شبیه سازی ns-3 | |
+----------------------+ |
| ns-3 گره | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNetDevice | | |
|--+----------------+--+ +------+ |
| | TAP | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+------------------------------|-----+
|
|
------------ (اینترنت) -----

در بالا، پیکربندی مستلزم آن است که هاست بتواند ترافیک را فوروارد کند
تولید شده توسط شبیه سازی به اینترنت.

مدل در TapBridge (در یک ماژول دیگر) به شرح زیر است:

+--------+
| لینوکس |
| میزبان | +----------+
| ------ | | روح |
| برنامه ها | | گره |
| ------ | | -------- |
| پشته | | IP | +----------+
| ------ | | پشته | | گره |
| TAP | |==========| | -------- |
| دستگاه | <----- IPC ------> | ضربه بزنید | | IP |
+--------+ | پل | | پشته |
| -------- | | -------- |
| ns-3 | | ns-3 |
| خالص | | خالص |
| دستگاه | | دستگاه |
+----------+ +----------+
|| ||
+----------------------------+
| کانال ns-3 |
+----------------------------+

در موارد فوق، بسته ها به جای عبور و مرور ns-3 NetDevices و کانال ها

الگوی استفاده برای این مثال این است که کاربر آدرس MAC و یا (or
هر دو) آدرس ها و ماسک های IPv4 و IPv6 روی دستگاه و هدر PI در صورت نیاز.
مثلا:

TapFdNetDeviceHelper helper.
helper.SetDeviceName (DeviceName);
helper.SetModePi (modePi);
helper.SetTapIpv4Address (tapIp);
helper.SetTapIpv4Mask (tapMask);
...
helper.Install (node);

PlanetLabFdNetDeviceHelper
PlanetLab یک بستر آزمایشی شبکه توزیع شده در سراسر جهان است که از گره های متصل به آن تشکیل شده است
اینترنت. اجرای شبیه سازی ns-3 در گره های PlanetLab با استفاده از
PlanetLabFdNetDeviceHelper اجازه می دهد تا ترافیک شبیه سازی شده تولید شده توسط ns-3 را مستقیماً به
اینترنت. این تنظیم می تواند برای اعتبارسنجی پروتکل های اینترنت ns-3 یا سایر آینده مفید باشد
پروتکل های پیاده سازی شده در ns-3

برای اجرای آزمایش‌ها با استفاده از گره‌های PlanetLab، باید یک حساب PlanetLab داشته باشید. فقط
اعضای موسسات شریک PlanetLab می توانند چنین حساب هایی را دریافت کنند ( برای اطلاعات بیشتر
بازدید http://www.planet-lab.org/ or http://www.planet-lab.eu ). یک بار حساب است
به دست آمد، یک PlanetLab برش برای انجام آزمایشات باید درخواست شود. یک تکه
یک واحد آزمایشی مربوط به گروهی از کاربران PlanetLab را نشان می دهد و می تواند مرتبط شود
به ماشین های مجازی در گره های مختلف PlanetLab. برش ها را نیز می توان با افزودن سفارشی کرد
تگ های پیکربندی به آن (این کار توسط مدیران PlanetLab انجام می شود).

PlanetLabFdNetDeviceHelper دستگاه های TAP را روی گره های PlanetLab با استفاده از موارد خاص ایجاد می کند
PlanetLab مکانیزم (یعنی سیستم vsys)، و دستگاه TAP را به a مرتبط می کند
FdNetDevice در ns-3. عملکرد ارائه شده توسط این کمک کننده مشابه آن است
ارائه شده توسط FdTapNetDeviceHelper، با این تفاوت که مکانیسم های اساسی برای ایجاد
دستگاه TAP متفاوت است.

+-------------------------------------+
| میزبان PlanetLab |
+-------------------------------------+
| شبیه سازی ns-3 | |
+----------------------+ |
| ns-3 گره | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNetDevice | | |
|--+----------------+--+ +------+ |
| | TAP | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+------------------------------|-----+
|
|
------------ (اینترنت) -----

برای اینکه بتوانیم آدرس های IPv4 خصوصی را به دستگاه های TAP، دارندگان حساب اختصاص دهیم
باید درخواست کند vsys_vnet برچسبی که باید توسط مدیران PlanetLab به برش آنها اضافه شود.
تگ vsys_vnet به بخش شبکه خصوصی مرتبط است و فقط از آن آدرس می‌دهد
بخش را می توان در آزمایش ها استفاده کرد.

نحوی که برای ایجاد یک دستگاه TAP با این کمک کننده استفاده می شود مشابه آنچه برای آن استفاده می شود
کمک کنندگانی که قبلاً توضیح داده شد:

PlanetLabFdNetDeviceHelper Helper;
helper.SetTapIpAddress (tapIp);
helper.SetTapMask (tapMask);
...
helper.Install (node);

گره های PlanetLab دارای توزیع مبتنی بر فدورا هستند، بنابراین ns-3 را می توان به دنبال آن نصب کرد
دستورالعمل نصب لینوکس ns-3.

خواص
La FdNetDevice تعدادی ویژگی را ارائه می دهد:

· نشانی:: آدرس MAC دستگاه

· آغاز: زمان شروع شبیه سازی برای چرخش نخ دستگاه

· توقف: زمان شروع شبیه سازی برای متوقف کردن نخ دستگاه

· حالت Encapsulation: فرمت کپسوله سازی لایه پیوند

·

RxQueueSize: La بافر اندازه of la خواندن صف on la پرونده توصیف کننده
رشته (پیش‌فرض 1000 بسته)

آغاز و توقف معمولاً نیازی به تعیین نیست مگر اینکه کاربر بخواهد آن را محدود کند
زمانی که این دستگاه فعال است. نشانی: باید به نوعی منحصر به فرد تنظیم شود
آدرس MAC اگر شبیه سازی با سایر دستگاه های واقعی به نحوی در تعامل باشد
آدرس های مک واقعی کد معمولی:

device->SetAttribute ("Address"، Mac48AddressValue (Mac48Address::Allocate ()));

تولید
ردیابی Ascii و PCAP مشابه دیگری ارائه می شود ns-3 انواع NetDevice، از طریق
کمک کننده ها، مانند (مثلا):

:: EmuFdNetDeviceHelper emu; دستگاه های NetDeviceContainer = emu.Install (node);
emu.EnablePcap ("emu-ping"، دستگاه، true);

مجموعه استاندارد منابع ردیابی NetDevice در سطح Mac ارائه شده است.

· MaxTx: منبع ردیابی زمانی فعال شد ns-3 یک قاب جدید برای ارسال به دستگاه ارائه می دهد

· MaxTxDrop: در صورت شکست توصیفگر نوشتن در فایل، منبع را ردیابی کنید

· MaxPromiscRx: هر زمان که فریم مک معتبری دریافت شود

· MaxRx: هر زمان که یک فریم مک معتبر برای این دستگاه دریافت شود

· اسنایفر: sniffer بسته غیرمجاز

· PromiscSniffer: sniffer بسته های غیرقانونی (برای ردیابی های tcpdump مانند)

مثال ها
چند مثال ارائه شده است:

· dummy-network.cc: این مثال ساده دو گره ایجاد می کند و آنها را با a به هم متصل می کند
یونیکس را با ارسال توصیفگرهای فایل از جفت سوکت به FdNetDevice لوله می کند
اشیاء گره های مربوطه

· realtime-dummy-network.cc: مانند dummy-network.cc اما از شبیه ساز زمان واقعی استفاده می کند
پیاده سازی به جای پیش فرض

· fd2fd-onoff.cc: هدف این مثال اندازه گیری توان عملیاتی FdNetDevice در است
یک شبیه سازی خالص برای این منظور دو دستگاه FdNet، متصل به گره های مختلف اما در
شبیه سازی مشابه، با استفاده از یک جفت سوکت متصل می شوند. ترافیک TCP در یک ارسال می شود
نرخ اشباع داده

· fd-emu-onoff.cc: هدف این مثال اندازه گیری توان عملیاتی FdNetDevice است
هنگام استفاده از EmuFdNetDeviceHelper برای اتصال دستگاه شبیه سازی شده به دستگاه واقعی در
ماشین میزبان این با اشباع کانال با ترافیک TCP به دست می آید.

· fd-emu-ping.cc: این مثال از EmuFdNetDeviceHelper برای ارسال ترافیک ICMP روی a استفاده می کند
کانال واقعی

· fd-emu-udp-echo.cc: این مثال از EmuFdNetDeviceHelper برای ارسال ترافیک UDP استفاده می کند
یک کانال واقعی

· fd-planetlab-ping.cc: این مثال نحوه تنظیم یک آزمایش برای ارسال ICMP را نشان می دهد
ترافیک از یک گره PlanetLab به اینترنت.

· fd-tap-ping.cc: این مثال از TapFdNetDeviceHelper برای ارسال ترافیک ICMP روی a استفاده می کند
کانال واقعی

شیر NetDevice
Tap NetDevice می تواند برای اجازه دادن به سیستم میزبان یا ماشین های مجازی برای تعامل با آن استفاده شود
یک شبیه سازی

TapBridge مدل بررسی اجمالی
Tap Bridge برای ادغام هاست های اینترنتی "واقعی" (یا دقیق تر، هاست ها) طراحی شده است
که از دستگاه های Tun/Tap پشتیبانی می کنند) در شبیه سازی ns-3. هدف این است که آن را به الف نشان دهیم
گره میزبان "واقعی" به این دلیل که یک دستگاه شبکه ns-3 به عنوان یک دستگاه محلی دارد. مفهوم الف
"میزبان واقعی" کمی لغزنده است زیرا "میزبان واقعی" ممکن است با استفاده از مجازی سازی شود
فناوری های در دسترس مانند VMware، VirtualBox یا OpenVZ.

از آنجایی که ما در اصل، ورودی و خروجی یک دستگاه شبکه ns-3 را به
ورودی و خروجی یک دستگاه لینوکس Tap net، ما این ترتیب را Tap Bridge می نامیم.

سه حالت اصلی عملکرد این دستگاه در دسترس کاربران قرار دارد. پایه ای
عملکرد اساساً یکسان است، اما حالت ها در جزئیات متفاوت هستند
نحوه ایجاد و پیکربندی آرایش؛ و چه دستگاه هایی می توانند در کدام طرف زندگی کنند
پل.

ما این سه حالت را حالت های ConfigureLocal، UseLocal و UseBridge می نامیم. اولین
"کلمه" در شناسه حالت شتر نشان می دهد که چه کسی مسئولیت ایجاد را دارد
و پیکربندی شیرها به عنوان مثال، "Configure" در حالت ConfigureLocal نشان می دهد
این TapBridge است که مسئولیت پیکربندی شیر را بر عهده دارد. در UseLocal
حالت و حالت های UseBridge، پیشوند "Use" نشان می دهد که از TapBridge خواسته می شود "استفاده" را انجام دهد.
یک پیکربندی موجود

به عبارت دیگر، در حالت ConfigureLocal، TapBridge مسئولیت ایجاد را دارد
و پیکربندی دستگاه های TAP. در حالت های UseBridge یا UseLocal، کاربر a
پیکربندی و TapBridge با آن پیکربندی سازگار می شود.

TapBridge ConfigureLocal حالت
در حالت ConfigureLocal، پیکربندی دستگاه شیر ns-3 است
پیکربندی محور اطلاعات پیکربندی از دستگاهی در ns-3 گرفته شده است
شبیه سازی و یک دستگاه ضربه ای مطابق با ویژگی های ns-3 به طور خودکار ایجاد می شود. که در
در این حالت، یک کامپیوتر لینوکس طوری به نظر می رسد که گویی مستقیماً به a متصل است
شبکه ns-3 شبیه سازی شده

این در زیر نشان داده شده است:

+--------+
| لینوکس |
| میزبان | +----------+
| ------ | | روح |
| برنامه ها | | گره |
| ------ | | -------- |
| پشته | | IP | +----------+
| ------ | | پشته | | گره |
| TAP | |==========| | -------- |
| دستگاه | <----- IPC ------> | ضربه بزنید | | IP |
+--------+ | پل | | پشته |
| -------- | | -------- |
| ns-3 | | ns-3 |
| خالص | | خالص |
| دستگاه | | دستگاه |
+----------+ +----------+
|| ||
+----------------------------+
| کانال ns-3 |
+----------------------------+

در این مورد، "دستگاه شبکه ns-3" در "گره شبح" به نظر می رسد که واقعاً
جایگزینی دستگاه TAP در هاست لینوکس. شبیه سازی ns-3 دستگاه TAP را روشن می کند
سیستم عامل لینوکس زیرین و آدرس های IP و MAC دستگاه TAP را برای مطابقت پیکربندی می کند
مقادیر اختصاص داده شده به دستگاه شبکه شبیه سازی شده ns-3. پیوند "IPC" نشان داده شده در بالا همان است
مکانیسم ضربه زدن به شبکه در سیستم عامل اصلی کل چیدمان به عنوان یک قرارداد متعارف عمل می کند
پل؛ اما پلی بین دستگاه هایی که اتفاقا دارای MAC و IP مشترک هستند
آدرس.

در اینجا، کاربر نیازی به ارائه هیچ گونه اطلاعات پیکربندی خاص برای آن ندارد
ضربه زدن. یک دستگاه شیر توسط ns-3 مطابق پیش‌فرض‌های آن ایجاد و پیکربندی می‌شود
دستگاه شیر با توجه به سیستم عامل اصلی نام خود را تعیین می کند
پیش فرض های آن

اگر کاربر نیازی به دسترسی به دستگاه شیر ایجاد شده داشته باشد، می تواند به صورت اختیاری
یک ویژگی "DeviceName" ارائه دهید. در این صورت، دستگاه تپ سیستم عامل ایجاد شده نامگذاری می شود
بر این اساس.

حالت ConfigureLocal حالت عملکرد پیش فرض Tap Bridge است.

TapBridge UseLocal حالت
حالت UseLocal کاملاً شبیه حالت ConfigureLocal است. تفاوت قابل توجه
همانطور که از نام حالت پیداست، TapBridge قرار است از یک دستگاه شیر موجود "استفاده" کند
قبلا توسط کاربر ایجاد و پیکربندی شده است. این حالت به ویژه زمانی مفید است که a
طرح مجازی سازی به طور خودکار دستگاه های ضربه ای را ایجاد می کند و از ns-3 برای ارائه استفاده می شود
شبکه های شبیه سازی شده برای آن دستگاه ها

+--------+
| لینوکس |
| میزبان | +----------+
| ------ | | روح |
| برنامه ها | | گره |
| ------ | | -------- |
| پشته | | IP | +----------+
| ------ | | پشته | | گره |
| TAP | |==========| | -------- |
| دستگاه | <----- IPC ------> | ضربه بزنید | | IP |
| مک ایکس | | پل | | پشته |
+--------+ | -------- | | -------- |
| ns-3 | | ns-3 |
| خالص | | خالص |
| دستگاه | | دستگاه |
| MAC Y | | MAC Z |
+----------+ +----------+
|| ||
+----------------------------+
| کانال ns-3 |
+----------------------------+

در این حالت، آدرس MAC از پیش پیکربندی شده «دستگاه ضربه بزنید» (MAC X)
مانند دستگاه پل شده "ns-3 net device" (MAC Y) که در تصویر بالا نشان داده شده است. که در
برای اتصال به دستگاه های شبکه ns-3 که از SendFrom() پشتیبانی نمی کنند (مخصوصاً بی سیم
گره‌های STA) شرطی را تحمیل می‌کنیم که فقط یک دستگاه لینوکس (با یک آدرس MAC منحصربه‌فرد).
-- در اینجا X) ترافیکی را ایجاد می کند که در سراسر پیوند IPC جریان دارد. این به این دلیل است که MAC
آدرس‌های ترافیک در سراسر پیوند IPC "جعلی" یا تغییر می‌کنند تا به نظر برسد
لینوکس و ns-3 که آدرس یکسانی دارند. یعنی ترافیک از لینوکس در حال حرکت است
میزبان گره شبح ns-3 آدرس MAC آن از X به Y و ترافیک از آن تغییر می کند
گره شبح میزبان لینوکس آدرس MAC خود را از Y به X تغییر خواهد داد
یک مکاتبات یک به یک بین دستگاه ها وجود دارد، ممکن است فقط یک منبع MAC وجود داشته باشد
از سمت لینوکس جاری می شود. این بدان معناست که لینوکس با بیش از یک دستگاه نت پل می شود
اضافه شده با حالت UseLocal ناسازگار است.

در حالت UseLocal، از کاربر انتظار می رود که یک دستگاه شیر را به طور کامل ایجاد و پیکربندی کند
خارج از محدوده شبیه سازی ns-3 با استفاده از چیزی شبیه به:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 hw ether 08:00:2e:00:00:01
$ sudo ifconfig tap0 10.1.1.1 netmask 255.255.255.0 بالا

برای اینکه به TapBridge بگوید چه اتفاقی می‌افتد، کاربر مستقیماً یکی از این دو را تنظیم می‌کند
TapBridge یا از طریق TapBridgeHelper، ویژگی "DeviceName". در مورد
در پیکربندی بالا، ویژگی «DeviceName» روی «tap0» و «Mode» تنظیم می‌شود.
ویژگی روی "UseLocal" تنظیم می شود.

یکی از موارد استفاده خاص برای این حالت در محیط OpenVZ است. آنجا امکان پذیر است
برای ایجاد یک دستگاه Tap در "گره سخت افزار" و انتقال آن به یک سرور خصوصی مجازی.
اگر TapBridge بتواند از یک دستگاه شیر موجود استفاده کند، می توان از آن اجتناب کرد
سربار یک پل سیستم عامل در آن محیط.

TapBridge استفاده از پل حالت
ساده ترین حالت برای کسانی که با شبکه های لینوکس آشنا هستند، حالت UseBridge است. از نو،
پیشوند "Use" نشان می دهد که TapBridge قرار است از یک پیکربندی موجود استفاده کند.
در این مورد، TapBridge به طور منطقی یک پل لینوکس را به ns-3 گسترش می دهد.

این در زیر نشان داده شده است:

+---------+
| لینوکس | +----------+
| ------- | | روح |
| برنامه ها | | گره |
| ------- | | -------- |
| پشته | | IP | +----------+
| ------- | +--------+ | پشته | | گره |
| مجازی | | TAP | |==========| | -------- |
| دستگاه | | دستگاه | <---- IPC -----> | ضربه بزنید | | IP |
+---------+ +--------+ | پل | | پشته |
|| || | -------- | | -------- |
+--------------------+ | ns-3 | | ns-3 |
| سیستم عامل (brctl) Bridge | | خالص | | خالص |
+--------------------+ | دستگاه | | دستگاه |
+----------+ +----------+
|| ||
+----------------------------+
| کانال ns-3 |
+----------------------------+

در این حالت، رایانه ای که برنامه های لینوکس، پروتکل ها و غیره را اجرا می کند، به a متصل می شود
ns-3 شبکه را به گونه‌ای شبیه‌سازی کرد که برای میزبان لینوکس به نظر برسد که TAP
دستگاه یک دستگاه شبکه واقعی است که در پل لینوکس شرکت می کند.

در شبیه سازی ns-3، یک TapBridge برای مطابقت با هر دستگاه TAP ایجاد می شود. نام
دستگاه TAP با استفاده از ویژگی "DeviceName" به Tap Bridge اختصاص داده می شود. TapBridge
سپس به طور منطقی پل سیستم عامل را گسترش می دهد تا دستگاه شبکه ns-3 را در بر بگیرد.

از آنجایی که این حالت به طور منطقی یک پل سیستم عامل را گسترش می دهد، ممکن است دستگاه های شبکه لینوکس زیادی روی آن وجود داشته باشد
غیر ns-3 سمت پل. بنابراین، مانند یک دستگاه شبکه بر روی هر پل، شبکه ns-3
دستگاه باید با احتمالاً بسیاری از آدرس های منبع سروکار داشته باشد. بنابراین، دستگاه های ns-3 باید
پشتیبانی از SendFrom() (NetDevice::SupportsSendFrom() باید true باشد) تا
برای استفاده در حالت UseBridge پیکربندی شده است.

انتظار می رود که کاربر برای پیکربندی پل کاری شبیه به زیر انجام دهد
و کاملاً خارج از ns-3 ضربه بزنید:

$ sudo brctl addbr mybridge
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw ether 00:00:00:00:00:01
$ sudo ifconfig mytap 0.0.0.0 up
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge ...
$ sudo ifconfig mybridge 10.1.1.1 netmask 255.255.255.0 بالا

برای اینکه به TapBridge بگوید چه اتفاقی می‌افتد، کاربر مستقیماً یکی از این دو را تنظیم می‌کند
TapBridge یا از طریق TapBridgeHelper، ویژگی "DeviceName". در مورد
در پیکربندی بالا، ویژگی "DeviceName" روی "mytap" و "Mode" تنظیم می شود.
ویژگی بر روی "UseBridge" تنظیم می شود.

این حالت به ویژه در مورد مجازی سازی که در آن پیکربندی شده است مفید است
هاست های مجازی ممکن است توسط سیستم دیگری دیکته شوند و برای ns-3 قابل تغییر نباشند.
به عنوان مثال، یک طرح VM خاص ممکن است دستگاه های مجازی "vethx" یا "vmnetx" ایجاد کند که
برای میزبان های مجازی محلی ظاهر شود. برای اتصال به چنین سیستم هایی، نیاز است
به صورت دستی دستگاه‌های TAP را در سیستم میزبان ایجاد کنید و این دستگاه‌های TAP را به آن متصل کنید
دستگاه های مجازی موجود (VM). وظیفه Tap Bridge در این مورد، گسترش آن است
پل برای پیوستن به یک دستگاه شبکه ns-3.

TapBridge ConfigureLocal عمل
در حالت ConfigureLocal، TapBridge و بنابراین دستگاه شبکه ns-3 مرتبط با آن ظاهر می شود
به کامپیوتر میزبان لینوکس به عنوان یک دستگاه شبکه درست مانند هر "eth0" یا "ath0" دلخواه
ممکن است ظاهر شود ایجاد و پیکربندی دستگاه TAP توسط ns-3 انجام می شود
شبیه سازی و هیچ پیکربندی دستی توسط کاربر مورد نیاز نیست. آدرس های IP، MAC
آدرس ها، دروازه ها و غیره برای دستگاه های TAP ایجاد شده از شبیه سازی استخراج می شوند
خود را با جستجو در پیکربندی دستگاه ns-3 و ویژگی های TapBridge.

از آنجایی که آدرس های MAC در سمت لینوکس و سمت ns-3 یکسان هستند، می توانیم از آن استفاده کنیم
Send() در دستگاه ns-3 که در تمام دستگاه های ns-3 net موجود است. از زمان MAC
آدرس‌ها یکسان هستند و نیازی به اتصال تماس‌های غیرقانونی به آن نیست
سمت دریافت بنابراین هیچ محدودیتی در مورد انواع دستگاه های شبکه وجود ندارد
قابل استفاده در حالت ConfigureLocal.

TapBridge در یک شبیه سازی ns-3 به عنوان یک دستگاه شبکه بدون کانال به نظر می رسد. این دستگاه
نباید یک آدرس IP مرتبط با آن داشته باشد، اما دستگاه شبکه پل شده (ns-3) باید داشته باشد
یک آدرس IP داشته باشید توجه داشته باشید که این برعکس ns-3 BridgeNetDevice (یا a
پل معمولی به طور کلی) که می طلبد پورت های پل آن آدرس IP نداشته باشند،
اما به خود دستگاه پل اجازه می دهد تا یک آدرس IP داشته باشد.

کامپیوتر میزبان در یک شبیه سازی به عنوان یک گره "شبح" که شامل یک گره است ظاهر می شود
TapBridge برای هر NetDevice که در حال پل زدن است. از منظر شبیه سازی،
تنها تفاوت بین گره شبح و هر گره دیگری وجود گره است
دستگاه های TapBridge. البته توجه داشته باشید که وجود TapBridge بر روی آن تأثیر می گذارد
اتصال دستگاه شبکه به پشته IP گره شبح.

پیکربندی اطلاعات آدرس و دستگاه های ns-3 به هیچ وجه تغییر نمی کند اگر الف
TapBridge وجود دارد. یک TapBridge اطلاعات آدرس دهی را از ns-3 دریافت می کند
دستگاه شبکه ای که به آن متصل است (دستگاه شبکه «پلی شده» آن) و از آن اطلاعات استفاده کنید
دستگاه TAP را روی میزبان واقعی ایجاد و پیکربندی کنید.

نتیجه نهایی این وضعیتی است که می توان برای مثال از پینگ استاندارد استفاده کرد
ابزاری در میزبان واقعی برای پینگ کردن یک گره ns-3 شبیه سازی شده. اگر مسیرهای صحیح به آن اضافه شود
میزبان اینترنت (انتظار می‌رود این کار به صورت خودکار در نسخه‌های بعدی ns-3 انجام شود)،
سیستم های مسیریابی در ns-3 مسیریابی صحیح بسته ها را در سراسر ns-3 شبیه سازی شده امکان پذیر می کند.
شبکه های. برای نمونه ای از این، به برنامه مثال ضربه بزنید-wifi-dumbbell.cc در
توزیع ns-3.

Tap Bridge در نوعی دنیای خاکستری در جایی بین میزبان لینوکس و ns-3 زندگی می کند
دستگاه پل از دیدگاه لینوکس، این کد به عنوان کنترل کننده حالت کاربر ظاهر می شود
یک دستگاه شبکه TAP. در حالت ConfigureLocal، این دستگاه Tap به طور خودکار توسط
شبیه سازی ns-3 هنگامی که میزبان لینوکس به یکی از این موارد به طور خودکار ایجاد می شود می نویسد
/dev/tap دستگاه‌ها، نوشتن به TapBridge هدایت می‌شود که در دنیای ns-3 زندگی می‌کند.
و از این منظر، بسته نوشتن در لینوکس تبدیل به یک بسته خوانده شده در Tap می شود
پل. به عبارت دیگر، یک فرآیند لینوکس یک بسته را به یک دستگاه تپ و این بسته می نویسد
توسط مکانیسم تپ شبکه به فرآیند ns-3 هدایت می شود که توسط آن دریافت می شود
TapBridge در نتیجه یک عملیات خواندن وجود دارد. سپس TapBridge بسته را در آن می نویسد
دستگاه شبکه ns-3 که به آن پل متصل شده است. و بنابراین به نظر می رسد که میزبان لینوکس است
یک بسته را مستقیماً از طریق یک دستگاه شبکه ns-3 به شبکه ns-3 ارسال کرد.

در جهت دیگر، یک بسته دریافت شده توسط دستگاه شبکه ns-3 متصل به Tap
Bridge از طریق دریافت پاسخ به TapBridge ارسال می شود. سپس TapBridge آن را می گیرد
بسته را ارسال می کند و با استفاده از مکانیسم ضربه زدن به شبکه آن را به هاست باز می نویسد. این را به
دستگاه طوری به میزبان لینوکس ظاهر می شود که گویی بسته ای به یک دستگاه نت رسیده است. و
بنابراین گویی یک بسته دریافتی توسط دستگاه شبکه ns-3 در طول شبیه سازی ظاهر شده است
در یک دستگاه نت واقعی لینوکس.

نتیجه این است که به نظر می‌رسد Tap Bridge یک دستگاه ضربه‌ای را روی یک میزبان لینوکس پل می‌کند
"دنیای واقعی" به یک دستگاه شبکه ns-3 در شبیه سازی. زیرا دستگاه TAP و
دستگاه شبکه bridged ns-3 دارای آدرس MAC یکسانی است و پیوند IPC تپ شبکه ندارد
خارجی، این نوع خاص از پل به نظر می رسد که یک دستگاه شبکه ns-3 است
در واقع در هاست لینوکس نصب شده است.

برای پیاده سازی این مورد در سمت ns-3، ما به یک "گره شبح" در شبیه سازی نیاز داریم.
دستگاه خالص ns-3 و TapBridge را نگه دارید. این گره در واقع نباید انجام دهد
هر چیز دیگری در شبیه سازی، زیرا وظیفه آن صرفاً نشان دادن دستگاه شبکه در داخل است
لینوکس. این فقط یک سیاست دلخواه نیست، به این دلیل است که:

· بیت های ارسال شده به TapBridge از لایه های بالاتر در گره شبح (با استفاده از TapBridge
روش ارسال) به طور کامل نادیده گرفته می شوند. TapBridge به خودی خود به هیچ کدام متصل نیست
شبکه، نه در لینوکس و نه در ns-3. شما هرگز نمی توانید داده ها را از طریق a ارسال یا دریافت کنید
بریج را از گره شبح تپ کنید.

· ارتباط دستگاه شبکه ns-3 بریج شده از گره ns-3 قطع شده است.
دوباره به Tap Bridge متصل شد. سپس تمام داده های دریافت شده توسط یک دستگاه پل شده ارسال می شود
به هاست لینوکس و توسط گره دریافت نخواهد شد. از دیدگاه
گره شبح، شما می توانید از طریق این دستگاه ارسال کنید اما هرگز نمی توانید دریافت کنید.

البته، اگر همه مسائل را درک کنید، می توانید کنترل سرنوشت خود را به دست بگیرید
و هر کاری که می خواهید انجام دهید -- ما به طور فعال مانع از استفاده شما از گره شبح نمی شویم
هر چیزی که شما تصمیم بگیرید شما قادر خواهید بود عملیات معمولی ns-3 را روی شبح انجام دهید
گره در صورت تمایل به عنوان مثال، پشته اینترنت باید وجود داشته باشد و فعال باشد
آن گره به منظور مشارکت در تخصیص آدرس IP و مسیریابی جهانی. با این حال،
همانطور که در بالا ذکر شد، اینترفیس ها با هر TapBridge یا دستگاه های شبکه متصل شده مرتبط با آن صحبت می کنند
به طور کامل کار نخواهد کرد. اگر دقیقاً متوجه شده اید که چه کاری انجام می دهید، می توانید راه اندازی کنید
سایر رابط ها و دستگاه های موجود در گره شبح و استفاده از آنها. یا از مزیت استفاده کنید
سمت ارسال عملیاتی دستگاه های پل شده برای ایجاد مولدهای ترافیک. ما به طور کلی
توصیه می کنیم که این گره را به عنوان شبح میزبان لینوکس در نظر بگیرید و آن را به حال خود رها کنید.
گرچه.

TapBridge UseLocal حالت عمل
همانطور که در بالا توضیح داده شد، TapBridge مانند پلی از دنیای "واقعی" به جهان عمل می کند
دنیای ns-3 شبیه سازی شده در مورد حالت ConfigureLocal، زندگی از زمان IP آسان است
آدرس دستگاه Tap با آدرس IP دستگاه ns-3 و آدرس MAC مطابقت دارد
دستگاه Tap با آدرس MAC دستگاه ns-3 مطابقت دارد. و یک به یک وجود دارد
ارتباط بین دستگاه ها

وقتی دستگاه Tap به صورت خارجی با a پیکربندی شده باشد، اوضاع کمی پیچیده می شود
آدرس مک متفاوت از دستگاه شبکه ns-3. روش مرسوم برای مقابله با این
یک نوع تفاوت در استفاده از حالت بی بند و بار در دستگاه پل شده برای دریافت بسته ها است
برای آدرس MAC مختلف و ارسال آنها به لینوکس. به منظور حرکت
بسته ها از طرف دیگر، راه حل معمولی SendFrom() است که به تماس گیرنده اجازه می دهد
"جعل" یا آدرس MAC منبع را تغییر دهید تا با آدرس MAC مختلف لینوکس مطابقت داشته باشد.

ما نیاز خاصی داریم تا بتوانیم ماشین های مجازی لینوکس را به آن متصل کنیم
گره های STA بی سیم متأسفانه، مشخصات 802.11 راه خوبی برای این کار ارائه نمی دهد
SendFrom() را پیاده سازی کنید، بنابراین باید آن مشکل را حل کنیم.

برای این منظور حالت UseLocal Tap Bridge را ارائه کردیم. این حالت به شما اجازه می دهد
طوری به مشکل برخورد کنید که انگار با یک دستگاه شبکه یک پل ایجاد می کنید. یک مجرد
آدرس مجاز در سمت لینوکس در TapBridge به خاطر سپرده می شود، و تمام بسته های ارسال می شوند
از سمت لینوکس، سمت ns-3 با استفاده از منبع MAC دستگاه ns-3 تکرار می شود
نشانی. تمام بسته هایی که از سمت ns-3 وارد می شوند با استفاده از سمت لینوکس تکرار می شوند
آدرس مک به خاطر سپرده شده این به ما امکان می دهد از Send() در سمت دستگاه ns-3 استفاده کنیم
در تمام دستگاه های شبکه ns-3 موجود است.

حالت UseLocal با حالت ConfigureLocal یکسان است به جز ایجاد و
پیکربندی دستگاه شیر و جعل آدرس MAC.

TapBridge استفاده از پل عمل
همانطور که در بخش ConfigureLocal mode توضیح داده شد، زمانی که هاست لینوکس به یکی از موارد می نویسد
/dev/tap دستگاه‌ها، نوشتن به TapBridge هدایت می‌شود که در دنیای ns-3 زندگی می‌کند.
در مورد حالت UseBridge، این بسته ها باید در ns-3 ارسال شوند
شبکه به گونه ای که گویی بر روی دستگاهی که در پل لینوکس شرکت دارد ارسال شده اند. این یعنی
فراخوانی متد SendFrom() در دستگاه پل شده و ارائه آدرس MAC منبع
در بسته پیدا شد

در جهت دیگر، بسته ای که توسط یک دستگاه شبکه ns-3 دریافت می شود، از طریق تماس برگشتی به
TapBridge این باید در حالت بی‌وقفه انجام شود، زیرا هدف پل زدن ns-3 است
دستگاه شبکه روی پل سیستم عامل (brctl) که دستگاه TAP بخشی از آن است.

به این دلایل، فقط دستگاه‌های شبکه ns-3 که از SendFrom() پشتیبانی می‌کنند و دارای هوک‌پذیر هستند
پاسخ تماس دریافتی بی‌وقفه مجاز به شرکت در حالت UseBridge TapBridge هستند
پیکربندی.

شیر پل کانال مدل
هیچ مدل کانالی مرتبط با Tap Bridge وجود ندارد. در واقع نیت ساختن است
به نظر می رسد که هاست اینترنتی واقعی به کانال شبکه بریج متصل است
دستگاه.

شیر پل ردیابی مدل
برخلاف اکثر دستگاه‌های ns-3، TapBridge هیچ منبع ردیابی استانداردی ارائه نمی‌کند. این
به این دلیل است که پل یک واسطه است که اساساً یک تابع از آن فاصله دارد
دستگاه پل شده ما انتظار داریم که قلاب های ردیابی در دستگاه بریج شده باشد
برای اکثر کاربران کافی است،

با استفاده از la TapBridge
ما انتظار داریم که اکثر کاربران با دستگاه TapBridge از طریق ارتباط برقرار کنند
روی BridgeHelper ضربه بزنید. کاربران سایر کلاس های کمکی، مانند CSMA یا Wifi، باید باشند
با اصطلاحات استفاده شده در آنجا راحت است.

ENERGY چارچوب

مصرف انرژی یک مسئله کلیدی برای دستگاه های بی سیم و محققان شبکه های بی سیم است
اغلب نیاز به بررسی مصرف انرژی در یک گره یا در کل شبکه در حالی است
اجرای شبیه سازی شبکه در ns-3. این به ns-3 برای پشتیبانی از مصرف انرژی نیاز دارد
مدل سازی علاوه بر این، همانطور که مفاهیمی مانند سلول های سوختی و مهار انرژی در حال تبدیل شدن هستند
قابل اجرا برای دستگاه های بی سیم کم توان، با ترکیب اثر این در حال ظهور
فناوری‌ها در شبیه‌سازی نیاز به پشتیبانی برای مدل‌سازی منابع انرژی متنوع در آن دارند
ns-3. چارچوب انرژی ns-3 اساس مصرف انرژی، منبع انرژی را فراهم می کند
و مدل سازی برداشت انرژی

مدل توضیحات:
کد منبع برای چارچوب انرژی در حال حاضر در: src/انرژی.

طرح
چارچوب انرژی ns-3 از 3 بخش تشکیل شده است: منبع انرژی، مدل انرژی دستگاه و
برداشت انرژی. چارچوب در اجرا شده است SRC/انرژی/مدل ها پوشه.

انرژی منبع
منبع انرژی منبع تغذیه هر گره را نشان می دهد. یک گره می تواند یک یا چند داشته باشد
منابع انرژی، و هر منبع انرژی را می توان به چندین مدل انرژی دستگاه متصل کرد.
اتصال یک منبع انرژی به یک مدل انرژی دستگاه دلالت بر این دارد که دستگاه مربوطه
از منبع نیرو می گیرد. کارکرد اصلی منبع انرژی ارائه است
انرژی برای دستگاه های روی گره هنگامی که انرژی به طور کامل از منبع انرژی تخلیه می شود،
به دستگاه های روی گره اطلاع می دهد تا هر دستگاه بتواند به این رویداد واکنش نشان دهد. به علاوه،
هر گره می تواند برای اطلاعاتی مانند انرژی باقیمانده یا به اشیاء منبع انرژی دسترسی داشته باشد
کسر انرژی (سطح باتری). این امکان اجرای پروتکل های آگاه از انرژی را فراهم می کند
در ns-3.

به منظور مدل سازی طیف گسترده ای از منابع تغذیه مانند باتری ها، منبع انرژی باید
بتواند ویژگی های این لوازم را به تصویر بکشد. 2 مورد مهم وجود دارد
ویژگی ها یا اثرات مربوط به باتری های کاربردی:

نرخ ظرفیت اثر
کاهش طول عمر باتری زمانی که مصرف جریان بیشتر از مقدار نامی باشد
باتری

بهبود اثر
افزایش طول عمر باتری زمانی که باتری به طور متناوب بین دشارژ و
حالت های بیکار

برای گنجاندن اثر ظرفیت نرخ، منبع انرژی از برداشت جریان استفاده می کند
تمام دستگاه های روی یک گره برای محاسبه مصرف انرژی. علاوه بر این، متعدد
برداشت انرژی را می توان به منبع انرژی متصل کرد تا انرژی آن را دوباره پر کند.
منبع انرژی به صورت دوره‌ای از همه دستگاه‌ها و برداشت‌کننده‌های انرژی روی یکسان نظرسنجی می‌کند
گره برای محاسبه تخلیه کل جریان و در نتیجه مصرف انرژی. هنگامی که یک دستگاه
تغییر وضعیت، مدل انرژی دستگاه مربوطه آن منبع انرژی را از این موضوع مطلع خواهد کرد
تغییر و مجموع قرعه کشی جدید محاسبه خواهد شد. به طور مشابه، هر برداشت کننده انرژی
به‌روزرسانی، به‌روزرسانی منبع انرژی متصل را آغاز می‌کند.

کلاس پایه انرژی منبع لیستی از دستگاه ها (اشیاء مدل انرژی دستگاه) و
برداشت‌کننده‌های انرژی (اشیاء Energy Harvester) که از منبع انرژی خاصی استفاده می‌کنند
به عنوان منبع تغذیه هنگامی که انرژی به طور کامل تخلیه شد، منبع انرژی به همه اطلاع خواهد داد
دستگاه های موجود در این لیست سپس هر دستگاه می تواند این رویداد را به طور مستقل، بر اساس
رفتار مطلوبی که در صورت قطع برق باید رعایت شود.

دستگاه انرژی مدل
مدل انرژی دستگاه، مدل مصرف انرژی یک دستگاه نصب شده بر روی گره است.
این به گونه ای طراحی شده است که یک مدل مبتنی بر حالت باشد که در آن هر دستگاه دارای تعدادی از فرض می شود
وضعیت می شود و هر حالت با مقدار مصرف برق مرتبط است. هر زمان که حالت از
دستگاه تغییر می کند، مدل انرژی دستگاه مربوطه به منبع انرژی اطلاع می دهد
قرعه کشی فعلی جدید دستگاه سپس منبع انرژی کل جدید را محاسبه خواهد کرد
انرژی باقیمانده را بکشید و به روز کنید.

مدل انرژی دستگاه را می توان برای دستگاه هایی که تعداد محدودی ندارند نیز استفاده کرد
ایالت ها. به عنوان مثال، در یک وسیله نقلیه الکتریکی، کشش جریان موتور تعیین می شود
با سرعتش از آنجایی که سرعت وسیله نقلیه می تواند مقادیر پیوسته ای را در محدوده خاصی داشته باشد،
تعریف مجموعه ای از حالت های عملیات گسسته غیرممکن است. با این حال، با تبدیل
مقدار سرعت را به طور مستقیم به جریان، همان مجموعه ای از API های مدل انرژی دستگاه هنوز هم می تواند
استفاده شود

انرژی برداشت
برداشت کننده انرژی نشان دهنده عناصری است که انرژی را از محیط و
منبع انرژی که به آن متصل است را شارژ کنید. برداشت انرژی شامل
اجرای کامل دستگاه واقعی برداشت انرژی (به عنوان مثال، یک پنل خورشیدی) و
محیط زیست (به عنوان مثال، تابش خورشیدی). این بدان معناست که در اجرای یک انرژی
برداشت، سهم انرژی محیط زیست و انرژی اضافی
الزامات دستگاه برداشت انرژی مانند راندمان تبدیل و
مصرف برق داخلی دستگاه نیاز به مدل سازی مشترک دارد.

اینترنت بی سیم رادیو انرژی مدل
مدل انرژی رادیویی WiFi مدل مصرف انرژی یک دستگاه شبکه Wifi است. آی تی
یک حالت برای هر یک از حالت های موجود لایه PHY ارائه می دهد: Idle، CcaBusy، Tx، Rx،
ChannelSwitch، Sleep. هر یک از این حالت ها با یک مقدار (در آمپر) از
قرعه کشی فعلی (برای نام ویژگی های مربوطه به زیر مراجعه کنید). یک مدل انرژی رادیویی Wifi
PHY Lister در Wifi PHY ثبت شده است تا از هر وضعیت Wifi PHY مطلع شود.
انتقال در هر انتقال، انرژی مصرف شده در حالت قبلی محاسبه می شود و
منبع انرژی به منظور به روز رسانی انرژی باقی مانده خود مطلع می شود.

مدل Wifi Tx Current این امکان را به شما می دهد که کشش فعلی را محاسبه کنید
حالت انتقال به عنوان تابعی از توان اسمی tx (بر حسب dBm)، همانطور که در چندین مورد مشاهده شد
اندازه گیری های تجربی برای این منظور، Wifi Radio Energy Model PHY listener می باشد
از توان اسمی tx که برای انتقال فریم فعلی استفاده می شود مطلع می شود و چنین می کند
مقدار مدل فعلی Wifi Tx که وظیفه به روز رسانی قرعه کشی فعلی در Tx را بر عهده دارد
حالت. از این رو، حتی اگر ایستگاه راه دور Wifi باشد، مصرف انرژی به درستی محاسبه می شود
مدیر کنترل قدرت هر فریم را انجام می دهد. در حال حاضر، یک مدل خطی Wifi Tx Current است
پیاده سازی شده است که جریان tx را به عنوان یک تابع خطی (بر اساس پارامترها) محاسبه می کند
که می تواند توسط کاربر مشخص شود) توان اسمی tx در dBm.

مدل انرژی رادیویی Wifi این امکان را برای تعیین یک تماس فراخوانی ارائه می دهد
زمانی که منبع انرژی تمام می شود. اگر چنین تماسی مشخص نشده است که فای
کمک کننده مدل انرژی رادیویی برای نصب مدل بر روی یک دستگاه استفاده می شود، یک کال بک است
بطور ضمنی طوری ساخته شده است که Wifi PHY در حالت SLEEP قرار می گیرد (بنابراین هیچ فریمی وجود ندارد
زمانی که منبع انرژی تمام می شود، منتقل یا دریافت می شود. همین طور است
امکان تعیین یک تماس برگشتی که هنگام شارژ مجدد منبع انرژی فراخوانی می شود (که
ممکن است در صورت اتصال یک برداشت کننده انرژی به منبع انرژی رخ دهد). اگر چنین است
هنگامی که از راهنما مدل انرژی رادیویی Wifi برای نصب استفاده می شود، پاسخ تماس مشخص نشده است
مدل بر روی یک دستگاه، به طور ضمنی یک تماس پاسخ داده می شود تا Wifi PHY از سر گرفته شود.
حالت SLEEP هنگامی که منبع انرژی شارژ می شود.

آینده مهاجرت کاری
برای مدل‌های انرژی دستگاه، ما در حال برنامه‌ریزی برای ارائه پشتیبانی از سایر مدل‌های لایه PHY هستیم
ارائه شده در ns-3 مانند وایمکس، و برای مدل سازی مصرف انرژی سایر غیر
دستگاه های ارتباطی، مانند یک سنسور عمومی و یک CPU. برای منابع انرژی، ما هستیم
برنامه ریزی برای گنجاندن انواع جدیدی از منابع انرژی مانند ابرخازن و نیکل-فلز
باتری هیدرید (Ni-MH). برای برداشت انرژی، ما در حال برنامه ریزی برای اجرای انرژی هستیم
برداشت کننده که منابع انرژی را با توجه به سطوح توان تعریف شده در الف شارژ می کند
مجموعه داده های قابل تنظیم توسط کاربر از اندازه گیری های واقعی.

منابع
[1] مدل انرژی ns-2:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu، S. Nabar و R. Poovendran. چارچوب انرژی برای شبیه ساز شبکه 3
(ns-3).

[3] M. Handy و D. Timmermann. شبیه سازی شبکه های بی سیم موبایل با دقت
مدل سازی اثرات باتری غیر خطی در Proc. شبیه سازی و مدل سازی کاربردی
(ASM)، 2003.

[4] DN Rakhmatov و SB Vrudhula. یک مدل باتری سطح بالا تحلیلی برای استفاده در
مدیریت انرژی سیستم های الکترونیکی قابل حمل در Proc. از IEEE/ACM International
کنفرانس طراحی به کمک کامپیوتر (ICCAD'01)، صفحات 488-493، نوامبر 2001.

[5] DN Rakhmatov، SB Vrudhula، و DA Wallach. پیش بینی طول عمر باتری برای
محاسبات آگاه از انرژی در Proc. سمپوزیوم بین المللی انرژی کم در سال 2002
الکترونیک و طراحی (ISLPED'02)، صفحات 154-159، 2002.

[6] سی تاپارلو، اچ. آیت اللهی و دبلیو. هاینزلمن. گسترش چارچوب انرژی برای
شبیه ساز شبکه 3 (ns-3). کارگاه آموزشی ns-3 (WNS3)، جلسه پوستر، آتلانتا، GA،
ایالات متحده آمریکا. مه، 2014.

استفاده
راه اصلی که کاربران ns-3 معمولاً با چارچوب انرژی تعامل خواهند داشت از طریق آن است
API کمکی و از طریق ویژگی های قابل مشاهده عمومی چارچوب. یاور
API در تعریف شده است src/energy/helper/*.h.

برای استفاده از چارچوب انرژی، کاربر باید یک منبع انرژی برای گره نصب کند
مورد علاقه، مدل انرژی دستگاه مربوطه برای دستگاه های شبکه و اگر
لازم است، یک یا چند دستگاه برداشت کننده انرژی. منبع انرژی (اشیاء) روی آنها جمع می شوند
هر گره توسط کمک کننده منبع انرژی. به منظور اجازه دادن به چندین منبع انرژی در هر گره،
ما یک ظرف منبع انرژی را به جای اینکه مستقیماً یک شی منبع را جمع آوری کنیم، جمع می کنیم.

شی منبع انرژی فهرستی از اشیاء مدل انرژی دستگاه و انرژی برداشت کننده را نگه می دارد
استفاده از منبع به عنوان منبع تغذیه اشیاء مدل انرژی دستگاه بر روی دستگاه نصب می شوند
منبع انرژی توسط Device Energy Model Helper، در حالی که شیء Energy Harvester هستند
نصب شده توسط Energy Harvester Helper. کاربر می تواند به اشیاء مدل انرژی دستگاه دسترسی داشته باشد
از طریق شی منبع انرژی برای به دست آوردن اطلاعات مصرف انرژی فرد
دستگاه ها علاوه بر این، کاربر می تواند برای جمع آوری به اشیاء Energy Harvester دسترسی داشته باشد
اطلاعات مربوط به توان قابل برداشت فعلی و کل انرژی برداشت شده توسط
دروگر

مثال ها
دایرکتوری های مثال، src/نمونه ها/انرژی و مثال ها / انرژی، حاوی چند کد اساسی است
که نحوه تنظیم چارچوب را نشان می دهد.

یاران
انرژی منبع کمک کننده
کلاس کمکی پایه برای اشیاء منبع انرژی، این کمک کننده شی منبع انرژی را جمع می کند
روی یک گره پیاده سازی فرزند این کلاس، شی منبع انرژی واقعی را ایجاد می کند.

دستگاه انرژی مدل کمک کننده
کلاس کمکی پایه برای اشیاء مدل انرژی دستگاه، این کمک کننده Device Energy را متصل می کند
اشیاء را بر روی اشیاء منبع انرژی مدل کنید. اجرای کودک این کلاس را ایجاد می کند
شی واقعی مدل انرژی دستگاه.

انرژی جمع آوری کمک کننده
کلاس کمکی پایه برای اشیاء Energy Harvester، این کمک کننده Energy Harvester را متصل می کند
اشیاء بر روی اشیاء منبع انرژی اجرای کودک این کلاس، واقعی را ایجاد می کند
شیء انرژی برداشت.

خواص
ویژگی ها بین منابع انرژی، مدل های انرژی دستگاه ها و برداشت کننده های انرژی متفاوت است
برای جزئیات، لطفاً به کلاس کودک خاص نگاه کنید.

اساسی انرژی منبع
· BasicEnergySourceInitialEnergyJ: انرژی اولیه ذخیره شده در منبع انرژی پایه.

· BasicEnergySupplyVoltageV: ولتاژ تغذیه اولیه برای منبع انرژی پایه.

· PeriodicEnergyUpdateInterval: زمان بین دو به روز رسانی انرژی دوره ای متوالی.

RV باتری مدل
· RvBatteryModelPeriodicEnergyUpdateInterval: فاصله نمونه برداری مدل باتری RV.

· RvBatteryModelOpenCircuit Voltage: ولتاژ مدار باز مدل باتری RV.

· RvBatteryModelCutoff Voltage: ولتاژ قطع باتری مدل RV.

· RvBatteryModelAlphaValue: باتری RV مدل آلفا مقدار.

· RvBatteryModelBetaValue: مدل باتری RV مقدار بتا.

· RvBatteryModelNumOfTerms: تعداد عبارت های حاصل جمع بی نهایت برای تخمین باتری
سطح.

اینترنت بی سیم رادیو انرژی مدل
· IdleCurrentA: جریان پیش فرض رادیویی Idle در آمپر.

· ccabusycurrenta: جریان رادیویی پیش فرض CCA حالت اشغال در آمپر.

· TxCurrentA: جریان رادیویی Tx در آمپر.

· RxCurrentA: جریان Rx رادیویی در آمپر.

· SwitchingCurrentA: جریان سوئیچ کانال رادیویی پیش فرض در آمپر.

· SleepCurrentA: رادیو جریان خواب در آمپر.

· مدل TxCurrent: اشاره گر به مدل فعلی tx پیوست شده.

اساسی انرژی برداشت
· PeriodicHarvestedPowerUpdateInterval: زمان بین دو به روز رسانی دوره ای متوالی از
قدرت برداشت شده

· HarvestablePower: متغیرهای تصادفی که نشان دهنده میزان توان ارائه شده است
توسط برداشت کننده انرژی

ردیابی
مقادیر ردیابی شده بین منابع انرژی، مدل های انرژی دستگاه ها و برداشت کننده های انرژی متفاوت است
برای جزئیات، لطفاً به کلاس کودک خاص نگاه کنید.

اساسی انرژی منبع
· انرژی باقیمانده: انرژی باقی مانده در BasicEnergySource.

RV باتری مدل
· RvBatteryModelBatteryLevel: سطح باتری مدل باتری RV.

· RvBatteryModelBatteryLifetime: طول عمر باتری مدل باتری RV.

اینترنت بی سیم رادیو انرژی مدل
· کل مصرف انرژی: کل انرژی مصرفی دستگاه رادیویی.

اساسی انرژی برداشت
· Harvested Power: برق فعلی ارائه شده توسط BasicEnergyHarvester.

· TotalEnergyHarvested: کل انرژی برداشت شده توسط BasicEnergyHarvester.

اعتبار
مقایسه چارچوب انرژی با دستگاه های واقعی انجام نشده است. جاری
اجرای چارچوب انرژی به صورت عددی برای خطاهای محاسباتی بررسی می شود. این
مدل باتری RV با مقایسه نتایج با آنچه در نسخه اصلی ارائه شده بود تأیید می شود
کاغذ مدل باتری RV.

FLOW مانیتور

مدل توضیحات:
کد منبع ماژول جدید در فهرست موجود است src/flow-monitor.

هدف ماژول Flow Monitor ارائه یک سیستم انعطاف پذیر برای اندازه گیری عملکرد است
پروتکل های شبکه این ماژول از پروب های نصب شده در گره های شبکه برای ردیابی استفاده می کند
بسته هایی که توسط گره ها مبادله می شوند و تعدادی پارامتر را اندازه گیری می کند. بسته ها هستند
بر اساس جریانی که به آن تعلق دارند تقسیم می‌شوند، جایی که هر جریان بر اساس آن تعریف می‌شود
ویژگی های کاوشگر (به عنوان مثال، برای IP، یک جریان به عنوان بسته هایی با همان بسته تعریف می شود
{پروتکل، منبع (IP، پورت)، مقصد (IP، پورت)} تاپل.

آمار جمع آوری شده برای هر جریان می تواند در قالب XML صادر شود. علاوه بر این،
کاربر می تواند مستقیماً به کاوشگرها دسترسی داشته باشد تا آمار خاصی در مورد هر جریان درخواست کند.

طرح
ماژول Flow Monitor به صورت ماژولار طراحی شده است. می توان آن را با زیر طبقه بندی گسترش داد
ns3::FlowProbe و ns3::FlowClassifier.

طراحی کامل ماژول در [FlowMonitor] توضیح داده شده است.

حوزه و محدودیت ها
در حال حاضر، پروب ها و طبقه بندی کننده ها برای IPv4 و IPv6 در دسترس هستند.

هر پروب بسته ها را در چهار نقطه طبقه بندی می کند:

· هنگام ارسال یک بسته (SendOutgoing IPv[4,6] traces)

· هنگامی که یک بسته ارسال می شود (ردیابی UnicastForward IPv[4,6])

· هنگامی که یک بسته دریافت می شود (ردیابی LocalDeliver IPv[4,6])

· هنگامی که یک بسته حذف می شود (ردیابی IPv[4,6] را رها کنید)

از آنجایی که بسته ها در سطح IP ردیابی می شوند، هرگونه ارسال مجدد توسط پروتکل های L4 ایجاد می شود
(به عنوان مثال، TCP) توسط پروب به عنوان یک بسته جدید دیده می شود.

یک برچسب به بسته اضافه می شود (ns3::Ipv[4,6،XNUMX]FlowProbeTag). برچسب پایه را حمل خواهد کرد
داده های بسته، برای طبقه بندی بسته مفید است.

لازم به ذکر است که تنها بسته های L4 (TCP، UDP) تا کنون طبقه بندی شده اند. علاوه بر این،
فقط بسته های unicast طبقه بندی خواهند شد. این محدودیت ها ممکن است در آینده حذف شوند.

داده های جمع آوری شده برای هر جریان عبارتند از:

· timeFirstTxPacket: زمانی که اولین بسته در جریان ارسال شد.

· timeLastTxPacket: زمانی که آخرین بسته در جریان ارسال شد.

· timeFirstRxPacket: زمانی که اولین بسته در جریان توسط یک گره پایانی دریافت شد.

· timeLastRxPacket: زمانی که آخرین بسته در جریان دریافت شد.

· delaySum: مجموع تمام تأخیرهای سرتاسری برای همه بسته های دریافتی جریان.

· jitterSum: مجموع همه مقادیر تاخیر (تغییر تاخیر) برای همه
بسته های جریان دریافتی، همانطور که در تعریف شده است RFC 3393;

· txBytes، txPackets: تعداد کل بایت ها / بسته های ارسال شده برای جریان.

· rxBytes، rxPackets: تعداد کل بایت ها / بسته های دریافتی برای جریان.

· lostPackets: تعداد کل بسته هایی که فرض می شود گم شده اند (بیش از 10 گزارش نشده است
ثانیه)؛

· timesForwarded: تعداد دفعاتی که یک بسته گزارش شده است.

· delayHistogram، jitterHistogram، packetSizeHistogram: نسخه های هیستوگرام برای تاخیر،
جیتر، و اندازه بسته، به ترتیب.

· packetsDropped، bytesDropped: تعداد بسته ها و بایت های گم شده، تقسیم بر اساس
کد دلیل ضرر (تعریف شده در پروب).

شایان ذکر است که کاوشگرها بایت های بسته از جمله هدر IP را اندازه گیری می کنند.
هدرهای L2 در اندازه گیری گنجانده نشده است.

این آمار در صورت درخواست به شکل XML نوشته می شود (به بخش استفاده مراجعه کنید).

منابع
[FlowMonitor]

G. Carneiro، P. Fortuna و M. Ricardo. 2009. FlowMonitor: یک چارچوب نظارت بر شبکه
برای شبیه ساز شبکه 3 (NS-3). در مجموعه مقالات چهارمین ICST بین المللی
کنفرانس روش ها و ابزارهای ارزیابی عملکرد (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

استفاده
استفاده از ماژول بسیار ساده است. کمک کننده از همه چیز مراقبت خواهد کرد.

استفاده معمولی این است:

// نمایشگر جریان
Ptr مانیتور جریان؛
FlowMonitorHelper flowHelper;
flowMonitor = flowHelper.InstallAll();

شبیه ساز::Stop (ثانیه(stop_time));
شبیه ساز::Run ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml"، true، true);

la SerializeToXmlFile () از پارامترهای تابع 2 و 3 به ترتیب استفاده می شود
هیستوگرام ها و آمار دقیق هر پروب را فعال/غیرفعال کنید.

سایر جایگزین های ممکن را می توان در مستندات Doxygen یافت.

یاران
Helper API از الگوی استفاده از Helperهای معمولی پیروی می کند. از طریق کمک کننده می توانید
مانیتور را در گره ها نصب کنید، ویژگی های مانیتور را تنظیم کنید و آمار را چاپ کنید.

یک چیز مهم این است: ns3::FlowMonitorHelper باید فقط یک بار در آن نمونه سازی شود
اصلی

خواص
ماژول ویژگی های زیر را در آن ارائه می دهد ns3::FlowMonitor:

· MaxPerHopDelay (زمان، 10 ثانیه پیش فرض): حداکثر تاخیر در هر هاپ که باید در نظر گرفته شود.

· StartTime (زمان، 0s پیش فرض): زمانی که نظارت شروع می شود.

· DelayBinWidth (دو برابر، پیش فرض 0.001): عرض مورد استفاده در هیستوگرام تاخیر.

· JitterBinWidth (دو برابر، پیش فرض 0.001): عرض مورد استفاده در هیستوگرام jitter.

· PacketSizeBinWidth (دو برابر، پیش فرض 20.0): عرض مورد استفاده در هیستوگرام packetSize.

· FlowInterruptionsBinWidth (دو برابر، پیش فرض 0.25): عرض مورد استفاده در
هیستوگرام flowInterruptions;

· FlowInterruptionsMinTime (دو برابر، پیش فرض 0.5): حداقل زمان بین ورود که
قطع جریان در نظر گرفته می شود.

تولید
خروجی مدل اصلی یک گزارش با فرمت XML در مورد آمار جریان است. یک مثال این است:




























خروجی توسط یک جریان TCP از 10.1.3.1 تا 10.1.2.2 تولید شد.

شایان ذکر است که کاوشگر index 2 بسته های بیشتری و بایت های بیشتری را گزارش می دهد
مشکلات دیگر این یک رفتار کاملا طبیعی است، زیرا بسته ها در IP تکه تکه می شوند
سطح در آن گره

همچنین باید توجه داشت که کاوشگر گره دریافت کننده (شاخص 4) آن را به حساب نمی آورد
قطعات، همانطور که مونتاژ مجدد قبل از نقطه کاوش انجام می شود.

مثال ها
نمونه ها در src/flow-monitor/نمونه ها.

علاوه بر این، نمونه‌های زیر از ماژول مانیتور جریان استفاده می‌کنند:

· نمونه ها/متریس-توپولوژی/متریس-توپولوژی.cc

· نمونه / مسیریابی / manet-routing-compare.cc

· نمونه ها/مسیریابی/ساده-جهانی-مسیریابی.cc

· examples/tcp/tcp-variants-comparison.cc

· نمونه ها/بی سیم/multirate.cc

· نمونه / بی سیم / wifi-hidden-terminal.cc

عیب یابی
بیش از یک تعریف نکنید ns3::FlowMonitorHelper در شبیه سازی

اعتبار
مقاله موجود در مراجع حاوی شرح کاملی از اعتبارسنجی ماژول در برابر a است
شبکه آزمایشی

آزمایش هایی برای اطمینان از عملکرد صحیح هیستوگرام ارائه شده است.

INTERNET مدل ها

اینترنت پشته
اینترنت پشته تجمع
یک کلاس لخت گره همانطور که هست خیلی مفید نیست. اشیاء دیگر باید به آن تجمیع شود
ارائه عملکرد مفید گره

La ns-3 دایرکتوری کد منبع src/اینترنت اجرای TCP/IPv4- و را فراهم می کند
اجزای مرتبط با IPv6 اینها شامل IPv4، ARP، UDP، TCP، IPv6، Neighbor Discovery و
سایر پروتکل های مرتبط

گره های اینترنتی زیر کلاس های کلاس Node نیستند. آنها به سادگی گره هایی هستند که دارای یک هستند
دسته ای از اشیاء مرتبط با IP که در آنها جمع شده است. آنها را می توان با دست یا از طریق a
عملکرد کمکی InternetStackHelper::Install () که موارد زیر را برای تمام گره ها انجام می دهد
به عنوان استدلال ارائه شد:

از درجه اعتبار ساقط
InternetStackHelper::Install (Ptr گره) const
{
اگر (m_ipv4Enabled)
{
/* پشته IPv4 */
if (node->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): جمع آوری"
"یک InternetStack به یک گره با یک شی Ipv4 موجود");
بازگشت؛
}

CreateAndAggregateObjectFromTypeId (گره، "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (گره، "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (گره، "ns3::Icmpv4L4Protocol");
// تنظیم مسیریابی
Ptr ipv4 = node->GetObject ()
Ptr ipv4Routing = m_routing->Create (node);
ipv4->SetRoutingProtocol (ipv4Routing)؛
}

اگر (m_ipv6Enabled)
{
/* پشته IPv6 */
if (node->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): جمع آوری"
"یک InternetStack به یک گره با یک شی Ipv6 موجود");
بازگشت؛
}

CreateAndAggregateObjectFromTypeId (گره، "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (گره، "ns3::Icmpv6L4Protocol");
// تنظیم مسیریابی
Ptr ipv6 = node->GetObject ()
Ptr ipv6Routing = m_routingv6->Create (node);
ipv6->SetRoutingProtocol (ipv6Routing)؛

/* پسوندها و گزینه های IPv6 را ثبت کنید */
ipv6->RegisterExtensions ();
ipv6->RegisterOptions ();
}

if (m_ipv4Enabled || m_ipv6Enabled)
{
/* پشته های UDP و TCP */
CreateAndAggregateObjectFromTypeId (گره، "ns3::UdpL4Protocol");
node->AggregateObject (m_tcpFactory.Create ())؛
Ptr کارخانه = CreateObject ()؛
node->AggregateObject (factory);
}
}

جایی که چندین پیاده سازی در آن وجود دارد ns-3 (TCP، مسیریابی IP)، این اشیاء توسط اضافه می شوند
یک شی کارخانه (TCP) یا توسط یک کمک کننده مسیریابی (m_routing).

توجه داشته باشید که پروتکل مسیریابی خارج از این تابع پیکربندی و تنظیم شده است. به صورت پیش فرض،
پروتکل های زیر اضافه می شوند:

void InternetStackHelper::Initialize ()
{
SetTcp ("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper staticRouting.
Ipv4GlobalRoutingHelper globalRouting.
Ipv4ListRoutingHelper listRouting;
Ipv6ListRoutingHelper listRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add (staticRouting، 0);
listRouting.Add (globalRouting, -10);
listRoutingv6.Add (staticRoutingv6, 0);
SetRoutingHelper (listRouting)؛
SetRoutingHelper (listRoutingv6)؛
}

به طور پیش فرض، IPv4 و IPv6 فعال هستند.

اینترنت گره ساختار
یک گره با قابلیت IP (یک ns-3 گره با تجمیع برای داشتن یک یا چند پشته IP تقویت شده است)
دارای ساختار داخلی زیر است.

لایه-3 پروتکل
در پایین ترین لایه، بالای NetDevices، پروتکل های "لایه 3" قرار دارند که شامل
IPv4، IPv6، ARP و غیره. کلاس پروتکل Ipv4L3 یک کلاس پیاده سازی است که
رابط عمومی معمولاً کلاس است IPv4، اما از Ipv4L3Protocol عمومی API نیز استفاده می شود
در حال حاضر داخلی

در کلاس Ipv4L3Protocol، یکی از روش هایی که در زیر توضیح داده شده است دريافت كردن ():

/ **
* لایه پایین این متد را پس از فراخوانی L3Demux::Lookup فراخوانی می کند
* زیر کلاس ARP باید بداند که این از کدام NetDevice است
* بسته در حال آمدن است به:
* - یک کش ARP برای هر NetDevice پیاده سازی کنید
* - پاسخ های arp را در دستگاه مناسب ارسال کنید
*/
void Receive(Ptr دستگاه، Ptr p، پروتکل uint16_t،
const آدرس &from, const آدرس &to, NetDevice::PacketType packetType);

ابتدا توجه داشته باشید که دريافت كردن () تابع دارای یک امضای مطابق با ReceiveCallback است
در کلاس گره. این نشانگر تابع در زمان کنترل کننده پروتکل Node درج می شود
افزودن اینترفیس () نامیده میشود. ثبت واقعی با عبارتی مانند
به شرح زیر است:

RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Receive, ipv4)
پروتکل Ipv4L3::PROT_NUMBER، 0);

شی Ipv4L3Protocol در Node جمع می شود. فقط یک پروتکل Ipv4L3 وجود دارد
هدف - شی. پروتکل های لایه بالاتر که بسته ای برای ارسال به پروتکل Ipv4L3 دارند.
شی می تواند تماس بگیرد GetObject () برای به دست آوردن یک اشاره گر به شرح زیر است:

Ptr ipv4 = m_node->GetObject ()؛
اگر (ipv4 != 0)
{
ipv4->ارسال (packet, saddr, daddr, PROT_NUMBER)؛
}

این کلاس به خوبی دو تکنیک را نشان می دهد که ما از آنها استفاده می کنیم ns-3 برای اتصال اشیا به یکدیگر:
تماس ها و تجمع اشیاء.

هنگامی که مسیریابی IPv4 مشخص کرد که یک بسته برای گره محلی است، آن را به سمت بالا ارسال می کند
پشته این کار با تابع زیر انجام می شود:

از درجه اعتبار ساقط
پروتکل Ipv4L3::LocalDeliver (Ptr بسته، Ipv4Header const&ip، uint32_t iif)

اولین قدم این است که شیء Ipv4L4Protocol مناسب را بر اساس شماره پروتکل IP پیدا کنید.
به عنوان مثال، TCP در demux به عنوان پروتکل شماره 6 ثبت می شود دريافت كردن()
عملکرد در پروتکل Ipv4L4 (مانند پروتکل TcpL4::دریافت نامیده میشود.

ما هنوز کلاس Ipv4Interface را معرفی نکرده ایم. اساساً هر NetDevice جفت شده است
با نمایش IPv4 از چنین دستگاهی. در لینوکس، این کلاس Ipv4 Interface تقریبا
مطابق با ساختار in_device; هدف اصلی ارائه آدرس-خانواده است
اطلاعات خاص (آدرس) در مورد یک رابط.

تمامی کلاس ها دارای ردیابی مناسب برای ردیابی بسته های ارسالی، دریافتی و گمشده هستند.
کاربران تشویق می شوند تا از آنها استفاده کنند تا دریابند که آیا (و کجا) یک بسته رها شده است یا خیر. آ
اشتباه رایج فراموش کردن اثرات صف های محلی هنگام ارسال بسته ها است، به عنوان مثال،
صف ARP این می تواند به ویژه هنگام ارسال بسته های جامبو یا انفجار بسته ها گیج کننده باشد
با استفاده از UDP صف معلق کش ARP محدود است (3 دیتاگرام) و بسته های IP ممکن است محدود باشد
تکه تکه شده، به راحتی اندازه صف کش ARP را بیش از حد پر می کند. در این موارد مفید است
اندازه کش ARP در انتظار را به مقدار مناسب افزایش دهید، به عنوان مثال:

پیکربندی::SetDefault ("ns3::ArpCache::PendingQueueSize"، UintegerValue (MAX_BURST_SIZE/L2MTU*3));

پیاده سازی IPv6 از معماری مشابهی پیروی می کند. گره های دوتایی (یکی با
پشتیبانی از هر دو IPv4 و IPv6) به یک سوکت IPv6 اجازه می دهد تا اتصالات IPv4 را به عنوان یک
سیستم استاندارد دو پشته ای انجام می دهد. یک سوکت متصل شده و به یک نقطه پایانی IPv6 گوش می دهد
یک اتصال IPv4 دریافت می کند و آدرس راه دور را به عنوان یک آدرس نقشه برداری IPv4 برمی گرداند.
پشتیبانی از گزینه سوکت IPV6_V6ONLY در حال حاضر وجود ندارد.

لایه-4 پروتکل و پریز برق
در ادامه توضیح می‌دهیم که چگونه پروتکل‌های حمل و نقل، سوکت‌ها و برنامه‌ها به هم متصل می‌شوند. که در
به طور خلاصه، هر پیاده سازی پروتکل حمل و نقل یک کارخانه سوکت است. اپلیکیشنی که
نیاز به یک سوکت جدید دارد

به عنوان مثال، برای ایجاد یک سوکت UDP، یک برنامه از یک قطعه کد مانند
زیر است:

Ptr udpSocketFactory = GetNode ()->GetObject ()؛
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Bind (m_local_address);
...

موارد بالا از گره پرس و جو می کند تا یک اشاره گر به کارخانه سوکت UDP خود دریافت کند، یکی را ایجاد می کند
چنین سوکتی، و از سوکت با یک API مشابه API سوکت های مبتنی بر C استفاده خواهد کرد، مانند
as اتصال () و ارسال (). آدرس به اتصال (), اتصال ()، یا ارسال ()
توابع ممکن است a آدرس IPv4, آدرس IPv6، یا نشانی:. اگر یک نشانی: گذشت در و
حاوی هر چیزی غیر از الف است آدرس IPv4 or آدرس IPv6، این توابع یک را برمی گرداند
خطا این اتصال (خالی) و اتصال 6 (خالی) توابع به "0.0.0.0" و "::" متصل می شوند.
بود.

سوکت همچنین می تواند به یک NetDevice خاص متصل شود BindToNetDevice
(Ptr دستگاه شبکه) تابع. BindToNetDevice (Ptr دستگاه شبکه) مقید خواهد شد
سوکت را به "0.0.0.0" و "::" (معادل تماس اتصال () و اتصال 6 ()مگر اینکه
سوکت قبلاً به یک آدرس خاص متصل شده است. خلاصه کردن، دنباله درست
است:

Ptr udpSocketFactory = GetNode ()->GetObject ()؛
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice)؛
...

و یا:

Ptr udpSocketFactory = GetNode ()->GetObject ()؛
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Bind (m_local_address);
m_socket->BindToNetDevice (n_netDevice)؛
...

موارد زیر یک خطا ایجاد می کند:

Ptr udpSocketFactory = GetNode ()->GetObject ()؛
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice)؛
m_socket->Bind (m_local_address);
...

فصل در را ببینید ns-3 سوکت برای اطلاعات بیشتر

ما تاکنون یک کارخانه سوکت را توضیح داده ایم (مثلاً کلاس udp) و یک سوکت، که ممکن است باشد
تخصصی (مثلاً کلاس UdpSocket). چند مورد کلیدی دیگر وجود دارد که به آن مربوط می شود
وظیفه تخصصی دی مالتی پلکس کردن یک بسته به یک یا چند سوکت گیرنده. کلید
شی در این وظیفه کلاس است Ipv4EndPointDemux. این دی مالتی پلکسر اشیاء را ذخیره می کند
کلاس Ipv4EndPoint. این کلاس دارای آدرس دهی/پورت تاپل (پورت محلی، محلی است
آدرس، پورت مقصد، آدرس مقصد) مرتبط با سوکت، و یک دریافت
پاسخ به تماس این پاسخ تماس دریافتی دارای یک تابع دریافت است که توسط سوکت ثبت شده است. را
گرین کارت آمریکا () تابع به Ipv4EndPointDemux لیستی از اشیاء Ipv4EndPoint را برمی گرداند (ممکن است وجود داشته باشد
یک لیست باشد زیرا ممکن است بیش از یک سوکت با بسته مطابقت داشته باشد). پروتکل لایه 4 کپی می کند
بسته را به هر Ipv4EndPoint و آن را فراخوانی می کند ForwardUp () متد، که سپس the را فراخوانی می کند
دريافت كردن () عملکرد ثبت شده توسط سوکت

مسئله ای که هنگام کار با سوکت API در سیستم های واقعی به وجود می آید، نیاز به آن است
خواندن را از یک سوکت، با استفاده از نوعی I/O مدیریت کنید (مثلاً مسدود کننده، غیر مسدود،
نامتقارن، ...). ns-3 یک مدل ناهمزمان برای سوکت I/O پیاده سازی می کند. برنامه
یک تماس برگشتی را تنظیم می کند تا از داده های دریافتی که آماده خواندن هستند مطلع شود، و تماس پاسخ داده می شود
هنگامی که داده در دسترس است توسط پروتکل حمل و نقل فراخوانی می شود. این تماس برگشتی به صورت مشخص شده است
به شرح زیر است:

void Socket::SetRecvCallback (Callback ،
Ptr ،
const Address&> receiveData);

داده های دریافت شده در بافر داده بسته منتقل می شود. یک مثال استفاده در است
کلاس PacketSink:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead، این));

به طور خلاصه، در داخل، پیاده سازی UDP به صورت زیر سازماندهی شده است:

· آ UdpImpl کلاسی که عملکرد کارخانه سوکت UDP را پیاده سازی می کند

· آ پروتکل UdpL4 کلاسی که منطق پروتکل را که مستقل از سوکت است پیاده سازی می کند

· آ UdpSocketImpl کلاسی که جنبه های خاص سوکت UDP را پیاده سازی می کند

· یک کلاس به نام Ipv4EndPoint که تاپل آدرس دهی را ذخیره می کند (پورت محلی، آدرس محلی،
پورت مقصد، آدرس مقصد) مرتبط با سوکت، و یک دریافت
پاسخ تماس برای سوکت

دارای IP گره رابط
بسیاری از جزئیات پیاده سازی یا خود اشیاء داخلی Node با قابلیت IP
اشیاء در API عمومی شبیه ساز در معرض نمایش قرار نمی گیرند. این اجازه می دهد تا برای متفاوت است
پیاده سازی ها به عنوان مثال، جایگزینی بومی ns-3 مدل هایی با پشته TCP/IP پورت شده
کد

APIهای عمومی C++ همه این اشیاء در src/شبکه فهرست راهنما،
از جمله اصولا:

· آدرس.h

· سوکت.h

· node.h

· بسته.h

اینها معمولاً اشیاء کلاس پایه هستند که مقادیر پیش فرض استفاده شده در را پیاده سازی می کنند
پیاده سازی، پیاده سازی روش های دسترسی برای دریافت/تنظیم متغیرهای حالت، ویژگی های میزبان و
پیاده سازی روش های در دسترس عموم در معرض مشتریان مانند CreateSocket.

مثال مسیر of a بسته
این دو شکل نمونه ای از ردیابی پشته ای از چگونگی جریان بسته ها از طریق اینترنت را نشان می دهد
اشیاء گره.
[تصویر] ارسال مسیر یک بسته..UNINDENT
[تصویر] مسیر دریافت بسته..UNINDENT

IPv4
حفره یا سوراخ فصل

IPv6
این فصل به شرح ns-3 قابلیت ها و محدودیت های مدل IPv6 به همراه آن
استفاده و مثال ها

IPv6 مدل شرح
مدل IPv6 پس از پیاده‌سازی لینوکس، الگوی ضعیفی دارد. اجرا است
کامل نیست زیرا برخی از ویژگی های IPv6 چندان مورد توجه مطالعات شبیه سازی نیستند، و
برخی از ویژگی های IPv6 به سادگی هنوز در مدل سازی نشده اند ns-3.

کلاس پایه IPv6 یک API عمومی تعریف می کند، در حالی که کلاس پروتکل Ipv6L3 واقعی است
کلاس پیاده سازی پروتکل کلاس های واقعی استفاده شده توسط پشته IPv6 قرار دارند
عمدتا در دایرکتوری src/اینترنت.

پیاده سازی IPv6 در فایل های زیر موجود است:

src/internet/model/icmpv6-header.{cc,h}
src/internet/model/icmpv6-l4-protocol.{cc,h}
src/internet/model/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
src/internet/model/ipv6-end-point.{cc,h}
src/internet/model/ipv6-end-point-demux.{cc,h}
src/internet/model/ipv6-extension.{cc,h}
src/internet/model/ipv6-extension-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/model/ipv6-header.{cc,h}
src/internet/model/ipv6-interface.{cc,h}
src/internet/model/ipv6-interface-address.{cc,h}
src/internet/model/ipv6-l3-protocol.{cc,h}
src/internet/model/ipv6-list-routing.{cc,h}
src/internet/model/ipv6-option.{cc,h}
src/internet/model/ipv6-option-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-cache.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/internet/model/ipv6-route.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/model/disc-cache.{cc,h}
src/network/utils/inet6-socket-address.{cc,h}
src/network/utils/ipv6-address.{cc,h}

همچنین برخی از کمک کنندگان با IPv6 درگیر هستند:

src/internet/helper/internet-stack-helper.{cc,h}
src/internet/helper/ipv6-address-helper.{cc,h}
src/internet/helper/ipv6-interface-container.{cc,h}
src/internet/helper/ipv6-list-routing-helper.{cc,h}
src/internet/helper/ipv6-routing-helper.{cc,h}
src/internet/helper/ipv6-static-routing-helper.{cc,h}

فایل های مدل را می توان به طور تقریبی به موارد زیر تقسیم کرد:

· مدل های پروتکل (مانند پروتکل ipv6، ipv6-l3-protocol، icmpv6-l4-protocol و غیره)

· مدل‌های مسیریابی (یعنی هر چیزی که به نام خود «مسیریابی» باشد)

· سوکت ها و رابط ها (به عنوان مثال، ipv6-raw-socket، ipv6-interface، ipv6-end-point، و غیره)

· چیزهای مرتبط با آدرس

· سرصفحه ها، سرصفحه های گزینه، سرصفحه های افزونه و غیره

· کلاس های جانبی (به عنوان مثال، ndisc-cache)

استفاده
توضیحات زیر بر اساس استفاده از کمک کننده های معمولی موجود در کد مثال است.

IPv6 نیازی به فعال سازی در گره ندارد. به طور خودکار به موجود اضافه می شود
پروتکل ها پس از نصب پشته اینترنت.

به منظور نه با نصب IPv6 همراه با IPv4 امکان استفاده وجود دارد
ns3::InternetStackHelper روش SetIpv6StackInstall (بول فعال کردن) قبل از نصب
InternetStack در گره ها.

توجه داشته باشید که برای داشتن یک شبکه فقط IPv6 (یعنی عدم نصب پشته IPv4 در یک گره)
باید استفاده کنی ns3::InternetStackHelper روش SetIpv4StackInstall (بول فعال کردن) قبل از
نصب پشته

به عنوان مثال، در کد زیر، گره 0 دارای هر دو IPv4 و IPv6 است، فقط گره 1
IPv6 و Node 2 فقط IPv4:

NodeContainer n;
n.Create (3);

InternetStackHelper اینترنت؛
InternetStackHelper internetV4only;
InternetStackHelper internetV6only;

internetV4only.SetIpv6StackInstall (نادرست);
internetV6only.SetIpv4StackInstall (نادرست);

Internet.Install (n.Get (0));
internetV6only.Install (n.Get (1));
internetV4only.Install (n.Get (2));

IPv6 آدرس واگذاری
برای استفاده از IPv6 در شبکه، اولین کاری که باید انجام دهید اختصاص آدرس های IPv6 است.

هر IPv6 فعال ns-3 گره حداقل یک NetDevice خواهد داشت: the ns3::LoopbackNetDevice.
آدرس دستگاه حلقه بک است :: 1. تمام NetDevice های دیگر یک یا چند IPv6 خواهند داشت
آدرس ها:

· یک پیوند - آدرس محلی: fe80::رابط ID، که در آن رابط ID برگرفته از
آدرس مک نت دیوایس

· آدرس های جهانی صفر یا بیشتر، به عنوان مثال، 2001: db8 :: 1.

معمولاً اولین آدرس در یک اینترفیس، پیوند محلی و سراسری خواهد بود
آدرس(ها) موارد زیر است.

آدرس های جهانی IPv6 ممکن است:

· به صورت دستی اختصاص داده شده است

· تولید خودکار

ns-3 می تواند از هر دو روش استفاده کند، و درک مفاهیم آن بسیار مهم است
هر دو.

بصورت دستی اختصاص داده IPv6 آدرس ها
این احتمالا ساده ترین و پرکاربردترین روش است. به عنوان مثال:

Ptr n0 = CreateObject ()
Ptr n1 = CreateObject ()
NodeContainer net (n0، n1)؛
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("Assign IPv6 Addresses.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::")، Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign (ndc);

این روش دو آدرس IPv6 جهانی را به گره ها اضافه می کند. توجه داشته باشید که طبق معمول برای IPv6،
تمام گره ها همچنین یک آدرس لینک محلی خواهند داشت. به طور معمول اولین آدرس در یک
رابط پیوند محلی خواهد بود، با آدرس(های) جهانی به شرح زیر است
آنهایی که.

توجه داشته باشید که آدرس های جهانی از آدرس MAC مشتق می شوند. به عنوان یک نتیجه،
انتظار داشته باشید که آدرس هایی مشابه داشته باشید 2001:db8::200:ff:fe00:1.

تکرار موارد بالا برای اختصاص بیش از یک آدرس سراسری به یک گره امکان پذیر است.
با این حال ، به دلیل IPv6AddressHelper ماهیت تک، ابتدا باید همه را اختصاص دهید
آدرس های یک شبکه، سپس پایگاه شبکه را تغییر دهید (SetBase، سپس یک تکلیف جدید انجام دهید.

از طرف دیگر، می توان یک آدرس خاص را به یک گره اختصاص داد:

Ptr n0 = CreateObject ()
NodeContainer net (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("به طور خاص یک آدرس IPv6 اختصاص دهید.");
Ipv6AddressHelper ipv6;
Ptr دستگاه = ndc.Get (0);
Ptr node = device->GetNode ();
Ptr ipv6proto = node->GetObject ()؛
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (دستگاه)؛
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42")، Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex، ipv6Addr)؛

تولید خودکار IPv6 آدرس ها
این کار با تکیه بر پروتکل RADVD که توسط کلاس پیاده سازی شده است، انجام می شود رادود. در
زمان هیچ کمکی برای این برنامه وجود ندارد و استفاده از آن نسبتاً دشوار است (نگاه کنید به
examples/ipv6/radvd.cc).

با استفاده از این روش، گره ها به صورت پویا (یعنی در طول شبیه سازی) به دست خواهند آورد.
یک (یا چند آدرس) جهانی با توجه به پیکربندی RADVD. این آدرس ها
مبتنی بر پیشوند اعلام شده RADVD و EUI-64 گره خواهد بود.

تصادفی تولید شده است IPv6 آدرس ها
در حالی که گره های واقعی IPv6 از آدرس های تولید شده به صورت تصادفی برای محافظت از حریم خصوصی استفاده می کنند. ns-3 میکند
این قابلیت را ندارند این ویژگی تا کنون به عنوان جالب در نظر گرفته نشده است
شبیه سازی.

تکراری نشانی: کشف (پدر)
گره ها DAD را انجام می دهند (می توان آن را با استفاده از یک غیرفعال کرد پروتکل Icmpv6L4 صفت). بر
با دریافت یک DAD، گره ها به آن واکنش نشان نمی دهند. همانطور که است: واکنش DAD ناقص است بنابراین
دور دلیل اصلی به قابلیت آدرس تصادفی از دست رفته وابسته است. علاوه بر این،
پس از ns-3 گره‌ها معمولاً رفتار خوبی دارند، نباید هیچ آدرس تکراری وجود داشته باشد.
این ممکن است در آینده تغییر کند، تا از مسائل مربوط به یکپارچه سازی دنیای واقعی جلوگیری شود
شبیه سازی ها

میزبان و روتر رفتار in IPv6 و ns-3
در IPv6 یک تمایز واضح بین وجود دارد روتر و میزبان. همانطور که می توان انتظار داشت،
روترها می توانند بسته ها را از یک اینترفیس به اینترفیس دیگر ارسال کنند، در حالی که هاست ها رها می شوند
بسته هایی که به آنها هدایت نمی شوند.

متأسفانه، ارسال تنها چیزی نیست که تحت تأثیر این تمایز قرار می گیرد و
خود ارسال ممکن است به خوبی تنظیم شود، به عنوان مثال، برای ارسال بسته های دریافتی از یک رابط
و بسته ها را از یک رابط دیگر رها کنید.

In ns-3 یک گره به صورت an پیکربندی شده است میزبان به صورت پیش فرض. دو راه اصلی برای تغییر وجود دارد
این رفتار:

· استفاده كردن ns3::Ipv6InterfaceContainer SetForwarding(uint32_t i, بول روتر) جایی که i هست
شاخص رابط در ظرف.

· تغییر دادن ns3:: IPv6 صفت IpForward.

هر کدام را می توان در طول شبیه سازی استفاده کرد.

راه اندازی ریز دانه را می توان با استفاده از آن انجام داد ns3::اینترفیس IPv6 SetForwarding (بول
رو به جلو)؛ که اجازه می دهد تا رفتار را بر اساس هر رابط تغییر دهید.

توجه داشته باشید که پیکربندی گسترده گره تنها به عنوان یک روش راحت برای فعال/غیرفعال کردن عمل می کند
la ns3::اینترفیس IPv6 تنظیم خاص یک Ipv6 Interface به یک گره با فورواردینگ اضافه شده است
فعال تنظیم می شود که به صورت فوروارد نیز باشد. زمانی که یک گره داشته باشد، این واقعا مهم است
رابط های اضافه شده در طول شبیه سازی.

با توجه به ns3::اینترفیس IPv6 حالت ارسال، موارد زیر رخ می دهد:

حمل و نقل خاموش

· گره به درخواست روتر پاسخ نمی دهد

· گره به تبلیغات روتر واکنش نشان می دهد

· گره به صورت دوره ای درخواست روتر را ارسال می کند

· پروتکل های مسیریابی باید بسته هایی را که به گره هدایت نمی شوند، رها کنند

· ارسال روشن است

· گره به درخواست روتر پاسخ خواهد داد

· گره به تبلیغات روتر واکنش نشان نخواهد داد

· گره درخواست روتر را ارسال نخواهد کرد

· پروتکل های مسیریابی باید بسته ها را ارسال کنند

رفتار با ip-sysctl.txt مطابقت دارد (‐
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) با این تفاوت که
نمی توان با استفاده از تنظیمات باطنی رفتار را نادیده گرفت (به عنوان مثال، ارسال اما
تبلیغات روتر، accept_ra=2، یا فوروارد کردن را بپذیرید، اما درخواست های روتر را ارسال کنید
ارسال=2).

پیامدهای ارسال بسته را با دقت در نظر بگیرید. به عنوان مثال، یک گره نمی خواهد
پیام های ICMPv6 PACKET_TOO_BIG را از یک رابط با فوروارد کردن ارسال کنید. این هست
کاملاً طبیعی است، زیرا پروتکل Routing بسته را قبل از تلاش رها می کند
بفرستش.

یاران
معمولاً کمک کننده هایی که در راه اندازی IPv6 استفاده می شوند عبارتند از:

· ns3::InternetStackHelper

· ns3::Ipv6AddressHelper

· ns3::Ipv6InterfaceContainer

استفاده تقریباً مشابه مورد IPv4 مربوطه است، به عنوان مثال:

NodeContainer n;
n.Create (4);

NS_LOG_INFO ("ایجاد پشته اینترنت IPv6")؛
InternetStackHelper internetv6;
internetv6.Install (n);

NS_LOG_INFO ("ایجاد کانال ها.");
CsmaHelper csma;
NetDeviceContainer d = csma.Install (n);

NS_LOG_INFO ("ایجاد شبکه ها و اختصاص آدرس های IPv6.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::")، Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

علاوه بر این، یک کار رایج فعال کردن ارسال در یکی از گره ها و راه اندازی a است
مسیر پیش فرض به سمت آن در گره های دیگر، به عنوان مثال:

iic.SetForwarding (0، true);
iic.SetDefaultRouteInAllNodes (0);

این امکان ارسال در گره را فراهم می کند 0 و یک مسیر پیش فرض را در آن راه اندازی می کند
ns3::Ipv6StaticRouting روی تمام گره های دیگر توجه داشته باشید که این مستلزم آن است
Ipv6StaticRouting در گره ها وجود دارد.

کمک‌کننده‌های مسیریابی IPv6 کاربر را قادر می‌سازد تا وظایف خاصی را در مورد خاص انجام دهد
الگوریتم مسیریابی و چاپ جداول مسیریابی.

خواص
بسیاری از کلاس ها در ns-3 پیاده سازی IPv6 حاوی ویژگی هایی است. مفیدترین آنها عبارتند از:

· ns3:: IPv6

· IpForward، بولی، نادرست پیش فرض. به صورت جهانی، ارسال IP را برای همه فعال یا غیرفعال کنید
دستگاه های IPv6 فعلی و آینده

· MtuDiscover، بولی، پیش فرض درست است. اگر غیرفعال باشد، هر رابط MTU خود را خواهد داشت
روی 1280 بایت تنظیم کنید.

· ns3::پروتکل IPv6L3

· پیش فرضTtl، uint8_t، پیش فرض 64. مقدار TTL به طور پیش فرض در تمام بسته های خروجی تنظیم شده است.
در این گره ایجاد می شود.

· SendIcmpv6Redirect، بولی، پیش فرض درست است. در صورت لزوم، ICMPv6 Redirect را ارسال کنید.

· ns3:: پروتکل Icmpv6L4

· DAD، بولی، پیش فرض درست است. همیشه DAD (تشخیص آدرس تکراری) را بررسی کنید.

· ns3::NdiscCache

· UnresolvedQueueSize، uint32_t، پیش فرض 3. اندازه صف برای بسته های در انتظار NA
پاسخ.

تولید
پشته IPv6 منابع ردیابی مفیدی را ارائه می دهد:

· ns3::پروتکل IPv6L3

· Tx، بسته IPv6 را به رابط خروجی ارسال کنید.

· Rx، بسته IPv6 را از رابط ورودی دریافت کنید.

· قطرهبسته IPv6 را رها کنید.

· ns3:: برنامه افزودنی IPv6

· قطرهبسته IPv6 را رها کنید.

آخرین منبع ردیابی زمانی ایجاد می شود که یک بسته حاوی یک گزینه ناشناخته باشد که آن را مسدود می کند
در حال پردازش.

به این فکر کن ns3::NdiscCache می تواند بسته ها را نیز رها کند، و آنها در یک ردیابی وارد نشده اند
منبع (هنوز). این ممکن است باعث سردرگمی در شمارنده بسته های ارسالی/دریافتی شود.

فناوری استفاده
IPv6 بیشترین انتقال واحد (MTU) و تکه تکه شدن
ns-3 NetDevices MTU را با توجه به دستگاه شبیه سازی شده L2 تعریف می کند. IPv6 به این نیاز دارد
حداقل MTU 1280 بایت است، بنابراین تمام NetDevice ها باید حداقل از این پشتیبانی کنند
MTU. این لینک-MTU است.

به منظور پشتیبانی از MTU های مختلف در مسیر مبدا-مقصد، ns-3 مدل IPv6 می تواند
انجام تکه تکه شدن این امر می تواند با دریافت بسته ای بزرگتر از آن ایجاد شود
link-MTU از پروتکل های L4 (UDP، TCP، و غیره)، یا با دریافت ICMPv6 PACKET_TOO_BIG
پیام این مدل از RFC 1981 تقلید می کند، با استثناهای قابل توجه زیر:

· پروتکل های L4 از تغییر مسیر MTU مطلع نمی شوند

· TCP نمی تواند اندازه بخش خود را مطابق با Path-MTU تغییر دهد.

هر دو محدودیت در زمان مقرر حذف خواهند شد.

کش Path-MTU در حال حاضر بر اساس آدرس های IPv6 مبدا مقصد است. به علاوه
طبقه بندی (به عنوان مثال، برچسب جریان) ممکن است اما هنوز اجرا نشده است.

زمان اعتبار پیش فرض Path-MTU 10 دقیقه است. پس از انقضای ورودی کش،
اطلاعات Path-MTU حذف می شود و بسته بعدی (در نهایت) یک ICMPv6 جدید را راه اندازی می کند.
پیام PACKET_TOO_BIG. توجه داشته باشید که 1) این با مشخصات RFC مطابقت دارد و 2)
پروتکل های L4 مسئول ارسال مجدد بسته ها هستند.

مثال ها
نمونه های IPv6 در دایرکتوری موجود است نمونه/ipv6. این نمونه ها بیشترین تمرکز را دارند
ویژگی های جالب IPv6، مانند تکه تکه شدن، تغییر مسیر و غیره.

علاوه بر این، بیشتر نمونه‌های TCP و UDP در داخل قرار دارند نمونه ها/udp, نمونه ها/tcpو غیره دارای یک
گزینه خط فرمان برای استفاده از IPv6 به جای IPv4.

عیب یابی
در حین استفاده فقط چند مشکل وجود دارد که باید از آنها اجتناب کنید ns-3 IPv6

مسیریابی حلقه ها
از آنجایی که تنها (تا کنون) طرح مسیریابی موجود برای IPv6 است ns3::Ipv6StaticRouting,
روتر پیش فرض باید به صورت دستی تنظیم شود. هنگامی که دو یا چند روتر در یک شبکه وجود دارد
(به عنوان مثال، گره A و گره B)، از استفاده از تابع کمکی خودداری کنید SetDefaultRouteInAllNodes برای
بیش از یک روتر

نتیجه این خواهد بود که یک مسیر پیش‌فرض به B در A و یک مسیر پیش‌فرض نشان‌دهنده نصب شود
به A در B، ایجاد یک حلقه.

جهانی نشانی نشت
به یاد داشته باشید که آدرس ها در IPv6 هستند جهانی طبق تعریف هنگام استفاده از IPv6 با یک
شبیه سازی ns-3 توانایی، به هر قیمتی از نشت آدرس به سمت اینترنت جهانی جلوگیری کنید.
توصیه می شود برای جلوگیری از نشتی یک فایروال خارجی راه اندازی کنید.

2001:DB8::/32 آدرس
استاندارد IPv6 (RFC 3849) تعریف می کند 2001:DB8::/32 کلاس آدرس برای مستندات.
این راهنما از این قرارداد استفاده می کند. با این حال، آدرس‌های این کلاس فقط در داخل قابل استفاده هستند
یک سند، و روترها باید آنها را دور بیندازند.

اعتبار
پروتکل های IPv6 هنوز به طور گسترده در برابر پیاده سازی های واقعی تایید نشده اند.
آزمایش‌های واقعی عمدتاً شامل بررسی فایل‌های ردیابی pcap. با Wireshark است.
و نتایج مثبت است.

مسیریابی مروری
ns-3 در نظر گرفته شده برای پشتیبانی از رویکردهای مسیریابی سنتی و پروتکل ها، پشتیبانی از پورت های
پیاده سازی مسیریابی منبع باز، و تسهیل تحقیق در مسیریابی غیرمتعارف
تکنیک. معماری کلی مسیریابی در زیر توضیح داده شده است مسیریابی معماری.
کاربرانی که مایلند فقط درباره نحوه پیکربندی مسیریابی جهانی برای توپولوژی های سیمی مطالعه کنند
خواندن جهانی متمرکز مسیریابی. پروتکل های مسیریابی Unicast در شرح داده شده است Unicast
مسیریابی. مسیریابی چندپخشی در مستند شده است چندپخشی مسیریابی.

مسیریابی معماری
[تصویر] نمای کلی مسیریابی.UNINDENT

بررسی اجمالی of مسیریابی معماری کلی مسیریابی برای Ipv4 را نشان می دهد. اشیاء کلیدی هستند
Ipv4L3Protocol، Ipv4RoutingProtocol(های) (کلاسی که تمام مسیریابی/مسابقات به آن انجام شده است
از پروتکل Ipv4L3 و Ipv4Route (های) تفویض شده است.

پروتکل Ipv4L3 باید حداقل یک پروتکل Ipv4Routing در شبیه سازی به آن اضافه شود
زمان راه اندازی این کار به صراحت با فراخوانی Ipv4::SetRoutingProtocol () انجام می شود.

کلاس پایه انتزاعی Ipv4RoutingProtocol () یک رابط حداقلی را اعلام می کند که شامل
از دو روش: RouteOutput () و RouteInput (). برای بسته هایی که به خارج از کشور سفر می کنند
یک میزبان، پروتکل حمل و نقل از Ipv4 برای شی Ipv4RoutingProtocol پرس و جو می کند
رابط، و از طریق Ipv4RoutingProtocol::RouteOutput () یک مسیر درخواست می کند. یک Ptr به
شی Ipv4Route برگردانده می شود. این مشابه ورودی dst_cache در لینوکس است. این
Ipv4Route به پروتکل Ipv4L3 منتقل می شود تا از جستجوی دوم در آنجا جلوگیری شود. با این حال،
برخی موارد (مثلاً سوکت‌های خام Ipv4) به تماس مستقیم با RouteOutput () نیاز دارند.
پروتکل Ipv4L3.

برای بسته های دریافتی ورودی برای ارسال یا تحویل، مراحل زیر انجام می شود.
Ipv4L3Protocol::Receive() Ipv4RoutingProtocol::RouteInput را فرا می خواند. این عبور می کند
مالکیت بسته به شی Ipv4RoutingProtocol. چهار پاسخ تماس وجود دارد
با این تماس:

· LocalDeliver

· UnicastForward

· MulticastForward

· خطا

پروتکل Ipv4Routing در نهایت باید یکی از این callback ها را برای هر بسته ای که
مسئولیت می پذیرد. اساساً فرآیند مسیریابی ورودی به این صورت است
لینوکس است.
[تصویر] تخصص Ipv4Routing..UNINDENT

این معماری کلی برای پشتیبانی از رویکردهای مسیریابی مختلف از جمله طراحی شده است
(در آینده) پیاده سازی مسیریابی مبتنی بر سیاست مبتنی بر لینوکس، فعال و
پروتکل های مسیریابی درخواستی و پروتکل های مسیریابی ساده برای زمانی که کاربر شبیه سازی است
واقعاً به مسیریابی اهمیت نمی دهد.

مسیریابی IPv4 تخصص نشان می دهد که چگونه پروتکل های مسیریابی متعدد از این استخراج می شوند
کلاس پایه کلاس Ipv4ListRouting (کلاس پیاده سازی Ipv4ListRoutingImpl) فراهم می کند
رویکرد مسیریابی لیست موجود در ns-3. API آن همان کلاس پایه است
Ipv4Routing به جز توانایی اضافه کردن چندین پروتکل مسیریابی اولویت بندی شده
(Ipv4ListRouting::AddRoutingProtocol()، Ipv4ListRouting::GetRoutingProtocol()).

جزئیات این پروتکل های مسیریابی در زیر توضیح داده شده است Unicast مسیریابی. در حال حاضر ،
ابتدا با یک قابلیت مسیریابی unicast اولیه که در سطح جهانی در نظر گرفته شده است، شروع خواهیم کرد
ساخت جداول مسیریابی در زمان شبیه سازی t=0 برای کاربران شبیه سازی که به آن اهمیتی نمی دهند
مسیریابی پویا

جهانی متمرکز مسیریابی
مسیریابی متمرکز جهانی گاهی اوقات مسیریابی "خدا" نامیده می شود. خاص است
پیاده سازی که توپولوژی شبیه سازی را طی می کند و الگوریتم کوتاه ترین مسیر را اجرا می کند و
جداول مسیریابی هر گره را پر می کند. بدون سربار پروتکل واقعی (در پیوندهای شبیه سازی شده)
با این رویکرد ایجاد می شود. این چند محدودیت دارد:

· سیم فقط: برای استفاده در شبکه های بی سیم در نظر گرفته نشده است.

· Unicast فقط: چندپخشی انجام نمی دهد.

· مقیاس پذیری: برخی از کاربران این در توپولوژی های بزرگ (مثلا 1000 گره) متوجه این موضوع شده اند
پیاده سازی فعلی خیلی مقیاس پذیر نیست. مسیریابی متمرکز جهانی خواهد بود
در آینده برای کاهش محاسبات و عملکرد زمان اجرا اصلاح شده است.

در حال حاضر، IPv4 متمرکز جهانی، مسیریابی unicast را هم از طریق نقطه به نقطه و هم به صورت اشتراکی انجام می دهد
پیوندهای (CSMA) پشتیبانی می شود.

به طور پیش فرض، هنگام استفاده از ns-3 helper API و InternetStackHelper پیش فرض، global
قابلیت مسیریابی به گره اضافه می شود و مسیریابی جهانی به عنوان یک درج می شود
پروتکل مسیریابی با اولویت کمتر از مسیرهای ثابت (یعنی کاربران می توانند مسیرها را وارد کنند
از طریق Ipv4StaticRouting API و آنها بر مسیرهای یافت شده توسط جهانی اولویت خواهند داشت
مسیریابی).

جهانی Unicast مسیریابی API
API عمومی بسیار کم است. اسکریپت های کاربر شامل موارد زیر است:

#include "ns3/internet-module.h"

اگر از InternetStackHelper پیش فرض استفاده شود، نمونه ای از مسیریابی جهانی خواهد بود
به هر گره تجمیع می شود. پس از پیکربندی آدرس های IP، تابع زیر را فراخوانی کنید
باعث می شود تمام گره هایی که دارای رابط Ipv4 هستند جداول ارسال را دریافت کنند
به طور خودکار توسط GlobalRouteManager وارد می شود:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

توجه داشته باشید: یادآوری اینکه WiFi NetDevice کار می کند اما هیچ گونه افکت بی سیم نمی گیرد
به حساب آوردن. برای بی سیم، ما مسیریابی پویا OLSR را توصیه می کنیم که در زیر توضیح داده شده است.

امکان فراخوانی مجدد این تابع در میان یک شبیه سازی با استفاده از
عملکرد عمومی اضافی زیر:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

که جداول قدیمی را شستشو می دهد، گره ها را برای اطلاعات رابط جدید جستجو می کند و
مسیرها را بازسازی می کند

به عنوان مثال، این تماس زمان‌بندی باعث می‌شود که جداول در زمان 5 ثانیه بازسازی شوند:

Simulator::Schedule (ثانیه (5)،
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

دو ویژگی بر رفتار حاکم است. اولی این است
Ipv4GlobalRouting::RandomEcmpRouting. اگر روی true تنظیم شود، بسته ها به طور تصادفی در سراسر مسیریابی می شوند
مسیرهای چند مسیره با هزینه برابر اگر روی false (پیش‌فرض) تنظیم شود، فقط یک مسیر ثابت است
استفاده شده. دومی Ipv4GlobalRouting::RespondToInterfaceEvents است. اگر روی true تنظیم شود،
به صورت پویا مسیرهای جهانی را بر اساس رویدادهای اعلان رابط (بالا/پایین یا.) دوباره محاسبه کنید
افزودن/حذف آدرس). اگر روی false (پیش‌فرض) تنظیم شود، مسیریابی ممکن است از بین برود مگر اینکه کاربر به صورت دستی
RecomputeRoutingTables() را پس از چنین رویدادهایی فرا می خواند. پیش فرض برای حفظ روی false تنظیم شده است
میراث ns-3 رفتار برنامه

جهانی مسیریابی پیاده سازی
این بخش برای آن دسته از خوانندگانی است که به نحوه اجرای آن اهمیت می دهند. تک قلو
شی (GlobalRouteManager) مسئول پر کردن مسیرهای ثابت در هر گره است.
با استفاده از API عمومی Ipv4 آن گره. هر گره در توپولوژی را برای a پرس و جو می کند
رابط "globalRouter". اگر پیدا شد، از API آن رابط برای به دست آوردن یک "لینک" استفاده می کند
تبلیغات دولتی (LSA)" برای روتر. تبلیغات وضعیت پیوند در OSPF استفاده می شود
مسیریابی، و ما قالب بندی آنها را دنبال می کنیم.

توجه به این نکته ضروری است که تمامی این محاسبات قبل از جریان یافتن بسته ها انجام می شود
در شبکه به ویژه، هیچ بسته سربار یا کنترلی مبادله نمی شود
هنگام استفاده از این پیاده سازی در عوض، این مدیر مسیر جهانی فقط فهرستی از آنها را پیاده می‌کند
گره ها برای ساختن اطلاعات لازم و پیکربندی جدول مسیریابی هر گره.

GlobalRouteManager یک پایگاه داده وضعیت پیوند را با LSAهای جمع آوری شده از کل پر می کند
توپولوژی سپس برای هر روتر در توپولوژی، GlobalRouteManager OSPF را اجرا می کند
ابتدا کوتاهترین مسیر (SPF) را در پایگاه داده محاسبه می کند و جداول مسیریابی را پر می کند
هر گره

کواگا (http://www.quagga.net) پیاده سازی OSPF به عنوان پایه ای برای استفاده استفاده شد
منطق محاسبات مسیریابی یکی از مزایای پیروی از اجرای OSPF SPF موجود این است
که OSPF قبلاً تبلیغات وضعیت پیوند را برای همه انواع رایج شبکه تعریف کرده است
پیوندها:

· نقطه به نقطه (لینک های سریال)

· نقطه به چند نقطه (فریم رله، بی سیم موقت)

· دسترسی چندگانه بدون پخش (ATM)

· پخش (اترنت)

بنابراین، ما فکر می کنیم که فعال کردن سایر انواع پیوندها اکنون ساده تر خواهد بود
که چارچوب اصلی OSPF SPF موجود است.

در حال حاضر، ما می توانیم IPv4 نقطه به نقطه، لینک های شماره گذاری شده و همچنین پخش مشترک را مدیریت کنیم.
پیوندهای (CSMA). چند مسیری با هزینه برابر نیز پشتیبانی می شود. اگرچه انواع پیوندهای بی سیم هستند
پشتیبانی شده توسط پیاده سازی، توجه داشته باشید که با توجه به ماهیت این پیاده سازی، هر
اثرات کانال در نظر گرفته نمی شود و جداول مسیریابی هر گره را فرض می کنند
در همان کانال مشترک از هر گره دیگری قابل دسترسی است (یعنی درمان خواهد شد
مانند یک پیوند پخش CSMA).

GlobalRouteManager ابتدا لیست گره ها را پیاده می کند و یک GlobalRouter را جمع می کند
رابط برای هر یک به شرح زیر است:

typedef std::vector < Ptr >::iterator Iterator;
برای (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
{
Ptr گره = *i;
Ptr globalRouter = CreateObject (گره)؛
node->AggregateObject (globalRouter);
}

این رابط بعداً مورد پرس و جو قرار می گیرد و برای ایجاد یک تبلیغ وضعیت پیوند برای هر یک استفاده می شود
روتر، و این پایگاه داده وضعیت پیوند به منطق محاسباتی کوتاه ترین مسیر OSPF وارد می شود.
در نهایت از Ipv4 API برای پر کردن مسیرها استفاده می شود.

Unicast مسیریابی
در حال حاضر هفت پروتکل مسیریابی unicast برای IPv4 و سه پروتکل برای IPv6 تعریف شده است:

· کلاس Ipv4StaticRouting (که هم تک پخشی و هم چندپخشی را پوشش می دهد)

· مسیریابی وضعیت پیوند IPv4 بهینه شده (OLSR) (یک پروتکل MANET تعریف شده در RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (پروتکل MANET تعریف شده در RFC 3561)

· بردار فاصله توالی مقصد IPv4 (DSDV) (یک پروتکل MANET)

· مسیریابی منبع دینامیک IPv4 (DSR) (یک پروتکل MANET)

· کلاس Ipv4ListRouting (برای ذخیره یک لیست اولویت بندی شده از پروتکل های مسیریابی استفاده می شود)

· کلاس Ipv4GlobalRouting (برای ذخیره مسیرهای محاسبه شده توسط مدیر مسیر جهانی استفاده می شود، اگر
که استفاده می شود)

· کلاس Ipv4NixVectorRouting (نسخه کارآمدتر مسیریابی جهانی که ذخیره می کند
مسیرهای منبع در فیلد سرصفحه بسته)

· کلاس Ipv6ListRouting (برای ذخیره یک لیست اولویت بندی شده از پروتکل های مسیریابی استفاده می شود)

· کلاس Ipv6StaticRouting

· کلاس RipNg - پروتکل IPv6 RIPng (RFC 2080)

در آینده، این معماری باید به کسی اجازه دهد تا لینوکس مانند را پیاده سازی کند
پیاده سازی با کش مسیریابی یا یک روتر مدولار Click، اما این موارد خارج از محدوده هستند
در حال حاضر

Ipv[4,6،XNUMX]ListRouting
این بخش پیش فرض فعلی را شرح می دهد ns-3 پروتکل مسیریابی IPv[4,6،XNUMX]. معمولا،
چندین پروتکل مسیریابی در فضای کاربر پشتیبانی می شوند و برای نوشتن یک واحد هماهنگ می شوند
جدول ارسال در هسته در حال حاضر در ns-3، پیاده سازی در عوض اجازه می دهد
چندین پروتکل مسیریابی برای ایجاد/حفظ وضعیت مسیریابی خود و IP
پیاده سازی هر یک از این پروتکل های مسیریابی را پرس و جو می کند (به ترتیبی که توسط
نویسنده شبیه سازی) تا زمانی که یک مسیر پیدا شود.

ما این رویکرد را انتخاب کردیم زیرا ممکن است ادغام موارد متفاوت را بهتر تسهیل کند
رویکردهای مسیریابی که ممکن است برای هماهنگ کردن نوشته ها در یک جدول مشکل باشد،
رویکردهایی که در آن اطلاعات بیشتر از آدرس IP مقصد (مثلاً مسیریابی منبع) است
برای تعیین جهش بعدی و رویکردهای مسیریابی برحسب تقاضا که بسته ها باید باشند استفاده می شود
ذخیره شده

Ipv[4,6]4ListRouting::AddRoutingProtocol
کلاس Ipv4ListRouting و Ipv6ListRouting یک اعلان تابع مجازی خالص را ارائه می دهد.
برای روشی که به فرد اجازه می دهد یک پروتکل مسیریابی اضافه کند:

void AddRoutingProtocol (Ptr پروتکل مسیریابی،
اولویت int16_t)؛

void AddRoutingProtocol (Ptr پروتکل مسیریابی،
اولویت int16_t)؛

این متدها به ترتیب توسط کلاس Ipv4ListRoutingImpl و کلاس پیاده سازی می شوند
Ipv6ListRoutingImpl در ماژول اینترنت.

متغیر اولویت بالا، اولویتی را که پروتکل های مسیریابی در آن قرار دارند، کنترل می کند
درج شده است. توجه داشته باشید که یک int امضا شده است. به طور پیش فرض در ns-3، کلاس های کمکی خواهند کرد
یک شی Ipv[4,6]ListRoutingImpl نمونه سازی کنید و یک Ipv[4,6]StaticRoutingImpl به آن اضافه کنید
شی در اولویت صفر در داخل، فهرستی از پروتکل‌های مسیریابی Ipv[4,6،XNUMX] ذخیره می‌شود و
و پروتکل‌های مسیریابی هر کدام به ترتیب اولویت برای مشاهده مورد بررسی قرار می‌گیرند
آیا مطابقت پیدا می شود. بنابراین، اگر می خواهید پروتکل Ipv4Routing شما دارای اولویت باشد
پایین تر از مسیریابی استاتیک، آن را با اولویت کمتر از 0 درج کنید. به عنوان مثال:

Ptr myRoutingProto = CreateObject ()؛
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

پس از فراخوانی به RouteOutput() یا RouteInput()، شی مسیریابی لیست لیست را جستجو می کند.
پروتکل های مسیریابی، به ترتیب اولویت، تا زمانی که یک مسیر پیدا شود. چنین پروتکل مسیریابی
پاسخ تماس مناسب را فراخوانی می کند و هیچ پروتکل مسیریابی دیگری جستجو نخواهد شد.

بهینه شده ارتباط دادن دولت مسیریابی (OLSR)
این پروتکل مسیریابی IPv4 در اصل از پیاده سازی OLSR-UM برای ns-2 منتقل شده است.
پیاده سازی در دایرکتوری src/olsr یافت می شود و یک نمونه اسکریپت در آن موجود است
نمونه‌ها/نقطه-به-نقطه-olsr.cc.

به طور معمول، OLSR در یک برنامه اصلی با استفاده از یک کلاس OlsrHelper که نصب می کند فعال می شود.
OLSR به یک شیء Ipv4ListRoutingProtocol. دستورات نمونه زیر فعال خواهند شد
OLSR در یک شبیه سازی با استفاده از این کلاس کمکی همراه با برخی دیگر از اشیاء کمکی مسیریابی.
تنظیم مقدار اولویت 10، جلوتر از اولویت staticRouting 0، به این معنی است که
OLSR برای یک مسیر قبل از جدول مسیریابی استاتیک گره مورد مشورت قرار می گیرد.

NodeContainer c:
...
// OLSR را فعال کنید
NS_LOG_INFO ("فعال کردن مسیریابی OLSR.");
OlsrHelper olsr;

Ipv4StaticRoutingHelper staticRouting.

لیست Ipv4ListRoutingHelper.
list.Add (staticRouting, 0);
list.Add (olsr, 10);

InternetStackHelper اینترنت؛
internet.SetRoutingHelper (لیست);
اینترنت.نصب (c);

پس از نصب، "رابط اصلی" OLSR را می توان با دستور SetMainInterface () تنظیم کرد.
اگر کاربر آدرس اصلی را مشخص نکند، پروتکل اولین IP اصلی را انتخاب می کند
آدرسی که پیدا می کند، ابتدا رابط حلقه بک و سپس بعدی را شروع می کند
رابط غیرحلقه ای به ترتیب شاخص رابط Ipv4 یافت شد. آدرس حلقه بک از
127.0.0.1 انتخاب نشده است. علاوه بر این، تعدادی ثابت پروتکل در آن تعریف شده است
olsr-routing-protocol.cc.

Olsr در زمان صفر شبیه سازی، بر اساس فراخوانی به Object::Start() شروع می شود.
در نهایت OlsrRoutingProtocol::DoStart را فراخوانی می کند. توجه: یک وصله برای شروع به کاربر
و توقف پروتکل در زمان های دیگر خوش آمدید.

در حال حاضر، OLSR برای استفاده با یک شی Ipv4ListRouting محدود شده است و به آن پاسخ نمی دهد.
تغییرات پویا در آدرس IP دستگاه یا اعلان‌های پیوند بالا/پایین؛ یعنی توپولوژی
تغییرات به دلیل از دست دادن/به دست آوردن اتصال از طریق یک کانال بی سیم است.

RIPng
این پروتکل مسیریابی IPv6 (RFC 2080) تکامل RIPv1 معروف و RIPv2 است
(نگاه کنید به RFC 1058 و RFC 1723) پروتکل های مسیریابی برای IPv4.

پروتکل بسیار ساده است و معمولاً برای شبکه های مسطح و ساده مناسب است
توپولوژی ها

RIPng به شدت مبتنی بر RIPv1 و RIPv2 است و اهداف مشابهی دارد
محدودیت ها. به طور خاص، RIP هر مسیری را با متریک مساوی یا بزرگتر از 16 در نظر می گیرد
به عنوان دست نیافتنی در نتیجه، حداکثر تعداد پرش شبکه باید کمتر باشد
بیش از 15 (تعداد روترها تنظیم نشده است). کاربران به خواندن تشویق می شوند RFC 2080 و RFC
1058 برای درک کامل رفتار و محدودیت های RIPng.

مسیریابی همگرایی
RIPng از الگوریتم Distance-Vector استفاده می کند و مسیرها بر اساس آن به روز می شوند
الگوریتم بلمن-فورد (گاهی اوقات به عنوان الگوریتم فورد-فولکرسون شناخته می شود). الگوریتم دارای یک است
زمان همگرایی O(|V|*|E|) که در آن |V| و |E| تعداد رئوس (روترها) و
لبه ها (پیوندها) به ترتیب. باید تاکید کرد که زمان همگرایی عدد است
از مراحل در الگوریتم، و هر مرحله توسط یک پیام راه اندازی می شود. از آنجا که باعث شده است
به‌روزرسانی‌ها (یعنی وقتی مسیری تغییر می‌کند) 1-5 ثانیه خنک‌سازی دارند، توپولوژی می‌تواند
برای تثبیت مدتی زمان نیاز دارد.

کاربران باید بدانند که در طول ساخت جداول مسیریابی، روترها ممکن است سقوط کنند
بسته ها ترافیک داده باید تنها پس از مدت زمانی طولانی ارسال شود تا امکان ساخت RIPng فراهم شود
توپولوژی شبکه معمولاً 80 ثانیه برای داشتن یک زیر بهینه (اما
کار) راه اندازی مسیریابی. این شامل زمان مورد نیاز برای انتشار بیشتر مسیرها می شود
روتر دور (16 پرش) با به‌روزرسانی‌های راه‌اندازی شده.

اگر توپولوژی شبکه تغییر کند (به عنوان مثال، یک پیوند خراب است)، زمان بازیابی ممکن است باشد
بسیار زیاد است و ممکن است حتی بیشتر از زمان راه اندازی اولیه باشد. علاوه بر این، شبکه
بازیابی توپولوژی تحت تأثیر استراتژی Split Horizoning قرار دارد.

مثال examples/routing/ripng-simple-network.cc هم تنظیمات شبکه و هم را نشان می دهد
مراحل بازیابی شبکه

شکاف افق پردازی
Split Horizon یک استراتژی برای جلوگیری از ناپایداری مسیریابی است. سه گزینه ممکن است:

· بدون شکاف افق

· Split Horizon

· معکوس سم

در حالت اول، مسیرها در تمام رابط های روتر تبلیغ می شوند. در دومی
در این صورت، روترها مسیری را در رابطی که از آن آموخته شده است، تبلیغ نمی کنند.
Poison Reverse مسیر را در رابطی که از آن آموخته شده تبلیغ می کند، اما
با متریک 16 (بی نهایت). برای تجزیه و تحلیل کامل از سه تکنیک، نگاه کنید به RFC
1058بخش 2.2.

مثال ripng-simple-network.cc بر اساس توپولوژی شبکه شرح داده شده در RFC است،
اما اثری که در آنجا توضیح داده شده را نشان نمی دهد.

دلیل به روز رسانی های راه اندازی شده، همراه با این واقعیت است که وقتی یک روتر
یک مسیر را باطل می کند، بنابراین فوراً غیرقابل دسترس بودن مسیر را منتشر می کند
جلوگیری از بسیاری از مسائل شرح داده شده در RFC.

با این حال، با توپولوژی های پیچیده، هنوز هم می توان پدیده های ناپایداری مسیر را داشت
مشابه آنچه در RFC پس از شکست لینک توضیح داده شده است. در نتیجه، همه
ملاحظات در مورد Split Horizon Remanins معتبر است.

به طور پیش فرض مسیرها
پروتکل RIPng باید نصب شود فقط در روترها در نتیجه، گره ها نمی دانند
روتر پیش فرض چیست

برای غلبه بر این محدودیت، کاربران باید مسیر پیش فرض را به صورت دستی نصب کنند (به عنوان مثال،
با توسل به Ipv6StaticRouting)، یا با استفاده از RADVd. RADVd در دسترس است ns-3 در
ماژول برنامه های کاربردی، و به شدت پیشنهاد می شود.

پروتکل پارامترهای و گزینه های
RIPng ns-3 پیاده سازی اجازه می دهد تا تمام تایمرهای مرتبط با مسیر را تغییر دهید
به روز رسانی و طول عمر مسیرها

علاوه بر این، کاربران می توانند معیارهای رابط را بر اساس هر گره تغییر دهند.

نوع Split Horizoning (برای جلوگیری از انتشار مجدد مسیرها) را می توان در a انتخاب کرد
بر اساس هر گره، با انتخاب های "بدون شکاف افق"، "افق تقسیم" و "زهر"
معکوس". ببینید RFC 2080 برای جزئیات بیشتر، و RFC 1058 برای بحث کامل در مورد
تقسیم استراتژی های افق یابی

محدودیت ها
هیچ پشتیبانی از گزینه Next Hop وجود ندارد (RFC 2080، بخش 2.1.1). هاپ بعدی
این گزینه زمانی مفید است که RIPng روی همه روترهای یک شبکه اجرا نمی شود. پشتیبانی
برای این گزینه ممکن است در آینده در نظر گرفته شود.

هیچ پشتیبانی برای تجمع پیشوند CIDR وجود ندارد. در نتیجه، هر دو جدول مسیریابی و
تبلیغات مسیر ممکن است بزرگتر از حد لازم باشد. تجمع پیشوند ممکن است در اضافه شود
آینده.

چندپخشی مسیریابی
تابع زیر برای افزودن یک مسیر چندپخشی استاتیک به یک گره استفاده می شود:

از درجه اعتبار ساقط
Ipv4StaticRouting::AddMulticastRoute (Ipv4Address مبدا،
گروه آدرس IPv4،
uint32_t inputInterface،
std:: vector outputInterfaces)؛

یک مسیر چندپخشی باید یک آدرس IP مبدا، یک گروه چندپخشی و یک ورودی را مشخص کند
شاخص رابط شبکه به عنوان شرایط و ارائه بردار رابط شبکه خروجی
شاخص هایی که بسته های منطبق بر شرایط ارسال می شوند.

به طور معمول دو نوع اصلی از مسیرهای چندپخشی وجود دارد: مسیرهای نوع اول استفاده می شوند
در حین ارسال تمام شرایط باید به صراحت ارائه شود. نوع دوم از
مسیرها برای خارج کردن بسته ها از یک گره محلی استفاده می شوند. تفاوت در ورودی است
رابط. مسیرهای ارسال همیشه دارای یک رابط ورودی صریح مشخص شده خواهند بود.
مسیرهای خارج از یک گره همیشه رابط ورودی را به یک علامت عام مشخص شده توسط گره تنظیم می کند
فهرست Ipv4RoutingProtocol::IF_INDEX_ANY.

برای مسیرهای خارج از یک گره محلی، ممکن است از حروف عام در گروه مبدا و چندپخشی استفاده شود
آدرس ها. عام مورد استفاده برای Ipv4Adresses همان آدرسی است که توسط آن برگردانده شده است
Ipv4Address::GetAny () -- معمولاً "0.0.0.0". استفاده از wildcard به شخص اجازه می دهد که مشخص کند
رفتار پیش فرض به درجات مختلف

به عنوان مثال، ساختن آدرس مبدا به صورت عام، اما خروج از گروه چندپخشی
خاص به یک (در مورد یک گره با چندین رابط) اجازه می دهد تا متفاوت ایجاد کند
مسیرهایی با استفاده از رابط های خروجی مختلف برای هر گروه چندپخشی.

اگر آدرس‌های مبدا و چندپخشی به صورت عام ساخته شده‌اند، شما اساساً a ایجاد کرده‌اید
آدرس چندپخشی پیش‌فرض که می‌تواند به چندین رابط ارسال شود. این را با
آدرس چندپخشی پیش فرض واقعی که محدود به تعیین یک رابط خروجی واحد است
برای سازگاری با عملکردهای موجود در سیستم های دیگر.

دستور دیگری مسیر پیش فرض چندپخشی را تنظیم می کند:

از درجه اعتبار ساقط
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t outputInterface)؛

این معادل چندپخشی نسخه unicast SetDefaultRoute است. ما به
سیستم مسیریابی در صورتی که یک مسیر خاص به مقصد چندپخشی چه کاری انجام شود
گروه یافت نشد سیستم بسته ها را از رابط مشخص شده به امید ارسال می کند
که "چیزی آنجا" بهتر می داند که چگونه بسته را مسیریابی کند. این روش فقط استفاده می شود
در ارسال اولیه بسته ها از یک میزبان. مسیر پیش‌فرض چندپخشی بررسی نشده است
در طول ارسال -- مسیرهای دقیق باید با استفاده از AddMulticastRoute برای آن مورد مشخص شود.

از آنجایی که ما اساساً بسته‌هایی را به نهادی ارسال می‌کنیم که فکر می‌کنیم بهتر می‌دانیم چه باید بکنیم،
ما به «ظرافت‌هایی» مانند آدرس مبدا توجه نمی‌کنیم و نگران هم نیستیم
ارسال چندین رابط اگر مسیر پیش‌فرض چندپخشی تنظیم شده باشد، برگردانده می‌شود
به عنوان مسیر انتخاب شده از LookupStatic صرف نظر از مبدا یا گروه چندپخشی اگر
مسیر مشخص دیگری یافت نشد.

در نهایت، تعدادی عملکرد اضافی برای واکشی و حذف چندپخشی ارائه شده است
مسیرها:

uint32_t GetNMulticastRoutes (void) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

bool RemoveMulticastRoute (Ipv4Address مبدا،
گروه آدرس IPv4،
uint32_t inputInterface)؛

void RemoveMulticastRoute (شاخص uint32_t)؛

TCP مدل in ns-3
این فصل مدل های TCP موجود در آن را شرح می دهد ns-3.

عمومی پشتیبانی برای TCP
ns-3 برای پشتیبانی از چند پیاده سازی TCP نوشته شده است. پیاده سازی ها ارث می برند
چند کلاس هدر رایج در src/شبکه دایرکتوری، به طوری که کد کاربر می تواند تعویض شود
پیاده سازی هایی با حداقل تغییرات در اسکریپت ها.

دو کلاس پایه انتزاعی مهم وجود دارد:

· کلاس TcpSocket: این در تعریف شده است src/internet/model/tcp-socket.{cc,h}. این کلاس
برای میزبانی ویژگی‌های TcpSocket وجود دارد که می‌توانند در نقاط مختلف مورد استفاده مجدد قرار گیرند
پیاده سازی ها به عنوان مثال، ویژگی InitialCwnd قابل استفاده برای هر یک از
پیاده سازی هایی که از کلاس نشات می گیرند TcpSocket.

· کلاس TcpSocketFactory: این مورد توسط نمونه پروتکل لایه 4 برای ایجاد TCP استفاده می شود
سوکت از نوع مناسب

در حال حاضر سه پیاده سازی از TCP برای آن موجود است ns-3.

· یک TCP بومی پیاده سازی شده برای ns-3

· پشتیبانی از شبکه ارتباطی شبیه سازی گهواره (NSC)

· پشتیبانی از مستقیم رمز اعدام (DCE)

همچنین لازم به ذکر است که روش های مختلف ترکیب ماشین های مجازی با ns-3
برخی از پیاده سازی های اضافی TCP را نیز در دسترس قرار می دهد، اما آنها خارج از محدوده هستند
این فصل.

ns-3 TCP
تا زمان انتشار ns-3.10، ns-3 حاوی پورتی از مدل TCP از GTNetS. این
پیاده سازی به طور قابل توجهی توسط آدریام تام برای ns-3.10 بازنویسی شد. مدل فول هستش
TCP، از این نظر که دو طرفه است و سعی می‌کند تا تنظیمات اتصال را مدل‌سازی و بسته کند
منطق.

پیاده سازی TCP در فایل های زیر موجود است:

src/internet/model/tcp-header.{cc,h}
src/internet/model/tcp-l4-protocol.{cc,h}
src/internet/model/tcp-socket-factory-impl.{cc,h}
SRC/اینترنت/مدل/TCP-Socket-base. {CC ، H}
src/internet/model/tcp-tx-buffer.{cc,h}
src/internet/model/tcp-rx-buffer.{cc,h}
src/internet/model/tcp-rfc793.{cc,h}
src/internet/model/tcp-tahoe.{cc,h}
src/internet/model/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/internet/model/tcp-newreno.{cc,h}
SRC/اینترنت/مدل/RTT-Estimator. {CC ، H}
SRC/Network/Model/Sequence Number. {CC ، H

انواع مختلف کنترل تراکم TCP با زیر کلاس بندی پایه مشترک پشتیبانی می شوند
کلاس tcpsocketbase. چندین نوع پشتیبانی می شود، از جمله RFC 793 (بدون تراکم
کنترل)، تاهو، رنو، وست وود، وست وود+ و نیو رینو. NewReno به طور پیش فرض استفاده می شود. دیدن
بخش استفاده از این سند برای نحوه تغییر نوع پیش فرض TCP مورد استفاده در
شبیه سازی.

استفاده
در بسیاری از موارد، استفاده از TCP در لایه برنامه با گفتن این تنظیم می شود ns-3
برنامه ای که از کدام نوع کارخانه سوکت استفاده کنید.

با استفاده از توابع کمکی تعریف شده در src/applications/helper و src/network/helper، اینجا
چگونه می توان یک گیرنده TCP ایجاد کرد:

// برای دریافت این بسته ها یک بسته سینک در ستاره "hub" ایجاد کنید
پورت uint16_t = 50000;
آدرس sinkLocalAddress(InetSocketAddress (Ipv4Address::GetAny ()، پورت));
PacketSinkHelper sinkHelper ("ns3::TcpSocketFactory"، sinkLocalAddress);
ApplicationContainer sinkApp = sinkHelper.Install (serverNode);
sinkApp.Start (ثانیه (1.0));
sinkApp.Stop (ثانیه (10.0))؛

به طور مشابه، قطعه زیر منبع ترافیک OnOffApplication را برای استفاده از TCP پیکربندی می کند:

// برنامه های OnOff را برای ارسال TCP به سرور ایجاد کنید
OnOffHelper clientHelper ("ns3::TcpSocketFactory"، آدرس ());

خواننده دقیق در بالا متوجه خواهد شد که ما TypeId یک پایه انتزاعی را مشخص کرده ایم
کلاس TcpSocketFactory. فیلمنامه چگونه می گوید ns-3 که بومی را می خواهد ns-3 TCP
در مقابل یکی دیگر؟ خوب، وقتی پشته های اینترنت به گره اضافه می شوند، TCP پیش فرض است
پیاده سازی که به گره تجمیع شده است ns-3 TCP. این می تواند به عنوان لغو شود
هنگام استفاده از Network Simulation Cradle در زیر نشان می دهیم. بنابراین، به طور پیش فرض، هنگام استفاده از ns-3
helper API، TCP که در گره‌هایی با پشته اینترنت جمع می‌شود، بومی است ns-3
TCP

برای پیکربندی رفتار TCP، تعدادی از پارامترها از طریق آن صادر می‌شوند ns-3
سیستم ویژگی اینها در مستند هستند اکسیژن
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> برای کلاس TcpSocket. برای
به عنوان مثال، حداکثر اندازه بخش یک ویژگی قابل تنظیم است.

برای تنظیم نوع سوکت پیش‌فرض قبل از ایجاد هر شیء مرتبط با پشته اینترنت، یک
ممکن است عبارت زیر را در بالای برنامه شبیه سازی قرار دهد:

پیکربندی::SetDefault ("ns3::TcpL4Protocol::SocketType"، StringValue ("ns3::TcpTahoe"));

برای کاربرانی که مایلند یک اشاره گر به سوکت واقعی داشته باشند (به طوری که عملیات سوکت مانند
Bind()، تنظیم گزینه های سوکت و غیره را می توان بر اساس هر سوکت انجام داد، سوکت های Tcp می توانند
با استفاده از سوکت::CreateSocket() روش. TypeId به
CreateSocket() باید از نوع باشد ns3::SocketFactory، بنابراین سوکت زیرین را پیکربندی کنید
نوع باید با چرخاندن ویژگی مرتبط با پروتکل TcpL4 زیرین انجام شود
هدف - شی. ساده ترین راه برای رسیدن به این امر از طریق پیکربندی ویژگی است
سیستم. در مثال زیر، کانتینر Node "n0n1" برای بدست آوردن صفر مورد دسترسی قرار گرفته است
عنصر، و یک سوکت در این گره ایجاد می شود:

// ایجاد و اتصال سوکت...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
پیکربندی:: تنظیم ("/NodeList/*/$ns3::TcpL4Protocol/SocketType"، TypeIdValue (tid));
Ptr localSocket =
سوکت::CreateSocket (n0n1.Get (0)، TcpSocketFactory::GetTypeId ());

در بالا، کارت وحشی "*" برای شماره گره به سیستم پیکربندی ویژگی ارسال می شود.
به طوری که تمام سوکت های آینده در همه گره ها روی تاهو تنظیم می شوند، نه فقط روی گره 'n0n1.Get (0)'.
اگر کسی بخواهد آن را فقط به گره مشخص شده محدود کند، باید کاری مانند:

// ایجاد و اتصال سوکت...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
std::stringstream nodeId;
nodeId << n0n1.Get (0)->GetId ();
std::string specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
پیکربندی:: تنظیم (specificNode، TypeIdValue (tid));
Ptr localSocket =
سوکت::CreateSocket (n0n1.Get (0)، TcpSocketFactory::GetTypeId ());

هنگامی که یک سوکت TCP ایجاد می شود، فرد می خواهد از منطق سوکت معمولی پیروی کند و یکی از آنها را دنبال کند
connect() و send() (برای مشتری TCP) یا bind()، listen() و accept() (برای TCP
سرور). برای بررسی نحوه استفاده از سوکت ها، به Sockets-APIs مراجعه کنید ns-3.

اعتبار
چندین نتیجه تست اعتبار سنجی TCP را می توان در آن یافت ویکی با ما توصیف این
پیاده سازی.

جاری محدودیت
· SACK پشتیبانی نمی شود

شبکه ارتباطی شبیه سازی گهواره
La شبکه ارتباطی شبیه سازی گهواره (NSC) چارچوبی برای بسته بندی کدهای شبکه در دنیای واقعی است
شبیه سازها، امکان شبیه سازی رفتار دنیای واقعی را با هزینه اضافی کمی فراهم می کند. این
کار با مقایسه موقعیت‌ها با استفاده از یک شبکه آزمایشی با همان وضعیت تأیید شده است
موقعیت ها در شبیه ساز تا به امروز نشان داده شده است که NSC قادر به تولید است
نتایج بسیار دقیق NSC از چهار پشته دنیای واقعی پشتیبانی می کند: FreeBSD، OpenBSD، lwIP
و لینوکس. تاکید بر عدم تغییر هیچ یک از پشته های شبکه با دست شده است. نه
یک خط کد در اجرای پروتکل شبکه هر یک از آنها تغییر کرده است
چهار پشته بالا با این حال، یک تجزیه کننده C سفارشی برای تغییر برنامه ای ساخته شده است
کد منبع

NSC قبلاً به آن منتقل شده است ns-2 و OMNeT++، و به اضافه شد ns-3 در سپتامبر
2008 (انتشار ns-3.2). این بخش شرح می دهد ns-3 پورت NSC و نحوه استفاده از آن

تا حدودی، NSC توسط پشتیبانی از هسته لینوکس در داخل جایگزین شده است مستقیم رمز
اعدام (DCE). با این حال، NSC هنوز از طریق سیستم ساخت bake در دسترس است. NSC
از هسته های لینوکس 2.6.18 و 2.6.26 پشتیبانی می کند، اما نسخه های جدیدتر هسته وجود ندارد.
منتقل شده

پیش نیازها
در حال حاضر، NSC آزمایش شده و نشان داده شده است که روی این پلتفرم‌ها کار می‌کند: Linux i386 و Linux
x86-64. NSC از powerpc پشتیبانی نمی کند. استفاده در FreeBSD یا OS X پشتیبانی نمی شود (اگرچه
ممکن است بتواند کار کند).

ساخت NSC به بسته‌های flex و bison نیاز دارد.

پیکربندی و دانلود
از ns-3.17 یا جدیدتر، NSC باید به طور جداگانه از مخزن خود دانلود شود.
یا دانلود هنگام استفاده از پختن ساختن سیستم of ns-3.

برای نسخه‌های ns-3.17 یا نسخه‌های جدیدتر، هنگام استفاده از bake، باید NSC را به عنوان بخشی از یک پیکربندی کنید.
پیکربندی "آلینون"، مانند:

پخت سی دی دلار
$ python bake.py پیکربندی -e ns-allinone-3.19
$ python bake.py دانلود کنید
ساخت $ python bake.py

به جای نسخه منتشر شده، می توان از نسخه توسعه ns-3 با مشخص کردن استفاده کرد
"ns-3-allinone" به مرحله پیکربندی بالا.

NSC همچنین ممکن است از دانلود شود آن دانلود سایت با استفاده از مرکوریال:

کلون $ hg https://secure.wand.net.nz/mercurial/nsc

قبل از انتشار ns-3.17، NSC در allinone tarball و منتشر شده گنجانده شده بود.
نسخه نیازی به دانلود جداگانه ندارد.

بنا و اعتبار سنجی
NSC ممکن است به عنوان بخشی از فرآیند ساخت bake ساخته شود. در عوض، می توان NSC را توسط
خودش با استفاده از سیستم ساختش. به عنوان مثال:

$ سی دی nsc-dev
$ python scons.py

هنگامی که NSC به صورت دستی یا از طریق سیستم پخت ساخته شد، به آن تغییر دهید ns-3
دایرکتوری منبع و سعی کنید پیکربندی زیر را اجرا کنید:

$ ./waf پیکربندی کنید

اگر NSC قبلاً توسط waf ساخته شده و پیدا شده باشد، خواهید دید:

پایگاه شبیه سازی شبکه: فعال است

اگر NSC پیدا نشد، خواهید دید:

پایگاه شبیه سازی شبکه: فعال نیست (NSC یافت نشد (به گزینه --with-nsc مراجعه کنید)

در این حالت باید مسیر نسبی یا مطلق را به کتابخانه های NSC با رمز عبور دهید
گزینه پیکربندی "--with-nsc". به عنوان مثال

$ ./waf configure --with-nsc=/path/to/my/nsc/directory

برای ns-3 منتشر شده قبل از انتشار ns-3.17، با استفاده از build.py اسکریپت در ns-3-allinone
دایرکتوری، NSC به طور پیش فرض ساخته می شود مگر اینکه پلتفرم آن را پشتیبانی نکند. به
در هنگام ساخت به صراحت آن را غیرفعال کنید ns-3، نوع:

$ ./waf configure --enable-examples --enable-tests --disable-nsc

اگر waf NSC را تشخیص دهد، پس ساختمان ns-3 با NSC به همان روش با waf انجام می شود
بدون آن. یک بار ns-3 ساخته شده است، مجموعه آزمایشی زیر را اجرا کنید:

$ ./test.py -s ns3-tcp-interoperability

اگر NSC با موفقیت ساخته شده باشد، آزمایش زیر باید در نتایج نشان داده شود:

PASS TestSuite ns3-tcp-Interoperability

این تأیید می کند که NSC آماده استفاده است.

استفاده
چند فایل نمونه وجود دارد. تلاش كردن:

$ ./waf -- tcp-nsc-zoo را اجرا کنید
$ ./waf -- tcp-nsc-lfn را اجرا کنید

این نمونه ها مقداری را واریز خواهند کرد pcap فایل های موجود در دایرکتوری شما، که می تواند توسط
tcpdump یا wireshark.

بیایید نگاه کنیم examples/tcp/tcp-nsc-zoo.cc فایل برای استفاده معمولی چگونه می شود
با استفاده از بومی متفاوت است ns-3 TCP؟ هنگام استفاده از NSC یک خط پیکربندی اصلی وجود دارد
و ns-3 helper API، که باید تنظیم شود:

InternetStackHelper internetStack;

internetStack.SetNscStack ("liblinux2.6.26.so");
// این گره‌های 0 و 1 را به پشته لینوکس 2.6.26 NSC تغییر می‌دهد.
internetStack.Install (n. دریافت(0))؛
internetStack.Install (n. دریافت(1))؛

خط کلیدی است SetNscStack. این به کمک کننده InternetStack می گوید که جمع شود
نمونه هایی از NSC TCP به جای بومی ns-3 TCP به گره های باقی مانده. مهم است
که این تابع فراخوانی شود قبل از فراخوانی نصب() عملکرد، همانطور که در بالا نشان داده شده است.

کدام پشته ها برای استفاده در دسترس هستند؟ در حال حاضر، تمرکز بر لینوکس 2.6.18 و لینوکس بوده است
2.6.26 پشته برای ns-3. برای مشاهده اینکه کدام پشته ها ساخته شده اند، می توان یافت زیر را اجرا کرد
فرمان در ns-3 دایرکتوری سطح بالا:

$ find nsc -name "*.so" -تایپ f
nsc/linux-2.6.18/liblinux2.6.18.so
nsc/linux-2.6.26/liblinux2.6.26.so

این به ما می گوید که ممکن است نام کتابخانه liblinux2.6.18.so را ارسال کنیم یا
liblinux2.6.26.so به مرحله پیکربندی بالا.

پشته پیکر بندی
NSC TCP دارای همان ویژگی های پیکربندی است که در بین سوکت های TCP رایج است
شرح داده شده در بالا و مستند در اکسیژن

علاوه بر این، NSC TCP بسیاری از متغیرهای پیکربندی را به داخل صادر می کند ns-3 خواص
سیستم، از طریق a Sysctlرابط -مانند. در examples/tcp/tcp-nsc-zoo به عنوان مثال، می توانید ببینید
پیکربندی زیر:

// این TCP SACK، wscale و مهرهای زمانی را در گره 1 غیرفعال می کند (ویژگی ها
مقادیر sysctl را نشان می دهد).
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"));

این متغیرهای پیکربندی اضافی برای بومی در دسترس نیستند ns-3 TCP

همچنین توجه داشته باشید که مقادیر پیش فرض برای ویژگی های TCP در ns-3 TCP ممکن است با nsc TCP متفاوت باشد
پیاده سازی. به طور مشخص در ns-3:

1. TCP پیش فرض MSS 536 است

2. تعداد Ack تاخیری TCP 2 است

بنابراین هنگام مقایسه بین نتایج به دست آمده با استفاده از nsc و ns-3 TCP، مراقبت
باید برای اطمینان از تنظیم مناسب این مقادیر انجام شود. دیدن
/examples/tcp/tcp-nsc-comparision.cc برای مثال.

شورای امنیت ملی API
این بخش API را که NSC به آن ارائه می‌کند، توضیح می‌دهد ns-3 یا هر شبیه ساز دیگری NSC
API خود را در قالب تعدادی کلاس که در آن تعریف شده اند ارائه می دهد
SIM/SIM_INTERFACE.H در دایرکتوری nsc

· INetStack INetStack شامل عملیات سطح پایین برای شبکه سیستم عامل است
پشته، به عنوان مثال توابع ورودی و خروجی از و به پشته شبکه (به این عنوان فکر کنید
"رابط درایور شبکه". همچنین توابعی برای ایجاد سوکت های TCP یا UDP جدید وجود دارد.

· ISendCallback هنگامی که یک بسته باید به شبکه ارسال شود توسط NSC فراخوانی می شود.
این شبیه ساز باید از این callback برای تزریق مجدد بسته به شبیه ساز استفاده کند
داده های واقعی را می توان به مقصد خود، جایی که در نهایت خواهد بود، تحویل/مسیر کرد
به Receive() تحویل داده می شود (و در نهایت از طریق نمونه NSC به گیرنده ها باز می گردد
INetStack->if_receive()).

· INetStreamSocket این ساختاری است که یک نقطه پایانی اتصال خاص (فایل
توصیفگر). این شامل روش هایی برای کار در این نقطه پایانی است، به عنوان مثال اتصال، قطع،
پذیرش، گوش دادن، ارسال_داده/خواندن_داده،...

· پاسخ تماس قطعی این شامل پاسخ تماس بیداری است که هر زمان توسط NSC فراخوانی می شود
اتفاق جالبی می افتد به wakeup() به عنوان جایگزینی برای عملیات فکر کنید
عملکرد بیدار شدن سیستم ها: هر زمان که سیستم عامل فرآیندی را بیدار کند
منتظر تکمیل یک عملیات (مثلاً دست دادن TCP در حین).
connect())، NSC فراخوانی wakeup() را فراخوانی می کند تا به شبیه ساز اجازه دهد وضعیت را بررسی کند
تغییرات در نقاط پایانی اتصال آن

ns-3 پیاده سازی
La ns-3 پیاده سازی از NSC API فوق استفاده می کند و به صورت زیر پیاده سازی می شود.

سه بخش اصلی عبارتند از:

· ns3::پروتکل NscTcpL4: یک زیر کلاس از پروتکل Ipv4L4 (و دو کلاس nsc: ISendCallback
و II interruptCallback)

· ns3::NscTcpSocketImpl: یک زیر کلاس از TcpSocket

· ns3::NscTcpSocketFactoryImpl: کارخانه ای برای ایجاد سوکت های جدید NSC

src/internet/model/nsc-tcp-l4-protocol کلاس اصلی است پس از مقداردهی اولیه، آن را بارگذاری می کند
پشته شبکه nsc برای استفاده (از طریق dlopen()). هر نمونه از این کلاس ممکن است از نمونه متفاوتی استفاده کند
پشته. پشته (=کتابخانه مشترک) برای استفاده با استفاده از متد SetNscLibrary() تنظیم شده است (در اینجا
زمان آن به طور غیرمستقیم از طریق راهنما پشته اینترنت فراخوانی می شود). سپس پشته nsc راه اندازی می شود
بر این اساس (تایمر و غیره). تابع NscTcpL4Protocol::Receive آن را به بسته تحویل می دهد
دریافت می کند (باید یک بسته tcp/ip کامل باشد) به پشته nsc برای پردازش بیشتر. به
قادر به ارسال بسته ها باشد، این کلاس متد nsc send_callback را پیاده سازی می کند. این روش
هر زمان که پشته nsc بخواهد بسته ای را به شبکه ارسال کند توسط nsc فراخوانی می شود. آن
آرگومان ها یک بافر خام هستند که حاوی یک بسته TCP/IP کامل و یک مقدار طول هستند. این
بنابراین روش باید داده های خام را به Ptr تبدیل کند قابل استفاده توسط ns-3. به منظور
از مسائل مختلف هدر ipv4 اجتناب کنید، هدر IP nsc گنجانده نشده است. در عوض، tcp
هدر و بار واقعی در Ptr قرار می گیرند ، پس از این Packet است
برای ارسال بسته به لایه 3 منتقل می شود (به درمان خاصی نیاز نیست
در مسیر ارسال کد).

این کلاس تماس می گیرد ns3::NscTcpSocketImpl هم از nsc wakeup () و هم از
مسیر دریافت (برای اطمینان از اینکه داده های احتمالاً در صف برای ارسال برنامه ریزی شده است).

src/internet/model/nsc-tcp-socket-impl رابط سوکت nsc را پیاده سازی می کند. هر نمونه
nscTcpSocket خود را دارد. داده هایی که Send() هستند از طریق به پشته nsc تحویل داده می شوند
m_nscTcpSocket->send_data(). (و نه به nsc-tcp-l4، این تفاوت عمده در مقایسه است
به ns-3 TCP). کلاس همچنین داده‌هایی را که Send() قبل از زیربنایی است در صف قرار می‌دهد
توصیفگر وارد حالت ESTABLISHED شده است. این کلاس از nsc-tcp-l4 فراخوانی می شود
کلاس، زمانی که فراخوانی nsc-tcp-l4 wakeup() توسط nsc فراخوانی می شود. سپس nsc-tcp-socket-impl
وضعیت اتصال فعلی (SYN_SENT، ESTABLISHED، LISTEN...) را بررسی می کند و زمان بندی می کند
تماس‌های مناسب در صورت لزوم، به عنوان مثال، یک سوکت LISTEN، Accept را برنامه‌ریزی می‌کند تا ببیند آیا جدید است یا خیر
اتصال باید پذیرفته شود، یک سوکت ESTABLISHED هرگونه داده معلق را برای نوشتن برنامه ریزی می کند،
برنامه‌ریزی برای پاسخ به تماس خواندن و غیره

توجه داشته باشید که ns3::NscTcpSocketImpl به طور مستقیم با nsc-tcp تعامل نمی کند: در عوض، داده ها هستند
به nsc هدایت شد. nsc-tcp سوکت‌های nsc-tcp یک گره را زمانی فراخوانی می‌کند که پاسخ تماس بیدارکننده آن باشد.
استناد شده توسط nsc.

محدودیت ها
· NSC فقط روی گره های تک رابط کار می کند. تلاش برای اجرای آن بر روی یک گره چند رابط
باعث خطای برنامه می شود.

· Cygwin و OS X PPC پشتیبانی نمی شوند. OS X Intel پشتیبانی نمی شود اما ممکن است کار کند

· پشته های غیر لینوکس NSC در پشتیبانی نمی شوند ns-3

· همه تماس های سوکت API پشتیبانی نمی شوند

برای اطلاعات بیشتر، نگاه کنید به این ویکی با ما.

CoDel صف پیاده سازی in ns-3
این فصل اجرای صف CoDel ([Nic12], [Nic14]) را در ns-3.

توسط Kathleen Nichols و Van Jacobson به عنوان راه حلی برای نفخ بافر توسعه داده شد [Buf14]
مشکل، CoDel (مدیریت تاخیر کنترل شده) یک رشته در صف است که از یک بسته استفاده می کند.
زمان اقامت (زمان در صف) برای تصمیم گیری در مورد رها کردن بسته ها.

مدل توضیحات:
کد منبع مدل CoDel در دایرکتوری قرار دارد src/اینترنت/مدل و
شامل 2 فایل codel-queue.h و codel-queue.cc تعریف یک کلاس CoDelQueue و a
کلاس کمکی CoDelTimestampTag. کد به آن منتقل شد ns-3 توسط اندرو مک گرگور بر اساس
کد هسته لینوکس توسط Dave Täht و Eric Dumazet پیاده سازی شده است.

· کلاس کدی: این کلاس الگوریتم اصلی CoDel را پیاده سازی می کند:

· Codelqueue :: doenqueue (): این روال یک بسته را با زمان فعلی قبل برچسب گذاری می کند
هل دادن آن به صف برچسب زمان استفاده می شود توسط CoDelQueue::DoDequeue() به
زمان اقامت بسته را محاسبه کنید اگر صف با رسیدن بسته پر است، این
روتین بسته را رها می کند و تعداد افت های ناشی از سرریز صف را ثبت می کند.
که در آن ذخیره می شود m_dropOverLimit.

· CoDelQueue::ShouldDrop (): این روال است CoDelQueue::DoDequeue()روال کمکی
که تعیین می کند بسته به زمان اقامتش باید رها شود یا نه.
اگر مدت اقامت بیشتر شود m_target و حداقل به طور مداوم در بالا باقی می ماند
m_فاصله، روال برمی گردد درست نشان می دهد که حذف بسته مشکلی ندارد.
در غیر این صورت برمی گردد غلط.

· Codelqueue :: dodequeue (): این روال افت واقعی بسته را بر اساس انجام می دهد
CoDelQueue::ShouldDrop ()'s مقدار را برمی گرداند و قطره بعدی را برنامه ریزی می کند.

· کلاس CoDelTimestampTag: این کلاس برچسب گذاری مهر زمانی را برای یک بسته پیاده سازی می کند. این
تگ برای محاسبه زمان اقامت بسته (تفاوت بین زمان ) استفاده می شود
بسته در صف قرار می گیرد و زمانی که در صف قرار می گیرد).

2 شعبه به Codelqueue :: dodequeue ():

1. اگر صف در حال حاضر در حالت حذف است، به این معنی که زمان اقامت دارد
بالا باقی ماند m_target برای بیش از m_فاصله، روال تعیین می کند که آیا خوب است یا خیر
حالت افتادن را رها کنید یا زمان قطره بعدی فرا رسیده است. چه زمانی CoDelQueue::ShouldDrop ()
بازده غلط، صف می تواند از حالت افت خارج شود (تنظیم m_dropping به غلط).
در غیر این صورت، صف به طور مداوم بسته ها را رها می کند و زمان برای قطره بعدی را به روز می کند
(m_dropNext) تا زمانی که یکی از شرایط زیر برآورده شود:

1. صف خالی است که صف از حالت افت خارج شده و خارج می شود
CoDelQueue::ShouldDrop () روتین؛

2. CoDelQueue::ShouldDrop () بازده غلط (یعنی زمان اقامت کمتر می شود
m_target) که صف از حالت افت خارج می شود.

3. هنوز زمان قطره بعدی نرسیده است (m_dropNext کمتر از زمان فعلی است).
که صف منتظر بسته بعدی می ماند تا دوباره وضعیت را بررسی کند.

2. اگر صف در حالت افت نباشد روتین وارد حالت افت می شود و
اگر بسته اول را رها کنید CoDelQueue::ShouldDrop () بازده درست (به معنای غربت
زمان بالاتر رفته است m_target برای حداقل m_فاصله برای اولین بار یا رفته است
بعد از اینکه صف از حالت افت خارج شد، دوباره در بالا.

منابع
[Nic12]

K. Nichols and V. Jacobson, Controlling Queue Delay, ACM Queue, Vol. 10 شماره 5، مه 2012.
در دسترس آنلاین در http://queue.acm.org/detail.cfm؟ id = 2209336.

[Nic14]

K. Nichols and V. Jacobson, Internet-Draft: Controlled Delay Active Queue Management,
مارس 2014. موجود آنلاین در
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Buf14]
Bufferbloat.net. در دسترس آنلاین در http://www.bufferbloat.net/.

خواص
ویژگی های کلیدی که کلاس CoDelQueue دارد شامل موارد زیر است:

· حالت: حالت کار CoDel (BYTES، PACKETS یا ILLEGAL). حالت پیش فرض BYTES است.

· MaxPackets: حداکثر تعداد بسته هایی که صف می تواند نگه دارد. مقدار پیش فرض است
DEFAULT_CODEL_LIMIT، که 1000 بسته است.

· MaxBytes: حداکثر تعداد بایت هایی که صف می تواند نگه دارد. مقدار پیش فرض 1500 * است
DEFAULT_CODEL_LIMIT، که 1500 * 1000 بایت است.

· minbytes: پارامتر الگوریتم CoDel minbytes. مقدار پیش فرض 1500 بایت است.

· فاصله: پنجره حداقل کشویی. مقدار پیش فرض 100 میلی ثانیه است.

· هدف: الگوریتم CoDel تاخیر صف را هدف قرار می دهد. مقدار پیش فرض 5 میلی ثانیه است.

مثال ها
اولین مثال این است codel-vs-droptail-basic-test.cc واقع در src/اینترنت/نمونه ها. به
فایل را اجرا کنید (نخستین فراخوانی زیر گزینه های موجود در خط فرمان را نشان می دهد):

$ ./waf --اجرای "codel-vs-droptail-basic-test --PrintHelp"
$ ./waf --run "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

خروجی مورد انتظار از دستورات قبلی دو فایل است: codel.pcap فایل و
cwndCoDel.tr فایل (ردیابی ASCII) فایل pcap. را می توان با استفاده از wireshark یا تجزیه و تحلیل کرد
tcptrace:

$ tcptrace -l -r -n -W codel.pcap

مثال دوم این است codel-vs-droptail-asymmetric.cc واقع در src/اینترنت/نمونه ها.
این مثال برای مدل سازی یک سناریوی معمولی استقرار مودم کابلی در نظر گرفته شده است. برای اجرای
فایل:

$ ./waf -- run "codel-vs-droptail-asymmetric --PrintHelp"
$ ./waf --run codel-vs-droptail-asymmetric

خروجی مورد انتظار از دستورات قبلی شش فایل pcap است:

· codel-vs-droptail-asymmetric-CoDel-server-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-wan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-cmts-wan.pcap

· codel-vs-droptail-asymmetric-CoDel-cmts-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-host-lan.pcap

یک فایل ویژگی:

· codel-vs-droptail-asymmetric-CoDel.attr

پنج فایل ردیابی ASCII:

· codel-vs-droptail-asymmetric-CoDel-drop.tr

· codel-vs-droptail-asymmetric-CoDel-drop-state.tr

· codel-vs-droptail-asymmetric-CoDel-sojourn.tr

· codel-vs-droptail-asymmetric-CoDel-length.tr

· codel-vs-droptail-asymmetric-CoDel-cwnd.tr

اعتبار
مدل CoDel با استفاده از تست شده است CoDelQueueTestSuite کلاس تعریف شده در
src/internet/test/codel-queue-test-suite.cc. این مجموعه شامل 5 مورد تست است:

· تست 1: اولین آزمون صف/تخم بدون افت را بررسی می کند و از آن مطمئن می شود
ویژگی های CoDel را می توان به درستی تنظیم کرد.

· تست 2: تست دوم صف را با افت به دلیل سرریز صف بررسی می کند.

· تست 3: تست سوم محاسبات NewtonStep() را در برابر پورت صریح لینوکس بررسی می کند.
پیاده سازی

· تست 4: تست چهارم ControlLaw() را در برابر پورت صریح لینوکس بررسی می کند
پیاده سازی

· تست 5: آزمون پنجم مطابق با CoDel، صف/دو صف را با افت چک می کند.
الگوریتم

مجموعه تست را می توان با استفاده از دستورات زیر اجرا کرد:

$ ./waf پیکربندی --enable-examples --enable-tests
$ ./waf ساخت
$ ./test.py -s codel-queue

or

$ NS_LOG="CoDelQueue" ./waf --run "test-runner --suite=codel-queue"
Page Break

نرخ پایین بی سیم شخصی محدوده شبکه (LR-WPAN)

این فصل پیاده‌سازی مدل‌های ns-3 را برای بی‌سیم با نرخ پایین توصیف می‌کند
شبکه شخصی (LR-WPAN) همانطور که توسط استاندارد IEEE 802.15.4 (2006) مشخص شده است.

مدل توضیحات:
کد منبع ماژول lr-wpan در فهرست موجود است src/lr-wpan.

طرح
طراحی مدل از نقطه نظر معماری دقیقاً از استاندارد پیروی می کند.
[تصویر] معماری و محدوده مدل های lr-wpan.UNINDENT

مناطق خاکستری در شکل (اقتباس شده از شکل 3 از IEEE Std. 802.15.4-2006)
محدوده مدل

Spectrum NetDevice از Nicola Baldo اساس پیاده سازی است.

این پیاده سازی همچنین قصد دارد از مدل های ns-2 توسعه یافته توسط ژنگ و لی وام بگیرد
در آینده است.

رابط های برنامه کاربردی
APIها دقیقاً از استاندارد پیروی می کنند که برای قراردادها و اصطلاحات نامگذاری ns-3 اقتباس شده است. را
APIها حول مفهوم خدمات اولیه سازماندهی شده اند که در زیر نشان داده شده است
شکل اقتباس شده از شکل 14 از IEEE Std. 802.15.4-2006.
[تصویر] سرویس اولیه.UNINDENT

API ها حول چهار سرویس مفهومی و نقطه دسترسی سرویس (SAP) سازماندهی شده اند:

· سرویس داده MAC (MCPS)

· سرویس مدیریت MAC (MLME)

· سرویس داده PHY (PD)

· خدمات مدیریت PHY (PLME)

به طور کلی، اولیه ها به شرح زیر استاندارد می شوند (به عنوان مثال بخش 7.1.1.1.1 IEEE
802.15.4-2006)::

درخواست MCPS-DATA (
SrcAddrMode،
DstAddrMode،
DstPANid،
DstAddr،
msdu طول،
msdu،
msduHandle،
TxOptions،
سطح امنیت،
KeyIdMode،
منبع کلیدی،
KeyIndex
)

این به کلاس ها و روش های ns-3 مانند:

ساخت McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

از درجه اعتبار ساقط
LrWpanMac::McpsDataRequest (پارامترهای McpsDataRequestParameters)
{
...
}

MAC
MAC در حال حاضر نوع بدون شکاف CSMA/CA را بدون استفاده از بیکنینگ پیاده سازی می کند. در حال حاضر
هیچ پشتیبانی از هماهنگ کننده ها و API های مربوطه وجود ندارد.

MAC پیاده سازی شده مشابه NullMAC Contiki است، یعنی MAC بدون ویژگی های خواب.
فرض بر این است که رادیو همیشه فعال (دریافت یا ارسال کننده)، کاملاً بسته است
پایین. دریافت فریم هنگام انجام CCA غیرفعال نمی شود.

API اصلی پشتیبانی شده API انتقال داده (McpsDataRequest/Indication/Confirm) است.
CSMA/CA طبق Stc 802.15.4-2006، بخش 7.5.1.4 پشتیبانی می شود. پذیرایی قاب و
رد طبق Std 802.15.4-2006، بخش 7.5.6.2 پشتیبانی می شود، از جمله
سپاسگزاریها. فقط آدرس کوتاه به طور کامل اجرا شده است. منابع ردیابی مختلف هستند
پشتیبانی می شود و منابع ردیابی را می توان به سینک ها متصل کرد.

PHY
اجزای لایه فیزیکی شامل یک مدل Phy، یک مدل نرخ خطا و یک ضرر است
مدل. مدل نرخ خطا در حال حاضر نرخ خطا را برای IEEE 802.15.4 2.4 گیگاهرتز مدل می کند.
کانال AWGN برای OQPSK؛ شرح مدل را می توان در IEEE Std 802.15.4-2006 یافت،
بخش E.4.1.7. مدل Phy بر اساس SpectrumPhy است و از مشخصات پیروی می کند
شرح داده شده در بخش 6 IEEE Std 802.15.4-2006. این مدل مشخصات سرویس PHY،
فرمت‌های PPDU، ثابت‌های PHY و ویژگی‌های PIB. در حال حاضر فقط از انتقال پشتیبانی می کند
ماسک چگالی طیفی توان مشخص شده در 2.4 گیگاهرتز در هر بخش 6.5.3.1. قدرت نویز
چگالی فرض می کند که نویز حرارتی به طور یکنواخت در سراسر باندهای فرکانسی توزیع شده است. از دست دادن
مدل می تواند به طور کامل از تمام مدل های از دست دادن ساده (غیر طیفی) موجود استفاده کند. مدل Phy
از مدل کانال تک طیفی موجود استفاده می کند. لایه فیزیکی بر روی بسته مدل سازی شده است
سطح، یعنی هیچ تشخیص مقدمه/SFD انجام نمی شود. دریافت بسته با آغاز خواهد شد
بیت اول مقدمه (که مدل سازی نشده است)، اگر SNR بیش از -5 دسی بل است، نگاه کنید به
IEEE Std 802.15.4-2006، پیوست E، شکل E.2. پس از دریافت بسته به پایان می رسد
بسته به طور کامل ارسال شد. بسته های دیگری که در طول پذیرش می رسند اضافه می شوند
به تداخل/نویز.

در حال حاضر حساسیت گیرنده روی مقدار ثابت -106.58 dBm تنظیم شده است. این
مربوط به نرخ خطای بسته 1٪ برای بسته های مرجع 20 بایتی برای این سیگنال است.
قدرت، طبق IEEE Std 802.15.4-2006، بخش 6.1.7. در آینده ارائه خواهیم داد
پشتیبانی از تغییر حساسیت به مقادیر مختلف
[تصویر] میزان خطای بسته در مقابل قدرت سیگنال.UNINDENT

NetDevice
اگرچه انتظار می رود که پروفایل های فناوری دیگر (مانند 6LoWPAN و ZigBee) این کار را انجام دهند
کلاس های NetDevice خود را بنویسند، یک LrWpanNetDevice اساسی ارائه شده است که کپسوله می کند
عملیات مشترک ایجاد یک دستگاه LrWpan عمومی و اتصال چیزها به یکدیگر.

حوزه و محدودیت ها
نسخه‌های بعدی این سند حاوی پیش‌فرم PICS مشابه ضمیمه D خواهد بود
IEEE 802.15.4-2006. تاکید فعلی بر روی حالت بدون شکاف عملکرد 802.15.4 است
برای استفاده در Zigbee، و دامنه محدود به فعال کردن یک حالت واحد (CSMA/CA) با پایه است
قابلیت های انتقال داده ارتباط با هماهنگ‌کنندگان PAN هنوز پشتیبانی نمی‌شود
استفاده از آدرس دهی توسعه یافته تداخل به عنوان AWGN مدل شده است اما در حال حاضر اینطور نیست
کاملا تست شده

صف NetDevice Tx محدود نیست، به عنوان مثال، بسته ها هرگز به دلیل صف حذف نمی شوند.
پر شدن آنها ممکن است به دلیل تلاش های مجدد ارسال بیش از حد یا دسترسی به کانال حذف شوند
شکست.

منابع
· مشخصات کنترل دسترسی متوسط ​​بی سیم (MAC) و لایه فیزیکی (PHY) برای
شبکه‌های شخصی بی‌سیم با نرخ پایین (WPAN)، انجمن رایانه‌ای IEEE، IEEE Std
802.15.4-2006، 8 سپتامبر 2006.

·

J. Zheng و Myung J. Lee، "مطالعه عملکرد جامع IEEE 802.15.4"، حسگر
عملیات شبکه، IEEE Press، Wiley Interscience، فصل 4، صفحات 218-237، 2006.

استفاده
را قادر می سازد lr-wpan
اضافه کردن lr-wpan به لیست ماژول های ساخته شده با ns-3.

کمک کننده
کمک کننده پس از سایر کمک کننده های دستگاه الگوبرداری شده است. به طور خاص، ردیابی (ascii و
pcap) به طور مشابه فعال است، و فعال کردن تمام اجزای گزارش lr-wpan انجام می شود
به طور مشابه استفاده از کمک کننده در نمونه است examples/lr-wpan-data.cc. برای آسکی
ردیابی، ردیابی ارسال و دریافت در لایه مک قلاب می شود.

مدل تلفات انتشار پیش‌فرض اضافه شده به کانال، زمانی که از این کمک کننده استفاده می‌شود، این است
LogDistancePropagationLossModel با پارامترهای پیش فرض.

مثال ها
نمونه های زیر نوشته شده است که می توان آنها را در src/lr-wpan/examples/:

· lr-wpan-data.cc: یک مثال ساده که انتقال داده ها را از سر به انتها نشان می دهد.

· lr-wpan-error-sistance-plot.cc: نمونه ای برای ترسیم تغییرات موفقیت بسته
نسبت به عنوان تابعی از فاصله

· lr-wpan-error-model-plot.cc: مثالی برای تست phy.

· lr-wpan-packet-print.cc: نمونه ای برای چاپ فیلدهای هدر MAC.

· lr-wpan-phy-test.cc: مثالی برای تست phy.

به طور خاص، ماژول یک سناریوی بسیار ساده‌شده برای انتقال داده‌ها را فعال می‌کند.
اجرا شده در lr-wpan-data.cc. شکل دنباله ای از رویدادها را نشان می دهد که آغاز شده اند
زمانی که MAC یک DataRequest از لایه بالاتر دریافت می کند. یک کانال پاک را فراخوانی می کند
ارزیابی (CCA) از PHY، و در صورت موفقیت آمیز بودن، فریم را به PHY پایین می فرستد.
از طریق کانال منتقل می شود و منجر به DataIndication در گره همتا می شود.
[تصویر] نمونه داده برای انتقال داده LR-WPAN ساده از سرتاسر.UNINDENT

مثال lr-wpan-error-sistance-plot.cc نسبت موفقیت بسته (PSR) را به صورت یک رسم می کند
تابع فاصله، با استفاده از مدل از دست دادن انتشار پیش فرض LogDistance و
مدل خطای 802.15.4. کانال (پیش‌فرض 11)، اندازه بسته (پیش‌فرض 20 بایت) و
قدرت انتقال (پیش‌فرض 0 dBm) را می‌توان با آرگومان‌های خط فرمان تغییر داد. برنامه
خروجی فایلی به نام 802.15.4-psr-distance.plt. با بارگذاری این فایل در gnuplot a
پرونده 802.15.4-psr-distance.eps، که می تواند به pdf یا فرمت های دیگر تبدیل شود. این
خروجی پیش فرض در زیر نشان داده شده است.
[تصویر] خروجی پیش فرض برنامه lr-wpan-error-sistance-plot.cc.UNINDENT

تست
تست های زیر نوشته شده است که می توانید آنها را پیدا کنید src/lr-wpan/tests/:

· lr-wpan-ack-test.cc: بررسی کنید که تأییدیه ها در حال استفاده و صدور هستند
سفارش صحیح.

· lr-wpan-collision-test.cc: تست دریافت صحیح بسته ها با تداخل و
برخوردها

· lr-wpan-error-model-test.cc: بررسی کنید که مدل خطا مقادیر قابل پیش بینی بدهد.

· lr-wpan-packet-test.cc: کلاس های هدر/تریلر MAC 802.15.4 را تست کنید

· lr-wpan-pd-plme-sap-test.cc: PLME و PD SAP را در IEEE 802.15.4 تست کنید

· lr-wpan-spectrum-value-helper-test.cc: تست کنید که تبدیل بین قدرت
(به صورت کمیت اسکالر بیان می شود) و توان طیفی، و دوباره، در 25٪ قرار می گیرد.
تحمل در طیف وسیعی از کانال های ممکن و توان های ورودی.

اعتبار
مدل در برابر سخت افزار واقعی تایید نشده است. مدل خطا بوده است
در برابر داده های IEEE Std 802.15.4-2006، بخش E.4.1.7 (شکل E.2) اعتبارسنجی شده است. را
رفتار MAC (CSMA backoff) با دست در برابر رفتار مورد انتظار تأیید شده است. را
نمودار زیر نمونه ای از اعتبارسنجی مدل خطا است و می توان آن را با اجرا دوباره تولید کرد
lr-wpan-error-model-plot.cc:
[تصویر] خروجی پیش فرض برنامه lr-wpan-error-model-plot.cc.UNINDENT

LTE MODULE

طرح مستندات
بررسی اجمالی
یک نمای کلی از مدل شبیه سازی LTE-EPC در شکل نشان داده شده است بررسی اجمالی of la
LTE-EPC شبیه سازی مدل. دو جزء اصلی وجود دارد:

· مدل LTE. این مدل شامل پشته پروتکل رادیویی LTE (RRC، PDCP، RLC، MAC،
PHY). این موجودیت ها به طور کامل در گره های UE و eNB قرار دارند.

· مدل EPC. این مدل ها شامل رابط های شبکه اصلی، پروتکل ها و موجودیت ها می باشد.
این موجودیت ها و پروتکل ها در گره های SGW، PGW و MME و تا حدی قرار دارند.
در گره های eNB
[تصویر] نمای کلی مدل شبیه سازی LTE-EPC.UNINDENT

طرح ضوابط
LTE مدل
مدل LTE برای پشتیبانی از ارزیابی جنبه های زیر LTE طراحی شده است
سیستم های:

· مدیریت منابع رادیویی

· زمانبندی بسته آگاه از QoS

· هماهنگی تداخل بین سلولی

· دسترسی به طیف پویا

به منظور مدل سازی سیستم های LTE تا سطحی از جزئیات که امکان درستی را فراهم می کند
ارزیابی جنبه های ذکر شده در بالا، الزامات زیر بوده است
در نظر گرفته شده:

1. در سطح رادیویی، دانه بندی مدل باید حداقل باشد
بلوک منابع (RB). در واقع، این واحد اساسی است که برای منبع استفاده می شود
تخصیص بدون این حداقل سطح دانه بندی، امکان مدل سازی وجود ندارد
زمان‌بندی بسته‌ها و تداخل بین سلولی با دقت. دلیل این است که، از آنجا که
زمان‌بندی بسته‌ها بر اساس هر RB انجام می‌شود، eNB ممکن است فقط بر روی یک زیر مجموعه ارسال کند.
از همه RB های موجود، از این رو با دیگر eNB ها فقط در آن RB هایی که در آن ها تداخل دارند
در حال انتقال است. توجه داشته باشید که این الزام، پذیرش یک سیستم را منتفی می کند
رویکرد شبیه‌سازی سطح، که تخصیص منابع را تنها در سطح ارزیابی می‌کند
ریزه کاری برقراری تماس/ حامل.

2. شبیه‌ساز باید تا ده‌ها eNB و صدها تجهیزات کاربر (UEs) را مقیاس‌بندی کند.
این امر استفاده از شبیه ساز سطح پیوند، به عنوان مثال، شبیه سازی رادیویی را منتفی می کند
رابط با یک دانه بندی تا سطح نماد مدل سازی شده است. این به این دلیل است که به
داشتن یک مدل سطح نماد، لازم است تمام سیگنال لایه PHY پیاده سازی شود
پردازش، که پیچیدگی محاسباتی عظیم آن شبیه سازی را به شدت محدود می کند. در حقیقت،
شبیه سازهای سطح پیوند معمولاً به یک eNB و یک یا چند UE محدود می شوند.

3. باید در داخل شبیه سازی امکان پیکربندی سلول های مختلف وجود داشته باشد تا
آنها از فرکانس های حامل مختلف و پهنای باند سیستم استفاده می کنند. پهنای باند استفاده شده توسط
سلول‌های مختلف باید اجازه داشته باشند که با هم همپوشانی داشته باشند تا از طیف پویا پشتیبانی کنند
راه حل های صدور مجوز مانند مواردی که در [Ofcom2600MHz] و [RealWireless] توضیح داده شده است.
محاسبه تداخل باید به طور مناسب این مورد را مدیریت کند.

4. معرف بیشتر استاندارد LTE و همچنین نزدیک بودن هر چه بیشتر
برای پیاده سازی های دنیای واقعی، شبیه ساز باید از MAC Scheduler API پشتیبانی کند
منتشر شده توسط FemtoForum [FFAPI]. انتظار می رود این رابط مورد استفاده قرار گیرد
سازندگان فمتوسل برای اجرای برنامه ریزی و منابع رادیویی
الگوریتم های مدیریت (RRM) با معرفی پشتیبانی از این رابط در
شبیه ساز، ما این امکان را برای فروشندگان و اپراتورهای تجهیزات LTE فراهم می کنیم تا در الف
محیط شبیه سازی دقیقا همان الگوریتم هایی است که در یک واقعی مستقر می شوند
سیستم.

5. مدل شبیه سازی LTE باید شامل پیاده سازی خود از API تعریف شده در باشد
[FFAPI]. نه باینری و نه ساختار داده سازگار با فروشنده خاص
اجرای همان رابط مورد انتظار است. از این رو، یک لایه سازگاری
هر زمان که قرار است از یک زمانبندی MAC خاص فروشنده با آن استفاده شود، باید وارد شود
شبیه ساز این شرط لازم است تا شبیه ساز مستقل باشد
از پیاده سازی های خاص فروشنده این مشخصات رابط. توجه می کنیم که
[FFAPI] فقط یک مشخصات منطقی است و اجرای آن (مثلاً ترجمه
به برخی از زبان های برنامه نویسی خاص) به فروشندگان واگذار می شود.

6. این مدل برای شبیه سازی انتقال بسته های IP توسط قسمت بالایی استفاده می شود
لایه های. از این نظر باید در نظر گرفت که در LTE زمانبندی و
مدیریت منابع رادیویی مستقیماً با بسته های IP کار نمی کند، بلکه با RLC کار می کند
PDU ها، که با تقسیم بندی و الحاق بسته های IP انجام شده توسط
نهادهای RLC از این رو، این قابلیت های لایه RLC باید مدل شوند
به درستی.

EPC مدل
هدف اصلی مدل EPC ارائه ابزاری برای شبیه‌سازی انتها به انتها است
اتصال IP از طریق مدل LTE. برای این هدف، از اتصال متقابل پشتیبانی می کند
چندین UE به اینترنت، از طریق یک شبکه دسترسی رادیویی از چندین eNB متصل به a
گره تک SGW/PGW، همانطور که در شکل نشان داده شده است بررسی اجمالی of la LTE-EPC شبیه سازی مدل.

انتخاب های طراحی زیر برای مدل EPC انجام شده است:

1. تنها نوع شبکه داده بسته (PDN) پشتیبانی شده IPv4 است.

2. موجودیت های عملکردی SGW و PGW در یک گره واحد پیاده سازی می شوند که این است
از این رو به عنوان گره SGW/PGW نامیده می شود.

3. سناریوهای با تحرک بین SGW مورد علاقه نیستند. از این رو، یک SGW/PGW واحد
گره در تمام سناریوهای شبیه سازی وجود خواهد داشت

4. لازمه مدل EPC این است که بتوان از آن برای شبیه سازی انتها به انتها استفاده کرد.
عملکرد برنامه های کاربردی واقع بینانه از این رو، باید امکان استفاده با
EPC هر برنامه معمولی ns-3 را که روی TCP یا UDP کار می کند، مدل کنید.

5. لازمه دیگر امکان شبیه سازی توپولوژی های شبکه با
وجود چندین eNB، که برخی از آنها ممکن است مجهز به backhaul باشند
ارتباط با قابلیت های محدود به منظور شبیه سازی چنین سناریوهایی، کاربر
پروتکل های صفحه داده ای که بین eNB ها و SGW/PGW استفاده می شوند باید مدل شوند
به درستی.

6. باید برای یک UE منفرد این امکان وجود داشته باشد که از برنامه های مختلف با برنامه های مختلف استفاده کند
پروفایل های QoS بنابراین، چندین حامل EPS باید برای هر UE پشتیبانی شود. این
شامل طبقه بندی لازم ترافیک TCP/UDP روی IP انجام شده در UE in
uplink و در PGW در downlink.

7. تمرکز مدل EPC عمدتاً بر روی صفحه داده EPC است. مدل سازی دقیق از
هواپیمای کنترل EPC، در حال حاضر، الزامی نیست. از این رو
فعل و انفعالات سطح کنترل لازم را می توان به روشی ساده مدلسازی کرد
اعمال نفوذ بر تعامل مستقیم بین اشیاء شبیه سازی مختلف از طریق
اشیاء کمکی ارائه کرد.

8. تمرکز مدل EPC بر روی شبیه سازی کاربران فعال در حالت متصل ECM است.
از این رو، تمام عملکردهایی که فقط برای حالت بیکار ECM مرتبط هستند (به ویژه،
به روز رسانی و صفحه بندی منطقه ردیابی) به هیچ وجه مدل سازی نشده است.

9. مدل باید امکان انجام یک تحویل مبتنی بر X2 را بین دو مورد فراهم کند
eNBs.

معماری
LTE مدل
UE معماری
معماری مدل پشته پروتکل رادیویی LTE UE در نشان داده شده است
آمار و ارقام LTE رادیو پروتکل پشته معماری برای la UE on la داده ها هواپیما و LTE رادیو
پروتکل پشته معماری برای la UE on la کنترل هواپیما که به ترتیب برجسته می شوند
صفحه داده و صفحه کنترل.
[تصویر] معماری پشته پروتکل رادیویی LTE برای UE در صفحه داده.UNINDENT
[تصویر] معماری پشته پروتکل رادیویی LTE برای UE در صفحه کنترل.UNINDENT

معماری مدل PHY/کانال UE در شکل نشان داده شده است PHY و
کانال مدل معماری برای la UE.
[تصویر] PHY و معماری مدل کانال برای UE.UNINDENT

eNB معماری
معماری مدل پشته پروتکل رادیویی LTE از eNB در نشان داده شده است
آمار و ارقام LTE رادیو پروتکل پشته معماری برای la eNB on la داده ها هواپیما و LTE رادیو
پروتکل پشته معماری برای la eNB on la کنترل هواپیما که به ترتیب برجسته می شوند
صفحه داده و صفحه کنترل.
[تصویر] معماری پشته پروتکل رادیویی LTE برای eNB در صفحه داده.UNINDENT
[تصویر] معماری پشته پروتکل رادیویی LTE برای eNB در صفحه کنترل.UNINDENT

معماری مدل PHY/کانال eNB در شکل نشان داده شده است PHY و
کانال مدل معماری برای la eNB.
[تصویر] PHY و معماری مدل کانال برای eNB.UNINDENT

EPC مدل
EPC داده ها هواپیما
در شکل LTE-EPC داده ها هواپیما پروتکل پشته، ما داده های LTE-EPC سرتاسر را نشان می دهیم
پشته پروتکل هواپیما همانطور که در شبیه ساز مدل شده است. از شکل مشخص است
که بزرگترین ساده سازی معرفی شده در مدل صفحه داده، گنجاندن آن است
عملکرد SGW و PGW در یک گره SGW/PGW، که نیاز به S5 را برطرف می کند.
یا رابط های S8 مشخص شده توسط 3GPP. از سوی دیگر، برای هر دو پشته پروتکل S1-U
و پشته پروتکل رادیویی LTE تمام لایه های پروتکل مشخص شده توسط 3GPP وجود دارد.
[تصویر] پروتکل داده هواپیمای LTE-EPC پشته.UNINDENT

EPC کنترل هواپیما
معماری اجرای مدل صفحه کنترل در شکل نشان داده شده است EPC
کنترل مدل. رابط های کنترلی که به صراحت مدل شده اند S1-AP، X2-AP هستند
و رابط های S11.

ما توجه می کنیم که رابط های S1-AP و S11 به روشی ساده، توسط مدل سازی شده اند
با استفاده از تنها یک جفت کلاس رابط برای مدل سازی تعامل بین موجودیت هایی که
در گره های مختلف قرار دارند (eNB و MME برای رابط S1-AP، و MME و
SGW برای رابط S11). در عمل، این بدان معنی است که بدوی از این
رابط ها به یک فراخوانی مستقیم تابع بین دو شی نگاشت می شوند. از سوی دیگر
رابط X2-AP با استفاده از واحدهای داده پروتکل ارسال شده از طریق پیوند X2 مدل سازی می شود
(مدل سازی شده به عنوان پیوند نقطه به نقطه)؛ به همین دلیل، مدل رابط X2-AP بیشتر است
واقع بین.
[تصویر] مدل کنترل EPC.UNINDENT

کانال و انتشار
برای اهداف مدلسازی کانال، ماژول LTE از SpectrumChannel رابط ارائه شده است
توسط ماژول طیف در زمان نوشتن این مقاله، دو پیاده سازی از چنین رابط
موجود هستند: کانال SingleModelSpectrum و MultiModelSpectrumChannelو LTE
ماژول نیاز به استفاده از MultiModelSpectrumChannel تا به درستی کار کند این
به دلیل نیاز به پشتیبانی از تنظیمات فرکانس و پهنای باند مختلف است. همه
مدل های انتشار پشتیبانی شده توسط MultiModelSpectrumChannel را می توان در داخل استفاده کرد
ماژول LTE

استفاده کنید of la ساختمان مدل با LTE
مدل انتشار توصیه شده برای استفاده با ماژول LTE مدل ارائه شده توسط است
ماژول ساختمان ها، که در واقع به طور خاص با LTE طراحی شده است (اگرچه می تواند باشد
با سایر فناوری های بی سیم نیز استفاده می شود). لطفا به اسناد و مدارک مراجعه کنید
ماژول ساختمان ها برای اطلاعات عمومی در مورد مدل انتشار که ارائه می دهد.

در این بخش ما برخی از ملاحظات را برجسته خواهیم کرد که به طور خاص در زمانی اعمال می شوند
ماژول ساختمان ها همراه با ماژول LTE استفاده می شود.

قرارداد نامگذاری مورد استفاده در موارد زیر خواهد بود:

· تجهیزات کاربر: UE

· ایستگاه پایه ماکرو: MBS

· ایستگاه پایه سلول کوچک (مانند پیکو/فمتوسل): SC

ماژول LTE فقط FDD را در نظر می گیرد و انتشار لینک های پایین و بالا را پیاده سازی می کند
بصورت جداگانه. در نتیجه، محاسبات مسیر زیر انجام می شود

· MBS <-> UE (داخلی و بیرونی)

· SC (داخلی و بیرونی) <-> UE (داخلی و بیرونی)

مدل LTE محاسبات مسیر زیر را ارائه نمی دهد:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

مدل ساختمان ها نوع واقعی گره را نمی داند. یعنی آگاه نیست
چه یک گره فرستنده یک UE، یک MBS یا یک SC باشد. در عوض، مدل ساختمان ها فقط اهمیت می دهد
در مورد موقعیت گره: داخلی و خارجی بودن آن و محور z آن چیست
با توجه به سطح پشت بام در نتیجه، برای یک گره eNB که در فضای باز قرار می گیرد و
در مختصات z بالای سطح پشت بام، مدل های انتشار معمولی MBS خواهد بود
توسط ماژول ساختمان ها استفاده می شود. برعکس، برای eNB که در فضای باز اما در زیر قرار می گیرد
روی پشت بام یا داخل خانه، مدل‌های انتشار معمولی پیکو و فمتوسل‌ها استفاده خواهد شد.

برای ارتباطات شامل حداقل یک گره داخلی، نفوذ دیوار مربوطه
تلفات توسط مدل ساختمان ها محاسبه خواهد شد. این موارد موارد استفاده زیر را پوشش می دهد:

· MBS <-> UE داخلی

· فضای باز SC <-> داخلی UE

· SC داخلی <-> داخلی UE

· SC داخلی <-> فضای باز UE

لطفاً برای جزئیات بیشتر در مورد مدل های واقعی به مستندات ماژول ساختمان ها مراجعه کنید
در هر مورد استفاده می شود.

محو شدن مدل
ماژول LTE شامل یک مدل محو شدن مبتنی بر ردیابی است که از مدلی که در طول توسعه یافته است، مشتق شده است
GSoC 2010 [Piro2011]. ویژگی اصلی این مدل این واقعیت است که
ارزیابی محو شدن در طول زمان اجرا شبیه سازی بر اساس هر ردیابی محاسبه شده است. این هست
برای محدود کردن پیچیدگی محاسباتی شبیه ساز انجام شده است. از طرفی نیاز دارد
سازه های بزرگ برای ذخیره آثار؛ بنابراین، یک مبادله بین تعداد
پارامترهای ممکن و اشغال حافظه باید پیدا شود. مهمترین آنها عبارتند از:

· سرعت کاربران: سرعت نسبی بین کاربران (بر فرکانس داپلر تأثیر می گذارد که در
چرخش بر ویژگی واریانس زمانی محو شدن تأثیر می گذارد)

· تعداد ضربه ها (و توان نسبی): تعداد مسیرهای متعدد در نظر گرفته شده که
بر ویژگی فرکانس محو شدن تأثیر می گذارد.

· دانه بندی زمانی ردیابی: زمان نمونه برداری از ردیابی.

· دانه بندی فرکانس ردیابی: تعداد مقادیر در فرکانس که باید ارزیابی شوند.

· طول ردیابی: به طور ایده آل به اندازه زمان شبیه سازی بزرگ است، ممکن است با پنجره گذاری کاهش یابد
مکانیسم

· تعداد کاربران: تعداد ردیابی مستقل مورد استفاده (در حالت ایده آل یک ردیابی در هر
کاربر).

با توجه به مدل انتشار کانال ریاضی، ما مدل ارائه شده توسط را پیشنهاد می کنیم
la ریلی چان عملکرد Matlab، زیرا کانالی قابل قبول را فراهم می کند
مدل سازی در حوزه زمان و فرکانس. برای اطلاعات بیشتر، خواننده است
اشاره به [ریاضیات].

شبیه ساز یک اسکریپت متلب را ارائه می دهد
(src/lte/model/fading-traces/fading-trace-generator.m) برای ایجاد ردیابی بر اساس
فرمت استفاده شده توسط شبیه ساز در جزئیات، شی کانال ایجاد شده با rayleighchan
تابع برای فیلتر کردن سیگنال ضربه ای زمان گسسته به منظور به دست آوردن آن استفاده می شود
پاسخ ضربه ای کانال فیلتر برای TTI های مختلف تکرار می شود، بنابراین نتیجه می دهد
پاسخ های کانال مرتبط با زمان بعدی (یکی در هر TTI). پاسخ کانال پس از آن است
پردازش شده با پولچ تابعی برای بدست آوردن مقادیر چگالی طیفی توان آن، که
سپس در فایلی با فرمت مناسب سازگار با مدل شبیه ساز ذخیره می شوند.

از آنجایی که تعداد متغیرها بسیار زیاد است، با در نظر گرفتن همه آنها ردیابی ایجاد کنید
ممکن است تعداد زیادی از آثار با اندازه بزرگ ایجاد کند. در این مورد، ما در نظر گرفتیم
به دنبال فرضیات پارامترهای مبتنی بر شرایط انتشار محو شدن 3GPP
(پیوست B.2 از [TS36104] را ببینید):

· سرعت کاربران: معمولاً فقط چند مقدار گسسته در نظر گرفته می شود، به عنوان مثال:

· 0 و 3 کیلومتر در ساعت برای سناریوهای عابر پیاده

30 و 60 کیلومتر در ساعت برای سناریوهای وسیله نقلیه

· 0، 3، 30 و 60 برای سناریوهای شهری

· ضربه های کانال: معمولاً فقط تعداد محدودی از مجموعه های ضربه های کانال در نظر گرفته می شود.
برای مثال سه مدل در پیوست B.2 [TS36104] ذکر شده است.

· دانه بندی زمانی: برای هر TTI به یک مقدار محو شدن نیاز داریم، یعنی هر 1 میلی ثانیه (چون این مقدار است
دانه بندی در زمان مدل ns-3 LTE PHY).

· دانه بندی فرکانس: ما به یک مقدار محو شدن در هر RB نیاز داریم (که فرکانس است
دانه بندی مدل طیف استفاده شده توسط مدل ns-3 LTE).

· طول ردیابی: شبیه ساز شامل مکانیزم پنجره سازی اجرا شده است
در طول GSoC 2011، که شامل برداشتن یک پنجره از ردیابی هر پنجره است
طول به صورت تصادفی

· فرآیند محو شدن به ازای هر کاربر: کاربران همان ردپای محو شدن را به اشتراک می گذارند، اما برای هر کاربر a
نقطه شروع مختلف در ردیابی به طور تصادفی انتخاب می شود. این انتخاب انجام شد تا
از نیاز به ارائه یک اثر محو شدن برای هر کاربر اجتناب کنید.

با توجه به پارامترهایی که در نظر گرفتیم، فرمول زیر با جزئیات بیان می کند
اندازه کل S_{traces} ردپای محو شده:

که در آن S_{sample} اندازه نمونه بر حسب بایت است (مثلاً 8 در صورت دقت مضاعف،
4 در صورت دقت شناور)، N_{RB} تعداد RB یا مجموعه ای از RB است که باید در نظر گرفته شود.
T_{trace} طول کل ردیابی است، T_{نمونه} وضوح زمانی ردیابی است.
(1 میلی ثانیه)، و N_{scenarios} تعداد سناریوهای محو شده مورد نظر است (یعنی،
ترکیبی از مجموعه‌های مختلف ضربه‌های کانال و مقادیر سرعت کاربر). ما آثاری را ارائه می دهیم
برای 3 سناریو مختلف، یکی برای پیکربندی هر شیر که در پیوست B.2 تعریف شده است
[TS36104]:

· عابر پیاده: با سرعت گره ها 3 کیلومتر در ساعت.

· وسیله نقلیه: با سرعت گره 60 کیلومتر در ساعت.

· شهری: با سرعت گره ها 3 کیلومتر در ساعت.

از این رو N_{سناریوها} = 3. همه ردیابی ها T_{trace} = 10 ثانیه و RB_{NUM} = 100 دارند.
در مجموع 24 مگابایت بایت ردیابی.

آنتن
بودن بر اساس SpectrumPhyمدل LTE PHY از مدل سازی آنتن از طریق ns-3 پشتیبانی می کند
آنتن مدل کلاس از این رو، هر مدل مبتنی بر این کلاس را می توان با هر eNB یا مرتبط کرد
نمونه UE. به عنوان مثال، استفاده از CosineAntennaModel مرتبط با دستگاه eNB
اجازه می دهد تا یک بخش از یک ایستگاه پایه ماکرو را مدل کنید. به طور پیش فرض، مدل آنتن ایزوتروپیک
هم برای eNB ها و هم برای UE ها استفاده می شود.

PHY
بررسی اجمالی
مدل لایه فیزیکی ارائه شده در این شبیه ساز LTE بر اساس مدلی است که در آن توضیح داده شده است
[Piro2011]، با تغییرات زیر. مدل در حال حاضر شامل بین سلول است
محاسبه تداخل و شبیه سازی ترافیک uplink، از جمله هر دو بسته
انتقال و تولید CQI.

فریم فرعی ساختار
همانطور که در شکل توضیح داده شده است، زیرفریم به بخش کنترل و داده تقسیم می شود LTE فریم فرعی
تقسیم.
[تصویر] بخش فریم فریم LTE..UNINDENT

با در نظر گرفتن دانه بندی شبیه ساز بر اساس RB، کنترل و مرجع
سیگنالینگ باید در نتیجه با در نظر گرفتن این محدودیت مدل شود. بر اساس
استاندارد [TS36211]، قاب کنترل downlink از ابتدای هر زیر فریم شروع می شود
و تا سه نماد در کل پهنای باند سیستم دوام دارد، جایی که واقعی است
مدت زمان توسط کانال نشانگر فرمت کنترل فیزیکی (PCFICH) ارائه می شود. این
سپس اطلاعات مربوط به تخصیص در منابع باقیمانده تا سطح نقشه برداری می شود
مدت زمان تعریف شده توسط PCFICH، در به اصطلاح کانال کنترل Downlink فیزیکی
(PDCCH). یک PDCCH یک پیام واحد به نام اطلاعات کنترل لینک (DCI) را منتقل می کند.
از لایه MAC، جایی که زمان‌بند تخصیص منبع را برای a نشان می‌دهد
کاربر خاص PCFICH و PDCCH با انتقال کنترل مدل‌سازی می‌شوند
فریم با مدت زمان ثابت 3/14 میلی ثانیه که در کل موجود است
پهنای باند، زیرا زمانبند اندازه منطقه کنترل را تخمین نمی زند. این
به این معنی است که یک بلوک انتقال واحد، کل قاب کنترل را با یک ثابت مدل می کند
توان (یعنی برق مورد استفاده برای PDSCH) در تمام RBهای موجود. با توجه به این
این انتقال همچنین نشان دهنده پشتیبانی ارزشمند برای سیگنال مرجع است
(RS). این به هر TTI امکان ارزیابی سناریوی تداخل را می دهد
همه eNB در حال انتقال (به طور همزمان) فریم کنترل بر روی مربوطه هستند
پهنای باند موجود توجه داشته باشیم که این مدل از آن زمان شامل افزایش قدرت نمی شود
هیچ گونه بهبودی در مدل پیاده سازی شده برآورد کانال را نشان نمی دهد.

سیگنال مرجع صدا (SRS) شبیه به فریم کنترل downlink مدل شده است.
SRS به صورت دوره ای در آخرین نماد زیرفریم در کل سیستم قرار می گیرد
پهنای باند ماژول RRC قبلاً شامل یک الگوریتم برای تخصیص پویا است
تناوب به عنوان تابعی از تعداد واقعی UE های متصل به eNB مطابق با
روش خاص UE (به بخش 8.2 [TS36213] مراجعه کنید).

MAC به کانال تاخیر
برای مدل‌سازی تأخیر پیاده‌سازی‌های واقعی MAC و PHY، مدل PHY a را شبیه‌سازی می‌کند
تاخیر MAC به کانال در چند برابر TTI (1ms). انتقال داده ها و کنترل
بسته ها با این مقدار تاخیر دارند.

CQI باز خورد
تولید بازخورد CQI مطابق با آنچه در [FFAPI] مشخص شده است انجام می شود. که در
جزئیات، ما تولید دوره‌ای CQI باند پهن (یعنی یک مقدار واحد از
حالت کانالی که نماینده همه RB های در حال استفاده تلقی می شود) و CQI های باند داخلی (یعنی الف
مجموعه ای از مقادیر نشان دهنده وضعیت کانال برای هر RB).

شاخص CQI که باید گزارش شود ابتدا با اندازه گیری SINR و سپس به دست می آید
با گذراندن این اندازه گیری SINR، مدولاسیون و کدگذاری تطبیقی ​​که آن را به نگاشت می کند
شاخص CQI.

در downlink، SINR مورد استفاده برای تولید بازخورد CQI را می توان به دو صورت مختلف محاسبه کرد
راه ها:

1. کلیدهای Ctrl روش: SINR با ترکیب قدرت سیگنال از مرجع محاسبه می شود
سیگنال ها (که در شبیه سازی معادل PDCCH است) و تداخل
برق از PDCCH این رویکرد منجر به در نظر گرفتن هر eNB همسایه به عنوان یک می شود
مداخله گر، صرف نظر از اینکه آیا این eNB واقعاً PDSCH را انجام می دهد یا خیر
انتقال، و صرف نظر از قدرت و RB های مورد استفاده برای تداخل نهایی
انتقال PDSCH

2. مخلوط روش: SINR با ترکیب قدرت سیگنال از مرجع محاسبه می شود
سیگنال ها (که در شبیه سازی معادل PDCCH است) و تداخل
برق از PDSCH این رویکرد منجر به در نظر گرفتن آنها به عنوان مداخله گر می شود
eNB های همسایه که به طور فعال داده ها را روی PDSCH انتقال می دهند و اجازه می دهد
CQIهای درون باند تولید می کنند که مقادیر مختلفی از تداخل را در موارد مختلف ایجاد می کنند
RB ها با توجه به سطح تداخل واقعی. در صورتی که هیچ PDSCH
انتقال توسط هر eNB انجام می شود، این روش در نظر می گیرد که تداخل است
صفر، یعنی SINR فقط به عنوان نسبت سیگنال به نویز محاسبه می شود.

برای جابجایی بین این دو رویکرد نسل CQI، LteHelper::UsePdschForCqiGeneration
باید پیکربندی شود: غلط برای رویکرد اول و درست برای رویکرد دوم (درست است
مقدار پیش فرض):

پیکربندی::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration"، BooleanValue (true));

در uplink دو نوع CQI پیاده سازی می شود:

· مبتنی بر SRS، به صورت دوره ای توسط UE ها ارسال می شود.

· بر اساس PUSCH، محاسبه شده از داده های ارسال شده واقعی.

رابط زمانبندی شامل یک سیستم ویژگی است که فراخوانی می شود فیلتر UlCqi برای مدیریت
فیلتر کردن CQI ها با توجه به ماهیت آنها، به تفصیل:

· SRS_UL_CQI برای ذخیره فقط CQI های مبتنی بر SRS.

· PUSCH_UL_CQI برای ذخیره فقط CQI های مبتنی بر PUSCH.

· ALL_UL_CQI برای ذخیره تمام CQI های دریافتی.

لازم به ذکر است که، FfMacScheduler فقط رابط را فراهم می کند و ماده است
از پیاده سازی زمانبندی واقعی برای گنجاندن کد برای مدیریت این ویژگی ها
(برای اطلاعات بیشتر در مورد این موضوع به بخش مربوط به زمانبندی مراجعه کنید).

دخالت مدل
مدل PHY بر اساس مدل های تداخل شناخته شده گاوسی است که بر اساس آن
قدرت سیگنال های تداخلی (در واحدهای خطی) برای تعیین با هم جمع می شوند
قدرت تداخل کلی

نمودار توالی شکل دنباله نمودار of la PHY دخالت محاسبه
روش نشان می دهد که چگونه سیگنال های تداخلی برای محاسبه SINR پردازش می شوند و چگونه SINR
سپس برای تولید بازخورد CQI استفاده می شود.
[تصویر] نمودار توالی روش محاسبه تداخل PHY.UNINDENT

LTE طیف مدل
استفاده از طیف رادیویی توسط eNBs و UEs در LTE در [TS36101] توضیح داده شده است. در
شبیه ساز، استفاده از طیف رادیویی به صورت زیر مدل شده است. بگذارید f_c نشان دهنده LTE Absolute باشد
شماره کانال فرکانس رادیویی، که فرکانس حامل را در 100 کیلوهرتز شناسایی می کند
شطرنجی علاوه بر این، اجازه دهید B پیکربندی پهنای باند انتقال بر حسب تعداد باشد
بلوک های منابع برای هر جفت (f_c,B) مورد استفاده در شبیه سازی، یک متناظر تعریف می کنیم
SpectrumModel با استفاده از عملکرد ارائه شده توسط sec-spectrum-module. مدل با استفاده از
چارچوب طیف توصیف شده در [Baldo2009]. f_c و B را می توان برای هر پیکربندی کرد
eNB نمونه در شبیه سازی. از این رو، هر eNB می تواند از مدل طیف متفاوتی استفاده کند.
هر UE به طور خودکار از مدل طیف eNB که به آن متصل است استفاده می کند. با استفاده از
MultiModelSpectrumChannel در [Baldo2009]، تداخل بین eNBهایی که از
مدل های طیف مختلف به درستی در نظر گرفته شده است. این امکان شبیه سازی پویا را فراهم می کند
سیاست‌های دسترسی به طیف، مانند سیاست‌های مجوز طیف که هستند
در [Ofcom2600MHz] بحث شده است.

داده ها PHY خطا مدل
شبیه ساز شامل یک مدل خطا از صفحه داده (یعنی PDSCH و PUSCH) مطابق با آن است
به تکنیک های استاندارد نگاشت پیوند به سیستم (LSM). انتخاب با
روش‌شناسی شبیه‌سازی سیستم استاندارد فناوری انتقال رادیویی OFDMA با تشکر از
LSM ما قادر به حفظ سطح خوبی از دقت و در عین حال محدود کردن
افزایش پیچیدگی محاسباتی این بر اساس نگاشت لایه پیوند واحد است
عملکرد به دست آمده با استفاده از شبیه سازهای سطح پیوند به سیستم (در شبکه مورد ما)
شبیه سازها به طور خاص از شبیه ساز لایه برای تولید عملکرد استفاده می شود
از یک پیوند واحد از دیدگاه لایه PHY، معمولاً از نظر نرخ خطای بلوک کد
(BLER)، تحت شرایط استاتیک خاص. LSM اجازه می دهد تا از این پارامترها در موارد بیشتری استفاده شود
سناریوهای پیچیده، نمونه شبیه سازهای سیستم/شبکه، که در آن لینک های بیشتری داریم،
تداخل و پدیده انتشار کانال "رنگی" (به عنوان مثال، فرکانس انتخابی
محو شدن).

برای انجام این کار از شبیه ساز LTE Vienna [ViennaLteSim] برای موارد مربوط به
استخراج عملکرد لایه پیوند و SINR موثر مبتنی بر اطلاعات متقابل
(MIESM) به عنوان تابع نقشه برداری LSM با استفاده از بخشی از کار اخیراً توسط Signet منتشر شده است
گروه دانشگاه پادوآ [PaduaPEM].

MIESM
روش LSM خاص اتخاذ شده، روشی است که مبتنی بر استفاده از اطلاعات متقابل است
متریک، معمولاً به عنوان اطلاعات متقابل در هر بیت کدگذاری شده (MIB یا MMIB زمانی که
میانگین چندگانه MIB درگیر است). گزینه دیگر توسط
ESM نمایی (EESM)؛ با این حال، مطالعات اخیر نشان می دهد که MIESM از EESM بهتر عمل می کند
شرایط دقت [LozanoCost].
[تصویر] نمودار روش محاسباتی MIESM.UNINDENT

اطلاعات متقابل (MI) به نگاشت صورت فلکی وابسته است و می تواند باشد
محاسبه شده به ازای هر بلوک انتقال (TB)، با ارزیابی MI بر روی نمادها و
حامل فرعی با این حال، این برای یک شبیه ساز شبکه بسیار پیچیده خواهد بود. از این رو، در ما
اجرای یک پاسخ کانال مسطح در RB در نظر گرفته شده است. بنابراین
MI کلی یک سل با میانگین MI ارزیابی شده به ازای هر RB مورد استفاده در سل محاسبه می شود.
به طور مفصل، طرح اجرا شده در شکل نشان داده شده است MIESM محاسباتی روش
نمودار، جایی که می بینیم که مدل با ارزیابی مقدار MI برای هر RB شروع می شود،
در شکل با نمونه های SINR نشان داده شده است. سپس MI معادل در هر مورد ارزیابی می شود
اساس سل با میانگین گیری مقادیر MI. در نهایت، یک گام دیگر باید از زمان انجام شود
شبیه ساز سطح لینک عملکرد لینک را از نظر میزان خطای بلوک برمی گرداند
(BLER) در یک کانال نویز سفید گواسی (AWGN) که در آن بلوک ها کد هستند
بلوک ها (CB) به طور مستقل توسط رمزگذار توربو کدگذاری/رمزگشایی می شوند. در این مورد
طرح تقسیم بندی استاندارد 3GPP برای تخمین اندازه واقعی CB استفاده شده است
(شرح شده در بخش 5.1.2 [TS36212]). این طرح، سل را به N_{K_-} تقسیم می‌کند.
بلوک‌های اندازه K_- و N_{K+} بلوک با اندازه K_+. بنابراین TB BLER کلی (TBLER)
می تواند به صورت بیان شود

که در آن CBLER_i BLER CB i است که طبق شبیه ساز سطح پیوند به دست آمده است
منحنی های CB BLER. برای تخمین CBLER_i، ارزیابی MI اجرا شده است
با توجه به تقریب عددی آن تعریف شده در [wimaxEmd]. علاوه بر این، برای کاهش
با پیچیدگی محاسبات، تقریب به جستجو تبدیل شده است
جداول در جزئیات، از مدل تجمعی گاوسی برای تقریب AWGN استفاده شده است
منحنی های BLER با سه پارامتر که تناسب نزدیک با AWGN استاندارد را فراهم می کند
اجراها، در فرمول:

جایی که x MI سل است، b_{ECR} نشان دهنده "مرکز انتقال" و c_{ECR} است.
مربوط به "عرض انتقال" توزیع تجمعی گاوسی برای هر یک
نرخ کد موثر (ECR) که نرخ انتقال واقعی با توجه به کانال است
کد نویسی و MCS برای محدود کردن پیچیدگی محاسباتی مدلی که در نظر گرفتیم
تنها زیر مجموعه ای از ECR های ممکن در واقع ما به طور بالقوه 5076 ECR ممکن خواهیم داشت
(یعنی 27 MCS و 188 اندازه CB). از این نظر، ما اندازه های CB را به برخی محدود می کنیم
مقادیر نماینده (یعنی 40، 140، 160، 256، 512، 1024، 2048، 4032، 6144)، در حالی که برای
بقیه بدترین مورد استفاده می شود که تقریبی واقعی است (یعنی CB کوچکتر
مقدار اندازه موجود با توجه به واقعی). این انتخاب مطابق با حالت معمولی است
عملکرد کدهای توربو، که در آن اندازه CB به شدت بر BLER تأثیر نمی گذارد.
با این حال، باید توجه داشت که برای اندازه‌های CB کمتر از 1000 بیت، این اثر ممکن است باشد
مربوطه (یعنی تا 2 دسی بل)؛ بنابراین، ما این فاصله نمونه گیری نامتعادل را برای
داشتن دقت بیشتر در جایی که لازم است. این رفتار توسط ارقام تایید شده است
ارائه شده در بخش Annes.

BLER منحنی
در این رابطه، بخشی از منحنی‌های به‌دست‌آمده در [PaduaPEM] را دوباره استفاده کردیم. در جزئیات، ما
با حمایت توسعه دهندگان، وابستگی اندازه CB را به منحنی های CB BLER معرفی کرد
از [PaduaPEM] و شبیه ساز LTE Vienna. در واقع، ماژول منتشر شده این را فراهم می کند
عملکرد لایه پیوند فقط برای آنچه به MCS مربوط می شود (یعنی با یک ECR ثابت معین). که در
جزئیات منحنی های نرخ خطای جدید برای هر یک با یک کمپین شبیه سازی ارزیابی شده است
با شبیه ساز لایه پیوند برای یک پیوند با نویز AWGN و برای اندازه CB 104،
140، 256، 512، 1024، 2048، 4032 و 6144. این منحنی ها با گاوس نگاشت شده اند.
فرمول مدل تجمعی ارائه شده در بالا برای به دست آوردن متناظرهای b_{ECR} و
c_{ECR} پارامترها.

عملکرد BLER تمام MCS به دست آمده با شبیه ساز سطح پیوند در نمودار نشان داده شده است
شکل های زیر (خطوط آبی) همراه با نگاشت متناظر آنها به گاوسی
توزیع تجمعی (خطوط چین دار قرمز).
[تصویر] BLER برای MCS 1، 2، 3 و 4..UNINDENT
[تصویر] BLER برای MCS 5، 6، 7 و 8..UNINDENT
[تصویر] BLER برای MCS 9، 10، 11 و 12..UNINDENT
[تصویر] BLER برای MCS 13، 14، 15 و 16..UNINDENT
[تصویر] BLER برای MCS 17، 17، 19 و 20..UNINDENT
[تصویر] BLER برای MCS 21، 22، 23 و 24..UNINDENT
[تصویر] BLER برای MCS 25، 26، 27 و 28..UNINDENT
[تصویر] BLER برای MCS 29..UNINDENT

ادغام of la BLER منحنی ها in la ns-3 LTE واحد
مدل پیاده‌سازی شده از منحنی‌های LSM مدل اخیر LTE PHY Error استفاده می‌کند
در انجمن ns3 توسط گروه Signet [PaduaPEM] منتشر شد و موارد جدید تولید شد
برای اندازه های مختلف CB این LteSpectrumPhy کلاس مسئول ارزیابی TB BLER است
با تشکر از روش های ارائه شده توسط LteMiErrorModel کلاسی که مسئول آن است
ارزیابی TB BLER با توجه به بردار SINR درک شده در هر RB، MCS و
اندازه به منظور مدل سازی مناسب تقسیم بندی سل در CBها. برای اینکه به دست بیارید
بردار SINR درک شده دو نمونه از پردازنده LtePemSinrChunk (فرزند از
پردازنده LteChunk اختصاص داده شده به ارزیابی SINR برای به دست آوردن عملکرد خطای فیزیکی)
به downlink UE و uplink eNB متصل شده اند LteSpectrumPhy ماژول هایی برای ارزیابی
توزیع مدل خطا به ترتیب PDSCH (سمت UE) و ULSCH (سمت eNB).

مدل را می توان برای کار با کانال صفر تلفات با تنظیم غیرفعال کرد PemEnabled
ویژگی از LteSpectrumPhy کلاس (به طور پیش فرض فعال است). این را می توان با توجه به
به روش استاندارد سیستم ویژگی ns3، یعنی:

پیکربندی::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled"، BooleanValue (نادرست));

کنترل کانال ها PHY خطا مدل
شبیه ساز شامل مدل خطا برای کانال های کنترل downlink (PCFICH و PDCCH) است.
در حالی که در uplink کانال بدون خطا فرضی و ایده آل است. مدل بر اساس
رویکرد MIESM قبلا برای در نظر گرفتن اثرات فرکانس انتخابی ارائه شده است
کانال از آنجایی که اکثر کانال های کنترلی کل پهنای باند موجود را در بر می گیرند.

PCFICH + PDCCH خطا مدل
مدل اتخاذ شده برای توزیع خطای این کانال ها بر اساس یک ارزیابی است
مطالعه ای در RAN4 3GPP انجام شد، جایی که فروشندگان مختلف آن را بررسی کردند
عملکرد دمدولاسیون PCFICH به طور مشترک با PDCCH. این به دلیل این واقعیت است که
PCFICH کانالی است که مسئول ارتباط با UE ها ابعاد واقعی آن است
PDCCH (که بین 1 تا 3 نماد را شامل می شود). بنابراین رمزگشایی صحیح از
DCI ها به تفسیر صحیح هر دو بستگی دارد. در 3GPP این مشکل وجود دارد
برای بهبود عملکرد لبه سلولی [FujitsuWhitePaper]، که در آن
تداخل بین سلول های همسایه به دلیل تخریب سیگنال می تواند نسبتاً زیاد باشد. آ
مشکل مشابهی در سناریوهای فمتوسل و به طور کلی در HetNet وجود دارد
سناریوهایی که گلوگاه عمدتاً به عنوان کانال PCFICH [Bharucha2011] شناسایی شده است،
در صورتی که بسیاری از eNB ها در یک منطقه خدماتی مستقر شده باشند، این کانال ممکن است برخورد کند
در فرکانس، تشخیص صحیح کانال PDCCH را نیز غیرممکن می کند.

در شبیه ساز، SINR درک شده در طول دریافت بر اساس برآورد شده است
مدل MIESM ارائه شده در بالا به منظور ارزیابی توزیع خطا PCFICH و
PDCCH. به طور مفصل، نمونه‌های SINR همه RBها در ارزیابی MI گنجانده شده‌اند
مربوط به قاب کنترل و با توجه به این مقادیر، SINR موثر (eSINR)
با معکوس کردن فرآیند ارزیابی MI به دست می آید. لازم به ذکر است که در صورت وجود
انتقال MIMO، هم PCFICH و هم PDCCH همیشه از حالت تنوع انتقال استفاده می کنند
توسط استاندارد تعریف شده است. با توجه به eSINR، خطای رمزگشایی را درک کرد
احتمال را می توان به عنوان تابعی از نتایج ارائه شده در [R4-081920] تخمین زد. در صورت
خطایی رخ می دهد، DCI ها دور ریخته می شوند و بنابراین UE قادر به دریافت آن نخواهد بود
Tbs خبرنگار، بنابراین در نتیجه از دست داده است.

MIMO مدل
استفاده از آنتن های متعدد در سمت فرستنده و گیرنده که به نام
چند ورودی و چند خروجی (MIMO)، مشکلی است که به خوبی در ادبیات مطالعه شده است
سال های گذشته بیشتر کارها بر ارزیابی تحلیلی سود متمرکز می شوند
طرح های مختلف MIMO ممکن است از نظر ظرفیت داشته باشند. با این حال کسانی نیز ارائه می دهند
اطلاعات بهره بر حسب توان دریافتی [CatreuxMIMO].

با توجه به ملاحظات بالا، با در نظر گرفتن مدلی انعطاف پذیرتر می توان به دست آورد
سودی که طرح های MIMO از نقطه نظر آماری در سیستم به ارمغان می آورد. مانند
قبلاً برجسته شده بود، [CatreuxMIMO] سود آماری چندین راه حل MIMO را ارائه می دهد.
با توجه به SISO یک در صورت عدم همبستگی بین آنتن ها. در کار
بهره به عنوان تابع توزیع تجمعی (CDF) خروجی SINR برای ارائه شده است
آنچه مربوط به طرح های SISO، MIMO-Alamouti، MIMO-MMSE، MIMO-OSIC-MMSE و MIMO-ZF است.
با تشریح نتایج، توزیع SINR خروجی را می توان با a تقریب زد
یک log-normal با میانگین و واریانس متفاوت به عنوان تابعی از طرح در نظر گرفته شده.
با این حال، واریانس ها چندان متفاوت نیستند و به طور تقریبی با یک برابر هستند
از حالت SISO که قبلاً در مؤلفه سایه زنی گنجانده شده است
BuildingsPropagationLossModel، به تفصیل:

· SISO: = 13.5 و ma = 20 [dB].

· MIMO-Alamouti: = 17.7 و ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 و ma = 16.6 [dB].

· MIMO-OSIC-MMSE: = 12.6 و ma = 15.5 [dB].

· MIMO-ZF: = 10.3 و ma = 12.6 [dB].

بنابراین لایه PHY مدل MIMO را به عنوان بهره درک شده توسط گیرنده پیاده سازی می کند
هنگام استفاده از یک طرح MIMO به طرحی که با استفاده از SISO one به دست آمده است، احترام بگذارید. ما توجه داشته باشید که، این
سود به موردی اشاره دارد که هیچ ارتباطی بین آنتن‌ها در MIMO وجود ندارد
طرح؛ بنابراین، تخریب را به دلیل همبستگی مسیرها مدل نکنید.

UE PHY اندازه گیری مدل
طبق [TS36214]، UE باید مجموعه ای از اندازه گیری های eNB را گزارش کند که
دستگاه قادر به درک: سیگنال مرجع قدرت دریافتی (RSRP) و
کیفیت دریافت سیگنال مرجع (RSRQ). اولی معیاری از توان دریافتی است
یک eNB خاص، در حالی که دومی شامل تداخل کانال و نویز حرارتی نیز می شود.
UE باید اندازه گیری ها را به طور مشترک با هویت سلول فیزیکی (PCI) گزارش دهد
سلول. هر دو اندازه گیری RSRP و RSRQ در طول دریافت RS انجام می شود.
در حالی که PCI با سیگنال همگام سازی اولیه (PSS) به دست می آید. PSS ارسال می شود
توسط eNB هر 5 فریم فرعی و با جزئیات در زیر فریم های 1 و 6. در سیستم های واقعی، فقط
504 PCI مجزا در دسترس است، و از این رو ممکن است دو eNB مجاور از
همان PCI؛ با این حال، در شبیه ساز ما PCI ها را با استفاده از ابرداده شبیه سازی مدل می کنیم و اجازه می دهیم
تا 65535 PCI متمایز، در نتیجه از برخورد PCI جلوگیری می شود به شرطی که کمتر از 65535 باشد.
eNB ها در همان سناریو شبیه سازی می شوند.

طبق [TS36133] بخش‌های 9.1.4 و 9.1.7، RSRP توسط لایه PHY در dBm گزارش می‌شود.
در حالی که RSRQ در دسی بل است. مقادیر RSRP و RSRQ از طریق به لایه های بالاتر ارائه می شود
C-PHY SAP (با استفاده از UeMeasurementsParameters struct) هر 200 میلی ثانیه همانطور که در تعریف شده است
[TS36331]. فیلتر لایه 1 با میانگین گیری تمام اندازه گیری های جمع آوری شده انجام می شود
در طول آخرین شکاف پنجره تناوب گزارش را می توان برای تحقیق تنظیم کرد
اهداف با استفاده از LteUePhy::UeMeasurementsFilterPeriod ویژگی.

فرمول های RSRP و RSRQ را می توان با توجه به فرض PHY ساده کرد.
لایه ای که کانال در داخل RB مسطح است، بهترین سطح دقت. در واقع این
به این معنی است که تمام REهای داخل یک RB دارای قدرت یکسانی هستند، بنابراین:

که در آن P(k,m) قدرت سیگنال RE m را در RB k نشان می دهد، که همانطور که مشاهده شد
قبل از، در همان RB ثابت است و برابر با P(k)، M تعداد REهای حامل است
RS در یک RB و K تعداد RBها است. لازم به ذکر است که P(k) و به طور کلی همه
توان های تعریف شده در این بخش در شبیه ساز از PSD RB بدست می آید
(که توسط پردازنده LteInterferencePowerChunk) به تفصیل:

که در آن PSD_{RB}(k) چگالی طیفی توان RB k است، 180000 پهنای باند بر حسب هرتز است.
از RB و 12 تعداد RE در هر RB در نماد OFDM است. به طور مشابه، برای RSSI ما
داشته باشد

که در آن S تعداد نمادهای OFDM حامل RS در یک RB و R تعداد RE است.
حمل یک RS در یک نماد OFDM (که روی 2 ثابت است) در حالی که P(k،s،r)، I(k،s،r) و N(k،s،r)
به ترتیب قدرت درک شده سلول سرویس دهنده، قدرت تداخل و
قدرت نویز RE r در نماد s. در مورد RSRP، اندازه گیری ها در یک RB هستند
طبق مدل PHY همیشه بین یکدیگر برابر است. بنابراین P(k,s,r) = P(k)
I(k,s,r) = I(k) و N(k,s,r) = N(k) که به این معنی است که RSSI را می توان به صورت زیر محاسبه کرد:

با توجه به محدودیت های اجرای زنجیره پذیرش PHY و به منظور
سطح پیچیدگی محاسباتی را پایین نگه دارید، فقط می توان RSRP را مستقیماً برای آن به دست آورد
تمام سلول ها این به دلیل این واقعیت است که LteSpectrumPhy برای ارزیابی طراحی شده است
تداخل فقط با توجه به سیگنال سرویس eNB. این نشان می دهد که PHY
لایه برای مدیریت اطلاعات سیگنال های قدرت با سرویس eNB به عنوان یک بهینه شده است
ارجاع. با این حال، RSRP و RSRQ سلول همسایه i را می توان با جریان استخراج کرد
اطلاعات موجود از سلول سرویس j به شرح زیر است:

که در آن RSRP_i RSRP سلول همسایه i است، P_i(k) توان درک شده در هر RE است.
در RB k، K تعداد کل RBها است، RSSI_i RSSI سلول همسایه i است.
وقتی UE به سلول j متصل است (که از آنجایی که مجموع تمام توان های دریافتی است،
منطبق با RSSI_j، I_j(k) کل تداخل درک شده توسط UE در هر RE از RB k است.
هنگامی که به سلول i متصل می شود (به دست آمده توسط پردازنده LteInterferencePowerChunk، P_j(k) است
توان درک شده از سلول j در هر RE از RB k و N، طیف نویز توان است
چگالی در هر RE. در صورت ارزیابی RSRQ نمونه معتبر در نظر گرفته می شود
بالای LteUePhy::RsrqUeMeasThreshold ویژگی.

HARQ
طرح HARQ اجرا شده بر اساس راه حل های ترکیبی افزونگی افزایشی (IR) است.
با چندین فرآیند توقف و انتظار برای فعال کردن یک جریان داده مداوم. در جزئیات،
راه حل اتخاذ شده است نرم ترکیب پیوندی IR کامل افزایشی افزونگی (همچنین به نام
IR نوع II)، که به این معنی است که ارسال‌های مجدد فقط حاوی اطلاعات جدید هستند
به قبلی ها الگوریتم تخصیص منابع HARQ پیاده سازی شده است
در کلاس های زمان بندی مربوطه (به عنوان مثال، RrFfMacScheduler و PfFfMacScheduler,
برای اطلاعات بیشتر به بخش های خبرنگار آنها مراجعه کنید)، در حالی که بخش رمزگشایی از
HARQ در این کشور پیاده سازی شده است LteSpectrumPhy و LteHarqPhy کلاس هایی که خواهد بود
در این بخش شرح داده شده است.

طبق استاندارد، ارسال های مجدد UL همزمان هستند و بنابراین هستند
7 میلی ثانیه پس از ارسال اصلی اختصاص داده شد. از سوی دیگر، برای DL، آنها هستند
ناهمزمان است و بنابراین می توان به روشی انعطاف پذیرتر با شروع از 7 میلی ثانیه و
این موضوع مربوط به اجرای زمانبندی خاص است. رفتار پردازش HARQ است
نشان داده شده در شکل:ref:fig-harq-processes-scheme.

در لایه MAC، موجودیت HARQ مستقر در زمانبندی مسئول کنترل است
8 فرآیند HARQ برای تولید بسته های جدید و مدیریت ارسال مجدد هر دو
DL و UL. زمان‌بندی بازخورد HARQ را از لایه‌های eNB و UE PHY جمع‌آوری می‌کند
(به ترتیب برای اتصال UL و DL) با استفاده از FF API اولیه
SchedUlTriggerReq و SchedUlTriggerReq. با توجه به بازخورد HARQ و RLC
وضعیت بافر، زمان‌بند مجموعه‌ای از DCI را شامل هر دو ارسال مجدد از
بلوک های HARQ به طور کلی ارسال های اشتباه و جدیدی را دریافت کردند که اولویت را به آن ها می دادند
سابق. در این مورد، زمانبندی باید یک محدودیت را در نظر بگیرد
تخصیص منبع برای ارسال مجدد HARQ، باید از همان ترتیب مدولاسیون استفاده کند
اولین تلاش برای انتقال (یعنی QPSK برای MCS در [0..9]، 16QAM برای MCS در [10..16]
و 64QAM برای MCS در [17..28]). این محدودیت ناشی از مشخصات نرخ است
تطبیق دهنده در استاندارد 3GPP [TS36212]، که در آن الگوریتم ترتیب مدولاسیون را برای
تولید بلوک های مختلف نسخه های افزونگی.

مدل خطای PHY (یعنی LteMiErrorModel کلاس قبلا ارائه شده است) دارد
برای در نظر گرفتن IR HARQ مطابق [wimaxEmd]، که در آن پارامترهای برای
نگاشت منحنی های AWGN برای نقشه برداری MIESM در صورت ارسال مجدد توسط:

که در آن X تعداد بیت های اطلاعات اصلی، C_i تعداد بیت های کدگذاری شده، M_i هستند
اطلاعات متقابل در هر بلوک HARQ دریافت شده در تعداد کل ارسال های مجدد q.
بنابراین برای اینکه بتوانیم احتمال خطا را با مدل خطا برگردانیم
پیاده سازی شده در شبیه ساز، R_{eff} و MI_{I eff} را ارزیابی می کند و مقدار را برمی گرداند.
احتمال خطای ECR همان مدولاسیون با نزدیکترین نرخ کمتر نسبت به
R_{eff}. به منظور در نظر گرفتن اثر ارسال مجدد HARQ مجموعه جدیدی از منحنی ها
با توجه به استاندارد مورد استفاده برای MCS اصلی یکپارچه شده اند. منحنی های جدید
برای پوشش مواردی در نظر گرفته شده اند که محافظه کارانه ترین MCS یک مدولاسیون استفاده می شود
که به معنای تولید R_{eff} کمتر از MCSهای استاندارد است. روی این
منحنی های ارسال مجدد 1، 2 و 3 برای 10 و 17 ارزیابی شده است.
MCS 0 ما فقط اولین ارسال مجدد را در نظر گرفتیم زیرا نرخ کد تولید شده قبلاً وجود دارد
بسیار محافظه کارانه (یعنی 0.04) و نرخ خطا را به اندازه کافی قوی برای دریافت برمی گرداند.
(یعنی نزول BLER در حدود -18 دسی بل متمرکز است). لازم به ذکر است که،
اندازه اولین انتقال TB به عنوان حاوی تمام بیت های اطلاعات در نظر گرفته شده است
کدگذاری شود؛ بنابراین X برابر است با اندازه اولین TB ارسال شده از یک فرآیند HARQ. را
مدل فرض می کند که حضور نهایی بیت های برابری در کلمات رمز قبلاً وجود دارد
در منحنی های سطح پیوند در نظر گرفته شده است. این بدان معناست که به محض اینکه حداقل R_{eff} باشد
مدل به دست آمده شامل سود ناشی از انتقال برابری بیشتر نیست
بیت
[تصویر] HARQ رفتار را در LTE.UNINDENT پردازش می کند

بخشی از HARQ که به مدیریت رمزگشایی بلوک های HARQ اختصاص یافته است
اجرا شده در LteHarqPhy و LteSpectrumPhy کلاس ها. سابق مسئول است
حفظ اطلاعات HARQ برای هر فرآیند فعال. دومی با آن تعامل دارد
LteMiErrorModel کلاس برای ارزیابی صحت بلوک های دریافتی و شامل
الگوریتم پیام رسانی که مسئول ارتباط با موجودیت HARQ در زمانبندی است
نتیجه رمزگشایی ها این پیام ها در محصور شده اند
dlInfoListElement برای DL و ulinfolistelement برای UL و ارسال از طریق PUCCH و
PHICH به ترتیب با یک مدل بدون خطا ایده آل با توجه به مفروضات موجود در آنها
پیاده سازی. طرحی از تکرار بین HARQ و پروتکل LTE در پشته
نشان داده شده در شکل:ref:انجیر-حرق-معماری.

در نهایت، موتور HARQ همیشه در لایه MAC و PHY فعال است. با این حال، در صورت
زمانبند از HARQ پشتیبانی نمی کند، سیستم به کار با HARQ ادامه می دهد
توابع مهار شده است (یعنی بافرها پر می شوند اما استفاده نمی شوند). این پیاده سازی
مشخصه سازگاری با زمان‌بندی‌های پیاده‌سازی شده قبل از HARQ را ارائه می‌دهد
ادغام.
[تصویر] تعامل بین HARQ و پروتکل LTE stack.UNINDENT

MAC
منابع تخصیص مدل
اکنون به طور مختصر نحوه تخصیص منابع در LTE را توضیح می دهیم و چگونگی آن را روشن می کنیم
مدل سازی شده در شبیه ساز زمانبندی مسئول تولید ساختارهای خاص است
نام داده ها کنترل نشانگر (DCI) که سپس توسط PHY eNB به
UE های متصل، به منظور اطلاع آنها از تخصیص منابع در هر زیرفریم
اساس در انجام این کار در جهت downlink، زمان‌بند باید موارد خاصی را پر کند
فیلدهای ساختار DCI با تمام اطلاعات، مانند: مدولاسیون و کدگذاری
طرح (MCS) مورد استفاده، اندازه بلوک انتقال MAC (TB) و بیت مپ تخصیص
که مشخص می کند کدام RB حاوی داده های ارسال شده توسط eNB به هر کاربر است.

برای نگاشت منابع به RB های فیزیکی، ما یک را اتخاذ می کنیم بومی سازی شده نقشه برداری رویکرد (نگاه کنید به
[Sesia2009]، بخش 9.2.2.1). از این رو در یک زیرفریم معین، هر RB همیشه به آن اختصاص داده می شود
یک کاربر در هر دو اسلات. بیت مپ تخصیص را می توان در قالب های مختلف کدگذاری کرد. که در
این پیاده سازی را در نظر گرفتیم تخصیص نوع 0 مطابق با [TS36213] تعریف شده است
که RB ها در گروه های بلوک منابع (RBG) با اندازه های مختلف گروه بندی می شوند
به عنوان تابعی از پیکربندی پهنای باند انتقال در حال استفاده.

برای مقادیر خاصی از پهنای باند، همه RB ها قابل استفاده نیستند، زیرا اندازه گروه a نیست
تقسیم کننده مشترک گروه این برای مثال زمانی است که پهنای باند برابر است
25 RB که منجر به اندازه RBG 2 RB می شود و بنابراین 1 RB نتیجه نمی دهد
آدرس پذیر در uplink، فرمت DCI ها متفاوت است، زیرا فقط RB های مجاور می توانند
به دلیل مدولاسیون SC-FDMA استفاده شود. در نتیجه، همه RB ها را می توان توسط
eNB صرف نظر از پیکربندی پهنای باند.

انطباقی تلفیق و برنامه نویسی
شبیه ساز دو مدل مدولاسیون و کدگذاری تطبیقی ​​(AMC) ارائه می دهد: یکی بر اساس
مدل GSoC [Piro2011] و مدلی بر اساس مدل خطای فیزیکی (شرح شده در
بخش های بعدی).

مدل قبلی یک نسخه اصلاح شده از مدل توصیف شده در [Piro2011] است که به نوبه خود
از [Seo2004] الهام گرفته شده است. نسخه ما در ادامه توضیح داده شده است. اجازه دهید من نشان می دهد
کاربر عمومی، و اجازه دهید mma_i SINR آن باشد. بازده طیفی \ta_i کاربر i را بدست می آوریم
با استفاده از معادلات زیر:

روش شرح داده شده در [R1-081483] برای دریافت طرح MCS مربوطه استفاده می شود. این
راندمان طیفی بر اساس شاخص کیفیت کانال (CQI) کوانتیزه می شود که به آن گرد می شود
کمترین مقدار، و به طرح MCS مربوطه نگاشت شده است.

در نهایت، ما متذکر می شویم که تفاوت هایی بین شاخص MCS در [R1-081483] وجود دارد.
و آنچه توسط استاندارد نشان داده شده است: [TS36213] جدول 7.1.7.1-1 می گوید که شاخص MCS
از 0 به 31 می رسد و 0 به نظر می رسد یک طرح معتبر MCS باشد (اندازه سل 0 نیست) اما در
[R1-081483] اولین شاخص مفید MCS 1 است. بنابراین برای بدست آوردن مقدار مورد نظر توسط
استاندارد باید 1 را از شاخص گزارش شده در [R1-081483] کم کنیم.

مدل جایگزین بر اساس مدل خطای فیزیکی توسعه یافته برای این شبیه ساز است
و در قسمت های زیر توضیح داده شده است. این طرح قادر به تطبیق انتخاب MCS است
به عملکرد واقعی لایه PHY طبق گزارش CQI خاص. مطابق با
تعریف آنها، یک شاخص CQI زمانی که یک سل PDSCH منفرد با مدولاسیون اختصاص داده می شود
طرح کدگذاری و نرخ کد مطابق با آن شاخص CQI در جدول 7.2.3-1 [TS36213]
را می توان با احتمال خطا کمتر از 0.1 دریافت کرد. در مورد CQI باند پهن،
سل مرجع شامل تمام RBG های موجود به منظور داشتن یک مرجع بر اساس
کل منابع موجود؛ در حالی که، برای CQI های زیر باند، سل مرجع به عنوان RBG اندازه می شود.

حمل و نقل مسدود کردن مدل
مدل بلوک های انتقال MAC (TBs) ارائه شده توسط شبیه ساز با ساده سازی شده است
با توجه به مشخصات 3GPP به طور خاص، یک کلاس شبیه ساز خاص
(PacketBurst) برای جمع آوری MAC SDU ها به منظور دستیابی به معادل شبیه ساز استفاده می شود.
یک سل، بدون پیچیدگی پیاده سازی مربوطه. مالتی پلکس شدن
کانال های منطقی مختلف به و از لایه RLC با استفاده از یک بسته اختصاصی انجام می شود
برچسب (LteRadioBearerTag)، که عملکردی را انجام می دهد که تا حدی معادل
هدرهای MAC مشخص شده توسط 3GPP.

La FemtoForum MAC زمان بند رابط
این بخش نسخه خاص ns-3 رابط زمانبند LTE MAC را شرح می دهد
مشخصات منتشر شده توسط FemtoForum [FFAPI].

ما نسخه خاص ns-3 رابط زمانبندی مک FemtoForum [FFAPI] را پیاده سازی کردیم.
به عنوان مجموعه ای از کلاس های انتزاعی C++. به طور خاص، هر اولیه به C++ ترجمه می شود
متد یک کلاس مشخص عبارت اجرا در اینجا با همان معنای اتخاذ شده استفاده می شود
در [FFAPI]، و از این رو به فرآیند ترجمه رابط منطقی اشاره دارد
مشخصات یک زبان برنامه نویسی خاص موارد اولیه در [FFAPI] گروه بندی می شوند
در دو گروه: CSCHED اولیه، که با پیکربندی زمانبندی سر و کار دارند، و
SCHED اولیه، که با اجرای زمانبندی سر و کار دارند. علاوه بر این، [FFAPI]
ابتدا دو نوع مختلف را تعریف می کند: آنهایی که از نوع REQ هستند از MAC به MAC می روند
Scheduler و آنهایی که از نوع IND/CNF هستند از زمانبندی به MAC می روند. برای ترجمه اینها
ویژگی ها در C++، کلاس های انتزاعی زیر را تعریف می کنیم که Service را پیاده سازی می کنند
نقاط دسترسی (SAP) مورد استفاده برای صدور اولیه:

· FfMacSchedSapProvider کلاس تمام متدهای C++ را که با SCHED مطابقت دارند تعریف می کند
اولیه از نوع REQ؛

· FfMacSchedSapUser کلاس تمام متدهای C++ را که با SCHED مطابقت دارند تعریف می کند
اولیه از نوع CNF/IND؛

· FfMacCschedSapProvider کلاس تمام متدهای C++ را که مطابقت دارند تعریف می کند
CSCHED اولیه از نوع REQ.

· FfMacCschedSapUser کلاس تمام متدهای C++ را که با CSCHED مطابقت دارند تعریف می کند
اولیه از نوع CNF/IND؛

3 بلوک در رابط MAC Scheduler وجود دارد: بلوک کنترل، بلوک ساب فریم
و بلوک Scheduler. هر یک از این بلوک ها یک قسمت از رابط برنامه نویس MAC را فراهم می کند.
شکل زیر رابطه بین بلوک ها و SAP های تعریف شده در ما را نشان می دهد
پیاده سازی رابط زمانبند MAC.
[تصویر]

علاوه بر اصول فوق، انتخاب های طراحی زیر نیز انجام شده است:

· تعریف کلاس های رابط MAC Scheduler از قراردادهای نامگذاری پیروی می کند
از ns-3 سبک کدنویسی به ویژه، ما از کنوانسیون CamelCase پیروی می کنیم
نام های اولیه به عنوان مثال، ابتدایی CSCHED_CELL_CONFIG_REQ ترجمه شده است به
CschedCellConfigReq در ns-3 کد

· همان قراردادهای نامگذاری برای پارامترهای اولیه دنبال می شود. به عنوان
پارامترهای ابتدایی متغیرهای عضو کلاس ها هستند، همچنین با a پیشوند می شوند
m_.

در مورد استفاده از بردارها و لیست ها در ساختارهای داده، توجه داشته باشیم که [FFAPI] یک
API تقریباً C محور. با این حال، در نظر گرفته می شود که C++ در ns-3 استفاده می شود، و این
استفاده از آرایه های C ممنوع است، ما از بردارهای STL استفاده کردیم (std:: vector) برای
پیاده سازی رابط زمانبند MAC، به جای استفاده از آرایه های C به عنوان
به طور ضمنی از طریق نحوه نگارش [FFAPI] پیشنهاد شده است.

· در C++ اعضای دارای سازنده و تخریب کننده اجازه ورود ندارند اتحادیه. از این رو همه
آن دسته از ساختارهای داده ای که گفته می شود اتحادیه در [FFAPI] به عنوان تعریف شده اند
سازه می دهد در کد ما

شکل زیر نحوه استفاده از رابط زمانبند MAC را در eNB نشان می دهد.
[تصویر]

سمت کاربر هر دو CSCHED SAP و SCHED SAP در eNB MAC پیاده‌سازی می‌شوند.
یعنی در فایل lte-enb-mac.cc. eNB MAC را می توان با زمانبندی های مختلف استفاده کرد
پیاده سازی بدون تغییر همین شکل به عنوان مثال نشان می دهد که چگونه
Round Robin Scheduler پیاده سازی شده است: برای تعامل با MAC eNB، Round Robin
زمانبند سمت ارائه دهنده رابط های SCHED SAP و CSCHED SAP را پیاده سازی می کند. آ
رویکرد مشابهی را می توان برای پیاده سازی زمانبندی های دیگر نیز مورد استفاده قرار داد. شرح هر کدام
از پیاده سازی زمانبندی که ما به عنوان بخشی از ماژول شبیه سازی LTE خود ارائه می کنیم، می باشد
در زیر بخش های زیر ارائه شده است.

گرد سینه سرخ (RR) زمان بند
زمانبندی Round Robin (RR) احتمالاً ساده ترین زمانبندی موجود در ادبیات است.
با تقسیم منابع موجود بین جریان‌های فعال، یعنی جریان‌های منطقی، کار می‌کند
کانال هایی که یک صف RLC غیر خالی دارند. اگر تعداد RBG ها بیشتر از
تعداد جریان های فعال، همه جریان ها را می توان در یک زیرفریم تخصیص داد. در غیر این صورت، اگر
تعداد جریان‌های فعال بیشتر از تعداد RBG است، همه جریان‌ها نمی‌توانند باشند
در یک زیرفریم معین برنامه ریزی شده است. سپس در زیرفریم بعدی تخصیص از شروع خواهد شد
آخرین جریانی که تخصیص داده نشد. MCS که برای هر کاربر اتخاذ می شود انجام می شود
با توجه به CQI های باند پهن دریافتی.

در رابطه با HARQ، RR نسخه غیر تطبیقی ​​را پیاده‌سازی می‌کند، که به این معنی است که در
تخصیص تلاش های ارسال مجدد RR از همان پیکربندی تخصیص استفاده می کند
بلوک اصلی، که به معنای حفظ همان RBG و MCS است. UE هایی که برای آنها تخصیص داده شده است
ارسال مجدد HARQ برای انتقال داده های جدید در صورت وجود در نظر گرفته نمی شود
یک فرصت انتقال در همان TTI موجود است. در نهایت، HARQ را می توان با غیر فعال کرد
سیستم ویژگی ns3 برای حفظ سازگاری با نسخه‌های آزمایشی قدیمی و کد،
به تفصیل:

پیکربندی::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled"، BooleanValue (نادرست));

زمانبند فیلتر کردن CQIهای uplink را با توجه به ماهیت آنها با آنها پیاده سازی می کند
فیلتر UlCqi به تفصیل:

· SRS_UL_CQI: فقط CQI مبتنی بر SRS در ویژگی های داخلی ذخیره می شود.

· PUSCH_UL_CQI: فقط CQI مبتنی بر PUSCH در ویژگی های داخلی ذخیره می شود.

· ALL_UL_CQI: همه CQI ها در یک ویژگی داخلی (یعنی آخرین CQI) ذخیره می شوند
دریافت شده مستقل از ماهیت آن ذخیره می شود).

متناسب منصفانه (PF) زمان بند
زمان‌بندی نمایشگاه متناسب (PF) [Sesia2009] با برنامه‌ریزی یک کاربر در زمانی کار می‌کند که
کیفیت کانال آنی نسبت به وضعیت متوسط ​​کانال خود بالا است
زمان. اجازه دهید i,j نشان دهنده کاربران عمومی باشد. بگذارید t شاخص فریم فریم و k منبع باشد
شاخص بلوک؛ اجازه دهید M_{i,k}(t) MCS قابل استفاده توسط کاربر i در بلوک منبع k مطابق با چه باشد
گزارش شده توسط مدل AMC (نگاه کنید به انطباقی تلفیق و برنامه نویسی) در نهایت، اجازه دهید S(M، B) باشد
اندازه TB بر حسب بیت همانطور که در [TS36213] برای مواردی که تعداد B از منبع تعریف شده است
بلوک استفاده می شود. نرخ قابل دستیابی R_{i}(k,t) بر حسب بیت/ثانیه برای کاربر i در گروه بلوک منابع
k در زیرقاب t به صورت تعریف شده است

که در آن au مدت زمان TTI است. در شروع هر زیرفریم t، هر RBG به a اختصاص داده می شود
کاربر خاص به طور مفصل، شاخص 144}_{k}(t) که RBG k در زمان t به آن اختصاص داده شده است
تعیین شده است

که در آن T_{j}(t) عملکرد خروجی گذشته درک شده توسط کاربر j است. مطابق با
با الگوریتم زمانبندی بالا، یک کاربر را می توان به RBG های مختلف اختصاص داد، که می تواند
چه مجاور یا نه، بسته به شرایط فعلی کانال و گذشته
عملکرد توان عملیاتی T_{j}(t). دومی در انتهای زیرقاب t تعیین می شود
با استفاده از رویکرد میانگین متحرک نمایی زیر:

که در آن lpha ثابت زمانی (به تعداد زیر فریم ها) حرکت نمایی است
میانگین، و 384 ثانیه توان عملیاتی واقعی به دست آمده توسط کاربر i در زیرفریم t. 360 است
طبق روش زیر اندازه گیری می شود. ابتدا MCS 840 j را تعیین می کنیم:

سپس عدد کل 936 j را تعیین می کنیم:

کجا |

در مورد HARQ، PF نسخه غیر تطبیقی ​​را پیاده‌سازی می‌کند، که به این معنی است که در
تخصیص تلاش‌های ارسال مجدد، زمان‌بند از همان تخصیص استفاده می‌کند
پیکربندی بلوک اصلی، که به معنای حفظ همان RBG و MCS است. UEs
که برای ارسال مجدد HARQ اختصاص داده شده است برای ارسال جدید در نظر گرفته نمی شود
داده ها در صورتی که یک فرصت انتقال در همان TTI وجود داشته باشد. در نهایت، HARQ
را می توان با سیستم ویژگی ns3 برای حفظ سازگاری با قدیمی غیرفعال کرد
موارد تست و کد، با جزئیات:

پیکربندی::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled"، BooleanValue (نادرست));

بیشترین ظرفیت تولید (MT) زمان بند
برنامه زمانبندی حداکثر توان عملیاتی (MT) [FCapo2012] با هدف به حداکثر رساندن توان کلی
از eNB. هر RB را به کاربر اختصاص می دهد که بتواند حداکثر نرخ قابل دستیابی را در آن به دست آورد
TTI فعلی در حال حاضر، زمانبندی MT در NS-3 دارای دو نسخه است: دامنه فرکانس
(FDMT) و دامنه زمان (TDMT). در FDMT، هر TTI، زمانبندی MAC RBGها را به UE اختصاص می دهد
که بالاترین نرخ قابل دستیابی محاسبه شده توسط زیر باند CQI را دارد. در TDMT، هر TTI، MAC
زمانبند یک UE را انتخاب می کند که بالاترین نرخ قابل دستیابی را دارد که توسط CQI باند پهن محاسبه شده است.
سپس زمانبندی MAC تمام RBGها را به این UE در TTI فعلی اختصاص می دهد. محاسبه از
نرخ قابل دستیابی در FDMT و TDMT به همان میزان در PF است. اجازه دهید i,j نشانگر عمومی باشد
کاربران؛ بگذارید t شاخص زیرفریم باشد و k شاخص بلوک منبع باشد. بگذارید M_{i,k}(t) باشد
MCS قابل استفاده توسط کاربر i در بلوک منبع k مطابق آنچه توسط مدل AMC گزارش شده است (نگاه کنید به
انطباقی تلفیق و برنامه نویسی) در نهایت، اجازه دهید S(M، B) اندازه TB در بیت باشد که در آن تعریف شده است
[TS36213] برای موردی که یک عدد B از بلوک های منبع استفاده می شود. نرخ قابل دستیابی
R_{i}(k,t) در بیت/ثانیه برای کاربر i در بلوک منبع k در زیرفریم t به صورت

که در آن au مدت زمان TTI است. در شروع هر زیرفریم t، هر RB به a اختصاص داده می شود
کاربر خاص به طور دقیق، شاخص 144}_{k}(t) که RB k در زمان t به آن اختصاص داده شده است
تعیین شده است

وقتی چندین UE وجود دارد که نرخ قابل دستیابی یکسانی دارند، اجرای فعلی همیشه
اولین UE ایجاد شده در اسکریپت را انتخاب می کند. اگرچه MT می تواند توان سلولی را به حداکثر برساند
نمی تواند عدالت را برای UE ها در شرایط کانال ضعیف ارائه دهد.

ظرفیت تولید به میانگین (TTA) زمان بند
برنامه زمانبندی تراکم به میانگین (TTA) [FCapo2012] را می توان به عنوان یک میانی در نظر گرفت.
بین MT و PF. متریک استفاده شده در TTA به صورت زیر محاسبه می شود:

در اینجا، R_{i}(k,t) در بیت/s نرخ قابل دستیابی برای کاربر i در بلوک منبع k را نشان می دهد.
زیر فریم t. روش محاسبه قبلاً در MT و PF نشان داده شده است. در همین حال، R_{i}(t) در
bit/s مخفف نرخ قابل دستیابی برای i در زیرفریم t است. تفاوت بین آن دو
نرخ های قابل دستیابی نحوه دریافت MCS است. برای R_{i}(k,t)، MCS توسط زیر باند CQI در حالی که محاسبه می‌شود
R_{i}(t) توسط CQI باند پهن محاسبه می شود. زمانبندی TTA فقط در فرکانس قابل پیاده سازی است
دامنه (FD) زیرا نرخ قابل دستیابی RBG خاص فقط به FD مربوط می شود
برنامه ریزی.

کور میانگین ظرفیت تولید زمان بند
هدف برنامه زمانبندی متوسط ​​کور [FCapo2012] ارائه توان عملیاتی برابر برای همه
UE های تحت eNB. متریک استفاده شده در TTA به صورت زیر محاسبه می شود:

که در آن T_{j}(t) عملکرد توان عملیاتی گذشته است که توسط کاربر j درک شده و می تواند باشد
با همین روش در زمانبندی PF محاسبه می شود. در حوزه زمان متوسط ​​توان عملیاتی کور
(TD-BET)، زمانبندی UE را با بیشترین اولویت سنجه انتخاب می کند و همه RBG ها را تخصیص می دهد.
به این UE. از سوی دیگر، در حوزه فرکانس متوسط ​​توان عملیاتی کور (FD-BET)،
در هر TTI، زمان‌بندی‌کننده ابتدا یک UE با کمترین مقدار گذشته متوسط ​​(بزرگترین) انتخاب می‌کند
متریک اولویت). سپس زمانبند یک RBG را به این UE اختصاص می دهد، انتظار می رود
توان عملیاتی این UE و از آن برای مقایسه با میانگین گذشته T_{j}(t) استفاده می کند
سایر UE ها زمان‌بند به تخصیص RBG به این UE تا زمان مورد انتظار ادامه می‌دهد
توان عملیاتی در میان میانگین توان گذشته T_{j}(t) همه UE کوچکترین نیست. سپس
زمانبند از همین روش برای تخصیص RBG برای یک UE جدید که کمترین گذشته را دارد استفاده می کند
میانگین توان عملیاتی T_{j}(t) تا زمانی که همه RBG ها به UE ها تخصیص داده شوند. اصل پشت این
این است که، در هر TTI، زمان‌بند بهترین تلاش را برای دستیابی به توان عملیاتی برابر در بین می‌کند
همه UE ها

رمز بانک منصفانه صف زمان بند
Token Bank Fair Queue (TBFQ) یک برنامه زمانبندی آگاه از QoS است که از سطل نشت کننده ناشی می شود.
سازوکار. در TBFQ، یک جریان ترافیک کاربر i با پارامترهای زیر مشخص می شود:

· t_{i}: نرخ رسیدن بسته (بایت/ثانیه)

· r_{i}: نرخ تولید رمز (بایت/ثانیه)

· p_{i}: اندازه مخزن توکن (بایت)

· E_{i}: شمارنده‌ای که تعداد توکن‌های قرض‌گرفته‌شده یا داده‌شده به آن را ثبت می‌کند
بانک با جریان i ; E_{i} می تواند کوچکتر از صفر باشد

هر K بایت داده، k نشانه مصرف می کند. همچنین، TBFQ یک بانک توکن مشترک (B) دارد تا بتواند
ترافیک بین جریان های مختلف را متعادل کنید. اگر نرخ تولید رمز r_{i} بزرگتر از
نرخ رسیدن بسته t_{i}، سپس توکن های سرریز شده از مخزن توکن به توکن اضافه می شوند
بانک، و E_{i} به همان میزان افزایش می یابد. در غیر این صورت، جریان من باید برداشته شود
توکن ها از بانک توکن بر اساس فرک متریک اولویت{E_{i}}{r_{i}} و E_{i} است
کاهش یافته. بدیهی است که کاربر مشارکت بیشتری در بانک توکن دارد که اولویت بیشتری دارد
قرض گرفتن نشانه ها؛ از سوی دیگر، کاربر توکن های بیشتری را از بانک وام می گیرد کمتر
اولویت برای ادامه برداشت توکن است. بنابراین، در صورت داشتن چندین کاربر
همان نرخ تولید توکن، نرخ ترافیک و اندازه استخر نشانه، کاربر از بالاتر رنج می برد
تداخل فرصت بیشتری برای قرض گرفتن توکن از بانک دارد. علاوه بر این، TBFQ می تواند پلیس کند
ترافیک با تنظیم نرخ تولید توکن برای محدود کردن توان عملیاتی. علاوه بر این،
TBFQ همچنین سه پارامتر زیر را برای هر جریان حفظ می کند:

· محدودیت بدهی d_{i}: اگر E_{i} کمتر از این آستانه باشد، کاربر من نمی‌تواند توکن‌ها را بیشتر قرض کند.
از بانک این برای جلوگیری از قرض گرفتن بیش از حد توکن توسط UE مخرب است.

· حد اعتبار c_{i}: حداکثر تعداد توکن UE که می توانم از بانک در یک وام بگیرم
زمان.

· آستانه اعتبار C: هنگامی که E_{i} به سقف بدهی رسید، UE i باید توکن های C را در بانک ذخیره کند.
به منظور استقراض بیشتر توکن از بانک.

LTE در NS-3 دارای دو نسخه زمانبندی TBFQ است: دامنه فرکانس TBFQ (FD-TBFQ) و زمان
دامنه TBFQ (TD-TBFQ). در FD-TBFQ، زمان‌بند همیشه UE را با بالاترین متریک و انتخاب می‌کند
RBG را با بالاترین زیر باند CQI اختصاص می دهد تا زمانی که هیچ بسته ای در بافر RLC UE وجود نداشته باشد.
یا همه RBG ها اختصاص داده شده اند [FABokhari2009]. در TD-TBFQ، پس از انتخاب UE با حداکثر
متریک، تمام RBG ها را با استفاده از CQI باند پهن [WKWong2004] به این UE اختصاص می دهد.

اولویت تنظیم زمان بند
زمانبندی مجموعه اولویت (PSS) یک زمانبندی آگاه از QoS است که دامنه زمانی (TD) و را ترکیب می کند
عملیات زمانبندی بسته دامنه فرکانس (FD) در یک زمانبندی [GMonghal2008]. آی تی
انصاف بین UE ها را با نرخ بیت هدف مشخص (TBR) کنترل می کند.

در بخش زمانبندی TD، PSS ابتدا UE ها را با بافر RLC غیر خالی انتخاب می کند و سپس آنها را تقسیم می کند.
به دو مجموعه بر اساس TBR:

· مجموعه 1: UE که میانگین توان گذشته آن کوچکتر از TBR است. زمانبندی TD محاسبه می کند
معیار اولویت آنها در سبک Blind Equal Throughput (BET):

· مجموعه 2: UE که میانگین توان گذشته آن بزرگتر (یا مساوی) از TBR است. زمانبندی TD
متریک اولویت آنها را در سبک متناسب (PF) محاسبه می کند:

UE های متعلق به مجموعه 1 دارای اولویت بالاتری نسبت به مجموعه 2 هستند. سپس PSS انتخاب می شود
N_{mux} UE با بالاترین متریک در دو مجموعه و آن UE را به زمان‌بندی FD ارسال کنید. در PSS،
زمانبند FD RBG k را به UE n اختصاص می دهد که متریک انتخاب شده را حداکثر می کند. دو زمانبندی PF
در زمانبندی PF استفاده می شود:

· نمایشگاه متناسب با برنامه (PFsch)

· حامل بیش از تداخل به میانگین (CoIta)

که در آن Tsch_{j}(t) عملکرد توان عملیاتی مشابهی است که توسط کاربر j درک شده است، با
تفاوت این است که فقط زمانی به روز می شود که کاربر i-ام واقعاً سرویس شود. CoI[j,k] یک است
تخمین SINR روی RBG k از UE j. هر دو PFsch و CoIta برای جدا کردن FD هستند
متریک از زمانبندی TD. علاوه بر این، زمان‌بندی PSS FD یک متریک وزن W[n] را نیز ارائه می‌کند.
برای کمک به کنترل انصاف در صورت تعداد کم UE.

که در آن T_{j}(t) عملکرد خروجی گذشته درک شده توسط کاربر j است. بنابراین، در
RBG k، زمانبندی FD UE j را انتخاب می کند که حاصلضرب فرکانس را به حداکثر می رساند
متریک دامنه (Msch، MCoI) بر اساس وزن W[n]. این استراتژی توان عملیاتی را تضمین می کند
UE با کیفیت پایین تر به سمت TBR تمایل دارد.

پیکربندی::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled"، BooleanValue (نادرست));

زمانبند فیلتر کردن CQIهای uplink را با توجه به ماهیت آنها با آنها پیاده سازی می کند
فیلتر UlCqi به تفصیل:

· SRS_UL_CQI: فقط CQI مبتنی بر SRS در ویژگی های داخلی ذخیره می شود.

· PUSCH_UL_CQI: فقط CQI مبتنی بر PUSCH در ویژگی های داخلی ذخیره می شود.

· ALL_UL_CQI: همه CQI ها در یک ویژگی داخلی (یعنی آخرین CQI) ذخیره می شوند
دریافت شده مستقل از ماهیت آن ذخیره می شود).

کانال و کیفیت سرویس مطلع زمان بند
برنامه زمانبندی کانال و QoS Aware (CQA) [Bbojovic2014] یک برنامه زمانبندی اتصال پایین LTE MAC است
الگوریتمی که تاخیر سر خط (HOL)، پارامترهای GBR و کانال را در نظر می‌گیرد
کیفیت در زیر باندهای مختلف زمانبندی CQA بر اساس برنامه ریزی مشترک TD و FD است.

در TD (در هر TTI) زمانبندی CQA کاربران را بر اساس اولویت گروه بندی می کند. هدف از
گروه بندی برای اعمال زمان بندی FD است تا ابتدا جریان هایی با بالاترین HOL در نظر گرفته شود
تاخیر انداختن. متریک گروه بندی m_{td} برای کاربر j=1,...,N به صورت زیر تعریف می شود:

که در آن d_{hol}^{j}(t) مقدار فعلی تاخیر HOL جریان j است و g یک گروه بندی است
پارامتری که دانه بندی گروه ها را تعیین می کند، یعنی تعداد جریان هایی که
در تکرار زمانبندی FD در نظر گرفته خواهد شد.

گروه‌های جریان انتخاب شده در تکرار TD به زمان‌بندی FD ارسال می‌شوند
با شروع از جریان هایی با بالاترین مقدار متریک m_{td} تا زمانی که همه RBG ها
در TTI مربوطه اختصاص داده شده است. در FD، برای هر RBG k=1،...،K، زمانبندی CQA
RBG فعلی را به کاربر j اختصاص می دهد که حداکثر مقدار متریک FD را دارد
به صورت زیر تعریف کنید:

که در آن m_{GBR}^j(t) به صورت زیر محاسبه می شود:

که در آن GBR^j نرخ بیت مشخص شده در حامل EPS جریان j، rie Rj () shps خروجی هوادهی است که
با میانگین متحرک محاسبه می شود، r^{j}(t) توان عملیاتی به دست آمده در زمان t است،
و lpha ضریبی است به طوری که 0 lpha ..sp برای m_{ca}^{(k,j)}(t) دو در نظر می گیریم
معیارهای مختلف: m_{pf}^{(k,j)}(t) و m_{ff}^{(k,j)}(t). m_{pf} متناسب است
معیار منصفانه که به صورت زیر تعریف می شود:

که در آن R_e^{(k,j)}(t) توان عملیاتی قابل دستیابی کاربر j بر روی RBG k است.
توسط طرح مدولاسیون و کدگذاری تطبیقی ​​(AMC) محاسبه شده است که کانال را ترسیم می کند
مقدار شاخص کیفیت (CQI) به اندازه بلوک انتقال بر حسب بیت.

معیار دیگر آگاهی کانال که در نظر می گیریم m_{ff} است که در آن پیشنهاد شده است
[GMonghal2008] و نشان دهنده افزایش محو شدن انتخابی فرکانس نسبت به RBG k برای کاربر است.
j و به صورت زیر محاسبه می شود:

که در آن CQI^{(k,j)}(t) آخرین مقدار CQI گزارش شده از کاربر j برای k-امین RBG است.

کاربر می تواند با تنظیم ویژگی انتخاب کند که آیا m_{pf} یا m_{ff} استفاده شود
ns3::CqaFfMacScheduler::CqaMetric به ترتیب به "CqaPf" or "CqaFf".

تصادفی دسترسی
مدل LTE شامل مدلی از روش دسترسی تصادفی بر اساس برخی ساده‌سازی‌ها است
مفروضاتی که در ادامه برای هر یک از پیام ها و سیگنال ها به تفصیل بیان شده است
در مشخصات [TS36321] توضیح داده شده است.

· تصادفی دسترسی (قورباغه) مقدمه: در سیستم های LTE واقعی این مربوط به Zadoff-Chu است
دنباله (ZC) با استفاده از یکی از چندین قالب موجود و ارسال شده در اسلات PRACH
که در اصل می تواند با PUSCH همپوشانی داشته باشد. PRACH Configuration Index 14 است
فرض می شود، یعنی مقدمه ها را می توان بر روی هر شماره قاب سیستم و شماره فریم فرعی ارسال کرد.
مقدمه RA با استفاده از کلاس LteControlMessage، یعنی به عنوان یک ایده آل، مدل سازی شده است
پیامی که هیچ منبع رادیویی را مصرف نمی کند. تصادم مقدمه
انتقال توسط چندین UE در یک سلول با استفاده از یک پروتکل مدل‌سازی می‌شود
مدل تداخل، یعنی هر زمان که دو یا چند مقدمه یکسان در آن مخابره شود
همان سلول در همان TTI، هیچ یک از این مقدمه های یکسان دریافت نخواهد شد
eNB. به غیر از این مدل برخورد، هیچ مدل خطایی با آن مرتبط نیست
دریافت مقدمه RA.

· تصادفی دسترسی واکنش (RAR): در سیستم های LTE واقعی، این یک MAC PDU ویژه است که روی آن ارسال می شود
DL-SCH. از آنجایی که عناصر کنترل MAC به طور دقیق در شبیه ساز مدل سازی نشده اند
(فقط RLC و بالاتر از PDU ها هستند)، RAR به عنوان یک LteControlMessage مدل شده است که این کار را انجام می دهد.
هیچ منبع رادیویی را مصرف نکنید. با این حال، در طول روش RA، LteEnbMac خواهد شد
از زمانبند درخواست تخصیص منابع برای RAR با استفاده از FF MAC کنید
زمانبندی اولیه SCHED_DL_RACH_INFO_REQ. از این رو، یک زمانبندی پیشرفته
پیاده سازی (در حال حاضر در دسترس نیست) می تواند منابع رادیویی را برای آن اختصاص دهد
RAR، بنابراین مدل سازی مصرف منابع رادیویی برای انتقال
RAR

· پیام 3: در سیستم های LTE واقعی، این یک RLC TM SDU است که از طریق منابع مشخص شده ارسال می شود
در UL Grant در RAR. در شبیه ساز، این به عنوان یک RLC TM RLC واقعی مدل شده است
PDU که منابع UL آن توسط زمانبندی پس از تماس به آن تخصیص داده می شود
SCHED_DL_RACH_INFO_REQ.

· مشاجره وضوح (CR): در سیستم LTE واقعی، فاز CR برای رسیدگی به آن مورد نیاز است
موردی که در آن دو یا چند UE مقدمه RA یکسانی را در همان TTI ارسال کردند و eNB بود
قادر به تشخیص این مقدمه با وجود برخورد. از آنجایی که این رویداد ندارد
به دلیل مدل تداخل پروتکل مورد استفاده برای دریافت مقدمات RA،
فاز CR در شبیه ساز مدل سازی نشده است، به عنوان مثال، CR MAC CE هرگز توسط
eNB و UE ها RA را پس از دریافت RAR موفق می دانند. به عنوان یک
در نتیجه، منابع رادیویی مصرف شده برای انتقال CR MAC CE هستند
مدل نشده

شکل دنباله نمودار of la مبتنی بر مناقشه MAC تصادفی دسترسی روش و دنباله
نمودار of la غیر مبتنی بر مناقشه MAC تصادفی دسترسی روش دنباله را نشان می دهد
نمودارهای دسترسی تصادفی MAC مبتنی بر مناقشه و غیرمشاهده
رویه، برجسته کردن تعاملات بین MAC و سایر موجودات.
[تصویر] نمودار توالی روش دسترسی تصادفی MAC مبتنی بر مناقشه.UNINDENT
[تصویر] نمودار توالی دسترسی تصادفی MAC مبتنی بر غیر مناقشه
رویه.UNINDENT

RLC
بررسی اجمالی
موجودیت RLC در مشخصات فنی 3GPP [TS36322] مشخص شده است و شامل
سه نوع مختلف RLC: حالت شفاف (TM)، حالت عدم تایید (UM) و
حالت تایید شده (AM). شبیه ساز شامل یک مدل برای هر یک از این موجودیت ها است

موجودیت های RLC رابط سرویس RLC را به لایه PDCP بالایی و MAC ارائه می دهند
رابط سرویس به لایه MAC پایینی. موجودیت های RLC از رابط سرویس PDCP استفاده می کنند
از لایه PDCP بالایی و رابط سرویس MAC از لایه MAC پایینی.

شکل پیاده سازی مدل of PDCP، RLC و MAC اشخاص و SAP ها نشان می دهد
مدل پیاده‌سازی موجودیت‌های RLC و ارتباط آن با سایر نهادها
و خدمات در پشته پروتکل.
[تصویر] مدل پیاده‌سازی موجودیت‌های PDCP، RLC و MAC و SAP.UNINDENT

محصولات واسط
RLC محصولات رابط
رابط سرویس RLC به دو بخش تقسیم می شود:

· RlcSapProvider بخش توسط لایه RLC ارائه شده و توسط لایه PDCP بالایی استفاده می شود
و

· RlcSapUser بخش توسط لایه PDCP بالایی ارائه شده و توسط لایه RLC استفاده می شود.

هر دو موجودیت UM و AM RLC همان رابط سرویس RLC را به قسمت بالایی ارائه می کنند
لایه PDCP.

RLC محصولات اولیه
لیست زیر مشخص می کند که کدام سرویس های اولیه توسط سرویس RLC ارائه می شوند
رابط ها:

· RlcSapProvider::TransmitPdcpPdu

· موجودیت PDCP از این اولیه برای ارسال یک PDU PDCP به موجودیت پایین تر RLC استفاده می کند.
در همتای فرستنده

· RlcSapUser::ReceivePdcpPdu

· موجودیت RLC از این اولیه برای ارسال یک PDU PDCP به موجودیت PDCP بالایی استفاده می کند.
در همتای گیرنده

MAC محصولات رابط
رابط سرویس MAC به دو بخش تقسیم می شود:

· MacSapProvider بخش توسط لایه MAC ارائه شده و توسط لایه RLC بالایی استفاده می شود
و

· MacSapUser بخش توسط لایه RLC بالایی ارائه شده و توسط لایه MAC استفاده می شود.

MAC محصولات اولیه
لیست زیر مشخص می کند که کدام سرویس های اولیه توسط سرویس MAC ارائه می شوند
رابط ها:

· MacSapProvider::TransmitPdu

· موجودیت RLC از این اولیه برای ارسال یک PDU RLC به موجودیت MAC پایین در
همتای فرستنده

· MacSapProvider::ReportBufferStatus

· موجودیت RLC از این اولیه برای گزارش موجودیت MAC به اندازه معلق استفاده می کند
بافرها در همتای فرستنده

· MacSapUser::NotifyTxOpportunity

· موجودیت MAC از این اولیه برای اطلاع رسانی به موجودیت RLC برای انتقال استفاده می کند
فرصت

· MacSapUser::ReceivePdu

· موجودیت MAC از این اولیه برای ارسال یک PDU RLC به موجودیت RLC بالایی استفاده می کند.
در همتای گیرنده

AM RLC
پردازش انتقال داده در موجودیت RLC حالت تأیید (AM) توضیح داده شده است
در بخش 5.1.3 [TS36322]. در این بخش ما برخی از جزئیات را شرح می دهیم
اجرای نهاد RLC

بافر ها برای la انتقال عملیات
پیاده سازی موجودیت AM RLC ما 3 بافر را برای عملیات انتقال حفظ می کند:

· انتقال بافر: این صف RLC SDU است. هنگامی که موجودیت AM RLC یک SDU دریافت می کند
در سرویس اولیه TransmitPdcpPdu از موجودیت PDCP بالایی، آن را در صف قرار می دهد.
در بافر انتقال ما محدودیتی در اندازه بافر RLC و فقط در سکوت قرار دادیم
وقتی بافر پر است SDU ها را رها کنید.

· انتقال PDU ها بافر: صف PDU های RLC ارسالی است که برای آن یک
ACK/NACK هنوز دریافت نشده است. هنگامی که موجودیت AM RLC یک PDU را به MAC ارسال می کند
موجودیت، همچنین یک کپی از PDU ارسال شده را در بافر Transmitted PDUs قرار می دهد.

· انتقال مجدد بافر: صف PDU های RLC است که برای آنها در نظر گرفته شده است
ارسال مجدد (به عنوان مثال، آنها NACK شده اند). موجودیت AM RLC این PDU را به
بافر ارسال مجدد، زمانی که یک PDU را از بافر ارسال شده مجددا ارسال می کند.

انتقال عملیات in downlink
نمودار توالی زیر تعاملات بین موجودیت های مختلف را نشان می دهد (RRC،
زمانبندی PDCP، AM RLC، MAC و MAC) از eNB در لینک پایین برای انجام داده ها
ارتباطات

شکل دنباله نمودار of داده ها PDU انتقال in downlink نشان می دهد که چگونه لایه های بالایی
ارسال PDU های داده و نحوه پردازش جریان داده توسط نهادها/سرویس های مختلف
پشته پروتکل LTE
[تصویر] نمودار توالی انتقال داده PDU در downlink.UNINDENT

موجودیت PDCP را فراخوانی می کند انتقال_PDCP_PDU سرویس بدوی به منظور ارسال یک داده
PDU موجودیت AM RLC این سرویس اولیه را با توجه به داده های AM پردازش می کند
مراحل انتقال تعریف شده در بخش 5.1.3 [TS36322].

هنگامی که انتقال_PDCP_PDU سرویس اولیه نامیده می شود، موجودیت AM RLC آن را انجام می دهد
عملیات زیر:

· SDU داده ها را در بافر انتقال قرار دهید.

· اندازه بافرها را محاسبه کنید (اندازه بافرها چگونه محاسبه می شود
بعد توضیح داده شد).

· با ... تماس بگیر گزارش_وضعیت_بافر سرویس اولیه موجودیت MAC eNB به منظور
اندازه بافرهای موجودیت AM RLC را به نهاد eNB MAC اطلاع دهید. سپس
موجودیت MAC eNB وضعیت بافر را در زمانبندی MAC با استفاده از
سرویس SchedDlRlcBufferReq اولیه API FF MAC Scheduler.

پس از آن، زمانی که زمان‌بندی MAC تصمیم گرفت که برخی از داده‌ها را می‌توان ارسال کرد، موجودیت MAC
آن را به نهاد RLC اطلاع می دهد، یعنی آن را فراخوانی می کند Notify_Tx_Opportunity سرویس اولیه،
سپس نهاد AM RLC کارهای زیر را انجام می دهد:

· ایجاد یک PDU داده واحد با بخش بندی و/یا الحاق SDU ها در
بافر انتقال.

· PDU داده ها را از بافر انتقال به بافر PDUهای ارسالی منتقل کنید.

· متغیرهای حالت را طبق بخش 5.1.3.1.1 [TS36322] به روز کنید.

· با ... تماس بگیر Transmit_PDU اولیه به منظور ارسال PDU داده به موجودیت MAC.

انتقال مجدد in downlink
نمودار توالی شکل دنباله نمودار of داده ها PDU ارسال مجدد in downlink
تعاملات بین موجودیت های مختلف (AM RLC، MAC و زمانبندی MAC) را نشان می دهد
eNB در downlink زمانی که PDUهای داده باید توسط نهاد AM RLC دوباره ارسال شوند.
[تصویر] نمودار توالی ارسال مجدد PDU داده در downlink.UNINDENT

موجودیت AM RLC فرستنده می تواند PDUهای STATUS را از موجودیت AM RLC همتا دریافت کند.
PDUهای STATUS مطابق بخش 5.3.2 [TS36322] و پردازش
دریافت طبق بخش 5.2.1 [TS36322] انجام می شود.

هنگامی که یک PDU داده از بافر PDUهای ارسال شده مجدداً ارسال می شود، همچنین به
بافر ارسال مجدد

انتقال عملیات in پیوند
نمودار توالی شکل دنباله نمودار of داده ها PDU انتقال in پیوند نشان می دهد
تعاملات بین موجودیت های مختلف UE (RRC، PDCP، RLC و MAC) و
eNB (MAC و Scheduler) در Uplink هنگامی که PDUهای داده توسط لایه های بالایی ارسال می شوند.
[تصویر] نمودار توالی انتقال داده PDU در uplink.UNINDENT

این شبیه به نمودار توالی در downlink است. تفاوت اصلی این است که در این
در صورتی که Report_Buffer_Status از UE MAC به MAC Scheduler در eNB ارسال شود.
روی هوا با استفاده از کانال کنترل

انتقال مجدد in پیوند
نمودار توالی شکل دنباله نمودار of داده ها PDU ارسال مجدد in پیوند نشان می دهد
تعاملات بین موجودیت های مختلف UE (AM RLC و MAC) و eNB
(MAC) در Uplink زمانی که PDUهای داده باید توسط نهاد AM RLC دوباره ارسال شوند.
[تصویر] نمودار توالی ارسال مجدد PDU داده در uplink.UNINDENT

محاسبه of la بافر اندازه
بافر انتقال شامل SDU های RLC است. RLC PDU یک یا چند بخش SDU به اضافه یک قطعه است
هدر RLC اندازه هدر RLC یک RLC PDU به تعداد SDU بستگی دارد
بخش هایی که PDU شامل می شود.

استاندارد 3GPP (بخش 6.1.3.1 [TS36321]) به صراحت می گوید که برای Uplink،
هدرهای RLC و MAC در اندازه بافری که قرار است به عنوان بخشی از آن گزارش شود، در نظر گرفته نمی‌شوند
گزارش وضعیت بافر برای لینک پایین، رفتار مشخص نشده است. هیچ کدام
[FFAPI] نحوه انجام آن را مشخص می کند. مدل RLC ما با این فرض کار می کند که محاسبه
اندازه بافر در downlink دقیقاً مانند uplink انجام می شود، یعنی در نظر گرفته نمی شود
اندازه هدر RLC و MAC

توجه می کنیم که این انتخاب بر عملکرد متقابل با زمانبندی MAC تأثیر می گذارد، زیرا، در
پاسخ به Notify_Tx_Opportunity خدمات اولیه، انتظار می رود RLC ایجاد یک
PDU بیش از اندازه درخواست شده توسط MAC، از جمله سربار RLC. از این رو، غیر ضروری است
تکه تکه شدن می تواند اتفاق بیفتد اگر (به عنوان مثال) MAC یک انتقال را دقیقاً برابر با آن اعلام کند
اندازه بافری که قبلا توسط RLC گزارش شده بود. ما فرض می کنیم که به زمانبند واگذار شده است
برای اجرای استراتژی های هوشمند برای انتخاب اندازه انتقال
فرصت، به منظور در نهایت اجتناب از ناکارآمدی تکه تکه شدن غیر ضروری.

جمع شدن و تقسیم بندی
موجودیت AM RLC دقیقاً یک PDU RLC را برای هر انتقال تولید و ارسال می کند
فرصت حتی اگر کوچکتر از اندازه گزارش شده توسط فرصت انتقال باشد.
بنابراین، برای مثال، اگر قرار است یک PDU STATUS ارسال شود، تنها این PDU در آن ارسال خواهد شد.
فرصت انتقال

بخش بندی و الحاق برای صف SDU موجودیت AM RLC به همین ترتیب است.
فلسفه همانند رویه‌های موجودیت UM RLC است، اما متغیرهای حالت جدیدی وجود دارد
(به بخش 36322 [TS7.1] مراجعه کنید) فقط در موجودیت AM RLC وجود دارد.

لازم به ذکر است که با توجه به مشخصات 3GPP، هیچ الحاقی برای آن وجود ندارد
بافر ارسال مجدد

تقسیم بندی مجدد
مدل فعلی موجودیت AM RLC از تقسیم بندی مجدد آن پشتیبانی نمی کند
بافر ارسال مجدد در عوض، موجودیت AM RLC فقط منتظر است تا به اندازه کافی بزرگ دریافت کند
فرصت انتقال

پشتیبانی نشده امکانات
ما از رویه های زیر [TS36322] پشتیبانی نمی کنیم:

· "ارسال نشانه ای مبنی بر تحویل موفقیت آمیز RLC SDU" (به بخش 5.1.3.1.1 مراجعه کنید)

· "به لایه های بالایی نشان دهید که حداکثر ارسال مجدد رسیده است" (به بخش مراجعه کنید
5.2.1)

· "روش های دور انداختن SDU" (به بخش 5.3 مراجعه کنید)

· "رویه استقرار مجدد" (به بخش 5.4 مراجعه کنید)

ما از هیچ یک از موارد اولیه اضافی RLC SAP برای موجودیت AM RLC پشتیبانی نمی کنیم. که در
خاص:

· عدم حذف SDU توسط PDCP

· عدم اطلاع از تحویل موفقیت آمیز / ناموفق توسط نهاد AM RLC به نهاد PDCP

UM RLC
در این بخش پیاده‌سازی حالت Unacknowledge Mode (UM) RLC را شرح می‌دهیم.

انتقال عملیات in downlink
عملیات انتقال UM RLC مشابه عملیات AM RLC قبلی است
شرح داده شده در بخش انتقال عملیات in downlink، با این تفاوت که، زیر
مشخصات [TS36322]، ارسال مجدد انجام نشده است و وضعیتی وجود ندارد
PDU ها

انتقال عملیات in پیوند
عملیات انتقال در uplink مشابه عملیات های downlink با اصلی است
تفاوت این است که Report_Buffer_Status از UE MAC به MAC Scheduler ارسال می شود.
eNB روی هوا با استفاده از کانال کنترل.

محاسبه of la بافر اندازه
محاسبه اندازه بافر برای UM RLC با استفاده از روش مشابه انجام می شود
AM RLC، لطفاً به بخش مراجعه کنید محاسبه of la بافر اندازه برای مربوطه
شرح.

TM RLC
در این بخش پیاده سازی حالت شفاف (TM) RLC را شرح می دهیم.

انتقال عملیات in downlink
در شبیه ساز، TM RLC همچنان همان رابط سرویس را به لایه های بالایی ارائه می دهد
توسط نهادهای AM و UM RLC به لایه PDCP ارائه شده است. در عمل، این رابط است
توسط یک نهاد RRC (نه یک نهاد PDCP) برای انتقال SDUهای RLC استفاده می شود. این انتخاب است
با انگیزه این واقعیت که خدمات ارائه شده توسط TM RLC به لایه های بالایی،
طبق [TS36322]، زیرمجموعه ای از مواردی است که توسط نهادهای UM و AM RLC به
لایه PDCP؛ از این رو، ما از همان رابط برای سادگی استفاده مجدد کردیم.

عملیات انتقال در downlink به شرح زیر انجام می شود. وقتی که
انتقال_PDCP_PDU سرویس بدوی توسط لایه های بالایی فراخوانی می شود، TM RLC این کار را انجام می دهد
زیر است:

SDU را در بافر انتقال قرار دهید

· اندازه بافر انتقال را محاسبه کنید

· با ... تماس بگیر گزارش_وضعیت_بافر سرویس اولیه موجودیت eNB MAC

پس از آن، زمانی که زمان‌بندی MAC تصمیم می‌گیرد که برخی از داده‌ها می‌توانند توسط منطقی ارسال شوند
کانالی که موجودیت TM RLC به آن تعلق دارد، موجودیت MAC آن را به TM RLC اطلاع می دهد.
موجودیت با فراخوانی Notify_Tx_Opportunity سرویس اولیه با استقبال از این
اولیه، موجودیت TM RLC کارهای زیر را انجام می دهد:

· اگر فرصت TX اندازه ای بزرگتر یا مساوی با اندازه داشته باشد
SDU سر خط در بافر انتقال

· SDU سر خط را از بافر انتقال جدا کنید

یک RLC PDU ایجاد کنید که به طور کامل شامل آن SDU باشد، بدون هیچ عنوان RLC

· با ... تماس بگیر Transmit_PDU اولیه به منظور ارسال RLC PDU به موجودیت MAC.

انتقال عملیات in پیوند
عملیات انتقال در uplink مشابه عملیات های downlink با اصلی است
تفاوت در این است که یک فرصت انتقال نیز می تواند از انتساب UL ایجاد شود
GRANT به عنوان بخشی از روش دسترسی تصادفی، بدون گزارش وضعیت بافر صریح
صادر شده توسط نهاد TM RLC.

محاسبه of la بافر اندازه
طبق مشخصات [TS36322]، TM RLC هیچ عنوان RLC را به PDU ها اضافه نمی کند.
در حال انتقال است. به همین دلیل، اندازه بافر گزارش شده به لایه MAC است
بنابراین به سادگی با جمع کردن اندازه تمام بسته ها در بافر انتقال محاسبه می شود
اندازه دقیق بافر را به MAC اطلاع دهید.

SM RLC
علاوه بر پیاده سازی های AM، UM و TM که پس از 3GPP مدل شده اند
مشخصات، یک مدل RLC ساده شده ارائه شده است که به آن حالت اشباع (SM) می گویند.
RLC. این مدل RLC PDU ها را از هیچ لایه بالا (مانند PDCP) نمی پذیرد. بلکه،
SM RLC در پاسخ به اطلاع رسانی از تولید PDU های RLC مراقبت می کند
فرصت های انتقال اطلاع رسانی شده توسط MAC. به عبارت دیگر، SM RLC شبیه سازی می کند
شرایط اشباع، به عنوان مثال، فرض می کند که بافر RLC همیشه پر است و می تواند
هر زمان که توسط زمانبندی اطلاع داده شود یک PDU جدید ایجاد کنید.

SM RLC برای سناریوهای شبیه سازی ساده که در آن فقط مدل رادیویی LTE استفاده می شود
بدون EPC و بنابراین بدون پشتیبانی شبکه IP استفاده می شود. توجه می کنیم که،
اگرچه SM RLC یک مدل ترافیک غیرواقعی است، اما همچنان امکان درستی را فراهم می کند
شبیه‌سازی سناریوها با جریان‌های متعدد متعلق به QoS مختلف (غیر زمان واقعی).
کلاس ها، به منظور آزمایش عملکرد QoS به دست آمده توسط زمانبندی های مختلف. این می تواند
انجام شود زیرا وظیفه زمانبند است که منابع انتقال را بر اساس آن تخصیص دهد
مشخصات (مثلاً نرخ بیت تضمینی) هر حامل رادیویی که مشخص شده است
بر اساس تعریف هر حامل در برنامه شبیه سازی.

در مورد زمان‌بندی‌هایی که برای کار با ترافیک QoS بی‌درنگ طراحی شده‌اند که دارای محدودیت‌های تاخیر هستند،
احتمالاً SM RLC انتخاب مناسبی نیست. این به دلیل عدم وجود واقعی است
RLC SDUs (که با نسل مصنوعی گزارش‌های وضعیت بافر جایگزین شده است) باعث می‌شود که این کار نباشد
این امکان وجود دارد که اطلاعات مربوط به تاخیر سر خط را به زمانبند ارائه دهد، که این است
اغلب معیار انتخابی برای اجرای سیاست‌های زمان‌بندی در زمان واقعی است
جریان های ترافیکی برای شبیه سازی و آزمایش چنین زمانبندی هایی، استفاده از آن توصیه می شود
در عوض مدل های UM یا AM RLC.

PDCP
PDCP مدل بررسی اجمالی
سند مرجع برای مشخصات موجودیت PDCP [TS36323] است. با احترام
برای این مشخصات، مدل PDCP پیاده‌سازی شده در شبیه‌ساز، تنها از آن پشتیبانی می‌کند
ویژگی های زیر:

· انتقال داده ها (سطح کاربر یا صفحه کنترل).

· نگهداری از PDCP SNs.

· انتقال وضعیت SN (برای استفاده در هنگام تحویل).

ویژگی های زیر در حال حاضر پشتیبانی نمی شوند:

· فشرده سازی هدر و رفع فشرده سازی جریان داده های IP با استفاده از پروتکل ROHC.

تحویل متوالی PDUهای لایه بالایی در هنگام استقرار مجدد لایه های پایین.

· حذف تکراری SDUهای لایه زیرین در ایجاد مجدد لایه های پایین تر برای
حامل های رادیویی نقشه برداری شده روی RLC AM.

· رمزگذاری و رمزگشایی داده های صفحه کاربر و داده های صفحه کنترل.

· حفاظت از یکپارچگی و تأیید صحت داده های صفحه کنترل.

· دور انداختن مبتنی بر تایمر.

· دور انداختن تکراری.

PDCP محصولات رابط
رابط سرویس PDCP به دو بخش تقسیم می شود:

· PdcpSapProvider بخش توسط لایه PDCP ارائه شده و توسط لایه بالایی استفاده می شود
و

· PdcpSapUser بخش توسط لایه بالایی ارائه شده و توسط لایه PDCP استفاده می شود.

PDCP محصولات اولیه
لیست زیر مشخص می کند که کدام سرویس های اولیه توسط سرویس PDCP ارائه می شوند
رابط ها:

· PdcpSapProvider::TransmitPdcpSdu

· موجودیت RRC از این اولیه برای ارسال یک PDU RRC به موجودیت PDCP پایین استفاده می کند.
در همتای فرستنده

· PdcpSapUser::ReceivePdcpSdu

· موجودیت PDCP از این اولیه برای ارسال یک PDU RRC به موجودیت RRC بالایی استفاده می کند.
در همتای گیرنده

RRC
امکانات
مدل RRC پیاده سازی شده در شبیه ساز عملکرد زیر را ارائه می دهد:

· تولید (در eNB) و تفسیر (در UE) اطلاعات سیستم (در
به ویژه بلوک اطلاعات اصلی و در زمان نگارش این مقاله فقط سیستم
بلوک اطلاعاتی نوع 1 و 2)

· انتخاب سلول اولیه

· روش ایجاد اتصال RRC

· روش پیکربندی مجدد RRC، از موارد استفاده زیر پشتیبانی می کند: + پیکربندی مجدد
از شاخص پیکربندی SRS + پیکربندی مجدد حالت PHY TX (MIMO) +
پیکربندی مجدد اندازه‌گیری‌های UE + راه‌اندازی حامل رادیویی داده + تحویل

· برقراری مجدد اتصال RRC، از موارد استفاده زیر پشتیبانی می کند: + تحویل

معماری
مدل RRC به اجزای زیر تقسیم می شود:

· نهادهای RRC LteUeRrc و LteEnbrRrc، که ماشین های حالت را پیاده سازی می کنند
نهادهای RRC به ترتیب در UE و eNB.

· RRC SAPs LteUeRrcSapProvider, LteUeRrcSapUser, LteEnbRrcSapProvider,
LteEnbRrcSapUser، که به نهادهای RRC امکان ارسال و دریافت پیام های RRC و
عناصر اطلاعاتی؛

· کلاس های پروتکل RRC LteUeRrcProtocolIdeal, LteEnbRrcProtocolIdeal,
LteUeRrcProtocolReal, LteEnbRrcProtocolReal، که دو مدل مختلف را برای
انتقال پیام های RRC

علاوه بر این، اجزای RRC از SAP های مختلف دیگر برای تعامل با بقیه استفاده می کنند
از پشته پروتکل نمایشی از تمام SAPهایی که استفاده می شوند در
آمار و ارقام LTE رادیو پروتکل پشته معماری برای la UE on la داده ها هواپیما, LTE رادیو
پروتکل پشته معماری برای la UE on la کنترل هواپیما, LTE رادیو پروتکل پشته
معماری برای la eNB on la داده ها هواپیما و LTE رادیو پروتکل پشته معماری برای
la eNB on la کنترل هواپیما.

UE RRC دولت دستگاه
در شکل UE RRC دولت دستگاه ما ماشین حالت را همانطور که در RRC UE پیاده سازی شده است نشان می دهیم
اشخاص
[تصویر] UE RRC State Machine.UNINDENT

لازم به ذکر است که اکثر حالت ها گذرا هستند، یعنی زمانی که UE به یک حالت تبدیل شود.
از حالت های CONNECTED هرگز به هیچ یک از حالت های IDLE برنمی گردد. این انتخاب
به دلایل زیر انجام می شود:

· همانطور که در بخش بحث شد طرح ضوابط، تمرکز شبیه سازی LTE-EPC
مدل در حالت CONNECTED است

خرابی پیوند رادیویی در حال حاضر مدلسازی نشده است، همانطور که در بخش بحث شد رادیو ارتباط دادن
شکست، بنابراین یک UE به دلیل خرابی پیوند رادیویی نمی تواند IDLE شود

· انتشار اتصال RRC در حال حاضر هرگز نه توسط EPC و نه توسط NAS آغاز نمی شود

با این حال، ما تصمیم گرفتیم به طور صریح حالت های IDLE را مدل کنیم، زیرا:

· یک پیکربندی واقعی UE RRC برای انتقال مورد نیاز است، که یک ویژگی ضروری است،
و برای داشتن یک پیاده سازی تمیزتر، منطقی است که از همان UE RRC استفاده کنید
پیکربندی همچنین برای ایجاد اتصال اولیه

· اجرای انتخاب سلول حالت بیکار را در آینده آسان تر می کند، که عبارت است از
ویژگی بسیار مطلوب

ENB RRC دولت دستگاه
eNB RRC وضعیت را برای هر UE که به سلول متصل است حفظ می کند. از یک
از دیدگاه پیاده سازی، وضعیت هر UE در یک نمونه از موجود است
کلاس UeManager. ماشین حالت در شکل نشان داده شده است ENB RRC دولت دستگاه برای هر
UE.
[تصویر] ENB RRC حالت ماشین برای هر UE.UNINDENT

اول سلول انتخاب
انتخاب سلول اولیه یک روش حالت IDLE است که توسط UE در زمانی که هنوز انجام نشده است انجام می شود
اردو زده یا به eNodeB متصل شده است. هدف از این روش یافتن یک سلول مناسب است
و برای دسترسی به شبکه تلفن همراه به آن متصل شوید.

همانطور که در شکل نشان داده شده است معمولاً در ابتدای شبیه سازی انجام می شود نمونه اجرا می شود of
اول سلول انتخاب in UE و زمان of مربوط حوادث زیر نمودار زمان در
سمت چپ حالتی را نشان می دهد که انتخاب سلول اولیه در اولین تلاش موفق می شود،
در حالی که نمودار سمت راست برای موردی است که در اولین تلاش شکست بخورد و
در تلاش دوم موفق شوید زمان‌بندی استفاده از مدل پروتکل RRC واقعی را فرض می‌کند (نگاه کنید به RRC
پروتکل مدل) و بدون خطای انتقال.
[تصویر] اجراهای نمونه انتخاب سلول اولیه در UE و زمان بندی مربوط
رویدادها.UNINDENT

این عملکرد بر اساس مشخصات حالت IDLE 3GPP است، مانند [TS36300]،
[TS36304] و [TS36331]. با این حال، اجرای مناسب حالت IDLE هنوز وجود ندارد
در شبیه ساز، بنابراین چندین فرض ساده کننده را رزرو می کنیم:

· فرکانس حامل چندگانه پشتیبانی نمی شود.

· چندین هویت شبکه عمومی زمین موبایل (PLMN) (یعنی چندین شبکه
اپراتورها) پشتیبانی نمی شود.

· اندازه گیری RSRQ استفاده نمی شود.

· انتخاب سلول اطلاعات ذخیره شده پشتیبانی نمی شود.

· حالت "Any Cell Selection" و اردو زدن به یک سلول قابل قبول پشتیبانی نمی شود.

· علامت گذاری یک سلول به عنوان مسدود یا رزرو شده پشتیبانی نمی شود.

· انتخاب مجدد سلول پشتیبانی نمی شود، بنابراین امکان کمپ کردن UE به a وجود ندارد
سلول های مختلف پس از قرار دادن اردوگاه اولیه. و

· لیست سفید گروه مشترکین بسته (CSG) UE تنها حاوی یک هویت CSG است.

همچنین توجه داشته باشید که انتخاب سلول اولیه فقط برای شبیه سازی های دارای EPC در دسترس است.
شبیه سازی های LTE فقط باید از روش پیوست دستی استفاده کنند. بخش را ببینید
sec-network-پیوست مستندات کاربر برای اطلاعات بیشتر در مورد تفاوت آنها
در استفاده

بخش‌های فرعی بعدی بخش‌های مختلف انتخاب سلول اولیه را پوشش می‌دهند سلول جستجو کردن,
پخش of سیستم اطلاعاتو سلول انتخاب ارزیابی.

سلول جستجو
هدف جستجوی سلولی شناسایی سلول های اطراف و اندازه گیری قدرت سیگنال دریافتی است
از هر یک از این سلول ها یکی از این سلول ها به نقطه ورود UE برای پیوستن به آن تبدیل می شود
شبکه تلفن همراه

اندازه‌گیری‌ها بر اساس RSRP PSS دریافت‌شده، میانگین‌گیری شده توسط فیلتر لایه 1 است.
و توسط لایه PHY انجام می شود، همانطور که قبلاً با جزئیات بیشتر در بخش توضیح داده شد UE PHY
اندازه گیری مدل. PSS توسط eNodeB از طریق 72 حامل فرعی مرکزی منتقل می شود
کانال DL (بخش 5.1.7.3 [TS36300])، از این رو جستجوی سلولی را برای کار با استفاده از یک DL مدل می کنیم.
پهنای باند 6 RBs توجه داشته باشید که اندازه گیری RSRQ در حال حاضر در دسترس نیست
در شبیه سازی در نتیجه، LteUePhy::RsrqUeMeasThreshold ویژگی ندارد
در طول جستجوی سلولی اعمال شود.

با استفاده از RSRP اندازه گیری شده، موجودیت PHY قادر است لیستی از سلول های شناسایی شده را تولید کند.
هر کدام با شناسه سلولی مربوطه و میانگین RSRP. این لیست به صورت دوره ای تحت فشار قرار می گیرد
از طریق CPHY SAP به نهاد RRC به عنوان گزارش اندازه گیری.

نهاد RRC گزارش را بازرسی می کند و به سادگی سلولی را با قوی ترین RSRP انتخاب می کند
همچنین در بخش 5.2.3.1 [TS36304] نشان داده شده است. سپس به موجودیت PHY دستور می دهد
با این سلول خاص همگام سازی کنید. پهنای باند عملیاتی واقعی سلول همچنان باقی است
در حال حاضر ناشناخته است، بنابراین موجودیت PHY فقط به حداقل پهنای باند 6 RB گوش می دهد.
با این وجود، نهاد PHY قادر به دریافت پیام پخش سیستم از این خواهد بود
eNodeB خاص، که موضوع زیربخش بعدی است.

پخش of سیستم اطلاعات
بلوک های اطلاعات سیستم توسط eNodeB به UE ها در بازه های زمانی از پیش تعریف شده پخش می شوند.
برگرفته از بخش 5.2.1.2 [TS36331]. بلوک های اطلاعات سیستم پشتیبانی شده عبارتند از:

·

استاد اطلاعات مسدود کردن (MIB)
حاوی پارامترهای مربوط به لایه PHY است که در طول سلول تولید می شود
پیکربندی و هر 10 میلی ثانیه در ابتدای قاب رادیویی به صورت یک پخش می شود
پیام کنترل

·

سیستم اطلاعات مسدود کردن نوع 1 (SIB1)
حاوی اطلاعات مربوط به دسترسی به شبکه است که هر 20 میلی ثانیه در شبکه پخش می شود
وسط قاب رادیویی به عنوان یک پیام کنترلی. در پیوست دستی استفاده نمی شود
روش. UE قبل از اینکه بتواند SIB1 را دریافت کند باید MIB را رمزگشایی کرده باشد.

·

سیستم اطلاعات مسدود کردن نوع 2 (SIB2)
شامل تنظیمات مربوط به UL و RACH است که برای انتقال از طریق پروتکل RRC برنامه ریزی شده است
در 16 میلی ثانیه پس از پیکربندی سلول، و سپس هر 80 میلی ثانیه تکرار می شود (قابل تنظیم
از طریق LteEnbRrc::تناوبی اطلاعات سیستم صفت. UE باید کمپ شود
به یک سلول تا بتواند SIB2 خود را دریافت کند.

دریافت اطلاعات سیستم برای پیشبرد UE در چرخه حیاتش اساسی است. MIB
UE را قادر می سازد تا پهنای باند DL اولیه 6 RB را به عملیات واقعی افزایش دهد.
پهنای باند شبکه SIB1 اطلاعات لازم برای انتخاب سلول را فراهم می کند
ارزیابی (در بخش بعدی توضیح داده شد). و در نهایت SIB2 قبل از UE مورد نیاز است
اجازه تغییر به حالت CONNECTED.

سلول انتخاب ارزیابی
UE RRC گزارش اندازه گیری تولید شده در را بررسی می کند سلول جستجو و دسترسی به سلول
اطلاعات ارائه شده توسط SIB1. هنگامی که هر دو اطلاعات برای یک سلول خاص در دسترس هستند،
UE فرآیند ارزیابی را آغاز می کند. هدف از این فرآیند تعیین اینکه آیا
سلول سلولی مناسب برای کمپ زدن است.

فرآیند ارزیابی یک نسخه کمی ساده شده از بخش 5.2.3.2 [TS36304] است.
از معیارهای زیر تشکیل شده است:

· معیار سطح Rx. و

· معیار گروه مشترکین بسته (CSG).

اولین معیار، سطح Rx، بر اساس RSRP Q_{rxlevmeas} اندازه گیری شده سلول است که
برای عبور از این معیار باید از حداقل Q_{rxlevmin} بیشتر باشد:

که در آن Q_{rxlevmin} توسط هر eNodeB تعیین می شود و توسط UE از SIB1 قابل دستیابی است.

آخرین معیار، CSG، ترکیبی از یک پارامتر درست یا نادرست به نام است CSG
نشانه و یک عدد ساده CSG هویت. قاعده اصلی این است که اتحادیه اروپا نباید به آن اردو بزند
eNodeB با هویت CSG متفاوت. اما این قانون تنها زمانی اجرا می شود که نشانه CSG باشد
به عنوان واقعی ارزش گذاری شده است. جزئیات بیشتر در بخش sec-network-attachment کاربر ارائه شده است
مستندات.

هنگامی که سلول تمام معیارهای فوق را پاس کند، سلول به عنوان در نظر گرفته می شود مناسب. سپس UE
به آن اردو می زند (IDLE_CAMPED_NORMALLY دولت).

پس از این، لایه بالایی ممکن است از UE درخواست کند تا وارد حالت CONNECTED شود. لطفا به بخش مراجعه کنید
RRC ارتباط استقرار برای جزئیات بیشتر در این مورد

از طرف دیگر، زمانی که سلول معیار CSG را پاس نمی کند، آنگاه سلول برچسب گذاری می شود.
as قابل قبول (بخش 10.1.1.1 [TS36300]). در این مورد، نهاد RRC به PHY می گوید
موجودی برای همگام سازی با دومین سلول قوی و تکرار انتخاب سلول اولیه
روش با استفاده از آن سلول تا زمانی که سلول مناسبی پیدا نشود، UE این موارد را تکرار خواهد کرد
در حالی که از سلول هایی که به عنوان قابل قبول تشخیص داده شده اند اجتناب کنید.

رادیو پذیرش کنترل
کنترل ورودی رادیویی با داشتن پاسخ eNB RRC به یک اتصال RRC پشتیبانی می شود
پیام درخواست ارسال شده توسط UE با یک پیام RRC CONNECTION SETUP یا یک RRC
پیام رد اتصال، بسته به اینکه آیا UE جدید باید پذیرفته شود یا خیر. که در
در اجرای فعلی، رفتار توسط ویژگی بولی تعیین می شود
ns3::LteEnbrRrc::AdmitRrcConnectionRequest. در حال حاضر هیچ کنترلی برای پذیرش رادیو وجود ندارد
الگوریتمی که به صورت پویا تصمیم می گیرد که آیا یک اتصال جدید پذیرفته شود یا خیر.

رادیو باربر پیکر بندی
برخی از انتخاب های پیاده سازی در RRC در مورد راه اندازی رادیو انجام شده است
حاملان:

سه گروه کانال منطقی (از چهار گروه موجود) برای بافر uplink پیکربندی شده اند
اهداف گزارش وضعیت، طبق سیاست زیر:

· LCG 0 برای سیگنال دهی حامل های رادیویی است

· LCG 1 برای حامل های رادیویی داده GBR است

· LCG 2 برای حامل های رادیویی داده غیر GBR است

رادیو ارتباط دادن شکست
از آنجایی که در این مرحله RRC فقط از حالت CONNECTED پشتیبانی می کند، خرابی پیوند رادیویی (RLF) است.
رسیدگی نمی شود. دلیل آن این است که یکی از نتایج احتمالی RLF (زمانی که RRC
استقرار مجدد ناموفق است) این است که RRC CONNECTED را با اطلاع NAS از RRC ترک کنید
شکست اتصال برای مدلسازی صحیح RLF، حالت RRC IDLE باید پشتیبانی شود.
از جمله در حالت بیکار خاص سلول (دوباره) انتخاب.

با مدل فعلی، UE که کیفیت لینک بدی را تجربه می‌کند و کارایی ندارد
انتقال
اشتباه پیکربندی شده) فقط با همان eNB مرتبط می ماند و زمانبندی متوقف می شود
تخصیص منابع به آن برای ارتباطات.

UE RRC اندازه گیری مدل
UE RRC اندازه گیری پشتیبانی
نهاد UE RRC پشتیبانی از اندازه گیری های UE را فراهم می کند. به طور خاص، آن را اجرا می کند
رویه های شرح داده شده در بخش 5.5 [TS36331]، با ساده سازی زیر
فرضیات:

· فقط اندازه‌گیری‌های درون فرکانس E-UTRA پشتیبانی می‌شوند که به این معنی است:

· در طول شبیه سازی فقط یک شی اندازه گیری استفاده می شود.

· برای انجام اندازه گیری ها به شکاف های اندازه گیری نیاز نیست.

· رویداد B1 و B2 اجرا نمی شوند.

· فقط گزارش StrongestCells هدف پشتیبانی می شود، در حالی که گزارشCGI و
گزارشStrongestCellsForSON اهداف پشتیبانی نمی شوند.

· s-Measure پشتیبانی نمی شود؛

· از آنجایی که تجمیع حامل توسط ماژول LTE پشتیبانی نمی شود، به شرح زیر است
مفروضات در اندازه گیری های UE درست است:

· بدون مفهوم سلول ثانویه (SCell);

· سلول اولیه (PCell) به سادگی به معنای خدمت به سلول است.

· رویداد A6 اجرا نمی شود.

· مقیاس بندی زمان تا ماشه وابسته به سرعت (بخش 5.5.6.2 [TS36331]) نیست
پشتیبانی.

به طور کلی طرح
مدل بر اساس مفهوم است UE اندازه گیری مصرف کننده، که موجودی است که ممکن است
از یک موجودیت RRC eNodeB برای ارائه گزارش های اندازه گیری UE درخواست کنید. مصرف کنندگان هستند، برای
مثال، تحویل دادن الگوریتم، که تصمیم تحویل را بر اساس اندازه گیری UE محاسبه می کند
گزارش ها. موارد تست و برنامه های کاربر نیز ممکن است به مصرف کننده تبدیل شوند. شکل ارتباط
میان UE اندازه گیری و آن مصرف کنندگان رابطه بین این موجودات را نشان می دهد.
[تصویر] رابطه بین اندازه گیری های UE و مصرف کنندگان آن.UNINDENT

کل عملکرد اندازه گیری UE در سطح RRC به 4 بخش عمده تقسیم می شود:

1. پیکربندی اندازه گیری (که توسط LteUeRrc::ApplyMeasConfig)

2. انجام اندازه‌گیری‌ها (که توسط LteUeRrc::DoReportUeMeasurements)

3. راه اندازی گزارش اندازه گیری (که توسط LteUeRrc::MeasurementReportTriggering)

4. گزارش اندازه گیری (که توسط LteUeRrc::SendMeasurementReport)

در بخش های بعدی هر یک از قسمت های بالا توضیح داده می شود.

اندازه گیری پیکر بندی
یک موجودیت RRC eNodeB اندازه گیری های UE را با ارسال پارامترهای پیکربندی به
نهاد UE RRC. این مجموعه از پارامترها در داخل تعریف شده است MeasConfig اطلاعات
عنصر (IE) پیام پیکربندی مجدد اتصال RRC (RRC ارتباط
راه اندازی مجدد).

موجودیت eNodeB RRC پارامترهای پیکربندی و رویه های شرح داده شده در را پیاده سازی می کند
بخش 5.5.2 [TS36331]، با فرض ساده‌سازی زیر:

· پیکربندی (یعنی افزودن، اصلاح و حذف) فقط قبل از
شبیه سازی آغاز می شود.

· تمام UE های متصل به eNodeB به همین ترتیب پیکربندی می شوند، یعنی هیچ وجود ندارد
پشتیبانی از پیکربندی اندازه گیری خاص برای UE خاص. و

· فرض بر این است که یک نقشه برداری یک به یک بین PCI و E-UTRAN وجود دارد
شناسه سلولی جهانی (EGCI). این با مفروضات مدل سازی PCI سازگار است
توصیف شده در UE PHY اندازه گیری مدل.

نمونه eNodeB RRC در اینجا به عنوان یک واسطه بین مصرف کنندگان و مصرف کنندگان عمل می کند
UE های پیوست شده در ابتدای شبیه سازی، هر مصرف کننده eNodeB RRC را ارائه می دهد
به عنوان مثال با پیکربندی اندازه گیری UE که به آن نیاز دارد. پس از آن، eNodeB
RRC پیکربندی را به UE های پیوست شده توزیع می کند.

کاربران ممکن است پیکربندی اندازه گیری را با استفاده از چندین روش سفارشی کنند. مراجعه فرمایید
بخش sec-configure-ue-measurements از مستندات کاربر برای شرح
این روش ها

انجام اندازه گیری
UE RRC هر دو اندازه گیری RSRP و RSRQ را به صورت دوره ای از UE PHY دریافت می کند.
توصیف شده در UE PHY اندازه گیری مدل. لایه 3 فیلتر برای این موارد اعمال خواهد شد
اندازه گیری ها را دریافت کرد. اجرای فیلتر از بخش 5.5.3.2 پیروی می کند
[TS36331]:

که در آن:

· M_n آخرین نتیجه اندازه گیری دریافت شده از لایه فیزیکی است.

· F_n نتیجه اندازه گیری فیلتر شده به روز شده است.

· F_{n-1} نتیجه اندازه گیری فیلتر شده قدیمی است که در آن F_0 = M_1 (یعنی اولین
اندازه گیری فیلتر نشده است)؛ و

· a = (ac{1}{2})^{ac{k}{4}}، که در آن k قابل تنظیم است ضریب فیلتر ارائه شده توسط
la QuantityConfig;

k = 4 مقدار پیش فرض است، اما می توان با تنظیم آن پیکربندی کرد ضریب فیلتر Rsrp و
ضریب فیلتر Rsrq صفات در LteEnbrRrc.

بنابراین k = 0 فیلتر لایه 3 را غیرفعال می کند. از سوی دیگر، اندازه گیری های گذشته می تواند
با استفاده از مقدار بزرگتر k، تأثیر بیشتری بر نتایج فیلتر کردن داده می شود.

اندازه گیری گزارش راه اندازی
در این قسمت، UE RRC لیست تنظیمات اندازه گیری فعال و
بررسی کنید که آیا شرط آغازگر مطابق با بخش 5.5.4 از برآورده شده است یا خیر
[TS36331]. زمانی که حداقل یک وضعیت محرک از تمام اندازه گیری های فعال وجود دارد
پیکربندی انجام شده است، روش گزارش اندازه گیری (در ادامه توضیح داده شده است
بخش فرعی) آغاز خواهد شد.

3GPP دو نوع تعریف می کند نوع: دوره ای و مبتنی بر رویداد. در حال حاضر ، فقط
معیار مبتنی بر رویداد پشتیبانی می شود. رویدادهای مختلفی را می توان انتخاب کرد، که
در جدول زیر به اختصار توضیح داده شده است:

فهرست of پشتیبانی مبتنی بر رویداد راه اندازی ضوابط
┌─────────┬─────── ────┐
│نام │ توضیحات │
├─────────┼─────────── ────┤
│رویداد A1 │ سلول خدمت بهتر از │ می شود
│ آستانه │
├─────────┼─────────── ────┤
│رویداد A2 │ سرویس سلول بدتر از │ می شود
│ آستانه │
├─────────┼─────────── ────┤
│رویداد A3 │ Neighbor می شود چاپ افست دسی بل │
│ │ بهتر از خدمت سلول │
├─────────┼─────────── ────┤
│رویداد A4 │ Neighbor بهتر از │ می شود
│ آستانه │
└─────────┴─────── ────┘

│رویداد A5 │ خدمت بدتر از │ می شود
│ آستانه 1 و همسایه می شود │
│ │ بهتر از آستانه 2 │
└─────────┴─────── ────┘

دو شرط اصلی که باید در یک تریگر مبتنی بر رویداد بررسی شوند عبارتند از: وارد شدن شرط و
la ترک شرط. جزئیات بیشتر در مورد این دو را می توان در بخش 5.5.4 یافت
[TS36331].

یک تریگر مبتنی بر رویداد را می توان با معرفی پسماند و پیکربندی بیشتر کرد
زمان تا ماشه هیسترزیس (Hys) فاصله بین ورود و خروج را مشخص می کند
شرایط بر حسب دسی بل به همین ترتیب، زمان تا ماشه تاخیر را هم برای ورود و هم برای خروج معرفی می کند
شرایط، اما به عنوان یک واحد زمان.

La دوره ای نوع ماشه گزارش پشتیبانی نمی شود، اما رفتار آن به راحتی قابل انجام است
با استفاده از یک ماشه مبتنی بر رویداد به دست می آید. این را می توان با پیکربندی اندازه گیری انجام داد
به گونه ای که شرط ورود همیشه انجام می شود، مثلاً با تنظیم کردن
آستانه رویداد A1 تا صفر (حداقل سطح). در نتیجه، اندازه گیری گزارش می دهد
همیشه در هر بازه زمانی مشخص، همانطور که توسط ReportInterval
میدان داخل LterRrcSap::ReportConfigEutra، بنابراین همان رفتار را ایجاد می کند
گزارش دوره ای

به عنوان یک محدودیت با توجه به مشخصات 3GPP، مدل فعلی پشتیبانی نمی کند
هر پیکربندی خاص سلول این پارامترهای پیکربندی در اندازه گیری تعریف می شوند
هدف - شی. در نتیجه، ترکیب لیستی از سلول‌های سیاه در فرآیند راه‌اندازی
پشتیبانی نمی شود. علاوه بر این، افست اختصاصی سلول (به عنوان مثال، O_{cn} و O_{cp} در رویداد A3، A4،
و A5) نیز پشتیبانی نمی شوند. مقدار برابر با صفر همیشه به جای آن در نظر گرفته می شود
آنها.

اندازه گیری گزارش
این بخش ارسال گزارش اندازه‌گیری از نهاد UE RRC را انجام می‌دهد
ارائه نهاد eNodeB از طریق پروتکل RRC. چندین فرض ساده پذیرفته شده است:

· گزارش مقدار is نه قابل اجرا (یعنی همیشه بی نهایت فرض می شود)؛

· در گزارش های اندازه گیری، مقدار گزارش همیشه فرض می شود هر دو، یعنی هر دو
RSRP و RSRQ همیشه گزارش می شوند، صرف نظر از اینکه triggerQuantity.

تحویل دادن
مدل RRC از تحرک UE در حالت CONNECTED با فراخوانی انتقال مبتنی بر X2 پشتیبانی می کند.
روش. مدل درون EUTRAN و درون فرکانس است، همانطور که بر اساس بخش 10.1.2.1 از
[TS36300].

این بخش بر روی فرآیند آغاز به کار واگذاری تمرکز دارد. اجرای واگذاری
خود روش در بخش پوشش داده شده است X2.

دو راه برای شروع فرآیند تحویل وجود دارد:

· به صراحت (یا به صورت دستی) توسط برنامه شبیه سازی با برنامه ریزی یک
اجرای روش LteEnbRrc::SendHandoverRequestو یا

· بطور خودکار توسط نهاد eNodeB RRC بر اساس اندازه‌گیری‌های UE و
با توجه به الگوریتم انتقال انتخاب شده.

بخش sec-x2-based-handover مستندات کاربر چند مثال در مورد استفاده ارائه می دهد
محرک های تحویل صریح و خودکار در شبیه سازی. زیربخش بعدی خواهد بود
با تشریح جنبه های طراحی روش خودکار، نگاهی دقیق تر به روش خودکار بیندازید
رابط الگوریتم تحویل و الگوریتم های تحویل موجود.

تحویل دادن الگوریتم
Handover در 3GPP LTE دارای ویژگی های زیر است:

·

به کمک UE
UE ورودی شبکه را در قالب گزارش های اندازه گیری فراهم می کند. این
توسط UE RRC اندازه گیری مدل.

·

تحت کنترل شبکه
شبکه (به عنوان مثال منبع eNodeB و eNodeB هدف) تصمیم می گیرد که چه زمانی انجام شود
تحویل را آغاز کرده و بر اجرای آن نظارت می کند.

La تحویل دادن الگوریتم در منبع eNodeB کار می کند و مسئولیت انتقال را بر عهده دارد
تصمیم گیری به شیوه ای "خودکار". با یک نمونه eNodeB RRC از طریق
تحویل دادن مدیریت SAP رابط. این روابط در شکل نشان داده شده است
ارتباط میان UE اندازه گیری و آن مصرف کنندگان از بخش قبل

رابط الگوریتم انتقال از روش های زیر تشکیل شده است:

·

adduemeasreportconfigforhandover
(الگوریتم انتقال -> eNodeB RRC) توسط الگوریتم انتقال برای درخواست استفاده می شود
گزارش های اندازه گیری از موجودیت RRC eNodeB، با ارسال مورد دلخواه
پیکربندی گزارش پیکربندی برای همه آینده اعمال خواهد شد
UE های پیوست شده

·

ReportUeMeas
(eNodeB RRC -> الگوریتم انتقال) بر اساس اندازه‌گیری‌های UE پیکربندی شده
اوایل در adduemeasreportconfigforhandover، UE ممکن است گزارش های اندازه گیری را ارسال کند
به eNodeB. موجودیت eNodeB RRC از ReportUeMeas رابط به
این گزارش های اندازه گیری را به الگوریتم انتقال ارسال کنید.

·

TriggerHandover
(Handover Algorithm -> eNodeB RRC) پس از بررسی گزارش های اندازه گیری
(اما نه لزوما)، الگوریتم انتقال ممکن است یک تحویل را اعلام کند. این
از روش برای اطلاع دادن به نهاد eNodeB RRC در مورد این تصمیم استفاده می شود
سپس مراحل تحویل را شروع کنید.

یک یادداشت برای adduemeasreportconfigforhandover. متد، را برمی گرداند measId
(هویت اندازه گیری) پیکربندی اندازه گیری جدید ایجاد شده. به طور معمول الف
الگوریتم انتقال این عدد منحصر به فرد را ذخیره می کند. ممکن است مفید باشد در ReportUeMeas
روش، به عنوان مثال زمانی که بیش از یک پیکربندی درخواست شده است و تحویل
الگوریتم نیاز به تمایز گزارش های دریافتی بر اساس پیکربندی دارد
آنها را تحریک کرد.

یک الگوریتم انتقال با نوشتن زیر کلاس پیاده سازی می شود الگوریتم LteHandover
superclass انتزاعی و پیاده سازی هر یک از روش های رابط SAP ذکر شده در بالا.
کاربران ممکن است الگوریتم تحویل خود را از این طریق توسعه دهند و سپس از آن در هر شبیه سازی استفاده کنند
با دنبال کردن مراحل ذکر شده در بخش sec-x2-based-handover کاربر
مستندات.

همچنین، کاربران ممکن است یکی از 3 الگوریتم تحویل داخلی ارائه شده را انتخاب کنند
توسط ماژول LTE: بدون عملیات، A2-A4-RSRQ، و قوی ترین الگوریتم انتقال سلول. آن ها هستند
آماده برای استفاده در شبیه سازی ها یا می توان آن را به عنوان نمونه ای از پیاده سازی یک تحویل در نظر گرفت
الگوریتم هر یک از این الگوریتم های داخلی در هر یک از موارد زیر پوشش داده شده است
زیر بخش ها

بدون عملیات تحویل دادن الگوریتم
La بدون اپ تحویل دادن الگوریتم (الگوریتم NoOpHandover کلاس) ساده ترین ممکن است
پیاده سازی الگوریتم انتقال اساساً هیچ کاری نمی کند، یعنی هیچ تماسی نمی گیرد
از روش های رابط مدیریت انتقال SAP. کاربران ممکن است این الگوریتم تحویل را انتخاب کنند
اگر آنها مایل به غیرفعال کردن ماشه تحویل خودکار در شبیه سازی خود هستند.

A2-A4-RSRQ تحویل دادن الگوریتم
La A2-A4-RSRQ تحویل دادن الگوریتم قابلیت انتقال پیش فرض را فراهم می کند
الگوریتمی که در اصل در LENA M6 (ns-3.18) گنجانده شده است، به SAP مدیریت انتقال داده شده است.
رابط به عنوان الگوریتم A2A4RsrqHandover کلاس.

همانطور که از نام آن پیداست، الگوریتم از کیفیت دریافت سیگنال مرجع (RSRQ) استفاده می کند.
اندازه گیری های به دست آمده از رویداد A2 و رویداد A4. بنابراین، الگوریتم 2 را اضافه می کند
پیکربندی اندازه گیری به نمونه eNodeB RRC مربوطه. استفاده مورد نظر آنها هستند
به شرح زیر است:

· واقعه A2 (خدمات RSRQ سلول بدتر از آستانه) برای نشان دادن اهرمی است
که UE کیفیت سیگنال ضعیفی را تجربه می‌کند و ممکن است از انتقال سود بهره مند شود.

· واقعه A4 (RSRQ سلول همسایه بهتر از آستانه) برای تشخیص استفاده می شود
سلول های همسایه و RSRQ مربوطه خود را از هر UE متصل به دست می آورند که
سپس توسط الگوریتم به صورت داخلی ذخیره می شوند. به طور پیش فرض، الگوریتم پیکربندی می شود
رویداد A4 با آستانه بسیار پایین، به طوری که معیارهای ماشه همیشه درست هستند.

شکل A2-A4-RSRQ تحویل دادن الگوریتم در زیر این روش را خلاصه می کند.
[تصویر] الگوریتم انتقال A2-A4-RSRQ.UNINDENT

دو ویژگی را می توان برای تنظیم رفتار الگوریتم تنظیم کرد:

·

ServingCell Threshold
La آستانه برای رویداد A2، یعنی یک UE باید RSRQ کمتر از این داشته باشد
آستانه ای که برای واگذاری در نظر گرفته شود.

·

NeighbourCellOffset
La چاپ افست هدف آن اطمینان از این است که UE کیفیت سیگنال بهتری را دریافت می کند
پس از تحویل یک سلول همسایه به عنوان سلول هدف در نظر گرفته می شود
تنها در صورتی تحویل داده شود که RSRQ آن از RSRQ سلول ارائه دهنده با مقدار آن بیشتر باشد
از این چاپ افست.

مقدار هر دو ویژگی به عنوان محدوده RSRQ بیان می شود (بخش 9.1.7 از [TS36133])،
که یک عدد صحیح بین 0 تا 34 است و 0 به عنوان کمترین RSRQ است.

قویترین سلول تحویل دادن الگوریتم
La قوی ترین سلول تحویل دادن الگوریتم، یا گاهی اوقات به عنوان سنتی قدرت
بودجه (PBGT) الگوریتم، با استفاده از [Dimou2009] به عنوان مرجع توسعه یافته است. ایده این است که
بهترین قدرت دریافتی سیگنال مرجع (RSRP) را برای هر UE فراهم کنید. این هست
به محض اینکه سلول بهتر (یعنی با RSRP قوی تر) انجام شود، یک انتقال انجام می شود
شناسایی شده.

واقعه A3 (RSRP سلول همسایه بهتر از RSRP سلول همسایه می شود) انتخاب شده است
این مفهوم را درک کنید این الگوریتم A3RsrpHandover کلاس نتیجه است
پیاده سازی. انتقال برای UE به بهترین سلول در اندازه گیری فعال می شود
گزارش.

شبیه‌سازی‌هایی که از این الگوریتم استفاده می‌کنند معمولاً در برابر تحویل پینگ پنگ آسیب‌پذیرتر هستند
(تحویل متوالی به منبع قبلی eNodeB در مدت زمان کوتاهی)،
به خصوص زمانی که محو شدن مدل فعال شده است. این مشکل معمولا توسط
ایجاد تاخیر معین در تحویل. الگوریتم این کار را با گنجاندن انجام می دهد
پسماند و پارامترهای زمان تا ماشه (بخش 6.3.5 از [TS36331]) به UE
پیکربندی اندازه گیری

هیسترزیس (معروف به حاشیه واگذاری) واگذاری را در رابطه با RSRP به تاخیر می اندازد. ارزش است
بیان شده بر حسب دسی بل، بین 0 تا 15 دسی بل است و دارای دقت 0.5 دسی بل است، به عنوان مثال، ورودی
مقدار 2.7 دسی بل به 2.5 دسی بل گرد می شود.

از سوی دیگر، زمان تا ماشه تحویل را از نظر زمان به تاخیر می اندازد. 3GPP 16 را تعریف می کند
مقادیر معتبر برای زمان تا شروع (همه در میلی ثانیه): 0، 40، 64، 80، 100، 128، 160، 256،
320، 480، 512، 640، 1024، 1280، 2560 و 5120.

تفاوت بین هیسترزیس و زمان تا شروع در شکل نشان داده شده است اثر of
هیسترس و زمان تا ماشه in قوی ترین سلول تحویل دادن الگوریتم زیر که گرفته شده است
از lena-x2-handover-measures مثال. این RSRP درک شده از سلول خدمت رسانی را به تصویر می کشد
و یک سلول مجاور توسط یک UE که از مرز سلول ها عبور می کند.
[تصویر] اثر هیسترزیس و زمان تا ماشه در انتقال قوی‌ترین سلول
الگوریتم.UNINDENT

به‌طور پیش‌فرض، الگوریتم از پسماند 3.0 دسی‌بل و زمان آغازگر 256 میلی‌ثانیه استفاده می‌کند.
این مقادیر را می توان از طریق تنظیم کرد هیسترزیس و TimeToTrigger ویژگی های
الگوریتم A3RsrpHandover کلاس.

همسایه رابطه
ماژول LTE از یک ساده شده پشتیبانی می کند اتوماتیک همسایه رابطه عملکرد (ANR). این هست
توسط LteAnr کلاس، که با یک نمونه eNodeB RRC از طریق ANR تعامل دارد
رابط SAP.

همسایه رابطه جدول
ANR دارای یک همسایه رابطه جدول (NRT)، مشابه توضیحات در بخش
22.3.2a از [TS36300]. هر ورودی در جدول a نامیده می شود همسایه رابطه (NR) و
یک سلول همسایه شناسایی شده را نشان می دهد که حاوی فیلدهای بولی زیر است:

·

نه برداشتن
نشان می دهد که NR باید نه از NRT حذف شود. این هست درست by
پیش فرض برای NR ارائه شده توسط کاربر و غلط در غیر این صورت.

·

نه X2 نشان می دهد که NR باید نه برای شروع از یک رابط X2 استفاده کنید
رویه‌هایی به سوی eNodeB که سلول هدف را پرورش می‌دهد. این هست غلط by
پیش فرض برای NR ارائه شده توسط کاربر، و درست در غیر این صورت.

·

نه HO نشان می دهد که NR باید نه توسط eNodeB به دلایل انتقال استفاده شود.
این هست درست در بیشتر موارد، به جز زمانی که NR هم توسط کاربر ارائه شده باشد و هم
شبکه شناسایی شد

هر ورودی NR ممکن است حداقل یکی از ویژگی های زیر را داشته باشد:

·

توسط کاربر ارائه شده است
این نوع NR طبق دستور کاربر شبیه سازی ایجاد می شود. مثلا،
یک NR به طور خودکار پس از ایجاد X2 توسط کاربر ایجاد می شود
اتصال بین 2 eNodeB، به عنوان مثال. همانطور که در بخش توضیح داده شده است
sec-x2-based-handover. راه دیگر برای ایجاد NR ارائه شده توسط کاربر فراخوانی است
AddNeighbourRation به صراحت عمل کند

·

شبکه شناسایی شد
این نوع NR به طور خودکار در طول شبیه سازی در نتیجه ایجاد می شود
کشف یک سلول در نزدیکی

به منظور ایجاد خودکار NR شناسایی شده توسط شبکه، ANR از اندازه گیری های UE استفاده می کند. که در
به عبارت دیگر، ANR مصرف کننده اندازه گیری های UE است، همانطور که در شکل نشان داده شده است ارتباط
میان UE اندازه گیری و آن مصرف کنندگان. RSRQ و رویداد A4 (همسایه بهتر می شود
نسبت به آستانه) برای پیکربندی گزارش استفاده می شود. رویداد پیش‌فرض A4 آستانه
روی کمترین میزان ممکن، یعنی حداکثر قابلیت تشخیص تنظیم شده است، اما می توان آن را تغییر داد
تنظیم کردن آستان ویژگی از LteAnr کلاس توجه داشته باشید که تحویل A2-A4-RSRQ
الگوریتم همچنین از یک پیکربندی گزارش مشابه استفاده می کند. با وجود شباهت، وقتی
هر دو ANR و این الگوریتم انتقال در eNodeB فعال هستند، آنها از گزارش جداگانه استفاده می کنند
پیکربندی

همچنین توجه داشته باشید که راه اندازی خودکار رابط X2 پشتیبانی نمی شود. به همین دلیل است
la نه X2 و نه HO فیلدها در NR شناسایی شده توسط شبکه درست هستند اما توسط کاربر شناسایی نمی شوند.

نقش of ANR in شبیه سازی
رابط ANR SAP وسیله ارتباطی بین ANR و eNodeB RRC را فراهم می کند. مقداری
توابع رابط توسط eNodeB RRC برای تعامل با NRT استفاده می شود، همانطور که در زیر نشان داده شده است:

·

AddNeighbourRation
(eNodeB RRC -> ANR) یک ورودی NR جدید ارائه شده توسط کاربر به NRT اضافه کنید.

·

GetNoRemove
(eNodeB RRC -> ANR) مقدار را دریافت کنید نه برداشتن فیلد یک ورودی NR از
شناسه سلول داده شده

·

GetNoHo
(eNodeB RRC -> ANR) مقدار را دریافت کنید نه HO فیلد ورودی NR داده شده
شناسه سلولی

·

GetNoX2
(eNodeB RRC -> ANR) مقدار را دریافت کنید نه X2 فیلد ورودی NR داده شده
شناسه سلولی

سایر توابع رابط برای پشتیبانی از نقش ANR به عنوان مصرف کننده اندازه گیری UE وجود دارد.
همانطور که در زیر ذکر شده است:

·

AddUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) توسط ANR برای درخواست گزارش های اندازه گیری از
موجودیت eNodeB RRC، با عبور از پیکربندی گزارش مورد نظر. این
پیکربندی برای همه UE های پیوست آینده اعمال خواهد شد.

·

ReportUeMeas
(eNodeB RRC -> ANR) بر اساس اندازه‌گیری‌های UE که قبلاً در پیکربندی شده بود
AddUeMeasReportConfigForAnr، UE ممکن است گزارش های اندازه گیری را به eNodeB ارسال کند.
موجودیت eNodeB RRC از ReportUeMeas رابط برای ارسال این
گزارش های اندازه گیری به ANR

لطفاً به اسناد API مربوطه مراجعه کنید LteAnrSap کلاس برای جزئیات بیشتر
در مورد استفاده و پارامترهای مورد نیاز

ANR توسط نمونه eNodeB RRC به عنوان یک ساختار داده برای پیگیری
وضعیت سلولهای همسایه مجاور. ANR همچنین به نمونه ENODEB RRC کمک می کند
تعیین اینکه آیا امکان اجرای یک رویه تحویل به سلول همسایه وجود دارد یا خیر.
این امر با این واقعیت قابل درک است که eNodeB RRC فقط به یک رویه انتقال اجازه می دهد
اگر ورودی NR سلول هدف هر دو را داشته باشد اتفاق می افتد نه HO و نه X2 فیلدها به غلط.

ANR به طور پیش فرض در هر نمونه eNodeB در شبیه سازی فعال است. می توان آن را غیر فعال کرد
با تنظیم AnrEnabled ویژگی در LteHelper کلاس به غلط.

RRC دنباله نمودارها
در این بخش ما تعدادی نمودار توالی ارائه می کنیم که مهمترین RRC را توضیح می دهد
رویه های در حال مدل سازی

RRC ارتباط استقرار
شکل دنباله نمودار of la RRC اتصال استقرار روش نشان می دهد که چگونه RRC
رویه ایجاد اتصال مدل‌سازی می‌شود و نقش لایه RRC را برجسته می‌کند
هر دو UE و eNB، و همچنین تعامل با لایه های دیگر.
[تصویر] نمودار توالی رویه ایجاد اتصال RRC.UNINDENT

چندین تایم اوت مربوط به این روش وجود دارد که در ادامه فهرست شده است
جدول زمان سنج in RRC ارتباط استقرار روش. اگر هر یک از این تایمرها منقضی شده باشد،
روش برقراری اتصال RRC با شکست خاتمه می یابد. در این مورد،
لایه بالایی (UE NAS) بلافاصله تلاش می کند تا این روش را دوباره امتحان کند تا زمانی که کامل شود
با موفقیت.

زمان سنج in RRC ارتباط استقرار روش
┌───────────────┬─ ─────┬─── ─────────────┬─────- ┐
│ نام │ مکان │ شروع تایمر │ توقف تایمر │ پیش فرض │ زمانی که تایمر │
│ │ │ │ │ مدت زمان │ منقضی شده │
├───────────────┼───── ─────┼─── ─────────────┼──────── ┤
│اتصال │ eNodeB RRC │ زمینه UE جدید │ دریافت RRC │ 15 میلی ثانیه │ حذف UE │
│درخواست │ │ اضافه شده │ اتصال │ │ زمینه │
│تایم اوت │ │ │ درخواست │ │ │
├───────────────┼───── ─────┼─── ─────────────┼──────── ┤
│اتصال │ UE RRC │ ارسال RRC │ دریافت RRC │ 100 میلی ثانیه │ بازنشانی UE MAC │
│تایم اوت (T300 │ │ CONNECTION │ CONNECTION │ │ │
│تایمر) │ │ درخواست │ راه اندازی یا │ │ │
│ │ │ │ رد │ │ │
├───────────────┼───── ─────┼─── ─────────────┼──────── ┤
│اتصال │ eNodeB RRC │ ارسال RRC │ دریافت RRC │ 100 میلی ثانیه │ حذف UE │
│موقعیت راه اندازی │ │ اتصال │ اتصال │ │ زمینه │
│ │ │ راه اندازی │ راه اندازی کامل │ │ │
├───────────────┼───── ─────┼─── ─────────────┼──────── ┤
│اتصال │ eNodeB RRC │ ارسال RRC │ هرگز │ 30 ms │ حذف UE │
│ رد شد │ │ اتصال │ │ │ زمینه │
│تایم اوت │ │ رد │ │ │ │
└───────────────┴──- ─────┴─── ─────────────┴──────- ┘

RRC ارتباط راه اندازی مجدد
شکل دنباله نمودار of la RRC اتصال تنظیم مجدد روش نشان می دهد که چگونه RRC
روش پیکربندی مجدد اتصال برای موردی که MobilityControlInfo است مدل شده است
ارائه نشده است، یعنی تحویل انجام نمی شود.
[تصویر] نمودار توالی رویه پیکربندی مجدد اتصال RRC.UNINDENT

شکل دنباله نمودار of la RRC اتصال تنظیم مجدد روش برای la تحویل دادن
مورد نشان می دهد که چگونه روش پیکربندی مجدد اتصال RRC برای مورد مدل سازی شده است
جایی که MobilityControlInfo ارائه شده است، یعنی انتقال باید انجام شود. همانطور که مشخص شد
در [TS36331] ، پس از دریافت la تحویل دادن پیام ، la UE تلاش به دسترسی la هدف
سلول at la اول در دسترس RACH فرصت مطابق به تصادفی دسترسی منابع انتخاب
مشخص in [TS36321]_، به عنوان مثال la تحویل دادن is نامتقارن. در نتیجه، چه زمانی تخصیص دادن
a اختصاصی مقدمه برای la تصادفی دسترسی in la هدف سلول، E-UTRA باید اطمینان حاصل شود it is
در دسترس از جانب la اول RACH فرصت la UE ممکن است استفاده کنید. بر موفق اتمام of la
تحویل دادن، la UE می فرستد a پیام استفاده به تایید la تحویل دادن. توجه داشته باشید که تصادفی است
رویه دسترسی در این مورد مبتنی بر غیر مناقشه است، از این رو در یک سیستم LTE واقعی آن است
کمی با مورد استفاده شده در اتصال RRC ایجاد شده متفاوت است. همچنین توجه داشته باشید که RA
شناسه مقدمه از طریق فرمان Handover موجود در درخواست تحویل X2 علامت‌گذاری می‌شود.
پیام ACK ارسال شده از eNB هدف به منبع eNB. به ویژه، مقدمه است
موجود در IE RACH-ConfigDedicated که بخشی از MobilityControlInfo است.
[تصویر] نمودار توالی روند پیکربندی مجدد اتصال RRC برای
مورد تحویل.UNINDENT

RRC پروتکل مدل
همانطور که قبلاً پیش بینی شده بود، ما دو مدل مختلف برای انتقال و
دریافت پیام های RRC: ایده آل و واقعی. هر یک از آنها در یکی از شرح داده شده است
زیر بخش های زیر

ایده آل RRC پروتکل مدل
بر اساس این مدل در کلاس ها و LteUeRrcProtocolIdeal و
LteEnbRrcProtocolIdeal، تمام پیام های RRC و عناصر اطلاعاتی بین آنها منتقل می شود
eNB و UE به شیوه ای ایده آل، بدون مصرف منابع رادیویی و بدون
خطاها از نقطه نظر پیاده سازی، این با ارسال داده های RRC به دست می آید
ساختار مستقیماً بین نهادهای UE و eNB RRC، بدون درگیر کردن لایه‌های پایین‌تر
(PDCP، RLC، MAC، زمانبندی).

واقعی RRC پروتکل مدل
این مدل در کلاس ها پیاده سازی می شود LteUeRrcProtocolReal و LteEnbRrcProtocolReal
و هدف آن مدل سازی انتقال PDU های RRC به طور معمول در LTE واقعی است
سیستم های. به خصوص:

· برای هر پیام RRC ارسالی، یک PDU RRC واقعی به دنبال ASN.1 ایجاد می شود
رمزگذاری PDU های RRC و عناصر اطلاعاتی (IE) مشخص شده در [TS36331]. مقداری
ساده سازی با توجه به IE های موجود در PDU انجام می شود، یعنی فقط آنها
IE هایی که برای اهداف شبیه سازی مفید هستند گنجانده شده اند. برای لیست دقیق لطفا
IE های تعریف شده را ببینید lte-rrc-sap.h و با [TS36331] مقایسه کنید.

· PDU های RRC رمزگذاری شده روی حامل های رادیویی سیگنالینگ ارسال می شوند و مشمول همان هستند
مدل سازی انتقال برای ارتباطات داده استفاده می شود، بنابراین شامل برنامه ریزی، رادیو
مصرف منابع، خطاهای کانال، تاخیر، ارسال مجدد و غیره.

سیگنالینگ رادیو باربر مدل
ما اکنون مدل حامل رادیو سیگنالینگ را که برای واقعی پروتکل RRC
مدل.

· SRB0 پیام ها (از طریق CCCH):

· RrcConnectionRequest: در سیستم های LTE واقعی، این یک RLC TM SDU است که ارسال می شود
منابع مشخص شده در UL Grant در RAR (نه در UL DCIs)؛ دلیل این است که
C-RNTI هنوز در این مرحله شناخته نشده است. در شبیه ساز، این به صورت واقعی مدل شده است
RLC TM RLC PDU که منابع UL آن توسط برنامه زمانبندی شده پس از تماس به تخصیص داده می شود
SCHED_DL_RACH_INFO_REQ.

· RrcConnectionSetup: در شبیه ساز این مانند در سیستم های LTE واقعی پیاده سازی شده است،
به عنوان مثال، با یک RLC TM SDU ارسال شده از طریق منابع نشان داده شده توسط یک UL DCI معمولی،
اختصاص داده شده با SCHED_DL_RLC_BUFFER_REQ توسط نمونه RLC TM که
به LCID 0 (CCCH) نگاشت شده است.

· SRB1 پیام ها (از طریق DCCH):

· تمام پیام های SRB1 مدل سازی شده در شبیه ساز (به عنوان مثال، RrcConnection تکمیل شد) هستند
مانند سیستم های LTE واقعی، یعنی با یک RLC SDU واقعی که از طریق RLC AM ارسال می شود، پیاده سازی می شود
با استفاده از منابع DL تخصیص یافته از طریق گزارش وضعیت بافر. مدل RLC را ببینید
اسناد برای جزئیات

· SRB2 پیام ها (از طریق DCCH):

· طبق [TS36331]، "SRB1 is برای RRC پیام (که ممکن است شامل a
کمربند ایمنی NAS پیام) as خوب as برای NAS پیام قبلی به la استقرار
of SRB2، تمام با استفاده از DCCH منطقی کانال"، در حالیکه "SRB2 is برای NAS پیام ها،
با استفاده از DCCH منطقی کانال"و"SRB2 است a با اولویت پایین تر نسبت به SRB1 و is
همیشه پیکربندی by E-UTRAN بعد از تیم امنیت لاتاری فعال سازی". مدل سازی
جنبه های مربوط به امنیت یک الزام مدل شبیه سازی LTE نیست،
از این رو ما همیشه از SRB1 استفاده می کنیم و هرگز SRB2 را فعال نمی کنیم.

ASN.1 پشتیبانی می کند of RRC IE
پیام های تعریف شده در RRC SAP، مشترک برای همه کاربران/ارائه دهندگان Ue/Enb SAP، منتقل می شوند.
در یک ظرف شفاف به/از Ue/Enb. فرمت رمزگذاری برای متفاوت
عناصر اطلاعات در [TS36331]، با استفاده از قوانین ASN.1 در غیر تراز مشخص شده اند.
گونه. پیاده سازی در Ns3/Lte به کلاس های زیر تقسیم شده است:

· Asn1Header: شامل رمزگذاری / رمزگشایی انواع ASN اساسی است

· RrcAsn1Header: Asn1Header را به ارث می برد و حاوی رمزگذاری / رمزگشایی مشترک است
IE در [TS36331] تعریف شده است

· کلاس های پیام های خاص / IEs Rrc: یک کلاس برای هر یک از پیام های تعریف شده در RRC
هدر SAP

Asn1Header کلاس - پیاده سازی of پایه ASN.1 انواع
این کلاس متدهایی را برای Serialize / Deserialize انواع ASN.1 که در آنها استفاده می شود پیاده سازی می کند
[TS36331]، با توجه به قوانین رمزگذاری بسته بندی شده در ITU-T X.691. انواع در نظر گرفته شده
هستند:

· Boolean: یک مقدار بولی از یک بیت استفاده می کند (1=true، 0=false).

· عدد صحیح: یک عدد صحیح محدود (با مقادیر حداقل و حداکثر تعریف شده) از حداقل استفاده می کند
مقدار بیت برای رمزگذاری محدوده آن (حداکثر-min+1).

· Bitstring: یک bistring ذره ذره در بافر سریال سازی کپی می شود.

· Octetstring: در حال حاضر استفاده نمی شود.

· Sequence : دنباله مقدمه ای را ایجاد می کند که حضور اختیاری و را نشان می دهد
فیلدهای پیش فرض همچنین مقداری اضافه می کند که نشانگر وجود نشانگر پسوند را نشان می دهد.

· Sequence...Of: دنباله...از نوع تعداد عناصر دنباله را رمزگذاری می کند.
به عنوان یک عدد صحیح (عناصر بعدی باید پس از آن کدگذاری شوند).

· Choice : نشان می دهد که کدام عنصر از میان عناصر مجموعه انتخابی در حال کدگذاری است.

· Enumeration : به صورت یک عدد صحیح سریالی می شود که نشان می دهد کدام مقدار در بین مقادیر استفاده شده است
آنهایی که در شمارش هستند، با تعداد عناصر در شمارش بالا
مقید

· تهی: مقدار null کدگذاری نشده است، اگرچه تابع سریال سازی آن تعریف شده است
برای ارائه یک نقشه واضح تر بین مشخصات و پیاده سازی.

کلاس از ns-3 Header ارث می برد، اما تابع Deserialize() مجازی خالص اعلام می شود.
بنابراین کلاسهای ارثی مجبور به اجرای آن هستند. دلیل این امر این است که دفع کننده اراده خواهد شد
عناصر موجود در پیام های RRC را که هر کدام حاوی اطلاعات متفاوتی هستند، بازیابی کنید
عناصر.

علاوه بر این، باید توجه داشت که طول بایت حاصل از یک نوع/پیام خاص است
با توجه به وجود فیلدهای اختیاری و به دلیل رمزگذاری بهینه شده، می تواند متفاوت باشد.
از این رو، بیت های سریال شده با استفاده از تابع PreSerialize () پردازش می شوند، و ذخیره می شود
منجر به m_serialization Result Buffer می شود. همانطور که روش های خواندن/نوشتن در بافر ns3 هستند
بر اساس بایت تعریف شده است، بیت های سریال سازی در m_serializationPendingBits ذخیره می شوند.
ویژگی، تا زمانی که 8 بیت تنظیم شود و بتوان آن را در تکرار کننده بافر نوشت. بالاخره کی
با فراخوانی Serialize()، محتویات ویژگی m_serializationResult کپی می شود
به بافر:: پارامتر تکرار کننده

RrcAsn1Header : مشترک IEs
از آنجایی که برخی از عناصر اطلاعاتی برای چندین پیام RRC استفاده می شوند، این کلاس
IE های رایج زیر را پیاده سازی می کند:

· SrbToAddModList

· DrbToAddModList

· LogicalChannelConfig

· radioresourceconfigdeded

· PhysicalConfigDedicated

· SystemInformationBlockType1

· SystemInformationBlockType2

· RadioResourceConfigCommonSIB

Rrc خاص پیام ها / IE کلاس ها
RRC SAP زیر اجرا شده است:

· RrcConnectionRequest

· rrcConnectionSetup

· RrcConnectionSetupCompleted

RrcConnectionReconfiguration

· RrcConnectionReconfigurationCompleted

· اطلاعات آماده سازی تحویل

· RrcConnectionReestablishmentRequest

· RrcConnectionReestablishment

· RrcConnectionReestablishmentComplete

· RrcConnectionReestablishmentReject

· RrcConnectionRelease

NAS
تمرکز مدل LTE-EPC روی حالت NAS Active است که با EMM مطابقت دارد
ثبت شده، ECM متصل و RRC متصل است. به همین دلیل، موارد زیر
ساده سازی ها انجام می شود:

· EMM و ECM به صراحت مدل نشده اند. در عوض، نهاد NAS در UE خواهد شد
برای انجام اقداماتی که معادل (با ناخالص) هستند، مستقیماً با MME تعامل کنید
ساده سازی ها) برای بردن UE به حالت های EMM Connected و ECM Connected.

· NAS همچنین از مالتی پلکس کردن بسته های داده uplink که از بالا می آیند مراقبت می کند
با استفاده از طبقه‌بندی کننده الگوی جریان ترافیک، در حامل EPS مناسب قرار می‌گیرد
(TftClassifier).

· NAS از انتخاب PLMN و CSG پشتیبانی نمی کند

· NAS از هیچ روش به روز رسانی/ صفحه بندی مکان در حالت بیکار پشتیبانی نمی کند

شکل دنباله نمودار of la ضمیمه کردن روش نشان می دهد که چگونه مدل NAS ساده شده است
روال پیوست را اجرا می کند. توجه داشته باشید که هم EPS پیش‌فرض و هم EPS اختصاصی نهایی
حامل ها به عنوان بخشی از این رویه فعال می شوند.
[تصویر] نمودار توالی فرآیند پیوست.UNINDENT

S1
S1-U
رابط S1-U به روشی واقع گرایانه با کپسوله کردن بسته های داده مدل سازی شده است
GTP/UDP/IP، همانطور که در سیستم های LTE-EPC واقعی انجام می شود. پشته پروتکل مربوطه در نشان داده شده است
شکل LTE-EPC داده ها هواپیما پروتکل پشته. همانطور که در شکل نشان داده شده است، دو تفاوت وجود دارد
لایه های شبکه IP اولین لایه، لایه انتها به انتها است که پایان به انتها را ارائه می دهد
اتصال به کاربران؛ این لایه ها شامل UE ها، PGW و میزبان راه دور است
(شامل روترهای اینترنتی و هاست های احتمالی در بین آنها)، اما eNB را شامل نمی شود.
به طور پیش فرض، UE ها یک آدرس IPv4 عمومی در شبکه 7.0.0.0/8 و PGW اختصاص داده می شوند.
آدرس 7.0.0.1 را دریافت می کند که توسط همه UE ها به عنوان دروازه دسترسی به اینترنت استفاده می شود.

لایه دوم شبکه IP، شبکه محلی EPC است. این شامل تمام eNB می شود
گره ها و گره SGW/PGW. این شبکه به صورت مجموعه ای از پیوندهای نقطه به نقطه پیاده سازی می شود
که هر eNB را با گره SGW/PGW متصل می کند. بنابراین، SGW/PGW دارای مجموعه ای از
دستگاه های نقطه به نقطه، که هر کدام به یک eNB متفاوت متصل می شوند. به طور پیش فرض، الف
زیرشبکه 10.x.y.z/30 به هر پیوند نقطه به نقطه اختصاص داده شده است (یک زیرشبکه /30 کوچکترین است
زیر شبکه ای که امکان دو آدرس میزبان مجزا را فراهم می کند).

همانطور که توسط 3GPP مشخص شده است، ارتباطات IP سرتاسر روی IP EPC محلی تونل می شود.
شبکه با استفاده از GTP/UDP/IP. در ادامه نحوه اجرای این تونل را توضیح می دهیم
در مدل EPC توضیح با بحث در مورد جریان سرتاسر داده ها انجام می شود
بسته ها
[تصویر] جریان داده در لینک پایین بین اینترنت و UE.UNINDENT

برای شروع، مورد downlink را در نظر می گیریم که در شکل نشان داده شده است داده ها
جریان in la downlink میان la اینترنت و la UE. بسته های Downlink Ipv4 هستند
از یک میزبان راه دور عمومی تولید شده و به یکی از دستگاه های UE آدرس داده می شود. اینترنت
مسیریابی از ارسال بسته به NetDevice عمومی SGW/PGW مراقبت می کند.
گره ای که به اینترنت متصل است (این رابط Gi طبق 3GPP است
واژه شناسی). SGW/PGW دارای یک VirtualNetDevice است که IP دروازه به آن اختصاص داده شده است
آدرس زیرشبکه UE؛ از این رو، قوانین مسیریابی استاتیک باعث ایجاد بسته ورودی می شود
از اینترنت برای هدایت از طریق این VirtualNetDevice. چنین دستگاهی راه اندازی می شود
روش تونل زنی GTP/UDP/IP، با ارسال بسته به یک برنامه اختصاصی در
گره SGW/PGW که EpcSgwPgwApplication نامیده می شود. این نرم افزار این کار را انجام می دهد
عملیات زیر:

1. با نگاه کردن به IP، گره eNB را که UE به آن متصل است، تعیین می کند
آدرس مقصد (که آدرس UE است)؛

2. بسته را با استفاده از Traffic Flow Templates (TFT) طبقه بندی می کند تا مشخص کند که کدام یک
حامل EPS متعلق به آن است. حامل های EPS یک نگاشت یک به یک با حامل های S1-U دارند، بنابراین
این عملیات شناسه نقطه پایانی تونل GTP-U (TEID) را برمی گرداند
بسته متعلق به

3. هدر پروتکل GTP-U مربوطه را به بسته اضافه می کند.

4. در نهایت، بسته را از طریق یک سوکت UDP به نقطه به نقطه S1-U می فرستد.
NetDevice، خطاب به eNB که UE به آن متصل است.

در نتیجه، بسته IP سرتاسری با هدرهای IP، UDP و GTP جدید اضافه شده است.
از طریق یکی از پیوندهای S1 به eNB ارسال می شود، جایی که به صورت محلی دریافت و تحویل می شود
(از آنجایی که آدرس مقصد هدر IP با آدرس IP eNB مطابقت دارد). این
فرآیند تحویل محلی، بسته را از طریق یک سوکت UDP به یک منبع اختصاصی ارسال می کند
برنامه ای به نام EpcEnbApplication. سپس این برنامه موارد زیر را انجام می دهد
عملیات:

1. هدر GTP را حذف می کند و TEID موجود در آن را بازیابی می کند.

2. استفاده از اهرم نقشه برداری یک به یک بین حامل های S1-U و حامل های رادیویی (که
یک الزام 3GPP است)، شناسه حامل (BID) که بسته به آن بسته می شود را تعیین می کند
متعلق است؛

3. BID را در یک تگ اختصاصی به نام EpsBearerTag ثبت می کند که به آن اضافه می شود.
بسته؛

4. بسته را از طریق یک بسته خام به LteEnbNetDevice گره eNB ارسال می کند.
پریز

توجه داشته باشید که در این مرحله، بیرونی ترین هدر بسته، سرآیند IP سرتاسر است.
از آنجایی که هدرهای IP/UDP/GTP پشته پروتکل S1 قبلاً حذف شده است. بر
با دریافت بسته از EpcEnbApplication، LteEnbNetDevice آن را بازیابی می کند.
BID از EpsBearerTag، و بر اساس BID، نمونه Radio Bearer را تعیین می کند.
(و نمونه های پروتکل PDCP و RLC مربوطه) که سپس برای ارسال استفاده می شود
بسته به UE از طریق رابط رادیویی LTE. در نهایت، LteUeNetDevice از UE خواهد شد
بسته را دریافت کنید و آن را به صورت محلی به پشته پروتکل IP تحویل دهید، که به نوبه خود انجام می شود
آن را به برنامه UE تحویل دهید، که نقطه پایانی لینک پایین است
ارتباطی است.
[تصویر] جریان داده در لینک بالا بین UE و اینترنت.UNINDENT

مورد uplink در شکل نشان داده شده است داده ها جریان in la پیوند میان la UE و
la اینترنت. بسته های IP Uplink توسط یک برنامه عمومی در داخل UE تولید می شوند.
و توسط پشته TCP/IP محلی به LteUeNetDevice UE ارسال می شود. را
LteUeNetDevice سپس عملیات زیر را انجام می دهد:

1. بسته را با استفاده از TFT طبقه بندی می کند و حامل رادیویی را تعیین می کند
بسته متعلق است (و RBID مربوطه)؛

2. نمونه پروتکل PDCP مربوطه را که نقطه ورود است، شناسایی می کند
پشته پروتکل رادیویی LTE برای این بسته.

3. بسته را از طریق پشته پروتکل رادیویی LTE به eNB می فرستد.

eNB بسته را از طریق LteEnbNetDevice خود دریافت می کند. از آنجایی که یک PDCP و RLC واحد وجود دارد
نمونه پروتکل برای هر حامل رادیویی، LteEnbNetDevice قادر است BID را تعیین کند.
از بسته این BID سپس بر روی یک EpsBearerTag ثبت می شود که به آن اضافه می شود
بسته سپس LteEnbNetDevice بسته را از طریق یک خام به EpcEnbApplication ارسال می کند.
سوکت بسته

پس از دریافت بسته، EpcEnbApplication عملیات زیر را انجام می دهد:

1. BID را از EpsBearerTag در بسته بازیابی می کند.

2. نمونه EPS Bearer و GTP-U TEID مربوطه را با اعمال اهرم بر روی تعیین می کند.
نقشه برداری یک به یک بین حامل های S1-U و حامل های رادیویی.

3. یک هدر GTP-U بر روی بسته اضافه می کند، از جمله TEID که قبلا تعیین شده است.

4. بسته را از طریق سوکت UDP متصل به S1-U به گره SGW/PGW ارسال می کند.
دستگاه شبکه نقطه به نقطه

در این مرحله، بسته علاوه بر هدرهای IP، UDP و GTP S1-U را شامل می شود
هدر IP سرتاسر اصلی. هنگامی که بسته توسط S1-U مربوطه دریافت می شود
NetDevice نقطه به نقطه گره SGW/PGW، به صورت محلی تحویل داده می شود (به عنوان مقصد
آدرس بیرونی ترین هدر IP با آدرس دستگاه شبکه نقطه به نقطه مطابقت دارد).
فرآیند تحویل محلی بسته را از طریق برنامه به EpcSgwPgwApplication ارسال می کند
سوکت UDP را تحریک کنید. سپس EpcSgwPgwApplication هدر GTP را حذف کرده و آن را فوروارد می کند
بسته به VirtualNetDevice. در این مرحله، بیرونی‌ترین هدر بسته عبارت است از
هدر IP سرتاسر. بنابراین، اگر آدرس مقصد در این هدر یک راه دور باشد
میزبان در اینترنت، بسته از طریق NetDevice مربوطه به اینترنت ارسال می شود
از SGW/PGW. در صورتی که بسته به UE دیگری آدرس داده شود، پشته IP از
SGW/PGW بسته را دوباره به VirtualNetDevice هدایت می کند و بسته می رود
از طریق فرآیند تحویل dowlink به منظور رسیدن به مقصد UE.

توجه داشته باشید که EPS Bearer QoS بر روی پیوندهای S1-U اعمال نمی شود، فرض بر این است که
تامین بیش از حد پهنای باند پیوند برای برآوردن نیازهای QoS همه کافی است
حاملان

S1AP
رابط S1-AP تعامل سطح کنترل بین eNB و MME را فراهم می کند. در
شبیه ساز، این رابط به روش ایده آل، با تعامل مستقیم بین مدل سازی شده است
اشیاء eNB و MME، بدون اجرای رمزگذاری پیام های S1AP
و عناصر اطلاعاتی مشخص شده در [TS36413] و در واقع بدون انتقال هیچ PDU
در هر لینک

S1-AP اولیه که مدل شده اند عبارتند از:

· پیام UE اولیه

· درخواست راه اندازی زمینه اولیه

· پاسخ راه اندازی متن اولیه

· درخواست سوئیچ مسیر

· درخواست سوئیچ مسیر

X2
رابط X2 دو eNB [TS36420] را به هم متصل می کند. از نقطه نظر منطقی، X2
رابط یک رابط نقطه به نقطه بین دو eNB است. در یک E-UTRAN واقعی،
رابط نقطه به نقطه منطقی باید حتی در غیاب فیزیکی قابل اجرا باشد
ارتباط مستقیم بین دو eNB در مدل X2 پیاده سازی شده در شبیه ساز،
رابط X2 یک پیوند نقطه به نقطه بین دو eNB است. دستگاه نقطه به نقطه است
ایجاد شده در هر دو eNB و دو دستگاه نقطه به نقطه به نقطه به نقطه متصل هستند
لینک کنید.

برای نمایش نحوه قرارگیری رابط X2 در معماری کلی LENA
مدل شبیه سازی، خواننده به شکل ارجاع داده شده است بررسی اجمالی of la LTE-EPC شبیه سازی
مدل.

رابط X2 پیاده سازی شده در شبیه ساز پیاده سازی دقیقی از
رویه‌های ابتدایی عملکرد مدیریت تحرک [TS36423]:

· روش درخواست تحویل

· رویه تأیید درخواست تحویل

· روش انتقال وضعیت SN

· روش انتشار متن UE

این رویه ها در تحویل مبتنی بر X2 دخیل هستند. می توانید جزئیات را پیدا کنید
شرح واگذاری در بخش 10.1.2.1 [TS36300]. ما توجه داشته باشید که شبیه ساز
مدل در حال حاضر فقط از بدون درز تحویل دادن همانطور که در بخش 2.6.3.1 تعریف شده است
[Sesia2009]; به خصوص، با فشرده سازی lossless تحویل دادن همانطور که در بخش 2.6.3.2 توضیح داده شده است
[Sesia2009] در زمان نگارش این مقاله پشتیبانی نمی‌شود.

شکل دنباله نمودار of la مبتنی بر X2 تحویل دادن در زیر تعامل
موجودیت های مدل X2 در شبیه ساز. برچسب های سایه دار نشان دهنده لحظاتی هستند که
انتقال UE یا eNodeB به حالت RRC دیگر.
[تصویر] نمودار توالی تحویل مبتنی بر X2.UNINDENT

شکل همچنین دو تایمر در فرآیند تحویل را نشان می دهد: تحویل دادن ترک
زمان سنج توسط منبع eNodeB نگهداری می شود، در حالی که تحویل دادن پیوستن زمان سنج توسط هدف
eNodeB. مدت زمان تایمرها را می توان در پیکربندی کرد
HandoverLeavingTimeoutDuration و HandoverJiningTimeoutDuration ویژگی های
قابل احترام LteEnbrRrc نمونه ها هنگامی که یکی از این تایمرها منقضی می شود، روش تحویل
شکست خورده محسوب می شود.

با این حال، در نسخه فعلی LTE مدیریت صحیحی برای خرابی انتقال وجود ندارد
مدول. کاربران باید شبیه سازی را به درستی تنظیم کنند تا از شکست تحویل جلوگیری شود.
در غیر این صورت ممکن است رفتار غیرمنتظره ای رخ دهد. لطفا به بخش مراجعه کنید
SEC-TUNING-HANDOVER SIMULATION از مستندات کاربر برای برخی از نکات در مورد این
موضوع.

مدل X2 موجودی است که از خدمات زیر استفاده می کند:

· رابط های X2،

· آنها به عنوان سوکت در بالای دستگاه های نقطه به نقطه اجرا می شوند.

· آنها برای ارسال/دریافت پیام های X2 از طریق رابط های X2-C و X2-U استفاده می شوند
(یعنی دستگاه نقطه به نقطه متصل به پیوند نقطه به نقطه) به سمت
همتا eNB.

· برنامه S1.

· در حال حاضر، EpcEnbApplication است.

· برای به دست آوردن برخی از اطلاعات مورد نیاز برای رویه های ابتدایی X2 استفاده می شود
پیام ها.

و خدماتی را ارائه می دهد:

· نهاد RRC (X2 SAP)

· برای ارسال/دریافت پیام های RRC. موجودیت X2 پیام RRC را به صورت شفاف ارسال می کند
ظرف در پیام X2. این پیام RRC به UE ارسال می شود.

شکل پیاده سازی مدل of X2 موجودیت و SAP ها مدل پیاده سازی X2 را نشان می دهد
موجودیت و ارتباط آن با سایر نهادها و خدمات موجود در پروتکل
پشته.
[تصویر] مدل پیاده‌سازی موجودیت X2 و SAPs.UNINDENT

نهاد RRC شروع روند تحویل را مدیریت می کند. این کار در
زیرماژول مدیریت واگذاری موجودیت eNB RRC. eNB هدف ممکن است برخی از عملکردها را انجام دهد
رویه های کنترل پذیرش این در زیر ماژول کنترل پذیرش انجام می شود.
در ابتدا، این زیر ماژول هرگونه درخواست تحویل را می پذیرد.

X2 رابط
مدل X2 دارای دو رابط است:

· رابط X2-C. این رابط کنترل است و برای ارسال PDU های X2-AP استفاده می شود
(یعنی رویه های ابتدایی).

· رابط X2-U. برای ارسال داده های حامل در صورت وجود استفاده می شود DL حمل و نقل.

شکل X2 رابط پروتکل پشته پشته های پروتکل رابط X2-U را نشان می دهد و
رابط X2-C در شبیه ساز مدل شده است.
[تصویر] پشته پروتکل رابط X2.UNINDENT

X2-C
رابط X2-C بخش کنترل رابط X2 است و برای ارسال استفاده می شود
PDU های X2-AP (یعنی رویه های ابتدایی).

در پشته پروتکل صفحه کنترل رابط X2 اصلی، SCTP به عنوان انتقال استفاده می شود
پروتکل اما در حال حاضر، پروتکل SCTP در شبیه ساز ns-3 و آن مدل سازی نشده است
اجرا خارج از محدوده پروژه است. پروتکل UDP به عنوان دیتاگرام استفاده می شود
پروتکل گرا به جای پروتکل SCTP.

X2-U
رابط X2-U برای ارسال داده های حامل در صورت وجود استفاده می شود DL حمل و نقل در طول
اجرای رویه تحویل مبتنی بر X2. مشابه کاری که برای S1-U انجام شد
رابط، بسته های داده در هنگام ارسال از طریق GTP/UDP/IP کپسوله می شوند
رابط. توجه داشته باشید که EPS Bearer QoS در پیوندهای X2-U اعمال نمی شود، فرض می شود
که تامین بیش از حد پهنای باند پیوند برای برآوردن الزامات QoS کافی است
از همه حاملان

X2 محصولات رابط
رابط سرویس X2 توسط نهاد RRC برای ارسال و دریافت پیام های X2 استفاده می شود
رویه ها به دو بخش تقسیم می شود:

· EpcX2SapProvider بخش توسط نهاد X2 ارائه شده و توسط نهاد RRC و استفاده می شود

· EpcX2SapUser بخش توسط نهاد RRC ارائه شده و توسط موجودیت RRC استفاده می شود.

اولیه هایی که در مدل X2-C ما پشتیبانی می شوند در ادامه توضیح داده شده اند
زیر بخش ها

X2-C بدوی برای تحویل دادن اعدام
اولیه های زیر برای انتقال مبتنی بر X2 استفاده می شوند:

· درخواست تحویل

· تحویل درخواست ACK

· شکست آماده سازی تحویل

· SN STATUS STRANSFER

· UE CONTEXT RELEASE

تمام اولیه های فوق توسط مدل RRC در حال حاضر پیاده سازی شده در طول دوره استفاده می شوند
آماده سازی و اجرای روش واگذاری. استفاده از آنها با RRC در تعامل است
ماشین حالت؛ بنابراین، حداقل برای سفارشی سازی کد مورد استفاده قرار نمی گیرند
مگر اینکه بخواهیم ماشین حالت RRC را اصلاح کنیم.

X2-C SON بدوی
از ابتدایی های زیر می توان برای پیاده سازی شبکه خودسازماندهی (SON) استفاده کرد.
قابلیت ها:

· بارگذاری اطلاعات

· به روز رسانی وضعیت منابع

توجه داشته باشید که مدل RRC فعلی در واقع از این موارد اولیه استفاده نمی کند، آنها شامل می شوند
در مدل فقط برای ایجاد امکان توسعه الگوریتم های SON موجود در منطق RRC
که از آنها استفاده می کنند.

به عنوان اولین مثال، در اینجا نشان می‌دهیم که چگونه می‌توان از اطلاعات بار اولیه استفاده کرد. فرض می کنیم
که LteEnbrRrc برای شامل متغیرهای عضو جدید زیر اصلاح شده است:

std::vector
m_currentUlInterferenceOverloadIndicationList;
std::vector
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

برای توضیح دقیق نوع این متغیرها پیشنهاد می کنیم به فایل مراجعه کنید
epc-x2-sap.h، مستندات داکسیژن مربوطه، و ارجاعات موجود در آن به
بخش های مربوطه 3GPP TS 36.423. حال، فرض کنید در زمان اجرا این متغیرها دارند
با توجه به مشخصات ذکر شده روی مقادیر معنی دار تنظیم شده است. پس شما می توانید
برای ارسال بار، کد زیر را در پیاده سازی کلاس LteEnbrRrc اضافه کنید
اطلاعات اولیه:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicationList = m_currentUlInterferenceOverloadIndicationList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams params;
params.targetCellId = cellId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (پارامز)؛

کد بالا به منبع eNB امکان ارسال پیام را می دهد. روش
LteEnbRrc::DoRecvLoadInformation هنگامی که ENB هدف پیام را دریافت می کند ، فراخوانی می شود.
بنابراین پردازش مورد نظر اطلاعات بار باید در آن اجرا شود
روش.

در مثال دوم زیر نشان می‌دهیم که چگونه از حالت اولیه به‌روزرسانی وضعیت منبع استفاده می‌شود.
ما فرض می کنیم که LteEnbrRrc برای شامل عضو جدید زیر تغییر یافته است
متغیر:

EpcX2Sap::CellMeasurementResultItem m_cmri;

مشابه قبل به آن اشاره می کنیم epc-x2-sap.h و ارجاعات موجود در آن به تفصیل
اطلاعات مربوط به این نوع متغیر مجدداً فرض می کنیم که متغیر قبلاً بوده است
روی یک مقدار معنادار تنظیم کنید. سپس می توانید کد زیر را برای ارسال یک اضافه کنید
به روز رسانی وضعیت منبع:

EpcX2Sap::ResourceStatusUpdateParams;
params.targetCellId = cellId;
params.cellMeasurementResultList.push_back (m_cmri);
m_x2SapProvider->SendResourceStatusUpdate (پارامز)؛

روش eEnbrRrc::DoRecvResourceStatusUpdate هنگامی که eNB هدف دریافت می شود، فراخوانی می شود
پیام به روز رسانی وضعیت منبع پردازش مورد نظر این پیام باید
بنابراین در آن روش پیاده سازی شود.

در نهایت، ما توجه می کنیم که تنظیم و پردازش مقادیر مناسب برای
متغیری که به ابتدایی های توصیف شده در بالا منتقل می شود، مختص SON در نظر گرفته می شود
الگوریتم در حال پیاده سازی است و از این رو تحت پوشش این مستندات نیست.

پشتیبانی نشده بدوی
Mobility Robustness Optimization اولیه مانند نشانگر خرابی پیوند رادیویی و
گزارش انتقال در این مرحله پشتیبانی نمی شود.

S11
رابط S11 تعامل سطح کنترل بین SGW و MME را با استفاده از
پروتکل GTPv2-C مشخص شده در [TS29274]. در شبیه ساز، این رابط در یک مدل سازی شده است
مد ایده آل، با تعامل مستقیم بین اشیاء SGW و MME، بدون
در واقع کدگذاری پیام ها را پیاده سازی می کند و در واقع هیچ کدام را ارسال نمی کند
PDU در هر لینک.

نمونه های اولیه S11 که مدل شده اند عبارتند از:

· ایجاد درخواست جلسه

· ایجاد پاسخ جلسه

· تغییر درخواست حامل

· اصلاح پاسخ حامل

از این موارد اولیه، دو مورد اول در پیوست اولیه UE برای
ایجاد حامل های S1-U؛ دو مورد دیگر در حین انتقال برای تعویض استفاده می شوند
حامل های S1-U از منبع eNB به eNB هدف در نتیجه دریافت توسط
MME یک پیام S1-AP درخواست سوئیچ مسیر.

قدرت کنترل
این بخش پیاده سازی ns-3 Downlink و Uplink Power Control را شرح می دهد.

پیوند پایین قدرت کنترل
از آنجایی که برخی از الگوریتم‌های استفاده مجدد از فرکانس به کنترل برق Downlink نیاز دارند، این ویژگی بود
همچنین در ns-3 پیاده سازی شده است.
[تصویر] نمودار توالی Downlink Power Control.UNINDENT

شکل دنباله نمودار of پیوند پایین قدرت کنترل نمودار توالی تنظیم را نشان می دهد
مقدار P_A downlink برای UE، که تعاملات بین RRC و دیگری را برجسته می کند
موجودیت ها. الگوریتم FR RRC را برای تغییر مقادیر P_A برای UE راه‌اندازی می‌کند. سپس RRC شروع می شود
تابع RrcConnectionReconfiguration برای اطلاع UE در مورد پیکربندی جدید. بعد از
با موفقیت RrcConnectionReconfiguration، RRC می تواند مقدار P_A را برای UE با فراخوانی تنظیم کند
تابع SetPa از CphySap، مقدار در نقشه جدید m_paMap که حاوی مقادیر P_A است ذخیره می شود.
برای هر UE ارائه شده توسط eNb.

هنگامی که LteEnbPhy فریم فریم جدید را راه اندازی می کند، پیام های کنترلی DCI برای بدست آوردن بردار پردازش می شوند.
RB های استفاده شده اکنون همچنین تابع GeneratePowerAllocationMap(uint16_t rnti, int rbId) نیز وجود دارد
تماس گرفت. این تابع مقدار P_A را برای UE بررسی می کند، برای هر RB برق تولید می کند و آن را در آن ذخیره می کند
m_dlPowerAlocationMap. سپس این نقشه توسط
برای ایجاد Ptr تابع CreateTxPowerSpectralDensityWithPowerAllocation
txPsd.

PdschConfigDedicated (TS 36.331، 6.3.2 PDSCH-Config) در اضافه شد
ساختار LteRrcSap::PhysicalConfigDedicated که در RrcConnectionReconfiguration استفاده می شود
روند.

بالا بردن قدرت کنترل
کنترل توان Uplink، توان انتقال فیزیکی uplink مختلف را کنترل می کند
کانال ها این عملکرد در بخش 3 36.213GPP TS 5 توضیح داده شده است.

Uplink Power Control به طور پیش فرض فعال است و می تواند توسط سیستم ویژگی غیرفعال شود:

پیکربندی::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl"، BooleanValue (نادرست));

دو مکانیزم کنترل توان Uplink پیاده سازی شده است:

· باز کردن حلقه Uplink Power Control: توان انتقال UE به تخمین بستگی دارد
مسیر از دست دادن لینک پایین و پیکربندی کانال

· کنترل برق Uplink حلقه بسته: مانند حلقه باز، علاوه بر این eNB می تواند UE را کنترل کند
قدرت انتقال با استفاده از دستورات صریح TPC کنترل توان انتقال
در لینک پایین منتقل می شود.

برای جابجایی بین این دو نوع مکانیزم، باید پارامتر را تغییر داد:

پیکربندی::SetDefault ("ns3::LteUePowerControl::ClosedLoop"، BooleanValue (true));

به طور پیش فرض، کنترل قدرت حلقه بسته فعال است.

دو حالت های of تعطیل حلقه بالا بردن قدرت کنترل هستند در دسترس:

· حالت مطلق: TxPower با مقادیر مطلق TPC محاسبه می شود

· حالت تجمعی: TxPower با مقادیر TPC انباشته شده محاسبه می شود

برای جابجایی بین این دو حالت، باید پارامتر را تغییر دهید:

پیکربندی::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled"، BooleanValue (true));

به طور پیش فرض، حالت تجمع فعال است و دستورات TPC در DL-DCI توسط همه تنظیم می شود.
زمان‌بندی‌ها به 1، چیزی که در حالت تجمع به مقدار 0 نگاشت شده است.

بالا بردن قدرت کنترل برای PUSCH
تنظیم توان انتقال UE برای یک کانال اشتراکی Uplink فیزیکی (PUSCH)
انتقال به صورت زیر تعریف می شود:

· اگر UE PUSCH را بدون یک PUCCH همزمان برای سلول سرویس c ارسال کند، سپس
توان انتقال UE P_{PUSCH,c}(i) برای انتقال PUSCH در زیرفریم i برای
خدمت سلول c توسط:

· اگر UE PUSCH را همزمان با PUCCH برای سلول سرویس دهنده c ارسال کند، UE
توان انتقال P_{PUSCH,c}(i) برای انتقال PUSCH در زیرفریم i برای
خدمت سلول c توسط:

از آنجایی که Uplink Power Control برای PUCCH اجرا نمی شود، این مورد اجرا نمی شود
نیز هست.

· اگر UE PUSCH را برای سلول سرویس دهنده c مخابره نمی کند، برای تجمع
دستور TPC دریافت شده با فرمت DCI 3/3A برای PUSCH، UE باید فرض کند که UE
توان انتقال P_{PUSCH,c}(i) برای انتقال PUSCH در زیرفریم i برای
خدمت سلول c توسط محاسبه می شود

که در آن:

· P_{CMAX,c}(i) قدرت انتقال UE پیکربندی شده است که در 3GPP 36.101 تعریف شده است. جدول
6.2.2-1 در زیرفراب i برای سرویس سلول c و {P}_{CMAX,c}(i) مقدار خطی است
از P_{CMAX,c}(i). مقدار پیش‌فرض برای P_{CMAX,c}(i) 23 dBm است

· M_{PUSCH,c}(i) پهنای باند تخصیص منبع PUSCH است که در
تعداد بلوک های منبع معتبر برای زیرفریم i و سلول سرویس c.

· P_{O_PUSCH,c}(j) پارامتری است که از مجموع یک جزء تشکیل شده است.
P_{O_NOMINAL_PUSCH,c}(j) از لایه‌های بالاتر برای j={0,1} و یک جزء ارائه شده است
P_{O_UE_PUSCH,c}(j) توسط لایه‌های بالاتر برای j={0,1} برای سرویس سلول c ارائه شده است.
پیام SIB2 باید برای حمل این دو مؤلفه گسترش یابد، اما در حال حاضر
آنها را می توان از طریق سیستم ویژگی تنظیم کرد:

پیکربندی::SetDefault ("ns3::LteUePowerControl::PoNominalPusch"، IntegerValue (-90));
پیکربندی::SetDefault ("ns3::LteUePowerControl::PoUePusch"، IntegerValue (7));

· lpha_{c} (j) یک پارامتر 3 بیتی است که توسط لایه های بالاتر برای ightinForelj=2 ارائه شده است،
برای j=0,1،0، lpha_c در t 0.4، 0.5، 0.6، 0.7، 0.8، 0.9، 1، XNUMX
lpha_{c} (j) = 1. این پارامتر توسط سیستم ویژگی قابل تنظیم است:

پیکربندی::SetDefault ("ns3::LteUePowerControl::Alpha"، DoubleValue (0.8));

· PL_{c} تخمین تلفات اتصال پایین است که در UE برای سرویس سلول c محاسبه شده است
در دسی بل و PL_{c} = referenceSignalPower - لایه بالاتر فیلتر شده RSRP، که در آن
referenceSignalPower توسط لایه های بالاتر و RSRP ارائه می شود. مرجع سیگنال پاور
در پیام SIB2 ارائه شده است

· و cond case اجرا می شود.

· f_{c}(i) جزء کنترل قدرت حلقه بسته است. این توان PUSCH فعلی است
کنترل وضعیت تنظیم برای سرویس سلول c.

اگر حالت تجمع فعال باشد f_{c}(i) توسط:

جایی که: elta_{PUSCH,c} یک مقدار تصحیح است که به آن دستور TPC نیز می‌گویند
و در PDCCH با DCI گنجانده شده است. elta_{PUSCH,c}(i - K_{PUSCH}) روشن شد
PDCCH/EPDCCH با DCI برای سرویس سلول c در زیر فریم (i - K_{PUSCH})؛ K_{PUSCH} =
4 برای FDD.

اگر UE برای سرویس سلول c به P_{CMAX,c}(i) رسیده باشد، دستورات TPC مثبت برای
در خدمت سلول c جمع نمی شوند. اگر UE به حداقل توان رسیده باشد، منفی است
دستورات TPC انباشته نمی شوند. حداقل توان UE در TS36.101 تعریف شده است
بخش 6.2.3. مقدار پیش فرض -40 dBm است.

اگر حالت تجمع فعال نباشد f_{c}(i) توسط:

جایی که: elta_{PUSCH,c} یک مقدار تصحیح است که به آن دستور TPC نیز می‌گویند
و در PDCCH با DCI گنجانده شده است. elta_{PUSCH,c}(i - K_{PUSCH}) روشن شد
PDCCH/EPDCCH با DCI برای سرویس سلول c در زیر فریم (i - K_{PUSCH})؛ K_{PUSCH} =
4 برای FDD.

نگاشت فیلد فرمان TPC در فرمت DCI 0/3/4 به مطلق و انباشته
مقادیر elta_{PUSCH,c} در TS36.231 بخش 5.1.1.1 جدول 5.1.1.1-2 تعریف شده است.

بالا بردن قدرت کنترل برای PUCCH
از آنجایی که تمام پیام های کنترل uplink یک پیام ایده آل هستند و هیچ رادیویی را مصرف نمی کنند
منابع، Uplink Power Control برای PUCCH مورد نیاز نیست و اجرا نمی شود.

بالا بردن قدرت کنترل برای SRS
تنظیم توان انتقال UE P_{SRS} برای SRS ارسال شده در زیرفریم i برای
خدمت سلول c با تعریف شده است

که در آن:

· P_{CMAX,c}(i) قدرت انتقال UE پیکربندی شده است که در 3GPP 36.101 تعریف شده است. جدول
6.2.2-1. مقدار پیش‌فرض برای P_{CMAX,c}(i) 23 dBm است

· P_{SRS_OFFSET,c}(m) به صورت نیمه استاتیک توسط لایه های بالاتر برای m=0,1 برای
سلول خدمت c . برای انتقال SRS نوع ماشه 0 و سپس m=0,1 و برای SRS داده شده است
انتقال داده شده ماشه نوع 1 سپس m=1. برای K_{s} = 0 P_Srs_Offset_Value است
محاسبه شده با معادله:

این پارامتر توسط سیستم ویژگی قابل تنظیم است:

پیکربندی::SetDefault ("ns3::LteUePowerControl::PsrsOffset"، IntegerValue (7));

· M_{SRS,c} پهنای باند انتقال SRS در زیرفریم i برای سرویس سلول است.
c به تعداد بلوک های منبع بیان می شود. در اجرای فعلی SRS ارسال می شود
در کل پهنای باند UL

· f_{c}(i) وضعیت فعلی تنظیم کنترل توان PUSCH برای سرویس سلول c است،
همانطور که در تعریف شده است بالا بردن قدرت کنترل برای PUSCH

· P_{O_PUSCH،c}(j) و lpha_{c}(j) پارامترهایی هستند که در بالا بردن قدرت
کنترل برای PUSCH، جایی که j = 1.

کسری فرکانس استفاده مجدد
بررسی اجمالی
این بخش پشتیبانی ns-3 برای الگوریتم‌های استفاده مجدد فرکانس کسری را توضیح می‌دهد. همه
الگوریتم های پیاده سازی شده در [ASHamza2013] توضیح داده شده اند. در حال حاضر 7 الگوریتم FR هستند
اجرا شده:

· ns3::الگوریتم LteFrNoOp

· ns3::الگوریتم LteFrHard

· ns3::الگوریتم LteFrStrict

· ns3::الگوریتم LteFrSoft

· NS3 :: LTEFFRSOFTALGORITHM

· ns3::الگوریتم LteFfrEnhanced

· ns3::الگوریتم LteFfrDistributed

کلاس جدید LteFfrAlgorithm ایجاد شد و یک کلاس انتزاعی برای استفاده مجدد از فرکانس است
پیاده سازی الگوریتم ها همچنین دو SAP جدید بین FR-Scheduler و FR-RRC اضافه شد.
[تصویر] نمودار توالی زمانبندی با الگوریتم FR.UNINDENT

شکل دنباله نمودار of زمان بندی با FR الگوریتم نمودار توالی را نشان می دهد
فرآیند زمان بندی با الگوریتم FR. در ابتدای فرآیند زمانبندی، زمانبندی
از نهاد FR RBG های موجود می خواهد. طبق پیاده سازی FR همه RBG ها را برمی گرداند
موجود در سلول یا آنها را بر اساس خط مشی آن فیلتر کنید. سپس هنگام تلاش برای اختصاص برخی
RBG به UE، زمان‌بند از موجودیت FR می‌پرسد که آیا این RBG برای این UE مجاز است یا خیر. وقتی FR برمی گردد
درست است، زمان‌بند می‌تواند این RBG را به این UE اختصاص دهد، اگر نه، زمان‌بند RBG دیگری را بررسی می‌کند
برای این UE. باز هم، پاسخ FR به اجرا و سیاست اعمال شده در UE بستگی دارد.

پشتیبانی FR الگوریتم
نه فرکانس استفاده مجدد
الگوریتم NoOp FR (کلاس LteFrNoOpAlgorithm) استفاده مجدد با فرکانس کامل را پیاده سازی می کند.
این به این معنی است که هیچ پارتیشن بندی فرکانسی بین eNB های یک شبکه انجام نمی شود
(ضریب استفاده مجدد فرکانس، FRF برابر با 1 است). eNB ها از کل پهنای باند سیستم و انتقال استفاده می کنند
با قدرت یکنواخت روی تمام RBG ها. این ساده ترین طرح است و راه اصلی است
راه اندازی یک شبکه LTE این طرح امکان دستیابی به حداکثر سرعت داده را فراهم می کند. ولی
از سوی دیگر، به دلیل سطوح تداخل سنگین از سلول های همسایه، لبه سلول
عملکرد کاربران بسیار محدود است.

شکل کامل فرکانس استفاده مجدد طرح در زیر فرکانس و طرح قدرت برای Full ارائه شده است
طرح استفاده مجدد فرکانس
[تصویر] طرح استفاده مجدد فرکانس کامل.UNINDENT

در ns-3، الگوریتم NoOp FR همیشه به زمانبندی اجازه می دهد تا از پهنای باند کامل استفاده کند و
همه UE ها برای استفاده از هر RBG. به سادگی هیچ چیز جدیدی انجام نمی دهد (یعنی eNB را محدود نمی کند
پهنای باند، الگوریتم FR غیرفعال است)، این ساده ترین پیاده سازی FrAlgorithm است.
کلاس و به طور پیش فرض در eNb نصب شده است.

سخت فرکانس استفاده مجدد
الگوریتم استفاده مجدد فرکانس سخت ساده ترین طرحی را ارائه می دهد که امکان کاهش را فراهم می کند
سطح تداخل بین سلولی در این طرح کل پهنای باند فرکانسی به تقسیم می شود
تعداد کمی (معمولاً 3، 4 یا 7) باندهای فرعی مجزا. eNB های مجاور با متفاوتی تخصیص داده می شوند
زیر باند ضریب استفاده مجدد فرکانس برابر با تعداد زیر باندها است. این طرح اجازه می دهد تا
به طور قابل توجهی ICI را در لبه سلول کاهش می دهد، بنابراین عملکرد کاربران سلول بهبود می یابد.
اما با توجه به این واقعیت، که هر eNB تنها از یک بخش از کل پهنای باند استفاده می کند، حداکثر سرعت داده
سطح نیز با ضریب برابر با ضریب استفاده مجدد کاهش می یابد.

شکل سخت فرکانس استفاده مجدد طرح در زیر فرکانس و طرح قدرت برای هارد ارائه شده است
طرح استفاده مجدد فرکانس
[تصویر] طرح استفاده مجدد فرکانس سخت.UNINDENT

در پیاده سازی ما، الگوریتم Hard FR فقط بردار RBGهای موجود برای eNB را دارد
و در طول توابع زمانبندی آن را به MAC Scheduler ارسال کنید. هنگامی که زمانبندی می پرسد، آیا RBG است
برای UE خاص مجاز است، همیشه درست است.

سخت فرکانس استفاده مجدد
طرح استفاده مجدد فرکانس دقیق ترکیبی از طرح های استفاده مجدد فرکانس کامل و سخت است. آی تی
شامل تقسیم پهنای باند سیستم به دو قسمت است که متفاوت خواهند بود
استفاده مجدد از فرکانس یک زیر باند مشترک از پهنای باند سیستم در داخل هر سلول استفاده می شود
(فرکانس استفاده مجدد-1)، در حالی که بخش دیگر از پهنای باند بین تقسیم شده است
eNBهای همسایه مانند استفاده مجدد فرکانس سخت (فرکانس استفاده مجدد-N، N>1)، به منظور ایجاد
یک زیر باند با سطح تداخل بین سلولی کم در هر بخش. مرکز UE ها خواهد بود
اعطا با تکه های فرکانس کاملاً استفاده مجدد، در حالی که UE های لبه سلولی با تکه های متعامد.
این بدان معنی است که UE های داخلی یک سلول هیچ طیفی با UE های لبه از یک سلول مشترک ندارند
سلول دوم، که تداخل را برای هر دو کاهش می دهد. همانطور که مشاهده می شود، Strict FR نیاز به a
در مجموع از N + 1 زیر باند، و اجازه می دهد تا به RFR در وسط بین 1 و 3.

شکل سخت فرکانس استفاده مجدد طرح در زیر فرکانس و طرح قدرت برای Strict ارائه شده است
طرح استفاده مجدد فرکانس با ضریب استفاده مجدد لبه سلولی N = 3.
[تصویر] طرح استفاده مجدد فرکانس دقیق.UNINDENT

در پیاده سازی ما، الگوریتم Strict FR دارای دو نقشه است، یکی برای هر زیر باند. اگر UE
را می توان در زیر باند خصوصی ارائه کرد، RNTI آن به نقشه m_privateSubBandUe اضافه می شود. اگر
UE را می توان در زیر باند مشترک ارائه کرد، RNTI آن به نقشه m_commonSubBandUe اضافه می شود.
الگوریتم Strict FR باید تصمیم بگیرد که در کدام زیر باند UE باید ارائه شود. استفاده می کند
اندازه گیری های UE ارائه شده توسط RRB و مقایسه آنها با آستانه کیفیت سیگنال (این
پارامتر را می توان به راحتی با مکانیسم ویژگی تنظیم کرد). آستانه تأثیر دارد
نسبت داخلی به شعاع سلول

نرم فرکانس استفاده مجدد
در طرح استفاده مجدد فرکانس نرم (SFR) هر eNb در کل پهنای باند سیستم ارسال می کند،
اما دو باند فرعی وجود دارد که در UE ها با سطح توان متفاوت سرو می شود. از آنجا که
UE های مرکز سلول پهنای باند را با سلول های همسایه به اشتراک می گذارند، آنها معمولاً در پایین تر انتقال می دهند
سطح توان نسبت به UE های لبه سلولی. SFR از پهنای باند کارآمدتر از Strict FR است.
زیرا از کل پهنای باند سیستم استفاده می کند، اما همچنین منجر به تداخل بیشتر برای هر دو می شود
کاربران داخلی سلول و لبه.

دو نسخه ممکن از طرح SFR وجود دارد:

· در نسخه اول، زیر باند اختصاص داده شده برای UE های لبه سلولی نیز ممکن است مورد استفاده قرار گیرد
UE های مرکز سلول اما با سطح توان کاهش یافته و تنها در صورتی که توسط آن اشغال نشده باشد
UE های لبه سلولی باند فرعی مرکز سلول فقط برای UE های مرکز در دسترس است. شکل
نرم فرکانس استفاده مجدد طرح نسخه 1 در زیر فرکانس و طرح قدرت برای
این نسخه از طرح استفاده مجدد فرکانس نرم.
[تصویر] طرح استفاده مجدد فرکانس نرم نسخه 1.UNINDENT

· در نسخه دوم، UE های مرکز سلولی به زیر باند لبه سلولی دسترسی ندارند. که در
به این ترتیب، هر سلول می تواند از کل پهنای باند سیستم استفاده کند و در عین حال پهنای باند را کاهش دهد
تداخل در سلول های همسایه از سوی دیگر، سطح ICI پایین تر در
لبه سلولی با هزینه استفاده از طیف کمتر به دست می آید. شکل نرم
فرکانس استفاده مجدد طرح نسخه 2 در زیر فرکانس و طرح توان برای این ارائه شده است
نسخه از طرح استفاده مجدد فرکانس نرم.
[تصویر] طرح استفاده مجدد فرکانس نرم نسخه 2.UNINDENT

الگوریتم SFR دو نقشه را حفظ می کند. اگر UE باید با سطح توان پایین‌تر ارائه شود، این است
RNTI به نقشه m_lowPowerSubBandUe اضافه شد. اگر UE باید با قدرت بالاتر سرو شود
سطح، RNTI آن به نقشه m_highPowerSubBandUe اضافه می شود. برای تصمیم گیری با کدام سطح قدرت
UE باید ارائه شود الگوریتم SFR با استفاده از اندازه گیری های UE، و آنها را با آن مقایسه می کند
آستانه. آستانه کیفیت سیگنال و PdschConfigDedicated (یعنی مقدار P_A) برای داخلی
و ناحیه بیرونی را می توان توسط سیستم ویژگی ها پیکربندی کرد. SFR از Downlink Power استفاده می کند
کنترل در اینجا توضیح داده شده است.

نرم کسری فرکانس استفاده مجدد
استفاده مجدد از فرکانس کسری نرم (SFFR) ترکیبی از فرکانس سخت و نرم است.
طرح های استفاده مجدد در حالی که Strict FR از زیر باندهای اختصاص داده شده برای منطقه بیرونی در استفاده نمی کند
سلول های مجاور، FFR نرم از این زیر باندها برای UE های داخلی با توان انتقال کم استفاده می کند. مانند
در نتیجه، SFFR، مانند SFR، از زیر باند با سطح توان انتقال بالا و با سطح پایین استفاده می کند
سطح توان انتقال بر خلاف Soft FR و مانند Strict FR، Soft FFR از معمول استفاده می کند
زیر باند که می تواند توان عملیاتی کاربران داخلی را افزایش دهد.

شکل نرم کسری کسری فرکانس استفاده مجدد طرح در زیر فرکانس و
طرح قدرت برای استفاده مجدد از فرکانس کسری نرم.
[تصویر] طرح استفاده مجدد فرکانس کسری نرم.UNINDENT

پیشرفته کسری فرکانس استفاده مجدد
استفاده مجدد فرکانس کسری پیشرفته (EFFR) شرح داده شده در [ZXie2009] 3 نوع سلول را تعریف می کند.
برای سلول های همسایه مستقیم در یک سیستم سلولی، و ذخیره برای هر سلول نوع a
بخشی از کل باند فرکانسی نامگذاری شده است اولیه بخش، که در میان سلول های نوع مختلف
باید متعامد باشد زیر کانال های باقی مانده را تشکیل می دهند دوم بخش.
اولیه بخش از یک نوع سلول در عین حال بخشی از دوم بخش
متعلق به دو نوع سلولی دیگر هر سلول می تواند تمام زیر کانال های خود را اشغال کند اولیه
بخش به میل خود، در حالی که تنها بخشی از کانال های فرعی در دوم بخش می تواند مورد استفاده قرار گیرد
توسط این سلول به شیوه ای آگاه از تداخل اولیه بخش از هر سلول تقسیم می شود
به یک قسمت استفاده مجدد-3 و استفاده مجدد-1 قسمت. بخش استفاده مجدد-1 می تواند توسط همه انواع سلول ها مورد استفاده مجدد قرار گیرد
در سیستم، در حالی که بخش استفاده مجدد-3 فقط می تواند به طور انحصاری توسط همان نوع دیگر مورد استفاده مجدد قرار گیرد
سلول‌ها (یعنی زیر کانال‌های استفاده مجدد-3 توسط سلول‌های همسایه مستقیماً قابل استفاده مجدد نیستند). بر
la دوم بخش سلول به عنوان مهمان عمل می کند و اشغال کانال های فرعی ثانویه است
بنابراین، در واقع از زیر کانال های اولیه متعلق به سلول های مستقیماً همسایه مجدداً استفاده کنید
استفاده مجدد در دوم بخش هر سلول باید با دو قانون مطابقت داشته باشد:

· قبل از استفاده نظارت کنید

· استفاده مجدد از منابع بر اساس برآورد SINR

هر سلول همیشه به هر کانال فرعی ثانویه گوش می دهد. و قبل از اشغال آن
ارزیابی SINR را با توجه به اطلاعات کیفی کانال جمع آوری شده (CQI) انجام می دهد و
منابعی را با بهترین مقادیر تخمینی برای استفاده مجدد انتخاب می کند. اگر مقدار CQI برای RBG بالاتر باشد
آستانه پیکربندی شده برای برخی از کاربران، انتقال برای این کاربر می تواند با استفاده از آن انجام شود
RBG.

در [ZXie2009] فرآیند زمان بندی شرح داده شده است، از سه مرحله و دو مرحله تشکیل شده است
سیاست های زمان بندی از آنجایی که هیچ یک از زمانبندی‌های اجرا شده در حال حاضر این اجازه را نمی‌دهند
رفتار، برخی از ساده سازی اعمال شد. در پیاده سازی ما استفاده مجدد - 1 کانال فرعی می تواند
فقط توسط کاربران مرکز سلولی استفاده شود. استفاده مجدد از 3 کانال فرعی می تواند توسط کاربران لبه استفاده شود، و فقط
اگر کاربر لبه ای وجود نداشته باشد، انتقال برای کاربران مرکز سلولی می تواند در استفاده مجدد-3 ارائه شود
کانال های فرعی

شکل پیشرفته کسری کسری فرکانس استفاده مجدد طرح در زیر فرکانس و
طرح قدرت برای استفاده مجدد از فرکانس کسری پیشرفته.
[تصویر] طرح استفاده مجدد فرکانس کسری کسری پیشرفته.UNINDENT

توزیع شده کسری فرکانس استفاده مجدد
این الگوریتم استفاده مجدد فرکانس کسری توزیع شده در [DKimura2012] ارائه شد. آی تی
به طور خودکار زیر باندهای لبه سلولی را با تمرکز بر توزیع کاربر بهینه می کند
خاص، توزیع توان دریافتی). این الگوریتم به صورت تطبیقی ​​RB ها را برای آن انتخاب می کند
زیر باند لبه سلولی بر اساس اطلاعات هماهنگی از سلول های مجاور و اطلاع رسانی می کند
ایستگاه های پایه سلول های مجاور، که RB ها را برای استفاده در زیر باند لبه انتخاب کرد.
ایستگاه پایه هر سلول از اطلاعات دریافتی و معادله زیر استفاده می کند
متریک باند لبه سلولی A_{k} را برای هر RB محاسبه کنید.

که در آن J مجموعه ای از سلول های همسایه است، X_{j,k}=0,1 RNTP از سلول همسایه j ام است.
وقتی از k-امین RB در سلول همسایه j به عنوان لبه سلول استفاده می شود مقدار 1 می گیرد.
زیر باند و 0 در غیر این صورت. نماد w_{j} وزن را نسبت به سلول مجاور j نشان می دهد،
یعنی تعداد کاربرانی که برای آنها تفاوت بین قدرت سیگنال وجود دارد
دریافت شده از سلول سرویس i و قدرت سیگنال دریافتی از مجاور
سلول j کمتر از یک مقدار آستانه است (یعنی تعداد کاربران نزدیک به لبه سلول در
سلول خدماتی). اختلاف توان دریافتی زیاد به این معنی است که کاربران لبه سلولی در i-th
سلول از تداخل شدید سلول j رنج می برد.

RB که متریک A_{k} برای آن کوچک‌ترین است کمتر تحت تأثیر قرار می‌گیرد
تداخل از یک سلول دیگر سلول سرویس تعداد پیکربندی شده ای از RB ها را به عنوان انتخاب می کند
زیر باند لبه سلولی به ترتیب صعودی A_{k}. در نتیجه، RBهایی که در آن کوچک است
تعداد کاربران لبه سلولی تداخل بالایی از ایستگاه های پایه مجاور دریافت می کنند
انتخاب شد.

سپس RNTP به روز شده به تمام سلول های همسایه ارسال می شود. برای جلوگیری از بی معنی
نوسان انتخاب باند لبه سلولی، یک ایستگاه پایه یک RNTP از پایه دیگر را نادیده می گیرد.
ایستگاهی که شناسه سلولی بزرگتری نسبت به ایستگاه پایه دارد.

تکرار این فرآیند در تمام سلول‌ها، تخصیص RBs به نواحی لبه سلول را ممکن می‌سازد
برای بهینه سازی در سیستم و با تغییرات در توزیع کاربر تنظیم شود.

شکل دنباله نمودار of توزیع شده فرکانس استفاده مجدد طرح در زیر دنباله ارائه می شود
نمودار طرح استفاده مجدد فرکانس کسری توزیع شده.
[تصویر] نمودار توالی طرح استفاده مجدد فرکانس توزیع شده.UNINDENT

یاران
از دو شی کمکی برای راه اندازی شبیه سازی ها و پیکربندی اجزای مختلف استفاده می شود.
این اشیاء عبارتند از:

· LteHelper، که از پیکربندی شبکه دسترسی رادیویی LTE مراقبت می کند، به عنوان
و همچنین هماهنگی راه اندازی و انتشار حامل های EPS. این LteHelper کلاس
هم تعریف API و هم پیاده سازی آن را ارائه می دهد.

· EpcHelper، که از پیکربندی هسته بسته تکامل یافته مراقبت می کند. این
EpcHelper کلاس یک کلاس پایه انتزاعی است که فقط تعریف API را ارائه می دهد. را
پیاده سازی به کلاس های کودک واگذار می شود تا امکان EPC های مختلف فراهم شود
مدل های شبکه

امکان ایجاد یک شبیه سازی ساده فقط LTE با استفاده از آن وجود دارد LteHelper به تنهایی یا به
با استفاده از هر دو، شبیه سازی های کامل LTE-EPC را ایجاد کنید LteHelper و EpcHelper. وقتی هر دو
کمک‌کننده‌ها استفاده می‌شوند، آنها به شیوه ارباب-برده تعامل دارند، با LteHelper استاد بودن
که مستقیماً با برنامه کاربر تعامل دارد و EpcHelper کار "زیر کاپوت" به
پیکربندی EPC بر اساس روش های صریح فراخوانی شده توسط LteHelper. فعل و انفعالات دقیق هستند
در شکل نمایش داده شده است دنباله نمودار of la اثر متقابل میان LteHelper و
EpcHelper.
[تصویر] نمودار توالی تعامل بین LteHelper و EpcHelper.UNINDENT

کاربر مستندات
زمینه
ما فرض می کنیم که خواننده قبلاً با نحوه استفاده از شبیه ساز ns-3 برای اجرای عمومی آشنا است
برنامه های شبیه سازی اگر اینطور نیست، ما اکیداً به خواننده توصیه می کنیم که مشورت کند
[ns3tutorial].

استفاده بررسی اجمالی
مدل ns-3 LTE یک کتابخانه نرم افزاری است که امکان شبیه سازی شبکه های LTE را فراهم می کند.
به صورت اختیاری شامل هسته بسته تکامل یافته (EPC). روند انجام چنین
شبیه سازی معمولا شامل مراحل زیر است:

1. تعریف کردن la سناریو شبیه سازی شود

2. نوشتن a شبیه سازی برنامه که سناریوی مورد نظر را بازسازی می کند
توپولوژی/معماری این کار با دسترسی به کتابخانه مدل ns-3 LTE با استفاده از
ns3::LteHelper API تعریف شده در src/lte/helper/lte-helper.h.

3. مشخص کردن پیکر بندی پارامترهای از اشیایی که برای
شبیه سازی. این کار را می توان با استفاده از فایل های ورودی (از طریق ns3::ConfigStore) و یا
مستقیماً در برنامه شبیه سازی

4. مجموعه la مطلوب تولید توسط شبیه ساز تولید می شود

5. دویدن شبیه سازی

تمام این جنبه ها در بخش های بعدی با استفاده از روش عملی توضیح داده خواهد شد
مثال ها.

اساسی شبیه سازی برنامه
در اینجا حداقل برنامه شبیه سازی است که برای انجام یک شبیه سازی فقط LTE مورد نیاز است
(بدون EPC).

1. دیگ بخار اولیه:

#include
#include
#include
#include

با استفاده از فضای نام ns3;

int main (int argc، char *argv[])
{
// بقیه برنامه شبیه سازی در ادامه می آید

2. ایجاد کنید LteHelper هدف - شی:

Ptr lteHelper = CreateObject ();

با این کار، برخی از اشیاء رایج (به عنوان مثال، شی Channel) نمونه سازی می شود و آن را ارائه می دهد
روش هایی برای افزودن eNB و UE و پیکربندی آنها.

3 ايجاد كردن گره اشیاء ENB (ها) و UES:

NodeContainer enbNodes;
enbNodes.Create (1);
NodeContainer ueNodes;
ueNodes.Create (2);

توجه داشته باشید که نمونه‌های Node فوق در این مرحله هنوز پروتکل LTE ندارند
پشته نصب شده؛ آنها فقط گره های خالی هستند.

4. مدل Mobility را برای همه گره ها پیکربندی کنید:

MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (ueNodes);

موارد فوق همه گره ها را در مختصات (0,0,0) قرار می دهد. لطفا به
مستندات مدل تحرک ns-3 برای نحوه تنظیم موقعیت یا پیکربندی خود
حرکت گره

5. یک پشته پروتکل LTE را روی eNB(ها) نصب کنید:

NetDeviceContainer enbDevs.
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. یک پشته پروتکل LTE را روی UE ها نصب کنید:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. UE ها را به یک eNB متصل کنید. این هر UE را مطابق eNB پیکربندی می کند
پیکربندی، و یک اتصال RRC بین آنها ایجاد کنید:

lteHelper->Attach (ueDevs، enbDevs.Get (0));

8. یک حامل رادیویی داده را بین هر UE و eNB که به آن متصل است فعال کنید:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
حامل EpsBearer (q);
lteHelper->ActivateDataRadioBearer (ueDevs، bearer)؛

این روش همچنین دو مولد ترافیک اشباع را برای آن حامل فعال می کند، یکی
در uplink و یکی در downlink.

9. زمان توقف را تنظیم کنید:

شبیه ساز::توقف (ثانیه (0.005))؛

این مورد نیاز است در غیر این صورت شبیه سازی برای همیشه ادامه خواهد داشت، زیرا (در میان دیگران)
رویداد start-of-subframe به طور مکرر برنامه ریزی شده است و زمان بندی شبیه ساز ns-3
از این رو هرگز از رویدادها خالی نشوید.

10. شبیه سازی را اجرا کنید:

شبیه ساز::Run ();

11. پاکسازی و خروج:

شبیه ساز::Destroy ();
0 بازگشت؛
}

برای نحوه کامپایل و اجرای برنامه های شبیه سازی لطفا به [ns3tutorial] مراجعه کنید.

پیکر بندی of LTE مدل پارامترهای
تمام پارامترهای مدل LTE مربوطه از طریق سیستم ویژگی ns-3 مدیریت می شوند.
لطفاً برای اطلاعات دقیق در مورد همه موارد به [ns3tutorial] و [ns3manual] مراجعه کنید
روش های ممکن برای انجام آن (متغیرهای محیطی، C++ API، GtkConfigStore...).

در ادامه، به طور خلاصه نحوه انجام این کار با استفاده از فایل های ورودی همراه با را خلاصه می کنیم
ns-3 ConfigStore. ابتدا باید موارد زیر را در شبیه سازی خود قرار دهید
برنامه، بلافاصله بعد اصلی () شروع می کند:

CommandLine cmd;
cmd.Parse (argc, argv);
ConfigStore inputConfig.
inputConfig.ConfigureDefaults ();
// دوباره تجزیه کنید تا بتوانید مقادیر پیش فرض را از خط فرمان لغو کنید
cmd.Parse (argc, argv);

برای اینکه موارد فوق کار کنند، مطمئن شوید که شما نیز #include "ns3/config-store.h". حالا یک را ایجاد کنید
فایل متنی با نام (مثلا) input-defaults.txt تعیین مقادیر پیش فرض جدید که
می خواهید برای برخی از ویژگی ها استفاده کنید:

پیش فرض ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
پیش فرض ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
پیش‌فرض ns3::LteEnbNetDevice::UlBandwidth "25"
پیش فرض ns3::LteEnbNetDevice::DlBandwidth "25"
پیش فرض ns3::LteEnbNetDevice::DlEarfcn "100"
پیش فرض ns3::LteEnbNetDevice::UlEarfcn "18100"
پیش فرض ns3::LteUePhy::TxPower "10"
پیش فرض ns3::LteUePhy::Noiseشکل "9"
پیش فرض ns3::LteEnbPhy::TxPower "30"
پیش فرض NS3 :: Lteenbphy :: SonderFigure "5"

فرض کنید برنامه شبیه سازی شما فراخوانی شده است src/lte/examples/lte-sim-with-input، شما می توانید
اکنون این تنظیمات را به روش زیر به برنامه شبیه سازی منتقل کنید:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --src/lte/examples/lte-sim-with-input را اجرا کنید

علاوه بر این، می توانید یک فایل ورودی قالب را با دستور زیر ایجاد کنید:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --src/lte/examples/lte-sim-with-input را اجرا کنید

توجه داشته باشید که موارد فوق در فایل قرار خواهد گرفت input-defaults.txt تمام مقادیر پیش فرض که
در ساخت خاص شبیه ساز شما ثبت شده اند، از جمله تعداد زیادی غیر LTE
ویژگی های.

مجموعه LTE MAC زمان بند
انواع مختلفی از زمانبندی LTE MAC وجود دارد که کاربر می تواند در اینجا انتخاب کند. کاربر می تواند از موارد زیر استفاده کند
کدهایی برای تعریف نوع زمانبندی:

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // زمانبندی FD-MT
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // زمانبندی TD-MT
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // زمانبندی TTA
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // زمانبندی FD-BET
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // زمانبندی TD-BET
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // زمانبندی FD-TBFQ
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // زمانبندی TD-TBFQ
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); //زمانبندی PSS

TBFQ و PSS پارامترهای بیشتری نسبت به زمانبندی های دیگر دارند. کاربران می توانند آن پارامترها را تعریف کنند
به روش زیر:

* زمانبندی TBFQ::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("DebtLimit"، IntegerValue(Yourvalue)); // مقدار پیش فرض -625000 بایت (-5 مگابایت)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(Yourvalue)); // مقدار پیش فرض 625000 بایت (5 مگابایت)
lteHelper->SetSchedulerAttribute("TokenPoolSize"، UintegerValue(ارزش شما)); // مقدار پیش فرض 1 بایت
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(Yourvalue)); // مقدار پیش فرض 0

* زمانبندی PSS::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("nMux"، UIntegerValue(Yourvalue)); // حداکثر تعداد UE انتخاب شده توسط زمانبندی TD
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // نوع زمانبندی PF در PSS

در TBFQ، مقادیر پیش‌فرض حد بدهی و حد اعتبار روی -5 مگابایت و 5 مگابایت تنظیم شده است
به ترتیب بر اساس مقاله [FABokhari2009]. اجرای فعلی در نظر گرفته نمی شود
آستانه اعتبار (C = 0). در PSS، اگر کاربر nMux را تعریف نکند، PSS این مقدار را روی تنظیم می کند
نیمی از کل UE زمانبندی پیش فرض FD PFsch است.

علاوه بر این، نرخ تولید توکن در TBFQ و نرخ بیت هدف در PSS باید باشد
پیکربندی شده توسط نرخ بیت تضمینی (GBR) یا حداکثر نرخ بیت (MBR) در QoS حامل epc
مولفه های. کاربران می توانند از کدهای زیر برای تعریف GBR و MBR در هر دو لینک و
لینک بالا:

Ptr lteHelper = CreateObject ();
enum EpsBearer::Qci q = EpsBearer::yourvalue; // نوع Qci را تعریف کنید
GbrQosInformation qos;
qos.gbrDl = yourvalue; // لینک پایین GBR
qos.gbrUl = مقدار شما; // Uplink GBR
qos.mbrDl = مقدار شما; // داونلینک MBR
qos.mbrUl = ارزش شما; // Uplink MBR
حامل EpsBearer (q، qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, bearer, EpcTft::Default ());

در PSS، TBR از GBR در پارامترهای QoS سطح حامل به دست می آید. در TBFQ، تولید توکن
نرخ از تنظیم MBR در پارامترهای QoS سطح حامل به دست می‌آید، که بنابراین
باید به طور مداوم پیکربندی شود. برای ترافیک نرخ بیت ثابت (CBR) پیشنهاد می شود
برای تنظیم MBR به GBR. برای ترافیک نرخ بیت واریانس (VBR)، پیشنهاد می شود که MBR k بار تنظیم شود
بزرگتر از GBR به منظور پوشش اوج نرخ ترافیک. در اجرای فعلی، k است
بر اساس کاغذ روی سه تنظیم شد [FABokhari2009]. علاوه بر این، نسخه فعلی TBFQ اینطور نیست
هدر RLC و طول هدر PDCP را در MBR و GBR در نظر بگیرید. پارامتر دیگر در TBFQ این است
نرخ رسیدن بسته این پارامتر در زمانبندی محاسبه می شود و برابر با گذشته است
متوسط ​​توان عملیاتی که در زمانبندی PF استفاده می شود.

بسیاری از ویژگی های مفید مدل LTE-EPC در ادامه توضیح داده خواهد شد
زیر بخش ها با این حال، بسیاری از صفات وجود دارد که به صراحت در آن ذکر نشده است
طراحی یا مستندات کاربر، اما به وضوح با استفاده از ویژگی ns-3 مستند شده اند
سیستم. شما به راحتی می توانید لیستی از ویژگی های یک شی معین را همراه با آن چاپ کنید
توضیحات و مقدار پیش فرض آنها عبور می کند --PrintAttributes= به یک برنامه شبیه سازی،
مثل این:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

همچنین می توانید با سایر اشیاء LTE و EPC مانند زیر امتحان کنید:

./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"

شبیه سازی تولید
مدل ns-3 LTE در حال حاضر از خروجی فایل در سطح PHY، MAC، RLC و PDCP پشتیبانی می کند.
شاخص های کلیدی عملکرد (KPI). می توانید آن را به روش زیر فعال کنید:

Ptr lteHelper = CreateObject ();

// تمام سناریوهای شبیه سازی را در اینجا پیکربندی کنید...

lteHelper->EnablePhyTraces ();
lteHelper->EnableMacTraces ();
lteHelper->EnableRlcTraces ();
lteHelper->EnablePdcpTraces ();

شبیه ساز::Run ();

KPI های RLC و PDCP در یک بازه زمانی محاسبه شده و در فایل های ASCII ذخیره می شوند.
KPIهای RLC و دو عدد برای KPIهای PDCP، در هر مورد یکی برای uplink و یکی برای downlink. زمان
مدت بازه زمانی را می توان با استفاده از ویژگی کنترل کرد
ns3::RadioBearerStatsCalculator::EpochDuration.

ستون‌های فایل‌های KPI RLC به شرح زیر است (برای لینک بالا و پایین یکسان است):

1. زمان شروع فاصله اندازه گیری بر حسب ثانیه از شروع شبیه سازی

2. زمان پایان فاصله اندازه گیری بر حسب ثانیه از شروع شبیه سازی

3. شناسه سلولی

4. شناسه منحصر به فرد UE (IMSI)

5. UE ID (RNTI) اختصاصی سلول

6. شناسه کانال منطقی

7. تعداد PDUهای RLC ارسالی

8. کل بایت های ارسال شده.

9. تعداد PDUهای RLC دریافتی

10. کل بایت های دریافتی

11. میانگین تاخیر RLC PDU در ثانیه

12. انحراف استاندارد تاخیر PDU RLC

13. حداقل مقدار تأخیر RLC PDU

14. حداکثر مقدار تاخیر PDU RLC

15. متوسط ​​اندازه RLC PDU ، در بایت

16. انحراف استاندارد از اندازه RLC PDU

17. حداقل اندازه PDU RLC

18. حداکثر اندازه PDU RLC

به طور مشابه، ستون های فایل های PDCP KPI به شرح زیر است (دوباره، برای uplink یکسان است
و لینک پایین):

1. زمان شروع فاصله اندازه گیری بر حسب ثانیه از شروع شبیه سازی

2. زمان پایان فاصله اندازه گیری بر حسب ثانیه از شروع شبیه سازی

3. شناسه سلولی

4. شناسه منحصر به فرد UE (IMSI)

5. UE ID (RNTI) اختصاصی سلول

6. شناسه کانال منطقی

7. تعداد PDUهای PDCP ارسال شده

8. کل بایت های ارسال شده.

9. تعداد PDU های PDCP دریافت شده

10. کل بایت های دریافتی

11. میانگین تاخیر PDCP PDU در ثانیه

12. انحراف استاندارد تاخیر PDU PDCP

13. حداقل مقدار تاخیر PDCP PDU

14. حداکثر مقدار تاخیر PDCP PDU

15. میانگین اندازه PDCP PDU، بر حسب بایت

16. انحراف معیار اندازه PDU PDCP

17. حداقل اندازه PDCP PDU

18. حداکثر اندازه PDCP PDU

KPIهای MAC اساساً ردی از تخصیص منابع گزارش شده توسط زمانبندی هستند
شروع هر زیر فریم آنها در فایل های ASCII ذخیره می شوند. برای MAC KPIهای downlink
قالب به شرح زیر است:

1. زمان شبیه سازی بر حسب ثانیه که در آن تخصیص توسط زمانبندی نشان داده می شود

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. شماره قاب

5. شماره زیر فریم

6. UE ID (RNTI) اختصاصی سلول

7. MCS سل 1

8. اندازه سل 1

9. MCS سل 2 (0 در صورت نبودن)

10. اندازه سل 2 (0 در صورت نبودن)

در حالی که برای MAC KPIهای uplink فرمت این است:

1. زمان شبیه سازی بر حسب ثانیه که در آن تخصیص توسط زمانبندی نشان داده می شود

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. شماره قاب

5. شماره زیر فریم

6. UE ID (RNTI) اختصاصی سلول

7. MCS سل

8. اندازه سل

نام فایل های مورد استفاده برای خروجی MAC KPI را می توان از طریق ویژگی های ns-3 سفارشی کرد
ns3::MacStatsCalculator::DlOutputFilename و ns3::MacStatsCalculator::UlOutputFilename.

KPIهای PHY در هفت فایل مختلف توزیع شده‌اند که از طریق ویژگی‌ها قابل تنظیم هستند

1. ns3::PhyStatsCalculator::DlRsrpSinrنام فایل

2. ns3::PhyStatsCalculator::UeSinrنام فایل

3. ns3::PhyStatsCalculator::InterferencenameFilename

4. ns3::PhyStatsCalculator::DlTxOutputنام فایل

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

در فایل RSRP/SINR، محتوای زیر موجود است:

1. زمان شبیه سازی بر حسب ثانیه که در آن تخصیص توسط زمانبندی نشان داده می شود

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. RSRP

5. میانگین خطی روی همه RBهای SINR پایین لینک در واحدهای خطی

محتویات فایل UE SINR عبارتند از:

1. زمان شبیه سازی بر حسب ثانیه که در آن تخصیص توسط زمانبندی نشان داده می شود

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. SINR را در واحدهای خطی برای UE پیوند دهید

در نام فایل تداخلی، محتوا این است:

1. زمان شبیه سازی بر حسب ثانیه که در آن تخصیص توسط زمانبندی نشان داده می شود

2. شناسه سلولی

3. فهرست مقادیر تداخل در هر RB

در فایل های انتقال UL و DL پارامترهای موجود عبارتند از:

1. زمان شبیه سازی بر حسب میلی ثانیه

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. RNTI

5. لایه انتقال

6. MCS

7. اندازه سل

8. نسخه افزونگی

9. پرچم نشانگر داده جدید

و در نهایت، در فایل های دریافت UL و DL پارامترهای موجود عبارتند از:

1. زمان شبیه سازی بر حسب میلی ثانیه

2. شناسه سلولی

3. شناسه منحصر به فرد UE (IMSI)

4. RNTI

5. حالت انتقال

6. لایه انتقال

7. MCS

8. اندازه سل

9. نسخه افزونگی

10. پرچم نشانگر داده جدید

11. صحت در دریافت سل

محو شدن پی گیری استفاده
در این بخش نحوه استفاده از ردپای محو شدن در شبیه سازی های LTE را شرح خواهیم داد.

محو شدن ردیابی ها نسل
با استفاده از یک اسکریپت اختصاصی متلب که همراه با آن ارائه شده است، می توان ردهای محو شده را ایجاد کرد
کد (/lte/model/fading-traces/fading-trace-generator.m). این اسکریپت قبلاً شامل می شود
پیکربندی شیرهای معمولی برای سه سناریو 3GPP (یعنی عابر پیاده، وسیله نقلیه و
شهری همانطور که در پیوست B.2 [TS36104] تعریف شده است). با این حال کاربران نیز می توانند خود را معرفی کنند
تنظیمات خاص لیست پارامترهای قابل تنظیم در قسمت ارائه شده است
زیر است:

· fc : فرکانس در حال استفاده (بر محاسبه سرعت داپلر تأثیر می گذارد).

· v_km_h : سرعت کاربران

· traceDuration : مدت زمان کل ردیابی بر حسب ثانیه.

· numRBs : تعداد بلوک منبعی که باید ارزیابی شود.

· برچسب : برچسبی که باید روی فایل ایجاد شده اعمال شود.

فایل تولید شده حاوی مقادیر واقعی با فرمت ASCII است که به صورت ماتریسی سازماندهی شده اند:
هر سطر مربوط به یک RB متفاوت است و هر ستون مربوط به متفاوت است
نمونه ردیابی محو شدن زمانی

لازم به ذکر است که ماژول ns-3 LTE قادر است با هر فایل ردیابی محو شده کار کند
که با فرمت ASCII شرح داده شده در بالا مطابقت دارد. از این رو، ابزارهای خارجی دیگر می توانند باشند
برای تولید ردهای محو سفارشی، مانند شبیه سازهای دیگر یا
دستگاه های آزمایشی

محو شدن ردیابی ها استفاده
هنگام استفاده از ردی محو، تعیین صحیح ردیابی از اهمیت بالایی برخوردار است
پارامترهای موجود در شبیه سازی، به طوری که مدل محو می شود و می تواند به درستی از آن استفاده کند. این
پارامترهایی که باید پیکربندی شوند عبارتند از:

· TraceFilename : نام ردیابی که باید بارگذاری شود (مسیر مطلق یا مسیر نسبی
w.r.t. مسیری که برنامه شبیه سازی از آنجا اجرا می شود)؛

· TraceLength : مدت زمان ردیابی بر حسب ثانیه.

· SamplesNum : تعداد نمونه;

· اندازه Window : اندازه پنجره نمونه برداری محو شده در ثانیه.

نکته مهم این است که فاصله نمونه برداری از رد محو شدن باید 1 میلی ثانیه باشد
یا بزرگتر، و در مورد دوم باید مضرب صحیح 1 ms باشد تا
به درستی توسط ماژول محو پردازش می شود.

پیکربندی پیش‌فرض اسکریپت matlab یک ردیابی به مدت 10 ثانیه را ارائه می‌کند
10,000 نمونه (یعنی 1 نمونه در هر TTI=1ms) و با اندازه ویندوز 0.5 ثانیه استفاده شده است
دامنه اینها همچنین مقادیر پیش‌فرض پارامترهای استفاده شده در بالا هستند
شبیه ساز؛ بنابراین در صورتی که اثر محو شدن به آنها احترام بگذارد، می توان از گیر کردن آنها جلوگیری کرد.

برای فعال کردن ماژول fading (که به طور پیش فرض فعال نیست) کد زیر را وارد کنید
باید در برنامه شبیه سازی گنجانده شود:

Ptr lteHelper = CreateObject ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

و برای تنظیم پارامترها:

lteHelper->SetFadingModelAttribute ("TraceFilename"، StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength"، TimeValue (ثانیه (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum"، UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("WindowSize"، TimeValue (ثانیه (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum"، UintegerValue (100));

لازم به ذکر است که ، TraceFilename مقدار پیش فرض ندارد، بنابراین باید داشته باشد
همیشه به صراحت تنظیم شود

شبیه ساز به طور بومی سه رد محو شده را ارائه می دهد که مطابق با
تنظیمات تعریف شده در پیوست B.2 [TS36104]. این آثار در دسترس هستند
پوشه src/lte/model/fading-traces/). گزیده ای از این آثار در نشان داده شده است
ارقام زیر
[تصویر: رد محو شدن 3 کیلومتر در ساعت] [تصویر] گزیده ای از رد محو شدن موجود در
شبیه ساز برای سناریوی عابر پیاده (سرعت 3 کیلومتر در ساعت)..UNINDENT
[تصویر: رد محو شدن 60 کیلومتر در ساعت] [تصویر] گزیده ای از رد محو شدن موجود در
شبیه ساز برای یک سناریوی وسیله نقلیه (سرعت 60 کیلومتر در ساعت)..UNINDENT
[تصویر: رد محو شدن 3 کیلومتر در ساعت] [تصویر] گزیده ای از رد محو شدن موجود در
شبیه ساز برای یک سناریوی شهری (سرعت 3 کیلومتر در ساعت)..UNINDENT

تحرک مدل با ساختمان
اکنون با مثال هایی توضیح می دهیم که چگونه از مدل ساختمان ها استفاده کنیم (به ویژه،
MobilityBuildingInfo و Building PropagationModel کلاس ها) در یک شبیه سازی ns-3
برنامه ای برای راه اندازی یک سناریوی شبیه سازی LTE که شامل ساختمان ها و گره های داخلی است.

1. فایل های سرصفحه ای که باید گنجانده شود:

#include
#include
#include

2. انتخاب مدل Pathloss:

Ptr lteHelper = CreateObject ();

lteHelper->SetAttribute ("PathlossModel"، StringValue ("ns3::BuildingsPropagationLossModel"));

3. انتخاب باند EUTRA

انتخاب فرکانس کاری مدل انتشار باید با
سیستم ویژگی استاندارد ns-3 همانطور که در بخش مربوطه توضیح داده شده است ("پیکربندی
پارامترهای مدل LTE") با استفاده از پارامترهای DlEarfcn و UEarfcn، به عنوان مثال:

lteHelper->SetEnbDeviceAttribute ("DlEarfcn"، UintegerValue (100));
lteHelper->SetEnbDeviceAttribute ("UlEarfcn"، UintegerValue (18100));

لازم به ذکر است که استفاده از ابزارهای دیگر برای پیکربندی فرکانس استفاده شده توسط
مدل انتشار (به عنوان مثال، پیکربندی BuildingsPropagationLossModel مربوطه
ویژگی‌ها مستقیماً) ممکن است تضادهایی در تعریف فرکانس‌ها ایجاد کند
ماژول ها در طول شبیه سازی، و بنابراین توصیه نمی شود.

1. انتخاب مدل تحرک:

MobilityHelper mobility;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");

لازم به ذکر است که هر مدل حرکتی قابل استفاده است.

2. ایجاد ساختمان:

x_min دو برابر = 0.0;
دو برابر x_max = 10.0;
دو برابر y_min = 0.0;
دو برابر y_max = 20.0;
z_min دو برابر = 0.0;
z_max دو برابر = 10.0;
Ptr b = CreateObject ()
b->SetBoundaries (جعبه (x_min، x_max، y_min، y_max، z_min، z_max));
b->SetBuildingType (ساختمان::مسکونی);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3)؛
b->SetNRoomsX (3);
b->SetNRoomsY (2);

این یک ساختمان مسکونی با زیربنای 10×20 متر و ارتفاع از آن نمونه خواهد بود
10 متر که دیوارهای خارجی آن بتنی با پنجره است. ساختمان دارای سه
طبقات و دارای یک شبکه داخلی 3×2 اتاق با اندازه مساوی.

3. ایجاد و تعیین موقعیت گره:

ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0)->GetObject ()
Ptr mm1 = enbNodes.Get (1)->GetObject ()
mm0->SetPosition (بردار (5.0، 5.0، 1.5));
mm1->SetPosition (بردار (30.0، 40.0، 1.5));

4. پیکربندی مدل ساختمان و تحرک را نهایی کنید:

BuildingsHelper::MakeMobilityModelConsistent ();

مستندات را ببینید ساختمان ماژول برای اطلاعات دقیق تر

PHY خطا مدل
مدل خطای فیزیکی از مدل خطای داده و خطای کنترل لینک پایین تشکیل شده است
مدل، هر دو به طور پیش فرض فعال هستند. غیرفعال کردن آنها با ns3 امکان پذیر است
سیستم ویژگی ، با جزئیات:

پیکربندی::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled"، BooleanValue (نادرست));
پیکربندی::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled"، BooleanValue (نادرست));

MIMO مدل
آیا در این بخش فرعی نحوه پیکربندی پارامترهای MIMO را نشان می دهیم. LTE 7 نوع تعریف می کند
حالت های انتقال:

· حالت انتقال 1: SISO.

· حالت انتقال 2: تنوع MIMO Tx.

· حالت انتقال 3: MIMO Spatial Multiplexity Open Loop.

· حالت انتقال 4: MIMO Spatial Multiplexity Closed Loop.

· حالت انتقال 5: MIMO چند کاربر.

· حالت انتقال 6: از پیش کدگذاری تک لایه حلقه نزدیکتر.

· حالت انتقال 7: درگاه تک آنتن 5.

با توجه به مدل اجرا شده، شبیه ساز شامل سه حالت اول انتقال است
انواع حالت پیش فرض انتقال 1 (SISO) است. به منظور تغییر پیش فرض
حالت انتقال مورد استفاده، ویژگی حالت انتقال پیش فرض از LteEnbrRrc می توان
استفاده شود، همانطور که در زیر نشان داده شده است:

پیکربندی::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (0)); // SISO
پیکربندی::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (1)); // تنوع MIMO Tx (1 ​​لایه)
پیکربندی::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (2)); // MIMO Spatial Multiplexity (2 لایه)

برای تغییر حالت انتقال یک کاربر خاص در طول شبیه سازی، یک برنامه خاص
رابط در هر دو زمانبندی استاندارد پیاده سازی شده است:

void TransmissionModeConfigurationUpdate (uint16_t rnti، uint8_t txMode)؛

این روش می تواند هم برای توسعه موتور تصمیم گیری حالت انتقال (یعنی برای
بهینه سازی حالت انتقال با توجه به شرایط کانال و/یا کاربر
الزامات) و برای تغییر دستی از اسکریپت شبیه سازی. در مورد دوم،
سوئیچینگ را می توان مطابق شکل زیر انجام داد:

Ptr lteEnbDev = enbDevs.Get (0)->GetObject ();
PointerValue ptrval;
enbNetDev->GetAttribute ("FfMacScheduler"، ptrval)؛
Ptr rrsched = ptrval.Get ();
شبیه ساز::Schedule (ثانیه (0.2)، &RrFfMacScheduler::TransmissionModeConfigurationUpdate، rrsched، rnti، 1);

در نهایت، مدل پیاده سازی شده را می توان با توجه به مدل های مختلف MIMO توسط
به روز رسانی مقادیر بهره (تنها محدودیت این است که بهره باید در طول مدت ثابت باشد
شبیه سازی زمان اجرا و رایج برای لایه ها). سود هر حالت انتقال می تواند باشد
مطابق با سیستم ویژگی استاندارد ns3 تغییر کرده است، که در آن ویژگی ها عبارتند از:
TxMode1Gain, TxMode2Gain, TxMode3Gain, TxMode4Gain, TxMode5Gain, TxMode6Gain و
TxMode7Gain. فقط به صورت پیش فرض TxMode1Gain, TxMode2Gain و TxMode3Gain معنی دار داشتن
مقدار، آنهایی هستند که توسط _[CatreuxMIMO] به دست می آیند (یعنی به ترتیب 0.0، 4.2 و 2.8-
دسی بل).

استفاده کنید of آنتن مدل
اکنون نشان می دهیم که چگونه یک AntennaModel خاص را با یک دستگاه eNB به منظور مدل سازی a مرتبط می کنیم
بخش یک eNB کلان برای این منظور، استفاده از آن راحت است CosineAntennaModel
ارائه شده توسط ماژول آنتن ns-3. پیکربندی eNB باید از طریق انجام شود
LteHelper به عنوان مثال درست قبل از ایجاد EnbNetDevice، همانطور که در نشان داده شده است
زیر است:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute ("Orientation"، DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("Beamwidth"، DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute ("MaxGain"، DoubleValue (0.0));

کد بالا یک مدل آنتن با عرض پرتو 60 درجه ایجاد می کند
محور X جهت گیری بر حسب درجه از محور X اندازه گیری می شود، به عنوان مثال، یک جهت
از 90 در امتداد محور Y و جهت گیری 90- به سمت منفی است
جهت در امتداد محور Y. پهنای پرتو 3-dB پهنای پرتو است، به عنوان مثال، برای 60 درجه
افزایش پهنای پرتو آنتن در زاویه m
30 درجه از جهت جهت گیری -3 دسی بل است.

برای ایجاد یک سایت چندبخشی، باید گره های مختلف ns-3 که در یک جا قرار گرفته اند ایجاد کنید
موقعیت، و برای پیکربندی جداگانه EnbNetDevice با جهت گیری آنتن های مختلف باشد
بر روی هر گره نصب شده است.

رادیو محیط نقشه ها
با استفاده از کلاس RadioEnvironmentMapHelper خروجی یک رادیو به یک فایل امکان پذیر است
نقشه محیطی (REM)، به عنوان مثال، یک شبکه دو بعدی یکنواخت از مقادیر که نشان دهنده
نسبت سیگنال به نویز در downlink نسبت به eNB که قوی‌ترین را دارد
سیگنال در هر نقطه می توان مشخص کرد که آیا REM باید برای داده ها تولید شود یا خیر
کانال کنترل همچنین کاربر می تواند RbId را تنظیم کند که REM برای آن تولید خواهد شد. RbId پیش فرض
1- است، به این معنی که REM با نسبت سیگنال به نویز متوسط ​​از همه تولید می شود.
RBs.

برای این کار کافیست کد زیر را به برنامه شبیه سازی خود اضافه کنید
پایان، درست قبل از تماس با Simulator::Run ():

Ptr remHelper = CreateObject ();
remHelper->SetAttribute ("ChannelPath"، StringValue ("/ChannelList/0"));
remHelper->SetAttribute ("OutputFile"، StringValue ("rem.out"));
remHelper->SetAttribute ("XMin"، DoubleValue (-400.0));
remHelper->SetAttribute ("XMax"، DoubleValue (400.0));
remHelper->SetAttribute ("XRes"، UintegerValue (100));
remHelper->SetAttribute ("YMin"، DoubleValue (-300.0));
remHelper->SetAttribute ("YMax"، DoubleValue (300.0));
remHelper->SetAttribute ("YRes"، UintegerValue (75));
remHelper->SetAttribute ("Z"، DoubleValue (0.0));
remHelper->SetAttribute ("UseDataChannel"، BooleanValue (true));
remHelper->SetAttribute ("RbId"، IntegerValue (10));
remHelper->Install ();

با پیکربندی ویژگی های RadioEnvironmentMapHelper همانطور که در بالا نشان داده شده است، شما
می تواند پارامترهای REM تولید شده را تنظیم کند. توجه داشته باشید که هر کدام
RadioEnvironmentMapHelper نمونه می تواند تنها یک REM تولید کند. اگر می خواهید بیشتر تولید کنید
REM ها، شما باید یک نمونه جداگانه برای هر REM ایجاد کنید.

توجه داشته باشید که نسل REM بسیار خواستار است، به ویژه:

· مصرف حافظه زمان اجرا تقریباً 5 کیلوبایت در هر پیکسل است. به عنوان مثال، یک REM
با رزولوشن 500x500 به حدود 1.25 گیگابایت حافظه و وضوح تصویر نیاز دارد.
1000x1000 به حدود 5 گیگابایت نیاز دارد (در این زمان برای یک کامپیوتر معمولی خیلی زیاد است
نوشتن). برای غلبه بر این مشکل، REM در مراحل متوالی، با هر مرحله تولید می‌شود
مرحله ارزیابی حداکثر تعداد پیکسل های تعیین شده توسط مقدار the
صفت RadioEnvironmentMapHelper::MaxPointsPerIteration.

· اگر REM را در ابتدای شبیه سازی ایجاد کنید، سرعت آن را کاهش می دهد
اجرای بقیه شبیه سازی اگر می خواهید یک REM برای یک برنامه تولید کنید
و همچنین با استفاده از همین برنامه برای به دست آوردن نتیجه شبیه سازی پیشنهاد می شود a اضافه کنید
سوئیچ خط فرمان که امکان تولید REM یا اجرای کامل را فراهم می کند
شبیه سازی. برای این منظور توجه داشته باشید که یک ویژگی وجود دارد
RadioEnvironmentMapHelper::StopWhenDone (پیش فرض: درست) که باعث می شود
شبیه سازی بلافاصله پس از تولید REM متوقف می شود.

REM در یک فایل ASCII با فرمت زیر ذخیره می شود:

· ستون 1 مختصات x است

· ستون 2 مختصات y است

· ستون 3 مختصات z است

· ستون 4 SINR در واحدهای خطی است

حداقل اسکریپت gnuplot که به شما امکان می دهد REM را رسم کنید در زیر آورده شده است:

تنظیم نقشه نمایش;
برچسب x را تنظیم کنید "X"
ylabel "y" را تنظیم کنید
تنظیم cblabel "SINR (dB)"
کلید تنظیم نشده
رسم "rem.out" با استفاده از ($1):($2):(10*log10($4)) با تصویر

به عنوان مثال، در اینجا REM است که می توان با برنامه مثال به دست آورد
lena-dual-stripe، که یک ماکروسل LTE سه بخش را در یک استقرار کانال مشترک با
برخی از فمتوسل های مسکونی به طور تصادفی در دو بلوک آپارتمان مستقر شده اند.
[تصویر] REM به دست آمده از مثال lena-dual-stripe.UNINDENT

توجه داشته باشید که برنامه نمونه lena-dual-stripe نیز خروجی سازگار با gnuplot تولید می کند
فایل های حاوی اطلاعاتی در مورد موقعیت گره های UE و eNB و همچنین
ساختمان ها به ترتیب در پرونده ها ues.txt, enbs.txt و buildings.txt. اینها می توانند
هنگام استفاده از gnuplot به راحتی گنجانده شود. به عنوان مثال، با فرض اینکه اسکریپت gnuplot شما
(به عنوان مثال، حداقل اسکریپت gnuplot که در بالا توضیح داده شد) در فایلی به نام ذخیره می شود
my_plot_script، اجرای دستور زیر مکان UE ها، eNB ها و را رسم می کند
ساختمان های بالای REM:

gnuplot -p enbs.txt ues.txt buildings.txt my_plot_script

AMC مدل و CQI محاسبه
شبیه ساز دو طرح ممکن را برای آنچه مربوط به انتخاب MCS است ارائه می دهد
و به تبع آن تولید CQIها. اولین مورد بر اساس ماژول GSoC است
[Piro2011] و بر اساس RB کار می کند. این مدل را می توان با ویژگی ns3 فعال کرد
سیستم، همانطور که در زیر ارائه شده است:

پیکربندی::SetDefault ("ns3::LteAmc::AmcModel"، EnumValue (LteAmc::PiroEW2010));

در حالی که، راه حل مبتنی بر مدل خطای فیزیکی را می توان با موارد زیر کنترل کرد:

پیکربندی::SetDefault ("ns3::LteAmc::AmcModel"، EnumValue (LteAmc::MiErrorModel));

در نهایت، کارایی مورد نیاز از PiroEW2010 ماژول AMC را می توان به لطف تنظیم کرد
بر ویژگی () به عنوان مثال:

پیکربندی::SetDefault ("ns3::LteAmc::Ber"، DoubleValue (0.00005));

تکامل بسته هسته (EPC)
اکنون نحوه نوشتن یک برنامه شبیه سازی را توضیح می دهیم که امکان شبیه سازی EPC را در آن فراهم می کند
علاوه بر شبکه دسترسی رادیویی LTE. استفاده از EPC امکان استفاده از شبکه IPv4 را فراهم می کند
با دستگاه های LTE به عبارت دیگر، شما قادر خواهید بود از برنامه های معمولی ns-3 استفاده کنید
و سوکت ها از طریق IPv4 از طریق LTE، و همچنین برای اتصال یک شبکه LTE به هر IPv4 دیگری
شبکه ای که ممکن است در شبیه سازی خود داشته باشید.

اول از همه، علاوه بر LteHelper که قبلا معرفی کردیم اساسی شبیه سازی
برنامه، باید از یک اضافی استفاده کنید EpcHelper کلاس، که از ایجاد مراقبت خواهد کرد
موجودیت های EPC و توپولوژی شبکه توجه داشته باشید که نمی توانید استفاده کنید EpcHelper به طور مستقیم ، همانطور که
یک کلاس پایه انتزاعی است. در عوض، باید از یکی از کلاس های فرزند آن استفاده کنید، که
پیاده سازی توپولوژی EPC مختلف را ارائه می دهد. در این مثال به بررسی خواهیم پرداخت
PointToPointEpcHelper، که یک EPC را بر اساس پیوندهای نقطه به نقطه پیاده سازی می کند. برای استفاده از آن،
ابتدا باید این کد را در برنامه شبیه سازی خود وارد کنید:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreateObject ();

سپس، باید به کمک کننده LTE بگویید که EPC استفاده خواهد شد:

lteHelper->SetEpcHelper (epcHelper);

مرحله فوق ضروری است تا کمک کننده LTE EPC مناسب را راه اندازی کند
پیکربندی مطابق با برخی از پیکربندی های مهم، مانند زمانی که یک eNB جدید
یا UE به شبیه سازی اضافه می شود یا حامل EPS ایجاد می شود. کمک کننده EPC خواهد کرد
به طور خودکار از تنظیمات لازم مانند ایجاد پیوند S1 و حامل S1 مراقبت می کند
برپایی. همه اینها بدون دخالت کاربر انجام خواهد شد.

صدا زدن lteHelper->SetEpcHelper (epcHelper) استفاده از EPC را امکان پذیر می کند و دارای سمت است
اثر که هر جدید LteEnbrRrc که ایجاد می شود خواهد داشت EpsBearerToRlcMapping
صفت تنظیم شده است RLC_UM_ALWAYS بجای RLC_SM_ALWAYS اگر دومی پیش فرض بود.
در غیر این صورت، ویژگی تغییر نخواهد کرد (به عنوان مثال، اگر پیش فرض را به
RLC_AM_ALWAYS، لمس نمی شود).

لازم به ذکر است که EpcHelper همچنین به طور خودکار گره PGW را ایجاد می کند و
آن را طوری پیکربندی کنید که بتواند ترافیک از/به شبکه دسترسی رادیویی LTE را به درستی مدیریت کند.
با این حال، برای اتصال PGW به سایر شبکه‌های IPv4 (به عنوان مثال:
اینترنت). در اینجا یک مثال بسیار ساده در مورد نحوه اتصال یک هاست از راه دور به تنهایی آورده شده است
PGW از طریق پیوند نقطه به نقطه:

Ptr pgw = epcHelper->GetPgwNode ();

// یک RemoteHost واحد ایجاد کنید
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr remoteHost = remoteHostContainer.Get (0);
InternetStackHelper اینترنت؛
internet.Install (remoteHostContainer)؛

// اینترنت را ایجاد کنید
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate"، DataRateValue (DataRate ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu"، UintegerValue (1500));
p2ph.SetChannelAttribute ("تاخیر"، TimeValue (ثانیه (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);
// رابط 0 لوکال هاست است، 1 دستگاه p2p است
Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);

مهم است که مسیرها را مشخص کنید تا میزبان راه دور بتواند به UE های LTE برسد. یکی از راه های
انجام این کار با بهره برداری از این واقعیت است که PointToPointEpcHelper به طور پیش فرض اختصاص خواهد داد
به LTE UE یک آدرس IP در شبکه 7.0.0.0. با در نظر گرفتن این موضوع، انجام این کار کافی است:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0")، Ipv4Mask ("255.0.0.0")، 1);

اکنون، باید ادامه دهید و همانطور که در بخش‌های قبلی توضیح داده شد، LTE eNB و UE ایجاد کنید.
البته می‌توانید سایر جنبه‌های LTE مانند مدل‌های گذرا و محو شدن را پیکربندی کنید. درست
پس از ایجاد UE ها، باید آنها را برای شبکه IP نیز پیکربندی کنید. این کار انجام می شود
به شرح زیر است. ما فرض می کنیم که شما یک محفظه برای گره های UE و eNodeB مانند این دارید:

NodeContainer ueNodes;
NodeContainer enbNodes;

برای پیکربندی یک شبیه‌سازی فقط LTE، معمولاً کاری شبیه به این انجام می‌دهید:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Attach (ueLteDevs, enbLteDevs.Get (0));

برای پیکربندی UE ها برای شبکه IP، فقط باید لایک کنید
این:

// پشته IP را روی UE ها نصب می کنیم
InternetStackHelper اینترنت؛
internet.Install (ueNodes)؛

// آدرس IP را به UE ها اختصاص دهید
برای (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 تنظیم کنید
Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress ()، 1);
}

فعال سازی حامل ها به روشی کمی متفاوت با آنچه انجام شده است انجام می شود
برای یک شبیه سازی فقط LTE. اول، روش ActivateDataRadioBearer استفاده نمی شود
هنگامی که EPC استفاده می شود. دوم، هنگامی که EPC استفاده می شود، حامل EPS پیش فرض فعال می شود
هنگامی که LteHelper::Attach () را فرا می خوانید به طور خودکار. سوم، اگر می‌خواهید تنظیمات اختصاصی را تنظیم کنید
حامل EPS، می توانید این کار را با استفاده از روش LteHelper::ActivateDedicatedEpsBearer () انجام دهید. این
متد الگوی جریان ترافیک (TFT) را به عنوان پارامتر می گیرد، که ساختاری است که
نوع ترافیکی را که به حامل EPS اختصاصی نگاشت می شود، شناسایی می کند. اینجا یک است
مثالی برای چگونگی راه اندازی یک حامل اختصاصی برای یک برنامه کاربردی در ارتباط با UE
پورت 1234:

Ptr tft = ایجاد ();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->افزودن (pf)؛
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs، EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT)، tft);

البته می‌توانید از پیکربندی‌های سفارشی EpsBearer و EpcTft استفاده کنید، لطفاً به ادامه مطلب مراجعه کنید
مستندات داکسیژن برای نحوه انجام آن.

در نهایت، می توانید برنامه هایی را روی گره های LTE UE نصب کنید که با ریموت ارتباط برقرار می کنند
برنامه های کاربردی از طریق اینترنت این کار طبق رویه های معمول ns-3 انجام می شود.
به دنبال مثال ساده ما با یک RemoteHost، در اینجا نحوه تنظیم downlink آورده شده است
ارتباط، با یک برنامه UdpClient در میزبان راه دور، و یک PacketSink در
LTE UE (با استفاده از همان نام متغیرهای کد قبلی)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory"،
InetSocketAddress (Ipv4Address::GetAny ()، dlPort));
ApplicationContainer serverApps = packetSinkHelper.Install (ue);
serverApps.Start (ثانیه (0.01))؛
سرویس گیرنده UdpClientHelper (ueIpIface.GetAddress (0)، dlPort)؛
ApplicationContainer clientApps = client.Install (remoteHost);
clientApps.Start (ثانیه (0.01));

همین! اکنون می توانید شبیه سازی خود را طبق معمول شروع کنید:

شبیه ساز::توقف (ثانیه (10.0))؛
شبیه ساز::Run ();

با استفاده از la EPC با شبیه سازی حالت
در بخش قبل از پیوندهای PointToPoint برای ارتباط بین eNB و
SGW (رابط S1-U) و در میان eNBها (رابط X2-U و X2-C). ماژول LTE
از استفاده از پیوندهای شبیه سازی شده به جای پیوندهای PointToPoint پشتیبانی می کند. این با فقط به دست می آید
جایگزینی ایجاد LteHelper و EpcHelper با کد زیر:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreateObject ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Initialize ();

صفات ns3::EmuEpcHelper::sgwDeviceName و ns3::EmuEpcHelper::enbDeviceName هستند
برای تنظیم نام دستگاه های مورد استفاده برای حمل و نقل S1-U، X2-U و X2-C استفاده می شود
اینترفیس ها به ترتیب در SGW و eNB. اکنون نشان خواهیم داد که چگونه این کار در یک انجام می شود
مثالی که در آن برنامه نمونه را اجرا می کنیم lena-simple-epc-emu با استفاده از دو مجازی
رابط های اترنت

اول از همه ما ns-3 را به طور مناسب می سازیم:

# پیکربندی
./waf configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# ساختن
./ واف

سپس دو رابط اترنت مجازی را راه اندازی می کنیم و wireshark را برای بررسی ترافیک راه اندازی می کنیم
عبور از:

# نکته: باید روت باشید

# دو دستگاه veth جفتی ایجاد کنید
لینک آی پی اضافه کردن نام veth0 نوع veth نام همتا veth1
نمایش لینک IP

# حالت غیرقانونی را فعال کنید
لینک آی پی veth0 promisc را روشن کرد
لینک آی پی veth1 promisc را روشن کرد

# رابط ها را بالا بیاورید
لینک آی پی veth0 را تنظیم کرد
لینک آی پی veth1 را تنظیم کرد

# wireshark را شروع کنید و روی veth0 عکس بگیرید
سیم کش و

اکنون می توانیم برنامه مثال را با ساعت شبیه سازی شده اجرا کنیم:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

با استفاده از wireshark، ابتدا باید وضوح ARP را ببینید، سپس برخی از بسته های GTP هر دو را مبادله می کنند
در uplink و downlink.

تنظیم پیش فرض برنامه نمونه 1 eNB و 1UE است. می توانید این را از طریق تغییر دهید
پارامترهای خط فرمان، به عنوان مثال:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

برای به دست آوردن لیستی از پارامترهای موجود:

./waf --run lena-simple-epc-emu --command="%s --PrintHelp"

برای اجرا با ساعت بیدرنگ: معلوم می شود که ساخت اشکال زدایی پیش فرض برای آن خیلی کند است
به موقع. نرم کردن محدودیت های زمان واقعی با حالت BestEffort ایده خوبی نیست:
ممکن است مشکلی پیش بیاید (به عنوان مثال، ARP ممکن است شکست بخورد) و اگر چنین است، هیچ بسته داده ای دریافت نخواهید کرد.
بیرون بنابراین شما به یک سخت افزار مناسب و ساخت بهینه شده با پیوند استاتیک نیاز دارید
ماژول ها:

./waf configure -d بهینه شده --enable-static --enable-modules=lte --enable-examples --enable-sudo

سپس برنامه نمونه را به صورت زیر اجرا کنید:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::Rempltime --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

به تنظیمات HardLimit توجه کنید، که باعث می شود برنامه در صورت عدم ادامه کار، خاتمه یابد
با زمان واقعی

روش توضیح داده شده در این بخش را می توان با هر نوع دستگاه شبکه استفاده کرد. برای
به عنوان مثال، [Baldo2014] چگونگی استفاده از آن برای اجرای یک شبکه LTE-EPC شبیه سازی شده را توضیح می دهد.
شبکه حمل و نقل بسته-اپتیکال چند لایه واقعی.

شبکه ارتباطی ضمیمه
همانطور که در مثال اصلی در بخش نشان داده شده است اساسی شبیه سازی برنامه، وصل کردن یک UE به an
eNodeB با فراخوانی انجام می شود LteHelper::پیوست تابع.

2 راه ممکن برای اتصال به شبکه وجود دارد. روش اول این است "کتابچه راهنمای" یکی،
در حالی که دومی بیشتر دارد "اتوماتیک" در آن احساس کنید هر یک از آنها پوشش داده خواهد شد
این بخش.

دستی ضمیمه
این روش از LteHelper::پیوست عملکرد ذکر شده در بالا تنها بوده است
روش پیوست شبکه موجود در نسخه های قبلی ماژول LTE. به طور معمول است
قبل از شروع شبیه سازی فراخوانی می شود:

lteHelper->Attach (ueDevs، enbDev)؛ // یک یا چند UE را به یک eNodeB متصل کنید

LteHelper::InstallEnbDevice و LteHelper::InstallUeDevice توابع باید فراخوانی شده باشند
قبل از پیوست کردن در شبیه سازی EPC-enabled، داشتن IPv4 به درستی نیز الزامی است
از پیش نصب شده در UE.

این روش بسیار ساده است، اما باید بدانید که دقیقاً کدام UE متعلق به کدام است
eNodeB قبل از شروع شبیه سازی. وقتی موقعیت اولیه UE باشد، این می تواند دشوار باشد
به طور تصادفی توسط اسکریپت شبیه سازی تعیین می شود.

می توان فاصله بین UE و eNodeB را به عنوان معیاری برای انتخاب انتخاب کرد
سلول مناسب بسیار ساده است (حداقل از نظر شبیه ساز) و
گاهی اوقات عملی اما توجه به این نکته ضروری است که گاهی فاصله باعث نمی شود
تنها معیار صحیح به عنوان مثال، جهت دهی آنتن eNodeB باید باشد
نیز در نظر گرفته شده است. علاوه بر این، باید شرایط کانال را نیز در نظر گرفت،
که ممکن است در صورت وجود محو شدن یا سایه زدن در نوسان باشد. در این نوع
در موارد، پیوست شبکه نباید تنها بر اساس فاصله باشد.

در زندگی واقعی، UE به طور خودکار معیارهای خاصی را ارزیابی می کند و بهترین سلول را برای آن انتخاب می کند
بدون دخالت دستی کاربر، به آن متصل شود. بدیهی است که در این مورد چنین نیست
این LteHelper::پیوست تابع. روش دیگر پیوست شبکه بیشتر استفاده می کند "اتوماتیک"
رویکرد اتصال به شبکه، همانطور که در ادامه توضیح داده خواهد شد.

اتوماتیک ضمیمه با استفاده از آرام حالت سلول انتخاب روش
قدرت سیگنال دریافتی معیار استانداردی است که برای انتخاب بهترین مورد استفاده قرار می گیرد
سلول برای اتصال استفاده از این معیار در اول سلول انتخاب
فرآیند، که می تواند با فراخوانی نسخه دیگری از آن فراخوانی شود LteHelper::پیوست
عملکرد، همانطور که در زیر نشان داده شده است:

lteHelper->Attach (ueDevs)؛ // یک یا چند UE را به قوی ترین سلول متصل کنید

تفاوت با روش دستی این است که eNodeB مقصد مشخص نشده است. این
رویه بهترین سلول را برای UE ها بر اساس معیارهای متعددی از جمله
قدرت سیگنال دریافتی (RSRP).

پس از فراخوانی متد، UE مدتی را صرف اندازه گیری سلول های همسایه می کند.
و سپس سعی کنید به بهترین مورد متصل شوید. جزئیات بیشتر را می توان در بخش یافت
sec-initial-cell-selection of Design Documentation.

ذکر این نکته ضروری است که این روش فقط در شبیه سازی های دارای EPC کار می کند. فقط LTE
شبیه سازی ها باید به روش پیوست دستی متوسل شوند.

تعطیل مشترک گروه
یک مورد استفاده جالب از فرآیند انتخاب سلول اولیه، راه اندازی یک شبیه سازی است
محیط با گروه مشترکین بسته (CSG).

به عنوان مثال، یک eNodeB خاص، معمولاً یک نسخه کوچکتر مانند femtocell، ممکن است متعلق باشد
به یک مالک خصوصی (مثلاً یک خانواده یا کسب و کار)، اجازه دسترسی فقط به برخی از UE ها را می دهد که
قبلاً توسط مالک ثبت شده است. eNodeB و UE های ثبت شده در مجموع
یک CSG تشکیل دهید.

محدودیت دسترسی را می توان با "برچسب گذاری" اعضای CSG با همان CSG شبیه سازی کرد
شناسه. این کار از طریق ویژگی ها در eNodeB و UE انجام می شود، برای مثال با استفاده از
پیروی LteHelper کارکرد:

// eNodeB های زیر را با هویت CSG 1 و نشانگر CSG فعال کنید
lteHelper->SetEnbDeviceAttribute ("CsgId"، UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication"، BooleanValue (true));

// یک یا چند UE را با هویت CSG 1 برچسب گذاری کنید
lteHelper->SetUeDeviceAttribute ("CsgId"، UintegerValue (1));

// eNodeBs و UE ها را نصب کنید
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

سپس رویه انتخاب سلول اولیه را در UE ها فعال کنید:

lteHelper->Attach (csgUeDevs)؛

این امر ضروری است زیرا محدودیت CSG فقط با روش خودکار شبکه کار می کند
پیوست، اما نه به روش دستی.

توجه داشته باشید که تنظیم نشانگر CSG یک eNodeB به عنوان نادرست (مقدار پیش‌فرض) خواهد بود
محدودیت را غیرفعال کنید، یعنی هر UE می تواند به این eNodeB متصل شود.

مجموعه UE اندازه گیری
پیکربندی اندازه‌گیری UE فعال در یک شبیه‌سازی توسط انتخاب شده دیکته می‌شود
به نام "مصرف کنندگان"، مانند الگوریتم تحویل. کاربران ممکن است پیکربندی خود را به آن اضافه کنند
اقدام، و چندین راه برای انجام آن وجود دارد:

1. پیکربندی مستقیم در موجودیت eNodeB RRC.

2. پیکربندی الگوریتم تحویل موجود. و

3. توسعه یک الگوریتم انتقال جدید.

این بخش فقط روش اول را پوشش می دهد. روش دوم در پوشش داده شده است اتوماتیک
تحویل دادن ماشه، در حالی که روش سوم به طور مفصل در بخش توضیح داده شده است
الگوریتم تحویل-ثانیه اسناد طراحی.

پیکربندی مستقیم در eNodeB RRC به صورت زیر عمل می کند. کاربر با ایجاد یک جدید شروع می کند
LterRrcSap::ReportConfigEutra نمونه و انتقال آن به LteEnbRrc::AddUeMeasReportConfig
تابع. تابع را برمی گرداند measId (هویت اندازه گیری) که منحصر به فرد است
مرجع پیکربندی در نمونه eNodeB. این تابع باید قبل از آن فراخوانی شود
شبیه سازی شروع می شود پیکربندی اندازه گیری در تمام UE های متصل به آن فعال خواهد بود
eNodeB در طول مدت شبیه سازی. در طول شبیه سازی، کاربر می تواند
گزارش های اندازه گیری تولید شده توسط UE ها را با گوش دادن به موارد موجود ضبط کنید
LteEnbRrc::RecvMeasurementReport منبع ردیابی

ساختار ReportConfigEutra مطابق با مشخصات 3GPP است. تعریف از
ساختار و هر فیلد عضو را می توان در بخش 6.3.5 [TS36331] یافت.

نمونه کد زیر اندازه گیری RSRP رویداد A1 را برای هر eNodeB در داخل پیکربندی می کند
ظرف توسعه دهندگان:

LterRrcSap::ReportConfigEutra config;
config.eventId = LteRrcSap::ReportConfigEutra::EVENT_A1;
config.threshold1.choice = LteRrcSap::ThresholdEutra::THRESHOLD_RSRP;
config.threshold1.range = 41;
config.triggerQuantity = LteRrcSap::ReportConfigEutra::RSRP;
config.reportInterval = LteRrcSap::ReportConfigEutra::MS480;

std::vector measIdList;

NetDeviceContainer::Iterator it;
برای (it = devs.Begin (); it != devs.End (); it++)
{
Ptr dev = *it;
Ptr enbDev = dev->GetObject ();
ptr enbrrc = enbdev-> getrrc () ؛

uint8_t measId = enbRrc->AddUeMeasReportConfig (پیکربندی);
measIdList.push_back (measId); // measId ایجاد شده را به خاطر بسپار

enbRrc->TraceConnect ("RecvMeasurementReport"،
"متن نوشته"،
MakeCallback (&RecvMeasurementReportCallback));
}

توجه داشته باشید که آستانه ها به صورت محدوده بیان می شوند. در مثال بالا، محدوده 41 برای RSRP
مربوط به -100 dBm است. تبدیل از و به فرمت محدوده به دلیل بخش است
9.1.4 و 9.1.7 از [TS36133]. این EutranMeasurementMapping کلاس چندین استاتیک دارد
توابعی که می توان برای این منظور استفاده کرد.

تابع callback مربوطه تعریفی مشابه زیر خواهد داشت:

از درجه اعتبار ساقط
RecvMeasurementReportCallback (std:: زمینه رشته،
uint64_t imsi،
uint16_t cellId،
uint16_t rnti،
LteRrcSap::MeasurementReport measReport);

این روش تابع فراخوانی را به عنوان مصرف کننده اندازه گیری های UE ثبت می کند. در
در موردی که بیش از یک مصرف کننده در شبیه سازی وجود دارد (به عنوان مثال الگوریتم انتقال)،
اندازه گیری های در نظر گرفته شده برای سایر مصرف کنندگان نیز توسط این تماس گرفته می شود
تابع. کاربران ممکن است از the استفاده کنند measId زمینه، موجود در
LteRrcSap::MeasurementReport آرگومان تابع callback، برای تشخیص کدام اندازه گیری
پیکربندی باعث شده است که گزارش.

به طور کلی، این مکانیسم از دخالت ناآگاهانه یک مصرف کننده با دیگری جلوگیری می کند
پیکربندی گزارش مصرف کننده

توجه داشته باشید که فقط قسمت پیکربندی گزارش (یعنی LterRrcSap::ReportConfigEutra) از
پارامتر اندازه گیری UE برای پیکربندی مصرف کنندگان باز است، در حالی که سایر قسمت ها
پنهان نگه داشته می شوند. محدودیت درون فرکانس انگیزه اصلی این API است
تصمیم اجرایی:

· تنها یکی وجود دارد، بدون ابهام و قطعی اندازه گیری هدف، بنابراین وجود ندارد
نیاز به پیکربندی آن؛

· اندازه گیری هویت ها به دلیل این واقعیت که یک به یک وجود دارد، پنهان نگه داشته می شوند
نقشه برداری بین پیکربندی گزارش و هویت اندازه گیری، بنابراین جدید است
هنگامی که پیکربندی گزارش جدید وجود دارد، هویت اندازه گیری به طور خودکار تنظیم می شود
ایجاد شده؛

· مقدار پیکر بندی در جای دیگری پیکربندی شده است، به sec-performing-mesurements مراجعه کنید. و

· اندازه گیری شکاف پشتیبانی نمی شوند، زیرا فقط برای فرکانس های بین فرکانس قابل استفاده است
تنظیمات؛

مبتنی بر X2 تحویل دادن
همانطور که توسط 3GPP تعریف شده است، تحویل روشی برای تغییر سلول سرویس دهنده یک UE در است
حالت متصل دو eNodeB درگیر در فرآیند معمولاً نامیده می شوند منبع
eNodeB و هدف eNodeB.

به منظور فعال کردن اجرای تحویل مبتنی بر X2 در شبیه سازی، دو مورد وجود دارد
الزاماتی که باید برآورده شوند. در مرحله اول، EPC باید در شبیه سازی فعال شود (نگاه کنید به تکامل
بسته هسته (EPC)).

ثانیا، یک رابط X2 باید بین دو eNodeB پیکربندی شود، که باید انجام شود
به صراحت در برنامه شبیه سازی انجام شده است:

lteHelper->AddX2Interface (enbNodes)؛

جایی که enbNodes هست یک NodeContainer که شامل دو eNodeB است که X2 بین آنها قرار دارد
رابط قرار است پیکربندی شود. اگر ظرف بیش از دو eNodeB داشته باشد، تابع
یک رابط X2 بین هر جفت eNodeB در کانتینر ایجاد می کند.

در نهایت، eNodeB هدف باید به عنوان "باز" ​​به X2 HANDOVER REQUEST پیکربندی شود. هر
eNodeB به طور پیش فرض باز است، بنابراین در بیشتر موارد به هیچ دستورالعمل اضافی نیاز نیست. با این حال، کاربران
ممکن است eNodeB را با تنظیم ویژگی بولی روی "بسته" تنظیم کند
LteEnbRrc::AdmitHandoverRequest به غلط. به عنوان مثال، می توانید اجرا کنید lena-x2-handover
برنامه ریزی کنید و ویژگی را به این صورت تنظیم کنید:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

پس از برآورده شدن سه الزام فوق، می توان روند تحویل را آغاز کرد
به صورت دستی یا خودکار هر کدام در بخش های فرعی بعدی ارائه خواهند شد.

دستی تحویل دادن ماشه
رویداد Handover را می توان به صورت دستی در برنامه شبیه سازی با زمان بندی یک راه اندازی کرد
رویداد تحویل صریح این LteHelper شی یک روش مناسب برای
برنامه ریزی یک رویداد تحویل به عنوان مثال، اجازه دهید این را فرض کنیم ueLteDevs هست یک
NetDeviceContainer که حاوی UE است که قرار است تحویل داده شود، و آن enbLteDevs is
دیگر NetDeviceContainer که حاوی منبع و eNB هدف است. سپس، یک تحویل
در 0.1s را می توان به صورت زیر برنامه ریزی کرد:

lteHelper->HandoverRequest (ثانیه (0.100)،
ueLteDevs.Get (0)،
enbLteDevs.Get (0)،
enbLteDevs.Get (1));

توجه داشته باشید که UE باید از قبل به منبع eNB متصل باشد، در غیر این صورت شبیه سازی
با یک پیغام خطا خاتمه می یابد.

برای مثال با کد منبع کامل، لطفاً به آدرس مراجعه کنید lena-x2-handover مثال
برنامه است.

اتوماتیک تحویل دادن ماشه
همچنین می‌تواند به‌طور خودکار توسط سرویس eNodeB UE راه‌اندازی شود.
منطق پشت تریگر به الگوریتم انتقالی که در حال حاضر در آن فعال است بستگی دارد
موجودیت eNodeB RRC. کاربران ممکن است الگوریتم انتقال مورد استفاده را انتخاب و پیکربندی کنند
در شبیه سازی که به زودی در این قسمت توضیح داده خواهد شد. کاربران همچنین ممکن است انتخاب کنند
پیاده سازی الگوریتم انتقال خود را همانطور که در بخش توضیح داده شده است بنویسید
الگوریتم تحویل-ثانیه اسناد طراحی.

انتخاب الگوریتم انتقال از طریق LteHelper شی و آن
SetHandoverAlgorithmType روشی که در زیر نشان داده شده است:

Ptr lteHelper = CreateObject ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

الگوریتم انتقال انتخابی ممکن است چندین ویژگی قابل تنظیم را نیز ارائه دهد که
را می توان به صورت زیر تنظیم کرد:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold"،
UintegerValue (30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset"،
UintegerValue (1));

سه گزینه از الگوریتم انتقال در ماژول LTE گنجانده شده است. این A2-A4-RSRQ
الگوریتم انتقال (با نام ns3::الگوریتم A2A4RsrqHandover) گزینه پیش فرض و است
استفاده قبلاً در بالا نشان داده شده است.

گزینه دیگر گزینه قوی ترین سلول الگوریتم انتقال (با نام
ns3::الگوریتم A3RsrpHandover) که با کد زیر قابل انتخاب و پیکربندی است:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("Hysteresis"،
DoubleValue (3.0))؛
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger"،
TimeValue (میلی ثانیه (256)))؛

گزینه آخر گزینه ویژه ای است ، به نام بدون اپ الگوریتم تحویل، که اساسا
ماشه تحویل خودکار را غیرفعال می کند. این برای مثال در مواردی که دستی است مفید است
ماشه تحویل به کنترل انحصاری تمام تصمیمات واگذاری نیاز دارد. هیچکدام را ندارد
ویژگی های قابل تنظیم استفاده به شرح زیر است:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

برای اطلاعات بیشتر در مورد سیاست تصمیم گیری هر الگوریتم تحویل و ویژگی های آنها،
لطفاً به زیربخش های مربوطه در بخش sec-handover-algorithm of the مراجعه کنید
مستندات طراحی

در نهایت، InstallEnbDevice عملکرد LteHelper یک نمونه از
الگوریتم انتقال انتخاب شده برای هر دستگاه eNodeB. به عبارت دیگر، حتما انتخاب کنید
الگوریتم تحویل سمت راست قبل از نهایی کردن آن در خط کد زیر:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

نمونه ای با کد منبع کامل استفاده از ماشه تحویل خودکار را می توان در قسمت پیدا کرد
lena-x2-handover-measures برنامه نمونه

میزان سازی شبیه سازی با تحویل دادن
همانطور که در مستندات طراحی ذکر شد، اجرای فعلی مدل تحویل ممکن است
هنگامی که شکست تحویل رخ می دهد، رفتار پیش بینی نشده ای ایجاد می کند. در این بخش فرعی تمرکز خواهد شد
مراحلی که کاربران در صورتی که قصد استفاده از انتقال را دارند باید در نظر گرفته شوند
شبیه سازی ها

علت اصلی شکست انتقال که ما با آن مقابله خواهیم کرد، خطا در انتقال است
پیام های سیگنالینگ مربوط به تحویل در طول اجرای یک رویه تحویل. مانند
مشهود از شکل fig-x2-based-handover-seq-diagram از مستندات طراحی،
تعداد زیادی از آنها وجود دارد و از رابط ها و پروتکل های مختلفی استفاده می کنند. به خاطر
سادگی، می توانیم با خیال راحت فرض کنیم که رابط X2 (بین منبع eNodeB و
هدف eNodeB) و رابط S1 (بین eNodeB هدف و SGW/PGW) کاملاً هستند
پایدار. بنابراین ما توجه خود را به پروتکل RRC (بین UE و
eNodeBs) و روش دسترسی تصادفی، که معمولاً از طریق هوا منتقل می شوند
و مستعد تخریب شرایط کانال است.

یک نکته کلی برای کاهش خطای انتقال این است که اطمینان حاصل شود بلند کافی SINR سطح در هر
UE. این را می توان با یک برنامه ریزی مناسب از توپولوژی شبکه انجام داد به حداقل می رساند شبکه
پوشش سوراخ. اگر توپولوژی دارای یک حفره پوشش شناخته شده باشد، UE باید پیکربندی شود
به آن منطقه جسارت نکنیم

رویکرد دیگری که باید در نظر داشت این است که اجتناب از خیلی دیر واگذاری ها. به عبارت دیگر، واگذاری
باید قبل از اینکه SINR UE خیلی کم شود اتفاق بیفتد، در غیر این صورت ممکن است UE نتواند دریافت کند
دستور تحویل از منبع eNodeB. الگوریتم های انتقال ابزاری برای کنترل دارند
چقدر زود یا دیر تصمیم تحویل گرفته می شود. به عنوان مثال، الگوریتم انتقال A2-A4-RSRQ
را می توان با یک آستانه بالاتر پیکربندی کرد تا تصمیم گیری برای تحویل زودتر بگیرد. به همین ترتیب،
پسماند کوچک‌تر و/یا زمان کوتاه‌تر برای شروع در قوی‌ترین الگوریتم انتقال سلول
معمولاً منجر به واگذاری های قبلی می شود. به منظور یافتن مقادیر مناسب برای اینها
پارامترها، یکی از عواملی که باید در نظر گرفته شود سرعت حرکت UE است.
به طور کلی، حرکت سریعتر UE مستلزم این است که تحویل زودتر اجرا شود. برخی تحقیقات
کار مقادیر توصیه شده را پیشنهاد کرده است، مانند [Lee2010].

نکات فوق باید در کاربردهای شبیه سازی معمولی کافی باشد، اما در مورد برخی موارد خاص
نیازها بوجود می آیند و می توان اقدامات شدیدی را در نظر گرفت. به عنوان مثال، کاربران
ممکن است در نظر بگیرند غیر فعال کردن la کانال خطا مدل. این تضمین می کند که همه
پیام های سیگنالینگ مربوط به انتقال بدون در نظر گرفتن با موفقیت ارسال می شوند
فاصله و وضعیت کانال با این حال، بر تمام داده ها یا کنترل های دیگر نیز تأثیر می گذارد
بسته هایی که مربوط به تحویل نیست، که ممکن است یک عارضه جانبی ناخواسته باشد. در غیر این صورت، می تواند
به شرح زیر انجام شود:

پیکربندی::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled"، BooleanValue (نادرست));
پیکربندی::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled"، BooleanValue (نادرست));

با استفاده از کد بالا مدل خطا را در هر دو کانال کنترل و داده غیرفعال می کنیم و
در هر دو جهت (downlink و uplink). این امر ضروری است زیرا مربوط به واگذاری است
پیام های سیگنالینگ با استفاده از این کانال ها منتقل می شوند. یک استثنا زمانی است که
شبیه سازی از پروتکل ایده آل RRC استفاده می کند. در این مورد، فقط رویه دسترسی تصادفی است
باقی مانده تا در نظر گرفته شود. این روش شامل پیام های کنترلی است، بنابراین ما فقط نیاز داریم
برای غیرفعال کردن مدل خطای کانال کنترل

تحویل دادن قدم به قدم
مدل RRC، به ویژه LteEnbrRrc و LteUeRrc اشیاء، ارائه برخی مفید است
ردیابی هایی که می توانند به برخی از توابع سفارشی متصل شوند تا در هنگام شروع فراخوانی شوند
و پایان مرحله اجرای تحویل در هر دو سمت UE و eNB. به عنوان مثال، در
برنامه شبیه سازی خود را می توانید روش های زیر را اعلام کنید:

از درجه اعتبار ساقط
NotifyHandoverStartUe (std:: زمینه رشته،
uint64_t imsi،
uint16_t cellId،
uint16_t rnti،
uint16_t targetCellId)
{
std::cout << شبیه ساز::اکنون ().GetSeconds () << " " << زمینه
<< " UE IMSI " << imsi
<< ": قبلاً به CellId " << cellId متصل شده است
<< " با RNTI " << rnti
<< "، در حال انتقال به CellId " << targetCellId
<< std::endl;
}

از درجه اعتبار ساقط
NotifyHandoverEndOkUe (std:: زمینه رشته،
uint64_t imsi،
uint16_t cellId،
uint16_t rnti)
{
std::cout << شبیه ساز::اکنون ().GetSeconds () << " " << زمینه
<< " UE IMSI " << imsi
<< ": تحویل موفقیت آمیز به CellId " << cellId
<< " با RNTI " << rnti
<< std::endl;
}

از درجه اعتبار ساقط
NotifyHandoverStartEnb (std:: زمینه رشته،
uint64_t imsi،
uint16_t cellId،
uint16_t rnti،
uint16_t targetCellId)
{
std::cout << شبیه ساز::اکنون ().GetSeconds () << " " << زمینه
<< " eNB CellId " << cellId
<< ": شروع تحویل UE با IMSI " << imsi
<< " RNTI " << rnti
<< " به CellId " << targetCellId
<< std::endl;
}

از درجه اعتبار ساقط
NotifyHandoverEndOkEnb (std:: زمینه رشته،
uint64_t imsi،
uint16_t cellId،
uint16_t rnti)
{
std::cout << شبیه ساز::اکنون ().GetSeconds () << " " << زمینه
<< " eNB CellId " << cellId
<< ": تحویل کامل UE با IMSI " << imsi
<< " RNTI " << rnti
<< std::endl;
}

سپس، می‌توانید این روش‌ها را به منابع ردیابی مربوطه مانند این متصل کنید:

پیکربندی:: اتصال ("/NodeList/*/DeviceList/*/LteEnbrRrc/HandoverStart"،
MakeCallback (&NotifyHandoverStartEnb))؛
پیکربندی:: اتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart"،
MakeCallback (&NotifyHandoverStartUe));
پیکربندی:: اتصال ("/NodeList/*/DeviceList/*/LteEnbrRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkEnb))؛
پیکربندی:: اتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkUe));

برنامه نمونه src/lte/examples/lena-x2-handover.cc نشان می دهد که چگونه همه بالا
دستورالعمل ها را می توان در یک برنامه شبیه سازی ادغام کرد. شما می توانید برنامه را به این صورت اجرا کنید:

./waf --اجرای lena-x2-handover

و پیام های چاپ شده توسط قلاب های ردیابی تحویل سفارشی را خروجی می دهد. به ترتیب
علاوه بر این، برخی از اطلاعات ورود معنی دار را تجسم کنید، می توانید برنامه را مانند اجرا کنید
این:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --run lena-x2-handover

فرکانس استفاده مجدد الگوریتم
در این بخش نحوه استفاده از الگوریتم‌های استفاده مجدد فرکانس در eNb در LTE را شرح خواهیم داد
شبیه سازی ها دو راه ممکن برای پیکربندی وجود دارد. اولین رویکرد این است
"دستی"، به پارامترهای بیشتری برای پیکربندی نیاز دارد، اما به کاربر اجازه می دهد تا FR را پیکربندی کند.
الگوریتمی که او نیاز دارد رویکرد دوم بیشتر "خودکار" است. بسیار راحت است،
زیرا برای هر الگوریتم FR یکسان است، بنابراین کاربر می تواند الگوریتم FR را خیلی سریع تغییر دهد
تغییر تنها نوع الگوریتم FR. یک اشکال این است که رویکرد "خودکار" فقط از آن استفاده می کند
مجموعه محدودی از پیکربندی‌ها برای هر الگوریتم، چیزی که باعث می‌شود انعطاف‌پذیری کمتری داشته باشد
برای اکثر موارد کافی است

این دو رویکرد در زیر بخش بعدی بیشتر توضیح داده خواهد شد.

اگر کاربر الگوریتم استفاده مجدد فرکانس را پیکربندی نکرد، یک الگوریتم پیش‌فرض (یعنی الگوریتم LteFrNoOp)
در eNb نصب شده است. طوری عمل می کند که انگار الگوریتم FR غیرفعال شده است.

نکته ای که باید ذکر شود این است که اکثر الگوریتم های FR پیاده سازی شده با آن کار می کنند
پهنای باند سلول بزرگتر یا مساوی از 15 RBs. این محدودیت ناشی از الزامی است که
حداقل سه RB پیوسته باید برای انتقال به UE اختصاص داده شود.

دستی پیکر بندی
الگوریتم استفاده مجدد فرکانس را می توان به صورت دستی در برنامه شبیه سازی پیکربندی کرد
تنظیم نوع الگوریتم FR و تمام ویژگی های آن. در حال حاضر، هفت الگوریتم FR هستند
اجرا شده:

· ns3::الگوریتم LteFrNoOp

· ns3::الگوریتم LteFrHard

· ns3::الگوریتم LteFrStrict

· ns3::الگوریتم LteFrSoft

· NS3 :: LTEFFRSOFTALGORITHM

· ns3::الگوریتم LteFfrEnhanced

· ns3::الگوریتم LteFfrDistributed

انتخاب یک الگوریتم FR از طریق LteHelper شی و آن SetFfrAlgorithmType
روشی که در زیر نشان داده شده است:

Ptr lteHelper = CreateObject ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

هر الگوریتم FR پیاده سازی شده چندین ویژگی قابل تنظیم را ارائه می دهد. کاربران ندارند
برای اهمیت دادن به پیکربندی پهنای باند UL و DL، زیرا به طور خودکار در طول انجام می شود
پیکربندی سلول برای تغییر پهنای باند برای الگوریتم FR، مقادیر مورد نیاز را برای آن پیکربندی کنید
LteEnbNetDevice:

uint8_t پهنای باند = 100;
lteHelper->SetEnbDeviceAttribute ("DlBandwidth"، UintegerValue (پهنای باند));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth"، UintegerValue (پهنای باند));

اکنون، هر پیکربندی الگوریتم های FR شرح داده خواهد شد.

سخت فرکانس استفاده مجدد الگوریتم
همانطور که در بخش sec-fr-hard-algorithm مستندات طراحی توضیح داده شده است
ns3::الگوریتم LteFrHard از یک زیر باند استفاده می کند. برای پیکربندی این زیر باند کاربر باید مشخص کند
افست و پهنای باند برای DL و UL بر حسب تعداد RB.

الگوریتم استفاده مجدد فرکانس سخت ویژگی های زیر را ارائه می دهد:

· DlSubBandOffset: کاهش لینک در تعداد گروه های بلوک منابع

· DlSubBandwidth: پیکربندی زیر پهنای باند انتقال لینک به تعداد
گروه های بلوک منابع

· UlSubBandOffset: Uplink Offset در تعداد گروه های بلاک منابع

· UlSubBandwidth: پیکربندی پهنای باند فرعی انتقال Uplink بر حسب تعداد منبع
مسدود کردن گروه ها

پیکربندی مثالی از الگوریتم LteFrHard را می توان به روش زیر انجام داد:

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))؛

مثال بالا به eNB اجازه می دهد فقط از RBهای 8 تا 16 در DL و UL استفاده کند، در حالی که کل سلول
پهنای باند 25 است.

سخت فرکانس استفاده مجدد الگوریتم
الگوریتم استفاده مجدد فرکانس دقیق از دو باند فرعی استفاده می کند: یکی مشترک برای هر سلول و دیگری
خصوصی. همچنین آستانه RSRQ وجود دارد که برای تصمیم گیری در UE زیر باند مورد نیاز است
باید سرو شود. علاوه بر این، انتقال نیرو در این زیر باندها می تواند متفاوت باشد.

الگوریتم استفاده مجدد فرکانس دقیق ویژگی های زیر را ارائه می دهد:

· UlCommonSubBandwidth: Uplink Common Subwidth Configuration بر حسب تعداد منبع
مسدود کردن گروه ها

· UlEdgeSubBandOffset: Uplink SubBand Edge Offset در تعدادی از Resource Block Groups

· UlEdgeSubBandwidth: پیکربندی زیربند پهنای باند لبه Uplink بر حسب تعداد منبع
مسدود کردن گروه ها

· DlCommonSubBandwidth: Downlink Common Subwidth Configuration به تعداد
گروه های بلوک منابع

· DlEdgeSubBandOffset: در تعداد گروه‌های بلوک منابع، زیر باند لبه پایین‌آمده است

· DlEdgeSubBandwidth: پیکربندی زیر پهنای باند لبه پایین بر حسب تعداد منبع
مسدود کردن گروه ها

· RsrqThreshold: اگر RSRQ از این آستانه بدتر است، UE باید در سرویس ارائه شود
زیر باند لبه

· CenterPowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند مرکزی، مقدار پیش فرض
dB0

· EdgePowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض dB0

· CenterAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه مرکزی، Absolute تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· EdgeAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه لبه تنظیم می شود، مطلق
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

مثال زیر به eNB اجازه می دهد از RB ها از 0 تا 6 به عنوان زیر باند رایج و از 12 تا 18 به عنوان استفاده کند.
زیر باند خصوصی در DL و UL، آستانه RSRQ 20 دسی بل است، قدرت در ناحیه مرکز برابر است
LteEnbPhy::TxPower - 3dB، توان در ناحیه لبه برابر است 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))؛

نرم فرکانس استفاده مجدد الگوریتم
با الگوریتم استفاده مجدد فرکانس نرم، eNb از کل پهنای باند سلول استفاده می کند، اما دو مورد وجود دارد
باندهای فرعی، در UE ها با سطوح توان متفاوت سرو می شوند.

الگوریتم استفاده مجدد فرکانس نرم ویژگی های زیر را ارائه می دهد:

· UlEdgeSubBandOffset: Uplink SubBand Edge Offset در تعدادی از Resource Block Groups

· UlEdgeSubBandwidth: پیکربندی زیربند پهنای باند لبه Uplink بر حسب تعداد منبع
مسدود کردن گروه ها

· DlEdgeSubBandOffset: در تعداد گروه‌های بلوک منابع، زیر باند لبه پایین‌آمده است

· DlEdgeSubBandwidth: پیکربندی زیر پهنای باند لبه پایین بر حسب تعداد منبع
مسدود کردن گروه ها

· AllowCenterUeUseEdgeSubBand: اگر UE های مرکز واقعی بتوانند RBG های زیر باند لبه را دریافت کنند،
در غیر این صورت زیر باند لبه فقط برای UE های لبه مجاز است، مقدار پیش فرض درست است

· RsrqThreshold: اگر RSRQ از این آستانه بدتر است، UE باید در سرویس ارائه شود
زیر باند لبه

· CenterPowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند مرکزی، مقدار پیش فرض
dB0

· EdgePowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض dB0

· CenterAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه مرکزی، Absolute تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· EdgeAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه لبه تنظیم می شود، مطلق
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

مثال زیر RB ها را از 8 تا 16 پیکربندی می کند تا توسط UE های لبه سلول استفاده شوند و این زیر باند
برای کاربران مرکز سلولی در دسترس نیست. آستانه RSRQ 20 دسی بل است، قدرت در ناحیه مرکز برابر است
LteEnbPhy::TxPower، توان در ناحیه لبه برابر است 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 (نادرست));
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))؛

نرم کسری فرکانس استفاده مجدد الگوریتم
استفاده مجدد فرکانس کسری نرم (SFFR) از سه زیر باند مرکزی، متوسط ​​(مشترک) و
حاشیه، غیرمتمرکز. کاربر باید تنها دو مورد از آنها را پیکربندی کند: مشترک و لبه. مرکز فرعی خواهد بود
از پهنای باند باقیمانده تشکیل شده است. هر زیر باند را می توان با انواع مختلف سرو کرد
قدرت انتقال از آنجایی که سه زیر باند وجود دارد، باید دو آستانه RSRQ وجود داشته باشد
پیکربندی شده است

الگوریتم استفاده مجدد فرکانس کسری نرم ویژگی های زیر را ارائه می دهد:

· UlCommonSubBandwidth: Uplink Common Subwidth Configuration بر حسب تعداد منبع
مسدود کردن گروه ها

· UlEdgeSubBandOffset: Uplink SubBand Edge Offset در تعدادی از Resource Block Groups

· UlEdgeSubBandwidth: پیکربندی زیربند پهنای باند لبه Uplink بر حسب تعداد منبع
مسدود کردن گروه ها

· DlCommonSubBandwidth: Downlink Common Subwidth Configuration به تعداد
گروه های بلوک منابع

· DlEdgeSubBandOffset: در تعداد گروه‌های بلوک منابع، زیر باند لبه پایین‌آمده است

· DlEdgeSubBandwidth: پیکربندی زیر پهنای باند لبه پایین بر حسب تعداد منبع
مسدود کردن گروه ها

· CenterRsrqThreshold: اگر RSRQ بدتر از این آستانه باشد، UE باید ارائه شود
در زیر باند متوسط

· EdgeRsrqThreshold: اگر RSRQ بدتر از این آستانه باشد، UE باید ارائه شود
در زیر باند لبه

· CenterAreaPowerOffset: PdschConfigDedicated::Pa مقدار برای زیر باند مرکزی، پیش فرض
مقدار dB0

· MediumAreaPowerOffset: PdschConfigDedicated:: مقدار Pa برای زیر باند متوسط، پیش فرض
مقدار dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض
dB0

· CenterAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه مرکزی، Absolute تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· MediumAreaTpc: مقدار TPC که در DL-DCI برای UE های ناحیه متوسط، مطلق تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· EdgeAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه لبه تنظیم می شود، مطلق
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

در مثال زیر از RB های 0 تا 6 به عنوان زیر باند معمولی (متوسط) استفاده می شود، RB ها از 6 تا
12 به عنوان زیر باند لبه و RB های 12 تا 24 به عنوان باند فرعی مرکزی استفاده می شود (آن
با RB های باقی مانده تشکیل شده است. آستانه RSRQ بین مرکز و ناحیه متوسط ​​28 دسی بل است.
آستانه RSRQ بین سطح متوسط ​​و لبه 18 دسی بل است. قدرت در ناحیه مرکز برابر است
LteEnbPhy::TxPower - 3dB، توان در ناحیه متوسط ​​برابر است LteEnbPhy::TxPower + 3dB، برق در
مساحت لبه برابر است 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))؛

پیشرفته کسری فرکانس استفاده مجدد الگوریتم
استفاده مجدد فرکانس کسری پیشرفته (EFFR) بخشی از پهنای باند سیستم را برای هر سلول ذخیره می کند
(معمولا 3 نوع سلول وجود دارد و هر کدام 1/3 پهنای باند سیستم را دریافت می کنند). سپس بخشی از
این پهنای باند فرعی به عنوان استفاده می شود اولیه بخش با فاکتور استفاده مجدد 3 و به عنوان دوم بخش
با ضریب استفاده مجدد 1. کاربر باید تعدیل پهنای باند فرعی سلول (برای DL و UL) را پیکربندی کند.
در تعداد RB، تعداد RB که به عنوان استفاده خواهد شد اولیه بخش و تعداد RB که
به عنوان استفاده خواهد شد دوم بخش. اولیه بخش توسط سلول به میل استفاده می شود، اما RBs از
دوم بخش را می توان به UE اختصاص داد فقط بازخورد CQI از این UE بالاتر است
مقدار از آستانه CQI پیکربندی شده است. UE زمانی به عنوان UE لبه در نظر گرفته می شود که RSRQ آن کمتر باشد
نسبت به RsrqThreshold.

از آنجایی که هر eNb باید بداند که در کدام سلول های اولیه و ثانویه قرار دارند، این کار را انجام خواهد داد
آنها را با فرض یکسان بودن پیکربندی برای هر سلول و تنها زیر پهنای باند محاسبه کنید
افست متفاوت است. بنابراین مهم است که پهنای باند موجود سیستم را به طور مساوی تقسیم کنیم
هر سلول و پیکربندی یکسانی از بخش های اولیه و ثانویه را برای آنها اعمال کنید.

الگوریتم استفاده مجدد فرکانس کسری پیشرفته ویژگی های زیر را ارائه می دهد:

· UlSubBandOffset: Uplink SubBand Offset برای این سلول در تعداد Block Resource
گروه ها

· UlReuse3SubBandwidth: استفاده مجدد Uplink 3 پیکربندی زیر پهنای باند بر حسب تعداد منبع
مسدود کردن گروه ها

· UlReuse1SubBandwidth: استفاده مجدد Uplink 1 پیکربندی زیر پهنای باند بر حسب تعداد منبع
مسدود کردن گروه ها

· DlSubBandOffset: Offset SubBand Downlink برای این سلول در تعداد Block Resource
گروه ها

· DlReuse3SubBandwidth: Downlink Reuse 3 پیکربندی زیر پهنای باند به تعداد
گروه های بلوک منابع

· DlReuse1SubBandwidth: Downlink Reuse 1 پیکربندی زیر پهنای باند به تعداد
گروه های بلوک منابع

· RsrqThreshold: اگر RSRQ از این آستانه بدتر است، UE باید در سرویس ارائه شود
زیر باند لبه

· CenterAreaPowerOffset: PdschConfigDedicated::Pa مقدار برای زیر باند مرکزی، پیش فرض
مقدار dB0

· EdgeAreaPowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض
dB0

· dlcqithreshold: اگر DL-CQI برای RBG از این آستانه بالاتر باشد، انتقال
در RBG امکان پذیر است

· UlCqiThreshold: اگر UL-CQI برای RBG از بالاتر از این آستانه باشد، انتقال
در RBG امکان پذیر است

· CenterAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه مرکزی، Absolute تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· EdgeAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه لبه تنظیم می شود، مطلق
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

در مثال زیر افست در DL و UL 0 RB است، 4 RB در استفاده خواهد شد اولیه بخش و
دوم بخش. آستانه RSRQ بین مرکز و ناحیه لبه 25 دسی بل است. DL و UL CQI
آستانه ها روی مقدار 10 تنظیم می شوند. قدرت در ناحیه مرکز برابر است LteEnbPhy::TxPower - 6dB,
قدرت در ناحیه لبه برابر است 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));

توزیع شده کسری فرکانس استفاده مجدد الگوریتم
استفاده مجدد فرکانس کسری توزیع شده نیاز به رابط X2 بین تمام eNB دارد
نصب شده است. رابط های X2 را می توان تنها زمانی نصب کرد که EPC پیکربندی شده باشد، بنابراین این طرح FFR
فقط با سناریوهای EPC قابل استفاده است.

با الگوریتم استفاده مجدد فرکانس کسری توزیع شده، eNb از کل پهنای باند سلول و
می تواند دو زیر باند وجود داشته باشد: زیر باند مرکزی و زیر باند لبه. در این زیر باندهای UE
را می توان با سطوح مختلف قدرت سرو کرد. الگوریتم به صورت تطبیقی ​​RB ها را برای لبه سلول انتخاب می کند
زیر باند بر اساس اطلاعات هماهنگی (به عنوان مثال RNTP) از سلول های مجاور و اطلاع می دهد
ایستگاه های پایه سلول های مجاور، که RB ها را برای استفاده در زیر باند لبه انتخاب کرد. اگر
هیچ UE طبقه بندی شده به عنوان UE لبه در سلول وجود ندارد، eNB از هیچ RB به عنوان زیر باند لبه استفاده نمی کند.

الگوریتم استفاده مجدد فرکانس کسری توزیع شده ویژگی های زیر را ارائه می دهد:

· CalculationInterval: فاصله زمانی بین محاسبه زیر باند Edge، پیش فرض
ارزش 1 ثانیه

· RsrqThreshold: اگر RSRQ از این آستانه بدتر است، UE باید در سرویس ارائه شود
زیر باند لبه

· RsrpDifferenceThreshold: اگر اختلاف بین قدرت سیگنال دریافتی
توسط UE از سلول سرویس دهنده و قدرت سیگنال دریافتی از مجاور
سلول کمتر از مقدار RsrpDifferenceThreshold است، وزن سلول افزایش می یابد

· CenterPowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض
dB0

· EdgePowerOffset: PdschConfigDedicated::مقدار Pa برای زیر باند لبه، مقدار پیش فرض dB0

· EdgeRbNum: تعداد RB قابل استفاده در زیر باند لبه

· CenterAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه مرکزی، Absolute تنظیم می شود
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

· EdgeAreaTpc: مقدار TPC که در DL-DCI برای UE ها در ناحیه لبه تنظیم می شود، مطلق
حالت استفاده می شود، مقدار پیش فرض 1 مطابق جدول 1-36.213 TS5.1.1.1 به -2 نگاشت شده است.

به عنوان مثال زیر فاصله محاسبه 500 میلی ثانیه است. آستانه RSRQ بین مرکز و لبه
مساحت 25 است. آستانه اختلاف RSRP روی 5 تنظیم شده است. در DL و UL 6 RB توسط
هر سلول در زیر باند لبه. قدرت در ناحیه مرکز برابر است LteEnbPhy::TxPower - 0dB، قدرت
در مساحت لبه برابر است LteEnbPhy::TxPower + 3dB:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrDistributedAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("CalculationInterval"، TimeValue(میلی ثانیه(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));

اتوماتیک پیکر بندی
الگوریتم‌های استفاده مجدد فرکانس را نیز می‌توان به روشی «خودکار» با تنظیم تنها پیکربندی کرد.
پهنای باند و FrCellTypeId. در طول اولیه سازی نمونه FR، پیکربندی برای
تنظیم پهنای باند و FrCellTypeId از جدول پیکربندی گرفته می شود. مهم است
که فقط باندهای فرعی پیکربندی می شوند، آستانه ها و توان انتقال روی آن تنظیم می شود
مقادیر پیش فرض. اگر کسی بخواهد، او می تواند آستانه ها و قدرت انتقال را به عنوان نمایش تغییر دهد
در بخش فرعی قبلی

سه FrCellTypeId وجود دارد: 1, 2, 3، که با سه پیکربندی مختلف مطابقت دارند
برای هر پهنای باند سه پیکربندی اجازه می دهد تا تنظیمات مختلفی را در آن داشته باشید
سلول های همسایه در طرح eNB شش ضلعی. اگر کاربر نیاز دارد که بیشتر متفاوت باشد
پیکربندی برای سلول های همسایه، او باید از پیکربندی دستی استفاده کند.

مثال زیر پیکربندی خودکار الگوریتم FR را نشان می دهد:

lteHelper->SetFfrAlgorithmType("ns3::LteFfrSoftAlgorithm");
lteHelper->SetFfrAlgorithmAttribute("FrCellTypeId", UintegerValue (1));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0))؛

بالا بردن قدرت کنترل
عملکرد Uplink Power Control به طور پیش فرض فعال است. کاربر می تواند با تنظیم آن را غیرفعال کند
ویژگی بولی ns3::LteUePhy::EnableUplinkPowerControl به حقیقت

کاربر می تواند بین مکانیسم های کنترل قدرت حلقه باز و کنترل قدرت حلقه بسته جابجا شود
با تنظیم ویژگی بولی ns3::LteUePowerControl::ClosedLoop. به طور پیش فرض بسته است
کنترل توان حلقه با حالت تجمع فعال است.

Path-loss جزء کلیدی Uplink Power Control است. به عنوان تفاوت بین محاسبه می شود
RSRP فیلتر شده و پارامتر ReferenceSignalPower. ReferenceSignalPower با SIB2 ارسال می شود.

ویژگی های موجود در Uplink Power Control:

· حلقه بسته: در صورت فعال بودن حالت کنترل قدرت حلقه بسته بالا و حلقه بسته و Open Loop
Power Control در غیر این صورت، مقدار پیش فرض نادرست است

· انباشت فعال شد: اگر حالت تجمع درست و حالت مطلق فعال باشد
در غیر این صورت، مقدار پیش فرض نادرست است

· آلفا: ضریب جبران خسارت مسیر، مقدار پیش فرض 1.0 است

· Pcmin: حداقل UE TxPower، مقدار پیش فرض -40 dBm است

· Pcmax: حداکثر UE TxPower، مقدار پیش فرض 23 dBm است

· PoNominalPusch: این پارامتر باید توسط لایه های بالاتر تنظیم شود، اما در حال حاضر نیاز است
برای پیکربندی توسط سیستم ویژگی، مقادیر ممکن اعداد صحیح در محدوده (-126 ...
24)، مقدار پیش فرض -80 است

· PoUePusch: این پارامتر باید توسط لایه های بالاتر تنظیم شود، اما در حال حاضر نیاز به تنظیم دارد
توسط سیستم ویژگی پیکربندی شود، مقادیر ممکن اعداد صحیح در محدوده (-8 ... 7) هستند.
مقدار پیش فرض 0 است

· PsrsOffset: این پارامتر باید توسط لایه های بالاتر تنظیم شود، اما در حال حاضر نیاز به تنظیم دارد
توسط سیستم ویژگی پیکربندی شود، مقادیر ممکن اعداد صحیح در محدوده (0 ... 15) هستند،
مقدار پیش فرض 7 است، چیزی که P_Srs_Offset_Value = 0 را می دهد

ترسیم ارزش in بالا بردن قدرت کنترل:

· ReportPuschTxPower: UE TxPower فعلی برای PUSCH

· ReportPucchTxPower: UE TxPower فعلی برای PUCCH

· ReportSrsTxPower: UE TxPower فعلی برای SRS

پیکربندی نمونه در زیر ارائه شده است:

پیکربندی::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl"، BooleanValue (true));
پیکربندی::SetDefault ("ns3::LteEnbPhy::TxPower"، DoubleValue (30));
پیکربندی::SetDefault ("ns3::LteUePowerControl::ClosedLoop"، BooleanValue (true));
پیکربندی::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled"، BooleanValue (true));

به عنوان مثال، کاربر می تواند نگاهی بیاندازد و برنامه lena-uplink-power-control را اجرا کند.

مثال ها برنامه ها
دایرکتوری src/lte/examples/ شامل چند نمونه برنامه شبیه سازی است که نشان می دهد چگونه
سناریوهای مختلف LTE را شبیه سازی کنید.

ارجاع سناریوها
تعداد زیادی از سناریوهای شبیه‌سازی LTE مرجع وجود دارد که می‌توان در آن یافت
ادبیات. در اینجا تعدادی از آنها را فهرست می کنیم:

· سناریوهای شبیه سازی سیستم ذکر شده در بخش A.2 [TR36814].

· مدل راه راه دوگانه [R4-092042] که تا حدی در مثال پیاده سازی شده است.
برنامه src/lte/examples/lena-dual-stripe.cc. این برنامه نمونه ویژگی های زیادی دارد
پارامترهای قابل تنظیم که می توانند با تغییر جهانی مربوطه سفارشی شوند
متغیرها برای دریافت لیستی از همه این متغیرهای سراسری، می توانید این دستور را اجرا کنید:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

در زیر بخش زیر نمونه ای از اجرای یک کمپین شبیه سازی با استفاده از آن ارائه شده است
این برنامه نمونه

تحویل دادن شبیه سازی کمپین
در این بخش، نمونه ای از اجرای یک کمپین شبیه سازی را با استفاده از آن نشان خواهیم داد
ماژول LTE از ns-3. هدف کمپین مقایسه تأثیر هر یک است
الگوریتم انتقال داخلی ماژول LTE.

کمپین از lena-dual-stripe برنامه نمونه ابتدا باید آن را اصلاح کنیم
نمونه برنامه ای برای تولید خروجی مورد نیاز. در این مناسبت می خواهیم تولید کنیم
تعداد تحویل، میانگین توان کاربر و میانگین SINR.

تعداد تحویل ها را می توان با شمارش تعداد دفعات بدست آورد HandoverEndOk
تحویل دادن قدم به قدم اخراج می شود. سپس میانگین توان کاربر را می توان با فعال کردن آن به دست آورد
RLC شبیه سازی تولید. در نهایت، SINR را می توان با فعال کردن شبیه سازی PHY به دست آورد
خروجی قطعه کد نمونه زیر یک راه ممکن برای به دست آوردن موارد فوق را نشان می دهد:

از درجه اعتبار ساقط
NotifyHandoverEndOkUe (std:: زمینه رشته، uint64_t imsi،
uint16_t cellId، uint16_t rnti)
{
std::cout << "تحویل IMSI" << imsi << std::endl;
}

INT
اصلی (int argc، char *argv[])
{
/*** SNIP ***/

پیکربندی:: اتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces ();
lteHelper->EnableRlcTraces ();
Ptr rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime"، TimeValue (ثانیه (0)));
rlcStats->SetAttribute ("EpochDuration"، TimeValue (ثانیه (simTime)));

شبیه ساز::Run ();
شبیه ساز::Destroy ();
0 بازگشت؛
}

سپس باید پارامترهای برنامه را متناسب با نیازهای شبیه سازی خود پیکربندی کنیم. ما
به دنبال مفروضات زیر در شبیه سازی ما هستند:

· 7 سایت eNodeBs ماکرو سه بخش (یعنی 21 ماکروسل) که به صورت شش ضلعی مستقر شده اند
طرح بندی با فاصله بین سایت 500 متر.

· با اينكه lena-dual-stripe در اصل برای یک دو لایه (ماکروسل و
شبیه سازی فمتوسل، ما شبیه سازی خود را به یک لایه (ماکروسل) ساده می کنیم.
فقط شبیه سازی

· UE ها به طور تصادفی در سراسر سایت ها توزیع می شوند و به طور خودکار به شبکه متصل می شوند
با استفاده از انتخاب سلول حالت بیکار. پس از آن، UE در محیط شبیه سازی پرسه می زند
با سرعت حرکت 60 کیلومتر در ساعت

· مدت زمان شبیه سازی 50 ثانیه، بنابراین UE ها به اندازه کافی مسافت را طی می کردند تا برخی را فعال کنند
واگذاری ها

· توان Tx ماکروسل 46 dBm و توان UE Tx 10 dBm.

· حالت EPC استفاده خواهد شد زیرا رویه تحویل X2 باید فعال باشد.

ترافیک بافر کامل و لینک بالا، هر دو در پهنای باند 5 مگاهرتز، با استفاده از پروتکل TCP
و زمانبندی نمایشگاه متناسب.

· پروتکل RRC ایده آل.

جدول lena-dual-stripe پارامتر پیکر بندی برای تحویل دادن کمپین در زیر نشان می دهد که چگونه ما
پیکربندی پارامترهای lena-dual-stripe برای دستیابی به مفروضات فوق

lena-dual-stripe پارامتر پیکر بندی برای تحویل دادن کمپین
┌───────────────── ───────── ───────┐
│نام پارامتر │ مقدار │ توضیحات │
├───────────────────┼─ ───────── ───────┤
│simTime │ 50 │ 50 ثانیه شبیه سازی │
│ │ │ مدت │
├───────────────────┼─ ───────── ───────┤
│nBlocks │ 0 │ غیرفعال کردن آپارتمان │
│ │ │ ساختمان ها و فمتوسل ها │
├───────────────────┼─ ───────── ───────┤
│nMacroEnbSites │ 7 │ تعداد ماکروسل │
│ │ │ سایت (هر سایت 3 │ دارد
│ │ │ سلول) │
├───────────────────┼─ ───────── ───────┤
│nMacroEnbSitesX │ 2 │ سایت های ماکروسل │
│ │ │ در 2-3-2 │ قرار بگیرید
│ │ │ تشکیل │
├───────────────────┼─ ───────── ───────┤
│فاصله بین سایتی │ 500 │ 500 متر فاصله بین │
│ │ │ سایت های ماکروسل مجاور │
├───────────────────┼─ ───────── ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 dBm Tx توان برای هر │
│ │ │ ماکروسل │
├───────────────────┼─ ───────── ───────┤
│epc │ 1 │ فعال کردن حالت EPC │
└───────────────── ───────── ───────┘

│epcDl │ 1 │ فعال کردن بافر کامل DL │
│ │ │ ترافیک │
├───────────────────┼─ ───────── ───────┤
│epcUl │ 1 │ فعال کردن بافر کامل UL │
│ │ │ ترافیک │
├───────────────────┼─ ───────── ───────┤
│useUdp │ 0 │ غیرفعال کردن ترافیک UDP و │
│ │ │ به جای آن TCP را فعال کنید │
├───────────────────┼─ ───────── ───────┤
│ macroUeDensity │ 0.00002 │ تعداد UE ها را تعیین می کند │
│ │ │ (به 48 UE در │ ترجمه می شود
│ │ │ شبیه سازی ما) │
├───────────────────┼─ ───────── ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ حداقل حرکت UE │
│ │ │ سرعت بر حسب متر بر ثانیه (60 کیلومتر بر ساعت) │
├───────────────────┼─ ───────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ حداکثر حرکت UE │
│ │ │ سرعت بر حسب متر بر ثانیه (60 کیلومتر بر ساعت) │
├───────────────────┼─ ───────── ───────┤
│macroEnb پهنای باند │ 25 │ 5 مگاهرتز DL و UL │
│ │ │ پهنای باند │
├───────────────────┼─ ───────── ───────┤
│generateRem │ 1 │ (اختیاری) برای رسم │
│ │ │ محیط رادیویی │
│ │ │ نقشه │
└───────────────── ───────── ───────┘

برخی از مفروضات مورد نیاز به عنوان پارامترهای موجود نیستند lena-dual-stripe. به
در این حالت، همانطور که در جدول نشان داده شده است، ویژگی های پیش فرض را لغو می کنیم برجسته به طور پیش فرض
خواص برای تحویل دادن کمپین زیر کلیک کنید.

برجسته به طور پیش فرض خواص برای تحویل دادن کمپین
┌───────────────── ───────── ────┬───────────── ───────── ──────────────┐
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::LteHelper::HandoverAlgorithm │ ns3::الگوریتم NoOpHandover، │ انتخاب واگذاری │
│ ns3::الگوریتم A3RsrpHandover، │ الگوریتم │
│ ns3::الگوریتم A2A4RsrqHandover │
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::LteHelper::Scheduler │ ns3::PfFfMacScheduler │ نمایشگاه متناسب │
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ نام فایل برای DL RLC │
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ نام فایل برای UL RLC │
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrنام فایل │ -DlRsrpSinrStats.txt │ نام فایل برای DL PHY │
├───────────────────- ───────── ────┼───────────────── ───────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ نام فایل برای UL PHY │
└───────────────── ───────── ────┴───────────────- ───────── ──────────────┘

ns-3 راه های زیادی برای انتقال مقادیر پیکربندی به یک شبیه سازی ارائه می دهد. در این
به عنوان مثال، ما از آرگومان های خط فرمان استفاده خواهیم کرد. اساساً با ضمیمه کردن انجام می شود
پارامترها و مقادیر آنها به واف هنگام شروع هر شبیه سازی فردی تماس بگیرید. بنابراین
la واف فراخوانی برای فراخوانی 3 شبیه سازی ما به صورت زیر است:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrنام فایل=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A3RsrpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a3-rsrp-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a3-rsrp-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrنام فایل=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrنام فایل=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

چند نکته در مورد اجرا:

توجه داشته باشید که برخی از آرگومان‌ها مشخص نشده‌اند، زیرا از قبل همان آرگومان‌ها هستند
مقادیر پیش فرض. ما همچنین الگوریتم های تحویل را روی هر تنظیمات پیش فرض خود نگه می داریم.

· به نام فایل های خروجی شبیه سازی توجه کنید، به عنوان مثال ردیابی RLC و ردیابی PHY، زیرا ما
باید مطمئن شوید که آنها در اجرای شبیه سازی بعدی بازنویسی نمی شوند. در این
برای مثال، با استفاده از آرگومان های خط فرمان، نام ها را یکی یکی مشخص می کنیم.

· --RngRun=1 آرگومان در انتها برای تنظیم عدد اجرا استفاده می شود
مولد اعداد تصادفی مورد استفاده در شبیه سازی. ما همان شبیه سازی ها را دوباره اجرا می کنیم
مختلف RngRun مقادیر، از این رو چندین تکرار مستقل از همان ایجاد می کند
شبیه سازی ها سپس نتایج به دست آمده از این تکرارها را برای دستیابی به میانگین می گیریم
مقداری اطمینان آماری

· می توانیم a اضافه کنیم --generateRem=1 آرگومان برای تولید فایل های لازم برای تولید
نقشه محیطی رادیویی (REM) شبیه سازی. نتیجه شکل است REM به دست آمده
از جانب a شبیه سازی in تحویل دادن کمپین در زیر، که با دنبال کردن آن قابل تولید است
مراحل شرح داده شده در بخش رادیو محیط نقشه ها. این شکل نیز نشان می دهد
موقعیت eNodeBs و UEs در ابتدای شبیه سازی با استفاده از RngRun = 1. دیگر
ارزش های RngRun ممکن است موقعیت UE متفاوتی ایجاد کند.
[تصویر] REM به دست آمده از یک شبیه سازی در کمپین تحویل.UNINDENT

پس از ساعت ها اجرا، کمپین شبیه سازی در نهایت به پایان می رسد. بعد ما خواهیم کرد
انجام برخی پس پردازش ها بر روی خروجی شبیه سازی تولید شده برای به دست آوردن معنی دار
اطلاعات از آن

در این مثال، ما از GNU Octave برای کمک به پردازش داده های خروجی و SINR استفاده می کنیم.
همانطور که در نمونه اسکریپت GNU Octave در زیر نشان داده شده است:

% RxBytes ستون دهم است
DlRxBytes = بار ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = مجموع (DlRxBytes) * 8 / 1000 / 50

% RxBytes ستون دهم است
UlRxBytes = بار ("no-op-UlRlcStats.txt") (:،10);
UlAverageThroughputKbps = مجموع (UlRxBytes) * 8 / 1000 / 50

% Sinr ستون 6 است
DlSinr = بار ("no-op-DlRsrpSinrStats.txt") (:,6);
% مقادیر NaN را حذف می کند
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (میانگین (DlSinr)) % تبدیل به دسی بل

% Sinr ستون 5 است
UlSinr = بار ("no-op-UlSinrStats.txt") (:,5);
% مقادیر NaN را حذف می کند
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (میانگین (UlSinr)) % تبدیل به دسی بل

در مورد تعداد تحویل‌ها، می‌توانیم از اسکریپت ساده پوسته برای شمارش تعداد استفاده کنیم
وقوع رشته "Handover" در فایل گزارش:

$ grep "Handover" no-op.txt | wc -l

جدول نتایج of تحویل دادن کمپین در زیر آمار کامل را پس از اتمام کار نشان می دهد
با پس پردازش در هر اجرای شبیه سازی فردی. مقادیر نشان داده شده میانگین هستند
از نتایج به دست آمده از RngRun از 1، 2، 3 و 4.

نتایج of تحویل دادن کمپین
┌───────────────── ───────┬─ ───────────────┐
│آمار │ بدون عملیات │ A2-A4-RSRQ │ قوی ترین سلول │
├────────────────────- ───────┼─ ───────────────┤
│سیستم DL متوسط ​​│ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│ توان عملیاتی │ │ │ │
├────────────────────- ───────┼─ ───────────────┤
│متوسط ​​سیستم UL │ 4 095 kbps │ 5 705 kbps │ 6 627 kbps │
│ توان عملیاتی │ │ │ │
├────────────────────- ───────┼─ ───────────────┤
│متوسط ​​DL SINR │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├────────────────────- ───────┼─ ───────────────┤
│ میانگین UL SINR │ 9.54 دسی بل │ │ 81.57 دسی بل │ │ 79.65 دسی بل │
├────────────────────- ───────┼─ ───────────────┤
│تعداد واگذاری │ 0 │ 0.05694 │ 0.04771 │
│در UE در ثانیه │ │ │ │
└───────────────── ───────┴─ ───────────────┘

نتایج نشان می دهد که داشتن یک الگوریتم انتقال در یک شبیه سازی تحرک هر دو را بهبود می بخشد
توان کاربر و SINR به طور قابل توجهی. تفاوت کمی بین این دو وجود دارد
الگوریتم های تحویل در این سناریوی کمپین. دیدن آنها جالب خواهد بود
عملکرد در سناریوهای مختلف، مانند سناریوهایی با استقرار eNodeBs خانگی.

فرکانس استفاده مجدد مثال ها
دو مثال وجود دارد که عملکرد الگوریتم‌های استفاده مجدد فرکانس را نشان می‌دهد.

لنا-فرکانس-استفاده مجدد مثال ساده با 3 eNB در طرح مثلث است. 3 سلول وجود دارد
UE های لبه، که در مرکز این مثلث و 3 UE مرکز سلول (یکی نزدیک
هر eNB). کاربر همچنین می تواند تعداد UE هایی که به صورت تصادفی قرار دارند را مشخص کند. الگوریتم FR است
نصب شده در eNB ها و هر eNB FrCellTypeId متفاوتی دارد، یعنی هر eNB از آن استفاده می کند
پیکربندی FR مختلف کاربر می تواند اجرا کند لنا-فرکانس-استفاده مجدد با 6 FR مختلف
الگوریتم ها: NoOp، Hard FR، Strict FR، Soft FR، Soft FFR و Enhanced FFR. برای اجرای سناریو
با الگوریتم FFR توزیع شده، کاربر باید استفاده کند lena-distributed-ffr. این دو نمونه
بسیار شبیه هستند، اما آنها تقسیم شدند زیرا FFR توزیع شده نیاز به استفاده از EPC دارد،
و سایر الگوریتم ها این کار را نمی کنند.

برای اجرا لنا-فرکانس-استفاده مجدد با استفاده از الگوریتم های مختلف فرکانس استفاده مجدد، کاربر نیاز دارد
الگوریتم FR را با نادیده گرفتن ویژگی پیش فرض مشخص کنید ns3::LteHelper::FfrAlgorithm.
نمونه دستور اجرا لنا-فرکانس-استفاده مجدد با الگوریتم Soft FR در زیر ارائه شده است:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

در این نمونه ها قابلیت تولید REM و ردیابی تحلیلگر طیف اضافه شد.
کاربر می تواند تولید آن را با تنظیم فعال کند تولید رم و تولید SpectrumTrace
ویژگی های.

دستور تولید REM برای RB 1 در کانال داده از لنا-فرکانس-استفاده مجدد سناریو با
الگوریتم Soft FR در زیر ارائه شده است:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

نقشه محیط رادیویی برای Soft FR در شکل ارائه شده است REM برای RB 1 به دست آمده از جانب
لنا-فرکانس-استفاده مجدد مثال با نرم FR الگوریتم فعال.
[تصویر] REM برای RB 1 به دست آمده از لنا-فرکانس-استفاده مجدد مثال با الگوریتم Soft FR
enabled.UNINDENT

دستور تولید ردیابی طیف از لنا-فرکانس-استفاده مجدد سناریو با Soft FFR
الگوریتم در زیر ارائه شده است (موقعیت تحلیلگر طیف باید در داخل پیکربندی شود
اسکریپت):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

نمونه ردیابی تحلیلگر طیف در شکل ارائه شده است طیف آنالایزر رد به دست آمده
از جانب لنا-فرکانس-استفاده مجدد مثال با نرم FFR الگوریتم فعال شده است طیف آنالایزر بود
واقع شده نیاز eNB با FrCellTypeId 2.. همانطور که مشاهده می شود، زیر باندهای کانال داده متفاوت است
با سطح توان متفاوت (با توجه به پیکربندی) ارسال می شوند، در حالی که کانال کنترل است
با توان یکنواخت در طول کل پهنای باند سیستم منتقل می شود.
[تصویر] ردیابی اسپکتروم آنالایزر به دست آمده از لنا-فرکانس-استفاده مجدد مثال با Soft FFR
الگوریتم فعال شد آنالایزر طیف نیاز eNB با FrCellTypeId 2..UNINDENT پیدا شد

lena-dual-stripe همچنین می تواند با الگوریتم های Frequency Reuse نصب شده در همه ماکروها اجرا شود
eNB. کاربر باید با نادیده گرفتن ویژگی پیش فرض الگوریتم FR را مشخص کند
ns3::LteHelper::FfrAlgorithm. نمونه دستور اجرا lena-dual-stripe با هارد FR
الگوریتم در زیر ارائه شده است:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrنام فایل=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

فرمان مثال برای تولید REM برای RB 1 در کانال داده از lena-dual-stripe سناریو
با الگوریتم Hard FR در زیر ارائه شده است:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=0 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrنام فایل=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

نقشه های محیطی رادیویی برای RB 1، 10 و 20 تولید شده از lena-dual-stripe سناریو با
الگوریتم استفاده مجدد فرکانس سخت در شکل های زیر ارائه شده است. این RB انتخاب شدند
زیرا هر یک توسط انواع مختلف سلول FR استفاده می شود.
[تصویر] REM برای RB 1 به دست آمده از lena-dual-stripe شبیه سازی با الگوریتم Hard FR
enabled.UNINDENT
[تصویر] REM برای RB 10 به دست آمده از lena-dual-stripe شبیه سازی با الگوریتم Hard FR
enabled.UNINDENT
[تصویر] REM برای RB 20 به دست آمده از lena-dual-stripe شبیه سازی با الگوریتم Hard FR
enabled.UNINDENT

عیب یابی و اشکال زدایی نکات
بسیاری از کاربران در لیست پستی ns-3-users پست می کنند و می پرسند که چرا هیچ دریافت نمی کنند.
ترافیک در شبیه سازی آنها، یا شاید فقط ترافیک بالا لینک، اما بدون ترافیک پایین، و غیره در بیشتر موارد
این یک اشکال در برنامه شبیه سازی کاربر است. در اینجا چند نکته برای رفع اشکال وجود دارد
برنامه ریزی کنید و علت مشکل را پیدا کنید.

رویکرد کلی این است که به طور انتخابی و تدریجی ثبت اطلاعات مربوطه را فعال کنید
اجزای ماژول LTE، پس از هر فعال سازی به این نتیجه می رسند که خروجی مطابق انتظار باشد. که در
جزئیات:

· ابتدا صفحه کنترل، به ویژه محل اتصال RRC را بررسی کنید
روش، با فعال کردن اجزای گزارش LteUeRrc و LteEnbRrc

· سپس انتقال بسته ها را در صفحه داده بررسی کنید و با فعال کردن گزارش شروع کنید
اجزای LteUeNetDevice و EpcSgwPgwApplication، سپس EpcEnbApplication، سپس
حرکت به سمت پایین پشته رادیویی LTE (PDCP، RLC، MAC، و در نهایت PHY). همه اینها تا تو
پیدا کردن جایی که بسته ها پردازش / ارسال نمی شوند.

تست مستندات
بررسی اجمالی
برای تست و اعتبار سنجی ماژول ns-3 LTE، مجموعه های آزمایشی متعددی ارائه شده است که وجود دارد
با چارچوب تست ns-3 یکپارچه شده است. برای اجرای آنها باید پیکربندی شده باشد
ساخت شبیه ساز به این صورت:

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

موارد فوق نه تنها مجموعه های آزمایشی متعلق به ماژول LTE، بلکه آن ها را نیز اجرا می کند
متعلق به تمام ماژول های دیگر ns-3 که ماژول LTE به آنها وابسته است. ns-3 را ببینید
راهنمای اطلاعات عمومی در مورد چارچوب تست.

از این طریق می توانید گزارش دقیق تری را در قالب HTML دریافت کنید:

$ ./test.py -w results.html

پس از اجرای دستور بالا، می توانید با باز کردن، نتیجه دقیق هر تست را مشاهده کنید
فایل results.html با مرورگر وب

با استفاده از این دستور می توانید هر مجموعه آزمایشی را جداگانه اجرا کنید:

$ ./test.py -s test-suite-name

برای اطلاعات بیشتر در مورد test.py و چارچوب تست ns-3، لطفاً به ns-3 مراجعه کنید
کتابچه راهنمای.

توضیحات: of la آزمون سوئیت ها
واحد تست
SINR محاسبه in la پیوند پایین
مجموعه تست lte-downlink-sinr بررسی می کند که محاسبه SINR در downlink انجام شده است
به درستی. SINR در downlink برای هر RB اختصاص داده شده به داده ها محاسبه می شود
انتقال با تقسیم توان سیگنال مورد نظر از eNB در نظر گرفته شده بر
مجموع توان نویز به اضافه تمام انتقالات روی RB یکسان که از سایر eNB ها می آید
(سیگنال های تداخل):

به طور کلی سیگنال های مختلفی می توانند در بازه های زمانی مختلف فعال باشند. الف را تعریف می کنیم
تکه به عنوان فاصله زمانی بین هر دو رویداد از نوع شروع یا پایان a
شکل موج به عبارت دیگر، یک قطعه بازه زمانی را مشخص می کند که در طی آن مجموعه از
شکل موج فعال تغییر نمی کند. اجازه دهید من تکه عمومی، T_i مدت آن و
thrm{SINR_i} SINR آن، با معادله بالا محاسبه می‌شود. محاسبه میانگین
SINR رایme
مجموعه آزمایشی بررسی می کند که محاسبه فوق در شبیه ساز به درستی انجام شده است.
بردارهای تست به صورت آفلاین توسط یک اسکریپت Octave که موارد فوق را پیاده سازی می کند به دست می آیند
معادله، و تعدادی سیگنال و تداخل تصادفی ارسال شده را دوباره ایجاد می کند
سیگنال هایی که سناریویی را تقلید می کنند که در آن یک UE تلاش می کند سیگنالی را از یک eNB رمزگشایی کند در حالی که
مواجهه با تداخل سایر eNB ها. در صورتی که مقادیر محاسبه شده برابر باشد، آزمون انجام می شود
بردار آزمون در تلورانس 10^{-7}. منظور از تلورانس برای حساب کردن است
خطاهای تقریبی معمولی از محاسبات ممیز شناور.

SINR محاسبه in la بالا بردن
مجموعه تست lte-uplink-sinr بررسی می کند که محاسبه SINR در uplink انجام شده است
به درستی. این مجموعه آزمایشی مشابه است lte-downlink-sinr شرح داده شده در قبلی
بخش، با تفاوت از هر دو سیگنال و تداخل در حال حاضر مراجعه کنید
انتقال توسط UE ها، و دریافت توسط eNB انجام می شود. این مجموعه تست
تعدادی سیگنال ارسالی تصادفی و سیگنال های تداخلی را برای تقلید از a باز می سازد
سناریویی که در آن یک eNB در تلاش برای رمزگشایی سیگنال از چندین UE به طور همزمان است (
در سلول eNB) در حالی که با تداخل سایر UE ها (آنهایی که متعلق به
به سلول های دیگر).

بردارهای آزمون توسط یک اسکریپت اختصاصی Octave به دست می آیند. آزمون قبول می شود اگر
مقادیر محاسبه شده برابر است با بردار آزمون در تلورانس 10^{-7} که، همانطور که برای
آزمون SINR downlink، به مسائل تقریب محاسباتی ممیز شناور می پردازد.

E-UTRA مطلق رادیو فرکانس کانال شماره (EARFCN)
مجموعه تست lte-earfcn بررسی می کند که فرکانس حامل استفاده شده توسط
کلاس LteSpectrumValueHelper (که مدل طیف LTE را پیاده سازی می کند) در
مطابق با [TS36101]، که در آن شماره کانال فرکانس رادیویی مطلق E-UTRA
(EARFCN) تعریف شده است. بردار آزمون برای این مجموعه آزمایشی شامل مجموعه ای از مقادیر EARFCN است
و فرکانس حامل مربوطه با استفاده از مشخصات محاسبه می شود
[TS36101]. اگر فرکانس حاملی که توسط LteSpectrumValueHelper برگردانده شده باشد، تست انجام می شود
همان مقدار شناخته شده برای هر عنصر در بردار آزمون.

سیستم تست
اختصاصی باربر غیرفعال کردن تست
مجموعه آزمایشی 'lte-test-deactivate-bearer' یک مورد آزمایشی را با EnodeB و Three ایجاد می کند.
UE ها هر UE شامل یک حامل پیش فرض و یک حامل EPS اختصاصی با همان حامل است
مشخصات اما با ARP متفاوت. Test Case Flow به شرح زیر است: UE -> Create را ضمیمه کنید
Default+Dedicated Bearer -> یکی از حامل های اختصاصی را غیرفعال کنید

کیس آزمایشی حامل اختصاصی دارای شناسه حامل 2 (LCID=BearerId+2) را غیرفعال می کند.
UE اول (UE_ID=1) کاربر می‌تواند غیرفعال‌سازی حامل را پس از تأخیر زمانی خاص با استفاده برنامه‌ریزی کند
روش شبیه ساز::Schedule ().

پس از پایان اجرای آزمایشی، DlRlcStats.txt و UlRlcStats.txt ایجاد می شود. کلید
فیلدهایی که باید در آمار بررسی شوند عبارتند از:

|
شروع | پایان | شناسه سلولی | IMSI | RNTI | LCID | TxBytes | RxBytes |

مورد تست در سه دوره اجرا می شود. 1) در دوره اول (0.04s-1.04s) همه UE و
حامل های مربوطه متصل می شود
و جریان بسته بر روی حامل های اختصاصی فعال می شود.

2. در دوره دوم (1.04s-2.04s)، غیرفعال کردن حامل به صورت نمونه انجام می شود، از این رو کاربر می تواند ببیند
تعداد نسبتاً کمتر TxByte در UE_ID=1 و LCID=4 در مقایسه با سایر حامل ها.

3. در دوره سوم (2.04s-3.04s) زیرا غیرفعال سازی حامل UE_ID=1 و LCID=4 است.
تکمیل شده است، کاربر هیچ گزارشی را در رابطه با LCID=4 مشاهده نخواهد کرد.

مورد آزمایشی می‌گذرد اگر و فقط اگر 1) IMSI=1 و LCID=4 به طور کامل در دوره سوم 2 حذف شوند.
هیچ بسته ای در TxBytes و RxBytes مربوط به IMSI=1 و LCID=4 در صورت بالا مشاهده نشد.
معیار با مورد آزمایشی در نظر گرفته شده ناموفق مطابقت ندارد

انطباقی تلفیق و برنامه نویسی تست
مجموعه تست lte-link-adaptation تست های سیستمی را ارائه می کند که یک سناریو را با یک بازآفرینی می کند
تک eNB و یک UE واحد. موارد تست مختلف مربوط به موارد مختلف ایجاد می شود
مقادیر SNR درک شده توسط UE. هدف آزمون بررسی این است که در هر مورد آزمایشی
MCS انتخاب شده با برخی از مقادیر مرجع شناخته شده مطابقت دارد. این مقادیر مرجع به دست می آیند
با پیاده سازی مجدد در Octave (نگاه کنید به src/lte/test/reference/lte_amc.m) مدل شرح داده شده در
بخش sec-lte-amc برای محاسبه بازده طیفی و تعیین
شاخص MCS مربوطه با جستجوی دستی جداول در [R1-081483]. نتیجه
بردار آزمون در شکل نشان داده شده است تست بردار برای انطباقی تلفیق و برنامه نویسی.

MCS که توسط شبیه ساز استفاده می شود با به دست آوردن خروجی ردیابی اندازه گیری می شود
تولید شده توسط زمانبندی پس از 4 میلی ثانیه (این مورد برای محاسبه تاخیر اولیه لازم است
گزارش CQI). SINR که توسط شبیه ساز محاسبه می شود نیز با استفاده از آن به دست می آید
پردازنده LteChunk رابط. در صورتی که هر دو شرایط زیر وجود داشته باشد، آزمون قبول می شود
راضی:

1. SINR محاسبه‌شده توسط شبیه‌ساز با SNR بردار آزمون درون مطابقت دارد
تحمل مطلق 10^{-7};

2. شاخص MCS مورد استفاده توسط شبیه ساز دقیقاً مطابق با شاخص موجود در آزمون است
بردار
[تصویر] بردار تست برای مدولاسیون تطبیقی ​​و کدگذاری.UNINDENT

بین سلولی دخالت تست
مجموعه تست تداخل lte تست های سیستمی را برای بازسازی یک سلول بین سلولی ارائه می دهد
سناریوی تداخل با دو eNB، که هر کدام دارای یک UE منفرد متصل به آن هستند و از آن استفاده می‌کنند
مدولاسیون و کدگذاری تطبیقی ​​هم در لینک پایین و هم در لینک بالا. توپولوژی از
سناریو در شکل نشان داده شده است توپولوژی برای la بین سلولی دخالت آزمون. d_1
پارامتر نشان دهنده فاصله هر UE تا eNB است که به آن متصل است، در حالی که d_2
پارامتر نشان دهنده فاصله تداخل کننده است. توجه می کنیم که توپولوژی سناریو چنین است
که فاصله تداخل کننده برای uplink و downlink یکسان است. هنوز، واقعی است
قدرت تداخل درک شده متفاوت خواهد بود، زیرا از دست دادن انتشار متفاوت است
در باندهای uplink و downlink. موارد تست مختلف با تغییر d_1 و به دست می آیند
پارامترهای d_2
[تصویر] توپولوژی برای تست تداخل بین سلولی.UNINDENT

بردارهای آزمون با استفاده از یک اسکریپت اختصاصی اکتاو (موجود در
src/lte/test/reference/lte_link_budget_interference.m) که بودجه پیوند را انجام می دهد
محاسبات (از جمله تداخل) مربوط به توپولوژی هر مورد آزمایشی،
و SINR و راندمان طیفی حاصل را به دست می آورد. دومی سپس استفاده می شود
تعیین (با استفاده از همان رویه اتخاذ شده برای انطباقی تلفیق و برنامه نویسی تستاست. ما
توجه داشته باشید که بردار تست حاوی مقادیر جداگانه برای uplink و downlink است.

UE اندازه گیری تست
مجموعه تست اندازه گیری lte-ue تست های سیستمی را برای بازسازی یک سلول بین سلولی ارائه می دهد
سناریوی تداخل مشابه با سناریویی که برای آن تعریف شده است تداخل lte مجموعه آزمایشی
با این حال، در این آزمایش، مقادیری که باید آزمایش شوند با RSRP و RSRQ نشان داده می شوند
اندازه گیری های انجام شده توسط UE در دو نقطه مختلف پشته: منبع، که
لایه UE PHY است و مقصد، eNB RRC است.

بردارهای آزمون با استفاده از یک اسکریپت اختصاصی اکتاو (موجود در
src/lte/test/reference/lte-ue-measurements.m) که محاسبات بودجه پیوند را انجام می دهد
(از جمله تداخل) مربوط به توپولوژی هر تست مورد، و خروجی آن
RSRP و RSRQ حاصل می شود. سپس مقادیر بدست آمده برای بررسی صحت استفاده می شود
اندازه گیری UE در لایه PHY. پس از آن، آنها باید طبق 3GPP تبدیل شوند
قالب بندی به منظور بررسی صحت آنها در سطح eNB RRC.

UE اندازه گیری پیکر بندی تست
علاوه بر مجموعه تستی که قبلا ذکر شد، 3 مجموعه تست دیگر برای تست UE وجود دارد
اندازه گیری: lte-ue-measurements-piecewise-1, lte-ue-measurements-piecewise-2و
lte-ue-measurements-handover. این مجموعه های آزمایشی بیشتر بر روی ماشه گزارش تمرکز دارند
رویه، یعنی درستی اجرای راه اندازی مبتنی بر رویداد
معیارها در اینجا تأیید می شوند.

به طور دقیق تر، آزمایش ها تأیید می کنند زمان و محتوا از هر گزارش اندازه گیری
دریافت شده توسط eNodeB. هر مورد آزمایشی یک شبیه‌سازی LTE مستقل است و مورد آزمایشی نیز چنین خواهد شد
اگر گزارش(های) اندازه گیری فقط در زمان مقرر اتفاق بیفتد و درست را نشان دهد، قبول می شود
سطح RSRP (RSRQ در حال حاضر تأیید نشده است).

قطعه ای پیکر بندی
هدف پیکربندی تکه‌ای، آزمایش پیکربندی اندازه‌گیری UE خاص است. را
اسکریپت شبیه سازی پیکربندی اندازه گیری های مربوطه را در UE تنظیم می کند که
در طول شبیه سازی فعال خواهد بود.

از آنجایی که مقادیر مرجع از قبل توسط دست محاسبه می‌شوند، چندین فرض برای آن صورت می‌گیرد
شبیه سازی را ساده کنید اولاً، کانال فقط تحت تأثیر مدل از دست دادن مسیر قرار می گیرد (در این
مورد، مدل Friis استفاده شده است). در مرحله دوم، پروتکل ایده آل RRC و لایه 3 استفاده می شود
فیلترینگ غیرفعال است در نهایت، UE در یک الگوی حرکتی از پیش تعریف شده بین 4 حرکت می کند
نقاط متمایز، همانطور که در شکل نشان داده شده است UE جنبش رد سراسر la شبیه سازی in
قطعه ای پیکر بندی زیر بنابراین نوسان RSRP اندازه گیری شده می تواند باشد
راحت تر تعیین می شود.
[تصویر] ردیابی حرکت UE در سراسر شبیه سازی در پیکربندی تکه ای.UNINDENT

انگیزه پشت "تلپورت" بین نقاط از پیش تعریف شده برای معرفی است
تغییر شدید سطح RSRP، که راه اندازی ورود یا خروج را تضمین می کند
وضعیت رویداد آزمایش شده با انجام تغییرات شدید، تست را می توان در داخل اجرا کرد
مدت زمان کمتر

شکل اندازه گیری RSRP رد of an مثال واقعه A1 آزمون مورد in قطعه ای پیکر بندی
در زیر RSRP اندازه گیری شده پس از فیلتر لایه 1 توسط لایه PHY در طول دوره نشان داده شده است
شبیه سازی با پیکربندی تکه ای چون فیلتر لایه 3 غیرفعال است، اینها
مقادیر دقیقی هستند که توسط نمونه UE RRC برای ارزیابی محرک گزارش استفاده می شوند
روش. توجه داشته باشید که مقادیر هر 200 میلی‌ثانیه به‌روزرسانی می‌شوند، که پیش‌فرض است
دوره فیلتر گزارش اندازه گیری لایه PHY. شکل همچنین زمان زمانی را نشان می دهد
ورود و خروج از شرایط یک نمونه از رویداد A1 (سلول خدمت می شود
بهتر از آستانه) در طول شبیه سازی رخ می دهد.
[تصویر] ردیابی RSRP نمونه مورد آزمایش رویداد A1 به صورت تکه‌ای اندازه‌گیری شد
configuration.UNINDENT

هر معیار گزارش دهی چندین بار با آستانه / افست متفاوت آزمایش می شود
مولفه های. برخی از سناریوهای آزمایشی، هیسترزیس و زمان تا شروع را نیز در نظر می گیرند.
شکل اندازه گیری RSRP رد of an مثال واقعه A1 با هیسترس آزمون مورد in قطعه ای
پیکر بندی اثر هیسترزیس را در نمونه دیگری از آزمون رویداد A1 به تصویر می کشد.
[تصویر] ردیابی RSRP اندازه‌گیری شده از یک رویداد نمونه A1 با مورد تست پسماند در
piecewise configuration.UNINDENT

پیکربندی تکه ای در دو مجموعه آزمایشی اندازه گیری UE استفاده می شود. اولی است
lte-ue-measurements-piecewise-1، از این پس تست Piecewise شماره 1 که 1 UE و را شبیه سازی می کند
1 eNodeB. یکی دیگر است lte-ue-measurements-piecewise-2، که دارای 1 UE و 2 eNodeB است
در شبیه سازی

آزمون تکه ای شماره 1 برای آزمایش معیارهای مبتنی بر رویداد که وابسته نیستند در نظر گرفته شده است
در مورد وجود یک سلول همسایه این معیارها شامل رویداد A1 و A2 است. را
رویدادهای دیگر نیز به طور خلاصه مورد آزمایش قرار می گیرند تا تأیید شود که هنوز به درستی کار می کنند
(اگرچه چیزی گزارش نمی شود) در غیاب هر سلول همسایه. جدول UE
اندازه گیری آزمون سناریوها با استفاده از قطعه ای پیکر بندی #1 در زیر سناریوها را فهرست می کند
تست شده در تست تکه ای شماره 1.

UE اندازه گیری آزمون سناریوها با استفاده از قطعه ای پیکر بندی #1
┌───────┬───────── ───────── ──┬─────────────────┐
│ تست شماره │ گزارش │ آستانه / آفست │ پسماند │ زمان تا ماشه │
│ │ ضوابط │ │ │ │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│1 │ رویداد A1 │ کم │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│2 │ رویداد A1 │ عادی │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│3 │ رویداد A1 │ عادی │ خیر │ کوتاه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│4 │ رویداد A1 │ عادی │ خیر │ طولانی │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│5 │ رویداد A1 │ عادی │ خیر │ فوق العاده │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│6 │ رویداد A1 │ عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│7 │ رویداد A1 │ زیاد │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│8 │ رویداد A2 │ کم │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│9 │ رویداد A2 │ عادی │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│10 │ رویداد A2 │ عادی │ خیر │ کوتاه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│11 │ رویداد A2 │ عادی │ خیر │ طولانی │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│12 │ رویداد A2 │ عادی │ خیر │ فوق العاده │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│13 │ رویداد A2 │ عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│14 │ رویداد A2 │ زیاد │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│15 │ رویداد A3 │ صفر │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│16 │ رویداد A4 │ عادی │ نه │ نه │
└───────┴───────────- ───────── ──┴─────────────────┘

│17 │ رویداد A5 │ عادی-عادی │ خیر │ نه │
└───────┴───────────- ───────── ──┴─────────────────┘

رویدادهای دیگر مانند رویداد A3، A4 و A5 به اندازه‌گیری سلول همسایه بستگی دارد، بنابراین
آنها به طور کامل در تست Piecewise شماره 2 آزمایش می شوند. شبیه سازی گره ها را روی a قرار می دهد
خط مستقیم و به UE دستور دهید "پرش" به روشی مشابه در آزمون Piecewise #1.
انتقال در شبیه سازی غیرفعال است، بنابراین نقش سرویس دهی و سلول های همسایه را انجام می دهند
در طول شبیه سازی سوئیچ نکنید. جدول UE اندازه گیری آزمون سناریوها با استفاده از قطعه ای
پیکر بندی #2 در زیر سناریوهای آزمایش شده در تست Piecewise شماره 2 را فهرست می کند.

UE اندازه گیری آزمون سناریوها با استفاده از قطعه ای پیکر بندی #2
┌───────┬───────── ───────── ──┬─────────────────┐
│ تست شماره │ گزارش │ آستانه / آفست │ پسماند │ زمان تا ماشه │
│ │ ضوابط │ │ │ │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│1 │ رویداد A1 │ کم │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│2 │ رویداد A1 │ عادی │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│3 │ رویداد A1 │ عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│4 │ رویداد A1 │ زیاد │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│5 │ رویداد A2 │ کم │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│6 │ رویداد A2 │ عادی │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│7 │ رویداد A2 │ عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│8 │ رویداد A2 │ زیاد │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│9 │ رویداد A3 │ مثبت │ خیر │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│10 │ رویداد A3 │ صفر │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│11 │ رویداد A3 │ صفر │ خیر │ کوتاه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│12 │ رویداد A3 │ صفر │ خیر │ سوپر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│13 │ رویداد A3 │ صفر │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│14 │ رویداد A3 │ منفی │ خیر │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│15 │ رویداد A4 │ کم │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│16 │ رویداد A4 │ عادی │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│17 │ رویداد A4 │ عادی │ خیر │ کوتاه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│18 │ رویداد A4 │ عادی │ خیر │ فوق العاده │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│19 │ رویداد A4 │ عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│20 │ رویداد A4 │ زیاد │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│21 │ رویداد A5 │ کم-پایین │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│22 │ رویداد A5 │ پایین-نرمال │ خیر │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│23 │ رویداد A5 │ کم-بالا │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│24 │ رویداد A5 │ نرمال-پایین │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│25 │ رویداد A5 │ عادی-عادی │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│26 │ رویداد A5 │ عادی-عادی │ خیر │ کوتاه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│27 │ رویداد A5 │ عادی-عادی │ خیر │ فوق العاده │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│28 │ رویداد A5 │ عادی-عادی │ بله │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│29 │ رویداد A5 │ نرمال-بالا │ نه │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│30 │ رویداد A5 │ زیاد-پایین │ خیر │ نه │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│31 │ رویداد A5 │ بالا-نرمال │ خیر │ خیر │
├───────┼───────────┼─ ───────── ──┼─────────────────┤
│32 │ رویداد A5 │ بالا-بالا │ نه │ نه │
└───────┴───────────- ───────── ──┴─────────────────┘

یک نکته در مورد آزمایش‌های با زمان تا شروع، آنها با استفاده از 3 مقدار مختلف آزمایش می‌شوند
زمان شروع: کوتاه (کمتر از فاصله زمانی گزارش)، طولانی (کوتاه تر از فیلتر
دوره اندازه گیری 200 میلی ثانیه)، و فوق العاده (بیشتر از 200 میلی ثانیه). دو مورد اول این را تضمین می کنند
ارزیابی زمان تا شروع همیشه از آخرین گزارش های اندازه گیری دریافت شده از PHY استفاده کنید
لایه. در حالی که آخرین مورد مسئول تأیید لغو زمان تا شروع است، برای
به عنوان مثال زمانی که یک گزارش اندازه گیری از PHY نشان می دهد که شرایط ورود/خروج خیر است
قبل از اینکه اولین ماشه فعال شود، طولانی تر است.

تحویل دادن پیکر بندی
هدف از پیکربندی تحویل، بررسی اینکه آیا اندازه‌گیری UE است یا خیر
پس از تحویل موفقیت آمیز، پیکربندی به درستی به روز می شود. برای این
هدف، شبیه سازی 2 eNodeB با اندازه گیری های مختلف UE می سازد
پیکربندی، و UE انتقال را از یک سلول به سلول دیگر انجام می دهد. UE خواهد بود
در یک خط مستقیم بین 2 eNodeB قرار دارد و انتقال فراخوانی می شود
به صورت دستی مدت زمان هر شبیه سازی 2 ثانیه (به جز آخرین مورد آزمایشی) و
تحویل دقیقاً در نیمه راه شبیه سازی آغاز می شود.

La lte-ue-measurements-handover مجموعه تست انواع مختلفی از پیکربندی را پوشش می دهد
تفاوت. اولین مورد تفاوت در فاصله گزارش است، به عنوان مثال اولین eNodeB است
با فاصله گزارش 480 میلی‌ثانیه پیکربندی شده است، در حالی که دومین eNodeB با 240 میلی‌ثانیه پیکربندی شده است.
فاصله گزارش بنابراین، زمانی که UE انتقال به سلول دوم، جدید را انجام داد
فاصله گزارش باید اعمال شود. همانطور که در پیکربندی تکه ای، زمان بندی و
محتوای هر گزارش اندازه گیری دریافت شده توسط eNodeB تایید خواهد شد.

انواع دیگر تفاوت های پوشش داده شده توسط مجموعه تست، تفاوت در رویداد و
تفاوت در آستانه / افست. جدول UE اندازه گیری آزمون سناریوها با استفاده از تحویل دادن
پیکر بندی در زیر سناریوهای آزمایش شده را فهرست می کند.

UE اندازه گیری آزمون سناریوها با استفاده از تحویل دادن پیکر بندی
────────────────────────────────────────────────── ─────────────────────
تست # موضوع آزمون اولیه پس از تحویل
پیکربندی پیکربندی
────────────────────────────────────────────────── ─────────────────────
1 فاصله گزارش 480 ms 240 ms
────────────────────────────────────────────────── ─────────────────────
2 فاصله گزارش 120 ms 640 ms
────────────────────────────────────────────────── ─────────────────────
3 رویداد رویداد A1 رویداد A2
────────────────────────────────────────────────── ─────────────────────
4 رویداد رویداد A2 رویداد A1
────────────────────────────────────────────────── ─────────────────────
5 رویداد رویداد A3 رویداد A4
────────────────────────────────────────────────── ─────────────────────
6 رویداد رویداد A4 رویداد A3
────────────────────────────────────────────────── ─────────────────────
7 رویداد رویداد A2 رویداد A3
────────────────────────────────────────────────── ─────────────────────
8 رویداد رویداد A3 رویداد A2
────────────────────────────────────────────────── ─────────────────────
9 رویداد رویداد A4 رویداد A5
────────────────────────────────────────────────── ─────────────────────
10 رویداد رویداد A5 رویداد A4
────────────────────────────────────────────────── ─────────────────────
11 محدوده آستانه/آفست RSRP 52 محدوده RSRP 56
(رویداد A1) (رویداد A1)
────────────────────────────────────────────────── ─────────────────────
12 محدوده آستانه/آفست RSRP 52 محدوده RSRP 56
(رویداد A2) (رویداد A2)
────────────────────────────────────────────────── ─────────────────────
13 آفست آستانه/افست A3 -30 افست A3 +30
(رویداد A3) (رویداد A3)
────────────────────────────────────────────────── ─────────────────────
14 محدوده آستانه/آفست RSRP 52 محدوده RSRP 56
(رویداد A4) (رویداد A4)
────────────────────────────────────────────────── ─────────────────────
15 محدوده آستانه/آفست RSRP 52-52 محدوده RSRP 56-56
(رویداد A5) (رویداد A5)
────────────────────────────────────────────────── ─────────────────────
16 زمان شروع 1024 ms 100 ms
────────────────────────────────────────────────── ─────────────────────
17 زمان شروع 1024 ms 640 ms
┌───────┬──────────- ────────┬ ─────────────────────┐
│ │ │ │ │
فایل باینری (ورودی استاندارد) مطابقت دارد

از ns-3-model-library به صورت آنلاین با استفاده از خدمات onworks.net استفاده کنید