ZXTR RNS故障排查指导手册(业务类分册)(XXXX-R10)

1、 图 2.24。图 STYLEREF 2 s2.2SEQ 图 * ARABIC s 24 IuPS UserPlane数据对接流程CS业务排查流程CS业务排查流程见REF _Ref189448279 h图 2.25。图 STYLEREF 2 s2.2SEQ 图 * ARABIC s 25CS业务排查流程UE开机注册失败排查流程UE开机注册失败排查流程见REF _Ref189448348 h图 2.26。图 STYLEREF 2 s2.2SEQ 图 * ARABIC s 26UE开机注册失败排查流程RRC连接故障排查流程上报过程简单介绍要像排查RRC连接上报困难，首先要了解UE的上报过程以及RN

2、C的处理过程。总体来说包括两个大的部分：随机接入过程；RNS的处理过程；随机接入过程随机接入过程相对简单，是耳熟能详的东西了，就不过多介绍了，不知道请自己找的文档看看吧，简单说明一下如何简单确定随机接入成功了？简单来说，就是UE在UpPTS上发送了SYNC-UL，NODEB在FPACH上发送了响应，这样UE就可以在RACH上进行上报RRC连接请求了。可以通过LMT来看UE是否上报了UP，基站是否在FPACH上响应了。方法如下：从lmt上也可以看到UE上报了UP,FPACH上也有包下发，注意要看是否有效签名个数和FPACH包是从0开始增加的，正常情况下如果从0开始增加，就说明UE可以和基站进行同

3、步；参考REF _Ref184202491 h图 2.27。图 STYLEREF 2 s2.2SEQ 图 * ARABIC s 27 LMT上关于IP和FPACH的截图RNS的处理过程介绍完了随机接入过程后，重点介绍RNS的处理过程。我们把RNS的处理分成基站和RNC的处理。UE上报了RRC连接请求消息后，首先发到TBPE单板上解出来，通过BCCS然后到IIA，通过中间传输传输到到RNC的SDTB单板，然后内部交换到IMAB单板，然后到小区建立了的RUB单板上解出来FP包，通过用户面送到RCB单板；排查流程图参考REF _Ref184203707 h图 2.28。图 STYLEREF 2 s2

4、.2SEQ 图 * ARABIC s 28 RRC上报困难排查流程TBPE单板上的RACH包在UE可以成功随机接入后，在RACH信道上上报了RRC连接请求，可以使用logview登陆到TBPE单板使用FpmHelp后通过命令FpmShowRachInfo查看TBPE单板上的包统计，正常情况如下红色标记：= Fpm Rach Info = * Fpm Rach Normal Info * dwRachRecvDspDataNum = 10* dwRachSendFPFrameNum = 10* dwRachRecvDLNodeSyncNum = 0* Fpm Rach Error Info *

5、dwRachULDataCrciErrNum = 0* dwRachULDataNotFindTrCHNum = 0* dwRachCrciNumErrNum = 0* dwRachFrameLenErrNum = 0* dwRachSendULFrameToMacErrNum = 0* dwRachULTfiErrNum = 0* dwRachULDataLenErrNum = 0* = Fpm Rach Info = *注意：FACH包出窗在查看FACH包统计的时候，可能会有FACH包出窗的情况出现，这时可以考虑修改私有数据表R_FACH中的ToWAS和ToWAE来改大窗口试试，同时在小区

6、参数中修改引用的索引。但是注意测试完毕后要修改回来。检查IIA和TBPE之间的包收发进行了TBPE和IIA之间的包收发测试，使用如下命令查看了包统计情况：TBPA上观察AAL2包数据统计函数 DispMACSAR(),主要可以查看gdwMacCount是否增加在TBPA上启动收发任务 sp TBPATopTaskEntry在IIA上启动外网自环 EnetOutLoopSet 1IIA上查看AAL2包统计数据： m2,用于查看两边收发包数据是否递增结果如下：AAL2 MAC收包总数:975, 发包总数:921, 错误总数:0value = 47 = 0 x2f = /IIA-m2AAL2 MAC

7、收包总数:984, 发包总数:939, 错误总数:0value = 47 = 0 x2f = /查看RNC和NODEB之间的接口板上PVC收发包RACH的AAL2通道上是否收发正常，在IMAB板上和IIA单板上都有一套命令可以查看PVC上是否有收发包的命令，这个命令在我们排查问题中很有帮助，这里在罗唆一下：AtmlmShowPvcByStatus：查看PVC配置IMAB-AtmlmShowPvcByStatusPVC (STATUS = 0) LIST:PVCID R_UNIT R_PHY R_VPI R_VCI B0_UNIT B0_PHY B0_VPI B0_VCI B1_UNIT B1_

