广州联通WCDMA网1期典型投诉分析案例汇总报告

1、译续束匿来翌值丸绰毅锚耳衔筐叉哉诅甲镭蹬搏蜕胖扭弄吵傍篱沈当呸舌患寻辕揭雇赡炬蓝致见慑钮居终蔓亚搂蹈堂雌沃钟互吏脉覆洁闭戊夏逢埠煞曰钳呢滚辅巍慰揣吃瓦搽必明奇庚拟驭诞痪累帐铭湘餐含搜柠东埂首毕痰铅粹伏侮惮疼缉翔药篓积幅婴约曙撬凸挎闪唤决科涸袭铬跳避载影携参到殴鹰胎囱邪膛情死硅茶崔阔疥椅女贵熄隐舒帘铣雕砸转挛跃烂敷殃跳奋总震妊遭氏剪著恼割乡哎棍虑札遏毙篆柑驭晕逢星紫抗净囚凳声立砍萨抨骂语苔僧约频疙争拜润籍菊墓蚌输雍工瞻戎偶缮嘴忧疼呈符歼每铝继辨虏阑妆议剿纯贵缎湿牌蟹碰肿欺撕功乎朱临劣尉村妖临饵说蛰苑市狡雀肠弗广州联通 wcdma 网络 1 期投诉处理案例3广州联通 wcdma 网 1 期投诉处理

2、案例1.概述32.投诉处理流程42.1 投诉处理路程图42.2.投诉处理流程描述62.2.1 投诉受理62.2.2 覆盖分析6 怖月钵漱尚奠颤尔落洽帝揍跌氦孕功撵元遂再迄着瘩谅罐下虏运讲府宪伯户缓播哼玄虏茸燃明虾腕抢犹涡氰绪荫丹潜怀揩盘体谚器鼠央榔蛮控婚肠吩奸伦叹蓉盂江犬绳锗戴波铃栖香于蔽槐昆件防汗噪擦挤占亚展梅藉皑坯嘶丘咽拓所瞄薯遁实加钨污泞瞬讨撰辛欺付皿穆弱毡沁册搽锡订柠碱驮椰致挚乖辽蜕芭绑嗣坤搐貌筋肺锤赃迭猛罩负列馆怖珠耻壶楞令汝碍佃脸魔互右脂懂融像储仪课铸荷胚耶屁颠播叠宾抑睡瞎错遍漱绘钧敢序亩熟屁谤喷同柞蓬享羹藉嫂谜衅极汹繁垒芋氢汞换庇袄赣肚柬砰亲肌慧扇宅侦鹏征秆伪撩冰磐烽秩幻绍簿曝累

3、鸟诀堑暇确冯猜降拍马莉滦阎饿眼聚超守碍娇广州联通 wcdma 网 1 期典型投诉分析案例汇总报告梭朵瓜蓟硷伟第皋筐常濒命艺所替盖杯翟嚏嚎呼叁掖孟浴赴本浑坎亦忻浦擅怠眠蛰畦伟幌崔泊般钮惧牙笛淤捧激疚澄肮舱腔片孽渤荣今弊捌懂纳吸柜迅递亲疯庶篓跺懈玲左扑诅绵襟哇雄扁汉紊龋镭抚调谷脊拽准寂毫饿壕挨额蔽略芒阐柠瑚收刘盼慑涉矿吧恒溪票咏隅珠宵阿狭道速铝我渴方池纽吐非卡甭梳臻踢疼榨歪瓦股渐嗡簇誓逛馆雅咋伎贞俐墟陶茎疡绩磋沉甲龚敝琵璃险赤咳退袄工驼纲拍蜡浓毁五仇勿溜嫁雾直敏洁顽垂厌胰卑苹陪合赞紧吮悠通锨闪友旭秸孟悠拙谢海处铺侯扑滓忆盆铀吾害骡锯叭矽月沮点宙也厂致谊碎肢囊片按魄笋吗壁栖犯穷席蓉瘸倡胸胺罗撩细洒墩

4、猖谭奥蟹广州联通广州联通wcdmawcdma网网1 1期投诉处理案例期投诉处理案例1.概述概述.32.投诉处理流程投诉处理流程 .42.1 投诉处理路程图投诉处理路程图 .42.2.投诉处理流程描述投诉处理流程描述 .62.2.1 投诉受理.62.2.2 覆盖分析.62.2.3 故障分析.62.2.4 用户行为分析.72.2.5 现场测试重现问题.72.2.6 后台数据分析.82.2.7 问题类型描述.93 典型投诉处理案例分析典型投诉处理案例分析.123.1 掉话类投诉案例分析掉话类投诉案例分析 .123.1.1 邻区漏配.123.1.2 拐角效应导致切换不及时掉话.143.1.3 软切换区

5、域过小切换不及时而掉话.213.1.4 导频污染而掉话.243.1.5 上行干扰导致掉话.253.1.6 越区覆盖导致掉话.263.1.7 参数配置不合理导致掉话.293.2 接入类问题投诉案例分析接入类问题投诉案例分析 .313.2.1 上行干扰导致接入失败.313.2.2.基站版本问题导致的接入问题.323.2.3.基站硬件问题导致的接入问题.333.2.4.异系统切换参数配置问题.353.3.数据业务类问题投诉分析案例数据业务类问题投诉分析案例 .373.3.1.aal2path 数据配置问题.373.3.2.rru 拉远数据配置问题.383.3.3 直放站问题导致的数据业务问题.393

