無線網路802.11 Frames-Part 4

802.11 Control Frames

8 min read1 day ago

802.11 控制幀(control frame)是 802.11 protocol中的一種幀，用於管理無線設備之間的通訊。

實際上，我們可以把它們想像成交通警察，指揮資料包的流動，並執行錯誤ˊ偵測、流量控制和AP同步等任務，控制幀中有欄位可以顯示正在執行的控制功能、傳輸需要多長時間，以及誰在發送和接收資料以及常見的控制幀，如 Ack(acknowledgment frame) 要求發送clear to send block Ack和 AP poll frames。

Ack(acknowledgment frame)

Ack 的子類型是 29。當我們透過無線網路傳送資料幀時，了解這些資料幀是否已被預期接收者收到非常重要，這時就要用 Ack 幀來確認這件事。Ack提供一種方法來驗證發送的資料幀的傳遞。Ack就是讓發送者知道資料已成功接收。

但並非所有的 Ack 幀都是相等的，在發送確認之前，接收方會檢查資料幀的 CRC，以確保它在傳輸過程中沒有被損壞。如果 CRC 校驗失敗，接收方不會發送Ack，因為它無法確認資料幀是否被正確接收。如果發送方在一定時間內沒有收到 Ack，則會假定資料幀在傳輸過程中遺失或損壞。因此在這種情況下，它會自動重新傳輸該幀以確保資料能夠傳輸。

Block ack(區塊確認)

我們已經知道unicast frame發送到一個端點，期望得到確認。但我們所做的也是發送一組資料幀並請求和接收對該組資料幀的確認。

當發送多個資料幀時，為每個資料幀發送確認幀實際上效率不高。因此，我們使用所謂的bar(block acknowledgement request)來確認收到whole block of frames。

所以，當我們傳送bar時，AP 會傳回一個區塊確認幀，告訴我們該幀已正確接收。這是使用bitmap完成的，bitmap就像一張小地圖，顯示已接收區塊的哪一部分。透過這樣做，可以避免重新傳輸已經正確接收的frames。這使得網路運作得更有效率，因為我們不會浪費大量的時間和資源來發送不必要的確認幀。

讓我們舉一個現實世界的例子。想像一下，我們正在透過 Wi-Fi 發送視訊通話，而不是為每一幀視訊發送一個確認幀，這會造成很大的overhead，我們可以使用block ack來確認收到整個視訊區塊一次可同時拍攝多幀。這意味著如果在傳輸過程中丟失了 1 或 2 個幀，我們只需重新傳輸這些特定的幀，而不是整個區塊。這讓得視訊通話更加順暢和有效率。因為我們不會在這些不必要的重傳上浪費大量的時間和資源。

PS Pool

PS pool frame是一種較舊的節能方法的一部分，但在某些情況下仍在使用。當我們發送poll frame時，我們基本上是在詢問 AP 是否有任何在裝置休眠期間時發送的幀在等待裝置，並確保 AP 知道哪個客戶端正在發出請求。客戶端將此association ID 包含在幀的duration ID 欄位中

舉例，我們在辦公室用筆電處理作業，我們有事需要離開座位一下，大約 5 到 10 分鐘後，筆電可能會進入修眠狀態以節省電力。同時，有人透過訊息應用程式向我們發送了電子郵件或訊息。因此，當我們喚醒筆電時，筆電會向 AP 發送一個輪詢幀，詢問是否有任何幀在等待它。如果有，AP 會將其發送到筆電，。

RTS/CTS(Request to send / Clear to send)

但在開始之前，我們需要定義一些術語。

NAV(network allocation vector)
NAV 是 802.11 無線設備使用的計時器(timer)，用於避免共享無線環境中的資料衝突。當一個設備傳輸一個幀並包含一個duration欄位，該欄位基本上指定了通道將忙多長時間時，接收該幀的其他設備將更新其NAV 計時器以反映duration欄位，因此它們不會在該時間內傳輸。這減少了發生碰撞(collision)的機會。
SIFTs(short interframe spacing)
SIFTs 是 802.11 無線裝置發送的兩個連續幀之間所需的最短時間。這是一段非常短的時間段，通常只有幾微秒，用於防止不同裝置發送的幀之間發生衝突。 SIFTs 用於幾種類型的幀，包括 ack 幀、CTS 幀和需要重傳的幀。