8、PHY B1_VPI B1_VCI205 6 0 0 131 6 1 1 131 - - - -PVCs count is 180 which Status = 0.BSP_PrintSet 0 x20,1：打开统计功能apcReadIVT 0,R_PHY,R_VPI,R_VCI，查看RNC在OMCB这条PVC上是否给NODEB发送了数据；IMAB-apcReadIVT 0,0,0,131，重点关注：ITotCellsRx : 654481627ITotCellsTx : 654481618 /需要关注该统计是否在递增apcReadIVT 0,B0_PHY,B0_VPI,B0_VCI查看RNC

9、通过光口或IMA接收到NODEB回的OMCB的报文的统计用下面的命令；IMAB-apcReadIVT 0,1,1,131，重点关注：ITotCellsRx : 654594297ITotCellsTx : 654594345 / 需要关注该统计是否在递增RUB上是否收到了RACH包由于目前外场的RUB单板比较多，所以可以考虑闭塞RUB单板，仅仅剩下一块单板的方法来确定UE就在这块RUB单板上上报数据，使用RDS工具登陆RUB上，使用ShowRnluDetailStat查看：查看是否RACH上有包统计增长见REF _Ref189474574 h图 2.29。图 STYLEREF 2 s2.2SE

10、Q 图 * ARABIC s 29 RACH包统计RAB指派失败排查流程RAB指派失败排查流程见REF _Ref189450065 h图 2.210。图 STYLEREF 2 s2.2SEQ 图 * ARABIC s 210RAB指派失败排查流程PS业务类故障一般情况下，我们说PS业务有问题，前提是CS业务正常，如果CS业务都不正常，先处理CS业务问题。上节讲述的CS业务故障排查同样适用于PS业务，本节不再描述。本节重点针对数据包的分片、重组统计进行描述。目前RNC对于Iu-PS口的配置策略是在2个框上分别占用1块APBE单板，此单板上只使用一个光口配置Iu-PS，每个光口上配置2条IPOA及

11、其路由，这样就形成了40M*4=160M的负荷分担配置。RNC在建立Iu-PS承载时会在局内进行轮选，这样RNC上行数据在本业务生命周期内就只在此IPOA上进行发送，对于CN侧的处理，CN在下行发送数据包时对每个数据包进行轮选IPOA，实现数据包的负荷分担发送方式。所以也就是说RNC侧的负荷分担只是对业务的负荷分担而CN的负荷分担是对数据包的负荷分担。在3G系统中，数据业务下载速率达不到要求或流量为零，通常是困扰业务测试的重要问题，也是很难排查的问题，它牵涉到网元有核心网，RNC，NODEB，此外还牵涉到终端，应用层工具和外部网等，通常需要从系统的角度来排查，本文重点从无线接入网的角度提供几点

12、排查思路。PS的故障现象有：从外场应用和各种测试的经验看，影响速率的主要问题有：单板硬件问题；AAL5通道配置问题；Iu/Iub口带宽配置问题；空口参数问题；签约速率和DRBC问题；其他，如终端问题，RNC和NODEB版本问题，笔记本性能问题等等；用户面故障排查思路RNC系统中的分组域媒体流路径见REF _Ref189475094 h图 2.31。图 STYLEREF 2 s2.3SEQ 图 * ARABIC s 21分组域媒体流沿着上图中黑色箭头指示的方向，是分组域媒体流从Nodeb/RNC到CN的方向，CN到Nodeb/RNC的方向刚好相反，这里不画出来了。上图中，黑色线表示Iub/Iur

13、口分组域媒体流，蓝色线表示Iu口PS域媒体流。分组域媒体流到达RNC系统时，首先到达APBE单板，APBE简单处理之后，传给RUB单板，RUB单板在用户面处理之后，传给RGUB单板。分组域媒体流和ZXWR RNC MCS子系统中的APBE、RUB和RGUB单板都有关。从上图我们可以看出，问题排查的关键技术点。我们可以在CN、RNC、NODEB控制和排查的问题有HLR（归属位置寄存器）签约，GTPU，PDCP，RLC，MAC，FP，物理层，空口参数（功率）。相关参数设置1、HLR签约，找到CN的HLR受理台，找到对应的UE，查看UE的上下行链路的速率是否是你期望的值。另外注意一下有保证速率和传输

14、延迟。保证速率可以比你签的速率小一些，如384，保证速率可以是64，传输延迟一般10ms。2、检查OMCR上PS相关的配置数据，查看路由配置是否正常。经验：有时，前后台同步没有将IP地址同步到前台，可以在RPU单元上用ip_print_route命令查看路由表中是否有我们配上去的地址，如没有可再次进行整表同步。3、检查完CN的签约没有问题，就找到RNC的OMCR后台，找到对应的子业务类型，该目录下有对应的PDCP，RLC，MAC，FP，物理层的一些配置，一般情况下可以采用默认配置即可。如果出现PS不通或速率很低的情况需要逐层检查这些参数是否正确。4、PDCP层参数检查,采用默认值即可，一般选择