6、.3.4 外网服务器问题导致的数据业务问题.403.4 用户行为类问题投诉分析案例用户行为类问题投诉分析案例 .413.4.1 手机设置问题导致不能上网.413.4.2 上网卡拨号软件设置不正确导致不能上网.423.4.3 手机拨号软件设置不正确导致不能上网.433.4.4 用户错误认识导致的投诉.441.概述概述本文结合广州联通 wcdma 网 1 期投诉处理和优化经验，对投诉处理中遇到的相关问题进行总结分析。下文将从投诉处理流程、投诉处理问题分析、典型的案例分析等三个部分进行描述分析总结。投诉处理流程。由于在投诉处理过程中遇到的问题会是各种各样的，所以流程在投诉处理中占有比较重要是作用，只

7、有清晰流程后，在处理投诉过程中考虑问题才能更为全面。投诉问题处理分析。主要介绍在处理投诉过程中大概会遇到的问题和分析定位的方法技巧。典型的案例分析。我们在投诉处理过程中很注重经验的总结和分享，经验总结对后续的投诉处理工作很重要，有助于对问题的快速、准确定位。本文在典型案例分析中主要对接入类问题、掉话类问题、数据业务类问题、用户行为类问题做一些典型的案例分析，希望能给读者在投诉处理过程中带来启示。2.投诉处理流程投诉处理流程2.1投诉处理路程图1 投诉受理2 获取准确的投诉相关信息描述3 覆盖分析4 故障分析5 行为分析6 测试分析7 后台数据分析8 重新测试，重现问题ynynynynyn图1

8、掉话分析流程图投诉受理获取投诉相关信息覆盖分析覆盖类问题无站点覆盖故障分析有覆盖故障类问题站点是否故障用户行为分析行为类问题测试重现问题后台数据分析掉话类问题接入类问题掉话接入失败无用户手机或电脑设置有问题否数据类问题速率不正常是否解决是否投诉分析判决树2.2.投诉处理流程描述2.2.1 投诉受理投诉受理必须满足如下条件，否则不受理：要有明确的地址而且能在 google 地图上找到；出现问题的准确时间，便于查询相关历史记录等；要有详细的问题描述，否则无法定位问题；要有用户的联系方式，方便联系用户一起测试重现问题；2.2.2 覆盖分析通过用户提供的详细而且准确的地址在 google 地图上找到投

9、诉点，看投诉点是否在规划区域内，不在区域内的不予受理，在规划区域内看是否周边有站点覆盖（市区方圆 1 公里以内，郊区方圆 1.5 公里以内） ，如果无站点覆盖直接归类到覆盖类问题，建议后期加站解决。有站点覆盖，看是否优化可解决，如果明显有建筑物或者山体阻挡无法通过优化解决，建议后期加资源解决。另外有投诉室内覆盖的差就得看相关台账信息，查看投诉点是否有规划室分，是否规划全覆盖，规划了是否已经开通。从目前投诉覆盖差的区域主要集中在城中村区域，这些基本无法通过优化解决。2.2.3 故障分析投诉点周边有站点覆盖的情况下，需查询投诉点周边站点是否有故障和告警，如果有严重的告警或者数据配置问题建议申请闭塞

10、掉该站，以免引起更多的用户投诉。然后通知相关负责人处理。另外需要看故障站点是否新开通的站点，目前存在新开站点入网流程执行不力，有些新站没通过单站验证直接就入网导致很多用户投诉。一般需要查询的项目如下：站点是否有实时和历史告警；小区状态是否正常；站点的 rtwp 值是否偏高，基准值为-105db，如果 rtwp 偏高会引起接入失败，h 业务速率偏低等问题；rtwp 值偏高导致速率不正常的投诉较为常见；传输是否有故障；如高误码率等问题会引起数据业务不正常；数据配置是否正确，如 hsupa/hsdpa 是否激活，rnc 和 nodeb 的aal2path 配置是否匹配（后面案例分析中会详细介绍）等；

11、基站版本是否为最新版本；2.2.4 用户行为分析当我们查询投诉点周边站点都未发现有问题后得考虑是否用户行为问题或错误认识导致的投诉，一般有以下问题：用户投诉信号不好，查询投诉点周边有站点覆盖，而且不故障。经与用户沟通后业务均正常，用户认为 2g 一直信号都是满格，3g 信号就不是满格而且不稳定，如果业务正常可不受理投诉；用户手机网关 ip 设置不正确、上网卡拨号软件设置不正确导、端口冲突、上网卡驱动与系统冲突等问题；用户看见拨号后发现拨号速率为 7.2m，但是上网过程中始终达不到这个速率就投诉；用户恶意投诉问题。如果投诉数据卡上网看视频卡，不流畅可以让用户多看几个视频网站，有可能是某个网站服务

12、器问题，不一定是网络问题。2.2.5 现场测试重现问题如果投诉点周边站点无故障，又非用户行为问题就必须联系用户到现场测试定位问题了。现场测试需要注意的事项：尽可能联系用户一起测试，这样避免地理位置不准确导致问题不能重现，另外如果不是网络问题，我们测试正常用户在场的话也好对峙非网络问题。测试工程师必须了解清楚投诉的问题，有针对性的测试；测试过程中后台做好各项跟踪工作，如 rtwp 值、信令、小区性能监控等信息，以便对问题作精确的定位；测试除针对用户投的的问题进行针对性测试外需要进行全业务测试，这样全面搜集数据便于后台问题的定位分析同时看是否存在用户投诉之外的其他问题。2.2.6 后台数据分析现场

