后台RNC信令分析资料剖析

目录
第1章CT工具的基本知识 (4)
1.1CT工具的配置 (4)
1.1.1服务器端配置 (4)
1.1.2客户端配置 (4)
1.1.3单机版使用 (6)
第2章信令分析说明 (7)
2.1 基本知识准备 (7)
2.1.1如何看业务信令 (7)
2.1.2流程中的几个重要概念 (9)
2.2 RRC建立过程的信令分析 (10)
2.2.1 RRC Connection Request信令综述 (10)
2.2.2 RRC Connection Request信令 (11)
2.2.3 Radio Link Setup信令 (13)
2.2.4 Radio Link Setup Response信令 (26)
2.2.5 Radio Link Setup Failure信令 (27)
2.2.6 RRC Connection Setup信令 (28)
2.2.7 Radio Link Restore Indication信令 (37)
2.2.8 RRC Connection SetupComplete信令 (37)
2.2.8 RRC建立过程中常见问题 (38)
2.3初始直传信令分析 (39)
2.3.1 InitialDirectTransfer信令分析 (41)
2.3.2 InitialUEMessage信令分析 (42)
2.3.2 CommonID信令分析 (42)
2.4鉴权过程（可选）信令分析 (43)
2.4.1 DirectTransfer信令分析（图中1） (46)
2.4.2 DownLinkDirectTransfer信令分析（图中2） (46)
2.4.3 UpLinkDirectTransfer信令分析（图中3） (47)
2.4.4 DirectTransfer信令分析（图中4） (47)
2.4.5 鉴权过程中常见问题 (48)
2.5安全模式信令分析 (48)
2.5.1 SecurityModeCommand（Iu口上，CN到RNC） (49)
2.5.2 SecurityModeCommand（Uu口上，RNC到UE） (53)
2.5.3 securityModeComplete（Uu口上，UE到RNC） (53)
2.5.4 securityModeComplete（Iu口上，RNC到CN） (54)
2.6直传信令分析 (54)
2.6.1 Setup过程信令分析 (55)
2.6.2 Call Proceeding过程信令分析 (56)
2.7 RAB建立过程信令分析 (57)
2.7.1 RAB Assignment Request信令分析 (61)
2.7.2 Radio Link Reconfiguration Prepare信令分析 (65)
2.7.3 Radio Link Reconfiguration Ready (76)
2.7.4 Radio Link Reconfiguration Failure (76)
2.7.5 Radio Link Reconfiguration Commit (78)
2.7.6 Radio Bearer Setup信令分析 (78)
第1章CT工具的基本知识
1.1CT工具的配置
1.1.1服务器端配置
服务器端的配置只要修改一个配置文件就可以实现。

修改的文件路径为“E:\NetNumen-TOMC\ums-svr\zxwomc\zxwomc-osf-tkit-rnc.par\conf”目录下的“osf-tkit-config.xml”文件。

（注：此目录也有可能在D盘下，只要是OMM服务器上的安装目录即可）
打开文件，先找到sbcx配置段，如下：
<sbcx>
<ServerIP>127.0.0.1</ServerIP>
<Port>5057</Port>
<FtpPort>21</FtpPort>
<Username>zte</Username>
<Password>ztezte</Password>
</sbcx>
其中蓝色标出的地址，修改为网管网段使用的接口地址，以北京为例，RNC11的接口地址为10.223.64.131，下面的端口号不需要修改。

再看一下server配置段，如下：
<server lastvisit="rnc,129.0.0.1,5057">
<address>rnc,129.0.0.1,5057</address>
</server>
其中蓝色标出的地址，修改为前台OMP的地址，该地址的配置为（129.0.31.RNC局号）。

修改完两项配置后保存该文件。

修改完配置文件后，停止网管服务器，删除网管服务器下“E:\NetNumen-TOMC\ums-svr\temp”目录下的文件，然后在启动网管服务器后就可以了。

注：由于XML文件很容易被修改出错，修改配置前最好能先备份该文件。

而且建议不要使用其他的文档修改工具，使用“写字板”工具就可以了。