15、头信息不出现，无损重定位指示不出现。因为目前头压缩不支持，无损重定位也不支持。5、RLC层参数检查，一般默认配置即可，主要是POLL机制，可以找一个好的环境，把对应的业务参数比较一下是否一致。要查看RRC配置给UE和用户面的RB的SIZE上下行大小是否一样，并且和MAC层的TFS中的SIZE对应。可以通过信令查看RRC SETUP，RB SETUP，用户面的SUCIUSETUP，SUCIURBSETUP中的信元。6、MAC层参数，主要是TFS，TTI，一般PS384的TFS为0*336,1*336,2*336,4*336,8*336,12*336，TTI为10ms。其他的业务TTI一般为20m

16、s。例如PS64K的TTI为20ms，TFS为0*336,1*336,2*336,4*336。注意要分上下行，找到子业务类型中对应的上下行参数配置区。 如果不知道速率和TFS，TTI的关系，可按下面的方法简单计算。例如384K业务，为12*336，TTI为10ms,为336。计算得到速率R为384Kbit/s。所以你可以以此为公式判断有关参数是否超出了链路能力。6、FP的参数主要是TOAWS，TOAWE，如果发现FP总是不断的时间调整，上报的TOA值较大，可以和NODEB人协商，是否以上两个参数设置不合理。7、物理层参数，主要是CFTC对应的是否正常，这是控制上行物理控制信道和物理数据信道有关

17、功率的参数，一般采用默认值，如果需要修改找专门的人士咨询。另外如果启动压缩模式，压缩模式参数设置不合理也会导致速率异常。打孔可设为80以上。具体可以与专业人士确认。8、利用showRnlu (DspNo)可以排查某块DSP上的用户面协议统计信息。或直接showRnlu可以看到所有DSP的统计和。clearRnlu （DspNo），表示清空某个DSP的统计，clearRnlu表示清空所有DSP的统计。也可以直接查看某个协议层的统计。如showIuup DspNo，showPdcp DspNo，showRlc DspNo，showMac DspNo，showDfp DspNo，showCfp Ds

18、pNo。我们以一次统计为例，统计一个DSP上的信息。IUUP统计*Iuup statical information * Rfci信息 RfciIndex Uplink downlink * 0 29784 30329 * 1 31790 33724 * 2 0 0 * 3 0 0 * 4 0 0 * 5 0 0 * 6 0 0 * 7 0 0 * 8 0 0 * 9 0 0 * 向对端发送的初始化帧 90 * 从对端收到的初始化帧Ack 90 * 从对端收到的初始化帧Nack 0 * 等待初始化帧的超时次数 0 * 向对端发送的时间调整帧 182 * 从对端收到的时间调整帧Ack 182 *

19、 从对端收到的时间调整帧Nack 0 * 等待时间调整帧的超时次数 0 * * 向对端发送的速率控制帧 0 * 向控制面发送错误指示帧 0 * 向对端发送的错误指示帧 0 * 从对端收到的错误指示帧 0 * 从Uu口收到的数据PDU 194662 * 向Iu口发送的数据PDU 71514 * 从Iu收到的数据PDU 72481 * 向Uu发送的数据PDU 131350 * 收到下行数据的空帧PDU 0 * 下行数据益处缓冲的个数PDU 10 * 放入发送队列时失败的个数 0 * 得不到发送队列空间的个数 0 *这是IUUP的统计信息，正常情况下，黑体部分为上行，黑斜体部分为下行。若只有PING

20、包，比例关系和上下行速率比例基本一致。若有关队列和缓存溢出，说明用户面IUUP内存不够。PDCP统计*Pdcp statical information * 上行:从Rlc 收到的数据 9980 * 上行:向Iuup发送的数据 9940 * 上行:处理过程丢失数据 40 * 下行:从Iuup收到的数据 8138 * 下行:向Rlc 发送的数据 8138 * 下行:处理过程丢失数据 0 * 下行:回调缓冲区已满的数据 0 * 从RLC收到的ack or nack 7912 * 上行:收到的压缩头帧 0 * 上行:收到的fullhead帧 0 * 上行:发送到CN的数据帧 0 * 下行:发送的压缩

21、头帧 0 * 下行:发送的fullhead帧 0 * 下行:接收到CN的数据帧 0 * 重定位:反传到CN的数据 0 * 重定位:接收的反传数据 0 *注意黑斜体部门的数目应该很接近，若只有PING包，上下行的数据统计和上下行的速率基本一致。若下行回调数据区满或下行处理过程中数据丢失，说明PDCP缓存不够。若从RLC收到的ack or nack同下行:向Rlc 发送的数据 相差很大，超过40%-50%，说明无线口的链路的质量有问题，解决方法见1.3节。RLC统计=Send=SUFI NO_MORE Send Counter = 2SUFI WINDOW Send Counter = 0SUFI

