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. אם AP תומך ב-Wi-Fi 7, ה-API יחזיר את הערך ScanResults.WIFI_STANDARD_11BE. כדי שאפליקציות יוכלו להשתמש ב-API הזה, המכשיר לא חייב לתמוך ב-Wi-Fi 7.

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

מצב חיבור 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 קובע את המצב על ידי קריאה ל-ISupplicantStaIface#getConnectionCapabilities() HAL API. ההטמעה של HAL API הזה בשכבת ה-AIDL‏ wpa_supplicant בודקת אם EHT Capability IE נמצא גם ב-AssocReq וגם ב-AssocRsp במהלך הגדרת החיבור.

בחירת רשת

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

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

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

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

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

ב-Android יש תמיכה ב-API עבור קידומת EHT ורוחב ערוץ של 320MHz עבור 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(). בשכבת Hostapd AIDL, הערך הזה משמש להגדרת הפרמטרים hostapd.conf.

ממשקי HAL API

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

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

ב-Android יש תמיכה ב-API כדי לכלול מידע על רוחב הערוץ ב-Wi-Fi 7 ו-320MHz במידע שבדיווח ה-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 נפרדת או STA MAC. גם לנקודת הגישה או לנקודת הקצה יש כתובת 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 אחד ממופה לקישור). קישור פעיל יכול להיות במצב חיסכון בסוללה כי ה-framework לא עוקב אחרי מצב הטעינה של הקישור.

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

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

מודול ה-Wi-Fi אוסף את המידע על ה-MLO באמצעות הפעולות הבאות:

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

ממשקי API

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

מידע על Wi-Fi 7 AP MLO המחובר

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

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

ממשקי API

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

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

סריקת AP-MLD

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

  • ייתכן שיתקבלו כמה אובייקטים של ScanResults מאותו AP-MLD (כי ל-AP יכולים להיות כמה קישורים של איתות Bluetooth).
  • יכול להיות שתתקבל רק קבוצה חלקית של תוצאות הסריקה של קישורי ה-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 שהוקצתה לחומרה, בהתאם לבחירה של המשתמש. כתובת ה-MAC של MLD מוגדרת על ידי המסגרת באמצעות ה-HAL API‏ IWifiStaIface#setMacAddress().

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

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

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

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

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

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

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

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

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

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

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

נתיב הנתונים

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

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

  • כשמצב זמן אחזור קצר מוגדר דרך 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 ואילך, כש-Wi-Fi 7 AP מודיע על השבתה זמנית של אחד הקישורים באמצעות רכיב מיפוי TID לקישור שמשודר במסגרות של איתות Bluetooth, תגובת בדיקה ותגובה לשיוך, תחנת 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: מדווחים על מספר איתות Bluetooth כדי למצוא את הקישור הטוב ביותר לממשק.
  • 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() כדי לבדוק אם מצב הקישור השתנה.

ה-method 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.