王鵬　李?！∷纹鹬￡悋?/p>

【摘 要】主要提出了一種基于TTCN-3測試語言和外部設(shè)備接口（PEI）的TETRA系統(tǒng)分組數(shù)據(jù)互操作性測試方案。首先介紹測試系統(tǒng)框架，然后對(duì)PEI鏈路的建立流程進(jìn)行分析，最后闡述了基于TTCN-3的TETRA系統(tǒng)分組數(shù)據(jù)互操作性測試的具體實(shí)現(xiàn)，并給出基于TTworkbench測試平臺(tái)的測試?yán)臏y試結(jié)果。

【關(guān)鍵詞】TETRA 分組數(shù)據(jù) 互操作性 TTCN-3

中圖分類號(hào)：TN929.52 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1006-1010（2014）-02-

1 引言

TETRA系統(tǒng)是目前國內(nèi)外應(yīng)用最普遍的數(shù)字集群通信系統(tǒng)，市場上已經(jīng)有眾多廠商生產(chǎn)開發(fā)的各類TETRA終端和網(wǎng)絡(luò)設(shè)備。為了確保這些設(shè)備都完全符合ETSI制定的TETRA標(biāo)準(zhǔn)[1]，就需要對(duì)不同廠商生產(chǎn)的TETRA終端和網(wǎng)絡(luò)設(shè)備進(jìn)行互操作性測試。目前，國際上的TETRA產(chǎn)業(yè)聯(lián)盟（TETRA MoU）所進(jìn)行的TETRA互操作性測試仍然是手工完成的，工作效率低、測試時(shí)間長，測試后需要耗費(fèi)大量人力和時(shí)間對(duì)待測設(shè)備采集的日志文件進(jìn)行分析，往往數(shù)月后才能獲得最終測試結(jié)果。因此，迫切需要建立一套可以快速、便捷地自動(dòng)完成TETRA互操作性測試的系統(tǒng)。

在TETRA系統(tǒng)測試中，分組數(shù)據(jù)的測試較復(fù)雜。本文針對(duì)分組數(shù)據(jù)測試的PPP協(xié)議處理、TTCN-3測試?yán)木帉?、系統(tǒng)適配器（SA，System Under Test Adapter）和編解碼器（CD，Codec）的開發(fā)等關(guān)鍵問題進(jìn)行了分析，并給出了相應(yīng)的解決方案。

2 測試系統(tǒng)框架

被測系統(tǒng)由移動(dòng)臺(tái)（MS，Mobile Station）和交換與管理基礎(chǔ)設(shè)施（SwMI，Switching and Management Infrastructure）共同構(gòu)成，測試系統(tǒng)組成如圖1所示。

圖1 測試系統(tǒng)組成

移動(dòng)臺(tái)和SwMI之間通過TETRA空中接口協(xié)議標(biāo)準(zhǔn)進(jìn)行信令和數(shù)據(jù)的傳輸。TETRA產(chǎn)業(yè)聯(lián)盟針對(duì)TETRA系統(tǒng)分組數(shù)據(jù)業(yè)務(wù)的互操作性測試制定了測試標(biāo)準(zhǔn)（TTR001-05[3]）和測試計(jì)劃（IOP001-05[4]）。測試系統(tǒng)使用TTCN-3測試語言進(jìn)行開發(fā)。TTCN-3是由ETSI維護(hù)的全球適用的標(biāo)準(zhǔn)測試語言，適用于描述在多種通信端口上的各種響應(yīng)系統(tǒng)測試，已經(jīng)被廣泛應(yīng)用于協(xié)議測試領(lǐng)域[5-7]。測試系統(tǒng)模擬數(shù)據(jù)終端的功能，通過PEI（Peripheral Equipment Interface，外部設(shè)備接口）接口控制移動(dòng)臺(tái)發(fā)送和接收分組數(shù)據(jù)，并將接收到的數(shù)據(jù)和測試標(biāo)準(zhǔn)進(jìn)行對(duì)比，從而實(shí)現(xiàn)互操作性自動(dòng)測試。

測試系統(tǒng)、移動(dòng)臺(tái)和SwMI之間的分組數(shù)據(jù)測試協(xié)議棧如圖2所示。進(jìn)行分組數(shù)據(jù)測試時(shí)，測試系統(tǒng)通過PEI鏈路與移動(dòng)臺(tái)相連接。測試系統(tǒng)的數(shù)據(jù)經(jīng)過移動(dòng)臺(tái)的PEI控制實(shí)體處理后，再傳至移動(dòng)臺(tái)的SNDCP實(shí)體，進(jìn)而觸發(fā)移動(dòng)臺(tái)與SwMI進(jìn)行相應(yīng)的空中接口協(xié)議交互。

