摘要：無線傳感網絡是由大量體積小，供電資源有限，并配置一定計算能力和無線通訊能力的傳感節點組成。對于傳感網絡系統，一定存在程序代碼更新和維護的需求，但由于傳感節點分散部署的特點，使得網絡遠程節點的程序升級變得異常困難。為此，空中下載（over the air， OTA）提供了一種有效的更新手段。本文首先介紹基于 ZigBee協議的OTA系統，并在CC2530F256 硬件平臺作出驗證。最后，在Z-Stack協議棧中，設計出一種鏡像頁請求的OTA更新方式，并通過實驗測試，與原有的鏡像塊請求方式進行了比較分析。實驗結果表明，鏡像頁請求方式可以大大減少網絡的更新流量，從而提高節點的更新效率。

　　0. 引言

　　近年來，由于硬件成本的下降以及制造工藝的進步，無線傳感網絡技術逐步取得大規模商業應用，如醫療監控，智能電網和智能家居[1]。對于任何一個嵌入式計算機系統，都存在程序代碼升級的需要。在無線傳感網絡的應用環境中，由于大量節點分散性部署，節點的回收工作變得異常困難，使傳統的物理連接的程序更新手段不再適用。對此，一種有效的解決方案是OTA技術。

　　空中下載技術起源于移動電話網絡，能夠通過移動通信網絡（如GSM）對SIM卡數據進行遠程管理與更新[2]。借鑒于移動通信網絡，空中下載技術也能應用于無線傳感網絡。與網絡層的路由協議[3]不同，代碼分發協議[4]是支撐OTA的核心技術。前者關注的是如何迅速高效地中轉網絡中的數據信息，后者關注的是如何向各節點完整無誤地傳遞更新代碼[5]。目前，成熟的代碼分發協議已經提出，典型的如基于TinyOS系統的Xnp[6]與Deluge[7]，前者提出了單跳網絡的更新方案，后者支持多跳網絡更新功能，但都需要具體的硬件平臺支持。

　　本文移植并驗證了一種基于ZigBee協議[8]的空中下載技術，其分發協議支持點對多傳輸更新功能，多跳網絡的代碼分發功能由路由協議支撐。在Z-Stack協議棧[9]下，僅僅支持鏡像塊請求功能，更新效率并不理想。針對此問題，設計出一種高效的鏡像頁請求功能，能夠提高點對多的傳輸更新效率，并減少網絡流量。

　　1. OTA概述

　　ZigBee協議規范使用了IEEE 802.15.4定義的物理層（PHY）和媒體介質訪問層（MAC），并在此基礎上定義了網絡層（NWK）應用層（APL）。針對無線傳感網絡重編程技術的需求，ZigBee聯盟在原有協議的框架上，提出了一種OTA規范[10]，作為一個系統可選的功能模塊。

　　圖1為OTA系統的結構示意圖，整個系統主要由3部分構成：OTA應用控制臺，OTA服務器，OTA客戶端。其中OTA應用控制臺是上位機管理軟件，負責OTA鏡像管理，網絡節點信息陳列與發送更新命令；OTA服務器負責向遠程節點無線發送升級鏡像，并通過串口與上位機連接，向應用控制臺匯報各節點更新進度信息等；OTA客戶端是指遠程網絡中的待升級節點。

　　根據代碼的更新范圍，分為整體代碼更新與基于差異性的更新[11]。前者是把所有可執行的二進制代碼打包成一個鏡像分發給節點，后者是通過比較新舊鏡像文件之間的差異，產生一個編輯腳本，然后把這個腳本分發到網絡中的節點進行差異性更新。毫無疑問，前者需要傳輸的數據量較大，一般為上千字節級，增加了網絡負擔，但代碼更新操作相對簡單；后者發送的數據量雖少，但增加了更新過程的復雜度，對處理器產生更大的負擔，帶來較大的能源損耗。由于ZigBee協議對網絡節點的低功耗標準有嚴格的要求，其OTA代碼分發協議采用前者的鏡像傳輸方式。

