עבור מכשירים עם אנדרואיד 13 ומעלה, אנדרואיד תומכת בתקן Wi-Fi 7 (IEEE 802.11be). דף זה מתאר תכונות של Android Wi-Fi 7, כולל תפעול בסיס והפעלה מרובה קישורים (MLO).
תכונות Wi-Fi 7 בסיסיות
סעיף זה מתאר תכונות Wi-Fi 7 הבסיסיות הכלולות ב-Android 13 ומעלה.
תמיכה ב-Wi-Fi 7 במכשיר
מסגרת האנדרואיד כוללת את ה-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, שקורא לפקודה nl80211NL80211_CMD_GET_WIPHY
. אם התכונהNL80211_BAND_IFTYPE_ATTR_EHT_CAP_PHY
נמצאת בתגובה מהנהג, ההנחה היא שהמכשיר תומך ב-Wi-Fi 7.
תמיכה ב-AP Wi-Fi 7 סרוקה
מסגרת האנדרואיד כוללת את ה-API int ScanResult#getWifiStandard()
, שאליו אפליקציות יכולות לקרוא כדי לבדוק אם נקודת גישה סרוקה (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
נמצא בתוצאות הסריקה, ה-AP הסרוק תומך ב-Wi-Fi 7. מחלקת AOSP WifiTracker
מציגה מידע תמיכה זה בממשק המשתמש כאשר היא פועלת במצב מילולי.
מצב חיבור STA
מסגרת האנדרואיד כוללת את ה-API int WifiInfo#getWifiStandard()
שאליו אפליקציות יכולות לקרוא כדי לבדוק אם מצב החיבור הנוכחי של התחנה (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
במהלך הגדרת החיבור.
בחירת רשת
באנדרואיד 13, בחירת הרשת משתמשת במספר פרמטרים כדי לקבוע לאיזה AP להתחבר. אחד הפרמטרים הוא התפוקה המשוערת של ה-AP, אשר נאמדת באמצעות בלוק ThroughputPredictor
. בלוק ThroughputPredictor
משתמש בפרמטרים של PHY הן של ההתקן והן של ה-AP הסרוק.
באנדרואיד 13, ThroughputPredictor
משתמש ביכולות ה-AP הבאות בחישוב שלו:
- תמיכה ב-Wi-Fi 7 (802.11be)
- תמיכה ברוחב ערוץ 320 מגה-הרץ
הכללת היכולות הללו בלוגיקת ThroughputPredictor
מגבירה את הסיכויים לבחירת APs עם Wi-Fi 7 כאשר המכשיר יכול לעשות שימוש בתכונות אלו.
טווח מבוסס Wi-Fi RTT
אנדרואיד מספקת תמיכה ב-API להקדמת EHT ורוחב ערוץ של 320 מגה-הרץ עבור Wi-Fi RTT . זה מאפשר תמיכה ביכולות הקשורות ל-Wi-Fi 7 בטווח RTT בכל פעם שהוא נתמך על ידי השבב.
ממשקי API של HAL
ממשקי ה-API של HAL הבאים תומכים ביכולות Wi-Fi 7 עבור טווח מבוסס RTT:
-
EHT
: קבוע ב-enum RttPreamble
ו-enum WifiRatePreamble
-
WIDTH_320
: קבוע ב-enum WifiChannelWidthInMhz
-
BW_320MHz
: קבוע ב-enum RttBw
ממשקי API
אפליקציות יכולות להשתמש בממשקי ה-API הבאים עבור טווחים מבוססי Wi-Fi 7 RTT:
-
ScanResult#PREAMBLE_EHT
-
ResponderConfig#PREAMBLE_EHT
(SystemApi)
AP רך
אנדרואיד תומך ב-Wi-Fi 7 ב-Soft AP ומספק את התכונות הבאות.
הפעל AP Soft
אנדרואיד תומך בהפעלת Soft AP במצב Wi-Fi 7. זה נשלט על ידי תצורת שכבת העל config_wifiSoftapIeee80211beSupported
.
מודול ה-Wi-Fi משתמש בשכבת-העל config_wifiSoftapIeee80211beSupported
כדי להגדיר את HwModeParams#enable80211BE
בוליאני בקריאה ל-API IHostApd#addAccessPoint()
. בשכבת hostapd AIDL, ערך זה משמש להגדרת הפרמטרים hostapd.conf
.
ממשקי API של HAL
ה-boolean enable80211BE
ב- HwModeParams
ב-hostapd HAL תומך בהפעלת Soft AP במצב Wi-Fi 7.
דווח על מידע AP רך
אנדרואיד כולל תמיכה ב-API כדי לכלול מידע על רוחב ערוץ Wi-Fi 7 ו-320 מגה-הרץ במידע המדווח על Soft AP.
ממשקי API של HAL
הקבוע WIFI_STANDARD_11BE
בממשק Generation.aidl
AIDL ב-hostapd HAL, המשמש ב- ApInfo
המדווח בהתקשרות חזרה של IHostapdCallback#onApInstanceInfoChanged()
, תומך בדיווח על מידע AP Soft.
ממשקי API
אפליקציות יכולות להשתמש בשיטות הבאות (ממשקי API של מערכת) ב- SoftApInfo
כדי לדווח על מידע AP Soft.
-
SoftApInfo#getWifiStandard()
: מחזירהScanResults.WIFI_STANDARD_11BE
אם ה-Soft AP מופעל במצב Wi-Fi 7. -
SoftApInfo#getBandwidth()
: מחזירהSoftApInfo#CHANNEL_WIDTH_320MHZ
אם נעשה שימוש ברוחב הערוץ של 320 מגה-הרץ.
תכונות MLO Wi-Fi 7
פעולה מרובת קישורים (MLO) היא התכונה העיקרית במפרט Wi-Fi 7 (802.11be). MLO היא תכונה חובה עבור התקני ריבוי קישורים (MLD) הפועלים ב-Wi-Fi 7, בין אם במקביל או לא במקביל.
איור 1. דיאגרמת MLO.
כפי שמוצג באיור 1, גם ל-AP-MLD וגם ל-STA-MLD יש מופעי AP או STA מרובים הפועלים בכל קישור. לכל קישור יש כתובת AP או STA MAC נפרדת. ל-AP או STA יש גם כתובת MLD MAC לזיהוי ההתקן.
ייצוג קישור MLO
המחלקה android.net.wifi.MloLink
מייצגת את הקישור 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. AOSP WifiTracker
מציג את פרמטרי ה-MLO כאשר הוא פועל במצב מילולי.
מודול ה-Wi-Fi אוסף את מידע ה-MLO על ידי ביצוע הפעולות הבאות:
- מנתח את אלמנט המידע הרב-קישורי (IE) הכלול בתגובת המשואה או הבדיקה כדי לקרוא את כתובת ה-AP MLD MAC ואת מזהה הקישור הנוכחי.
- מנתח את דוח השכנים המופחת (RNR) IE הכלול במשואה או בתגובת הבדיקה כדי לקרוא את רשימת המידע של הקישורים הקשורים.
ממשקי API
כדי לקבל מידע AP MLO סרוק, אפליקציות יכולות להשתמש בממשקי ה-API הבאים:
-
ScanResult#BSSID
: כתובת ה-MAC של מופע AP (עבור הקישור שבו מתקבלת תוצאת הסריקה) -
MacAddress ScanResult#getApMldMacAddress()
: מחזירה את כתובת ה-MAC MLD של ה-AP. -
int ScanResult#getApMloLinkId()
: מחזירה את מזהה הקישור עבור הקישור שבו התקבלה ScanResult. -
List<MloLink> ScanResult#getAffiliatedMloLinks()
: מחזירה רשימה של אובייקטיMloLink
עבור כל הקישורים המפורסמים על ידי ה-AP-MLD כולל הקישור שבו התקבלה ה-ScanResult.
מידע Wi-Fi 7 AP MLO מחובר
כאשר מכשיר מתחבר ל-Wi-Fi 7 AP-MLD, המסגרת אוספת את פרמטרי ה-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:
- עשוי לקבל אובייקטי
ScanResults
מרובים מאותו AP-MLD (מכיוון של-AP יכולים להיות מספר קישורי ביאוון). - עשוי לקבל רק קבוצה חלקית של תוצאות הסריקה עבור קישורי ה-AP של AP-MLD מכיוון שחלק מאותות הקישור הללו לא יתקבלו על ידי הקושחה.
התוכנה של הספק מדווחת רק על תוצאות סריקה שהתקבלו באוויר, ואסור ליצור (לסנתז באופן מלאכותי) תוצאות סריקה המבוססות על קישורים שפורסמו על ידי ה-AP-MLD.
תוכנת הספק חייבת לכלול את הגרסה הבסיסית של ריבוי קישורים ו-RNR IEs שהתקבלו ממופעי AP בתוצאות הסריקה המדווחות. אם חסרים פרטי AP משויכים בתוצאות הסריקה, תוכנת הספק יכולה לשלוח בקשות בדיקה מרובות קישורים (מסגרת בקשת בדיקה הכוללת רכיב ריבוי קישורים של בקשת בדיקה) כדי לכלול את הסט השלם או החלקי של היכולות, הפרמטרים ורכיבי הפעולה של ה-AP עם ה-AP-MLD הממוקד במסגרת התגובה.
תוכנת הספק יכולה להפעיל חיטוט ML (באמצעות גרסת בדיקה 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 מקסימלית
- ספירת קישורי שיוך מקסימלית
- שילובי להקות בו זמנית
איור 2. בחירת רשת MLO.
ספירת קישורי STR מקסימלית
שידור וקבלה בו-זמנית (STR) היא ערכת מחלוקת בינונית ב-Wi-Fi להפעלה מרובת קישורים. בידוד האותות בין קישורים שונים מספיק כדי שהקישורים יוכלו לפעול באופן עצמאי ויוכלו לשדר ולקבל בו זמנית בקישורים שונים. STR שונה מ-STA של קישור יחיד (SL) מדור קודם ומ-STA של דו-פס כפול (DBDC). STA המזוהים עם STA MLD חולקים מספר רצף משדר משותף (SN) ומרחב משותף להעברת נתונים המוקצה לקישורים שונים אם לשידור של מספר קישורים יש אותה קטגוריית גישה (AC).
המספר המרבי של קישורי STR בשימוש יכול להיות שונה מהמספר המרבי של מכשירי רדיו הנתמכים על ידי השבב. בדוגמה באיור 2, ספירת קישורי STR מקסימלית היא 2.
ממשקי ה-AIDL HAL הבאים תומכים ביכולות ספירת קישורי STR המקסימלית ובמספר המרבי של ספירת קישורי שיוך:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
ספירת קישורי שיוך מקסימלית
קישורים מרובים יכולים לפעול ברדיו יחיד באמצעות ערכת המחלוקת, Enhanced Multi-Link Single Radio (eMLSR). התקן מרובה קישורים משתמש ב-eMLSR על קבוצת קישורים אם הוא יכול לקבל מסגרות בקרה בסיסיות מסוימות ולבצע הערכת ערוצים ברורה (CCA) בו-זמנית על קבוצת הקישורים. עם זאת, ה-MLD משדר או מקבל נתונים על קישור אחד בלבד (הקישור שנבחר באופן דינמי בכל תקופת שידור (TXOP)) בכל פעם.
תחנת MLD יכולה למקסם את מספר קישורי השיוך לאמינות טובה יותר, תפוקה טובה יותר והשהייה נמוכה יותר (בהשוואה לתחנת קישור מדור קודם) על ידי פעולה במקביל ב-STR ו-eMLSR אם היא נתמכת על ידי השבב. באיור 2, ספירת קישורי השיוך המקסימלית היא 3.
ממשקי ה-AIDL HAL הבאים תומכים ביכולת ספירת קישורי השיוך המקסימלית:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
hardware/interfaces/wifi/aidl/android/hardware/wifi/WifiChipCapabilities.aidl
שילובי להקות בו זמנית
המסגרת מבקשת מהשבב לקבל את שילובי הרדיו המותרים (דרך ממשק IWifiChip.aidl
AIDL) שיכולים לפעול בו זמנית. ממידע זה, המסגרת גוזרת שילובים אפשריים של להקות בו-זמנית. להלן רשימה לדוגמה של שילובי פס בו זמנית (GHz):
- 2.4
- 5
- 6
- 2.4 x 5
- 2.4 x 6
- 5 x 6
ממשק ה-AIDL HAL הבא תומך בשילובי רדיו בו זמנית:
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
בחירת רשת
במהלך בחירת רשת (MLO), רשימת המועמדים מקובצת לפי חברים עם אותה כתובת MLD MAC. ציון התפוקה המרבי החזוי המרבי מחושב עבור כל קבוצה, בהתבסס על ספירת קישורי STR המקסימלית ושילובי פס בו זמנית הנתמכים על ידי השבב. אם המועמד מסוגל לריבוי קישורים והשבב תומך ב-STR, ציון התפוקה החזוי מוחלף בציון התפוקה המצופה מרובה קישורים. זה נותן דחיפה למועמדי MLO במהלך בחירת הרשת.
בעת הצטרפות לרשת AP-MLD, המסגרת מבצעת את בחירת ה-SSID על סמך מידע שהתקבל באובייקט ScanResults
כפי שדווח על ידי תוכנת הספק. עם בחירת SSID על ידי המסגרת, תוכנת הספק אחראית לבחירת ה-BSSID עבור ה-AP (או קישור ה-AP) הטוב ביותר לשימוש עבור שיוך.
טיפול בכתובת MAC של מכשיר STA
סעיף זה מתאר כיצד מטופלות בכתובות STA MAC של מכשיר (כתובות MLD MAC וכתובות STA MAC לכל קישור).
כתובת MAC של MLD
מסגרת ה-Wi-Fi מנהלת את כתובת ה-MAC MLD של המכשיר. כתובת ה-MAC של MLD מטופלת באותו אופן שבו התקן שאינו MLD מטפל בכתובת ה-MAC שלו. כתובת ה-MAC יכולה להיות כתובת MAC אקראית או כתובת MAC שהוענקה לחומרה על סמך בחירת המשתמש. כתובת ה-MAC של MLD נקבעת על ידי המסגרת באמצעות IWifiStaIface#setMacAddress()
HAL API.
כתובת MAC של STA לכל קישור
תוכנת הספק מנהלת כתובות STA MAC של מופע (עבור כל קישור). כאשר התקן משויך ל-AP, תוכנת הספק מקצה כתובת MAC למופע עבור כל קישור משויך.
תוכנת הספק מקצה כתובות MAC לכל קישור על סמך האלגוריתם שלה. האלגוריתם חייב להיות בר-חזרה ולהיות פונקציה של הדברים הבאים:
- כתובת MAC STA-MLD שנקבעה על ידי מסגרת ה-Wi-Fi.
- מזהה קישור (התקבל מ-AP)
המשמעות היא שאם המסגרת עושה שימוש חוזר באותה כתובת MLD MAC, על הספק לעשות שימוש חוזר באותן כתובות MAC המשויכות לכל מופע, ולהיפך. זה מבטיח שכאשר כתובת ה-STA-MLD שנוצרה על ידי המסגרת היא קבועה עבור SSID, כתובות ה-MAC לכל STA הן גם קבועות.
להלן אלגוריתם לדוגמה להקצאת כתובת MAC של STA לכל קישור (ספקים יכולים ליישם כל אלגוריתם העונה על קריטריוני האלגוריתם):
- אוקטט 0: ודא שהביט המנוהל באופן מקומי מוגדר
- אוקטט 1-4: זהה לכתובת MAC STA-MLD
- אוקטט 5: Per-STA = (STA-MLD + מזהה קישור + 1) MOD (256)
טיפול מרובה קישורים
הקושחה של הספק יכולה לבצע החלפת קישורים ולנהל את מצב חיסכון בחשמל של הקישורים להפעלה או ביטול ללא קלט ממסגרת ה-Wi-Fi.
מסגרת ה-Wi-Fi אינה מצפה להתראה כאשר מצב הקישור משתנה.
ניהול מצב חיסכון בחשמל
מצב חיסכון בחשמל מופעל כברירת מחדל במסגרת ה-Wi-Fi. במצב חיסכון בחשמל, הקושחה של הספק מנהלת את מצב חיסכון בחשמל של קישורים בודדים בהתבסס על דפוסי תעבורה והחלטות הפעלה או ביטול של קישורים.
עם זאת, מסגרת ה-Wi-Fi יכולה לכפות על השבתת מצב חיסכון בחשמל על ידי קריאה ל- ISupplicantStaIface::setPowerSave(false)
HAL API. אם מצב החיסכון בחשמל מושבת על ידי המסגרת, הקושחה של הספק חייבת לשמור על קישור אחד לפחות פעיל (חיסכון בחשמל מושבת). במצב זה, מימוש הקושחה מחליט איזה קישור מוגדר.
נתיב נתונים
זה מתאר את יישום הקושחה של הספק לטיפול ב-uplink והורדות.
תעבורת Uplink
הקושחה מנתבת תעבורת Uplink לקישור אחד (או יותר) בהתבסס על היישום הפנימי שלה. הקושחה של הספק מחליטה מתי לבצע איזון עומסים, שכפול או צבירה של תעבורה בהתבסס על דפוסי תעבורה. אנו ממליצים על תנועה כפולה של הקושחה למספר קישורים במקרים הבאים:
- כאשר מצב אחזור נמוך מוגדר דרך
IWifiChip#setLatencyMode()
HAL API. - כאשר יש תנועה עם עדיפות משתמש 6 ו-7.
תעבורה ב-Downlink
הקושחה חייבת להחליף את כתובת ה-MAC (היעד) של כותרת ה-MAC ב-MLD-STA MAC ואת כתובת ה-MAC לכל AP (המקור) של כותרת ה-MAC בכתובת ה-MAC של MLD-AP. הקושחה חייבת לבצע החלפת כתובת MAC זו לפני שהיא עוברת דרך מסנן APF מכיוון שלפקודות מסנן APF יש מסננים המבוססים על כתובות MLD MAC. יש מסנן APF יחיד עבור כל הקישורים של AP-MLD.
במקביל
תרחישי מקבילים, שבהם נעשה שימוש ברדיו עבור ממשק חדש, חייבות להיות עדיפות על פני הקדשת מכשירי רדיו מרובים לקישורים של אותו ממשק. גם תרחישי מקביל חייבים לקבל עדיפות על פני MLO לא משנה מה הגיע קודם. שימוש במספר קישורים עבור ממשק יחיד הוא אופורטוניסטי, כלומר משתמשים במספר קישורים רק כאשר:
- MLO נדרש בהתבסס על החלטת קושחה עבור איזון עומסים, צבירה או שכפול.
- MLO זמין , כלומר רדיו אינו נדרש על ידי ממשק אחר.
מיפוי TID לקישור
למכשירים המריצים אנדרואיד 14 ומעלה, כאשר ה-Wi-Fi 7 AP מכריז על השבתה זמנית של אחד הקישורים באמצעות רכיב מיפוי TID-to-link המשודר במסגרות תגובת משואה, בדיקה ושיוך, ה-Wi-Fi 7 התחנה ממשיכה את הקשר עם ה-AP באמצעות הקישורים הנותרים שהוגדרו, מבלי לבצע שיוך נוסף.
עבור מכשירים עם אנדרואיד 13 ומטה, מסגרת ה-Wi-Fi אינה תומכת בקבלת הודעות כאשר מצב הקישור משתנה עקב מיפוי TID-to-link, גם אם הקישור המשויך אינו מקושר ל-TID.
AIDL HAL
מבקש ה-Wi-Fi מודיע למסגרת ה-Wi-Fi על שינויים במיפוי TID-to-link דרך ממשקי ה-AIDL הבאים:
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIfaceCallback.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/ISupplicantStaIface.aidl
hardware/interfaces/wifi/supplicant/aidl/android/hardware/wifi/supplicant/MloLinksInfo.aidl
ממשקי API
אפליקציות יכולות לקבל מידע על שינויים במיפוי TID-to-link באמצעות ממשקי ה-API הבאים:
-
ConnectivityManager.NetworkCallback.onCapabilitiesChanged()
: התקשרות חוזרת לרשת המופעלת על ידי המסגרת כאשר יש שינוי במיפוי TID לקישור. -
WifiInfo#getAssociatedMloLinks()
: מחזירה את קישורי ה-MLO המשויכים. -
MloLink#getState()
: מחזירה את מצב הקישור,MLO_LINK_STATE_ACTIVE
אוMLO_LINK_STATE_IDLE
.
יכולות משא ומתן למיפוי TID-to-link
עבור מכשירים המריצים אנדרואיד 14 ומעלה, ממשקי ה-API הבאים זמינים כדי לקבל את יכולות המשא ומתן על מפת TID-to-link עבור התחנה וה-AP.
יכולת שבב
הממשקים הבאים תומכים ביכולת השבבים למשא ומתן על מיפוי TID-to-link.
AIDL HAL
ממשק ה-AIDL למשא ומתן על מיפוי TID-to-link נמצא ב- FeatureSetMask
hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl
. היכולת T2LM_NEGOTIATION = 1 << 8
מצביעה על כך שהשבב תומך במיפוי TID-to-link. ממשקי API
-
WifiManager.isTidToLinkMappingNegotiationSupported()
: מחזירה את השבב התומך במשא ומתן על מיפוי TID-to-link.
יכולת AP
הממשקים הבאים תומכים ביכולת AP למשא ומתן על מיפוי TID-to-link.
AIDL HAL
המסגרת שוללת את יכולת ה-AP מהמבקש יחד עם יכולת החיבור הנוכחית.
-
apTidToLinkMapNegotiationSupported
: בודק אם AP תומך ביכולת המשא ומתן של מפת TID-to-link.
ממשקי API
-
WifiInfo.isApTidToLinkMappingNegotiationSupported()
: מחזירה אם AP תומך במשא ומתן על מיפוי TID-to-link.
נתונים סטטיסטיים של שכבת קישור
נתונים סטטיסטיים של שכבת קישור כוללים פרטים ספציפיים לקישור Wi-Fi כגון RSSI, מוני מנות TX ו-RX שונים וסטטיסטיקות רדיו. מסגרת ה-Wi-Fi סוקרת מעת לעת נתונים סטטיסטיים של שכבת קישור ו-RSSI כדי לבחור את הרשת הטובה ביותר או להעריך את איכות הרשת המחוברת. עבור מכשירים עם אנדרואיד 14 ומעלה, הנתונים הסטטיסטיים של שכבת קישורים כוללים תמיכה בריבוי קישורים. כדי לתמוך ב-Wi-Fi 7, אנדרואיד תומכת ב-MLO גם בסטטיסטיקה של שכבת קישור וגם בסקר אותות.
נתונים סטטיסטיים ספציפיים לקישור נמצאים בממשקי AIDL של שכבת הקישור הבאים:
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerIfaceStats.aidl
-
hardware/interfaces/wifi/aidl/android/hardware/wifi/StaLinkLayerLinkStats.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()
נתונים סטטיסטיים של שכבת קישור באנדרואיד 13
עבור מכשירים שבהם פועל אנדרואיד 13, סטטיסטיקת שכבת קישורים אינה לוקחת בחשבון את השימוש במספר קישורים עבור ממשק יחיד. כדי לתמוך ב-MLO, תוכנת הספק חייבת ליישם את לוגיקת הצבירה הבאה בעת דיווח על LinkLayerStats
דרך IWifi# getLinkLayerStats_1_6()
HAL API. הקישור הטוב ביותר הוא הקישור עם ה-RSSI הגבוה ביותר.
-
StaLinkLayerStats.iface.beaconRx
: דווח על ספירת המשואות עבור הקישור הטוב ביותר המשמש עבור הממשק. -
StaLinkLayerStats.iface.avgRssiMgmt
: דווח עלavgRssiMgmt
עבור הקישור הטוב ביותר המשמש עבור הממשק. -
StaLinkLayerStats.iface.wmeXxPktStats
(Xx = Vo, Vi, Be,Bk): דווח על סטטיסטיקת המנות המצטברת (סה"כ) על פני הקישורים של הממשק. -
StaLinkLayerStats.iface.wmeXxContentionTimeStats
(Xx = Vo, Vi, Be,Bk): דווח על הנתונים הסטטיסטיים של זמן המחלוקת עבור הקישור הטוב ביותר בשימוש בממשק (הסטטיסטיקה הנמוכה ביותר של זמן המחלוקת).
תצורה מחדש של קישור MLO
כאשר אחד מהקישורים של נקודת הגישה ל-Wi-Fi 7 נעשה מחדש, ה-AP יכול להכריז על הסרת הקישור באמצעות תצורה מחדש של קישור MLO. תחנות יכולות לשמור על קישוריות חלקה עם ה-AP ללא שיוך מחדש בקישורים הנותרים.
ממשק ה- onMloLinksInfoChanged
AIDL, הממוקם במתחם ה-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
המסגרת משתמשת setMloMode
בממשק IWifiChip
AIDL כדי להגדיר את מצב MLO.