趙 靖，王如武，周 皓

大連理工大學(xué) 軟件學(xué)院，遼寧 大連 116024

隨著“工業(yè)互聯(lián)網(wǎng)”“工業(yè)4.0““中國(guó)制造2025”等戰(zhàn)略的提出，制造業(yè)數(shù)字化轉(zhuǎn)型已成為共識(shí)。打破不同工業(yè)系統(tǒng)間的信息壁壘，改善傳統(tǒng)工業(yè)企業(yè)的“信息孤島”現(xiàn)象，整合海量數(shù)據(jù)，挖掘更大的信息價(jià)值，優(yōu)化流程，提升效率，賦能工業(yè)生產(chǎn)、管理、運(yùn)營(yíng)、銷(xiāo)售、售后等整條生態(tài)鏈，是數(shù)字化轉(zhuǎn)型的目標(biāo)和作用。工業(yè)制造往往涉及的產(chǎn)品類(lèi)型眾多，工業(yè)系統(tǒng)之間千差萬(wàn)別，而且工業(yè)現(xiàn)場(chǎng)環(huán)境復(fù)雜，網(wǎng)絡(luò)不穩(wěn)定。盡管在降低時(shí)延方面，可以采用目前比較流行的邊緣計(jì)算解決方案，在工廠內(nèi)部或附近放置大量邊緣云設(shè)備以減少延遲，但大量的專(zhuān)有傳感器及邊緣設(shè)備的信息交互也會(huì)增加通信成本，加大工業(yè)用電量，增加成本和運(yùn)營(yíng)費(fèi)用。因此通訊協(xié)議的選取至關(guān)重要，而在物聯(lián)網(wǎng)領(lǐng)域廣泛流行的消息隊(duì)列遙測(cè)傳輸（Message Queuing Telemetry Transport，MQTT）[1]協(xié)議就因?yàn)槠湎Ⅲw積小，通訊成本低，能量消耗少，適合在結(jié)構(gòu)各異的系統(tǒng)間進(jìn)行消息傳遞而備受關(guān)注。其獨(dú)特的發(fā)布/訂閱體系結(jié)構(gòu)，使不同客戶(hù)端之間的通信脫鉤，從而允許不同的供應(yīng)商在不同的系統(tǒng)中獨(dú)立實(shí)現(xiàn)MQTT，擺脫原始系統(tǒng)本身的專(zhuān)有協(xié)議進(jìn)行通信，從而在不同的專(zhuān)有系統(tǒng)中建立互操作性，非常適合作為工業(yè)生產(chǎn)中多種異構(gòu)系統(tǒng)與部件間消息傳遞的標(biāo)準(zhǔn)，在智能制造中的應(yīng)用越來(lái)越受歡迎。國(guó)內(nèi)外的工業(yè)互聯(lián)網(wǎng)平臺(tái)，如華為FusionPlant平臺(tái)、西門(mén)子mindsphere平臺(tái)、海爾COSMOPlat平臺(tái)等的解決方案中都采用了MQTT作為通訊協(xié)議，因此在傳統(tǒng)工業(yè)企業(yè)中通過(guò)部署MQTT進(jìn)行大量設(shè)備間的消息傳遞已經(jīng)逐漸成為一種普遍的選擇。

而在MQTT部署方案的制定中以及實(shí)際部署前，若先通過(guò)仿真模擬技術(shù)獲取關(guān)鍵數(shù)據(jù)以供參考，并且快速得到直觀的部署效果從而及時(shí)修正，則可以大大減小方案落地后的偏差，降低試錯(cuò)成本。這得益于仿真的簡(jiǎn)便靈活，可以快速獲取所需數(shù)據(jù)（如網(wǎng)絡(luò)設(shè)備吞吐量、網(wǎng)絡(luò)帶寬、時(shí)延等），而且成本極低，這對(duì)于工業(yè)企業(yè)來(lái)說(shuō)是至關(guān)重要的。如果初期就通過(guò)實(shí)際部署進(jìn)行評(píng)估測(cè)試會(huì)造成大量人力物力財(cái)力的浪費(fèi)。

模擬部署MQTT是觀察及研究其性能和表現(xiàn)的重要手段。目前在該方面主要分為小規(guī)模本地部署和仿真軟件模擬兩種方式。文獻(xiàn)[3]中通過(guò)在兩臺(tái)機(jī)器上分別搭建單獨(dú)的MQTT客戶(hù)端和服務(wù)端進(jìn)行了小規(guī)模的模擬實(shí)驗(yàn)，對(duì)比了MQTT和CoAP兩種協(xié)議的端到端時(shí)延和帶寬消耗情況，結(jié)果表明協(xié)議的性能取決于網(wǎng)絡(luò)條件，在較低丟包率時(shí)MQTT會(huì)具有更低的延遲，但是該實(shí)驗(yàn)只設(shè)置了一個(gè)客戶(hù)端，對(duì)于大量客戶(hù)端的情況無(wú)法進(jìn)行準(zhǔn)確評(píng)估。文獻(xiàn)[4]利用OPNET仿真器進(jìn)行無(wú)線(xiàn)樓宇網(wǎng)絡(luò)中MQTT的仿真以獲取最佳部署節(jié)點(diǎn)數(shù)，然后在實(shí)際系統(tǒng)中部署進(jìn)行下一步測(cè)試。雖然其能夠較好地模擬MQTT，但是OPNET并不是免費(fèi)的軟件，主要面向商業(yè)用戶(hù)，價(jià)格昂貴。文獻(xiàn)[5]中使用OMNet++仿真器的INET框架評(píng)估了MQTT協(xié)議在工業(yè)環(huán)境下的性能，觀察了在不同傳感器數(shù)量下該協(xié)議的吞吐量和時(shí)延變化。但是文獻(xiàn)[6-7]中的對(duì)比結(jié)果都表明，相比于OMNet++等其他模擬器，NS-3模擬器都有著更好的整體性能，比如需要更少的計(jì)算時(shí)間及更低的內(nèi)存，同時(shí)NS-3是開(kāi)源免費(fèi)的，它擁有更加活躍的社區(qū)對(duì)其進(jìn)行維護(hù)，每三到四個(gè)月定期發(fā)布具有新功能的版本[8]。另外，利用文獻(xiàn)[9]提供的ns3-ai擴(kuò)展模塊還可以開(kāi)展計(jì)算機(jī)網(wǎng)絡(luò)和人工智能算法相結(jié)合的交叉研究，這些優(yōu)勢(shì)都促使更多的人愿意使用NS-3，并積極地完善和擴(kuò)展它以便進(jìn)行更廣泛的研究。

