基于MQTT的遙測數(shù)據(jù)無線傳輸

馬鑫龍，艾冬生，孫發(fā)魚，張景鵬

(西安機電信息技術研究所，陜西 西安 710065)

0 引言

隨著現(xiàn)代武器系統(tǒng)的復雜度提升，如火力打擊平臺、通訊指揮平臺、故障診斷平臺統(tǒng)一構成的網(wǎng)絡化綜合戰(zhàn)場系統(tǒng)，往往需要采集多個點位的數(shù)傳、圖像、音頻等不同類型數(shù)據(jù)，要求遙測終端具有多點位采集[1-2]、大容量傳輸及多數(shù)據(jù)融合與管理能力。傳統(tǒng)固定的單節(jié)點或有限節(jié)點的測試模式隨著武器種類、試驗頻度和測量數(shù)據(jù)類型的增多，已經(jīng)不能適應海量數(shù)據(jù)的傳輸和多源數(shù)據(jù)融合的需求。多節(jié)點、動態(tài)移動化測試模式必將為武器系統(tǒng)提供更好的測試保障[3]。

隨著硬件、軟件和大數(shù)據(jù)技術的高速發(fā)展，朱澤鋒[1]、譚維熾[4]等人都對大數(shù)據(jù)時代的遙測進行了分析和展望；呂鵬等對遙測進行了網(wǎng)絡化的整體設計[5]。但均沒有對目前使用的技術進行測試與對比分析。本文對目前遙測數(shù)據(jù)處理系統(tǒng)存在的單節(jié)點管道測試數(shù)據(jù)的采集、傳輸和管理在多節(jié)點、動態(tài)移動化測試下會存在數(shù)據(jù)包丟失和不適用的問題，提出了基于消息對列遙測傳輸(MQTT)協(xié)議的遙測數(shù)據(jù)無線傳輸方法。

1 遙測數(shù)據(jù)傳輸問題及分析

在基于客戶機/服務器(C/S)架構的遙測數(shù)據(jù)傳輸系統(tǒng)中，使用的數(shù)據(jù)傳輸協(xié)議是用戶數(shù)據(jù)報協(xié)議(UDP)，它建立在互聯(lián)網(wǎng)(IP)協(xié)議上，提供無連接數(shù)據(jù)報傳輸，支持雙向的數(shù)據(jù)流傳輸，但并不保證是可靠、有序、無重復的。數(shù)據(jù)報方式取消了重發(fā)和校驗機制，能夠達到較高的傳輸速率。在固定單節(jié)點的測試模式下，數(shù)據(jù)在局域網(wǎng)內(nèi)傳輸，網(wǎng)絡條件穩(wěn)定，通過設置緩沖區(qū)，多線程控制的方式可以有效地避免數(shù)據(jù)包的丟失達到數(shù)據(jù)的快速準確傳輸。隨著現(xiàn)代武器測試復雜度的提升，除了對武器及其內(nèi)部載荷的檢測之外，還有諸如外部氣象環(huán)境、磁環(huán)境、目標特性測量、實況圖像等信息等等。在多節(jié)點、移動化測試條件下相較于傳統(tǒng)的單節(jié)點固定式不能采用一對一網(wǎng)線電纜傳輸，而無線局域網(wǎng)的環(huán)境下會受到測試環(huán)境內(nèi)其他信號源干擾導致信號不穩(wěn)定從而使UDP協(xié)議傳輸產(chǎn)生大量丟包，并且當服務器的負載過高，并行操作過多時，不能及時處理內(nèi)核socket緩沖區(qū)中的UDP包時會產(chǎn)生丟包，在同一個端口發(fā)送的數(shù)據(jù)量太大時會導致網(wǎng)卡丟包，相對于有線傳輸在網(wǎng)絡條件不穩(wěn)定時也會產(chǎn)生數(shù)據(jù)包的丟失[6]。

考慮到可能存在的高并發(fā)性與數(shù)據(jù)的準確性要求，提出基于消息隊列遙測傳輸(MQTT)協(xié)議的傳輸方式來滿足未來云架構下的遙測數(shù)據(jù)傳輸處理。

1.1 MQTT協(xié)議

MQTT協(xié)議最初是由IBM于20世紀90年代晚期主導開發(fā)的物聯(lián)網(wǎng)傳輸協(xié)議。它是用于輕量級的發(fā)布/訂閱式消息傳輸，旨在為低帶寬和不穩(wěn)定的網(wǎng)絡環(huán)境中的物聯(lián)網(wǎng)設備提供可靠的網(wǎng)絡服務[7-9]。它是一個開源、可靠、輕巧、簡單的網(wǎng)絡傳輸協(xié)議。

