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 ของ AP ที่สแกน

เฟรมเวิร์ก Android มี 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

เฟรมเวิร์ก 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)
  • รองรับแบนด์วิดท์ช่อง 320 MHz

การรวมความสามารถเหล่านี้ไว้ในตรรกะ ThroughputPredictor จะช่วยเพิ่มโอกาสในการเลือก AP ที่รองรับ Wi-Fi 7 เมื่ออุปกรณ์ใช้ฟีเจอร์เหล่านี้ได้

การวัดระยะทางตาม RTT ของ Wi-Fi

Android รองรับ API สำหรับคำนำหน้า EHT และแบนด์วิดท์ช่อง 320 MHz สำหรับ Wi-Fi RTT ซึ่งจะช่วยให้รองรับความสามารถที่เกี่ยวข้องกับ Wi-Fi 7 ในการวัดระยะ RTT ได้ทุกเมื่อที่ชิปรองรับ

HAL APIs

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() ในเลเยอร์ AIDL ของ hostapd ค่านี้จะใช้เพื่อตั้งค่าพารามิเตอร์ hostapd.conf

HAL APIs

enable80211BE บูลีนใน HwModeParams ใน hostapd HAL รองรับ การเริ่มต้น Soft AP ในโหมด Wi-Fi 7

รายงานข้อมูล Soft AP

Android มีการรองรับ API เพื่อรวมข้อมูล Wi-Fi 7 และความกว้างของช่อง 320 MHz ไว้ในข้อมูล Soft AP ที่รายงาน

HAL APIs

ค่าคงที่ WIFI_STANDARD_11BE ในอินเทอร์เฟซ Generation.aidl AIDL ใน HAL ของ hostapd ซึ่งใช้ ใน ApInfo ที่รายงานในแฮนเดิล IHostapdCallback#onApInstanceInfoChanged() callback รองรับการรายงานข้อมูล 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 ของ AP หรือ STA แยกกัน นอกจากนี้ AP หรือ STA ยังมีที่อยู่ MAC ของ MLD เพื่อระบุอุปกรณ์ด้วย

คลาส 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 อย่างน้อย 1 รายการกับลิงก์) ลิงก์ที่ใช้งานอยู่อาจอยู่ในโหมดประหยัดพลังงานเนื่องจากเฟรมเวิร์กไม่ได้ตรวจสอบสถานะพลังงานของลิงก์

ข้อมูล MLO ของ AP Wi-Fi 7 ที่สแกน

แอปจะรับพารามิเตอร์ MLO สำหรับ AP MLD ของ Wi-Fi 7 ได้เมื่อโมดูล Wi-Fi ได้รับออบเจ็กต์ ScanResult จาก AP-MLD AOSP WifiTracker จะแสดงพารามิเตอร์ MLO เมื่อ ทำงานในโหมด Verbose

โมดูล Wi-Fi จะรวบรวมข้อมูล MLO โดยทำดังนี้

  • แยกวิเคราะห์องค์ประกอบข้อมูล (IE) แบบหลายลิงก์ที่รวมอยู่ในบีคอนหรือการตอบกลับการตรวจสอบเพื่ออ่านที่อยู่ MAC ของ MLD ของ AP และรหัสลิงก์ปัจจุบัน
  • แยกวิเคราะห์ IE รายงานเพื่อนบ้านที่ลดลง (RNR) ที่รวมอยู่ในบีคอนหรือการตอบกลับการตรวจสอบ เพื่ออ่านรายการข้อมูลลิงก์ในเครือ

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

ข้อมูล MLO ของ AP Wi-Fi 7 ที่เชื่อมต่อ

เมื่ออุปกรณ์เชื่อมต่อกับ AP-MLD ของ Wi-Fi 7 เฟรมเวิร์กจะรวบรวม พารามิเตอร์ 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 รวมถึงลิงก์ที่เกี่ยวข้อง คุณสามารถค้นหาที่อยู่ MAC ของทั้ง AP และ STA ได้ในออบเจ็กต์ MloLink แต่ละรายการ

การสแกน AP-MLD

ซอฟต์แวร์ของผู้ให้บริการจะให้เฟรมเวิร์ก Wi-Fi พร้อมผลการสแกนสำหรับ แต่ละสัญญาณบีคอนหรือการตอบกลับการตรวจสอบที่ได้รับ ซึ่งหมายความว่าเฟรมเวิร์ก Wi-Fi มีลักษณะดังนี้

  • อาจได้รับออบเจ็กต์ ScanResults หลายรายการจาก AP-MLD เดียวกัน (เนื่องจาก AP อาจมีลิงก์การส่งสัญญาณหลายลิงก์)
  • อาจได้รับผลการสแกนสำหรับลิงก์ AP ของ AP-MLD เพียงบางส่วน เนื่องจากเฟิร์มแวร์อาจไม่ได้รับสัญญาณลิงก์บางรายการ

