TD-SCDMA網(wǎng)絡(luò)測試儀中Uu接口的信令分析

摘要　深入研究了在TD-SCDMA系統(tǒng)中對Uu接口協(xié)議棧進(jìn)行信令監(jiān)測的方法。給出了Node B節(jié)點(diǎn)的用戶平面和Uu接口控制平面的結(jié)構(gòu)模型和公共傳輸信道傳輸格式的確定方式，分析了Uu接口協(xié)議棧RLC協(xié)議的分段重組過程。在此基礎(chǔ)上提出了從Iub接口FP協(xié)議數(shù)據(jù)幀中得到Uu接口協(xié)議棧數(shù)據(jù)，實(shí)現(xiàn)信令監(jiān)測的一種算法。該算法的程序模塊在實(shí)際環(huán)境下進(jìn)行了測試，結(jié)果說明，運(yùn)用該算法能夠在Iub接口準(zhǔn)確地、完整地監(jiān)測和分析Uu接口的信令消息。

0、引言

TD-SCDMA系統(tǒng)是TDMA和CDMA 2種基本傳輸模式的靈活結(jié)合。TD-SCDMA系統(tǒng)特別適合在城市人口密集地區(qū)提供高密度大容量話音、數(shù)據(jù)和多媒體業(yè)務(wù)。系統(tǒng)可以單獨(dú)運(yùn)營，也可以與其他技術(shù)配合使用[1]。中國將于2007年開始實(shí)施TD-SCDMA第三代移動(dòng)通信網(wǎng)絡(luò)的建設(shè)，各廠家的TD-SCDMA網(wǎng)絡(luò)設(shè)備在設(shè)計(jì)和制造上雖然遵守標(biāo)準(zhǔn)的協(xié)議，但是在某些情況下仍出現(xiàn)了設(shè)備互聯(lián)互通的問題[2]，這就需要開發(fā)出適合中國國情的多協(xié)議信令檢測儀表，為網(wǎng)絡(luò)交換機(jī)的正常運(yùn)行提供必備的檢測依據(jù)和維護(hù)手段。

我們在原有的GSM/CDMA等一系列信令分析儀表的基礎(chǔ)上，針對TD-SCDMA系統(tǒng)，研制了TD-SCDMA網(wǎng)絡(luò)測試儀。TD-SCDMA網(wǎng)絡(luò)測試儀可為網(wǎng)絡(luò)交換機(jī)的正常運(yùn)行提供必備的檢測依據(jù)和維護(hù)手段，是確保實(shí)現(xiàn)設(shè)備運(yùn)行的關(guān)鍵技術(shù)之一。

在本文中，我們針對TD-SCDMA如何對Uu接口協(xié)議信令進(jìn)行測試，根據(jù)Uu接口協(xié)議信令在Iub用戶平面的承載方式提出了一種通過Iub接口實(shí)現(xiàn)Uu接口信令測試和研究的一種方法。這樣信令測試儀將不再需要無線信號接收模塊，從而降低開發(fā)成本，縮短研發(fā)周期。經(jīng)測試表明，采用該方法能夠在Iub接口準(zhǔn)確地測試Uu接口信令，滿足設(shè)備廠商和運(yùn)營商的測試需求。

1、FP幀協(xié)議及Uu接口第2層協(xié)議格式分析

TD-SCDMA接入網(wǎng)（universal terrestrial radio access network，UTRAN）結(jié)構(gòu)如圖1所示，在TD-SCDMA系統(tǒng)中通用地面無線接入網(wǎng)絡(luò)部分主要是由無線網(wǎng)絡(luò)控制器、節(jié)點(diǎn)B（NodeB）和用戶設(shè)備（UE）構(gòu)成。Iub接口位于節(jié)點(diǎn)B（NodeB）與無線網(wǎng)絡(luò)中心（RNC）之間。Uu接口存在于Ue與NodeB之間。在2個(gè)RNC之間是Iur接口，傳遞2個(gè)RNC之間的信息。

圖1　TD-SCDMA系統(tǒng)UTRAN網(wǎng)絡(luò)接口

Fig.1 Interfaces of TD-SCDMA UTRAN

