Wi-Fi 7

במכשירים עם Android 13 ואילך, מערכת Android תומכת בתקן Wi-Fi 7 ‏ (IEEE 802.11be). בדף הזה מתוארות התכונות של Wi-Fi 7 ב-Android, כולל פעולת קו בסיס ופעולה מרובת קישורים (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 NL80211_CMD_GET_WIPHY. אם המאפיין NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY מופיע בתשובה מהדרייבר, המכשיר נחשב כתומך ב-Wi-Fi 7.

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

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

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

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

בחירת רשת

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

ב-Android 13, ‏ ThroughputPredictor משתמש ביכולות הבאות של AP בחישוב שלו:

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

הכללת היכולות האלה בלוגיקה של ThroughputPredictor מגדילה את הסיכוי לבחירת נקודות גישה עם תמיכה ב-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 ומספק את התכונות הבאות.

הפעלת נקודת גישה וירטואלית

מערכת 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.

דיווח מידע על נקודות גישה וירטואליות

מערכת Android כוללת תמיכה ב-API כדי לכלול מידע על Wi-Fi 7 ועל רוחב פס של ערוץ 320 MHz במידע על נקודת הגישה הווירטואלית (Soft AP) שמדווחת.

ממשקי HAL API

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

ממשקי API

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

תכונות MLO Wi-Fi 7

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

תרשים MLO

איור 1. תרשים MLO.

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

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

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

  • ‫int getState(): מצב הקישור. יכול להיות אחד מהסטטוסים הבאים:

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

מידע על נקודות גישה (AP) של Wi-Fi 7 MLO שנסרקו

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

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

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

ממשקי API

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

מידע על נקודת גישה (AP) עם חיבור Wi-Fi 7 MLO

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

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

ממשקי API

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

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

סריקת AP-MLD

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

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

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

תוכנת הספק צריכה לכלול את רכיבי המידע (IE) של RNR ואת רכיבי המידע של multi-link של הגרסה הבסיסית שהתקבלו ממופעי ה-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 עבור פעולה רב-קישורית. בידוד האותות בין הקישורים השונים מספיק כדי שהקישורים יוכלו לפעול באופן עצמאי, וכדי שיוכלו לשדר ולקבל בו-זמנית בקישורים שונים. ה-STR שונה מ-STA מסוג SL (קישור יחיד) מדור קודם ומ-STA מסוג DBDC (פס כפול, שידור בו-זמני) מדור קודם. ל-STA שמשויכים ל-STA MLD יש מספר סידורי (SN) משותף של משדר ומרחב משותף לשידור נתונים שמוקצה לקישורים שונים אם לשידור של כמה קישורים יש אותה קטגוריית גישה (AC).

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

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

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

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

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

שילובים בו-זמניים של ערוצים

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

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

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

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

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

נתיב הנתונים

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

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

  • כשמגדירים מצב זמן טעינה קצר דרך 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 מודיעה על השבתה זמנית של אחד הקישורים דרך רכיב מיפוי של TID לקישור שמועבר בפריים של beacon, probe response ו-association response, תחנת Wi-Fi 7 ממשיכה את החיבור לנקודת הגישה באמצעות הקישורים שנותרו שהוגדרו, בלי לבצע שיוך נוסף.

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

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

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

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

יכולות הצ'יפ

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

AIDL HAL

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

יכולת של חשבון תשלומים

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

AIDL HAL

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

‫APIs

הנתונים הסטטיסטיים של שכבת הקישור כוללים פרטים ספציפיים לקישור 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)

כדי לשלוח שאילתה לגבי מזהי קישורים זמינים, אפליקציות יכולות להפעיל את השיטה 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 דרך IWifi# getLinkLayerStats_1_6() HAL API. הקישור הטוב ביותר הוא הקישור עם ה-RSSI הגבוה ביותר.

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

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

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

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

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

אסטרטגיית Chip 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 בממשק IWifiChip AIDL כדי להגדיר את מצב ה-MLO.