基于和諧模式的數(shù)字集群二層協(xié)議棧的實現(xiàn)

劉葉紅，馬 越，徐海川，鄢楚平

（華北計算技術(shù)研究所，北京100083）

0 引 言

數(shù)字集群通信系統(tǒng)是一種共享資源、分擔費用、共用無線信道設(shè)備及服務(wù)的高級專用移動調(diào)度通信系統(tǒng)。數(shù)字集群通信系統(tǒng)采用了數(shù)字信令方式、語音數(shù)字編碼和數(shù)字調(diào)制解調(diào)等關(guān)鍵技術(shù)，因此，還具有頻譜利用率高、抗信號衰落能力強、保密性好以及業(yè)務(wù)多樣化等特點。

隨著數(shù)字集群通信技術(shù)的發(fā)展，國內(nèi)外先后為集群通信系統(tǒng)推出了各種空中接口協(xié)議標準。目前，主要的標準有TETRA、iDEN、DMR。國外的TETRA與iDEN系統(tǒng)都基于TDMA技術(shù)，國內(nèi)的GT800與GoTa系統(tǒng)則結(jié)合了TDMA和公眾移動通信網(wǎng)技術(shù)。TETRA系統(tǒng)采用的是基于小區(qū)制的數(shù)字集群通信系統(tǒng)，要實現(xiàn)遠距離通信和大區(qū)域覆蓋，就需要建設(shè)數(shù)量更多的基站，導(dǎo)致投資巨大，無法滿足部分行業(yè)用戶構(gòu)建專網(wǎng)的需要；而GT800和GoTa系統(tǒng)是基于公網(wǎng)而擴展的數(shù)字集群業(yè)務(wù)系統(tǒng)，在呼叫接續(xù)時間、終端直通等指標和功能上無法滿足應(yīng)急指揮調(diào)度用戶的應(yīng)用需求。因此迫切需要一種既采用TDMA技術(shù)體制，又能滿足大區(qū)域覆蓋，且呼叫接續(xù)時間短的數(shù)字集群通信系統(tǒng)。

在協(xié)議棧的開發(fā)方面，過去的分析和設(shè)計方法存在的問題主要有：

（1）分析設(shè)計沒有一個統(tǒng)一的標準；

（2）分析設(shè)計方法不統(tǒng)一；

（3）從設(shè)計到實現(xiàn)沒有一個統(tǒng)一的工程化方法，使得產(chǎn)品形成過程中的人為因素影響十分嚴重；

（4）設(shè)計成果難以被類似的開發(fā)項目或產(chǎn)品重用。

針對以上的不足，本文所采用的和諧設(shè)計模式借助UML語言的優(yōu)勢，為協(xié)議棧的開發(fā)提供了清晰的結(jié)構(gòu)流程以及可復(fù)用的軟件模塊，從而提高了開發(fā)效率和可維護性。

本文所選用的開發(fā)工具Rhapsody軟件是一種遵循UML和SysML標準的模型驅(qū)動的設(shè)計工具，對和諧設(shè)計進行了專門的配置與優(yōu)化，非常適用于嵌入式軟件的開發(fā)。

1 空中接口協(xié)議棧的總體架構(gòu)

數(shù)字集群通信系統(tǒng)空中接口協(xié)議棧的設(shè)計采用了OSI七層模型的分層思想，圖1示出了數(shù)字集群空中接口協(xié)議棧的模型。第一層為物理層，由定時結(jié)構(gòu)、無線電射頻信道等組成；第二層為數(shù)據(jù)鏈路層，可分為媒體接入控制（MAC）子層和邏輯鏈路控制（LLC）子層。其中，MAC子層又分為上 MAC（UMAC）子層和下 MAC（LMAC）子層；第三層為網(wǎng)絡(luò)層，其中，較低子層稱為移動鏈路實體（MLE），主要負責上下層之間的傳輸工作；較高子層包括移動性管理（MM）、電路控制實體（CMCE）以及子網(wǎng)絡(luò)獨立匯聚協(xié)議（SNDCP）3部分。

圖1 數(shù)字集群通信系統(tǒng)空中接口協(xié)議棧模型

