PS业务问题优化指导书

1、大唐移动通信设备有限公司 ps业务问题优化指导书ps业务问题优化指导书(仅供内部使用)项目名称支撑项目文档编号qrsn00015590版 本 号v1.0.0作 者版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注2009-7-6龚莉v0.0.1创建提纲 2009-7-15龚莉v0.0.1创建原文2009-7-20梁剑补充5.3、5.4、6.1

2、节相关内容；唐宏川补充7.1.1、7.1.2节相关内容赵敏补充7.1.3、7.1.4节相关内容；基站同事提供补充、、、、6.2、3.1、节相关内容。目 录1概述42ps问题评估42.1ps 业务qos指标要求43hspa速率问题checklist53.1hsdpa速率问题checklist53.2hsupa速率问题checklist（待补充）74数据采集74.1综述74.2nodeb侧log抓取方法84.2.1atp日志的抓取和分析方法84.2.2nodeb侧告警抓取和分析方法204.3rnc侧log抓取方法214.3.1i

3、ma物理传输的log抓取和分析方法214.3.2rnc侧信令跟踪log的抓取和分析方法234.3.3rnc侧qos跟踪log的抓取和分析方法244.3.4rnc侧gtp-u统计抓取和分析方法254.3.5span outum软件抓取终端信令信息274.3.6miniptas软件联芯log 304.3.7ethereal等抓包工具 334.4cn侧log抓取方法334.5数据采集工具汇总335数据分析345.1接入失败345.1.1ue直接发起ps业务 345.1.2ue作为pc的modem 355.2业务面不通425.2.1r问题分析 425.2.2cn侧问题分析 485.3数传性能差495.

4、3.1查看告警 505.3.2操作类对比和分析 505.3.3dch承载ran侧数传性能差问题分析525.3.4hsdpa承载ran侧数传性能差问题分析555.3.5cn侧数传性能差问题分析645.4数传中断665.4.1dch数传中断分析 665.4.2hsdpa数传中断分析 686案例716.1ran侧案例716.1.1中试端到端应用测试线hsdpa下载有缝隙716.1.2银川td上网本做hsdpa打开网页没有速率726.1.3兰州网页打开慢及在线视频不流畅问题726.1.4用户拥塞导致掉话（iub资源受限）736.1.5某局点测试上行ps64k业务速率不能达到验收要求736.1.6不同业

5、务类型下的ping包时延的统计和分析736.1.7南京出现业务不通现象746.2nb侧案例766.2.1终端接入后，速率没有达到预期速率（带宽配置受限）766.2.220所基站dpa速率始终200-300k（参数配置问题）766.2.3速率偶尔能达到2.6m，有时只有2m（e1链路质量问题）766.3cn侧案例776.3.1上海网络网页浏览速率慢，ftp下载速率低776.3.2移动应标测试hsdpa 2.8m速率不稳问题786.3.3长春网页打开慢问题 796.3.4服务器tcp窗口过小导致ftp下载速率低问题796.3.5同时进行上传、下传问题806.3.6多个ue同时下载速率下降问题816

6、.3.7ps速率不稳定问题（ip丢包问题）826.3.8商用局ps单线程速率不稳定攻关（ip丢包问题）837附录847.1附录1：ps业务相关知识847.1.1ps相关协议简介 847.1.2ps数据传输通路 897.1.3ps业务承载方式 917.1.4hsdpa相关算法及参数介绍927.1.5tcp接收窗口修改方法1127.1.6mtu修改方法 1127.1.7修改注册表 1137.1.8pdp激活请求消息中确认apn、速率1147.2附录1：ps业务相关工具介绍1167.2.1tcp接收窗、mtu修改工具1167.2.2sniffer 1167.2.3ethereal通用抓包工具 117

7、7.2.4wireshirk通用抓包工具117封页4 1 概述在td-cdma网络中，除了传统的会话业务，数据业务作为无线网络方兴未艾的特色业务，具有很大的发展前景。反映td-cdma数据业务性能的指标主要有以下几个方面：1）接入性能，通过数据业务的rrc建立成功率、rab建立成功率，以及pdp激活成功率反映。2）业务保持能力，即ps业务掉话率。3）吞吐率4）时延，包括接入时延以及各项硬切换发生时造成的业务中断时延。本文针对ps业务网络优化中经常出现的接入、数传不通、数传速率低、数传速率不稳、数传中断等问题的log抓取和分析定位方法进行描述，给出问题的处理流程和常见故障分析。文档中hsdpa部

