TD-SCDMA測(cè)試儀中Iub接口實(shí)現(xiàn)RLC層信令解碼

摘要　為了更精確地完成TD-SCDMA測(cè)試儀中相關(guān)信令的解碼測(cè)試工作，對(duì)TD-SCDMA系統(tǒng)的Uu接口RLC層信令在Iub接口實(shí)現(xiàn)的解碼進(jìn)行了深入分析和研究，給出了RLC層的信令消息結(jié)構(gòu)和流程，提出了RLC解碼的一種算法，并且應(yīng)用到TD-SCDMA測(cè)試儀中，經(jīng)調(diào)試并實(shí)際測(cè)試后，得到了預(yù)期的良好效果。經(jīng)過(guò)再改進(jìn)，完全可以滿足市場(chǎng)需要。

0、引言

TD-SCDMA系統(tǒng)作為第三代移動(dòng)通信系統(tǒng)的主流標(biāo)準(zhǔn)之一，受到了全球研究學(xué)者、移動(dòng)通信運(yùn)營(yíng)廠商和廣大用戶的密切關(guān)注，具有廣闊的發(fā)展前景[1]。TD-SCDMA于2000年5月在土耳其召開(kāi)的國(guó)際電聯(lián)2000年全會(huì)上被批準(zhǔn)為國(guó)際電聯(lián)的正式標(biāo)準(zhǔn)后，經(jīng)過(guò)幾年的發(fā)展，無(wú)論在形式上還是在實(shí)質(zhì)上，都已在國(guó)際上被廣大運(yùn)營(yíng)商、設(shè)備制造商所認(rèn)可和接收。TD-SCDMA系統(tǒng)綜合了4種多址方式：TDMA，F(xiàn)DMA，CDMA和SDMA，采用了6大關(guān)鍵技術(shù)：智能天線、聯(lián)合檢測(cè)、接力切換、上行同步及動(dòng)態(tài)信道分配和軟件無(wú)線電。通過(guò)這些技術(shù)[2-7]極大地降低了系統(tǒng)的干擾，擴(kuò)大了系統(tǒng)的容量，提高了頻譜的利用率，同時(shí)也節(jié)省了系統(tǒng)的成本開(kāi)支。在中國(guó)，用TD-SCDMA標(biāo)準(zhǔn)組建第三代移動(dòng)通信運(yùn)營(yíng)網(wǎng)的呼聲更是越來(lái)越高。TD-SCDMA網(wǎng)絡(luò)的大規(guī)模建設(shè)已經(jīng)迫在眉睫。作為組網(wǎng)的重要支撐技術(shù)的測(cè)試儀的開(kāi)發(fā)顯得異常重要。

針對(duì)這種情況，重慶郵電大學(xué)在對(duì)TD-SCDMA技術(shù)充分研究的基礎(chǔ)上，研制出了具有自主知識(shí)產(chǎn)權(quán)的TD-SCDMA移動(dòng)通信網(wǎng)絡(luò)測(cè)試儀，完善了TD-SCDMA產(chǎn)業(yè)鏈，并形成系列產(chǎn)品并推向市場(chǎng)。TD-SCDMA網(wǎng)絡(luò)測(cè)試儀提供了強(qiáng)大的分析、統(tǒng)計(jì)和處理功能，支持UMTS R99，R4，R5等多種版本網(wǎng)絡(luò)的信令及業(yè)務(wù)分析，提供協(xié)議解碼、通用指標(biāo)統(tǒng)計(jì)、呼損分析、呼叫追蹤、多接口關(guān)聯(lián)分析以及協(xié)議仿真測(cè)試等功能，是移動(dòng)無(wú)線網(wǎng)、接入網(wǎng)及SS #7網(wǎng)絡(luò)設(shè)備研發(fā)、網(wǎng)絡(luò)組建、網(wǎng)絡(luò)維護(hù)、網(wǎng)絡(luò)優(yōu)化、網(wǎng)絡(luò)安全、運(yùn)營(yíng)決策及增值應(yīng)用的實(shí)用工具。

1、Iub接口RLC層消息

