TD-SCDMA网络测试仪中Uu接口的信令分析

TD-SCDMA网络测试仪中Uu接口的信令分析     文章来源：中国通信器材网 　　 添加人：admin 　　 添加时间：2007-7-2 10:43:00

    

摘要　深入研究了在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.