8、分问题分析、shell命令、产品功能等描述主要基于目前产品版本：tdr3000v4.10.10_18tdb36a_v4.00.00.33_20090509其中涉及的rrm算法和产品实现默认是指rrm算法设计报告v1.5.2版本本文第1章概要介绍文档编写的目的和内容；第2章介绍td-cdma ps业务吞吐率优化目标，用于发现和评估ps业务问题；第3章给出问题定位时的checklist；第4章介绍数据采集和log收集方法，包括dt/cqt测试和信令跟踪分析等等；第5章介绍数据分析流程和方法；第6章介绍一些常见的ps业务优化案例，包括ran侧优化案例和cn侧优化案例；第7章介绍与ps业务相关的原理性

9、内容以及相关工具。2 ps问题评估2.1 ps 业务qos指标要求ps吞吐率优化目标可从dt/cqt、话统等角度提出。目前仅仅给出常用dt/cqt指标，如下面表1所示，话务统计的指标待后续补充。表1 dt/cqt测试对ps吞吐率指标要求指标业务参考值测试方法参考r99下行平均吞吐率ps ul64k/dl 64k4856kbps1)市区8天线，在c/i5db, 广播信道rscp-85dbm的区域进行测试；2）在话务量比较低的时候进行测试，排除由于拥塞导致的掉话问题；3）ftp服务器放置在cn内；4）采用5线程下载；5）由于非接入网问题或者ue引起的吞吐率下降的问题需要排除；ps ul64k/dl

10、 128k96106kbpsps ul64k/dl 384k300350kbpsr99上行平均吞吐率ps ul64k/dl 64k4856kbps1) 市区8天线，在c/i5db, 广播信道rscp-85dbm的区域进行测试；2）在话务量比较低（要求上行和下行的负载不超过规划的负载）的时候进行测试，排除由于拥塞导致的掉话问题；3）ftp服务器放置在cn内；4）采用5线程上传；5）由于非接入网问题或者ue引起的吞吐率下降的问题需要排除；hsdpa单用户下行平均吞吐率ps ul64k/dl 2048k1.1-1.52mbps(bler=10%)1) 广播信道rscp-85dbm的区域进行测试；2)

11、 2:4小区，hs-pdsch占用三个整ts,载波功率、iub带宽资源都不受限定3）空载、单用户小区中心hsdpa单用户下行平均吞吐率ps ul64k/dl 2048k（2倍复用）1.1-1.3mbps1） ps算法关闭2） 上行速率同下行速率比值为2%3） 最好是上行限制64k接入.4）用移动指定的ftp服务器，采用5线程下载。5）联芯8130终端相比下性能会更好。6）非连续与连续时，单用户下载速率相差不大。hsdpa单用户下行平均吞吐率ps ul64k/dl 2048k（空分复用）1.1-1.37 mbps1) 两通道隔离大于30db，满足空分测试条件，空分效果较明显，下行snr10db。

12、2）用移动指定的ftp服务器，采用5线程下载3）测试过程中，如果发现速率不是很高，需要不断地尝试移动两个用户的位置，改变用户之间的隔离度，速率会进一步提升。4) 在速率不高的情况下，可以尝试调整波束赋形门限x值（默认值是16384），将该值变小。5）2重空分复用时，小区总的吞吐量接近原来的2倍；4重空分复用时，小区总的吞吐量接近原来的4倍。3 hspa速率问题checklist鉴于现在大部分网络支持的ps业务都承载在hspa信道上，hspa吞吐率问题最为常见，也较难定位，下面就根据以往经验给出了定位hspa吞吐率类问题的checklist，方便现场快速缩小问题范围和定位故障。3.1 hsdpa

