簡介移動自組網仿真資源面向無線網絡研究者與AODV協(xié)議學習者聚焦Ad Hoc網絡中按需距離矢量路由的實現(xiàn)與驗證。資源包共3個文件均為C/C頭文件壓縮后僅8KB內容覆蓋AODV協(xié)議核心定義、報文封裝格式與路由表管理邏輯便于在仿真工程中直接引用或二次開發(fā)。AODV通過RREQ廣播、RREP應答、RERR通告完成按需建路與故障處理這些頭文件從協(xié)議結構到路由維護為理解上述機制提供了清晰入口。已有243人瀏覽學習。對于正在開展車載通信、應急通信或軍事通信仿真的讀者借助這三個頭文件可以快速搭建AODV路由模塊模擬節(jié)點移動條件下的數(shù)據轉發(fā)過程并進一步評估端到端延遲、吞吐量及路由穩(wěn)定性等關鍵性能指標為協(xié)議優(yōu)化與場景適配提供代碼級參考。1. 移動自組網仿真找上 AODV先弄清楚這個方向要解決什么問題移動自組網MANET沒有中心基站節(jié)點一邊當終端一邊當路由器拓撲隨時因節(jié)點移動而變化。這種網絡里最常用的路由協(xié)議之一就是 AODVAd hoc On-Demand Distance Vector它屬于按需路由只有當節(jié)點真正要發(fā)數(shù)據時才去尋找路由。做移動自組網仿真時你拿到的 aodv.rar 里通常是一套 NS2 工程腳本包含場景生成、協(xié)議配置和結果統(tǒng)計。這篇筆記會把這個壓縮包背后的東西拆清楚AODV 在仿真里怎么建模、最小可運行的 tcl 腳本怎么寫、trace 數(shù)據怎么變成論文里的曲線以及我這些年調 AODV 仿真翻過的車。適合正在做 MANET 課程設計、畢業(yè)設計或者要評估應急通信、傳感器網絡路由方案的工程師。2. 先想清楚再動手AODV 仿真的建模對象與工具選型2.1 AODV 的核心機制RREQ/RREP/RERR 與路由表生命周期AODV 是反應式距離向量協(xié)議它和 DSDV 這類表驅動協(xié)議最大的區(qū)別是“平時不干活”。仿真里你會看到靜止狀態(tài)下節(jié)點之間沒有流量時路由表基本是空的一旦源節(jié)點有數(shù)據要發(fā)而且緩存里沒有到目的地的有效路由它就會廣播一個 RREQ路由請求消息。這個 RREQ 里帶有源節(jié)點序列號、目的節(jié)點序列號、跳數(shù)計數(shù)和廣播 ID。中間節(jié)點收到 RREQ 后先檢查自己有沒有到目的地的有效路由如果有并且目的序列號比 RREQ 里攜帶的更新就直接回復 RREP如果沒有就把 RREQ 繼續(xù)廣播出去同時在自己的路由表里記錄一條到源節(jié)點的反向路由。這個過程對應到仿真里就是一次洪泛你可以在 nam 動畫里看到藍色波浪狀擴散。當 RREP 沿反向路徑回到源節(jié)點每個經過的節(jié)點都會在路由表里建立到目的地的正向路由跳數(shù)為累計跳數(shù)有效期由路由表項的超時時間決定。NS2 里 AODV 的默認路由表項超時時間是 3 秒AODV_RTE_TIMEOUT如果 3 秒內沒有數(shù)據包使用這條路由表項就失效。這個參數(shù)直接影響高移動性場景下的性能很多調參的文章會把它改成 5 秒甚至 10 秒來降低路由發(fā)現(xiàn)頻率但代價是路由指向一個早已不在原位置的鄰居反而增加丟包。鏈路斷開時節(jié)點會向所有上游節(jié)點發(fā)送 RERR路由錯誤上游節(jié)點依次刪除對應的路由表項下一次發(fā)送數(shù)據時重新觸發(fā) RREQ。這個“發(fā)現(xiàn)—建立—失效—再發(fā)現(xiàn)”的循環(huán)就是移動自組網仿真的核心動態(tài)。仿真里如果要觀察 AODV 是否正確工作重點盯三件事RREQ 廣播會不會無休止傳播RREP 是否沿反向路徑回傳RERR 是否被及時觸發(fā)。NS2 的 AODV 實現(xiàn)基于 RFC 3561但跟標準存在一些實現(xiàn)細節(jié)差異比如它對 MAC 層丟包的處理比較敏感。所以同樣一套參數(shù)在 NS2 和 NS3 里的結果可能不同這不代表協(xié)議錯了而是協(xié)議棧的耦合方式不同。2.2 仿真工具怎么選NS2/NS3/OMNeT 與 gnu octave 的邊界AODV 仿真的主流工具是 NS2、NS3、OMNeT也有用 MATLAB 或者 gnu octave 通信仿真做理論驗證的。先說你手里的 aodv.rar絕大多數(shù)是 NS2 的 tcl 腳本因為 NS2 從 2.28 開始就自帶 AODV 實現(xiàn)網上流傳的 MANET 仿真模板基本都以 NS2 為底座。NS2 的優(yōu)點不是性能而是“老”內置協(xié)議模型多AODV 的 bug 和特性都被前人摸透了你遇到任何詭異現(xiàn)象都能搜到別人的踩坑記錄。缺點是安裝麻煩、trace 格式古老、腳本語法對初學者不友好。NS3 是 NS2 的繼任者C 實現(xiàn)AODV 模塊在 ns-3.10 之后內置。NS3 的架構更干凈還支持 python 綁定但它對 AODV 的默認參數(shù)和 NS2 不完全一致比如 Hello 間隔、活躍路由超時時間都存在差異。如果你只看路由協(xié)議本身NS3 更現(xiàn)代但如果你想復現(xiàn)和對比別人的論文NS2 反而更容易對上參數(shù)。OMNeT 配合 INET 框架也實現(xiàn)了 AODV模塊化強適合做多協(xié)議、跨層設計的仿真但需要額外安裝框架學習曲線最陡。gnu octave 通信仿真適合做快速數(shù)值驗證比如計算鏈路穩(wěn)定概率、路由開銷的理論公式推導但不適合做完整的移動自組網協(xié)議仿真因為你需要自己實現(xiàn)移動模型、信道競爭和協(xié)議狀態(tài)機工作量不亞于寫一個輕量模擬器。我的建議是如果目標是跑通 AODV、出性能指標曲線直接用 NS2如果目標是實現(xiàn)協(xié)議改進并做大規(guī)模參數(shù)掃描用 NS3如果只缺一個對照曲線gnu octave 畫圖足夠。下面的操作都以 NS2 為例因為這是 aodv.rar 最可能的來源。2.3 為什么很多 AODV 仿真還是用 NS2不是為了情懷我接觸過不少用 NS3 跑 AODV 的人最后又翻回 NS2核心原因是“可復現(xiàn)性”。NS2 的 AODV 實現(xiàn)里每個關鍵參數(shù)都有明確的默認值你可以直接在 tcl 腳本里用Agent/AODV set hello_period_去改不需要去翻 C 源碼。而 NS3 的 AODV 配置要通過屬性系統(tǒng)ns3::aodv::RoutingProtocol設置雖然也很 Open但很多教程只告訴你“默認就行”等你想改 RREQ 重傳次數(shù)時得去源碼里翻枚舉類型和屬性名效率低。另一個原因是 nam 動畫。NS2 自帶的 nam 工具可以直觀看到節(jié)點移動、RREQ 洪泛、數(shù)據包沿多跳路徑轉發(fā)這對理解 AODV 的按需行為特別有幫助。NS3 本身沒有官方圖形工具你還要用 NetAnim 或外部可視化插件。做課程答辯時nam 動畫比靜態(tài)曲線更有說服力。所以如果你已經是 NS3 的熟練用戶可以用 NS3但如果你是剛開始做自組網仿真我會堅持推薦 NS2。版本上盡量用 2.35這是最后發(fā)布的版本坑最少。3. 在 NS2 里把 AODV 跑起來最小實驗配置與 tcl 腳本拆解3.1 搭建移動自組網仿真場景節(jié)點數(shù)、移動模型、通信流量一個完整的移動自組網場景由三部分組成節(jié)點部署、移動軌跡、數(shù)據流量。節(jié)點數(shù)一般取 10 到 100常見的是 50。節(jié)點部署通常用隨機方式但為了可復現(xiàn)應該使用固定的隨機種子。移動模型最常用 random waypoint即每個節(jié)點隨機選一個目標點、隨機速度移動到目標點、再暫停一段時間然后重復。暫停時間pause time和最大速度max speed是參數(shù)變化的重點一般讓速度從 1 m/s 到 20 m/s 變化看 AODV 性能如何隨移動性下降。數(shù)據流量我一般用 CBR恒定比特率over UDP不用 TCP因為 TCP 的擁塞控制會干擾路由協(xié)議的性能判斷。CBR 流量需要設置發(fā)包間隔和包大小典型的是每 0.25 秒發(fā)一個 512 字節(jié)的包相當于約 16 kbps。節(jié)點對之間建立 UDP 連接常用連接對數(shù) 10 到 30 對。在跑大規(guī)模實驗之前先做一個最小場景10 個節(jié)點、3 對連接、速度 5 m/s、仿真時間 50 秒目的只是驗證腳本和統(tǒng)計流程能跑通。移動場景文件通常用setdest工具生成。它在 NS2 安裝目錄indep-utils/cmu-scen-gen/setdest下命令行形式是./setdest -v 1 -n 10 -p 5 -M 5 -t 50 -x 500 -y 500 scen10.txt參數(shù)含義-v版本號固定 1-n節(jié)點數(shù)-p暫停時間秒-M最大速度m/s-t仿真總時間-x -y場景范圍 500x500 米。生成的 scen10.txt 里每一行是節(jié)點編號和初始坐標后續(xù)是移動指令$node_(n) set X_ ...。注意 setdest 生成的坐標是浮點數(shù)字符串格式可能不帶換行導致 tcl 解析錯誤我遇到過多次后面避坑章會講。3.2 AODV 仿真的最小 tcl 腳本從場景生成到 trace 輸出下面給出一個可以直接運行的 minimal-aodv.tcl它配置了無線信道、802.11 MAC、隊列和 AODV 路由協(xié)議創(chuàng)建 10 個節(jié)點加載 scen10.txt 的移動場景建立 3 對 UDP/CBR 連接最后輸出 trace 和 nam 文件。# 創(chuàng)建仿真器實例 set ns [new Simulator] # 設置 trace 文件nam 用于動畫tr 用于數(shù)據統(tǒng)計 set tracefd [open mini.tr w] $ns trace-all $tracefd set namfd [open mini.nam w] $ns namtrace-all-wireless $namfd 500 500 # 配置無線物理層和 MAC 層參數(shù) set topo [new Topography] $topo load_flatgrid 500 500 set god_ [create-god 10] set chan_ [new Channel/WirelessChannel] set prop [new Propagation/TwoRayGround] set netif [new Phy/WirelessPhy] set mac [new Mac/802_11] set ifq [new Queue/DropTail/PriQueue] set ll [new LL] set ant [new Antenna/OmniAntenna] # 關鍵默認天線高度和發(fā)送功率影響覆蓋范圍 $ant set height_ 1.5 $netif set Pt_ 0.2818 $netif set freq_ 914e6 # 配置隊列長度未完成的分組可能被丟棄 $ifq set len_ 50 # 配置網絡堆棧指定路由協(xié)議為 AODV add-to-list $ll add-to-list $mac add-to-list $ifq add-to-list $netif add-to-list $ant add-to-list $prop add-to-list $topo add-to-list $god_ add-to-list $chan_ $ns node-config -adhocRouting AODV \ -llType LL \ -macType Mac/802_11 \ -ifqType Queue/DropTail/PriQueue \ -ifqLen 50 \ -antType Antenna/OmniAntenna \ -propType Propagation/TwoRayGround \ -phyType Phy/WirelessPhy \ -channelType Channel/WirelessChannel \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -movementTrace OFF # 創(chuàng)建 10 個無線節(jié)點 for {set i 0} {$i 10} {incr i} { set node_($i) [$ns node] $node_($i) random-motion 0 } # 加載 setdest 生成的移動場景 source scen10.txt # 建立 3 對 CBR 流0 - 31 - 42 - 5 set udp0 [new Agent/UDP] set null3 [new Agent/Null] $ns attach-agent $node_(0) $udp0 $ns attach-agent $node_(3) $null3 $ns connect $udp0 $null3 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 512 $cbr0 set interval_ 0.25 $cbr0 attach-agent $udp0 # 另一對連接 set udp1 [new Agent/UDP] set null4 [new Agent/Null] $ns attach-agent $node_(1) $udp1 $ns attach-agent $node_(4) $null4 $ns connect $udp1 $null4 set cbr1 [new Application/Traffic/CBR] $cbr1 set packetSize_ 512 $cbr1 set interval_ 0.25 $cbr1 attach-agent $udp1 # 第三對連接 set udp2 [new Agent/UDP] set null5 [new Agent/Null] $ns attach-agent $node_(2) $udp2 $ns attach-agent $node_(5) $null5 $ns connect $udp2 $null5 set cbr2 [new Application/Traffic/CBR] $cbr2 set packetSize_ 512 $cbr2 set interval_ 0.25 $cbr2 attach-agent $udp2 # 等移動場景加載完畢再開啟流量避免初始路由建立失敗 $ns at 5.0 $cbr0 start $ns at 5.0 $cbr1 start $ns at 5.0 $cbr2 start $ns at 45.0 $cbr0 stop $ns at 45.0 $cbr1 stop $ns at 45.0 $cbr2 stop # 結束前檢查 AODV 路由表統(tǒng)計 $ns at 50.0 stop $ns at 50.01 puts \simulation done\ ; $ns halt proc stop {} { global ns tracefd namfd $ns flush-trace close $tracefd close $namfd } puts Starting AODV simulation... $ns run代碼邏輯說明node-config一次性指定了整個無線協(xié)議棧其中-adhocRouting AODV是核心把路由協(xié)議切到 AODV。-ifqLen 50決定了接口隊列最多緩存 50 個待發(fā)送包如果隊列滿后面的包直接被丟棄。Propagation/TwoRayGround是兩徑傳播模型它比自由空間模型更接近真實地面環(huán)境也是大多數(shù) AODV 論文用的默認模型。$ns node創(chuàng)建節(jié)點時move 指令來自 scen10.txt里面設置的坐標范圍必須和load_flatgrid一致否則節(jié)點會跑到仿真區(qū)域外。流量開啟時間設為 5 秒是為了給節(jié)點完成初始位置更新和鄰居發(fā)現(xiàn)留出預熱時間。如果不預熱前幾秒發(fā)送的數(shù)據包會因為路由尚未建立而全部丟失拉低投遞率。CBR 的interval_ 0.25表示每 0.25 秒發(fā)一個包如果場景里節(jié)點間路徑跳數(shù)多接收端統(tǒng)計的包序號不連續(xù)就說明發(fā)生了重傳或丟包。3.3 關鍵參數(shù)說明無線傳播模型、MAC 層與隊列長度對 AODV 的影響傳播模型仿真里最常被忽略的參數(shù)是發(fā)送功率Pt_和天線高度height_。TwoRayGround 模型下無線信號被地面反射接收功率與距離的四次方成反比。AODV 能否建立多跳路由完全取決于節(jié)點間的鏈路是否“可達”。NS2 里你可以通過修改Pt_控制覆蓋半徑默認值 0.2818 在 500x500 場景里覆蓋半徑約 250 米10 個節(jié)點隨機分布時平均鄰居數(shù)足夠形成連通網絡。如果你把Pt_改小到 0.05可能整個網絡都斷成碎片AODV 會瘋狂發(fā) RREQ 但找不到路由投遞率接近零。MAC 層用 802.11 DCF默認不開啟 RTS/CTS。路由發(fā)現(xiàn)廣播包 RREQ 是廣播幀不需要 RTS/CTS但數(shù)據包是單播如果鏈路質量差重傳會消耗大量時間。Mac/802_11里的basicRate_和dataRate_會影響幀在信道上占用的時間間接影響 AODV 的端到端時延。網絡負載大時建議把ifqLen從 50 加大到 100但不要超過 200否則隊列排隊時延會嚴重影響實時性指標。還有一個易錯點AODV 的 Hello 機制默認開啟。NS2 里Agent/AODV set enable_hello_ 1節(jié)點每隔 hello_period默認 1 秒廣播一次 Hello 消息用來維護鄰居列表。Hello 消息本身也是數(shù)據幀會占用信道所以在統(tǒng)計路由開銷時要把 Hello 帶來的額外開銷算進去。如果你只想觀察 AODV 的基本性能可以在 tcl 里加Agent/AODV set enable_hello_ 0但這樣鏈路斷開檢測只能依賴 MAC 層反饋可能讓 RERR 觸發(fā)變慢。跑對照實驗時這個開關必須固定為一個值否則結果不可比。4. 把數(shù)據挖出來trace 文件解析與性能指標計算4.1 NS2 trace 格式事件類型、節(jié)點、協(xié)議層的字段含義NS2 無線 trace 的每一行以事件類型開頭s表示發(fā)送sendr表示接收received表示丟棄drop。后面依次是時間、源節(jié)點 id、目的節(jié)點 id、層級標識、標志、報文源地址、報文目的地址、序列號、包類型和包大小。一個典型行長這樣s 6.5 2 4 AGT 0 0.0 5.0 17 3 [MAC 0 0] [CBR 1 4 512]其含義是6.5 秒時節(jié)點 2 的應用層AGT向節(jié)點 5 發(fā)送了一個 CBR 包包序號 17大小 512 字節(jié)。注意這里的源節(jié)點和目的節(jié)點后面還跟了[MAC 0 0]和[CBR ...]兩段附加信息。統(tǒng)計投遞率時只統(tǒng)計 AGT 層的發(fā)送和接收事件因為路由層RTR的發(fā)送是轉發(fā)或者廣播 RREQ不能算作用戶數(shù)據。MAC 層的發(fā)送事件是物理幀更不能算。路由層事件里你能看到RREQ、RREP、RERR和RREP_ACK等包類型。統(tǒng)計路由開銷時要統(tǒng)計所有 RTR 層發(fā)出的 RREQ、RREP、RERR 包的總字節(jié)數(shù)因為這些包消耗了信道帶寬。在 trace 中s事件后跟的包類型字段是AODV的包類型比如s 8.2 1 2 RTR 0 ... [AODV RREQ 10]。這里[AODV RREQ 10]表示 RREQ 的廣播 id。4.2 計算分組投遞率、端到端時延、路由開銷的 awk 腳本下面是一個完整的 awk 腳本它從 mini.tr 中提取三個指標投遞率PDR、平均端到端時延、路由開銷以發(fā)往 RTR 層的 AODV 控制包字節(jié)數(shù)計。# analyze.awk # 用法: awk -f analyze.awk mini.tr BEGIN { sent 0; recv 0; sum_delay 0; ctl_bytes 0; } { if ($1 s $4 AGT $7 CBR) { sent; # 記錄發(fā)送時間到數(shù)組用源節(jié)點和包序號作為鍵 key $3 : $11; send_time[key] $2; } if ($1 r $4 AGT $7 CBR) { recv; key $3 : $11; if (key in send_time) { delay $2 - send_time[key]; if (delay 0) { sum_delay delay; } } } # 統(tǒng)計AODV控制包RTR層發(fā)出的RREQ/RREP/RERR if ($1 s $4 RTR) { # 第8個字段是包類型字段,例如 AODV # 第9個字段是包子類型, 例如 RREQ / RREP / RERR for (i 1; i NF; i) { if ($i RREQ || $i RREP || $i RERR) { # 假設包大小在第12個字段后面或包信息中簡化處理 # 用典型AODV包大小RREQ28, RREP20, RERR16 if ($i RREQ) ctl_bytes 28; else if ($i RREP) ctl_bytes 20; else ctl_bytes 16; break; } } } } END { printf 發(fā)送分組數(shù): %d\n, sent; printf 接收分組數(shù): %d\n, recv; if (sent 0) { printf 分組投遞率: %.2f%%\n, (recv / sent) * 100; } else { printf 分組投遞率: 0%%\n; } if (recv 0) { printf 平均端到端時延: %.3f ms\n, (sum_delay / recv) * 1000; } printf AODV控制包總字節(jié)數(shù): %d\n, ctl_bytes; }awk 腳本的邏輯說明判斷$4 AGT是為了區(qū)分應用層還是路由層。CBR 流量在 AGT 層只有s和r事件不會在d事件里對應到應用層丟包。發(fā)送時間存在send_time數(shù)組里鍵是源節(jié)點:包序號這個組合在 CBR 流里是唯一的因為每個源節(jié)點獨立編號。如果接收事件對應的發(fā)送時間找不到說明包不是從合法路徑到達的可能來自舊的轉發(fā)緩存這樣的時延數(shù)據不可靠我直接忽略?？刂瓢止?jié)數(shù)按 RFC 3561 的包大小近似比解析實際二進制更簡單在做相對比較時足夠準。跑這個腳本前要先確認 trace 文件里 CBR 的包類型字段確實是CBR。NS2 的 trace 里CBR 應用層的包類型寫在第 8 個字段位置附近但不同 NS2 版本字段偏移可能不同。你可以先用head -5 mini.tr看前幾行確認第 7 個字段是AGT、第 8 個字段是CBR還是別的。如果字段對不上需要調整 awk 中的列號。這是最常見的統(tǒng)計翻車原因之一。4.3 用 gnu octave 或 matplotlib 畫性能曲線統(tǒng)計腳本輸出的是單個場景的結果論文里需要的是不同參數(shù)下的曲線。比如把最大速度從 1、5、10、15、20 m/s 各跑一遍得到五組投遞率和時延數(shù)據?？梢杂?gnu octave 寫個小腳本繪圖gnu octave 通信仿真里最常用來畫曲線因為它能直接讀文本文件命令語法接近 MATLAB。下面是用 gnu octave 讀取三個文本文件每個文件里是一列投遞率值和對應速度并繪制曲線的示例% plot_pdr.m v [1 5 10 15 20]; % m/s pdr_5 load(pdr_5nodes.txt); % 5節(jié)點場景 pdr_10 load(pdr_10nodes.txt); % 10節(jié)點場景 figure; plot(v, pdr_5, -o, LineWidth, 2, Color, #1f77b4); hold on; plot(v, pdr_10, -s, LineWidth, 2, Color, #d62728); grid on; xlabel(Max speed (m/s)); ylabel(Packet Delivery Ratio (%)); title(AODV PDR vs Node Speed); legend({5 nodes, 10 nodes}, Location, southwest); print(pdr_speed.png, -dpng, -r300);參數(shù)說明load讀取的文本文件里如果不含矩陣分隔符octave 會把純數(shù)字列讀成列向量。plot的-o表示帶圓點標記-s表示帶方塊標記。-r300指定輸出 300 dpi 的 PNG論文用圖一般需要 300 dpi。如果是在腳本里批量處理可以把for循環(huán)包在外面每次運行一個 sim 后重定向輸出文件。注意 octave 默認色彩順序跟 MATLAB 略有不同如果你要嚴格按 IEEE 配色需要手動指定Color。5. 避坑/常見問題/排查AODV 仿真最常見的翻車現(xiàn)場5.1 現(xiàn)象仿真結果全零或丟包率 100%我第一次跑 AODV 時就遇到投遞率是 0trace 文件里全是d事件。檢查下來是場景生成器setdest生成的 tcl 文件里節(jié)點初始坐標有負數(shù)而 topo 范圍是 0 到 500負坐標節(jié)點直接掉到地圖外AODV 找不到任何鄰居。原因setdest 舊版本在某些-x -y參數(shù)組合下會生成負坐標的小概率事件或者場景文件里混入了空行source時語法報錯節(jié)點沒創(chuàng)建成功。解決先在source scen10.txt前加puts loading scenario再用puts node 0 at [$node_(0) set X_] [$node_(0) set Y_]打印節(jié)點坐標確認所有節(jié)點坐標都在 0~500 范圍內。如果坐標越界重新生成場景文件或者加一行$node_($i) set X_ [expr abs($x)]做絕對值處理。另外如果仿真時間太短比如 10 秒內 CBR 剛啟動還沒完成路由發(fā)現(xiàn)也會造成投遞率 0。解決方法是把流量開啟時間提前到 1 秒或者把仿真總時長拉長到 50 秒以上給協(xié)議足夠的時間收斂。5.2 現(xiàn)象路由建立后立刻失效吞吐量斷崖下跌高移動速度下AODV 的投遞率會從 90% 掉到 30%甚至更低。很多人以為是路由協(xié)議不行其實更可能是路由建立的時間大于鏈路生存時間。原因節(jié)點以 20 m/s 移動時相鄰節(jié)點幾秒鐘就超出無線覆蓋范圍。AODV 在發(fā)送第一個數(shù)據包前要先發(fā) RREQ等 RREP 回來這個過程在 NS2 里通常需要幾十毫秒但如果鏈路在路由建立的瞬間就斷裂RREQ 洪泛還沒完成包就丟了。解決一是把最大速度控制在 10 m/s 以內做模型驗證不要一開始就上 20 m/s二是調整路由表超時時間把Agent/AODV set rte_timeout_從默認 3 秒改成 5 秒讓已有路由更“耐用”三是開啟 RREP_ACK 機制Agent/AODV set aodv_ack_ 1避免反向路由失效。更直接的辦法是降低移動模型的更新頻率比如把setdest的 pause time 設為 10 秒而不是 0這樣節(jié)點是“跑一段停一段”鏈路保持時間更長AODV 性能更接近真實場景。5.3 現(xiàn)象trace 文件巨大磁盤爆滿腳本跑不動50 節(jié)點、500 秒仿真默認的 trace 可以到 300MB 甚至 1GB因為 MAC 層和物理層事件全被記錄。我在連續(xù)跑 100 組參數(shù)實驗時磁盤半年就滿了。原因NS2 默認trace-all會記錄每一個無線事件的細節(jié)。解決不需要所有層都 trace 時在 node-config 里把-macTrace OFF和-movementTrace OFF只保留-agentTrace ON和-routerTrace ON。這樣 trace 文件可以縮小三分之二。另外不要直接對全量 trace 文件反復跑 awk而是在腳本里用awk ... mini.tr summary.txt流式統(tǒng)計統(tǒng)計完就刪掉原始 trace。如果磁盤確實緊張可以用ns的trace-annotate只輸出關鍵事件或者用namtrace-all和trace-all共用同一個文件描述符減少重復寫入。還有一個習慣每個參數(shù)組合獨立建一個目錄trace 文件放在里面跑完立即壓縮避免后期找不到對應關系。5.4 現(xiàn)象復現(xiàn)別人論文的參數(shù)結果卻完全對不上這是 AODV 仿真里最玄學的一點。很多論文只寫了節(jié)點數(shù)和速度沒寫隨機種子、傳播模型、隊列長度、Hello 開關甚至沒寫用的是 NS2 的哪個版本。你按照它寫的參數(shù)去復現(xiàn)投遞率差十個點都很正常。原因NS2 的隨機數(shù)發(fā)生器默認用系統(tǒng)時間當種子兩次運行結果不同setdest生成的移動場景文件如果不固定種子整個節(jié)點軌跡就不同傳播模型默認參數(shù)不同步也會導致鄰居集合變化。解決第一在 tcl 腳本開頭加set rng [new RNG]和$rng seed 12345固定全局隨機種子第二用setdest時把-seed參數(shù)也固定并保存場景文件在實驗記錄里寫明 hash 值第三在論文里至少列出傳播模型、MAC 層、隊列長度、Hello 開關、ifqLen、Pt_ 這六個參數(shù)。我自己做對比實驗時會直接把 tcl 腳本打成壓縮包存到 gitcommit 注釋里寫上所有參數(shù)值這樣之后回來對數(shù)據不用猜。6. 進階驗證把 AODV 與 DSR/OLSR 對比并檢查路由表變化的合理性6.1 同一場景跑多種協(xié)議對比的公平性AODV 的指標讓審稿人認可最好加一個同場景下的協(xié)議對比。常見對照組是 DSR 和 OLSR。DSR 是源路由協(xié)議包頭帶完整路徑開銷比 AODV 大但在移動性較低時投遞率高OLSR 是主動式協(xié)議需要周期交換拓撲信息節(jié)點多時開銷高但在拓撲變化快時穩(wěn)健。在 NS2 里切換協(xié)議只改一個字段-adhocRouting DSR或-adhocRouting OLSR。但公平性是關鍵三個協(xié)議必須使用完全相同的移動場景、CBR 流量、傳播模型、MAC 層和仿真時間。你不能給 AODV 開了 Hello 而 DSR 沒開也不能把隊列長度一個設 50 另一個設 100。另外注意 DSR 在 NS2 里需要額外加載 dsrcode路徑是/home/ubuntu/ns2.35/ns-2.35/dsr要在編譯前配置。對比時統(tǒng)計的指標也要一致比如都只統(tǒng)計 AGT 層的投遞率都用同樣的時延定義。6.2 用 nam 動畫檢查 RREQ 洪泛和路由建立比曲線更直觀的是 nam 動畫。運行完 tcl 后用nam mini.nam打開你能看到節(jié)點移動、CBR 包沿多跳路徑前進。AODV 正常工作時你會看到某個節(jié)點發(fā)出一個淡藍色的圓環(huán)擴散開那個就是 RREQ 洪泛隨后一條深色路徑從目的節(jié)點反方向延伸回源節(jié)點那就是 RREP 建立的路徑。如果 RREQ 洪泛反復出現(xiàn)且沒有 RREP 回來說明網絡不連通或者目的節(jié)點不可達。這個驗證方法能幫你快速定位是協(xié)議問題還是場景問題。在沒有輸出 nam 時也可以從 trace 里過濾 RREQ 和 RREP 的時間戳檢查是否在 CBR 開始后的幾十毫秒內出現(xiàn)了 RREP。如果 RREP 從未出現(xiàn)基本可以斷定是鏈路層無法建立連接。6.3 一個實用技巧把節(jié)點移動速度設為 0 做基線驗證我最常做的第一個實驗不是直接調速度而是先把所有節(jié)點設為靜止速度 0、暫停時間永遠跑同一套流量。這樣做有兩個目的一是驗證自己的 tcl 腳本、統(tǒng)計腳本、繪圖流程都沒有 bug因為靜止網絡里 AODV 的投遞率理論上接近 99%除非隊列溢出或 MAC 沖突二是得到一條“理論下界”曲線后續(xù)移動場景的結果不至于比這個基線還好否則說明統(tǒng)計或隨機種子出了問題。靜止場景里如果投遞率不足 95%優(yōu)先查隊列長度和流量負荷而不是懷疑路由協(xié)議。這個習慣幫我排掉了很多腳本錯誤。把速度設 0 的方法很簡單setdest的-M 0就行但要注意 NS2 的setdest對-M 0可能拒絕生成移動指令此時手動給每個節(jié)點寫setdest x y 0并讓暫停時間無限大。為了省事我一般先跑到 5 m/s 的同一組隨機種子再把移動軌跡全注釋掉對比數(shù)據。這條路走到這里AODV 仿真的主流程你已經摸清了。最后想強調一句不要迷信默認參數(shù)也不要隨意改參數(shù)騙曲線。把隨機種子和傳播模型固定下來把所有實驗腳本歸檔別人復現(xiàn)你數(shù)據時才不會在第一步就翻車。希望幫到你。本文還有配套的精品資源點擊獲取