Iub接口包括2個(gè)功能層：無線網(wǎng)絡(luò)層和傳輸網(wǎng)絡(luò)層，而每一層又分為控制平面和用戶平面。無線網(wǎng)絡(luò)層用戶平面由相應(yīng)的Iub-FP協(xié)議組成，其主要功能是把Uu接口上的數(shù)據(jù)承載到Iub接口上的FP數(shù)據(jù)幀。在Uu接口上按其功能和任務(wù)分為物理層，數(shù)據(jù)鏈路層和網(wǎng)絡(luò)層等3層。其中，數(shù)據(jù)鏈路層又分為媒體接入控制（MAC）、無線鏈路控制（RLC）、分組數(shù)據(jù)匯聚協(xié)議（PDCP）和廣播/多播控制（BMC）等4個(gè)子層。Uu接口協(xié)議棧第3層協(xié)議和RLC按其功能又分為控制平面和用戶平面，Uu接口協(xié)議棧第2層協(xié)議的PDCP和BMC只存在于用戶平面中。在控制平面上，Uu接口協(xié)議棧第3層協(xié)議又被分為無線資源控制（RRC）、移動(dòng)性管理（MM）和連接管理（CM）等3個(gè)子層。

Uu接口用戶平面的語音、分組數(shù)據(jù)和控制平面的信令數(shù)據(jù)在NodeB都作為用戶數(shù)據(jù)從用戶平面發(fā)送。用戶平面的FP協(xié)議將Uu接口控制平面和用戶平面的數(shù)據(jù)封裝成幀，然后在事先分配的AAL2鏈路上進(jìn)行傳送。從而實(shí)現(xiàn)Uu接口的信令和用戶數(shù)據(jù)在NodeB以透明方式傳送給RNC端。NodeB用戶平面成幀協(xié)議包括：USCH FP，DSCH FP，PCH FP，F(xiàn)ACH FP，RACH FP和DCH FP，根據(jù)數(shù)據(jù)屬于不同的傳輸信道，采用對應(yīng)的FP協(xié)議對數(shù)據(jù)進(jìn)行封裝。我們重點(diǎn)討論Uu接口控制平面部分MAC，RLC協(xié)議在Iub上的承載方式、測試軟件中采用的解碼方法以及RRC PDU的分段重組算法。

首先介紹FP協(xié)議本身的消息結(jié)構(gòu)和對Uu接口協(xié)議數(shù)據(jù)的承載方式。圖2描述了Iub接口用戶平面FP協(xié)議基本數(shù)據(jù)幀結(jié)構(gòu)。

圖2　Iub用戶平面數(shù)據(jù)幀結(jié)構(gòu)

Fig.2 Iub interface user plane message format

圖2中，數(shù)據(jù)幀頭部（Header）包含以下幾部分：①Head CRC（幀頭CRC）：主要是對幀頭信息進(jìn)行校驗(yàn)；②FT（幀類型）：1 bit——0表示數(shù)據(jù)幀，1表示控制幀；③TFI（傳輸格式指示）：提供凈負(fù)荷的傳輸格式信息；④Other information（其他信息）：如定時(shí)信息、測量信息和功率信息等。凈負(fù)荷（Payload）主要由3部分組成：①TB（傳輸塊）：攜帶要傳輸?shù)臄?shù)據(jù)信息，每個(gè)TB塊就包含了一個(gè)MAC協(xié)議的PDU；②Spare Extension（預(yù)留塊）：為將來增加新的IE（信息元素）保留位置；③Payload CRC（凈負(fù)荷CRC）：對凈負(fù)荷數(shù)據(jù)進(jìn)行校驗(yàn)。

Uu接口控制平面協(xié)議棧第2層協(xié)議主要包括MAC和RLC協(xié)議，它們和無線網(wǎng)絡(luò)層的協(xié)議信令都將通過FP成幀協(xié)議映射到Iub接口的AAL2承載上，下面將分別介紹MAC和RLC協(xié)議的信令消息格式。

MAC層與物理層之間的通信是通過傳輸信道進(jìn)行的，而與無線鏈路控制層之間的通信則是使用邏輯信道。因此，在MAC子層中將完成邏輯信道和傳輸信道之間的相互映射，并根據(jù)邏輯信道的資源速率為傳輸信道選擇合適的傳輸格式（TF），而傳輸格式的選擇是根據(jù)連接建立時(shí)由RRC實(shí)體定義的傳輸格式集（TFCS）進(jìn)行的。MAC層的PDU結(jié)構(gòu)如圖3所示。

圖3　MAC層基本PDU結(jié)構(gòu)

Fig.3 MAC protocol PDU format

MAC子層PDU結(jié)構(gòu)解析如下。

●TCTF字段編碼：TCTF主要用來識別RACH和FACH上的邏輯信道，從MAC PDU結(jié)構(gòu)也可看出，TCTF字段只存在于RACH和FACH上。

●UE-Id類型編碼：UE-Id type字段只用于目標(biāo)邏輯信道為DCCH或DTCH、傳輸信道為公共傳輸信道或共享信道的情況，即需要UE-Id的場合，來指示所用UE-Id的類型。這里需要注意的是：DTCH/DCCH RACH時(shí)，UE-Id type必須為C-RNTI（01）；DTCH/DCCH DSCH/USCH時(shí)，UE-Id type必須為DSCH-RNTI（01）。