13、速率问题checklist检查类别检查项自检1便携机（终端）检查项1.1便携机（笔记本终端）tcp window size设置正常，可以用drtcp优化，tcp window size设置65535，mtu=15001.2便携机内存至少512m以上1.3下载时检查便携机cpu占用率，防止便携机cpu占用满了影响下载速率1.4关闭便携机的防火墙软件2.rnc侧检查项2.1在rnc omt执行小区状态查询，确认小区已经激活2.2如果对h业务进行测试，需检查小区类型是否“混合hsdpa小区”或纯“hsdpa小区”；2.3检查给hsdpa分配的hs-pdsch码个数，按照协议要求配置一个pdsch时隙

14、要占用500k的带宽，一般dpa小区配置为2上4下，下行hs-pdsch配置三个整时隙，对应48个bru .2.4检查该小区h频点使用hsdpa的最大用户数，该用户数不能为“0”；2.5检查 hs-pdsch与 hs-scch的总功率，需要配置为小区最大发射功率2.6上行伴随dpch的速率不小于32k，推荐配置为64k；如果是单用户尽量配置dpch为连续分配：重复周期为1、重复长度为1、偏移为0。2.7算法参数检查u hsdpa算法参数：由于nodeb和终端的限制，“dpch是否采用不连续分配”需要设置为否；u lcc算法参数：关闭lcc算法；u cac算法参数：由于受到终端上报ue能力的限制

15、，建议关闭“资源分配是否考虑ue能力-pdcp”；interactive/background的上行速率是否限制需要配置为“不限制”（否则上行申请128k及以上速率时将按照dch 来分配资源）；u rls算法参数：关闭上下行无线链路监测算法；u ps算法参数：建议关闭ps算法开关.2.8检查rnc版本，确保该版本没有已知问题影响数传速率2.9检查iub带宽配置，对应支持hsdpa业务数据链路的pvc带宽，单h小区数据链路的带宽配置不应该低于2m（e1链路激活一路就是2m的带宽，e1链路的带宽要大于数据链路的），如果一个基站三个h小区，则at m方式至少需要3根e1； rnc和nb之间的链路带宽

16、逻辑上设置的带宽要小于等于物理上的e1带宽，如果逻辑上的大于物理上的e1，速率也会受到影响，实验室测试数据要小200k左右。2.10核查nodeb侧的带宽设置是否和rnc侧一致，不一致的话需要修改一致（一般在rnc侧修改带宽数据后需要对应修改的数据）； 2.10将问题nodeb与其他nodeb与rnc间的ping包往返时延对比，核查是否有明显差异，以快速发现iub口是否可能有传输问题，是否有rlc丢包的可能性。2.11检查小区的pccpch配置是否合理，要求比小区最大发射功率小3db左右2.12 检查ptpa单板是否正常2.13检查问题小区的ima传输是否连续有ima帧失步（icp帧错）告警。

17、3.侧检查项 3.1 ldt-b上是否有大量“fp下行dch crc校验错误”和“fp收到tfi错误”告警；3.2 ldt-b上是否有dsp任务运行故障告警；3.3 ldt-b 连接问题nb，查询 ima信息-链路性能统计，刷新并关注各条激活ima链路的“帧失步”和“接收非法icp信元”、“接收stuff信元数”统计；3.2检查上行和下行bler是否超过10，要求小于103.3 初始bler表示数据发送过程中的误块率。如果空口质量较差，重传次数较多的时候，可以将初始bler由默认的10修改为1，此修改需要结合cqi修正范围进行调整，对于bler由10改为1的情况，cqi修正范围最小增量可以设置

18、为83.4如果速率不能达到预计的结果，可以尝试调节cqi修正算法的开关、步长和最大增量、最小增量。还可以通过调节初始的bler来控制反馈的块大小。cqi修正算法默认为打开的，如果速率可以达到要求但是速率不稳定，可以尝试将cqi算法关闭。当cqi算法打开的时候速率低时可以将修正步长增大为2，这样可以较快的调整rtbs的大小。步长最大增量表示当rtbs需要向上修正是增加的最大幅度；最小增量表示需要将rtbs向下做修正的时候在原来反馈的rtbs基础上减小的最大幅度值。一般步长、最大增量和最小增量默认值为1、3、-8，但这个默认组合并不是每个基站都适用，有些基站配置默认值速率仍然较低，需要将其做一下调