TD-SCDMA系統(tǒng)中Node B和RNC（無(wú)線網(wǎng)絡(luò)控制）的接口，即Iub接口[3]，用來(lái)傳輸RNC和Node-B之間的信令和無(wú)線接口的數(shù)據(jù)，它的協(xié)議棧是典型的三平面表示法[4]：無(wú)線網(wǎng)絡(luò)層、傳輸網(wǎng)絡(luò)層和物理層。無(wú)線網(wǎng)絡(luò)層由控制平面的NBAP和用戶平面的幀協(xié)議（FP）組成；傳輸網(wǎng)絡(luò)層目前采用ATM傳輸；物理層可以使用E1\T1\STM-1等多種接口，目前常用的是E1和STM-1。Iub接口主要功能為：Iub傳輸資源管理、Node-B的管理與維護(hù)、系統(tǒng)信息管理、公共信道業(yè)務(wù)管理、專用信道業(yè)務(wù)管理、共享信道業(yè)務(wù)管理、定時(shí)與同步管理、數(shù)據(jù)傳輸?shù)�。Iub接口在網(wǎng)絡(luò)中的位置相當(dāng)于GSM中的Abis接口。在現(xiàn)行的第三代移動(dòng)通信系統(tǒng)標(biāo)準(zhǔn)中，Iub接口沒(méi)有象Iur接口和Iu接口一樣做成完全開(kāi)放的接口。

在協(xié)議禎（FP）[8]傳輸?shù)腞RC消息數(shù)據(jù)被添加了MAC頭、RLC頭，還有可能被分段或者串接等，因而對(duì)于信令數(shù)據(jù)而言，只有除去了MAC頭、RLC頭，并經(jīng)過(guò)組裝（有分段的情況）后才能成為完整的RRC層信令數(shù)據(jù)，進(jìn)行解碼或者進(jìn)一步處理。由于其層次多，數(shù)據(jù)復(fù)雜，已成為測(cè)試儀開(kāi)發(fā)中的一個(gè)難點(diǎn)。其中連接RRC（或者PDCP，BMC）和MAC層的RLC層的數(shù)據(jù)更是類別眾多，結(jié)構(gòu)多變，相當(dāng)復(fù)雜。

RLC[9]層在MAC[10]之上，在RRC（或者PDCP層，BMC層）之下，進(jìn)行相對(duì)獨(dú)立的管理和控制。RLC子層所支持的功能如下[9]：①工程分段和重組，在發(fā)送端執(zhí)行將不同長(zhǎng)度的高層PDU分段，使之成為較小的RLC PDU，并在接收端進(jìn)行重組，RLC單元的大小可以根據(jù)實(shí)際的傳輸格式集進(jìn)行調(diào)整；②串接，當(dāng)一個(gè)RLC SDU的內(nèi)容不能填滿一個(gè)RLC PDU時(shí)，下一個(gè)RLC SDU的第一段可能放在該RLC PDU中與前一個(gè)RLC SDU的最后一段連接在一起；③填充，當(dāng)連接不適當(dāng)且要發(fā)送的剩余數(shù)據(jù)不能填滿一個(gè)完整的RLC PDU時(shí)，RLC PDU的剩余數(shù)據(jù)域?qū)⒂锰畛浔忍靥顫M；④用戶數(shù)據(jù)傳輸，該功能用于在RLC業(yè)務(wù)用戶之間的數(shù)據(jù)傳輸，RLC支持確認(rèn)、非確認(rèn)、透明的數(shù)據(jù)傳輸，QoS的設(shè)置控制用戶數(shù)據(jù)的傳輸；⑤糾錯(cuò)，該功能與物理層采用編碼等方式降低誤碼率不同，RLC子層的確認(rèn)傳輸方式利用重傳機(jī)制提供糾錯(cuò)功能，例如選擇重發(fā)、返回N、停止等待自動(dòng)重傳請(qǐng)求；⑥高層PDU的順序傳遞，在確認(rèn)模式下進(jìn)行數(shù)據(jù)傳輸時(shí)，該功能保證遞交到RLC的高層PDU的發(fā)送順序，若高層要求提供無(wú)順序的傳遞服務(wù)，RLC將不使用該功能；⑦重復(fù)檢測(cè)，該功能在接收端檢測(cè)接收到的RLC PDU是否重復(fù)接收，確保送到高層的PDU只遞交一次；⑧流量控制，該功能允許RLC接收端控制對(duì)等發(fā)送端RLC信息發(fā)送的速率；⑨序列號(hào)檢查，該功能用于非確認(rèn)傳輸模式，保證重組PDU的完整性并提供一個(gè)檢測(cè)惡化的RLC SDU的機(jī)制，將拋棄惡化的RLC SDU；⑩協(xié)議錯(cuò)誤檢側(cè)和恢復(fù)，該功能用于在RLC協(xié)議操作中檢測(cè)錯(cuò)誤并進(jìn)行恢復(fù)；⑾加密，該功能阻止未經(jīng)允許的數(shù)據(jù)用在RLC層的非透明模式中；⑿輪詢，該功能用于RLC發(fā)送端請(qǐng)求RLC接收端回復(fù)一個(gè)狀態(tài)報(bào)告；⒀狀態(tài)傳輸，為了通知RLC發(fā)送端PDU是否接收到，一個(gè)RLC接收端將使用該功能傳送一個(gè)狀態(tài)報(bào)告；⒁SDU的拋棄，該功能允許RLC的發(fā)送端釋放緩沖區(qū)中的一個(gè)RLC SDU；⒂暫停/繼續(xù)功能，該功能用于暫停和繼續(xù)數(shù)據(jù)的傳輸；⒃重建功能，該功能用于重建一個(gè)確認(rèn)和非確認(rèn)模式的RLC實(shí)體；⒄高層數(shù)據(jù)分段或連接成為固定長(zhǎng)度的分組，第三代移動(dòng)通信系統(tǒng)能夠傳輸不同性質(zhì)、不同速率的多種業(yè)務(wù)，而在物理層傳輸?shù)臄?shù)據(jù)包的長(zhǎng)度是相對(duì)固定的，RLC層根據(jù)物理層的數(shù)據(jù)傳輸格式，將來(lái)自高層的大小不等的數(shù)據(jù)包（SDU）分段或連接成為固定長(zhǎng)度的分組（RLC PDU）。

