WiFiCx 低延遲連線品質

如果有在系統上執行的應用程式需要低延遲資料流量， (例如 VoIP 應用程式) ，則可以針對低延遲模式作業設定埠。 在此作業模式中時，驅動程式應該修改任何行為 (，例如掃描或較佳的 AP 漫遊) ，導致它從針對低延遲模式設定的埠通道移出。 它也應該遵循 NDIS_STATUS_WDI_INDICATION_LINK_STATE_CHANGE指示的 指定指引。 主機會提供 WDI_TLV_LOW_LATENCY_CONNECTION_QUALITY_PARAMETERS 埠在此模式中時應該使用的埠。 這會指定埠應該關閉通道的時間上限，以及連線在起始低延遲漫遊 (之前必須下降的最低連結品質值，包括傳送 NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED) 。

針對掃描，主機會提供通道停留時間上限， (主動和被動通道有不同的值) ，而且介面卡不應超過最大時間。 主機也會節流不必要的掃描。 不過，如果 WDI_SCAN_TRIGGERWDI_SCAN_TRIGGER_BACKGROUND 或 WDI_SCAN_TRIGGER_ROAM，配接器可以進一步節流掃描。 如果介面卡在此模式中執行自己的掃描，建議您包含它正在尋找的 SSID (，除非它是在從睡眠恢復) 之後，以減少通道上的停留時間。 此外，它應該避免在單一離通道掃描中掃描多個通道，使其處於整體離路時間限制之下。

主機會考慮從介面卡 NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED 強式要求來漫遊，因此在此模式中，介面卡應該小心傳送此指示的頻率。 如果配接器執行自己的漫遊/AP 選取決策，則必須採用適當的機制 (，例如鄰近報表或 PMKID，) 尋找並選取/排名 AP。

若要優化關聯程式，配接器應該盡可能在聯結期間針對 TSF 計時器同步處理使用快取的 BSS 專案。 快取專案應該足以進行 TSF 計時器同步處理，因為從最近的探查要求取得它，所以最全新。 即使驅動程式決定挑選沒有最新快取探查回應的 AP，仍可稍後完成 TSF 同步處理。 驅動程式可以停用Wi-Fi電源節省，直到收到下一個指標為止，這通常會在 100 毫秒內發生。

在多通道並行模式中運作時，建議介面卡採用 ECSA 或其他機制，在執行通道多工處理時啟用無縫/無抖動體驗。