19、整如步长增大到2，最大增量设置大于3的数，最小增量要减小-2或者0。3.5 hsdpa的流量控制参数调整也会对速率产生相对微小的影响。如将速率低于低门限时增加的pdu个数由默认的1增加到2，这样可以使得速率降低后到达一个较大的向上修正值。3.6 fc下行功控开关默认是打开的，但是由于联芯终端的功率控制存在问题，相同的环境下与数据卡的下载速率相比要低，这时将fc的下行功率控制开关关闭后会使速率有明显的提升而且速率较稳定。3.7提取对应时间段性能统计，看该小区的上行ts iscp测量是否偏高。备注：观察iscp平均和最大值，一般大于-90dbm就认为有异常。3.8 检查fc 的hs-pdsch的功

20、率配置是否是按照时隙最大发射功率配置（即配置的是初配值）4.cn检查项4.1sim卡开户速率正确，下行2m，建议上行开户64k5.iu口检查项5.1检查rnc iu带宽配置是否充足，需要满足业务需求5.2检查sgsn iu带宽配置是否充足，需要满足业务需求6.服务器检查项6.1如果是servu作为服务器，检查servu发送缓存和接收缓存，都设置成65535；6.2服务器tcp window size设置正常，可以用drtcp优化，tcp window size设置65535，mtu=15006.3服务器最好采用service 2003，监控下载时的cpu占用率，防止服务器性能影响下载速率6.4

21、可以用ethereal(或wireshark)在测试时候进行抓包，然后通过tcp层协议显示数据核查tcp层是否有丢包等7.其它检查项7. 在ps业务测试中，为了减小应用层tcp接收窗口等因素的影响，推荐使用flashget等多线程下载工具，线程数一般可设为5。对于上行数传，可打开多个ftp进程同时上传。建议使用flashfxp软件下载保定的服务器ftp:/gprstest:gprstest05。3.2 hsupa速率问题checklist（待补充） 4 数据采集4.1 综述通过性能统计、dt/cqt测试，以及用户投诉等途径发现问题后，除了cdl分析和dt/cqt测试这两种

22、途径，还可以结合其它工具来进行问题的分析和定位。如rnc ldt的信令跟踪、模拟shell 功能、rnc运行日志，事件日志、各网元的告警、omt上单板和链路状态查询以及wireshink等辅助测试的小工具等。下面分别对不同的网元实体的log 收集和基本分析方法作简单介绍。4.2 nodeb侧log抓取方法基站侧需要做好的工作： 查询基站软件版本、固件版本。 检查基站是否处于正常运行状态，各板卡的指示灯是否正常、板卡接口的连接线是否畅通等。 查询小区的id、频点、码字。 理清“频点bburru”的对应关系。 查看小区iscp的情况。提取公共日志（初始化日志、告警日志、数据一致性文件、动态配置文件

23、）、ccu41/43号日志、bbu全部日志、atp消息。基站侧抓取log主要是通过测试工具完成。应用的主要测试工具包括：lmt-b、atp、pc机等。4.2.1 atp日志的抓取和分析方法 pc机上的ip配置方式（该配置以tdb18ae为例）针对tdb18ae基站，网线从accu板卡（一般在0机框1槽位）的bug口和trace口连接到hub上，通过网线将hub和pc机连接。pc机内网的ip配置和测试工具的ip配置如下：配置好该页面的ip后，点击“高级”选项，添加如下ip00 mask 00 mask 255.255.25

24、5.0点击pc机的“开始”菜单-运行，输入：cmd添加ip由scp到其他板卡的路由：route add mask 92 (accu板卡在0机框0槽位配置 )route add mask 92 (accu板卡在0机框1槽位配置 )如上pc机上的ip配置完成之后，可以登录atp、lmt-b、hammer等工具。在登录这些工具之前要事先将ip参数配置正确。 atp日志的抓取登录atp之前，ip参数配置如下： 点击“连接管理”进入“板卡登录配置”窗口，按照上面pc的配置

