WCDMA网络优化会战案例汇编.doc

WCDMA网络优化会战案例汇编目录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-16 12：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上看下行数据报RLC SN连续，不存在乱序，排除Iub口引入乱序的可能。而Iu-PS在RNC-SGSN-GGSN-PDN均采用IP传输，很有可能存在乱序。从图中可以看到SGSN1通过2个 XKCE1 到我们的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设置一条主用路由，一条备用路由。方法2：开启RNC对下行TCP包进行排序功能，在RNC对乱序进行纠正。由于RNC较多，组网更为复杂，所以未采方法1，而采用方法2。RNC对下行TCP包进行排序，需要核心网发给RNC的Rab指派中带下来Deliver Order参数为保序。.RAB_AssignmentRequestMsg.rAB_SetupOrModifyList.elem0.rAB_SetupOrModifyItemFirst.rAB_Parameters.deliveryOrder = TRANAP_delivery_order_requested如果为保序，RNC就可以对乱序进行纠正，纠正需要设置以下RNC参数：IuDlInSeqDlvTmrBYTEIU下行数据排序定时器(IU Downlink in Sequence Delivery Timer)060ms, step: 2ms0表示无需排序（In Sequence Delivery is not Required）0：无需排序 (In Sequence Delivery is not Required)6:为建议排序时长（Suggested Value）B(B83_BRNC)打开RNC的下行排序功能（配置为10ms），定点单线程最大下载速率可以达到6.4Mbps，平均速率到5Mbps，改进比较明显。从UE侧抓包看修改后没有再出现乱序。4、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 BRNC 汇聚交换机 SGSN交换机GGSNPDNGGSN交换机SGSN汇聚交换机RNCNode BUE，在手机侧抓取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, 50020.1720.1739983998(500, 80014.434.5728576855(800, 10009.1143.6818088663(1000, 12007.5451.22149510158(1200, 200018.7669.98372213880(2000, 300016.1286.1319817078(3000, +INF)13.9100275819836【问题分析】通过对路测数据的分析，发现无线环境未发生大的变化。配合后台参数检查，发现码道数配置正常，功率相关的参数也没有发生改动。通过仔细比对以前的测试数据，发现同样是对渭南市区进行的测试 ，成功的短呼次数分别是42次和37次，但成功的软切换次数却相差了1878次，由此初步断定应该是切换的问题。升级后的KPI指标统计：KPITypeSuccTimesTotalTimesRate(%)RRC Connect Success Rate424593.33Soft HandOver Success Rate28372837100Call Access Success Rate424593.33Call Setup Success Rate000CS Call Drop Rate000PDP Activate Success Rate4242100PS Setup Success Rate4545100PS Drop Rate000表3 升级前的KPI指标统计KPITypeSuccTimesTotalTimesRate(%)RRC Connect Success Rate3737100Soft HandOver Success Rate959959100CS Call Setup Success Rate000CS Call Drop Rate000PDP Activate Success Rate3333100PS Drop Rate0370Location Update Success Rate33100于是在后台对相关的切换参数进行了修改，分别是：全网小区PS业务1D事件判决迟滞和全网HSPA 1D事件惩罚时间。全网小区PS业务1D事件判决迟滞指示了在判断事件是否满足事件触发条件的迟滞。该参数与测量和事件类型相关。使用此参数就可以使得触发某事件的状态和离开该事件的触发状态中间有一个差值，避免有一点小变化都会引起触发状态的改变。Hysteresis越大，表明触发事件的门限与离开该事件的门限差值越大。全网HSPA 1D事件惩罚时间指示了HSPA服务小区改变或HSDCH信道迁移的所必需的最小时间间隔，以避免频繁的HSPA服务小区改变和信道迁移。【问题处理】将1D事件的参数 HYSTERESIS 从2db改为4db。将Timer for Event 1D in HSPA or MBMS参数从2s改为0s 。 HSDPA吞吐量路测图：HSDPA吞吐量表格图：CategoryPercent(%)Cum_Percent(%)NumberCum_Number(-INF, 100018.8718.8722632263(1000, 12002.0420.912452508(1200, 200010.8631.7713023810(2000, 22003.6235.394344244(2200, 300018.9354.3222706514(3000, +INF)45.68100547611990参数修改后的KPI指标统计：KPITypeSuccTimesTotalTimesRate(%)RRC Connect Success Rate5151100Soft HandOver Success RatS Call Setup Success Rate000CS Call Drop Rate000PDP Activate Success Rate33100PS Drop Rate0500Location Update Success Rate44100在参数修改后的路测中，发现在成功的51次短呼情况下，软切换次数也有明显下降，只有1430次，同时全网的下载速率也恢复到正常水平。通过这个案例可以得到如下结论：HSDPA下行吞吐量除了与新增的AMC，HARQ以及快速分组调度算法等技术有直接关系外，还与HSDPA的切换性能有直接的关系，总的来讲，HSDPA的切换越少越好，切换时延越小越好。HSDSCH服务小区的更新会降低下行吞吐量，其主要原因有以下两点：主服务小区的Ec/Io逐渐变差导致CQI变差，会降低下行吞吐量。HS-DSCH服务小区在更新时，在下行链路会有几百毫秒的中断时长：HS-DSCH新的小区会有几百毫秒的无线配置时间所产生的通信中断，以及UE本身的切换时长所产生的通信中断。以上这些通信中断会降低下行吞吐量。6、室分接入困难【问题描述】部分用户投诉在办公楼内拨打3G电话困难，呼叫应答的时间较长，用户的感知明显下降。【问题分析】通过前台测试，发现办公楼内的室分信号强度较强，也没有告警出现，就排除了硬件故障。观察后台界面，发现有大量的虚警接入拒绝，挤占了解调资源，导致接入困难。我们知道，终端在随机接入消息发送前，先发送随机接入前导消息。第一个前导的发射功率，公式为：Preamble_Initial_Power = Primary CPICH DL TX power CPICH_RSCP + UL interference + Constant Value 从上式可看出Primary CPICH DL TX power CPICH_RSCP即为下行路损，在功率控制算法中不能直接使用下行的路损来估算上行的初始发射功率，开环功控的算法还需要考虑上行的干扰、上下行频率偏差、上下行由于接收机灵敏度不同导致的SIR要求不一致等因素。根据AICH的应答更新Preamble_Initial_Power。如果AICH无应答，则以功率增加步长增加前导发射功率；若接收到正的AICH应答，则开始发送随机接入消息。在开环功控过程中，PRACH信道参数有着重要的意义，这些参数分别是：检测前导门限(Preamble Threshold)参数描述：Preamble Threshold设置了Node B检测到前导的判决门限。PRACH发射的前导被Node B检测到的前提是：在前导周期内前导的接收功率与干扰水平的比值要超过此门限。参数值设置太大会造成容量损失和干扰增大；太小则有可能造成前导检测不到。取值范围： (-36.00.0)dB。缺省值：-19.5dBPRACH初始发射功率修正值(Constant Value)参数描述：UE计算PRACH的前导初始发射功率时用到的修正值。它是一个与小区环境相关的量，且此值与PRACH所承载的业务速率和品质因素相关，UE从系统广播消息中获取。取值范围： (-35.-10)dB。缺省值：-20dB调整方法： Constant Value反映的是PRACH的初始前导的初始发射功率是否在比较合适的范围最大上行发射功率(Maximum allowed UL TX power)参数描述：为PRACH使用的最大上行发射功率，是针对每条PRACH物理信道的。此值的作用是限制上行PRACH的发射功率，如果设置太大，可能造成瞬间干扰导致其它用户掉话；否则可能会造成上行接入失败。取值范围：(-50.33) dBm.缺省值：33dBmPreamble Threshold的大小直接影响PRACH的消息部分是否能被Node B正确接收。通过后台信令跟踪，发现在RNC侧没有收到RRC CONNECTION REQUEST消息，而从Node B的BMC TRACE上看到RACH CRC ERROR全错。说明该门限值设置的太低，使得消息部分的发射功率非常低，Node B不能正确接收；此时则可以尝试把Preamble Threshold适当调大。将检测前导门限从-24d改为-21d,PRACH初始发射功率修正值从-21dB改为-18dB，经过测试，故障消除。呼叫120次，全部成功。【问题处理】修改前的界面如下修改后的界面如下7、2G到3G重选不成功（一）【问题描述】在3G覆盖区域，手机在自由模式不能顺利重选至3G网络【问题分析】1、在3G覆盖区域内，将手机从2G手动选到自由模式，观察其信令的变化，手机一直不能发送Page_Requst消息，一直未出现LOCATING_UPDATING REQUST消息。2、根据信令分析和时钟同步测试，发现基站时钟和时钟源交换时钟不同步。【问题处理】从时钟源提取时钟，进行全网修改，经过复测发现可以重选：8、2G到3G重选不成功（二）【问题描述】如下图手机空闲状态刚开始占用2G信号从09：15：52开始，以后手机发起的都是2G系统消息，没有位置更新请求。 从下图看到手机到09：19：20从2G向3G发起位置更新请求完成消息，从2G到这个状态大约用了4分多钟。重选时间比较长说明重选不成功。 【问题分析】一般出现这种原因是2G基站漏加了3G的邻区，或者2G基站的重选接入门限比较高不容易让3G信号接入进来。【问题处理】检查玻璃厂周围2G基站是否增加玻璃厂3G的邻区，发现啤酒厂2G基站没有增加玻璃厂3G邻区，增加邻区后测试情况如下：下图是手机空闲状态刚开始占用2G信号从02：11：42开始，从这后手机发起的都是2G系统消息没有位置更新请求。下图所示手机到02：12：33开始从2G向3G发起位置更新请求Location updating Request，这个时候手机还在2G状态下。从