משתמש:Talel Atias/MANET

דף זה אינו ערך אנציקלופדי
דף זה הוא טיוטה של Talel Atias.

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

דף זה אינו ערך אנציקלופדי
דף זה הוא טיוטה של Talel Atias.

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

MANET - mobile ad hoc networks


ברשתות אלחוטיות אלו כל host הוא גם נתב מאחר ואין תשתית מוגדרת מראש וכ"ו ולכן כל host בנוסף להיותו משתתף צריך להעביר חבילות.

נוצרת פה בעייתיות עקב העובדה שברשתות ניידות קצב השינויים גדול ולכן יש צורך בפרוטוקול ייעודי

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

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

ישנם שני סוגים של פרוטוקולי ניתוב עבור רשתות MANET, האחד הינו יוזם(proactive) והשני הינו עצל(reactive), ה proactive דואג כל הזמן לשמור על מפת הנתיבים נכונים והשני reactive דואג למצוא נתיב רק כאשר יש צורך (on demand).

יתרונו של ה proactive הוא Latency נמוך יותר אך חסרונו הוא תקורה גבוהה יותר עקב אחזקת המסלולים.

מה יותר משתלם תלוי בסוג הרשת ובמידת התקשורת בה.

חשוב להבדיל בין שני סוגי ניתוב – הראשון זה ה hop-by-hop-routing שזה אומר שבטבלאות הניתוב יש

את ה next hop עבור היעד והשני הוא ה source-routing שהוא ניתוב שמתבסס על כך שהוא מגדיר את כל המסלול(ונשמר בכותרת).


DSR – Dynamic Source Routing: פרוטוקול זה הוא reactive(מגלה מסלול עלפי דרישה).

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

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


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

OLSR – Optimized Link State Routing: פרוטוקול זה הוא proactive(משמר מסלולים) ומשתמש בניתוב hop-by-hop . ראשית המשתתפים ברשתי בוחרים Connected Domain Set קטן ככל שהם יכולים, כך שרק הקבוצה הזו יוצרת LSA ורק היא מפיצה LSA שהיא מקבלת מאחד ממשתתפיה. • פרוטוקול proactive(מתחזק מצב) עבור רשתות אל חוטיות.

• כל צומת שומר על הצומת הבאה בדרך(next-hop).

• Link-State-overhead מופחת ע"י:

• רק חלק מהצמתים יוצרים LSA (רק צמתי ה ConnectedDomainSet שנקראים MultipoingRelayNodes) ומפיצים LSA של צמתים אחרים(נקראים TS מלשון Topology Control).

• הודעת LSA שכזו מכילה: שם הצומת המקור s, MS(s), בקשרים בין s לבין MS(s), הקשרים בין s לבין MPR(s), מספר סידורי.

• ייתכן שלא יעבור דיווח ב LSA על כל הצמתים.

• צמתי ב CDS נבחרים באופן מבוזר והם מנסים ליצור קבוצה קטנה ככל הניתן אך אין זה מובטח.

• אופן בחירת צמתי ה MultipointRealyNodes:

• כל צומת v בוחרת קבוצה MPR(v) שזו הקבוצה שתפיץ את ההודעות של v.


• אופן בחירת ה MPR(v) היא כך שכל הצמתים שבמרחק 2 קפיצות מ v מכוסות ע"י MPR(v).

• נגדיר קבוצת MultipointRelaySelectorSet ונסמנה כ MS(u) ככל הצמתים v שבחרו את u ב MPR(v).

• כעת כאשר הצומת u תדווח על שינויים היא תדווח על שינויים שהתרחשו רק ב MS(u) שלה.


• כיצד ניתן לדעת על שינויים ברשת?

• ע"י פרוטוקול HELLO של OLSR:

• תחנות מחליפות ביניהם הודעות HELLO (שכוללות גם מספר סידורי בתוכן).

• כל תחנה שמקבלת HELLO שולחת אותה גם לכל השכנים שלה במרחק 1 ומוסיפה לה את כל השכנים שלה במרחק 1(ובכך ניתן לדעת מהו ה MPR)

• כל שינוי של צמתים במרחק 1 עד 2 גורם לחישוב מחדש של ה MPR.

• בכל הודעת HELLO מאוחר יותר ישלחו השכנים וכן קבוצת ה MPR שנבחרה.