25、，做如下配置注意：如果accu板卡在0机框1槽位上，“dsp跟踪代理ccu插槽号：”要填写1。在0机框0槽位就填写0。否则无法跟踪出物理层消息。 上面配置的bcp01位置是0机框1槽位，bcp02位置是0机框3槽位。（槽位号从0算起）配置好如上ip，就可以登录相应的板卡跟踪log了。跟踪log分为跟踪信令面的log和业务的log。跟踪log之前要选择对应的接口，将跟踪开关打开。跟踪信令面的log一般按照如下进行选择：在跟踪信令消息的时候，如果不需要分析测量上报相关的接口，可以将测量上报滤除，减少log的占用空间。测量上报一般在bcp处理器的pl-apb、apb-mac、mac-apb中。如下所

26、示：跟踪业务的相关消息一般是通过发送测试消息跟踪的，在抄送业务的消息之前必须确保pl-gts和gts-l2两个开关是选中的。上面界面可以在atp中“消息跟踪”“测试消息设置”打开。对于hsdpa业务一般跟踪的消息包括：32号、30号、28号、15号、121号中的o_maccc_scch_data、o_maccc_dsch_data。跟踪消息前要通过-b查看要跟踪的用户所在的bbu是否是上面设置的bcp01，用户对应的载波是否设置为1。如果通过这种方式无法跟踪出想要的测试消息，还可以通过atp手动发送测试消息的方式完成。发送消息的步骤及注意事项如下：1、消息模拟-模拟文件编辑 或者直接通过快捷键

27、“ctrl+r” 打开 对话框中选择要发送的测试消息。当选择中相应的测试消息后进入消息编辑对话框，如下：仅以32号测试消息为例说明测试消息的设置：目标处理器号选择要抄送测试消息的bbu。目标地址和源地址的填写是按照规定填写：目标地址的填写是填写bbu板卡上用户所在的dsp上的处理器号。每个bbu上有6个dsp，每个dsp上有4个核，每个核上有不同的模块core0上有ccm、sjm1（ts1）、ac、sd、fp+maccore1上有sjm1（ts2）、fc、bccore2上有sjm1（ts3）、cc目前只用到了前三个核，地址列表（机框、槽位、处理器、sfu类型）的填写就是从bbu板上的第一个ds

28、p的第一个核为2算起，如果抄送fp+mac的消息而且用户建立在了第一个dsp上，则该处的处理器号应该配置为2，如果是第一个dsp的cc模块的消息，则应该配置处理器号为4。第二个dsp的核0配置处理器号为6，核1为7，核2为8.。因此如果用户建立在了第二个dsp上而且要向抄送cc的测试消息则应该配置处理器号为8。sfu类型的配置方法为：cc6号同步消息和ccmac的sich 12号测试消息都配置为26。32、30、28、15号测试消息配置sfu类型为3。配置号四个参数之后就可以核对用户数据（二进制、解析内容、消息描述）下面的参数了，该部分参数的配置要根据测试消息手册中的消息结构进行配置，一般重点

29、关注的参数是消息号、消息开关、频点索引、rl_id。配置好以上参数后先点击页面左端的“保存”，然后点击右侧的“保存”，将测试消息保存。最后点击“发送”。如果测试消息发送成功，就可以在atp的跟踪界面看到相应消息。注：hsdpa测试消息默认放在atp安装目录的tdb36a_testmessage文件夹内的mac文件夹。注意：出现问题后，不要立即关闭，等待10s左右关闭log。在日志中搜索“crnc_cc_id=”，找到出现问题的id（可以由rnc提供，也可以找到完整消息后向rnc确认crnc-communicationcontextid）。确认id（如49821）后，搜索“crnc_cc_id=

30、49821”，找到第一条消息对应的消息名应该是o_apsapb_rl_setup_req，最后一条消息对应的消息名应该是o_apsapb_rl_del_req。这样，就找到了一个完整的消息。截取两条消息之间的内容，搜索各关键字，看各关键消息是否抓到。如m1fc、ccbc、rncfp、ccapb等。 跟踪log分析方法基站侧log按照第二节的方法抓取后，可针对一些主要参数进行分析，说明如下：1、空口质量分析：空口质量分析重点关注cc给mac的sich数据帧，首先看该帧是否连续发送，如果有丢帧说明空口质量较差。ccmac: resource:dsp messagenumber:152

