UNTS维护部HSDPA速率问题定位指导书初级篇

1、文档类别密级 系统问题定位指导书内部公开 所属部门 umts维护部 共19页 umts维护部hsdpa速率问题定位指导书初 级篇 v0.20 拟制系统问题组日期2008-7-22 评审人日期yyyy-mm-dd 批准日期yyyy-mm-dd 签发日期yyyy-mm-dd huawei technologies co., ltd. 华华为为技技术术有有限限公公司司 all rights reserved 版权所有 侵权必究 修订记录 日期修订 版本 cr 号修改 章节 修改描述作者 2008-06-150.18初稿完成王昆仑 2008-07-220.20根据评审意见修改完成 目 录 第1章 概述

2、.5 1.1 当前状况.5 1.2 本文目的.5 第2章 问题分析指导.6 2.1 速率问题分析思路.6 2.1.1 明确问题现象.6 2.1.2 判断问题发生的大致原因.6 2.1.3 根据原因做针对性测试.7 2.2 问题处理流程.7 2.3 速率问题现象的获取方法.7 2.3.1 测试人员描述.7 2.3.2 dumeter截图.8 2.3.3 rnc cdt l2统计.9 2.4 判断问题发生的大致原因.10 2.4.1 判断是否iu接口以上问题.10 2.4.2 判断问题是否和rnc功能相关.11 2.4.3 判断是否iub接口以下问题.12 2.4.4 判断是空口还是iub接口原因

3、.13 2.5 根据原因做针对性的检查.15 2.5.1 iu接口以上问题的参数检查.15 2.5.2 rnc问题的参数检查.15 2.5.3 iub接口问题的参数检查.15 2.5.4 uu接口问题的参数检查.17 第3章 补充.18 3.1 关于本文.18 3.2 信息反馈.18 表目录 表2-1 nodeb支持的流控算法列表.14 图目录 图2-1 hsdpa速率问题处理流程 .7 图2-2 dumeter选项设定示意图.8 图2-3 dumeter截图效果示意.9 图2-4 cdt l2统计跟踪配置.9 图2-5 l2统计中的速率情况查看（土耳其）.10 图2-6 rlc bo满情况的

4、曲线(vdf测试).10 图2-7 rlc bo不足情况的曲线(新加坡m1).11 图2-8 ue引发的速率低(korea).12 图2-9 iub丢包引发的速率波动(香港).12 图2-10 iub带宽配置引发的速率波动(la).12 图2-11 iub重传指标配置.13 图2-12 重传率.14 图2-13 hsdpa监控的启动位置 .16 图2-14 hsdpa监控的形式 .16 章1章 概述 1.1 当前状况 随着wcdma演进到hspa阶段，hsdpa业务已经象语音业务一样，成为无线的基 本业务之一。不论是各个试验局进行的比拼测试、准入测试，还是商用局进行的各 种展示、版本升级、业务

5、验证，hsdpa速率测试都已经成为最基本的测试项之一。 对于语音业务，其端到端涉及的所有设备，从主叫ue开始、经过bts、bsc、 一直到被叫ue，都属于电信网络中的标准设备，qos相对有保证，而且语音业务的 速率也比较低，对资源要求比较少，出问题的可能性也比较少。 而hsdpa业务端到端所涉及的设备相对要多一些，在终端侧要从数据卡延伸到便 携机，在网络侧从ggsn出去要到服务器，这中间大多数情况还要经过公网。便携 机、服务器都属于民用设备，qos基本上是没有保障的，尤其是便携机，安装了各 种软件后性能更是很难控制，而且目前hsdpa主流速率已经到了7.2m，即便是无 线网络中的很多设备、包括

6、终端也都没做好承载这样高的速率的准备，因此很容易 出现hsdpa速率问题。 hsdpa速率即将进入14.4m商用时代，面临的商用局、试验局也会越来越多，速率 问题在短期内还将是困扰我们的主流问题。不过随着设备的成熟、测试人员技能的 提升、客户对速率问题理解的加深，虽然速率问题依旧将频繁出现，但用服、网规 和测试部都将成长起来，承担起问题的分析和解决，那时，速率问题将不再成为困 扰维护部的重点。 1.2 本文目的 速率问题是一个端到端的问题，从便携机开始，经过ue、空口、nodeb、iub口、 rnc、iu接口、sgsn、gn口、ggsn、gi口、传输网络、服务器。这些设备中任 何一个出现问题或

