WLAN/藍牙耗電議題發酵 無線省電協定抬頭

2008-10-16
雖然有相當多的方法可用於減少無線區域網路(WLAN)和藍牙(Bluetooth)應用程式的耗電量,但其中大多數須以晶片層級(Chip Level)的方式建置,且其傳輸和接收電源層級方面的效用並不明顯。若要將系統層級的耗電量減至最少,了解這些方法的運作是極為重要。
由於省電協定和系統解決方案對耗電量的影響重大,故本文著重於此類方法如何有效減少耗電量,同時還能確保高度的無線系統效能。  

無線實體狀態以組合形式建立協定模式  

當無線裝置進行運作時,其實體(PHY)會處於下列的五種狀態之一:

關閉
  唯一的電源消耗為漏電流(Leakage Current),但是要離開關閉狀態將耗費很長一段時間(許多毫秒)。
睡眠/待命
  裝置可能只消耗175微瓦,除非關閉主要振盪晶體,否則可以快速喚醒。
聆聽
  裝置正在聆聽封包抵達,因此必須開啟大部分的無線電接收器(Radio Receiver)。處於此模式之WLAN和藍牙裝置最佳功率數分別為110和46毫瓦。
主動式Rx
  與聆聽狀態類似,但使用額外的電路系統可能會將WLAN(802.11g)和藍牙裝置的耗電量分別擴增為140和52毫瓦。
主動式Tx
  在傳輸狀態時,裝置的主動元件包含RF功率放大器,通常用於控制高功率傳輸系統。802.11g WLAN裝置的最佳耗電量為450毫瓦(功率為15 dBmTx時);藍牙裝置的值則為78毫瓦(功率為3 dBmTx時)和55毫瓦(功率為18dBm時)。

各種無線實體狀態將以組合的方式來建立無線協定模式,包括搜尋網路、連結但處於閒置狀態、媒體資料流量以及最大輸出資料流量。  

以下用圖來比較兩個模式之間的不同,圖1顯示各種狀態在搜尋網路時所耗費的時間,圖2則顯示媒體資料流量的狀態。當搜尋網路時,裝置幾乎將所有的時間耗費於睡眠模式。

圖1 無線電源模式:搜尋網路

圖2 無線電源模式:媒體資料流量

令人驚訝的是,當傳送和接收媒體資料流量時,裝置仍將大部分的時間耗費於睡眠模式。所需的資料傳輸率(Data Rate)低於無線電容量(Radio Capacity),而裝置可以維持此狀態數個小時。  

在最大輸出狀態時,無線裝置會嘗試盡快移動大量的資料(如檔案傳輸),裝置通常會在此模式中進行短脈衝(Short Burst)。資料傳輸率愈高,裝置回復閒置的時間愈快。  

利用省電協定有效提升效率  

雖然看起來將每個協定模式的耗電量減至最小,似乎可以將整體耗電量降之最低,但卻與事實大相逕庭。實際上,裝置使用協定模式的方法才是造成差異的主因。  

若欲了解其原因,請思考一下現今可用的標準省電協定,包含舊有的省電模式,即原始的802.11省電方式;非排程自動省電模式(Unscheduled Automatic Power Save Delivery, u-APSD),係定義在11e中作為基本802.11標準的修正和強化省電模式;802.11n特有的多重輸入多重輸出(Multiple Input Multiple Output, MIMO)省電模式;以及802.11n中同時定義多重輪詢省電模式(Power Save Multi-poll, PSMP)。  

圖3顯示舊有省電模式的運作方式。裝置告知基地台(AP)本身即將進入睡眠模式,當裝置處於睡眠模式時,AP將保留準備進入裝置的資料。

點圖放大
資料來源:IEEE 802.11規格
圖3 舊有的省電模式

裝置將會定期醒來並聆聽信標(Beacon)。AP將在信標中指示是否含有資料流量,進而決定裝置是否應該醒來並接收資料。  

AP使用名為延緩通訊指示映射(Delivery Traffic Indication Message, DTIM)的特殊信標,它能夠指示是否含有欲提供給特定裝置的單點傳輸(Uni-cast)資料流。  

