Wi-Fi 7

במכשירים עם Android מגרסה 13 ואילך, מערכת Android תומכת בתקן Wi-Fi 7‏ (IEEE 802.11be). בדף הזה מתוארות התכונות של Android Wi-Fi 7, כולל תכונות בסיסיות ופעולה במספר קישורים (MLO).

תכונות בסיסיות של Wi-Fi 7

בקטע הזה מוסבר על תכונות הבסיס של Wi-Fi 7 שכלולות ב-Android מגרסה 13 ואילך.

תמיכה ב-Wi-Fi 7 במכשיר

מסגרת Android כוללת את ה-API‏ WifiManager#isWifiStandardSupported(int standard), שאפליקציות יכולות להפעיל באמצעות הארגומנט ScanResults.WIFI_STANDARD_11BE כדי לבדוק אם המכשיר תומך ב-Wi-Fi 7.

כשמתבצעת קריאה ל-API הזה, מודול ה-Wi-Fi בודק אם שכבת-העל של התצורה config_wifi11beSupportOverride משמשת כביטול הגדרה ברירת המחדל, ומבצע את הפעולות הבאות:

  • אם שכבת-העל מוגדרת כ-true, ההנחה היא שהמכשיר תומך ב-Wi-Fi 7, ללא קשר לתשובה מ-nl80211. שינוי הערך הזה שימושי רק ליצרני מכשירים שאין להם מנהלי התקנים שתומכים ב-Wi-Fi 7.
  • אם שכבת-העל מוגדרת לערך false (ערך ברירת המחדל), מודול ה-Wi-Fi משתמש במידע מ-nl80211. מודול ה-Wi-Fi מבקש את המידע מ-wificond, שמפעיל את הפקודה NL80211_CMD_GET_WIPHY של nl80211. אם המאפיין NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY נמצא בתשובה מהדרייבר, ההנחה היא שהמכשיר תומך ב-Wi-Fi 7.

תמיכה ב-Wi-Fi 7 בנקודות AP שסורקו

מסגרת Android כוללת את ה-API‏ int ScanResult#getWifiStandard(), שאפליקציות יכולות להפעיל כדי לבדוק אם נקודת גישה (AP) שנסרקה תומכת ב-Wi-Fi 7. אם הנתב תומך ב-Wi-Fi 7, ה-API מחזיר את הערך ScanResults.WIFI_STANDARD_11BE. כדי שאפליקציות יוכלו להשתמש ב-API הזה, המכשיר לא חייב לתמוך ב-Wi-Fi 7.

כשקוראים ל-API הזה, מודול ה-Wi-Fi בודק אם EHT Capability IE נמצא בתוצאות שהתקבלו מסריקת הקישוריות. אם הערך EHT Capability IE מופיע בתוצאות הסריקה, נקודת הגישה שנסרקה תומכת ב-Wi-Fi 7. בכיתה WifiTracker של AOSP מוצג מידע התמיכה הזה בממשק המשתמש כשהיא פועלת במצב מפורט.

מצב החיבור של STA

מסגרת Android כוללת את ה-API‏ int WifiInfo#getWifiStandard(), שאפליקציות יכולות להפעיל כדי לבדוק אם מצב החיבור הנוכחי של התחנה (STA) הוא Wi-Fi 7. מצב החיבור של STA הוא Wi-Fi 7 כשגם המכשיר וגם הנתב המחובר תומכים ב-Wi-Fi 7. אם סטטוס החיבור הוא Wi-Fi 7, ה-API מחזיר את הערך ScanResults.WIFI_STANDARD_11BE.

כשמתבצעת קריאה ל-getWifiStandard, מודול ה-Wi-Fi קובע את המצב על ידי קריאה ל-HAL API של ISupplicantStaIface#getConnectionCapabilities(). ההטמעה של HAL API הזה בשכבת ה-AIDL‏ wpa_supplicant בודקת אם EHT Capability IE נמצא גם ב-AssocReq וגם ב-AssocRsp במהלך הגדרת החיבור.

בחירת רשת

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

ב-Android 13, הערך של ThroughputPredictor מחושב על סמך היכולות הבאות של AP:

  • תמיכה ב-Wi-Fi 7‏ (802.11be)
  • תמיכה ברוחב ערוץ של 320 MHz