圖1　RLC子層的總體模型

Fig 1 Overall model of RLC

RLC層消息利用透明模式（TM）、非確認(rèn)模式（UM）和確認(rèn)模式（AM）等3種數(shù)據(jù)傳輸方式，為不同類型的業(yè)務(wù)提供不同的傳輸通道。其中，AM傳輸方式以一套較復(fù)雜的機(jī)制提供數(shù)據(jù)的可靠傳輸，并且使高層可以通過(guò)對(duì)AM實(shí)體參數(shù)的不同配置，獲得更高級(jí)別的QoS控制；非確認(rèn)模式的RLC實(shí)體和透明模式的RLC實(shí)體即可作為發(fā)送RLC實(shí)體也可以作為接收RLC實(shí)體。發(fā)送RLC實(shí)體發(fā)送RLC PDUs，接收RLC實(shí)體接收RLC PDUs，而確認(rèn)模式的RLC實(shí)體則由發(fā)送端發(fā)送RLC PDUs的AM實(shí)體和接收端接收RLC PDUs的AM實(shí)體組成。RLC子層的總體模型如圖1所示。

2、RLC層消息解碼關(guān)鍵原理

對(duì)于RLC層的解碼，主要考慮下面幾種功能對(duì)解碼所具有的普遍性影響：①RLC層支持分段和重組功能，在發(fā)送端將根據(jù)RRC建立時(shí)候的傳輸格式集等的指示對(duì)高層PDU分段，使之成為較小的PDU，并在接收端重組、解碼時(shí)考慮到一條邏輯信道中的傳輸數(shù)據(jù)是在一個(gè)高層PDU依次傳輸，而需要對(duì)其重組；②RLC層支持串接功能，當(dāng)一個(gè)RLC SDU的內(nèi)容不能填滿一個(gè)RLC PDU時(shí)，下一個(gè)RLC SDU的第一段可能放在該RLC PDU中，與前一個(gè)RLC SDU的最后一段連接在一起，解碼時(shí)將依靠解出的LI（長(zhǎng)度指示）的內(nèi)容來(lái)具體分析串接數(shù)據(jù)的結(jié)構(gòu)，并對(duì)其進(jìn)行處理；③RLC具有填充功能，解碼時(shí)也可以依據(jù)LI來(lái)做出判斷處理。此外，其他功能造成的解碼問(wèn)題由于不具有普遍性，我們只是在解碼中對(duì)具體問(wèn)題具體分析。

