面向高速公路通信系統基于簇的傳輸機制

熊立勝， 何施茗， 羅元盛

(1.湖南省交通運輸廳科技信息中心， 湖南 長沙 410022; 2.長沙理工大學 計算機與通信工程學院， 湖南 長沙 410114)

0 引言

高速公路機電系統主要分為收費系統、監控系統、通信系統3個部分，其中通信系統是收費系統、監控系統的傳輸承載平臺，是高速業務正常運行基礎。湖南高速公路通信網絡結構規劃分為3級模式[1]，2個網絡，即湖南省通信中心(設在長沙市的湖南省高速公路管理局)，各條路的通信管理處(設在各地市)，各路段通信站(設在收費站服務區)。由省中心到各分中心為干線網，各分中心到各收費站為接入網。湖南省高速公路通信系統的拓撲結構見圖1。

圖1 湖南省通信網絡拓撲圖

根據湖南省交通廳《基于混合網絡的高速公路數據實時傳輸保障平臺及分布式存儲協同機制關鍵技術研究》項目調研報告，雖然湖南省高速公路通信光纖專網早已建成，且隨著新高速公路的竣工還在不斷延伸，但存在以下問題： ① 高速公路光纖專網鏈路質量不均衡。每條高速的建設年代不一樣，光纖專網也因鋪設年代不同而存在不同程度的老化與損壞。例如: 永州管理處大部分高速公路是去年或前年通車，高速公路光纖專網通信質量很好；而老高速公路，如長沙至益陽至常德、京珠高速湘潭以南等，這些建成已有10a以上的高速光纖網，經常發生中斷。 ② 長沙是湖南省高速公路光纖專網的邏輯中心節點，是各種業務數據的存儲中心、指揮中心。長沙周邊的高速公路光纖專網普遍因使用年限久經常發生中斷，由于目前干線傳輸系統還不是網狀組網，新的高速專網必須通過這些老的高速專網才能與省中心連通，從而導致新的高速專網也無法連接到省中心。③ 高速公路光纖專網的規模和覆蓋范圍與電信等專業公司相差無幾，但在設備和維護等方面投入遠小于專業公司。光纖經過多次熔接，信號衰減嚴重，導致出現網絡抖動、數據傳輸延遲長、丟包等極端狀況。雖然專網沒斷，但是間歇性出現上述現象。因此，單純依賴光纖專網來保障實時性、穩定性、可靠性要求高的各種業務應用系統是不現實的。

為解決傳輸可靠性問題，本文面向高速公路通信系統特點，設計基于簇的傳輸機制。高速公路通信系統依附高速公路修建，本身具有地理位置物理特性，地理位置上已經形成簇。基于簇的傳輸機制，可以提供雙層的可靠性傳輸保障，提高可靠性。設計簇頭選擇標準和算法，基于此進行分簇，并設計基于簇的數據傳輸機制的協議，形成分層的通信方式。實驗表明，基于簇的傳輸機制比直接傳輸具有更少的傳輸延時和傳輸完成時間。

1 相關工作

國內針對高速公路數據通信方面的研究成果主要有：長安大學楊曉東及其團隊成員李楠提出的區域高速公路網通信系統規劃研究與應用[2]，以提高通信系統資源利用率和指導通信系統建設為目標，提出了通信系統網絡架構；復旦大學戴偉輝及其團隊成員谷雨為上海高速公路平臺提出了一套以IEEE 802.3ae萬兆以太網技術為核心的高速公路通信網解決方案[3]，該方案采用新技術，成功解決了上海高速公路網絡業務的通信需求；龔樹超[4]提出了構建高速公路網無線寬帶網絡的設想，并且對比了專用無線寬帶網絡與租用無線寬帶網絡這兩種模式的優缺點。李新法等[5]提出了對現有高速公路通信系統MSTP傳輸網架構進行全IP通信網的設計方案。孫蕓麗[6]從網絡結構合理性、可擴展性、數據傳輸穩定性等方面出發比較了SDH網絡和智能ASON網絡，分析并探討如何合理、科學地構建省域高速公路骨干通信系統網絡。王露[7]、王輝[8]利用PTN技術，為高速公路通信網組建多種結構的業務傳送平臺，向集中的業務節點與開放型、分布式、一體化接入網相結合的方向發展，使通信網絡從綜合成本、效益與效率、網絡可拓展性等諸多層面適應新時期的發展趨勢，全面提高通信網絡的業務能力。結合湖北黃黃高速公路萬兆環網建設實例[9]，通過改造高速公路通信系統來提高傳輸可靠性。總體而言，國內對高速公路數據通信方面的研究主要集中在通信網規劃設計和改造方面，有關數據可靠傳輸方面的研究成果還比較少。而在計算機網絡研究領域，其研究成果比較豐富[9-13]，但是大部分成果沒有結合高速公路應用背景，其實際工程應用效果還有待檢驗。