本文針對(duì)NS-3中無(wú)法對(duì)MQTT協(xié)議提供簡(jiǎn)單易用的模塊和接口支持問(wèn)題，提出并實(shí)現(xiàn)了一個(gè)名為ns3-mqtt的框架來(lái)對(duì)NS-3進(jìn)行擴(kuò)展，詳細(xì)描述了該框架的設(shè)計(jì)策略和實(shí)現(xiàn)細(xì)節(jié)，包括它的三個(gè)擴(kuò)展組件（MQTT核心模塊、MQTT應(yīng)用程序、MQTT幫助程序），同時(shí)提供了一個(gè)工業(yè)場(chǎng)景仿真案例來(lái)說(shuō)明集成后的NS-3如何模擬部署MQTT以獲取必要數(shù)據(jù)，進(jìn)而為實(shí)際部署MQTT提供有力的幫助。另外，還對(duì)數(shù)據(jù)包大小和客戶(hù)端數(shù)量對(duì)MQTT協(xié)議性能的影響進(jìn)行了研究，觀察到了和OMNet++仿真器中相似的現(xiàn)象，證明了ns3-mqtt框架的可行性。

1 相關(guān)概念

1.1 NS-3網(wǎng)絡(luò)模擬器

NS-3網(wǎng)絡(luò)模擬器是一個(gè)開(kāi)源的離散事件驅(qū)動(dòng)的網(wǎng)絡(luò)模擬器，主要用于研究和教育目的[10]。它可以在一臺(tái)計(jì)算機(jī)上用C++和Python編寫(xiě)腳本來(lái)模擬現(xiàn)實(shí)世界的網(wǎng)絡(luò)[11]。在一個(gè)網(wǎng)絡(luò)系統(tǒng)的仿真中，每一個(gè)實(shí)體都會(huì)由一個(gè)稱(chēng)為節(jié)點(diǎn)的容器表示。網(wǎng)絡(luò)設(shè)備、協(xié)議、應(yīng)用程序都會(huì)依次安裝到這個(gè)容器中。NS-3提供了多種網(wǎng)絡(luò)協(xié)議（802.11、TCP、UDP等）及通訊技術(shù)（WIFI、LTE、5G等），作為一個(gè)開(kāi)源項(xiàng)目，它完全由C++語(yǔ)言編寫(xiě)，主要運(yùn)行于linux平臺(tái)，任何組織和個(gè)人可對(duì)源碼進(jìn)行下載及修改，由NS-3社區(qū)維護(hù)。另外，它還可以與外部系統(tǒng)和實(shí)際應(yīng)用進(jìn)行交互，提供了與其他平臺(tái)進(jìn)行聯(lián)合仿真并獲取更真實(shí)數(shù)據(jù)的可能性。

1.2 MQTT協(xié)議

MQTT協(xié)議是一種使用發(fā)布/訂閱機(jī)制的消息傳遞協(xié)議，最初由Andy等設(shè)計(jì)[12]，適用于資源受限設(shè)備以及低帶寬、高延遲或不可靠的網(wǎng)絡(luò)[13]。該協(xié)議位于OSI網(wǎng)絡(luò)模型中的應(yīng)用層，依賴(lài)于傳輸層的TCP協(xié)議以及網(wǎng)絡(luò)層的IP協(xié)議，支持TLS/SSL加密。它獨(dú)特的消息傳遞機(jī)制以及低帶寬占用、可靠的特性，使其非常適合工業(yè)領(lǐng)域云邊通信[14]的應(yīng)用場(chǎng)景，在有限帶寬的情況下也可為大量傳感器等設(shè)備的連接提供實(shí)時(shí)可靠的消息服務(wù)。該協(xié)議基于一個(gè)稱(chēng)為broker的中心服務(wù)器來(lái)實(shí)現(xiàn)對(duì)所有消息的代理，形成發(fā)布訂閱模式，其客戶(hù)端只能夠和中心服務(wù)器直接交互，而且消息的傳遞是基于主題的，客戶(hù)端可向某一主題發(fā)布訂閱請(qǐng)求或發(fā)布請(qǐng)求，中心服務(wù)器一旦接收到消息請(qǐng)求，就會(huì)根據(jù)消息主題在該主題的訂閱列表下增加該客戶(hù)端以滿(mǎn)足訂閱請(qǐng)求，或者分發(fā)消息內(nèi)容給已訂閱該主題的其他客戶(hù)端以滿(mǎn)足發(fā)布請(qǐng)求，可實(shí)現(xiàn)訂閱方和發(fā)布方之間的解耦。

1.2.1 MQTT協(xié)議的消息格式

MQTT消息由2個(gè)字節(jié)的固定報(bào)頭，2個(gè)字節(jié)的可變報(bào)頭以及有效載荷三部分組成，固定報(bào)頭的格式規(guī)范如圖1所示。其中Retain字段用于設(shè)置該條消息是否需要服務(wù)端保留；Qos Level字段用于設(shè)置該條消息所需的服務(wù)等級(jí)；Dup Flag字段用于設(shè)置該條消息是否為重發(fā)消息；Message Type字段的值代表消息的類(lèi)型（共有14種）；Remaining Length字段的值則代表消息的可變報(bào)頭和有效載荷大小。

圖1 MQTT固定報(bào)頭格式Fig.1 MQTT fixed header format

可變報(bào)頭是否存在由消息類(lèi)型（Message Type）決定，當(dāng)消息類(lèi)型為PUBLISH（Qos＞0）、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK類(lèi)型時(shí)可變報(bào)頭存儲(chǔ)的是報(bào)文標(biāo)識(shí)（MessageID），長(zhǎng)度為2個(gè)字節(jié)，其他類(lèi)型時(shí)可不添加可變報(bào)頭。而有效載荷則承載了MQTT消息攜帶的實(shí)際數(shù)據(jù)，包括主題和內(nèi)容。

1.2.2 MQTT協(xié)議的主題

