摘要:基于Micaz節點平臺設計了系列實驗,測試TinyOS網絡協議棧各層面的時間特性。根據實驗的結果,分析了影響無線傳感器網絡實時性能的主要因素,為協議和應用的設計提供了實驗基礎。
關鍵詞:無線傳感器網絡;傳感器節點;基站;實時
中圖分類號:TP393文獻標志碼:A
文章編號:1001-3695(2007)05-0241-03
無線傳感器網絡能夠協作地實時監測、感知和采集網絡分布區域內的各種環境或監測對象的信息,并對它們進行處理,獲得詳盡而準確的結果,然后傳送到用戶。例如,傳感器網絡可以向正在準備進行登陸作戰的部隊指揮官報告敵方岸灘的詳實特征信息,如叢林地帶的地面堅硬度、干濕度等,為制定作戰方案提供可靠的材料。因此,它可以被廣泛地應用于國防軍事、國家安全、環境監測、交通管理、反恐抗災等領域[1]。在這些應用中,大多帶有明顯的實時需求,要求傳感器網絡能夠將采集到的數據盡量在規定的時間內傳輸到數據中心,由數據中心對數據進行分析,并將最終分析結果交給決策者。
對于具有實時需求的無線傳感器網絡應用來說,首先無線傳感器網絡是Ad hoc網絡的一個特例,它的數據傳輸時間與傳輸的跳數(Hops)有著很大的關系;其次由于無線傳感器網絡的特殊性,它除了考慮實時約束(消息必須在規定的延時內到達基站)外,還需要考慮資源約束(能源、帶寬)、傳感器網絡的不可靠性等其他約束。
1研究現狀
無線傳感器網絡正處在研究階段,它的應用也處在開發探索階段。目前帶有實時要求的傳感器網絡中滿足實時要求的有以下三種處理方法[2]:
①建立在IEEE 802.11標準之上的MAC層解決方案。它將傳感器網絡中的節點布置成蜂窩結構[3],采用Earliest Deadline First算法進行調度,使得對下面的無線媒質可以無沖突地訪問[4]。②網絡層解決方案。它是一種通過保證預期的發送速度來提供軟實時服務的路由協議(SPEED)[5]。③一種通信體系結構RAP,它的各層協同工作對數據包進行優先級的分配和調度[6]。
但是在上面的方案中除了方案③是一種體系結構外,方案①要求網絡部署成特殊的結構(不能隨機部署)等其他嚴格限制,而且筆者也只進行一個蜂窩內的實驗。由于蜂窩之間的通信很復雜,實驗沒有進行。方案②只是一個網絡層的解決方案。
本文的目的就是以TinyOS網絡協議棧為例,測試其在Micaz節點平臺下各層面的時間特性,并由此分析了影響無線傳感器網絡實時性能的主要因素。實驗表明,為了更好地滿足實時應用的需求,需要對MAC層和路由層進行協同設計,不能停留在單一層面上。
2實驗平臺及其配置
2.1硬件平臺
對于無線傳感器網絡來說,硬件部分由Sink節點和傳感器節點兩種類型的節點組成。現在使用的大多都是美國的Crossbow公司生產的Mica系列產品。Sink節點由傳感器節點加上編程板組成。它負責將無線傳感器網絡中的數據傳遞給數據中心,同時也負責將數據中心的指令發布到網絡。所以,Sink節點是數據中心與無線傳感器網絡之間的橋梁。另外,對于傳感器節點來說,可以根據應用的不同需求選擇安裝不同類型的傳感器板。
下面是本文使用的配置:傳感器節點Micaz,編程板Mib510,使用2.4 GHz的無線信道收發數據;使用1.5 m長的串口延長線將基站接入PC端,這種接口線應該是直通的(Straight-through)。
Micaz的主要特點是能在戶外使用。因為節點之間使用的是2.4 GHz公用無線頻道進行通信,無須申請注冊;而且支持IEEE 802.15.4協議,能適應與其他設備通信的要求[7]。
2.2軟件平臺
(1)無線傳感器網絡操作系統。
對于無線傳感器網絡來說,使用的軟件平臺主要是TinyOS和SOS(Sensor Operating System)。SOS由UCLA的NESL實驗室開發,它使用公用的核心實現了消息傳遞、動態內存管理、模塊的動態加載和上傳等服務;動態可裝載的軟件模塊實現網絡服務的增加、修改和刪除,而且從軟件上支持IEEE 802.15.4協議[8]。
當然使用最為廣泛的還是UC Berkeley開發的TinyOS。它也是專門為無線傳感器網絡開發的開源操作系統[9]。其基于組件的系統結構使軟件開發變得很簡單。
該硬件平臺(Micaz)需要至少TinyOS 1.1.7以上版本。因為在以前的硬件平臺Mica2,Mica2dot使用的是芯片CC1000進行無線數據接收,而Micaz使用的是Chipon公司的CC2420芯片用2.4 GHz進行數據收發。這個芯片只有在TinyOS 1.1.7版本之后才得以支持[7]。本文使用的是TinyOS 1.1.11。
(2)無線傳感器節點軟件。實驗使用的應用程序的基礎是TinyOS的Apps目錄下的Surge。該應用程序的主要功能就是傳感器節點將采集得到的數據通過無線傳感器網絡傳輸到編號為0的Sink節點,由Sink將數據轉發給數據中心。
在TinyOS 1.1.11上傳過程中,使用TinyOS和Crossbow公司文檔介紹的方法均沒有上傳成功。后來檢查發現是TinyOS的Makefile腳本有一點問題,只有使用make micaz (re)install.n mib510,/dev/ttyS0才可以成功上傳。使用下面的方法不能成功:
Make micaz install.n mib510,com1(Crossbow公司介紹的方法)
MIB510=/dev/ttyS0 make install micaz[10](TinyOS介紹的方法)
(3)客戶端的設置。
當數據到達基站時,基站就把該數據包發送到UART上傳給PC。所以只能捕獲到成功到達基站的報文。TinyOS提供了從串口捕獲數據包的工具,而且支持多用戶通過互聯網遠程連接捕獲。Micaz的串口連接速率是57 600 bps。操作命令是:java net.tinyos.sf.SerialForwarder ̄comm serial@COM1:57 600,然后就可以打開另外一個窗口使用java net.tinyos.tools.Listen接收發給PC的數據包了。
3實時性能實驗
3.1實驗評價指標
在TinyOS中,網絡協議棧由應用層、路由層、MAC層和物理層構成。中間沒有傳輸層。
應用層負責數據的采集及融合。
路由層的標準協議是MINIRoute。它使用基于鏈路質量估計而不是根據最小跳數來進行路由選擇。因為根據收發鏈路的質量選擇傳輸的父節點將使得數據包到達Sink節點的傳輸數最小。
標準的TinyOS MAC層協議是基于沖突檢測的MAC層協議B-MAC。它通過低能監聽(Low-power Listening)提供能源管理。可以通過只在數據包的末尾增加幾個附加位實現同步應答。而且,B-MAC協議的很多參數是可設置的,滿足跨層協同設計的需要。但是,B-MAC不進行鏈路級的重傳;也不處理隱藏終端問題,設計者認為它應該在高層處理。
物理層采用CC2420芯片進行無線數據的發送,從硬件上支持IEEE 802.15.4。
從數據包的傳輸來看,它的傳輸過程如圖1所示。
因此,對于一個數據包來說,它的傳輸時間等于:
該實驗就是測試上面的各個時間參數,并由此分析影響無線傳感器網絡實時性能的主要因素。
3.2發送節點上數據包從應用層到MAC層的處理時間
測試這個時間比較容易。在TinyOS中,提供了獲取系統時鐘的接口SysTime,它能提供16位的時鐘,也可以提供32位的時鐘。測試方法是在應用層提交數據發送請求時調用一次系統時鐘函數,將該計數值放在TinyOS的報文中,因此這個數值隨著報文一起提交給了路由層。當數據包到達MAC層時再調用一次系統時鐘函數,與開始的時間相減得出從應用層提交到達MAC層的時間。
實驗發現,從應用層傳到MAC層的時間一般為84、85個Micaz時鐘單位(一個Micaz的時間單位為1/921 600 s)。由此可以看出,從應用層到達MAC層的時間是非常穩定的。
3.3一個節點的MAC層到下一個節點MAC層的時間
測試的方法是由一個節點發送數據包給另一個節點接收,然后接收節點又將數據包發送回來。具體的方法是在TinyOS報文中加入兩個時間字段,一個字段記錄著數據包從發送節點離開到接收回來的時間,另外一個是記錄著數據包在接收節點上的停留時間。由此可以計算出兩倍的從一個MAC層離開到另一個MAC接收的時間。通過實驗發現,這個時間穩定在0xE8C個Micaz時間單位。
3.4從MAC層接收經過路由層處理到再次遞交給MAC層的時間
這個時間主要是針對中間路由節點而言的。因為無線傳感器網絡是特殊意義上的Ad hoc網絡,數據包通常都需要經過多次傳輸才能到達數據中心。
在不同流量背景的不同節點上進行測試,結果發現這個時間也非常穩定,為196或197個Micaz時鐘單位。
3.5數據包從提交發送到發送完畢的處理時間
發送節點上數據包的處理時間是指從數據包的提交到數據包發送完畢之間的時間(從Send.send到Send.sendDone之間的時間)。這個時間不能隨同測試報文傳回基站,使用的方法是在下一個報文中傳回來。
由于這個參數是針對單個節點而言的,通過實驗測試一下該參數在不同的干擾和不同的網絡流量下的變化情況。
從數據的統計分析來看,在不同流量背景的情況下,數據包從提交發送到發送完畢所經歷的時間并不是絕對增加,而是顯示出很大的隨機性。但是,從這個時間的標準差分析來看,隨著平均時間的增加,標準差也增大。因此,從實驗可以得知,這個時間很不穩定,變化的區間也很大。由傳輸過程可以得知,這主要是由于TtMac的時間不確定引起的。
3.6數據包的傳輸時間
數據包的傳輸時間是指數據包從發送節點提交發送開始計算到達Sink節點所花費的時間。由于從一個節點的MAC層離開到另外一個節點的MAC層接收的時間是一個穩定值,實驗中沒有將它計算在內。
在實驗中,數據包通過兩跳到達Sink節點,發送節點的發送速率固定為400 ms/個;然后改變中間節點和Sink節點的發送速率,一共設置了四個速率。分別為1s/個,500 ms/個,100 ms/個,80 ms/個。計算傳輸時間的均值和標準差,分別如圖4、5所示。
測試結果顯示,隨著平均時間的增加,傳輸時間的偏移程度也在增大。但是傳輸時間并不是隨著流量的增加而增加,而表現出很大的隨機性,初步分析可能還是由于MAC層的隨機Backoff時間引起的。
當然,更多傳輸跳數的實驗能夠證明,隨著跳數的增加,數據包的平均傳輸時間也隨之增加。
3.7Micaz節點的最大流量
在實驗中發現,即使在只有一個傳感器節點和一個Sink節點的情況下,Sink節點能接收到的最大傳感器節點發送速率為34 ms/個數據包。高于這個速率,Sink節點就無法接收數據包了。
4結束語
從實驗的數據分析來看,對于單個節點,數據包從提交發送到發送完畢所花費時間的變化主要是由于節點在MAC層上的停留時間不確定引起的。
對于傳輸時間,隨著數據包傳輸跳數的增加,傳輸時間也相應延長,具有線性關系。但是,隨著流量的增加,傳輸時間不一定增加,表現出很大的隨機性。從傳輸過程可以得知,這主要也是由于MAC層的不確定性引起的。
由于CSMA/CD MAC層協議無須時間同步、擴展性好等優點以及無線傳感器網絡規模大、節點能量小的特點,使其成為無線傳感器網絡一定層面上最適合的MAC協議類型。但從實驗結果來看,CSMA/CD類型的MAC層協議對實時性能的影響是很大的,是傳輸時間不穩定性的主要來源。因此,為了更好地滿足大規模隨機部署的無線傳感器實時應用的需求,MAC層和路由層協議均需根據實時應用的特點進行協同設計,減少數據包的傳輸時間;更重要的是克服傳輸時間的隨機性,而不能僅僅停留在某一層面的改進上。
本文在這個工作的基礎上,正在利用多信道和長跳步協同設計,更好地滿足了實時應用需求的MAC層和路由層協議。
參考文獻:
[1]李建中, 李金寶, 石勝飛.傳感器網絡及其數據管理的概念、問題與進展[J].軟件學報,2003,14(10):1717-1727.
[2]STANKOVIC J, ABDELZAHER T, LU Chengyang,et al.Real-time communication and coordination in embedded sensor networks[J].Proceedings of the IEEE, 2003,91(7):1002-1022.
[3]GOODMAN D J.Cellular packet communications[J].IEEE Transactions on Communications, 1990,38(8):1272-1280.
[4]CACCAMO M, ZHANG L Y,LIU Sha,et al. An implicit prioritized access protocol for wireless sensor networks: IEEE Real-time Systems Symposium[C].[S.l.]:[s.n.], 2002.
[5]HE Tian, STANKOVIC J, LU Chengyang,et al. SPEED: a stateless protocol for real-time communications in sensor networks:International Conference on Distributed Computing Systems(ICDCS’03)[C].[S.l.]:[s.n.], 2003:46-55.
[6]LU Chengyang, BLUM B M, ABDELZAHER T F,et al. He.RAP: a real-time communications architecture for large-scale wireless sensor networks: Real-time Technology and Applications Symposium[C]. San Jose: [s.n.],2002.
[7]Crossbow website[EB/OL].[2006].http://www.xbow.com/Support/support.htm.
[8]SOS website[EB/OL][2006]. http://nesl.ee.ucla.edu/projects/SOS/.
[9]TinyOS website[EB/OL][2006]. http://webs.cs.berkeley[EB/OL].edu/tos/.
[10]TinyOS (tinyos-1.1.11-3i )tutorial[EB/OL].http://tinyos-1.x/doc/tutorial/programmers.html.
注:“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”