●UE-Id編碼：UE-Id字段只用于目標(biāo)邏輯信道為DCCH或DTCH、傳輸信道為公共傳輸信道或共享信道的情況，用來識別不同的UE。

●C/T字段編碼：C/T字段用于在有邏輯信道復(fù)用時(shí)識別不同的邏輯信道，其編碼對公共傳輸信道和專用信道都相同。

在RLC層和MAC層之間的SAP提供邏輯信道，RLC提供3類SAP，對應(yīng)于RLC的3種操作模式：非確認(rèn)模式（UM）、確認(rèn)模式（AM）和透明模式（TM）。在控制平面RLC向高層（RRC）提供的服務(wù)為信令無線承載（SRB）；在用戶平面RLC向高層（PDCP、BMC）提供的服務(wù)為無線承載（RB）。在控制平面和用戶平面上，RLC提供的服務(wù)沒有區(qū)別。在透明模式下，RLC使用TMD PDU來傳輸用戶數(shù)據(jù)。TMD PDU在傳送RLC SDU數(shù)據(jù)時(shí)不添加任何RLC頭，其PDU就是上層數(shù)據(jù)本身。在非確認(rèn)模式和確認(rèn)模式下，RLC分別使用UMD PDU和AMD PDU來傳輸用戶數(shù)據(jù)[3]。UM和AM模式的PDU格式分別如圖4，圖5所示。

圖4　UM模式PDU結(jié)構(gòu)

Fig.4 UM mode PDU format

圖5　AM模式PDU結(jié)構(gòu)

Fig.5 AM mode PDU format

D/C：用于標(biāo)識PDU是數(shù)據(jù)PDU還是控制PDU的字段，值為0時(shí)表示PDU為控制PDU，值為1時(shí)表示PDU為數(shù)據(jù)PDU。

SN：該域指示RLC PDU的序號，二進(jìn)制編碼。

輪詢比特（P）：該域用來請求一個(gè)從接收端的狀態(tài)報(bào)告（一個(gè)或者幾個(gè)狀態(tài)PDU）。用于請求對等端發(fā)送狀態(tài)報(bào)告。0表示不請求狀態(tài)報(bào)告，1表示請求狀態(tài)報(bào)告。

PDU類型：指示控制PDU的類型。

擴(kuò)展比特（E）：該比特指示下個(gè)八位組是否是長度指示。0表示下一個(gè)字段是數(shù)據(jù)、捎帶STA-TUS PDU或填充。1表示下一個(gè)字段是長度指示LI和擴(kuò)展比特E。

保留1（R1）：在復(fù)位PDU和復(fù)位應(yīng)答PDU中的這個(gè)域用來組成一個(gè)復(fù)合8比特組，編碼為“000”。其它值保留并且在協(xié)議版本中考慮為無效。

報(bào)頭擴(kuò)展比特（HE）：這個(gè)2bit域指示下個(gè)8位組是數(shù)據(jù)還是長度指示和擴(kuò)展比特。

長度指示（LI）：用來指示在PDU中的每個(gè)RLC SDU結(jié)尾的最后一個(gè)8位組。

2、傳輸信道在Iub接口上的AAL2類承載映射關(guān)系的確定

在Iub接口用戶平面，不同的傳輸信道對應(yīng)著不同的FP成幀協(xié)議，采用不同的幀格式和傳輸格式。在這里要獲取Uu接口信令PDU需要先確定當(dāng)前數(shù)據(jù)幀的傳輸格式。而不同的傳輸信道各自具備一套傳輸格式集，數(shù)據(jù)幀的傳輸格式屬于這個(gè)集合并且由數(shù)據(jù)幀中攜帶的指示字段指示當(dāng)前數(shù)據(jù)幀所采用的傳輸格式。傳輸格式集是在傳輸信道建立時(shí)由RRC實(shí)體發(fā)送傳輸信道建立消息的過程中指示的，一個(gè)傳輸格式集中包含了在該傳輸信道上可能出現(xiàn)的多個(gè)傳輸格式。所以只需要知道每個(gè)Iub接口上的AAL2類承載對應(yīng)的是那個(gè)傳輸信道，就可以知道FP數(shù)據(jù)幀的傳輸格式屬于哪一個(gè)傳輸格式集，從而確定其格式。下面就具體介紹如何確定一個(gè)AAL2類承載對應(yīng)的傳輸信道。