本文的研究重點是協(xié)議棧的第二層，即數(shù)據(jù)鏈路層。在數(shù)據(jù)鏈路層中，LLC子層負責處理多條邏輯鏈路，以支持多個并發(fā)的業(yè)務(wù)，并負責信息的差錯控制、分段和重組、數(shù)據(jù)確認的傳輸、流量控制以及重傳等。MAC子層主要解決如何進行數(shù)據(jù)處理以適應(yīng)無線信道傳輸。其中，UMAC子層負責消息的分片聯(lián)合、信道復(fù)用、隨機接入、幀同步、功率控制等。LMAC子層主要實現(xiàn)信道編碼和交織，與物理層關(guān)系較大，因此在本文中不做研究。

此外，該模型的一個重要特點就是根據(jù)所傳輸信息的類型，將MAC層以上劃分為處理控制信息及分組業(yè)務(wù)的控制面（C面）和處理電路交換的話音及用戶數(shù)據(jù)業(yè)務(wù)的用戶面（U面）。

（1）對應(yīng)C面部分，LLC子層使用TLA＿SAP、TLB＿SAP和TLC＿SAP這3個業(yè)務(wù)接入點為移動鏈路實體（MLE）提供服務(wù)。其中，TLA＿SAP用來傳送信令信息，TLB＿SAP用來傳送系統(tǒng)廣播信息，TLC＿SAP用來傳送本地層管理信息。而LLC子層與UMAC子層之間使用TMA＿SAP、TMB＿SAP以及TMC＿SAP這3個業(yè)務(wù)接入點進行通信，分別對應(yīng)TLA＿SAP、TLB＿SAP和TLC＿SAP，用來傳送信令、廣播以及層管理信息。

（2）對應(yīng)U面部分，UMAC子層使用TMD＿SAP傳輸電路模式的業(yè)務(wù)，從圖1中可以看出，電路模式中沒有LLC實體。此外，UMAC子層和LMAC子層之間通過TMV＿SAP業(yè)務(wù)接入點進行通信。

2 空中接口協(xié)議棧的和諧設(shè)計過程

和諧設(shè)計與開發(fā)方法是一種由模型驅(qū)動的過程。在該過程中，模型是核心的工作產(chǎn)品，過程的階段都由特定類型的模型支撐。

和諧設(shè)計過程主要分為需求分析、功能分析和設(shè)計綜合等3個過程。

（1）需求分析過程：首先，將用戶需求導(dǎo)入，轉(zhuǎn)換為所需要的系統(tǒng)功能，并且將已經(jīng)識別的系統(tǒng)需求連接到相應(yīng)的用戶需求；然后，定義系統(tǒng)用例，并將系統(tǒng)用例與系統(tǒng)需求相映射。因此，支撐需求分析階段的模型主要有需求模型和系統(tǒng)用例模型，但這些模型是不能執(zhí)行的。

（2）功能分析過程：首先，創(chuàng)建用例與參與者之間的關(guān)系、用例場景以及對外端口和接口；然后，通過活動圖、順序圖或狀態(tài)圖來定義需求分析階段生成的用例的行為。其中，最重要的圖是狀態(tài)圖，它集合了黑盒順序圖及黑盒活動圖的信息，并且可以通過運行模型來驗證；最后，通過模型執(zhí)行來驗證模型及所承載的需求。

（3）設(shè)計綜合過程：主要有架構(gòu)分析、架構(gòu)設(shè)計和詳細架構(gòu)設(shè)計3個過程。架構(gòu)分析階段的重點是以合理的方式去確定實現(xiàn)特殊功能的最佳方法；架構(gòu)設(shè)計階段的重點是將系統(tǒng)層的業(yè)務(wù)功能分配給架構(gòu)元素；詳細架構(gòu)設(shè)計階段的重點是最終子系統(tǒng)端口和接口以及每個子系統(tǒng)的基于狀態(tài)的行為的定義。

本文通過以上3個設(shè)計過程，對數(shù)字集群空中接口協(xié)議棧整個系統(tǒng)進行了設(shè)計，并將得到的設(shè)計成果移交給后續(xù)的開發(fā)過程，以此規(guī)范了協(xié)議棧各部分的開發(fā)。設(shè)計成果可以保證協(xié)議棧各層之間的交互遵循一個統(tǒng)一的標準，從而提高了開發(fā)效率和可維護性，其內(nèi)容包括系統(tǒng)需求、系統(tǒng)結(jié)構(gòu)及協(xié)議棧各層之間的邏輯接口、至各層的外部激勵、各層的模型、屬性、方法、端口、接口、活動圖、狀態(tài)圖以及用例場景等。本文將依照上述移交的設(shè)計成果，使用基于和諧設(shè)計和開發(fā)思想的Rhapsody開發(fā)平臺，對二層協(xié)議棧進行具體的設(shè)計與實現(xiàn)。