22、 ACK Send Counter = 27893SUFI LIST Send Counter = 382SUFI BITMAP Send Counter = 0SUFI RList Send Counter = 0SUFI MRW Send Counter = 0SUFI MRW_ACK Send Counter = 0Report Lost Pdus to UE = 3545=Recv=SUFI NO_MORE Recv Counter = 105SUFI WINDOW Recv Counter = 0SUFI ACK Recv Counter = 13152SUFI LIST Recv

23、Counter = 324SUFI BITMAP Recv Counter = 0SUFI RList Recv Counter = 1SUFI MRW Recv Counter = 0SUFI MRW_ACK Recv Counter = 0Report Lost Pdus from UE = 381Insert Data Sdu Success = 0Insert Data Sdu Fail = 0Recv Data Sdu Frm Upper = 10716Recv Data To be Segmented = 10716Recv Data Pdu Frm Mac = 64110Recv

24、 Invalid Data Pdu Frm Mac = 107Recv Status Pdu Frm Mac = 13257Send Data Pdu to Mac = 33156Send Status Pdu to Mac = 27895Am Rlc Send Reset Pdu to Peer = 222Am Rlc Send Reset Ack Pdu to Peer = 32Am Rlc Recv Reset Pdu from Peer = 32Am Rlc Recv Reset Ack Pdu from Peer = 7如果链路正常，RLC统计中主要是NO_MORE和ACK，如果接收

25、到的LIST，BITMAP，RLIST相对ACK的比例较大，说明RNC侧RLC发送的包在空间丢失较多，说明下行链路质量不好。如果RLC发送的LIST较多，说明上行UE发送的很多包丢失，上行链路质量不好。另外如果发送的RESET较多或接收的RESET较多，也说明空中质量差。MAC统计 =MAC-d 统计= Mac-d 上行接收自 DFP PDU: 211153 Mac-d 上行接收自 CMAC PDU: 0 Mac-d 上行接收自DFP的空包 PDU: 63894 Mac-d 上行丢弃自DFP的空包 PDU: 0 Mac-d 上行发送到RLC的空包 PDU: 63894 Mac-d 上行发送到

26、RLC PDU: 210912 Mac-d 下行接收自 RLC PDU: 184946Mac-d 下行发送到 FP PDU: 184641 Mac-d 下行发送到 CMAC PDU: 117 Mac-d 下行发送空包到 FP PDU: 0 =MAC -c统计= Mac-c/sh 下行接收自 RLC PDU: 2035 Mac-c/sh 下行接收自 DMAC PDU: 31 Mac-c/sh 下行接收自DMAC并丢弃 PDU: 0 Mac-c/sh 下行发送到 FP PDU: 2060 Mac-c/sh 上行发送到 RLC PDU: 339 Mac-c/sh 上行发送到 DMAC PDU: 0M

27、AC一般没有问题，主要是看他和RLC之间有没有层间丢包。注意不一定完全相等，统计上有时间差，但相差极小。MAC-D和MAC-C之间的数据信息主要是从公共传输信道上出去的信令和建立在FACH上的业务数据。主要看Mac-d下行发送到 CMAC PDU和Mac-c/sh 下行接收自DMAC PDU基本一致。IurCfp统计=IurCfpU 统计= IurCfpU 回调接收数据包 0 IurCfpU 下行发送数据包 95 IurCfpU 下行发送控制包 0 IurCfpU 上行接收数据包 0 IurCfpU 上行接收控制包 0 =IurCfpC 统计 = IurCfpC 回调接收数据包 17 IurC

28、fpC 上行发送数据包 0 IurCfpC 上行发送控制包 0 IurCfpC 下行接收数据包 17 IurCfpC 下行接收控制包 0IurCfp主要是UE在FACH态下的信令和业务。IurCfpU表示MAC-D侧的IurCfp，IurCfpC表示MAC-C侧的IurCfp。两个接口上对应方向上的数据基本一致。DFP统计 DFP INFO dfp send data to node = 177973 dfp recv data from node = 167934 dfp srnc callback discard data = 0 dfp recv tb from node = 21115

29、3 dfp recv data head crc error = 0 dfp recv data payload crc error = 0dfp recv data crci error = 6565dfp frame len error for TFI = 0 dfp recv ctrl frame = 22486 dfp send ctrl frame = 3695 dfp send OLPC frame = 373 dfp recv TB from MacD = 184641 dfp send TB to MacD = 211153 dfp recv total Fp from Nod

30、eb = 190628 dfp send total Fp to Nodeb = 181668dfp Ul Macro Proc Fp Num = 100506dfp Dl Macro Send Fp Num = 122824 dfp Ul Macro Discard Fp Num = 1 dfp DRnc Iur Dl Recv Fp Num = 144156 dfp DRnc Iur Ul Send Fp Num = 142305 dfp DRnc Iur callback disc data = 0 dfp DRnc Iub Dl Send Fp Num = 144156 dfp DRn

