鼎立后台分析

鼎立后台分析1常见信令流程：
2信令解析：
1系统消息
UMTS-FDD模式下的SIB消息所承载的信息列表如下：SIB1:非接入层信息,如CS域,PS域
SIB2:URA标识(与URA_PCH状态有关)
SIB3:空闲模式下广播小区选择和小区重选信息
SIB4:连接模式下广播小区选择和小区重选信息
SIB5:空闲模式下广播配置公共物理信道的参数信息
SIB6:连接模式下广播配置公共物理信道的参数信息
SIB7:与随机接入相关的参数信息
SIB8:FDD制式下的CPCH配置和功率信息
SIB9:FDD制式下的CPCH接入相关的参数信息
SIB11:空闲模式下广播与测量相关的控制信息
SIB12:连接模式下广播与测量相关的控制信息
SIB16:无线承载,传输信道和物理信道的参数信息
SIB18:广播邻区列表中的小区所属PLMN的标识
1MIB消息
MIB中主要包含了SIB信息的调度信息，具体信令内容如下：
2SIB1
SIB1中主要包含非接入层信息及UE在空闲及连接状态的计时器。

在SIB1中，cn-CommonGSM-MAP-NAS-SysInfo表示的当前的系统LAC号，这里为C7 D4，即51156；CS gsm-MAP:0D 01，则有两层含义，其中，0D代表了T3212计时器的取值，这里0D转换为十进制为13，即T3212=13*6=98min，而01则代表了ATT （Attach-detach allowed）的取值，这里01表示允许在该网络中进行IMSI附着及去附着。

PS gsm-MAP:D4 01也包含两层含义，其中D4代表RAC，即212，01代表NMO （Network mode of operation），这里01表示NMOⅡ。

附：
ATT参数简析：IMSI分离过程是指移动台向网络通告它正从工作状态进入非工作状态（通常指关机过程），或SIM卡已从移动台中取出的过程。

网络在收到移动台的通告后将指示该IMSI用户处于非工作状态，因此以该用户作为被叫的接续请求将被拒绝。

与分离过程相应的是IMSI结合过程，它是指移动台向网络通告它已进入工作状态（通
常指开机过程），或SIM卡再次被插入移动台。

移动台重新进入工作状态后将检测当
前所在位置区（LAI）是否和最后记录在移动台中的LAI相同，若相同则移动台启动IMSI结合过程，否则移动台启动位置更新过程（代替IMSI结合过程）。

网络接收到位置更新或IMSI结合过程后，将指示该IMSI用户正处于工作状态。

参数ATT用于通知
移动台，在本小区内是否允许进行IMSI结合和分离过程。

NMO模式简析：网络操作模式（Network Operation Mode, NOM 或者 Network Mode of Operation NMO）一共分为三种，但W支持前两种，即 NOM I：支持 combined procedure，简单说就是能够利用 Routing Area Update Procedure 完成 Location Update Procedure，很多情况下如果 RAU 失败了，手机会继续尝试 LU，该模式要求
核心网具有Gs接口；NOM II：RAU 和 LU 是分开进行的，互不干扰，互不知晓，目前很大一部分网络工作在此类网络操作模式下。

图3 SIB1中包含的连接及空闲状态下的计时器及计数器
SIB1中还会通告UE在连接及空闲状态下使用的计时器及计数器，各参数作用如下表所诉：
3SIB3
SIB3主要包含一些小区选择、重选等信息。

图4 SIB中关于小区重选的信息
图5 小区访问限制信息
在SIB3中包含小区访问限制信息，一般被Barred的小区只允许切换但不允许用户接入，而预留小区只允许部分特殊用户接入。

参数：wips贴图
4SIB5
SIB5主要承载了小区公共信道的一些配置信息，包括PRACH、AICH等。

图6 SIB5中关于PRACH信道的一些信息
图7 SIB5中关于PRACH及AICH的一些信息
图8 SIB5中小区HSPA能力指示
5SIB7
SIB7中主要包含小区上行干扰值。

