灌包测试

灌包测试

RB重配置频繁，考虑是不是存在用户数过多的情况。另外你的RTWP是从后台跟踪还是前台信令得到，建议还是需要从后台单板跟踪比较明显，查看清楚具体情况，测试端也可能存在问题。速率很低的话，考虑是不是没有正常接入。可以查看是否承载在EDCH信道上

感觉是你自己上传的资源有问题，导致RLC资源不足，你把信令双击打开，看上报的是4A事件还是4B事件，建议重换FTP地址，或者灌包测试，再不行的话，关闭Dccc开关，进行测试。

自动灌包 是测试RNC 到UE 的链路是否畅通，如果链路无问题，进行灌包操作，测试速率会很高！

就是在CDT跟踪那个选项里就有灌包选项，输入在现场测试的数据卡的IMSI。拨号上网后就可以开始灌包

华为自带DBS3900,在通过IMSI跟踪时就有这个选项，灌包测试其实就是当对速率异常问题进行排查过程中的一个步骤：查看RNC 和 NODE B 的数据正常。

灌包模式与非灌包模式在同一个地点测试，最直接可以体现出是否受服务器TCP窗口大小限制，或者受服务器性能限制，等于抛开服务器性能不管，单纯的空口性能测试，华为的后台可以直接灌包，最好灌包的时候把L2的信令也跟踪下，可以分析下RNC的BO，建议CDT跟踪时采用灌包模式，虽然指标会高出很多，但是能抛开服务器的影响。

灌包测试其实就是当对速率异常问题进行排查过程中的一个步骤，数据业务是端到端的（UE-CN），问题定位起来相对困难，因此排查问题时也经常采用排除法。灌包测试的具体过程就是从RNC侧人为地下发数据到UE侧（可以向指定的IMSI下发），同时UE侧进行HSDPA业务测试，观察UE的下载速率是否正常，如果正常，说明问题不在RAN侧，应该往RNC-CN或CN-外部服务器方向去排查定位；如果异常，那么就在RAN侧进行相关排查，其实就是一个由面到点逐步定位问题的过程。

灌包测试实际操作是在RNC LMT上进行的

下行灌包在CDT跟踪中有个选项，上行灌包用TEST PING

建议通过灌包的方式，从RNC侧往UE灌包，如果灌包稳定，排除设备和参数问题；如果灌包速率也不稳定的情况下，最重要的看一下RTWP，我遇到过一次就是干扰过大造成速率不稳定。

1、把测试卡设置成金牌用户以排除多用户的影响；

2、检查相关的拥塞及HS功率设置参数，多半是无线参数的问题

查看传输有无问题，包括RNC和基站侧定义的AtmTrafficDescriptor,QOS等等？

查看有无告警或隐性故障(针对某个站点)？

FTP服务器是否正常？

测试设备有无问题？

：1.先在后台跟踪一下此区域的RTWP值和CQI值，看一下此区域是否存在干扰。

2..在排除干扰的情况下，在RAN侧查看上行Uu接口的误码（UL BLER）,他会直接影响上传速率。

3..在查看Lub接口的传输误码，时延抖动，以及Lub带宽等问题，他也会直接影响上传速率。

4.查看一下此区域基站相关小区的HSUPA的资源分配情况（可以找一个好的作对比）

（1）HSUPA信道码资源分配是否合理

（2）HSUPA伴随的DCH信道码资源分配是否合理

（3）HSUPA信道功率配置（这个比较重要）

5.后台查看没问题后，在查看相关基站的硬件有没有问题（在后台查看有没有各种告警。有一个叫什么RDTU的设备有没有问题，是不是这个设备我记不清了，你可以问一下基站督导）

6.最后在看一下此区域的上传速率是不是很大，如果你是上传下载同时测得话，有时候上传下载是相互有影响的。建议分开来测试试一试。

以上是根据楼主遇到的情况分析的，不一定准确，仅供参考。

1.天馈参数不合理导致掉话问题描述

如图所示，当车辆行驶至如图所示位置时，UE同时占用3个主导频，RSCP都在-86dBm左右，Ec/Io都在-9dB左右，而且相差较小，为导频污染现象。测试中过程中发生掉话。

处理过程

由于该路段周边基站天馈参数不合理，导致出现较为严重的导频污染，并且出现邻区漏配情况，从而导致掉话发生，重点从天馈调整入手，解决掉话问题。

处理结果

经将北玉丰70号_1、_2的电下倾角由0度/0度调整为2度/2度；将中菲大厦_1的电下倾角由6度调整为8度；在对中诚大厦_1和北玉丰70号_1、对中诚大厦_1和北玉丰70号_2、对中诚大厦_1和电器成套设备厂_2、军粮供应站_3和电器成套设备厂_2互配邻区；再对电器成套设备厂_2升功率后，不再掉话。