7、者性能达不到要求，都会表现为ps速率不稳或者速率低。 本文总结了常用的问题隔离手段，希望在仅仅利用lmt进行log抓取的条件下，通 过一些简单的数据分析和针对性测试，达到缩小定位范围的目的，使得一线人员可 以更快的找到可能引发问题的位置，从而更有针对性的进行排查，提高定位效率。 章2章 问题分析指导 2.1 速率问题分析思路 速率问题主要有两种：速率低和速率波动。不管是哪种情况，问题分析的思路都是 一样的，大致思路如下： 1） 明确问题现象。 2） 通过rnc cdt，判断引发问题的位置。 3） 根据前面的判断结果做针对性测试确认大致原因。 在确认了问题发生的大致原因后，就是针对性的进行具体的

8、分析和定位了，这部分 内容涉及更多的分析工具，不放在本指导书的描述范围内。 2.1.1 明确问题现象 每个具体的速率问题，都有其独特的特点，在速率异常上也往往表现出一定的规律 性，当然，很多时候这种规律性并不是那么容易就能观测到的。处理速率问题的第 一步，就是要对速率问题的表现进行观察，在明确问题现象的同时，尽可能找出里 面隐藏的规律。 比如：同样是平均速率低的问题，可能是每次速率升高到一定程度就稳定在这个值， 或者是速率先冲高、后回落到某个稳定的值，这种区别就是处理一个问题最先要搞 清楚的。 这一步所需花费的时间并不多，但非常重要，因为当速率出现异常时，很多指标都 会表现出异常，这些异常哪些

9、是因、哪些是果，哪些是主要的，哪些暂时不用关注， 都需要依靠问题的现象和规律来辅助判断。 明确问题现象和规律主要依靠应用层速率截图（dumeter截图）、测试人员的描述、 cdt中的l2统计等。 2.1.2 判断问题发生的大致原因 rnc cdt是最重要数据，从ran的角度讲，定位第一步要进行的判断是：速率问 题主要是受哪个环节的影响导致的？是ue、空口、nodeb，还是iub口、rnc、或 者rnc以上。 rnc的cdt中可以跟踪到丰富的l2信息，这些信息可以让我们初步判断出引发速率 问题的大致原因。 2.1.3 根据原因做针对性测试 在大致得出了问题出在哪个网元之后，下一步要做的是通过修改

10、参数、测试手段等 来验证得出的结论是否正确。 从ps速率问题的处理经验看，现场测试人员在问题定位过程中实际上是能起到很大 作用的，但在问题初期，由于涉及的网元太多，他们往往无从下手，而当问题的范 围缩小到某个网元、并提供了一些调整、测试手段后，现场就可以尝试更多的测试 并提供更多的线索，甚至直接找到问题的根因。 2.2 问题处理流程 hsdpa速率问题建议一线进行的处理流程如下： 观察速率问题的现象和特点 是否iu？口以上原因 uu 参见iu口以上问题检查步骤 y 在rnclmt上抓去问题出现时的cdt跟踪 是否和rnc相关？ 参见rnc相关问题检查步骤 是iub？口还是uu口原因 参见uu口

11、问题检查步骤 确认iub口以下原因的现象 参见iub口问题检查步骤 n y n iub 图 2-1 hsdpa 速率问题处理流程 2.3 速率问题现象的获取方法 获取问题现象的方法包括：1）测试人员描述。2）dumeter截图。3）rnc cdt l2 统计。 2.3.1 测试人员描述 现场测试人员的描述一般都是最早能获取到的信息，对于一些有经验的测试人员， 反馈问题时会从测试背景、目的、一直到问题的现象、已经进行的处理以及现场的 怀疑方向等等都描述清楚，而对于没有相关经验的一线人员，反馈信息则会显得比 较凌乱，在这种情况下，则需要问题处理的责任人主动对测试人员进行引导，从而 获得更全面的信息