　　服務器與客戶端之間的數據交互過程如圖2所示。首先OTA服務器通過單播或者廣播方式向OTA客戶端（節點）發送鏡像公告（Image Notify），指示新鏡像已經準備好。收到鏡像提示信息后，節點就向OTA服務器發送查詢下一個鏡像請求（Query Next Image Request），此請求信息包含了當前運行固件的版本信息。收到該請求后，OTA服務器作出響應（Query Next Image Response）。隨后，OTA客戶端與OTA服務器通過二次握手機制，鏡像塊請求（Image Block Request）和鏡像塊響應（Image Block Response），完成整個鏡像傳輸過程。當OTA客戶端收到鏡像塊數據后，把塊數據寫到第二存儲區（客戶端當前運行的鏡像保存在第一存儲區）。完成下載后，節點將對下載后的鏡像進行CRC校驗。最后，當節點需要更新時，把新鏡像從第二存儲區復制到第一存儲區，新固件開始運行，從而完成了整個升級過程。

　　2. OTA系統設計

　　本文的OTA系統基于TI公司的ZigBee SOC芯片CC2530F256[12]設計，包括硬件與軟件的設計。其中硬件部分主要涉及CC2530 F256內部Flash存儲空間分配方式與鏡像存儲方式的選擇；軟件部分介紹了OTA啟動代碼工作流程。

　　2. 1硬件系統

　　CC2530F256內部集成一個增強型8051單片機，擁有8KB SRAM和256KB內部flash存儲器。內部flash主要用來保存程序代碼和常量數據。由于傳統8051 代碼存儲空間尋址范圍只有64KB，CC2530把內部256KB flash分成8個bank，每一個bank大小是32KB，通過寄存器FMAP.MAP[2：0]選擇不同的bank映射到代碼存儲空間，解決了尋址空間受限的問題。

　　對于OTA客戶端，啟動代碼位于bank0的0x0000到0x0800地址區域，大小為2KB。其余的254KB的flash空間，用來存儲當前固件和其他信息。值得注意的是，0x0888~0x088B區域存放了CRC校驗信息，0x088C~0x0897區域存放了PREAMBLE，即鏡像大小，制造商ID，鏡像類型和鏡像版本號信息。另外，bank7最后的14KB空間（0x7C800~0x7FFFF）用作非易失性（None volatile， NV）變量區（12KB）和特定信息保留區（2KB）。

　　OTA系統升級方案有兩種，分別是片內flash升級和片外flash升級。片內flash的方案是把256KB的flash大小分成兩半，前一半（第一存儲區）提供給當前運行鏡像存儲，后一半（第二存儲區）提供給新鏡像存儲；片外flash的方案是把片內flash作為第一存儲區，外擴的flash作為第二存儲區。考慮到一般程序固件大小都超過128KB，和以后程序功能升級的擴展性，本文采用片外flash的方案。采用的片外flash（M25PE20）容量為256KB，通過SPI總線與CC2530之間傳輸數據。

　　2. 2軟件系統

　　對于基于任務事件輪詢機制的Z-Stack工程，默認是沒有添加OTA功能。如果節點需要開啟OTA功能，首先需要燒寫OTA的啟動代碼。當節點完成鏡像接收之后，對新鏡像進行CRC校驗，并清空當前鏡像的CRC信息，然后重啟。當節點重啟后，首先跳轉到啟動代。

　　碼的地址，開始執行如圖3所示的工作流程。由于內部鏡像的CRC信息被清空，所以被判斷為不正確而執行下一步。由于為0的CRC信息標志著不需要被重新校驗，故執行將新鏡像復制到片內Flash的操作，并產生新鏡像的CRC信息。然后，重新執行啟動代碼。新鏡像啟動時讀取其CRC信息，再次判斷后跳轉到應用程序區，完成整個啟動過程。

　　3. OTA的鏡像頁請求實現

　　根據ZigBee OTA的規范，OTA客戶端向OTA服務器請求鏡像的方式有兩種，分別是鏡像塊請求與鏡像頁請求。前者是基于二次握手機制，鏡像塊請求包含了已下載鏡像的偏移量(File offset)與每次傳輸的鏡像塊大小等信息。當OTA服務器接收到該請求后，根據請求節點的短地址，鏡像偏移量和鏡像塊大小等信息，通過串口向OTA應用控制臺索取特定的鏡像塊。隨后，OTA服務器回復的鏡像塊響應包含了該鏡像塊數據。當節點收到鏡像塊數據后，把塊數據寫到第二存儲區，隨即更新下載鏡像的偏移量，并準備下一輪的請求。

