投诉处理流程及案例分析

投诉处理流程及案例分析
投诉处理流程 (1)
1、投诉处理流程 (1)
1.1 投诉信息采集 (1)
1.2 投诉处理流程 (2)
2、投诉现象分类 (2)
3、投诉处理常用方法 (3)
3.1话务跟踪分析 (3)
3.2 硬件故障查找 (4)
3.3 现场测试分析 (5)
4、投诉处理案例分析 (5)
4．1接入失败 (5)
4．2 信号差 (6)
4．3单通 (8)
4．4用户不在服务区 (10)
4．5部分手机打不通电话 (12)
1、投诉处理流程
投诉处理工作是网络日常维护中不可缺少的部分，因此需要有一套好的流程和方法，以确保工作的有效性和高效性。

方法和流程主要包括以下几方面。

1.1 投诉信息采集
原始投诉信息的采集是处理投诉问题的基础和条件。

我们接到的投诉多半比较紧迫，需要以最快速度解决，但在未了解实际投诉问题的情况下拿着测试手机或仪器去现场测试是盲目而低效的。

我们必须完成基本信息的采集，其内容包括：
➢用户基本信息。

➢投诉问题类型
➢具体投诉描述
➢具体投诉地点
➢投诉问题发生的时间及频率
➢使用手机终端类型
➢主被叫号码
➢其它相关信息（包括重要活动、用户行为等）
有了这些信息，我们对投诉问题的分析就更加具有针对性，也便于我们制定出随后的话务跟踪、话务统计、硬件排查以及现场测试等综合分析计划。

1.2 投诉处理流程
实际处理投诉问题时，建议按照如下流程开展工作:
2、投诉现象分类
根据以上流程，我们接到投诉后首先根据其现象进行归类。

大致可分为以下几类：
➢用户终端问题。

➢信号差
➢信号不稳定
➢通话断断续续
➢有信号打不了电话（接入失败）
➢通话回音
➢有信号则提示用户不在服务区
➢掉话
➢单向通话（单通）
若根据用户反映的情况是手机终端问题则现场跟用户沟通解释；若是无覆盖则现场勘测，提出建站需求。

用户投诉信号差、信号不稳定、通话断断续续等一般都是由于弱覆盖及无主覆小区引起，可以通过参数和天线调整来尝试解决；对于接入失败、单通、有回音则要根据实际情况，综合统计和现场测试来定位问题所在。

3、投诉处理常用方法
用户投诉问题一般比较紧迫，因此在接到投诉后必须以最快的方式定位问题原因，排除故障，实施优化调整，最终保证网络更好的服务质量，以提高用户的满意度。

在进行投诉处理时一般采用如下一些方法。

3.1话务跟踪分析
话务跟踪分析是我们处理投诉问题的常用方法，它可以快速定位投诉问题的原因。

在处理大量用户类似投诉时，话务统计数据往往能提供各种全面详实的信息，便于我们从宏观上把握网络状况，由点及面、点面结合地分析和定位问题。

用户投诉的问题，如掉话、呼叫失败、话音质量差等，一旦频繁出现在某个区域，则一般都能在话务统计数据中有所体现。

比如和掉话相关的话务统计指标及OSS工具统计有：
➢无线掉话率
➢切换成功率
➢信道拥塞率
➢话务掉话比
➢MRR统计
和呼叫失败相关的话务统计指标有：
➢随机接入成功率
➢TCH分配成功率
➢SDCCH分配成功率
➢TCH&SDCCH信道拥塞率
➢信道完好率
和话音质量相关的话务统计及OSS工具测量有：
➢质差掉话（上下行质差掉话）
➢ICMBAND统计
➢FAS统计
➢切换原因统计
通过分析话务统计指标的变化和指标间的相关性，通过OSS工具统计发现可能存在的问题，如话务量激增造成的拥塞、突发硬件问题引起的大量系统侧呼叫失败和掉话、外部干扰的影响及过覆盖导致的干扰等等。

这时解决个别投诉问题则上升到解决网络整体或局部的问题，结合网络话务统计数据可以有效地避免“只见树木，不见森林”的误区，从根本上定位问题所在，以利于采取切实可行的措施。

3.2 硬件故障查找
如果从话务统计数据上发现在投诉的日期或时间段服务基站的多项性能指标突然恶化，而之前或随后又基本正常时，投诉问题很大程度上和硬件的瞬间故障有关。