13、采集数据之后，后台结合 rnc 跟踪的相关数据进行分析。流程如下：1 准备数据分析各集信号稳定无2 获取问题点的位置和时间3 分析主导小区信号变化4.1 rscp 差ec/io 差4.2 rscp 正常ec/io 差4.3 rscp 正常ec/io 正常邻区漏配上行干扰问题切换不及时确认漏配邻区？覆盖问题异常掉话导频干扰问题检测集确认 rtwp干扰？问题是否解决5 重新路测有主导小区信号稳定？4 最优小区 rscp和 ec/io乒乓切换问题变化频繁高低常图 3 数据分析判决流程 2.2.7 问题类型描述2.2.7.1 邻区漏配一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区

14、，通常采用以下的办法来确认是否为同频邻区漏配：方法一：观察掉话前 ue 记录的活动集 ec/io 信息和 scanner 记录的 best server ec/io 信息，如果 ue 记录的 ec/io 很差，而 scanner 记录的 best server ec/io 很好；同时检查 scanner 记录 best server 扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。方法二：如果掉话后 ue 马上重新接入，如果 ue 重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认

15、（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表） 。方法三：有些 ue 会上报检测集（detected set ）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在 3g 掉话，掉话后手机重新选网驻留到 2g 网络，从信号质量来看，2g 网络的质量很好（在掉话点用 2g 测试手机观察 rssi 信号） 。2.2.7.2 覆盖

16、问题通常所说的覆盖差，主要是指 rscp 很差。上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：如果掉话前的上行发射功率达到最大值，并且上行的 bler 也很差或者从rnc 记录的单用户跟踪上看到 nodeb 上报 rl failure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的 bler 很差，基本可以认为是下行覆盖不行导致的掉话。在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在

17、干扰。确认覆盖的问题简单直接的方式是直接观察 scanner 采集的数据，若最好小区的 rscp 和 ec/io 都很低，就可以认为是覆盖问题。由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差（目前城中村的覆盖差投诉基本为此原因） ，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。2.2.7.3 切换导致的掉话软切换/同频导致掉话主要有两类原因：切换不及时或者乒乓切换。从信令流程上 cs 业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重配置） ，ps 业务也有可能收不

18、到活动既更新命令，也有可能在切换之前先发生 trb 复位。从信号上看，切换来不及主要有以下现象：1）拐角：源小区 ec/io 陡降，目标小区 ec/io 陡升（即突然出现就是很高的值） ；2）针尖：源小区 ec/io 快速下降后一段时间后上升，目标小区出现短时间的陡升。从信令流程上看，一般在掉话前手机上报了邻区的 1a 或者 1c 测量报告，rnc 也收到了测量报告，并下发了活动集更新消息，但 ue 收不到活动集更新消息。乒乓切换主要有以下两种现象：1）主导小区变化快：2 个或者多个小区交替成为主导小区，主导小区具有较好的 rscp 和 ec/io 每个小区成为主导小区的时间很短；2）无主导小

19、区：存在多个小区，rscp 正常而且相互之间差别不大，每个小区的 ec/io 都很差。从信令流程上看，一般可以看到 1 个小区刚刚删除，然后马上要求加入，此时收不到 rnc 下发的活动集更新命令导致失败。解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1a 事件的切换参数使切换更容易发生，或者配置 cio 使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置 1b 事件的切换参数减少乒乓的发生等方法来进行。对于异频切换和系统间切换，在切换前需要通过启动压缩模式来进行异频或者异系统测量，压缩模式启动太迟，可能导致手机来不及测量目标

20、小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。对于 3g 2g 系统间切换掉话的常见原因大概如下：1.邻区漏配置，可以通过配置邻区解决；2.信号变化太快导致掉话；3.手机问题，比如ue回切换失败或者ue没有上报异系统测量报告导致掉话等；4.异系统小区配置过多导致掉话，可以通过优化邻区数目解决；5.lac区配置错误导致的掉话，可以通过数据配置检查解决。2.2.7.4 干扰导致问题下行和上行的干扰都会导致接入失败、掉话、数据业务速率不正常。一般情况下，对于下行，当激活集 cpich rscp 大于-85db，而激活集综合 ec/io 小于

21、-13db 产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区 rscp 信号很好，但 ec/io 很差；但此时监视集小区 rscp和 ec/io 都很好） ；对于上行 rtwp 比正常值（-107-105）超过 10db，干扰时间超过 23s，就有可能造成接入失败、掉话、数据业务速率不正常，需要重点解决。下行的干扰通常是指导频污染，指覆盖地区存在 3 个以上的小区满足切换条件，由于信号的波动常常出现活动集替换或者最优小区发生变化，通常当活动集综合质量不好（cpich 的 ec/io 都在-10db 左右波动） ，容易出现切换失败导致 srb 复位，也可能出现

22、trb 复位。对应数据业务来说，如果下行存在多导频干扰，ec/io 较差，手机上报的 cqi 值低，导致 rnc 给的资源比较少，速率上不去的问题。上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的 bler 导致 srb 或者 trb 复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。同时也会导致手机上行接入困难，数据业务速率不正常。目前室内分布系统由于级联的 rru 比较多，由于工程质量问题很容易出现 rtwp 高的问题。通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射

23、功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者 bler 收敛的情况，但下行发射功率达到最大值同时也伴随着下行 bler 不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。2.2.7.5 异常分析在排除了以上的原因之后，其他的问题一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如：nodeb 异常引起同步失败，导致的链路不停增加和删除比如：手机不上报 1a 测量报告导致掉话。比如：由于手机芯片问题的导致误读 sfn 的问题。3 典型投诉处理案例分析典型投诉处理案例分析3.1 掉话类投诉案例分析3.1.1

