關于無線Mesh網絡信道分配策略的探討
多跳路徑的rtt 用ping 命令來測量，ping 命令功能是發(fā)送icmpecho 數據包[5]。本文將基于hmcp 多跳路徑的rtt 與單信道下多跳路徑的rtt 進行比較。由于單信道中沒有信道切換，比較這兩種情況有助于理解信道切換延遲對多跳路徑的rtt 影響。單信道網絡中，不同路徑的rtt 差距只有數毫秒。而在hmcp 實驗中，信道切換延遲決定了路徑的rtt。
首先，在源節(jié)點和目的節(jié)點間建立一條正向和反向的單一路徑，即從目的節(jié)點到源節(jié)點的反向路徑與正向路徑中的節(jié)點是相同的，只是節(jié)點順序為逆序。在這種情況下，無論何時路徑中信道改變，每個中間節(jié)點的信道切換延遲決定了rtt。在混合多信道協議中，信道改變意味著路徑上的連續(xù)節(jié)點監(jiān)聽著不同的固定信道。對于這種路徑，中間節(jié)點在不同信道上（固定信道在下一跳）傳送數據到目的節(jié)點并且在不同信道上（固定信道在前一跳）回傳給源節(jié)點。由于每個節(jié)點上只有一個可換信道接口，因此，多跳信道轉換中，每個中間節(jié)點在傳送數據到目的節(jié)點和回傳給源節(jié)點的過程中不得不切換信道。正如前面所提到的，可換接口每切換一次信道時，在信道上停留的時間至少為chan_min_time（目前設置為20ms）。當可換接口上的其他信道接收到數據幀時，chan_min_time 定時器開始計時。
因此，多跳路徑的rtt 每增加一跳，rtt 要增加chan_min_time*2。因為中間節(jié)點要發(fā)送數據到目的節(jié)點， 可換接口需要連接到下一跳的接收信道， 在這之前要等待chan_min_time。之后中間節(jié)點要回傳數據到源節(jié)點，需要切換信道到前一跳的接收信道上，這也要等待chan_min_time。因此，每跳rtt 都要增加chan_min_time*2（=40ms）的延遲。表1 顯示的是單信道和多信道下的rtt。在hmcp 實驗中多跳路徑的最小rtt 也符合前面討論的結論。平均rtt ≈ chan_min_time*2（number_of_hops-1）,這里number_of_hops＞1。
在hmcp 實驗中，多跳路徑的最大rtt 值稍微偏高，主要是在網絡中廣播hello 信息的原因。每個節(jié)點廣播一條hello 消息，這條hello 信息包含了它的固定信道和鄰節(jié)點信息。
這些信息每hello_time_interval（默認設置為5s）發(fā)送一次。因此，每5s 每個節(jié)點都會廣播一條信息出去。在hmcp 中，所有信道都會發(fā)送廣播信息。目前，每個節(jié)點使用5 個信道，固定接口發(fā)送數據包到固定信道上，可換接口發(fā)送數據包到其他四個信道上。每hello_time_interval 節(jié)點需要在可換接口上切換3 個信道廣播hello 數據包。因此，如果一個數據包在某個信道上要被轉發(fā)，此時此信道正在發(fā)送廣播消息，那么這個數據包可能要等3 個信道切換完后才被發(fā)送。因此，在某個節(jié)點上，如果數據包排列在廣播信息后發(fā)送，數據包可能會有3*20=60ms 的延遲。最大rtt 之所以偏高的原因就在此。由于在一條路徑的不同節(jié)點上廣播hello 消息，icmpecho 或者icmpechoreply 可能會延遲。ping數據包每分鐘發(fā)送一次，而hello 消息每5 分鐘發(fā)送一次。因此，平均每5 個ping 數據包被hello 消息影響一次。其他4 個ping 數據包的rtt ≈chan_min_time*2*(number_of_hops-1),這里number_of_hops＞1。
而多跳路徑的最小rtt 比理論值稍微低點。這也是由于受hello 消息機制的影響。雖然路徑中的節(jié)點在可換接口上通過切換信道來廣播hello 消息，但是可能有這樣一種情況發(fā)生：