當兩個站點要傳輸資料時，需要先判斷頻道是否繁忙，以避免衝突。實體載波監聽(physical carrier sense)涉及監聽射頻訊號，但站點有可能能夠與 AP 通訊但無法互相聽到。這就是虛擬載波監聽(Virtual Carrier Sense)的發揮作用，它基於每個站的NAV timer。

因此，當此處的一個站點是另一個站點進行傳輸時，它會將其NAV timer設定為傳輸的持續時間，從而阻止其在計時器到期之前進行傳輸。這基本上就是review，但在某些站點無法互相聽到的情況下，虛擬載波監聽過程會變得不那麼可靠，而且更容易發生衝突。而這時就是使用RTS/CTS。

RTS/CTS 是一種執行 NAV 分發的機制，透過在資料傳輸之前保留介質(medium)來幫助防止衝突。

每當一個站點想要傳輸一幀時，它必須先執行 RTS/CTS exchnage，然後才能進行正常的資料傳輸。當發送站想要發送資料幀時，它首先發送一個 RTS 幀，其中包含幀交換(frame exchange)的完整持續時間，以及接收器地址-TA（即傳輸的預期接收者）和發送器地址-RA（即站點的地址）發送幀。

RTS 幀的持續時間值(duration value)會重設所有監聽站的NAV計時器，因此它們必須等到 CTS 資料和 Ack 幀傳輸完畢。然後，接收站（即 AP）發送 CTS，該 CTS 也用於 NAV distribution，並且 CTS 幀的值會重置所有監聽站的NAV timer，以便它們必須等待，直到資料和確認幀都已發送。

RTS 幀的持續時間值表示傳輸 CTS 資料和ack exchange加上三個SHIFTs intervals所需的時間（以微秒為單位）。當一個站點聽到 RTS 或 CTS 時，它將把NAV timer設置為提供的值，通過使用 CTS，基本服務集中的所有站點都應設置其NAV timer，並且站點應等到整個資料交換完成完全的。

因此，這有助於減少衝突的次數並提高無線網路的整體效率，在某些情況下會使用 RTS/CTS。

隱藏節點問題(hidden node problem)

所謂的隱藏節點問題(hidden node problem)如上圖，即兩個或多個客戶端點彼此超出範圍但卻在 AP 的範圍內，它們可能無法偵測到彼此的傳輸。這當然可能會導致衝突，而 RTS/CTS 機制則透過在傳輸期間保留介質來緩解該問題。

另一個是大資料幀(large data frames)，當一個站點想要發送一個大資料幀時，它需要將該幀分成多個小數據包來傳輸。但這同時也增加了與其他站點發生碰撞的可能性。RTS/CTS 用於在傳輸資料幀之前保留介質，以減少衝突的機會。

另一個是高錯誤率(High error rates)。在某些干擾程度較高的環境中，WiFi 的錯誤率可能很高，這會導致高重傳率，進一步增加衝突的可能性。採用RTS/CTS機制，透過在傳輸資料幀之前預留介質來減少重傳的次數。

CTS-To-Self

CTS-to-self 機制是一種在使用不同調變技術的混合環境中防止碰撞(Collision)的方法。

例如，802.11 b設備使用 DSS 調變(modulation)，而 802.11g 設備使用 ERP 或 OFDM 調變，由於這些設備使用不同的調變，它們格式是不通的，從而導致它們同時傳輸幀時發生衝突。

當新的 11g 設備想要傳輸資料時，它會發送一個 CTS 幀，而前面沒有 RTS 幀，此 CTS 幀使用傳統 11b 設備的調變技術發送，這有助於網路中的舊客戶端了解將有傳輸後，它們會停止下來並繼續等待輪到自己存取介質。

CTS-to-self 方法用於混合環境，因為它有助於避免碰撞。那麼，CTS-to-seif 在哪裡出現呢？來源位址通常是裝置本身的 Mac 位址，這表示裝置授予自己傳輸的權限。而目的位址也是設備本身的Mac位址。

這表明 CTS 幀用於自我接收，並且 CTS 幀本身是執行 NAV 分發的一種更簡單的方式。因此與 RTS/CTS 機制不同，只發送一幀，從而減少了開銷並節省了時間。

但這種方法也有風險，因為距離較遠的用戶端可能無法解碼 CTS 幀並設定其NAV timer。