3 二層協(xié)議棧的設(shè)計與實現(xiàn)

3.1 協(xié)議概述

3.1.1 LLC子層協(xié)議概述

LLC子層提供兩種具有不同業(yè)務(wù)質(zhì)量的鏈路：基本鏈路和高級鏈路。當移動臺和基站取得同步后就存在可用的基本鏈路，它主要用于一般信令消息的傳送。高級鏈路需要請求才能建立，它對于大量數(shù)據(jù)傳輸具有更高的效率。

高級鏈路和基本鏈路類似的功能主要有邏輯鏈路維護、差錯檢測、重傳、接收數(shù)據(jù)確認、數(shù)據(jù)發(fā)送順序設(shè)定等。除以上功能之外，高級鏈路還具有一些基本鏈路不具備的功能，如分段和重裝、窗口機制、流量控制。

3.1.2 UMAC子層協(xié)議概述

UMAC子層主要實現(xiàn)消息的接入控制、分片、重組、信道復(fù)用及解復(fù)用等功能。在上行鏈路，MS可以采取隨機接入或保留接入的方式接入信道，但初始接入必須使用隨機接入的方式。隨機接入是基于Slotted ALOHA協(xié)議的，所以，為了保證較高的成功率，必須選擇適當?shù)慕尤雲(yún)?shù)。當上層發(fā)送的信令超過一個物理時隙所能承載的長度時，可以使用分片技術(shù)通過多個時隙按序傳輸這些分片信令。與分片對應(yīng)的是信令重組技術(shù)，當接收方接收到分片信令之后，將緩存分片直到收齊所有分片，然后進行重組并將完整的信令交付給上層。信道復(fù)用是指在上行方向，UMAC按時隙將數(shù)據(jù)傳輸?shù)絃MAC，在同一個時隙內(nèi)，若干邏輯信道按一定的準則進行復(fù)用并形成發(fā)送突發(fā)。信道解復(fù)用是指在下行方向，LMAC把接收到的時隙上若干邏輯信道按一定的準則解復(fù)用，形成協(xié)議包遞交到UMAC。

3.2 結(jié)構(gòu)設(shè)計

在和諧設(shè)計階段，得到了數(shù)據(jù)鏈路層兩子層的模型，以及子層之間以及與上下層之間的公共接口。在結(jié)構(gòu)設(shè)計階段，按照功能對生成的二層協(xié)議棧的模型進一步劃分，此外，還定義了各子層模塊之間的內(nèi)部接口。

LLC層的內(nèi)部結(jié)構(gòu)如圖2所示，主要包括邏輯鏈路管理（Logic＿Link＿Management）模塊、基本鏈路（Basic＿Link）模塊、確認的高級鏈路（Acknowledged＿Advanced＿Link）模塊、不確認的高級鏈路（Unacknowledged＿Advanced＿Link）模塊和格式管理（Formatter＿Management）模塊。

圖2 LLC子層結(jié)構(gòu)

（1）邏輯鏈路管理模塊主要負責邏輯鏈路的建立、管理和拆除，并且轉(zhuǎn)發(fā)上下層的信令消息及用戶數(shù)據(jù)。

（2）基本鏈路模塊按實現(xiàn)的業(yè)務(wù)不同，可分為基本鏈路確認（Basic＿Link＿Acknowledged）模塊和基本鏈路不確認（Basic＿Link＿Unacknowledged）模塊，分別實現(xiàn)確認消息的傳輸和不確認消息的傳輸。

（3）確認的高級鏈路模塊和不確認的高級鏈路模塊分別實現(xiàn)高級鏈路的確認消息的傳輸和不確認消息的傳輸。

（4）格式管理模塊FM主要實現(xiàn)PDU的編解碼以及轉(zhuǎn)發(fā)上下層的原語信息。