廣播和多點傳輸(Multi-cast)資料流同時也留給處於省電模式的裝置使用,AP保留住這些訊息,並在DTIM信標之後立即傳送它們。  

醒來聆聽信標的裝置會保持喚醒狀態以接收廣播和多功資料流(Broadcast and Multi-task Traffic)。若AP未有提供給特定裝置的單點傳輸資料流,當廣播和多功傳輸資料流完成時,裝置將回復睡眠狀態。  

若信標指示AP含有欲提供給特定裝置的單點傳輸資料流,該裝置將有兩個選擇可用來取得其資料流,其一為會傳回省電輪詢訊息,以指示AP必須釋放特定數量的封包;若單一省電輪詢未能釋放出保留的封包,裝置可以提出額外的輪詢,以取得其他封包。  

一旦AP釋放出所有保存的資料給特定的裝置,AP將在最後的封包中指示已經將欲給該裝置的所有資料送出,該裝置則可以回復睡眠狀態。  

另一個方法是讓裝置指示AP本身即將離開省電狀態,並在獲得進一步的訊息之前保持清醒,且能夠隨時接收其封包。  

當有大量封包時,此方法會更有效率,因為多重省電輪詢並毋須被傳送。喚醒/睡眠指示可以伴隨資料封包或省電輪詢一起傳送。  

讓此方法成功運作的關鍵在於知道裝置何時應該進入和離開省電狀態,如先前所述,處於睡眠或待命狀態的裝置可以大幅降低耗電量。然而,處於省電狀態同時會增加延遲。

事實上,如果有封包即將進入裝置,接收此封包所耗費的時間可能是等待整個信標週期所產生的延遲,在此時間之後,裝置會醒來、輪詢AP以取得該封包,最後接收該封包。若DTIM信標每300毫秒進來一次,延遲的順序則為300毫秒,其為WLAN網路中的慣例值。除了增加延遲外,省電狀態還會減少輸出。進出睡眠狀態所耗費的時間或傳送省電輪詢,皆會減少整體的輸出。  

為了改善上述的情況,良好的演算法會預測何時有或沒有資料流。根據這些演算法的預測,裝置將在看起來可能持續一陣子不會接收資料流的情況下進入省電狀態。當演算法預測將有資料流時,裝置會離開省電狀態並完全處於清醒聆聽/接收/傳輸狀態。  

u-APSD有利媒體資訊流應用  

u-APSD也是採用類似的運作方式。此省電協定是以輪詢AP以取得資料的裝置為基礎,與先前所述的方式類似,但此情況將睡眠清醒期間細分的更詳盡。因此,u-APSD更適用於VoIP等媒體資料流(Media Stream)。  

圖4顯示u-APSD的運作方式。運載語音資料流的WLAN裝置將一直處於聆聽狀態,因其永遠無法得知下行封包(Downlink Packet)何時會進入。當裝置含有欲傳送的資料時,即進入傳輸狀態。

資料來源:IEEE 802.11規格
圖4 非排程自動省電模式(u-APSD)

此時無法進入睡眠狀態並為下一個信標而醒來,因為此段時間約100毫秒,而VoIP封包每10或20毫秒即進來一次。因此,若裝置嘗試使用傳統的省電方法,將產生過多的語音資料流延遲。  

在使用u-APSD的情況下,裝置會告知AP其正根據此協定進行運作,而AP將儲存該裝置的下行封包。但是在此情況中,當AP一看到裝置的上行(Uplink)封包時,會自動釋放保留給該裝置的任何下行封包。  

如此一來,將允許裝置在必須傳送上行VoIP封包之前處於睡眠狀態,而此上行封包也會自動釋放欲提供給該裝置的任何下行封包。當AP收集並向下傳送封包時,聆聽模式會出現一些延遲,此時裝置進入接收模式。  

一旦裝置已接收所有的下行封包(依照慣例在最後的封包中含有指示),將立即回復至低耗電的睡眠狀態。  