1.1.2客户端配置
客户端的配置基本很简单，只需要在登录的时候改变一下登录的配置就可以了。

配置截图如下：
先选择“Clinet”方式连接。

在连接地址和端口号这两个配置上和以前后一些不同，我们的维护终端一般都在维护网
段上（北京为10.223.64.0/24），这里填写的地址为OMM服务器的网管端口地址，端口号固定
为“35057”，其他配置不需要修改。

点击确认后就可以看到连接成功，终于可以实现跨网段
的信令跟踪功能。

实现跨网段连接后问题有来了，如果还是只能一个人登录连接，那么还是如能方便自如
的使用。

如果多人使用现在的系统也是支持的，需要更改客户端的模块号配置。

修改的配置
文件为“E:\omm_2.30.110c\ums-clnt\tools\zxwomc-tools-rnc\zxwomc-wsf-tkit-rnc\conf”目
录下的“config.xml”文件，模块号的具体配置如下：
在system配置段中有，如下的ModuleId字段：
<!--后台模块号，前台只能支持128-192-->
<ModuleId>150</ModuleId>
原来默认的配置模块为150，如果多人同时使用其他人配置成其他的模块就可以了，但
是注意上面的提示，前台能够支持的模块号只有128-192。

讲到这个模块号，大家好像都能
有点印象，我们的3GPLAT工具也需要使用模块号，RDS工具也需要使用模块号，于是问题就
来了，我们这个模块号到底应该怎么取值，才能保证各个工具不相互冲突呢？
这就需要使用RDS工具登录到主用的OMP单板上，敲一下OSS_DbgShowComm命令，在返回
的结果中，最后的部分，我们可以看到已经连接到OMP的各工具使用的模块号,结果如下：Back ground link table:(Ip attached)
module IP(hex) socket state kpalive rcvFrag sndFrag sndQ maxQueSize(K) maxQueUsed(K)
153 8100010b 30 3 0 0 0 0 128 0
152 8100010b 29 3 1 0 0 0 128 0
130 8100010b 31 3 0 0 0 0 128 0 151 8100010b 32 3 2 0 0 0 128 0 150 8100010b 33 3 0 0 0 0 128 0 修改为一个为连接的模块号后，就能实现多个信令跟踪同时进行跟踪了。

我在这里就是用了150和151两个模块号，实现了两个信令跟踪同时使用的情况。

使用期间发现如果多用户连接，出现了个别用户可能由于OMP资源问题，被异常中断的情况。

注：虽然现在跟踪工具连接的地址变成了OMM的网管地址，但是由于我们的信令跟踪工具还是通过OMM服务器转接到OMP单板上的，其实还是和OMP单板进行了连接，所以研发人员的建议是同时连接的信令跟踪不能超过3个，还是要尽量少的占用OMP的资源，保证RNC的稳定运行。

1.1.3单机版使用
目前的系统支持CT数据的自动生成，OMM服务器自动将数据备份到E:\NetNumen-TOMC\ums-svr\tkit\Ctback目录内，我们从此目录内取得对应时间段的CT数据即可进行问题信令的分析（目前CT工具记录数据有限可能会造成记录缺少的现象）。

在取得CT数据或手动跟踪得来的信令的同时，需要在本机上准备一套CT工具单机版，这样可以方便地进行脱线数据分析查询，对于单机上运行的CT工具，只需要COPY以下几个目录到本机即可运行：
1）E:\NetNumen-TOMC\ums-clnt\tools\zxwomc-tools-rnc\jdk-windows
2）E:\NetNumen-TOMC\ums-clnt\tools \zxwomc-tools-rnc\zxwomc-wsf-tkit-rnc 取得这两个文件夹后（可放在本机的任何位置），运行\zxwomc-tools-rnc\zxwomc-wsf-tkit-rnc目录下的run.bat或runsignal.bat都可以运行该工具。

第2章信令分析说明
为了更有条理地进行说明，本文将依据整个信令流程分成几个独立阶段进行描述。

在每个阶段中，先进行流程介绍，关键技术点分析，然后是信令的查看与解释以及重要信令参数说明以及常见问题的分析与排查。

