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

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

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

0 引 言

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

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

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

（1）分析設(shè)計(jì)沒有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 協(xié)議概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 PDU和原語(yǔ)設(shè)計(jì)

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

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

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

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

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

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

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

4.1 編碼和實(shí)現(xiàn)

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

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

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

4.2 測(cè) 試

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

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

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

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

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

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

［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)進(jìn)國(guó)，林孝康.TETRA標(biāo)準(zhǔn)技術(shù)發(fā)展現(xiàn)狀 ［J］.移動(dòng)通信，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ù)字集群移動(dòng)通信系統(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］.移動(dòng)通信，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平臺(tái)的數(shù)字集群終端協(xié)議棧的設(shè)計(jì)與實(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移動(dòng)臺(tái)空中接口協(xié)議棧軟件開發(fā) ［J］.電子測(cè)量技術(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移動(dòng)終端上Layer2通信協(xié)議的分析與設(shè)計(jì) ［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層高級(jí)鏈路功能的研究與實(shí)現(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］.移動(dòng)通信，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）.［仲達(dá)帆.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ù)字集群中信道爭(zhēng)用問題的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）.［陳香，薛小平，張思東.標(biāo)簽防沖突算法的研究 ［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］.計(jì)算機(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］.計(jì)算機(jī)工程與設(shè)計(jì)，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］.