南昌联通WCDMA网投诉指导书Word文档下载推荐.doc

南昌联通WCDMA网投诉指导书Word文档下载推荐.doc

《南昌联通WCDMA网投诉指导书Word文档下载推荐.doc》由会员分享，可在线阅读，更多相关《南昌联通WCDMA网投诉指导书Word文档下载推荐.doc（45页珍藏版）》请在冰豆网上搜索。

3.1.6越区覆盖导致掉话 26

3.1.7参数配置不合理导致掉话 29

3.2接入类问题投诉案例分析 31

3.2.1上行干扰导致接入失败 31

3.2.2.基站版本问题导致的接入问题 32

3.2.3.基站硬件问题导致的接入问题 33

3.2.4.异系统切换参数配置问题 35

3.3.数据业务类问题投诉分析案例 37

3.3.1.AAL2PATH数据配置问题 37

3.3.2.RRU拉远数据配置问题 38

3.3.3直放站问题导致的数据业务问题 39

3.3.4外网服务器问题导致的数据业务问题 40

3.4用户行为类问题投诉分析案例 41

3.4.1手机设置问题导致不能上网 41

3.4.2上网卡拨号软件设置不正确导致不能上网 42

3.4.3手机拨号软件设置不正确导致不能上网 43

3.4.4用户错误认识导致的投诉 44

1.概述

本文将从投诉处理流程、投诉处理问题分析、典型的案例分析等三个部分进行描述分析总结。

投诉处理流程。

由于在投诉处理过程中遇到的问题会是各种各样的，所以流程在投诉处理中占有比较重要是作用，只有清晰流程后，在处理投诉过程中考虑问题才能更为全面。

投诉问题处理分析。

主要介绍在处理投诉过程中大概会遇到的问题和分析定位的方法技巧。

典型的案例分析。

我们在投诉处理过程中很注重经验的总结和分享，经验总结对后续的投诉处理工作很重要，有助于对问题的快速、准确定位。

本文在典型案例分析中主要对接入类问题、掉话类问题、数据业务类问题、用户行为类问题做一些典型的案例分析，希望能给读者在投诉处理过程中带来启示。

2.投诉处理流程

2.1投诉处理路程图

1投诉受理

2获取准确的投诉相关信息描述

3覆盖分析

4故障分析

5行为分析

6测试分析

7后台数据分析

8重新测试，重现问题

Y

N

图1掉话分析流程图

投诉受理

获取投诉相关信息

覆盖分析

覆盖类问题

无站点覆盖

故障分析

有覆盖

故障类问题

站点是否故障

用户行为分析

行为类问题

测试重现问题

后台数据分析

掉话类问题

接入类问题

掉话

接入失败

无

用户手机或电脑设置有问题否

数据类问题

速率不正常

是否解决

是

否

投诉分析判决树

2.2.投诉处理流程描述

2.2.1投诉受理

投诉受理必须满足如下条件，否则不受理：

Ø

要有明确的地址而且能在google地图上找到；

出现问题的准确时间，便于查询相关历史记录等；

要有详细的问题描述，否则无法定位问题；

要有用户的联系方式，方便联系用户一起测试重现问题；

2.2.2覆盖分析

通过用户提供的详细而且准确的地址在Google地图上找到投诉点，看投诉点是否在规划区域内，不在区域内的不予受理，在规划区域内看是否周边有站点覆盖（市区方圆1公里以内，郊区方圆1.5公里以内），如果无站点覆盖直接归类到覆盖类问题，建议后期加站解决。

有站点覆盖，看是否优化可解决，如果明显有建筑物或者山体阻挡无法通过优化解决，建议后期加资源解决。

另外有投诉室内覆盖的差就得看相关台账信息，查看投诉点是否有规划室分，是否规划全覆盖，规划了是否已经开通。

从目前投诉覆盖差的区域主要集中在城中村区域，这些基本无法通过优化解决。

2.2.3故障分析

投诉点周边有站点覆盖的情况下，需查询投诉点周边站点是否有故障和告警，如果有严重的告警或者数据配置问题建议申请闭塞掉该站，以免引起更多的用户投诉。

然后通知相关负责人处理。

另外需要看故障站点是否新开通的站点，目前存在新开站点入网流程执行不力，有些新站没通过单站验证直接就入网导致很多用户投诉。

一般需要查询的项目如下：

站点是否有实时和历史告警；

小区状态是否正常；

站点的RTWP值是否偏高，基准值为-105dB，如果RTWP偏高会引起接入失败，H业务速率偏低等问题；