MQTT協(xié)議的主題Topic起到過(guò)濾消息的作用，同時(shí)也是消息的一種標(biāo)識(shí)，從而對(duì)消息進(jìn)行分組?？蛻?hù)端只會(huì)收到其感興趣的分組的內(nèi)容。它是一個(gè)分層結(jié)構(gòu)，在表示上類(lèi)似restful風(fēng)格。一個(gè)主題名可以由多個(gè)主題層級(jí)組成，每一層通過(guò)“/”斜杠分隔開(kāi)，例如：“/layer1/layer2/layer3“。如果客戶(hù)端對(duì)多個(gè)相似分組感興趣，則可以在主題的某個(gè)層級(jí)使用通配符，包括“+”和“#”兩種?！?”通配符屬于單層通配符，只匹配某一個(gè)層級(jí)的全部?jī)?nèi)容，例如“/layer1/+”可匹配“/layer1/layer2a”和“/layer1/layer2b”。而“#”屬于多層通配符，可匹配包括當(dāng)前層級(jí)在內(nèi)的后面的全部層級(jí)的子主題。需要注意的是“#”通配符也可代表0個(gè)層次，比如“/layer1/#”也能匹配單一的“/layer1”，此時(shí)“#”就代表0個(gè)層級(jí)。同時(shí)它在一個(gè)主題只能出現(xiàn)一次，且需在主題層級(jí)的末尾處，不可以出現(xiàn)在主題的中間和首部，也不可以在多個(gè)層級(jí)中同時(shí)出現(xiàn)。

1.2.3 MQTT協(xié)議的消息服務(wù)質(zhì)量

MQTT協(xié)議通過(guò)控制Qos等級(jí)來(lái)決定服務(wù)質(zhì)量[15]，其Qos等級(jí)共有三個(gè)，分別是Qos0、Qos1、Qos2。不同的等級(jí)代表了不同的可靠性要求，具體描述如下。

（1）消息服務(wù)等級(jí)為Qos0時(shí)，代表著消息到達(dá)至多一次，由于消息發(fā)布是完全依賴(lài)于底層的TCP/IP協(xié)議的，因此會(huì)有消息丟失或重復(fù)的情況發(fā)生。這一等級(jí)的服務(wù)適用于偶爾丟失一次記錄無(wú)影響的場(chǎng)景下，比如監(jiān)測(cè)環(huán)境溫度信息，它會(huì)在不久以后繼續(xù)接收下一次消息。

（2）消息服務(wù)等級(jí)為Qos1時(shí)，代表著消息至少到達(dá)一次，但是可能會(huì)有消息重復(fù)現(xiàn)象發(fā)生。

（3）消息服務(wù)等級(jí)為Qos2時(shí)，代表著消息一定會(huì)到達(dá)且只到達(dá)一次。這一等級(jí)適用于對(duì)消息重復(fù)或者丟失比較敏感的場(chǎng)景。

2 ns3-mqtt框架描述

ns3-mqtt框架由MQTT核心模塊、MQTT應(yīng)用程序、MQTT幫助程序三個(gè)部分組成。MQTT核心模塊主要實(shí)現(xiàn)了協(xié)議頭、客戶(hù)端和代理服務(wù)端。代理服務(wù)端可對(duì)消息進(jìn)行存儲(chǔ)和轉(zhuǎn)發(fā)、客戶(hù)端可訂閱和發(fā)布消息，二者均支持Qos0、Qos1、Qos2三種服務(wù)等級(jí)?？紤]到未來(lái)對(duì)保留消息功能的潛在需求，例如測(cè)試新訂閱客戶(hù)端獲取歷史消息的性能等，還實(shí)現(xiàn)了對(duì)Retain類(lèi)型消息的支持。而MQTT應(yīng)用程序部分則是在MQTT核心模塊基礎(chǔ)上開(kāi)發(fā)，分為mqtt-client和mqtt-broker兩個(gè)應(yīng)用程序，能夠定時(shí)開(kāi)啟和關(guān)閉客戶(hù)端以及服務(wù)端，并進(jìn)行端到端的數(shù)據(jù)統(tǒng)計(jì)。同時(shí)能夠通過(guò)設(shè)置客戶(hù)端發(fā)包大小、間隔、Qos等進(jìn)行流量生成。另外還編寫(xiě)了ns3：：mqttbroker-helper和ns3：：mqtt-client-helper類(lèi)作為幫助程序，該部分的目的是提供便捷的高度封裝的接口，并可以批量安裝MQTT應(yīng)用程序以及靈活設(shè)置流量生成參數(shù)，為安裝和使用MQTT應(yīng)用程序提供方便。圖2展示了ns3-mqtt框架的結(jié)構(gòu)以及和NS-3自身模塊間的關(guān)系。

圖2 ns3-mqtt框架結(jié)構(gòu)Fig.2 ns3-mqtt frame structure

2.1 MQTT核心模塊

該模塊參考MQTT-V3.1.1[1]協(xié)議規(guī)范對(duì)MQTT協(xié)議主要功能進(jìn)行了實(shí)現(xiàn)。模塊結(jié)構(gòu)遵循NS-3項(xiàng)目風(fēng)格。圖3顯示了模塊中所有類(lèi)之間的關(guān)系。其中ns3：：Mqtt-Header類(lèi)是基于ns3：：Header類(lèi)的擴(kuò)展，ns3：：util類(lèi)則是用于對(duì)MQTT頭部數(shù)據(jù)的存取操作進(jìn)行簡(jiǎn)化。同時(shí)，服務(wù)端和客戶(hù)端由ns3：：broker類(lèi)和ns3：：client類(lèi)實(shí)現(xiàn)，二者采用packet對(duì)象作為信息載體，利用TCP/IP協(xié)議提供的可編程接口socket[16]實(shí)現(xiàn)通訊，其中服務(wù)端類(lèi)還要依賴(lài)ns3：：mqtt_db類(lèi)進(jìn)行數(shù)據(jù)管理。以下各節(jié)將對(duì)實(shí)現(xiàn)細(xì)節(jié)進(jìn)行詳細(xì)解釋。

圖3 MQTT核心模塊類(lèi)關(guān)系圖Fig.3 MQTT core module class diagram

2.1.1 MQTT消息頭