这时需要监控该基站状态，通过ERRLOG查看是否有硬件告警记录；同时与基站班组沟通，查看基站日志文件，看是否有硬件故障恢复记录；必要时对投诉较严重、故障出现次数多的基站进行检测，以排除硬件故障带来的网络服务质量隐患。

如果从话务统计数据上发现一些指标异常而无明显的硬件告警指示，如掉话多、接通率低也可以查看MOTS统计，是否在某一块载频上有明显的TS 掉话，有则该载频有故障。

3.3 现场测试分析
接到投诉后在上述几项分析完成大概可以确定问题所在后进行现场测试、现场调整、现场解决，若仍然无法定位故障原因，或没有足够的线索时，需要去投诉现场进行问题测试。

一般覆盖问题投诉可以通过信号测试比较方便的找出问题原因，如室内深度覆盖、建筑密集信号弱，然后通过天线和参数调整方案，在兼顾周围覆盖要求的前提下尽可能改善覆盖目标的信号质量；对于无法通过优化解决的问题则提出后期加站和加室内分布系统的方案。

而对于呼叫失败、掉话、话音质量等问题，其可重复性往往不能保证，同时涉及无线环境、小区负荷、基站硬件以及手机终端等多个方面，现场测试定位问题的效率比较低。

在这种情况下，进行现场测试必需了解尽可能准确的投诉地点和时间，完成相同呼叫类型的话务，同时记录空中接口信令消息，并在系统侧进行话务跟踪，一旦采集到投诉的问题实例，便可以结合多种数据进行综合分析，定位问题原因。

4、投诉处理案例分析
4．1接入失败
投诉问题：用户在万秀村信号满格而无法打进打出
投诉分析：根据用户反应的情况，按照上面的处理方法，首先对其投诉点所覆盖的小区话务统计进行搜集，分析统计发现万秀村附近的明秀北一里445号1800
基站NI32701和NI32703小区话务不正常，在本小区没有起呼的话务，都是切入话务，SDCCH占用0次，随机接入0次，如下表：
根据统计从18日8点开始NI32701和NI32703小区话务就不正常，跟用户反映的从18日开始打不了电话相符合，该小区SDCCH占用0次，随机接入0次，如上统计。

由于有切入的话务，我们估计是该2个小区的BCCH载频有故障或掉死，我们分别对其NI32701和NI32703小区的BCCH载频闭解后话务回复正常，如下统计：
回访用户，用户确认已能正常拨打电话。

确认是NI32701和NI32703小区的BCCH载频故障引起。

4．2 信号差
投诉问题：新阳路三医院门口公车站一带信号很弱，通话声音断断续续
投诉分析：首先分析用户投诉现象，应该是由于信号弱引起通话断续，对于市区弱信号，一般从统计上无明显特征，这就需要现场测试，具体了解投诉点占用那个小区较为合适。

根据用户投诉，实地测试发现用户反映情况属实，且罐头厂大门口离基站大约500M左右RXLEV为－85DB，以下是医院门口测试情况：
从现场测试观察，投诉点应占用罐头厂NN21702小区较为合适，根据以上处理方法所述，我们应该检查该小区有关覆盖的参数设置（如BSPWRT、BSPWRB、ACCMIN等）是否正常，经检查都属正常配置，检查天线资料发现，该小区俯仰角为13度，俯仰角过大，覆盖范围缩小。

调整NN21702天线俯仰角13°->7°后，信号明显改善，见下图：
4月26日调整后指标观察，跟调整前指标有明显改善，以下是调整前后一天
（25日与27日）6忙时指标对比，且每时段话务量都增加了10ERL左右，19：00－20：00增加有20ERL,充分利用了网络资源，提高了用户感知度。

4．3单通
投诉问题：联动中心用户投诉能听到对方讲话，而对方不能听见自己的声音。

投诉分析：根据用户反映情况，应属单通现象。

单通一般跟交换侧A接口、互联互通及无线侧硬件故障等引起，A接口问题一般引起大面积用户投诉、互联互通则只是针对拨打联通或电信等有单通现象而其他正常，根据用户反映都排除以上两种情况，无线侧则一般是硬件及频点干扰引起。

首先查看统计，指标较为正常，无明显变化；检查硬件无历史告警指示。

经现场DT测试主要是微蜂窝室内覆盖（NH25710），在室内收到较多地方信号如NH10223&NH10221,信号较好，见下图：
根据用户反映的有单通现象，进行了CQT测试，发现很少占用主覆小区CID:NH25710 TCH:7，锁频测试时，发现占用7号频点（TRX-69-1）时对方听不见我方的声音，但我方能很清楚的听见对方（即单向通话），且没有干扰。

