基于會話、隊列控制的北斗短報文傳輸協議設計?

2018-03-31 06:04:35徐開來馬良荔

艦船電子工程 2018年3期

王亮徐開來馬良荔

1 引言

北斗是我國自行研制的衛星導航系統，具有定位、授時、短報文功能，且成本低、體積小，非常適合廣域物聯網網絡層的解決方案，其中短報文功能為解決遠海和偏遠地區通信提供了雙向信道。北斗衛星導航系統的短報文功能在設計之初并未考慮到大于單條報文長度以及多對多的應用，在數據大于短報文的情況下無法實現有效的傳輸，且目前尚無同等價格、同等體積的通信設備替代北斗衛星的功能。從具體應用方面來看，北斗的短報文通信在傳輸中還存在限制，具體如下：

1）單次通信容量有限，每次進行短報文通信所能傳輸的數據量是有限的，普通用戶最高傳輸速度為120字節/分鐘，數據如果超過最大報文長度，必須進行分包傳送；

2）通信頻度有限，北斗系統每發送完一條報文后需等待很長的時間才能進行下一次傳輸；

3）北斗衛星通信是不可靠的通信鏈路，在連續傳輸中丟包率較高。

文獻［1～5］均對常規短報文協議進行擴展，一定程度增加了傳輸性能，但其定義的分包傳輸協議僅解決了點對點的傳輸方案，實際應用中不可能有如此理想的傳輸環境，尤其是在多對多的物聯網環境中，某點在長時間接收分包數據的同時還有可能接收到其他點數據或同一點的第二份數據（加裝復數北斗卡的發送端），由于沒有標識符，接收端無法分辨數據來源，這就造成了數據混淆，使得分包數據無法還原，得不到最終數據。本文將傳統的短報文分包傳輸協議進行改進，加入WEB服務器中的“會話控制”和“隊列控制”方法，融合重傳和確認機制保證數據可靠傳輸，以滿足物聯網中多對多傳輸的實際需求，使北斗通信在物聯網平臺能發揮更好的功效。

2 會話控制的設計與實現

物聯網應用架構下，其采集端的數據種類包括控制指令、文字信息、圖像信息等，且數據交互頻繁，對于數據長度大于單次報文最大度120字節的數據，通常利用分包傳輸，但傳輸等待時間長，在等待時間內為避免多份數據之間混淆，設定一個全網唯一標識符進行區別。

接受端向發送端請求數據后，結合發送端和接收端的用戶ID生成的全網唯一標識符“會話ID”（具體生成算法不在本文研究范圍中），之后發送確認包，包含本次傳輸的會話ID、是否分包且分包數量等信息，之后開始數據包傳輸。與此同時，接收端仍可以實時接收其他或同一發送端的數據包，區分規則即為會話ID。這樣，當接收端收到另一發送端的數據時，為不同會話ID開辟獨立內存空間進行接收存儲，直至數據傳輸完畢，從內存中銷毀會話ID，將數據寫入硬盤。

3 隊列控制的設計與實現

發送端在進行數據傳輸時，會遇到上一會話還沒有完成，又接收新的發送指令，此時應根據請求創建會話隊列，檢測是否有空閑的信道，有則分配信道開始傳輸，否則掛起傳輸請求，等待前次傳輸完成。在等待期間若接收到接收端的“取消請求數據”的請求包，根據其攜帶的會話ID，查詢相應的傳輸進程，若傳輸未完成則終止傳輸，否則取消請求數據失敗，兩種情況均插隊向接收端發送一條確認包，并銷毀會話ID，記入日志。

接收端只有在收到確認包，識別到會話ID后才可知本次傳輸是否在隊列、預計排隊時間、預計完全接收完畢的時間，告知用戶，由用戶決定是否取消本次傳輸。若取消，則發送帶有“取消請求數據”和本次傳輸“會話ID”的請求包，之后收到取消成功的確認包即完成取消請求操作；不取消，則等待傳輸完畢。

4 可靠傳輸的設計與實現

4.1 發送端流程

在發送端接收到接收端請求數據的請求包后，創建“會話ID”作為本次傳輸的唯一標識符，根據“數據標識符”找到要傳輸的數據，分析所請求的數據體積，若超出單次報文最大長度則拆分為子數據包，并對每個小數據包添加包含“會話ID”和“數據包ID”的包頭，依次發送，直至全部發送完畢。若發送期間再次接收到請求數據的請求包，則依然創建“會話ID”，開啟隊列模式，暫時掛起本次會話ID傳輸，等待信道空閑，并插隊發送一條確認包，告知接收端會話ID。接收端可依照會話ID，發送“取消請求數據”的請求包，發送端會根據會話ID取消在隊列中的傳輸，并插隊發送一條確認包，告知接收端該會話ID的傳輸取消成功。

數據發送完畢后，等待接收端回執包，識別回執包中“類型”若為1（完成）則，將本次會話相關信息存入硬盤后，銷毀會話ID，清空緩存；若為2（補發）則識別“回執包總條數”，確認要接收的回執包個數，等待全部回執包接收完畢，統計“缺失數據包序號”，重新發送相應的子數據包，重復此過程直至回執包“類型”為1。若為3（超時）或等待超過一定時間，則判定為超時，將本次“會話”相關數據掛起存入硬盤，寫入日志，等待人工操作，之后銷毀“會話ID”，清空緩存。

4.2 接收端流程

向發送端發送請求包后，等待“確認包”，收到后識別“本次傳輸數據包總量”，查詢“會話ID”，若無則創建，之后持續接收數據包，分析包頭，并將數據包按照“會話ID”存儲于緩存中，直至接收完畢，比對緩存中數據包，記錄丟包編號，向發送端發送回執包，標注“類型2（補包）”，同時繼續接收數據包，重復此過程直至數據包完整，向發送端發送回執包“類型1（完成）”，重新組合數據包。接收過程中，一定時間未收到數據包或確認包則判定為超時，將本次“會話”相關數據掛起存入硬盤，寫入日志，等待人工操作，之后銷毀“會話ID”，清空緩存。發送端、接收端整體流程圖如圖1所示。