הכללת היכולות האלה בלוגיקה של ThroughputPredictor מגדילה את הסיכויים לבחירת נקודות AP שתומכות ב-Wi-Fi 7, אם המכשיר יכול להשתמש בתכונות האלה.

מדידת מרחק מבוססת-RTT ב-Wi-Fi

Android מספק תמיכה ב-API לפתיח EHT ולרוחב ערוץ של 320 MHz ל-Wi-Fi RTT. כך אפשר לתמוך ביכולות שקשורות ל-Wi-Fi 7 בטווח RTT, בכל פעם שהצ'יפ תומך בכך.

ממשקי HAL API

ממשקי ה-API הבאים של HAL תומכים ביכולות של Wi-Fi 7 למדידת מרחק מבוססת-RTT:

ממשקי API

אפליקציות יכולות להשתמש בממשקי ה-API הבאים למדידת מרחק מבוססת-RTT ב-Wi-Fi 7:

Soft AP

Android תומך ב-Wi-Fi 7 ב-Soft AP ומספק את התכונות הבאות.

הפעלת Soft AP

ב-Android יש תמיכה בהפעלת Soft AP במצב Wi-Fi 7. ההגדרה הזו כפופה להגדרת שכבת-העל config_wifiSoftapIeee80211beSupported.

מודול ה-Wi-Fi משתמש בשכבת-העל config_wifiSoftapIeee80211beSupported כדי להגדיר את הערך הבוליאני HwModeParams#enable80211BE בקריאת ה-API IHostApd#addAccessPoint(). בשכבת ה-AIDL של hostapd, הערך הזה משמש להגדרת הפרמטרים hostapd.conf.

ממשקי HAL API

המשתנה הבווליאני enable80211BE ב-HwModeParams ב-HAL של hostapd תומך בהפעלת Soft AP במצב Wi-Fi 7.

דיווח על מידע של Soft AP

Android כולל תמיכה ב-API כדי לכלול מידע על Wi-Fi 7 ועל רוחב ערוץ של 320 MHz בנתוני ה-Soft AP שמדווחים.

ממשקי HAL API

הקבוע WIFI_STANDARD_11BE בממשק AIDL של Generation.aidl ב-HAL של hostapd, שמשמש ב-ApInfo שמדווח ב-callback של IHostapdCallback#onApInstanceInfoChanged(), תומך בדיווח על פרטי Soft AP.

ממשקי API

אפליקציות יכולות להשתמש בשיטות הבאות (ממשקי API של מערכת) ב-SoftApInfo כדי לדווח על פרטי Soft AP.

התכונות של MLO Wi-Fi 7

פעולה במספר קישורים (MLO) היא התכונה העיקרית במפרט של Wi-Fi 7‏ (802.11be). MLO היא תכונה חובה למכשירים עם קישורים מרובים (MLD) שפועלים ב-Wi-Fi 7, בין אם בו-זמנית ובין אם לא בו-זמנית.

תרשים MLO

איור 1. דיאגרמה של MLO.

כפי שמוצג באיור 1, גם ל-AP-MLD וגם ל-STA-MLD יש כמה מכונות AP או STA שפועלות בכל קישור. לכל קישור יש כתובת MAC נפרדת של AP או STA. גם לנקודת הגישה או לנקודת הקצה יש כתובת MAC של MLD לזיהוי המכשיר.

הכיתה android.net.wifi.MloLink מייצגת את הקישור ל-MLO. הכיתה הזו כוללת את הפרמטרים הבאים:

  • int getLinkId(): מזהה הקישור כפי שפורסם על ידי ה-MLD של AP.
  • MacAddress getApMacAddress(): כתובת ה-MAC של הנקודה לשיתוף אינטרנט. ה-BSSID של מכונה של נקודת הגישה לקישור הזה.
  • MacAddress getStaMacAddress(): כתובת ה-MAC של ה-STA. כתובת ה-MAC שהוקצתה באופן מקומי למכונה של STA בקישור.
  • int getChannel(): קישור הערוץ. מספר הערוץ של הקישור.
  • int getBand(): פס קישור. התדר של הקישור.
  • int getState(): מצב הקישור. יכול להיות אחד מהסטטוסים הבאים:

    • MLO_LINK_STATE_INVALID: לא תקף. משמשת לצורכי אתחול ולמקרים של שגיאות.
    • MLO_LINK_STATE_UNASSOCIATED: לא משויך. הקישור לא משויך לנקודת גישה.
    • MLO_LINK_STATE_IDLE: מצב המתנה. הקישור משויך אבל לא פעיל (לא ממופה לקישור מזהה תנועה (TID)).
    • MLO_LINK_STATE_ACTIVE: פעיל. הקישור משויך ופעיל (לפחות מזהה TID אחד ממופה לקישור). קישור פעיל יכול להיות במצב חיסכון בסוללה כי המסגרת לא עוקבת אחרי מצב האנרגיה של הקישור.