31、4 time:2009-04-29 16:52:09 sfn:0sourceid： 0:3:16:28 destid： 0:3:14:12 opcode： o_ccmac_sich_data length：8bytes.sub_sfn=5543 关注此处是否连续.freq_index=3.msg_number=1.sich_valid_flag=1.sich_index=0.rmf=1.rtbs=42 此处为终端反馈的块大小，可以看出信道质量如何.status_ind=1 这两个ie如果是1、0表明是反馈的ack，说明传输的块是正确的。.decode_ind=0mac cc: resource

32、:dsp messagenumber:1525 time:2009-04-29 16:52:09 sfn:0sourceid： 0:3:14:13 destid： 0:3:16:29 opcode： o_maccc_scch_data length：16bytes.sub_sfn=5544 关注此处检查mac是否连续调度.freq_index=3.msg_number=1.rl_freq_index=3.ue_id=5355.rl_id=0.scch_index=0.scch_data_len=30.uu_sub_sfn=5545.scch_data.startcode=15 该处表示为终端分

33、配时隙的码道资源.scch_data.stopcode=0.scch_data.ts2=0 时隙为1表示为终端分配该时隙资源.scch_data.ts3=1.scch_data.ts4=1.scch_data.ts5=1.scch_data.ts6=0.scch_data.mf=1.scch_data.tbsize=52.scch_data.processid=0.scch_data.rv=0.scch_data.ndi=0.scch_data.hcsn=7fp mac: resource:bcp02 messagenumber:248 time:2009-04-29 13:23:28 sfn

34、:1617sourceid： 0:4:6:10 destid： 0:4:0:21 opcode： o_fpmac_capacity_req length：8bytes该帧是rnc发送给基站的容量请求帧，请求基站要发送的数据量。.fp_mac_capreq_ctrl.u8frametype=1 该ie表示了数据帧类型，1表示控制帧，0表示数据帧。.fp_mac_capreq_ctrl.u8rl_fi=1 该ie表示无线链路所在频点的索引.fp_mac_capreq_ctrl.u8rl_id=1.fp_mac_capreq_ctrl.u8flowindex=0.fp_mac_capreq_ctrl

35、.u8cmch_pi=9.fp_mac_capreq_ctrl.u16userbufsize=84 该值表示了rnc侧的数据量mac fp:resource:bcp02 messagenumber:125 time:2009-04-29 13:07:45 sfn:3884sourceid： 0:4:6:7 destid： 0:4:0:21 opcode： o_macfp_capacity_alloc length：12bytes.mac_fp_capalloc.u8rl_fi=1.mac_fp_capalloc.u8rl_id=1.mac_fp_capalloc.u8flowindex=0.m

36、ac_fp_capalloc.u8cmch_pi=9.mac_fp_capalloc.u8interval=1.mac_fp_capalloc.u8repetitionperiod=0.mac_fp_capalloc.u16max_macdpdu_len=336.mac_fp_capalloc.u16credit=16 基站收到rnc的容量请求帧之后，通过该接口向rnc反馈容量分配帧。这个ie表示基站要求rnc发送的数据块个数。resource:bcp02 messagenumber:126 time:2009-04-29 13:07:45 sfn:3885sourceid： 0:4:6:10

37、 destid： 0:4:0:21 opcode： o_l2gts_test_mode_rsp length：88bytes.struflowctrlinfo.struqueinfo0.u8rl_id=1 .u8queindex=0 .u8validclusternum=0 u8flowctlstate=2 流控状态为2表示有数据发送，为3表示不发送数据.u8quetsn=9 .u8waittime=0 .u8prohibittime=1 .u8prequenum=1 .u16queoutbittti=0 .u32queiubrate=537600 .u32queavguurate=47068

38、6 .u32que_bo=0 . 该处表示基站侧队列中数据，为0表示基站侧没有数据要发送给空口u32rnc_bo=13944该处表示rnc侧缓存中存储的数据，该数据的多少可以反映出rnc侧数据是否饱满。 .u32que_highthreshold=13939 .u32que_lowthreshold=1765 .u32rcvdatalen=0 .u32storedatalen=0 .u32discarddatalen=0 .u16uurate=6632resource:bcp01 messagenumber:122 time:2009-04-29 16:52:12 sfn:2903source