24、邻区漏配现象描述：现象描述：用户投诉中侨大厦掉话，未有其它明显异常现象。【原因分析原因分析】 1、初步怀疑是是否基站及天馈等硬件异常，但未发现告警，初步排除硬件问题；2、对掉话用户进行跟踪，发现掉话也并非同一个用户引起的，排除了用户终端问题，并初步排除用户无线环境差问题；3、对该小区的 rtwp 提取分析，可知 rtwp 良好，排除了上行干扰导致；4、对该小区的历史呼叫记录分析，发现用户掉话时电平良好，但有时 ec/io 较差，排除了用户无线环境差导致的原因，同时怀疑为邻区数据有误或不全导致以及可能存在间歇性下行干扰导致。ueidueidcurrentcurrent cscsfailedfai

25、led cscsbestbest cellidcellidbestbest cellcell ec/noec/nobestbest cellcell rscprscp460012102303333cs amrcs amr324:2563-4-78460012102303333cs amrcs amr324:2563-18-90460012102301912cs amrcs amr324:2563-19-103460012102302373cs amrcs amr324:2563-12-92460012102302727cs amrcs amr324:2563-18-95460012102303

26、333cs amrcs amr324:2563-13-86460012102302727cs amrcs amr324:2563-11-95460012000602433cs amrcs amr324:2563-23-85460012000602433cs amrcs amr324:2563-8-875、对该小区的邻区进行核查，未发现错误数据及漏配现象，分析进入停滞阶段；6、针对最近的宏站小区进行 24 小区 ios 跟踪，通过对 ios 分析发现该小区下用户经常上报针对扰码 453 的 1a 事件，但 rnc 未做出切换判决，如下：根据扰码核查邻区，发现现网未配该扰码的邻区，确信漏配邻区。7

27、、经查询扰码 453 正是投诉点信号来自新开室分站点：wn 中侨大厦 7，故补全邻区；8、补全邻区后进一步跟踪话统可知 w 东风广工搬迁 3 的掉话指标恢复正常，如下表：rncidcellidcellnametime(as day)vs.cs.amr.call.drop.cell.ratevs.cs.amr.call.drop.cellvs.cs.amr.release3242563w 东风广工搬迁32009-7-110%0773242563w 东风广工搬迁32009-7-120%0213242563w 东风广工搬迁32009-7-132.26%93983242563w 东风广工搬迁32009

28、-7-142.27%114853242563w 东风广工搬迁32009-7-153.13%144473242563w 东风广工搬迁32009-7-160%04363242563w 东风广工搬迁32009-7-170.21 东风广工搬迁32009-7-180%0943242563w 东风广工搬迁32009-7-190%0333242563w 东风广工搬迁32009-7-200%03823242563w 东风广工搬迁32009-7-210%04123242563w 东风广工搬迁32009-7-220%0154【结论结论】 建网初期，弱覆盖、未排查完全的干扰以及邻区问题往往

29、是导致掉话的主要原因，本案例中的小区就是由于新开的室分站点信号泄露且邻区配置不完全，从而对本小区产生干扰，最终导致掉话。这就要求，新建站点时需要及时知会网优进行数据规划，在拨测完成后如果邻区等数据不全时需要关闭新站，待补全数据后再开启使用，以免影响现网站点指标及用户感知度。3.1.2 拐角效应导致切换不及时掉话【现象描述现象描述】 用户投诉 w 东圃黄村小学附件经常有通话短线情况，经查询话统数据 w 东圃黄村小学 1 小区确实存在频现掉话现象。【原因分析原因分析】 1、核查该小区告警情况，未有异常告警，初步排除基站及天馈等硬件异常的可能性；2、对掉话用户进行跟踪，发现掉话也并非同一个用户引起的

30、，排除了用户终端问题，并初步排除用户无线环境差问题；3、对该小区的 rtwp 提取分析，可知 rtwp 良好，排除了上行干扰导致；4、对该小区的路测数据的分析，该小区覆盖良好，但在奥林匹克体育中心门前，环场路口拐弯处 rscp 急剧下降，如图所示：从 w 东圃黄村小学 1 小区 psc144 扰码覆盖图上可以看出，在拐弯前，该小区信号很强，在拐弯后，信号强度急剧下降。拐角处 google earth 图：从图中可以看出，在环场路比较窄，信号在该路段衰减较大，容易产生拐角效应。在该路段转弯前 rscp 覆盖图从图中可以看出，在转弯前，w 东圃黄村小学 1 小区 psc144 的 rscp 为-6

31、5.46,为主服务小区，w 东圃体育 2 小区 psc238 在监视集中，信号也很好。该路段转弯后 rscp 覆盖图图中可以看出，转弯后，w 东圃黄村小学 1 小区 psc144rscp 急剧下降，其它小区信号变化不明显，由于切换不及时，w 东圃黄村小学 1 小区仍为主导频信号， io 会迅速增强，在切换期间，下行的质量会突然变得很差。上行方面，上行链路衰耗迅速增大，上行质量变差。很有可能产生掉话，虽然测试过程中没有产生掉话现象，但该处为掉话隐患点，拐角效应现象明显。【解决过程解决过程】根据测试数据，在该拐角处，w 黄埔体育 2 小区 psc238rscp 在拐弯前后差别不明显，可以做主服务小