פרטי MLO של נקודת Wi-Fi 7 AP שנסרקה

אפליקציות יכולות לקבל את הפרמטרים של MLO ל-Wi-Fi 7 AP MLD כשמודול ה-Wi-Fi מקבל אובייקט ScanResult מה-AP-MLD. ב-AOSP, WifiTracker מציג את הפרמטרים של MLO כשהוא פועל במצב מפורט.

מודול ה-Wi-Fi אוסף את פרטי ה-MLO באופן הבא:

  • ניתוח רכיב המידע של כמה קישורים (IE) שכלול בתג ה-beacon או בתשובה לבדיקה, כדי לקרוא את כתובת ה-MAC של ה-MLD של הנקודה לשיתוף (AP) ואת מזהה הקישור הנוכחי.
  • ה-IE של דוח השכנים המופחת (RNR) שמצורף לתג ה-Beacon או לתשובה לבדיקה מנותח כדי לקרוא את רשימת הפרטים של הקישורים המשויכים.

ממשקי API

כדי לקבל מידע סרוק של MLO ב-AP, אפליקציות יכולות להשתמש בממשקי ה-API הבאים:

פרטי MLO של AP Wi-Fi 7 המחובר

כשמכשיר מתחבר ל-Wi-Fi 7 AP-MLD, המסגרת אוספת את הפרמטרים של ה-MLO של החיבור מהאובייקט WifiInfo. המידע הזה מוצג באובייקט WifiTracker של AOSP כשמריצים אותו במצב מפורט.

כשהמכשיר מתחבר ל-AP-MLD, מודול ה-Wi-Fi מעתיק את המידע של ה-MLO מהאובייקט ScanResult שמתקבל מה-AP. לאחר מכן, המודול קורא ל-HAL API‏ ISupplicantStaIface#getConnectionMloLinksInfo() כדי לקרוא את כתובות ה-MAC של כל קישור, גם ל-AP וגם ל-STA, ולעדכן את המצב של הקישורים המשויכים.

ממשקי API

כדי לקבל את פרטי החיבור ל-MLO, אפליקציות יכולות להשתמש בממשקי ה-API הבאים:

  • WifiInfo#getBSSID(): הפונקציה מחזירה את כתובת ה-MAC של מכשיר ה-AP (עבור הקישור שאליו המכשיר משויך).
  • MacAddress WifiInfo#getApMldMacAddress(): מחזירה את כתובת ה-MAC של MLD של הנקודה לשיתוף אינטרנט.
  • int WifiInfo#getApMloLinkId(): הפונקציה מחזירה את מזהה הקישור שאליו משויך ה-STA ב-AP.
  • List<MloLink> WifiInfo#getAffiliatedMloLinks(): הפונקציה מחזירה רשימה של אובייקטים מסוג MloLink לכל הקישורים שפורסמו על ידי AP-MLD, כולל הקישור המשויך. אפשר לשלוח שאילתה לגבי כתובות ה-MAC של AP ו-STA בכל אובייקט MloLink.

סריקת AP-MLD

תוכנת הספק מספקת למסגרת ה-Wi-Fi את תוצאות הסריקה של כל תשובה מאיתות או מבדיקה שהוא מקבל. כלומר, המסגרת של Wi-Fi:

  • יכול לקבל כמה אובייקטים מסוג ScanResults מאותו AP-MLD (כי ל-AP יכולים להיות כמה קישורי איתות).
  • יכול להיות שתתקבל רק קבוצה חלקית של תוצאות הסריקה של קישורי ה-AP של AP-MLD, כי יכול להיות שחלק מאותות הקישור האלה לא יתקבלו על ידי הקושחה.

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