RLC層為高層（RRC，PDCP，BMC）[11]提供的數(shù)據(jù)傳輸服務(wù)有3種模式：透明模式、非確認(rèn)模式和確認(rèn)模式。他們的傳輸?shù)南�息結(jié)構(gòu)如圖2所示。

圖2　RLC PDU格式

Fix.2 RLC PDU format

圖2給出了RLC PDU的3種傳輸模式中所包含的各個(gè)字段，這些字段都是解碼程序模塊設(shè)計(jì)及實(shí)際運(yùn)行需要的，下面對(duì)部分關(guān)鍵的RLC頭包含的字段做出如下解釋[9]：①D/C字段，占用1 bit，對(duì)于數(shù)據(jù)PDU，D/C字段值為1；②SN字段，在UM PDU中占用7 bit，在AM PDU中占用12 bit，表示PDU傳輸?shù)男蛄刑?hào)；③HE，E字段，指示下一字段是要傳輸?shù)臄?shù)據(jù)還是RLC頭中的長(zhǎng)度指示，其中HE占用2 bit，E占用1 bit；④P字段，輪詢比特；用于請(qǐng)求對(duì)等端發(fā)送狀態(tài)報(bào)告，0表示不請(qǐng)求狀態(tài)報(bào)告，1表示請(qǐng)求狀態(tài)報(bào)告，占用1 bit；⑤LI字段，是長(zhǎng)度指示字段[9]，該字段在解碼函數(shù)模塊中非常重要，其字段提取的正確性是解碼能否成功的保證。

長(zhǎng)度指示用來(lái)指示在PDU中每個(gè)RLC SDU結(jié)尾的最后一個(gè)八位組。除了保留專用目的的預(yù)定義值外，長(zhǎng)度指示為：從RLC頭的末尾直到一個(gè)RLC SDU片斷最后一個(gè)八位組之間的八位組數(shù)目，包括在他們涉及的PDU中。長(zhǎng)度指示大小為7 bit或者15 bit，其長(zhǎng)度指示大小由上行和下行獨(dú)立決定。對(duì)于UM和AM PDUs，長(zhǎng)度指示值不能超過(guò)（PDU的值—RLC頭）指示的值。涉及相同PDU的長(zhǎng)度指示萬(wàn)一重發(fā)也不重新安排，和他們涉及的RLC SDUs有相同的順序。

（1）對(duì)AM模式的長(zhǎng)度指示。如果AM PDU大小模式≤126 octets，則用7 bit長(zhǎng)度指示，否則使用15 bit長(zhǎng)度指示。對(duì)于一個(gè)RLC實(shí)體，長(zhǎng)度指示的大小總是和所有的AM PDUs相同。其他具體意義和UM模式相似。

（2）對(duì)于UM模式的長(zhǎng)度指示。如果最大UM PDU大小模式≤125 octets，則使用7 bit長(zhǎng)度指示，否則使用15 bit長(zhǎng)度指示。在“最大UM PDU大小”模式中，長(zhǎng)度指示的大小都和所有的UM PDUs相同。如果RLC SDU開(kāi)始于RLC PDU的開(kāi)頭，并且RLC PDU在上行鏈路傳輸，而且在先前的RLC PDU中，指示的RLC SDU尾部恰好在最末端，或者是一個(gè)八比特組的“長(zhǎng)度指示”（僅當(dāng)15 bit長(zhǎng)度指示被使用）不存在。此時(shí)，如果使用7 bit長(zhǎng)度指示，長(zhǎng)度指示值為111 1100；如果使用15 bit長(zhǎng)度指示，值為111 1111 1111 1100。

