【正文】 發(fā)生，就需要將該事件報告給基站，基站收到報告后做出相應的動作（比如將消息發(fā)至互聯(lián)網或者衛(wèi)星）。根據具體應用的場合，不同的性能目標需要不同的數據傳播策略，這些目標包括對響應的實時性的要求，對數據冗余的要求，對安全性的要求等。 、 主要特點 無線傳感網的特點有： 節(jié)點小型化 有限的能量供給 苛刻的環(huán)境條件 節(jié)點失效問題 動態(tài)的網絡拓撲 通訊失敗問題 大量部署的節(jié)點 無人值守 可以將傳感節(jié)點想像成一臺小巧的計算機，特別是在它們的接口和組件方面。傳感節(jié)點通常由這些部分組成，一個計算能力和存儲能力有限的處理單元，一些傳感器（有特定的調節(jié)電路），一個通訊設備（通常為無線電收發(fā)器），和一個通常為電池的能量供給裝置。其他一些可選部分有環(huán)境能源發(fā)電模塊，輔助的專用集成電路，以及可能的輔助通訊設備（比如 RS232 或 USB）。 基站可以有一個或者多個，它們是無線傳感網中的特殊成員，具有相對強大的計算、能量和通訊資源?；镜淖饔孟喈斢趥鞲泄?jié)點和最終用戶之間的網關。 典型的無線傳感網架構見圖 1。 、 硬件平臺 硬件方面的主要挑戰(zhàn)在于制造低成本和微小的傳感節(jié)點。考慮這一目標，現在的傳感節(jié)點主要還處在原型階段。小型化和低成本的解決要寄希望于最近以及將來在微機電系統(tǒng)（ MEMS）和納機電系統(tǒng)（ NEMS）領域的進展。 SNM Sensor Network ，組件，技術和相關主題 。 和主流計算機不同，目前還沒有無線傳感網的官方標準，所以硬件以及軟件的互操作性和可重用性都較低。下面列出一些領域內研究所使用的標準： ZigBee Wibree 6lowpan 、 軟件平臺 對無線傳感網節(jié)點而言，能量是最缺乏的資源，它決定了節(jié)點們的生命周期。無線傳感網節(jié)點將被大量放置到各式各樣的環(huán)境下，包括遙遠和敵對的區(qū)域，這樣自組織通訊將變得重要。由于這些原因，算法和協(xié)議必須解決以下問題： 9 生命周期最大化 魯棒性和容錯性 自配置 無線傳感網軟件研究上的一些 熱門課題有： 安全性 可移動性（移動中的傳感節(jié)點或者基站） 中間件（在軟件和硬件之間設計中間層） （ 1） 操作系統(tǒng) 一般來說，無線傳感網節(jié)點上的操作系統(tǒng)比通用操作系統(tǒng)的復雜度低。這有兩方面的原因，一方面是由于傳感網應用程序的特定需求，另一方面是由于傳感網硬件平臺的資源限制。舉一個例子，傳感網應用程序通常不要求像 PC 機應用程序那樣的可交互性，這樣操作系統(tǒng)就不需要支持那樣的用戶接口。更進一步講，在內存和內存映射硬件支持上的資源限制，使得類似于虛擬內存的機制變得不必要或者不可能實現。 無 線傳感網在硬件上和傳統(tǒng)的嵌入式系統(tǒng)沒有區(qū)別，這就有可能在傳感網上使用像 eCos 或者uC/OS 這樣的嵌入式操作系統(tǒng)。不過這些操作系統(tǒng)的設計通常具有實時特性，而與傳統(tǒng)嵌入式操作系統(tǒng)不同的是，專用于傳感網的操作系統(tǒng)一般不支持實時性。 TinyOS 也許是第一個專門為無線傳感網而設計的操作系統(tǒng)。和大多數操作系統(tǒng)不同， TinyOS采用基于事件驅動的編程模型，而不是基于多線程。 TinyOS 程序由事件處理例程和具備語義運行的任務所組成。當外部事件發(fā)生時，比如新到數據包或者讀傳感器， TinyOS 調用相應的事件處理例程來處理 該事件。事件處理例程可以發(fā)布任務，這些任務將被 TinyOS 核心所調度。不管是 TinyOS 系統(tǒng)，還是 TinyOS 下開發(fā)的應用程序，都是用 nesC 編程語言寫成的。 nesC 是 C 編程語言的擴展，它被設計成可以發(fā)現在任務和事件處理例程之間的競爭條件。 存在一些操作系統(tǒng)支持 C 語言編程，這些操作系統(tǒng)包括 Contiki、 MANTIS、 BTnut、 SOS 和NanoRK。 Contiki 的設計支持從網絡加載模塊，還支持運行時加載標準 ELF 文件。和 TinyOS一樣， Contiki 的核心是基于事件驅動的，但是 Contiki 支持基 于每應用程序的多線程。更進一步的， Contiki 支持 protothreads，它在提供類似于多線程編程抽象的同時，只支付了非常小的內存開銷。與事件驅動的 Contiki 核心不同， MANTIS 和 NanoRK 的核心基于搶先式多線程。在搶先式多線程方式下，應用程序不需要顯式地釋放微處理器給其他進程，取而代之的是，核心將時間劃片給活動進程，并決定當前可以執(zhí)行哪一個進程。這使得應用程序的編程更加容易。NanoRK 核心對資源的分配是實時的，能夠有很好的粒度來控制任務對 CPU 時間、網絡和傳感器的占用。和 TinyOS、 Contiki 一樣， SOS 是基于事件驅動的操作系統(tǒng)， SOS 的主要功能是支持可加載模塊，一個完整的系統(tǒng)由一些小模塊所構建，這樣的構建可能發(fā)生在運行時。為了支持模塊接口內在的動態(tài)性， SOS 也致力于支持動態(tài)內存管理。 BTnut 基于協(xié)作式多線程和 plain C代碼，有打包的開發(fā)工具和指南。 （ 2） 中間件 目前有大量的研究投入在無線傳感網中間件的設計上。一般來講研究方向可以分為分布式數據庫、移動代理和基于事件的模型。 （ 3） 編程語言 在傳感節(jié)點上的編程比在常規(guī)的計算機系統(tǒng)困難。這些節(jié)點上受限的資源狀態(tài)，帶來 了新的編程模型，盡管這些節(jié)點大多采用 C 編程語言。下面是一些編程語言列表： c@t（在空間和時間上的某一點上進行計算） DCL（分布式組合語言） galsC nesC Prototheads SNACK SQTL （ 4） 算法 無線傳感網包含大量的傳感節(jié)點，這就隱含地要求為無線傳感網所設計的算法是分布式算法。在無線傳感網中，最匱乏的資源是能源供給，而最耗費能源的操作之一是數據傳輸。由于這個原因，無線傳感網的算法研究大都集中在能源相關的從傳感節(jié)點到基站的數據傳輸算法上。由于無 線傳輸的能源消耗相對于傳輸距離以多項式增長，數據傳輸常是多跳的（從節(jié)點到節(jié)點，往基站方向）。 10 無線傳感網的算法研究和協(xié)議研究的區(qū)別在于，算法研究的數學模型通常更抽象，更具一般性，但是有時候實用性不如協(xié)議設計的模型。 、 仿真系統(tǒng) 存在一些專門的無線傳感網仿真平臺，比如 TOSSIM，它是 TinyOS 的一部分。 ns2 之類的傳統(tǒng)的網絡仿真器也可用來仿真。一份詳盡的無線傳感網絡仿真工具列表可以在CRUISE WSN Simulation Tool Knowledgebase 上找到。 、 數據可視化 無線傳感網所采集的數據通常以數字數據的形式存放在一個中心基站。有很多程序支持查看其所存放的大量數據，比如 TosGUI、 MonSense 和 GSN。另一方面，開放地理空間聯(lián)盟（ Open Geospatial Consortium）正在制定可互操作接口和元數據編碼的標準，這些標準支持將那些異質的傳感站點實時地集成到互聯(lián)網，允許任何一個個體使用 Web 瀏覽器監(jiān)視或控制無線傳感網。 NS2 開發(fā)理論及方法 NS 簡單工具介紹 對于使用網絡仿真軟件來做網絡效能分析的人而言，步驟通常是先設計出符合自己需要的網 絡仿真環(huán)境，設定其不同的參數，執(zhí)行仿真，收集結果資料，最后把資料使用圖片或表格把結果呈現出來以方便分析實驗。一般而言，對于 ns2 的初學者而言，總是會遇到一個問題，就是網絡仿真程序跑完后，接下來該如何分析。這是非常重要的一個過程，所以希望 ns2 的初學者能好好的研究此章節(jié)的內容，相信一定會對大家的研究有相當的幫助。 本節(jié)打算以一個簡單的網絡環(huán)境為范例，介紹如何使用一些工具來分析和呈現仿真結果，這包含了如何去量測 EndtoEnd Delay、 Jitter、 Packet Loss、和 Throughput。而采用的方法是去分析 traffic trace 檔案的方式，這種方法的優(yōu)點是簡單且不需要去修改到 ns2 核心的部份，但缺點是若是仿真資料若是太多， traffic trace 的檔案會太大，這樣會增加分析所需要的時間。另外一種方法，是去更改 ns2 核心，增加或修改一些檔案，把所需要量測的參數直接記錄下來，這種方法的優(yōu)點是仿真結束后，所需要量測的數據已經完全記錄下來，但缺點是要動到 ns2 核心的部分，對于初學者而言，這是一個很大的門檻，這個方法筆者留到后面的章節(jié)在做介紹。 筆者先對要仿真的環(huán)境做一個簡單的介紹。 這個網絡的環(huán)境包含了四個網絡節(jié)點 (n0， n1， n2， n3)，如下圖所示。網絡節(jié)點 n0 到節(jié)點 n2 之間，和節(jié)點 n1 到節(jié)點 n2 之間的網絡頻寬 (bandwidth)是 2Mbps，延遲時間 (propagation delay)是 10ms。網絡拓樸中的頻寬瓶頸是在節(jié)點 n2 到節(jié)點 n3 之間，頻寬為 ，延遲的時間為20ms。每個網絡節(jié)都是采用 DropTail queue 的方式，且在節(jié)點 n2 到節(jié)點 n3 之間的最大隊列長度是 10 個封包的長度。在節(jié)點 n0 到 n3 之間會有一條 FTP 的聯(lián)機， FTP 應用程序是架構在 TCP 之上，所 以在寫仿真環(huán)境的描述語言的時候，必需先建立一條TCP 的聯(lián)機，在來源端 n0 上使用 TCP agent 產生 ”tcp” 來發(fā)送 TCP 的封包；在目的地端 n3 使用 TCPsink agent 產生 ”sink” 來接受 TCP 的資料、并產生回復封包 (ACK)回傳送端、最后把接收的 TCP 封包釋放。最后要把這兩個 agent 連起來 (connect)，聯(lián)機才能建立。若是沒有額外的參數設定， TCP 封包的長度為 1Kbytes。在這里順便補充說明一下，對于 ns2 仿真參數內定值設定是在 \\tcl\lib 目錄下 11 的 ，有想要進一步了解的人，可以去查看此檔。另外，在節(jié)點 n1 到 n3之間有一條固定的傳輸速率的聯(lián)機 (Constant Bit Rate， CBR)， CBR 應用程序是架構在UDP 之上，因此必需在 n1 使用 UDP agent 來產生” udp” 用來發(fā)送 UDP 封包，在 n3上使用 Null agent 來產生 ”sink” 以接收由 n1 傳送過來的 UDP 封包，然后把接收的封包釋放。 CBR 的傳送速度為 1Mbps，每一個封包大小為 1Kbytes。 CBR 是在 秒開始傳送，在 秒結束傳輸； FTP 是在 秒開始傳送， 秒結束傳輸。 [Simulation Topology] 里面的 例子仿真結果 :如下 仿真結束后，會產生兩個檔案，一個是 ，這是給 NAM 用的，用來把仿真的過程用可視化的方式呈現出來，這可以讓使用者用 ” 看 ” 的方式去了解封包 12 傳送是如何從來源端送到接收端。另一個檔案是 ，這個檔案記錄了仿真過程中封包傳送中所有的事件，例如第一筆記錄是一個 CBR 的封包，長度為 1000bytes，在時間 秒的時候，從 n1 傳送到 n2。這個檔案對我 們做效能分析很重要，所以要先對這個檔案的格式做仔細的介紹。 每一筆記錄的開始都是封包事件發(fā)生的原因，若是 r 則表示封包被某個節(jié)點所接收，若是 +則表示進入了隊列，若是 則表示離開隊列，若是 d 則表示封包被隊列所丟棄。接著的第二個字段表示的是事件發(fā)生的時間；字段三和字段四表示事件發(fā)生的地點 (從 from node 到 to node)；字段五表示封包的型態(tài)；字段六是封包的大小，字段七是封包的旗標標注；字段八表示封包是屬于那一個資料流；字段九和字段十是表示封包的來源端和目的端，這兩個字段的格式是 ， a 代表節(jié)點編 號， b 表示埠號 (port number)；字段十一表示封包的序號；最后字段十二表示封包的 id。以前面trace file 的第一筆為例，意思就是說有一個封包 pakcet id 為 0，資料流 id 為 2，序號為 0，長度為 1000 bytes，型態(tài)為 CBR，它是從來源端 要到目的地 ，在時間 秒的時候，從節(jié)點 1 進入了節(jié)點 2 的隊列中。 接下來，筆者先簡單介紹 awk，然后如何使用 awk 去分析 trace file，以得到Throughput、 Delay、 Jitter、和 Loss Rate。 [awk] awk 是一種程序語言。它具有一般程序語言常見的功能。因 awk 語言具有某些特點，如：使用直譯器 (Interpreter)不需先行編譯；變量無型別之分 (Typeless)，可使用文字當數組的注標 (Associative Array)等特色。因此，使用 awk 撰寫程序比起使用其它語言更簡潔便利且節(jié)省時間。 awk 還具有一些內建功能，使得 awk 擅于處理具資料列 (Record)，字段 (Field)型態(tài)的資料；此外， awk 內建有 pipe 的功能，可將處理中的資料傳送給外部的 Shell 命令加以處理， 再將 Shell 命令 處理后的資料傳回 awk程序，這個特點也使得 awk 程序很容易使用系統(tǒng)資源。 B. awk 是如何運作的 13 為便于解釋 awk 程序架構，以及相關的術語，筆者就以上面 trace file 為例，來加以介紹。 : 1. 1.