因?yàn)閷Ｓ脗鬏斝诺缹��?yīng)的AAL2類承載能夠從公共傳輸信道獲取的信令消息中得知，所以關(guān)鍵在于找到公共傳輸信道對應(yīng)的AAL2類承載，具體來說就是獲得FACH，RACH，PCH信道對應(yīng)的2類承載。首先建立公共傳輸信道中各類信道的傳輸格式集合和公共傳輸信道的ATM連接集合；接著提取公共傳輸信道中ATM連接上的幀長度，并記錄各自的ATM連接傳輸參數(shù)VPI/VCI/CID；將提取的數(shù)據(jù)幀長度與建立的傳輸格式集合中的數(shù)據(jù)進(jìn)行比較，以判斷該數(shù)據(jù)幀屬于哪一種公共傳輸信道，以此判斷公共傳輸信道類型[4]。具體的判斷依據(jù)如下：如果某一ATM連接上數(shù)據(jù)幀的長度屬于某個(gè)傳輸信道的幀長度集合，則標(biāo)記該連接承載該傳輸信道。如果標(biāo)記為某傳輸信道類型的ATM連接上出現(xiàn)了不屬于該信道的幀長度集合的數(shù)據(jù)幀長度，則重新標(biāo)記該連接不屬于該傳輸信道類型。最終利用各信道數(shù)據(jù)幀長集合中的非交集部分可成功地判斷出傳輸信道和AAL2類承載的映射關(guān)系。該過程的算法描述如圖6所示。

圖6　傳輸信道AAL2類承載映射關(guān)系分析過程

Fig.6　Arithmetic about confirming the AAL2 bear for transport channels

在獲得了傳輸信道與AAL2類承載的映射關(guān)系之后，將根據(jù)不同的傳輸信道格式集包含的FP幀的TB塊長度來提取MAC層的PDU。

3、MAC協(xié)議解碼分析

從FP數(shù)據(jù)幀中獲得MAC層PDU之后就開始MAC層的解碼和提取SDU過程。MAC實(shí)體主要實(shí)現(xiàn)邏輯信道與傳輸信道的映射，在解碼流程中MAC模塊主要實(shí)現(xiàn)MAC頭信息解碼以及提取RLC協(xié)議的PDU，并將該P(yáng)DU對應(yīng)的邏輯信道類型信息和PDU數(shù)據(jù)段一起傳送給RLC解碼模塊。

上面一節(jié)中論述了MAC協(xié)議PDU的通用格式，但是根據(jù)傳輸信道對應(yīng)的邏輯信道不同，MAC實(shí)體將按具體情況包含不同的字段信息。下面僅以RACH信道為例，介紹MAC頭字段在對應(yīng)不同邏輯信道時(shí)字段內(nèi)容的變化情況。

在傳輸信道RACH上，依據(jù)邏輯信道的不同，MAC頭的結(jié)構(gòu)有所不同，如圖7所示。

圖7　RACH信道上MAC頭信息類型

Fig.7 MAC protocol message type on RACH

從圖7可以看出，由于傳輸信道對應(yīng)的邏輯信道不同，MAC頭信息字段有比較大的差別，所以在FP數(shù)據(jù)幀完成從TB塊中提取MAC PDU之后還需要將該P(yáng)DU所在的傳輸信道類型作為MAC模塊解碼所需的必要信息一并送給MAC解碼模塊。另外MAC層解碼模塊還需要知道各個(gè)傳輸信道上的邏輯信道復(fù)用情況，這需要根據(jù)被測試設(shè)備的配置信息來確定。

在獲得了MAC PDU和該P(yáng)DU對應(yīng)的傳輸信道類型信息后，MAC解碼模塊對該P(yáng)DU進(jìn)行解碼。由于不同的傳輸信道對應(yīng)的邏輯信道不同且MAC頭的字段結(jié)構(gòu)也不相同，這里我們以RACH信道為例，對MAC協(xié)議PDU解碼方法做如下分析。

首先取得該MAC PDU的比特單位長度和該P(yáng)DU對應(yīng)的傳輸信道類型。然后根據(jù)邏輯信道復(fù)用情況，判斷該RACH信道是否映射唯一邏輯信道SHCCH，若是則無MAC頭。否則，進(jìn)行MAC頭解碼，通過TCTF字段進(jìn)行邏輯信道類型判斷。首先取MAC PDU頭部前2個(gè)bit，如果是（00）B，則該P(yáng)DU映射的邏輯信道為CCCH；若為（10）B，則該P(yáng)DU映射的邏輯信道為SHCCH。在這2種情況下，MAC頭信息長度均為2 bit。如果前2 bit是（01）B，那么邏輯信道為DCCH或DTCH，且該種情況下TCTF字段應(yīng)該為6 bit（010001），MAC頭總長為26 bit。若為其他值則是異常情況。在確定了RACH信道映射的邏輯信道類型之后，按照其邏輯信道類型所對應(yīng)MAC頭信息字段內(nèi)容分別對各個(gè)字段進(jìn)行解碼。MAC PDU除去頭信息部分剩下的便是Uu接口RLC協(xié)議的PDU數(shù)據(jù)。MAC解碼模塊將得到的RLC PDU和該P(yáng)DU對應(yīng)的邏輯信道類型信息一同傳送給RLC解碼模塊。上述MAC模塊解碼算法如圖8所示。