而对于出问题时的处理方法如下：
◆首先比对标准信令过程，看看从哪一条信令开始和标准信令过程不吻合，查找实
现流程不吻合的原因；
◆排除流程原因后，查看是那一条信令出现异常。

从异常信令的位置开始往前，逐
条检查每条信令内容，和标准信令配置参数比对。

如果参数不一样，则先逐个排
除参数，将参数调整为一致，看看是否参数原因导致的异常
◆如果全部排除参数和流程的原因后，就需要从该流程原理以及代码实现上来排查
问题，以及当UE，NODEB，CN返回失败时，需要请这些设备的相关人员一起
定位问题。

主要阶段有以下几个：
◆RRC连接过程
◆NAS信令建立过程（初始直传信令过程）
◆鉴权过程（可选）
◆安全模式过程
◆SETUP过程
◆CALL PROCEEDING过程
◆RAB建立过程
◆呼叫释放过程
2.1 基本知识准备
2.1.1如何看业务信令
业务信令跟踪包括了Iu信令、IuB信令、UU信令，下面以以rrc Connection Request信令为例进行简单说明如何看业务信令：
信令内容可以在协议里面查询。

RRC协议在25.331，NBAP协议在25.433，RANAP协议在25.413，CN相关的协议在24008等
如上图中rrc Connection Request消息中的内容可以在25.331中查询。

比如InitialUE-Identity的详细相关内容。