תוכנת הספק חייבת לכלול את ה-IEs הבסיסיים של הקישור המרובה וה-RNR שהתקבלו ממכונות ה-AP בתוצאות הסריקה שדווחו. אם פרטי ה-AP המשויך חסרים בתוצאות הסריקה, תוכנת הספק יכולה לשלוח בקשות בדיקה עם כמה קישורים (מסגרת של בקשת בדיקה שכוללת רכיב של בקשת בדיקה עם כמה קישורים) כדי לכלול את הקבוצה המלאה או חלקית של היכולות, הפרמטרים ורכיבי הפעולה של ה-AP עם ה-AP-MLD המטורגט במסגרת התגובה.

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

שיוך רשתות של AP-MLD

כשמכשיר מצטרף לרשת AP-MLD, תוכנת הספק משתמשת בקישור ה-AP שנבחר (הקישור המשויך) לצורך איתות. תוכנת הספק יכולה לשייך את כל הקישורים או חלק מהם שנתמכים במכשיר.

אחרי ההתאמה, הנהג מדווח על ISupplicantStaIfaceCallback#onStateChanged() עם ה-BSSID של קישור ל-AP-MLD. לאחר מכן, הנהג בוחר קישור של AP-MLD, בתנאי שתוצאות הסריקה דווחו למסגרת של הקישור הזה.

דירוג רשתות

במכשירים עם Android מגרסה 14 ואילך, התכונה בחירת רשת Wi-Fi ב-Android תומכת ב-Wi-Fi 7 MLO. כלומר, מערכת Android בוחרת את רשת ה-Wi-Fi הטובה ביותר למכשיר על סמך מספר הקישורים שזמינים ל-MLO.

כדי לתמוך ב-MLO, אלגוריתם בחירת הרשת משתמש ביכולות ה-MLO הבאות שבצ'יפ ה-Wi-Fi:

  • מספר הקישורים המקסימלי ב-STR
  • מספר הקישורים המקסימלי של השיוך
  • שילובים של תדרים בו-זמנית

בחירת רשת Wi-Fi MLO

איור 2. בחירת רשת MLO.

העברה וקבלה בו-זמנית (STR) היא סכימה של תחרות על אמצעי תקשורת ב-Wi-Fi לפעולה במספר קישורים. בידוד האות בין קישורים שונים מספיק כדי שהקישורים יוכלו לפעול באופן עצמאי, ויש להם יכולת לשדר ולקלוט בו-זמנית בקישור שונה. STA עם תמיכה ב-STR שונה מ-STA מדור קודם עם קישור יחיד (SL) ומ-STA מדור קודם עם תמיכה בשני תדרים בו-זמנית (DBDC). STA שמשויך ל-STA MLD משתף מספר רצף משדר (SN) משותף ומרחב משותף לשידור נתונים שמוקצה לקישורים שונים, אם לשידור בכמה קישורים יש אותה קטגוריית גישה (AC).

המספר המקסימלי של קישורי STR שבהם נעשה שימוש עשוי להיות שונה מהמספר המקסימלי של מכשירי הרדיו הנתמכים על ידי הצ'יפ. בדוגמה שמוצגת באיור 2, מספר הקישורים המקסימלי של STR הוא 2.

ממשקי ה-HAL הבאים של AIDL תומכים במספר המקסימלי של קישורי STR ובמספר המקסימלי של קישורי שיוכים:

מספר קישורים יכולים לפעול ברדיו אחד באמצעות סכמת התחרות Enhanced Multi-Link Single Radio‏ (eMLSR). מכשיר עם כמה קישורים משתמש ב-eMLSR על קבוצת קישורים אם הוא יכול לקבל מסגרות בקרה בסיסיות מסוימות ולבצע הערכה של ערוץ נקי (CCA) בו-זמנית בקבוצת הקישורים. עם זאת, ה-MLD מעביר או מקבל נתונים בקישור אחד בלבד בכל פעם (הקישור שנבחר באופן דינמי בכל תקופת העברה (TXOP)).

תחנת MLD יכולה למקסם את מספר קישורי השיוך כדי לשפר את האמינות, את תעבורת הנתונים ואת זמן האחזור (בהשוואה לתחנה מדור קודם עם קישור יחיד), על ידי הפעלה בו-זמנית של STR ו-eMLSR, אם הצ'יפ תומך בכך. באיור 2, מספר קישורי השיוך המקסימלי הוא 3.