　　鏡像塊請求的優點是能夠通過二次握手機制，確保每次傳輸的鏡像塊數據準確無誤。但是大量的請求信息，無疑給整個網絡的流量造成了嚴重的負擔。再者，節點不停地發送請求命令，也加劇了自身的能源損耗。在外界干擾并不嚴重或點對點傳輸的應用場合，節點與服務器交換數據的過程并不會出現大量的丟包現象，基于塊請求的OTA更新方式效率較低。于是需要設計出一種能夠減輕網絡流量，提高效率的更新手段。

　　鏡像塊請求功能在大部分的ZigBee開發平臺上（如TI的Z-Stack協議棧）已得到實現，但并沒有提供鏡像頁請求功能。本文根據ZigBee OTA的規范，在Z-Stack協議棧上設計出鏡像頁請求的更新方式。頁請求命令與塊請求命令類似，在數據幀當中附加了鏡像頁大小（Page Size）與響應間隔(Response Spacing)信息。當OTA服務器收到一次頁請求后，在一定時間間隔內，多次向節點發送塊響應，免去了多次塊請求。其中塊響應的次數由鏡像頁大小決定，時間間隔由響應間隔設定。正因為請求命令的銳減，能夠大大減輕整個網絡流量的負擔，并提高節點的傳輸更新效率。

　　Z-Stack運行在一個OSAL操作系統上，OSAL是一種基于任務事件調度機制的操作系統。每個任務包含若干事件，每個事件對應一個事件號。當一個事件需要產生時，可以通過API函數設置相應的事件號，然后提交給操作系統調度觸發。本文設計的鏡像頁請求功能正是基于這種機制。如圖4所示，OTA服務器為每一個請求更新的節點分配一個事件號，并通過請求節點的短地址索引，設置特定的事件。進入事件后，OTA服務器通過串口向OTA應用控制臺請求鏡像數據塊，并向節點發送鏡像塊數據。通過把事件添加到定時器鏈表，就能夠以響應間隔為時間單位，循環發送鏡像塊數據，直到累計的發送鏡像塊大小等于節點的請求鏡像頁大小，從而完成一次鏡像頁請求的傳輸過程。

　　Z-Stack協議棧有一個MAC定時器為操作系統提供計時。該定時器以每1ms為單位，更新系統的定時器事件鏈表。定時器事件鏈表如圖5所示，鏈表的每一個結點記錄了任務號（task_id），事件號（event_flag）與計時時間( timeout )和下一個結點地址（*next）。圖中ZCL_OTA_MT_READn定義為每個請求節點對應的事件號，Response Spacing即為節點請求的響應間隔，把兩者添加到鏈表當中。當計時時間減為0后，系統自動設定對應的事件號，從而使OTA服務器循環地向OTA應用控制臺索取鏡像塊數據，并向節點發送鏡像塊響應。

　　以下是OTA服務器處理鏡像頁請求的部分代碼段：

　　typedef struct

　　{

　　uint32 SeverfileOffset； //OTA服務器讀取鏡像的偏移量，與OTA客戶端的同步

　　afAddrType_t Psourceaddress； //OTA客戶端短地址

　　zclOTA_FileID_t FileID； //鏡像信息，包括鏡像類型，制造商ID與版本號

　　uint16 ResponseTime； //響應間隔時間

　　uint8 Length； //鏡像塊大小

　　uint8 Count； //鏡像頁計數

　　} zclOTA_Address_Index； //鏡像頁請求屬性結構體

　　zclOTA_Address_Index Address_index[]； //鏡像頁請求屬性結構體數組

　　if ( events & ZCL_OTA_MT_READn ) //處理OTA客戶端鏡像頁請求事件

　　{

　　ZStatus_t status = ZFailure； //初始化狀態值

　　Address_index[n].Count--； //自減鏡像頁計數變量

　　if(Address_index[n].SeverfileOffset >= Imagesize) //判斷鏡像偏移量是否超出鏡像大小

　　{

　　return ( events ^ ZCL_OTA_MT_READn )； //如果超出直接退出事件處理

　　}

　　//OTA服務器根據OTA客戶端的鏡像頁請求信息，向應用控制臺索取鏡像塊數據

　　Status = MT_OtaFileReadReq(&(Address_index[n].Psourceaddress)， &(Address_index[n].FileID)， Address_index[n].Length， Address_index[n].SeverfileOffset)；

　　if (status == ZSuccess) //假如索取成功，累加已請求的鏡像偏移量

　　{

　　Address_index[n].SeverfileOffset += Address_index[n].Length；

　　}

　　if(Address_index[n].Count > 0) //判斷累計的請求鏡像塊大小是否超出鏡像頁大小

　　{

　　//假如沒超出，把該鏡像頁處理時間繼續添加到定時器鏈表，等待下一輪的處理

　　osal_start_timerEx(zclOTA_TaskID， ZCL_OTA_MT_READn，Address_index[n].ResponseTime)；

　　}

　　//結束處理事件，并清除該事件號

　　return ( events ^ ZCL_OTA_MT_READn )；

　　}

