《ZXTR RNS故障排查指导手册(业务类分册)(XXXX-R10).docx》由会员分享，可在线阅读，更多相关《ZXTR RNS故障排查指导手册(业务类分册)(XXXX-R10).docx（85页珍藏版）》请在三一办公上搜索。
1、ZXTR RNS（V1.21）故障排查指导手册（业务类分册）（2008-R1.0） 中兴通讯股份有限公司修改记录版本号拟制人/修改人拟制/修改日期更改理由主要更改内容V1.21马伟，李开彬2008/01/30新建提交初稿V1.30李开彬2008/11/5添加添加了HS部分内容注1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。注2：文件第一次归档时，“更改理由”、“主要更改内容”栏写“无”。7声 明本资料著作权属中兴通讯股份有限公司所有。未经著作权人书面许可，任何单位或个人不得以任何方式摘录、复制或翻译。侵权必究。和是中兴通讯股份有限公司的注册商标。中兴通讯产品的名称和标
2、志是中兴通讯的专有标志或注册商标。在本手册中提及的其他产品或公司的名称可能是其各自所有者的商标或商名。在未经中兴通讯或第三方商标或商名所有者事先书面同意的情况下，本手册不以任何方式授予阅读者任何使用本手册上出现的任何标记的许可或权利。本产品符合关于环境保护和人身安全方面的设计要求，产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。由于产品和技术的不断更新、完善，本资料中的内容可能与实际产品不完全相符，敬请谅解。如需查询产品的更新情况，请联系当地办事处。前 言中兴通讯自主开发的TD-SCDMA第三代移动通信系统，由ZXTN（核心网部分）和ZXTR（无线网络子系统）构成。
3、ZXTR无线网络子系统包括RNC（无线网络控制器）和Node B（无线基站），完成呼叫处理、无线资源分配管理、终端移动性管理、小区切换控制和无线接入的功能。手册说明本手册是一套针对TD-SCDMA无线移动系统的系列性资料，汇集了目前TD外场出现的各类典型故障，并给出了常见问题的处理思路和典型案例分析，可作为日常维护时的参考。全套手册包括：ZXTR RNS（V1.21）故障排查指导手册通用类分册（信令篇）ZXTR RNS（V1.21）故障排查指导手册通用类分册（工具篇）ZXTR RNS（V1.21）故障排查指导手册对接类分册ZXTR RNS（V1.21）故障排查指导手册业务类分册ZXTR RNS
4、（V1.21）故障排查指导手册设备类分册ZXTR RNS（V1.21）故障排查指导手册网管类分册本手册为第X分册设备类分册，主要介绍各类设备本身出现的故障解决思路，按照设备作出分类描述。目 录第1章 常见故障分类11.1 概述1第2章 常见故障排查思路32.1 概述32.2 CS业务类故障42.2.1 典型信令流程介绍（主叫）42.2.2 开通类常见问题-数据对接故障52.2.3 CS业务排查流程92.2.4 UE开机注册失败排查流程92.2.5 RRC连接故障排查流程102.2.6 RAB指派失败排查流程152.3 PS业务类故障162.3.1 用户面故障排查思路172.3.2 终端、笔记本
5、、下载工具问题292.4 并发类业务故障排查思路312.4.1 常见故障现象322.4.2 常见故障原因以及排查思路322.5 3G小区内切换类业务故障排查思路322.5.1 RNC内小区切换322.5.2 跨RNC的小区之间切换332.6 23G切换类业务故障排查思路332.6.1 常见故障现象332.6.2 常见故障原因342.7 HS业务故障排查思路342.7.1 常见故障现象342.7.2 常见故障原因342.7.3 LMT上的数据分析方法35第3章 典型故障案例383.1 CS业务类典型案例383.1.1 手机开机后无法注册网络,从信令跟踪上看信令没有到CN,只有IUB口信令的交互3
6、83.1.2 从信令跟踪跟踪上看，IUB口的信令已经走完，RNC初始到CN的消息失败403.1.3 CS电话不通_IUUP初始化失败故障423.1.4 Iub口传输带宽限制导致业务失败问题483.1.5 UE开机后搜索不到小区，信令跟踪上看不到RRC连接建立请求523.2 PS业务类典型案例563.2.1 PS无法激活故障解决过程（信令跟踪消息没有保存下来）563.2.2 PS激活成功率比较低问题583.2.3 PS下载速率比较低问题593.2.4 Ping大包不通的故障排查603.2.5 画面出现马赛克故障663.3 并发类业务典型案例693.3.1 先PS业务成功，后被叫CS业务失败693
7、.3.2 先做PS业务，然后主叫CS业务失败；693.3.3 先做CS业务，后做PS业务失败693.4 RNC内的3G小区之间切换典型案例703.4.1 信令流程不完全703.4.2 CS信令正常，切换后无声或者有杂音723.4.3 PS切换信令正确，但是切换后速率异常723.5 跨RNC切换典型案例733.5.1 信令流程不正确733.5.2 CS信令正常，切换后无声或者有杂音733.5.3 PS切换信令正确，但是切换后速率异常733.6 23G小区切换典型案例733.6.1 信令流程不正确733.6.2 信令切换正常，切换后业务存在问题753.7 HS故障典型案例讲解763.7.1 物理信
8、道重配置失败763.7.2 下载速率不理想76第1章 常见故障分类摘要本章介绍了RNC、NODEB等设备在时钟、硬件启动、传输、版本下载以及无线干扰等故障的故障现象、故障原因分析和故障处理方法等。1.1 概述按照外场设备运行中发现的和业务相关的各种故障现象，可以将业务类故障划分为以下几类：CS类故障：包含数据对接故障，RRC连接故障，开机注册失败等故障；PS类故障：包含PS无法激活，PS激活成功率低，PS下载速率低，PS出现马赛克等故障；并发类故障：包括信令流程走不通，终端不支持并发，CN签约问题，传输或者码道资源不够使用等；切换类故障：包括信令流程走不通，传输或者码道资源不够使用等；HSDP
9、A业务故障：包括物理信道重配置失败，终端无法接入，HS呼叫不成功，下载速率不理想等。与业务类相关的常见故障的故障分类及其典型故障现象见表 1.11 常见故障分类表 1.11 常见故障分类故障分类典型故障现象常见故障原因CS类故障RRC连接故障；开机注册失败；信令流程走不通；单通或者双向无音；数据对接问题；干扰问题；传输或者码道资源不够使用；PS类故障PS无法激活；PS激活成功率低；PS下载速率低；PS出现马赛克等；数据对接问题；干扰问题；传输或者码道资源不够使用；并发类故障先做PS业务，然后被叫CS业务失败；先做PS业务，然后主叫CS业务失败；先做CS业务，后做PS业务失败。终端不支持并发业务
10、；CN没有进行正确业务签约；终端或者笔记本参数设置问题；有的并发业务没有必要，例如CS12.2K和CS64K并发；无线或者传输资源不够使用；CN或者RNS没有下发第二类寻呼；切换类故障信令流程不正确；CS切换后无声或者有杂音；PS切换后速率异常。RNC没有下发测量控制，或者测量控制消息不准确；目标小区Iub口传输资源不够使用；目标小区无线资源不够使用；目标小区干扰过高，导致切换完成消息（物理信道重配置完成或者RB重配置完成）不能上报；CN没有给RNC发送数据包或者全部是静音帧；UU口用户面数据包异常；RUB单板故障；终端故障；HS类故障物理信道重配置失败终端无法接入HS呼叫不成功下载速率不理想
11、78第2章 常见故障排查思路摘要本章介绍了业务类故障的常见原因、故障原因分析和故障处理方法等。2.1 概述业务类故障可分为以下几大类：1） CS类故障2） PS类故障3） 并发类故障4） 切换类故障其中,1) 2) 3) 类故障是不包含切换过程的故障. 4) 对切换过程中的故障进行专述，请参考表格表 2.11 业务类故障概述。 表 2.11 业务类故障概述故障分类故障表现形式(包括但不限于)CS类故障1. 手机不能注册2. 手机收不到寻呼, 3. 接通率底4. 通话过程中掉话5. 呼叫拒绝6. 业务(话音/图像)质量差7. PS类故障1. 呼叫(PDP激活)成功率低2. 速率不稳定3. 马赛克
12、问题4. 应用层问题5. 并发类故障1. 终端不支持并发业务；2. CN没有进行正确业务签约；3. 终端或者笔记本参数设置问题；4. 有的并发业务没有必要，例如CS12.2K和CS64K并发；5. 无线或者传输资源不够使用；6. CN或者RNS没有下发第二类寻呼；切换类故障1. RNC没有下发测量控制，或者测量控制消息不准确；2. 目标小区Iub口传输资源不够使用；3. 目标小区无线资源不够使用；4. 目标小区干扰过高，导致切换完成消息（物理信道重配置完成或者RB重配置完成）不能上报；5. CN没有给RNC发送数据包或者全部是静音帧；6. UU口用户面数据包异常；7. RUB单板故障；8. 终
13、端故障；2.2 CS业务类故障 本节介绍CS业务类故障的处理方法，分为几个方面来描述：1. 典型信令流程介绍2. 数据对接问题3. CS业务排查思路2.2.1 典型信令流程介绍（主叫）对于CS业务故障处理，应熟悉CS业务流程。当出现问题时要养成从解读、分析信令入手，看看业务走到哪一步，再来定位问题。信令流程介绍请参阅相关文档，这里就不再描述2.2.1.1 完整的起呼信令流程一个完整的主叫流程见图 2.21。 图 2.21完整的起呼信令流程从信令跟踪入手，从整体上把CS业务问题分为几个大的方面来处理。1. 小区和公共信道建立正常，如果小区和公共信道建立都不正常，就谈不上业务。小区和公共信道建立异
14、常的故障，请参与相关文档来处理。2. UE开机注册问题排查。在作业务的前提是，手机能正常注册到网络。如果不能注册到网络，则先检查手机不能注册的原因。3. Iu口的信令连接建立是否正常。主要涉及到直传消息的信令解读，查看加密、鉴权参数设置是否有问题。4. RAB指派流程建立是否正常。系统出现问题最多的就是RAB指派流程。用户面出现的问题，都体现在RAB指派失败上。2.2.2 开通类常见问题-数据对接故障在开通期间出现问题最多的就是数据对接问题，约占故障总数的80以上。因为数据配置和故障处理一般是同一个人，在检查参数时往往存在误区。这一点要注意。首先要向局方工程师和CN侧工程师确定一下参数。部分关
15、键参数一旦我们照此配置好了CN邻接局的数据，修改起来比较麻烦的。如：MCC，MNC，RNCID，LAC，RAC，SAC。CS域或者PS域的对接都建议按照先控制面（信令）再用户面承载（数据）的顺序来对接。在对接面的时候，建议按照从底层到高层逐层确认的方式完成对接。2.2.2.1 下面把对接过程中对接参数和各层对接之间的关系列出来 1、Iu接口信令链路各层对应关系见表 2.21。表 2.21 Iu接口信令链路各层对关系协议层对接参数如果有问题，出现的故障现象PHY帧格式（SDH还是SONET）ATMVPI，VCI，PCR，业务类型SSCOP建链失败AAL5SSCOPSSCFMTP3SLC，SPC，
16、SSF信令链路状态不正常；信令点不可达SCCPRANAPMCC，MNC，RNCIDSSCP连接被拒；SST发送，收不到对应子系统的SSA。2、IuCS User Plane各层对应关系见表 2.22。表 2.22 IuCS User Plane各层对应关系协议层对接参数如果有问题，出现的故障现象PHY帧格式（SDH还是SONET）ATMVPI，VCI，PCR，业务类型，AAL2PathIDAAL2链路状态闭塞IuUPATM地址IuUP建立失败；3、IuPS User Plane各层对应关系见表 2.23。表 2.23 IuPS User Plane各层对应关系协议层对接参数如果有问题，故障现象
17、PHY帧格式（SDH还是SONET）ATMVPI，VCI，PCR，业务类型AAL5IPIPOA本端地址和对端地址Ping包不通UDPGTP-U本端和对方的GTP-U地址Ping包不通2.2.2.2 数据对接过程的一般操作顺序大家不一定严格要按照这个顺序来，但是可以做为一个判断问题的基本思路。1、Iu接口信令链路对接流程见图 2.22。图 2.22 Iu接口信令链路对接流程2、IuCS UserData数据对接流程见图 2.23。图 2.23 IuCS UserData数据对接流程3、IuPS UserPlane数据对接流程见图 2.24。图 2.24 IuPS UserPlane数据对接流程2
18、.2.3 CS业务排查流程CS业务排查流程见图 2.25。图 2.25 CS业务排查流程2.2.4 UE开机注册失败排查流程UE开机注册失败排查流程见图 2.26。图 2.26 UE开机注册失败排查流程2.2.5 RRC连接故障排查流程2.2.5.1 上报过程简单介绍要像排查RRC连接上报困难，首先要了解UE的上报过程以及RNC的处理过程。总体来说包括两个大的部分： 随机接入过程； RNS的处理过程；2.2.5.2 随机接入过程 随机接入过程相对简单，是耳熟能详的东西了，就不过多介绍了，不知道请自己找的文档看看吧，简单说明一下如何简单确定随机接入成功了？简单来说，就是UE在UpPTS上发送了S
19、YNC-UL，NODEB在FPACH上发送了响应，这样UE就可以在RACH上进行上报RRC连接请求了。可以通过LMT来看UE是否上报了UP，基站是否在FPACH上响应了。方法如下：从lmt上也可以看到UE上报了UP,FPACH上也有包下发，注意要看是否有效签名个数和FPACH包是从0开始增加的，正常情况下如果从0开始增加，就说明UE可以和基站进行同步；参考图 2.27。图 2.27 LMT上关于IP和FPACH的截图2.2.5.3 RNS的处理过程介绍完了随机接入过程后，重点介绍RNS的处理过程。我们把RNS的处理分成基站和RNC的处理。UE上报了RRC连接请求消息后，首先发到TBPE单板上解
20、出来，通过BCCS然后到IIA，通过中间传输传输到到RNC的SDTB单板，然后内部交换到IMAB单板，然后到小区建立了的RUB单板上解出来FP包，通过用户面送到RCB单板；排查流程图参考图 2.28。图 2.28 RRC上报困难排查流程2.2.5.4 TBPE单板上的RACH包在UE可以成功随机接入后，在RACH信道上上报了RRC连接请求，可以使用logview登陆到TBPE单板使用FpmHelp后通过命令FpmShowRachInfo查看TBPE单板上的包统计，正常情况如下红色标记：= Fpm Rach Info = * - Fpm Rach Normal Info - * dwRachRe
21、cvDspDataNum = 10* dwRachSendFPFrameNum = 10* dwRachRecvDLNodeSyncNum = 0* - Fpm Rach Error Info - * dwRachULDataCrciErrNum = 0* dwRachULDataNotFindTrCHNum = 0* dwRachCrciNumErrNum = 0* dwRachFrameLenErrNum = 0* dwRachSendULFrameToMacErrNum = 0* dwRachULTfiErrNum = 0* dwRachULDataLenErrNum = 0* = Fp
22、m Rach Info = *注意：FACH包出窗在查看FACH包统计的时候，可能会有FACH包出窗的情况出现，这时可以考虑修改私有数据表R_FACH中的ToWAS和ToWAE来改大窗口试试，同时在小区参数中修改引用的索引。但是注意测试完毕后要修改回来。2.2.5.5 检查IIA和TBPE之间的包收发进行了TBPE和IIA之间的包收发测试， 使用如下命令查看了包统计情况： TBPA上观察AAL2包数据统计函数 DispMACSAR(),主要可以查看gdwMacCount是否增加 在TBPA上启动收发任务 sp TBPATopTaskEntry 在IIA上启动外网自环 EnetOutLoopSe
23、t 1 IIA上查看AAL2包统计数据： m2,用于查看两边收发包数据是否递增结果如下：AAL2 MAC收包总数:975, 发包总数:921, 错误总数:0value = 47 = 0x2f = /IIA-m2AAL2 MAC收包总数:984, 发包总数:939, 错误总数:0value = 47 = 0x2f = /2.2.5.6 查看RNC和NODEB之间的接口板上PVC收发包RACH的AAL2通道上是否收发正常，在IMAB板上和IIA单板上都有一套命令可以查看PVC上是否有收发包的命令，这个命令在我们排查问题中很有帮助，这里在罗唆一下：AtmlmShowPvcByStatus：查看PVC
24、配置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_PHY B1_VPI B1_VCI205 6 0 0 131 6 1 1 131 - - - -PVCs count is 180 which Status = 0.BSP_PrintSet 0x20,1：打开统计功能apcReadIVT 0, R_PHY, R_VPI, R_VCI，查看RNC在OMCB这条PVC上是否给NODEB发送了数据；IMAB-ap
25、cReadIVT 0,0,0,131，重点关注：ITotCellsRx : 654481627ITotCellsTx : 654481618 /需要关注该统计是否在递增apcReadIVT 0, B0_PHY, B0_VPI, B0_VCI查看RNC通过光口或IMA接收到NODEB回的OMCB的报文的统计用下面的命令；IMAB-apcReadIVT 0,1,1,131，重点关注：ITotCellsRx : 654594297ITotCellsTx : 654594345 / 需要关注该统计是否在递增2.2.5.7 RUB上是否收到了RACH包由于目前外场的RUB单板比较多，所以可以考虑闭塞RU
26、B单板，仅仅剩下一块单板的方法来确定UE就在这块RUB单板上上报数据，使用RDS工具登陆RUB上，使用ShowRnluDetailStat查看：查看是否RACH上有包统计增长见图 2.29。图 2.29 RACH包统计2.2.6 RAB指派失败排查流程RAB指派失败排查流程见图 2.210。图 2.210 RAB指派失败排查流程2.3 PS业务类故障 一般情况下，我们说PS业务有问题，前提是CS业务正常，如果CS业务都不正常，先处理CS业务问题。上节讲述的CS业务故障排查同样适用于PS业务，本节不再描述。本节重点针对数据包的分片、重组统计进行描述。目前RNC对于Iu-PS口的配置策略是在2个框
27、上分别占用1块APBE单板，此单板上只使用一个光口配置Iu-PS，每个光口上配置2条IPOA及其路由，这样就形成了40M*4=160M的负荷分担配置。RNC在建立Iu-PS承载时会在局内进行轮选，这样RNC上行数据在本业务生命周期内就只在此IPOA上进行发送，对于CN侧的处理，CN在下行发送数据包时对每个数据包进行轮选IPOA，实现数据包的负荷分担发送方式。所以也就是说RNC侧的负荷分担只是对业务的负荷分担而CN的负荷分担是对数据包的负荷分担 。在3G系统中，数据业务下载速率达不到要求或流量为零，通常是困扰业务测试的重要问题，也是很难排查的问题，它牵涉到网元有核心网，RNC，NODEB，此外还
28、牵涉到终端，应用层工具和外部网等，通常需要从系统的角度来排查，本文重点从无线接入网的角度提供几点排查思路。PS的故障现象有：从外场应用和各种测试的经验看，影响速率的主要问题有： 单板硬件问题； AAL5通道配置问题； Iu/Iub口带宽配置问题； 空口参数问题； 签约速率和DRBC问题； 其他，如终端问题，RNC和NODEB版本问题，笔记本性能问题等等；2.3.1 用户面故障排查思路RNC系统中的分组域媒体流路径见图 2.31。图 2.31分组域媒体流沿着上图中黑色箭头指示的方向，是分组域媒体流从Nodeb/RNC到CN的方向，CN到Nodeb/RNC的方向刚好相反，这里不画出来了。上图中，黑
29、色线表示Iub/Iur口分组域媒体流，蓝色线表示Iu口PS域媒体流。分组域媒体流到达RNC系统时，首先到达APBE单板，APBE简单处理之后，传给RUB单板，RUB单板在用户面处理之后，传给RGUB单板。分组域媒体流和ZXWR RNC MCS子系统中的APBE、RUB和RGUB单板都有关。从上图我们可以看出，问题排查的关键技术点。我们可以在CN、RNC、NODEB控制和排查的问题有HLR（归属位置寄存器）签约，GTPU，PDCP，RLC，MAC，FP，物理层，空口参数（功率）。2.3.1.1 相关参数设置1、HLR签约，找到CN的HLR受理台，找到对应的UE，查看UE的上下行链路的速率是否是你
30、期望的值。另外注意一下有保证速率和传输延迟。保证速率可以比你签的速率小一些，如384，保证速率可以是64，传输延迟一般10ms。2、检查OMCR上PS相关的配置数据，查看路由配置是否正常。 经验：有时，前后台同步没有将IP地址同步到前台，可以在RPU单元上用ip_print_route命令查看路由表中是否有我们配上去的地址，如没有可再次进行整表同步。3、检查完CN的签约没有问题，就找到RNC的OMCR后台，找到对应的子业务类型，该目录下有对应的PDCP，RLC，MAC，FP，物理层的一些配置，一般情况下可以采用默认配置即可。如果出现PS不通或速率很低的情况需要逐层检查这些参数是否正确。4、PD
31、CP层参数检查,采用默认值即可，一般选择头信息不出现，无损重定位指示不出现。因为目前头压缩不支持，无损重定位也不支持。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
32、为10ms。其他的业务TTI一般为20ms。例如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对应的是否正常
33、，这是控制上行物理控制信道和物理数据信道有关功率的参数，一般采用默认值，如果需要修改找专门的人士咨询。另外如果启动压缩模式，压缩模式参数设置不合理也会导致速率异常。打孔可设为80以上。具体可以与专业人士确认。8、利用showRnlu (DspNo)可以排查某块DSP上的用户面协议统计信息。或直接showRnlu可以看到所有DSP的统计和。clearRnlu （DspNo），表示清空某个DSP的统计，clearRnlu表示清空所有DSP的统计。也可以直接查看某个协议层的统计。如showIuup DspNo，showPdcp DspNo，showRlc DspNo，showMac DspNo，sh
34、owDfp DspNo，showCfp DspNo。我们以一次统计为例，统计一个DSP上的信息。 2.3.1.2 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 * 向对端发送
35、的时间调整帧 182 * 从对端收到的时间调整帧Ack 182 * 从对端收到的时间调整帧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的统计
36、信息，正常情况下，黑体部分为上行，黑斜体部分为下行。若只有PING包，比例关系和上下行速率比例基本一致。若有关队列和缓存溢出，说明用户面IUUP内存不够。2.3.1.3 PDCP统计*-Pdcp statical information -* 上行:从Rlc 收到的数据 9980 * 上行:向Iuup发送的数据 9940 * 上行:处理过程丢失数据 40 * 下行:从Iuup收到的数据 8138 * 下行:向Rlc 发送的数据 8138 * 下行:处理过程丢失数据 0 * 下行:回调缓冲区已满的数据 0 * 从RLC收到的ack or nack 7912 * 上行:收到的压缩头帧 0 * 上行
37、:收到的fullhead帧 0 * 上行:发送到CN的数据帧 0 * 下行:发送的压缩头帧 0 * 下行:发送的fullhead帧 0 * 下行:接收到CN的数据帧 0 * 重定位:反传到CN的数据 0 * 重定位:接收的反传数据 0 *注意黑斜体部门的数目应该很接近，若只有PING包，上下行的数据统计和上下行的速率基本一致。若下行回调数据区满或下行处理过程中数据丢失，说明PDCP缓存不够。若从RLC收到的ack or nack同下行:向Rlc 发送的数据 相差很大，超过40%-50%，说明无线口的链路的质量有问题，解决方法见1.3节。2.3.1.4 RLC统计=Send=SUFI NO_MO
38、RE Send Counter = 2SUFI WINDOW Send Counter = 0SUFI 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 Coun
39、ter = 0SUFI ACK Recv Counter = 13152SUFI LIST Recv 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
40、 Segmented = 10716Recv Data Pdu Frm Mac = 64110Recv 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，如果接收到的LIST，BITMAP，RLIST相对ACK的比例较大，说明RNC侧RLC发送的包在空间丢失较多，说明下行链路质量不好。如果RLC发送的LIST较多，说明上行UE发送的很多包丢失，上行链路质量不