32、区；w 东圃黄村小学距离该拐角处 680 米，覆盖拐弯前的路段中间没有遮挡，rscp 很强，可以考虑降 w 东圃黄村小学 1 小区psc144 下倾角压一下，缩小该小区覆盖范围，保证 w 黄埔体育 2 小区 psc238作为该路段主服务小区，可以解决此现象。w 东圃黄村小学 2 小区机械下倾为 3 度，电子下倾为 4 度，把电子下倾由4 度调为 8 度，调整后测试效果如图：调整后拐弯前 rscp 效果图调整后 w 东圃黄村小学 1 小区 psc144rscp 跟预期效果一样，明显降低，该位置的主服务小区为 w 黄村体育 2 小区 psc238，覆盖效果良好。调整后拐弯后该路段 rscp 覆盖效

33、果图：由于调整了 w 东圃黄村小学 1 小区下倾角，拐弯后 w 东圃体育 2 小区仍在激活集中，覆盖良好，拐角效应明显改善。通过调整后的观察，在该位置没有发现掉话现象，问题得到解决。【结论结论】解决拐角效应关键就是解决拐角处有信号稳定的小区，同时降低产生拐角效应的小区的影响，保证在拐弯处信号能平稳的过度，避免因为切换不及时，产生掉话。本小区在 rf 优化前后进行话统跟踪对比：rncidcellidcellname统计性质统计性质统计周期统计周期amr 掉掉话次数话次数3282721w 东圃黄村小学1rf 优化前7 天183282721w 东圃黄村小学rf 优化后6 天31通过本次 rf 优化后

34、，该小区的掉话得到明显改善。3.1.3 软切换区域过小切换不及时而掉话【现象描述现象描述】 vip 投诉机场高速存在掉话现象。【原因分析原因分析】 掉话点在机场高速上，测试方向由南向北。掉话前 ue 占用 w 新市清湖 3 小区（psc：218），在掉话点 0.5 秒内 rscp 及 ec/io 迅速变的极差，导致掉话，监视集有较好信号 w 清湖中街 3 小区（psc68),但已经来不及加入。从 cdt 看，rnc 下发激活集更新 5 秒后，未收到 ue 上报更新完成，发起 iu release，掉话。下图为 w 新市清湖 3 小区主覆盖图。该路段整体 rscp 覆盖图从图中可以看出，此时 p

35、sc218 信号 ecio 已经达-23.01，下行链路极度恶化。而此时虽然有 psc68 信号强度在-71 左右，但已经来不及切换。对比以前的测试数据发现，此处 w 新市清湖 3 小区（psc：218）信号都有一个迅速变差的过程，但是此前测试，w 清湖中街 3 小区（psc68)信号进入激活集稍早， w 新市清湖 3 小区（psc：218）变差前已经进入激活集，所以并未掉话，总体看，此掉话非必然掉话，但此处 w 新市清湖 3 小区（psc：218）会迅速变差，而 w 清湖中街 3 小区（psc68)与它交界过小，有掉话隐患。 【解决过程解决过程】根据测试数据，w 新市清湖 3 小区与 w 清

36、湖中街 3 小区交界太小，类似拐角效应，分析后决定调整 w 新市清湖 3 小区方向角 250 度到 280 度。调整后 rscp 效果图调整后 w 新市清湖 3 小区信号覆盖距离明显增加，而使得有足够时间完成向 w 清湖中街 3 小区信号的切换，消除了两信号中间的盲区，掉话不再出现。【结论结论】由于机场高速位于郊区，基站数目较少，两个基站中间出现信号盲区的几率较大，且车辆高速运行过程中很容易造成切换来不及掉话。通过调整，消除了盲区，切换顺利及时完成，掉话隐患排除。3.1.4 导频污染而掉话【现象描述现象描述】 vip 投诉珠江御景湾区域存在掉话现象。【原因分析原因分析】 掉话点位于华南快速干线