圖2 測試系統(tǒng)、移動(dòng)臺(tái)和SwMI之間的分組數(shù)據(jù)測試協(xié)議棧

3 PEI協(xié)議過程分析

測試系統(tǒng)通過PEI鏈路和被測系統(tǒng)進(jìn)行通信，而PEI鏈路的建立需要遵從PPP（Point to Point Protocol）協(xié)議[8-9]。測試系統(tǒng)與移動(dòng)臺(tái)連接后，先向移動(dòng)臺(tái)發(fā)送“ATD*99#”命令，隨后兩者之間開始進(jìn)行建鏈協(xié)商。

PEI鏈路的建立分為三個(gè)階段進(jìn)行：

第一階段是鏈路控制協(xié)議（LCP，Link Control Protocol）協(xié)商，主要進(jìn)行與鏈路控制相關(guān)的參數(shù)的配置，包括最大幀長、異步控制字符映射、是否使用鑒權(quán)協(xié)議和頭部壓縮等。

第二階段是鑒權(quán)，本階段是否執(zhí)行取決于在LCP階段協(xié)商中是否使用鑒權(quán)協(xié)議。如果使用鑒權(quán)協(xié)議，在本階段就需要進(jìn)行相應(yīng)的鑒權(quán)處理，目前系統(tǒng)支持的鑒權(quán)協(xié)議是PAP鑒權(quán)[10]和CHAP鑒權(quán)[11]；否則，跳過本階段直接進(jìn)入下一階段。

第三階段是網(wǎng)絡(luò)控制協(xié)議（NCP，Network Control Protocol）協(xié)商，主要進(jìn)行網(wǎng)絡(luò)層相關(guān)參數(shù)的配置，包括IP地址的分配、TCP/IP頭部壓縮等。本測試系統(tǒng)中具體執(zhí)行IP控制協(xié)議（IPCP，IP Control Protocol）。

測試系統(tǒng)可以以靜態(tài)IP地址或動(dòng)態(tài)IP地址進(jìn)行PDP上下文激活，其通過PEI鏈路與移動(dòng)臺(tái)的交互過程和移動(dòng)臺(tái)通過空中接口與SwMI的交互過程具有對(duì)應(yīng)關(guān)系。

NCP階段完成后，鏈路進(jìn)入可進(jìn)行數(shù)據(jù)通信的“鏈路打開”狀態(tài)，即分組數(shù)據(jù)PDP上下文激活成功。此后，鏈路兩端可以隨時(shí)向?qū)Ψ桨l(fā)送分組數(shù)據(jù)。

測試過程中，測試系統(tǒng)向被測系統(tǒng)發(fā)送承載ICMP報(bào)文的IP數(shù)據(jù)包進(jìn)行數(shù)據(jù)傳輸測試。當(dāng)發(fā)送IP數(shù)據(jù)包時(shí)，IP數(shù)據(jù)包會(huì)被封裝在PPP幀中進(jìn)行傳輸，協(xié)議域?yàn)?x0021（若LCP階段進(jìn)行了協(xié)議域壓縮協(xié)商，則協(xié)議域?yàn)?x21）。

4 測試系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

與C、C++等語言相比較，TTCN-3語言用于開發(fā)測試集具有簡潔便利、層次分明的特點(diǎn)。測試集的開發(fā)與編解碼器、系統(tǒng)適配器等模塊的開發(fā)可以獨(dú)立進(jìn)行，以提高開發(fā)效率。測試系統(tǒng)選用Testing Tech公司的TTworkbench測試平臺(tái)，該平臺(tái)支持使用Java、ASN.1和XML等語言編寫插件，大大提高了測試系統(tǒng)的擴(kuò)展性和靈活性。

借助TTworkbench提供的開發(fā)環(huán)境，本文主要進(jìn)行了以下四個(gè)模塊的開發(fā)工作：測試?yán)═E，TTCN-3 Executable）、編解碼器（CD）模塊、系統(tǒng)適配器（SA）模塊以及平臺(tái)適配器（PA，Platform Adapter）模塊。

4.1 測試?yán)═E）開發(fā)

