802.11協議精讀9：初探節能模式（PS mode）以及緩衝機制

標籤：

序言

由於802.11的協議工作機制，如果其一種處於工作狀態下，那麼能耗還是比較大的，尤其行動裝置的電量有限，所以在802.11協議初期就設計了相應的能耗管理機制，即引入了節能模式。本文我們主要討論一下其節能模式的一些基本思想和相應的組件。對於具體的MAC層工作機制，我們在後續的文章中在進行展開。

註：本文初始的意圖是描述在節能模式下具體的MAC層工作機制，不過後來在寫緩衝結構的時候，發現內容整理還是較多，所以進行分拆。故在本文中，我們主要描述了802.11協議中，節能的基本思想，以及其所添加的一些組件，具體的MAC協議之後再進行補充。

802.11協議中的能耗

為了理解802.11節能機制，我們首先需要梳理一下wifi中的一些所出現的能耗。通常情況下，802.11裝置一共會有4個工作狀態：

• Sleep（睡眠模式）：節點會關閉發送和接收模組進行休眠，從而能耗最低。
  
• Rx Idle（接收空閑狀態）：節點對通道進行監聽，但並未真實接收資料幀。
  
• Rx（接收狀態）：節點監聽到資料幀，並對其進行接收。
  
• Tx（發送狀態）：節點發送資料幀。
  

其中Rx Idle狀態，Rx狀態和Tx狀態的關係，需要從我們之前描述的發送/接收過程來理解。1）節點需要首先執行CCA，用以監聽通道中有沒有資料幀（主要是ED和CS兩個過程），這個過程即是Rx Idle狀態。Rx Idle狀態下面可以轉移至Rx狀態，也可以轉移至Tx狀態。2）若節點在監聽通道過程中，發現有802.11的資料幀，那麼其就轉移至Rx狀態進行接收。3）若節點本身有資料需要發送，且在持續監聽通道的過程中（即backoff過程中），發現通道是閒置，那麼其就轉移至Tx狀態進行發送。

在上述過程中，真正有用的只有Rx和Tx狀態。但是實際過程中，為了保證接受與發送中沒有衝突，節點需要長時間處於Rx Idle狀態，從而會消耗很多能量。一般意義上，Rx Idle狀態近似於Rx狀態，只是一個少了一些上層的邏輯處理工作，而能耗較大的RF模組，LNA，AGC這些都是同樣需要工作的。所以在802.11協議設計中，需要引入Sleep休眠狀態以代替Rx Idle狀態，達到節能的目的，進而擴充成了睡眠模式下的工作機制。

給出了一般wifi晶片中，這四種模式的功耗情況（參考《AR5213_Data_Sheet_0704》中第10.1.5 Power Consumption節）

該圖所描述的都是工作在802.11g的模式下，為了更好的描述主題，我們對原圖進行了一些裁剪，其餘工作模式的功耗還請查閱原文。分別列舉了AR5213這塊晶片，在1.8V的供電模式和3.3V的供電模式下，對應的不同的功耗。可以明顯看出，Sleep狀態和其他幾個狀態的功耗還是有很大差距的，從而節能模式如果設定的好，那麼的確可以達到一個很好的節能效果。

同時，只是給出了一個標準Tx的功率大小，在802.11中還存在transmit power levels參數，一般有8個層級，可以調節具體的Tx功率。同時在beacon幀中，也可能會添加Power Constraint element與Power Capability element這些參數，從而對該地區內的節點功率進行約束。這些都會影響具體的Tx功率大小，不過由於這些機制主要用於TPC（Transmit Power Control）機制，而本文討論主要是節能機制，所以就不展開了。

節能模式的基本思想

按照之前我們的敘述，在802.11中功耗最大的部分是在Rx Idle狀態。如果能夠減少Rx Idle狀態的期間，那麼節點就可以節能了。在本章節討論中，由於不討論具體的MAC機制，所以我們簡單假設一個拓撲，該拓撲僅包含一個AP和一個節點。節點上行發送都是發往AP的，下行是AP發往節點的。故從節點的角度而言，執行Rx Idle的目的則有兩種可能性：