39、id： 0:3:14:12 destid： 0:3:0:21 opcode： o_l2gts_test_mode_rsp length：176bytes.test_nr=32.subsfn=5807.u8rl_fi=0.u8outputindex=1.struperfstatinfo.strumac_fi_perfinfo.u32ackedusrdatavolume=868800.struperfstatinfo.strumac_fi_perfinfo.u32ttinum=151 .struperfstatinfo.strumac_fi_perfinfo.u32uenum=151.strupe

40、rfstatinfo.strumac_fi_perfinfo.u32usrbuffernum=151.struperfstatinfo.strumac_fi_perfinfo.u32acknum=139 该参数可以看出终端反馈的数据是否连续 该值最大是200 说明没有重传.struperfstatinfo.strumac_fi_perfinfo.u32nacknum=04.2.2 nodeb侧告警抓取和分析方法使用lmt-b工具。1） nodeb告警抓取方法如下图：说明：登陆lmt-b后，选择文件，然后上传需要的各种日志2） 告警打开分析方法如下图：3） nodeb常见告警分析一般通过node

41、b告警可以看出物理传输层的问题和ndoeb本地小区以及载波是否存在问题，首先检查是否存在大量“fp下行dch crc校验错误”和“fp收到tfi错误”告警，这些告警的存在说明ndoeb和rnc在传输上有问题；进一步察看传输是否有问题可以在lmt-b上查询 ima信息-链路性能统计，刷新并关注各条激活ima链路的“帧失步”和“接收非法icp信元”、“接收stuff信元数”统计，这些统计通过实时刷新统计数，可以动态统计那些传输链路有问题，这样基本就可以定位传输上的问题。如果nodeb本地小区或者载波有问题，在告警中也可以看到相应的告警，这样就可以判断nodeb本地小区和载波是否有问题。4.3 rn

42、c侧log抓取方法rnc侧需要做好的工作： 查询rnc软件版本、固件版本信息。 检查rnc是否处于正常运行状态，各板卡的指示灯是否正常、板卡接口的连接线是否畅通等。 按照checklist进行rnc 的数据检查。 提取事件日志、告警日志和运行日志，进行小区级消息跟踪（或者ue跟踪）及qos 跟踪 ，rnc侧抓取log主要是通过ldt工具完成。4.3.1 ima物理传输的log抓取和分析方法1） 在rnc 侧ldt上的模拟shell功能下，输入接口板所在架框槽和主cpu号，进入shell命令输入界面，输入以下命令获取传输层ima组和ima链路传输情况的统计信息：drv_ima_ldt_group

43、_count 芯片号, ima组号drv_ima_ldt_imalink_count 芯片号, 链路号drv_ima_ldt_task_count_print 芯片号, 0, 6drv_ima_ldt_task_count_print 芯片号, 1, 9drv_ima_ldt_imalink_event 芯片号, 链路号drv_ima_ldt_imalink_alarm 芯片号, 链路号2） 分析方法：drv_ima_ldt_group_count 芯片号, ima组号/查看ima组消息统计是否有信元丢弃计数，如果存在信元丢弃统计，下一步需要确认那些链路上有信元丢弃，进一步需要查询ima组内各

44、个链路的信元统计情况；如果ima组不存在信元计数统计，说明该ima组工作正常，则下面ima链路的统计命令不需要执行。 drv_ima_ldt_imalink_count 芯片号, 链路号/查看打印结果中发送stuff信元个数，如果ima组工作异常，查看rnc侧stuff信元发送统计，如果rnc侧不发送stuff信元（银川ima传输问题），则说明rnc侧ima工作异常。drv_ima_ldt_task_count_print 芯片号, 0, 6/查看打印结果中ima组添加、删除的计数；当出现ima组工作异常后，需要查询该统计以确认出现问题时是否进行过频繁的删除、添加操作还是因为ima闪断引起的i

45、ma工作异常drv_ima_ldt_task_count_print 芯片号, 1, 9/查看打印结果中ima链路添加、删除的计数；当出现ima组工作异常后，需要查询该统计以确认出现问题时是否进行过频繁的删除、添加操作还是因为ima闪断引起的ima工作异常drv_ima_ldt_imalink_event 芯片号, 链路号drv_ima_ldt_imalink_alarm 芯片号, 链路号/查看打印结果中ima链路的告警计数；当ima组统计有信元丢弃时，再采用该命令查看ima组内的那些ima链路存在告警，以确认ima组内的那些链路故障。4.3.2 rnc侧信令跟踪log的抓取和分析方法1） 信