12、。 一般来说，希望测试人员反馈的信息包括：1）测试环境信息、2）测试版本信息、 3）测试目标、4）问题的现象（与目标之间的差距）、5）现场已经进行的分析和 对比测试、6）现场的怀疑方向。 由于一线测试人员往往要面临很大的压力，这些口头的描述只作为判断问题现象的 参考，以避免主观因素影响描述引起偏差。 2.3.2 dumeter截图 1 参数设定 图 2-2 dumeter 选项设定示意图 在dumeter的菜单中选择options，在弹出的general页面，确保display units的选择 在kilobits per second(kbps)上。 2 启动跟踪 在进行速率跟踪时，要同时选

13、择new stopwatch选项，在下载开始后，点击start启 动平均速率统计，跟踪时间要足够长，（建议为3分钟），反馈的速率截图类似下 面的样子： 图 2-3 dumeter 截图效果示意 从dumeter的截图上，可以了解到平均速率、最大速率以及速率波动情况以及波动 的规律等等。 2.3.3 rnc cdt l2统计 1 跟踪设定 rnc的cdt在rnc lmt上启动，建议的参数配置如下： 图 2-4 cdt l2 统计跟踪配置 确保速率异常的现象已经出现，并保持1分钟后，停止cdt跟踪。 2 速率查看 l2统计反映出的是rnc l2真实的发包情况，其中直观反映速率变动情况的统计值 是r

14、b.uldlpdunum（l2下行发送的pdu数目），另外rb.usdlretranrate（l2下行重 传率），rb.uldlnaspktthroughput（l2下行收到的数据的吞吐率）这两个指标同时 也可以作为参考。 图 2-5 l2 统计中的速率情况查看（土耳其） 这个速率变化情况和其他资源变化趋势之间的关系，是后续进行问题隔离判断的基 础。 2.4 判断问题发生的大致原因 造成速率异常的原因是很多的，可能同时存在多种原因都会导致速率异常，在分析 时要从源头开始分析，抓主要矛盾，一步一步的解决问题。对于下行速率分析来说， 先从判断是否iu接口以上的问题开始，依次判断是否是rnc的问题，

15、是否是iub口 问题，是否是空口问题。 下面的判断都基于umat的“hsdpa吞吐率分析曲线”进行，打开cdt后，在工 具条上直接点击图标即可。 2.4.1 判断是否iu接口以上问题 当iu接口以上出现问题，或者应用层(如tcp层)出现问题时，在rnc看到的表现是 类似的，就是iu接口发到rnc的数据量不足。对rnc来说，iu接口下发的数据就 是吞吐率的源泉，当数据源泉无法保证时，速率自然不会理想。 通过cdt中记录的rlc bo变化情况，可以判断iu接口下发的数据是否充足，下面 是一次吞吐率测试的例子： 图 2-6 rlc bo 满情况的曲线(vdf 测试) 图中的绿色曲线，就是rlc bo

16、情况，它反应的是下行数据在rnc buffer中积累的 情况，从保证速率源的角度讲，rlc bo关键是有还是无（0或者非0），如果rlc bo一直为非0值，也就意味者rnc一直有数据可以发送，此时rlc bo值是多大， 1m or 2m，反而不重要了（rlc bo曲线和其他曲线之间的相对关系是没有意义的） 。 下面是一个rlc bo异常情况的曲线： 图 2-7 rlc bo 不足情况的曲线(新加坡 m1) 在这张曲线图中，开始的五分之四部分，rlc bo（绿色曲线），基本都是0，这说 明在这期间速率低的原因在于iu接口下行速率不足。（最后的五分之一部分，rlc bo有了明显的增加，这时速率异常

17、则有其他原因，可以参见后面介绍的手段分析） 。 2.4.2 判断问题是否和rnc功能相关 这里所说和rnc相关，不是指rnc有bug，而是指rnc在下发数据时的某些限制 或者功能导致速率出现异常，或者rnc l2和ue l2这两个对等实体之间的交互动作 导致rnc主动降低发送速率，从而引起速率的异常。 这种速率异常在数据上的表现是：1）rlc bo有数据、2）rb下发速率低于nodeb 分配的hsdpa带宽且两者之间感觉不到任何关联。 下面是一个由于ue驱动性能不足，导致ue l2主动通知rnc减小接收窗口，从而影 响到rnc下发速率而导致的速率异常： 图 2-8 ue 引发的速率低(kore

18、a) 图中绿色为rlc bo，红色为rnc下发数据信息，蓝色为hsdpa带宽分配情况。从 这个图中可以看出，rlc bo（绿色）一直很满，hsdpa带宽分配（蓝色）也很充 足，而rnc下发的速率（红色）一直维持在一个很低的位置上。 2.4.3 判断是否iub接口以下问题 iub接口的问题、nodeb的问题、uu接口问题，在rnc看来都是差不多的，rnc能 看到的就是nodeb的hsdpa带宽分配结果是否正常，而对于是什么原因引起 hsdpa带宽分配异常，单纯从cdt是看不出来的。（后面也会提供一些简单的测 试手段判断是iub口异常还是空口异常）。 iub接口一下问题的判定原则是：rnc下发速率