图9 SIB7中的主要信息情况
6SIB11
SIB11中主要包换邻区信息，具体如下：
图10 SIB11同频邻区信息
图11 SIB11中的异系统邻区信息
2RRC建立
1rrcreq
为了成功呼叫，UE将发起RRC连接建立过程，建立起与RNC之间的信令连接。

图12 RrcConnectionRequest信令
其中，常见的有这么几类：语音主叫（Originating Conversational Call）、语音被叫（Terminating Conversational Call）、短信发送（Terminating High Priority Signalling或Terminating Low Priority Signalling）、短信接收（Terminating Low Priority Signalling）、FTP下载（Originating Background Call）、注册（Registration）。

图15 信令主要内容之终端能力指示
在这里，终端会上报自己支持的网络版本，如此处的Rel-5，就标识UMTS 的R5版本，如果是一个支持HSUPA的终端，它此处就会填入Rel-6。

2radiolinksetup
如上图所示在RRCreq和RRCsetup之间需要在IUb口建立radio link 链路，每
个radiolink链路都有自己的RLid，同时会上报RTWP给nodeb，反应上行的干扰情况。

在radiolinksetupresponse中可以区分该小区采用的是ATM技术还是FE，如果transpertLayerAddress=0x45………………（ATM）/0xXX………………（FE）。

这里
也可以看到该radiolink的ID和SETID。

利用RLid可以在分析过程中找出那条链路出现问题。

3rrcsetup
以上为 RrcConnectionSetup信令内容，其中U-RNTI为网络侧为UE分配的网络临时标识符，用于在UTRAN中唯一的标识UE。

Rrc-StateIndicator用于指示RRC连接的状态，这里显示的是当前的RRC连接处于CELL-DCH状态，其下的DRX为不连续接受周期系数，主要在UE监听寻呼信道时使用。

图18 信令主要内容之SRB配置信息
在一个典型的AMR12.2K语音中，会建立3个DTCH和4个DCCH，其中，DCCH承载在SRB之上，这里信令中给出的，就是SRB的一些信息。

关于RB，W系统中，总共可以建立32条，其中，0~4，用于SRB，而0是
用于CCCH的，1~4用于DCCH，这里，信令中给出的就是1~4号SRB的配置信息，其中，红框里面的，是表示其RLC的传输模式，在RLC的传输模式中，共有3种，分别是确认模式（AM）、非确认模式（UM）及透明模式（TM），由图中可
以看出，SRB 1#，使用的是UM即非确认模式，在DCCH使用的4个SRB中，只
有SRB 1使用UM模式，其他的都是用AM模式。

由于SRB内容的复杂性，这里
就不详细介绍其他内容了。

图19信令主要内容之上行信道信息
其中，maxAllowedUL-TX-Power为上行允许的最大发射功率，这里是24dBm，其下的scramblingCodeType中，指明了上行使用的扰码类型及扩频因子长度，这里，上行使用longSC（长扰码），扩频因子为64（即sf64）。

图20 信令主要内容之下行信道信息
与上行信道信息向对应，这里主要给出了下行信道的一些主要信息，primaryCPICH-Info为当前使用的主扰码，这里是361，sf-AndCodeNumber给
出了当前下行使用的扩频因子长度及编号，这里使用的是SF128:11，其中，
128代表扩频因子长度，11为使用的128个长度为128的扩频因子中的标号为
第11的扩频因子。

4rrcsetupcomplete
图22 信令主要内容
这里给给出了网络侧中CS几PS域的标识符，及UE对一些功能的支持情况。

Cs-domain及ps-domai分别代表CS域及PS域，pdcp-Capability主要是表明UE对PDCP协议（分组数据集中协议）的支持情况，重途中可以看出，这款UE
不支持losslessSRNS-Relocation（SRNS无损迁移）及RFC2507协议（该协议
用于IP包头压缩）；rlc-Capability主要说明了UE对RLC层的一些支持能力，如缓存大小，传输窗口大小及AM实体数目等，在此就不在详述。

图23信令主要内容
这里给出了手机的功率级别及对长度为512的扩频因子的支持情况，可以
看出，该UE的PowerClass为3，对长度为512的扩频因子不支持。

