摘要：首先介紹了以TI的無線傳感器網絡芯片CC2530為核心部件的節點硬件實現，接著介紹TinyOS操作系統的運行機制及其在CC2530平臺下的移植過程；并在此基礎上以nesC語言實現了AODV路由協議，最后對系統進行組網測試，測試結果表明平臺各功能正常運行并且實現AODV協議的基本功能。
關鍵詞：無線傳感器網絡；TinyOS；CC2530；AODV

0 引言
無線傳感器網絡(Wireless Sensor Network)是由具有感知、計算和通信能力的大量微型傳感器節點組成，被廣泛地應用于國防軍事、環境監測等領域。加州大學Berkeley分校設計的基于事件驅動、組件模塊化的無線傳感器網絡操作系統TinyOS具有核心程序小、對硬件要求低等優勢，但它不支持功能強大的無線傳感網絡芯片CC2530，為此需要將TinyOS移植至CC2530平臺，以使其得到更好的應用。同時為了節省傳輸能量，需要采用相應的路由協議，以多跳中繼的方式將數據經由多個節點組成的路由傳回匯聚節點或基站。
本文選用TI的CC2530作為傳感器節點的核心部件，采用Tiny OS操作系統作為軟件平臺，成功將Tiny OS移植至CC2530平臺，并添加了Tim er、UART、RF等組件；在移植的平臺上，以nesC語言實現了AODV路由協議，并且實現了傳感器節點的組網，數據包的多跳轉發；為TinyOS和AODV的研究和應用奠定基礎。

1 無線傳感器網絡系統結構
1．1 傳感器節點硬件結構
傳感器節點一般由供電單元、數據采集單元、數據處理單元(由微控制器和存儲器組成)、無線通信單元組成。其中，數據處理單元中的微控制器負責對其他三個單元的控制。
本文的系統采用無線傳感器網絡節點芯片CC2530作為微控制器。CC2530使用了增強型8051CPU，運行時鐘頻率為32 MHz，具有8 KB RAM；包括一個普通16位定時器和兩個8位定時器，21個可編程程I／O引腳，兩個支持多種串行通信協議的USART，一個符合IEEE 802．15．4標準的2．4 GHz無線收發器和MAC定時器。CC2530是用于IEEE．802．1 5．4，ZigBee和RF4CE應用的一個真正的片上系統(SoC)解決方案。本文節點核心部分的硬件設計如圖1所示。

TinyOS采用基于事件驅動、兩層調度的并發模型。內核支持兩種執行線程，即中斷處理和任務，主控構件維護兩個數據結構支持內核的兩層調度：中斷向量表和任務隊列。TinyOS系統采用組件化思想，其應用程序都是由若干個模塊組件和配置組件構成的，其組件有四個相互關聯的部分：一組命令處理程序句柄，一組事件處理程序句柄，一個經過封裝的私有數據幀，一組簡單任務。每一個組件聲明自己使用的接口及其需要用信號的通知的事件。一個應用程序的組件結構圖如圖2所示，高層次的組件通過命令調用低層次組件，低層次組件發送信號事件給高層次組件，最低層次組件直接與硬件相互作用。
1．3 TinyOS操作系統移植
1．3．1 修改編譯工具鏈
TinyOS開發環境為Unix，若要為TinyOS開發應用程序，首先要使用nesC進行編程，產生以“．nc”為擴展名的源文件；然后再調用Unix的NCC(nesC Compiler)編譯器將源文件編譯成硬件可以執行的二進制／十六進制機器碼，如圖3(a)所示。

但nesC的編譯器NCC調用的是Unix的GCC(GNU Compiler Collection)編譯器，而GCC編譯器并不支持CC2530所使用的8051處理器。為此，需要在編譯過程使用Perl語言，轉換C語言編譯器不能識別的nesC關鍵字，將nesC語言編寫的“．nc”文件編譯為常規的C語言源文件，然后繞過Unix的GCC編譯器，改由支持8051的Keil進行編譯，其過程如圖3(b)所示。具體的實現為編寫腳本文件mangleAppC．pl，在編譯規則文“．rules”中添加該Perl腳本的引用，以生成中間文件App．preMangle．c，并通過建立批處理文件CC2530F256．bat，調用Keil程序編譯生成目標文件App．hex。
1．3．2 TinyOS平臺搭建
TinyOS應用程序的編譯是以平臺為對象的，但TinyOS并不支持CC2530平臺，因此必須先建立能被TinyOS承認的平臺。根據TinyOS最小平臺的定義，需要創建的目錄及編寫的文件為：
(1)／tos／platforms／cc2530目錄，及其下的“．platform”文件、platform．h、PlatformC．nc和PlatformP．nc文件，這些文件包含平臺初始化的實現代碼和平臺的環境變量；
(2)／tos／support／make下的CC2530em．target文件，包含移植代碼的目標平臺的識別信息；
(3)／tos／support／make／mcs51下的“．rules”文件，包含生成目標平臺二進制／十六進制可執行代碼時的編譯說明；
(4)／tos／chips／mcs51下的hardware．h和McuSleepC．nc文件，包含平臺硬件體系必備的宏定義和低功耗機制實現代碼。
1．3．3 基于CC2530的組件編寫
TinyOS應用程序是由一系列組件鏈接而成，其中包括用于實現應用程序功能的組件、系統提供的用于實現常用功能的組件和針對不同芯片的硬件表達和抽象組件。由于TinyOS本身并不含有針對CC2530平臺的硬件表達和抽象組件，因此需要編寫直接與硬件相互作用的組件來完成移植。編寫以下幾個重要的組件：
(1)IO口組件，通過建立HplCC2530GeneralIOC組件來提供兩類系統接口GeneralIO和Init。
(2)Timer組件，主要由TimerMilli組件、HilTimerMilliC配置組件、HplCC2530TimerlAlarmCounterP組件等組成，用于產生以毫秒為單位的計時器。
(3)Uart組件，由StdOut組件、PlatformSerialC配置組件、HalCC2530SimpleUartP組件等組成，用于實現串口收發功能。
(4)RF組件，主要由ActiveMessageC配置組件、CC2530ActiveMessageP模塊組件、CC2530TransmitP模塊組件、HalCC2530Radio模塊組件和HplCC2530InterruptsC模塊組件構成，用于實現基本無線數據傳輸功能。