下面是调整前后对比图：

调整前RSCP调整后RSCP调整前Ec/Io调整后Ec/Io2.越区覆盖导致掉话

问题描述

调整前EC/IO

如图所示，当测试车辆由南向北的行驶过程中，UE占用梁家街村1、2小区、电力技校1、3小区，但在检测集发现PSC（扰码）为33的信号，且RSCP在-95dBm左右， Ec/No在-10dB左右，分析此区域为PSC（扰码）33的信号（经核查不是三瑞金属_2而是木材公司_2）为越区造成掉话。

处理过程

鼎立掉话覆盖图（下附图），分析为三瑞金属影响导致掉话，经核查三瑞金属2小区发现PSC为33的信号非常可疑，三瑞金属距电厂西路掉话点4.5公里左右，经核查RNC机房，此站正常，经关闭此小区发现PSC为33的信号依然存在，所以确定并非是三瑞金属_2小区导致掉话，经核查“西安WCDMA基站信息汇总表(共942个站点)V.090815”确定是基站木材公司_2所导致，经关闭木材公司_2验证就是木材公司_2小区越区造成的掉话。且由于业主（物业部工作人员今天有事提前下班）下班木材公司基站未能调整（楼顶门被锁）。所以暂添加木材公司和梁家街村、电力技校、堡子村为邻区。

处理结果

经添加木材公司和梁家街村、电力技校、堡子村为邻区。

下面是调整前后覆盖对比图：

调整前的RSCP分布图调整后RSCP分布图：

调整前EC/IO分布图

调整后EC/IO分布图

3.扰码复用不合理导致切换失败

在西安联通发现多小区（超过3个小区）站点更软切失败是由扰码复用造成的。新加信号的SFN_Frame_与老信号差2以上。经研究，发现多为同扰码小区的越区干扰，造成切换失败。提交网优同事修改扰码后，扰码复用问题解决。

分析软切失败原因

RNC3074下NodeBID180，10801质检大厦_1（PSC126），10802质检大厦_2（PSC134），10803质检大厦_3（PSC142），10805万嘉商务酒店（科技路）（PSC461），10806萨菲尔。从关联日志中可以看到当前小区为10805（PSC461），试图更软切10801（PSC126），如图1所示。

图1 试图加10801（PSC126）

2009-07-16 12：59：02测量报告内容为：报1a加PSC126，当前激活集里面的PSC461帧偏2（如图2所示），但PSC126帧偏203（如图3所示）.

图2 PSC461帧偏2

图3 PSC126帧偏203

我们之前看到的多小区站点出现软切失败都是激活集里先加后减（测量报告中各小区帧偏都一样），先报1a，然后1b删去不好的那条腿，之后就报无线链路增加失败。其原因就是。

综上所述，多小区站点软切失败时上面两种原因可能同时存在，当然也有相当数量的多小区站点软切失败是仅由激活集原因造成的。

解决多小区站点软切失败的方法

根据上面的分析，要解决多小区站点软切失败问题首先要改小区扰码。

网优同事修改扰码情况如表1。

表1 扰码修改情况

小区ID 修改前扰码 修改后扰码

10801 126 390

10802 134 398

10803 142 406

10805 461 435

修改扰码后，从2009-07-25从关联日志中测量报告看到报1c，用390替换406，从图4和图5中可以看到新腿和老腿的帧偏只相差1。

图4 PSC390帧偏为7

这种问题多为扰码规划不合理造成同扰码干扰，修改扰码后可解决切换失败。

4.路由器设置不当导致下行速率慢

问题描述

西安联通外场HSDPA单线程下载测试，在无线质量较好前提下，定点HSDPA单线程下载速率平均3Mbps左右且速率波动非常大。在RNC侧对单个UE灌包测试，速率平均5.5m比较平稳，说明Iub口和空口没有问题。

解决思路

从UElog来看，在CQI较好的时候，UE收到下行数据量不足。

说明：红框中数据为TSN标识，标识连续标明下行数据未有丢包

从UE侧抓包看，存在大量TCP包乱序，在乱序后马上会启动快速重传，对DPA的下载速率有很大影响。从UElog上看下行数据报RLC SN连续，不存在乱序，排除Iub口引入乱序的可能。而Iu-PS在RNC《-》SGSN-《-》GGSN《-》PDN均采用IP传输，很有可能存在乱序。

看一下西安这边的组网图：

从图中可以看到SGSN－1通过2个 XK－CE－1 到我们的RNC1、2、3，在CN侧也设置了两个路由，且两个路由没有优先级设置，这样包可能从任何一个路由到RNC，所以很可能产生乱序。

为确定乱序可以在Iu口抓取报文或者在UIM上抓取报文分析，由于西安联通这边用户较多在UIM上抓取报文存在问题，以下引用金华单线程下载速率分析的相关乱序判定数据。

