XMesh無線網(wǎng)絡架構(gòu)設計與論述

/XMesh開發(fā)詳解第一章XMesh概述1.1mesh網(wǎng)絡基礎基于無線mesh網(wǎng)絡結(jié)構(gòu)的短距離、小范圍網(wǎng)絡已經(jīng)發(fā)展到使用有效的能量方式來管理非計算機設備。自組織的mesh網(wǎng)絡結(jié)構(gòu)已經(jīng)使能新的無線設備應用，包括戰(zhàn)場上的傳感監(jiān)控；視頻生產(chǎn)和運輸中溫度監(jiān)控；與醫(yī)療設備用信號對病人的診斷。無線傳感網(wǎng)絡可以在不同的方式被設計不同的地址優(yōu)先級并。所有的無線mesh網(wǎng)絡系統(tǒng)都有一些基本的應用要求：低功耗——為了提供較長時間的操作，radio連接的能量的消耗必須被縮減，這樣設備就可由輕的就像硬幣大小的電池來供電較長時間。容易使用——網(wǎng)絡協(xié)議允許網(wǎng)絡以一種高度的adhoc、自組織方式來初始化自己?？蓴U展性——網(wǎng)絡必須能對節(jié)點提供實時支持，并支持未來的增長而不會引起過載。Responsiveness——協(xié)議發(fā)現(xiàn)和重發(fā)現(xiàn)必須有效，尤其是對移動的傳感節(jié)點，比如在移動設備或無線傳感中范圍——發(fā)射低能量的RF信號在一個短的距離內(nèi)傳輸，可以被中轉(zhuǎn)多次，這比起在一個長范圍內(nèi)傳輸高能量的信號來更加有效。使用協(xié)議構(gòu)建中繼網(wǎng)絡，能支持多跳路由，這樣，數(shù)據(jù)包就可以被中轉(zhuǎn)從一個中繼站到另外一個，當移動RF終端遠離基站的時候。Bi-directionalcommunication——網(wǎng)關和傳感器之間的通信是bi-directional，它能使基站傳輸信號來適當調(diào)節(jié)操作參數(shù)，此外，接收傳感器數(shù)據(jù)?？煽啃浴敂?shù)據(jù)的可靠性很重要時，它對很多應用來說變成了一個關鍵性的設備，比如在醫(yī)療監(jiān)控中。Smallmoduleformfactor——一個非常小的構(gòu)成因素對網(wǎng)絡模塊來說是需要的，因為這樣終端節(jié)點能適應內(nèi)部或很容易的接到已存在的設備上。一個魯棒性強的網(wǎng)絡協(xié)議是為滿足上述要求，以與那些在特別是mesh網(wǎng)絡而設計得。網(wǎng)絡協(xié)議提供支持的網(wǎng)絡拓撲結(jié)構(gòu)和管理路由數(shù)據(jù)通過網(wǎng)絡。為了讓應用從無線傳感網(wǎng)絡中受益，基本協(xié)議必須支持所有這些基本要求。1.2拓撲有幾種結(jié)構(gòu)可以用來實現(xiàn)無線傳感網(wǎng)絡的應用，包括星型、拓撲與星型—拓撲混合的。每一種結(jié)構(gòu)都有他自己的難點和優(yōu)缺點。一個無線我網(wǎng)絡包括以下這些組件：終端節(jié)點——傳感和制動器一起來捕獲數(shù)據(jù)。對ZiggBee網(wǎng)絡，這些通常指的是RFDs。RFDs不能向上、向下傳送報文。XMesh-ELPMotes類似一個RFDs設備路由——擴大網(wǎng)絡覆蓋，路由繞過障礙物，并在網(wǎng)絡擁塞或設備故障下提供主干路由備份。某些情況下，路由也能作為終端節(jié)點。路由也可以指ZigBee網(wǎng)絡中的FFD設備。XMesh里的所有版本就像FFDs網(wǎng)關——統(tǒng)計網(wǎng)絡中的數(shù)據(jù)，提供到主機、LAN或者因特網(wǎng)的接口，就像一個入口來管理網(wǎng)絡性能和參數(shù)。系統(tǒng)軟件——提供網(wǎng)絡歇息來使能自組織、自處理的adhoc網(wǎng)絡。CrossbowXMesh網(wǎng)絡在RFDs和FFDs之間沒有明顯的差別，所以有整合傳感的節(jié)點都可以向上、向下傳送報文。拓撲指的是硬件的布局和數(shù)據(jù)如何通過這樣的布局。1.3XMeshOverviewXMesh是一個由多跳、adhoc、mesh網(wǎng)絡協(xié)議構(gòu)成的網(wǎng)絡，由Crossbow公司開發(fā)。一個XMesh網(wǎng)絡包含許多節(jié)點能無線地彼此間通信，也能將radio報文傳遞給基站，然后給PC或其他用戶。多跳性有效地擴展了radio的通信范圍并減小傳輸報文的能量需求。用這種方式多跳數(shù)據(jù)。節(jié)點不需要在一個raidio的范圍內(nèi)直接相連通信。另外，如果2各節(jié)點之間有一個壞的radio連接，這個障礙可以通過周圍路由來克服。典型地，節(jié)點運行在一個低能量的mode上，大多數(shù)時間處于睡眠狀態(tài)，這樣是為了延長多年的電池使用壽命。XMesh是一個軟件庫，它使用TinyOS操作系統(tǒng)，并運行在嵌入式設備上，被稱作Motes。Motes包含：1、Microprocessor(AtmelATmega128forMICA2,MICA2DOTandMICAz).ATmega128has128Kofflashmemory,4KofRAM,and4KofEEPROM.(AtmelATmega1281M9100,M2100andM2110).ATmega1281has128Kofflashmemory,8KofRAM4KofEEPROM.2.Radio:aMICA2radioat916/433MHzoraM9100radioat916MHz,aMICAz/M2100/M2110radioat2.4GHz.3.SerialFlash:ExternalflashstoragememorytosupportOTAP(over-the-airprogramming)anddatalogging.UID:Anintegratedcircuitthatisprogrammedwithaunique64-bitidentifier(forMICA2andMICA2DOT)XMesh網(wǎng)絡包含：一或更多的Motes參與網(wǎng)絡一個基站節(jié)點。這是一個有XMeshBase應用程序的MICA2接口板。它管理網(wǎng)絡并提供數(shù)據(jù)報文進入和離開meshPC,給橋和其他客戶提供向mesh網(wǎng)絡發(fā)送數(shù)據(jù)的圖形化界面。XMesh提供一個mesh網(wǎng)絡服務同時具有自組織和自處理功能。XMesh能把數(shù)據(jù)向上路由值基站或向下路由到單個節(jié)點。也可以在一個節(jié)點簇中任意廣播。并使用QOS服務保障數(shù)據(jù)通信質(zhì)量。XMesh有各種不同能量的節(jié)點構(gòu)成包括HP、LP、ELP等。XMesh網(wǎng)絡協(xié)議有許多選項包括：低功耗偵聽、時間同步、節(jié)點睡眠、任意路由。所有Crossbow傳感和數(shù)據(jù)獲得板都可以為一個XMesh網(wǎng)路提供支持。XMesh網(wǎng)絡有如下結(jié)構(gòu)：?MICA2,MICA2DOT,andMICAzsupport?Lowpower(typicallylessthan220μAaveragecurrent(withoutsensorboard)?Networktimesynchronizationto±1msec.?Lowpowerlisteningwithan8timespersecondwake-upinterval,allowingforrapidmessagetransferacrossthenetwork.Thedefaultsamplingperiodis3minutes,althoughmanyothersamplingintervalsXMesh的網(wǎng)絡已經(jīng)被廣泛的測試過，不管在室內(nèi)還是戶外，在一個典型的室內(nèi)測試中，節(jié)點每300平方英尺放置一個，能覆蓋1萬平方英尺內(nèi)的設施。為了仿真較遠距離間的通信，無線電的傳輸功率傳輸頻率下降到-6dBm。在戶外的測試中，節(jié)點以每10000平方米一個的分布傳越幾個崎嶇不平英畝。關于許多發(fā)展的靜態(tài)分析表明大于90%的范圍在任何節(jié)點都會被收基站集到，無需使用端到端的確認機制。1.4XMesh網(wǎng)絡概況一個無限網(wǎng)絡設備由3個層級分明的軟件組成：節(jié)點層：XMesh的所在地，是一個運行在傳感節(jié)點簇的軟件，來構(gòu)成一個拓撲網(wǎng)絡。XMesh軟件提供網(wǎng)絡算法以構(gòu)建一個可靠地通信主干，它包含了mesh所能提供服務的所有的節(jié)點。服務層：是一個總是處于可用狀態(tài)的設施來處理來自無線網(wǎng)絡的數(shù)據(jù)通信和緩沖，并為無線節(jié)點和因特網(wǎng)用戶提供一個通道。XServer和XOtap是服務層的應用可以運行在PC或Stargate上用戶層：為用戶提供可視化軟件和圖形化接口來管理網(wǎng)絡。Crossbow提供免費的客戶端軟件叫做MoteView，但是Xmesh也是一個客戶軟件接口。一個XMesh傳感網(wǎng)絡系統(tǒng)包含多跳的節(jié)點（MICAz）和一個基站單元(MICAz)，這些被集成在一個MIB520板上?；咎峁┑姆沼?個目的：作為節(jié)點層和拂去七層的網(wǎng)關?；就ㄟ^無線電和其他節(jié)點通信，通過端口和服務器通信。這樣，基站在主機系統(tǒng)和其他的mesh網(wǎng)絡上提供了一個發(fā)送和接收信息的橋梁。他構(gòu)成了了網(wǎng)絡的一部分并且是數(shù)據(jù)從各節(jié)點直接傳到他自身上。對網(wǎng)絡上的其他節(jié)點來說，基站節(jié)點能無功耗的向PC主機發(fā)送信息?；竟?jié)點在一個本地系統(tǒng)中總是被標記為“node0”.另外，對于基站，mesh網(wǎng)絡包含了一定數(shù)量的其他節(jié)點，每一個帶有一個可識別的序號。這個節(jié)點系統(tǒng)可運行XMesh，自組織到一個網(wǎng)絡，向上至基站，向下直接點路由信息。1.5XMesh結(jié)構(gòu)和優(yōu)點包括：TrueMesh；更多的傳輸服務；更多的服務質(zhì)量保證；更多的節(jié)點控制；健壯性檢查；時間同步；空中編程TrueMeshTrueMesh技術(shù)指的是節(jié)點的這樣一種能力，當由于無線電磁干擾或控制權(quán)的循環(huán)使用導致部分網(wǎng)絡掉線時，它能動態(tài)地為傳遞數(shù)據(jù)包尋找新的途徑。一個網(wǎng)絡通過簡單的節(jié)點間彼此互聯(lián)的散射構(gòu)建本地無線網(wǎng)絡。基于一個特殊的無線網(wǎng)絡環(huán)境，節(jié)點間可相互發(fā)現(xiàn)和構(gòu)建一個路由樹。因此，在XMesh網(wǎng)絡中的節(jié)點真正可以是自組織和自處理的。1.5.2多傳輸服務XMesh提供多種傳輸服務協(xié)議在彼此的通信之間，他們是：上溯——從一個node運輸包至基站Mote下溯——從基站到節(jié)點單跳——只向鄰近的節(jié)點傳輸包1.5.3更多的質(zhì)量服務保證XMesh可提供更多的質(zhì)量服務的模型，他們是：最好的努力——通過鏈路層的確認，Mote將多次傳送一個消息給他的直接鄰居?？煽康膫鬏敗峁┒说蕉说拇_認，消息通過mesh傳到基站，然后基站返回一個確認。1.5.4多功能Modes1HighPower——HP提供：TrueMesh能力網(wǎng)絡中的每一個節(jié)點能路由數(shù)據(jù)高帶寬，低latencyMote無線電總是上電的2LowPower——LP提供：TrueMesh能力網(wǎng)絡中的每一個節(jié)點能路由數(shù)據(jù)高帶寬，低latencyMote的頻率通常停在一個低的睡眠狀態(tài)，然后定期醒來檢查無線頻率的傳輸。3擴展的低功耗：只供網(wǎng)絡的終端節(jié)點使用節(jié)點不能路由數(shù)據(jù)使用星型—網(wǎng)絡的混合結(jié)構(gòu)1.5.5健壯性診斷在一個XMesh網(wǎng)絡里，節(jié)點可以自動地傳輸健壯性信息給基站，這些信息包括節(jié)點在網(wǎng)絡里的無線傳輸，電池電壓與父節(jié)點的無線電信號強度指示(RSSI)?；綧ote將把這些健壯性的信息傳遞給Moteview和XSniffer來監(jiān)控和診斷XMesh的健壯性。1.5.6時間同步XMesh-LP支持網(wǎng)絡的全球時間同步到±1毫秒，時間戳用來同步頻率信息，但也用作用戶傳感器測量的同步1.5.7OTAPXMesh支持空中編程，它允許用戶對網(wǎng)絡的所有節(jié)點用新的代碼進行重新編程。OTAP使用直接下載的策略將不同的代碼影響下載到不同的Motes。這允許用戶開發(fā)傳感板并僅在感興趣的單元上編程。OTAP也使用一種promiscuous幀聽模式?；究梢酝德牭叫鹿?jié)點的下載，并得知他們需要同樣的影響，然后存儲代碼存儲器中。（transmissions）第二章構(gòu)建XMesh主要內(nèi)容：XMesh的搭建環(huán)境搭建一個XMesh的應用開發(fā)和測試一個小型網(wǎng)絡用二進制搭建應用獲得CrossbiwCVS代碼庫2.1XMesh的搭建環(huán)境XMesh使用MoteWorks來編譯和搭建，你必須有以下3個文件：?MakeXbowlocal?Makefile?Make在構(gòu)建任何應用時應根據(jù)需要在以上每一個文件中設置正確的參數(shù)2.1.1MakeXbowlocal這個MakeXbowlocal文件包含全局參數(shù)，他對一個特別的安裝包含了所有的應用。這個文件在/MoteWorks/apps中參數(shù)描述RADIO_CLASS這個參數(shù)定義了MICA2/MICADOT網(wǎng)絡通信的頻率。這個波特率由無線硬件設定，需要和board上的label相對應?？捎玫念悓ica2和Mica2Dot是916MHZ、433MHZ和315MHZRADIO_CHANNEL這個參數(shù)定義了操作的網(wǎng)絡無線波段，每一個波特率有多種波段可供操作，用戶應選擇一個網(wǎng)絡上不被其他無線設備使用的channel參看MICAz設置表RADIO_POWER這個參數(shù)定義了radio的powerjibieDEFAULT_LOCAL_GROUP本地組標記了網(wǎng)絡中每一個可通信的節(jié)點。群標號是一個供多網(wǎng)絡在同一個波特率上操作的方式，并且通過群組號進行通信下表列出了MICAZ802.15.4頻率的所有可用channels。USA/FCC&Canada注冊機構(gòu)總共分配了27個channels，Channels11到26在2.4GHZ波特率上。2.1.2Makefile這個文件包含特殊的參數(shù)。它定義的大多數(shù)高級別的服務，作為特殊的應用列在一張目標列表中。文件在/MoteWorks/apps/<specificappname>/2.2構(gòu)建一個XMesh的應用構(gòu)建一個XMesh-HP的應用來說明構(gòu)建一個多跳的網(wǎng)絡。我們將要開發(fā)的這個應用是XMeshCountToLeds應用，在這個應用中，每一個節(jié)點每秒增加它自己的數(shù)。并將值返回給基站供檢測用。證明count應用在LEDs列出數(shù)值。需要：至少3各節(jié)點。Mote編程板，在你的PC和mote網(wǎng)絡間編寫和實現(xiàn)，MIB520通信，PC,CD.第三章硬件概述（略）第四章XMesh概述關于XMesh如何構(gòu)建ad-hoc網(wǎng)絡的概述4．1XMesh功耗的概述Crossbow傳感網(wǎng)絡能運行許多不同策略的功耗，每一種策略是一個在功能和數(shù)據(jù)率之間的交互，對于有持久功率的系統(tǒng)來說，XMesh-HP是最好的選擇。這個提供了最好的保文速率，對于radio的典型波特率，對電池操作系統(tǒng)來講，需要數(shù)月或數(shù)年的生命期XMesh-LP和XMesh-ELP是通常使用的4.1.1XMesh-HP在這一模塊，Moteradio和處理器是連續(xù)的提供能量。這一消耗在15到30mA之間，主要依賴于Mote的類型。Motes能在任何時候接受和傳送報文。Route更新報文和健康信息被一一個很快的速率它將減少時間，在為一個新的mote加入到mesh里構(gòu)建一個新的mesh4.1.2XMesh-LP低功率的mesh能靜態(tài)或動態(tài)地運行在任何時間，最好的功率效率通過Xmesh-LP到達。在這種模式下，所有的motes是在±1mesc上是時間同步的。Motes一般是每秒喚醒8次，時間同步，對一個非常短的interval，去查看radio是否檢測任何操作信號在有噪聲的背景下。如果是這樣，radio正在保持接收信號，這一操作將導致當前80uA的。當前的總能量依賴于收到和傳輸?shù)膱笪臄?shù)量。當傳輸?shù)臄?shù)據(jù)在每3分鐘這個通常的功率在一個有50個節(jié)點的網(wǎng)絡。當前獲得平均的傳感器數(shù)據(jù)將會增加這個。XMesh-LP可被配置成很低的功耗通過減少活動時間和在一個很低的功率上傳送。Route的最新的間隔也被設置在一個很低功率以維護電量。這也導致一個更長的mesh信息時間。4.1.3XMesh-ELPELP模型是僅為葉節(jié)點和運行著XMesh-HP的父節(jié)點通信時而使用。一個葉節(jié)點被定義為一個節(jié)點，它不能參與mesh，他也不能將信息從孩子結(jié)點轉(zhuǎn)發(fā)到父節(jié)點。ELP版本結(jié)果是非常低的能量因為mote不需要使用時間同步活動的節(jié)點來檢查radio報文。這個mote能睡眠很長的一段時間。這個模型里，mote維持了一張到鄰居的的列表來記錄它可選擇的父節(jié)點。當他到達父節(jié)點的時候沒有一個連接確認，它將尋找另一個父節(jié)點。這個會非常快的發(fā)生或者或一些時間，如果RF環(huán)境或mesh確認機制有了很大的變換。4.2構(gòu)造多跳Mesh網(wǎng)絡構(gòu)建和維持一個Mesh網(wǎng)絡，下面的平行進程將被包含一個節(jié)點首先在它鄰居中偵聽并用那些信息來更新一個鄰居的列表，他檢測通過一個序列號它是否能很好的偵聽到一個鄰居在一個多跳的首部，并運行一個EWMA算法來理順那樣的估計。鄰接表的大小是被一個宏定義，通常是16的來預置。如果一個mote能聽到16個鄰居，它將從表中將質(zhì)量最低的一個刪除，基站mote的鄰接表被設置成一個更大的值40來處理更多的鄰居。因為基站通常不會運行一個會限制孩子mote的應用。2父節(jié)點選擇節(jié)點搜索他所有的鄰居并從中選擇一個能承擔最低的能量代價來作為他的父節(jié)點。一個鄰居被認為是一個父親的候選者如果他具有：已經(jīng)進入XMesh不是一個descendant節(jié)點對最后3個間隔。這打算避免循環(huán)是一個ELP節(jié)點一個XMesh網(wǎng)絡是網(wǎng)絡中所有的motes定期廣播路由更新信息，這將包含以下信息：1父節(jié)點號：如果節(jié)點沒有進入mesh這塊是0xFFFF2cost：它告訴其他節(jié)點向上發(fā)送給基站一個報文需要多少的代價3Hopcount：發(fā)送到基站報文的跳數(shù)4一個正確的列表和估計值。鑒于TinyOS數(shù)據(jù)包的大小，每一個路由更新消息將包含五個鄰居。一個合格的鄰居是他收到一個估計比一個threshold大（100高能量，10是低的）。默認狀態(tài)下，鄰居表的大小，對遠處節(jié)點是16，基站是40，如果有超過5個合格的鄰居。節(jié)點將會按序通過鄰接表并把這些信息放在一個多跳、有序、可更新的route信息中。這個route更新信息將會廣播每一個RUI為了更好的理解這個進程，我們將首先定義一些相關的指標：RE：接收估計，radio接受來自一個特定鄰居計算機，通過應用EWMA算法得出收到數(shù)據(jù)包的百分比New_Estimate=255*received/(received+missed)RE=(1-alpha)*RE+alpha*New_EstimateAlpha是EWMA的因素，他是一個介于0和1之間定義一個新的估計值的權(quán)重SE:發(fā)送估計值，radio將質(zhì)量傳送給一個特定的鄰居，它從一個鄰居的更新報文里獲得。當一個節(jié)點廣播一個路由更新信息，他也將鄰居的RE放在包里，因此鄰居知道這個節(jié)點的SE是什么注意：SE和RE是被歸在[0，255]的一個值里，因為255很好的質(zhì)量LC:到一個特殊鄰居的鏈路代價。只要知道了一個到特殊節(jié)點的SE和RE，LC就是這樣來計算：LC=(1<<18)/(SE*RE)注意：如果鏈路質(zhì)量很好，即意味著SE和RE都是255，LC是4，假定鏈路質(zhì)量很好，這個傳輸每條消耗的代價是4NC:鄰居代價，一個值來自一個特殊的鄰居的一個特殊的路由更新消息OC:向基站發(fā)送報文的代價值。他通過如下計算：OC=LC+NC路由將會用最低的OC挑揀鄰居作為它的父親注意：運輸?shù)交舅璧哪芰吭蕉?，代價越高。XMesh然后使用MT成本配置。這個配置的目的是將傳輸?shù)交镜目偝杀咀钚』?。在mesh網(wǎng)絡里的每一個節(jié)點將會廣播它的成本價值。這個基站在他的路由更新報文里廣播“0”。XMesh，每8RUIs執(zhí)行一個父節(jié)點選擇，它假定一個節(jié)點需要這個duration有足夠長度來獲取關于它的鄰居的信息并基于這些信息做一個好的決定。XMesh通過引入一個快速的信息mote加塊Mesh的信息時間。一旦一個新節(jié)點進入這個模型，他將執(zhí)行快速信息算法得到一個次優(yōu)的父節(jié)點以便于快速地進入這個mesh，然后再挑選到最好的父節(jié)點上。因為一個次優(yōu)的父節(jié)點有Mesh的一部分，被認為是一個父節(jié)點的候選者，對一個節(jié)點連接到Mesh是一個RUI的功能和跳計數(shù)。作為一個thumb規(guī)則，節(jié)點一個離開基站將會進入在1RUI的Mesh，節(jié)點2跳將會加入在2RUI2的Mesh，等等如此繼續(xù)，需要8RUIs到達穩(wěn)定。第五章發(fā)送和接受XMesh報文這部分討論怎么通過XMesh網(wǎng)絡從一個應用發(fā)送和接收報文。她包括：XMesh多跳信息的描述XMesh信息API使用XMeshAPI5.1TinyOS多跳報文XMesh報文是TinyOS報文加上額外的關于報文路由的信息構(gòu)成…….注意：最大數(shù)據(jù)值典型被限制到55bytes，擴展數(shù)據(jù)增加了SRAM的使用歸于多跳TOSbuffers的創(chuàng)立。短數(shù)據(jù)長度的報文能在任何時候被發(fā)送。TOSH_DATA_LENGTH僅決定最大報文長度。5.2XMesh報文的APIXMesh能向上、向下傳送報文。向下傳送通信將使能有效地從XMsh網(wǎng)絡上的一個基站到一個節(jié)點。向下的路徑同向上的路徑一樣由向上的路由器通過一個來自節(jié)點的包決定。只有當基站已經(jīng)收到一個來自其他mote的向上的報文重要：對于向下通信，基站必須接收到來自其他節(jié)點的至少一個向上的報文。報文可以被QOS層：鏈路層確認這個QOS提供傳輸退休在一個發(fā)送和接收Mote節(jié)點之間，如果一個確認報文沒有被發(fā)送者收到。這個QOS并不能保證一個多跳路由信息能成功從源傳送到基站，或向下傳送。使用鏈路層的確認機制對低能量來說是最好的QOS，并對適合于需要最低能量的系統(tǒng)，并不需要100%的數(shù)據(jù)傳輸2點對點的確認這個QOS使用一個點對點的確認來組合一個鏈路層的確認。對于向上的信息，基站將要返回給源一個確認。對向下的信息，基站將會從一個既定的源接受和確認。XMeshAPI允許用戶決定這個報文是否應該被發(fā)送。這個QOS消耗了比鏈路層確認更多的能量，也消耗了更多的RF帶寬。用戶可以使用任何鏈路層或是點對點的確認。XMesh提供一套的TinyOS的數(shù)據(jù)和接口，允許用戶將TinyOS的組件導通并把他們從應用中調(diào)出了。用戶可以做到如下：從終端節(jié)點發(fā)送向上和向下報文，允許或不允許使用點對點確認。在網(wǎng)絡里攔截處理比如數(shù)據(jù)聚集和壓縮轉(zhuǎn)發(fā)Snooptraffic對各種語言的聽目的5.2.1多跳收發(fā)接口這個多跳收發(fā)接口使用應用id來為這些命令設置參數(shù)。用戶被推薦使用這些接口（反之發(fā)送窗口被描述如下。這個接口包含以下3個命令）：接口：commandvoid*getBuffer(TOS_MsgPtrmsg,uint16_t*length);描述：給定一個TinyOS報文的緩沖，提供一個數(shù)據(jù)指針payloadsection以此一個應用可以能使用像它的長度那樣。如果一個無意識的協(xié)議應用是發(fā)送一個帶有接口的包，它必首先調(diào)用getBuffer()來得到一個指向有效數(shù)據(jù)區(qū)的指針，這允許應用來發(fā)送一個特殊的緩沖區(qū)而不是要求包結(jié)構(gòu)的知識接口：commandresult_tsend(TOS_MsgPtrmsg,uint16_tlength);描述：這個發(fā)送端口用AM類型來設置參數(shù)。它提供了維持后端-臨時能力使用先前的XMesh用AM類型來區(qū)分不同的應用。新的應用不應該使用這些接口。發(fā)送端將使用一個特定長度的輸入隊列發(fā)送一個報文緩沖，這個緩沖應該有他的已經(jīng)設定好的協(xié)議棧，或者通過一個協(xié)議組件或getBuffer()接口：eventresult_tsendDone(TOS_MsgPtrmsg,result_tsuccess);描述：信號當一個包發(fā)送使用send()完成5.2.2Receive()和ReceiveAck()接口5.2.3P這個接口允許應用控制/幀聽所有的radio報文包括廣播報文，而不管應用id和地址5.3使用的報文API5.3.1活動的報文和應用IDTinyOS一直在TOS報文中使用AM參數(shù)作為一個服務器/應用的標識，當AM類型被用在XMesh里（radio層，路由層和傳輸層）。應用ID允許應用使用相同的AM類型的服務給不同用戶提供多元化的服務。用戶僅僅處理應用IDs并通過MhopSend/receive接口來收發(fā)報文。XMesh為報文決定選擇哪種AM的類型，AM類型對XMesh是一個外部變量，當前網(wǎng)絡中有16種預先定義的XMesh，這些是用戶不該用作其他的目的的。5.3.2向上發(fā)送報文簡單地調(diào)用這些發(fā)送命令CallMhopSend.send(BASE_STATION_ADDRESS,MODE_UPSTREAM,&gMsgBuffer,sizeof(bfr));使下面發(fā)送sendDone事件eventresult_tSend.sendDone(TOS_MsgPtrpMsg,result_tsuccess){returnSUCCESS};5.3.3使用點對點確認向上發(fā)送報文為了接受到確認包，應用需要連線：AppM.RcvAck->XMeshRouter.ReceiveAck[appID];appID應該同樣在MhopSend里的一樣，然后應用使用ReceiveAck事件eventTOS_MsgPtrRcvAck.receive(TOS_MsgPtrpMsg,void*payload,uint16_tpayloadLen){reu//heserscansetthestatetostartsendingnextpacket}一個普通的模型是發(fā)送一個報文后啟動一個短的定時器。如果在時間到之前，端到端的確認沒有被接收到，應用就決定時候重新發(fā)送報文。建議的時間間隔是10s對一個XMesh-LP和20ms對一個XMesh-HP一個典型的例子是：在一個發(fā)送任務中，發(fā)送報文并啟動定時器：if((callSend.send(BASE_STATION_ADDRESS,MODE_UPSTREAM_ACK,&gMsgBuffer,sizeof(UpStream_t)))==SUCCESS){callTimerAck.start(TIMER_ONE_SHOT,20);//forhighpowerstackbAckWait=TRUE;}當定時器到期時，就決定是否在重新分組的基礎上重新發(fā)送報文eventresult_tTimerAck.fired(){if(NUM_RETRY!=num_retry++){postsendTask();}else{//reachretrylimitnum_retry=0;bAckWait=FALSE;}returnSUCCESS;}如果端到端的確認被收到在定時器到期前，取消時鐘：eventTOS_MsgPtrRcvAck.receive(TOS_MsgPtrpMsg,void*payload,uint16_tpayloadLen){if(bAckWait){callTimerAck.stop();num_retry=0;bAckWait=FALSE;}returnpMsg;}注意：沒有全局的XMesh序列號（這個在XMesh中的序列號多跳路由的首部是在每一跳的基礎上，用于鏈路質(zhì)量計算）所以最終的確認不進行序列編號的確認數(shù)據(jù)包，用戶應用程序不應該發(fā)出一個新的確認數(shù)據(jù)包，如果對先前報文的確認沒有收到5.3.4向下發(fā)送報文有2中情景用來向下發(fā)送報文：直接從基站發(fā)送從PC機或其他連接到主機上的基站如果從基站發(fā)送，就使用下面的命令：callMhopSend.send(downstream_node_id,MODE_DOWNSTREAM,&gMsgBuffer,length);//andimplementthesendDoneevent:eventresult_tSend.sendDone(TOS_MsgPtrpMsg,result_tsuccess){returnSUCCESS;}如果向下發(fā)送的報文來自PC機或其它通過運行AMeshBase基站的主機,PC代碼需要：將向下的節(jié)點號傳遞給TOSMsg首部地址把放在TOSMsg首部的類型區(qū)域把socket號放在socket區(qū)域計算CRC不改變多跳首部，是XMesh的內(nèi)部。XMesh在向下發(fā)送前將余下的空間填滿5.3.5用端對端的確認發(fā)送向下報文如果從基站發(fā)送，調(diào)用下面的發(fā)送命令：callMhopSend.send(downstream_node_id,MODE_DOWNSTREAM_ACK,&gMsgBuffer,length);//andimplementthesendDoneevent:eventresult_tSend.sendDone(TOS_MsgPtrpMsg,result_tsuccess){returnSUCCESS;}如果向下的包從一個PC機或其他通過運行XMeshBase基站的主機發(fā)送，除了類型領域，其他的一樣PC的代碼應該也能檢查一個對AM247類型的回滾，這是一個從節(jié)點到基站的段對端的確認。第六章XMesh路由控制有時用戶需要基于網(wǎng)絡狀態(tài)給出些應用層的決定，為了適應這一需要，XMesh提供一個路由控制接口（MoteWorks/interfaces）接口：commanduint16_tgetParent()描述：返回父節(jié)點地址接口：commanduint16_getDepth()描述：返回節(jié)點的深度，深度被定義為離開基站的跳數(shù)….…..第七章XMesh-LP(LowPower)這章討論XMesh中的低功能節(jié)點。也將討論：低功耗的操作是什么低功率策略7.1低功耗操作處理器功耗模式XMeshmote可以被配置成2種方式來接受數(shù)據(jù)，高功率和低功率。在高功率中，節(jié)點使得XMesh網(wǎng)絡總在工作。這個Mote的處理器和radio一直地消耗功率。Radio是正常的接收mode有哪次能在任何時候偵聽到所有鄰居的通信。這是mode向基站傳輸報文的最高帶寬。一個典型的處理器有幾種操作modes來消耗不同數(shù)量的能量。對一個完全活躍的mode。處理器消耗最大量的能量，通常在8mA的范圍內(nèi)，最低功耗消費的mode，一些構(gòu)成了深度睡眠的mode處理器只能按順序消耗15Amps處理器間的不同時處理器的具體模式。用戶應該查閱用戶手冊，…..典型地，最淺睡眠的mode將會沒有運行的外設，并為SRAM提供保留，通常需要一個外部中斷來喚醒進程，在大多數(shù)應用中，額外的32kHz時鐘被用來喚醒信號源在TintOS，用戶并不知道能量的管理。沒有任何更長的明確的被OS調(diào)用的能量管理，這樣將使得處理器進入睡眠。相反，因為TinyOS是一個基于任務的OS事件驅(qū)動，一旦隊列空了，調(diào)度就將處理器睡眠包含在決定睡眠mode的處理進程是一系列處于活動狀態(tài)的處理外設。能量管理模塊將確保睡眠modeset將會是最低功耗的，將會適應當前正確的活動設備。TinyOS的設計者認為，既然檢驗能夠延遲睡眠操作，實際的檢驗在睡眠命令調(diào)用的之前發(fā)生，因此，底層的驅(qū)動有責任在開始和結(jié)束之后調(diào)用檢驗和。詳細的課查閱scheduler.candHPLPowerManagement.ncsourcefiles.RadioPowerModesRsdio傳感器典型地有2個操作模式，它有一個傳送和接收的狀態(tài)?；谔厥獾膔adio傳感器，theTX(Transmit)andRX(Receive)操作的消耗在10to20mA.的范圍內(nèi)，對額外的TX、RX，radio傳感器有一系列的低功率狀態(tài)。當傳感器完全停電的時候，它消耗大約3μW.7.1.1低功耗策略既然OS已經(jīng)接管了處理器的能量管理工作，焦點也就轉(zhuǎn)向低功率的即時通信。需要被標記，大多數(shù)的傳感器網(wǎng)絡應用有很低的數(shù)據(jù)速率而不需要持續(xù)的處理或網(wǎng)絡行為。任何試圖減小能量的策略應該能利用典型的傳感器網(wǎng)絡低循環(huán)的應用要求。然而，當發(fā)送報文的時候，它沒有足夠來斷電，一個radio必須能從他的peers中接收報文，并知道什么時候打開接受的radioPowerCycling網(wǎng)絡中的一些節(jié)點在先前就被邊界設備所獲之，就不需要再加入路由。這些設備能在需要傳送數(shù)據(jù)的時候用低功耗策略傳送，在傳送完畢的時候斷電。假設這些邊界設備能連到一個節(jié)點上處理通過網(wǎng)絡來自邊界設備的報文。PowerCycling在一個已知的隊列PowerCyclingonaKnownSchedule廣播電臺在一個特定的時間間隔中向一個網(wǎng)絡中的所有節(jié)點廣播。每一個使用這一策略的節(jié)點將定期功率無線電偵聽活動。這個監(jiān)聽時間的一個節(jié)點是固定的間隔，每個通道的監(jiān)控也是固定的。信道間的監(jiān)控是通過網(wǎng)絡的。因此，如果任何節(jié)點希望與其鄰居通信，它將在傳送報文前的喚醒時間傳遞一個喚醒序列，轉(zhuǎn)遞前的實際信息。以這種方式，如果任何鄰國節(jié)點發(fā)現(xiàn)任何無線電活動，在其渠道的監(jiān)測，將繼續(xù)進行，直至該郵件完全接受。這一戰(zhàn)略使節(jié)點斷電大多數(shù)的時間是斷電的，只有在信道監(jiān)聽和報文傳送的時候是上電的。PowerCycling在一個同步隊列中在先前的策略中，網(wǎng)絡中的每一個節(jié)點在一個特定的間隔在他的radio上power。如果一個節(jié)點每秒監(jiān)聽信道8次，然后在每個信道上監(jiān)聽的時間間隔是125ms。當一個基點要發(fā)送數(shù)據(jù)，他就必須首先發(fā)送一個125ms的喚醒序列或這個較長的時期。這樣即時在向其鄰居節(jié)點發(fā)送簡單的提示的時候都會消耗大量的能量。喚醒序號必須掃描整個的間隔是因為節(jié)點不是同步的。不同步的節(jié)點不會知道鄰居節(jié)點偵聽信道時候精確地外部值在一個同步序列上，每一個節(jié)點都會通過相同的window定期監(jiān)控信道，然后喚醒隊列將動態(tài)減少，這個時間窗口如果在鄰接點的1ms之內(nèi)的話，就能確保每一個節(jié)點將會監(jiān)聽彼此之間在1ms內(nèi)的活動。因此喚醒隊列僅需要2ms7.1.2低功耗性能測量技術(shù)Period長2次連續(xù)的監(jiān)聽操作的總長。如果一個節(jié)點每秒監(jiān)聽8次，則這個長度是125ms帶寬由Period長度決定，如果長度是15ms，帶寬是每秒8個包延遲延遲由監(jiān)聽period的持續(xù)時間決定的。如果持續(xù)時間是125ms，則每一個鏈路的延遲是125ms能量檢測每一個節(jié)點的能量一定是花在定期信道檢測的活動上。傳輸能量：每一個包傳輸?shù)哪芰堪瑔拘殃犃薪邮漳芰浚好恳粋€包的接收能量7.1.3低功耗技術(shù)分析Period長VS帶寬和延遲Period長與延遲正比，與貸款成反比。增加period長會降低帶寬而提高延遲Period長VS能量消耗這個Period長在傳輸和接收能兩反面起作用，當監(jiān)聽periods是非同步的活著包需要用一個喚醒隊列發(fā)送出去，必須擴展整個的period長度Period越長，喚醒隊列就必須掃描更大的period長。如果接收者假定不同步，則接收者將在period長的中期上電。因此接收能量總是平均增加傳輸能量的一半。7.1.4時間無線同步棧和定期喚醒檢查無線電棧使用有時間Synchronization服務提供的同步時鐘，來對定期喚醒檢查排隊通過發(fā)送RSSI，這個通過以下到達：一個定期的檢查被初始化，當時鐘的低7位全0或128ms，一個時鐘時間對每一個喚醒檢查必須是很好的排列。當一個喚醒檢查需要被排隊的時候，無線棧就獲取當前的時間，直到最低位為0，時鐘節(jié)拍一直計數(shù)，然后計算一個將來喚醒檢查的隊列。這個方法允許時鐘向前向后移動而不引起不必要的時鐘打斷合適的同步之前，節(jié)點依賴于時鐘位同步的值，這將導致定期抽樣的128ms間隔7.1.5無線棧和包傳輸為喚醒檢查排隊無線棧也基于同步時鐘檢測包傳輸，有3種類型的傳輸?FullExtendedPreamble?ShortExtendedPreamble?StandardPreamble不同類型的包傳輸和時間同步是基于接收表列的FullExtendedPreamble：與所有的鄰居節(jié)點通信而不管當前的時間同步。包傳輸在喚醒檢查后15ms開始通信，因此節(jié)點以最小代價同步傳輸ShortExtendedPreamble：只用在已經(jīng)同步的節(jié)點間通信。這個包傳輸被排列成先前的傳遞，當其他的節(jié)點作為傳輸樣本的時候，節(jié)點將會探測即將到來的傳輸并在實際數(shù)據(jù)包到來之前打開radioStandardPreamble：被用在高能量節(jié)點間的通訊，包傳輸沒有包含額外的bytes并安排在定期喚醒檢查之間傳輸。它可以在不引起周圍節(jié)點喚醒的時候傳輸包的傳輸類型網(wǎng)絡棧使用不同包傳輸類型依賴于應該發(fā)出的包長度節(jié)點的平均能量消耗可以由傳輸和接收到的包傳輸類型和數(shù)量計算出，這個期望的節(jié)點生命期可使用itheRXcost,TXcost,andRFWake-up檢測代價等參數(shù)計算就如由每一種接收和發(fā)送的包類型序號。第八章XMesh-ELP8.1ELP是什么？XMesh-ELP到達了最低的操作功耗，因為所有的mode都處于睡眠狀態(tài)。只是位于網(wǎng)絡邊界的節(jié)點工作。這些節(jié)點不向上、向下或向其他的mode傳世報文。他們只能是其他mode的孩子而不可能是父節(jié)點。如圖示：這些節(jié)點被用在數(shù)據(jù)的立即發(fā)送。這種類型的設備通常睡眠從幾分鐘、幾個小時或幾天不等。一些使用ELP設備的例子是：低交換，每天僅發(fā)送幾次報文。在這個應用中，設備必須快速喚醒并發(fā)送報文電池操作一天用幾次。這種類型的應用需要使得機器上電并啟動通信部分一段時間，然后繼續(xù)睡眠ELP通過如下進入mesh的：掛在到父節(jié)點。持續(xù)上電直到他加入到mesh進入睡眠狀態(tài)。ELP同時保存鄰居表，下次使用相同將節(jié)點啟動，如果不成功，它將使用表中的另外的父節(jié)點。他周邊的上電并傳輸健狀的報文使用端對端的確認機制。如果接到一個確認，他們將睡眠，沒有接到確認，則需要試幾次在放棄前。ELPmode傳輸更新但是最終才報告他的代價，即其他的mode不能把他們當做父節(jié)點。ELPmode假定網(wǎng)絡協(xié)議與他們的父節(jié)點是靜態(tài)的。如果鄰居經(jīng)歷極端變化，如所有的節(jié)點斷電。然后ELPmode將會啟動一個快速地信息處理，從而在它再次睡眠之前獲得新的父節(jié)點。這通常意味著ELP節(jié)點總為2-3個外部路由更新。8.2ELP的操作理論啟動mode需要進入mesh。這個通過條用ElpI.route_discover(rui).完成，服務器等待rui*(ROUTE_UPDATE_INTERVALS)來加入mesh。ElpI.route_discover_done(success,parent)這個事件信號的結(jié)果是：如果是True，則ELP節(jié)點成功加入到mesh并且父節(jié)點參數(shù)將包含父節(jié)點的id。失敗的，就沒有加入到mesh，父節(jié)點保留廣播地址。用戶需要決定是否再試一次或是睡眠。ELPMote加入到mesh后，ElpI.sleep()將被觸發(fā)，而ELP是睡眠節(jié)點時，健康報文將被發(fā)送到基站并按預期從基站接收到一個確認。如果預期確認在既定時間沒有收到，將再試一次，之后，因失敗返回sleepdone()并不再嘗試。直到被喚醒。如果收到確認，服務器將停止XMesh啟動時鐘并把radio睡眠。如此重復。用force_sleep()參數(shù)控制行為，工作模式如下：構(gòu)建XMesh-ELPELP的應用需要如下代碼，外部中斷喚醒用戶應用，應用調(diào)用ElpI.wake()——打開radio并加入meshasynceventresult_tFireDetect.alert(){callElpI.wake();//turnontheradioandrejointheMesh}TheapplicationwaitsuntilElpI.wakedone()andthensendsradiomessages.eventresult_tElpI.wake_done(result_tss){callMhopSend.send(…);}Aftertheradiomessagehasbeensenttheapplicationcallsmode.;NOTE:ElpI.sleep()returnsSUCCESSifthemotehasreturnedtoELPsleepmode.ElpI.sleeptoretu