MQTT協(xié)議消息頭由名為MqttHeader的類(lèi)表示。根據(jù)NS-3官方文檔所述，該類(lèi)必須從ns3：：Header類(lèi)派生，并實(shí)現(xiàn)ns3：：Header類(lèi)的純虛方法。派生出的ns3：：MqttHeader類(lèi)需實(shí)現(xiàn)MQTT協(xié)議頭部的序列化和反序列化，而序列化或反序列化中每次操作的字節(jié)數(shù)則需根據(jù)協(xié)議本身進(jìn)行設(shè)置。為方便數(shù)據(jù)統(tǒng)計(jì)和重發(fā)數(shù)據(jù)包的辨別，將MQTT的可變頭部統(tǒng)一設(shè)置為2個(gè)字節(jié)。因此MQTT協(xié)議報(bào)文頭固定為4個(gè)字節(jié)。相對(duì)應(yīng)的ns3：：MqttHeader類(lèi)里序列化和反序列化函數(shù)中每次操作的大小也為4個(gè)字節(jié)。需要注意的是，序列化和反序列化過(guò)程會(huì)調(diào)用Buffer函數(shù)對(duì)緩沖區(qū)進(jìn)行寫(xiě)入和讀出，二者的調(diào)用順序不能顛倒，否則會(huì)造成緩沖區(qū)數(shù)據(jù)異常。另外，在ns3：：packet中添加MQTT消息頭需調(diào)用其中的AddHeader函數(shù)。由于ns3：：MqttHeader中數(shù)值以二進(jìn)制形式存儲(chǔ)，因此需通過(guò)位運(yùn)算將協(xié)議頭部各字段值寫(xiě)入。而接收方獲取數(shù)據(jù)包后則需利用ns3：：packet中提供的PeekHeader函數(shù)，將數(shù)據(jù)先取出到ns3：：MqttHeader對(duì)象中，然后調(diào)用該對(duì)象中GetData函數(shù)才能獲取到數(shù)據(jù)。此數(shù)據(jù)為32位（4個(gè)字節(jié)）的二進(jìn)制數(shù)，最后還需通過(guò)特定的位運(yùn)算才能獲取協(xié)議報(bào)文各字段的值，比如Message Type，Qos等。表1列出了協(xié)議頭部二進(jìn)制數(shù)據(jù)的寫(xiě)入和讀出涉及的位運(yùn)算公式。其中d表示當(dāng)前頭部的值。為了方便在程序中使用，已在輔助類(lèi)中將其封裝成函數(shù)，提供了對(duì)應(yīng)接口。

表1 字段計(jì)算公式表Table 1 Field calculation formula table

2.1.2 MQTT協(xié)議的客戶(hù)端

MQTT協(xié)議客戶(hù)端由ns3：：client類(lèi)實(shí)現(xiàn)，主要完成對(duì)消息的發(fā)送，三種Qos服務(wù)等級(jí)的交互響應(yīng)以及客戶(hù)端參數(shù)的設(shè)置。消息的發(fā)送采用socket實(shí)現(xiàn)，Qos等級(jí)的交互響應(yīng)采用回調(diào)函數(shù)和仿真調(diào)度器實(shí)現(xiàn)，具體的將在3.3.4小節(jié)進(jìn)行介紹。ns3：：client類(lèi)提供的可設(shè)置參數(shù)有訂閱的主題、發(fā)送消息的類(lèi)型和內(nèi)容、Qos服務(wù)等級(jí)以及是否為保留消息，該類(lèi)中默認(rèn)接收消息的監(jiān)聽(tīng)端口號(hào)設(shè)置為1883。由于該類(lèi)繼承自ns3：：Application類(lèi)，其可作為一種應(yīng)用程序在Node上運(yùn)行。但為了簡(jiǎn)化仿真的復(fù)雜性，還提供了進(jìn)一步封裝的客戶(hù)端應(yīng)用程序mqtt-client，能夠較為簡(jiǎn)便地對(duì)單一客戶(hù)端進(jìn)行參數(shù)設(shè)置，例如數(shù)據(jù)流量參數(shù)等。而mqtt-client-helper幫助程序則是提供對(duì)客戶(hù)端批量安裝以及參數(shù)批量設(shè)定的功能，以適應(yīng)更大規(guī)模的仿真，免去了仿真中需逐一安裝設(shè)定的麻煩。關(guān)于客戶(hù)端應(yīng)用程序和幫助程序會(huì)在3.2、3.3節(jié)進(jìn)行更詳細(xì)的介紹。

2.1.3 MQTT協(xié)議的服務(wù)端

MQTT服務(wù)端也稱(chēng)為broker，它由ns3：：mqtt_db，ns3：：broker類(lèi)實(shí)現(xiàn)。ns3：：mqtt_db類(lèi)負(fù)責(zé)存儲(chǔ)消息以及維護(hù)客戶(hù)端和消息之間的對(duì)應(yīng)關(guān)系，ns3：：broker類(lèi)則負(fù)責(zé)數(shù)據(jù)包的接收校驗(yàn)以及消息的轉(zhuǎn)發(fā)。并且ns3：：mqtt_db和ns3：：broker是一一對(duì)應(yīng)的，前者作為后者類(lèi)中的一個(gè)私有成員變量。

ns3：：mqtt_db中存儲(chǔ)消息采用的數(shù)據(jù)結(jié)構(gòu)是訂閱樹(shù)，它類(lèi)似于多叉樹(shù)。樹(shù)的節(jié)點(diǎn)由Subtree_node對(duì)象表示，該對(duì)象由兩個(gè)分別存儲(chǔ)子節(jié)點(diǎn)指針和客戶(hù)端指針的列表，以及代表該節(jié)點(diǎn)名稱(chēng)的字符串組成。其中客戶(hù)端可存儲(chǔ)在一個(gè)或多個(gè)樹(shù)節(jié)點(diǎn)下，代表該客戶(hù)端訂閱了由根節(jié)點(diǎn)的兒子節(jié)點(diǎn)到該節(jié)點(diǎn)途徑所有節(jié)點(diǎn)的名稱(chēng)構(gòu)成的主題，一個(gè)典型的訂閱樹(shù)如圖4所示，其中client2就訂閱了“/layer1/layer2a”和“/sys”兩個(gè)主題。ns3：：mqtt_db在接收到經(jīng)過(guò)ns3：：broker校驗(yàn)后的數(shù)據(jù)包時(shí)，首先會(huì)調(diào)用getPacketHeadType函數(shù)得到數(shù)據(jù)包包頭中的Message Type的值判斷消息類(lèi)型，若是PUBLISH型消息，則用字符分割函數(shù)將負(fù)載中主題和內(nèi)容分開(kāi)，利用find_topic_exits函數(shù)對(duì)訂閱樹(shù)進(jìn)行深度優(yōu)先遍歷，判斷該主題在訂閱樹(shù)中是否存在，若存在，將會(huì)立即調(diào)用pub_add_sub_client函數(shù)以及push_msg_to_client函數(shù)將消息存儲(chǔ)在訂閱了該主題的客戶(hù)端中，這里的客戶(hù)端是一個(gè)臨時(shí)的Client對(duì)象，僅用作存儲(chǔ)消息內(nèi)容和維護(hù)實(shí)際客戶(hù)端待接收的消息隊(duì)列，此時(shí)消息還未開(kāi)始向?qū)嶋H客戶(hù)端發(fā)送。若是SUBSCRIBE型消息，則先調(diào)用find_child函數(shù)在訂閱樹(shù)中查找匹配的節(jié)點(diǎn)，此函數(shù)采用遞歸查找并返回可匹配到的最后一個(gè)節(jié)點(diǎn)。若能完全匹配則調(diào)用sub_add_sub_client函數(shù)將此訂閱客戶(hù)端存儲(chǔ)到完全匹配的最后一個(gè)節(jié)點(diǎn)的客戶(hù)端隊(duì)列中，準(zhǔn)備接收消息。否則會(huì)先調(diào)用add_subtree_topic函數(shù)在訂閱樹(shù)中增加相應(yīng)節(jié)點(diǎn)以達(dá)到完全匹配。