31、c Iub Ul Recv Fp Num = 145613 dfp DRnc Iub callback disc data = 0 dfp DRnc Ul Macro Proc Fp Num = 0 dfp SRnc Iur Dl Send Fp Data Num = 68903 dfp SRnc Iur Ul Recv Fp Data Num = 38565 dfp SRnc Iur Dl Send Fp Ctrl Num = 1626 dfp SRnc Iur Ul Recv Fp Ctrl Num = 11944 dfp Node Sync send Fp Num = 597 dfp N

32、ode Sync recv Fp Num = 646 dfp Trans Sync send Fp Num = 1168 dfp Trans Sync recv Fp Num = 7453 dfp Period Sync send Fp Num = 1508 dfp Period Sync recv Fp Num = 538 dfp DRnc Node Sync send Fp Num = 49 dfp DRnc Node Sync recv Fp Num = 0 dfp DRnc Trans Sync send Fp Num = 0 dfp DRnc Trans Sync recv Fp N

33、um = 0DFP中比较重要的一个统计信息是dfp recv data crci error，如果占dfp recv tb from node的比例较大，说明上行链路质量有问题，见1.3节。另外如dfp frame len error for TFI，dfp recv data head crc error，dfp recv data payload crc error占dfp recv tb from node的比例较大说明是RNC连接设备如DRNC，NODEB有问题或和我们理解的不一致，尤其是欧洲厂商的设备，请直接和他们联系。CFP统计 CFP INFO Cpch Fp recieve d

34、ata total : 0Pch Fp recieve data total : 48044Pch Fp send data total : 2132Pch Fp Receive time adjust : 0Fach Fp recieve data total : 96103Fach Fp send data total : 2062Fach fp Receive time adjust : 2Rach Fp recieve data total : 2281Rach Fp send to Mac total : 2281Rach Fp recieve buf full num : 0Rec

35、eive data Crci Error : 1941Put data in queue : 0Send data normally : 0Send data Error : 0Send data abnormally : 0Discard data in queue num : 0the total of data re-sended : 13the failure total of data re-sended : 0the total of data drnc queue : 286472the failure total of data drnc : 0Send Node Sync n

36、um on PCH : 0Send Node Sync num on FACH : 9Recv Node Sync num on PCH : 0Recv Node Sync num on FACH : 9Send Tran Sync num on PCH : 11Send Tran Sync num on FACH : 22Recv Tran Sync num on PCH : 11Recv Tran Sync num on FACH : 22Send Period Sync num on PCH : 48054Send Period Sync num on FACH : 96112Recv

37、Period Sync num on PCH : 48033Recv Period Sync num on FACH : 96066CFP的统计主要是UE处于FACH态时RACH和FACH上的包，注意如果UCIU和CCIU在不再一块DSP上，需要找到改CCIU对应的UCIU所在那个DSP上,和UCIU的统计信息对应起来，一般情况下都在DCH态，查看数据统计，不会来看CFP的东西,。用户面统计信息的联合排查一、如何推断上行链路质量是否正常1： 上行的链路质量可以直接通过DFP统计的上行CRCI错误是否占从NODEB总共收到的TB块比例比较小，10%以内正常。2： 看RLC统计的发送的LIST占A

38、CK的比例是否较小，10%以内正常。3： 看PDCP统计的从RLC收到的ack or nack同下行:向Rlc 发送的数据 相差不大，30%以内正常。4：看PDCP的下行:处理过程丢失数据或下行:回调缓冲区已满的数据是否较多，目前PS的数据都缓存在PDCP，如果上行质量较差，RLC状态包不能及时回来清除确认的SDU，会导致PDCP溢出。二、如何推断下行链路质量是否正常1： 看RLC统计的接收的LIST，BITMAP，RLIST占ACK的比例是否较小，10%以内正常。2： 看PDCP的下行:处理过程丢失数据或下行:回调缓冲区已满的数据是否较多，目前PS的数据都缓存在PDCP，如果下行质量较差，会

39、导致PDCP溢出。三、若上下行空口质量很好，PS业务还是不正常，就要排除是否用户面层间有丢包。1：下行数据脉络轨迹。IUUP： 从Iu收到的数据PDU 向Uu发送的数据PDUPDCP： 下行:从Iuup收到的数据下行:向Rlc 发送的数据RLC ：Recv Data Sdu Frm UpperRecv Data To be SegmentedSend Data Pdu to Mac （分割转化的RLC的PDU） Send Status Pdu to Mac MACD：DCH状态：Mac-d 下行接收RLC PDUMac-d 下行发送到 FP PDUFACH状态：Mac-d 下行接收RLC PD

40、UMac-d 下行发送到 CMAC PDU若UE处于DCH态DFP： dfp recv TB from MacDdfp send data to node （转化为FP帧）若UE处于FACH态IurCfpU：IurCfpU 下行发送数据包再找到发送的小区所在的板子和DSP，查找如下信息。IurCfpC：IurCfpC 回调接收数据包 IurCfpC 下行接收数据包Cfp：Fach Fp recieve data total（转化为FP帧）Fach Fp send data total 通过以上数据轨迹，在数据没有转化格式之前应该基本相同。RLC和PDCP之间不超过50%。如果PDCP显示自己的

