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 כוללת את WifiManager#isWifiStandardSupported(int standard) ל-API, שאליו האפליקציות יכולות לקרוא באמצעות 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 מבקש את המידע מ-Wi-Fi, שמתקשר פקודת nl80211 NL80211_CMD_GET_WIPHY. אם המאפיין NL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY נמצא בתשובה מנהל התקן, ההנחה היא שהמכשיר תומך ב-Wi-Fi 7.

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

המסגרת של Android כוללת את int ScanResult#getWifiStandard() API, האפליקציות יכולות לבצע קריאה כדי לבדוק אם נקודת גישה שנסרקה (AP) תומך ב-Wi-Fi 7. אם AP תומך ב-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 כוללת את int WifiInfo#getWifiStandard() API, לאפליקציות יכולות לבצע קריאה כדי לבדוק אם החיבור לתחנה הנוכחית (STA) הוא מצב Wi-Fi 7. מצב חיבור STA הוא Wi-Fi 7 כאשר המכשיר שה-AP המחובר תומך ב-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 להתחבר. אחד מהפרמטרים הוא התפוקה המשוערת של סוכנות AP, שההערכה היא באמצעות חסימה אחת (ThroughputPredictor). הבלוק ThroughputPredictor משתמש בפרמטרים PHY גם של המכשיר וגם של פרופיל AP שנסרק.

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

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

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

טווח מבוסס-Wi-Fi RTT

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

ממשקי API עם מערכת HAL

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

ממשקי API

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

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.

ממשקי API עם מערכת HAL

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

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

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

ממשקי API עם מערכת HAL

הקבוע WIFI_STANDARD_11BE בפונקציה Generation.aidl ב-hostapd HAL, שבו נעשה שימוש בApInfo שדווח בIHostapdCallback#onApInstanceInfoChanged() קריאה חוזרת (callback), תומכת בדיווח מידע על Soft AP.

ממשקי API

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

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

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

תרשים MLO

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

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

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

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

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

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

מידע על Wi-Fi 7 AP MLO שנסרק

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

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

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

ממשקי API

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

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

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

כשהמכשיר מתחבר ל-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 של ה-AP.
  • int WifiInfo#getApMloLinkId(): מחזירה את מזהה הקישור של הקישור שבו ה-STA משויך AP.
  • List<MloLink> WifiInfo#getAffiliatedMloLinks(): מחזירה רשימה של אובייקטים מסוג MloLink עבור כל הקישורים שמתפרסמים על ידי AP-MLD, כולל הקישור המשויך. כתובות AP ו-STA MAC יכולות תישלח שאילתה על כל אובייקט MloLink.

סריקת AP-MLD

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

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

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

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

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

שיוך רשת AP-MLD

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

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

דירוג רשת

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בחירת רשת

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

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

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

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

כתובת MAC של MLD

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

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

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

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

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

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

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

נתיב נתונים

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

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

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

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

בו-זמניות

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

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

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

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

ספק ה-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

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

AIDL HAL

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

ממשקי API

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

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

android.net.wifi.WifiManager#addOnWifiUsabilityStatsListener() System API מאזין לכל הנתונים הסטטיסטיים של שכבת הקישור. ה-framework מופעל מדי פעם ה-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: אפשר לדווח על מספר איתות Bluetooth כדי לקבל את התוצאות הטובות ביותר הקישור שמשמש את הממשק.
  • StaLinkLayerStats.iface.avgRssiMgmt: דיווח על avgRssiMgmt עקב הקישור הטוב ביותר לממשק.
  • StaLinkLayerStats.iface.wmeXxPktStats (Xx = Vo, Vi, Be,Bk): דיווח את הנתונים הסטטיסטיים המצטברים של המנות (סה"כ) בקישורים של הממשק.
  • StaLinkLayerStats.iface.wmeXxContentionTimeStats (Xx = Vo, Vi, Be,Bk): דיווח על הנתונים הסטטיסטיים לגבי זמן התחרות לקבלת הקישור הטוב ביותר שנעשה בו שימוש ממשק (נתונים סטטיסטיים על זמן הקרב הנמוך ביותר).

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

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

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

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

אסטרטגיית צ'יפ MLO

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

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

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

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