乱序报文判断基本原则：

收到GTPU内部IP 编号1，2，3，里面剥开来，承载的application IP报文（PDN）是 A,C,B，

说明 PDN ->GGSN乱了。

收到GTPU内部IP编号 1，3，2，里面剥开来，承载的application IP报文（PDN）是A,C,B。说明 GGSN->SGSN->RNC乱了。

金华在GUIM上现场抓取报文，分析如下

当TCP乱序发生时，先收到 GTPU 外层承载IP报文 IP ID 为0为0xe4ac，对应承载原始报文IP ID 0X4905

在收到GTPU P外层承载报文 IP ID 为0xe4ab, 对应承载原始报文IP ID 0X4904

从而在GGSN-RNC之间引入乱序。

解决方法

方法1：给每个RNC设置一条主用路由，一条备用路由。西安联通这边由于RNC较多，组网更为复杂，所以未采用这个方式，而采用了下面的方法2.

方法2：开启RNC对下行TCP包进行排序功能，在RNC对乱序进行纠正。

RNC对下行TCP包进行排序，需要核心网发给RNC的Rab指派中带下来Deliver Order参数为保序。

.RAB__[0].rAB__ryOrder = TRANAP_delivery_order_requested

如果为保序，RNC就可以对乱序进行纠正，纠正需要设置以下RNC参数：IuDlInSeqDlvTmr BYTE IU下行数据排序定时器(IU Downlink in Sequence

Delivery Timer) 0~60ms, step: 2ms

0表示无需排序（In Sequence Delivery is not Required） 0：无需排序 (In Sequence

Delivery is not Required) 6:为建议排序时长（Suggested Value） B(B83_BRNC)

解决效果

西安联通打开RNC的下行排序功能（配置为10ms），定点单线程最大下载速率可以达到6.4m，平均速率到5m，改进比较明显。从UE侧抓包看修改后没有再出现乱序。

5. SGSN接口板的光模块故障导致上行速率慢问题描述

8月19日起我们接到大量的用户投诉说是UPA上传没有速率，邮件发送失败。我们在现场进行复现，发现对于DCH或是e-DCH有时拨号上去后速率一直为0，然后user inactivity，持续很久速率也不能恢复，有的时候拨号后UPA和DCH上传速率完全正常。一段时间内反复重复呼叫，总能抓到上行速率为0的情况。上行速率为0的时候，ping PDN服务器大量丢包，但此时HSDPA和DCH下载速率均很正常，从UE采用iperf向PDN UDP灌包速率也正常。

解决思路

刚开始怀疑可能在RUB的某个DSP上有问题，经过试验，发现建立在同一块RUB板的同一个DSP上有正常的情况，也有不正常的情况，排除某个DSP故障导致。

在UE侧使用wireshark进行抓包，发现发到PDN服务器的包，有丢包，很多包UE发送了很多次，PDN服务器却一直没有收到，让UE不断进行重传，导致TCP窗口一直不能正常向前推进，最后TCP窗口完全关闭。整个数据的流向是：UE –〉Node B –〉RNC –〉汇聚交换机- > SGSN->交换机-〉GGSN->DN->GGSN->交换机-〉SGSN->汇聚交换机->RNC->Node B->UE，在手机侧抓取UELOG分析，RLC层上下行包连续不存在重传和丢包。初步怀疑在RNC到PDN服务器之间可能有丢包发生。

联系核心网的同事在SGSN上跟踪SGSN收到的数据，我们在UE侧进行抓包，然后采用ping

包的方式进行测试，在上传无速率的情况下，对比两侧抓下来的数据。发现核心网收到了100次 ping包Request，但是只给RNC发送了67次ping包的Reply，和从UE上看到的一致，所以基本肯定RNC内部没有丢包、RNC和SGSN之间没有丢包。

之后在SGSN和GGSN中间的交换机上进行抓包，发现在交换机上收到的ping包Reuqest和Reply个数是相等的，但是交换机上收到的Request总数要小于SGSN上收到Request，基本定位在SGSN和交换机之间上行有丢包。

解决方法

CN同事最后定位出SGSN接口板的光模块有问题存在丢包。

解决效果

更换光模块之后，在现场测试多次，未出现ping包不通，上行无速率的问题。上载测试也均匀高速。

6.天馈参数设置不合理导致覆盖差

问题描述

如图所示，当测试车辆由东向西的行驶过程中，UE占用灞桥三厂招待所，西安东纺三路，辅仁医院，节约坊等基站信号，且该区域存在RSCP-106dBm左右， Ec/No在18dB左右和一些地方由于导频污染造成Ec/No恶化，分析此区域为明显RSCP、Ec/Io弱覆盖、导频污染问题。

处理过程

该区域属于一个相对较为独立的小社区，由于楼宇密集，地形起伏，加上基站数量有限造成多个路段的覆盖较差，所以通过对该区域的所有基站的天馈参数进行重新规划，集中调整，争取从整体上提升覆盖效果。

