specialist's tech
2014年2月7日 星期五
性能評估/使用限制待克服 ZigBee通訊協定非萬靈丹
Src:
http://www.mem.com.tw/article_content.asp?sn=0811030002
Notes:
---------------------------------
《建構無線感知網路環境系列--從計畫到實作(3-2)》
性能評估/使用限制待克服 ZigBee通訊協定非萬靈丹
2008/11
劉永之
ZigBee無線感知網路技術發展至今,各項規格標準以及晶片模組也都逐漸臻於成熟。不過,晶片生產商仍是ZigBee無線感知網路市場拓展的重要角色,其他業者部分,像是各家感測原件設備商,生產家庭自動化以及提供軟硬體整合服務的資訊業者,面對無線感知網路領域技術仍是一籌莫展,不得其門而入。
本系列文章針對嘗試引入無線感知網路技術卻又不知該如何開始的業者提供資訊,將專注於ZigBee無線感知網路的實作層面,並從系統整合者的角度來切入分析無線感知網路的各種特性。在上一期文章中已經介紹過ZigBee的基本特性,本篇將進一步介紹ZigBee的性能評估方式以及使用上的限制。 如同任何一個新興技術,ZigBee適用於很多不同的應用情境,但是它不可能包山包海處理各種狀況。ZigBee本身有其限制存在,包括效能、布建環境以及擴充性。如何評估ZigBee的適用性,克服可能存在的問題,是廠商導入ZigBee技術前一定要先準備好的功課。
無線通訊/硬體裝置 影響ZigBee傳輸效能
一個無線傳輸技術,「效能」表示兩個具體的指標,一個是傳輸延遲(Latency),亦即一個封包從起點到終點須要經過多少時間;另外一個則是資料吞吐量(Throughput),亦即在一段固定時間內可以傳輸多少資料。
ZigBee網路技術就像任何一種多點傳輸的網路技術一樣,中間經過的轉送節點數量越多,延遲就越久。當發生資料重送的時候,延遲也會增加。延遲的程度和網路的繁忙程度有關,不過,不會改變的是網路的規模與延遲時間成正比。
流量的估算比較複雜。ZigBee底層的媒體存取控制層(MAC Layer)使用CSMA/CA避碰技術,2.4GHz實體層雖然可以支援到最高250kbit/s的傳輸速度,但是MAC能達到的理論速度大約只有70kbit/s。其次,由於無線傳輸的頻寬是共享的,當有多個裝置同時在收發資料的時候,傳輸效率也跟著下降。因此在實際的應用中,無線傳輸能達到的資料流量遠小於理論值。
除了無線傳輸的影響以外,實際上使用時,效能的瓶頸不只是無線通訊,硬體裝置也是須要考慮的因素。在上一節中曾經介紹過,由於ZigBee通訊模組的可程式化空間的可用大小受限,因此比較複雜的工作,通常都是使用外部處理器,不管是嵌入系統或是一台完整的個人電腦(PC)。這些外部處理器與ZigBee通訊模組的連接方式,最常見的就是透過UART。由於ZigBee通訊模組通常不會具備太高的運算速度,因此UART的效率無法達到理論的最高效率115,200bit/s。為了追求比較穩定的傳輸,通常都會使用較慢的速率。
另外一個比較少人知道的效能瓶頸則是來自硬體裝置的暫存空間。由於成本考量,個別裝置的記憶體空間受限,因此可用的封包暫存空間數量也有所限制。目前ZigBee晶片的實作,通常會配置十至二十個左右的封包暫存空間。當發生封包須重傳的時候,已占用的暫存空間無法釋放,就會壓縮到後續待處理的封包排序。如果節點本身須要傳輸大量資料或是網路真的很繁忙,有可能由於暫存空間不足而導致後續資料無法處理。
綜合以上各種限制條件,一個正常使用的網路中ZigBee的效能大概可以用兩個數字來做快速評估,單一節點的資料流量大約是9,600bit/s;每多增加一個轉送節點會增加平均20毫秒的延遲時間。這兩個數字並非理論數字,而是由經驗得出的保守估計值,可用來作為初步評估應用程式適用性時的參考。
當我們須要在效能限制的條件狀況下,對一個應用情境進行評估與規畫的時候,通常可以使用兩種不同的傳輸模型,來判斷ZigBee的效能是否符合此一應用情境的需求。第一種模型是串流形式,資料以比較短的間隔持續回傳,但是允許封包遺失。第二種模型是封包形式,資料以比較長的間隔回傳,但是必須確保每一個封包都正確送達目的地。一般來說,大部分的應用情境都可以套用這兩種傳輸模式。
採用第一種模型進行規畫的時候,預期資料會發生遺失。因此在設計應用程式的時候,可以採用資料採樣點互相涵蓋,或是傳輸重複資料的方式來補足遺失的部分。這一種模型可以達到比較大的資料流量,個別資料點的傳輸延遲則是趨近於常數,此種模型通常適用於環境資料的採樣與蒐集。採用第二種模型進行規畫的時候,由於資料會發生重新傳輸,在設計的時候就必須考慮流量控管的必要性,同時在發送端也必須有能力處理封包永久遺失時的逾時處理。而這種模型通常只會使用在用傳輸控制命令。
第一種模型和第二種模型可以在同一個網路中共存,但是在整體資源利用的規畫以及流量控管等方面,都須要特別處理。
應用情境/硬體裝置的製作品質 決定ZigBee省電效能
一般人對於ZigBee的兩大迷思,一是成本,另外一個迷思,就是省電。「省電」是很多人對ZigBee的刻板印象。但是「省電」是一個相對的比較;相較於其他無線傳輸技術使用的硬體裝置,ZigBee傳輸晶片的確比較省電。但是省電的程度和許多人想像中的「省電」,仍有相當大的差距。
當進行所謂省電效能評估時,其實真正在意的就只有一個裝置靠電池可以用多久。要計算電池壽命,必須先了解電子電路的工作原理。從電源供應的角度來看,一個電子電路,基本上就是「電壓」以及「電流」兩個參數。電壓是一個常數,取決於電源供應端本身的屬性,而電流則是會隨著電子電路工作而隨時變動。
電池的容量一般都是用「mAh」標示。所謂「mAh」的意思就是在固定的電壓之下,持續輸出1毫安培(mA)的電流,能夠供應多少小時。舉例來說,一個3伏特、500mAh的電池,可以讓一個工作電壓為3伏特,工作電流25毫安培的電子電路,連續工作20個小時的時間。
這種計算方式是一個概略的估算方式。由於一般電池在儲存電量消耗到一定程度的時候,電壓也會逐漸降低。當電壓降到電子電路可容忍的範圍之外,電子電路就會停止工作了。因此,實際上的一個依靠電池運作的裝置,連續工作時間比推估的電池壽命更短。從上面的說明可以推論出一個結論:一個使用固定工作電壓的電子電路裝置,消耗的工作電流越少,電池的壽命就可以越長。
現在回頭看看使用一般電池的ZigBee裝置的省電效能。不同廠商推出的ZigBee通訊晶片耗電量各有不同;以一個完整的ZigBee通訊模組來說,工作電壓通常是3伏特,耗電量等級大約是40毫安培(工作耗電量)至5微安培(休眠耗電量)左右。一般常見電池的電壓與電池容量可參閱下列表1:
表1 一般常見市售電池的容量與電壓
電池種類
電池容量
供應電壓
AA 鎳氫充電式電池
2,500 mAh
1.25V
AA 鹼性電池
1,000 mAh
1.5V
AAA 鎳氫充電式電池
850 mAh
1.25V
AAA 鹼性電池
550 mAh
1.5V
鈕扣型水銀電池
250 mAh
3V
資料來源:資策會
由上述數據計算,一個使用兩顆三號電池的ZigBee裝置,忽略其他電路的耗電與漏電,如果一直在工作狀態,電池大約不到40個小時就耗盡了,但是如果一直在休眠狀態,則可以用上17年。
2天和17年兩個工作時間的長度,實在差距相當大。如果不需要這個裝置一直工作,讓裝置進入休眠,是否就能增加電池壽命?來計算看看,假設這個裝置須要每秒鐘回報一次狀況,每次回報狀況須要花費大約50毫秒,這個裝置的執行週期(Duty Cycle)為5%,亦即裝置有95%的時間是在休眠狀態,有5%的時間在工作狀態。如此一來,這個裝置的平均耗電量將是:40毫安培×0.05+10微安培×0.95=2.01毫安培。亦即同樣的電池容量,使用時間可以延長到31天。若更進一步降低這個裝置的回報頻率,改成每10秒一次,亦即這個裝置的Duty Cycle到0.5%,使用相同的方式計算,同樣的電池容量,使用時間可以長達297天。
現在把ZigBee通訊模組以外的耗電與漏電也考慮進去,重新計算一次。假設這個裝置在工作狀態下耗電量增加到50毫安培,休眠狀態耗電量增加到100微安培,使用兩顆三號電池時,如果一直在工作狀態,電池壽命由40小時降為30小時;如果一直在休眠狀態,電池壽命則是由17年降為1.7年。Duty Cycle為5%時的平均耗電為2.7毫安培,電池壽命從31天降為23天。Duty Cycle是0.5%時的平均耗電為350微安培,電池壽命從297天降為178天(表2)。
表2 不同使用情境的電池壽命
Duty Cycle
工作耗電
休眠耗電
平均耗電
電池壽命
100%
50mA
-
50mA
30小時
5%
50mA
100uA
2.7mA
23天
0.5%
50mA
100uA
350uA
178天
0.05%
50mA
100uA
125uA
1.3年
0.005%
50mA
100uA
103uA
1.6年
資料來源:資策會
由以上的計算,應該可以看出ZigBee「省電」的兩大原則,想要讓電池壽命延長,就必須讓裝置盡量維持在休眠狀態,同時要降低在休眠時由硬體線路本身造成的漏電(表3)。換句話說,ZigBee的「省電」性能,取決於應用情境以及硬體裝置的製作品質。
表3 修改電路,改善休眠,耗電以同樣方式計算的結果
Duty Cycle
工作耗電
休眠耗電
平均耗電
電池壽命
100%
50mA
-
50mA
30小時
5%
50mA
20uA
2.7mA
25天
0.5%
50mA
20uA
270uA
232天
0.05%
50mA
20uA
45uA
3.8年
0.005%
50mA
20uA
22uA
7.6年
資料來源:資策會
在這兩項原則中,第一項原則存在一個矛盾的狀況,裝置必須在休眠狀態下才能省電,但是在休眠狀態下的裝置卻無法接收封包。在前面章節曾經介紹過,ZigBee網路本身可以藉由路由轉送而達成跨多節點通訊的效果。如果負責路由轉送的節點進入休眠狀態,就無法轉送封包。由於這個因素,一個「完全依靠電池動力的ZigBee網路」在目前是無法實用化的。熟悉其他無線通訊技術的工作者可能會質疑,有關無線通訊省電的研究不是很多嗎?為什麼不想辦法實作出來?
事實上,目前有關無線通訊省電的研究都著重於提升整體節點的電池壽命,避免部分節點因為轉發過多封包而提早耗盡,或是對靠近的節點發送封包時降低發送功率。但是現有的ZigBee通訊模組,都有一個鮮為人知的特殊現象,那就是傳輸時的耗電量比待機/接收時的耗電量低。由於這個特性,使得大多數針對其他無線通訊技術建立的各種省電理論,在ZigBee網路中全部都不適用。
目前有關ZigBee低省電路由(Low Power Routing, LPR)研究,偏向使用時間同步(Synchronization)或是訊號喚醒(Wake-on-RF)的方式來解決。然而截至本篇文章撰稿為止,負責制定ZigBee標準的組織對此一議題尚未有定論。因此在目前進行ZigBee網路規畫的時候,可行的解決方式就是避免提出「完全依靠電池動力的ZigBee網路」的需求。
通訊協定/網路構成形成ZigBee限制
第一部分曾經介紹過ZigBee網路的構成。ZigBee通訊協定本身具備自動組織成一個網路的能力,這種功能在某些情境很便利,但是同時也會造成一些限制與困擾。在ZigBee通訊協定中,雖然封包的通訊允許無限制任意傳輸,但是網路的構成本身還是必須依循一個樹狀的拓撲結構,從樹根(Root,亦即Coordinator)開始往外生長。裝置的網路位址,是在裝置加入時,由裝置在整體網路拓撲架構中的相對位置所計算得來。ZigBee網路位址是一個16位元的數字,受限於整個網路位址數量,拓撲的廣度與深度也會受到限制。現行的Zig-Bee標準中,網路最深可以達到十五個階層,然而每個階層能夠允許的拓撲連線數量就會很少。亦即如果須要布建一個涵蓋範圍相當廣的網路時,就必須考慮使用叢集式的網路架構,並且混合TCP/IP網路來擴展整體涵蓋範圍。
另外一個限制來自於網路的構成。由於ZigBee網路的構建模式是由加入的一方主動要求加入,已經加入網路的節點必須被動等候其他節點加入,因此想要加入網路的節點,必須能夠正確辨識應該要加入的網路:當有數個網路同時存在的時候,才不會加入其他人的網路。
對於這個問題,有幾種可行的解決方式,最常見的解決方式就是裝置預先設定網路的辨識代碼;如此一來,裝置就會自動辨識出哪一個是應該要加入的網路。ZigBee通訊協定使用的網路辨識代碼是一個64位元的數字,使用IEEE硬體位址(Hardware Address)相同的原則配發,因此不可能發生兩個不同的網路恰巧使用同一個網路辨識代碼的狀況。
裝置預先設定網路代碼的方式,則是隨著不同的實作與不同的應用情境,有很多解決方案。一般說來,一個經過預先規畫、遵循計畫步驟布建的網路,會採用先設定完成再安裝的模式。而一個以DIY市場為主要目標的消費性產品,則可能會採用類似藍牙(Bluetooth)的配對(Pairing)動作,讓最終使用者在安裝時自行設定。
以上介紹的兩種使用限制主要針對網路的建構與延伸,是在網路規畫與構建階段須要面對的問題。而在網路已經完成建構的使用階段,主要碰到的限制,就是對於移動節點的支援。
ZigBee為標準中的非標準解決方案
ZigBee通訊協定雖然是一個功能相當完整的網路通訊協定,但還是有標準涵蓋不及的狀況存在。最明顯的一個例子就是移動節點的支援。
前面曾經介紹過,ZigBee通訊協定本身具有自動探知路由路徑的能力。因此,一個節點如果離開原本規畫的收訊範圍,遷移到網路的另外一端,只要這個節點本身具備探知路由的能力(亦即這個節點本身是一個路由器),重新建構一條路由路徑將不會構成任何問題。但是這個重新探知路由路徑的動作須要花費一點時間,大約數秒至數十秒,如果裝置本身並不會經常移動,例如一個放在推車上、須要使用的時候會推到使用者座位附近的實驗儀器,在使用上將不會有任何問題,使用者也不會感覺任何異常。但是如果裝置本身會持續移動,比如一個佩戴在使用者身上,隨著使用者走來走去的感測器,ZigBee將無法正常支援。
對於這個限制,目前的解決方式多採用非標準協定或是在現有ZigBee標準規範之下以應用程式技術來解決。若是單項傳輸的應用情境,例如環境監測或定位應用等,目前已經發展出相當完整的解決方案。
但是對於須要雙向傳輸的應用情境,例如定位追蹤加上即時私人訊息廣播,目前雖然也有可實用化的解決方案,但是相當複雜。有關細節部分已經超出本篇文章的範圍,不再贅述。
如同以上所述,ZigBee本身存在使用的限制。想要克服這些障礙,最有效的方式就是預先規畫。評估障礙發生的可能,然後從布建與應用程式評估克服障礙的可行性,如此才能順利達成需求的功效。本篇系列文章下一部分將介紹幾種常見的實際布建網路架構及規畫的原則。
(本文作者為資策會網路多媒體研究所組長)
上一篇
支援MIMO數學運算突顯優勢 OFDM躍居調變主流
下一篇
多頻RF單晶片效能/彈性兼具 新一代UMTS手機更上手
沒有留言:
張貼留言
較新的文章
較舊的文章
首頁
訂閱:
張貼留言 (Atom)
沒有留言:
張貼留言