隨著智能化浪潮席卷全球，如今的車輛早已不再是單純的交通工具，而是一個(gè)具備自主推理能力、能和云端交互進(jìn)行車路協(xié)同的移動(dòng)智能節(jié)點(diǎn)。
很多的新型應(yīng)用場(chǎng)景不但計(jì)算量巨大，而且對(duì)通信鏈路有非常強(qiáng)的低時(shí)延、低能耗和高可靠要求。傳統(tǒng)的通信協(xié)議如 HTTP 等并不能同時(shí)滿足以上要求。而作為目前物聯(lián)網(wǎng)領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)協(xié)議，MQTT 提供了 Pub/Sub 的消息模式，具備精簡(jiǎn)優(yōu)良的協(xié)議設(shè)計(jì)，可以滿足低延時(shí)和低功耗的需求，適用于資源有限的車機(jī)系統(tǒng)。
但不同于智能家居、機(jī)器人這類設(shè)備固定且網(wǎng)絡(luò)環(huán)境穩(wěn)定的場(chǎng)景，車聯(lián)網(wǎng)中快速移動(dòng)、場(chǎng)景切換快、網(wǎng)絡(luò)情況復(fù)雜多變等特性，對(duì) MQTT 協(xié)議在車端和服務(wù)端的應(yīng)用提出了更高的要求。
本文將深入分析車聯(lián)網(wǎng)移動(dòng)場(chǎng)景下 MQTT 消息傳輸面臨的問題及產(chǎn)生原因，并利用 MQTT 協(xié)議特性對(duì)其加以解決和優(yōu)化，幫助用戶構(gòu)建更穩(wěn)定的車聯(lián)網(wǎng)通信架構(gòu)。
當(dāng)你高速駕駛時(shí)，當(dāng)你穿越隧道時(shí)，網(wǎng)絡(luò)實(shí)際發(fā)生了什么？
相信大家使用 4G 手機(jī)時(shí)都有過類似體驗(yàn)：進(jìn)入地下室時(shí)信號(hào)強(qiáng)度突然變?nèi)?，雖然網(wǎng)絡(luò)沒有顯示中斷，但是實(shí)際使用體驗(yàn)就和斷網(wǎng)一樣；亦或是在一個(gè)很大區(qū)域的 WiFi 網(wǎng)絡(luò)范圍內(nèi)移動(dòng)，在不同的 AP（無線接入點(diǎn)）覆蓋范圍之間切換時(shí)也會(huì)有類似情況。這就是一個(gè)典型的移動(dòng)設(shè)備導(dǎo)致的網(wǎng)絡(luò)遷移問題。
而在車聯(lián)網(wǎng)中，由于車輛是高速移動(dòng)，特別是在高速公路基站覆蓋稀疏或穿過隧道的情況，都會(huì)導(dǎo)致這種問題更加頻繁地出現(xiàn)，從而引起車機(jī)端 MQTT 連接中斷重連。
首先我們來看看車聯(lián)網(wǎng)場(chǎng)景面對(duì)的網(wǎng)絡(luò)現(xiàn)狀：根據(jù) 2020 年底的數(shù)據(jù)，我國(guó)基站總數(shù)為 931 萬個(gè)，其中 3G/4G 基站總數(shù)為 575 萬個(gè)。但這些基站大多集中在城市區(qū)域，而在鄉(xiāng)村，高速公路甚至是隧道內(nèi)的信號(hào)覆蓋就遠(yuǎn)沒有城市那么全面。目前，針對(duì)高速公路和國(guó)道省道等區(qū)域的網(wǎng)絡(luò)覆蓋方案基本分為公網(wǎng)延伸和專網(wǎng)覆蓋方案。
● 公網(wǎng)延伸：將路線區(qū)域與周邊區(qū)域統(tǒng)一規(guī)劃，使用常規(guī)基站蜂窩組網(wǎng)方式進(jìn)行覆蓋。由于往往是直接將大網(wǎng)的網(wǎng)絡(luò)資源延伸到高速公路上，所以也叫大網(wǎng)延伸覆蓋。
公網(wǎng)基站覆蓋示意圖
● 專網(wǎng)覆蓋：針對(duì)特殊的點(diǎn)覆蓋和線覆蓋場(chǎng)景的特殊要求進(jìn)行優(yōu)化，配置特殊的頻率、信令和功能進(jìn)行異頻組網(wǎng)。由于建設(shè)成本高，往往更多用于高速鐵路沿線覆蓋。專網(wǎng)與公網(wǎng)之間完全隔離，只有在特定出入口例如高速公路收費(fèi)站才能進(jìn)入或離開專網(wǎng)。
專網(wǎng)延伸覆蓋示意圖
可以發(fā)現(xiàn)，我們使用的網(wǎng)絡(luò)是依靠通信從業(yè)者建設(shè)的一個(gè)個(gè)蜂窩基站提供的。而車輛在快速移動(dòng)的過程中，位置更新頻繁，經(jīng)常會(huì)在多個(gè)基站覆蓋范圍之間切換。這導(dǎo)致其網(wǎng)絡(luò)信令負(fù)荷大，基站切換頻繁，最終將導(dǎo)致車載 4G 模塊的網(wǎng)絡(luò)鏈路中斷。
雖然專網(wǎng)覆蓋可以通過采用 BBU+RRU 小區(qū)合并的技術(shù)來減少網(wǎng)際切換和同頻干擾，進(jìn)而解決這一問題，但由于專網(wǎng)方案建設(shè)成本高昂，所以實(shí)際場(chǎng)景里，車聯(lián)網(wǎng)更多面對(duì)的還是第一種公網(wǎng)覆蓋方案。
從運(yùn)營(yíng)商提供的管理系統(tǒng)里查看 4G 連接的情況
于是，我們就會(huì)發(fā)現(xiàn)車機(jī)端的 4G 連接出現(xiàn)如上圖所示的不斷上下線的情況。
多普勒效應(yīng)和隧道覆蓋
除了基站覆蓋帶來的網(wǎng)絡(luò)問題外，當(dāng)車輛行駛速度很快的時(shí)候，也會(huì)由于多普勒效應(yīng)造成延遲增加和丟包。車速越大，頻偏越大，延遲越大，丟包的概率也越大。
多普勒效應(yīng)示意圖
MQTT 連接發(fā)生了什么？
我們知道了車輛的網(wǎng)絡(luò)情況，那么這些因素是如何影響車機(jī)端 MQTT 連接的呢？
眾所周知，MQTT 連接也是基于 TCP/IP 協(xié)議棧?？吹竭@里大家可能會(huì)有疑問：TCP/IP 協(xié)議棧里有連接?；顧C(jī)制，MQTT 協(xié)議里也有 Keep Alive 參數(shù)供連接重建恢復(fù)，哪怕基站切換導(dǎo)致了短暫的通信中斷，但是等到進(jìn)入下一個(gè)基站的范圍，通信鏈路也很快就恢復(fù)了，那么為什么還會(huì)導(dǎo)致車輛設(shè)備 MQTT 連接的頻繁離線呢？要回答這個(gè)疑問，我們需要結(jié)合 TCP/IP 和移動(dòng)網(wǎng)絡(luò)入網(wǎng)過程一起來分析。
TCP/IP 協(xié)議握手過程
TCP/IP 協(xié)議誕生之初，主要針對(duì)的是穩(wěn)定的有線網(wǎng)絡(luò)，作為一個(gè)可靠傳輸協(xié)議，其內(nèi)部有數(shù)據(jù) ACK，能夠進(jìn)行數(shù)據(jù)重傳和連接復(fù)用。但是，這一切都是基于 IP 地址不變的前提下，而在車聯(lián)網(wǎng)場(chǎng)景里，基站切換是會(huì)導(dǎo)致車機(jī)端的 IP 地址變更的。每次車機(jī) 4G 模塊進(jìn)入新的基站覆蓋范圍時(shí)都會(huì)重新發(fā)起一次入網(wǎng)附著請(qǐng)求。
網(wǎng)絡(luò)入網(wǎng)過程-UE 初始化附著到 UE-UTRAN 網(wǎng)絡(luò)的過程
其中的協(xié)議細(xì)節(jié)這里不進(jìn)行詳細(xì)解釋。由于目前我們?nèi)匀辉谑褂?IPV4 標(biāo)準(zhǔn)，所以車機(jī) 4G 模塊在重新入網(wǎng)過程中會(huì)向新搜尋到的 eNB 基站發(fā)送一個(gè)關(guān)鍵的信令 PDN（Packet Domain Network）來請(qǐng)求為自己分配一個(gè)新的 IP 地址，而這個(gè)地址往往都是 NAT 地址，這也是 4G 終端開機(jī)即在線的技術(shù)的一環(huán)。此時(shí)還伴隨著網(wǎng)絡(luò)質(zhì)量檢測(cè)、APN 匹配等流程來判斷終端使用的網(wǎng)絡(luò)類型和推送網(wǎng)絡(luò)路由以保證連通性。如果此時(shí)的邊緣 eNB 基站沒有針對(duì)車機(jī)端的 4G 卡和 PDN 信令進(jìn)行對(duì)應(yīng)優(yōu)化，是無法獲知其原先使用的 IP 地址的，那么這時(shí)候 IP 地址就發(fā)生了改變，需要進(jìn)行 NAT 地址重綁定。
而對(duì)于 MQTT 和 TCP/IP 這一類長(zhǎng)鏈接協(xié)議來說，IP 地址變化后，TCP 服務(wù)端無法識(shí)別出現(xiàn)在的客戶端是否還是原先的客戶端，所以 TCP 連接是必須要重新建立的，從而導(dǎo)致 MQTT 連接也必須重建。
TCP 連接和 MQTT 連接的關(guān)系
以上是一個(gè)正常的快速移動(dòng)的車輛在蜂窩基站間正常切換會(huì)發(fā)生的過程。而實(shí)際情況中網(wǎng)絡(luò)更加復(fù)雜，公網(wǎng)覆蓋方案由于共享基站和接入網(wǎng)資源，若邊緣基站負(fù)載過高還會(huì)發(fā)生 eNB 基站對(duì) PDN 請(qǐng)求不響應(yīng)等情況。網(wǎng)絡(luò)側(cè)對(duì)承載請(qǐng)求不響應(yīng)，更不用說偽基站。此外地理環(huán)境和多普勒效應(yīng)引起的多徑效應(yīng)和信號(hào)衰減都會(huì)導(dǎo)致延時(shí)增加和連接中斷。
如何改善移動(dòng)網(wǎng)絡(luò)下 MQTT 連接穩(wěn)定性
清楚了問題的根源，接下來我們將借助 MQTT 協(xié)議的特性來解決上述問題，構(gòu)建更穩(wěn)定的車聯(lián)網(wǎng)通信架構(gòu)，避免因?yàn)檫B接重連和中斷造成的數(shù)據(jù)丟失。
雖然 TCP/IP 部分無法改變，但 MQTT 協(xié)議提供了許多供配置的參數(shù)和消息 QoS 等級(jí)供我們配置。針對(duì)一些關(guān)鍵數(shù)據(jù)，比如車機(jī)端重要的狀態(tài)變化和用戶發(fā)出的請(qǐng)求，我們需要保證消息到達(dá)，這就需要我們使用 QoS 1/2。
Clean Session
首先，我們要解決 IP 更新導(dǎo)致 TCP 重連后客戶端無法識(shí)別的問題。我們可以通過 MQTT 會(huì)話保持特性來解決。
*關(guān)于 MQTT 會(huì)話狀態(tài)可參考文章：
https://www.emqx.com/zh/blog/mqtt-session
MQTT 要求客戶端與服務(wù)端在會(huì)話有效期內(nèi)存儲(chǔ)一系列與客戶端標(biāo)識(shí)（ClientID）相關(guān)聯(lián)的狀態(tài)，即會(huì)話狀態(tài)。我們將從客戶端向服務(wù)端發(fā)起 MQTT 連接請(qǐng)求開始，到連接中斷直到會(huì)話過期為止的消息收發(fā)序列稱為會(huì)話。
會(huì)話可能僅持續(xù)一個(gè)網(wǎng)絡(luò)連接，也可能跨越多個(gè)網(wǎng)絡(luò)連接存在。所以在這種網(wǎng)絡(luò)切換的過程中，車機(jī)端每次連接使用相同的客戶端標(biāo)識(shí)，就可以讓 MQTT Broker 在TCP連接重建的情況下，仍然可以識(shí)別到新連接是之前的客戶端，從而將緩存的 QoS 消息重發(fā)，并應(yīng)用之前的連接狀態(tài)。
客戶端使用會(huì)話保持的方式以 Java 為例：
MQTT 5.0
基于這種網(wǎng)絡(luò)連接頻繁斷開重連的情況，為了避免應(yīng)用層頻繁收到上下線事件，影響業(yè)務(wù)進(jìn)行。MQTT 5.0 也對(duì)協(xié)議進(jìn)行了響應(yīng)的優(yōu)化：
Will Delay Interval（延時(shí)遺愿消息發(fā)布）：我們經(jīng)常使用遺愿消息對(duì)客戶端的下線進(jìn)行追蹤和告知。在這種情況下回頻繁的收到遺愿消息。所以遺囑時(shí)間間隔的一個(gè)重要用途就是避免在頻繁的網(wǎng)絡(luò)連接臨時(shí)斷開時(shí)發(fā)布遺囑消息，因?yàn)榭蛻舳送鶗?huì)很快重新連上網(wǎng)絡(luò)并繼續(xù)之前的會(huì)話。
Session Expiry Interval（會(huì)話過期間隔）：MQTT 3.1.1 未對(duì)會(huì)話保持時(shí)間做明確規(guī)定。如果使用 sesseion 保持功能的客戶端大量頻繁上下線會(huì)造成 Broker 內(nèi)存使用增加，最終影響服務(wù)高可用。所以 MQTT 5.0 也針對(duì)這種情況設(shè)計(jì)了會(huì)話過期時(shí)間?？蛻舳丝梢栽谶B接時(shí)使用這一特性設(shè)置自己的會(huì)話保持時(shí)間。
QoS 1/2
設(shè)置完會(huì)話保留狀態(tài)，我們就可以使用 QoS 消息來保證消息的到達(dá)。
*關(guān)于 QoS 的詳解可參考文章：
https://www.emqx.com/zh/blog/introduction-to-mqtt-qos
我們建議對(duì)于重要數(shù)據(jù)在車機(jī)端使用 QoS 1 進(jìn)行發(fā)送，并且使用帶有 QoS 重傳功能和內(nèi)置 QoS 消息窗口（隊(duì)列）的 MQTT SDK。例如 NanoSDK（https://www.emqx.com/zh/mqtt-client-sdk），其具有異步確認(rèn)、內(nèi)置 QoS 消息隊(duì)列、自動(dòng)重發(fā)、高吞吐高消費(fèi)能力等特點(diǎn)。
Broker QoS MsgQueue
QoS 消息在 Broker 端有內(nèi)存持久化功能，除了客戶端有內(nèi)置的消息隊(duì)列，Broker 也有一個(gè) QoS 消息隊(duì)列。
如上文所述，車聯(lián)網(wǎng)場(chǎng)景經(jīng)常發(fā)生的基站切換導(dǎo)致連接重置，反映到 MQTT 連接就體現(xiàn)為 QoS 消息積壓現(xiàn)象?？蛻舳撕头?wù)端都會(huì)有未確認(rèn)的消息積壓在隊(duì)列里。所以我們要根據(jù)實(shí)際情況設(shè)置消息隊(duì)列的長(zhǎng)度。
以 EMQX 為例，消息隊(duì)列設(shè)置：
打開 emqx.conf
max_awaiting_rel 為接受 QoS 2 的消息隊(duì)列長(zhǎng)度。QoS 1 此項(xiàng)無限制。
await_rel_timeout 為 QoS 2 消息超時(shí)時(shí)間。
max_mqueue_len 為下發(fā) QoS 1/2 的隊(duì)列緩存長(zhǎng)度
默認(rèn)的 QoS 2 消息隊(duì)列長(zhǎng)度僅為 100，此處建議根據(jù)給客戶端發(fā)布消息的頻率和消費(fèi)能力適當(dāng)增加，一般考慮為 publisher 平均每秒產(chǎn)生消息的數(shù)量 *2 。此隊(duì)列提供消費(fèi)端一定的緩沖時(shí)間來完成重連后積壓消息的消費(fèi)。
更優(yōu)的解決方案：MQTT over QUIC
由于 TCP 采用四元組來判斷識(shí)別連接的獨(dú)特性，而 UDP 并沒有同樣的要求。2022 年 6 月 11 日，IETF 正式頒布了 HTTP/3 RFC 技術(shù)標(biāo)準(zhǔn)文檔后，基于 UDP 的 QUIC 正式成為了傳輸層標(biāo)準(zhǔn)之一。而基于 QUIC 的 MQTT 方案也有望成為下一個(gè)行業(yè)標(biāo)準(zhǔn)。
借助 QUIC 協(xié)議的地址遷移、流式多路復(fù)用、分路流控、更低的連接建立延遲，我們有望徹底解決車聯(lián)網(wǎng)移動(dòng)場(chǎng)景下的連接問題。
‘’
0-RTT 示意圖
QUIC 能夠偵測(cè)到地址改變，自動(dòng)采用 0-RTT 的方式重建連接，從而使得客戶端和服務(wù)端對(duì)于 IP 地址的變動(dòng)無感知，這樣就徹底避免了上文所說的一系列問題。
結(jié)語
本文分析了車聯(lián)網(wǎng)移動(dòng)場(chǎng)景中 MQTT 通信不穩(wěn)定現(xiàn)象的成因，并通過客戶端和服務(wù)端對(duì)會(huì)話保持、QoS、客戶端 ID 的配置和內(nèi)置消息隊(duì)列緩存等 MQTT 協(xié)議特性，在一定程度上解決了高速移動(dòng)帶來的連接不穩(wěn)定導(dǎo)致的數(shù)據(jù)丟失問題。
此外，如前文提到，相比之下 MQTT over QUIC 可能是一種更優(yōu)的解決方案。目前最新發(fā)布的 EMQX 5.0 已支持 MQTT over QUIC 并設(shè)計(jì)了獨(dú)特的消息傳輸機(jī)制和管理方式，實(shí)現(xiàn)了有效降低數(shù)據(jù)丟包率，減少握手延遲。車聯(lián)網(wǎng)用戶可以使用 EMQX 5.0 獲得更加高效、低延遲的物聯(lián)網(wǎng)數(shù)據(jù)傳輸體驗(yàn)。隨著 EMQ 在 MQTT over QUIC 標(biāo)準(zhǔn)化進(jìn)程的積極推進(jìn)，相信未來車聯(lián)網(wǎng)及其他更多物聯(lián)網(wǎng)行業(yè)的弱網(wǎng)與不固定網(wǎng)絡(luò)通路場(chǎng)景下的消息傳輸問題都將得到進(jìn)一步改善。
本文作者
余杰霖，曾于聯(lián)合國(guó) ESCAP 負(fù)責(zé) GIS 數(shù)據(jù)分析工作，現(xiàn)負(fù)責(zé) EMQ 邊緣計(jì)算，NanoMQ 開源項(xiàng)目發(fā)起人。
文章來源： IoT物聯(lián)網(wǎng)技術(shù)
在線咨詢
在線咨詢
0371-63319761