　　4. 驗證與分析

　　4. 1功能驗證

　　為了驗證OTA功能，在CC2530F256平臺上搭建一個小型樹狀網絡，并使用Packet Sniffer[13]對OTA更新時的節點進行抓包分析。如圖6(a)所示，四個傳感節點的當前固件并沒有添加溫度采集功能，所以溫度顯示為0；在新的固件中添加了溫度采集函數，用于驗證OTA更新成功。

　　對于某些特定應用，需要節點更新固件后能夠保持原來的網絡拓撲結構。內部Flash的NV區能夠保存節點的網絡信息，只要在工程添加NV_INIT與NV_RESTORE預編譯項，節點在掉電后還能恢復原來網絡信息。

　　對四個傳感節點進行OTA更新。如圖6(b)所示，OTA更新后，溫度采集功能成功添加，而且傳感節點的網絡短地址沒有發生變化，網絡拓撲結構保持完整，驗證了進行OTA鏡像升級過程中，并不會對NV區進行擦除，有利于節點網絡信息的恢復。

　　在OTA更新過程中，應用層的數據幀格式如圖7所示。OTA服務器被配置為路由器（0x06BC），對傳感節點（0x0002）進行點對點更新。第一條短幀是子路由向OTA服務器發送Image Block Request，應用層載荷從第4字節開始記錄了新鏡像的制造商ID（0x5678），鏡像類型（0x1234），版本號（0x00000002）和鏡像塊偏移量。最后1個字節記錄了每次傳送最大鏡像塊大小(OTA_MAX_MTU)，默認為0x20，即為32字節。第二條長幀是OTA服務器發送的Image Block Response，載荷記錄格式與前者類似，并在最大鏡像塊大小字節后面附上32字節鏡像塊信息，從而完成一個鏡像塊傳輸周期。

　　4. 2效率分析

　　搭建一個星形網絡，把OTA服務器配置成協調器，把所有OTA客戶端配置成節點，并進行如下兩個實驗。

　　實驗一（測試數據如表1、表2所示）：為了對比分析兩種更新手段的效率，分別使用鏡像塊請求命令與鏡像頁請求命令，對節點進行OTA更新。星形網絡中，通過廣播Image Notify，能夠對多節點進行批量更新。網絡規模分別為1個節點到6個節點，測量了不同規模網絡下節點完成更新傳輸所需的時間。Min與Max分別指最快與最慢完成更新傳輸的節點對應的時間，Ave指平均每個節點完成更新傳輸所需時間（使用Max值計算）。其中鏡像頁請求設置的Response Spacing為100ms，Page size為640字節。鏡像大小統一為113K字節，并修改OTA_MAX_MTU大小為64字節。節點與OTA服務器間隔均為5米。

　　實驗二（測試數據如表3所示）：為了測試鏡像頁請求在點對點更新情況下的最高效率，設定最短的Response Spacing為10ms，分別測量不同Page Size下的單個節點更新傳輸時間。使用CC2531（支持USB）作為OTA服務器，能夠縮短服務器向應用控制臺索取鏡像塊數據的時間，進一步加快更新傳輸效率。鏡像大小統一為113K字節，OTA_MAX_MTU大小為64字節，節點與OTA服務器間隔均為5米。

　　表3 不同鏡像頁大小下的傳輸時間（Response Spacing = 10ms）