手机的功
率级别共有4级，既Class1、Class2、Class3和Class4，其对应的最大发射
功率分别为33dBm、27dBm、24dBm和21dBm，其中，在W中，Class3的终端最为最常见。

图24 信令主要内容
该部分主要描述了UE对多模式的支持，从中我们可以看出，该UE支持GSM，不支持多载波模式，支持上下行压缩模式的测量。

图25 信令主要内容
该部分表明了UE的HSDPA级别为6，也就是说最大支持3.6Mbps的下行速率。

根据UE硬件能力的不同，3GPP将HSDPA终端共划分了12个级别，每种级别分别对应不同的最大下行速度等，具体划分见下图。

图26 HSDPA终端分类
3NAS层信令连接
1 CM Service Request
该信令主要是表明了UE请求业务的种类并上报手机的Classmark。

图27 CM Service Request信令
图28 信令主要内容
CM Service Type主要表明了请求服务的种类，这里是普通正常呼叫，紧急呼叫及短消息发送会有不同的类型值，其下是上报的UE的Classmark。

2Authentication Request/Response
图29 Authentication Request/Response
该信令主要是用来鉴别用户的合法性的，防止非法用户接入网络。

UE在收到Authentication Request后，会通过其中提供的各种参数值，来计算一个新的密钥来，然后返回给网络侧，网络侧在验证通过后，鉴定用户为合法用户，允许其接入网络，否则将拒绝用户接入网络。

3 SecurityModeCommand/Complete
图30SecurityModeCommand/Complete信令
该信令主要是用来协商加密的，用来进行用户数据加密及完整性保护的。

4setup
1主叫setup
图31 Setup信令
图32 信令主要内容
该信令主要是上报UE支持的语音编码模式及被叫号码。

2被叫setup
3短信
5 Call Proceeding
图33 Call Proceeding信令
此信令表明网络侧已经接受了UE的呼叫连接信息。

且此时，网络侧向被叫发出寻呼信息。

6PDP激活/去激活
1激活
该条信令里面包含了很多信息：NSAPI、TI、PDPTYPE、PDP Address、APN、QOS等，另外在IUB口的消息里还有LAC、PLMN、RAC、SAC等消息。

2去激活
7RAB建立过程
1RABassreq/resp
2RBsetup/complete
该信令主要表示将根据用户申请的业务类型，为用户新建一个无线承载，其里面的内容，跟用户申请的业务及业务的QoS有关。

因其内容多是关于格式及映射的内容，多且复杂，在此就不详述了。

当UE收到RadioBearerComplete 时，表明其无线承载已经建立完成。

8 Alerting、Connect及Connect Acknowledge
图35 Alerting、Connect及Connect Acknowledge信令
当UE收到Alerting时，用户就可以听到振铃音了，当被叫用户接起手机时，主叫会收到Connect，当主叫应答后，即双方连接完全建立，主叫手机上发Connect Ackknowledge，表明一次呼叫成功建立。

9 Disconnect
当一次通话结束后，UE或网络侧会发出Disconnect信令，断开网络连接。

图36 Disconnect信令
图37 信令主要内容
在Disconnect中，会带有连接断开的原因值，这在判断是否为正常断开及异常断开问题确定上，是比较有帮助的，从上图可以看出，这是一次正常断开（Normal call clearing）。

10软切换
3问题发现与分析：
1 Active set update超时
详细情况如下：
第一次：1A不成功
14:28:43 ue占用主服务小区为排水总公司2小区，1a添加精益腐竹厂3
小区到激活剂中，trace查看，14:25:29，RNC下发ACTIVE set update （添
加精益腐竹3小区，扰码291），UE收到后上发ACTIVE set update complete，但是RNC没有收到。

10秒钟后RNC下发radio link deletion request，NodeB 回复radio
link deletion response，删除Radio link，RNC上发iu release，原因是Radio link connection with UE lost。

第二次：
14:33:41 ue占用主服务小区为排水总公司2小区，上报1B删除排水总公司1小区，
trace查看，14:30:28 RNC下发ACTIVE set update （删除排水总公司1小区，扰码4），UE收到后上发ACTIVE set update complete，但是RNC没有收到。