依據(jù)IOP測試標(biāo)準(zhǔn)，結(jié)合前面的PEI接口協(xié)議分析，測試?yán)幕咎幚砹鞒淘O(shè)計(jì)如圖3所示。其中的后續(xù)操作取決于不同測試?yán)鶞y試的具體內(nèi)容，可能包括PDP上下文去激活模塊、數(shù)據(jù)傳輸模塊等。endprint

整個(gè)處理流程中，最重要的是實(shí)現(xiàn)PPP協(xié)議的兩個(gè)模塊：LCP模塊和IPCP模塊，按照RFC 1661規(guī)定的配置選項(xiàng)進(jìn)行協(xié)商建鏈。

為了提高測試系統(tǒng)的兼容性，使其能夠同時(shí)支持各主流廠商的移動(dòng)臺(tái)，并且盡量減少SA、CD等其他模塊的開發(fā)難度，在測試?yán)_發(fā)中重點(diǎn)解決了以下幾個(gè)問題：

（1）進(jìn)行“ATD*99#”撥號(hào)后，各廠商移動(dòng)臺(tái)的響應(yīng)是不同的。SEPURA移動(dòng)臺(tái)完全符合TETRA協(xié)議，撥號(hào)后測試系統(tǒng)收到移動(dòng)臺(tái)發(fā)出的CONNECT命令，然后開始LCP階段；MOTOROLA移動(dòng)臺(tái)撥號(hào)后，測試系統(tǒng)先收到一系列字符串，之后才收到CONNECT命令，然后還要再收到OK命令后才能開始LCP階段；EADS移動(dòng)臺(tái)撥號(hào)后先收到CONNECT命令，然后收到OK命令后才開始LCP階段。為了使測試?yán)軌蛲瑫r(shí)支持三個(gè)廠商的移動(dòng)臺(tái)，筆者專門設(shè)計(jì)了一個(gè)altstep函數(shù)，在撥號(hào)之后自動(dòng)調(diào)用該函數(shù)以解決此問題。

（2）按照協(xié)議規(guī)定，測試系統(tǒng)和移動(dòng)臺(tái)分別向?qū)Ψ桨l(fā)出LCP協(xié)商請求，是相互獨(dú)立的過程，沒有先后順序。若測試系統(tǒng)先發(fā)送LCP配置請求幀，則會(huì)收到移動(dòng)臺(tái)對(duì)此LCP請求的響應(yīng)幀以及移動(dòng)臺(tái)的LCP配置請求幀。在使用SEPURA移動(dòng)臺(tái)測試時(shí)，發(fā)現(xiàn)其兩個(gè)連續(xù)的LCP數(shù)據(jù)幀之間會(huì)省略一個(gè)幀界定符（0x7E），導(dǎo)致CD模塊解碼時(shí)崩潰。為了不增加CD模塊的設(shè)計(jì)難度，測試?yán)胁捎玫姆桨甘牵簻y試系統(tǒng)等待收到移動(dòng)臺(tái)發(fā)出的LCP配置請求幀后，再發(fā)送LCP配置請求。

（3）按照TTCN-3標(biāo)準(zhǔn)，CD模塊并不具有記憶功能，如果在LCP階段進(jìn)行了協(xié)議域壓縮（PFC）的協(xié)商，則需要編寫支持壓縮和不支持壓縮兩個(gè)不同的CD模塊來支持，這會(huì)增加CD的開發(fā)難度。因此，測試?yán)性贚CP階段不進(jìn)行此項(xiàng)協(xié)商，以簡化CD模塊的開發(fā)。

（4）如果在LCP階段進(jìn)行了異步控制字符映射（ACCM）協(xié)商，由于不同移動(dòng)臺(tái)的ACCM協(xié)商結(jié)果可能不同，因此需要編寫不同的CD模塊才能實(shí)現(xiàn)相應(yīng)處理。為了簡化CD模塊開發(fā)，采取的方案是測試系統(tǒng)不主動(dòng)發(fā)起ACCM協(xié)商，而對(duì)于移動(dòng)臺(tái)主動(dòng)發(fā)起的ACCM協(xié)商總是確認(rèn)。這樣，無論移動(dòng)臺(tái)是否進(jìn)行了ACCM協(xié)商，僅需要開發(fā)一個(gè)CD模塊，按照RFC 1662的規(guī)定進(jìn)行轉(zhuǎn)義操作，就可以完成數(shù)據(jù)的正常發(fā)送與接收。

