摘要：首先介紹基于ZigBee協(xié)議的OTA系統(tǒng)，并在CC2530F256硬件平臺上進行驗證。在Z-Staek協(xié)議棧中，設(shè)計出一種鏡像頁請求的空中下載(Over the Air，OTA)更新方式，并通過實驗測試，與原有的鏡像塊請求方式進行了比較分析。實驗結(jié)果表明，鏡像頁請求方式可以大大減少網(wǎng)絡(luò)的更新流量，從而提高節(jié)點的更新效率。
關(guān)鍵詞：無線傳感網(wǎng)絡(luò)；ZigBee；空中下載；鏡像塊請求；鏡像頁請求；更新效率

引言
    本文移植并驗證了一種基于ZigBee協(xié)議的空中下載(OTA)技術(shù)，其分發(fā)協(xié)議支持點對多傳輸更新功能，多跳網(wǎng)絡(luò)的代碼分發(fā)功能由路由協(xié)議支撐。在Z-Stack協(xié)議棧下，僅僅支持鏡像塊請求功能，更新效率并不理想。針對此問題，設(shè)計出一種高效的鏡像頁請求功能，能夠提高點對多的傳輸更新效率，并減少網(wǎng)絡(luò)流量。

1 OTA概述
    ZigBee協(xié)議規(guī)范使用了IEEE 802．15．4定義的物理層(PHY)和媒體介質(zhì)訪問層(MAC)，并在此基礎(chǔ)上定義了網(wǎng)絡(luò)層(NWK)和應(yīng)用層(APL)。針對無線傳感網(wǎng)絡(luò)重編程技術(shù)的需求，ZigBee聯(lián)盟在原有協(xié)議的框架上，提出了一種OTA規(guī)范，其作為一個系統(tǒng)可選的功能模塊。OTA系統(tǒng)的結(jié)構(gòu)示意圖和服務(wù)器與客戶端之間的數(shù)據(jù)交互過程略——編者注。

2 OTA系統(tǒng)設(shè)計
    本文的OTA系統(tǒng)基于TI公司的ZigBee SoC芯片CC2530F256設(shè)計，包括硬件與軟件的設(shè)計。
2．1 硬件系統(tǒng)
    CC2530F256內(nèi)部集成一個增強型8051單片機，擁有8 KB SRAM和256 KB內(nèi)部Flash存儲器。內(nèi)部Flash主要用來保存程序代碼和常量數(shù)據(jù)。由于傳統(tǒng)8051代碼存儲空間尋址范圍只有64 KB，CC2530把內(nèi)部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系統(tǒng)升級方案有兩種，分別是片內(nèi)Flash升級和片外Flash升級。考慮到一般程序固件大小都超過128KB和以后程序功能升級的擴展性，本文采用片外Flash的方案。采用的片外Flash(M25PE20)容量為256 KB，通過SPI總線與CC2530之間傳輸數(shù)據(jù)。
2．2 軟件系統(tǒng)
    對于基于任務(wù)事件輪詢機制的Z-Stack工程，默認沒有添加OTA功能。如果節(jié)點需要開啟OTA功能，首先需要燒寫OTA的啟動代碼。當節(jié)點完成鏡像接收之后，對新鏡像進行CRC校驗，并清空當前鏡像的CRC信息，然后重啟。當節(jié)點重啟后，首先跳轉(zhuǎn)到啟動代碼的地址，開始執(zhí)行如圖1所示的工作流程。