圖4 訂閱樹(shù)示例Fig.4 Example of subscription tree

ns3：：broker類(lèi)對(duì)接收到的數(shù)據(jù)包的包頭和負(fù)載進(jìn)行校驗(yàn)時(shí)，先通過(guò)位運(yùn)算獲取其頭部各字段的值，若未出現(xiàn)非法值則校驗(yàn)后該消息交由mqtt_db處理，否則丟棄該數(shù)據(jù)包。當(dāng)消息經(jīng)mqtt_db處理后，ns3：：broker會(huì)對(duì)mqtt_db中訂閱樹(shù)進(jìn)行搜索。若發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)中Client的實(shí)際客戶(hù)端待接收消息隊(duì)列大小不為0，就根據(jù)Client的地址（和實(shí)際客戶(hù)端地址一一對(duì)應(yīng)）取出消息隊(duì)列中的每一條消息。取出后隨即創(chuàng)建新的socket，根據(jù)Client的地址以及監(jiān)聽(tīng)的端口號(hào)（1883）與對(duì)應(yīng)客戶(hù)端進(jìn)行連接并轉(zhuǎn)發(fā)對(duì)應(yīng)消息。該轉(zhuǎn)發(fā)功能同樣支持Qos的三個(gè)服務(wù)等級(jí)，但服務(wù)等級(jí)是由消息發(fā)布時(shí)的Qos等級(jí)和客戶(hù)端訂閱時(shí)的Qos等級(jí)共同確定，取二者的較小值。

2.1.4 MQTT協(xié)議的服務(wù)等級(jí)

MQTT協(xié)議的三種Qos服務(wù)等級(jí)功能的實(shí)現(xiàn)主要依靠回調(diào)函數(shù)和Simulator調(diào)度器，NS-3中的回調(diào)函數(shù)和C++中回調(diào)函數(shù)類(lèi)似，都需要訂閱函數(shù)指針、賦值以及調(diào)用三個(gè)步驟。不過(guò)NS-3中對(duì)回調(diào)函數(shù)的步驟進(jìn)行了簡(jiǎn)化，其使用步驟被封裝在了對(duì)應(yīng)的類(lèi)和函數(shù)中。函數(shù)指針在Callback類(lèi)模板中被定義，該模板可支持最多9個(gè)形參并可以定義函數(shù)簽名的返回值。而Callback對(duì)象的創(chuàng)建和賦值由函數(shù)MakeCallback完成。通過(guò)回調(diào)函數(shù)接收到消息時(shí)可以通過(guò)socket回復(fù)消息，但只能回復(fù)一次。接收者如果想要再次發(fā)送消息，只能構(gòu)造新的socket來(lái)發(fā)送，這種情況多出現(xiàn)在Qos2等級(jí)中，因?yàn)樾枰瓿蓛纱谓换?。Simulator調(diào)度器主要應(yīng)用在控制何時(shí)去發(fā)送回復(fù)消息，該調(diào)度器是NS-3離散事件仿真引擎的入口，控制著整個(gè)仿真事件的調(diào)度，保證仿真不混亂。

在實(shí)際實(shí)現(xiàn)中只需設(shè)置MQTT數(shù)據(jù)包包頭的Qos Level字段即可將Qos值跟隨消息一起發(fā)送。其中Qos0等級(jí)由于只發(fā)送一次，故不存在交互行為。當(dāng)服務(wù)等級(jí)為Qos1時(shí)，客戶(hù)端發(fā)送消息后會(huì)調(diào)用等待接收ack函數(shù)sendRecvAck來(lái)接收服務(wù)端發(fā)回的ack報(bào)文。同時(shí)此函數(shù)中設(shè)有等待時(shí)間，若在規(guī)定時(shí)間內(nèi)沒(méi)有收到ack則重傳消息。當(dāng)服務(wù)等級(jí)為Qos2時(shí)，客戶(hù)端發(fā)送消息后會(huì)調(diào)用sendRecvREC函數(shù)，等待接收PUBREC類(lèi)型消息，若在規(guī)定時(shí)間無(wú)回應(yīng)則重發(fā)該消息。若接收到PUBREC類(lèi)型消息則開(kāi)始進(jìn)行第二次交互，也就是調(diào)用sendREL函數(shù)發(fā)送PUBREL消息，之后調(diào)用sendRecvCOMP函數(shù)等待服務(wù)端PUBCOMP類(lèi)型的回應(yīng)消息，若一段時(shí)間內(nèi)收不到回應(yīng)同樣會(huì)重傳消息，若接收到則代表著兩次交互已完成。在交互的過(guò)程中服務(wù)端會(huì)一直啟用socket監(jiān)聽(tīng)，收到消息后立即調(diào)用回調(diào)函數(shù)對(duì)消息進(jìn)行解析和邏輯處理，由此來(lái)完成和客戶(hù)端的交互。而對(duì)于服務(wù)端轉(zhuǎn)發(fā)消息給客戶(hù)端的情況，同樣涉及Qos服務(wù)等級(jí)。這里Qos等級(jí)的確定方法和客戶(hù)端發(fā)送消息給服務(wù)端時(shí)相同，并且交互過(guò)程也相同，只是此時(shí)客戶(hù)端和服務(wù)端角色互換了。

2.1.5 MQTT協(xié)議的Retain功能