（5）為了簡化設(shè)計(jì)，在IPCP階段，只接受IP地址的協(xié)商配置，而忽略其他選項(xiàng)的協(xié)商。具體設(shè)計(jì)是測試系統(tǒng)收到移動(dòng)臺(tái)IPCP配置請求時(shí)，判斷其中是否有IP協(xié)商之外的選項(xiàng)，若存在，對(duì)其回復(fù)拒絕幀；當(dāng)只存在IP配置選項(xiàng)時(shí)，才回復(fù)確認(rèn)幀。這樣的設(shè)計(jì)能夠降低CD模塊的開發(fā)難度和工作量。

4.2 編解碼器（CD）模塊開發(fā)

編解碼模塊主要是對(duì)測試系統(tǒng)和被測系統(tǒng)之間傳輸?shù)臏y試數(shù)據(jù)進(jìn)行編碼與解碼轉(zhuǎn)換。TTCN-3測試?yán)卸x的數(shù)據(jù)類型都需要開發(fā)相應(yīng)的CD模塊實(shí)現(xiàn)編解碼功能。分組數(shù)據(jù)互操作性測試中所涉及的數(shù)據(jù)類型有AT指令、PPP協(xié)議中的各種數(shù)據(jù)結(jié)構(gòu)、IPv4協(xié)議數(shù)據(jù)包以及ICMP協(xié)議數(shù)據(jù)包等。

4.3 系統(tǒng)適配器（SA）模塊開發(fā)

系統(tǒng)適配器模塊用來實(shí)現(xiàn)測試系統(tǒng)與被測系統(tǒng)之間的通信過程，在SA中可以調(diào)用TRI接口所提供的API函數(shù)。測試中的PEI接口采用的是RS232串口形式，所以使用了TTworkbench提供的RS232插件。TTworkbench支持在SA模塊中加入用戶開發(fā)的端口過濾器（Port Filter），可以在標(biāo)準(zhǔn)的RS232插件處理之前對(duì)輸入輸出數(shù)據(jù)進(jìn)行相應(yīng)的過濾操作，具有很強(qiáng)的靈活性與便利性。本測試系統(tǒng)中，發(fā)送數(shù)據(jù)時(shí)端口過濾器完成對(duì)數(shù)據(jù)的封裝處理，包括使用CRC算法計(jì)算FCS、添加地址和控制域及添加幀定界符等。接收數(shù)據(jù)時(shí)完成對(duì)數(shù)據(jù)的提取處理，包括以上封裝處理的逆處理。

例如，在LCP協(xié)商階段，測試?yán)惺褂肨TCN-3語言編寫的數(shù)據(jù)結(jié)構(gòu)首先經(jīng)過CD編碼后成為二進(jìn)制數(shù)據(jù)流：C0 21 01 01 00 14 02 06 00 00 00 00 05 06 2F 5A 60 7C 07 02 08 02，然后傳送至SA的端口過濾器中進(jìn)行處理，具體步驟如下：

（1）加上地址和控制域：FF 03 C0 21 01 01 00 14 02 06 00 00 00 00 05 06 2F 5A 60 7C 07 02 08 02

（2）計(jì)算FCS并添加到數(shù)據(jù)末尾，F(xiàn)CS的低字節(jié)在前，高字節(jié)在后：FF 03 C0 21 01 01 00 14 02 06 00 00 00 00 05 06 2F 5A 60 7C 07 02 08 02 87 68

（3）掃描整個(gè)序列，進(jìn)行轉(zhuǎn)義處理：FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 2F 5A 60 7C 7D 27 7D 22 7D 28 7D 22 87 68

（4）在數(shù)據(jù)首尾添加幀界定符7E組成PPP幀，發(fā)送：7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 2F 5A 60 7C 7D 27 7D 22 7D 28 7D 22 87 68 7E

4.4 平臺(tái)適配器（PA）模塊開發(fā)