ממשקי ה-HAL הבאים של AIDL תומכים ביכולת של מספר המקסימום של קישורי השיוך:

שילובים של תדרים בו-זמנית

המסגרת שולחת שאילתה לצ'יפ כדי לקבל את שילובי הרדיו המותרים (דרך ממשק IWifiChip.aidl AIDL) שיכולים לפעול בו-זמנית. על סמך המידע הזה, המסגרת מפיקה שילובים אפשריים של תדרים בו-זמנית. בהמשך מופיעה רשימת דוגמאות לשילובי תדרים בו-זמניים (GHz):

  • 2.4
  • 5
  • 6
  • 2.4 x 5
  • 2.4 x 6
  • 5 x 6

ממשק ה-HAL הבא של AIDL תומך בשילובי רדיו בו-זמניים:

בחירת רשת

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

כשמצטרפים לרשת AP-MLD, המערכת מבצעת את בחירת ה-SSID על סמך המידע שמתקבל באובייקט ScanResults, כפי שדווח על ידי תוכנת הספק. אחרי שבמסגרת נבחרת SSID, תוכנת הספק אחראית לבחירת ה-BSSID של נקודת ה-AP (או הקישור לנקודת ה-AP) הטובה ביותר לשימוש לצורך שיוך.

טיפול בכתובת ה-MAC של STA במכשיר

בקטע הזה מוסבר איך מטפלים בכתובות MAC של STA במכשיר (כתובות MAC של MLD וכתובות MAC של STA לכל קישור).

כתובת MAC של MLD

מסגרת ה-Wi-Fi מנהלת את כתובת ה-MAC של MLD של המכשיר. הטיפול בכתובת ה-MAC של MLD זהה לטיפול בכתובת ה-MAC של מכשיר שאינו MLD. כתובת ה-MAC יכולה להיות כתובת MAC אקראית או כתובת MAC שהוקצתה לחומרה, בהתאם לבחירה של המשתמש. מסגרת ה-MLD מגדירה את כתובת ה-MAC באמצעות ה-HAL API‏ IWifiStaIface#setMacAddress().

תוכנת הספק מנהלת את כתובות ה-MAC של STA של המכונה (לכל קישור). כשמכשיר משויך לנקודת גישה, תוכנת הספק מקצה כתובת MAC של מכונה לכל קישור משויך.

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

  • כתובת ה-MAC של STA-MLD שמוגדרת על ידי מסגרת ה-Wi-Fi.
  • מזהה הקישור (מתקבל מה-AP)

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

בהמשך מופיע אלגוריתם לדוגמה להקצאת כתובת MAC של STA לכל קישור (הספקים יכולים להטמיע כל אלגוריתם שעונה על הקריטריונים של האלגוריתם):

  • אוקטט 0: מוודאים שהביט המנוהל באופן מקומי מוגדר
  • אוקטט 1-4: זהה לכתובת ה-MAC של STA-MLD
  • אוקטט 5: לכל STA = (STA-MLD + מזהה הקישור + 1) MOD (256)

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

מסגרת ה-Wi-Fi לא מצפה להתראה כשמצב הקישור משתנה.

ניהול מצב חיסכון באנרגיה

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

עם זאת, מסגרת ה-Wi-Fi יכולה לאלץ להשבית את מצב חיסכון הסוללה על ידי קריאה ל-ISupplicantStaIface::setPowerSave(false) HAL API. אם המערכת משביתה את מצב חיסכון האנרגיה, קושחת הקניין של הספק חייבת לשמור לפחות קישור אחד פעיל (חיסכון האנרגיה מושבת). במצב הזה, הטמעת הקושחה קובעת איזה קישור יוגדר.

נתיב הנתונים

כאן מתוארת ההטמעה של קושחת הספק לטיפול בתעבורת נתונים ב-uplink וב-download.

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

  • כשמצב זמן אחזור קצר מוגדר דרך IWifiChip#setLatencyMode() HAL API.
  • כשיש תנועה עם עדיפות משתמש 6 ו-7.