10秒钟后14:30:38 iurelease reqest（cause：Radio link connection with UE lost。

）
随后我们对这种情况进行了多次测试.
跨RNC成功率55.45%
解决方法: 打补丁。

2 Radio Link Failure Indication.
UE占用主服务小区为精益腐竹厂1小区，速率正常，上报1A添加保欣公
司2小区，添加两次不成功Radio Link Addition Failure，第三次添加成功。

随后删除保欣公司2小区，删除成功后iur口Radio Link Failure
Indication。

UE占用主服务小区为精益腐竹厂1小区，UE上报1A事件，添加前辛庄3小区到激活剂，RNC收到MR消息，RNC收到Radio Link Addition Request.和Radio Link Addition Response.在同一秒Radio Link Failure Indication.导致 iurelease。

解决方法:打补丁。

3 Radio Link Reconfiguration Cancel
UE主服务小区为市区纸库2小区，上报1D重配到西苑小区电信3小区，
无线环境良好的情况下两个node B向RNC上发radio link reconfiguration ready后，RNC直接向两个node B下发radio link reconfiguration cancel，RNC上发iu release（cause：unspecified failure），rrc connection release（cause：unspecified）
解决方法: 打补丁
4 radio link reconfigurantion failure
Trace时间11:37:25，ue占用市区朝阳路排水泵站3小区，上报1d事件，主服务小区从市区朝阳路排水泵站3小区向西小庄变更，node B上发radio
link reconfiguration failure（cause：unspecified failure）并且RNC下
发radio link reconfiguration cancel，同时node B上发radio link
failure indication（cause：unspecified），随后连续2次radio link reconfiguration failure和radio link reconfiguration cancel的现象，RNC上发iu release（cause：unspecified failure）
解决方法: 打补丁。

5 RB重配超时
该现象主要表现为：
RNC下发Radio Bearer Reconfiguration，UE并上报Radio Bearer Reconfiguration compelte ，但是RNC未收到该消息，10秒钟后超时RNC上行iurelease request
详细情况如以下两次：
第一次：RB重配超时
UE主服务小区占用烈士林园1小区，UE上报1D事件，主服务小区变更为龙潭宾馆2小区，RNC下发Radio Bearer Reconfiguration，UE收到后上报Radio Bearer Reconfiguration compelte ，但是RNC未收到该消息，10秒钟后超时RNC上行iurelease request （cause：release due to utran generated reason）
第二次：RB重配超时
09:59:06 主服务小区占用龙潭宾馆2小区（扰码=254、ECIO=-9/RSCP=-81）,上报1D事件，主服务小区要重配烈士陵园1小区（扰码=105、ECIO=-6/RSCP=-78），RNC在9:55:52收到1D并下发radio bearer reconfiguration,UE收到radio bearer reconfiguration，并向RNC上发radio bearer reconfiguration complete 但是RNC未收到，10秒钟超时iurelease。

解决方法:打补丁
6 RNC收到1D事件无响应
UE占用主服务小区烈士林园1小区（扰码105），上报1D事件，主服务小区变更为龙潭宾馆2小区（扰码254），RNC收到1D Measurement Report事件，此时无线环境[SCC: 105, EcIo: -4 dB, RSCP: -74 dBm,] [SCC: 254, EcIo: -14.5 dB, RSCP: -84 dBm,]但RNC是未做任何处理，之后主服务小区烈士林园
1小区信号变差，导致iurelease。

解决方法:打补丁
7 IU-release-command after RANAP SRNS context response
该现象主要表现为：
在无线环境良好的情况下，核心网向RNC下发RANAP SRNS context request ，RNC上行回复RANAP SRNS context response，随后核心网下行 iu release command。

详细如以下两次现象描述：
第一次：
16:41:49 Ue占用排水总公司2小区（psc=132、ECIO=-12.5、RSCP=-76）,无线环境良好，速率正常良好，如下图：
16:41:54 添加了新河酒店2小区、华电二校1小区、精益腐竹厂3小区到激活集，并且都添加成功。

此时速率正常，无线环境良好。