19、和hsdpa带宽分配的波动情况吻合。 下面是一个iub丢包引发的速率波动情况： 图 2-9 iub 丢包引发的速率波动(香港) 从图中可以看出，hsdpa带宽分配（蓝色）一直呈现周期性波动，而rnc下发的 速率（红色）也一直呈现类似带宽分配的波动情况。这说明当前速率波动，根本原 因在于nodeb分配的hsdpa带宽一直在波动。 下面则是一个由于nodeb hsdpa path的scr配置不足引起的速率低的情况： 图 2-10 iub 带宽配置引发的速率波动(la) 在这个例子中，hsdpa带宽分配结果一直维持在4m左右（不考虑中间的几次波动） ，rnc下发的速率和hsdpa带宽分配结果基本一致

20、。象这种比较稳定的维持在某 一个固定值以下，往往都是配置上的资源受限导致的。 2.4.4 判断是空口还是iub接口原因 在明确是iub口以下的问题后，再深入分析，就是要搞清楚，为什么hsdpa带宽分 配结果会出现异常，由于带宽是nodeb分配的，定位这类问题单纯依靠rnc的跟踪 是很难搞定的，往往需要附加其他的log信息，如nodeb调试台的增强性能跟踪、 qxdm或者probe跟踪等，而这类跟踪对于一线的兄弟来说往往并不容易操作，所 以本文介绍几种比较简单易行的判别手段，仍然基于lmt，大致区分是uu接口问 题、iub接口配置问题、还是iub传输问题。（这里只能进行大致的判断，深入的 分析还

21、是要依赖更多的log信息，这部分内容放在中级篇中描述）。 1 l2重传情况 l2重传情况是判断iub以下问题的第一个辅助指标，由于iub口丢包必然引发rlc 的重传，所以判断iub传输是否丢包第一个要看的就是rlc重传情况。查看重传情 况的方法如下： 在吞吐率分析图上右键，选择图例，勾中“下行rlc重传率”这个指标： 图 2-11 iub 重传指标配置 点击ok后，即可查看下行重传率的变化情况。下面是重传率的一个例子： 图 2-12 重传率 重传率低于1%一般认为是可以接收的，此时重传率曲线基本是同座标轴重合的， 象上图中的重传率经常到达30%的情况，已经是非常不正常了。 判断是否存在iub传

22、输问题时，第一个要看的就是l2重传率，重传率为0可以说明 iub口肯定没有丢包，重传率高则说明iub口可能丢包了，也可能是空口丢包了（当 然，空口丢包导致重传率高的情况是比较罕见的）。 2 iub流控方式 另外一个区分iub问题还是空口问题的重要手段就是通过更改nodeb上配置的流控算 法开关（命令：set hsdpaflowctrlpara，参数：switch），在不同的流 控算法作用下，查看nodeb分配的hsdpa带宽变化情况。目前nodeb支持三种不同 的流控算法： 表 2-1 nodeb 支持的流控算法列表 序号中文名称英文名称特点 1自适应流控auto_adjust_flow_ct

23、rl考虑 iub 丢包率和时延、 考虑 iub 可用带宽 考虑空口情况 2简单流控simple_flow_ctrl考虑 iub 可用带宽 考虑空口情况 3无流控no_flow_ctrl考虑空口情况 由于这三种流控算法在带宽分配时，考虑的因素具有阶梯性特点，通过对比不同流 控方式下hsdpa分配带宽的差异，可以判断带宽分配的变化最有可能是由哪个因 素引发的，从而进一步区别问题发生的位置。 3 判断原则 如果l2重传率高，则继续比较自适应流控和简单流控下的hsdpa带宽分配结果： 如果自适应流控和简单流控的hsdpa带宽分配结果存在很大不同，说明重传 的原因是由于iub口存在丢包。 如果自适应流控