（3）在下行鏈路的情況。①如果使用7 bit長(zhǎng)度指示，接收端將會(huì)準(zhǔn)備收到值為111 1100的長(zhǎng)度指示；當(dāng)值為111 1100的長(zhǎng)度指示存在和當(dāng)它不存在時(shí)，接收端會(huì)根據(jù)接收到的UMD PDU更新VR（US），如果VR（US）更新的步驟不等于1（例如一個(gè)或者多個(gè)UMD PDUs沒(méi)收到），則丟棄擁有這個(gè)片斷的SDU或者是在這個(gè)沒(méi)收到的UMD PDUs中的指示到這個(gè)SDUs的尾端的長(zhǎng)度指示。②如果使用15 bit的長(zhǎng)度指示，接收端將準(zhǔn)備接收到的值為111 1111 1111 1100的長(zhǎng)度指示；當(dāng)值為111 1111 1111 1100的長(zhǎng)度指示存在和不存在的時(shí)候，接收端會(huì)根據(jù)接收到的UM PDU更新VR（US），如果VR（US）更新的步驟不等于1（例如一個(gè)或者多個(gè)UM PDUs沒(méi)收到），則丟棄擁有這個(gè)片斷的SDU，或者在這個(gè)沒(méi)收到的UM PDUs中的指示到這個(gè)SDUs的尾端的長(zhǎng)度指示。上述2種情況中，RLC SDU片斷的末端恰好是PDU的末端，這就沒(méi)有對(duì)RLC SDU的長(zhǎng)度指示。③如果用7 bit長(zhǎng)度指示，值為000 0000的長(zhǎng)度指示將用在下一個(gè)PDU的第一個(gè)長(zhǎng)度指示上。④如果用15 bit長(zhǎng)度指示，值為000 0000 0000 0000的長(zhǎng)度指示將用在下一個(gè)PDU的第一個(gè)長(zhǎng)度指示上。這種情況，若一個(gè)PDU包含一個(gè)15 bit長(zhǎng)度指示指示一個(gè)RLC SDU末端，而PDU只剩下一個(gè)八位組，則PDU最后一個(gè)八位組將由發(fā)送端填充，并由接收端忽略，沒(méi)有長(zhǎng)度指示指示這個(gè)額外的填充，并且PDU最后一個(gè)八位組不填充到下一個(gè)SDU數(shù)據(jù)的初始八位組。

在以上情況下，PDU中使用15 bit長(zhǎng)度指示，一個(gè)RLC SDU的最后一個(gè)片斷是一個(gè)剛好填充PDU的短八位組，即，①如果下一個(gè)PDU用15 bit長(zhǎng)度指示，值為111 1111 1111 1011的長(zhǎng)度指示將用在下一個(gè)PDU的第一個(gè)長(zhǎng)度指示上，當(dāng)前PDU的剩余一個(gè)八位組將被發(fā)送端填充，被接收端忽略，而且沒(méi)有指示額外填充的長(zhǎng)度指示；②如果下一個(gè)PDU使用7 bit的長(zhǎng)度指示，RLC配置為UM模式，值為000 0000的長(zhǎng)度指示將用在下個(gè)PDU的第一個(gè)長(zhǎng)度指示上，并且傳輸前，它的序列號(hào)將會(huì)增加2。

如果RLC PDU使用7 bit的長(zhǎng)度指示，在RLC PDU中最后一個(gè)RLC SDU的末端有一個(gè)或者多個(gè)填充八位組，則用PDU最后的值為111 1111的長(zhǎng)度指示值來(lái)指示存在的填充。同樣，如果RLC PDU使用15 bit長(zhǎng)度指示，在RLC PDU中最后一個(gè)RLC SDU的末端由一個(gè)或者多個(gè)填充八位組，則用PDU最后的值為111 1111 1111 1111的長(zhǎng)度指示值來(lái)指示存在的填充（注意：在長(zhǎng)度指示指示的存在RLC PDU內(nèi)含的填充后，填充的長(zhǎng)度可以為0）。

如果長(zhǎng)度指示在等待發(fā)送，而沒(méi)有用到RLC SDU，一個(gè)由這個(gè)長(zhǎng)度指示、適當(dāng)填充長(zhǎng)度指示和填充組成的RLC PDU將會(huì)被傳輸。

長(zhǎng)度指示預(yù)定義值用來(lái)指示填充。長(zhǎng)度指示為7 bit和15 bit情況的保留值在表1和表2中列出，僅有預(yù)定義長(zhǎng)度指示值能指示填充空間，這些值僅用于其他對(duì)PDU的長(zhǎng)度指示值之后。

表1　長(zhǎng)度指示為7 bit情況的保留值

Tab.1 Retention value when LI denotes 7 bits

表2　長(zhǎng)度指示為15 bit情況的保留值

Tab.2 Retention value when LI denotes 15 bits