MQTT協(xié)議的Retain功能旨在讓新訂閱者及時(shí)得到發(fā)布方最新的消息或狀態(tài)信息。只要客戶(hù)端一訂閱帶保留消息的主題，就會(huì)立即獲得該主題下最新的保留消息。如果訂閱的主題帶有通配符，那么就會(huì)收到相匹配的每個(gè)主題下的保留消息。具體的設(shè)計(jì)思路為，對(duì)于服務(wù)端來(lái)說(shuō)每個(gè)主題僅會(huì)保留唯一一個(gè)Retain消息，存儲(chǔ)在該主題尾部對(duì)應(yīng)的訂閱樹(shù)節(jié)點(diǎn)的retainmsg成員變量中，新的Retain消息會(huì)不斷覆蓋之前的。如果想刪除某主題下的Retain消息，可以發(fā)布相同主題的，Retain字段為1并且內(nèi)容為“-”的消息來(lái)刪除。實(shí)際實(shí)現(xiàn)中，服務(wù)端收到消息后會(huì)先將其存儲(chǔ)在訂閱樹(shù)中匹配的節(jié)點(diǎn)里，在節(jié)點(diǎn)處理待發(fā)數(shù)據(jù)時(shí)，遇到保留消息會(huì)存儲(chǔ)到retainmsg中。節(jié)點(diǎn)數(shù)據(jù)發(fā)送完畢就會(huì)清空待發(fā)數(shù)據(jù)隊(duì)列。待新的訂閱者到來(lái)時(shí)，如果其訂閱的主題對(duì)應(yīng)的節(jié)點(diǎn)中retainmsg不為空，則將其中的保留消息發(fā)送給新的訂閱者（客戶(hù)端），使新訂閱者立即獲得該主題下最新的消息。

2.2 MQTT應(yīng)用程序

MQTT應(yīng)用程序主要包括客戶(hù)端應(yīng)用程序以及服務(wù)端應(yīng)用程序，分別由類(lèi)ns3：：MqttClient和類(lèi)ns3：：MqttBroker實(shí)現(xiàn)。客戶(hù)端應(yīng)用程序主要負(fù)責(zé)MQTT流量生成，可以設(shè)置的參數(shù)包括數(shù)據(jù)包大小、總數(shù)、發(fā)包間隔、發(fā)送速率、數(shù)據(jù)包中攜帶的主題和內(nèi)容、數(shù)據(jù)包中攜帶的消息是否為保留消息以及發(fā)送所需的服務(wù)質(zhì)量Qos（默認(rèn)為Qos0）。而服務(wù)端應(yīng)用程序可設(shè)置時(shí)間進(jìn)行定時(shí)打開(kāi)和關(guān)閉，在關(guān)閉后將調(diào)用Count函數(shù)進(jìn)行數(shù)據(jù)統(tǒng)計(jì)并將結(jié)果輸出到控制臺(tái)或指定文件中。為方便進(jìn)行延遲等數(shù)據(jù)的統(tǒng)計(jì)，在MQTT數(shù)據(jù)包中還添加了時(shí)間戳TimestampTag，但是NS-3中計(jì)算packet大小時(shí)會(huì)自動(dòng)忽略TimestampTag對(duì)象的大小。表2、表3分別列出了服務(wù)端和客戶(hù)端應(yīng)用程序的主要函數(shù)及說(shuō)明。

表2 服務(wù)端應(yīng)用程序函數(shù)列表Table 2 Server application function list

表3 客戶(hù)端應(yīng)用程序函數(shù)列表Table 3 Client application function list

2.3 MQTT幫助程序

MQTT幫助程序主要目的在于提供更加簡(jiǎn)便的高級(jí)接口，表4列出了這些高級(jí)接口。它們?yōu)楣?jié)點(diǎn)批量安裝MQTT應(yīng)用程序和設(shè)置屬性提供方便。該部分包括MQTT客戶(hù)端以及服務(wù)端兩個(gè)幫助程序，分別由類(lèi)ns3：：MqttClientHelper和類(lèi)ns3：：MqttBrokerHelper實(shí)現(xiàn)。二者均提供了Install方法用于在節(jié)點(diǎn)中簡(jiǎn)便地安裝應(yīng)用程序，同時(shí)提供兩種不同的安裝方式（由傳入的參數(shù)決定），分為單獨(dú)安裝和批量安裝。單獨(dú)安裝可對(duì)某一節(jié)點(diǎn)的應(yīng)用程序單獨(dú)進(jìn)行屬性設(shè)置，而批量安裝則會(huì)針對(duì)列表內(nèi)所有節(jié)點(diǎn)統(tǒng)一安裝屬性相同的應(yīng)用程序。

表4 MQTT幫助程序接口列表Table 4 MQTT helper interface list

3 使用說(shuō)明及仿真測(cè)試

3.1 集成方法

本文選擇ns-3.30版本的NS-3為例說(shuō)明擴(kuò)展的軟件包如何安裝到NS-3仿真平臺(tái)中。NS-3的安裝環(huán)境為ubuntu18.04 Linux操作系統(tǒng)，內(nèi)核版本為5.4.0-73-generic。具體的集成方法如下。

（1）下載ns-3.30版本的NS-3軟件。

（2）參照NS-3官方文檔安裝成功后，切換到ns-allinone-3.30/ns-3.30/src目錄，在該目錄下打開(kāi)終端，輸入sudo./create-module.py ns3-mqtt命令，利用create-module.py腳本創(chuàng)建一個(gè)新的ns3-mqtt模塊。

（3）模塊創(chuàng)建完成后，進(jìn)入ns-allinone-3.30/ns-3.30/src/ns3-mqtt目錄，也就是新創(chuàng)建模塊的文件夾中，用所擴(kuò)展的ns3-mqtt軟件包里的文件替換這個(gè)文件夾下的所有文件。

（4）然后返回至ns-allinone-3.30/ns-3.30目錄下執(zhí)行sudo./waf configure命令，對(duì)NS-3進(jìn)行重新配置，編譯系統(tǒng)會(huì)檢查NS-3依賴(lài)的軟件包是否已經(jīng)成功安裝。

（5）最后在相同目錄下執(zhí)行sudo./waf命令進(jìn)行編譯，編譯無(wú)錯(cuò)誤則ns3-mqtt安裝成功。

3.2 仿真示例

3.2.1 仿真設(shè)置