UMAC子層按功能可以劃分為發(fā)送模塊（TransmitP）和接收模塊（ReceiveP）兩個模塊，分別負責數(shù)據(jù)的發(fā)送和接收，如圖3所示。

（1）接收模塊用于空中接口下行數(shù)據(jù)的處理。主要實現(xiàn)幀和復(fù)幀的同步、PDU譯碼、功率控制、信道維護、路徑損耗的計算以及節(jié)能操作等功能。

圖3 UMAC子層結(jié)構(gòu)

（2）發(fā)送模塊用于空中接口上行數(shù)據(jù)的處理。主要實現(xiàn)隨機接入、保留接入、分片、信道復(fù)用、PDU編碼以及信道挪用等功能。

此外，URelayP和LRelayP是中繼模塊，主要負責UMAC子層內(nèi)部功能模塊與上下層實體之間的信令轉(zhuǎn)發(fā)，引入這兩個模塊是為了保證每個端口和模塊的一一對應(yīng)，為工程實現(xiàn)所需要，無協(xié)議功能。

3.3 PDU和原語設(shè)計

為了實現(xiàn)各個模塊間的信息交互，按照協(xié)議規(guī)定，定義了各個模塊接口之間所需要的PDU和原語。通過設(shè)計相應(yīng)的PDU編解碼函數(shù)，實現(xiàn)對不同類型PDU的編解碼操作。原語用來實現(xiàn)協(xié)議棧上下層之間的信息交互，按照協(xié)議規(guī)定，將原語定義成結(jié)構(gòu)體，其中包含了上下層參數(shù)和要傳輸?shù)臄?shù)據(jù)。

所有的PDU和原語都是通過信號事件的方式進行傳輸。信號事件代表對象之間傳遞的一種異步激勵信號，可以攜帶參數(shù)，并且和一個響應(yīng)對象關(guān)聯(lián)。此外，還定義了另一種事件即定時事件，以精確程序的執(zhí)行時間，此外，也設(shè)計了處理相應(yīng)超時現(xiàn)象的操作。

3.4 狀態(tài)機設(shè)計

Rhapsody支持UML狀態(tài)機，包括層次狀態(tài)分解和嵌套、帶參事件、定時事件、完成轉(zhuǎn)移、入口和出口動作等功能，也包含了UML中定義的異步事件處理模型。本文針對LLC子層和UMAC子層提供的業(yè)務(wù)，分別設(shè)計了各個子模塊的狀態(tài)圖，利用狀態(tài)圖描述了各個子模塊之間以及與上下層之間信息交互的過程。由于UMAC子層狀態(tài)遷移較少，因此本文不做描述。圖4給出了基本鏈路的狀態(tài)轉(zhuǎn)移圖。

圖4 LLC基本鏈路實體的狀態(tài)轉(zhuǎn)移

基本鏈路實體主要有3種狀態(tài)。IDLE表示空閑狀態(tài)， 此時沒有數(shù)據(jù)傳送。DATA＿TX表示數(shù)據(jù)傳輸狀態(tài)。WAIT＿FOR＿MAC＿HANDLE表示發(fā)送完數(shù)據(jù)，停靠在這一個狀態(tài)以等待MAC的傳輸報告。WAIT＿FOR＿MAC＿CANCEL表示LLC收到數(shù)據(jù)取消請求時，但已經(jīng)將數(shù)據(jù)發(fā)送給MAC，便停靠在這一個狀態(tài)以等待MAC的傳送取消報告。其中，IDLE是默認的初始狀態(tài)，當沒有數(shù)據(jù)需要傳輸時，基本鏈路將一直保持這個狀態(tài)。如果在IDLE狀態(tài)下接收到數(shù)據(jù)發(fā)送請求，基本鏈路轉(zhuǎn)到DATA ＿TX狀態(tài)，同時，向MAC子層發(fā)送DATA ＿IN＿BUFFER信號，通知MAC子層有數(shù)據(jù)要傳輸，并且開始等待MAC子層給予的發(fā)送許可。當收到FormatterReady發(fā)送許可之后，基本鏈路把數(shù)據(jù)發(fā)送給MAC子層，同時，進入WAIT＿FOR＿MAC＿HANDLE狀態(tài)，以等待MAC子層的發(fā)送報告。當收到TMA＿REPORT＿IND回應(yīng)后，基本鏈路判斷等待隊列是否還有數(shù)據(jù)要發(fā)，如果沒有，則進入IDLE狀態(tài)，否則進入DATA＿TX狀態(tài)，繼續(xù)傳輸隊列中的數(shù)據(jù)。