圖8　RACH信道MAC協(xié)議解碼流程

Fig.8 Arithmetic about MAC message decode on RACH

4、RLC協(xié)議分段重組算法分析

在經(jīng)過MAC解碼模塊后將得到Uu接口RLC協(xié)議的PDU數(shù)據(jù)塊。TD-SCDMA信令分析儀中的RLC解碼模塊主要實(shí)現(xiàn)RLC信息解碼和Uu接口第3層協(xié)議PDU的重組，并且將完整的PDU送給Uu接口協(xié)議棧第3層協(xié)議對應(yīng)的RRC解碼模塊。RLC協(xié)議的本層信息字段都是固定字節(jié)長度，其解碼方法與MAC模塊采用的取位操作一致，這里不再贅述。本節(jié)主要針對RLC模塊如何實(shí)現(xiàn)重組上層RRC PDU進(jìn)行論述。

在透明模式下，Uu接口協(xié)議棧第3層協(xié)議數(shù)據(jù)可能分段也可能不分段，不管是否分段，上層協(xié)議的一個(gè)PDU都將在一個(gè)TTI內(nèi)傳送，且RLC協(xié)議不附加任何協(xié)議信息。即是說透明模式下一個(gè)FP數(shù)據(jù)幀內(nèi)就包含了一個(gè)Uu接口協(xié)議棧第3層協(xié)議的完整信令PDU，F(xiàn)P模塊將其攜帶的所有TB塊經(jīng)過MAC模塊對MAC協(xié)議信息解碼后交給RLC模塊，再由RLC模塊對每個(gè)MAC解碼模塊送上來的PDU進(jìn)行連接就能得到Uu接口協(xié)議棧第3層協(xié)議的完整信令數(shù)據(jù)。

Uu接口協(xié)議棧第3層協(xié)議PDU在確認(rèn)模式和非確認(rèn)模式下的分段重組規(guī)則一致，下面就以非確認(rèn)模式進(jìn)行分析。RLC工作在非確認(rèn)模式時(shí)，使用UM PDU來傳送數(shù)據(jù)。非確認(rèn)模式下的消息格式結(jié)構(gòu)前面已經(jīng)介紹了，在解碼過程中實(shí)現(xiàn)分段重組獲得完整的Uu接口協(xié)議棧第3層協(xié)議PDU關(guān)鍵在于LI字段。LI可以提取Uu接口協(xié)議棧第3層協(xié)議PDU的數(shù)據(jù)字節(jié)。一個(gè)RLC PDU可能包含不止一個(gè)Uu接口協(xié)議棧第3層協(xié)議SDU，相應(yīng)的LI指示每個(gè)Uu接口協(xié)議棧第3層協(xié)議SDU的長度。同樣，一個(gè)高層的PDU也可能在RLC層分段，LI特定指示高層PDU的開頭和結(jié)尾。LI字段長度為7 bit，當(dāng)LI取值為0000000時(shí)，表明之前的RLC PDU恰好由最后一個(gè)RLC SDU填充，并且在這個(gè)之前的RLC PDU中的RLC SDU末端沒有指示其長度，可用于判斷前邊一個(gè)SDU的結(jié)束；LI取值為1111100時(shí)，表明第一個(gè)RLC PDU的數(shù)據(jù)8位組是RLC SDU的第一個(gè)8位組，可用于判斷SDU的第一個(gè)片斷的開始；當(dāng)LI取值為1111111時(shí)，表明RLC PDU剩下為填充部分，用于判斷SDU的結(jié)束。另外1111101～1111110作為LI的保留值[5]。