24、和简单流控的hsdpa带宽分配结果一致，说明重传的原因最 有可能在uu口。 如果l2重传率低，则继续将三种流控方式下hsdpa带宽分配结果放在一起对比： 如果三种流控方式下hsdpa带宽分配结果差不多（均存在异常），说明当前 问题主要出在空口上。 如果无流控下hsdpa带宽分配结果比较好，剩下两个异常，说明当前问题主 要出在iub口传输的配置上。 如果只有自适应流控下hsdpa带宽分配结果异常，可能的原因是由于iub口存 在fp包乱序导致nodeb误判或者时延抖动比较大触发了自适应流控的带宽调整。 这里要留意的是，对比带宽分配结果时，务必保证每次测试都按照前面介绍的分析 过程从头开始判断，要确

25、认每次测试都是由于iub接口以下原因导致速率异常或者 测试结果已经正常了，再进行本节介绍的对比过程，来确保对比的有效性。 2.5 根据原因做针对性的检查 在初步对问题可能存在的位置进行判断后，可以通过有针对性的检查、修改相关参 数，来尝试解决问题。 2.5.1 iu接口以上问题的参数检查 应用层数据量不足，最常用的手段就是采用多线程（10个线程）来规避，但实际应 用中可能由于服务器侧的线程数的限制，导致虽然设置了多个线程下载，但实际上 只有一两个线程真正在下载，所以在实际测试中，要注意观察下载软件是否的确是 在使用多个线程下载。 如果多线程测试结果还是数据量不足，则可以采用从服务器向ue灌包来

26、检查速率 不足的原因。如果灌包时，rlc bo中的数据依然不足，那说明从iu接口到服务器 之间存在一个瓶颈，后续从sgsn、ggsn、各个交换机配置、直到服务器，一路 查过去，看到底哪里的配置限制了速率。 如果灌包后rlc bo数据充足了，说明速率不足应该是应用层的原因导致的，问题 可能出在服务器，或者iu口以上存在丢包，或者空口存在上行误块，可以采取的措 施一般是改从多个ftp服务器进行多线程下载、修改便携的tcp参数来规避服务器 以及丢包造成的影响，以及提高上行sirtarget减少上行误块。根因则需要进行更深 入的分析以及对比测试，这部分不在本文的范围内。 2.5.2 rnc问题的参数检

27、查 针对本文所涉及的定位手段而言，如果判断速率是rnc原因，只能检查一下 hsdpa path的scr是否太小了，或者rnc的反压算法是否生效了。l2行为异常分 析不在初级篇范围内。 如果发生这种情况，请一线尽快按照umts维护部hsdpa速率问题信息采集指导 书的要求，将所需信息反馈给维护部进行处理。 2.5.3 iub接口问题的参数检查 iub接口检查主要有两点：1）hsdpa path配置的rcr是否正确。2）iub传输中所 涉及的设备配置是否正确。 如果nodeb的软件是v18版本，也可以在下载时通过nodeb lmt的“hsdpa monitor”来观察此时nodeb分配带宽的情况：

28、 图 2-14 hsdpa 监控的启动位置 下面是监控的结果列表： 图 2-15 hsdpa 监控的形式 结果包含五列数据，这五列的含义分别为： 1.total bandwidth(bps) 端口总可用带宽，计算公式为：iub口物理端口带宽 信令占用带宽 维护通道带宽。 2.r99 allocated bandwidth(bps) 物理端口上r99占用的带宽，其值为所有r99建链 时分配带宽的总和。 3.hsdpa remain bandwidth(bps) hsdpa可用带宽，计算公式为：min（hsdpa rt path配置的带宽 hsdpa nrt配置的带宽，物理端口带宽 信令占用的 带宽 维护通道的带宽 r99占用的带宽）。 4.hsdpa allocated bandwidth(bps)：指所有dsp上给hsdpa分配带宽。 5.hsdpa used bandwidth(bps)：指所有dsp上hsdpa业务实际使用带宽。 根据这些带宽分配结果可以大致判断hsdpa带宽分配异常可能是由于哪里引起的： 如果是第一列“总可用带宽”