2 簇頭選擇指標設計

簇頭選擇指標從節點間選出能力最佳的節點設置為簇頭[14-16]。分布式自適應簇頭的選取結合最大節點ID算法和延時權重算法。延時權重WD由節點與省中心、節點與鄰居節點的延時共同決定，計算如下：

WD=W*Delayc+(1-W)*D，W∈[0，1)

(1)

其中，Delayc為節點與省中心連接的延時。每次節點與省中心通信過程中，都會記錄一個新的延時Delayc。為了計算的精確性，也可以利用歷史數據進行時間序列分析;D為節點與鄰居節點的平均延時。

假設某個節點有n個有效鄰居節點，那么平均延時為：

(2)

當出現兩個節點WD相等時，選擇節點ID較大的節點作為簇頭節點。

3 基于簇的傳輸機制設計

3.1 消息和數據結構設計

為了完成分布式分簇和基于簇的傳輸，需要進行消息傳遞和存儲相應的數據。每個節點都存儲以下數據結構：省中心連通狀態表、簇頭選擇指標、簇頭和簇成員表，省中心存儲簇信息表。

省中心連通狀態表用于記錄節點到省中心的連通情況，尤其是與省中心的延時用于計算簇頭選擇指標。包括省中心節點id，網絡類型，IP地址，延時Delayc，連通率PDR，歷史延時Delay_old。

簇頭選擇指標是根據式(1)中計算的本節點的指標值，是一個雙精度的浮點數。

簇頭是記錄節點所處的簇的簇頭節點id，如果節點還未加入簇，該值為空。

簇成員表用于記錄所處簇包含的節點id。

簇信息表由省中心存儲，用于記錄所有簇的簇頭和簇成員節點信息，簇信息表的每一項包含簇頭id，簇成員節點id list。

協議消息包括簇加入消息(hello-join)、簇頭存在消息(hello-CH)、簇成員存在消息(hello-CM)、簇競選消息(hello-cont)、簇成員匯報消息。消息格式如表1。

表1 分簇主要消息格式格式序號消息格式1消息類型hello-join,發送節點id,目的節點id,消息編號2消息類型hello-CH,發送節點id,目的節點id,消息編號,簇成員節點id list3消息類型hello-CM,發送節點id,目的節點id,簇頭節點id,消息編號4消息類型hello-cont,發送節點id,目的節點id,消息編號,簇頭選擇指標值5消息類型簇成員匯報,發送節點id,目的節點id,消息編號,簇頭,簇成員節點id list

3.2 分簇協議

節點在分簇過程中存在3種狀態：未確定狀態(UN)、簇頭狀態(CH)和簇成員狀態(CM)。節點之間通過消息傳遞，改變自身狀態，計算簇頭選擇指標來完成分簇。節點狀態轉移見圖2。

節點x初始處于UN狀態，發送hello-join請求加入簇，等待t1時間。如果收到來自簇頭的hello-CH就加入該簇，對應箭頭(1)；否則，發送hello-cont進入競爭選擇新簇頭的階段。

hello-cont中包含本節點的簇頭選擇指標值，鄰居節點也都發送hello-cont，等待t2時間。指標最小的節點xi當選簇頭，xi發送hello-CH，對應箭頭(2)；別的收到hello-CH的節點成為該簇成員，對應箭頭(1)。

圖2 節點狀態轉移圖

簇頭將簇成員信息匯報給省中心。執行流程如下所示。

3.2.1算法1：節點x處于UN狀態