由于在UM和AM模式下SDU的長度是變化的，所以LI字段是解碼過程中一個(gè)非常重要的參量，在RLC模塊中，主要根據(jù)L1的值及字段E對上層協(xié)議的PDU進(jìn)行重組和定界。上層協(xié)議的PDU在RLC分段，那么RLC PDU中的第一個(gè)LI值為7C或00，表示一個(gè)RRC PDU的第一個(gè)片斷。其后該RRC PDU的片段將分別封裝在多個(gè)RLC PDU中，且這些RLC PDU中沒有LI指示字段。直到RRC PDU分段的最后一個(gè)封裝到RLC PDU中時(shí)，RLC實(shí)體會(huì)為其加上一個(gè)普通的LI指示，該LI將表示這個(gè)片斷是被分段的RRC PDU的最后一段。如果是多個(gè)上層的RRC PDU封裝在一個(gè)RLC PDU中，那么將有多個(gè)普通LI來對多個(gè)RRC PDU進(jìn)行定界。因此RLC模塊的重組主要就是根據(jù)LI字段的值來進(jìn)行。首先判斷是否是TM模式，若為TM模式則將一個(gè)TBS中的所有RLC PDU直接串接形成一個(gè)完整的RRC PDU；若不是TM模式則找到第一個(gè)LI，判斷該LI的值是否為0x7C或0x00。如果是，則表明這是一個(gè)RCC PDU分段的第一個(gè)片斷，將其存入組裝緩沖區(qū)內(nèi)；如果不是，則表明是一個(gè)普通的LI指示字段，標(biāo)明了一個(gè)完整RRC PDU的分界或者是一個(gè)RRC PDU分段的最后一段，于是將其與組裝緩沖區(qū)內(nèi)的已有字段連接再送到FP模塊的RRC PDU存儲鏈表中。如果當(dāng)前的RLC PDU中沒有LI指示，則表明該RLC PDU中包含的是一個(gè)RRC PDU片斷的中間一段，此時(shí)緩沖區(qū)域內(nèi)已經(jīng)存放且組裝了該P(yáng)DU的前邊所有片斷，因此將該片斷放入緩沖區(qū)內(nèi)并連接在已有片斷后邊。圖9描述了RLC模塊組裝流程。

圖9　RLC模塊組裝流程

Fig.9 RLC module recombine process

5、FP模塊解碼及調(diào)度算法分析

一個(gè)FP數(shù)據(jù)幀根據(jù)傳輸信道是否復(fù)用包含一個(gè)或多個(gè)TB塊集（TBS）和傳輸格式指示字段，其中一個(gè)TBS（傳輸塊集）對應(yīng)一個(gè)傳輸信道在一個(gè)TTI內(nèi)傳送的所有TB塊。每個(gè)TB塊是由一個(gè)MAC PDU和填充比特構(gòu)成，在一個(gè)TBS中的所有TB塊長度以及TB塊對應(yīng)的MAC PDU長度是相同的。其中MAC PDU是由MAC協(xié)議頭信息和上層RLC協(xié)議的PDU組成。圖10清楚的表明了三者PDU的封裝承載關(guān)系。

圖10　Uu接口協(xié)議PDU封裝過程

Fig.10 Uu interface protocol PDU encapsulation process

由于MAC模塊和RLC模塊需要FP模塊提供相關(guān)必要信息用于各自的解碼，并且在AAL2類承載上是按一個(gè)FP數(shù)據(jù)幀為單位進(jìn)行解碼的，所以MAC模塊和RLC模塊不能獨(dú)立于FP模塊存在，在該算法中FP模塊完成對MAC和RLC模塊的調(diào)度和數(shù)據(jù)傳遞。FP解碼模塊將根據(jù)TB塊的個(gè)數(shù)，循環(huán)調(diào)用MAC和RLC解碼功能模塊，循環(huán)次數(shù)取決于FP數(shù)據(jù)幀中TB塊個(gè)數(shù)[6]。

FP協(xié)議信息字段主要存在于數(shù)據(jù)幀的頭部和尾部。在FP數(shù)據(jù)幀的幀頭部包含Header CRC，F(xiàn)T，CF以及TFI等字段，這些字段都是固定長度的信息單元。通過移位和位與的方式取出固定比特長度的字段值，然后與3GPP標(biāo)準(zhǔn)進(jìn)行比較并解釋其具體含義。通過頭部字段解碼得到TFI值，通過該值在事先配置的傳輸格式集中找到當(dāng)前FP數(shù)據(jù)幀中TBS采用的傳輸格式。在確定了傳輸格式后，就能夠確定TBS總長度和每個(gè)TB塊的填充長度。同時(shí)也能確定數(shù)據(jù)幀尾的CRCI字段的個(gè)數(shù)，根據(jù)協(xié)議規(guī)定，一個(gè)TB塊對應(yīng)一個(gè)1bit長度的CRCI字段。在確定了CRCI字段個(gè)數(shù)之后，根據(jù)FP數(shù)據(jù)幀總長度確定數(shù)據(jù)幀尾部的擴(kuò)展字段長度和Payload CRC長度，然后按照bit位長度字段的解碼方法完成FP數(shù)據(jù)幀尾部的信息字段的解碼。