此運作的一點有趣之處為增加資料傳輸率提升了電源效率,此因裝置在主動式傳送器(Tx)和接收器(Rx)中耗費較少的時間,而在睡眠狀態中耗費較多的時間。整體而言,此技術能夠非常有效地減少VoIP的耗電量,大約是不使用u-APSD時的六分之一。  

MIMO省電模式可動態變更傳接數量  

接著要介紹的省電協定方法為MIMO省電模式,其所以有潛力成為更有效率的方案,乃是因為使用多重傳接鏈(Multiple Transmit-and-receive Chain)使資料傳輸率成倍數增加;但相對多重傳接鏈會增加耗電量。  

如先前所解釋,僅增加部分耗電量所產生之更高的資料傳輸率,可以更有效地增加電池的使用壽命。然而,在聆聽狀態中,若只為了等待封包進入而使用多重接收鏈,對於降低功耗是沒有幫助的。  

此外,當裝置只是在等待低資料傳輸率的信標時,也毋須執行能夠接收高資料傳輸率的雙完整接收鏈。信標通常以低資料傳輸率的方式傳送,以確保網路上的所有裝置皆能夠成功地接收它們,因此在傳送信標時,通常不會加上MIMO編碼,所以毋須使用雙接收鏈。  

裝置能夠動態地變更各種情況下現有的傳接鏈數量,以達到省電的目的(圖5)。此功能稱為MIMO省電模式。舉例來說,裝置可以根據其使用電池電源或插電電源動態地在2×2和1×1組態間進行切換。

點圖放大
圖5 2×2MIMO降級轉換為1×1

若裝置使用插電電源時,則已準備好隨時進行高速資料傳輸率的運作;相對而言,若裝置使用電池電源時,則必須具備經常降級轉換為1×1模式的能力。動態變更MIMO組態的能力(依資料流負載而定)在低資料流時,可以減少約30%的耗電量。  

用戶端裝置可以自行變更本身的模式,並將此選擇指示給AP。此設定可避免AP傳送MIMO編碼的封包給僅使用單鏈進行接收的裝置。AP可以藉由傳送簡短的喚醒封包(欲傳送的請求或RTS封包)來指示AP即將傳送MIMO封包,以動態啟動MIMO模式運作。接下來,裝置可以喚醒其所有的接收器。  

動態MIMO省電模式(Dynamic MIMO Power Save)是802.11n中的標準功能,但它屬於可選用的模式。  

PSMP為VoIP應用最佳方案  

此處所述之最新的802.11省電機制為多重輪詢省電模式(PSMP),此機制(圖6)宣稱可作為VoIP用戶端的省電方法,但僅在某些情況下才有效。PSMP將聆聽的作業負擔轉交給PSMP信標(以及提供其他節點使用之部分語音封包的潛在聆聽),如此當有大量VoIP裝置在同一時間嘗試運作時,可以減少媒介之間的競爭。

點圖放大
圖6 PSMP運載的VoIP

PSMP在較大的802.11系統內模擬分時多工存取(TDMA)系統。PSMP信標會切割出供TDMA運作模式使用的時間,當其他所有的裝置聆聽到信標後,信標會讓它們停止運作,並在AP準備將下行封包傳送給具備PSMP功能的裝置(如不同的VoIP電話)時運載排程。AP同時使用信標來安排這些裝置之上行連結的排程。  

比較PSMP和省電模式自動傳送(APSD)是耐人尋味的。在APSD模式中,裝置僅耗費時間於傳送上行資料流和取得區塊認可應答(ACK),或接收下行資料流和傳送ACK,其運作方式非常具有效率。  

在PSMP模式中,裝置必須醒來並接收完整的PSMP信標。根據網路上其他無線裝置的數量和活動的時段,裝置可能沒有時間轉換為睡眠模式、醒來以及取得封包。有可能是因為時間內的間隔過短,以至於裝置在其他裝置接收VoIP封包時,必須保持清醒。若是如此,時間同時完全浪費,相同的情況也會發生在PSMP運作的傳輸期間。  