3 OTA的鏡像頁請求實現(xiàn)
    根據(jù)ZigBee OTA的規(guī)范，OTA客戶端向OTA服務(wù)器請求鏡像的方式有兩種，分別是鏡像塊請求與鏡像頁請求。鏡像塊請求的OTA更新方式效率較低。
    本文根據(jù)ZigBee OTA的規(guī)范，在Z-Stack協(xié)議棧上設(shè)計出鏡像頁請求的更新方式。頁請求命令與塊請求命令類似，在數(shù)據(jù)幀當中附加了鏡像頁大小與響應(yīng)間隔信息。當OTA服務(wù)器收到一次頁請求后，在一定時間間隔內(nèi)多次向節(jié)點發(fā)送塊響應(yīng)，免去了多次塊請求。其中，塊響應(yīng)的次數(shù)由鏡像頁大小決定，時間間隔由響應(yīng)間隔設(shè)定。正因為請求命令的銳減，能夠大大減輕整個網(wǎng)絡(luò)流量的負擔，并提高節(jié)點的傳輸更新效率。
    Z-Stack運行在一個OSAL操作系統(tǒng)上，OSAL是一種基于任務(wù)事件調(diào)度機制的操作系統(tǒng)。每個任務(wù)包含若干事件，每個事件對應(yīng)一個事件號。當一個事件需要產(chǎn)生時，可以通過API函數(shù)設(shè)置相應(yīng)的事件號，然后提交給操作系統(tǒng)調(diào)度觸發(fā)。本文設(shè)計的鏡像頁請求功能正是基于這種機制。OTA服務(wù)器的鏡像頁請求處理流程如圖2所示，OTA服務(wù)器為每一個請求更新的節(jié)點分配一個事件號，并通過請求節(jié)點的短地址索引，設(shè)置特定的事件。進入事件后，OTA服務(wù)器通過串口向OTA應(yīng)用控制臺請求鏡像數(shù)據(jù)塊，并向節(jié)點發(fā)送鏡像塊數(shù)據(jù)。通過把事件添加到定時器鏈表，就能夠以響應(yīng)間隔為時間單位，循環(huán)發(fā)送鏡像塊數(shù)據(jù)，直到累計的發(fā)送鏡像塊大小等于節(jié)點的請求鏡像頁大小，從而完成一次鏡像頁請求的傳輸過程。

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

    OTA服務(wù)器處理鏡像頁請求的部分代碼段如下：
   
   

4 驗證與分析
4．1 功能驗證
    為了驗證OTA功能，在CC2530F256平臺上搭建一個小型樹狀網(wǎng)絡(luò)，并使用Packet Sniffer對OTA更新時的節(jié)點進行抓包分析。4個傳感節(jié)點的固件并沒有添加溫度采集功能，所以溫度顯示為0。在新的固件中添加了溫度采集函數(shù)，用于驗證OTA更新成功。
    對于某些特定應(yīng)用，需要節(jié)點更新固件后能夠保持原來的網(wǎng)絡(luò)拓撲結(jié)構(gòu)。內(nèi)部Flash的NV區(qū)能夠保存節(jié)點的網(wǎng)絡(luò)信息，只要在工程添加NV_INIT與NV_RESTORE預(yù)編譯項，節(jié)點在掉電后還能恢復(fù)原來網(wǎng)絡(luò)信息。
    對4個傳感節(jié)點進行OTA更新。OTA更新后，溫度采集功能成功添加，而且傳感節(jié)點的網(wǎng)絡(luò)短地址沒有發(fā)生變化，網(wǎng)絡(luò)拓撲結(jié)構(gòu)保持完整，驗證了進行OTA鏡像升級過程中，并不會對NV區(qū)進行擦除，有利于節(jié)點網(wǎng)絡(luò)信息的恢復(fù)。
    OTA服務(wù)器被配置為路由器(0x06BC)，對傳感節(jié)點(0x0002)進行點對點更新。第一條短幀是子路由向OTA服務(wù)器發(fā)送Image Block Reque st，應(yīng)用層載荷從第4字節(jié)開始記錄了新鏡像的制造商ID(0x5678)、鏡像類型(0x1234)、版本號(0x00000002)和鏡像塊偏移量。最后1個字節(jié)記錄了每次傳送最大鏡像塊大小(OTA_MAX_MTU)，默認為0x20，即為32字節(jié)。第二條長幀是OTA服務(wù)器發(fā)送的Image Block Response，載荷記錄格式與前者類似，并在最大鏡像塊大小字節(jié)后面附上32字節(jié)鏡像塊信息，從而完成一個鏡像塊傳輸周期。
