1 引言

IEEE 802.11、藍牙、UWB等協議推出以來，在短距離的無線監測、控制、數據傳輸領域得到廣泛應用，但它們仍然存在功耗大、組網能力差等弱點。以組網能力強著稱的ZigBee協議能彌補上述協議的不足，特別適合于組建短距離低速無線個域網、無線傳感器網絡等。

ZigBee協議由ZigBee聯盟于2004年12月中旬正是推出，其介質訪問控制子層（MAC）基于IEEE 802.15.4標準，網絡層采用Cluster-Tree+AODVjr路由算法，支持星形（Star）、樹狀（Cluster-Tree）、網格（Mesh）等多種拓撲結構^[1]，算法可在簡單的單片機平臺上實現^[2]。其中，單獨采用AODVjr（AODV Junior，簡化的AODV）路由算法的Mesh網絡最為簡單，應用較廣泛。AODVjr算法是AODV（Ad hoc On Demand Distance Vector, Ad hoc按需距離矢量路由協議）算法的簡化，它跟AODV一樣，與目標節點通信時，采用先問路由，再發送數據或命令的辦法^[3,4]。本文提出采用捎帶技術的AODVjr算法，將要發送的數據捎帶在AODVjr的路由請求和路由應答包中，大大提高ZigBee網絡的通信效率。DSP2812

2 ZigBee的AODVjr協議

ZigBee協議網絡層AODVjr算法是需求驅動型的，由源節點選擇路由，它是針對AODV算法的簡化改進。考慮到節能、成本、應用方便性等因素，AODVjr簡化AODV的一些特點，但是仍然保持AODV的主要功能。

首先，在AODVjr路由算法中，沒有目標節點序列號，只有目標節點才能發送路由應答（Route Reply，RREP）包，這樣可以避免循環問題和無效RREP包出現，提高通信效率。其次，AODVjr刪除路由錯誤（Route Error，RERR）包及前驅列表（Precursor List）。另外，為了避免廣播風暴，AODV中周期性發送的Hello包也被刪除。在ZigBee的集成路由算法中，AODVjr中的許多優點使得路由協議簡單化且實現AODV的基本路由功能^[5,6]。

圖1（a）和（b）是AODVjr算法尋找路由的方式。當節點A要發送信息給節點D時，如果發現自己沒有到節點D的路由，便通過組播（Multi-Broadcast）路由請求（Route Request，RREQ）包，請求其鄰居幫忙查找到節點D的路徑。每個接收到RREQ包的節點，都維護一條到節點A的路由信息，同時幫助節點A廣播查找節點D。通過這種洪泛（Flooding）方式，RREQ包會被廣播轉發至節點D。節點D接收到RREQ包后，根據RREQ包的路由代價（Cost）決定是否更新自己的路由表，同時通過路由代價最小的路徑給節點A回復RREP包。節點A查找目標節點通常是通過組播進行的，而節點D給節點A回復RREP包則通過單播（Unit-Broadcast）進行的。節點A接收到節點D的RREP包后，根據Cost最小原則決定與節點D通信所走的最佳路徑。圖1中，節點A查找到節點D的最短路徑：A->B->C->D，然后把數據發送給節點D，節點D再通過D->C->B->A給節點A確認信息。

DSP2812

圖1 AODVjr算法查找路由及通信方式

在ZigBee協議里，AODVjr的RREQ包和RREP包作為網絡層命令傳送，成為單獨的網絡負荷，如圖2所示。其中命令標識值等于0x01時是RREQ包，等于0x02時是RREP包；單字節的命令選項只使用一個比特，用于區分該路由包是單獨進行路由查找還是進行路由修復（Route Repair）^[1]。

（a）路由請求包

DSP2812

（b）路由應答包

（c）命令選項

圖2 ZigBee網絡層的命令包

3 捎帶技術在AODVjr的應用

ZigBee網絡里的AODVjr屬于后應式的按需Ad hoc網絡，不周期性地更新自己的路由信息，只有在需要通信時，才發起路由查找過程。在ZigBee網絡里，節點會移動或者休眠，通信時幾乎每次都要重新查找路由，而每次傳輸的數據量又比較少，絕大多數情況下只要傳送一次即可完成，如獲取傳感器的值。為了達到節能且降低通信復雜度的目的，可將互聯網中常用的“捎帶確認”技術應用于ZigBee網絡。

所謂“捎帶確認”，是指為了提高網絡的通信效率，目標節點接收到源節點的數據后，將確認（ACK）信息附加在目標節點發送給源節點的數據包中，由這些數據包捎帶給源節點。DSP2812

采用捎帶技術后，如圖3（a）所示，源節點可以把要發送給目標節點的數據或命令放置在RREQ包后面，成為網絡負荷的一部分，由RREQ包傳送給目標節點。目標節點接收到RREQ包后，在給源節點回應RREP包之前，處理源節點發送的數據或者命令，將要發送的ACK或者數據由RREP包捎帶給源節點，如圖3（b）所示。