4 二層協(xié)議棧的實現(xiàn)和測試

4.1 編碼和實現(xiàn)

數(shù)字集群通信系統(tǒng)空中接口協(xié)議棧使用Rational Rhapsody開發(fā)和編譯，協(xié)議開發(fā)流程如圖5所示。

首先，針對結(jié)構(gòu)設(shè)計中劃分的各個子模塊，設(shè)計了模塊間各接口上傳輸?shù)腜DU、原語和用于存儲和傳輸信息的參數(shù)變量。然后編寫了PDU的編解碼函數(shù)，至此，完成了協(xié)議棧的靜態(tài)設(shè)計與實現(xiàn)。接著，使用狀態(tài)圖描述協(xié)議交互的過程，實現(xiàn)了協(xié)議棧的動態(tài)設(shè)計。最后，編寫測試用例對協(xié)議進行功能測試。

圖5 協(xié)議開發(fā)流程

4.2 測 試

在協(xié)議實現(xiàn)之后，對協(xié)議進行了功能測試。本文采用一致性測試方法，通過給被測系統(tǒng)一個輸入激勵，然后比較實際輸出與預(yù)期輸出的異同，判定被測系統(tǒng)與協(xié)議標準的一致程度。

本文使用Rhapsody提供的測試工具（工具名稱），采用狀態(tài)圖和序列圖來描述測試用例，對各功能模塊和模塊間接口進行了測試，檢測模塊功能是否正確實現(xiàn)。

Rhapsody允許通過執(zhí)行狀態(tài)圖和順序圖來驗證系統(tǒng)的功能和邏輯，能將被測對象的方法調(diào)用和狀態(tài)改變以圖形形式表現(xiàn)出來。本文利用這一特點對各功能模塊和模塊間接口進行了測試，檢測模塊功能是否正確實現(xiàn)。圖6示出了二層協(xié)議棧的LLC子層使用基本鏈路傳送信令的執(zhí)行過程。

圖6 LLC子層發(fā)送信令的過程

5 結(jié)束語

本文論述了基于和諧設(shè)計模式下，數(shù)字集群二層協(xié)議棧的設(shè)計和開發(fā)流程，并對協(xié)議進行了編碼實現(xiàn)和一致性測試，結(jié)果證明協(xié)議流程完全符合數(shù)字集群通信系統(tǒng)協(xié)議標準。本文所采用的Rhapsody工具是一種支持實時UML的嵌入式系統(tǒng)軟件工具，它實現(xiàn)了從系統(tǒng)的分析、設(shè)計到代碼自動生成的開發(fā)過程自動化，為嵌入式軟件的開發(fā)提供了清晰的設(shè)計流程、結(jié)構(gòu)流程以及可復(fù)用的軟件模塊，從而提高了軟件的開發(fā)效率和可維護性。本文今后將對協(xié)議某些重要參數(shù)和功能進行進一步研究和優(yōu)化，如并發(fā)業(yè)務(wù)的處理、系統(tǒng)接入時間等方面。

［1］LI Duoduo，QUAN Jinguo，LIN Xiaokang.The development status of TETRA standard technology ［J］.Mobile Communications，2006，30（4）：31－34（in Chinese）.［李多多，權(quán)進國，林孝康.TETRA標準技術(shù)發(fā)展現(xiàn)狀 ［J］.移動通信，2006，30（4）：31－34.］

［2］ZHENG Zuhui，LU Jinhua，ZHENG Lan.Digital trunking mobile communication system ［M］.2nd ed.Beijing：Electronics Industry Press，2005（in Chinese）.［鄭祖輝，陸錦華，鄭嵐.數(shù)字集群移動通信系統(tǒng) ［M］.2版.北京：電子工業(yè)出版社，2005.］

［3］SUN xin，LI Hai.The analysis of TETRA digital trunking air interface protocol stack architecture ［J］.Mobile Communications，2008，32（3）：34－37（in Chinese）.［孫 昕， 李 海.TETRA數(shù)字集群空中接口協(xié)議棧體系結(jié)構(gòu)分析 ［J］.移動通信，2008，32（3）：34－37.］