4．2 效率分析
    搭建一個星形網(wǎng)絡(luò)，把OTA服務(wù)器配置成協(xié)調(diào)器，把所有OTA客戶端配置成節(jié)點，并進行如下兩個實驗。
4．2．1 實驗一
    為了對比分析兩種更新手段的效率，分別使用鏡像塊請求命令與鏡像頁請求命令，對節(jié)點進行OTA更新。星形網(wǎng)絡(luò)中，通過廣播Image Notify，能夠?qū)Χ喙?jié)點進行批量更新。網(wǎng)絡(luò)規(guī)模分別為1～6個節(jié)點，測量了不同規(guī)模網(wǎng)絡(luò)下節(jié)點完成更新傳輸所需的時間。Min與Max分別
指最快與最慢完成更新傳輸?shù)墓?jié)點對應(yīng)的時間，Ave指平均每個節(jié)點完成更新傳輸所需時間(使用Max值計算)。
其中，鏡像頁請求設(shè)置的Response Spacing為100 ms，鏡像頁大小為640字節(jié)。鏡像大小統(tǒng)一為113 KB，并修改OTA_MAX_MTU大小為64字節(jié)。節(jié)點與OTA服務(wù)器間隔均為5 m。鏡像塊、鏡像頁請求的傳輸時間分別如表1、表2所列，響應(yīng)間隔均為100 ms。

    實驗一中，使用鏡像塊請求，節(jié)點發(fā)送鏡像塊請求所需時間為15．5 ms，OTA服務(wù)器返回鏡像塊響應(yīng)所需時間實際為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基本符合。
    本文設(shè)計的鏡像頁請求中鏡像頁大小為640字節(jié)，每次傳輸鏡像塊大小為64字節(jié)，即節(jié)點發(fā)送1次頁請求可以得到10次塊響應(yīng)。當更新1個節(jié)點時，使用鏡像頁請求可以把原來的1 765條請求命令和1 765條確認幀減少9／10，共減少3 177條傳輸幀。減少的傳輸幀數(shù)量隨著節(jié)點數(shù)目成比例增長。
    對比表1與表2，可以發(fā)現(xiàn)無論節(jié)點數(shù)目為多少，頁請求的平均每個節(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 實驗二
    為了測試鏡像頁請求在點對點更新情況下的最高效率，設(shè)定最短的響應(yīng)間隔為10 ms，分別測量不同鏡像頁大小的單個節(jié)點更新傳輸時間。使用CC2531(支持USB)作為OTA服務(wù)器，能夠縮短服務(wù)器向應(yīng)用控制臺索取鏡像塊數(shù)據(jù)的時間，進一步加快更新傳輸效率。鏡像大小統(tǒng)一為113 KB，OTA_MAX_MTU大小為64字節(jié)，節(jié)點與OTA服務(wù)器間隔均為5 m。不同鏡像頁大小下的傳輸時間如表3所列。

    實驗二中，由于采用了支持USB的CC2531，能夠把OTA服務(wù)器返回的鏡像塊響應(yīng)所需時間縮短為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é)語
    通過無線更新固件，免去了回收更新節(jié)點所需時間，可以達到更新完成后不破壞當前網(wǎng)絡(luò)拓撲結(jié)構(gòu)的效果。另外，在Z-Stack協(xié)議棧設(shè)計了一種鏡像頁請求更新方式，實驗結(jié)果表明，當批量更新整個網(wǎng)絡(luò)時，既可以提高節(jié)點的更新效率，又可以大大減小網(wǎng)絡(luò)的更新流量，并節(jié)省節(jié)點的功耗。當進行點對點更新時，如果把響應(yīng)間隔縮減為10 ms，并把鏡像頁設(shè)置得足夠大，單個節(jié)點的更新時間可以縮減為27．3 s，接近單個節(jié)點更新速度的極限。至于使用批量的更新方式還是點對點的更新方式，視具體的應(yīng)用場合而定。