ซอฟต์แวร์ของผู้ให้บริการจะรายงานเฉพาะผลการสแกนที่ได้รับแบบไร้สาย และต้องไม่สร้าง (สังเคราะห์โดยเทียม) ผลการสแกนตามลิงก์ที่โฆษณาโดย AP-MLD

ซอฟต์แวร์ของผู้ให้บริการต้องมีลิงก์หลายรายการของตัวแปรพื้นฐานและ IE ของ RNR ที่ได้รับจากอินสแตนซ์ AP ในผลการสแกนที่รายงาน หากไม่มีรายละเอียด AP ที่เชื่อมโยงในผลการสแกน ซอฟต์แวร์ของผู้ให้บริการจะส่งคำขอ Probe แบบหลายลิงก์ (เฟรมคำขอ Probe ที่มีองค์ประกอบคำขอ Probe แบบหลายลิงก์) เพื่อรวมชุดความสามารถ พารามิเตอร์ และองค์ประกอบการทำงานของ AP ที่สมบูรณ์หรือบางส่วนกับ AP-MLD เป้าหมายในเฟรมการตอบกลับ

ซอฟต์แวร์ของผู้ให้บริการ สามารถทริกเกอร์การตรวจสอบ ML (ใช้ ML IE ที่เป็นตัวแปรของคำขอ Probe ในเฟรมคำขอ Probe) หากจำเป็น

การเชื่อมโยงเครือข่าย AP-MLD

เมื่ออุปกรณ์เข้าร่วมเครือข่าย AP-MLD ซอฟต์แวร์ของผู้ให้บริการจะใช้ AP link (ลิงก์ที่เชื่อมโยง) ที่เลือกสำหรับการส่งสัญญาณ ซอฟต์แวร์ของผู้ให้บริการสามารถ เชื่อมโยงกับลิงก์ทั้งหมดหรือบางลิงก์ที่อุปกรณ์รองรับ

เมื่อเชื่อมโยงสำเร็จ ไดรเวอร์จะรายงาน ISupplicantStaIfaceCallback#onStateChanged() พร้อม BSSID ของลิงก์สำหรับ AP-MLD จากนั้นไดรเวอร์จะเลือกลิงก์ของ AP-MLD โดยมีเงื่อนไขว่า มีการรายงานผลการสแกนไปยังเฟรมเวิร์กสำหรับลิงก์นั้น

การให้คะแนนเครือข่าย

สำหรับอุปกรณ์ที่ใช้ Android 14 ขึ้นไป การเลือกเครือข่าย Wi-Fi ของ Android รองรับ MLO ของ Wi-Fi 7 ซึ่งหมายความว่า Android จะเลือกเครือข่าย Wi-Fi ที่ดีที่สุดสำหรับอุปกรณ์โดยอิงตามจำนวนลิงก์ที่พร้อมใช้งานสำหรับ MLO

อัลกอริทึมการเลือกเครือข่ายจะใช้ความสามารถ MLO ต่อไปนี้จากชิป Wi-Fi เพื่อรองรับ MLO

  • จำนวนลิงก์ STR สูงสุด
  • จำนวนลิงก์การเชื่อมโยงสูงสุด
  • การรวมแบนด์พร้อมกัน

การเลือกเครือข่าย MLO ของ Wi-Fi

รูปที่ 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

อินเทอร์เฟซ AIDL HAL ต่อไปนี้รองรับการผสมผสานวิทยุพร้อมกัน

การเลือกเครือข่าย