［4］DONG Chao.The design and implementation of digital trunking terminal protocol stack based on platform of OMAP ［D］.Chengdu：University of Electronic Science and Technology，2010（in Chinese）.［董超.基于OMAP平臺的數(shù)字集群終端協(xié)議棧的設(shè)計與實現(xiàn) ［D］.成都：電子科技大學(xué)，2010.］

［5］LI Yanbo，F(xiàn)ENG Zhiyong.Research of Tetra mobile station air interface protocol stack software development ［J］.Electronic Measurement Technology，2007，30（5）：126－128（in Chinese）.［李延波，馮志勇.Tetra移動臺空中接口協(xié)議棧軟件開發(fā) ［J］.電子測量技術(shù)，2007，30（5）：126－128.］

［6］HE Wenjuan.The analysis and design of Layer2communication protocol on WCDMA mobile terminal ［D］.Beijing：Posts and Telecommunications University，2005（in Chinese）.［和文娟.WCDMA移動終端上Layer2通信協(xié)議的分析與設(shè)計 ［D］.北京：北京郵電大學(xué)，2005.］

［7］ZUO Yiping.Research and realization of LLC advanced link in TETRA digital trunked base station ［D］.Beijing：Beijing Jiaotong University，2008（in Chinese）.［左一平.TETRA 數(shù)字集群基站LLC層高級鏈路功能的研究與實現(xiàn) ［D］.北京：北京交通大學(xué)，2008.］

［8］SONG Zhenyu，SUN Xin.The development of TETRA system upper MAC layer protocol stack ［J］.Mobile Communications，2009，30（12）：35－39（in Chinese）.［宋政育，孫昕.TETRA數(shù)字集群系統(tǒng)上MAC層協(xié)議棧的開發(fā) ［J］.移動通信，2009，30（12）：35－39.］

［9］ZHONG Dafan.Researeh and development for uplink channel of upper MAC layer in TETRA digital trunked system ［D］.Beijing：Beijing Jiaotong University，2008（in Chinese）.［仲達帆.TETRA數(shù)字集群系統(tǒng)上MAC層上行信道的研究與開發(fā)［D］.北京：北京交通大學(xué)，2008.］

［10］YOU Jiajin.A study on TETRA mobile station MAC protocol［J］.Informatization Research，2010，36（1）：30－32（in Chinese）.［尤佳勁.TETRA系統(tǒng)中 MS側(cè) MAC層協(xié)議研究［J］.信息化研究，2010，36（1）：30－32.］

［11］WANG Bin，LUO Haibin.ALOHA protocol for resolving channel collision in digital trunking system ［J］.Communications Technology，2008，41（7）：150－152（in Chinese）.［王彬，羅海彬.數(shù)字集群中信道爭用問題的ALOHA協(xié)議研究［J］.通信技術(shù)，2008，41（7）：150－152.］

［12］CHEN Xiang，XUE Xiaoping，ZhANG Sidong.Studies on tag anti－collision algorithms ［J］.Modern Electronics Technique，2006，29（5）：13－15（in Chinese）.［陳香，薛小平，張思東.標簽防沖突算法的研究 ［J］.現(xiàn)代電子技術(shù)，2006，29（5）：13－15.］

［13］WANG Hao，WANG Yang，LIN Xiaokang.A simulation model based on signal flow of DLL in the air interface of TETRA protocol ［J］.Computer Simulation，2007，24（10）：131－135（in Chinese）.［汪 浩， 汪 洋， 林 孝 康. 一 種 基 于TETRA空中接口DLL信令的仿真模型 ［J］.計算機仿真，2007，24（10）：131－135.］

［14］Che Kui，Cheng Baozhong，Niu Xiaotai，Xing Shutao.Research and application of UML for embedded system development［J］.Computer Engineering And Design，2009，30（15）：3559－3564（in Chinese）.［車葵，程保中，牛曉太，等.UML在嵌入式系統(tǒng)開發(fā)中的研究與應(yīng)用 ［J］.計算機工程與設(shè)計，2009，30（15）：3559－3564.］

［15］TS 100 392－2V2.6.1.Terrestrial trunked radio（TETRA）voice plus data（V＋D）part 2：Air interface（AI）［S］.