引言
本文移植并驗證了一種基于ZigBee協議的空中下載(OTA)技術，其分發(fā)協議支持點對多傳輸更新功能，多跳網絡的代碼分發(fā)功能由路由協議支撐。在Z-Stack協議棧下，僅僅支持鏡像塊請求功能，更新效率并不理想。針對此問題，設計出一種高效的鏡像頁請求功能，能夠提高點對多的傳輸更新效率，并減少網絡流量。
1 OTA概述
ZigBee協議規(guī)范使用了IEEE 802．15．4定義的物理層(PHY)和媒體介質訪問層(MAC)，并在此基礎上定義了網絡層(NWK)和應用層(APL)。針對無線傳感網絡重編程技術的需求，ZigBee聯盟在原有協議的框架上，提出了一種OTA規(guī)范，其作為一個系統可選的功能模塊。OTA系統的結構示意圖和服務器與客戶端之間的數據交互過程略——編者注。
2 OTA系統設計
本文的OTA系統基于TI公司的ZigBee SoC芯片CC2530F256設計，包括硬件與軟件的設計。
2．1 硬件系統
CC2530F256內部集成一個增強型8051單片機，擁有8 KB SRAM和256 KB內部Flash存儲器。內部Flash主要用來保存程序代碼和常量數據。由于傳統8051代碼存儲空間尋址范圍只有64 KB，CC2530把內部256 KBFlash分成8個bank，每一個bank大小是32 KB，通過寄存器FMA P．MAP[2：0]選擇不同的bank映射到代碼存儲空間，解決了尋址空間受限的問題。
對于OTA客戶端，啟動代碼位于bank0的0x0000～0x0800地址區(qū)域，大小為2 KB。其余的254 KB的Flash空間，用來存儲當前固件和其他信息。值得注意的是，0x0888～0x088B區(qū)域存放了CRC校驗信息，0x088C～0x0897區(qū)域存放了PREAMBLE，包括鏡像大小、制造商ID、鏡像類型和鏡像版本號信息。另外，bank7最后的14 KB空間(0x7C800～0x7FFFF)用作非易失性(None Volatile，NV)變量區(qū)(12 KB)和特定信息保留區(qū)(2 KB)。
OTA系統升級方案有兩種，分別是片內Flash升級和片外Flash升級。考慮到一般程序固件大小都超過128KB和以后程序功能升級的擴展性，本文采用片外Flash的方案。采用的片外Flash(M25PE20)容量為256 KB，通過SPI總線與CC2530之間傳輸數據。
2．2 軟件系統
對于基于任務事件輪詢機制的Z-Stack工程，默認沒有添加OTA功能。如果節(jié)點需要開啟OTA功能，首先需要燒寫OTA的啟動代碼。當節(jié)點完成鏡像接收之后，對新鏡像進行CRC校驗，并清空當前鏡像的CRC信息，然后重啟。當節(jié)點重啟后，首先跳轉到啟動代碼的地址，開始執(zhí)行如圖1所示的工作流程。
3 OTA的鏡像頁請求實現
根據ZigBee OTA的規(guī)范，OTA客戶端向OTA服務器請求鏡像的方式有兩種，分別是鏡像塊請求與鏡像頁請求。鏡像塊請求的OTA更新方式效率較低。
本文根據ZigBee OTA的規(guī)范，在Z-Stack協議棧上設計出鏡像頁請求的更新方式。頁請求命令與塊請求命令類似，在數據幀當中附加了鏡像頁大小與響應間隔信息。當OTA服務器收到一次頁請求后，在一定時間間隔內多次向節(jié)點發(fā)送塊響應，免去了多次塊請求。其中，塊響應的次數由鏡像頁大小決定，時間間隔由響應間隔設定。正因為請求命令的銳減，能夠大大減輕整個網絡流量的負擔，并提高節(jié)點的傳輸更新效率。
Z-Stack運行在一個OSAL操作系統上，OSAL是一種基于任務事件調度機制的操作系統。每個任務包含若干事件，每個事件對應一個事件號。當一個事件需要產生時，可以通過API函數設置相應的事件號，然后提交給操作系統調度觸發(fā)。本文設計的鏡像頁請求功能正是基于這種機制。OTA服務器的鏡像頁請求處理流程如圖2所示，OTA服務器為每一個請求更新的節(jié)點分配一個事件號，并通過請求節(jié)點的短地址索引，設置特定的事件。進入事件后，OTA服務器通過串口向OTA應用控制臺請求鏡像數據塊，并向節(jié)點發(fā)送鏡像塊數據。通過把事件添加到定時器鏈表，就能夠以響應間隔為時間單位，循環(huán)發(fā)送鏡像塊數據，直到累計的發(fā)送鏡像塊大小等于節(jié)點的請求鏡像頁大小，從而完成一次鏡像頁請求的傳輸過程。
Z-Stack協議棧有一個MAC定時器為操作系統提供計時。該定時器以每1 ms為單位，更新系統的定時器事件鏈表。定時器事件鏈表如圖3所示，鏈表的每一個結點記錄了任務號(task_id)、事件號(event_flag)，計時時間(timeout)和下一個結點地址(*next)。圖中的ZCL_OTA_MT_ READ n定義為每個請求節(jié)點對應的事件號，Response Spacing即為節(jié)點請求的響應間隔，把兩者添加到鏈表當中。當計時時間減為0后，系統自動設定對應的事件號，從而使OTA服務器循環(huán)地向OTA應用控制臺索取鏡像塊數據，并向節(jié)點發(fā)送鏡像塊響應。
OTA服務器處理鏡像頁請求的部分代碼段如下：
4 驗證與分析
4．1 功能驗證
為了驗證OTA功能，在CC2530F256平臺上搭建一個小型樹狀網絡，并使用Packet Sniffer對OTA更新時的節(jié)點進行抓包分析。4個傳感節(jié)點的固件并沒有添加溫度采集功能，所以溫度顯示為0。在新的固件中添加了溫度采集函數，用于驗證OTA更新成功。
對于某些特定應用，需要節(jié)點更新固件后能夠保持原來的網絡拓撲結構。內部Flash的NV區(qū)能夠保存節(jié)點的網絡信息，只要在工程添加NV_INIT與NV_RESTORE預編譯項，節(jié)點在掉電后還能恢復原來網絡信息。
對4個傳感節(jié)點進行OTA更新。OTA更新后，溫度采集功能成功添加，而且傳感節(jié)點的網絡短地址沒有發(fā)生變化，網絡拓撲結構保持完整，驗證了進行OTA鏡像升級過程中，并不會對NV區(qū)進行擦除，有利于節(jié)點網絡信息的恢復。
OTA服務器被配置為路由器(0x06BC)，對傳感節(jié)點(0x0002)進行點對點更新。第一條短幀是子路由向OTA服務器發(fā)送Image Block Reque st，應用層載荷從第4字節(jié)開始記錄了新鏡像的制造商ID(0x5678)、鏡像類型(0x1234)、版本號(0x00000002)和鏡像塊偏移量。最后1個字節(jié)記錄了每次傳送最大鏡像塊大小(OTA_MAX_MTU)，默認為0x20，即為32字節(jié)。第二條長幀是OTA服務器發(fā)送的Image Block Response，載荷記錄格式與前者類似，并在最大鏡像塊大小字節(jié)后面附上32字節(jié)鏡像塊信息，從而完成一個鏡像塊傳輸周期。
4．2 效率分析
搭建一個星形網絡，把OTA服務器配置成協調器，把所有OTA客戶端配置成節(jié)點，并進行如下兩個實驗。
4．2．1 實驗一
為了對比分析兩種更新手段的效率，分別使用鏡像塊請求命令與鏡像頁請求命令，對節(jié)點進行OTA更新。星形網絡中，通過廣播Image Notify，能夠對多節(jié)點進行批量更新。網絡規(guī)模分別為1～6個節(jié)點，測量了不同規(guī)模網絡下節(jié)點完成更新傳輸所需的時間。Min與Max分別
指最快與最慢完成更新傳輸的節(jié)點對應的時間，Ave指平均每個節(jié)點完成更新傳輸所需時間(使用Max值計算)。
其中，鏡像頁請求設置的Response Spacing為100 ms，鏡像頁大小為640字節(jié)。鏡像大小統一為113 KB，并修改OTA_MAX_MTU大小為64字節(jié)。節(jié)點與OTA服務器間隔均為5 m。鏡像塊、鏡像頁請求的傳輸時間分別如表1、表2所列，響應間隔均為100 ms。
實驗一中，使用鏡像塊請求，節(jié)點發(fā)送鏡像塊請求所需時間為15．5 ms，OTA服務器返回鏡像塊響應所需時間實際為96 ms，來回確認幀時間大概為1．92+3．84=5．76ms。一個更新周期傳輸鏡像塊大小為64字節(jié)，完成113KB大小的鏡像傳送需要1765個周期。總時間為(96+15．5 +5．76)×1765=206 963 ms，這與表1中的測量值207．2 s基本符合。
本文設計的鏡像頁請求中鏡像頁大小為640字節(jié)，每次傳輸鏡像塊大小為64字節(jié)，即節(jié)點發(fā)送1次頁請求可以得到10次塊響應。當更新1個節(jié)點時，使用鏡像頁請求可以把原來的1 765條請求命令和1 765條確認幀減少9／10，共減少3 177條傳輸幀。減少的傳輸幀數量隨著節(jié)點數目成比例增長。
對比表1與表2，可以發(fā)現無論節(jié)點數目為多少，頁請求的平均每個節(jié)點的更新傳輸時間都比塊請求的要短。其中，發(fā)送鏡像頁請求時間為15．5 ms，請求確認幀時間為1．92 ms，節(jié)點為1時，共減少時間為(15．5+1．92)×1765×0．9=27 672 ms，此值與表1和表2的測量值207．2-179．6=27．6 s基本符合。
4．2．2 實驗二
為了測試鏡像頁請求在點對點更新情況下的最高效率，設定最短的響應間隔為10 ms，分別測量不同鏡像頁大小的單個節(jié)點更新傳輸時間。使用CC2531(支持USB)作為OTA服務器，能夠縮短服務器向應用控制臺索取鏡像塊數據的時間，進一步加快更新傳輸效率。鏡像大小統一為113 KB，OTA_MAX_MTU大小為64字節(jié)，節(jié)點與OTA服務器間隔均為5 m。不同鏡像頁大小下的傳輸時間如表3所列。
實驗二中，由于采用了支持USB的CC2531，能夠把OTA服務器返回的鏡像塊響應所需時間縮短為22．5ms，節(jié)點發(fā)送鏡像頁請求所需時間保持為15．5 ms不變，來回確認幀時間為5．76 ms。當鏡像頁大小為64字節(jié)時，傳輸所需時間為(22．5+15．5+5．76)×1765=77 236ms，也與表3中的測量值77．2 s基本相符。當鏡像頁大小為6 400字節(jié)時，即請求命令減少到原來的1／100，時間縮短了50 s，更新效率大幅度提高，基本達到了單個節(jié)點更新速度的極限。
結語
通過無線更新固件，免去了回收更新節(jié)點所需時間，可以達到更新完成后不破壞當前網絡拓撲結構的效果。另外，在Z-Stack協議棧設計了一種鏡像頁請求更新方式，實驗結果表明，當批量更新整個網絡時，既可以提高節(jié)點的更新效率，又可以大大減小網絡的更新流量，并節(jié)省節(jié)點的功耗。當進行點對點更新時，如果把響應間隔縮減為10 ms，并把鏡像頁設置得足夠大，單個節(jié)點的更新時間可以縮減為27．3 s，接近單個節(jié)點更新速度的極限。至于使用批量的更新方式還是點對點的更新方式，視具體的應用場合而定。