此時會因為無線通道的快速變化而使PSMP無效率的狀況發生。當裝置移動時,可支援的資料傳輸率會隨之增加和減少,因此,PSMP裝置必須以穩定的方式運作,並使用較低的資料傳輸率,因為錯誤的封包會造成系統的負擔。  

換句話說,如果封包在TDMA系統中發生錯誤,系統必須於相當晚的時間修補此錯誤,須配置新的時槽(Time Slot)以重新傳送封包,因為TDMA的基本概念即正確地封裝每個傳輸,因此沒有時間可用於重新傳輸錯誤的封包。  

相對的,在APSD模式中,封包可能發生錯誤,但不須經過中央協調即可立即重新傳送。如此可大幅降低因錯誤封包所造成的不良影響,並允許APSD裝置更主動地使用更高的資料傳輸率,進而減少耗電量(圖7)。

點圖放大
圖7 APSD運載的VoIP

上述所有因素導致PSMP產生相當大的負擔,所以此模式只有在VoIP節點和AP的總數超過十五才有效。在APSD模式中,裝置會根據所屬的時段醒來,且不會進行協調,在許多裝置爭搶電波資源的情況下,彼此將產生抵觸或者等待對方完成傳輸作業。  

基本上,當VoIP裝置的數量不多時,APSD是最好的方法。同時進入相同基地台之內含大量VoIP呼叫(大於十五)的網路也能受惠於PSMP。  

三大方案減少藍牙耗電量  

藍牙技術屬於TDMA系統。採用藍牙標準基本模式的作業可以達成協定所提供之大部分的省電效益,但是晶片設計人員可以使用其他方法進一步減少耗電量。

動態監聽
  採用動態監聽(Sniff Subrating)功能是其中一項方法,它是藍牙2.1規格中的標準功能。動態監聽允許動態調整聆聽和傳輸期間的週期。藍牙裝置與WLAN中的信標和睡眠期類似,也具有待命期,在這段期間之後,裝置將醒來並監聽,同時能夠對監聽時段進行協調。
動態監聽對於滑鼠或鍵盤等會有突發性資料流的裝置特別有效。當滑鼠移動時,必須具備相當高的反應性;但是當滑鼠靜止不動時,則必須進入非常省電的模式。藉由動態監聽,藍牙裝置可以經常重新協調進入睡眠狀態的時間長短,以及醒來和傳輸資料的頻率。
同步監聽/HV3運作
  採用耳機模式(HV3)的藍牙裝置以三分之一時槽進行運作。此類裝置能夠以耳機語音資料未占用的三分之二時槽來傳輸資料,這些裝置必須在每個時槽開始時進行聆聽時,以查看是否有此類資料存在。
然而,若一開始使用藍牙2.0的規格,裝置可以在HV3執行時使用監聽模式,以在耗電量最少時作好傳輸資料的準備。採用此方式時,以HV3模式運作的裝置可以在大部分的時間維持睡眠狀態,毋須傳輸或接收語音資料,僅要偶爾醒來查看其他時槽是否有額外的資料須要接收,可惜的是,部分製造商尚未建置此功能。
傳輸電源控制
  藍牙技術包含精密的傳輸電源控制機制。當兩個藍牙裝置之間的距離很接近時,可以使用較低的傳輸電源成功地相互傳輸訊息。降低傳輸的電源可以減少射頻(RF)電源放大器所消耗的電池電量。
藍牙電源控制系統屬於閉迴路(Closed-loop)電源控制系統。接收器在能夠安全地減少功率值(Power Level)時會告知發射器。相同的程序可以同時在其他的收發方向操作,此機制具備高度的可靠性,因為接收器能夠指定適當接收所需的真正功率值。

多元省電協定提供彈性選擇  

無線通訊標準提供多類型減少無線晶片耗電量的方法。運作模式結合本文所述之省電協定,便能提供多項管理耗電量的選擇。大部分的選項多可以自由選擇,而獲得的結果也必然將依晶片設計人員所採用的協定建置方式不同,而產生很大的差異。  

(本文作者為Atheros技術長)  

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!