本文設(shè)計(jì)的仿真實(shí)驗(yàn)旨在給出一個(gè)示例作為參考，同時(shí)檢驗(yàn)框架實(shí)現(xiàn)的效果。為了和文獻(xiàn)[5]中使用OMNet++進(jìn)行的仿真實(shí)驗(yàn)結(jié)果進(jìn)行對(duì)比，本文中的仿真參數(shù)配置盡量與其接近。實(shí)驗(yàn)?zāi)M的是工業(yè)場(chǎng)景下空氣狀況的監(jiān)測(cè)，涉及溫濕度傳感器和紅外氣體傳感器，分別用于空氣溫濕度的監(jiān)測(cè)和空氣污染物的檢測(cè)?？臻g設(shè)定在100 m×100 m的范圍內(nèi)，節(jié)點(diǎn)的分布分為兩個(gè)區(qū)域，左側(cè)區(qū)域（60 m×100 m）代表了工業(yè)生產(chǎn)區(qū)域，右側(cè)區(qū)域（20 m×100 m）代表了工業(yè)數(shù)據(jù)監(jiān)測(cè)區(qū)域，MQTT服務(wù)端應(yīng)用程序安裝在坐標(biāo)為（50，50）的中心位置節(jié)點(diǎn)（位于工業(yè)生產(chǎn)區(qū)域內(nèi)），訂閱方MQTT客戶(hù)端應(yīng)用程序安裝在右側(cè)工業(yè)數(shù)據(jù)監(jiān)測(cè)區(qū)域的邊緣位置，用于收集傳感器發(fā)送的數(shù)據(jù)。其他發(fā)布方MQTT客戶(hù)端應(yīng)用程序都安裝在左側(cè)工業(yè)生產(chǎn)區(qū)域的節(jié)點(diǎn)中，工業(yè)生產(chǎn)區(qū)域的節(jié)點(diǎn)分布采用ns3：：UniformDiscPositionAllocator模型以恒定的密度隨機(jī)均勻地分布在以（30，50）坐標(biāo)為圓心半徑30 m的圓型區(qū)域內(nèi)，移動(dòng)模型選擇的是隨機(jī)圓盤(pán)靜態(tài)分布模型，所有節(jié)點(diǎn)在圓盤(pán)范圍內(nèi)隨機(jī)靜態(tài)分布，通過(guò)使用NetAnim動(dòng)畫(huà)工具展示了該布局，圖5給出了該布局的一個(gè)網(wǎng)絡(luò)拓?fù)涫纠?。另外仿真?shí)驗(yàn)中發(fā)布方客戶(hù)端設(shè)置為每隔5 s發(fā)送固定大小數(shù)據(jù)包以生成流量，同時(shí)所有模擬運(yùn)行10次取平均值以增加可信度，每次模擬運(yùn)行120 s。仿真實(shí)驗(yàn)的節(jié)點(diǎn)數(shù)量選為{1，30，60，90，120，150，180，210，240，270，300，330，360，390，420}，和文獻(xiàn)[5]中不同的原因在于為了觀察當(dāng)更大數(shù)量節(jié)點(diǎn)存在時(shí)，吞吐量及延遲的表現(xiàn)，這也是以前的研究所忽略的地方（注意這里的節(jié)點(diǎn)數(shù)量是指作為發(fā)布方的節(jié)點(diǎn)的數(shù)量）。同時(shí)考慮到仿真設(shè)定的空氣監(jiān)測(cè)場(chǎng)景不是延遲敏感型的，并且文獻(xiàn)[5]中的實(shí)驗(yàn)也采用了無(wú)線(xiàn)通信，因此通信模型選擇了wifi無(wú)線(xiàn)模型，Qos設(shè)置為默認(rèn)值0。仿真中的數(shù)據(jù)包大小設(shè)置為12字節(jié)以更好地符合傳感器等小型設(shè)備發(fā)包較小的特點(diǎn)，同時(shí)也增設(shè)了大小為120字節(jié)的數(shù)據(jù)包用于觀察數(shù)據(jù)包大小對(duì)吞吐量和延遲的影響。

圖5 網(wǎng)絡(luò)拓?fù)涫纠鼺ig.5 Example of network topology

3.2.2 性能指標(biāo)

MQTT的性能評(píng)估指標(biāo)采用的是平均時(shí)延和最大吞吐量。該性能指標(biāo)對(duì)于設(shè)備的采購(gòu)和網(wǎng)絡(luò)部署具有關(guān)鍵的指導(dǎo)作用。性能指標(biāo)中沒(méi)有選擇平均吞吐量的原因在于平均吞吐量只能反映設(shè)備一般情況下的性能，而工業(yè)環(huán)境中有著更嚴(yán)格的要求，即使在流量最高峰時(shí)也需滿(mǎn)足服務(wù)需求，因此在工業(yè)環(huán)境下最大吞吐量更有意義，能更精確地指導(dǎo)服務(wù)器等設(shè)備的參數(shù)選擇。以下為兩個(gè)指標(biāo)的具體描述。

（1）平均時(shí)延：所有分組（數(shù)據(jù)包）從源節(jié)點(diǎn)到達(dá)目標(biāo)節(jié)點(diǎn)所花費(fèi)的時(shí)間的平均值，單位為s。

（2）最大吞吐量：?jiǎn)挝粫r(shí)間內(nèi)節(jié)點(diǎn)接收的最大數(shù)據(jù)量（分組大小之和），單位為bit/s。

3.2.3 仿真結(jié)果及分析

仿真實(shí)驗(yàn)總共分為兩組。第一組仿真實(shí)驗(yàn)，數(shù)據(jù)包大小設(shè)置為12 Byte。觀察了客戶(hù)端數(shù)量對(duì)吞吐量和端到端延遲的影響，以獲取該仿真環(huán)境中每個(gè)服務(wù)端應(yīng)服務(wù)的最佳客戶(hù)端數(shù)量。圖6顯示了隨著客戶(hù)端數(shù)量的變化吞吐量大小的改變。圖7則顯示了隨著客戶(hù)端數(shù)量的變化延遲的改變。仿真結(jié)果顯示吞吐量在客戶(hù)端數(shù)量增長(zhǎng)的初期不斷大幅度上升，而到達(dá)一定數(shù)量后上升幅度驟降，甚至開(kāi)始下降，這與文獻(xiàn)[5]中觀察到的現(xiàn)象極其相似。

圖6 吞吐量峰值隨客戶(hù)端數(shù)量的變化Fig.6 Peak throughput variation with number of clients

圖7 延遲隨客戶(hù)端數(shù)量的變化Fig.7 Latency variation with number of clients