הקושחה צריכה להחליף את כתובת ה-MAC (יעד) לכל STA בכותרת ה-MAC בכתובת ה-MAC של MLD-STA, ואת כתובת ה-MAC (מקור) לכל AP בכותרת ה-MAC בכתובת ה-MAC של MLD-AP. הקושחה צריכה לבצע את החלפת כתובת ה-MAC הזו לפני שהיא עוברת דרך המסנן APF, כי לפקודות של מסנן ה-APF יש מסננים שמבוססים על כתובות MAC של MLD. יש מסנן APF אחד לכל הקישורים של AP-MLD.

בו-זמניות

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

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

במכשירים עם Android מגרסה 14 ואילך, כש-AP של Wi-Fi 7 מכריז על השבתה זמנית של אחד מהקישורים באמצעות רכיב מיפוי של TID לקישור שמשודר בפריימים של איתות, תגובת בדיקה ותגובת שיוך, תחנת Wi-Fi 7 ממשיכה את החיבור ל-AP באמצעות הקישורים הנותרים שהוגדרו, בלי לבצע שיוך נוסף.

במכשירים עם Android מגרסה 13 ומטה, מסגרת ה-Wi-Fi לא תומכת בקבלת התראות על שינוי במצב הקישור עקב מיפוי של מזהה TID לקישור, גם אם הקישור המשויך לא מקושר למזהה TID.

ה-supplicant של Wi-Fi מודיע למסגרת Wi-Fi על שינויים במיפוי של ה-TID לקישור באמצעות ממשקי ה-AIDL הבאים:

אפליקציות יכולות לקבל מידע על שינויים במיפוי של TID לקישור באמצעות ממשקי ה-API הבאים:

במכשירים עם Android מגרסה 14 ואילך, ממשקי ה-API הבאים זמינים כדי לקבל את יכולות המשא ומתן של המפה מ-TID לקישור לתחנה ול-AP.

יכולת הצ'יפ

הממשקים הבאים תומכים ביכולת של הצ'יפ לנהל משא ומתן על מיפוי של TID לקישור.

AIDL HAL

ממשק ה-AIDL למשא ומתן על מיפוי של TID לקישור נמצא ב-FeatureSetMask ב-hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl. היכולת T2LM_NEGOTIATION = 1 << 8 מציינת שהצ'יפ תומך במיפוי של TID לקישור. API

יכולת AP

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

AIDL HAL

המסגרת שולחת שאילתה למסוף ה-AP מהמגיש (supplicant) לגבי יכולת החיבור הנוכחית.

API

הנתונים הסטטיסטיים של שכבת הקישור כוללים פרטים ספציפיים לקישור Wi-Fi, כמו RSSI, ספירות שונות של חבילות TX ו-RX ונתונים סטטיסטיים של רדיו. מסגרת ה-Wi-Fi מבצעת מדי פעם סקרים של נתונים סטטיסטיים של שכבת הקישור ו-RSSI כדי לבחור את הרשת הטובה ביותר או כדי להעריך את האיכות של הרשת המקושרת. במכשירים עם Android מגרסה 14 ואילך, הנתונים הסטטיסטיים של שכבת הקישור כוללים תמיכה בכמה קישורים. כדי לתמוך ב-Wi-Fi 7, Android תומכת ב-MLO גם בנתונים הסטטיסטיים של שכבת הקישור וגם בסקרים של האות.

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

ממשק ה-API של המערכת android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() מקשיב לכל הנתונים הסטטיסטיים של שכבת הקישור. המסגרת מפעילה את ה-API הזה מדי פעם כדי לעדכן את הנתונים הסטטיסטיים של נוחות השימוש ב-Wi-Fi.

ממשקי ה-API הבאים שספציפיים לקישור זמינים ב-android.net.wifi.WifiUsabilityStatsEntry.

int getRssi(int linkId)
int getLinkState(int linkId)
int getRadioId(int linkId)
int getTxLinkSpeedMbps(int linkId)
long getTotalTxSuccess(int linkId)
long getTotalTxRetries(int linkId)
long getTotalTxBad(int linkId)
long getTotalRxSuccess(int linkId)
long getTotalBeaconRx(int linkId)
int getRxLinkSpeedMbps(int linkId)
int getTimeSliceDutyCycleInPercent(int linkId)
ContentionTimeStats getContentionTimeStats(int linkId, @WmeAccessCategory int ac)
List<RateStats> getRateStats(int linkId)