前面完成了FP協(xié)議信息的解碼和TB塊的定界工作，接下來FP模塊將調(diào)用MAC和RLC模塊完成MAC及RLC協(xié)議信息的解碼和RRC PDU的提取功能。在該調(diào)度算法中每一次循環(huán)將完成一個(gè)TB塊上MAC協(xié)議信息、RLC協(xié)議信息的解碼功能，并根據(jù)字段信息對TB塊中的RLC SDU進(jìn)行分段或重組得到0個(gè)、1個(gè)或多個(gè)RRC PDU。首先FP模塊將根據(jù)傳輸格式去掉TB塊中的填充比特，然后將得到的MAC PDU送給MAC解碼模塊。根據(jù)以上所述，F(xiàn)P解碼模塊還需要將當(dāng)前TB塊所屬的傳輸信道類型一并告知MAC解碼模塊。在MAC解碼模塊完成了MAC協(xié)議信息解碼后，它將返回一個(gè)RLC PDU以及該RLC PDU對應(yīng)的邏輯信道類型給FP模塊。FP模塊再調(diào)用RLC模塊，將得到的PDU和相應(yīng)邏輯信道類型傳遞給RLC模塊完成解碼和分段重組的功能。由于調(diào)用一次FP模塊就將完成一個(gè)FP數(shù)據(jù)幀中多個(gè)TB塊的解碼，這樣將會(huì)產(chǎn)生多個(gè)RRC PDU。因此，在FP模塊中將保存一個(gè)RRC PDU存儲鏈表，在調(diào)用了RLC功能模塊后得到的RRC PDU將被返回給FP模塊存儲到該P(yáng)DU鏈表中。在完成了一個(gè)FP數(shù)據(jù)幀中所有TB塊的解碼后，將生成的所有RRC PDU送到上層RRC協(xié)議解碼模塊。以上介紹的是一個(gè)傳輸信道映射到一個(gè)AAL2類承載上只有一個(gè)TBS的情況。如果在一個(gè)AAL2類承載上存在多個(gè)傳輸信道的復(fù)用，那么在一個(gè)FP數(shù)據(jù)幀中將會(huì)出現(xiàn)多個(gè)TBS，一個(gè)TBS就對應(yīng)一個(gè)傳輸信道在一個(gè)TTI內(nèi)傳送的所有數(shù)據(jù)。所以在傳輸信道復(fù)用的情況下還將按照TBS的個(gè)數(shù)，重復(fù)執(zhí)行以上的解碼及提取步驟完成每個(gè)TBS的解碼。圖11描述了數(shù)據(jù)幀中只存在一個(gè)TBS的解碼算法。

圖11　FP模塊解碼流程

Fig.11 FP module decode process

6、數(shù)據(jù)分析和軟件運(yùn)行結(jié)果

下面給出一個(gè)具體的Uu接口消息在上述軟件模塊下的運(yùn)行結(jié)果。這里以一條經(jīng)過Iub接口從NodeB發(fā)向RNC的Uu接口消息為例。該消息原始數(shù)據(jù)如表1所示。

表1　原始消息比特?cái)?shù)據(jù)串

Tab.1　Bit stream data