2 TinyOS下的AODV路由實現
AODV是一種適用于無線傳感器網絡的按需路由協議，采用最短路由選路，注重網絡吞吐量和網絡服務質量，實現簡單。本文以TinyOS作為系統的軟件平臺，根據TinyOS操作系統的應用程序結構，以nesC語言實現了AODV路由協議。
2．1 AODV路由協議的基本思想
AODV(Ad hoc On-demand Distance Vector)借用了DSR中路由發現和路由維護的基礎程序，以及DS-DV的逐跳(Hop-by-Hop)路由、順序編號和路由維護階段的周期更新機制。
當源節點需要和目的節點通信時，如果在路由表中已經存在了對應的路由時，AODV就不會進行任何操作，而是直接進行通信。當原路由失效或者需要和新的目的節點通信時，它就會發起路由發現過程，廣播RREQ信息。當RREQ到達目的節點本身，或者是一個擁有“足夠新”的到目的節點路由的中間節點時，目的節點或者中間節點通過RREQ的反向路徑向源節點返回一個RREP消息。所謂“足夠新”就是通過目的序列號來判斷的，每個節點進行節點序列號的管理，維護自身的序列號和保存目的節點序列號。AODV使用了分布式的、基于路由表的路由方式，建立路由表項以后，在路由中的每個節點都要執行路由維持、管理路由表的任務。節點會監視一個活動路由(Active Route)中下一跳節點的狀況。當發現有鏈路斷開的情況時，就向該路由的前驅節點發出RERR消息通知。在RRER消息中，指明了由于鏈路斷開而導致無法到達的目的節點。每個節點都保留了一個“前驅列表”(Precursor List)來幫助完成錯誤報告的功能。
2．2 AODV路由實現的軟件結構
AODV路由協議的實現主要包括兩個組件：MulitHopEngineM和MulihopAodv，如圖4所示。其中MultiHopEngineM組件負責轉發分組，Multi HopAodv是AODV路由功能的實現組件，通過配置組件MultiHopAodvRouter將兩個組件寫通(write)起來。

MultiHopAodv使用TimerMilliC提供的Timer接口作為路由協議所需的定時器，實現了AODV的路由發現、路由維護、Hello消息等機制，為MulitHopEngineM提供路由的下一跳地址。MultiHopEngineM通過兩個接口(RotlteControl，RolneSelect)和MultiHopAodv交互，它的實現獨立于任何路由協議實現，這非常有利于基于TinyOS平臺的第三方路由協議的開發。AodvQueueTransmitP為MultiHopEngineM和MultiHopAodv提供了AMSend和Receive接口，同時提供了FIFO機制。

3 系統測試
采用6個節點進行組網測試，使用16位的短地址作為節點地址，如表1所示。系統測試時，PC端使用串口與節點連接，然后通過串口查看節點的路由信息和數據的轉發情況。

3．1 路由發現機制
源節點發起尋找目的節點的路由發現過程，中間節點收到RREQ后，檢查自身是否有到達目的節點的有效路由，如果有，則回復RREP；如果沒有，則繼續廣播RREQ，如圖5所示。

如圖6和圖7所示，節點2在收到節點4發來的RREQ后，更新到源節點(節點4)的路由，同時在路由表查找到目的節點的有效路由，然后向節點4回復RREP。節點4收到節點2返回的RREP，添加相應路由，將節點2作為到目的節點(節點1)的下一跳節點。該測試表明本系統實現了AODV路由協議的RREQ轉發機制和中間路由回復機制，節點4獲得到達目的節點的路由。

3．2 數據包的發送和轉發
將6個節點隔開一定距離布置，節點1作為sink節點，其余5個節點建立到達節點1的路由，向sink節點發送數據，中間節點同時負責轉發其他的節點的數據，圖8是組網完成后的拓撲圖。

源節點(節點3)發起查找目的節點(節點1)路由發現過程，在建立路由之后(3→4→2→1)，向下一跳節點(節點4)發送數據包，如圖9所示，中繼節點(節點2，節點4)轉發數據包如圖10～圖12所示。在圖12中，目的節點收到節點2轉發的來自節點3的數據。從該測試結果看出系統具備AODV協議的路由發現、路由表查找、數據包的轉發等基本功能。

4 結語
本文介紹了無線傳感器網絡硬件節點和TinyOS操作系統的結構，根據系統所采用的硬件將TinyOS操作系統移植至8051平臺，同時添加系統所需的IO，Timer，UART，RF等組件。這些組件提供了AODV路由協議所需要的IO控制、定時器、射頻收發等功能。通過測試AODV協議的路由發現和多跳轉發等機制驗證了所移植組件和路由協議實現的正確性。