ns-3-model-library - מקוון בענן

תָכְנִית:

שֵׁם

ns-3-model-library - ספריית מודל ns-3

זה ns-3 מספר סימוכין סִפְרִיָה תיעוד. תיעוד ראשי לפרויקט ns-3
זמין בחמש צורות:

· ns-3 חמצן: תיעוד של ממשקי ה-API הציבוריים של הסימולטור

· ספריית הדרכה, מדריך ומודלים (זֶה מסמך) עבור האחרון לשחרר ו
פיתוח עץ

· ns-3 ויקי

מסמך זה כתוב ב ReStructuredText ל ספינקס ומתוחזק ב
doc/מודלים ספריית קוד המקור של ns-3.

ארגון

מדריך זה אוסף תיעוד עבור ns-3 דגמים ותוכנות תומכות המאפשרות
משתמשים כדי לבנות סימולציות רשת. חשוב להבחין ביניהם מודולים
ו מודלים:

· ns-3 התוכנה מאורגנת בנפרד מודולים שכל אחד בנוי כנפרד
ספריית תוכנה. תוכניות ns-3 בודדות יכולות לקשר את המודולים (הספריות) שהם צריכים
לבצע את הסימולציה שלהם.

· ns-3 מודלים הם ייצוגים מופשטים של אובייקטים בעולם האמיתי, פרוטוקולים, מכשירים וכו'.

An ns-3 מודול עשוי להיות מורכב מיותר מדגם אחד (לדוגמה, ה אינטרנט מודול
מכיל מודלים הן עבור TCP והן עבור UDP). באופן כללי, דגמי ns-3 אינם משתרעים על פני מספר רב
עם זאת, מודולי תוכנה.

מדריך זה מספק תיעוד על הדגמים של ns-3. זה משלים שניים אחרים
מקורות תיעוד לגבי דגמים:

· ממשקי API של המודל מתועדים, מנקודת מבט של תכנות, באמצעות חמצן. דוקסגן
עבור דגמי ns-3 זמין on מה היא פּרוֹיֶקט אינטרנט שרת.

· ה ns-3 הליבה מתועדת במדריך למפתחים. ns-3 דגמים עושים שימוש ב
מתקנים של הליבה, כגון תכונות, ערכי ברירת מחדל, מספרים אקראיים, בדיקה
מסגרות וכו'. התייעצו עם ראשי אינטרנט אתר כדי למצוא עותקים של המדריך.

לבסוף, תיעוד נוסף על היבטים שונים של ns-3 עשוי להתקיים על פּרוֹיֶקט
ויקי.

ניתן למצוא מתאר לדוגמה כיצד לכתוב תיעוד ספריית מודל על ידי הפעלת ה
create-module.py תוכנית ומתבונן בתבנית שנוצרה בקובץ
new-module/doc/new-module.rst.

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

שאר המסמך הזה מאורגן בסדר אלפביתי לפי שם המודול.

אם אתה חדש ns-3, אולי תרצה קודם כל לקרוא להלן על מודול הרשת, אשר
מכיל כמה מודלים בסיסיים עבור הסימולטור. דגם החבילה, דגמים עבור
פורמטים שונים של כתובת, ומחלקות בסיס מופשטות עבור אובייקטים כגון צמתים, net
התקנים, ערוצים, שקעים ויישומים נדונים שם.

אנימציה

אנימציה היא כלי חשוב להדמיית רשת. בזמן 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 רושם את עצמו כ- trace hook לאירועי tx ו-rx לפני ה-
סימולציה מתחילה. כאשר חבילה מתוכננת לשידור או קליטה, ה
tx ו-rx trace hooks התואמים ב- AnimationInterface נקראים. כאשר ה-rx מתחבר
נקראים, AnimationInterface יהיה מודע לשתי נקודות הקצה שביניהן חבילה
זרם, ומוסיף מידע זה לקובץ המעקב, בפורמט XML יחד עם
חותמות זמן tx ו-rx מתאימות. פורמט ה-XML יידון בחלק מאוחר יותר.
חשוב לציין כי AnimationInterface מקליט חבילה רק אם ה-rx עוקב
ווים נקראים. לכל אירוע TX יש להתאים אירוע rx.

הורדת NetAnim
אם NetAnim עדיין לא זמין ב- ns-3 חבילה שהורדת, אתה יכול לעשות את
הבא:

אנא ודא שהתקנת Mercurial. הגרסה האחרונה של NetAnim יכולה להיות
הורדה באמצעות mercurial עם הפקודה הבאה:

שיבוט $ hg http://code.nsnam.org/netanim

בִּניָן NetAnim
תנאים מוקדמים
Qt4 (4.7 ומעלה) נדרש לבניית NetAnim. ניתן להשיג זאת באמצעות הדברים הבאים
דרכים:

עבור הפצות Debian/Ubuntu Linux:

$ apt-get התקנת qt4-dev-tools

להפצה מבוססת Red Hat/Fedora:

$ yum להתקין qt4
$ yum התקן את qt4-devel

עבור Mac/OSX, ראה http://qt.nokia.com/downloads/

לִבנוֹת צעדים
כדי לבנות NetAnim השתמש בפקודות הבאות:

$ cd נטנים
$ לעשות נקי
$ qmake NetAnim.pro (למשתמשי MAC: qmake -spec macx-g++ NetAnim.pro)
make $

הערה: qmake יכול להיות "qmake-qt4" במערכות מסוימות

זה אמור ליצור קובץ הפעלה בשם "NetAnim" באותה ספרייה:

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

נוֹהָג
השימוש ב-NetAnim הוא תהליך בן שני שלבים

שלב 1: צור את קובץ ה-XML האנימציה במהלך השימוש בסימולציה
"ns3::AnimationInterface" ב- ns-3 בסיס קוד.

שלב 2: טען את קובץ ה-XML שנוצר בשלב 1 עם האנימטור המבוסס Qt4 לא מקוון
בשם NetAnim.

שלב 1: ליצור XML הנפשה להתחקות פילה
המחלקה "AnimationInterface" תחת "src/netanim" משתמשת בבסיס ns-3 להתחקות אחר מקורות ל
לבנות קובץ ASCII עם חותמת זמן בפורמט XML.

דוגמאות נמצאות תחת src/netanim/examples דוגמה:

$ ./waf -d debug configure --enable-examples
$ ./waf --הפעל "דמבל-animation"

האמור לעיל ייצור קובץ XML dumbbell-animation.xml

חובה
1. ודא שה-wscript של התוכנית שלך כולל את מודול "נטנים". דוגמה לכזה
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, כפול x, כפול y);

AnimationInterface דורש שהמיקום של כל הצמתים יוגדר. ב ns-3 זה נעשה על ידי
הגדרת MobilityModel משויך. "SetConstantPosition" היא דרך מהירה להגדיר את ה-xy
קואורדינטות של צומת שהוא נייח.

// שלב 3
anim.SetStartTime (שניות(150)); ו-anim.SetStopTime (שניות(150));

AnimationInterface יכול ליצור קובצי XML גדולים. ההצהרות לעיל מגבילות את החלון
שביניהם AnimationInterface עושה מעקב. הגבלת החלון משמשת למיקוד בלבד
על חלקים רלוונטיים של הסימולציה ויצירת קבצי XML קטנים לניהול

// שלב 4
AnimationInterface anim ("animation.xml", 50000);

שימוש בבנאי לעיל מבטיח שלכל קובץ מעקב XML של אנימציה יש רק 50000
מנות. לדוגמה, אם AnimationInterface לוכד 150000 מנות, באמצעות האמור לעיל
הקונסטרוקטור מפצל את הלכידה ל-3 קבצים

· animation.xml - מכיל את טווח החבילות 1-50000

· animation.xml-1 - מכיל את טווח החבילות 50001-100000

· animation.xml-2 - מכיל את טווח החבילות 100001-150000

// שלב 5
anim.EnablePacketMetadata (true);

עם ההצהרה לעיל, 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 מגדיר את המונה עם Id == 89, משויך
עם Node 7 עם הערך 3.4. המונה עם מזהה 89 מתקבל באמצעות
AnimationInterface::AddNodeCounter. שימוש לדוגמה עבור זה הוא ב
src/netanim/examples/resources_demo.cc.

שלב 2: טעינה מה היא XML in NetAnim
1. בהנחה ש-NetAnim נבנתה, השתמש בפקודה "./NetAnim" כדי להפעיל את NetAnim. אנא
עיין בסעיף "בניית NetAnim" אם NetAnim אינו זמין.

2. כאשר NetAnim נפתחת, לחץ על כפתור פתיחת קובץ בפינה השמאלית העליונה, בחר
קובץ ה-XML שנוצר במהלך שלב 1.

3. לחץ על כפתור ההפעלה הירוק כדי להתחיל בהנפשה.

הנה סרטון שממחיש זאת http://www.youtube.com/watch?v=tz_hUuNwFDs

Wiki
להנחיות מפורטות על התקנת "NetAnim", שאלות נפוצות וטעינת קובץ ה-XML
(מוזכר קודם לכן) באמצעות NetAnim אנא עיין: http://www.nsnam.org/wiki/NetAnim

אנטנה מודול

עיצוב תיעוד
סקירה כללית
מודול האנטנה מספק:

1. מחלקה בסיס חדשה (AntennaModel) המספקת ממשק למידול של
דפוס קרינה של אנטנה;

2. קבוצה של מחלקות הנגזרות ממחלקת בסיס זו שכל אחת מדגמנת את תבנית הקרינה
סוגים שונים של אנטנות.

דגם אנטנה
דגם האנטנה משתמש במערכת הקואורדינטות שאומצה ב- [Balanis] ומתואר באיור
לתאם מערכת of מה היא דגם אנטנה. מערכת זו מתקבלת על ידי טרסלינג של הקרטזיאני
מערכת הקואורדינטות המשמשת את ns-3 MobilityModel למקור החדש o שהוא ה
מיקום האנטנה, ולאחר מכן שינוי הקואורדינטות של כל נקודה גנרית p של
המרחב מקואורדינטות קרטזיות (x,y,z) לקואורדינטות כדוריות (r, heta,hi).
דגם האנטנה מזניח את הרכיב הרדיאלי r, ומתחשב רק ברכיבי הזווית
(הטה, היי).
תבנית קרינת אנטנה באה לידי ביטוי כפונקציה מתמטית g(heta, hi)
grightarrow thcal{R} שמחזיר את הרווח (ב-dB) עבור כל כיוון אפשרי של
שידור/קליטה. כל הזוויות מתבטאות ברדיאנים.
[תמונה] מערכת קואורדינטות של AntennaModel.UNINDENT

ספק מודלים
בסעיף זה אנו מתארים את דגמי דפוס קרינת האנטנה הכלולים בתוכם
מודול האנטנה.

דגם אנטנה איזוטרופי
דגם דפוס קרינת אנטנה זה מספק רווח אחיד (0 dB) לכל הכיוונים.

CosineAntennaModel
זהו מודל הקוסינוס המתואר ב-[Chunjian]: רווח האנטנה נקבע כ:

איפה היי_{0}
הוא הכיוון האזימוטלי של האנטנה (כלומר, כיוון ההגבר המרבי שלה) וה-
מעריכי

קובע את רוחב האלומה הרצוי של 3dB hi_{3dB}.
שימו לב שדפוס קרינה זה אינו תלוי בזווית הנטייה heta.

הבדל עיקרי בין המודל של [Chunjian] לזה שיושם בכיתה
CosineAntennaModel הוא רק גורם האלמנט (כלומר, מה שתואר על ידי האמור לעיל
נוסחאות) נחשבות. למעשה, [Chunjian] נחשב גם מערך אנטנות נוסף
גורם. הסיבה לכך שהאחרון אינו נכלל היא שאנו מצפים שהמשתמש הממוצע
ירצה לציין רוחב אלומה נתון בדיוק, מבלי להוסיף גורם מערך ב-a
שלב אחרון שבפועל ישנה את רוחב האלומה האפקטיבי של המתקבל
דפוס קרינה.

דגם אנטנה פרבולית
מודל זה מבוסס על קירוב פרבולי של דפוס הקרינה של האונה הראשית. זה
משמש לעתים קרובות בהקשר של מערכת סלולרית למודל של דפוס הקרינה של תא
מגזר, ראה למשל [R4-092042a] ו-[Calcev]. רווח האנטנה ב-dB נקבע
כמו:

איפה היי_{0}
הוא הכיוון האזימוטלי של האנטנה (כלומר, כיוון ההגבר המרבי שלה),
היי_{3dB}
הוא רוחב האלומה של 3 dB, ו-A_{max} הוא ההנחתה המקסימלית ב-dB של האנטנה. הערה
שתבנית קרינה זו אינה תלויה בזווית הנטייה heta.

[בלאניס]
CA Balanis, "תורת האנטנה - ניתוח ועיצוב", Wiley, מהדורה שנייה.

[צ'ונג'יאן]
לי צ'ונג'יאן, "דפוסי אנטנה יעילים למערכות WCDMA תלת מגזרים", מאסטר של
עבודת גמר מדעית, אוניברסיטת צ'אלמרס לטכנולוגיה, גטבורג, שבדיה, 2003

[Calcev]
ג'ורג' קלסב ומאט דילון, "בקרת הטיית אנטנה ברשתות CDMA", ב-Proc. שֶׁל
ועידת האינטרנט האלחוטי הבינלאומית השנייה (WICON), 2

[R4-092042a]
3GPP TSG RAN WG4 (רדיו) פגישה מס' 51, R4-092042, הנחות סימולציה ו
פרמטרים עבור דרישות FDD HeNB RF.

משתמש תיעוד
ניתן להשתמש באנטנה עם מודול עם כל הטכנולוגיות האלחוטיות והשכבה הפיזית
דגמים שתומכים בזה. נכון לעכשיו, זה כולל את דגמי השכבה הפיזית המבוססים על
SpectrumPhy. אנא עיין בתיעוד של כל אחד מהדגמים הללו לפרטים.

בדיקות תיעוד
בסעיף זה אנו מתארים את חבילות הבדיקה הכלולות במודול האנטנה המאמתות
הפונקציונליות הנכונה שלו.

זוויות
חבילת הבדיקות של היחידה זוויות מאמת שמחלקת ה-Angles בנויה כהלכה על ידי
המרה נכונה מקואורדינטות קרטזיות תלת מימדיות לפי השיטות הזמינות
(בנייה מוקטור בודד ומזוג וקטורים). לכל שיטה, כמה
מסופקים מקרי בדיקה המשווים את הערכים (היי,
heta) נקבע על ידי הבנאי לערכי ייחוס ידועים. המבחן עובר אם עבור כל אחד
במקרה הערכים שווים להתייחסות עד לסובלנות של 10^{-10} אשר אחראית
לשגיאות מספריות.

DegreesToRadians
חבילת הבדיקות של היחידה מעלות-רדיאנים מוודא שהשיטות DegreesToRadians ו
RadiansToDegrees לעבוד כראוי על ידי השוואה עם ערכי ייחוס ידועים במספר של
מקרי מבחן. כל מקרה מבחן עובר אם ההשוואה שווה עד לסובלנות של 10^{-10}
מה שמסביר שגיאות מספריות.

דגם אנטנה איזוטרופי
חבילת הבדיקות של היחידה איזוטרופי-אנטנה-מודל בודק כי ה דגם אנטנה איזוטרופי בכיתה
עובד כמו שצריך, כלומר, מחזיר תמיד רווח של 0dB ללא קשר לכיוון.

CosineAntennaModel
חבילת הבדיקות של היחידה דגם קוסינוס-אנטנה בודק כי ה CosineAntennaModel עבודות בכיתה
כראוי. מסופקים מספר מקרי בדיקה הבודקים את ערך ההגברה של האנטנה שחושב
בכיוונים שונים ועבור ערכים שונים של הכיוון, רווח ההתייחסות
ואת רוחב האלומה. רווח הייחוס מחושב ביד. כל מקרה מבחן עובר אם
רווח התייחסות ב-dB שווה לערך המוחזר על ידי CosineAntennaModel בתוך
סובלנות של 0.001, המהווה את הקירוב שנעשה לחישוב ה-
ערכי ייחוס.

דגם אנטנה פרבולית
חבילת הבדיקות של היחידה פרבולי-אנטנה-מודל בודק כי ה דגם אנטנה פרבולית בכיתה
עובד כמו שצריך. מסופקים מספר מקרי בדיקה הבודקים את ערך ההגברה של האנטנה
מחושב בכיוונים שונים ועבור ערכים שונים של הכיוון, ה
הנחתה מקסימלית ורוחב האלומה. רווח הייחוס מחושב ביד. כל מבחן
מקרה עובר אם רווח הייחוס ב-dB שווה לערך המוחזר על ידי
דגם אנטנה פרבולית בתוך סובלנות של 0.001, המהווה את הקירוב
נעשה עבור חישוב ערכי הייחוס.

AD HOC לפי דרישה מרחק וקטור (AODV)

מודל זה מיישם את מפרט הבסיס של וקטור המרחק על פי דרישה Ad-hoc
פרוטוקול (AODV). היישום מבוסס על RFC 3561.

הדגם נכתב על ידי אלנה בוכצקאיה ופבל בויקו מ-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 ולאפשר את תכונות הפרוטוקול הפעלה/השבתה, כגון
שידור הודעות HELLO, שידור מנות נתונים וכן הלאה.

AODV מגלה מסלולים לפי דרישה. לכן, מודל AODV מאחסן את כל החבילות בזמן א
חבילת בקשת מסלול (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, השידור נעשה לעתים קרובות בקצב סיביות נמוך יותר מ-unicasting,
לפיכך, הודעות HELLO יכולות להגיע רחוק יותר מנתוני unicast. 2) שלום הודעות קטנות,
לכן פחות נוטה לשגיאות סיביות מאשר שידורי נתונים, ו-3) שידורי שידור
לא מובטח להיות דו-כיווני, בניגוד לשידורים חד-שידורים. שנית, אנו משתמשים
משוב שכבה 2 כשאפשר. הקישור נחשב כשבור אם שידור המסגרת
גורם לכישלון שידור עבור כל הניסיונות החוזרים. מנגנון זה מיועד לפעיל
קישור ועובד מהר יותר מהשיטה הראשונה.

יישום המשוב של שכבה 2 מסתמך על TxErrHeader מקור עקבות, כרגע
נתמך ב-AdhocWifiMac בלבד.

היקף ו מגבלות
הדגם מיועד ל-IPv4 בלבד. אופטימיזציות הפרוטוקול האופציונליות הבאות אינן
מוטמע:

1. הרחבת חיפוש הטבעת.

2. תיקון קישור מקומי.

3. הרחבות הודעות RREP, RREQ ו-HELLO.

טכניקות אלו דורשות גישה ישירה לכותרת IP, מה שסותר את הטענה מאת
ה-AODV RFC ש-AODV עובד על UDP. מודל זה משתמש ב-UDP לפשטות, ומפריע ל
יכולת ליישם אופטימיזציות מסוימות של פרוטוקולים. הדגם אינו משתמש בשכבה נמוכה
שקעים כי הם אינם ניידים.

שלנו תיק עבודות
אין תוכניות מוכרזות.

הפניות
נוֹהָג
דוגמאות
עוזרים
תכונות
מעקב
רישום
אזהרות
בדיקת מערכות
יחידה בדיקות
בקנה מידה גדול יותר ביצועים בדיקות

יישומים

מציין מיקום פרק

לְגַשֵׁר NETDEVICE

מציין מיקום פרק

ניתן למצוא כמה דוגמאות לשימוש ב-Bridge NetDevice ב דוגמאות/csma/ במדריך.

BRITE שילוב

מודל זה מיישם ממשק ל-BRITE, נציג האינטרנט של אוניברסיטת בוסטון
גנרטור טופולוגיה [1]. BRITE הוא כלי סטנדרטי ליצירת אינטרנט ריאליסטי
טופולוגיות. מודל ns-3, המתואר כאן, מספק שיעור עוזר להקל
יצירת טופולוגיות ספציפיות ל-ns-3 באמצעות קובצי תצורה של BRITE. BRITE בונה את
גרף מקורי המאוחסן כצמתים וקצוות במחלקה ns-3 BriteTopolgyHelper. ב
השילוב של ns-3 של BRITE, המחולל יוצר טופולוגיה ולאחר מכן מספק גישה
לעלות צמתים עבור כל AS שנוצר. משתמשי ns-3 יכולים לצרף טופולוגיות מותאמות אישית
צמתים אלו על ידי יצירתם באופן ידני או באמצעות מחוללי טופולוגיה המסופקים ב
ns-3.

ישנם שלושה סוגים עיקריים של טופולוגיות זמינות ב-BRITE: נתב, AS ו
היררכי שהוא שילוב של AS ונתב. למטרות ns-3
סימולציה, סביר להניח שהשימושיים ביותר יהיו נתב והיררכי. רמת הנתב
טופולוגיות נוצרות באמצעות מודל וקסמן או מודל Barabasi-Albert. כל אחד
למודל יש פרמטרים שונים המשפיעים על יצירת טופולוגיה. עבור טופולוגיות ראוטר שטוחות,
כל הצמתים נחשבים באותו AS.

טופולוגיות היררכיות של BRITE מכילות שתי רמות. הראשון הוא רמת AS. הרמה הזו
ניתן ליצור גם באמצעות מודל וקסמן או מודל Barabasi-Albert.
לאחר מכן עבור כל צומת בטופולוגיית AS, נבנית טופולוגיה ברמת הנתב. אלה
טופולוגיות ברמת הנתב יכולות שוב להשתמש במודל Waxman או במודל של Barbasi-Albert.
BRITE מחבר בין טופולוגיות הנתב הנפרדות הללו כפי שצוין על ידי רמת AS
טופולוגיה. ברגע שהטופולוגיה ההיררכית נבנית, היא משטחת לגדול
טופולוגיה ברמת הנתב.

מידע נוסף ניתן למצוא במדריך למשתמש של BRITE:
http://www.cs.bu.edu/brite/publications/usermanual.pdf

מספר סימוכין תיאור
המודל מסתמך על בניית ספריית BRITE חיצונית, ולאחר מכן בניית כמה ns-3
עוזרים שקוראים לספרייה. קוד המקור עבור עוזרי ns-3 חי ב-
בספרייה src/brite/helper.

עיצוב
כדי ליצור את הטופולוגיה של BRITE, עוזרי ns-3 קוראים לספריית BRITE החיצונית, ו
באמצעות קובץ תצורה סטנדרטי של BRITE, קוד BRITE בונה גרף עם צמתים ו
קצוות לפי קובץ תצורה זה. אנא עיין במסמך BRITE או את
קובצי תצורה לדוגמה ב-src/brite/examples/conf_files כדי לקבל הבנה טובה יותר של
אפשרויות תצורה של BRITE. הגרף שנבנה על ידי BRITE מוחזר ל-ns-3, ול-ns-3
נבנה יישום הגרף. צמתי עלים עבור כל AS זמינים עבור המשתמש
לצרף טופולוגיות מותאמות אישית או להתקין יישומי ns-3 ישירות.

הפניות
[1] אלברטו מדינה, אנוקול לקינה, איברהים מאטה וג'ון ביירס. בריט: גישה ל
דור טופולוגיה אוניברסלי. בהליכי הסדנה הבינלאומית על
מידול, ניתוח וסימולציה של מערכות מחשב וטלקומוניקציה- MASCOTS
'01, סינסינטי, אוהיו, אוגוסט 2001.

נוֹהָג
ניתן להפנות לדוגמא הגנרית-brite כדי לראות את השימוש הבסיסי בממשק BRITE. ב
לסיכום, ה-BriteTopologyHelper משמש כנקודת הממשק על ידי מעבר ב-BRITE
קובץ תצורה. יחד עם קובץ התצורה קובץ זרעים אקראי בפורמט BRITE
ניתן גם להעביר פנימה. אם לא מועבר קובץ סיד, העוזר יצור סיד
קובץ באמצעות UniformRandomVariable של ns-3. לאחר שהטופולוגיה נוצרה על ידי BRITE,
BuildBriteTopology() נקרא כדי ליצור את הייצוג ns-3. כתובת ה-IP הבאה יכולה להיות
מוקצה לטופולוגיה באמצעות AssignIpv4Addresses() או AssignIpv6Addresses(). זה
יש לציין שכל קישור מנקודה לנקודה בטופולוגיה יטופל כאל חדש
לכן, עבור IPV4 יש להשתמש ברשת משנה /30 כדי למנוע בזבוז של כמות גדולה של
מרחב הכתובות הפנוי.

קובצי תצורה לדוגמה של BRITE ניתן למצוא ב- /src/brite/examples/conf_files/.
ASBarbasi ו-ASWaxman הן דוגמאות לטופולוגיות AS בלבד. ה-RTBarabasi ו-RTWaxman
קבצים הם דוגמאות לטופולוגיות של נתב בלבד. לבסוף ה-TD_ASBarabasi_RTWaxman
קובץ התצורה הוא דוגמה לטופולוגיה היררכית המשתמשת ב-Barabasi-Albert
מודל לרמת AS ומודל Waxman עבור כל אחת מהטופולוגיות ברמת הנתב.
מידע על הפרמטרים של BRITE המשמשים בקבצים אלה ניתן למצוא במשתמש BRITE
מדריך ל.

בִּניָן BRITE אינטגרציה
הצעד הראשון הוא להוריד ולבנות את מאגר BRITE הספציפי ל-ns-3:

שיבוט $ hg http://code.nsnam.org/BRITE
$ CD BRITE
make $

זה יבנה את BRITE ותיצור ספרייה, libbrite.so, בתוך ספריית BRITE.

לאחר בניית BRITE בהצלחה, אנו ממשיכים להגדיר את ns-3 עם תמיכת BRITE.
שנה לספריית ns-3 שלך:

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

ודא שכתוב 'מופעל' לצד 'שילוב BRITE'. אם לא, אז משהו כן
השתבש. או ששכחת לבנות BRITE תחילה בעקבות השלבים שלמעלה, או
ns-3 לא הצליח למצוא את ספריית BRITE שלך.

לאחר מכן, בנה ns-3:

$ ./waf

דוגמאות
לדוגמא המדגימה את ריצת האינטגרציה של BRITE:

$ ./waf --הרץ 'brite-generic-example'

על ידי הפעלת הפרמטר המילולי, הדוגמה תדפיס את הצומת והקצה
מידע בפורמט דומה לפלט BRITE סטנדרטי. יש הרבה אחרים
פרמטרים של שורת הפקודה כולל confFile, מעקב ו-nix, המתוארים להלן:

confFile
קובץ תצורה של BRITE. דוגמאות רבות לקובצי תצורה של BRITE
קיים בספריית src/brite/examples/conf_files, למשל,
RTBarabasi20.conf ו-RTWaxman.conf. אנא עיין בספריית conf_files
לקבלת דוגמאות נוספות.

התחקות
מאפשר מעקב אחר ascii.

ניקס מאפשר ניתוב nix-vector. ניתוב גלובלי משמש כברירת מחדל.

הדוגמה הגנרית של BRITE תומכת גם בהדמיה באמצעות pyviz, בהנחה של כריכות פיתון
ב-ns-3 מופעלים:

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

ניתן להשתמש בסימולציות הכוללות BRITE גם עם MPI. המספר הכולל של מופעי MPI
מועבר לעזר הטופולוגיה של BRITE שבו נעשה שימוש בחלוקה מודולית להקצאת הצמתים
עבור כל AS למופע MPI. ניתן למצוא דוגמה ב-src/brite/examples:

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

אנא עיין בתיעוד ns-3 MPI למידע על הגדרת MPI עם ns-3.

בניינים מודול

cd .. include:: replace.txt

עיצוב תיעוד
סקירה כללית
מודול הבניינים מספק:

1. כיתה חדשה (בִּניָן) המדגים נוכחות של בניין בסימולציה
תַרחִישׁ;

2. כיתה חדשה (MobilityBuildingInfo) המאפשר לציין את המיקום, הגודל ו
מאפיינים של מבנים המצויים בשטח המדומה, ומאפשר את ההצבה
של צמתים בתוך אותם מבנים;

3. מחלקת מיכל עם ההגדרה של המודלים השימושיים ביותר של pathloss וה-
משתנים מתאימים נקראים מבנים התפשטות מודל הפסד.

4. מודל ריבוי חדש (מבנים היברידיים מודל אובדן התפשטות) עבודה עם
מודל ניידות שזה עתה הוצג, המאפשר לדגמן את התופעה של
ריבוי פנימי/חיצוני בנוכחות מבנים.

5. מודל פשוט שעובד רק עם Okumura Hata (OhBuildingsPropagationLossModel)
בהתחשב בתופעה של ריבוי פנימי/חיצוני בנוכחות
בניינים.

הדגמים עוצבו מתוך מחשבה על LTE, אם כי היישום שלהם הוא למעשה
בלתי תלוי בכל קוד ספציפי ל-LTE, וניתן להשתמש בו עם ns-3 אלחוטיים אחרים
גם טכנולוגיות (למשל, wifi, wimax).

השמיים מבנים היברידיים מודל אובדן התפשטות מודל pathloss הכלול מתקבל דרך א
שילוב של מספר מודלים ידועים של אובדן פתיל על מנת לחקות שונה
תרחישים סביבתיים כגון אזורים עירוניים, פרבריים ושטחים פתוחים. יתר על כן, הדגם
סבור שיש לכלול תקשורת חיצונית ופנימית פנימית וחיצונית
מכיוון ש-HeNB עשוי להיות מותקן בתוך הבניין וגם מחוצה לו. במקרה של מקורה
תקשורת, המודל צריך לשקול גם את סוג הבניין בחוץ <-> פנימי
תקשורת על פי כמה קריטריונים כלליים כגון הפסדי חדירת קיר של
החומרים הנפוצים; יתר על כן, הוא כולל כמה תצורה כללית עבור הפנימי
קירות בתקשורת פנימית.

השמיים OhBuildingsPropagationLossModel מודל pathloss נוצר כדי לפשט את
הקודם מסיר את הספים למעבר מדגם אחד לאחר. על שעשה זאת
נעשה בו שימוש רק במודל התפשטות אחד מזה הזמין (כלומר, האוקומורה
האטה). נוכחות הבניין עדיין נחשבת במודל; לכן כל
השיקולים שלעיל לגבי סוג הבניין עדיין תקפים. אותו הדבר
ניתן לשקול מה נוגע לתרחיש הסביבתי והתדירות מאז
שניהם הם פרמטרים של המודל הנחשב.

השמיים בִּניָן בכיתה
המודל כולל מחלקה ספציפית הנקראת בִּניָן המכיל ns3 אריזה מקורית כיתה עבור
הגדרת מימד הבניין. על מנת ליישם את המאפיינים של
מודלים של pathloss כלולים, ה בִּניָן class תומך בתכונות הבאות:

· סוג בנייה:

· מגורים (ערך ברירת מחדל)

· משרד

· מסחרי

· סוג קירות חיצוניים

· עץ

· ConcreteWithWindows (ערך ברירת מחדל)

· בטון ללא חלונות

· אבן בלוקים

· מספר הקומות (ערך ברירת מחדל 1, כלומר רק בקומת הקרקע)

· מספר חדרים בציר x (ערך ברירת מחדל 1)

· מספר חדרים בציר y (ערך ברירת מחדל 1)

מחלקת הבניין מבוססת על ההנחות הבאות:

· בניין מיוצג כמקבילית מלבני (כלומר, קופסה)

· הקירות מקבילים לציר x, y ו-z

· בניין מחולק לרשת של חדרים, המזוהה לפי הפרמטרים הבאים:

· מספר קומות

· מספר חדרים לאורך ציר ה-x

· מספר חדרים לאורך ציר ה-y

· ציר z הוא הציר האנכי, כלומר, מספרי קומות גדלים להגדלת ציר z
ערכים

· מדדי החדרים x ו-y מתחילים מ-1 ועוברים לאורך ציר x ו-y
בהתאמה

· כל החדרים בבניין בגודל שווה

השמיים MobilityBuildingInfo בכיתה
השמיים MobilityBuildingInfo class, שיורשת מהמחלקה ns3 חפץ, אחראי על
שמירה על מידע על מיקומו של צומת ביחס לבנייה. ה
מידע המנוהל על ידי MobilityBuildingInfo היא:

· האם הצומת הוא פנימי או חיצוני

· אם בתוך הבית:

· באיזה בניין נמצא הצומת

· באיזה חדר ממוקם הצומת (מדדי חדר x, y וקומה)

הכיתה MobilityBuildingInfo משמש על ידי מבנים התפשטות מודל הפסד כיתה, אשר
יורש מהמחלקה ns3 PropagationLossModel ומנהלת את חישוב אובדן הנתיבים של
הרכיבים הבודדים והרכבם לפי מיקומי הצמתים. יתר על כך,
הוא מיישם גם את ההצללה, כלומר האובדן עקב מכשולים בנתיב הראשי
(כלומר, צמחייה, מבנים וכו').

יש לציין כי, MobilityBuildingInfo ניתן להשתמש בכל מודל ריבוי אחר.
עם זאת, בהתבסס על המידע בעת כתיבת שורות אלה, רק אלה המוגדרים ב
מודול הבניין מתוכנן להתחשב באילוצים שהוצגו על ידי
בניינים.
g
ItuR1238PropagationLossModel
מחלקה זו משלימה מודל אובדן התפשטות פנימי תלוי-בניין המבוסס על ITU
P.1238 modg{ הכולל הפסדים עקב סוג הבניין (כלומר, מגורים, משרדים ו
מסחרי)ia הביטוי האנליטי ניתן להלן.
nr
{r
aa
איפה: ry ight. : אובדן חשמל
N = tr}מגורים \ 30 & משרד \ 22 & מסחרי\nd{מערך}
מקדם [dB]
yl ight.
L_f = t }sidential \ 15+4(n-1) & office \ 6+3(n-1) & commercial\nd{array}
{l
n : מספר הקומות בין תחנת בסיס לנייד (n 1)
l2
f : תדר [MHz]
}&
d : מרחק (כאשר d > 1) [מ]
n
מבנים פרופג&ationLossModel
ה- BuildingsPropagationLossModel מספק קבוצה נוספת של תלות בניינים
רכיבי מודל pathloss המשמשים ליישום לוגיקה שונה של pathloss. אלה
אלמנטים של מודל pathloss מתוארים בתתי הסעיפים הבאים.

חיצוני קיר פסד (EWL)
רכיב זה מדגמן את אובדן החדירה דרך קירות עבור פנים וחוץ
תקשורת ולהיפך. הערכים לקוחים מהמודל [cost231].

· עץ ~ 4 dB

· בטון עם חלונות (לא מתכת) ~ 7 dB

· בטון ללא חלונות ~ 15 dB (מתפרש בין 10 ל-20 ב-COST231)

· גושי אבן ~ 12 dB

פנימי קירות פסד (IWL)
רכיב זה מדגמן את אובדן החדירה המתרחש בתקשורת פנימית-פנימית
בתוך אותו בניין. ההפסד הכולל מחושב בהנחה שכל אחד פנימי
לקיר יש אובדן חדירה קבוע L_{siw}, ובקירוב למספר הקירות ש
חודרים עם מרחק מנהטן (במספר חדרים) בין המשדר
והמקלט. בפירוט, תן ל-x_1, y_1, x_2, y_2 לסמן את מספר החדר לאורך ה-x ו-
ציר y בהתאמה עבור משתמש 1 ו-2; ההפסד הכולל L_{IWL} מחושב כ

גוֹבַה לְהַשִׂיג מספר סימוכין (HG)
רכיב זה מדגמן את הרווח בשל העובדה שהמכשיר המשדר נמצא על רצפה
מעל האדמה. בספרות [turkmani] רווח זה הוערך כ-2 dB בערך
לקומה. רווח זה יכול להיות מיושם על כל התקשורת פנים וחוץ
להיפך.

הַצלָלָה מספר סימוכין
ההצללה מעוצבת לפי התפלגות לוג-נורמלית עם תקן משתנה
סטייה כפונקציה של המיקום היחסי (פנימי או חיצוני) של ה-MobilityModel
מקרים מעורבים. ערך אקראי אחד נמשך עבור כל זוג של MobilityModels, ונשאר
קבוע עבור זוג זה במהלך כל הסימולציה. לפיכך, הדגם מתאים ל
צמתים סטטיים בלבד.

המודל מחשיב שהממוצע של אובדן ההצללה ב-dB הוא תמיד 0. עבור
שונות, המודל שוקל שלושה ערכים אפשריים של סטיית תקן, בפירוט:
ightarrow X_thrm{O}
· חיצוני (m_shadowingSigmaOutdoor, ערך ברירת מחדל של 7 dB)
N(_thrm{O}, ma_thrm{O}^2).
ightarrow X_thrm{I}
· מקורה (m_shadowingSigmaIndoor, ערך ברירת מחדל של 10 dB)
N(_thrm{I}, ma_thrm{I}^2).
ightarrow
· חדירת קירות חיצוניים (m_shadowingSigmaExtWalls, ערך ברירת מחדל 5 dB)
X_thrm{W} N(_thrm{W}, ma_thrm{W}^2)

הסימולטור מייצר ערך הצללה לכל קישור פעיל לפי צמתים
מיקום בפעם הראשונה שהקישור משמש לשידור. במקרה של שידורים מ
צמתים חיצוניים לצמתים פנימיים, ולהיפך, סטיית התקן (ma_thrm{IO}) חייבת
להיות מחושב כשורש הריבועי של סכום הערכים הריבועיים של התקן
סטייה במקרה של צמתים חיצוניים וזו עבור חדירת הקירות החיצוניים. זה
בשל העובדה שהרכיבים המייצרים את ההצללה אינם תלויים בכל אחד מהם
אַחֵר; לכן, השונות של התפלגות הנובעת מסכום שניים בלתי תלויים
נורמליים הם סכום השונות.

דרך אבודה לוגיקה
להלן אנו מתארים את הלוגיקה השונה של הפסד הנתיבים המיושמים על ידי
יורשת מ- BuildingsPropagationLossModel.

מבנים היברידיים מודל אובדן התפשטות
השמיים מבנים היברידיים מודל אובדן התפשטות מודל pathloss הכלול מתקבל דרך א
שילוב של מספר מודלים ידועים של אובדן מסלולים על מנת לחקות חוץ ו
תרחישים פנימיים, כמו גם תרחישים מפנים-חוץ וחוץ-פנים. בפירוט,
הכיתה מבנים היברידיים מודל אובדן התפשטות משלב את המודלים הבאים של אובדן נתיב:

· OkumuraHataPropagationLossModel (OH) (בתדרים > 2.3 GHz מוחלף על ידי
Kun2600MhzPropagationLossModel)

· ItuR1411LosPropagationLossModel ו-ItuR1411NlosOverRooftopPropagationLossModel
(I1411)

· ItuR1238PropagationLossModel (I1238)

· רכיבי הפסקת הנתיבים של BuildingsPropagationLossModel (EWL, HG, IWL)

הפסאודו-קוד הבא ממחיש כיצד מתוארים האלמנטים השונים של מודל אובדן הנתיב
לעיל משולבים ב מבנים היברידיים מודל אובדן התפשטות:

if (txNode הוא בחוץ)
אז
if (rxNode הוא בחוץ)
אז
אם (מרחק > 1 ק"מ)
אז
if (rxNode או txNode נמצאים מתחת לגג)
אז
L = I1411
אחר
L = OH
אחר
L = I1411
אחר (rxNode הוא מקורה)
אם (מרחק > 1 ק"מ)
אז
if (rxNode או txNode נמצאים מתחת לגג)
L = I1411 + EWL + HG
אחר
L = OH + EWL + HG
אחר
L = I1411 + EWL + HG
אחר (txNode הוא מקורה)
if (rxNode הוא מקורה)
אז
אם (אותו בניין)
אז
L = I1238 + IWL
אחר
L = I1411 + 2*EWL
אחר (rxNode הוא בחוץ)
אם (מרחק > 1 ק"מ)
אז
if (rxNode או txNode נמצאים מתחת לגג)
אז
L = I1411 + EWL + HG
אחר
L = OH + EWL + HG
אחר
L = I1411 + EWL

נציין כי במקרה של תקשורת בין שני צמתים מתחת לרמת הגג עם
המרחק גדול מ-1 ק"מ, אנחנו עדיין מתייחסים לדגם I1411, מכיוון ש-OH הוא ספציפית
מיועד לתאי מאקרו ולכן לאנטנות מעל רמת הגג.

עבור דגם ITU-R P.1411 אנו רואים גם את גרסאות ה-LOS וגם את גרסאות NLoS. בפרט, אנחנו
מחשיב את התפשטות ה-LoS למרחקים מקוצרים מאשר סף שניתן לכוונן
(m_itu1411NlosThreshold). במקרה של התפשטות NLoS, הדגם מעל הגג הוא
נלקח בחשבון עבור מודלים של מאקרו BS ו-SC. במקרה ב-NLoS מספר
נכללו פרמטרים תלויי תרחיש, כגון רוחב רחוב ממוצע,
כיוון וכו'. הערכים של פרמטרים כאלה צריכים להיות מוגדרים כראוי בהתאם ל
התרחיש מיושם, המודל אינו מחשב את הערכים שלהם באופן מקורי. בכל מקרה
מסופקים ערכים, משתמשים בסטנדרטים, מלבד גובה הנייד וה-BS,
שבמקום זאת, השלמות שלהם נבדקת ישירות בקוד (כלומר, הם חייבים להיות
גדול מאפס). בהמשך אנו נותנים את הביטויים של מרכיבי ה-
מודל.

אנו מציינים גם שהשימוש במודלים שונים של ריבוי (OH, I1411, I1238 עם
וריאציות) ב-HybridBuildingsPropagationLossModel עלולות לגרום לחוסר המשכיות של
אובדן נתיב ביחס למרחק. כוונון נכון של התכונות (במיוחד ה
תכונות סף מרחק) יכולות למנוע אי-רציפות אלו. עם זאת, מאז
ההתנהגות של כל דגם תלויה במספר פרמטרים אחרים (תדירות, גובה צומת וכו'),
אין ערך ברירת מחדל של הספים הללו שיכול למנוע את אי המשכיות בכלל
תצורות אפשריות. לפיכך, כוונון מתאים של פרמטרים אלה נותר ל-
המשתמש.

OhBuildingsPropagationLossModel
השמיים OhBuildingsPropagationLossModel המחלקה נוצרה כאמצעי פשוט לפתור את
בעיות אי המשכיות של מבנים היברידיים מודל אובדן התפשטות בלי לעשות
כוונון פרמטר ספציפי לתרחיש. הפתרון הוא להשתמש בהפסד ריבוי אחד בלבד
מודל (כלומר, Okumura Hata), תוך שמירה על המבנה של ההיגיון של הפסקת נתיב עבור ה-
חישוב של מרכיבי אובדן נתיב אחרים (כגון הפסדי חדירת קיר). התוצאה היא
דגם נקי מחוסר המשכיות (חוץ מאלה הנובעות מקירות), אבל זה פחות
מציאותי בסך הכל לתרחיש גנרי עם מבנים ומשתמשים חיצוניים/פנימיים, למשל,
כי Okumura Hata אינו מתאים לא לתקשורת פנימית ולא לחוץ
תקשורת מתחת לגובה הגג.

בפירוט, הכיתה OhBuildingsPropagationLossModel משלב את אובדן הנתיב הבא
הדגמה

· OkumuraHataPropagationLossModel (OH)

· רכיבי הפסקת הנתיבים של BuildingsPropagationLossModel (EWL, HG, IWL)

הפסאודו-קוד הבא ממחיש כיצד מתוארים האלמנטים השונים של מודל אובדן הנתיב
לעיל משולבים ב OhBuildingsPropagationLossModel:

if (txNode הוא בחוץ)
אז
if (rxNode הוא בחוץ)
אז
L = OH
אחר (rxNode הוא מקורה)
L = OH + EWL
אחר (txNode הוא מקורה)
if (rxNode הוא מקורה)
אז
אם (אותו בניין)
אז
L = OH + IWL
אחר
L = OH + 2*EWL
אחר (rxNode הוא בחוץ)
L = OH + EWL

אנו מציינים כי OhBuildingsPropagationLossModel הוא פישוט משמעותי עם כבוד
ל-HybridBuildingsPropagationLossModel, בשל העובדה ש-OH משמש תמיד. בעוד זה
נותן מודל פחות מדויק בתרחישים מסוימים (במיוחד מתחת לגג ובפנים), זה
נמנע למעשה מהנושא של אי רציפות אובדן נתיב שמשפיע
מבנים היברידיים מודל אובדן התפשטות.

משתמש תיעוד
איך ל להשתמש בניינים in a הדמיה
בחלק זה נסביר את השימוש הבסיסי במודל הבניינים בתוך סימולציה
תכנית.

לכלול מה היא כותרות
הוסף את זה בתחילת תוכנית הסימולציה שלך:

#לִכלוֹל

צור a הבניין
כדוגמה, בואו ניצור בניין מגורים בגודל 10 x 20 x 10:

כפול x_min = 0.0;
כפול x_max = 10.0;
כפול y_min = 0.0;
כפול y_max = 20.0;
כפול z_min = 0.0;
כפול z_max = 10.0;
Ptr b = CreateObject ();
b->SetBoundaries (תיבה (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRroomsX (3);
b->SetNRroomsY (2);

לבניין זה שלוש קומות ורשת פנימית של 3 על 2 חדרים בגודל שווה.

כיתת העזר GridBuildingAllocator זמינה גם ליצירת קבוצה בקלות
מבנים בעלי מאפיינים זהים המוצבים על רשת מלבנית. הנה דוגמה
כיצד להשתמש בו:

Ptr gridBuildingAllocator;
gridBuildingAllocator = CreateObject ();
gridBuildingAllocator->SetAttribute ("GridWidth", UintegerValue (3));
gridBuildingAllocator->SetAttribute ("LengthX", DoubleValue (7));
gridBuildingAllocator->SetAttribute ("LengthY", DoubleValue (13));
gridBuildingAllocator->SetAttribute ("DeltaX", DoubleValue (3));
gridBuildingAllocator->SetAttribute ("DeltaY", DoubleValue (3));
gridBuildingAllocator->SetAttribute ("גובה", DoubleValue (6));
gridBuildingAllocator->SetBuildingAttribute ("NRroomsX", UintegerValue (2));
gridBuildingAllocator->SetBuildingAttribute ("NRroomsY", UintegerValue (4));
gridBuildingAllocator->SetBuildingAttribute ("NFloors", UintegerValue (2));
gridBuildingAllocator->SetAttribute ("MinX", DoubleValue (0));
gridBuildingAllocator->SetAttribute ("MinY", DoubleValue (0));
gridBuildingAllocator->צור (6);

זה ייצור רשת 3x2 של 6 בניינים, כל אחד בגודל 7x13x6 מ' עם 2x4 חדרים בפנים
2 קומות; הבניינים מרווחים ב-3 מ' הן על ציר x והן על ציר y.

התקנה צמתים ו ניידות מודלים
צמתים ודגמי ניידות מוגדרים כרגיל, אולם על מנת להשתמש בהם עם
דגם בניינים שאתה צריך שיחה נוספת אליו BuildingsHelper::Install(), כדי לאפשר
מודל הניידות כולל את המידע על מיקומם ביחס למבנים. הנה
דוגמה:

MobilityHelper ניידות;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);

יש לציין שניתן להשתמש בכל דגם ניידות. עם זאת, מומלץ למשתמש לעשות זאת
ודא שההתנהגות של מודל הניידות בשימוש תואמת את
נוכחות של מבנים. לדוגמה, שימוש בניידות אקראית פשוטה על פני הכלל
אזור סימולציה בנוכחות בניינים עלול לגרום בקלות למעבר של צומת פנימה והחוצה ממנו
מבנים, ללא קשר לנוכחות הקירות.

מקום כמה צמתים
אתה יכול למקם צמתים בסימולציה שלך באמצעות מספר שיטות, המתוארות ב-
הבא.

מוֹרֶשֶׁת מיצוב שיטות
ניתן להשתמש בכל שיטת מיקום מדור קודם של ns-3 כדי למקם צומת בסימולציה. ה
שלב נוסף חשוב הוא למשל, אתה יכול למקם צמתים באופן ידני כך:

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

MobilityHelper ניידות;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);
mm0->SetPosition (וקטור (5.0, 5.0, 1.5));
mm1->SetPosition (וקטור (30.0, 40.0, 1.5));

לחלופין, תוכל להשתמש בכל מחלקה קיימת של PositionAllocator. הקואורדינטות של ה
הצומת יקבע אם הוא ממוקם בחוץ או בפנים, ואם הוא בפנים, באיזה
הבניין והחדר שהוא ממוקם.

ספציפי לבניין מיצוב שיטות
כיתות מקצה התפקידים הבאות זמינות להצבת צומת בתפקידים מיוחדים
לגבי מבנים:

· RandomBuildingPositionAllocator: הקצאת כל עמדה על ידי בחירה אקראית של א
בנייה מרשימת כל הבניינים, ולאחר מכן בחירה אקראית של מיקום בפנים
הבניין.

· RandomRoomPositionAllocator: הקצו כל עמדה על ידי בחירה אקראית של חדר
את רשימת החדרים בכל הבניינים, ולאחר מכן בחירה אקראית במיקום בתוך
חדר.

· SameRoomPositionAllocator: הולך על NodeContainer נתון ברצף, ולכל אחד
צומת להקצות מיקום חדש באופן אקראי באותו חדר של אותו צומת.

· FixedRoomPositionAllocator: צור מיקום אקראי המופץ באופן אחיד ב-
נפח של חדר נבחר בתוך בניין נבחר.

לעשות מה היא ניעות מספר סימוכין עקבי
חָשׁוּב: בכל פעם שאתה משתמש בבניינים, אתה צריך להוציא את הפקודה הבאה אחרי שאנחנו
הציבו את כל הצמתים והבניינים בסימולציה:

BuildingsHelper::MakeMobilityModelConsistent ();

פקודה זו תעבור על הרשימות של כל הצמתים ושל כל הבניינים, תקבע עבור
כל משתמש אם זה פנימי או חיצוני, ואם זה מקורה זה יקבע גם את המבנה בפנים
שבו המשתמש נמצא והקומה והמספר המתאימים בתוך הבניין.

מודע לבנייה דרך אבודה מודל
לאחר שהצבת מבנים וצמתים בסימולציה, תוכל להשתמש ב- Building aware
מודל pathloss בסימולציה בדיוק באותו האופן שבו תשתמש בכל אובדן נתיב רגיל
דֶגֶם. איך לעשות זאת ספציפית למודול האלחוטי שאתה שוקל (lte,
wifi, wimax וכו'), אז אנא עיין בתיעוד של דגם זה עבור ספציפי
הוראות.

ראשי ניתן להגדרה תכונות
השמיים בִּניָן למחלקה יש את הפרמטרים הבאים להגדרה:

· סוג מבנה: מגורים, משרדים ומסחר.

· סוג קירות חיצוניים: עץ, ConcreteWithWindows, ConcreteWithoutWindows ו-stoneBlocks.

· גבולות בניין: א אריזה מקורית כיתה עם גבולות הבניין.

· מספר קומות.

· מספר חדרים בציר x ובציר y (ניתן למקם חדרים רק בצורת רשת).

השמיים BuildingMobilityLossModel פרמטר הניתן להגדרה עם מערכת התכונות ns3 הוא
מיוצג על ידי המחרוזת (מחרוזת גבולות) של אזור הסימולציה על ידי מתן א אריזה מקורית בכיתה
עם גבולות השטח. יתר על כן, באמצעות השיטות שלה הפרמטרים הבאים יכולים להיות
מוגדר:

· מספר הקומה שהצומת ממוקם (ברירת מחדל 0).

· המיקום ברשת החדרים.

השמיים BuildingPropagationLossModel למחלקה יש את הפרמטרים הבאים להגדרה
ניתן להגדרה עם מערכת התכונות:

· תדר: תדר ייחוס (ברירת מחדל 2160 מגה-הרץ), שים לב שעל-ידי הגדרת התדר
אורך הגל נקבע בהתאם באופן אוטומטי ולהיפך).

· למבדה: אורך הגל (0.139 מטר, בהתחשב בתדירות לעיל).

· ShadowSigmaOutdoor: סטיית התקן של הצללה עבור צמתים חיצוניים (ברירת מחדל
7.0).

· ShadowSigmaIndoor: סטיית התקן של הצללה עבור צמתים פנימיים (ברירת מחדל
8.0).

· ShadowSigmaExtWalls: סטיית התקן של הצללה עקב קירות חיצוניים
חדירה לתקשורת חיצונית לפנים (ברירת מחדל 5.0).

· רמת גג: גובה גג הבניין במטרים (ברירת מחדל 20 מטר).

· Los2NlosThr: ערך המרחק של נקודת המעבר בין קו הראייה ל-
מודל התפשטות ללא קו ראייה במטרים (ברירת מחדל 200 מטר).

· ITU1411DistanceThr: ערך המרחק של נקודת המעבר בין טווח קצר
(ITU 1211) תקשורת וטווח ארוך (Okumura Hata) במטרים (ברירת מחדל 200 מטר).

· MinDistance: המרחק המינימלי במטרים בין שני צמתים להערכת ה
pathloss (נחשב זניח לפני סף זה) (ברירת מחדל 0.5 מטר).

· סביבה: תרחיש הסביבה בין Urban, SubUrban ו-OpenAreas (ברירת מחדל
עִירוֹנִי).

· CitySize: מימד העיר בין קטן, בינוני, גדול (ברירת מחדל לארג').

על מנת להשתמש במצב ההיברידי, המחלקה שבה יש להשתמש היא
HybridBuildingMobilityLossModel, המאפשר בחירה במודל ה-pathloss המתאים
על פי ההיגיון של הפסד הנתיבים המוצג בפרק העיצוב. עם זאת, פתרון זה
יש בעיה שנקודות המיתוג של מודל אובדן הנתיבים עשויות להציג אי רציפות עקב
למאפיינים השונים של הדגם. זה מרמז שלפי הספציפי
בתרחיש, הסף המשמש למעבר חייב להיות מכוון כראוי. הפשוט
OhBuildingMobilityLossModel להתגבר על בעיה זו על ידי שימוש רק במודל Okumura Hata ו
הפסדי חדירת הקיר.

בדיקות תיעוד
סקירה כללית
כדי לבדוק ולאמת את מודול ns-3 Building Pathloss, מסופקות כמה חבילות בדיקה אשר
משולבים עם מסגרת הבדיקה ns-3. כדי להפעיל אותם, עליך להגדיר את
בניית הסימולטור בדרך זו:

$ ./waf configure --enable-tests --enable-modules=בניינים
$ ./test.py

האמור לעיל יפעיל לא רק את חבילות הבדיקה השייכות למודול הבניינים, אלא גם
אלה השייכים לכל שאר המודולים של ns-3 שבהם תלוי מודול הבניינים. לִרְאוֹת
מדריך ns-3 למידע כללי על מסגרת הבדיקה.

תוכל לקבל דוח מפורט יותר בפורמט HTML בדרך זו:

$ ./test.py -w results.html

לאחר הפעלת הפקודה לעיל, תוכל להציג את התוצאה המפורטת עבור כל בדיקה על ידי פתיחה
הקובץ results.html עם דפדפן אינטרנט.

אתה יכול להפעיל כל חבילת בדיקה בנפרד באמצעות הפקודה הזו:

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

לפרטים נוספים על test.py ומסגרת הבדיקות של ns-3, אנא עיין ב-ns-3
מדריך ל.

תיאור of מה היא מבחן סוויטות
בניינים עוזר מבחן
חבילת הבדיקות מבנים-עוזר בודק שהשיטה
BuildingsHelper::MakeAllInstancesConsistent () עובד כמו שצריך, כלומר, כי
BuildingsHelper מצליח לאתר אם הצמתים נמצאים בחוץ או בפנים, ואם בפנים
שהם ממוקמים בבניין, בחדר ובקומה הנכונים. כמה מקרי מבחן הם
מסופקים עם מבנים שונים (בעלי גודל, מיקום, חדרים וקומות שונים) ו
מיקומי צומת שונים. הבדיקה עוברת אם כל צומת ממוקם נכון.

BuildingPositionAlocator מבחן
חבילת הבדיקות בניין-עמדה-מקצה מציגים שני מקרי בדיקה שבודקים זאת
בהתאמה RandomRoomPositionAllocator ו- SameRoomPositionAllocator פועלים כראוי. כל אחד
מקרי בדיקה כוללים בניין חדר בודד בגודל 2x3x2 (סה"כ 12 חדרים) בקואורדינטות ידועות
24 ו-48 צמתים בהתאמה. שתי הבדיקות בודקות את מספר הצמתים שהוקצו בכל אחד מהם
החדר הוא הצפוי וכי גם מיקום הצמתים נכון.

בניינים דרך אבודה בדיקות
חבילת הבדיקות בניינים-pathloss-מודל מספק בדיקות יחידות שונות המשוות את
התוצאות הצפויות של מודול אובדן נתיב הבניינים בתרחישים ספציפיים עם קדם
ערכים מחושבים שהתקבלו במצב לא מקוון עם סקריפט אוקטבה
(test/reference/buildings-pathloss.m). המבחנים נחשבים שעברו אם שני הערכים
שווים עד לסובלנות של 0.1, הנחשבת מתאימה לשימוש האופייני של
ערכי pathloss (שהם ב-dB).

להלן פירטנו את התרחישים שנחשבו, עבורם נעשתה בחירתם
מכסה את הסט הרחב של שילובי לוגיקה אפשריים של הפסד נתיב. תוצאות ההיגיון של אובדן הנתיבים
לכן נבדק באופן מרומז.

מִבְחָן #1 אוקומורה חתה
במבחן זה אנו בודקים את דגם Okumura Hata הסטנדרטי; לכן הן eNB והן UE ממוקמות
בחוץ במרחק של 2000 מ'. התדר המשמש הוא הלהקה E-UTRA #5, אשר
תואם ל-869 מגה-הרץ (ראה טבלה 5.5-1 מ-36.101). המבחן כולל גם את האימות
של הרחבות השטחים (כלומר, עירוניים, פרבריים ושטחים פתוחים) ושל גודל העיר
(קטן, בינוני וגדול).

מִבְחָן #2 עלות 231 מספר סימוכין
בדיקה זו נועדה לאמת את מודל COST231. המבחן דומה לאוקמורה
נקודה אחת, אלא שהתדר בשימוש הוא רצועת EUTRA #1 (2140 מגה-הרץ) וכי הבדיקה
ניתן לבצע רק עבור ערים גדולות וקטנות בתרחישים עירוניים בשל המודל
מגבלות.

מִבְחָן #3 2.6 GHz מודל
בדיקה זו מאמתת את דגם 2.6 GHz Kun. הבדיקה דומה ל- Okumura Hata one למעט
שהתדר הוא רצועת EUTRA #7 (2620 מגה-הרץ) וניתן לבצע את הבדיקה רק ב
תרחיש עירוני.

מִבְחָן #4 ITU1411 LoS מודל
בדיקה זו נועדה לאמת את מודל ITU1411 במקרה של קו ראייה בתוך הרחוב
שידורים של קניונים. במקרה זה ה-UE ממוקם במרחק של 100 מטר מה-eNB, שכן
הסף למעבר בין LoS ל-NLoS נותר לברירת מחדל (כלומר, 200 מ').

מִבְחָן #5 ITU1411 NLoS מודל
בדיקה זו נועדה לאמת את מודל ITU1411 במקרה של אי קו ראייה מעל
הילוכים על הגג. במקרה זה ה-UE ממוקם במרחק של 900 מטרים מה-eNB, ב
כדי להיות מעל הסף למעבר בין LoS ל-NLoS נותר לברירת מחדל
(כלומר, 200 מ').

מִבְחָן #6 ITUP1238 מודל
בדיקה זו נועדה לאמת את דגם ה-ITUP1238 במקרה של הילוכים פנימיים. ב
במקרה זה גם ה-UE וגם ה-eNB ממוקמים בבניין מגורים עם קירות עשויים
בטון עם חלונות. Ue ממוקם בקומה השנייה ומרוחק 30 מטרים ממנו
ה-eNB, אשר ממוקם בקומה הראשונה.

מִבְחָן #7 בָּחוּץ -> מקורה עם אוקומורה חתה מודל
בדיקה זו מאמתת את השידורים החיצוניים לפנים למרחקים גדולים. במקרה הזה
ה-UE ממוקם בבניין מגורים עם קיר עשוי בטון עם חלונות ו
מרחקים 2000 מטר מה-eNB החיצוני.

מִבְחָן #8 בָּחוּץ -> מקורה עם ITU1411 מודל
בדיקה זו מאמתת את השידור החיצוני לפנים למרחקים קצרים. במקרה הזה
ה-UE ממוקם בבניין מגורים עם קירות עשויים בטון עם חלונות ו
מרחקים 100 מטר מה-eNB החיצוני.

מִבְחָן #9 מקורה -> בָּחוּץ עם ITU1411 מודל
בדיקה זו מאמתת את השידורים החיצוניים לפנים למרחקים קצרים מאוד. בזה
במקרה שה-eNB ממוקם בקומה השנייה של בניין מגורים עם קירות עשויים
בטון עם חלונות ומרחקים של 100 מטרים מה-UE החיצוני (כלומר, LoS
תִקשׁוֹרֶת). לכן יש לכלול את העלייה בגובה בהערכת אובדן הנתיב.

מִבְחָן #10 מקורה -> בָּחוּץ עם ITU1411 מודל
בדיקה זו מאמתת את השידור החיצוני לפנים למרחקים קצרים. במקרה הזה
ה-eNB ממוקם בקומה השנייה של בניין מגורים עם קירות עשויים
בטון עם חלונות ומרחקים של 500 מטרים מה-UE החיצוני (כלומר, NLoS
תִקשׁוֹרֶת). לכן יש לכלול את העלייה בגובה בהערכת אובדן הנתיב.

בניינים הַצלָלָה מִבְחָן
חבילת הבדיקות מבנים-הצללה-מבחן הוא מבחן יחידה שנועד לאמת את הסטטיסטי
הפצה של מודל ההצללה המיושם על ידי בנייניםPathlossModel. ההצללה
מדגם לפי התפלגות נורמלית עם ממוצע = 0 ותקן משתנה
סטייה ma, לפי מודלים הנפוצים בספרות. שלושה מקרי מבחן הם
מסופק, המכסים את המקרים של תקשורת פנימית, חיצונית ופנימית לחוץ.
כל מקרה בדיקה מייצר 1000 דוגמאות שונות של הצללה עבור זוגות שונים של
מופעי MobilityModel בתרחיש נתון. ערכי הצללה מתקבלים על ידי חיסור
משווי ההפסד הכולל שהוחזר על ידי HybridBuildingsPathlossModel מרכיב אובדן הנתיב
שהוא קבוע ונקבע מראש לכל מקרה מבחן. הבדיקה מאמתת שהדגימה
ממוצע ושונות מדגם של ערכי הצללה נופלים בתוך רווח הסמך של 99%.
של ממוצע המדגם ושונות המדגם. הבדיקה גם מוודאת שערכי הצללה
המוחזר בזמנים עוקבים עבור אותו זוג של מופעי MobilityModel הוא קבוע.

הפניות
[טורקמני]
Turkmani AMD, JD Parson ו-DG Lewis, "הפצת רדיו לתוך בניינים ב
441, 900 ו-1400 מגה-הרץ", בהליך של ועידה בינלאומית 4 על רדיו נייד קרקעי, 1987.

לחץ מודולרי נתב שילוב

קליק היא ארכיטקטורת תוכנה לבניית נתבים הניתנים להגדרה. על ידי שימוש שונה
שילובים של יחידות עיבוד מנות הנקראות אלמנטים, ניתן ליצור נתב קליק
לבצע סוג מסוים של פונקציונליות. גמישות זו מספקת פלטפורמה טובה עבור
בדיקה והתנסות עם פרוטוקולים שונים.

מספר סימוכין תיאור
קוד המקור של מודל הקליק נמצא בספרייה src/לחץ.

עיצוב
העיצוב של ns-3 מתאים היטב לשילוב עם Click בשל הסיבות הבאות:

· מנות ב-ns-3 מועברות בסידרה/הסריאליזציה כשהן נעות למעלה/מטה בערימה. זה מאפשר
חבילות ns-3 שיועברו אל וממנה לחץ כפי שהן.

· זה גם אומר שכל סוג של מחולל תנועה ותחבורה ns-3 צריך לעבוד בקלות
על גבי קליק.

· על ידי שאיפה ליישם קליק כמופע Ipv4RoutingProtocol, נוכל להימנע
שינויים משמעותיים בשכבת LL ו-MAC של קוד ns-3.

מטרת העיצוב הייתה להפוך את ה-API הציבורי של ns-3-click לפשוט מספיק, כך שהמשתמש
צריך רק להוסיף מופע Ipv4ClickRouting לצומת, ולהודיע ​​לכל צומת קליק
של קובץ התצורה של קליק (קובץ .click) שבו הוא אמור להשתמש.

מודל זה מיישם את הממשק לנתב מודולרי קליק ומספק את
מחלקה Ipv4ClickRouting כדי לאפשר לצומת להשתמש ב-Click עבור ניתוב חיצוני. בניגוד לרגיל
סוגי משנה של Ipv4RoutingProtocol, Ipv4ClickRouting לא משתמש בשיטת RouteInput() אבל
במקום זאת, מקבל חבילה בממשק המתאים ומעבד אותה בהתאם. הערה
שאתה צריך שיהיה לך אלמנט מסוג טבלת ניתוב בתרשים הקליקים כדי להשתמש ב-Click for
ניתוב חיצוני. זה נחוץ על ידי הפונקציה RouteOutput() שקיבלה בירושה
Ipv4RoutingProtocol. יתר על כן, צומת מבוסס קליק משתמש בסוג אחר של L3 ב-
צורה של Ipv4L3ClickProtocol, שהיא גרסה מצומצמת של Ipv4L3Protocol.
Ipv4L3ClickProtocol מעביר מנות העוברות דרך הערימה ל-Ipv4ClickRouting עבור
מעבד.

מתפתח a מדמה API ל להתיר ns-3 ל אינטראקציה עם נְקִישָׁה
חלק גדול מה-API כבר מוגדר היטב, מה שמאפשר ל-Click לחפש מידע ממנו
הסימולטור (כמו מזהה של צומת, מזהה ממשק וכן הלאה). על ידי שמירה על רוב ה
שיטות, זה אמור להיות אפשרי לכתוב יישומים חדשים ספציפיים ל-ns-3 עבור אותו
פונקציונליות.

לפיכך, עבור שילוב קליק עם ns-3, מחלקה בשם Ipv4ClickRouting תטפל ב
אינטראקציה עם קליק. ניתן למצוא את הקוד לאותו דבר ב
src/click/model/ipv4-click-routing.{cc,h}.

מנה יד כבוי בֵּין ns-3 ו נְקִישָׁה
ישנם ארבעה סוגים של מסירות מנות שיכולות להתרחש בין ns-3 ל-Click.

· L4 עד L3

· L3 עד L4

· L3 עד L2

· L2 עד L3

כדי להתגבר על זה, אנו מיישמים את Ipv4L3ClickProtocol, גרסה מופשטת של
Ipv4L3 פרוטוקול. Ipv4L3ClickProtocol מעביר מנות אל וממנה Ipv4ClickRouting
כראוי לבצע ניתוב.

היקף ו מגבלות
· במצבו הנוכחי, NS-3 Click Integration מוגבל לשימוש רק עם L3, עוזב
NS-3 לטיפול ב-L2. אנו עובדים כעת על הוספת תמיכת Click MAC גם כן. ראה את
סעיף השימוש כדי לוודא שאתה מעצב את גרפי הקליקים שלך בהתאם.

· יתר על כן, ns-3-click יעבוד רק עם אלמנטים ברמת המשתמש. הרשימה המלאה של
אלמנטים זמינים ב http://read.cs.ucla.edu/click/elements. אלמנטים שיש
ניתן להשתמש ב-'all', 'userlevel' או 'ns' המוזכרים לצדם.

· נכון לעכשיו, ממשק ns-3 ל-Click הוא Ipv4 בלבד. אנו נוסיף תמיכה ב-IPv6
העתיד.

הפניות
· אדי קולר, רוברט מוריס, בנג'י צ'ן, ג'ון ג'נוטי ומ.פרנס קאסשוק. ה
נתב מודולרי לחץ. עסקאות ACM על מערכות מחשוב 18(3), אוגוסט 2000, עמודים
263-297.

· ללית סורש פ., ורובן מרז. Ns-3-click: לחץ על שילוב נתב מודולרי עבור ns-3.
ב-Proc. של סדנת ICST הבינלאומית השלישית בנושא NS-3 (WNS3), ברצלונה, ספרד. מרץ,
2011.

· מיכאל נויפלד, אשיש ג'יין ודירק גרונוולד. Nsclick: הדמיית רשת גישור
ופריסה. MSWiM '02: הליכים של הסדנה הבינלאומית החמישית של ACM בנושא דוגמנות
ניתוח וסימולציה של מערכות אלחוטיות וניידות, 2002, אטלנטה, ג'ורג'יה, ארה"ב.
http://doi.acm.org/10.1145/570758.570772

נוֹהָג
בִּניָן נְקִישָׁה
הצעד הראשון הוא לשכפל קליק ממאגר github ולבנות אותו:

$ git clone https://github.com/kohler/click
$ cd click/
$ ./configure --disable-linuxmodule --enable-nsclick --enable-wifi
make $

ניתן לדלג על הדגל --enable-wifi אם אינך מתכוון להשתמש בלחיצה עם Wifi. *
הערה: אינך צריך לבצע 'בצע התקנה'.

לאחר שהקליק נבנה בהצלחה, עבור לספריית ns-3 והגדר את ns-3
עם תמיכה בשילוב קליקים:

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

רמז: אם לחצתם התקנת ספרייה אחת מעל ns-3 (כגון ב-ns-3-allinone
ספרייה), ושם הספרייה הוא 'קליק' (או קישור סמלי לספרייה
נקרא 'קליק'), אז אין צורך במפרט --with-nsclick; המבנה של ns-3
המערכת תמצא בהצלחה את הספרייה.

אם כתוב 'מופעל' לצד 'תמיכה בשילוב NS-3 Click', אז אתה מוכן ללכת.
הערה: אם פועל ns-3 מודולרי, קבוצת המודולים המינימלית הנדרשת להפעלת כל ns-3-click
דוגמאות הן 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 וכן הלאה (גם אם אתה
באמצעות wifi). שימו לב שמספור המכשיר צריך להתחיל מ-0. בעתיד, זה
יגמיש כך שמשתמשים יוכלו לתת שמות למכשירים בקובץ הקליקים שלהם כרצונם.

· אלמנט טבלת ניתוב הוא חובה. יציאות ה-OUT של רכיב טבלת הניתוב צריכים
תואם למספר הממשק של המכשיר שדרכו החבילה תהיה
בסופו של דבר יישלחו החוצה. הפרת כלל זה תוביל לעקבות מנות מוזרות באמת.
לאחר מכן יש להעביר את שמו של רכיב טבלת ניתוב זה לפרוטוקול Ipv4ClickRouting
אובייקט כפרמטר סימולציה. עיין בדוגמאות קליק לפרטים.

· היישום הנוכחי מותיר את Click עם פונקציונליות L3 בעיקר, עם טיפול ב-ns-3
L2. בקרוב נתחיל לפעול לתמיכה בשימוש בפרוטוקולי MAC גם ב-Click.
המשמעות היא שנכון לעכשיו, לא ניתן להשתמש ברכיבים הספציפיים של ה-Wifi של Click עם ns-3.

Debugging מנה זורם החל מ- נְקִישָׁה
מכל נקודה בתוך גרף קליקים, אתה יכול להשתמש ב-Print (-
http://read.cs.ucla.edu/click/elements/print) אלמנט וגרסאותיו להדפסה יפה
של תכולת החבילה. יתר על כן, אתה עשוי ליצור עקבות pcap של מנות הזורמות דרך a
לחץ על גרף באמצעות ToDump (http://read.cs.ucla.edu/click/elements/todump) אלמנט as
נו. לדוגמה:

myarpquerier
-> הדפס (frommarpquery,64)
-> ToDump(out_arpquery,PER_NODE 1)
-> ethout;

ו...ידפיס את התוכן של חבילות שזורמות מה-ArpQuerier, ואז יפיק א
קובץ מעקב pcap שתהיה לו סיומת 'out_arpquery', עבור כל צומת באמצעות הלחצן
קובץ, לפני דחיפת מנות אל 'ethout'.

עוֹזֵר
כדי להפעיל את הצומת Click, הדרך הקלה ביותר תהיה להשתמש ב-ClickInternetStackHelper
שיעור בסקריפט הסימולציה שלך. לדוגמה:

ClickInternetStackHelper קליק;
click.SetClickFile (myNodeContainer, "nsclick-simple-lan.click");
click.SetRoutingTableElement (myNodeContainer, "u/rt");
click.Install (myNodeContainer);

התסריטים לדוגמה בפנים src/click/examples/ להדגים את השימוש בצמתים מבוססי קליק ב
תרחישים שונים. ניתן למצוא את מקור העוזר בפנים
src/click/helper/click-internet-stack-helper.{h,cc}

דוגמאות
הדוגמאות הבאות נכתבו, אותן ניתן למצוא ב src/click/examples/:

· nsclick-simple-lan.cc ו-nsclick-raw-wlan.cc: צומת מבוסס קליקים המתקשר עם
צומת ns-3 רגיל ללא קליק, באמצעות Csma ו- Wifi בהתאמה. זה גם מדגים
השימוש ב-TCP על גבי קליק, משהו שעבורו המימוש המקורי של nsclick
NS-2 לא הצליח להשיג.

· nsclick-udp-client-server-csma.cc ו-nsclick-udp-client-server-wifi.cc: LAN 3 צמתים
(Csma ו-Wifi בהתאמה) שבהם 2 צמתים מבוססי קליק מריצים לקוח UDP, ששולח
מנות לצומת שלישי מבוסס קליקים המריץ שרת UDP.

· nsclick-routing.cc: צומת מבוסס קליק אחד מתקשר לאחר באמצעות צומת שלישי
פועל כנתב IP (באמצעות נתב ה-IP Click Configuration). זה מדגים
ניתוב באמצעות קליק.

סקריפטים זמינים בתוך /conf/ המאפשרים לך ליצור קבצי קליק עבור
כמה תרחישים נפוצים. נתב ה-IP בשימוש ב nsclick-routing.cc נוצר מה
קובץ make-ip-conf.pl ומותאם מעט לעבודה עם ns-3-click.

בדיקת מערכות
דגם זה נבדק באופן הבא:

· בדיקות יחידה נכתבו כדי לאמת את החלקים הפנימיים של Ipv4ClickRouting. זה יכול להיות
נמצא ב src/click/ipv4-click-routing-test.cc. בדיקות אלו מוודאות אם השיטות
בתוך Ipv4ClickRouting העוסקים בשם מכשיר לזיהוי, כתובת IP מתוך שם המכשיר
ו-Mac Address מהכריכות של שם המכשיר פועלות כצפוי.

· הדוגמאות שימשו לבדיקת קליק עם תרחישי סימולציה בפועל. אלה יכולים להיות
נמצא ב src/click/examples/. בדיקות אלו מכסות את הדברים הבאים: השימוש במגוון
סוגים של העברות על גבי קליק, TCP/UDP, אם צמתי קליק יכולים לתקשר איתם
צמתים שאינם מבוססי קליק, האם צמתים קליק יכולים לתקשר זה עם זה, באמצעות קליק
לנתב מנות באמצעות ניתוב סטטי.

· קליק נבדק עם מכשירי Csma, Wifi ו-Point-to-Point. הוראות שימוש הן
זמין בסעיף הקודם.

CSMA NETDEVICE

זהו המבוא לפרק CSMA NetDevice, כדי להשלים את מודל Csma dooxygen.

סקירה כללית of מה היא CSMA מודל
השמיים ns-3 התקן CSMA מדגמן רשת אוטובוסים פשוטה ברוח ה-Ethernet. למרות שזה
אינו מדגמן שום רשת פיזית אמיתית שאי פעם תוכל לבנות או לקנות, היא כן מספקת
פונקציונליות שימושית מאוד.

בדרך כלל כשחושבים על רשת אוטובוס Ethernet או IEEE 802.3 עולה בראש. אתרנט
משתמש ב-CSMA/CD (Carrier Sense Multiple Access עם זיהוי התנגשות עם אקספוננציאלית
הגדלת הגיבוי כדי להתמודד על אמצעי השידור המשותף. ה ns-3 מכשיר CSMA
מודל רק חלק מתהליך זה, תוך שימוש באופי של הערוץ הזמין בעולם
לספק תחושת נושא מיידי (מהיר מהאור) והתנגשות מבוססת עדיפות
"הימנעות". התנגשויות במובן של Ethernet לעולם לא קורות וכך ns-3 מכשיר CSMA
אינו מדגמן זיהוי התנגשות, וגם כל שידור בעיצומו לא יהיה "תקוע".

CSMA שִׁכבָה מספר סימוכין
ישנן מספר מוסכמות בשימוש לתיאור תקשורת מרובדת
ארכיטקטורות בספרות ובספרי לימוד. מודל השכבות הנפוץ ביותר הוא
מודל ייחוס של שבע שכבות ISO. בתצוגה זו הצמד CsmaNetDevice ו-CsmaChannel
תופסת את שתי השכבות הנמוכות ביותר - בקישור הפיזי (שכבה אחת) ובקישור הנתונים (שכבה שתיים)
עמדות. מודל התייחסות חשוב נוסף הוא זה שצוין על ידי RFC 1122, "דרישות
עבור מארחי אינטרנט -- שכבות תקשורת." בתצוגה זו, ה-CsmaNetDevice ו
צמד CsmaChannel תופס את השכבה הנמוכה ביותר - שכבת הקישור. יש גם לכאורה
אוסף אינסופי של תיאורים חלופיים שנמצאו בספרי הלימוד ובספרות. אָנוּ
לאמץ את מוסכמות השמות המשמשות בתקני IEEE 802 המדברים על LLC, MAC, MII
ושכבות PHY. ראשי תיבות אלו מוגדרים כ:

· LLC: בקרת קישור לוגי;

· MAC: בקרת גישה למדיה;

· MII: ממשק עצמאי של מדיה;

· PHY: שכבה פיזית.

במקרה זה ה LLC ו מק הן שכבות משנה של שכבת קישור הנתונים של OSI ושל MII ו PHY
הן שכבות משנה של השכבה הפיזית של OSI.

ה"חלק העליון" של מכשיר ה-CSMA מגדיר את המעבר משכבת ​​הרשת לנתונים
שכבת קישור. המעבר הזה מבוצע על ידי שכבות גבוהות יותר על ידי קריאה לאחת מהן
CsmaNetDevice::Send או CsmaNetDevice::SendFrom.

בניגוד לתקני IEEE 802.3, אין PHY שצוין במדויק ב-CSMA
דגם במובן של סוגי חוטים, אותות או pinouts. ממשק ה"תחתון" של
ניתן לחשוב על CsmaNetDevice כמעין ממשק עצמאי של מדיה (MII) כפי שנראה
במפרט "Fast Ethernet" (IEEE 802.3u). ממשק MII זה מתאים ל-a
ממשק מדיה בלתי תלוי ב-CsmaChannel. לא תמצא את
שווה ערך ל-10BASE-T או 1000BASE-LX PHY.

ה-CsmaNetDevice קורא ל-CsmaChannel דרך ממשק בלתי תלוי במדיה. יש
שיטה שהוגדרה כדי לומר לערוץ מתי להתחיל "להתנועע בחוטים" באמצעות השיטה
CsmaChannel::TransmitStart, ושיטה לספר לערוץ מתי תהליך השידור
הסתיים והערוץ צריך להתחיל להפיץ את החלק האחרון על פני "החוט":
CsmaChannel::TransmitEnd.

כאשר מתבצעת שיטת TransmitEnd, הערוץ ידגמן אות אחיד בודד
עיכוב התפשטות במדיום ומסיר קופי החבילה לכל אחד מהמכשירים
מצורף לחבילה באמצעות שיטת CsmaNetDevice::Receive.

יש "pin" בממשק המדיה הבלתי תלוי של המכשיר המתאים ל-"COL"
(הִתנַגְשׁוּת). ניתן לחוש את מצב הערוץ על ידי קריאה ל-CsmaChannel::GetState. כל אחד
המכשיר יסתכל על ה"פין" הזה לפני תחילת השליחה ויבצע גיבוי מתאים
פעולות במידת הצורך.

מנות שהתקבלו כהלכה מועברות לרמות גבוהות יותר מה-CsmaNetDevice באמצעות a
מנגנון התקשרות חוזרת. פונקציית ההתקשרות חוזרת מאתחלת על ידי השכבה הגבוהה יותר (כאשר הרשת
המכשיר מצורף) באמצעות CsmaNetDevice::SetReceiveCallback ומופעל על "ראוי"
קליטה של ​​חבילה על ידי מכשיר הרשת על מנת להעביר את החבילה במעלה הפרוטוקול
ערימה.

CSMA ערוץ מספר סימוכין
הכיתה CsmaChannel מדגמנת את אמצעי השידור בפועל. אין מגבלה קבועה עבור
מספר המכשירים המחוברים לערוץ. CsmaChannel מדגים קצב נתונים ו-a
עיכוב מהירות האור שאליו ניתן לגשת באמצעות התכונות "DataRate" ו-"Delay"
בהתאמה. קצב הנתונים המסופק לערוץ משמש להגדרת קצבי הנתונים שבהם משתמשים
קטעי המשדר של התקני CSMA המחוברים לערוץ. אין דרך לעשות זאת
להגדיר באופן עצמאי קצבי נתונים במכשירים. מכיוון שקצב הנתונים משמש רק לחישוב
זמן השהייה, אין הגבלה (מלבד סוג הנתונים שמחזיק את הערך).
המהירות שבה ערוצי CSMA ומכשירים יכולים לפעול; וללא הגבלה על סמך אף אחת
סוג של מאפייני PHY.

ל-CsmaChannel יש שלושה מצבים, לְהִתְבַּטֵל, שידור ו מתפשט. שלוש המדינות הללו
"נראים" באופן מיידי על ידי כל המכשירים בערוץ. בכך אנו מתכוונים שאם אחד
המכשיר מתחיל או מסיים שידור מדומה, כל המכשירים בערוץ הם מיד
מודעים לשינוי במצב. אין זמן שבמהלכו מכשיר אחד עשוי לראות לְהִתְבַּטֵל
ערוץ בעוד שמכשיר אחר רחוק יותר פיזית בתחום ההתנגשות עשוי להיות
התחילו לשדר כשהאותות הקשורים לא התפשטו בערוץ לאחר
מכשירים. לפיכך אין צורך בזיהוי התנגשות במודל CsmaChannel וזהו
לא מיושם בשום צורה.

יש לנו, כפי שהשם מעיד, היבט של Carrier Sense לדגם. מאז
הסימולטור הוא פתיל יחיד, הגישה לערוץ המשותף תבוצע בסידרה על ידי
מַדמֶה. זה מספק מנגנון דטרמיניסטי להתמודדות על הערוץ. ה
הערוץ מוקצה (הועבר ממצב לְהִתְבַּטֵל לציין שידור) על כל הקודם זוכה
בסיס ראשון. הערוץ תמיד עובר תהליך של שלושה מצבים:

בטלה -> שידור -> התפשטות -> בטלה

השמיים שידור המדינה מדגימה את הזמן שבמהלכו נמצא בפועל התקן נטו המקור
מניע את האותות על החוט. ה מתפשט מדינה מודלים את הזמן שאחרי החלק האחרון
נשלח, כאשר האות מתפשט לאורך החוט ל"קצה הרחוק".

המעבר ל- שידור המדינה מונעת על ידי קריאה אל
CsmaChannel::TransmitStart שנקרא על ידי מכשיר הרשת שמשדר את החבילה. זה
באחריותו של אותו מכשיר לסיים את השידור עם שיחה אל
CsmaChannel::TransmitEnd בזמן הסימולציה המתאים המשקף את הזמן שחלף
לשים את כל חלקי החבילה על החוט. כאשר קוראים ל-TransmitEnd, הערוץ
מתזמן אירוע המתאים לעיכוב בודד של מהירות האור. עיכוב זה חל על
כל מכשירי הרשת בערוץ זהים. אתה יכול לחשוב על רכזת סימטרית שבה
סיביות החבילות מתפשטות למיקום מרכזי ואז יוצאות החוצה כבלים באורך שווה
שאר המכשירים בערוץ. ההשהיה היחידה של "מהירות האור" תואמת אז
הזמן שלוקח ל: 1) אות להתפשט מ-CsmaNetDevice אחד דרך הכבל שלו
לרכזת; פלוס 2) הזמן שלוקח לרכזת להעביר את החבילה החוצה יציאה; ועוד
3) הזמן שלוקח לאות המדובר להתפשט לרשת היעד
מכשיר.

ה-CsmaChannel מדגמן מדיום שידור כך שהחבילה מועברת לכל המכשירים
בערוץ (כולל המקור) בתום זמן ההפצה. זה
אחריות המכשיר השולח לקבוע אם הוא מקבל חבילה או לא
משודר בערוץ.

CsmaChannel מספק את התכונות הבאות:

· DataRate: קצב הסיביות להעברת מנות במכשירים מחוברים;

· Delay: מהירות ההשהיה של שידור האור עבור הערוץ.

CSMA נֶטוֹ מכשיר מספר סימוכין
התקן הרשת CSMA נראה קצת כמו התקן Ethernet. ה-CsmaNetDevice
מספק את התכונות הבאות:

· כתובת: כתובת ה-Mac48 של המכשיר;

· SendEnable: אפשר שידור מנות אם נכון;

· ReceiveEnable: אפשר קליטת מנות אם נכון;

· EncapsulationMode: סוג אנקפסולציה של שכבת קישור לשימוש;

· RxErrorModel: מודל שגיאת הקבלה;

· TxQueue: תור השידור המשמש את המכשיר;

· InterframeGap: הזמן האופציונלי להמתנה בין "פריימים";

· Rx: מקור מעקב עבור מנות שהתקבלו;

· Drop: מקור מעקב עבור מנות שנפלו.

ה-CsmaNetDevice תומך בהקצאה של "מודל שגיאת קבלה". זה
אובייקט ErrorModel המשמש כדי לדמות שחיתות נתונים בקישור.

מנות הנשלחות דרך CsmaNetDevice מנותבות תמיד דרך תור השידור אל
לספק וו מעקב עבור מנות הנשלחות דרך הרשת. ניתן להגדיר תור שידור זה
(באמצעות תכונה) למודל של אסטרטגיות תור שונות.

ניתן להגדיר גם לפי תכונה שיטת האנקפסולציה שבה משתמש המכשיר. כֹּל
packet מקבל EthernetHeader הכולל את כתובות היעד והמקור של MAC, ו
שדה אורך/סוג. כל חבילה מקבלת גם EthernetTrailer הכולל את ה-FCS.
הנתונים בחבילה עשויים להיות מובלעים בדרכים שונות.

כברירת מחדל, או על ידי הגדרת התכונה "EncapsulationMode" ל-"Dix", האנקפסולציה היא
לפי תקן DEC, Intel, Xerox. זה נקרא לפעמים EthernetII framing
והוא הפורמט המוכר של 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 תפוצה) כשהמכשיר רוצה
להתחיל להפיץ. זה גורם להשהייה אקראית של עד pow ​​(2, ניסיונות חוזרים) - 1
מיקרו שניות לפני ניסיון חוזר. ברירת המחדל המספר המרבי של ניסיונות חוזרים הוא 1000.

שימוש מה היא CsmaNetDevice
מכשירי וערוצים נטו של CSMA נוצרים ומוגדרים בדרך כלל באמצעות
המשויך CsmaHelper לְהִתְנַגֵד. השונות ns-3 עוזרי התקן עובדים בדרך כלל בדומה
דרך, והשימוש בהם נראה ברבות מהתוכניות שלנו לדוגמה.

המודל הרעיוני לעניין הוא של "קליפת" מחשב חשופה שאליו אתה מחבר את הרשת
מכשירים. המחשבים החשופים נוצרים באמצעות a NodeContainer עוֹזֵר. אתה פשוט שואל את זה
עוזר ליצור כמה שיותר מחשבים (אנחנו קוראים להם צמתים) כפי שאתה צריך ברשת שלך:

NodeContainer csmaNodes;
csmaNodes.Create (nCsmaNodes);

ברגע שיש לך את הצמתים שלך, אתה צריך ליצור מופע א CsmaHelper ולהגדיר את כל התכונות שאתה
אולי רוצה לשנות.:

CsmaHelper csma;
csma.SetChannelAttribute ("קצב נתונים", StringValue ("100Mbps"));
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 Datagrams דרך רשתות Ethernet." המספר נגזר למעשה מ
גודל החבילה המרבי עבור רשתות 10Base5 (מפרט מלא Ethernet) -- 1518 בתים. אם אתה
להחסיר תקורה של DIX encapsulation עבור מנות Ethernet (18 בתים) בסופו של דבר תקבל א
גודל נתונים מרבי אפשרי (MTU) של 1500 בתים. אפשר גם למצוא את ה-MTU עבור IEEE
רשתות 802.3 הן 1492 בתים. הסיבה לכך היא כי אנקפסולציה של LLC/SNAP מוסיפה שמונה נוספים
בתים של תקורה לחבילה. בשני המקרים, חומרת הרשת הבסיסית היא
מוגבל ל-1518 בתים, אבל ה-MTU שונה כי האנקפסולציה שונה.

אם משאירים את תכונת Mtu ב-1500 בתים ומשנים את תכונת מצב האנקפסולציה
ל-Llc, התוצאה תהיה רשת שתכלול רכיבי PDU של 1500 בתים עם LLC/SNAP
מסגור וכתוצאה מכך מנות של 1526 בתים. זה יהיה בלתי חוקי ברשתות רבות, אבל
אנו מאפשרים לך לעשות זאת. זה מביא לסימולציה שלא משקפת בצורה עדינה למדי
למה אתה עשוי לצפות מכיוון שמכשיר אמיתי יסרב לשלוח חבילה של 1526 בתים.

קיימות גם מסגרות ג'מבו (1500 < MTU <= 9000 בתים) וסופר-ג'מבו (MTU > 9000
bytes) מסגרות שאינן מאושרות רשמית על ידי IEEE אך זמינות בחלקן
רשתות מהירות (Gigabit) ו-NIC. במודל CSMA, אפשר להשאיר את
מצב אנקפסולציה מוגדר ל-Dix, והגדר את ה-Mtu ל-64000 בתים -- למרות
CsmaChannel DataRate נותר על 10 מגה-ביט לשנייה (בוודאי לא Gigabit Ethernet).
זה בעצם ידגם מתג אתרנט העשוי בסגנון שנות השמונים של המאה הקודמת
רשתות 10Base5 שתומכות ב- super-jumbo datagrams, וזה בהחלט לא משהו כזה
נוצר אי פעם, וסביר להניח שלא ייעשה אי פעם; עם זאת, זה די קל עבורך
להגדיר.

היזהר מהנחות לגבי מה CSMA היא בעצם דוגמנות וכיצד
תצורה (תכונות) עשויה לאפשר לך להתרחק במידה ניכרת מהמציאות.

CSMA מעקב
כמו כולם ns-3 מכשירים, דגם CSMA מספק מספר מקורות עקבות. אלה עקבות
ניתן לחבר מקורות באמצעות קוד מעקב מותאם אישית משלך, או שאתה יכול להשתמש בעוזר שלנו
פונקציות כדי לארגן את הפעלת המעקב במכשירים שאתה מציין.

שלב גבוה יותר (מק) הוקס
מנקודת מבט של מעקב במכשיר הרשת, ישנן מספר נקודות מעניינות
כדי להכניס ווי עקבות. מוסכמה שעברה בירושה מסימולטורים אחרים היא שמנות
המיועדים לשידור לרשתות מחוברות עוברים דרך "תור שידור" בודד ב
מכשיר הרשת. אנו מספקים ווי מעקב בשלב זה בזרימת מנות, התואמת
(באופן אבסטרקטי) רק למעבר מהרשת לשכבת קישור נתונים, ולקרוא להם
יחד את ה-MAC הווים המכשיר.

כאשר חבילה נשלחת למכשיר CSMA net לשידור היא תמיד עוברת דרך
תור שידור. תור השידור ב-CsmaNetDevice יורש מ-Queue, ולכן
יורש שלושה מקורות עקבות:

· מקור פעולת Enqueue (ראה Queue::m_traceEnqueue);

· מקור פעולת Dequeue (ראה Queue::m_traceDequeue);

· מקור פעולת Drop (ראה Queue::m_traceDrop).

ווי המעקב ברמה העליונה (MAC) עבור CsmaNetDevice הם, למעשה, בדיוק שלושת אלה
מעקב אחר מקורות על תור השידור היחיד של המכשיר.

אירוע m_traceEnqueue מופעל כאשר מנות מונחת בתור השידור. זֶה
קורה בזמן ש-CsmaNetDevice::Send או CsmaNetDevice::SendFrom נקראים על ידי
שכבה גבוהה יותר לתור חבילה לשידור.

אירוע m_traceDequeue מופעל כאשר מנות מוסרת מתור השידור.
תורים מתור השידור יכולים לקרות בשלושה מצבים: 1) אם הבסיס
הערוץ אינו פעיל כאשר קוראים ל-CsmaNetDevice::Send או CsmaNetDevice::SendFrom,
החבילה מושבתת בתור השידור ומשודרת מיד; 2) אם ה
הערוץ הבסיסי אינו פעיל, חבילה עשויה להתנתק מהתור ולהעביר אותה מיד ב-an
Intern TransmitCompleteEvent שמתפקד בדומה להפסקת שידור מלאה
שגרת שירות; או 3) מהמטפל אקספוננציאלי לאחור אם יש פסק זמן
זוהה.

מקרה (3) מרמז שחבילה מושבתת בתור השידור אם היא לא יכולה להיות
מועבר על פי כללי הגיבוי. חשוב להבין שזה יהיה
להופיע כחבילה ב-Dequeued וקל להניח בטעות שהחבילה הייתה
משודר מאז שעבר דרך תור השידור. למעשה, חבילה היא למעשה
נפל על ידי מכשיר הרשת במקרה זה. הסיבה להתנהגות זו היא בשל
הגדרה של אירוע הורדת התור. אירוע m_traceDrop מופעל, בהגדרה, כאשר א
לא ניתן להציב מנות בתור השידור מכיוון שהיא מלאה. האירוע הזה רק יורה
אם התור מלא ואנחנו לא מעמיסים את האירוע הזה כדי לציין ש-CsmaChannel כן
"מלא."

רמה נמוכה יותר (PHY) הוקס
בדומה לווי העקבות ברמה העליונה, ישנם ווי מעקב זמינים בחלק התחתון
רמות של מכשיר הרשת. אנחנו קוראים לזה ה-PHY hooks. אירועים אלו יורים מהמכשיר
שיטות המדברות ישירות אל CsmaChannel.

מקור המעקב m_dropTrace נקרא כדי לציין חבילה שנפלטה על ידי המכשיר.
זה קורה בשני מקרים: ראשית, אם צד הקבלה של מכשיר הרשת אינו מופעל
(ראה CsmaNetDevice::m_receiveEnable והתכונה המשויכת "ReceiveEnable").

ה-m_dropTrace משמש גם כדי לציין שחבילה נמחקה כפגומה אם א
נעשה שימוש במודל השגיאה לקבל (ראה CsmaNetDevice::m_receiveErrorModel והמשויך
התכונה "ReceiveErrorModel").

מקור העקבות האחר ברמה הנמוכה נורה עם קליטה של ​​חבילה מקובלת (ראה
CsmaNetDevice::m_rxTrace). חבילה מתקבלת אם היא מיועדת לשידור
כתובת, כתובת ריבוי שידור, או לכתובת ה-MAC שהוקצתה למכשיר הרשת.

<br> סיכום
דגם ns3 CSMA הוא דגם פשטני של רשת דמוית אתרנט. זה תומך ב
פונקציית Carrier-Sense ומאפשרת גישה מרובה למדיום משותף. זה לא
פיזי במובן שמצב המדיום משותף בין כולם באופן מיידי
מכשירים. המשמעות היא שאין צורך בזיהוי התנגשות בדגם זה ואף לא
מיושם. לעולם לא תהיה "ריבה" של חבילה כבר על המדיום. גישה ל
הערוץ המשותף הוא על בסיס כל הקודם זוכה כפי שנקבע על ידי הסימולטור
מתזמן. אם הערוץ נחוש להיות עסוק בהסתכלות על המצב העולמי, א
החזרה אקספוננציאלית אקראית מבוצעת וניסיון חוזר.

Ns-3 Attributes מספקים מנגנון להגדרת פרמטרים שונים במכשיר ו
ערוץ כגון כתובות, מצבי אנקפסולציה ובחירת מודל שגיאה. ווים עקבות הם
מסופק באופן הרגיל עם סט ווים ברמה העליונה התואמים לשדר
תור ומשמש במעקב ASCII; וגם סט של ווים ברמה נמוכה יותר המשמשים למעקב אחר pcap.

למרות שה-ns-3 CsmaChannel ו-CsmaNetDevice לא מדגמים לך שום סוג של רשת
יכול לבנות או לקנות, זה כן מספק לנו פונקציונליות שימושית כלשהי. אתה צריך,
עם זאת, הבינו שזה בפירוש לא Ethernet או כל טעם של IEEE 802.3 אלא
תת קבוצה מעניינת.

נתונים COLLECTION

פרק זה מתאר את מסגרת איסוף הנתונים ns-3 (DCF), המספקת
יכולות להשיג נתונים שנוצרו על ידי מודלים בסימולטור, לביצוע און ליין
הפחתה ועיבוד נתונים, וכן לרכז נתונים גולמיים או שעברו טרנספורמציה לתפוקות שונות
פורמטים.

המסגרת תומכת כיום בריצות עצמאיות של ns-3 שאינן מסתמכות על אף חיצוני
בקרת ביצוע תוכנית. האובייקטים שסופקו על ידי DCF עשויים להיות מחוברים אליהם ns-3 להתחקות
מקורות כדי לאפשר עיבוד נתונים.

קוד המקור של השיעורים נמצא בספרייה src/stats.

פרק זה מאורגן באופן הבא. ראשית, סקירה כללית של הארכיטקטורה היא
הוצג. בהמשך, מוצגים העוזרים לכיתות אלו; טיפול ראשוני זה
צריך לאפשר שימוש בסיסי במסגרת איסוף הנתונים עבור מקרי שימוש רבים. משתמשים אשר
רוצים לייצר פלט מחוץ לתחום העוזרים הנוכחיים, או שרוצים ליצור
אובייקטי איסוף הנתונים שלהם, צריכים לקרוא את המשך הפרק, אשר הולך
לפרטים על כל סוגי האובייקטים הבסיסיים של DCF ומספק קידוד ברמה נמוכה
דוגמאות.

עיצוב
DCF מורכב משלושה מחלקות בסיסיות:

· בדיקה הוא מנגנון למכשיר ובקרה על הפלט של נתוני סימולציה כלומר
משמש למעקב אחר אירועים מעניינים. זה מייצר פלט בצורה של אחד או יותר ns-3
מקורות עקבות. חפצי בדיקה מחוברים לעקבה אחת או יותר כיורים (שקוראים לו
אספנים), אשר מעבדים דוגמאות און ליין ומכינות אותן לפלט.

· אספן צורכת את הנתונים שנוצרו על ידי אובייקט Probe אחד או יותר. זה מבצע
טרנספורמציות על הנתונים, כגון נורמליזציה, הפחתה וחישוב של
סטטיסטיקה בסיסית. אובייקטי אספן אינם מייצרים נתונים המופקים ישירות על ידי ה
ריצת ns-3; במקום זאת, הם פלטים נתונים במורד הזרם לסוג אחר של אובייקט, הנקרא
צבר, שמבצע את הפונקציה הזו. בדרך כלל, אספנים מוציאים את הנתונים שלהם פנימה
גם בצורת מקורות עקבות, המאפשרים לכבול אספנים בסדרות.

· צבר היא נקודת הסיום של הנתונים שנאספו על ידי רשת של בדיקות ואספנים.
האחריות העיקרית של האגרגטור היא לרכז נתונים והתאמתם
מטא נתונים, לפורמטים שונים של פלט כגון קבצי טקסט רגיל, קבצי גיליונות אלקטרוניים, או
מאגרי מידע.

כל שלושת המחלקות הללו מספקות את היכולת להפעיל או לכבות את עצמם באופן דינמי
לאורך סימולציה.

כל עצמאי ns-3 ריצת סימולציה המשתמשת ב- DCF תיצור בדרך כלל לפחות אחד
מופע של כל אחת משלושת המחלקות לעיל.
[תמונה] סקירת מסגרת איסוף נתונים.UNINDENT

הזרימה הכוללת של עיבוד הנתונים מתוארת ב נתונים אוספים מסגרת סקירה.
בצד שמאל, ריצה ns-3 סימולציה מתוארת. במהלך הפעלת ה
סימולציה, הנתונים זמינים על ידי מודלים באמצעות מקורות עקבות, או באמצעים אחרים.
התרשים מתאר שניתן לחבר בדיקות למקורות עקבות אלה כדי לקבל נתונים
באופן אסינכרוני, או בדיקות יכולות לבצע סקר נתונים. לאחר מכן, הנתונים מועברים לאובייקט אספן
שהופך את הנתונים. לבסוף, ניתן לחבר אגרגטור ליציאות של
אספן, ליצירת מגרשים, קבצים או מסדי נתונים.
[תמונה] אגרגציה של מסגרת איסוף נתונים.UNINDENT

וריאציה על האיור לעיל מסופקת ב נתונים אוספים מסגרת - צבירה.
איור שני זה ממחיש שאובייקטי DCF עשויים להיות משורשרים יחדיו באופן
שאובייקטים במורד הזרם מקבלים תשומות ממספר אובייקטים במעלה הזרם. הצורה
מראה קונספטואלית שמספר בדיקות עשויות ליצור פלט שמוזן ליחידה
אַסְפָן; כדוגמה, אספן שמפיק יחס של שני מונים יעשה זאת
בדרך כלל רוכשים כל נתוני מונה מבדיקות נפרדות. אספנים מרובים יכולים גם כן
הזנה לתוך אגרגטור יחיד, אשר (כשמו כן הוא) עשוי לאסוף מספר נתונים
זרמים להכללה בחלקה, קובץ או מסד נתונים בודדים.

נתונים אוספים עוזרים
הגמישות המלאה של מסגרת איסוף הנתונים מסופקת על ידי הקישוריות
של בדיקות, אספנים ואגרגטורים. ביצוע כל החיבורים הללו מוביל ל
הצהרות תצורה רבות בתוכניות משתמש. לנוחות השימוש, חלק מהנפוצים ביותר
ניתן לשלב פעולות ולכלול אותן בפונקציות עוזר. בנוסף, כמה
אמירות המעורבות ns-3 למקורות עקבות אין כריכות Python, עקב מגבלות ב
הכריכות.

נתונים אוספים עוזרים סקירה כללית
בחלק זה, אנו מספקים סקירה כללית של כמה כיתות עוזר שנוצרו עבור
להקל על התצורה של מסגרת איסוף הנתונים עבור כמה מקרי שימוש נפוצים. ה
עוזרים מאפשרים למשתמשים ליצור פעולות נפוצות עם רק כמה הצהרות ב-C++ או
תוכניות פייתון. אבל, קלות השימוש הזו באה במחיר של פחות משמעותית
גמישות מאשר תצורה ברמה נמוכה יכולה לספק, והצורך בקוד מפורש
תמיכה בסוגי בדיקה חדשים לתוך העוזרים (כדי לעקוף בעיה המתוארת להלן).

הדגש על העוזרים הנוכחיים הוא לסדר נתונים ns-3 להתחקות אחר מקורות לתוך
עלילות gnuplot או קבצי טקסט, ללא רמה גבוהה של התאמה אישית של פלט או סטטיסטיקה
עיבוד (בהתחלה). כמו כן, השימוש מוגבל לסוגי הבדיקה הזמינים ב
ns-3. חלקים מאוחרים יותר בתיעוד זה יפרטו יותר על יצירת חדש
סוגי בדיקה, כמו גם פרטים על חיבור בדיקות, אספנים ואגרגטורים
בסידורים מותאמים אישית.

עד כה, שני עוזרי איסוף נתונים יושמו:

· GnuplotHelper

· FileHelper

GnuplotHelper
ה-GnuplotHelper הוא מחלקה עוזרת להפקת קבצי פלט המשמשים לייצור גנופלוטים. ה
המטרה הכללית היא לספק למשתמשים את היכולת ליצור במהירות עלילות מנתונים מיוצאים
in ns-3 מקורות עקבות. כברירת מחדל, מתבצעת כמות מינימלית של שינוי נתונים;
המטרה היא ליצור מגרשים עם כמה שפחות הצהרות תצורה (ברירת מחדל).
אפשרי.

GnuplotHelper סקירה כללית
ה-GnuplotHelper יצור 3 קבצים שונים בסוף הסימולציה:

· קובץ נתוני gnuplot מופרדים מרווחים

· קובץ בקרת גנופלוט

· סקריפט מעטפת ליצירת הגנופלוט

ישנן שתי הצהרות תצורה שדרושות להפקת עלילות. הראשון
המשפט מגדיר את העלילה (שם קובץ, כותרת, אגדות וסוג פלט, שבו הפלט
סוג ברירת המחדל ל-PNG אם לא צוין):

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

ההצהרה השנייה תופסת את מקור העניין:

void PlotProbe (const std::string &typeId,
const std::string &path,
const std::string &probeTraceSource,
const std::string &title);

הטיעונים הם כדלקמן:

· typeId: ה ns-3 TypeId של הבדיקה

· נתיב: השביל ב- ns-3 מרחב שמות של תצורה למקור מעקב אחד או יותר

· probeTraceSource: איזה פלט של הבדיקה (בעצמה מקור עקבות) צריך להיות משורטט

· כותרת: הכותרת שיש לשייך למערך הנתונים (במקרא ה-gnuplot)

גרסה של PlotProbe לעיל היא לציין ארגומנט אופציונלי חמישי השולט
היכן בעלילה ממוקם המפתח (אגדה).

דוגמה מעובדת במלואה (מ seventh.cc) מוצג להלן:

// צור את עוזר הגנופלוט.
GnuplotHelper plotHelper;

// הגדר את העלילה.
// הגדר את העלילה. הארגומנט הראשון הוא קידומת שם הקובץ
// עבור קבצי הפלט שנוצרו. השני, השלישי והרביעי
// ארגומנטים הם, בהתאמה, כותרת העלילה, תוויות ציר ה-x וציר ה-y
plotHelper.ConfigurePlot ("ספירת-חבילה-שביעית-בתים",
"ספירת בתים של חבילה לעומת זמן",
"זמן (שניות)",
"ספירת בתים של חבילה",
"png");

// ציין את סוג הבדיקה, נתיב המקור (במרחב השמות של התצורה), וכן
// בדיקה מקור עקבות פלט ("OutputBytes") כדי לתכנן. הטיעון הרביעי
// מציין את השם של תווית סדרת הנתונים על העלילה. האחרון
// ארגומנט מעצב את העלילה על ידי ציון היכן יש למקם את המפתח.
plotHelper.PlotProbe (probeType,
tracePath,
"OutputBytes",
"ספירת בתים של חבילה",
GnuplotAggregator::KEY_BELOW);

בדוגמה זו, probeType ו tracePath הם כדלקמן (עבור IPv4):

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

ה-probeType הוא פרמטר מפתח כדי שהעוזר הזה יעבוד. TypeId זה חייב להיות רשום
במערכת, והחתימה על כיור העקיבה של ה-Probe חייבת להתאים לזו של העקיבה
מקור אליו הוא מחובר. סוגי בדיקה מוגדרים מראש עבור מספר סוגי נתונים
המקביל ל ns-3 ערכי מעקב, ועבור כמה חתימות אחרות של מקור מעקב כגון
מקור העקבות 'Tx' של ns3::Ipv4L3Protocol מעמד.

שים לב שנתיב מקור המעקב שצוין עשוי להכיל תווים כלליים. במקרה זה, מרובה
מערכי נתונים משורטטים על חלקה אחת; אחד עבור כל נתיב מותאם.

הפלט העיקרי שיופק יהיה שלושה קבצים:

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

בשלב זה, משתמשים יכולים לערוך ביד את קובץ ה-.plt עבור התאמות אישיות נוספות, או
פשוט הפעל את זה דרך גנופלוט. רץ sh seventh-packet-byte-count.sh פשוט מנהל את העלילה
דרך gnuplot, כפי שמוצג להלן.
[תמונה] 2-D Gnuplot נוצר על ידי seventh.cc דוגמה..UNINDENT

ניתן לראות שמרכיבי המפתח (אגדה, כותרת, מיקום מקרא, xlabel, ylabel,
והנתיב לנתונים) ממוקמים כולם על העלילה. מאז היו שני התאמות ל
נתיב תצורה מסופק, שתי סדרות הנתונים מוצגות:

· ספירת בתים של מנות-0 מתאימה ל-/NodeList/0/$ns3::Ipv4L3Protocol/Tx

· ספירת בתים של מנות-1 מתאימה ל-/NodeList/1/$ns3::Ipv4L3Protocol/Tx

GnuplotHelper ConfigurePlot
ה-GnuplotHelper's ConfigurePlot() ניתן להשתמש בפונקציה כדי להגדיר מגרשים.

יש לו את אב הטיפוס הבא:

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

יש לו את הטיעונים הבאים:

┌───────────────────────────────┬───────────────── ─────────────────┐
│טיעון │ תיאור │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension │ שם של קבצים הקשורים ל-gnuplot אל │
│ │ כתוב ללא סיומת. │
├───────────────────────────────┼───────────────── ─────────────────┤
│כותרת │ מחרוזת כותרת עלילה לשימוש עבור │
│ │ העלילה הזו. │
└───────────────────────────────┴───────────────── ─────────────────┘

│xLegend │ המקרא עבור ה-x האופקי │
ציר │ │. │
├───────────────────────────────┼───────────────── ─────────────────┤
│yLegend │ המקרא עבור אנכי y │
ציר │ │. │
├───────────────────────────────┼───────────────── ─────────────────┤
│terminalType │ מחרוזת הגדרת סוג טרמינל עבור │
│ │ פלט. מסוף ברירת המחדל │
סוג │ │ הוא "png". │
└───────────────────────────────┴───────────────── ─────────────────┘

ה-GnuplotHelper's ConfigurePlot() הפונקציה מגדירה פרמטרים הקשורים לעלילה עבור זה
gnuplot helper כך שהוא יצור קובץ נתוני gnuplot מופרד מרווח בשם
outputFileNameWithoutExtension + ".dat", קובץ בקרת gnuplot בשם
outputFileNameWithoutExtension + ".plt", וסקריפט מעטפת ליצירת הגנופלוט בשם
outputFileNameWithoutExtension + ".sh".

דוגמה לשימוש בפונקציה זו ניתן לראות ב- seventh.cc קוד שתואר לעיל
שבו נעשה בו שימוש באופן הבא:

plotHelper.ConfigurePlot ("ספירת-חבילה-שביעית-בתים",
"ספירת בתים של חבילה לעומת זמן",
"זמן (שניות)",
"ספירת בתים של חבילה",
"png");

GnuplotHelper PlotProbe
ה-GnuplotHelper's PlotProbe() ניתן להשתמש בפונקציה כדי לשרטט ערכים שנוצרו על ידי בדיקות.

יש לו את אב הטיפוס הבא:

void PlotProbe (const std::string &typeId,
const std::string &path,
const std::string &probeTraceSource,
const std::string &title,
enum GnuplotAggregator::KeyLocation keyLocation = GnuplotAggregator::KEY_INSIDE);

יש לו את הטיעונים הבאים:

┌─────────────────┬─────────────────────────────── ───┐
│טיעון │ תיאור │
├─────────────────┼─────────────────────────────── ───┤
│typeId │ מזהה הסוג של הבדיקה │
│ │ נוצר על ידי עוזר זה. │
├─────────────────┼─────────────────────────────── ───┤
│נתיב │ הגדר נתיב לגישה למעקב │
│ │ מקור. │
├─────────────────┼─────────────────────────────── ───┤
│probeTraceSource │ מקור מעקב הבדיקה אל │
│ │ גישה. │
├─────────────────┼─────────────────────────────── ───┤
│כותרת │ הכותרת שיש לשייך אליה │
│ │ מערך הנתונים הזה │
├─────────────────┼─────────────────────────────── ───┤
│keyLocation │ מיקום המפתח ב│
│ │ עלילה. מיקום ברירת המחדל הוא │
│ │ בפנים. │
└─────────────────┴─────────────────────────────── ───┘

ה-GnuplotHelper's PlotProbe() function משרטט מערך נתונים שנוצר על ידי חיבור של ns-3
התחקות אחר מקור עם בדיקה שנוצרה על ידי העוזר, ולאחר מכן מתווה את הערכים מה-
probeTraceSource. למערך הנתונים תהיה הכותרת שסופקה, והוא יהיה מורכב מה-
'newValue' בכל חותמת זמן.

אם לנתיב התצורה יש יותר מהתאמה אחת במערכת בגלל שיש תו כללי, אז
מערך נתונים אחד עבור כל התאמה ישורטט. כותרות מערך הנתונים יסתיימו ב-
תווים מותאמים לכל אחד מהתווים הכלליים בנתיב התצורה, מופרדים ברווחים. ל
לדוגמה, אם כותרת הנתונים המוצעים היא המחרוזת "בתים", ויש שני תווים כלליים לחיפוש
בנתיב, אז כותרות מערך נתונים כמו "bytes-0 0" או "bytes-12 9" יהיו אפשריים בתור
תוויות עבור מערכי הנתונים המתוכננים.

דוגמה לשימוש בפונקציה זו ניתן לראות ב- seventh.cc קוד שתואר לעיל
היכן הוא שימש (עם החלפה משתנה) באופן הבא:

plotHelper.PlotProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"OutputBytes",
"ספירת בתים של חבילה",
GnuplotAggregator::KEY_BELOW);

אחר דוגמאות
גנופלוט עוֹזֵר דוגמה
דוגמה קצת יותר פשוטה מה seventh.cc ניתן למצוא דוגמה ב
src/stats/examples/gnuplot-helper-example.cc. הגנופלוט הדו-ממדי הבא נוצר באמצעות
הדוגמה.
[תמונה] Gnuplot דו-ממדי נוצר על ידי gnuplot-helper-example.cc דוגמה..UNINDENT

בדוגמה זו, יש אובייקט פולט שמגדיל את המונה שלו לפי א
Poisson מעבד ולאחר מכן פולט את הערך של המונה כמקור עקבות.

Ptr emitter = CreateObject ();
שמות::Add ("/שמות/פולט", פולט);

שים לב שבגלל שאין תווים כלליים בנתיב המשמש למטה, רק זרם נתונים אחד היה
מצוייר בעלילה. זרם הנתונים הבודד הזה בעלילה נקרא פשוט "ספירת פולטים",
ללא סיומות נוספות כמו שאפשר לראות אם יש תווים כלליים בנתיב.

// צור את עוזר הגנופלוט.
GnuplotHelper plotHelper;

// הגדר את העלילה.
plotHelper.ConfigurePlot ("gnuplot-helper-example",
"ספירת פולטים לעומת זמן",
"זמן (שניות)",
"ספירת פולטים",
"png");

// ציירו את הערכים שנוצרו על ידי הגשושית. הדרך שאנו מספקים
// עוזר לבלבל את מקור העקבות.
plotHelper.PlotProbe ("ns3::Uinteger32Probe",
"/שמות/פולט/מונה",
"תְפוּקָה",
"ספירת פולטים",
GnuplotAggregator::KEY_INSIDE);

FileHelper
ה-FileHelper הוא מחלקת עוזר המשמשת להכנסת ערכי נתונים לקובץ. המטרה הכללית היא
כדי לספק למשתמשים את היכולת ליצור במהירות קבצי טקסט מעוצבים מנתונים מיוצאים
in ns-3 מקורות עקבות. כברירת מחדל, מתבצעת כמות מינימלית של שינוי נתונים;
המטרה היא ליצור קבצים עם כמה שפחות הצהרות תצורה (ברירת מחדל).
אפשרי.

FileHelper סקירה כללית
ה-FileHelper יצור קובץ טקסט אחד או יותר בסוף הסימולציה.

ה-FileHelper יכול ליצור 4 סוגים שונים של קבצי טקסט:

· מעוצב

· רווח מופרד (ברירת המחדל)

· מופרד באמצעות פסיקים

· כרטיסיות מופרדות

קבצים מעוצבים משתמשים במחרוזות פורמט בסגנון C ובפונקציה sprintf() כדי להדפיס אותם
ערכים בקובץ הנכתב.

קובץ הטקסט הבא עם 2 עמודות של ערכים מעוצבים בשם
seventh-packet-byte-count-0.txt נוצר באמצעות קוד חדש נוסף שהתווסף ל-
מְקוֹרִי ns-3 קוד לדוגמה של הדרכה. רק 10 השורות הראשונות של קובץ זה מוצגות
כאן לקיצור.

זמן (שניות) = 1.000e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.004e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.004e+00 ספירת בתים של מנות = 576
זמן (שניות) = 1.009e+00 ספירת בתים של מנות = 576
זמן (שניות) = 1.009e+00 ספירת בתים של מנות = 576
זמן (שניות) = 1.015e+00 ספירת בתים של מנות = 512
זמן (שניות) = 1.017e+00 ספירת בתים של מנות = 576
זמן (שניות) = 1.017e+00 ספירת בתים של מנות = 544
זמן (שניות) = 1.025e+00 ספירת בתים של מנות = 576
זמן (שניות) = 1.025e+00 ספירת בתים של מנות = 544

...

קובץ הטקסט השונה הבא עם 2 עמודות של ערכים מעוצבים בשם
seventh-packet-byte-count-1.txt נוצר גם באמצעות אותו קוד חדש שנוסף אליו
המקורי ns-3 קוד לדוגמה של הדרכה. רק 10 השורות הראשונות של קובץ זה מוצגות
כאן לקיצור.

זמן (שניות) = 1.002e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.007e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.013e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.020e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.028e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.036e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.045e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.053e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.061e+00 ספירת בתים של מנות = 40
זמן (שניות) = 1.069e+00 ספירת בתים של מנות = 40

...

הקוד החדש שנוסף להפקת שני קבצי הטקסט נמצא למטה. פרטים נוספים על
ממשק API זה יסוקר בסעיף מאוחר יותר.

שימו לב שבגלל שהיו 2 התאמות לתווים הכלליים בנתיב, 2 קובצי טקסט נפרדים
נוצרו. קובץ הטקסט הראשון, ששמו "seventh-packet-byte-count-0.txt",
מתאים להתאמה של התווים הכלליים כשה-"*" מוחלף ב-"0". קובץ הטקסט השני,
ששמו "seventh-packet-byte-count-1.txt", מתאים להתאמה של התווים הכלליים עם
ה-"*" הוחלף ב-"1". כמו כן, שימו לב שהפונקציה קוראת ל WriteProbe() ייתן
הודעת שגיאה אם ​​אין התאמות לנתיב המכיל תווים כלליים.

// צור את עוזר הקובץ.
FileHelper fileHelper;

// הגדר את הקובץ שייכתב.
fileHelper.ConfigureFile ("ספירת-חבילה-שביעית-בתים",
FileAggregator::FORMATTED);

// הגדר את התוויות עבור קובץ הפלט המעוצב הזה.
fileHelper.Set2dFormat ("זמן (שניות) = %.3e\tPacket Byte Count = %.0f");

// כתוב את הערכים שנוצרו על ידי הבדיקה.
fileHelper.WriteProbe ("ns3::Ipv4PacketProbe",
"/NodeList/*/$ns3::Ipv4L3Protocol/Tx",
"OutputBytes");

FileHelper ConfigureFile
של ה-FileHelper ConfigureFile() ניתן להשתמש בפונקציה כדי להגדיר קבצי טקסט.

יש לו את אב הטיפוס הבא:

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

יש לו את הטיעונים הבאים:

┌───────────────────────────────┬───────────────── ─────────────────┐
│טיעון │ תיאור │
├───────────────────────────────┼───────────────── ─────────────────┤
│outputFileNameWithoutExtension │ שם קובץ הפלט לכתיבה │
│ │ ללא הרחבה. │
├───────────────────────────────┼───────────────── ─────────────────┤
│fileType │ סוג הקובץ לכתיבה. ה│
│ │ סוג ברירת המחדל של הקובץ הוא רווח │
│ │ מופרדים. │
└───────────────────────────────┴───────────────── ─────────────────┘

של ה-FileHelper ConfigureFile() הפונקציה מגדירה פרמטרים הקשורים לקובץ טקסט עבור
עוזר קובץ כך שהוא יצור קובץ בשם outputFileNameWithoutExtension plus
מידע נוסף אפשרי מהתאמות עם תווים כלליים בתוספת ".txt" עם ערכים מודפסים כ
שצוין על ידי fileType. סוג הקובץ המוגדר כברירת מחדל הוא מופרד מרווחים.

דוגמה לשימוש בפונקציה זו ניתן לראות ב- seventh.cc קוד שתואר לעיל
שבו נעשה בו שימוש באופן הבא:

fileHelper.ConfigureFile ("ספירת-חבילה-שביעית-בתים",
FileAggregator::FORMATTED);

FileHelper WriteProbe
של ה-FileHelper WriteProbe() ניתן להשתמש בפונקציה כדי לכתוב ערכים שנוצרו על ידי בדיקות ל
קבצי טקסט.

יש לו את אב הטיפוס הבא:

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

יש לו את הטיעונים הבאים:

┌─────────────────┬─────────────────────────────── ───┐
│טיעון │ תיאור │
├─────────────────┼─────────────────────────────── ───┤
│typeId │ מזהה הסוג עבור הגשוש להיות │
│ │ נוצר. │
├─────────────────┼─────────────────────────────── ───┤
│נתיב │ הגדר נתיב לגישה למעקב │
│ │ מקור. │
├─────────────────┼─────────────────────────────── ───┤
│probeTraceSource │ מקור מעקב הבדיקה אל │
│ │ גישה. │
└─────────────────┴─────────────────────────────── ───┘

של ה-FileHelper WriteProbe() הפונקציה יוצרת קובצי טקסט פלט שנוצרו על ידי חיבור של
מקור התחקות ns-3 עם בדיקה שנוצרה על ידי העוזר, ולאחר מכן כתיבת הערכים מה-
probeTraceSource. שמות קבצי הפלט יאוחסנו במשתנה האיבר
m_outputFileNameWithoutExtension בתוספת ".txt", והוא יהיה מורכב מה-newValue בכל אחד
חותמת זמן.

אם לנתיב התצורה יש יותר מהתאמה אחת במערכת בגלל שיש תו כללי, אז
יווצר קובץ פלט אחד עבור כל התאמה. שמות קבצי הפלט יכילו את
טקסט ב-m_outputFileNameWithoutExtension בתוספת התווים התואמים עבור כל אחד מה-
תווים כלליים בנתיב התצורה, מופרדים באמצעות מקפים, בתוספת ".txt". לדוגמה, אם הערך
ב-m_outputFileNameWithoutExtension היא המחרוזת "packet-byte-count", ויש שניים
תווים כלליים בנתיב, ואז פלט שמות קבצים כמו "packet-byte-count-0-0.txt" או
"packet-byte-count-12-9.txt" יהיה אפשרי בתור שמות לקבצים שייווצרו.

דוגמה לשימוש בפונקציה זו ניתן לראות ב- seventh.cc קוד שתואר לעיל
שבו נעשה בו שימוש באופן הבא:

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

אחר דוגמאות
שלח עוֹזֵר דוגמה
דוגמה קצת יותר פשוטה מה seventh.cc ניתן למצוא דוגמה ב
src/stats/examples/file-helper-example.cc. דוגמה זו משתמשת רק ב- FileHelper.

קובץ הטקסט הבא עם 2 עמודות של ערכים מעוצבים בשם file-helper-example.txt
נוצר באמצעות הדוגמה. רק 10 השורות הראשונות של קובץ זה מוצגות כאן עבור
קוֹצֶר.

זמן (שניות) = 0.203 ספירה = 1
זמן (שניות) = 0.702 ספירה = 2
זמן (שניות) = 1.404 ספירה = 3
זמן (שניות) = 2.368 ספירה = 4
זמן (שניות) = 3.364 ספירה = 5
זמן (שניות) = 3.579 ספירה = 6
זמן (שניות) = 5.873 ספירה = 7
זמן (שניות) = 6.410 ספירה = 8
זמן (שניות) = 6.472 ספירה = 9
...

בדוגמה זו, יש אובייקט פולט שמגדיל את המונה שלו לפי א
Poisson מעבד ולאחר מכן פולט את הערך של המונה כמקור עקבות.

Ptr emitter = CreateObject ();
שמות::Add ("/שמות/פולט", פולט);

שים לב שבגלל שאין תווים כלליים בנתיב המשמש למטה, רק קובץ טקסט אחד היה
נוצר. קובץ הטקסט היחיד הזה נקרא בפשטות "file-helper-example.txt", ללא תוספת
סיומות כמו שהיית רואה אם ​​היו תווים כלליים בנתיב.

// צור את עוזר הקובץ.
FileHelper fileHelper;

// הגדר את הקובץ שייכתב.
fileHelper.ConfigureFile ("קובץ-helper-example",
FileAggregator::FORMATTED);

// הגדר את התוויות עבור קובץ הפלט המעוצב הזה.
fileHelper.Set2dFormat ("זמן (שניות) = %.3e\tCount = %.0f");

// כתוב את הערכים שנוצרו על ידי הבדיקה. הדרך שאנו
// לספק עוזר לבלבל את מקור העקבות.
fileHelper.WriteProbe ("ns3::Uinteger32Probe",
"/שמות/פולט/מונה",
"תְפוּקָה");

היקף ו מגבלות
נכון לעכשיו, רק בדיקות אלה יושמו וחוברו ל-GnuplotHelper ו
ל-FileHelper:

· BooleanProbe

· DoubleProbe

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TimeProbe

· PacketProbe

· ApplicationPacketProbe

· Ipv4PacketProbe

בדיקות אלו, לפיכך, הן ה-TypeIds היחידות הזמינות לשימוש בהן PlotProbe() ו
WriteProbe().

בחלקים הבאים, אנו מכסים כל אחד מסוגי האובייקטים הבסיסיים (Probe, Collector,
ו-Aggregator) ביתר פירוט, ולהראות כיצד ניתן לחבר אותם יחד באמצעות
API ברמה נמוכה יותר.

בדיקות
סעיף זה מפרט את הפונקציונליות שמספקת מחלקת ה-Probe ל- an ns-3
סימולציה, ונותן דוגמאות כיצד לקודד אותם בתוכנית. הסעיף הזה מיועד ל
משתמשים המעוניינים לפתח סימולציות עם ns-3 כלים ושימוש בנתונים
Collection Framework, שמחלקת Probe היא חלק ממנה, להפקת פלט נתונים איתה
תוצאות הסימולציה שלהם.

בדיקה סקירה כללית
אובייקט Probe אמור להיות מחובר למשתנה מהסימולציה שהערכים שלו
לאורך הניסוי רלוונטיים למשתמש. הגשש יתעד את מה שהיו
ערכים הנלקחים על ידי המשתנה לאורך הסימולציה ומעבירים נתונים כאלה לאחר
חבר במסגרת איסוף הנתונים. אמנם זה מחוץ לתחום של סעיף זה
לדון במה שקורה לאחר שה-Probe מייצר את הפלט שלו, מספיק לומר זאת, על ידי
בסוף הסימולציה, למשתמש יהיה מידע מפורט על הערכים שהיו
מאוחסן בתוך המשתנה הנבדק במהלך הסימולציה.

בדרך כלל, Probe מחובר ל- ns-3 מקור עקבות. באופן זה, בכל פעם שה
מקור המעקב מייצא ערך חדש, ה-Probe צורך את הערך (ומייצא אותו במורד הזרם
לאובייקט אחר דרך מקור עקבות משלו).

ניתן לחשוב על ה-Probe כסוג של מסנן על מקורות עקבות. הסיבות העיקריות ל
חיבור אולי ל-Probe ולא ישירות למקור עקבות הם כדלקמן:

· בדיקות עשויות להיות מופעלות וכיבויות באופן דינמי במהלך הסימולציה עם שיחות אל לְאַפשֵׁר()
ו השבת(). לדוגמה, הפלט של נתונים עשוי להיות מושבת במהלך
שלב חימום סימולציה.

· בדיקות עשויות לבצע פעולות על הנתונים כדי לחלץ ערכים מסובכים יותר
מבנים; למשל, הפלט של ערך גודל החבילה מ-ns3::Packet שהתקבל.

· בדיקות רושמות שם במרחב השמות ns3::Config (באמצעות שמות::הוסף ()) כך שהאחר
חפצים עשויים להתייחס אליהם.

· Probes מספקים שיטה סטטית המאפשרת לבצע מניפולציות של Probe לפי שם, כגון
מה נעשה ב-ns2measure [Cic06]

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

המקבילה ל-ns-3 של קוד ns2measure לעיל היא, למשל

DoubleProbe::SetValueByPath ("/path/to/probe", דוגמה);

בריאה
שים לב שלא ניתן ליצור אובייקט של מחלקת בסיס Probe מכיוון שהוא בסיס מופשט
class, כלומר יש לו פונקציות וירטואליות טהורות שלא יושמו. חפץ של
סוג DoubleProbe, שהיא תת מחלקה של מחלקת Probe, תיווצר כאן כדי להראות
מה שצריך להיעשות.

אחד מכריז על DoubleProbe בזיכרון דינמי באמצעות מחלקת המצביע החכם (Ptr ). ל
ליצור DoubleProbe בזיכרון דינמי עם מצביעים חכמים, צריך רק לקרוא ל-
ns-3 שיטה CreateObject ():

Ptr myprobe = CreateObject ();

ההצהרה שלמעלה יוצרת DoubleProbes באמצעות ערכי ברירת המחדל עבור התכונות שלו.
ישנן ארבע תכונות במחלקה DoubleProbe; שניים באובייקט המחלקה הבסיסית
DataCollectionObject, ושניים במחלקת הבסיס של Probe:

· "שם" (DataCollectionObject), StringValue

· "מופעל" (DataCollectionObject), ערך BooleanValue

· "התחל" (בדיקה), ערך זמן

· "עצור" (בדיקה), ערך זמן

אפשר להגדיר תכונות כאלה ביצירת אובייקט באמצעות השיטה הבאה:

Ptr myprobe = CreateObjectWithAttributes (
"שם", StringValue ("myprobe"),
"מופעל", BooleanValue (שקר),
"התחל", TimeValue (שניות (100.0)),
"עצור", TimeValue (שניות (1000.0)));

התחלה ועצירה הם משתני זמן שקובעים את מרווח הפעולה של ה-Probe. ה
בדיקה תוציא נתונים רק אם הזמן הנוכחי של הסימולציה נמצא בתוך זה
הַפסָקָה. ערך הזמן המיוחד של 0 שניות עבור עצור ישבית תכונה זו (כלומר
השאר את ה-Probe מופעל במשך כל הסימולציה). מופעל הוא דגל שמפעיל את ה-Probe או
כבוי, וחייב להיות מוגדר כ-true כדי שה-Probe ייצא נתונים. השם הוא שם האובייקט
במסגרת DCF.

יבוא ו ייצוא נתונים
ns-3 מקורות מעקב מוקלדים היטב, כך שהמנגנונים לחיבור בדיקות לעקבות
מקור ולייצוא נתונים שייכים לתתי המחלקות שלו. למשל, ברירת המחדל
הפצה של ns-3 מספק DoubleProbe בכיתה שנועד להתחבר לעקבות
מקור מייצא ערך כפול. בהמשך נפרט את פעולת ה-DoubleProbe, ו
לאחר מכן דנו כיצד מחלקות Probe אחרות עשויות להיות מוגדרות על ידי המשתמש.

DoubleProbe סקירה כללית
ה-DoubleProbe מתחבר לבעל ערך כפול ns-3 מקור עקבות, ובעצמו מייצא א
שונה בעל ערך כפול ns-3 מקור עקבות.

הקוד הבא, שאוב מ src/stats/examples/double-probe-example.cc, מציג את הבסיס
פעולות של אינסטלציה של ה-DoubleProbe לסימולציה, שבה היא בודקת מונה
מיוצא על ידי אובייקט פולט (מחלקה Emitter).

Ptr emitter = CreateObject ();
שמות::Add ("/שמות/פולט", פולט);
...

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");

// עלינו להוסיף אותו למסד הנתונים של התצורה
שמות::Add ("/Names/Probes", probe3->GetName (), probe3);

הפונקציה Count() של הפולט יכולה כעת להגדיר את הערך עבור DoubleProbe זה כ
התעופה

לבטל את
פולט::ספירה (בטל)
{
...
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
...
}

הדוגמה שלמעלה מראה כיצד הקוד הקורא ל-Probe לא חייב להיות מפורש
התייחסות ל-Probe, אבל יכול לכוון את הגדרת הערך דרך מרחב השמות Config.
זה דומה בפונקציונליות ל- Stat::Put שיטה שהוצגה על ידי נייר ns2measure
[Cic06], ומאפשר למשתמשים להוסיף באופן זמני הצהרות בדיקה כמו הדפס הצהרות
בתוך הקיים ns-3 דגמים. שימו לב שכדי להיות מסוגל להשתמש ב-DoubleProbe בזה
דוגמה כזו, 2 דברים היו נחוצים:

1. קובץ הכותרת של מודול הנתונים הסטטיסטיים נכלל בקובץ ה-cc לדוגמה

2. הדוגמה נעשתה תלויה במודול הנתונים הסטטיסטיים בקובץ ה-wscript שלו.

יש לעשות דברים אנלוגיים על מנת להוסיף Probes אחרים במקומות אחרים ב- ns-3
בסיס קוד.

ניתן להגדיר את הערכים עבור DoubleProbe גם באמצעות הפונקציה DoubleProbe::SetValue(),
בעוד שניתן לקבל את הערכים עבור DoubleProbe באמצעות הפונקציה
DoubleProbe::GetValue().

ה-DoubleProbe מייצא ערכים כפולים במקור העקיבה "פלט" שלו; אובייקט במורד הזרם
יכול לחבר כיור עקבות (NotifyViaProbe) לזה באופן הבא:

מחובר = probe1->TraceConnect ("פלט", probe1->GetName (), MakeCallback (&NotifyViaProbe));

אחר בדיקות
מלבד ה-DoubleProbe, הבדיקות הבאות זמינות גם:

· Uinteger8Probe מתחבר ל- ns-3 מקור מעקב מייצא uint8_t.

· Uinteger16Probe מתחבר ל- ns-3 מקור מעקב מייצא uint16_t.

· Uinteger32Probe מתחבר ל- ns-3 מקור מעקב מייצא uint32_t.

· PacketProbe מתחבר ל- ns-3 מקור מעקב מייצא חבילה.

· ApplicationPacketProbe מתחבר ל- ns-3 מקור מעקב מייצא חבילה ושקע
כתובת.

· Ipv4PacketProbe מתחבר ל- ns-3 מקור מעקב מייצא מנה, אובייקט IPv4 ו
ממשק.

יוצרים חדש בדיקה סוגים
כדי ליצור סוג בדיקה חדש, עליך לבצע את השלבים הבאים:

· ודא שמחלקת ה-Probe החדשה שלך נגזרת ממחלקת הבסיס של ה-Probe.

· ודא שהפונקציות הווירטואליות הטהורות שמחלקת ה-Probe החדשה שלך יורשת מה-
מחלקות בסיס בדיקה מיושמות.

· מצא מחלקת Probe קיימת שמשתמשת במקור עקבות הקרוב ביותר בסוג ל-
סוג מקור העקיבה שה-Probe שלך ​​ישתמש.

· העתק את קובץ ה-header (.h) וקובץ היישום (.cc) של מחלקת Probe הקיימת לשניים
קבצים חדשים עם שמות התואמים את ה-Probe החדש שלך.

· החלף את הסוגים, הארגומנטים והמשתנים בקבצים המועתקים במתאימים
הקלד עבור ה-Probe שלך.

· בצע את השינויים הדרושים כדי לגרום לקוד להדר ולגרום לו להתנהג כפי שהיית מתנהג
כמו.

דוגמאות
שתי דוגמאות יידונו בפירוט כאן:

· דוגמה לבדיקה כפולה

· דוגמה ל-IPv4 Packet Plot

זוגי בדיקה דוגמה
דוגמת הבדיקה הכפולה נדונה בעבר. ניתן למצוא את התוכנית לדוגמה
in src/stats/examples/double-probe-example.cc. לסיכום מה קורה בתוכנית זו,
יש פולט שמייצא מונה שמתגבר לפי תהליך פואסון.
בפרט, מוצגות שתי דרכים לפליטת נתונים:

1. דרך משתנה עקבות המחובר לבדיקה אחת:

TracedValue m_counter; // בדרך כלל זה יהיה סוג מספר שלם

2. דרך מונה שערכו נשלח ל-Probe שני, שמוזכר בשמו ב
מערכת התצורה:

לבטל את
פולט::ספירה (בטל)
{
NS_LOG_FUNCTION (זה);
NS_LOG_DEBUG ("סופר ב" << Simulator::Now ().GetSeconds ());
m_counter += 1.0;
DoubleProbe::SetValueByPath ("/Names/StaticallyAccessedProbe", m_counter);
Simulator::Schedule (שניות (m_var->GetValue ()), &Emitter::Count, this);
}

בואו נסתכל על ה-Probe ביתר שאת. בדיקות יכולות לקבל את הערכים שלהם בכפולה
דרכים:

1. על ידי הגשת ה-Probe ישירות למקור העקבות וחיבור אליו כיור מעקב

2. על ידי ה-Probe גישה למקור המעקב דרך מרחב השמות של התצורה וחיבור א
לשקוע אליו

3. על ידי קוד הקריאה הקורא במפורש ל-Probe's הגדר ערך() שיטה

4. על ידי קוד קורא מפורש קורא SetValueByPath
("/path/through/Config/namespace", ...)

שתי הטכניקות הראשונות צפויות להיות הנפוצות ביותר. גם בדוגמה, ה
חיבור של פונקציית התקשרות חוזרת רגילה מוצג, כפי שנעשה בדרך כלל ב ns-3. זֶה
פונקציית התקשרות חוזרת אינה משויכת לאובייקט Probe. נכנה את המקרה הזה 0) להלן.

// זוהי פונקציה לבדיקת חיבור פונקציה גולמית למקור המעקב
לבטל את
NotifyViaTraceSource (std::string context, double oldVal, double newVal)
{
NS_LOG_DEBUG ("הקשר: " << הקשר << " ישן " << oldVal << " new " << newVal);
}

ראשית, יש להגדיר את הפולט:

Ptr emitter = CreateObject ();
שמות::Add ("/שמות/פולט", פולט);

// האובייקט Emitter אינו משויך לצומת ns-3, אז
// זה לא יתחיל אוטומטית, אז אנחנו צריכים לעשות זאת בעצמנו
סימולטור::לוח זמנים (שניות (0.0), &פולט::התחל, פולט);

ה-DoubleProbes השונים מקיימים אינטראקציה עם הפולט בדוגמה כפי שמוצג להלן.

מקרה 0):

// להלן מראה פונקציונליות טיפוסית ללא בדיקה
// (חבר פונקציית כיור למקור עקבות)
//
מחובר = emitter->TraceConnect ("מונה", "הקשר לדוגמה", MakeCallback (&NotifyViaTraceSource));
NS_ASSERT_MSG (מחובר, "מקור מעקב לא מחובר");

תיק 1):

//
// Probe1 יתחבר ישירות לאובייקט מקור המעקב של Emitter
//

// probe1 יתחבר למקור המעקב של פולט
Ptr probe1 = CreateObject ();
// שם הגשוש יכול לשמש כהקשר שלו במעקב
probe1->SetName ("ObjectProbe");

// חבר את הגשושית למונה של הפולט
מחובר = probe1->ConnectByObject ("מונה", פולט);
NS_ASSERT_MSG (מחובר, "מקור מעקב לא מחובר לבדיקה1");

תיק 2):

//
// Probe2 יתחבר לאובייקט מקור המעקב של Emitter על ידי
// גישה אליו לפי שם נתיב במסד הנתונים של Config
//

// צור בדיקה דומה נוספת; זה יתחבר דרך נתיב Config
Ptr probe2 = CreateObject ();
probe2->SetName ("PathProbe");

// הערה, לא מסומן ערך החזרה כאן
probe2->ConnectByPath ("/Names/Emitter/Counter");

מקרה 4) (מקרה 3 אינו מוצג בדוגמה זו):

//
// Probe3 ייקרא על ידי הפולט ישירות דרך
// שיטה סטטית SetValueByPath().
//
Ptr probe3 = CreateObject ();
probe3->SetName ("StaticallyAccessedProbe");
// עלינו להוסיף אותו למסד הנתונים של התצורה
שמות::Add ("/Names/Probes", probe3->GetName (), probe3);

ולבסוף, הדוגמה מראה כיצד ניתן לחבר את הבדיקות כדי ליצור פלט:

// הבדיקה עצמה אמורה ליצור פלט. ההקשר שאנו מספקים
// לבדיקה זו (במקרה זה, שם הבדיקה) יעזור לבלבל
// מקור העקבות
מחובר = probe3->TraceConnect ("פלט",
"/Names/Probes/StaticallyAccessedProbe/Output",
MakeCallback (&NotifyViaProbe));
NS_ASSERT_MSG (מחובר, "מקור מעקב לא .. מחובר לפלט probe3");

ההתקשרות חזרה הבאה מחוברת ל-Probe בדוגמה זו למטרות המחשה;
בדרך כלל, הגשושית תהיה מחוברת לחפץ אספן.

// זוהי פונקציה לבדיקת חיבורו לפלט הבדיקה
לבטל את
NotifyViaProbe (std::string context, double oldVal, double newVal)
{
NS_LOG_DEBUG ("הקשר: " << הקשר << " ישן " << oldVal << " new " << newVal);
}

IPv4 מנה מגרש דוגמה
דוגמה עלילת מנות IPv4 מבוססת על הדוגמה fifth.cc מה- ns-3 הדרכה. זה
ניתן למצוא src/stats/examples/ipv4-packet-plot-example.cc.

צומת 0 צומת 1
+----------------+ +----------------+
| ns-3 TCP | | ns-3 TCP |
+----------------+ +----------------+
| 10.1.1.1 | | 10.1.1.2 |
+----------------+ +----------------+
| נקודה לנקודה | | נקודה לנקודה |
+----------------+ +----------------+
| |
+----------------------------+

רק נסתכל על ה-Probe, מכיוון שהוא ממחיש ש-Probes עשוי גם לפרוק ערכים ממנו
מבנים (במקרה זה, מנות) ומדווחים על ערכים אלה בתור פלטי מקור מעקב, במקום זאת
מאשר רק לעבור דרך אותו סוג של נתונים.

ישנם היבטים נוספים של דוגמה זו שיוסברו בהמשך התיעוד.
שני סוגי הנתונים המיוצאים הם החבילה עצמה (תְפוּקָה) וספירה של ה
מספר בתים בחבילה (OutputBytes).

TypeId
Ipv4PacketProbe::GetTypeId ()
{
static TypeId tid = TypeId ("ns3::Ipv4PacketProbe")
.SetParent ()
.AddConstructor ()
‎.AddTraceSource ("פלט",
"החבילה בתוספת אובייקט ה-IPv4 והממשק שלה המשמשים כפלט עבור בדיקה זו",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_output))
.AddTraceSource ( "OutputBytes",
"מספר הבתים בחבילה",
MakeTraceSourceAccessor (&Ipv4PacketProbe::m_outputBytes))
;
לחזור tid;
}

כאשר כיור המעקב של ה-Probe מקבל חבילה, אם ה-Probe מופעל, הוא יוציא פלט
החבילה שעליה תְפוּקָה מקור מעקב, אבל הוא גם יוציא את מספר הבתים ב-
OutputBytes מקור עקבות.

לבטל את
Ipv4PacketProbe::TraceSink (Ptr חבילה, Ptr ממשק ipv4, uint4_t)
{
NS_LOG_FUNCTION (ממשק << זה << ipv4 <<);
if (IsEnabled ())
{
m_packet = 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, אספנים עדיין בפיתוח ועדיין לא מסופקים כחלק
של המסגרת.

צוברים
סעיף זה מפרט את הפונקציונליות שמספקת מחלקה Aggregator ל- an ns-3
סימולציה. חלק זה מיועד למשתמשים המעוניינים לפתח סימולציות עם
ns-3 כלים ושימוש ב-Data Collection Framework, אשר מחלקה Aggregator היא א
חלק, כדי ליצור פלט נתונים עם תוצאות הסימולציה שלהם.

צבר סקירה כללית
אובייקט Aggregator אמור להיות מחובר למקור עקבות אחד או יותר כדי לעשות זאת
לקבל קלט. אגרגטורים הם נקודת הסיום של הנתונים שנאספו על ידי הרשת של
בדיקות ואספנים במהלך הסימולציה. תפקידו של האגרגטור לקחת את אלה
ערכים והפיכתם לפורמט הפלט הסופי שלהם כגון קבצי טקסט רגיל,
קבצי גיליונות אלקטרוניים, עלילות או מסדי נתונים.

בדרך כלל, אגרגטור מחובר לאספנים אחד או יותר. באופן הזה, בכל פעם
מקורות המעקב של האספנים מייצאים ערכים חדשים, האגרגטור יכול לעבד את הערך כך
שניתן להשתמש בו בפורמט הפלט הסופי שבו ערכי הנתונים יתגוררו לאחר ה-
סימולציה.

שימו לב לדברים הבאים לגבי אגרגטורים:

· ניתן להפעיל ולכבות אגרגטורים באופן דינמי במהלך הסימולציה עם שיחות אל
לְאַפשֵׁר() ו השבת(). לדוגמה, צבירת הנתונים עשויה להיות מושבתת במהלך
שלב החימום של הסימולציה, כלומר הערכים האלה לא ייכללו בגמר
מדיום פלט.

· אגרגטורים מקבלים נתונים מאספנים באמצעות התקשרויות חוזרות. כאשר אספן משויך
ל-Aggregator מתבצעת קריאה ל-TraceConnect כדי לבסס את העקבות של Aggregator
שיטת sink כהתקשרות חוזרת.

עד כה, שני אגרגטורים יושמו:

· GnuplotAggregator

· FileAggregator

GnuplotAggregator
ה-GnuplotAggregator מייצר קבצי פלט המשמשים ליצירת גנופלוטים.

ה-GnuplotAggregator יצור 3 קבצים שונים בסוף הסימולציה:

· קובץ נתוני gnuplot מופרדים מרווחים

· קובץ בקרת גנופלוט

· סקריפט מעטפת ליצירת הגנופלוט

בריאה
אובייקט מסוג GnuplotAggregator ייווצר כאן כדי להראות מה צריך לעשות.

אחד מכריז על GnuplotAggregator בזיכרון דינמי על ידי שימוש במחלקת המצביע החכם
(Ptr ). כדי ליצור GnuplotAggregator בזיכרון דינמי עם מצביעים חכמים, אחד פשוט
צריך להתקשר ל ns-3 שיטה CreateObject (). הקוד הבא מ
src/stats/examples/gnuplot-aggregator-example.cc מראה כיצד לעשות זאת:

string fileNameWithoutExtension = "gnuplot-aggregator";

// צור אגרגטור.
Ptr אגרגטור =
CreateObject (שם קובץWithoutExtension);

הארגומנט הראשון עבור הבנאי, fileNameWithoutExtension, הוא השם של
קבצים הקשורים ל-gnuplot לכתיבה ללא סיומת. GnuplotAggregator זה יצור א
קובץ נתוני gnuplot המופרדים מרווח בשם "gnuplot-aggregator.dat", קובץ בקרת gnuplot
בשם "gnuplot-aggregator.plt", וסקריפט מעטפת ליצירת הגנופלוט בשם +
"gnuplot-aggregator.sh".

הגנופלוט שנוצר יכול לקבל את המפתח שלו ב-4 מיקומים שונים:

· אין מפתח

· מפתח בתוך העלילה (ברירת המחדל)

· מפתח מעל העלילה

· מפתח מתחת לעלילה

ערכי ה-enum של מיקום מפתח הגנופלוט הבאים רשאים לציין את מיקום המפתח:

enum KeyLocation {
אין מפתח,
KEY_INSIDE,
KEY_ABOVE,
KEY_BELOW
};

אם היה רצוי שהמפתח יהיה למטה ולא את מיקום ברירת המחדל של בפנים, אז
תוכל לעשות את הדבר הבא.

aggregator->SetKeyLocation(GnuplotAggregator::KEY_BELOW);

דוגמאות
דוגמה אחת תידון בהרחבה כאן:

· דוגמה ל-Gnuplot Aggregator

גנופלוט צבר דוגמה
ניתן למצוא דוגמה שמתרגלת את GnuplotAggregator
src/stats/examples/gnuplot-aggregator-example.cc.

הגנופלוט הדו-ממדי הבא נוצר באמצעות הדוגמה.
[תמונה] 2-D Gnuplot נוצר על ידי gnuplot-aggregator-example.cc דוגמה..UNINDENT

קוד זה מהדוגמה מראה כיצד לבנות את GnuplotAggregator כפי שנדון
מֵעַל.

void Create2dPlot ()
{
שימוש במרחב השמות std;

string fileNameWithoutExtension = "gnuplot-aggregator";
string plotTitle = "עלילת אגרגטור גנופלוט";
string plotXAxisHeading = "זמן (שניות)";
string plotYAxisHeading = "ערכים כפולים";
string plotDatasetLabel = "ערכי נתונים";
string datasetContext = "מערך נתונים/הקשר/מחרוזת";

// צור אגרגטור.
Ptr אגרגטור =
CreateObject (שם קובץWithoutExtension);

תכונות GnuplotAggregator שונות מוגדרות כולל מערך הנתונים הדו-ממדי שיהיה
זוממה.

// הגדר את המאפיינים של הצבר.
aggregator->SetTerminal ("png");
aggregator->SetTitle (plotTitle);
aggregator->SetLegend (plotXAxisHeading, plotYAxisHeading);

// הוסף מערך נתונים לצבר.
aggregator->Add2dDataset (datasetContext, plotDatasetLabel);

// אגרגטור חייב להיות מופעל
אגרגטור->אפשר ();

לאחר מכן, הערכים הדו-ממדיים מחושבים, וכל אחד מהם נכתב בנפרד ל-
GnuplotAggregator באמצעות Write2d() פונקציה.

זמן כפול;
ערך כפול;

// צור את מערך הנתונים הדו-ממדי.
עבור (זמן = -5.0; זמן <= +5.0; זמן += 1.0)
{
// חשב את העקומה הדו-ממדית
//
// 2
// ערך = זמן .
//
ערך = זמן * זמן;

// הוסף את הנקודה הזו לעלילה.
aggregator->Write2d (datasetContext, זמן, ערך);
}

// השבת רישום נתונים עבור האגרגטור.
אגרגטור->השבת ();
}

File Aggregator
ה-FileAggregator שולח את הערכים שהוא מקבל לקובץ.

ה-FileAggregator יכול ליצור 4 סוגים שונים של קבצים:

· מעוצב

· רווח מופרד (ברירת המחדל)

· מופרד באמצעות פסיקים

· כרטיסיות מופרדות

קבצים מעוצבים משתמשים במחרוזות פורמט בסגנון C ובפונקציה sprintf() כדי להדפיס אותם
ערכים בקובץ הנכתב.

בריאה
אובייקט מסוג FileAggregator ייווצר כאן כדי להראות מה צריך לעשות.

אחד מכריז על FileAggregator בזיכרון דינמי באמצעות מחלקת המצביע החכם (Ptr ).
כדי ליצור FileAggregator בזיכרון דינמי עם מצביעים חכמים, צריך רק להתקשר
מה היא ns-3 שיטה CreateObject. הקוד הבא מ
src/stats/examples/file-aggregator-example.cc מראה כיצד לעשות זאת:

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

// צור אגרגטור שיהיו לו ערכים מעוצבים.
Ptr אגרגטור =
CreateObject (שם קובץ, FileAggregator::FORMATTED);

הארגומנט הראשון של הבנאי, שם הקובץ, הוא שם הקובץ לכתיבה; ה
ארגומנט שני, fileType, הוא סוג הקובץ לכתיבה. FileAggregator זה יצור א
קובץ בשם "file-aggregator-formatted-values.txt" עם הערכים שלו מודפסים כפי שצוין על ידי
fileType, כלומר, מעוצב במקרה זה.

ערכי ה-enum של סוג הקובץ הבאים מותרים:

enum FileType {
מעוצב,
SPACE_SEPARATED,
מופרד באמצעות פסיקים,
TAB_SPARATED
};

דוגמאות
דוגמה אחת תידון בהרחבה כאן:

· דוגמה לקובץ אגרגטור

שלח צבר דוגמה
דוגמה להפעלת FileAggregator ניתן למצוא ב
src/stats/examples/file-aggregator-example.cc.

קובץ הטקסט הבא עם 2 עמודות של ערכים מופרדות בפסיקים נוצר באמצעות ה-
דוגמא.

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

קוד זה מהדוגמה מראה כיצד לבנות את FileAggregator כפי שנדון
מֵעַל.

void CreateCommaSeparatedFile ()
{
שימוש במרחב השמות std;

string fileName = "file-aggregator-comma-separated.txt";
string datasetContext = "מערך נתונים/הקשר/מחרוזת";

// צור אגרגטור.
Ptr אגרגטור =
CreateObject (שם קובץ, FileAggregator::COMMA_SEPARATED);

תכונות FileAggregator מוגדרות.

// אגרגטור חייב להיות מופעל
אגרגטור->אפשר ();

לאחר מכן, הערכים הדו-ממדיים מחושבים, וכל אחד מהם נכתב בנפרד ל-
FileAggregator באמצעות ה Write2d() פונקציה.

זמן כפול;
ערך כפול;

// צור את מערך הנתונים הדו-ממדי.
עבור (זמן = -5.0; זמן <= +5.0; זמן += 1.0)
{
// חשב את העקומה הדו-ממדית
//
// 2
// ערך = זמן .
//
ערך = זמן * זמן;

// הוסף את הנקודה הזו לעלילה.
aggregator->Write2d (datasetContext, זמן, ערך);
}

// השבת רישום נתונים עבור האגרגטור.
אגרגטור->השבת ();
}

קובץ הטקסט הבא עם 2 עמודות של ערכים מעוצבים נוצר גם באמצעות ה-
דוגמא.

זמן = -5.000e+00 ערך = 25
זמן = -4.000e+00 ערך = 16
זמן = -3.000e+00 ערך = 9
זמן = -2.000e+00 ערך = 4
זמן = -1.000e+00 ערך = 1
זמן = 0.000e+00 ערך = 0
זמן = 1.000e+00 ערך = 1
זמן = 2.000e+00 ערך = 4
זמן = 3.000e+00 ערך = 9
זמן = 4.000e+00 ערך = 16
זמן = 5.000e+00 ערך = 25

קוד זה מהדוגמה מראה כיצד לבנות את FileAggregator כפי שנדון
מֵעַל.

void CreateFormattedFile ()
{
שימוש במרחב השמות std;

string fileName = "file-aggregator-formatted-values.txt";
string datasetContext = "מערך נתונים/הקשר/מחרוזת";

// צור אגרגטור שיהיו לו ערכים מעוצבים.
Ptr אגרגטור =
CreateObject (שם קובץ, FileAggregator::FORMATTED);

תכונות FileAggregator מוגדרות, כולל מחרוזת הפורמט בסגנון C לשימוש.

// הגדר את הפורמט של הערכים.
aggregator->Set2dFormat ("זמן = %.3e\tValue = %.0f");

// אגרגטור חייב להיות מופעל
אגרגטור->אפשר ();

לאחר מכן, הערכים הדו-ממדיים מחושבים, וכל אחד מהם נכתב בנפרד ל-
FileAggregator באמצעות ה Write2d() פונקציה.

זמן כפול;
ערך כפול;

// צור את מערך הנתונים הדו-ממדי.
עבור (זמן = -5.0; זמן <= +5.0; זמן += 1.0)
{
// חשב את העקומה הדו-ממדית
//
// 2
// ערך = זמן .
//
ערך = זמן * זמן;

// הוסף את הנקודה הזו לעלילה.
aggregator->Write2d (datasetContext, זמן, ערך);
}

// השבת רישום נתונים עבור האגרגטור.
אגרגטור->השבת ();
}

מתאמים
סעיף זה מפרט את הפונקציונליות שמספקת מחלקת המתאם ל- an ns-3
סימולציה. חלק זה מיועד למשתמשים המעוניינים לפתח סימולציות עם
ns-3 כלים ושימוש במסגרת איסוף הנתונים, שמחלקת המתאם היא חלק ממנה,
ליצור פלט נתונים עם תוצאות הסימולציה שלהם.

הערה: המונח 'מתאם' עשוי להיות מאויית גם 'מתאם'; בחרנו באיות מיושר
עם תקן C++.

מתאם סקירה כללית
מתאם משמש ליצירת חיבורים בין סוגים שונים של אובייקטי DCF.

עד כה, מתאם אחד יושם:

· TimeSeriesAdaptor

זְמַן סדרה מתאם
ה-TimeSeriesAdaptor מאפשר ל-Probes להתחבר ישירות ל-Aggregators ללא צורך
אספן בין לבין.

שני עוזרי DCF המיושמים משתמשים ב-TimeSeriesAdaptors כדי לבצע בדיקה
ערכים מסוגים שונים ופלט את הזמן הנוכחי בתוספת הערך עם שניהם מומרים
לכפילים.

תפקידה של מחלקת TimeSeriesAdaptor הוא של מתאם, שלוקח ערך גולמי
בדיקה של נתוני בדיקה מסוגים שונים ומוציאה טופלה של שני ערכים כפולים. הראשון הוא א
חותמת זמן, אשר עשויה להיות מוגדרת ברזולוציות שונות (למשל שניות, אלפיות שניות וכו') ב
העתיד אך מקודד כעת ל-Seconds. השני הוא ההמרה של א
ערך לא כפול לערך כפול (אפשר עם אובדן דיוק).

היקף/הגבלות
סעיף זה דן בהיקף ובמגבלות של מסגרת איסוף הנתונים.

נכון לעכשיו, רק בדיקות אלה יושמו ב-DCF:

· BooleanProbe

· DoubleProbe

· Uinteger8Probe

· Uinteger16Probe

· Uinteger32Probe

· TimeProbe

· PacketProbe

· ApplicationPacketProbe

· Ipv4PacketProbe

נכון לעכשיו, אין אספנים זמינים ב-DCF, אם כי BasicStatsCollector נמצא תחת
פיתוח.

נכון לעכשיו, רק אגרגטורים אלה יושמו ב-DCF:

· GnuplotAggregator

· FileAggregator

נכון לעכשיו, רק המתאם הזה יושם ב-DCF:

מתאם סדרת זמן.

שלנו תיק עבודות
חלק זה דן בעבודה העתידית שתעשה על מסגרת איסוף הנתונים.

הנה כמה דברים שעדיין צריך לעשות:

· חבר מקורות עקבות נוספים ns-3 קוד כדי להוציא יותר ערכים מהסימולטור.

· ליישם יותר סוגים של Probes ממה שיש כיום.

· יישם יותר מסתם אספן הדו-ממד הנוכחי היחיד, BasicStatsCollector.

· הטמעת אגרגטורים נוספים.

· הטמע יותר מסתם מתאמים.

DSDV ניתוב

פרוטוקול ניתוב וקטור מרחק ברצף יעד (DSDV) הוא פרו-אקטיבי,
פרוטוקול ניתוב מונחה טבלה עבור MANETs שפותח על ידי צ'ארלס א. פרקינס ופרווין
Bhagwat בשנת 1994. הוא משתמש בספירת הקפות כמדד בבחירת המסלול.

מודל זה פותח על ידי מה היא ResiliNets מחקר קבוצה באוניברסיטת קנזס. א
נייר על דגם זה קיים ב זֶה כתובת האתר.

DSDV ניתוב סקירה כללית
טבלת ניתוב DSDV: כל צומת ישמור טבלה המפרטת את כל הצמתים האחרים שיש לו
ידוע ישירות או דרך כמה שכנים. לכל צומת יש כניסה בודדת ב-
טבלת ניתוב. הערך יכלול מידע על כתובת ה-IP של הצומת, הידועה לאחרונה
מספר רצף וספירת הקפיצות כדי להגיע לצומת זה. יחד עם הפרטים הללו הטבלה
גם עוקב אחר השכן Nexthop כדי להגיע לצומת היעד, חותמת הזמן של
העדכון האחרון שהתקבל עבור אותו צומת.

הודעת עדכון DSDV מורכבת משלושה שדות, כתובת יעד, מספר רצף ו
ספירת הופ.

כל צומת משתמש בשני מנגנונים כדי לשלוח את עדכוני ה-DSDV. הם,

1.

תְקוּפָתִי עדכונים
עדכונים תקופתיים נשלחים לאחר כל m_periodicUpdateInterval (ברירת מחדל: 15 שניות).
בעדכון זה הצומת משדר את כל טבלת הניתוב שלו.

2.

הדק עדכונים
עדכוני טריגר הם עדכונים קטנים בין העדכונים התקופתיים. העדכונים האלה
נשלחים בכל פעם שצומת מקבל חבילת DSDV שגרמה לשינוי שלה
טבלת ניתוב. העיתון המקורי לא ציין בבירור מתי לאיזה שינוי
בטבלה יש לשלוח עדכון DSDV. היישום הנוכחי שולח
להוציא עדכון ללא קשר לשינוי בטבלת הניתוב.

העדכונים מתקבלים על סמך המדד עבור צומת מסוים. הגורם הראשון
קביעת הקבלה של עדכון היא מספר הרצף. הוא חייב לקבל את העדכון
אם מספר הרצף של הודעת העדכון גבוה יותר ללא קשר למדד. אם ה
העדכון עם אותו מספר רצף מתקבל, ולאחר מכן העדכון עם המדד הכי פחות (hopCount)
ניתנת עדיפות.

בתרחישים ניידים מאוד, יש סיכוי גבוה לתנודות במסלול, ולכן יש לנו את
מושג של זמן יישוב משוקלל שבו לא יהיה עדכון עם שינוי במדד
מפורסם לשכנים. הצומת ממתין לזמן ההתיישבות כדי לוודא שלא
קבל את העדכון מהשכן הישן שלו לפני שליחת העדכון.

היישום הנוכחי מכסה את כל התכונות הנ"ל של DSDV. הנוכחי
למימוש יש גם תור בקשות לאגירת מנות שאין להן נתיבים אליהן
יַעַד. ברירת המחדל מוגדרת לאגירה של עד 5 מנות לכל יעד.

הפניות
קישור לעיתון: http://portal.acm.org/citation.cfm?doid=190314.190336

DSR ניתוב

פרוטוקול ניתוב מקור דינמי (DSR) הוא פרוטוקול ניתוב תגובתי שתוכנן במיוחד
לשימוש ברשתות אד-הוק אלחוטיות מרובות הופ של צמתים ניידים.

מודל זה פותח על ידי מה היא ResiliNets מחקר קבוצה באוניברסיטת קנזס.

DSR ניתוב סקירה כללית
מודל זה מיישם את מפרט הבסיס של פרוטוקול ניתוב מקור דינמי (DSR).
היישום מבוסס על RFC 4728, עם כמה הרחבות ושינויים ל-RFC
מפרטים.

DSR פועל לפי התנהגות לפי דרישה. לכן, מודל ה-DSR שלנו מאחסן את כל החבילות בזמן א
חבילת בקשת מסלול (RREQ) מופצת. אנו מיישמים מאגר מנות ב
dsr-rsendbuff.cc. תור החבילות מיישם איסוף אשפה של מנות ישנות וא
מגבלת גודל התור. כאשר החבילה נשלחת ממאגר השליחה, היא תוצב בתור
חיץ תחזוקה לאישור הדילוג הבא.

לאחר מכן מאגר התחזוקה מאחסן את החבילות שכבר נשלחו וממתין ל-
הודעה על משלוח מנות. פעולת הפרוטוקול תלויה מאוד בקישור שבור
מנגנון זיהוי. אנו מיישמים את שלוש ההיוריסטיקות המומלצות על בסיס ה-RFC as
התעופה

ראשית, אנו משתמשים במשוב שכבת קישור כשאפשר, שהוא גם המנגנון המהיר ביותר של
שלושת אלה כדי לזהות שגיאות קישור. קישור נחשב כשבור אם העברת מסגרת
גורם לכישלון שידור עבור כל הניסיונות החוזרים. מנגנון זה מיועד לפעיל
קישור ועובד הרבה יותר מהר מאשר בהיעדרו. DSR מסוגל לזהות את שכבת הקישור
כשל בשידור והודיע ​​על כך שהוא מקולקל. חישוב מחדש של מסלולים יופעל
במקרה הצורך. אם המשתמש אינו רוצה להשתמש באישור שכבת קישור, ניתן לכוון אותו על ידי
הגדרת התכונה "LinkAcknowledgement" ל-false ב-"dsr-routing.cc".

שנית, יש להשתמש בהכרה פסיבית במידת האפשר. הצומת נדלק
מצב קבלה "מופקר", בו הוא יכול לקבל מנות שלא מיועדות לעצמו, ו
כאשר הצומת מבטיח את מסירת חבילת הנתונים הזו ליעדו, הוא מבטל את
טיימר אישור פסיבי.

לבסוף, אנו משתמשים בסכימת אישור שכבת רשת כדי להודיע ​​על קבלת חבילה. מַסלוּל
חבילת בקשה לא תאושר או תשודר מחדש.

היישום Route Cache תומך באיסוף אשפה של ערכים ישנים ומצב
מכונה, כהגדרתה בתקן. הוא מיישם כמיכל מפת STL. המפתח הוא ה
כתובת IP של יעד.

DSR פועלת עם גישה ישירה ל-IP header, ופועלת בין רשת לתחבורה
שִׁכבָה. כאשר החבילה נשלחת משכבת ​​התחבורה, היא עוברת את עצמה ל-DSR ו-DSR
הכותרת מצורפת.

יש לנו שני מנגנוני מטמון: מטמון נתיב ומטמון קישור. מטמון הנתיב שומר את כולו
נתיב במטמון. השבילים ממוינים על סמך ספירת הכשות, ובכל פעם שביל אחד
לא ניתן להשתמש בו, אנו משנים לנתיב הבא. מטמון הקישור מעט טוב יותר
עיצוב במובן שהוא משתמש בנתיבי משנה שונים ומשתמש ב-Implemented Link Cache באמצעות
אלגוריתם Dijsktra, והחלק הזה מיושם על ידי Song Luan[מוגן בדוא"ל]>.

אופטימיזציות הפרוטוקול האופציונליות הבאות אינן מיושמות:

· מצב זרימה

· דגלי הופ חיצוני ראשון (F), דגלים אחרונים הופ חיצוני (L).

· טיפול באפשרויות DSR לא ידועות

·

שני סוגים of שגיאה כותרות:

1. מצב זרימה לא נתמך אפשרות

2. אפשרות לא נתמכת (לא יקרה בסימולציה)

DSR עדכון in ns-3.17
במקור השתמשנו ב-"TxErrHeader" ב-Ptr כדי לציין את שגיאת השידור של א
חבילה ספציפית בשכבת הקישור, עם זאת, היא לא עבדה כהלכה מאז אפילו מתי
החבילה נשמטה, כותרת זו לא תועדה בקובץ המעקב. נהגנו א
נתיב שונה ביישום מנגנון ההתראה של שכבת הקישור. אנחנו מסתכלים לתוך
קובץ מעקב על ידי מציאת אירוע קבלת מנות. אם נמצא אירוע קבלה אחד עבור הנתונים
חבילה, אנו סופרים זאת כאינדיקטור לאספקת נתונים מוצלחת.

מוֹעִיל פרמטרים
+------------------------ +----------------------- --------------+--------------+
| פרמטר | תיאור | ברירת מחדל |
+==========================+===================== ===============+=============+
| MaxSendBuffLen | מספר מקסימלי של מנות שיכולות | 64 |
| | להיות מאוחסן במאגר השליחה | |
+------------------------ +----------------------- --------------+--------------+
| MaxSendBuffTime | מנות זמן מקסימליות ניתנות לתור | שניות(30) |
| | במאגר השליחה | |
+------------------------ +----------------------- --------------+--------------+
| MaxMaintLen | מספר מקסימלי של מנות שיכולות | 50 |
| | להיות מאוחסן במאגר תחזוקה | |
+------------------------ +----------------------- --------------+--------------+
| MaxMaintTime | מנות זמן מקסימליות ניתנות לתור | שניות(30) |
| | במאגר תחזוקה | |
+------------------------ +----------------------- --------------+--------------+
| MaxCacheLen | מספר מקסימלי של כניסות למסלול | 64 |
| | שניתן לאחסן במטמון המסלול | |
+------------------------ +----------------------- --------------+--------------+
| RouteCacheTimeout | הזמן המרבי שהמטמון של המסלול יכול | שניות(300) |
| | לעמוד בתור במטמון המסלול | |
+------------------------ +----------------------- --------------+--------------+
| RreqRetries | מספר מקסימלי של שידורים חוזרים | 16 |
| | לבקשת גילוי מסלול | |
+------------------------ +----------------------- --------------+--------------+
| CacheType | השתמש ב-Link Cache או השתמש ב-Path Cache | "LinkCache" |
| | | |
+------------------------ +----------------------- --------------+--------------+
| LinkAcknowledgement | אפשר אישור שכבת קישור | נכון |
| | מנגנון | |
+------------------------ +----------------------- --------------+--------------+

יישום שינוי
·

השמיים DsrFsHeader יש ל הוסיף 3 שדות: הודעה סוג, מָקוֹר מזהה יעד מזהה ו אלה
שינויים רק ל לאחר עיבוד

1. סוג ההודעה משמש לזיהוי חבילת הנתונים מחבילת הבקרה

2. מזהה מקור משמש לזיהוי המקור האמיתי של חבילת הנתונים שכן יש לנו
לספק את החבילה הופ-אחר-הופ וה-ipv4header אינו נושא את האמיתי
כתובת ה-IP של המקור והיעד לפי הצורך

3. מזהה היעד הוא מאותה סיבה לעיל

· כותרת התשובה של מסלול אינה מיושרת למילים ב-DSR RFC, שנה אותה ל-word-aligned in
הפעלה

· DSR עובד ככותרת shim בין פרוטוקול תחבורה ורשת, הוא צריך משלו
מנגנון העברה, אנו משנים את העברת המנות למסירה הופ-אחר-הופ, אז
הוספנו שני שדות בכותרת קבועה dsr כדי להודיע ​​על משלוח מנות

נוֹכְחִי מסלול סליק הפעלה
יישום זה השתמש ב-"path cache", שהוא פשוט ליישום ומבטיח לולאות
נתיבים:

· למטמון הנתיב יש מדיניות תפוגה אוטומטית

· המטמון שומר מספר ערכי מסלול עבור יעד מסוים וממיין את הערכים
מבוסס על ספירת הכשות

· ניתן לכוונן את MaxEntriesEachDst כדי לשנות את הערכים המקסימליים שנשמרו עבור יחיד
יעד

· כאשר מוסיפים מספר מסלולים ליעד אחד, המסלול מושווה על סמך
זמן ספירת הופ ותפוגה, זה עם פחות ספירת הופ או מסלול חדש יחסית
מועדף

· יישום עתידי עשוי לכלול "מטמון קישור" כאפשרות נוספת

DSR הוראות
יש לזכור את הדברים הבאים בעת הפעלת DSR כפרוטוקול ניתוב:

· NodeTraversalTime הוא הזמן שלוקח לעבור שני צמתים סמוכים וצריך להיות
נבחר כדי להתאים לטווח השידור

· PassiveAckTimeout הוא הזמן שבו חבילה במאגר תחזוקה ממתינה לפסיבית
אישור, בדרך כלל מוגדר כפעמיים של NodeTraversalTime

· יש להגדיר ערך קטן יותר של RouteCacheTimeout כאשר מהירות הצמתים נעשית גבוהה יותר.
ערך ברירת המחדל הוא 300 שניות.

עוֹזֵר
כדי להפעיל צומת DSR, הדרך הקלה ביותר תהיה להשתמש ב-DsrHelper ו-DsrMainHelpers
בסקריפט הסימולציה שלך. לדוגמה:

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

התסריטים לדוגמה בפנים src/dsr/examples/ להדגים את השימוש ב-Nodesin מבוסס DSR
תרחישים שונים. ניתן למצוא את מקור העוזר בפנים
src/dsr/helper/dsr-main-helper.{h,cc} ו src/dsr/helper/dsr-helper.{h,cc}

דוגמאות
את הדוגמה ניתן למצוא ב src/dsr/examples/:

· dsr.cc השתמש ב-DSR כפרוטוקול ניתוב בתוך סביבת MANETs מסורתית[3].

DSR נבנה גם במקרה של השוואת ניתוב ב דוגמאות/ניתוב/:

· manet-routing-compare.cc הוא מקרה השוואה עם פרוטוקולי ניתוב מובנים של MANET ו
יכול לייצר תוצאות משלו.

בדיקת מערכות
דגם זה נבדק באופן הבא:

· בדיקות יחידה נכתבו כדי לאמת את הפנימיות של DSR. ניתן למצוא זאת ב
src/dsr/test/dsr-test-suite.cc. בדיקות אלו מוודאות אם השיטות בתוך מודול DSR
שעוסקים במאגר מנות, הכותרות פועלות כהלכה.

· מקרי סימולציה דומים ל-[3] נבדקו ויש להם תוצאות דומות.

· נעשה שימוש ב-manet-routing-compare.cc כדי להשוות DSR עם שלושה ניתובים אחרים
פרוטוקולים.

מאמר הוצג על תוצאות אלה בסדנה על ns-3 ב-2011.

מגבלות
הדגם אינו תואם באופן מלא RFC 4728. כדוגמה, לכותרת בגודל קבוע של Dsr יש
הוארך והוא ארוך בארבע אוקטטים ממפרט ה-RFC. כתוצאה מכך,
לא ניתן לפענח נכון את כותרות ה-DSR על ידי Wireshark.

התאמה מלאה של הדגם ל-RFC מתוכננת לעתיד.

הפניות
[1] נייר מקורי: http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf

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

[3] מאמר ההשוואה של ברוך: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps

אמולציה סקירה כללית

ns-3 תוכנן לשילוב בסביבות מבחן ומכונות וירטואליות. אָנוּ
ענו על הצורך הזה על ידי אספקת שני סוגים של התקני רשת. מכשיר מהסוג הראשון
הוא מכשיר נטו של מתאר קבצים (FdNetDevice), שהוא סוג מכשיר גנרי שיכול
לקרוא ולכתוב מתוך מתאר קובץ. על ידי שיוך מתאר קובץ זה עם שונה
דברים במערכת המארחת, ניתן לספק יכולות שונות. למשל, ה
ניתן לשייך FdNetDevice לשקע מנות בסיסי כדי לספק אמולציה
יכולות. זה מאפשר ns-3 סימולציות לשליחת נתונים ברשת "אמיתית". השני
סוג, הנקרא א ברז NetDevice מאפשר למארח "אמיתי" להשתתף ב- ns-3 סימולציה כמו
אם זה היה אחד הצמתים המדומים. א ns-3 ניתן לבנות סימולציה עם כל
שילוב של מכשירים מדומים או חיקויים.

הערה: לפני ns-3.17, יכולת האמולציה סופקה על ידי מכשיר מיוחד בשם
an אֶמוּ NetDevice; ה אֶמוּ NetDevice הוחלף ב- FdNetDevice.

אחד ממקרי השימוש בהם אנו רוצים לתמוך הוא זה של מיטת מבחן. דוגמה קונקרטית של א
סביבה מסוג זה היא ערכת המבחן של ORBIT. ORBIT הוא אמולטור מעבדה/ניסוי שטח
רשת מסודרת כרשת דו מימדית של 400 צמתי רדיו 802.11. אנחנו משתלבים עם
ORBIT באמצעות תהליך "ההדמיה" שלהם לטעינה ולהפעלה ns-3 סימולציות על ORBIT
מַעֲרָך. אנחנו יכולים להשתמש שלנו EmuFdNetDevice להניע את החומרה במשטח המבחן ואנחנו יכולים
לצבור תוצאות באמצעות ns-3 פונקציות מעקב ורישום, או הילידים
טכניקות לאיסוף נתונים של ORBIT. לִרְאוֹת http://www.orbit-lab.org/ לפרטים על ORBIT
נבד

סימולציה מסוג זה מוצגת באיור הבא:
[תמונה] דוגמה ליישום של אמולציית Testbed..UNINDENT

אתה יכול לראות שיש מארחים נפרדים, שכל אחד מהם מפעיל תת-קבוצה של "גלובלי"
סימולציה. במקום א ns-3 ערוץ המחבר את המארחים, אנו משתמשים בחומרה אמיתית
מסופק על ידי מיטת המבחן. זה מאפשר ns-3 יישומים וערימות פרוטוקולים המצורפות לא
צומת סימולציה לתקשורת באמצעות חומרה אמיתית.

אנו מצפים שהשימוש העיקרי בתצורה זו יהיה ליצור ניתנים לחזרה
תוצאות ניסיוניות בסביבת רשת בעולם האמיתי הכוללת את כל ns-3
כלי מעקב, רישום, הדמיה ואיסוף סטטיסטיקות.

במה שניתן לראות כתצורה הפוכה בעצם, אנו מאפשרים מכונות "אמיתיות".
הפעלת יישומים מקוריים וערימות פרוטוקולים לשילוב עם ns-3 סימולציה.
זה מאפשר הדמיה של רשתות גדולות המחוברות למכונה אמיתית, וגם
מאפשר וירטואליזציה. סימולציה מסוג זה מוצגת באיור הבא:
[תמונה] סקירת יישום של ערוץ אמולציה..UNINDENT

כאן תראה שיש מארח יחיד עם מספר מכונות וירטואליות פועלות
על זה. א ns-3 סימולציה מוצגת פועלת במכונה הוירטואלית המוצגת במרכז
הצורה. לסימולציה זו יש מספר צמתים המשויכים ns-3 יישומים ו
ערימות פרוטוקול שמדברות עם א ns-3 ערוץ באמצעות סימולציה מקורית ns-3 נטו
התקנים.

יש גם שתי מכונות וירטואליות המוצגות בקצה השמאלי והקצה הימני של האיור.
מחשבי VM אלה מריצים יישומים מקוריים (Linux) וערימות פרוטוקולים. ה-VM הוא
מחובר לסימולציה באמצעות מכשיר Linux Tap net. המטפל במצב משתמש עבור
מכשיר הקשה מופעל בסימולציה ומצורף לצומת פרוקסי ש
מייצג את ה-VM המקורי בסימולציה. מטפלים אלה מאפשרים למכשירי Tap על
VMs מקוריים להתנהג כאילו היו ns-3 התקני נטו ב-VM של סימולציה. זה, ב
turn, מאפשר לתוכנות ולחבילות הפרוטוקולים המקוריות ב-VMs המקוריים להאמין בכך
הם מחוברים למדומה 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, לשקע,
או לתהליך מרחב משתמש.

זה תלוי במשתמש של מכשיר זה לספק מתאר קובץ. סוג הקובץ
המתאר המסופק קובע את המודל. למשל, אם הקובץ
descriptor מספק שקע גולמי לכרטיס WiFi במחשב המארח, כשהמכשיר הוא
הדגם הוא מכשיר WiFi.

מה"חלק העליון" הרעיוני של המכשיר במבט מטה, הוא נראה כמו הצומת המדומה
מכשיר התומך בכתובת IEEE MAC של 48 סיביות שניתן לגשר עליה, תומך בשידור ו
משתמש ב-IPv4 ARP או IPv6 Neighbor Discovery, אם כי ניתן לכוון את התכונות הללו על
בסיס לכל מקרה שימוש.

עיצוב
המימוש של FdNetDevice עושה שימוש באובייקט קורא, מורחב מה- FdReader
בכיתה ב ns-3 src/core מודול, שמנהל שרשור נפרד מהראשי ns-3
שרשור ביצוע, על מנת לקרוא תעבורה מתאר הקובץ.

עם הפעלת ה StartDevice השיטה, אובייקט הקורא מאותחל ומתחיל את
חוט קריאה. לפני הפעלת המכשיר, יש לשייך קודם לכן מתאר קובץ
ה-FdNetDevice עם ה SetFileDescriptor קְרִיאָה.

את היצירה וההגדרה של מתאר הקובץ ניתן להשאיר למספר עוזרים,
המתואר ביתר פירוט להלן. כאשר זה נעשה, הפניה של SetFileDescriptor is
אחריותו של העוזר ואין להפעיל ישירות על ידי המשתמש.

עם קריאת מסגרת נכנסת מתאר הקובץ, הקורא יעביר את המסגרת אל
מה היא קבל התקשרות חוזרת שיטה, שתפקידה לתזמן את קליטת המסגרת על ידי ה
מכשיר בתור א ns-3 אירוע סימולציה. מאז שהמסגרת החדשה מועברת משרשור הקורא אל
העיקרי ns-3 חוט סימולציה, בעיות בטיחות חוט נמנעות על ידי שימוש ב-
ScheduleWithContext להתקשר במקום הרגיל לוח זמנים שיחה.

על מנת להימנע מהצפת המתזמן כאשר קצב הנתונים הנכנס גבוה מדי, א
המונה נשמר עם מספר הפריימים שמתוכננים כעת להתקבל על ידי
המכשיר. אם מונה זה מגיע לערך שניתן על ידי ה- RxQueueSize תכונה ב
מכשיר, אז המסגרת החדשה תישמט בשקט.

הקליטה בפועל של המסגרת החדשה על ידי המכשיר מתרחשת בזמן המתוכנן FordwarUp
השיטה מופעלת על ידי הסימולטור. שיטה זו פועלת כאילו הגיעה מסגרת חדשה מא
ערוץ המחובר למכשיר. לאחר מכן, המכשיר מסיר את הקפסולה של המסגרת, ומסיר כל שכבה
2 כותרות, ומעביר אותו לשכבות ערימת הרשת העליונות של הצומת. ה קדימה למעלה
השיטה תסיר את כותרות המסגרת, בהתאם לסוג הקיפסולציה של המסגרת שהוגדרה על ידי
מה היא EncapsulationMode תכונה, ולהפעיל את הקבלה להתקשרות חוזרת בהעברת חבילת IP.

כותרת נוספת, כותרת PI, יכולה להיות קיימת כאשר מתאר הקובץ משויך ל-a
מכשיר TAP שנוצר ללא הגדרת דגל IFF_NO_PI. הכותרת הנוספת הזו היא
הוסר אם EncapsulationMode מוגדר לערך DIXPI.

בכיוון ההפוך, מנות שנוצרות בתוך הסימולציה שנשלחות החוצה
דרך המכשיר, יועבר ל- שילחו שיטה, אשר בתורה תפעיל את
שלח מאת שיטה. השיטה האחרונה תוסיף את הכותרות הנחוצות של שכבה 2, ופשוט
כתוב את המסגרת החדשה שנוצרה לתיאור הקובץ.

היקף ו מגבלות
משתמשים במכשיר הזה מוזהרים שאין בקרת זרימה על פני הקובץ
גבול מתאר, בעת שימוש במצב אמולציה. כלומר, במערכת לינוקס, אם ה
מהירות כתיבת מנות רשת עולה על היכולת של המכשיר הפיזי הבסיסי לעשות זאת
לחצץ את החבילות, לחץ אחורי עד ליישום הכתיבה יופעל כדי להימנע
אובדן מנות מקומי. לא מסופקת בקרת זרימה כזו על פני ממשק מתאר הקבצים,
לכן המשתמשים חייבים להיות מודעים למגבלה זו.

כפי שהוסבר קודם, התכונה RxQueueSize מגבילה את מספר החבילות שיכולות להיות
ממתין להתקבל על ידי המכשיר. מסגרות נקראות מתאר הקובץ בזמן שה-
מספר החבילות הממתינות נמצא במקסימום יבוטל בשקט.

ברירת המחדל של ה-mtu של ההתקן הוא ערך Ethernet II MTU. עם זאת, עוזרים אמורים
כדי להגדיר את ה-mtu לערך הנכון שישקף את המאפיינים של ממשק הרשת
המשויך לתיאור הקובץ. אם לא נעשה שימוש במסייע, אזי האחריות של
הגדרת ערך ה-MTU הנכון עבור המכשיר נופלת בחזרה למשתמש. גודל הקריאה
מאגר בקורא מתאר הקבצים מוגדר לערך mtu ב- StartDevice שִׁיטָה.

מחלקת FdNetDevice תומכת כיום בשלושה מצבי אנקפסולציה, DIX עבור Ethernet II
מסגרות, LLC עבור מסגרות 802.2 LLC/SNAP, ו-DIXPI עבור מסגרות Ethernet II עם מסגרות נוספות
כותרת TAP PI. המשמעות היא שתעבורה שעוברת את מתאר הקובץ צפויה להיות
תואם Ethernet II. חיבור FdNetDevice לממשק אלחוטי אפשרי כמו
כל עוד מנהל ההתקן מספק מסגרות Ethernet II ל-Socket API. שימו לב לשיוך
FdNetDevice לכרטיס אלחוטי במצב אד-הוק, יש להגדיר את כתובת ה-MAC של המכשיר
לכתובת ה-MAC של הכרטיס האמיתי, אחרת כל תעבורה נכנסת תהיה כתובת MAC מזויפת
נזרק על ידי הנהג.

כפי שצוין קודם, שלושה עוזרים מסופקים עם מודול fd-net-device. כל אחד
לעוזר בודד (סוג מתאר קובץ) עשויות להיות מגבלות פלטפורמה. לדוגמה,
שרשור, מצב סימולציה בזמן אמת והיכולת ליצור התקני TUN/TAP הם
תנאים מוקדמים לשימוש בעוזרים שסופקו. ניתן למצוא תמיכה במצבים אלה ב-
פלט של WAF להגדיר שלב, למשל:

שרשור פרימיטיבים: מופעל
סימולטור זמן אמת: מופעל
Emulated Net Device : מופעל
הקש על גשר: מופעל

חשוב להזכיר שבזמן בדיקת ה FdNetDevice מצאנו גבול עליון
מגבלה לתפוקת TCP בעת שימוש בקישורי Ethernet של 1Gb של 60Mbps. הגבול הזה הוא הכי הרבה
ככל הנראה בשל כוח העיבוד של המחשבים המעורבים בבדיקות.

נוֹהָג
דפוס השימוש במכשיר מסוג זה דומה למכשירי רשת אחרים עם עוזרים
המתקינים מצביעי צומת או מיכלי צומת. בעת שימוש בבסיס FdNetDeviceHelper
המשתמש אחראי ליצור ולהגדיר את מתאר הקובץ בעצמו.

FdNetDeviceHelper fd;
התקני NetDeviceContainer = fd.Install (צמתים);

// יצירת מתאר קבצים
...

device->SetFileDescriptor (fd);

בדרך כלל ישמש FdNetDevice לאינטראקציה עם המערכת המארחת. במקרים אלו
כמעט בטוח שהמשתמש ירצה להפעיל במצב אמולציה בזמן אמת, וכן
לאפשר חישובי סכום ביקורת. הצהרות התוכנית האופייניות הן כדלקמן:

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

הדרך הקלה ביותר להגדיר ניסוי המקיים אינטראקציה עם מערכת מארח לינוקס היא למשתמש
מה היא אֶמוּ ו ברז עוזרים. אולי החלק היוצא דופן ביותר של יישומי עוזר אלה
מתייחס לדרישה לביצוע חלק מהקוד עם הרשאות משתמש-על.
במקום לאלץ את המשתמש לבצע את כל הסימולציה כשורש, אנו מספקים קטן
תוכנית "יוצר" הפועלת כשורש ועושה כל שקעים נדרשים עם הרשאות גבוהות.
הדרך הקלה ביותר להגדיר את ההרשאות הנכונות עבור תוכניות ה"יוצר", היא על ידי הפעלת
--enable-sudo דגל בעת ביצוע WAF להגדיר.

אנחנו עושים דבר דומה לשניהם אֶמוּ ו ברז מכשירים. ההשקפה ברמה הגבוהה היא כזו
מה היא CreateFileDescriptor השיטה יוצרת שקע מקומי בין תהליכים (Unix), מזלגות ו
מבצע את תוכנית היצירה הקטנה. התוכנית הקטנה, הפועלת כ-suid root, יוצרת א
שקע גולמי ושולח בחזרה את מתאר קובץ השקע הגולמי מעל שקע יוניקס שהוא
הועבר אליו כפרמטר. השקע הגולמי מועבר כהודעת בקרה (לפעמים
שנקרא נתונים נלווים) מסוג SCM_RIGHTS.

עוזרים
EmuFdNetDeviceHelper
EmuFdNetDeviceHelper יוצר שקע גולמי למכשיר פיזי בסיסי, ו
מספק את מתאר השקע ל-FdNetDevice. זה מאפשר את ns-3 סימולציה ל
קרא מסגרות וכתוב מסגרות להתקן רשת במארח.

עוזר האמולציה מאפשר לשלב בשקיפות סימולציה ns-3 צומת לתוך א
רשת המורכבת מצמתים אמיתיים.

+---------------------+ +------------------------------+
| מארח 1 | | מארח 2 |
+---------------------+ +------------------------------+
| סימולציית ns-3 | | |
+----------------------------+ | לינוקס |
| ns-3 צומת | | מחסנית רשת |
| +----------------+ | | +----------------+ |
| | ns-3 TCP | | | | TCP | |
| +----------------+ | | +----------------+ |
| | ns-3 IP | | | | IP | |
| +----------------+ | | +----------------+ |
| | FdNetDevice | | | | | |
| | 10.1.1.1 | | | | | |
| +----------------+ | | + ETHERNET + |
| | שקע גולמי | | | | | |
|--+----------------+--| | +----------------+ |
| | eth0 | | | | eth0 | |
+-------+------+--------+ +--------+------+-------+

10.1.1.11 10.1.1.12

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

עוזר זה מחליף את הפונקציונליות של EmuNetDevice נמצא ב ns-3 לפני ns-3.17,
על ידי הכנסת סוג זה של מכשיר למסגרת המשותפת של FdNetDevice. ה
EmuNetDevice הודח לטובת העוזר החדש הזה.

ההתקן מוגדר לבצע זיוף של MAC כדי להפריד בין תעבורת רשת סימולציה
מתעבורת רשת אחרת שעשויה להיות זורמת אל וממנו המארח.

אפשר להשתמש בעוזר הזה במצב מבחן שבו המארח שעליו נמצאת הסימולציה
לריצה יש ממשק עניין ספציפי שמניע את חומרת המבחן. אתה היית
צריך גם להגדיר את הממשק הספציפי הזה למצב מופקר ולספק הולם
שם המכשיר ל- ns-3 סימולציה. בנוסף, הורדת חומרה של פילוח ו
יש להשבית סכומי בדיקה.

העוזר עובד רק אם הממשק הבסיסי פועל ובמצב מופקר. מנות
ישלחו דרך המכשיר, אבל אנחנו משתמשים בזיוף MAC. כתובות ה-MAC יהיו
נוצר (כברירת מחדל) באמצעות המזהה הייחודי הארגוני (OUI) 00:00:00 בתור
בסיס. קוד ספק זה אינו מוקצה לאף ארגון ולכן אינו אמור להתנגש עם
כל חומרה אמיתית.

זה תמיד תלוי במשתמש כדי לקבוע שהשימוש בכתובות MAC אלה הוא בסדר עבורך
רשת ולא יתנגש עם שום דבר אחר (כולל סימולציה נוספת באמצעות כזו
התקנים) ברשת שלך. אם אתה משתמש בתצורת FdNetDevice המדומה ב
סימולציות נפרדות, עליך לשקול בעיות של הקצאת כתובות MAC גלובליות ולהבטיח
שכתובות MAC הן ייחודיות בכל הסימולציות. מכשיר הרשת המדומה מכבד את
כתובת MAC מסופקת ב- כתובת תכונה כדי שתוכל לעשות זאת באופן ידני. לגדולים יותר
סימולציות, ייתכן שתרצה להגדיר את ה-OUI בפונקציית הקצאת כתובות MAC.

לפני הפעלת ה התקן בשיטה, יש להגדיר את שם ההתקן הנכון ב-
עוזר המשתמש ב- SetDeviceName שיטה. שם המכשיר נדרש כדי לזהות איזה
יש להשתמש במכשיר פיזי כדי לפתוח את השקע הגולמי.

EmuFdNetDeviceHelper emu;
emu.SetDeviceName (deviceName);
התקני NetDeviceContainer = emu.Install (צומת);
Ptr device = devices.Get (0);
device->SetAttribute ("כתובת", Mac48AddressValue (Mac48Address::Allocate ()));

TapFdNetDeviceHelper
מכשיר Tap הוא סוג מיוחד של מכשיר לינוקס שעבורו נראה קצה אחד של המכשיר
הקרנל כ-net_device וירטואלי, והקצה השני מסופק כמתאר קובץ ל
מרחב משתמש. ניתן להעביר את מתאר הקובץ הזה ל-FdNetDevice. מנות שהועברו ל
מכשיר ה-TAP על ידי הליבה יופיע ב-FdNetDevice in ns-3.

על המשתמשים לשים לב ששימוש זה במכשירי TAP שונה מזה שסופק על ידי
TapBridge NetDevice נמצא ב src/tap-bridge. המודל בעזר זה הוא כדלקמן:

+--------------------------------------------+
| מארח |
+--------------------------------------------+
| סימולציית ns-3 | |
+----------------------------+ |
| ns-3 צומת | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNetDevice | | |
|--+----------------+--+ +------+ |
| | TAP | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-------------------------------|-----+
|
|
------------ (מרשתת) -----

באמור לעיל, התצורה דורשת שהמארח יוכל להעביר תעבורה
שנוצר על ידי הסימולציה לאינטרנט.

הדגם ב-TapBridge (במודול אחר) הוא כדלקמן:

+--------+
| לינוקס |
| מארח | +----------+
| ------ | | רוח רפאים |
| אפליקציות | | צומת |
| ------ | | -------- |
| מחסנית | | IP | +----------+
| ------ | | מחסנית | | צומת |
| TAP | |===========| | -------- |
| מכשיר | <----- IPC ------> | הקש | | IP |
+--------+ | גשר | | מחסנית |
| -------- | | -------- |
| ns-3 | | ns-3 |
| נטו | | נטו |
| מכשיר | | מכשיר |
+----------+ +----------+
|| ||
+--------------------------------+
| ערוץ ns-3 |
+--------------------------------+

באמור לעיל, מנות במקום חוצות ns-3 NetDevices וערוצים.

דפוס השימוש בדוגמה זו הוא שהמשתמש מגדיר את כתובת ה-MAC או (או
שניהם) כתובות ומסיכות 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 ל-a
FdNetDevice ב-ns-3. הפונקציונליות שמספק עוזר זה דומה לזה
מסופק על ידי FdTapNetDeviceHelper, אלא שהמנגנונים הבסיסיים ליצירת ה
מכשירי TAP שונים.

+--------------------------------------------+
| מארח PlanetLab |
+--------------------------------------------+
| סימולציית ns-3 | |
+----------------------------+ |
| ns-3 צומת | |
| +----------------+ | |
| | ns-3 TCP | | |
| +----------------+ | |
| | ns-3 IP | | |
| +----------------+ | |
| | FdNetDevice | | |
|--+----------------+--+ +------+ |
| | TAP | | eth0 | |
| +------+ +------+ |
| 192.168.0.1 | |
+-------------------------------|-----+
|
|
------------ (מרשתת) -----

על מנת להיות מסוגל להקצות כתובות IPv4 פרטיות למכשירי TAP, בעלי חשבונות
חייב לבקש את vsys_vnet תג שיתווסף לפרוסה שלהם על ידי מנהלי PlanetLab.
התג vsys_vnet משויך לפלח רשת פרטית ורק כתובות ממנו
ניתן להשתמש בקטע בניסויים.

התחביר המשמש ליצירת התקן TAP עם מסייע זה דומה לזה המשמש עבור
עוזרים שתוארו בעבר:

PlanetLabFdNetDeviceHelper עוזר;
helper.SetTapIpAddress (tapIp);
helper.SetTapMask (tapMask);
...
helper.Install (צומת);

לצמתים של PlanetLab יש הפצה מבוססת Fedora, כך שניתן להתקין את ns-3 בעקבות ה
הוראות להתקנת ns-3 Linux.

תכונות
השמיים FdNetDevice מספק מספר תכונות:

· כתובת: כתובת ה-MAC של המכשיר

· הַתחָלָה: שעת ההתחלה של הסימולציה לסובב את פתיל המכשיר

· עצור: שעת ההתחלה של הסימולציה לעצירת שרשור המכשיר

· EncapsulationMode: פורמט אנקפסולציה של שכבת קישור

·

RxQueueSize: השמיים חיץ גודל of מה היא לקרוא תור on מה היא פילה מתאר
שרשור (ברירת מחדל של 1000 מנות)

הַתחָלָה ו עצור בדרך כלל אין צורך לציין אלא אם המשתמש רוצה להגביל את
זמן שבמהלכו מכשיר זה פעיל. כתובת צריך להיות מוגדר לסוג של ייחודי
כתובת MAC אם הסימולציה תהיה אינטראקציה עם מכשירים אמיתיים אחרים באמצעות איכשהו
כתובות MAC אמיתיות. קוד טיפוסי:

device->SetAttribute ("כתובת", Mac48AddressValue (Mac48Address::Allocate ()));

תְפוּקָה
מעקב אחר Ascii ו-PCAP מסופק בדומה לשני ns-3 סוגי NetDevice, דרך ה
עוזרים, כגון (למשל):

:: EmuFdNetDeviceHelper emu; התקני NetDeviceContainer = emu.Install (צומת);
emu.EnablePcap ("emu-ping", מכשיר, true);

הסט הסטנדרטי של מקורות מעקב NetDevice ברמת Mac מסופק.

· MaxTx: מקור מעקב מופעל כאשר ns-3 מספק למכשיר מסגרת חדשה לשליחה

· MaxTxDrop: מעקב אחר מקור אם מתאר הכתיבה לקובץ נכשל

· MaxPromiscRx: בכל פעם שמתקבלת מסגרת Mac חוקית כלשהי

· MaxRx: בכל פעם שמתקבלת מסגרת Mac חוקית עבור מכשיר זה

· כוסית: רחרח מנות לא מופקר

· PromiscSniffer: רחרח מנות מופקר (עבור עקבות דמויי tcpdump)

דוגמאות
מובאות מספר דוגמאות:

· dummy-network.cc: דוגמה פשוטה זו יוצרת שני צמתים ומחברת ביניהם עם a
צינור יוניקס על ידי העברת מתארי הקבצים מצמד השקעים ל-FdNetDevice
אובייקטים של הצמתים המתאימים.

· realtime-dummy-network.cc: זהה ל-dummy-network.cc אבל משתמש בסימולטור זמן אמת
יישום במקום ברירת המחדל.

· fd2fd-onoff.cc: דוגמה זו מכוונת למדידת התפוקה של ה-FdNetDevice ב
סימולציה טהורה. למטרה זו שני FdNetDevices, המחוברים לצמתים שונים אך בתוך
אותה סימולציה, מחוברים באמצעות זוג שקעים. תעבורת TCP נשלחת ב-a
קצב נתונים רווי.

· fd-emu-onoff.cc: דוגמה זו מכוונת למדידת התפוקה של ה-FdNetDevice
בעת שימוש ב-EmuFdNetDeviceHelper כדי לחבר את ההתקן המדומה למכשיר אמיתי ב
המכונה המארח. זה מושג על ידי הרוויה של הערוץ בתעבורת TCP.

· fd-emu-ping.cc: דוגמה זו משתמשת ב-EmuFdNetDeviceHelper כדי לשלוח תעבורת ICMP דרך א
ערוץ אמיתי.

· fd-emu-udp-echo.cc: דוגמה זו משתמשת ב-EmuFdNetDeviceHelper כדי לשלוח תעבורת UDP
ערוץ אמיתי.

· fd-planetlab-ping.cc: דוגמה זו מראה כיצד להגדיר ניסוי לשליחת ICMP
תעבורה מצומת PlanetLab לאינטרנט.

· fd-tap-ping.cc: דוגמה זו משתמשת ב-TapFdNetDeviceHelper כדי לשלוח תעבורת ICMP דרך א
ערוץ אמיתי.

ברז NetDevice
ניתן להשתמש ב-Tap NetDevice כדי לאפשר למערכת מארחת או למכונות וירטואליות אינטראקציה
סימולציה.

TapBridge מספר סימוכין סקירה כללית
The Tap Bridge נועד לשלב מארחי אינטרנט "אמיתיים" (או ליתר דיוק, מארחים
התומכים במכשירי Tun/Tap) לסימולציות ns-3. המטרה היא לגרום לזה להיראות לא
צומת מארח "אמיתי" בכך שיש לו מכשיר ns-3 net כהתקן מקומי. הרעיון של א
"מארח אמיתי" הוא קצת חלקלק מכיוון שה"מארח האמיתי" עשוי להיות וירטואלי באמצעות שימוש
טכנולוגיות זמינות כמו VMware, VirtualBox או OpenVZ.

מכיוון שאנו, בעצם, מחברים את הכניסות והיציאות של התקן ns-3 net ל-
כניסות ויציאות של מכשיר Linux Tap net, אנו קוראים להסדר הזה Tap Bridge.

ישנם שלושה מצבי הפעלה בסיסיים של מכשיר זה זמינים למשתמשים. בסיסי
הפונקציונליות זהה במהותה, אבל המצבים שונים בפרטים לגבי
כיצד נוצר והגדרת ההסדר; ואיזה מכשירים יכולים לחיות באיזה צד של
הגשר.

אנו קוראים לשלושת המצבים האלה המצבים ConfigureLocal, UseLocal ו-UseBridge. הראשון
"מילה" במזהה מצב מקרה גמל מציינת למי יש אחריות ליצור
והגדרת הברזים. לדוגמה, "הגדר" במצב ConfigureLocal מציין
שזהו ה-TapBridge שאחריות להגדיר את הברז. ב-UseLocal
מצב ומצבי UseBridge, הקידומת "השתמש" מציינת שה-TapBridge מתבקש "השתמש"
תצורה קיימת.

במילים אחרות, במצב ConfigureLocal, ל-TapBridge יש את האחריות ליצור
והגדרת התקני TAP. במצבי UseBridge או UseLocal, המשתמש מספק א
תצורה וה-TapBridge מסתגל לתצורה זו.

TapBridge ConfigureLocal מצב
במצב ConfigureLocal, התצורה של התקן הברז היא ns-3
ממוקד תצורה. מידע תצורה נלקח מהתקן ב-ns-3
סימולציה והתקן ברז התואם לתכונות ns-3 נוצר אוטומטית. ב
במקרה זה, מחשב לינוקס עשוי להיראות כאילו הוא מחובר ישירות ל-a
רשת ns-3 מדומה.

זה מודגם להלן:

+--------+
| לינוקס |
| מארח | +----------+
| ------ | | רוח רפאים |
| אפליקציות | | צומת |
| ------ | | -------- |
| מחסנית | | IP | +----------+
| ------ | | מחסנית | | צומת |
| TAP | |===========| | -------- |
| מכשיר | <----- IPC ------> | הקש | | IP |
+--------+ | גשר | | מחסנית |
| -------- | | -------- |
| ns-3 | | ns-3 |
| נטו | | נטו |
| מכשיר | | מכשיר |
+----------+ +----------+
|| ||
+--------------------------------+
| ערוץ ns-3 |
+--------------------------------+

במקרה זה, ה-"ns-3 net device" ב-"ghost node" נראה כאילו היה זה בפועל
החלפת התקן TAP במארח לינוקס. הדמיית ns-3 יוצרת את התקן TAP מופעל
מערכת ההפעלה הבסיסית של Linux ומגדירה את כתובות ה-IP וה-MAC של מכשיר ה-TAP כך שיתאימו
הערכים שהוקצו למכשיר המדמה ns-3 net. הקישור "IPC" המוצג למעלה הוא
מנגנון הקשה ברשת במערכת ההפעלה הבסיסית. ההסדר כולו פועל כמקובל
לְגַשֵׁר; אלא גשר בין מכשירים שבמקרה יש להם את אותו MAC ו-IP משותפים
כתובות.

כאן, המשתמש אינו נדרש לספק מידע תצורה ספציפי ל-
בֶּרֶז. התקן ברז יווצר ויוגדר על ידי ns-3 בהתאם לברירות המחדל שלו, וכן
שמו של מכשיר הברז יוקצה על ידי מערכת ההפעלה הבסיסית בהתאם
ברירת המחדל שלו.

אם למשתמש יש דרישה לגשת למכשיר ההקשה שנוצר, הוא או היא יכולים לחלופין
ספק תכונה "DeviceName". במקרה זה, התקן ההקשה של מערכת ההפעלה שנוצר יקבל שם
בהתאם לכך.

מצב ConfigureLocal הוא מצב ההפעלה המוגדר כברירת מחדל של ה-Tap Bridge.

TapBridge השתמש ב-Local מצב
מצב UseLocal דומה למדי למצב ConfigureLocal. ההבדל המשמעותי
הוא, כפי ששם המצב מרמז, ה-TapBridge הולך "להשתמש" בהתקן ברז קיים
נוצר והוגדר בעבר על ידי המשתמש. מצב זה שימושי במיוחד כאשר א
סכימת וירטואליזציה יוצרת אוטומטית התקני ברז ו-ns-3 משמש לספק
רשתות מדומה עבור אותם מכשירים.

+--------+
| לינוקס |
| מארח | +----------+
| ------ | | רוח רפאים |
| אפליקציות | | צומת |
| ------ | | -------- |
| מחסנית | | IP | +----------+
| ------ | | מחסנית | | צומת |
| TAP | |===========| | -------- |
| מכשיר | <----- IPC ------> | הקש | | IP |
| MAC X | | גשר | | מחסנית |
+--------+ | -------- | | -------- |
| ns-3 | | ns-3 |
| נטו | | נטו |
| מכשיר | | מכשיר |
| MAC Y | | MAC Z |
+----------+ +----------+
|| ||
+--------------------------------+
| ערוץ ns-3 |
+--------------------------------+

במקרה זה, כתובת ה-MAC המוגדרת מראש של "מכשיר ההקשה" (MAC X) לא תהיה
זהה לזה של ה-"ns-3 net device" (MAC Y) המגושר המוצג באיור למעלה. ב
כדי לגשר להתקני ns-3 net שאינם תומכים ב-SendFrom() (במיוחד אלחוטי
צמתי STA) אנו מטילים דרישה שרק מכשיר לינוקס אחד (עם כתובת MAC ייחודית אחת
-- כאן X) מייצר תעבורה שזורמת על פני קישור ה-IPC. זה בגלל ה-MAC
כתובות של תעבורה בקישור ה-IPC "יזויפו" או ישתנו כדי לגרום לה להיראות כך
לינוקס ו-ns-3 שיש להם אותה כתובת. כלומר, תעבורה נעה מה-Linux
מארח לצומת הרפאים ns-3 ישתנה כתובת ה-MAC שלו מ-X ל-Y ותעבורה מ-
כתובת ה-MAC שלו תשתנה מ-Y ל-X של צומת הרפאים למארח לינוקס. מאז
יש התכתבות של אחד לאחד בין מכשירים, יכול להיות שיש רק מקור MAC אחד
זורם מהצד של לינוקס. המשמעות היא שלינוקס מגשרת עם יותר ממכשיר נטו אחד
שנוספו אינם תואמים למצב UseLocal.

במצב UseLocal, המשתמש צפוי ליצור ולהגדיר התקן ברז לחלוטין
מחוץ להיקף של סימולציית ns-3 באמצעות משהו כמו:

$ sudo tunctl -t tap0
$ sudo ifconfig tap0 hw ether 08:00:2e:00:00:01
$ sudo ifconfig tap0 10.1.1.1 מסיכת רשת 255.255.255.0 למעלה

כדי לספר ל-TapBridge מה קורה, המשתמש יגדיר את אחד מהם ישירות לתוך
TapBridge או דרך TapBridgeHelper, התכונה "DeviceName". במקרה של ה
בתצורה שלמעלה, התכונה "DeviceName" תוגדר ל-"tap0" וה-"Mode"
התכונה תוגדר ל-"UseLocal".

מקרה שימוש מסוים עבור מצב זה הוא בסביבת OpenVZ. שם זה אפשרי
כדי ליצור התקן Tap ב"צומת החומרה" ולהעביר אותו לשרת פרטי וירטואלי.
אם ה-TapBridge מסוגל להשתמש בהתקן ברז קיים, אז אפשר להימנע מה
מעל גשר מערכת הפעלה בסביבה זו.

TapBridge UseBridge מצב
המצב הפשוט ביותר למי שמכיר את רשת לינוקס הוא מצב UseBridge. שוב,
הקידומת "השתמש" מציינת שה-TapBridge הולך להשתמש בתצורה קיימת.
במקרה זה, ה-TapBridge הולך להרחיב באופן הגיוני גשר לינוקס ל-ns-3.

זה מודגם להלן:

+---------+
| לינוקס | +----------+
| ------- | | רוח רפאים |
| אפליקציות | | צומת |
| ------- | | -------- |
| מחסנית | | IP | +----------+
| ------- | +--------+ | מחסנית | | צומת |
| וירטואלי | | TAP | |===========| | -------- |
| מכשיר | | מכשיר | <---- IPC -----> | הקש | | IP |
+--------+ +--------+ | גשר | | מחסנית |
|| || | -------- | | -------- |
+---------------------------+ | ns-3 | | ns-3 |
| OS (brctl) Bridge | | נטו | | נטו |
+--------------------+ | מכשיר | | מכשיר |
+----------+ +----------+
|| ||
+--------------------------------+
| ערוץ ns-3 |
+--------------------------------+

במקרה זה, מחשב המריץ אפליקציות לינוקס, פרוטוקולים וכו', מחובר ל-a
ns-3 מדמה רשת בצורה כזו שתראה למארח לינוקס שה-TAP
התקן הוא מכשיר רשת אמיתי המשתתף בגשר לינוקס.

בסימולציית ns-3 נוצר TapBridge שיתאים לכל התקן TAP. השם של
התקן TAP מוקצה ל-Tap Bridge באמצעות התכונה "DeviceName". ה-TapBridge
לאחר מכן מרחיב באופן הגיוני את גשר מערכת ההפעלה כדי להקיף את התקן ns-3 net.

מכיוון שמצב זה מרחיב באופן הגיוני גשר של מערכת הפעלה, ייתכן שיהיו התקני Linux רבים ברשת
צד שאינו ns-3 של הגשר. לכן, כמו מכשיר רשת בכל גשר, ה-ns-3 net
המכשיר חייב להתמודד עם אולי כתובות מקור רבות. לפיכך, התקני ns-3 חייבים
support SendFrom() (NetDevice::SupportsSendFrom() חייב להחזיר true) כדי להיות
מוגדר לשימוש במצב UseBridge.

צפוי שהמשתמש יעשה משהו כמו הבא כדי להגדיר את הגשר
והקש לגמרי מחוץ ל-ns-3:

$ sudo brctl addbr mybridge
$ sudo tunctl -t mytap
$ sudo ifconfig mytap hw ether 00:00:00:00:00:01
$ sudo ifconfig mytap 0.0.0.0 למעלה
$ sudo brctl addif mybridge mytap
$ sudo brctl addif mybridge ...
$ sudo ifconfig mybridge 10.1.1.1 מסיכת רשת 255.255.255.0 למעלה

כדי לספר ל-TapBridge מה קורה, המשתמש יגדיר את אחד מהם ישירות לתוך
TapBridge או דרך TapBridgeHelper, התכונה "DeviceName". במקרה של ה
בתצורה שלמעלה, התכונה "DeviceName" תוגדר ל-"mytap" וה-"Mode"
התכונה תוגדר ל-"UseBridge".

מצב זה שימושי במיוחד במקרה של וירטואליזציה שבה התצורה של
המארחים הווירטואליים עשויים להיות מוכתבים על ידי מערכת אחרת ואינם ניתנים לשינוי כדי להתאים ל-ns-3.
לדוגמה, סכימת VM מסוימת עשויה ליצור התקני "vethx" או "vmnetx" וירטואליים
מופיעים מקומיים למארחים וירטואליים. כדי להתחבר למערכות כאלה, יהיה צורך בכך
צור ידנית התקני TAP במערכת המארחת וגישור את התקני TAP אלה אל
מכשירים וירטואליים קיימים (VM). התפקיד של גשר הברז במקרה זה הוא להאריך את
גשר כדי להצטרף למכשיר ns-3 net.

TapBridge ConfigureLocal פעולה
במצב ConfigureLocal, ה-TapBridge ולפיכך התקן ns-3 net המשויך לו מופיעים
למחשב המארח של לינוקס כהתקן רשת בדיוק כמו כל "eth0" או "ath0" שרירותי
עשוי להופיע. היצירה וההגדרה של מכשיר ה-TAP נעשים על ידי ה-ns-3
סימולציה ולא נדרשת תצורה ידנית על ידי המשתמש. כתובות ה-IP, MAC
כתובות, שערים וכו' עבור התקני TAP שנוצרו נשלפים מהסימולציה
עצמו על ידי שאילתת התצורה של התקן ns-3 ותכונות TapBridge.

מכיוון שכתובות ה-MAC זהות בצד לינוקס ובצד ns-3, אנו יכולים להשתמש
Send() במכשיר ns-3 אשר זמין בכל מכשירי ns-3 net. מאז ה-MAC
הכתובות זהות, אין חובה לחבר את ההתקשרות המופקרת
צד לקבל. לכן אין הגבלות על סוגי מכשירי הרשת שהם
שמיש במצב ConfigureLocal.

ה-TapBridge נראה בהדמיית ns-3 כהתקן נטו ללא ערוצים. המכשיר הזה
לא חייבת להיות משויכת אליה כתובת IP, אבל התקן הרשת המגושר (ns-3) חייב
יש כתובת IP. שים לב שזהו היפוך של ns-3 BridgeNetDevice (או a
גשר קונבנציונלי באופן כללי) הדורש שליציאות הגשר שלו לא יהיו כתובות IP,
אך מאפשר להתקן הגשר עצמו לקבל כתובת IP.

המחשב המארח יופיע בסימולציה כצומת "רוח רפאים" שמכיל אחד
TapBridge עבור כל NetDevice שנמצא בגישור. מנקודת המבט של סימולציה,
ההבדל היחיד בין צומת רפאים לכל צומת אחר יהיה הנוכחות של ה-
מכשירי TapBridge. עם זאת, שים לב שנוכחות ה-TapBridge אכן משפיעה על
קישוריות התקן הרשת לערימת ה-IP של צומת הרפאים.

תצורת פרטי הכתובות והתקני ns-3 אינה משתנה בשום אופן אם א
TapBridge קיים. TapBridge יאסוף את מידע הכתובת מה-ns-3
מכשיר רשת שאליו הוא מחובר (התקן הרשת ה"מגושר" שלו) והשתמש במידע זה כדי
ליצור ולהגדיר את התקן TAP במארח האמיתי.

התוצאה הסופית של זה היא מצב שבו אפשר, למשל, להשתמש בפינג הסטנדרטי
כלי עזר על מארח אמיתי כדי לבצע ping לצומת ns-3 מדומה. אם נוספו מסלולים נכונים ל-
מארח אינטרנט (זה צפוי להיעשות אוטומטית במהדורות עתידיות של ns-3), ה
מערכות ניתוב ב-ns-3 יאפשרו ניתוב נכון של המנות על פני ns-3 מדומה
רשתות. לדוגמא לכך, עיין בתוכנית לדוגמה, tap-wifi-dumbbell.cc ב-
הפצת ns-3.

The Tap Bridge חי במעין עולם אפור איפשהו בין מארח לינוקס ל-ns-3
מכשיר גשר. מנקודת המבט של לינוקס, קוד זה מופיע כמטפל במצב משתמש עבור
מכשיר TAP net. במצב ConfigureLocal, התקן Tap זה נוצר באופן אוטומטי על ידי
סימולציית ns-3. כאשר מארח לינוקס כותב לאחד מאלה שנוצר באופן אוטומטי
/dev/tap devices, הכתיבה מנותבת ל-TapBridge שחי בעולם ns-3;
ומנקודת מבט זו, כתיבת החבילות בלינוקס הופכת לחבילה הנקראת ב-Tap
לְגַשֵׁר. במילים אחרות, תהליך לינוקס כותב חבילה למכשיר ברז ולחבילה הזו
מופנה מחדש על ידי מנגנון הקשה ברשת לתהליך ns-3 שבו הוא מתקבל על ידי
TapBridge כתוצאה מפעולת קריאה שם. לאחר מכן ה-TapBridge כותב את החבילה אל
התקן ns-3 נטו אליו הוא מגשר; ולכן זה נראה כאילו מארח לינוקס
שלח חבילה ישירות דרך התקן ns-3 net לרשת ns-3.

בכיוון השני, חבילה שהתקבלה על ידי התקן ns-3 net המחובר ל-Tap
Bridge נשלח באמצעות קבלה התקשרות חזרה ל-TapBridge. לאחר מכן ה-TapBridge לוקח את זה
מנה וכותבת אותה בחזרה למארח באמצעות מנגנון ההקשה ברשת. זה כתוב ל-
המכשיר ייראה למארח לינוקס כאילו הגיעה מנה למכשיר נטו; ו
לכן כאילו הופיעה מנה שהתקבלה על ידי התקן ns-3 net במהלך סימולציה
במכשיר לינוקס נטו אמיתי.

התוצאה היא שנראה ש-Tap Bridge מגשר בין התקן ברז על מארח לינוקס ב-
"עולם אמיתי" למכשיר ns-3 נטו בסימולציה. מכיוון שהמכשיר TAP וה
למכשיר ns-3 net מגושר יש אותה כתובת MAC ולקישור ה-IPC ברז לרשת לא
בהחצנה, סוג מסוים זה של גשר גורם להראות שהתקן ns-3 net הוא
מותקן בפועל במארח לינוקס.

על מנת ליישם זאת בצד ns-3, אנו צריכים "צומת רפאים" בסימולציה ל
החזק את התקן ns-3 net המגושר ואת ה-TapBridge. הצומת הזה לא אמור לעשות
כל דבר אחר בסימולציה שכן תפקידו הוא פשוט לגרום למכשיר הרשת להופיע
לינוקס. זו לא רק מדיניות שרירותית, זה בגלל:

· ביטים שנשלחו ל-TapBridge משכבות גבוהות יותר בצומת הרפאים (באמצעות ה-TapBridge
שיטת השליחה) מתעלמת לחלוטין. ה-TapBridge אינו, בעצמו, מחובר לאף אחד
רשת, לא בלינוקס ולא ב-ns-3. לעולם לא תוכל לשלוח או לקבל נתונים דרך א
TapBridge מצומת הרפאים.

· התקן ns-3 net המגושר מנותק את הקבלה שלו מהצומת ns-3 ו
התחבר מחדש לגשר הברזים. כל הנתונים שיתקבלו על ידי מכשיר מגושר יישלחו לאחר מכן
למארח לינוקס ולא יתקבל על ידי הצומת. מנקודת המבט של ה
צומת רפאים, אתה יכול לשלוח דרך המכשיר הזה אבל אתה לא יכול לקבל לעולם.

כמובן, אם אתה מבין את כל הנושאים אתה יכול להשתלט על הגורל שלך
ותעשה מה שאתה רוצה -- אנחנו לא מונעים ממך באופן פעיל להשתמש בצומת הרפאים עבור
כל דבר שתחליט. תוכל לבצע פעולות ns-3 טיפוסיות על הרוח
צומת אם תרצה בכך. ערימת האינטרנט, למשל, חייבת להיות שם ולהתפקד
צומת זה על מנת להשתתף בהקצאת כתובות IP ובניתוב גלובלי. למרות זאת,
כפי שהוזכר לעיל, ממשקים מדברים עם כל TapBridge או התקני רשת מגושרים הקשורים אליו
לא יעבוד לגמרי. אם אתה מבין בדיוק מה אתה עושה, אתה יכול להגדיר
ממשקים והתקנים אחרים בצומת הרפאים והשתמש בהם; או לנצל את
צד השליחה התפעולי של ההתקנים המגושרים ליצירת מחוללי תנועה. אנחנו באופן כללי
ממליץ להתייחס לצומת זה כרוח רפאים של מארח לינוקס ולהשאיר אותו לעצמו,
אף.

TapBridge השתמש ב-Local מצב פעולה
כפי שתואר לעיל, ה-TapBridge פועל כמו גשר מהעולם ה"אמיתי" אל העולם
עולם ns-3 מדומה. במקרה של מצב ConfigureLocal, החיים קלים מאז ה-IP
כתובת התקן Tap תואמת את כתובת ה-IP של התקן ns-3 וכתובת ה-MAC של
מכשיר ה-Tap מתאים לכתובת ה-MAC של התקן ns-3; ויש אחד לאחד
הקשר בין המכשירים.

הדברים מעט מסובכים כאשר מכשיר Tap מוגדר חיצונית עם a
כתובת MAC שונה מהתקן ns-3 net. הדרך המקובלת להתמודד עם זה
סוג ההבדל הוא להשתמש במצב מופקר במכשיר המגושר כדי לקבל מנות
מיועדים לכתובת ה-MAC השונה ולהעביר אותם ללינוקס. על מנת לזוז
מנות לכיוון השני, הפתרון המקובל הוא SendFrom() המאפשר למתקשר לעשות זאת
"זייף" או שנה את כתובת ה-MAC המקור כך שתתאים לכתובת ה-MAC השונה של לינוקס.

יש לנו דרישה ספציפית כדי להיות מסוגלים לגשר אל מכונות וירטואליות של לינוקס
צמתי STA אלחוטיים. למרבה הצער, מפרט 802.11 אינו מספק דרך טובה לעשות זאת
ליישם את SendFrom(), אז עלינו לעקוף את הבעיה הזו.

לשם כך, סיפקנו את מצב UseLocal של גשר ה-Tap. מצב זה מאפשר לך
לגשת לבעיה כאילו אתה יוצר גשר עם התקן נטו בודד. בודד
הכתובת המותרת בצד לינוקס נזכרת ב-TapBridge, וכל החבילות מגיעות
מצד הלינוקס חוזרים על יד ns-3 באמצעות מקור MAC של מכשיר ns-3
כתובת. כל החבילות הנכנסות מהצד ns-3 חוזרות על עצמן מהצד של לינוקס באמצעות
כתובת ה-MAC הזכורה. זה מאפשר לנו להשתמש ב-Send() בצד מכשיר ns-3 כלומר
זמין בכל מכשירי ns-3 net.

מצב UseLocal זהה למצב ConfigureLocal למעט היצירה ו
תצורה של התקן הברז וזיוף כתובת MAC.

TapBridge UseBridge פעולה
כפי שמתואר בסעיף מצב ConfigureLocal, כאשר מארח לינוקס כותב לאחד מה-
/dev/tap devices, הכתיבה מנותבת ל-TapBridge שחי בעולם ns-3.
במקרה של מצב UseBridge, חבילות אלו יצטרכו להישלח ב-ns-3
רשת כאילו הם נשלחו במכשיר המשתתף בגשר לינוקס. זה אומר
קריאה לשיטת SendFrom() במכשיר המגושר ומספקת את כתובת ה-MAC המקור
נמצא בחבילה.

בכיוון השני, חבילה המתקבלת על ידי מכשיר ns-3 net מתחברת באמצעות התקשרות חזרה
את TapBridge. זה חייב להיעשות במצב מופקר מכיוון שהמטרה היא לגשר על ns-3
מכשיר net על גשר מערכת ההפעלה (brctl) שמכשיר ה-TAP הוא חלק ממנו.

מסיבות אלו, רק התקני ns-3 net התומכים ב-SendFrom() ובעלי חיבור לחיבור
קבלה מופקרת מורשים להשתתף במצב UseBridge TapBridge
תצורות.

ברז גשר ערוץ מספר סימוכין
אין מודל ערוץ המשויך לגשר ה-Tap. למעשה, הכוונה היא לעשות
נראה שמארח האינטרנט האמיתי מחובר לערוץ הרשת המגושרת
מכשיר.

ברז גשר מעקב מספר סימוכין
בניגוד לרוב מכשירי ה-ns-3, ה-TapBridge אינו מספק מקורות מעקב סטנדרטיים. זֶה
זה בגלל שהגשר הוא מתווך שרחוק ממנו בעצם קריאת פונקציה אחת
המכשיר המגושר. אנו מצפים כי ווי המעקב במכשיר המגושר יהיו
מספיק לרוב המשתמשים,

שימוש מה היא TapBridge
אנו מצפים שרוב המשתמשים יתקשרו עם מכשיר ה-TapBridge דרך ה
TapBridgeHelper. משתמשים בשיעורי עוזר אחרים, כגון CSMA או Wifi, צריכים להיות
נוח עם הניבים המשמשים שם.

אנרגיה מִסגֶרֶת

צריכת אנרגיה היא נושא מרכזי עבור מכשירים אלחוטיים וחוקרי רשתות אלחוטיות
לעתים קרובות צריך לחקור את צריכת האנרגיה בצומת או ברשת הכוללת תוך כדי
הפעלת סימולציות רשת ב-ns-3. זה דורש ns-3 כדי לתמוך בצריכת אנרגיה
דוּגמָנוּת. יתר על כן, ככל שמושגים כמו תאי דלק וניקוי אנרגיה הופכים
קיימא עבור התקנים אלחוטיים בהספק נמוך, תוך שילוב ההשפעה של אלה המתעוררים
טכנולוגיות לסימולציות דורשות תמיכה במודלים של מקורות אנרגיה מגוונים ב
ns-3. מסגרת האנרגיה של ns-3 מספקת את הבסיס לצריכת אנרגיה, מקור אנרגיה
ומידול לקצירת אנרגיה.

מספר סימוכין תיאור
קוד המקור של מסגרת האנרגיה נמצא כעת ב: src/energy.

עיצוב
מסגרת האנרגיה של ns-3 מורכבת משלושה חלקים: מקור אנרגיה, מודל אנרגיה של מכשיר ו
קוצר אנרגיה. המסגרת מיושמת לתוך src/energy/models תיקייה.

אנרגיה מָקוֹר
מקור האנרגיה מייצג את ספק הכוח בכל צומת. לצומת יכול להיות אחד או יותר
מקורות אנרגיה, וכל מקור אנרגיה יכול להיות מחובר לדגמי אנרגיה מרובים של מכשירים.
חיבור מקור אנרגיה למודל אנרגיה של התקן מרמז שהמכשיר המתאים
שואב כוח מהמקור. הפונקציונליות הבסיסית של מקור האנרגיה היא לספק
אנרגיה עבור התקנים על הצומת. כאשר האנרגיה מתנקזת לחלוטין ממקור האנרגיה,
זה מודיע למכשירים בצומת כך שכל מכשיר יכול להגיב לאירוע הזה. נוסף,
כל צומת יכול לגשת לאובייקטי מקור האנרגיה לקבלת מידע כגון אנרגיה שנותרה או
שבר אנרגיה (רמת הסוללה). זה מאפשר יישום של פרוטוקולים מודעים לאנרגיה
ב-ns-3.

על מנת לדגמן מגוון רחב של ספקי כוח כגון סוללות, מקור האנרגיה חייב
להיות מסוגל ללכוד מאפיינים של אספקה ​​אלה. יש 2 חשובים
מאפיינים או אפקטים הקשורים לסוללות מעשיות:

ציון קיבולת השפעה
ירידה באורך חיי הסוללה כאשר צריכת הזרם גבוהה מהערך המדורג
של הסוללה.

התאוששות השפעה
הגדלת חיי הסוללה כאשר הסוללה עוברת לסירוגין בין פריקה ל
מצבי סרק.

על מנת לשלב את אפקט קיבולת הקצב, מקור האנרגיה משתמש בהוצאת זרם מ
כל המכשירים באותו צומת כדי לחשב את צריכת האנרגיה. יתר על כן, מרובה
ניתן לחבר קוצרי אנרגיה למקור האנרגיה על מנת לחדש את האנרגיה שלו.
מקור האנרגיה סוקר מעת לעת את כל המכשירים וקוצרי האנרגיה באותו אופן
צומת כדי לחשב את סך הניקוז הנוכחי ומכאן את צריכת האנרגיה. כאשר מכשיר
משנה מצב, מודל האנרגיה התואם שלו יודיע על כך למקור האנרגיה
יחושבו שינוי והגרלה הנוכחית הכוללת החדשה. באופן דומה, כל קציר אנרג'י
עדכון מפעיל עדכון למקור האנרגיה המחובר.

מחלקת הבסיס של מקור אנרגיה שומרת רשימה של מכשירים (אובייקטי מודל אנרגטי של מכשירים) ו
קוצרי אנרגיה (חפצי קציר אנרג'י) המשתמשים במקור האנרגיה המסוים
כספק כוח. כאשר האנרגיה מתרוקנת לחלוטין, מקור האנרגיה יודיע לכולם
מכשירים ברשימה זו. כל מכשיר יכול אז לטפל באירוע זה באופן עצמאי, בהתבסס על
התנהגות רצויה שיש לעקוב אחריה במקרה של הפסקת חשמל.

מכשיר אנרגיה מספר סימוכין
מודל האנרגיה של המכשיר הוא מודל צריכת האנרגיה של התקן המותקן על הצומת.
זה מתוכנן להיות דגם מבוסס מדינה שבו מניחים שלכל מכשיר יש מספר של
מצבים, וכל מצב משויך לערך צריכת חשמל. בכל פעם שהמצב של
אם המכשיר משתנה, דגם האנרגיה המתאים יודיע למקור האנרגיה על
ההגרלה הנוכחית החדשה של המכשיר. לאחר מכן, מקור האנרגיה יחשב את הסכום החדש
לצייר נוכחי ולעדכן את האנרגיה שנותרה.

ניתן להשתמש במודל האנרגיה של המכשיר גם עבור מכשירים שאין להם מספר סופי של
מדינות. לדוגמה, ברכב חשמלי נקבעת יציאת הזרם של המנוע
לפי המהירות שלו. מכיוון שמהירות הרכב יכולה לקבל ערכים רציפים בטווח מסוים,
זה בלתי אפשרי להגדיר קבוצה של מצבי פעולה נפרדים. עם זאת, על ידי המרה
את ערך המהירות לזרם ישירות, אותה קבוצה של ממשקי API של מודל אנרגיה של מכשיר עדיין יכולה
לשמש.

אנרגיה מקצרה
קוצר האנרגיה מייצג את היסודות הקוצרים אנרגיה מהסביבה ו
להטעין את מקור האנרגיה אליו הוא מחובר. קוצר האנרגיה כולל את
יישום מלא של מכשיר קצירת האנרגיה בפועל (למשל, פאנל סולארי) ו
הסביבה (למשל, קרינת השמש). זה אומר שביישום אנרגיה
הקוצר, תרומת האנרגיה של הסביבה והאנרגיה הנוספת
הדרישות של מכשיר קצירת האנרגיה כגון יעילות ההמרה וה
יש לעצב במשותף את צריכת החשמל הפנימית של המכשיר.

וויי - פיי רדיו אנרגיה מספר סימוכין
דגם ה-WiFi Radio Energy הוא מודל צריכת האנרגיה של מכשיר Wifi Net. זה
מספק מצב עבור כל אחד מהמצבים הזמינים של שכבת PHY: Idle, CcaBusy, Tx, Rx,
מתג ערוצים, שינה. כל אחת ממצבים כאלה קשורה לערך (באמפר) של
הגרלה נוכחית (ראה להלן לשמות המאפיינים המתאימים). דגם Wifi Radio Energy
PHY Listener רשום ל-Wifi PHY כדי לקבל הודעה על כל מצב Wifi PHY
מַעֲבָר. בכל מעבר, האנרגיה שנצרכה במצב הקודם מחושבת ו
מקור האנרגיה מקבל הודעה על מנת לעדכן את האנרגיה שנותרה שלו.

מודל ה-Wifi Tx Current נותן את האפשרות לחשב את המשיכה הנוכחית ב-
מצב שידור כפונקציה של הספק tx הנומינלי (ב-dBm), כפי שנצפה במספר
מדידות ניסיוניות. לשם כך, ה-Wifi Radio Energy Model PHY Listener הוא
מודיע על הספק ה-TX הנומינלי המשמש להעברת המסגרת הנוכחית ומעביר כזה
ערך ל-Wifi Tx Current Model שדואג לעדכן את המשיכה הנוכחית ב-Tx
מדינה. לפיכך, צריכת האנרגיה מחושבת כראוי גם אם תחנת Wifi Remote
המנהל מבצע בקרת כוח לכל מסגרת. נכון לעכשיו, דגם Linear Wifi Tx Current הוא
מיושם אשר מחשב את זרם tx כפונקציה לינארית (לפי פרמטרים
שניתן לציין על ידי המשתמש) של הספק tx נומינלי ב-dBm.

דגם ה-Wifi Radio Energy מציע את האפשרות לציין התקשרות חוזרת המופעלת
כאשר מקור האנרגיה מתרוקן. אם התקשרות חזרה כזו לא צוין כאשר ה- Wifi
Radio Energy Model Helper משמש להתקנת הדגם במכשיר, התקשרות חוזרת היא
נוצר באופן מרומז כך שה-Wifi PHY יוכנס למצב SLEEP (ולכן אין מסגרת
משודר או מתקבל לאחר מכן) כאשר מקור האנרגיה מתרוקן. כך גם כן
ניתן לציין התקשרות חוזרת המופעלת כאשר מקור האנרגיה נטען מחדש (אשר
עלול להתרחש במקרה שקוצר אנרגיה מחובר למקור האנרגיה). אם כזה
התקשרות חוזרת אינה מצוינת כאשר משתמשים ב-Wifi Radio Energy Model Helper להתקנת
דגם במכשיר, התקשרות חוזרת מתבצעת באופן מרומז כך שה-Wifi PHY מחודש מה-
מצב שינה כאשר מקור האנרגיה נטען מחדש.

שלנו תיק עבודות
עבור מודלים של אנרגיה של מכשירים, אנו מתכננים לכלול תמיכה בדגמי שכבת PHY אחרים
מסופק ב-ns-3 כגון WiMAX, וכדי לדגמן את צריכת האנרגיה של אחרים שאינם
התקני תקשורת, כמו חיישן גנרי ומעבד. עבור מקורות אנרגיה, אנחנו
מתכננים לכלול סוגים חדשים של מקורות אנרגיה כגון קבל-על וניקל-מתכת
סוללת הידריד (Ni-MH). עבור קוצרי האנרגיה, אנו מתכננים ליישם אנרגיה
קוצר המטעין את מקורות האנרגיה בהתאם לרמות ההספק המוגדרות בא
מערך נתונים שניתן להתאמה אישית של משתמשים של מדידות אמיתיות.

הפניות
[1] מודל אנרגטי ns-2:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Docs/Manuel-NS2/node204.html

[2] H. Wu, S. Nabar and R. Poovendran. מסגרת אנרגיה עבור סימולטור הרשת 3
(ns-3).

[3] מ' הנדי וד' טימרמן. סימולציה של רשתות אלחוטיות ניידות עם מדויק
מודלים של אפקטי סוללה לא ליניאריים. ב-Proc. של סימולציה יישומית ומידול
(ASM), 2003.

[4] ד"נ רחמטוב וס"ב ורודולה. מודל סוללה אנליטי ברמה גבוהה לשימוש ב
ניהול אנרגיה של מערכות אלקטרוניות ניידות. ב-Proc. של IEEE/ACM International
כנס לעיצוב בעזרת מחשב (ICCAD'01), עמודים 488-493, נובמבר 2001.

[5] ד"נ רחמטוב, ס"ב ורודולה, וד"א וולך. חיזוי חיי סוללה עבור
מחשוב מודע לאנרגיה. ב-Proc. של הסימפוזיון הבינלאומי לשנת 2002 על כוח נמוך
אלקטרוניקה ועיצוב (ISLPED'02), עמודים 154-159, 2002.

[6] C. Tapparello, H. Ayatollahi and W. Heinzelman. הרחבת מסגרת האנרגיה עבור
סימולטור רשת 3 (ns-3). סדנה בנושא ns-3 (WNS3), סשן פוסטרים, אטלנטה, GA,
ארה"ב. מאי, 2014.

נוֹהָג
הדרך העיקרית שבה משתמשי ns-3 יתקשרו בדרך כלל עם ה-Energy Framework היא דרך
ה-API של העזר ודרך התכונות הגלויות לציבור של המסגרת. העוזר
API מוגדר ב src/energy/helper/*.h.

על מנת להשתמש במסגרת האנרגיה, על המשתמש להתקין מקור אנרגיה עבור הצומת
לעניין, דגם האנרגיה המתאים עבור התקני הרשת ואם
הכרחי, ה-Energy Harvester אחד או יותר. מקור האנרגיה (אובייקטים) מצטברים
כל צומת על ידי עוזר מקור האנרגיה. על מנת לאפשר מספר מקורות אנרגיה לכל צומת,
אנו צוברים מיכל מקור אנרגיה במקום לצבור ישירות אובייקט מקור.

אובייקט מקור האנרגיה שומר רשימה של אובייקטים של מודל אנרגטי של מכשיר ו-Energy Harvester
שימוש במקור כספק כוח. אובייקטים של דגם אנרגטי התקן מותקנים על גבי
מקור אנרגיה על ידי ה-Device Energy Model Helper, בעוד אובייקט Energy Harvester הם
הותקן על ידי ה-Energy Harvester Helper. המשתמש יכול לגשת לאובייקטים של Device Energy Model
באמצעות אובייקט מקור האנרגיה כדי לקבל מידע על צריכת אנרגיה של אדם
מכשירים. יתר על כן, המשתמש יכול לגשת לאובייקטים של Energy Harvester על מנת לאסוף
מידע לגבי ההספק הנוכחי הניתן לקציר וסך האנרגיה שנקטפה על ידי
מַקצֵרָה.

דוגמאות
הספריות לדוגמה, src/examples/energy ו דוגמאות/אנרגיה, מכילים קוד בסיסי כלשהו
שמראה כיצד להגדיר את המסגרת.

עוזרים
אנרגיה מָקוֹר עוֹזֵר
מחלקת עוזר בסיס עבור אובייקטים של מקור אנרגיה, אובייקט עוזר זה מצטבר אובייקט מקור אנרגיה
על צומת. יישום צאצא של מחלקה זו יוצר את אובייקט מקור האנרגיה בפועל.

מכשיר אנרגיה מספר סימוכין עוֹזֵר
כיתת עוזר בסיס עבור אובייקטים של Device Energy Model, עוזר זה מצרף את Device Energy
דגם אובייקטים על אובייקטים של מקור אנרגיה. יישום ילד של מחלקה זו יוצר את
אובייקט מודל אנרגטי של המכשיר בפועל.

אנרגיה קְצִיר עוֹזֵר
כיתת עוזר בסיס עבור חפצי Energy Harvester, עוזר זה מצרף את Energy Harvester
אובייקטים על אובייקטים של מקור אנרגיה. יישום ילד של מחלקה זו יוצר את המציאות
אובייקט קציר אנרג'י.

תכונות
התכונות שונות בין מקורות אנרגיה, מודלים של אנרגיה של מכשירים וקצירי אנרגיה
יישומים, אנא עיין בכיתת הילד הספציפית לפרטים.

בסיסי אנרגיה מָקוֹר
· BasicEnergySourceInitialEnergyJ: אנרגיה ראשונית המאוחסנת במקור אנרגיה בסיסי.

· BasicEnergySupplyVoltageV: מתח אספקה ​​ראשוני למקור אנרגיה בסיסי.

· PeriodicEnergyUpdateInterval: זמן בין שני עדכוני אנרגיה תקופתיים רצופים.

RV סוֹלְלָה מספר סימוכין
· RvBatteryModelPeriodicEnergyUpdateInterval: מרווח דגימה של דגם סוללת RV.

· RvBatteryModelOpenCircuitVoltage: מתח מעגל פתוח דגם סוללת RV.

· RvBatteryModelCutoffVoltage: מתח חיתוך דגם סוללת RV.

· RvBatteryModelAlphaValue: ערך אלפא דגם סוללת קרוואנים.

· RvBatteryModelBetaValue: ערך בטא של דגם סוללת קרוואנים.

· RvBatteryModelNumOfTerms: מספר האיברים של הסכום האינסופי להערכת הסוללה
רָמָה.

וויי - פיי רדיו אנרגיה מספר סימוכין
· IdleCurrentA: ברירת המחדל של זרם הרדיו במצב סרק באמפר.

· CcaBusyCurrentA: ברירת המחדל של הרדיו CCA Busy State הנוכחי באמפר.

· TxCurrentA: זרם הרדיו Tx באמפר.

· RxCurrentA: זרם הרדיו Rx באמפר.

· SwitchingCurrentA: ברירת המחדל של החלפת ערוץ הרדיו באמפר.

· SleepCurrentA: הרדיו זרם שינה באמפר.

· TxCurrentModel: מצביע למודל הנוכחי tx המצורף.

בסיסי אנרגיה מקצרה
· PeriodicHarvestedPowerUpdateInterval: זמן בין שני עדכונים תקופתיים רצופים של
הכוח שנקטף.

· HarvestablePower: משתנים אקראיים המייצגים את כמות ההספק שסופק
על ידי קוצר האנרגיה.

מעקב
ערכי המעקב נבדלים בין מקורות אנרגיה, מודלים של אנרגיה של מכשירים וקצירי אנרגיה
יישומים, אנא עיין בכיתת הילד הספציפית לפרטים.

בסיסי אנרגיה מָקוֹר
· אנרגיה שנותרה: אנרגיה שנותרה ב-BasicEnergySource.

RV סוֹלְלָה מספר סימוכין
· RvBatteryModelBatteryLevel: רמת הסוללה של דגם RV.

· RvBatteryModelBatteryLifetime: חיי סוללה מדגם RV.

וויי - פיי רדיו אנרגיה מספר סימוכין
· צריכת אנרגיה כוללת: צריכת אנרגיה כוללת של מכשיר הרדיו.

בסיסי אנרגיה מקצרה
· HarvestedPower: כוח נוכחי מסופק על ידי BasicEnergyHarvester.

· TotalEnergyHarvested: סך האנרגיה שנקטפה על ידי BasicEnergyHarvester.

בדיקת מערכות
לא בוצעה השוואה בין מסגרת האנרגיה למכשירים בפועל. נוֹכְחִי
יישום מסגרת האנרגיה נבדק מספרית לאיתור שגיאות חישוב. ה
דגם סוללת RV מאומת על ידי השוואת תוצאות למה שהוצג במקור
נייר דגם סוללת קרוואנים.

FLOW מוניטור

מספר סימוכין תיאור
קוד המקור של המודול החדש נמצא בספרייה src/flow-monitor.

מטרת מודול מוניטור הזרימה היא לספק מערכת גמישה למדידת הביצועים שלה
פרוטוקולי רשת. המודול משתמש בבדיקות, המותקנות בצמתי רשת, כדי לעקוב אחר
מנות שהוחלפו על ידי הצמתים, וזה ימדוד מספר פרמטרים. מנות הן
מחולקים לפי הזרימה אליה הם שייכים, כאשר כל זרימה מוגדרת לפי ה
המאפיינים של בדיקה (למשל, עבור IP, זרימה מוגדרת כמנות עם אותו
{פרוטוקול, מקור (IP, יציאה), יעד (IP, יציאה)} טופל.

הנתונים הסטטיסטיים נאספים עבור כל זרימה ניתן לייצא בפורמט XML. יתר על כן, ה
המשתמש יכול לגשת ישירות לבדיקות כדי לבקש נתונים סטטיסטיים ספציפיים לגבי כל זרימה.

עיצוב
מודול מוניטור זרימה מתוכנן בצורה מודולרית. ניתן להרחיב אותו על ידי סיווג משנה
ns3::FlowProbe ו ns3::FlowClassifier.

עיצוב המודול המלא מתואר ב-[FlowMonitor]

היקף ו מגבלות
כרגע, בדיקות ומסווגים זמינים עבור IPv4 ו- IPv6.

כל בדיקה תסווג מנות בארבע נקודות:

· כאשר מנות נשלחת (SendOutgoing IPv[4,6] עקבות)

· כאשר מנות מועברת (מעקבות IPv[4,6] של UnicastForward)

· כאשר מנות מתקבלת (עקבות IPv[4,6] של LocalDeliver)

· כאשר מנות נפלטה (הורד עקבות IPv[4,6])

מכיוון שהמנות נמצאות במעקב ברמת IP, כל שידור חוזר שנגרם על ידי פרוטוקולי L4
(למשל, TCP) ייראה על ידי הבדיקה כחבילה חדשה.

תג יתווסף לחבילה (ns3::Ipv[4,6]FlowProbeTag). התג יישא בסיסי
נתוני החבילה, שימושיים לסיווג החבילה.

יש להדגיש שרק מנות L4 (TCP, UDP) מסווגות, עד כה. יתר על כך,
רק חבילות unicast יסווגו. ייתכן שהמגבלות הללו יוסרו בעתיד.

הנתונים שנאספו עבור כל זרימה הם:

· timeFirstTxPacket: כאשר החבילה הראשונה בזרימה שודרה;

· timeLastTxPacket: כאשר החבילה האחרונה בזרימה שודרה;

· timeFirstRxPacket: כאשר החבילה הראשונה בזרימה התקבלה על ידי צומת קצה;

· timeLastRxPacket: כאשר החבילה האחרונה בזרימה התקבלה;

· delaySum: סכום כל העיכובים מקצה לקצה עבור כל החבילות שהתקבלו בזרימה;

· jitterSum: הסכום של כל ערכי ריצוד השהיה מקצה לקצה (וריאציה של השהיה) עבור כולם
קיבלו מנות של הזרימה, כהגדרתה ב RFC 3393;

· txBytes, txPackets: המספר הכולל של בתים/מנות משודרים עבור הזרימה;

· rxBytes, rxPackets: המספר הכולל של בתים/מנות שהתקבלו עבור הזרימה;

· חבילות אבודות: המספר הכולל של חבילות שיש להניח שהן אבדו (לא דווח על יותר מ-10
שניות);

· timesForwarded: מספר הפעמים שבהן דווח כי חבילה הועברה;

· delayHistogram, jitterHistogram, packetSizeHistogram: גרסאות היסטוגרמה עבור ההשהיה,
ריצוד וגדלים של מנות, בהתאמה;

· packetsDropped, bytesDropped: מספר החבילות והבתים שאבדו, מחולק לפי
קוד הסיבה לאובדן (מוגדר בבדיקה).

ראוי לציין שהבדיקות מודדות את בתים של החבילות כולל כותרות IP.
כותרות L2 אינן כלולות במדד.

נתונים סטטיסטיים אלה ייכתבו בצורת XML לפי בקשה (ראה סעיף שימוש).

הפניות
[FlowMonitor]

G. Carneiro, P. Fortuna, and M. Ricardo. 2009. FlowMonitor: מסגרת ניטור רשת
עבור סימולטור הרשת 3 (NS-3). בהליכים של ה-ICST הבינלאומי הרביעי
כנס על מתודולוגיות וכלים להערכת ביצועים (VALUETOOLS '09).
http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493

נוֹהָג
השימוש במודול הוא פשוט ביותר. העוזר ידאג לכל דבר.

השימוש האופייני הוא:

// צג זרימה
Ptr flowMonitor;
FlowMonitorHelper flowHelper;
flowMonitor = flowHelper.InstallAll();

סימולטור::Stop (Seconds(stop_time));
סימולטור::Run ();

flowMonitor->SerializeToXmlFile("NameOfFile.xml", true, true);

מה היא SerializeToXmlFile () פונקציה 2 ו-3 פרמטרים משמשים בהתאמה
הפעל/השבת את ההיסטוגרמות ואת הנתונים הסטטיסטיים המפורטים לכל בדיקה.

ניתן למצוא חלופות אפשריות נוספות בתיעוד Doxygen.

עוזרים
ממשק ה-API של עוזר עוקב אחר השימוש בדפוסים של עוזרים רגילים. דרך העוזר אתה יכול
התקן את הצג בצמתים, הגדר את תכונות הצג והדפיס את הנתונים הסטטיסטיים.

דבר אחד חשוב הוא: ה ns3::FlowMonitorHelper חייב להיות מופע רק פעם אחת ב
רָאשִׁי.

תכונות
המודול מספק את התכונות הבאות ב ns3::FlowMonitor:

· MaxPerHopDelay (זמן, ברירת מחדל 10s): ההשהיה המקסימלית לכל הופ שיש לקחת בחשבון;

· StartTime (זמן, ברירת מחדל 0s): הזמן שבו הניטור מתחיל;

· DelayBinWidth (כפול, ברירת מחדל 0.001): הרוחב המשמש בהיסטוגרמת ההשהיה;

· JitterBinWidth (כפול, ברירת מחדל 0.001): הרוחב המשמש בהיסטוגרמת ריצוד;

· PacketSizeBinWidth (כפול, ברירת מחדל 20.0): הרוחב בשימוש בהיסטוגרמה של packetSize;

· FlowInterruptionsBinWidth (כפול, ברירת מחדל 0.25): הרוחב בשימוש ב-
היסטוגרמה של הפסקות זרימה;

· FlowInterruptionsMinTime (כפול, ברירת מחדל 0.5): זמן ההגעה המינימלי שהוא
נחשב להפרעה בזרימה.

תְפוּקָה
הפלט העיקרי של המודל הוא דוח בפורמט XML על סטטיסטיקות זרימה. דוגמה היא:




























הפלט נוצר על ידי זרימת TCP מ-10.1.3.1 עד 10.1.2.2.

כדאי לשים לב שהבדיקה של אינדקס 2 מדווחת על יותר מנות ויותר בתים מאשר
הבעיות האחרות. זו התנהגות נורמלית לחלוטין, שכן מנות מפוצלות ב-IP
רמה באותו צומת.

כמו כן יש לשים לב שהבדיקה של הצומת המקבל (אינדקס 4) אינה סופרת את
שברים, כאשר ההרכבה מחדש מתבצעת לפני נקודת הגישוש.

דוגמאות
הדוגמאות נמצאות ב src/flow-monitor/examples.

יתרה מכך, הדוגמאות הבאות משתמשות במודול מוניטור הזרימה:

· דוגמאות/מטריקס-טופולוגיה/מטריקס-טופולוגיה.cc

· examples/routing/manet-routing-compare.cc

· examples/routing/simple-global-routing.cc

· examples/tcp/tcp-variants-comparison.cc

· examples/wireless/multirate.cc

· examples/wireless/wifi-hidden-terminal.cc

פתרון בעיות
אין להגדיר יותר מאחד ns3::FlowMonitorHelper בסימולציה.

בדיקת מערכות
המאמר בהפניות מכיל תיאור מלא של אימות המודול כנגד א
רשת לבדוק.

בדיקות מסופקות כדי להבטיח את הפונקציונליות הנכונה של ההיסטוגרמה.

לאינטרנט מודלים

אינטרנט לערום
אינטרנט לערום - צבירה
כיתה חשופה צומת אינו שימושי במיוחד כפי שהוא; יש לצבור אליו אובייקטים אחרים
לספק פונקציונליות שימושית של צומת.

השמיים ns-3 ספריית קוד המקור src/אינטרנט מספק הטמעה של TCP/IPv4- ו
רכיבים הקשורים ל-IPv6. אלה כוללים IPv4, ARP, UDP, TCP, IPv6, Neighbor Discovery ו
פרוטוקולים קשורים אחרים.

צמתי אינטרנט אינם תת מחלקות של צומת class; הם פשוט צמתים שהיו להם א
חבורה של אובייקטים הקשורים ל-IP שנצברו אליהם. ניתן להרכיב אותם ביד, או באמצעות א
תפקוד עוזר InternetStackHelper::התקן () שעושה את הדברים הבאים לכל הצמתים
הועבר כטיעונים:

לבטל את
InternetStackHelper::Install (Ptr node) const
{
if (m_ipv4Enabled)
{
/* ערימת IPv4 */
if (צומת->GetObject () != 4)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): צבירת "
"InternetStack לצומת עם אובייקט Ipv4 קיים");
לחזור;
}

CreateAndAggregateObjectFromTypeId (צומת, "ns3::ArpL3Protocol");
CreateAndAggregateObjectFromTypeId (צומת, "ns3::Ipv4L3Protocol");
CreateAndAggregateObjectFromTypeId (צומת, "ns3::Icmpv4L4Protocol");
// הגדר ניתוב
Ptr ipv4 = node->GetObject ();
Ptr ipv4Routing = m_routing->Create (צומת);
ipv4->SetRoutingProtocol (ipv4Routing);
}

if (m_ipv6Enabled)
{
/* ערימת IPv6 */
if (צומת->GetObject () != 6)
{
NS_FATAL_ERROR ("InternetStackHelper::Install (): צבירת "
"InternetStack לצומת עם אובייקט Ipv6 קיים");
לחזור;
}

CreateAndAggregateObjectFromTypeId (צומת, "ns3::Ipv6L3Protocol");
CreateAndAggregateObjectFromTypeId (צומת, "ns3::Icmpv6L4Protocol");
// הגדר ניתוב
Ptr ipv6 = node->GetObject ();
Ptr ipv6Routing = m_routingv6->צור (צומת);
ipv6->SetRoutingProtocol (ipv6Routing);

/* רישום הרחבות ואפשרויות IPv6 */
ipv6->RegisterExtensions ();
ipv6->אפשרויות רישום ();
}

if (m_ipv4Enabled || m_ipv6Enabled)
{
/* ערימות UDP ו-TCP */
CreateAndAggregateObjectFromTypeId (צומת, "ns3::UdpL4Protocol");
node->AggregateObject (m_tcpFactory.Create ());
Ptr factory = CreateObject ();
node->AggregateObject (מפעל);
}
}

כאשר קיימים יישומים מרובים ב ns-3 (TCP, ניתוב IP), אובייקטים אלה מתווספים על ידי
אובייקט מפעל (TCP) או על ידי עוזר ניתוב (m_routing).

שים לב שפרוטוקול הניתוב מוגדר ומוגדר מחוץ לפונקציה זו. כברירת מחדל,
הפרוטוקולים הבאים מתווספים:

void InternetStackHelper::אתחול ()
{
SetTcp ("ns3::TcpL4Protocol");
Ipv4StaticRoutingHelper staticRouting;
Ipv4GlobalRoutingHelper globalRouting;
Ipv4ListRoutingHelper listRouting;
Ipv6ListRoutingHelper listRoutingv6;
Ipv6StaticRoutingHelper staticRoutingv6;
listRouting.Add (staticRouting, 0);
listRouting.Add (GlobalRouting, -10);
listRoutingv6.Add (staticRoutingv6, 0);
SetRoutingHelper (listRouting);
SetRoutingHelper (listRoutingv6);
}

כברירת מחדל, IPv4 ו-IPv6 מופעלים.

אינטרנט צומת מִבְנֶה
צומת בעל יכולת IP (an ns-3 צומת מוגדל על ידי צבירה כדי שיהיה לו ערימת IP אחת או יותר)
בעל המבנה הפנימי הבא.

שכבה-3 פרוטוקולים
בשכבה הנמוכה ביותר, היושבת מעל ה-NetDevices, נמצאים פרוטוקולי "שכבה 3", כולל
IPv4, IPv6, ARP וכן הלאה. הכיתה Ipv4L3 פרוטוקול הוא כיתת יישום אשר
הממשק הציבורי הוא בדרך כלל מחלקה Ipv4, אך נעשה שימוש גם ב-API הציבורי של Ipv4L3Protocol
פנימית כיום.

בכיתה Ipv4L3Protocol, שיטה אחת המתוארת להלן היא לְקַבֵּל ():

/ **
* השכבה התחתונה קוראת לשיטה זו לאחר קריאה ל-L3Demux::Lookup
* תת-מחלקת ה-ARP צריכה לדעת מאיזה NetDevice זה
*החבילה מגיעה ל:
* - הטמעת מטמון ARP לכל NetDevice
* - שלח בחזרה תשובות arp במכשיר הנכון
*/
void Receive( Ptr מכשיר, Ptr p, פרוטוקול uint16_t,
const כתובת &from, const כתובת &to, NetDevice::PacketType packetType);

ראשית, שימו לב ש לְקַבֵּל () לפונקציה יש חתימה תואמת ל-ReceiveCallback
בכיתה צומת. מצביע פונקציה זה מוכנס למטפל הפרוטוקול של הצומת כאשר
הוסף ממשק () נקרא. הרישום בפועל נעשה עם הצהרה כגון
התעופה

RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Receive, ipv4),
Ipv4L3Protocol::PROT_NUMBER, 0);

האובייקט Ipv4L3Protocol מצטבר ל-Node; יש רק Ipv4L3Protocol אחד כזה
לְהִתְנַגֵד. פרוטוקולים בשכבה גבוהה יותר שיש להם חבילה לשליחה אל Ipv4L3Protocol
אובייקט יכול לקרוא GetObject () כדי לקבל מצביע, באופן הבא:

Ptr ipv4 = m_node->GetObject ();
if (ipv4 != 0)
{
ipv4->שלח (מנות, saddr, daddr, PROT_NUMBER);
}

שיעור זה מדגים יפה שתי טכניקות שאנו מנצלים בהן ns-3 לאגד חפצים יחד:
התקשרויות חוזרות וצבירת אובייקטים.

ברגע שניתוב IPv4 קבע שחבילה מיועדת לצומת המקומי, הוא מעביר אותה למעלה
את הערימה. זה נעשה עם הפונקציה הבאה:

לבטל את
Ipv4L3Protocol::LocalDeliver (Ptr packet, Ipv4Header const&ip, uint32_t iif)

הצעד הראשון הוא למצוא את אובייקט Ipv4L4Protocol הנכון, בהתבסס על מספר פרוטוקול IP.
לדוגמה, TCP רשום ב-demux כפרוטוקול מספר 6. לבסוף, ה- לְקַבֵּל()
פונקציה בפרוטוקול Ipv4L4 (כגון TcpL4Protocol::Receive נקרא.

עדיין לא הצגנו את המחלקה 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, יישום ישתמש בקטע קוד כגון
הבא:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Bind (m_local_address);
...

האמור לעיל יבקש מהצומת לקבל מצביע למפעל שקע UDP שלו, יצור אחד
שקע כזה, וישתמש בשקע עם API דומה ל-API של שקעים מבוססי C, כגון
as לְחַבֵּר () ו שילחו (). הכתובת עברה ל- לאגד (), לְחַבֵּר (), או שילחו ()
פונקציות עשויות להיות א כתובת IPv4, כתובת IPv6, או כתובת. אם כתובת מועבר ב ו
מכיל כל דבר מלבד א כתובת IPv4 or כתובת IPv6, פונקציות אלו יחזירו an
שְׁגִיאָה. ה לאגד (בָּטֵל) ו לאגד 6 (בָּטֵל) פונקציות מתחברות ל-"0.0.0.0" ול-"::"
בהתאמה.

השקע יכול להיות קשור גם ל-NetDevice ספציפי BindToNetDevice
(Ptr מכשיר net) פונקציה. BindToNetDevice (Ptr מכשיר net) יתחייב
השקע ל-"0.0.0.0" ו-"::" (שווה ערך להתקשרות לאגד () ו לאגד 6 (), אלא אם כן ה
השקע כבר נקשר לכתובת ספציפית. לסיכום, הרצף הנכון
היא:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
...

או:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->Bind (m_local_address);
m_socket->BindToNetDevice (n_netDevice);
...

הדבר הבא מעלה שגיאה:

Ptr udpSocketFactory = GetNode ()->GetObject ();
Ptr m_socket = socketFactory->CreateSocket ();
m_socket->BindToNetDevice (n_netDevice);
m_socket->Bind (m_local_address);
...

ראה פרק ns-3 שקעים למידע נוסף.

תיארנו עד כה מפעל שקעים (למשל בכיתה Udp) ושקע, שיכול להיות
מתמחה (למשל, כיתה UdpSocket). ישנם עוד כמה אובייקטים מרכזיים הקשורים ל-
משימה מיוחדת של חלוקת חבילה לשקע קבלה אחד או יותר. המפתח
האובייקט במשימה זו הוא מחלקה Ipv4EndPointDemux. Demultiplexer זה מאחסן אובייקטים של
בכיתה Ipv4EndPoint. מחלקה זו מכילה את הכתובת/פורט tuple (יציאה מקומית, מקומית
כתובת, יציאת יעד, כתובת יעד) הקשורה לשקע וקבלה
התקשר חזרה. קבלה להתקשרות חוזרת זו כוללת פונקציית קבלה הרשומה על ידי השקע. ה
בדיקה () פונקציה ל-Ipv4EndPointDemux מחזירה רשימה של אובייקטי Ipv4EndPoint (ייתכן
להיות רשימה מכיוון שיותר משקע אחד עשוי להתאים לחבילה). עותקים של פרוטוקול שכבה-4
החבילה לכל Ipv4EndPoint וקוראת לה קדימה למעלה () שיטה, אשר לאחר מכן מכנה את
לְקַבֵּל () פונקציה שנרשמה על ידי השקע.

בעיה שמתעוררת כאשר עובדים עם ה-API של sockets על מערכות אמיתיות היא הצורך בכך
נהל את הקריאה משקע, באמצעות סוג כלשהו של קלט/פלט (למשל, חסימה, לא חסימה,
אסינכרוני, ...). ns-3 מיישמת מודל אסינכרוני עבור שקע I/O; היישום
מגדיר התקשרות חוזרת לקבל הודעה על נתונים שהתקבלו מוכנים לקריאה, וההתקשרות חזרה היא
מופעל על ידי פרוטוקול התחבורה כאשר נתונים זמינים. התקשרות חוזרת זו מוגדרת כ
התעופה

void Socket::SetRecvCallback (התקשרות חוזרת ,
Ptr ,
const Address&> receiveData);

הנתונים המתקבלים מועברים במאגר נתוני המנות. שימוש לדוגמה הוא ב
בכיתה PacketSink:

m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, זה));

לסיכום, באופן פנימי, יישום UDP מאורגן באופן הבא:

· א UdpImpl מחלקה המיישמת את פונקציונליות המפעל של שקע UDP

· א UdpL4 פרוטוקול מחלקה המיישמת את לוגיקה של הפרוטוקול שאינה תלויה בשקעים

· א UdpSocketImpl מחלקה המיישמת היבטים ספציפיים לשקעים של UDP

· כיתה בשם Ipv4EndPoint שמאחסן את הכתובת (יציאה מקומית, כתובת מקומית,
יציאת יעד, כתובת יעד) הקשורה לשקע וקבלה
התקשרות חוזרת עבור השקע.

בעל יכולת IP צומת ממשקים
רבים מפרטי היישום, או האובייקטים הפנימיים עצמם, של Node בעל יכולת IP
אובייקטים אינם נחשפים ב-API הציבורי של סימולטור. זה מאפשר שונה
יישומים; למשל, החלפת היליד ns-3 דגמים עם ערימת TCP/IP מועברת
קוד.

ממשקי ה-API הציבוריים של C++ של כל האובייקטים הללו נמצאים ב- src/רשת מַדרִיך,
כולל בעיקר:

· כתובת.ח

· socket.h

· node.h

· packet.h

אלו הם בדרך כלל אובייקטים של מחלקות בסיס שמיישמים את ערכי ברירת המחדל המשמשים ב-
יישום, הטמעת שיטות גישה כדי לקבל/להגדיר משתני מצב, תכונות מארח ו
ליישם שיטות זמינות לציבור שנחשפו ללקוחות כגון CreateSocket.

דוגמה נתיב of a מנות
שני האיורים הללו מציגים דוגמה למעקב אחר מחסנית של איך מנות זורמות דרך האינטרנט
אובייקטים של צומת.
[תמונה] שלח נתיב של חבילה..UNINDENT
[תמונה] נתיב קבלה של חבילה..UNINDENT

IPv4
מציין מיקום פרק

IPv6
פרק זה מתאר את ns-3 יכולות ומגבלות דגם IPv6 יחד עם זה
שימוש ודוגמאות.

IPv6 מודל תיאור
מודל ה-IPv6 מעוצב בצורה רופפת לאחר הטמעת לינוקס; היישום הוא
לא שלם מכיוון שחלק מהתכונות של IPv6 אינן מעניינות במיוחד מחקרי סימולציה, וכן
חלק מהתכונות של IPv6 פשוט לא עוצבו עדיין ns-3.

מעמד הבסיס Ipv6 מגדיר API גנרי, בעוד המחלקה Ipv6L3 פרוטוקול הוא הממשי
כיתה המיישמת את הפרוטוקול. המחלקות בפועל בשימוש מחסנית IPv6 ממוקמות
בעיקר בספרייה src/אינטרנט.

היישום של IPv6 כלול בקבצים הבאים:

src/internet/model/icmpv6-header.{cc,h}
src/internet/model/icmpv6-l4-protocol.{cc,h}
src/internet/model/ipv6.{cc,h}
src/internet/model/ipv6-address-generator.{cc,h}
src/internet/model/ipv6-autoconfigured-prefix.{cc,h}
src/internet/model/ipv6-end-point.{cc,h}
src/internet/model/ipv6-end-point-demux.{cc,h}
src/internet/model/ipv6-extension.{cc,h}
src/internet/model/ipv6-extension-demux.{cc,h}
src/internet/model/ipv6-extension-header.{cc,h}
src/internet/model/ipv6-header.{cc,h}
src/internet/model/ipv6-interface.{cc,h}
src/internet/model/ipv6-interface-address.{cc,h}
src/internet/model/ipv6-l3-protocol.{cc,h}
src/internet/model/ipv6-list-routing.{cc,h}
src/internet/model/ipv6-option.{cc,h}
src/internet/model/ipv6-option-demux.{cc,h}
src/internet/model/ipv6-option-header.{cc,h}
src/internet/model/ipv6-packet-info-tag.{cc,h}
src/internet/model/ipv6-pmtu-cache.{cc,h}
src/internet/model/ipv6-raw-socket-factory.{cc,h}
src/internet/model/ipv6-raw-socket-factory-impl.{cc,h}
src/internet/model/ipv6-raw-socket-impl.{cc,h}
src/internet/model/ipv6-route.{cc,h}
src/internet/model/ipv6-routing-protocol.{cc,h}
src/internet/model/ipv6-routing-table-entry.{cc,h}
src/internet/model/ipv6-static-routing.{cc,h}
src/internet/model/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-protocol, icmpv6-l4-protocol וכו')

· דגמי ניתוב (כלומר, כל דבר עם 'ניתוב' בשמו)

· שקעים וממשקים (למשל, ipv6-raw-socket, ipv6-interface, ipv6-end-point וכו')

· דברים הקשורים לכתובת

· כותרות, כותרות אפשרויות, כותרות של הרחבות וכו'.

· שיעורי אביזרים (למשל, ndisc-cache)

נוֹהָג
התיאור הבא מבוסס על שימוש בעוזרים האופייניים שנמצאים בקוד לדוגמה.

אין צורך להפעיל את IPv6 בצומת. הוא נוסף אוטומטית לזמין
פרוטוקולים לאחר התקנת ערימת האינטרנט.

על מנת לֹא להתקין IPv6 יחד עם IPv4, זה אפשרי להשתמש
ns3::InternetStackHelper שיטה SetIpv6StackInstall (בול לְאַפשֵׁר) לפני התקנת
InternetStack בצמתים.

שים לב שלצורך רשת IPv6 בלבד (כלומר, לא להתקין את ערימת ה-IPv4 בצומת)
צריך להשתמש ns3::InternetStackHelper שיטה SetIpv4StackInstall (בול לְאַפשֵׁר) לפני
התקנת מחסנית.

כדוגמה, בקוד הבא לצומת 0 יהיו גם IPv4 וגם IPv6, רק לצומת 1
IPv6 וצומת 2 בלבד IPv4:

NodeContainer n;
n.Create (3);

InternetStackHelper אינטרנט;
InternetStackHelper internetV4only;
InternetStackHelper internetV6only;

internetV4only.SetIpv6StackInstall (false);
internetV6only.SetIpv4StackInstall (false);

internet.Install (n.Get (0));
internetV6only.Install (n.Get (1));
internetV4only.Install (n.Get (2));

IPv6 כתובות משימה
על מנת להשתמש ב-IPv6 ברשת, הדבר הראשון שצריך לעשות הוא הקצאת כתובות IPv6.

כל IPv6 מאופשר ns-3 לצומת יהיה לפחות NetDevice אחד: ה ns3::LoopbackNetDevice.
כתובת התקן הלולאה היא :: 1. לכל שאר ה-NetDevices יהיה IPv6 אחד או יותר
כתובות:

· כתובת מקומית אחת של קישור: fe80::ממשק ID, שם ממשק ID נגזר מ-
כתובת MAC של NetDevice.

· אפס כתובות גלובליות או יותר, למשל, 2001: db8 :: 1.

בדרך כלל הכתובת הראשונה בממשק תהיה הכתובת הקישורית, עם הכתובת הגלובלית
הכתובות הן הבאות.

כתובות IPv6 גלובליות עשויות להיות:

· מוקצה באופן ידני

· מופעל אוטומטית

ns-3 יכול להשתמש בשתי השיטות, וזה די חשוב להבין את ההשלכות של
שניהם.

באופן ידני שהוקצה IPv6 כתובות
זו כנראה השיטה הקלה והשימושית ביותר. לדוגמא:

Ptr n0 = CreateObject ();
Ptr n1 = CreateObject ();
NodeContainer net (n0, n1);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("הקצה כתובות IPv6.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer ic = ipv6.Assign (ndc);

שיטה זו תוסיף שתי כתובות IPv6 גלובליות לצמתים. שימו לב שכרגיל עבור IPv6,
לכל הצמתים תהיה גם כתובת קישור מקומית. בדרך כלל הכתובת הראשונה ב-an
הממשק יהיה קישור מקומי, כאשר הכתובות הגלובליות יהיו הבאות
יחידות.

שימו לב שהכתובות הגלובליות ייגזרו מכתובת ה-MAC. כתוצאה מכך,
מצפה לקבל כתובות דומות ל 2001:db8::200:ff:fe00:1.

אפשר לחזור על האמור לעיל כדי להקצות יותר מכתובת גלובלית אחת לצומת.
עם זאת, בשל Ipv6AddressHelper טבע יחיד, צריך קודם להקצות את כל
כתובות של רשת, ואז שנה את בסיס הרשת (SetBase), ולאחר מכן בצע מטלה חדשה.

לחלופין, ניתן להקצות כתובת ספציפית לצומת:

Ptr n0 = CreateObject ();
NodeContainer net (n0);
CsmaHelper csma;
NetDeviceContainer ndc = csma.Install (net);

NS_LOG_INFO ("הקצה באופן ספציפי כתובת IPv6.");
Ipv6AddressHelper ipv6;
Ptr device = ndc.Get (0);
Ptr node = device->GetNode ();
Ptr ipv6proto = node->GetObject ();
int32_t ifIndex = 0;
ifIndex = ipv6proto->GetInterfaceForDevice (התקן);
Ipv6InterfaceAddress ipv6Addr = Ipv6InterfaceAddress (Ipv6Address ("2001:db8:f00d:cafe::42"), Ipv6Prefix (64));
ipv6proto->AddAddress (ifIndex, ipv6Addr);

מופעל אוטומטית IPv6 כתובות
זה מושג על ידי הסתמכות על פרוטוקול RADVD, המיושם על ידי המחלקה Radvd. ליד
הזמן שאין עוזר ליישום זה, והשימוש די קשה (ראה
examples/ipv6/radvd.cc).

בעת שימוש בשיטה זו, הצמתים ירכשו באופן דינמי (כלומר, במהלך הסימולציה)
כתובת גלובלית אחת (או יותר) בהתאם לתצורת RADVD. הכתובות האלה
יהיו בסיסים על הקידומת שהוכרזה על ידי RADVD ועל ה-EUI-64 של הצומת.

נוצר באקראי IPv6 כתובות
בעוד שצמתים אמיתיים של IPv6 ישתמשו בכתובות שנוצרו באופן אקראי כדי להגן על הפרטיות, ns-3 עושה
אין את היכולת הזו. תכונה זו לא נחשבה עד כה כמעניינת עבור
סימולציה.

לשכפל כתובת איתור (אַבָּא)
צמתים יבצעו DAD (ניתן לנטרל אותו באמצעות Icmpv6L4 פרוטוקול תְכוּנָה). עַל
עם זאת, קבלת DAD, צמתים לא יגיבו אליו. כפי שהוא: תגובת DAD אינה שלמה ולכן
רָחוֹק. הסיבה העיקרית מסתמכת על יכולת הכתובת החסרה שנוצרת אקראית. יתר על כך,
since ns-3 צמתים בדרך כלל יתנהגו היטב, לא אמורה להיות כתובת כפולה.
זה עשוי להשתנות בעתיד, כדי למנוע בעיות עם אינטגרציה בעולם האמיתי
סימולציות.

מארח ו נתב התנהגות in IPv6 ו ns-3
ב-IPv6 יש הבחנה ברורה בין נתבים ו מארחים. כפי שניתן לצפות,
נתבים יכולים להעביר מנות מממשק לממשק אחר, בזמן שהמארחים יורדים
חבילות שלא מופנות אליהם.

למרבה הצער, העברה אינה הדבר היחיד המושפע מההבחנה הזו, וכן
העברה עצמה עשויה להיות מכווננת, למשל, להעברת מנות הנכנסות מממשק
ושחרר מנות מממשק אחר.

In ns-3 צומת מוגדר להיות an המארח כברירת מחדל. יש שתי דרכים עיקריות לשינוי
ההתנהגות הזו:

· שימוש ns3::Ipv6InterfaceContainer SetForwarding(uint32_t i, bool נתב) איפה i האם ה
אינדקס ממשק במיכל.

· שינוי ה ns3::Ipv6 תכונה IPForward.

בכל אחד מהם ניתן להשתמש במהלך הסימולציה.

ניתן להשיג הגדרה עדינה באמצעות שימוש ns3::Ipv6 ממשק SetForwarding (בול
קָדִימָה); מה שמאפשר לשנות את ההתנהגות על בסיס ממשק.

שימו לב שהתצורה של כל הצומת משמשת רק כשיטה נוחה להפעלה/השבתה
מה היא ns3::Ipv6 ממשק הגדרה ספציפית. ממשק Ipv6 נוסף לצומת עם העברה
מופעל יוגדר להעברה גם כן. זה באמת חשוב כאשר יש לצומת
ממשקים שנוספו במהלך הסימולציה.

על פי ns3::Ipv6 ממשק מצב העברה, קורה את הדברים הבאים:

· העברה כבויה

· הצומת לא יענה ל-Router Solicitation

· הצומת יגיב לפרסומת הנתב

· הצומת ישלח מעת לעת שידול לנתב

· פרוטוקולי ניתוב חייבים לשחרר מנות שאינן מכוונות לצומת

· העברה פועלת

· הצומת יענה ל-Router Solicitation

· הצומת לא יגיב לפרסום בנתב

· הצומת לא ישלח שידול לנתב

· פרוטוקולי ניתוב חייבים להעביר מנות

ההתנהגות תואמת את 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;
n.Create (4);

NS_LOG_INFO ("צור ערימת אינטרנט IPv6");
InternetStackHelper internetv6;
internetv6.Install (n);

NS_LOG_INFO ("צור ערוצים.");
CsmaHelper csma;
NetDeviceContainer d = csma.Install (n);

NS_LOG_INFO ("צור רשתות והקצה כתובות IPv6.");
Ipv6AddressHelper ipv6;
ipv6.SetBase (Ipv6Address ("2001:db8::"), Ipv6Prefix (64));
Ipv6InterfaceContainer iic = ipv6.Assign (d);

בנוסף, משימה נפוצה היא לאפשר העברה באחד הצמתים ולהגדיר א
מסלול ברירת המחדל אליו בצמתים האחרים, למשל:

iic.SetForwarding (0, נכון);
iic.SetDefaultRouteInAllNodes (0);

זה יאפשר העברה בצומת 0 ויגדיר מסלול ברירת מחדל ב
ns3::Ipv6StaticRouting בכל שאר הצמתים. שימו לב שזה דורש את זה
Ipv6StaticRouting קיים בצמתים.

עוזרי ניתוב IPv6 מאפשרים למשתמש לבצע משימות ספציפיות בפרט
אלגורית ניתוב והדפסת טבלאות הניתוב.

תכונות
שיעורים רבים ב ns-3 יישום IPv6 מכיל תכונות. השימושיים ביותר הם:

· ns3::Ipv6

· IPForward, בוליאני, ברירת מחדל false. הפעל או השבת את העברת ה-IP באופן גלובלי עבור כולם
התקני IPv6 נוכחיים ועתידיים.

· MtuDiscover, בוליאני, ברירת מחדל נכון. אם מושבת, לכל ממשק יהיה MTU שלו
מוגדר ל-1280 בתים.

· ns3::Ipv6L3Protocol

· DefaultTtl, uint8_t, ברירת מחדל 64. ערך ה-TTL שהוגדר כברירת מחדל בכל החבילות היוצאות
נוצר בצומת זה.

· SendIcmpv6Redirect, בוליאני, ברירת מחדל נכון. שלח את ההפניה מחדש של ICMPv6 כאשר מתאים.

· ns3::Icmpv6L4Protocol

· אַבָּא, בוליאני, ברירת מחדל נכון. בצע תמיד בדיקת DAD (זיהוי כתובות כפולות).

· ns3::NdiscCache

· UnresolvedQueueSize, uint32_t, ברירת מחדל 3. גודל התור למנות הממתינות ל-NA
תשובה.

תְפוּקָה
ערימת ה-IPv6 מספקת כמה מקורות מעקב שימושיים:

· ns3::Ipv6L3Protocol

· Tx, שלח חבילת IPv6 לממשק היוצא.

· Rx, קבל מנות IPv6 מממשק נכנס.

· ירידה, זרוק חבילת IPv6.

· ns3::Ipv6Extension

· ירידה, זרוק חבילת IPv6.

מקור המעקב האחרון נוצר כאשר חבילה מכילה אפשרות לא ידועה החוסמת אותה
מעבד.

תתחשב בזה ns3::NdiscCache יכול להפיל גם מנות, והן אינן מחוברות למעקב
מקור (עדיין). זה עלול ליצור קצת בלבול במוני החבילות שנשלחו/התקבלו.

מתקדם נוֹהָג
IPv6 מקסימום תמסורת יחידה (MTU) ו התנפצות
ns-3 NetDevices מגדירים את ה-MTU לפי ההתקן המדומה L2. IPv6 דורש את זה
ה-MTU המינימלי הוא 1280 בתים, כך שכל מכשירי NetDevices נדרשים לתמוך לפחות בזה
MTU. זה הקישור-MTU.

על מנת לתמוך ב-MTUs שונים בנתיב מקור-יעד, ns-3 דגם IPv6 יכול
לבצע פיצול. זה יכול להיות מופעל על ידי קבלת חבילה גדולה יותר מה-
link-MTU מפרוטוקולי L4 (UDP, TCP וכו'), או על ידי קבלת ICMPv6 PACKET_TOO_BIG
הוֹדָעָה. הדגם מחקה את RFC 1981, עם החריגים הבולטים הבאים:

· פרוטוקולי L4 אינם מעודכנים על השינוי ב-Path MTU

· TCP לא יכול לשנות את גודל הפלח שלו בהתאם ל-Path-MTU.

שתי המגבלות יוסרו בבוא העת.

מטמון ה-Path-MTU מבוסס כרגע על כתובות ה-IPv6 של יעד המקור. נוסף
סיווגים (למשל, תווית זרימה) אפשריים אך עדיין לא יושמו.

זמן תוקף ברירת המחדל של Path-MTU הוא 10 דקות. לאחר פקיעת כניסת המטמון, ה-
מידע Path-MTU מוסר והחבילה הבאה תפעיל (בסופו של דבר) ICMPv6 חדש
הודעה PACKET_TOO_BIG. שימו לב ש-1) זה תואם את מפרט ה-RFC ו-2)
פרוטוקולי L4 אחראים לשידור מחדש של החבילות.

דוגמאות
הדוגמאות עבור IPv6 נמצאות בספרייה דוגמאות/ipv6. דוגמאות אלה מתמקדות ביותר
מוזרויות IPv6 מעניינות, כגון פיצול, הפניה מחדש וכן הלאה.

יתר על כן, רוב דוגמאות ה-TCP וה-UDP נמצאות ב דוגמאות/udp, דוגמאות/tcpוכו' יש א
אפשרות שורת הפקודה להשתמש ב-IPv6 במקום ב-IPv4.

פתרון בעיות
יש רק כמה מלכודות שכדאי להימנע מהשימוש ns-3 IPv6.

ניתוב לולאות
מכיוון שסכימת הניתוב היחידה (בינתיים) הזמינה עבור IPv6 היא ns3::Ipv6StaticRouting,
יש להגדיר את הנתב המוגדר כברירת מחדל באופן ידני. כאשר ישנם שני נתבים או יותר ברשת
(למשל, צומת A וצומת B), הימנע משימוש בפונקציית העזר SetDefaultRouteInAllNodes ל
יותר מנתב אחד.

התוצאה תהיה התקנת מסלול ברירת מחדל ל-B ב-A והצבעת מסלול ברירת מחדל
ל-A ב-B, יצירת לולאה.

גלוֹבָּלִי כתובת דליפה
זכור שכתובות ב-IPv6 הן גלוֹבָּלִי לפי הגדרה. בעת שימוש ב-IPv6 עם an
אמולציה ns-3 יכולת, הימנעו בכל מחיר מדליפת כתובות לעבר האינטרנט העולמי.
רצוי להגדיר חומת אש חיצונית כדי למנוע דליפה.

2001:DB8::/32 כתובות
תקן IPv6 (RFC 3849) מגדיר את 2001:DB8::/32 כיתת כתובת עבור תיעוד.
מדריך זה משתמש במוסכמה זו. עם זאת, הכתובות במחלקה זו ניתנות לשימוש רק ב
מסמך, והנתבים צריכים להשליך אותם.

בדיקת מערכות
פרוטוקולי ה-IPv6 עדיין לא עברו תיקוף נרחב כנגד יישומים אמיתיים.
הבדיקות בפועל כוללות בעיקר ביצוע בדיקות של קובצי המעקב ב-.pcap עם Wireshark,
והתוצאות חיוביות.

ניתוב סקירה
ns-3 נועד לתמוך בגישות ובפרוטוקולים ניתוב מסורתיים, תמיכה ביציאות של
יישומי ניתוב בקוד פתוח, והקל על מחקר על ניתוב לא שגרתי
טכניקות. ארכיטקטורת הניתוב הכוללת מתוארת להלן ב ניתוב ארכיטקטורה.
משתמשים שרוצים פשוט לקרוא כיצד להגדיר ניתוב גלובלי עבור טופולוגיות קוויות יכולים
לקרוא גלוֹבָּלִי מְרוּכָּז ניתוב. פרוטוקולי ניתוב Unicast מתוארים ב Unicast
ניתוב. ניתוב ריבוי שידור מתועד ב שידור לקבוצה ניתוב.

ניתוב ארכיטקטורה
[תמונה] סקירה כללית של routing.UNINDENT

סקירה כללית of ניתוב מציג את ארכיטקטורת הניתוב הכוללת עבור Ipv4. האובייקטים המרכזיים הם
Ipv4L3Protocol, Ipv4RoutingProtocol(s) (מחלקה שאליה בוצע כל הניתוב/העברה
האצלה מ-Ipv4L3Protocol), ו-Ipv4Route(s).

ל-Ipv4L3Protocol חייב להוסיף לפחות Ipv4RoutingProtocol אחד בסימולציה
זמן ההגדרה. זה נעשה במפורש על ידי קריאה ל-Ipv4::SetRoutingProtocol ().

מחלקת הבסיס המופשטת Ipv4RoutingProtocol () מכריזה על ממשק מינימלי, המורכב
של שתי שיטות: RouteOutput () ו-RouteInput (). עבור חבילות שנוסעות החוצה
מארח, פרוטוקול התחבורה ישאל את Ipv4 עבור אובייקט Ipv4RoutingProtocol
ממשק, ויבקש נתיב דרך Ipv4RoutingProtocol::RouteOutput (). A Ptr to
אובייקט Ipv4Route מוחזר. זה מקביל לערך dst_cache בלינוקס. ה
Ipv4Route מועבר אל Ipv4L3Protocol כדי למנוע חיפוש שני שם. למרות זאת,
במקרים מסוימים (למשל שקעי Ipv4 raw) ידרשו קריאה ל-RouteOutput() ישירות מ-
Ipv4L3 פרוטוקול.

עבור מנות שהתקבלו נכנסות לצורך העברה או משלוח, השלבים הבאים מתרחשים.
Ipv4L3Protocol::Receive() קורא ל-Ipv4RoutingProtocol::RouteInput(). זה עובר את
בעלות על מנות לאובייקט Ipv4RoutingProtocol. ישנן ארבע התקשרויות משויכות
עם השיחה הזו:

· LocalDeliver

· UnicastForward

· MulticastForward

· שגיאה

ה-Ipv4RoutingProtocol חייב בסופו של דבר לקרוא לאחת מההתקשרויות הללו עבור כל מנה
זה לוקח אחריות על. כך בעצם עובד תהליך ניתוב הקלט
לינוקס.
[תמונה] התמחות Ipv4Routing..UNINDENT

ארכיטקטורה כוללת זו נועדה לתמוך בגישות ניתוב שונות, כולל
(בעתיד) יישום ניתוב מבוסס מדיניות דמוי לינוקס, פרואקטיבי ו
פרוטוקולי ניתוב לפי דרישה, ופרוטוקולי ניתוב פשוטים עבור המשתמש בסימולציה
לא ממש אכפת מניתוב.

ניתוב IPv4 התמחות. ממחיש כיצד נובעים מזה פרוטוקולי ניתוב מרובים
מעמד בסיס. מחלקה Ipv4ListRouting (מחלקת יישום Ipv4ListRoutingImpl) מספקת
גישת ניתוב הרשימה הקיימת ב ns-3. ה-API שלו זהה למחלקה הבסיסית
Ipv4Routing למעט היכולת להוסיף מספר פרוטוקולי ניתוב עם עדיפות
(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).

הפרטים של פרוטוקולי ניתוב אלה מתוארים להלן ב Unicast ניתוב. לעת עתה,
נתחיל תחילה עם יכולת ניתוב unicast בסיסית המיועדת לכל העולם
לבנות טבלאות ניתוב בזמן סימולציה t=0 עבור משתמשי סימולציה שלא אכפת להם מהם
ניתוב דינמי.

גלוֹבָּלִי מְרוּכָּז ניתוב
ניתוב ריכוזי גלובלי נקרא לפעמים ניתוב "אלוהים"; זה מיוחד
יישום המהלך על טופולוגיית הסימולציה ומריץ אלגוריתם הנתיב הקצר ביותר, ו
מאכלס את טבלאות הניתוב של כל צומת. אין תקורה של פרוטוקול בפועל (בקישורים המדומים)
נוצר עם גישה זו. יש לזה כמה אילוצים:

· קווית רק: הוא אינו מיועד לשימוש ברשתות אלחוטיות.

· Unicast רק: זה לא עושה שידור רב.

· מדרגיות: חלק מהמשתמשים של זה בטופולוגיות גדולות (למשל 1000 צמתים) שמו לב לכך
היישום הנוכחי אינו ניתן להרחבה במיוחד. הניתוב הריכוזי העולמי יהיה
שונה בעתיד כדי להפחית את החישובים ואת ביצועי זמן הריצה.

נכון להיום, ניתוב unicast IPv4 מרוכז עולמי על פני נקודה לנקודה ומשותף
קישורי (CSMA) נתמכים.

כברירת מחדל, בעת שימוש ב- ns-3 ממשק API של עוזר וברירת המחדל של InternetStackHelper, גלובלית
יכולת ניתוב תתווסף לצומת, וניתוב גלובלי יוכנס כ-a
פרוטוקול ניתוב בעדיפות נמוכה יותר מהמסלולים הסטטיים (כלומר, משתמשים יכולים להוסיף מסלולים
באמצעות Ipv4StaticRouting API והם יקבלו עדיפות על פני מסלולים שנמצאו על ידי גלובל
ניתוב).

גלוֹבָּלִי Unicast ניתוב API
ה-API הציבורי הוא מאוד מינימלי. סקריפטים למשתמש כוללים את הדברים הבאים:

#include "ns3/internet-module.h"

אם נעשה שימוש ברירת המחדל של InternetStackHelper, אז יהיה מופע של ניתוב גלובלי
מצטבר לכל צומת. לאחר הגדרת כתובות IP, קריאת הפונקציה הבאה
יגרום לכל הצמתים שיש להם ממשק Ipv4 לקבל טבלאות העברה
הוזן אוטומטית על ידי GlobalRouteManager:

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

הערה: תזכורת לכך שה-wifi NetDevice יעבוד אך אינו מקבל אפקטים אלחוטיים
בחשבון. עבור אלחוטי, אנו ממליצים על ניתוב דינמי של OLSR המתואר להלן.

אפשר לקרוא לפונקציה זו שוב בעיצומה של סימולציה באמצעות ה
פונקציה ציבורית נוספת הבאה:

Ipv4GlobalRoutingHelper::RecomputeRoutingTables ();

אשר שוטפת את הטבלאות הישנות, מבקשת מהצמתים מידע חדש על ממשק, וכן
בונה מחדש את המסלולים.

לדוגמה, קריאת תזמון זו תגרום לבנייה מחדש של הטבלאות בזמן של 5 שניות:

סימולטור::לוח זמנים (שניות (5),
&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);

ישנן שתי תכונות השולטות בהתנהגות. הראשון הוא
Ipv4GlobalRouting::RandomEcmpRouting. אם מוגדר כ-true, מנות מנותבות באופן אקראי
מסלולים מרובי נתיבים בעלות שווה. אם מוגדר כ-false (ברירת מחדל), רק מסלול אחד הוא באופן עקבי
בשימוש. השני הוא Ipv4GlobalRouting::RespondToInterfaceEvents. אם מוגדר כ-true,
לחשב מחדש באופן דינמי את המסלולים הגלובאליים עם אירועי הודעות ממשק (למעלה/למטה, או
הוסף/הסר כתובת). אם מוגדר כ-false (ברירת מחדל), הניתוב עלול להישבר אלא אם המשתמש ידני
קורא ל-RecomputeRoutingTables() לאחר אירועים כאלה. ברירת המחדל מוגדרת ל-false כדי לשמור
מורשה ns-3 התנהגות תוכנית.

גלוֹבָּלִי ניתוב יישום
חלק זה מיועד לאותם קוראים שחשוב להם איך זה מיושם. יחיד
אובייקט (GlobalRouteManager) אחראי לאכלוס המסלולים הסטטיים בכל צומת,
באמצעות ה-API הציבורי של IPv4 של אותו צומת. זה שואל כל צומת בטופולוגיה עבור א
ממשק "GlobalRouter". אם הוא נמצא, הוא משתמש בממשק ה-API של אותו ממשק כדי להשיג "קישור
פרסומת מדינה (LSA)" עבור הנתב. פרסומות של מצב קישור משמשות ב-OSPF
ניתוב, ואנחנו עוקבים אחר העיצוב שלהם.

חשוב לציין שכל החישובים הללו נעשים לפני שהחבילות זורמות
ברשת. בפרט, אין חבילות תקורה או בקרה המוחלפות
בעת שימוש ביישום זה. במקום זאת, מנהל המסלול הגלובלי הזה פשוט הולך ברשימת
צמתים כדי לבנות את המידע הדרוש ולהגדיר את טבלת הניתוב של כל צומת.

ה-GlobalRouteManager מאכלס מסד נתונים של מצב קישורים עם LSAs שנאספו מכל
טופולוגיה. לאחר מכן, עבור כל נתב בטופולוגיה, ה-GlobalRouteManager מבצע את OSPF
חישוב הנתיב הקצר ביותר (SPF) במסד הנתונים, ומאכלס את טבלאות הניתוב על
כל צומת.

הקוואגה (http://www.quagga.net) יישום OSPF שימש כבסיס ל
לוגיקה חישובית ניתוב. יתרון אחד של ביצוע יישום OSPF SPF קיים הוא
ש-OSPF כבר הגדיר פרסומות של מצב קישור לכל סוגי הרשת הנפוצים
קישורים:

· נקודה לנקודה (קישורים סדרתיים)

· נקודה לריבוי נקודות (Frame Relay, אלחוטי אד-הוק)

· גישה מרובה ללא שידור (כספומט)

· שידור (אתרנט)

לכן, אנו חושבים שהפעלת סוגי קישורים אחרים אלה תהיה פשוטה יותר כעת
שמסגרת OSPF SPF הבסיסית קיימת.

נכון לעכשיו, אנו יכולים לטפל ב-IPv4 נקודה לנקודה, קישורים ממוספרים, כמו גם שידור משותף
קישורים (CSMA). ריבוי נתיבים בעלות שווה נתמכת גם. למרות שסוגי קישורים אלחוטיים הם
נתמך על ידי היישום, שים לב כי בשל אופיו של יישום זה, כל
השפעות ערוץ לא ייחשבו וטבלאות הניתוב יניחו שכל צומת
באותו ערוץ משותף ניתן להגיע מכל צומת אחר (כלומר הוא יטופל
כמו קישור CSMA שידור).

ה-GlobalRouteManager עובר תחילה ברשימת הצמתים ומצבר GlobalRouter
ממשק לכל אחד באופן הבא:

typedef std::vector < Ptr >::iterator איטרטור;
עבור (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
{
Ptr node = *i;
Ptr globalRouter = CreateObject (צוֹמֶת);
node->AggregateObject (GlobalRouter);
}

ממשק זה נבדק מאוחר יותר ומשמש ליצירת פרסומת מצב קישור עבור כל אחד מהם
נתב, ומסד הנתונים של מצב הקישור הזה מוזן לתוך לוגיקה החישובית של הנתיב הקצר ביותר של OSPF.
ה-API של Ipv4 משמש סוף סוף לאכלוס המסלולים עצמם.

Unicast ניתוב
ישנם כיום שבעה פרוטוקולי ניתוב unicast המוגדרים עבור IPv4 ושלושה עבור IPv6:

· class Ipv4StaticRouting (המכסה הן unicast והן multicast)

· IPv4 Optimized Link State Routing (OLSR) (פרוטוקול MANET המוגדר ב RFC 3626)

· IPv4 Ad Hoc On Demand Distance Vector (AODV) (פרוטוקול MANET המוגדר ב RFC 3561)

· IPv4 Destination Sequenced Distance Vector (DSDV) (פרוטוקול MANET)

· ניתוב מקור דינמי IPv4 (DSR) (פרוטוקול MANET)

· class Ipv4ListRouting (משמש לאחסון רשימה של פרוטוקולי ניתוב עם עדיפות)

· class Ipv4GlobalRouting (משמש לאחסון מסלולים המחושבים על ידי מנהל המסלולים הגלובלי, אם
זה בשימוש)

· class Ipv4NixVectorRouting (גרסה יעילה יותר של ניתוב גלובלי המאחסנת
נתיבי מקור בשדה כותרת מנות)

· class Ipv6ListRouting (משמש לאחסון רשימה של פרוטוקולי ניתוב עם עדיפות)

· class Ipv6StaticRouting

· class RipNg - פרוטוקול IPv6 RIPng (RFC 2080)

בעתיד, ארכיטקטורה זו אמורה גם לאפשר למישהו ליישם גרסה דמוית לינוקס
יישום עם מטמון ניתוב, או נתב מודולרי Click, אך אלה אינם בהיקף
לעת עתה.

IPv[4,6]ListRouting
סעיף זה מתאר את ברירת המחדל הנוכחית ns-3 Ipv[4,6]RoutingProtocol. בדרך כלל,
פרוטוקולי ניתוב מרובים נתמכים במרחב המשתמש ומתואמים לכתיבת יחיד
טבלת העברות בקרנל. כרגע ב ns-3, היישום במקום מאפשר זאת
פרוטוקולי ניתוב מרובים כדי לבנות/לשמור על מצב ניתוב משלהם, ועל ה-IP
היישום ישאל כל אחד מפרוטוקולי הניתוב הללו (בסדר מסוים שנקבע על ידי
מחבר הסימולציה) עד למציאת מסלול.

בחרנו בגישה זו מכיוון שהיא עשויה להקל טוב יותר על השילוב של שונות
גישות ניתוב שעלולות להיות קשות לתאם את הכתיבה לטבלה אחת,
גישות שבהן נמצא יותר מידע מכתובת ה-IP של יעד (למשל, ניתוב מקור).
משמש לקביעת הקפיצה הבאה, וגישות ניתוב לפי דרישה שבהן מנות חייבות להיות
שמור.

Ipv[4,6]4ListRouting::AddRoutingProtocol
מחלקות Ipv4ListRouting ו-Ipv6ListRouting מספקות הצהרת פונקציה וירטואלית טהורה
עבור השיטה המאפשרת להוסיף פרוטוקול ניתוב:

void AddRoutingProtocol (Ptr ניתוב פרוטוקול,
int16_t priority);

void AddRoutingProtocol (Ptr ניתוב פרוטוקול,
int16_t priority);

שיטות אלו מיושמות בהתאמה לפי מחלקה Ipv4ListRoutingImpl ולפי מחלקה
Ipv6ListRoutingImpl במודול האינטרנט.

משתנה העדיפות לעיל שולט בעדיפות שבה נמצאים פרוטוקולי הניתוב
מוּכנָס. שימו לב שמדובר ב-int חתום. כברירת מחדל ב ns-3, כיתות העוזרים יהיו
הצג אובייקט Ipv[4,6]ListRoutingImpl, והוסף לו Ipv[4,6]StaticRoutingImpl
אובייקט בעדיפות אפס. באופן פנימי, מאוחסנת רשימה של Ipv[4,6]RoutingProtocols, ו
וכל פרוטוקולי הניתוב נועדו לפי סדר עדיפות יורד כדי לראות
האם נמצאה התאמה. לכן, אם אתה רוצה שה-Ipv4RoutingProtocol שלך יקבל עדיפות
נמוך מהניתוב הסטטי, הכנס אותו בעדיפות נמוכה מ-0; לְמָשָׁל:

Ptr myRoutingProto = CreateObject ();
listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);

עם קריאות ל-RouteOutput() או RouteInput(), אובייקט ניתוב הרשימה יחפש ברשימה
של פרוטוקולי ניתוב, בסדר עדיפות, עד למציאת מסלול. פרוטוקול ניתוב כזה
יפעיל את ההתקשרות החוזרת המתאימה ולא יחפשו פרוטוקולי ניתוב נוספים.

אופטימלי קישור מדינה ניתוב (OLSR)
פרוטוקול ניתוב IPv4 זה הועבר במקור מיישום OLSR-UM עבור ns-2.
היישום נמצא בספריית src/olsr, וסקריפט לדוגמה נמצא בתוכו
examples/simple-point-to-point-olsr.cc.

בדרך כלל, OLSR מופעל בתוכנית ראשית על ידי שימוש במחלקה OlsrHelper שמתקין
OLSR לתוך אובייקט Ipv4ListRoutingProtocol. הפקודות הבאות לדוגמה יאפשרו
OLSR בסימולציה באמצעות מחלקה עוזרת זו יחד עם כמה אובייקטי עוזר ניתוב אחרים.
הגדרת ערך העדיפות 10, לפני העדיפות ה-staticRouting של 0, פירושה ש
OLSR יתייעץ לגבי מסלול לפני טבלת הניתוב הסטטית של הצומת.:

NodeContainer c:
...
// הפעל את OLSR
NS_LOG_INFO ("הפעלת ניתוב OLSR.");
OlsrHelper olsr;

Ipv4StaticRoutingHelper staticRouting;

רשימת Ipv4ListRoutingHelper;
list.Add (staticRouting, 0);
list.Add (olsr, 10);

InternetStackHelper אינטרנט;
internet.SetRoutingHelper (רשימה);
internet.Install (c);

לאחר ההתקנה, ניתן להגדיר את "הממשק הראשי" של OLSR באמצעות הפקודה SetMainInterface() .
אם המשתמש לא מציין כתובת ראשית, הפרוטוקול יבחר את ה-IP הראשי הראשון
כתובת שהיא מוצאת, מתחילה תחילה את ממשק ה-loopback ולאחר מכן את הממשק הבא
נמצא ממשק ללא לולאה, לפי סדר אינדקס ממשק Ipv4. כתובת הלולאה של
127.0.0.1 לא נבחר. בנוסף, מוגדרים מספר קבועי פרוטוקול ב
olsr-routing-protocol.cc.

Olsr מופעל בזמן אפס של הסימולציה, בהתבסס על קריאה ל- Object::Start() that
בסופו של דבר קורא ל- OlsrRoutingProtocol::DoStart(). הערה: תיקון כדי לאפשר למשתמש להתחיל
ולהפסיק את הפרוטוקול בזמנים אחרים יתקבל בברכה.

נכון לעכשיו, OLSR מוגבל לשימוש עם אובייקט Ipv4ListRouting, ואינו מגיב ל
שינויים דינמיים בכתובת ה-IP של מכשיר או קישור הודעות למעלה/למטה; כלומר הטופולוגיה
השינויים נובעים מאובדן/עלייה של קישוריות בערוץ אלחוטי.

RIPng
פרוטוקול ניתוב IPv6 זה (RFC 2080) היא האבולוציה של RIPv1 anf RIPv2 הידועים
(ראה RFC 1058 ו RFC 1723) פרוטוקולי ניתוב עבור IPv4.

הפרוטוקול פשוט מאוד, ובדרך כלל הוא מתאים לרשת שטוחה ופשוטה
טופולוגיות.

RIPng מבוסס חזק על RIPv1 ו-RIPv2, ויש לו אותן מטרות ו
מגבלות. בפרט, RIP מחשיב כל נתיב עם מדד השווה או גדול מ-16
כבלתי ניתן להשגה. כתוצאה מכך, המספר המרבי של הקפות הוא שהרשת חייבת להיות קטנה יותר
מ-15 (מספר הנתבים לא מוגדר). מומלץ למשתמשים לקרוא RFC 2080 ו RFC
1058 להבין באופן מלא את התנהגות ומגבלות RIPng.

ניתוב התכנסות
RIPng משתמש באלגוריתם Distance-Vector, והמסלולים מתעדכנים בהתאם ל-
אלגוריתם בלמן-פורד (המכונה לפעמים אלגוריתם פורד-פולקרסון). לאלגוריתם יש א
זמן התכנסות של O(|V|*|E|) כאשר |V| ו |E| הם מספר הקודקודים (נתבים) ו
קצוות (קישורים) בהתאמה. יש להדגיש שזמן ההתכנסות הוא המספר
של שלבים באלגוריתם, וכל צעד מופעל על ידי הודעה. מאז שהופעל
לעדכונים (כלומר, כאשר מסלול משתנה) יש התקררות של 1-5 שניות, הטופלוגיה יכולה
דורש קצת זמן להתייצב.

על המשתמשים להיות מודעים לכך שבמהלך בניית טבלאות ניתוב, הנתבים עלולים לרדת
מנות. יש לשלוח תעבורת נתונים רק לאחר זמן ארוך מספיק כדי לאפשר בניית RIPng
טופולוגיית הרשת. בדרך כלל 80 שניות צריכות להספיק כדי שיהיה לא אופטימלי (אבל
עובד) הגדרת ניתוב. זה כולל את הזמן הדרוש כדי להפיץ את המסלולים הכי הרבה
נתב מרוחק (16 הכשות) עם עדכונים מופעלים.

אם טופולוגיית הרשת משתנה (למשל, קישור נשבר), ייתכן שזמן השחזור יהיה
די גבוה, והוא עשוי להיות אפילו גבוה יותר מזמן ההגדרה הראשוני. יתר על כן, הרשת
שחזור טופולוגיה מושפע מאסטרטגיית Split Horizoning.

הדוגמה examples/routing/ripng-simple-network.cc מציג גם את הגדרת הרשת וגם
שלבי שחזור הרשת.

לְפַצֵל אופקים
Split Horizon היא אסטרטגיה למניעת חוסר יציבות בניתוב. שלוש אפשרויות אפשריות:

· ללא אופק מפוצל

· אופק מפוצל

· Poison Reverse

במקרה הראשון, מסלולים מתפרסמים בכל ממשקי הנתב. בשנייה
במקרה, נתבים לא יפרסמו מסלול בממשק ממנו הוא נלמד.
Poison Reverse יפרסם את המסלול בממשק ממנו הוא נלמד, אבל
עם מדד של 16 (אינסוף). לניתוח מלא של שלוש הטכניקות, ראה RFC
1058, סעיף 2.2.

הדוגמה ripng-simple-network.cc מבוסס על טופולוגיית הרשת המתוארת ב-RFC,
אבל זה לא מראה את האפקט המתואר שם.

הסיבה הם ה- Triggered Updates, יחד עם העובדה שכאשר נתב
מבטל מסלול, הוא יפיץ מיד את חוסר הגישה למסלול, ובכך
מונע את רוב הבעיות המתוארות ב-RFC.

עם זאת, עם טופלוגיות מורכבות, עדיין אפשר להופיע בתופעות של חוסר יציבות במסלול
דומה לזה שמתואר ב-RFC לאחר כשל בקישור. כתוצאה מכך, כל
השיקולים לגבי אופק מפוצל נותרו תקפים.

בְּרִירַת מֶחדָל נתיבים
יש להתקין פרוטוקול RIPng רק על נתבים. כתוצאה מכך, צמתים לא יידעו
מהו הנתב המוגדר כברירת מחדל.

כדי להתגבר על מגבלה זו, על המשתמשים להתקין את מסלול ברירת המחדל באופן ידני (למשל,
באמצעות שימוש ב-Ipv6StaticRouting), או באמצעות RADVd. RADVd זמין ב ns-3 ב
מודול יישומים, ומומלץ מאוד.

פרוטוקול פרמטרים ו אפשרויות
ה-RIPng ns-3 יישום מאפשר לשנות את כל הטיימרים הקשורים למסלול
עדכונים ומסלולים לכל החיים.

יתרה מכך, משתמשים יכולים לשנות את מדדי הממשק על בסיס צומת.

ניתן לבחור את סוג ה-Split Horizonting (כדי למנוע התפשטות מסלולים לאחור) ב-a
בסיס לכל צומת, כאשר האפשרויות הן "ללא אופק מפוצל", "אופק מפוצל" ו"רעל
הפוך". ראה RFC 2080 לפרטים נוספים, ו RFC 1058 לדיון שלם בנושא
אסטרטגיות פיצול אופקים.

מגבלות
אין תמיכה באפשרות Next Hop (RFC 2080, סעיף 2.1.1). ההופ הבא
האפשרות שימושית כאשר RIPng אינו מופעל בכל הנתבים ברשת. תמיכה
שכן אפשרות זו עשויה להיבחן בעתיד.

אין תמיכה בצבירה של קידומת CIDR. כתוצאה מכך, גם טבלאות ניתוב וגם
פרסומות מסלול עשויות להיות גדולות מהנדרש. ניתן להוסיף צבירת קידומת ב-
עתיד.

שידור לקבוצה ניתוב
הפונקציה הבאה משמשת להוספת נתיב ריבוי שידור סטטי לצומת:

לבטל את
Ipv4StaticRouting::AddMulticastRoute (מקור Ipv4Address,
קבוצת כתובת IPv4,
uint32_t inputInterface,
std::vector ממשקי פלט);

מסלול ריבוי שידור חייב לציין כתובת IP מקור, קבוצת שידור וקלט
אינדקס ממשק רשת כתנאים ולספק וקטור של ממשק רשת פלט
מדדים שעליהם נשלחות מנות התואמות לתנאים.

בדרך כלל ישנם שני סוגים עיקריים של מסלולי ריבוי שידורים: מסלולים מהסוג הראשון משמשים
במהלך ההעברה. יש לציין במפורש את כל התנאים. הסוג השני של
מסלולים משמשים להוצאת מנות מצומת מקומית. ההבדל הוא בקלט
מִמְשָׁק. למסלולים להעברה תמיד יצוין ממשק קלט מפורש.
מסלולים מחוץ לצומת תמיד יגדירו את ממשק הקלט לתווים כלליים שצוינו על ידי
אינדקס Ipv4RoutingProtocol::IF_INDEX_ANY.

עבור מסלולים מחוץ לצומת מקומי ניתן להשתמש בתווים כלליים בקבוצת המוצא והשידור הרב-שידורי
כתובות. התו הכללי המשמש עבור Ipv4Adresses הוא הכתובת המוחזרת על ידי
Ipv4Address::GetAny () -- בדרך כלל "0.0.0.0". השימוש בתו כללי מאפשר לציין
התנהגות ברירת מחדל בדרגות שונות.

לדוגמה, הפיכת כתובת המקור לתו כללי, אך עזיבת קבוצת השידור הרב-שידור
specific מאפשר לאחד (במקרה של צומת עם מספר ממשקים) ליצור שונה
מסלולים באמצעות ממשקי פלט שונים עבור כל קבוצת ריבוי שידורים.

אם כתובות המקור והשידור הרב-שידור עשויות לתווים כלליים, יצרת בעצם א
כתובת ברירת מחדל לריבוי שידור שיכולה להעביר למספר ממשקים. השווה את זה ל-
כתובת ריבוי שידור המוגדרת כברירת מחדל, המוגבלת לציון ממשק פלט יחיד
להתאמה לפונקציונליות הקיימת במערכות אחרות.

פקודה נוספת מגדירה את ברירת המחדל של נתיב השידור הרב-שידור:

לבטל את
Ipv4StaticRouting::SetDefaultMulticastRoute (Uint32_t outputInterface);

זוהי המקבילה לריבוי שידורים של גרסת ה-unicast SetDefaultRoute. אנחנו אומרים את
מערכת ניתוב מה לעשות במקרה שבו נתיב ספציפי ל-multicast של יעד
הקבוצה לא נמצאה. המערכת מעבירה מנות מהממשק שצוין בתקווה
ש"משהו שם בחוץ" יודע טוב יותר איך לנתב את החבילה. שיטה זו משמשת רק
בשליחת מנות בתחילה מארח. ברירת המחדל של מסלול השידור הרב-שידור אינו נבדק
במהלך ההעברה -- יש לציין מסלולים מדויקים באמצעות AddMulticastRoute למקרה זה.

מכיוון שאנו בעצם שולחים מנות לאיזו ישות שאנו חושבים שאולי יודעים טוב יותר מה לעשות,
אנחנו לא שמים לב ל"דקויות" כמו כתובת מוצא, וגם לא לדאוג
העברת ממשקים מרובים. אם מוגדר מסלול ברירת המחדל לריבוי שידור, הוא מוחזר
בתור המסלול שנבחר מ- LookupStatic ללא קשר למקור או לקבוצת ריבוי שידורים אם
לא נמצא נתיב ספציפי אחר.

לבסוף, מספר פונקציות נוספות מסופקות לאחזור והסרה של שידור רב
מסלולים:

uint32_t GetNMulticastRoutes (בטל) const;

Ipv4MulticastRoute *GetMulticastRoute (uint32_t i) const;

Ipv4MulticastRoute *GetDefaultMulticastRoute (void) const;

bool RemoveMulticastRoute (מקור כתובת IPv4,
קבוצת כתובת IPv4,
uint32_t inputInterface);

void RemoveMulticastRoute (אינדקס uint32_t);

TCP מודלים in ns-3
פרק זה מתאר את דגמי ה-TCP הזמינים ב ns-3.

כללי תמיכה ל TCP
ns-3 נכתב כדי לתמוך במספר יישומי TCP. המימושים יורשים מ
כמה מחלקות כותרות נפוצות ב- src/רשת ספרייה, כך שקוד המשתמש יוכל להחליף
יישומים עם שינויים מינימליים בסקריפטים.

ישנן שתי מחלקות בסיס מופשטות חשובות:

· מעמד Tcpsocket: זה מוגדר ב src/internet/model/tcp-socket.{cc,h}. הכיתה הזאת
קיים עבור אירוח תכונות TcpSocket שניתן לעשות בהן שימוש חוזר על פני תכונות שונות
יישומים. למשל, התכונה InitialCwnd יכול לשמש עבור כל אחד מה
יישומים הנובעים מהכיתה Tcpsocket.

· מעמד TcpSocketFactory: זה משמש את מופע פרוטוקול שכבה-4 ליצירת TCP
שקעים מהסוג הנכון.

יש כרגע שלושה יישומים של TCP זמינים עבור ns-3.

· TCP מיושם מקורי עבור ns-3

· תמיכה ב- רשת הדמיה עֶרֶשׂ (NSC)

· תמיכה ל ישיר קופונים הוצאה לפועל (DCE)

כמו כן יש להזכיר כי דרכים שונות לשלב מכונות וירטואליות עם ns-3
זמין גם כמה יישומי TCP נוספים, אך אלה אינם בגדר
הפרק הזה.

ns-3 TCP
עד שחרור ns-3.10, ns-3 הכיל יציאה מדגם TCP מ GTNetS. זֶה
היישום שוכתב באופן מהותי על ידי 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}
src/internet/model/tcp-rfc793.{cc,h}
src/internet/model/tcp-tahoe.{cc,h}
src/internet/model/tcp-reno.{cc,h}
src/internet/model/tcp-westwood.{cc,h}
src/internet/model/tcp-newreno.{cc,h}
src/internet/model/rtt-estimator.{cc,h}
src/network/model/sequence-number.{cc,h}

גרסאות שונות של בקרת גודש TCP נתמכות על ידי סיווג משנה של הבסיס המשותף
בכיתה TcpSocketBase. מספר גרסאות נתמכות, כולל RFC 793 (אין עומס
control), Tahoe, Reno, Westwood, Westwood+ ו-NewReno. NewReno משמש כברירת מחדל. לִרְאוֹת
סעיף השימוש במסמך זה כיצד לשנות את גרסת ברירת המחדל של TCP בשימוש
סימולציה.

נוֹהָג
במקרים רבים, השימוש ב-TCP נקבע בשכבת היישום על ידי אזכור של ns-3
יישום באיזה סוג של מפעל שקעים להשתמש.

שימוש בפונקציות העזר המוגדרות ב src/applications/helper ו src/network/helper, פה
כך אפשר ליצור מקלט TCP:

// צור כיור מנות ב-"hub" הכוכב כדי לקבל מנות אלו
יציאת uint16_t = 50000;
כתובת sinkLocalAddress(InetSocketAddress (Ipv4Address::GetAny (), port));
PacketSinkHelper sinkHelper ("ns3::TcpSocketFactory", sinkLocalAddress);
ApplicationContainer sinkApp = sinkHelper.Install (serverNode);
sinkApp.Start (שניות (1.0));
sinkApp.Stop (שניות (10.0));

באופן דומה, הקטע הבא מגדיר את מקור התעבורה OnOffApplication להשתמש ב-TCP:

// צור את יישומי OnOff כדי לשלוח TCP לשרת
OnOffHelper clientHelper ("ns3::TcpSocketFactory", כתובת ());

הקורא הזהיר יציין לעיל שציינו את ה-TypeId של בסיס מופשט
בכיתה TcpSocketFactory. איך התסריט מספר ns-3 שזה רוצה את היליד ns-3 TCP
לעומת מישהו אחר? ובכן, כאשר מוסיפים ערימות אינטרנט לצומת, ברירת המחדל של TCP
יישום המצטבר לצומת הוא ה ns-3 TCP. ניתן לעקוף זאת כ
אנו מראים להלן בעת ​​שימוש בעריסה של סימולציית רשת. אז, כברירת מחדל, בעת שימוש ב- ns-3
עוזר API, ה-TCP שמצטבר לצמתים עם מחסנית אינטרנט הוא המקור ns-3
TCP.

כדי להגדיר התנהגות של TCP, מספר פרמטרים מיוצאים דרך ה- ns-3
מערכת תכונות. אלה מתועדים ב- חמצן
<http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html> לשיעור Tcpsocket. פורום
לדוגמה, גודל המקטע המקסימלי הוא תכונה הניתנת להגדרה.

כדי להגדיר את סוג השקע המוגדר כברירת מחדל לפני יצירת אובייקטים הקשורים למחסנית אינטרנט, אחד
יכול לשים את ההצהרה הבאה בראש תוכנית הסימולציה:

Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe"));

למשתמשים שרוצים לקבל מצביע לשקע בפועל (כדי שפעולות השקע כמו
ניתן לבצע Bind(), הגדרת אפשרויות שקע וכו' על בסיס שקע), שקעי Tcp יכולים
להיווצר באמצעות Socket::CreateSocket() שיטה. ה-TypeId עבר אל
CreateSocket() חייב להיות מסוג ns3::SocketFactory, כך מגדירים את השקע הבסיסי
הסוג חייב להיעשות על ידי סיבוב התכונה הקשורה לפרוטוקול TcpL4 הבסיסי
לְהִתְנַגֵד. הדרך הקלה ביותר להגיע לכך תהיה באמצעות תצורת התכונה
מערכת. בדוגמה שלמטה, נגישות למיכל הצומת "n0n1" כדי לקבל את האפס
אלמנט, ושקע נוצר בצומת זה:

// צור ואגד את השקע...
TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe");
Config::Set ("/NodeList/*/$ns3::TcpL4Protocol/SocketType", TypeIdValue (tid));
Ptr localSocket =
Socket::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 specificNode = "/NodeList/" + nodeId.str () + "/$ns3::TcpL4Protocol/SocketType";
Config::Set (specificNode, TypeIdValue (tid));
Ptr localSocket =
Socket::CreateSocket (n0n1.Get (0), TcpSocketFactory::GetTypeId ());

לאחר יצירת שקע TCP, אחד ירצה לעקוב אחר לוגיקה שקעים קונבנציונלית וגם
connect() ו- send() (עבור לקוח TCP) או bind(), listen() ו-accept() (עבור TCP
שרת). ראה Sockets-APIs לסקירה של אופן השימוש בשקעים ns-3.

בדיקת מערכות
ניתן למצוא מספר תוצאות בדיקת אימות TCP ב- ויקי עמוד המתאר את זה
יישום.

נוֹכְחִי מגבלות
· SACK אינו נתמך

רשת הדמיה עֶרֶשׂ
השמיים רשת הדמיה עֶרֶשׂ (NSC) היא מסגרת לעטיפה של קוד רשת בעולם האמיתי
לתוך סימולטורים, המאפשרים סימולציה של התנהגות בעולם האמיתי בעלות נוספת קטנה. זֶה
העבודה אומתה על ידי השוואת מצבים באמצעות רשת בדיקה עם אותו הדבר
מצבים בסימולטור. עד היום הוכח שה-NSC מסוגל לייצר
תוצאות מדויקות ביותר. NSC תומך בארבע ערימות בעולם האמיתי: FreeBSD, OpenBSD, lwIP
ולינוקס. הושם דגש על אי שינוי ידנית של אף אחת מערימות הרשת. לֹא
שורת קוד בודדת שונתה ביישומי פרוטוקול הרשת של כל אחד מהם
ארבע הערימות לעיל. עם זאת, מנתח C מותאם אישית נבנה לשינוי תכנותי
קוד מקור.

NSC הועבר בעבר אל ns-2 ו-OMNeT++, ונוספה ns-3 בחודש ספטמבר
2008 (מהדורה ns-3.2). סעיף זה מתאר את ns-3 הנמל של NSC וכיצד להשתמש בו.

במידה מסוימת, NSC הוחלפה על ידי תמיכת ליבת לינוקס בתוך ישיר קופונים
הוצאה לפועל (DCE). עם זאת, NSC עדיין זמין דרך מערכת ה-bake build. NSC
תומך בקרנות לינוקס 2.6.18 ו-2.6.26, אך גרסאות חדשות יותר של הליבה לא היו
מועבר.

תנאים מוקדמים
נכון לעכשיו, NSC נבדק והוכח כי הוא עובד על הפלטפורמות הללו: Linux i386 ו-Linux
x86-64. NSC אינו תומך ב-powerpc. השימוש ב-FreeBSD או OS X אינו נתמך (למרות שהוא
אולי יוכל לעבוד).

בניית NSC דורשת את החבילות flex וביזון.

קביעת תצורה ו הורדת
החל מ-ns-3.17 ואילך, יש להוריד את NSC בנפרד מהמאגר שלו,
או הורדה בעת שימוש ב- לאפות לִבנוֹת מערכת of ns-3.

עבור מהדורות ns-3.17 ואילך, בעת שימוש ב-bake, יש להגדיר את NSC כחלק מ-
תצורת "allinone", כגון:

$ CD לאפות
$ python bake.py configure -e ns-allinone-3.19
הורדה של $ python bake.py
$ python bake.py build

במקום גרסה שפורסמה, אפשר להשתמש בגרסת הפיתוח ns-3 על ידי ציון
"ns-3-allinone" לשלב ההגדרה שלמעלה.

ניתן להוריד גם את NSC מ שלה להורדה אתר באמצעות Mercurial:

שיבוט $ hg https://secure.wand.net.nz/mercurial/nsc

לפני השחרור של ns-3.17, NSC נכלל ב-allinone tarball והשוחרר
לא היה צורך להוריד את הגרסה בנפרד.

בִּניָן ו מאמת
NSC עשוי להיבנות כחלק מתהליך בניית האפייה; לחלופין, אפשר לבנות NSC על ידי
עצמה משתמשת במערכת הבנייה שלה; לְמָשָׁל:

$ cd nsc-dev
$ python scons.py

לאחר שנבנה NSC באופן ידני או דרך מערכת האפייה, שנה ל- ns-3
ספריית מקור ונסה להפעיל את התצורה הבאה:

$ ./waf להגדיר

אם NSC נבנה בעבר ונמצא על ידי waf, תראה:

עריסת הדמיית רשת : מופעלת

אם NSC לא נמצא, תראה:

עריסת הדמיית רשת: לא מופעלת (NSC לא נמצא (ראה אפשרות --with-nsc))

במקרה זה, עליך להעביר את הנתיב היחסי או המוחלט לספריות NSC עם
אפשרות תצורה של "--with-nsc"; לְמָשָׁל

$ ./waf configure --with-nsc=/path/to/my/nsc/directory

בעד ns-3 מהדורות לפני מהדורת ns-3.17, תוך שימוש ב- build.py סקריפט ב-ns-3-allinone
ספרייה, NSC ייבנה כברירת מחדל אלא אם הפלטפורמה לא תומכת בה. ל
השבת אותו במפורש בעת הבנייה ns-3, סוג:

$ ./waf configure --enable-examples --enable-tests --disable-nsc

אם waf מזהה NSC, אז בנייה ns-3 עם NSC מתבצע באותו אופן עם waf as
בלי זה. פַּעַם ns-3 בנוי, נסה להפעיל את חבילת הבדיקה הבאה:

$ ./test.py -s ns3-tcp-interoperability

אם NSC נבנה בהצלחה, הבדיקה הבאה אמורה להופיע בתוצאות:

PASS TestSuite ns3-tcp-interoperability

זה מאשר כי NSC מוכן לשימוש.

נוֹהָג
יש כמה קבצים לדוגמה. לְנַסוֹת:

$ ./waf --הפעל את tcp-nsc-zoo
$ ./waf --הרץ tcp-nsc-lfn

דוגמאות אלה יפקידו כמה .pcap קבצים בספרייה שלך, אותם ניתן לבדוק על ידי
tcpdump או wireshark.

בואו נסתכל על ה examples/tcp/tcp-nsc-zoo.cc קובץ לשימוש טיפוסי כלשהו. איך זה
שונה משימוש במקור ns-3 TCP? יש קו תצורה ראשי אחד, בעת שימוש ב- NSC
ו ns-3 ממשק API של עוזר, שצריך להגדיר:

InternetStackHelper internetStack;

internetStack.SetNscStack ("liblinux2.6.26.so");
// זה מחליף את הצמתים 0 ו-1 ל-NSCs Linux 2.6.26 מחסנית.
internetStack.Install (n.קבל(0));
internetStack.Install (n.קבל(1));

קו המפתח הוא SetNscStack. זה אומר למסייע של InternetStack להצטבר
מופעים של NSC TCP במקום מקורי ns-3 TCP לצמתים הנותרים. זה חשוב
שהפונקציה הזו תיקרא לפני קורא ל להתקין() פונקציה, כפי שמוצג לעיל.

באילו ערימות זמינות לשימוש? נכון לעכשיו, ההתמקדות הייתה ב-Linux 2.6.18 וב-Linux
2.6.26 ערימות עבור ns-3. כדי לראות אילו ערימות נבנו, אפשר לבצע את הממצא הבא
פקודה ב ns-3 ספרייה ברמה העליונה:

$ find nsc -name "*.so" -סוג f
nsc/linux-2.6.18/liblinux2.6.18.so
nsc/linux-2.6.26/liblinux2.6.26.so

זה אומר לנו שאנחנו יכולים להעביר את שם הספרייה liblinux2.6.18.so או
liblinux2.6.26.so לשלב התצורה לעיל.

לערום תצורה
NSC TCP חולק את אותן תכונות תצורה הנפוצות בכל שקעי TCP, כמו
שתואר לעיל ותועד ב חמצן

בנוסף, NSC TCP מייצאת הרבה משתני תצורה ל- ns-3 תכונות
מערכת, דרך א sysctlממשק כמו. בתוך ה דוגמאות/tcp/tcp-nsc-zoo לדוגמה, אתה יכול לראות
התצורה הבאה:

// זה משבית את TCP SACK, wscale וחותמות זמן בצומת 1 (התכונות
מייצגים ערכי sysctl).
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack",
StringValue ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps",
StringValue ("0"));
Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling",
StringValue ("0"));

משתני תצורה נוספים אלה אינם זמינים למקוריים ns-3 TCP.

שים לב גם שערכי ברירת המחדל עבור תכונות TCP ב ns-3 TCP עשוי להיות שונה מה- nsc TCP
יישום. ספציפית ב ns-3:

1. ברירת המחדל של TCP MSS היא 536

2. ספירת TCP Delayed Ack היא 2

לכן בעת ​​ביצוע השוואות בין תוצאות המתקבלות באמצעות nsc ו ns-3 TCP, זהירות
יש לנקוט כדי להבטיח שערכים אלה מוגדרים כראוי. לִרְאוֹת
/examples/tcp/tcp-nsc-comparision.cc לדוגמה.

המועצה לביטחון לאומי API
סעיף קטן זה מתאר את ה-API ש-NSC מציג בפניו ns-3 או כל סימולטור אחר. NSC
מספק את ה-API שלו בצורה של מספר מחלקות המוגדרות ב
sim/sim_interface.h בספריית nsc.

· INetStack INetStack מכיל את פעולות 'רמה נמוכה' עבור רשת מערכת ההפעלה
מחסנית, למשל פונקציות כניסה ופלט מחסנית הרשת ואליה (חשבו על זה כ-
'ממשק מנהל התקן רשת'. יש גם פונקציות ליצירת שקעי TCP או UDP חדשים.

· ISendCallback זה נקרא על ידי NSC כאשר יש לשלוח חבילה לרשת.
סימולטור זה צריך להשתמש בהתקשרות חוזרת זו כדי להזריק מחדש את החבילה לסימולטור כך
ניתן להעביר/לנתב את הנתונים בפועל ליעדם, שם הם יהיו בסופו של דבר
נמסר לתוך Receive() (ובסופו של דבר חזרה למופע NSC של המקלט באמצעות
INetStack->if_receive() ).

· INetStreamSocket זהו המבנה המגדיר נקודת קצה מסוימת של חיבור (קובץ
מתאר). הוא מכיל שיטות לפעול בנקודת קצה זו, למשל חיבור, ניתוק,
קבל, האזנה, send_data/read_data, ...

· IInterruptCallback זה מכיל את ה-Wkeup Callback, אשר נקרא על ידי NSC בכל פעם
משהו מעניין קורה. תחשוב על wakeup() כתחליף להפעלה
פונקציית התעוררות מערכות: בכל פעם שמערכת ההפעלה הייתה מתעוררת תהליך שיש לו
חיכיתי להשלמת הפעולה (לדוגמה לחיצת היד של TCP במהלך
connect()), NSC מפעיל את ה-wakeup() callback כדי לאפשר לסימולטור לבדוק את המצב
שינויים בנקודות הקצה של החיבור שלו.

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 הוא הכיתה הראשית. עם האתחול, הוא טוען an
ערימת רשת nsc לשימוש (באמצעות dlopen()). כל מופע של מחלקה זו עשוי להשתמש בגרסה אחרת
לַעֲרוֹם. המחסנית (=ספרייה משותפת) לשימוש מוגדרת באמצעות שיטת SetNscLibrary() (בשלב זה
זמן זה נקרא בעקיפין דרך האינטרנט מחסנית עוזר). לאחר מכן, ערימת nsc מוגדרת
בהתאם (טיימרים וכו'). הפונקציה NscTcpL4Protocol::Receive() מוסרת אותה לחבילה
מקבל (חייבת להיות חבילת tcp/ip מלאה) למחסנית nsc להמשך עיבוד. ל
להיות מסוגל לשלוח מנות, מחלקה זו מיישמת את שיטת nsc send_callback. השיטה הזאת
נקרא על ידי nsc בכל פעם שמחסנית nsc רוצה לשלוח מנה החוצה לרשת. שֶׁלָה
הארגומנטים הם מאגר גולמי, המכיל חבילת TCP/IP מלאה וערך אורך. זֶה
לכן על השיטה להמיר את הנתונים הגולמיים ל-Ptr שמיש על ידי ns-3. כדי
הימנע מבעיות שונות של כותרות ipv4, כותרת ה-ip nsc אינה כלולה. במקום זאת, ה-tcp
header והמטען בפועל מוכנסים ל-Ptr , אחרי זה החבילה היא
הועבר לשכבה 3 לשליחת החבילה החוצה (אין צורך בטיפול מיוחד נוסף
בנתיב שליחה של קוד).

הכיתה הזו מתקשרת ns3::NscTcpSocketImpl הן מהקריאה חוזרת של nsc wakeup() והן מה-
נתיב קבלה (כדי להבטיח שהנתונים העומדים בתור מתוזמנים לשליחה).

src/internet/model/nsc-tcp-socket-impl מיישמת את ממשק socket nsc. כל מופע
יש nscTcpSocket משלו. נתונים שהם Send() ימסרו למחסנית nsc באמצעות
m_nscTcpSocket->send_data(). (ולא ל-nsc-tcp-l4, זה ההבדל העיקרי בהשוואה
ל ns-3 TCP). המחלקה גם מעמידה בתור נתונים שהם Send() לפני הבסיס
המתאר נכנס למצב ESTABLISHED. מחלקה זו נקראת מה-nsc-tcp-l4
class, כאשר nsc-tcp-l4 wakeup() callback מופעל על ידי nsc. nsc-tcp-socket-impl אז
בודק את מצב החיבור הנוכחי (SYN_SENT, ESTABLISHED, LISTEN...) ולוחות זמנים
התקשרויות חוזרות מתאימות לפי הצורך, למשל שקע LISTEN יתזמן קבל כדי לראות אם חדש
יש לאשר את החיבור, שקע ESTABLISHED מתזמן נתונים ממתינים לכתיבה,
תזמן התקשרות חוזרת לקריאה וכו'.

שים לב כי ns3::NscTcpSocketImpl אינו מקיים אינטראקציה ישירה עם nsc-tcp: במקום זאת, הנתונים הם
מנותב מחדש ל nsc. nsc-tcp קורא לשקעי nsc-tcp-sockets של צומת כאשר ההתקשרות חזרה מתעוררות
מופעל על ידי nsc.

מגבלות
· NSC פועל רק על צמתים עם ממשק יחיד; מנסה להפעיל אותו בצומת מרובה ממשקים
יגרום לשגיאה בתוכנית.

· Cygwin ו-OS X PPC אינם נתמכים; OS X Intel אינו נתמך אך עשוי לעבוד

· הערימות שאינן בלינוקס של NSC אינן נתמכות ב ns-3

· לא כל שיחות ה-API של socket נתמכות

לקבלת מידע נוסף, ראה זֶה ויקי עמוד.

CoDel תור הפעלה in ns-3
פרק זה מתאר את יישום התור של CoDel ([Nic12], [Nic14]) ב ns-3.

פותח על ידי קתלין ניקולס ואן ג'ייקובסון כפתרון ל-bufferbloat [Buf14]
בעיה, CoDel (ניהול עיכובים מבוקר) היא דיסציפלינה של תורים שמשתמשת ב-Packet's
זמן שהייה (זמן בתור) לקבלת החלטות על ירידת מנות.

מספר סימוכין תיאור
קוד המקור של מודל CoDel נמצא בספרייה src/internet/model ו
מורכב מ-2 קבצים codel-queue.h ו codel-queue.cc הגדרת מחלקה CoDelQueue וא
מחלקה CoDelTimestampTag עוזר. הקוד הועבר אל ns-3 מאת אנדרו מקגרגור מבוסס על
קוד ליבת לינוקס מיושם על ידי Dave Täht ואריק Dumazet.

· מעמד CoDelQueue: מחלקה זו מיישמת את האלגוריתם הראשי של CoDel:

· CoDelQueue::DoEnqueue (): שגרה זו מתייגת חבילה עם הזמן הנוכחי לפני
לדחוף אותו לתור. תג חותמת הזמן משמש על ידי CoDelQueue::DoDequeue() ל
לחשב את זמן השהייה של החבילה. אם התור מלא עם הגעת החבילה, זה
השגרה תפיל את החבילה ותתעד את מספר הנפילות עקב הצפת תור,
אשר מאוחסן ב m_dropOverLimit.

· CoDelQueue::ShouldDrop (): השגרה הזו היא CoDelQueue::DoDequeue()שגרת העוזרים של
שקובע אם יש להוריד חבילה או לא בהתבסס על זמן השהייה שלה.
אם זמן השהייה יעלה מעל m_target ונשאר מעל ברציפות לפחות
m_interval, השגרה חוזרת נָכוֹן מציין שזה בסדר לשחרר את החבילה.
אחרת, זה חוזר שקר.

· CoDelQueue::DoDequeue (): שגרה זו מבצעת את הפלת החבילה בפועל על סמך
CoDelQueue::ShouldDrop ()ערך ההחזרה של ותזמון הירידה הבאה.

· מעמד CoDelTimestampTag: מחלקה זו מיישמת את תיוג חותמת הזמן עבור מנה. זֶה
תג משמש לחישוב זמן השהייה של החבילה (ההבדל בין זמן ה-
החבילה מושבתת והזמן שהיא נדחפת לתור).

יש 2 סניפים ל CoDelQueue::DoDequeue ():

1. אם התור נמצא כרגע במצב ירידה, כלומר יש לזמן השהייה
נשאר מעל m_target ליותר מ m_interval, השגרה קובעת אם זה בסדר
עזוב את מצב הירידה או שהגיע הזמן לטיפה הבאה. מתי CoDelQueue::ShouldDrop ()
החזרות שקר, התור יכול לצאת ממצב השחרור (סט m_dropping ל שקר).
אחרת, התור מוריד מנות ללא הרף ומעדכן את הזמן לירידה הבאה
(m_dropNext) עד שיתקיים אחד מהתנאים הבאים:

1. התור ריק, עליו התור עוזב את מצב הירידה ויוצא
CoDelQueue::ShouldDrop () שגרה;

2. CoDelQueue::ShouldDrop () החזרות שקר (כלומר זמן השהייה הולך למטה
m_target) שעליו התור עוזב את מצב הירידה;

3. עדיין לא הגיע הזמן לירידה הבאה (m_dropNext הוא פחות מהזמן הנוכחי).
שהתור ממתין לתור החבילות הבא כדי לבדוק שוב את המצב.

2. אם התור אינו במצב שחרור, השגרה נכנסת למצב שחרור ו
שחרר את החבילה הראשונה אם CoDelQueue::ShouldDrop () החזרות נָכוֹן (הכוונה לשהייה
הזמן עלה מעל m_target לפחות m_interval בפעם הראשונה או שזה נעלם
למעלה שוב לאחר שהתור עוזב את מצב ההורדה).

הפניות
[Nic12]

K. Nichols and V. Jacobson, Controlling Queue Delay, ACM Queue, Vol. 10 מס' 5, מאי 2012.
זמין באינטרנט בכתובת http://queue.acm.org/detail.cfm?id=2209336.

[Nic14]

K. Nichols and V. Jacobson, Internet-Draft: Controlled Delay Active Queue Management,
מרץ 2014. זמין באינטרנט ב
http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02.

[Buf14]
Bufferbloat.net. זמין באינטרנט ב http://www.bufferbloat.net/.

תכונות
תכונות המפתח שמחזיקה במחלקת CoDelQueue כוללות את הדברים הבאים:

· מצב: מצב הפעלה CoDel (BYTES, PACKETS או ILLEGAL). מצב ברירת המחדל הוא BYTES.

· MaxPackets: המספר המרבי של מנות שהתור יכול להכיל. ערך ברירת המחדל הוא
DEFAULT_CODEL_LIMIT, שהם 1000 מנות.

· MaxBytes: המספר המרבי של בתים שהתור יכול להכיל. ערך ברירת המחדל הוא 1500 *
DEFAULT_CODEL_LIMIT, שהם 1500 * 1000 בתים.

· MinBytes: פרמטר ה-Minbytes של אלגוריתם CoDel. ערך ברירת המחדל הוא 1500 בתים.

· מרווח: חלון הזזה-מינימום. ערך ברירת המחדל הוא 100 אלפיות השנייה.

· יַעַד: עיכוב תור היעד של אלגוריתם CoDel. ערך ברירת המחדל הוא 5 אלפיות השנייה.

דוגמאות
הדוגמה הראשונה היא codel-vs-droptail-basic-test.cc ממוקם ב src/internet/examples. אל
הפעל את הקובץ (הפנייה הראשונה למטה מציגה את אפשרויות שורת הפקודה הזמינות):

$ ./waf --הפעל "קודל-מול-דרופטייל-בסיסי-מבחן --PrintHelp"
$ ./waf --הפעל "codel-vs-droptail-basic-test --queueType=CoDel --pcapFileName=codel.pcap --cwndTrFileName=cwndCodel.tr"

הפלט הצפוי מהפקודות הקודמות הם שני קבצים: codel.pcap להגיש ו
cwndCoDel.tr (ASCII trace) קובץ ניתן לנתח את קובץ ה-.pcap באמצעות wireshark או
tcptrace:

$ tcptrace -l -r -n -W codel.pcap

הדוגמה השנייה היא codel-vs-droptail-asymmetric.cc ממוקם ב src/internet/examples.
דוגמה זו נועדה לדמות תרחיש פריסת מודם כבלים טיפוסי. כדי להפעיל את
קובץ:

$ ./waf --הפעל "קודל-vs-droptail-asymmetric --PrintHelp"
$ ./waf --הפעל codel-vs-droptail-asymmetric

הפלט הצפוי מהפקודות הקודמות הוא שישה קבצי pcap:

· codel-vs-droptail-asymmetric-CoDel-server-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-wan.pcap

· codel-vs-droptail-asymmetric-CoDel-router-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-cmts-wan.pcap

· codel-vs-droptail-asymmetric-CoDel-cmts-lan.pcap

· codel-vs-droptail-asymmetric-CoDel-host-lan.pcap

קובץ תכונה אחת:

· codel-vs-droptail-asymmetric-CoDel.attr

חמישה קובצי מעקב ASCII:

· codel-vs-droptail-asymmetric-CoDel-drop.tr

· codel-vs-droptail-asymmetric-CoDel-drop-state.tr

· codel-vs-droptail-asymmetric-CoDel-sojourn.tr

· codel-vs-droptail-asymmetric-CoDel-length.tr

· codel-vs-droptail-asymmetric-CoDel-cwnd.tr

בדיקת מערכות
מודל ה-CoDel נבדק באמצעות CoDelQueueTestSuite כיתה שהוגדרה ב
src/internet/test/codel-queue-test-suite.cc. החבילה כוללת 5 מקרי בדיקה:

· בדיקה 1: הבדיקה הראשונה בודקת את התור/התור ללא נפילות ומוודאת זאת
ניתן להגדיר כהלכה תכונות CoDel.

· בדיקה 2: הבדיקה השנייה בודקת את התור עם נפילות עקב הצפת תור.

· מבחן 3: המבחן השלישי בודק את אריתמטיקה של NewtonStep() מול יציאה מפורשת של לינוקס
הפעלה

· מבחן 4: המבחן הרביעי בודק את ControlLaw() מול יציאה מפורשת של לינוקס
הפעלה

· מבחן 5: הבדיקה החמישית בודקת את התור/התור עם נפילות לפי CoDel
אַלגוֹרִיתְם

ניתן להפעיל את חבילת הבדיקה באמצעות הפקודות הבאות:

$ ./waf configure --enable-examples --enable-tests
$ ./waf build
$ ./test.py -s תור-קודל

or

$ NS_LOG="CoDelQueue" ./waf --הרץ "test-runner --suite=codel-queue"
מעבר עמודים

דירוג נמוך WIRELESS אישי AREA רשת (LR-WPAN)

פרק זה מתאר את ההטמעה של דגמי ns-3 עבור מכשיר אלחוטי בקצב נמוך
רשת תקשורת אישית (LR-WPAN) כמפורט בתקן IEEE 802.15.4 (2006).

מספר סימוכין תיאור
קוד המקור למודול lr-wpan נמצא בספרייה src/lr-wpan.

עיצוב
עיצוב הדגם עוקב מקרוב אחר הסטנדרט מנקודת מבט אדריכלית.
[תמונה] ארכיטקטורה והיקף של דגמי lr-wpan.UNINDENT

האזורים האפורים באיור (מותאם מאיור 3 של IEEE Std. 802.15.4-2006) מראים את
היקף הדגם.

ה- Spectrum NetDevice מבית Nicola Baldo הוא הבסיס ליישום.

היישום גם מתכנן ללוות מדגמי ns-2 שפותחו על ידי ג'נג ולי
בעתיד.

ממשקי API
ממשקי ה-API עוקבים מקרוב אחר התקן, המותאמים למוסכמות וניבים של שמות ns-3. ה
ממשקי API מאורגנים סביב הרעיון של פרימיטיביות שירות כפי שמוצג להלן
דמות מותאמת מאיור 14 של IEEE Std. 802.15.4-2006.
[תמונה] פרימיטיבים של שירות.UNINDENT

ממשקי ה-API מאורגנים סביב ארבעה שירותים רעיוניים ונקודות גישה לשירות (SAP):

· שירות נתונים של MAC (MCPS)

· שירות ניהול MAC (MLME)

· שירות נתונים PHY (PD)

· שירות ניהול PHY (PLME)

באופן כללי, הפרימיטיבים מתוקנים כדלקמן (למשל סעיף 7.1.1.1.1 של IEEE
802.15.4-2006)::

MCPS-DATA.request (
SrcAddrMode,
DstAddrMode,
DstPANId,
DstAddr,
msduLength,
msdu,
msduHandle,
TxOptions,
רמת אבטחה,
KeyIdMode,
מקור מפתח,
מפתח חיפוש
)

זה ממפה למחלקות ושיטות של ns-3 כגון::

struct McpsDataRequestParameters
{
uint8_t m_srcAddrMode;
uint8_t m_dstAddrMode;
...
};

לבטל את
LrWpanMac::McpsDataRequest (פרמטרים של McpsDataRequestParameters)
{
...
}

מק
ה-MAC מיישם כיום את גרסת CSMA/CA ללא חריצים, ללא משואה. כַּיוֹם
אין תמיכה ברכזים ובממשקי ה-API הרלוונטיים.

ה-MAC המיושם דומה ל-NullMAC של Contiki, כלומר, MAC ללא תכונות שינה.
ההנחה היא שהרדיו פעיל תמיד (מקבל או משדר), או סגור לחלוטין
מטה. קליטת הפריימים אינה מושבתת בזמן ביצוע ה-CCA.

ה-API העיקרי הנתמך הוא ה-API להעברת נתונים (McpsDataRequest/Indication/Confirm).
CSMA/CA לפי Stc 802.15.4-2006, סעיף 7.5.1.4 נתמך. קליטת פריים ו
דחייה לפי Std 802.15.4-2006, סעיף 7.5.6.2 נתמך, כולל
תודות. רק התייחסות קצרה מיושם לחלוטין. מקורות עקבות שונים הם
נתמך, וניתן לחבר מקורות עקבות לכיורים.

PHY
רכיבי השכבה הפיזית מורכבים ממודל Phy, מודל של שיעור שגיאה והפסד
דֶגֶם. מודל שיעור השגיאה מדגמן כיום את שיעור השגיאות עבור IEEE 802.15.4 2.4 GHz
ערוץ AWGN עבור OQPSK; ניתן למצוא את תיאור הדגם ב-IEEE Std 802.15.4-2006,
סעיף E.4.1.7. מודל Phy מבוסס על SpectrumPhy והוא עוקב אחר המפרט
המתואר בסעיף 6 של IEEE Std 802.15.4-2006. זה מדגמן מפרטי שירות PHY,
פורמטי PPDU, קבועי PHY ותכונות PIB. כרגע זה תומך רק בשידור
מסכת צפיפות ספקטרלית הספק המצוינת ב-2.4 GHz לכל סעיף 6.5.3.1. כוח הרעש
הצפיפות מניחה שרעש תרמי מפוזר באופן אחיד על פני פסי התדר. ההפסד
המודל יכול לנצל באופן מלא את כל המודלים הפשוטים הקיימים (ללא ספקטרום phy) לאובדן. דגם ה-Phy
משתמש במודל ערוץ ספקטרום יחיד הקיים. השכבה הפיזית מעוצבת לפי חבילה
רמה, כלומר, לא נעשה זיהוי מבוא/SFD. קליטת מנות תתחיל עם
החלק הראשון של ההקדמה (שאינו מעוצב), אם ה-SNR הוא יותר מ-5 dB, ראה
IEEE Std 802.15.4-2006, נספח E, איור E.2. קבלת החבילה תסתיים לאחר מכן
החבילה הועברה לחלוטין. מנות אחרות שיגיעו במהלך הקבלה יצטברו
להפרעות/רעש.

כרגע רגישות המקלט מוגדרת לערך קבוע של -106.58 dBm. זֶה
מתאים לשיעור שגיאות מנות של 1% עבור מנות ייחוס של 20 בתים עבור אות זה
כוח, לפי IEEE Std 802.15.4-2006, סעיף 6.1.7. בעתיד נספק
תמיכה בשינוי הרגישות לערכים שונים.
[תמונה] שיעור שגיאות מנות לעומת כוח האות. UNINDENT

NetDevice
למרות שצפוי שפרופילי טכנולוגיה אחרים (כגון 6LoWPAN ו-ZigBee) יעשו זאת
כותבים מחלקות NetDevice משלהם, מסופק LrWpanNetDevice בסיסי, שמכיל בתוכו
הפעולות הנפוצות של יצירת מכשיר LrWpan גנרי וחיבור דברים יחד.

היקף ו מגבלות
גרסאות עתידיות של מסמך זה יכילו פרופורמה PICS הדומה לנספח D של
IEEE 802.15.4-2006. הדגש הנוכחי הוא על מצב unslotted של פעולת 802.15.4
לשימוש ב-Zigbee, וההיקף מוגבל להפעלת מצב יחיד (CSMA/CA) עם בסיסי
יכולות העברת נתונים. אין עדיין תמיכה בקשר עם רכזי PAN
השימוש בכתובת מורחבת. ההפרעה מעוצבת כ-AWGN אבל זה לא נכון כרגע
נבדק ביסודיות.

תור NetDevice Tx אינו מוגבל, כלומר, מנות לעולם אינן נשמטות עקב תור
הופכים מלאים. הם עלולים להישמט עקב ניסיונות שידור חוזרים מדי או גישה לערוץ
כישלון.

הפניות
· מפרט בקרת גישה בינונית אלחוטית (MAC) ושכבה פיזית (PHY) עבור
רשתות תקשורת אישיות אלחוטיות בקצב נמוך (WPAN), IEEE Computer Society, IEEE Std
802.15.4-2006, 8 בספטמבר 2006.

·

J. Zheng ומיונג J. Lee, "מחקר ביצועים מקיף של IEEE 802.15.4," חיישן
Network Operations, IEEE Press, Wiley Interscience, פרק 4, עמ' 218-237, 2006.

נוֹהָג
מפעיל lr-wpan
להוסיף lr-wpan לרשימת המודולים שנבנו עם ns-3.

עוֹזֵר
העוזר מעוצב בדוגמת עוזרי מכשיר אחרים. בפרט, מעקב (ascii ו
pcap) מופעל באופן דומה, ומתבצעת הפעלה של כל רכיבי היומן lr-wpan
באופן דומה. השימוש במסייע מודגם ב examples/lr-wpan-data.cc. עבור ascii
מעקב, עקבות השידור והקבלה מחוברים לשכבת ה-Mac.

מודל אובדן התפשטות ברירת המחדל שנוסף לערוץ, כאשר נעשה שימוש במסייע זה, הוא
LogDistancePropagationLossModel עם פרמטרי ברירת מחדל.

דוגמאות
הדוגמאות הבאות נכתבו, אותן ניתן למצוא ב src/lr-wpan/examples/:

· lr-wpan-data.cc: דוגמה פשוטה המציגה העברת נתונים מקצה לקצה.

· lr-wpan-error-distance-plot.cc: דוגמה לשרטוט וריאציות של הצלחת החבילה
יחס כפונקציה של המרחק.

· lr-wpan-error-model-plot.cc: דוגמה לבדיקת ה-phy.

· lr-wpan-packet-print.cc: דוגמה להדפסת שדות הכותרת של MAC.

· lr-wpan-phy-test.cc: דוגמה לבדיקת ה-phy.

בפרט, המודול מאפשר תרחיש העברת נתונים פשוט מאוד מקצה לקצה,
מיושם ב lr-wpan-data.cc. האיור מציג רצף של אירועים המופעלים
כאשר ה-MAC מקבל DataRequest מהשכבה הגבוהה יותר. זה מפעיל ערוץ ברור
הערכה (CCA) מה-PHY, ואם היא מצליחה, שולחת את המסגרת אל ה-PHY שם היא
מועבר דרך הערוץ ומביא לאינדיקציה DataIndication בצומת העמיתים.
[תמונה] דוגמה לנתונים עבור העברת נתונים פשוטה של ​​LR-WPAN מקצה לקצה.UNINDENT

הדוגמה lr-wpan-error-distance-plot.cc משרטט את יחס הצלחת המנות (PSR) בתור א
פונקציה של מרחק, באמצעות מודל ברירת המחדל של אובדן התפשטות LogDistance וה-
מודל שגיאה 802.15.4. הערוץ (ברירת מחדל 11), גודל מנות (ברירת מחדל 20 בתים) ו
ניתן לשנות את כוח השידור (ברירת המחדל 0 dBm) על ידי ארגומנטים של שורת הפקודה. התכנית
מפלט קובץ בשם 802.15.4-psr-distance.plt. טעינת קובץ זה לתוך gnuplot מניבה א
פילה 802.15.4-psr-distance.eps, שניתן להמיר ל-pdf או לפורמטים אחרים. ה
פלט ברירת המחדל מוצג להלן.
[תמונה] פלט ברירת מחדל של התוכנית lr-wpan-error-distance-plot.cc.UNIDENT

בדיקות
נכתבו המבחנים הבאים, אותם ניתן למצוא ב src/lr-wpan/tests/:

· lr-wpan-ack-test.cc: בדוק אם נעשה שימוש באישורים ומונפקים ב-
הזמנה נכונה.

· lr-wpan-collision-test.cc: בדוק קליטה נכונה של מנות עם הפרעות ו
התנגשויות.

· lr-wpan-error-model-test.cc: בדוק שמודל השגיאה נותן ערכים צפויים.

· lr-wpan-packet-test.cc: בדוק את 802.15.4 מחלקות הכותרת/טריילר של MAC

· lr-wpan-pd-plme-sap-test.cc: בדוק את PLME ו-PD SAP לפי IEEE 802.15.4

· lr-wpan-spectrum-value-helper-test.cc: בדוק שההמרה בין כוח
(מבוטא ככמות סקלרית) והספק ספקטרלי, וחוזר חלילה, נופל בטווח של 25%
סובלנות על פני מגוון הערוצים והכוחות הקלט האפשריים.

בדיקת מערכות
הדגם לא אושר כנגד חומרה אמיתית. מודל השגיאה היה
מאומת כנגד הנתונים ב-IEEE Std 802.15.4-2006, סעיף E.4.1.7 (איור E.2). ה
התנהגות MAC (CSMA backoff) אומתה ביד כנגד התנהגות צפויה. ה
העלילה למטה היא דוגמה לאימות מודל השגיאה וניתן לשחזר אותה על ידי ריצה
lr-wpan-error-model-plot.cc:
[תמונה] פלט ברירת מחדל של התוכנית lr-wpan-error-model-plot.cc.UNIDENT

LTE מודול

עיצוב תיעוד
סקירה כללית
סקירה כללית של מודל הדמיית LTE-EPC מתוארת באיור סקירה כללית of מה היא
LTE-EPC הדמיה מודל. ישנם שני מרכיבים עיקריים:

· דגם LTE. דגם זה כולל את ערימת פרוטוקול הרדיו LTE (RRC, PDCP, RLC, MAC,
PHY). ישויות אלה שוכנות במלואן בתוך צמתי ה-UE וה-eNB.

· דגם ה-EPC. מודל זה כולל ממשקי ליבה של רשת, פרוטוקולים וישויות.
הישויות והפרוטוקולים הללו נמצאים בתוך צמתי SGW, PGW ו-MME, ובחלקם
בתוך צמתי eNB.
[תמונה] סקירה כללית של מודל הדמיית LTE-EPC.UNINDENT

עיצוב קריטריונים
LTE מספר סימוכין
מודל LTE תוכנן כדי לתמוך בהערכה של ההיבטים הבאים של LTE
מערכות:

· ניהול משאבי רדיו

· תזמון מנות מודע ל-QoS

· תיאום הפרעות בין תאים

· גישה לספקטרום דינמי

על מנת לדגמן מערכות LTE לרמת פירוט המספיקה כדי לאפשר תקין
הערכה של ההיבטים שהוזכרו לעיל, הדרישות הבאות היו
נחשב:

1. ברמת הרדיו, הגרנולריות של הדגם צריכה להיות לפחות זו של
בלוק משאבים (RB). למעשה, זוהי היחידה הבסיסית המשמשת למשאב
הַקצָאָה. ללא רמת הפירוט המינימלית הזו, לא ניתן לדגמן
תזמון מנות בצורה מדויקת והפרעות בין תאים. הסיבה היא שמאז
תזמון מנות נעשה על בסיס RB, eNB עשוי לשדר על תת-קבוצה בלבד
מכל ה-RBs הזמינים, ומכאן מפריע ל-eNBs אחרים רק באותם RBs שבהם
זה משדר. שימו לב שדרישה זו שוללת אימוץ של מערכת
גישת סימולציה ברמה, אשר מעריכה הקצאת משאבים רק ב-
פירוט של הקמת שיחה/נושאת.

2. הסימולטור צריך להגדיל עד עשרות eNBs ומאות ציוד משתמש (UEs).
זה שולל שימוש בסימולטור ברמת קישור, כלומר, סימולטור שהרדיו שלו
הממשק מעוצב בפירוט עד לרמת הסמל. זה בגלל ש
יש מודל ברמת סמל יש צורך ליישם את כל האות של שכבת PHY
עיבוד, שהמורכבות החישובית העצומה שלו מגבילה מאוד את הסימולציה. למעשה,
סימולטורים ברמת קישור מוגבלים בדרך כלל ל-eNB בודד ו-UE אחד או כמה.

3. צריך להיות אפשרי בתוך הסימולציה להגדיר תאים שונים כך
הם משתמשים בתדרים שונים של ספק ורוחב פס מערכת. רוחב הפס בשימוש על ידי
יש לאפשר לתאים שונים לחפוף, על מנת לתמוך בספקטרום דינמי
פתרונות רישוי כגון אלו המתוארים ב-[Ofcom2600MHz] ו-[RealWireless].
חישוב ההפרעה צריך לטפל במקרה זה כראוי.

4. להיות מייצג יותר את תקן LTE, כמו גם להיות קרוב ככל האפשר
למימושים בעולם האמיתי, הסימולטור צריך לתמוך ב-MAC Scheduler API
פורסם על ידי FemtoForum [FFAPI]. ממשק זה צפוי לשמש את
יצרני femtocell ליישום תזמון ומשאב רדיו
אלגוריתמי ניהול (RRM). על ידי הצגת תמיכה בממשק זה ב-
סימולטור, אנו מאפשרים לספקי ולמפעילי ציוד LTE לבדוק ב-
סביבה סימולטיבית בדיוק אותם אלגוריתמים שייפרסו במציאות
מערכת.

5. מודל הדמיית LTE צריך להכיל יישום משלו של ה-API המוגדר ב
[FFAPI]. לא תאימות בינארית או מבנה נתונים עם ספק ספציפי
צפויים יישומים של אותו ממשק; לפיכך, שכבת תאימות
יש לשלב בכל פעם שמתזמן MAC ספציפי לספק יש להשתמש עם
מַדמֶה. דרישה זו נחוצה כדי לאפשר לסימולטור להיות עצמאי
מיישומים ספציפיים לספק של מפרט ממשק זה. אנו מציינים זאת
[FFAPI] הוא מפרט לוגי בלבד, והיישום שלו (למשל, תרגום
לשפת תכנות מסוימת) נותר לספקים.

6. המודל אמור לשמש כדי לדמות שידור של מנות IP על ידי העליון
שכבות. בהקשר זה, ייחשב שב-LTE התזמון ו
ניהול משאבי רדיו לא עובד עם מנות IP ישירות, אלא עם RLC
PDUs, אשר מתקבלים על ידי פילוח ושרשור של מנות IP שנעשו על ידי
ישויות RLC. לפיכך, יש לעצב את הפונקציות הללו של שכבת RLC
במדויק.

EPC מספר סימוכין
המטרה העיקרית של מודל ה-EPC היא לספק אמצעים לסימולציה של מקצה לקצה
קישוריות IP על דגם LTE. למטרה זו, הוא תומך בחיבור הדדי של
מספר UEs לאינטרנט, דרך רשת גישה לרדיו של מספר eNBs המחוברים ל-a
צומת SGW/PGW יחיד, כפי שמוצג באיור סקירה כללית of מה היא LTE-EPC הדמיה מודל.

בחירות העיצוב הבאות נעשו עבור דגם ה-EPC:

1. סוג ה-Packet Data Network (PDN) היחיד הנתמך הוא IPv4.

2. הישויות הפונקציונליות SGW ו-PGW מיושמות בתוך צומת בודד, כלומר
מכאן מכונה צומת SGW/PGW.

3. התרחישים עם ניידות בין-SGW אינם מעניינים. לפיכך, SGW/PGW בודד
הצומת יהיה קיים בכל תרחישי הסימולציות

4. דרישה למודל ה-EPC היא שניתן להשתמש בו כדי לדמות את הקצה לקצה
ביצועים של יישומים מציאותיים. לפיכך, זה אמור להיות אפשרי להשתמש עם
EPC דגם כל יישום ns-3 רגיל שעובד על גבי TCP או UDP.

5. דרישה נוספת היא האפשרות לדמות טופולוגיות רשת עם ה
נוכחות של מספר eNBs, שחלקם עשויים להיות מצוידים ב-backhaul
חיבור עם יכולות מוגבלות. על מנת לדמות תרחישים כאלה, המשתמש
יש לעצב פרוטוקולים של מישור נתונים הנמצאים בשימוש בין ה-eNBs וה-SGW/PGW
במדויק.

6. זה אמור להיות אפשרי עבור UE בודד להשתמש ביישומים שונים עם שונות
פרופילי QoS. לפיכך, יש לתמוך במספר נושאי EPS עבור כל UE. זֶה
כולל את הסיווג הדרוש של תעבורת TCP/UDP דרך IP שנעשה ב-UE in
ה-uplink וב-PGW ב-downlink.

7. המיקוד של מודל ה-EPC הוא בעיקר במישור הנתונים של ה-EPC. הדוגמנות המדויקת של
מטוס הבקרה של EPC אינו דרישה, לעת עתה; מכאן, ה
ניתן לעצב אינטראקציות במישור הבקרה הדרושות בצורה פשוטה על ידי
מינוף על אינטראקציה ישירה בין אובייקטי הסימולציה השונים באמצעות ה
סיפקו חפצי עזר.

8. המיקוד של מודל ה-EPC הוא בסימולציות של משתמשים פעילים במצב מחובר ECM.
לפיכך, כל הפונקציונליות שרלוונטית רק למצב סרק ECM (בפרט,
עדכון אזור מעקב והחלפת) אינם מעוצבים כלל.

9. המודל אמור לאפשר אפשרות לבצע מסירה מבוססת X2 בין שניים
eNBs.

אדריכלות
LTE מספר סימוכין
UE ארכיטקטורה
הארכיטקטורה של מודל מחסנית פרוטוקול הרדיו LTE של ה-UE מיוצגת ב-
דמויות LTE רָדִיוֹ פרוטוקול לערום ארכיטקטורה ל מה היא UE on מה היא נתונים מטוס ו LTE רָדִיוֹ
פרוטוקול לערום ארכיטקטורה ל מה היא UE on מה היא לִשְׁלוֹט מטוס אשר מדגישים בהתאמה
מישור הנתונים ומישור הבקרה.
[תמונה] ארכיטקטורת מחסנית פרוטוקול רדיו LTE עבור ה-UE במישור הנתונים.UNINDENT
[תמונה] ארכיטקטורת מחסנית פרוטוקול רדיו LTE עבור ה-UE במישור הבקרה.UNINDENT

הארכיטקטורה של מודל PHY/ערוץ של ה-UE מיוצגת באיור PHY ו
ערוץ מודל ארכיטקטורה ל מה היא UE.
[תמונה] PHY וארכיטקטורת מודל ערוץ עבור UE.UNINDENT

eNB ארכיטקטורה
הארכיטקטורה של מודל מחסנית פרוטוקול הרדיו LTE של ה-eNB מיוצגת ב-
דמויות LTE רָדִיוֹ פרוטוקול לערום ארכיטקטורה ל מה היא eNB on מה היא נתונים מטוס ו LTE רָדִיוֹ
פרוטוקול לערום ארכיטקטורה ל מה היא eNB on מה היא לִשְׁלוֹט מטוס אשר מדגישים בהתאמה
מישור הנתונים ומישור הבקרה.
[תמונה] ארכיטקטורת מחסנית של פרוטוקול רדיו LTE עבור ה-eNB במישור הנתונים.UNINDENT
[תמונה] ארכיטקטורת מחסנית פרוטוקול רדיו LTE עבור ה-eNB במישור הבקרה. UNINDENT

הארכיטקטורה של מודל PHY/ערוץ של ה-eNB מיוצגת באיור PHY ו
ערוץ מודל ארכיטקטורה ל מה היא eNB.
[תמונה] ארכיטקטורת PHY ומודל ערוץ עבור eNB.UNINDENT

EPC מספר סימוכין
EPC נתונים מטוס
באיור LTE-EPC נתונים מטוס פרוטוקול לערום, אנו מייצגים את נתוני LTE-EPC מקצה לקצה
ערימת פרוטוקול מטוס כפי שהיא מעוצבת בסימולטור. מהדמות זה ניכר
שהפישוט הגדול ביותר שהוצג במודל מישור הנתונים הוא הכללת ה
פונקציונליות SGW ו-PGW בתוך צומת SGW/PGW יחיד, אשר מסירה את הצורך ב-S5
או ממשקי S8 שצוינו על ידי 3GPP. מצד שני, עבור שניהם ערימת פרוטוקול S1-U
וערימת פרוטוקול הרדיו LTE כל שכבות הפרוטוקול שצוינו על ידי 3GPP קיימות.
[תמונה] מחסנית פרוטוקול מטוס נתונים LTE-EPC.UNINDENT

EPC לִשְׁלוֹט מטוס
הארכיטקטורה של יישום מודל מישור הבקרה מוצגת באיור EPC
לִשְׁלוֹט מודל. ממשקי הבקרה המעוצבים באופן מפורש הם ה-S1-AP, ה-X2-AP
וממשקי S11.

נציין כי ממשקי S1-AP ו-S11 מעוצבים בצורה פשוטה על ידי
באמצעות זוג אחד בלבד של מחלקות ממשק כדי לדגמן את האינטראקציה בין ישויות
שוכנים בצמתים שונים (ה-eNB וה-MME עבור ממשק S1-AP, וה-MME ו
ה-SGW עבור ממשק S11). בפועל, זה אומר שהפרימיטיבים של אלה
ממשקים ממופים לקריאת פונקציה ישירה בין שני האובייקטים. מנגד
יד, ממשק ה-X2-AP מעוצב באמצעות יחידות נתוני פרוטוקול הנשלחות דרך קישור X2
(מעוצב כקישור מנקודה לנקודה); מסיבה זו, מודל הממשק X2-AP הוא יותר
מְצִיאוּתִי.
[תמונה] דגם בקרת EPC.UNINDENT

ערוץ ו רביה
למטרות דוגמנות ערוצים, מודול LTE משתמש ב- SpectrumChannel הממשק מסופק
על ידי מודול הספקטרום. בזמן כתיבת שורות אלה, שני יישומים של ממשק כזה
פנויים: SingleModelSpectrumChannel ו MultiModelSpectrumChannel, וה-LTE
מודול דורש שימוש ב- MultiModelSpectrumChannel על מנת לעבוד כמו שצריך. זֶה
זה בגלל הצורך לתמוך בתצורות שונות של תדר ורוחב פס. את כל
את דגמי ההפצה הנתמכים על ידי MultiModelSpectrumChannel ניתן להשתמש בתוך
מודול LTE.

השתמש of מה היא בניינים מודל עם LTE
מודל ההפצה המומלץ לשימוש עם מודול LTE הוא זה שמסופק על ידי
מודול הבניינים, שלמעשה תוכנן במיוחד עם LTE (אם כי זה יכול להיות
משמש גם עם טכנולוגיות אלחוטיות אחרות). אנא עיין בתיעוד של
מודול בניינים למידע כללי על מודל ההפצה שהוא מספק.

בחלק זה נדגיש כמה שיקולים החלים במיוחד כאשר ה
מודול מבנים משמש יחד עם מודול LTE.

מוסכמות השמות המשמשת בקטע הבא תהיה:

· ציוד משתמש: UE

· תחנת מאקרו בסיס: MBS

· תחנת בסיס של תאים קטנים (למשל, pico/femtocell): SC

מודול ה-LTE מתייחס ל-FDD בלבד, ומיישם התפשטות מטה ו-uplink
לְחוּד. כתוצאה מכך, מבוצעים חישובי אובדן הנתיבים הבאים

· MBS <-> UE (פנים וחוץ)

· SC (פנימי וחיצוני) <-> UE (פנימי וחיצוני)

מודל LTE אינו מספק את חישובי אובדן הנתיבים הבאים:

· UE <-> UE

· MBS <-> MBS

· MBS <-> SC

· SC <-> SC

מודל הבניינים אינו יודע את סוג הצומת בפועל; כלומר, זה לא מודע
אם צומת משדר הוא UE, MBS או SC. במקום זאת, למודל הבניינים אכפת רק
לגבי מיקום הצומת: האם הוא פנימי וחיצוני, ומהו ציר ה-Z שלו
כבוד לרמת הגג. כתוצאה מכך, עבור צומת eNB שמוקם בחוץ ו
בקואורדינטת z מעל רמת הגג, יהיו דגמי ההתפשטות האופייניים ל-MBS
בשימוש על ידי מודול הבניינים. לעומת זאת, עבור eNB שמוקם בחוץ אך מתחת ל-
על הגג, או בתוך הבית, ישמשו דגמי התפשטות האופייניים לפיקו ופמטוצלים.

לתקשורת הכוללת לפחות צומת פנימי אחד, חדירת הקיר המקבילה
ההפסדים יחושבו לפי מודל הבניינים. זה מכסה את מקרי השימוש הבאים:

· MBS <-> UE מקורה

· חיצוני SC <-> UE פנימי

· Indoor SC <-> Indoor UE

· פנימי SC <-> חיצוני UE

אנא עיין בתיעוד של מודול הבניינים לפרטים על הדגמים בפועל
בשימוש בכל מקרה.

דוֹהֶה מספר סימוכין
מודול LTE כולל מודל דהייה מבוסס עקבות הנגזר מזה שפותח במהלך
ה- GSoC 2010 [Piro2011]. המאפיין העיקרי של מודל זה הוא העובדה כי
הערכת דהייה במהלך זמן ריצה של סימולציה מבוססת על עקבות מחושבות. זה
נעשה כדי להגביל את המורכבות החישובית של הסימולטור. מצד שני, זה צריך
מבנים ענקיים לאחסון העקבות; לכן, פשרה בין מספר
יש למצוא פרמטרים אפשריים ואת תפוסת הזיכרון. החשובים שבהם הם:

· מהירות המשתמשים: מהירות יחסית בין משתמשים (משפיעה על תדר הדופלר, אשר ב
סיבובים משפיעים על תכונת שונות הזמן של הדהייה)

· מספר ברזים (וכוח יחסי): מספר נתיבים מרובים שנחשבים, אשר
משפיע על תכונת התדר של הדהייה.

· פירוט זמן של העקבות: זמן דגימה של העקיבה.

· גרעיניות התדר של העקיבה: מספר הערכים בתדירות שיש להעריך.

· אורך עקבות: גדול באופן אידיאלי כמו זמן הסימולציה, עשוי להיות מופחת על ידי חלון
מנגנון.

· מספר משתמשים: מספר עקבות עצמאיות לשימוש (אידיאלי עקבות אחת לכל
מִשׁתַמֵשׁ).

ביחס למודל התפשטות הערוצים המתמטיים, אנו מציעים את זה שמסופק על ידי
מה היא רייליצ'אן פונקציה של Matlab, מכיוון שהיא מספקת ערוץ מקובל
מודליזציה הן בתחום הזמן והן בתחום התדר. למידע נוסף, הקורא הוא
הפנה אל [מתמטיקה].

הסימולטור מספק סקריפט מטלב
(src/lte/model/fading-traces/fading-trace-generator.m) ליצירת עקבות על בסיס ה
פורמט המשמש את הסימולטור. בפירוט, אובייקט הערוץ שנוצר עם ה-rayleighchan
הפונקציה משמשת לסינון אות דחף בזמן דיסקרטי על מנת להשיג את
ערוץ תגובה דחף. הסינון חוזר על עצמו עבור TTI שונה, ובכך מניב
תגובות ערוץ עוקבות בקורלציה בזמן (אחת לכל TTI). תגובת הערוץ היא אז
מעובד עם ה pwelch פונקציה להשגת ערכי צפיפות ספקטרלי ההספק שלו, אשר
לאחר מכן נשמרים בקובץ בפורמט המתאים התואם לדגם הסימולטור.

מכיוון שמספר המשתנים הוא די גבוה, צור עקבות בהתחשב בכולם
עשוי לייצר מספר גבוה של עקבות בגודל עצום. בעניין זה שקלנו את
להלן הנחות של הפרמטרים המבוססים על תנאי התפשטות הדהייה של 3GPP
(ראה נספח B.2 של [TS36104]):

· מהירות המשתמשים: בדרך כלל רק כמה ערכים בדידים נחשבים, כלומר:

· 0 ו-3 קמ"ש עבור תרחישים של הולכי רגל

· 30 ו-60 קמ"ש עבור תרחישים של כלי רכב

· 0, 3, 30 ו-60 עבור תרחישים עירוניים

· ברזי ערוצים: רק מספר מצומצם של סטים של ברזי ערוצים נחשבים בדרך כלל,
לדוגמה, שלושה דגמים מוזכרים בנספח B.2 של [TS36104].

· פירוט זמן: אנחנו צריכים ערך דהייה אחד לכל TTI, כלומר, כל 1 ms (מכיוון שזהו
פירוט בזמן של דגם ns-3 LTE PHY).

· גרעיניות תדר: אנחנו צריכים ערך דהייה אחד לכל RB (שהוא התדר
גרעיניות של מודל הספקטרום המשמש את מודל ns-3 LTE).

· אורך המעקב: הסימולטור כולל את מנגנון החלונות המיושם
במהלך GSoC 2011, אשר מורכב מאיסוף חלון של עקבות כל חלון
אורך בצורה אקראית.

· תהליך דהייה לכל משתמש: משתמשים חולקים את אותו עקבות דהייה, אך עבור כל משתמש א
נקודת התחלה שונה במעקב נאספת באופן אקראי. בחירה זו נעשתה ל
הימנע מהצורך לספק עקבות דהייה אחת לכל משתמש.

לפי הפרמטרים ששקלנו, הנוסחה הבאה מבטאת בפירוט את ה
גודל כולל S_{traces} של עקבות הדהייה:

כאשר S_{מדגם} הוא הגודל בבייטים של המדגם (למשל, 8 במקרה של דיוק כפול,
4 במקרה של דיוק ציפה), N_{RB} הוא מספר ה-RB או קבוצת ה-RB שיש לקחת בחשבון,
T_{trace} הוא האורך הכולל של העקיבה, T_{sample} הוא רזולוציית הזמן של העקיבה
(1 ms), ו-N_{תרחישים} הוא מספר תרחישי הדהייה הרצויים (כלומר,
שילובים של קבוצות שונות של ברזי ערוצים וערכי מהירות המשתמש). אנו מספקים עקבות
עבור 3 תרחישים שונים אחד עבור כל תצורת ברזים המוגדרת בנספח B.2 של
[TS36104]:

· הולך רגל: עם מהירות צמתים של 3 קמ"ש.

· רכב: עם מהירות צמתים של 60 קמ"ש.

· עירוני: עם מהירות צמתים של 3 קמ"ש.

לפיכך N_{תרחישים} = 3. לכל העקבות יש T_{trace} = 10 שניות ו-RB_{NUM} = 100.
בסך הכל 24 מגה בייט של עקבות.

אנטנות
בהתבסס על ה SpectrumPhy, דגם ה-LTE PHY תומך בדוגמנות אנטנות באמצעות ה-ns-3
דגם אנטנה מעמד. לפיכך, כל מודל המבוסס על מחלקה זו יכול להיות משויך לכל eNB או
מופע UE. לדוגמה, השימוש ב- CosineAntennaModel המשויך למכשיר eNB
מאפשר לדגמן סקטור אחד של תחנת בסיס מאקרו. כברירת מחדל, ה דגם אנטנה איזוטרופי
משמש גם עבור eNBs וגם עבור UEs.

PHY
סקירה כללית
מודל השכבה הפיזית המסופק בסימולטור LTE זה מבוסס על זה המתואר ב
[Piro2011], עם השינויים הבאים. המודל כולל כעת את התא הבין
חישוב הפרעות וסימולציה של תעבורת Uplink, כולל שתי המנות
שידור ויצירת CQI.

תת מסגרת מִבְנֶה
תת המסגרת מחולקת לחלק בקרה ונתונים כמתואר באיור LTE תת-מסגרת
חֲלוּקָה..
[תמונה] חלוקת תת-מסגרת של LTE..UNINDENT

בהתחשב בפירוט של הסימולטור המבוסס על RB, הבקרה וההתייחסות
יש ליצור מודל של איתות בהתחשב באילוץ הזה. על פי
תקן [TS36211], מסגרת הבקרה למטה מתחילה בתחילת כל תת מסגרת
ונמשך עד שלושה סמלים על פני כל רוחב הפס של המערכת, כאשר בפועל
משך הזמן מסופק על ידי ערוץ האינדיקטור של פורמט הבקרה הפיזי (PCFICH). ה
לאחר מכן, מידע על ההקצאה ממופה במשאב הנותר עד ל-
משך הזמן שהוגדר על ידי ה-PCFICH, במה שנקרא ערוץ הבקרה הפיזי של קישור למטה
(PDCCH). PDCCH מעביר הודעה בודדת בשם Downlink Control Information (DCI)
מגיע משכבת ​​ה-MAC, כאשר המתזמן מציין את הקצאת המשאבים עבור א
משתמש ספציפי. ה-PCFICH וה-PDCCH מעוצבים עם השידור של הבקרה
מסגרת של משך זמן קבוע של 3/14 של אלפיות השנייה המשתרעת על כל הזמין
רוחב פס, שכן המתזמן אינו מעריך את גודל אזור הבקרה. זֶה
מרמז שבלוק שידור יחיד מדגמן את כל מסגרת הבקרה עם קבוע
כוח (כלומר, זה המשמש עבור PDSCH) על פני כל ה-RBs הזמינים. לפי זה
תכונה, שידור זה מייצג גם תמיכה רבת ערך עבור אות ההתייחסות
(RS). זה מאפשר לכל TTI הערכה של תרחיש ההפרעות מאז
כל ה-eNB משדרים (במקביל) את מסגרת הבקרה על הקבצים המתאימים
רוחבי פס זמינים. נציין כי הדגם אינו כולל את הגברת הכוח מאז
הוא אינו משקף שיפור כלשהו במודל המיושם של הערכת הערוץ.

אות ההתייחסות לצלילים (SRS) מעוצב בדומה למסגרת הבקרה למטה.
ה-SRS ממוקם מעת לעת בסמל האחרון של תת-המסגרת בכל המערכת
רוחב פס. מודול RRC כבר כולל אלגוריתם להקצאה דינמית של
מחזוריות כפונקציה של המספר האמיתי של UEs המחוברים ל-eNB בהתאם ל
הליך ספציפי ל-UE (ראה סעיף 8.2 של [TS36213]).

מק ל ערוץ עיכוב
כדי לדגמן את ההשהיה של יישומי MAC ו-PHY אמיתיים, מודל PHY מדמה א
השהיית MAC לערוץ בכפולות של TTIs (1ms). העברת נתונים ושליטה כאחד
מנות מתעכבות בסכום זה.

CQI מָשׁוֹב
יצירת משוב CQI נעשה בהתאם למה שצוין ב-[FFAPI]. ב
בפירוט, שקלנו את יצירת ה-CQI בפס רחב תקופתי (כלומר, ערך בודד של
מצב ערוץ שנחשב כמייצג של כל ה-RBs בשימוש) ו-CQIs בתוך פס (כלומר, א
סט ערך המייצג את מצב הערוץ עבור כל RB).

מדד ה-CQI שיש לדווח מתקבל על ידי השגת תחילה מדידת SINR ולאחר מכן
העברת מדידת SINR זו את המודולציה והקידוד האדפטיבי שימפה אותו ל-
מדד CQI.

ב-downlink, ניתן לחשב את ה-SINR המשמש ליצירת משוב CQI בשניים שונים
דרכים:

1. Ctrl שיטה: SINR מחושב בשילוב עוצמת האות מההפניה
אותות (שבסימולציה שווה ל-PDCCH) וההפרעות
מתח מה-PDCCH. גישה זו גורמת להתייחסות של כל eNB שכנה כאל
מפריע, ללא קשר אם ה-eNB הזה באמת מבצע PDSCH כלשהו
שידור, וללא קשר להספק ול-RBs המשמשים להפרעה בסופו של דבר
שידורי PDSCH.

2. מעורב שיטה: SINR מחושב בשילוב עוצמת האות מההפניה
אותות (שבסימולציה שווה ל-PDCCH) וההפרעות
כוח מה-PDSCH. גישה זו מביאה להתייחסות כמפריעים רק לאלה
eNBs שכנים שמשדרים נתונים באופן פעיל ב-PDSCH, ומאפשרים זאת
ליצור CQIs inband אשר אחראים לכמויות שונות של הפרעות על שונות
RBs לפי רמת ההפרעה בפועל. במקרה שאין PDSCH
שידור מבוצע על ידי כל eNB, שיטה זו רואים בהפרעה
אפס, כלומר, ה-SINR יחושב כיחס בין האות לרעש בלבד.

כדי לעבור בין שתי גישות דורות CQI אלה, LteHelper::UsePdschForCqiGeneration
צריך להגדיר: false עבור הגישה הראשונה ו-true עבור הגישה השנייה (true is
ערך ברירת מחדל):

Config::SetDefault ("ns3::LteHelper::UsePdschForCqiGeneration", BooleanValue (true));

ב-uplink, שני סוגים של CQIs מיושמים:

· מבוסס SRS, נשלח מעת לעת על ידי ה-UEs.

· מבוסס PUSCH, מחושב מהנתונים המועברים בפועל.

ממשק המתזמן כולל מערכת תכונות calld UlCqiFilter לניהול ה
סינון של ה-CQI על פי טבעם, בפירוט:

· SRS_UL_CQI לאחסון CQI מבוססי SRS בלבד.

· PUSCH_UL_CQI לאחסון CQI מבוססי PUSCH בלבד.

· ALL_UL_CQI לאחסון כל ה-CQIs שהתקבלו.

יש לציין כי, ה FfMacScheduler מספק רק את הממשק וזה עניין
של יישום המתזמן בפועל כדי לכלול את הקוד לניהול התכונות הללו
(ראה סעיף הקשור למתזמן למידע נוסף בעניין זה).

התערבות מספר סימוכין
מודל PHY מבוסס על דגמי ההפרעות גאוסים הידועים, לפיהם
הכוחות של אותות מפריעים (ביחידות ליניאריות) מסוכמים יחד כדי לקבוע
כוח ההפרעה הכולל.

דיאגרמת הרצף של איור רצף תרשים of מה היא PHY הַפרָעָה חישוב
הליך מראה כיצד מעובדים אותות מפריעים לחישוב ה-SINR, וכיצד SINR
משמש לאחר מכן ליצירת משוב CQI.
[תמונה] דיאגרמת רצף של הליך חישוב הפרעות PHY.UNINDENT

LTE ספֵּקטרוּם מספר סימוכין
השימוש בספקטרום הרדיו על ידי eNBs ו-UEs ב-LTE מתואר ב-[TS36101]. בתוך ה
סימולטור, השימוש בספקטרום הרדיו מעוצב כדלקמן. תן f_c לציין את LTE Absolute
מספר ערוץ תדר רדיו, המזהה את תדר הספק על 100 קילו-הרץ
רסטר; יתר על כן, תן ל-B להיות תצורת רוחב הפס של השידור במספר של
חסימות משאבים. עבור כל זוג (f_c,B) המשמש בסימולציה אנו מגדירים תואם
SpectrumModel באמצעות הפונקציונליות המסופקת על ידי ה-sec-spectrum-module. מודל באמצעות
מסגרת הספקטרום המתוארת ב- [Baldo2009]. ניתן להגדיר f_c ו-B עבור כל אחד
eNB מופע בסימולציה; לפיכך, כל eNB יכול להשתמש במודל ספקטרום שונה.
כל UE ישתמש אוטומטית במודל הספקטרום של ה-eNB אליו הוא מחובר. משתמש ב
MultiModelSpectrumChannel המתואר ב-[Baldo2009], ההפרעה בין eNBs המשתמשים
מודלים שונים של ספקטרום נחשבים כראוי. זה מאפשר לדמות דינמיקה
מדיניות גישה לספקטרום, כמו למשל מדיניות רישוי הספקטרום שכן
נדון ב-[Ofcom2600MHz].

נתונים PHY שְׁגִיאָה מספר סימוכין
הסימולטור כולל מודל שגיאה של מישור הנתונים (כלומר, PDSCH ו-PUSCH) בהתאם
לטכניקות מיפוי קישור למערכת (LSM) הסטנדרטיות. הבחירה מותאמת ל-
מתודולוגיית סימולציית מערכת סטנדרטית של טכנולוגיית שידור רדיו OFDMA. הודות ל
LSM אנו מסוגלים לשמור על רמת דיוק טובה ובו בזמן להגביל את
עלייה במורכבות החישובית. זה מבוסס על מיפוי של שכבת קישור בודדת
ביצועים המתקבלים באמצעות סימולטורים ברמת קישור למערכת (במקרה שלנו רשת)
סימולטורים. קישור מיוחד סימולטור השכבות משמש ליצירת הביצועים
של קישור בודד מנקודת מבט של שכבת PHY, בדרך כלל במונחים של שיעור שגיאות בלוק קוד
(BLER), בתנאים סטטיים ספציפיים. LSM מאפשר שימוש בפרמטרים אלו יותר
תרחישים מורכבים, אופייניים לסימולטורים של מערכת/רשת, שבהם יש לנו קישורים נוספים,
הפרעות ותופעות התפשטות ערוץ "צבעוני" (למשל, סלקטיבי תדר
דוֹהֶה).

לשם כך נעשה שימוש בסימולטור LTE של וינה [ViennaLteSim] עבור מה שנוגע ל
מיצוי של ביצועי שכבת קישור וה-SINR האפקטיבי מבוסס מידע הדדי
(MIESM) כפונקציית מיפוי LSM תוך שימוש בחלק מהעבודה שפורסמה לאחרונה על ידי ה-Signet
קבוצת אוניברסיטת פדובה [PaduaPEM].

MIESM
שיטת ה-LSM הספציפית שאומצה היא זו המבוססת על שימוש במידע הדדי
מדד, המכונה בדרך כלל המידע ההדדי לכל סיביות מקודד (MIB או MMIB כאשר
מעורב ממוצע של מספר MIBs). אפשרות אחרת תהיה מיוצגת על ידי
ESM אקספוננציאלי (EESM); עם זאת, מחקרים עדכניים מראים כי MIESM עולה על EESM ב
תנאי הדיוק [LozanoCost].
[תמונה] דיאגרמת פרוצדורה חישובית של MIESM.UNINDENT

המידע ההדדי (MI) תלוי במיפוי קבוצות הכוכבים ויכול להיות
מחושב על בסיס בלוק תחבורה (TB), על ידי הערכת ה-MI על הסמלים וה-
ספק משנה. עם זאת, זה יהיה מורכב מדי עבור סימולטור רשת. לפיכך, אצלנו
יישום תגובת ערוץ שטוח בתוך ה-RB נשקללה; לכן ה
MI הכולל של שחפת מחושב בממוצע של MI המוערך לכל RB בשימוש בשחפת.
בפירוט, התוכנית המיושמת מתוארת באיור MIESM חישובית הליך
תרשים, שבו אנו רואים שהמודל מתחיל בהערכת ערך MI עבור כל RB,
מיוצג באיור על ידי דגימות SINR. ואז ה-MI המקביל מוערך לפי
בסיס שחפת על ידי ממוצע ערכי MI. לבסוף, יש לעשות צעד נוסף מאז
סימולטור רמת קישור מחזיר את הביצועים של הקישור במונחים של שיעור שגיאות חסימה
(BLER) בערוץ רעש גואסי לבן נוסף (AWGN), שבו הבלוקים הם הקוד
בלוקים (CBs) מקודדים/מפענחים באופן עצמאי על ידי מקודד הטורבו. בעניין זה ה
נעשה שימוש בסכימת פילוח סטנדרטית של 3GPP להערכת גודל ה-CB בפועל
(מתואר בסעיף 5.1.2 של [TS36212]). סכמה זו מחלקת את ה-TB ב-N_{K_-}
בלוקים בגודל K_- ו-N_{K+} בלוקים בגודל K_+. לכן ה-TB BLER הכולל (TBLER)
יכול לבוא לידי ביטוי כ

כאשר ה-CBLER_i הוא ה-BLER של ה-CB i המתקבל לפי סימולטור רמת הקישור
עקומות CB BLER. להערכת ה-CBLER_i, הערכת MI יושמה
לפי הקירוב המספרי שלו המוגדר ב-[wimaxEmd]. יתר על כן, להפחתה
המורכבות של החישוב, הקירוב הומר לחיפוש
שולחנות. בפירוט, נעשה שימוש במודל מצטבר גאוסי לקירוב ה-AWGN
עקומות BLER עם שלושה פרמטרים המספקים התאמה הדוקה ל-AWGN הסטנדרטי
הופעות, בנוסחה:

כאשר x הוא ה-MI של ה-TB, b_{ECR} מייצג את "מרכז המעבר" ו-c_{ECR} הוא
קשור ל"רוחב המעבר" של ההתפלגות המצטברת של גאוס עבור כל אחד מהם
Effective Code Rate (ECR) שהוא קצב השידור בפועל לפי הערוץ
קידוד ו-MCS. להגבלת המורכבות החישובית של המודל שקלנו
רק תת-קבוצה של ECRs אפשרי למעשה יהיו לנו פוטנציאל 5076 ECRs אפשרי
(כלומר, 27 MCS ו-188 גדלי CB). מהבחינה הזו, נגביל את גדלי ה-CB לכמה
ערכים מייצגים (כלומר, 40, 140, 160, 256, 512, 1024, 2048, 4032, 6144), בעוד עבור
האחרים ישמשו הגרוע ביותר המתקרב לזה האמיתי (כלומר, CB הקטן יותר
ערך גודל זמין ביחס לזה האמיתי). בחירה זו מותאמת לאופייני
ביצועים של קודי טורבו, כאשר גודל ה-CB אינו משפיע מאוד על ה-BLER.
עם זאת, יש לציין כי עבור גדלי CB הנמוכים מ-1000 סיביות האפקט עשוי להיות
רלוונטי (כלומר, עד 2 dB); לכן, אנו מאמצים מרווח דגימה לא מאוזן זה עבור
בעל דיוק רב יותר היכן שצריך. התנהגות זו מאושרת על ידי הנתונים
מוצג במדור אנס.

BLER עקומות
מבחינה זו, השתמשנו מחדש בחלק מהעקומות שהתקבלו בתוך [PaduaPEM]. בפירוט, אנחנו
הציג את התלות בגודל CB לעקומות CB BLER בתמיכת המפתחים
של [PaduaPEM] ושל סימולטור LTE Vienna. למעשה, המודול ששוחרר מספק את
ביצועי שכבת קישור רק עבור מה שנוגע ל-MCSs (כלומר, עם 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 מה היא BLER עקומות in מה היא ns-3 LTE מודול
המודל המיושם משתמש בעקומות עבור ה-LSM של מודל השגיאה של LTE PHY לאחרונה
שוחרר בקהילת ns3 על ידי קבוצת Signet [PaduaPEM] והחדשים שנוצרו
עבור גדלי CB שונים. ה LteSpectrumPhy הכיתה אחראית על הערכת ה-TB BLER
הודות לשיטות המסופקות על ידי ה LteMiErrorModel כיתה, אשר מופקדת על
הערכת ה-TB BLER לפי הווקטור של ה-SINR הנתפס לכל RB, ה-MCS ו-
הגודל על מנת ליצור מודל נכון של הפילוח של השחפת ב-CBs. על מנת להשיג
הווקטור של ה-SINR הנתפס בשני מקרים של מעבד LtePemSinrChunk (ילד של
LteChunkProcessor מוקדש להערכת SINR להשגת ביצועי שגיאה פיזית)
צורפו ל-UE downlink ול-eNB uplink LteSpectrumPhy מודולים להערכת
התפלגות מודל השגיאה בהתאמה של PDSCH (צד UE) ו-ULSCH (צד eNB).

ניתן להשבית את המודל לעבודה עם ערוץ אפס הפסדים על ידי הגדרת ה PemEnabled
תכונה של LteSpectrumPhy class (כברירת מחדל פעילה). ניתן לעשות זאת בהתאם
לנוהל מערכת התכונות הסטנדרטי של ns3, כלומר:

Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

שליטה ערוצים PHY שְׁגִיאָה מספר סימוכין
הסימולטור כולל את מודל השגיאה עבור ערוצי בקרה למטה (PCFICH ו-PDCCH),
בעוד ב-uplink הוא ערוץ משוער ואידיאלי ללא שגיאות. המודל מבוסס על
גישת MIESM שהוצגה קודם לבחינת ההשפעות של סלקטיבי התדרים
ערוץ שכן רוב ערוצי הבקרה משתרעים על כל רוחב הפס הזמין.

PCFICH + PDCCH שְׁגִיאָה מספר סימוכין
המודל שאומץ להתפלגות השגיאות של ערוצים אלו מבוסס על הערכה
מחקר שבוצע ב-RAN4 של 3GPP, שבו ספקים שונים חקרו את
ביצועי דמודולציה של ה-PCFICH במשותף עם PDCCH. זה נובע מהעובדה ש
ה-PCFICH הוא הערוץ שאחראי לתקשר ל-UEs את המימד האמיתי של
ה-PDCCH (המתפרש בין 1 ל-3 סמלים); לכן הפענוח הנכון של
ה-DCIs תלוי בפירוש הנכון של שניהם. ב-3GPP יש בעיה זו
הוערך עבור שיפור ביצועי קצה התא [FujitsuWhitePaper], כאשר ה
הפרעה בין תאים שכנים יכולה להיות גבוהה יחסית עקב השפלת האות. א
בעיה דומה הייתה הודעות בתרחיש פמטו-תא, ובאופן כללי יותר, ב-HetNet
תרחישים שצוואר הבקבוק זוהה בעיקר כערוץ PCFICH [Bharucha2011],
כאשר במקרה של eNBs רבים פרוסים באותו אזור שירות, ערוץ זה עלול להתנגש
בתדירות, מה שהופך גם את הזיהוי הנכון של ערוץ PDCCH לבלתי אפשרי.

בסימולטור, ה-SINR הנתפס במהלך הקבלה נאמד לפי
מודל MIESM שהוצג לעיל על מנת להעריך את התפלגות השגיאות של PCFICH ו
PDCCH. בפירוט, דגימות SINR של כל ה-RBs נכללות בהערכת ה-MI
הקשורים למסגרת הבקרה ולפי ערכים אלה, ה-SINR האפקטיבי (eSINR)
מתקבל על ידי היפוך תהליך הערכת MI. יש לציין שבמקרה של
שידור MIMO, גם PCFICH וגם PDCCH משתמשים תמיד במצב גיוון השידור כ
מוגדר על ידי התקן. על פי eSINR תפסו את שגיאת הפענוח
ניתן להעריך את ההסתברות כפונקציה של התוצאות המוצגות ב-[R4-081920]. במקרה
התרחשה שגיאה, ה-DCIs נמחקו ולכן ה-UE לא יוכל לקבל את
הכתב Tbs, ולכן אבוד כתוצאה מכך.

MIMO מספר סימוכין
השימוש במספר אנטנות הן בצד המשדר והן בצד המקלט, המכונה
קלט מרובה ופלטים מרובים (MIMO), היא בעיה שנחקרה היטב בספרות במהלך
השנים האחרונות. רוב העבודה מתרכזת בהערכה אנליטית של הרווח שה-
תוכניות MIMO שונות עשויות להיות במונחים של קיבולת; אולם מישהו מספק גם
מידע על הרווח במונחים של כוח שהתקבל [CatreuxMIMO].

על פי השיקולים לעיל, ניתן לקבל מודל גמיש יותר בהתחשב
הרווח שתכניות MIMO מביאות למערכת מנקודת מבט סטטיסטית. כפי ש
שהודגשו בעבר, [CatreuxMIMO] מציג את הרווח הסטטיסטי של מספר פתרונות MIMO
כבוד ל-SISO one במקרה של אין מתאם בין האנטנות. בעבודה ה
הרווח מוצג כפונקציית ההפצה המצטברת (CDF) של הפלט SINR עבור
מה דאגה לתוכניות SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE ו-MIMO-ZF.
משכלל את התוצאות, ניתן להעריך את התפלגות SINR של הפלט באמצעות א
לוג-נורמלי עם ממוצע ושונות שונים כפונקציה של הסכימה הנחשבת.
עם זאת, השונות אינן כל כך שונות והן שוות בקירוב לזו
של מצב SISO כבר כלול ברכיב ההצללה של
מבנים התפשטות מודל הפסד, בפירוט:

· SISO: = 13.5 ו-ma = 20 [dB].

· MIMO-Alamouti: = 17.7 ו-ma = 11.1 [dB].

· MIMO-MMSE: = 10.7 ו-ma = 16.6 [dB].

· MIMO-OSIC-MMSE: = 12.6 ו-ma = 15.5 [dB].

· MIMO-ZF: = 10.3 ו-ma = 12.6 [dB].

לכן שכבת PHY מיישמת את מודל ה-MIMO בתור הרווח הנתפס על ידי המקלט
כאשר משתמשים בסכימת MIMO מתייחסים לזו שהושגה באמצעות SISO one. נציין כי, אלה
רווחים התייחסו למקרה שבו אין מתאם בין האנטנות ב-MIMO
תָכְנִית; לכן אל תדגמי השפלה עקב מתאם נתיבים.

UE PHY מדידות מספר סימוכין
לפי [TS36214], על ה-UE לדווח על סט מדידות של eNBs שה-
המכשיר מסוגל לקלוט: את אות הייחוס שהתקבל (RSRP) ואת
איכות קבלת אות התייחסות (RSRQ). הראשון הוא מדד לכוח המתקבל של
eNB ספציפי, בעוד שהאחרון כולל גם הפרעות ערוץ ורעש תרמי.
ה-UE צריך לדווח על המדידות במשותף עם זהות התא הפיזית (PCI) של
תָא. מדידות ה-RSRP וה-RSRQ מבוצעות במהלך קליטת ה-RS,
בעוד שה-PCI מתקבל עם אות הסנכרון הראשי (PSS). ה-PSS נשלח
על ידי eNB כל 5 תת מסגרות ובפירוט בתתי מסגרות 1 ו-6. במערכות אמיתיות, רק
504 PCIs נפרדים זמינים, ומכאן שיכול להתרחש ששני eNBs קרובים משתמשים ב-
אותו PCI; עם זאת, בסימולטור אנו מדגמים PCIs באמצעות מטא נתונים של סימולציה, ואנו מאפשרים
עד 65535 PCIs נפרדים, ובכך למנוע התנגשויות PCI בתנאי שפחות מ-65535
eNBs מדומים באותו תרחיש.

לפי [TS36133] סעיפים 9.1.4 ו-9.1.7, RSRP מדווח לפי שכבת PHY ב-dBm
בעוד RSRQ ב-dB. הערכים של RSRP ו-RSRQ מסופקים לשכבות גבוהות יותר דרך
C-PHY SAP (באמצעות UeMeasurementsParameters struct) כל 200 אלפיות השנייה כפי שהוגדר ב
[TS36331]. סינון שכבה 1 מתבצע על ידי ממוצע של כל המדידות שנאספו
במהלך חריץ החלון האחרון. ניתן להתאים את מחזוריות הדיווח למחקר
מטרות באמצעות ה LteUePhy::UeMeasurementsFilterPeriod תכונה.

ניתן לפשט את הנוסחאות של ה-RSRP וה-RSRQ בהתחשב בהנחה של ה-PHY
שכבה שהערוץ שטוח בתוך ה-RB, רמת הדיוק הטובה ביותר. למעשה, זה
מרמז שלכל ה-RE בתוך RB יש את אותו הכוח, לכן:

כאשר P(k,m) מייצג את עוצמת האות של ה-RE m בתוך ה-RB k, אשר, כפי שנצפה
לפני, הוא קבוע בתוך אותו RB ושווה ל-P(k), M הוא מספר ה-RE הנושאים
ה-RS ב-RB ו-K הוא מספר ה-RB. יש לציין כי P(k), ובכלל הכל
הסמכויות המוגדרות בסעיף זה, מתקבלות בסימולטור מהפס"ד של הר"ב
(אשר מסופק על ידי 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; לכן P(k,s,r) = P(k),
I(k,s,r) = I(k) ו-N(k,s,r) = N(k), מה שמרמז שניתן לחשב את ה-RSSI כ:

בהתחשב באילוצים של יישום שרשרת קליטה PHY, ועל מנת
לשמור על רמת המורכבות החישובית נמוכה, רק RSRP ניתן לקבל ישירות עבור
כל התאים. זה נובע מהעובדה ש LteSpectrumPhy מיועד להערכת ה
הפרעה רק ביחס לאות של ה-eNB המשרת. זה מרמז שה-PHY
שכבה מותאמת לניהול מידע אותות הכוח עם ה-eNB המשרת כ-a
התייחסות. עם זאת, ניתן לחלץ RSRP ו- RSRQ של תא i שכן על ידי הזרם
מידע זמין של תא 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(k) הוא
ההספק הנתפס של תא j בכל RE של RB k ו-N הוא ספקטרלי רעש ההספק
צפיפות בכל RE. המדגם נחשב לתקף במקרה של ה-RSRQ המוערך הוא
מעל ה LteUePhy::RsrqUeMeasThreshold תכונה.

HARQ
ערכת HARQ המיושמת מבוססת על פתרונות יתירות מצטברים (IR) משולבים
עם מספר תהליכי עצירה והמתנה לאפשר זרימת נתונים רציפה. בפירוט, ה
הפתרון שאומץ הוא רך שילוב כלאים IR מלא מצטבר יתירות (המכונה גם
IR Type II), מה שמרמז שהשידורים החוזרים מכילים רק כבוד למידע חדש
לקודמים. אלגוריתם הקצאת המשאבים של ה-HARQ יושם
בתוך כיתות המתזמן המתאימות (כלומר, RrFfMacScheduler ו PfFfMacScheduler,
עיין במדורי הכתב שלהם למידע נוסף), בעוד שחלק הפענוח של ה
HARQ יושם ב- LteSpectrumPhy ו LteHarqPhy שיעורים שיהיו
מפורט בסעיף זה.

על פי התקן, שידורי ה-UL הם סינכרוניים ולכן כן
הוקצו 7 אלפיות השנייה לאחר השידור המקורי. מצד שני, עבור ה-DL, הם כן
אסינכרוני ולכן ניתן להקצות אותו בצורה גמישה יותר החל מ-7 ms ו
זה עניין של יישום מתזמן ספציפי. התנהגות תהליכי HARQ היא
מתואר באיור:ref:fig-harq-processes-scheme.

בשכבת ה-MAC, ישות HARQ השוכנת במתזמן אחראית על השליטה
8 תהליכי HARQ להפקת מנות חדשות וניהול השידורים החוזרים עבור שניהם
ה-DL וה-UL. המתזמן אוסף את משוב ה-HARQ משכבות eNB ו-UE PHY
(בהתאמה לחיבור UL ו-DL) באמצעות הפרימיטיבים של FF API
SchedUlTriggerReq ו SchedUlTriggerReq. על פי משוב HARQ וה- RLC
מצב buffers, המתזמן יוצר קבוצה של DCIs הכוללת את שתי השידורים החוזרים של
בלוקים HARQ קיבלו שידורים שגויים וחדשים, באופן כללי, נותנים עדיפות ל
לְשֶׁעָבַר. בעניין זה, המתזמן צריך לקחת בחשבון אילוץ אחד מתי
הקצאת המשאב לשידורים חוזרים של HARQ, עליו להשתמש באותו סדר אפנון של
ניסיון השידור הראשון (כלומר, QPSK עבור MCS ב-[0..9], 16QAM עבור MCS ב-[10..16]
ו-64QAM עבור MCS ב-[17..28]). הגבלה זו נובעת ממפרט התעריף
matcher בתקן 3GPP [TS36212], שבו האלגוריתם מתקן את סדר האפנון עבור
יצירת הבלוקים השונים של גרסאות היתירות.

מודל PHY Error Model (כלומר, ה LteMiErrorModel כיתה כבר הוצגה בעבר) יש
הוארך לשקול IR HARQ לפי [wimaxEmd], שבו הפרמטרים עבור
מיפוי עקומות AWGN עבור מיפוי MIESM במקרה של שידורים חוזרים ניתנים על ידי:

כאשר X הוא מספר סיביות המידע המקוריות, C_i הם מספר הסיביות המקודדות, M_i הם
המידע ההדדי לכל בלוק HARQ שהתקבל על המספר הכולל של שידורים חוזרים q.
לכן, על מנת שניתן יהיה להחזיר את הסתברות השגיאה עם מודל השגיאה
מיושם בסימולטור מעריך את ה-R_{eff} ואת ה-MI_{I eff} ומחזיר את הערך
של הסתברות שגיאה של ECR של אותה אפנון עם הקצב הנמוך הקרוב ביותר ביחס ל
ה-R_{eff}. על מנת לשקול את ההשפעה של שידורים חוזרים של HARQ, קבוצות חדשות של עקומות
שולבו ביחס לסטנדרט המשמש ל-MCS המקורי. הקימורים החדשים
מיועדים לכיסוי המקרים שבהם נעשה שימוש ב-MCS השמרני ביותר של אפנון
מה שמרמז על יצירת כבוד נמוך יותר של R_{eff} לזה של MCS סטנדרטיים. על זה
משנה, העקומות עבור שידורים חוזרים של 1, 2 ו-3 הוערכו עבור 10 ו-17.
MCS 0 שקלנו רק את השידור החוזר הראשון מכיוון שקצב הקוד שהופק כבר
שמרני מאוד (כלומר, 0.04) ומחזיר שיעור שגיאה חזק מספיק עבור הקליטה
(כלומר, הירידה של ה-BLER מרוכזת סביב -18 dB). יצוין כי, ה
ההנחה היא שהגודל של שידור ה-TB הראשון מכיל את כל סיביות המידע
להיות מקודד; לכן X שווה לגודל ה-TB הראשון שנשלח בתהליך HARQ. ה
המודל מניח שהנוכחות הסופית של סיביות זוגיות במילות הקוד כבר קיימת
נחשב בעקומות רמת הקישור. זה מרמז שברגע שהמינימום R_{eff} הוא
הגיע המודל אינו כולל את הרווח עקב העברת שוויון נוסף
ביטים.
[תמונה] HARQ מעבד התנהגות ב-LTE.UNINDENT

החלק של HARQ שהוקדש לניהול הפענוח של בלוקי HARQ היה
מיושם ב LteHarqPhy ו LteSpectrumPhy שיעורים. הראשון אחראי על
שמירה על מידע HARQ עבור כל תהליך פעיל. האחרון מקיים אינטראקציה עם
LteMiErrorModel מחלקה להערכת נכונות הבלוקים שהתקבלו וכוללת
אלגוריתם ההודעות שאחראי על התקשורת לישות HARQ במתזמן
התוצאה של הפענוחים. הודעות אלו מובלעות ב-
dlInfoListElement עבור DL ו ulInfoListElement עבור UL ונשלח דרך PUCCH וה-
PHICH בהתאמה עם מודל נטול שגיאות אידיאלי לפי ההנחות שלהם
יישום. שרטוט של האיטרציה בין פרוטוקול HARQ ו-LTE
מיוצג באיור:ref:תאנים-חרק-אדריכלות.

לבסוף, מנוע HARQ פעיל תמיד הן בשכבת MAC והן בשכבת PHY; עם זאת, במקרה של
המתזמן אינו תומך ב-HARQ, המערכת תמשיך לעבוד עם ה-HARQ
פונקציות מעוכבות (כלומר, מאגרים ממולאים אך אינם בשימוש). יישום זה
מאפיין נותן תאימות לאחור עם מתזמנים שיושמו לפני HARQ
שילוב.
[תמונה] אינטראקציה בין ערימת פרוטוקול HARQ ו-LTE.UNINDENT

מק
משאב הַקצָאָה מספר סימוכין
כעת אנו מתארים בקצרה כיצד מטופלת הקצאת משאבים ב-LTE, ומבהירה כיצד היא
מעוצב בסימולטור. המתזמן אחראי על יצירת מבנים ספציפיים
נקרא נתונים שליטה סִימָן (DCI) אשר מועברים לאחר מכן על ידי ה-PHY של ה-eNB אל
ה-UEs המחוברים, על מנת ליידע אותם על הקצאת המשאבים בכל תת-מסגרת
בָּסִיס. כשעושים זאת בכיוון ההורדה, המתזמן צריך למלא משהו ספציפי
שדות של מבנה DCI עם כל המידע, כגון: המודולציה והקידוד
Scheme (MCS) לשימוש, גודל ה-MAC Transport Block (TB) ומפת הסיביות של ההקצאה
אשר מזהה אילו RBs יכילו את הנתונים המשודרים על ידי ה-eNB לכל משתמש.

למיפוי משאבים ל-RBs פיזי, אנו מאמצים א מקומי מיפוי גישה (ראה
[Sesia2009], סעיף 9.2.2.1); מכאן שבתת-מסגרת נתונה כל RB מוקצה תמיד
אותו משתמש בשני המשבצות. ניתן לקודד את מפת הסיביות של ההקצאה בפורמטים שונים; ב
יישום זה, שקלנו את הַקצָאָה סוּג 0 מוגדר ב-[TS36213], לפי
אליהם מקובצים ה-RBs בקבוצות בלוק משאבים (RBG) בגודל שונה שנקבע
כפונקציה של תצורת רוחב הפס של השידור בשימוש.

עבור ערכי רוחב פס מסוימים לא כל ה-RBs ניתנים לשימוש, מכיוון שגודל הקבוצה אינו a
מחלק משותף של הקבוצה. זה למשל המקרה כאשר רוחב הפס שווה ל
25 RBs, מה שמביא לגודל RBG של 2 RBs, ולכן 1 RB לא יביא
ניתן להתייחסות. ב-uplink הפורמט של DCIs שונה, מכיוון שרק RBs סמוכים יכולים
לשמש בגלל אפנון SC-FDMA. כתוצאה מכך, ניתן להקצות את כל RBs על ידי
ה-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 רחב פס, ה
reference TB כולל את כל ה-RBGs הזמינים על מנת לקבל הפניה המבוססת על
משאבים זמינים שלמים; בעוד, עבור subband CQIs, גודל ההתייחסות TB הוא כ-RBGs.

תחבורה לחסום מודל
המודל של MAC Transport Blocks (TBs) המסופק על ידי הסימולטור הוא פשוט עם
כבוד למפרטי 3GPP. בפרט, שיעור ספציפי לסימולטור
(PacketBurst) משמש לצבירה של MAC SDUs על מנת להשיג את המקבילה של הסימולטור
של שחפת, ללא מורכבות היישום המקבילה. הריבוי של
ערוצים לוגיים שונים לשכבת RLC וממנה מתבצעים באמצעות חבילה ייעודית
תג (LteRadioBearerTag), המבצע פונקציונליות ששווה בחלקה ל
זה של כותרות ה-MAC שצוינו על ידי 3GPP.

השמיים FemtoForum מק מתזמן מִמְשָׁק
סעיף זה מתאר את הגרסה הספציפית של ns-3 של ממשק LTE MAC Scheduler
מפרט שפורסם על ידי FemtoForum [FFAPI].

הטמענו את הגרסה הספציפית של ns-3 של ממשק ה-FemtoForum MAC Scheduler [FFAPI]
כקבוצה של מחלקות מופשטות של C++; בפרט, כל פרימיטיבי מתורגם ל-C++
שיטה של ​​מחלקה נתונה. התנאי יושם כאן נעשה שימוש באותה משמעות שאומצה
ב-[FFAPI], ומכאן מתייחס לתהליך תרגום הממשק הלוגי
מפרט לשפת תכנות מסוימת. הפרימיטיבים ב-[FFAPI] מקובצים
בשתי קבוצות: הפרימיטיבים של CSCHED, העוסקים בתצורת מתזמן, וה-
פרימיטיבים של SCHED, העוסקים בביצוע המתזמן. יתר על כן, [FFAPI]
מגדיר פרימיטיבים משני סוגים שונים: אלה מסוג 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 Scheduler: בלוק בקרה, בלוק Subframe
ובלוק מתזמן. כל אחד מהבלוקים הללו מספק חלק אחד בממשק MAC Scheduler.
האיור שלהלן מראה את היחס בין הבלוקים וה-SAPs המוגדרים אצלנו
יישום ממשק מתזמן MAC.
[תמונה]

בנוסף לעקרונות שלעיל, נבחרו בחירות העיצוב הבאות:

· ההגדרה של מחלקות ממשק MAC Scheduler עוקבת אחר מוסכמות השמות
של ns-3 סגנון קידוד. בפרט, אנו עוקבים אחר אמנת CamelCase עבור
שמות פרימיטיביים. למשל, הפרימיטיבי CSCHED_CELL_CONFIG_REQ מתורגם ל
CschedCellConfigReq ב ns-3 קוד.

· לפי אותן מוסכמות שמות עבור הפרמטרים הפרימיטיביים. בתור ה
פרמטרים פרימיטיביים הם משתני חבר של מחלקות, הם גם מקבלים קידומת a
m_.

· לגבי השימוש בוקטורים ורשימות במבני נתונים, נציין כי [FFAPI] הוא א
ממש ממשק API מכוון C. עם זאת, נחשב ש-C++ משמש ב-ns-3, וזה
השימוש במערכים C אינו מעודד, השתמשנו בוקטורים STL (std :: וקטור) בשביל ה
יישום של ממשק מתזמן 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 שלנו
המופיעים בסעיפים הבאים.

עָגוֹל אדום החזה (RR) מתזמן
מתזמן הרובין העגול (RR) הוא כנראה המתזמן הפשוט ביותר שנמצא בספרות.
זה עובד על ידי חלוקת המשאבים הזמינים בין הזרמים הפעילים, כלומר אלה הלוגיים
ערוצים שיש להם תור RLC לא ריק. אם מספר ה-RBGs גדול מה-
מספר זרימות פעילות, ניתן להקצות את כל הזרימות באותה תת-מסגרת. אחרת, אם
מספר הזרימות הפעילות גדול ממספר ה-RBGs, לא כל הזרימות יכולות להיות
מתוזמן בתת מסגרת נתונה; לאחר מכן, בתת המסגרת הבאה ההקצאה תתחיל ממנה
התזרים האחרון שלא הוקצה. ה-MCS שיאומץ עבור כל משתמש נעשה
לפי ה-CQIs רחב הפס שהתקבלו.

לעניין ה-HARQ, RR מיישמת את הגרסה הלא אדפטיבית, מה שמרמז כי ב
הקצאת ניסיונות השידור החוזר RR משתמש באותה תצורת הקצאה של
בלוק מקורי, כלומר שמירה על אותם RBGs ו-MCS. UEs שהוקצו עבור
שידורים חוזרים של HARQ אינם נחשבים להעברת נתונים חדשים במקרה שיש להם
אפשרות שידור זמינה באותו TTI. לבסוף, ניתן להשבית את HARQ
מערכת תכונות ns3 לשמירה על תאימות לאחור עם מקרי בדיקה וקוד ישנים,
בפירוט:

Config::SetDefault ("ns3::RrFfMacScheduler::HarqEnabled", BooleanValue (false));

המתזמן מיישם את הסינון של CQIs uplink בהתאם לאופי שלהם עם
UlCqiFilter תכונה, בפירוט:

· SRS_UL_CQI: רק CQI מבוסס SRS מאוחסנים בתכונות הפנימיות.

· PUSCH_UL_CQI: רק CQI מבוסס PUSCH מאוחסנים בתכונות הפנימיות.

· ALL_UL_CQI: כל CQIs מאוחסנים באותה תכונה פנימית (כלומר, CQI האחרון
שהתקבל מאוחסן באופן עצמאי מטבעו).

פרופורציונאלי יריד (FP) מתזמן
מתזמן ה-Proportional Fair (PF) [Sesia2009] פועל על ידי תזמון משתמש כאשר
איכות הערוץ המיידית גבוהה יחסית למצב הערוץ הממוצע שלו
זְמַן. תן i,j לציין משתמשים גנריים; תן t להיות אינדקס המשנה, ו-k יהיה המשאב
מדד בלוק; תן ל-M_{i,k}(t) להיות MCS שמיש על ידי משתמש i בבלוק משאבים k לפי מה
דווח על ידי דגם AMC (ראה מסתגל אפנון ו סִמוּל); לבסוף, תן S(M,B) להיות
גודל ה-TB בסיביות כפי שהוגדר ב-[TS36213] למקרה שבו מספר B של משאב
נעשה שימוש בלוקים. הקצב שניתן להשיג R_{i}(k,t) בסיביות/שניות עבור משתמש i בקבוצת בלוק משאבים
k בתת-מסגרת t מוגדרת כ

כאשר au הוא משך ה-TTI. בתחילת כל תת-מסגרת t, כל RBG מוקצה ל-a
משתמש מסוים. בפירוט, האינדקס 144}_{k}(t) שאליו מוקצה RBG k בזמן t הוא
נקבע כ

כאשר T_{j}(t) הוא ביצועי התפוקה בעבר שנתפסו על ידי המשתמש j. לפי
אלגוריתם התזמון לעיל, ניתן להקצות משתמש ל-RBGs שונים, אשר יכולים להיות
סמוך או לא, תלוי במצב הנוכחי של הערוץ ובעבר
ביצועי תפוקה T_{j}(t). האחרון נקבע בסוף תת-מסגרת t
תוך שימוש בגישת הממוצע הנע האקספוננציאלי הבא:

כאשר lpha הוא קבוע הזמן (במספר תת-פריימים) של התנועה המעריכית
ממוצע, ו-384s התפוקה בפועל שהושג על ידי המשתמש i בתת-מסגרת t. 360 הוא
נמדד לפי הנוהל הבא. ראשית אנו קובעים את ה-MCS 840 j:

אז אנו קובעים את המספר הכולל 936 j:

איפה |

לעניין ה-HARQ, PF מיישם את הגרסה הלא אדפטיבית, מה שמרמז על כך שב
הקצאת ניסיונות השידור החוזר המתזמן משתמש באותה הקצאה
תצורה של הבלוק המקורי, כלומר שמירה על אותם RBGs ו-MCS. UEs
שהוקצו עבור שידורים חוזרים של HARQ אינם נחשבים לשידור של חדש
נתונים במקרה שיש להם הזדמנות שידור זמינה באותו TTI. לבסוף, HARQ
ניתן להשבית עם מערכת תכונות 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) להיות גודל ה-TB בסיביות כפי שהוגדר ב
[TS36213] למקרה שבו נעשה שימוש במספר B של בלוקים של משאבים. השיעור בר השגה
R_{i}(k,t) ב-bit/s עבור משתמש i בבלוק המשאב k בתת-מסגרת t מוגדר כ

כאשר au הוא משך ה-TTI. בתחילת כל תת-מסגרת t, כל RB מוקצה ל-a
משתמש מסוים. בפירוט, האינדקס 144}_{k}(t) שאליו מוקצה RB k בזמן t הוא
נקבע כ

כאשר יש מספר UEs עם אותו שיעור בר השגה, היישום הנוכחי תמיד
בוחר את ה-UE הראשון שנוצר בסקריפט. למרות ש-MT יכול למקסם את תפוקת התא, זה
לא יכול לספק הוגנות ל-UEs במצב ערוץ גרוע.

התפוקה ל מְמוּצָע (TTA) מתזמן
מתזמן התפוקה לממוצע (TTA) [FCapo2012] יכול להיחשב כאמצעי ביניים
בין MT ל-PF. המדד המשמש ב-TTA מחושב באופן הבא:

כאן, R_{i}(k,t) בסיביות/שניות מייצג את הקצב שניתן להשיג עבור משתמש i בבלוק המשאב k ב
תת מסגרת t. שיטת החישוב כבר מוצגת ב-MT וב-PF. בינתיים, R_{i}(t) ב
bit/s מייצג את הקצב שניתן להשיג עבור i בתת-מסגרת t. ההבדל בין שני אלה
שיעורים בר השגה הם איך להשיג MCS. עבור R_{i}(k,t), MCS מחושב על ידי תת-הפס CQI while
R_{i}(t) מחושב על ידי CQI רחב פס. מתזמן TTA יכול להיות מיושם רק בתדירות
תחום (FD) מכיוון שהשיעור הניתן להשגה של RBG מסוים קשור רק ל-FD
תזמון.

עיוור מְמוּצָע התפוקה מתזמן
מתזמן התפוקה הממוצע העיוור [FCapo2012] שואף לספק תפוקה שווה לכולם
UEs תחת eNB. המדד המשמש ב-TTA מחושב באופן הבא:

כאשר T_{j}(t) הוא ביצועי התפוקה בעבר שנתפס על ידי המשתמש j ויכול להיות
מחושב באותה שיטה ב-PF מתזמן. תפוקה ממוצעת עיוור בתחום הזמן
(TD-BET), המתזמן בוחר את ה-UE עם מדד העדיפות הגדול ביותר ומקצה את כל ה-RBGs
ל-UE זה. מצד שני, בתחום התדרים תפוקה ממוצעת עיוור (FD-BET),
בכל TTI, המתזמן בוחר תחילה UE אחד עם תפוקת העברהממוצעת הנמוכה ביותר (הגדולה ביותר
מדד עדיפות). אז מתזמן מקצה RBG אחד ל-UE זה, הוא מחשב את הצפוי
תפוקה של UE זה ומשתמשת בו כדי להשוות עם תפוקה ממוצעת בעבר T_{j}(t) של
UEs אחרים. המתזמן ממשיך להקצות RBG ל-UE זה עד הצפוי שלו
התפוקה אינה הקטן ביותר מבין התפוקה הממוצעת בעבר T_{j}(t) מכל ה-UE. לאחר מכן
המתזמן ישתמש באותה דרך כדי להקצות RBG עבור UE חדש בעל העבר הנמוך ביותר
תפוקה ממוצעת T_{j}(t) עד שכל ה-RBGs מוקצים ל-UEs. העיקרון מאחורי זה
הוא שבכל TTI, המתזמן מנסה כמיטב יכולתו להשיג את התפוקה השווה בין
כל ה-UEs.

אסימון בנק יריד תור מתזמן
Token Bank Fair Queue (TBFQ) הוא מתזמן מודע ל-QoS שנובע מהדלי הדולף
מַנגָנוֹן. ב-TBFQ, זרימת תעבורה של משתמש i מאופיינת בפרמטרים הבאים:

· t_{i}: קצב הגעת מנות (בתים/שנייה)

· r_{i}: קצב יצירת אסימון (בייט/שנייה)

· p_{i}: גודל מאגר אסימונים (בייט)

· E_{i}: מונה שמתעד את מספר האסימון שהושאל מהאסימון או ניתן לו
בנק לפי תזרים i; E_{i} יכול להיות קטן מאפס

כל נתוני K בתים צורכים k אסימונים. כמו כן, TBFQ שומרת על בנק אסימונים משותף (B) כדי לעשות זאת
לאזן את התנועה בין זרימות שונות. אם קצב יצירת האסימון r_{i} גדול מ
קצב הגעת מנות t_{i}, ואז אסימונים שעולים על גדותיהם ממאגר האסימונים מתווספים לאסימון
בנק, ו-E_{i} מוגדל באותו סכום. אחרת, זרימה אני צריכה לסגת
אסימונים מבנק האסימונים המבוססים על ערך עדיפות{E_{i}}{r_{i}}, ו-E_{i} הוא
ירד. ברור שהמשתמש תורם יותר לבנק האסימונים יש עדיפות גבוהה יותר
לשאול אסימונים; מצד שני, המשתמש לווה יותר אסימונים מהבנק יש נמוך יותר
עדיפות להמשיך למשוך אסימונים. לכן, במקרה של מספר משתמשים שיש להם את
אותו קצב יצירת אסימון, קצב תעבורה וגודל מאגר אסימון, המשתמש סובל מגבוה יותר
להפרעות יש יותר הזדמנות ללוות אסימונים מהבנק. בנוסף, TBFQ יכול לשוטר
את התעבורה על ידי הגדרת קצב יצירת האסימון כדי להגביל את התפוקה. בנוסף,
TBFQ גם שומרת על שלושה פרמטרים הבאים עבור כל זרימה:

· מגבלת חוב d_{i}: אם E_{i} מתחת לסף זה, למשתמש אין אפשרות ללוות עוד אסימונים
מהבנק. זה נועד למנוע מ-UE זדוני לשאול יותר מדי אסימונים.

· תקרת אשראי c_{i}: המספר המרבי של אסימונים UE i יכול ללוות מהבנק באחד
הזמן.

· סף אשראי C: ברגע ש-E_{i} מגיע למגבלת החוב, UE i חייב לאחסן אסימוני 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) הוא מתזמן מודע ל-QoS המשלב תחום זמן (TD) ו
פעולות תזמון מנות של תחום תדר (FD) לתוך מתזמן אחד [GMonghal2008]. זה
שולט בהוגנות בין UEs על ידי קצב סיביות מוגדר (TBR).

בחלק של מתזמן TD, PSS בוחר תחילה UEs עם מאגר RLC לא ריק ולאחר מכן מחלק אותם
לשתי קבוצות המבוססות על TBR:

· סט 1: UE שתפוקת העבר הממוצעת שלו קטנה מ-TBR; מתזמן TD מחשב
מדד העדיפות שלהם בסגנון עיוור שווה תפוקה (BET):

· סט 2: UE שתפוקת העבר הממוצעת שלו גדולה (או שווה) מ-TBR; מתזמן TD
מחשב את מדד העדיפות שלהם בסגנון הוגן פרופורציונלי (PF):

UEs השייכים לסט 1 הם בעלי עדיפות גבוהה יותר מאלו בסט 2. אז PSS יבחר
N_{mux} UEs עם המדד הגבוה ביותר בשתי סטים ומעבירים את ה-UE האלה למתזמן FD. ב-PSS,
מתזמן FD מקצה RBG k ל-UE n שממקסם את המדד הנבחר. שני מתזמני PF
משמשים בתזמון PF:

· יריד פרופורציונלי מתוכנן (PFsch)

· ספק מעל הפרעות לממוצע (CoIta)

כאשר Tsch_{j}(t) הוא ביצועי תפוקה דומים בעבר שנתפסו על ידי המשתמש j, עם ה-
ההבדל הוא שהוא מתעדכן רק כאשר המשתמש ה-i מוגש בפועל. CoI[j,k] הוא an
אומדן ה-SINR על ה-RBG k של UE j. גם PFsch וגם CoIta מיועדים לניתוק FD
מדד מתזמן TD. בנוסף, מתזמן PSS FD מספק גם מדד משקל W[n]
לסיוע בשליטה בהוגנות במקרה של מספר נמוך של UEs.

כאשר T_{j}(t) הוא ביצועי התפוקה בעבר שנתפס על ידי המשתמש j . לכן, על
RBG k, מתזמן ה-FD בוחר את ה-UE j שממקסם את המכפלה של התדר
מדד תחום (Msch, MCoI) לפי משקל W[n]. אסטרטגיה זו תבטיח את התפוקה של
UE באיכות נמוכה יותר נוטה לכיוון ה-TBR.

Config::SetDefault ("ns3::PfFfMacScheduler::HarqEnabled", BooleanValue (false));

המתזמן מיישם את הסינון של CQIs uplink בהתאם לאופי שלהם עם
UlCqiFilter תכונה, בפירוט:

· SRS_UL_CQI: רק CQI מבוסס SRS מאוחסנים בתכונות הפנימיות.

· PUSCH_UL_CQI: רק CQI מבוסס PUSCH מאוחסנים בתכונות הפנימיות.

· ALL_UL_CQI: כל CQIs מאוחסנים באותה תכונה פנימית (כלומר, CQI האחרון
שהתקבל מאוחסן באופן עצמאי מטבעו).

ערוץ ו QoS מודע מתזמן
מתזמן ערוץ ו-QoS Aware (CQA) [Bbojovic2014] הוא תזמון LTE MAC downlink
אלגוריתם שמתחשב בהשהיית head of line (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 עבור המשתמש
j ומחושב באופן הבא:

כאשר CQI^{(k,j)}(t) הוא ערך ה-CQI האחרון שדווח ממשתמש j עבור ה-k-th RBG.

המשתמש יכול לבחור אם נעשה שימוש ב-m_{pf} או m_{ff} על-ידי הגדרת התכונה
ns3::CqaFfMacScheduler::CqaMetric בהתאמה ל "CqaPf" or "CqaFf".

אַקרַאִי גִישָׁה
מודל ה-LTE כולל מודל של הליך גישה אקראית המבוסס על פישוט מסוים
הנחות היסוד, המפורטות להלן עבור כל אחד מהמסרים והאותות
המתואר במפרט [TS36321].

· אַקרַאִי גִישָׁה (צְפַרְדֵעַ) הַקדָמָה: במערכות LTE אמיתיות זה מתאים ל-Zadoff-Chu
רצף (ZC) באמצעות אחד מכמה פורמטים הזמינים ונשלחים בחריצי PRACH
דבר שיכול באופן עקרוני לחפוף עם PUSCH. PRACH Configuration Index 14 הוא
בהנחה, כלומר, ניתן לשלוח הקדמות בכל מספר מסגרת מערכת ומספר תת מסגרת.
הקדמת RA מעוצבת באמצעות מחלקת LteControlMessage, כלומר, כאידיאל
הודעה שאינה צורכת משאבי רדיו. ההתנגשות של ההקדמה
שידור על ידי מספר UEs באותו תא מעוצב באמצעות פרוטוקול
מודל הפרעות, כלומר, בכל פעם שמועברות פנימה שתי הקדמות זהות או יותר
אותו תא באותו TTI, אף אחת מהמקדמות זהות לא תתקבל על ידי
ה-eNB. מלבד מודל התנגשות זה, אין מודל שגיאה משויך ל-
קבלה של הקדמת RA.

· אַקרַאִי גִישָׁה תְגוּבָה (RAR): במערכות LTE אמיתיות, זהו MAC PDU מיוחד שנשלח הלאה
ה-DL-SCH. מכיוון שרכיבי בקרת MAC אינם מעוצבים במדויק בסימולטור
(רק PDUs RLC ומעלה), ה-RAR מעוצב כ-LteControlMessage שעושה
לא לצרוך משאבי רדיו. ובכל זאת, במהלך הליך RA, ה-LteEnbMac יעשה זאת
לבקש למתזמן הקצאת משאבים עבור ה-RAR באמצעות ה-FF MAC
מתזמן פרימיטיבי SCHED_DL_RACH_INFO_REQ. לפיכך, מתזמן משופר
יישום (לא זמין כרגע) יכול להקצות משאבי רדיו עבור
RAR, ובכך מיידל את הצריכה של משאבי רדיו לשידור של
RAR.

· הערות נוספות 3: במערכות LTE אמיתיות, זהו RLC TM SDU שנשלח על המשאבים שצוינו
במענק UL ב-RAR. בסימולטור, זה מעוצב כמו RLC TM RLC אמיתי
PDU שמשאבי ה-UL שלו מוקצים על ידי המתזמן בעת ​​קריאה אליו
SCHED_DL_RACH_INFO_REQ.

· מַחֲלוֹקֶת החלטה (CR): במערכת LTE אמיתית, יש צורך בשלב ה-CR כדי לטפל ב
מקרה שבו שניים או יותר UE שלחו את אותה הקדמת RA באותו TTI, וה-eNB היה
מסוגל לזהות את ההקדמה הזו למרות ההתנגשות. מאז האירוע הזה לא
להתרחש עקב מודל הפרעות הפרוטוקול המשמש לקליטת הקדמות RA,
שלב ה-CR אינו מעוצב בסימולטור, כלומר, ה-CR MAC CE לעולם לא נשלח על ידי
ה-eNB וה-UEs מחשיבים את ה-RA כמוצלח עם קליטת ה-RAR. כ
כתוצאה מכך, משאבי הרדיו הנצרכים לשידור של ה-CR MAC CE הם
לא מעוצב.

תרשים רצף תרשים of מה היא מבוסס מחלוקת מק אַקרַאִי גִישָׁה הליך ו רצף
תרשים of מה היא לא מבוסס מחלוקות מק אַקרַאִי גִישָׁה הליך מציג את הרצף
דיאגרמות של גישה אקראית של MAC המבוססת על מחלוקת ולא מבוססת מחלוקות
נוהל, המדגיש את האינטראקציות בין ה-MAC לבין הישויות האחרות.
[תמונה] דיאגרמת רצף של נוהל גישה אקראית של MAC מבוסס עימות. UNINDENT
[תמונה] דיאגרמת רצף של גישה אקראית של MAC ללא מחלוקת
הליך.UNINDENT

RLC
סקירה כללית
ישות ה-RLC מצוינת במפרט הטכני של 3GPP [TS36322], וכוללת
שלושה סוגים שונים של RLC: מצב שקוף (TM), מצב ביטול אישור (UM) ו
מצב מאושר (AM). הסימולטור כולל דגם אחד עבור כל אחד מהישויות הללו

ישויות RLC מספקות את ממשק שירות RLC לשכבת PDCP העליונה ול-MAC
ממשק שירות לשכבת ה-MAC התחתונה. ישויות RLC משתמשות בממשק שירות PDCP
משכבת ​​PDCP העליונה ומממשק שירות MAC משכבת ​​MAC התחתונה.

תרשים יישום מספר סימוכין of PDCP, RLC ו מק ישויות ו SAPs מציג את
מודל הטמעה של ישויות RLC והקשר שלו עם כל הישויות האחרות
ושירותים בערימת הפרוטוקולים.
[תמונה] מודל יישום של ישויות PDCP, RLC ו-MAC ו-SAPs.UNINDENT

שֵׁרוּת ממשקים
RLC שֵׁרוּת מִמְשָׁק
ממשק השירות RLC מחולק לשני חלקים:

· ה RlcSapProvider חלק מסופק על ידי שכבת RLC ומשמש את שכבת PDCP העליונה
ו

· ה RlcSapUser חלק מסופק על ידי שכבת PDCP העליונה ומשמש את שכבת RLC.

הן הישויות UM והן הישויות AM RLC מספקות את אותו ממשק שירות RLC לעליון
שכבת PDCP.

RLC שֵׁרוּת פרימיטיבים
הרשימה הבאה מציינת אילו פרימיטיבים של שירות מסופקים על ידי שירות RLC
ממשקים:

· RlcSapProvider::TransmitPdcpPdu

· ישות ה-PDCP משתמשת בפרימיטיבי הזה כדי לשלוח PDCP PDU לישות ה-RLC התחתונה
בעמית המשדר

· RlcSapUser::ReceivePdcpPdu

· ישות RLC משתמשת בפרימיטיבי הזה כדי לשלוח PDCP PDU לישות PDCP העליונה
בעמית המקלט

מק שֵׁרוּת מִמְשָׁק
ממשק שירות MAC מחולק לשני חלקים:

· ה MacSapProvider החלק מסופק על ידי שכבת ה-MAC ומשמש את שכבת ה-RLC העליונה
ו

· ה 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.

חוצצים ל מה היא לְהַעֲבִיר פעולות
היישום שלנו של ישות AM RLC שומר על 3 מאגרים עבור פעולות השידור:

· תִמסוֹרֶת בלם: זהו תור RLC SDU. כאשר ישות AM RLC מקבלת SDU
בשירות הפרימיטיבי של TransmitPdcpPdu מהישות העליונה PDCP, הוא מעמיד אותו בתור
במאגר ההילוכים. שמנו מגבלה על גודל המאגר RLC ופשוט בשקט
שחרר SDUs כאשר המאגר מלא.

· מועבר PDUs בלם: זהו התור של RLC PDUs משודרים שעבורו יש
ACK/NACK עדיין לא התקבל. כאשר ישות AM RLC שולחת PDU ל-MAC
ישות, היא גם שמה עותק של ה-PDU המשודר במאגר ה-PDUs המשודר.

· שידור חוזר בלם: זה התור של RLC PDUs אשר נחשבים עבור
שידור חוזר (כלומר, הם עברו NACK). ישות AM RLC מעבירה PDU זה ל-
מאגר שידור חוזר, כאשר הוא משדר מחדש PDU מהמאגר המשודר.

לשדר פעולות in downlink
תרשים הרצף הבא מציג את האינטראקציות בין הישויות השונות (RRC,
מתזמן PDCP, AM RLC, MAC ו-MAC) של ה-eNB ב-downlink לביצוע נתונים
תקשורת.

תרשים רצף תרשים of נתונים PDU תמסורת in downlink מראה כיצד השכבות העליונות
שליחת נתונים PDUs וכיצד זרימת הנתונים מעובדת על ידי הישויות/שירותים השונים של
ערימת פרוטוקול LTE.
[תמונה] דיאגרמת רצף של העברת נתונים PDU ב-downlink.UNINDENT

ישות PDCP קוראת ל- שידור_PDCP_PDU שרות פרימיטיבי על מנת לשלוח נתונים
PDU. ישות AM RLC מעבדת שירות פרימיטיבי זה בהתאם לנתוני AM
נהלי העברה המוגדרים בסעיף 5.1.3 של [TS36322].

כאשר שידור_PDCP_PDU שירות פרימיטיבי נקרא, הישות AM RLC מבצעת את
הפעולות הבאות:

· הכנס את SDU הנתונים למאגר השידור.

· מחשב את גודל המאגרים (איך יחושבו גודל המאגרים
הוסבר לאחר מכן).

· תתקשר ל Report_Buffer_Status שירות פרימיטיבי של ישות eNB MAC על מנת
להודיע ​​לישות eNB MAC על הגדלים של המאגרים של ישות AM RLC. אז ה
ישות MAC eNB מעדכנת את מצב המאגר במתזמן ה-MAC באמצעות
שירות SchedDlRlcBufferReq פרימיטיבי של ממשק ה-API של FF MAC Scheduler.

לאחר מכן, כאשר מתזמן ה-MAC מחליט שניתן לשלוח נתונים מסוימים, ישות ה-MAC
מודיע על כך לישות RLC, כלומר היא קוראת ל- הודע_Tx_Opportunity שירות פרימיטיבי,
אז הישות AM RLC עושה את הפעולות הבאות:

· צור PDU נתונים יחיד על ידי פילוח ו/או שרשור ה-SDUs ב-
מאגר הילוכים.

· העבר את PDU הנתונים ממאגר השידור למאגר ה-PDUs המשודר.

· עדכון משתני מצב בהתאם לסעיף 5.1.3.1.1 של [TS36322].

· תתקשר ל שידור_PDU פרימיטיבי על מנת לשלוח את PDU הנתונים לישות MAC.

שידור חוזר in downlink
דיאגרמת הרצף של איור רצף תרשים of נתונים PDU שידור חוזר in downlink
מציג את האינטראקציות בין הישויות השונות (AM RLC, MAC ומתזמן MAC) של
ה-eNB ב-downlink כאשר PDUs נתונים חייבים להיות משודרים מחדש על ידי ישות AM RLC.
[תמונה] דיאגרמת רצף של שידור מחדש של נתונים PDU ב-downlink.UNINDENT

ישות AM RLC המשדרת יכולה לקבל STATUS PDUs מהישות AM RLC העממית.
STATUS PDUs נשלחים בהתאם לסעיף 5.3.2 של [TS36322] והעיבוד של
הקליטה מתבצעת בהתאם לסעיף 5.2.1 של [TS36322].

כאשר PDUs נתונים משודרים מחדש ממאגר ה-PDUs המשודר, הוא גם מועבר אל
מאגר השידור החוזר.

לשדר פעולות in uplink
דיאגרמת הרצף של איור רצף תרשים of נתונים PDU תמסורת in uplink מופעים
האינטראקציות בין הישויות השונות של ה-UE (RRC, PDCP, RLC ו-MAC) וה
eNB (MAC ומתזמן) ב-uplink כאשר PDUs נתונים נשלחים על ידי השכבות העליונות.
[תמונה] דיאגרמת רצף של העברת נתונים PDU ב-uplink.UNINDENT

זה דומה לתרשים הרצף ב-downlink; ההבדל העיקרי הוא שבזה
במקרה ש-Report_Buffer_Status נשלח מ-UE MAC למתזמן MAC ב-eNB
באוויר באמצעות ערוץ הבקרה.

שידור חוזר in uplink
דיאגרמת הרצף של איור רצף תרשים of נתונים PDU שידור חוזר in uplink מופעים
האינטראקציות בין הישויות השונות של ה-UE (AM RLC ו-MAC) וה-eNB
(MAC) ב-uplink כאשר PDUs נתונים חייבים להיות משודרים מחדש על ידי ישות AM RLC.
[תמונה] דיאגרמת רצף של שידור מחדש של נתונים PDU ב-uplink.UNINDENT

תחשיב of מה היא חיץ גודל
מאגר השידור מכיל RLC SDUs. PDU RLC הוא מקטע SDU אחד או יותר בתוספת
כותרת RLC. גודל כותרת RLC של RLC PDU אחד תלוי במספר ה-SDU
מקטעים שה-PDU מכיל.

תקן 3GPP (סעיף 6.1.3.1 של [TS36321]) אומר בבירור כי עבור ה-uplink,
כותרות RLC ו-MAC אינן נחשבות בגודל המאגר שיש לדווח כחלק ממנו
דוח מצב המאגר. עבור ה-downlink, ההתנהגות לא צוינה. לא זה ולא זה
[FFAPI] מציין כיצד לעשות זאת. מודל RLC שלנו עובד על ידי הנחה שהחישוב של
גודל המאגר ב-downlink נעשה בדיוק כמו ב-uplink, כלומר, לא לוקח בחשבון
גודל הכותרת RLC ו-MAC.

אנו מציינים שבחירה זו משפיעה על הפעולה ההדדית עם מתזמן MAC, שכן, ב
תגובה ל הודע_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 for AM RLC. ב
מיוחד:

· אין ביטול SDU שנמסר על ידי PDCP

· אין הודעה על מסירה מוצלחת/נכשלה על ידי ישות AM RLC לישות PDCP

UM RLC
בסעיף זה אנו מתארים את ההטמעה של הישות RLC של מצב Unacknowledge (UM).

לשדר פעולות in downlink
פעולות השידור של UM RLC דומות לאלו של AM RLC בעבר
המתואר בסעיף לשדר פעולות in downlink, בהבדל שבהמשך
המפרטים של [TS36322], שידור חוזר לא מבוצע, ואין סטטוס
PDUs.

לשדר פעולות in uplink
פעולות השידור ב-uplink דומות לאלו של ה-downlink, עם הראשי
הבדל ש-Report_Buffer_Status נשלח מה-UE MAC למתזמן MAC ב
ה-eNB באוויר באמצעות ערוץ הבקרה.

תחשיב of מה היא חיץ גודל
חישוב גודל המאגר עבור UM RLC נעשה באמצעות אותה גישה של
AM RLC, אנא עיין בסעיף תחשיב of מה היא חיץ גודל עבור המקביל
תאור.

TM RLC
בסעיף זה אנו מתארים את היישום של ישות RLC של מצב שקוף (TM).

לשדר פעולות in downlink
בסימולטור, ה-TM RLC עדיין מספק לשכבות העליונות את אותו ממשק שירות
מסופק על ידי הישויות AM ו-UM RLC לשכבת PDCP; בפועל, ממשק זה הוא
בשימוש על ידי ישות RRC (לא ישות PDCP) לשידור של RLC SDUs. הבחירה הזו היא
מונע על ידי העובדה שהשירותים שמספקים TM RLC לשכבות העליונות,
לפי [TS36322], היא תת-קבוצה של אלה שסופקו על ידי ישויות UM ו-AM RLC ל-
שכבת PDCP; לפיכך, השתמשנו מחדש באותו ממשק למען הפשטות.

פעולות השידור ב-downlink מבוצעות באופן הבא. כאשר
שידור_PDCP_PDU שרות פרימיטיבי נקרא על ידי השכבות העליונות, ה-TM RLC עושה את
הבא:

· הכנס את ה-SDU למאגר השידור

· לחשב את גודל מאגר ההילוכים

· תתקשר ל Report_Buffer_Status פרימיטיבי שירות של ישות eNB MAC

לאחר מכן, כאשר מתזמן ה-MAC מחליט שניתן לשלוח נתונים מסוימים על ידי הלוגי
ערוץ שאליו שייכת ישות TM RLC, ישות MAC מודיעה על כך ל-TM RLC
ישות על ידי קריאה ל- הודע_Tx_Opportunity שירות פרימיטיבי. עם קבלת זה
פרימיטיבי, הישות TM RLC עושה את הפעולות הבאות:

· אם להזדמנות ה-TX יש גודל גדול או שווה לגודל של
SDU ראשי קו במאגר השידור

· תור את ה-SDU ראש קו ממאגר השידור

· ליצור RLC PDU אחד שמכיל כולו את ה-SDU הזה, ללא שום כותרת RLC

· תתקשר ל שידור_PDU פרימיטיבי על מנת לשלוח את ה-RLC PDU לישות MAC.

לשדר פעולות in uplink
פעולות השידור ב-uplink דומות לאלו של ה-downlink, עם הראשי
הבדל שהזדמנות שידור יכולה לנבוע גם מהקצאת ה-UL
GRANT כחלק מהליך הגישה האקראית, ללא דוח מצב מאגר מפורש
שהונפקו על ידי ישות TM RLC.

תחשיב of מה היא חיץ גודל
לפי המפרט [TS36322], ה-TM RLC אינו מוסיף שום כותרת RLC ל-PDUs
מועבר. בגלל זה, גודל המאגר המדווח לשכבת MAC הוא
מחושב פשוט על ידי סיכום הגודל של כל החבילות במאגר השידור, לפיכך
הודעה ל-MAC על גודל המאגר המדויק.

SM RLC
בנוסף למימושים של AM, UM ו-TM שעוצבו במודל של 3GPP
מפרטים, מסופק דגם RLC מפושט, הנקרא מצב רוויה (SM)
RLC. מודל RLC זה אינו מקבל PDUs מכל שכבה מעל (כגון PDCP); במקום זאת, ה
SM RLC דואג לייצור של RLC PDUs בתגובה להודעה של
הזדמנויות שידור על ידי ה-MAC. במילים אחרות, ה-SM RLC מדמה
תנאי רוויה, כלומר, הוא מניח שמאגר RLC תמיד מלא ויכול
ליצור PDU חדש בכל פעם שהמתזמן מקבל הודעה.

ה-SM RLC משמש לתרחישי סימולציה מפושטים שבהם רק דגם הרדיו LTE
נמצא בשימוש, ללא ה-EPC ומכאן ללא כל תמיכה ברשת IP. נציין כי,
למרות שה-SM RLC הוא מודל תעבורה לא מציאותי, הוא עדיין מאפשר את הנכון
סימולציה של תרחישים עם זרימות מרובות השייכות ל-QoS שונה (לא בזמן אמת).
מחלקות, על מנת לבדוק את ביצועי ה-QoS שהושגו על ידי מתזמנים שונים. זה יכול
להיעשות מכיוון שזו משימתו של המתזמן להקצות משאבי שידור על סמך
המאפיינים (למשל, קצב סיביות מובטח) של כל נושא רדיו, המפורטים
על ההגדרה של כל נושא בתוכנית הסימולציה.

באשר למתזמנים שנועדו לעבוד עם תעבורת QoS בזמן אמת שיש לה אילוצי עיכוב,
ה-SM RLC הוא כנראה לא בחירה מתאימה. הסיבה לכך היא היעדר בפועל
RLC SDUs (מוחלפים על ידי הדור המלאכותי של דוחות מצב מאגר) גורם לכך שלא
ניתן לספק למתזמן מידע משמעותי על עיכוב ראשי קו, כלומר
לעתים קרובות מדד הבחירה ליישום מדיניות תזמון בזמן אמת
זרימות תנועה. לסימולציה ובדיקה של מתזמנים כאלה, רצוי להשתמש
במקום זאת דגמי UM או AM RLC.

PDCP
PDCP מספר סימוכין סקירה כללית
מסמך ההתייחסות למפרט של ישות PDCP הוא [TS36323]. בכבוד
לפי מפרט זה, מודל PDCP המיושם בסימולטור תומך רק ב
התכונות הבאות:

· העברת נתונים (מישור משתמש או מישור בקרה);

· תחזוקה של PDCP SNs;

· העברת סטטוס SN (לשימוש בעת מסירה);

התכונות הבאות אינן נתמכות כרגע:

· דחיסת כותרת ופירוק זרימות נתוני IP באמצעות פרוטוקול ROHC;

· אספקה ​​ברצף של PDUs בשכבה העליונה בעת הקמה מחדש של שכבות תחתונות;

· חיסול כפול של SDUs בשכבה התחתונה בהקמת מחדש של שכבות נמוכות עבור
נושאי רדיו ממופים על RLC AM;

· הצפנה ופענוח של נתוני מטוס משתמש ונתוני מטוס בקרה;

· הגנת תקינות ואימות תקינות של נתוני מטוס הבקרה;

· השלכה מבוססת טיימר;

· השלכה כפולה.

PDCP שֵׁרוּת מִמְשָׁק
ממשק שירות PDCP מחולק לשני חלקים:

· ה PdcpSapProvider חלק מסופק על ידי שכבת PDCP ומשמש את השכבה העליונה
ו

· ה PdcpSapUser חלק מסופק על ידי השכבה העליונה ומשמש את שכבת PDCP.

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) +
הגדרה מחדש של מדידות UE + הגדרת נושא רדיו נתונים + מסירה

· הקמת חיבור RRC מחדש, התומך במקרי השימוש הבאים: + מסירה

אדריכלות
מודל RRC מחולק למרכיבים הבאים:

· ישויות RRC LteUeRrc ו LteEnbRrc, אשר מיישמים את מכונות המדינה של ה
ישויות RRC בהתאמה ב-UE וב-eNB;

· ה-RRC SAPs LteUeRrcSapProvider, LteUeRrcSapUser, LteEnbRrcSapProvider,
LteEnbRrcSapUser, המאפשרים לישויות RRC לשלוח ולקבל הודעות RRC ו
רכיבי מידע;

· מחלקות פרוטוקול RRC LteUeRrcProtocolIdeal, LteEnbrRrcProtocolIdeal,
LteUeRrcProtocolReal, LteEnbRrcProtocolReal, אשר מיישמים שני מודלים שונים עבור
העברת הודעות RRC.

בנוסף, רכיבי RRC משתמשים ב-SAPs שונים אחרים כדי ליצור אינטראקציה עם השאר
של ערימת הפרוטוקולים. ייצוג של כל ה-SAPs שבהם נעשה שימוש מסופק ב-
דמויות LTE רָדִיוֹ פרוטוקול לערום ארכיטקטורה ל מה היא UE on מה היא נתונים מטוס, LTE רָדִיוֹ
פרוטוקול לערום ארכיטקטורה ל מה היא UE on מה היא לִשְׁלוֹט מטוס, LTE רָדִיוֹ פרוטוקול לערום
ארכיטקטורה ל מה היא eNB on מה היא נתונים מטוס ו LTE רָדִיוֹ פרוטוקול לערום ארכיטקטורה ל
מה היא eNB on מה היא לִשְׁלוֹט מטוס.

UE RRC מדינה מכונה
באיור UE RRC מדינה מכונה אנו מייצגים את מכונת המדינה כפי שהוטמעה ב- RRC UE
ישויות.
[תמונה] UE RRC State Machine.UNINDENT

יש לציין שרוב המצבים הם חולפים, כלומר ברגע שה-UE נכנס למצב אחד
ממצבי CONNECTED הוא לעולם לא יחזור לאף אחד ממצבי ה-IDLE. הבחירה הזו
נעשה מהסיבות הבאות:

· כפי שנדון בסעיף עיצוב קריטריונים, המוקד של סימולציית LTE-EPC
הדגם נמצא במצב CONNECTED

· כשל בקישור הרדיו אינו מעוצב כעת, כפי שנדון בסעיף רדיו קישור
כשלון, כך ש-UE לא יכול לעבור ל-IDLE בגלל כשל בקישור הרדיו

· שחרור חיבור RRC אינו מופעל כרגע לא על ידי ה-EPC ולא על ידי ה-NAS

ובכל זאת, בחרנו לדגמן במפורש את מצבי ה-IDLE, כי:

· דרושה תצורת UE RRC מציאותית עבור מסירה, שהיא תכונה נדרשת,
וכדי לקבל יישום נקי יותר הגיוני להשתמש באותו UE RRC
תצורה גם עבור יצירת החיבור הראשונית

· זה מקל על יישום בחירת תאים במצב סרק בעתיד, שהוא א
תכונה רצויה ביותר

ENB RRC מדינה מכונה
ה-eNB RRC שומר על המצב עבור כל UE שמחובר לתא. מאת
נקודת מבט של יישום, המצב של כל UE כלול במופע של
שיעור UeManager. מכונת המצב מיוצגת באיור ENB RRC מדינה מכונה ל כל אחד
UE.
[תמונה] ENB RRC State Machine עבור כל UE.UNINDENT

התחיל תא בחירה
בחירת תאים ראשונית היא הליך במצב IDLE, המבוצע על ידי UE כאשר טרם בוצע
מחנה או מחובר ל-eNodeB. מטרת ההליך היא למצוא תא מתאים
ולצרף אליו כדי לקבל גישה לרשת הסלולרית.

זה נעשה בדרך כלל בתחילת הסימולציה, כפי שמתואר באיור מדגם פועל of
בתחילה תא מבחר in UE ו תזמון of קָשׁוּר אירועים לְהַלָן. דיאגרמת הזמן על
הצד השמאלי ממחיש את המקרה שבו בחירת תאים ראשונית מצליחה בניסיון הראשון,
בעוד שהתרשים בצד ימין מיועד למקרה שבו הוא נכשל בניסיון הראשון ו
להצליח בניסיון השני. התזמון מניח את השימוש במודל פרוטוקול RRC אמיתי (ראה RRC
פרוטוקול מודלים) וללא שגיאת שידור.
[תמונה] ריצות לדוגמה של בחירת תאים ראשונית ב-UE ותזמון של קשורים
אירועים.UNINDENT

הפונקציונליות מבוססת על מפרטי מצב 3GPP IDLE, כגון ב-[TS36300],
[TS36304], ו-[TS36331]. עם זאת, יישום נכון של מצב IDLE עדיין חסר
בסימולטור, לכן אנו שומרים לעצמנו מספר הנחות מפשטות:

· תדר רשת מרובים אינו נתמך;

· מספר זהויות של רשתות סלולריות ציבוריות (PLMN) (כלומר מספר רשתות
מפעילים) אינו נתמך;

· מדידות RSRQ אינן מנוצלות;

· בחירת תא מידע מאוחסן אינה נתמכת;

· מצב "כל בחירת תאים" וקמפינג לתא מקובל אינם נתמכים;

· סימון תא כסגור או שמור אינו נתמך;

· בחירה מחדש של תאים אינה נתמכת, ומכאן שלא ניתן ל-UE להחנות ל-a
תא שונה לאחר הצבת המחנה הראשוני; ו

· הרשימה הלבנה של קבוצת מנויים סגורה (CSG) של UE מכילה רק זהות CSG אחת.

כמו כן, שים לב שבחירת תאים ראשונית זמינה רק עבור סימולציות התומכות ב-EPC.
סימולציות LTE בלבד חייבות להשתמש בשיטת החיבור הידנית. ראה סעיף
sec-network-attachment של תיעוד המשתמש למידע נוסף על ההבדלים ביניהם
בשימוש.

תת הסעיפים הבאים מכסים חלקים שונים של בחירת תאים ראשונית, כלומר תא search,
מִשׁדָר of מערכת מידע, ו תא מבחר הערכה.

תא חיפוש
חיפוש תאים נועד לזהות תאים מסביב ולמדוד את עוצמת האות המתקבל
מכל אחד מהתאים הללו. אחד מהתאים הללו יהפוך לנקודת הכניסה של ה-UE להצטרף ל
רשת סלולרית.

המדידות מבוססות על ה-RSRP של ה-PSS שהתקבל, בממוצע על ידי סינון שכבה 1,
ומבוצע על ידי שכבת PHY, כפי שתואר בעבר ביתר פירוט בסעיף UE PHY
מדידות מספר סימוכין. PSS מועבר על ידי eNodeB על פני 72 ספקי המשנה המרכזיים של ה-
ערוץ DL (סעיף 5.1.7.3 [TS36300]), לפיכך אנו מדגמים את חיפוש התא לפעול באמצעות DL
רוחב פס של 6 RBs. שימו לב כי מדידות של RSRQ אינן זמינות בנקודת זמן זו
בסימולציה. כתוצאה מכך, ה LteUePhy::RsrqUeMeasThreshold התכונה לא
החל במהלך חיפוש סלולרי.

על ידי שימוש ב-RSRP הנמדד, ישות PHY מסוגלת ליצור רשימה של תאים שזוהו,
כל אחד עם מזהה התא המתאים לו ו-RSRP ממוצע. רשימה זו נדחפת מעת לעת
באמצעות CPHY SAP לישות RRC כדוח מדידה.

ישות RRC בודקת את הדוח ופשוט בוחרת את התא עם ה-RSRP החזק ביותר, כמו
מצוין גם בסעיף 5.2.3.1 של [TS36304]. ואז הוא מורה בחזרה לישות PHY
לסנכרן לתא הספציפי הזה. רוחב הפס ההפעלה בפועל של התא עדיין עדיין
לא ידוע בשלב זה, כך שהישות PHY מאזינה רק לרוחב הפס המינימלי של 6 RBs.
עם זאת, ישות PHY תוכל לקבל הודעת שידור מערכת מכאן
eNodeB מסוים, שהוא הנושא של תת-הסעיף הבא.

משדר of מערכת מֵידָע
בלוקים של מידע מערכת משודרים על ידי eNodeB ל-UEs במרווחי זמן מוגדרים מראש,
מותאם מסעיף 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
מותר לעבור למצב CONNECTED.

תא בחירה הערכה
UE RRC סוקר את דוח המדידה שהופק ב תא חיפוש והגישה לתא
מידע שסופק על ידי SIB1. ברגע ששני המידע זמין עבור תא ספציפי, ה
UE מפעיל את תהליך ההערכה. מטרת תהליך זה היא לקבוע האם
התא הוא תא מתאים למחנה אליו.

תהליך ההערכה הוא גרסה פשוטה מעט של סעיף 5.2.3.2 של [TS36304].
הוא מורכב מהקריטריונים הבאים:

· קריטריון רמת Rx; ו

· קריטריון של קבוצת מנויים סגורה (CSG).

הקריטריון הראשון, רמת Rx, מבוסס על RSRP שנמדד של התא Q_{rxlevmeas}, אשר
חייב להיות גבוה מהמינימום הנדרש Q_{rxlevmin} כדי לעבור את הקריטריון:

כאשר Q_{rxlevmin} נקבע על ידי כל eNodeB וניתן להשיגו על ידי UE מ-SIB1.

הקריטריון האחרון, CSG, הוא שילוב של פרמטר נכון או לא נכון שנקרא CSG
סִימָן ומספר פשוט CSG זהות. הכלל הבסיסי הוא ש-UE לא תחנה
eNodeB עם זהות CSG שונה. אבל כלל זה נאכף רק כאשר ציון CSG
מוערך כאמת. פרטים נוספים מסופקים ב-Section sec-network-attachment של המשתמש
תיעוד.

כאשר התא עובר את כל הקריטריונים לעיל, התא נחשב כ מַתְאִים. ואז UE
מחנות אליו (IDLE_CAMPED_NORMALLY מדינה).

לאחר מכן, השכבה העליונה עשויה לבקש מ-UE להיכנס למצב CONNECTED. אנא עיין בסעיף
RRC הקשר הקמה לפרטים על כך.

מצד שני, כשהתא לא עובר את קריטריון ה-CSG, אז התא מסומן
as קביל (סעיף 10.1.1.1 [TS36300]). במקרה זה, ישות ה-RRC תספר ל-PHY
ישות לסנכרן לתא השני החזק ולחזור על בחירת התא הראשונית
הליך באמצעות התא הזה. כל עוד לא נמצא תא מתאים, ה-UE יחזור על אלה
צעדים תוך הימנעות מתאים שזוהו כמקובלים.

רדיו הודאה שליטה
בקרת כניסה לרדיו נתמכת בכך שה-eNB RRC עונה ל-RRC CONNECTION
הודעת REQUEST שנשלחה על ידי ה-UE עם הודעת RRC CONNECTION SETUP או RRC
הודעת CONNECTION REJECT, תלוי אם ה-UE החדש יתקבל או לא. ב
ביישום הנוכחי, ההתנהגות נקבעת על ידי התכונה הבוליאנית
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 מספקת תמיכה למדידות UE; בפרט, הוא מיישם את
נהלים המתוארים בסעיף 5.5 של [TS36331], עם הפישוט הבא
הנחות:

· רק מדידות תוך-תדרים E-UTRA נתמכות, מה שמרמז:

· רק אובייקט מדידה אחד משמש במהלך הסימולציה;

· אין צורך בפערי מדידה לביצוע המדידות;

· אירוע B1 ו-B2 אינם מיושמים;

· רק דווח על תאים חזקים המטרה נתמכת, בעוד דווחCGI ו
דווח StrongestCellsForSON מטרות אינן נתמכות;

· s-מדידה לא נתמך;

· מאחר שצבירת הספקים אינה נתמכת על ידי מודול LTE, הבא
ההנחות במדידות UE מתקיימות:

· אין מושג של תא משני (SCell);

· תא ראשי (PCell) פירושו פשוט משרת תא;

· אירוע A6 אינו מיושם;

· קנה מידה תלוי מהירות של זמן עד להדק (סעיף 5.5.6.2 של [TS36331]) אינו
נתמך.

באופן כללי עיצוב
המודל מבוסס על הרעיון של UE מידות צרכן, שהיא ישות שיכולה
לבקש מישות eNodeB RRC לספק דוחות מדידה של UE. הצרכנים הם, עבור
דוגמא, מסירת אַלגוֹרִיתְם, אשר מחשבים החלטת מסירה על סמך מדידת UE
דיווחים. מקרי בדיקה ותוכניות של משתמשים עשויים גם הם להפוך לצרכנים. דמות קשר
בֵּין UE מידות ו שלה צרכנים מתאר את היחסים בין הישויות הללו.
[תמונה] הקשר בין מדידות UE לצרכנים שלה.UNINDENT

כל פונקציית מדידות ה-UE ברמת RRC מחולקת ל-4 חלקים עיקריים:

1. תצורת מדידה (מטופל על ידי LteUeRrc::ApplyMeasConfig)

2. ביצוע מדידות (טופל על ידי LteUeRrc::DoReportUeMeasurements)

3. הפעלת דוחות מדידה (מטופל על ידי LteUeRrc::MeasurementReportTriggering)

4. דיווח מדידה (מטופל על ידי LteUeRrc::SendMeasurementReport)

הסעיפים הבאים יתארו כל אחד מהחלקים לעיל.

מדידה תצורה
ישות eNodeB RRC מגדירה מדידות UE על ידי שליחת פרמטרי התצורה אל
ישות UE RRC. קבוצה זו של פרמטרים מוגדרת בתוך MeasConfig מֵידָע
רכיב (IE) של הודעת תצורה מחדש של חיבור RRC (RRC הקשר
הגדרה מחדש).

הישות eNodeB RRC מיישמת את פרמטרי התצורה והנהלים המתוארים ב
סעיף 5.5.2 של [TS36331], עם ההנחה המפשטת הבאה:

· תצורה (כלומר הוספה, שינוי והסרה) יכולה להיעשות רק לפני
סימולציה מתחילה;

· כל UEs המחוברים ל-eNodeB יוגדרו באותו אופן, כלומר אין
תמיכה בהגדרת מדידה ספציפית עבור UE ספציפי; ו

· ההנחה היא שקיים מיפוי אחד לאחד בין ה-PCI ל-E-UTRAN
מזהה תא גלובלי (EGCI). זה תואם את הנחות המודל של PCI
מתואר ב UE PHY מדידות מספר סימוכין.

מופע eNodeB RRC כאן פועל כמתווך בין הצרכנים לבין
UEs מצורפים. בתחילת הסימולציה, כל צרכן מספק את eNodeB RRC
מופע עם תצורת מדידות UE שהיא דורשת. לאחר מכן, ה-eNodeB
RRC מפיץ את התצורה ל-UEs מחוברים.

משתמשים יכולים להתאים אישית את תצורת המדידה באמצעות מספר שיטות. בבקשה התייחס ל
סעיף sec-configure-ue-measures של תיעוד המשתמש לתיאור של
שיטות אלו.

מבצע מידות
UE RRC מקבל מדידות RSRP ו-RSRQ על בסיס תקופתי מ-UE PHY, כמו
מתואר ב UE PHY מדידות מספר סימוכין. שִׁכבָה 3 סינון יחולו על אלה
קיבלו מידות. יישום הסינון בהתאם לסעיף 5.5.3.2 של
[TS36331]:

שם:

· M_n היא תוצאת המדידה האחרונה שהתקבלה מהשכבה הפיזית;

· F_n היא תוצאת המדידה המסוננת המעודכנת;

· F_{n-1} היא תוצאת המדידה המסוננת הישנה, ​​כאשר F_0 = M_1 (כלומר הראשון
המדידה אינה מסוננת); ו

· a = (ac{1}{2})^{ac{k}{4}}, כאשר k הוא הניתן להגדרה filterCoeficent המסופקים על ידי
מה היא QuantityConfig;

k = 4 הוא ערך ברירת המחדל, אך ניתן להגדיר אותו על ידי הגדרת ה- RsrpFilterCoefficient ו
RsrqFilterCoefficient תכונות ב LteEnbRrc.

לכן k = 0 ישבית את סינון שכבה 3. מצד שני, מדידות עבר יכולות
להעניק השפעה רבה יותר על תוצאות הסינון על ידי שימוש בערך גדול יותר של k.

מדידה דיווח מפעילה
בחלק זה, UE RRC יעבור על רשימת תצורת המדידה הפעילה ו
לבדוק אם תנאי ההפעלה מתקיים בהתאם לסעיף 5.5.4 של
[TS36331]. כאשר לפחות מצב הפעלה אחד מכל המדידה הפעילה
התצורה מתקיימת, הליך דיווח המדידה (מתואר בהמשך
סעיף קטן) יופעל.

3GPP מגדיר שני סוגים של triggerType: תקופתי ו מבוסס אירועים. כרגע, רק
קריטריון מבוסס אירועים נתמך. ישנם אירועים שונים שניתן לבחור, אשר
מתוארים בקצרה בטבלה שלהלן:

רשימה of נתמך מבוסס אירועים מפעילה הקריטריונים
──────────┬─────────────────────────
│שם │ תיאור │
├─────────┼─────────────────────────────────
│אירוע A1 │ תא הגשה הופך טוב יותר מ│
│ │ סף │
├─────────┼─────────────────────────────────
│אירוע A2 │ תא הגשה הופך גרוע יותר מ│
│ │ סף │
├─────────┼─────────────────────────────────
│אירוע A3 │ שכן הופך לקזז dB │
│ │ טוב יותר מתא הגשה │
├─────────┼─────────────────────────────────
│אירוע A4 │ שכן הופך לטוב יותר מ│
│ │ סף │
└─────────┴─────────────────────────────

│אירוע A5 │ ההגשה הופכת גרועה מ│
│ │ סף 1 ו השכן הופך ל│
│ │ יותר טוב מ סף 2 │
└─────────┴─────────────────────────────

שני תנאים עיקריים שיש לבדוק בטריגר מבוסס-אירוע הם הזנת מצב ו
מה היא עזיבה מצב. פרטים נוספים על שני אלה ניתן למצוא בסעיף 5.5.4 של
[TS36331].

ניתן להגדיר טריגר מבוסס אירועים נוסף על ידי הכנסת היסטרזיס ו
זמן להפעלה. היסטרזי (Hys) מגדיר את המרחק בין הכניסה ליציאה
תנאים ב-dB. באופן דומה, זמן להפעלה מציג עיכוב הן בכניסה והן ביציאה
תנאים, אלא כיחידת זמן.

השמיים תקופתי סוג הטריגר לדיווח אינו נתמך, אך ההתנהגות שלו יכולה להיות בקלות
מתקבל על ידי שימוש בטריגר מבוסס אירועים. ניתן לעשות זאת על ידי הגדרת המדידה
באופן שתנאי הכניסה מתקיים תמיד, למשל, על ידי הגדרת ה-
הסף של אירוע A1 לאפס (הרמה המינימלית). כתוצאה מכך, המדידה מדווחת
תמיד יופעל בכל מרווח מסוים, כפי שנקבע על ידי reportInterval
שדה בפנים LteRrcSap::ReportConfigEutra, ולכן מייצר את אותה התנהגות כמו
דיווח תקופתי.

כמגבלה ביחס למפרטי 3GPP, הדגם הנוכחי אינו תומך
כל תצורה ספציפית לתא. פרמטרי תצורה אלו מוגדרים במדידה
לְהִתְנַגֵד. כתוצאה מכך, שילוב רשימה של תאים שחורים בתהליך ההפעלה
לא נתמך. יתר על כן, היסט ספציפי לתא (כלומר, O_{cn} ו-O_{cp} באירוע A3, A4,
ו-A5) אינם נתמכים גם כן. הערך השווה לאפס תמיד מניחים במקום
אותם.

מדידה דיווח
חלק זה מטפל בהגשת דו"ח מדידה מהישות של UE RRC ל-
משרת ישות eNodeB באמצעות פרוטוקול RRC. אומצו מספר הנחות מפשטות:

· reportAmount is לֹא ישים (כלומר תמיד מניחים שהוא אינסופי);

· בדוחות מדידה, ה דוח כמות תמיד מניחים שכן שניהם, כלומר, שניהם
RSRP ו-RSRQ מדווחים תמיד, ללא קשר ל- triggerQuantity.

מסירת
דגם RRC תומך בניידות UE במצב CONNECTED על ידי הפעלת מסירה מבוססת X2
תהליך. המודל הוא תוך-EUTRAN ובתדר-תדר, כפי שמבוסס על סעיף 10.1.2.1 של
[TS36300].

חלק זה מתמקד בתהליך של הפעלת מסירה. ביצוע המסירה
ההליך עצמו מכוסה בסעיף X2.

ישנן שתי דרכים להפעיל את הליך המסירה:

· בִּמְפוּרָשׁ (או באופן ידני) מופעל על ידי תוכנית הסימולציה על ידי תזמון an
ביצוע השיטה LteEnbRrc::SendHandoverRequest, או

· באופן אוטומטי מופעל על ידי ישות eNodeB RRC בהתבסס על מדידות UE ו
לפי אלגוריתם המסירה שנבחר.

סעיף sec-x2-based-handover של תיעוד המשתמש מספק כמה דוגמאות לשימוש
מפעילי מסירה מפורשים וגם אוטומטיים בסימולציה. תת הסעיף הבא יהיה
תסתכל מקרוב על השיטה האוטומטית, על ידי תיאור היבטי העיצוב של
ממשק אלגוריתמי מסירה ואלגוריתמי מסירה זמינים.

מסירת אַלגוֹרִיתְם
למסירה ב-3GPP LTE יש את המאפיינים הבאים:

·

בסיוע UE
ה-UE מספק קלט לרשת בצורה של דוחות מדידה. זֶה
מטופל על ידי UE RRC מדידות מספר סימוכין.

·

נשלטת ברשת
הרשת (כלומר המקור eNodeB והיעד eNodeB) מחליטה מתי לעשות זאת
להפעיל את המסירה ולפקח על ביצועה.

השמיים מסירה אַלגוֹרִיתְם פועל במקור eNodeB ואחראי בביצוע מסירה
החלטות בצורה "אוטומטית". הוא מקיים אינטראקציה עם מופע eNodeB RRC דרך ה
מסירת ניהול שוטף SAP מִמְשָׁק. קשרים אלה מומחשים באיור
קשר בֵּין UE מידות ו שלה צרכנים מהסעיף הקודם.

ממשק אלגוריתם המסירה מורכב מהשיטות הבאות:

·

AddUeMeasReportConfigForHandover
(אלגוריתם מסירה -> eNodeB RRC) משמש את אלגוריתם המסירה לבקש
דוחות מדידה מהישות eNodeB RRC, על ידי העברת הרצוי
תצורת דיווח. התצורה תיושם בכל עתיד
UEs מצורפים.

·

ReportUeMeas
(eNodeB RRC -> אלגוריתם מסירה) מבוסס על מדידות ה-UE שהוגדרו
קודם לכן AddUeMeasReportConfigForHandover, UE רשאית להגיש דוחות מדידה
ל-eNodeB. ישות eNodeB RRC משתמשת ב- ReportUeMeas ממשק ל
להעביר את דוחות המדידה הללו לאלגוריתם המסירה.

·

TriggerHandover
(אלגוריתם מסירה -> eNodeB RRC) לאחר בחינת דוחות המדידה
(אך לא בהכרח), אלגוריתם המסירה עשוי להכריז על מסירה. זֶה
השיטה משמשת כדי להודיע ​​לישות eNodeB RRC על החלטה זו, אשר תעשה זאת
לאחר מכן המשך להתחיל בהליך המסירה.

הערה אחת עבור AddUeMeasReportConfigForHandover. השיטה תחזיר את measId
(זהות מדידה) של תצורת המדידה החדשה שנוצרה. בדרך כלל א
אלגוריתם מסירה יאחסן את המספר הייחודי הזה. זה עשוי להיות שימושי ב ReportUeMeas
שיטה, למשל כאשר התבקשה יותר מתצורה אחת והמסירה
האלגוריתם צריך להבדיל דוחות נכנסים על סמך התצורה ש
עורר אותם.

אלגוריתם מסירה מיושם על ידי כתיבת תת מחלקה של אלגוריתם LteHandover
מחלקה מופשטת ויישום כל אחת משיטות ממשק SAP שהוזכרו לעיל.
משתמשים יכולים לפתח אלגוריתם מסירה משלהם בדרך זו, ולאחר מכן להשתמש בו בכל סימולציה
על ידי ביצוע השלבים המתוארים בסעיף סעיף-x2 מבוסס-מסירה של המשתמש
תיעוד.

לחלופין, משתמשים יכולים לבחור להשתמש באחד משלושת אלגוריתמי המסירה המובנים שסופקו
על ידי מודול LTE: no-op, A2-A4-RSRQ ואלגוריתם מסירת תאים החזק ביותר. הם
מוכן לשימוש בסימולציות או שניתן לקחת אותו כדוגמה ליישום מסירה
אַלגוֹרִיתְם. כל אחד מהאלגוריתמים המובנים הללו מכוסה בכל אחד מהדברים הבאים
תת סעיפים.

ללא הפעלה מסירה אַלגוֹרִיתְם
השמיים ללא הפעלה מסירה אַלגוֹרִיתְם (אלגוריתם NoOpHandover class) היא הפשוטה ביותר האפשרית
יישום אלגוריתם מסירה. זה בעצם לא עושה כלום, כלומר, לא קורא לאף אחד
של שיטות ממשק SAP לניהול מסירה. משתמשים יכולים לבחור באלגוריתם מסירה זה
אם הם מעוניינים להשבית את טריגר המסירה האוטומטית בסימולציה שלהם.

A2-A4-RSRQ מסירה אַלגוֹרִיתְם
השמיים A2-A4-RSRQ מסירה אַלגוֹרִיתְם מספק את הפונקציונליות של מסירת ברירת המחדל
אלגוריתם שנכלל במקור ב-LENA M6 (ns-3.18), מועבר ל-SAP לניהול מסירה
ממשק כמו ה אלגוריתם A2A4RsrqHandover מעמד.

כפי שהשם מרמז, האלגוריתם משתמש באיכות מתקבלת אות התייחסות (RSRQ)
מדידות שנרכשו מאירוע A2 ואירוע A4. לפיכך, האלגוריתם יוסיף 2
תצורת מדידה למופע eNodeB RRC המתאים. השימוש המיועד שלהם הם
מתואר כדלקמן:

· אירוע A2 (המשרת RSRQ של התא הופך גרוע יותר מ סף) ממונפת להצביע
שה-UE חווה איכות אות ירודה ועשויה להפיק תועלת ממסירה.

· אירוע A4 (ה-RSRQ של התא השכן הופך טוב יותר מ סף) משמש לזיהוי
תאים שכנים ורוכשים את ה-RSRQ המתאים שלהם מכל UE מחובר, אשר
לאחר מכן מאוחסנים באופן פנימי על ידי האלגוריתם. כברירת מחדל, האלגוריתם מוגדר
אירוע A4 עם סף נמוך מאוד, כך שקריטריוני ההדק תמיד נכונים.

תרשים A2-A4-RSRQ מסירה אַלגוֹרִיתְם להלן מסכם הליך זה.
[תמונה] אלגוריתם מסירה A2-A4-RSRQ.UNINDENT

ניתן להגדיר שתי תכונות כדי לכוונן את התנהגות האלגוריתם:

·

ServingCellThreshold
השמיים סף עבור אירוע A2, כלומר ל-UE חייב להיות RSRQ נמוך מזה
סף שיש לשקול למסירה.

·

NeighbourCellOffset
השמיים לקזז שמטרתו להבטיח שה-UE תקבל איכות אות טובה יותר
לאחר המסירה. תא שכן נחשב כתא מטרה עבור
מסירה רק אם ה- RSRQ שלו גבוה מה- RSRQ של התא המשרת בסכום
של זה לקזז.

הערך של שתי התכונות מבוטא כטווח RSRQ (סעיף 9.1.7 של [TS36133]),
שהוא מספר שלם בין 0 ל-34, כאשר 0 הוא RSRQ הנמוך ביותר.

הכי חזק תא מסירה אַלגוֹרִיתְם
השמיים החזק ביותר תא מסירה אַלגוֹרִיתְם, או גם ידוע לפעמים בשם מסורתי כּוֹחַ
תקציב (PBGT) אַלגוֹרִיתְם, פותח באמצעות [Dimou2009] בתור התייחסות. הרעיון הוא
לספק לכל UE את ההספק הטוב ביותר האפשרי של Reference Signal Received (RSRP). זה
נעשה על ידי ביצוע מסירה ברגע שתא טוב יותר (כלומר עם RSRP חזק יותר).
זוהה.

אירוע A3 (ה-RSRP של התא השכן הופך טוב יותר מה-RSRP של התא השכן) נבחר כדי
להבין את הרעיון הזה. ה אלגוריתם A3RsrpHandover הכיתה היא התוצאה של
יישום. מסירה מופעלת עבור ה-UE לתא הטוב ביותר במדידה
לדווח.

סימולציה המשתמשת באלגוריתם זה בדרך כלל פגיעה יותר להעברת פינג-פונג
(מסירה רצופה למקור הקודם eNodeB תוך פרק זמן קצר),
במיוחד כאשר ה דוֹהֶה מספר סימוכין מופעל. בעיה זו מטופלת בדרך כלל על ידי
הכנסת עיכוב מסוים למסירה. האלגוריתם עושה זאת על ידי הכללה
הפרמטרים של היסטרזה ופרמטרי זמן עד להפעיל (סעיף 6.3.5 של [TS36331]) ל-UE
תצורת מדידות.

היסטרזי (המכונה מרווח מסירה) מעכב את המסירה לגבי RSRP. הערך הוא
מבוטא ב-dB, נע בין 0 ל-15 dB, ובעל דיוק של 0.5 dB, למשל, קלט
ערך של 2.7 dB מעוגל ל-2.5 dB.

מצד שני, זמן להפעלה מעכב את המסירה ביחס לזמן. 3GPP מגדיר 16
ערכים תקפים עבור זמן עד להפעלה (הכל באלפיות שניות): 0, 40, 64, 80, 100, 128, 160, 256,
320, 480, 512, 640, 1024, 1280, 2560 ו-5120.

ההבדל בין היסטרזיס לזמן להפעלה מודגם באיור השפעה of
היסטריה ו זמן להפעלה in החזק ביותר תא מסירה אַלגוֹרִיתְם למטה, אשר נלקח
מ לנה-x2-מדדי מסירה דוגמא. הוא מתאר את ה-RSRP הנתפס של תא משרת
ותא שכן על ידי UE שזז עובר את גבול התאים.
[תמונה] השפעת היסטרזיס וזמן ההפעלה בהעברת התא החזקה ביותר
algorithm.UNINDENT

כברירת מחדל, האלגוריתם משתמש בהיסטרזיס של 3.0 dB ובזמן ההפעלה של 256 אלפיות השנייה.
ניתן לכוונן ערכים אלה דרך ה היסטרזי ו TimeToTrigger תכונות של
אלגוריתם A3RsrpHandover מעמד.

שָׁכֵן קשר
מודול LTE תומך בפשטות מכני עם סלילה אוטומטית שָׁכֵן קשר פונקציה (ANR). זה
מטופל על ידי LteAnr מחלקה, המקיימת אינטראקציה עם מופע eNodeB RRC דרך ה-ANR
ממשק SAP.

שָׁכֵן קשר טבלתי
ה-ANR מחזיק א שָׁכֵן קשר טבלתי (NRT), בדומה לתיאור בסעיף
22.3.2א של [TS36300]. כל ערך בטבלה נקרא a שָׁכֵן קשר (NR) ו
מייצג תא שכן שזוהה, המכיל את השדות הבוליאניים הבאים:

·

לא להסיר
מציין כי NR יהיה לֹא יוסר מה-NRT. זה נָכוֹן by
ברירת מחדל עבור NR ו- שקר אחרת.

·

לא X2 מציין כי NR יהיה לֹא השתמש בממשק X2 כדי ליזום
נהלים לקראת eNodeB ההורות לתא היעד. זה שקר by
ברירת מחדל עבור NR שסופק על ידי המשתמש, ו נָכוֹן אחרת.

·

לא HO מציין כי NR יהיה לֹא ישמש את eNodeB מסיבות מסירה.
זהו נָכוֹן ברוב המקרים, למעט כאשר ה-NR מסופק גם על ידי המשתמש וגם
זוהה ברשת.

לכל ערך NR עשוי להיות לפחות אחד מהמאפיינים הבאים:

·

מסופק על ידי המשתמש
סוג זה של NR נוצר לפי הוראות משתמש הסימולציה. לדוגמה,
NR נוצר באופן אוטומטי עם הקמת X2 ביוזמת המשתמש
חיבור בין 2 eNodeBs, למשל. כמתואר בסעיף
מסירה מבוססת sec-x2. דרך נוספת ליצור NR שסופק על ידי המשתמש היא לקרוא ל-
Add NeighbourRelation לתפקד באופן מפורש.

·

זוהה ברשת
סוג זה של NR נוצר אוטומטית במהלך הסימולציה כתוצאה מ
גילוי של תא סמוך.

על מנת ליצור אוטומטית NR מזוהה ברשת, ANR משתמש במדידות UE. ב
במילים אחרות, ANR הוא צרכן של מדידות UE, כפי שמתואר באיור קשר
בֵּין UE מידות ו שלה צרכנים. RSRQ ואירוע A4 (השכן הופך טוב יותר
מֵאֲשֶׁר סף) משמשים לתצורת הדיווח. אירוע ברירת המחדל A4 סף
מוגדר לנמוך ביותר האפשרי, כלומר, יכולת זיהוי מקסימלית, אך ניתן לשינוי על ידי
הגדרת ה- סף תכונה של LteAnr מעמד. שימו לב שהמסירה של A2-A4-RSRQ
האלגוריתם משתמש גם בתצורת דיווח דומה. למרות הדמיון, מתי
גם ANR וגם אלגוריתם מסירה זה פעילים ב-eNodeB, הם משתמשים בדיווח נפרד
תצורה.

שים לב גם שהגדרה אוטומטית של ממשק X2 אינה נתמכת. זו הסיבה לכך
מה היא לא X2 ו לא HO שדות נכונים ב-NR שזוהה ברשת אך לא זוהה על ידי משתמש.

תפקיד of ANR in הדמיה
ממשק ANR SAP מספק את אמצעי התקשורת בין ANR ל-eNodeB RRC. כמה
פונקציות הממשק משמשות את eNodeB RRC לאינטראקציה עם ה-NRT, כפי שמוצג להלן:

·

Add NeighbourRelation
(eNodeB RRC -> ANR) הוסף ערך NR חדש שסופק על ידי המשתמש ל-NRT.

·

GetNoRemove
(eNodeB RRC -> ANR) קבל את הערך של לא להסיר שדה של ערך NR של
נתון מזהה תא.

·

GetNoHo
(eNodeB RRC -> ANR) קבל את הערך של לא HO שדה של ערך NR של הנתון
מזהה תא.

·

GetNoX2
(eNodeB RRC -> ANR) קבל את הערך של לא X2 שדה של ערך NR של הנתון
מזהה תא.

פונקציות ממשק אחרות קיימות כדי לתמוך בתפקיד של ANR כצרכן מדידות UE,
כמפורט להלן:

·

AddUeMeasReportConfigForAnr
(ANR -> eNodeB RRC) משמש את ה-ANR כדי לבקש דוחות מדידה מה-
ישות eNodeB RRC, על ידי העברת תצורת הדיווח הרצויה. ה
התצורה תחול על כל ה-UE המצורפים בעתיד.

·

ReportUeMeas
(eNodeB RRC -> ANR) מבוסס על מדידות UE שהוגדרו קודם לכן
AddUeMeasReportConfigForAnr, UE רשאית להגיש דוחות מדידה ל-eNodeB.
ישות eNodeB RRC משתמשת ב- ReportUeMeas ממשק להעביר את אלה
דוחות מדידה ל-ANR.

אנא עיין בתיעוד ה-API המתאים עבור LteAnrSap כיתה לפרטים נוספים
על השימוש והפרמטרים הנדרשים.

ה-ANR מנוצל על ידי מופע eNodeB RRC כמבנה נתונים כדי לעקוב אחר
מצבם של תאים סמוכים. ה-ANR גם עוזר למופע eNodeB RRC לעשות זאת
לקבוע האם ניתן לבצע הליך מסירה לתא שכן.
זה מובן על ידי העובדה כי eNodeB RRC יאפשר רק הליך מסירה
קורה אם כניסת ה-NR של תא היעד מכילה את שניהם לא HO ו לא X2 שדות מוגדרים ל שקר.

ANR מופעל כברירת מחדל בכל מופע eNodeB בסימולציה. זה יכול להיות מושבת
על ידי הגדרת ה- AnrEnabled תכונה ב LteHelper כיתה ל שקר.

RRC רצף דיאגרמות
בסעיף זה אנו מספקים כמה דיאגרמות רצף המסבירות את ה-RRC החשוב ביותר
נהלים במודל.

RRC הקשר הקמה
תרשים רצף תרשים of מה היא RRC הקשר הקמת הליך מראה כיצד RRC
הליך הקמת חיבור הוא מודל, המדגיש את תפקידה של שכבת RRC ב
גם ה-UE וגם ה-eNB, כמו גם האינטראקציה עם השכבות האחרות.
[תמונה] דיאגרמת רצף של הליך הקמת החיבור RRC.UNINDENT

ישנם מספר פסקי זמן הקשורים להליך זה, המפורטים להלן
טבלתי שעוני in RRC הקשר הקמה הליך. אם פג תוקף אחד מהטיימרים האלה,
הליך יצירת חיבור RRC הסתיים בכשל. במקרה זה, ה
השכבה העליונה (UE NAS) תנסה מיד לנסות שוב את ההליך עד להשלמתו
בְּהַצלָחָה.

שעוני in RRC הקשר הקמה הליך
┌───────────────┬──────────────────── ─────┬─── ─────────────┬──────────┬──────────── ┐
│ שם │ מיקום │ טיימר מופעל │ טיימר עוצר │ ברירת מחדל │ כאשר טיימר │
│ │ │ │ │ משך │ פג │
├───────────────┼─────────────────────── ─────┼─── ─────────────┼──────────┼───────────── ┤
│ חיבור │ eNodeB RRC │ הקשר UE חדש │ קבלת RRC │ 15 ms │ הסר UE │
│בקשה │ │ נוספה │ חיבור │ │ הקשר │
│פסק זמן │ │ │ בקשה │ │ │
├───────────────┼─────────────────────── ─────┼─── ─────────────┼──────────┼───────────── ┤
│ חיבור │ UE RRC │ שלח RRC │ קבל RRC │ 100 ms │ אפס UE MAC │
│פסק זמן (T300 │ │ חיבור │ חיבור │ │ │
│טיימר) │ │ REQUEST │ SETUP או │ │ │
│ │ │ │ דחייה │ │ │
├───────────────┼─────────────────────── ─────┼─── ─────────────┼──────────┼───────────── ┤
│ חיבור │ eNodeB RRC │ שלח RRC │ קבל RRC │ 100 ms │ הסר UE │
│ זמן קצוב להגדרה │ │ חיבור │ חיבור │ │ הקשר │
│ │ │ הגדרה │ ההגדרה הושלמה │ │ │
├───────────────┼─────────────────────── ─────┼─── ─────────────┼──────────┼───────────── ┤
│חיבור │ eNodeB RRC │ שלח RRC │ לעולם │ 30 אלפיות השנייה │ הסר UE │
│נדחה │ │ חיבור │ │ │ הקשר │
│פסק זמן │ │ דחייה │ │ │ │
└───────────────┴────────────────────── ─────┴─── ─────────────┴──────────┴─────────────── ┘

RRC הקשר הגדרה מחדש
תרשים רצף תרשים of מה היא RRC הקשר הגדרה מחדש הליך מראה כיצד RRC
הליך הגדרת התצורה מחדש של החיבור מיועד למקרה שבו נמצא MobilityControlInfo
לא מסופק, כלומר, מסירה לא מבוצעת.
[תמונה] דיאגרמת רצף של הליך קביעת התצורה מחדש של חיבור RRC.UNINDENT

תרשים רצף תרשים of מה היא RRC הקשר הגדרה מחדש הליך ל מה היא מסירה
מקרה מראה כיצד הליך קביעת התצורה מחדש של חיבור RRC מעוצב עבור המקרה
היכן מסופק MobilityControlInfo, כלומר, יש לבצע מסירה. כמפורט
ב-[TS36331], לאחר קבלה מה היא מסירה הוֹדָעָה, מה היא UE ניסיונות ל גישה מה היא יעד
תא at מה היא ראשון זמין RACH הזדמנות פי ל אַקרַאִי גִישָׁה משאב מבחר
מוגדר in [TS36321]_, כלומר מה היא מסירה is אסינכרוני. כתוצאה מכך, מתי הקצאה
a מוקדש הַקדָמָה ל מה היא אקראי גישה in מה היא יעד תָא, E-UTRA יהיה לְהַבטִיחַ it is
זמין החל מ- מה היא ראשון RACH הזדמנות מה היא UE אולי שימוש. עַל מוצלח השלמה of מה היא
מסירה, מה היא UE שולח a הודעה מְשׁוּמָשׁ ל לְאַשֵׁר מה היא מסירה. שימו לב שהאקראי
הליך הגישה במקרה זה אינו מבוסס על מחלוקת, ומכאן שבמערכת LTE אמיתית
שונה במקצת מזה המשמש בחיבור RRC שנוצר. שימו לב גם שהר"ע
מזהה הקדמה מסומן באמצעות פקודת המסירה הכלולה בבקשת המסירה X2
הודעת ACK שנשלחה מה-eNB היעד ל-eNB המקור; בפרט, ההקדמה היא
כלול ב-RACH-ConfigDedicated IE שהוא חלק מ-MobilityControlInfo.
[תמונה] דיאגרמת רצף של הליך קביעת התצורה מחדש של חיבור RRC עבור
תיק מסירה.UNINDENT

RRC פרוטוקול מודלים
כפי שציפינו בעבר, אנו מספקים שני דגמים שונים עבור תיבת ההילוכים ו
קליטה של ​​הודעות RRC: אידאל ו חוות דעת. כל אחד מהם מתואר באחד
הסעיפים הבאים.

אידאל RRC פרוטוקול מודל
על פי מודל זה, מיושם בשיעורים ו LteUeRrcProtocolIdeal ו
LteEnbrRrcProtocolIdeal, כל הודעות RRC ורכיבי המידע מועברים ביניהם
ה-eNB וה-UE בצורה אידיאלית, בלי לצרוך משאבי רדיו ובלי
שגיאות. מנקודת מבט של יישום, זה מושג על ידי העברת נתוני RRC
מבנה ישירות בין הישויות UE ו-eNB RRC, מבלי לערב את השכבות התחתונות
(PDCP, RLC, MAC, מתזמן).

חוות דעת RRC פרוטוקול מודל
מודל זה מיושם בשיעורים LteUeRrcProtocolReal ו LteEnbRrcProtocolReal
ומטרתה לעצב את השידור של RRC PDUs כפי שמבוצע בדרך כלל ב-LTE אמיתי
מערכות. באופן מיוחד:

· עבור כל הודעת RRC שנשלחת, נוצר RRC PDUs אמיתי בעקבות ה-ASN.1
קידוד של RRC PDUs ורכיבי מידע (IEs) המפורטים ב-[TS36331]. כמה
נעשה פישוט ביחס ל-IEs הכלולים ב-PDU, כלומר, רק אלה
IEs שימושיים למטרות סימולציה כלולים. לרשימה מפורטת בבקשה
ראה את ה-IEs המוגדרים ב lte-rrc-sap.h והשוו עם [TS36331].

· ה-RRC PDUs המקודדים נשלחים על נושאי רדיו איתות וכפופים לכך
מודל שידור המשמש לתקשורת נתונים, ובכך כולל תזמון, רדיו
צריכת משאבים, שגיאות ערוצים, עיכובים, שידורים חוזרים וכו'.

איתות רדיו נושא מודל
כעת אנו מתארים את מודל Signaling Radio Bearer המשמש עבור חוות דעת פרוטוקול RRC
מודל.

· SRB0 הודעות (מעל 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).

· SRB1 הודעות (מעל DCCH):

· כל הודעות SRB1 המעוצבות בסימולטור (למשל, RrcConnectionCompleted) הם
מיושם כמו במערכות LTE אמיתיות, כלומר, עם RLC SDU אמיתי שנשלח דרך RLC AM
באמצעות משאבי DL שהוקצו באמצעות דוחות מצב מאגר. ראה את דגם RLC
תיעוד לפרטים.

· SRB2 הודעות (מעל DCCH):

· לפי [TS36331], "SRB1 is ל RRC הודעות (איזה אולי לכלול a
בגב גלגלי NAS הודעה) as טוֹב as ל NAS הודעות קוֹדֵם ל מה היא הקמה
of SRB2, את כל באמצעות DCCH הגיוני ערוץ", ואילו "SRB2 is ל NAS הודעות,
באמצעות DCCH הגיוני ערוץ"ו"SRB2 יש ל a בעדיפות נמוכה יותר מֵאֲשֶׁר SRB1 ו is
תמיד מוגדר by E-UTRAN לאחר אבטחה הפעלה". דוגמנות
היבטים הקשורים לאבטחה אינם דרישה של מודל הדמיית LTE,
לפיכך אנו תמיד משתמשים ב-SRB1 ולעולם לא מפעילים את SRB2.

ASN.1 הַצפָּנָה of RRC של IE
ההודעות המוגדרות ב-RRC SAP, המשותפות לכל משתמשי/ספקי SAP של Ue/Enb, מועברות
במיכל שקוף אל/מ Ue/Enb. פורמט הקידוד עבור השונה
רכיבי מידע מצוינים ב-[TS36331], באמצעות כללי ASN.1 ב-Unaligned
גִרְסָה אַחֶרֶת. היישום ב-Ns3/Lte חולק במחלקות הבאות:

· Asn1Header : מכיל את הקידוד/פענוח של סוגי ASN בסיסיים

· RrcAsn1Header: יורש את Asn1Header ומכיל את הקידוד/פענוח של משותף
IE's מוגדר ב-[TS36331]

· מחלקות Rrc הודעות/IEs ספציפיות: מחלקה לכל אחת מההודעות המוגדרות ב-RRC
כותרת SAP

Asn1Header בכיתה - יישום of בסיס ASN.1 סוגים
מחלקה זו מיישמת את השיטות להסדרה / דה-סריאליזציה של סוגי ASN.1 שבהם נעשה שימוש
[TS36331], בהתאם לכללי הקידוד הארוזים ב-ITU-T X.691. הסוגים הנחשבים
הם:

· בוליאני: ערך בוליאני משתמש בביט בודד (1=נכון, 0=שקר).

· מספר שלם: מספר שלם מוגבל (עם ערכי מינימום ומקסימום מוגדרים) משתמש במינימום
כמות ביטים לקידוד הטווח שלו (מקסימום-דקה+1).

· מחרוזת סיביות: ביסטרינג תועתק טיפין טיפין למאגר הסידרה.

· Octetstring: לא בשימוש כרגע.

· רצף: הרצף יוצר הקדמה המציינת את נוכחותם של אופציונלי ו
שדות ברירת מחדל. זה גם מוסיף קצת המציין את נוכחותו של סמן הרחבה.

· Sequence...Of: הרצף...של הסוג מקודד את מספר האלמנטים של הרצף
כמספר שלם (הרכיבים הבאים יצטרכו להיות מקודד לאחר מכן).

· בחירה : מציינת איזה אלמנט מבין אלה בסט הבחירה מקודד.

· ספירה : מסודרת כמספר שלם המציין באיזה ערך נעשה שימוש, בין ה
אחדים בספירה, כאשר מספר האלמנטים בספירה כעליון
כָּרוּך.

· Null : הערך null אינו מקודד, אם כי פונקציית הסידרה שלו מוגדרת
לספק מפה ברורה יותר בין מפרט ליישום.

המחלקה יורשת מ-ns-3 Header, אך הפונקציה Deserialize() מוכרזת וירטואלית טהורה,
ובכך ירשו מחלקות שחייבו ליישם את זה. הסיבה היא שהסידריאליזציה תהיה
אחזר את האלמנטים בהודעות RRC, כל אחד מהם מכיל מידע שונה
אלמנטים.

בנוסף, יש לציין שאורך הבייטים המתקבל של סוג/הודעה ספציפיים
יכול להשתנות, בהתאם לנוכחות של שדות אופציונליים, ובשל הקידוד המאופטימלי.
לפיכך, הביטים המסודרים יעובדו באמצעות הפונקציה PreSerialize(), תוך שמירת ה-
התוצאה ב-m_serializationResult Buffer. כפי שהשיטות לקריאה/כתיבה במאגר ns3 הן
מוגדר על בסיס בתים, סיביות הסדרת מאוחסנות ב-m_serializationPendingBits
תכונה, עד ש-8 הסיביות מוגדרות וניתן לכתוב אותן באיטרטור המאגר. לבסוף, מתי
מפעיל את Serialize(), התוכן של התכונה m_serializationResult יועתק
to Buffer::Iterator פרמטר

RrcAsn1Header : Common IEs
מכיוון שחלק מרכיבי המידע נמצאים בשימוש עבור מספר הודעות RRC, מחלקה זו
מיישם את ה-IE הנפוצים הבאים:

· SrbToAddModList

· DrbToAddModList

· LogicalChannelConfig

· RadioResourceConfigDedicated

· PhysicalConfigDedicated

· SystemInformationBlockType1

· SystemInformationBlockType2

· RadioResourceConfigCommonSIB

Rrc ספציפי הודעות/IEs כיתות
ה-RRC SAP הבאות יושמו:

· RrcConnectionRequest

· RrcConnectionSetup

· RrcConnectionSetupCompleted

· RrcConnectionReconfiguration

· RrcConnectionReconfigurationCompleted

· מידע על הכנת מסירה

· RrcConnectionReestablishmentRequest

· RrcConnectionRestablishment

· RrcConnectionReestablishmentComplete

· RrcConnectionReestablishmentReject

· RrcConnectionRelease

NAS
המיקוד של מודל LTE-EPC הוא במצב NAS Active, התואם ל-EMM
רשום, ECM מחובר ו-RRC מחובר. בשל כך, הדברים הבאים
נעשה הפשטות:

· EMM ו-ECM אינם מעוצבים במפורש; במקום זאת, ישות ה-NAS ב-UE תעשה זאת
אינטראקציה ישירה עם ה-MME כדי לבצע פעולות שוות ערך (עם ברוטו
הפשטות) להעברת ה-UE למצבים 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. הראשון הוא השכבה מקצה לקצה, המספקת מקצה לקצה
קישוריות למשתמשים; שכבה זו כוללת את ה-UEs, ה-PGW והמארח המרוחק
(כולל נתבי אינטרנט ומארחים ביניהם), אך אינו כרוך ב-eNB.
כברירת מחדל, UEs מוקצים כתובת IPv4 ציבורית ברשת 7.0.0.0/8, וב-PGW
מקבל את הכתובת 7.0.0.1, המשמשת את כל ה-UE כשער להגיע לאינטרנט.

השכבה השנייה של רשת IP היא רשת ה-EPC המקומית. זה כרוך בכל eNB
צמתים והצומת SGW/PGW. רשת זו מיושמת כקבוצה של קישורים מנקודה לנקודה
המחברים כל eNB עם הצומת SGW/PGW; לפיכך, ל-SGW/PGW יש סט של
התקני נקודה לנקודה, שכל אחד מהם מספק קישוריות ל-eNB אחר. כברירת מחדל, א
רשת משנה 10.x.y.z/30 מוקצה לכל קישור מנקודה לנקודה (רשת משנה /30 היא הקטנה ביותר
רשת משנה המאפשרת שתי כתובות מארח נפרדות).

כפי שצוין על ידי 3GPP, תקשורת ה-IP מקצה לקצה מועברת דרך ה-EPC IP המקומי
רשת באמצעות GTP/UDP/IP. בהמשך, נסביר כיצד מיישמים מנהור זה
בדגם EPC. ההסבר נעשה על ידי דיון בזרימת הנתונים מקצה לקצה
חבילות.
[תמונה] זרימת נתונים ב-downlink בין האינטרנט ל-UE.UNINDENT

מלכתחילה, אנו רואים את המקרה של ה-downlink, המתואר באיור נתונים
תזרים in מה היא downlink בֵּין מה היא אינטרנט ו מה היא UE. Downlink מנות 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 Bearer זה שייך. לנשאי EPS יש מיפוי אחד לאחד ל-S1-U Bearers, אז
פעולה זו מחזירה את מזהה מנהרת הקצה 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), היא קובעת את ה-Bearer ID (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, שהיא נקודת הסיום של ה-downlink
תקשורת.
[תמונה] זרימת נתונים ב-uplink בין ה-UE לבין האינטרנט.UNINDENT

המקרה של ה-uplink מתואר באיור נתונים תזרים in מה היא uplink בֵּין מה היא UE ו
מה היא אינטרנט. מנות IP Uplink נוצרות על ידי יישום גנרי בתוך ה-UE,
ומועבר על ידי מחסנית ה-TCP/IP המקומית ל-LteUeNetDevice של ה-UE. ה
לאחר מכן LteUeNetDevice מבצע את הפעולות הבאות:

1. הוא מסווג את החבילה באמצעות TFT וקובע את נושא הרדיו אליו
שייך למנה (וה-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 ל-Radio Bearers;

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, והחבילה תעבור
דרך תהליך מסירת ה-Dowlink על מנת להגיע ליעד UE.

שימו לב שה-EPS Bearer QoS אינו נאכף על קישורי S1-U, ההנחה היא שה-
הקצאת יתר של רוחב הפס של הקישור מספיקה כדי לעמוד בדרישות ה-QoS של כולם
נושאים.

S1AP
ממשק S1-AP מספק אינטראקציה של מישור בקרה בין ה-eNB ל-MME. בתוך ה
סימולטור, ממשק זה מעוצב בצורה אידיאלית, עם אינטראקציה ישירה ביניהם
ה-eNB והאובייקטים MME, מבלי ליישם בפועל את הקידוד של הודעות S1AP
ורכיבי מידע המפורטים ב-[TS36413] ומבלי לשדר למעשה PDU כלשהו
בכל קישור.

הפרימיטיבים של S1-AP שעוצבו במודל הם:

· הודעת UE ראשונית

· בקשת הגדרת הקשר ראשונית

· תגובת הגדרת הקשר ראשונית

· בקשת מיתוג נתיב

· אישור בקשת החלפת נתיב

X2
ממשק X2 מחבר בין שני eNBs [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 של
[Sesia2009]; באופן מיוחד, lossless מסירה כמתואר בסעיף 2.6.3.2 של
[Sesia2009] אינו נתמך בזמן כתיבת שורות אלה.

תרשים רצף תרשים of מה היא מבוסס X2 מסירה להלן מראה את האינטראקציה של
ישויות של דגם X2 בסימולטור. התוויות המוצללות מציינות את הרגעים שבהם
מעבר UE או eNodeB למצב RRC אחר.
[תמונה] דיאגרמת רצף של המסירה מבוססת X2.UNINDENT

האיור מציג גם שני טיימרים במסגרת הליך המסירה: ה מסירה עזיבה
שעון עצר מתוחזק על ידי המקור eNodeB, בעוד ה- מסירה הצטרפות שעון עצר לפי המטרה
eNodeB. ניתן להגדיר את משך הטיימרים ב-
מסירהLeavingTimeoutDuration ו משך זמן ההצטרפות למסירה תכונות של
אלה LteEnbRrc מקרים. כאשר אחד מהטיימרים הללו יפוג, הליך המסירה
נחשב ככשל.

עם זאת, אין טיפול נכון בכישלון מסירה בגרסה הנוכחית של LTE
מודול. על המשתמשים לכוון את הסימולציה כראוי על מנת למנוע כשל במסירת המסירה,
אחרת עלולה להתרחש התנהגות בלתי צפויה. אנא עיין בסעיף
sec-tuning-handover-simulation של תיעוד המשתמש לכמה טיפים לגבי זה
עניין.

מודל X2 הוא ישות המשתמשת בשירותים מ:

· ממשקי X2,

· הם מיושמים כשקעים על גבי התקני נקודה לנקודה.

· הם משמשים לשליחת/קבלת הודעות X2 דרך ממשקי X2-C ו-X2-U
(כלומר התקן נקודה לנקודה המחובר לקישור נקודה לנקודה) לכיוון
peer eNB.

· אפליקציית S1.

· נכון לעכשיו, זה ה-EpcEnbApplication.

· הוא משמש כדי לקבל מידע הדרוש לפרוצדורות היסודיות של ה-X2
הודעות.

והוא מספק שירותים ל:

· הישות RRC (X2 SAP)

· כדי לשלוח/לקבל הודעות RRC. הישות X2 שולחת את הודעת ה-RRC כשקופה
מיכל בהודעת X2. הודעת RRC זו נשלחת ל-UE.

תרשים יישום מספר סימוכין of X2 ישות ו SAPs מציג את מודל ההטמעה של ה-X2
ישות ויחסיה עם כל הישויות והשירותים האחרים בפרוטוקול
ערימה.
[תמונה] מודל יישום של ישות X2 ו-SAPs.UNINDENT

ישות RRC מנהלת את התחלת הליך המסירה. זה נעשה ב-
תת-מודול ניהול מסירה של ישות eNB RRC. היעד eNB עשוי לבצע כמה
נהלי בקרת קבלה. זה נעשה בתת-מודול בקרת קבלה.
בתחילה, תת-מודול זה יקבל כל בקשת מסירה.

X2 ממשקים
דגם X2 מכיל שני ממשקים:

· ממשק X2-C. זהו ממשק הבקרה והוא משמש לשליחת X2-AP PDUs
(כלומר הנהלים האלמנטריים).

· ממשק X2-U. הוא משמש לשליחת נתוני הנושא כאשר יש DL העברה.

תרשים X2 ממשק פרוטוקול ערימות מציג את ערימות הפרוטוקול של ממשק X2-U ו
ממשק X2-C מעוצב בסימולטור.
[תמונה] ערימות פרוטוקול ממשק X2.UNINDENT

X2-C
ממשק X2-C הוא חלק הבקרה של ממשק X2 והוא משמש לשליחת
X2-AP PDUs (כלומר הנהלים היסודיים).

בערימת פרוטוקולי מטוס הבקרה המקורית של ממשק X2, SCTP משמש בתור התחבורה
פרוטוקול אך נכון לעכשיו, פרוטוקול SCTP אינו מעוצב בסימולטור ns-3 ושלו
היישום הוא מחוץ לתחום הפרויקט. פרוטוקול UDP משמש כ-datagram
פרוטוקול מכוון במקום פרוטוקול SCTP.

X2-U
ממשק X2-U משמש לשליחת נתוני הנושא כאשר יש DL העברה במהלך
ביצוע נוהל מסירה מבוסס X2. בדומה למה שנעשה עבור ה-S1-U
ממשק, מנות נתונים מובלעות על גבי GTP/UDP/IP כאשר נשלחות על זה
מִמְשָׁק. שימו לב שה-EPS Bearer QoS לא נאכף על קישורי X2-U, ההנחה היא
שהקצאת יתר של רוחב הפס של הקישור מספיקה כדי לעמוד בדרישות ה-QoS
מכל הנושאים.

X2 שֵׁרוּת מִמְשָׁק
ממשק השירות X2 משמש את ישות ה-RRC כדי לשלוח ולקבל הודעות של ה-X2
נהלים. הוא מחולק לשני חלקים:

· ה EpcX2SapProvider חלק מסופק על ידי ישות X2 ומשמש את ישות RRC ו

· ה EpcX2SapUser חלק מסופק על ידי ישות RRC ומשמש את ישות RRC.

הפרימיטיבים הנתמכים במודל X2-C שלנו מתוארים להלן
תת סעיפים.

X2-C פרימיטיבים ל מסירה הוצאת להורג
הפרימיטיבים הבאים משמשים עבור מסירה מבוססת X2:

· בקשת מסירה

· אישור בקשת מסירה

· כשל בהכנה למסירה

· העברת סטטוס SN

· שחרור UE CONTEXT

כל הפרימיטיבים שלעיל משמשים את מודל ה-RRC המיושם כעת במהלך
הכנה וביצוע הליך המסירה. השימוש בהם מקיים אינטראקציה עם ה-RRC
מכונת מצבים; לכן, הם לא נועדו לשמש להתאמה אישית של קוד, לפחות
אלא אם כן יש צורך לשנות את מכונת המצב RRC.

X2-C שלה פרימיטיבים
ניתן להשתמש בפרימיטיבים הבאים כדי ליישם רשת מאורגנת עצמית (SON)
פונקציות:

· טען מידע

· עדכון סטטוס משאבים

שים לב שמודל ה-RRC הנוכחי אינו משתמש בפרימיטיבים אלה בפועל, הם כלולים
במודל רק כדי לאפשר לפתח אלגוריתמי SON הכלולים בלוגיקת RRC
שעושים בהם שימוש.

כדוגמה ראשונה, אנו מראים כאן כיצד ניתן להשתמש בפרימיטיבי מידע העומס. אנחנו מניחים
שה-LteEnbRrc שונה כך שיכלול את משתני החברים החדשים הבאים:

std::vector
m_currentUlInterferenceOverloadIndicationList;
std::vector
m_currentUlHighInterferenceInformationList;
EpcX2Sap::RelativeNarrowbandTxBand m_currentRelativeNarrowbandTxBand;

לתיאור מפורט של סוג המשתנים הללו, אנו מציעים לעיין בקובץ
epc-x2-sap.h, תיעוד הדוoxygen המתאים, וההפניות בו ל-
סעיפים רלוונטיים של 3GPP TS 36.423. כעת, נניח שבזמן הריצה יש למשתנים האלה
הוגדר לערכים משמעותיים בעקבות המפרטים שהוזכרו זה עתה. אז את \ ה יכול \ ה
הוסף את הקוד הבא ביישום המחלקה LteEnbRrc כדי לשלוח עומס
מידע פרימיטיבי:

EpcX2Sap::CellInformationItem cii;
cii.sourceCellId = m_cellId;
cii.ulInterferenceOverloadIndicationList = m_currentUlInterferenceOverloadIndicationList;
cii.ulHighInterferenceInformationList = m_currentUlHighInterferenceInformationList;
cii.relativeNarrowbandTxBand = m_currentRelativeNarrowbandTxBand;

פרמטרים של EpcX2Sap::LoadInformationParams;
params.targetCellId = cellId;
params.cellInformationList.push_back (cii);
m_x2SapProvider->SendLoadInformation (פראמים);

הקוד לעיל מאפשר למקור 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 (פראמים);

השיטה eEnbRrc::DoRecvResourceStatusUpdate ייקרא כאשר היעד eNB יקבל
הודעת עדכון מצב המשאב. העיבוד הרצוי של הודעה זו צריך
לכן מיושם בשיטה זו.

לבסוף, נציין כי ההגדרה והעיבוד של הערכים המתאימים עבור
משתנה המועבר לפרימיטיבים המתוארים לעיל נחשב ספציפי ל-SON
אלגוריתם מיושם, ולפיכך אינו מכוסה בתיעוד זה.

אינו נתמך פרימיטיבים
פרימיטיבים לאופטימיזציה של יציבות ניידות כגון חיווי תקלות רדיו קישור ו
דוח מסירה אינו נתמך בשלב זה.

S11
ממשק S11 מספק אינטראקציה של מישור בקרה בין ה-SGW וה-MME באמצעות
פרוטוקול GTPv2-C שצוין ב-[TS29274]. בסימולטור, ממשק זה מעוצב ב-an
אופנה אידיאלית, עם אינטראקציה ישירה בין SGW ואובייקטי MME, ללא
יישום בפועל של קידוד ההודעות וללא העברת הודעות
PDU בכל קישור.

הפרימיטיבים של S11 שעוצבו במודל הם:

· צור בקשת מפגש

· צור תגובה למפגש

· שנה את בקשת הנושא

· שנה את תגובת הנושא

מבין הפרימיטיבים הללו, שני הראשונים משמשים בחיבור UE ראשוני עבור ה-
הקמת נושאי S1-U; השניים האחרים משמשים במהלך מסירה כדי להחליף את
נושאי S1-U מהמקור eNB ל-eNB היעד כתוצאה מהקליטה על ידי
ה-MME של הודעת PATH SWITCH REQUEST S1-AP.

כוח שליטה
סעיף זה מתאר את יישום ns-3 של Downlink ו-Uplink Power Control.

קישור למטה כוח שליטה
מכיוון שחלק מאלגוריתמי השימוש החוזר בתדרים דורשים בקרת כוח של Downlink, תכונה זו הייתה
מיושם גם ב-ns-3.
[תמונה] דיאגרמת רצף של Downlink Power Control.UNINDENT

תרשים רצף תרשים of קישור למטה כוח שליטה מציג את דיאגרמת הרצף של ההגדרה
downlink P_A ערך עבור UE, המדגיש את האינטראקציות בין ה-RRC והאחר
ישויות. אלגוריתם FR מפעיל את RRC לשנות ערכי P_A עבור UE. ואז RRC מתחיל
פונקציית RrcConnectionReconfiguration ליידע את UE על תצורה חדשה. לאחר
RrcConnectionReconfiguration מוצלח, RRC יכול להגדיר ערך P_A עבור UE על ידי קריאה
פונקציה SetPa מ-CphySap, הערך נשמר במפה חדשה m_paMap המכילה ערכי P_A
עבור כל UE המוגש על ידי eNb.

כאשר LteEnbPhy מתחיל תת-מסגרת חדשה, הודעות בקרת DCI מעובדות כדי לקבל וקטור של
השתמשו ב-RBs. כעת גם הפונקציה GeneratePowerAllocationMap(uint16_t rnti, int rbId) היא גם
שקוראים לו. פונקציה זו בודקת ערך P_A עבור UE, מייצרת חשמל עבור כל RB ומאחסנת אותו
m_dlPowerAllocationMap. אז מפה זו משמשת על ידי
פונקציית CreateTxPowerSpectralDensityWithPowerAllocation ליצירת Ptr
txPsd.

PdschConfigDedicated (TS 36.331, 6.3.2 PDSCH-Config) נוספה ב-
LteRrcSap::PhysicalConfigDedicated struct, המשמש ב-RrcConnectionReconfiguration
התהליך.

Uplink כוח שליטה
בקרת עוצמת הקישור בקישור שולטת בעוצמת השידור של הקישור הפיזי השונה
ערוצים. פונקציונליות זו מתוארת בסעיף 3 של 36.213GPP TS 5.

Uplink Power Control מופעל כברירת מחדל, וניתן להשבית אותו על ידי מערכת תכונות:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (false));

שני מנגנוני Uplink Power Control מיושמים:

· Open Loop Uplink Power Control: כוח השידור של UE תלוי בהערכה של
אובדן נתיב קישור ותצורת ערוץ

· Closed Loop Uplink Control Power Control: כמו ב-Open Loop, בנוסף eNB יכול לשלוט ב-UE
כוח שידור באמצעות פקודות TPC של בקרת כוח שידור מפורשת
מועבר ב-downlink.

כדי לעבור בין שני סוגי המנגנון הללו, יש לשנות פרמטר:

Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));

כברירת מחדל, בקרת חשמל במעגל סגור מופעלת.

שני מצבי of סגור לולאה Uplink כוח שליטה יש לו זמין:

· מצב מוחלט: TxPower מחושב עם ערכי TPC מוחלטים

· מצב צבירה: TxPower מחושב עם ערכי TPC מצטברים

כדי לעבור בין שני המצבים הללו, יש לשנות פרמטר:

Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

כברירת מחדל, מצב צבירה מופעל ופקודות TPC ב-DL-DCI מוגדרות על ידי כולם
מתזמנים ל-1, מה ממופה לערך של 0 במצב צבירה.

Uplink כוח שליטה ל PUSCH
ההגדרה של עוצמת השידור של UE עבור ערוץ משותף בקישור פיזי (PUSCH)
שידור מוגדר כדלקמן:

· אם ה-UE משדר PUSCH ללא PUCCH בו-זמנית עבור תא המשרת c, אז
כוח השידור של UE P_{PUSCH,c}(i) עבור שידור PUSCH בתת-מסגרת i עבור
הגשת תא c ניתנת על ידי:

· אם ה-UE משדר PUSCH בו-זמנית עם PUCCH עבור תא המשרת c, אז ה-UE
כוח שידור P_{PUSCH,c}(i) עבור שידור ה-PUSCH בתת-מסגרת i עבור ה-
הגשת תא c ניתנת על ידי:

מכיוון שבקרת כוח Uplink עבור PUCCH לא מיושם, מקרה זה אינו מיושם
גם כן.

· אם ה-UE אינו משדר PUSCH עבור תא המשרת c, עבור הצטברות של
פקודת TPC שהתקבלה בפורמט DCI 3/3A עבור PUSCH, ה-UE יניח שה-UE
כוח שידור P_{PUSCH,c}(i) עבור שידור ה-PUSCH בתת-מסגרת i עבור ה-
המשרת תא c מחושב על ידי

שם:

· P_{CMAX,c}(i) הוא כוח השידור המוגדר ב-UE המוגדר ב-3GPP 36.101. שולחן
6.2.2-1 בתת-מסגרת i לשרת תא c ו-{P}_{CMAX,c}(i) הוא הערך הליניארי
של P_{CMAX,c}(i). ערך ברירת המחדל עבור P_{CMAX,c}(i) הוא 23 dBm

· M_{PUSCH,c}(i) הוא רוחב הפס של הקצאת משאב PUSCH המתבטאת ב
מספר בלוקים של משאבים תקפים עבור תת-מסגרת i ומשרת תא c.

· P_{O_PUSCH,c}(j) הוא פרמטר המורכב מסכום של רכיב
P_{O_NOMINAL_PUSCH,c}(j) מסופק משכבות גבוהות יותר עבור j={0,1} ורכיב
P_{O_UE_PUSCH,c}(j) מסופק על ידי שכבות גבוהות יותר עבור j={0,1} להגשת תא c.
יש להרחיב את הודעת SIB2 כדי לשאת את שני הרכיבים הללו, אך כרגע
ניתן להגדיר אותם באמצעות מערכת תכונות:

Config::SetDefault ("ns3::LteUePowerControl::PoNominalPusch", IntegerValue (-90));
Config::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. פרמטר זה ניתן להגדרה לפי מערכת תכונות:

Config::SetDefault ("ns3::LteUePowerControl::Alpha", DoubleValue (0.8));

· PL_{c} הוא אומדן אובדן הנתיב בקישור למטה המחושב ב-UE לשרת תא c
ב-dB ו-PL_{c} = referenceSignalPower - RSRP מסונן בשכבה גבוהה יותר, כאשר
referenceSignalPower מסופק על ידי שכבות גבוהות יותר ו-RSRP. referenceSignalPower
מסופק בהודעת SIB2

· ומקרה cond מיושם.

· 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}); K_{PUSCH} =
4 עבור FDD.

אם UE הגיעה ל-P_{CMAX,c}(i) לשירות תא c, פקודות TPC חיוביות עבור
המשרתים תא c אינם מצטברים. אם ה-UE הגיע למינימום הספק, שלילי
פקודות TPC אינן מצטברות. כוח UE מינימלי מוגדר ב-TS36.101
סעיף 6.2.3. ערך ברירת המחדל הוא -40 dBm.

אם מצב צבירה אינו מופעל f_{c}(i) ניתן על ידי:

כאשר: elta_{PUSCH,c} הוא ערך תיקון, המכונה גם פקודת TPC
והוא כלול ב-PDCCH עם DCI; elta_{PUSCH,c}(i - K_{PUSCH}) הופעל
PDCCH/EPDCCH עם DCI לשרת תא c על תת-מסגרת (i - K_{PUSCH}); K_{PUSCH} =
4 עבור FDD.

מיפוי של שדה פקודה TPC בפורמט DCI 0/3/4 למוחלט ומצטבר
ערכי elta_{PUSCH,c} מוגדרים ב-TS36.231 סעיף 5.1.1.1 טבלה 5.1.1.1-2

Uplink כוח שליטה ל PUCCH
מכיוון שכל הודעות השליטה ב-uplink הן הודעות אידיאליות ואינן צורכות שום רדיו
משאבים, Uplink Power Control עבור PUCCH אינו נחוץ והוא אינו מיושם.

Uplink כוח שליטה ל SRS
ההגדרה של עוצמת השידור של UE P_{SRS} עבור ה-SRS המשודרת על תת-מסגרת i עבור
המשרת תא c מוגדר על ידי

שם:

· P_{CMAX,c}(i) הוא כוח השידור המוגדר ב-UE המוגדר ב-3GPP 36.101. שולחן
6.2.2-1. ערך ברירת המחדל עבור P_{CMAX,c}(i) הוא 23 dBm

· P_{SRS_OFFSET,c}(m) מוגדר חצי סטטי על ידי שכבות גבוהות יותר עבור m=0,1 עבור
משרת תא ג. עבור שידור SRS נתון טריגר מסוג 0 אז m=0,1 ועבור SRS
שידור נתון טריגר סוג 1 ואז m=1. עבור K_{s} = 0 P_Srs_Offset_Value הוא
מחושב עם משוואה:

פרמטר זה ניתן להגדרה לפי מערכת תכונות:

Config::SetDefault ("ns3::LteUePowerControl::PsrsOffset", IntegerValue (7));

· M_{SRS,c} הוא רוחב הפס של שידור SRS בתת-מסגרת i עבור תא שירות
c מבוטא במספר בלוקים של משאבים. ביישום הנוכחי נשלח SRS
על כל רוחב הפס של UL.

· f_{c}(i) הוא מצב התאמת בקרת הכוח הנוכחי של PUSCH עבור הגשת תא c,
כפי שמוגדר ב Uplink כוח שליטה ל PUSCH

· P_{O_PUSCH,c}(j) ו-lpha_{c}(j) הם פרמטרים כפי שהוגדרו ב- Uplink כוח
שליטה ל PUSCH, כאשר j = 1 .

חֶלקִי תדר שימוש חוזר
סקירה כללית
סעיף זה מתאר את התמיכה ב-ns-3 עבור אלגוריתמים של שימוש חוזר בתדר חלקי. את כל
אלגוריתמים מיושמים מתוארים ב-[ASHamza2013]. נכון לעכשיו 7 אלגוריתמי FR הם
מוטמע:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

נוצרה מחלקה חדשה LteFfrAlgorithm והיא מחלקה מופשטת לשימוש חוזר בתדרים
יישום אלגוריתמים. כמו כן, נוספו שני SAPs חדשים בין FR-Scheduler ו-FR-RRC.
[תמונה] דיאגרמת רצף של תזמון עם אלגוריתם FR.UNINDENT

תרשים רצף תרשים of תזמון עם FR אַלגוֹרִיתְם מציג את דיאגרמת הרצף של
תהליך תזמון עם אלגוריתם FR. בתחילת תהליך התזמון, מתזמן
מבקשת מישות FR RBGs זמינים. על פי היישום FR מחזירה את כל ה-RBGs
זמינים בתא או סנן אותם על סמך המדיניות שלו. ואז כשמנסים להקצות כמה
RBG ל-UE, מתזמן שואל את ישות FR אם RBG זה מותר עבור UE זה. כאשר FR חוזר
נכון, המתזמן יכול להקצות את ה-RBG הזה ל-UE הזה, אם לא המתזמן בודק RBG אחר
עבור UE זה. שוב, תגובת FR תלויה ביישום ובמדיניות המיושמת על UE.

נתמך FR אלגוריתמים
לא תדר שימוש חוזר
אלגוריתם NoOp FR (מחלקה LteFrNoOpAlgorithm) מיישם שימוש חוזר בתדר מלא
תכנית, כלומר לא מתבצעת חלוקת תדרים בין eNBs של אותה רשת
(גורם שימוש חוזר בתדר, FRF שווה 1). eNBs משתמש ברוחב פס שלם של המערכת ומשדר
עם כוח אחיד על כל RBGs. זוהי התוכנית הפשוטה ביותר והיא הדרך הבסיסית של
הפעלת רשת LTE. סכימה זו מאפשרת להשיג את קצב הנתונים הגבוה ביותר. אבל
מצד שני, עקב רמות הפרעות כבדות של תאים שכנים, קצה התא
ביצועי המשתמשים מוגבלים מאוד.

תרשים מלא תדר שימוש חוזר תכנית להלן מציג תדר ותוכנית כוח עבור Full
ערכת שימוש חוזר בתדירות.
[תמונה] ערכת שימוש חוזר בתדר מלא.UNINDENT

ב-ns-3, אלגוריתם NoOp FR תמיד מאפשר למתזמן להשתמש ברוחב פס מלא ומאפשר
כל UEs להשתמש בכל RBG. זה פשוט לא עושה שום דבר חדש (כלומר זה לא מגביל את eNB
רוחב פס, אלגוריתם FR מושבת), זהו היישום הפשוט ביותר של FrAlgorithm
class ומותקן ב-eNb כברירת מחדל.

קשה תדר שימוש חוזר
אלגוריתם Hard Frequency Reuse מספק את הסכימה הפשוטה ביותר המאפשרת להפחית
רמת הפרעות בין תאים. בתכנית זו רוחב הפס התדר כולו מחולק ל
מעט (בדרך כלל 3, 4 או 7) תת-להקות מפורקות. eNBs סמוכים מוקצים עם שונים
תת-להקה. גורם שימוש חוזר בתדר שווה למספר תת-הפסים. תכנית זו מאפשרת
להפחית משמעותית את ICI בקצה התא, כך שהביצועים של משתמשי סלולר משתפרים.
אבל בשל העובדה, שכל eNB משתמש רק בחלק אחד מרוחב הפס כולו, קצב נתונים שיא
הרמה מופחתת גם בגורם השווה לגורם השימוש החוזר.

תרשים קשה תדר שימוש חוזר תכנית להלן תוכנית תדר וכוח עבור Hard
ערכת שימוש חוזר בתדירות.
[תמונה] ערכת שימוש חוזר בתדר קשה. UNINDENT

ביישום שלנו, לאלגוריתם ה-Hard FR יש רק וקטור של RBGs זמין עבור eNB
והעבירו אותו ל-MAC Scheduler במהלך תזמון פונקציות. כאשר מתזמן לשאול, אם RBG הוא
מותר עבור UE ספציפי זה תמיד מחזיר אמת.

קפדן תדר שימוש חוזר
סכימת שימוש חוזר בתדר קפדני היא שילוב של סכימות שימוש חוזר בתדר מלא וקשה. זה
מורכב מחלוקת רוחב הפס של המערכת לשני חלקים שיהיו שונים
שימוש חוזר בתדר. תת-פס אחד נפוץ של רוחב הפס של המערכת משמש בכל פנים תא
(שימוש חוזר בתדר-1), בעוד שהחלק השני של רוחב הפס מחולק בין
eNBs שכנים כמו בשימוש חוזר בתדר קשה (שימוש חוזר בתדר-N, N>1), על מנת ליצור
תת-פס אחד עם רמת הפרעות בין תאים נמוכה בכל מגזר. UEs מרכז יהיו
ניתן עם נתחי התדר בשימוש חוזר במלואו, בעוד ש-UEs בקצה התא עם נתחים אורטוגונליים.
זה אומר ש-UEs פנימיים מתא אחד אינם חולקים ספקטרום כלשהו עם UEs קצה
תא שני, מה שמפחית הפרעות עבור שניהם. כפי שניתן לשים לב, Strict FR דורש א
סך של N + 1 תת-רצועות, ומאפשר להשיג RFR באמצע בין 1 ל-3.

תרשים קפדן תדר שימוש חוזר תכנית להלן תוכנית תדר וכוח עבור Strict
סכימת שימוש חוזר בתדירות עם מקדם שימוש חוזר בקצה התא של N = 3.
[תמונה] ערכת שימוש חוזר בתדירות קפדנית.UNINDENT

ביישום שלנו, לאלגוריתם Strict FR יש שתי מפות, אחת לכל תת-פס. אם UE
ניתן להגיש בתוך תת-פס פרטי, ה-RNTI שלו מתווסף למפת m_privateSubBandUe. אם
ניתן להגיש UE בתוך תת-פס משותף, ה-RNTI שלו מתווסף למפת m_commonSubBandUe.
אלגוריתם FR קפדני צריך להחליט באיזו תת-פס UE יש להגיש. זה משתמש
מדידות UE שסופקו על ידי RRB והשוו אותן עם סף איכות האות (זה
ניתן לכוונן בקלות את הפרמטר על ידי מנגנון תכונה). לסף יש השפעה על
יחס רדיוס פנימי לתא.

רך תדר שימוש חוזר
בשיטת Soft Frequency Reuse (SFR) כל eNb משדר על פני כל רוחב הפס של המערכת,
אבל יש שתי תתי פסים, בתוך UEs מוגשות עם רמת הספק שונה. מאז
UE-מרכזי תאים חולקים את רוחב הפס עם תאים שכנים, הם בדרך כלל משדרים במהירות נמוכה יותר
רמת הספק מאשר UEs קצה התא. SFR יעיל יותר ברוחב פס מאשר Strict FR,
מכיוון שהוא משתמש ברוחב הפס של המערכת כולו, אבל זה גם מביא ליותר הפרעות לשניהם
פנים התא ומשתמשי קצה.

ישנן שתי גרסאות אפשריות של ערכת SFR:

· בגרסה הראשונה, תת-הפס המיועדת ל-UEs קצה התא עשוי לשמש גם על ידי
ה-UEs במרכז התא אך עם רמת הספק מופחתת ורק אם הוא אינו תפוס על ידי
ה-UEs בקצה התא. תת-פס מרכז תא זמין ל-UEs המרכזיים בלבד. דמות
רך תדר שימוש חוזר תכנית גרסה 1 להלן מציג תדר ותוכנית כוח עבור
גרסה זו של ערכת שימוש חוזר בתדרים רכים.
[תמונה] סכימת שימוש חוזר בתדר רך גרסה 1.UNINDENT

· בגרסה השנייה, ל-UEs במרכז התא אין גישה לתת-פס קצה התא. ב
בדרך זו, כל תא יכול להשתמש בכל רוחב הפס של המערכת תוך הפחתת
הפרעה לתאים של השכנים. מצד שני, רמת ICI נמוכה יותר ב-
קצה התא מושג על חשבון ניצול נמוך יותר של ספקטרום. דמות רך
תדר שימוש חוזר תכנית גרסה 2 להלן מציג תדר ותוכנית כוח לכך
גרסה של ערכת שימוש חוזר בתדרים רכים.
[תמונה] סכימת שימוש חוזר בתדר רך גרסה 2.UNINDENT

אלגוריתם SFR שומר על שתי מפות. אם יש להגיש UE עם רמת הספק נמוכה יותר, שלה
RNTI נוסף למפת m_lowPowerSubBandUe. אם יש להגיש UE בעוצמה גבוהה יותר
ברמה, ה-RNTI שלו מתווסף למפת m_highPowerSubBandUe. להחליט באיזו רמת כוח
UE צריך להיות מוגש אלגוריתם SFR להשתמש במדידות UE, ומשווה אותם
מפתן. סף איכות אות ו-PdschConfigDedicated (כלומר ערך P_A) עבור פנימי
והאזור החיצוני יכול להיות מוגדר על ידי מערכת תכונות. SFR משתמש ב-Downlink Power
שליטה המתוארת כאן.

רך חֶלקִי תדר שימוש חוזר
שימוש חוזר בתדר שבר רך (SFFR) הוא שילוב של תדר קפדני ורך
שימוש חוזר בתכניות. בעוד Strict FR אינם משתמשים בתתי-הרצועות שהוקצו לאזור החיצוני ב-
תאים סמוכים, FFR soft משתמש בתתי-הפסים הללו עבור ה-UEs הפנימיים עם עוצמת שידור נמוכה. כפי ש
כתוצאה מכך, ה-SFFR, כמו SFR, משתמש בתת-הפס עם רמת הספק שידור גבוהה ועם נמוך
רמת עוצמת השידור. בניגוד ל-Soft FR וכמו Strict FR, ה-Soft FFR משתמש במשותף
תת-פס שיכול לשפר את התפוקה של המשתמשים הפנימיים.

תרשים רך חֶלקִי חֶלקִי תדר שימוש חוזר תכנית להלן מציג תדירות ו
תוכנית כוח לשימוש חוזר בתדר חלקי רך.
[תמונה] סכימת שימוש חוזר בתדר חלקי חלקי רך. UNINDENT

משופר חֶלקִי תדר שימוש חוזר
Enhanced Fractional Frequency Reuse (EFFR) המתואר ב-[ZXie2009] מגדיר 3 סוגי תאים
עבור תאים שכנים ישירות במערכת סלולרית, ועתודות עבור כל סוג תא a
חלק מכל רצועת התדרים הנקראת ראשי מגזר, אשר בין תאים מסוגים שונים
צריך להיות אורתוגונלי. שאר ערוצי המשנה מהווים את המשני מגזר. ה
ראשי מגזר של סוג תא הוא באותו זמן חלק מה- המשני פלחים
השייכים לשני סוגי התאים האחרים. כל תא יכול לתפוס את כל תתי הערוצים שלו ראשי
מגזר כרצונו, בעוד שרק חלק מתתי הערוצים ב- המשני מגזר ניתן להשתמש בו
על ידי תא זה באופן מודע להפרעות ראשי מגזר של כל תא מחולק
לשימוש חוזר-3 חלק ושימוש חוזר-1 חלק. ניתן לעשות שימוש חוזר בחלק החוזר-1 על ידי כל סוגי התאים
במערכת, בעוד שניתן לעשות שימוש חוזר בלעדי בחלק של שימוש חוזר-3 רק על ידי סוג אחר
תאים (כלומר לא ניתן לעשות שימוש חוזר בתתי-השימוש החוזר-3 על ידי תאים שכנים ישירות). עַל
מה היא המשני מגזר התא פועל כאורח, ותופסת ערוצי משנה משניים היא
למעשה לעשות שימוש חוזר בתתי הערוצים הראשיים השייכים לתאים הסמוכים ישירות, כך
שימוש חוזר על המשני מגזר על ידי כל תא צריך להתאים לשני כללים:

· לפקח לפני השימוש

· שימוש חוזר במשאבים על בסיס הערכת SINR

כל תא מאזין בכל תת ערוץ משני כל הזמן. ולפני הכיבוש, זה
עושה הערכת SINR על פי מידע איכות הערוץ שנאסף (CQI) ו
בוחר משאבים עם ערכי ההערכה הטובים ביותר לשימוש חוזר. אם ערך CQI עבור RBG הוא למעלה
סף מוגדר עבור משתמש כלשהו, ​​ניתן לבצע שידור עבור משתמש זה באמצעות זה
RBG.

בתהליך התזמון [ZXie2009] מתואר, הוא מורכב משלושה שלבים ושניים
מדיניות תזמון. מכיוון שאף אחד מהמתזמנים המיושמים כרגע לא מאפשר זאת
התנהגות, הוחל קצת פישוט. בהטמעה שלנו שימוש חוזר-1 תתי ערוצים יכולים
לשמש רק את משתמשי מרכז הסלולר. שימוש חוזר-3 ערוצי משנה יכולים לשמש את משתמשי הקצה, ורק
אם אין משתמש קצה, ניתן להגיש שידור עבור משתמשי מרכז סלולרי בשימוש חוזר-3
תתי ערוצים.

תרשים משופר חֶלקִי חֶלקִי תדר שימוש חוזר תכנית להלן מציג תדירות ו
תוכנית צריכת חשמל עבור שימוש חוזר בתדר חלקי משופר.
[תמונה] ערכת שימוש חוזר בתדירות שברית משופרת. UNINDENT

מופץ חֶלקִי תדר שימוש חוזר
אלגוריתם שימוש חוזר בתדר שבר מבוזר זה הוצג ב-[DKimura2012]. זה
מבצע אופטימיזציה אוטומטית של תת-רצועות קצה התא על ידי התמקדות בהפצת משתמשים (ב
במיוחד, חלוקת כוח קבלה). אלגוריתם זה בוחר באופן אדפטיבי RBs עבור
תת-רצועת קצה התא על בסיס מידע תיאום מתאים סמוכים ומודיעים
תחנות הבסיס של התאים הסמוכים, אשר RBs שהיא בחרה להשתמש בהם בתת פס קצה.
תחנת הבסיס של כל תא משתמשת במידע שהתקבל ובמשוואה הבאה כדי
חשב את מדד רצועת הקצה של התא A_{k} עבור כל RB.

כאשר J הוא קבוצה של תאים שכנים, X_{j,k}=0,1 הוא ה-RNTP מהתא השכן ה-j.
זה לוקח ערך של 1 כאשר RB k-th בתא השכן j-th משמש כקצה התא
תת-להקה ו-0 אחרת. הסמל w_{j} מציין משקל ביחס לתא j הסמוך,
כלומר, מספר המשתמשים שעבורם ההבדל בין עוצמת האות
מתקבל מהתא המשרת i והעוצמה של האות המתקבל מהסמוך
תא j קטן מערך סף (כלומר, מספר המשתמשים ליד קצה התא ב-
תא שירות). הפרש צריכת חשמל גדול שהתקבל אומר שמשתמשים בקצה התא ב-i-th
התא סובלים מהפרעות חזקות מהתא ה-j.

ה-RB שעבורו המדד A_{k} הוא הקטן ביותר נחשב לפחות מושפע ממנו
הפרעה מתא אחר. תא הגשה בוחר מספר מוגדר של RBs כ
תת-רצועת קצה התא בסדר עולה של A_{k}. כתוצאה מכך, RBs שבו קטן
מספר המשתמשים בקצה הסלולרי מקבלים הפרעות גבוהות מתחנות בסיס סמוכות
נבחר.

ה-RNTP המעודכן נשלח לאחר מכן לכל התאים השכנים. על מנת להימנע מחסר משמעות
תנודה של בחירת פס-קצה התא, תחנת בסיס מתעלמת מ-RNTP מבסיס אחר
תחנה בעלת מזהה תא גדול יותר מתחנת הבסיס.

חזרה על תהליך זה בכל התאים מאפשרת הקצאת RBs לאזורי קצה התא
להיות מותאם על פני המערכת ולהיות מותאם עם שינויים בהפצת המשתמשים.

תרשים רצף תרשים of מופץ תדר שימוש חוזר תָכְנִית להלן מציג רצף
תרשים של תוכנית שימוש חוזר בתדירות מבוזרת.
[תמונה] דיאגרמת רצף של Disted Frequency Reuse Scheme.UNINDENT

עוזרים
שני אובייקטים עוזרים משמשים להגדרת סימולציות ולהגדיר את הרכיבים השונים.
החפצים הללו הם:

· LteHelper, אשר דואגת לתצורת רשת הגישה לרדיו LTE, as
כמו גם של תיאום ההגדרה והשחרור של נושאי EPS. ה LteHelper בכיתה
מספק הן את הגדרת ה-API והן את היישום שלה.

· EpcHelper, שדואגת לתצורה של ליבת ה-Evolved Packet. ה
EpcHelper class הוא מחלקת בסיס מופשטת אשר מספקת רק את הגדרת ה-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,
אופציונלי כולל את ליבת המנות המתפתחת (EPC). תהליך ביצוע כזה
סימולציות כוללות בדרך כלל את השלבים הבאים:

1. לְהַגדִיר מה היא תרחיש להיות הדמיה

2. לכתוב a הדמיה התוכנית שמשחזר את התרחיש הרצוי
טופולוגיה/ארכיטקטורה. זה נעשה באמצעות גישה לספריית דגמי ns-3 LTE באמצעות
ns3::LteHelper API מוגדר ב src/lte/helper/lte-helper.h.

3. לפרט תצורה פרמטרים של החפצים המשמשים עבור
סימולציה. ניתן לעשות זאת באמצעות קבצי קלט (דרך ns3::ConfigStore) או
ישירות בתוך תוכנית הסימולציה.

4. גדר מה היא רצוי תפוקה שיופק על ידי הסימולטור

5. הפעלה הסימולציה.

כל ההיבטים הללו יוסברו בסעיפים הבאים באמצעות מעשי
דוגמאות.

בסיסי הדמיה התוכנית
הנה תוכנית הסימולציה המינימלית הדרושה לביצוע הדמיית LTE בלבד
(ללא EPC).

1. לוח דוד ראשוני:

#לִכלוֹל
#לִכלוֹל
#לִכלוֹל
#לִכלוֹל

שימוש במרחב שמות ns3;

int main (int argc, char * argv [])
{
// שאר תוכנית הסימולציה בהמשך

2. צור LteHelper אובייקט:

Ptr lteHelper = CreateObject ();

זה יציג כמה אובייקטים נפוצים (למשל, אובייקט הערוץ) ויספק את
שיטות להוספת eNBs ו-UEs ולהגדיר אותם.

3. לִיצוֹר צומת אובייקטים עבור eNB/ים ו-UEs:

NodeContainer enbNodes;
enbNodes.Create (1);
NodeContainer ueNodes;
ueNodes.Create (2);

שים לב שלמופעי הצומת לעיל בשלב זה עדיין אין פרוטוקול LTE
ערימה מותקנת; הם רק צמתים ריקים.

4. הגדר את מודל הניידות עבור כל הצמתים:

MobilityHelper ניידות;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (enbNodes);
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (ueNodes);

האמור לעיל יציב את כל הצמתים בקואורדינטות (0,0,0). אנא עיין ב
תיעוד של מודל הניידות ns-3 כיצד להגדיר מיקום או תצורה משלך
תנועת צומת.

5. התקן ערימת פרוטוקול LTE על ה-eNB:

NetDeviceContainer enbDevs;
enbDevs = lteHelper->InstallEnbDevice (enbNodes);

6. התקן ערימת פרוטוקול LTE ב-UEs:

NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);

7. חבר את ה-UEs ל-eNB. זה יגדיר כל UE בהתאם ל-eNB
תצורה, וצור חיבור RRC ביניהם:

lteHelper->Attach (ueDevs, enbDevs.Get (0));

8. הפעל נושא רדיו נתונים בין כל UE לבין ה-eNB שאליו הוא מחובר:

enum EpsBearer::Qci q = EpsBearer::GBR_CONV_VOICE;
EpsBearer bearer (q);
lteHelper->ActivateDataRadioBearer (ueDevs, bearer);

שיטה זו תפעיל גם שני מחוללי תעבורת רוויה עבור אותו נושא, אחד
ב-uplink ואחד ב-downlink.

9. הגדר את זמן העצירה:

סימולטור::עצור (שניות (0.005));

זה נחוץ אחרת הסימולציה תימשך לנצח, כי (בין היתר) ה
אירוע התחלה של תת-מסגרת מתוזמן שוב ושוב, ומתזמן הסימולטור של ns-3 יעשה זאת
מכאן שלעולם לא נגמרו האירועים.

10. הפעל את הסימולציה:

סימולטור::Run ();

11. ניקוי ויציאה:

סימולטור::הרוס ();
0 לחזור;
}

כיצד להדר ולהפעיל תוכניות סימולציה, עיין ב[ns3tutorial].

תְצוּרָה of LTE מודל פרמטרים
כל הפרמטרים הרלוונטיים של מודל LTE מנוהלים באמצעות מערכת התכונות ns-3.
אנא עיין ב[ns3tutorial] וב-[ns3manual] לקבלת מידע מפורט על כל
שיטות אפשריות לעשות את זה (משתנים סביבתיים, C++ API, GtkConfigStore...).

בהמשך, אנו רק מסכמים בקצרה כיצד לעשות זאת באמצעות קבצי קלט יחד עם
ה-ns-3 ConfigStore. קודם כל, אתה צריך לשים את הדברים הבאים בסימולציה שלך
תוכנית, מיד אחרי ראשי () מתחיל:

CommandLine cmd;
cmd.Parse (argc, argv);
ConfigStore inputConfig;
inputConfig.ConfigureDefaults ();
// לנתח שוב כדי שתוכל לעקוף את ערכי ברירת המחדל משורת הפקודה
cmd.Parse (argc, argv);

כדי שהאמור לעיל יעבוד, ודא שגם אתה #include "ns3/config-store.h". כעת צור א
קובץ טקסט בשם (לדוגמה) input-defaults.txt ציון ערכי ברירת המחדל החדשים ש
אתה רוצה להשתמש עבור כמה תכונות:

ברירת מחדל ns3::LteHelper::Scheduler "ns3::PfFfMacScheduler"
ברירת מחדל ns3::LteHelper::PathlossModel "ns3::FriisSpectrumPropagationLossModel"
ברירת המחדל ns3::LteEnbNetDevice::UlBandwidth "25"
ברירת המחדל ns3::LteEnbNetDevice::DlBandwidth "25"
ברירת המחדל ns3::LteEnbNetDevice::DlEarfcn "100"
ברירת המחדל ns3::LteEnbNetDevice::UlEarfcn "18100"
ברירת מחדל ns3::LteUePhy::TxPower "10"
ברירת מחדל ns3::LteUePhy::NoiseFigure "9"
ברירת המחדל ns3::LteEnbPhy::TxPower "30"
ברירת המחדל ns3::LteEnbPhy::NoiseFigure "5"

נניח שתוכנית הסימולציה שלך נקראת src/lte/examples/lte-sim-with-input, אתה יכול
כעת העבירו את ההגדרות הללו לתוכנית הסימולציה באופן הבא:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Load --ns3::ConfigStore::FileFormat=RawText" --הפעל את src/lte/examples/lte-sim-with-input

יתר על כן, אתה יכול ליצור קובץ קלט תבנית עם הפקודה הבאה:

./waf --command-template="%s --ns3::ConfigStore::Filename=input-defaults.txt --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=RawText" --הפעל את src/lte/examples/lte-sim-with-input

שימו לב שהאמור לעיל יכניס לקובץ input-defaults.txt את כל ערכי ברירת המחדל ש
רשומים במבנה הספציפי שלך של הסימולטור, כולל הרבה לא-LTE
תכונות.

גדר LTE מק מתזמן
ישנם מספר סוגים של מתזמן LTE MAC שיכול לבחור כאן. המשתמש יכול להשתמש הבא
קודים להגדרת סוג מתזמן:

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerType ("ns3::FdMtFfMacScheduler"); // מתזמן FD-MT
lteHelper->SetSchedulerType ("ns3::TdMtFfMacScheduler"); // מתזמן TD-MT
lteHelper->SetSchedulerType ("ns3::TtaFfMacScheduler"); // מתזמן TTA
lteHelper->SetSchedulerType ("ns3::FdBetFfMacScheduler"); // מתזמן FD-BET
lteHelper->SetSchedulerType ("ns3::TdBetFfMacScheduler"); // מתזמן TD-BET
lteHelper->SetSchedulerType ("ns3::FdTbfqFfMacScheduler"); // מתזמן FD-TBFQ
lteHelper->SetSchedulerType ("ns3::TdTbfqFfMacScheduler"); // מתזמן TD-TBFQ
lteHelper->SetSchedulerType ("ns3::PssFfMacScheduler"); // מתזמן PSS

ל-TBFQ ול-PSS יש יותר פרמטרים מתזמנים אחרים. משתמשים יכולים להגדיר את הפרמטרים האלה
בדרך הבאה:

* מתזמן TBFQ::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("DebtLimit", IntegerValue(yourvalue)); // ערך ברירת מחדל -625000 בתים (-5Mb)
lteHelper->SetSchedulerAttribute("CreditLimit", UintegerValue(yourvalue)); // ערך ברירת מחדל 625000 בתים (5Mb)
lteHelper->SetSchedulerAttribute("TokenPoolSize", UintegerValue(yourvalue)); // ערך ברירת מחדל 1 בייט
lteHelper->SetSchedulerAttribute("CreditableThreshold", UintegerValue(yourvalue)); // ערך ברירת מחדל 0

* מתזמן PSS::

Ptr lteHelper = CreateObject ();
lteHelper->SetSchedulerAttribute("nMux", UIntegerValue(yourvalue)); // המספר המרבי של UE שנבחר על ידי מתזמן TD
lteHelper->SetSchedulerAttribute("PssFdSchedulerType", StringValue("CoItA")); // סוג מתזמן PF ב-PSS

ב-TBFQ, ערכי ברירת המחדל של מגבלת חוב ומגבלת אשראי מוגדרים ל-5Mb ו-5Mb
בהתאמה מבוסס על נייר [FABokhari2009]. היישום הנוכחי לא לוקח בחשבון
סף אשראי (C = 0). ב-PSS, אם המשתמש לא מגדיר nMux, PSS יגדיר ערך זה ל
מחצית מסך ה-UE. מתזמן ה-FD המוגדר כברירת מחדל הוא PFsch.

בנוסף, קצב יצירת אסימון ב-TBFQ וקצב סיביות יעד ב-PSS צריכים להיות
מוגדר על ידי קצב סיביות מובטח (GBR) או קצב סיביות מקסימלי (MBR) ב-epc bearer QoS
פרמטרים. משתמשים יכולים להשתמש בקודים הבאים כדי להגדיר GBR ו-MBR גם ב-downlink וגם
קישור למעלה:

Ptr lteHelper = CreateObject ();
enum EpsBearer::Qci q = EpsBearer::yourvalue; // הגדר סוג Qci
GbrQosInformation qos;
qos.gbrDl = yourvalue; // Downlink GBR
qos.gbrUl = yourvalue; // Uplink GBR
qos.mbrDl = yourvalue; // Downlink MBR
qos.mbrUl = yourvalue; // Uplink MBR
EpsBearer bearer (q, qos);
lteHelper->ActivateDedicatedEpsBearer (ueDevs, bearer, EpcTft::Default ());

ב-PSS, TBR מתקבל מ-GBR בפרמטרים של QoS ברמת נושא. ב-TBFQ, יצירת אסימונים
קצב מתקבל מהגדרת MBR בפרמטרים של QoS ברמת נושא, ולכן
צריך להגדיר באופן עקבי. עבור תעבורת קצב סיביות קבוע (CBR), זה מוצע
כדי להגדיר את MBR ל-GBR. עבור תעבורת קצב סיביות שונות (VBR), מומלץ להגדיר MBR k פעמים
גדול מ-GBR כדי לכסות את קצב שיא התעבורה. ביישום הנוכחי, k הוא
מוגדר לשלושה על סמך נייר [FABokhari2009]. בנוסף, הגרסה הנוכחית של TBFQ אינה עושה זאת
קחו בחשבון את אורך הכותרת RLC ו-PDCP ב-MBR ו-GBR. פרמטר נוסף ב-TBFQ הוא
תעריף הגעת מנות. פרמטר זה מחושב בתוך מתזמן ושווה לעבר
תפוקה ממוצעת המשמשת בתזמון PF.

תכונות שימושיות רבות של מודל LTE-EPC יתוארו להלן
תת סעיפים. ובכל זאת, ישנן תכונות רבות שאינן מוזכרות במפורש ב
עיצוב או תיעוד משתמש, אך מתועדים בבירור באמצעות התכונה ns-3
מערכת. אתה יכול בקלות להדפיס רשימה של התכונות של אובייקט נתון יחד עם
התיאור שלהם וערך ברירת המחדל עוברים --PrintAttributes= לתוכנית סימולציה,
ככה:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteHelper"

אתה יכול לנסות גם עם אובייקטי LTE ו-EPC אחרים, כמו זה:

./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbNetDevice"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbMac"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteEnbPhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::LteUePhy"
./waf --run lena-simple --command-template="%s --PrintAttributes=ns3::PointToPointEpcHelper"

הדמיה תְפוּקָה
דגם ns-3 LTE תומך כעת בפלט לקובץ ברמת PHY, MAC, RLC ו-PDCP
מדדי ביצועים מרכזיים (KPI). אתה יכול להפעיל אותו בדרך הבאה:

Ptr lteHelper = CreateObject ();

// הגדר את כל תרחיש הסימולציה כאן...

lteHelper->EnablePhyTraces ();
lteHelper->EnableMacTraces ();
lteHelper->EnableRlcTraces ();
lteHelper->EnablePdcpTraces ();

סימולטור::Run ();

RLC ו-PDCP KPI מחושבים על פני מרווח זמן ומאוחסנים בקבצי ASCII, שניים עבור
RLC KPIs ושניים עבור PDCP KPIs, בכל מקרה אחד עבור uplink ואחד עבור downlink. הזמן
ניתן לשלוט על משך המרווח באמצעות התכונה
ns3::RadioBearerStatsCalculator::EpochDuration.

העמודות של קבצי RLC KPI הן הבאות (זהה עבור קישור למעלה ולמטה):

1. זמן התחלה של מרווח מדידה בשניות מתחילת הסימולציה

2. זמן סיום מרווח המדידה בשניות מאז תחילת הסימולציה

3. מזהה תא

4. מזהה UE ייחודי (IMSI)

5. מזהה UE ספציפי לתא (RNTI)

6. מזהה ערוץ לוגי

7. מספר RLC PDUs משודרים

8. סך בתים ששודרו.

9. מספר RLC PDUs שהתקבלו

10. סך הבתים שהתקבלו

11. השהיה ממוצעת של RLC PDU בשניות

12. סטיית תקן של השהיה RLC PDU

13. ערך מינימלי של השהיה RLC PDU

14. ערך מקסימלי של השהיית RLC PDU

15. גודל RLC PDU ממוצע, בבתים

16. סטיית תקן של גודל PDU RLC

17. גודל RLC PDU מינימלי

18. גודל RLC PDU מקסימלי

באופן דומה, העמודות של קבצי ה-PDCP KPI הן הבאות (שוב, זהה ל-uplink
ו-downlink):

1. זמן התחלה של מרווח מדידה בשניות מתחילת הסימולציה

2. זמן סיום מרווח המדידה בשניות מאז תחילת הסימולציה

3. מזהה תא

4. מזהה UE ייחודי (IMSI)

5. מזהה UE ספציפי לתא (RNTI)

6. מזהה ערוץ לוגי

7. מספר PDCP PDUs משודרים

8. סך בתים ששודרו.

9. מספר PDCP PDUs שהתקבלו

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 מקסימלי

KPIs של MAC הם בעצם עקבות של הקצאת המשאבים שעליה דיווח המתזמן
ההתחלה של כל תת מסגרת. הם מאוחסנים בקבצי ASCII. עבור KPI של MAC עם קישור למטה
הפורמט הוא הבא:

1. זמן סימולציה בשניות שבו ההקצאה מסומנת על ידי המתזמן

2. מזהה תא

3. מזהה UE ייחודי (IMSI)

4. מספר מסגרת

5. מספר תת-מסגרת

6. מזהה UE ספציפי לתא (RNTI)

7. MCS של TB 1

8. גודל TB 1

9. MCS של TB 2 (0 אם לא קיים)

10. גודל של TB 2 (0 אם לא קיים)

בעוד עבור KPIs של MAC Uplink הפורמט הוא:

1. זמן סימולציה בשניות שבו ההקצאה מסומנת על ידי המתזמן

2. מזהה תא

3. מזהה UE ייחודי (IMSI)

4. מספר מסגרת

5. מספר תת-מסגרת

6. מזהה UE ספציפי לתא (RNTI)

7. MCS של שחפת

8. גודל שחפת

ניתן להתאים אישית את שמות הקבצים המשמשים עבור פלט MAC KPI באמצעות תכונות ns-3
ns3::MacStatsCalculator::DlOutputFilename ו ns3::MacStatsCalculator::UlOutputFilename.

PHY KPIs מופצים בשבעה קבצים שונים, הניתנים להגדרה באמצעות התכונות

1. ns3::PhyStatsCalculator::DlRsrpSinrשם הקובץ

2. ns3::PhyStatsCalculator::UeSinrשם קובץ

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. ממוצע ליניארי על כל ה-RBs של ה-Downlink SINR ביחידות ליניאריות

התוכן בקובץ UE SINR הוא:

1. זמן סימולציה בשניות שבו ההקצאה מסומנת על ידי המתזמן

2. מזהה תא

3. מזהה UE ייחודי (IMSI)

4. Uplink SINR ביחידות ליניאריות עבור ה-UE

בשם קובץ ההפרעות התוכן הוא:

1. זמן סימולציה בשניות שבו ההקצאה מסומנת על ידי המתזמן

2. מזהה תא

3. רשימת ערכי הפרעות לכל RB

בקבצי שידור UL ו-DL הפרמטרים הכלולים הם:

1. זמן סימולציה באלפיות שניות

2. מזהה תא

3. מזהה UE ייחודי (IMSI)

4. RNTI

5. שכבת שידור

6. MCS

7. גודל השחפת

8. גרסת יתירות

9. דגל חיווי נתונים חדש

ולבסוף, בקבצי קליטה של ​​UL ו-DL הפרמטרים הכלולים הם:

1. זמן סימולציה באלפיות שניות

2. מזהה תא

3. מזהה UE ייחודי (IMSI)

4. RNTI

5. מצב שידור

6. שכבת שידור

7. MCS

8. גודל השחפת

9. גרסת יתירות

10. דגל חיווי נתונים חדש

11. תקינות בקליטה של ​​השחפת

דוֹהֶה עקבות נוֹהָג
בסעיף זה נתאר כיצד להשתמש בעקבות דהייה בתוך סימולציות LTE.

דוֹהֶה עקבות דור
ניתן ליצור עקבות דהייה באמצעות סקריפט מטלב ייעודי המסופק עם
הקוד (/lte/model/fading-traces/fading-trace-generator.m). הסקריפט הזה כבר כולל
תצורות הברזים האופייניות לשלושה תרחישי 3GPP (כלומר, הולכי רגל, כלי רכב ו
עירוני כהגדרתו בנספח B.2 של [TS36104]); עם זאת משתמשים יכולים גם להציג את שלהם
תצורות ספציפיות. רשימת הפרמטרים הניתנים להגדרה מסופקת ב-
הבא:

· fc : התדר בשימוש (הוא משפיע על חישוב מהירות הדופלר).

· v_km_h : מהירות המשתמשים

· traceDuration : משך האורך הכולל של המעקב בשניות.

· numRBs : המספר של בלוק המשאבים שיש להעריך.

· תג : התג שיש להחיל על הקובץ שנוצר.

הקובץ שנוצר מכיל ערכים אמיתיים בפורמט ASCII המאורגנים בצורה מטריצה:
כל שורה מתאימה ל-RB אחר, וכל עמודה מתאימה ל-RB אחר
דגימת עקבות דהייה זמנית.

יש לציין שמודול ns-3 LTE מסוגל לעבוד עם כל קובץ עקבות דוהה
התואם את פורמט ASCII המתואר לעיל. לפיכך, כלים חיצוניים אחרים יכולים להיות
משמש ליצירת עקבות דהייה מותאמים אישית, כמו למשל סימולטורים אחרים או
מכשירים ניסיוניים.

דוֹהֶה עקבות נוֹהָג
בעת שימוש בעקיבה דהייה, ישנה חשיבות עליונה לציון נכון של העקיבה
פרמטרים בסימולציה, כך שמודל הדהייה יוכל לטעון ולהשתמש בו בצורה נכונה. ה
הפרמטרים שיש להגדיר הם:

· TraceFilename : שם המעקב שיש לטעון (נתיב מוחלט, או נתיב יחסי
לכתוב את הנתיב ממנו מופעלת תוכנית הסימולציה);

· TraceLength : משך המעקב בשניות;

· SamplesNum : מספר הדגימות;

· גודל חלון : גודל חלון הדגימה הדוהה בשניות;

חשוב להדגיש שמרווח הדגימה של עקבות הדהייה חייב להיות 1 ms
או יותר, ובמקרה האחרון היא צריכה להיות כפולה שלמה של 1 ms כדי להיות
מעובד כהלכה על ידי מודול הדהייה.

תצורת ברירת המחדל של סקריפט matlab מספקת עקבות באורך 10 שניות, עשויה
10,000 דגימות (כלומר, דגימה אחת לכל TTI=1ms) ובשימוש עם גודל חלונות של 1 שניות
אמפליטודה. אלו הם גם ערכי ברירת המחדל של הפרמטרים לעיל בשימוש ב-
מַדמֶה; לכן ניתן להימנע מהתקיעה שלהם במקרה שהעקבות הדוהות מכבדות אותם.

על מנת להפעיל את מודול הדהייה (שאינו פעיל כברירת מחדל) הקוד הבא
צריך להיכלל בתוכנית הסימולציה:

Ptr lteHelper = CreateObject ();
lteHelper->SetFadingModel("ns3::TraceFadingLossModel");

ולהגדרת הפרמטרים:

lteHelper->SetFadingModelAttribute ("TraceFilename", StringValue ("src/lte/model/fading-traces/fading_trace_EPA_3kmph.fad"));
lteHelper->SetFadingModelAttribute ("TraceLength", TimeValue (שניות (10.0)));
lteHelper->SetFadingModelAttribute ("SamplesNum", UintegerValue (10000));
lteHelper->SetFadingModelAttribute ("גודל חלון", ערך זמן (שניות (0.5)));
lteHelper->SetFadingModelAttribute ("RbNum", UintegerValue (100));

יש לציין כי, TraceFilename אין ערך ברירת מחדל, ולכן הוא חייב
להיות מוגדר תמיד במפורש.

הסימולטור מספק באופן מקורי שלוש עקבות דהייה שנוצרו על פי
תצורות המוגדרות בנספח B.2 של [TS36104]. עקבות אלה זמינים ב
תיקייה src/lte/model/fading-traces/). קטע מתוך עקבות אלה מיוצג ב-
הנתונים הבאים.
[תמונה: עקבות דהייה 3 קמ"ש] [תמונה] קטע של עקבות הדהייה הכלולה ב-
סימולטור לתרחיש הולכי רגל (מהירות של 3 קמ"ש)..UNINDENT
[תמונה: עקבות דהייה 60 קמ"ש] [תמונה] קטע של עקבות הדהייה הכלולה ב-
סימולטור לתרחיש של רכב (מהירות של 60 קמ"ש)..UNINDENT
[תמונה: עקבות דהייה 3 קמ"ש] [תמונה] קטע של עקבות הדהייה הכלולה ב-
סימולטור לתרחיש עירוני (מהירות של 3 קמ"ש)..UNINDENT

ניעות מספר סימוכין עם בניינים
כעת נסביר באמצעות דוגמאות כיצד להשתמש במודל הבניינים (במיוחד, ה
MobilityBuildingInfo ו BuildingPropagationModel שיעורים) בסימולציה ns-3
תוכנית להגדרת תרחיש סימולציית LTE הכולל מבנים וצמתים פנימיים.

1. קבצי כותרות שיש לכלול:

#לִכלוֹל
#לִכלוֹל
#לִכלוֹל

2. בחירת דגם Pathloss:

Ptr 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. בחירת דגם ניידות:

MobilityHelper ניידות;
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");

יש לציין שניתן להשתמש בכל דגם ניידות.

2. יצירת בניין:

כפול x_min = 0.0;
כפול x_max = 10.0;
כפול y_min = 0.0;
כפול y_max = 20.0;
כפול z_min = 0.0;
כפול z_max = 10.0;
Ptr b = CreateObject ();
b->SetBoundaries (תיבה (x_min, x_max, y_min, y_max, z_min, z_max));
b->SetBuildingType (Building::Residential);
b->SetExtWallsType (Building::ConcreteWithWindows);
b->SetNFloors (3);
b->SetNRroomsX (3);
b->SetNRroomsY (2);

זה ייצור בניין מגורים עם בסיס של 10 על 20 מטר וגובה של
10 מטר שקירותיהם החיצוניים מבטון עם חלונות; בבניין יש שלושה
קומות ויש לו רשת פנימית של 3 על 2 חדרים בגודל שווה.

3. יצירה ומיצוב של צומת:

ueNodes.Create (2);
mobility.Install (ueNodes);
BuildingsHelper::Install (ueNodes);
NetDeviceContainer ueDevs;
ueDevs = lteHelper->InstallUeDevice (ueNodes);
Ptr mm0 = enbNodes.Get (0)->GetObject ();
Ptr mm1 = enbNodes.Get (1)->GetObject ();
mm0->SetPosition (וקטור (5.0, 5.0, 1.5));
mm1->SetPosition (וקטור (30.0, 40.0, 1.5));

4. סיים את תצורת מודל הבניין והניידות:

BuildingsHelper::MakeMobilityModelConsistent ();

ראה את התיעוד של בניינים מודול למידע מפורט יותר.

PHY שְׁגִיאָה מספר סימוכין
מודל השגיאה הפיזית מורכב ממודל שגיאת הנתונים ושגיאת בקרת ההורדה
מודל, שניהם פעילים כברירת מחדל. אפשר לבטל אותם עם ה-ns3
מערכת תכונות, בפירוט:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

MIMO מספר סימוכין
האם תת-סעיף זה נמחיש כיצד להגדיר את פרמטרי MIMO. LTE מגדיר 7 סוגים
של מצבי שידור:

· מצב שידור 1: SISO.

· מצב שידור 2: MIMO Tx Diversity.

· מצב שידור 3: MIMO Spatial Multiplexity Open Loop.

· מצב שידור 4: MIMO Spatial Multiplexity Closed Loop.

· מצב שידור 5: MIMO Multi-User.

· מצב שידור 6: קידוד שכבה בודדת בלולאה קרובה יותר.

· מצב שידור 7: יציאת אנטנה אחת 5.

לפי המודל שיושם, הסימולטור כולל את שלושת מצבי השידור הראשונים
סוגים. ברירת המחדל היא מצב שידור 1 (SISO). על מנת לשנות את ברירת המחדל
מצב שידור לשימוש, התכונה DefaultTransmissionMode של LteEnbRrc יכול
לשמש, כפי שמוצג להלן:

Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (0)); // SISO
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (1)); // גיוון MIMO Tx (שכבה אחת)
Config::SetDefault ("ns3::LteEnbRrc::DefaultTransmissionMode", UintegerValue (2)); // ריבוי מרחבי MIMO (2 שכבות)

לשינוי מצב השידור של משתמש מסוים במהלך הסימולציה ספציפית
ממשק הוטמע בשני המתמנים הסטנדרטיים:

void TransmissionModeConfigurationUpdate (uint16_t rnti, uint8_t txMode);

ניתן להשתמש בשיטה זו הן לפיתוח מנוע החלטה במצב הילוכים (כלומר, עבור
אופטימיזציה של מצב השידור בהתאם למצב הערוץ ו/או של המשתמש
דרישות) ולמעבר ידני מסקריפט סימולציה. במקרה האחרון, ה
ניתן לבצע מיתוג כפי שמוצג בקטע הבא:

Ptr lteEnbDev = enbDevs.Get (0)->GetObject ();
PointerValue ptrval;
enbNetDev->GetAttribute ("FfMacScheduler", ptrval);
Ptr rrsched = ptrval.Get ();
Simulator::Schedule (שניות (0.2), &RrFfMacScheduler::TransmissionModeConfigurationUpdate, rrsched, rnti, 1);

לבסוף, ניתן להגדיר מחדש את המודל המיושם לפי דגמי MIMO שונים על ידי
עדכון ערכי הרווח (האילוצים היחידים הם שהרווח צריך להיות קבוע במהלך
זמן ריצה של סימולציה ומשותף לשכבות). הרווח של כל מצב שידור יכול להיות
השתנה בהתאם למערכת התכונות הסטנדרטית ns3, כאשר התכונות הן:
TxMode1Gain, TxMode2Gain, TxMode3Gain, TxMode4Gain, TxMode5Gain, TxMode6Gain ו
TxMode7Gain. כברירת מחדל בלבד TxMode1Gain, TxMode2Gain ו TxMode3Gain יש משמעות
ערך, שהם אלה שנגזרו מ-_[CatreuxMIMO] (כלומר, 0.0, 4.2 ו-2.8 בהתאמה
dB).

השתמש of דגם אנטנה
כעת אנו מראים כיצד לשייך דגם אנטנה מסוים להתקן eNB על מנת ליצור דגם א
מגזר של מאקרו eNB. למטרה זו, נוח להשתמש ב- CosineAntennaModel
מסופק על ידי מודול האנטנה ns-3. ההגדרה של ה-eNB צריכה להיעשות באמצעות
LteHelper מופע ממש לפני יצירת ה EnbNetDevice, כפי שמוצג ב
הבא:

lteHelper->SetEnbAntennaModelType ("ns3::CosineAntennaModel");
lteHelper->SetEnbAntennaModelAttribute ("כיוון", DoubleValue (0));
lteHelper->SetEnbAntennaModelAttribute ("רוחב קרן", DoubleValue (60);
lteHelper->SetEnbAntennaModelAttribute ("MaxGain", DoubleValue (0.0));

הקוד לעיל יפיק דגם אנטנה עם רוחב אלומה של 60 מעלות המצביע לאורך
ציר X. הכיוון נמדד במעלות מציר X, למשל, כיוון
של 90 יצביע לאורך ציר Y, ​​וכיוון של -90 יצביע לשלילה
כיוון לאורך ציר Y. רוחב האלומה הוא רוחב האלומה -3 dB, למשל, עבור 60 מעלות
רוחב האלומה רווח האנטנה בזווית של מ'
30 מעלות מכיוון הכיוון הוא -3 dB.

כדי ליצור אתר רב-מגזרי, עליך ליצור צמתים שונים של ns-3 הממוקמים באותו מקום
מיקום, ולהגדיר נפרד EnbNetDevice עם כיווני אנטנה שונים להיות
מותקן בכל צומת.

רדיו סביבה מפות
על ידי שימוש בכיתה RadioEnvironmentMapHelper אפשר להוציא לקובץ רדיו
מפת הסביבה (REM), כלומר, רשת דו-ממדית אחידה של ערכים המייצגים את
יחס אות לרעש ב-downlink ביחס ל-eNB שיש לו את החזק ביותר
אות בכל נקודה. אפשר לציין אם יש ליצור REM עבור נתונים או
ערוץ בקרה. כמו כן, המשתמש יכול להגדיר את ה-RbId, שעבורו יווצר REM. ברירת מחדל RbId
הוא -1, מה שאומר ש-REM יופק עם יחס אות לרעש ממוצע מכל
RBs.

כדי לעשות זאת, אתה רק צריך להוסיף את הקוד הבא לתוכנית הסימולציה שלך לקראת
סוף, ממש לפני הקריאה לסימולטור::הפעלה ():

Ptr remHelper = CreateObject ();
remHelper->SetAttribute ("ChannelPath", StringValue ("/ChannelList/0"));
remHelper->SetAttribute ("OutputFile", StringValue ("rem.out"));
remHelper->SetAttribute ("XMin", DoubleValue (-400.0));
remHelper->SetAttribute ("XMax", DoubleValue (400.0));
remHelper->SetAttribute ("XRes", UintegerValue (100));
remHelper->SetAttribute ("YMin", DoubleValue (-300.0));
remHelper->SetAttribute ("YMax", DoubleValue (300.0));
remHelper->SetAttribute ("YRes", UintegerValue (75));
remHelper->SetAttribute ("Z", DoubleValue (0.0));
remHelper->SetAttribute ("UseDataChannel", BooleanValue (true));
remHelper->SetAttribute ("RbId", IntegerValue (10));
remHelper->התקן ();

על ידי הגדרת התכונות של RadioEnvironmentMapHelper חפץ כפי שמוצג לעיל, אתה
יכול לכוון את הפרמטרים של ה-REM שייווצר. שימו לב שכל אחד
RadioEnvironmentMapHelper מופע יכול ליצור רק REM אחד; אם אתה רוצה לייצר יותר
REMs, עליך ליצור מופע אחד נפרד עבור כל REM.

שימו לב שדור ה-REM תובעני מאוד, במיוחד:

· צריכת הזיכרון בזמן הריצה היא בערך 5KB לפיקסל. לדוגמה, REM
עם רזולוציה של 500x500 יצטרך כ-1.25 ג'יגה-בייט של זיכרון, ורזולוציה של
1000x1000 יצטרך בערך 5 GB (יותר מדי למחשב רגיל בזמן זה
כְּתִיבָה). כדי להתגבר על בעיה זו, ה-REM נוצר בשלבים עוקבים, עם כל אחד
שלב הערכת לכל היותר מספר פיקסלים שנקבע לפי הערך של ה-
תכונה RadioEnvironmentMapHelper::MaxPointsPerIteration.

· אם אתה יוצר REM בתחילת סימולציה, זה יאט את
ביצוע שאר הסימולציה. אם אתה רוצה ליצור REM עבור תוכנית
וגם להשתמש באותה תוכנה כדי לקבל תוצאת סימולציה, מומלץ להוסיף א
מתג שורת פקודה המאפשר ליצור את ה-REM או להפעיל את השלם
סימולציה. לשם כך, שימו לב שיש תכונה
RadioEnvironmentMapHelper::StopWhenDone (ברירת מחדל: נכון) שיכריח את
סימולציה שתעצור מיד לאחר יצירת ה-REM.

ה-REM מאוחסן בקובץ ASCII בפורמט הבא:

· עמודה 1 היא קואורדינטת x

· עמודה 2 היא קואורדינטת ה-y

· עמודה 3 היא קואורדינטת z

· עמודה 4 היא SINR ביחידות ליניאריות

סקריפט גנופלוט מינימלי המאפשר לך לשרטט את ה-REM ניתן להלן:

הגדר מפת תצוגה;
הגדר xlabel "X"
הגדר תווית "Y"
הגדר את התווית "SINR (dB)"
מפתח בטל
עלילה "rem.out" באמצעות ($1):($2):(10*log10($4)) עם תמונה

כדוגמה, הנה ה-REM שניתן להשיג בתוכנית לדוגמה
lena-dual-stripe, המציגה מאקרו תא LTE תלת מגזרים בפריסה משותפת עם ערוץ
כמה תאים למגורים נפרסו באקראי בשני בלוקים של דירות.
[תמונה] REM שהתקבל מהדוגמה של lena-dual-stripe.UNINDENT

שים לב שהתוכנית למשל lena-dual-stripe מייצרת גם פלט תואם gnuplot
קבצים המכילים מידע על מיקומי הצמתי UE ו-eNB וכן של
הבניינים, בהתאמה בתיקים ues.txt, enbs.txt ו buildings.txt. אלה יכולים
להיכלל בקלות בעת שימוש ב-gnuplot. לדוגמה, בהנחה שסקריפט הגנופלוט שלך
(למשל, סקריפט ה-gnuplot המינימלי שתואר לעיל) נשמר בקובץ בשם
my_plot_script, הפעלת הפקודה הבאה תשרטט את המיקום של UEs, eNBs ו
בניינים על גבי ה-REM:

gnuplot -p enbs.txt ues.txt buildings.txt my_plot_script

AMC מספר סימוכין ו CQI תחשיב
הסימולטור מספק שתי תוכניות אפשריות עבור מה שנוגע לבחירת ה-MCS
ובהתאמה הדור של ה-CQIs. הראשון מבוסס על מודול GSoC
[Piro2011] ועובד לפי בסיס RB. ניתן להפעיל את המודל הזה עם התכונה ns3
מערכת, כפי שמוצגת להלן:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::PiroEW2010));

אמנם, ניתן לשלוט בפתרון המבוסס על מודל השגיאה הפיזי באמצעות:

Config::SetDefault ("ns3::LteAmc::AmcModel", EnumValue (LteAmc::MiErrorModel));

לבסוף, היעילות הנדרשת של PiroEW2010 ניתן לכוון מודול AMC הודות ל
בר תכונה (), למשל:

Config::SetDefault ("ns3::LteAmc::Ber", DoubleValue (0.00005));

התפתח מנה ליבה (EPC)
כעת נסביר כיצד לכתוב תוכנית סימולציה המאפשרת לדמות את ה-EPC פנימה
בנוסף לרשת הגישה לרדיו LTE. השימוש ב-EPC מאפשר להשתמש ברשת IPv4
עם מכשירי LTE. במילים אחרות, תוכל להשתמש ביישומי ns-3 הרגילים
ושקעים מעל IPv4 על LTE, וגם לחיבור רשת LTE לכל IPv4 אחר
רשת שאולי יש לך בסימולציה שלך.

קודם כל, בנוסף ל LteHelper שכבר הצגנו בסיסי הדמיה
התוכנית, עליך להשתמש בתוספת נוספת EpcHelper כיתה, שתדאג ליצור
ישויות EPC וטופולוגיית הרשת. שים לב שאתה לא יכול להשתמש EpcHelper ישירות, כמו שזה
הוא מחלקת בסיס מופשטת; במקום זאת, עליך להשתמש באחת מכיתות הילד שלה, אשר
לספק יישומי טופולוגיה שונים של EPC. בדוגמה זו נשקול
PointToPointEpcHelper, המיישמת EPC המבוססת על קישורים מנקודה לנקודה. להשתמש בזה,
תחילה עליך להכניס את הקוד הזה לתוכנית הסימולציה שלך:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreateObject ();

לאחר מכן, עליך לומר למסייע LTE שייעשה שימוש ב-EPC:

lteHelper->SetEpcHelper (epcHelper);

השלב שלעיל הכרחי כדי שהמסייע LTE יפעיל את ה-EPC המתאים
תצורה בהתכתבות עם תצורה חשובה כלשהי, כגון כאשר eNB חדש
או UE מתווסף לסימולציה, או נוצר נושא EPS. עוזר ה-EPC יעשה זאת
דואג אוטומטית להגדרה הדרושה, כגון יצירת קישור S1 ונושא S1
להכין. כל זה ייעשה ללא התערבות המשתמש.

יִעוּד lteHelper->SetEpcHelper (epcHelper) מאפשר שימוש ב-EPC, ויש לו את הצד
השפעה כי כל חדש LteEnbRrc אשר נוצר יהיה EpsBearerToRlcMapping
התכונה מוגדרת ל RLC_UM_ALWAYS במקום RLC_SM_ALWAYS אם האחרון היה ברירת המחדל;
אחרת, התכונה לא תשתנה (למשל, אם שינית את ברירת המחדל ל
RLC_AM_ALWAYS, זה לא ייגע).

יצוין כי ה EpcHelper גם יצור אוטומטית את הצומת PGW ו
הגדר אותו כך שיוכל לטפל כראוי בתעבורה מ/אל רשת הגישה לרדיו LTE.
ובכל זאת, עליך להוסיף קוד מפורש כדי לחבר את ה-PGW לרשתות IPv4 אחרות (למשל,
האינטרנט). הנה דוגמה פשוטה מאוד כיצד לחבר אליו מארח מרוחק יחיד
ה-PGW באמצעות קישור מנקודה לנקודה:

Ptr pgw = epcHelper->GetPgwNode ();

// צור RemoteHost יחיד
NodeContainer remoteHostContainer;
remoteHostContainer.Create (1);
Ptr remoteHost = remoteHostContainer.Get (0);
InternetStackHelper אינטרנט;
internet.Install (remoteHostContainer);

// צור את האינטרנט
PointToPointHelper p2ph;
p2ph.SetDeviceAttribute ("קצב נתונים", DataRateValue (קצב נתונים ("100Gb/s")));
p2ph.SetDeviceAttribute ("Mtu", UintegerValue (1500));
p2ph.SetChannelAttribute ("עיכוב", ערך זמן (שניות (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 הוא localhost, 1 הוא התקן p2p
Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);

חשוב לציין מסלולים כדי שהמארח המרוחק יוכל להגיע ל-LTE UEs. דרך אחת של
לעשות זאת על ידי ניצול העובדה שה PointToPointEpcHelper כברירת מחדל יקצה
ל-LTE UEs כתובת IP ברשת 7.0.0.0. עם זה בחשבון, מספיק לעשות:

Ipv4StaticRoutingHelper ipv4RoutingHelper;
Ptr remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ());
remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address ("7.0.0.0"), Ipv4Mask ("255.0.0.0"), 1);

כעת, עליך להמשיך וליצור LTE eNBs ו-UEs כפי שהוסבר בסעיפים הקודמים.
אתה כמובן יכול להגדיר היבטי LTE אחרים כמו אובדן נתיב ודגמי דהייה. ימין
לאחר שיצרת את ה-UEs, עליך להגדיר אותם גם לרשת IP. זה גמור
כדלהלן. אנו מניחים שיש לך מיכל לצמתי UE ו-eNodeB כמו זה:

NodeContainer ueNodes;
NodeContainer enbNodes;

כדי להגדיר סימולציה של LTE בלבד, בדרך כלל תעשה משהו כזה:

NetDeviceContainer ueLteDevs = lteHelper->InstallUeDevice (ueNodes);
lteHelper-> Attach (ueLteDevs, enbLteDevs.Get (0));

כדי להגדיר את UEs עבור רשת IP, אתה רק צריך בנוסף לעשות לייק
זֶה:

// אנו מתקינים את ערימת ה-IP על ה-UEs
InternetStackHelper אינטרנט;
internet.Install (ueNodes);

// הקצה כתובת IP ל-UEs
עבור (uint32_t u = 0; u < ueNodes.GetN (); ++u)
{
Ptr ue = ueNodes.Get (u);
Ptr ueLteDevice = ueLteDevs.Get (u);
Ipv4InterfaceContainer ueIpIface = epcHelper->AssignUeIpv4Address (NetDeviceContainer (ueLteDevice));
// הגדר את שער ברירת המחדל עבור ה-UE
Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ue->GetObject ());
ueStaticRouting->SetDefaultRoute (epcHelper->GetUeDefaultGatewayAddress (), 1);
}

ההפעלה של נושאים נעשית בצורה מעט שונה ביחס למה שנעשה
עבור הדמיית LTE בלבד. ראשית, אין להשתמש בשיטה ActivateDataRadioBearer
כאשר נעשה שימוש ב-EPC. שנית, כאשר נעשה שימוש ב-EPC, יופעל נושא ה-EPS המוגדר כברירת מחדל
אוטומטית כאשר אתה מתקשר ל-LteHelper::Attach (). שלישית, אם אתה רוצה להגדיר ייעודי
EPS bearer, אתה יכול לעשות זאת באמצעות השיטה LteHelper::ActivateDedicatedEpsBearer (). זֶה
השיטה לוקחת כפרמטר את תבנית זרימת התנועה (TFT), שהיא מבנה זה
מזהה את סוג התעבורה שתמוף לנושא ה-EPS הייעודי. הנה א
דוגמה כיצד להגדיר נושא ייעודי עבור יישום ב-UE המתקשר
נמל 1234:

Ptr tft = צור ();
EpcTft::PacketFilter pf;
pf.localPortStart = 1234;
pf.localPortEnd = 1234;
tft->הוסף (pf);
lteHelper->ActivateDedicatedEpsBearer (ueLteDevs, EpsBearer (EpsBearer::NGBR_VIDEO_TCP_DEFAULT), tft);

אתה כמובן יכול להשתמש בתצורות EpsBearer ו-EpcTft מותאמות אישית, אנא עיין ב-
תיעוד דוקסגן כיצד לעשות זאת.

לבסוף, אתה יכול להתקין יישומים על צמתי LTE UE המתקשרים עם השלט
יישומים דרך האינטרנט. זה נעשה בעקבות נהלי ns-3 הרגילים.
בעקבות הדוגמה הפשוטה שלנו עם מארח מרוחק יחיד, הנה כיצד להגדיר קישור למטה
תקשורת, עם יישום UdpClient במארח המרוחק, ו-PacketSink ב-
LTE UE (באמצעות אותם שמות משתנים של קטעי הקוד הקודמים)

uint16_t dlPort = 1234;
PacketSinkHelper packetSinkHelper ("ns3::UdpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), dlPort));
ApplicationContainer serverApps = packetSinkHelper.Install (ue);
serverApps.Start (שניות (0.01));
לקוח UdpClientHelper (ueIpIface.GetAddress (0), dlPort);
ApplicationContainer clientApps = client.Install (remoteHost);
clientApps.Start (שניות (0.01));

זה הכל! כעת תוכל להתחיל את הסימולציה שלך כרגיל:

סימולטור::עצור (שניות (10.0));
סימולטור::Run ();

שימוש מה היא EPC עם אמולציה מצב
בסעיף הקודם השתמשנו בקישורי PointToPoint לחיבור בין ה-eNBs ו
ה-SGW (ממשק S1-U) ובין eNBs (ממשקי X2-U ו-X2-C). מודול LTE
תומך בשימוש בקישורים מדומים במקום קישורי PointToPoint. זה מושג על ידי פשוט
מחליף את היצירה של LteHelper ו EpcHelper עם הקוד הבא:

Ptr lteHelper = CreateObject ();
Ptr epcHelper = CreateObject ();
lteHelper->SetEpcHelper (epcHelper);
epcHelper->אתחול ();

התכונות ns3::EmuEpcHelper::sgwDeviceName ו ns3::EmuEpcHelper::enbDeviceName יש לו
משמש להגדרת שם המכשירים המשמשים להובלת ה-S1-U, X2-U ו-X2-C
ממשקים ב-SGW וב-eNB, בהתאמה. כעת נראה כיצד זה נעשה ב-an
דוגמה שבה אנו מבצעים את התוכנית לדוגמה lena-simple-epc-emu באמצעות שני וירטואליים
ממשקי Ethernet.

קודם כל אנחנו בונים את ns-3 בצורה מתאימה:

# להגדיר
./waf configure --enable-sudo --enable-modules=lte,fd-net-device --enable-examples

# בנייה
./ואף

לאחר מכן אנו מגדירים שני ממשקי Ethernet וירטואליים, ומתחילים wireshark כדי להסתכל על התעבורה
עובר:

# הערה: אתה צריך להיות שורש

# צור שני התקני וות' מזווגים
קישור ip הוסף שם veth0 סוג veth שם עמית veth1
הצגת קישור ל- ip

# אפשר מצב מופקר
קישור ip הגדר veth0 promisc
קישור ip הגדר veth1 promisc

# העלה ממשקים
קישור ip הגדר veth0 למעלה
קישור ip הגדר veth1 למעלה

# התחל wireshark ולכד ב-veth0
wireshark &

כעת נוכל להפעיל את התוכנית לדוגמה עם השעון המדומה:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1"

באמצעות wireshark, אתה אמור לראות תחילה את רזולוציית ARP, ולאחר מכן כמה מנות GTP החליפו את שתיהן
ב-uplink וב-downlink.

הגדרת ברירת המחדל של התוכנית לדוגמה היא 1 eNB ו-1UE. אתה יכול לשנות זאת באמצעות
פרמטרים של שורת הפקודה, למשל:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --nEnbs=2 --nUesPerEnb =2"

כדי לקבל רשימה של הפרמטרים הזמינים:

./waf --הפעל lena-simple-epc-emu --command="%s --PrintHelp"

כדי לרוץ עם שעון זמן אמת: מסתבר שבניית ברירת המחדל של ניפוי באגים איטית מדי עבור
זמן אמת. ריכוך אילוצי הזמן האמיתי עם מצב BestEffort אינו רעיון טוב:
משהו יכול להשתבש (למשל, ARP יכול להיכשל), ואם כן, לא תקבל חבילות נתונים
הַחוּצָה. אז אתה צריך חומרה הגונה ומבנה אופטימלי עם קישור סטטי
מודולים:

./waf configure -d optimized --enable-static --enable-modules=lte --enable-examples --enable-sudo

לאחר מכן הפעל את התוכנית לדוגמה כך:

./waf --run lena-simple-epc-emu --command="%s --ns3::EmuEpcHelper::sgwDeviceName=veth0 --ns3::EmuEpcHelper::enbDeviceName=veth1 --simulatorImplementationType=ns3::RealtimeSimulatorImplS --ns3::RealtimeSimulatorImpl::SynchronizationMode=HardLimit"

שימו לב להגדרת HardLimit, שתגרום לתוכנית להפסיק אם היא לא יכולה לעמוד בקצב
עם זמן אמת.

ניתן להשתמש בגישה המתוארת בסעיף זה עם כל סוג של מכשיר רשת. ל
לדוגמה, [Baldo2014] מתאר כיצד הוא שימש להפעלת רשת LTE-EPC מדומה על גבי
רשת הובלה אופטית של מנות מרובת שכבות אמיתית.

רשת התקשרות
כפי שמוצג בדוגמה הבסיסית בסעיף בסיסי הדמיה התוכנית, חיבור UE ל- an
eNodeB נעשה על ידי קריאה LteHelper::צרף פונקציה.

ישנן 2 דרכים אפשריות לחיבור רשת. השיטה הראשונה היא ה "מדריך ל" אחד,
בעוד שלשני יש יותר "אוֹטוֹמָטִי" חוש על זה. כל אחד מהם יכוסה
חלק זה.

מדריך ל התקשרות
בשיטה זו נעשה שימוש ב- LteHelper::צרף פונקציה שהוזכרה לעיל. זה היה היחיד
שיטת חיבור רשת זמינה בגרסאות קודמות של מודול LTE. זה בדרך כלל
מופעל לפני תחילת הסימולציה:

lteHelper-> Attach (ueDevs, enbDev); // צרף UE אחד או יותר ל-eNodeB יחיד

LteHelper::InstallEnbDevice ו LteHelper::InstallUeDevice כנראה שנקראו לפונקציות
לפני ההצמדה. בסימולציה התומכת ב-EPC, נדרש גם IPv4 כראוי
מותקן מראש ב-UE.

שיטה זו פשוטה מאוד, אך מחייבת אותך לדעת בדיוק לאיזה UE שייכת לאיזה
eNodeB לפני תחילת הסימולציה. זה יכול להיות קשה כאשר המיקום ההתחלתי של UE הוא
נקבע באופן אקראי על ידי תסריט הסימולציה.

אפשר לבחור את המרחק בין ה-UE ל-eNodeB כקריטריון לבחירת
תא מתאים. זה די פשוט (לפחות מנקודת המבט של הסימולטור) ו
לפעמים מעשי. אבל חשוב לציין שלפעמים מרחק לא עושה א
קריטריון אחד נכון. לדוגמה, כיווניות אנטנת eNodeB צריכה להיות
נחשב גם כן. חוץ מזה, צריך לקחת בחשבון גם את מצב הערוץ,
אשר עשוי להיות משתנה אם יש דהייה או הצללה בתוקף. בסוג כזה של
במקרים, חיבור רשת לא צריך להתבסס על מרחק בלבד.

בחיים האמיתיים, UE יעריך אוטומטית קריטריונים מסוימים ותבחר את התא הטוב ביותר
לצרף, ללא התערבות ידנית של המשתמש. ברור שזה לא המקרה ב
זֶה LteHelper::צרף פוּנקצִיָה. שיטת חיבור הרשת האחרת משתמשת ביותר "אוֹטוֹמָטִי"
גישה לחיבור רשת, כפי שיתואר בהמשך.

מכני עם סלילה אוטומטית התקשרות באמצעות להתבטל מצב תא מבחר הליך
עוצמת האות המתקבל היא הקריטריון הסטנדרטי המשמש לבחירת הטוב ביותר
תא להצמדה אליו. השימוש בקריטריון זה מיושם ב- בתחילה תא מבחר
תהליך, שניתן להפעילו על ידי קריאה לגרסה אחרת של LteHelper::צרף
פונקציה, כפי שמוצג להלן:

lteHelper-> Attach (ueDevs); // צרף UE אחד או יותר לתא החזק ביותר

ההבדל בשיטה הידנית הוא שהיעד eNodeB לא מצוין. ה
ההליך ימצא את התא הטוב ביותר עבור ה-UEs, בהתבסס על מספר קריטריונים, כולל
חוזק האות המתקבל (RSRP).

לאחר קריאת השיטה, ה-UE ישקיע זמן מה למדידת התאים השכנים,
ולאחר מכן נסה להיצמד לטוב ביותר. פרטים נוספים ניתן למצוא בסעיף
sec-initial-cell-selection של תיעוד העיצוב.

חשוב לציין ששיטה זו פועלת רק בסימולציות התומכות ב-EPC. LTE בלבד
סימולציות חייבות להיעזר בשיטת התקשרות ידנית.

סגור מנוי קְבוּצָה
מקרה שימוש מעניין בתהליך בחירת התאים הראשוני הוא הגדרת סימולציה
סביבה עם קבוצת מנויים סגורה (CSG).

לדוגמה, eNodeB מסוים, בדרך כלל גרסה קטנה יותר כמו femtocell, עשוי להיות שייך
לבעלים פרטיים (למשל משק בית או עסק), המאפשר גישה רק לכמה UEs אשר
נרשמו בעבר על ידי הבעלים. ה-eNodeB וה-UE הרשומים בסך הכל
יוצרים CSG.

ניתן לדמות את הגבלת הגישה על ידי "תיוג" של חברי ה-CSG עם אותו CSG
תְעוּדַת זֶהוּת. זה נעשה באמצעות התכונות הן ב-eNodeB והן ב-UE, למשל באמצעות ה
הבא LteHelper פונקציות you

// תווית את ה-eNodeBs הבאים עם זהות CSG של 1 והפעלת חיווי CSG
lteHelper->SetEnbDeviceAttribute ("CsgId", UintegerValue (1));
lteHelper->SetEnbDeviceAttribute ("CsgIndication", BooleanValue (true));

// תווית UE אחד או יותר עם זהות CSG של 1
lteHelper->SetUeDeviceAttribute ("CsgId", UintegerValue (1));

// התקן את eNodeBs ו-UEs
NetDeviceContainer csgEnbDevs = lteHelper->InstallEnbDevice (csgEnbNodes);
NetDeviceContainer csgUeDevs = lteHelper->InstallUeDevice (csgUeNodes);

לאחר מכן הפעל את הליך בחירת התאים הראשוני ב-UEs:

lteHelper-> Attach (csgUeDevs);

זה הכרחי מכיוון שההגבלה של CSG עובדת רק בשיטה אוטומטית של רשת
קובץ מצורף, אבל לא בשיטה הידנית.

שים לב שהגדרת חיווי ה-CSG של eNodeB כ-false (ערך ברירת המחדל).
השבת את ההגבלה, כלומר, כל UE יכול להתחבר ל-eNodeB זה.

גדר UE מידות
תצורת מדידת ה-UE הפעילה בסימולציה מוכתבת על ידי כך שנבחר
המכונה "צרכנים", כגון אלגוריתם מסירה. משתמשים יכולים להוסיף תצורה משלהם ל
פעולה, וישנן מספר דרכים לעשות זאת:

1. תצורה ישירה בישות eNodeB RRC;

2. הגדרת אלגוריתם מסירה קיים; ו

3. פיתוח אלגוריתם מסירה חדש.

סעיף זה יכסה את השיטה הראשונה בלבד. השיטה השנייה מכוסה מכני עם סלילה אוטומטית
מסירה להפעיל, ואילו השיטה השלישית מוסברת באריכות בסעיף
אלגוריתם מסירת שניות של תיעוד העיצוב.

תצורה ישירה ב-eNodeB RRC פועלת באופן הבא. המשתמש מתחיל ביצירת חדש
LteRrcSap::ReportConfigEutra מופע ולהעביר אותו ל- LteEnbRrc::AddUeMeasReportConfig
פוּנקצִיָה. הפונקציה תחזיר את measId (זהות מדידה) שהיא ייחודית
הפניה של התצורה במופע eNodeB. יש לקרוא לפונקציה זו לפני
הסימולציה מתחילה. תצורת המדידה תהיה פעילה בכל ה-UE המצורפים אליהם
ה-eNodeB לאורך כל משך הסימולציה. במהלך הסימולציה, המשתמש יכול
ללכוד את דוחות המדידה שהופקו על ידי ה-UEs על ידי האזנה לקיים
LteEnbRrc::RecvMeasurementReport מקור עקבות.

המבנה ReportConfigEutra תואם למפרט 3GPP. הגדרה של ה
ניתן למצוא את המבנה וכל שדה חבר בסעיף 6.3.5 של [TS36331].

דגימת הקוד שלהלן מגדירה מדידת RSRP של Event A1 לכל eNodeB בתוך
מכולה devs:

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;

std::vector measIdList;

NetDeviceContainer::Iterator את זה;
עבור (it = devs.Begin (); it != devs.End (); it++)
{
Ptr dev = *it;
Ptr enbDev = dev->GetObject ();
Ptr enbRrc = enbDev->GetRrc ();

uint8_t measId = enbrRrc->AddUeMeasReportConfig (config);
measIdList.push_back (measId); // זכור את measId שנוצר

enbrRrc->TraceConnect ("RecvMeasurementReport",
"הֶקשֵׁר",
MakeCallback (&RecvMeasurementReportCallback));
}

שים לב שספים מבוטאים כטווח. בדוגמה למעלה, הטווח 41 עבור RSRP
מתאים ל-100 dBm. ההמרה מפורמט הטווח ואליו נובעת מ-Section
9.1.4 ו-9.1.7 של [TS36133]. ה EutranMeasurementMapping לכיתה יש כמה סטטיים
פונקציות שניתן להשתמש בהן למטרה זו.

לפונקציית ה-callback המתאימה תהיה הגדרה דומה להלן:

לבטל את
RecvMeasurementReportCallback (std::string context,
uint64_t imsi,
uint16_t cellId,
uint16_t rnti,
LteRrcSap::MeasurementReport measReport);

שיטה זו תרשום את פונקציית ה-callback כצרכן של מדידות UE. בתוך ה
במקרה שבו יש יותר מצרכן אחד בסימולציה (למשל אלגוריתם מסירה),
המדידות המיועדות לצרכנים אחרים ייקלטו גם על ידי התקשרות חוזרת זו
פוּנקצִיָה. משתמשים עשויים להשתמש ב- measId שדה, הכלול ב-
LteRrcSap::MeasurementReport ארגומנט של פונקציית ה-callback, כדי לדעת איזו מדידה
התצורה הפעילה את הדוח.

באופן כללי, מנגנון זה מונע מצרכן אחד להתערב שלא ביודעין באחר
תצורת הדיווח של הצרכן.

שים לב שרק חלק תצורת הדיווח (כלומר LteRrcSap::ReportConfigEutra) של
פרמטר מדידות UE פתוח לצרכנים להגדיר, בעוד החלקים האחרים
נשמרים מוסתרים. המגבלה התוך-תדר היא המניע העיקרי מאחורי API זה
החלטת יישום:

· יש רק אחד, חד משמעי ומוחלט מדידה אובייקט, ולכן אין
צריך להגדיר את זה;

· מדידה זהויות נשמרים מוסתרים בגלל העובדה שיש אחד לאחד
מיפוי בין תצורת דיווח לזהות מדידה, ובכך חדש
זהות מדידה מוגדרת באופן אוטומטי כאשר תצורת דיווח חדשה קיימת
נוצר;

· כמות תצורה מוגדר במקום אחר, ראה sc-performing-measures; ו

· מדידה פערים אינם נתמכים, כי זה ישים רק עבור בין-תדרים
הגדרות;

מבוסס X2 מסירה
כפי שהוגדר על ידי 3GPP, מסירה היא הליך לשינוי תא ההגשה של UE ב
מצב מחובר. שני eNodeBs המעורבים בתהליך נקראים בדרך כלל מָקוֹר
eNodeB ו יעד eNodeB.

על מנת לאפשר ביצוע מסירה מבוססת X2 בסימולציה, ישנם שניים
דרישות שיש לעמוד בהן. ראשית, יש להפעיל EPC בסימולציה (ראה התפתח
מנה ליבה (EPC)).

שנית, יש להגדיר ממשק X2 בין שני ה-eNodeBs, וזה צריך להיות
נעשה במפורש במסגרת תוכנית הסימולציה:

lteHelper->AddX2Interface (enbNodes);

איפה enbNodes הוא NodeContainer שמכיל את שני ה-eNodeBs שביניהם ה-X2
יש להגדיר את הממשק. אם למיכל יש יותר משני eNodeBs, הפונקציה
תיצור ממשק X2 בין כל זוג eNodeBs במיכל.

לבסוף, יש להגדיר את היעד eNodeB כ"פתוח" ל-X2 HANDOVER REQUEST. כֹּל
eNodeB פתוח כברירת מחדל, כך שאין צורך בהוראה נוספת ברוב המקרים. עם זאת, משתמשים
עשוי להגדיר את ה-eNodeB ל"סגור" על ידי הגדרת התכונה הבוליאנית
LteEnbRrc::AdmitHandoverRequest ל שקר. כדוגמה, אתה יכול להפעיל את מסירת lena-x2
תוכנית והגדרת התכונה בצורה זו:

NS_LOG=EpcX2:LteEnbRrc ./waf --הרץ lena-x2-handover --command="%s --ns3::LteEnbRrc::AdmitHandoverRequest=false"

לאחר מילוי שלוש הדרישות לעיל, ניתן להפעיל את הליך המסירה
באופן ידני או אוטומטי. כל אחד מהם יוצג בתתי הסעיפים הבאים.

מדריך ל מסירה להפעיל
ניתן להפעיל אירוע מסירה "ידנית" בתוך תוכנית הסימולציה על ידי תזמון
אירוע מסירה מפורש. ה LteHelper אובייקט מספק שיטה נוחה עבור
תזמון אירוע מסירה. כדוגמה, הבה נניח זאת ueLteDevs הוא
NetDeviceContainer שמכיל את ה-UE שאמור להימסר, וזה enbLteDevs is
אַחֵר NetDeviceContainer שמכיל את המקור ואת היעד eNB. ואז, מסירה
ב-0.1 שניות ניתן לתזמן כך:

lteHelper->Handover Request (שניות (0.100),
ueLteDevs.Get (0),
enbLteDevs.Get (0),
enbLteDevs.Get (1));

שימו לב שה-UE כבר צריך להיות מחובר למקור eNB, אחרת הסימולציה
יסתיים עם הודעת שגיאה.

לדוגמא עם קוד מקור מלא, עיין ב- מסירת lena-x2 דוגמה
תכנית.

מכני עם סלילה אוטומטית מסירה להפעיל
הליך מסירה יכול להיות מופעל גם "אוטומטי" על ידי ה-eNodeB המשרת של ה-UE.
ההיגיון מאחורי הדק תלוי באלגוריתם המסירה הפעיל כרגע ב-
ישות eNodeB RRC. משתמשים יכולים לבחור ולהגדיר את אלגוריתם המסירה שישמש
בסימולציה, שתוסבר בקרוב בחלק זה. משתמשים יכולים גם לבחור
לכתוב את היישום שלהם של אלגוריתם מסירה, כמתואר בסעיף
אלגוריתם מסירת שניות של תיעוד העיצוב.

בחירת אלגוריתם מסירה מתבצעת באמצעות LteHelper חפץ ושלו
SetHandoverAlgorithmType שיטה כפי שמוצג להלן:

Ptr lteHelper = CreateObject ();
lteHelper->SetHandoverAlgorithmType ("ns3::A2A4RsrqHandoverAlgorithm");

אלגוריתם המסירה שנבחר עשוי גם לספק מספר תכונות הניתנות להגדרה, אשר
ניתן להגדיר באופן הבא:

lteHelper->SetHandoverAlgorithmAttribute ("ServingCellThreshold",
UintegerValue (30));
lteHelper->SetHandoverAlgorithmAttribute ("NeighbourCellOffset",
UintegerValue (1));

שלוש אפשרויות של אלגוריתם מסירה כלולות במודול LTE. ה A2-A4-RSRQ
אלגוריתם מסירה (שמו כ ns3::A2A4RsrqHandover אלגוריתם) היא אפשרות ברירת המחדל, ו
השימוש כבר הוצג למעלה.

אפשרות נוספת היא החזק ביותר תא אלגוריתם מסירה (שמו כ
ns3::A3RsrpHandoverAlgorithm), שניתן לבחור ולהגדיר באמצעות הקוד הבא:

lteHelper->SetHandoverAlgorithmType ("ns3::A3RsrpHandoverAlgorithm");
lteHelper->SetHandoverAlgorithmAttribute ("היסטרזיס",
DoubleValue (3.0));
lteHelper->SetHandoverAlgorithmAttribute ("TimeToTrigger",
TimeValue (מילישניות (256)));

האפשרות האחרונה היא אפשרות מיוחדת, הנקראת ללא הפעלה אלגוריתם מסירה, אשר בעצם
משבית את טריגר המסירה האוטומטית. זה שימושי למשל במקרים בהם ידני
טריגר מסירה צריך שליטה בלעדית על כל החלטות המסירה. אין לזה
תכונות הניתנות להגדרה. השימוש הוא כדלקמן:

lteHelper->SetHandoverAlgorithmType ("ns3::NoOpHandoverAlgorithm");

למידע נוסף על מדיניות ההחלטות של כל אלגוריתם מסירה והתכונות שלו,
אנא עיין בתתי הסעיפים המתאימים שלהם ב-Section sec-handover-algorithm של
תיעוד עיצוב.

לבסוף, InstallEnbDevice פונקציה של LteHelper יציג מופע אחד של
אלגוריתם מסירה נבחר עבור כל מכשיר eNodeB. במילים אחרות, הקפד לבחור
אלגוריתם המסירה הימני לפני שמסיימים אותו בשורת הקוד הבאה:

NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes);

ניתן למצוא דוגמה עם קוד מקור מלא לשימוש בטריגר מסירה אוטומטית ב-
לנה-x2-מדדי מסירה תוכנית לדוגמה.

כונון הדמיה עם מסירה
כפי שהוזכר בתיעוד העיצוב, היישום הנוכחי של מודל מסירה עשוי
לייצר התנהגות בלתי צפויה כאשר מתרחש כישלון מסירה. סעיף קטן זה יתמקד
הצעדים שצריכים להילקח בחשבון על ידי המשתמשים אם הם מתכננים להשתמש במסירת העברה שלהם
סימולציות.

הגורם העיקרי לכישלון מסירה בו אנו נטפל הוא השגיאה בשידור
הודעות איתות הקשורות למסירה במהלך ביצוע הליך מסירה. כפי ש
כפי שניתן לראות בתרשים fig-x2-based-handover-seq-דיאגרמת תיעוד העיצוב,
יש הרבה מהם והם משתמשים בממשקים ופרוטוקולים שונים. למען ה
בפשטות, אנו יכולים להניח בבטחה שממשק X2 (בין המקור eNodeB וה-
target eNodeB) וממשק S1 (בין יעד eNodeB ל-SGW/PGW) הם די
יַצִיב. לכן נמקד את תשומת הלב שלנו לפרוטוקול RRC (בין ה-UE ל-
eNodeBs) ונוהל גישה אקראית, המועברים בדרך כלל באוויר
ורגישים לפגיעה במצב הערוץ.

טיפים כלליים להפחתת שגיאות שידור הוא ל לְהַבטִיחַ גָבוֹהַ מספיק SINR רמה בכל
UE. זה יכול להיעשות על ידי תכנון נכון של טופולוגיית הרשת ממזער רשת
כיסוי חור. אם לטופולוגיה יש חור כיסוי ידוע, יש להגדיר את ה-UE
לא לצאת לאזור הזה.

גישה נוספת שיש לזכור היא לְהִמָנַע מאוחר מידי מסירות. במילים אחרות, מסירה
צריך לקרות לפני שה-SINR של ה-UE הופך נמוך מדי, אחרת ה-UE עלול להיכשל לקבל
פקודת המסירה מהמקור eNodeB. לאלגוריתמים של מסירה יש את האמצעים לשלוט
כמה מוקדם או מאוחר מתקבלת החלטת מסירה. לדוגמה, אלגוריתם מסירה A2-A4-RSRQ
ניתן להגדיר עם סף גבוה יותר כדי לגרום לו להחליט על מסירה מוקדם יותר. באופן דומה,
היסטרזיס קטן יותר ו/או זמן הפעלה קצר יותר באלגוריתם מסירת התא החזק ביותר
בדרך כלל מביא למסירות מוקדמות יותר. על מנת למצוא את הערכים הנכונים עבור אלה
פרמטרים, אחד הגורמים שיש לקחת בחשבון הוא מהירות התנועה של UE.
בדרך כלל, UE שזז מהר יותר דורש שהמסירה תתבצע מוקדם יותר. קצת מחקר
העבודה הציעו ערכים מומלצים, כמו ב-[Lee2010].

העצות שלעיל אמורות להספיק בשימושי סימולציה רגילים, אבל במקרה כמה מיוחדים
צרכים מתעוררים אז ניתן לקחת בחשבון אמצעי קיצוני. למשל, משתמשים
עשוי לשקול משבית מה היא ערוץ שגיאה מודלים. זה יבטיח שכל
הודעות איתות הקשורות למסירה ישודרו בהצלחה, ללא קשר ל
מרחק ומצב ערוץ. עם זאת, זה ישפיע גם על כל הנתונים או הבקרה האחרים
מנות שאינן קשורות למסירה, שעשויה להיות תופעת לוואי לא רצויה. אחרת, זה יכול
להיעשות באופן הבא:

Config::SetDefault ("ns3::LteSpectrumPhy::CtrlErrorModelEnabled", BooleanValue (false));
Config::SetDefault ("ns3::LteSpectrumPhy::DataErrorModelEnabled", BooleanValue (false));

על ידי שימוש בקוד לעיל, אנו משביתים את מודל השגיאה הן בערוצי הבקרה והן בערוצי הנתונים
בשני הכיוונים (Downlink ו-uplink). זה הכרחי כי קשור למסירה
הודעות איתות מועברות באמצעות ערוצים אלה. יוצא דופן הוא כאשר ה
סימולציה משתמשת בפרוטוקול RRC האידיאלי. במקרה זה, רק הליך גישה אקראית הוא
נותר לשקול. ההליך מורכב מהודעות בקרה, ולכן אנחנו צריכים רק
כדי להשבית את מודל השגיאה של ערוץ הבקרה.

מסירת צעדיו
מודל ה-RRC, בפרט ה LteEnbRrc ו LteUeRrc אובייקטים, לספק כמה שימושי
עקבות שניתן לחבר לכמה פונקציות מותאמות אישית כך שייקראו עם ההתחלה
וסיום שלב ביצוע המסירה הן בצד UE והן בצד eNB. כדוגמה, ב
תוכנית הסימולציה שלך תוכל להכריז על השיטות הבאות:

לבטל את
NotifyHandoverStartUe (std::string context,
uint64_t imsi,
uint16_t cellId,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << הקשר
<< " UE IMSI " << imsi
<< ": מחובר בעבר ל- CellId " << cellId
<< " עם RNTI " << rnti
<< ", עושה מסירה ל- CellId " << targetCellId
<< std::endl;
}

לבטל את
NotifyHandoverEndOkUe (std::string context,
uint64_t imsi,
uint16_t cellId,
uint16_t rnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << הקשר
<< " UE IMSI " << imsi
<< ": מסירה מוצלחת ל- CellId " << cellId
<< " עם RNTI " << rnti
<< std::endl;
}

לבטל את
NotifyHandoverStartEnb (std::string context,
uint64_t imsi,
uint16_t cellId,
uint16_t rnti,
uint16_t targetCellId)
{
std::cout << Simulator::Now ().GetSeconds () << " " << הקשר
<< " eNB CellId " << cellId
<< ": התחל מסירת UE עם IMSI " << imsi
<< " RNTI " << rnti
<< " to CellId " << targetCellId
<< std::endl;
}

לבטל את
NotifyHandoverEndOkEnb (std::string context,
uint64_t imsi,
uint16_t cellId,
uint16_t rnti)
{
std::cout << Simulator::Now ().GetSeconds () << " " << הקשר
<< " eNB CellId " << cellId
<< ": הושלמה מסירה של UE עם IMSI " << imsi
<< " RNTI " << rnti
<< std::endl;
}

לאחר מכן, אתה יכול לחבר את השיטות האלה למקורות העקבות המתאימים כך:

Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverStart",
MakeCallback (&NotifyHandoverStartUe));
Config::Connect ("/NodeList/*/DeviceList/*/LteEnbRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkEnb));
Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

התוכנית לדוגמה src/lte/examples/lena-x2-handover.cc ממחיש כיצד הכל למעלה
ניתן לשלב הוראות בתוכנית סימולציה. אתה יכול להפעיל את התוכנית כך:

./waf --הפעל את lena-x2-handover

והוא יוציא את ההודעות המודפסות על ידי ווי מעקב מסירה מותאמים אישית. בסדר
בנוסף לדמיין קצת מידע רישום משמעותי, אתה יכול להפעיל את התוכנית כמו
זֶה:

NS_LOG=LteEnbRrc:LteUeRrc:EpcX2 ./waf --הרץ lena-x2-handover

תדר שימוש חוזר אלגוריתמים
בסעיף זה נתאר כיצד להשתמש באלגוריתמים של שימוש חוזר בתדרים ב-eNb בתוך LTE
סימולציות. ישנן שתי דרכים אפשריות להגדרה. הגישה הראשונה היא ה
"ידני" אחד, זה דורש יותר פרמטרים להיות מוגדרים, אבל לאפשר למשתמש להגדיר FR
אלגוריתם כפי שהוא/היא צריך. הגישה השנייה היא יותר "אוטומטית". זה מאוד נוח,
כי זהה לכל אלגוריתם FR, כך שהמשתמש יכול להחליף אלגוריתם FR במהירות רבה על ידי
שינוי הסוג היחיד של אלגוריתם FR. חסרון אחד הוא שגישה "אוטומטית" משתמשת בלבד
סט מוגבל של תצורות עבור כל אלגוריתם, מה שהופך אותו לפחות גמיש, אבל הוא
מספיק לרוב המקרים.

שתי גישות אלו יתוארו יותר בסעיף המשנה הבא.

אם המשתמש אינו מגדיר אלגוריתם שימוש חוזר בתדר, ברירת מחדל (כלומר LteFrNoOpAlgorithm)
מותקן ב-eNb. הוא פועל כאילו אלגוריתם FR הושבת.

דבר אחד שצריך להזכיר הוא שרוב אלגוריתמי ה-FR המיושמים עובדים איתם
רוחב פס תא גדול או שווה מ-15 RBs. מגבלה זו נגרמת על ידי דרישה כי
יש להקצות לפחות שלושה RBs רציפים ל-UE לשידור.

מדריך ל תצורה
אלגוריתם שימוש חוזר בתדר ניתן להגדיר "ידנית" בתוך תוכנית הסימולציה על ידי
סוג ההגדרה של אלגוריתם FR וכל התכונות שלו. נכון לעכשיו, שבעה אלגוריתמי FR הם
מוטמע:

· ns3::LteFrNoOpAlgorithm

· ns3::LteFrHardAlgorithm

· ns3::LteFrStrictAlgorithm

· ns3::LteFrSoftAlgorithm

· ns3::LteFfrSoftAlgorithm

· ns3::LteFfrEnhancedAlgorithm

· ns3::LteFfrDistributedAlgorithm

בחירת אלגוריתם FR מתבצעת באמצעות LteHelper חפץ ושלו SetFfrAlgorithmType
שיטה כפי שמוצג להלן:

Ptr lteHelper = CreateObject ();
lteHelper->SetFfrAlgorithmType ("ns3::LteFrHardAlgorithm");

כל אלגוריתם FR מיושם מספק מספר תכונות הניתנות להגדרה. למשתמשים אין
לדאוג לתצורת רוחב הפס של UL ו-DL, מכיוון שזה נעשה באופן אוטומטי במהלך
תצורת התא. כדי לשנות את רוחב הפס עבור אלגוריתם FR, הגדר את הערכים הנדרשים עבור
LteEnbNetDevice:

רוחב פס uint8_t = 100;
lteHelper->SetEnbDeviceAttribute ("DlBandwidth", UintegerValue (רוחב פס));
lteHelper->SetEnbDeviceAttribute ("UlBandwidth", UintegerValue (רוחב פס));

כעת, כל תצורת אלגוריתמי FR תתואר.

קשה תדר שימוש חוזר אַלגוֹרִיתְם
כפי שמתואר בסעיף sec-fr-hard-algorithm של תיעוד העיצוב
ns3::LteFrHardAlgorithm משתמש בתת פס אחד. כדי להגדיר את תת-הפס זה המשתמש צריך לציין
היסט ורוחב פס עבור DL ו-UL במספר RBs.

אלגוריתם שימוש חוזר בתדר קשיח מספק את התכונות הבאות:

· DlSubBandOffset: היסט קישור למטה במספר קבוצות חסימת משאבים

· DlSubBandwidth: תצורת רוחב-תת-פס להעברת קישור למטה במספר של
קבוצות חסימת משאבים

· UlSubBandOffset: היסט קישור מעלה במספר קבוצות חסימת משאבים

· UlSubBandwidth: תצורת רוחב תת פס של שידור Uplink במספר המשאבים
חסום קבוצות

תצורה לדוגמה של 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: Uplink Common SubBandWith Configuration במספר המשאבים
חסום קבוצות

· UlEdgeSubBandOffset: Uplink Edge SubBand היסט במספר קבוצות בלוק משאבים

· UlEdgeSubBandwidth: תצורת Uplink Edge SubBandwidth במספר המשאבים
חסום קבוצות

· DlCommonSubBandwidth: תצורת רוחב פס נפוצה של Downlink במספר של
קבוצות חסימת משאבים

· DlEdgeSubBandOffset: קיזוז של קצה SubBand ב-Downlink במספר קבוצות בלוק משאבים

· DlEdgeSubBandwidth: תצורת רוחב רוחב משנה של Edge Downlink במספר המשאבים
חסום קבוצות

· RsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
תת-רצועת קצה

· CenterPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס מרכזי, ערך ברירת מחדל
dB0

· EdgePowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת המחדל dB0

· CenterAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור המרכזי, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· EdgeAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור קצה, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

הדוגמה להלן מאפשרת ל-eNB להשתמש ב-RBs מ-0 עד 6 כתת-פס נפוץ ומ-12 עד 18 כ-
תת-פס פרטי ב-DL ו-UL, סף RSRQ הוא 20 dB, הספק באזור המרכז שווה
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 משתמש ברוחב פס שלם של התא, אבל יש שניים
תת-להקות, בתוך UEs מוגשות עם רמת הספק שונה.

אלגוריתם שימוש חוזר בתדר רך מספק את התכונות הבאות:

· UlEdgeSubBandOffset: Uplink Edge SubBand היסט במספר קבוצות בלוק משאבים

· UlEdgeSubBandwidth: תצורת Uplink Edge SubBandwidth במספר המשאבים
חסום קבוצות

· DlEdgeSubBandOffset: קיזוז של קצה SubBand ב-Downlink במספר קבוצות בלוק משאבים

· DlEdgeSubBandwidth: תצורת רוחב רוחב משנה של Edge Downlink במספר המשאבים
חסום קבוצות

· AllowCenterUeUseEdgeSubBand: אם UEs מרכזיים אמיתיים יכולים לקבל RBGs על תת-פס קצה,
אחרת תת-רצועת קצה מותרת רק עבור UEs קצה, ערך ברירת המחדל הוא אמת

· RsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
תת-רצועת קצה

· CenterPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס מרכזי, ערך ברירת מחדל
dB0

· EdgePowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת המחדל dB0

· CenterAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור המרכזי, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· EdgeAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור קצה, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

הדוגמה להלן מגדירה RBs מ-8 עד 16 לשימוש על-ידי UEs קצה התא ותת-הפס זה הוא
לא זמין עבור משתמשי סלולר. סף RSRQ הוא 20 dB, הספק באזור המרכז שווה
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: Uplink Common SubBandWith Configuration במספר המשאבים
חסום קבוצות

· UlEdgeSubBandOffset: Uplink Edge SubBand היסט במספר קבוצות בלוק משאבים

· UlEdgeSubBandwidth: תצורת Uplink Edge SubBandwidth במספר המשאבים
חסום קבוצות

· DlCommonSubBandwidth: תצורת רוחב פס נפוצה של Downlink במספר של
קבוצות חסימת משאבים

· DlEdgeSubBandOffset: קיזוז של קצה SubBand ב-Downlink במספר קבוצות בלוק משאבים

· DlEdgeSubBandwidth: תצורת רוחב רוחב משנה של Edge Downlink במספר המשאבים
חסום קבוצות

· CenterRsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
בתת פס בינוני

· EdgeRsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
בתת פס קצה

· CenterAreaPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס מרכזי, ברירת מחדל
ערך dB0

· MediumAreaPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס בינוני, ברירת מחדל
ערך dB0

· EdgeAreaPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת מחדל
dB0

· CenterAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור המרכזי, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· MediumAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור בינוני, Absolute
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· EdgeAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור קצה, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

בדוגמה להלן RBs מ-0 עד 6 ישמשו כתת-פס נפוץ (בינוני), RBs מ-6 עד
12 ישמש כתת-פס קצה ו-RBs מ-12 עד 24 ישמש כתת-פס מרכזי (זה
מורכב עם RBs שנותרו). סף RSRQ בין אזור מרכז לבינוני הוא 28 dB,
סף RSRQ בין אזור בינוני לקצה הוא 18 dB. כוח באזור המרכז שווה
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));

משופר חֶלקִי תדר שימוש חוזר אַלגוֹרִיתְם
Enhanced Fractional Frequency Reuse (EFFR) שומרת חלק מרוחב הפס של המערכת עבור כל תא
(בדרך כלל ישנם 3 סוגי תאים וכל אחד מקבל 1/3 מרוחב הפס של המערכת). ואז חלק מ
רוחב-הפס הזה שהוא השתמש בו ראשי מגזר עם שימוש חוזר בגורם 3 וכמו המשני מגזר
עם גורם שימוש חוזר 1. על המשתמש להגדיר (עבור DL ו-UL) היסט של תת-הפס של התא
במספר RB, מספר RB אשר ישמש כ ראשי מגזר ומספר RB אשר
ישמש כ המשני מגזר. ראשי מגזר משמש תא כרצונו, אבל RBs מ
המשני מגזר ניתן להקצות ל-UE רק אם משוב CQI מ-UE זה גבוה יותר
ערך מסף CQI שהוגדר. UE נחשב ל-Edge UE כאשר RSRQ שלו נמוך יותר
מֵאֲשֶׁר RsrqThreshold.

מכיוון שכל eNb צריך לדעת היכן הם ראשיים ומשניים של סוגי תאים אחרים, הוא יעשה זאת
חשב אותם בהנחה שהתצורה זהה עבור כל תא ורק רוחב פס משנה
הקיזוזים שונים. לכן חשוב לחלק את רוחב הפס הזמין של המערכת באופן שווה
כל תא והחל את אותה תצורה של פלחים ראשיים ומשניים עליהם.

אלגוריתם שימוש חוזר בתדר חלקי משופר מספק את התכונות הבאות:

· UlSubBandOffset: Uplink SubBand Offset עבור תא זה במספר בלוק משאבים
קבוצות

· UlReuse3SubBandwidth: Uplink Reuse 3 SubBandwidth Configuration במספר המשאבים
חסום קבוצות

· UlReuse1SubBandwidth: Uplink Reuse 1 SubBandwidth Configuration במספר המשאבים
חסום קבוצות

· DlSubBandOffset: קיזוז תת-הקישור למטה עבור תא זה במספר בלוק משאבים
קבוצות

· DlReuse3SubBandwidth: Downlink Reuse 3 SubBandwidth Configuration במספר של
קבוצות חסימת משאבים

· DlReuse1SubBandwidth: Downlink Reuse 1 SubBandwidth Configuration במספר של
קבוצות חסימת משאבים

· RsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
תת-רצועת קצה

· CenterAreaPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס מרכזי, ברירת מחדל
ערך dB0

· EdgeAreaPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת מחדל
dB0

· DlCqiThreshold: אם ה-DL-CQI עבור RBG של גבוה מסף זה, שידור
ב-RBG אפשרי

· UlCqiThreshold: אם ה-UL-CQI עבור RBG של גבוה מסף זה, שידור
ב-RBG אפשרי

· CenterAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור המרכזי, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· EdgeAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור קצה, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

בדוגמה למטה היסט ב-DL ו-UL הוא 0 RB, 4 RB ישמש ב ראשי מגזר ו
המשני מגזר. סף RSRQ בין אזור המרכז לקצה הוא 25 dB. 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 שהיא בחרה להשתמש בהם בתת פס קצה. אם
אין UE המסווגים כ-Edge UE בתא, eNB לא ישתמש באף RB כתת-פס קצה.

אלגוריתם שימוש חוזר בתדר חלקי מבוזר מספק את התכונות הבאות:

· חישוב מרווח: מרווח זמן בין חישוב של תת-רצועת Edge, ברירת מחדל
ערך שנייה אחת

· RsrqThreshold: אם ה-RSRQ של גרוע מסף זה, יש להגיש UE
תת-רצועת קצה

· RsrpDifferenceThreshold: אם ההבדל בין עוצמת האות המתקבל
על ידי UE מהתא המשרת והספק האות המתקבל מהסמוך
התא קטן מערך RsrpDifferenceThreshold, משקל התא גדל

· CenterPowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת מחדל
dB0

· EdgePowerOffset: PdschConfigDedicated:: ערך Pa עבור תת-פס קצה, ערך ברירת המחדל dB0

· EdgeRbNum: מספר RB שניתן להשתמש בהם בתת-פס קצה

· CenterAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור המרכזי, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 1 ממופה ל-1 לפי TS36.213 טבלה 5.1.1.1-2

· EdgeAreaTpc: ערך TPC אשר יוגדר ב-DL-DCI עבור UEs באזור קצה, מוחלט
נעשה שימוש במצב, ערך ברירת המחדל 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));

Uplink כוח שליטה
הפונקציונליות של Uplink Power Control מופעלת כברירת מחדל. המשתמש יכול להשבית אותו על ידי הגדרה
התכונה הבוליאנית ns3::LteUePhy::EnableUplinkPowerControl לאמיתי.

המשתמש יכול לעבור בין מנגנוני בקרת כוח בלולאה פתוחה ובקרת כוח במעגל סגור
על ידי הגדרת התכונה הבוליאנית ns3::LteUePowerControl::ClosedLoop. כברירת מחדל סגור
בקרת כוח לולאה עם מצב צבירה מופעלת.

אובדן נתיב הוא מרכיב מפתח ב-Uplink Power Control. זה מחושב כהבדל בין
פרמטר RSRP ופרמטר ReferenceSignalPower מסונן. ReferenceSignalPower נשלח עם SIB2.

תכונות זמינות ב-Uplink Power Control:

· לופ סגור: אם נכון לולאה סגורה מצב בקרת כוח Uplink מופעל ו-Open Loop
Power Control אחרת, ערך ברירת המחדל הוא false

· הצטברות מופעלת: אם מצב צבירה אמיתי מופעל ומצב מוחלט
אחרת, ערך ברירת המחדל הוא false

· אלפא: גורם הפיצוי לאובדן נתיב, ערך ברירת המחדל הוא 1.0

· Pcmin: UE TxPower מינימלי, ערך ברירת המחדל הוא -40 dBm

· Pcmax: UE TxPower מקסימלי, ערך ברירת המחדל הוא 23 dBm

· PoNominalPusch: פרמטר זה צריך להיות מוגדר על ידי שכבות גבוהות יותר, אבל כרגע הוא צריך
כדי להיות מוגדר על ידי מערכת תכונות, ערכים אפשריים הם מספרים שלמים בטווח (-126 ...
24), ערך ברירת המחדל הוא -80

· PoUePusch: פרמטר זה צריך להיות מוגדר על ידי שכבות גבוהות יותר, אבל כרגע הוא צריך
להיות מוגדר לפי מערכת תכונות, ערכים אפשריים הם מספרים שלמים בטווח (-8 ... 7),
ערך ברירת המחדל הוא 0

· PsrsOffset: פרמטר זה צריך להיות מוגדר על ידי שכבות גבוהות יותר, אבל כרגע הוא צריך
להיות מוגדר לפי מערכת תכונות, ערכים אפשריים הם מספרים שלמים בטווח (0 ... 15),
ערך ברירת המחדל הוא 7, מה שנותן P_Srs_Offset_Value = 0

עקבות ערכים in Uplink כוח לִשְׁלוֹט:

· ReportPuschTxPower: UE TxPower נוכחי עבור PUSCH

· ReportPucchTxPower: UE TxPower נוכחי עבור PUCCH

· ReportSrsTxPower: UE TxPower נוכחי עבור SRS

תצורה לדוגמה מוצגת להלן:

Config::SetDefault ("ns3::LteUePhy::EnableUplinkPowerControl", BooleanValue (true));
Config::SetDefault ("ns3::LteEnbPhy::TxPower", DoubleValue (30));
Config::SetDefault ("ns3::LteUePowerControl::ClosedLoop", BooleanValue (true));
Config::SetDefault ("ns3::LteUePowerControl::AccumulationEnabled", BooleanValue (true));

כדוגמה, המשתמש יכול להציץ ולהפעיל את תוכנית lena-uplink-power-control.

דוגמאות תוכניות
הספריה src/lte/examples/ מכיל כמה תוכנות סימולציה לדוגמה המראות כיצד לעשות זאת
לדמות תרחישי LTE שונים.

התייחסות תרחישים
יש כמות עצומה של תרחישי סימולציית LTE ייחוס שניתן למצוא ב
סִפְרוּת. הנה רשימה של כמה מהם:

· תרחישי הדמיית המערכת המוזכרים בסעיף A.2 של [TR36814].

· דגם הפס הכפול [R4-092042], אשר מיושם בחלקו בדוגמה
התוכנית src/lte/examples/lena-dual-stripe.cc. תוכנית לדוגמה זו כוללת הרבה
פרמטרים הניתנים להגדרה אשר ניתן להתאים אישית על ידי שינוי הגלובלי המתאים
משתנים. כדי לקבל רשימה של כל המשתנים הגלובליים האלה, אתה יכול להפעיל את הפקודה הזו:

./waf --run lena-dual-stripe --command-template="%s --PrintGlobals"

תת-הסעיף הבא מציג דוגמה להפעלת קמפיין סימולציה באמצעות
תוכנית לדוגמה זו.

מסירת הדמיה מסע
בתת-סעיף זה, נדגים דוגמה להפעלת קמפיין סימולציה באמצעות
מודול LTE של ns-3. מטרת הקמפיין היא להשוות את ההשפעה של כל אחד מהם
אלגוריתם מסירה מובנה של מודול LTE.

הקמפיין ישתמש ב- לנה-דו-פס תוכנית לדוגמה. ראשית, עלינו לשנות את
תוכנית לדוגמה להפקת הפלט שאנו צריכים. בהזדמנות זו, אנחנו רוצים לייצר
מספר מסירות, תפוקה ממוצעת של משתמש ו-SINR ממוצע.

ניתן לקבל את מספר המסירות על ידי ספירת מספר הפעמים HandoverEndOk
מסירת צעדיו מפוטר. לאחר מכן ניתן לקבל את התפוקה הממוצעת של המשתמש על ידי הפעלת ה
RLC הדמיה תְפוּקָה. לבסוף, ניתן לקבל SINR על ידי הפעלת הדמיית PHY
תְפוּקָה. קטע הקוד לדוגמה הבא מציג דרך אפשרית אחת להשיג את האמור לעיל:

לבטל את
NotifyHandoverEndOkUe (std::string context, uint64_t imsi,
uint16_t cellId, uint16_t rnti)
{
std::cout << "Handover IMSI " << imsi << std::endl;
}

int
main (int argc, char *argv[])
{
/*** SNIP ***/

Config::Connect ("/NodeList/*/DeviceList/*/LteUeRrc/HandoverEndOk",
MakeCallback (&NotifyHandoverEndOkUe));

lteHelper->EnablePhyTraces ();
lteHelper->EnableRlcTraces ();
Ptr rlcStats = lteHelper->GetRlcStats ();
rlcStats->SetAttribute ("זמן התחלה", ערך זמן (שניות (0)));
rlcStats->SetAttribute ("EpochDuration", TimeValue (שניות (simTime)));

סימולטור::Run ();
סימולטור::הרוס ();
0 לחזור;
}

לאחר מכן עלינו להגדיר את הפרמטרים של התוכנית כך שיתאימו לצרכי הסימולציה שלנו. אָנוּ
מחפשים את ההנחות הבאות בסימולציה שלנו:

· 7 אתרים של מאקרו eNodeBs תלת-מגזרי (כלומר 21 מאקרו-תאים) פרוסים במשושה
פריסה עם מרחק של 500 מ' בין האתרים.

· למרות ש לנה-דו-פס מיועד במקור עבור דו-שכבתי (macrocell ו
סימולציית femtocell), נפשט את הסימולציה שלנו לשכבה אחת (macrocell)
סימולציה בלבד.

· UEs מופצים באופן אקראי ברחבי האתרים ומתחברים לרשת באופן אוטומטי
באמצעות בחירת תאים במצב המתנה. לאחר מכן, UE תשוטט בסביבת הסימולציה
עם מהירות תנועה של 60 קמ"ש.

· משך סימולציה של 50 שניות, כך ש-UEs היו נוסעים מספיק רחוק כדי להפעיל כמה
מסירות.

· 46 dBm הספק מקרוסל Tx והספק UE Tx של 10 dBm.

· ישמש מצב EPC מכיוון שהליך המסירה של X2 מחייב את הפעלתו.

· תעבורת downlink ו-uplink במאגר מלא, שניהם ברוחב פס של 5 מגה-הרץ, באמצעות פרוטוקול TCP
ומתזמן יריד פרופורציונלי.

· פרוטוקול RRC אידיאלי.

טבלתי לנה-דו-פס פרמטר תצורה ל מסירה מסע להלן מראה כיצד אנו
להגדיר את הפרמטרים של לנה-דו-פס כדי להשיג את ההנחות לעיל.

לנה-דו-פס פרמטר תצורה ל מסירה מסע
┌───────────────────┬────────────────── ───────── ───────┐
│שם פרמטר │ ערך │ תיאור │
├───────────────────┼────────────────── ───────── ───────┤
│simTime │ 50 │ 50 שניות סימולציה │
│ │ │ משך │
├───────────────────┼────────────────── ───────── ───────┤
│nבלוקים │ 0 │ השבתת דירה │
│ │ │ מבנים ופמטו-תאים │
├───────────────────┼────────────────── ───────── ───────┤
│nMacroEnbSites │ 7 │ מספר מאקרותא │
│ │ │ אתרים (בכל אתר יש 3 │
│ │ │ תאים) │
├───────────────────┼────────────────── ───────── ───────┤
│nMacroEnbSitesX │ 2 │ אתרי המאקרו-תאים יהיו │
│ │ │ להיות ממוקם ב-2-3-2 │
│ │ │ היווצרות │
├───────────────────┼────────────────── ───────── ───────┤
│interSiteDistance │ 500 │ 500 מ' מרחק בין │
│ │ │ אתרי מאקרו תאים סמוכים │
├───────────────────┼────────────────── ───────── ───────┤
│macroEnbTxPowerDbm │ 46 │ 46 dBm הספק Tx לכל │
│ │ │ מאקרותא │
├───────────────────┼────────────────── ───────── ───────┤
│epc │ 1 │ אפשר מצב EPC │
└───────────────────┴─────────────────── ───────── ───────┘

│epcDl │ 1 │ אפשר DL מאגר מלא │
│ │ │ תנועה │
├───────────────────┼────────────────── ───────── ───────┤
│epcUl │ 1 │ אפשר UL מאגר מלא │
│ │ │ תנועה │
├───────────────────┼────────────────── ───────── ───────┤
│useUdp │ 0 │ השבת תעבורת UDP ו│
│ │ │ אפשר TCP במקום זאת │
├───────────────────┼────────────────── ───────── ───────┤
│macroUeDensity │ 0.00002 │ קובע את מספר UEs │
│ │ │ (מתורגם ל-48 UEs ב-│
│ │ │ הסימולציה שלנו) │
├───────────────────┼────────────────── ───────── ───────┤
│outdoorUeMinSpeed ​​│ 16.6667 │ תנועת UE מינימלית │
│ │ │ מהירות ב-m/s (60 קמ"ש) │
├───────────────────┼────────────────── ───────── ───────┤
│outdoorUeMaxSpeed ​​│ 16.6667 │ תנועת UE מקסימלית │
│ │ │ מהירות ב-m/s (60 קמ"ש) │
├───────────────────┼────────────────── ───────── ───────┤
│macroEnbBandwidth │ 25 │ 5 MHz DL ו-UL │
│ │ │ רוחב פס │
├───────────────────┼────────────────── ───────── ───────┤
│generateRem │ 1 │ (אופציונלי) לשרטוט │
│ │ │ סביבת הרדיו │
│ │ │ מפה │
└───────────────────┴─────────────────── ───────── ───────┘

חלק מההנחות הנדרשות אינן זמינות כפרמטרים של לנה-דו-פס,
במקרה זה, אנו עוקפים את תכונות ברירת המחדל, כפי שמוצג בטבלה מגבילים ברירת מחדל
תכונות ל מסירה מסע לְהַלָן.

מגבילים ברירת מחדל תכונות ל מסירה מסע
┌──────────────────────────────────────── ───────── ────┬────────────────────────────────── ───────── ──────────────┐
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::LteHelper::HandoverAlgorithm │ ns3::NoOpHandoverAlgorithm, │ בחירת מסירה │
│ │ ns3::A3RsrpHandoverAlgorithm, │ אלגוריתם │
│ │ ns3::A2A4RsrqHandover אלגוריתם │ │
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::LteHelper::מתזמן │ ns3::PfFfMacScheduler │ יריד פרופורציונלי │
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::DlRlcOutputFilename │ -DlRlcStats.txt │ שם קובץ עבור DL RLC │
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::RadioBearerStatsCalculator::UlRlcOutputFilename │ -UlRlcStats.txt │ שם קובץ עבור UL RLC │
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::PhyStatsCalculator::DlRsrpSinrשם הקובץ │ -DlRsrpSinrStats.txt │ שם קובץ עבור DL PHY │
├─────────────────────────────────────── ───────── ────┼─────────────────────────────────── ───────── ──────────────┤
│ns3::PhyStatsCalculator::UlSinrשם קובץ │ -UlSinrStats.txt │ שם קובץ עבור UL PHY │
└─────────────────────────────────────── ───────── ────┴──────────────────────────────────── ───────── ──────────────┘

ns-3 מספק דרכים רבות להעברת ערכי תצורה לסימולציה. בזה
לדוגמה, נשתמש בארגומנטים של שורת הפקודה. זה נעשה בעצם על ידי הוספת ה
פרמטרים והערכים שלהם ל- WAF להתקשר כאשר מתחילים כל סימולציה בודדת. כך
מה היא WAF קריאות להפעלת 3 הסימולציות שלנו ייראו כך:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::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 traces, כי אנחנו
צריך לוודא שהם לא יוחלפו בהפעלת הסימולציה הבאה. בזה
לדוגמה, אנו מציינים את השמות אחד אחד באמצעות הארגומנטים של שורת הפקודה.

· --RngRun=1 ארגומנט בסוף משמש להגדרת מספר הריצה המשמש את
מחולל מספרים אקראיים בשימוש בסימולציה. אנחנו מריצים מחדש את אותן סימולציות עם
אחר RngRun ערכים, ומכאן יוצרים כמה שכפולים עצמאיים של אותו הדבר
סימולציות. לאחר מכן אנו ממוצעים את התוצאות שהושגו משכפולים אלה להשגה
קצת אמון סטטיסטי.

· נוכל להוסיף א --generateRem=1 ארגומנט ליצירת הקבצים הדרושים ליצירה
מפת סביבת הרדיו (REM) של הסימולציה. התוצאה היא איור REM מושג
החל מ- a הדמיה in מסירה מסע להלן, שניתן להפיק על ידי ביצוע ה
השלבים המתוארים בסעיף רדיו סביבה מפות. איור זה מציג גם את
מיקום של eNodeBs ו-UEs בתחילת סימולציה באמצעות RngRun = 1. אַחֵר
ערכים של RngRun עשוי לייצר עמדת UE שונה.
[תמונה] REM שהתקבל מסימולציה בקמפיין מסירה.UNINDENT

לאחר שעות של ריצה, מסע הסימולציה יסתיים בסופו של דבר. בהמשך נעשה
לבצע עיבוד אחר על פלט הסימולציה המופק כדי לקבל משמעות
מידע מתוכו.

בדוגמה זו, אנו משתמשים ב- GNU Octave כדי לסייע בעיבוד של נתוני תפוקה ונתוני SINR,
כפי שהודגם בתסריט לדוגמה של GNU Octave להלן:

% RxBytes הוא העמודה העשירית
DlRxBytes = load ("no-op-DlRlcStats.txt") (:,10);
DlAverageThroughputKbps = סכום (DlRxBytes) * 8 / 1000 / 50

% RxBytes הוא העמודה העשירית
UlRxBytes = load ("no-op-UlRlcStats.txt") (:,10);
UlAverageThroughputKbps = סכום (UlRxBytes) * 8 / 1000 / 50

% Sinr הוא העמודה השישית
DlSinr = load ("no-op-DlRsrpSinrStats.txt") (:,6);
% לבטל ערכי NaN
idx = isnan (DlSinr);
DlSinr (idx) = 0;
DlAverageSinrDb = 10 * log10 (ממוצע (DlSinr)) % המרה ל-dB

% Sinr הוא העמודה השישית
UlSinr = load ("no-op-UlSinrStats.txt") (:,5);
% לבטל ערכי NaN
idx = isnan (UlSinr);
UlSinr (idx) = 0;
UlAverageSinrDb = 10 * log10 (ממוצע (UlSinr)) % המרה ל-dB

באשר למספר מסירות, אנו יכולים להשתמש בסקריפט מעטפת פשוט כדי לספור את מספר
מופעים של המחרוזת "Handover" בקובץ היומן:

$ grep "Handover" no-op.txt | wc -l

טבלתי תוצאות שימוש of מסירה מסע להלן מראה את הנתונים הסטטיסטיים המלאים לאחר שסיימנו
עם עיבוד לאחר בכל ריצת סימולציה בודדת. הערכים המוצגים הם הממוצע
מהתוצאות שהתקבלו מ RngRun של 1, 2, 3 ו-4.

תוצאות שימוש of מסירה מסע
┌────────────────────┬──────────────── ───────┬─ ───────────────┐
│ סטטיסטיקה │ ללא הפעלה │ A2-A4-RSRQ │ התא החזק ביותר │
├────────────────────┼────────────────── ───────┼─ ───────────────┤
│ מערכת DL ממוצעת │ 6 615 kbps │ 20 509 kbps │ 19 709 kbps │
│תפוקה │ │ │ │
├────────────────────┼────────────────── ───────┼─ ───────────────┤
│ מערכת UL ממוצעת │ 4 095 kbps │ 5 705 kbps │ 6 627 kbps │
│תפוקה │ │ │ │
├────────────────────┼────────────────── ───────┼─ ───────────────┤
│ממוצע DL SINR │ -0.10 dB │ 5.19 dB │ 5.24 dB │
├────────────────────┼────────────────── ───────┼─ ───────────────┤
│ממוצע UL SINR │ 9.54 dB │ 81.57 dB │ 79.65 dB │
├────────────────────┼────────────────── ───────┼─ ───────────────┤
│מספר מסירות │ 0 │ 0.05694 │ 0.04771 │
│ לכל UE לשנייה │ │ │ │
└────────────────────┴────────────────── ───────┴─ ───────────────┘

התוצאות מראות כי קיום אלגוריתם מסירה בסימולציית ניידות משפר את שניהם
תפוקת משתמש ו-SINR באופן משמעותי. יש הבדל קטן בין השניים
אלגוריתמי מסירה בתרחיש זה של מסע פרסום. יהיה מעניין לראות אותם
ביצועים בתרחישים שונים, כגון תרחישים עם פריסת eNodeBs ביתית.

תדר שימוש חוזר דוגמאות
ישנן שתי דוגמאות המציגות את הפונקציונליות של אלגוריתמי שימוש חוזר בתדר.

לנה-תדר-שימוש חוזר היא דוגמה פשוטה עם 3 eNBs בפריסת משולש. יש 3 תאים
UEs edge, הממוקמים במרכז המשולש הזה ו-3 UEs מרכזי תאים (אחד ליד
כל eNB). המשתמש יכול גם לציין את מספר ה-UEs הממוקמים באופן אקראי. אלגוריתם FR הוא
מותקן ב-eNBs ולכל eNB יש FrCellTypeId שונה, מה המשמעות של כל eNB
תצורת FR שונה. המשתמש יכול להפעיל לנה-תדר-שימוש חוזר עם 6 FR שונים
אלגוריתמים: NoOp, Hard FR, Strict FR, Soft FR, Soft FFR ו-Enhanced FFR. כדי להפעיל תרחיש
עם אלגוריתם FFR מבוזר, המשתמש צריך להשתמש lena-distributed-ffr. שתי הדוגמאות הללו
דומים מאוד, אבל הם פוצלו מכיוון ש-FFR מבוזר דורש שימוש ב-EPC,
ואלגוריטים אחרים לא.

לרוץ לנה-תדר-שימוש חוזר עם אלגוריתמים שונים של שימוש חוזר בתדר, המשתמש צריך
ציין אלגוריתם FR על ידי דריסה של תכונת ברירת המחדל ns3::LteHelper::FfrAlgorithm.
דוגמה לפקודה להפעלה לנה-תדר-שימוש חוזר עם אלגוריתם Soft FR מוצג להלן:

$ ./waf --הרץ "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm"

בדוגמאות אלה נוספה פונקציונליות ליצירת REM ומעקב אחר מנתח ספקטרום.
המשתמש יכול לאפשר יצירה שלו על ידי הגדרה generRem ו gener SpectrumTrace
תכונות.

פקודה ליצירת REM עבור RB 1 בערוץ הנתונים מ לנה-תדר-שימוש חוזר תרחיש עם
אלגוריתם FR רך מוצג להלן:

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFrSoftAlgorithm
--generateRem=true --remRbId=1"

מפת סביבת רדיו עבור Soft FR מוצגת באיור REM ל RB 1 מושג החל מ-
לנה-תדר-שימוש חוזר דוגמה עם רך FR אַלגוֹרִיתְם מופעל.
[תמונה] REM עבור RB 1 שהתקבל מ לנה-תדר-שימוש חוזר דוגמה עם אלגוריתם Soft FR
enabled.UNINDENT

פקודה ליצירת עקבות ספקטרום ממנה לנה-תדר-שימוש חוזר תרחיש עם Soft FFR
האלגוריתם מוצג להלן (יש להגדיר את מיקום מנתח הספקטרום בפנים
תַסרִיט):

$ ./waf --run "lena-frequency-reuse --ns3::LteHelper::FfrAlgorithm=ns3::LteFfrSoftAlgorithm
--generateSpectrumTrace=true"

דוגמה למעקב אחר מנתח ספקטרום מוצג באיור ספֵּקטרוּם מנתח להתחקות מושג
החל מ- לנה-תדר-שימוש חוזר דוגמה עם רך FFR אַלגוֹרִיתְם מאופשר. ספֵּקטרוּם מנתח היה
ממוקם צורך eNB עם FrCellTypeId 2.. כפי שניתן לראות, תת-רצועות ערוצי נתונים שונות
נשלחים עם רמת הספק שונה (לפי התצורה), בעוד ערוץ הבקרה הוא
מועבר בהספק אחיד לאורך כל רוחב הפס של המערכת.
[תמונה] עקבות מנתח ספקטרום שהתקבלו מ לנה-תדר-שימוש חוזר דוגמה עם Soft FFR
אלגוריתם מופעל. ספקטרום מנתח אותר צריך eNB עם FrCellTypeId 2..UNINDENT

לנה-דו-פס ניתן להפעיל גם עם אלגוריתמים של שימוש חוזר בתדירות המותקנים בכל המאקרו
eNB. המשתמש צריך לציין אלגוריתם FR על ידי דריסה של תכונת ברירת המחדל
ns3::LteHelper::FfrAlgorithm. דוגמה לפקודה להפעלה לנה-דו-פס עם הארד FR
האלגוריתם מוצג להלן:

$ ./waf --run="lena-dual-stripe
--simTime=50 --nBlocks=0 --nMacroEnbSites=7 --nMacroEnbSitesX=2
--epc=1 --useUdp=0 --outdoorUeMinSpeed=16.6667 --outdoorUeMaxSpeed=16.6667
--ns3::LteHelper::HandoverAlgorithm=ns3::NoOpHandoverAlgorithm
--ns3::LteHelper::FfrAlgorithm=ns3::LteFrHardAlgorithm
--ns3::RadioBearerStatsCalculator::DlRlcOutputFilename=no-op-DlRlcStats.txt
--ns3::RadioBearerStatsCalculator::UlRlcOutputFilename=no-op-UlRlcStats.txt
--ns3::PhyStatsCalculator::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
enabled.UNINDENT
[תמונה] REM עבור RB 10 שהתקבל מ לנה-דו-פס סימולציה עם אלגוריתם Hard FR
enabled.UNINDENT
[תמונה] REM עבור RB 20 שהתקבל מ לנה-דו-פס סימולציה עם אלגוריתם Hard FR
enabled.UNINDENT

פתרון בעיות ו ניפוי טיפים
משתמשים רבים מפרסמים ברשימת התפוצה של ns-3-users ושואלים, למשל, מדוע הם לא מקבלים
תעבורה בסימולציה שלהם, או אולי רק מעלה אבל בלי תעבורה למטה וכו' ברוב
במקרים, זה באג בתוכנית סימולציית המשתמש. להלן כמה טיפים לניפוי באגים
לתכנן ולגלות את סיבת הבעיה.

הגישה הכללית היא לאפשר באופן סלקטיבי והדרגתי רישום של רלוונטיים
רכיבי מודול LTE, מוכיחים עם כל הפעלה שהפלט הוא כצפוי. ב
פירוט:

· בדוק תחילה את מישור הבקרה, בפרט את חיבור ה-RRC
הליך, על ידי הפעלת רכיבי היומן LteUeRrc ו-LteEnbRrc

לאחר מכן בדוק שידורי מנות במישור הנתונים, החל מהפעלת היומן
רכיבי LteUeNetDevice וה-EpcSgwPgwApplication, ואז EpcEnbApplication, ואז
תנועה מטה בערימת הרדיו LTE (PDCP, RLC, MAC, ולבסוף PHY). כל זה עד לך
מצא היכן מפסיקים לעבד / להעביר מנות.

בדיקות תיעוד
סקירה כללית
כדי לבדוק ולאמת את מודול ns-3 LTE, מסופקות מספר חבילות בדיקה
משולב עם מסגרת הבדיקה ns-3. כדי להפעיל אותם, עליך להגדיר את
בניית הסימולטור בדרך זו:

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

האמור לעיל יפעיל לא רק את חבילות הבדיקה השייכות למודול LTE, אלא גם את אלה
השייכים לכל שאר המודולים של ns-3 בהם תלוי מודול LTE. ראה את ns-3
מדריך למידע כללי על מסגרת הבדיקה.

תוכל לקבל דוח מפורט יותר בפורמט HTML בדרך זו:

$ ./test.py -w results.html

לאחר הפעלת הפקודה לעיל, תוכל להציג את התוצאה המפורטת עבור כל בדיקה על ידי פתיחה
הקובץ results.html עם דפדפן אינטרנט.

אתה יכול להפעיל כל חבילת בדיקה בנפרד באמצעות הפקודה הזו:

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

לפרטים נוספים על test.py ומסגרת הבדיקות של ns-3, אנא עיין ב-ns-3
מדריך ל.

תיאור of מה היא מבחן סוויטות
יחידה בדיקות
SINR חישוב in מה היא קישור למטה
חבילת הבדיקות lte-downlink-sinr בודק שחישוב ה-SINR ב-downlink מבוצע
נכונה. ה-SINR ב-downlink מחושב עבור כל RB המוקצה לנתונים
שידורים על ידי חלוקת הספק של האות המיועד מה-eNB הנחשב ב-
סכום הספק הרעש בתוספת כל השידורים באותו RB המגיעים מ-eNBs אחרים
(אותות ההפרעה):

באופן כללי, אותות שונים יכולים להיות פעילים במהלך פרקי זמן שונים. אנו מגדירים את א
נֶתַח כמרווח הזמן בין כל שני אירועים מסוג התחלה או סוף של a
צורת גל. במילים אחרות, נתח מזהה מרווח זמן שבמהלכו הסט של
צורות גל אקטיביות אינן משתנות. תן לי להיות הנתח הגנרי, T_i משך הזמן שלו ו
thrm{SINR_i} ה-SINR שלו, מחושב עם המשוואה שלעיל. חישוב הממוצע
SINR rieme
חבילת הבדיקה בודקת שהחישוב הנ"ל מבוצע כהלכה בסימולטור.
וקטורי הבדיקה מתקבלים במצב לא מקוון על ידי סקריפט Octave שמיישם את האמור לעיל
המשוואה, וזה יוצר מחדש מספר אותות והפרעות משודרות אקראיות
אותות המחקים תרחיש שבו UE מנסה לפענח אות מ-eNB תוך כדי
מתמודדים עם הפרעות מ-eNBs אחרים. המבחן עובר אם הערכים המחושבים שווים ל
וקטור הבדיקה בסובלנות של 10^{-7}. הסובלנות נועדה להסביר את
שגיאות קירוב אופייניות לאריתמטיקה של נקודה צפה.

SINR חישוב in מה היא Uplink
חבילת הבדיקות lte-uplink-sinr בודק שחישוב ה-SINR ב-uplink מבוצע
נכונה. חבילת בדיקה זו זהה ל lte-downlink-sinr שתואר בקודם
סעיף, עם ההבדל ממה שמתייחסים כעת גם האות וגם ההפרעה
שידורים על ידי UEs, והקליטה מתבצעת על ידי eNB. חבילת הבדיקות הזו
יוצר מחדש מספר אותות משודרים אקראיים ואותות הפרעה כדי לחקות א
תרחיש שבו eNB מנסה לפענח את האות מכמה UEs בו זמנית (
אלה בתא של ה-eNB) בעודם מתמודדים עם הפרעות מ-UEs אחרים (אלה השייכים
לתאים אחרים).

וקטורי הבדיקה מתקבלים על ידי סקריפט אוקטבה ייעודי. המבחן עובר אם ה
ערכים מחושבים שווים לוקטור הבדיקה בתוך סובלנות של 10^{-7} אשר, באשר
מבחן ה-Downlink SINR, עוסק בבעיות של קירוב אריתמטי של נקודה צפה.

E-UTRA מוּחלָט רדיו תדר ערוץ מספר (EARFCN)
חבילת הבדיקות lte-earfcn בודק שתדר הספק המשמש את
מחלקה LteSpectrumValueHelper (שמיישמת את מודל הספקטרום LTE) מתבצעת ב
תאימות ל-[TS36101], שבו מספר ערוץ תדר הרדיו המוחלט של E-UTRA
(EARFCN) מוגדר. וקטור הבדיקה עבור חבילת בדיקה זו מורכב מקבוצה של ערכי EARFCN
ותדר הספק המתאים מחושב ביד בעקבות המפרט של
[TS36101]. הבדיקה עוברת אם תדר הספק המוחזר על ידי LteSpectrumValueHelper הוא
זהה לערך הידוע עבור כל אלמנט בווקטור הבדיקה.

מערכת בדיקות
מוקדש נושא שִׁחרוּר מִשֵׁרוּת בדיקות
חבילת הבדיקה 'lte-test-deactivate-bearer' יוצרת מקרה מבחן עם EnodeB ו-3 בודדים
של UE. כל UE מורכב מנושא ברירת מחדל אחד ונושא EPS ייעודי אחד עם אותו נושא
מפרט אבל עם ARP שונה. זרימת מקרה מבחן היא כדלקמן: צרף UE -> צור
ברירת מחדל+נושא ייעודי -> השבת אחד מהנושאים הייעודיים

מקרה הבדיקה משבית עוד יותר את הנושא היעודי בעל מזהה נושא 2(LCID=BearerId+2) של
UE ראשון (UE_ID=1) המשתמש יכול לתזמן את השבתת הנושא לאחר עיכוב זמן מסוים באמצעות
שיטת סימולטור::Schedule ().

לאחר סיום ביצוע מקרה הבדיקה, הוא יצור DlRlcStats.txt ו-UlRlcStats.txt. מַפְתֵחַ
שדות שצריך לבדוק בסטטיסטיקה הם:

|
התחל | סוף | מזהה תא | IMSI | RNTI | LCID | TxBytes | RxBytes |

מקרה מבחן מבוצע בשלושה עידנים. 1) בתקופה הראשונה (0.04s-1.04s) כל ה-UE's ו
נושאים מקבילים נקשרים
וזרימת מנות על הנושאים הייעודיים שהופעלו.

2. בתקופה השנייה (1.04s-2.04s), נטרול נושא מבוצע, ומכאן שהמשתמש יכול לראות
מספר קטן יחסית של TxBytes ב-UE_ID=1 ו-LCID=4 בהשוואה לנושאים אחרים.

3. בתקופה השלישית (2.04s-3.04s) מאז השבתת נושא של UE_ID=1 ו-LCID=4 היא
הושלם, המשתמש לא יראה שום רישום הקשור ל-LCID=4.

מקרה המבחן יעבור אם ורק אם 1) IMSI=1 ו-LCID=4 הוסרו לחלוטין בתקופה השלישית 2)
לא נראו מנות ב-TxBytes ו-RxBytes המתאימות ל-IMSI=1 ו-LCID=4 אם למעלה
הקריטריון אינו תואם למקרה המבחן הנחשב כנכשל

מסתגל אפנון ו סִמוּל בדיקות
חבילת הבדיקות lte-link-adaptation מספק בדיקות מערכת המשחזרות תרחיש עם א
eNB יחיד ו-UE יחיד. מקרי בדיקה שונים נוצרים התואמים לשונים
ערכי SNR הנתפסים על ידי ה-UE. מטרת הבדיקה היא לבדוק שבכל מקרה בדיקה את
MCS שנבחר תואם לכמה ערכי ייחוס ידועים. ערכי ייחוס אלו מתקבלים
על ידי יישום מחדש באוקטבה (ראה src/lte/test/reference/lte_amc.m) המודל המתואר ב
סעיף sec-lte-amc לחישוב היעילות הספקטרלית, וקביעת
אינדקס MCS המתאים על ידי חיפוש ידני של הטבלאות ב-[R1-081483]. המתקבל
וקטור הבדיקה מיוצג באיור מִבְחָן וקטור ל מסתגל אפנון ו סִמוּל.

ה-MCS המשמש את הסימולטור נמדד על ידי השגת פלט המעקב
מיוצר על ידי המתזמן לאחר 4ms (זה נחוץ כדי לקחת בחשבון את העיכוב הראשוני ב
דיווח CQI). ה-SINR שמחושב על ידי הסימולטור מתקבל גם באמצעות
LteChunkProcessor מִמְשָׁק. המבחן עובר אם שני התנאים הבאים מתקיימים
מרוצה:

1. ה-SINR שחושב על ידי הסימולטור מתאים ל-SNR של וקטור הבדיקה שבתוכו
סובלנות מוחלטת של 10^{-7};

2. מדד ה-MCS המשמש את הסימולטור מתאים בדיוק לזה שבבדיקה
וֶקטוֹר.
[תמונה] וקטור בדיקה עבור אפנון אדפטיבי וקידוד.UNINDENT

בין-תא התערבות בדיקות
חבילת הבדיקות Lte-התערבות מספק בדיקות מערכת היוצרות מחדש בין תא
תרחיש הפרעה עם שני eNBs, שלכל אחד מהם מחובר UE יחיד ועובד
מודולציה וקידוד אדפטיבית הן ב-downlink והן ב-uplink. הטופולוגיה של ה
התרחיש מתואר באיור טופולוגיה ל מה היא בין תא הַפרָעָה מבחן. ה-d_1
פרמטר מייצג את המרחק של כל UE ל-eNB שאליו הוא מחובר, בעוד שה-d_2
פרמטר מייצג את מרחק המפריע. נציין שטופולוגיית התרחישים היא כזו
שמרחק המפריע זהה ל-uplink ול-downlink; עדיין, בפועל
כוח ההפרעה הנתפס יהיה שונה, בגלל אובדן ההתפשטות השונה
ברצועות ה-uplink וה-downlink. מקרי בדיקה שונים מתקבלים על ידי שינוי ה-d_1 ו
d_2 פרמטרים.
[תמונה] טופולוגיה למבחן ההתאבכות הבין-תאית.UNINDENT

וקטורי הבדיקה מתקבלים באמצעות סקריפט אוקטבה ייעודי (זמין ב
src/lte/test/reference/lte_link_budget_interference.m), שעושה את תקציב הקישור
חישובים (כולל הפרעות) התואמים לטופולוגיה של כל מקרה בדיקה,
ומוציא את ה-SINR והיעילות הספקטרלית המתקבלת. זה האחרון רגיל אז
לקבוע (באמצעות אותו נוהל שאומץ עבור מסתגל אפנון ו סִמוּל בדיקות. אנחנו
שים לב שווקטור הבדיקה מכיל ערכים נפרדים עבור uplink ו-downlink.

UE מדידות בדיקות
חבילת הבדיקות lte-ue-מדידות מספק בדיקות מערכת היוצרות מחדש בין תא
תרחיש הפרעות זהה לזה שהוגדר עבורו Lte-התערבות חבילת בדיקות.
עם זאת, בבדיקה זו הכמויות שייבדקו מיוצגות על ידי RSRP ו-RSRQ
מדידות שבוצעו על ידי ה-UE בשתי נקודות שונות של המחסנית: המקור, אשר
היא שכבת UE PHY, והיעד, כלומר eNB RRC.

וקטורי הבדיקה מתקבלים על ידי שימוש בסקריפט אוקטבה ייעודי (זמין ב
src/lte/test/reference/lte-ue-measurements.m), שעושה את חישובי תקציב הקישור
(כולל הפרעות) התואם את הטופולוגיה של כל מקרה בדיקה, ומוציא את
כתוצאה מכך RSRP ו-RSRQ. הערכים שהתקבלו משמשים לאחר מכן לבדיקת נכונות
מדידות UE בשכבת PHY. לאחר מכן, יש להמיר אותם לפי 3GPP
עיצוב לצורך בדיקת נכונותם ברמת eNB RRC.

UE מדידה תצורה בדיקות
מלבד חבילת הבדיקה שהוזכרה לעיל, ישנן 3 חבילות בדיקה נוספות לבדיקת UE
מידות: lte-ue-measurements-piecewise-1, lte-ue-measurements-piecewise-2, ו
מסירת מידות. חבילות בדיקה אלו מתמקדות יותר בטריגר הדיווח
הליך, כלומר נכונות היישום של ההפעלה מבוססת אירועים
הקריטריונים מאומתים כאן.

באופן ספציפי יותר, הבדיקות מאמתות את תזמון ו תוכן של כל דוחות מדידה
שהתקבל על ידי eNodeB. כל מקרה מבחן הוא הדמיית LTE עצמאית ומקרה המבחן יהיה
לעבור אם דוחות המדידה מתרחשים רק בזמן שנקבע ומראה את הנכון
רמת RSRP (RSRQ אינו מאומת כרגע).

לפי חתיכה תצורה
התצורה החתיכה נועדה לבדוק תצורת מדידות UE מסוימת. ה
סקריפט סימולציה יגדיר את תצורת המדידות המתאימה ל-UE, אשר
יהיה פעיל לאורך כל הסימולציה.

מכיוון שערכי הייחוס מחושבים מראש על ידי ידיים, מניחים מספר הנחות
לפשט את הסימולציה. ראשית, הערוץ מושפע רק ממודל אובדן נתיב (בזה
במקרה, נעשה שימוש במודל Friis). שנית, נעשה שימוש בפרוטוקול RRC האידיאלי, ושכבה 3
הסינון מושבת. לבסוף, ה-UE נע בדפוס תנועה מוגדר מראש בין 4
כתמים ברורים, כפי שמתואר באיור UE תנועה להתחקות בכל מה היא הדמיה in
בצורה חלקית תצורה לְהַלָן. לכן התנודתיות של ה-RSRP הנמדד יכולה להיות
נקבע ביתר קלות.
[תמונה] עקבות תנועת UE לאורך הסימולציה בתצורה חלקית. UNINDENT

המוטיבציה מאחורי ה "טלפורט" בין הנקודות המוגדרות מראש היא להציג
שינוי דרסטי של רמת ה-RSRP, שיבטיח את ההפעלה של כניסה או יציאה
מצב האירוע הנבדק. על ידי ביצוע שינויים דרסטיים, ניתן להריץ את הבדיקה בפנים
פרק זמן קצר יותר.

תרשים נמדד RSRP להתחקות of an דוגמה אירוע A1 מבחן מקרה in בצורה חלקית תצורה
להלן מראה RSRP שנמדד לאחר סינון שכבה 1 על ידי שכבת PHY במהלך
סימולציה עם תצורה חלקית. מכיוון שסינון שכבה 3 מושבת, אלה
הם הערכים המדויקים שבהם השתמש מופע UE RRC להערכת טריגר דיווח
תהליך. שימו לב שהערכים מתרעננים כל 200 אלפיות השנייה, שזו ברירת המחדל
תקופת הסינון של דוח מדידות שכבת PHY. האיור מציג גם את הזמן שבו
תנאי כניסה ויציאה של מופע לדוגמה של אירוע A1 (תא המשרת הופך
טוב מהסף) מתרחשים במהלך הסימולציה.
[תמונה] עקבות RSRP נמדדת של מקרה בדיקה לדוגמה של אירוע A1 בחתיכה
configuration.UNINDENT

כל קריטריון דיווח נבדק מספר פעמים עם סף/קיזוז שונה
פרמטרים. חלק מתרחישי הבדיקה לוקחים בחשבון גם היסטרזיס וזמן להפעלה.
תרשים נמדד RSRP להתחקות of an דוגמה אירוע A1 עם היסטריה מבחן מקרה in בצורה חלקית
תצורה מתאר את השפעת ההיסטרזיס בדוגמה נוספת של מבחן אירוע A1.
[תמונה] עקבות RSRP נמדדת של אירוע A1 לדוגמה עם מקרה מבחן היסטרזיס
תצורה חלקית.UNINDENT

תצורה של Piecewise משמשת בשתי חבילות בדיקה של מדידות UE. הראשון הוא
lte-ue-measurements-piecewise-1, מעתה מבחן Piecewise #1, המדמה 1 UE ו
1 eNodeB. השני הוא lte-ue-measurements-piecewise-2, שיש לו UE אחד ו-1 eNodeBs
בסימולציה.

מבחן Piecewise #1 נועד לבדוק את הקריטריונים המבוססים על אירועים שאינם תלויים
על קיומו של תא שכן. קריטריונים אלה כוללים את אירוע A1 ו-A2. ה
אירועים אחרים נבדקים גם הם בקצרה כדי לוודא שהם עדיין פועלים כהלכה
(אם כי לא מדווחים כלום) בהיעדר תא שכן. שולחן UE
מידות מבחן תרחישים באמצעות בצורה חלקית תצורה #1 להלן מפרט את התרחישים
נבדק במבחן חלקי מס' 1.

UE מידות מבחן תרחישים באמצעות בצורה חלקית תצורה #1
┌───────┬───────────┬─────────────────── ───────── ──┬─────────────────┐
│ בדיקה מס' │ דיווח │ סף/היסט │ היסטרזיס │ זמן עד להפעלה │
│ │ קריטריונים │ │ │ │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│1 │ אירוע A1 │ נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│2 │ אירוע A1 │ רגיל │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│3 │ אירוע A1 │ רגיל │ לא │ קצר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│4 │ אירוע A1 │ רגיל │ לא │ ארוך │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│5 │ אירוע A1 │ רגיל │ לא │ סופר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│6 │ אירוע A1 │ רגיל │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│7 │ אירוע A1 │ גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│8 │ אירוע A2 │ נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│9 │ אירוע A2 │ רגיל │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│10 │ אירוע A2 │ רגיל │ לא │ קצר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│11 │ אירוע A2 │ רגיל │ לא │ ארוך │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│12 │ אירוע A2 │ רגיל │ לא │ סופר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│13 │ אירוע A2 │ רגיל │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│14 │ אירוע A2 │ גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│15 │ אירוע A3 │ אפס │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│16 │ אירוע A4 │ רגיל │ לא │ לא │
└───────┴───────────┴──────────────────── ───────── ──┴─────────────────┘

│17 │ אירוע A5 │ רגיל-נורמלי │ לא │ לא │
└───────┴───────────┴──────────────────── ───────── ──┴─────────────────┘

אירועים אחרים כגון אירוע A3, A4 ו-A5 תלויים במדידות של התא הסמוך, כך
הם נבדקים בצורה יסודית יותר במבחן Piecewise מס' 2. הסימולציה ממקמת את הצמתים על a
קו ישר ולהורות ל-UE "קְפִיצָה" באופן דומה כמו במבחן Piecewise #1.
מסירה מושבתת בסימולציה, כך שתפקיד התאים המשרתים והשכנים עושה זאת
לא לעבור במהלך הסימולציה. שולחן UE מידות מבחן תרחישים באמצעות בצורה חלקית
תצורה #2 להלן מפרטים את התרחישים שנבדקו במבחן Piecewise מס' 2.

UE מידות מבחן תרחישים באמצעות בצורה חלקית תצורה #2
┌───────┬───────────┬─────────────────── ───────── ──┬─────────────────┐
│ בדיקה מס' │ דיווח │ סף/היסט │ היסטרזיס │ זמן עד להפעלה │
│ │ קריטריונים │ │ │ │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│1 │ אירוע A1 │ נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│2 │ אירוע A1 │ רגיל │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│3 │ אירוע A1 │ רגיל │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│4 │ אירוע A1 │ גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│5 │ אירוע A2 │ נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│6 │ אירוע A2 │ רגיל │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│7 │ אירוע A2 │ רגיל │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│8 │ אירוע A2 │ גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│9 │ אירוע A3 │ חיובי │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│10 │ אירוע A3 │ אפס │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│11 │ אירוע A3 │ אפס │ לא │ קצר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│12 │ אירוע A3 │ אפס │ לא │ סופר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│13 │ אירוע A3 │ אפס │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│14 │ אירוע A3 │ שלילי │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│15 │ אירוע A4 │ נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│16 │ אירוע A4 │ רגיל │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│17 │ אירוע A4 │ רגיל │ לא │ קצר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│18 │ אירוע A4 │ רגיל │ לא │ סופר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│19 │ אירוע A4 │ רגיל │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│20 │ אירוע A4 │ גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│21 │ אירוע A5 │ נמוך-נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│22 │ אירוע A5 │ נמוך-נורמלי │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│23 │ אירוע A5 │ נמוך-גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│24 │ אירוע A5 │ רגיל-נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│25 │ אירוע A5 │ רגיל-נורמלי │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│26 │ אירוע A5 │ רגיל-נורמלי │ לא │ קצר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│27 │ אירוע A5 │ רגיל-נורמלי │ לא │ סופר │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│28 │ אירוע A5 │ רגיל-נורמלי │ כן │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│29 │ אירוע A5 │ רגיל-גבוה │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│30 │ אירוע A5 │ גבוה-נמוך │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│31 │ אירוע A5 │ גבוה-נורמלי │ לא │ לא │
├───────┼───────────┼─────────────────── ───────── ──┼─────────────────┤
│32 │ אירוע A5 │ גבוה-גבוה │ לא │ לא │
└───────┴───────────┴──────────────────── ───────── ──┴─────────────────┘

הערה אחת לגבי הבדיקות עם זמן עד להדק, הן נבדקות באמצעות 3 ערכים שונים של
זמן להפעלה: קצר (קצר מרווח הדיווח), ארוך (קצר יותר מהפילטר
תקופת מדידה של 200 אלפיות השנייה), ו סופר (יותר מ-200 אלפיות השנייה). שני הראשונים מבטיחים זאת
הערכת זמן להפעלה השתמש תמיד בדוחות המדידה האחרונים שהתקבלו מ-PHY
שִׁכבָה. בעוד שהאחרון אחראי על אימות הזמן עד לביטול ההפעלה, עבור
דוגמה כאשר דוח מדידה מ-PHY מראה שתנאי הכניסה/יציאה הוא לא
יותר נכון לפני הפעלת ההדק הראשון.

מסירת תצורה
מטרת תצורת המסירה היא לוודא אם מדידת UE
התצורה מתעדכנת כראוי לאחר מסירה מוצלחת. לזה
המטרה, הסימולציה תבנה 2 eNodeBs עם מדידת UE שונה
תצורה, וה-UE יבצע מסירה מתא אחד למשנהו. ה-UE יהיה
ממוקם על קו ישר בין 2 eNodeBs, והמסירה תופעל
באופן ידני. משך כל סימולציה הוא 2 שניות (למעט מקרה הבדיקה האחרון) וה-
המסירה מופעלת בדיוק באמצע הדרך של הסימולציה.

השמיים מסירת מידות חבילת הבדיקה מכסה סוגים שונים של תצורה
הבדלים. הראשון הוא ההבדל במרווח הדוחות, למשל ה-eNodeB הראשון הוא
מוגדר עם מרווח דוחות של 480 אלפיות השנייה, בעוד שה-eNodeB השני מוגדר עם 240 אלפיות השנייה
מרווח דיווח. לכן, כאשר ה-UE ביצע מסירה לתא השני, החדש
מרווח הדיווח חייב להיכנס לתוקף. כמו בתצורה חלקית, התזמון וה-
התוכן של כל דוח מדידה שיתקבל על ידי 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 offset -30 A3 offset +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-library באינטרנט באמצעות שירותי onworks.net