（a）捎帶數據或命令的路由請求包

（b）捎帶ACK或數據的路由應答包

（c）改進后的命令選項

圖3 采用捎帶技術的ZigBee網絡層命令包

如圖3（c）所示：引進捎帶功能后，要修改AODVjr里的命令選項，將保留的7個比特用于表示捎帶數據的長度，為0時表示此路由包沒有捎帶任何數據，是普通的AODVjr路由包。

沒有采用捎帶技術時，如圖1所示，源節點和目標節點之間傳輸數據需要2個來回；改進后只需要圖1（a）、（b）所示的一個來回。由此可見，將數據捎帶在路由包中，對于只需通信一次數據就可以傳輸完畢的情況，能夠節省一個來回的時間。這樣，網絡在通信延遲、節能、效率上都有優化，同時降低通信復雜度。

4 算法的實現

4.1 協議棧

采用捎帶技術的ZigBee協議棧有3層，其體系結構如圖4所示。協議棧參考ZigBee網絡的結構，物理層和介質訪問控制層采用IEEE 802.15.4協議，網絡層僅使用捎帶技術的AODVjr路由算法，通過應用支持子層與應用層建立聯系。該協議棧簡單、實用、高效。

圖4 采用捎帶技術的ZigBee協議棧

4.2 路由設計與實現

（a）目標節點接收到RREQ包

（b）源節點接收到RREP包

圖5 目標節點和源節點處理RREQ和RREP流程

采用捎帶技術后，對算法復雜度的影響不大。只要稍微改動源節點和目標節點發送以及接收RREQ包和RREP包的程序即可，中間節點仍按普通的AODVjr包處理數據。

圖5是目標節點和源節點處理RREQ包和RREP包的程序流程，從中可以看出，捎帶技術并沒有增加算法實現的復雜度。作者在美國赫立訊公司的IP-Link122x系列模塊中使用Keil C編程，實現使用捎帶技術的ZigBee網絡。該模塊通過美國FCC認證，經過ZigBee聯盟指定的德國萊茵TUV ZigBee實驗室一致性測試，是符合IEEE 802.15.4標準和ZigBee協議的模塊。本文算法運行在模塊自帶的嵌入式芯片――Silicon Laboratories公司的8051內核MCU上，采用Chipcon AS公司的射頻芯片CC2420收發數據。

5 實驗結果

研發過程中，可以使用Chipcon AS公司的IEEE 802.15.4包監聽器（Packet Sniffer）分析空氣中傳送的數據包，對不同節點數目的Ad hoc進行測試，可取得良好的結果。

實驗中，采用Mesh拓撲，50個節點組成的ZigBee網絡隨意分布在三層樓中，采用對等連接方式，僅使用AODVjr路由算法。兩個節點通信的平均傳輸延遲及成功率，采用捎帶技術前后質量對比如表1所示。從表1可知，傳輸延遲時間可以減少很多，且成功率有一定的提高。證明本文提出的網絡結構及軟硬件設計的可行性。

表1 采用捎帶技術前后的通信質量對比

6 結論

本文提出采用捎帶技術的AODVjr算法，同時給出簡化的ZigBee協議體系結構，并在硬件平臺上實現該方案。實踐證明，采用捎帶技術能降低算法實現的復雜度，減少通信量，節約電池能量，有效提高ZigBee網絡的總體性能。本方法還可以在其他使用AODV算法的網絡中推廣，具有一定的實用價值。DSP2812開發板

參考文獻：

[1] Zigbee Alliance. ZigBee Specification (Version 1.1)[S]. 2006.

[2] 張成武,譚斌.單片機Zigbee技術在遠程抄表系統中的應用[J].微計算機信息,DSP2812開發板2006:22(32):96-98.

[3] RFC 3561:Ad hoc On-Demand Distance Vector (AODV) Routing[S].2003.http://www.51kaifa.com/shop/read.php?ID=4732

[4]Mobility Management and Networking (MOMENT) Laboratory. Ad hoc On-Demand Distance Vector Routing[EB/OL].http://moment.cs.ucsb.edu/AODV/aodv.html, 2007-4-2.

[5]Ian D. Chakeres, Luke Klein-Verndt. AODVjr,AODV Simplified[J]. Mobile Computing and Communication Review,2002,6(3):100-101.http://www.51kaifa.com/shop/read.php?ID=4732

[6]Qiu F., Wang J-M., Leng J. "Design and Implementation of a Wireless Personal Area Network Based on AODVjr Routing" in Wireless MobileMultimedia Networks (ICWMMN) Proceedings[C].Beijing:The Institution of Engineering and Technology,London(IET),2006:424-427.