InitialUE-Identity ::= CHOICE {
imsi IMSI-GSM-MAP,
tmsi-and-LAI TMSI-and-LAI-GSM-MAP,
p-TMSI-and-RAI P-TMSI-and-RAI-GSM-MAP,
imei IMEI,
esn-DS-41 ESN-DS-41,
imsi-DS-41 IMSI-DS-41,
imsi-and-ESN-DS-41 IMSI-and-ESN-DS-41,
tmsi-DS-41 TMSI-DS-41
(意为UE ID可以选择的内容)
说明如下：
Initial UE identity是在RRC连接建立时提供一个唯一的UE在空闲模式下的非接入层标识。

UCPM_C根据initial UE identity选择SCCPCH（RLC根据SCCPCH获取FACH信息）。

UE
对非接入层标识类型选择原则为：
若UE中的变量SELECTED_CN值为"GSM-MAP"，UE根据下列优先级在信息元素"initial UE identity"中选择"UE id type"：
1）TMSI（GSM-MAP）：TMSI若有效则选择。

当使用TMSI时信息元素"initial UE identity"中应包含信息元素"LAI"以保证其唯一性。

2）P-TMSI（GAM-MAP）：若无有效的TMSI（GSM-MAP）且存在有效的P-TMSI （GSM-MAP），则选择。

当使用P-TMSI时信息元素"initial UE identity"中应包含信息元素"RAI"以保证其唯一性。

3）IMSI（GSM-MAP）：若无有效的TMSI及P-TMSI（GSM-MAP），且存在有效的IMSI （GSM-MAP），则选择。

4）IMEI：若上述条件均不满足则选择IMEI。

注意：在使用时信息元素"TMSI(GSM-MAP)"、"P-TMSI（GAM-MAP）"、"IMSI （GSM-MAP）"，"LAI"和"RAI"应设置为与USIM或SIM存贮的相应标识值相等。

2.1.2流程中的几个重要概念
在进行信令分析之前，需要了先解几个重要的概念：
1）RRC连接
RRC连接是UE与UTRAN的RRC协议层之间建立的一种双向点到点的连接。

对一个UE来说，至多存在一条RRC连接。

RRC连接在UE与UTRAN之间传输无线网络信令，如进行无线资源的分配等等。

RRC连接在呼叫建立之初建立，在通话结束后释放，并在期间一直维持。

用于传输RRC消息的可用无线承载（RB）被定义为“信令无线承载（SRB）”。

UE和UTRAN应为在DCCH和CCCH上使用RLC-TM、RLC-UM 和RLC-AM的RRC消息来选择信令无线承载。

2）Iu信令连接
如果说RRC连接建立了UE与UTRAN之间的信令通路，那么Iu信令连接则是建立了UE与CN之间的信令通路。

Iu信令连接主要传输UE与CN之间非接入层信令。

在UTRAN中，非接入层信令是通过上下行直接传输信令透明传输的。

3）鉴权加密
出于网络安全性能考虑，在呼叫建立时，网络必须对UE进行鉴权和加密。

（Authentication and ciphering）
4）无线接入承载（RAB）
RAB可以看作是UE与CN之间接入层向非接入层提供的业务，主要用于用户数据的传输,包括IU承载和RB承载。

RAB直接与UE业务相关，它涉及接入层各个协议模块，在空中接口上，RAB反映为无线承载（RB）。

（Radio Access Bear）5）无线承载（RB）
RB是UE与UTRAN之间L2向上层提供的业务。

上面我们提到的RRC连接也可以看作是一种承载信令的RB。

（Radio Bear）
6）无线链路（RL）
无线链路是指一个UE和一个UTRAN接入点之间的逻辑连接。

（Radio Link）
2.2 RRC建立过程的信令分析
2.2.1 RRC Connection Request信令综述
UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。

每个UE最多只有一个RRC连接。

当RNC接收到UE的RRC CONNECTION REQUEST消息，由其无线资源管理模块RRM 根据特定的算法(CAC算法)确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。

对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。

基本流程如下：
相对应在，在信令跟踪工具内看到的过程如下图（此为手动信令跟踪得来，没有打开内部消息跟踪）：
如果对应的TKIT内自动生成的CT数据，则过程如下：
图中：FP为帧协议（Node B与RNC同步使用，此时的同步只是新的无线链路的同步，并不是整个Node B与RNC的同步）
下面逐个对相关的信令进行分析：
2.2.2 RRC Connection Request信令
首先来看RRC Connection Request信令，它是UE在上行CCCH上发送一个RRC Connection Request 消息，请求建立一条RRC连接，它的整体结果如下图所示：
可以将RRC Connection Request信令为成以下几个部分：
1）initial UE_Identity
2）establishmentCause
3）protocolErrorIndicator
4）measureResultOnRACH
5）NoCritialExtension
展开initial UE_Identity消息，内容如下图所示：
Initial UE Identity中含有初始的UE标识，如IMSI、TMSI and LAI、PTMSI and RAI等参数，用来让网络识别发送该建立请求消息的UE。

在本例中，PTMSI=C2748BCE、MCC=460、MNC=07、LAC=02、RAC=01，其中RAC占1个8位的字节、LAC占2个8位的字节、PTMSI 占4个8位的字节
establishmentCause为系统间的重选（TRRC_interRA T_CellReselection，RRC建立原因，有多种类型，但UE每次只能选择其一RRC建立的方式，而对于RRC建立的方式，系统上可以进行设置，中兴的系统目前的设置有三种类型：强制FACH、强制DCH、不强制）RRC建立的原因有以下几种（参见协议25.331 P516）：
●Originating Conversational Call（主叫会话类）
●Originating Streaming Call（主叫流类）
●Originating Interactive Call（主叫交互类）
●Originating Background Call（主叫背景类）
●Originating Subscribed traffic Call（主要类）
●Terminating Conversational Call（被叫会话类）
●Terminating Streaming Call（被叫流类）
●Terminating Interactive Call（被叫交互类）
●Terminating Background Call（被叫背景类）
●Emergency Call（紧急呼叫）
●Inter-RAT cell re-selection（系统间重选择）
●Inter-RAT cell change order（系统间重置）
●Registration（注册）
●Detach（分离）
●Originating High Priority Signalling
●Originating Low Priority Signalling
●Call re-establishment,
●Terminating High Priority Signalling
●Terminating Low Priority Signalling
●Terminating – cause unknown, MBMS reception, MBMS ptp RB request
protocolErrorIndicator协议错误指示为无错误（注：此项目为一Boolean值，TRUE表示有协议错误发生；FALSE表示没有协议错误发生。

缺省值为FALSE。

UE在启动RRC建立过程时应设置该变量为缺省值。

）
IE measureResultOnRACH则主要表明了当前的测试结果，其中的currentCell则表示当时服务小区的测试结果，而此测试结果是以-116dBm为基准，测时的绝对值等于测量值+（-116），在本例中，测量的PCCPCH-RSCP值等于-116加上42，结果为-74dBm。

扩展内容不存在实际的分析意义，在这里不再描述。

2.2.3 Radio Link Setup信令
Radio Link Setup Request是由RNC发向Node B的信令，这个过程用于在Node B中为新的
Node B通信上下文建立必需的资源。

由CRNC通过Node B控制端口发送到Node B的，建立一条包括一条或多条传输信道的无线链路。

请求NodeB分配RRC连接所需要的特定无线链路资源，在RL获得Uu接口上行同步之前，Node B用消息中指定的初始下行功率在RL中每个时隙，每个下行DPCH发起下行传输。

在这期间不用内环功率控制。

随后，下行功率将依据内环功控而变化，但将始终保持在RADIO LINK SETUP REQUEST消息所指定的最大和最小功率范围内。

在这个过程中，如果Node B收到了Radio Link Setup Request，此时分析LMT数据可以看到如下图（并且很快就回Radio Link Setup Response消息）：
（注：此小区第三个载频为HS频载，TS0上的6个码道为公共信道，TS1上的为PRACH 和HS-SICH的二个码道，TS4和TS5上为HS-PDSCH的各16个码道，TS6为HS-SCCH的4个码道）
Radio Link Setup Request信令结构如下图：
其中tProcID消息的说明如下图所示：
uL_CCTrCH_InformationList_RL_SetupRqstTDD (上行CCTrCH信息列表-RL建立请求的)的分析如下：
在这里我们可以得到的参数有：
1）上行SIR目标值参数：uL_SIRTarget，测量值除10即可
2）TFCI的分割方式：no_Split_in_TFCI，当其值为1时不分割，当其值为2时分割。

本例中其值为2，如下图所示：
在分割成的两个部分（elem[0]和elem[1]）内含有以下几个参数
●上行链路增益因子（BETA）：协议25.331的10.3.6.55中明确RACH只有一个TF，
因此只有一个BETA，取值范围为0~15，本处取值为1（注意：在本例的两个
部分中，只有elem[1]有上行链路增益因子）
●传输格式组合个数（ctfc2bit）
●算出的传输格式组合（refTFCNumber）
参数表示如下图：
而在tdd_UL_DPCH_TimeSlotFormat_LCR 中我们可以得到QPSK时隙格式，在本例中为17，如下图所示：
对于上行链路，QPSK和8PSK的取值范围协议中规定如下：
时隙格式的具体计算在协议25.221中，详细见P18（5.2.2.6 Timeslot formats），下面附上本例中使用的上行QPSK时隙格式（表中用红色加粗表示出）：
Timeslot formats for the Uplink
（注意：第90号时隙格式仅用于HS-SICH中）
dL_CCTrCH_InformationList_RL_SetupRqstTDD (下行CCTrCH信息列表-RL建立请求的)的分析如下：
基本结构与上行一致，但这里面有几个我们需要注意的参数：
●无线链路所在的时隙位置：timeSlotLCR
●无线链路下行的时间格式：tdd_DL_DPCH_TimeSlotFormat_LCR （本例=17）
●下行初始传输功率：initial_DL_Transmission_Power（本例为-130）
●下行最大发射功率：相对于PCCPCH
●TSTD使用指标：tstdIndicator （取值有两种，inactive和active两种）
●下行最小发射功率：相对于PCCPCH
对于下行时隙格式的具体计算也在协议25.221中，详细见P18（5.2.2.6 Timeslot formats），下面附上本例中使用的上行QPSK时隙格式（表中用红色加粗表示出）：
Time slot formats for the Downlink
（注意：本文上下行时隙格式均取自25221协议的R6版本，可能与R4有所不同）dCH_TDD_Information 消息解释：
另外两个参数：
●pre_emptionCapability = TNBAP_may_trigger_pre_emption
●pre_emptionVulnerability = TNBAP_not_pre_emptable
分别解释如下：
这两个参数与priorityLevel参数，一起表示分配或保持（抢占）Node B 的内部资源的优先级（组合），都在协议25.433的第167页第9.2.1.1A章节。

同时在dCH_TDD_Information中我们也可以查出建立的业务类型与速率配置情况，主要在dCH_TDD_Information消息中的ul（DL）_TransportFormatSet 分消息中，下面以ul_TransportFormatSet（此消息定义了与一条传输信道相关的一组传送格式集合）为例进行解释如下图：
在这部分消息中从传输块的大小区基本上可以判断业务的类型，计算方法如下：
信令速率：[148（transportBlockSize）- 4（MAC Header）- 8（RLC Header）] / TTI （10ms）=13.6 kbps （高速信令），通过计算常的值有PS业务的80、65、103等，336为会话类。

下面我们来说Radio Link Setup消息最后一条分消息rL_Information_RL_SetupRqstTDD，对我们来说这里面最有用的只有一条，即服务小区的主频点，如下图所示：
2.2.4 Radio Link Setup Response信令
Node B根据Radio Link Setup Request消息的参数，来建立NODEB的上、下行无线链路，配置成功后，NODEB发送Radio Link Setup Response响应消息给SRNC。

另外也可能存在不成功的机会，如果不成功，则回信令RADIO LINK SETUP FAILURE，我们先来看成功时的信令解释：
这里面对优化有意义的是无线链路占用的时隙参数timeSlotLCR，在这里这个参数为3，表示链路建立在3时隙上（上行时隙），另外则是ISCP值，在这里值22，它表示实际值为-94dBm，也就是表示加上-116即为实际值的大小。

2.2.5 Radio Link Setup Failure信令
没有找到相关的信令，如有再加入
但在这个信令里的失败原因是我们需要关注的，原因有以下几种：
●unknown C-ID,
●Cell not available,
●Power level not supported,
●DL radio resources not available,
●UL radio resources not available,
●RL Already Activated allocated,
●Node B Resources Unavailable,
●Measurement not supported for the object,
●Combining Resources not available,
●Requested configuration not supported,
●Synchronization failure,
●Priority transport channel established,
●SIB Origination in Node B not Supported,
●Requested Tx Diversity Mode not supported,
●Unspecified,
●BCCH scheduling error,
●Measurement Temporarily not Available,
●Invalid CM Setting,
●Reconfiguration CFN not elapsed,
●Number of DL codes not supported,
●S-CPICH not supported,
●Combining not supported,
●UL SF not supported,
●DL SF not supported,
2.2.6 RRC Connection Setup信令
RRC connection setup信令是RNC通过Uu口向UE传送的一条信令，属于下行信令，主要有initialUE_Identity 和criticalExtensions 两部分消息组成，而initialUE_Identity较为简单，如下图所示：
在本例中是PTMSI来进行标注的，实际上有几种方式，PTMSI方式、IMSI方式、TMSI 方式等，所以上图中的U部分也有可能变化为IMSI或TMSI。

下面我们重点对criticalExtensions信令进行分析解释，由于这条信令较为庞大，我们也将之分成多个部分，其组成图如下：
1）rrc_StateIndicator项：指标了UE将要进入的状态，UE将进入由IE“RRC State Indicator”指示的状态，即使在接收到的消息中包含有仅用于其他状态的IE。

例如，如果RRC state indicator被设置为CELL_FACH，而其它IE由于提供了专用信道配置信息，那么UE应当进入CELL_FACH。

然而如果UE没有获得由IE“RRC state indicator”指示状态所需的配置信息，那么UE可以认为所要求的配置无效。

2）utran_DRX_CycleLengthCoeff参数：取值范围3~9，主要用来计算寻呼时段和PICH侦听时段，其意为对于某一特定的UE，两个寻呼时机之间的时间间隔。

3）分消息srb_InformationSetupList：
这个消息内建立了4个SRB，对SRB0进行查看（如上图），SRB0是UM模式，同时我们也可以从rb_MappingInfo中查看其映射情况，如下图所示：
从图中可以看出SRB0，上行即映射到了DCH上也映射到了RACH上，而下行即映射到DCH上也映射到FACH上。

而其它SRB的映射与之基本相同，不再重述，但在SRB1上我们可以看到不同于SRB0的一些信息，重点是rlc_InfoChoice里面的内容：
Rlc_InfoChoice上行链路的说明如下图：
其它的SRB基本与之一样，不再详述。

4）ul_AddReconfTransChInfoList分消息中，参数如下：
5）dl_AddReconfTransChInfoList消息中的参数：
6）frequencyInfo消息中有用的参数：
7）ul_ChannelRequirement消息内参数：
9）v4d0NonCriticalExtensions消息中的信息参数：
2.2.7 Radio Link Restore Indication信令
RNC一旦收到从NODEB发来的Radio Link Restore Indication消息，说明UE和NODEB间同步已经完成。

此信令中并无我们需要的信息，它只是起到标志的作用。

2.2.8 RRC Connection SetupComplete信令
此消息是UE发给RNC的上行信令，发送的信道为上行DCCH信道，标志着RRC连接过程的结束，在此信令中的主要参数有以下几个：
1）RRC transaction identifier：RRC事务标识。

2）START list：开始列表，包含CN域标识和开始值列表信息。

3）UE radio access capability：UE无线接入能力。

4）UE radio access capability extension：UE无线接入能力扩展。

5）UE system specific capability：UE系统能力。

2.2.8 RRC建立过程中常见问题
●RNC收不到RRC连接请求
现象：
UE一直上报RRC CONNECTION REQ, 但后台信令跟踪上看不到任何信令过程。

常见原因：
1）随机接入过程出现问题，可能存在UpPCH的干扰，
（1）首先检查NODEB的RACH统计有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCH干扰。

（2）通过CT工具检查UPPCH上的干扰
（3）通过性能统计，查看UPPOS上的UP干扰统计
2）终端问题，重启UE看能否接入
3）Node B 问题：重启基站
●RRC连接拒绝
在25331协议里，对于RRC连接拒绝的原因，只有规定如下：
目前看到的数据里大部分都是congestion，只有少量的unspecified.
常见原因：
◆调用数据库接口获取RUP的板号失败，如板子故障闭塞等。

为该UE建立呼叫，需要
轮选合适的用户面板，来建立用户面实例，如果获取不到，则会失败。

其特征为LOG 中UCPMC模块出现“UCIC: Inst %d rcvd GetRupAck with FALSE.”打印
◆无线链路建立失败，导致RRC连接拒绝。

其特征为LOG中UCPMC模块出现“UCIC:
Inst %d receive one FAIL Rl Setup Resp!”打印。

有可能是Iub口，NODEB反馈无线链路建立失败，也有可能是Iub口无线链路建立成功后FP进行传输同步失败。

前者观察信令跟踪，即可发现NODEB返回的是无线链路建立失败，此时需要检查无线链路建立的参数是否正确，在NODEB侧定位失败原因。

后者的特征是LOG中RLMM模块出现”Rcvd Fp Fail Indication!”打印,那么首先要在用户面看同步帧发送出去没有，排除RNC 发送处理问题；其次看NODEB用户面收到没有，排除Iub口传输问题；然后看NODEB 回同步帧没有，排除NODEB发送处理问题；然后看RNC收到没有，最后看收到的帧正确否，其中任何一个环节出问题都会导致同步失败。

●RRC CONNECTION SETUP消息发下后，收不到RRC CONNECTION SETUP
COMPLETE
现象：RNC发了RRC CONNECTION SETUP消息，但是收不到UE的RRC CONNECTION SETUP COMPLETE消息，UE反复上RRC CONNECTION REQUEST
常见原因：
◆RRC CONNECTION SETUP COMPLETE消息是呼叫过程中DCH上的第一包数据，收
不到此消息说明DCH的配置有问题，查看Radiolink Setup中的传输格式、时隙格式等参数。

造成此问题的原因可能有两个方面：NODEB本身的原因和RNC参数配置的原因。

RNC参数配置，需要检查是否是默认配置参数，以及检查Iub口配置和Uu口配置参数是否一致。

◆随后在观察UE的处理，是没有收到RRC CONNECTION SETUP,还是收到了RRC
CONNECTION SETUP后，发送了RRC Connection Setup Complete而RNC没有收到。

前者关注下行，后者需要关注上行的实际处理以及环境干扰情况。

RNC参数对该现象影响比较大的主要是同业务相关的初始发射功率，最大和最小发射功率。

◆查看DFP上是否收到错包，如果连错包也没有收到，则需要从NodeB查起。

如果DFP
上收到有长度错的包，则说明控制面给用户面、NodeB的DCH参数不一致，通常情况是给NodeB的参数说明FP帧不包含CRC，而给用户面的参数说明FP需要CRC校验。

2.3初始直传信令分析
Iu口信令流程是在UE与UTRAN之间的RRC连接建立成功后，UE发起的。

RRC连接过程建立了RNC与UE之间的信令通道，而Iu信令连接则建立了UE与CN之间的信令通路。

主要传输UE与CN之间非接入层信令。

在UTRAN中，非接入层信令是通过上下行直接传输信令透明传输的，RNC不做任何处理。

UE发送到CN的消息，通过上行直传（Uplink Direct Transfer）发送到RNC，RNC将其转化为直传消息（Direct Transfer）发送到CN；CN发送到UE的消息，通过直传消息发送到RNC，RNC将其转化为下行直传消息（Downlink Direct Transfer）发送到UE。

具体信令流程如下：
大致信令流程描述如下：
（1）RRC连接建立后，UE通过RRC连接向RNC发送初始直传消息（Initial Direct Transfer），消息中携带UE发送到CN的NAS信息内容。

此过程由UE发起，用于在上行链路上建立一条信令连接，在无线接口上传送初始的非接入层（NAS）消息。

UE在UL DCCH上使用AM RLC方式由RB3向UTRAN发送此消息。

（2）RNC接收到UE的初始直传消息，通过Iu接口向CN发送SCCP连接请求消息（CR），消息数据为RNC向CN发送的初始UE消息（Initial UE Message），该消息带有UE发送到CN的消息内容。

（3）如果CN准备接受连接请求，则向RNC回SCCP连接证实消息（CC），SCCP连接建立成功。

RNC接收到该消息，确认信令连接建立成功。

如果CN不能接受连接请求，则向RNC 回SCCP连接拒绝消息（CJ），SCCP连接建立失败。

RNC接收到该消息，确认信令连接建立失败，则发起RRC释放过程。

（4）信令连接建立成功后，UE发送到CN的消息，通过上行直传消息（Uplink Direct Transfer）发送到RNC，RNC将其转换为直传消息(Direct Transfer)发送到CN；CN发送到UE 的消息，通过直传消息（Direct Transfer）发送到RNC，RNC将其转换为下行直传消息（Downlink Direct Transfer）发送到UE。

从信令跟踪工具上的流程如下图所示：
下面对各个信令进行逐个分析：
2.3.1 InitialDirectTransfer信令分析
这个信令是通过Uu口的上行信令，简单地翻译之为初始直传信令，里面含有如下信令参数：
●Integrity check info：整体性校验信息，包含了XMAC-I和MAC-I计算所需的
RRC信息序列号。

●CN domain identity：CN域标识，标明是PS域或CS域。

●Intra Domain NAS Node Selector：NAS域内节点选择，为被寻址的CN域在节
点中选择路由。

●NAS message：NAS消息，在UTRAN中透明传输。

从图中可以看到，其实这条信令对网络优化的意义并不是很大，对优化有的用信令主要有两个：
1）业务类型
2）主叫号码的IMSI
2.3.2 InitialUEMessage信令分析
RNC接收到UE的初始直传消息（InitialDirectMessage），通过Iu接口向CN发送SCCP连接请求消息（CM Service Request），消息数据为RNC向CN发送的初始UE消息（Initial UE Message），该消息带有UE发送到CN的消息内容。

信令分析如下图所示：
2.3.2 CommonID信令分析
CommonID信令其实是安全控制部分的信令，但这里我们对之先进行分析，这一过程的目的是将用户的permanent NAS UE Identity（如IMSI）告诉RNC，详细的信令解释如下图：。