RTWP值偏高导致速率不正常的投诉较为常见；

传输是否有故障；

如高误码率等问题会引起数据业务不正常；

数据配置是否正确，如HSUPA/HSDPA是否激活，RNC和NODEB的AAL2PATH配置是否匹配（后面案例分析中会详细介绍）等；

基站版本是否为最新版本；

2.2.4用户行为分析

当我们查询投诉点周边站点都未发现有问题后得考虑是否用户行为问题或错误认识导致的投诉，一般有以下问题：

用户投诉信号不好，查询投诉点周边有站点覆盖，而且不故障。

经与用户沟通后业务均正常，用户认为2G一直信号都是满格，3G信号就不是满格而且不稳定，如果业务正常可不受理投诉；

用户手机网关IP设置不正确、上网卡拨号软件设置不正确导、端口冲突、上网卡驱动与系统冲突等问题；

用户看见拨号后发现拨号速率为7.2M，但是上网过程中始终达不到这个速率就投诉；

用户恶意投诉问题。

如果投诉数据卡上网看视频卡，不流畅可以让用户多看几个视频网站，有可能是某个网站服务器问题，不一定是网络问题。

2.2.5现场测试重现问题

如果投诉点周边站点无故障，又非用户行为问题就必须联系用户到现场测试定位问题了。

现场测试需要注意的事项：

尽可能联系用户一起测试，这样避免地理位置不准确导致问题不能重现，另外如果不是网络问题，我们测试正常用户在场的话也好对峙非网络问题。

测试工程师必须了解清楚投诉的问题，有针对性的测试；

测试过程中后台做好各项跟踪工作，如RTWP值、信令、小区性能监控等信息，以便对问题作精确的定位；

测试除针对用户投的的问题进行针对性测试外需要进行全业务测试，这样全面搜集数据便于后台问题的定位分析同时看是否存在用户投诉之外的其他问题。

2.2.6后台数据分析

现场采集数据之后，后台结合RNC跟踪的相关数据进行分析。

流程如下：

1准备数据

分析各集信号

稳定

2获取问题点的

位置和时间

3分析主导小区信号变化

4.1RSCP差

Ec/Io差

4.2RSCP正常

4.3RSCP正常

Ec/Io正常

邻区漏配

上行干扰问题

切换不及时

确认漏配

邻区？

覆盖问题

异常掉话

导频干扰问题

检测集

确认RTWP

干扰？

问题是否解决

5重新路测

有

主导小区信号稳定？

4最优小区RSCP

和Ec/Io

乒乓切换问题

变化频繁

高

低常

图3数据分析判决流程

2.2.7问题类型描述

2.2.7.1邻区漏配

一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。

对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：

方法一：

观察掉话前UE记录的活动集Ec/Io信息和Scanner记录的BestServerEc/Io信息，如果UE记录的Ec/Io很差，而Scanner记录的BestServerEc/Io很好；

同时检查Scanner记录BestServer扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。

方法二：

如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。

方法三：

有些UE会上报检测集（DetectedSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。

邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。

异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。

异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。

2.2.7.2覆盖问题

通常所说的覆盖差，主要是指RSCP很差。

上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：

如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RLfailure，基本可以认为上行覆盖差导致的掉话；

如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。

在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。

如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。

确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和Ec/Io都很低，就可以认为是覆盖问题。

由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差（目前城中村的覆盖差投诉基本为此原因），扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。

2.2.7.3切换导致的掉话

软切换/同频导致掉话主要有两类原因：

切换不及时或者乒乓切换。

从信令流程上CS业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重配置），PS业务也有可能收不到活动既更新命令，也有可能在切换之前先发生TRB复位。

从信号上看，切换来不及主要有以下现象：

1）拐角：

源小区Ec/Io陡降，目标小区Ec/Io陡升（即突然出现就是很高的值）；

2）针尖：

源小区Ec/Io快速下降后一段时间后上升，目标小区出现短时间的陡升。

从信令流程上看，一般在掉话前手机上报了邻区的1a或者1c测量报告，RNC也收到了测量报告，并下发了活动集更新消息，但UE收不到活动集更新消息。

乒乓切换主要有以下两种现象：

1）主导小区变化快：

2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和Ec/Io每个小区成为主导小区的时间很短；

2）无主导小区：

存在多个小区，RSCP正常而且相互之间差别不大，每个小区的Ec/Io都很差。

从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的活动集更新命令导致失败。

解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1a