這些作業卸載的主要類別是可設定的。
- MSDU 層級接收作業
- 框架轉送 (轉送決策和動作)
- 通訊協定/工作卸載
以下是 RX 作業和卸載的清單。
| 函式 | 描述 | 擁有權 | 注意 |
|---|---|---|---|
解密 |
使用為傳送者指定的安全性類型和安全性金鑰，解密框架內容。 |
目標 |
在主機實作的 FIPS 模式中，解密會在主機軟體內完成。 系統會略過目標的解密。 |
A-MPDU deaggregation |
將 RX A-MPDU 分解成個別的 MPDU。 |
目標 |
|
A-MSDU deaggregation |
將 RX A-MSDU 分解成個別的 MSDU。 |
目標/TAL |
每個 RX MSDU 都會放在個別的緩衝區中。 |
MSDU 安全性解譯和取消 MIC |
針對涉及 MSDU 層級 MIC 的安全性類型，請確認收到的 MIC。 將安全性頁首和頁尾減去。 |
目標/TAL |
作業系統會視需要執行因應措施。 |
Rx decap |
使用初始 A-MSDU 子框架的 802.11 標頭取代非初始 A-MSDU 子框架標頭，並視需要使用初始 A-MSDU 子框架中的 802.11 標頭欄位。 |
目標/TAL |
在 A-MSDU 取消匯總期間，A-MSDU 的非初始 MSDU 需要其 802.3 標頭，以泛型 802.11 標頭取代。 WDI 一律需要 802.11 個標頭。 |
Rx 重新排序邏輯 |
針對每個 RX MPDU，判斷 Rx 重新排序陣列所在的位置。 判斷是否有一系列順序的框架存在。 判斷即使先前的畫面尚未到達，仍要釋放擱置的畫面格的時機。 |
目標/TAL |
|
Rx 捨棄邏輯 |
判斷需要捨棄哪些 Rx 畫面格：
|
目標/TAL 會做出所有捨棄決策。 |
|
Rx PN/重新執行檢查 |
確認每個 MPDU 都有大於先前 PN 的相異封包號碼。 |
這是必要且一律啟用卸載，但與重新排序佇列相關聯的資料流程和重新排序佇列管理並未完全卸載至目標。 |
|
Chatter 卸載 |
避免針對每個可延遲的「雜訊」Rx 畫面中斷主機。 相反地，將 Rx 雜訊畫面分組，並使用單一中斷來傳遞所有這類畫面。 |
目標 |
|
重組 |
將 802.11 片段重新組合成其原始 MSDU。 |
目標/TAL |
|
Rx 重新排序佇列 |
將順序錯亂的 Rx MPDU 儲存到流程中遺失的先前 MPDU 為止。 |
目標/TAL |
|
Rx 捨棄動作 |
根據目標上執行的 Rx 捨棄邏輯所標示的規格，捨棄 Rx 畫面格。 |
目標/TAL |
|
較高層級的通訊協定 (工作) 卸載 |
總和檢查碼 |
總和檢查碼：如有需要，可在開機時設定卸載。 |
總和檢查碼：目標會在啟動期間將其總和檢查碼卸載功能當做裝置上限的一部分傳遞至 WDI。 如需功能的相關資訊，請參閱 NDIS_TCP_IP_ CHECKSUM_OFFLOAD。 |
在 FIPS 模式Host-Implemented接收作業
在此模式中，目標可能會以 802.11 標頭或 802.3 標頭表示收到的畫面格。 在指示之前，不得解密框架。
如果捨棄邏輯卸載至目標，則如果它們符合下列任何準則，則必須標示已接收的框架以供捨棄。
- 具有不良 CRC 的框架。
- 重複的框架。
- 不符合已設定封包篩選準則的框架。
目標必須針對埠成功接收或捨棄的封包，遞增適當的 MAC 和 PHY 統計資料。
此外，如果卸載，目標必須執行捨棄動作。
當在主機實作 FIPS 模式中運作時，目標不應該從 RX 路徑上的 802.11 標頭移除 QoS 旗標。 目標應該會指出框架，而不需修改 QoS 標頭。
針對片段封包的情況，LE 針對 FIPS 模式回報的承載類型一律 會WDI_FRAME_MSDU_FRAGMENT ，因為主機正在執行重組程式。 不過，在非 FIPS 模式中，報告承載類型應該 WDI_FRAME_MSDU ，因為 Target/TAL 正在執行重組。