陕西联通WCDMA网络优化会战案例汇编

陕西联通WCDMA网络优化会战案例汇编陕西联通网优中心2009年10月目录1、天馈参数不合理导致掉话.........................................................................................................32、扰码复用不合理导致切换失败.................................................................................................53、路由器设置不当导致下行速率慢.............................................................................................84、SGSN接口板的光模块故障导致上行速率慢........................................................................115、切换参数设置不当对HSDPA下载速率影响........................................................................126、室分接入困难...........................................................................................................................157、2G到3G重选不成功（一）..................................................................................................178、2G到3G重选不成功（二）..................................................................................................189、3G-2G切换失败（一）...........................................................................................................2110、3G-2G切换失败（二）.........................................................................................................231、天馈参数不合理导致掉话【问题描述】如图所示，当车辆行驶至如图所示位置时，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、扰码复用不合理导致切换失败【问题描述】发现多小区（超过3个小区）站点更软切失败是由扰码复用造成的，新加信号的SFN_Frame_difference.off与老信号差2以上。【问题分析】经研究，发现多为同扰码小区的越区干扰，造成切换失败。分析软切失败原因RNC3074下NodeBID180，10801质检大厦_1（PSC126），10802质检大厦_2（PSC134），10803质检大厦_3（PSC142），10805万嘉商务酒店（科技路）（PSC461），10806萨菲尔。从关联日志中可以看到当前小区为10805（PSC461），试图更软切10801（PSC126），如下图（试图加10801）所示。2009-07-1612：59：02测量报告内容为：报1a加PSC126，当前激活集里面的PSC461帧偏2，如下图所示。但PSC126帧偏203，如下图所示。我们之前看到的多小区站点出现软切失败都是激活集里先加后减（测量报告中各小区帧偏都一样），先报1a，然后1b删去不好的那条信号，之后就报无线链路增加失败。如上，多小区站点软切失败时是由扰码复用原因造成的，当然也有相当数量的多小区站点软切失败是仅由激活集原因造成的。【问题处理】解决多小区站点软切失败的方法根据上面的分析，要解决多小区站点软切失败问题首先要改小区扰码。修改扰码情况如下表。小区ID修改前扰码修改后扰码10801126390108021343981080314240610805461435修改扰码后，从2009-07-25从关联日志中测量报告看到报1c，用390替换406，从下图中可以看到新信号和老信号的帧偏只相差1。3、路由器设置不当导致下行速率慢【问题描述】外场HSDPA单线程下载测试，在无线质量较好前提下，定点HSDPA单线程下载速率平均3Mbps左右且速率波动非常大。在RNC侧对单个UE灌包测试，速率平均5.5Mbps比较平稳，说明Iub口和空口没有问题。【问题分析】从UElog来看，在CQI较好的时候，UE收到下行数据量不足。上图红框中数据为TSN标识，标识连续表明下行数据未有丢包。从UE侧抓包看，存在大量TCP包乱序，在乱序后马上会启动快速重传，对DPA的下载速率有很大影响。从UElog上看下行数据报RLCSN连续，不存在乱序，排除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，里面承载的applicationIP报文（PDN）是A,C,B，说明PDN-GGSN乱了。收到GTPU内部IP编号1，3，2，里面承载的applicationIP报文（PDN）是A,C,B。说明GGSN-SGSN-RNC乱了。在GUIM上现场抓取报文，分析如下：当TCP乱序发生时，先收到GTPU外层承载IP报文IPID为0为0xe4ac，对应承载原始报文IPID0X4905。再收到GTPUP外层承载报文IPID为0xe4ab,对应承载原始报文IPID0X4904从而在GGSN-RNC之间引入乱序。【问题处理】方法1：给每个RNC设置一条主用路由，一条备用路由。方法2：开启RNC对下行TCP包进行排序功能，在RNC对乱序进行纠正。由于RNC较多，组网更为复杂，所以未采方法1，而采用方法2。RNC对下行TCP包进行排序，需要核心网发给RNC的Rab指派中带下来DeliverOrder参数为保序。.RAB_AssignmentRequestMsg.rAB_SetupOrModifyList.elem[0].rAB_SetupOrModifyItemFirst.rAB_Parameters.deliveryOrder=TRANAP_delivery_order_requested如果为保序，RNC就可以对乱序进行纠正，纠正需要设置以下RNC参数：IuDlInSeqDlvTmrBYTEIU下行数据排序定时器(IUDownlinkinSequenceDeliveryTimer)0~60ms,step:2ms0表示无需排序（InSequenceDeliveryisnotRequired）0：无需排序(InSequenceDeliveryisnotRequired)6:为建议排序时长（SuggestedValue）B(B83_BRNC)打开RNC的下行排序功能（配置为10ms），定点单线程最大下载速率可以达到6.4Mbps，平均速率到5Mbps，改进比较明显。从UE侧抓包看修改后没有再出现乱序。4、SGSN接口板的光模块故障导致上行速率慢【问题描述】8月19日起接到大量的用户投诉说UPA上传没有速率，邮件发送失败。在现场进行复现，发现对于DCH或是e-DCH有时拨号上去后速率一直为0，然后userinactivity，持续很久速率也不能恢复，有的时候拨号后UPA和DCH上传速率完全正常。一段时间内反复重复呼叫，总能抓到上行速率为0的情况。上行速率为0的时候，pingPDN服务器大量丢包，但此时HSDPA和DCH下载速率均很正常，从UE采用iperf向PDNUDP灌包速率也正常。【问题分析】刚开始怀疑可能在RUB的某个DSP上有问题，经过试验，发现建立在同一块RUB板的同一个DSP上有正常的情况，也有不正常的情况，排除某个DSP故障导致。在UE侧使用wireshark进行抓包，发现发到PDN服务器的包，有丢包，很多包UE发送了很多次，PDN服务器却一直没有收到，让UE不断进行重传，导致TCP窗口一直不能正常向前推进，最后TCP窗口完全关闭。整个数据的流向是：UE—NodeB—RNC—汇聚交换机—SGSN—交换机—GGSN—PDN—GGSN—交换机—SGSN—汇聚交换机—RNC—NodeB—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和交换机之间上行有丢包。最后定位出SGSN接口板的光模块有问题存在丢包。【问题处理】更换光模块之后，在现场测试多次，未出现ping包不通，上行无速率的问题。上载测试也均匀高速。5、切换参数设置不当对HSDPA下载速率影响【问题描述】渭南的WCDMA网在RNC版本升级后的测试中，发现HSDPA的下载速率下降明显，平均速率只有1.2Mbps左右，对用户的感知带来较大影响。下图就是市区PS域测试的结果。HSDPA吞吐量路测图：HSDPA吞吐量表格：CategoryPercent(%)Cum_Percent(%)NumberCum_Number(-INF,500]20.1720.1739983998(500,800]14.434.5728576855(800,1000]9.1143.6818088663(1000,1200]7.5451.22149510158(1200,2000]18.7669.98372213880(2000,3000]16.1286.1319817078(3000,+INF)13.9100275819836【问题分析】通过对路测数据的分析，发现无线环境未发生大的变化。配合后台参数检查，发现