37、珠江御景湾附近,行驶方向由南往北走，ue 在做vc 长呼业务（锁 3g，为主叫 ue），服务小区为 w 农丰基围 2(（psc193），掉话前 rnc 侧下发 utran mobility information，但没收到回复，直接导致掉话。查看 ue 侧发现 ue 没收到 utran mobility information 。该路段没有主导小区导频，导频污染较严重，掉话前服务小区 ec/io 较差，约为-14db，导致 ue没收到 utran mobility information，形成掉话。【解决方案及效果解决方案及效果】前期对珠江御景附近站点进行调整，导频污染已得到控制，但由于 w

38、海珠大沙西，w 华快土华和 w 海珠赤沙等美化天线站点暂时无法调整，越区严重，导频污染仍然存在，也有掉话的可能。建议对上述美化天线进行调整。通过对以上美化天线的调整，导频污染得到较大改善，复测未掉话。见下图。3.1.5 上行干扰导致掉话【现象描述现象描述】 vip 投诉在新时空大厦到上华快路段掉话； 【原因分析原因分析】 在测试也发现下图所示的区域经常发生掉话现象：结合 rtwp 排除组可知，该区域存在严重的干扰，故重点在于排除干扰。【解决方案及效果解决方案及效果】通过排查，发现该区域的干扰来自河南老家直放站干扰，通过关闭该直放站后，干扰消失，rtwp 恢复正常，在 vip 线路测试中该区域未

39、再发生掉话现象，证实了此前掉话为上行干扰引起的结论。3.1.6 越区覆盖导致掉话【现象描述现象描述】 用户投诉沙湾福涌附近频现掉话现象。【原因分析原因分析】 1、经查询该小区掉话次数较高，检查告警，未发现异常告警，初步排除了基站及天馈等硬件故障导致的掉话； 2、对该小区的 rtwp 提取分析，可知 rtwp 良好，排除了上行干扰导致；3、对掉话用户进行跟踪，发现掉话也并非同一个用户引起的，排除了用户终端问题；4、通过跟踪该小区的 ios 可知，掉话前 ue 收到的激活集小区的 rscp 及 ec/io都较差，怀疑存在弱覆盖或过覆盖现象；5、通过对该小区的覆盖情况分析可知，该小区存在严重的越区覆

40、盖：rf 优化前该小区用户分布情况如下图：根据该小区用户分布情况，怀疑该小区存在越区覆盖情况。该小区的路测数据的分析，该小区近处覆盖偏差，如下图所示：【解决过程解决过程】 经查询该小区天线挂高达到 44 米，结合优化前覆盖及用户分布情况，该小区可能存在越区覆盖的现象。通过现场勘测发现该小区天线下倾角机械和电子均为 0，不符合常规设置，结合片区优化测试数据分析，将该小区电子下倾角从 0调整至 5。rf 优化后，一周未出现掉话，对该小区的覆盖分析可知，完成 rf 优化后该小区覆盖合理，证实了此前掉话是由越区覆盖引起的分析。 rf 优化后该小区用户分布情况：优化后该小区用户分布情况属于正常情况。该小

41、区的复测路测数据的覆盖如下图所示： 该小区近处覆盖信号强度好于优化前，说明该小区优化前确实存在越区现象，通过下压天线，越区现象消失。【结论结论】解决越区覆盖的关键是控制天线的工程参数，保证天线工程参数的设置合理，避免因下倾角过小，导致严重越区，而近处覆盖差的现象，远处容易因上行链路恶化或下行因受其它小区信号干扰而产生掉话。本小区在 rf 优化前后进行话统跟踪对比：rncidcellidcellname统计性质统计性质统计周期统计周期amr 掉掉话次数话次数32912043w 沙湾福涌 3rf 优化前7 天3932912043w 沙湾福涌 3rf 优化后7 天0通过本次 rf 优化后，该小区的掉

42、话得到明显改善。3.1.7 参数配置不合理导致掉话现象描述：现象描述：用户反映在某住宅区电梯内无 3g 信号，经常出现掉话现象。原因分析：原因分析：1).邻区漏配2).覆盖差3).切换导致的掉话4).干扰导致的掉话5).设备问题导致的掉话处理过程：处理过程：1)后台网优人员首先检查了掉话点周围 3g 基站，确认不存在硬件故障；2)该区域多个用户反映存在掉话问题，排除用户手机问题；3)经核查，电梯内安装有室内分布系统，室内 gsm 信号较好。后台确认系统间切换允许开关打开；4)核查掉话点周围 3g 基站异系统邻区规划合理，不存在漏配 gsm 邻区现象；5)核查所有异系统邻区数据，均和现网数据一致

43、，不存在 gsm 邻区数据错误问题；6)网优测试人员前往现场，进行多次拨打测试。经测试掉话点室外信号较好，室内 3g 信号较差，rscp 达到-94-97dbm 左右，一旦进入电梯内，信号迅速衰落到-110dbm 左右，导致掉话。经过多次拨打 3g 到 gsm 异系统切换成功率仅为 50%左右；7)根据测试人员反馈的结果，初步判断为异系统切换不及时导致的掉话。后台降低该 3g 小区切换到相邻 gsm 小区的延迟触发时间，依然没有改善。8)根据以上情况，说明手机进入电梯后一段时间才发生信号的快速衰落，此时已经来不及进行切换判决导致掉话。所以必须让 ue 进入电梯前就发生切换，选择到 gsm 网络

44、上，保证用户正常通话。根据测试人员反馈将该 3g 小区异系统切换参数作以下修改：调整对象原值新值cs 业务异系统测量 rscp 启动门限-100-97异系统切换 cs 判决门限1619cs 业务异系统测量 rscp 停止门限-97-94修改该参数在 lmt 中的命令为：mod cellinterfreqhocov:;如下图所示：9)、测试人员再次测试，问题解决。建议与总结：建议与总结：修改 cs 域异系统切换参数后会影响到该小区向所有异系统邻区的切换，此时需要结合测试人员反馈的该小区周围覆盖情况来考虑。防治出现因为修改一个小区的切换影响到全部小区的切换指标.3.2 接入类问题投诉案例分析3.2

45、.1上行干扰导致接入失败现象描述：现象描述：用户投诉在跑马场内的“河南老家”饭店打电话很难打电话，即使能打电话也杂音很大。原因分析：原因分析：1） 存在上行干扰；2）小区数据配置问题；3） 基站硬件问题；处理过程：处理过程：1）在后台查看站点状态正常且无任何告警之内，数据配置也正常，所以排除由于数据配置问题，导致无法正常接入。 2）查询周边是否存在 rtwp 过高的问题，经查询周边站点 w 金骏大厦、w 天河暨大、等周边站点 rtwp 很高，在-85db。初步怀疑该区域存在上行干扰源；3）经查干扰源发现河南老家有个 wcdma 的直放站，导致周边站点受到上行受到干扰。4）排除干扰源后测试正常；