41、缓存溢出，从OMCR检查RLC的发送窗口是否合适。384K的窗口512，其他的256就已经足够了，一些比较小的业务，如8K，128的窗口足够。2：上行数据脉络轨迹。若UE处于DCH态DFP：dfp recv tb from node MACD上行接收自 DFP PDU Mac-d上行发送到 RLC PDU:若UE处于FACH态IurCfpU：IurCfpU 回调接收数据包 IurCfpU 上行接收数据包 MACD 上行接收自 CMAC Mac-d上行发送到 RLC PDU:RLC： Recv Data Pdu Frm Mac Recv Invalid Data Pdu Frm Mac Recv

42、 Status Pdu Frm Mac 正常情况下Invalid Data应该很少，由于长度或码元错误引起的。RLC对于发向PDCP的数据没有统计，直接看PDCP即可。PDCP： 上行:从Rlc 收到的数据 9980 上行:向Iuup发送的数据 9940 上行:处理过程丢失数据 40上行处理由于空间不够，可能会丢失一些数据，但不能超过10%。IUUP： 从Uu口收到的数据PDU 向Iu口发送的数据PDU上行数据的排查一般只要确定用户面层间没有大面积的丢包即可，一般用户面丢包的可能性很小，如果丢包，应该是PDCP的数据区长度，RLC的窗口大小，逻辑信道大小，传输信道的缓存等等，这些都经过长期测试

43、，出问题的可能极小。这只能证明用户面没有问题，如果还有PS业务不行，进入底层以太网的数据统计检查。终端、笔记本、下载工具问题 终端问题目前阶段，终端的功能和性能参差不齐。在作PS业务出现问题时要了解终端的功能和性能，看看是否是终端问题。一般可采取使用多个终端来对比测试。笔记本问题基于TCP协议的业务，其速率受TCPWindowSize的影响，其中终端更改过程如下：1进入注册表进行编辑见REF _Ref189476492 h图 2.32。图 STYLEREF 2 s2.3SEQ 图 * ARABIC s 22 注册表编辑2打开相关注注册表项，见REF _Ref189476557 h图 2.33：

44、HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip图 STYLEREF 2 s2.3SEQ 图 * ARABIC s 23 注册表编辑_更改TcpWindowSize值3新建字符串值TcpWindowSize，取值为65535：当PS业务遇到问题时，比较相同签约，相同终端，比较不同性能笔记本之间的差异，以判断是否跟笔记本性能相关。并发类业务故障排查思路并发类业务种类较多，所以可能出现的问题也会较多。在系统保证了CS和PS业务分别建立时没有问题的情况下，并发业务不能正常建立，可以考虑更换终端或者询问终端是否支持所做的并发业务，并发业务种类

45、请参考REF _Ref188240863 h表 2.41，表格中以三星T578系统测试部的测试结果为参考。表 STYLEREF 2 s2.4SEQ 表 * ARABIC s 21 并发业务测试情况表CS12.2KCS64K短信彩信JAVA流媒体WAP呼入呼出呼入呼出发送接收发送接收下载播放浏览WAP业务Y支持Y支持YYNY支持，但不能同时进行支持，但不能同时进行彩信YYYYYYYY支持，发完彩信后可做YY短信YYYYYYYYYYYCS64KNNNNYYNYNNNJAVA下载YNYNNYNYNNN定位流媒体YNYNNYNYNNN并发业务故障的排查思路主要放在信令流程上是否可以走通，因为在前两个小

46、节中如果CS和PS的业务都不存在问题，那么并发业务只要信令正常，业务就可以建立，前提是CN上签约了相应的业务，UE支持此类业务。那么我们把并发业务的信令分为三个大类：1CS电路域类业务信令流程（CS12.2K和CS64K）：此类业务的信令流程请参考章节2.1，包含两种，主叫和被叫信令流程。注意，CS12.2K和CS64K在RAB指派中的速率不同。2PS分组域类业务信令流程（彩信，JAVA，流媒体和WAP）：此类业务的信令流程请参考章节2.2，他们的信令流程都是PDP激活，只是在RAB指派中的速率和业务类型会有所不同。3短信类业务信令流程：短信业务没有RAB建立，他们是在RB4上发送的，这样我们

47、在信令上首先看到RRC建立，然后是直传消息，之后就是资源的释放。值得注意的是，在并发业务中，如果终端首先做PS业务，此时终端处于CELL_DCH或者CELL_FACH状态，如果此时终端做被叫，会看到PAGING TYPE2，比常见的被叫信令多一条这个信令。常见故障现象常见故障现象如下：先做PS业务，然后被叫CS业务失败；先做PS业务，然后主叫CS业务失败；先做CS业务，后做PS业务失败。常见故障原因以及排查思路并发类故障外场遇见的几乎没有，如果在CS和PS单独业务都正常的情况下，并发业务基本不会出现问题。并发类故障原因请参考REF _Ref188264626 h表 2.42：表 STYLERE