TTCN-3語言的優(yōu)勢在于對(duì)系統(tǒng)測試的描述與交互，但是使用其來編寫涉及數(shù)學(xué)運(yùn)算的程序會(huì)比較困難。因此，筆者在平臺(tái)適配器模塊中編寫了外部函數(shù)，專門實(shí)現(xiàn)各種算法，然后在測試?yán)姓{(diào)用這些外部函數(shù)來實(shí)現(xiàn)所需要的功能。

分組數(shù)據(jù)互操作性測試中所涉及的外部函數(shù)主要包括PPP幀長度的計(jì)算、CHAP鑒權(quán)所需要的MD5算法、IPv4包中的首部校驗(yàn)和計(jì)算以及ICMP中的校驗(yàn)和計(jì)算等。endprint

5 測試結(jié)果

根據(jù)測試標(biāo)準(zhǔn)TTR001-05和IOP001-05，筆者開發(fā)了全部27個(gè)測試?yán)?。由于目前的移?dòng)臺(tái)和網(wǎng)絡(luò)設(shè)備不支持標(biāo)準(zhǔn)中的部分功能，因此對(duì)其中的19個(gè)測試?yán)M(jìn)行了實(shí)際測試驗(yàn)證。

測試中使用的移動(dòng)臺(tái)包括MOTOROLA、SEPURA和EADS三家廠商的移動(dòng)臺(tái)，網(wǎng)絡(luò)設(shè)備采用北京理工大學(xué)和北京交通大學(xué)聯(lián)合研制的TETRA基站和交換機(jī)系統(tǒng)。測試系統(tǒng)運(yùn)行平臺(tái)為Windows XP系統(tǒng)和TTworkbench v14。

圖4是按照IOP 001-05標(biāo)準(zhǔn)中測試?yán)?.3.1的要求設(shè)計(jì)的測試?yán)倪\(yùn)行結(jié)果（LCP協(xié)商部分）。該測試?yán)〒芴?hào)、LCP協(xié)商、IPCP協(xié)商、數(shù)據(jù)傳輸和去激活的完整過程，具有很強(qiáng)的代表性。整個(gè)測試過程都是TTCN-3程序自動(dòng)完成的，無需人工操作，測試完成后立刻得到測試是否通過的結(jié)果，完全達(dá)到了預(yù)期目的。

6 結(jié)束語

本文提出了一種基于TTCN-3語言的TETRA協(xié)議互操作性測試的設(shè)計(jì)方案，按照此方案設(shè)計(jì)的測試系統(tǒng)已經(jīng)投入實(shí)際使用。文中所提出的PPP協(xié)議處理方法不僅可以用于TETRA系統(tǒng)，也可以應(yīng)用于其他移動(dòng)通信系統(tǒng)的分組數(shù)據(jù)測試。本測試系統(tǒng)既可以用于協(xié)議一致性或者互操作性的測試，也可以加以擴(kuò)展用于系統(tǒng)的壓力測試、性能測試和生產(chǎn)測試等諸多領(lǐng)域。

參考文獻(xiàn)：

[1] ETSI EN 300 392-2 V3.4.0. Terrestrial Trunked Radio（TETRA）； Voice plus Data（V+D）； Part 2： Air Interface（AI）[S]. ETSI. 2010.

[2] ETSI ES 201 873-1 V4.2.1. Methods for Testing and Specification（MTS）； The Testing and Test Control Notation version 3； Part 1： TTCN-3 Core Language[S]. ETSI. 2010.

[3] TTR 001-05 V3.0.0. TETRA Association； TETRA Interoperability Profile（TIP） Part 5： Packet Data[R]. TETRA Association Technical Forum. 2008.

[4] IOP 001-05 V3.0.5. TETRA Association TETRA V+D TIP Compliance Test Plan IOP 001-05 for testing of V+D TIP Part 05 Packet Data（TTR 001-05）[R]. TETRA Association Technical Forum. 2010.

[5] 陳元，尹霞，王之梁. 基于TTCN-3的LDP一致性測試研究[J]. 計(jì)算機(jī)應(yīng)用研究， 2009，26（1）： 286-288.

[6] 詹寶容，庾錫昌. 基于TTCN-3的移動(dòng)業(yè)務(wù)測試平臺(tái)的設(shè)計(jì)[J]. 計(jì)算機(jī)工程與設(shè)計(jì)， 2011，32（16）： 1893-1897.

[7] 文霄，高阜鄉(xiāng)，賴旻. 基于TTCN-3同步擴(kuò)展的協(xié)議一致性測試研究[J]. 電腦知識(shí)與技術(shù)， 2011，7（1）： 63-65.

[8] RFC 1661. The Point-to-Point Protocol（PPP）[S]. Network Working Group. 1994.

[9] RFC 1662. PPP in HDLC-like Framing[S]. Network Working Group. 1994.