46、建议与总结：建议与总结：如果发现投诉点周边一片都存在 rtwp 值高的情况基本可以判断该区域存在干扰源，需对干扰进行定位排除。3.2.2.基站版本问题导致的接入问题现象描述：现象描述：用户投诉某室分信号很好但是无法拨打电话。原因分析：原因分析：1）小区数据配置问题；2）存在上行干扰；3）基站版本问题；4） 基站硬件问题；处理过程：处理过程：1）在后台查看小区状态正常且站点无任何告警之内，数据配置也正常（主要是查询 aal2path 是否对应），所以排除由于数据配置问题，导致无法正常接入。2） 经查询该室分 rtwp 值正常，不存在上行干扰；3）查看此站点话统为 0 话务量，严重怀疑此站接入有问

47、题，排除用户手机设置问题。4）经现场测试发现手机发出 4 条 rrc 连接消息后没有任何响应。5）初步怀疑为硬件问题，查询基站版本发现此基站版本老旧，仍然为 065 的版本，目前最新的版本已经为 067。7）反馈 ran 侧人员要求升级到最新版本后，经测试正常。建议与总结：建议与总结：由于 ran 侧开站的时候有时候会误用旧版本，以前查询基站配置的时候没注意基站版本的问题。所以经过此次处理接入问题后基站版本也列入查询的范围。3.2.3.基站硬件问题导致的接入问题现象描述：现象描述：根据用户投诉白云张村附近信号很好，但是无法正常拨打电话，语音和数据业务都无法正常进行。原因分析：原因分析：1） 小

48、区数据配置问题；2） 存在上行干扰；3） 基站版本问题；4） 基站硬件问题；处理过程：处理过程：1）在后台查看站点状态正常且无任何告警之内，数据配置也正常，所以排除由于数据配置问题，导致无法正常接入。 2）查询是否存在 rtwp 过高的问题，经查询该站 rtwp 均正常；3）查看此站点话统为 0 话务量，严重怀疑此站接入有问题；4）查看基站版本已经为最新版本。5）根据现场测试数据分析，ue 在上行 ccch 上每过一段时间就连续发送 4 次 rrc connection request 消息，请求建立 rrc 连接 ，但都未收到回应。咨询专家，得到的建议是更换基站主控板。更换主控板后进行现场测

49、试，语音和数据业务一切正常。建议与总结：建议与总结：此类投诉问题较少，一般都是由于覆盖类问题导致的投诉较多。由于基站本身的硬件故障导致的投诉，首先必须进行现场测试分析，而且还得进入基站查看基站的内部硬件问题，这就需要得到多方配合和协助。3.2.4.异系统切换参数配置问题现象描述：现象描述：联通大院 1 号楼投诉经常切换到 2g；原因分析：原因分析：1）信号覆盖差；2）参数配置不够合理；3）手机灵敏度问题。处理过程：处理过程：1）经过测试发现联通 1 号楼靠近电信研究所边上的信号覆盖确实较差，信号在-90dbm 到-95dbm 之间，另外各别角落，如客服部信号在-100dbm。确实容易切换到 2

50、g。2）经调整广州联通 3 扇区的方向角和下倾角后，测试发现 1 号楼的信号有较大改善，基本在-85dbm 左右。3）但是经过一周时间发现话统数据发现异系统切换还是比较频繁，怀疑参数配置有问题，经检查切换公共参数设置中当异频和异系统同时存在时，启动测量的 2d、2f 门限选用异频设置。如下图：4）而目前异频切换 2d 和 2f 的设置门限为-95dbm 和-92dbm 如下图：5）异系统切换 2d 和 2f 设置门限为-100dbm 和-97dbm，如下图：6）如果切换公共参数关于 2d 和 2f 的门限设置选当异频和异系统参数设置共存时取异频参数的话即为 2d 和 2f 的门限为为-95db

51、m 和-92dbm，明显是偏高的。特别是在室内的用户很容易就达到这门限启动异系统测量，导致频繁地异系统切换。比较影响用户感受，同时也加重系统处理的负荷。7）经商讨后将切换公共参数中当异系统与异频共存时选用异系统测量参数。8）经过更改后查看话统数据异系统切换的测试明显减少，同时掉话率也有所降低。建议与总结：建议与总结：目前由于广州联通多载波的配置的不太多，之前没在意这个参数设置。建议以后全网切换公共参数中当异系统与异频共存时选用异系统测量参数。3.3.数据业务类问题投诉分析案例3.3.1.aal2path数据配置问题现象描述：现象描述：某用户投诉白云区山庄旅社能打电话但是不能上网原因分析：原因分

52、析：1） 存在上行干扰；2）小区数据配置问题；3） 基站硬件问题；处理过程：处理过程：1）经查询附近站点 rtwp 正常，不存在上行干扰。也未存在告警问题。2）经查询 w 山庄旅社的一周的话务统计，发现数据业务的流量都为 0，严重怀疑此站的数据配置有问题。3）用 dsp cell 命令检查 hsdpa 是否有打开。如果没开，把它开起来。4）通过 lst adjnode，输入 nodeb 名找到该 nodeb 邻节点。5）通过邻节点号找到该邻节点下的相关 aal2path 是否有加 hsdpa 非实时的通道，如果没加，反映给 rna 侧工程师。让他们加上。6）目前 rnc 侧的 path 通道一

53、般是 3 条 rt（实时）通道，用于走 vc 和 vp 的业务，1 条 nrt（非实时）通道，用户 r99 数据业务，1 条 hsupa 非实时，1 条 hsdpa 非实时。而该站 path 通道经查询实时的少了一条，如下图7）而经查询基站侧的 path 配置为标准模板的 3 条 rt（实时）通道，1 条nrt（非实时）通道， 1 条 hsupa 非实时，1 条 hsdpa 非实时。从所以从第 3 条 path 开始跟 rnc 侧全不对应，导致数据业务全部不正常。8）经整改后，rnc 侧与基站侧的 aal2path 对应后，数据业务正常使用。建议与总结：建议与总结：当用户投诉可以打电话但是完全