之后删除华电二校1小区，之后20秒UE上报信息RNC未收到。

TRACE查看，从16:38:42（trace时间）删除华电二校1小区成功后，从16:38:42到16:39:04在这20秒内未收到ue上报的任何信息，在16:39:04核
心网向RNC下发RANAP SRNS context request ，RNC上行回复RANAP SRNS context response，随后核心网下行 iu release command（原因normal release ），在同一秒16:39:04 RNC下行rrc connection release （cause：normalevent）
第二次：
主服务小区占用精益腐竹厂1小区，无线信号良好，上报1B删除精益腐竹厂2小区和排水总公司1小区，删除后7秒钟核心网下行RANAP SRNS context request ，上行回复，RANAP SRNS context response，随后核心网下行 iu release command，在同一秒核心网下行rrc connection release （cause：normalevent）
解决方法：SGSN会下发SRNS context request，RNC回复SRNS context response消息，然后SGSN下发iu release command，原因是normal。

TAC认为该信令的出现，理论上来讲是在FACH状态发生跨RNC流程，但是从UE和call trace来看，只能看到速率为0，不知道怎么判断进入FACH状态。

8 UE上报MR（1A/1D）消息RNC未收到
第一次：
16:06:37 占用主服务小区排水总公司2小区上报1A事件添加精益腐竹厂3小区到激活集中，随后速率将为0，UE上报的MR消息（1A、1D），RNC都未收到，导致信号在排水总公司2小区信号变差拖死。

Trace查看该段时间无信令，20秒钟后iu release（cause：radio connection with ue lost）。

第二次：
UE 占用主服务小区为西苑小区电信2小区(RNC223)，信号良好，上报1D 事件主服务小区变更为西苑南区1小区（RNC222）,但RNC 未收到1D 消息，20秒钟后iurelease （cause ：radio connection with ue lost ）。

解决方法：打补丁。

9 IU-release-request cause of
Relocation_Failure_in_Target_CN_RNC_or_Target_Syste m
UE占用开源铁塔厂3小区，无线环境良好，17:19:42手机删除原RNC在激活集中的小区付村1小区，此时激活集中无原RNC小区，10秒钟后RNC下发UTRAN Mobility Informationrelocition， 5秒钟计时无响应iurelease Cause : Relocation_Failure_in_Target_CN_RNC_or_Target_System
解决方法：
10未上报1D即重配无线环境差小区
09:19:11:859，手机上报1d事件，要求更换主服务小区为市区公交社区1小区（psc = 90），
09:19:14:921，系统下发radio bearer reconfiguration，信息内显示重配置公交社区1（psc = 90），
09:19:15:656，ue上报radio bearer reconfiguration complete信令。

09:19:23:312，系统再一次下发radio bearer reconfiguration，信息内显示重配置瑞祥综合楼2小区（psc = 153）,但此前的6个measurement report中（trace中只显示了5次）并没有上报1d事件,而是上报的1b事件（删除psc = 153）。

09:19:23:640，此时重配至PSC = 153小区完成。

但是该小区无线环境很差。

EcIo在-16dB左右。

09:19:23:968，此处发生了激活集更新信令，把激活集中信号较好的psc = 90删除掉了，而此前通过信令查看并未发现1b该小区的事件。

随后随着psc = 153的小区（瑞祥综合楼2小区）EcIo不断恶化，导致Iu release，cause值如图。

解决方法：打补丁。

11 二次RAB导致掉线
UE在进行数据业务跨RNC切换后，在没有relocation的情况下，核心网
下发二次RAB Assignment request消息，RAB建立失败导致数据业务掉线。

UE上发Activate PDP context request后，在15:41:46.158核心网第一
次下发RAB Assignment Request，RAB ID=0x05，如图1所示。

图1
在15:41:46.885时刻时，RNC上发RAB Assignment Rsponse，回复核心网RAB（RAB ID=0x05）建立成功，如图2所示。

图2
在15:42:06.655时刻，UE由瑞祥综合楼2小区（PSC=153，LAC=45345），跨Iur切换到市区车管所_电信1小区（PSC=6，LAC=45346）。