狀態(tài)PDUs能夠在AMD PDU中使用部分或者全部填充空間被捎帶。一個(gè)預(yù)定義長(zhǎng)度指示值將用來(lái)指示捎帶狀態(tài)PDU，這個(gè)長(zhǎng)度指示值代替了填充長(zhǎng)度指示，捎帶狀態(tài)PDU直接附加在PDU數(shù)據(jù)之后。當(dāng)只有部分填充空間被使用時(shí)，捎帶狀態(tài)PDU的尾端有一個(gè)SUFI域NO_MORE或者ACK指示，所以沒(méi)有額外長(zhǎng)度指示來(lái)顯示這里還有填充。

如果配置了外在信令的SDU丟棄，則一個(gè)AMD PDU能包含最大數(shù)字為15的長(zhǎng)度指示來(lái)指示對(duì)應(yīng)的的15個(gè)PDU，AMD PDU剩余空間將填充或者是捎帶狀態(tài)PDU。不同的模式有不同的SDU傳輸結(jié)構(gòu)，所以將根據(jù)模式的不同采用不同的解碼方法如下。

（1）透明模式，在一個(gè)TTI中傳輸且僅傳輸一個(gè)上層SDU，且本層SUD傳輸時(shí)不添加RLC頭結(jié)構(gòu)，對(duì)于本層的SDU來(lái)說(shuō)，它只是上層PDU的部分或者全部數(shù)據(jù)，因此方法比較簡(jiǎn)單，只需要將其在TTI中傳輸?shù)臄?shù)據(jù)按照傳輸順序串接起來(lái)就可以形成一個(gè)完整的上層PDU數(shù)據(jù)，可直接供上層使用或者上層解碼使用。

（2）非確認(rèn)模式，發(fā)送端通過(guò)UM-SAP從高層接收SDU后，將根據(jù)UM參數(shù)指示進(jìn)行SDU分段或者串接，然后添加RLC層控制信息頭，進(jìn)行傳輸。解碼程序中將先解出RLC層控制信息頭的信息，然后根據(jù)頭信息中的LI等信息進(jìn)行分析研究，對(duì)后面的PDU數(shù)據(jù)進(jìn)行分段（如果傳輸時(shí)候有串接情況）和串接（如果傳輸時(shí)候有分段情況）處理。

（3）確認(rèn)模式的數(shù)據(jù)PDU傳輸?shù)那闆r，從解碼的角度來(lái)看，其傳輸方法也和非確認(rèn)模式類似（控制信息頭稍有不同，解碼時(shí)指針的移動(dòng)大小稍不同；數(shù)據(jù)最后可能有捎帶狀態(tài)PDU，可對(duì)其采用確認(rèn)模式的、控制PDU的解碼方法），也可以采用確認(rèn)模式的方法進(jìn)行解碼，確認(rèn)模式的控制PDU解出PDU頭信息后，采用循環(huán)的方法對(duì)若干個(gè)超域（SUFI）進(jìn)行解碼。

3、RLC層消息解碼算法分析

我們主要對(duì)TM模式、UM模式、AM模式的解碼算法進(jìn)行分析，其各個(gè)算法流程如圖3，圖4，圖5所示。

圖3　RLC層TM消息解碼算法流程圖

Fig.3 Arithmetic for RLC TM decode

圖4　RLC層UM消息解碼算法流程圖

Fig.4 Arithmetic for RLC UM decode

圖5　RLC層AM消息解碼算法流程圖

Fig.5 Arithmetic for RLC AM decode

（1）對(duì)于TM模式傳輸?shù)南�息解碼，其算法相對(duì)簡(jiǎn)單，解碼時(shí)候只需要根據(jù)一個(gè)TTI指示的接口函數(shù)做出判斷，將同一個(gè)TTI的消息片斷按照接收次序組裝起來(lái)，是一個(gè)完整上層消息，可送入上層解碼。