圖1 MQTT協(xié)議通信模型Fig.1 MQTT protocol communication model

MQTT通過發(fā)布/訂閱模式實現(xiàn)[4]，利用主題建立發(fā)布方和訂閱方之間的消息傳輸通道。MQTT由消息代理服務器(Broker)和MQTT客戶端組成。MQTT客戶端既可以是發(fā)布者，也可以是訂閱者，發(fā)布者發(fā)布消息到消息代理Broker，訂閱者向消息代理訂閱或取消訂閱應用消息。MQTT消息代理服務器作為發(fā)布方和訂閱方之間的中介，接收來自客戶端的連接請求及發(fā)布的消息，處理客戶端代理方的訂閱請求并轉發(fā)應用消息。

具有以下幾項特征：

1) 通信開銷非常小，最小的消息大小為2 B；

2) 支持多種流行語言且易于使用客戶端；

3) 支持發(fā)布/訂閱模型，簡化應用程序的開發(fā)；

4) 提供三種不同的服務質(zhì)量(QoS，Quality of Service)，讓消息能按需到達目的地，適應在不穩(wěn)定的網(wǎng)絡傳輸需求。

1.2 MQTT的QoS消息交付質(zhì)量等級分析

QoS是發(fā)送者和接收者之間對于消息傳遞的可靠程度的協(xié)商。QoS的設計是 MQTT 協(xié)議里的重點，旨在協(xié)議層解決傳輸質(zhì)量問題。

1) QoS 0服務質(zhì)量等級:至多分發(fā)一次。發(fā)布者向接收者發(fā)送一個PUBLISH包后不管結果如何，丟掉已發(fā)送的包，發(fā)送完成。為不可靠發(fā)送，可能出現(xiàn)丟包。

2) QoS 1服務質(zhì)量等級:至少分發(fā)一次。發(fā)布者發(fā)送一個PUBLISH報文后需接到接收者回復一個PUBACK確認。該種方式保證傳輸?shù)目煽啃?，但可能重復發(fā)送。

圖2 QoS服務質(zhì)量等級Fig.2 Quality of service

3) QoS 2服務質(zhì)量等級:僅發(fā)一次。最高等級的服務質(zhì)量，保證消息的可靠交付，并且不會重復，只有一次到達。接收方收到PUBLISH報文后回復一個PUBREC消息，發(fā)送方接收到PUBREC報文后，回復PUBREL報文，接收方收到PUBREL報文后回復PUBCOMP消息。該方式使用多次確認，保證了消息的可靠傳輸，但其需要的開銷較大，傳輸效率最低。

2 基于MQTT的遙測數(shù)據(jù)無線傳輸方法

2.1 無線遙測數(shù)據(jù)傳輸去重算法

通過對比三種交付質(zhì)量等級，為了兼顧效率和準確性，本文選擇使用QoS1等級的服務質(zhì)量。QoS1存在可能出現(xiàn)重復的問題，所以需要在應用里手動對消息進行去重設置。避免重復的做法就是在消息數(shù)據(jù)里面設置一個唯一的消息ID，訂閱端保存已經(jīng)收到的消息ID。當收到新消息的時候，通過消息的ID來判斷是否是重復的消息，如果重復，則丟棄；如果沒有重復則更新消息ID并存儲數(shù)據(jù)包。這樣做就可以保證消息的可靠性和準確性的同時不會出現(xiàn)重復的問題。該算法適用于在使用MQTT協(xié)議時需要保證數(shù)據(jù)的準確性的同時又要兼顧傳輸速度的情況，在應用程序客戶端進行去重處理，就減少了對數(shù)據(jù)傳輸速度的影響。算法流程圖如圖3所示。

圖3 去重算法流程Fig.3 Deduplication algorithm flow

2.2 無線遙測數(shù)據(jù)傳輸整體模型