闭掉其中一块好的载频（TRX-69-0），让通话都占用TRX-69-1载频，结果发现都是单通，不断尝试都如此，如下图：
上图是与被叫接通后而对方无法听到我方的声音而挂断的测试情况。

激活TRX-69-0，闭掉载频TRX-69-1后通话正常，由此证明TRX-69－1载频故障。

因此这是由于硬件故障引起的单通现象。

4．4用户不在服务区
投诉问题：XX城区一段时间以来用户投诉在一定区域“用户不在服务区”现象出现较多；同时有时主叫不能成功，用户听到“嘀嘀”声后掉线，第二次呼叫又能成功。

问题分析："用户不在服务区"这一现象出现的几种可能性有：
1、 MS接收信号不好掉网,MS掉电未给网络送关机信号。

2、用户SIM卡触点损坏,PAGING无响应。

3、所在小区有硬件损坏。

4、 BSC数据库中参数设置有问题。

首先检查相关参数设置及BSC参数T3212是否设置一致，T3212决定小区内MS LOCATION UPDATE的时长。

与MSC参数MOBTHR:IDETTIM联合判断
MS的ATTACH/DETACH状态.(T3212<IDETTIM),经检查均正常；根据投诉现象描述并非一个用户现象，所以排除1、2种可能性。

由此我们可以检查基站硬件，该小区配置为5个TRX，分别为0、1、2、4、5，分别对5个载频CQT测试，发现占用TRX1时对方打我电话都出现提示：“你拨打的电话暂时无法接通”，所以判断TRX1故障（但无告警），而在TRX1上配有SDCCH/8一个，TCH七个。

TRX1故障后直接导致8个SDCCH 信道在ACTIVE时不成功，无法进行成功的SDCCH指配，从而使正常的呼叫和寻呼过程由于SDCCH信道激活失败而失败。

MSC在收到呼入请求后，将寻呼消息下发给被叫用户所在LAC的BSC，BSC在整个LAC内所有小区的PCH 信道上对被叫MS进行寻呼；MS收到、并正确解码寻呼消息后，将在RACH 信道上发起一个响应寻呼消息的接入请求BUST，BTS将次消息透明传给BSC，由BSC通过无线资源管理进行专用信令信道的分配；BSC通过无线资源管理找到一个空闲的SDCCH信道，并给BTS下发CHANNEL ACTIVE命令激活该SDCCH信道；SDCCH信道激活成功后，BSC将向MS发起对该SDCCH 信道的立即支配流程，支配成功后小区寻呼成功次数计数器加一，同时BSC将一个含有PAGING RESPONSE消息的完全层消息回给MSC ，之后在建立起的SDCCH信道上进行通话前的信令处理。

由于TRX1故障，其上的8个SDCCH不能激活，当BSC命令BTS激活的SDCCH在TRX1上时，BTS返回CHANNEL ACTIVATON NACK（信道激活不成功）消息给BSC；随后BSC 发出Immediate Assigment Command给BTS，BTS发Immediate Assigment Reject给MS。

从而寻呼不成功。

当MS发起呼叫时首先在RACH信道上发出呼叫接入的Channel requst BUST，BTS将此消息传给BSC，由BSC通过无线资源管理功能找到空闲的SDCCH信道，并通过Channel Activation 消息通知BTS激活此信道，激活后由BTS回一个Channel Activation ACK消息给BSC；随后BSC开始SDCCH的立即指配流程，立即指配成功后，BSC向MSC发送一条含有CM服务请求的完全层三消息；之后在建立起的SDCCH信道上进行和呼叫相关的信令处理。

在TRX1故障后，其上的8个SDCCH不能激活，当BSC命令BTS激活的SDCCH在TRX1上时，BTS返回CHANNEL ACTIV ATON NACK（信道激活不成功）消息给BSC；随后BSC 发出Immediate Assigment Command给BTS，BTS发Immediate Assigment Reject
给MS。

SDCCH信道无法建立，主叫不成功。

然而，由于该小区中在TRX0上还配有一个SDCCH/8，当BSC通过无线资源管理功能命令BTS激活的SDCCH信道在TRX0上时，MS作为主叫或被叫均能正常通话。

4．5部分手机打不通电话
投诉问题：宾阳大桥附近部分手机打不了电话，但有些手机能正常通话。

问题分析：出现部分手机打不了电话的几种可能性有：
1、手机故障。

2、弱信号引起，在信号覆盖较差的地方由于信号的不稳定以致信号时有
时无。