① 給有效鄰居發送hello-join請求加入簇，等待t1時間；如果收到來自簇頭j的hello-CH消息，就加入該簇，對應箭頭(1)，發送hello-CM給簇頭j，節點x的狀態改為CM；否則給有效鄰居發送hello-cont，等待t2時間；進入競爭選擇新簇頭的階段：收到有效鄰居節點發送的hello-cont；將自身的簇頭選擇指標與收到的有效鄰居節點比較，指標值是否最小；是則節點x當選簇頭，對應箭頭(2)，節點x的狀態改為CH，簇成員表是之前收到了hello-cont的有效鄰居節點，節點x向簇成員表中的節點發送hello-CH；如果收到來自節點j的hello-CH；節點x成為節點j的簇成員，回復hello-CM，簇頭設定為節點j，對應箭頭(1)，節點x的狀態改為CM。② 如果收到來自節點i的hello-cont消息，回復hello-cont消息，等待t2時間；進入競爭選擇新簇頭的階段。

3.2.2算法2：節點x處于CH狀態

① 定時t1給簇成員節點發送hello-CH消息；超過時間未收到成員節點的hello-CM消息，刪除該成員節點；匯報簇成員節點信息給省中心。② 如果收到來自節點i的hello-join消息，回復hello-CH消息；如果收到節點i的hello-CM，簇成員表新增節點i。③ 如果收到來自簇頭節點j的hello-CH消息，等待t4時間；簇合并：如果還可以接收hello-CH就重新成簇；簇頭節點交換兩者的指標值，是否指標值較小；是則節點x保留為簇頭，節點x的簇成員表新增節點j的簇成員；節點x向簇成員表中節點發送hello-CH；利用簇成員匯報消息，匯報簇成員節點信息給省中心；否則節點x變成簇成員，對應箭頭(6)，節點x的狀態改為CM，節點x的簇頭設為節點j。

3.2.3算法3：節點x處于CM狀態

① 如果收到來自簇頭節點j的hello-CH消息，回復hello-CM消息。② 如果超過時間t3未收到簇頭節點j的hello-CH消息，刪除簇頭信息，對應箭頭(4)，節點x的狀態改為UN，簇分離。 ③如果收到來自節點i的hello-cont消息，回復hello-cont消息，等待t2時間；進入競爭選擇新簇頭的階段。

在協議過程中，在節點狀態改變時需要對簇頭和簇成員表進行重置。節點x改為UN狀態，簇頭和簇成員表清空；節點x改為CH狀態，簇頭設為節點x；節點x改為CM狀態，簇成員表清空。

省中心根據簇頭發送的簇成員匯報消息，構建和更新簇成員表。

3.3 簇維護協議

通過消息傳遞和節點狀態改變，來實現簇分裂和合并。

簇維護過程中，簇頭i以周期t1發送hello-CH來維護簇。

簇分離過程中，1個CM狀態的節點在t3時間內沒有收到任何hello-CH；進入競爭簇頭階段，計算指標，發送hello-cont。等待t2時間，最小指標的CM節點成為簇頭發送hello-CH，對應箭頭(3)。一個CM或CH狀態節點在t3時間沒有收到任何hello-CH或hello-CM消息，就可以認為沒有任何鄰居存在，退回到UN狀態，對應箭頭(4)、(5)。

簇合并過程中，1個CH狀態的節點收到別的節點發出的hello-CH，等待t4時間，如果還可以接收hello-CH就重新成簇，簇頭節點交換兩者的指標值，指標值較小的保留為簇頭，較大的變成簇成員，對應箭頭(6)。

3.4 基于簇的數據傳輸協議

分布式分簇后，利用簇頭進行中繼數據傳輸和確認機制，且保證每個節點至少收到1份來自省中心的數據拷貝[17]。協議消息包括數據包和3類確認消息(ACK1，ACK2，ACK3)。3類確認消息用于簇頭和省中心、簇頭和簇成員之間的確認，數據的格式如表2。

表2 數據包與確認消息數據格式格式序號數據格式1源節點id,目的節點id,目的節點id List,數據包編號,網絡類型,數據內容2確認消息類型ACK,源節點id,目的節點id,確認數據包編號3確認消息類型ACK2,源節點id,目的節點id,確認數據包編號4確認消息類型ACK3,源節點id,目的節點id,確認數據包編號,未正確收到簇成員節點id list