46、令跟踪的抓取方法侧信令跟踪包含跟踪和小区跟踪两种，下面分别介绍：用户跟踪：进行信令跟踪时，打开软件，点击标题栏“信令跟踪”， 在左面弹出的信令跟踪菜单下选择“跟踪”新建任务，注意这里的跟踪级别有三种，基本级、详细级、ldt级，一般我们都使用详细级的跟踪，详细级/ldt级跟踪包括呼叫过程中产生的内部接口消息，其中ldt 级跟踪包含一些tpss的内部消息，用户标识可以选择不同的初始用户标识，一般使用imsi 跟踪比较好操作，但是缺点是仅仅可以跟踪到common id 后的消息 ，抓取方法可参考下图： 小区跟踪：小区跟踪的抓取方法和跟踪基本相同，不同的是，小区跟踪是针对该小区下所有用户的信令进行跟踪

47、，在不针对某个用户或者不知道用户的情况下发起小区跟踪比较方便。跟踪方法参开跟踪。2） 信令跟踪的分析方法信令跟踪的分析方法比较简单，确认返回失败消息的网络实体，按照哪个网元返回失败那个网元先定位的原则进行，如果是接入过程失败，一般是rnc发起iu release request消息进行资源释放，由于释放可能是内部原因引起的，所以一般需要先抓取小区详细级（带有rnc内子系统的信令交互过程，可以方便定位是哪个子系统返回的失败）信令跟踪来分析，根据失败原因或者释放消息中携带的错误码或者cdl中的，在错误信息表找到对应的错误码进行定位。如果信令已经建立，属于数据传输质量的问题，那么此时需要先对信令跟踪

48、中的消息进行分析。确认参数的配置是否合适，比较重要的三条消息是配置nb的radio link reconfiguration prepration和配置终端的radio bear setup消息和配置rnc本地业务面的hsps_tpss_l2_config_req消息。需要检查消息配置是否正确和在各实体间一致。4.3.3 rnc侧qos跟踪log的抓取和分析方法1) qos跟踪抓取方法和4.3.2节的信令跟踪类似。2) qos跟踪分析方法如下图：3） 分析方法：选择qos跟踪界面的qos分析，rnc侧只能分析上行qos，针对ps业务，28s上报一次统计信息，一般64kps业务正常的速率为（28

49、s/20ms*4（ps业务块数），如果上行有误块，误块超过10%，下行重传（界面显示是下行误块），重传超过10%则 说明传输或者nodeb到rnc的处理数据有问题。4.3.4 rnc侧gtp-u统计抓取和分析方法1） 从ldt信令跟踪上确认需要ps业务用户所在rtpa和dsp号，具体方法如下：在rab指派后rnc本地资源分析消息中，查看倒数第二个响应消息，根据rdbs_rdbs_lc_allocate_rsp_msg中的dspaddr后三位确定用户接入在1-2-13 rtpa业务板,根据dspip的最后一个字节确认在9号cpu（dsp）。2） 在1-2-13 9cpu的模拟shell上键入：t

50、pss_cntr_reset 复位当前dsp之前的统计信息.3） 在1-2-13 9cpu模拟shell上键入：tpss_cntr_show 确认是否计数器清零。4） 用终端做ping业务，长时间保持命令如下“ping ip地址 -l 1000 -t”5） 在1-2-13 9cpu的模拟shell上键入：tpss_cntr_show 显示的信息如下：- uplink statistic -receive data from rach - 0cchfp to macc(fp layer) - 0cchfp to macc(mac layer) - 0receive data from dch -

51、 11900dchfp to macd(fp layer) - 11900dchfp to macd(mac layer) - 12720receive data from edch- 0edchfp to macd(fp layer)- 0edchfp to macd(mac layer) - 0macd to rlc edch(mac layer)-0macd to rlc edch for timerout(mac layer)-0mac to rlc - 6430rlc to pdcp(rlc layer) - 2827rlc to pdcp(pdcp layer) - 2827pdcp to gtpu - 2827 pdcp dro