[10] RFC 1334. PPP Authentication Protocols[S]. Network Working Group. 1992.

[11] RFC 1994. PPP Challenge Handshake Authentication Protocol（CHAP）[S]. Network Working Group. 1996.★endprint

5 測試結(jié)果

根據(jù)測試標(biāo)準(zhǔn)TTR001-05和IOP001-05，筆者開發(fā)了全部27個(gè)測試?yán)?。由于目前的移?dòng)臺(tái)和網(wǎng)絡(luò)設(shè)備不支持標(biāo)準(zhǔn)中的部分功能，因此對(duì)其中的19個(gè)測試?yán)M(jìn)行了實(shí)際測試驗(yàn)證。

測試中使用的移動(dòng)臺(tái)包括MOTOROLA、SEPURA和EADS三家廠商的移動(dòng)臺(tái)，網(wǎng)絡(luò)設(shè)備采用北京理工大學(xué)和北京交通大學(xué)聯(lián)合研制的TETRA基站和交換機(jī)系統(tǒng)。測試系統(tǒng)運(yùn)行平臺(tái)為Windows XP系統(tǒng)和TTworkbench v14。

圖4是按照IOP 001-05標(biāo)準(zhǔn)中測試?yán)?.3.1的要求設(shè)計(jì)的測試?yán)倪\(yùn)行結(jié)果（LCP協(xié)商部分）。該測試?yán)〒芴?hào)、LCP協(xié)商、IPCP協(xié)商、數(shù)據(jù)傳輸和去激活的完整過程，具有很強(qiáng)的代表性。整個(gè)測試過程都是TTCN-3程序自動(dòng)完成的，無需人工操作，測試完成后立刻得到測試是否通過的結(jié)果，完全達(dá)到了預(yù)期目的。

6 結(jié)束語

本文提出了一種基于TTCN-3語言的TETRA協(xié)議互操作性測試的設(shè)計(jì)方案，按照此方案設(shè)計(jì)的測試系統(tǒng)已經(jīng)投入實(shí)際使用。文中所提出的PPP協(xié)議處理方法不僅可以用于TETRA系統(tǒng)，也可以應(yīng)用于其他移動(dòng)通信系統(tǒng)的分組數(shù)據(jù)測試。本測試系統(tǒng)既可以用于協(xié)議一致性或者互操作性的測試，也可以加以擴(kuò)展用于系統(tǒng)的壓力測試、性能測試和生產(chǎn)測試等諸多領(lǐng)域。

參考文獻(xiàn)：

[1] ETSI EN 300 392-2 V3.4.0. Terrestrial Trunked Radio（TETRA）； Voice plus Data（V+D）； Part 2： Air Interface（AI）[S]. ETSI. 2010.

[2] ETSI ES 201 873-1 V4.2.1. Methods for Testing and Specification（MTS）； The Testing and Test Control Notation version 3； Part 1： TTCN-3 Core Language[S]. ETSI. 2010.

[3] TTR 001-05 V3.0.0. TETRA Association； TETRA Interoperability Profile（TIP） Part 5： Packet Data[R]. TETRA Association Technical Forum. 2008.

[4] IOP 001-05 V3.0.5. TETRA Association TETRA V+D TIP Compliance Test Plan IOP 001-05 for testing of V+D TIP Part 05 Packet Data（TTR 001-05）[R]. TETRA Association Technical Forum. 2010.

[5] 陳元，尹霞，王之梁. 基于TTCN-3的LDP一致性測試研究[J]. 計(jì)算機(jī)應(yīng)用研究， 2009，26（1）： 286-288.

[6] 詹寶容，庾錫昌. 基于TTCN-3的移動(dòng)業(yè)務(wù)測試平臺(tái)的設(shè)計(jì)[J]. 計(jì)算機(jī)工程與設(shè)計(jì)， 2011，32（16）： 1893-1897.

[7] 文霄，高阜鄉(xiāng)，賴旻. 基于TTCN-3同步擴(kuò)展的協(xié)議一致性測試研究[J]. 電腦知識(shí)與技術(shù)， 2011，7（1）： 63-65.

[8] RFC 1661. The Point-to-Point Protocol（PPP）[S]. Network Working Group. 1994.

[9] RFC 1662. PPP in HDLC-like Framing[S]. Network Working Group. 1994.

[10] RFC 1334. PPP Authentication Protocols[S]. Network Working Group. 1992.