• 如果節點是為了發送資料，那麼Rx Idle是用來監聽通道的，從而如果沒有資料發送，那麼就不進行監聽，從而就可以減少Rx Idle的期間了，這個還是很容易做到的。
• 如果節點是為了接收資料，那麼Rx Idle則一定需要長時間持續進行。因為作為接收方，節點無法知道AP什麼時候發送給自己的下行資料，所以要不斷的監聽通道，保持Rx Idle狀態，對於每一個資料包都不能漏。由於節點無法控制AP，所以這一塊是比較難做到的。
  

所以在802.11中就提供了一種被動請求機制，其主要就是提供了一種機制，讓節點可以控制AP，讓其發送對應的下行幀給自己。故在節能模式下，802.11協議中就引入了兩個機制：

• 緩衝機制：這裡緩衝的主要是AP發往節點的資料。當AP從外網接收到要轉寄給節點的資料後，會將以MSDU的形式（即MAC層的資料幀）進行緩衝（這裡僅僅對工作在節能模式下的節點資料進行緩衝），並不直接發送給節點。

• PS-Poll機制：若節點想要擷取下行資料，那麼節點需要主動跟AP請求資料，該請求幀就是PS-Poll幀。AP接收到該幀後，會檢查緩衝區是否有對應該節點的緩衝，如果有就會從緩衝區中調出對應該節點的快取資料，並進行下發，如果沒有則反饋一個NULL幀（既空資料）。有的書中，也將這個請求機制比較形象的描述為“兵乓”機制。

我們用大致描述下這裡其互動機制：

1. 由於AP已知節點工作在節能模式，所以其首先將發送給節點的資料進行緩衝。
2. 當工作在節能模式的節點wake-up後，其在完成競爭後，首先發送PS-Poll幀向AP請求下行資料幀。
   
3. AP從而就在自己的緩衝區裡面找該節點的快取資料。當找到對應資料幀後，通過Frame進行反饋，這裡可以看到標註了一個IEEE80211_FCTL_MOREDATA的描述，該參數實際上對應到無線資料包中的more data欄位，如果AP。
4. 如果節點識別到該more data欄位為1後，則知道AP中還有自己的快取資料，那麼會再次發送PS-Poll幀進行請求。
   
5. 直到AP反饋的Frame中的more data欄位為0，那麼節點就不會繼續反饋PS-Poll幀。該輪的資料請求就結束了，從而繼續sleep進行省電。

PS：簡單描述了節能模式的基本工作原理，其中我們省略了ACK的過程，以及在多節點情況下的具體工作機制，之後我們再進行補充。上述表述如果有錯誤的地方，還請見諒。

緩衝機制

這裡我們大致談論下AP對於下行資料的緩衝機制，首先筆者對這一塊也沒有完全的理順，尤其是協議與核心實現機制這一塊，貌似並不是完全按照協議的定義來實現的，所以這裡只是一些簡單的列舉。如有錯誤還請指出，以便將這一塊更加理順一些。

• 協議中對於緩衝機制的描述（參考802.11協議07/12版本）
  

在協議中，對於該buffer的描述還是較為複雜的。為了表述緩衝，我們首先要描述在802.11協議中，對於一個幀如何存放是怎麼定義的。在802.11協議中，資料幀的存放是通過FragSdu結構體進行存放的。（細節見07版協議第805-806頁）

在這一段中，我們按照標註的順序進行描述。

