摘要 深入研究了在TD-SCDMA系統中對Uu接口協議棧進行信令監測的方法。給出了Node B節點的用戶平面和Uu接口控制平面的結構模型和公共傳輸信道傳輸格式的確定方式，分析了Uu接口協議棧RLC協議的分段重組過程。在此基礎上提出了從Iub接口FP協議數據幀中得到Uu接口協議棧數據，實現信令監測的一種算法。該算法的程序模塊在實際環境下進行了測試，結果說明，運用該算法能夠在Iub接口準確地、完整地監測和分析Uu接口的信令消息。
0、引言
TD-SCDMA系統是TDMA和CDMA 2種基本傳輸模式的靈活結合。TD-SCDMA系統特別適合在城市人口密集地區提供高密度大容量話音、數據和多媒體業務。系統可以單獨運營，也可以與其他技術配合使用[1]。中國將於2007年開始實施TD-SCDMA第三代移動通信網絡的建設，各廠家的TD-SCDMA網絡設備在設計和製造上雖然遵守標準的協議，但是在某些情況下仍出現了設備互聯互通的問題[2]，這就需要開發出適合中國國情的多協議信令檢測儀表，爲網絡交換機的正常運行提供必備的檢測依據和維護手段。
我們在原有的GSM/CDMA等一系列信令分析儀表的基礎上，針對TD-SCDMA系統，研製了TD-SCDMA網絡測試儀。TD-SCDMA網絡測試儀可爲網絡交換機的正常運行提供必備的檢測依據和維護手段，是確保實現設備運行的關鍵技術之一。
在本文中，我們針對TD-SCDMA如何對Uu接口協議信令進行測試，根據Uu接口協議信令在Iub用戶平面的承載方式提出了一種通過Iub接口實現Uu接口信令測試和研究的一種方法。這樣信令測試儀將不再需要無線信號接收模塊，從而降低開發成本，縮短研發週期。經測試表明，採用該方法能夠在Iub接口準確地測試Uu接口信令，滿足設備廠商和運營商的測試需求。
1、FP幀協議及Uu接口第2層協議格式分析
TD-SCDMA接入網（universal terrestrial radio access network，UTRAN）結構如圖1所示，在TD-SCDMA系統中通用地面無線接入網絡部分主要是由無線網絡控制器、節點B（NodeB）和用戶設備（UE）構成。Iub接口位於節點B（NodeB）與無線網絡中心（RNC）之間。Uu接口存在於Ue與NodeB之間。在2個RNC之間是Iur接口，傳遞2個RNC之間的信息。
圖1 TD-SCDMA系統UTRAN網絡接口
Fig.1 Interfaces of TD-SCDMA UTRAN
Iub接口包括2個功能層：無線網絡層和傳輸網絡層，而每一層又分爲控制平面和用戶平面。無線網絡層用戶平面由相應的Iub-FP協議組成，其主要功能是把Uu接口上的數據承載到Iub接口上的FP數據幀。在Uu接口上按其功能和任務分爲物理層，數據鏈路層和網絡層等3層。其中，數據鏈路層又分爲媒體接入控制（MAC）、無線鏈路控制（RLC）、分組數據匯聚協議（PDCP）和廣播/多播控制（BMC）等4個子層。Uu接口協議棧第3層協議和RLC按其功能又分爲控制平面和用戶平面，Uu接口協議棧第2層協議的PDCP和BMC只存在於用戶平面中。在控制平面上，Uu接口協議棧第3層協議又被分爲無線資源控制（RRC）、移動性管理（MM）和連接管理（CM）等3個子層。
Uu接口用戶平面的語音、分組數據和控制平面的信令數據在NodeB都作爲用戶數據從用戶平面發送。用戶平面的FP協議將Uu接口控制平面和用戶平面的數據封裝成幀，然後在事先分配的AAL2鏈路上進行傳送。從而實現Uu接口的信令和用戶數據在NodeB以透明方式傳送給RNC端。NodeB用戶平面成幀協議包括：USCH FP，DSCH FP，PCH FP，FACH FP，RACH FP和DCH FP，根據數據屬於不同的傳輸信道，採用對應的FP協議對數據進行封裝。我們重點討論Uu接口控制平面部分MAC，RLC協議在Iub上的承載方式、測試軟件中採用的解碼方法以及RRC PDU的分段重組算法。
首先介紹FP協議本身的消息結構和對Uu接口協議數據的承載方式。圖2描述了Iub接口用戶平面FP協議基本數據幀結構。
圖2 Iub用戶平面數據幀結構
Fig.2 Iub interface user plane message format
圖2中，數據幀頭部（Header）包含以下幾部分：①Head CRC（幀頭CRC）：主要是對幀頭信息進行校驗；②FT（幀類型）：1 bit——0表示數據幀，1表示控制幀；③TFI（傳輸格式指示）：提供淨負荷的傳輸格式信息；④Other information（其他信息）：如定時信息、測量信息和功率信息等。淨負荷（Payload）主要由3部分組成：①TB（傳輸塊）：攜帶要傳輸的數據信息，每個TB塊就包含了一個MAC協議的PDU；②Spare Extension（預留塊）：爲將來增加新的IE（信息元素）保留位置；③Payload CRC（淨負荷CRC）：對淨負荷數據進行校驗。
Uu接口控制平面協議棧第2層協議主要包括MAC和RLC協議，它們和無線網絡層的協議信令都將通過FP成幀協議映射到Iub接口的AAL2承載上，下面將分別介紹MAC和RLC協議的信令消息格式。
MAC層與物理層之間的通信是通過傳輸信道進行的，而與無線鏈路控制層之間的通信則是使用邏輯信道。因此，在MAC子層中將完成邏輯信道和傳輸信道之間的相互映射，並根據邏輯信道的資源速率爲傳輸信道選擇合適的傳輸格式（TF），而傳輸格式的選擇是根據連接建立時由RRC實體定義的傳輸格式集（TFCS）進行的。MAC層的PDU結構如圖3所示。
圖3 MAC層基本PDU結構
Fig.3 MAC protocol PDU format
MAC子層PDU結構解析如下。
●TCTF字段編碼：TCTF主要用來識別RACH和FACH上的邏輯信道，從MAC PDU結構也可看出，TCTF字段只存在於RACH和FACH上。
●UE-Id類型編碼：UE-Id type字段只用於目標邏輯信道爲DCCH或DTCH、傳輸信道爲公共傳輸信道或共享信道的情況，即需要UE-Id的場合，來指示所用UE-Id的類型。這裏需要注意的是：DTCH/DCCH RACH時，UE-Id type必須爲C-RNTI（01）；DTCH/DCCH DSCH/USCH時，UE-Id type必須爲DSCH-RNTI（01）。
●UE-Id編碼：UE-Id字段只用於目標邏輯信道爲DCCH或DTCH、傳輸信道爲公共傳輸信道或共享信道的情況，用來識別不同的UE。
●C/T字段編碼：C/T字段用於在有邏輯信道複用時識別不同的邏輯信道，其編碼對公共傳輸信道和專用信道都相同。
在RLC層和MAC層之間的SAP提供邏輯信道，RLC提供3類SAP，對應於RLC的3種操作模式：非確認模式（UM）、確認模式（AM）和透明模式（TM）。在控制平面RLC向高層（RRC）提供的服務爲信令無線承載（SRB）；在用戶平面RLC向高層（PDCP、BMC）提供的服務爲無線承載（RB）。在控制平面和用戶平面上，RLC提供的服務沒有區別。在透明模式下，RLC使用TMD PDU來傳輸用戶數據。TMD PDU在傳送RLC SDU數據時不添加任何RLC頭，其PDU就是上層數據本身。在非確認模式和確認模式下，RLC分別使用UMD PDU和AMD PDU來傳輸用戶數據[3]。UM和AM模式的PDU格式分別如圖4，圖5所示。
圖4 UM模式PDU結構
Fig.4 UM mode PDU format
圖5 AM模式PDU結構
Fig.5 AM mode PDU format
D/C：用於標識PDU是數據PDU還是控制PDU的字段，值爲0時表示PDU爲控制PDU，值爲1時表示PDU爲數據PDU。
SN：該域指示RLC PDU的序號，二進制編碼。
輪詢比特（P）：該域用來請求一個從接收端的狀態報告（一個或者幾個狀態PDU）。用於請求對等端發送狀態報告。0表示不請求狀態報告，1表示請求狀態報告。
PDU類型：指示控制PDU的類型。
擴展比特（E）：該比特指示下個八位組是否是長度指示。0表示下一個字段是數據、捎帶STA-TUS PDU或填充。1表示下一個字段是長度指示LI和擴展比特E。
保留1（R1）：在復位PDU和復位應答PDU中的這個域用來組成一個複合8比特組，編碼爲“000”。其它值保留並且在協議版本中考慮爲無效。
報頭擴展比特（HE）：這個2bit域指示下個8位組是數據還是長度指示和擴展比特。
長度指示（LI）：用來指示在PDU中的每個RLC SDU結尾的最後一個8位組。
2、傳輸信道在Iub接口上的AAL2類承載映射關係的確定
在Iub接口用戶平面，不同的傳輸信道對應着不同的FP成幀協議，採用不同的幀格式和傳輸格式。在這裏要獲取Uu接口信令PDU需要先確定當前數據幀的傳輸格式。而不同的傳輸信道各自具備一套傳輸格式集，數據幀的傳輸格式屬於這個集合並且由數據幀中攜帶的指示字段指示當前數據幀所採用的傳輸格式。傳輸格式集是在傳輸信道建立時由RRC實體發送傳輸信道建立消息的過程中指示的，一個傳輸格式集中包含了在該傳輸信道上可能出現的多個傳輸格式。所以只需要知道每個Iub接口上的AAL2類承載對應的是那個傳輸信道，就可以知道FP數據幀的傳輸格式屬於哪一個傳輸格式集，從而確定其格式。下面就具體介紹如何確定一個AAL2類承載對應的傳輸信道。
因爲專用傳輸信道對應的AAL2類承載能夠從公共傳輸信道獲取的信令消息中得知，所以關鍵在於找到公共傳輸信道對應的AAL2類承載，具體來說就是獲得FACH，RACH，PCH信道對應的2類承載。首先建立公共傳輸信道中各類信道的傳輸格式集合和公共傳輸信道的ATM連接集合；接着提取公共傳輸信道中ATM連接上的幀長度，並記錄各自的ATM連接傳輸參數VPI/VCI/CID；將提取的數據幀長度與建立的傳輸格式集合中的數據進行比較，以判斷該數據幀屬於哪一種公共傳輸信道，以此判斷公共傳輸信道類型[4]。具體的判斷依據如下：如果某一ATM連接上數據幀的長度屬於某個傳輸信道的幀長度集合，則標記該連接承載該傳輸信道。如果標記爲某傳輸信道類型的ATM連接上出現了不屬於該信道的幀長度集合的數據幀長度，則重新標記該連接不屬於該傳輸信道類型。最終利用各信道數據幀長集合中的非交集部分可成功地判斷出傳輸信道和AAL2類承載的映射關係。該過程的算法描述如圖6所示。
圖6 傳輸信道AAL2類承載映射關係分析過程
Fig.6 Arithmetic about confirming the AAL2 bear for transport channels
在獲得了傳輸信道與AAL2類承載的映射關係之後，將根據不同的傳輸信道格式集包含的FP幀的TB塊長度來提取MAC層的PDU。
3、MAC協議解碼分析
從FP數據幀中獲得MAC層PDU之後就開始MAC層的解碼和提取SDU過程。MAC實體主要實現邏輯信道與傳輸信道的映射，在解碼流程中MAC模塊主要實現MAC頭信息解碼以及提取RLC協議的PDU，並將該PDU對應的邏輯信道類型信息和PDU數據段一起傳送給RLC解碼模塊。
上面一節中論述了MAC協議PDU的通用格式，但是根據傳輸信道對應的邏輯信道不同，MAC實體將按具體情況包含不同的字段信息。下面僅以RACH信道爲例，介紹MAC頭字段在對應不同邏輯信道時字段內容的變化情況。
在傳輸信道RACH上，依據邏輯信道的不同，MAC頭的結構有所不同，如圖7所示。
圖7 RACH信道上MAC頭信息類型
Fig.7 MAC protocol message type on RACH
從圖7可以看出，由於傳輸信道對應的邏輯信道不同，MAC頭信息字段有比較大的差別，所以在FP數據幀完成從TB塊中提取MAC PDU之後還需要將該PDU所在的傳輸信道類型作爲MAC模塊解碼所需的必要信息一併送給MAC解碼模塊。另外MAC層解碼模塊還需要知道各個傳輸信道上的邏輯信道複用情況，這需要根據被測試設備的配置信息來確定。
在獲得了MAC PDU和該PDU對應的傳輸信道類型信息後，MAC解碼模塊對該PDU進行解碼。由於不同的傳輸信道對應的邏輯信道不同且MAC頭的字段結構也不相同，這裏我們以RACH信道爲例，對MAC協議PDU解碼方法做如下分析。
首先取得該MAC PDU的比特單位長度和該PDU對應的傳輸信道類型。然後根據邏輯信道複用情況，判斷該RACH信道是否映射唯一邏輯信道SHCCH，若是則無MAC頭。否則，進行MAC頭解碼，通過TCTF字段進行邏輯信道類型判斷。首先取MAC PDU頭部前2個bit，如果是（00）B，則該PDU映射的邏輯信道爲CCCH；若爲（10）B，則該PDU映射的邏輯信道爲SHCCH。在這2種情況下，MAC頭信息長度均爲2 bit。如果前2 bit是（01）B，那麼邏輯信道爲DCCH或DTCH，且該種情況下TCTF字段應該爲6 bit（010001），MAC頭總長爲26 bit。若爲其他值則是異常情況。在確定了RACH信道映射的邏輯信道類型之後，按照其邏輯信道類型所對應MAC頭信息字段內容分別對各個字段進行解碼。MAC PDU除去頭信息部分剩下的便是Uu接口RLC協議的PDU數據。MAC解碼模塊將得到的RLC PDU和該PDU對應的邏輯信道類型信息一同傳送給RLC解碼模塊。上述MAC模塊解碼算法如圖8所示。
圖8 RACH信道MAC協議解碼流程
Fig.8 Arithmetic about MAC message decode on RACH
4、RLC協議分段重組算法分析
在經過MAC解碼模塊後將得到Uu接口RLC協議的PDU數據塊。TD-SCDMA信令分析儀中的RLC解碼模塊主要實現RLC信息解碼和Uu接口第3層協議PDU的重組，並且將完整的PDU送給Uu接口協議棧第3層協議對應的RRC解碼模塊。RLC協議的本層信息字段都是固定字節長度，其解碼方法與MAC模塊採用的取位操作一致，這裏不再贅述。本節主要針對RLC模塊如何實現重組上層RRC PDU進行論述。
在透明模式下，Uu接口協議棧第3層協議數據可能分段也可能不分段，不管是否分段，上層協議的一個PDU都將在一個TTI內傳送，且RLC協議不附加任何協議信息。即是說透明模式下一個FP數據幀內就包含了一個Uu接口協議棧第3層協議的完整信令PDU，FP模塊將其攜帶的所有TB塊經過MAC模塊對MAC協議信息解碼後交給RLC模塊，再由RLC模塊對每個MAC解碼模塊送上來的PDU進行連接就能得到Uu接口協議棧第3層協議的完整信令數據。
Uu接口協議棧第3層協議PDU在確認模式和非確認模式下的分段重組規則一致，下面就以非確認模式進行分析。RLC工作在非確認模式時，使用UM PDU來傳送數據。非確認模式下的消息格式結構前面已經介紹了，在解碼過程中實現分段重組獲得完整的Uu接口協議棧第3層協議PDU關鍵在於LI字段。LI可以提取Uu接口協議棧第3層協議PDU的數據字節。一個RLC PDU可能包含不止一個Uu接口協議棧第3層協議SDU，相應的LI指示每個Uu接口協議棧第3層協議SDU的長度。同樣，一個高層的PDU也可能在RLC層分段，LI特定指示高層PDU的開頭和結尾。LI字段長度爲7 bit，當LI取值爲0000000時，表明之前的RLC PDU恰好由最後一個RLC SDU填充，並且在這個之前的RLC PDU中的RLC SDU末端沒有指示其長度，可用於判斷前邊一個SDU的結束；LI取值爲1111100時，表明第一個RLC PDU的數據8位組是RLC SDU的第一個8位組，可用於判斷SDU的第一個片斷的開始；當LI取值爲1111111時，表明RLC PDU剩下爲填充部分，用於判斷SDU的結束。另外1111101～1111110作爲LI的保留值[5]。
由於在UM和AM模式下SDU的長度是變化的，所以LI字段是解碼過程中一個非常重要的參量，在RLC模塊中，主要根據L1的值及字段E對上層協議的PDU進行重組和定界。上層協議的PDU在RLC分段，那麼RLC PDU中的第一個LI值爲7C或00，表示一個RRC PDU的第一個片斷。其後該RRC PDU的片段將分別封裝在多個RLC PDU中，且這些RLC PDU中沒有LI指示字段。直到RRC PDU分段的最後一個封裝到RLC PDU中時，RLC實體會爲其加上一個普通的LI指示，該LI將表示這個片斷是被分段的RRC PDU的最後一段。如果是多個上層的RRC PDU封裝在一個RLC PDU中，那麼將有多個普通LI來對多個RRC PDU進行定界。因此RLC模塊的重組主要就是根據LI字段的值來進行。首先判斷是否是TM模式，若爲TM模式則將一個TBS中的所有RLC PDU直接串接形成一個完整的RRC PDU；若不是TM模式則找到第一個LI，判斷該LI的值是否爲0x7C或0x00。如果是，則表明這是一個RCC PDU分段的第一個片斷，將其存入組裝緩衝區內；如果不是，則表明是一個普通的LI指示字段，標明瞭一個完整RRC PDU的分界或者是一個RRC PDU分段的最後一段，於是將其與組裝緩衝區內的已有字段連接再送到FP模塊的RRC PDU存儲鏈表中。如果當前的RLC PDU中沒有LI指示，則表明該RLC PDU中包含的是一個RRC PDU片斷的中間一段，此時緩衝區域內已經存放且組裝了該PDU的前邊所有片斷，因此將該片斷放入緩衝區內並連接在已有片斷後邊。圖9描述了RLC模塊組裝流程。
圖9 RLC模塊組裝流程
Fig.9 RLC module recombine process
5、FP模塊解碼及調度算法分析
一個FP數據幀根據傳輸信道是否複用包含一個或多個TB塊集（TBS）和傳輸格式指示字段，其中一個TBS（傳輸塊集）對應一個傳輸信道在一個TTI內傳送的所有TB塊。每個TB塊是由一個MAC PDU和填充比特構成，在一個TBS中的所有TB塊長度以及TB塊對應的MAC PDU長度是相同的。其中MAC PDU是由MAC協議頭信息和上層RLC協議的PDU組成。圖10清楚的表明了三者PDU的封裝承載關係。
圖10 Uu接口協議PDU封裝過程
Fig.10 Uu interface protocol PDU encapsulation process
由於MAC模塊和RLC模塊需要FP模塊提供相關必要信息用於各自的解碼，並且在AAL2類承載上是按一個FP數據幀爲單位進行解碼的，所以MAC模塊和RLC模塊不能獨立於FP模塊存在，在該算法中FP模塊完成對MAC和RLC模塊的調度和數據傳遞。FP解碼模塊將根據TB塊的個數，循環調用MAC和RLC解碼功能模塊，循環次數取決於FP數據幀中TB塊個數[6]。
FP協議信息字段主要存在於數據幀的頭部和尾部。在FP數據幀的幀頭部包含Header CRC，FT，CF以及TFI等字段，這些字段都是固定長度的信息單元。通過移位和位與的方式取出固定比特長度的字段值，然後與3GPP標準進行比較並解釋其具體含義。通過頭部字段解碼得到TFI值，通過該值在事先配置的傳輸格式集中找到當前FP數據幀中TBS採用的傳輸格式。在確定了傳輸格式後，就能夠確定TBS總長度和每個TB塊的填充長度。同時也能確定數據幀尾的CRCI字段的個數，根據協議規定，一個TB塊對應一個1bit長度的CRCI字段。在確定了CRCI字段個數之後，根據FP數據幀總長度確定數據幀尾部的擴展字段長度和Payload CRC長度，然後按照bit位長度字段的解碼方法完成FP數據幀尾部的信息字段的解碼。
前面完成了FP協議信息的解碼和TB塊的定界工作，接下來FP模塊將調用MAC和RLC模塊完成MAC及RLC協議信息的解碼和RRC PDU的提取功能。在該調度算法中每一次循環將完成一個TB塊上MAC協議信息、RLC協議信息的解碼功能，並根據字段信息對TB塊中的RLC SDU進行分段或重組得到0個、1個或多個RRC PDU。首先FP模塊將根據傳輸格式去掉TB塊中的填充比特，然後將得到的MAC PDU送給MAC解碼模塊。根據以上所述，FP解碼模塊還需要將當前TB塊所屬的傳輸信道類型一併告知MAC解碼模塊。在MAC解碼模塊完成了MAC協議信息解碼後，它將返回一個RLC PDU以及該RLC PDU對應的邏輯信道類型給FP模塊。FP模塊再調用RLC模塊，將得到的PDU和相應邏輯信道類型傳遞給RLC模塊完成解碼和分段重組的功能。由於調用一次FP模塊就將完成一個FP數據幀中多個TB塊的解碼，這樣將會產生多個RRC PDU。因此，在FP模塊中將保存一個RRC PDU存儲鏈表，在調用了RLC功能模塊後得到的RRC PDU將被返回給FP模塊存儲到該PDU鏈表中。在完成了一個FP數據幀中所有TB塊的解碼後，將生成的所有RRC PDU送到上層RRC協議解碼模塊。以上介紹的是一個傳輸信道映射到一個AAL2類承載上只有一個TBS的情況。如果在一個AAL2類承載上存在多個傳輸信道的複用，那麼在一個FP數據幀中將會出現多個TBS，一個TBS就對應一個傳輸信道在一個TTI內傳送的所有數據。所以在傳輸信道複用的情況下還將按照TBS的個數，重複執行以上的解碼及提取步驟完成每個TBS的解碼。圖11描述了數據幀中只存在一個TBS的解碼算法。
圖11 FP模塊解碼流程
Fig.11 FP module decode process
6、數據分析和軟件運行結果
下面給出一個具體的Uu接口消息在上述軟件模塊下的運行結果。這裏以一條經過Iub接口從NodeB發向RNC的Uu接口消息爲例。該消息原始數據如表1所示。
表1 原始消息比特數據串
Tab.1 Bit stream data
首先按照3GPP協議標準對該數據串進行解釋。第一個字節由FP幀的頭CRC和FT字段組成。第一個字節二進制表示爲（11000110）B，其中頭CRC字段佔第一個字節的高7位（01100011）B，轉化爲16進製爲0x63。FT字段爲最底位（00000001）B，轉化爲16進製爲0x01。頭校驗CRC數據用於校驗FP數據幀的頭部信息，FT指示了該FP幀爲數據幀用於傳送Uu接口數據。第2個字節爲CFN幀號，值爲0x38。第3個字節高3位是填充bit，低5位是TFI字段，這裏TFI字段值爲0x00，指示了該FP數據幀採用的傳輸格式在傳輸格式集中的序號。如前所述，在獲得了該值後通過查找傳輸格式集就能夠確定當前數據幀中TB塊大小。第4個字節是一個SYNC UL字段值爲0x6b，表明收到的SYNC UL的時間偏移。從第5個字節（0x44）開始到第25個字節（0x00），是當前幀的TBS。根據傳輸格式可以知道該TBS只包含了一個TB塊。在知道TB塊大小及個數之後，就可以對TBS定界，然後對FP幀的尾部信息進行解碼。當前數據幀的尾部包含一個TB-CRCI佔一個bit位，值爲0x00，表示該TB塊正確。之後是一個7 bit的填充，值爲0x00，無具體意義。最後是2個字節的Payload CRC，值爲0x268b。TB塊的前邊26個bit，分別爲TCTF，UE-ID Type，C-RNTI，C/T字段。其中當前幀的TCTF字段值爲0x04表明在當前的RACH信道映射着一條專用控制信道（DCCH）。UE-ID值爲0x01表明當前UE使用的是C-RNTI類型標識。當前UE的C-RNTI ID值爲0x047a，該值在一個RNC內唯一標識該UE。C/T字段的出現表明傳輸信道上覆用了多條邏輯信道，當前的邏輯信道編號爲2。接着就是MAC SDU即上層RLC協議的PDU數據段。第1個字節的最高比特是D/C字段，值爲0x01表明當前RLC SDU爲數據PDU。接着是12 bit長度的SN（序列號）字段，當前RLC PDU的序列號爲0x01。P字段值爲0x01表明請求一個狀態報告。最後的HE字段值爲0x00，緊接着後邊的是RLC SDU，由於MAC頭信息不是整字節長度，所以這裏的RLC SDU從第10個字節的比特5開始，到第21個字節結束。圖12按照二進制的方式標明瞭每個字段。
圖12 數據比特串釋意
Fig.12 bit stream explanation
上面對一條原始數據字段按照3GPP的定義做了完整解釋，圖13是該條消息經過本軟件模塊在完成FP，MAC，RLC 3層解碼及字段提取後在TD-SCDMA測試儀上的顯示結果。需要說明一下MAC解碼結果部分的RLC Mode信息是外界配置並顯示的，該信息不是消息字段中的內容。
圖13 消息解碼結果
Fig.13 Decode result
可見在採用本軟件模塊的TD-SCDMA測試儀器上能夠按照3GPP協議標準對本條消息完成正確解碼，並能成功分段和重組Uu接口RRC協議的PDU數據段。
7、結束語
在文中我們提出了一種在有線接口上完成無線接口協議棧信令測試的思想。並通過對Uu接口RLC和MAC協議的格式和封裝過程以及Iub接口FP幀結構的分析和研究，採用面向對象的方式完成了實現該思想的軟件模塊。通過TD-SCDMA測試儀對Uu接口大量信令數據的測試，本軟件的解碼結果均符合3GPP協議規範，實現了設計目的和功能要求。
參考文獻
[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接口公共傳輸信道類型的自動識別方法：中國，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信令軟件設計方案[J].重慶郵電學院學報(自然科學版)，2003，15(1)：32-34.
