TD-SCDMA測試儀中Iub接口CDR的合成方案
引言
本文引用地址:http://cafeforensic.com/article/193477.htm隨著有中國自主知識產(chǎn)權(quán)的第三代移動通信標準TD-SCDMA商用網(wǎng)測試日趨完成,大規(guī)模的3G網(wǎng)絡即將在全國各地組建,作為組網(wǎng)的重要支撐技術(shù),測試儀的開發(fā)顯得非常重要。
對網(wǎng)絡故障進行快速診斷并降低網(wǎng)絡中斷時間是3G信令測試系統(tǒng)的主要用途之一。當3G系統(tǒng)發(fā)生故障時,需要使用測試設備接入關(guān)鍵的信令鏈路監(jiān)測點,并進行協(xié)議測試和分析。通常來說,通用移動通信系統(tǒng)(universal mobile telecommuniCAtion system,UMTS)網(wǎng)絡故障主要可分為2大類:UMTS的陸地無線接入網(wǎng)絡(UMTS terrestrial radio access network,UTRAN)側(cè)故障和核心網(wǎng)(core network,CN)側(cè)故障。由于3GPP R4(Release 4)UTRAN的網(wǎng)絡結(jié)構(gòu)和協(xié)議同GSM系統(tǒng)相比有了較大變化,因此比較容易出現(xiàn)問題;而R4核心網(wǎng)和GSM系統(tǒng)基本相同,因此出現(xiàn)問題的概率相對較小。由于Iub和Iu接口是UTRAN中最重要的測試接口,一般來說需要同時對這2個接口進行數(shù)據(jù)采集和關(guān)聯(lián)性分析[1-3]。
若要有效地診斷3G網(wǎng)
絡故障,網(wǎng)絡工程師需要對UMTS各接口和相關(guān)協(xié)議有較全面和深入的理解,這樣才能迅速找到存在的問題,并對其中的關(guān)鍵字段進行分析。所有這些工作,都離不開一臺具備全面解碼、呼叫跟蹤和統(tǒng)計功能的3G信令測試設備的配合。
CDR(call data record)在PSTN中表示呼叫數(shù)據(jù)記錄,現(xiàn)在延伸意思為一個完整的流程,CDR合成是上述功能的基礎,對網(wǎng)絡中消息按信令流程進行歸類,并用索引方式把這些消息聯(lián)系到一起,然后才便于完成諸如呼叫跟蹤和呼損統(tǒng)計等高級功能[4-5]。
我們在本文中將以TD-SCDMA UTRAN中Iub接口間的各個協(xié)議的CDR合成,多協(xié)議關(guān)聯(lián)為例,對CDR合成的方法進行描述。該方法同樣實用于WCDMA系統(tǒng)。
1、Iub接口中的信令消息
圖1為Iub接口中協(xié)議的關(guān)系圖。Iub接口協(xié)議棧包含3個協(xié)議平面,分別是無線網(wǎng)絡控制平面、傳輸網(wǎng)絡控制平面和用戶平面,分別對應3個協(xié)議的信令流程,即NBAP(Node B application part,Node B應用部分)、ALCAP(access link control application protocol,接入層鏈路控制應用協(xié)議)、Iub FP(frame protocol)消息[6]。FP所承載的協(xié)議包括無線資源控制(radio resource control,RRC),包數(shù)據(jù)集中協(xié)議(packet data convergence protocol,PDCP)等。這3個協(xié)議有著緊密的聯(lián)系,當無線網(wǎng)絡控制器(radio network controller,RNC)發(fā)起傳輸信道管理或者無線連接管理相關(guān)過程的時候,是通過NBAP協(xié)議的相關(guān)過程來實現(xiàn),比如Common Transport Channel Setup,Radio Link Setup,Radio Link Addition等。但同時需要對用戶平面鏈路進行分配或刪除,在Iub接口上,用戶數(shù)據(jù)(FP)通過ATM結(jié)構(gòu)中的AAL2傳送,此時需要建立控制機制,ALCAP定義了與用戶面建立、釋放傳輸承載的方式,因此需要ALCAP協(xié)議來完成這些操作。一般情況下,如果不涉及到用戶平面時,Iub接口中就只有NBAP過程的消息。當涉及到用戶平面的時候,情況要復雜得多[7]。
圖1 Iub接口協(xié)議關(guān)系圖
Fig.1 Relation graph of Iub interface
RNC在以下2種情況下將涉及到用戶平面的操作:一種是對小區(qū)的公共傳輸信道做操作的時候;另一種是為UE提供專用信道的時候。在對傳輸信道做操作的過程中,用戶平面只有FP同步消息,不會有RRC消息。當RNC涉及到對UE操作時候,需要先在RNC和UE之間建立一個無線連接(RRC連接),建立過程大致如下:UE先向RNC請求建立RRC連接,RNC收到請求后根據(jù)具體情況選擇是否為該UE建立專用信道。如果要建立專用信道(dedicated channel,DCH),RNC將通過NBAP協(xié)議請求建立無線鏈路或者重配置無線鏈路,Node B成功應答后,RNC將通過ALCAP協(xié)議分配DCH所需的AAL2鏈路,成功分配后RNC通過前向接入信道(forward access channel,F(xiàn)ACH)發(fā)送RRC建立成功消息。如果不需要為該UE建立專用信道,那么就沒有上述NBAP和ALCAP過程,RNC將直接通過FACH發(fā)送RRC建立成功消息,該消息將指示UE只能
通過公共傳輸信道傳輸所有的消息給RNC。圖2顯示了Iub接口中可能會出現(xiàn)的消息種類。
圖2 Iub接口中所包含消息
Fig.2 Messages in Iub interface
至此,可歸納出Iub接口的流程大致有4類:
①純NBAP過程;
②NBAP過程+ALCAP過程+FP(公共傳輸信道,同步消息);
③NBAP過程+ALCAP過程+FP(DCH,包括同步消息和RRC消息);
④RRC過程(公共信道傳輸,共享信道傳輸)。
其中②和③可以歸為一類處理。不難看出,Iub接口的CDR合成可先按NBAP,ALCAP,F(xiàn)P,RRC消息合成,然后再進行多協(xié)議的關(guān)聯(lián)。雖然RRC是在FP之上的,但一個RRC流程的消息可能會出現(xiàn)在多個FP里面,所以這里將兩者進行了區(qū)分。
2、Iub接口CDR合成基本原理和實現(xiàn)算法
下面以上節(jié)中流程類型③(NBAP過程+ALCAP過程+FP)的消息合成進行詳細介紹,因為這是最復雜的一類,對該類型
的CDR合成方法包含了其它3種類型的CDR合成方法。具體又以移動發(fā)起呼叫(mobile oriented call,MOC)為例(見圖3),對RRC建立連接,以及怎樣實現(xiàn)NBAP,ALCAP,F(xiàn)P,RRC的消息合成,多協(xié)議關(guān)聯(lián)等基本原理進行了描述。
圖3 MOC消息流前面部分
Fig.3 Message flow.of MOC
如圖3所示,虛線上面消息流程為RRC建立過程部分,也將是CDR合成的主要部分。首先UE通過RACH隨機接入信道發(fā)送rrcConnectionRequest消息請求建立RRC連接,該消息中包含IMSI/TMSI和建立原因參數(shù),RNC收到請求后發(fā)起無線鏈路建立請求intiatingMessage Id-radioLinkSetup(如果已經(jīng)建立了無線鏈路,將發(fā)起無線鏈路資源重配置請求),NodeB通過successfulOutcome ID-radioLinkSetup確認請求后,RNC將為UE分配DCH專用信道,即調(diào)用ALCAP協(xié)議分配AAL2鏈路來承載DCH,DCH經(jīng)過同步后,所有該UE的RRC消息將在該DCH上傳輸。成功分配后,RNC發(fā)起rrcConnectionSetup建立RRC連接,NodeB通過rrcConnectionSetupComplete確認,至此,RRC建立成功,NAS(Non-Access Stratum,非接入層)消息將通過RRC消息封裝發(fā)送到RNC,再經(jīng)過Iu接口發(fā)送到MSC。
對Iub接口的各協(xié)議關(guān)聯(lián)方法說明如下(參見圖3各連接箭頭的指示,暫不考慮NAS消息的合成):
●NBAP消息關(guān)聯(lián):同一過程的NBAP消息用消息中Transaction ID參數(shù)進行關(guān)聯(lián),涉及同一個UE的不同NB·AP過程之間的消息用Id-CRNC-CommunicationContextID參數(shù)進行關(guān)聯(lián)。
●ALCAP消息關(guān)聯(lián):一個流程的ACLAP消息可通過OSAID和DSAID參數(shù)進行關(guān)聯(lián)。
●RRC消息關(guān)聯(lián):同一過程的RRC消息可通過RRC Transaction ID進行關(guān)聯(lián),同一個UE的RRC消息可通過I·MSI/TMSI進行關(guān)聯(lián)。在公共傳輸信道中的RRC消息可以根據(jù)MAC中UEID來區(qū)分是否屬于同一個UE。
Iub接口的多協(xié)議關(guān)聯(lián)如下(參見圖3各連接箭頭的指示):
●NBAP消息和RRC消息關(guān)聯(lián):TDD模式中通過Time Slots和User Codes進行關(guān)聯(lián),F(xiàn)DD模式下通過Scrambling code進行關(guān)聯(lián)。
●NBAP消息和ALCAP消息關(guān)聯(lián):通過NBAP消息中的BindingID參數(shù)值與ALCAP的ERQ消息中的SUGR參數(shù)值相等的方法進行關(guān)聯(lián)。
●ALCAP消息和RRC(DCH中的)消息關(guān)聯(lián):通過承載RRC消息中DCH信道的VPI/VCI/CID與ALCAP的ERQ消息中的PathID(VPI/VCI經(jīng)過換算等于PathID),ChannelID(CID=ChannelID)進行關(guān)聯(lián)。
按照上述先對各個協(xié)議進行合成,然后協(xié)議之間進行合成,協(xié)議間合成按一定的時間周期進行,最后得到的結(jié)果便是所需的Iub接口CDR信息。
3、Iub接口CDR合成算法分析
該CDR合成算法主要是根據(jù)一些關(guān)鍵參數(shù)進行查找、匹配來確定是否屬于同一個消息流程,因此在這個過程中,需要一些臨時存儲方式來保存沒有匹配到的消息,在內(nèi)存分配上比較復雜,涉及動態(tài)分配內(nèi)存。另外,該合成算法涉及大量的查找、匹配,所以需要建立許多方便查找的索引,比較好地建立索引方法顯得至關(guān)重要,但是建立這些索引也是要耗費時間的,所以根據(jù)具體情況應使用具體的索引建立方法,我們在設計過程中除了平衡二叉樹以外也曾采用其它索引建立方法,比如二叉樹,哈希表等。
協(xié)議間合成是定期執(zhí)行的操作,時間周期的長短選擇也將影響合成的效率。如果間隔時間太短,每關(guān)聯(lián)一次完成的流程很少,同時也耗費了時間;時間太長了缺乏實時性。而我們采用的是多線程的方式單獨用一個線程來完成多協(xié)議關(guān)聯(lián),效果非常好。圖4為該方法應用到TD-SCDMA網(wǎng)絡測試儀中的執(zhí)行結(jié)果。
圖4 結(jié)果顯示
Fig.4 Result display
4、結(jié)束語
通過對Iub接口各消息流程的深入分析和研究,結(jié)合Iu接口,使用C++語言進行編碼測試,能很好地達到CDR合成的效果,實現(xiàn)多協(xié)議乃至多接口間的協(xié)議關(guān)聯(lián)。該程序模塊已經(jīng)應用到重慶郵電大學通信網(wǎng)與測試技術(shù)重點實驗室TD-SCDMA網(wǎng)絡測試儀中,效果
良好。
參考文獻:
[1] 3GPP TS 25.401 V5.9.0.UTRAN overall descrIPtion [EB/OL].(2003-09-20)[2006-05-30].http://WWW.3gpp.org/ftp/Specs/2004-09/Rel-5/25_series/25401-590.zip.
[2] 3GPP TS 25.430 V4.4.0.UTRAN Iub Interface:General Aspects and Principles [EB/OL].(2002-09-18)[2006-05-30].http://WWW.3gpp.org/ftp/specs/2004-09/Rel-4/25_series/25430-490.zip.
[3] 李小文,李貴勇,陳賢亮,等.TD-SCDMA第三代移動通信系統(tǒng)、信令及實現(xiàn)[M].北京:人民郵電出版社,2003.
[4] 張毅.鮮繼清.TD-SCDMA信令測試軟件設計方案[J].重慶郵電學院學報(自然科學版).2003,15(1):32-34.
[5] 劉偉.張治中.TD-SCDMA網(wǎng)絡測試儀IP數(shù)據(jù)采集卡的研制[J].重慶郵電學院學報(自然科學版).2005,17(6):853 856.
[6] 3GPP TR 25.931 V4.4.0.UTRAN functions,examples on signalling procedures[EB/OL].(2002-06-18)[2006-05-30].http://WWW.arib.or.jp/IMT-2000/V310Sep02/S3g/R99/25/25931-370.pdf.
[7] ITU-T Q2630.1.AAL type 2 signalling protocol-Capability Set 1[EB/OL].(1999-12-20)[2006-05-30].http://WWW.itu.int/rec/T-REC-Q.2630.1/en.
評論