وای فای 7

برای دستگاه‌هایی که اندروید ۱۳ یا بالاتر را اجرا می‌کنند، اندروید از استاندارد Wi-Fi 7 (IEEE 802.11be) پشتیبانی می‌کند. این صفحه ویژگی‌های Wi-Fi 7 اندروید، از جمله عملکرد پایه و چند لینکی (MLO) را شرح می‌دهد.

ویژگی‌های پایه وای‌فای ۷

این بخش ویژگی‌های پایه Wi-Fi 7 موجود در اندروید ۱۳ و بالاتر را شرح می‌دهد.

پشتیبانی دستگاه از وای‌فای ۷

چارچوب اندروید شامل API WifiManager#isWifiStandardSupported(int standard) است که برنامه‌ها می‌توانند آن را با آرگومان ScanResults.WIFI_STANDARD_11BE فراخوانی کنند تا بررسی کنند که آیا دستگاهی از Wi-Fi 7 پشتیبانی می‌کند یا خیر.

وقتی این API فراخوانی می‌شود، ماژول Wi-Fi بررسی می‌کند که آیا از پوشش پیکربندی config_wifi11beSupportOverride به عنوان یک override استفاده شده است یا خیر و سپس اقدامات زیر را انجام می‌دهد:

  • اگر overlay روی true تنظیم شده باشد، فرض می‌شود که دستگاه صرف نظر از پاسخ nl80211 از Wi-Fi 7 پشتیبانی می‌کند. این تغییر فقط برای تولیدکنندگان دستگاهی مفید است که درایورهایی ندارند که پشتیبانی از Wi-Fi 7 را برگردانند.
  • اگر overlay روی 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() است که برنامه‌ها می‌توانند آن را برای بررسی اینکه آیا یک نقطه دسترسی (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 در نتایج اسکن باشد، AP اسکن شده از Wi-Fi 7 پشتیبانی می‌کند. کلاس AOSP WifiTracker این اطلاعات پشتیبانی را هنگام اجرا در حالت verbose در رابط کاربری نمایش می‌دهد.

حالت اتصال STA

چارچوب اندروید شامل 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 در لایه wpa_supplicant AIDL بررسی می‌کند که آیا EHT Capability IE در طول تنظیم اتصال در هر دو AssocReq و AssocRsp قرار دارد یا خیر.

انتخاب شبکه

در اندروید ۱۳، انتخاب شبکه از چندین پارامتر برای تعیین اینکه به کدام AP متصل شود استفاده می‌کند. یکی از پارامترها، توان عملیاتی تخمینی AP است که با استفاده از بلوک ThroughputPredictor تخمین زده می‌شود. بلوک ThroughputPredictor از پارامترهای PHY هم برای دستگاه و هم برای AP اسکن شده استفاده می‌کند.

در اندروید ۱۳، ThroughputPredictor از قابلیت‌های AP زیر در محاسبات خود استفاده می‌کند:

  • پشتیبانی از وای‌فای ۷ (۸۰۲.۱۱be)
  • پشتیبانی از پهنای کانال ۳۲۰ مگاهرتز

گنجاندن این قابلیت‌ها در منطق ThroughputPredictor شانس انتخاب اکسس‌پوینت‌های سازگار با Wi-Fi 7 را افزایش می‌دهد، زمانی که دستگاه بتواند از این ویژگی‌ها استفاده کند.

مسافت‌یابی مبتنی بر Wi-Fi RTT

اندروید پشتیبانی API برای پیش‌نیاز EHT و پهنای کانال ۳۲۰ مگاهرتز برای Wi-Fi RTT را ارائه می‌دهد. این امر پشتیبانی از قابلیت‌های مرتبط با Wi-Fi 7 را در محدوده RTT، هر زمان که توسط تراشه پشتیبانی شود، امکان‌پذیر می‌سازد.

رابط‌های برنامه‌نویسی کاربردی (API) هال

API های HAL زیر از قابلیت‌های Wi-Fi 7 برای مسافت‌یابی مبتنی بر RTT پشتیبانی می‌کنند:

رابط‌های برنامه‌نویسی کاربردی (API)

برنامه‌ها می‌توانند از APIهای زیر برای مسافت‌یابی مبتنی بر Wi-Fi 7 RTT استفاده کنند:

نرم افزار AP

اندروید از Wi-Fi 7 در Soft AP پشتیبانی می‌کند و ویژگی‌های زیر را ارائه می‌دهد.

شروع نرم افزار AP

اندروید از راه‌اندازی Soft AP در حالت Wi-Fi 7 پشتیبانی می‌کند. این موضوع توسط پیکربندی config_wifiSoftapIeee80211beSupported overlay مدیریت می‌شود.

ماژول Wi-Fi از لایه config_wifiSoftapIeee80211beSupported برای تنظیم مقدار بولی HwModeParams#enable80211BE در فراخوانی API IHostApd#addAccessPoint() استفاده می‌کند. در لایه hostapd AIDL، این مقدار برای تنظیم پارامترهای hostapd.conf استفاده می‌شود.

رابط‌های برنامه‌نویسی کاربردی (API) هال

مقدار بولی enable80211BE در HwModeParams در hostapd HAL از شروع Soft AP در حالت Wi-Fi 7 پشتیبانی می‌کند.

گزارش اطلاعات Soft AP

اندروید از API پشتیبانی می‌کند تا اطلاعات مربوط به پهنای کانال Wi-Fi 7 و 320 مگاهرتز را در اطلاعات Soft AP گزارش‌شده بگنجاند.

رابط‌های برنامه‌نویسی کاربردی (API) هال

ثابت WIFI_STANDARD_11BE در رابط Generation.aidl AIDL در hostapd HAL، که در ApInfo گزارش شده در فراخوانی IHostapdCallback#onApInstanceInfoChanged() استفاده می‌شود، از گزارش اطلاعات Soft AP پشتیبانی می‌کند.

رابط‌های برنامه‌نویسی کاربردی (API)

برنامه‌ها می‌توانند از روش‌های زیر (APIهای سیستم) در SoftApInfo برای گزارش اطلاعات Soft AP استفاده کنند.

ویژگی‌های وای‌فای ۷ MLO

عملیات چند لینکی (MLO) ویژگی اصلی در مشخصات Wi-Fi 7 (802.11be) است. MLO یک ویژگی اجباری برای دستگاه‌های چند لینکی (MLD) است که در Wi-Fi 7 اجرا می‌شوند، چه به صورت همزمان و چه غیر همزمان.

نموداری که عملیات چند پیوندی (MLO) را نشان می‌دهد که در آن هم AP-MLD (دستگاه چند پیوندی نقطه دسترسی) و هم STA-MLD (دستگاه چند پیوندی ایستگاه) چندین نمونه در حال اجرا روی لینک‌های مختلف دارند که هر کدام دارای یک آدرس MAC جداگانه و یک آدرس MAC MLD برای شناسایی دستگاه هستند.

شکل ۱. نمودار MLO.

همانطور که در شکل 1 نشان داده شده است، هر دو AP-MLD و STA-MLD دارای چندین نمونه AP یا STA هستند که روی هر لینک اجرا می‌شوند. هر لینک یک آدرس MAC AP یا STA جداگانه دارد. AP یا STA همچنین دارای یک آدرس MAC MLD برای شناسایی دستگاه است.

کلاس android.net.wifi.MloLink لینک MLO را نشان می‌دهد. این کلاس شامل پارامترهای زیر است:

  • int getLinkId() : شناسه لینک که توسط AP MLD اعلام شده است.
  • MacAddress getApMacAddress() : آدرس مک نقطه دسترسی (AP). شناسه استاندارد (BSSID) مربوط به آن لینک.
  • MacAddress getStaMacAddress() . آدرس مک اختصاص داده شده به صورت محلی برای نمونه ایستگاه روی لینک.
  • 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 را هنگام اجرا در حالت verbose نمایش می‌دهد.

ماژول Wi-Fi اطلاعات MLO را با انجام موارد زیر جمع‌آوری می‌کند:

  • عنصر اطلاعات چند لینکی (IE) موجود در پاسخ بیکن یا کاوشگر را تجزیه می‌کند تا آدرس MAC مربوط به AP MLD و شناسه لینک فعلی را بخواند.
  • گزارش همسایه کاهش‌یافته (RNR) IE موجود در پاسخ beacon یا probe را تجزیه و تحلیل می‌کند تا لیست اطلاعات لینک‌های وابسته را بخواند.

رابط‌های برنامه‌نویسی کاربردی (API)

برای دریافت اطلاعات AP MLO اسکن شده، برنامه‌ها می‌توانند از API های زیر استفاده کنند:

  • ScanResult#BSSID : آدرس MAC نمونه AP (برای لینکی که نتیجه اسکن از طریق آن دریافت می‌شود)
  • MacAddress ScanResult#getApMldMacAddress() : آدرس MAC مربوط به نقطه دسترسی (AP) را برمی‌گرداند.
  • int ScanResult#getApMloLinkId() شناسه لینکی را که ScanResult از طریق آن دریافت شده است، برمی‌گرداند.
  • List<MloLink> ScanResult#getAffiliatedMloLinks() : فهرستی از اشیاء MloLink را برای تمام لینک‌های اعلام‌شده توسط AP-MLD، از جمله لینکی که ScanResult از طریق آن دریافت شده است، برمی‌گرداند.

اطلاعات MLO مربوط به Wi-Fi 7 AP متصل

وقتی دستگاهی به یک Wi-Fi 7 AP-MLD متصل می‌شود، این چارچوب پارامترهای MLO اتصال را از شیء WifiInfo جمع‌آوری می‌کند. شیء AOSP WifiTracker این اطلاعات را هنگام اجرا در حالت verbose نمایش می‌دهد.

وقتی دستگاه به AP-MLD متصل می‌شود، ماژول Wi-Fi اطلاعات MLO را از شیء ScanResult دریافتی از AP ​​کپی می‌کند. سپس ماژول، رابط برنامه‌نویسی کاربردی HAL با نام ISupplicantStaIface#getConnectionMloLinksInfo() را فراخوانی می‌کند تا آدرس‌های MAC هر لینک را برای AP و STA بخواند و وضعیت لینک‌های مرتبط را به‌روزرسانی کند.

رابط‌های برنامه‌نویسی کاربردی (API)

برای دریافت اطلاعات اتصال MLO، برنامه‌ها می‌توانند از API های زیر استفاده کنند:

  • WifiInfo#getBSSID() : آدرس MAC نمونه AP (برای لینکی که دستگاه به آن متصل است) را برمی‌گرداند.
  • MacAddress WifiInfo#getApMldMacAddress() : آدرس MAC مربوط به نقطه دسترسی (AP) را برمی‌گرداند.
  • 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 می‌تواند چندین لینک Beaconing داشته باشد.
  • ممکن است فقط بخشی از نتایج اسکن برای لینک‌های AP یک AP-MLD را دریافت کند، زیرا ممکن است برخی از این سیگنال‌های لینک توسط میان‌افزار دریافت نشوند.

نرم‌افزار فروشنده فقط نتایج اسکن دریافتی از طریق بی‌سیم را گزارش می‌دهد و نباید نتایج اسکن را بر اساس لینک‌های تبلیغ‌شده توسط AP-MLD ایجاد کند (به‌طور مصنوعی ترکیب کند).

نرم‌افزار فروشنده باید انواع پایه‌ی multi-link و RNR IE های دریافتی از نمونه‌های AP را در نتایج اسکن گزارش‌شده لحاظ کند. اگر جزئیات AP وابسته در نتایج اسکن وجود نداشته باشد، نرم‌افزار فروشنده می‌تواند درخواست‌های کاوش چند لینکی (فریم درخواست کاوش که شامل یک عنصر چند لینکی درخواست کاوش است) را ارسال کند تا مجموعه‌ی کامل یا جزئی از قابلیت‌ها، پارامترها و عناصر عملیاتی AP را با AP-MLD هدف در فریم پاسخ لحاظ کند.

نرم‌افزار فروشنده می‌تواند در صورت لزوم، کاوش یادگیری ماشینی (ML-probing) را (با استفاده از نوع درخواست کاوش ML IE در فریم درخواست کاوش) آغاز کند.

انجمن شبکه AP-MLD

وقتی یک دستگاه به یک شبکه AP-MLD متصل می‌شود، نرم‌افزار فروشنده از لینک AP انتخاب‌شده (لینک مرتبط) برای سیگنال‌دهی استفاده می‌کند. نرم‌افزار فروشنده می‌تواند به تمام یا برخی از لینک‌هایی که توسط دستگاه پشتیبانی می‌شوند، متصل شود.

پس از اتصال موفقیت‌آمیز، درایور ISupplicantStaIfaceCallback#onStateChanged() را به همراه BSSID لینکی برای AP-MLD گزارش می‌دهد. سپس درایور لینکی از AP-MLD را انتخاب می‌کند، مشروط بر اینکه نتایج اسکن برای آن لینک به فریم‌ورک گزارش شده باشد.

امتیازدهی شبکه

برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، Android Wi-Fi Network Selection از Wi-Fi 7 MLO پشتیبانی می‌کند. این بدان معناست که اندروید بر اساس تعداد لینک‌های موجود برای MLO، بهترین شبکه Wi-Fi را برای دستگاه انتخاب می‌کند.

برای پشتیبانی از MLO، الگوریتم انتخاب شبکه از قابلیت‌های MLO زیر از تراشه Wi-Fi استفاده می‌کند:

  • حداکثر تعداد لینک‌های STR
  • حداکثر تعداد پیوندهای ارتباطی
  • ترکیب همزمان باندها

نموداری که فرآیند انتخاب شبکه Wi-Fi MLO را نشان می‌دهد، که در آن یک دستگاه چندین لینک Wi-Fi را در باندهای مختلف (2.4 گیگاهرتز، 5 گیگاهرتز، 6 گیگاهرتز) برای اتصال بهینه بر اساس قابلیت‌های تراشه مانند حداکثر تعداد لینک STR، حداکثر تعداد لینک‌های ارتباطی و ترکیب‌های باند همزمان در نظر می‌گیرد.

شکل 2. انتخاب شبکه MLO.

ارسال و دریافت همزمان (STR) یک طرح رقابت رسانه Wi-Fi برای عملیات چند لینکی است. جداسازی سیگنال بین لینک‌های مختلف به اندازه‌ای است که لینک‌ها بتوانند به طور مستقل عمل کنند و قادر به ارسال و دریافت همزمان در لینک‌های مختلف باشند. STR با STA تک لینک (SL) قدیمی و STA همزمان دوگانه باند دوگانه (DBDC) قدیمی متفاوت است. STAهای وابسته به یک STA MLD یک شماره ترتیب فرستنده (SN) مشترک و یک فضای مشترک برای انتقال داده اختصاص داده شده به لینک‌های مختلف را به اشتراک می‌گذارند، اگر انتقال چندین لینک دارای دسته دسترسی (AC) یکسان باشند.

حداکثر تعداد لینک‌های STR مورد استفاده می‌تواند با حداکثر تعداد رادیوهای پشتیبانی شده توسط تراشه متفاوت باشد. در مثال شکل ۲، حداکثر تعداد لینک STR برابر با ۲ است.

رابط‌های AIDL HAL زیر از حداکثر تعداد لینک STR و حداکثر تعداد قابلیت‌های تعداد لینک‌های ارتباطی پشتیبانی می‌کنند:

چندین لینک می‌توانند با استفاده از طرح رقابت، رادیوی تک لینکی پیشرفته (eMLSR)، روی یک رادیوی واحد کار کنند. یک دستگاه چند لینکی در صورتی از eMLSR روی مجموعه‌ای از لینک‌ها استفاده می‌کند که بتواند فریم‌های کنترلی پایه خاصی را دریافت کند و ارزیابی کانال شفاف (CCA) را به طور همزمان روی مجموعه‌ای از لینک‌ها انجام دهد. با این حال، MLD داده‌ها را فقط روی یک لینک (لینکی که به صورت پویا در هر دوره فرصت ارسال (TXOP) انتخاب می‌شود) در یک زمان ارسال یا دریافت می‌کند.

یک ایستگاه MLD می‌تواند با عملکرد همزمان در STR و eMLSR در صورت پشتیبانی تراشه، تعداد لینک‌های ارتباطی را برای قابلیت اطمینان بهتر، توان عملیاتی بهتر و تأخیر کمتر (در مقایسه با یک ایستگاه قدیمی تک لینک) به حداکثر برساند. در شکل 2، حداکثر تعداد لینک‌های ارتباطی 3 است.

رابط‌های AIDL HAL زیر از حداکثر قابلیت تعداد لینک‌های ارتباطی پشتیبانی می‌کنند:

ترکیب همزمان باندها

این چارچوب از تراشه درخواست می‌کند تا ترکیبات رادیویی مجاز (از طریق رابط IWifiChip.aidl AIDL) را که می‌توانند همزمان کار کنند، دریافت کند. از این اطلاعات، چارچوب ترکیبات باند همزمان ممکن را استخراج می‌کند. در زیر لیستی از ترکیبات باند همزمان (گیگاهرتز) به عنوان مثال آمده است:

  • ۲.۴
  • ۵
  • ۶
  • ۲.۴ × ۵
  • ۲.۴ در ۶
  • ۵ در ۶

رابط AIDL HAL زیر از ترکیب‌های رادیویی همزمان پشتیبانی می‌کند:

انتخاب شبکه

در طول انتخاب شبکه (MLO)، فهرست نامزدها بر اساس اعضایی با آدرس MAC MLD یکسان گروه‌بندی می‌شود. حداکثر امتیاز پیش‌بینی‌شده‌ی توان عملیاتی چند لینکی برای هر گروه، بر اساس حداکثر تعداد لینک STR و ترکیب‌های باند همزمان پشتیبانی‌شده توسط تراشه محاسبه می‌شود. اگر نامزد قابلیت چند لینکی داشته باشد و تراشه از STR پشتیبانی کند، امتیاز توان عملیاتی پیش‌بینی‌شده با امتیاز توان عملیاتی پیش‌بینی‌شده‌ی چند لینکی جایگزین می‌شود. این امر باعث افزایش شانس نامزدهای MLO در طول انتخاب شبکه می‌شود.

هنگام اتصال به یک شبکه AP-MLD، این چارچوب انتخاب SSID را بر اساس اطلاعات دریافتی در شیء ScanResults که توسط نرم‌افزار فروشنده گزارش شده است، انجام می‌دهد. پس از انتخاب SSID توسط چارچوب، نرم‌افزار فروشنده مسئول انتخاب BSSID برای بهترین AP (یا لینک AP) برای استفاده در ارتباط است.

مدیریت آدرس MAC دستگاه STA

این بخش نحوه مدیریت آدرس‌های MAC STA دستگاه (آدرس‌های MAC MLD و آدرس‌های MAC STA به ازای هر لینک) را شرح می‌دهد.

آدرس مک MLD

چارچوب Wi-Fi، آدرس MAC MLD دستگاه را مدیریت می‌کند. آدرس MAC MLD به همان روشی مدیریت می‌شود که یک دستگاه غیر MLD آدرس MAC خود را مدیریت می‌کند. آدرس MAC می‌تواند یک آدرس MAC تصادفی یا یک آدرس MAC ارائه شده توسط سخت‌افزار بر اساس انتخاب کاربر باشد. آدرس MAC MLD توسط چارچوب با استفاده از IWifiStaIface#setMacAddress() HAL API تنظیم می‌شود.

نرم‌افزار فروشنده، آدرس‌های MAC نمونه STA (برای هر لینک) را مدیریت می‌کند. هنگامی که یک دستگاه با یک AP مرتبط می‌شود، نرم‌افزار فروشنده یک آدرس MAC نمونه برای هر لینک مرتبط اختصاص می‌دهد.

نرم‌افزار فروشنده، آدرس‌های MAC را بر اساس الگوریتم خود به ازای هر لینک اختصاص می‌دهد. این الگوریتم باید قابل تکرار باشد و تابعی از موارد زیر باشد:

  • آدرس MAC STA-MLD که توسط چارچوب Wi-Fi تنظیم شده است.
  • شناسه پیوند (دریافت شده از AP)

این بدان معناست که اگر چارچوب از همان آدرس MAC MLD استفاده مجدد کند، فروشنده باید از همان آدرس‌های MAC مرتبط به ازای هر نمونه استفاده مجدد کند، و اگر فروشنده از آدرس‌های MAC به ازای هر نمونه استفاده مجدد کند، چارچوب باید از همان آدرس MAC MLD استفاده مجدد کند. این امر تأیید می‌کند که وقتی آدرس STA-MLD تولید شده توسط چارچوب برای یک SSID پایدار است، آدرس‌های MAC به ازای هر STA نیز پایدار هستند.

در زیر یک الگوریتم نمونه برای تخصیص آدرس MAC به ازای هر لینک STA آمده است (فروشندگان می‌توانند هر الگوریتمی را که معیارهای الگوریتم را برآورده کند، پیاده‌سازی کنند):

  • اکتت ۰: مطمئن شوید که بیت مدیریت‌شده‌ی محلی تنظیم شده است
  • اکتت ۱-۴: مشابه آدرس مک STA-MLD
  • Octet 5: Per-STA = (STA-MLD + شناسه پیوند + 1) MOD (256)

سیستم عامل فروشنده می‌تواند بدون نیاز به ورودی از چارچوب Wi-Fi، سوئیچینگ لینک را انجام داده و وضعیت صرفه‌جویی در مصرف برق لینک‌ها را برای فعال یا غیرفعال کردن مدیریت کند.

چارچوب Wi-Fi انتظار ندارد هنگام تغییر وضعیت لینک، اعلانی ارسال شود.

مدیریت وضعیت صرفه‌جویی در مصرف برق

حالت صرفه‌جویی در مصرف برق به طور پیش‌فرض در چارچوب Wi-Fi فعال است. در حالت صرفه‌جویی در مصرف برق، میان‌افزار فروشنده، حالت صرفه‌جویی در مصرف برق هر لینک را بر اساس الگوهای ترافیک و تصمیمات فعال یا غیرفعال کردن لینک مدیریت می‌کند.

با این حال، چارچوب Wi-Fi می‌تواند با فراخوانی ISupplicantStaIface::setPowerSave(false) HAL API، حالت صرفه‌جویی در مصرف برق را غیرفعال کند. اگر حالت صرفه‌جویی در مصرف برق توسط چارچوب غیرفعال شود، میان‌افزار فروشنده باید حداقل یک لینک را فعال نگه دارد (صرفه‌جویی در مصرف برق غیرفعال باشد). در این حالت، پیاده‌سازی میان‌افزار تصمیم می‌گیرد که کدام لینک تنظیم شود.

مسیر داده

این، پیاده‌سازی میان‌افزار فروشنده را برای مدیریت ترافیک آپ‌لینک و دانلود توصیف می‌کند.

این میان‌افزار، ترافیک آپ‌لینک را بر اساس پیاده‌سازی داخلی خود به یک (یا چند) لینک هدایت می‌کند. میان‌افزار فروشنده، بر اساس الگوهای ترافیک، تصمیم می‌گیرد که چه زمانی تعادل بار، تکثیر یا تجمیع ترافیک را انجام دهد. توصیه می‌کنیم در موارد زیر، میان‌افزار، ترافیک را به چندین لینک تکثیر کند:

  • وقتی حالت تأخیر کم از طریق رابط برنامه‌نویسی کاربردی HAL IWifiChip#setLatencyMode() تنظیم می‌شود.
  • وقتی ترافیکی با اولویت کاربری ۶ و ۷ وجود دارد.

فریمور باید آدرس MAC (مقصد) به ازای هر STA از هدر MAC را با MAC MLD-STA و آدرس MAC (منبع) به ازای هر AP از هدر MAC را با آدرس MAC MLD-AP جایگزین کند. فریمور باید این جایگزینی آدرس MAC را قبل از عبور از فیلتر APF انجام دهد زیرا دستورات فیلتر APF فیلترهایی بر اساس آدرس‌های MAC MLD دارند. برای همه لینک‌های یک AP-MLD یک فیلتر APF واحد وجود دارد.

همزمانی

سناریوهای همزمانی، که در آن از یک رادیو برای یک رابط جدید استفاده می‌شود، باید نسبت به اختصاص چندین رادیو برای لینک‌های همان رابط اولویت داشته باشند. سناریوهای همزمانی همچنین باید نسبت به MLO اولویت داشته باشند، صرف نظر از اینکه کدام یک اول آمده است. استفاده از چندین لینک برای یک رابط واحد، فرصت‌طلبانه است، به این معنی که چندین لینک فقط زمانی استفاده می‌شوند که:

  • MLO بر اساس تصمیم میان‌افزار برای متعادل‌سازی بار، تجمیع یا تکثیر مورد نیاز است .
  • MLO در دسترس است ، به این معنی که رابط دیگری به رادیو نیاز ندارد.

برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، هنگامی که نقطه دسترسی Wi-Fi 7 از طریق یک عنصر نگاشت TID به لینک که در فریم‌های beacon، probe response و association response ارسال می‌شود، غیرفعال شدن موقت یکی از لینک‌ها را اعلام می‌کند، ایستگاه Wi-Fi 7 با استفاده از لینک‌های باقی‌مانده که راه‌اندازی شده‌اند، بدون انجام اتصال دیگر، اتصال با نقطه دسترسی را ادامه می‌دهد.

برای دستگاه‌هایی که اندروید ۱۳ یا پایین‌تر دارند، چارچوب Wi-Fi به دلیل نگاشت TID به لینک، از دریافت اعلان‌ها برای تغییر وضعیت لینک پشتیبانی نمی‌کند، حتی اگر لینک مرتبط به TID متصل نباشد.

درخواست‌کننده‌ی وای‌فای، تغییرات نگاشت TID به لینک را از طریق رابط‌های AIDL زیر به چارچوب وای‌فای اطلاع می‌دهد:

برنامه‌ها می‌توانند با استفاده از APIهای زیر، اطلاعات مربوط به تغییرات نگاشت TID به لینک را دریافت کنند:

برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، APIهای زیر برای دریافت قابلیت‌های مذاکره نقشه TID-to-link برای ایستگاه و AP در دسترس هستند.

قابلیت تراشه

رابط‌های زیر از قابلیت تراشه برای مذاکره نگاشت TID به لینک پشتیبانی می‌کنند.

آیدل هال

رابط AIDL برای مذاکره نگاشت TID به لینک در FeatureSetMask در hardware/interfaces/wifi/aidl/android/hardware/wifi/IWifiChip.aidl قرار دارد. قابلیت T2LM_NEGOTIATION = 1 << 8 نشان می‌دهد که تراشه از نگاشت TID به لینک پشتیبانی می‌کند. APIها

قابلیت AP

رابط‌های زیر از قابلیت AP برای مذاکره نگاشت TID به لینک پشتیبانی می‌کنند.

آیدل هال

این چارچوب، قابلیت AP را به همراه قابلیت اتصال فعلی از درخواست‌کننده (supplicant) درخواست می‌کند.

  • apTidToLinkMapNegotiationSupported : بررسی می‌کند که آیا یک AP از قابلیت مذاکره نقشه TID-to-link پشتیبانی می‌کند یا خیر.

رابط‌های برنامه‌نویسی کاربردی (API)

آمار لایه پیوند شامل جزئیات خاص لینک وای‌فای مانند RSSI، شمارنده‌های مختلف بسته‌های TX و RX و آمار رادیویی است. چارچوب وای‌فای به‌طور دوره‌ای آمار لایه پیوند و RSSI را برای انتخاب بهترین شبکه یا ارزیابی کیفیت شبکه متصل، بررسی می‌کند. برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، آمار لایه پیوند شامل پشتیبانی از چند لینک است. برای پشتیبانی از وای‌فای ۷، اندروید از 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()

برای دستگاه‌هایی که اندروید ۱۳ را اجرا می‌کنند، آمار لایه پیوند، استفاده از چندین پیوند برای یک رابط واحد را در نظر نمی‌گیرد. برای پشتیبانی از MLO، نرم‌افزار فروشنده باید هنگام گزارش LinkLayerStats از طریق IWifi# getLinkLayerStats_1_6() HAL API، منطق تجمیع زیر را اعمال کند. بهترین پیوند، پیوندی با بالاترین RSSI است.

  • StaLinkLayerStats.iface.beaconRx : تعداد beaconهای بهترین لینک استفاده شده برای رابط را گزارش می‌دهد.
  • 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 حفظ کنند.

رابط 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 به دستگاه‌ها اجازه می‌دهد تا داده‌ها را همزمان روی چندین لینک وای‌فای ارسال و دریافت کنند، که می‌تواند عملکرد برنامه‌هایی را که نیازهای خاصی مانند تأخیر کم، پهنای باند بالا و مصرف انرژی کم دارند، بهبود بخشد. فروشندگان تراشه می‌توانند الگوریتم‌هایی را در مورد نحوه استفاده از لینک‌های موجود توسعه دهند.

برنامه‌های دارای امتیاز می‌توانند این الگوریتم‌ها را با استفاده از متد 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 استفاده می‌کند.