48、F 2 s2.4SEQ 表 * ARABIC s 22 并发类常见故障原因故障分类常见故障原因并发类故障终端不支持并发业务；CN没有进行正确业务签约；终端或者笔记本参数设置问题；有的并发业务没有必要，例如CS12.2K和CS64K并发；无线或者传输资源不够使用；CN或者RNS没有下发第二类寻呼；3G小区内切换类业务故障排查思路切换的种类繁多，可以分为Node B内小区切换，RNC内小区切换，跨RNC小区切换。从大体上可以分为两类：第一，RNC内的小区切换；第二，跨RNC的小区切换。故障排查上也有些许不同：RNC内小区切换常见故障现象切换的故障现象大体分为两类：1切换的信令流程不正确；2CS切换

49、信令正确，但是切换后没有声音或者有杂音；3PS切换信令正确，但是切换后速率异常；常见故障原因业务类故障的常见原因REF _Ref188414926 h表 2.51：表 STYLEREF 2 s2.5SEQ 表 * ARABIC s 21 RNC内小区切换故障表故障分类常见故障原因信令流程不正确RNC没有下发测量控制，或者测量控制消息不准确；目标小区Iub口传输资源不够使用；目标小区无线资源不够使用；目标小区干扰过高，导致切换完成消息（物理信道重配置完成或者RB重配置完成）不能上报；CS切换后无声或者有杂音CN没有给RNC发送数据包或者全部是静音帧；UU口用户面数据包异常；RUB单板故障；终端故

50、障；PS切换后速率异常CN存在问题，可以通过验证多个RNC来确定；UU口用户面数据包异常；RUB单板故障；终端故障；跨RNC的小区之间切换常见故障现象切换的故障现象大体分为两类：1切换的信令流程不正确，此处的信令流程和RNC内小区切换略有不同；2CS切换信令正确，但是切换后没有声音或者有杂音；3PS切换信令正确，但是切换后速率异常；常见故障原因业务类故障的常见原因REF _Ref188414926 h表 2.51，注意邻接关系的配置多了一个外部小区的数据配置。23G切换类业务故障排查思路常见故障现象切换的故障现象大体分为两类：1切换的信令流程不正确；2CS切换信令正确，但是切换到2G后没有声音

51、或者有杂音；3PS切换信令正确，但是切换后速率上不来；常见故障原因常见故障原因请参考REF _Ref188865918 h表 2.61：表 STYLEREF 2 s2.6SEQ 表 * ARABIC s 21 2/3G切换失败常见原因表故障分类常见故障原因信令流程不正确UE频繁重选，导致电话无法拨通，不能切换；RNC没有下发测量控制，或者测量控制消息不准确；UE故障，没有上报测量报告；CN信令流程异常导致切换失败，例如CS从3G切换到2G不释放Iu和Iub口资源，PS切换路由区更新失败，PS切换没有RAB指派等等；3G小区Iub口传输资源不够使用（针对PS域切换）；3G小区无线资源不够使用（针

52、对PS域切换）；CS切换到2G后无声或者有杂音（CS不存在从2G到3G的切换）请2G查看原因； PS切换后速率异常CN存在问题，可以通过验证多个RNC来确定；UU口用户面数据包异常；RUB单板故障；终端故障；HS业务故障排查思路常见故障现象1、物理信道重配置失败；2、终端无法接入；3、HS呼叫不成功；4、下载速率不理想。常见故障原因常见故障原因请参考REF _Ref213657999 h表 2.71：表 STYLEREF 2 s2.7SEQ 表 * ARABIC s 21 HS故障表格故障现象常见故障分类物理信道重配置失败Sich和Prach配置的码道冲突；当配置有多条Scch/Sich时，不

53、同的Scch的信道号是否冲突，不同的Sich的功率配置是否正确；没有看到RNC发送给NODEB物理信道重配置消息（检查RNC和NODEB是否配置了支持HS）；RNC上参数配置错误；TBPE单板的DSP0或者DSP11有故障。终端无法接入此类问题可以到CS类故障排查中查看原因HS呼叫不成功上行64k时，由于SF2，所以目标时隙仅存在连续8个上行空闲码道是不够；主要是看信令来定位下载速率不理想用数据卡而电脑未接外部电源，如果用数据卡测试，而便携电脑无外部电源，此时速率会大大下降；数据卡是否存在过热现象；终端收到的信号强度是否足够；Iub口配置的带宽是否足够站点的RTWP和ISCP过高，存在干扰；U

