| 摘要 深入研究了在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. | 
![CentOS7下TestLink環境的部署[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)