具體來(lái)看，客戶(hù)端數(shù)量是達(dá)到210后吞吐量的增幅開(kāi)始驟降，甚至出現(xiàn)了負(fù)增長(zhǎng)。這說(shuō)明初期在一定范圍內(nèi)隨著節(jié)點(diǎn)數(shù)量的增多，數(shù)據(jù)流量增加，帶寬利用率提高，同時(shí)網(wǎng)絡(luò)中的沖突和丟包現(xiàn)象較少，導(dǎo)致吞吐量提高。但是隨著節(jié)點(diǎn)越來(lái)越多，網(wǎng)絡(luò)信道過(guò)度使用、數(shù)據(jù)包丟失、網(wǎng)絡(luò)沖突等現(xiàn)象就會(huì)發(fā)生。這在工業(yè)環(huán)境中往往是很不利的。為此在實(shí)際部署前應(yīng)充分考慮每個(gè)服務(wù)端能服務(wù)的客戶(hù)端數(shù)量，在保證通訊質(zhì)量和數(shù)據(jù)完整性前提下最大限度地提升其吞吐量，提高資源利用率，節(jié)約成本。同時(shí)，實(shí)驗(yàn)表明延遲雖然整體會(huì)隨著節(jié)點(diǎn)數(shù)量的增加而不斷增加，但是在客戶(hù)端數(shù)量達(dá)到240后延遲的增幅會(huì)加大。這是由于網(wǎng)絡(luò)數(shù)據(jù)包逐漸增多，在一定范圍內(nèi)只是輕微擁堵造成延遲小幅度增加，但隨著客戶(hù)端的數(shù)量越來(lái)越多，數(shù)據(jù)包也會(huì)越來(lái)越多，而網(wǎng)絡(luò)信道的容量是有限的，會(huì)發(fā)生嚴(yán)重?fù)矶聸_突，并且接收方客戶(hù)端的接收數(shù)據(jù)的速率也是有上限的，會(huì)產(chǎn)生排隊(duì)時(shí)延等問(wèn)題，因此在當(dāng)前仿真場(chǎng)景下，每個(gè)服務(wù)端服務(wù)的發(fā)布方客戶(hù)端的最佳數(shù)量應(yīng)為210左右。

第二組仿真實(shí)驗(yàn)，則是觀察了不同數(shù)據(jù)包大小對(duì)訂閱方客戶(hù)端吞吐量和延遲變化的影響，以獲取相關(guān)啟發(fā)。針對(duì)吞吐量，實(shí)驗(yàn)觀察的是其達(dá)到增量拐點(diǎn)時(shí)對(duì)應(yīng)的客戶(hù)端數(shù)量，增量拐點(diǎn)指在該點(diǎn)以后吞吐量增量驟降的點(diǎn)。實(shí)驗(yàn)設(shè)置兩種數(shù)據(jù)包大小，分別是12 Byte和120 Byte。增加的120 Byte數(shù)據(jù)包用作對(duì)比，除單次發(fā)包大小不同外，其他仿真參數(shù)均不變。為方便對(duì)比效果的展示，將120 Byte時(shí)的吞吐量增量數(shù)據(jù)除以10。這樣處理是考慮到數(shù)據(jù)包大小增加十倍后，吞吐量也增加十倍左右。圖8顯示了在不同數(shù)據(jù)包大小下吞吐量增量隨著客戶(hù)端數(shù)量增加的變化情況。

從圖8中可以觀察到，數(shù)據(jù)包大小為12 Byte時(shí)到達(dá)增量拐點(diǎn)對(duì)應(yīng)的客戶(hù)端數(shù)量為210，而120 Byte時(shí)為150，隨著數(shù)據(jù)包的增大增量拐點(diǎn)提前了。這是因?yàn)閿?shù)據(jù)包的增大會(huì)更容易導(dǎo)致網(wǎng)絡(luò)擁塞。因此想要同時(shí)高質(zhì)量地服務(wù)更多的客戶(hù)端則需要更小的消息負(fù)載來(lái)降低數(shù)據(jù)包大小。

圖8 吞吐量增量隨客戶(hù)端數(shù)量的變化對(duì)比Fig.8 Comparison of throughput increment with number of clients

另外該組實(shí)驗(yàn)也觀察到了數(shù)據(jù)包增大對(duì)端到端的延遲的影響，圖9顯示了不同數(shù)據(jù)包大小下延遲隨客戶(hù)端數(shù)量增加的變化情況。

圖9 延遲隨客戶(hù)端數(shù)量的變化對(duì)比Fig.9 Comparison of latency with number of clients

觀察圖9可以發(fā)現(xiàn)，在210個(gè)客戶(hù)端內(nèi)，不同的負(fù)載下二者的延遲相差很少，但是隨著客戶(hù)端數(shù)量的繼續(xù)增加，更大的數(shù)據(jù)包就會(huì)導(dǎo)致更高的端到端的延遲。這是因?yàn)橥^大數(shù)據(jù)包被接收所需的時(shí)間更長(zhǎng)，而在客戶(hù)端較少時(shí)由于接收方的收包能力是冗余的，單位時(shí)間內(nèi)接收的數(shù)據(jù)量一直未到達(dá)極限值，因此對(duì)延遲的影響極小。從以上吞吐量增量和延遲的對(duì)比來(lái)看，較小的數(shù)據(jù)包都會(huì)帶來(lái)更優(yōu)的性能。為此在實(shí)際部署MQTT時(shí)應(yīng)盡量降低單次發(fā)送數(shù)據(jù)包的大小以獲取更好的性能及更低的部署成本。

4 結(jié)束語(yǔ)

本文提出了ns3-mqtt擴(kuò)展框架，并以軟件包的形式集成到NS-3中，使得在NS-3中模擬部署MQTT成為可能，極大地方便了相關(guān)研究的展開(kāi)。本文的框架設(shè)計(jì)思路以及協(xié)議的實(shí)現(xiàn)方法對(duì)NS-3中實(shí)現(xiàn)或改進(jìn)其他應(yīng)用層協(xié)議也具有借鑒意義，可供讀者參考。同時(shí)，為驗(yàn)證框架實(shí)現(xiàn)的有效性，參照文獻(xiàn)[5]中使用OMNet++仿真器的仿真參數(shù)，在集成后的NS-3中進(jìn)行了相似的仿真實(shí)驗(yàn)。仿真結(jié)果表明該框架能夠在NS-3中按照預(yù)期運(yùn)行，且觀察到了和文獻(xiàn)[5]中相似的實(shí)驗(yàn)現(xiàn)象。下一步的工作主要集中在開(kāi)發(fā)安全模塊，繼續(xù)豐富和擴(kuò)展本文提出的框架，通過(guò)仿真分析一些新穎的MQTT安全增強(qiáng)方案，并探究進(jìn)一步改進(jìn)的方法。