处理结果

经调整灞桥三厂招待所_1、2、3小区，1小区电子下倾角由2度调为0度，2小区电子下倾角由2度调为0度，3小区电子下倾角2度调为0度；调整西安东纺三路_1、2、3小区，1小区电子下倾角由6度调为2度，机械下倾角由4度调为0度，方位角由0度调为340度，2小区电子下倾角由6度调为2度，机械下倾角由4度调为0度，3小区电子下倾角由6度调为2度，机械下倾角由4度调为0度，方位角由240度调为220度；调整节约坊_1、2、3小区，1小区电子下倾角由1度调为6度，机械下倾角由6度调为0度，方位角由0度调为30度，2小区电子下倾角由1度调为2度，机械下倾角由6度调为2度，3小区电子下倾角由1度调为0度；调整辅仁医院_1、2、3小区，1小区，方位角由0度调为330度，2小区机械下倾角由6度调为4度，3小区机械下倾角由7度调为6度。

下面是调整前后覆盖对比图：

调整前的RSCP分布图

调整后RSCP分布图：

调整前EC/IO分布图

调整后EC/IO分布图

7.室分系统干扰排查案例

唐城宾馆的RRU连接方式为1光口---3个RRU串联 2光口---2个RRU串联 3光口1个RRU,后台数据为两个小区，把1光口3个RRU做成一个逻辑小区，2光口和3光口的RRU合并为一个逻辑小区

由于这个站点没有找到2G设备，后经证实这个站点未安装2G设备，因此底噪抬升的原因只可能是设备与天馈系统。

联系后台知道1小区的底噪为-96dBm，有明显的抬升，故对一小区的问题进行定位，定位步骤如下：

1、断开一小区第一RRU（2F弱电井与后续两个RRU连接的光纤 ，在第一个RRU堵负载，底噪恢复正常（-106dBm左右）-----证实第一个RRU正常

2、断开一小区第一RRU与后续两个RRU连接的光纤 ，第一个RRU接天馈系统，底噪恢

复正常（-106dBm左右）-----证实第一个RRU正常和第一个RRU连接的天馈系统正常；

恢复第一个RRU与后续两个RRU的光纤连接

3、到第二个RRU位置（4F弱电井），断开第二个RRU与第三个RRU连接的光纤，第二个RRU堵负载，底噪恢复正常（-106dBm左右）-----证实第二个RRU正常

4、断开第二个RRU与第三个RRU连接的光纤，第二个RRU接入天馈系统，底噪恢复正常（-106dBm左右）-----证实第二个RRU正常与第二个RRU连接的天馈系统正常

恢复第二个RRU与第三个RRU的光纤连接

5、到第三个RRU位置（7F弱电井），第三个RRU堵负载，底噪恢复正常-----证实第三个RRU正常（-106dBm左右）

6、第三个RRU接入天馈系统，底噪抬升至-96dBm左右-----得出结论：第三个RRU接入的天馈系统存在问题，引起底噪的抬升，故需室分厂家对第三个RRU的天馈系统进行排查

8.弯道效应造成掉话

问题描述

测试在拐弯处主叫占用民航老干部处3小区，通话正常。被叫由于EC/IO差掉话。

问题分析

从被叫检测出来的邻区中，被叫占用民航老干部处时RSCP-72dBm左右，而邻区中检测到附近基站信号大部分相差不大，强导频污染导致EC/IO-20db以下，不能满足通话要求，最终被叫掉话。

处理结果

海天大厦1小区方位减小，民航老干部处1小区方位增大或俯仰角下压，油脂科研所3小区方位调整或方位调整。调整后测试，无掉话发生。

9.测试软件设置问题导致接入失败

问题描述

当测试车辆由西向东行驶至如图所示位置时，UE一直占用华清村_3扇区信号，RSCP为-88dBm左右，Ec/Io为-9dB左右，发生一次接入失败。

问题分析

当测试车辆行驶至如图所示位置时，从信令可以看出，主叫手机发起RRC Connection

Request到RAB Setup Completed再到主叫手机收到Alerting，但是随后立即发出了Disconnect命令，由于UE的呼叫建立时间超过15秒，软件设置的连接时限为15秒，软件误统计接入失败。

10.被叫手机位置更新导致接入失败

问题描述

当测试车辆由西向东行驶至如图所示位置时，UE一直占用蔬菜公司_2、3扇区、外贸宾馆_2信号，RSCP为-77dBm左右，Ec/Io为-8dB左右，发生一次接入失败。

问题分析

当测试车辆行驶至如图所示位置时，从信令可以看出，主叫手机发起寻呼时，被叫手机正在进行位置更新，所以主叫手机无法寻呼到被叫，导致一次接入失败。