3、上行干扰引起。

下行信号弱的区域，上行至基站的信号也弱，而在上
行干扰存在的区域，较弱的上行信号会被上行干扰所淹没，导致这部
分手机在下行有信号的情况下，却无法打电话和收发短信
4、覆盖小区硬件故障（如载频、天馈线故障）
首先从现象分析，根据现场测试排除手机故障和弱信号情况，则经过FAS工具分析没发现有频点干扰情况，所以从上面的可能情况可以初步判断为硬件问题。

检查各时段话务统计发现覆盖小区NT11931随机接入申请和SDCCH试呼为0次，用户无法在该小区起呼，只有切入的话务，见下表：
从上表得知有可能是BCCH载频吊死，尝试重启BCCH载频后都能在NT11931小区发起呼叫，现场反馈也表示能正常占用，且统计指标正常，如下表：
4．6 干扰引起用户投诉掉话
投诉问题：横向芦村用户投诉掉严重。

问题分析：掉话是网络优化中最难解决的问题,掉话产生既与无线网络有关,也与交换网络有关,但发生在无线网络的掉话占绝大部分的比例。

无线掉话有弱信号掉话、质差掉话、TA掉话、突然掉话。

但处理的方法很多，一般根据掉话的类型采取不同的方法，但发生掉话根本的原因有：信号强度太弱、信号质量差（频点及外部干扰）、切换拓朴不合理、基站硬件故障等。

根据横向芦村反映的用户情况，实地核实覆盖小区为NT11633,收集统计发现掉话较高主要是突然掉话和上行质差掉话，如下表：
突然掉话的原因比较复杂，用户行为、硬件、传输和切换等都可引起突然掉话；但质差掉话就有可能是同邻频干扰、移动台之间的干扰、交调干扰等。

ERRLOG统计无告警，从MOTS统计看掉话在每个载频上都有TS中断的现象（如下表），且已更换过载频，由此推断有可能是传输或干扰引起。

5 27
NNBSC20/RXOTS-105-0-6 2007-3-
27 21:00:00 31 7 22.58
NNBSC20/RXOTS-105-0-7 2007-3-
27 21:00:00 31 14 45.16
NNBSC20/RXOTS-105-1-0 2007-3-
27 21:00:00 0 0 0
NNBSC20/RXOTS-105-1-1 2007-3-
27 21:00:00 0 0 0
NNBSC20/RXOTS-105-1-2 2007-3-
27 21:00:00 11 0 0
NNBSC20/RXOTS-105-1-3 2007-3-
27 21:00:00 46 1 2.17
NNBSC20/RXOTS-105-1-4 2007-3-
27 21:00:00 71 0 0
NNBSC20/RXOTS-105-1-5 2007-3-
27 21:00:00 66 1 1.52
NNBSC20/RXOTS-105-1-6 2007-3-
27 21:00:00 136 65 47.79
NNBSC20/RXOTS-105-1-7 2007-3-
27 21:00:00 84 10 11.9
但检查传输，传输质量很好，排除传输问题。

同RIR统计有明显的低端频点干扰，如下图：
所以估计是低端频点受联通CDMA干扰，修改低端频点后一个小时仅1、2次掉话，掉话现象明显减少，故障消除。

4．7 用户无法正常使用GPRS业务
投诉问题：南宁市南国街用户投诉无法正常使用GPRS业务。

问题分析：无法正常使用GPRS业务有很多原因引起，一般有以下几种可能：
1、用户操作不当。

2、终端问题。

3、CRH、CRO等参数设置不当引起。

4、小区话务拥塞无PDCH分配。

5、PCU拥塞或RPP故障无法正常分配PDCH。

6、GPRS核心网故障。

首先根据用户反映的情况进行核实，是否是用户行为及用户终端问题，从对国街用户核实情况及测试情况（已能正常使用GPRS）分析排除1、2、3的可能性，同时排除GPRS核心网问题，检查话务统计覆盖小区NF14443无TCH拥塞的情况，所以排除无PDCH分配的原因。

由此有可能为PCU拥塞和RPP故障，检查GPRS统计发现BSC6下的很多小区都无GPRS流量，且只有PDCH 分配尝试次数，而没有分配占用次数，如下表：
通过RLGRP指令查看这些小区都是在RPP=494&498下尝试分配PDCH,且STDEP 看RPP下DEV基本都是IDLE状态，而根据统计PCU已轻微拥塞,所以我们判断是RPP故障引起，MBL RPP=494&498后回复正常，都能正常分配PDCH信道。