（2）對(duì)于UM模式傳輸?shù)南�息解碼，首先判斷PDU的長(zhǎng)度，然后指針從頭開(kāi)始，按照消息結(jié)構(gòu)提出PDU消息頭的各個(gè)特征片斷（如SN，LI等）的數(shù)據(jù)，并用一個(gè)數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)其值，同時(shí)指針根據(jù)特征片斷的長(zhǎng)度向后移動(dòng)，消息頭解碼結(jié)束后，根據(jù)消息頭中LI和指針的繼續(xù)移動(dòng)，對(duì)SDU或者SDU片斷進(jìn)行處理，分別進(jìn)行組裝或者提取后，形成完整的上層SDU送入上層。對(duì)于SUD片斷，需要數(shù)據(jù)結(jié)構(gòu)對(duì)其暫時(shí)存貯，我們可使用容器或者鏈表等進(jìn)行處理。

（3）對(duì)于AM模式傳輸?shù)南�息解碼，首先指針指向第一比特，判斷是數(shù)據(jù)PDU還是控制PDU，如果是數(shù)據(jù)PDU，可參照UM模式解碼算法，需要注意的是PDU的填充可能有捎帶狀態(tài)PDU，可將其數(shù)據(jù)提取出來(lái)，按照控制PDU的算法進(jìn)行處理；如果是控制PDU，可使指針按照消息結(jié)構(gòu)各個(gè)特征片斷的長(zhǎng)度進(jìn)行移動(dòng)，并解碼，需要注意的是，控制PDU中的SUFI可能有多個(gè)，我們可使用循環(huán)處理的方法進(jìn)行處理。

4、解碼測(cè)試程序分析

測(cè)試程序使用Visual C++語(yǔ)言編寫，在VC環(huán)境中經(jīng)過(guò)編譯、連接之后，執(zhí)行程序就會(huì)出現(xiàn)如圖6所示的對(duì)話框，提示選擇所需解碼模式。鍵入解碼模式后，屏幕提示輸入所需解碼的PDU長(zhǎng)度，輸入數(shù)據(jù)采用16進(jìn)制表示，最后，程序會(huì)提示輸入代碼的內(nèi)容。

UM模式中沒(méi)有長(zhǎng)度指示的解碼示例，程序運(yùn)行結(jié)果如圖7所示，輸入的數(shù)據(jù)長(zhǎng)度是0x04，內(nèi)容是0x2a，0x78，0x98，0x22。

圖6　輸入代碼

Fig.6 Input code

圖7　無(wú)LI的解碼結(jié)果

Fig.7 Decode result without LI

UM模式中有一個(gè)長(zhǎng)度指示的解碼示例，程序運(yùn)行結(jié)果如圖8所示，輸入的數(shù)據(jù)長(zhǎng)度是0x04，內(nèi)容是0x03，0xf8，0x99，0x88。

圖8　長(zhǎng)度指示LI為0x7C的解碼結(jié)果

Fig.8 Decode result with LI 0x7C

圖8為L(zhǎng)I是0x7c情況的解碼示例，此情況可用于判斷SDU第一個(gè)片斷的開(kāi)始。根據(jù)PDU的格式，序列號(hào)取前7 bit，即SN=(1)16=(1)10，擴(kuò)展比特為下一比特，即E=(1)16而根據(jù)E比特的含義可知：當(dāng)其為1時(shí)，下一字節(jié)為L(zhǎng)I和E，因而程序進(jìn)入有長(zhǎng)度指示的解碼部分。又因?yàn)楸境绦蛑簧婕傲薒I為7 bit的情況，所以下7 bit為L(zhǎng)I，即LI=(1111100)2=(7C)16=(124)10此時(shí)下一比特為0，即E=(0)16，表示下一字節(jié)為數(shù)據(jù)。

UM模式中有LI1和LI2 2個(gè)長(zhǎng)度指示的解碼示例，2個(gè)LI都為普通值的情況，輸入長(zhǎng)度為0x07，內(nèi)容為0xed，0x05，0x06，0x44，0x55，0x66，0x77的代碼，其運(yùn)行結(jié)果如圖9所示。

圖9　LI1=0x02，LI2=0x03的解碼結(jié)果

Fig.9 Decode result with LI1=0x02 and LI2=0x03

UM模式中有3個(gè)及其以上LI的解碼示例，LI1-0x7c，LI2，LI3，LI4，LI5為普通值的情況，輸入變量為0xed，0xf9，0x05，0x07，0x09，0x0c，0x11，0x22，0x33，0x44，0x55，0x66，長(zhǎng)度為0x0c，其運(yùn)行結(jié)果加圖10所示。

圖10　LI1=0x7c，LI1，LI2，LI3，LI4為普通值的解碼結(jié)果