　　實驗一中，使用鏡像塊請求，節點發送鏡像塊請求所需時間為15.5ms，OTA服務器返回鏡像塊響應所需時間實際為96ms左右，來回確認幀時間大概為1.92+3.84=5.76ms。一個更新周期傳輸鏡像塊大小為64字節，完成113K字節大小的鏡像傳送需要1765個周期。總時間為（96+15.5+5.76）*1765=206963ms，這與表1測量值207.2基本符合。本文設計的鏡像頁請求，鏡像頁大小為640字節，每次傳輸鏡像塊大小為64字節，即節點發送1次頁請求可以得到10次塊響應。當更新1個節點時，使用鏡像頁請求可以把原來的1765條請求命令和1765條確認幀減少十分之九，共減少3177條傳輸幀。減少的傳輸幀數量隨著節點數目成比例增長。對比表1與表2，可以發現無論節點數目為多少，頁請求的平均每個節點的更新傳輸時間都比塊請求的要短。其中發送鏡像頁請求時間為15.5ms，請求確認幀時間為1.92ms，節點為1時，共減少時間為（15.5+1.92）*1765*0.9=27672ms，此值與表1表2的測量值207.2-179.6=27.6s基本符合。

　　實驗二中，由于采用了支持USB的CC2531，能夠把OTA服務器返回的鏡像塊響應所需時間縮短為22.5ms，節點發送鏡像頁請求所需時間保持為15.5ms不變，來回確認幀時間為5.76ms。當鏡像頁大小為64字節時，傳輸所需時間為（22.5+15.5+5.76）*1765=77236ms，也與表3的測量值77.2基本相符。當鏡像頁大小為6400字節時候，即請求命令減少到原來的百分之一，時間縮短了50s，更新效率大幅度提高，基本達到了單個節點更新速度的極限。

　　5. 結論

　　介紹了一種基于ZigBee的空中下載技術，非常適用于短距離的無線傳感網絡應用場合。通過無線更新固件，免去了回收更新節點所需時間，可以達到更新完成后不破壞當前網絡拓撲結構的效果。另外，在Z-Stack協議棧設計了一種鏡像頁請求更新方式，實驗結果表明，當批量更新整個網絡時，既可以提高節點的更新效率，又可以大大減少網絡的更新流量，并節省節點的功耗；當進行點對點更新時，如果把響應間隔縮減為10ms，并把鏡像頁設置為足夠大，單個節點的更新時間可以縮減為27.3s，接近單個節點更新速度的極限。至于使用批量的更新方式還是點對點的更新方式，視具體的應用場合而定。

　　參考文獻

　　[1] 劉云浩. 物聯網導論[M]. 北京：科學出版社，2011：303-312.

　　[2] 陳固杰. 空中下載技術在移動互聯網中的應用[J]. 現代通信，2002（6）：3-4.

　　[3] Akyildiz I F，Su W L，Sankarasubramaniam Y，et al. A survey on sensor Networks[J]. IEEE Communications Magazine，2002，40（8）：102-114.

　　[4] Wang Q，Zhu Y Y，Cheng L. Reprogramming wireless sensor networks: challenges and approaches[J]. IEEE Network，2006，20（3）：48-55.

　　[5] 曾照星，蔣澤軍，王麗芳等. 無線傳感器網絡代碼更新協議研究[J]. 計算機測量與控制，2008，16（9）：1359-1362.

　　[6] Crossbow Technology，Inc. Mote In-Network Programming User Reference[EB/OL]. 2003.http://webs.cs.berkeley.edu/tos/tinyos-1.x/doc/Xnp.pdf/.

　　[7] Hui J W，Culler D. The Dynamic Behavior of a Data Dissemination Protocol for Network

　　Programming at Scale[C]. New York: SenSys04 Proceedings of the 2nd international conference，2004: 81-94．

　　[8] Farahani S. ZigBee Wireless Networks and Transceivers[M]. Oxford: Elsevier Publication，2008: 1-23.

　　[9] Texas Instruments Inc. Z-Stack Users Guide[EB/OL]. 2011，http://www.ti. com/ tool/z-stack&DCMP=HPA_RFIC_General&HQS=Other+OT+z-stack/.

　　[10] ZigBee Alliance. ZB_ZARC_Interest_OTA_Upgrade_Cluster_Specification[EB/OL].2010，http://www.zigbee.org/.

　　[11] 侯彤. 無線傳感器網絡空中加載技術的研究[D]. 西安：西安電子科技大學學位論文，2011.

　　[12] Texas Instruments Inc. A True System-on-Chip Solution for 2.4-GHz IEEE 802.15.4 and ZigBee Applications[EB/OL]. 2010，http://www.ti.com/product/cc2530/.

　　[13] Chipcon Inc. Packet Sniffer User Manual[EB/OL]. 2004，http://www.chipcon.com./