搜索
内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播西安联通WCDMA网一期工程优化案例内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播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/Io内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播2.越区覆盖导致掉话问题描述调整前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_difference.off与老信号差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-1612：59：02测量报告内容为：报1a加PSC126，当前激活集里面的PSC461帧偏2（如图2所示），但PSC126帧偏203（如图3所示）.内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播图2PSC461帧偏2图3PSC126帧偏203我们之前看到的多小区站点出现软切失败都是激活集里先加后减（测量报告中各小区帧偏都一样），先报1a，然后1b删去不好的那条腿，之后就报无线链路增加失败。其原因就是。综上所述，多小区站点软切失败时上面两种原因可能同时存在，当然也有相当数量的多小区站点软切失败是仅由激活集原因造成的。解决多小区站点软切失败的方法内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播根据上面的分析，要解决多小区站点软切失败问题首先要改小区扰码。网优同事修改扰码情况如表1。表1扰码修改情况小区ID修改前扰码修改后扰码10801126390108021343981080314240610805461435修改扰码后，从2009-07-25从关联日志中测量报告看到报1c，用390替换406，从图4和图5中可以看到新腿和老腿的帧偏只相差1。图4PSC390帧偏为7这种问题多为扰码规划不合理造成同扰码干扰，修改扰码后可解决切换失败。4.路由器设置不当导致下行速率慢问题描述西安联通外场HSDPA单线程下载测试，在无线质量较好前提下，定点HSDPA单线程下载速率平均3Mbps左右且速率波动非常大。在RNC侧对单个UE灌包测试，速率平均5.5m比较平稳，说明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设置一条主用路由，一条备用路由。西安联通这边由于RNC较多，组网更为复杂，所以未采用这个方式，而采用了下面的方法2.方法2：开启RNC对下行TCP包进行排序功能，在RNC对乱序进行纠正。RNC对下行TCP包进行排序，需要核心网发给RNC的Rab指派中带下来DeliverOrder参数为保序。.RAB_AssignmentRequestMsg.rAB_SetupOrModifyList.elem[0].rAB_SetupOrModifyItemFirst.rAB_Parameters.deliveryOrder=TRANAP_delivery_order_requested如果为保序，RNC就可以对乱序进行纠正，纠正需要设置以下RNC参数：IuDlInSeqDlvTmrBYTEIU下行数据排序定时器(IUDownlinkinSequenceDelivery0~60ms,step:2ms0表示无需排序（In0：无需排序(InSequenceDeliveryisnot6:为建议排序时长（SuggestedB(B83_BRNC)内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播Timer)SequenceDeliveryisnotRequired）Required)Value）解决效果西安联通打开RNC的下行排序功能（配置为10ms），定点单线程最大下载速率可以达到6.4m，平均速率到5m，改进比较明显。从UE侧抓包看修改后没有再出现乱序。5.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和交换机之间上行有丢包。解决方法CN同事最后定位出SGSN接口板的光模块有问题存在丢包。解决效果更换光模块之后，在现场测试多次，未出现ping包不通，上行无速率的问题。上载测试也均匀高速。内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播6.天馈参数设置不合理导致覆盖差问题描述如图所示，当测试车辆由东向西的行驶过程中，UE占用灞桥三厂招待所，西安东纺三路，辅仁医院，节约坊等基站信号，且该区域存在RSCP-106dBm左右，Ec/No在18dB左右和一些地方由于导频污染造成Ec/No恶化，分析此区域为明显RSCP、Ec/Io弱覆盖、导频污染问题。处理过程该区域属于一个相对较为独立的小社区，由于楼宇密集，地形起伏，加上基站数量内部公开▲本文中的所有信息均为中兴通讯股份有限公司内部信息，不得向外传播有限造成多个路段的覆盖较差，所以通过对该区域的所有基站的天馈参数进行重新规划，集中调整，争取从整体上提升覆盖效果。处理结果经调整灞桥三厂招待所_1、2、3小区，1小区电子下倾角由2度调为0度，2小区电