Fig. 10 Decode result with LI1 0x7c and other

利用測(cè)試程序還可以測(cè)試其他模式以及其他所有因?yàn)長(zhǎng)I不同而形成的不同類型的PDU。經(jīng)大規(guī)模測(cè)試，程序解碼正確，算法合理。

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

RLC層信令的解碼和組裝是測(cè)試儀中通過(guò)Iub口測(cè)試Uu口消息信令的關(guān)鍵一步，它在MAC層解碼基礎(chǔ)上，將信令消息進(jìn)一步解析并組裝或者拆分，形成完整的上層消息，其中，根據(jù)解碼后的RLC消息頭進(jìn)行信令消息的組裝是其中的難點(diǎn)，我們經(jīng)縝密思考做出上述解碼算法，還使用Visual C++語(yǔ)言對(duì)RLC層消息解碼部分進(jìn)行了編程。該程序dll模塊已經(jīng)應(yīng)用到“重慶郵電大學(xué)TD-SCDMA網(wǎng)絡(luò)測(cè)試儀”中，測(cè)試其效果良好。目前已經(jīng)準(zhǔn)備再次改進(jìn)，力爭(zhēng)盡早達(dá)到TD-SCDMA市場(chǎng)應(yīng)用的各種要求。

參考文獻(xiàn)

[1]　李小文，李貴勇，陳賢亮.TD-SCDMA第三代移動(dòng)通信系統(tǒng)、信令及實(shí)現(xiàn)[M].北京：人民郵電出版社，2003.

[2]　3GPP TS?23.110 V4.0.0 UMTS Access Stratum；Services and Functions[EB/OL].(2001-04-11)[2006-10-11].http：//WWW.3gpp.org/ftp/Specs/archive/23_series/23.110/23110-400.zip.

[3]　3GPP TS?25.401 V4.6.0 UTRAN Overall Description[EB/OL].(2003-01-03)[2006-10-10].http：//WWW.3gpp.org/ftp/Specs/archive/25_series/25.401/25401-460.zip.

[4]　3GPP TS 25.430 V4.4.0 UTRAN Iub Interface.General Aspects and Principles[EB/OL].(2002-10-03)[2006-10-11].http：//WWW.3gpp.org/ftp/specs/archive/25_series/25.430/25430-440.zip.

[5]　3GPP TS 25.431 V4.0.0 UTRAN Iub Interface.Layer 1[EB/OL].(2001-04-06)[2006-10-11].http：//WWW.3gpp.org/ftp/Specs/archive/25_series/25.431/25431-400.zip.

[6]　3GPP TS 25.432 V4.0.0 UTRAN Iub Interface.Signalling Transport[EB/OL].(2001-04-06)[2006-10-12].http：//WWW.3gpp.org/ftp/specs/archive/25_series/25.432/25432-400.zip.

[7]　3GPP TR 25.990 V3.0.0 Vocabulary for UTRAN [EB/OL].(1999-10-13)[2006-10-12].http：//WWW.3gpp.org/ftp/Specs/archive/25_series/25.990/25990-300.zip.

[8]　3GPP TS 25.301 V4.4.0 Radio Interface Protocol Architecture[EB/OL].(2002-09-18)[2006-10-14].http：//WWW.3gpp.org/ftp/Specs/archive/25_series/25.301/25301-440.zip.

[9]　3GPP TS 25.322 V4.12.0 Radio Link Control(RLC)protocol specification[EB/OL].(2004-06-17)[2006-10-18].http：//WWW.3gpp.org/ftp/specs/archive/25_series/25.322/25322-4co.zip.

[10]　3GPP TS?25.321 V4.10.0 Medium Access Control (MAC)protocol specification[EB/OL].(2004-06-17)[2064-10-17].http：//WWW.3gpp.org/ftp/Specs/archive/25_series/25.321/25321-4a0.zip.

[11]　3GPP TS?25.331 V5.8.0 Radio Resource Control (RRC)protocol specification[EB/OL].(2004-03-24)[2006-10-21].　http：//WWW.3gpp.org/ftp/specs/archive/25_series/25.331/25331-580.zip.

作者：龔玨　雒江濤　張治中 來(lái)源：重慶郵電學(xué)院學(xué)報(bào)