资源描述
ZXTR RNS（V1.21）故障排查指导手册（业务类分册）
（2008-R1.0）
中兴通讯股份有限公司
修改记录
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
V1.21
马伟，李开彬
2008/01/30
新建
提交初稿
V1.30
李开彬
2008/11/5
添加
添加了HS部分内容
注1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。
注2：文件第一次归档时，“更改理由”、“主要更改内容”栏写“无”。
声 明
本资料著作权属中兴通讯股份有限公司所有。未经著作权人书面许可，任何单位或个人不得以任何方式摘录、复制或翻译。
侵权必究。
和是中兴通讯股份有限公司的注册商标。中兴通讯产品的名称和标志是中兴通讯的专有标志或注册商标。在本手册中提及的其他产品或公司的名称可能是其各自所有者的商标或商名。在未经中兴通讯或第三方商标或商名所有者事先书面同意的情况下，本手册不以任何方式授予阅读者任何使用本手册上出现的任何标记的许可或权利。
本产品符合关于环境保护和人身安全方面的设计要求，产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。
由于产品和技术的不断更新、完善，本资料中的内容可能与实际产品不完全相符，敬请谅解。如需查询产品的更新情况，请联系当地办事处。
前 言
中兴通讯自主开发的TD-SCDMA第三代移动通信系统，由ZXTN（核心网部分）和ZXTR（无线网络子系统）构成。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（V1.21）故障排查指导手册－设备类分册》
《ZXTR RNS（V1.21）故障排查指导手册－网管类分册》
本手册为《第X分册—设备类分册》，主要介绍各类设备本身出现的故障解决思路，按照设备作出分类描述。
目 录
第1章 常见故障分类 1
1.1 概述 1
第2章 常见故障排查思路 3
2.1 概述 3
2.2 CS业务类故障 4
2.2.1 典型信令流程介绍（主叫） 4
2.2.2 开通类常见问题-数据对接故障 5
2.2.3 CS业务排查流程 9
2.2.4 UE开机注册失败排查流程 9
2.2.5 RRC连接故障排查流程 10
2.2.6 RAB指派失败排查流程 15
2.3 PS业务类故障 16
2.3.1 用户面故障排查思路 17
2.3.2 终端、笔记本、下载工具问题 29
2.4 并发类业务故障排查思路 31
2.4.1 常见故障现象 32
2.4.2 常见故障原因以及排查思路 32
2.5 3G小区内切换类业务故障排查思路 32
2.5.1 RNC内小区切换 32
2.5.2 跨RNC的小区之间切换 33
2.6 23G切换类业务故障排查思路 33
2.6.1 常见故障现象 33
2.6.2 常见故障原因 34
2.7 HS业务故障排查思路 34
2.7.1 常见故障现象 34
2.7.2 常见故障原因 34
2.7.3 LMT上的数据分析方法 35
第3章 典型故障案例 38
3.1 CS业务类典型案例 38
3.1.1 手机开机后无法注册网络,从信令跟踪上看信令没有到CN,只有IUB口信令的交互 38
3.1.2 从信令跟踪跟踪上看，IUB口的信令已经走完，RNC初始到CN的消息失败 40
3.1.3 CS电话不通_IUUP初始化失败故障 42
3.1.4 Iub口传输带宽限制导致业务失败问题 48
3.1.5 UE开机后搜索不到小区，信令跟踪上看不到RRC连接建立请求 52
3.2 PS业务类典型案例 56
3.2.1 PS无法激活故障解决过程（信令跟踪消息没有保存下来） 56
3.2.2 PS激活成功率比较低问题 58
3.2.3 PS下载速率比较低问题 59
3.2.4 Ping大包不通的故障排查 60
3.2.5 画面出现马赛克故障 66
3.3 并发类业务典型案例 69
3.3.1 先PS业务成功，后被叫CS业务失败 69
3.3.2 先做PS业务，然后主叫CS业务失败； 69
3.3.3 先做CS业务，后做PS业务失败 69
3.4 RNC内的3G小区之间切换典型案例 70
3.4.1 信令流程不完全 70
3.4.2 CS信令正常，切换后无声或者有杂音 72
3.4.3 PS切换信令正确，但是切换后速率异常 72
3.5 跨RNC切换典型案例 73
3.5.1 信令流程不正确 73
3.5.2 CS信令正常，切换后无声或者有杂音 73
3.5.3 PS切换信令正确，但是切换后速率异常 73
3.6 23G小区切换典型案例 73
3.6.1 信令流程不正确 73
3.6.2 信令切换正常，切换后业务存在问题 75
3.7 HS故障典型案例讲解 76
3.7.1 物理信道重配置失败 76
3.7.2 下载速率不理想 76
第1章 常见故障分类
摘要
本章介绍了RNC、NODEB等设备在时钟、硬件启动、传输、版本下载以及无线干扰等故障的故障现象、故障原因分析和故障处理方法等。
1.1 概述
按照外场设备运行中发现的和业务相关的各种故障现象，可以将业务类故障划分为以下几类：
CS类故障：包含数据对接故障，RRC连接故障，开机注册失败等故障；
PS类故障：包含PS无法激活，PS激活成功率低，PS下载速率低，PS出现马赛克等故障；
并发类故障：包括信令流程走不通，终端不支持并发，CN签约问题，传输或者码道资源不够使用等；
切换类故障：包括信令流程走不通，传输或者码道资源不够使用等；
HSDPA业务故障：包括物理信道重配置失败，终端无法接入，HS呼叫不成功，下载速率不理想等。
与业务类相关的常见故障的故障分类及其典型故障现象见表 1.1 1 常见故障分类
表 1.1 1 常见故障分类
故障分类
典型故障现象
常见故障原因
CS类故障
RRC连接故障；
开机注册失败；
信令流程走不通；
单通或者双向无音；
数据对接问题；
干扰问题；
传输或者码道资源不够使用；
PS类故障
PS无法激活；
PS激活成功率低；
PS下载速率低；
PS出现马赛克等；
数据对接问题；
干扰问题；
传输或者码道资源不够使用；
并发类故障
先做PS业务，然后被叫CS业务失败；
先做PS业务，然后主叫CS业务失败；
先做CS业务，后做PS业务失败。
终端不支持并发业务；
CN没有进行正确业务签约；
终端或者笔记本参数设置问题；
有的并发业务没有必要，例如CS12.2K和CS64K并发；
无线或者传输资源不够使用；
CN或者RNS没有下发第二类寻呼；
切换类故障
信令流程不正确；
CS切换后无声或者有杂音；
PS切换后速率异常。
RNC没有下发测量控制，或者测量控制消息不准确；
目标小区Iub口传输资源不够使用；
目标小区无线资源不够使用；
目标小区干扰过高，导致切换完成消息（物理信道重配置完成或者RB重配置完成）不能上报；
CN没有给RNC发送数据包或者全部是静音帧；
UU口用户面数据包异常；
RUB单板故障；
终端故障；
HS类故障
物理信道重配置失败
终端无法接入
HS呼叫不成功
下载速率不理想
第2章 常见故障排查思路
摘要
本章介绍了业务类故障的常见原因、故障原因分析和故障处理方法等。
2.1 概述
业务类故障可分为以下几大类：
1） CS类故障
2） PS类故障
3） 并发类故障
4） 切换类故障
其中,1) 2) 3) 类故障是不包含切换过程的故障. 4) 对切换过程中的故障进行专述，请参考表格表 2.1 1 业务类故障概述。
表 2.1 1 业务类故障概述
故障分类
故障表现形式(包括但不限于…)
CS类故障
1. 手机不能注册
2. 手机收不到寻呼,
3. 接通率底
4. 通话过程中掉话
5. 呼叫拒绝
6. 业务(话音/图像)质量差
7. …
PS类故障
1. 呼叫(PDP激活)成功率低
2. 速率不稳定
3. 马赛克问题
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. 终端故障；
2.2 CS业务类故障
本节介绍CS业务类故障的处理方法，分为几个方面来描述：
1. 典型信令流程介绍
2. 数据对接问题
3. CS业务排查思路
2.2.1 典型信令流程介绍（主叫）
对于CS业务故障处理，应熟悉CS业务流程。当出现问题时要养成从解读、分析信令入手，看看业务走到哪一步，再来定位问题。信令流程介绍请参阅相关文档，这里就不再描述
2.2.1.1 完整的起呼信令流程
一个完整的主叫流程见图 2.2 1。
图 2.2 1完整的起呼信令流程
从信令跟踪入手，从整体上把CS业务问题分为几个大的方面来处理。
1. 小区和公共信道建立正常，如果小区和公共信道建立都不正常，就谈不上业务。小区和公共信道建立异常的故障，请参与相关文档来处理。
2. UE开机注册问题排查。在作业务的前提是，手机能正常注册到网络。如果不能注册到网络，则先检查手机不能注册的原因。
3. Iu口的信令连接建立是否正常。主要涉及到直传消息的信令解读，查看加密、鉴权参数设置是否有问题。
4. RAB指派流程建立是否正常。系统出现问题最多的就是RAB指派流程。用户面出现的问题，都体现在RAB指派失败上。
2.2.2 开通类常见问题-数据对接故障
在开通期间出现问题最多的就是数据对接问题，约占故障总数的80％以上。因为数据配置和故障处理一般是同一个人，在检查参数时往往存在误区。这一点要注意。
首先要向局方工程师和CN侧工程师确定一下参数。
部分关键参数一旦我们照此配置好了CN邻接局的数据，修改起来比较麻烦的。如：MCC，MNC，RNCID，LAC，RAC，SAC。
CS域或者PS域的对接都建议按照先控制面（信令）再用户面承载（数据）的顺序来对接。在对接面的时候，建议按照从底层到高层逐层确认的方式完成对接。
2.2.2.1 下面把对接过程中对接参数和各层对接之间的关系列出来
1、Iu接口信令链路各层对应关系见表 2.2 1。
表 2.2 1 Iu接口信令链路各层对关系
协议层
对接参数
如果有问题，出现的故障现象
PHY
帧格式（SDH还是SONET）
ATM
VPI，VCI，PCR，业务类型
SSCOP建链失败
AAL5
SSCOP
SSCF
MTP3
SLC，SPC，SSF
信令链路状态不正常；信令点不可达
SCCP
RANAP
MCC，MNC，RNCID
SSCP连接被拒；SST发送，收不到对应子系统的SSA。
2、IuCS User Plane各层对应关系见表 2.2 2。
表 2.2 2 IuCS User Plane各层对应关系
协议层
对接参数
如果有问题，出现的故障现象
PHY
帧格式（SDH还是SONET）
ATM
VPI，VCI，PCR，业务类型，
AAL2
PathID
AAL2链路状态闭塞
IuUP
ATM地址
IuUP建立失败；
3、IuPS User Plane各层对应关系见表 2.2 3。
表 2.2 3 IuPS User Plane各层对应关系
协议层
对接参数
如果有问题，故障现象
PHY
帧格式（SDH还是SONET）
ATM
VPI，VCI，PCR，业务类型
AAL5
IP
IPOA本端地址和对端地址
Ping包不通
UDP
GTP-U
本端和对方的GTP-U地址
Ping包不通
2.2.2.2 数据对接过程的一般操作顺序
大家不一定严格要按照这个顺序来，但是可以做为一个判断问题的基本思路。
1、Iu接口信令链路对接流程见图 2.2 2。
图 2.2 2 Iu接口信令链路对接流程
2、IuCS UserData数据对接流程见图 2.2 3。
图 2.2 3 IuCS UserData数据对接流程
3、IuPS UserPlane数据对接流程见图 2.2 4。
图 2.2 4 IuPS UserPlane数据对接流程
2.2.3 CS业务排查流程
CS业务排查流程见图 2.2 5。
图 2.2 5 CS业务排查流程
2.2.4 UE开机注册失败排查流程
UE开机注册失败排查流程见图 2.2 6。
图 2.2 6 UE开机注册失败排查流程
2.2.5 RRC连接故障排查流程
2.2.5.1 上报过程简单介绍
要像排查RRC连接上报困难，首先要了解UE的上报过程以及RNC的处理过程。
总体来说包括两个大的部分：
Ø 随机接入过程；
Ø RNS的处理过程；
2.2.5.2 随机接入过程
随机接入过程相对简单，是耳熟能详的东西了，就不过多介绍了，不知道请自己找的文档看看吧，简单说明一下如何简单确定随机接入成功了？简单来说，就是UE在UpPTS上发送了SYNC-UL，NODEB在FPACH上发送了响应，这样UE就可以在RACH上进行上报RRC连接请求了。可以通过LMT来看UE是否上报了UP，基站是否在FPACH上响应了。方法如下：
从lmt上也可以看到UE上报了UP,FPACH上也有包下发，注意要看是否有效签名个数和FPACH包是从0开始增加的，正常情况下如果从0开始增加，就说明UE可以和基站进行同步；参考图 2.2 7。
图 2.2 7 LMT上关于IP和FPACH的截图
2.2.5.3 RNS的处理过程
介绍完了随机接入过程后，重点介绍RNS的处理过程。我们把RNS的处理分成基站和RNC的处理。UE上报了RRC连接请求消息后，首先发到TBPE单板上解出来，通过BCCS然后到IIA，通过中间传输传输到到RNC的SDTB单板，然后内部交换到IMAB单板，然后到小区建立了的RUB单板上解出来FP包，通过用户面送到RCB单板；排查流程图参考图 2.2 8。
图 2.2 8 RRC上报困难排查流程
2.2.5.4 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 ----------------- *
* dwRachULDataCrciErrNum = 0
* dwRachULDataNotFindTrCHNum = 0
* dwRachCrciNumErrNum = 0
* dwRachFrameLenErrNum = 0
* dwRachSendULFrameToMacErrNum = 0
* dwRachULTfiErrNum = 0
* dwRachULDataLenErrNum = 0
* =================== Fpm 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上启动外网自环 EnetOutLoopSet 1
Ø IIA上查看AAL2包统计数据： m2,用于查看两边收发包数据是否递增
结果如下：
AAL2 MAC收包总数:975, 发包总数:921, 错误总数:0
value = 47 = 0x2f = '/'
IIA->m2
AAL2 MAC收包总数:984, 发包总数:939, 错误总数:0
value = 47 = 0x2f = '/'
2.2.5.6 查看RNC和NODEB之间的接口板上PVC收发包
RACH的AAL2通道上是否收发正常，在IMAB板上和IIA单板上都有一套命令可以查看PVC上是否有收发包的命令，这个命令在我们排查问题中很有帮助，这里在罗唆一下：
AtmlmShowPvcByStatus：查看PVC配置
IMAB->AtmlmShowPvcByStatus
PVC (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_VCI
205 6 0 0 131 6 1 1 131 -- -- -- --
PVC's count is 180 which Status = 0.
BSP_PrintSet 0x20,1：打开统计功能
apcReadIVT 0, R_PHY, R_VPI, R_VCI，查看RNC在OMCB这条PVC上是否给NODEB发送了数据；
IMAB->apcReadIVT 0,0,0,131，重点关注：
ITotCellsRx : 654481627
ITotCellsTx : 654481618 //需要关注该统计是否在递增
apcReadIVT 0, B0_PHY, B0_VPI, B0_VCI查看RNC通过光口或IMA接收到NODEB回的OMCB的报文的统计用下面的命令；
IMAB->apcReadIVT 0,1,1,131，重点关注：
ITotCellsRx : 654594297
ITotCellsTx : 654594345 // 需要关注该统计是否在递增
2.2.5.7 RUB上是否收到了RACH包
由于目前外场的RUB单板比较多，所以可以考虑闭塞RUB单板，仅仅剩下一块单板的方法来确定UE就在这块RUB单板上上报数据，使用RDS工具登陆RUB上，使用ShowRnluDetailStat查看：
查看是否RACH上有包统计增长见图 2.2 9。
图 2.2 9 RACH包统计
2.2.6 RAB指派失败排查流程
RAB指派失败排查流程见图 2.2 10。
图 2.2 10 RAB指派失败排查流程
2.3 PS业务类故障
一般情况下，我们说PS业务有问题，前提是CS业务正常，如果CS业务都不正常，先处理CS业务问题。上节讲述的CS业务故障排查同样适用于PS业务，本节不再描述。本节重点针对数据包的分片、重组统计进行描述。
目前RNC对于Iu-PS口的配置策略是在2个框上分别占用1块APBE单板，此单板上只使用一个光口配置Iu-PS，每个光口上配置2条IPOA及其路由，这样就形成了40M*4=160M的负荷分担配置。RNC在建立Iu-PS承载时会在局内进行轮选，这样RNC上行数据在本业务生命周期内就只在此IPOA上进行发送，对于CN侧的处理，CN在下行发送数据包时对每个数据包进行轮选IPOA，实现数据包的负荷分担发送方式。所以也就是说RNC侧的负荷分担只是对业务的负荷分担而CN的负荷分担是对数据包的负荷分担 。
在3G系统中，数据业务下载速率达不到要求或流量为零，通常是困扰业务测试的重要问题，也是很难排查的问题，它牵涉到网元有核心网，RNC，NODEB，此外还牵涉到终端，应用层工具和外部网等，通常需要从系统的角度来排查，本文重点从无线接入网的角度提供几点排查思路。
PS的故障现象有：
从外场应用和各种测试的经验看，影响速率的主要问题有：
Ø 单板硬件问题；
Ø AAL5通道配置问题；
Ø Iu/Iub口带宽配置问题；
Ø 空口参数问题；
Ø 签约速率和DRBC问题；
Ø 其他，如终端问题，RNC和NODEB版本问题，笔记本性能问题等等；
2.3.1 用户面故障排查思路
RNC系统中的分组域媒体流路径见图 2.3 1。
图 2.3 1分组域媒体流
沿着上图中黑色箭头指示的方向，是分组域媒体流从Nodeb/RNC到CN的方向，CN到Nodeb/RNC的方向刚好相反，这里不画出来了。上图中，黑色线表示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的上下行链路的速率是否是你期望的值。
另外注意一下有保证速率和传输延迟。保证速率可以比你签的速率小一些，如384，保证速率可以是64，传输延迟一般10ms。
2、检查OMCR上PS相关的配置数据，查看路由配置是否正常。
经验：有时，前后台同步没有将IP地址同步到前台，可以在RPU单元上用ip_print_route命令查看路由表中是否有我们配上去的地址，如没有可再次进行整表同步。
3、检查完CN的签约没有问题，就找到RNC的OMCR后台，找到对应的子业务类型，该目录下有对应的PDCP，RLC，MAC，FP，物理层的一些配置，一般情况下可以采用默认配置即可。如果出现PS不通或速率很低的情况需要逐层检查这些参数是否正确。
4、PDCP层参数检查,采用默认值即可，一般选择头信息不出现，无损重定位指示不出现。因为目前头压缩不支持，无损重定位也不支持。
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一般为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对应的是否正常，这是控制上行物理控制信道和物理数据信道有关功率的参数，一般采用默认值，如果需要修改找专门的人士咨询。
另外如果启动压缩模式，压缩模式参数设置不合理也会导致速率异常。打孔可设为80以上。具体可以与专业人士确认。
8、利用showRnlu (DspNo)可以排查某块DSP上的用户面协议统计信息。或直接showRnlu可以看到所有DSP的统计和。clearRnlu （DspNo），表示清空某个DSP的统计，clearRnlu表示清空所有DSP的统计。也可以直接查看某个协议层的统计。如showIuup DspNo，showPdcp DspNo，showRlc DspNo，showMac DspNo，showDfp 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 *
* 向对端发送的时间调整帧 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的统计信息，正常情况下，黑体部分为上行，黑斜体部分为下行。若只有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 *
* 上行:收到的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_MORE] Send Counter = 2
SUFI[ WINDOW] Send Counter = 0
SUFI[ ACK] Send Counter = 27893
SUFI[ LIST] Send Counter = 382
SUFI[ BITMAP] Send Counter = 0
SUFI[ RList] Send Counter = 0
SUFI[ MRW] Send Counter = 0
SUFI[ MRW_ACK] Send Counter = 0
Report Lost Pdus to UE = 3545
======================Recv============================
SUFI[ NO_MORE] Recv Counter = 105
SUFI[ WINDOW] Recv Counter = 0
SUFI[ ACK] Recv Counter = 13152
SUFI[ LIST] Recv Counter = 324
SUFI[ BITMAP] Recv Counter = 0
SUFI[ RList] Recv Counter = 1
SUFI[ MRW] Recv Counter = 0
SUFI[ MRW_ACK] Recv Counter = 0
Report Lost Pdus from UE = 381
Insert Data Sdu Success = 0
Insert Data Sdu Fail = 0
Recv Data Sdu Frm Upper = 10716
Recv Data To be Segmented = 10716
Recv Data Pdu Frm Mac = 64110
Recv Invalid Data Pdu Frm Mac = 107
Recv Status Pdu Frm Mac = 13257
Send Data Pdu to Mac = 33156
Send Status Pdu to Mac = 27895
Am Rlc Send Reset Pdu to Peer = 222
Am Rlc Send Reset Ack Pdu to Peer = 32
Am Rlc Recv Reset Pdu from Peer = 32
Am Rlc Recv Reset Ack Pdu from Peer = 7
如果链路正常，RLC统计中主要是NO_MORE和ACK，如果接收到的LIST，BITMAP，RLIST相对ACK的比例较大，说明RNC侧RLC发送的包在空间丢失较多，说明下行链路质量不好。如果RLC发送的LIST较多，说明上行UE发送的很多包丢失，上行链路质量不好。另外如果发送
展开阅读全文
浙ICP备2021020529号-1 | 浙B2-20240490 