• 紅色部分的1，這個部分描述了這整個模組的功能，是用來描述一個分段支援類的。然後在這個類下面，定義了3個子模組（圖中只有2個，還有一個與節能模式有關所以放在後面描述）。
• 紅色部分的2，注釋表明說明，這裡定義了一個數組用來存放具體的資料幀的。
• 藍色部分的1，標識部分即是該FragArray數組的具體定義。
• 紅色部分的3，注釋了FragSdu的功能，實際上整個發送緩衝，無論是否有fragment都是按照FragSdu進行儲存的，該FragSdu在實現上具體就是一個結構體。雖然名字是用來定義分區的SDU的，但是其中也寫明了“Each SDU, even if not fragmented, is held in an instance of this structure awaiting its (re)transmission attempt(s).”，故即使該資料包沒有分區，那麼應該是按照FragSdu這種形式統一存放的。
• 藍色部分的2，在FragSdu結構體中，主要存放這個具體資料包中對應的很多的參數。這些參數包含一些資料幀中具體的控制欄位，我們以紫色方框的標註敘述其具體描述方法。在紫色方框這一行中，紫色1標註該變數名為psm，紫色2所標註變數類型是Boolean類型，紫色3所標註的欄位是注釋，標註該變數是描述該資料包是否發往節能模式下的節點的。在這一行表述中，如果該變數是1的話，那麼就標識這個資料包對應的接收節點是工作在節能模式，反之則不是。之前在紅色部分2所定義的FragArray數組，也是通過最後一行所定義的pdus參數，存放在FragSdu結構體中。
  

PS：因為本文是描述節能模式下的緩衝機制，所以就沒有對幀重組部分的進行展開，如果是幀重組的情況，那麼主要起作用的是FragNum類型的3個參數和SeqNum類型的1個參數。

每一個幀是通過FragSdu來存放的，對於多個幀，在802.11協議中實際上是以一個隊列進行存放，該隊列即是SduQueue。在802.11協議中，發送緩衝以及用來節能模式下的發送緩衝都是一個隊列的結構。在802.11協議描述中，其是首先定義了一個隊列的類，然後在分段支援類進行對SduQueue進行了繼承。首先我們查閱下Queue類的初始定義，如下：

在該Queue類中，其定義了兩個方法，即Qfirst(queue,item)和Qlast(queue,item)。其中Qfirst(queue,item)子函數負責把資料幀插入到隊列首部，Qlast(queue,item)負責把資料幀插入到隊列尾部，在一些材料中，這裡還所述定義了first_and_tail方法，不過筆者在協議中並沒有直接找到。在分段支援類中，對Queue進行了繼承，如下：

即增加了一個方法Qsearch(queue,addr)，在節能模式下，當節點發送PS-Poll後，AP需要在緩衝區尋找出對應該節點的資料幀，再進行相應的傳輸。在這一段描述中，該FragSdu描述是為了power save buffers使用的，但是很多材料中所述，整個傳輸緩衝就是按照SduQueue的形式存放的，這裡筆者並沒有嚴格考證過，最後我們用一張圖大致描述下整個結構。

• 核心中對於緩衝機制以及節能模式的描述（參考《Linux Kernel Networking》第12章部分內容以及openwrt的源碼）
  

在核心中，對於緩衝是在openwrt源碼中\net\mac80211\Sta_info.h中定義的，如

其中ps_tx_buf就是用以節能模式下，儲存節點的buffer的，其中IEEE80211_NUM_ACS參數一般設成4，其對應是802.11e中存在的4中不同優先順序的隊列，sk_buffer_head是一個結構體，其含義是一個鏈表頭，一般該結構都是用來輔助sk_buff結構快速找到鏈表頭結點的。具體實現中，應該是利用該鏈表結構實現了一個Queue，或者說是一個FIFO。

同時實現中，定義了一些有關buffer長度的限制，筆者目前整理一共有三處限制。

• STA_MAX_TX_BUFFER：該參數大小是64（書上所述是128），是用來限制ps_tx_buf的帶下的，位置在\net\mac80211\Sta_info.h中。該參數的意思是，每一個節點最多可以儲存64個資料包。

• AP_MAX_BC_BUFFER：該參數大小是128，是用來限制bc_buf的大小，位置是在\net\mac80211\Ieee80211_i.h。該buffer是專門用來存放組播/廣播幀的，該buffer只有1個隊列。

• TOTAL_MAX_TX_BUFFER：該參數大小是512，根據描述，是用來限制總的buffer大小的，位置是在\net\mac80211\Ieee80211_i.h中。

PS：上述主要還是關注了下，AP中為節能模式所設定的緩衝結構，具體的節能實現機制和MAC層協議，這裡我們還沒有展開，還請見諒。

802.11協議精讀9：初探節能模式（PS mode）以及緩衝機制