首先按照3GPP協(xié)議標(biāo)準(zhǔn)對該數(shù)據(jù)串進(jìn)行解釋。第一個(gè)字節(jié)由FP幀的頭CRC和FT字段組成。第一個(gè)字節(jié)二進(jìn)制表示為（11000110）B，其中頭CRC字段占第一個(gè)字節(jié)的高7位（01100011）B，轉(zhuǎn)化為16進(jìn)制為0x63。FT字段為最底位（00000001）B，轉(zhuǎn)化為16進(jìn)制為0x01。頭校驗(yàn)CRC數(shù)據(jù)用于校驗(yàn)FP數(shù)據(jù)幀的頭部信息，F(xiàn)T指示了該FP幀為數(shù)據(jù)幀用于傳送Uu接口數(shù)據(jù)。第2個(gè)字節(jié)為CFN幀號，值為0x38。第3個(gè)字節(jié)高3位是填充bit，低5位是TFI字段，這里TFI字段值為0x00，指示了該FP數(shù)據(jù)幀采用的傳輸格式在傳輸格式集中的序號。如前所述，在獲得了該值后通過查找傳輸格式集就能夠確定當(dāng)前數(shù)據(jù)幀中TB塊大小。第4個(gè)字節(jié)是一個(gè)SYNC UL字段值為0x6b，表明收到的SYNC UL的時(shí)間偏移。從第5個(gè)字節(jié)（0x44）開始到第25個(gè)字節(jié)（0x00），是當(dāng)前幀的TBS。根據(jù)傳輸格式可以知道該TBS只包含了一個(gè)TB塊。在知道TB塊大小及個(gè)數(shù)之后，就可以對TBS定界，然后對FP幀的尾部信息進(jìn)行解碼。當(dāng)前數(shù)據(jù)幀的尾部包含一個(gè)TB-CRCI占一個(gè)bit位，值為0x00，表示該TB塊正確。之后是一個(gè)7 bit的填充，值為0x00，無具體意義。最后是2個(gè)字節(jié)的Payload CRC，值為0x268b。TB塊的前邊26個(gè)bit，分別為TCTF，UE-ID Type，C-RNTI，C/T字段。其中當(dāng)前幀的TCTF字段值為0x04表明在當(dāng)前的RACH信道映射著一條專用控制信道（DCCH）。UE-ID值為0x01表明當(dāng)前UE使用的是C-RNTI類型標(biāo)識。當(dāng)前UE的C-RNTI ID值為0x047a，該值在一個(gè)RNC內(nèi)唯一標(biāo)識該UE。C/T字段的出現(xiàn)表明傳輸信道上復(fù)用了多條邏輯信道，當(dāng)前的邏輯信道編號為2。接著就是MAC SDU即上層RLC協(xié)議的PDU數(shù)據(jù)段。第1個(gè)字節(jié)的最高比特是D/C字段，值為0x01表明當(dāng)前RLC SDU為數(shù)據(jù)PDU。接著是12 bit長度的SN（序列號）字段，當(dāng)前RLC PDU的序列號為0x01。P字段值為0x01表明請求一個(gè)狀態(tài)報(bào)告。最后的HE字段值為0x00，緊接著后邊的是RLC SDU，由于MAC頭信息不是整字節(jié)長度，所以這里的RLC SDU從第10個(gè)字節(jié)的比特5開始，到第21個(gè)字節(jié)結(jié)束。圖12按照二進(jìn)制的方式標(biāo)明了每個(gè)字段。

圖12　數(shù)據(jù)比特串釋意

Fig.12 bit stream explanation

上面對一條原始數(shù)據(jù)字段按照3GPP的定義做了完整解釋，圖13是該條消息經(jīng)過本軟件模塊在完成FP，MAC，RLC 3層解碼及字段提取后在TD-SCDMA測試儀上的顯示結(jié)果。需要說明一下MAC解碼結(jié)果部分的RLC Mode信息是外界配置并顯示的，該信息不是消息字段中的內(nèi)容。

圖13　消息解碼結(jié)果

Fig.13 Decode result

可見在采用本軟件模塊的TD-SCDMA測試儀器上能夠按照3GPP協(xié)議標(biāo)準(zhǔn)對本條消息完成正確解碼，并能成功分段和重組Uu接口RRC協(xié)議的PDU數(shù)據(jù)段。

7、結(jié)束語

在文中我們提出了一種在有線接口上完成無線接口協(xié)議棧信令測試的思想。并通過對Uu接口RLC和MAC協(xié)議的格式和封裝過程以及Iub接口FP幀結(jié)構(gòu)的分析和研究，采用面向?qū)ο蟮姆绞酵瓿闪藢?shí)現(xiàn)該思想的軟件模塊。通過TD-SCDMA測試儀對Uu接口大量信令數(shù)據(jù)的測試，本軟件的解碼結(jié)果均符合3GPP協(xié)議規(guī)范，實(shí)現(xiàn)了設(shè)計(jì)目的和功能要求。

參考文獻(xiàn)

[1]　KAMMERLANDER.Benefits and implementation of TD-SCDMA[EB/OL].(2000-04-12)[2006-11-28].http：//ieeexplore.ieee.org/ie15/7138/19221/00890848.pdf?isnumber=&arnumber=890848.

[2]　LI Bo，XIE Dong-liang. Recent advances on TD-SCDMA in China[J].Communications Magazine，IEEE，2005，43(1)：30-37.

[3]　3GPP TS25.321 V4.4.0-2002，Media Access Control (MAC)protocol specification[EB/OL].　(2001-03)[2006-10-17].http：//www.3gpp.org/ftp/Specs/html-info/25321.htm.

[4]　雒江濤.張治中.Iub接口公共傳輸信道類型的自動(dòng)識別方法：中國，CN1859435[P].2006-06.

[5]　3GPP TS25.322 V4.12.0-2002，Radio Link Control (RLC)protocol specification[EB/OL].(2001-03)[2006-6-21].http：//www.3gpp.org/ftp/Specs/html-info/25322.htm.

[6]　張毅.鮮繼清.TD-SCDMA信令軟件設(shè)計(jì)方案[J].重慶郵電學(xué)院學(xué)報(bào)(自然科學(xué)版)，2003，15(1)：32-34.