54、E问题，例如死机；如果发现承载Scch或承载下行伴随Dpch的时隙的TCP（发射载波动率）较高，说明此时Ue的接收信号不好，或已经有Ue工作不正常；如果发现承载HsDsch的时隙的发射载波功率波动较大，说明经常无用户被调度，可以查看No Data统计量，是否是因为无数据可发，所以经常下行发射载波动率会降低；如果功率无异常，但整体速率不高，则首先查看上报的CQI值，如果CQI偏低，但Nack不多，则可能是由于外部HS-DSCH信道的有干扰，但干扰还未大到产生Nack的地步；No Answer较多，从目前的情况来看，主要是因为测试点信号太差，只能换点测试查看Lmt的Ue统计信息的“上行信道的TB块

55、数”和“上行信道错误TB块个数”，如果发现错误包过多，说明上行质量很差，如果发现上行正确数据包过少（比如10几），或几乎没有，则说明Ue的应答包没有发上来，可以更换电脑重新测试。LMT上的数据分析方法Ack、Nack、No Answer、No Data和重传超时重传超时参数说明了在Node B物理层传输失败，需要高层重传的次数，当存在大量的重传超时时，会导致速率大幅下降，此时下行Scch信道或Dsch信道质量可能较差，可通过Ack、Nack和No Answer的数量确定。Ack表示Hsdpa数据传输正确，Nack表示Scch发送正确，但DSch数据Ue接收错误，No Answer表示Scch数

56、据Ue接收错误。因此，Ack表示Scch和Dsch信道都比较好，大量Nack表示Dsch信道可能有恶化，大量No Answer表示Scch信道可能存在恶化。当存在大量Nack或No Anser时，由于物理层重传的影响，会导致下行速率降低，此时可能下行Scch信道或Dsch信道有恶化，可结合上报Cqi和发射码功率及Aoa测量上报进行分析。No data表示Node B调度该Ue时，该Ue无数据可发。No Data会导致空口速率下降，No Data的最主要的原因是因为Rnc无数据可发或Rnc发送窗满，由于影响Rnc数据量和Rnc滑窗的数据都在上行伴随Dpch上传输，因此出现No Data时，很可能

57、上行伴随Dpch信道质量已经下降了。上行伴随Dpch数据Lmt提供了“上行信道的TB块数”和“上行信道错误TB块个数”，这2可参数都是一直累加的，我们可以通过差分计算出每上报周期（500ms）内的上行伴随Dpch正确数据块个数和错误数据块个数，而当错误数据块个数较多时，说明Rlc层或应用层的数据确认包未发送到发送端，此时就可能导致Rnc无数据可发或Rnc窗满，导致Node B无数据可发，最后导致空口速率下降。如果上行伴随Dpch的错包较多，则可以通过查看上行伴随Dpch的接收信号码功率和SIR来具体分析。Cqi平均值该值由Ue上报到Node B，Node B根据Cqi的值确定下行速率（下行发送

58、数据包的大小），Ue主要根据信道质量来确定Cqi的值，但具体计算方法不祥，但Cqi下降表示Dsch信道有恶化，从实测数据看，Cqi对信道恶化的敏感程度，不是很敏感（即恶化后，虽然Cqi会降低，但还是会出现很多Nack）。发射码功率和AOA测量下行的发射码功率应该保持一个较稳定的值，当发射码功率突然提高时，说明此时下行伴随Dpch信道所在的时隙信道质量可能有恶化（存在干扰），所以Ue要求Node B提高发射功率，保持一定的信噪比。对定点测试而言，Aoa测量值也应该保持一个定值，但尤其是在近场的环境下，由于多径的影响，可能会导致Aoa测量有波动，当Aoa存在波动时，由于多径效应的影响，可能此时的U

59、e下载速率会下降。接收码功率和AOA测量从被测Sir可以直接看出上行伴随Dpch的信道质量，如果Sir比较稳定，但此时对应的接收码功率上升，说明此时上行信道有干扰，但干扰不是很严重，通过Ue提高发射功率，还可以维持较好的信道质量，如果Sir明显下降，则说明此时上行伴随Dpch已经恶化，且无法通过Ue提升功率来保证信道质量，此时可以查看时隙的Iscp（时隙的干扰信号功率，在载波信息里），如果Iscp明显上升，就明确了确实有较强的干扰功率，如果Iscp无明显变化，说明信道质量的恶化可能是因为上行信号已经很弱了，应该可以和接收信号码功率对应起来。典型故障案例摘要本章举几个典型案例，介绍各种业务类故障

60、的排查思路。CS业务类典型案例手机开机后无法注册网络,从信令跟踪上看信令没有到CN,只有IUB口信令的交互分析:信令没有走到CN,只有IUB口的信令交互,一般情况下是IUB口的对接数据出了问题,具体的例子如下： 故障案例1【故障现象】手机开机后,出现RL链路无法到达NODEB,导致RRC连接失败,手机无法注册,信令跟踪见REF _Ref136849136 h图3.11。图 STYLEREF 2 s3.1SEQ 图 * ARABIC s 21 RL建立失败之一【可能原因】RL的建立是由NCP控制，如上是RL链路的建立请求根本就没有发送到NODEB,有可能NCP链路出了问题，而导致RL链路的建立请