數(shù)據(jù)丟包重傳優(yōu)化方法
【技術(shù)領(lǐng)域】 [0001] 本發(fā)明涉及數(shù)據(jù)傳輸領(lǐng)域，特別涉及數(shù)據(jù)傳輸?shù)膩G包重傳優(yōu)化方法。
【背景技術(shù)】 [0002] 隨著控制技術(shù)的發(fā)展，在各種應(yīng)用系統(tǒng)中的數(shù)據(jù)傳輸越來越頻繁；同 時系統(tǒng)的構(gòu)建也由有線通信發(fā)展到無線通信，端對端聯(lián)系越來越密切而物理距離越來越 大，從而因為同頻干擾、障礙物或傳輸距離等環(huán)境因素造成的數(shù)據(jù)傳輸丟包現(xiàn)象時有發(fā)生， 不同的通信網(wǎng)絡(luò)丟包程度輕重不同而已。
[0003] 為保證數(shù)據(jù)傳輸質(zhì)量，現(xiàn)代各種通信協(xié)議棧一般都有制定丟包重傳機制。舉一基 于ZigBee (紫蜂協(xié)議，是一種基于IEEE802. 15. 4標(biāo)準(zhǔn)的低功耗局域網(wǎng)協(xié)議）技術(shù)的智能 控制系統(tǒng)為例，該系統(tǒng)包括一中控設(shè)備，用戶可以通過客戶端的界面工具(例如但不限于瀏 覽器）來訪問該中控設(shè)備的控制中心，從而實現(xiàn)對系統(tǒng)中各個ZigBee終端設(shè)備的控制或 獲取來自這些ZigBee終端設(shè)備的狀態(tài)或傳感數(shù)據(jù)。雖然ZigBee芯片所采用的ZigBee協(xié) 議棧有重傳機制，但受芯片資源、處理能力有限等因素的制約，加上外界WiFi (-種基于 IEEE802. lib標(biāo)準(zhǔn)的無線局域網(wǎng)）信號、微波爐微波輻射等同頻干擾、距離和障礙物對信號 的影響，這種重傳機制變得很不可靠，尤其在有連續(xù)控制請求需求的場景控制場合將出現(xiàn) 較多丟包，使智能控制系統(tǒng)實時控制的準(zhǔn)確度下降。

【發(fā)明內(nèi)容】
[0004] 本發(fā)明要解決的技術(shù)問題是針對上述現(xiàn)有技術(shù)的不足之處，而提出一種 丟包重傳優(yōu)化方法，避免收發(fā)數(shù)據(jù)在信號傳輸覆蓋范圍內(nèi)丟包較多造成通信不良。
[0005] 為解決上述技術(shù)問題，本發(fā)明的基本構(gòu)思為：基于數(shù)據(jù)通信的上、下行雙向傳輸及 數(shù)據(jù)交互的特性，若用一個消息識別碼來區(qū)分不同的交互事件，即把消息識別碼作為控制 請求消息及其控制響應(yīng)消息的唯一識別碼，控制中心即可利用該消息識別碼來匹配控制請 求消息和控制響應(yīng)消息，從而確認丟包事件及實現(xiàn)重傳優(yōu)化。具體到ZigBee系統(tǒng)中，用消 息識別碼替代ZCL幀幀頭中發(fā)送系列號字段，可以最大簡化協(xié)調(diào)器和終端設(shè)備的編碼或軟 件調(diào)整。
[0006] 作為實現(xiàn)本發(fā)明構(gòu)思的技術(shù)方案是，提供一種數(shù)據(jù)丟包重傳方法，基于交互系統(tǒng) 的數(shù)據(jù)雙向傳輸，包括步驟： A. 控制中心根據(jù)控制請求發(fā)送出控制請求消息； B. 控制中心接收控制響應(yīng)消息； C. 控制中心完成所述控制請求； 尤其是，設(shè)置一消息識別碼，用作為控制請求消息及其對應(yīng)控制響應(yīng)消息的唯一識別 碼，被所述控制中心賦予每一所述控制請求消息使該控制請求消息攜帶所述消息識別碼被 終端接收，并且該消息識別碼將隨著控制響應(yīng)消息返回給所述控制中心；控制中心發(fā)送一 控制請求消息后，根據(jù)預(yù)定時間間隔內(nèi)是否接收到有相同消息識別碼的控制響應(yīng)消息來判 斷是否發(fā)生數(shù)據(jù)丟包，若沒接收到則重發(fā)該控制請求消息。具體地，所述預(yù)定時間間隔可以 用定時器或定時器程序來實現(xiàn)。
[0007] 上述方法方案中，還包括設(shè)置一發(fā)送鏈表，所述控制中心每發(fā)送一控制請求消息 均還設(shè)置一對應(yīng)的控制請求消息封包來添加到所述發(fā)送鏈表，該控制請求消息封包包括該 控制請求消息和所述消息識別碼；所述控制中心每接收到一控制響應(yīng)消息均根據(jù)消息識別 碼來刪除該發(fā)送鏈表中對應(yīng)的控制請求消息封包。這樣系統(tǒng)將擁有并行處理多條控制請求 消息的能力。
[0008] 進一步地，所述控制請求消息封包還包括時間戳，用來記錄本對應(yīng)控制請求消息 的發(fā)送時刻。所述控制請求消息封包還包括重發(fā)次數(shù)，用來記錄本對應(yīng)控制請求消息被重 發(fā)的次數(shù)，以便控制中心對重發(fā)超過預(yù)定次數(shù)的控制請求消息進行處理，該處理包括將對 應(yīng)控制請求消息封包從發(fā)送鏈表中刪除。這樣，可以在系統(tǒng)有限的資源與追求數(shù)據(jù)完整傳 輸之間取得平衡。
[0009] 優(yōu)選地，上述方案中，所述交互系統(tǒng)為基于ZigBee協(xié)議的智能控制系統(tǒng)，該智能 控制系統(tǒng)包括所述控制中心、一 ZigBee協(xié)調(diào)器、若干ZigBee終端和一用來發(fā)布用戶控制命 令的客戶端；所述控制中心通過所述ZigBee協(xié)調(diào)器來與各ZigBee終端進行包括所述控制 請求消息和控制響應(yīng)消息在內(nèi)的數(shù)據(jù)傳輸，所述消息識別碼被設(shè)置在ZCL幀頭的發(fā)送系列 號字段。
[0010] 上述方案中，在所述智能控制系統(tǒng)內(nèi)設(shè)置一發(fā)送鏈表，所述控制中心每發(fā)送一控 制請求消息均還設(shè)置一對應(yīng)的控制請求消息封包來添加到該發(fā)送鏈表，該控制請求消息封 包包括該控制請求消息和所述消息識別碼，每接收到一控制響應(yīng)消息均根據(jù)消息識別碼來 刪除該發(fā)送鏈表中對應(yīng)的控制請求消息封包；所述控制請求消息封包中還包括時間戳和重 發(fā)次數(shù)，其中時間戳用來記錄該控制請求消息的發(fā)送時刻，重發(fā)次數(shù)用來記錄該控制請求 消息被重發(fā)的次數(shù)；對重發(fā)超過預(yù)定次數(shù)的控制請求消息，控制中心將把對應(yīng)的控制請求 消息封包從發(fā)送鏈表中刪除；重發(fā)一控制請求消息時，控制中心將更新發(fā)送鏈表中對應(yīng)的 控制請求消息封包，把時間戳更改為當(dāng)前重發(fā)時刻及把重發(fā)次數(shù)加1。
[0011] 進一步為防止誤動作，所述控制請求消息包括短地址和端點；所述控制中心每發(fā) 送一控制請求消息均還遍歷所述發(fā)送鏈表，來確保更新后的發(fā)送鏈表中具有與該控制請求 消息相同短地址和端點的控制請求消息封包有且僅有當(dāng)前一條。
[0012] 本發(fā)明方法的有益效果是：可以在處理芯片資源和處理能力有限的條件下大大 降低數(shù)據(jù)傳輸中的丟包率，從而克服環(huán)境因素對丟包的影響，提升用戶體驗，尤其適用于 Zigbee智能系統(tǒng)中的大場景控制。
[0013]
【附圖說明】圖1為使用本發(fā)明方法的中控設(shè)備示意框圖； 圖2為使用本發(fā)明方法的ZigBee系統(tǒng)框圖； 圖3為圖2實施例中發(fā)送控制請求消息的方法流程圖； 圖4為圖2實施例中重傳控制流程示意圖； 圖5為圖2實施例中控制響應(yīng)消息的接收處理流程示意圖。
【具體實施方式】 [0014] 下面結(jié)合【附圖說明】本發(fā)明方法。
[0015] 交互系統(tǒng)的數(shù)據(jù)雙向傳輸一般通過如圖1所示的中控設(shè)備進行控制。作為系統(tǒng)的 核心設(shè)備，中控設(shè)備至少包括相連的控制中心和數(shù)據(jù)收發(fā)處理模塊?？刂普埱笸ㄟ^有線(例 如但不限于與控制中心電連接的一用戶輸入端）或無線網(wǎng)絡(luò)(例如但不限于無線局域網(wǎng)）的 方式被控制中心所接收處理并得到響應(yīng)結(jié)果，所述接收處理包括步驟： A.控制中心根據(jù)所述控制請求發(fā)送出控制請求消息；該控制請求消息將經(jīng)過所述數(shù) 據(jù)收發(fā)處理模塊通過有線或無線網(wǎng)絡(luò)的方式傳輸出去；典型的控制請求消息一般包括有命 令字、消息長度、消息數(shù)據(jù)等字段； B. 控制中心接收控制響應(yīng)消息；該控制響應(yīng)消息是通過有線或無線網(wǎng)絡(luò)的方式由所 述數(shù)據(jù)收發(fā)處理模塊接收送往該控制中心的； C. 控制中心完成所述控制請求；進一步地，控制中心可以通過有線或無線網(wǎng)絡(luò)的方式 對外發(fā)送響應(yīng)結(jié)果。
[0016] 圖2 7K意了圖1在傳輸系統(tǒng)中的一個具體實施例，所述交互系統(tǒng)為基于ZigBee 協(xié)議的智能控制系統(tǒng)。所述控制中心通過相連的無線路由器例如但不限于在WiFi網(wǎng)絡(luò)中 與用來發(fā)布用戶控制命令的客戶端實現(xiàn)數(shù)據(jù)交互；客戶端可以但不限于使用瀏覽器來將用 戶發(fā)布的用戶控制命令轉(zhuǎn)換為相應(yīng)的若干控制請求傳送往該控制中心，并根據(jù)控制中心完 成控制請求后的反饋數(shù)據(jù)而提示執(zhí)行結(jié)果。所述數(shù)據(jù)收發(fā)處理模塊可以具體化但不限為 Zigbee協(xié)調(diào)器，在Zigbee網(wǎng)絡(luò)中以無線方式與若干Zigbee終端設(shè)備實現(xiàn)數(shù)據(jù)交互，從而所 述控制中心通過串口連接所述ZigBee協(xié)調(diào)器來與各ZigBee終端設(shè)備進行包括所述控制請 求消息和控制響應(yīng)消息在內(nèi)的數(shù)據(jù)傳輸。在小型通信系統(tǒng)中，不排除所述數(shù)據(jù)收發(fā)處理模 塊與控制中心集成在同一芯片上的可能。
[0017] 本發(fā)明數(shù)據(jù)丟包重傳方法是在上述接收處理過程中設(shè)置一消息識別碼，用作為 控制請求消息及其對應(yīng)控制響應(yīng)消息的唯一識別碼，所述控制中心將賦予每一所述控制 請求消息一個消息識別碼，使該控制請求消息攜帶該消息識別碼被終端(例如但不限于 Zigbee終端設(shè)備）接收，并且該消息識別碼將隨著控制響應(yīng)消息由終端返回給所述控制中 心；這樣控制中心發(fā)送一控制請求消息后，可以根據(jù)預(yù)定時間間隔內(nèi)是否接收到返有相同 消息識別碼的控制響應(yīng)消息來判斷是否發(fā)生數(shù)據(jù)丟包，若沒接收到則重發(fā)該控制請求消 息。該預(yù)定時間間隔可以用定時器或定時器程序來實現(xiàn)。以圖2實施例為例，ZigBee協(xié) 議規(guī)范中針對許多應(yīng)用場合的數(shù)據(jù)交互定義了若干標(biāo)準(zhǔn)的Zigbee簇庫（即ZCL，zigbee cluster 1 ibrary的縮寫)，并針對基于這些標(biāo)準(zhǔn)Zigbee簇庫的數(shù)據(jù)通信定義了標(biāo)準(zhǔn)的ZCL 幀消息，格式如下表所示：
可見，ZCL幀包括ZCL幀頭和ZCL幀負載，其中ZCL幀頭包括了 8位幀控制、0或16位 廠商代碼、8位發(fā)送系列號和8位命令I(lǐng)D。在Zigbee協(xié)調(diào)器和Zigbee終端設(shè)備間交互的 數(shù)據(jù)均以ZCL幀為基礎(chǔ)。為達到對系統(tǒng)軟硬件的最小改動，本發(fā)明方法在ZigBee智能控制 系統(tǒng)中最好將所述消息識別碼設(shè)置在ZCL幀頭的發(fā)送系列號字段。該8位字段的取值范圍 為0~255。
[0018] 圖2智能控制