在實時獲取數(shù)據(jù)時，串行PCM碼流經(jīng)解調(diào)卡串/并轉換，以字節(jié)為單位存到解調(diào)卡緩沖區(qū)，當解調(diào)卡緩沖區(qū)達到一定數(shù)量時，會觸發(fā)中斷，讓解調(diào)卡驅動程序把數(shù)據(jù)取走，存入到內(nèi)存緩沖區(qū)中。網(wǎng)絡發(fā)送緩沖區(qū)將驅動程序緩沖區(qū)中的數(shù)據(jù)取出存放并封裝發(fā)送到中心服務器所發(fā)送的主題(topic)中?？蛻舳擞嗛喎掌鞫酥袑膖opic訂閱消息時，網(wǎng)卡驅動程序將遙測數(shù)據(jù)放入網(wǎng)絡接收緩沖區(qū)，接收線程將接收緩沖區(qū)內(nèi)的數(shù)據(jù)放入內(nèi)存緩沖區(qū)，當啟動存儲或者實時顯示功能時，接收線程便將遙測數(shù)據(jù)放入存儲緩沖區(qū)和顯示緩沖區(qū)，通過存儲線程和顯示處理線程調(diào)用。MQTT協(xié)議最多可以傳輸256 MB的報文，如果直接以最大長度傳輸，在傳輸時需要開辟很大的緩沖區(qū)，在地面接收嵌入式設備中很難保證，考慮到網(wǎng)絡環(huán)境不穩(wěn)定的情況，網(wǎng)絡傳輸?shù)臄?shù)據(jù)包長度越大傳輸過程中出錯的幾率就越高，一旦數(shù)據(jù)包收不到就會增大開銷，導致傳出效率和成功率低，需要適當選擇傳輸負載的大小。在發(fā)布端向MQTT服務器以及MQTT服務器向訂閱端傳輸時都采取QoS1的質(zhì)量等級，保證數(shù)據(jù)質(zhì)量。

圖5 整體傳輸流程Fig.4 Overall transmission process

在多節(jié)點、動態(tài)化的測試模式下，多個客戶端連入同一個中心服務器，每個客戶端既可以是發(fā)布者也可以是訂閱者，發(fā)布者和訂閱者都與之對應一個topic，不同的topic之間互不影響各自的傳輸。

3 系統(tǒng)測試

3.1 協(xié)議測試

使用iperf測試工具來測試無線網(wǎng)絡中UDP數(shù)據(jù)包的傳輸性能，輸入“-u”，傳輸100MB的UDP數(shù)據(jù)包會出現(xiàn)0.3%左右的丟包，使用EMQTT benchmark對MQTT服務器進行測試選擇“-q 1”的服務質(zhì)量，模擬100個客戶端以每秒100條發(fā)送消息，多次測試后在一段時間不會發(fā)生丟包。

3.2 客戶端之間消息傳輸測試

為了檢驗在QOS1的服務質(zhì)量和設置標志位去重的條件下對遙測數(shù)據(jù)實時傳輸性能的要求，進行數(shù)據(jù)包傳輸時延測試。

在發(fā)布端使用定時器間隔60 ms發(fā)送一次數(shù)據(jù)確保數(shù)據(jù)能發(fā)送且不會影響到下一次發(fā)送，數(shù)據(jù)通過代理服務器發(fā)布到接收端，通過Wireshark軟件抓包來測試時延。

本設計共進行10次實驗，每次實驗時間1 min，時延結果取平均值后結果如圖5所示。

圖5 平均時延Fig.5 Average delay

通過圖5可以得出端對端的平均時延大概在15～19 ms之間波動，時延低是滿足實驗需求的，波動原因可能和數(shù)據(jù)傳輸時網(wǎng)絡條件有關。

在QOS1下傳輸負載為5 KB，10 KB，20 KB,40 KB,80 KB時對端對端的時延進行測試，結果如圖6所示。

圖6 有負載時延Fig.6 With load delay

圖6對負載不同時端到端的時延進行了測試，由圖中可以看出隨著負載的增大時延逐漸增大，但時延都在0.5 s以內(nèi)。在今后的整體系統(tǒng)實驗測試中調(diào)整負載的大小以達到數(shù)據(jù)實時穩(wěn)定傳輸?shù)囊蟆?/p>

4 結論

本文提出了基于MQTT協(xié)議的遙測數(shù)據(jù)傳輸方法。該方法有效地解決了傳統(tǒng)單節(jié)點遙測數(shù)據(jù)傳輸在多節(jié)點動態(tài)測試向中心服務器傳輸過程中存在的準確性問題，通過采用QoS1的服務質(zhì)量等級解決了傳統(tǒng)遙測傳輸中使用UDP協(xié)議在傳輸過程中存在的丟包問題，通過設置標志位去重的算法解決了數(shù)據(jù)包可能出現(xiàn)的重復問題。仿真測試結果表明，該方法在數(shù)據(jù)傳輸壓力測試過程中，沒有出現(xiàn)數(shù)據(jù)丟失的情況；通過在應用程序客戶端標志位判定不會對數(shù)據(jù)包傳輸過程造成影響，滿足傳輸效率要求，達到設計的預期效果，為之后的遙測大數(shù)據(jù)挖掘打下了基礎。