כדי לשלוח שאילתות לגבי מזהי הקישורים הזמינים, אפליקציות יכולות להפעיל את ה-method‏ android.net.wifi.WifiUsabilityStatsEntry#getLinkIds().

ממשקי API ב-android.net.wifi.WifiUsabilityStatsEntry עבור קישור יחיד (לא MLO) מחזירים את הנתונים הסטטיסטיים המצטברים של חיבורי MLO. אלה קריטריוני הצבירה:

  • בנתונים הסטטיסטיים המצטברים הבאים לגבי חבילות נעשה שימוש בסכום של הנתונים הסטטיסטיים לכל קישור:

    public long getTotalTxSuccess()
    public long getTotalTxRetries()
    public long getTotalTxBad()
    public long getTotalRxSuccess()
    public int getRxLinkSpeedMbps()
    
  • הנתונים הסטטיסטיים הבאים מבוססים על הנתונים מהקישור עם ערך ה-RSSI הגבוה ביותר:

    public int getRssi()
    public int getLinkSpeedMbps()
    public long getTotalBeaconRx()
    public int getTimeSliceDutyCycleInPercent()
    public ContentionTimeStats getContentionTimeStats(@WmeAccessCategory int ac)
    public List<RateStats> getRateStats()
    

במכשירים עם Android 13, הנתונים הסטטיסטיים של שכבת הקישור לא מביאים בחשבון שימוש בכמה קישורים לממשק יחיד. כדי לתמוך ב-MLO, תוכנת הספק חייבת להחיל את לוגיקת הצבירה הבאה כשמדווחים על LinkLayerStats דרך HAL API‏ IWifi# getLinkLayerStats_1_6(). הקישור הטוב ביותר הוא הקישור עם ערך ה-RSSI הגבוה ביותר.

  • StaLinkLayerStats.iface.beaconRx: דיווח על מספר הסמנים של הקישור הטוב ביותר שמשמש את הממשק.
  • StaLinkLayerStats.iface.avgRssiMgmt: דיווח avgRssiMgmt על הקישור הטוב ביותר שמשמש את הממשק.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, ‏ Vi, ‏ Be,‏ Bk): דיווח על נתונים סטטיסטיים מצטברים של חבילות (סה"כ) בקישורים של הממשק.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, ‏ Vi,‏ Be,‏ Bk): דיווח על הנתונים הסטטיסטיים של זמן התחרות של הקישור הטוב ביותר שנעשה בו שימוש בממשק (הנתונים הסטטיסטיים של זמן התחרות הנמוך ביותר).

כשאחד מהקישורים של נקודת הגישה ל-Wi-Fi 7 משמש למטרה אחרת, ה-AP יכול להודיע על הסרת הקישור באמצעות שינוי התצורה של הקישור ב-MLO. תחנות יכולות לשמור על קישוריות חלקה עם הנקודה לקישור נתונים (AP) בלי צורך באיחוד מחדש בקישורים הנותרים.

ממשק ה-AIDL‏ onMloLinksInfoChanged, שנמצא ב-supplicant של Wi-Fi ב-ISupplicantStaIfaceCallback.aidl, תומך בהגדרה מחדש של קישור (הסרת הקישור מה-AP).

כשמסגרת ה-Wi-Fi מעבדת את הסרת הקישור, מצב הקישור מוגדר ל-MLO_LINK_STATE_UNASSOCIATED. לאחר מכן, המסגרת מפעילה את ConnectivityManager.NetworkCallback#onCapabilitiesChanged() כדי לבדוק אם מצב הקישור השתנה.

השיטה WifiInfo#getAffiliatedMloLinks מחזירה את הקישורים של MLO המשויך. השיטה MloLink#getState מחזירה את המצב של הקישור. אם הקישור הוסר, מצב הקישור המוחזר הוא MLO_LINK_STATE_UNASSOCIATED.

אסטרטגיית MLO של שבב

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

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

  • MLO_MODE_DEFAULT = 0
  • MLO_MODE_LOW_LATENCY = 1
  • MLO_MODE_HIGH_THROUGHPUT = 2
  • MLO_MODE_LOW_POWER = 3

ה-framework משתמש ב-setMloMode בממשק AIDL של IWifiChip כדי להגדיר את מצב ה-MLO.