對于省中心發出的數據，目的節點id設為簇頭id，目的節點id list設為簇成員節點的id list。簇頭在收到數據包后，按目的節點id list再進行轉發，將目的節點id list的節點作為目的節點繼續發送。

3.4.1算法4：省中心數據傳輸流程

① 省中心需要發送信息。對簇信息表中的所有簇構建數據包，其中目的節點id設為簇頭id，目的節點id list設為簇成員節點的id list；發送數據包；等待時間t5。②如果收到來自簇頭j的ACK3消息，如果存在未正確接收的節點，重傳整個傳輸單元。

3.4.2算法5：簇頭數據傳輸流程

① 如果收到來自省中心的數據包，回復ACK1；對于目的節點id list中的所有節點i，構建數據包，其中目的節點id設為節點i，目的節點id list設為空；發送數據包；等待時間t5。② 如果收到來自簇成員節點i的ACK1消息，節點i正確收到。③t5定時器觸發，根據未收到數據包的簇成員節點構造ACK3。

3.4.3算法6：簇成員傳輸流程

① 如果收到來自簇頭的數據包，回復ACK2。

為保證每個節點至少收到一份來自省中心的數據拷貝，考慮采用3次確認機制(見圖3)。

圖3 基于簇頭轉發確認機制圖

Step1： 省中心發送數據包給簇頭節點，對應箭頭(1)；如果簇頭正確收到，簇頭節點對省中心進行第一次回復確認ACK1，對應箭頭(2)。

Step2 ：簇頭將數據轉發給所有簇成員節點，對應箭頭(3)；如果簇成員節點正確收到，簇成員節點對簇頭進行第二次回復確認ACK2，對應箭頭(4)。

Step3： 簇頭等待t5時間后，根據ACK2統計正確收到的簇成員節點，將未正確收數據的簇成員節點id發送給省中心，進行第三次回復確認ACK3，對應箭頭(5)。

設定傳輸單元為1個路徑文件或1個視頻文件。當省中心確定某一個節點未正確收到傳輸單元中的某一個數據包時，省中心通過別的路徑重傳整個傳輸單元。

4 性能分析

仿真實驗在NS2中進行，n0為省中心，30個收費節點分別為n1到n30。節點之間通過vpn和光纖互聯，網絡拓撲結構如圖4所示，鏈路的參數如表3所示。省中心向所有節點發送相同數目的數據包，采用TCP的FTP類型應用，數據包大小為1000 byte。一個路徑信息大約為500 k字節，那么一個路徑信息需要發送500個數據包。

采用2種傳輸方式，直接傳輸和分簇傳輸方式。直接傳輸采用vpn鏈路，傳輸采用的路徑結果如圖5所示。分簇傳輸利用光纖，路徑結果如圖6所示，其中設定分為3個簇，每個簇大小為10個節點，簇頭節點為簇中編號最小的節點。

圖4 網絡拓撲結構

表3 鏈路參數類型帶寬/Mbps延時/ms丟包率/%vpn 10205光纖100 81

每個流的路徑信息發送量從1、2 增加到20。由于存在30個并發流，那么省中心就需要發送30，60到600個路徑信息。圖7和圖8是不同發送量下，2種傳輸方式的數據包延時和路徑信息平均完成時間比較。由于有TCP的發送窗口限制，在并發流數目確定的情況下，延時和路徑信息平均完成時間變化不大。

節點數目從10，20增加到50，每個流發送5個路徑信息。分簇情況下，每個簇大小為10個節點，那么簇的數目將從1，2增加到5。圖9和圖10是不同節點數目下，2種傳輸方式的數據包延時和路徑信息平均完成時間比較。

圖5 直接傳輸路徑

圖6 分簇傳輸路徑

圖7 延時受發送量影響

圖8 路徑信息平均完成時間受發送量影響

圖9 延時受節點數目影響

圖10 路徑信息平均完成時間受節點數目影響

5 結語

為解決高速公路通信系統可靠性傳輸問題，面向高速公路通信系統特點，設計基于簇的傳輸機制，設計簇頭選擇標準和算法，基于此進行分簇，并設計基于簇的數據傳輸機制的協議，形成分層的通信方式。實驗表明，基于簇的傳輸機制比直接傳輸具有更低的傳輸延時和傳輸完成時間。