https://zhuanlan.zhihu.com/p/21505178

序言

由于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幀（既空數據）。有的書中，也將這個請求機制比較形象的描述為“兵乓”機制。

我們用下圖大致描述下這里其交互機制：

由于AP已知節點工作在節能模式，所以其首先將發送給節點的數據進行緩存。

當工作在節能模式的節點wake-up后，其在完成競爭后，首先發送PS-Poll幀向AP請求下行數據幀。

AP從而就在自己的緩存區里面找該節點的緩存數據。當找到對應數據幀后，通過Frame進行反饋，這里可以看到上圖標注了一個IEEE80211_FCTL_MOREDATA的描述，該參數實際上對應到無線數據包中的more data字段，如果AP。

如果節點識別到該more data字段為1后，則知道AP中還有自己的緩存數據，那么會再次發送PS-Poll幀進行請求。

直到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）与缓存机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。