[11] RFC 1994. PPP Challenge Handshake Authentication Protocol（CHAP）[S]. Network Working Group. 1996.★endprint

5 測試結(jié)果

根據(jù)測試標(biāo)準(zhǔn)TTR001-05和IOP001-05，筆者開發(fā)了全部27個(gè)測試?yán)Ｓ捎谀壳暗囊苿?dòng)臺(tái)和網(wǎng)絡(luò)設(shè)備不支持標(biāo)準(zhǔn)中的部分功能，因此對(duì)其中的19個(gè)測試?yán)M(jìn)行了實(shí)際測試驗(yàn)證。

測試中使用的移動(dòng)臺(tái)包括MOTOROLA、SEPURA和EADS三家廠商的移動(dòng)臺(tái)，網(wǎng)絡(luò)設(shè)備采用北京理工大學(xué)和北京交通大學(xué)聯(lián)合研制的TETRA基站和交換機(jī)系統(tǒng)。測試系統(tǒng)運(yùn)行平臺(tái)為Windows XP系統(tǒng)和TTworkbench v14。

圖4是按照IOP 001-05標(biāo)準(zhǔn)中測試?yán)?.3.1的要求設(shè)計(jì)的測試?yán)倪\(yùn)行結(jié)果（LCP協(xié)商部分）。該測試?yán)〒芴?hào)、LCP協(xié)商、IPCP協(xié)商、數(shù)據(jù)傳輸和去激活的完整過程，具有很強(qiáng)的代表性。整個(gè)測試過程都是TTCN-3程序自動(dòng)完成的，無需人工操作，測試完成后立刻得到測試是否通過的結(jié)果，完全達(dá)到了預(yù)期目的。

6 結(jié)束語

本文提出了一種基于TTCN-3語言的TETRA協(xié)議互操作性測試的設(shè)計(jì)方案，按照此方案設(shè)計(jì)的測試系統(tǒng)已經(jīng)投入實(shí)際使用。文中所提出的PPP協(xié)議處理方法不僅可以用于TETRA系統(tǒng)，也可以應(yīng)用于其他移動(dòng)通信系統(tǒng)的分組數(shù)據(jù)測試。本測試系統(tǒng)既可以用于協(xié)議一致性或者互操作性的測試，也可以加以擴(kuò)展用于系統(tǒng)的壓力測試、性能測試和生產(chǎn)測試等諸多領(lǐng)域。

參考文獻(xiàn)：

[1] ETSI EN 300 392-2 V3.4.0. Terrestrial Trunked Radio（TETRA）； Voice plus Data（V+D）； Part 2： Air Interface（AI）[S]. ETSI. 2010.

[2] ETSI ES 201 873-1 V4.2.1. Methods for Testing and Specification（MTS）； The Testing and Test Control Notation version 3； Part 1： TTCN-3 Core Language[S]. ETSI. 2010.

[3] TTR 001-05 V3.0.0. TETRA Association； TETRA Interoperability Profile（TIP） Part 5： Packet Data[R]. TETRA Association Technical Forum. 2008.

[4] IOP 001-05 V3.0.5. TETRA Association TETRA V+D TIP Compliance Test Plan IOP 001-05 for testing of V+D TIP Part 05 Packet Data（TTR 001-05）[R]. TETRA Association Technical Forum. 2010.

[5] 陳元，尹霞，王之梁. 基于TTCN-3的LDP一致性測試研究[J]. 計(jì)算機(jī)應(yīng)用研究， 2009，26（1）： 286-288.

[6] 詹寶容，庾錫昌. 基于TTCN-3的移動(dòng)業(yè)務(wù)測試平臺(tái)的設(shè)計(jì)[J]. 計(jì)算機(jī)工程與設(shè)計(jì)， 2011，32（16）： 1893-1897.

[7] 文霄，高阜鄉(xiāng)，賴旻. 基于TTCN-3同步擴(kuò)展的協(xié)議一致性測試研究[J]. 電腦知識(shí)與技術(shù)， 2011，7（1）： 63-65.

[8] RFC 1661. The Point-to-Point Protocol（PPP）[S]. Network Working Group. 1994.

[9] RFC 1662. PPP in HDLC-like Framing[S]. Network Working Group. 1994.

[10] RFC 1334. PPP Authentication Protocols[S]. Network Working Group. 1992.

[11] RFC 1994. PPP Challenge Handshake Authentication Protocol（CHAP）[S]. Network Working Group. 1996.★endprint