WiMinet 評說1.3：模擬式UDP中繼技術缺陷

在《WiMinet 評說 1.2：多跳無線網路的現狀》一文中，我們提到：在室外長距離的無線自組織網路中，由於節點之間的鏈路損耗較大，其鏈路預算相對不足，其包誤位元速率PER會相應升高，也就是丟包機率 p 會比較大；而在一個大規模網路中，某些分支節點的通訊鏈路又會比較深，也就是網路跳數 n 比較大，在這種情況下其通訊成功率P _n自然也就顯著下降了，人們的切身感受就是這個鏈路不太穩定。

此時人們的第一反應自然是上 TCP 演算法，在傳送節點啟用 TCP Client 演算法，在接收點啟用 TCP Server 演算法，實現端到端的控制，這樣不就可以解決多跳無線通訊網路的可靠性了麼？我們今天就來深入討論一下這個問題。

很顯然在一個真實的無線通訊系統中，每一個節點都是具備雙向收發能力的，但是為了更加清晰的描述資料流向，我們將原始資料的發出者定義為發射機，將目標資料的接受者定義為接收機；如下圖所示，我們定義左邊紅色的“鐵塔”為發射機，右邊藍色的“鍋蓋”為接收機。

圖1-發射機與接收機

在一個較大規模的無線通訊網路中，中繼通常有兩種存在形式，一種是獨立的中繼器，通常其硬體配置較高，效能也比較強勁，並安裝有多根天線；另外一種是普通的資料節點本身承擔資料轉發的功能，這種節點成本較低，通常僅僅配置一根天線。無論其硬體配置和工作原理如何，它們都可以承擔資料轉發的功能，為了更加直觀的描述中繼的工作機制，我們以雙天線的中繼器為例。

圖2-多跳無線中繼

在多數情況下，負責引數通訊的還有外部的使用者系統，比如連線資料庫的上位機應用程式和連線現場工業感測器的嵌入式裝置；通常負責發起資料請求的是上位機應用程式，二者以RJ45乙太網線或者RS232電纜連線。

圖3-上位機應用軟體

負責採集資料並回傳的是嵌入式裝置，二者以RS232電纜，TTL電平的串列埠或者GPIO埠直接相連。

圖4-下位機現場裝置

按照我們之前的約定，我們選定網路中一個具有6跳的（5箇中繼）分支鏈路，在該鏈路上一個標準的通訊業務流程通常如下：

(1) 上位機系統發起資料請求

(2) 資料請求透過有線電纜傳遞給發射機

(3) 發射機將資料傳送給1號中繼

(4) 資料依次在中繼1 → 2 → 3 → 4 → 5 之間傳遞，最後到達接收機

(5) 接收機將資料透過有線電纜傳遞給嵌入式系統

(6) 嵌入式系統採集資料

注意到，這裡僅僅是資料的下行請求過程，在嵌入式系統完成了資料的採集之後，就會將其作為應答回傳給上位機系統，其上行通訊流程剛好和下行傳輸完全相反：

(1) 嵌入式系統送出採集到的資料

(2) 資料應答透過有線電纜傳送給接收機

(3) 接收機將資料傳送給5號中繼

(4) 資料依次在中繼5 → 4 → 3 → 2 → 1 之間傳遞，最後到達發射機

(5) 發射機將資料透過有線電纜傳遞給上位機系統

(6) 上位機系統完成資料的儲存，計算和顯示

我們都知道，有線通訊由於在封閉的通道中執行，其錯誤率通常在 10 ^-9~10 ^-12，可靠性是非常高的，我們基本不用考慮丟包的問題。這裡為了敘述方便，我們將上位機應用程式的功能合併到發射機中去，將連線工業感測器的嵌入式裝置的功能合併到接收機中去，這樣簡化之後的模型就是下圖。

圖5-UDP多跳傳輸模型

在該模型中，每一個角色的基本工作原理如下：

(1) 發射機：產生資料請求，傳送給中繼1，然後轉入接收狀態，等待來自目標節點（接收機）的應答資料；如果在指定的時間之內收到了應答資料則代表通訊成功；如果沒有則重新傳送請求並增加計數器；當計數器到達某個限定數值則認定通訊失敗。

(2) 接收機：平時處於接收等待狀態，一旦從中繼5接收到了來自發射機的請求資料，則立刻生成應答資料，並交給中繼5。

(3) 中繼器：按照報文約定的指定的傳輸方向，複製報文並以重新傳送給下一個接收節點，包括中繼，發射機和接收機。

上圖是丟包機率 p = 10% 的時候的一種效果模擬圖。這裡設定了5次資料重傳，從該圖我們看出來每一次的通訊丟包情況都不同：

(1) 新資料請求，在發射機到中繼1的下行鏈路上就丟失了

(2) 第1次重傳，在中繼2到中繼3的下行鏈路上丟失了

(3) 第2次重傳，下行鏈路各跳全部成功，接收機正確的收到了資料，並生成了應答，但是應答資料在中繼5 → 中繼4的上行鏈路上丟失了

(4) 第3次重傳，在中繼3到中繼4的下行鏈路上丟失了

(5) 第4次重傳，下行鏈路各跳全部成功，接收機正確的收到了資料，並生成了應答，但是應答資料在中繼2 → 中繼1的上行鏈路上丟失了

(6) 第5次重傳，在在中繼5到接收機的下行鏈路上丟失了

(7) 重傳計數器到達極限，應用程式判定當前鏈路不穩定，通訊失敗！

當然有的讀者心裡會想，這個效果模擬圖太過於極端，上述流程中有好幾次差一點就通訊成功了呢，就差一口氣！如果我們加大嘗試的次數，說不定就成功了呢?

事實上在大多數情況下，加大嘗試次數，通訊成功率的確會有一定的改善，但無法從根本上消除問題。考慮到有線鏈路的和無線多跳的通訊延遲，再疊加上目標裝置的資料採集行為，下行或者上行鏈路的傳輸時間可能高達數百毫秒。

在真實的環境中，還要考慮到各種系統延遲和等待操作，比如Windows，Linux等主流桌面作業系統的排程延遲，各級無線節點的微控制器延遲，這個時間往往還需要進一步加大，最終這個總的時間往往高達數秒甚至幾十秒，在一個有幾百個節點的資料採集系統中，系統整體掃描一遍，耗時將會比較長了。

從上述分析可以看出，端到端的重傳機制在跳數較深的無線自組織網路中難以保證足夠的可靠性，即便犧牲延時，加大重傳次數，效果也不會有根本性的改善。那麼問題來了！我們要怎麼做才可以獲得理想的可靠性與實時性呢？敬請關注後續系列文章的深入解讀。