ns-3-model-library - عبر الإنترنت في السحابة

برنامج:

اسم

ns-3-model-library - مكتبة ns-3 النموذجية

هذا هو NS-3 الموديل المكتبة توثيق. الوثائق الأولية لمشروع ns-3
متوفر بخمسة أشكال:

· NS-3 Doxygen: توثيق واجهات برمجة التطبيقات العامة لجهاز المحاكاة

· البرنامج التعليمي والدليل والمكتبة النموذجية (هذه وثيقة) ل آخر الافراج عن
تطوير شجرة

· NS-3 ويكي

هذه الوثيقة مكتوبة باللغة reStructuredText For أبو الهول ويتم الحفاظ عليه في
مستند/نماذج دليل الكود المصدري ns-3.

منظمة

يجمع هذا الدليل الوثائق الخاصة بـ NS-3 النماذج والبرامج الداعمة التي تمكن
المستخدمين لبناء محاكاة الشبكة. ومن المهم التمييز بين نماذج
عارضات ازياء:

· NS-3 يتم تنظيم البرامج في منفصلة نماذج التي تم بناؤها على حدة
مكتبة البرمجيات. يمكن لبرامج ns-3 الفردية ربط الوحدات (المكتبات) التي تحتاجها
لإجراء المحاكاة الخاصة بهم.

· NS-3 عارضات ازياء هي تمثيلات مجردة لكائنات وبروتوكولات وأجهزة في العالم الحقيقي، وما إلى ذلك.

An NS-3 قد تتكون الوحدة من أكثر من نموذج واحد (على سبيل المثال، الإنترنت وحدة
يحتوي على نماذج لكل من TCP وUDP). بشكل عام، لا تمتد نماذج ns-3 إلى عدة
وحدات البرمجيات، ولكن.

يوفر هذا الدليل وثائق حول نماذج NS-3. وهو يكمل اثنين آخرين
مصادر التوثيق الخاصة بالنماذج:

· تم توثيق نماذج واجهات برمجة التطبيقات (APIs) من منظور برمجي باستخدام Doxygen. دوكسيجين
لنماذج ns-3 متاحة on هيه تنفيذ المشاريع الويب الخادم.

· ال NS-3 الأساسية موثقة في دليل المطور. NS-3 النماذج تستفيد من
المرافق الأساسية، مثل السمات والقيم الافتراضية والأرقام العشوائية والاختبار
الأطر، الخ. استشر رئيسي الويب الموقع للعثور على نسخ من الدليل.

وأخيرا، وثائق إضافية حول جوانب مختلفة من NS-3 قد تكون موجودة على تنفيذ المشاريع
ويكي.

يمكن العثور على مخطط تفصيلي لكيفية كتابة وثائق المكتبة النموذجية عن طريق تنفيذ الأمر
create-module.py البرنامج والنظر في القالب الذي تم إنشاؤه في الملف
new-module/doc/new-module.rst.

$ مؤتمر نزع السلاح سرك
$ ./create-module.py وحدة جديدة

يتم تنظيم ما تبقى من هذه الوثيقة أبجديًا حسب اسم الوحدة.

إذا كنت جديدا على NS-3، قد ترغب أولاً في قراءة ما يلي حول وحدة الشبكة، والتي
يحتوي على بعض النماذج الأساسية للمحاكاة. نموذج الحزمة، نماذج ل
تنسيقات عناوين مختلفة، وفئات أساسية مجردة لكائنات مثل العقد والشبكة
تتم مناقشة الأجهزة والقنوات والمقابس والتطبيقات هناك.

ANIMATION

الرسوم المتحركة هي أداة مهمة لمحاكاة الشبكة. بينما NS-3 لا يحتوي على
أداة الرسوم المتحركة الافتراضية، لدينا حاليًا طريقتان لتوفير الرسوم المتحركة، وهما
باستخدام طريقة PyViz أو طريقة NetAnim. تم وصف طريقة PyViz في
http://www.nsnam.org/wiki/PyViz.

سنصف طريقة NetAnim باختصار هنا.

NetAnim
NetAnim هو برنامج مستقل قابل للتنفيذ يستند إلى Qt4 ويستخدم ملف تتبع تم إنشاؤه
خلال NS-3 محاكاة لعرض الهيكل وتحريك تدفق الحزمة بينهما
العقد.
[صورة] مثال على الرسوم المتحركة للحزمة على الروابط السلكية.UNINDENT

بالإضافة إلى ذلك، يوفر NetAnim أيضًا ميزات مفيدة مثل الجداول لعرض البيانات التعريفية
من الحزم مثل الصورة أدناه
[صورة] مثال لجداول البيانات التعريفية لحزم البيانات باستخدام مرشحات البروتوكول.UNINDENT

طريقة لتصور مسار العقدة المتنقلة
[صورة] مثال على مسار عقدة متنقلة.UNINDENT

طريقة لعرض جداول التوجيه لعقد متعددة في نقاط زمنية مختلفة
[صورة]

طريقة لعرض العدادات المرتبطة بعقد متعددة على شكل مخطط أو جدول
[صورة]
[صورة]

طريقة لعرض الجدول الزمني لأحداث إرسال واستقبال الحزمة
[صورة]

آلية العمل
الفئة ns3::AnimationInterface مسؤولة عن إنشاء ملف التتبع XML.
تستخدم AnimationInterface البنية التحتية للتتبع لتتبع تدفقات الحزم بين العقد.
تسجل AnimationInterface نفسها كخطاف تتبع لأحداث tx وrx قبل
تبدأ المحاكاة. عندما تتم جدولة حزمة لإرسالها أو استقبالها، فإن
يتم استدعاء خطافات تتبع tx وrx المقابلة في AnimationInterface. عندما يتم ربط rx
يتم استدعاء AnimationInterface، وستكون على دراية بنقطتي النهاية التي توجد بينهما الحزمة
يتدفق، ويضيف هذه المعلومات إلى ملف التتبع، بتنسيق XML مع ملف
الطوابع الزمنية tx وrx المقابلة. سيتم مناقشة تنسيق XML في قسم لاحق.
من المهم ملاحظة أن AnimationInterface يسجل الحزمة فقط في حالة تتبع rx
تسمى السنانير. يجب أن يتطابق كل حدث tx مع حدث rx.

تحميل NetAnim
إذا لم يكن NetAnim متاحًا بالفعل في ملف NS-3 الحزمة التي قمت بتنزيلها، يمكنك القيام بذلك
التالية:

يرجى التأكد من أنك قمت بتثبيت الزئبق. يمكن أن يكون أحدث إصدار من NetAnim
تم التنزيل باستخدام Mercurial باستخدام الأمر التالي:

استنساخ $ hg http://code.nsnam.org/netanim

ابني NetAnim
المتطلبات الأساسية المسبقة
مطلوب Qt4 (4.7 وما فوق) لبناء NetAnim. ويمكن الحصول على ذلك باستخدام ما يلي
طرق:

بالنسبة لتوزيعات Debian/Ubuntu Linux:

$ apt-get install qt4-dev-tools

للتوزيع القائم على Red Hat/Fedora:

$ يم تثبيت qt4
$ يم تثبيت 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 جون جون 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 تكوين التصحيح --enable-examples
$ ./waf --تشغيل "الرسوم المتحركة بالدمبل"

ما ورد أعلاه سوف ينشئ ملف XML، dumpbell-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 يتم ذلك عن طريق
إعداد نموذج التنقل المرتبط. يعد "SetConstantPosition" طريقة سريعة لتعيين xy
إحداثيات العقدة التي تكون ثابتة.

// الخطوة 3
أنيم.سيتستارتتايم (ثانية(150))؛ و anim.SetStopTime (ثانية(150)) ؛

يمكن لـ AnimationInterface إنشاء ملفات XML كبيرة الحجم. العبارات المذكورة أعلاه تقيد النافذة
التي تقوم AnimationInterface بالتتبع بينها. يؤدي تقييد النافذة إلى التركيز فقط
على الأجزاء ذات الصلة من المحاكاة وإنشاء ملفات XML صغيرة يمكن التحكم فيها

// الخطوة 4
AnimationInterface anim ("animation.xml"، 50000)؛

يضمن استخدام المُنشئ أعلاه أن كل ملف تتبع XML للرسوم المتحركة يحتوي على 50000 فقط
الحزم. على سبيل المثال، إذا التقطت AnimationInterface 150000 حزمة، باستخدام ما ورد أعلاه
يقوم المنشئ بتقسيم الالتقاط إلى 3 ملفات

Animation.xml - يحتوي على نطاق الحزمة 1-50000

الرسوم المتحركة.xml-1 - يحتوي على نطاق الحزمة 50001-100000

الرسوم المتحركة.xml-2 - يحتوي على نطاق الحزمة 100001-150000

// الخطوة 5
anim.EnablePacketMetadata (صحيح)؛

باستخدام العبارة أعلاه، تسجل AnimationInterface البيانات الوصفية لكل حزمة في ملف
ملف تتبع XML. يمكن لـ NetAnim استخدام البيانات التعريفية لتوفير إحصائيات وتصفية أفضل.
مع توفير بعض المعلومات المختصرة عن الحزمة مثل رقم تسلسل TCP
أو عنوان IP للمصدر والوجهة أثناء الرسوم المتحركة للحزمة.

تنبيه: سيؤدي تمكين هذه الميزة إلى زيادة حجم ملفات تتبع XML. أرجوك لا
قم بتمكين هذه الميزة عند استخدام روابط Wimax.

// الخطوة 6
anim.UpdateNodeDescription (5، "نقطة الوصول")؛

باستخدام العبارة أعلاه، تقوم AnimationInterface بتعيين النص "نقطة الوصول" إلى العقدة 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 بتعيين العداد بالمعرف == 89 المرتبط به
مع العقدة 7 بقيمة 3.4. يتم الحصول على العداد ذو المعرف 89 باستخدام
واجهة الرسوم المتحركة::AddNodeCounter. مثال على الاستخدام لهذا هو في
src/netanim/examples/resources_demo.cc.

خطوة 2: تحميل هيه XML in NetAnim
1. بافتراض إنشاء NetAnim، استخدم الأمر "./NetAnim" لتشغيل NetAnim. لو سمحت
قم بمراجعة قسم "Building NetAnim" إذا لم يكن NetAnim متاحًا.

2. عند فتح NetAnim، انقر فوق الزر "فتح الملف" في الزاوية العلوية اليسرى، ثم حدد
ملف XML الذي تم إنشاؤه أثناء الخطوة 1.

3. اضغط على زر التشغيل الأخضر لبدء الرسوم المتحركة.

وهنا فيديو يوضح هذا http://www.youtube.com/watch?v=tz_hUuNwFDs

ويكي
للحصول على إرشادات مفصلة حول تثبيت "NetAnim"، والأسئلة الشائعة وتحميل ملف تتبع XML
(المذكورة سابقًا) باستخدام NetAnim، يرجى الرجوع إلى: http://www.nsnam.org/wiki/NetAnim

هوائي MODULE

تصميم توثيق
نظرة عامة
توفر وحدة الهوائي:

1. فئة أساسية جديدة (AntennaModel) توفر واجهة لنمذجة
مخطط إشعاع الهوائي؛

2. مجموعة من الفئات المشتقة من هذه الفئة الأساسية التي يقوم كل منها بنمذجة مخطط الإشعاع
من أنواع مختلفة من الهوائيات.

نموذج الهوائي
يستخدم نموذج الهوائي نظام الإحداثيات المعتمد في [Balanis] والموضح في الشكل
تنسيق نظام of هيه نموذج الهوائي. يتم الحصول على هذا النظام عن طريق ترجمة الديكارتي
نظام الإحداثيات المستخدم بواسطة ns-3 MobilityModel في الأصل الجديد o وهو
موقع الهوائي، ثم تحويل إحداثيات كل نقطة عامة ص
المسافة من الإحداثيات الديكارتية (x,y,z) إلى الإحداثيات الكروية (r, heta,hi).
ويهمل نموذج الهوائي المكون الشعاعي r، ويأخذ في الاعتبار فقط مكونات الزاوية
(هيتا، مرحبا).
يتم بعد ذلك التعبير عن مخطط إشعاع الهوائي كدالة رياضية g(heta, hi)
grightarrow thcal{R} الذي يُرجع الكسب (بالديسيبل) لكل اتجاه ممكن
الإرسال/الاستقبال. يتم التعبير عن جميع الزوايا بالراديان.
[صورة] نظام إحداثيات AntennaModel.UNINDENT

المقدمة عارضات ازياء
نصف في هذا القسم نماذج مخطط إشعاع الهوائي المضمنة ضمنها
وحدة الهوائي.

نموذج الهوائي المتناحي
يوفر نموذج مخطط إشعاع الهوائي هذا كسبًا وحدويًا (dB 0) لجميع الاتجاهات.

CosineAntennaModel
هذا هو نموذج جيب التمام الموصوف في [Chunjian]: يتم تحديد كسب الهوائي على النحو التالي:

أين مرحبًا_{0}
هو الاتجاه السمتي للهوائي (أي اتجاهه لأقصى كسب) و
الأسي

يحدد عرض الحزمة المطلوب 3dB hi_{3dB}.
لاحظ أن مخطط الإشعاع هذا مستقل عن زاوية الميل هيتا.

هناك فرق كبير بين نموذج [Chunjian] والنموذج المطبق في الفصل
CosineAntennaModel هو أن عامل العنصر فقط (أي ما هو موضح أعلاه
الصيغ) يعتبر. في الواقع، اعتبر [Chunjian] أيضًا مجموعة هوائيات إضافية
عامل. سبب استبعاد الأخير هو أننا نتوقع ذلك من المستخدم العادي
قد ترغب في تحديد عرض حزمة معين بالضبط، دون إضافة عامل صفيف عند a
المرحلة الأخيرة والتي من شأنها في الواقع تغيير عرض الحزمة الفعال الناتج
نمط الإشعاع.

ParabolicAntennaModel
يعتمد هذا النموذج على التقريب المكافئ لنمط إشعاع الفص الرئيسي. هو - هي
غالبًا ما يستخدم في سياق النظام الخلوي لنمذجة نمط إشعاع الخلية
القطاع، انظر على سبيل المثال [R4-092042a] و[Calcev]. يتم تحديد كسب الهوائي بالديسيبل
على النحو التالي:

أين مرحبًا_{0}
هو الاتجاه السمتي للهوائي (أي اتجاهه لتحقيق أقصى كسب)،
مرحبا _ {3ديسيبل}
هو عرض حزمة 3 dB، وA_{max} هو الحد الأقصى للتوهين بالديسيبل للهوائي. ملحوظة
أن مخطط الإشعاع هذا مستقل عن زاوية الميل هيتا.

[بالانيس]
CA Balanis، "نظرية الهوائي - التحليل والتصميم"، وايلي، الطبعة الثانية.

[تشونجيان]
لي تشونجيان، "أنماط الهوائي الفعالة لأنظمة WCDMA ثلاثية القطاعات"، ماجستير في
رسالة علمية، جامعة تشالمرز للتكنولوجيا، جوتنبرج، السويد، 2003

[كالتشيف]
جورج كالتسيف ومات ديلون، "التحكم في إمالة الهوائي في شبكات CDMA"، في بروك. ل
المؤتمر الدولي السنوي الثاني للإنترنت اللاسلكي (WICON)، 2

[R4-092042a]
3GPP TSG RAN WG4 (الراديو) الاجتماع رقم 51، R4-092042، افتراضات المحاكاة و
المعلمات لمتطلبات FDD HeNB RF.

اسم المستخدم توثيق
يمكن استخدام الهوائي الموحد مع جميع التقنيات اللاسلكية والطبقة المادية
النماذج الداعمة له. يتضمن هذا حاليًا نماذج الطبقة المادية المستندة إلى
SpectrumPhy. يرجى الرجوع إلى وثائق كل من هذه النماذج للحصول على التفاصيل.

الاختبار توثيق
نقوم في هذا القسم بوصف مجموعات الاختبار المضمنة مع وحدة الهوائي التي تتحقق
وظيفتها الصحيحة.

زوايا
مجموعة اختبارات الوحدة الزوايا يتحقق من أن فئة الزوايا تم إنشاؤها بشكل صحيح بواسطة
التحويل الصحيح من الإحداثيات الديكارتية ثلاثية الأبعاد حسب الطرق المتاحة
(البناء من متجه واحد ومن زوج من المتجهات). لكل طريقة عدة
يتم توفير حالات الاختبار التي تقارن القيم (hi،
heta) يحدده المنشئ إلى القيم المرجعية المعروفة. يجتاز الاختبار إذا كان لكل منهما
في حالة أن القيم مساوية للمرجع حتى 10^{-10} وهو ما يمثل
للأخطاء العددية

درجات إلى راديان
مجموعة اختبارات الوحدة درجات راديان التحقق من أن الأساليب درجات إلى راديان
راديان إلى درجات العمل بشكل صحيح من خلال المقارنة مع القيم المرجعية المعروفة في عدد من
حالات تجريبية. تنجح كل حالة اختبار إذا كانت المقارنة تساوي تفاوتًا قدره 10^{-10}
والذي يسبب أخطاء رقمية.

نموذج الهوائي المتناحي
مجموعة اختبارات الوحدة نموذج الهوائي الخواص يتحقق من أن نموذج الهوائي المتناحي فئة
يعمل بشكل صحيح، على سبيل المثال، يعود دائمًا بكسب قدره 0 ديسيبل بغض النظر عن الاتجاه.

CosineAntennaModel
مجموعة اختبارات الوحدة نموذج هوائي جيب التمام يتحقق من أن CosineAntennaModel أعمال الفصل
على وجه صحيح. يتم توفير العديد من حالات الاختبار التي تتحقق من حساب قيمة كسب الهوائي
في اتجاهات مختلفة ولقيم مختلفة للتوجه، يكون الكسب المرجعي
وعرض الشعاع. يتم حساب الكسب المرجعي يدويًا. تمر كل حالة اختبار إذا كان
الكسب المرجعي بالديسيبل يساوي القيمة التي يتم إرجاعها بواسطة CosineAntennaModel ضمن
التسامح 0.001، وهو ما يمثل التقريب الذي تم إجراؤه لحساب
القيم المرجعية.

ParabolicAntennaModel
مجموعة اختبارات الوحدة نموذج هوائي مكافئ يتحقق من أن ParabolicAntennaModel فئة
يعمل بشكل صحيح. يتم توفير العديد من حالات الاختبار التي تتحقق من قيمة كسب الهوائي
محسوبة في اتجاهات مختلفة ولقيم مختلفة من الاتجاه، و
الحد الأقصى للتوهين وعرض الحزمة. يتم حساب الكسب المرجعي يدويًا. كل اختبار
يتم تمرير الحالة إذا كان الكسب المرجعي بالديسيبل يساوي القيمة التي يتم إرجاعها بواسطة
ParabolicAntennaModel ضمن التسامح 0.001، وهو ما يمثل التقريب
القيام به لحساب القيم المرجعية.

AD المخصص على الطلب مسافه: بعد قوه موجهة (أودف)

يطبق هذا النموذج المواصفات الأساسية لمتجه المسافة المخصص حسب الطلب
بروتوكول (AODV). ويستند التنفيذ على RFC 3561.

تمت كتابة النموذج بواسطة Elena Buchatskaia وPavel Boyko من ITTP RAS، وهو مبني على
نموذج ns-2 AODV الذي طورته مجموعة CMU/MONARCH وقام سمير بتحسينه وضبطه
داس وماهيش مارينا، جامعة سينسيناتي، وأيضا على تنفيذ AODV-UU من قبل
إريك نوردستروم من جامعة أوبسالا.

الموديل الوصف
الكود المصدري لنموذج AODV موجود في الدليل src/aodv.

تصميم
مبوبة ns3::aodv::RoutingProtocol ينفذ جميع وظائف تبادل حزم الخدمة
ويرث من ns3::Ipv4RoutingProtocol. تحدد الفئة الأساسية وظيفتين افتراضيتين
لتوجيه الحزمة وإعادة توجيهها. الاول، ns3::aodv::RouteOutput، يستخدم في
الحزم التي تم إنشاؤها محليًا، والثانية، ns3::aodv::RouteInput، يستخدم في
إعادة توجيه و/أو تسليم الحزم المستلمة.

يعتمد تشغيل البروتوكول على العديد من المعلمات القابلة للتعديل. المعلمات لهذا
الوظائف هي سمات ns3::aodv::RoutingProtocol. القيم الافتراضية للمعلمة هي
مستمدة من RFC وتسمح بميزات بروتوكول التمكين/التعطيل، مثل
بث رسائل الترحيب وبث حزم البيانات وما إلى ذلك.

AODV يكتشف الطرق حسب الطلب. لذلك، يقوم نموذج AODV بتخزين كافة الحزم مؤقتًا أثناء a
يتم نشر حزمة طلب المسار (RREQ). يتم تنفيذ قائمة انتظار الحزمة في
aodv-rqueue.cc. مؤشر ذكي للحزمة، ns3::Ipv4RoutingProtocol::ErrorCallback,
ns3::Ipv4RoutingProtocol::UnicastForwardCallback، ويتم تخزين رأس IP في هذا
طابور. تقوم قائمة انتظار الحزم بتنفيذ مجموعة البيانات المهملة للحزم القديمة وحجم قائمة الانتظار
الحد.

يدعم تطبيق جدول التوجيه جمع البيانات المهملة للإدخالات والحالة القديمة
الآلة، المحددة في المعيار. يتم تنفيذه كحاوية خريطة STL. المفتاح هو أ
عنوان IP الوجهة.

لم يتم وصف بعض عناصر تشغيل البروتوكول في RFC. هذه العناصر بشكل عام
يتعلق بالتعاون بين طبقات نموذج OSI المختلفة. يستخدم النموذج ما يلي
الاستدلال:

· يمكن لتطبيق AODV اكتشاف وجود روابط أحادية الاتجاه وتجنبها
اذا كان ضروري. إذا كانت العقدة التي يتلقى النموذج RREQ لها مجاورة، فقد يكون السبب هو ذلك
أن يكون رابطًا أحادي الاتجاه. هذا الإرشاد مأخوذ من تطبيق AODV-UU ويمكنه
يتم تعطيل.

· يعتمد تشغيل البروتوكول بشدة على آلية الكشف عن الارتباطات المعطلة. الموديل
ينفذ اثنين من هذه الاستدلالات. أولاً، يدعم هذا التنفيذ رسائل HELLO.
ومع ذلك، فإن رسائل HELLO ليست طريقة جيدة لاستشعار الجوار في شبكة لاسلكية
البيئة (على الأقل ليس أكثر من 802.11). لذلك، قد يواجه المرء أداءً سيئًا
عند التشغيل عبر اللاسلكي. هناك عدة أسباب لذلك: 1) رسائل الترحيب هي
بثت. في 802.11، يتم البث غالبًا بمعدل بت أقل من البث الأحادي.
ومن ثم يمكن لرسائل HELLO أن تنتقل إلى أبعد من بيانات البث الأحادي. 2) رسائل الترحيب صغيرة،
وبالتالي أقل عرضة لأخطاء البت من عمليات نقل البيانات، و3) عمليات البث الإذاعي
لا يمكن ضمان أن تكون ثنائية الاتجاه، على عكس عمليات الإرسال أحادية البث. ثانيا نستخدم
ردود فعل الطبقة الثانية عندما يكون ذلك ممكنًا. يعتبر الارتباط معطلاً في حالة إرسال الإطار
يؤدي إلى فشل الإرسال لجميع المحاولات. هذه الآلية مخصصة للنشاط
الروابط ويعمل بشكل أسرع من الطريقة الأولى.

يعتمد تنفيذ ردود الفعل للطبقة الثانية على TxErrHeader مصدر التتبع، حاليا
مدعوم في AdhocWifiMac فقط.

مجال القيود
النموذج مخصص لـ IPv4 فقط. تحسينات البروتوكول الاختياري التالية ليست كذلك
نفذ:

1. توسيع البحث الدائري.

2. إصلاح الارتباط المحلي.

3. امتدادات رسائل RREP وRREQ وHELLO.

تتطلب هذه التقنيات الوصول المباشر إلى رأس IP، وهو ما يتناقض مع التأكيد الصادر عن
AODV RFC الذي يعمل AODV عبر UDP. يستخدم هذا النموذج UDP للبساطة، مما يعيق عملية
القدرة على تنفيذ بعض التحسينات على البروتوكول. لا يستخدم النموذج طبقة خام منخفضة
مآخذ لأنها ليست محمولة.

Future للعمل
لا توجد خطط معلنة.

مراجع حسابات
الأستعمال
أمثلة
المساعدون
السمات
البحث عن المفقودين
تسجيل
المحاذير
التحقق
وحدة اختبارات
نطاق أوسع أداء اختبارات

برامج

نائب الفصل

BRIDGE NETDEVICE

نائب الفصل

يمكن العثور على بعض الأمثلة على استخدام Bridge NetDevice في أمثلة/CSMA/ الدليل.

برايت الاندماج

يطبق هذا النموذج واجهة لـ BRITE، ممثل الإنترنت لجامعة بوسطن
مولد الطوبولوجيا [1]. BRITE هي أداة قياسية لإنشاء إنترنت واقعي
علوم الهندسة اللاكمية. يوفر نموذج ns-3 الموصوف هنا فئة مساعدة لتسهيل الأمر
إنشاء طبولوجيا محددة لـ ns-3 باستخدام ملفات تكوين BRITE. برايت يبني
الرسم البياني الأصلي الذي يتم تخزينه كعقد وحواف في فئة ns-3 BriteTopolgyHelper. في
من خلال تكامل NS-3 مع BRITE، يقوم المولد بإنشاء طوبولوجيا ثم يوفر الوصول
إلى العقد الورقية لكل AS تم إنشاؤها. يمكن لمستخدمي ns-3 إرفاق طبولوجيا مخصصة بها
هذه العقد الطرفية إما عن طريق إنشائها يدويًا أو باستخدام مولدات الهيكل المتوفرة في
NS-3.

هناك ثلاثة أنواع رئيسية من الطبولوجيا المتوفرة في BRITE: جهاز التوجيه، وAS، و
التسلسل الهرمي وهو مزيج من AS وجهاز التوجيه. لأغراض NS-3
من المرجح أن يكون جهاز التوجيه والتسلسل الهرمي هو الأكثر فائدة. مستوى جهاز التوجيه
يتم إنشاء الطبولوجيا باستخدام نموذج واكسمان أو نموذج باراباسي-ألبرت. كل
يحتوي النموذج على معلمات مختلفة تؤثر على إنشاء الطوبولوجيا. بالنسبة لطبولوجيا جهاز التوجيه المسطح،
تعتبر جميع العقد في نفس AS.

تحتوي طبولوجيا BRITE الهرمية على مستويين. الأول هو مستوى AS. هذا المستوى
يمكن أيضًا إنشاؤها باستخدام نموذج واكسمان أو نموذج باراباسي-ألبرت.
ثم لكل عقدة في طوبولوجيا AS، يتم إنشاء طوبولوجيا مستوى جهاز التوجيه. هؤلاء
يمكن لطبولوجيا مستوى جهاز التوجيه مرة أخرى استخدام نموذج Waxman أو نموذج Barbasi-Albert.
يقوم BRITE بتوصيل طبولوجيا جهاز التوجيه المنفصلة هذه كما هو محدد بواسطة مستوى AS
البنية. بمجرد إنشاء الطوبولوجيا الهرمية، يتم تسويتها إلى مساحة كبيرة
طوبولوجيا مستوى جهاز التوجيه.

يمكن العثور على مزيد من المعلومات في دليل مستخدم BRITE:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

الموديل الوصف
يعتمد النموذج على بناء مكتبة BRITE خارجية، ومن ثم بناء بعض ns-3
المساعدين الذين يتصلون بالمكتبة. الكود المصدري لمساعدي ns-3 موجود في
دليل src/برايت/مساعد.

تصميم
لإنشاء طوبولوجيا BRITE، يقوم مساعدو ns-3 باستدعاء مكتبة BRITE الخارجية، و
باستخدام ملف تكوين BRITE القياسي، يقوم كود BRITE بإنشاء رسم بياني يحتوي على العقد و
الحواف وفقًا لملف التكوين هذا. يرجى الاطلاع على وثائق BRITE أو
أمثلة على ملفات التكوين في src/brite/examples/conf_files للحصول على فهم أفضل لها
خيارات تكوين برايت. يتم إرجاع الرسم البياني الذي تم إنشاؤه بواسطة BRITE إلى ns-3 وns-3
تم بناء تنفيذ الرسم البياني. العقد الورقية لكل AS متاحة للمستخدم
لإرفاق طبولوجيا مخصصة أو تثبيت تطبيقات ns-3 مباشرةً.

مراجع حسابات
[1] ألبرتو مدينا، أنوكوول لاخينا، إبراهيم متى، وجون بايرز. برايت: نهج ل
جيل الطوبولوجيا العالمية. في وقائع ورشة العمل الدولية حول
نمذجة وتحليل ومحاكاة أنظمة الكمبيوتر والاتصالات – MASCOTS
'01، سينسيناتي، أوهايو، أغسطس 2001.

الأستعمال
يمكن الرجوع إلى مثال brite-generic لمعرفة الاستخدام الأساسي لواجهة BRITE. في
باختصار، يتم استخدام BriteTopologyHelper كنقطة واجهة عن طريق تمرير BRITE
ملف الضبط. بالإضافة إلى ملف التكوين، يوجد ملف أولي عشوائي بتنسيق BRITE
يمكن أيضًا تمريره. إذا لم يتم تمرير ملف أولي، فسيقوم المساعد بإنشاء بذرة
الملف باستخدام ns-3's UnionRandomVariable. بمجرد إنشاء الهيكل بواسطة BRITE،
يتم استدعاء BuildBriteTopology() لإنشاء تمثيل ns-3. يمكن أن يكون عنوان IP التالي
المخصصة للطوبولوجيا باستخدام إما AssignIpv4Addresses() أو AssignIpv6Addresses(). هو - هي
تجدر الإشارة إلى أنه سيتم التعامل مع كل رابط من نقطة إلى نقطة في الهيكل على أنه رابط جديد
لذلك يجب استخدام الشبكة الفرعية IPV4 a/30 لتجنب إهدار كمية كبيرة من
مساحة العنوان المتاحة.

يمكن العثور على أمثلة لملفات تكوين BRITE في /src/brite/examples/conf_files/.
ASBarbasi وASWaxman هما مثالان على طبولوجيا AS فقط. وRTBarabasi وRTWaxman
الملفات هي أمثلة على طبولوجيا جهاز التوجيه فقط. وأخيرا TD_ASBarabasi_RTWaxman
يعد ملف التكوين مثالاً على الهيكل الهرمي الذي يستخدم ملف Barabasi-Albert
نموذج لمستوى AS ونموذج Waxman لكل من طبولوجيا مستوى جهاز التوجيه.
يمكن العثور على معلومات حول معلمات BRITE المستخدمة في هذه الملفات في مستخدم BRITE
كتيب.

ابني برايت الاندماج
الخطوة الأولى هي تنزيل وإنشاء مستودع BRITE الخاص بـ ns-3:

استنساخ $ hg http://code.nsnam.org/BRITE
$ قرص مضغوط برايت
$ الصنع

سيؤدي هذا إلى إنشاء BRITE وإنشاء مكتبة، libbrite.so، داخل دليل BRITE.

بمجرد إنشاء BRITE بنجاح، ننتقل إلى تكوين ns-3 بدعم BRITE.
التغيير إلى دليل ns-3 الخاص بك:

$ ./waf تكوين --with-brite=/your/path/to/brite/source --enable-examples

تأكد من وجود كلمة "ممكّن" بجوار "تكامل BRITE". إذا لم يحدث ذلك، فقد حدث شيء ما
حدث خطأ. إما أنك نسيت إنشاء BRITE أولاً باتباع الخطوات المذكورة أعلاه، أو
تعذر على ns-3 العثور على دليل BRITE الخاص بك.

بعد ذلك، قم ببناء ns-3:

$ ./واف

أمثلة
للحصول على مثال يوضح تشغيل تكامل BRITE:

$ ./waf --تشغيل "مثال عام لـ brite"

من خلال تمكين المعلمة المطولة، سيقوم المثال بطباعة العقدة والحافة
المعلومات بتنسيق مشابه لمخرجات BRITE القياسية. هناك العديد من الآخرين
معلمات سطر الأوامر بما في ذلك confFile، والتتبع، وnix، الموضحة أدناه:

confile
ملف تكوين برايت. العديد من الأمثلة المختلفة لملفات تكوين BRITE
موجودة في الدليل src/brite/examples/conf_files، على سبيل المثال،
RTBarabasi20.conf و RTWaxman.conf. يرجى الرجوع إلى دليل conf_files
لمزيد من الأمثلة.

البحث عن المفقودين
تمكين تتبع أسكي.

لا شىء تمكين التوجيه لا شىء المتجهات. يتم استخدام التوجيه العالمي بشكل افتراضي.

يدعم مثال BRITE العام أيضًا التصور باستخدام pyviz، بافتراض ارتباطات python
في ns-3 ممكّنة:

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

يمكن أيضًا استخدام عمليات المحاكاة التي تتضمن BRITE مع MPI. إجمالي عدد مثيلات MPI
يتم تمريره إلى مساعد طبولوجيا BRITE حيث يتم استخدام تقسيم modulo لتعيين العقد
لكل AS إلى مثيل MPI. يمكن العثور على مثال في src/brite/examples :

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

الرجاء مراجعة وثائق ns-3 MPI للحصول على معلومات حول إعداد MPI باستخدام ns-3.

المباني MODULE

مؤتمر نزع السلاح .. تشمل:: استبدال.txt

تصميم توثيق
نظرة عامة
توفر وحدة المباني ما يلي:

1. فئة جديدة (ابني) التي تمثل وجود مبنى في المحاكاة
سيناريو؛

2. فئة جديدة (معلومات بناء التنقل) الذي يسمح بتحديد الموقع والحجم و
خصائص المباني الموجودة في منطقة المحاكاة، ويسمح بوضعها
من العقد داخل تلك المباني؛

3. فئة حاوية مع تعريف نماذج Pathloss الأكثر فائدة و
تسمى المتغيرات المقابلة المباني نموذج فقدان الانتشار.

4. نموذج انتشار جديد (HybridBuildingsPropagationLossModel) العمل مع
نموذج التنقل الذي تم تقديمه للتو، والذي يسمح بنمذجة ظاهرة
الانتشار الداخلي/الخارجي في وجود المباني.

5. نموذج مبسط يعمل فقط مع أوكومورا هاتا (OhBuildingsPropagationLossModel)
مع الأخذ في الاعتبار ظاهرة الانتشار الداخلي/الخارجي بحضور
البنايات.

تم تصميم النماذج مع وضع تقنية LTE في الاعتبار، على الرغم من أن تنفيذها يتم في الواقع
مستقل عن أي رمز خاص بـ LTE، ويمكن استخدامه مع أجهزة ns-3 اللاسلكية الأخرى
التقنيات أيضًا (مثل wifi وwimax).

تشير HybridBuildingsPropagationLossModel يتم الحصول على نموذج Pathloss المتضمن من خلال أ
مزيج من العديد من نماذج Pathloss المعروفة من أجل تقليد مختلف
السيناريوهات البيئية مثل المناطق الحضرية والضواحي والمناطق المفتوحة. وعلاوة على ذلك، النموذج
يأخذ بعين الاعتبار ضرورة تضمين الاتصالات الداخلية والخارجية
نظرًا لأنه قد يتم تركيب HeNB إما داخل المبنى أو خارجه. في حالة الأماكن المغلقة
الاتصالات، يجب على النموذج أن يأخذ في الاعتبار أيضًا نوع المبنى الخارجي <-> الداخلي
الاتصالات وفقا لبعض المعايير العامة مثل خسائر اختراق الجدار
المواد المشتركة؛ وعلاوة على ذلك فإنه يتضمن بعض التكوين العام للداخلية
الجدران في الاتصالات الداخلية.

تشير OhBuildingsPropagationLossModel تم إنشاء نموذج Pathloss لتبسيط
السابق إزالة عتبات التحول من نموذج إلى آخر. للقيام بذلك
لقد تم استخدام نموذج انتشار واحد فقط من النموذج المتاح (أي Okumura
هاتا). ولا يزال وجود المبنى يؤخذ بعين الاعتبار في النموذج؛ لذلك كل
الاعتبارات المذكورة أعلاه فيما يتعلق بنوع المبنى لا تزال سارية. نفس الشيء
يمكن النظر في ما يتعلق بالسيناريو البيئي والتكرار منذ ذلك الحين
كلاهما معلمات للنموذج الذي تم النظر فيه.

تشير ابني فئة
يتضمن النموذج فئة محددة تسمى ابني الذي يحتوي على ns3 صندوق فئة ل
تحديد أبعاد المبنى. من أجل تنفيذ خصائص
وشملت نماذج Pathloss، و ابني تدعم الفئة السمات التالية:

· نوع البناية:

· سكني (القيمة الافتراضية)

· مكتب

· تجاري

· نوع الجدران الخارجية

· خشب

· ConcreteWithWindows (القيمة الافتراضية)

· الخرسانة بدون ويندوز

· كتل حجرية

· عدد الطوابق (القيمة الافتراضية 1، والتي تعني الطابق الأرضي فقط)

· عدد الغرف في المحور السيني (القيمة الافتراضية 1)

· عدد الغرف في المحور الصادي (القيمة الافتراضية 1)

تعتمد فئة البناء على الافتراضات التالية:

· يتم تمثيل المباني على شكل متوازي مستطيل (أي مربع)

· تكون الجدران موازية للمحاور x وy وz

· ينقسم المبنى إلى شبكة من الغرف، يتم تحديدها بالمعايير التالية:

· عدد الطوابق

· عدد الغرف على طول المحور السيني

· عدد الغرف على طول المحور الصادي

· المحور z هو المحور الرأسي، أي أن الأعداد الأرضية تزداد بزيادة المحور z
القيم

· تبدأ مؤشرات الغرفة x وy من 1 وتزداد على طول المحورين x وy
على التوالي

· جميع الغرف في المبنى متساوية الحجم

تشير معلومات بناء التنقل فئة
تشير معلومات بناء التنقل فئة ترث من فئة ns3 هدف، مسؤول عن
الحفاظ على المعلومات حول موقف العقدة فيما يتعلق بالبناء. ال
المعلومات التي تديرها معلومات بناء التنقل هو:

· سواء كانت العقدة داخلية أو خارجية

· إذا كان داخليًا:

· في أي مبنى تقع العقدة

· في أي غرفة تقع العقدة (x، y ومؤشرات غرفة الطابق)

الفصل معلومات بناء التنقل يستخدم من قبل المباني نموذج فقدان الانتشار الطبقة التي
يرث من فئة ns3 نموذج فقدان الانتشار ويدير حساب فقدان المسار
المكونات المفردة وتكوينها حسب مواضع العقد. علاوة على ذلك،
وينفذ أيضًا التظليل، أي الخسارة بسبب عوائق في المسار الرئيسي
(أي النباتات والمباني وما إلى ذلك).

تجدر الإشارة إلى أنه، معلومات بناء التنقل يمكن استخدامها من قبل أي نموذج انتشار آخر.
ومع ذلك، واستنادًا إلى المعلومات المتوفرة وقت كتابة هذه السطور، فقط تلك المحددة في
تم تصميم وحدة البناء للنظر في القيود التي أدخلتها
البنايات.
g
ItuR1238نموذج فقدان الانتشار
تُكمل هذه الفئة نموذج خسارة الانتشار الداخلي المعتمد على المبنى استنادًا إلى الاتحاد الدولي للاتصالات
P.1238 modeg{ والذي يتضمن الخسائر الناجمة عن نوع المبنى (أي سكني ومكتبي و
تجاري)ia ويرد التعبير التحليلي في ما يلي.
nr
{r
aa
حيث: راي لايت. : فقدان الطاقة
N = tr}sidential \ 30 & Office \ 22 & Commercial\nd{array}
معامل [ديسيبل]
خفيف.
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 في الأقسام الفرعية التالية.

خارجي جدار خسارة (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} على أنها

الطول ربح الموديل (زئبق)
هذا المكون يمثل الكسب بسبب وجود جهاز الإرسال على الأرض
فوق الأرض. في الأدبيات [التركمانية] تم تقييم هذا الكسب بحوالي 2 ديسيبل
لكل طابق. يمكن تطبيق هذا المكسب على جميع الاتصالات الداخلية والخارجية
والعكس صحيح.

التظليل الموديل
تم تصميم التظليل وفقًا للتوزيع اللوغاريتمي الطبيعي بمعيار متغير
الانحراف كدالة للموضع النسبي (داخلي أو خارجي) لنموذج التنقل
الحالات المعنية. يتم رسم قيمة عشوائية واحدة لكل زوج من نماذج 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.

HybridBuildingsPropagationLossModel
تشير HybridBuildingsPropagationLossModel يتم الحصول على نموذج Pathloss المتضمن من خلال أ
مزيج من العديد من نماذج Pathloss المعروفة من أجل تقليد مختلف الأماكن الخارجية والداخلية
السيناريوهات الداخلية، بالإضافة إلى السيناريوهات الداخلية والخارجية والخارجية والداخلية. بالتفصيل،
الفصل HybridBuildingsPropagationLossModel يدمج نماذج Pathloss التالية:

· OkumuraHataPropagationLossModel (OH) (عند ترددات> ​​2.3 جيجاهرتز تم استبداله بـ
كون 2600 ميجا هرتز نموذج فقدان الانتشار)

· ItuR1411LosPropagationLossModel وItuR1411NlosOverRooftopPropagationLossModel
(ط1411)

· نموذج ItuR1238PropagationLoss (I1238)

· عناصر المسار لنموذج BuildingsPropagationLoss (EWL، HG، IWL)

يوضح الكود الزائف التالي كيفية وصف عناصر نموذج فقدان المسار المختلفة
تم دمج ما ورد أعلاه في HybridBuildingsPropagationLossModel:

إذا (txNode خارجي)
then
إذا (rxNode خارجي)
then
إذا (المسافة> 1 كم)
then
إذا كان (rxNode أو txNode موجودًا أسفل السطح)
then
ل = I1411
آخر
ل = أوه
آخر
ل = I1411
آخر (rxNode داخلي)
إذا (المسافة> 1 كم)
then
إذا كان (rxNode أو txNode موجودًا أسفل السطح)
L = I1411 + EWL + HG
آخر
L = أوه + إيول + زئبق
آخر
L = I1411 + EWL + HG
آخر (txNode داخلي)
إذا (rxNode داخلي)
then
إذا (نفس المبنى)
then
ل = I1238 + IWL
آخر
ل = I1411 + 2*EWL
آخر (rxNode خارجي)
إذا (المسافة> 1 كم)
then
إذا كان (rxNode أو txNode موجودًا أسفل السطح)
then
L = I1411 + EWL + HG
آخر
L = أوه + إيول + زئبق
آخر
ل = I1411 + إيول

نلاحظ أنه في حالة الاتصال بين عقدتين تحت مستوى السطح مع
المسافة أكبر من كيلومتر واحد، وما زلنا نعتبر النموذج I1، حيث أن OH هو على وجه التحديد
مصممة للخلايا الكلية وبالتالي للهوائيات فوق مستوى السطح.

وبالنسبة للنموذج ITU-R P.1411، فإننا ندرس كلا الإصدارين LOS وNLoS. على وجه الخصوص، نحن
يأخذ في الاعتبار انتشار خط البصر للمسافات التي تقل عن العتبة القابلة للضبط
(m_itu1411NlosThreshold). وفي حالة انتشار NLoS، يكون النموذج الموجود على السطح هو
تؤخذ في الاعتبار لنمذجة كل من BS الكلي وSC. في حالة NLoS عدة
تم تضمين المعلمات المعتمدة على السيناريو، مثل متوسط ​​عرض الشارع،
الاتجاه، وما إلى ذلك. يجب ضبط قيم هذه المعلمات بشكل صحيح وفقًا لـ
عند تنفيذ السيناريو، لا يحسب النموذج قيمه أصلاً. في حال وجود أي
يتم توفير القيم، ويتم استخدام القيم القياسية، بصرف النظر عن ارتفاع الهاتف المحمول وBS،
والتي بدلاً من ذلك يتم اختبار سلامتها مباشرةً في الكود (على سبيل المثال، يجب أن تكون كذلك
أكبر من الصفر). فيما يلي نعطي تعبيرات مكونات
نموذج.

نلاحظ أيضًا أن استخدام نماذج الانتشار المختلفة (OH، I1411، I1238 مع خصائصها)
المتغيرات) في HybridBuildingsPropagationLossModel يمكن أن يؤدي إلى انقطاع
مسار المسار فيما يتعلق بالمسافة. الضبط الصحيح للسمات (خاصة
سمات عتبة المسافة) يمكن تجنب هذه الانقطاعات. ومع ذلك، منذ
يعتمد سلوك كل نموذج على عدة معلمات أخرى (التردد، ارتفاع العقدة، إلخ)،
ولا توجد قيمة افتراضية لهذه العتبات يمكنها تجنب الانقطاعات على الإطلاق
التكوينات الممكنة. ومن ثم، يتم ترك ضبط مناسب لهذه المعلمات
المستخدم.

OhBuildingsPropagationLossModel
تشير OhBuildingsPropagationLossModel تم إنشاء الفصل كوسيلة بسيطة لحل المشكلة
مشاكل انقطاع HybridBuildingsPropagationLossModel بدون فعل
ضبط المعلمة الخاصة بالسيناريو. الحل هو استخدام خسارة انتشار واحدة فقط
نموذج (على سبيل المثال، أوكومورا هاتا)، مع الاحتفاظ ببنية منطق فقدان المسار لـ
حساب مكونات خسارة المسير الأخرى (مثل خسائر اختراق الجدار). النتيجه هي
نموذج خالٍ من الانقطاعات (ما عدا تلك الناتجة عن الجدران)، ولكن ذلك أقل
واقعي بشكل عام بالنسبة لسيناريو عام مع المباني والمستخدمين الخارجيين/الداخليين، على سبيل المثال،
لأن Okumura Hata ليس مناسبًا للاتصالات الداخلية أو الخارجية
الاتصالات تحت مستوى السطح.

بالتفصيل، الطبقة OhBuildingsPropagationLossModel يدمج المسار التالي
عارضات ازياء:

· نموذج أوكومورا هاتا لخسارة الانتشار (OH)

· عناصر المسار لنموذج BuildingsPropagationLoss (EWL، HG، IWL)

يوضح الكود الزائف التالي كيفية وصف عناصر نموذج فقدان المسار المختلفة
تم دمج ما ورد أعلاه في OhBuildingsPropagationLossModel:

إذا (txNode خارجي)
then
إذا (rxNode خارجي)
then
ل = أوه
آخر (rxNode داخلي)
ل = أوه + إيول
آخر (txNode داخلي)
إذا (rxNode داخلي)
then
إذا (نفس المبنى)
then
ل = أوه + إيول
آخر
L = أوه + 2*EWL
آخر (rxNode خارجي)
ل = أوه + إيول

نلاحظ أن OhBuildingsPropagationLossModel يعد تبسيطًا كبيرًا فيما يتعلق بالاحترام
إلى HybridBuildingsPropagationLossModel، نظرًا لحقيقة استخدام OH دائمًا. بينما هذا
يعطي نموذجًا أقل دقة في بعض السيناريوهات (خاصة أسفل السطح وفي الداخل).
يتجنب بشكل فعال مشكلة انقطاع المسار الذي يؤثر
HybridBuildingsPropagationLossModel.

اسم المستخدم توثيق
كيفية إلى تستخدم البنايات in a محاكاة
نشرح في هذا القسم الاستخدام الأساسي لنموذج المباني ضمن عملية المحاكاة
برنامج.

تضمن هيه رؤوس
أضف هذا في بداية برنامج المحاكاة الخاص بك:

#يشمل

إنشاء 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؛
بي تي آر ب = إنشاء كائن ()؛
ب->SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
ب->SetExtWallsType (Building::ConcreteWithWindows);
ب->SetNFloors (3)؛
ب->SetNRoomsX (3);
ب->SetNRoomsY (2);

يتكون هذا المبنى من ثلاثة طوابق وشبكة داخلية من الغرف متساوية الحجم مقاس 3 × 2.

تتوفر أيضًا فئة المساعد GridBuildingAllocator لإنشاء مجموعة من
المباني ذات الخصائص المتطابقة الموضوعة على شبكة مستطيلة. هنا مثال
كيفية استخدامه:

بي تي آر net.gridBuildingAllocator;
GridBuildingAllocator = CreateObject ()؛
GridBuildingAllocator->SetAttribute ("GridWidth"، UintegerValue (3))؛
GridBuildingAllocator->SetAttribute ("LengthX"، DoubleValue (7))؛
GridBuildingAllocator->SetAttribute ("LengthY"، DoubleValue (13));
GridBuildingAllocator->SetAttribute ("DeltaX"، DoubleValue (3))؛
GridBuildingAllocator->SetAttribute ("DeltaY"، DoubleValue (3))؛
GridBuildingAllocator->SetAttribute ("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->إنشاء (6);

سيؤدي ذلك إلى إنشاء شبكة 3x2 مكونة من 6 مباني، كل منها 7 × 13 × 6 م مع 2 × 4 غرف بالداخل و
2 فور؛ تتباعد المباني بمقدار 3 أمتار على المحورين x وy.

اقامة العقد التنقل عارضات ازياء
يتم تكوين العقد ونماذج التنقل كالمعتاد، ولكن من أجل استخدامها مع
نموذج المباني الذي تحتاج إلى اتصال إضافي به BuildingsHelper::Install()، وذلك للسماح
يتضمن نموذج التنقل المعلومات المتعلقة بموقعهم في المباني. هنا
مثال:

التنقل
التنقل.SetMobilityModel("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
التنقل. التثبيت (ueNodes)؛
BuildingsHelper::Install (ueNodes);

وتجدر الإشارة إلى أنه يمكن استخدام أي نموذج للتنقل. ومع ذلك، ينصح المستخدم بذلك
تأكد من أن سلوك نموذج التنقل المستخدم يتوافق مع
وجود المباني. على سبيل المثال، باستخدام التنقل العشوائي البسيط على العموم
قد تؤدي منطقة المحاكاة في وجود المباني بسهولة إلى تحرك العقدة داخل وخارج
المباني بغض النظر عن وجود الجدران.

المكان بعض العقد
يمكنك وضع العقد في المحاكاة الخاصة بك باستخدام عدة طرق، والتي تم وصفها في
التالية.

إرث وضع طرق
يمكن استخدام أي طريقة قديمة لتحديد المواقع ns-3 لوضع العقدة في المحاكاة. ال
الخطوة الإضافية المهمة هي على سبيل المثال، يمكنك وضع العقد يدويًا مثل هذا:

بي تي آر mm0 = enbNodes.Get (0)->GetObject ()؛
بي تي آر mm1 = enbNodes.Get (1)->GetObject ()؛
mm0->SetPosition (المتجه (5.0، 5.0، 1.5))؛
mm1->SetPosition (المتجه (30.0، 40.0، 1.5))؛

التنقل
التنقل.SetMobilityModel("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
التنقل. التثبيت (ueNodes)؛
BuildingsHelper::Install (ueNodes);
mm0->SetPosition (المتجه (5.0، 5.0، 1.5))؛
mm1->SetPosition (المتجه (30.0، 40.0، 1.5))؛

وبدلاً من ذلك، يمكنك استخدام أي فئة PositionAllocator موجودة. إحداثيات
ستحدد العقدة ما إذا كانت موضوعة في الخارج أم في الداخل، وإذا كانت داخلية، ففي أي مكان
المبنى والغرفة التي يتم وضعها.

خاص بالبناء وضع طرق
تتوفر فئات مخصص الموضع التالية لوضع العقدة في مواضع خاصة
فيما يتعلق بالمباني:

· RandomBuildingPositionAllocator: تخصيص كل موقف عن طريق اختيار عشوائيا
بناء من قائمة جميع المباني، ومن ثم اختيار موقع في الداخل بشكل عشوائي
المبنى.

· RandomRoomPositionAllocator: تخصيص كل موقف عن طريق اختيار غرفة بشكل عشوائي
قائمة الغرف في جميع المباني، ومن ثم اختيار موقع عشوائي داخل
غرفة.

· SameRoomPositionAllocator: يمشي على NodeContainer معين بالتسلسل، ولكل منهما
تقوم العقدة بتخصيص موضع جديد بشكل عشوائي في نفس الغرفة لتلك العقدة.

· FixedRoomPositionAllocator: إنشاء موضع عشوائي موزع بشكل موحد في
حجم الغرفة المختارة داخل المبنى المختار.

المصنع هيه التحرك الموديل دائم
مهم: كلما استخدمت المباني، عليك أن تصدر الأمر التالي بعدنا
لقد وضعت جميع العقد والمباني في المحاكاة:

BuildingsHelper::MakeMobilityModelConsistent ();

سيمر هذا الأمر عبر قوائم جميع العقد وجميع المباني التي سيتم تحديدها
كل مستخدم إذا كان داخليًا أو خارجيًا، وإذا كان داخليًا، فسيحدد أيضًا المبنى الموجود فيه
الذي يقع فيه المستخدم والطابق والرقم المقابل له داخل المبنى.

بناء على علم فقدان الطريق نموذج
بعد وضع المباني والعقد في المحاكاة، يمكنك استخدام أداة بناء مدركة
نموذج Pathloss في المحاكاة تمامًا بنفس الطريقة التي تستخدم بها أي خسارة مسار عادية
نموذج. كيفية القيام بذلك خاصة بالوحدة اللاسلكية التي تفكر فيها (lte،
wifi، وwimax، وما إلى ذلك)، لذا يرجى الرجوع إلى وثائق هذا النموذج للحصول على معلومات محددة
تعليمات.

الرئيسية شكلي سمات
تشير ابني تحتوي الفئة على المعلمات القابلة للتكوين التالية:

· نوع المبنى: سكني، مكتبي، تجاري.

· أنواع الحوائط الخارجية: خشبية، وخرسانية بدون نوافذ، وخرسانية بدون نوافذ، وبلوك حجري.

· حدود البناء: أ صندوق الطبقة مع حدود البناء.

· عدد الطوابق.

· عدد الغرف في المحور السيني والمحور الصادي (يمكن وضع الغرف بطريقة شبكية فقط).

تشير BuildingMobilityLossModel المعلمة القابلة للتكوين باستخدام نظام سمات ns3 هي
ممثلة بالحدود (string حدود) لمنطقة المحاكاة من خلال توفير أ صندوق فئة
مع حدود المنطقة. وعلاوة على ذلك، من خلال منهجيته يمكن أن تكون المعلمات التالية
مهيأ:

· عدد الطوابق التي تم وضع العقدة فيها (الافتراضي 0).

· الموقع في شبكة الغرف.

تشير نموذج خسارة نشر البناء تحتوي الفئة على المعلمات القابلة للتكوين التالية
قابل للتكوين باستخدام نظام السمات:

· تردد: التردد المرجعي (الافتراضي 2160 ميجاهيرتز)، لاحظ أنه عن طريق ضبط التردد
ويتم ضبط الطول الموجي وفقًا لذلك تلقائيًا والعكس).

· لامدا: الطول الموجي (0.139 متر باعتبار التردد أعلاه).

· ShadowSigmaOutdoor: الانحراف المعياري للتظليل للعقد الخارجية (default
7.0).

· ShadowSigmaIndoor: الانحراف المعياري للتظليل للعقد الداخلية (افتراضي
8.0).

· ShadowSigmaExtWalls: الانحراف المعياري للتظليل بسبب الجدران الخارجية
اختراق الاتصالات الخارجية والداخلية (الافتراضي 5.0).

· مستوى السطح: مستوى سطح المبنى بالمتر (الافتراضي 20 متر).

· Los2NlosThr: قيمة مسافة نقطة التبديل بين خط البصر و
نموذج الانتشار خارج خط البصر بالأمتار (الافتراضي 200 متر).

· ITU1411 المسافة: قيمة مسافة نقطة التبديل بين المدى القصير
(ITU 1211) الاتصالات بعيدة المدى (أوكومورا هاتا) بالأمتار (الافتراضي 200 متر).

· مسافة دقيقة: الحد الأدنى للمسافة بالأمتار بين العقدتين لتقييم
فقدان المسار (يعتبر مهملاً قبل هذه العتبة) (الافتراضي 0.5 متر).

· البيئة: سيناريو البيئة بين المناطق الحضرية وشبه الحضرية والمناطق المفتوحة (افتراضي
حضري).

· حجم المدينة: حجم المدينة بين صغير، متوسط، كبير (افتراضي كبير).

من أجل استخدام الوضع المختلط، فإن الفئة التي سيتم استخدامها هي
نموذج HybridBuildingMobilityLossModel، والذي يسمح باختيار نموذج Pathloss المناسب
وفقًا لمنطق فقدان المسار المقدم في فصل التصميم. ومع ذلك، هذا الحل
لديه مشكلة تتمثل في أن نقاط تبديل نموذج فقدان المسار قد تؤدي إلى انقطاعات بسبب
لخصائص النموذج المختلفة. وهذا يعني أنه وفقا لمحددة
السيناريو، يجب ضبط العتبة المستخدمة للتبديل بشكل صحيح. البسيط
OhBuildingMobilityLossModel التغلب على هذه المشكلة باستخدام نموذج أوكومورا هاتا فقط
خسائر اختراق الجدار.

الاختبار توثيق
نظرة عامة
لاختبار والتحقق من صحة وحدة 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-suit-name

لمزيد من التفاصيل حول test.py وإطار اختبار ns-3، يرجى الرجوع إلى ns-3
كتيب.

الوصف of هيه تجربه بالعربي الأجنحة
BuildingsHelper تجربه بالعربي
جناح الاختبار مساعد المباني يتحقق من أن الطريقة
BuildingsHelper::MakeAllInstancesConsistent () يعمل بشكل صحيح، أي أن
ينجح BuildingsHelper في تحديد ما إذا كانت العقد خارجية أو داخلية، وإذا كانت داخلية
أنها تقع في المبنى والغرفة والطابق الصحيح. العديد من حالات الاختبار هي
مزودة بمباني مختلفة (بأحجام ومواقع وغرف وأرضيات مختلفة) و
مواقف العقدة المختلفة. ينجح الاختبار إذا تم تحديد موقع كل عقدة بشكل صحيح.

BuildingPositionAllocator تجربه بالعربي
جناح الاختبار بناء موقف المخصص تتميز بحالتين اختباريتين تتحققان من ذلك
على التوالي، يعمل RandomRoomPositionAllocator وSameRoomPositionAllocator بشكل صحيح. كل
تتضمن حالات الاختبار مبنى غرفة واحدة 2 × 3 × 2 (إجمالي 12 غرفة) في الإحداثيات المعروفة و
على التوالي 24 و 48 عقدة. يتحقق كلا الاختبارين من عدد العقد المخصصة في كل منهما
الغرفة هي المتوقعة وأن موضع العقد صحيح أيضًا.

المباني فقدان الطريق اختبارات
جناح الاختبار المباني-pathloss-نموذج يوفر اختبارات وحدة مختلفة تقارن
النتائج المتوقعة لوحدة Pathloss المباني في سيناريوهات محددة مع ما قبل
تم الحصول على القيم المحسوبة دون الاتصال بالإنترنت باستخدام برنامج نصي Octave
(اختبار/مرجع/المباني-pathloss.m). تعتبر الاختبارات ناجحة إذا كانت القيمتان
تساوي تسامحًا قدره 0.1، وهو ما يعتبر مناسبًا للاستخدام النموذجي لـ
قيم Pathloss (الموجودة بالديسيبل).

في ما يلي قمنا بتفصيل السيناريوهات التي تم النظر فيها، وقد تم اختيارها
يغطي مجموعة واسعة من مجموعات المنطق المحتملة لفقدان المسار. نتائج منطق Pathloss
وبالتالي اختبارها ضمنيا.

اختبار #1 أوكومورا خطأ
في هذا الاختبار نقوم باختبار نموذج أوكومورا هاتا القياسي؛ ولذلك يتم وضع كل من eNB وUE
خارج على مسافة 2000 م. التردد المستخدم هو النطاق E-UTRA رقم 5
تتوافق مع 869 ميجا هرتز (انظر الجدول 5.5-1 من 36.101). يتضمن الاختبار أيضًا التحقق من الصحة
من امتدادات المناطق (أي المناطق الحضرية والضواحي والمناطق المفتوحة) وحجم المدينة
(صغيرة ومتوسطة وكبيرة).

اختبار #2 التكلفة231 الموديل
يهدف هذا الاختبار إلى التحقق من صحة نموذج COST231. الاختبار مشابه لاختبار أوكومورا
هاتا واحد، إلا أن التردد المستخدم هو نطاق EUTRA رقم 1 (2140 ميجاهرتز) وذلك الاختبار
لا يمكن إجراؤها إلا للمدن الكبيرة والصغيرة في السيناريوهات الحضرية بسبب النموذج
محددات.

اختبار #3 2.6 غيغاهرتز نموذج
يتحقق هذا الاختبار من صحة نموذج كون بتردد 2.6 جيجا هرتز. الاختبار مشابه لاختبار أوكومورا هاتا باستثناء
أن التردد هو نطاق EUTRA رقم 7 (2620 ميجا هرتز) ولا يمكن إجراء الاختبار إلا في
السيناريو الحضري

اختبار #4 ITU1411 خط البصر نموذج
ويهدف هذا الاختبار إلى التحقق من صحة نموذج ITU1411 في حالة خط الرؤية داخل الشارع
انتقالات الوديان. في هذه الحالة، يتم وضع UE على بعد 100 متر من eNB، منذ ذلك الحين
وتُترك عتبة التبديل بين LoS وNLoS على القيمة الافتراضية (أي 200 m).

اختبار #5 ITU1411 خارج خط البصر نموذج
يهدف هذا الاختبار إلى التحقق من صحة نموذج 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
تواصل). ولذلك يجب إدراج كسب الارتفاع في تقييم فقدان المسار.

المباني التظليل اختبار
جناح الاختبار اختبار تظليل المباني هو اختبار وحدة يهدف إلى التحقق من الإحصائية
توزيع نموذج التظليل الذي نفذته المباني PathlossModel. التظليل
تم تصميمه وفقًا للتوزيع الطبيعي بمتوسط ​​= 0 ومعيار متغير
الانحراف أماه، وفقا للنماذج المستخدمة عادة في الأدب. ثلاث حالات اختبار هي
المقدمة، والتي تغطي حالات الاتصالات الداخلية والخارجية ومن الداخل إلى الخارج.
تولد كل حالة اختبار 1000 عينة مختلفة من التظليل لأزواج مختلفة من
مثيلات MobilityModel في سيناريو معين. يتم الحصول على قيم التظليل عن طريق الطرح
من إجمالي قيمة الخسارة التي تم إرجاعها بواسطة HybridBuildingsPathlossModel مكون فقدان المسار
وهو ثابت ومحدد مسبقًا لكل حالة اختبار. ويتحقق الاختبار من أن العينة
يقع متوسط ​​وتباين العينة لقيم التظليل ضمن فاصل الثقة 99%
متوسط ​​العينة وتباين العينة. يتحقق الاختبار أيضًا من قيم التظليل
يتم إرجاعها في أوقات متتالية لنفس زوج مثيلات MobilityModel بشكل ثابت.

مراجع حسابات
[تركماني]
توركماني أيه إم دي، جي دي بارسون، دي جي لويس، "انتشار الراديو في المباني في
441 و900 و1400 ميجاهرتز"، في وقائع المؤتمر الدولي الرابع للراديو المحمول الأرضي، 4.

اضغط MODULAR ROUTER الاندماج

Click عبارة عن بنية برمجية لإنشاء أجهزة توجيه قابلة للتكوين. باستخدام مختلفة
مجموعات من وحدات معالجة الحزم تسمى العناصر، يمكن إنشاء جهاز توجيه Click لها
أداء نوع معين من الوظائف. توفر هذه المرونة منصة جيدة ل
اختبار وتجربة البروتوكولات المختلفة.

الموديل الوصف
الكود المصدري لنموذج Click موجود في الدليل سرك/انقر.

تصميم
يعد تصميم ns-3 مناسبًا تمامًا للتكامل مع Click للأسباب التالية:

· يتم إجراء تسلسل/إلغاء تسلسل الحزم في ns-3 أثناء تحركها لأعلى/لأسفل في المكدس. هذا يسمح
حزم ns-3 التي سيتم تمريرها من وإلى النقر كما هي.

· وهذا يعني أيضًا أن أي نوع من مولدات حركة المرور والنقل ns-3 يجب أن يعمل بسهولة
أعلى النقر.

· من خلال السعي إلى تنفيذ النقر كمثيل Ipv4RoutingProtocol، يمكننا تجنب ذلك
تغييرات كبيرة على طبقة LL وMAC من كود ns-3.

كان هدف التصميم هو جعل واجهة برمجة التطبيقات العامة ns-3-click بسيطة بدرجة كافية بحيث يتمكن المستخدم من ذلك
يحتاج فقط إلى إضافة مثيل Ipv4ClickRouting إلى العقدة، وإبلاغ كل عقدة Click
لملف تكوين النقر (ملف .click) الذي سيتم استخدامه.

يقوم هذا النموذج بتطبيق الواجهة على Click Modular Router ويوفر
فئة Ipv4ClickRouting للسماح للعقدة باستخدام النقر للتوجيه الخارجي. على عكس الطبيعي
الأنواع الفرعية Ipv4RoutingProtocol، لا يستخدم Ipv4ClickRouting طريقة RouteInput()، ولكن
بدلاً من ذلك، يتلقى حزمة على الواجهة المناسبة ويعالجها وفقًا لذلك. ملحوظة
أنك تحتاج إلى وجود عنصر نوع جدول التوجيه في الرسم البياني للنقر الخاص بك لاستخدام النقر لـ
التوجيه الخارجي. هذا مطلوب من قبل الدالة RouteOutput() الموروثة من
IPv4RoutingProtocol. علاوة على ذلك، تستخدم العقدة القائمة على النقر نوعًا مختلفًا من L3 في
نموذج Ipv4L3ClickProtocol، وهو نسخة مختصرة من Ipv4L3Protocol.
يقوم Ipv4L3ClickProtocol بتمرير الحزم التي تمر عبر المكدس إلى Ipv4ClickRouting for
معالجة.

النامية a محاكاة API إلى السماح NS-3 إلى تفاعل مع انقر
تم بالفعل تعريف جزء كبير من واجهة برمجة التطبيقات (API) بشكل جيد، مما يسمح لـ Click بالبحث عن المعلومات منها
جهاز المحاكاة (مثل معرف العقدة ومعرف الواجهة وما إلى ذلك). من خلال الاحتفاظ بمعظم
الأساليب، يجب أن يكون من الممكن كتابة تطبيقات جديدة خاصة بـ ns-3 لنفسه
وظائف.

وبالتالي، بالنسبة لتكامل Click مع ns-3، ستتعامل فئة تسمى Ipv4ClickRouting مع ns-XNUMX
التفاعل مع النقر. يمكن العثور على الكود الخاص به في
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 Click Integration على المستوى 3 فقط، ثم يتم المغادرة
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.
في بروك. ورشة عمل ICST الدولية الثالثة حول NS-3 (WNS3)، برشلونة، إسبانيا. يمشي،
2011

· مايكل نيوفيلد، أشيش جاين، وديرك جرونوالد. Nsclick: محاكاة شبكة الجسر
والنشر. MSWiM '02: وقائع ورشة العمل الدولية الخامسة لـ ACM حول النمذجة
تحليل ومحاكاة الأنظمة اللاسلكية والمتنقلة، 2002، أتلانتا، جورجيا، الولايات المتحدة الأمريكية.
http://doi.acm.org/10.1145/570758.570772

الأستعمال
ابني انقر
الخطوة الأولى هي الاستنساخ. انقر من مستودع جيثب وقم بإنشائه:

استنساخ $ git https://github.com/kohler/click
$ النقر على القرص المضغوط/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
$ الصنع

قد يتم تخطي علامة --enable-wifi إذا كنت لا تنوي استخدام Click with Wifi. *
ملاحظة: لا تحتاج إلى إجراء "إجراء تثبيت".

بمجرد إنشاء Click بنجاح، قم بالتغيير إلى الدليل ns-3 وقم بتكوين ns-3
مع دعم تكامل النقر:

$ ./waf تكوين --enable-examples --enable-tests --with-nsclick=/path/to/click/source

تلميح: إذا قمت بالنقر فوق تثبيت دليل واحد أعلى ns-3 (كما هو الحال في ns-3-allinone
الدليل)، واسم الدليل هو "انقر" (أو رابط رمزي للدليل
يسمى "انقر")، فإن محدد --with-nsclick ليس ضروريًا؛ بناء NS-3
سيجد النظام الدليل بنجاح.

إذا ظهرت كلمة "ممكّن" بجوار "NS-3 Click Integration Support"، فهذا يعني أنك جاهز للبدء.
ملاحظة: في حالة تشغيل وحدات 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).

· بالنسبة لأي عقدة، يتم تسمية الجهاز الذي يرسل/يستقبل الحزم من/إلى النواة
"اضغط0". يجب تسمية الواجهات المتبقية eth0 وeth1 وما إلى ذلك (حتى لو كنت كذلك).
باستخدام واي فاي). يرجى ملاحظة أن ترقيم الجهاز يجب أن يبدأ من 0. في المستقبل، هذا
سيتم جعله مرنًا بحيث يمكن للمستخدمين تسمية الأجهزة في ملف النقر الخاص بهم كما يحلو لهم.

· عنصر جدول التوجيه إلزامي. يجب أن تكون المنافذ الخارجية لعنصر جدول التوجيه
تتوافق مع رقم واجهة الجهاز الذي سيتم من خلاله إرسال الحزمة
سيتم إرسالها في نهاية المطاف. سيؤدي انتهاك هذه القاعدة إلى ظهور آثار حزم غريبة حقًا.
يجب بعد ذلك تمرير اسم عنصر جدول التوجيه هذا إلى بروتوكول Ipv4ClickRouting
الكائن كمعلمة محاكاة. راجع أمثلة النقر للحصول على التفاصيل.

· يترك التطبيق الحالي Click مع وظيفة L3 بشكل أساسي، مع معالجة ns-3
L2. وسنبدأ قريبًا العمل على دعم استخدام بروتوكولات MAC عند النقر أيضًا.
وهذا يعني أنه اعتبارًا من الآن، لا يمكن استخدام العناصر المحددة لـ Click's Wifi مع ns-3.

التصحيح رزمة يطفو تبدأ من انقر
من أي نقطة داخل الرسم البياني للنقر، يمكنك استخدام الطباعة (-
http://read.cs.ucla.edu/click/elements/print) العنصر ومتغيراته للطباعة الجميلة
من محتويات الحزمة. علاوة على ذلك، يمكنك إنشاء آثار PCAP للحزم المتدفقة عبر ملف
انقر فوق الرسم البياني باستخدام ToDump (http://read.cs.ucla.edu/click/elements/todump) العنصر كما
حسنًا. على سبيل المثال:

com.myarpquerier
-> طباعة(fromarpquery,64)
-> تودومب(out_arpquery,PER_NODE 1)
-> إيثوث؛

و... سوف يقوم بطباعة محتويات الحزم التي تتدفق من ArpQuerier، ثم يقوم بإنشاء ملف
ملف تتبع pcap والذي سيكون له لاحقة "out_arpquery"، لكل عقدة تستخدم النقر
الملف، قبل دفع الحزم إلى "ethout".

المساعد
لتشغيل العقدة انقر، أسهل طريقة هي استخدام ClickInternetStackHelper
فئة في البرنامج النصي المحاكاة الخاص بك. على سبيل المثال:

ClickInternetStackHelper click;
click.SetClickFile (myNodeContainer، "nsclick-simple-lan.click")؛
click.SetRoutingTableElement (myNodeContainer، "u/rt")؛
Click.Install (myNodeContainer)؛

الأمثلة على البرامج النصية في الداخل سرك/انقر/أمثلة/ توضيح استخدام العقد القائمة على النقر في
سيناريوهات مختلفة. يمكن العثور على مصدر المساعد في الداخل
src/click/helper/click-internet-stack-helper.{h,cc}

أمثلة
تمت كتابة الأمثلة التالية، والتي يمكن العثور عليها في سرك/انقر/أمثلة/:

· 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 ثلاثية العقد
(Csma وWifi على التوالي) حيث تقوم العقدتان القائمتان على النقر بتشغيل عميل UDP الذي يرسل
الحزم إلى عقدة ثالثة قائمة على النقر تقوم بتشغيل خادم UDP.

nsclick-routing.cc: عقدة تعتمد على نقرة واحدة تتصل بأخرى عبر عقدة ثالثة
يعمل بمثابة جهاز توجيه IP (باستخدام تكوين النقر فوق جهاز التوجيه IP). وهذا يوضح
التوجيه باستخدام النقر.

البرامج النصية متوفرة داخل / أسيوط / التي تسمح لك بإنشاء ملفات النقر لـ
بعض السيناريوهات الشائعة. جهاز توجيه IP المستخدم في nsclick-routing.cc تم إنشاؤها من
make-ip-conf.pl وتم تعديله قليلاً للعمل مع ns-3-click.

التحقق
تم اختبار هذا النموذج على النحو التالي:

· تمت كتابة اختبارات الوحدة للتحقق من الأجزاء الداخلية لـ Ipv4ClickRouting. هذا يمكن أن يكون
عثر عليه في src/click/ipv4-click-routing-test.cc. تتحقق هذه الاختبارات مما إذا كانت الطرق
داخل Ipv4ClickRouting الذي يتعامل مع اسم الجهاز إلى المعرف وعنوان IP من اسم الجهاز
ويعمل عنوان Mac من روابط اسم الجهاز كما هو متوقع.

· تم استخدام الأمثلة لاختبار النقر باستخدام سيناريوهات المحاكاة الفعلية. يمكن أن تكون هذه
عثر عليه في سرك/انقر/أمثلة/. وتغطي هذه الاختبارات ما يلي: استخدام مختلف
أنواع وسائل النقل أعلى النقر، وTCP/UDP، وما إذا كان يمكن لعقد النقر التواصل معها
العقد التي لا تعتمد على النقر، ما إذا كان يمكن لعقد النقر التواصل مع بعضها البعض، باستخدام النقر
لتوجيه الحزم باستخدام التوجيه الثابت.

· تم اختبار النقر باستخدام أجهزة Csma وWifi وPoint-to-Point. تعليمات الاستخدام هي
موجود في القسم السابق

CSMA NETDEVICE

هذه هي مقدمة فصل CSMA NetDevice، لاستكمال نموذج Doxygen لـ Csma.

نظرة عامة of هيه CSMA نموذج
تشير NS-3 يقوم جهاز CSMA بتصميم شبكة ناقل بسيطة بروح الإيثرنت. على الرغم من أنه
لا تمثل أي شبكة فعلية حقيقية يمكنك بنائها أو شراؤها، فهي توفر بعضًا منها
وظيفة مفيدة للغاية.

عادة عندما يفكر المرء في شبكة الناقل Ethernet أو IEEE 802.3 يتبادر إلى ذهنه. إيثرنت
يستخدم CSMA/CD (الوصول المتعدد لتحسس الناقل مع اكتشاف الاصطدام بشكل كبير
زيادة التراجع للتنافس على وسيلة النقل المشتركة. ال 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 ماك هي طبقات فرعية من طبقة ارتباط بيانات OSI و MII فيز
هي طبقات فرعية من الطبقة المادية 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. كل
سينظر الجهاز إلى هذا "الرقم التعريفي" قبل بدء الإرسال وسيقوم بإجراء التراجع المناسب
العمليات إذا لزم الأمر.

تتم إعادة توجيه الحزم المستلمة بشكل صحيح إلى مستويات أعلى من CsmaNetDevice عبر ملف
آلية رد الاتصال. تتم تهيئة وظيفة رد الاتصال بواسطة الطبقة العليا (عندما تكون الشبكة
الجهاز متصل) باستخدام CsmaNetDevice::SetReceiveCallback ويتم استدعاؤه عند "مناسب"
استقبال حزمة بواسطة جهاز الشبكة من أجل إعادة توجيه الحزمة إلى أعلى البروتوكول
كومة.

CSMA قناة الموديل
تمثل فئة CsmaChannel وسيلة النقل الفعلية. لا يوجد حد ثابت ل
عدد الأجهزة المتصلة بالقناة. تصمم CsmaChannel معدل البيانات و
تأخير سرعة الضوء والذي يمكن الوصول إليه عبر السمتين "DataRate" و"Delay"
على التوالى. يتم استخدام معدل البيانات المقدم للقناة لتعيين معدلات البيانات المستخدمة من قبل
أقسام المرسل الخاصة بأجهزة CSMA المتصلة بالقناة. لا توجد وسيلة ل
ضبط معدلات البيانات بشكل مستقل في الأجهزة. نظرًا لأن معدل البيانات يستخدم فقط للحساب
وقت تأخير، لا توجد قيود (بخلاف نوع البيانات الذي يحمل القيمة).
السرعة التي يمكن أن تعمل بها قنوات وأجهزة CSMA؛ ولا قيود على أي
نوع من خصائص PHY.

تحتوي قناة CsmaChannel على ثلاث حالات، IDLE, الإرسال نشر. هذه الدول الثلاث
يتم "مشاهدتها" على الفور بواسطة جميع الأجهزة الموجودة على القناة. ونعني بهذا أنه إذا كان واحدًا
يبدأ الجهاز أو ينهي الإرسال المحاكى، وجميع الأجهزة الموجودة على القناة فورا
على علم بالتغير في الدولة. لا يوجد وقت يمكن أن يرى فيه جهاز واحد رسالة IDLE
قناة بينما قد يكون هناك جهاز آخر بعيدًا فعليًا في مجال الاصطدام
بدأ الإرسال مع عدم نشر الإشارات المرتبطة بها عبر القناة إلى أخرى
الأجهزة. وبالتالي ليست هناك حاجة لاكتشاف الاصطدام في نموذج CsmaChannel وهو كذلك
لم يتم تنفيذها بأي شكل من الأشكال.

لدينا، كما يشير الاسم، جانب Carrier Sense في النموذج. منذ
المحاكي عبارة عن خيط واحد، وسيتم إجراء تسلسل للوصول إلى القناة المشتركة بواسطة
محاكاة. وهذا يوفر آلية حتمية للتنافس على القناة. ال
يتم تخصيص القناة (تم الانتقال من الحالة IDLE إلى الدولة الإرسال) على أسبقية الحضور
أساس يخدم أولا. تمر القناة دائمًا بعملية من ثلاث حالات:

خامل -> إرسال -> نشر -> خامل

تشير الإرسال نماذج الحالة هي الوقت الذي يكون فيه جهاز الشبكة المصدر فعليًا
تذبذب الإشارات على السلك. ال نشر نماذج الدولة في الوقت بعد الجزء الأخير
تم إرساله، عندما تنتشر الإشارة عبر السلك إلى "النهاية البعيدة".

الانتقال إلى الإرسال الحالة مدفوعة بالدعوة إلى
CsmaChannel::TransmitStart الذي يتم استدعاؤه بواسطة جهاز الشبكة الذي ينقل الحزمة. هو - هي
تقع على عاتق هذا الجهاز مسؤولية إنهاء الإرسال بمكالمة إلى
CsmaChannel::TransmitEnd في وقت المحاكاة المناسب الذي يعكس الوقت المنقضي
لوضع كافة بتات الحزمة على السلك. عندما يتم استدعاء TransmitEnd، القناة
جدولة حدث يتوافق مع تأخير سرعة الضوء واحد. ينطبق هذا التأخير على
جميع الأجهزة صافية على القناة بشكل متماثل. يمكنك التفكير في مركز متماثل فيه
تنتشر بتات الحزمة إلى موقع مركزي ثم تتراجع عن الكابلات ذات الطول المتساوي إلى
الأجهزة الأخرى في القناة. ثم يتوافق تأخير "سرعة الضوء" الفردي مع
الوقت المستغرق لـ: 1) انتشار الإشارة من جهاز CsmaNetDevice عبر الكابل الخاص به
إلى المحور بالإضافة إلى 2) الوقت الذي يستغرقه المركز لإعادة توجيه الحزمة إلى خارج المنفذ؛ زائد
3) الوقت الذي تستغرقه الإشارة المعنية للانتشار إلى شبكة الوجهة
الجهاز.

تقوم CsmaChannel بتصميم وسيط بث بحيث يتم تسليم الحزمة إلى كافة الأجهزة
على القناة (بما في ذلك المصدر) في نهاية وقت الانتشار. انها
مسؤولية الجهاز المرسل لتحديد ما إذا كان سيستقبل الحزمة أم لا
البث عبر القناة.

توفر CsmaChannel السمات التالية:

معدل البيانات: معدل نقل البيانات على الأجهزة المتصلة.

· التأخير: سرعة تأخير نقل الضوء للقناة.

CSMA شبكة الجهاز الموديل
يظهر جهاز شبكة CSMA إلى حدٍ ما مثل جهاز Ethernet. جهاز CsmaNet
يوفر السمات التالية:

· العنوان: عنوان Mac48 الخاص بالجهاز؛

· SendEnable: تمكين إرسال الحزمة إذا كان صحيحاً.

· ReceiveEnable: تمكين استقبال الحزم إذا كان صحيحاً؛

EncapsulationMode : نوع من تغليف طبقة الارتباط للاستخدام ؛

· RxErrorModel : نموذج الخطأ المتلقي .

· TxQueue: قائمة انتظار الإرسال التي يستخدمها الجهاز.

· InterframeGap: الوقت الاختياري للانتظار بين "الإطارات".

· Rx: مصدر تتبع للحزم المستلمة.

· Drop: مصدر تتبع للحزم المسقطة.

يدعم CsmaNetDevice تعيين "نموذج خطأ الاستلام". هذا
كائن ErrorModel الذي يتم استخدامه لمحاكاة تلف البيانات على الارتباط.

يتم دائمًا توجيه الحزم المرسلة عبر CsmaNetDevice عبر قائمة انتظار الإرسال إلى
توفير خطاف تتبع للحزم المرسلة عبر الشبكة. يمكن تعيين قائمة انتظار الإرسال هذه
(عبر السمة) لنمذجة استراتيجيات الانتظار المختلفة.

كما يمكن تكوينها حسب السمة وهي طريقة التغليف التي يستخدمها الجهاز. كل
تحصل الحزمة على EthernetHeader الذي يتضمن الوجهة وعناوين MAC المصدر، و
حقل الطول/النوع. تحصل كل حزمة أيضًا على EthernetTrailer الذي يتضمن FCS.
قد يتم تغليف البيانات الموجودة في الحزمة بطرق مختلفة.

بشكل افتراضي، أو عن طريق تعيين سمة "EncapsulationMode" على "Dix"، يكون التغليف هو
وفقًا لمعايير DEC وIntel وXerox. يُسمى هذا أحيانًا بتأطير EthernetII
وهي الوجهة المألوفة MAC، وMAC المصدر، وEtherType، وData، وتنسيق CRC.

إذا تم تعيين سمة "EncapsulationMode" على "Llc"، فإن التغليف يتم بواسطة LLC SNAP. في
في هذه الحالة، تتم إضافة رأس SNAP الذي يحتوي على EtherType (IP أو ARP).

أوضاع التغليف الأخرى المنفذة هي IP_ARP (اضبط "EncapsulationMode" على "IpArp")
حيث يتلقى نوع طول رأس Ethernet رقم البروتوكول الخاص بـ
رزمة؛ أو ETHERNET_V1 (اضبط "EncapsulationMode" على "EthernetV1") حيث يكون نوع الطول
يتلقى رأس Ethernet طول الحزمة. وضع التغليف "الخام" هو
تم تعريفه ولكن لم يتم تنفيذه - يؤدي استخدام وضع RAW إلى تأكيد.

لاحظ أنه يجب ضبط جميع أجهزة الشبكة الموجودة على القناة على نفس وضع التغليف
النتائج الصحيحة. لا يتم استشعار وضع التغليف عند جهاز الاستقبال.

يطبق CsmaNetDevice خوارزمية التراجع الأسي العشوائي التي يتم تنفيذها إذا
تم تحديد القناة لتكون مشغولة (الإرسال or الانتشار) عندما يريد الجهاز
لبدء الانتشار. يؤدي هذا إلى تأخير عشوائي يصل إلى الأسرى (2، إعادة المحاولة) - 1
ميكروثانية قبل محاولة إعادة المحاولة. الحد الأقصى الافتراضي لعدد مرات إعادة المحاولة هو 1000.

باستخدام هيه جهاز CsmaNet
عادةً ما يتم إنشاء أجهزة وقنوات شبكة CSMA وتكوينها باستخدام
أسوشيتد com.CsmaHelper هدف. المختلف NS-3 يعمل مساعدو الأجهزة بشكل عام بطريقة مماثلة
الطريقة، ويتم رؤية استخدامها في العديد من أمثلة البرامج لدينا.

النموذج المفاهيمي المثير للاهتمام هو نموذج "قشرة" الكمبيوتر العارية التي يتم توصيل الشبكة بها
الأجهزة. يتم إنشاء أجهزة الكمبيوتر العارية باستخدام NodeContainer المساعد. أنت فقط تسأل هذا
مساعد لإنشاء أكبر عدد ممكن من أجهزة الكمبيوتر (نسميها العقد) كما تحتاج على شبكتك:

NodeContainer csmaNodes;
csmaNodes.Create (nCsmaNodes);

بمجرد حصولك على العقد الخاصة بك، ستحتاج إلى إنشاء مثيل لـ com.CsmaHelper وتعيين أي سمات لك
قد ترغب في التغيير.:

CsmaHelper csma;
csma.SetChannelAttribute ("DataRate"، StringValue ("100 ميجابت في الثانية"))؛
csma.SetChannelAttribute ("Delay"، 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 عبر شبكات Ethernet." الرقم مشتق بالفعل من
الحد الأقصى لحجم الحزمة لشبكات 10Base5 (إيثرنت كاملة المواصفات) - 1518 بايت. اذا أنت
اطرح حمل تغليف DIX لحزم Ethernet (18 بايت) وسينتهي بك الأمر بـ
أقصى حجم ممكن للبيانات (MTU) يبلغ 1500 بايت. يمكن للمرء أيضًا أن يجد أن MTU لـ IEEE
شبكات 802.3 هي 1492 بايت. وذلك لأن تغليف LLC/SNAP يضيف ثمانية إضافية
بايت من الحمل إلى الحزمة. في كلتا الحالتين، أجهزة الشبكة الأساسية هي
يقتصر على 1518 بايت، لكن وحدة الإرسال الكبرى (MTU) مختلفة نظرًا لاختلاف التغليف.

إذا ترك أحد سمة Mtu عند 1500 بايت وقام بتغيير سمة وضع التغليف
إلى Llc، ستكون النتيجة شبكة تحتوي على 1500 بايت من وحدات PDU مع LLC/SNAP
يؤدي التأطير إلى حزم بحجم 1526 بايت. وهذا من شأنه أن يكون غير قانوني في العديد من الشبكات، ولكن
نحن نسمح لك أن تفعل هذا. وينتج عن هذا محاكاة لا تعكسها بمهارة
ما قد تتوقعه نظرًا لأن الجهاز الحقيقي قد يرفض إرسال حزمة بحجم 1526 بايت.

توجد أيضًا إطارات ضخمة جدًا (1500 < MTU <= 9000 بايت) وإطارات ضخمة جدًا (MTU > 9000)
bytes) الإطارات التي لم يتم اعتمادها رسميًا بواسطة IEEE ولكنها متوفرة في بعضها
شبكات عالية السرعة (جيجابت) وبطاقات NIC. في نموذج CSMA، يمكن للمرء أن يترك
اضبط وضع التغليف على Dix، واضبط Mtu ​​على 64000 بايت - على الرغم من وجود رابط مرتبط
تم ترك CsmaChannel DataRate عند 10 ميغابت في الثانية (بالتأكيد ليس Gigabit Ethernet).
سيكون هذا بمثابة نموذج أساسي لمحول إيثرنت مصنوع من طراز الثمانينات الذي استغله مصاصو الدماء
شبكات 10Base5 التي تدعم مخططات البيانات فائقة الحجم، وهو بالتأكيد ليس شيئًا من هذا القبيل
تم صنعه على الإطلاق، ومن غير المرجح أن يتم تصنيعه على الإطلاق؛ ومع ذلك فمن السهل جدًا عليك القيام بذلك
تهيئة.

كن حذرًا بشأن الافتراضات المتعلقة بنموذج CSMA الفعلي وكيفية ذلك
قد يسمح لك التكوين (السمات) بالانحراف بشكل كبير بعيدًا عن الواقع.

CSMA البحث عن المفقودين
مثل كل NS-3 الأجهزة، يوفر نموذج CSMA عددًا من مصادر التتبع. هذه التتبع
يمكن ربط المصادر باستخدام رمز التتبع المخصص الخاص بك، أو يمكنك استخدام مساعدنا
وظائف لترتيب تمكين التتبع على الأجهزة التي تحددها.

المستوى العلوي (ماك) السنانير
من وجهة نظر التتبع في جهاز الشبكة، هناك عدة نقاط مثيرة للاهتمام
لإدخال خطافات التتبع. هناك اتفاقية موروثة من أجهزة المحاكاة الأخرى وهي تلك الحزم
المخصصة للإرسال إلى الشبكات المتصلة تمر عبر "قائمة انتظار الإرسال" واحدة
الجهاز صافي . نحن نقدم خطافات التتبع في هذه المرحلة من تدفق الحزمة، وهو ما يتوافق
(مجردا) فقط للانتقال من الشبكة إلى طبقة ارتباط البيانات، والاتصال بهم
بشكل جماعي خطافات MAC الخاصة بالجهاز.

عندما يتم إرسال حزمة إلى جهاز شبكة CSMA للإرسال، فإنها تمر دائمًا عبر
قائمة انتظار الإرسال. قائمة انتظار الإرسال في CsmaNetDevice ترث من قائمة الانتظار، وبالتالي
يرث ثلاثة مصادر تتبع:

· مصدر عملية Enqueue (انظر Queue::m_traceEnqueue);

· مصدر عملية Dequeue (انظر Queue::m_traceDequeue);

· مصدر عملية الإسقاط (انظر Queue::m_traceDrop).

خطافات التتبع ذات المستوى الأعلى (MAC) الخاصة بـ CsmaNetDevice هي في الواقع هذه الثلاثة بالضبط
تتبع المصادر في قائمة انتظار الإرسال الفردية للجهاز.

يتم تشغيل الحدث m_traceEnqueue عند وضع حزمة في قائمة انتظار الإرسال. هذا
يحدث في الوقت الذي يتم فيه استدعاء CsmaNetDevice::Send أو CsmaNetDevice::SendFrom بواسطة
طبقة أعلى لوضع حزمة في قائمة الانتظار للإرسال.

يتم تشغيل الحدث m_traceDequeue عند إزالة حزمة من قائمة انتظار الإرسال.
يمكن أن تحدث قوائم الانتظار من قائمة انتظار الإرسال في ثلاث حالات: 1) إذا كانت المشكلة الأساسية
تكون القناة خاملة عند استدعاء CsmaNetDevice::Send أو CsmaNetDevice::SendFrom،
يتم فصل الحزمة من قائمة انتظار الإرسال وإرسالها على الفور؛ 2) إذا
القناة الأساسية خاملة، وقد يتم وضع الحزمة في قائمة الانتظار وإرسالها على الفور في ملف
TransmitCompleteEvent الداخلي الذي يعمل بشكل يشبه إلى حد كبير مقاطعة الإرسال الكاملة
روتين الخدمة؛ أو 3) من معالج التراجع الأسي العشوائي في حالة انتهاء المهلة
الكشف.

تشير الحالة (3) إلى أن الحزمة قد تم فصلها من قائمة انتظار الإرسال إذا لم يكن من الممكن القيام بذلك
تنتقل وفقا لقواعد التراجع. ومن المهم أن نفهم أن هذا سوف
تظهر كحزمة تم وضعها في قائمة الانتظار ومن السهل الافتراض بشكل غير صحيح أن الحزمة كانت كذلك
تنتقل منذ أن مرت عبر قائمة انتظار الإرسال. في الواقع، حزمة هي في الواقع
انخفض بواسطة جهاز الشبكة في هذه الحالة. يعود سبب هذا السلوك إلى
تعريف حدث Queue Drop. يتم تشغيل الحدث m_traceDrop، حسب التعريف، عندما يتم تشغيل a
لا يمكن إدراج الحزمة في قائمة انتظار الإرسال لأنها ممتلئة. هذا الحدث يطلق النار فقط
إذا كانت قائمة الانتظار ممتلئة ولم نقم بتحميل هذا الحدث بشكل زائد للإشارة إلى أن CsmaChannel
"ممتلىء."

المستويات الدنيا (فاي) السنانير
على غرار خطافات التتبع في المستوى العلوي، تتوفر خطافات تتبع في المستوى السفلي
مستويات الشبكة للجهاز. نحن نسميها خطافات PHY. يتم إطلاق هذه الأحداث من الجهاز
الأساليب التي تتحدث مباشرة إلى CsmaChannel.

يتم استدعاء مصدر التتبع m_dropTrace للإشارة إلى الحزمة التي تم إسقاطها بواسطة الجهاز.
يحدث هذا في حالتين: أولاً، إذا لم يتم تمكين جانب الاستلام لجهاز الشبكة
(راجع CsmaNetDevice::m_receiveEnable والسمة المرتبطة "ReceiveEnable").

يتم استخدام m_dropTrace أيضًا للإشارة إلى أنه تم تجاهل الحزمة باعتبارها تالفة في حالة وجود ملف
يتم استخدام نموذج خطأ التلقي (راجع CsmaNetDevice::m_receiveErrorModel وما يرتبط به من
السمة "ReceiveErrorModel").

يتم تشغيل مصدر التتبع الآخر منخفض المستوى عند استقبال حزمة مقبولة (انظر
CsmaNetDevice::m_rxTrace). يتم قبول الحزمة إذا كانت مخصصة للبث
العنوان أو عنوان البث المتعدد أو عنوان MAC المخصص لجهاز الشبكة.

الملخص
يعد نموذج ns3 CSMA نموذجًا مبسطًا لشبكة تشبه شبكة Ethernet. وهو يدعم أ
وظيفة Carrier-Sense وتسمح بالوصول المتعدد إلى وسيط مشترك. ليس
مادي بمعنى أن حالة الوسط يتم تقاسمها على الفور بين الجميع
الأجهزة. وهذا يعني أنه لا يوجد حاجة للكشف عن الاصطدام في هذا النموذج ولا شيء مطلوب
تم تنفيذه. لن يكون هناك أبدًا "ازدحام" للحزمة الموجودة بالفعل على الوسيط. الولوج إلى
تكون القناة المشتركة على أساس أسبقية الحضور كما هو محدد بواسطة جهاز المحاكاة
جدولة. إذا تم تحديد القناة لتكون مشغولة من خلال النظر إلى الحالة العالمية، أ
يتم إجراء التراجع الأسي العشوائي ومحاولة إعادة المحاولة.

توفر سمات Ns-3 آلية لتعيين معلمات مختلفة في الجهاز و
قناة مثل العناوين وأوضاع التغليف واختيار نموذج الخطأ. خطافات التتبع موجودة
يتم توفيره بالطريقة المعتادة مع مجموعة من خطافات المستوى العلوي المقابلة للإرسال
قائمة الانتظار وتستخدم في تتبع ASCII؛ وأيضًا مجموعة من الخطافات ذات المستوى الأدنى المستخدمة في تتبع PCAP.

على الرغم من أن ns-3 CsmaChannel وCsmaNetDevice لا يمثلان أي نوع من الشبكات لك
يمكن بناؤها أو شرائها، فهي توفر لنا بعض الوظائف المفيدة. يجب،
ومع ذلك، افهم أنه ليس إيثرنت بشكل صريح أو أي نكهة من IEEE 802.3 ولكنه
مجموعة فرعية مثيرة للاهتمام.

بيانات مجموعة

يصف هذا الفصل ns-3 Data Collection Framework (DCF) ، والذي يوفر
القدرة على الحصول على البيانات التي تم إنشاؤها بواسطة النماذج في جهاز المحاكاة ، لأداء عبر الإنترنت
الاختزال ومعالجة البيانات ، وتنظيم البيانات الخام أو المحولة إلى مخرجات مختلفة
الأشكال.

يدعم إطار العمل حاليًا عمليات تشغيل ns-3 المستقلة التي لا تعتمد على أي خارجي
مراقبة تنفيذ البرنامج. قد يتم ربط الكائنات التي يوفرها DCF NS-3 تتبع
مصادر لتمكين معالجة البيانات.

الكود المصدري للفئات موجود في الدليل src / احصائيات.

تم تنظيم هذا الفصل على النحو التالي. أولا ، نظرة عامة على العمارة
قدم. بعد ذلك ، يتم تقديم المساعدين لهذه الفئات ؛ هذا العلاج الأولي
يجب أن يسمح بالاستخدام الأساسي لإطار عمل جمع البيانات للعديد من حالات الاستخدام. المستخدمون الذين
ترغب في إنتاج مخرجات خارج نطاق المساعدين الحاليين ، أو الذين يرغبون في إنشاء
كائنات جمع البيانات الخاصة بهم ، يجب قراءة ما تبقى من الفصل ، والذي يذهب
بالتفصيل حول جميع أنواع كائنات DCF الأساسية ويوفر ترميزًا منخفض المستوى
أمثلة.

تصميم
يتكون DCF من ثلاث فئات أساسية:

· مسبار هي آلية للأداة والتحكم في إخراج بيانات المحاكاة
تستخدم لرصد الأحداث الشيقة. ينتج مخرجات في شكل واحد أو أكثر NS-3
مصادر التتبع. يتم توصيل كائنات المجس بتتبع واحد أو أكثر المصارف (مسمي
جامعي) ، التي تعالج العينات عبر الإنترنت وتجهزها للإخراج.

· جامع يستهلك البيانات التي تم إنشاؤها بواسطة كائن مسبار واحد أو أكثر. ينفذ
التحولات على البيانات ، مثل التطبيع والتخفيض وحساب
إحصائيات أساسية. لا تنتج كائنات المُجمع البيانات التي يتم إخراجها مباشرةً بواسطة
ns-3 المدى بدلاً من ذلك ، يقومون بإخراج البيانات في اتجاه المصب إلى نوع آخر من الكائنات يسمى
مجمع، الذي يؤدي هذه الوظيفة. عادةً ما يُخرج المُجمعون بياناتهم بتنسيق
شكل مصادر التتبع أيضًا ، مما يسمح بتقييد الجامعين في سلسلة.

· مجمع هي نقطة نهاية البيانات التي تم جمعها بواسطة شبكة من المجسات والمجمعات.
المسؤولية الرئيسية للمُجمِّع هي تنظيم البيانات وما يقابلها
البيانات الوصفية إلى تنسيقات إخراج مختلفة مثل ملفات النص العادي أو ملفات جداول البيانات أو
قواعد بيانات.

توفر كل هذه الفئات الثلاثة القدرة على تشغيل نفسها أو إيقاف تشغيلها ديناميكيًا
في جميع أنحاء المحاكاة.

أي قائمة بذاتها NS-3 عادةً ما يُنشئ تشغيل المحاكاة الذي يستخدم DCF واحدًا على الأقل
مثيل لكل من الفئات الثلاثة أعلاه.
[صورة] نظرة عامة على إطار عمل جمع البيانات

تم توضيح التدفق الإجمالي لمعالجة البيانات بتنسيق البيانات المجموعات الإطار نظرة عامة.
على الجانب الأيسر ، ركض NS-3 تم تصوير المحاكاة. في سياق تشغيل
المحاكاة ، يتم توفير البيانات بواسطة النماذج من خلال مصادر التتبع ، أو عبر وسائل أخرى.
يوضح الرسم التخطيطي إمكانية توصيل المجسات بمصادر التتبع هذه لتلقي البيانات
بشكل غير متزامن ، أو تستطيع المجسات الاستقصاء عن البيانات. ثم يتم تمرير البيانات إلى كائن المجمع
الذي يحول البيانات. أخيرًا ، يمكن توصيل مُجمِّع بمخرجات ملف
جامع ، لإنشاء المؤامرات أو الملفات أو قواعد البيانات.
[صورة] تجميع إطار عمل جمع البيانات

يتم توفير تباين في الشكل أعلاه البيانات المجموعات الإطار تجميع.
يوضح هذا الشكل الثاني أن كائنات DCF يمكن ربطها ببعضها البعض بطريقة ما
أن كائنات المصب تأخذ مدخلات من عدة كائنات في المنبع. الرقم
يظهر من الناحية المفاهيمية أن عدة مجسات قد تولد مخرجات يتم تغذيتها في واحدة
جامع. كمثال ، فإن المجمع الذي ينتج نسبة عدادات
عادة الحصول على كل بيانات عداد من تحقيقات منفصلة. يمكن أيضًا لهواة الجمع المتعددة
تغذيها في مجمّع واحد ، والذي (كما يوحي اسمه) قد يجمع عددًا من البيانات
تدفقات لتضمينها في قطعة أرض أو ملف أو قاعدة بيانات واحدة.

البيانات المجموعات المساعدون
يتم توفير المرونة الكاملة لإطار جمع البيانات من خلال الترابط
من المجسات والمجمعات والمجمعات. يؤدي إجراء كل هذه الترابطات إلى
العديد من بيانات التكوين في برامج المستخدم. لسهولة الاستخدام ، فإن بعضًا من أكثرها شيوعًا
يمكن دمج العمليات وتغليفها في وظائف المساعدة. بالإضافة إلى بعض
البيانات التي تنطوي على NS-3 لا تحتوي مصادر التتبع على روابط Python ، بسبب القيود في
الارتباطات.

البيانات المجموعات المساعدون نظرة عامة
في هذا القسم ، نقدم نظرة عامة على بعض الفئات المساعدة التي تم إنشاؤها من أجلها
تسهيل تكوين إطار عمل جمع البيانات لبعض حالات الاستخدام الشائعة. ال
يسمح المساعدون للمستخدمين بتكوين عمليات مشتركة مع عدد قليل فقط من العبارات في C ++ أو
برامج بايثون. لكن سهولة الاستخدام هذه تأتي بتكلفة أقل بكثير
المرونة التي يمكن أن يوفرها التكوين منخفض المستوى ، والحاجة إلى رمز صريح
دعم أنواع مسبار جديدة في المساعدين (للتغلب على مشكلة موصوفة أدناه).

التركيز على المساعدين الحاليين هو تنظيم البيانات من NS-3 تتبع مصادر في
مخططات gnuplot أو ملفات نصية ، بدون درجة عالية من تخصيص الإخراج أو الإحصاء
المعالجة (في البداية). أيضًا ، يقتصر الاستخدام على أنواع المجسات المتوفرة في
NS-3. ستدخل الأقسام اللاحقة من هذه الوثائق في مزيد من التفاصيل حول إنشاء جديد
أنواع المجسات ، بالإضافة إلى تفاصيل حول ربط المجسات والمجمعات والتجمعات معًا
في الترتيبات المخصصة.

حتى الآن ، تم تنفيذ اثنين من مساعدي جمع البيانات:

· غنوبلوتهيلبر

FileHelper

مساعد Gnuplot
GnuplotHelper هي فئة مساعدة لإنتاج ملفات الإخراج المستخدمة لإنشاء gnuplots. ال
الهدف العام هو توفير القدرة للمستخدمين على إنشاء قطع بسرعة من البيانات المصدرة
in NS-3 مصادر التتبع. بشكل افتراضي ، يتم تنفيذ الحد الأدنى من تحويل البيانات ؛
الهدف هو إنشاء مخططات مع عدد قليل من عبارات التكوين (الافتراضية) مثل
ممكن.

مساعد Gnuplot نظرة عامة
سينشئ GnuplotHelper 3 ملفات مختلفة في نهاية المحاكاة:

مساحة منفصلة ملف البيانات gnuplot

ملف التحكم gnuplot

نص قذيفة لتوليد gnuplot

هناك نوعان من عبارات التكوين اللازمة لإنتاج المؤامرات. الأول
بيان تكوين المؤامرة (اسم الملف ، العنوان ، وسائل الإيضاح ، ونوع الإخراج ، حيث الإخراج
النوع الافتراضي هو PNG إذا لم يتم تحديده):

ConfigurePlot باطل (const std :: string & outputFileNameWithoutExtension ،
const std :: string & title،
const std :: string & xLegend ،
const std :: string & yLegend ،
const std :: string & terminalType = ".png") ؛

العبارة الثانية تربط مصدر الاهتمام:

PlotProbe باطل (const std :: string & typeId ،
const std :: string & path،
const std :: string & probeTraceSource ،
const std :: string & title) ؛

الحجج هي كما يلي:

typeId: ملف NS-3 TypeId للمسبار

· المسار: المسار في NS-3 التكوين لمصدر تتبع واحد أو أكثر

· probeTraceSource: ما هو ناتج المسبار (مصدر التتبع نفسه) الذي يجب رسمه

· العنوان: العنوان المطلوب ربطه بمجموعة (مجموعات) البيانات (في وسيلة إيضاح gnuplot)

أحد المتغيرات في PlotProbe أعلاه هو تحديد وسيطة اختيارية خامسة تتحكم
حيث يتم وضع المفتاح (وسيلة الإيضاح) في المؤامرة.

مثال يعمل بشكل كامل (من السابع) موضح أدناه:

// أنشئ مساعد gnuplot.
مخطط GnuplotHelper

// تكوين المؤامرة.
// تكوين المؤامرة. الوسيطة الأولى هي بادئة اسم الملف
// لملفات الإخراج التي تم إنشاؤها. الثاني والثالث والرابع
// الوسيطات هي ، على التوالي ، عناوين الرسم ، والمحور السيني ، والمحور الصادي
plotHelper.ConfigurePlot ("عدد الحزمة السابعة بايت" ،
"عدد بايتات الحزم مقابل الوقت" ،
"الوقت (بالثواني)" ،
"عدد بايت الحزم" ،
"بي إن جي")؛

// حدد نوع الفحص ومسار مصدر التتبع (في مساحة اسم التكوين) و
// فحص مصدر تتبع الإخراج ("OutputBytes") للتخطيط. الحجة الرابعة
// يحدد اسم تسمية سلسلة البيانات على قطعة الأرض. الاخير
// الوسيطة تنسق الحبكة عن طريق تحديد المكان الذي يجب أن يوضع فيه المفتاح.
plotHelper.PlotProbe (نوع المسبار ،
tracePath ،
"OutputBytes"،
"عدد بايت الحزم" ،
GnuplotAggregator :: KEY_BELOW) ؛

في هذا المثال ، نوع المسبار com.tracePath هي كما يلي (لـ IPv4):

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

يعتبر probeType معلمة أساسية لعمل هذا المساعد. يجب تسجيل معرّف TypeId هذا
في النظام ، ويجب أن يتطابق التوقيع الموجود على مصدر التتبع الخاص بالمسبار مع توقيع التتبع
المصدر الذي يتم ربطه به. أنواع المجسات محددة مسبقًا لعدد من أنواع البيانات
الموافق NS-3 القيم المتتبعة ، ولعدد قليل من تواقيع مصدر التتبع الأخرى مثل
مصدر تتبع "Tx" لـ ns3 :: Ipv4L3Protocol فئة.

لاحظ أن مسار مصدر التتبع المحدد قد يحتوي على أحرف بدل. في هذه الحالة ، متعددة
يتم رسم مجموعات البيانات على قطعة أرض واحدة ؛ واحد لكل مسار مطابق.

الناتج الرئيسي سيكون ثلاثة ملفات:

الحزمة السابعة بايت عدد. dat
العدد السابع للحزمة البايت
الحزمة السابعة بايت- العد. sh

في هذه المرحلة ، يمكن للمستخدمين إما تحرير ملف .plt لمزيد من التخصيصات ، أو
فقط قم بتشغيله من خلال gnuplot. جري sh الحزمة السابعة بايت- العد. sh يدير المؤامرة ببساطة
من خلال gnuplot ، كما هو موضح أدناه.
[صورة] 2-D Gnuplot تم إنشاؤه بواسطة مثال XNUMXth.cc..UNINDENT

يمكن ملاحظة أن العناصر الأساسية (وسيلة الإيضاح ، العنوان ، موضع وسيلة الإيضاح ، xlabel ، ylabel ،
ومسار البيانات) كلها موضوعة على قطعة الأرض. منذ أن كانت هناك مطابقتان ل
مسار التكوين المقدم ، يتم عرض سلسلتي البيانات:

· عدد بايتات الحزم 0 يتوافق مع / NodeList / 0 / $ ns3 :: Ipv4L3Protocol / Tx

· عدد بايتات الحزم 1 يتوافق مع / NodeList / 1 / $ ns3 :: Ipv4L3Protocol / Tx

مساعد Gnuplot تكوينالمؤامرة
GnuplotHelper's ConfigurePlot () يمكن استخدام الوظيفة لتكوين المؤامرات.

لديها النموذج الأولي التالي:

ConfigurePlot باطل (const std :: string & outputFileNameWithoutExtension ،
const std :: string & title،
const std :: string & xLegend ،
const std :: string & yLegend ،
const std :: string & terminalType = ".png") ؛

لها الحجج التالية:

┌───────────────────────────────┬───────────────── ─────────────────┐
│ الوسيطة │ الوصف │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension اسم ملفات gnuplot ذات الصلة بـ
│ │ الكتابة بدون تمديد. │
├───────────────────────────────┼───────────────── ─────────────────┤
│ العنوان │ سلسلة عنوان المؤامرة لاستخدامها في │
│ │ هذه المؤامرة. │
└───────────────────────────────┴───────────────── ─────────────────┘

│xLegend أسطورة x أفقي │
│ │ المحور. │
├───────────────────────────────┼───────────────── ─────────────────┤
“أسطورة” “أسطورة” عمودي “ص”
│ │ المحور. │
├───────────────────────────────┼───────────────── ─────────────────┤
│terminalType │ سلسلة ضبط نوع المحطة الطرفية لـ │
│ │ الإخراج. المحطة الافتراضية │
│ │ النوع هو "png". │
└───────────────────────────────┴───────────────── ─────────────────┘

GnuplotHelper's ConfigurePlot () تكوّن الوظيفة المعلمات ذات الصلة بالمؤامرة لهذا الغرض
gnuplot helper بحيث يقوم بإنشاء ملف بيانات gnuplot مفصول بمسافة باسم
outputFileNameWithoutExtension + ".dat" ، ملف تحكم gnuplot اسمه
outputFileNameWithoutExtension + ".plt" ، وبرنامج نصي شل لإنشاء gnuplot المسمى
outputFileNameWithoutExtension + ".sh".

يمكن رؤية مثال على كيفية استخدام هذه الوظيفة في ملف السابع الكود الموصوف أعلاه
حيث تم استخدامه على النحو التالي:

plotHelper.ConfigurePlot ("عدد الحزمة السابعة بايت" ،
"عدد بايتات الحزم مقابل الوقت" ،
"الوقت (بالثواني)" ،
"عدد بايت الحزم" ،
"بي إن جي")؛

مساعد Gnuplot مؤامرة
GnuplotHelper's PlotProbe () يمكن استخدام الوظيفة لرسم القيم التي تم إنشاؤها بواسطة المجسات.

لديها النموذج الأولي التالي:

PlotProbe باطل (const std :: string & typeId ،
const std :: string & path،
const std :: string & probeTraceSource ،
const std :: string & title،
تعداد GnuplotAggregator :: KeyLocation keyLocation = GnuplotAggregator :: KEY_INSIDE) ؛

لها الحجج التالية:

┌─────────────────┬─────────────────────────────── ───┐
│ الوسيطة │ الوصف │
├─────────────────┼─────────────────────────────── ───┤
│typeId معرف النوع للمسبار │
│ │ تم إنشاؤها بواسطة هذا المساعد. │
├─────────────────┼─────────────────────────────── ───┤
│ المسار │ تكوين المسار للوصول إلى التتبع │
│ │ المصدر. │
├─────────────────┼─────────────────────────────── ───┤
│probeTraceSource مصدر تتبع المجس إلى │
│ │ الوصول. │
├─────────────────┼─────────────────────────────── ───┤
│ العنوان │ العنوان المراد ربطه بـ │
│ │ مجموعة البيانات هذه │
├─────────────────┼─────────────────────────────── ───┤
│keyLocation موقع المفتاح في │
│ │ مؤامرة. الموقع الافتراضي هو │
│ │ بالداخل. │
└─────────────────┴─────────────────────────────── ───┘

GnuplotHelper's PlotProbe () ترسم الدالة مجموعة بيانات تم إنشاؤها عن طريق ربط ملف NS-3
مصدر التتبع باستخدام مسبار تم إنشاؤه بواسطة المساعد ، ثم رسم القيم من
فحص المصدر. سيكون لمجموعة البيانات العنوان المقدم ، وسوف تتكون من
"newValue" في كل طابع زمني.

إذا كان مسار التكوين يحتوي على أكثر من تطابق في النظام بسبب وجود حرف بدل ، إذن
سيتم رسم مجموعة بيانات واحدة لكل مباراة. سيتم إلحاق عناوين مجموعة البيانات بـ
الأحرف المتطابقة لكل من أحرف البدل في مسار التكوين ، مفصولة بمسافات. ل
على سبيل المثال ، إذا كان عنوان مجموعة البيانات المقترحة هو السلسلة "بايت" ، وكان هناك حرفان بدل
في المسار ، فإن عناوين مجموعة البيانات مثل "bytes-0 0" أو "bytes-12 9" ستكون ممكنة
تسميات لمجموعات البيانات المرسومة.

يمكن رؤية مثال على كيفية استخدام هذه الوظيفة في ملف السابع الكود الموصوف أعلاه
حيث تم استخدامه (مع استبدال متغير) على النحو التالي:

plotHelper.PlotProbe ("ns3 :: Ipv4PacketProbe"،
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx" ،
"OutputBytes"،
"عدد بايت الحزم" ،
GnuplotAggregator :: KEY_BELOW) ؛

أخرى أمثلة
غنوبلوت المساعد مثال
مثال أبسط قليلاً من السابع يمكن العثور على المثال في
src / stats / أمثلة / gnuplot-helper-example.cc. تم إنشاء gnuplot ثنائي الأبعاد التالي باستخدام
المثال.
[صورة] 2-D Gnuplot تم إنشاؤه بواسطة gnuplot-helper-example.cc مثال .. UNINDENT

في هذا المثال ، يوجد كائن Emitter يزيد من عداده وفقًا لـ
عملية Poisson ثم تنبعث قيمة العداد كمصدر تتبع.

Ptr باعث = CreateObject () ؛
الأسماء :: إضافة ("/ أسماء / باعث" ، باعث) ؛

لاحظ أنه نظرًا لعدم وجود أحرف بدل في المسار المستخدم أدناه ، كان هناك داتاستريم واحد فقط
مرسومة في المؤامرة. تم تسمية مجموعة البيانات المنفردة هذه في المؤامرة ببساطة باسم "عدد الباعث" ،
مع عدم وجود لاحقات إضافية مثل ما يمكن للمرء أن يرى ما إذا كان هناك أحرف البدل في المسار.

// أنشئ مساعد gnuplot.
مخطط GnuplotHelper

// تكوين المؤامرة.
plotHelper.ConfigurePlot ("gnuplot-helper-example"،
"الباعث يحسب مقابل الوقت" ،
"الوقت (بالثواني)" ،
"عدد الباعث"،
"بي إن جي")؛

// ارسم القيم التي تم إنشاؤها بواسطة المسبار. الطريق الذي نقدمه
// يساعد على إزالة الغموض عن مصدر التتبع.
plotHelper.PlotProbe ("ns3 :: Uinteger32Probe" ،
"/ Names / Emitter / Counter" ،
"انتاج"،
"عدد الباعث"،
GnuplotAggregator :: KEY_INSIDE) ؛

FileHelper
FileHelper عبارة عن فئة مساعدة تُستخدم لوضع قيم البيانات في ملف. الهدف العام هو
لتزويد المستخدمين بالقدرة على إنشاء ملفات نصية منسقة بسرعة من البيانات المصدرة
in NS-3 مصادر التتبع. بشكل افتراضي ، يتم تنفيذ الحد الأدنى من تحويل البيانات ؛
الهدف هو إنشاء ملفات مع عدد قليل من عبارات التكوين (الافتراضية) مثل
ممكن.

FileHelper نظرة عامة
سيقوم FileHelper بإنشاء ملف نصي واحد أو أكثر في نهاية المحاكاة.

يمكن لـ FileHelper إنشاء 4 أنواع مختلفة من الملفات النصية:

· منسق

مسافة مفصولة (الافتراضي)

· مفصولة بفواصل

· الجدولة مفصولة

تستخدم الملفات المنسقة سلاسل تنسيق نمط C ووظيفة sprintf () لطباعة ملفات
القيم الموجودة في الملف الذي تتم كتابته.

الملف النصي التالي مع عمودين من القيم المنسقة المسماة
الحزمة السابعة بايت عدد 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



الملف النصي المختلف التالي مع عمودين من القيم المنسقة المسماة
الحزمة السابعة بايت عدد 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



الكود الجديد الذي تمت إضافته لإنتاج الملفين النصيين أدناه. مزيد من التفاصيل حول
سيتم تغطية واجهة برمجة التطبيقات هذه في قسم لاحق.

لاحظ أنه نظرًا لوجود 2 تطابق لحرف البدل في المسار ، هناك ملفان نصيان منفصلان
خلقوا. الملف النصي الأول ، والذي يحمل الاسم "0th-packet-byte-count-XNUMX.txt" ،
يتوافق مع تطابق حرف البدل مع استبدال "*" بـ "0". الملف النصي الثاني ،
والتي تسمى "الحزمة السابعة بايت عدد 1.txt" ، يتوافق مع تطابق حرف البدل مع
تم استبدال "*" بـ "1". لاحظ أيضًا أن استدعاء الوظيفة لـ كتابة مسبار () سيعطي
رسالة خطأ إذا لم تكن هناك مطابقات لمسار يحتوي على أحرف البدل.

// إنشاء الملف المساعد.
FileHelper fileHelper ؛

// تكوين الملف المراد كتابته.
fileHelper.ConfigureFile ("عدد الحزم السابعة بايت" ،
FileAggregator :: FORMATTED) ؛

// تعيين التسميات لملف الإخراج المنسق هذا.
fileHelper.Set2dFormat ("الوقت (ثوان) =٪ .3e \ t عدد وحدات البايت =٪ .0f")؛

// اكتب القيم التي تم إنشاؤها بواسطة المسبار.
fileHelper.WriteProbe ("ns3 :: Ipv4PacketProbe"،
"/ NodeList / * / $ ns3 :: Ipv4L3Protocol / Tx" ،
"OutputBytes") ؛

FileHelper تكوين الملف
FileHelper's تكوين ملف () يمكن استخدام الوظيفة لتكوين ملفات نصية.

لديها النموذج الأولي التالي:

ConfigureFile باطل (const std :: string & outputFileNameWithoutExtension ،
تعداد FileAggregator :: FileType fileType = FileAggregator :: SPACE_SEPARATED) ؛

لها الحجج التالية:

┌───────────────────────────────┬───────────────── ─────────────────┐
│ الوسيطة │ الوصف │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension اسم ملف الإخراج المراد كتابته
│ │ بدون تمديد. │
├───────────────────────────────┼───────────────── ─────────────────┤
│ نوع الملف │ نوع الملف المراد كتابته. │
│ النوع الافتراضي للملف هو space
│ │ مفصول. │
└───────────────────────────────┴───────────────── ─────────────────┘

FileHelper's تكوين ملف () تعمل الوظيفة على تكوين المعلمات ذات الصلة بالملف النصي لـ
file helper بحيث يقوم بإنشاء ملف يسمى outputFileNameWithoutExtension plus
معلومات إضافية محتملة من مطابقات أحرف البدل بالإضافة إلى ".txt" بقيم مطبوعة بتنسيق
محدد بواسطة نوع الملف. نوع الملف الافتراضي هو مفصول بمسافات.

يمكن رؤية مثال على كيفية استخدام هذه الوظيفة في ملف السابع الكود الموصوف أعلاه
حيث تم استخدامه على النحو التالي:

fileHelper.ConfigureFile ("عدد الحزم السابعة بايت" ،
FileAggregator :: FORMATTED) ؛

FileHelper اكتب مسبار
FileHelper's كتابة مسبار () يمكن استخدام الوظيفة لكتابة القيم التي تم إنشاؤها بواسطة المسابير إلى
ملفات نصية.

لديها النموذج الأولي التالي:

WriteProbe باطل (const std :: string & typeId ،
const std :: string & path،
const std :: string & probeTraceSource) ؛

لها الحجج التالية:

┌─────────────────┬─────────────────────────────── ───┐
│ الوسيطة │ الوصف │
├─────────────────┼─────────────────────────────── ───┤
│typeId معرف النوع للمسبار ليكون │
│ │ تم إنشاؤه. │
├─────────────────┼─────────────────────────────── ───┤
│ المسار │ تكوين المسار للوصول إلى التتبع │
│ │ المصدر. │
├─────────────────┼─────────────────────────────── ───┤
│probeTraceSource مصدر تتبع المجس إلى │
│ │ الوصول. │
└─────────────────┴─────────────────────────────── ───┘

FileHelper's كتابة مسبار () تقوم الوظيفة بإنشاء ملفات نصية ناتجة تم إنشاؤها عن طريق ربط ملف
مصدر التتبع ns-3 بمسبار تم إنشاؤه بواسطة المساعد ، ثم كتابة القيم من
فحص المصدر. ستحتوي أسماء ملفات الإخراج على النص المخزن في متغير العضو
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 / أمثلة / file-helper-example.cc. يستخدم هذا المثال ملف FileHelper فقط.

الملف النصي التالي مع عمودين من القيم المنسقة المسماة ملف مساعد- 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 يزيد من عداده وفقًا لـ
عملية Poisson ثم تنبعث قيمة العداد كمصدر تتبع.

Ptr باعث = CreateObject () ؛
الأسماء :: إضافة ("/ أسماء / باعث" ، باعث) ؛

لاحظ أنه نظرًا لعدم وجود أحرف بدل في المسار المستخدم أدناه ، كان هناك ملف نصي واحد فقط
مخلوق. يسمى هذا الملف النصي الفردي ببساطة "file-helper-example.txt" ، بدون أي إضافات
اللواحق كما لو كانت هناك أحرف بدل في المسار.

// إنشاء الملف المساعد.
FileHelper fileHelper ؛

// تكوين الملف المراد كتابته.
fileHelper.ConfigureFile ("ملف مساعد-مثال" ،
FileAggregator :: FORMATTED) ؛

// تعيين التسميات لملف الإخراج المنسق هذا.
fileHelper.Set2dFormat ("الوقت (ثوان) =٪ .3e \ tCount =٪ .0f") ؛

// اكتب القيم التي تم إنشاؤها بواسطة المسبار. الطريق الذي نحن
// تقديم يساعد على إزالة الغموض عن مصدر التتبع.
fileHelper.WriteProbe ("ns3 :: Uinteger32Probe" ،
"/ Names / Emitter / Counter" ،
"انتاج")؛

مجال القيود
حاليًا ، تم تنفيذ هذه المجسات فقط وتوصيلها بـ GnuplotHelper و
إلى FileHelper:

· مسبار بوليان

· DoubleProbe

· التحقيق Uinteger8

· التحقيق Uinteger16

· التحقيق Uinteger32

· تايم بروب

· مسبار الحزم

· ApplicationPacketProbe

· IPv4PacketProbe

وبالتالي ، فإن هذه المجسات هي النوع الوحيد المتاح للاستخدام فيه PlotProbe ()
كتابة مسبار ().

في الأقسام القليلة التالية ، نغطي كل نوع من أنواع الكائنات الأساسية (Probe ، Collector ،
و Aggregator) بمزيد من التفصيل ، وإظهار كيف يمكن توصيلهما معًا باستخدام
المستوى الأدنى API.

تحقيقات
يوضح هذا القسم تفاصيل الوظائف التي توفرها فئة Probe إلى ملف NS-3
محاكاة ، ويعطي أمثلة على كيفية ترميزها في أحد البرامج. هذا القسم مخصص لـ
المستخدمون المهتمون بتطوير عمليات المحاكاة باستخدام NS-3 الأدوات واستخدام البيانات
Collection Framework ، التي تعد فئة Probe جزءًا منها ، لإنشاء إخراج البيانات باستخدام
نتائج المحاكاة الخاصة بهم.

مسبار نظرة عامة
من المفترض أن يكون كائن المسبار متصلاً بمتغير من المحاكاة التي تكون قيمها
خلال التجربة ذات الصلة بالمستخدم. سيسجل المسبار ما كان
القيم التي يفترضها المتغير خلال المحاكاة وتمرير هذه البيانات إلى آخر
عضو في إطار جمع البيانات. بينما هو خارج نطاق هذا القسم ل
ناقش ما يحدث بعد أن ينتج المسبار مخرجاته ، يكفي أن نقول ذلك ، بواسطة
في نهاية المحاكاة ، سيكون لدى المستخدم معلومات مفصلة حول القيم التي كانت
مخزنة داخل المتغير الذي يتم فحصه أثناء المحاكاة.

عادةً ما يكون المسبار متصلًا بملف NS-3 مصدر التتبع. بهذه الطريقة ، كلما
يقوم مصدر التتبع بتصدير قيمة جديدة ، ويستهلك المسبار القيمة (ويصدرها في اتجاه مجرى النهر
إلى كائن آخر عبر مصدر التتبع الخاص به).

يمكن اعتبار المسبار كنوع من مرشح على مصادر التتبع. الأسباب الرئيسية ل
من المحتمل أن يتم ربط المسبار بدلاً من مصدر التتبع مباشرة كما يلي:

· قد يتم تشغيل وإيقاف المجسات ديناميكيًا أثناء المحاكاة مع المكالمات إلى يُمكَِن()
إبطال(). على سبيل المثال ، قد يتم إيقاف إخراج البيانات أثناء
مرحلة إحماء المحاكاة.

· قد تقوم المجسات بإجراء عمليات على البيانات لاستخراج القيم من أكثر تعقيدًا
الهياكل؛ على سبيل المثال ، إخراج قيمة حجم الحزمة من حزمة مستلمة ns3 :: Packet.

· تقوم المجسات بتسجيل اسم في ns3 :: Config مساحة الاسم (باستخدام الأسماء :: إضافة ()) حتى أن الآخرين
قد تشير الأشياء إليهم.

· توفر المجسات طريقة ثابتة تسمح للشخص بمعالجة المسبار بالاسم ، مثل
ما الذي يتم في مقياس ns2measure [Cic06]

Stat :: put ("my_metric" ، معرف ، عينة) ؛

المكافئ ns-3 لرمز القياس ns2 أعلاه ، على سبيل المثال

DoubleProbe :: SetValueByPath ("/ path / to / probe" ، عينة) ؛

خلق
لاحظ أنه لا يمكن إنشاء كائن فئة أساسية Probe لأنه قاعدة مجردة
class ، أي أنها تحتوي على وظائف افتراضية خالصة لم يتم تنفيذها. كائن من
سيتم إنشاء نوع DoubleProbe ، وهو فئة فرعية من فئة Probe ، هنا للعرض
ما يجب القيام به.

يقوم أحدهم بتعريف DoubleProbe في الذاكرة الديناميكية باستخدام فئة المؤشر الذكي (Ptr ). ل
إنشاء DoubleProbe في ذاكرة ديناميكية باستخدام مؤشرات ذكية ، يحتاج المرء فقط إلى استدعاء
NS-3 طريقة إنشاء كائن():

Ptr myprobe = CreateObject () ؛

يُنشئ الإعلان أعلاه DoubleProbes باستخدام القيم الافتراضية لسماته.
هناك أربع سمات في فئة DoubleProbe؛ اثنان في كائن الفئة الأساسية
DataCollectionObject ، واثنان في فئة Probe الأساسية:

· "الاسم" (DataCollectionObject) ، قيمة StringValue

"ممكّن" (DataCollectionObject) ، قيمة منطقية

· "ابدأ" (دقق) ، قيمة زمنية

· "توقف" (دقق) ، قيمة زمنية

يمكن للمرء تعيين هذه السمات عند إنشاء الكائن باستخدام الطريقة التالية:

Ptr myprobe = CreateObjectWithAttributes (
"الاسم" ، StringValue ("myprobe") ،
"ممكّن" ، قيمة منطقية (خطأ) ،
"Start" ، TimeValue (ثواني (100.0)) ،
"Stop"، TimeValue (Seconds (1000.0))) ؛

البداية والإيقاف هي متغيرات الوقت التي تحدد الفاصل الزمني لعمل المسبار. ال
سيقوم المسبار بإخراج البيانات فقط إذا كان الوقت الحالي للمحاكاة داخل ذلك
فاصلة. ستعمل قيمة الوقت الخاصة البالغة 0 ثانية للإيقاف على تعطيل هذه السمة (على سبيل المثال
استمر في تشغيل المسبار للمحاكاة بأكملها). Enabled هي علامة تقوم بتشغيل Probe أو
متوقف ، ويجب ضبطه على "صواب" لكي يقوم المسبار بتصدير البيانات. الاسم هو اسم الكائن
في إطار DCF.

استيراد تصدير البيانات
NS-3 يتم كتابة مصادر التتبع بقوة ، وبالتالي فإن آليات ربط المجسات بالتتبع
المصدر وتصدير البيانات تنتمي إلى الفئات الفرعية. على سبيل المثال ، الافتراضي
توزيع لل NS-3 يوفر فئة DoubleProbe المصممة لربط التتبع
مصدر تصدير قيمة مزدوجة. سنقوم بعد ذلك بتفصيل عملية DoubleProbe و
ثم ناقش كيف يمكن للمستخدم تعريف فئات المسبار الأخرى.

دبلبروب نظرة عامة
يتصل DoubleProbe بملف NS-3 مصدر التتبع ، ويصدر نفسه أ
مختلفة مزدوجة القيمة NS-3 مصدر التتبع.

الكود التالي مأخوذ من src / stats / أمثلة / double-probe-example.cc، يظهر الأساسيات
عمليات سباكة DoubleProbe في محاكاة ، حيث يتم فحص عداد
تم تصديره بواسطة كائن باعث (class Emitter).

Ptr باعث = CreateObject () ؛
الأسماء :: إضافة ("/ أسماء / باعث" ، باعث) ؛


Ptr probe1 = CreateObject () ؛

// قم بتوصيل المجس بعداد المرسل
bool متصل = probe1-> ConnectByObject ("Counter" ، باعث) ؛

تقوم التعليمة البرمجية التالية بفحص نفس العداد الذي تم تصديره بواسطة نفس كائن المرسل. هذا
ومع ذلك ، يستخدم 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 كـ
يتبع:

باطل
باعث :: العد (باطل)
{

m_counter + = 1.0 ؛
DoubleProbe :: SetValueByPath ("/ Names / StaticallyAccessedProbe"، m_counter) ؛

}

يوضح المثال أعلاه كيف أن الكود الذي يستدعي المسبار لا يجب أن يكون صريحًا
مرجع إلى المسبار ، ولكن يمكنه توجيه إعداد القيمة من خلال مساحة اسم التكوين.
هذا مشابه في وظائف ستات :: وضع الطريقة التي أدخلتها ns2measure paper
[Cic06] ، ويسمح للمستخدمين بإدراج عبارات Probe مؤقتًا مثل printf البيانات
ضمن القائمة NS-3 عارضات ازياء. لاحظ أنه من أجل أن تكون قادرًا على استخدام DoubleProbe في هذا
مثال كهذا ، شيئان ضروريان:

1. تم تضمين ملف رأس وحدة الإحصائيات في مثال ملف .cc

2. تم جعل المثال يعتمد على وحدة الإحصائيات في ملف wscript الخاص بها.

يجب القيام بأشياء مماثلة من أجل إضافة مجسات أخرى في أماكن أخرى في NS-3
قاعدة التعليمات البرمجية.

يمكن أيضًا تعيين قيم DoubleProbe باستخدام الوظيفة DoubleProbe :: SetValue () ،
بينما يمكن الحصول على قيم DoubleProbe باستخدام الوظيفة
DoubleProbe :: GetValue ().

يقوم DoubleProbe بتصدير قيم مزدوجة في مصدر تتبع "الإخراج" الخاص به؛ كائن المصب
يمكن ربط حوض التتبع (NotifyViaProbe) بهذا على النحو التالي:

متصل = probe1-> TraceConnect ("Output"، 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) إلى ملفين
ملفات جديدة بأسماء تطابق مسبارك الجديد.

· استبدال الأنواع والحجج والمتغيرات في الملفات المنسوخة بالمناسبة
اكتب للمسبار الخاص بك.

· قم بإجراء التعديلات اللازمة لجعل الشفرة ترجمة ولجعلها تتصرف كما تريد
أحب.

أمثلة
سيتم مناقشة مثالين بالتفصيل هنا:

مثال مسبار مزدوج

مثال على حزمة IPv4

مزدوج مسبار مثال
تمت مناقشة مثال المسبار المزدوج سابقًا. يمكن العثور على مثال البرنامج
in src / stats / أمثلة / double-probe-example.cc. لتلخيص ما يحدث في هذا البرنامج ،
هناك باعث يصدر عدادًا يتزايد وفقًا لعملية بواسون.
على وجه الخصوص ، يتم عرض طريقتين لإصدار البيانات:

1. من خلال متغير تتبع مرتبط بمسبار واحد:

TracedValue m_counter ؛ // عادةً ما يكون هذا نوعًا صحيحًا

2. من خلال عداد تم ترحيل قيمته إلى مسبار ثان ، يشار إليه باسمه في
نظام التكوين:

باطل
باعث :: العد (باطل)
{
NS_LOG_FUNCTION (هذا) ،
NS_LOG_DEBUG ("العد عند" << Simulator :: Now () .GetSeconds ()) ؛
m_counter + = 1.0 ؛
DoubleProbe :: SetValueByPath ("/ Names / StaticallyAccessedProbe"، m_counter) ؛
المحاكاة :: الجدول (الثواني (m_var-> GetValue ()) ، والباعث :: Count ، هذا) ؛
}

دعونا ننظر إلى المسبار بعناية أكبر. يمكن أن تتلقى المجسات قيمها في صورة مضاعفة
طرق:

1. بواسطة المجس للوصول إلى مصدر التتبع مباشرة وربط حوض التتبع به

2. بواسطة المسبار للوصول إلى مصدر التتبع من خلال مساحة اسم التكوين وتوصيل أ
تتبع الغرق إليه

3. بواسطة كود الاستدعاء صراحة استدعاء المسبار SetValue () طريقة

4. بواسطة كود الاستدعاء صراحة SetValueByPath
("/ path / through / Config / namespace"، ...)

من المتوقع أن تكون أول طريقتين هي الأكثر شيوعًا. أيضًا في المثال ، ملف
يتم عرض ربط وظيفة رد الاتصال العادية ، كما هو الحال عادةً في NS-3. هذا
وظيفة رد الاتصال غير مرتبطة بكائن مسبار. سنسمي هذه الحالة 0) أدناه.

// هذه وظيفة لاختبار ربط دالة خام بمصدر التتبع
باطل
NotifyViaTraceSource (سياق std :: string ، double oldVal ، double newVal)
{
NS_LOG_DEBUG ("السياق:" << سياق << "قديم" << oldVal << "new" << newVal) ؛
}

أولاً ، يحتاج الباعث إلى الإعداد:

Ptr باعث = CreateObject () ؛
الأسماء :: إضافة ("/ أسماء / باعث" ، باعث) ؛

// لا يرتبط الكائن Emitter بعقدة ns-3 ، لذلك
// لن تبدأ تلقائيًا ، لذلك نحن بحاجة إلى القيام بذلك بأنفسنا
المحاكاة :: الجدول (الثواني (0.0) ، والباعث :: البداية ، الباعث) ؛

تتفاعل DoubleProbes المختلفة مع الباعث في المثال كما هو موضح أدناه.

الحالة 0):

// يظهر أدناه وظائف نموذجية بدون مسبار
// (قم بتوصيل وظيفة الحوض بمصدر التتبع)
//
متصل = باعث-> TraceConnect ("عداد" ، "سياق عينة" ، MakeCallback (& ​​NotifyViaTraceSource)) ؛
NS_ASSERT_MSG (متصل ، "مصدر التتبع غير متصل") ؛

حالة 1):

//
// سيتم ربط Probe1 مباشرة بكائن مصدر تتبع Emitter
//

// سيتم ربط المسبار 1 بمصدر تتبع Emitter
Ptr probe1 = CreateObject () ؛
// يمكن أن يكون اسم المسبار بمثابة سياقه في التتبع
probe1-> SetName ("ObjectProbe") ؛

// قم بتوصيل المجس بعداد المرسل
متصل = probe1-> ConnectByObject ("عداد" ، باعث) ؛
NS_ASSERT_MSG (متصل ، "مصدر التتبع غير متصل بـ probe1") ؛

حالة 2):

//
// سيتم ربط Probe2 بكائن مصدر تتبع Emitter بواسطة
// الوصول إليه عن طريق اسم المسار في قاعدة بيانات التكوين
//

// إنشاء مسبار آخر مماثل ؛ سيؤدي ذلك إلى التوصيل عبر مسار التكوين
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") ؛

تم ربط رد الاتصال التالي بالمسبار في هذا المثال لأغراض توضيحية ؛
عادة ، سيتم ربط المسبار بكائن جامع.

// هذه وظيفة لاختبار ربطه بمخرج المجس
باطل
NotifyViaProbe (std :: string Context، double oldVal، double newVal)
{
NS_LOG_DEBUG ("السياق:" << سياق << "قديم" << oldVal << "new" << newVal) ؛
}

IPv4 رزمة قطعة مثال
يعتمد مثال مخطط حزمة IPv4 على المثال الخامس من ملف NS-3 درس تعليمي. هو - هي
يمكن العثور عليها في src / stats / أمثلة / ipv4-packet-plot-example.cc.

العقدة 0 العقدة 1
+ ---------------- + + ---------------- +
| NS-3 TCP | | NS-3 TCP |
+ ---------------- + + ---------------- +
| 10.1.1.1 | | 10.1.1.2 |
+ ---------------- + + ---------------- +
| من نقطة إلى نقطة | | من نقطة إلى نقطة |
+ ---------------- + + ---------------- +
| |
+ --------------------- +

سنلقي نظرة فقط على المسبار ، لأنه يوضح أن المجسات قد تفك حزم القيم أيضًا من
الهياكل (في هذه الحالة ، الحزم) والإبلاغ عن هذه القيم كمخرجات تتبع المصدر ، بدلاً من ذلك
من مجرد المرور عبر نفس النوع من البيانات.

هناك جوانب أخرى لهذا المثال سيتم شرحها لاحقًا في التوثيق.
نوعا البيانات التي يتم تصديرها هما الحزمة نفسها (الناتج) وعدد من
عدد البايت في الحزمة (بايتات الإخراج).

النوع
Ipv4PacketProbe :: GetTypeId ()
{
ثابت 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 << الواجهة) ؛
إذا (IsEnabled ())
{
m_packet = حزمة ؛
m_ipv4 = ipv4 ؛
m_interface = الواجهة ؛
m_output (حزمة ، ipv4 ، واجهة) ؛

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

مراجع حسابات
[Cic06]
كلاوديو سيكونيتي ، إنزو مينجوزي ، جيوفاني ستيا ، "إطار متكامل لـ
تمكين جمع البيانات والتحليل الإحصائي الفعال مع ns2 ، ورشة عمل حول
ns-2 (WNS2) ، بيزا ، إيطاليا ، أكتوبر 2006.

جامعي
هذا القسم هو عنصر نائب لتفاصيل الوظائف التي يوفرها المُجمع
فئة ل NS-3 محاكاة ، ويعطي أمثلة على كيفية ترميزها في أحد البرامج.

ملحوظة: اعتبارًا من ns-3.18 ، لا يزال المقتنيات قيد التطوير ولم يتم توفيرها كجزء
من الإطار.

تجميع
يوضح هذا القسم تفاصيل الوظائف التي توفرها فئة المُجمِّع إلى ملف NS-3
محاكاة. هذا القسم مخصص للمستخدمين المهتمين بتطوير عمليات المحاكاة باستخدام
NS-3 الأدوات واستخدام إطار عمل جمع البيانات ، والذي تعتبر فئة المُجمِّع منه
الجزء ، لتوليد إخراج البيانات مع نتائج المحاكاة الخاصة بهم.

مجمع نظرة عامة
من المفترض أن يتم ربط كائن المجمع بواحد أو أكثر من مصادر التتبع من أجل
تلقي المدخلات. المُجمِّعون هم نقطة نهاية البيانات التي تم جمعها بواسطة شبكة
المجسات والجامع أثناء المحاكاة. إنها مهمة المجمع أن يأخذ هذه الأشياء
القيم وتحويلها إلى تنسيق الإخراج النهائي مثل ملفات النص العادي ،
ملفات جداول البيانات أو المؤامرات أو قواعد البيانات.

عادةً ما يكون المُجمِّع متصلاً بواحد أو أكثر من المُجمِّعين. بهذه الطريقة ، في أي وقت
تقوم مصادر تتبع المُجمِّعين بتصدير قيم جديدة ، ويمكن للمُجمِّع معالجة القيمة على هذا النحو
أنه يمكن استخدامه في تنسيق الإخراج النهائي حيث توجد قيم البيانات بعد
محاكاة.

لاحظ ما يلي حول المُجمِّعين:

المُجمِّع قد يتم تشغيله وإيقاف تشغيله ديناميكيًا أثناء المحاكاة مع المكالمات إلى
يُمكَِن() إبطال(). على سبيل المثال ، قد يتم إيقاف تجميع البيانات أثناء
مرحلة إحماء المحاكاة ، مما يعني أن هذه القيم لن يتم تضمينها في المرحلة النهائية
وسط الإخراج.

المُجمِّعون يتلقون البيانات من المُجمِّعين عبر عمليات الاسترداد. عندما يرتبط المُجمع
إلى مجمع ، يتم إجراء استدعاء لـ TraceConnect لتأسيس تتبع العارض
طريقة الحوض كإعادة اتصال.

حتى الآن ، تم تنفيذ اثنين من المُجمِّعين:

· مجمع GnuplotAggregator

مجمع الملفات

مجمّع Gnuplot
ينتج GnuplotAggregator ملفات الإخراج المستخدمة لإنشاء gnuplots.

سيقوم GnuplotAggregator بإنشاء 3 ملفات مختلفة في نهاية المحاكاة:

مساحة منفصلة ملف البيانات gnuplot

ملف التحكم gnuplot

نص قذيفة لتوليد gnuplot

خلق
سيتم إنشاء كائن من النوع GnuplotAggregator هنا لإظهار ما يجب القيام به.

يقوم أحدهم بتعريف GnuplotAggregator في ذاكرة ديناميكية باستخدام فئة المؤشر الذكي
(Ptr ). لإنشاء مجمّع GnuplotAggregator في ذاكرة ديناميكية باستخدام مؤشرات ذكية ، واحد فقط
يحتاج إلى استدعاء NS-3 طريقة إنشاء كائن(). الكود التالي من
src / stats / أمثلة / gnuplot-aggregator-example.cc يوضح كيفية القيام بذلك:

سلسلة fileNameWithoutExtension = "gnuplot-aggregator" ؛

// إنشاء مجمع.
Ptr المجمّع =
إنشاء كائن (fileNameWithoutExtension) ؛

الوسيطة الأولى للمُنشئ ، fileNameWithoutExtension ، هي اسم ملف
gnuplot ذات الصلة بالكتابة بدون امتداد. سيقوم GnuplotAggregator هذا بإنشاء ملف
ملف بيانات gnuplot مفصول بمسافة باسم "gnuplot-aggregator.dat" ، ملف تحكم gnuplot
باسم "gnuplot-aggregator.plt" ، ونص برمجي شل لإنشاء gnuplot المسمى +
"gnuplot-aggregator.sh".

يمكن أن يكون لـ gnuplot الذي تم إنشاؤه مفتاحه في 4 مواقع مختلفة:

· لا مفتاح

· المفتاح داخل الحبكة (الافتراضي)

· المفتاح فوق المؤامرة

· المفتاح أدناه المؤامرة

يُسمح لقيم تعداد موقع مفتاح gnuplot التالية بتحديد موضع المفتاح:

تعداد KeyLocation {
لا مفتاح،
KEY_INSIDE ،
KEY_ABOVE ،
المفتاح_أدناه
};

إذا كان مطلوبًا أن يكون لديك المفتاح أدناه بدلاً من الموضع الافتراضي للداخل ، إذن
يمكنك القيام بما يلي.

المجمع-> SetKeyLocation (GnuplotAggregator :: KEY_BELOW) ؛

أمثلة
سيتم مناقشة أحد الأمثلة بالتفصيل هنا:

مثال مجمع Gnuplot

غنوبلوت مجمع مثال
يمكن العثور على مثال يقوم بتمارين GnuplotAggregator في
src / stats / أمثلة / gnuplot-aggregator-example.cc.

تم إنشاء gnuplot ثنائي الأبعاد التالي باستخدام المثال.
[صورة] 2-D Gnuplot تم إنشاؤه بواسطة gnuplot-aggregator-example.cc مثال .. UNINDENT

يوضح هذا الرمز من المثال كيفية إنشاء GnuplotAggregator كما تمت مناقشته
في الاعلى.

Create2dPlot () باطلة
{
باستخدام مساحة الاسم الأمراض المنقولة جنسيا.

سلسلة fileNameWithoutExtension = "gnuplot-aggregator" ؛
string plotTitle = "Gnuplot Aggregator Plot"؛
سلسلة plotXAxisHeading = "الوقت (بالثواني)" ؛
سلسلة plotYAxisHeading = "قيم مزدوجة" ؛
سلسلة plotDatasetLabel = "قيم البيانات" ؛
سلسلة datasetContext = "مجموعة البيانات / السياق / السلسلة"؛

// إنشاء مجمع.
Ptr المجمّع =
إنشاء كائن (fileNameWithoutExtension) ؛

يتم تعيين سمات GnuplotAggregator المختلفة بما في ذلك مجموعة البيانات ثنائية الأبعاد التي ستكون
مؤامرة.

// تعيين خصائص المجمّع.
المجمع-> SetTerminal ("png") ؛
المجمع-> SetTitle (plotTitle) ؛
المجمع-> SetLegend (plotXAxisHeading ، plotYAxisHeading) ؛

// أضف مجموعة بيانات إلى المُجمع.
المجمع-> Add2dDataset (datasetContext ، plotDatasetLabel) ؛

// يجب أن يكون المجمّع قيد التشغيل
المجمع-> تمكين () ؛

بعد ذلك ، يتم حساب القيم ثنائية الأبعاد ، ويتم كتابة كل واحدة على حدة إلى
GnuplotAggregator باستخدام امتداد Write2d () وظيفة.

وقت مضاعف؛
قيمة مزدوجة

// أنشئ مجموعة بيانات ثنائية الأبعاد.
لـ (الوقت = -5.0 ؛ الوقت <= +5.0 ؛ الوقت + = 1.0)
{
// احسب منحنى 2-D
//
/ / 2
// القيمة = الوقت.
//
القيمة = الوقت * الوقت ؛

// أضف هذه النقطة إلى المؤامرة.
المجمع-> Write2d (datasetContext ، الوقت ، القيمة) ؛
}

// تعطيل تسجيل البيانات للمجمع.
المجمع-> تعطيل () ؛
}

مجمع الملفات
يرسل FileAggregator القيم التي يتلقاها إلى ملف.

يمكن لـ FileAggregator إنشاء 4 أنواع مختلفة من الملفات:

· منسق

مسافة مفصولة (الافتراضي)

· مفصولة بفواصل

· الجدولة مفصولة

تستخدم الملفات المنسقة سلاسل تنسيق نمط C ووظيفة sprintf () لطباعة ملفات
القيم الموجودة في الملف الذي تتم كتابته.

خلق
سيتم هنا إنشاء كائن من النوع FileAggregator لإظهار ما يجب القيام به.

يقوم أحدهم بتعريف FileAggregator في الذاكرة الديناميكية باستخدام فئة المؤشر الذكي (Ptr ).
لإنشاء مجمّع ملفات في ذاكرة ديناميكية باستخدام مؤشرات ذكية ، يحتاج المرء فقط إلى الاتصال
هيه NS-3 طريقة CreateObject. الكود التالي من
src / stats / أمثلة / file-aggregator-example.cc يوضح كيفية القيام بذلك:

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

// إنشاء مجمع يحتوي على قيم منسقة.
Ptr المجمّع =
إنشاء كائن (اسم الملف ، FileAggregator :: FORMATTED) ؛

الوسيطة الأولى للمُنشئ ، اسم الملف ، هي اسم الملف المراد كتابته ؛ ال
الوسيطة الثانية ، نوع الملف ، هي نوع الملف المراد كتابته. سيقوم FileAggregator هذا بإنشاء ملف
ملف يسمى "file-aggregator-formatted-values.txt" مع طباعة قيمه كما هو محدد بواسطة
نوع الملف ، أي تنسيقه في هذه الحالة.

يُسمح بقيم تعداد أنواع الملفات التالية:

تعداد نوع الملف {
منسق ،
SPACE_SEPARATED ،
مفصولة بفواصل،
TAB_SEPARATED
};

أمثلة
سيتم مناقشة أحد الأمثلة بالتفصيل هنا:

مثال مجمع الملف

قم بتقديم مجمع مثال
يمكن العثور على مثال يقوم بتمارين FileAggregator في
src / stats / أمثلة / file-aggregator-example.cc.

تم إنشاء الملف النصي التالي مع عمودين من القيم مفصولة بفاصلات باستخدام
مثال.

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

يوضح هذا الرمز من المثال كيفية إنشاء FileAggregator كما تمت مناقشته
في الاعلى.

CreateCommaSeparatedFile () باطلة
{
باستخدام مساحة الاسم الأمراض المنقولة جنسيا.

سلسلة fileName = "ملف-مجمّع-فاصلة-مفصول. txt" ؛
سلسلة datasetContext = "مجموعة البيانات / السياق / السلسلة"؛

// إنشاء مجمع.
Ptr المجمّع =
إنشاء كائن (اسم الملف ، FileAggregator :: COMMA_SEPARATED) ؛

يتم تعيين سمات FileAggregator.

// يجب أن يكون المجمّع قيد التشغيل
المجمع-> تمكين () ؛

بعد ذلك ، يتم حساب القيم ثنائية الأبعاد ، ويتم كتابة كل واحدة على حدة إلى
FileAggregator باستخدام امتداد الملف Write2d () وظيفة.

وقت مضاعف؛
قيمة مزدوجة

// أنشئ مجموعة بيانات ثنائية الأبعاد.
لـ (الوقت = -5.0 ؛ الوقت <= +5.0 ؛ الوقت + = 1.0)
{
// احسب منحنى 2-D
//
/ / 2
// القيمة = الوقت.
//
القيمة = الوقت * الوقت ؛

// أضف هذه النقطة إلى المؤامرة.
المجمع-> Write2d (datasetContext ، الوقت ، القيمة) ؛
}

// تعطيل تسجيل البيانات للمجمع.
المجمع-> تعطيل () ؛
}

تم أيضًا إنشاء الملف النصي التالي مع عمودين من القيم المنسقة باستخدام امتداد
مثال.

الوقت = -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 كما تمت مناقشته
في الاعلى.

CreateFormattedFile () باطلة
{
باستخدام مساحة الاسم الأمراض المنقولة جنسيا.

string fileName = "file-aggregator-formatted-values.txt" ؛
سلسلة datasetContext = "مجموعة البيانات / السياق / السلسلة"؛

// إنشاء مجمع يحتوي على قيم منسقة.
Ptr المجمّع =
إنشاء كائن (اسم الملف ، FileAggregator :: FORMATTED) ؛

يتم تعيين سمات FileAggregator ، بما في ذلك سلسلة تنسيق النمط C لاستخدامها.

// تعيين تنسيق القيم.
المجمع-> Set2dFormat ("الوقت =٪ .3e \ tValue =٪ .0f") ؛

// يجب أن يكون المجمّع قيد التشغيل
المجمع-> تمكين () ؛

بعد ذلك ، يتم حساب القيم ثنائية الأبعاد ، ويتم كتابة كل واحدة على حدة إلى
FileAggregator باستخدام امتداد الملف Write2d () وظيفة.

وقت مضاعف؛
قيمة مزدوجة

// أنشئ مجموعة بيانات ثنائية الأبعاد.
لـ (الوقت = -5.0 ؛ الوقت <= +5.0 ؛ الوقت + = 1.0)
{
// احسب منحنى 2-D
//
/ / 2
// القيمة = الوقت.
//
القيمة = الوقت * الوقت ؛

// أضف هذه النقطة إلى المؤامرة.
المجمع-> Write2d (datasetContext ، الوقت ، القيمة) ؛
}

// تعطيل تسجيل البيانات للمجمع.
المجمع-> تعطيل () ؛
}

محولات
يوضح هذا القسم تفاصيل الوظائف التي توفرها فئة المحول إلى ملف NS-3
محاكاة. هذا القسم مخصص للمستخدمين المهتمين بتطوير عمليات المحاكاة باستخدام
NS-3 الأدوات واستخدام إطار عمل جمع البيانات ، الذي تعتبر فئة المحول جزءًا منه ،
لتوليد إخراج البيانات مع نتائج المحاكاة الخاصة بهم.

ملاحظة: المصطلح "محول" يمكن أن يكون مكتوبًا أيضًا "محول" ؛ اخترنا محاذاة التدقيق الإملائي
مع معيار C ++.

محول نظرة عامة
يتم استخدام المحول لإجراء اتصالات بين أنواع مختلفة من كائنات DCF.

حتى الآن ، تم تنفيذ مهايئ واحد:

TimeSeriesAdaptor

الوقت: مسلسلات محول
يتيح TimeSeriesAdaptor للمسابقات الاتصال مباشرة بالمجمِّعين دون الحاجة إلى أي منها
جامع بينهما.

يستخدم كل من مساعدي DCF المنفذين TimeSeriesAdaptors من أجل إجراء اختبار
قيم من أنواع مختلفة وإخراج الوقت الحالي بالإضافة إلى القيمة مع كلاهما المحول
إلى الزوجي.

دور فئة TimeSeriesAdaptor هو دور المحول ، الذي يأخذ قيمة أولية
فحص البيانات من أنواع مختلفة وإخراج مجموعة من قيمتين مزدوجتين. الأول هو
الطابع الزمني ، والذي قد يتم تعيينه على درجات دقة مختلفة (على سبيل المثال ، ثوانٍ ، ميلي ثانية ، إلخ) في
المستقبل ولكنه حاليًا غير مقيد إلى ثوانٍ. والثاني هو تحويل أ
قيمة غير مزدوجة إلى قيمة مزدوجة (ربما مع فقدان الدقة).

النطاق / القيود
يناقش هذا القسم نطاق وحدود إطار عمل جمع البيانات.

حاليًا ، تم تنفيذ هذه المجسات فقط في DCF:

· مسبار بوليان

· DoubleProbe

· التحقيق Uinteger8

· التحقيق Uinteger16

· التحقيق Uinteger32

· تايم بروب

· مسبار الحزم

· ApplicationPacketProbe

· IPv4PacketProbe

حاليًا ، لا يتوفر مُجمع في DCF ، على الرغم من أن BasicStatsCollector أقل من
التنمية.

حاليًا ، تم تنفيذ المجمعين فقط في DCF:

· مجمع GnuplotAggregator

مجمع الملفات

حاليًا ، تم تنفيذ هذا المحول فقط في DCF:

محول سلسلة الوقت.

Future للعمل
يناقش هذا القسم العمل المستقبلي الذي يتعين القيام به في إطار عمل جمع البيانات.

فيما يلي بعض الأشياء التي لا يزال يتعين القيام بها:

ربط المزيد من مصادر التتبع في NS-3 كود للحصول على المزيد من القيم من المحاكاة.

· تنفيذ أنواع أكثر من المجسات الموجودة حاليًا.

· تنفيذ أكثر من مجرد جامع ثنائي الأبعاد ، BasicStatsCollector.

· تنفيذ المزيد من المُجمِّعين.

· تنفيذ أكثر من مجرد محولات.

DSDV ROUTING

يعد بروتوكول توجيه ناقل المسافة المتسلسل للوجهة (DSDV) بمثابة بروتوكول استباقي،
بروتوكول توجيه يعتمد على الجدول لـ MANETs تم تطويره بواسطة Charles E. Perkins وPravin
بهاجوات في عام 1994. ويستخدم عدد القفزات كمقياس في اختيار المسار.

تم تطوير هذا النموذج بواسطة هيه شبكات المرونة بحث رأس التجميع في جامعة كانساس. أ
الورق الخاص بهذا النموذج موجود في URL.

DSDV التوجيه نظرة عامة
جدول توجيه DSDV: ستحتفظ كل عقدة بجدول يسرد جميع العقد الأخرى الموجودة بها
معروفة سواء بشكل مباشر أو عن طريق بعض الجيران. كل عقدة لديها إدخال واحد في
جدول التوجيه. سيحتوي الإدخال على معلومات حول عنوان IP الخاص بالعقدة، والذي كان معروفًا آخر مرة
رقم التسلسل وعدد القفزات للوصول إلى تلك العقدة. جنبا إلى جنب مع هذه التفاصيل الجدول
يتتبع أيضًا الجار التالي للوصول إلى العقدة الوجهة، والطابع الزمني لـ
آخر تحديث تم تلقيه لتلك العقدة.

تتكون رسالة تحديث DSDV من ثلاثة حقول، عنوان الوجهة ورقم التسلسل و
عدد القفزات.

تستخدم كل عقدة آليتين لإرسال تحديثات DSDV. هم،

1.

دوري آخر التحديثات
يتم إرسال التحديثات الدورية بعد كل m_periodicUpdateInterval(افتراضي:15s).
في هذا التحديث، تقوم العقدة ببث جدول التوجيه بالكامل.

2.

تحفيز عملية آخر التحديثات
تحديثات التشغيل هي تحديثات صغيرة بين التحديثات الدورية. هذه التحديثات
يتم إرسالها عندما تتلقى العقدة حزمة DSDV التي تسببت في تغيير في بياناتها
جدول التوجيه. ولم تذكر الورقة الأصلية بوضوح متى سيتم التغيير
في الجدول يجب إرسال تحديث DSDV. يرسل التنفيذ الحالي
إجراء تحديث بغض النظر عن التغيير في جدول التوجيه.

يتم قبول التحديثات بناءً على المقياس الخاص بعقدة معينة. العامل الأول
تحديد قبول التحديث هو الرقم التسلسلي. وعليه أن يقبل التحديث
إذا كان الرقم التسلسلي لرسالة التحديث أعلى بغض النظر عن المقياس. إذا
يتم استلام التحديث بنفس رقم التسلسل، ثم التحديث بأقل مقياس (hopCount)
تعطى الأسبقية.

في السيناريوهات عالية الحركة، هناك احتمال كبير لتقلبات المسار، وبالتالي لدينا
مفهوم وقت التسوية المرجح حيث لن يتم التحديث مع التغيير في المقياس
المعلن عنها للجيران. تنتظر العقدة وقت التسوية للتأكد من أنها لم تفعل ذلك
تلقي التحديث من جارتها القديمة قبل إرسال هذا التحديث.

يغطي التنفيذ الحالي جميع ميزات DSDV المذكورة أعلاه. الحالي
يحتوي التنفيذ أيضًا على قائمة انتظار طلبات للتخزين المؤقت للحزم التي ليس لها طرق إليها
وجهة. تم تعيين الإعداد الافتراضي للتخزين المؤقت لما يصل إلى 5 حزم لكل وجهة.

مراجع حسابات
رابط إلى الورقة: http://portal.acm.org/citation.cfm?doid=190314.190336

DSR ROUTING

بروتوكول توجيه المصدر الديناميكي (DSR) هو بروتوكول توجيه تفاعلي مصمم خصيصًا
للاستخدام في الشبكات اللاسلكية المخصصة متعددة القفزات للعقد المتنقلة.

تم تطوير هذا النموذج بواسطة هيه شبكات المرونة بحث رأس التجميع في جامعة كانساس.

DSR التوجيه نظرة عامة
يطبق هذا النموذج المواصفات الأساسية لبروتوكول توجيه المصدر الديناميكي (DSR).
التنفيذ يعتمد على RFC 4728، مع بعض الملحقات والتعديلات على RFC
مواصفات.

يعمل DSR على أساس السلوك عند الطلب. لذلك، يقوم نموذج DSR الخاص بنا بتخزين كافة الحزم مؤقتًا أثناء a
يتم نشر حزمة طلب المسار (RREQ). نقوم بتنفيذ المخزن المؤقت للحزم في
dsr-rsendbuff.cc. تقوم قائمة انتظار الحزم بتنفيذ عملية جمع البيانات المهملة للحزم القديمة و
الحد الأقصى لحجم قائمة الانتظار. عندما يتم إرسال الحزمة من المخزن المؤقت للإرسال، سيتم وضعها في قائمة الانتظار
المخزن المؤقت للصيانة لإقرار الخطوة التالية.

يقوم مخزن الصيانة المؤقت بعد ذلك بتخزين الحزم المرسلة بالفعل وينتظر
إشعار تسليم الحزمة. يعتمد تشغيل البروتوكول بشدة على الارتباط المعطل
آلية الكشف. نحن ننفذ الاستدلالات الثلاثة الموصى بها بناءً على RFC
يتبع:

أولاً، نستخدم تعليقات طبقة الارتباط عندما يكون ذلك ممكنًا، وهي أيضًا أسرع آلية
هذه الثلاثة لاكتشاف أخطاء الارتباط. يعتبر الارتباط معطلاً في حالة إرسال الإطار
يؤدي إلى فشل الإرسال لجميع المحاولات. هذه الآلية مخصصة للنشاط
الروابط ويعمل بشكل أسرع بكثير مما كان عليه في غيابه. DSR قادر على اكتشاف طبقة الارتباط
فشل الإرسال وإخطار أنه مكسور. سيتم تشغيل إعادة حساب الطرق
عند الاحتياج. إذا كان المستخدم لا يريد استخدام إقرار طبقة الارتباط، فيمكن ضبطه عن طريق
تعيين سمة "LinkAcknowledgment" على "خطأ" في "dsr-routing.cc".

ثانيًا، يجب استخدام الإقرار السلبي كلما أمكن ذلك. يتم تشغيل العقدة
وضع الاستلام "المختلط"، الذي يمكنه من خلاله تلقي حزم غير موجهة لنفسه، و
عندما تضمن العقدة تسليم حزمة البيانات تلك إلى وجهتها، فإنها تلغي عملية الإرسال
توقيت الاعتراف السلبي.

وأخيرًا، نستخدم نظام إقرار طبقة الشبكة للإخطار باستلام الحزمة. طريق
لن يتم الإقرار بحزمة الطلب أو إعادة إرسالها.

يدعم تطبيق Route Cache جمع البيانات المهملة للإدخالات والحالة القديمة
الآلة، كما هو محدد في المعيار. يتم تنفيذه كحاوية خريطة STL. المفتاح هو
عنوان IP الوجهة.

يعمل DSR مع الوصول المباشر إلى رأس IP، ويعمل بين الشبكة والنقل
طبقة. عندما يتم إرسال الحزمة من طبقة النقل، فإنها تمرر نفسها إلى DSR وDSR
تم إلحاق الرأس.

لدينا آليتان للتخزين المؤقت: ذاكرة التخزين المؤقت للمسار وذاكرة التخزين المؤقت للارتباط. ذاكرة التخزين المؤقت للمسار تحفظ الكل
المسار في ذاكرة التخزين المؤقت. يتم فرز المسارات بناءً على عدد القفزات، وكلما كان هناك مسار واحد
غير قادر على استخدامها، ننتقل إلى المسار التالي. ذاكرة التخزين المؤقت للارتباط أفضل قليلاً
التصميم بمعنى أنه يستخدم مسارات فرعية مختلفة ويستخدم ذاكرة التخزين المؤقت للارتباط المنفذ باستخدام
خوارزمية Dijsktra، ويتم تنفيذ هذا الجزء بواسطة Song Luan[البريد الإلكتروني محمي]>.

لم يتم تنفيذ تحسينات البروتوكول الاختياري التالية:

· حالة التدفق

· أعلام القفزة الأولى الخارجية (F)، والقفزة الأخيرة الخارجية (L).

· التعامل مع خيارات DSR غير المعروفة

·

المستوى الثاني⁧⁩ أنواع of خطأ رؤوس:

1. خيار حالة التدفق غير معتمد

2. خيار غير مدعوم (لن يحدث في المحاكاة)

DSR تحديث in NS-3.17
استخدمنا في الأصل "TxErrHeader" في Ptr للإشارة إلى خطأ الإرسال أ
حزمة معينة في طبقة الارتباط، ومع ذلك، لم تكن تعمل بشكل صحيح تمامًا منذ ذلك الحين
تم إسقاط الحزمة، ولم يتم تسجيل هذا الرأس في ملف التتبع. اعتدنا على أ
مسار مختلف في تنفيذ آلية إعلام طبقة الارتباط. نحن ننظر في
تتبع الملف من خلال العثور على حدث تلقي الحزمة. إذا وجدنا واحدًا يتلقى حدثًا للبيانات
الحزمة، فإننا نعتبر ذلك مؤشرًا لتسليم البيانات بنجاح.

مفيد المعلمات
+------------------------- +----------------------- -------------+------------+
| المعلمة | الوصف | الافتراضي |
+============================================================================================== ======================+
| ماكس سيند باف لين | الحد الأقصى لعدد الحزم التي يمكن | 64 |
| | يتم تخزينها في المخزن المؤقت للإرسال | |
+------------------------- +----------------------- -------------+------------+
| MaxSendBuffTime | الحد الأقصى لحزم الوقت التي يمكن وضعها في قائمة الانتظار | ثانية(30) |
| | في المخزن المؤقت للإرسال | |
+------------------------- +----------------------- -------------+------------+
| ماكس مينت لين | الحد الأقصى لعدد الحزم التي يمكن | 50 |
| | يتم تخزينها في المخزن المؤقت للصيانة | |
+------------------------- +----------------------- -------------+------------+
| ماكس مينت تايم | الحد الأقصى لحزم الوقت التي يمكن وضعها في قائمة الانتظار | ثانية(30) |
| | في المخزن المؤقت للصيانة | |
+------------------------- +----------------------- -------------+------------+
| ماكس كاش لين | الحد الأقصى لعدد إدخالات المسار | 64 |
| | التي يمكن تخزينها في ذاكرة التخزين المؤقت للطريق | |
+------------------------- +----------------------- -------------+------------+
| RouteCacheTimeout | الحد الأقصى للوقت الذي يمكن لذاكرة التخزين المؤقت للمسار | ثانية(300) |
| | تكون في قائمة الانتظار في ذاكرة التخزين المؤقت للطريق | |
+------------------------- +----------------------- -------------+------------+
| إعادة المحاولة | الحد الأقصى لعدد عمليات إعادة الإرسال | 16 |
| | لطلب اكتشاف طريق | |
+------------------------- +----------------------- -------------+------------+
| نوع ذاكرة التخزين المؤقت | استخدم ذاكرة التخزين المؤقت للارتباط أو استخدم ذاكرة التخزين المؤقت للمسار | "LinkCache" |
| | | |
+------------------------- +----------------------- -------------+------------+
| إقرار الارتباط | تمكين إقرار طبقة الارتباط | صحيح |
| | آلية | |
+------------------------- +----------------------- -------------+------------+

تطبيق تعديل
·

تشير DsrFsHeader لديها وأضاف 3 مجالات: الرسالة اكتب، مصدر الهوية افضل الرحلات السياحية الهوية هؤلاء
التغييرات فقط For المعالجة البعدية

1. يتم استخدام نوع الرسالة لتحديد حزمة البيانات من حزمة التحكم

2. يتم استخدام معرف المصدر لتحديد المصدر الحقيقي لحزمة البيانات منذ أن قمنا بذلك
لتسليم الحزمة خطوة بخطوة ولا يحمل ipv4header النسخة الحقيقية
عنوان IP المصدر والوجهة حسب الحاجة

3. معرف الوجهة لنفس السبب المذكور أعلاه

· رأس توجيه الرد غير محاذي للكلمات في DSR RFC، قم بتغييره إلى محاذاة للكلمات
التنفيذ

· يعمل DSR كنقطة وصل بين بروتوكول النقل والشبكة، وهو يحتاج إلى بروتوكول خاص به
آلية إعادة التوجيه، نقوم بتغيير إرسال الحزمة إلى التسليم خطوة بخطوة، لذلك
أضفنا حقلين في رأس dsr الثابت لإخطار تسليم الحزمة

حالياًّ طريق مخبأ التنفيذ
استخدم هذا التنفيذ "ذاكرة التخزين المؤقت للمسار"، وهو سهل التنفيذ ويضمن خلوه من الحلقات
مسارات:

· مسار ذاكرة التخزين المؤقت لديه سياسة انتهاء الصلاحية التلقائية

· ذاكرة التخزين المؤقت يحفظ إدخالات الطريق المتعددة لوجهة معينة وفرز الإدخالات
على أساس عدد القفزات

· يمكن ضبط MaxEntriesEachDst لتغيير الحد الأقصى للإدخالات المحفوظة لمرة واحدة
افضل الرحلات السياحية

· عند إضافة مسارات متعددة لوجهة واحدة، تتم مقارنة المسار بناءً على ذلك
عدد القفزات ووقت انتهاء الصلاحية، وهو المسار الذي يحتوي على عدد أقل من القفزات أو المسار الجديد نسبيًا
مفضل

· قد يتضمن التنفيذ المستقبلي "رابط مخبأ" كاحتمال آخر

DSR تعليمات
يجب مراعاة ما يلي عند تشغيل DSR كبروتوكول توجيه:

· NodeTraversalTime هو الوقت الذي يستغرقه اجتياز عقدتين متجاورتين ويجب أن يكون كذلك
تم اختياره ليناسب نطاق الإرسال

· PassiveAckTimeout هو الوقت الذي تنتظر فيه الحزمة الموجودة في المخزن المؤقت للصيانة السلبي
يتم تعيين الإقرار عادةً على أنه مرتين في NodeTraversalTime

· ينبغي تعيين قيمة RouteCacheTimeout أصغر عندما تصبح سرعة العقد أعلى.
القيمة الافتراضية هي 300 ثانية.

المساعد
لجعل العقدة تقوم بتشغيل DSR، فإن أسهل طريقة هي استخدام DsrHelper وDsrMainHelpers
في نص المحاكاة الخاص بك. على سبيل المثال:

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

الأمثلة على البرامج النصية في الداخل سرك/دسر/أمثلة/ إظهار استخدام العقد المستندة إلى DSR
سيناريوهات مختلفة. يمكن العثور على مصدر المساعد في الداخل
src/dsr/helper/dsr-main-helper.{h,cc} src/dsr/helper/dsr-helper.{h,cc}

أمثلة
المثال يمكن العثور عليه في سرك/دسر/أمثلة/:

· يستخدم 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] آر إف سي 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 عمليات محاكاة لإرسال البيانات على شبكة "حقيقية". الثاني
نوع، ويسمى أ نقر 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/ للحصول على تفاصيل حول أوربت
المرحلة التجريبية.

وتظهر محاكاة من هذا النوع في الشكل التالي:
[صورة] مثال على تنفيذ محاكاة Testbed..UNINDENT

يمكنك أن ترى أن هناك مضيفين منفصلين، كل منهم يشغل مجموعة فرعية من "العالمية"
محاكاة. بدلا من NS-3 قناة تربط بين المضيفين، نستخدم أجهزة حقيقية
المقدمة من الاختبار. هذا يسمح NS-3 التطبيقات ومكدسات البروتوكول المرفقة بـ
عقدة محاكاة للتواصل عبر أجهزة حقيقية.

نتوقع أن يكون الاستخدام الأساسي لهذا التكوين هو إنشاء قابل للتكرار
نتائج تجريبية في بيئة شبكة حقيقية تتضمن كافة NS-3
أدوات التتبع والتسجيل والتصور وجمع الإحصائيات.

وفي ما يمكن اعتباره في الأساس تكوينًا عكسيًا، فإننا نسمح بالآلات "الحقيقية".
تشغيل التطبيقات الأصلية ومكدسات البروتوكول للتكامل مع NS-3 محاكاة.
وهذا يسمح بمحاكاة الشبكات الكبيرة المتصلة بجهاز حقيقي، وكذلك
تمكن المحاكاة الافتراضية. وتظهر محاكاة من هذا النوع في الشكل التالي:
[صورة] نظرة عامة على تنفيذ القناة التي تمت محاكاتها..UNINDENT

هنا، سترى أن هناك مضيفًا واحدًا به عدد من الأجهزة الافتراضية قيد التشغيل
عليه. ان NS-3 تظهر المحاكاة قيد التشغيل في الجهاز الظاهري الموضح في وسط
الشكل. تحتوي هذه المحاكاة على عدد من العقد المرتبطة بها NS-3 التطبيقات و
مكدسات البروتوكول التي تتحدث إلى NS-3 القناة من خلال محاكاة الأصلي NS-3 صاف
الأجهزة.

يوجد أيضًا جهازان افتراضيان يظهران في أقصى يسار الشكل وأقصى يمينه.
تعمل هذه الأجهزة الافتراضية على تشغيل تطبيقات (Linux) الأصلية ومكدسات البروتوكولات. جهاز VM هو
متصلة بالمحاكاة بواسطة جهاز Linux Tap net. معالج وضع المستخدم لـ
يتم إنشاء مثيل لجهاز Tap في المحاكاة وإرفاقه بعقدة وكيل
يمثل VM الأصلي في المحاكاة. تسمح هذه المعالجات لأجهزة Tap الموجودة على
الأجهزة الافتراضية الأصلية تتصرف كما لو كانت كذلك NS-3 أجهزة net في محاكاة VM. هذا، في
بدوره، يسمح للبرامج الأصلية ومجموعات البروتوكولات في الأجهزة الافتراضية الأصلية بالاعتقاد بذلك
فهي متصلة بالمحاكاة NS-3 القناة.

نتوقع أن تكون حالة الاستخدام النموذجية لهذه البيئة هي تحليل سلوك
التطبيقات الأصلية ومجموعات البروتوكولات في وجود محاكاة كبيرة NS-3
الشبكات.

قم بتقديم واصف NetDevice
تشير 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 بتوجيه الإطارات من المحاكاة إلى ملف
واصف. قد يرتبط واصف الملف بجهاز Linux TUN/TAP أو بمقبس أو
أو إلى عملية مساحة المستخدم.

الأمر متروك لمستخدم هذا الجهاز لتوفير واصف الملف. نوع الملف
يحدد الواصف المقدم ما يتم تصميمه. على سبيل المثال، إذا كان الملف
يوفر الواصف مقبسًا أوليًا لبطاقة WiFi على الجهاز المضيف، وهو الجهاز
على غرار جهاز واي فاي.

من "الجزء العلوي" المفاهيمي للجهاز، ينظر إلى الأسفل، ويبدو وكأنه العقدة المحاكاة
جهاز يدعم عنوان IEEE MAC 48 بت الذي يمكن توصيله، ويدعم البث، و
يستخدم IPv4 ARP أو IPv6 Neighbor Discovery، على الرغم من إمكانية ضبط هذه السمات على ملف
أساس كل حالة استخدام.

تصميم
يستخدم تطبيق FdNetDevice كائن القارئ الممتد من FDReader
الطبقة في NS-3 src / الأساسية الوحدة النمطية، التي تدير موضوع منفصل عن الرئيسي NS-3
مؤشر ترابط التنفيذ، من أجل قراءة حركة المرور من واصف الملف.

عند استدعاء StartDevice الطريقة، تتم تهيئة كائن القارئ ويبدأ
موضوع القراءة. قبل بدء تشغيل الجهاز، يجب أن يكون واصف الملف مرتبطًا مسبقًا
جهاز FdNetDevice مع SetFileDescriptor استدعاء.

يمكن ترك عملية إنشاء واصف الملف وتكوينه لعدد من المساعدين،
موصوفة بمزيد من التفاصيل أدناه. عندما يتم ذلك، يتم استدعاء SetFileDescriptor is
مسؤولية المساعد ويجب ألا يتم الاحتجاج بها مباشرة من قبل المستخدم.

عند قراءة إطار وارد من واصف الملف، سيقوم القارئ بتمرير الإطار إليه
هيه تلقي رد الاتصال الطريقة التي تتمثل مهمتها في جدولة استقبال الإطار بواسطة
الجهاز باعتباره NS-3 حدث محاكاة. منذ أن تم تمرير الإطار الجديد من مؤشر ترابط القارئ إلى
الرئيسية NS-3 محاكاة الخيط، يتم تجنب مشكلات سلامة الخيط باستخدام
جدولة مع سياق اتصل بدلا من العادية حدد مكالمة.

من أجل تجنب إرباك المجدول عندما يكون معدل البيانات الواردة مرتفعًا جدًا، أ
يتم الاحتفاظ بالعداد بعدد الإطارات المقرر حاليًا استلامها
الجهاز. إذا وصل هذا العداد إلى القيمة المعطاة بواسطة RxQueueSize السمة في
الجهاز، فسيتم إسقاط الإطار الجديد بصمت.

يتم الاستقبال الفعلي للإطار الجديد بواسطة الجهاز في الموعد المقرر FordwarUp
يتم استدعاء الطريقة بواسطة جهاز المحاكاة. تعمل هذه الطريقة كما لو أن إطارًا جديدًا قد وصل من ملف
القناة المرفقة بالجهاز يقوم الجهاز بعد ذلك بفك تغليف الإطار وإزالة أي طبقة
2 رأسًا، ويعيد توجيهه إلى طبقات مكدس الشبكة العليا للعقدة. ال إلى الأمام
ستقوم الطريقة بإزالة رؤوس الإطار، وفقًا لنوع تغليف الإطار المحدد بواسطة
هيه وضع التغليف السمة، واستدعاء رد الاتصال الاستلام لتمرير حزمة IP.

يمكن أن يوجد رأس إضافي، رأس PI، عندما يرتبط واصف الملف بملف
جهاز TAP الذي تم إنشاؤه بدون تعيين علامة IFF_NO_PI. هذا الرأس الإضافي هو
إزالتها إذا وضع التغليف تم ضبطه على قيمة DIXPI.

وفي الاتجاه المعاكس، يتم إرسال الحزم المولدة داخل المحاكاة إلى الخارج
سيتم تمريرها من خلال الجهاز إلى إرسال الطريقة، والتي بدورها سوف تستدعي
ارسل من طريقة. ستضيف الطريقة الأخيرة رؤوس الطبقة الثانية الضرورية وببساطة
اكتب الإطار الذي تم إنشاؤه حديثًا إلى واصف الملف.

مجال القيود
يتم تحذير مستخدمي هذا الجهاز من عدم وجود تحكم في التدفق عبر الملف
حدود الواصف، عند استخدامها في وضع المحاكاة. وهذا يعني، في نظام Linux، إذا كان
تتجاوز سرعة كتابة حزم الشبكة قدرة الجهاز الفعلي الأساسي على ذلك
قم بتخزين الحزم مؤقتًا، وسيتم تطبيق الضغط الخلفي حتى تطبيق الكتابة لتجنب ذلك
فقدان الحزمة المحلية. لا يتم توفير مثل هذا التحكم في التدفق عبر واجهة واصف الملف،
لذلك يجب أن يكون المستخدمون على دراية بهذا القيد.

كما هو موضح من قبل، تحدد سمة RxQueueSize عدد الحزم التي يمكن أن تكون
في انتظار استلامها من قبل الجهاز. قراءة الإطارات من واصف الملف أثناء
سيتم إسقاط عدد الحزم المعلقة عند الحد الأقصى بصمت.

تكون قيمة mtu الخاصة بالجهاز هي قيمة Ethernet II MTU. ومع ذلك، من المفترض أن يكون هناك مساعدين
لتعيين mtu على القيمة الصحيحة لتعكس خصائص واجهة الشبكة
المرتبطة بواصف الملف. إذا لم يتم استخدام مساعد، ثم مسؤولية
يعود تحديد قيمة mtu الصحيحة للجهاز إلى المستخدم. حجم القراءة
يتم تعيين المخزن المؤقت الموجود على قارئ واصف الملف على قيمة mtu في ملف StartDevice الأسلوب.

تدعم فئة FdNetDevice حاليًا ثلاثة أوضاع تغليف، DIX لـ Ethernet II
إطارات، LLC لإطارات 802.2 LLC/SNAP، وDIXPI لإطارات Ethernet II مع إطار إضافي
اضغط على رأس PI. وهذا يعني أنه من المتوقع أن تكون حركة المرور التي تعبر واصف الملف
متوافق مع إيثرنت II. من الممكن توصيل جهاز FdNetDevice بواجهة لاسلكية
طالما أن برنامج التشغيل يوفر إطارات Ethernet II لواجهة برمجة تطبيقات المقبس. لاحظ أن لربط
FdNetDevice إلى بطاقة لاسلكية في الوضع المخصص، فيجب تعيين عنوان MAC الخاص بالجهاز
إلى عنوان MAC الحقيقي للبطاقة، وإلا فإن أي حركة مرور واردة ستكون عنوان MAC مزيفًا
تم التخلص منها من قبل السائق.

كما ذكرنا من قبل، يتم توفير ثلاثة مساعدين مع وحدة fd-net-device. كل
قد يكون للمساعد الفردي (نوع واصف الملف) قيود على النظام الأساسي. على سبيل المثال،
الترابط، ووضع المحاكاة في الوقت الفعلي، والقدرة على إنشاء أجهزة TUN/TAP
المتطلبات الأساسية لاستخدام المساعدين المقدمة. يمكن العثور على دعم لهذه الأوضاع في
إخراج WAF تكوين خطوة، على سبيل المثال:

أساسيات الترابط: مُمكّن
محاكي الوقت الحقيقي: ممكّن
جهاز الشبكة الذي تمت محاكاته: ممكّن
اضغط على الجسر: ممكّن

ومن المهم أن نذكر أنه أثناء اختبار FdNetDevice لقد وجدنا الحد الأعلى
حد إنتاجية TCP عند استخدام وصلات Ethernet بسرعة 1 جيجابت وسرعة 60 ميجا بت في الثانية. هذا الحد هو الأكثر
على الأرجح بسبب قوة المعالجة لأجهزة الكمبيوتر المشاركة في الاختبارات.

الأستعمال
يشبه نمط الاستخدام لهذا النوع من الأجهزة أجهزة الشبكة الأخرى التي تحتوي على مساعدين
التي يتم تثبيتها على مؤشرات العقدة أو حاويات العقدة. عند استخدام القاعدة FdNetDeviceHelper
يكون المستخدم مسؤولاً عن إنشاء وتعيين واصف الملف بنفسه.

fdNetDeviceHelper fd;
أجهزة NetDeviceContainer = fd.Install (العقد)؛

// إنشاء واصف الملف


جهاز->SetFileDescriptor (fd);

الأكثر شيوعًا هو استخدام FdNetDevice للتفاعل مع النظام المضيف. في هذه الحالات
يكاد يكون من المؤكد أن المستخدم سيرغب في التشغيل في وضع المحاكاة في الوقت الفعلي
تمكين حسابات المجموع الاختباري. بيانات البرنامج النموذجية هي كما يلي:

GlobalValue::Bind ("SimulatorImplementationType"، StringValue ("ns3::RealtimeSimulatorImpl"))؛
GlobalValue::Bind ("ChecksumEnabled"، BooleanValue (true))؛

أسهل طريقة لإعداد تجربة تتفاعل مع نظام Linux المضيف هي من خلال المستخدم
هيه الإمو طائر استرالي نقر مساعدين. ربما يكون الجزء الأكثر غرابة في هذه التطبيقات المساعدة
يتعلق بمتطلبات تنفيذ بعض التعليمات البرمجية بأذونات المستخدم الفائق.
بدلاً من إجبار المستخدم على تنفيذ المحاكاة بأكملها كجذر، فإننا نوفر تطبيقًا صغيرًا
برنامج "المنشئ" الذي يعمل كجذر ويقوم بأي عمل مطلوب من المقابس ذات الأذونات العالية.
أسهل طريقة لتعيين الامتيازات الصحيحة لبرامج "المنشئ" هي تمكين
--enable-sudo العلم عند الأداء WAF تكوين.

نحن نفعل الشيء نفسه لكلا الإمو طائر استرالي و نقر الأجهزة. وجهة النظر رفيعة المستوى هي ذلك
هيه CreateFileDescriptor تقوم الطريقة بإنشاء مأخذ توصيل داخلي (Unix) وشوك و
ينفذ برنامج الخلق الصغير. يقوم البرنامج الصغير، الذي يعمل كجذر suid، بإنشاء ملف
مأخذ توصيل خام ويرسل مرة أخرى واصف ملف مأخذ التوصيل الخام عبر مقبس يونكس
مرت إليها كمعلمة. يتم تمرير المقبس الخام كرسالة تحكم (أحيانًا
تسمى البيانات المساعدة) من النوع SCM_RIGHTS.

المساعدون
EmuFdNetDeviceHelper
يقوم EmuFdNetDeviceHelper بإنشاء مأخذ توصيل أولي لجهاز فعلي أساسي، و
يوفر واصف مأخذ التوصيل إلى FdNetDevice. وهذا يسمح NS-3 محاكاة ل
قراءة الإطارات من جهاز الشبكة الموجود على المضيف وكتابتها عليها.

يسمح مساعد المحاكاة بدمج ملف محاكاة بشفافية NS-3 العقدة في أ
شبكة مكونة من عقد حقيقية.

+-----------------------+ +-----------------------+
| المضيف 1 | | المضيف 2 |
+-----------------------+ +-----------------------+
| محاكاة ns-3 | | |
+----------------------+ | لينكس |
| عقدة ns-3 | | مكدس الشبكة |
| +----------------+ | | +----------------+ |
| | ns-3 TCP | | | | برنامج التعاون الفني | |
| +----------------+ | | +----------------+ |
| | ns-3 IP | | | | الملكية الفكرية | |
| +----------------+ | | +----------------+ |
| | فدنيت ديفايس | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + إيثرنت + |
| | المقبس الخام | | | | | |
|--+-------------------| | +----------------+ |
| | إيث0 | | | | إيث0 | |
+-------+------+-------+------+------+-------+

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 (اسم الجهاز)؛
أجهزة NetDeviceContainer = emu.Install (node)؛
بي تي آر الجهاز = الأجهزة. احصل على (0)؛
جهاز->SetAttribute ("العنوان"، Mac48AddressValue (Mac48Address::Allocate ()));

اضغط علىFdNetDeviceHelper
جهاز Tap هو نوع خاص من أجهزة Linux يظهر له أحد طرفي الجهاز
النواة كجهاز net_device افتراضي، ويتم توفير الطرف الآخر كواصف ملف لـ
مساحة المستخدم. يمكن تمرير واصف الملف هذا إلى FdNetDevice. الحزم التي تم إرسالها إلى
سيظهر جهاز TAP بواسطة kernel في FdNetDevice في NS-3.

يجب على المستخدمين ملاحظة أن هذا الاستخدام لأجهزة TAP يختلف عن ذلك الذي توفره
تم العثور على TapBridge NetDevice في src/tap-bridge. النموذج في هذا المساعد هو كما يلي:

+-------------------------------------+
| المضيف |
+-------------------------------------+
| محاكاة ns-3 | |
+----------------------+ |
| عقدة ns-3 | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | فدنيت ديفايس | | |
|--++------------------+ +------+ |
| | اضغط | | إيث0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-------------------------------|-----+
|
|
------------ (إنترنت) -----

في ما سبق، يتطلب التكوين أن يكون المضيف قادرًا على إعادة توجيه حركة المرور
الناتجة عن المحاكاة إلى الإنترنت.

النموذج الموجود في TapBridge (في وحدة أخرى) هو كما يلي:

+ -------- +
| لينكس |
| المضيف | +---------+
| ------ | | شبح |
| تطبيقات | | العقدة |
| ------ | | -------- |
| كومة | | الملكية الفكرية | +---------+
| ------ | | كومة | | العقدة |
| اضغط | |==========| | -------- |
| جهاز | <----- IPC ------> | اضغط على | | الملكية الفكرية |
+--------+ | جسر | | كومة |
| -------- | | -------- |
| نس-3 | | نس-3 |
| صافي | | صافي |
| جهاز | | جهاز |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| قناة ns-3 |
+ --------------------------- +

في ما سبق، يتم اجتياز الحزم بدلاً من ذلك NS-3 أجهزة الشبكة والقنوات.

نمط الاستخدام لهذا المثال هو أن يقوم المستخدم بتعيين عنوان MAC وإما (أو
كلاهما) عناوين وأقنعة IPv4 وIPv6 الموجودة على الجهاز، ورأس PI إذا لزم الأمر.
فمثلا:

مساعد TapFdNetDeviceHelper؛
helper.SetDeviceName (deviceName)؛
helper.SetModePi (modePi);
helper.SetTapIpv4Address (tapIp);
helper.SetTapIpv4Mask (tapMask);

helper.Install (عقدة)؛

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 بـ
FdNetDevice في ns-3. الوظيفة التي يوفرها هذا المساعد مشابهة لتلك
المقدمة من FdTapNetDeviceHelper، باستثناء أن الآليات الأساسية لإنشاء ملف
جهاز TAP مختلف.

+-------------------------------------+
| مضيف PlanetLab |
+-------------------------------------+
| محاكاة ns-3 | |
+----------------------+ |
| عقدة ns-3 | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | فدنيت ديفايس | | |
|--++------------------+ +------+ |
| | اضغط | | إيث0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-------------------------------|-----+
|
|
------------ (إنترنت) -----

لتتمكن من تعيين عناوين IPv4 خاصة لأجهزة TAP وأصحاب الحسابات
يجب أن يطلب vsys_vnet العلامة المراد إضافتها إلى شريحتهم بواسطة مسؤولي PlanetLab.
ترتبط علامة vsys_vnet بقطاع الشبكة الخاصة والعناوين الواردة من هذا فقط
يمكن استخدام الجزء في التجارب.

إن بناء الجملة المستخدم لإنشاء جهاز TAP باستخدام هذا المساعد مشابه لتلك المستخدمة في
المساعدين الموصوفين سابقًا:

مساعد PlanetLabFdNetDeviceHelper؛
helper.SetTapIpAddress (tapIp);
helper.SetTapMask (tapMask);

helper.Install (عقدة)؛

تحتوي عقد PlanetLab على توزيع يعتمد على Fedora، لذا يمكن تثبيت ns-3 باتباع
تعليمات لتثبيت ns-3 Linux.

السمات
تشير FdNetDevice يوفر عددا من الصفات:

· العنوان: عنوان MAC الخاص بالجهاز

· آبدأ: وقت بدء المحاكاة لتدوير خيط الجهاز

· قلة النوم: وقت بدء المحاكاة لإيقاف مؤشر ترابط الجهاز

· وضع التغليف: تنسيق تغليف طبقة الارتباط

·

حجم قائمة الانتظار: تشير العازلة المقاس of هيه اقرأ طابور on هيه ملف واصف
خيط (افتراضي 1000 حزمة)

آبدأ قلة النوم لا تحتاج عادةً إلى التحديد إلا إذا أراد المستخدم تقييد
الوقت الذي يكون فيه هذا الجهاز نشطًا. العنوان يحتاج إلى تعيين إلى نوع من فريدة من نوعها
عنوان MAC إذا كانت المحاكاة ستتفاعل مع الأجهزة الحقيقية الأخرى بطريقة ما
عناوين MAC الحقيقية. الكود النموذجي:

جهاز->SetAttribute ("العنوان"، Mac48AddressValue (Mac48Address::Allocate ()));

الناتج
يتم توفير تتبع Ascii وPCAP بشكل مشابه للآخر NS-3 أنواع NetDevice، من خلال
مساعدين، مثل (على سبيل المثال):

:: EmuFdNetDeviceHelper emu; أجهزة NetDeviceContainer = emu.Install (node)؛
emu.EnablePcap ("emu-ping"، جهاز، صحيح)؛

يتم توفير المجموعة القياسية لمصادر تتبع NetDevice على مستوى Mac.

· MaxTx: مصدر التتبع أثار عندما NS-3 يزود الجهاز بإطار جديد للإرسال

· MaxTxDrop: تتبع المصدر في حالة فشل الكتابة إلى واصف الملف

· MaxPromiscRx: عند استلام أي إطار Mac صالح

· MaxRx: عند استلام إطار Mac صالح لهذا الجهاز

· الشم: غير مختلط حزمة الشم

· com.PromiscSniffer: أداة شم الحزم غير الشرعية (للآثار المشابهة لـ tcpdump)

أمثلة
يتم تقديم عدة أمثلة:

· دمية-network.cc: يقوم هذا المثال البسيط بإنشاء عقدتين وربطهما معًا بـ
توجيه Unix عن طريق تمرير واصفات الملف من زوج المقبس إلى FdNetDevice
كائنات العقد المعنية.

· الوقت الحقيقي-الدمية-network.cc: مثل dummy-network.cc ولكنه يستخدم جهاز محاكاة الوقت الحقيقي
التنفيذ بدلا من الافتراضي.

· fd2fd-onoff.cc: يهدف هذا المثال إلى قياس إنتاجية FdNetDevice في
محاكاة نقية. لهذا الغرض، تم ربط جهازين FdNetDevices بعقد مختلفة ولكن في
نفس المحاكاة، متصلة باستخدام زوج مآخذ. يتم إرسال حركة مرور TCP على
معدل تشبع البيانات

· فد-الاتحاد الاقتصادي والنقدي-onoff.cc: يهدف هذا المثال إلى قياس إنتاجية FdNetDevice
عند استخدام EmuFdNetDeviceHelper لتوصيل الجهاز المحاكي بجهاز حقيقي
الآلة المضيفة. يتم تحقيق ذلك عن طريق تشبع القناة بحركة مرور TCP.

· FD-EMU-ping.cc: يستخدم هذا المثال EmuFdNetDeviceHelper لإرسال حركة مرور ICMP عبر ملف
قناة حقيقية.

· فد-الاتحاد الاقتصادي والنقدي-udp-echo.cc: يستخدم هذا المثال EmuFdNetDeviceHelper لإرسال حركة مرور UDP
قناة حقيقية.

· FD-Planetlab-ping.cc: يوضح هذا المثال كيفية إعداد تجربة لإرسال ICMP
حركة المرور من عقدة PlanetLab إلى الإنترنت.

· FD-الصنبور-ping.cc: يستخدم هذا المثال TapFdNetDeviceHelper لإرسال حركة مرور ICMP عبر ملف
قناة حقيقية.

نقر NetDevice
يمكن استخدام Tap NetDevice للسماح للنظام المضيف أو الأجهزة الافتراضية بالتفاعل معها
محاكاة.

اضغط على بريدج الموديل نظرة عامة
تم تصميم Tap Bridge لدمج مضيفي الإنترنت "الحقيقيين" (أو بشكل أكثر دقة، المضيفين
التي تدعم أجهزة Tun/Tap) في عمليات محاكاة ns-3. الهدف هو جعله يبدو ل
العقدة المضيفة "الحقيقية" حيث أنها تحتوي على جهاز شبكة ns-3 كجهاز محلي. مفهوم أ
يعد "المضيف الحقيقي" أمرًا زلقًا بعض الشيء نظرًا لأن "المضيف الحقيقي" قد يكون افتراضيًا باستخدام
التقنيات المتاحة بسهولة مثل VMware أو VirtualBox أو OpenVZ.

نظرًا لأننا، في الأساس، نقوم بتوصيل مدخلات ومخرجات جهاز الشبكة ns-3 بالشبكة
المدخلات والمخرجات لجهاز Linux Tap net، نطلق على هذا الترتيب اسم Tap Bridge.

هناك ثلاثة أوضاع تشغيل أساسية لهذا الجهاز متاحة للمستخدمين. أساسي
الوظيفة متطابقة بشكل أساسي، لكن الأوضاع مختلفة في التفاصيل المتعلقة
كيفية إنشاء الترتيب وتكوينه؛ وما هي الأجهزة التي يمكن أن تعيش على أي جانب من
الجسر.

نطلق على هذه الأوضاع الثلاثة اسم ConfigureLocal، وUseLocal، وUseBridge. الأول
تشير كلمة "word" في معرف وضع حالة الجمل إلى من يتحمل مسؤولية الإنشاء
وتكوين الصنابير. على سبيل المثال، يشير "التكوين" في وضع ConfigureLocal
أن TapBridge هو المسؤول عن تكوين الصنبور. في الاستخدام المحلي
وأوضاع UseBridge، تشير البادئة "Use" إلى أنه تمت مطالبة TapBridge بـ "Use"
تكوين موجود.

بمعنى آخر، في وضع ConfigureLocal، يتحمل TapBridge مسؤولية الإنشاء
وتكوين أجهزة TAP. في أوضاع UseBridge أو UseLocal، يوفر المستخدم ملفًا
التكوين ويتكيف TapBridge مع هذا التكوين.

اضغط على بريدج تكوين محلي موضة
في وضع ConfigureLocal، يكون تكوين جهاز الصنبور هو ns-3
تتمحور حول التكوين. يتم أخذ معلومات التكوين من جهاز في ns-3
يتم إنشاء المحاكاة وجهاز النقر المطابق لسمات ns-3 تلقائيًا. في
في هذه الحالة، يظهر جهاز الكمبيوتر الذي يعمل بنظام التشغيل Linux كما لو كان متصلاً مباشرةً بجهاز
محاكاة شبكة NS-3.

وهذا موضح أدناه:

+ -------- +
| لينكس |
| المضيف | +---------+
| ------ | | شبح |
| تطبيقات | | العقدة |
| ------ | | -------- |
| كومة | | الملكية الفكرية | +---------+
| ------ | | كومة | | العقدة |
| اضغط | |==========| | -------- |
| جهاز | <----- IPC ------> | اضغط على | | الملكية الفكرية |
+--------+ | جسر | | كومة |
| -------- | | -------- |
| نس-3 | | نس-3 |
| صافي | | صافي |
| جهاز | | جهاز |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| قناة ns-3 |
+ --------------------------- +

في هذه الحالة، يظهر "جهاز الشبكة ns-3" الموجود في "العقدة الشبحية" كما لو كان موجودًا بالفعل
استبدال جهاز TAP في مضيف Linux. تقوم محاكاة ns-3 بإنشاء جهاز TAP قيد التشغيل
نظام التشغيل Linux الأساسي ويقوم بتكوين عناوين IP وMAC لجهاز TAP للمطابقة
القيم المخصصة لجهاز الشبكة ns-3 المحاكى. رابط "IPC" الموضح أعلاه هو
آلية النقر على الشبكة في نظام التشغيل الأساسي. الترتيب بأكمله يعمل كتقليدي
كوبري؛ ولكنه جسر بين الأجهزة التي لها نفس عنوان MAC وIP المشتركين
عناوين.

هنا، لا يُطلب من المستخدم تقديم أي معلومات تكوين خاصة بالملف
مقبض. سيتم إنشاء جهاز النقر وتكوينه بواسطة ns-3 وفقًا لإعداداته الافتراضية
سيتم تعيين اسم جهاز النقر بواسطة نظام التشغيل الأساسي وفقًا لـ
افتراضياتها.

إذا كان لدى المستخدم متطلبات للوصول إلى جهاز النقر الذي تم إنشاؤه، فيمكنه اختياريًا
توفير سمة "اسم الجهاز". في هذه الحالة، سيتم تسمية جهاز النقر الذي تم إنشاؤه بنظام التشغيل
وفقا لذلك.

يعد وضع ConfigureLocal هو وضع التشغيل الافتراضي لـ Tap Bridge.

اضغط على بريدج UseLocal موضة
يشبه وضع UseLocal تمامًا وضع ConfigureLocal. الفرق الكبير
كما يوحي اسم الوضع، فإن TapBridge سوف "يستخدم" جهاز النقر الموجود
تم إنشاؤها وتكوينها مسبقًا من قبل المستخدم. هذا الوضع مفيد بشكل خاص عندما أ
يقوم نظام المحاكاة الافتراضية تلقائيًا بإنشاء أجهزة النقر ويتم استخدام ns-3 لتوفيرها
محاكاة الشبكات لتلك الأجهزة.

+ -------- +
| لينكس |
| المضيف | +---------+
| ------ | | شبح |
| تطبيقات | | العقدة |
| ------ | | -------- |
| كومة | | الملكية الفكرية | +---------+
| ------ | | كومة | | العقدة |
| اضغط | |==========| | -------- |
| جهاز | <----- IPC ------> | اضغط على | | الملكية الفكرية |
| ماك اكس | | جسر | | كومة |
+--------+ | -------- | | -------- |
| نس-3 | | نس-3 |
| صافي | | صافي |
| جهاز | | جهاز |
| ماك واي | | ماك زد |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| قناة ns-3 |
+ --------------------------- +

في هذه الحالة، لن يكون عنوان MAC الذي تم تكوينه مسبقًا لـ "جهاز النقر" (MAC X) هو العنوان
نفس جهاز "ns-3 net devices" (MAC Y) الموضح في الرسم التوضيحي أعلاه. في
من أجل التوصيل إلى أجهزة net ns-3 التي لا تدعم SendFrom() (خاصة الأجهزة اللاسلكية
عقد STA) نفرض شرطًا على جهاز Linux واحد فقط (مع عنوان MAC فريد واحد
-- هنا X) ينشئ حركة مرور تتدفق عبر رابط IPC. وذلك لأن MAC
سيتم "انتحال" عناوين حركة المرور عبر رابط IPC أو تغييرها لإظهارها
Linux وNS-3 لديهما نفس العنوان. وهذا هو، حركة المرور تتحرك من لينكس
سيتم تغيير عنوان MAC الخاص بالمضيف إلى العقدة الشبحية ns-3 من X إلى Y وحركة المرور من
سيتم تغيير عنوان MAC الخاص بالعقدة الشبحية لمضيف Linux من Y إلى X. منذ ذلك الحين
هناك مراسلات فردية بين الأجهزة، وقد يكون هناك مصدر MAC واحد فقط
تتدفق من جانب Linux. وهذا يعني أن نظام Linux يربط بين أكثر من جهاز شبكة واحد
المضافة غير متوافقة مع وضع UseLocal.

في وضع UseLocal، من المتوقع أن يقوم المستخدم بإنشاء جهاز النقر وتكوينه بالكامل
خارج نطاق محاكاة ns-3 باستخدام شيء مثل:

$ سودو tunctl -t Tap0
$ سودو ifconfig Tap0 الأب الأثير 08:00:2e:00:00:01
$ سودو ifconfig Tap0 10.1.1.1 قناع الشبكة 255.255.255.0 لأعلى

لإخبار TapBridge بما يجري، سيقوم المستخدم بتعيين إما مباشرة في الملف
TapBridge أو عبر TapBridgeHelper، السمة "DeviceName". في حالة
التكوين أعلاه، سيتم تعيين سمة "اسم الجهاز" على "tap0" و"الوضع"
سيتم تعيين السمة على "UseLocal".

إحدى حالات الاستخدام المحددة لهذا الوضع موجودة في بيئة OpenVZ. هناك فمن الممكن
لإنشاء جهاز Tap على "Hardware Node" ونقله إلى Virtual Private Server.
إذا كان TapBridge قادرًا على استخدام جهاز صنبور موجود، فمن الممكن تجنب ذلك
الحمل العلوي لجسر نظام التشغيل في تلك البيئة.

اضغط على بريدج استخدم بريدج موضة
إن أبسط وضع لأولئك الذين هم على دراية بشبكات Linux هو وضع UseBridge. مرة أخرى،
تشير البادئة "الاستخدام" إلى أن TapBridge سيستخدم تكوينًا موجودًا.
في هذه الحالة، سيقوم TapBridge بتوسيع جسر Linux بشكل منطقي إلى ns-3.

وهذا موضح أدناه:

+--------+
| لينكس | +---------+
| ------- | | شبح |
| تطبيقات | | العقدة |
| ------- | | -------- |
| كومة | | الملكية الفكرية | +---------+
| ------- | +--------+ | كومة | | العقدة |
| افتراضية | | اضغط | |==========| | -------- |
| الجهاز | | الجهاز | <---- التصنيف الدولي للبراءات -----> | اضغط على | | الملكية الفكرية |
+---------+ +-------+ | جسر | | كومة |
|| || | -------- | | -------- |
+--------------------+ | نس-3 | | نس-3 |
| جسر نظام التشغيل (brctl) | | صافي | | صافي |
+--------------------+ | جهاز | | جهاز |
+ ---------- + + ---------- +
|| ||
+ --------------------------- +
| قناة ns-3 |
+ --------------------------- +

في هذه الحالة، يكون الكمبيوتر الذي يقوم بتشغيل تطبيقات وبروتوكولات Linux وما إلى ذلك متصلاً بـ
تمت محاكاة شبكة ns-3 بطريقة تجعلها تظهر لمضيف Linux أن TAP
الجهاز هو جهاز شبكة حقيقي مشارك في جسر Linux.

في محاكاة ns-3، يتم إنشاء TapBridge لمطابقة كل جهاز TAP. اسم ال
يتم تعيين جهاز TAP إلى Tap Bridge باستخدام السمة "DeviceName". تاببريدج
ثم يقوم بتوسيع جسر نظام التشغيل بشكل منطقي ليشمل جهاز الشبكة ns-3.

نظرًا لأن هذا الوضع يقوم بتوسيع جسر نظام التشغيل بشكل منطقي، فقد يكون هناك العديد من أجهزة شبكة Linux على الشبكة
الجانب غير ns-3 من الجسر. لذلك، مثل جهاز الشبكة على أي جسر، شبكة ns-3
يجب أن يتعامل الجهاز مع احتمال وجود العديد من عناوين المصدر. وبالتالي، يجب على أجهزة NS-3
دعم SendFrom() (يجب أن يُرجع NetDevice::SupportsSendFrom() صحيحًا) حتى يكون
تم تكوينه للاستخدام في وضع UseBridge.

من المتوقع أن يقوم المستخدم بفعل ما يلي لتكوين الجسر
ثم اضغط بالكامل خارج ns-3:

$ سودو brctl addbr mybridge
$ sudo tuntctl -t mytap
$ سودو ifconfig mytap hw الأثير 00:00:00:00:00:01
$ Sudo ifconfig mytap 0.0.0.0 up
$ sudo brctl addif mybridge mytap
$ سودو brctl addif mybridge ...
$ سودو ifconfig mybridge 10.1.1.1 قناع الشبكة 255.255.255.0 لأعلى

لإخبار TapBridge بما يجري، سيقوم المستخدم بتعيين إما مباشرة في الملف
TapBridge أو عبر TapBridgeHelper، السمة "DeviceName". في حالة
التكوين أعلاه، سيتم تعيين سمة "اسم الجهاز" على "mytap" و"الوضع"
سيتم تعيين السمة على "UseBridge".

يعد هذا الوضع مفيدًا بشكل خاص في حالة المحاكاة الافتراضية حيث يتم تكوين
قد يتم إملاء المضيفين الافتراضيين بواسطة نظام آخر ولا يمكن تغييرهم ليناسب ns-3.
على سبيل المثال، قد يقوم نظام VM معين بإنشاء أجهزة افتراضية "vethx" أو "vmnetx" يمكنها
تظهر محليًا للمضيفين الظاهريين. ومن أجل الاتصال بمثل هذه الأنظمة، يجب على المرء أن يفعل ذلك
قم بإنشاء أجهزة TAP يدويًا على النظام المضيف وقم بتوصيل أجهزة TAP هذه إلى
الأجهزة الافتراضية (VM) الموجودة. مهمة Tap Bridge في هذه الحالة هي تمديد
جسر للانضمام إلى جهاز شبكة NS-3.

اضغط على بريدج تكوين محلي تشغيل
في وضع ConfigureLocal، يظهر TapBridge وجهاز الشبكة ns-3 المرتبط به
إلى الكمبيوتر المضيف Linux كجهاز شبكة تمامًا مثل أي "eth0" أو "ath0" عشوائي
ربما يظهر. يتم إنشاء جهاز TAP وتكوينه بواسطة ns-3
المحاكاة ولا يلزم تكوين يدوي من قبل المستخدم. عناوين IP، MAC
يتم استخراج العناوين والبوابات وما إلى ذلك لأجهزة TAP التي تم إنشاؤها من المحاكاة
نفسه عن طريق الاستعلام عن تكوين جهاز ns-3 وسمات TapBridge.

نظرًا لأن عناوين MAC متطابقة على جانب Linux وجانب ns-3، فيمكننا استخدامها
Send() على جهاز ns-3 والمتوفر على جميع أجهزة net ns-3. منذ لجنة الهدنة العسكرية
العناوين متطابقة ولا توجد حاجة لربط رد الاتصال المختلط على
تلقي الجانب. لذلك لا توجد قيود على أنواع أجهزة الشبكة الموجودة
يمكن استخدامها في وضع ConfigureLocal.

يظهر TapBridge لمحاكاة ns-3 كجهاز شبكة بدون قناة. هذا الجهاز
يجب ألا يكون له عنوان IP مرتبط به، ولكن يجب أن يكون لجهاز الشبكة المتصل (ns-3).
لديك عنوان IP. انتبه إلى أن هذا هو عكس جهاز BridgeNetDevice ns-3 (أو ملف
الجسر التقليدي بشكل عام) والذي يتطلب ألا تحتوي منافذ الجسر الخاصة به على عناوين IP،
ولكنه يسمح لجهاز الجسر نفسه بالحصول على عنوان IP.

سيظهر الكمبيوتر المضيف في المحاكاة كعقدة "شبحية" تحتوي على واحدة
اضغط على TapBridge لكل جهاز NetDevice يتم توصيله. من منظور المحاكاة،
سيكون الاختلاف الوحيد بين العقدة الشبحية وأي عقدة أخرى هو وجود
أجهزة TapBridge. ومع ذلك، لاحظ أن وجود TapBridge يؤثر على
اتصال جهاز الشبكة بمكدس IP الخاص بالعقدة الشبحية.

لا يتم تغيير تكوين معلومات العنوان وأجهزة ns-3 بأي شكل من الأشكال إذا أ
TapBridge موجود. سوف يلتقط TapBridge معلومات العنونة من ns-3
net الذي يتصل به (جهاز الشبكة "الموصول" الخاص به) واستخدام تلك المعلومات من أجل
إنشاء وتكوين جهاز TAP على المضيف الحقيقي.

والنتيجة النهائية لذلك هي الحالة التي يمكن فيها، على سبيل المثال، استخدام اختبار ping القياسي
أداة مساعدة على مضيف حقيقي لإجراء اختبار الاتصال لعقدة ns-3 المحاكية. إذا تمت إضافة المسارات الصحيحة إلى
مضيف الإنترنت (من المتوقع أن يتم ذلك تلقائيًا في إصدارات NS-3 المستقبلية)،
ستمكن أنظمة التوجيه في ns-3 من التوجيه الصحيح للحزم عبر محاكاة ns-3
الشبكات. للحصول على مثال على ذلك، راجع البرنامج النموذجي، اضغط على wifi-dumbbell.cc في ملف
توزيع NS-3.

يعيش Tap Bridge في نوع من العالم الرمادي في مكان ما بين مضيف Linux وNS-3
جهاز الجسر. من منظور Linux، يظهر هذا الرمز كمعالج لوضع المستخدم
جهاز TAP صافي. في وضع ConfigureLocal، يتم إنشاء جهاز Tap هذا تلقائيًا بواسطة
محاكاة NS-3. عندما يكتب مضيف Linux إلى أحد هذه البرامج التي يتم إنشاؤها تلقائيًا
/dev/tap، تتم إعادة توجيه الكتابة إلى TapBridge الذي يعيش في عالم ns-3؛
ومن هذا المنظور، تصبح حزمة الكتابة على Linux حزمة مقروءة في Tap
كوبري. بمعنى آخر، تقوم عملية Linux بكتابة حزمة إلى جهاز النقر وهذه الحزمة
تتم إعادة توجيهه بواسطة آلية النقر على الشبكة إلى عملية ns-3 حيث يتم استلامه بواسطة
TapBridge نتيجة لعملية القراءة هناك. ثم يقوم TapBridge بكتابة الحزمة إلى
جهاز الشبكة ns-3 الذي تم توصيله به؛ وبالتالي يبدو كما لو كان مضيف Linux
إرسال حزمة مباشرة من خلال جهاز شبكة ns-3 إلى شبكة ns-3.

وفي الاتجاه الآخر، حزمة يستقبلها جهاز ns-3 net المتصل بجهاز Tap
يتم إرسال Bridge عبر رد اتصال استقبال إلى TapBridge. ثم يأخذ TapBridge ذلك
الحزمة وكتابتها مرة أخرى إلى المضيف باستخدام آلية النقر على الشبكة. هذه الكتابة إلى
سيظهر الجهاز لمضيف Linux كما لو أن الحزمة قد وصلت إلى جهاز شبكي؛ و
لذلك كما لو أن الحزمة التي استقبلها جهاز الشبكة ns-3 أثناء المحاكاة قد ظهرت
على جهاز شبكة Linux حقيقي.

والنتيجة هي أن Tap Bridge يبدو وكأنه جسر لجهاز النقر على مضيف Linux في
"العالم الحقيقي" لجهاز ns-3 net في المحاكاة. لأن جهاز TAP و
جهاز net ns-3 الموصول له نفس عنوان MAC ورابط IPC الخاص بالشبكة ليس كذلك
خارجيًا، هذا النوع المحدد من الجسور يجعل الأمر يبدو وكأنه جهاز شبكة ns-3
تم تثبيته فعليًا في مضيف Linux.

من أجل تنفيذ ذلك على جانب ns-3، نحتاج إلى "عقدة شبحية" في المحاكاة
أمسك جهاز الشبكة ns-3 الموصول وTapBridge. لا ينبغي أن تفعل هذه العقدة في الواقع
أي شيء آخر في المحاكاة حيث أن وظيفتها هي ببساطة إظهار جهاز الشبكة
لينكس. وهذه ليست مجرد سياسة تعسفية، بل للأسباب التالية:

· البتات المرسلة إلى TapBridge من الطبقات العليا في العقدة الشبحية (باستخدام TapBridge
طريقة الإرسال) يتم تجاهلها بالكامل. إن TapBridge ليس في حد ذاته متصلاً بأي جهاز
الشبكة، لا في لينكس ولا في NS-3. لا يمكنك مطلقًا إرسال أو استقبال البيانات عبر ملف
اضغط على Bridge من العقدة الشبحية.

· تم فصل رد اتصال الاستقبال لجهاز الشبكة ns-3 المجسور من عقدة ns-3 و
تم إعادة الاتصال بـ Tap Bridge. سيتم بعد ذلك إرسال جميع البيانات التي يتلقاها الجهاز المتصل
إلى مضيف Linux ولن تستقبله العقدة. من وجهة نظر ال
العقدة الشبحية، يمكنك الإرسال عبر هذا الجهاز ولكن لا يمكنك الاستقبال على الإطلاق.

وبطبيعة الحال، إذا فهمت جميع القضايا، يمكنك السيطرة على مصيرك
وافعل ما تريد - نحن لا نمنعك بشكل فعال من استخدام العقدة الشبحية
أي شيء تقرره. ستكون قادرًا على تنفيذ عمليات ns-3 النموذجية على الشبح
عقدة إذا كنت ترغب في ذلك. على سبيل المثال، يجب أن تكون حزمة الإنترنت موجودة وتعمل قيد التشغيل
تلك العقدة من أجل المشاركة في تعيين عنوان IP والتوجيه العالمي. لكن،
كما هو مذكور أعلاه، الواجهات التي تتصل بأي من أجهزة TapBridge أو أجهزة الشبكة المتصلة المرتبطة بها
لن تعمل تماما. إذا فهمت بالضبط ما تفعلونه، يمكنك إعداده
الواجهات والأجهزة الأخرى الموجودة على العقدة الشبحية واستخدامها؛ أو الاستفادة من
جانب الإرسال التشغيلي للأجهزة المتصلة لإنشاء مولدات حركة المرور. نحن عموما
ننصحك بمعاملة هذه العقدة كشبح لمضيف Linux وتركها لنفسها،
بالرغم من ذلك.

اضغط على بريدج UseLocal موضة تشغيل
كما هو موضح أعلاه، يعمل TapBridge كجسر من العالم "الحقيقي" إلى العالم
محاكاة عالم NS-3. في حالة وضع ConfigureLocal، أصبحت الحياة سهلة منذ عنوان IP
يتطابق عنوان جهاز Tap مع عنوان IP الخاص بجهاز ns-3 وعنوان MAC الخاص به
يطابق جهاز Tap عنوان MAC الخاص بجهاز ns-3؛ وهناك واحد لواحد
العلاقة بين الأجهزة.

تصبح الأمور معقدة بعض الشيء عندما يتم تكوين جهاز Tap خارجيًا باستخدام ملف
عنوان MAC مختلف عن جهاز الشبكة ns-3. الطريقة التقليدية للتعامل مع هذا
نوع الاختلاف هو استخدام الوضع المختلط في الجهاز المتصل باستقبال الحزم
المخصصة لعنوان MAC المختلف وإعادة توجيهها إلى Linux. من أجل التحرك
الحزم بالطريقة الأخرى، الحل التقليدي هو SendFrom() الذي يسمح للمتصل بذلك
"محاكاة ساخرة" أو قم بتغيير عنوان MAC المصدر ليطابق عنوان Linux MAC المختلف.

لدينا متطلبات محددة لنتمكن من ربط أجهزة Linux الافتراضية بها
عقد STA اللاسلكية. لسوء الحظ، لا توفر مواصفات 802.11 طريقة جيدة للقيام بذلك
قم بتنفيذ SendFrom()، لذلك يتعين علينا حل هذه المشكلة.

ولتحقيق هذه الغاية، قمنا بتوفير وضع UseLocal الخاص بـ Tap Bridge. هذا الوضع يسمح لك
تعامل مع المشكلة كما لو كنت تقوم بإنشاء جسر باستخدام جهاز شبكة واحد. واحد
يتم تذكر العنوان المسموح به على جانب Linux في TapBridge، وتأتي جميع الحزم
من جانب Linux يتم تكرارها من جانب ns-3 باستخدام مصدر MAC لجهاز ns-3
عنوان. يتم تكرار جميع الحزم الواردة من جانب ns-3 خارج جانب Linux باستخدام
عنوان MAC الذي تم تذكره. يتيح لنا هذا استخدام Send() على جانب الجهاز ns-3 وهو
متوفر على جميع أجهزة الشبكة ns-3.

وضع UseLocal مطابق لوضع ConfigureLocal باستثناء الإنشاء و
تكوين جهاز النقر وانتحال عنوان MAC.

اضغط على بريدج استخدم بريدج تشغيل
كما هو موضح في قسم الوضع ConfigureLocal، عندما يكتب مضيف Linux إلى أحد ملفات
/dev/tap، تتم إعادة توجيه الكتابة إلى TapBridge الذي يعيش في عالم ns-3.
في حالة وضع UseBridge، يجب إرسال هذه الحزم على ns-3
الشبكة كما لو تم إرسالها على جهاز مشارك في جسر Linux. هذا يعنى
استدعاء طريقة SendFrom() على الجهاز المتصل وتوفير عنوان MAC المصدر
وجدت في الحزمة.

وفي الاتجاه الآخر، يتم ربط الحزمة المستلمة بواسطة جهاز شبكة ns-3 عبر رد الاتصال
تاببريدج. يجب أن يتم ذلك في وضع غير شرعي لأن الهدف هو سد ns-3
net على جسر نظام التشغيل (brctl) الذي يعد جهاز TAP جزءًا منه.

لهذه الأسباب، فقط أجهزة ns-3 net التي تدعم SendFrom() ولها إمكانية ربط
يُسمح بتلقي رد الاتصال المختلط بالمشاركة في وضع UseBridge TapBridge
تكوينات.

نقر جسر قناة الموديل
لا يوجد نموذج قناة مرتبط بـ Tap Bridge. والحقيقة هي أن النية موجودة
يبدو أن مضيف الإنترنت الحقيقي متصل بقناة الشبكة المتصلة
الجهاز.

نقر جسر البحث عن المفقودين الموديل
على عكس معظم أجهزة ns-3، لا يوفر TapBridge أي مصادر تتبع قياسية. هذا
وذلك لأن الجسر عبارة عن وسيط يبعد عنه استدعاء دالة واحدة
الجهاز الموصول. نتوقع أن تكون خطافات التتبع في الجهاز الذي تم توصيله موجودة
كافية لمعظم المستخدمين،

باستخدام هيه اضغط على بريدج
نتوقع أن يتفاعل معظم المستخدمين مع جهاز TapBridge من خلال
اضغط على BridgeHelper. يجب أن يكون مستخدمو الفئات المساعدة الأخرى، مثل CSMA أو Wifi
مريح مع التعابير المستخدمة هناك.

ENERGY الإطار

يعد استهلاك الطاقة مشكلة رئيسية للأجهزة اللاسلكية والباحثين في مجال الشبكات اللاسلكية
غالبًا ما تحتاج إلى التحقق من استهلاك الطاقة في العقدة أو في الشبكة الشاملة أثناء ذلك
تشغيل محاكاة الشبكة في ns-3 وهذا يتطلب ns-3 لدعم استهلاك الطاقة
النمذجة. علاوة على ذلك، مع ظهور مفاهيم مثل خلايا الوقود وكسح الطاقة
قابلة للتطبيق للأجهزة اللاسلكية منخفضة الطاقة، وتتضمن تأثير هذه الناشئة
تتطلب التقنيات في عمليات المحاكاة دعمًا لنمذجة مصادر الطاقة المتنوعة في
نس-3. يوفر إطار الطاقة ns-3 الأساس لاستهلاك الطاقة ومصدر الطاقة
ونمذجة حصاد الطاقة.

الموديل الوصف
الكود المصدري لإطار الطاقة موجود حاليًا على: src/الطاقة.

تصميم
يتكون إطار الطاقة ns-3 من 3 أجزاء: مصدر الطاقة، ونموذج طاقة الجهاز، و
حصادة الطاقة. يتم تنفيذ الإطار في src/الطاقة/نماذج المجلد.

الطاقة مصدر
يمثل مصدر الطاقة مصدر الطاقة في كل عقدة. يمكن أن تحتوي العقدة على واحد أو أكثر
مصادر الطاقة، ويمكن توصيل كل مصدر للطاقة بنماذج طاقة متعددة الأجهزة.
إن توصيل مصدر طاقة بنموذج طاقة الجهاز يعني ضمناً أن الجهاز المقابل
يستمد الطاقة من المصدر. الوظيفة الأساسية لمصدر الطاقة هي توفيرها
الطاقة للأجهزة الموجودة على العقدة. عندما يتم استنزاف الطاقة بالكامل من مصدر الطاقة،
يقوم بإعلام الأجهزة الموجودة على العقدة بحيث يمكن لكل جهاز التفاعل مع هذا الحدث. إضافي،
يمكن لكل عقدة الوصول إلى كائنات مصدر الطاقة للحصول على معلومات مثل الطاقة المتبقية أو الطاقة المتبقية
جزء الطاقة (مستوى البطارية). يتيح ذلك تنفيذ البروتوكولات المدركة للطاقة
في NS-3.

من أجل تصميم مجموعة واسعة من مصادر الطاقة مثل البطاريات، يجب أن يكون مصدر الطاقة
تكون قادرة على التقاط خصائص هذه الإمدادات. هناك 2 مهم
الخصائص أو التأثيرات المتعلقة بالبطاريات العملية:

معدل القدرات تأثير
انخفاض عمر البطارية عندما يكون السحب الحالي أعلى من القيمة المقدرة
من البطارية.

التعافى تأثير
زيادة عمر البطارية عندما تتناوب البطارية بين التفريغ و
حالات الخمول.

من أجل دمج تأثير قدرة المعدل، يستخدم مصدر الطاقة السحب الحالي من
جميع الأجهزة الموجودة على نفس العقدة لحساب استهلاك الطاقة. علاوة على ذلك، متعددة
يمكن توصيل حصادات الطاقة بمصدر الطاقة من أجل تجديد طاقتها.
يقوم مصدر الطاقة بشكل دوري باستقصاء جميع الأجهزة وجامعي الطاقة على نفس الشيء
عقدة لحساب إجمالي استنزاف التيار وبالتالي استهلاك الطاقة. عندما يكون الجهاز
إذا تغيرت الحالة، فسيقوم نموذج طاقة الجهاز المقابل له بإخطار مصدر الطاقة بذلك
سيتم حساب التغيير وإجمالي السحب الحالي الجديد. وبالمثل، كل حصادة الطاقة
يؤدي التحديث إلى تحديث مصدر الطاقة المتصل.

تحتفظ الفئة الأساسية لمصدر الطاقة بقائمة من الأجهزة (كائنات نموذج طاقة الجهاز) و
حصادات الطاقة (كائنات حصاد الطاقة) التي تستخدم مصدر الطاقة المحدد
كمصدر للطاقة. عندما يتم استنزاف الطاقة بالكامل، سيقوم مصدر الطاقة بإخطار الجميع
الأجهزة في هذه القائمة. يمكن لكل جهاز بعد ذلك التعامل مع هذا الحدث بشكل مستقل، بناءً على
السلوك المرغوب الذي ينبغي اتباعه في حالة انقطاع التيار الكهربائي.

الجهاز الطاقة الموديل
نموذج طاقة الجهاز هو نموذج استهلاك الطاقة لجهاز مثبت على العقدة.
تم تصميمه ليكون نموذجًا قائمًا على الحالة حيث يُفترض أن يحتوي كل جهاز على عدد من الأجهزة
الحالات، وترتبط كل حالة بقيمة استهلاك الطاقة. كلما كانت حالة
يتغير الجهاز، وسيقوم نموذج طاقة الجهاز المقابل بإخطار مصدر الطاقة بذلك
السحب الحالي الجديد للجهاز. سيقوم مصدر الطاقة بعد ذلك بحساب الإجمالي الجديد
السحب الحالي وتحديث الطاقة المتبقية.

يمكن أيضًا استخدام نموذج طاقة الجهاز للأجهزة التي لا تحتوي على عدد محدود من الأجهزة
تنص على. على سبيل المثال، في السيارة الكهربائية، يتم تحديد السحب الحالي للمحرك
من خلال سرعته. وبما أن سرعة السيارة يمكن أن تأخذ قيمًا مستمرة ضمن نطاق معين،
من غير الممكن تحديد مجموعة من حالات التشغيل المنفصلة. ومع ذلك، عن طريق التحويل
قيمة السرعة إلى التيار مباشرة، لا يزال بإمكان نفس مجموعة واجهات برمجة تطبيقات نموذج طاقة الجهاز
يستخدم.

الطاقة حاصدة
يمثل محصد الطاقة العناصر التي تحصد الطاقة من البيئة و
إعادة شحن مصدر الطاقة الذي يتصل به. يشمل حصاد الطاقة
التنفيذ الكامل لجهاز حصاد الطاقة الفعلي (على سبيل المثال، لوحة شمسية) و
البيئة (مثل الإشعاع الشمسي). وهذا يعني أنه في تنفيذ الطاقة
حصادة، مساهمة الطاقة في البيئة والطاقة الإضافية
متطلبات جهاز حصاد الطاقة مثل كفاءة التحويل و
يجب تصميم استهلاك الطاقة الداخلي للجهاز بشكل مشترك.

واي فاي راديو الطاقة الموديل
نموذج طاقة راديو WiFi هو نموذج استهلاك الطاقة لجهاز شبكة Wifi. هو - هي
يوفر حالة لكل حالة من الحالات المتاحة لطبقة PHY: Idle، CcaBusy، Tx، Rx،
تبديل القناة، النوم. ترتبط كل حالة من هذه الحالات بقيمة (بالأمبير) تبلغ
السحب الحالي (انظر أدناه لمعرفة أسماء السمات المقابلة). نموذج طاقة راديو واي فاي
يتم تسجيل مستمع PHY في Wifi PHY ليتم إعلامه بكل حالة Wifi PHY
انتقال. في كل تحول، يتم حساب الطاقة المستهلكة في الحالة السابقة و
ويتم إخطار مصدر الطاقة من أجل تحديث الطاقة المتبقية لديه.

يوفر نموذج Wifi Tx Current Model إمكانية حساب السحب الحالي في
حالة الإرسال كدالة لقدرة الإرسال الاسمية (بالديسيبل مللي واط)، كما لوحظ في العديد
القياسات التجريبية. ولهذا الغرض، فإن مستمع Wifi Radio Energy Model PHY هو
يتم إخطارك بقدرة الإرسال الاسمية المستخدمة لنقل الإطار الحالي ويمرر مثل هذا
القيمة إلى نموذج Wifi Tx الحالي الذي يعتني بتحديث السحب الحالي في Tx
ولاية. ومن ثم، يتم حساب استهلاك الطاقة بشكل صحيح حتى لو كانت محطة Wifi عن بعد
يقوم المدير بالتحكم في الطاقة لكل إطار. حاليًا، يوجد نموذج خطي لشبكة Wifi Tx
تم تنفيذه والذي يحسب تيار tx كدالة خطية (وفقًا للمعلمات
التي يمكن تحديدها من قبل المستخدم) من قدرة الإرسال الاسمية بوحدة dBm.

يوفر نموذج طاقة راديو Wifi إمكانية تحديد رد اتصال يتم استدعاؤه
عندما ينضب مصدر الطاقة. إذا لم يتم تحديد رد الاتصال هذا عند اتصال Wifi
يتم استخدام مساعد نموذج الطاقة الراديوية لتثبيت النموذج على الجهاز، وهو عبارة عن رد اتصال
تم إنشاؤه ضمنيًا بحيث يتم وضع Wifi PHY في وضع السكون (وبالتالي لا يوجد إطار
تنتقل ولا تستقبل بعد ذلك) عند استنفاد مصدر الطاقة. كذلك الأمر كذلك
من الممكن تحديد رد الاتصال الذي يتم استدعاؤه عند إعادة شحن مصدر الطاقة (والذي
قد يحدث في حالة توصيل محصد الطاقة بمصدر الطاقة). إذا كان هذا أ
لم يتم تحديد رد الاتصال عند استخدام Wifi Radio Energy Model Helper لتثبيت
على الجهاز، يتم إجراء رد اتصال ضمنيًا بحيث يتم استئناف Wifi PHY من
وضع السكون عند إعادة شحن مصدر الطاقة.

Future للعمل
بالنسبة لنماذج طاقة الأجهزة، نخطط لتضمين دعم لنماذج طبقة PHY الأخرى
المتوفرة في ns-3 مثل WiMAX، ولنمذجة استهلاك الطاقة لغيرها
أجهزة الاتصال، مثل المستشعر العام ووحدة المعالجة المركزية. بالنسبة لمصادر الطاقة، نحن كذلك
التخطيط لتضمين أنواع جديدة من مصادر الطاقة مثل المكثفات الفائقة والنيكل ميتال
بطارية هيدريد (Ni-MH). بالنسبة لحصادات الطاقة، نحن نخطط لتنفيذ الطاقة
الحصادة التي تعيد شحن مصادر الطاقة وفقًا لمستويات الطاقة المحددة في أ
مجموعة بيانات قابلة للتخصيص للمستخدم من القياسات الحقيقية.

مراجع حسابات
[1] نموذج الطاقة ns-2:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] إتش وو، س. نابار، ر. بوفيندران. إطار الطاقة لمحاكاة الشبكة 3
(نس-3).

[3] م. هاندي ود. تيمرمان. محاكاة الشبكات اللاسلكية المتنقلة بدقة
نمذجة تأثيرات البطارية غير الخطية. في بروك. المحاكاة التطبيقية والنمذجة
(ASM)، 2003.

[4] د.ن. رحماتوف و س.ب. فرودهولا. نموذج بطارية تحليلي عالي المستوى للاستخدام في
إدارة الطاقة للأنظمة الإلكترونية المحمولة. في بروك. IEEE/ACM الدولية
مؤتمر التصميم بمساعدة الكمبيوتر (ICCAD'01)، الصفحات 488-493، نوفمبر 2001.

[5] د.ن. رحماتوف، س.ب. فرودهولا، و د.أ. والاش. التنبؤ بعمر البطارية لـ
الحوسبة المدركة للطاقة. في بروك. للندوة الدولية لعام 2002 حول الطاقة المنخفضة
الإلكترونيات والتصميم (ISLPED'02)، الصفحات 154-159، 2002.

[6] سي. تاباريلو، آية الله، و. هاينزلمان. توسيع إطار الطاقة ل
محاكي الشبكة 3 (ns-3). ورشة عمل حول NS-3 (WNS3)، جلسة الملصقات، أتلانتا، جورجيا،
الولايات المتحدة الأمريكية. مايو 2014.

الأستعمال
الطريقة الرئيسية التي يتفاعل بها مستخدمو ns-3 عادةً مع Energy Framework هي من خلال
واجهة برمجة التطبيقات المساعدة ومن خلال السمات المرئية للعامة لإطار العمل. المساعد
يتم تعريف واجهة برمجة التطبيقات (API) في src/الطاقة/المساعد/*.h.

من أجل استخدام إطار الطاقة، يجب على المستخدم تثبيت مصدر طاقة للعقدة
من المثير للاهتمام، نموذج طاقة الجهاز المقابل لأجهزة الشبكة، وإذا
ضروري، واحد أو أكثر من حصادة الطاقة. يتم تجميع مصدر الطاقة (الأشياء) على
كل عقدة بواسطة مساعد مصدر الطاقة. من أجل السماح بمصادر طاقة متعددة لكل عقدة،
نقوم بتجميع حاوية مصدر الطاقة بدلاً من تجميع كائن مصدر بشكل مباشر.

يحتفظ كائن مصدر الطاقة بقائمة من كائنات نموذج طاقة الجهاز وكائنات حصاد الطاقة
باستخدام المصدر كمصدر للطاقة. يتم تثبيت كائنات نموذج طاقة الجهاز على
مصدر الطاقة بواسطة مساعد نموذج طاقة الجهاز، بينما كائن حصادة الطاقة موجود
تم تثبيته بواسطة Energy Harvester Helper. يمكن للمستخدم الوصول إلى كائنات نموذج طاقة الجهاز
من خلال كائن مصدر الطاقة للحصول على معلومات استهلاك الطاقة للفرد
الأجهزة. علاوة على ذلك، يمكن للمستخدم الوصول إلى كائنات Energy Harvester من أجل جمعها
المعلومات المتعلقة بالطاقة القابلة للحصاد الحالية وإجمالي الطاقة التي يتم حصادها بواسطة
حصاد.

أمثلة
الدلائل سبيل المثال، src/أمثلة/الطاقة أمثلة/الطاقة، تحتوي على بعض التعليمات البرمجية الأساسية
الذي يوضح كيفية إعداد الإطار.

المساعدون
الطاقة مصدر المساعد
فئة المساعدة الأساسية لكائنات مصدر الطاقة، يقوم هذا المساعد بتجميع كائن مصدر الطاقة
على عقدة. يؤدي تنفيذ هذه الفئة إلى إنشاء كائن مصدر الطاقة الفعلي.

الجهاز الطاقة الموديل المساعد
فئة المساعدة الأساسية لكائنات نموذج طاقة الجهاز، يقوم هذا المساعد بإرفاق طاقة الجهاز
نموذج الكائنات على كائنات مصدر الطاقة. يؤدي تنفيذ الطفل لهذه الفئة إلى إنشاء
كائن نموذج طاقة الجهاز الفعلي.

الطاقة اﻟﺤﺼﺎد المساعد
فئة المساعدة الأساسية لكائنات Energy Harvester، يقوم هذا المساعد بإرفاق Energy Harvester
كائنات على كائنات مصدر الطاقة. يؤدي تنفيذ الطفل لهذه الفئة إلى إنشاء ملف فعلي
كائن حصادة الطاقة.

السمات
تختلف السمات بين مصادر الطاقة، ونماذج طاقة الأجهزة، وحصادات الطاقة
التطبيقات، يرجى إلقاء نظرة على فئة فرعية محددة للحصول على التفاصيل.

Basic الطاقة مصدر
· مصدر الطاقة الأساسيالطاقة الأوليةJ: الطاقة الأولية المخزنة في مصدر الطاقة الأساسية.

· الأساسيةإمدادات الطاقةالجهدV: جهد الإمداد الأولي لمصدر الطاقة الأساسي.

· فترة تحديث الطاقة الدورية: الوقت بين تحديثين دوريين متتاليين للطاقة.

RV خصائص اخرى : محرر صور وفيديو وعارض مستندات الموديل
· RvBatteryModelPeriodicEnergyUpdateInterval: الفاصل الزمني لأخذ عينات طراز بطارية RV.

· RvBatteryModelOpenCircuitVoltage: نموذج بطارية RV جهد ​​الدائرة المفتوحة.

· RvBatteryModelCutoffVoltage: قطع الجهد الكهربي لنموذج بطارية RV.

· RvBatteryModelAlphaValue: قيمة ألفا لنموذج بطارية RV.

· RvBatteryModelBetaValue: القيمة التجريبية لنموذج بطارية RV.

· RvBatteryModelNumOfTerms: عدد شروط المجموع اللانهائي لتقدير البطارية
.

واي فاي راديو الطاقة الموديل
· IdleCurrentA: تيار الخمول الافتراضي للراديو في أمبير.

· CcaBusyCurrentA: الراديو الافتراضي CCA Busy State الحالي في Ampere.

· TxCurrentA: تيار الراديو Tx في أمبير.

· RxCurrentA: تيار الراديو Rx في أمبير.

· التبديل الحالي أ: مفتاح قناة الراديو الافتراضي الحالي في أمبير.

· SleepCurrentA: الراديو النوم الحالي في أمبير.

· TxCurrentModel: مؤشر إلى نموذج tx الحالي المرفق.

Basic الطاقة حاصدة
· دورية HarvestedPowerUpdateInterval: الوقت بين تحديثين دوريين متتاليين لل
القوة المحصودة.

· قوة قابلة للحصاد: متغيرات عشوائية تمثل مقدار الطاقة التي يتم توفيرها
بواسطة حصادة الطاقة.

البحث عن المفقودين
تختلف القيم المتتبعة بين مصادر الطاقة، ونماذج طاقة الأجهزة، وحصادات الطاقة
التطبيقات، يرجى إلقاء نظرة على فئة فرعية محددة للحصول على التفاصيل.

Basic الطاقة مصدر
· الطاقة المتبقية: الطاقة المتبقية في BasicEnergySource.

RV خصائص اخرى : محرر صور وفيديو وعارض مستندات الموديل
· RvBatteryModelBatteryLevel: مستوى بطارية طراز بطارية RV.

· RvBatteryModelBatteryLifetime: عمر بطارية طراز بطارية RV.

واي فاي راديو الطاقة الموديل
· إجمالي استهلاك الطاقة: إجمالي استهلاك الطاقة لجهاز الراديو.

Basic الطاقة حاصدة
· القوة المحصودة: الطاقة الحالية المقدمة من BasicEnergyHarvester.

· إجمالي الطاقة الحصاد: إجمالي الطاقة التي تم حصادها بواسطة BasicEnergyHarvester.

التحقق
لم يتم إجراء مقارنة إطار الطاقة بالأجهزة الفعلية. حاضِر
يتم فحص تنفيذ إطار الطاقة رقميًا بحثًا عن أخطاء حسابية. ال
يتم التحقق من صحة طراز بطارية RV من خلال مقارنة النتائج بما تم تقديمه في النسخة الأصلية
ورق نموذج بطارية RV.

FLOW MONITOR

الموديل الوصف
الكود المصدري للوحدة الجديدة موجود في الدليل src/flow-monitor.

هدف وحدة مراقبة التدفق هو توفير نظام مرن لقياس أداء
بروتوكولات الشبكة. تستخدم الوحدة مجسات مثبتة في عقد الشبكة لتتبع
الحزم المتبادلة بين العقد، وسوف يتم قياس عدد من المعلمات. الحزم هي
مقسمة حسب التدفق الذي تنتمي إليه، حيث يتم تعريف كل تدفق حسب
خصائص المسبار (على سبيل المثال، بالنسبة لـ IP، يتم تعريف التدفق على أنه الحزم التي لها نفس
{البروتوكول، المصدر (IP، المنفذ)، الوجهة (IP، المنفذ)} tuple.

يمكن تصدير الإحصائيات المجمعة لكل تدفق بتنسيق XML. وعلاوة على ذلك، فإن
يمكن للمستخدم الوصول إلى التحقيقات مباشرة لطلب إحصائيات محددة حول كل تدفق.

تصميم
تم تصميم وحدة مراقبة التدفق بطريقة معيارية. ويمكن تمديده عن طريق فئة فرعية
ns3::FlowProbe ns3::FlowClassifier.

تم وصف تصميم الوحدة الكاملة في [FlowMonitor]

مجال القيود
في الوقت الحالي، تتوفر المسابير والمصنفات لـ IPv4 وIPv6.

سيقوم كل مسبار بتصنيف الحزم في أربع نقاط:

· عند إرسال حزمة (تتبعات SendOutgoing IPv[4,6])

· عند إعادة توجيه الحزمة (تتبعات UnicastForward IPv[4,6])

· عند استلام حزمة (تتبعات LocalDeliviver IPv[4,6])

· عند إسقاط حزمة (إسقاط آثار IPv[4,6])

وبما أنه يتم تعقب الحزم على مستوى IP، فإن أي إعادة إرسال تنتج عن بروتوكولات L4
(على سبيل المثال، TCP) سوف يراها المسبار كحزمة جديدة.

ستتم إضافة علامة إلى الحزمة (ns3::Ipv[4,6]FlowProbeTag). سوف تحمل العلامة الأساسية
بيانات الحزمة، مفيدة لتصنيف الحزمة.

يجب التأكيد على أن حزم L4 (TCP، UDP) فقط هي التي تم تصنيفها حتى الآن. علاوة على ذلك،
سيتم تصنيف الحزم أحادية البث فقط. قد تتم إزالة هذه القيود في المستقبل.

البيانات التي تم جمعها لكل تدفق هي:

· timeFirstTxPacket: عندما يتم إرسال الحزمة الأولى في التدفق؛

· timeLastTxPacket: متى تم إرسال الحزمة الأخيرة في التدفق؛

· timeFirstRxPacket: عندما يتم استلام الحزمة الأولى في التدفق بواسطة عقدة النهاية؛

· timeLastRxPacket: متى تم استلام آخر حزمة في التدفق؛

· DelaySum: مجموع كل التأخيرات من طرف إلى طرف لجميع حزم التدفق المستلمة.

· jitterSum : مجموع جميع قيم ارتعاش التأخير (تباين التأخير) للجميع
تلقى حزم التدفق، كما هو محدد في RFC 3393;

· txBytes، txPackets: العدد الإجمالي للبايتات / الحزم المرسلة للتدفق.

· rxBytes، rxPackets: العدد الإجمالي للبايتات / الحزم المستلمة للتدفق؛

· الحزم المفقودة: إجمالي عدد الحزم التي من المفترض أن تكون مفقودة (لم يتم الإبلاغ عنها أكثر من 10
ثواني)؛

· timesForwarded: عدد المرات التي تم فيها إعادة توجيه الحزمة.

· تأخير الرسم البياني، غضب الرسم البياني، packetSizeHistogram: إصدارات الرسم البياني للتأخير،
غضب، وأحجام الحزمة، على التوالي؛

· الحزم المسقطة، البايتات المسقطة: عدد الحزم والبايتات المفقودة، مقسمة حسب
رمز سبب الخسارة (المحدد في التحقيق).

ومن الجدير بالذكر أن المجسات تقيس بايتات الحزمة بما في ذلك رؤوس IP.
لا يتم تضمين رؤوس L2 في هذا الإجراء.

ستتم كتابة هذه الإحصائيات في نموذج XML عند الطلب (راجع قسم الاستخدام).

مراجع حسابات
[مراقبة التدفق]

جي كارنيرو، بي فورتونا، وم. ريكاردو. 2009. FlowMonitor: إطار مراقبة الشبكة
لمحاكاة الشبكة 3 (NS-3). في وقائع المؤتمر الدولي الرابع ICST
مؤتمر حول منهجيات وأدوات تقييم الأداء (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

الأستعمال
استخدام الوحدة بسيط للغاية. سوف يعتني المساعد بكل شيء.

الاستخدام النموذجي هو:

// مراقبة التدفق
بي تي آر this.flowMonitor;
FlowMonitorHelperflowHelper;
flowMonitor =flowHelper.InstallAll();

محاكي::Stop (Seconds(stop_time));
محاكي :: تشغيل () ؛

flowMonitor->SerializeToXmlFile("NameOfFile.xml", true, true);

هيه تسلسلToXmlFile () يتم استخدام معلمات الوظيفة الثانية والثالثة على التوالي
تنشيط/إلغاء تنشيط الرسوم البيانية والإحصائيات التفصيلية لكل مسبار.

يمكن العثور على بدائل أخرى محتملة في وثائق Doxygen.

المساعدون
تتبع واجهة API المساعدة استخدام النمط للمساعدين العاديين. من خلال المساعد يمكنك
قم بتثبيت الشاشة في العقد، وقم بتعيين سمات الشاشة، وطباعة الإحصائيات.

شيء واحد مهم هو: ns3::FlowMonitorHelper يجب إنشاء مثيل مرة واحدة فقط في
رئيسي.

السمات
توفر الوحدة السمات التالية في ns3::FlowMonitor:

· MaxPerHopDelay (الوقت، الافتراضي 10 ثوانٍ): الحد الأقصى لتأخير كل قفزة الذي ينبغي أخذه في الاعتبار؛

· وقت البدء (الوقت، الافتراضي 0): الوقت الذي يبدأ فيه الرصد.

· DelayBinWidth (مزدوج، الافتراضي 0.001): العرض المستخدم في الرسم البياني للتأخير.

· JitterBinWidth (مزدوج، الافتراضي 0.001): العرض المستخدم في الرسم البياني للارتعاش.

· PacketSizeBinWidth (مزدوج، الافتراضي 20.0): العرض المستخدم في الرسم البياني لحجم الحزمة.

· FlowInterruptionsBinWidth (مزدوج، الافتراضي 0.25): العرض المستخدم في
الرسم البياني لمقاطع التدفق؛

· FlowInterruptionsMinTime (مزدوج، الافتراضي 0.5): الحد الأدنى للوقت بين الوصول
يعتبر انقطاع التدفق.

الناتج
مخرجات النموذج الرئيسي هي تقرير بتنسيق XML حول إحصائيات التدفق. مثال على ذلك هو:




























تم إنشاء الإخراج بواسطة تدفق TCP من 10.1.3.1 إلى 10.1.2.2.

تجدر الإشارة إلى أن مسبار الفهرس 2 يقوم بالإبلاغ عن المزيد من الحزم والبايتات أكثر من
المشاكل الأخرى. وهذا سلوك طبيعي تمامًا، حيث يتم تجزئة الحزم عند عنوان IP
المستوى في تلك العقدة.

وتجدر الإشارة أيضًا إلى أن مسبار العقدة المستقبلة (الفهرس 4) لا يحسب قيمة
الأجزاء، حيث تتم إعادة التجميع قبل نقطة الفحص.

أمثلة
الأمثلة موجودة في src/flow-monitor/examples.

علاوة على ذلك، تستخدم الأمثلة التالية وحدة مراقبة التدفق:

· أمثلة/matrix-topology/matrix-topology.cc

· أمثلة/التوجيه/manet-routing-compare.cc

· أمثلة/التوجيه/simple-global-routing.cc

· أمثلة/tcp/tcp-variants-comparison.cc

· أمثلة/wireless/multirate.cc

· أمثلة/wireless/wifi-hidden-terminal.cc

استكشاف الأخطاء:
لا تحدد أكثر من واحد ns3::FlowMonitorHelper في المحاكاة.

التحقق
تحتوي الورقة الموجودة في المراجع على وصف كامل للتحقق من صحة الوحدة مقابل أ
شبكة الاختبار.

يتم توفير الاختبارات لضمان وظيفة الرسم البياني الصحيح.

INTERNET عارضات ازياء

Internet كومة
Internet كومة تجميع
فئة عارية العقدة ليست مفيدة جدًا كما هي؛ يجب تجميع الكائنات الأخرى إليه
توفير وظائف العقدة المفيدة.

تشير NS-3 دليل التعليمات البرمجية المصدر src/internet يوفر تنفيذ TCP/IPv4- و
المكونات المتعلقة بـ IPv6. وتشمل هذه IPv4 وARP وUDP وTCP وIPv6 وNeighbor Discovery و
البروتوكولات الأخرى ذات الصلة.

عقد الإنترنت ليست فئات فرعية من عقدة الفئة؛ إنها مجرد عقد تحتوي على ملف
مجموعة من الكائنات المتعلقة بالملكية الفكرية مجمعة لهم. يمكن تجميعها يدويًا أو عبر
وظيفة مساعد InternetStackHelper::تثبيت () الذي يفعل ما يلي لجميع العقد
تم تمريرها كوسائط:

باطل
InternetStackHelper::تثبيت (Ptr عقدة) ثابت
{
إذا (m_ipv4Enabled)
{
/* مكدس IPv4 */
إذا (عقدة->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): التجميع"
""InternetStack إلى عقدة بها كائن Ipv4 موجود");
العودة؛
}

CreateAndAggregateObjectFromTypeId (node, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Icmpv4L4Protocol");
// تعيين التوجيه
Ptr ipv4 = عقدة-> GetObject () ؛
بي تي آر ipv4Routing = m_routing->إنشاء (عقدة);
ipv4->SetRoutingProtocol (ipv4Routing);
}

إذا (m_ipv6Enabled)
{
/* مكدس IPv6 */
إذا (عقدة->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): التجميع"
""InternetStack إلى عقدة بها كائن Ipv6 موجود");
العودة؛
}

CreateAndAggregateObjectFromTypeId (node, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (node, "ns3::Icmpv6L4Protocol");
// تعيين التوجيه
Ptr ipv6 = عقدة-> GetObject () ؛
بي تي آر ipv6Routing = m_routingv6->إنشاء (عقدة)؛
ipv6->SetRoutingProtocol (ipv6Routing);

/* تسجيل ملحقات وخيارات IPv6 */
ipv6->امتدادات التسجيل ();
ipv6->خيارات التسجيل ();
}

إذا (m_ipv4Enabled || m_ipv6Enabled)
{
/* مكدسات UDP وTCP */
CreateAndAggregateObjectFromTypeId (node, "ns3::UdpL4Protocol");
العقدة->AggregateObject (m_tcpFactory.Create ());
بي تي آر المصنع = إنشاء كائن ()؛
العقدة->الكائن التجميعي (المصنع)؛
}
}

حيث توجد تطبيقات متعددة في NS-3 (TCP، توجيه IP)، تتم إضافة هذه الكائنات بواسطة
كائن المصنع (TCP) أو عن طريق مساعد التوجيه (m_routing).

لاحظ أنه تم تكوين بروتوكول التوجيه وتعيينه خارج هذه الوظيفة. بشكل افتراضي،
تتم إضافة البروتوكولات التالية:

باطلة 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.

Internet العقدة بناء
عقدة قادرة على IP (an NS-3 العقدة المعززة بالتجميع لتحتوي على مكدس IP واحد أو أكثر)
لديه الهيكل الداخلي التالي.

طبقة 3 البروتوكولات
في الطبقة السفلية، فوق NetDevices، توجد بروتوكولات "الطبقة 3"، بما في ذلك
IPv4، IPv6، ARP وما إلى ذلك. الفصل بروتوكول IPv4L3 هي فئة التنفيذ التي
الواجهة العامة عادة ما تكون فئة IPv4، ولكن يتم أيضًا استخدام واجهة برمجة التطبيقات العامة Ipv4L3Protocol
داخليا في الوقت الحاضر.

في فئة Ipv4L3Protocol، إحدى الطرق الموضحة أدناه هي احصل على ():

/ **
* تستدعي الطبقة السفلية هذه الطريقة بعد استدعاء L3Demux::Lookup
* تحتاج فئة ARP الفرعية إلى معرفة أي جهاز NetDevice هذا
* الحزمة قادمة إلى:
* - تنفيذ ذاكرة التخزين المؤقت ARP لكل NetDevice
* - إرسال ردود ARP على الجهاز الصحيح
*/
تلقي باطلة (Ptr الجهاز، بي تي آر ص، بروتوكول uint16_t،
عنوان const &from، عنوان const &to، NetDevice::PacketType packetType);

أولاً، لاحظ أن احصل على () تحتوي الدالة على توقيع مطابق لـ RececeCallback
في الفصل العقدة. يتم إدراج مؤشر الوظيفة هذا في معالج بروتوكول العقدة عندما
AddInterface () يسمى. يتم التسجيل الفعلي ببيان مثل
يتبع:

RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Receive، ipv4)،
Ipv4L3Protocol::PROT_NUMBER, 0);

يتم تجميع كائن Ipv4L3Protocol في العقدة؛ لا يوجد سوى بروتوكول Ipv4L3 واحد فقط
هدف. بروتوكولات الطبقة العليا التي تحتوي على حزمة لإرسالها إلى بروتوكول Ipv4L3
يمكن استدعاء الكائن GetObject () للحصول على المؤشر كما يلي:

بي تي آر ipv4 = m_node->GetObject ()؛
إذا (ipv4 != 0)
{
ipv4->إرسال (حزمة، صدر، أبيدر، PROT_NUMBER)؛
}

يوضح هذا الفصل بشكل جيد تقنيتين نستغلهما NS-3 لربط الأشياء ببعضها:
عمليات الاسترجاعات وتجميع الكائنات.

بمجرد أن يحدد توجيه IPv4 أن الحزمة مخصصة للعقدة المحلية، فإنه يعيد توجيهها لأعلى
المدخنة. يتم ذلك من خلال الوظيفة التالية:

باطل
بروتوكول Ipv4L3::LocalDeliver (Ptr الحزمة، Ipv4Header const&ip، uint32_t iif)

الخطوة الأولى هي العثور على كائن Ipv4L4Protocol الصحيح، بناءً على رقم بروتوكول IP.
على سبيل المثال، يتم تسجيل TCP في demux كبروتوكول رقم 6. وأخيرًا، يتم تسجيل يستلم()
وظيفة على Ipv4L4Protocol (مثل TcpL4Protocol::تلقي يسمى.

لم نقدم بعد فئة Ipv4Interface. في الأساس، يتم إقران كل جهاز NetDevice
مع تمثيل IPv4 لهذا الجهاز. في لينكس، هذه الفئة واجهة IPv4 تقريبا
يتوافق مع البنية in_device; والغرض الرئيسي هو توفير عنوان الأسرة
معلومات محددة (عناوين) حول الواجهة.

تحتوي جميع الفئات على آثار مناسبة لتتبع الحزم المرسلة والمستلمة والمفقودة.
يتم تشجيع المستخدمين على استخدامها لمعرفة ما إذا تم إسقاط الحزمة (وأين). أ
الخطأ الشائع هو نسيان تأثيرات قوائم الانتظار المحلية عند إرسال الحزم، على سبيل المثال،
قائمة انتظار ARP. يمكن أن يكون هذا محيرًا بشكل خاص عند إرسال حزم ضخمة أو دفعات من الحزم
باستخدام UDP. قائمة الانتظار المعلقة لذاكرة التخزين المؤقت لـ ARP محدودة (3 مخططات بيانات) وقد تكون حزم IP كذلك
مجزأة، مما يؤدي بسهولة إلى زيادة حجم قائمة انتظار ذاكرة التخزين المؤقت لـ ARP. في تلك الحالات يكون من المفيد
زيادة حجم ذاكرة التخزين المؤقت لـ ARP المعلقة إلى القيمة المناسبة، على سبيل المثال:

Config::SetDefault ("ns3::ArpCache::PendingQueueSize"، UintegerValue (MAX_BURST_SIZE/L2MTU*3));

يتبع تطبيق IPv6 بنية مماثلة. العقد المزدوجة المكدسة (واحدة مع
دعم كل من IPv4 وIPv6) سيسمح لمقبس IPv6 باستقبال اتصالات IPv4 كملف
النظام المزدوج المكدس يفعل ذلك. يمكن ربط المقبس والاستماع إلى نقطة نهاية IPv6
تلقي اتصال IPv4 وسيقوم بإرجاع العنوان البعيد كعنوان IPv4 المعين.
دعم خيار مأخذ التوصيل IPV6_V6ONLY غير موجود حاليًا.

طبقة 4 البروتوكولات مآخذ
سنصف بعد ذلك كيفية ربط بروتوكولات النقل والمقابس والتطبيقات معًا. في
باختصار، كل تطبيق لبروتوكول النقل هو مصنع مقابس. تطبيق ذلك
يحتاج إلى مقبس جديد

على سبيل المثال، لإنشاء مقبس UDP، قد يستخدم التطبيق مقتطف التعليمات البرمجية مثل
التالية:

بي تي آر udpSocketFactory = GetNode ()->GetObject ()؛
بي تي آر m_socket =ocketFactory->CreateSocket();
m_socket->ربط (m_local_address);


ما ورد أعلاه سوف يستعلم عن العقدة للحصول على مؤشر إلى مصنع مقبس UDP الخاص بها، وسيقوم بإنشاء واحد
مثل هذا المقبس، وسوف يستخدم المقبس مع واجهة برمجة التطبيقات (API) المشابهة لواجهة برمجة تطبيقات المقابس المستندة إلى C، مثل
as التواصل () إرسال (). تم تمرير العنوان إلى مأزق (), التواصل ()الطرق أو إرسال ()
قد تكون الوظائف أ عنوان IPv4, عنوان IPv6الطرق أو العنوان. اذا كان العنوان يتم تمريره في و
يحتوي على أي شيء آخر غير أ عنوان IPv4 or عنوان IPv6، ستُرجع هذه الوظائف ملفًا
خطأ. ال مأزق (فارغ) ربط 6 (فارغ) ترتبط الوظائف بـ "0.0.0.0" و "::"
على التوالي.

يمكن أيضًا ربط المقبس بجهاز NetDevice محدد من خلال ملف BindToNetDevice
(بتر جهاز الشبكة) وظيفة. BindToNetDevice (بتر جهاز الشبكة) سوف تلتزم
المقبس إلى "0.0.0.0" و "::" (أي ما يعادل الاتصال مأزق () ربط 6 ()، ما لم يكن
لقد تم بالفعل ربط المقبس بعنوان محدد. تلخيص، التسلسل الصحيح
هو:

بي تي آر udpSocketFactory = GetNode ()->GetObject ()؛
بي تي آر m_socket =ocketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);


أو:

بي تي آر udpSocketFactory = GetNode ()->GetObject ()؛
بي تي آر m_socket =ocketFactory->CreateSocket();
m_socket->ربط (m_local_address);
m_socket->BindToNetDevice (n_netDevice);


ما يلي يثير خطأ:

بي تي آر udpSocketFactory = GetNode ()->GetObject ()؛
بي تي آر m_socket =ocketFactory->CreateSocket();
m_socket->BindToNetDevice (n_netDevice);
m_socket->ربط (m_local_address);


انظر الفصل الخاص NS-3 مآخذ لمزيد من المعلومات.

لقد وصفنا حتى الآن مصنع مقابس (على سبيل المثال فئة UDP) ومأخذ، والذي قد يكون
المتخصصة (على سبيل المثال، فئة UdpSocket). هناك عدد قليل من الأشياء الرئيسية التي تتعلق بـ
مهمة متخصصة تتمثل في إزالة تعدد إرسال الحزمة إلى واحد أو أكثر من مآخذ الاستقبال. المفتاح
الكائن في هذه المهمة هو الطبقة IPv4EndPointDemux. يقوم جهاز إزالة تعدد الإرسال هذا بتخزين كائنات
فئة IPv4EndPoint. تحتوي هذه الفئة على مجموعة العنونة/المنفذ (المنفذ المحلي، المحلي
العنوان ومنفذ الوجهة وعنوان الوجهة) المرتبط بالمقبس والاستقبال
أتصل مرة أخرى. يحتوي رد الاتصال المتلقي هذا على وظيفة استقبال مسجلة بواسطة المقبس. ال
بحث () تقوم الدالة إلى Ipv4EndPointDemux بإرجاع قائمة بكائنات Ipv4EndPoint (قد يكون هناك
تكون قائمة نظرًا لأن أكثر من مأخذ توصيل واحد قد يتطابق مع الحزمة). نسخ بروتوكول الطبقة 4
الحزمة إلى كل Ipv4EndPoint وتستدعيها إلى الأمام () الطريقة، والتي تستدعي بعد ذلك
احصل على () وظيفة مسجلة بواسطة المقبس.

المشكلة التي تنشأ عند العمل مع واجهة برمجة تطبيقات مآخذ التوصيل على أنظمة حقيقية هي الحاجة إلى ذلك
إدارة القراءة من مأخذ توصيل، باستخدام نوع من أنواع الإدخال/الإخراج (على سبيل المثال، الحظر، عدم الحظر،
غير متزامن، ...). NS-3 ينفذ نموذجًا غير متزامن لمأخذ الإدخال/الإخراج؛ تطبيق
يضبط رد الاتصال ليتم إعلامك بالبيانات المستلمة الجاهزة للقراءة، ويكون رد الاتصال
يتم استدعاؤه بواسطة بروتوكول النقل عندما تكون البيانات متاحة. تم تحديد رد الاتصال هذا كـ
يتبع:

باطلة المقبس::SetRecvCallback (رد الاتصال ,
بي تي آر ,
عنوان ثابت&> البيانات المستلمة)؛

يتم نقل البيانات التي يتم تلقيها في المخزن المؤقت لحزم البيانات. مثال على الاستخدام في
فئة PacketSink:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this));

لتلخيص ذلك، داخليًا، يتم تنظيم تنفيذ UDP على النحو التالي:

· أ UdpImpl فئة تنفذ وظيفة مصنع مقبس UDP

· أ UdpL4Protocol فئة تنفذ منطق البروتوكول المستقل عن المقبس

· أ UdpSocketImpl فئة تنفذ الجوانب الخاصة بمقبس UDP

· فئة تسمى IPv4EndPoint الذي يخزن صف العنونة (المنفذ المحلي، العنوان المحلي،
منفذ الوجهة وعنوان الوجهة) المرتبط بالمقبس والاستقبال
رد الاتصال للمأخذ.

قادرة على IP العقدة واجهات
العديد من تفاصيل التنفيذ، أو الكائنات الداخلية نفسها، لـ Node
لا يتم عرض الكائنات في واجهة برمجة التطبيقات العامة للمحاكاة. وهذا يسمح لمختلف
التنفيذ؛ على سبيل المثال، استبدال الأم NS-3 النماذج ذات مكدس TCP/IP المنقول
رمز.

تم العثور على واجهات برمجة التطبيقات العامة C++ لجميع هذه الكائنات في ملف src / الشبكة الدليل،
بما في ذلك بشكل رئيسي:

· عنوان.ح

· المقبس. ح

· عقدة

· الحزمة. ح

هذه عادةً ما تكون كائنات فئة أساسية تقوم بتنفيذ القيم الافتراضية المستخدمة في ملف
التنفيذ، وتنفيذ طرق الوصول للحصول على/تعيين متغيرات الحالة، وسمات المضيف، و
تنفيذ الأساليب المتاحة للجمهور المكشوفة للعملاء مثل CreateSocket.

مثال مسار of a حزمة
يوضح هذان الشكلان مثالاً لتتبع المكدس لكيفية تدفق الحزم عبر الإنترنت
كائنات العقدة.
[صورة] إرسال مسار الحزمة..UNINDENT
[صورة] تلقي مسار الحزمة..UNINDENT

IPv4
نائب الفصل

IPv6
يصف هذا الفصل NS-3 قدرات وقيود نموذج IPv6 بالإضافة إلى
الاستخدام والأمثلة.

IPv6 نموذج وصف
تم تصميم نموذج IPv6 بشكل فضفاض بعد تطبيق Linux؛ التنفيذ هو
ليست كاملة لأن بعض ميزات IPv6 ليست ذات أهمية كبيرة لدراسات المحاكاة، و
بعض ميزات IPv6 لم يتم تصميمها بعد NS-3.

الطبقة الأساسية IPv6 يحدد واجهة برمجة التطبيقات العامة، في حين أن الفئة بروتوكول IPv6L3 هو الفعلي
فئة تنفيذ البروتوكول. توجد الفئات الفعلية التي يستخدمها مكدس IPv6
بشكل رئيسي في الدليل src/internet.

تم تضمين تنفيذ 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/ndisc-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، وبروتوكول icmpv6-l4، وما إلى ذلك)

· نماذج التوجيه (أي أي شيء يحمل اسمه "توجيه")

· المقابس والواجهات (على سبيل المثال، ipv6-raw-socket، وipv6-interface، وipv6-end-point، وما إلى ذلك)

· الأمور المتعلقة بالعنوان

· الرؤوس، ورؤوس الخيارات، ورؤوس الامتداد، وما إلى ذلك.

· فئات الملحقات (على سبيل المثال، ذاكرة التخزين المؤقت ndisc)

الأستعمال
يعتمد الوصف التالي على استخدام المساعدين النموذجيين الموجودين في رمز المثال.

لا يحتاج IPv6 إلى التنشيط في العقدة. يتم إضافته تلقائيا إلى المتاحة
البروتوكولات بمجرد تثبيت Internet Stack.

لكي ليس تثبيت IPv6 مع IPv4، فمن الممكن استخدامه
ns3 :: InternetStackHelper طريقة SetIpv6StackInstall (منطقي يُمكَِن) قبل تثبيت
InternetStack في العقد.

لاحظ أنه للحصول على شبكة IPv6 فقط (أي عدم تثبيت مكدس IPv4 في العقدة)
يجب استخدام ns3 :: InternetStackHelper طريقة SetIpv4StackInstall (منطقي يُمكَِن) أمام
تركيب المكدس.

على سبيل المثال، في العقدة البرمجية التالية، ستحتوي العقدة 0 على كل من IPv4 وIPv6، والعقدة 1 فقط
IPv6 والعقدة 2 فقط IPv4:

NodeContainer n ؛
ن.إنشاء (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. ستحتوي جميع أجهزة NetDevices الأخرى على IPv6 واحد أو أكثر
عناوين:

· عنوان ارتباط محلي واحد: fe80::interface ID، حيث الواجهة ID مشتق من
عنوان MAC الخاص بـ NetDevice.

· صفر أو أكثر من العناوين العالمية، على سبيل المثال، 2001: دي بي 8 :: 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 ("تعيين عناوين IPv6.");
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 ؛
بي تي آر الجهاز = ndc.Get (0)؛
بي تي آر العقدة = الجهاز->GetNode ()؛
بي تي آر ipv6proto = العقدة->GetObject ()؛
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (device);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

يستخرج تلقائيا IPv6 العناوين
يتم تحقيق ذلك من خلال الاعتماد على بروتوكول RADVD الذي ينفذه الفصل رادفد. في
الوقت لا يوجد مساعد لهذا التطبيق، والاستخدام صعب نوعا ما (انظر
أمثلة/ipv6/radvd.cc).

عند استخدام هذه الطريقة، سوف تكتسب العقد ديناميكيًا (أي أثناء المحاكاة)
عنوان (عناوين) عالمي واحد (أو أكثر) وفقًا لتكوين RADVD. هذه العناوين
ستكون قواعد على البادئة المعلنة لـ RADVD وEUI-64 الخاصة بالعقدة.

عشوائية IPv6 العناوين
في حين أن العقد الحقيقية لـ IPv6 ستستخدم عناوين تم إنشاؤها عشوائيًا لحماية الخصوصية، NS-3 هل
لا تملك هذه القدرة. لم يتم اعتبار هذه الميزة مثيرة للاهتمام حتى الآن
محاكاة.

مكررة العنوان كشف (DAD)
ستقوم العقد بتنفيذ DAD (يمكن تعطيله باستخدام ملف بروتوكول Icmpv6L4 يصف). على
ومع ذلك، عند تلقي DAD، لن تتفاعل العقد معه. كما هو: رد فعل DAD غير مكتمل لذلك
بعيد. يعتمد السبب الرئيسي على القدرة المفقودة على العناوين التي تم إنشاؤها عشوائيًا. علاوة على ذلك،
منذ NS-3 عادةً ما تكون العقد تعمل بشكل جيد، ولا ينبغي أن يكون هناك أي عنوان مكرر.
قد يتم تغيير هذا في المستقبل، وذلك لتجنب مشاكل التكامل مع العالم الحقيقي
المحاكاة.

مضيف راوتر سلوك in IPv6 NS-3
في IPv6 هناك تمييز واضح بين الموجهات المضيفين. وكما قد يتوقع المرء،
يمكن لأجهزة التوجيه إعادة توجيه الحزم من واجهة إلى واجهة أخرى، بينما يسقط المضيفون
الحزم غير موجهة لهم.

لسوء الحظ، إعادة التوجيه ليست هي الشيء الوحيد الذي يتأثر بهذا التمييز، و
قد يتم ضبط عملية إعادة التوجيه نفسها بشكل دقيق، على سبيل المثال، لإعادة توجيه الحزم الواردة من الواجهة
وإسقاط الحزم من واجهة أخرى.

In NS-3 تم تكوين العقدة لتكون مضيف بشكل افتراضي. هناك طريقتان رئيسيتان للتغيير
هذا السلوك:

· استخدام ns3::Ipv6InterfaceContainer SetForwarding(uint32_t i, منطقي جهاز التوجيه) أين i هل
فهرس الواجهة في الحاوية.

· تغيير ns3 :: IPv6 السمة إيبفوروارد.

يمكن استخدام أي منهما أثناء المحاكاة.

يمكن تحقيق الإعداد الدقيق باستخدام ns3::Ipv6Interface SetForwarding (منطقي
إلى الأمام)؛ والذي يسمح بتغيير السلوك على أساس كل واجهة.

لاحظ أن التكوين على مستوى العقدة يعمل فقط كطريقة مناسبة للتمكين/التعطيل
هيه ns3::Ipv6Interface إعداد محدد. تمت إضافة واجهة Ipv6Interface إلى العقدة مع إعادة التوجيه
سيتم تعيين تمكين لإعادة التوجيه أيضًا. هذا مهم حقًا عندما تكون هناك عقدة
واجهات المضافة أثناء المحاكاة.

وفقًا ns3::Ipv6Interface حالة إعادة التوجيه، يحدث ما يلي:

· إعادة توجيه OFF

· لن ترد العقدة على طلب جهاز التوجيه

· سوف تتفاعل العقدة مع إعلان جهاز التوجيه

· ستقوم العقدة بإرسال طلب توجيه بشكل دوري

· يجب على بروتوكولات التوجيه إسقاط الحزم غير الموجهة إلى العقدة

· إعادة التوجيه

· سوف تقوم العقدة بالرد على طلب جهاز التوجيه

· لن تتفاعل العقدة مع إعلان جهاز التوجيه

· لن تقوم العقدة بإرسال التماس جهاز التوجيه

· يجب أن تقوم بروتوكولات التوجيه بإعادة توجيه الحزم

يتطابق السلوك مع ip-sysctl.txt (-
http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) مع اختلاف ذلك
ليس من الممكن تجاوز السلوك باستخدام الإعدادات الباطنية (على سبيل المثال، إعادة التوجيه ولكن
قبول إعلانات جهاز التوجيه، أو Accept_ra=2، أو إعادة التوجيه ولكن إرسال طلبات جهاز التوجيه
إعادة التوجيه = 2).

فكر بعناية في الآثار المترتبة على إعادة توجيه الحزم. على سبيل المثال، لن تقوم العقدة بذلك
إرسال رسائل ICMPv6 PACKET_TOO_BIG من واجهة مع إيقاف تشغيلها. هذا هو
طبيعي تمامًا، حيث سيقوم بروتوكول التوجيه بإسقاط الحزمة قبل محاولة القيام بذلك
إحالتها.

المساعدون
عادة ما تكون المساعدات المستخدمة في إعداد IPv6 هي:

· ns3 :: InternetStackHelper

· ns3::Ipv6AddressHelper

· ns3::Ipv6InterfaceContainer

الاستخدام مطابق تقريبًا لحالة IPv4 المقابلة، على سبيل المثال:

NodeContainer n ؛
ن.إنشاء (4)؛

NS_LOG_INFO ("إنشاء مكدس إنترنت IPv6")؛
InternetStackHelper internetv6;
internetv6.Install (ن)؛

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);

بالإضافة إلى ذلك، هناك مهمة شائعة تتمثل في تمكين إعادة التوجيه على إحدى العقد وإعداد ملف
المسار الافتراضي نحوه في العقد الأخرى، على سبيل المثال:

iic.SetForwarding (0، صحيح)؛
iic.SetDefaultRouteInAllNodes (0);

سيؤدي هذا إلى تمكين إعادة التوجيه على العقدة 0 وسيتم إعداد المسار الافتراضي في
ns3::Ipv6StaticRouting على جميع العقد الأخرى. لاحظ أن هذا يتطلب ذلك
Ipv6StaticRouting موجود في العقد.

تمكن مساعدات توجيه IPv6 المستخدم من أداء مهام محددة على وجه الخصوص
خوارزمية التوجيه وطباعة جداول التوجيه.

السمات
العديد من الفصول في NS-3 يحتوي تطبيق IPv6 على سمات. الأكثر فائدة هي:

· ns3 :: IPv6

· إيبفوروارد، منطقية، كاذبة افتراضية. تمكين أو تعطيل إعادة توجيه IP للجميع على المستوى العالمي
أجهزة IPv6 الحالية والمستقبلية.

· MtuDiscover، منطقية، صحيح الافتراضي. إذا تم تعطيله، فستحتوي كل واجهة على وحدة الإرسال الكبرى (MTU) الخاصة بها
تعيين إلى 1280 بايت.

· ns3 :: Ipv6L3Protocol

· DefaultTtl، uint8_t، الافتراضي 64. يتم تعيين قيمة TTL افتراضيًا على كافة الحزم الصادرة
تم إنشاؤها على هذه العقدة.

· إرسالIcmpv6إعادة التوجيه، منطقي، صحيح افتراضي. أرسل إعادة توجيه ICMPv6 عندما يكون ذلك مناسبًا.

· ns3 :: Icmpv6L4Protocol

· ابي، منطقي، صحيح افتراضي. قم دائمًا بالتحقق من DAD (الكشف عن العناوين المكررة).

· ns3::NdiscCache

· حجم قائمة الانتظار غير المحلولة، uint32_t، الافتراضي 3. حجم قائمة الانتظار للحزم المعلقة NA
الرد.

الناتج
يوفر مكدس IPv6 بعض مصادر التتبع المفيدة:

· ns3 :: Ipv6L3Protocol

· Tx، أرسل حزمة IPv6 إلى الواجهة الصادرة.

· Rx، تلقي حزمة IPv6 من الواجهة الواردة.

· قطرة، إسقاط حزمة IPv6.

· ns3::امتداد Ipv6

· قطرة، إسقاط حزمة IPv6.

يتم إنشاء أحدث مصدر تتبع عندما تحتوي الحزمة على خيار غير معروف يحظرها
معالجة.

اهتم بذلك ns3::NdiscCache يمكن أن يسقط الحزم أيضًا، ولا يتم تسجيل دخولهم في التتبع
المصدر (حتى الآن). قد يؤدي هذا إلى حدوث بعض الالتباس في عدادات الحزم المرسلة/المستلمة.

متقدم الأستعمال
IPv6 أقصى انتقال وحدة (متو) تجزئة
NS-3 تحدد NetDevices وحدة الإرسال الكبرى (MTU) وفقًا لجهاز محاكاة L2. IPv6 يتطلب ذلك
الحد الأدنى لوحدة الإرسال الكبرى (MTU) هو 1280 بايت، لذا يتعين على جميع أجهزة NetDevices دعم هذا على الأقل
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 دقائق. بعد انتهاء صلاحية إدخال ذاكرة التخزين المؤقت، سيتم
تتم إزالة معلومات مسار MTU وستقوم الحزمة التالية (في النهاية) بتشغيل ICMPv6 جديد
رسالة PACKET_TOO_BIG. لاحظ أن 1) هذا يتوافق مع مواصفات RFC و2)
بروتوكولات L4 مسؤولة عن إعادة إرسال الحزم.

أمثلة
توجد أمثلة لـ IPv6 في الدليل أمثلة/ipv6. تركز هذه الأمثلة على أكثر من غيرها
خصائص IPv6 المثيرة للاهتمام، مثل التجزئة وإعادة التوجيه وما إلى ذلك.

علاوة على ذلك، فإن معظم أمثلة TCP وUDP موجودة في أمثلة/udp, أمثلة/برنامج التعاون الفني، وما إلى ذلك لديها
خيار سطر الأوامر لاستخدام IPv6 بدلاً من IPv4.

استكشاف الأخطاء:
لا يوجد سوى عدد قليل من المزالق التي يجب تجنبها أثناء الاستخدام NS-3 الإصدار IPv6.

التوجيه الحلقات
نظرًا لأن نظام التوجيه الوحيد (حتى الآن) المتاح لـ IPv6 هو ns3::Ipv6StaticRouting,
يجب إعداد جهاز التوجيه الافتراضي يدويًا. عندما يكون هناك جهازي توجيه أو أكثر في الشبكة
(على سبيل المثال، العقدة A والعقدة B)، تجنب استخدام الوظيفة المساعدة SetDefaultRouteInAllNodes For
أكثر من جهاز توجيه.

ستكون النتيجة تثبيت مسار افتراضي إلى B في A وتوجيه مسار افتراضي
إلى A في B، مما يؤدي إلى إنشاء حلقة.

أبحاث العنوان تسرب
تذكر أن العناوين الموجودة في IPv6 موجودة شامل حسب التعريف. عند استخدام IPv6 مع
محاكاة NS-3 القدرة، وتجنب بأي ثمن معالجة التسرب نحو الإنترنت العالمية.
يُنصح بإعداد جدار حماية خارجي لمنع التسرب.

2001:DB8::/32 عناوين
يحدد معيار IPv6 (RFC 3849) نطاق 2001:DB8::/32 فئة العنوان ل توثيق.
يستخدم هذا الدليل هذه الاتفاقية. ومع ذلك، فإن العناوين الموجودة في هذه الفئة قابلة للاستخدام فقط في
مستند، ويجب على أجهزة التوجيه التخلص منها.

التحقق
لم يتم حتى الآن التحقق من صحة بروتوكولات IPv6 على نطاق واسع مقابل التطبيقات الحقيقية.
تتضمن الاختبارات الفعلية بشكل أساسي إجراء عمليات فحص لملفات التتبع ‎.pcap باستخدام Wireshark،
والنتائج إيجابية.

التوجيه نظرة عامة
NS-3 يهدف إلى دعم أساليب وبروتوكولات التوجيه التقليدية، ودعم منافذ
تطبيقات التوجيه مفتوحة المصدر، وتسهيل البحث في التوجيه غير التقليدي
التقنيات. تم توضيح بنية التوجيه الشاملة أدناه في التوجيه هندسة معمارية.
يمكن للمستخدمين الذين يرغبون في القراءة فقط حول كيفية تكوين التوجيه العام للطبولوجيا السلكية
اقرأ أبحاث مركزية التوجيه. تم وصف بروتوكولات توجيه البث الأحادي في الإرسال
التوجيه. تم توثيق توجيه البث المتعدد في الإرسال المتعدد التوجيه.

التوجيه هندسة معمارية
[صورة] نظرة عامة على التوجيه UNINDENT

نظرة عامة of التوجيه يعرض بنية التوجيه الشاملة لـ Ipv4. الكائنات الرئيسية هي
Ipv4L3Protocol، Ipv4RoutingProtocol (الفئة التي تم توجيه/إعادة التوجيه إليها
مفوض من Ipv4L3Protocol)، وIpv4Route(s).

يجب أن يشتمل بروتوكول Ipv4L3Protocol على بروتوكول Ipv4RoutingProtocol واحد على الأقل مضافًا إليه عند المحاكاة
وقت الإعداد. يتم ذلك بشكل صريح عن طريق استدعاء Ipv4::SetRoutingProtocol ().

تعلن الفئة الأساسية المجردة Ipv4RoutingProtocol () عن واجهة بسيطة تتكون من
من طريقتين: RouteOutput () وRouteInput (). بالنسبة للحزم التي تسافر للخارج من
مضيفًا، سيقوم بروتوكول النقل بالاستعلام عن Ipv4 لكائن Ipv4RoutingProtocol
الواجهة، وسيطلب مسارًا عبر Ipv4RoutingProtocol::RouteOutput (). بتر ل
يتم إرجاع كائن Ipv4Route. هذا مشابه لإدخال dst_cache في Linux. ال
يتم نقل Ipv4Route إلى Ipv4L3Protocol لتجنب البحث الثاني هناك. لكن،
ستتطلب بعض الحالات (مثل مآخذ توصيل Ipv4 الخام) استدعاء RouteOutput() مباشرة من
بروتوكول IPv4L3.

بالنسبة للحزم المستلمة للوارد لإعادة التوجيه أو التسليم، يتم تنفيذ الخطوات التالية.
يستدعي Ipv4L3Protocol::Receive() Ipv4RoutingProtocol::RouteInput(). هذا يمر
ملكية الحزمة لكائن Ipv4RoutingProtocol. هناك أربعة عمليات الاسترجاعات المرتبطة
مع هذه الدعوة:

· التسليم المحلي

· UnicastForward

· MulticastForward

· خطأ

يجب أن يقوم Ipv4RoutingProtocol في النهاية باستدعاء إحدى عمليات الاسترجاعات هذه لكل حزمة
فإنه يأخذ المسؤولية عن. هذه هي الطريقة الأساسية التي تعمل بها عملية توجيه الإدخال
لينكس.
[صورة] تخصص توجيه IPv4..UNINDENT

تم تصميم هذه البنية الشاملة لدعم أساليب التوجيه المختلفة، بما في ذلك
(في المستقبل) تطبيق توجيه قائم على السياسات يشبه Linux، استباقي و
بروتوكولات التوجيه عند الطلب، وبروتوكولات التوجيه البسيطة عندما يستخدمها مستخدم المحاكاة
لا يهتم حقًا بالتوجيه.

توجيه IPv4 تخصص. يوضح كيف تشتق بروتوكولات التوجيه المتعددة من هذا
الطبقة الأساسية. توفر فئة Ipv4ListRouting (فئة التنفيذ Ipv4ListRoutingImpl)
نهج توجيه القائمة الموجودة في NS-3. واجهة برمجة التطبيقات الخاصة به هي نفس الفئة الأساسية
Ipv4Routing باستثناء القدرة على إضافة بروتوكولات توجيه متعددة ذات أولوية
(Ipv4ListRouting::AddRoutingProtocol()، Ipv4ListRouting::GetRoutingProtocol()).

تم توضيح تفاصيل بروتوكولات التوجيه هذه أدناه في الإرسال التوجيه. الى الان،
سنبدأ أولاً بقدرة توجيه البث الأحادي الأساسية المخصصة عالميًا
إنشاء جداول التوجيه في وقت المحاكاة t=0 لمستخدمي المحاكاة الذين لا يهتمون بها
التوجيه الديناميكي.

أبحاث مركزية التوجيه
يُطلق على التوجيه المركزي العالمي أحيانًا اسم التوجيه "الله"؛ إنها خاصة
التنفيذ الذي يسير في طوبولوجيا المحاكاة ويدير خوارزمية أقصر مسار، و
يملأ جداول التوجيه الخاصة بكل عقدة. لا يوجد حمل فعلي للبروتوكول (على الروابط المحاكاة)
يتم تكبدها مع هذا النهج. لديها بعض القيود:

· سلكي فقط: غير مخصص للاستخدام في الشبكات اللاسلكية.

· الإرسال فقط: لا يفعل البث المتعدد.

· التدرجية: وقد لاحظ ذلك بعض مستخدمي الطبولوجيا الكبيرة (مثل 1000 عقدة).
التنفيذ الحالي ليس قابلاً للتطوير بشكل كبير. سيكون التوجيه المركزي العالمي
تعديلها في المستقبل لتقليل العمليات الحسابية وأداء وقت التشغيل.

في الوقت الحاضر، يتم توجيه البث الأحادي المركزي العالمي لـ IPv4 عبر كل من نقطة إلى نقطة والمشتركة
روابط (CSMA) مدعومة.

بشكل افتراضي، عند استخدام NS-3 helper API وInternetStackHelper الافتراضي العالمي
ستتم إضافة إمكانية التوجيه إلى العقدة، وسيتم إدراج التوجيه العام كـ
بروتوكول التوجيه ذو أولوية أقل من المسارات الثابتة (أي يمكن للمستخدمين إدراج المسارات
عبر Ipv4StaticRouting API وستكون لها الأسبقية على المسارات التي وجدتها global
التوجيه).

أبحاث الإرسال التوجيه API
واجهة برمجة التطبيقات العامة ضئيلة للغاية. تتضمن البرامج النصية للمستخدم ما يلي:

# تضمين "ns3 / internet-module.h"

إذا تم استخدام InternetStackHelper الافتراضي، فسيتم استخدام مثيل التوجيه العام
مجمعة لكل عقدة. بعد تكوين عناوين IP، يتم استدعاء الوظيفة التالية
سيؤدي ذلك إلى قيام كافة العقد التي تحتوي على واجهة Ipv4 باستقبال جداول إعادة التوجيه
تم إدخاله تلقائيًا بواسطة GlobalRouteManager:

Ipv4GlobalRoutingHelper::PopulateRoutingTables();

ملحوظة: للتذكير بأن جهاز wifi NetDevice سيعمل ولكنه لا يأخذ أي تأثيرات لاسلكية
داخل الحساب. بالنسبة للاتصال اللاسلكي، نوصي بالتوجيه الديناميكي OLSR الموضح أدناه.

من الممكن استدعاء هذه الوظيفة مرة أخرى في منتصف عملية المحاكاة باستخدام
الوظيفة العامة الإضافية التالية:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables();

الذي يقوم بمسح الجداول القديمة، ويستعلم عن العقد للحصول على معلومات الواجهة الجديدة، و
يعيد بناء الطرق.

على سبيل المثال، سيؤدي استدعاء الجدولة هذا إلى إعادة بناء الجداول في وقت قدره 5 ثوانٍ:

محاكي::الجدول (ثواني (5)،
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

هناك نوعان من السمات التي تحكم السلوك. الأول هو
Ipv4GlobalRouting::RandomEcmpRouting. إذا تم التعيين على "صحيح"، فسيتم توجيه الحزم بشكل عشوائي عبرها
مسارات متعددة المسارات متساوية التكلفة. إذا تم التعيين على خطأ (افتراضي)، فسيكون هناك مسار واحد فقط متسق
مستخدم. والثاني هو Ipv4GlobalRouting::RespondToInterfaceEvents. إذا تم تعيينه على صحيح،
إعادة حساب المسارات العالمية ديناميكيًا عند أحداث إشعارات الواجهة (لأعلى/لأسفل، أو
إضافة/إزالة العنوان). إذا تم التعيين على خطأ (افتراضي)، فقد ينقطع التوجيه ما لم يكن المستخدم يدويًا
يستدعي RecomputeRoutingTables() بعد مثل هذه الأحداث. تم ضبط الإعداد الافتراضي على خطأ للمحافظة عليه
إرث NS-3 سلوك البرنامج.

أبحاث التوجيه تطبيق
هذا القسم مخصص للقراء الذين يهتمون بكيفية تنفيذ ذلك. مفردة
الكائن (GlobalRouteManager) مسؤول عن تعبئة المسارات الثابتة على كل عقدة،
باستخدام واجهة برمجة تطبيقات Ipv4 العامة لتلك العقدة. يستعلم عن كل عقدة في الهيكل لـ a
واجهة "globalRouter". إذا تم العثور عليه، فإنه يستخدم واجهة برمجة التطبيقات (API) لتلك الواجهة للحصول على "رابط".
إعلان الحالة (LSA)" لجهاز التوجيه. يتم استخدام إعلانات حالة الارتباط في OSPF
التوجيه، ونحن نتبع تنسيقها.

ومن المهم ملاحظة أن كل هذه الحسابات تتم قبل تدفق الحزم
في الشبكة. وعلى وجه الخصوص، لا يتم تبادل أي حزم حمل أو حزم تحكم
عند استخدام هذا التنفيذ. بدلاً من ذلك، يقوم مدير الطريق العالمي هذا فقط بالتنقل في قائمة
العقد لبناء المعلومات الضرورية وتكوين جدول التوجيه الخاص بكل عقدة.

يقوم GlobalRouteManager بملء قاعدة بيانات حالة الارتباط مع LSAs المجمعة من الكل
البنية. بعد ذلك، بالنسبة لكل جهاز توجيه في الهيكل، يقوم GlobalRouteManager بتنفيذ OSPF
حساب أقصر مسار أولاً (SPF) في قاعدة البيانات، وملء جداول التوجيه
كل عقدة.

الكواجا (http://www.quagga.net) تم استخدام تطبيق OSPF كأساس لـ
منطق حساب التوجيه إحدى فوائد اتباع تطبيق OSPF SPF الحالي هي
أن OSPF قد قام بالفعل بتعريف إعلانات حالة الارتباط لجميع أنواع الشبكات الشائعة
الروابط:

· نقطة إلى نقطة (روابط تسلسلية)

· نقطة إلى عدة نقاط (ترحيل الإطارات، لاسلكي مخصص)

· الوصول المتعدد غير الإذاعي (ATM)

· البث (إيثرنت)

ولذلك، نعتقد أن تمكين أنواع الروابط الأخرى هذه سيكون أكثر وضوحًا الآن
أن إطار OSPF SPF الأساسي موجود.

في الوقت الحاضر، يمكننا التعامل مع الروابط المرقمة من نقطة إلى نقطة IPv4، بالإضافة إلى البث المشترك
روابط (CSMA). كما يتم دعم المسارات المتعددة ذات التكلفة المتساوية. على الرغم من أن أنواع الارتباط اللاسلكي موجودة
مدعومًا بالتنفيذ، لاحظ أنه نظرًا لطبيعة هذا التنفيذ، فإن أي
لن يتم أخذ تأثيرات القناة في الاعتبار وستفترض جداول التوجيه أن كل عقدة
على نفس القناة المشتركة يمكن الوصول إليها من كل عقدة أخرى (أي سيتم التعامل معها
مثل رابط بث CSMA).

يقوم GlobalRouteManager أولاً بالتنقل عبر قائمة العقد ثم يقوم بتجميع GlobalRouter
واجهة كل واحد على النحو التالي:

typedef std::vector <Ptr >::مكرر مكرر؛
for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
{
بي تي آر العقدة = *i;
بي تي آر globalRouter = CreateObject (العقدة)؛
العقدة->AggregateObject (globalRouter);
}

يتم الاستعلام عن هذه الواجهة لاحقًا واستخدامها لإنشاء إعلان حالة الارتباط لكل منها
جهاز التوجيه، ويتم تغذية قاعدة بيانات حالة الارتباط هذه في منطق حساب المسار الأقصر لـ OSPF.
يتم استخدام Ipv4 API أخيرًا لملء المسارات نفسها.

الإرسال التوجيه
يوجد حاليًا سبعة بروتوكولات توجيه أحادية البث محددة لـ 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)

في المستقبل، يجب أن تسمح هذه البنية أيضًا لأي شخص بتنفيذ ما يشبه Linux
التنفيذ باستخدام ذاكرة التخزين المؤقت للتوجيه، أو جهاز التوجيه المعياري Click، ولكن هذه خارج النطاق
الى الان.

IPv[4,6]قائمة التوجيه
يصف هذا القسم الإعداد الافتراضي الحالي NS-3 IPv[4,6]بروتوكول التوجيه. عادة،
يتم دعم بروتوكولات التوجيه المتعددة في مساحة المستخدم والتنسيق لكتابة بروتوكول واحد
جدول إعادة التوجيه في النواة. حاليا في NS-3، التنفيذ بدلاً من ذلك يسمح بذلك
بروتوكولات توجيه متعددة لبناء/الاحتفاظ بحالة التوجيه الخاصة بها، وعنوان IP
سوف يقوم التنفيذ بالاستعلام عن كل واحد من بروتوكولات التوجيه هذه (بترتيب ما يحدده
مؤلف المحاكاة) حتى يتم العثور على الطريق.

لقد اخترنا هذا النهج لأنه قد يسهل بشكل أفضل تكامل المتباينين
أساليب التوجيه التي قد يكون من الصعب تنسيق الكتابة فيها على جدول واحد،
الأساليب التي تحتوي على معلومات أكثر من عنوان IP الوجهة (على سبيل المثال، توجيه المصدر).
تُستخدم لتحديد الخطوة التالية، وأساليب التوجيه حسب الطلب حيث يجب أن تكون الحزم
مخبأ.

IPv[4,6]4ListRouting::AddRoutingProtocol
توفر الفئتان Ipv4ListRouting وIpv6ListRouting تعريفًا خالصًا للوظيفة الافتراضية
للطريقة التي تسمح لأحد بإضافة بروتوكول التوجيه:

باطلة AddRoutingProtocol (Ptr بروتوكول التوجيه,
int16_t الأولوية)؛

باطلة AddRoutingProtocol (Ptr بروتوكول التوجيه,
int16_t الأولوية)؛

يتم تنفيذ هذه الأساليب على التوالي حسب الفئة Ipv4ListRoutingImpl وحسب الفئة
Ipv6ListRoutingImpl في وحدة الإنترنت.

يتحكم متغير الأولوية أعلاه في الأولوية التي تكون فيها بروتوكولات التوجيه
تم إدراجها. لاحظ أنه موقع int. بشكل افتراضي في NS-3، سوف الطبقات المساعدة
إنشاء مثيل لكائن Ipv[4,6]ListRoutingImpl، وإضافة Ipv[4,6]StaticRoutingImpl إليه
كائن في الأولوية صفر. داخليًا، يتم تخزين قائمة IPv[4,6]RoutingProtocols، و
ويتم استشارة كل من بروتوكولات التوجيه بترتيب تنازلي للأولوية للرؤية
ما إذا تم العثور على تطابق. لذلك، إذا كنت تريد أن يكون لـ Ipv4RoutingProtocol الأولوية
أقل من التوجيه الثابت، أدخله بأولوية أقل من 0؛ على سبيل المثال:

بي تي آر myRoutingProto = CreateObject ()؛
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

عند استدعاء RouteOutput() أو RouteInput()، سيقوم كائن توجيه القائمة بالبحث في القائمة
لبروتوكولات التوجيه، بترتيب الأولوية، حتى يتم العثور على المسار. مثل بروتوكول التوجيه
سيتم استدعاء رد الاتصال المناسب ولن يتم البحث في أي بروتوكولات توجيه أخرى.

الأمثل الرابط الولايه او المحافظه التوجيه (أولسر)
تم نقل بروتوكول توجيه IPv4 هذا في الأصل من تطبيق OLSR-UM لـ ns-2.
تم العثور على التنفيذ في دليل src/olsr، ويوجد مثال للبرنامج النصي
أمثلة/بسيطة من نقطة إلى نقطة olsr.cc.

عادةً، يتم تمكين OLSR في البرنامج الرئيسي عن طريق استخدام فئة OlsrHelper التي يتم تثبيتها
OLSR في كائن Ipv4ListRoutingProtocol. سيتم تمكين نماذج الأوامر التالية
OLSR في محاكاة باستخدام هذه الفئة المساعدة مع بعض الكائنات المساعدة الأخرى للتوجيه.
إن تحديد قيمة الأولوية 10، قبل أولوية staticRouting البالغة 0، يعني ذلك
ستتم استشارة OLSR لمعرفة المسار قبل جدول التوجيه الثابت للعقدة.:

حاوية العقدة ج:

// تمكين OLSR
NS_LOG_INFO ("تمكين توجيه OLSR.");
OlsrHelper olsr;

Ipv4StaticRoutingHelper staticRouting;

قائمة Ipv4ListRoutingHelper؛
list.Add (staticRouting, 0);
list.Add (olsr, 10);

إنترنت InternetStackHelper ؛
internet.SetRoutingHelper (قائمة)؛
إنترنت.تثبيت (ج)؛

بمجرد التثبيت، يمكن تعيين "الواجهة الرئيسية" لـ OLSR باستخدام الأمر SetMainInterface().
إذا لم يحدد المستخدم عنوانًا رئيسيًا، فسيقوم البروتوكول بتحديد عنوان IP الأساسي الأول
العنوان الذي يجده، بدءًا من واجهة الاسترجاع أولاً ثم الواجهة التالية
تم العثور على واجهة غير قابلة للاسترجاع، بترتيب فهرس واجهة Ipv4. عنوان الاسترجاع ل
لم يتم تحديد 127.0.0.1. بالإضافة إلى ذلك، تم تعريف عدد من ثوابت البروتوكول في
olsr-routing-protocol.cc.

يبدأ Olsr في الوقت صفر من المحاكاة، بناءً على استدعاء Object::Start()
في النهاية يستدعي OlsrRoutingProtocol::DoStart(). ملاحظة: تصحيح للسماح للمستخدم بالبدء
وإيقاف البروتوكول في أوقات أخرى سيكون موضع ترحيب.

حاليًا، يقتصر استخدام OLSR مع كائن Ipv4ListRouting، ولا يستجيب لـ
التغييرات الديناميكية على عنوان IP الخاص بالجهاز أو ربط الإشعارات لأعلى/لأسفل؛ أي طوبولوجيا
التغييرات ناتجة عن فقدان/كسب الاتصال عبر قناة لاسلكية.

التمزق
بروتوكول توجيه IPv6 هذا (RFC 2080) هو تطور لـ RIPv1 anf RIPv2 المعروف
(انظر RFC 1058 RFC 1723) بروتوكولات التوجيه لـ IPv4.

البروتوكول بسيط جدًا، وعادةً ما يكون مناسبًا للشبكات المسطحة والبسيطة
علوم الهندسة اللاكمية.

يعتمد RIPng بقوة على RIPv1 وRIPv2، وله نفس الأهداف والأهداف
محددات. على وجه الخصوص، يأخذ RIP في الاعتبار أي مسار بمقياس يساوي أو أكبر من 16
كما لا يمكن الوصول إليها. ونتيجة لذلك، يجب أن يكون الحد الأقصى لعدد القفزات في الشبكة أقل
أكثر من 15 (لم يتم ضبط عدد أجهزة التوجيه). ويتم تشجيع المستخدمين على القراءة RFC 2080 RFC
1058 لفهم سلوك RIPng والقيود بشكل كامل.

التوجيه الالتقاء
يستخدم RIPng خوارزمية ناقل المسافة، ويتم تحديث المسارات وفقًا لـ
خوارزمية بيلمان-فورد (تُعرف أحيانًا باسم خوارزمية فورد-فولكرسون). الخوارزمية لديها
وقت التقارب لـ O(|V|*|E|) حيث |V| و |ه| هي عدد القمم (أجهزة التوجيه) و
الحواف (الروابط) على التوالي. وينبغي التأكيد على أن وقت التقارب هو الرقم
من الخطوات في الخوارزمية، ويتم تشغيل كل خطوة بواسطة رسالة. منذ أثار
التحديثات (على سبيل المثال، عند تغيير المسار) لها فترة تهدئة تتراوح من 1 إلى 5 ثوانٍ، ويمكن للهيكل أن يفعل ذلك
تتطلب بعض الوقت حتى تستقر.

يجب أن يدرك المستخدمون أنه أثناء إنشاء جداول التوجيه، قد تسقط أجهزة التوجيه
الحزم. يجب أن يتم إرسال حركة البيانات فقط بعد فترة زمنية كافية للسماح بإنشاء RIPng
طوبولوجيا الشبكة. عادةً ما تكون 80 ثانية كافية للحصول على مستوى دون المستوى الأمثل (لكن
العمل) إعداد التوجيه. يتضمن ذلك الوقت اللازم لنشر المسارات إلى أقصى حد
جهاز توجيه بعيد (16 قفزة) مع تحديثات مشغلة.

إذا تم تغيير هيكل الشبكة (على سبيل المثال، تم قطع الرابط)، فقد يكون وقت الاسترداد هو الوقت المناسب
عالية جدًا، وقد تكون أعلى من وقت الإعداد الأولي. علاوة على ذلك، الشبكة
يتأثر استرداد الهيكل باستراتيجية Split Horizoning.

المثال أمثلة/التوجيه/ripng-simple-network.cc يظهر كلاً من إعداد الشبكة و
مراحل استعادة الشبكة

الانقسام الأفق
Split Horizon هي استراتيجية لمنع عدم استقرار التوجيه. ثلاثة خيارات ممكنة:

· لا يوجد سبليت هورايزون

· سبليت هورايزن

· عكس السم

في الحالة الأولى، يتم الإعلان عن المسارات على جميع واجهات جهاز التوجيه. في الثانية
في هذه الحالة، لن تقوم أجهزة التوجيه بالإعلان عن المسار على الواجهة التي تم التعرف عليها منها.
سيعلن Poison Reverse عن المسار على الواجهة التي تم التعرف عليه منها، ولكن
بمقياس 16 (اللانهاية). للحصول على تحليل كامل للتقنيات الثلاثة، انظر RFC
1058، القسم 2.2.

المثال ripng-simple-network.cc يعتمد على طوبولوجيا الشبكة الموصوفة في RFC،
لكنه لا يظهر التأثير الموصوف هناك.

والسبب هو التحديثات المشغلة، بالإضافة إلى حقيقة أنه عندما يقوم جهاز التوجيه
يبطل المسار، فإنه سيتم على الفور نشر عدم إمكانية الوصول إلى المسار، وبالتالي
منع معظم المشكلات الموضحة في RFC.

ومع ذلك، مع الطوبولوجيا المعقدة، لا يزال من الممكن حدوث ظواهر عدم استقرار المسار
مشابه لتلك الموصوفة في RFC بعد فشل الارتباط. ونتيجة لذلك، كل
الاعتبارات المتعلقة ببقاء Split Horizon صالحة.

الترتيب طرق
يجب تثبيت بروتوكول RIPng فقط على أجهزة التوجيه. ونتيجة لذلك، فإن العقد لن تعرف
ما هو جهاز التوجيه الافتراضي.

للتغلب على هذا القيد، يجب على المستخدمين إما تثبيت المسار الافتراضي يدويًا (على سبيل المثال،
باللجوء إلى Ipv6StaticRouting)، أو باستخدام RADVd. RADVd متاح في NS-3 في ال
وحدة التطبيقات، وهي مقترحة بشدة.

بروتوكول المعلمات الخيارات
التمزق NS-3 يسمح التنفيذ بتغيير جميع الموقتات المرتبطة بالطريق
التحديثات والطرق مدى الحياة.

علاوة على ذلك، يمكن للمستخدمين تغيير مقاييس الواجهة على أساس كل عقدة.

يمكن تحديد نوع Split Horizoning (لتجنب الانتشار الخلفي للمسارات) على أ
على أساس كل عقدة، مع اختيارات "لا يوجد أفق منقسم" و"أفق منقسم" و"سم".
عكس". انظر RFC 2080 لمزيد من التفاصيل، و RFC 1058 للمناقشة الكاملة حول
استراتيجيات تقسيم الأفق.

القيود
لا يوجد دعم لخيار Next Hop (RFC 2080، القسم 2.1.1). القفزة القادمة
يكون الخيار مفيدًا عندما لا يتم تشغيل RIPng على كافة أجهزة التوجيه الموجودة على الشبكة. يدعم
لأنه يمكن النظر في هذا الخيار في المستقبل.

لا يوجد دعم لتجميع بادئات CIDR. ونتيجة لذلك، فإن كلا من جداول التوجيه و
قد تكون إعلانات الطريق أكبر من اللازم. يمكن إضافة تجميع البادئة في
مستقبل.

الإرسال المتعدد التوجيه
يتم استخدام الوظيفة التالية لإضافة مسار بث متعدد ثابت إلى العقدة:

باطل
Ipv4StaticRouting::AddMulticastRoute (أصل عنوان Ipv4،
مجموعة عنوان IPv4,
uint32_t واجهة الإدخال،
الأمراض المنقولة جنسيا::ناقل واجهات الإخراج)؛

يجب أن يحدد مسار البث المتعدد عنوان IP الأصلي ومجموعة البث المتعدد والإدخال
مؤشر واجهة الشبكة كشروط ويوفر ناقلًا لواجهة شبكة الإخراج
المؤشرات التي يتم إرسال الحزم المطابقة للشروط عليها.

عادةً ما يكون هناك نوعان رئيسيان من مسارات البث المتعدد: يتم استخدام مسارات من النوع الأول
أثناء الشحن. ويجب توفير جميع الشروط بشكل صريح. النوع الثاني من
تُستخدم المسارات لإخراج الحزم من العقدة المحلية. الفرق هو في المدخلات
واجهه المستخدم. ستحتوي مسارات إعادة التوجيه دائمًا على واجهة إدخال واضحة محددة.
ستؤدي المسارات خارج العقدة دائمًا إلى تعيين واجهة الإدخال على حرف بدل محدد بواسطة
فهرس Ipv4RoutingProtocol::IF_INDEX_ANY.

بالنسبة للمسارات خارج العقدة المحلية، يمكن استخدام أحرف البدل في الأصل ومجموعة البث المتعدد
عناوين. حرف البدل المستخدم لـ Ipv4Adresses هو ذلك العنوان الذي يتم إرجاعه بواسطة
Ipv4Address::GetAny () - عادةً "0.0.0.0". استخدام حرف البدل يسمح للمرء بالتحديد
السلوك الافتراضي بدرجات متفاوتة.

على سبيل المثال، جعل العنوان الأصلي حرف بدل، مع ترك مجموعة البث المتعدد
محدد يسمح لأحد (في حالة وجود عقدة ذات واجهات متعددة) بإنشاء مختلفة
المسارات التي تستخدم واجهات إخراج مختلفة لكل مجموعة بث متعدد.

إذا تم إنشاء عناوين الأصل والبث المتعدد بأحرف بدل، فقد قمت بإنشاء ملف
عنوان البث المتعدد الافتراضي الذي يمكنه إعادة التوجيه إلى واجهات متعددة. قارن هذا ب
عنوان البث المتعدد الافتراضي الفعلي الذي يقتصر على تحديد واجهة إخراج واحدة
للتوافق مع الوظائف الموجودة في الأنظمة الأخرى.

يقوم أمر آخر بتعيين مسار البث المتعدد الافتراضي:

باطل
Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_toutputInterface);

هذا هو المكافئ المتعدد البث لإصدار البث الأحادي SetDefaultRoute. نقول ل
نظام التوجيه ما يجب القيام به في حالة وجود طريق محدد إلى وجهة البث المتعدد
لم يتم العثور على المجموعة. يقوم النظام بإعادة توجيه الحزم إلى الواجهة المحددة على أمل
أن "الشيء الموجود هناك" يعرف بشكل أفضل كيفية توجيه الحزمة. يتم استخدام هذه الطريقة فقط
في البداية إرسال الحزم من المضيف. لا تتم استشارة مسار البث المتعدد الافتراضي
أثناء إعادة التوجيه - يجب تحديد المسارات الدقيقة باستخدام AddMulticastRoute لهذه الحالة.

نظرًا لأننا نقوم أساسًا بإرسال حزم إلى كيان ما نعتقد أنه قد يعرف بشكل أفضل ما يجب فعله،
نحن لا ننتبه إلى "التفاصيل الدقيقة" مثل عنوان الأصل، ولا نقلق بشأنها
إعادة توجيه واجهات متعددة. إذا تم تعيين مسار البث المتعدد الافتراضي، فسيتم إرجاعه
باعتباره المسار المحدد من LookupStatic بغض النظر عن الأصل أو مجموعة البث المتعدد إذا
لم يتم العثور على طريق محدد آخر.

وأخيرًا، يتم توفير عدد من الوظائف الإضافية لجلب البث المتعدد وإزالته
الطرق:

uint32_t GetNMulticastRoutes (باطل) const؛

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

منطقي RemoveMulticastRoute (أصل عنوان IPv4،
مجموعة عنوان IPv4,
uint32_t inputInterface);

باطلة RemoveMulticastRoute (مؤشر uint32_t)؛

TCP عارضات ازياء in NS-3
يصف هذا الفصل نماذج TCP المتوفرة في NS-3.

عام تقنية For TCP
NS-3 تمت كتابته لدعم تطبيقات TCP المتعددة. التطبيقات ترث من
بعض فئات الرؤوس الشائعة في src / الشبكة الدليل، بحيث يمكن تبديل رمز المستخدم
التنفيذ مع الحد الأدنى من التغييرات على البرامج النصية.

هناك نوعان من الفئات الأساسية المجردة الهامة:

· فصل TcpSocket: تم تعريف ذلك في src/internet/model/tcp-socket.{cc,h}. هذه الفئة
موجود لاستضافة سمات TcpSocket التي يمكن إعادة استخدامها عبر مختلف
التطبيقات. على سبيل المثال، السمة الأوليCwnd يمكن استخدامها لأي من
التطبيقات المستمدة من الطبقة TcpSocket.

· فصل TcpSocketFactory: يتم استخدامه بواسطة مثيل بروتوكول الطبقة الرابعة لإنشاء TCP
مآخذ من النوع الصحيح.

يوجد حاليًا ثلاثة تطبيقات متاحة لـ TCP NS-3.

· برنامج التعاون الفني الذي تم تنفيذه محليًا لـ ns-3

· دعم شبكة محاكاة الحاضنة (NSC)

· الدعم ل مباشرة رمز التنفيذ (ديسي)

وتجدر الإشارة أيضًا إلى أن هناك طرقًا مختلفة للجمع بين الأجهزة الافتراضية NS-3
يتيح أيضًا بعض تطبيقات TCP الإضافية، ولكنها خارج نطاقها
هذا الفصل.

NS-3 TCP
حتى إصدار NS-3.10، NS-3 يحتوي على منفذ لنموذج TCP من GTNetS. هذا
تمت إعادة كتابة التنفيذ بشكل كبير بواسطة Adriam Tam لـ 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/internet/model/tcp-socket-base.{cc,h}
src/internet/model/tcp-tx-buffer.{cc,h}
src/internet/model/tcp-rx-buffer.{cc,h}
سرك/الإنترنت/نموذج/tcp-rfc793.{cc، h}
src/internet/model/tcp-tahoe.{cc,h}
src/internet/model/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/internet/model/tcp-newreno.{cc,h}
src/internet/model/rtt-estimator.{cc,h}
src/network/model/sequence-number.{cc,h}

يتم دعم المتغيرات المختلفة للتحكم في ازدحام TCP من خلال التصنيف الفرعي للقاعدة المشتركة
فئة TcpSocketBase. يتم دعم العديد من المتغيرات، بما في ذلك RFC 793 (لا يوجد ازدحام
التحكم)، تاهو، رينو، ويستوود، ويستوود +، ونيو رينو. يتم استخدام NewReno بشكل افتراضي. يرى
قسم الاستخدام في هذا المستند للتعرف على كيفية تغيير متغير TCP الافتراضي المستخدم فيه
محاكاة.

الأستعمال
في كثير من الحالات، يتم تعيين استخدام TCP في طبقة التطبيق عن طريق إخبار NS-3
تطبيق أي نوع من مصنع المقبس للاستخدام.

استخدام الوظائف المساعدة المحددة في src/applications/helper src/شبكة/مساعد، هنا
هي كيفية إنشاء جهاز استقبال TCP:

// قم بإنشاء مخزن حزم على "المركز" النجمي لتلقي هذه الحزم
منفذ uint16_t = 50000؛
العنوانغرقLocalAddress(InetSocketAddress (Ipv4Address::GetAny(), port));
PacketSinkHelper SinkHelper("ns3::TcpSocketFactory"،sinkLocalAddress);
ApplicationContainer SinkApp = SinkHelper.Install (serverNode)؛
SinkApp.Start (Seconds (1.0));
SinkApp.Stop (Seconds (10.0));

وبالمثل، يقوم المقتطف أدناه بتكوين مصدر حركة مرور OnOffApplication لاستخدام TCP:

// قم بإنشاء تطبيقات OnOff لإرسال TCP إلى الخادم
OnOffHelper clientHelper ("ns3::TcpSocketFactory"، العنوان ())؛

سيلاحظ القارئ الدقيق أعلاه أننا حددنا TypeId لقاعدة مجردة
فئة TcpSocketFactory. كيف يقول السيناريو NS-3 أنه يريد الأصلي NS-3 TCP
مقابل شخص آخر؟ حسنًا، عند إضافة مكدسات الإنترنت إلى العقدة، يتم استخدام TCP الافتراضي
التنفيذ الذي تم تجميعه في العقدة هو NS-3 برنامج التعاون الفني. يمكن تجاوز هذا كما
نعرض أدناه عند استخدام Network Simulation Cradle. لذلك، بشكل افتراضي، عند استخدام NS-3
helper API، TCP الذي يتم تجميعه إلى العقد مع مكدس الإنترنت هو الأصل NS-3
برنامج التعاون الفني.

لتكوين سلوك TCP، يتم تصدير عدد من المعلمات من خلال الملف NS-3
نظام السمات. تم توثيق هذه في Doxygen
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> للصف TcpSocket. إلى
على سبيل المثال، الحد الأقصى لحجم المقطع هو سمة قابلة للتعيين.

لتعيين نوع المقبس الافتراضي قبل إنشاء أي كائنات مرتبطة بمكدس الإنترنت، يجب استخدام XNUMX
يجوز وضع العبارة التالية في أعلى برنامج المحاكاة:

التكوين::SetDefault ("ns3::TcpL4Protocol::SocketType"، StringValue ("ns3::TcpTahoe"))؛

بالنسبة للمستخدمين الذين يرغبون في الحصول على مؤشر إلى المقبس الفعلي (بحيث تشبه عمليات المقبس
يمكن إجراء Bind()، وتعيين خيارات المقبس، وما إلى ذلك على أساس كل مقبس)، ويمكن لمقابس Tcp
يتم إنشاؤها باستخدام المقبس::CreateSocket() طريقة. تم تمرير TypeId إلى
يجب أن يكون CreateSocket() من النوع ns3::SocketFactory، لذا قم بتكوين المقبس الأساسي
يجب أن يتم الكتابة عن طريق التلاعب بالسمة المرتبطة ببروتوكول TcpL4Protocol
هدف. أسهل طريقة لتحقيق ذلك هي من خلال تكوين السمة
نظام. في المثال أدناه، تم الوصول إلى حاوية العقدة "n0n1" للحصول على الصفر
العنصر، ويتم إنشاء مأخذ توصيل على هذه العقدة:

// إنشاء وربط المقبس...
TypeId tid = TypeId::LookupByName("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType"، TypeIdValue (tid));
بي تي آر مقبس محلي =
المقبس::CreateSocket (n0n1.Get (0)، TcpSocketFactory::GetTypeId ());

أعلاه، يتم تمرير الحرف البدل "*" لرقم العقدة إلى نظام تكوين السمات،
بحيث يتم تعيين كافة المقابس المستقبلية على كافة العقد إلى Tahoe، وليس فقط على العقدة "n0n1.Get (0)".
إذا أراد المرء أن يقتصر على العقدة المحددة فقط، فسيتعين عليه القيام بشيء مثل:

// إنشاء وربط المقبس...
TypeId tid = TypeId::LookupByName("ns3::TcpTahoe");
std::stringstream NodeId;
NodeId << n0n1.Get (0)->GetId ();
std::stringحدّد Node = "/NodeList/" +nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (speciNode, TypeIdValue (tid));
بي تي آر مقبس محلي =
المقبس::CreateSocket (n0n1.Get (0)، TcpSocketFactory::GetTypeId ());

بمجرد إنشاء مأخذ توصيل TCP، سيحتاج المرء إلى اتباع منطق مأخذ التوصيل التقليدي وإما
الاتصال () والإرسال () (لعميل TCP) أو الربط () والاستماع () والقبول () (لعميل TCP)
الخادم). راجع واجهات برمجة التطبيقات (Sockets-APIs) لمراجعة كيفية استخدام المقابس NS-3.

التحقق
يمكن العثور على العديد من نتائج اختبار التحقق من صحة TCP في ملف ويكي صفحة وصف هذا
التنفيذ.

حالياًّ القيود
· الكيس غير معتمد

شبكة محاكاة الحاضنة
تشير شبكة محاكاة الحاضنة (NSC) هو إطار لتغليف كود الشبكة في العالم الحقيقي
إلى أجهزة محاكاة، مما يسمح بمحاكاة سلوك العالم الحقيقي بتكلفة إضافية قليلة. هذا
تم التحقق من صحة العمل من خلال مقارنة المواقف باستخدام شبكة اختبارية بنفس الطريقة
المواقف في جهاز محاكاة. لقد ثبت حتى الآن أن مجلس الأمن القومي قادر على الإنتاج
نتائج دقيقة للغاية. يدعم NSC أربعة مكدسات حقيقية: FreeBSD، OpenBSD، lwIP
ولينكس. تم التركيز على عدم تغيير أي من مكدسات الشبكة يدويًا. لا
تم تغيير سطر واحد من التعليمات البرمجية في تطبيقات بروتوكول الشبكة لأي من
الأكوام الأربعة المذكورة أعلاه. ومع ذلك، تم إنشاء محلل لغة C مخصص لتغييره برمجيًا
مصدر الرمز.

تم نقل NSC مسبقًا إلى NS-2 وOMNeT++، وتمت إضافتها إلى NS-3 في سبتمبر
2008 (إصدار ns-3.2). يصف هذا القسم NS-3 منفذ NSC وكيفية استخدامه.

إلى حد ما، تم استبدال NSC بدعم Linux kernel في الداخل مباشرة رمز
التنفيذ (ديسي). ومع ذلك، لا يزال NSC متاحًا من خلال نظام بناء الخبز. مجلس الأمن القومي
يدعم نواة لينكس 2.6.18 و2.6.26، ولكن الإصدارات الأحدث من النواة لم يتم تثبيتها
استدار.

المتطلبات الأساسية المسبقة
في الوقت الحالي، تم اختبار NSC وإظهار قدرته على العمل على هذه الأنظمة الأساسية: Linux i386 وLinux
x86-64. NSC لا يدعم powerpc. الاستخدام على FreeBSD أو OS X غير مدعوم (على الرغم من أنه
قد يكون قادرا على العمل).

يتطلب بناء NSC الحزم المرنة والبيسون.

تكوين تحميل
اعتبارًا من ns-3.17 أو الإصدارات الأحدث، يجب تنزيل NSC بشكل منفصل من مستودعه الخاص،
أو التنزيل عند استخدام خبز نساعدك في بناء نظام of NS-3.

بالنسبة إلى ns-3.17 أو الإصدارات الأحدث، عند استخدام المخبأ، يجب على المرء تكوين NSC كجزء من ملف ns-XNUMX
تكوين "allinone"، مثل:

خبز مؤتمر نزع السلاح $
$ python Bake.py تكوين -e ns-allinone-3.19
تحميل $ بايثون Bake.py
بناء $ بيثون Bake.py

بدلاً من الإصدار الذي تم إصداره، يمكن للمرء استخدام إصدار التطوير ns-3 عن طريق تحديد
"ns-3-allinone" إلى خطوة التكوين أعلاه.

يمكن أيضًا تنزيل NSC من انها بإمكانك تحميله الموقع باستخدام الزئبق:

استنساخ $ hg https://secure.wand.net.nz/mercurial/nsc

قبل إصدار ns-3.17، تم تضمين NSC في allinone tarball وتم إصداره
لا يلزم تنزيل الإصدار بشكل منفصل.

ابني التحقق
قد يتم بناء NSC كجزء من عملية بناء المخبوزات؛ وبدلاً من ذلك، يمكن للمرء بناء مجلس الأمن القومي من خلال
نفسها باستخدام نظام البناء الخاص بها؛ على سبيل المثال:

$ مؤتمر نزع السلاح NSC-ديف
$ بيثون scons.py

بمجرد إنشاء NSC إما يدويًا أو من خلال نظام الخبز، قم بالتغيير إلى NS-3
الدليل المصدر وحاول تشغيل التكوين التالي:

$ ./waf تكوين

إذا تم بناء NSC مسبقًا والعثور عليه بواسطة WAF، فسترى:

مهد محاكاة الشبكة: ممكّن

إذا لم يتم العثور على NSC، سترى:

مهد محاكاة الشبكة: غير ممكّن (لم يتم العثور على NSC (راجع الخيار - with-nsc))

في هذه الحالة، يجب عليك تمرير المسار النسبي أو المطلق إلى مكتبات NSC باستخدام الملف
خيار التكوين "--with-nsc" ؛ على سبيل المثال

$ ./waf تكوين --with-nsc=/path/to/my/nsc/directory

في حالة NS-3 الإصدارات السابقة لإصدار NS-3.17، باستخدام build.py البرنامج النصي في ns-3-allinone
الدليل، سيتم إنشاء NSC بشكل افتراضي ما لم يكن النظام الأساسي يدعمه. ل
قم بتعطيله بشكل صريح عند البناء NS-3، اكتب:

$ ./waf تكوين --enable-examples --enable-tests --disable-nsc

إذا اكتشف WAF NSC، فسيتم البناء NS-3 مع NSC يتم تنفيذه بنفس الطريقة مع waf مثل
بدونه. مرة واحدة NS-3 تم بناءه، حاول تشغيل مجموعة الاختبار التالية:

$ ./test.py -s ns3-tcp-interoperability

إذا تم بناء NSC بنجاح، فيجب أن يظهر الاختبار التالي في النتائج:

تمرير TestSuite ns3-tcp-قابلية التشغيل المتداخل

وهذا يؤكد أن NSC جاهز للاستخدام.

الأستعمال
هناك بعض الأمثلة على الملفات. يحاول:

$ ./waf --run tcp-nsc-zoo
$ ./waf --تشغيل tcp-nsc-lfn

هذه الأمثلة سوف تودع بعض .pcap الملفات الموجودة في الدليل الخاص بك، والتي يمكن فحصها بواسطة
tcpdump أو wireshark.

لنلقِ نظرة على ملف أمثلة/tcp/tcp-nsc-zoo.cc ملف لبعض الاستخدام النموذجي. كيف ذلك؟
تختلف عن استخدام الأصلي NS-3 برنامج التعاون الفني؟ يوجد خط تكوين رئيسي واحد عند استخدام NSC
و NS-3 واجهة API المساعدة التي يجب تعيينها:

InternetStackHelper internetStack;

internetStack.SetNscStack("liblinux2.6.26.so");
// يؤدي هذا إلى تبديل العقدتين 0 و1 إلى مكدس NSC Linux 2.6.26.
إنترنت ستاك.تثبيت (ن.احصل على(0)) ؛
إنترنت ستاك.تثبيت (ن.احصل على(1)) ؛

الخط الرئيسي هو SetNscStack. هذا يخبر مساعد InternetStack بالتجميع
مثيلات NSC TCP بدلاً من الأصلية NS-3 TCP إلى العقد المتبقية. انه مهم
أن يتم استدعاء هذه الوظيفة قبل استدعاء ثَبَّتَ() الوظيفة، كما هو موضح أعلاه.

ما هي الأكوام المتاحة للاستخدام؟ في الوقت الحاضر، تم التركيز على Linux 2.6.18 وLinux
2.6.26 مداخن ل NS-3. لمعرفة أي الأكوام تم بناؤها، يمكن تنفيذ البحث التالي
الأمر في NS-3 دليل المستوى الأعلى:

$ ابحث عن 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، مثل
الموصوفة أعلاه والموثقة في Doxygen

بالإضافة إلى ذلك، يقوم NSC TCP بتصدير الكثير من متغيرات التكوين إلى ملف NS-3 سمات
النظام، عبر أ sysctl-مثل الواجهة. في ال أمثلة/tcp/tcp-nsc-zoo على سبيل المثال، يمكنك أن ترى
التكوين التالي:

// يؤدي هذا إلى تعطيل TCP SACK وwscale والطوابع الزمنية على العقدة 1 (السمات
تمثل قيم sysctl).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
قيمة السلسلة ("0"))؛
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
قيمة السلسلة ("0"))؛
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
قيمة السلسلة ("0"))؛

متغيرات التكوين الإضافية هذه غير متاحة للمواطن الأصلي NS-3 برنامج التعاون الفني.

لاحظ أيضًا أن القيم الافتراضية لسمات TCP موجودة NS-3 قد يختلف TCP عن NSC TCP
تطبيق. على وجه التحديد في NS-3:

1. MSS الافتراضي لـ TCP هو 536

2. عدد الاستلام المؤجل لـ TCP هو 2

لذلك عند إجراء المقارنات بين النتائج التي تم الحصول عليها باستخدام NSC و NS-3 برنامج التعاون الفني، والرعاية
يجب اتخاذها لضمان تعيين هذه القيم بشكل مناسب. يرى
/examples/tcp/tcp-nsc-comparision.cc على سبيل المثال.

مجلس الأمن القومي API
يصف هذا القسم الفرعي واجهة برمجة التطبيقات التي يقدمها NSC NS-3 أو أي جهاز محاكاة آخر. مجلس الأمن القومي
يوفر واجهة برمجة التطبيقات (API) الخاصة به في شكل عدد من الفئات التي تم تعريفها فيها
سيم/sim_interface.h في دليل NSC.

· INetStack يحتوي INetStack على عمليات "المستوى المنخفض" لشبكة نظام التشغيل
المكدس، على سبيل المثال، وظائف الإدخال والإخراج من وإلى مكدس الشبكة (فكر في هذا باعتباره
"واجهة برنامج تشغيل الشبكة". هناك أيضًا وظائف لإنشاء مآخذ توصيل TCP أو UDP جديدة.

· ISendCallback يتم استدعاء هذا بواسطة NSC عندما يجب إرسال حزمة إلى الشبكة.
يجب أن يستخدم هذا المحاكي رد الاتصال هذا لإعادة حقن الحزمة في جهاز المحاكاة
يمكن تسليم/توجيه البيانات الفعلية إلى وجهتها، حيث ستكون في النهاية
تم تسليمها إلى تلقي () (وفي النهاية العودة إلى مثيل NSC للمستقبلات عبر
INetStack->if_receive() .

· INetStreamSocket هذا هو الهيكل الذي يحدد نقطة نهاية اتصال معينة (ملف
واصف). ويحتوي على طرق للعمل على نقطة النهاية هذه، على سبيل المثال، الاتصال، قطع الاتصال،
قبول، الاستماع، send_data/read_data، ...

· IInterruptCallback يحتوي هذا على رد اتصال التنبيه، الذي يستدعيه NSC كلما
يحدث شيء مثير للاهتمام. فكر في Wakeup() كبديل للتشغيل
وظيفة تنبيه الأنظمة: عندما يقوم نظام التشغيل بتنبيه عملية ما
كان ينتظر اكتمال العملية (على سبيل المثال، مصافحة TCP أثناء
Connect ())، يستدعي NSC رد الاتصال Wakeup () للسماح للمحاكي بالتحقق من الحالة
التغييرات في نقاط النهاية اتصالها.

NS-3 التنفيذ
تشير NS-3 يستخدم التنفيذ واجهة NSC API المذكورة أعلاه، ويتم تنفيذه على النحو التالي.

الأجزاء الثلاثة الرئيسية هي:

· ns3::NscTcpL4Protocol: فئة فرعية من Ipv4L4Protocol (وفئتين من NSC: ISendCallback
و IInterruptCallback)

· 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 المختلفة، لا يتم تضمين رأس NSC IP. بدلا من ذلك، برنامج التعاون الفني
يتم وضع الرأس والحمولة الفعلية في Ptr ، بعد ذلك تكون الحزمة
يتم تمريرها إلى الطبقة 3 لإرسال الحزمة (لا حاجة لمزيد من المعالجة الخاصة
في مسار رمز الإرسال).

يدعو هذا الفصل ns3::NscTcpSocketImpl كلاهما من رد الاتصال NSC Wakeup() ومن
مسار الاستلام (للتأكد من جدولة إرسال البيانات الموجودة في قائمة الانتظار).

src/internet/model/nsc-tcp-socket-impl ينفذ واجهة مقبس NSC. كل مثيل
لديه nscTcpSocket الخاص به. سيتم تسليم البيانات المرسلة () إلى مكدس NSC عبر
m_nscTcpSocket->send_data(). (وليس nsc-tcp-l4، وهذا هو الفرق الرئيسي مقارنة
إلى NS-3 بروتوكول التعاون الفني). يقوم الفصل أيضًا بوضع البيانات في قائمة الانتظار وهي Send () قبل البيانات الأساسية
لقد دخل الواصف في حالة تأسيس. يتم استدعاء هذه الفئة من الملف nsc-tcp-l4
فئة، عندما يتم استدعاء رد الاتصال nsc-tcp-l4 Wakeup() بواسطة NSC. NSC-TCP-Socket-impl بعد ذلك
التحقق من حالة الاتصال الحالية (SYN_SENT، ESTABLISHED، LISTEN...) والجداول الزمنية
عمليات الاسترجاعات المناسبة حسب الحاجة، على سبيل المثال، سيقوم مقبس LISTEN بجدولة القبول لمعرفة ما إذا كان هناك جديد
يجب قبول الاتصال، ويقوم المقبس المُنشأ بجدولة أي بيانات معلقة للكتابة،
جدولة رد اتصال للقراءة، وما إلى ذلك.

نلاحظ أن ns3::NscTcpSocketImpl لا يتفاعل مع NSC-TCP مباشرة: بدلاً من ذلك، البيانات
تمت إعادة التوجيه إلى NSC. يستدعي nsc-tcp مآخذ nsc-tcp الخاصة بالعقدة عندما يكون رد اتصال التنبيه الخاص بها
تم استدعاؤه بواسطة NSC.

القيود
· يعمل NSC فقط على العقد ذات الواجهة الواحدة. محاولة تشغيله على عقدة متعددة الواجهات
سوف يسبب خطأ في البرنامج.

· Cygwin وOS X PPC غير مدعومين؛ OS X Intel غير مدعوم ولكنه قد يعمل

· لا يتم دعم مجموعات NSC التي لا تعمل بنظام التشغيل Linux NS-3

· ليست كل عمليات الاسترجاعات الخاصة بمقبس API مدعومة

لمزيد من المعلومات، راجع ويكي صفحة.

كوديل طابور التنفيذ in NS-3
يصف هذا الفصل تنفيذ قائمة انتظار CoDel ([Nic12]، [Nic14]) في NS-3.

تم تطويره بواسطة كاثلين نيكولز وفان جاكوبسون كحل للانتفاخ المخزن المؤقت [Buf14]
مشكلة، CoDel (إدارة التأخير المتحكم فيه) هو نظام انتظار يستخدم الحزمة
وقت الإقامة (الوقت الموجود في قائمة الانتظار) لاتخاذ قرارات بشأن إسقاط الحزم.

الموديل الوصف
الكود المصدري لنموذج CoDel موجود في الدليل src/الإنترنت/نموذج
يتكون من ملفين codel-queue.h codel-queue.cc تحديد فئة CoDelQueue و
فئة المساعد CoDelTimestampTag. تم نقل الرمز إلى NS-3 بقلم أندرو ماكجريجور بناءً على
تم تنفيذ كود نواة Linux بواسطة Dave Täht و Eric Dumazet.

· فصل CoDelQueue: تطبق هذه الفئة خوارزمية CoDel الرئيسية:

· CoDelQueue::DoEnqueue (): يقوم هذا الروتين بوضع علامة على حزمة بالوقت الحالي من قبل
دفعه إلى قائمة الانتظار. يتم استخدام علامة الطابع الزمني بواسطة CoDelQueue::DoDequeue() إلى
حساب وقت إقامة الحزمة. إذا كانت قائمة الانتظار ممتلئة عند وصول الحزمة، فهذا
سيقوم الروتين بإسقاط الحزمة وتسجيل عدد القطرات بسبب تجاوز قائمة الانتظار،
الذي يتم تخزينه في m_dropOverLimit.

· CoDelQueue::ShouldDrop (): هذا الروتين CoDelQueue::DoDequeue()الروتين المساعد
الذي يحدد ما إذا كان ينبغي إسقاط الحزمة أم لا بناءً على وقت إقامتها.
إذا تجاوز وقت الإقامة m_target ويبقى فوق بشكل مستمر لمدة على الأقل
m_interval، يعود الروتين صحيح مما يشير إلى أنه من المقبول إسقاط الحزمة.
وإلا فإنه يعود زائف.

· CoDelQueue::DoDequeue (): يقوم هذا الروتين بتنفيذ عملية إسقاط الحزمة الفعلية بناءً على
CoDelQueue::ShouldDrop ()القيمة المرجعة وجدولة الانخفاض التالي.

· فصل CoDelTimestampTag: تقوم هذه الفئة بتنفيذ علامات الطابع الزمني للحزمة. هذا
يتم استخدام العلامة لحساب وقت إقامة الحزمة (الفرق بين وقت إقامة الحزمة
يتم وضع الحزمة في قائمة الانتظار والوقت الذي يتم فيه دفعها إلى قائمة الانتظار).

هناك فرعين ل CoDelQueue::DoDequeue ():

1. إذا كانت قائمة الانتظار حاليًا في حالة إسقاط، فهذا يعني أن وقت الإقامة قد أصبح كذلك
بقي فوق m_target لأكثر من m_interval، يحدد الروتين ما إذا كان من المناسب القيام بذلك
اترك حالة الهبوط أو حان وقت الهبوط التالي. متى CoDelQueue::ShouldDrop ()
عائدات زائف، يمكن لقائمة الانتظار الخروج من حالة الإسقاط (set m_dropping إلى زائف).
وبخلاف ذلك، تقوم قائمة الانتظار باستمرار بإسقاط الحزم وتحديث وقت الإسقاط التالي
(m_dropNext) حتى يتم استيفاء أحد الشروط التالية:

1. قائمة الانتظار فارغة، وعندها تترك قائمة الانتظار حالة الإسقاط وتخرج
CoDelQueue::ShouldDrop () نمط؛

2. CoDelQueue::ShouldDrop () عائدات زائف (بمعنى أن وقت الإقامة يذهب أدناه
m_target) حيث تترك قائمة الانتظار حالة الإسقاط؛

3. لم يحن الوقت بعد للإسقاط التالي (m_dropNext أقل من الوقت الحالي) عليها
والتي تنتظرها قائمة الانتظار حتى قائمة انتظار الحزمة التالية للتحقق من الحالة مرة أخرى.

2. إذا لم تكن قائمة الانتظار في حالة الإسقاط، يدخل الروتين في حالة الإسقاط و
قم بإسقاط الحزمة الأولى إذا CoDelQueue::ShouldDrop () عائدات صحيح (يعني الإقامة
لقد ذهب الوقت أعلاه m_target على الاقل m_interval لأول مرة أو أنها ذهبت
أعلاه مرة أخرى بعد أن تترك قائمة الانتظار حالة الإسقاط).

مراجع حسابات
[نيك12]

K. نيكولز وفي. جاكوبسون، التحكم في تأخير قائمة الانتظار، قائمة انتظار ACM، المجلد. 10 العدد 5، مايو 2012.
متاح على الإنترنت في http://queue.acm.org/detail.cfm؟ معرف = 2209336.

[نيك14]

ك. نيكولز وفي. جاكوبسون، مسودة الإنترنت: إدارة قائمة الانتظار النشطة للتأخير المتحكم فيه،
مارس 2014. متاح على الانترنت في
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[بوف14]
Bufferbloat.net. متاح على الانترنت في http://www.bufferbloat.net/.

السمات
تتضمن السمات الرئيسية التي تحملها فئة CoDelQueue ما يلي:

· الوضع: وضع تشغيل CoDel (BYTES أو PACKETS أو ILLEGAL). الوضع الافتراضي هو BYTES.

· ماكسباكيتس: الحد الأقصى لعدد الحزم التي يمكن أن تحتويها قائمة الانتظار. القيمة الافتراضية هي
DEFAULT_CODEL_LIMIT، وهو 1000 حزمة.

· ماكس بايت: الحد الأقصى لعدد البايتات التي يمكن لقائمة الانتظار الاحتفاظ بها. القيمة الافتراضية هي 1500 *
DEFAULT_CODEL_LIMIT، وهو 1500 * 1000 بايت.

· وحدات البايت الصغيرة: معلمة الدقائق الصغيرة لخوارزمية CoDel. القيمة الافتراضية هي 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 -l -r -n -W codel.pcap

المثال الثاني هو codel-vs-droptail-ametric.cc تقع في src/الإنترنت/أمثلة.
يهدف هذا المثال إلى تصميم سيناريو نشر مودم كبل نموذجي. لتشغيل
ملف:

$ ./waf --run "codel-vs-droptail-ametric --PrintHelp"
$ ./waf --run codel-vs-droptail-ametric

الناتج المتوقع من الأوامر السابقة هو ستة ملفات pcap:

· codel-vs-droptail-ametric-CoDel-server-lan.pcap

· codel مقابل droptail غير المتماثلة CoDel جهاز التوجيه wan.pcap

· codel مقابل droptail غير المتماثلة CoDel-router-lan.pcap

· codel-vs-droptail-ametric-CoDel-cmts-wan.pcap

· codel مقابل droptail غير المتماثلة CoDel-cmts-lan.pcap

· codel مقابل droptail غير المتماثلة CoDel المضيف lan.pcap

ملف سمة واحد:

· codel-vs-droptail-ametric-CoDel.attr

خمسة ملفات تتبع ASCII:

· codel-vs-droptail-ametric-CoDel-drop.tr

· codel-vs-droptail-ametric-CoDel-drop-state.tr

· codel-vs-droptail-ametric-CoDel-sojourn.tr

· codel-vs-droptail-ametric-CoDel-length.tr

· codel-vs-droptail-ametric-CoDel-cwnd.tr

التحقق
تم اختبار نموذج CoDel باستخدام CoDelQueueTestSuite الفئة المحددة في
src/internet/test/codel-queue-test-suite.cc. يتضمن الجناح 5 حالات اختبار:

· الاختبار 1: يقوم الاختبار الأول بفحص قائمة الانتظار/إلغاء القائمة بدون أي قطرات والتأكد من ذلك
يمكن تعيين سمات CoDel بشكل صحيح.

· الاختبار 2: يقوم الاختبار الثاني بفحص قائمة الانتظار مع السقوط بسبب تجاوز قائمة الانتظار.

· الاختبار 3: الاختبار الثالث يفحص حساب NewtonStep() مقابل المنفذ الصريح لنظام التشغيل Linux
التنفيذ

· الاختبار 4: الاختبار الرابع يفحص ControlLaw() مقابل منفذ Linux الصريح
التنفيذ

· الاختبار 5: يقوم الاختبار الخامس بفحص قائمة الانتظار/إلغاء قائمة الانتظار مع القطرات وفقًا لـ CoDel
خوارزمية

يمكن تشغيل مجموعة الاختبار باستخدام الأوامر التالية:

تكوين $ ./waf - أمثلة قابلة للتمكين - اختبارات التمكين
$ ./waf بناء
$ ./test.py -s codel-queue

or

$ NS_LOG = "CoDelQueue" ./waf --تشغيل "test-runner --suite=codel-queue"
فاصل صفحة

معدل منخفض WIRELESS الشخصية المنطقة NETWORK (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 من نيكولا بالدو هو الأساس للتنفيذ.

يخطط التنفيذ أيضًا للاقتراض من نماذج ns-2 التي طورها Zheng و Lee
فى المستقبل.

واجهات برمجة التطبيقات
تتبع واجهات برمجة التطبيقات (API) بشكل وثيق المعيار، الذي تم تكييفه مع اصطلاحات التسمية والتعابير ns-3. ال
يتم تنظيم واجهات برمجة التطبيقات حول مفهوم أساسيات الخدمة كما هو موضح في ما يلي
الرقم مقتبس من الشكل 14 من IEEE Std. 802.15.4-2006.
[صورة] أساسيات الخدمة.UNINDENT

يتم تنظيم واجهات برمجة التطبيقات حول أربع خدمات مفاهيمية ونقاط وصول إلى الخدمة (SAP):

· خدمة بيانات MAC (MCPS)

· خدمة إدارة MAC (MLME)

· خدمة بيانات PHY (PD)

· خدمة إدارة PHY (PLME)

بشكل عام، يتم توحيد البدائيات على النحو التالي (على سبيل المثال القسم 7.1.1.1.1 من IEEE
802.15.4-2006)::

طلب بيانات MCPS (
سركأدرمود,
وضع دستأدر,
دستبانيد،
دستأدر,
طول مسدو,
مسدو,
مسدوهاندل,
تكسوبيشنز،
مستوى الأمان،
وضع معرف المفتاح،
مصدر رئيسي,
المؤشر الرئيسي
)

يعين هذا فئات وطرق ns-3 مثل::

بناء McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;

};

باطل
LrWpanMac::McpsDataRequest (معلمات McpsDataRequestParameters)
{

}

ماك
يطبق MAC حاليًا متغير CSMA/CA غير المحدد بدون إشارات. حالياً
لا يوجد دعم للمنسقين وواجهات برمجة التطبيقات ذات الصلة.

يشبه MAC المطبق NullMAC من Contiki، أي MAC بدون ميزات السكون.
من المفترض أن يكون الراديو نشطًا دائمًا (استقبالًا أو إرسالًا)، أو مغلقًا تمامًا
تحت. لا يتم تعطيل استقبال الإطار أثناء إجراء التقييم القطري المشترك (CCA).

واجهة برمجة التطبيقات الرئيسية المدعومة هي واجهة برمجة تطبيقات نقل البيانات (McpsDataRequest/Indication/Confirm).
CSMA/CA وفقًا لـ Stc 802.15.4-2006، القسم 7.5.1.4 مدعوم. استقبال الإطار و
الرفض وفقًا لـ Std 802.15.4-2006، القسم 7.5.6.2 مدعوم، بما في ذلك
اعترافات. تم تنفيذ المعالجة القصيرة فقط بالكامل. مصادر التتبع المختلفة هي
مدعومة، ويمكن توصيل المصادر النزرة بالأحواض.

فيز
تتكون مكونات الطبقة المادية من نموذج Phy ونموذج معدل الخطأ والخسارة
نموذج. يقوم نموذج معدل الخطأ حاليًا بنمذجة معدل الخطأ لـ IEEE 802.15.4 2.4 جيجا هرتز
قناة AWGN لـ OQPSK؛ يمكن العثور على وصف النموذج في IEEE Std 802.15.4-2006،
القسم هـ.4.1.7. يعتمد نموذج Phy على SpectrumPhy ويتبع المواصفات
الموصوفة في القسم 6 من IEEE Std 802.15.4-2006. إنه يصمم مواصفات خدمة PHY،
تنسيقات PPDU وثوابت PHY وسمات PIB. وهو يدعم حاليًا الإرسال فقط
قناع الكثافة الطيفية للقدرة المحدد في التردد 2.4 GHz لكل قسم 6.5.3.1. قوة الضجيج
تفترض الكثافة ضوضاء حرارية موزعة بشكل موحد عبر نطاقات التردد. خسارة
يمكن للنموذج الاستفادة الكاملة من جميع نماذج الخسارة البسيطة (غير الطيفية) الموجودة. نموذج فاي
يستخدم نموذج قناة الطيف الواحد الحالي. الطبقة المادية على غرار الحزمة
المستوى، أي أنه لم يتم إجراء اكتشاف للديباجة/SFD. سيتم بدء استقبال الحزمة مع
البتة الأولى من المقدمة (التي لم يتم تصميمها)، إذا كانت نسبة الإشارة إلى الضوضاء (SNR) أكبر من -5 ديسيبل، انظر
IEEE Std 802.15.4-2006، الملحق E، الشكل E.2. سينتهي استلام الحزمة بعد ذلك
تم نقل الحزمة بالكامل. سيتم إضافة الحزم الأخرى التي تصل أثناء الاستقبال
للتداخل/الضوضاء.

يتم حاليًا ضبط حساسية جهاز الاستقبال على قيمة ثابتة تبلغ -106.58 ديسيبل ميلي واط. هذا
يتوافق مع معدل خطأ في الرزم قدره 1٪ لحزم مرجعية مكونة من 20 بايت لهذه الإشارة
الطاقة، وفقًا لمعيار IEEE Std 802.15.4-2006، القسم 6.1.7. في المستقبل سوف نقدم
دعم لتغيير الحساسية لقيم مختلفة.
[صورة] معدل خطأ الحزمة مقابل قوة الإشارة.UNINDENT

NetDevice
على الرغم من أنه من المتوقع أن تقوم ملفات تعريف التكنولوجيا الأخرى (مثل 6LoWPAN وZigBee) بذلك
كتابة فئات NetDevice الخاصة بهم، ويتم توفير LrWpanNetDevice الأساسي، والذي يتم تغليفه
العمليات الشائعة لإنشاء جهاز LrWpan عام وربط الأشياء معًا.

مجال القيود
ستحتوي الإصدارات المستقبلية من هذا المستند على نموذج أولي لـ PICS مشابه للملحق د من
إيي 802.15.4-2006. ينصب التركيز الحالي على الوضع غير المحدد لتشغيل 802.15.4
للاستخدام في Zigbee، ويقتصر النطاق على تمكين وضع واحد (CSMA/CA) مع الأساسي
قدرات نقل البيانات. الارتباط مع منسقي PAN ليس مدعومًا بعد
استخدام العنونة الموسعة. تم تصميم التداخل على أنه AWGN ولكن هذا ليس كذلك حاليًا
تم اختباره بدقة.

قائمة انتظار NetDevice Tx ليست محدودة، أي لا يتم إسقاط الحزم أبدًا بسبب قائمة الانتظار
تصبح ممتلئة. وقد يتم إسقاطها بسبب عمليات إعادة الإرسال المفرطة أو الوصول إلى القناة
بالفشل.

مراجع حسابات
· مواصفات التحكم في الوصول إلى الوسائط اللاسلكية (MAC) والطبقة المادية (PHY).
شبكات المناطق الشخصية اللاسلكية ذات المعدل المنخفض (WPANs)، جمعية 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
بصورة مماثلة. ويتجلى استخدام المساعد في أمثلة/lr-wpan-data.cc. لأسكي
التتبع، يتم ربط آثار الإرسال والاستقبال في طبقة Mac.

نموذج خسارة الانتشار الافتراضي المضاف إلى القناة، عند استخدام هذا المساعد، هو
LogDistancePropagationLossModel مع المعلمات الافتراضية.

أمثلة
تمت كتابة الأمثلة التالية، والتي يمكن العثور عليها في سرك/lr-wpan/أمثلة/:

· lr-wpan-data.cc: مثال بسيط يوضح نقل البيانات من طرف إلى طرف.

· lr-wpan-خطأ-المسافة-plot.cc: مثال لرسم الاختلافات في نجاح الحزمة
النسبة كدالة للمسافة.

· lr-wpan-خطأ-نموذج-plot.cc: مثال لاختبار الفيزياء.

· lr-wpan-packet-print.cc: مثال لطباعة حقول رأس MAC.

· lr-wpan-phy-test.cc: مثال لاختبار الفيزياء.

على وجه الخصوص، تتيح الوحدة سيناريو مبسط للغاية لنقل البيانات من طرف إلى طرف،
تنفذ في lr-wpan-data.cc. يوضح الشكل تسلسل الأحداث التي تم تشغيلها
عندما يتلقى MAC طلب DataRequest من الطبقة العليا. فإنه يستدعي قناة واضحة
التقييم (CCA) من PHY، وإذا نجح، يرسل الإطار إلى PHY حيث يتم
يتم إرساله عبر القناة وينتج عنه مؤشر بيانات على العقدة النظيرة.
[صورة] مثال بيانات لنقل بيانات LR-WPAN البسيط من طرف إلى طرف.UNINDENT

المثال lr-wpan-خطأ-المسافة-plot.cc يرسم نسبة نجاح الحزمة (PSR) كـ a
دالة المسافة، باستخدام نموذج فقدان الانتشار LogDistance الافتراضي و
نموذج الخطأ 802.15.4. القناة (الافتراضي 11) وحجم الحزمة (الافتراضي 20 بايت) و
يمكن أن تختلف طاقة الإرسال (الافتراضي 0 ديسيبل ميلي واط) بواسطة وسيطات سطر الأوامر. البرنامج
إخراج ملف اسمه 802.15.4-psr-distance.plt. يؤدي تحميل هذا الملف إلى gnuplot إلى الحصول على ملف
ملف 802.15.4-psr-distance.epsوالتي يمكن تحويلها إلى pdf أو صيغ أخرى. ال
يظهر الإخراج الافتراضي أدناه.
[صورة] الإخراج الافتراضي للبرنامج lr-wpan-خطأ-المسافة-plot.cc.إلغاء المسافة البادئة

اختبارات
تمت كتابة الاختبارات التالية، والتي يمكن العثور عليها في سرك/lr-wpan/الاختبارات/:

· lr-wpan-ack-test.cc: تأكد من استخدام الإقرارات وإصدارها في
طلب صحيح.

· lr-wpan-collision-test.cc: اختبار الاستقبال الصحيح للحزم مع التداخل و
الاصطدامات.

· lr-wpan-خطأ-نموذج-test.cc: تأكد من أن نموذج الخطأ يعطي قيمًا يمكن التنبؤ بها.

· lr-wpan-packet-test.cc: اختبر فئات رأس/مقطورة 802.15.4 MAC

· lr-wpan-pd-plme-sap-test.cc: اختبار PLME وPD SAP وفقًا لمعايير IEEE 802.15.4

· lr-wpan-الطيف-قيمة-مساعد-test.cc: اختبار أن التحويل بين السلطة
(يتم التعبير عنها بكمية عددية) والطاقة الطيفية، وبالعودة مرة أخرى، تقع ضمن 25%
التسامح عبر مجموعة من القنوات الممكنة وقوى الإدخال.

التحقق
لم يتم التحقق من صحة النموذج مقابل الأجهزة الحقيقية. لقد كان نموذج الخطأ
تم التحقق من صحتها مقابل البيانات الواردة في IEEE Std 802.15.4-2006، القسم E.4.1.7 (الشكل E.2). ال
تم التحقق من صحة سلوك MAC (التراجع عن CSMA) يدويًا مقابل السلوك المتوقع. ال
الرسم أدناه هو مثال للتحقق من صحة نموذج الخطأ ويمكن إعادة إنتاجه عن طريق التشغيل
lr-wpan-خطأ-نموذج-plot.cc:
[صورة] الإخراج الافتراضي للبرنامج lr-wpan-خطأ-نموذج-plot.cc.إلغاء المسافة البادئة

LTE MODULE

تصميم توثيق
نظرة عامة
يوضح الشكل نظرة عامة على نموذج محاكاة LTE-EPC نظرة عامة of هيه
LTE-EPC محاكاة نموذج. هناك مكونان رئيسيان:

· طراز LTE. يتضمن هذا الطراز مجموعة بروتوكولات راديو LTE (RRC، PDCP، RLC، MAC،
فاي). تقع هذه الكيانات بالكامل داخل UE وعقد eNB.

· نموذج EPC. يتضمن هذا النموذج واجهات الشبكة الأساسية والبروتوكولات والكيانات.
توجد هذه الكيانات والبروتوكولات ضمن عقد SGW وPGW وMME وجزئيًا
داخل العقد eNB.
[صورة] نظرة عامة على نموذج محاكاة LTE-EPC.UNINDENT

تصميم المعايير
LTE الموديل
تم تصميم نموذج LTE لدعم تقييم الجوانب التالية لـ LTE
الأنظمة:

· إدارة موارد الراديو

· جودة الخدمة علماً بجدولة الحزم

· تنسيق التدخل بين الخلايا

· الوصول إلى الطيف الديناميكي

من أجل تصميم أنظمة LTE بمستوى من التفاصيل يكفي للسماح بالتصحيح
تقييم الجوانب المذكورة أعلاه، تم المتطلبات التالية
يعتبر:

1. على المستوى الراديوي، ينبغي أن تكون دقة النموذج على الأقل مماثلة لتلك الموجودة في النموذج
كتلة الموارد (RB). في الواقع، هذه هي الوحدة الأساسية المستخدمة للموارد
توزيع. وبدون هذا المستوى الأدنى من التفاصيل، لا يمكن وضع نموذج
جدولة الحزم بدقة والتداخل بين الخلايا. والسبب هو أنه منذ ذلك الحين
تتم جدولة الحزم على أساس كل RB، وقد يقوم eNB بالإرسال على مجموعة فرعية فقط
من جميع المكاتب الإقليمية المتاحة، وبالتالي تتداخل مع المكاتب الإقليمية الأخرى فقط على تلك المكاتب الإقليمية حيث
إنه يرسل. لاحظ أن هذا الشرط يستبعد اعتماد النظام
نهج محاكاة المستوى، الذي يقيم تخصيص الموارد فقط على المستوى
تفصيل مؤسسة الدعوة/الحامل.

2. يجب أن يصل حجم جهاز المحاكاة إلى عشرات من وحدات eNB ومئات من معدات المستخدم (UEs).
يستبعد هذا استخدام جهاز محاكاة مستوى الارتباط، أي جهاز محاكاة يكون راديوه
تم تصميم الواجهة بتفاصيل تصل إلى مستوى الرمز. هذا بسبب
لديك نموذج مستوى الرمز، فمن الضروري تنفيذ جميع إشارات طبقة PHY
المعالجة، التي يحد تعقيدها الحسابي الضخم من المحاكاة بشدة. في الحقيقة،
عادةً ما تقتصر أجهزة المحاكاة على مستوى الارتباط على وحدة eNB واحدة وواحدة أو عدد قليل من وحدات المستعمل.

3. يجب أن يكون من الممكن ضمن المحاكاة تكوين خلايا مختلفة بحيث
يستخدمون ترددات حاملة مختلفة وعروض نطاق النظام. عرض النطاق الترددي المستخدم من قبل
وينبغي السماح للخلايا المختلفة بالتداخل، من أجل دعم الطيف الديناميكي
حلول الترخيص مثل تلك الموضحة في [Ofcom2600MHz] و[RealWireless].
ويجب أن يتعامل حساب التداخل مع هذه الحالة بشكل مناسب.

4. أن نكون أكثر تمثيلاً لمعيار LTE، وأن نكون أقرب ما يكون إليه
بالنسبة للتطبيقات في العالم الحقيقي، يجب أن يدعم جهاز المحاكاة واجهة برمجة التطبيقات لجدولة MAC
تم نشره بواسطة FemtoForum [FFAPI]. ومن المتوقع أن يتم استخدام هذه الواجهة من قبل
الشركات المصنعة femtocell لتنفيذ الجدولة والموارد الراديوية
خوارزميات الإدارة (RRM). من خلال تقديم الدعم لهذه الواجهة في
محاكاة، نحن نتيح لبائعي ومشغلي معدات LTE الاختبار في
بيئة محاكاة هي بالضبط نفس الخوارزميات التي سيتم نشرها في الواقع
نظام.

5. يجب أن يحتوي نموذج محاكاة LTE على تطبيق خاص به لواجهة برمجة التطبيقات (API) المحددة في
[فابي]. لا يتوافق الثنائي ولا بنية البيانات مع البائع المحدد
من المتوقع تنفيذ نفس الواجهة؛ وبالتالي، طبقة التوافق
يجب أن يتم التدخل عند استخدام برنامج جدولة MAC الخاص بالبائع مع
محاكاة. يعد هذا المطلب ضروريًا للسماح للمحاكي بأن يكون مستقلاً
من التطبيقات الخاصة بالبائع لمواصفات الواجهة هذه. لاحظنا ذلك
[FFAPI] هي مواصفات منطقية فقط، ويتم تنفيذها (على سبيل المثال، الترجمة
لبعض لغات البرمجة المحددة) يتم تركها للبائعين.

6. سيتم استخدام النموذج لمحاكاة نقل حزم IP بواسطة الجزء العلوي
طبقات. في هذا الصدد، يجب اعتبار أنه في LTE الجدولة و
لا تعمل إدارة موارد الراديو مع حزم IP مباشرة، بل مع RLC
وحدات PDU، والتي يتم الحصول عليها عن طريق تجزئة وتسلسل حزم IP التي يتم إجراؤها بواسطة
كيانات RLC. وبالتالي، ينبغي تصميم هذه الوظائف لطبقة RLC
بدقة.

EPC الموديل
الهدف الرئيسي لنموذج EPC هو توفير وسائل لمحاكاة النهاية إلى النهاية
اتصال IP عبر طراز LTE. وتحقيقا لهذا الهدف، فإنه يدعم الربط البيني
وحدات مستعمل متعددة إلى الإنترنت، عبر شبكة وصول راديوية مكونة من عدة وحدات eNB متصلة بـ
عقدة SGW/PGW واحدة، كما هو موضح في الشكل نظرة عامة of هيه LTE-EPC محاكاة نموذج.

تم إجراء خيارات التصميم التالية لنموذج EPC:

1. نوع شبكة حزم البيانات (PDN) الوحيد المدعوم هو IPv4.

2. يتم تنفيذ الكيانات الوظيفية SGW وPGW ضمن عقدة واحدة، وهي
ومن ثم يشار إليها باسم عقدة SGW/PGW.

3. سيناريوهات التنقل بين SGW ليست ذات أهمية. وبالتالي، SGW/PGW واحد
ستكون العقدة موجودة في جميع سيناريوهات المحاكاة

4. من متطلبات نموذج EPC أنه يمكن استخدامه لمحاكاة النهاية إلى النهاية
أداء التطبيقات الواقعية. وبالتالي، ينبغي أن يكون من الممكن استخدامها مع
نموذج EPC هو أي تطبيق ns-3 عادي يعمل فوق TCP أو UDP.

5. الشرط الآخر هو إمكانية محاكاة طبولوجيا الشبكة مع
وجود وحدات eNB متعددة، وقد يكون بعضها مجهزًا بوصلة توصيل
اتصال مع قدرات محدودة. ومن أجل محاكاة مثل هذه السيناريوهات، يجب على المستخدم
وينبغي وضع نماذج لبروتوكولات مستوى البيانات المستخدمة بين eNBs وSGW/PGW
بدقة.

6. ينبغي أن يكون من الممكن لتجهيز مستعمل واحد أن يستخدم تطبيقات مختلفة ببرامج مختلفة
ملفات تعريف جودة الخدمة. وبالتالي، ينبغي دعم العديد من حاملات EPS لكل تجهيزات مستعمل. هذا
يتضمن التصنيف الضروري لحركة مرور TCP/UDP عبر IP الذي يتم إجراؤه في UE
الوصلة الصاعدة وعلى PGW في الوصلة الهابطة.

7. ينصب تركيز نموذج EPC بشكل أساسي على مستوى بيانات EPC. النمذجة الدقيقة لل
إن مستوى التحكم EPC ليس شرطًا في الوقت الحالي؛ وبالتالي،
يمكن نمذجة تفاعلات مستوى التحكم الضرورية بطريقة مبسطة
الاستفادة من التفاعل المباشر بين كائنات المحاكاة المختلفة عبر
الكائنات المساعدة المقدمة.

8. ينصب تركيز نموذج EPC على محاكاة المستخدمين النشطين في الوضع المتصل بـ ECM.
ومن ثم، فإن جميع الوظائف ذات الصلة فقط بوضع الخمول ECM (على وجه الخصوص،
(تحديث منطقة التتبع والترحيل) لم يتم تصميمها على الإطلاق.

9. يجب أن يسمح النموذج بإمكانية تنفيذ عملية تسليم مستندة إلى X2 بين اثنين
eNBs.

معمار
LTE الموديل
UE هندسة معمارية
يتم تمثيل بنية نموذج مكدس بروتوكول الراديو LTE الخاص بـ UE في
الأرقام LTE راديو بروتوكول كومة هندسة معمارية For هيه UE on هيه البيانات طائرة LTE راديو
بروتوكول كومة هندسة معمارية For هيه UE on هيه مراقبة طائرة والتي تسليط الضوء على التوالي
مستوى البيانات ومستوى التحكم.
[صورة] بنية مكدس بروتوكول الراديو LTE لUE على مستوى البيانات.UNINDENT
[صورة] بنية مكدس بروتوكول الراديو LTE لUE على مستوى التحكم.UNINDENT

وتظهر في الشكل معمارية نموذج الطبقة المادية/القناة لتجهيزات المستعمل فيز
قناة نموذج هندسة معمارية For هيه UE.
[صورة] بنية نموذج PHY والقناة لـ UE.UNINDENT

eNB هندسة معمارية
يتم تمثيل بنية نموذج مكدس بروتوكول الراديو LTE الخاص بـ eNB في
الأرقام LTE راديو بروتوكول كومة هندسة معمارية For هيه eNB on هيه البيانات طائرة LTE راديو
بروتوكول كومة هندسة معمارية For هيه eNB on هيه مراقبة طائرة والتي تسليط الضوء على التوالي
مستوى البيانات ومستوى التحكم.
[صورة] بنية مكدس بروتوكول الراديو LTE لـ eNB على مستوى البيانات.UNINDENT
[صورة] بنية مكدس بروتوكول الراديو LTE لـ eNB على مستوى التحكم.UNINDENT

يتم تمثيل بنية نموذج PHY/channel الخاص بـ eNB في الشكل فيز
قناة نموذج هندسة معمارية For هيه 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 قناة الطيف واجهة المقدمة
بواسطة وحدة الطيف. وفي وقت كتابة هذه السطور، كان هناك تطبيقان لهذه الواجهة
تتوفر: SingleModelSpectrumChannel MultiModelSpectrumChannelو LTE
تتطلب الوحدة استخدام MultiModelSpectrumChannel من أجل العمل بشكل صحيح. هذا
يرجع ذلك إلى الحاجة إلى دعم تكوينات التردد وعرض النطاق الترددي المختلفة. الجميع
نماذج الانتشار التي يدعمها MultiModelSpectrumChannel يمكن استخدامها داخل
وحدة LTE.

استعمل of هيه المباني نموذج مع LTE
نموذج الانتشار الموصى باستخدامه مع وحدة LTE هو النموذج الذي توفره
وحدة المباني، والتي تم تصميمها في الواقع خصيصًا مع تقنية LTE (على الرغم من أنها يمكن أن تكون كذلك).
المستخدمة مع التقنيات اللاسلكية الأخرى أيضًا). يرجى الرجوع إلى وثائق
وحدة المباني للحصول على معلومات عامة عن نموذج الانتشار الذي توفره.

سنسلط الضوء في هذا القسم على بعض الاعتبارات التي تنطبق على وجه التحديد عندما
يتم استخدام وحدة المباني مع وحدة LTE.

سيكون اصطلاح التسمية المستخدم في ما يلي:

· معدات المستخدم: UE

· المحطة الأساسية الكلية: MBS

· محطة قاعدة الخلية الصغيرة (على سبيل المثال، بيكو/فيمتوسيل): SC

تأخذ وحدة LTE بعين الاعتبار FDD فقط، وتقوم بتنفيذ نشر الوصلة الهابطة والصاعدة
بشكل منفصل. ونتيجة لذلك، يتم إجراء حسابات Pathloss التالية

· MBS <-> UE (داخلي وخارجي)

· SC (داخلي وخارجي) <-> UE (داخلي وخارجي)

لا يوفر نموذج LTE حسابات فقدان المسار التالية:

· الاتحاد الأوروبي <-> الاتحاد الأوروبي

· محمد بن سلمان <-> محمد بن سلمان

· محمد بن سلمان <-> SC

· سك <-> سك

لا يعرف نموذج المباني النوع الفعلي للعقدة؛ أي أنه ليس على علم
ما إذا كانت عقدة الإرسال عبارة عن UE أو MBS أو SC. وبدلا من ذلك، فإن نموذج المباني يهتم فقط
حول موضع العقدة: هل هي داخلية أم خارجية، وما هو محورها z
فيما يتعلق بمستوى السطح. ونتيجة لذلك، بالنسبة لعقدة eNB التي يتم وضعها في الهواء الطلق و
وعند الإحداثي z فوق مستوى السطح، ستكون نماذج الانتشار النموذجية لـ MBS
المستخدمة من قبل وحدة المباني. على العكس من ذلك، بالنسبة لـ eNB الذي يتم وضعه في الخارج ولكن أسفله
سيتم استخدام نماذج الانتشار النموذجية لخلايا البيكو والفيمتو على السطح أو في الداخل.

بالنسبة للاتصالات التي تتضمن عقدة داخلية واحدة على الأقل، يجب أن يكون اختراق الجدار المقابل
سيتم حساب الخسائر من خلال نموذج المباني. يغطي هذا حالات الاستخدام التالية:

· محمد بن سلمان <-> UE داخلي

· SC خارجي <-> UE داخلي

· SC داخلي <-> UE داخلي

· SC داخلي <-> UE خارجي

يرجى الرجوع إلى وثائق وحدة المباني للحصول على تفاصيل حول النماذج الفعلية
المستخدمة في كل حالة.

ذبول الموديل
تتضمن وحدة LTE نموذجًا للتلاشي قائمًا على التتبع مشتقًا من النموذج الذي تم تطويره أثناء ذلك
GSoC 2010 [Piro2011]. السمة الرئيسية لهذا النموذج هي حقيقة أن
يعتمد تقييم الخبو أثناء وقت تشغيل المحاكاة على تتبعات محسوبة. هذا هو
تم القيام به للحد من التعقيد الحسابي لجهاز المحاكاة. ومن ناحية أخرى يحتاج
هياكل ضخمة لتخزين الآثار؛ وبالتالي، فإن المفاضلة بين عدد
يجب العثور على المعلمات الممكنة وإشغال الذاكرة. وأهمها هي:

· سرعة المستخدمين: السرعة النسبية بين المستخدمين (تؤثر على تردد الدوبلر الذي فيه
تؤثر المنعطفات على خاصية التباين الزمني للتلاشي)

· عدد الصنابير (والقوة النسبية): عدد المسارات المتعددة التي تم النظر فيها
يؤثر على خاصية التردد للتلاشي.

· دقة الوقت للتتبع: وقت أخذ العينات من التتبع.

· دقة تردد التتبع: عدد القيم في التردد المطلوب تقييمها.

· طول الأثر: كبير بشكل مثالي مثل وقت المحاكاة، ويمكن تقليله عن طريق النوافذ
آلية.

· عدد المستخدمين: عدد الآثار المستقلة التي سيتم استخدامها (من الأفضل أن يكون أثر واحد لكل
مستخدم).

وفيما يتعلق بنموذج انتشار القناة الرياضية، نقترح النموذج الذي قدمه
هيه rayleighchan وظيفة Matlab، لأنها توفر قناة مقبولة بشكل جيد
النمذجة في المجال الزمني والتردد. لمزيد من المعلومات، القارئ هو
تمت الإشارة إليه مع [mathworks].

يوفر جهاز المحاكاة برنامج نصي MATLAB
(src/lte/model/fading-traces/fading-trace-generator.m) لإنشاء آثار بناءً على
التنسيق المستخدم بواسطة جهاز المحاكاة. بالتفصيل، كائن القناة الذي تم إنشاؤه باستخدام rayleighchan
يتم استخدام الوظيفة لتصفية إشارة نبضية منفصلة من أجل الحصول على
استجابة نبض القناة يتم تكرار التصفية لمختلف TTI، وبالتالي العائد
استجابات القناة اللاحقة المرتبطة بالوقت (واحدة لكل TTI). رد القناة هو بعد ذلك
معالجتها مع pwelch وظيفة للحصول على قيم الكثافة الطيفية لقدرتها، والتي
ثم يتم حفظها في ملف بالتنسيق المناسب المتوافق مع نموذج المحاكاة.

نظرًا لأن عدد المتغيرات مرتفع جدًا، فقم بإنشاء آثار مع الأخذ في الاعتبار جميعها
قد ينتج عددًا كبيرًا من الآثار ذات الحجم الضخم. وفي هذا الشأن نظرنا في
باتباع افتراضات المعلمات المستندة إلى ظروف انتشار الخبو 3GPP
(انظر الملحق ب.2 من [TS36104]):

· سرعة المستخدمين: عادة ما يتم أخذ عدد قليل من القيم المنفصلة في الاعتبار، على سبيل المثال:

· 0 و3 كيلومتر في الساعة لسيناريوهات المشاة

· 30 و60 كيلومتراً في الساعة لسيناريوهات المركبات

· 0 و3 و30 و60 للسيناريوهات الحضرية

· نقرات القناة: يتم عادةً أخذ عدد محدود من مجموعات نقرات القناة في الاعتبار،
على سبيل المثال، تم ذكر ثلاثة نماذج في الملحق ب.2 من [TS36104].

· دقة الوقت: نحتاج إلى قيمة خبو واحدة لكل TTI، أي كل 1 مللي ثانية (لأن هذا هو
التفاصيل في الوقت المناسب لنموذج ns-3 LTE PHY).

· دقة التردد: نحتاج إلى قيمة خبو واحدة لكل RB (وهو التردد
تفاصيل نموذج الطيف المستخدم بواسطة طراز ns-3 LTE).

· طول الأثر: يتضمن جهاز المحاكاة آلية النافذة المنفذة
خلال GSoC 2011، والذي يتكون من التقاط نافذة لتتبع كل نافذة
الطول بطريقة عشوائية.

· عملية الخبو لكل مستخدم: يتشارك المستخدمون في نفس أثر الخبو، ولكن لكل مستخدم أ
يتم التقاط نقطة بداية مختلفة في التتبع بشكل عشوائي. تم هذا الاختيار ل
تجنب الحاجة إلى توفير أثر خبو واحد لكل مستخدم.

وفقا للمعلمات التي أخذناها في الاعتبار، فإن الصيغة التالية تعبر بالتفصيل عن
الحجم الإجمالي S_{آثار} لآثار الخبو:

حيث S_{sample} هو الحجم بالبايتات من العينة (على سبيل المثال، 8 في حالة الدقة المزدوجة،
4 في حالة دقة التعويم)، N_{RB} هو عدد RB أو مجموعة RBs التي يجب أخذها في الاعتبار،
T_{trace} هو الطول الإجمالي للتتبع، T_{sample} هو دقة الوقت للتتبع
(1 مللي ثانية)، وN_{scenarios} هو عدد سيناريوهات الخبو المطلوبة (أي،
مجموعات مختلفة من نقرات القنوات وقيم سرعة المستخدم). نحن نقدم آثار
لثلاثة سيناريوهات مختلفة، واحد لكل تكوين صنبور محدد في الملحق ب.3 من
[TS36104]:

· المشاة: بسرعة العقد 3 كم/ساعة.

· مركبات: تبلغ سرعة عقدها 60 كيلومتراً في الساعة.

· حضري: سرعة العقد فيه 3 كم/ساعة.

وبالتالي N_{scenarios} = 3. جميع الآثار لها T_{trace} = 10 s وRB_{NUM} = 100. هذه النتائج
في إجمالي 24 ميغابايت من الآثار.

هوائيات
يجري على أساس SpectrumPhy، يدعم طراز LTE PHY نمذجة الهوائي عبر ns-3
نموذج الهوائي فصل. وبالتالي، يمكن ربط أي نموذج يعتمد على هذه الفئة بأي eNB أو
مثيل UE. على سبيل المثال، استخدام CosineAntennaModel المرتبطة بجهاز eNB
يسمح بتصميم قطاع واحد من محطة قاعدة ماكرو. بشكل افتراضي، نموذج الهوائي المتناحي
يتم استخدامه لكل من eNBs وUEs.

فيز
نظرة عامة
يعتمد نموذج الطبقة المادية المقدم في محاكي LTE هذا على النموذج الموضح في
[Piro2011]، مع التعديلات التالية. يتضمن النموذج الآن الخلية البينية
حساب التداخل ومحاكاة حركة مرور الوصلة الصاعدة، بما في ذلك كلا الرزمتين
نقل وتوليد CQI.

سوبفرامي الهيكلية
ينقسم الإطار الفرعي إلى جزء التحكم والبيانات كما هو موضح في الشكل LTE إطار فرعي
الانقسام..
[صورة] تقسيم الإطار الفرعي LTE..UNINDENT

مع الأخذ في الاعتبار دقة جهاز المحاكاة المعتمد على RB والتحكم والمرجع
وبالتالي يجب تصميم الإشارات مع الأخذ في الاعتبار هذا القيد. بحسب ال
قياسي [TS36211]، يبدأ إطار التحكم في الوصلة الهابطة في بداية كل إطار فرعي
ويستمر ما يصل إلى ثلاثة رموز عبر النطاق الترددي للنظام بأكمله، حيث يكون فعليًا
يتم توفير المدة من خلال قناة مؤشر تنسيق التحكم الفعلي (PCFICH). ال
يتم بعد ذلك تعيين المعلومات المتعلقة بالتخصيص في المورد المتبقي حتى
المدة المحددة بواسطة PCFICH، في ما يسمى بقناة التحكم المادية للوصلة الهابطة
(بدكش). تنقل PDCCH رسالة واحدة تسمى معلومات التحكم في الوصلة الهابطة (DCI)
القادمة من طبقة MAC، حيث يشير المجدول إلى تخصيص الموارد لـ
مستخدم محدد. تم تصميم PCFICH وPDCCH مع إرسال عنصر التحكم
إطار لمدة ثابتة قدرها 3/14 ميلي ثانية تمتد في كامل المتاح
عرض النطاق الترددي، حيث أن المجدول لا يقدر حجم منطقة التحكم. هذا
يعني ذلك أن كتلة نقل واحدة تشكل إطار التحكم بأكمله بإطار ثابت
الطاقة (أي تلك المستخدمة لـ PDSCH) عبر جميع المكاتب الإقليمية المتاحة. وفقا لهذا
الميزة، يمثل هذا الإرسال أيضًا دعمًا قيمًا للإشارة المرجعية
(RS). وهذا يسمح بإجراء تقييم لكل TTI لسيناريو التداخل منذ ذلك الحين
تقوم جميع وحدات eNB بإرسال (في وقت واحد) إطار التحكم عبر كل منها
عروض النطاق الترددي المتاحة. نلاحظ أن النموذج لا يتضمن تعزيز الطاقة منذ ذلك الحين
ولا يعكس أي تحسن في النموذج المطبق لتقدير القناة.

تم تصميم إشارة السبر المرجعية (SRS) بشكل مشابه لإطار التحكم في الوصلة الهابطة.
يتم وضع SRS بشكل دوري في الرمز الأخير للإطار الفرعي في النظام بأكمله
عرض النطاق. تتضمن وحدة RRC بالفعل خوارزمية لتعيين ملف ديناميكيًا
الدورية كدالة للعدد الفعلي لوحدات المستعمل المرتبطة بـ eNB وفقًا لـ
الإجراء الخاص بـ UE (انظر القسم 8.2 من [TS36213]).

ماك إلى قناة تأخير
لنمذجة زمن الوصول لتطبيقات MAC وPHY الحقيقية، يحاكي نموذج PHY أ
تأخير من MAC إلى القناة في مضاعفات TTI (1 مللي ثانية). نقل كل من البيانات والتحكم
يتم تأخير الحزم بهذا المقدار.

CQI ردود الفعل
يتم إنشاء تعليقات CQI وفقًا لما هو محدد في [FFAPI]. في
بالتفصيل، نظرنا في إنشاء CQI للنطاق العريض الدوري (أي قيمة واحدة لـ
حالة القناة التي تعتبر ممثلة لجميع المكاتب الإقليمية المستخدمة) ومؤشرات جودة الجودة الداخلية (على سبيل المثال، أ
مجموعة من القيمة تمثل حالة القناة لكل RB).

يتم الحصول على مؤشر CQI الذي سيتم الإبلاغ عنه عن طريق الحصول أولاً على قياس SINR ثم بعد ذلك
تمرير قياس SINR هذا إلى التعديل التكيفي والترميز الذي سيعينه إلى
مؤشر CQI.

في الوصلة الهابطة، يمكن حساب نسبة SINR المستخدمة لإنشاء تعليقات CQI بطريقتين مختلفتين
طرق:

1. CTRL الطريقة: يتم حساب SINR بدمج قوة الإشارة من المرجع
الإشارات (التي تعادل في المحاكاة القناة PDCCH) والتداخل
الطاقة من PDCCH. يؤدي هذا النهج إلى اعتبار أي eNB مجاور بمثابة
متداخل، بغض النظر عما إذا كان eNB هذا يقوم فعليًا بإجراء أي PDSCH
الإرسال، وبغض النظر عن الطاقة والمربعات الإقليمية المستخدمة للتدخل في نهاية المطاف
عمليات الإرسال PDSCH.

2. خليط الطريقة: يتم حساب SINR بدمج قوة الإشارة من المرجع
الإشارات (التي تعادل في المحاكاة القناة PDCCH) والتداخل
الطاقة من PDSCH. يؤدي هذا النهج إلى اعتبار هؤلاء فقط متدخلين
eNBs المجاورة التي تقوم بنقل البيانات بشكل نشط على PDSCH، وتسمح بذلك
قم بإنشاء مؤشرات جودة الجودة الداخلية التي تمثل كميات مختلفة من التداخل على مختلف
RBs حسب مستوى التداخل الفعلي. في حالة عدم وجود PDSCH
يتم تنفيذ الإرسال بواسطة أي eNB، وتعتبر هذه الطريقة أن التداخل هو
صفر، أي أنه سيتم حساب نسبة الإشارة إلى الضوضاء (SINR) كنسبة الإشارة إلى الضوضاء فقط.

للتبديل بين هذين النهجين لتوليد CQI، LteHelper::UsePdschForCqiGeneration
يحتاج إلى التهيئة: false للنهج الأول وصحيح للنهج الثاني (صحيح هو
القيمة الافتراضية):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration"، BooleanValue (true));

في الوصلة الصاعدة، يتم تنفيذ نوعين من CQIs:

· تعتمد على خدمة الأبحاث الفضائية (SRS)، ويتم إرسالها بشكل دوري من قبل وحدات المستعمل.

· يعتمد على PUSCH، ويحسب من البيانات المرسلة الفعلية.

تشتمل واجهة المجدول على استدعاء نظام السمات UlCqiFilter لإدارة
تصفية مؤشرات الجودة الشاملة (CQIs) حسب طبيعتها، بالتفصيل:

· SRS_UL_CQI لتخزين CQIs المستندة إلى SRS فقط.

· PUSCH_UL_CQI لتخزين CQIs المستندة إلى PUSCH فقط.

· ALL_UL_CQI لتخزين جميع CQIs المستلمة.

تجدر الإشارة إلى أن، ffMacScheduler يوفر فقط الواجهة وهذا أمر مهم
من تنفيذ المجدول الفعلي ليشمل التعليمات البرمجية لإدارة هذه السمات
(راجع القسم المتعلق بالجدولة لمزيد من المعلومات حول هذا الأمر).

تدخل الموديل
يعتمد نموذج PHY على نماذج التداخل الغوسية المعروفة والتي بموجبها
يتم تلخيص قوى الإشارات المتداخلة (في الوحدات الخطية) معًا لتحديدها
قوة التدخل الشاملة

مخطط تسلسل الشكل تسلسل رسم بياني of هيه فيز تدخل حساب
الإجراءات يوضح كيفية معالجة الإشارات المتداخلة لحساب قيمة SINR، وكيفية معالجة إشارة SINR
ثم يتم استخدامه لتوليد ردود فعل CQI.
[صورة] مخطط تسلسلي لإجراءات حساب التداخل PHY.UNINDENT

LTE طيف الموديل
تم وصف استخدام الطيف الراديوي بواسطة eNBs وUEs في LTE في [TS36101]. في ال
محاكاة، يتم تصميم استخدام الطيف الراديوي على النحو التالي. دع f_c ​​يشير إلى LTE المطلق
رقم قناة تردد الراديو، الذي يحدد تردد الموجة الحاملة على 100 كيلو هرتز
النقطية. علاوة على ذلك، دع B هو تكوين النطاق الترددي للإرسال بعدد
كتل الموارد. لكل زوج (f_c,B) مستخدم في المحاكاة نحدد ما يقابله
SpectrumModel باستخدام الوظيفة التي توفرها وحدة sec-spectrum. نموذج باستخدام
إطار الطيف الموصوف في [Baldo2009]. يمكن تكوين f_c وB لكل منهما
تم إنشاء مثيل eNB في المحاكاة؛ وبالتالي، يمكن لكل eNB استخدام نموذج طيف مختلف.
سيستخدم كل UE تلقائيًا نموذج الطيف الخاص بـ eNB المرفق به. باستخدام
MultiModelSpectrumChannel الموصوف في [Baldo2009]، التداخل بين eNBs التي تستخدم
يتم حساب نماذج الطيف المختلفة بشكل صحيح. وهذا يسمح لمحاكاة ديناميكية
سياسات الوصول إلى الطيف، مثل سياسات ترخيص الطيف على سبيل المثال
تمت مناقشته في [Ofcom2600MHz].

البيانات فيز خطأ الموديل
يشتمل جهاز المحاكاة على نموذج خطأ لمستوى البيانات (أي PDSCH وPUSCH) وفقًا لذلك
تقنيات رسم الخرائط القياسية للارتباط بالنظام (LSM). ويتوافق الاختيار مع
منهجية محاكاة النظام القياسية لتكنولوجيا الإرسال الراديوي OFDMA. شكرا ل
LSM نحن قادرون على الحفاظ على مستوى جيد من الدقة وفي نفس الوقت الحد من
زيادة التعقيد الحسابي. يعتمد على رسم خرائط طبقة الارتباط الفردية
الأداء الذي تم الحصول عليه عن طريق محاكيات مستوى الارتباط بالنظام (في حالتنا الشبكة)
أجهزة محاكاة. على وجه الخصوص، يتم استخدام محاكي الطبقة لتوليد الأداء
لارتباط واحد من منظور طبقة PHY، عادةً من حيث معدل خطأ كتلة التعليمات البرمجية
(BLER)، في ظل ظروف ثابتة محددة. يسمح LSM باستخدام هذه المعلمات بشكل أكبر
سيناريوهات معقدة، نموذجية لمحاكاة النظام/الشبكة، حيث يكون لدينا المزيد من الروابط،
التداخل وظواهر انتشار القناة "الملونة" (على سبيل المثال، التردد الانتقائي
بهوت).

وللقيام بذلك، تم استخدام جهاز محاكاة LTE فيينا [ViennaLteSim] لما يتعلق بـ
استخراج أداء طبقة الارتباط وSINR الفعال القائم على المعلومات المتبادلة
(MIESM) كوظيفة رسم خرائط LSM باستخدام جزء من العمل الذي نشرته Signet مؤخرًا
مجموعة جامعة بادوا [PaduaPEM].

ميسم
طريقة LSM المحددة المعتمدة هي الطريقة التي تعتمد على استخدام المعلومات المتبادلة
متري، يشار إليه عادةً باسم المعلومات المتبادلة لكل بتة مشفرة (MIB أو MMIB متى
يعني مضاعفات MIBs المعنية). سيتم تمثيل خيار آخر بواسطة
الإدارة السليمة بيئياً الأسية (EESM) ؛ ومع ذلك، أظهرت الدراسات الحديثة أن MIESM يتفوق على EESM في
شروط الدقة [LozanoCost].
[صورة] مخطط الإجراءات الحسابية MIESM.UNINDENT

تعتمد المعلومات المتبادلة (MI) على رسم خرائط الكوكبة ويمكن أن تكون كذلك
محسوبة على أساس كتلة النقل (TB)، من خلال تقييم MI على الرموز و
الناقل الفرعي. ومع ذلك، قد يكون هذا الأمر معقدًا للغاية بالنسبة لمحاكاة الشبكة. وبالتالي، في لدينا
تم النظر في تنفيذ استجابة قناة مسطحة داخل المكتب الإقليمي؛ وبالتالي فإن
يتم حساب MI الإجمالي للسل بمتوسط ​​MI الذي تم تقييمه لكل RB مستخدم في السل.
ويرد بالتفصيل المخطط المطبق في الشكل ميسم الحسابية الإجراءات
رسم بيانيحيث نرى أن النموذج يبدأ بتقييم قيمة MI لكل RB،
ممثلة في الشكل بعينات SINR. ثم يتم تقييم MI المكافئ لكل
أساس السل عن طريق حساب متوسط ​​قيم MI. وأخيرا، لا بد من اتخاذ خطوة أخرى منذ ذلك الحين
يقوم محاكي مستوى الارتباط بإرجاع أداء الارتباط من حيث معدل خطأ الكتلة
(BLER) في قناة ضوضاء غاسية بيضاء مضافة (AWGN)، حيث تكون الكتل هي الكود
كتل (CBs) مشفرة/فك تشفيرها بشكل مستقل بواسطة جهاز التشفير التوربيني. في هذا الشأن
تم استخدام نظام تجزئة 3GPP القياسي لتقدير حجم CB الفعلي
(الموصوف في القسم 5.1.2 من [TS36212]). يقسم هذا المخطط السل إلى N_{K_-}
كتل بحجم K_- وN_{K+} كتل بحجم K_+. وبالتالي فإن إجمالي السل BLER (TBLER)
يمكن التعبير عنها

حيث CBLER_i هو BLER الخاص بـ CB الذي حصلت عليه وفقًا لمحاكاة مستوى الارتباط
منحنيات CB BLER. ولتقدير CBLER_i، تم تنفيذ تقييم MI
وفقًا للتقريب العددي المحدد في [wimaxEmd]. وعلاوة على ذلك، للحد
نظرًا لتعقيد الحساب، تم تحويل التقريب إلى بحث
الجداول. بالتفصيل، تم استخدام النموذج التراكمي الغوسي لتقريب AWGN
منحنيات BLER بثلاثة معلمات توفر توافقًا وثيقًا مع AWGN القياسي
العروض، في الصيغة:

حيث x هو MI للسل، ويمثل b_{ECR} "مركز الانتقال" وc_{ECR} هو
المتعلقة بـ "عرض الانتقال" للتوزيع التراكمي الغوسي لكل منها
معدل التشفير الفعال (ECR) وهو معدل الإرسال الفعلي وفقًا للقناة
الترميز وMCS. للحد من التعقيد الحسابي للنموذج الذي نظرنا فيه
فقط مجموعة فرعية من ECRs المحتملة في الواقع سيكون لدينا 5076 ECRs محتملة
(أي 27 MCSs و188 أحجام CB). وفي هذا الصدد، سوف نقتصر أحجام CB على البعض
القيم التمثيلية (أي 40، 140، 160، 256، 512، 1024، 2048، 4032، 6144)، بينما ل
سيتم استخدام الآخرين الأسوأ المقارب للحقيقي (على سبيل المثال، CB الأصغر
قيمة الحجم المتاحة فيما يتعلق بالقيمة الحقيقية). يتماشى هذا الاختيار مع النموذجي
أداء رموز توربو، حيث لا يؤثر حجم CB بقوة على BLER.
ومع ذلك، تجدر الإشارة إلى أنه بالنسبة لأحجام CB الأقل من 1000 بت، قد يكون التأثير كذلك
ذات صلة (أي حتى 2 ديسيبل)؛ لذلك، نعتمد فترة أخذ العينات غير المتوازنة هذه
الحصول على مزيد من الدقة حيثما كان ذلك ضروريا. وهذا السلوك تؤكده الأرقام
المقدمة في قسم Annes.

بلير منحنيات
وفي هذا الصدد، قمنا بإعادة استخدام جزء من المنحنيات التي تم الحصول عليها داخل [PaduaPEM]. وفي التفاصيل نحن
قدم تبعية حجم CB إلى منحنيات CB BLER بدعم من المطورين
من [PaduaPEM] وLTE Vienna Simulator. في الواقع، توفر الوحدة التي تم إصدارها
أداء طبقة الارتباط فقط فيما يتعلق بشبكات 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 هيه بلير المنحنيات in هيه NS-3 LTE وحدة
يستخدم النموذج المطبق منحنيات LSM لنموذج خطأ LTE PHY الذي تم مؤخرًا
تم إصداره في مجتمع ns3 بواسطة Signet Group [PaduaPEM] وتم إنشاء الإصدارات الجديدة
لأحجام CB المختلفة. ال LteSpectrumPhy الفصل هو المسؤول عن تقييم TB BLER
وذلك بفضل الأساليب التي تقدمها LteMiErrorModel الطبقة التي تتولى
تقييم TB BLER وفقًا لمتجه SINR المتصور لكل RB وMCS و
الحجم من أجل وضع نموذج مناسب لتجزئة السل في CBs. من أجل الحصول على
ناقل SINR المدرك لحالتين LtePemSinrChunkProcessor (طفل
معالج LteChunk مخصص لتقييم SINR للحصول على أداء الخطأ المادي)
تم ربطها بالوصلة الهابطة UE والوصلة الصاعدة eNB LteSpectrumPhy وحدات لتقييم
توزيع نموذج الخطأ على التوالي لـ PDSCH (جانب UE) وULSCH (جانب eNB).

يمكن تعطيل النموذج للعمل مع قناة خالية من الخسائر عن طريق تعيين تمكين بيم
سمة من LteSpectrumPhy فئة (افتراضيا نشطة). ويمكن القيام بذلك وفقا
إلى إجراء نظام السمات ns3 القياسي، وهو:

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled"، BooleanValue (false));

مراقبة القنوات فيز خطأ الموديل
يشتمل المحاكي على نموذج الخطأ لقنوات التحكم في الوصلة الهابطة (PCFICH وPDCCH)،
أثناء وجودها في الوصلة الصاعدة، يُفترض أنها قناة مثالية خالية من الأخطاء. يعتمد النموذج على
تم تقديم نهج MIESM من قبل للنظر في تأثيرات التردد الانتقائي
القناة نظرًا لأن معظم قنوات التحكم تغطي كامل النطاق الترددي المتوفر.

PCFICH + PDCCH خطأ الموديل
ويعتمد النموذج المعتمد لتوزيع الأخطاء لهذه القنوات على التقييم
دراسة أجريت في RAN4 لـ 3GPP، حيث قام بائعون مختلفون بالتحقيق في
أداء إزالة تشكيل PCFICH بالاشتراك مع PDCCH. هذا بسبب الحقيقة بأن
PCFICH هي القناة المسؤولة عن التواصل مع وحدات المستعمل بالبعد الفعلي لها
وPDCCH (الذي يمتد بين 1 و3 رموز)؛ وبالتالي فإن فك التشفير الصحيح لل
تعتمد DCIs على التفسير الصحيح لكلاهما. في 3GPP هذه المشكلة لها
تم تقييمه لتحسين أداء حافة الخلية [FujitsuWhitePaper]، حيث
يمكن أن يكون التداخل بين الخلايا المجاورة مرتفعًا نسبيًا بسبب تدهور الإشارة. أ
كانت هناك مشكلة مماثلة في سيناريو خلايا الفيمتو، وبشكل عام، في HetNet
السيناريوهات التي تم اكتشاف عنق الزجاجة فيها بشكل رئيسي هي قناة PCFICH [Bharucha2011]،
حيث أنه في حالة نشر العديد من وحدات eNB في نفس منطقة الخدمة، قد تتصادم هذه القناة
في التردد، مما يجعل من المستحيل الكشف الصحيح عن قناة PDCCH أيضًا.

في جهاز المحاكاة، تم تقدير نسبة الإشارة إلى الضوضاء (SINR) المدركة أثناء الاستقبال وفقًا لـ
نموذج MIESM الموضح أعلاه من أجل تقييم توزيع الأخطاء لـ PCFICH و
PDCCH. بالتفصيل، يتم تضمين عينات SINR لجميع المكاتب الإقليمية في تقييم 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
سجل عادي مع متوسط ​​وتباين مختلفين كوظيفة للمخطط الذي تم النظر فيه.
ومع ذلك، فإن التباينات ليست مختلفة تمامًا، فهي تساوي الواحد تقريبًا
لوضع SISO المضمن بالفعل في مكون التظليل الخاص بـ
المباني نموذج فقدان الانتشار، بالتفصيل:

· SISO: = 13.5 و ma = 20 [ديسيبل].

· MIMO-العلموتي: = 17.7 و ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 و ma = 16.6 [ديسيبل].

· MIMO-OSIC-MMSE: = 12.6 و ma = 15.5 [ديسيبل].

· MIMO-ZF: = 10.3 وma = 12.6 [dB].

ولذلك تطبق طبقة PHY نموذج MIMO باعتباره الكسب الذي يدركه جهاز الاستقبال
عند استخدام نظام MIMO فيما يتعلق بالمخطط الذي تم الحصول عليه باستخدام SISO one. ونلاحظ أن هؤلاء
تشير المكاسب إلى حالة لا يوجد فيها ارتباط بين الهوائيات في MIMO
مخطط؛ لذلك لا تقم بنموذج التدهور بسبب ارتباط المسارات.

UE فيز القياسات الموديل
وفقًا لـ [TS36214]، يجب على المستعمل أن يقدم تقريرًا عن مجموعة من قياسات eNBs التي
الجهاز قادر على إدراك: الطاقة المستلمة للإشارة المرجعية (RSRP) و
جودة الإشارة المرجعية المستلمة (RSRQ). الأول هو مقياس للقوة المستلمة
eNB محدد، بينما يتضمن الأخير أيضًا تداخل القناة والضوضاء الحرارية.
ويتعين على تجهيزات المستعمل أن تبلغ عن القياسات بالاشتراك مع هوية الخلية المادية (PCI) للوحدة
خلية. يتم إجراء قياسات RSRP وRSRQ أثناء استقبال RS،
بينما يتم الحصول على PCI باستخدام إشارة المزامنة الأولية (PSS). يتم إرسال PSS
بواسطة eNB كل 5 إطارات فرعية وبالتفصيل في الإطارين الفرعيين 1 و6. في الأنظمة الحقيقية، فقط
تتوفر 504 وحدات PCI متميزة، ومن ثم قد يحدث أن يستخدم اثنان من وحدات eNB القريبة نطاق
نفس PCI؛ ومع ذلك، في جهاز المحاكاة، نقوم بتصميم واجهات PCI باستخدام بيانات تعريف المحاكاة، ونحن نسمح بذلك
ما يصل إلى 65535 PCI متميزة، وبالتالي تجنب تصادمات PCI بشرط أن يكون أقل من 65535
تتم محاكاة eNBs في نفس السيناريو.

وفقًا لـ [TS36133] القسمين 9.1.4 و9.1.7، يتم الإبلاغ عن RSRP بواسطة طبقة PHY بوحدة dBm
بينما RSRQ بالديسيبل. يتم توفير قيم RSRP وRSRQ إلى الطبقات الأعلى من خلال
C-PHY SAP (عن طريق UeMeasurementsParameters البنية) كل 200 مللي ثانية كما هو محدد في
[TS36331]. يتم إجراء تصفية الطبقة الأولى عن طريق حساب متوسط ​​جميع القياسات التي تم جمعها
خلال فتحة النافذة الأخيرة. ويمكن تعديل دورية التقارير للبحث
الأغراض عن طريق LteUePhy::UeMeasurementsFilterPeriod السمة.

يمكن تبسيط صيغ RSRP وRSRQ مع الأخذ في الاعتبار افتراض PHY
طبقة أن القناة مسطحة داخل RB، أرقى مستوى من الدقة. في الواقع، هذا
يعني أن جميع العناصر المتجددة داخل المكتب الإقليمي لها نفس القوة، وبالتالي:

حيث تمثل P(k,m) قدرة إشارة RE m داخل RB k، كما لوحظ
من قبل، ثابت داخل نفس RB ويساوي P(k)، M هو عدد العناصر المتجددة التي تحملها
RS في RB و K هو عدد RBs. تجدر الإشارة إلى أن P(k)، وبشكل عام جميعها
يتم الحصول على الصلاحيات المحددة في هذا القسم في جهاز المحاكاة من PSD الخاص بـ RB
(الذي يقدمه LteInterferencePowerChunkProcessor)، بالتفصيل:

حيث PSD_{RB}(k) هي الكثافة الطيفية لقدرة RB k، و180000 هو عرض النطاق الترددي بالهرتز
من RB و12 هو عدد REs لكل RB في رمز OFDM. وبالمثل، بالنسبة لـ RSSI نحن
لديك

حيث S هو عدد رموز OFDM التي تحمل RS في RB وR هو عدد REs
يحمل RS في رمز OFDM (الذي تم تثبيته على 2) بينما P(k,s,r) وI(k,s,r) وN(k,s,r)
تمثل على التوالي القوة المتصورة لخلية الخدمة وقوة التداخل و
قوة الضوضاء لـ RE r بالرمز s. أما بالنسبة لـ RSRP، فإن القياسات داخل RB هي
دائمًا متساوون فيما بينهم وفقًا لنموذج PHY؛ ولذلك ف(ك، ق، ص) = ف (ك)،
I(k,s,r) = I(k) وN(k,s,r) = N(k)، مما يعني أنه يمكن حساب مؤشر RSSI على النحو التالي:

مع الأخذ في الاعتبار القيود المفروضة على تنفيذ سلسلة استقبال PHY، ومن أجل
الحفاظ على مستوى التعقيد الحسابي منخفضًا، فقط RSRP يمكن الحصول عليه مباشرة
جميع الخلايا. هذا بسبب الحقيقة بأن LteSpectrumPhy تم تصميمه لتقييم
التداخل يتعلق فقط بإشارة خدمة eNB. وهذا يعني أن PHY
تم تحسين الطبقة لإدارة معلومات إشارات الطاقة من خلال خدمة eNB باعتبارها
مرجع. ومع ذلك، يمكن استخراج RSRP وRSRQ للخلية المجاورة بواسطة التيار
المعلومات المتاحة لخلية التقديم j كما هو مفصل فيما يلي:

حيث RSRP_i هو RSRP للخلية المجاورة i، P_i(k) هي القدرة المتصورة عند أي RE
داخل RB k، K هو إجمالي عدد RBs، RSSI_i هو RSSI للخلية المجاورة i
عندما يتم إرفاق UE بالخلية j (والتي، نظرًا لأنها مجموع كل الصلاحيات المستلمة،
يتزامن مع RSSI_j)، I_j(k) هو إجمالي التداخل الذي يتصوره UE في أي RE لـ RB k
عند إرفاقها بالخلية i (التي تم الحصول عليها بواسطة LteInterferencePowerChunkProcessor)، P_j(ك) هو
القدرة المتصورة للخلية j في أي RE من RB k و N هي القدرة الطيفية للضوضاء
الكثافة في أي RE. تعتبر العينة صالحة في حالة تقييم RSRQ
فوق LteUePhy::RsrqUeMeasThreshold السمة.

حرق
يعتمد مخطط HARQ المطبق على حلول التكرار المتزايد (IR) مجتمعة
مع عمليات التوقف والانتظار المتعددة لتمكين التدفق المستمر للبيانات. وفي التفاصيل،
الحل المعتمد هو ناعم الجمع بين هجين IR طويل الإضافية وفرة (أيضا يسمى
IR النوع II)، مما يعني أن عمليات إعادة الإرسال تحتوي فقط على معلومات جديدة
إلى السابقين. تم تنفيذ خوارزمية تخصيص الموارد لـ HARQ
ضمن فئات الجدولة المعنية (على سبيل المثال، RrFfMacScheduler PfFfMacScheduler,
راجع الأقسام المقابلة لها لمزيد من المعلومات)، في حين أن جزء فك التشفير من
تم تنفيذ HARQ في LteSpectrumPhy LteHarqPhy الفصول التي ستكون
مفصل في هذا القسم.

وفقًا للمعيار، تكون عمليات إعادة الإرسال UL متزامنة، وبالتالي فهي كذلك
تخصيص 7 مللي ثانية بعد الإرسال الأصلي. من ناحية أخرى، بالنسبة لـ DL، هم كذلك
غير متزامن وبالتالي يمكن تخصيصه بطريقة أكثر مرونة بدءًا من 7 مللي ثانية و
إنها مسألة تنفيذ جدولة محددة. سلوك عمليات HARQ هو
موضح في الشكل:المرجع:Fig-harq-processes-scheme.

في طبقة MAC، يكون كيان HARQ الموجود في المجدول مسؤولاً عن التحكم
عمليات HARQ الثمانية لإنشاء حزم جديدة وإدارة عمليات إعادة الإرسال لكل من
DL وUL. يقوم المجدول بجمع تعليقات HARQ من طبقات eNB وUE PHY
(على التوالي لاتصال UL وDL) عن طريق أساسيات FF API
SchedUlTriggerReq SchedUlTriggerReq. وفقا لملاحظات HARQ و RLC
حالة المخازن المؤقتة، يقوم المجدول بإنشاء مجموعة من DCIs بما في ذلك عمليات إعادة الإرسال
تلقت كتل 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} احترامًا أقل لواحد من MCSs القياسية. على هذا
بغض النظر عن ذلك، فقد تم تقييم منحنيات عمليات إعادة الإرسال 1 و2 و3 لـ 10 و17.
MCS 0 اعتبرنا فقط إعادة الإرسال الأولى حيث أن معدل الكود المنتج موجود بالفعل
متحفظ للغاية (أي 0.04) ويعيد معدل خطأ قويًا بدرجة كافية للاستقبال
(أي أن انخفاض BLER يتمركز حول -18 ديسيبل). تجدر الإشارة إلى أن،
يُفترض أن حجم إرسال السل الأول يحتوي على جميع بتات المعلومات
تكون مشفرة؛ ولذلك فإن X يساوي حجم أول تيرابايت مرسل من عملية HARQ. ال
يفترض النموذج أن الوجود النهائي لبتات التكافؤ في كلمات التشفير موجود بالفعل
تعتبر في منحنيات مستوى الارتباط. وهذا يعني أنه بمجرد أن يكون الحد الأدنى R_{eff}.
تم التوصل إلى النموذج لا يشمل الكسب الناتج عن انتقال مزيد من التكافؤ
بت.
[صورة] يعالج HARQ السلوك في LTE.UNINDENT

لقد تم تخصيص الجزء من HARQ لإدارة فك تشفير كتل HARQ
نفذت في LteHarqPhy LteSpectrumPhy الطبقات. السابق هو المسؤول
الحفاظ على معلومات HARQ لكل عملية نشطة. والأخير يتفاعل مع
LteMiErrorModel فئة لتقييم صحة الكتل المستلمة والمتضمنة
خوارزمية المراسلة المسؤولة عن التواصل مع كيان HARQ في المجدول
نتيجة فك التشفير. يتم تغليف هذه الرسائل في
dlInfoListElement ل DL و ulInfoListElement لـ UL وإرسالها عبر PUCCH و
PHICH على التوالي مع نموذج مثالي خالٍ من الأخطاء وفقًا للافتراضات الواردة فيه
تطبيق. رسم تخطيطي للتكرار بين مكدس بروتوكول HARQ وLTE
ممثلة في الشكل:المرجع:تين-حرق-العمارة.

وأخيرًا، يكون محرك HARQ نشطًا دائمًا في طبقة MAC وPHY؛ ومع ذلك، في حالة
لا يدعم المجدول HARQ، وسيستمر النظام في العمل مع HARQ
الوظائف الممنوعة (أي، يتم ملء المخازن المؤقتة ولكن لا يتم استخدامها). هذا التنفيذ
توفر الخاصية توافقًا مع الإصدارات السابقة مع برامج الجدولة التي تم تنفيذها قبل HARQ
دمج.
[صورة] التفاعل بين مكدس بروتوكول HARQ وLTE.UNINDENT

ماك
مورد توزيع الموديل
نحن الآن نصف بإيجاز كيفية التعامل مع تخصيص الموارد في LTE، مع توضيح كيفية ذلك
على غرار في جهاز محاكاة. المجدول مسؤول عن إنشاء هياكل محددة
تسمى البيانات مراقبة إشارة (DCI) والتي يتم إرسالها بعد ذلك بواسطة PHY الخاص بـ eNB إلى
وحدات المستعمل المتصلة، لإبلاغها بتخصيص الموارد على كل إطار فرعي
أساس. للقيام بذلك في اتجاه الوصلة الهابطة، يجب على المجدول ملء بعض التفاصيل المحددة
مجالات بنية DCI مع كافة المعلومات مثل: التعديل والتشفير
المخطط (MCS) الذي سيتم استخدامه وحجم كتلة النقل MAC (TB) والصورة النقطية للتخصيص
الذي يحدد المكاتب الإقليمية التي ستحتوي على البيانات المرسلة بواسطة eNB إلى كل مستخدم.

لرسم خرائط الموارد للمكاتب الإقليمية المادية، نعتمد أ مترجم رسم الخرائط النهج (انظر
[Sesia2009]، القسم 9.2.2.1)؛ ومن ثم، في إطار فرعي معين، يتم تخصيص كل منطقة RB دائمًا
نفس المستخدم في كلا الفتحتين. يمكن ترميز الصورة النقطية للتخصيص بتنسيقات مختلفة؛ في
هذا التنفيذ، نظرنا في توزيع النوع 0 المحددة في [TS36213]، وفقًا
التي يتم تجميع المكاتب الإقليمية لها في مجموعات كتل الموارد (RBG) ذات أحجام مختلفة محددة
كوظيفة لتكوين النطاق الترددي للإرسال المستخدم.

بالنسبة لبعض قيم عرض النطاق الترددي، لا تكون جميع المكاتب الإقليمية قابلة للاستخدام، نظرًا لأن حجم المجموعة ليس أ
القاسم المشترك للمجموعة . هذا هو الحال على سبيل المثال عندما يكون عرض النطاق الترددي مساوياً لـ
25 RBs، مما يؤدي إلى حجم RBG قدره 2 RBs، وبالتالي فإن 1 RB لن يؤدي إلى
قابل للعنونة. يختلف تنسيق DCIs في الوصلة الصاعدة، نظرًا لأن المكاتب الإقليمية المجاورة فقط هي التي تستطيع ذلك
يمكن استخدامه بسبب تعديل SC-FDMA. ونتيجة لذلك، يمكن تخصيص جميع المكاتب الإقليمية بواسطة
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 TB واحد مع التشكيل
مخطط الترميز ومعدل التشفير المتوافق مع مؤشر CQI في الجدول 7.2.3-1 من [TS36213]
يمكن تلقيها مع احتمال خطأ أقل من 0.1. في حالة CQIs ذات النطاق العريض، فإن
يتضمن السل المرجعي جميع RBGs المتاحة من أجل الحصول على مرجع يعتمد على
كامل الموارد المتاحة؛ بينما بالنسبة للنطاق الفرعي CQIs، يتم تحديد حجم السل المرجعي على أنه RBGs.

المواصلات والنقل حظر نموذج
تم تبسيط نموذج كتل نقل MAC (TBs) التي يوفرها جهاز المحاكاة باستخدام
فيما يتعلق بمواصفات 3GPP. على وجه الخصوص، فئة خاصة بالمحاكاة
يتم استخدام (PacketBurst) لتجميع وحدات MAC SDU لتحقيق ما يعادل جهاز المحاكاة
من السل، دون تعقيد التنفيذ المقابلة. تعدد الإرسال
يتم تنفيذ قنوات منطقية مختلفة من وإلى طبقة RLC باستخدام حزمة مخصصة
العلامة (LteRadioBearerTag)، التي تؤدي وظيفة تعادل جزئيًا
تلك الخاصة برؤوس MAC المحددة بواسطة 3GPP.

تشير منتدى الفيمتو ماك جدولة السطح البيني
يصف هذا القسم الإصدار المحدد من ns-3 لواجهة جدولة LTE MAC
المواصفات التي نشرها FemtoForum [FFAPI].

قمنا بتنفيذ الإصدار المحدد ns-3 من واجهة جدولة FemtoForum MAC [FFAPI]
كمجموعة من فئات C++ المجردة؛ على وجه الخصوص، تتم ترجمة كل بدائية إلى C++
طريقة فئة معينة. على المدى نفذت هنا يستخدم بنفس المعنى المعتمد
في [FFAPI]، وبالتالي يشير إلى عملية ترجمة الواجهة المنطقية
مواصفات لغة برمجة معينة. يتم تجميع الأوليات في [FFAPI].
في مجموعتين: أساسيات CSCHED، التي تتعامل مع تكوين المجدول، و
الأوليات SCHED، التي تتعامل مع تنفيذ المجدول. علاوة على ذلك، [فابي]
يعرّف الأوليات من نوعين مختلفين: تلك من النوع REQ تنتقل من MAC إلى
ينتقل المجدول وتلك من النوع IND/CNF من المجدول إلى MAC. لترجمة هذه
الخصائص في C++، نحدد الفئات المجردة التالية التي تنفذ الخدمة
نقاط الوصول (SAPs) التي سيتم استخدامها لإصدار الأوليات:

· ال FfMacSchedSapProvider تحدد الفئة كافة أساليب C++ التي تتوافق مع SCHED
البدائيات من النوع REQ؛

· ال FfMacSchedSapUser تحدد الفئة كافة أساليب C++ التي تتوافق مع SCHED
البدائيات من النوع CNF/IND؛

· ال FfMacCschedSapProvider تحدد الفئة كافة أساليب C++ التي تتوافق معها
الأوليات CSCHED من النوع REQ؛

· ال FfMacCschedSapUser تحدد الفئة جميع أساليب C++ التي تتوافق مع CSCHED
البدائيات من النوع CNF/IND؛

هناك 3 كتل متضمنة في واجهة برنامج جدولة MAC: كتلة التحكم، وكتلة الإطار الفرعي
وكتلة المجدول. توفر كل واحدة من هذه الكتل جزءًا واحدًا من واجهة برنامج جدولة MAC.
يوضح الشكل أدناه العلاقة بين الكتل وبرامج SAP المحددة في موقعنا
تنفيذ واجهة جدولة MAC.
[صورة]

بالإضافة إلى المبادئ المذكورة أعلاه، تم اتخاذ خيارات التصميم التالية:

· تعريف فئات واجهة برنامج جدولة MAC يتبع اصطلاحات التسمية
ل NS-3 نمط الترميز. على وجه الخصوص، نحن نتبع اتفاقية CamelCase لـ
أسماء بدائية. على سبيل المثال، البدائية CSCHED_CELL_CONFIG_REQ يترجم إلى
CschedCellConfigReq في ال NS-3 رمز.

· يتم اتباع نفس اصطلاحات التسمية للمعلمات البدائية. كما
المعلمات البدائية هي متغيرات الأعضاء في الفئات، وهي أيضًا مسبوقة بـ a
m_.

· فيما يتعلق باستخدام المتجهات والقوائم في هياكل البيانات، نلاحظ أن [FFAPI] هو
إلى حد كبير واجهة برمجة التطبيقات الموجهة نحو C. ومع ذلك، اعتبر أن C++ مستخدم في ns-3، وذلك
لا يُنصح باستخدام صفائف C، فقد استخدمنا ناقلات STL (الأمراض المنقولة جنسيا :: ناقلات) ل
تنفيذ واجهة جدولة MAC، بدلاً من استخدام صفائف C
تم اقتراحه ضمنيًا من خلال طريقة كتابة [FFAPI].

· في لغة C++، لا يُسمح للأعضاء ذوي المنشئات والمدمرات بالدخول النقابات. ومن هنا كل شيء
هياكل البيانات تلك التي يقال إنها النقابات في [FFAPI] تم تعريفها على أنها
البنيات في كودنا.

يوضح الشكل أدناه كيفية استخدام واجهة جدولة MAC داخل eNB.
[صورة]

يتم تنفيذ جانب المستخدم لكل من CSCHED SAP وSCHED SAP داخل eNB MAC،
أي في الملف lte-enb-mac.cc. يمكن استخدام eNB MAC مع برنامج جدولة مختلف
التنفيذ دون تعديلات. ويبين الشكل نفسه أيضا، على سبيل المثال، كيف
يتم تنفيذ برنامج Round Robin جدولة: للتفاعل مع MAC الخاص بـ eNB، وRound Robin
يقوم المجدول بتنفيذ جانب الموفر من واجهات SCHED SAP وCSCHED SAP. أ
يمكن استخدام نهج مماثل لتنفيذ برامج الجدولة الأخرى أيضًا. وصف لكل منهما
من تطبيقات الجدولة التي نقدمها كجزء من وحدة محاكاة LTE الخاصة بنا هي
المنصوص عليها في الأقسام الفرعية التالية.

مستدير روبن (ر) جدولة
من المحتمل أن يكون برنامج جدولة Round Robin (RR) هو أبسط برنامج جدولة موجود في الأدبيات.
وهو يعمل عن طريق تقسيم الموارد المتاحة بين التدفقات النشطة، أي تلك المنطقية
القنوات التي تحتوي على قائمة انتظار RLC غير فارغة. إذا كان عدد RBG أكبر من
عدد التدفقات النشطة، يمكن تخصيص كافة التدفقات في نفس الإطار الفرعي. وإلا إذا
عدد التدفقات النشطة أكبر من عدد RBGs، وليس كل التدفقات يمكن أن تكون كذلك
المقرر في إطار فرعي معين؛ ثم، في الإطار الفرعي التالي سيبدأ التخصيص من
التدفق الأخير الذي لم يتم تخصيصه. تم الانتهاء من نظام MCS الذي سيتم اعتماده لكل مستخدم
وفقًا لمؤشرات جودة النطاق العريض المستلمة.

فيما يتعلق بـ HARQ، تطبق RR النسخة غير التكيفية، مما يعني ذلك في
تخصيص محاولات إعادة الإرسال يستخدم RR نفس تكوين التخصيص لـ
الكتلة الأصلية، وهو ما يعني الحفاظ على نفس RBGs وMCS. وحدات UE المخصصة ل
لا يتم اعتبار عمليات إعادة إرسال HARQ لنقل البيانات الجديدة في حالة وجودها
فرصة إرسال متاحة في نفس TTI. وأخيرًا، يمكن تعطيل HARQ باستخدام
نظام سمات ns3 للحفاظ على التوافق مع الإصدارات السابقة مع حالات الاختبار والتعليمات البرمجية القديمة،
بالتفصيل:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled"، BooleanValue (false));

يقوم المجدول بتنفيذ تصفية CQIs للوصلة الصاعدة وفقًا لطبيعتها
UlCqiFilter الصفة بالتفصيل:

· SRS_UL_CQI: يتم تخزين CQI المستند إلى SRS فقط في السمات الداخلية.

· PUSCH_UL_CQI: يتم تخزين CQI المستند إلى PUSCH فقط في السمات الداخلية.

· ALL_UL_CQI: يتم تخزين كافة مؤشرات جودة الجودة (CQIs) في نفس السمة الداخلية (أي آخر CQI
يتم تخزينها بشكل مستقل عن طبيعتها).

متناسب معرض (FP) جدولة
تعمل أداة جدولة العرض النسبي (PF) [Sesia2009] عن طريق جدولة المستخدم عندما يكون
تعد جودة القناة اللحظية عالية مقارنة بمتوسط ​​حالة القناة الخاصة بها
وقت. دع i,j يشير إلى المستخدمين العموميين؛ دع t يكون فهرس الإطار الفرعي، و k هو المورد
مؤشر الكتلة؛ دع M_{i,k}(t) يكون MCS قابلاً للاستخدام من قبل المستخدم i على كتلة الموارد k وفقًا لما
تم الإبلاغ عنها بواسطة نموذج AMC (انظر على التكيف تعديل البرمجة); وأخيرا، دع S (M، B) يكون
حجم السل بالبت كما هو محدد في [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). يتم تحديد الأخير في نهاية الإطار الفرعي ر
باستخدام نهج المتوسط ​​المتحرك الأسي التالي:

حيث lpha هو الثابت الزمني (في عدد الإطارات الفرعية) للحركة الأسية
المتوسط، و384s هو الإنتاجية الفعلية التي حققها المستخدم i في الإطار الفرعي t. 360 هو
تقاس وفقا للإجراء التالي. أولاً نحدد MCS 840 j:

ثم نحدد العدد الإجمالي 936 ي :

حيث |

فيما يتعلق بـ HARQ، يطبق PF النسخة غير التكيفية، مما يعني ذلك في
تخصيص محاولات إعادة الإرسال يستخدم المجدول نفس التخصيص
تكوين الكتلة الأصلية، مما يعني الحفاظ على نفس RBGs وMCS. UEs
التي تم تخصيصها لإعادة إرسال HARQ لا تعتبر لنقل جديدة
البيانات في حالة توفر فرصة إرسال في نفس TTI. أخيرا، حرق
يمكن تعطيله باستخدام نظام سمات ns3 للحفاظ على التوافق مع الإصدارات القديمة
حالات الاختبار والرمز بالتفصيل:

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled"، BooleanValue (false));

أقصى الإنتاجية (MT) جدولة
يهدف برنامج جدولة الحد الأقصى للإنتاجية (MT) [FCapo2012] إلى زيادة الإنتاجية الإجمالية إلى الحد الأقصى
من eNB. فهو يخصص كل RB للمستخدم الذي يمكنه تحقيق أقصى معدل يمكن تحقيقه فيه
TTI الحالي. حاليًا، يوجد لجدولة MT في NS-3 نسختان: مجال التردد
(FDMT) والمجال الزمني (TDMT). في FDMT، يقوم كل برنامج جدولة TTI وMAC بتخصيص RBGs إلى UE
الذي لديه أعلى معدل يمكن تحقيقه محسوبًا بواسطة النطاق الفرعي CQI. في TDMT، كل TTI، MAC
يختار المجدول UE واحدًا يتمتع بأعلى معدل يمكن تحقيقه محسوبًا بواسطة CQI واسع النطاق.
ثم يقوم برنامج جدولة MAC بتخصيص جميع RBGs إلى UE هذا في TTI الحالي. حساب
المعدل الذي يمكن تحقيقه في FDMT وTDMT هو نفس المعدل الموجود في PF. دع i,j يشير إلى عام
المستخدمين؛ دع t يكون فهرس الإطار الفرعي، و k هو فهرس كتلة الموارد؛ دع M_{i،k}(t) يكون
MCS يمكن استخدامها من قبل المستخدم i على كتلة الموارد k وفقًا لما أبلغ عنه نموذج AMC (انظر
على التكيف تعديل البرمجة); أخيرًا، دع S(M, B) يكون حجم السل بالبتات كما هو محدد في
[TS36213] للحالة التي يتم فيها استخدام الرقم B من كتل الموارد. المعدل الذي يمكن تحقيقه
يتم تعريف R_{i}(k,t) بالبت/الثانية للمستخدم i على كتلة الموارد k في الإطار الفرعي t على أنه

حيث au هي مدة TTI. في بداية كل إطار فرعي t، يتم تعيين كل RB إلى a
مستخدم معين. بالتفصيل، الفهرس 144}_{k}(t) الذي تم تعيين RB k له في الوقت t هو
تحدد كما

عندما يكون هناك العديد من وحدات المستعمل لها نفس المعدل القابل للتحقيق، فإن التنفيذ الحالي دائمًا
يحدد أول UE تم إنشاؤه في البرنامج النصي. على الرغم من أن MT يمكنه زيادة إنتاجية الخلية إلى الحد الأقصى، إلا أنه
لا يمكن أن توفر العدالة لتجهيزات المستعمل في حالة القناة السيئة.

الإنتاجية إلى متوسط (تا) جدولة
يمكن اعتبار جدولة الإنتاجية إلى المتوسط ​​(TTA) [FCapo2012] بمثابة وسيط
بين MT وPF. يتم حساب المقياس المستخدم في TTA على النحو التالي:

هنا، تمثل R_{i}(k,t) بالبت/الثانية المعدل الذي يمكن تحقيقه للمستخدم i على كتلة الموارد k عند
الإطار الفرعي ر. طريقة الحساب موضحة بالفعل في MT وPF. وفي الوقت نفسه، R_{i}(t) في
تشير البتة/الثانية إلى المعدل الذي يمكن تحقيقه بالنسبة إلى i عند الإطار الفرعي t. الفرق بين هذين
معدلات يمكن تحقيقها هي كيفية الحصول على MCS. بالنسبة إلى R_{i}(k,t)، يتم حساب MCS بواسطة النطاق الفرعي CQI while
يتم حساب R_{i}(t) بواسطة CQI عريض النطاق. لا يمكن تنفيذ برنامج جدولة TTA إلا بالتردد
المجال (FD) لأن المعدل الذي يمكن تحقيقه لـ RBG معين يرتبط فقط بـ FD
الجدولة.

بليند متوسط الإنتاجية جدولة
يهدف برنامج جدولة متوسط ​​الإنتاجية الأعمى [FCapo2012] إلى توفير إنتاجية متساوية للجميع
وحدات المستعمل تحت eNB. يتم حساب المقياس المستخدم في TTA على النحو التالي:

حيث T_{j}(t) هو أداء الإنتاجية السابق الذي يراه المستخدم j ويمكن أن يكون
يتم حسابها بنفس الطريقة في جدولة PF. في المجال الزمني متوسط ​​الإنتاجية الأعمى
(TD-BET)، يختار المجدول UE ذو مقياس الأولوية الأكبر ويخصص جميع RBGs
إلى هذا الاتحاد الأوروبي. من ناحية أخرى، في مجال التردد متوسط ​​الإنتاجية الأعمى (FD-BET)،
في كل TTI، يقوم المجدول أولاً باختيار UE واحد ذي أقل متوسط ​​إنتاجية سابقة (أكبر
مقياس الأولوية). ثم يقوم المجدول بتعيين RBG واحد لUE هذا، ويحسب المتوقع
صبيب هذا المستعمل ويستخدمه للمقارنة مع متوسط ​​الصبيب السابق T_{j}(t) of
وحدات استخدام أخرى. يستمر المجدول في تخصيص RBG لUE هذا حتى المتوقع
والصبيب ليس الأصغر بين متوسط ​​الصبيب T_{j}(t) السابق لجميع تجهيزات المستعمل. ثم
سيستخدم المجدول نفس الطريقة لتخصيص RBG لوحدة مستعمل جديدة ذات أدنى مستوى سابق
متوسط ​​الإنتاجية T_{j}(t) حتى يتم تخصيص جميع RBGs لوحدات المستعمل. المبدأ الكامن وراء هذا
هو أنه في كل TTI، يحاول المجدول بذل قصارى جهده لتحقيق الإنتاجية المتساوية بين
جميع الوحدات.

رمز المصرف معرض طابور جدولة
Token Bank Fair Queue (TBFQ) عبارة عن برنامج جدولة مدرك لجودة الخدمة مشتق من الدلو المتسرب
آلية. في TBFQ، يتميز تدفق حركة مرور المستخدم i بالمعلمات التالية:

· t_{i}: معدل وصول الحزمة (بايت/ثانية)

· r_{i}: معدل إنشاء الرمز المميز (بايت/ثانية)

· p_{i}: حجم تجمع الرمز المميز (بايت)

· E_{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} أقل من هذا الحد، فلن يتمكن المستخدم i من استعارة الرموز المميزة
من البنك. وذلك لمنع UE الضار من استعارة الكثير من الرموز المميزة.

· حد الائتمان c_{i}: الحد الأقصى لعدد الرموز المميزة UE التي يمكنني اقتراضها من البنك في عملة واحدة
مرة.

· حد الائتمان C: بمجرد وصول E_{i} إلى حد الدين، يجب على UE تخزين رموز C في البنك
من أجل اقتراض المزيد من الرمز المميز من البنك.

يحتوي LTE في NS-3 على نسختين من جدولة TBFQ: مجال التردد TBFQ (FD-TBFQ) والوقت
المجال TBFQ (TD-TBFQ). في FD-TBFQ، يقوم المجدول دائمًا بتحديد UE بأعلى مقياس و
يخصص RBG مع أعلى نطاق فرعي CQI حتى لا توجد حزم داخل المخزن المؤقت RLC الخاص بـ UE
أو يتم تخصيص جميع RBGs [FABokhari2009]. في TD-TBFQ، بعد اختيار UE مع الحد الأقصى
متري، فإنه يخصص جميع RBGs لUE هذا باستخدام النطاق العريض CQI [WKWong2004].

درجة الأهمية بكيج جدولة
برنامج جدولة مجموعة الأولوية (PSS) هو برنامج جدولة مدرك لجودة الخدمة والذي يجمع بين المجال الزمني (TD) و
عمليات جدولة حزم مجال التردد (FD) في برنامج جدولة واحد [GMonghal2008]. هو - هي
يتحكم في العدالة بين وحدات المستعمل من خلال معدل البت المستهدف المحدد (TBR).

في جزء جدولة TD، يقوم PSS أولاً بتحديد وحدات المستعمل ذات المخزن المؤقت RLC غير الفارغ ثم يقوم بتقسيمها
إلى مجموعتين على أساس TBR:

· المجموعة 1: تجهيزات المستعمل التي يقل متوسط ​​صبيبها السابق عن TBR؛ يحسب جدولة TD
مقياس الأولوية الخاص بهم بأسلوب الإنتاجية المتساوية (BET):

· المجموعة 2: تجهيزات المستعمل التي يكون متوسط ​​صبيبها السابق أكبر (أو يساوي) من TBR؛ جدولة TD
يحسب مقياس الأولوية الخاص به بأسلوب النسبي العادل (PF):

تتمتع تجهيزات المستعمل التي تنتمي إلى المجموعة 1 بأولوية أعلى من تلك الموجودة في المجموعة 2. وبعد ذلك سيتم تحديد PSS
عدد N_{mux} من وحدات المستعمل ذات القياس الأعلى في مجموعتين، ثم يتم توجيه وحدات المستعمل هذه إلى برنامج جدولة FD. في بي إس إس،
يخصص برنامج جدولة FD RBG k لـ UE n الذي يصل إلى الحد الأقصى للقياس المختار. اثنين من جدولة PF
تستخدم في جدولة PF:

· المعرض النسبي المقرر (PFsch)

· الناقل عبر التدخل إلى المتوسط ​​(كويتا)

حيث يكون Tsch_{j}(t) مشابهًا لأداء الإنتاجية السابق الذي يراه المستخدم j، مع
الفرق هو أنه يتم تحديثه فقط عندما يتم تقديم الخدمة للمستخدم الأول بالفعل. CoI[j,k] هو
تقدير SINR على RBG k لـ UE j . كل من PFsch وCoIta مخصصان لفصل FD
متري من جدولة TD. بالإضافة إلى ذلك، يوفر برنامج جدولة PSS FD أيضًا مقياسًا للوزن W[n]
للمساعدة في التحكم في العدالة في حالة انخفاض عدد وحدات المستعمل.

حيث T_{j}(t) هو أداء الإنتاجية السابق الذي يراه المستخدم j . لذلك، على
RBG k، يختار برنامج جدولة FD UE j الذي يزيد ناتج التردد إلى الحد الأقصى
مقياس المجال (Msch، MCoI) بالوزن W[n]. ستضمن هذه الإستراتيجية إنتاجية
تميل UE ذات الجودة المنخفضة نحو TBR.

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled"، BooleanValue (false));

يقوم المجدول بتنفيذ تصفية CQIs للوصلة الصاعدة وفقًا لطبيعتها
UlCqiFilter الصفة بالتفصيل:

· SRS_UL_CQI: يتم تخزين CQI المستند إلى SRS فقط في السمات الداخلية.

· PUSCH_UL_CQI: يتم تخزين CQI المستند إلى PUSCH فقط في السمات الداخلية.

· ALL_UL_CQI: يتم تخزين كافة مؤشرات جودة الجودة (CQIs) في نفس السمة الداخلية (أي آخر CQI
يتم تخزينها بشكل مستقل عن طبيعتها).

قناة جودة الخدمة علم جدولة
برنامج جدولة القناة وجودة الخدمة (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} حتى تكون جميع RBGs
المعينة في TTI المقابلة. في FD، لكل RBG k=1,...,K، جدولة CQA
يقوم بتعيين RBG الحالي للمستخدم j الذي لديه الحد الأقصى لقيمة مقياس FD الذي نحن
تحديد بالطريقة التالية:

حيث يتم حساب m_{GBR}^j(t) على النحو التالي:

حيث GBR^j هو معدل البت المحدد في حامل EPS للتدفق j، rie R j ( ) 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 بالنسبة للمستخدم
ي ويتم حسابها بالطريقة التالية:

حيث CQI^{(k,j)}(t) هي آخر قيمة CQI تم الإبلاغ عنها من المستخدم j لـ k-th RBG.

يمكن للمستخدم تحديد ما إذا كان سيتم استخدام m_{pf} أو m_{ff} عن طريق تعيين السمة
ns3::CqaFfMacScheduler::CqaMetric على التوالي ل "ككابف" or "كقافف".

عشوائية استخدم
يتضمن نموذج LTE نموذجًا لإجراء الوصول العشوائي بناءً على بعض التبسيط
الافتراضات، والتي نوضحها بالتفصيل فيما يلي لكل من الرسائل والإشارات
الموصوفة في المواصفات [TS36321].

· عشوائية استخدم (ضفدع) مقدمة: في أنظمة LTE الحقيقية يتوافق هذا مع Zadoff-Chu
(ZC) باستخدام أحد التنسيقات العديدة المتاحة والمرسلة في فتحات PRACH
والتي يمكن أن تتداخل من حيث المبدأ مع PUSCH. مؤشر تكوين PRACH 14 هو
من المفترض، أي أنه يمكن إرسال الديباجات على أي رقم إطار نظام ورقم إطار فرعي.
تم تصميم مقدمة RA باستخدام فئة LteControlMessage، على سبيل المثال، كنموذج مثالي
رسالة لا تستهلك أي موارد الراديو. تصادم الديباجة
يتم تصميم الإرسال بواسطة وحدات مستعمل متعددة في نفس الخلية باستخدام بروتوكول
نموذج التداخل، أي عندما يتم إرسال ديباجتين متطابقتين أو أكثر
نفس الخلية في نفس TTI، لن يتم استقبال أي من هذه الديباجات المتطابقة
eNB. بخلاف نموذج الاصطدام هذا، لا يوجد نموذج خطأ مرتبط بـ
استقبال ديباجة RA.

· عشوائية استخدم استجابة (رار): في أنظمة LTE الحقيقية، يتم إرسال وحدة PDU الخاصة لـ MAC
DL-SCH. نظرًا لأن عناصر التحكم في MAC لم يتم تصميمها بدقة في جهاز المحاكاة
(فقط RLC وما فوق وحدات PDU)، تم تصميم RAR على أنه LteControlMessage الذي يقوم بذلك
لا تستهلك أي موارد الراديو. ومع ذلك، أثناء إجراء RA، سيقوم LteEnbMac بذلك
طلب من المجدول تخصيص الموارد لـ RAR باستخدام FF MAC
جدولة SCHED_DL_RACH_INFO_REQ البدائية. وبالتالي، جدولة المحسنة
التنفيذ (غير متوفر في الوقت الحالي) يمكن أن يخصص موارد راديوية لـ
RAR، وبالتالي نمذجة استهلاك موارد الراديو لنقل
رر.

· الموضوع 3: في أنظمة LTE الحقيقية، هذا هو RLC TM SDU يتم إرساله عبر الموارد المحددة
في UL Grant في RAR. في جهاز المحاكاة، تم تصميم هذا على أنه RLC TM RLC حقيقي
وحدة PDU التي يتم تخصيص موارد UL الخاصة بها بواسطة المجدول عند الاتصال بها
SCHED_DL_RACH_INFO_REQ.

· خلاف دقة الشاشة (سجل تجاري): في نظام LTE الحقيقي، هناك حاجة إلى مرحلة CR لمعالجة
الحالة التي يرسل فيها اثنان أو أكثر من تجهيزات المستعمل نفس ديباجة RA في نفس TTI، وكان eNB كذلك
قادرة على الكشف عن هذه الديباجة على الرغم من الاصطدام. لأن هذا الحدث لا
تحدث نتيجة لنموذج تداخل البروتوكول المستخدم لاستقبال مقدمات RA،
لم يتم تصميم مرحلة CR في جهاز المحاكاة، أي أنه لا يتم إرسال CR MAC CE أبدًا
ويعتبر eNB وUEs أن RA ناجح عند استقبال RAR. ك
ونتيجة لذلك، فإن الموارد الراديوية المستهلكة لإرسال CR MAC CE هي
لا على غرار.

الشكل تسلسل رسم بياني of هيه على أساس التنافس ماك عشوائية استخدم الإجراءات تسلسل
رسم بياني of هيه غير قائم على الخلاف ماك عشوائية استخدم الإجراءات يظهر التسلسل
الرسوم البيانية للوصول العشوائي إلى MAC القائم على التنافس وغير القائم على التنافس على التوالي
الإجراء، وتسليط الضوء على التفاعلات بين لجنة الهدنة العسكرية والكيانات الأخرى.
[صورة] مخطط تسلسلي لإجراء الوصول العشوائي إلى MAC القائم على التنافس.UNINDENT
[صورة] مخطط تسلسلي للوصول العشوائي إلى MAC غير القائم على التنافس
الإجراء.UNINDENT

RLC
نظرة عامة
تم تحديد كيان RLC في المواصفات الفنية لـ 3GPP [TS36322]، ويتضمن
ثلاثة أنواع مختلفة من RLC: الوضع الشفاف (TM)، ووضع عدم الاعتراف (UM) و
الوضع المعترف به (ص). ويتضمن جهاز المحاكاة نموذجاً واحداً لكل جهة من هذه الجهات

توفر كيانات RLC واجهة خدمة RLC لطبقة PDCP العليا وMAC
واجهة الخدمة إلى طبقة MAC السفلى. تستخدم كيانات RLC واجهة خدمة PDCP
من طبقة PDCP العليا وواجهة خدمة MAC من طبقة MAC السفلية.

الشكل تطبيق الموديل of بكب، RLC ماك الكيانات حلول SAP ويبين
نموذج تنفيذ كيانات RLC وعلاقته بجميع الكيانات الأخرى
والخدمات في مكدس البروتوكول.
[صورة] نموذج تنفيذ كيانات PDCP وRLC وMAC وSAPs.UNINDENT

العطاء واجهات
RLC العطاء السطح البيني
تنقسم واجهة خدمة RLC إلى قسمين:

· ال RlcSapProvider يتم توفير الجزء بواسطة طبقة RLC ويتم استخدامه بواسطة طبقة PDCP العليا


· ال RlcSapUser يتم توفير الجزء بواسطة طبقة PDCP العليا وتستخدمه طبقة RLC.

يوفر كل من كياني UM وAM RLC نفس واجهة خدمة RLC للجزء العلوي
طبقة بي دي سي بي.

RLC العطاء البدائيون
تحدد القائمة التالية أساسيات الخدمة التي توفرها خدمة RLC
واجهات:

· RlcSapProvider::TransmitPdcpPdu

· يستخدم كيان PDCP هذه البدائية لإرسال PDCP PDU إلى كيان RLC الأدنى
في نظير الارسال

· RlcSapUser::ReceivePdcpPdu

· يستخدم كيان RLC هذه البدائية لإرسال PDCP PDU إلى كيان PDCP العلوي
في النظير المتلقي

ماك العطاء السطح البيني
تنقسم واجهة خدمة MAC إلى قسمين:

· ال MacSapProvider يتم توفير الجزء بواسطة طبقة MAC ويتم استخدامه بواسطة طبقة RLC العليا


· ال com.MacSapUser يتم توفير الجزء بواسطة طبقة RLC العليا ويتم استخدامه بواسطة طبقة MAC.

ماك العطاء البدائيون
تحدد القائمة التالية أساسيات الخدمة التي توفرها خدمة MAC
واجهات:

· MacSapProvider::TransmitPdu

· يستخدم كيان RLC هذه البدائية لإرسال RLC PDU إلى كيان MAC الأدنى فيه
النظير الارسال

· MacSapProvider::ReportBufferStatus

· يستخدم كيان RLC هذا الإعداد الأولي للإبلاغ عن كيان MAC بحجم معلق
المخازن المؤقتة في نظير الارسال

· MacSapUser::NotifyTxOpportunity

· يستخدم كيان MAC هذا الإجراء الأولي لإخطار كيان RLC بالإرسال
غير محدودة

· MacSapUser::ReceivePdu

· يستخدم كيان MAC هذا البدائي لإرسال RLC PDU إلى كيان RLC العلوي
في النظير المتلقي

AM RLC
يتم شرح معالجة نقل البيانات في كيان RLC في وضع الإقرار (AM).
في القسم 5.1.3 من [TS36322]. في هذا القسم نعرض بعض التفاصيل عن
تنفيذ كيان RLC.

معادِلات For هيه نقل عمليات
يحتفظ تطبيقنا لكيان AM RLC بثلاثة مخازن مؤقتة لعمليات الإرسال:

· ناقل السرعة العازلة: إنها قائمة انتظار RLC SDU. عندما يتلقى كيان AM RLC وحدة SDU
في خدمة TransmitPdcpPdu البدائية من كيان PDCP العلوي، يتم وضعها في قائمة الانتظار
في المخزن المؤقت للإرسال. لقد وضعنا حدًا لحجم المخزن المؤقت لـ RLC وبصمت فقط
قم بإسقاط وحدات SDU عندما يكون المخزن المؤقت ممتلئًا.

· أحال وحدات PDU العازلة: إنها قائمة انتظار وحدات PDU RLC المرسلة والتي
لم يتم استلام ACK/NACK بعد. عندما يرسل كيان AM RLC وحدة PDU إلى MAC
الكيان، فإنه يضع أيضًا نسخة من وحدة PDU المرسلة في المخزن المؤقت لوحدات PDU المرسلة.

· إعادة البث العازلة: إنها قائمة انتظار RLC PDUs التي يتم أخذها في الاعتبار
إعادة الإرسال (أي تم NACKed). يقوم كيان AM RLC بنقل وحدة PDU هذه إلى
مخزن إعادة الإرسال المؤقت، عندما يعيد إرسال وحدة PDU من المخزن المؤقت المرسل.

نقل عمليات in الهابطة
يوضح الرسم البياني التسلسلي التالي التفاعلات بين الكيانات المختلفة (RRC،
PDCP، AM RLC، MAC وMAC جدولة) من eNB في الوصلة الهابطة لأداء البيانات
مجال الاتصالات.

الشكل تسلسل رسم بياني of البيانات PDU انتقال in الهابطة يبين كيفية الطبقات العليا
إرسال وحدات PDU للبيانات وكيفية معالجة تدفق البيانات بواسطة الكيانات/الخدمات المختلفة
مكدس بروتوكول LTE.
[صورة] مخطط تسلسلي لنقل البيانات PDU في الوصلة الهابطة.UNINDENT

يستدعي كيان PDCP Transmit_PDCP_PDU الخدمة بدائي من أجل إرسال البيانات
PDU. يقوم كيان AM RLC بمعالجة هذه الخدمة بشكل أساسي وفقًا لبيانات AM
إجراءات النقل المحددة في القسم 5.1.3 من [TS36322].

عندما Transmit_PDCP_PDU يتم استدعاء الخدمة البدائية، ويقوم كيان AM RLC بتنفيذ
العمليات التالية:

· وضع البيانات SDU في المخزن المؤقت للإرسال.

· حساب حجم المخازن المؤقتة (كيف سيتم حساب حجم المخازن المؤقتة
وأوضح بعد ذلك).

· اتصل ب Report_Buffer_Status الخدمة البدائية لكيان eNB MAC من أجل
قم بإخطار كيان eNB MAC بأحجام المخازن المؤقتة لكيان AM RLC. ثم،
يقوم كيان eNB MAC بتحديث حالة المخزن المؤقت في برنامج جدولة MAC باستخدام
خدمة SchedDlRlcBufferReq البدائية لواجهة برمجة التطبيقات لجدولة FF MAC.

بعد ذلك، عندما يقرر برنامج جدولة MAC إمكانية إرسال بعض البيانات، يتم إرسال كيان MAC
بإعلامه إلى كيان RLC، أي أنه يستدعي Notify_Tx_Opportunity الخدمة بدائية،
ثم يقوم كيان AM RLC بما يلي:

· إنشاء وحدة PDU بيانات واحدة عن طريق تجزئة و/أو تسلسل وحدات SDU في
المخزن المؤقت للإرسال.

· نقل البيانات PDU من المخزن المؤقت للإرسال إلى المخزن المؤقت لوحدات PDU المرسلة.

· تحديث متغيرات الحالة وفقًا للقسم 5.1.3.1.1 من [TS36322].

· اتصل ب Transmit_PDU بدائي لإرسال بيانات PDU إلى كيان MAC.

إعادة البث in الهابطة
مخطط تسلسل الشكل تسلسل رسم بياني of البيانات PDU إعادة الإرسال in الهابطة
يُظهر التفاعلات بين الكيانات المختلفة (AM RLC وMAC وMAC جدولة) الخاصة بـ
eNB في الوصلة الهابطة عندما يجب إعادة إرسال وحدات PDU للبيانات بواسطة كيان AM RLC.
[صورة] مخطط تسلسلي لإعادة إرسال البيانات PDU في الوصلة الهابطة.UNINDENT

يمكن لكيان الإرسال AM RLC أن يستقبل وحدات PDU الخاصة بالحالة من كيان AM RLC النظير.
يتم إرسال وحدات PDU للحالة وفقًا للقسم 5.3.2 من [TS36322] ومعالجة
يتم الاستقبال وفقًا للقسم 5.2.1 من [TS36322].

عند إعادة إرسال وحدات PDU للبيانات من المخزن المؤقت لوحدات PDU المرسلة، يتم نقلها أيضًا إلى
المخزن المؤقت لإعادة الإرسال.

نقل عمليات in الإرسال
مخطط تسلسل الشكل تسلسل رسم بياني of البيانات PDU انتقال in الإرسال عروض
التفاعلات بين الكيانات المختلفة لتجهيزات المستعمل (RRC وPDCP وRLC وMAC) و
eNB (MAC وScheduler) في الوصلة الصاعدة عندما يتم إرسال وحدات PDU للبيانات بواسطة الطبقات العليا.
[صورة] مخطط تسلسلي لنقل البيانات PDU في الوصلة الصاعدة.UNINDENT

وهو مشابه لمخطط التسلسل في الوصلة الهابطة؛ والفرق الرئيسي هو أن في هذا
في حالة إرسال Report_Buffer_Status من UE MAC إلى برنامج جدولة MAC في eNB
عبر الهواء باستخدام قناة التحكم.

إعادة البث in الإرسال
مخطط تسلسل الشكل تسلسل رسم بياني of البيانات PDU إعادة الإرسال in الإرسال عروض
التفاعلات بين الكيانات المختلفة لتجهيزات المستعمل (AM RLC وMAC) وeNB
(MAC) في الوصلة الصاعدة عندما يجب إعادة إرسال وحدات PDU للبيانات بواسطة كيان AM RLC.
[صورة] مخطط تسلسلي لإعادة إرسال البيانات PDU في الوصلة الصاعدة.UNINDENT

عملية حسابية of هيه العازلة المقاس
يحتوي المخزن المؤقت للإرسال على وحدات RLC SDU. وحدة RLC PDU عبارة عن مقطع واحد أو أكثر من وحدات SDU بالإضافة إلى
رأس RLC. يعتمد حجم رأس RLC لوحدة RLC PDU واحدة على عدد SDU
الأجزاء التي تحتوي عليها وحدة PDU.

يقول معيار 3GPP (القسم 6.1.3.1 من [TS36321]) بوضوح أنه بالنسبة للوصلة الصاعدة،
لا يتم أخذ رؤوس RLC وMAC في الاعتبار في حجم المخزن المؤقت الذي سيتم التقرير عنه كجزء منه
تقرير حالة المخزن المؤقت. بالنسبة للوصلة الهابطة، لم يتم تحديد السلوك. لا
[FFAPI] يحدد كيفية القيام بذلك. يعمل نموذج RLC الخاص بنا على افتراض أن حساب
يتم حجم المخزن المؤقت في الوصلة الهابطة تمامًا كما هو الحال في الوصلة الصاعدة، أي لا يأخذ في الاعتبار
حجم رأس RLC وMAC.

نلاحظ أن هذا الاختيار يؤثر على التشغيل البيني مع برنامج جدولة MAC، منذ ذلك الحين
ردا على Notify_Tx_Opportunity الخدمة بدائية، ومن المتوقع أن يقوم RLC بإنشاء ملف
وحدة PDU لا تزيد عن الحجم المطلوب بواسطة MAC، بما في ذلك الحمل RLC. وبالتالي، لا لزوم لها
يمكن أن يحدث التجزئة إذا (على سبيل المثال) قام MAC بإخطار إرسال مساوٍ تمامًا لـ
حجم المخزن المؤقت الذي تم الإبلاغ عنه سابقًا بواسطة RLC. نحن نفترض أن الأمر متروك للمجدول
لتنفيذ استراتيجيات ذكية لاختيار حجم الإرسال
الفرصة، من أجل تجنب عدم كفاءة التجزئة غير الضرورية.

سلسلة التجزئة
يقوم كيان AM RLC بإنشاء وإرسال RLC PDU واحد بالضبط لكل إرسال
الفرصة حتى لو كانت أصغر من الحجم الذي أبلغت عنه فرصة الإرسال.
لذلك، على سبيل المثال، إذا تم إرسال STATUS PDU، فسيتم إرسال وحدة PDU هذه فقط في ذلك
فرصة الإرسال.

ويتبع التجزئة والتسلسل لقائمة انتظار SDU لكيان AM RLC نفس الشيء
الفلسفة هي نفس إجراءات كيان UM RLC ولكن هناك متغيرات حالة جديدة
(انظر [TS36322] القسم 7.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
في هذا القسم، نصف عملية تنفيذ كيان RLC في وضع عدم الإقرار (UM).

نقل عمليات in الهابطة
تشبه عمليات الإرسال الخاصة بـ UM RLC عمليات الإرسال الخاصة بـ AM RLC سابقًا
الموصوفة في القسم نقل عمليات in الهابطة، مع الفارق الذي يليه
مواصفات [TS36322]، لم يتم إجراء إعادة الإرسال، ولا توجد حالة
وحدات PDU.

نقل عمليات in الإرسال
تشبه عمليات الإرسال في الوصلة الصاعدة عمليات الوصلة الهابطة، مع الرئيسية
الفرق الذي يتم إرسال Report_Buffer_Status من UE MAC إلى برنامج جدولة MAC فيه
وeNB عبر الهواء باستخدام قناة التحكم.

عملية حسابية of هيه العازلة المقاس
يتم حساب حجم المخزن المؤقت لـ UM RLC باستخدام نفس أسلوب
AM RLC، يرجى الرجوع إلى القسم عملية حسابية of هيه العازلة المقاس للمقابل
وصف.

TM RLC
في هذا القسم نقوم بوصف تنفيذ كيان RLC للوضع الشفاف (TM).

نقل عمليات in الهابطة
وفي جهاز المحاكاة، لا يزال TM RLC يوفر للطبقات العليا نفس واجهة الخدمة
المقدمة من كيانات AM وUM RLC إلى طبقة PDCP؛ في الممارسة العملية، هذه الواجهة
يُستخدم بواسطة كيان RRC (وليس كيان PDCP) لإرسال وحدات RLC SDU. هذا الاختيار هو
بدافع من حقيقة أن الخدمات التي تقدمها TM RLC إلى الطبقات العليا،
وفقًا لـ [TS36322]، هي مجموعة فرعية من تلك التي توفرها كيانات UM وAM RLC إلى
طبقة بكب؛ ومن ثم، قمنا بإعادة استخدام نفس الواجهة من أجل البساطة.

يتم تنفيذ عمليات الإرسال في الوصلة الهابطة على النحو التالي. عندما
Transmit_PDCP_PDU الخدمة بدائي يتم استدعاؤه بواسطة الطبقات العليا، ويقوم TM RLC بذلك
التالية:

· ضع وحدة SDU في المخزن المؤقت للإرسال

· حساب حجم المخزن المؤقت للإرسال

· اتصل ب Report_Buffer_Status الخدمة البدائية لكيان 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 الإرسال
تشبه عمليات الإرسال في الوصلة الصاعدة عمليات الوصلة الهابطة، مع الرئيسية
الفرق هو أن فرصة الإرسال يمكن أن تنشأ أيضًا من تخصيص UL
المنحة كجزء من إجراء الوصول العشوائي، بدون تقرير واضح عن حالة المخزن المؤقت
الصادرة عن كيان TM RLC.

عملية حسابية of هيه العازلة المقاس
وفقًا للمواصفات [TS36322]، لا يضيف TM RLC أي رأس RLC إلى وحدات PDU
يتم نقلها. وبسبب هذا، فإن حجم المخزن المؤقت الذي تم الإبلاغ عنه لطبقة MAC هو
يتم حسابها ببساطة عن طريق جمع حجم كافة الحزم في المخزن المؤقت للإرسال، وبالتالي
إخطار MAC بالحجم الدقيق للمخزن المؤقت.

SM RLC
بالإضافة إلى تطبيقات AM وUM وTM التي تم تصميمها على غرار 3GPP
المواصفات، يتم توفير نموذج RLC مبسط، وهو ما يسمى وضع التشبع (SM)
RLC. لا يقبل نموذج RLC هذا وحدات PDU من أي طبقة أعلاه (مثل PDCP)؛ بدلا من ذلك،
يعتني SM RLC بإنشاء وحدات RLC PDU استجابةً للإخطار
فرص الإرسال التي أبلغت بها لجنة الهدنة العسكرية. وبعبارة أخرى، يحاكي SM RLC
شروط التشبع، أي أنه يفترض أن المخزن المؤقت RLC ممتلئ دائمًا ويمكنه ذلك
قم بإنشاء وحدة PDU جديدة عندما يتم إخطارك بذلك بواسطة المجدول.

يتم استخدام SM RLC لسيناريوهات المحاكاة المبسطة التي يتم فيها استخدام نموذج راديو LTE فقط
يتم استخدامه بدون EPC وبالتالي بدون أي دعم لشبكات IP. لاحظنا ذلك،
على الرغم من أن SM RLC هو نموذج حركة مرور غير واقعي، إلا أنه لا يزال يسمح بالتصحيح
محاكاة السيناريوهات ذات التدفقات المتعددة التي تنتمي إلى جودة خدمة مختلفة (غير في الوقت الفعلي).
الفئات، من أجل اختبار أداء جودة الخدمة التي تم الحصول عليها بواسطة برامج جدولة مختلفة. هذا يمكن
يجب القيام به نظرًا لأن مهمة المجدول هي تعيين موارد النقل بناءً على ذلك
الخصائص المحددة (مثل معدل البت المضمون) لكل حامل راديو
بناء على تعريف كل حامل ضمن برنامج المحاكاة.

أما بالنسبة للجدولة المصممة للعمل مع حركة مرور جودة الخدمة في الوقت الحقيقي والتي لها قيود تأخير،
ربما لا يكون SM RLC خيارًا مناسبًا. وذلك بسبب غياب الفعلي
وحدات RLC SDU (التي تم استبدالها بالجيل الاصطناعي لتقارير حالة المخزن المؤقت) لا تجعلها كذلك
من الممكن تزويد المجدول بمعلومات ذات معنى عن تأخير رأس الخط، وهي
غالبًا ما يكون المقياس المفضل لتنفيذ سياسات الجدولة في الوقت الفعلي
تدفقات حركة المرور. لمحاكاة واختبار مثل هذه الجداول، فمن المستحسن استخدامها
إما طرازات UM أو AM RLC بدلاً من ذلك.

بدكب
بدكب الموديل نظرة عامة
الوثيقة المرجعية لمواصفات كيان PDCP هي [TS36323]. مع الاحترام
وفقًا لهذه المواصفات، يدعم نموذج PDCP المطبق في جهاز المحاكاة فقط
الميزات التالية:

· نقل البيانات (مستوى المستخدم أو مستوى التحكم)؛

· صيانة شبكات PDCP.

· نقل حالة الرقم التسلسلي (للاستخدام عند التسليم)؛

الميزات التالية غير مدعومة حاليًا:

· ضغط الرأس وإلغاء ضغط تدفقات بيانات IP باستخدام بروتوكول ROHC؛

· التسليم المتسلسل لوحدات PDU للطبقة العليا عند إعادة إنشاء الطبقات السفلية.

· القضاء المكرر على وحدات SDU للطبقة السفلى عند إعادة إنشاء الطبقات السفلى
حاملات الراديو المعينة على RLC AM؛

· تشفير وفك تشفير بيانات مستوى المستخدم وبيانات مستوى التحكم.

· حماية السلامة والتحقق من سلامة بيانات طائرة التحكم.

· تجاهل الموقت على أساس.

· تجاهل مكررة.

بدكب العطاء السطح البيني
تنقسم واجهة خدمة PDCP إلى قسمين:

· ال PdcpSapProvider يتم توفير الجزء بواسطة طبقة PDCP وتستخدمه الطبقة العليا


· ال PdcpSapUser يتم توفير الجزء بواسطة الطبقة العليا وتستخدمه طبقة PDCP.

بدكب العطاء البدائيون
تحدد القائمة التالية أساسيات الخدمة التي توفرها خدمة PDCP
واجهات:

· PdcpSapProvider::TransmitPdcpSdu

· يستخدم كيان RRC هذه البدائية لإرسال RRC PDU إلى كيان PDCP الأدنى
في نظير الارسال

· PdcpSapUser::ReceivePdcpSdu

· يستخدم كيان PDCP هذه البدائية لإرسال RRC PDU إلى كيان RRC العلوي
في النظير المتلقي

RRC
المميزات
يوفر نموذج RRC المطبق في جهاز المحاكاة الوظائف التالية:

· توليد (في eNB) وتفسير (في UE) لمعلومات النظام (في
على وجه الخصوص، كتلة المعلومات الرئيسية، وفي وقت كتابة هذا التقرير، فقط النظام
كتلة المعلومات من النوع 1 و 2)

· الاختيار الأولي للخلية

· إجراء إنشاء اتصال RRC

· إجراء إعادة تشكيل RRC، الذي يدعم حالات الاستخدام التالية: + إعادة التشكيل
لمؤشر تكوين SRS + إعادة تكوين وضع PHY TX (MIMO) +
إعادة تشكيل قياسات تجهيزات المستعمل + إعداد حامل راديو البيانات + التسليم

· إعادة إنشاء اتصال RRC، ودعم حالات الاستخدام التالية: + التسليم

معمار
ينقسم نموذج RRC إلى المكونات التالية:

· كيانات RRC LteUeRrc LteEnbRrc، التي تنفذ أجهزة الدولة ل
كيانات RRC على التوالي في الاتحاد الأوروبي وeNB؛

· برامج التكيف الهيكلي في RRC LteUeRrcSapProvider, LteUeRrcSapUser, LteEnbRrcSapProvider,
LteEnbRrcSapUser، والتي تسمح لكيانات RRC بإرسال واستقبال رسائل RRC و
عناصر المعلومات؛

· فئات بروتوكول RRC LteUeRrcProtocolIdeal, LteEnbRrcProtocolIdeal,
LteUeRrcProtocolReal, LteEnbRrcProtocolReal، والتي تنفذ نموذجين مختلفين لـ
نقل رسائل RRC.

بالإضافة إلى ذلك، تستخدم مكونات RRC العديد من برامج SAPs الأخرى للتفاعل مع الباقي
من مكدس البروتوكول. يتم توفير تمثيل لجميع برامج SAP المستخدمة في
الأرقام LTE راديو بروتوكول كومة هندسة معمارية For هيه UE on هيه البيانات طائرة, LTE راديو
بروتوكول كومة هندسة معمارية For هيه UE on هيه مراقبة طائرة, LTE راديو بروتوكول كومة
هندسة معمارية For هيه eNB on هيه البيانات طائرة LTE راديو بروتوكول كومة هندسة معمارية For
هيه eNB on هيه مراقبة طائرة.

UE RRC الولايه او المحافظه تشمل
في الشكل UE RRC الولايه او المحافظه تشمل نحن نمثل جهاز الحالة كما هو مطبق في RRC UE
الكيان.
[صورة] UE RRC State Machine.UNINDENT

وتجدر الإشارة إلى أن معظم الحالات تكون عابرة، أي بمجرد دخول الاتحاد الأوروبي إلى حالته
من الحالات المتصلة، لن يعود أبدًا إلى أي من حالات الخمول. هذا الاختيار
للأسباب التالية:

· كما نوقش في القسم تصميم المعايير، محور محاكاة LTE-EPC
النموذج في وضع الاتصال

· لم يتم وضع نموذج لفشل الارتباط اللاسلكي حاليًا، كما تمت مناقشته في هذا القسم راديو الرابط
فشل، لذلك لا يمكن لUE أن يصبح خاملاً بسبب فشل الارتباط اللاسلكي

· لا يتم حاليًا إطلاق اتصال RRC مطلقًا بواسطة EPC أو NAS

ومع ذلك، اخترنا أن نصمم حالات IDLE بشكل صريح، للأسباب التالية:

· هناك حاجة إلى تكوين واقعي لـ UE RRC للتسليم، وهي ميزة مطلوبة.
ومن أجل الحصول على تنفيذ أنظف فمن المنطقي استخدام نفس UE RRC
التكوين أيضًا لإنشاء الاتصال الأولي

· يسهل تنفيذ اختيار خلية الوضع الخامل في المستقبل، وهو ما يعد أ
ميزة مرغوبة للغاية

ENB RRC الولايه او المحافظه تشمل
يحافظ eNB RRC على حالة كل وحدة مستعمل متصلة بالخلية. من
من وجهة نظر التنفيذ، يتم تضمين حالة كل UE في مثيل
فئة UeManager. يتم تمثيل آلة الدولة في الشكل ENB RRC الولايه او المحافظه تشمل For كل
UE.
[صورة] جهاز حالة ENB RRC لكل UE.UNINDENT

في البداية الموبايل اختيار
التحديد الأولي للخلية هو إجراء في وضع الخمول، يتم تنفيذه بواسطة UE عندما لا يتم ذلك بعد
معسكر أو متصل بـ eNodeB. الهدف من هذا الإجراء هو العثور على خلية مناسبة
وإرفاقه للوصول إلى الشبكة الخلوية.

ويتم ذلك عادةً في بداية المحاكاة، كما هو موضح في الشكل عينة يدير of
في البداية الخلية اختيار in UE توقيت of ذات صلة أحداث أقل. الرسم البياني للوقت على
يوضح الجانب الأيسر الحالة التي ينجح فيها الاختيار الأولي للخلية في المحاولة الأولى،
بينما الرسم البياني الموجود على الجانب الأيمن مخصص للحالة التي فشل فيها في المحاولة الأولى و
تنجح في المحاولة الثانية. يفترض التوقيت استخدام نموذج بروتوكول RRC الحقيقي (انظر RRC
بروتوكول عارضات ازياء) ولا يوجد خطأ في الإرسال.
[صورة] عينة من اختيار الخلايا الأولية في UE وتوقيت ذات الصلة
events.UNINDENT

تعتمد الوظيفة على مواصفات وضع 3GPP IDLE، كما هو الحال في [TS36300]،
[TS36304]، و[TS36331]. ومع ذلك، لا يزال التطبيق الصحيح لوضع IDLE مفقودًا
في جهاز المحاكاة، لذلك نحتفظ بعدة افتراضات مبسطة:

· تردد الناقل المتعدد غير معتمد؛

· هويات متعددة لشبكة الهاتف المحمول البرية العامة (PLMN) (أي شبكة متعددة
المشغلين) غير مدعوم؛

· لا يتم استخدام قياسات RSRQ.

· اختيار خلية المعلومات المخزنة غير معتمد.

· لا يتم دعم حالة "أي تحديد خلية" والتخييم في خلية مقبولة؛

· وضع علامة على الخلية على أنها محظورة أو محجوزة غير مدعوم؛

· إعادة اختيار الخلية غير مدعومة، وبالتالي ليس من الممكن لـ UE أن يخيم على أ
خلية مختلفة بعد وضع المعسكر الأولي؛ و

· تحتوي القائمة البيضاء لمجموعة المشتركين المغلقة (CSG) الخاصة بـ UE على هوية CSG واحدة فقط.

لاحظ أيضًا أن التحديد الأولي للخلية متاح فقط لعمليات المحاكاة التي تدعم EPC.
يجب أن تستخدم عمليات محاكاة LTE فقط طريقة المرفقات اليدوية. انظر القسم
مرفق الشبكة الثانية لوثائق المستخدم لمزيد من المعلومات حول الاختلافات بينهما
في الاستخدام.

تغطي الأقسام الفرعية التالية أجزاء مختلفة من الاختيار الأولي للخلية، وهي الخلية .,
بث of نظام معلوماتو الخلية اختيار تقييم.

الموبايل بحث
يهدف البحث عن الخلايا إلى اكتشاف الخلايا المحيطة وقياس قوة الإشارة المستقبلة
من كل خلية من هذه الخلايا. ستصبح إحدى هذه الخلايا نقطة دخول UE للانضمام إلى
شبكه خلوية.

تعتمد القياسات على RSRP الخاص بـ PSS المستلم، والتي تم حساب متوسطها بواسطة تصفية الطبقة الأولى،
ويتم تنفيذها بواسطة طبقة PHY، كما هو موضح مسبقًا بمزيد من التفاصيل في القسم UE فيز
القياسات الموديل. يتم إرسال 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 RBs.
ومع ذلك، فإن كيان PHY سيكون قادرًا على استقبال رسالة بث النظام من هذا
eNodeB على وجه الخصوص، وهو موضوع القسم الفرعي التالي.

بث of معلومات
يتم بث كتل معلومات النظام بواسطة eNodeB إلى وحدات المستعمل على فترات زمنية محددة مسبقًا،
مقتبس من القسم 5.2.1.2 من [TS36331]. كتل معلومات النظام المدعومة هي:

·

الماجستير معلومات حظر (MIB)
يحتوي على المعلمات المتعلقة بطبقة PHY، التي تم إنشاؤها أثناء الخلية
التكوين ويتم بثه كل 10 مللي ثانية في بداية إطار الراديو كـ a
رسالة التحكم.

·

معلومات حظر النوع 1 (SIB1)
يحتوي على معلومات تتعلق بالوصول إلى الشبكة، ويتم بثها كل 20 مللي ثانية على
منتصف الإطار الراديوي كرسالة تحكم. لا يستخدم في المرفقات اليدوية
طريقة. يجب أن يكون UE قد قام بفك تشفير MIB قبل أن يتمكن من استقبال SIB1.

·

معلومات حظر النوع 2 (SIB2)
يحتوي على إعدادات متعلقة بـ UL وRACH، مجدولة للإرسال عبر بروتوكول RRC
عند 16 مللي ثانية بعد تكوين الخلية، ثم يتكرر كل 80 مللي ثانية (قابل للتكوين
من خلال LteEnbRrc::SystemInformationPeriodicity يصف. يجب أن يتم تخييم UE
إلى خلية لتتمكن من استقبال SIB2 الخاص بها.

يعد استقبال معلومات النظام أمرًا أساسيًا لUE للتقدم في دورة حياته. MIB
تمكن UE من زيادة عرض النطاق الترددي DL الأولي بمقدار 6 RBs إلى التشغيل الفعلي
عرض النطاق الترددي للشبكة. يوفر SIB1 المعلومات اللازمة لاختيار الخلية
التقييم (موضح في القسم التالي). وأخيرًا، مطلوب SIB2 قبل UE
مسموح له بالتبديل إلى الحالة المتصلة.

الموبايل اختيار التقييم
يقوم UE RRC بمراجعة تقرير القياس الصادر في الموبايل بحث والوصول إلى الخلية
المعلومات المقدمة من SIB1. بمجرد توفر كلا المعلومات لخلية معينة، سيتم
UE يطلق عملية التقييم. والغرض من هذه العملية هو تحديد ما إذا كان
الخلية هي خلية مناسبة للتخييم فيها.

عملية التقييم هي نسخة مبسطة قليلاً من القسم 5.2.3.2 من [TS36304].
وتتكون من المعايير التالية:

· معيار مستوى آر إكس. و

· معيار مجموعة المشتركين المغلقة (CSG).

المعيار الأول، مستوى Rx، يعتمد على قياس RSRP Q_{rxlevmeas} للخلية، والذي
يجب أن يكون أعلى من الحد الأدنى المطلوب Q_{rxlevmin} من أجل اجتياز المعيار:

حيث يتم تحديد Q_{rxlevmin} بواسطة كل eNodeB ويمكن الحصول عليه بواسطة UE من SIB1.

المعيار الأخير، CSG، هو مزيج من معلمة صواب أو خطأ تسمى CSG
إشارة وعدد بسيط CSG هوية. القاعدة الأساسية هي أن الاتحاد الأوروبي لا يجوز له أن يعسكر
eNodeB بهوية CSG مختلفة. ولكن يتم تطبيق هذه القاعدة فقط عند الإشارة إلى CSG
يتم تقديره على أنه صحيح. يتم توفير المزيد من التفاصيل في قسم مرفق الشبكة الثاني للمستخدم
كابل بيانات.

عندما تجتاز الخلية جميع المعايير المذكورة أعلاه، تعتبر الخلية كذلك مناسب. ثم الاتحاد الأوروبي
معسكرات لها(IDLE_CAMPED_NORMALLY حالة).

بعد ذلك، قد تطلب الطبقة العليا من UE الدخول في وضع الاتصال. يرجى الرجوع إلى القسم
RRC صلة تأسيس للحصول على تفاصيل حول هذا.

من ناحية أخرى، عندما لا تمر الخلية بمعيار CSG، يتم تسمية الخلية
as مقبول (القسم 10.1.1.1 [TS36300]). في هذه الحالة، سيقوم كيان RRC بإبلاغ PHY
الكيان للمزامنة مع ثاني أقوى خلية وتكرار التحديد الأولي للخلية
الإجراء باستخدام تلك الخلية. وطالما لم يتم العثور على خلية مناسبة، فسوف يكرر UE هذه الخلايا
الخطوات مع تجنب الخلايا التي تم تحديدها على أنها مقبولة.

راديو التسجيل و القبول مراقبة
يتم دعم التحكم في دخول الراديو من خلال رد eNB RRC على اتصال RRC
رسالة طلب يرسلها تجهيزات المستعمل إما مع رسالة RRC CONNECTION SETUP أو RRC
رسالة رفض الاتصال، اعتمادًا على ما إذا كان سيتم قبول تجهيزات المستخدم الجديدة أم لا. في
في التنفيذ الحالي، يتم تحديد السلوك بواسطة السمة المنطقية
ns3::LteEnbRrc::AdmitRrcConnectionRequest. لا يوجد حاليا أي التحكم في دخول الراديو
خوارزمية تقرر ديناميكيًا ما إذا كان سيتم قبول اتصال جديد أم لا.

راديو حامل الاعداد
تم اتخاذ بعض خيارات التنفيذ في RRC فيما يتعلق بإعداد الراديو
حاملي:

· تم تكوين ثلاث مجموعات قنوات منطقية (من أصل أربع مجموعات متاحة) لتخزين الوصلة الصاعدة
لأغراض تقرير الحالة، وفقًا للسياسة التالية:

· 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 الدعم لقياسات تجهيزات المستعمل؛ على وجه الخصوص، فإنه ينفذ
الإجراءات الموضحة في القسم 5.5 من [TS36331]، مع التبسيط التالي
الافتراضات:

· لا يتم دعم سوى قياسات E-UTRA داخل التردد، مما يعني ما يلي:

· يتم استخدام كائن قياس واحد فقط أثناء المحاكاة؛

· ليست هناك حاجة إلى فجوات القياس لإجراء القياسات.

· لم يتم تنفيذ الحدث B1 وB2؛

· فقط تقرير أقوى الخلايا ويدعم الغرض، في حين تقريرCGI
تقريرأقوى الخلاياForSON الأغراض غير مدعومة؛

· قياس غير مدعومة؛

· نظرًا لأن تجميع شركات الاتصالات غير مدعوم بواسطة وحدة LTE، فما يلي
الافتراضات في قياسات UE صحيحة:

· لا يوجد مفهوم للخلية الثانوية (SCخلية);

· الخلية الأولية (PCell) يعني ببساطة خدمة الخلية؛

· لم يتم تنفيذ الحدث A6؛

· القياس المعتمد على السرعة لوقت التشغيل (القسم 5.5.6.2 من [TS36331]) ليس كذلك
أيد.

أوفرول التصميم
يعتمد النموذج على مفهوم UE قياسات مستهلك، وهو الكيان الذي يجوز
اطلب من كيان eNodeB RRC تقديم تقارير قياس UE. المستهلكون، ل
مثال، التسليم خوارزمية، والتي تحسب قرار التسليم بناءً على قياس UE
التقارير. قد تصبح حالات الاختبار وبرامج المستخدم مستهلكة أيضًا. شكل علاقة
ما بين UE قياسات انها người tiêu dùng يصور العلاقة بين هذه الكيانات.
[صورة] العلاقة بين قياسات تجهيزات المستعمل ومستهلكيها.UNINDENT

وتنقسم وظيفة قياسات تجهيزات المستعمل بأكملها على مستوى المؤتمر الإقليمي الإقليمي إلى أربعة أجزاء رئيسية:

1. تكوين القياس (يتم التعامل معه بواسطة LteUeRrc::ApplyMeasConfig)

2. إجراء القياسات (يتم التعامل معها بواسطة LteUeRrc::DoReportUeMeasurements)

3. تفعيل تقرير القياس (يتم التعامل معه بواسطة LteUeRrc::MeasurementReportTriggering)

4. تقارير القياس (يتم التعامل معها بواسطة LteUeRrc::SendMeasurementReport)

سوف تصف الأقسام التالية كل جزء من الأجزاء المذكورة أعلاه.

مقاسات ترتيب
يقوم كيان eNodeB RRC بتكوين قياسات UE عن طريق إرسال معلمات التكوين إلى
كيان UE RRC. يتم تعريف هذه المجموعة من المعلمات ضمن مياسكونفيج معلومات
العنصر (IE) لرسالة إعادة تكوين اتصال RRC (RRC صلة
انخفاض تكلفة الشحن الدولي وخدمات تتحرك).

يقوم كيان eNodeB RRC بتنفيذ معلمات وإجراءات التكوين الموضحة في
القسم 5.5.2 من [TS36331]، مع الافتراض المبسط التالي:

· التكوين (أي الإضافة والتعديل والإزالة) لا يمكن أن يتم إلا قبل
تبدأ المحاكاة؛

· جميع وحدات المستعمل المرتبطة بـ eNodeB سيتم تكوينها بنفس الطريقة، أي لا يوجد
دعم تكوين قياس محدد لتجهيزات مستعمل محددة؛ و

· من المفترض أن يكون هناك تعيين واحد لواحد بين PCI وE-UTRAN
معرف الخلية العالمية (EGCI). وهذا يتوافق مع افتراضات نمذجة PCI
موضح في UE فيز القياسات الموديل.

يعمل مثيل eNodeB RRC هنا كوسيط بين المستهلكين و
وحدات UE المرفقة. في بداية المحاكاة، يقوم كل مستهلك بتوفير eNodeB RRC
على سبيل المثال مع تكوين قياسات UE الذي يتطلبه. بعد ذلك، تم إنشاء eNodeB
يقوم RRC بتوزيع التكوين على وحدات المستعمل المرفقة.

يمكن للمستخدمين تخصيص تكوين القياس باستخدام عدة طرق. يرجى الرجوع إلى
قسم قياسات sec-configure-ue لوثائق المستخدم لوصف
هذه الأساليب.

أداء قياسات
يتلقى UE RRC قياسات RSRP وRSRQ على أساس دوري من UE PHY، كما
موضح في UE فيز القياسات الموديل. طبقة 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 هو العنصر القابل للتكوين filterCoefficent التي تقدمها
هيه تكوين الكمية;

k = 4 هي القيمة الافتراضية، ولكن يمكن تهيئتها عن طريق تعيين RsrpFilterCoefficiency
RsrqFilterCoefficiency الصفات في LteEnbRrc.

ولذلك فإن k = 0 سوف يقوم بتعطيل تصفية الطبقة الثالثة. من ناحية أخرى، يمكن للقياسات الماضية
سيتم منحها تأثيرًا أكبر على نتائج التصفية باستخدام قيمة أكبر لـ k.

مقاسات التقارير اثار
في هذا الجزء، سيستعرض UE RRC قائمة تكوينات القياس النشط و
تحقق مما إذا كان شرط التشغيل قد تم استيفاءه وفقًا للقسم 5.5.4 من
[TS36331]. عندما يكون هناك شرط واحد على الأقل من جميع القياسات النشطة
تم استيفاء التكوين، وإجراء إعداد تقرير القياس (الموصوف في الجزء التالي
القسم الفرعي) سيتم البدء فيه.

يحدد 3GPP نوعين من TriggerType: دورية على أساس الحدث. في هذه اللحظة ، فقط
يتم دعم المعيار القائم على الحدث. هناك العديد من الأحداث التي يمكن اختيارها، والتي
موصوفة بإيجاز في الجدول أدناه:

قائمة of أيد على أساس الحدث اثار المعايير
┌────────────────────────────────── ─────┐
│ الاسم │ الوصف │
├─────────┼──────────────────────── ─────┤
│الحدث A1 │ تصبح خلية الخدمة أفضل من │
│ │ عتبة │
├─────────┼──────────────────────── ─────┤
│الحدث A2 │ تصبح خلية الخدمة أسوأ من │
│ │ عتبة │
├─────────┼──────────────────────── ─────┤
│الحدث A3 │ يصبح الجار عوض ديسيبل │
│ │ أفضل من خدمة الخلية │
├─────────┼──────────────────────── ─────┤
│الحدث A4 │ يصبح الجار أفضل من │
│ │ عتبة │
└─────────┴──────────────────────── ─────┘

│الحدث A5 │ يصبح التقديم أسوأ من │
│ │ عتبة 1 لأي لبس يصبح الجار │
│ │ أفضل من عتبة 2 │
└─────────┴──────────────────────── ─────┘

هناك شرطان رئيسيان يجب التحقق منهما في المشغل المستند إلى الحدث وهما الدخول حالة
هيه مغادرة حالة. يمكن العثور على مزيد من التفاصيل حول هذين الأمرين في القسم 5.5.4 من
[TS36331].

يمكن تكوين المشغل المستند إلى الحدث بشكل أكبر من خلال تقديم التباطؤ و
وقت التشغيل. التخلفية نزعة المادة الممغنطة إلي البقاء في حالة مغناطيسية (Hys) يحدد المسافة بين الدخول والخروج
الظروف في ديسيبل. بصورة مماثلة، وقت التشغيل يقدم تأخيرًا في الدخول والخروج
الظروف، ولكن كوحدة زمنية.

تشير دورية نوع مشغل التقارير غير معتمد، ولكن سلوكه يمكن أن يكون بسهولة
تم الحصول عليها باستخدام مشغل يستند إلى الحدث. ويمكن القيام بذلك عن طريق تكوين القياس
بطريقة يتم فيها استيفاء شرط الإدخال دائمًا، على سبيل المثال، عن طريق تعيين
عتبة الحدث A1 إلى الصفر (المستوى الأدنى). ونتيجة لذلك، تقارير القياس
سيتم تشغيله دائمًا عند كل فترة زمنية محددة، وفقًا لما يحدده ReportInterval
المجال داخل LteRrcSap::ReportConfigEutra، وبالتالي إنتاج نفس السلوك كما
التقارير الدورية.

كقيد فيما يتعلق بمواصفات 3GPP، لا يدعم النموذج الحالي
أي تكوين خاص بالخلية. يتم تعريف معلمات التكوين هذه في القياس
هدف. ونتيجة لذلك، دمج قائمة الخلايا السوداء في عملية التحفيز
غير مدعومة. علاوة على ذلك، الإزاحة الخاصة بالخلية (على سبيل المثال، O_{cn} وO_{cp} في الحدث A3 وA4،
وA5) غير مدعومين أيضًا. يتم دائمًا افتراض القيمة التي تساوي الصفر بدلاً من
لهم.

مقاسات التقارير
يعالج هذا الجزء تقديم تقرير القياس من كيان UE RRC إلى
خدمة كيان eNodeB عبر بروتوكول RRC. تم اعتماد العديد من الافتراضات المبسطة:

· ReportAmount is ليس قابلة للتطبيق (أي يُفترض دائمًا أنها لا نهائية)؛

· في تقارير القياس ReportQuantity يفترض دائما أن يكون على حد سواء، أي: كلاهما
يتم دائمًا الإبلاغ عن RSRP وRSRQ، بغض النظر عن TriggerQuantity.

التسليم
يدعم نموذج RRC إمكانية تنقل UE في الوضع CONNECTED عن طريق استدعاء عملية التسليم المستندة إلى X2
إجراء. النموذج هو داخل EUTRA وداخل التردد، بناءً على القسم 10.1.2.1 من
[TS36300].

يركز هذا القسم على عملية بدء عملية التسليم. تنفيذ التسليم
يتم تناول الإجراء نفسه في القسم X2.

هناك طريقتان لبدء إجراء التسليم:

· صراحة (أو يدويًا) يتم تشغيله بواسطة برنامج المحاكاة عن طريق جدولة
تنفيذ الطريقة LteEnbRrc::SendHandoverRequest. أو

· تلقائيا يتم تشغيله بواسطة كيان eNodeB RRC استنادًا إلى قياسات UE و
وفقا لخوارزمية التسليم المحددة.

يقدم القسم sec-x2-based-handover من وثائق المستخدم بعض الأمثلة حول الاستخدام
يتم تشغيل كل من عمليات التسليم الصريحة والتلقائية في المحاكاة. القسم الفرعي التالي سوف
قم بإلقاء نظرة فاحصة على الطريقة التلقائية، من خلال وصف جوانب التصميم الخاصة بها
واجهة خوارزمية التسليم وخوارزميات التسليم المتاحة.

التسليم خوارزمية
يتمتع التسليم في 3GPP LTE بالخصائص التالية:

·

بمساعدة UE
ويوفر تجهيزات المستعمل المدخلات إلى الشبكة في شكل تقارير قياس. هذا
يتم التعامل معه بواسطة UE RRC القياسات الموديل.

·

تسيطر عليها الشبكة
تقرر الشبكة (أي eNodeB المصدر وeNodeB المستهدف) متى يتم ذلك
إطلاق عملية التسليم والإشراف على تنفيذها.

تشير سلم خوارزمية يعمل في eNodeB المصدر ويكون مسؤولاً عن عملية التسليم
القرارات بطريقة "تلقائية". يتفاعل مع مثيل eNodeB RRC عبر
التسليم الإدارة SAP واجهه المستخدم. هذه العلاقات موضحة في الشكل
علاقة ما بين UE قياسات انها người tiêu dùng من القسم السابق.

تتكون واجهة خوارزمية التسليم من الطرق التالية:

·

AddUeMeasReportConfigForHandover
(خوارزمية التسليم -> eNodeB RRC) تستخدمها خوارزمية التسليم للطلب
تقارير القياس من كيان eNodeB RRC، وذلك بتمرير المطلوب
تكوين التقارير. سيتم تطبيق التكوين على كل المستقبل
وحدات UE المرفقة.

·

تقريرUeMeas
(eNodeB RRC -> خوارزمية التسليم) بناءً على قياسات UE التي تم تكوينها
في وقت سابق AddUeMeasReportConfigForHandover، قد يقدم UE تقارير القياس
إلى eNodeB. يستخدم كيان eNodeB RRC تقريرUeMeas واجهة ل
قم بإرسال تقارير القياس هذه إلى خوارزمية التسليم.

·

TriggerHandover
(خوارزمية التسليم -> eNodeB RRC) بعد فحص تقارير القياس
(ولكن ليس بالضرورة)، قد تعلن خوارزمية التسليم عن عملية تسليم. هذا
يتم استخدام الطريقة لإخطار كيان eNodeB RRC بهذا القرار، والذي سيتم
ثم انتقل لبدء إجراءات التسليم.

ملاحظة واحدة ل AddUeMeasReportConfigForHandover. سوف تقوم الطريقة بإرجاع measId
(هوية القياس) لتكوين القياس المنشأ حديثًا. عادة أ
ستقوم خوارزمية التسليم بتخزين هذا الرقم الفريد. قد يكون من المفيد في تقريرUeMeas
الطريقة، على سبيل المثال عندما يتم طلب أكثر من تكوين واحد والتسليم
تحتاج الخوارزمية إلى التمييز بين التقارير الواردة بناءً على التكوين الذي
أثارتهم.

يتم تنفيذ خوارزمية التسليم عن طريق كتابة فئة فرعية من LteHandoverAlgorithm
مجردة الطبقة الفائقة وتنفيذ كل من أساليب واجهة SAP المذكورة أعلاه.
يمكن للمستخدمين تطوير خوارزمية التسليم الخاصة بهم بهذه الطريقة، ثم استخدامها في أي محاكاة
باتباع الخطوات الموضحة في القسم sec-x2-based-handover الخاص بالمستخدم
كابل بيانات.

وبدلاً من ذلك، يمكن للمستخدمين اختيار استخدام إحدى خوارزميات التسليم الثلاثة المضمنة المتوفرة
بواسطة وحدة LTE: no-op، A2-A4-RSRQ، وأقوى خوارزمية تسليم الخلايا. هم
جاهزة للاستخدام في عمليات المحاكاة أو يمكن اعتبارها مثالاً على تنفيذ عملية التسليم
خوارزمية. يتم تناول كل من هذه الخوارزميات المضمنة في كل مما يلي
الأقسام الفرعية.

لا المرجع سلم خوارزمية
تشير لا مرجع سلم خوارزمية (NoOpHandoverAlgorithm class) هو أبسط ما يمكن
تنفيذ خوارزمية التسليم. وهو في الأساس لا يفعل شيئًا، أي لا يتصل بأي شيء
لأساليب واجهة إدارة التسليم SAP. يمكن للمستخدمين اختيار خوارزمية التسليم هذه
إذا كانوا يرغبون في تعطيل مشغل التسليم التلقائي في المحاكاة الخاصة بهم.

A2-A4-RSRQ سلم خوارزمية
تشير A2-A4-RSRQ سلم خوارزمية يوفر وظيفة التسليم الافتراضي
تم تضمين الخوارزمية في الأصل في LENA M6 (ns-3.18)، وتم نقلها إلى Handover Management SAP
واجهة مثل A2A4RsrqHandoverAlgorithm فئة.

كما يوحي الاسم، تستخدم الخوارزمية جودة الإشارة المستلمة (RSRQ)
القياسات المكتسبة من الحدث A2 والحدث A4. وبالتالي، ستضيف الخوارزمية 2
تكوين القياس لمثيل eNodeB RRC المقابل. استخدامها المقصود هو
الموصوفة على النحو التالي:

· الحدث/الفعالية A2 (تصبح خدمة RSRQ للخلية أسوأ من عتبة) مرفوع للإشارة
أن تجهيزات المستعمل تعاني من ضعف جودة الإشارة وقد تستفيد من عملية التسليم.

· الحدث/الفعالية A4 (يصبح RSRQ للخلية المجاورة أفضل من عتبة) يستخدم للكشف
الخلايا المجاورة والحصول على RSRQ المقابلة لها من كل UE المرفقة، والتي
ثم يتم تخزينها داخليًا بواسطة الخوارزمية. بشكل افتراضي، يتم تكوين الخوارزمية
الحدث A4 ذو عتبة منخفضة جدًا، بحيث تكون معايير التشغيل صحيحة دائمًا.

الشكل A2-A4-RSRQ سلم خوارزمية أدناه يلخص هذا الإجراء.
[صورة] خوارزمية تسليم A2-A4-RSRQ.UNINDENT

يمكن تعيين سمتين لضبط سلوك الخوارزمية:

·

عتبة خدمة الخلية
تشير عتبة وبالنسبة للحدث A2، أي يجب أن يكون لتجهيزات المستعمل رقم RSRQ أقل من هذا
الحد الذي يجب النظر فيه للتسليم.

·

NeighbourCellOffset
تشير عوض يهدف إلى ضمان حصول تجهيزات المستعمل (UE) على جودة إشارة أفضل
بعد التسليم. تعتبر الخلية المجاورة بمثابة خلية مستهدفة لل
يتم التسليم فقط إذا كان RSRQ الخاص به أعلى من RSRQ الخاص بخلية العرض بالمبلغ
من هذا عوض.

يتم التعبير عن قيمة كلتا السمتين كنطاق RSRQ (القسم 9.1.7 من [TS36133])،
وهو عدد صحيح بين 0 و34، مع 0 كأدنى RSRQ.

أقوى الخلية سلم خوارزمية
تشير أقوى الخلية سلم خوارزمية، أو يُعرف أيضًا أحيانًا باسم تقليدي قوة
ميزانية (ببغت) خوارزميةتم تطويره باستخدام [Dimou2009] كمرجع. الفكرة هي أن
تزويد كل تجهيزات مستعمل بأفضل قدرة ممكنة على استقبال الإشارة المرجعية (RSRP). هذا هو
يتم ذلك عن طريق إجراء عملية التسليم بمجرد وجود خلية أفضل (أي مع RSRP أقوى).
الكشف.

الحدث/الفعالية A3 (يصبح RSRP للخلية المجاورة أفضل من RSRP للخلية التي تخدم) تم اختياره
تحقيق هذا المفهوم. ال A3RsrpHandoverAlgorithm الطبقة هي نتيجة
تطبيق. يتم تشغيل التسليم لUE إلى أفضل خلية في القياس
تقرير.

عادةً ما تكون المحاكاة التي تستخدم هذه الخوارزمية أكثر عرضة لتسليم كرة الطاولة
(التسليم المتتالي إلى المصدر السابق eNodeB خلال فترة زمنية قصيرة)،
خاصة عندما ذبول الموديل تم تمكينه. عادة ما يتم التعامل مع هذه المشكلة عن طريق
تقديم تأخير معين للتسليم. تقوم الخوارزمية بذلك عن طريق تضمين
معلمات التباطؤ ووقت التشغيل (القسم 6.3.5 من [TS36331]) إلى تجهيزات المستعمل
تكوين القياسات

التخلفية نزعة المادة الممغنطة إلي البقاء في حالة مغناطيسية (المعروف أيضًا باسم هامش التسليم) يؤخر التسليم فيما يتعلق بـ 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 أقوى الخلية سلم خوارزمية أدناه، الذي يؤخذ
من تدابير التسليم لينا-x2 مثال. إنه يصور RSRP المتصور لخلية الخدمة
وخلية مجاورة بواسطة UE والتي تتحرك عبر حدود الخلايا.
[صورة] تأثير التباطؤ وزمن التشغيل في أقوى عملية تسليم للخلايا
خوارزمية.UNINDENT

افتراضيًا، تستخدم الخوارزمية تباطؤًا قدره 3.0 ديسيبل ووقت التشغيل 256 مللي ثانية.
يمكن ضبط هذه القيم من خلال التخلفية نزعة المادة الممغنطة إلي البقاء في حالة مغناطيسية TimeToTrigger سمات
A3RsrpHandoverAlgorithm فئة.

الجيران علاقة
تدعم وحدة LTE طريقة مبسطة أوتوماتيك الجيران علاقة وظيفة (ANR). هذا هو
التعامل معها من قبل LteAnr فئة تتفاعل مع مثيل eNodeB RRC من خلال ANR
واجهة ساب.

الجيران علاقة طاولات ومكاتب
ANR يحمل أ الجيران علاقة طاولات ومكاتب (NRT)، على غرار الوصف في القسم
22.3.2a من [TS36300]. كل إدخال في الجدول يسمى أ الجيران علاقة (ن ر) و
يمثل خلية مجاورة تم اكتشافها، والتي تحتوي على الحقول المنطقية التالية:

·

لا حذف
يشير إلى أن NR يجب ليس تتم إزالته من NRT. هذا هو صحيح by
الافتراضي لـ NR المقدمة من قبل المستخدم و زائف غير ذلك.

·

لا X2 يشير إلى أن NR يجب ليس استخدم واجهة X2 للبدء
إجراءات تجاه eNodeB لتربية الخلية المستهدفة. هذا هو زائف by
الافتراضي لNR المقدمة من قبل المستخدم، و صحيح غير ذلك.

·

لا HO يشير إلى أن NR يجب ليس يمكن استخدامها بواسطة eNodeB لأسباب تتعلق بالتسليم.
هذا هو صحيح في معظم الحالات، إلا عندما يكون NR مقدمًا من قبل المستخدم و
تم الكشف عن الشبكة.

قد يحتوي كل إدخال NR على واحدة على الأقل من الخصائص التالية:

·

المقدمة من قبل المستخدم
يتم إنشاء هذا النوع من NR وفقًا لتعليمات مستخدم المحاكاة. على سبيل المثال،
يتم إنشاء NR تلقائيًا عند إنشاء X2 بواسطة المستخدم
الاتصال بين 2 eNodeBs، على سبيل المثال كما هو موضح في القسم
التسليم المستند إلى sec-x2. هناك طريقة أخرى لإنشاء NR مقدم من المستخدم وهي استدعاء
AddNeighbourRelation وظيفة صراحة.

·

تم اكتشاف الشبكة
يتم إنشاء هذا النوع من NR تلقائيًا أثناء المحاكاة نتيجة لـ
اكتشاف خلية قريبة.

من أجل إنشاء NR المكتشف عبر الشبكة تلقائيًا، يستخدم ANR قياسات تجهيزات المستعمل. في
وبعبارة أخرى، ANR هو مستهلك لقياسات UE، كما هو مبين في الشكل علاقة
ما بين UE قياسات انها người tiêu dùng. RSRQ والحدث A4 (يصبح الجار أفضل
من عتبة) يتم استخدامها لتكوين التقارير. الحدث الافتراضي A4 عتبة
تم ضبطه على أدنى مستوى ممكن، أي الحد الأقصى لقدرة الكشف، ولكن يمكن تغييره
وضع عتبة سمة من سمات LteAnr فصل. لاحظ أن تسليم A2-A4-RSRQ
تستخدم الخوارزمية أيضًا تكوينًا مشابهًا لإعداد التقارير. رغم التشابه متى
كل من ANR وخوارزمية التسليم هذه نشطة في eNodeB، ويستخدمان تقارير منفصلة
ترتيب.

لاحظ أيضًا أن الإعداد التلقائي لواجهة X2 غير مدعوم. هذا هو السبب
هيه لا X2 لا HO تكون الحقول صحيحة في NR الذي تم اكتشافه بواسطة الشبكة ولكن لم يتم اكتشافه بواسطة المستخدم.

النوع of ANR in محاكاة
توفر واجهة ANR SAP وسيلة اتصال بين ANR وeNodeB RRC. بعض
يتم استخدام وظائف الواجهة بواسطة eNodeB RRC للتفاعل مع NRT، كما هو موضح أدناه:

·

AddNeighbourRelation
(eNodeB RRC -> ANR) قم بإضافة إدخال NR جديد مقدم من المستخدم إلى NRT.

·

GetNoRemove
(eNodeB RRC -> ANR) احصل على قيمة لا حذف مجال إدخال NR لـ
معرف الخلية المحدد.

·

GetNoHo
(eNodeB RRC -> ANR) احصل على قيمة لا HO مجال إدخال NR للمعطى
معرف الخلية.

·

GetNoX2
(eNodeB RRC -> ANR) احصل على قيمة لا X2 مجال إدخال NR للمعطى
معرف الخلية.

توجد وظائف واجهة أخرى لدعم دور ANR كمستهلك لقياسات تجهيزات المستعمل،
كما هو موضح أدناه:

·

AddUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) يستخدم بواسطة ANR لطلب تقارير القياس من
كيان eNodeB RRC، عن طريق تمرير تكوين التقارير المطلوب. ال
سيتم تطبيق التكوين على كافة وحدات المستعمل المرفقة في المستقبل.

·

تقريرUeMeas
(eNodeB RRC -> ANR) استنادًا إلى قياسات UE التي تم تكوينها مسبقًا
AddUeMeasReportConfigForAnr، قد يقدم UE تقارير القياس إلى eNodeB.
يستخدم كيان eNodeB RRC تقريرUeMeas واجهة لإعادة توجيه هذه
تقارير القياس إلى ANR.

يرجى الرجوع إلى وثائق API المقابلة لـ LteAnrSap فئة لمزيد من التفاصيل
على الاستخدام والمعلمات المطلوبة.

يتم استخدام ANR بواسطة مثيل eNodeB RRC كبنية بيانات لتتبع
حالة الخلايا المجاورة القريبة. يدعم ANR أيضًا مثيل eNodeB RRC
تحديد ما إذا كان من الممكن تنفيذ إجراء التسليم إلى خلية مجاورة.
يتم تحقيق ذلك من خلال حقيقة أن eNodeB RRC لن يسمح إلا بإجراء التسليم
يحدث إذا كان إدخال NR للخلية المستهدفة يحتوي على كليهما لا HO لا X2 الحقول المحددة ل زائف.

يتم تمكين ANR افتراضيًا في كل مثيل eNodeB في المحاكاة. يمكن تعطيله
عن طريق ضبط AnrEnabled السمة في LteHelper الفئة الى زائف.

RRC تسلسل الرسوم البيانية
نقدم في هذا القسم بعض المخططات التسلسلية التي تشرح أهم RRC
الإجراءات التي يتم نمذجةها.

RRC صلة تأسيس
الشكل تسلسل رسم بياني of هيه 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 │ │ الاتصال │ الاتصال │ │ │
│ الموقت) │ │ طلب │ الإعداد أو │ │ │
│ │ │ │ رفض │ │ │
├─────────────┼──────────────────── ──────┼─── ───────────┼──────────┼──────────── ─┤
│ اتصال │ eNodeB RRC │ إرسال RRC │ تلقي RRC │ 100 مللي ثانية │ إزالة UE │
│ مهلة الإعداد │ │ الاتصال │ الاتصال │ │ السياق │
│ │ │ الإعداد │ اكتمال الإعداد │ │ │
├─────────────┼──────────────────── ──────┼─── ───────────┼──────────┼──────────── ─┤
│ الاتصال │ eNodeB RRC │ إرسال RRC │ أبدًا │ 30 مللي ثانية │ إزالة UE │
│ مرفوض │ │ اتصال │ │ │ سياق │
│مهلة │ │ رفض │ │ │ │
└─────────────┴──────────────────── ──────┴─── ───────────┴──────────┴──────────── ─┘

RRC صلة انخفاض تكلفة الشحن الدولي وخدمات تتحرك
الشكل تسلسل رسم بياني of هيه RRC الاتصال إعادة تشكيل الإجراءات يظهر كيف أن RRC
تم تصميم إجراء إعادة تكوين الاتصال للحالة التي يكون فيها MobilityControlInfo موجودًا
لم يتم توفيرها، أي لم يتم تنفيذ التسليم.
[صورة] مخطط تسلسلي لإجراء إعادة تكوين اتصال RRC.UNINDENT

الشكل تسلسل رسم بياني of هيه RRC الاتصال إعادة تشكيل الإجراءات For هيه سلم
حقيبة يوضح كيفية تصميم إجراء إعادة تكوين اتصال RRC للحالة
حيث يتم توفير MobilityControlInfo، أي أنه سيتم إجراء التسليم. كما هو محدد
في [TS36331]، بعد يستلم هيه سلم رسالة، هيه UE محاولات إلى الوصول هيه الهدف
الخلية at هيه أول متاح راش مناسبة بالنسبة الى إلى عشوائية استخدم مورد اختيار
تعريف in [TS36321]_، أي هيه سلم is غير متزامن. وبناء على ذلك، متى تخصيص
a مخصصة مقدمة For هيه عشوائية الوصول in هيه الهدف زنزانة، E-UTRA سوف ضمان it is
متاح تبدأ من هيه أول راش مناسبة هيه UE قد استخدام. بناء على ناجح إكمال of هيه
سلم، هيه UE يرسل a الرسالة مستعمل إلى تؤكد هيه سلم. لاحظ أن العشوائية
إجراء الوصول في هذه الحالة لا يعتمد على التنافس، وبالتالي في نظام LTE الحقيقي
يختلف قليلاً عن ذلك المستخدم في اتصال RRC. لاحظ أيضًا أن RA
تتم الإشارة إلى معرف الديباجة عبر أمر التسليم المضمن في طلب تسليم X2
يتم إرسال رسالة ACK من eNB الهدف إلى eNB المصدر؛ على وجه الخصوص، الديباجة هي
تم تضمينه في RACH-ConfigDedicated IE والذي يعد جزءًا من 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 وعناصر المعلومات (IEs) المحددة في [TS36331]. بعض
يتم التبسيط فيما يتعلق بـ IEs المضمنة في PDU، أي تلك فقط
يتم تضمين عناصر IE المفيدة لأغراض المحاكاة. للحصول على قائمة مفصلة، ​​من فضلك
راجع IEs المحددة في lte-rrc-sap.h وقارن مع [TS36331].

· يتم إرسال وحدات PDU المشفرة لـ RRC على حوامل راديو الإشارة وتخضع لذلك
نمذجة الإرسال المستخدمة لاتصالات البيانات، بما في ذلك الجدولة والراديو
استهلاك الموارد، وأخطاء القناة، والتأخير، وإعادة الإرسال، وما إلى ذلك.

يشير راديو حامل نموذج
نحن الآن نصف نموذج حامل راديو الإشارة المستخدم في لابيلا ريال بروتوكول RRC
نموذج.

· ريال سعودي 0 الرسائل (عبر CCCH):

· طلب RrcConnectionRequest: في أنظمة LTE الحقيقية، يتم إرسال RLC TM SDU
الموارد المحددة في منحة UL في 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).

· ريال سعودي 1 الرسائل (عبر DCCH):

· جميع رسائل SRB1 المصممة في جهاز المحاكاة (على سبيل المثال، اكتمل RrcConnection) هي
يتم تنفيذه كما هو الحال في أنظمة LTE الحقيقية، أي مع RLC SDU حقيقي يتم إرساله عبر RLC AM
باستخدام موارد DL المخصصة عبر تقارير حالة المخزن المؤقت. انظر نموذج RLC
وثائق للحصول على التفاصيل.

· ريال سعودي 2 الرسائل (عبر DCCH):

· وفقًا لـ [TS36331]، "ريال سعودي 1 is For RRC رسائل (التي قد تتضمن a
على ظهره NAS الرسالة) as حسنا as For NAS رسائل قبل إلى هيه تأسيس
of إس آر بي 2، الكل استخدام DCCH منطقي قناة"، بينما "ريال سعودي 2 is For NAS الرسائل،
استخدام DCCH منطقي قناة"و"ريال سعودي 2 لديها a أولوية أقل من ريال سعودي 1 is
دائما تكوين by إي-أوتران بعد أمن تفعيل". النمذجة
الجوانب المتعلقة بالأمن ليست من متطلبات نموذج محاكاة LTE،
ومن ثم فإننا نستخدم SRB1 دائمًا ولا نقوم بتنشيط SRB2 أبدًا.

ASN.1 ترميز of RRC أي
يتم نقل الرسائل المحددة في RRC SAP، المشتركة بين جميع مستخدمي/مقدمي خدمات Ue/Enb SAP
في حاوية شفافة من/إلى Ue/Enb. تنسيق الترميز لمختلف
تم تحديد عناصر المعلومات في [TS36331]، باستخدام قواعد ASN.1 في الوضع غير المحاذي
البديل. تم تقسيم التنفيذ في Ns3/Lte إلى الفئات التالية:

· Asn1Header: يحتوي على ترميز/فك تشفير أنواع ASN الأساسية

· RrcAsn1Header: يرث Asn1Header ويحتوي على ترميز/فك تشفير شائع
تم تعريف IE في [TS36331]

· رسائل RRC محددة/فئات IEs: فئة لكل رسالة من الرسائل المحددة في RRC
رأس ساب

Asn1Header فئة - تطبيق of قاعدة ASN.1 أنواع
تطبق هذه الفئة طرق إجراء تسلسل/إلغاء تسلسل أنواع ASN.1 المستخدمة فيها
[TS36331]، وفقًا لقواعد التشفير المضمنة في ITU-T X.691. الأنواع المعتبرة
هي:

· منطقية : تستخدم القيمة المنطقية بت واحد (1 = صحيح، 0 = خطأ).

· عدد صحيح : عدد صحيح مقيد (مع تحديد الحد الأدنى والحد الأقصى للقيم) يستخدم الحد الأدنى
كمية البتات اللازمة لتشفير مداها (الحد الأقصى-الدقيقة+1).

· سلسلة البت : سيتم نسخ سلسلة البت شيئا فشيئا إلى المخزن المؤقت للتسلسل.

· Octetstring: غير مستخدم حالياً.

· التسلسل : ينشأ عن التسلسل تمهيد يدل على وجود اختياري و
الحقول الافتراضية. كما أنه يضيف قليلاً يشير إلى وجود علامة الامتداد.

· تسلسل...من: تسلسل...من النوع يشفر عدد عناصر التسلسل
كعدد صحيح (يجب تشفير العناصر اللاحقة بعد ذلك).

· الاختيار: يشير إلى العنصر الذي يتم ترميزه من بين العناصر الموجودة في مجموعة الاختيار.

· التعداد : يتم تسلسله كعدد صحيح يشير إلى القيمة المستخدمة بين
تلك الموجودة في التعداد، مع عدد العناصر في التعداد في الأعلى
مقيد.

· Null: القيمة الخالية لم يتم ترميزها، على الرغم من أن وظيفة التسلسل الخاصة بها محددة
لتوفير خريطة أوضح بين المواصفات والتنفيذ.

ترث الفئة من رأس ns-3، ولكن تم إعلان وظيفة Deserialize () افتراضية خالصة،
وبالتالي ورثت الطبقات الحاجة إلى تنفيذها. والسبب هو أن إلغاء التسلسل سوف
استرداد العناصر الموجودة في رسائل RRC، والتي يحتوي كل منها على معلومات مختلفة
العناصر.

بالإضافة إلى ذلك، تجدر الإشارة إلى أن طول البايت الناتج لنوع/رسالة معينة
يمكن أن تختلف وفقًا لوجود الحقول الاختيارية وبسبب التشفير الأمثل.
وبالتالي، ستتم معالجة البتات المتسلسلة باستخدام وظيفة PreSerialize()، مما يؤدي إلى حفظ البيانات
يؤدي إلى m_serializationResult Buffer. كما هي طرق القراءة/الكتابة في المخزن المؤقت ns3
المحددة على أساس البايت، يتم تخزين بتات التسلسل في m_serializationPendingBits
السمة، حتى يتم تعيين 8 بتات ويمكن كتابتها إلى مكرر المخزن المؤقت. واخيرا متى
باستدعاء Serialize()، سيتم نسخ محتويات السمة m_serializationResult
إلى المعلمة Buffer::Iterator

RrcAsn1Header : مشترك آي إي
نظرًا لاستخدام بعض عناصر المعلومات في العديد من رسائل RRC، فإن هذه الفئة
تنفذ IE المشتركة التالية:

· SrbToAddModList

· DrbToAddModList

· تكوين القناة المنطقية

· RadioResourceConfigDedicated

· التكوين الفيزيائي المخصص

· SystemInformationBlockType1

· SystemInformationBlockType2

· RadioResourceConfigCommonSIB

RRC محدد الرسائل/IEs فصول
تم تنفيذ RRC SAP التالية:

· طلب RrcConnectionRequest

· RrcConnectionSetup

· اكتمل RrcConnectionSetup

· RrcConnectionReconfiguration

· اكتمل RrcConnectionReconfiguration

· معلومات الاستعداد للتسليم

· RrcConnectionRestitutementRequest

· إعادة تأسيس RrcConnection

· RrcConnectionRetitutionmentComplete

· RrcConnectionRetitutionmentReject

· RrcConnectionRelease

NAS
ينصب تركيز نموذج LTE-EPC على حالة NAS النشطة، والتي تتوافق مع EMM
مسجل، ومتصل بـ ECM، ومتصل بـ RRC. ولهذا السبب ما يلي
يتم إجراء التبسيطات:

· لم يتم تصميم EMM وECM بشكل صريح؛ وبدلاً من ذلك، سيقوم كيان NAS في UE بذلك
التفاعل مباشرة مع MME لأداء الإجراءات المكافئة (مع الإجمالي
التبسيط) لأخذ تجهيزات المستعمل إلى حالتي EMM Connected وECM Connected؛

· يعتني NAS أيضًا بتعدد إرسال حزم بيانات الوصلة الصاعدة القادمة من الجزء العلوي
طبقات في حامل EPS المناسب باستخدام مصنف قالب تدفق حركة المرور
(TftClassifier).

· لا تدعم NAS اختيار PLMN وCSG

· لا يدعم NAS أي إجراء لتحديث/ترحيل الموقع في وضع الخمول

الشكل تسلسل رسم بياني of هيه يرفق الإجراءات يوضح كيفية عمل نموذج NAS المبسط
ينفذ الإجراء المرفق. لاحظ أن كلا من EPS الافتراضي والمخصص في نهاية المطاف
يتم تنشيط حامليها كجزء من هذا الإجراء.
[صورة] مخطط تسلسلي لإجراء الإرفاق.UNINDENT

S1
S1-U
تم تصميم واجهة S1-U بطريقة واقعية من خلال تغليف حزم البيانات
GTP/UDP/IP، كما هو الحال في أنظمة LTE-EPC الحقيقية. يتم عرض مكدس البروتوكول المقابل في
الشكل LTE-EPC البيانات طائرة بروتوكول كومة. كما هو موضح في الشكل، هناك نوعان مختلفان
طبقات شبكات IP. الطبقة الأولى هي الطبقة الممتدة من طرف إلى طرف، والتي توفر طبقة من طرف إلى طرف
الاتصال بالمستخدمين؛ تتضمن هذه الطبقات وحدات UE وPGW والمضيف البعيد
(بما في ذلك أجهزة توجيه الإنترنت والمضيفات بينهما)، ولكنها لا تشمل eNB.
افتراضيًا، يتم تعيين عنوان IPv4 عام لوحدات المستعمل في شبكة 7.0.0.0/8، وPGW
يحصل على العنوان 7.0.0.1، والذي تستخدمه جميع وحدات المستعمل كبوابة للوصول إلى الإنترنت.

الطبقة الثانية من شبكات IP هي شبكة المنطقة المحلية EPC. وهذا يشمل جميع eNB
العقد وعقدة SGW/PGW. يتم تنفيذ هذه الشبكة كمجموعة من الروابط من نقطة إلى نقطة
والتي تربط كل eNB بعقدة SGW/PGW؛ وبالتالي، فإن SGW/PGW لديه مجموعة من
أجهزة من نقطة إلى نقطة، يوفر كل منها إمكانية الاتصال بشبكة eNB مختلفة. بشكل افتراضي، أ
10.xyz/30 يتم تعيين الشبكة الفرعية لكل رابط من نقطة إلى نقطة (الشبكة الفرعية /30 هي الأصغر
شبكة فرعية تسمح بعنوانين مضيفين مختلفين).

كما هو محدد بواسطة 3GPP، يتم توجيه اتصالات IP من طرف إلى طرف عبر EPC IP المحلي
الشبكة باستخدام GTP/UDP/IP. وفي ما يلي، نوضح كيفية تنفيذ هذا النفق
في نموذج EPC. ويتم الشرح من خلال مناقشة التدفق الشامل للبيانات
الحزم.
[صورة] تدفق البيانات في الوصلة الهابطة بين الإنترنت وUE.UNINDENT

في البداية، سننظر في حالة الوصلة الهابطة، الموضحة في الشكل البيانات
تدفق in هيه الهابطة ما بين هيه الإنترنت هيه UE. حزم الوصلة الهابطة Ipv4 هي
تم إنشاؤها من مضيف بعيد عام، وموجهة إلى أحد أجهزة UE. إنترنت
سيهتم التوجيه بإعادة توجيه الحزمة إلى NetDevice العام الخاص بـ SGW/PGW
العقدة المتصلة بالإنترنت (هذه هي واجهة Gi وفقًا لـ 3GPP
المصطلح). يحتوي SGW/PGW على VirtualNetDevice الذي تم تعيين عنوان IP للبوابة
عنوان الشبكة الفرعية لUE؛ ومن ثم، فإن قواعد التوجيه الثابتة ستتسبب في ظهور الحزمة الواردة
من الإنترنت ليتم توجيهها من خلال VirtualNetDevice هذا. يبدأ هذا الجهاز
إجراء نفق GTP/UDP/IP، عن طريق إعادة توجيه الحزمة إلى تطبيق مخصص في
عقدة SGW/PGW والتي تسمى EpcSgwPgwApplication. هذا التطبيق يقوم
العمليات التالية:

1. يحدد عقدة eNB التي يتصل بها UE، من خلال النظر إلى IP
عنوان الوجهة (وهو عنوان UE)؛

2. يقوم بتصنيف الحزمة باستخدام قوالب تدفق حركة المرور (TFTs) لتحديدها
حامل 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

تم توضيح حالة الوصلة الصاعدة في الشكل البيانات تدفق in هيه الإرسال ما بين هيه UE
هيه الإنترنت. يتم إنشاء حزم IP للوصلة الصاعدة بواسطة تطبيق عام داخل UE،
ويتم توجيهه بواسطة مكدس TCP/IP المحلي إلى LteUeNetDevice الخاص بـ UE. ال
ثم يقوم LteUeNetDevice بتنفيذ العمليات التالية:

1. يقوم بتصنيف الحزمة باستخدام TFTs وتحديد حامل الراديو الذي سيتم نقله إليه
تنتمي الحزمة (والمعرف RBID المقابل)؛

2. يحدد مثيل بروتوكول PDCP المقابل، وهو نقطة الدخول
ومكدس بروتوكول راديو LTE لهذه الحزمة؛

3. يرسل الحزمة إلى eNB عبر مكدس بروتوكول راديو LTE.

يتلقى 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. يرسل الحزمة إلى عقدة SGW/PGW عبر مقبس UDP المتصل بـ S1-U
جهاز شبكة من نقطة إلى نقطة.

عند هذه النقطة، تحتوي الحزمة على رؤوس S1-U IP وUDP وGTP بالإضافة إلى ملف
رأس IP الأصلي من طرف إلى طرف. عندما يتم استلام الحزمة بواسطة S1-U المقابل
NetDevice من نقطة إلى نقطة لعقدة SGW/PGW، يتم تسليمه محليًا (باعتباره الوجهة
يتطابق عنوان رأس IP الأقصى مع عنوان جهاز الشبكة من نقطة إلى نقطة).
ستقوم عملية التسليم المحلية بإعادة توجيه الحزمة إلى EpcSgwPgwApplication عبر
مقبس UDP المقابل. يقوم EpcSgwPgwApplication بعد ذلك بإزالة رأس GTP وإعادة توجيهه
الحزمة إلى VirtualNetDevice. عند هذه النقطة، يكون الرأس الخارجي للحزمة هو
رأس IP من طرف إلى طرف. ومن ثم، إذا كان عنوان الوجهة داخل هذا الرأس بعيدًا
المضيف على الإنترنت، يتم إرسال الحزمة إلى الإنترنت عبر NetDevice المقابل
من SGW/PGW. في حالة توجيه الحزمة إلى UE آخر، فإن مكدس IP الخاص بـ
سيقوم SGW/PGW بإعادة توجيه الحزمة مرة أخرى إلى VirtualNetDevice، وسوف تنتقل الحزمة
من خلال عملية تسليم الوصلة الهابطة من أجل الوصول إلى وجهتها UE.

لاحظ أن جودة خدمة EPS Bearer لا يتم فرضها على الوصلات S1-U، ومن المفترض أن
يعد التوفير الزائد لعرض النطاق الترددي للارتباط كافيًا لتلبية متطلبات جودة الخدمة للجميع
حملة.

S1AP
توفر واجهة S1-AP تفاعل مستوى التحكم بين eNB وMME. في ال
محاكاة، تم تصميم هذه الواجهة بطريقة مثالية، مع التفاعل المباشر بين
كائنات eNB وMME، دون التنفيذ الفعلي لتشفير رسائل S1AP
وعناصر المعلومات المحددة في [TS36413] ودون إرسال أي وحدة PDU فعليًا
على أي رابط.

العناصر الأولية S1-AP التي تم تصميمها هي:

· رسالة UE الأولية

· طلب إعداد السياق الأولي

· الاستجابة الأولية لإعداد السياق

· طلب تبديل المسار

· الاعتراف بطلب تبديل المسار

X2
تربط واجهة X2 بين اثنين من وحدات eNB [TS36420]. من وجهة نظر منطقية، X2
الواجهة هي واجهة من نقطة إلى نقطة بين eNBs. في E-UTRAN حقيقي،
يجب أن تكون الواجهة المنطقية من نقطة إلى نقطة ممكنة حتى في حالة عدم وجود واجهة فعلية
اتصال مباشر بين اثنين من eNBs. في نموذج X2 المطبق في جهاز المحاكاة، تم
واجهة X2 عبارة عن رابط من نقطة إلى نقطة بين جهازي eNBs. جهاز نقطة إلى نقطة هو
تم إنشاؤها في كل من eNBs ويتم توصيل جهازي نقطة إلى نقطة بجهاز نقطة إلى نقطة
الرابط.

للحصول على تمثيل لكيفية تناسب واجهة X2 مع البنية العامة لـ LENA
نموذج المحاكاة، تتم إحالة القارئ إلى الشكل نظرة عامة of هيه LTE-EPC محاكاة
نموذج.

توفر واجهة X2 المطبقة في جهاز المحاكاة تنفيذًا تفصيليًا لـ
اتباع الإجراءات الأولية لوظيفة إدارة التنقل [TS36423]:

· إجراءات طلب التسليم

· إجراءات تسليم طلب الإقرار

· إجراء نقل حالة SN

· إجراء إصدار سياق UE

يتم تضمين هذه الإجراءات في عملية التسليم المستندة إلى X2. يمكنك العثور على التفاصيل
وصف التسليم في القسم 10.1.2.1 من [TS36300]. نلاحظ أن جهاز محاكاة
يدعم النموذج حاليًا فقط سلس سلم كما هو محدد في القسم 2.6.3.1 من
[سيسيا 2009]؛ بخاصة، ضياع سلم كما هو موضح في القسم 2.6.3.2 من
[Sesia2009] غير مدعوم في وقت كتابة هذه السطور.

الشكل تسلسل رسم بياني of هيه القائم على X2 سلم أدناه يظهر التفاعل
كيانات نموذج X2 في جهاز المحاكاة. تشير التسميات المظللة إلى اللحظات التي يكون فيها
انتقال UE أو eNodeB إلى حالة RRC أخرى.
[صورة] مخطط تسلسلي لعملية التسليم المستندة إلى X2.UNINDENT

يوضح الشكل أيضًا مؤقتين ضمن إجراء التسليم: سلم مغادرة
مؤقت تتم صيانته بواسطة eNodeB المصدر، في حين أن سلم انضمام مؤقت بالهدف
eNodeB. يمكن تكوين مدة الموقتات في
HandoverLeavingTimeoutDuration HandoverJoiningTimeoutDuration سمات
هؤلاء LteEnbRrc الحالات. عند انتهاء صلاحية أحد هذه الموقتات، يتم إجراء التسليم
يعتبر فاشلا.

ومع ذلك، لا توجد معالجة مناسبة لفشل التسليم في الإصدار الحالي من LTE
وحدة. يجب على المستخدمين ضبط المحاكاة بشكل صحيح لتجنب فشل التسليم،
وإلا فقد يحدث سلوك غير متوقع. يرجى الرجوع إلى القسم
محاكاة ثانية لوثائق المستخدم للحصول على بعض النصائح بخصوص هذا الأمر
شيء.

نموذج X2 هو كيان يستخدم الخدمات من:

· واجهات X2،

· يتم تنفيذها كمقابس أعلى أجهزة نقطة إلى نقطة.

· يتم استخدامها لإرسال/استقبال رسائل X2 من خلال واجهات X2-C وX2-U
(أي جهاز نقطة إلى نقطة متصل بوصلة نقطة إلى نقطة) باتجاه
نظير eNB.

· تطبيق S1.

· حاليا، هو EpcEnbApplication.

· يتم استخدامه للحصول على بعض المعلومات اللازمة للإجراءات الأولية لـ X2
الرسائل.

ويقدم الخدمات إلى:

· كيان RRC (X2 SAP)

· إرسال/استقبال رسائل RRC. يرسل الكيان X2 رسالة RRC كرسالة شفافة
الحاوية في رسالة X2. ويتم إرسال رسالة RRC هذه إلى تجهيزات المستعمل.

الشكل تطبيق الموديل 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 لا يتم فرضها على الوصلات X2-U
أن الإفراط في توفير عرض النطاق الترددي للارتباط يكفي لتلبية متطلبات جودة الخدمة
من جميع الحاملين.

X2 العطاء السطح البيني
يتم استخدام واجهة خدمة X2 بواسطة كيان RRC لإرسال واستقبال رسائل X2
إجراءات. وهي مقسمة إلى قسمين:

· ال EpcX2SapProvider يتم توفير الجزء بواسطة كيان X2 ويستخدمه كيان RRC و

· ال EpcX2SapUser يتم توفير الجزء من قبل كيان RRC ويستخدمه كيان RRC.

تم وصف الأساسيات المدعومة في نموذج X2-C الخاص بنا فيما يلي
الأقسام الفرعية.

X2-C البدائيون For سلم
يتم استخدام البدائيات التالية للتسليم المستند إلى X2:

· طلب التسليم

· تسليم طلب ACK

· فشل إعداد التسليم

· نقل حالة SN

· بيان سياق UE

يتم استخدام جميع البدائيات المذكورة أعلاه بواسطة نموذج RRC المطبق حاليًا أثناء
إعداد وتنفيذ إجراءات التسليم. يتفاعل استخدامها مع RRC
آلة الدولة لذلك، لا يُقصد استخدامها لتخصيص التعليمات البرمجية، على الأقل
ما لم يكن هناك رغبة في تعديل جهاز حالة RRC.

X2-C هي البدائيون
يمكن استخدام البدائيات التالية لتنفيذ الشبكة ذاتية التنظيم (SON)
الوظائف:

· معلومات التحميل

· تحديث حالة الموارد

لاحظ أن نموذج RRC الحالي لا يستخدم هذه البدائيات فعليًا، بل تم تضمينها
في النموذج فقط لتمكين تطوير خوارزميات SON المضمنة في منطق RRC
التي تستفيد منها.

كمثال أول، نوضح هنا كيف يمكن استخدام معلومات التحميل البدائية. نحن نفترض
أنه تم تعديل LteEnbRrc ليشمل متغيرات الأعضاء الجديدة التالية:

الأمراض المنقولة جنسيا::ناقل
m_currentUlInterferenceOverloadInstructionList;
الأمراض المنقولة جنسيا::ناقل
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

للحصول على وصف تفصيلي لنوع هذه المتغيرات، نقترح مراجعة الملف
epc-x2-sap.h، وثائق الدوكسيجين المقابلة، والمراجع الواردة فيها إلى
الأقسام ذات الصلة من 3GPP TS 36.423. الآن، افترض أن هذه المتغيرات موجودة في وقت التشغيل
تم ضبطها على قيم ذات معنى باتباع المواصفات المذكورة للتو. إذا تستطيع
قم بإضافة الكود التالي في تطبيق فئة LteEnbRrc لإرسال التحميل
المعلومات البدائية:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadInstructionList = m_currentUlInterferenceOverloadInstructionList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

EpcX2Sap::LoadInformationParams params;
params.targetCellId = cellId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (params);

يسمح الكود أعلاه لـ eNB المصدر بإرسال الرسالة. طريقة
LteEnbRrc::DoRecvLoadInformation سيتم استدعاؤه عندما يتلقى eNB الهدف الرسالة.
ولذلك ينبغي تنفيذ المعالجة المطلوبة لمعلومات التحميل ضمن ذلك
الأسلوب.

في المثال الثاني التالي نوضح كيفية استخدام تحديث حالة المورد البدائي.
نحن نفترض أنه تم تعديل LteEnbRrc ليشمل العضو الجديد التالي
المتغير:

EpcX2Sap::CellMeasurementResultItem m_cmri;

على غرار ما سبق، نشير إلى epc-x2-sap.h والمراجع فيه للتفصيل
معلومات حول هذا النوع المتغير. مرة أخرى، نفترض أن المتغير موجود بالفعل
تعيين إلى قيمة ذات معنى. وبعد ذلك، يمكنك إضافة الكود التالي لإرسال رسالة
تحديث حالة الموارد:

EpcX2Sap::ResourceStatusUpdateParams المعلمات؛
params.targetCellId = cellId;
params.cellMeasurementResultList.push_back (m_cmri)؛
m_x2SapProvider->SendResourceStatusUpdate (params);

الأسلوب eEnbRrc::DoRecvResourceStatusUpdate سيتم استدعاؤه عندما يتلقى eNB الهدف
رسالة تحديث حالة المورد. يجب أن تتم المعالجة المطلوبة لهذه الرسالة
وبالتالي يتم تنفيذها ضمن هذا الأسلوب.

وأخيرا، نلاحظ أن إعداد ومعالجة القيم المناسبة ل
يعتبر المتغير الذي تم تمريره إلى البدائيات الموصوفة أعلاه خاصًا بـ SON
يتم تنفيذ الخوارزمية، وبالتالي لا تغطيها هذه الوثائق.

غير معتمد البدائيون
أساسيات تحسين متانة التنقل مثل مؤشر فشل ارتباط الراديو و
تقرير التسليم غير مدعوم في هذه المرحلة.

S11
توفر واجهة S11 تفاعل مستوى التحكم بين SGW وMME باستخدام
بروتوكول GTPv2-C المحدد في [TS29274]. في جهاز المحاكاة، تم تصميم هذه الواجهة بطريقة
الموضة المثالية، مع التفاعل المباشر بين كائنات SGW وMME، بدون
التنفيذ الفعلي لتشفير الرسائل ودون إرسال أي منها فعليًا
PDU على أي رابط.

البدائيات S11 التي تم تصميمها هي:

· إنشاء طلب الجلسة

· إنشاء استجابة الجلسة

· تعديل طلب الحامل

· تعديل استجابة الحامل

من بين هذه البدائيات، يتم استخدام الأولين عند مرفق UE الأولي لـ
إنشاء حاملات S1-U؛ يتم استخدام الاثنين الآخرين أثناء التسليم لتبديل
حاملات S1-U من مصدر eNB إلى eNB المستهدف نتيجة للاستقبال بواسطة
MME لرسالة PATH SWITCH REQUEST S1-AP.

الطاقة مراقبة
يصف هذا القسم تطبيق ns-3 للتحكم في طاقة الوصلة الهابطة والصاعدة.

إلى أسفل لينك الطاقة مراقبة
نظرًا لأن بعض خوارزميات إعادة استخدام التردد تتطلب التحكم في طاقة الوصلة الهابطة، فقد كانت هذه الميزة
نفذت أيضا في NS-3.
[صورة] مخطط تسلسلي للتحكم في طاقة الوصلة الهابطة.UNINDENT

الشكل تسلسل رسم بياني of إلى أسفل لينك الطاقة مراقبة يظهر الرسم البياني تسلسل الإعداد
قيمة P_A للوصلة الهابطة لتجهيزات المستعمل، مع تسليط الضوء على التفاعلات بين مركز الاتصالات الراديوية والآخر
جهات. تقوم خوارزمية FR بتشغيل RRC لتغيير قيم P_A لـ UE. ثم يبدأ RRC
وظيفة RrcConnectionReconfiguration لإبلاغ UE بالتكوين الجديد. بعد
بنجاح RrcConnectionReconfiguration، يمكن لـ RRC تعيين قيمة P_A لـ UE عن طريق الاتصال
الدالة SetPa من CphySap، يتم حفظ القيمة في الخريطة الجديدة m_paMap التي تحتوي على قيم P_A
لكل وحدة مستعمل تخدمها eNb.

عندما يبدأ LteEnbPhy إطارًا فرعيًا جديدًا، تتم معالجة رسائل التحكم DCI للحصول على متجه
تستخدم RBs. الآن أيضًا أصبحت وظيفة GeneratePowerAlllocationMap(uint16_t rnti, int rbId) أيضًا
مُسَمًّى. تقوم هذه الوظيفة بفحص قيمة P_A لـ UE، وتوليد الطاقة لكل RB وتخزينها
m_dlPowerAlllocationMap. ثم يتم استخدام هذه الخريطة من قبل
وظيفة CreateTxPowerSpectralDensityWithPowerAlllocation لإنشاء Ptr
txPsd.

تمت إضافة PdschConfigDedicated (TS 36.331، 6.3.2 PDSCH-Config) في
LteRrcSap::PhysicalConfigDedicated، والذي يتم استخدامه في RrcConnectionReconfiguration
.

الإرسال الطاقة مراقبة
يتحكم التحكم في طاقة الوصلة الصاعدة في قوة الإرسال للوصلة الصاعدة المادية المختلفة
القنوات. تم توضيح هذه الوظيفة في القسم 3 من 36.213GPP TS 5.

يتم تمكين التحكم في طاقة الوصلة الصاعدة بشكل افتراضي، ويمكن تعطيله بواسطة نظام السمات:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl"، BooleanValue (false));

يتم تنفيذ آليتين للتحكم في طاقة الوصلة الصاعدة:

· التحكم في طاقة الوصلة الصاعدة المفتوحة: تعتمد قوة نقل UE على تقدير
فقدان مسار الوصلة الهابطة وتكوين القناة

· التحكم في طاقة الوصلة الصاعدة ذات الحلقة المغلقة: كما هو الحال في الحلقة المفتوحة، بالإضافة إلى ذلك، يمكن لـ eNB التحكم في UE
طاقة الإرسال عن طريق أوامر TPC للتحكم في طاقة الإرسال الصريحة
تنتقل في الوصلة الهابطة.

للتبديل بين هذين النوعين من الآليات، يجب تغيير المعلمة:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop"، BooleanValue (true));

افتراضيًا، يتم تمكين التحكم في طاقة الحلقة المغلقة.

المستوى الثاني⁧⁩ وسائط of مغلق أنشوطة الإرسال الطاقة مراقبة . المتاحة:

· الوضع المطلق: يتم حساب TxPower باستخدام قيم TPC المطلقة

· الوضع التراكمي: يتم حساب TxPower باستخدام قيم TPC المتراكمة

للتبديل بين هذين الوضعين، ينبغي للمرء تغيير المعلمة:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled"، BooleanValue (true));

افتراضيًا، يتم تمكين وضع التراكم ويتم تعيين أوامر TPC في DL-DCI بواسطة الجميع
المجدولون إلى 1، ما يتم تعيينه إلى قيمة 0 في وضع التراكم.

الإرسال الطاقة مراقبة For اضغط
إعداد طاقة إرسال UE للقناة المشتركة للوصلة الصاعدة المادية (PUSCH)
يتم تعريف الإرسال على النحو التالي:

· إذا أرسل تجهيزات المستعمل PUSCH دون إرسال PUCCH متزامن لخلية التقديم c، فحينئذٍ
يرسل UE قدرة P_{PUSCH,c}(i) لإرسال PUSCH في الإطار الفرعي i لـ
يتم إعطاء خلية الخدمة c بواسطة:

· إذا أرسل تجهيزات المستعمل PUSCH بالتزامن مع PUCCH لخلية التقديم c، فإن تجهيزات المستعمل
إرسال القدرة P_{PUSCH,c}(i) لإرسال PUSCH في الإطار الفرعي i لـ
يتم إعطاء خلية الخدمة c بواسطة:

نظرًا لعدم تنفيذ التحكم في طاقة الوصلة الصاعدة لـ PUCCH، لم يتم تنفيذ هذه الحالة
كذلك.

· إذا كان تجهيزات المستعمل لا يرسل PUSCH للخلية المقدمة c، لتراكم
يتم استلام أمر TPC بصيغة DCI 3/3A لـ PUSCH، ويجب أن يفترض تجهيزات المستعمل أن مستعمل
إرسال القدرة 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، ج} (ط). القيمة الافتراضية لـ 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 إلى التوسع لتحمل هذين المكونين، ولكن حاليًا
يمكن ضبطها عبر نظام السمات:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch"، IntegerValue (-90));
التكوين::SetDefault ("ns3::LteUePowerControl::PoUePusch"، IntegerValue (7));

· lpha_{c} (j) عبارة عن معلمة 3 بت مقدمة من طبقات أعلى لـ ightinForelj=2،
بالنسبة لـ j=0,1، lpha_c في t 0، 0.4، 0.5، 0.6، 0.7، 0.8، 0.9، 1
lpha_{c} (j) = 1. هذه المعلمة قابلة للتكوين بواسطة نظام السمات:

التكوين::SetDefault ("ns3::LteUePowerControl::Alpha"، DoubleValue (0.8));

· PL_{c} هو تقدير خسارة مسار الوصلة الهابطة المحسوب في تجهيزات المستعمل لخدمة الخلية c
في ديسيبل وPL_{c} =referenceSignalPower – الطبقة العليا التي تمت تصفيتها RSRP، حيث
يتم توفير ReferenceSignalPower من خلال طبقات أعلى وRSRP. مرجع إشارة الطاقة
يتم توفيره في رسالة SIB2

· ويتم تنفيذ الحالة الشرطية.

· f_{c}(i) هو أحد مكونات التحكم في طاقة الحلقة المغلقة. إنها قوة PUSCH الحالية
حالة ضبط التحكم لخدمة الخلية ج.

إذا تم تمكين وضع التراكم f_{c}(i) فسيتم الحصول عليه بواسطة:

حيث: elta_{PUSCH,c} هي قيمة تصحيح، ويشار إليها أيضًا بأمر TPC
ويتم تضمينه في PDCCH مع DCI؛ تم تشغيل الإشارة إلى elta_{PUSCH,c}(i - K_{PUSCH}).
PDCCH/EPDCCH مع DCI لخدمة الخلية c على الإطار الفرعي (i - K_{PUSCH})؛ ك _ {دفعة} =
4 لقوات الدفاع عن الديمقراطية.

إذا وصل UE إلى P_{CMAX,c}(i) لخدمة الخلية c، فإن أوامر TPC الموجبة لـ
لا يتم تجميع خلية الخدمة c. إذا وصل UE إلى الحد الأدنى من الطاقة، يكون سلبيًا
لا يتم تجميع أوامر TPC. يتم تعريف الحد الأدنى من طاقة UE في TS36.101
القسم 6.2.3. القيمة الافتراضية هي -40 ديسيبل مللي واط.

إذا لم يتم تمكين وضع التراكم f_{c}(i) فسيتم الحصول عليه بواسطة:

حيث: elta_{PUSCH,c} هي قيمة تصحيح، ويشار إليها أيضًا بأمر TPC
ويتم تضمينه في PDCCH مع DCI؛ تم تشغيل الإشارة إلى elta_{PUSCH,c}(i - K_{PUSCH}).
PDCCH/EPDCCH مع DCI لخدمة الخلية c على الإطار الفرعي (i - K_{PUSCH})؛ ك _ {دفعة} =
4 لقوات الدفاع عن الديمقراطية.

تعيين حقل أمر TPC بتنسيق DCI 0/3/4 إلى المطلق والمتراكم
تم تعريف قيم elta_{PUSCH,c} في القسم TS36.231 5.1.1.1 الجدول 5.1.1.1-2

الإرسال الطاقة مراقبة For بوكش
نظرًا لأن جميع رسائل التحكم في الوصلة الصاعدة هي رسائل مثالية ولا تستهلك أي راديو
الموارد، ليست هناك حاجة للتحكم في طاقة الوصلة الصاعدة لـ PUCCH ولم يتم تنفيذها.

الإرسال الطاقة مراقبة For SRS
ضبط قدرة إرسال UE P_{SRS} لخدمة SRS المرسلة على الإطار الفرعي i for
يتم تعريف خلية الخدمة 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 لـ
خدمة الخلية ج. بالنسبة لإرسال SRS، نظرًا لنوع الزناد 0، فإن m=0,1 وبالنسبة لـ SRS
انتقال نظرا لنوع الزناد 1 ثم م = 1. بالنسبة لـ K_{s} = 0 P_Srs_Offset_Value هي
محسوبة بالمعادلة:

هذه المعلمة قابلة للتكوين بواسطة نظام السمات:

التكوين::SetDefault ("ns3::LteUePowerControl::PsrsOffset"، IntegerValue (7));

· M_{SRS,c} هو عرض النطاق الترددي لإرسال SRS في الإطار الفرعي i لخلية الخدمة
ج معبرا عنه في عدد كتل الموارد. في التنفيذ الحالي يتم إرسال SRS
على كامل عرض النطاق الترددي UL.

· f_{c}(i) هي حالة ضبط التحكم في الطاقة PUSCH الحالية لخدمة الخلية c،
على النحو المحدد في الإرسال الطاقة مراقبة For اضغط

· P_{O_PUSCH,c}(j) وlpha_{c}(j) هي معلمات كما هو محدد في الإرسال الطاقة
مراقبة For اضغطحيث ي = 1 .

كسري تردد إعادة استخدام
نظرة عامة
يصف هذا القسم دعم ns-3 لخوارزميات إعادة استخدام التردد الجزئي. الجميع
تم وصف الخوارزميات المنفذة في [ASHamza2013]. حاليا 7 خوارزميات FR هي
نفذ:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

تم إنشاء فئة LteFfrAlgorithm جديدة وهي فئة مجردة لإعادة استخدام التردد
تنفيذ الخوارزميات. كما تمت إضافة برنامجي SAP جديدين بين FR-Scheduler وFR-RRC.
[صورة] مخطط تسلسلي للجدولة باستخدام خوارزمية FR.UNINDENT

الشكل تسلسل رسم بياني of جدولة مع FR خوارزمية يظهر الرسم التخطيطي للتسلسل
عملية الجدولة باستخدام خوارزمية FR. في بداية عملية الجدولة، جدولة
يسأل كيان FR عن RBGs المتاحة. وفقًا للتنفيذ، تقوم FR بإرجاع جميع RBGs
المتوفرة في الخلية أو تصفيتها بناءً على سياستها. ثم عند محاولة تعيين بعض
RBG إلى UE، يسأل المجدول كيان FR إذا كان RBG مسموحًا به لـ UE هذا. عندما يعود FR
صحيح، يمكن للمجدول تعيين RBG هذا إلى UE هذا، إذا لم يكن المجدول يقوم بفحص RBG آخر
لهذا الاتحاد الأوروبي. ومرة أخرى، تعتمد استجابة FR على التنفيذ والسياسة المطبقة على تجهيزات المستعمل.

مدعومة FR خوارزميات
لا تردد إعادة استخدام
خوارزمية NoOp FR (فئة LteFrNoOpAlgorithm) هي تطبيق لإعادة استخدام التردد الكامل
هذا يعني عدم إجراء تقسيم التردد بين وحدات eNB لنفس الشبكة
(عامل إعادة استخدام التردد، FRF يساوي 1). يستخدم eNBs النطاق الترددي للنظام بأكمله ويرسله
مع قوة موحدة على جميع RBGs. إنه أبسط مخطط وهو الطريقة الأساسية
تشغيل شبكة LTE. يسمح هذا المخطط بتحقيق معدل بيانات الذروة العالي. لكن
من ناحية أخرى، وذلك بسبب مستويات التداخل الشديد من الخلايا المجاورة، حافة الخلية
أداء المستخدمين محدود إلى حد كبير.

الشكل طويل تردد إعادة استخدام مخطط يعرض أدناه التردد وخطة الطاقة للكامل
مخطط إعادة استخدام التردد.
[صورة] مخطط إعادة استخدام التردد الكامل.UNINDENT

في ns-3، تسمح خوارزمية NoOp FR دائمًا للمجدول باستخدام النطاق الترددي الكامل وتسمح بذلك
جميع وحدات UE لاستخدام أي RBG. إنه ببساطة لا يفعل شيئًا جديدًا (أي أنه لا يحد من نطاق eNB
عرض النطاق الترددي، تم تعطيل خوارزمية FR)، وهو أبسط تطبيق لخوارزمية Fr
class ويتم تثبيته في eNb افتراضيًا.

الثابت تردد إعادة استخدام
توفر خوارزمية إعادة استخدام التردد الثابت أبسط مخطط يسمح بالتقليل
مستوى التداخل بين الخلايا في هذا المخطط يتم تقسيم عرض النطاق الترددي بأكمله إلى
عدد قليل (عادة 3، 4، أو 7) نطاقات فرعية منفصلة. يتم تخصيص eNBs المجاورة مع مختلف
النطاق الفرعي. عامل إعادة استخدام التردد يساوي عدد النطاقات الفرعية. هذا المخطط يسمح ل
يؤدي بشكل كبير إلى تقليل ICI عند حافة الخلية، وبالتالي يتم تحسين أداء مستخدمي الخلية.
ولكن يرجع ذلك إلى حقيقة أن كل eNB يستخدم جزءًا واحدًا فقط من النطاق الترددي الكامل، وهو معدل ذروة البيانات
ويتم أيضًا تقليل المستوى بمعامل يساوي عامل إعادة الاستخدام.

الشكل الثابت تردد إعادة استخدام مخطط يعرض أدناه التردد وخطة الطاقة لـ Hard
مخطط إعادة استخدام التردد.
[صورة] مخطط إعادة استخدام التردد الثابت.UNINDENT

في تنفيذنا، تحتوي خوارزمية Hard FR على متجه فقط من RBGs المتاحة لـ eNB
وقم بتمريرها إلى برنامج جدولة MAC أثناء وظائف الجدولة. عندما يسأل المجدول، إذا كان RBG
مسموح به لـ UE محدد فإنه يعود دائمًا صحيحًا.

صارم تردد إعادة استخدام
نظام إعادة استخدام التردد الصارم هو مزيج من مخططات إعادة استخدام التردد الكامل والصعب. هو - هي
يتكون من تقسيم النطاق الترددي للنظام إلى قسمين مختلفين
إعادة استخدام التردد. يتم استخدام نطاق فرعي مشترك لعرض النطاق الترددي للنظام في كل خلية داخلية
(إعادة استخدام التردد-1)، بينما يتم تقسيم الجزء الآخر من عرض النطاق الترددي بين
eNBs المجاورة كما هو الحال في إعادة استخدام التردد الثابت (إعادة استخدام التردد-N، N> 1)، من أجل الإنشاء
نطاق فرعي واحد مع مستوى تداخل منخفض بين الخلايا في كل قطاع. سوف يكون مركز UEs
تُمنح مع قطع التردد المعاد استخدامها بالكامل، في حين أن وحدات المستعمل الموجودة على حافة الخلية ذات القطع المتعامدة.
وهذا يعني أن وحدات المستعمل الداخلية من خلية واحدة لا تشترك في أي طيف مع وحدات المستعمل الحافة منها
الخلية الثانية، مما يقلل من التدخل لكليهما. كما يمكن ملاحظته، يتطلب Strict FR أ
إجمالي النطاقات الفرعية N + 1، ويسمح بتحقيق RFR في المنتصف بين 1 و3.

الشكل صارم تردد إعادة استخدام مخطط يعرض أدناه التردد وخطة الطاقة لـ Strict
مخطط إعادة استخدام التردد مع عامل إعادة استخدام حافة الخلية N = 3.
[صورة] مخطط إعادة استخدام التردد الصارم.UNINDENT

في تنفيذنا، تحتوي خوارزمية Strict FR على خريطتين، واحدة لكل نطاق فرعي. إذا الاتحاد الأوروبي
يمكن تقديمه ضمن نطاق فرعي خاص، وتتم إضافة RNTI الخاص به إلى خريطة m_privateSubBandUe. لو
ويمكن تقديم تجهيزات المستعمل ضمن نطاق فرعي مشترك، وتتم إضافة RNTI الخاص به إلى خريطة m_commonSubBandUe.
تحتاج خوارزمية FR الصارمة إلى تحديد النطاق الفرعي الذي يجب تقديم خدمة UE ضمنه. يستخدم
قياسات تجهيزات المستعمل المقدمة من لجنة لوائح الراديو ومقارنتها بعتبة جودة الإشارة (هذا
يمكن ضبط المعلمة بسهولة عن طريق آلية السمة). العتبة لها تأثير على
نسبة نصف القطر الداخلي إلى الخلية.

ناعم تردد إعادة استخدام
في نظام إعادة استخدام التردد الناعم (SFR) يرسل كل eNb عبر النطاق الترددي للنظام بأكمله،
ولكن هناك نطاقان فرعيان، داخل تجهيزات المستعمل يتم تقديمهما بمستويات مختلفة من الطاقة. منذ
تشترك وحدات المستعمل الموجودة في مركز الخلية في عرض النطاق الترددي مع الخلايا المجاورة، وعادةً ما ترسل بمعدلات أقل
مستوى الطاقة من وحدات UE على حافة الخلية. يعد SFR أكثر كفاءة في عرض النطاق الترددي من Strict FR،
لأنه يستخدم النطاق الترددي للنظام بأكمله، ولكنه يؤدي أيضًا إلى مزيد من التداخل مع كليهما
مستخدمي الخلية الداخلية والحافة.

هناك نسختان محتملتان من مخطط SFR:

· في الإصدار الأول، يمكن أيضًا استخدام النطاق الفرعي المخصص لوحدات المستعمل الموجودة على حافة الخلية
وحدات المستعمل الموجودة في مركز الخلية ولكن بمستوى طاقة منخفض وفقط إذا لم تكن مشغولة
وحدات UE على حافة الخلية. النطاق الفرعي لمركز الخلية متاح لوحدات المستعمل المركزية فقط. شكل
ناعم تردد إعادة استخدام مخطط الإصدار 1 يعرض أدناه التردد وخطة الطاقة لـ
هذا الإصدار من مخطط إعادة استخدام التردد الناعم.
[صورة] إصدار نظام إعادة استخدام التردد الناعم 1.UNINDENT

· في الإصدار الثاني، لا تستطيع وحدات المستعمل الموجودة في مركز الخلية الوصول إلى النطاق الفرعي لحافة الخلية. في
بهذه الطريقة، يمكن لكل خلية استخدام النطاق الترددي للنظام بأكمله مع تقليل النطاق الترددي
التدخل في الخلايا المجاورة. من ناحية أخرى، انخفض مستوى ICI عند
يتم تحقيق حافة الخلية على حساب انخفاض استخدام الطيف. شكل ناعم
تردد إعادة استخدام مخطط الإصدار 2 يعرض أدناه التردد وخطة الطاقة لهذا الغرض
نسخة من مخطط إعادة استخدام التردد الناعم.
[صورة] إصدار نظام إعادة استخدام التردد الناعم 2.UNINDENT

تحتفظ خوارزمية SFR بخريطتين. إذا كان ينبغي تقديم UE بمستوى طاقة أقل، فهذا يعني أنه يجب تقديمه
تتم إضافة RNTI إلى خريطة m_lowPowerSubBandUe. إذا كان ينبغي تقديم UE بقوة أعلى
المستوى، تتم إضافة RNTI الخاص به إلى خريطة m_highPowerSubBandUe. لتحديد مستوى الطاقة
يجب أن يتم تقديم UE إلى خوارزمية SFR باستخدام قياسات UE ومقارنتها
عتبة. عتبة جودة الإشارة وPdschConfigDedicated (أي قيمة P_A) للداخلية
ويمكن تكوين المنطقة الخارجية عن طريق نظام السمات. يستخدم SFR قوة الوصلة الهابطة
السيطرة الموصوفة هنا.

ناعم كسري تردد إعادة استخدام
إعادة استخدام التردد الجزئي الناعم (SFFR) عبارة عن مزيج من التردد الصارم والناعم
مخططات إعادة الاستخدام. بينما لا تستخدم Strict FR النطاقات الفرعية المخصصة للمنطقة الخارجية في
الخلايا المجاورة، يستخدم FFR الناعم هذه النطاقات الفرعية لوحدات المستعمل الداخلية ذات قدرة الإرسال المنخفضة. مثل
ونتيجة لذلك، يستخدم SFFR، مثل SFR، النطاق الفرعي بمستوى قدرة إرسال مرتفع ومستوى طاقة إرسال منخفض
نقل مستوى الطاقة. على عكس Soft FR ومثل Strict FR، يستخدم Soft FFR المشترك
النطاق الفرعي الذي يمكن أن يعزز إنتاجية المستخدمين الداخليين.

الشكل ناعم كسري كسري تردد إعادة استخدام مخطط أدناه يعرض التردد و
خطة الطاقة لإعادة استخدام التردد الجزئي الناعم.
[صورة] مخطط إعادة استخدام التردد الجزئي الناعم.UNINDENT

تعزيز كسري تردد إعادة استخدام
تحدد إعادة استخدام التردد الجزئي المحسن (EFFR) الموضح في [ZXie2009] 3 أنواع من الخلايا
للخلايا المجاورة مباشرة في النظام الخلوي، والاحتياطيات لكل نوع خلية أ
جزء من نطاق التردد بأكمله المسمى المرحلة الابتدائية قطعة، والتي بين الخلايا نوع مختلف
يجب أن تكون متعامدة. تشكل القنوات الفرعية المتبقية ثانوي قطعة.
المرحلة الابتدائية قطعة من نوع الخلية هو في نفس الوقت جزء من ثانوي شرائح
تنتمي إلى النوعين الآخرين من الخلايا. يمكن لكل خلية أن تشغل جميع القنوات الفرعية الخاصة بها المرحلة الابتدائية
قطعة في الإرادة، في حين أن جزءا فقط من القنوات الفرعية في ثانوي قطعة ويمكن استخدام
بواسطة هذه الخلية بطريقة علم التدخل المرحلة الابتدائية قطعة من كل خلية مقسمة
إلى جزء إعادة الاستخدام 3 وإعادة الاستخدام جزء واحد. يمكن إعادة استخدام الجزء reuse-1 بواسطة جميع أنواع الخلايا
في النظام، في حين لا يمكن إعادة استخدام الجزء reuse-3 إلا من خلال نفس النوع الآخر
الخلايا (أي لا يمكن إعادة استخدام القنوات الفرعية لإعادة الاستخدام 3 بواسطة الخلايا المجاورة مباشرة). على
هيه ثانوي قطعة تعمل الخلية كضيف، وتحتل القنوات الفرعية الثانوية
في الواقع إعادة استخدام القنوات الفرعية الأولية التي تنتمي إلى الخلايا المجاورة مباشرة، وبالتالي
إعادة الاستخدام على ثانوي قطعة يجب أن تتوافق كل خلية مع قاعدتين:

· مراقبة قبل الاستخدام

· إعادة استخدام الموارد على أساس تقدير SINR

تستمع كل خلية إلى كل قناة فرعية ثانوية طوال الوقت. وقبل الاحتلال كان
يقوم بتقييم SINR وفقًا لمعلومات جودة القناة المجمعة (CQI) و
يختار الموارد ذات أفضل قيم التقدير لإعادة استخدامها. إذا كانت قيمة CQI لـ RBG أعلاه
العتبة التي تم تكوينها لبعض المستخدمين، يمكن إجراء النقل لهذا المستخدم باستخدام هذا
آر بي جي.

في [ZXie2009] يتم وصف عملية الجدولة، وهي تتكون من ثلاث خطوات وخطوتين
سياسات الجدولة. نظرًا لعدم السماح لأي من برامج الجدولة المنفذة حاليًا بذلك
السلوك، وتم تطبيق بعض التبسيط. في تنفيذنا، يمكن إعادة استخدام القنوات الفرعية 1
يمكن استخدامها فقط من قبل مستخدمي مركز الخلية. يمكن استخدام القنوات الفرعية Reuse-3 بواسطة مستخدمي Edge فقط
إذا لم يكن هناك مستخدم طرفي، فيمكن تقديم الإرسال لمستخدمي المركز الخلوي في إعادة الاستخدام-3
القنوات الفرعية.

الشكل تعزيز كسري كسري تردد إعادة استخدام مخطط أدناه يعرض التردد و
خطة الطاقة لإعادة استخدام التردد الجزئي المحسن.
[صورة] مخطط إعادة استخدام التردد الجزئي المحسن.UNINDENT

وزعت كسري تردد إعادة استخدام
تم تقديم خوارزمية إعادة استخدام التردد الجزئي الموزع في [DKimura2012]. هو - هي
يعمل تلقائيًا على تحسين النطاقات الفرعية لحافة الخلية من خلال التركيز على توزيع المستخدم (في
على وجه الخصوص، توزيع الطاقة المتلقية). تقوم هذه الخوارزمية باختيار RBs بشكل تكيفي
النطاق الفرعي لحافة الخلية على أساس معلومات التنسيق من الخلايا المجاورة والإخطارات
المحطات الأساسية للخلايا المجاورة، والتي اختارتها RBs لاستخدامها في نطاق الحافة الفرعي.
تستخدم المحطة الأساسية لكل خلية المعلومات المستلمة والمعادلة التالية
حساب مقياس نطاق حافة الخلية A_{k} لكل RB.

حيث J هي مجموعة من الخلايا المجاورة، X_{j,k}=0,1 هي RNTP من الخلية المجاورة j.
يستغرق الأمر قيمة 1 عند استخدام k-th RB في الخلية المجاورة j كحافة خلية
النطاق الفرعي و 0 خلاف ذلك. يشير الرمز w_{j} إلى الوزن بالنسبة للخلية المجاورة j،
أي عدد المستخدمين الذين يختلف عنهم قوة الإشارة
المستلمة من الخلية المقدمة i وقوة الإشارة الواردة من الخلية المجاورة
الخلية j أقل من قيمة العتبة (أي عدد المستخدمين بالقرب من حافة الخلية في
خلية الخدمة). يعني الاختلاف الكبير في الطاقة المستلمة أن مستخدمي حافة الخلية في i-th
تعاني الخلية من تداخل قوي من الخلية j.

يعتبر RB الذي يكون فيه المقياس A_{k} هو الأصغر هو الأقل تأثراً به
تدخل من خلية أخرى. تحدد خلية العرض عددًا مكونًا من RBs كـ
النطاق الفرعي لحافة الخلية بترتيب تصاعدي لـ A_{k}. ونتيجة لذلك، فإن المكاتب الإقليمية التي صغيرة
يتلقى عدد من مستخدمي حافة الخلية تداخلاً عاليًا من المحطات القاعدية المجاورة
المحدد.

ثم يتم إرسال RNTP المحدث إلى كافة الخلايا المجاورة. من أجل تجنب ما لا معنى له
عند تذبذب اختيار نطاق حافة الخلية، تتجاهل المحطة الأساسية RNTP من قاعدة أخرى
المحطة التي لها معرف خلية أكبر من المحطة الأساسية.

يؤدي تكرار هذه العملية عبر كافة الخلايا إلى تمكين تخصيص المكاتب الإقليمية لمناطق حافة الخلية
ليتم تحسينها على النظام وتعديلها مع التغييرات في توزيع المستخدم.

الشكل تسلسل رسم بياني of وزعت تردد إعادة استخدام مخطط أدناه يعرض التسلسل
رسم تخطيطي لنظام إعادة استخدام التردد الجزئي الموزع.
[صورة] مخطط تسلسلي لنظام إعادة استخدام التردد الموزع.UNINDENT

المساعدون
يتم استخدام كائنين مساعدين لإعداد عمليات المحاكاة وتكوين المكونات المختلفة.
هذه الكائنات هي:

· LteHelper، الذي يعتني بتكوين شبكة الوصول إلى الراديو LTE، مثل
بالإضافة إلى تنسيق إعداد وإصدار حاملات EPS. ال LteHelper فئة
يوفر تعريف واجهة برمجة التطبيقات (API) وتنفيذه.

· EpcHelper، الذي يعتني بتكوين الحزمة الأساسية المتطورة. ال
EpcHelper الفئة هي فئة أساسية مجردة توفر فقط تعريف API؛ ال
يتم تفويض التنفيذ إلى الفئات الفرعية للسماح بـ EPC مختلف
نماذج الشبكة.

من الممكن إنشاء عمليات محاكاة بسيطة لـ LTE فقط باستخدام LteHelper وحده أو إلى
إنشاء عمليات محاكاة LTE-EPC كاملة باستخدام كليهما LteHelper EpcHelper. عندما كلاهما
يتم استخدام المساعدين، ويتفاعلون بطريقة السيد والعبد، مع LteHelper كونه السيد
التي تتفاعل مباشرة مع برنامج المستخدم، و EpcHelper العمل "تحت الغطاء" ل
قم بتكوين EPC بناءً على طرق صريحة يتم استدعاؤها بواسطة LteHelper. التفاعلات الدقيقة هي
المعروضة في الشكل تسلسل رسم بياني of هيه تفاعل ما بين LteHelper
EpcHelper.
[صورة] مخطط تسلسلي للتفاعل بين LteHelper وEpcHelper.UNINDENT

اسم المستخدم توثيق
خلفيّة
نفترض أن القارئ على دراية بكيفية استخدام جهاز محاكاة ns-3 لتشغيله بشكل عام
برامج المحاكاة. إذا لم يكن الأمر كذلك، فإننا نوصي بشدة القارئ بالتشاور
[ns3tutorial].

الأستعمال نظرة عامة
نموذج ns-3 LTE عبارة عن مكتبة برمجية تسمح بمحاكاة شبكات LTE،
بما في ذلك بشكل اختياري Evolved Packet Core (EPC). عملية تنفيذ مثل هذا
تتضمن عمليات المحاكاة عادة الخطوات التالية:

1. حدد هيه سيناريو ليتم محاكاتها

2. كتابة a محاكاة برنامج الذي يعيد السيناريو المطلوب
طوبولوجيا / الهندسة المعمارية. يتم ذلك من خلال الوصول إلى مكتبة طرازات ns-3 LTE باستخدام ملف
ns3::LteHelper واجهة برمجة التطبيقات المحددة في src/lte/helper/lte-helper.h.

3. تحديد ترتيب المعلمات من الكائنات التي يتم استخدامها ل
محاكاة. يمكن القيام بذلك باستخدام ملفات الإدخال (عبر ملف ns3::ConfigStore) أو
مباشرة ضمن برنامج المحاكاة.

4. ضبط هيه مطلوب الناتج ليتم إنتاجها بواسطة جهاز محاكاة

5. يجري المحاكاة.

سيتم شرح كل هذه الجوانب في الأقسام التالية بالوسائل العملية
أمثلة.

Basic محاكاة برنامج
إليك الحد الأدنى من برنامج المحاكاة المطلوب لإجراء محاكاة LTE فقط
(بدون EPC).

1. النموذج الأولي:

#يشمل
#يشمل
#يشمل
#يشمل

باستخدام مساحة الاسم ns3 ؛

int main (int argc، char * argv [])
{
// يتبع بقية برنامج المحاكاة

2. قم بإنشاء ملف LteHelper موضوع:

بي تي آر lteHelper = CreateObject ()؛

سيؤدي هذا إلى إنشاء مثيل لبعض الكائنات الشائعة (على سبيل المثال، كائن القناة) وتوفير
طرق لإضافة eNBs وUEs وتكوينها.

3. خلق العقدة كائنات eNB(s) وUEs:

NodeContainer enbNodes;
enbNodes.Create (1);
NodeContainer ueNodes;
ueNodes.Create (2);

لاحظ أن مثيلات العقدة المذكورة أعلاه في هذه المرحلة لا تزال لا تحتوي على بروتوكول LTE
تم تثبيت المكدس؛ إنها مجرد عقد فارغة.

4. قم بتكوين نموذج التنقل لجميع العقد:

التنقل
التنقل.SetMobilityModel("ns3::ConstantPositionMobilityModel");
التنقل. التثبيت (enbNodes)؛
التنقل.SetMobilityModel("ns3::ConstantPositionMobilityModel");
التنقل. التثبيت (ueNodes)؛

ما ورد أعلاه سوف يضع جميع العقد في الإحداثيات (0,0,0،XNUMX،XNUMX). يرجى الرجوع إلى
توثيق نموذج التنقل ns-3 لكيفية تحديد موقعك أو تكوينه
حركة العقدة.

5. قم بتثبيت حزمة بروتوكول LTE على eNB(s):

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. قم بتثبيت حزمة بروتوكول LTE على أجهزة UE:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. قم بتوصيل وحدات المستعمل إلى eNB. سيؤدي هذا إلى تكوين كل UE وفقًا لـ eNB
التكوين وإنشاء اتصال RRC بينهما:

lteHelper->Attach (ueDevs, enbDevs.Get (0));

8. قم بتنشيط حامل راديو البيانات بين كل UE وeNB المرفق به:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
حامل EpsBearer (ف)؛
lteHelper->ActivateDataRadioBearer (ueDevs, Bearer);

ستقوم هذه الطريقة أيضًا بتنشيط مولدين لحركة التشبع لهذا الحامل، أحدهما
في الوصلة الصاعدة وواحد في الوصلة الهابطة.

9. ضبط وقت التوقف:

محاكي::توقف (ثواني (0.005))؛

وهذا مطلوب وإلا فإن المحاكاة سوف تستمر إلى الأبد، لأنه (من بين أمور أخرى)
تتم جدولة حدث بدء الإطار الفرعي بشكل متكرر، وسيقوم برنامج جدولة المحاكاة ns-3 بذلك
وبالتالي لا تنفد الأحداث أبدًا.

10. قم بتشغيل المحاكاة:

محاكي :: تشغيل () ؛

11. التنظيف والخروج:

جهاز محاكاة :: تدمير () ؛
0 العودة؛
}

لمعرفة كيفية تجميع برامج المحاكاة وتشغيلها، يرجى الرجوع إلى [ns3tutorial].

الاعداد of LTE نموذج المعلمات
تتم إدارة جميع معلمات طراز LTE ذات الصلة من خلال نظام السمات ns-3.
برجاء الرجوع إلى [ns3tutorial] و[ns3manual] للحصول على معلومات مفصلة حول جميع
الطرق الممكنة للقيام بذلك (المتغيرات البيئية، C++ API، GtkConfigStore...).

فيما يلي، نلخص بإيجاز كيفية القيام بذلك باستخدام ملفات الإدخال مع
مخزن التكوين ns-3. أولا وقبل كل شيء، تحتاج إلى وضع ما يلي في المحاكاة الخاصة بك
البرنامج، مباشرة بعد رئيسي () يبدأ:

CommandLine كمد ؛
cmd ، Parse (argc ، argv) ؛
ConfigStore inputConfig ؛
inputConfig.ConfigureDefaults () ،
// قم بالتحليل مرة أخرى حتى تتمكن من تجاوز القيم الافتراضية من سطر الأوامر
cmd ، Parse (argc ، argv) ؛

لكي يعمل ما سبق، تأكد أنت أيضًا تتضمن # "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::Noiseالشكل "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" --run 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" --run src/lte/examples/lte-sim-with-input

لاحظ أن ما ورد أعلاه سيتم وضعه في الملف input-defaults.txt الكل القيم الافتراضية التي
مسجلة في البنية الخاصة بك لجهاز المحاكاة، بما في ذلك الكثير من شبكات LTE
الصفات.

ضبط LTE ماك جدولة
هناك عدة أنواع يمكن لمستخدم جدولة LTE MAC الاختيار منها هنا. يمكن للمستخدم استخدام ما يلي
رموز لتحديد نوع الجدولة:

بي تي آر 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::

بي تي آر lteHelper = CreateObject ()؛
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(yourvalue)); // القيمة الافتراضية -625000 بايت (-5 ميجابايت)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(yourvalue)); // القيمة الافتراضية 625000 بايت (5 ميجابايت)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(yourvalue)); // القيمة الافتراضية 1 بايت
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(yourvalue)); // القيمة الافتراضية 0

* جدولة PSS::

بي تي آر 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) في جودة الخدمة لحامل epc
حدود. يمكن للمستخدمين استخدام الرموز التالية لتعريف GBR وMBR في كل من الوصلة الهابطة و
الوصلة الصاعدة:

بي تي آر lteHelper = CreateObject ()؛
enum EpsBearer::Qci q = EpsBearer::yourvalue; // تحديد نوع Qci
GbrQosInformation qos;
qos.gbrDl = yourvalue; // الوصلة الهابطة GBR
qos.gbrUl = yourvalue; // الإرسال GBR
qos.mbrDl = yourvalue; // الوصلة الهابطة MBR
qos.mbrUl = yourvalue; // الإرسال MBR
حامل EpsBearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, Bearer, EpcTft::Default ());

في PSS، يتم الحصول على TBR من GBR في معلمات جودة الخدمة على مستوى الحامل. في TBFQ، إنشاء الرمز المميز
يتم الحصول على المعدل من إعداد MBR في معلمات جودة الخدمة على مستوى الحامل، وبالتالي
يحتاج إلى تكوين باستمرار. ويُقترح ذلك بالنسبة لحركة معدل البتات الثابت (CBR).
لتعيين MBR إلى GBR. بالنسبة لحركة معدل بتات التباين (VBR)، يقترح تعيين MBR k مرات
أكبر من GBR من أجل تغطية معدل حركة المرور الذروة. في التنفيذ الحالي، k هو
مضبوطة على ثلاثة على الورق [FABokhari2009]. بالإضافة إلى ذلك، الإصدار الحالي من TBFQ لا يفعل ذلك
خذ بعين الاعتبار رأس RLC وطول رأس PDCP في MBR وGBR. معلمة أخرى في TBFQ هي
معدل وصول الحزمة يتم حساب هذه المعلمة ضمن المجدول وتساوي الماضي
متوسط ​​الإنتاجية المستخدمة في جدولة PF.

سيتم وصف العديد من السمات المفيدة لنموذج LTE-EPC فيما يلي
الأقسام الفرعية. ومع ذلك، هناك العديد من الصفات التي لم يتم ذكرها صراحة في
التصميم أو وثائق المستخدم، ولكن تم توثيقها بوضوح باستخدام السمة ns-3
نظام. يمكنك بسهولة طباعة قائمة بسمات كائن معين مع
وصفهم وتمرير القيمة الافتراضية --PrintAttributes= إلى برنامج محاكاة
مثله:

./waf --تشغيل lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

يمكنك أيضًا تجربة كائنات LTE وEPC الأخرى، مثل هذا:

./waf --تشغيل lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --تشغيل 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 --تشغيل lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

محاكاة الناتج
يدعم طراز ns-3 LTE حاليًا الإخراج إلى ملف بمستوى PHY وMAC وRLC وPDCP
مؤشرات الأداء الرئيسية (KPIs). يمكنك تمكينه بالطريقة التالية:

بي تي آر lteHelper = CreateObject ()؛

// قم بتكوين كل سيناريو المحاكاة هنا...

lteHelper->EnablePhyTraces();
lteHelper->EnableMacTraces();
lteHelper->EnableRlcTraces();
lteHelper->EnablePdcpTraces();

محاكي :: تشغيل () ؛

يتم حساب مؤشرات الأداء الرئيسية RLC وPDCP على مدار فترة زمنية ويتم تخزينها في ملفات ASCII، اثنان منها لـ
مؤشرات الأداء الرئيسية لـ RLC واثنتين لمؤشرات الأداء الرئيسية لـ PDCP، في كل حالة واحدة للوصلة الصاعدة وواحدة للوصلة الهابطة. الوقت
يمكن التحكم في مدة الفاصل الزمني باستخدام السمة
ns3::RadioBearerStatsCalculator::EpochDuration.

أعمدة ملفات RLC KPI هي كما يلي (نفس الشيء بالنسبة للوصلة الصاعدة والوصلة الهابطة):

1. وقت بدء فاصل القياس بالثواني منذ بدء المحاكاة

2. وقت انتهاء فترة القياس بالثواني منذ بدء المحاكاة

3 معرف الخلية

4. معرف UE الفريد (IMSI)

5. معرف UE الخاص بالخلية (RNTI)

6. معرف القناة المنطقية

7. عدد وحدات PDU RLC المرسلة

8. إجمالي البايتات المرسلة.

9. عدد وحدات PDU RLC المستلمة

10. إجمالي البايتات المستلمة

11. متوسط ​​تأخير RLC PDU بالثواني

12. الانحراف المعياري لتأخير RLC PDU

13. الحد الأدنى لقيمة تأخير RLC PDU

14. الحد الأقصى لقيمة تأخير RLC PDU

15. متوسط ​​حجم RLC PDU، بالبايت

16. الانحراف المعياري لحجم RLC PDU

17. الحد الأدنى لحجم RLC PDU

18. الحد الأقصى لحجم RLC PDU

وبالمثل، فإن أعمدة ملفات PDCP KPI هي التالية (مرة أخرى، نفس الشيء بالنسبة للوصلة الصاعدة
والوصلة الهابطة):

1. وقت بدء فاصل القياس بالثواني منذ بدء المحاكاة

2. وقت انتهاء فترة القياس بالثواني منذ بدء المحاكاة

3 معرف الخلية

4. معرف UE الفريد (IMSI)

5. معرف UE الخاص بالخلية (RNTI)

6. معرف القناة المنطقية

7. عدد وحدات PDU PDCP المرسلة

8. إجمالي البايتات المرسلة.

9. عدد وحدات PDU PDCP المستلمة

10. إجمالي البايتات المستلمة

11. متوسط ​​تأخير PDCP PDU بالثواني

12. الانحراف المعياري لتأخير PDCP PDU

13. الحد الأدنى لقيمة تأخير PDCP PDU

14. الحد الأقصى لقيمة تأخير PDCP PDU

15. متوسط ​​حجم PDCP PDU، بالبايت

16. الانحراف المعياري لحجم PDCP PDU

17. الحد الأدنى لحجم PDCP PDU

18. الحد الأقصى لحجم PDCP PDU

مؤشرات الأداء الرئيسية لـ MAC هي في الأساس تتبع لتخصيص الموارد الذي أبلغ عنه المجدول
بداية كل إطار فرعي. يتم تخزينها في ملفات ASCII. بالنسبة لمؤشرات الأداء الرئيسية لـ MAC للوصلة الهابطة، فإن
التنسيق هو ما يلي:

1. وقت المحاكاة بالثواني التي تتم فيها الإشارة إلى التخصيص بواسطة المجدول

2 معرف الخلية

3. معرف UE الفريد (IMSI)

4. رقم الإطار

5. رقم الإطار الفرعي

6. معرف UE الخاص بالخلية (RNTI)

7. MCS من السل 1

8. حجم السل 1

9. MCS لـ TB 2 (0 إذا لم يكن موجودًا)

10. حجم السل 2 (0 إذا لم يكن موجودا)

بينما بالنسبة لمؤشرات الأداء الرئيسية لـ MAC للوصلة الصاعدة، يكون التنسيق هو:

1. وقت المحاكاة بالثواني التي تتم فيها الإشارة إلى التخصيص بواسطة المجدول

2 معرف الخلية

3. معرف UE الفريد (IMSI)

4. رقم الإطار

5. رقم الإطار الفرعي

6. معرف UE الخاص بالخلية (RNTI)

7. مرض السل

8. حجم السل

يمكن تخصيص أسماء الملفات المستخدمة لإخراج MAC KPI عبر سمات ns-3
ns3::MacStatsCalculator::DlOutputFilename ns3::MacStatsCalculator::UlOutputFilename.

يتم توزيع مؤشرات الأداء الرئيسية لـ PHY في سبعة ملفات مختلفة، قابلة للتكوين من خلال السمات

1. ns3::PhyStatsCalculator::DlRsrpSinrFilename

2. ns3::PhyStatsCalculator::UeSinrFilename

3. ns3::PhyStatsCalculator::InterferenceFilename

4. ns3::PhyStatsCalculator::DlTxOutputFilename

5. ns3::PhyStatsCalculator::UlTxOutputFilename

6. ns3::PhyStatsCalculator::DlRxOutputFilename

7. ns3::PhyStatsCalculator::UlRxOutputFilename

في ملف RSRP/SINR، يتوفر المحتوى التالي:

1. وقت المحاكاة بالثواني التي تتم فيها الإشارة إلى التخصيص بواسطة المجدول

2 معرف الخلية

3. معرف UE الفريد (IMSI)

4. آر إس آر بي

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. إم سي إس

7. حجم السل

8. نسخة التكرار

9. علامة مؤشر البيانات الجديدة

وأخيرًا، في ملفات الاستقبال UL وDL، المعلمات المضمنة هي:

1. وقت المحاكاة بالمللي ثانية

2 معرف الخلية

3. معرف UE الفريد (IMSI)

4. RNTI

5. وضع النقل

6. طبقة الإرسال

7. إم سي إس

8. حجم السل

9. نسخة التكرار

10. علامة مؤشر البيانات الجديدة

11. الصواب في استقبال السل

ذبول أثر الأستعمال
سنصف في هذا القسم كيفية استخدام آثار الخبو في عمليات محاكاة LTE.

ذبول آثار جيل
من الممكن إنشاء آثار يتلاشى باستخدام برنامج نصي MATLAB مخصص متوفر مع
الرمز (/lte/model/fading-traces/fading-trace-generator.m). يتضمن هذا البرنامج النصي بالفعل
تكوينات الصنابير النموذجية لثلاثة سيناريوهات 3GPP (أي المشاة والمركبات و
حضري كما هو محدد في الملحق ب.2 من [TS36104])؛ ومع ذلك، يمكن للمستخدمين أيضًا تقديم ملفات تعريف الارتباط الخاصة بهم
تكوينات محددة. يتم توفير قائمة المعلمات القابلة للتكوين في
التالية:

· fc : التردد المستخدم (يؤثر على حساب سرعة دوبلر).

· v_km_h : سرعة المستخدمين

· TraceDuration : المدة بالثواني من إجمالي طول التتبع.

· numRBs : عدد كتلة الموارد المراد تقييمها.

· بطاقة : العلامة التي سيتم تطبيقها على الملف الذي تم إنشاؤه.

يحتوي الملف الذي تم إنشاؤه على قيم حقيقية بتنسيق ASCII منظمة بطريقة المصفوفة:
يتوافق كل صف مع RB مختلف، وكل عمود يتوافق مع مختلف
عينة تتبع التلاشي الزمني.

تجدر الإشارة إلى أن وحدة ns-3 LTE قادرة على العمل مع أي ملف تتبع يتلاشى
يتوافق مع تنسيق ASCII الموصوف أعلاه. وبالتالي، يمكن أن تكون الأدوات الخارجية الأخرى
تُستخدم لإنشاء آثار خبو مخصصة، مثل أجهزة المحاكاة الأخرى أو
الأجهزة التجريبية.

ذبول آثار الأستعمال
عند استخدام أثر الخبو، من الأهمية بمكان تحديد التتبع بشكل صحيح
المعلمات في المحاكاة، بحيث يمكن تحميل نموذج التلاشي واستخدامه بشكل صحيح. ال
المعلمات التي سيتم تكوينها هي:

· TraceFilename : اسم التتبع المراد تحميله (المسار المطلق، أو المسار النسبي
اكتب المسار من حيث يتم تنفيذ برنامج المحاكاة)؛

· طول التتبع : مدة التتبع بالثواني؛

· عدد العينات : عدد العينات؛

· بحجم النافذه : حجم نافذة أخذ العينات المتلاشية بالثواني؛

ومن المهم التأكيد على أن الفاصل الزمني لمعاينة أثر الخبو يجب أن يكون 1 مللي ثانية
أو أكبر، وفي الحالة الأخيرة يجب أن يكون عددًا صحيحًا مضاعفًا لـ 1 مللي ثانية لكي يكون
تمت معالجتها بشكل صحيح بواسطة وحدة التلاشي.

يوفر التكوين الافتراضي للبرنامج النصي MATLAB تتبعًا مدته 10 ثوانٍ، مصنوعًا من
10,000 عينة (على سبيل المثال، عينة واحدة لكل TTI = 1 مللي ثانية) وتستخدم بحجم نوافذ يبلغ 1 ثانية
السعة. هذه أيضًا هي القيم الافتراضية للمعلمات المذكورة أعلاه المستخدمة في ملف
محاكاة؛ ولذلك يمكن تجنب استقرارها في حالة احترام أثر الذبول لها.

من أجل تفعيل وحدة التلاشي (التي تكون غير نشطة افتراضيًا)، أدخل الكود التالي
ينبغي تضمينها في برنامج المحاكاة:

بي تي آر lteHelper = CreateObject ()؛
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

ولضبط المعلمات:

lteHelper->SetFadingModelAttribute ("TraceFilename"، StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"))؛
lteHelper->SetFadingModelAttribute ("TraceLength"، TimeValue (Seconds (10.0)))؛
lteHelper->SetFadingModelAttribute ("SamplesNum"، UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("WindowSize"، TimeValue (Seconds (0.5)));
lteHelper->SetFadingModelAttribute("RbNum"، UintegerValue (100));

ولا بد من الإشارة إلى أنه، TraceFilename ليس لها قيمة افتراضية، وبالتالي لا بد من ذلك
يتم تعيينها دائمًا بشكل صريح.

يوفر جهاز المحاكاة في الأصل ثلاثة آثار للتلاشي تم إنشاؤها وفقًا لـ
التكوينات المحددة في الملحق ب.2 من [TS36104]. هذه الآثار متوفرة في
مجلد src/lte/model/fading-traces/). ويرد مقتطف من هذه الآثار في
الأرقام التالية.
[صورة: أثر التلاشي بسرعة 3 كيلومتر في الساعة] [صورة] مقتطف من أثر التلاشي المتضمن في
محاكاة لسيناريو المشاة (سرعة 3 كم في الساعة)..UNINDENT
[صورة: أثر التلاشي بسرعة 60 كيلومتر في الساعة] [صورة] مقتطف من أثر التلاشي المتضمن في
محاكاة لسيناريو المركبات (سرعة 60 كم في الساعة)..UNINDENT
[صورة: أثر التلاشي بسرعة 3 كيلومتر في الساعة] [صورة] مقتطف من أثر التلاشي المتضمن في
محاكاة للسيناريو الحضري (سرعة 3 كم في الساعة)..UNINDENT

التحرك الموديل مع المباني
نوضح الآن بالأمثلة كيفية استخدام نموذج المباني (على وجه الخصوص، نموذج
معلومات بناء التنقل و نموذج نشر البناء الطبقات) في محاكاة NS-3
برنامج لإعداد سيناريو محاكاة LTE يتضمن المباني والعقد الداخلية.

1. ملفات الرأس المراد تضمينها:

#يشمل
#يشمل
#يشمل

2. اختيار نموذج Pathloss:

بي تي آر lteHelper = CreateObject ()؛

lteHelper->SetAttribute ("PathlossModel"، StringValue ("ns3::BuildingsPropagationLossModel"))؛

3. اختيار نطاق EUTRA

يجب أن يتم اختيار تردد العمل لنموذج الانتشار باستخدام
نظام السمات ns-3 القياسي كما هو موضح في القسم المقابل ("تكوين
معلمات طراز LTE") عن طريق معلمات DlEarfcn وUlEarfcn، على سبيل المثال:

lteHelper->SetEnbDeviceAttribute ("DlEarfcn"، UintegerValue (100));
lteHelper->SetEnbDeviceAttribute ("UlEarfcn"، UintegerValue (18100));

تجدر الإشارة إلى أن استخدام وسائل أخرى لتكوين التردد المستخدم من قبل
نموذج الانتشار (أي تكوين ملف BuildingsPropagationLossModel المقابل).
السمات مباشرة) قد يؤدي إلى حدوث تعارضات في تعريف الترددات في ملف
وحدات أثناء المحاكاة، وبالتالي لا ينصح.

1. اختيار نموذج التنقل:

التنقل
التنقل.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؛
بي تي آر ب = إنشاء كائن ()؛
ب->SetBoundaries (Box (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
ب->SetExtWallsType (Building::ConcreteWithWindows);
ب->SetNFloors (3)؛
ب->SetNRoomsX (3);
ب->SetNRoomsY (2);

سيؤدي ذلك إلى إنشاء مبنى سكني بقاعدة تبلغ 10 × 20 مترًا وارتفاعه
10 أمتار جدرانها الخارجية من الخرسانة مع النوافذ؛ المبنى لديه ثلاثة
طوابق وبها شبكة داخلية 3 × 2 من الغرف متساوية الحجم.

3. إنشاء العقدة وتحديد موضعها:

ueNodes.Create (2);
التنقل. التثبيت (ueNodes)؛
BuildingsHelper::Install (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
بي تي آر mm0 = enbNodes.Get (0)->GetObject ()؛
بي تي آر mm1 = enbNodes.Get (1)->GetObject ()؛
mm0->SetPosition (المتجه (5.0، 5.0، 1.5))؛
mm1->SetPosition (المتجه (30.0، 40.0، 1.5))؛

4. الانتهاء من تكوين نموذج البناء والتنقل:

BuildingsHelper::MakeMobilityModelConsistent ();

راجع توثيق البنايات وحدة للحصول على معلومات أكثر تفصيلا.

فيز خطأ الموديل
يتكون نموذج الخطأ المادي من نموذج خطأ البيانات وخطأ التحكم في الوصلة الهابطة
النموذج، وكلاهما نشط بشكل افتراضي. من الممكن إلغاء تنشيطها باستخدام ns3
نظام السمات بالتفصيل:

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

MIMO الموديل
في هذا القسم الفرعي نوضح كيفية تكوين معلمات MIMO. يحدد LTE 7 أنواع
وسائط الإرسال:

· وضع النقل 1: SISO.

· وضع النقل 2: تنوع MIMO Tx.

· وضع النقل 3: حلقة مفتوحة لتعدد الإرسال المكاني MIMO.

· وضع الإرسال 4: حلقة مغلقة لتعدد الإرسال المكاني MIMO.

· وضع النقل 5: MIMO متعدد المستخدمين.

· وضع الإرسال 6: طبقة واحدة أقرب للتشفير المسبق.

· وضع النقل 7: منفذ هوائي واحد 5.

وفقًا للنموذج المطبق، يتضمن جهاز المحاكاة أوضاع النقل الثلاثة الأولى
أنواع. الوضع الافتراضي هو وضع النقل 1 (SISO). من أجل تغيير الافتراضي
وضع النقل الذي سيتم استخدامه، السمة وضع الإرسال الافتراضي ل LteEnbRrc يمكن
واستخدامها، كما هو موضح في ما يلي:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (0)); // سيسو
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (1)); // تنوع MIMO Tx (طبقة واحدة)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode"، UintegerValue (2)); // تعدد الإرسال المكاني MIMO (طبقتان)

لتغيير وضع الإرسال لمستخدم معين أثناء المحاكاة
تم تنفيذ الواجهة في كلا الجدولتين القياسيتين:

باطلة TransmissionModeConfigurationUpdate (uint16_t rnti، uint8_t txMode)؛

يمكن استخدام هذه الطريقة لتطوير محرك قرار وضع النقل (على سبيل المثال
تحسين وضع الإرسال وفقًا لحالة القناة و/أو حالة المستخدم
المتطلبات) وللتحويل اليدوي من برنامج المحاكاة النصي. وفي الحالة الأخيرة،
ويمكن إجراء التبديل كما هو موضح في ما يلي:

بي تي آر lteEnbDev = enbDevs.Get (0)->GetObject ()؛
PointerValue ptrval;
enbNetDev->GetAttribute ("FfMacScheduler"، ptrval)؛
بي تي آر rsched = ptrval.Get ()؛
Simulator::Schedule (Seconds (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 من أجل تصميم نموذج
قطاع 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 ديسيبل، على سبيل المثال، لـ 60 درجة
عرض الحزمة كسب الهوائي بزاوية m
30 درجة من اتجاه الاتجاه -3 ديسيبل.

لإنشاء موقع متعدد القطاعات، تحتاج إلى إنشاء عقد ns-3 مختلفة موضوعة في نفس الوقت
الموقف، وتكوين منفصلة EnbNetDevice مع اتجاهات هوائي مختلفة ليكون
مثبتة على كل عقدة.

راديو البيئة برنامج Maps
باستخدام الطبقة راديو البيئةMapHelper فمن الممكن لإخراج ملف الراديو
خريطة البيئة (REM)، أي شبكة موحدة ثنائية الأبعاد من القيم التي تمثل البيئة
نسبة الإشارة إلى الضوضاء في الوصلة الهابطة مقارنة بـ eNB التي لديها الأقوى
إشارة في كل نقطة. من الممكن تحديد ما إذا كان يجب إنشاء REM للبيانات أم لا
قناة التحكم. يمكن للمستخدم أيضًا تعيين RbId الذي سيتم إنشاء REM له. معرف Rb الافتراضي
هو -1، ما يعني أنه سيتم إنشاء REM بمتوسط ​​نسبة الإشارة إلى الضوضاء من الكل
الموارد الطبيعية.

للقيام بذلك، تحتاج فقط إلى إضافة الكود التالي إلى برنامج المحاكاة الخاص بك نحو
النهاية، مباشرة قبل استدعاء Simulator::Run ():

بي تي آر 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 ();

من خلال تكوين سمات راديو البيئةMapHelper الكائن كما هو موضح أعلاه، أنت
يمكن ضبط معلمات REM المراد إنشاؤها. لاحظ أن كل
راديو البيئةMapHelper يمكن للمثيل إنشاء REM واحد فقط؛ إذا كنت تريد توليد المزيد
REMs، تحتاج إلى إنشاء مثيل واحد منفصل لكل REM.

لاحظ أن جيل REM متطلب للغاية، على وجه الخصوص:

· يبلغ استهلاك الذاكرة أثناء التشغيل حوالي 5 كيلو بايت لكل بكسل. على سبيل المثال، حركة العين السريعة
بدقة 500 × 500 ستحتاج إلى حوالي 1.25 جيجابايت من الذاكرة، ودقة تبلغ
سيحتاج 1000 × 1000 إلى حوالي 5 جيجابايت (وهو عدد كبير جدًا بالنسبة لجهاز كمبيوتر عادي في ذلك الوقت
كتابة). للتغلب على هذه المشكلة، يتم إنشاء REM في خطوات متتالية، مع كل منها
خطوة تقوم بتقييم عدد وحدات البكسل على الأكثر والتي تحددها قيمة
السمة RadioEnvironmentMapHelper::MaxPointsPerIteration.

· إذا قمت بإنشاء حركة REM في بداية المحاكاة، فسوف يؤدي ذلك إلى إبطاء عملية المحاكاة
تنفيذ بقية المحاكاة. إذا كنت ترغب في إنشاء REM لبرنامج ما
وأيضا استخدام نفس البرنامج للحصول على نتيجة المحاكاة، فمن المستحسن إضافة
مفتاح سطر الأوامر الذي يسمح إما بإنشاء REM أو تشغيل الملف بالكامل
محاكاة. ولهذا الغرض، لاحظ أن هناك سمة
RadioEnvironmentMapHelper::StopWhenDone (الافتراضي: صحيح) من شأنه أن يجبر
محاكاة للتوقف مباشرة بعد إنشاء REM.

يتم تخزين REM في ملف ASCII بالتنسيق التالي:

· العمود 1 هو الإحداثي x

· العمود 2 هو إحداثي y

· العمود 3 هو الإحداثي z

· العمود 4 هو SINR بالوحدات الخطية

فيما يلي الحد الأدنى من البرنامج النصي gnuplot الذي يسمح لك برسم REM:

تعيين خريطة العرض؛
تعيين xlabel "X"
تعيين التسمية "Y"
ضبط cblabel "SINR (ديسيبل)"
مفتاح غير محدد
مؤامرة "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 وeNBs و
المباني الموجودة أعلى REM:

gnuplot -p enbs.txt ues.txt Buildings.txt my_plot_script

AMC الموديل CQI عملية حسابية
يوفر جهاز المحاكاة مخططين محتملين لما يتعلق باختيار MCSs
وبالمقابل جيل CQIs. الأول يعتمد على وحدة GSoC
[Piro2011] ويعمل على أساس RB. يمكن تفعيل هذا النموذج باستخدام السمة ns3
النظام، كما هو مبين في ما يلي:

التكوين::SetDefault ("ns3::LteAmc::AmcModel"، EnumValue (LteAmc::PiroEW2010));

بينما يمكن التحكم في الحل المبني على نموذج الخطأ المادي من خلال:

التكوين::SetDefault ("ns3::LteAmc::AmcModel"، EnumValue (LteAmc::MiErrorModel));

وأخيراً الكفاءة المطلوبة لل بيروEW2010 يمكن ضبط وحدة AMC بفضل
البر السمة ()، على سبيل المثال:

التكوين::SetDefault ("ns3::LteAmc::Ber"، DoubleValue (0.00005));

تطورت رزمة جوهر (EPC)
نشرح الآن كيفية كتابة برنامج محاكاة يسمح بمحاكاة EPC فيه
بالإضافة إلى شبكة الوصول إلى الراديو LTE. يسمح استخدام EPC باستخدام شبكات IPv4
مع أجهزة LTE. بمعنى آخر، سوف تكون قادرًا على استخدام تطبيقات ns-3 العادية
والمآخذ عبر IPv4 عبر LTE، وأيضًا لتوصيل شبكة LTE بأي IPv4 آخر
الشبكة التي قد تكون لديك في المحاكاة الخاصة بك.

بادئ ذي بدء، بالإضافة إلى LteHelper التي قدمناها بالفعل Basic محاكاة
برنامج، تحتاج إلى استخدام إضافية EpcHelper الطبقة التي سوف تهتم بالإنشاء
كيانات EPC وطوبولوجيا الشبكة. لاحظ أنه لا يمكنك استخدام EpcHelper مباشرة ، كما هو
هي فئة أساسية مجردة. بدلاً من ذلك، تحتاج إلى استخدام إحدى فئاته الفرعية، والتي
توفير تطبيقات طوبولوجيا EPC مختلفة. في هذا المثال سننظر
PointToPointEpcHelper، الذي ينفذ EPC استنادًا إلى الروابط من نقطة إلى نقطة. لتستخدمها،
تحتاج أولاً إلى إدخال هذا الرمز في برنامج المحاكاة الخاص بك:

بي تي آر lteHelper = CreateObject ()؛
بي تي آر epcHelper = CreateObject ()؛

بعد ذلك، يتعين عليك إخبار مساعد LTE أنه سيتم استخدام EPC:

lteHelper->SetEpcHelper (epcHelper);

تعد الخطوة المذكورة أعلاه ضرورية حتى يتمكن مساعد LTE من تشغيل EPC المناسب
التكوين في المراسلات مع بعض التكوين المهم، مثل عندما يكون eNB جديد
أو تتم إضافة UE إلى المحاكاة، أو يتم إنشاء حامل EPS. سيقوم مساعد EPC بذلك
يعتني تلقائيًا بالإعدادات الضرورية، مثل إنشاء رابط S1 وحامل S1
يثبت. وكل هذا سيتم دون تدخل المستخدم.

دعوة lteHelper->SetEpcHelper (epcHelper) تمكن من استخدام EPC، ولها الجانب
تأثير أي جديد LteEnbRrc الذي تم إنشاؤه سيكون له EpsBearerToRlcMapping
السمة المحددة ل RLC_UM_ALWAYS بدلا من RLC_SM_ALWAYS إذا كان الأخير هو الافتراضي؛
وإلا فلن يتم تغيير السمة (على سبيل المثال، إذا قمت بتغيير الإعداد الافتراضي إلى
RLC_AM_ALWAYS، لن يتم لمسها).

من الجدير بالذكر أن ملف EpcHelper سيقوم أيضًا تلقائيًا بإنشاء عقدة PGW و
قم بتكوينه بحيث يمكنه التعامل بشكل صحيح مع حركة المرور من/إلى شبكة الوصول إلى الراديو LTE.
ومع ذلك، فأنت بحاجة إلى إضافة بعض التعليمات البرمجية الواضحة لتوصيل PGW بشبكات IPv4 الأخرى (على سبيل المثال،
الإنترنت). فيما يلي مثال بسيط جدًا حول كيفية توصيل مضيف بعيد واحد به
PGW عبر رابط من نقطة إلى نقطة:

بي تي آر pgw = epcHelper->GetPgwNode();

// قم بإنشاء RemoteHost واحد
NodeContainer RemoteHostContainer;
RemoteHostContainer.Create (1);
بي تي آر RemoteHost = RemoteHostContainer.Get (0);
إنترنت InternetStackHelper ؛
internet.Install (remoteHostContainer)؛

// إنشاء الإنترنت
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("DataRate"، DataRateValue (DataRate ("100 جيجابايت/ثانية")))؛
p2ph.SetDeviceAttribute ("Mtu"، UintegerValue (1500))؛
p2ph.SetChannelAttribute ("Delay"، TimeValue (Seconds (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);

من المهم تحديد المسارات حتى يتمكن المضيف البعيد من الوصول إلى LTE UEs. طريقة واحدة ل
القيام بذلك عن طريق استغلال حقيقة أن PointToPointEpcHelper سيتم تعيينه بشكل افتراضي
إلى LTE UEs عنوان IP في شبكة 7.0.0.0. ومع أخذ ذلك في الاعتبار، يكفي القيام بما يلي:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
بي تي آر RemoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
RemoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0")، Ipv4Mask ("255.0.0.0")، 1)؛

الآن، يجب عليك المتابعة وإنشاء LTE eNBs وUEs كما هو موضح في الأقسام السابقة.
يمكنك بالطبع تكوين جوانب LTE الأخرى مثل نماذج فقدان المسار والتلاشي. يمين
بعد إنشاء وحدات UE، يجب عليك أيضًا تكوينها لشبكات IP. لقد انتهى هذا
على النحو التالي. نفترض أن لديك حاوية لعقد UE وeNodeB مثل هذا:

NodeContainer ueNodes;
NodeContainer enbNodes;

لتكوين محاكاة LTE فقط، عادةً ما تفعل شيئًا مثل هذا:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper->Attach (ueLteDevs, enbLteDevs.Get (0));

من أجل تكوين وحدات المستعمل لشبكات IP، ما عليك سوى القيام بما يلي أيضًا
هذه:

// نقوم بتثبيت مكدس IP على وحدات UE
إنترنت InternetStackHelper ؛
internet.Install (ueNodes)؛

// تعيين عنوان IP لوحدات UE
for (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
بي تي آر ue = ueNodes.Get(u);
بي تي آر ueLteDevice = ueLteDevs.Get(u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// قم بتعيين البوابة الافتراضية لـ UE
بي تي آر ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress(), 1);
}

يتم تفعيل الحاملين بطريقة مختلفة قليلاً فيما يتعلق بما تم القيام به
لمحاكاة LTE فقط. أولاً، لا ينبغي استخدام الطريقة ActivateDataRadioBearer
عندما يتم استخدام EPC. ثانيًا، عند استخدام EPC، سيتم تنشيط حامل EPS الافتراضي
تلقائيًا عند الاتصال بـ LteHelper::Attach (). ثالثا، إذا كنت ترغب في الإعداد المخصص
حامل EPS، يمكنك القيام بذلك باستخدام الطريقة LteHelper::ActivateDedicatedEpsBearer (). هذا
تأخذ الطريقة كمعلمة قالب تدفق حركة المرور (TFT)، وهو عبارة عن بنية
يحدد نوع حركة المرور التي سيتم تعيينها إلى حامل EPS المخصص. هنا
مثال لكيفية إعداد حامل مخصص لتطبيق ما في تجهيزات المستعمل (UE) للتواصل
المنفذ 1234:

بي تي آر 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 المعتادة.
باتباع مثالنا البسيط مع مضيف بعيد واحد، إليك كيفية إعداد الوصلة الهابطة
الاتصال، مع تطبيق UdpClient على المضيف البعيد، وPacketSink على
LTE UE (باستخدام نفس الأسماء المتغيرة لمقتطفات التعليمات البرمجية السابقة)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory"،
InetSocketAddress (Ipv4Address::GetAny(), dlPort));
ApplicationContainer serverApps = packetSinkHelper.Install (ue);
serverApps.Start (Seconds (0.01));
عميل UdpClientHelper (ueIpIface.GetAddress (0)، dlPort)؛
ApplicationContainer clientApps = client.Install (remoteHost)؛
ClientApps.Start (ثواني (0.01))؛

هذا كل شئ! يمكنك الآن بدء المحاكاة كالمعتاد:

محاكي::توقف (ثواني (10.0))؛
محاكي :: تشغيل () ؛

باستخدام هيه EPC مع محاكاة طريقة
في القسم السابق استخدمنا روابط PointToPoint للاتصال بين eNBs و
SGW (واجهة S1-U) وبين eNBs (واجهات X2-U وX2-C). وحدة LTE
يدعم استخدام الروابط التي تمت محاكاتها بدلاً من روابط PointToPoint. يتم تحقيق ذلك عن طريق فقط
استبدال إنشاء LteHelper EpcHelper مع الكود التالي:

بي تي آر lteHelper = CreateObject ()؛
بي تي آر epcHelper = CreateObject ()؛
lteHelper->SetEpcHelper (epcHelper);
epcHelper->Initialize ();

السمات ns3::EmuEpcHelper::sgwDeviceName ns3::EmuEpcHelper::enbDeviceName .
يُستخدم لتعيين اسم الأجهزة المستخدمة لنقل S1-U وX2-U وX2-C
واجهات في SGW وeNB، على التوالي. سنبين الآن كيف يتم ذلك في
مثال حيث نقوم بتنفيذ البرنامج المثال لينا-بسيطة-epc-emu باستخدام اثنين من الظاهري
واجهات إيثرنت.

بادئ ذي بدء، قمنا ببناء ns-3 بشكل مناسب:

# تهيئة
./waf تكوين --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# يبني
./waff

بعد ذلك، نقوم بإعداد واجهتي إيثرنت افتراضيتين، ونبدأ في استخدام wireshark لمراقبة حركة المرور
يعبر من خلال:

#ملاحظة: يجب أن تكون جذرًا

# إنشاء جهازين بيطريين مقترنين
رابط IP إضافة اسم veth0 نوع veth اسم النظير veth1
عرض رابط ip

# تمكين الوضع المختلط
تم ضبط رابط IP على veth0 promisc
تم ضبط رابط IP على veth1 promisc

#إظهار الواجهات
تم تعيين رابط IP veth0
تم تعيين رابط IP veth1

# ابدأ wireshark والتقطه على veth0
واير شارك &

يمكننا الآن تشغيل البرنامج النموذجي باستخدام الساعة المحاكاة:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

باستخدام wireshark، يجب أن ترى دقة ARP أولاً، ثم يتم تبادل كليهما مع بعض حزم GTP
في الوصلة الصاعدة والوصلة الهابطة.

الإعداد الافتراضي لبرنامج المثال هو 1 eNB و1UE. يمكنك تغيير هذا عبر
معلمات سطر الأوامر، على سبيل المثال:

./waf --تشغيل lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

للحصول على قائمة بالمعلمات المتاحة:

./waf --تشغيل lena-simple-epc-emu --command="%s --PrintHelp"

للتشغيل مع ساعة الوقت الفعلي: اتضح أن إنشاء تصحيح الأخطاء الافتراضي بطيء جدًا
في الوقت الحالى. إن تخفيف قيود الوقت الفعلي باستخدام وضع BestEffort ليس فكرة جيدة:
من الممكن أن يحدث خطأ ما (على سبيل المثال، يمكن أن يفشل ARP)، وإذا كان الأمر كذلك، فلن تحصل على أي حزم بيانات
خارج. لذا فأنت بحاجة إلى جهاز لائق وبنية مُحسّنة مرتبطة بشكل ثابت
الوحدات:

./waf تكوين -d الأمثل --enable-static --enable-modules=lte --enable-examples --enable-sudo

ثم قم بتشغيل البرنامج المثال مثل هذا:

./waf --تشغيل lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImpl --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

لاحظ إعداد HardLimit، الذي سيؤدي إلى إنهاء البرنامج إذا لم يتمكن من المتابعة
مع الوقت الحقيقي.

يمكن استخدام الطريقة الموضحة في هذا القسم مع أي نوع من أجهزة الشبكة. ل
على سبيل المثال، يصف [Baldo2014] كيف تم استخدامه لتشغيل شبكة LTE-EPC التي تمت محاكاتها عبر شبكة
شبكة نقل حزم ضوئية حقيقية متعددة الطبقات.

شبكة المرفق
كما هو موضح في المثال الأساسي في القسم Basic محاكاة برنامج، إرفاق UE بـ
يتم تنفيذ eNodeB عن طريق الاتصال LteHelper::إرفاق وظيفة.

هناك طريقتان ممكنتان للاتصال بالشبكة. الطريقة الأولى هي "يدوي" احد،
بينما الثاني لديه المزيد "تلقائي" الشعور به. سيتم تغطية كل واحد منهم
هذا القسم.

مانيوال التعلق
تستخدم هذه الطريقة LteHelper::إرفاق الوظيفة المذكورة أعلاه. لقد كان الوحيد
طريقة ربط الشبكة المتوفرة في الإصدارات السابقة من وحدة LTE. إنه عادة
يتم استدعاؤه قبل بدء المحاكاة:

lteHelper->Attach (ueDevs, enbDev); // إرفاق واحد أو أكثر من وحدات المستخدم إلى eNodeB واحد

LteHelper::InstallEnbDevice LteHelper::InstallUeDevice يجب أن يتم استدعاء الوظائف
قبل أن تعلق. في المحاكاة التي تدعم EPC، يلزم أيضًا أن يكون لديك IPv4 بشكل صحيح
مثبتة مسبقًا في الاتحاد الأوروبي.

هذه الطريقة بسيطة للغاية، ولكنها تتطلب منك أن تعرف بالضبط أي UE ينتمي إليه
eNodeB قبل بدء المحاكاة. قد يكون هذا صعبًا عندما يكون الوضع الأولي لـ UE
يتم تحديدها عشوائيًا بواسطة برنامج المحاكاة.

يمكن للمرء اختيار المسافة بين UE وeNodeB كمعيار لاختيار
الخلية المناسبة. إنه بسيط جدًا (على الأقل من وجهة نظر المحاكي) و
عملي في بعض الأحيان. ولكن من المهم أن نلاحظ أن المسافة في بعض الأحيان لا تجعل
معيار صحيح واحد على سبيل المثال، ينبغي أن يكون اتجاه هوائي eNodeB
يعتبر كذلك. بالإضافة إلى ذلك، ينبغي للمرء أيضًا أن يأخذ في الاعتبار حالة القناة،
والتي قد تكون متقلبة إذا كان هناك تلاشي أو تظليل ساري المفعول. في هذا النوع من
وفي هذه الحالات، لا ينبغي أن يعتمد الارتباط بالشبكة على المسافة وحدها.

في الحياة الواقعية، سيقوم UE تلقائيًا بتقييم معايير معينة واختيار أفضل خلية لها
إرفاقها دون تدخل يدوي من المستخدم. ومن الواضح أن هذا ليس هو الحال في
LteHelper::إرفاق وظيفة. تستخدم طريقة ربط الشبكة الأخرى المزيد "تلقائي"
طريقة ربط الشبكة كما سيتم شرحها لاحقا.

أوتوماتيك التعلق استخدام الخمول طريقة الخلية اختيار الإجراءات
قوة الإشارة المستقبلة هي المعيار القياسي المستخدم لاختيار الأفضل
خلية لنعلق عليها. يتم تنفيذ استخدام هذا المعيار في في البداية الخلية اختيار
العملية، والتي يمكن استدعاؤها عن طريق استدعاء نسخة أخرى من LteHelper::إرفاق
وظيفة، كما هو مبين أدناه:

lteHelper->Attach (ueDevs); // إرفاق واحد أو أكثر من وحدات المستعمل بأقوى خلية

الفرق مع الطريقة اليدوية هو أن الوجهة eNodeB لم يتم تحديدها. ال
سيجد الإجراء أفضل خلية لوحدات المستعمل، بناءً على عدة معايير، بما في ذلك
قوة الإشارة المستقبلة (RSRP).

بعد استدعاء الطريقة، سيقضي UE بعض الوقت لقياس الخلايا المجاورة،
ومن ثم حاول أن نعلق على أفضل واحد. يمكن العثور على مزيد من التفاصيل في القسم
اختيار الخلية الأولية الثانية لوثائق التصميم.

من المهم ملاحظة أن هذه الطريقة تعمل فقط في عمليات المحاكاة التي تدعم EPC. LTE فقط
يجب أن تلجأ عمليات المحاكاة إلى طريقة المرفقات اليدوية.

مغلق المشترك تجمع
إحدى حالات الاستخدام المثيرة للاهتمام لعملية اختيار الخلايا الأولية هي إعداد محاكاة
البيئة مع مجموعة المشتركين المغلقة (CSG).

على سبيل المثال، قد تنتمي eNodeB معينة، وعادةً ما تكون نسخة أصغر مثل femtocell
لمالك خاص (مثل الأسرة أو الشركة)، مما يسمح بالوصول فقط إلى بعض وحدات المستعمل التي
تم تسجيلها مسبقاً من قبل المالك. eNodeB وUEs المسجلة تمامًا
تشكيل CSG.

يمكن محاكاة تقييد الوصول عن طريق "وضع العلامات" على أعضاء CSG بنفس CSG
بطاقة تعريف. ويتم ذلك من خلال السمات الموجودة في كل من eNodeB وUE، على سبيل المثال باستخدام ملف
متابعيك LteHelper المهام:

// قم بتسمية eNodeBs التالية بهوية CSG بقيمة 1 وتمكين إشارة CSG
lteHelper->SetEnbDeviceAttribute ("CsgId"، UintegerValue (1))؛
lteHelper->SetEnbDeviceAttribute ("CsgIndication"، BooleanValue (true));

// قم بتسمية واحد أو أكثر من وحدات المستعمل بهوية CSG بقيمة 1
lteHelper->SetUeDeviceAttribute ("CsgId"، UintegerValue (1))؛

// تثبيت eNodeBs وUEs
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

ثم قم بتمكين إجراء التحديد الأولي للخلية على وحدات UE:

lteHelper->Attach (csgUeDevs);

يعد ذلك ضروريًا لأن تقييد CSG يعمل فقط مع الطريقة التلقائية للشبكة
مرفق، ولكن ليس بالطريقة اليدوية.

لاحظ أن تعيين إشارة CSG لـ eNodeB على أنها false (القيمة الافتراضية) سيؤدي إلى ذلك
قم بتعطيل التقييد، أي أن أي وحدات مستخدم يمكنها الاتصال بـ eNodeB هذا.

ضبط UE قياسات
يتم تحديد تكوين قياس UE النشط في المحاكاة بواسطة الطريقة المحددة
تسمى "المستهلكين"، مثل خوارزمية التسليم. يمكن للمستخدمين إضافة التكوين الخاص بهم إلى
الإجراء، وهناك عدة طرق للقيام بذلك:

1. التكوين المباشر في كيان eNodeB RRC؛

2. تكوين خوارزمية التسليم الحالية؛ و

3. تطوير خوارزمية تسليم جديدة.

سيغطي هذا القسم الطريقة الأولى فقط. الطريقة الثانية مذكورة في أوتوماتيك
سلم يثير، بينما يتم شرح الطريقة الثالثة بالتفصيل في القسم
خوارزمية التسليم الثانية لوثائق التصميم.

يعمل التكوين المباشر في eNodeB RRC على النحو التالي. يبدأ المستخدم بإنشاء ملف جديد
LteRrcSap::ReportConfigEutra المثال وتمريره إلى LteEnbRrc::AddUeMeasReportConfig
وظيفة. سوف تقوم الدالة بإرجاع measId (هوية القياس) وهي فريدة من نوعها
مرجع التكوين في مثيل eNodeB. يجب أن يتم استدعاء هذه الوظيفة من قبل
تبدأ المحاكاة. وستكون تشكيلة القياس نشطة في جميع وحدات المستعمل المرتبطة بها
eNodeB طوال مدة المحاكاة. أثناء المحاكاة، يمكن للمستخدم
التقاط تقارير القياس التي تنتجها وحدات المستعمل من خلال الاستماع إلى التقارير الموجودة
LteEnbRrc::RecvMeasurementReport مصدر التتبع.

الهيكل ReportConfigEutra يتوافق مع مواصفات 3GPP. تعريف
يمكن العثور على البنية وكل حقل عضو في القسم 6.3.5 من [TS36331].

يقوم نموذج التعليمات البرمجية أدناه بتكوين قياس الحدث A1 RSRP لكل eNodeB داخل
حاوية المشروعات الإنمائية:

LteRrcSap::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;

الأمراض المنقولة جنسيا::ناقل measIdList;

NetDeviceContainer::Iterator it;
لـ (it = devs.Begin ()؛ it != devs.End ()؛ it++)
{
بي تي آر dev = *it;
بي تي آر enbDev = dev->GetObject ()؛
بي تي آر enbRrc = enbDev->GetRrc();

uint8_t measId = enbRrc->AddUeMeasReportConfig (config);
measIdList.push_back (measId); // تذكر معرف القياس الذي تم إنشاؤه

enbRrc->TraceConnect ("RecvMeasurementReport"،
"سياق"،
MakeCallback (&RecvMeasurementReportCallback));
}

لاحظ أنه يتم التعبير عن العتبات كنطاق. في المثال أعلاه، النطاق 41 لـ RSRP
يتوافق مع -100 ديسيبل. التحويل من وإلى تنسيق النطاق يرجع إلى القسم
9.1.4 و9.1.7 من [TS36133]. ال EutranMeasurementMapping فئة لديها عدة ثابتة
الوظائف التي يمكن استخدامها لهذا الغرض.

سيكون لوظيفة رد الاتصال المقابلة تعريف مشابه لما يلي:

باطل
RecvMeasurementReportCallback (سياق سلسلة::std،
uint64_t إيمسي،
uint16_t معرف الخلية،
uint16_t رنتي،
LteRrcSap::MeasurementReport measReport);

ستقوم هذه الطريقة بتسجيل وظيفة رد الاتصال كمستهلك لقياسات تجهيزات المستعمل. في ال
الحالة التي يوجد فيها أكثر من مستهلك واحد في المحاكاة (مثل خوارزمية التسليم)،
سيتم أيضًا التقاط القياسات المخصصة للمستهلكين الآخرين من خلال رد الاتصال هذا
وظيفة. يمكن للمستخدمين الاستفادة من measId المجال الموجود داخل
LteRrcSap::MeasurementReport وسيطة وظيفة رد الاتصال لمعرفة القياس
أدى التكوين إلى تشغيل التقرير.

وبشكل عام، تمنع هذه الآلية مستهلكًا من التدخل مع مستهلك آخر دون علمه
تكوين تقارير المستهلك.

لاحظ أن جزء تكوين التقارير فقط (أي LteRrcSap::ReportConfigEutra) من
معلمة قياسات UE مفتوحة للمستهلكين لتكوينها، في حين أن الأجزاء الأخرى
يتم الاحتفاظ بها مخفية. يعد القيد داخل التردد هو الدافع الرئيسي وراء واجهة برمجة التطبيقات هذه
قرار التنفيذ:

· هناك واحد فقط لا لبس فيه ونهائي قياس موضوع، وبالتالي لا يوجد
تحتاج إلى تكوينه.

· قياس المتطابقات يتم الاحتفاظ بها مخفية بسبب حقيقة أن هناك واحدًا لواحد
رسم الخرائط بين تكوين التقارير وهوية القياس، وبالتالي جديد
يتم إعداد هوية القياس تلقائيًا عند تكوين تقارير جديدة
مخلوق؛

· كمية ترتيب تم تكوينه في مكان آخر، راجع قياسات الأداء الثانية؛ و

· قياس الفجوات غير مدعومة، لأنها تنطبق فقط على الترددات البينية
الإعدادات؛

القائم على X2 سلم
كما هو محدد بواسطة 3GPP، فإن التسليم هو إجراء لتغيير خلية التقديم الخاصة بوحدة المستخدم
وضع متصل. عادةً ما يُطلق على وحدتي eNodeB المشاركين في العملية اسم مصدر
eNodeB و الهدف eNodeB.

من أجل تمكين تنفيذ عملية التسليم المستندة إلى X2 في المحاكاة، هناك نوعان
المتطلبات التي يجب الوفاء بها. أولاً، يجب تمكين EPC في المحاكاة (انظر تطورت
رزمة جوهر (EPC)).

ثانيًا، يجب تكوين واجهة X2 بين وحدتي eNodeB، وهو ما يجب أن يكون كذلك
يتم ذلك بشكل صريح ضمن برنامج المحاكاة:

lteHelper->AddX2Interface (enbNodes);

أين enbNodes هو NodeContainer الذي يحتوي على اثنين من eNodeBs بينهما X2
واجهة ليتم تكوينها. إذا كانت الحاوية تحتوي على أكثر من eNodeBs، فستتم الدالة
سيقوم بإنشاء واجهة X2 بين كل زوج من eNodeBs في الحاوية.

وأخيرًا، يجب تكوين eNodeB المستهدف ليكون "مفتوحًا" لطلب تسليم X2. كل
يكون eNodeB مفتوحًا بشكل افتراضي، لذلك لا توجد حاجة إلى تعليمات إضافية في معظم الحالات. ومع ذلك، المستخدمين
قد يقوم بتعيين eNodeB إلى "مغلق" عن طريق تعيين السمة المنطقية
LteEnbRrc::AdmitHandoverRequest إلى زائف. على سبيل المثال، يمكنك تشغيل لينا-x2-التسليم
البرنامج وتعيين السمة بهذه الطريقة:

NS_LOG=EpcX2:LteEnbRrc ./waf --run lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

بعد استيفاء المتطلبات الثلاثة المذكورة أعلاه، يمكن بدء إجراء التسليم
يدويا أو تلقائيا. وسيتم عرض كل منها في الأقسام الفرعية التالية.

مانيوال سلم يثير
يمكن تشغيل حدث التسليم "يدويًا" ضمن برنامج المحاكاة عن طريق جدولة
حدث تسليم صريح. ال LteHelper يوفر الكائن طريقة ملائمة لـ
جدولة حدث التسليم. على سبيل المثال، لنفترض ذلك ueLteDevs هو
NetDeviceContainer الذي يحتوي على وحدة المستعمل التي سيتم تسليمها، وذلك com.enbLteDevs is
طرق NetDeviceContainer الذي يحتوي على المصدر والهدف eNB. ومن ثم التسليم
عند 0.1s يمكن جدولتها على النحو التالي:

lteHelper->طلب التسليم (الثواني (0.100)،
ueLteDevs.Get (0)،
enbLteDevs.Get (0)،
enbLteDevs.Get (1));

لاحظ أن تجهيزات المستعمل يجب أن تكون متصلة بالفعل بمصدر eNB، وإلا فستتم المحاكاة
سيتم إنهاء مع رسالة خطأ.

للحصول على مثال مع كود المصدر الكامل، يرجى الرجوع إلى لينا-x2-التسليم مثال
برنامج.

أوتوماتيك سلم يثير
يمكن أيضًا تشغيل إجراء التسليم "تلقائيًا" من خلال خدمة eNodeB الخاصة بـ UE.
يعتمد المنطق الكامن وراء المشغل على خوارزمية التسليم النشطة حاليًا في
كيان eNodeB RRC. يمكن للمستخدمين تحديد وتكوين خوارزمية التسليم التي سيتم استخدامها
في المحاكاة، والتي سيتم شرحها بعد قليل في هذا القسم. يمكن للمستخدمين أيضًا اختيار ذلك
كتابة التنفيذ الخاص بهم لخوارزمية التسليم، كما هو موضح في القسم
خوارزمية التسليم الثانية لوثائق التصميم.

يتم اختيار خوارزمية التسليم عبر LteHelper الكائن وخاصته
SetHandoverAlgorithmType الطريقة كما هو موضح أدناه:

بي تي آر lteHelper = CreateObject ()؛
lteHelper->SetHandoverAlgorithmType("ns3::A2A4RsrqHandoverAlgorithm");

قد توفر خوارزمية التسليم المحددة أيضًا العديد من السمات القابلة للتكوين، والتي
يمكن ضبطها على النحو التالي:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold"،
UintegerValue (30)) ؛
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset"،
UintegerValue (1)) ؛

يتم تضمين ثلاثة خيارات لخوارزمية التسليم في وحدة LTE. ال A2-A4-RSRQ
خوارزمية التسليم (المسماة باسم ns3::A2A4RsrqHandoverAlgorithm) هو الخيار الافتراضي، و
لقد تم بالفعل عرض الاستخدام أعلاه.

خيار آخر هو أقوى الخلية خوارزمية التسليم (المسماة باسم
ns3::A3RsrpHandoverAlgorithm)، والتي يمكن تحديدها وتكوينها بواسطة الكود التالي:

lteHelper->SetHandoverAlgorithmType("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("التخلفية"،
قيمة مزدوجة (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger"،
القيمة الزمنية (ملي ثانية (256)))؛

الخيار الأخير هو خيار خاص يسمى لا مرجع خوارزمية التسليم، والتي في الأساس
تعطيل مشغل التسليم التلقائي. وهذا مفيد على سبيل المثال في الحالات التي يكون فيها الدليل
يحتاج مشغل التسليم إلى سيطرة حصرية على جميع قرارات التسليم. ليس لديها أي
سمات قابلة للتكوين. الاستخدام هو كما يلي:

lteHelper->SetHandoverAlgorithmType("ns3::NoOpHandoverAlgorithm");

لمزيد من المعلومات حول سياسة القرار الخاصة بكل خوارزمية تسليم وسماتها،
يرجى الرجوع إلى الأقسام الفرعية الخاصة بكل منها في قسم خوارزمية التسليم الثانية في
توثيق التصميم.

وأخيرا، InstallEnbDevice وظيفة LteHelper سيتم إنشاء مثيل واحد من
خوارزمية التسليم المحددة لكل جهاز eNodeB. بمعنى آخر، تأكد من الاختيار
خوارزمية التسليم الصحيحة قبل الانتهاء منها في السطر التالي من التعليمات البرمجية:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

يمكن العثور على مثال مع كود المصدر الكامل لاستخدام مشغل التسليم التلقائي في
تدابير التسليم لينا-x2 برنامج المثال.

ضبط محاكاة مع سلم
كما هو مذكور في وثائق التصميم، قد يكون التنفيذ الحالي لنموذج التسليم
إنتاج سلوك غير متوقع عند حدوث فشل التسليم. سوف يركز هذا القسم الفرعي على
الخطوات التي يجب أن يأخذها المستخدمون في الاعتبار إذا كانوا يخططون لاستخدام التسليم في حياتهم
المحاكاة.

السبب الرئيسي لفشل التسليم الذي سنعالجه هو الخطأ في الإرسال
رسائل الإشارة المتعلقة بالتسليم أثناء تنفيذ إجراء التسليم. مثل
واضح من الشكل-x2-based-handover-seq-diagram من وثائق التصميم،
هناك الكثير منهم ويستخدمون واجهات وبروتوكولات مختلفة. من أجل خاطر
البساطة، يمكننا أن نفترض بأمان أن واجهة X2 (بين eNodeB المصدر و
الهدف eNodeB) والواجهة S1 (بين eNodeB الهدف وSGW/PGW) مناسبان تمامًا
مستقر. ولذلك سوف نركز اهتمامنا على بروتوكول RRC (بين الاتحاد الأوروبي و
eNodeBs) وإجراءات الوصول العشوائي، والتي يتم نقلها عادةً عبر الهواء
وعرضة لتدهور حالة القناة.

النصائح العامة لتقليل خطأ الإرسال هي ضمان عالي كاف سينر المستوى في كل
الاتحاد الأوروبي. ويمكن القيام بذلك عن طريق التخطيط السليم لطوبولوجيا الشبكة يقلل شبكة
تغطية حفرة. إذا كانت البنية بها فتحة تغطية معروفة، فيجب تكوين تجهيزات المستعمل (UE).
عدم المغامرة في تلك المنطقة.

هناك طريقة أخرى يجب وضعها في الاعتبار وهي تجنب بعد فوات الأوان عمليات التسليم. وبعبارة أخرى، التسليم
يجب أن يحدث ذلك قبل أن تصبح نسبة الإشارة إلى الضوضاء (SINR) الخاصة بتجهيزات المستعمل منخفضة للغاية، وإلا فقد يفشل تجهيزات المستعمل في الاستقبال
أمر التسليم من eNodeB المصدر. تمتلك خوارزميات التسليم وسائل التحكم
مدى سرعة أو تأخر اتخاذ قرار التسليم. على سبيل المثال، خوارزمية تسليم A2-A4-RSRQ
يمكن تهيئتها بحد أعلى لجعلها تقرر التسليم مبكرًا. بصورة مماثلة،
تباطؤ أصغر و/أو وقت تشغيل أقصر في أقوى خوارزمية تسليم الخلية
يؤدي عادةً إلى عمليات تسليم مبكرة. من أجل العثور على القيم الصحيحة لهذه
المعلمات، أحد العوامل التي ينبغي النظر فيها هي سرعة حركة UE.
بشكل عام، يتطلب تجهيز المستعمل الذي يتحرك بشكل أسرع أن يتم تنفيذ عملية التسليم مبكرًا. بعض الأبحاث
وقد اقترح العمل القيم الموصى بها، كما هو الحال في [Lee2010].

النصائح المذكورة أعلاه يجب أن تكون كافية في استخدامات المحاكاة العادية، لكن في هذه الحالة هناك بعض النصائح الخاصة
تنشأ الاحتياجات ثم يمكن اتخاذ إجراء متطرف في الاعتبار. على سبيل المثال، المستخدمين
قد يعتبر تعطيل هيه قناة خطأ عارضات ازياء. وهذا يضمن أن كل شيء
سيتم إرسال رسائل الإشارات المتعلقة بالتسليم بنجاح، بغض النظر عن ذلك
المسافة وحالة القناة ومع ذلك، فإنه سيؤثر أيضًا على كافة البيانات أو عناصر التحكم الأخرى
الحزم غير المرتبطة بالتسليم، والتي قد تكون أثرًا جانبيًا غير مرغوب فيه. خلاف ذلك، يمكن
يتم على النحو التالي:

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

باستخدام الكود أعلاه، نقوم بتعطيل نموذج الخطأ في كل من قنوات التحكم والبيانات
في كلا الاتجاهين (الوصلة الهابطة والصاعدة). وهذا أمر ضروري لأنه يتعلق بالتسليم
يتم إرسال رسائل الإشارة باستخدام هذه القنوات. الاستثناء هو عندما
تستخدم المحاكاة بروتوكول RRC المثالي. في هذه الحالة، يتم إجراء الوصول العشوائي فقط
تركت للنظر فيها. يتكون الإجراء من رسائل التحكم، لذلك نحتاج فقط
لتعطيل نموذج خطأ قناة التحكم.

التسليم خطى
نموذج RRC، على وجه الخصوص LteEnbRrc LteUeRrc الكائنات، وتوفير بعض مفيدة
الآثار التي يمكن توصيلها ببعض الوظائف المخصصة بحيث يتم استدعاؤها عند البدء
ونهاية مرحلة تنفيذ التسليم في كل من جانب UE وeNB. على سبيل المثال، في
برنامج المحاكاة الخاص بك يمكنك إعلانه بالطرق التالية:

باطل
NotifyHandoverStartUe (std::string context،
uint64_t إيمسي،
uint16_t معرف الخلية،
uint16_t رنتي،
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << سياق
<< "UE IMSI" << imsi
<< ": متصل مسبقًا بمعرف الخلية " << cellId
<< "مع RNTI" << rnti
<< "، إجراء التسليم إلى CellId" << targetCellId
<< ستد::endl;
}

باطل
NotifyHandoverEndOkUe (std::string context،
uint64_t إيمسي،
uint16_t معرف الخلية،
uint16_t رنتي)
{
std::cout << Simulator::Now ().GetSeconds () << " " << سياق
<< "UE IMSI" << imsi
<< ": تم التسليم بنجاح إلى CellId " << cellId
<< "مع RNTI" << rnti
<< ستد::endl;
}

باطل
NotifyHandoverStartEnb (std::string context،
uint64_t إيمسي،
uint16_t معرف الخلية،
uint16_t رنتي،
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << سياق
<< "eNB CellId" << cellId
<< ": بدء تسليم UE مع IMSI " << imsi
<< " RNTI " << rnti
<< "إلى CellId" << targetCellId
<< ستد::endl;
}

باطل
NotifyHandoverEndOkEnb (std::string context،
uint64_t إيمسي،
uint16_t معرف الخلية،
uint16_t رنتي)
{
std::cout << Simulator::Now ().GetSeconds () << " " << سياق
<< "eNB CellId" << cellId
<< ": تم تسليم UE مع IMSI " << imsi
<< " RNTI " << rnti
<< ستد::endl;
}

بعد ذلك، يمكنك ربط هذه الطرق بمصادر التتبع المقابلة مثل هذا:

التكوين::الاتصال ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart"،
MakeCallback (&NotifyHandoverStartEnb));
التكوين::الاتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart"،
MakeCallback (&NotifyHandoverStartUe));
التكوين::الاتصال ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkEnb));
التكوين::الاتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkUe));

البرنامج المثالى src/lte/examples/lena-x2-handover.cc يوضح كيفية كل ما سبق
يمكن دمج التعليمات في برنامج المحاكاة. يمكنك تشغيل البرنامج مثل هذا:

./waf --run lena-x2-handover

وسيتم إخراج الرسائل المطبوعة بواسطة خطافات تتبع التسليم المخصصة. مرتب
بالإضافة إلى تصور بعض معلومات التسجيل ذات مغزى، يمكنك تشغيل البرنامج مثل
هذه:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --تشغيل lena-x2-handover

تردد إعادة استخدام خوارزميات
سنصف في هذا القسم كيفية استخدام خوارزميات إعادة استخدام التردد في eNb داخل LTE
المحاكاة. هناك طريقتان ممكنتان للتكوين. النهج الأول هو
"يدويًا"، يتطلب تكوين المزيد من المعلمات، ولكنه يسمح للمستخدم بتكوين FR
الخوارزمية كما يحتاجها. النهج الثاني هو أكثر "تلقائية". هذا مناسب جدا،
لأنه هو نفسه بالنسبة لكل خوارزمية FR، لذلك يمكن للمستخدم تبديل خوارزمية FR بسرعة كبيرة
تغيير النوع الوحيد من خوارزمية FR. عيب واحد هو أن النهج "التلقائي" يستخدم فقط
مجموعة محدودة من التكوينات لكل خوارزمية، ما يجعلها أقل مرونة، ولكنها كذلك
كافية لمعظم الحالات.

سيتم وصف هذين النهجين أكثر في القسم الفرعي التالي.

إذا لم يقم المستخدم بتكوين خوارزمية إعادة استخدام التردد، فستكون الخوارزمية الافتراضية (أي LteFrNoOpAlgorithm)
تم تثبيته في eNb. إنه يعمل كما لو تم تعطيل خوارزمية FR.

الشيء الوحيد الذي يجب ذكره هو أن معظم خوارزميات FR المطبقة تعمل معها
عرض النطاق الترددي للخلية أكبر أو يساوي 15 RBs. سبب هذا القيد هو شرط ذلك
ويجب تخصيص ثلاث مكاتب إقليمية متواصلة على الأقل لتجهيزات المستعمل (UE) للإرسال.

مانيوال ترتيب
يمكن تكوين خوارزمية إعادة استخدام التردد "يدويًا" ضمن برنامج المحاكاة بواسطة
تحديد نوع خوارزمية FR وجميع سماتها. حاليا، هناك سبع خوارزميات FR
نفذ:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

يتم اختيار خوارزمية FR عبر LteHelper الكائن وخاصته SetFfrAlgorithmType
الطريقة كما هو موضح أدناه:

بي تي آر lteHelper = CreateObject ()؛
lteHelper->SetFfrAlgorithmType("ns3::LteFrHardAlgorithm");

توفر كل خوارزمية FR مطبقة عدة سمات قابلة للتكوين. ليس لدى المستخدمين
للاهتمام بتكوين عرض النطاق الترددي UL وDL، لأنه يتم تلقائيًا أثناء ذلك
تكوين الخلية. لتغيير عرض النطاق الترددي لخوارزمية FR، قم بتكوين القيم المطلوبة لـ
LteEnbNetDevice:

uint8_t عرض النطاق الترددي = 100؛
lteHelper->SetEnbDeviceAttribute ("DlBandwidth"، UintegerValue (bandwidth));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth"، UintegerValue (bandwidth));

الآن، سيتم وصف كل تكوين لخوارزميات FR.

الثابت تردد إعادة استخدام خوارزمية
كما هو موضح في قسم خوارزمية sec-fr-hard في وثائق التصميم
ns3::LteFrHardAlgorithm يستخدم نطاقًا فرعيًا واحدًا. لتكوين هذا المستخدم النطاق الفرعي يحتاج إلى تحديد
الإزاحة وعرض النطاق الترددي للوصلة DL وUL في عدد المكاتب الإقليمية.

توفر خوارزمية إعادة استخدام التردد الثابت السمات التالية:

· DlSubBandOffset: إزاحة الوصلة الهابطة في عدد مجموعات كتل الموارد

· DlSubBandwidth: تكوين عرض النطاق الترددي الفرعي للإرسال الهابط في عدد
مجموعات كتلة الموارد

· UlSubBandOffset: إزاحة الوصلة الصاعدة في عدد مجموعات كتل الموارد

· UlSubBandwidth: تكوين عرض النطاق الترددي الفرعي للإرسال في عدد الموارد
حظر المجموعات

يمكن إجراء تكوين مثال لخوارزمية LteFrHardAlgorithm بالطريقة التالية:

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 باستخدام RBs فقط من 8 إلى 16 في DL وUL، بينما الخلية بأكملها
عرض النطاق الترددي هو 25.

صارم تردد إعادة استخدام خوارزمية
تستخدم خوارزمية إعادة استخدام التردد الصارمة نطاقين فرعيين: واحد مشترك لكل خلية والآخر
خاص. هناك أيضًا عتبة RSRQ، وهي ضرورية لتحديد نطاق UE ضمن النطاق الفرعي
ينبغي أن يخدم. علاوة على ذلك، يمكن أن يكون نقل الطاقة في هذه النطاقات الفرعية مختلفًا.

توفر خوارزمية إعادة استخدام التردد الصارمة السمات التالية:

· UlCommonSubBandwidth: تكوين النطاق الفرعي المشترك للوصلة الصاعدة في عدد الموارد
حظر المجموعات

· UlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الصاعدة في عدد مجموعات كتل الموارد

· UlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الصاعدة في عدد الموارد
حظر المجموعات

· DlCommonSubBandwidth: تكوين النطاق الترددي الفرعي المشترك للوصلة الهابطة في عدد
مجموعات كتلة الموارد

· DlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الهابطة في عدد مجموعات كتل الموارد

· DlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الهابطة في عدد الموارد
حظر المجموعات

· RsrqThreshold: إذا كان RSRQ أسوأ من هذا الحد، فيجب تقديم UE فيه
حافة النطاق الفرعي

· CenterPowerOffset: قيمة PdschConfigDedicated::Pa للنطاق الفرعي المركزي، القيمة الافتراضية
ديسيبل 0

· EdgePowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية dB0

· CenterAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المركزية، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· EdgeAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في منطقة الحافة، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

يسمح المثال أدناه لـ eNB باستخدام النطاقات الإقليمية من 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 النطاق الترددي للخلية بالكامل، ولكن هناك اثنان
يتم تقديم النطاقات الفرعية داخل تجهيزات المستعمل بمستويات طاقة مختلفة.

توفر خوارزمية إعادة استخدام التردد الناعم السمات التالية:

· UlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الصاعدة في عدد مجموعات كتل الموارد

· UlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الصاعدة في عدد الموارد
حظر المجموعات

· DlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الهابطة في عدد مجموعات كتل الموارد

· DlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الهابطة في عدد الموارد
حظر المجموعات

· السماحCenterUeUseEdgeSubBand: إذا كان بإمكان تجهيزات المستعمل المركزية الحقيقية استقبال RBGs في النطاق الفرعي الحافة،
وإلا فإن النطاق الفرعي للحافة مسموح به فقط لوحدات تجهيزات الحافة، وتكون القيمة الافتراضية صحيحة

· RsrqThreshold: إذا كان RSRQ أسوأ من هذا الحد، فيجب تقديم UE فيه
حافة النطاق الفرعي

· CenterPowerOffset: قيمة PdschConfigDedicated::Pa للنطاق الفرعي المركزي، القيمة الافتراضية
ديسيبل 0

· EdgePowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية dB0

· CenterAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المركزية، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· EdgeAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في منطقة الحافة، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

يقوم المثال أدناه بتكوين النطاقات الإقليمية من 8 إلى 16 ليتم استخدامها بواسطة وحدات مستعمل حافة الخلية وهذا النطاق الفرعي هو
غير متاح لمستخدمي مركز الخلية. عتبة 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 (false));
lteHelper->SetFfrAlgorithmAttribute("RsrqThreshold", UintegerValue (20));
lteHelper->SetFfrAlgorithmAttribute ("CenterPowerOffset"،
UintegerValue (LteRrcSap::PdschConfigDedicated::dB0));
lteHelper->SetFfrAlgorithmAttribute ("EdgePowerOffset"،
UintegerValue (LteRrcSap::PdschConfigDedicated::dB3));
NetDeviceContainer enbDevs = lteHelper->InstallEnbDevice (enbNodes.Get(0)) ؛

ناعم كسري تردد إعادة استخدام خوارزمية
تستخدم إعادة استخدام التردد الجزئي الناعم (SFFR) ثلاثة نطاقات فرعية: المركز، المتوسط ​​(المشترك) و
حافة. يتعين على المستخدم تكوين اثنين منهم فقط: المشترك والحافة. سيكون النطاق الفرعي المركزي
تتألف من عرض النطاق الترددي المتبقي. يمكن تقديم كل نطاق فرعي بطرق مختلفة
انتقال السلطة. نظرًا لوجود ثلاثة نطاقات فرعية، يجب أن تكون هناك عتبتان لـ RSRQ
تكوين.

توفر خوارزمية إعادة استخدام التردد الجزئي الناعم السمات التالية:

· UlCommonSubBandwidth: تكوين النطاق الفرعي المشترك للوصلة الصاعدة في عدد الموارد
حظر المجموعات

· UlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الصاعدة في عدد مجموعات كتل الموارد

· UlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الصاعدة في عدد الموارد
حظر المجموعات

· DlCommonSubBandwidth: تكوين النطاق الترددي الفرعي المشترك للوصلة الهابطة في عدد
مجموعات كتلة الموارد

· DlEdgeSubBandOffset: إزاحة النطاق الفرعي لحافة الوصلة الهابطة في عدد مجموعات كتل الموارد

· DlEdgeSubBandwidth: تكوين عرض النطاق الترددي الفرعي لحافة الوصلة الهابطة في عدد الموارد
حظر المجموعات

· CenterRsrqThreshold: إذا كان RSRQ أسوأ من هذه العتبة، فيجب تقديم UE
في النطاق الفرعي المتوسط

· EdgeRsrqThreshold: إذا كان RSRQ أسوأ من هذه العتبة، فيجب تقديم UE
في النطاق الفرعي الحافة

· CenterAreaPowerOffset: قيمة PdschConfigDedicated::Pa للنطاق الفرعي المركزي، الافتراضي
القيمة ديسيبل0

· MediumAreaPowerOffset: قيمة PdschConfigDedicated::Pa للنطاق الفرعي المتوسط، الافتراضي
القيمة ديسيبل0

· EdgeAreaPowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية
ديسيبل 0

· CenterAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المركزية، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· MediumAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المتوسطة، المطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· EdgeAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في منطقة الحافة، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

في المثال أدناه، سيتم استخدام النطاقات الإقليمية من 0 إلى 6 كنطاق فرعي مشترك (متوسط)، والمكاتب الإقليمية من 6 إلى
سيتم استخدام 12 كنطاق فرعي حافة وسيتم استخدام RBs من 12 إلى 24 كنطاق فرعي مركزي (هو
يتكون من المكاتب الإقليمية المتبقية). عتبة 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 أنواع من الخلايا ويحصل كل منها على ثلث النطاق الترددي للنظام). ثم جزء من
هذا النطاق الفرعي الذي يستخدمه المرحلة الابتدائية قطعة مع عامل إعادة الاستخدام 3 وكما ثانوي قطعة
مع عامل إعادة الاستخدام 1. يجب على المستخدم تكوين (لـ DL وUL) إزاحة عرض النطاق الفرعي للخلية
في عدد RB، عدد RB الذي سيتم استخدامه المرحلة الابتدائية قطعة وعدد RB الذي
سيتم استخدامها كما ثانوي قطعة. المرحلة الابتدائية قطعة يتم استخدامه من قبل الخلية في الإرادة، ولكن RBs من
ثانوي قطعة يمكن تعيينها إلى UE فقط إذا كانت تعليقات CQI من UE أعلى
القيمة من عتبة CQI التي تم تكوينها. يعتبر UE بمثابة UE حافة عندما يكون RSRQ الخاص به أقل
من RsrqThreshold.

نظرًا لأن كل eNb يحتاج إلى معرفة مكان وجود أنواع الخلايا الأساسية والثانوية في أنواع الخلايا الأخرى، فسوف يفعل ذلك
قم بحسابها على افتراض أن التكوين هو نفسه لكل خلية وعرض النطاق الفرعي فقط
الإزاحات مختلفة. لذلك من المهم تقسيم النطاق الترددي المتاح للنظام بالتساوي
كل خلية وتطبيق نفس التكوين للقطاعات الأساسية والثانوية عليها.

توفر خوارزمية إعادة استخدام التردد الجزئي المحسنة السمات التالية:

· UlSubBandOffset: إزاحة النطاق الفرعي للوصلة الصاعدة لهذه الخلية في عدد كتلة الموارد
المجموعات

· UlReuse3SubBandwidth: إعادة استخدام الوصلة الصاعدة 3 تكوين النطاق الترددي الفرعي في عدد الموارد
حظر المجموعات

· UlReuse1SubBandwidth: إعادة استخدام الوصلة الصاعدة 1 تكوين النطاق الترددي الفرعي في عدد الموارد
حظر المجموعات

· DlSubBandOffset: إزاحة النطاق الفرعي للوصلة الهابطة لهذه الخلية في عدد كتلة الموارد
المجموعات

· DlReuse3SubBandwidth: إعادة استخدام الوصلة الهابطة 3 تكوين النطاق الترددي الفرعي في عدد
مجموعات كتلة الموارد

· DlReuse1SubBandwidth: إعادة استخدام الوصلة الهابطة 1 تكوين النطاق الترددي الفرعي في عدد
مجموعات كتلة الموارد

· RsrqThreshold: إذا كان RSRQ أسوأ من هذا الحد، فيجب تقديم UE فيه
حافة النطاق الفرعي

· CenterAreaPowerOffset: قيمة PdschConfigDedicated::Pa للنطاق الفرعي المركزي، الافتراضي
القيمة ديسيبل0

· EdgeAreaPowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية
ديسيبل 0

· DlCqiThreshold: إذا كان DL-CQI لـ RBG أعلى من هذه العتبة، يتم الإرسال
على RBG هو ممكن

· UlCqiThreshold: إذا كان UL-CQI لـ RBG أعلى من هذه العتبة، فسيتم الإرسال
على RBG هو ممكن

· CenterAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المركزية، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· EdgeAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في منطقة الحافة، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.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 عرض النطاق الترددي للخلية بالكامل و
يمكن أن يكون هناك نطاقان فرعيان: النطاق الفرعي المركزي والنطاق الفرعي للحافة. ضمن هذه النطاقات الفرعية UEs
يمكن تقديمه بمستوى طاقة مختلف. تقوم الخوارزمية باختيار RBs بشكل تكيفي لحافة الخلية
النطاق الفرعي على أساس معلومات التنسيق (أي RNTP) من الخلايا المجاورة والإخطارات
المحطات الأساسية للخلايا المجاورة، والتي اختارتها RBs لاستخدامها في نطاق الحافة الفرعي. لو
لا توجد وحدات مستعمل مصنفة على أنها وحدات مستعمل حافة في الخلية، ولن يستخدم eNB أي نطاقات إقليمية كنطاق فرعي للحافة.

توفر خوارزمية إعادة استخدام التردد الجزئي الموزع السمات التالية:

· CalculationInterval: الفاصل الزمني بين حساب النطاق الفرعي للحافة، افتراضي
القيمة 1 ثانية

· RsrqThreshold: إذا كان RSRQ أسوأ من هذا الحد، فيجب تقديم UE فيه
حافة النطاق الفرعي

· عتبة الاختلاف: إذا كان الفرق بين قوة الإشارة المستلمة
بواسطة UE من خلية الخدمة وقوة الإشارة الواردة من الخلية المجاورة
الخلية أقل من قيمة RsrpDifferenceThreshold، فسيتم زيادة وزن الخلية

· CenterPowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية
ديسيبل 0

· EdgePowerOffset: قيمة PdschConfigDedicated::Pa لنطاق الحافة الفرعي، القيمة الافتراضية dB0

· EdgeRbNum: عدد RB التي يمكن استخدامها في نطاق الحافة الفرعي

· CenterAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في المنطقة المركزية، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.1.1.1-2

· EdgeAreaTpc: قيمة TPC التي سيتم تعيينها في DL-DCI لوحدات المستعمل في منطقة الحافة، مطلقة
يتم استخدام الوضع، ويتم تعيين القيمة الافتراضية 1 إلى -1 وفقًا لجدول TS36.213 5.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)) ؛

الإرسال الطاقة مراقبة
يتم تمكين وظيفة التحكم في طاقة الوصلة الصاعدة بشكل افتراضي. يمكن للمستخدم تعطيله عن طريق الإعداد
السمة المنطقية ns3::LteUePhy::EnableUplinkPowerControl الى الحقيقة.

يمكن للمستخدم التبديل بين آليات التحكم في طاقة الحلقة المفتوحة وآليات التحكم في طاقة الحلقة المغلقة
عن طريق تحديد السمة المنطقية ns3::LteUePowerControl::ClosedLoop. افتراضيا مغلق
تم تمكين التحكم في الطاقة الحلقية مع وضع التراكم.

يعد فقدان المسار مكونًا رئيسيًا للتحكم في طاقة الوصلة الصاعدة. ويتم حسابه كالفرق بين
معلمة RSRP وReferenceSignalPower التي تمت تصفيتها. يتم إرسال ReferenceSignalPower مع SIB2.

السمات المتوفرة في التحكم في طاقة الوصلة الصاعدة:

· حلقة مغلقة: إذا تم تمكين وضع التحكم في طاقة الوصلة الصاعدة للحلقة المغلقة الحقيقية وفتح الحلقة
التحكم في الطاقة، وإلا فإن القيمة الافتراضية خاطئة

· التراكم ممكّن: إذا تم تمكين وضع التراكم الحقيقي والوضع المطلق
وإلا فإن القيمة الافتراضية خاطئة

· ألفا: عامل تعويض خسارة المسار، القيمة الافتراضية هي 1.0

· كمين: الحد الأدنى من UE TxPower، القيمة الافتراضية هي -40 ديسيبل مللي واط

· بكماكس: الحد الأقصى لـ UE TxPower، القيمة الافتراضية هي 23 ديسيبل مللي واط

· PoNominalPusch: يجب تعيين هذه المعلمة بواسطة طبقات أعلى، ولكنها تحتاج حاليًا
ليتم تكوينها بواسطة نظام السمات، القيم المحتملة هي أعداد صحيحة في النطاق (-126 ...
24)، القيمة الافتراضية هي -80

· PoUePusch: يجب تعيين هذه المعلمة بواسطة طبقات أعلى، ولكنها تحتاج حاليًا إلى ذلك
يتم تكوينها بواسطة نظام السمات، والقيم المحتملة هي أعداد صحيحة في النطاق (-8 ... 7)،
القيمة الافتراضية هي 0

· PsrsOffset: يجب تعيين هذه المعلمة بواسطة طبقات أعلى، ولكنها تحتاج حاليًا إلى ذلك
يتم تكوينها بواسطة نظام السمات، والقيم المحتملة هي أعداد صحيحة في النطاق (0 ... 15)،
القيمة الافتراضية هي 7، ما يعطي P_Srs_Offset_Value = 0

تتبعت القيم in الإرسال الطاقة مراقبة:

· تقريرPuschTxPower: UE TxPower الحالي لـ PUSCH

· تقريرPucchTxPower: UE TxPower الحالي لـ PUCCH

· تقريرSrsTxPower: UE TxPower الحالي لـ SRS

يتم عرض مثال التكوين أدناه:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl"، BooleanValue (true));
التكوين::SetDefault ("ns3::LteEnbPhy::TxPower"، DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop"، BooleanValue (true));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled"، BooleanValue (true));

على سبيل المثال، يمكن للمستخدم إلقاء نظرة وتشغيل برنامج lena-uplink-power-control.

أمثلة البرامج
الدليل سرك/لت/أمثلة/ يحتوي على بعض أمثلة برامج المحاكاة التي توضح كيفية القيام بذلك
محاكاة سيناريوهات LTE مختلفة.

الرقم المرجعي سيناريوهات
هناك قدر كبير من سيناريوهات محاكاة LTE المرجعية التي يمكن العثور عليها في
الأدب. ونذكر هنا بعضًا منها:

· سيناريوهات محاكاة النظام المذكورة في القسم أ.2 من [TR36814].

· نموذج الشريط المزدوج [R4-092042]، والذي تم تنفيذه جزئيًا في المثال
برنامج src/lte/examples/lena-dual-stripe.cc. يتميز هذا البرنامج النموذجي بالكثير من
المعلمات القابلة للتكوين والتي يمكن تخصيصها عن طريق تغيير المعلمات العالمية المقابلة
المتغيرات. للحصول على قائمة بجميع هذه المتغيرات العامة، يمكنك تشغيل هذا الأمر:

./waf --تشغيل lena-dual-stripe --command-template="%s --PrintGlobals"

يقدم القسم الفرعي التالي مثالاً على تشغيل حملة محاكاة باستخدام
هذا البرنامج المثال.

التسليم محاكاة حملة
في هذا القسم الفرعي، سنعرض مثالاً لتشغيل حملة محاكاة باستخدام
وحدة LTE من NS-3. الهدف من الحملة هو مقارنة تأثير كل منها
خوارزمية التسليم المضمنة لوحدة LTE.

ستستخدم الحملة لينا ثنائي الشريط برنامج المثال. أولا علينا تعديل
برنامج مثال لإنتاج المخرجات التي نحتاجها. في هذه المناسبة، نريد أن ننتج
عدد عمليات التسليم، ومتوسط ​​إنتاجية المستخدم، ومتوسط ​​SINR.

يمكن الحصول على عدد عمليات التسليم عن طريق حساب عدد مرات التسليم HandoverEndOk
التسليم خطى مطرود من العمل. ثم يمكن الحصول على متوسط ​​إنتاجية المستخدم من خلال تمكين
RLC محاكاة الناتج. وأخيرا، يمكن الحصول على SINR من خلال تمكين محاكاة PHY
انتاج. يوضح نموذج مقتطف التعليمات البرمجية التالي إحدى الطرق الممكنة للحصول على ما ورد أعلاه:

باطل
NotifyHandoverEndOkUe (std::string context، uint64_t imsi،
uint16_t معرف الخلية، uint16_t rnti)
{
std::cout << "تسليم IMSI" << imsi << std::endl;
}

مادبا
main (int argc، char * argv [])
{
/*** القصاصة ***/

التكوين::الاتصال ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk"،
MakeCallback (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces();
lteHelper->EnableRlcTraces();
بي تي آر rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("StartTime"، TimeValue (Seconds (0)));
rlcStats->SetAttribute ("EpochDuration"، TimeValue (Seconds (simTime)))؛

محاكي :: تشغيل () ؛
جهاز محاكاة :: تدمير () ؛
0 العودة؛
}

ثم يتعين علينا تكوين معلمات البرنامج لتناسب احتياجات المحاكاة لدينا. نحن
يبحثون عن الافتراضات التالية في المحاكاة لدينا:

· 7 مواقع لوحدات eNodeBs الكلية ثلاثية القطاعات (أي 21 خلية كبيرة) منتشرة بشكل سداسي
تخطيط مع مسافة 500 متر بين الموقع.

· بالرغم من لينا ثنائي الشريط تم تصميمه في الأصل لطبقة ثنائية (macrocell و
femtocell) ، سنقوم بتبسيط المحاكاة لدينا إلى طبقة واحدة (macrocell)
محاكاة فقط.

· يتم توزيع وحدات المستعمل بشكل عشوائي حول المواقع ويتم ربطها بالشبكة تلقائيًا
باستخدام تحديد خلية وضع الخمول. بعد ذلك، سوف يتجول UE في بيئة المحاكاة
مع سرعة حركة 60 كم في الساعة.

· مدة المحاكاة 50 ثانية، لذا فإن وحدات المستعمل ستكون قد قطعت مسافة كافية لإثارة بعض المحاكاة
عمليات التسليم.

· قوة 46 ديسيبل ماكروسيل Tx وقوة 10 ديسيبل UE Tx.

· سيتم استخدام وضع EPC لأن إجراء تسليم X2 يتطلب تمكينه.

· المخزن المؤقت الكامل لحركة الوصلة الهابطة والصاعدة، وكلاهما في عرض النطاق الترددي 5 ميغاهيرتز، باستخدام بروتوكول TCP
وجدولة عادلة نسبية.

· بروتوكول RRC المثالي.

طاولات ومكاتب لينا ثنائي الشريط المعلمة ترتيب For سلم حملة أدناه يبين كيف نحن
تكوين المعلمات لينا ثنائي الشريط لتحقيق الافتراضات المذكورة أعلاه.

لينا ثنائي الشريط المعلمة ترتيب For سلم حملة
┌─────────────────┬──────┬───────── ────────── ───────┐
│ اسم المعلمة │ القيمة │ الوصف │
├─────────────────┼──────────────── ────────── ───────┤
│simTime │ 50 │ محاكاة 50 ثانية │
│ │ │ المدة │
├─────────────────┼──────────────── ────────── ───────┤
│nBlocks │ 0 │ تعطيل الشقة │
│ │ │ المباني والفيمتوسيل │
├─────────────────┼──────────────── ────────── ───────┤
│nMacroEnbSites │ 7 │ عدد الخلايا الكبيرة │
│ │ │ مواقع (يحتوي كل موقع على 3 │
│ │ │ الخلايا) │
├─────────────────┼──────────────── ────────── ───────┤
│nMacroEnbSitesX │ 2 │ سوف تقوم مواقع الخلايا الكبيرة │
│ │ │ يتمركز في خط 2-3-2 │
│ │ │ التشكيل │
├─────────────────┼──────────────── ────────── ───────┤
│interSiteDistance │ 500 │ مسافة 500 متر بين │
│ │ │ مواقع الخلايا الكبيرة المجاورة │
├─────────────────┼──────────────── ────────── ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 ديسيبل مللي أمبير قوة Tx لكل │
│ │ │ خلية كبيرة │
├─────────────────┼──────────────── ────────── ───────┤
│epc │ 1 │ تمكين وضع EPC │
└─────────────────┴──────┴───────── ────────── ───────┘

│epcDl │ 1 │ تمكين المخزن المؤقت الكامل DL │
│ │ │ حركة المرور │
├─────────────────┼──────────────── ────────── ───────┤
│epcUl │ 1 │ تمكين المخزن المؤقت الكامل UL │
│ │ │ حركة المرور │
├─────────────────┼──────────────── ────────── ───────┤
│useUdp │ 0 │ تعطيل حركة مرور UDP و │
│ │ │ قم بتمكين TCP بدلاً من ذلك │
├─────────────────┼──────────────── ────────── ───────┤
│macroUeDensity │ 0.00002 │ يحدد عدد وحدات المستعمل │
│ │ │ (يُترجم إلى 48 وحدة مستعمل في │)
│ │ │ محاكاة لدينا) │
├─────────────────┼──────────────── ────────── ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ الحد الأدنى لحركة UE │
│ │ │ السرعة م/ث (60 كم/ساعة) │
├─────────────────┼──────────────── ────────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ الحد الأقصى لحركة UE │
│ │ │ السرعة م/ث (60 كم/ساعة) │
├─────────────────┼──────────────── ────────── ───────┤
│macroEnbBandwidth │ 25 │ 5 ميجا هرتز DL و UL │
│ │ │ عرض النطاق الترددي │
├─────────────────┼──────────────── ────────── ───────┤
│ إنشاء Rem │ 1 │ (اختياري) للتخطيط │
│ │ │ بيئة الراديو │
│ │ │ الخريطة │
└─────────────────┴──────┴───────── ────────── ───────┘

بعض الافتراضات المطلوبة غير متوفرة كمعلمات لينا ثنائي الشريط. في
في هذه الحالة، نقوم بتجاوز السمات الافتراضية، كما هو موضح في الجدول تجاوز الافتراضي
سمات For سلم حملة أدناه.

تجاوز الافتراضي سمات For سلم حملة
┌────────────────────────────────── ────────── ────┬───────────────────────────┬── ────────── ──────────────┐
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::HandoverAlgorithm │ ns3::NoOpHandoverAlgorithm‎│ اختيار التسليم │
│ │ ns3::A3RsrpHandoverAlgorithm، │ الخوارزمية │
│ │ ns3::A2A4RsrqHandoverAlgorithm │ │
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::LteHelper::Scheduler │ ns3::PfFfMacScheduler │ العادل النسبي │
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ اسم الملف لـ DL RLC │
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ اسم الملف لـ UL RLC │
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrFilename │ -DlRsrpSinrStats.txt │ اسم الملف لـ DL PHY │
├────────────────────────────────── ────────── ────┼───────────────────────────┼── ────────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrFilename │ -UlSinrStats.txt │ اسم الملف لـ UL PHY │
└────────────────────────────────── ────────── ────┴───────────────────────────┴── ────────── ──────────────┘

NS-3 يوفر العديد من الطرق لتمرير قيم التكوين إلى المحاكاة. في هذا
على سبيل المثال، سوف نستخدم وسيطات سطر الأوامر. يتم ذلك بشكل أساسي عن طريق إلحاق
المعلمات وقيمها WAF اتصل عند بدء كل محاكاة فردية. لذا
هيه WAF ستبدو دعوات استدعاء عمليات المحاكاة الثلاثة لدينا كما يلي:

$ ./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::DlRsrpSinrFilename=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::DlRsrpSinrFilename=a3-rsrp-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a3-rsrp-UlSinrStats.txt
--RngRun=1" > a3-rsrp.txt

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::A2A4RsrqHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=a2-a4-rsrq-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=a2-a4-rsrq-UlRlcStats.txt
--ns3::PhyStatsCalculator::DlRsrpSinrFilename=a2-a4-rsrq-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=a2-a4-rsrq-UlSinrStats.txt
--RngRun=1" > a2-a4-rsrq.txt

بعض الملاحظات على التنفيذ:

· لاحظ أن بعض الوسائط لم يتم تحديدها لأنها بالفعل نفس الوسيطات
قيم افتراضية. نحتفظ أيضًا بخوارزميات التسليم في كل الإعدادات الافتراضية الخاصة بنا.

· لاحظ أسماء ملفات مخرجات المحاكاة، على سبيل المثال، آثار RLC وآثار PHY، لأننا
يجب أن تتأكد من عدم استبدالها بعملية المحاكاة التالية. في هذا
على سبيل المثال، نحدد الأسماء واحدًا تلو الآخر باستخدام وسيطات سطر الأوامر.

· ال --RngRun=1 يتم استخدام الوسيطة في النهاية لتعيين رقم التشغيل الذي يستخدمه الملف
مولد الأرقام العشوائية المستخدم في المحاكاة. نعيد تشغيل نفس عمليات المحاكاة مع
مختلف RngRun القيم، وبالتالي إنشاء العديد من النسخ المتماثلة المستقلة للنفس
المحاكاة. ثم نقوم بمتوسط ​​النتائج التي تم الحصول عليها من هذه التكرارات لتحقيقها
بعض الثقة الإحصائية.

· يمكننا أن نضيف أ --generateRem=1 وسيطة لإنشاء الملفات اللازمة للإنشاء
خريطة البيئة الراديوية (REM) للمحاكاة. والنتيجة هي الشكل REM تم الحصول عليها
تبدأ من a محاكاة in سلم حملة أدناه، والتي يمكن إنتاجها باتباع
الخطوات الموضحة في القسم راديو البيئة برنامج Maps . ويبين هذا الشكل أيضا
موضع 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 هو العمود السادس
DlSinr = تحميل ("no-op-DlRsrpSinrStats.txt") (:,6);
% القضاء على قيم NaN
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (متوسط ​​(DlSinr)) % تحويل إلى ديسيبل

% Sinr هو العمود السادس
UlSinr = تحميل ("no-op-UlSinrStats.txt") (:،5)؛
% القضاء على قيم NaN
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (متوسط ​​(UlSinr)) % تحويل إلى ديسيبل

أما بالنسبة لعدد عمليات التسليم، فيمكننا استخدام برمجة نصية بسيطة لحساب عدد عمليات التسليم
تكرارات السلسلة "Handover" في ملف السجل:

$ grep "التسليم" no-op.txt | مرحاض -ل

طاولات ومكاتب النتائج of سلم حملة يظهر أدناه الإحصائيات الكاملة بعد الانتهاء
مع المعالجة اللاحقة في كل عملية محاكاة فردية. القيم المعروضة هي المتوسط
من النتائج التي تم الحصول عليها من RngRun من 1 و 2 و 3 و 4.

النتائج of سلم حملة
┌──────────────────┬─────────┬───── ────────┬─ ───────────────┐
│ الإحصائيات │ عدم التشغيل │ A2-A4-RSRQ │ أقوى خلية │
├──────────────────┼─────────┼───── ────────┼─ ───────────────┤
│ متوسط ​​نظام DL │ 6 كيلوبت في الثانية │ 615 كيلوبت في الثانية │ 20 كيلوبت في الثانية │
│ الإنتاجية │ │ │ │
├──────────────────┼─────────┼───── ────────┼─ ───────────────┤
│ متوسط ​​نظام UL │ 4 كيلوبت في الثانية │ 095 كيلوبت في الثانية │ 5 كيلوبت في الثانية │
│ الإنتاجية │ │ │ │
├──────────────────┼─────────┼───── ────────┼─ ───────────────┤
│ متوسط ​​DL SINR │ -0.10 ديسيبل │ 5.19 ديسيبل │ 5.24 ديسيبل │
├──────────────────┼─────────┼───── ────────┼─ ───────────────┤
│ متوسط ​​UL SINR │ 9.54 ديسيبل │ 81.57 ديسيبل │ 79.65 ديسيبل │
├──────────────────┼─────────┼───── ────────┼─ ───────────────┤
│ عدد عمليات التسليم │ 0 │ 0.05694 │ 0.04771 │
│ لكل UE في الثانية │ │ │ │
└──────────────────┴─────────┴───── ────────┴─ ───────────────┘

تظهر النتائج أن وجود خوارزمية التسليم في محاكاة التنقل يعمل على تحسين كليهما
إنتاجية المستخدم وSINR بشكل ملحوظ. هناك فرق بسيط بين الاثنين
خوارزميات التسليم في سيناريو الحملة هذا. سيكون من المثير للاهتمام أن نرى بهم
الأداء في سيناريوهات مختلفة، مثل السيناريوهات مع نشر eNodeBs المنزلي.

تردد إعادة استخدام أمثلة
يوجد مثالان يوضحان وظيفة خوارزميات إعادة استخدام التردد.

إعادة استخدام التردد لينا هو مثال بسيط مع 3 eNBs في تخطيط المثلث. هناك 3 خلايا
وحدات UE الحافة، والتي تقع في وسط هذا المثلث و3 وحدات UE مركزية للخلايا (أحدها بالقرب من
كل eNB). يمكن للمستخدم أيضًا تحديد عدد وحدات المستعمل الموجودة بشكل عشوائي. خوارزمية FR هي
مثبتة في eNBs وكل eNB لديه FrCellTypeId مختلف، ما يعني أن كل eNB يستخدم
تكوين FR مختلف. يمكن للمستخدم تشغيل إعادة استخدام التردد لينا مع 6 FR مختلفة
الخوارزميات: NoOp، وHard FR، وStrict FR، وSoft FR، وSoft FFR، وFFR المحسن. لتشغيل السيناريو
مع خوارزمية FFR الموزعة، يجب على المستخدم استخدامها لينا الموزعة FFR. هذين المثالين
متشابهة جدًا، ولكن تم تقسيمها لأن FFR الموزع يتطلب استخدام EPC،
والخوارزميات الأخرى لا تفعل ذلك.

يهرب إعادة استخدام التردد لينا مع خوارزميات إعادة استخدام التردد المختلفة، يحتاج المستخدم إلى ذلك
تحديد خوارزمية FR عن طريق تجاوز السمة الافتراضية ns3::LteHelper::FfrAlgorithm.
أمر مثال للتشغيل إعادة استخدام التردد لينا مع خوارزمية Soft FR معروضة أدناه:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

تمت إضافة وظيفة إنشاء REM وتتبع محلل الطيف في هذه الأمثلة.
يمكن للمستخدم تمكين توليده عن طريق الإعداد إنشاء Rem createSpectrumTrace
الصفات.

أمر لإنشاء REM لـ RB 1 في قناة البيانات من إعادة استخدام التردد لينا السيناريو مع
يتم عرض خوارزمية FR الناعمة أدناه:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

يتم عرض خريطة بيئة الراديو لـ Soft FR في الشكل REM For RB 1 تم الحصول عليها تبدأ من
إعادة استخدام التردد لينا مثال مع ناعم FR خوارزمية تمكين.
[صورة] تم الحصول على REM لـ RB 1 من إعادة استخدام التردد لينا مثال مع خوارزمية Soft FR
ممكّن.UNINDENT

أمر لتوليد تتبع الطيف من إعادة استخدام التردد لينا السيناريو مع FFR الناعمة
يتم عرض الخوارزمية أدناه (يجب تكوين موضع محلل الطيف بالداخل
النصي):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

ويرد في الشكل مثال لتتبع محلل الطيف طيف محلل تتبع تم الحصول عليها
تبدأ من إعادة استخدام التردد لينا مثال مع ناعم FFR خوارزمية تمكين. طيف محلل وكان
تقع حاجة eNB مع FrCellTypeId 2.. كما يمكن أن يرى، نطاقات فرعية مختلفة لقناة البيانات
يتم إرسالها بمستوى طاقة مختلف (وفقًا للتكوين)، بينما يتم إرسال قناة التحكم
تنتقل بقوة موحدة على طول النطاق الترددي للنظام بأكمله.
[صورة] تم الحصول على تتبع محلل الطيف من إعادة استخدام التردد لينا مثال مع FFR الناعمة
تم تمكين الخوارزمية. تم تحديد موقع محلل الطيف وهو بحاجة إلى eNB مع FrCellTypeId 2..UNINDENT

لينا ثنائي الشريط يمكن تشغيله أيضًا باستخدام خوارزميات إعادة استخدام التردد المثبتة في كل وحدات الماكرو
eNB. يحتاج المستخدم إلى تحديد خوارزمية FR عن طريق تجاوز السمة الافتراضية
ns3::LteHelper::FfrAlgorithm. أمر مثال للتشغيل لينا ثنائي الشريط مع الصلب الاب
يتم عرض الخوارزمية أدناه:

$ ./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::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1" > no-op.txt

أمر مثال لإنشاء REM لـ RB 1 في قناة البيانات منها لينا ثنائي الشريط سيناريو
مع خوارزمية 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::DlRsrpSinrFilename=no-op-DlRsrpSinrStats.txt
--ns3::PhyStatsCalculator::UlSinrFilename=no-op-UlSinrStats.txt
--RngRun=1 --generateRem=true --remRbId=1" > no-op.txt

خرائط البيئة الراديوية للمحطات RB 1 و10 و20 تم إنشاؤها من لينا ثنائي الشريط السيناريو مع
يتم عرض خوارزمية إعادة استخدام التردد الثابت في الأشكال أدناه. تم اختيار هؤلاء RB
لأنه يتم استخدام كل واحدة بواسطة نوع مختلف من خلايا FR.
[صورة] تم الحصول على REM لـ RB 1 من لينا ثنائي الشريط المحاكاة باستخدام خوارزمية Hard FR
ممكّن.UNINDENT
[صورة] تم الحصول على REM لـ RB 10 من لينا ثنائي الشريط المحاكاة باستخدام خوارزمية Hard FR
ممكّن.UNINDENT
[صورة] تم الحصول على REM لـ RB 20 من لينا ثنائي الشريط المحاكاة باستخدام خوارزمية Hard FR
ممكّن.UNINDENT

استكشاف الأخطاء: التصحيح نصائح
يقوم العديد من المستخدمين بالنشر على القائمة البريدية لمستخدمي ns-3 ويتساءلون، على سبيل المثال، عن سبب عدم حصولهم على أي منها
حركة المرور في محاكاتها، أو ربما الوصلة الصاعدة فقط ولكن لا توجد حركة الوصلة الهابطة، وما إلى ذلك
في هذه الحالات، يكون هناك خطأ في برنامج محاكاة المستخدم. فيما يلي بعض النصائح لتصحيح أخطاء
البرنامج ومعرفة سبب المشكلة.

يتمثل النهج العام في تمكين تسجيل العناصر ذات الصلة بشكل انتقائي وتدريجي
مكونات وحدة LTE، تتأكد عند كل عملية تنشيط أن الإخراج كما هو متوقع. في
التفاصيل:

· قم أولاً بفحص مستوى التحكم، وخاصة مؤسسة اتصال RRC
الإجراء، من خلال تمكين مكونات السجل LteUeRrc وLteEnbRrc

· ثم تحقق من إرسال الحزم على مستوى البيانات، بدءاً بتمكين السجل
مكونات LteUeNetDevice وEpcSgwPgwApplication، ثم EpcEnbApplication، ثم
التحرك لأسفل مكدس راديو LTE (PDCP، RLC، MAC، وأخيرًا PHY). كل هذا حتى لك
ابحث عن المكان الذي تتوقف فيه معالجة / إعادة توجيه الحزم.

الاختبار توثيق
نظرة عامة
لاختبار وحدة ns-3 LTE والتحقق من صحتها، يتم توفير العديد من مجموعات الاختبار وهي:
متكاملة مع إطار اختبار NS-3. لتشغيلها، تحتاج إلى تكوين
بناء جهاز محاكاة بهذه الطريقة:

$ ./waf تكوين --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-suit-name

لمزيد من التفاصيل حول test.py وإطار اختبار ns-3، يرجى الرجوع إلى ns-3
كتيب.

الوصف of هيه تجربه بالعربي الأجنحة
وحدة اختبارات
سينر حساب in هيه إلى أسفل لينك
جناح الاختبار lte-الوصلة الهابطة-sinr يتحقق من إجراء حساب SINR في الوصلة الهابطة
بشكل صحيح. يتم حساب نسبة SINR في الوصلة الهابطة لكل منطقة RB مخصصة للبيانات
الإرسال عن طريق تقسيم قوة الإشارة المقصودة من eNB المدروس بواسطة
مجموع قدرة الضوضاء بالإضافة إلى جميع عمليات الإرسال على نفس RB القادمة من eNBs الأخرى
(إشارات التداخل):

بشكل عام، يمكن أن تكون الإشارات المختلفة نشطة خلال فترات زمنية مختلفة. نحدد أ
قطعة كالفاصل الزمني بين أي حدثين من النوع إما بداية أو نهاية a
الموجي. بمعنى آخر، تحدد القطعة فترة زمنية يتم خلالها تحديد مجموعة من
لا تتغير الأشكال الموجية النشطة. دعني أكون القطعة العامة، T_i مدتها و
thrm{SINR_i} الخاص بها، SINR، محسوبًا بالمعادلة أعلاه. حساب المتوسط
سينر ريme
تتحقق مجموعة الاختبار من تنفيذ الحساب أعلاه بشكل صحيح في جهاز المحاكاة.
يتم الحصول على متجهات الاختبار دون اتصال بالإنترنت بواسطة برنامج نصي Octave الذي ينفذ ما ورد أعلاه
المعادلة، والتي تعيد إنشاء عدد من الإشارات المرسلة العشوائية والتداخل
الإشارات التي تحاكي السيناريو الذي يحاول فيه UE فك تشفير إشارة من eNB أثناء ذلك
مواجهة التدخل من eNBs الأخرى. ينجح الاختبار إذا كانت القيم المحسوبة متساوية
متجه الاختبار ضمن تسامح قدره 10^{-7}. والمقصود من التسامح لحساب
أخطاء تقريبية نموذجية في حساب النقطة العائمة.

سينر حساب in هيه الإرسال
جناح الاختبار lte-uplink-sinr يتحقق من إجراء حساب SINR في الوصلة الصاعدة
بشكل صحيح. مجموعة الاختبار هذه متطابقة مع lte-الوصلة الهابطة-sinr الموصوفة في السابق
القسم، مع الاختلاف عما تشير إليه الإشارة والتداخل الآن
ويتم الإرسال بواسطة وحدات المستعمل، ويتم الاستقبال بواسطة eNB. هذا جناح الاختبار
يعيد إنشاء عدد من الإشارات المرسلة عشوائيًا وإشارات التداخل لتقليد أ
السيناريو حيث يحاول eNB فك تشفير الإشارة من عدة وحدات UE في وقت واحد (
تلك الموجودة في خلية eNB) أثناء مواجهة التداخل من وحدات UE الأخرى (تلك التي تنتمي إلى
إلى خلايا أخرى).

يتم الحصول على متجهات الاختبار بواسطة برنامج نصي أوكتاف مخصص. ينجح الاختبار إذا
القيم المحسوبة تساوي متجه الاختبار ضمن تفاوت قدره 10^{-7} والذي، كما هو الحال
ويتعامل اختبار SINR للوصلة الهابطة مع مسائل التقريب الحسابي للنقطة العائمة.

E-UTRA مطلق راديو تردد قناة رقم الهاتف (إيرفكن)
جناح الاختبار lte-earfcn يتحقق من تردد الناقل الذي يستخدمه
يتم تنفيذ فئة LteSpectrumValueHelper (التي تنفذ نموذج طيف LTE).
الامتثال لـ [TS36101]، حيث رقم قناة التردد الراديوي المطلق E-UTRA
تم تعريف (EARFCN). يشتمل متجه الاختبار لمجموعة الاختبار هذه على مجموعة من قيم EARFCN
ويتم حساب تردد الموجة الحاملة المقابل يدويًا وفقًا لمواصفات
[TS36101]. ينجح الاختبار إذا كان تردد الموجة الحاملة الذي تم إرجاعه بواسطة LteSpectrumValueHelper هو
نفس القيمة المعروفة لكل عنصر في ناقل الاختبار.

اختبارات
مخصصة حامل إخماد اختبارات
تقوم مجموعة الاختبار "lte-test-deactivate-bearer" بإنشاء حالة اختبار باستخدام EnodeB واحد وثلاثة
الاتحاد الأوروبي. يتكون كل UE من حامل EPS افتراضي واحد وحامل EPS مخصص مع نفس الحامل
المواصفات ولكن مع ARP مختلفة. يكون تدفق حالة الاختبار كما يلي: إرفاق UE -> إنشاء
الافتراضي + الحامل المخصص -> قم بإلغاء تنشيط أحد الحاملين المخصصين

تعمل حالة الاختبار أيضًا على إلغاء تنشيط الحامل المخصص الذي له معرف الحامل 2(LCID=BearerId+2) الخاص
أول UE (UE_ID=1) يمكن للمستخدم جدولة إلغاء تنشيط الحامل بعد تأخير زمني محدد باستخدام
طريقة المحاكاة::Schedule ().

بمجرد انتهاء تنفيذ حالة الاختبار، سيتم إنشاء DlRlcStats.txt وUlRlcStats.txt. مفتاح
الحقول التي يجب التحقق منها في الإحصائيات هي:

|
ابدأ | النهاية | معرف الخلية | آي إم إس آي | رنتي | إل سي آي دي | تك بايتس | آر إكس بايتس |

يتم تنفيذ حالة الاختبار في ثلاث حقب. 1) في العصر الأول (0.04 ثانية - 1.04 ثانية) جميع UE و
يتم إرفاق الحاملين المقابلين
ويتم تنشيط تدفق الحزم عبر الحاملات المخصصة.

2. في العصر الثاني (1.04 ثانية - 2.04 ثانية)، يتم إلغاء تنشيط الحامل، وبالتالي يمكن للمستخدم رؤية
عدد أقل نسبيًا من TxBytes على UE_ID=1 وLCID=4 مقارنة بالحاملات الأخرى.

3. في العصر الثالث (2.04 ثانية - 3.04 ثانية) منذ إلغاء تنشيط حامل UE_ID=1 وLCID=4
اكتمل، فلن يرى المستخدم أي تسجيل يتعلق بـ LCID=4.

تنجح حالة الاختبار في حالة وفقط إذا 1) تمت إزالة IMSI=1 وLCID=4 بالكامل في المرحلة الثالثة 2)
لم يتم رؤية أي حزم في TxBytes وRxBytes المتوافقة مع IMSI=1 وLCID=4 إذا كان أعلاه
لا يتطابق المعيار مع حالة الاختبار التي تعتبر فاشلة

على التكيف تعديل البرمجة اختبارات
جناح الاختبار LTE الارتباط التكيف يوفر اختبارات النظام لإعادة إنشاء السيناريو باستخدام ملف
eNB واحد وUE واحد. يتم إنشاء حالات اختبار مختلفة تتوافق مع حالات مختلفة
قيم SNR التي ينظر إليها الاتحاد الأوروبي. الهدف من الاختبار هو التحقق من أنه في كل حالة اختبار
يتوافق MCS المختار مع بعض القيم المرجعية المعروفة. يتم الحصول على هذه القيم المرجعية
عن طريق إعادة التنفيذ في أوكتاف (انظر src/lte/test/reference/lte_amc.m) النموذج الموصوف في
القسم sec-lte-amc لحساب الكفاءة الطيفية وتحديد
فهرس MCS المقابل عن طريق البحث يدويًا عن الجداول في [R1-081483]. النتيجة
يتم تمثيل ناقل الاختبار في الشكل اختبار ناقلات For على التكيف تعديل البرمجة.

يتم قياس MCS الذي يستخدمه جهاز المحاكاة من خلال الحصول على مخرجات التتبع
تم إنتاجه بواسطة المجدول بعد 4 مللي ثانية (وهذا ضروري لمراعاة التأخير الأولي في
تقارير CQI). يتم أيضًا الحصول على قيمة SINR التي يتم حسابها بواسطة جهاز المحاكاة باستخدام
معالج LteChunk واجهه المستخدم. ينجح الاختبار إذا توفرت الحالتان التاليتان
راضي:

1. تتوافق نسبة الإشارة إلى الضوضاء (SINR) المحسوبة بواسطة جهاز المحاكاة مع نسبة الإشارة إلى الضوضاء (SNR) لمتجه الاختبار داخلها
التسامح المطلق 10 ^ {-7}؛

2. مؤشر MCS الذي يستخدمه جهاز المحاكاة يتوافق تمامًا مع المؤشر الموجود في الاختبار
المتجه.
[صورة] ناقل اختبار التعديل التكيفي والترميز.UNINDENT

بين الخلايا تدخل اختبارات
جناح الاختبار التدخل LTE يوفر اختبارات النظام لإعادة إنشاء الخلايا الداخلية
سيناريو التداخل مع اثنين من وحدات eNB، يحتوي كل منهما على وحدة تجهيز واحدة متصلة به وتستخدمه
التعديل والتشفير التكيفي في كل من الوصلة الهابطة والوصلة الصاعدة. طوبولوجيا
السيناريو موضح في الشكل طبيعة الكابل For هيه بين الخلايا تدخل تجربه بالعربي. د_1
تمثل المعلمة مسافة كل UE إلى eNB المتصل به، في حين أن d_2
تمثل المعلمة مسافة التداخل. نلاحظ أن طوبولوجيا السيناريو هي كذلك
وأن مسافة التداخل هي نفسها بالنسبة للوصلة الصاعدة والوصلة الهابطة؛ لا يزال، الفعلي
وستكون قدرة التداخل المتصورة مختلفة بسبب اختلاف خسارة الانتشار
في نطاقات الوصلة الصاعدة والوصلة الهابطة. يتم الحصول على حالات اختبار مختلفة عن طريق تغيير d_1 و
معلمات d_2.
[صورة] طوبولوجيا لاختبار التداخل بين الخلايا.UNINDENT

يتم الحصول على متجهات الاختبار باستخدام برنامج نصي مخصص للأوكتاف (متوفر في
src/lte/test/reference/lte_link_budget_interference.m)، الذي يقوم بموازنة الارتباط
الحسابات (بما في ذلك التداخل) المقابلة لطوبولوجيا كل حالة اختبار،
ويخرج SINR الناتج والكفاءة الطيفية. ثم يتم استخدام هذا الأخير ل
تحديد (باستخدام نفس الإجراء المعتمد ل على التكيف تعديل البرمجة اختبارات. نحن
لاحظ أن متجه الاختبار يحتوي على قيم منفصلة للوصلة الصاعدة والوصلة الهابطة.

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-القياسات-قطعة-1, lte-ue-القياسات-قطعة-2و
lte-ue-القياسات-التسليم. تركز مجموعات الاختبار هذه بشكل أكبر على مشغل إعداد التقارير
الإجراء، أي صحة تنفيذ التحفيز القائم على الحدث
يتم التحقق من المعايير هنا.

وبشكل أكثر تحديدًا، تتحقق الاختبارات من توقيت و محتوى من كل تقارير القياس
تم الاستلام بواسطة eNodeB. كل حالة اختبار عبارة عن محاكاة LTE مستقلة وستفعل حالة الاختبار ذلك
ينجح إذا تم تقديم تقرير (تقارير) القياس فقط في الوقت المحدد ويظهر الصحيح
مستوى RSRP (لم يتم التحقق من RSRQ في الوقت الحالي).

بطريقة متقطعة ترتيب
ويهدف التكوين المتعدد الأجزاء إلى اختبار تكوين معين لقياسات تجهيزات المستعمل. ال
سيقوم البرنامج النصي للمحاكاة بإعداد تكوين القياسات المقابلة لUE، والتي
ستكون نشطة طوال فترة المحاكاة.

وبما أن القيم المرجعية يتم حسابها مسبقًا يدويًا، فقد تم وضع العديد من الافتراضات
تبسيط المحاكاة. أولاً، تتأثر القناة فقط بنموذج فقدان المسار (في هذا
الحالة، تم استخدام نموذج فريس). ثانيًا، يتم استخدام بروتوكول RRC المثالي والطبقة الثالثة
تم تعطيل التصفية. أخيرًا، يتحرك UE في نمط حركة محدد مسبقًا بين 4
أماكن مميزة، كما هو موضح في الشكل UE حركة تتبع طوال هيه محاكاة in
قطعة ترتيب أقل. ولذلك فإن تقلب RSRP المقاسة يمكن أن يكون
تحديد بسهولة أكبر.
[صورة] تتبع حركة UE طوال عملية المحاكاة بتكوين متعدد التعريف.UNINDENT

الدافع وراء "النقل الفضائي" بين المواقع المحددة مسبقا هو تقديم
تغيير جذري في مستوى RSRP، والذي سيضمن تفعيل الدخول أو الخروج
حالة الحدث الذي تم اختباره. ومن خلال إجراء تغييرات جذرية، يمكن إجراء الاختبار في الداخل
كمية أقصر من الوقت.

الشكل قياس آر إس آر بي تتبع of an مثال الحدث/الفعالية A1 تجربه بالعربي حقيبة in قطعة ترتيب
يوضح أدناه RSRP المقاس بعد تصفية الطبقة 1 بواسطة طبقة PHY أثناء
محاكاة مع تكوين تدريجي. بسبب تعطيل تصفية الطبقة 3، هذه
هي القيم الدقيقة التي يستخدمها مثيل UE RRC لتقييم مشغل التقارير
إجراء. لاحظ أنه يتم تحديث القيم كل 200 مللي ثانية، وهو الإعداد الافتراضي
فترة التصفية لتقرير قياسات طبقة PHY. ويوضح الشكل أيضًا الوقت الذي
شروط الدخول والخروج لمثال للحدث A1 (تصبح خلية العرض
أفضل من العتبة) تحدث أثناء المحاكاة.
[صورة] تم قياس تتبع RSRP لمثال حالة اختبار الحدث A1 بطريقة تدريجية
التكوين.UNINDENT

يتم اختبار كل معيار من معايير الإبلاغ عدة مرات باستخدام عتبة/إزاحة مختلفة
حدود. تأخذ بعض سيناريوهات الاختبار أيضًا التباطؤ ووقت التشغيل في الاعتبار.
الشكل قياس آر إس آر بي تتبع of an مثال الحدث/الفعالية A1 مع التخلفية نزعة المادة الممغنطة إلي البقاء في حالة مغناطيسية تجربه بالعربي حقيبة in قطعة
ترتيب يصور تأثير التباطؤ في مثال آخر لاختبار الحدث A1.
[صورة] تتبع RSRP المُقاس لمثال الحدث A1 مع حالة اختبار التباطؤ في
التكوين الجزئي.UNINDENT

يتم استخدام التكوين المتعدد الأطراف في مجموعتين من اختبارات قياسات تجهيزات المستعمل. اول واحد هو
lte-ue-القياسات-قطعة-1، من الآن فصاعدا اختبار قطعة رقم 1، الذي يحاكي 1 UE و
1 إي نود ب. والآخر هو lte-ue-القياسات-قطعة-2، الذي يحتوي على 1 UE و2 eNodeBs
في المحاكاة.

يهدف الاختبار الجزئي رقم 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 تعتمد على قياسات الخلية المجاورة، لذلك
لقد تم اختبارها بشكل أكثر شمولاً في الاختبار الجزئي رقم 2. المحاكاة تضع العقد على
خط مستقيم وإرشاد الاتحاد الأوروبي إلى "القفز" بنفس الطريقة كما في اختبار القطعة رقم 1.
يتم تعطيل عملية التسليم في المحاكاة، وبالتالي يتم تفعيل دور الخدمة والخلايا المجاورة
لا التبديل أثناء المحاكاة. طاولة UE قياسات تجربه بالعربي سيناريوهات استخدام قطعة
ترتيب #2 يسرد أدناه السيناريوهات التي تم اختبارها في اختبار القطعة رقم 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 أن حالة الدخول/الخروج هي لا
يعد صحيحًا قبل إطلاق الزناد الأول.

التسليم ترتيب
والغرض من تكوين التسليم هو التحقق من قياس تجهيزات المستعمل
يتم تحديث التكوين بشكل صحيح بعد إجراء عملية التسليم الناجحة. لهذا
لهذا الغرض، ستقوم المحاكاة ببناء 2 eNodeBs بقياسات مختلفة لUE
التكوين، وسيقوم UE بإجراء عملية التسليم من خلية إلى أخرى. سوف يكون الاتحاد الأوروبي
تقع على خط مستقيم بين وحدتي eNodeB، وسيتم استدعاء عملية التسليم
يدويا. مدة كل محاكاة هي ثانيتان (باستثناء حالة الاختبار الأخيرة) و
يتم تشغيل عملية التسليم في منتصف عملية المحاكاة تمامًا.

تشير lte-ue-القياسات-التسليم يغطي جناح الاختبار أنواعًا مختلفة من التكوين
اختلافات. الأول هو الفرق في الفاصل الزمني للتقرير، على سبيل المثال، eNodeB الأول هو
تم تكوينها بفاصل زمني للتقرير يبلغ 480 مللي ثانية، بينما تم تكوين eNodeB الثاني بفاصل زمني يبلغ 240 مللي ثانية
الفاصل الزمني للتقرير. ولذلك، عندما يقوم تجهيز المستعمل بالتسليم إلى الخلية الثانية، الخلية الجديدة
يجب أن يصبح الفاصل الزمني للتقرير ساري المفعول. كما هو الحال في التكوين الجزئي، والتوقيت و
سيتم التحقق من محتوى كل تقرير قياس يتلقاه eNodeB.

الأنواع الأخرى من الاختلافات التي تغطيها مجموعة الاختبار هي الاختلافات في الحدث و
الاختلافات في العتبة / الإزاحة. طاولة UE قياسات تجربه بالعربي سيناريوهات استخدام سلم
ترتيب يسرد أدناه السيناريوهات التي تم اختبارها.

UE قياسات تجربه بالعربي سيناريوهات استخدام سلم ترتيب
────────────────────────────────────────────────── ──────────────────────
اختبار # موضوع الاختبار الأولي بعد التسليم
تكوين التكوين
────────────────────────────────────────────────── ──────────────────────
1 الفاصل الزمني للتقرير 480 مللي ثانية 240 مللي ثانية
────────────────────────────────────────────────── ──────────────────────
2 الفاصل الزمني للتقرير 120 مللي ثانية 640 مللي ثانية
────────────────────────────────────────────────── ──────────────────────
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 مللي ثانية 100 مللي ثانية
────────────────────────────────────────────────── ──────────────────────
17 وقت التشغيل 1024 مللي ثانية 640 مللي ثانية
┌───────┬────────────────────────── ─────────┬ ───────────────────┐
│ │ │ │ │
يطابق الملف الثنائي (الإدخال القياسي)

استخدم مكتبة ns-3-model عبر الإنترنت باستخدام خدمات onworks.net