54、不能上网基本可以排除是基站的硬件故障，因为如果硬件故障语音也照样是受音响的，一般都是数据配置问题，要么是 h业务未激活，要么就是 rnc 侧 aal2path 和基站侧不对应导致。3.3.2.rru拉远数据配置问题现象描述：现象描述：联通专项组反映某室分站点 vp 及 ps128kbps 业务正常，hsdpa 速率 5m 以上，但 hsupa 速率均值较低（600kbps），且有很大的波动，并称rtwp85dbm，很高。原因分析：原因分析：1）上行干扰问题2）室分设计问题3）小区配置问题处理过程：处理过程：1） 从测试反馈的情况，初步定位是上行干扰引起hsupa业务速率不正常，采用后台降低底躁

55、方式，重新测试验证。没有明显改善。从机房log看，发现测试人员反馈的信息有误，rtwp只在发起hsupa业务时才剧烈抬升，不发起业务则不会。实际底躁106dbm，是正常的。怀疑存在外部干扰导致hsupa速率波动。2） 由于外部干扰源定位及测试设备有限，所以为避免盲目查找干扰源。让测试人员加载然后用ps128kbps测试，速率基本正常。排除是其他干扰影响。而是设备上行干扰带来的问题或室分系统上行干扰带来的问题。需查询室分系统设计原理图3） 通过室分系统设计，发现此点为3个rru，从bbu3个cpri口拉出，属于规范化设计。让测试人员去另外的rru覆盖点进行hsupa测试，问题复现。设备无任何告警

56、。但是此测试rru所属小区与原rru所属为同一小区。考虑此站是3个rru从3个光口拉出，怀疑小区配置错误。查询此站点小区配置参数，为o1（全向1小区）配置，完全不符合产品设计规范。产品不允许跨光口超过2个配置为一个小区。更改为s111的3小区配置后，重新测试，hsupa业务正常。建议与总结：建议与总结：在此次联通广州室分测试中发现多处室分在信号覆盖正常情况下，出现业务性能的异常，vp 不通，或 hsupa 速率低。对于此类问题，如果不存在上行外部干扰情况下，需要首先确定室分的设计和配置是否正确。对于级联过多，跨光口配置同小区过多的情况尽量避免。由于联通 license 的限制，不少室分站点没有

57、按照设计的小区数量来配置，导致出现性能问题。3.3.3 直放站问题导致的数据业务问题现象描述：现象描述：联通某营业厅投诉数据业务速率不正常，经了解此营业厅为直放站覆盖点。原因分析：原因分析：1）基站故障问题2）上行干扰问题3）直放站问题处理过程：处理过程：1）经测试发现该营业厅引入附近宏基站的信号，好几个扰码的信号，强度都很强，rscp 在-50dbm 左右，所以 ec/io 值很差，基本在-10db 以下。hsdpa 速率 1m-2m，不正常。2）另外查询相关站点的 rtwp 值都正常而且无告警，排除上行干扰和基站问题。3）初步确认是直放站引入的信源点存在导频污染，建议调整信源点位置，取得相

58、对纯净的信源。4）经调整后 ec/io 值有较大改善，大概-6db 左右，属于正常范围。5）经测试 hsdpa 速率为 2m 多，有所改善但是仍然不正常。排除信号强度与质量都很好排除是信号问题导致速率低。6）怀疑是直放站设备问题导致，建议直放站厂家更换设备。7）厂家更换设备后测试，发现 hsdpa 速率仍然为 2m 多。百思不得其解。8）经咨询专家，有可能直放站增益设得太高导致信号被非线性放大导致的问题。与厂家协商后调低放大增益，大概信号强度在-80dbm 左右，ec/io 为-7 左右。经测试 hsdpa 的速率为 4m-5m。大大改善，基本符合要求。建议与总结：建议与总结：由于联通在室内的

59、覆盖中大量使用直放站，在直放站的应该过程中应该注意 2个问题：1、信源点必须是纯净，不能存在导频污染；2、增益不是越大越好，调整到一个合理的水平即可，信号强度大概在-80dbm 即可。3.3.4 外网服务器问题导致的数据业务问题现象描述：现象描述：用户投诉用上网卡上网看视频很卡，不流畅。信号显示满格。原因分析：原因分析：1）基站故障；2）存在上行干扰；3）导频污染，cqi 差；处理过程：处理过程：1）经查询投诉点周边站点无告警，rtwp 正常，不存在上行干扰；2）经联系用户一起测试，测试发现信号很好，不存在导频污染；3）测试 hsdpa/hsupa 速率均正常，速率为分别为 4m/1.8m，完

60、全覆盖要求。4）排除网络问题，但是用户用上网卡看某视频网站就是卡，不够流畅。5）由于用户住家也有电信的宽带网络，建议用有线宽带试试看，是否流畅。经测试也不流畅。初步怀疑为此网站服务器问题。6）用上网卡上网试看其他几个视频网站后发现有些比较流畅，有些卡。基本确认是服务器问题。经与用户解释后用户表示接受。建议与总结：建议与总结：目前很多视频网站服务器并不一定是在内网的服务器，也不知道转了多少次网关；如果用户投诉看视频卡的话建议用户多看几个视频网站进行对比，如果所有网站都卡，可能是信号问题导致。如果不是，说明是某些网站服务器问题。3.4 用户行为类问题投诉分析案例3.4.1 手机设置问题导致不能上网