ในระหว่างการเลือกเครือข่าย (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 ของอินสแตนซ์ (สำหรับแต่ละลิงก์) เมื่ออุปกรณ์เชื่อมโยงกับ AP ซอฟต์แวร์ของผู้ให้บริการจะกำหนดที่อยู่ MAC ของอินสแตนซ์ สำหรับลิงก์ที่เชื่อมโยงแต่ละลิงก์

ซอฟต์แวร์ของผู้ให้บริการจะกำหนดที่อยู่ MAC ต่อลิงก์ตามอัลกอริทึมของซอฟต์แวร์ อัลกอริทึมต้องทำซ้ำได้และเป็นฟังก์ชันของสิ่งต่อไปนี้

  • ชุดที่อยู่ MAC ของ STA-MLD ที่กำหนดโดยเฟรมเวิร์ก Wi-Fi
  • รหัสลิงก์ (ได้รับจาก AP)

ซึ่งหมายความว่าหากเฟรมเวิร์กใช้ที่อยู่ MAC ของ MLD เดียวกันซ้ำ ผู้ให้บริการ ต้องใช้ที่อยู่ MAC ต่ออินสแตนซ์ที่เชื่อมโยงเดียวกันซ้ำ และในทางกลับกัน ซึ่งจะรับประกันว่าเมื่อที่อยู่ STA-MLD ที่เฟรมเวิร์กสร้างขึ้นยังคงอยู่สำหรับ SSID ที่อยู่ MAC ต่อ STA ก็จะยังคงอยู่ด้วย

ต่อไปนี้คือตัวอย่างอัลกอริทึมสำหรับการกำหนดที่อยู่ MAC ของ STA ต่อลิงก์ (ผู้ให้บริการสามารถใช้อัลกอริทึมใดก็ได้ที่ตรงตามเกณฑ์ของอัลกอริทึม)

  • Octet 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 หากเฟรมเวิร์กปิดใช้สถานะประหยัดพลังงาน เฟิร์มแวร์ของผู้ให้บริการต้องเปิดลิงก์อย่างน้อย 1 ลิงก์ไว้ (ปิดใช้การประหยัดพลังงาน) ในสถานะนี้ การติดตั้งเฟิร์มแวร์ จะเป็นตัวกำหนดว่าจะตั้งค่าลิงก์ใด

เส้นทางของข้อมูล

ซึ่งอธิบายการติดตั้งใช้งานเฟิร์มแวร์ของผู้ให้บริการสำหรับการจัดการการรับส่งข้อมูลขาขึ้นและขาลง

เฟิร์มแวร์จะกำหนดเส้นทางการรับส่งข้อมูลขาขึ้นไปยังลิงก์อย่างน้อย 1 ลิงก์ตามการติดตั้งใช้งานภายใน เฟิร์มแวร์ของผู้ให้บริการจะตัดสินใจว่าจะทำ Load Balancing การทำซ้ำ หรือการรวบรวมการเข้าชมเมื่อใดโดยอิงตามรูปแบบการเข้าชม เราขอแนะนำให้เฟิร์มแวร์ทำซ้ำการรับส่งข้อมูลไปยังหลายลิงก์ในกรณีต่อไปนี้

  • เมื่อตั้งค่าโหมดค่าความหน่วงต่ำผ่าน 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 ขึ้นไป เมื่อ AP ของ Wi-Fi 7 ประกาศการปิดลิงก์ชั่วคราวผ่าน องค์ประกอบการแมป TID กับลิงก์ที่ส่งในเฟรมบีคอน การตอบกลับการตรวจสอบ และ การตอบกลับการเชื่อมโยง สถานี 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

อินเทอร์เฟซต่อไปนี้รองรับความสามารถของ AP สำหรับการเจรจาการเชื่อมโยง TID กับลิงก์

AIDL HAL

เฟรมเวิร์กจะค้นหาความสามารถของ AP จาก Supplicant พร้อมกับ ความสามารถในการเชื่อมต่อปัจจุบัน

  • apTidToLinkMapNegotiationSupported: ตรวจสอบว่า AP รองรับความสามารถในการเจรจาการแมป TID กับลิงก์หรือไม่

API

สถิติเลเยอร์ลิงก์ประกอบด้วยรายละเอียดเฉพาะลิงก์ Wi-Fi เช่น RSSI, ตัวนับแพ็กเก็ต TX และ RX ต่างๆ รวมถึงสถิติวิทยุ เฟรมเวิร์ก Wi-Fi จะสำรวจสถิติเลเยอร์ลิงก์และ RSSI เป็นระยะๆ เพื่อเลือกเครือข่ายที่ดีที่สุดหรือประเมินคุณภาพ ของเครือข่ายที่เชื่อมต่อ สำหรับอุปกรณ์ที่ใช้ Android 14 ขึ้นไป สถิติเลเยอร์ลิงก์จะรวมถึง การรองรับแบบหลายลิงก์ Android รองรับ MLO ทั้งในสถิติเลเยอร์ลิงก์และในการสำรวจสัญญาณเพื่อรองรับ Wi-Fi 7

สถิติเฉพาะลิงก์จะอยู่ในอินเทอร์เฟซ 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: รายงานจำนวนบีคอนสำหรับลิงก์ที่ดีที่สุด ที่ใช้สำหรับอินเทอร์เฟซ
  • 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 ซึ่งอยู่ใน Supplicant ของ 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 ในอินเทอร์เฟซ AIDL ของ IWifiChip เพื่อตั้งค่าโหมด MLO