最新完美版投诉处理流程及案例分析.docx
- 文档编号:7287926
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:23
- 大小:374KB
最新完美版投诉处理流程及案例分析.docx
《最新完美版投诉处理流程及案例分析.docx》由会员分享,可在线阅读,更多相关《最新完美版投诉处理流程及案例分析.docx(23页珍藏版)》请在冰豆网上搜索。
最新完美版投诉处理流程及案例分析
投诉处理流程及案例分析
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次,如下表:
MO
TCH话务量(总)
TCH试呼数(不含切换)
TCH试呼数(含切换)(全)
TCH接通率(不含切换)(总)
TCH接通率(含切换)(全)
随机接入请求
随机接入成功数
随机接入成功率
CCH试呼数
CCH占用次数
SDCCH分配成功率
NI32701
14.78
35
1068
102.86%
73.03%
0
0
0.00%
0
0
0.00%
NI32702
21.44
852
535
99.30%
98.32%
2198
2198
100.00%
2198
2063
93.86%
NI32703
11.40
24
1107
100.00%
71.00%
0
0
0.00%
0
0
0.00%
NI32701
9.44
6
1313
100.00%
53.47%
0
0
0.00%
0
0
0.00%
NI32702
14.22
508
697
100.00%
97.99%
1406
1405
99.93%
1405
1356
96.51%
NI32703
8.60
14
1451
100.00%
42.94%
0
0
0.00%
0
0
0.00%
根据统计从18日8点开始NI32701和NI32703小区话务就不正常,跟用户反映的从18日开始打不了电话相符合,该小区SDCCH占用0次,随机接入0次,如上统计。
由于有切入的话务,我们估计是该2个小区的BCCH载频有故障或掉死,我们分别对其NI32701和NI32703小区的BCCH载频闭解后话务回复正常,如下统计:
MO
TCH话务量(总)
TCH试呼数(不含切换)
TCH试呼数(含切换)(全)
TCH接通率(不含切换)(总)
TCH接通率(含切换)(全)
随机接入请求
随机接入成功数
随机接入成功率
CCH试呼数
CCH占用次数
SDCCH分配成功率
NI32701
10.91
296
1079
77.70%
76.18%
742
742
100.00%
750
711
94.80%
NI32702
16.40
477
623
100.42%
98.07%
1227
1226
99.92%
1226
1167
95.19%
NI32703
13.07
549
1040
87.98%
60.67%
1142
1140
99.82%
1148
1110
96.69%
回访用户,用户确认已能正常拨打电话。
确认是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,充分利用了网络资源,提高了用户感知度。
DATE
CELL
TCH每线话务量(全)
TCH每线话务量(半)
TCH话务量(总)
TCH接通率(含切换)(全)
TCH话务掉话比(总)
话音信道掉话率(总)
话音信道掉话次数(总)
随机接入成功率
SDCCH分配成功率
切换成功率
切换成功率(反向)
42508000900
NN21702
0.30
0.00
13.25
98.97%
158.97
0.39%
5
99.97%
95.30%
96.15%
98.33%
42708000900
NN21702
0.34
0.17
22.49
99.18%
674.58
0.11%
2
99.95%
95.97%
97.47%
99.45%
42509001000
NN21702
0.38
0.05
18.80
99.23%
125.33
0.55%
9
99.98%
96.07%
97.20%
98.45%
42709001000
NN21702
0.33
0.32
28.74
99.43%
574.83
0.12%
3
99.97%
96.86%
98.65%
99.33%
42510001100
NN21702
0.40
0.05
19.92
99.29%
70.29
0.99%
17
99.91%
94.89%
96.39%
98.16%
42710001100
NN21702
0.34
0.36
30.78
99.35%
307.81
0.23%
6
100.00%
96.41%
96.95%
99.26%
42517001800
NN21702
0.39
0.09
21.09
99.39%
105.44
0.68%
12
99.90%
95.33%
98.45%
98.38%
42717001800
NN21702
0.33
0.41
32.78
98.24%
178.79
0.39%
11
99.96%
95.69%
98.85%
98.36%
42518001900
NN21702
0.40
0.03
18.82
98.93%
188.19
0.37%
6
99.97%
96.12%
98.51%
98.63%
42718001900
NN21702
0.31
0.42
32.04
98.26%
174.76
0.35%
11
100.00%
96.57%
97.97%
98.87%
42519002000
NN21702
0.39
0.10
21.81
98.99%
118.97
0.58%
11
99.92%
95.20%
96.91%
99.36%
42719002000
NN21702
0.30
0.67
42.67
94.22%
232.74
0.29%
11
99.94%
96.73%
97.20%
98.63%
4.3单通
投诉问题:
联动中心用户投诉能听到对方讲话,而对方不能听见自己的声音。
投诉分析:
根据用户反映情况,应属单通现象。
单通一般跟交换侧A接口、互联互通及无线侧硬件故障等引起,A接口问题一般引起大面积用户投诉、互联互通则只是针对拨打XX或XX等有单通现象而其他正常,根据用户反映都排除以上两种情况,无线侧则一般是硬件及频点干扰引起。
首先查看统计,指标较为正常,无明显变化;检查硬件无历史告警指示。
经现场DT测试主要是微蜂窝室内覆盖(NH25710),在室内收到较多地方信号如NH10223&NH10221,信号较好,见下图:
根据用户反映的有单通现象,进行了CQT测试,发现很少占用主覆小区CID:
NH25710TCH:
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决定小区内MSLOCATIONUPDATE的时长。
与MSC参数MOBTHR:
IDETTIM联合判断MS的ATTACH/DETACH状态.(T3212 由此我们可以检查基站硬件,该小区配置为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下发CHANNELACTIVE命令激活该SDCCH信道;SDCCH信道激活成功后,BSC将向MS发起对该SDCCH信道的立即支配流程,支配成功后小区寻呼成功次数计数器加一,同时BSC将一个含有PAGINGRESPONSE消息的完全层消息回给MSC,之后在建立起的SDCCH信道上进行通话前的信令处理。 由于TRX1故障,其上的8个SDCCH不能激活,当BSC命令BTS激活的SDCCH在TRX1上时,BTS返回CHANNELACTIVATONNACK(信道激活不成功)消息给BSC;随后BSC发出ImmediateAssigmentCommand给BTS,BTS发ImmediateAssigmentReject给MS。 从而寻呼不成功。 当MS发起呼叫时首先在RACH信道上发出呼叫接入的ChannelrequstBUST,BTS将此消息传给BSC,由BSC通过无线资源管理功能找到空闲的SDCCH信道,并通过ChannelActivation消息通知BTS激活此信道,激活后由BTS回一个ChannelActivationACK消息给BSC;随后BSC开始SDCCH的立即指配流程,立即指配成功后,BSC向MSC发送一条含有CM服务请求的完全层三消息;之后在建立起的SDCCH信道上进行和呼叫相关的信令处理。 在TRX1故障后,其上的8个SDCCH不能激活,当BSC命令BTS激活的SDCCH在TRX1上时,BTS返回CHANNELACTIVATONNACK(信道激活不成功)消息给BSC;随后BSC发出ImmediateAssigmentCommand给BTS,BTS发ImmediateAssigmentReject给MS。 SDCCH信道无法建立,主叫不成功。 然而,由于该小区中在TRX0上还配有一个SDCCH/8,当BSC通过无线资源管理功能命令BTS激活的SDCCH信道在TRX0上时,MS作为主叫或被叫均能正常通话。 4.5部分手机打不通电话 投诉问题: 宾阳大桥附近部分手机打不了电话,但有些手机能正常通话。 问题分析: 出现部分手机打不了电话的几种可能性有: 1、手机故障。 2、弱信号引起,在信号覆盖较差的地方由于信号的不稳定以致信号时有时无。 3、上行干扰引起。 下行信号弱的区域,上行至基站的信号也弱,而在上行干扰存在的区域,较弱的上行信号会被上行干扰所淹没,导致这部分手机在下行有信号的情况下,却无法打电话和收发短信 4、覆盖小区硬件故障(如载频、天馈线故障) 首先从现象分析,根据现场测试排除手机故障和弱信号情况,则经过FAS工具分析没发现有频点干扰情况,所以从上面的可能情况可以初步判断为硬件问题。 检查各时段话务统计发现覆盖小区NT11931随机接入申请和SDCCH试呼为0次,用户无法在该小区起呼,只有切入的话务,见下表: MO DATE TCH话务量(总) TCH试呼数(不含切换) TCH分配失败数(不含切换) TCH试呼数(含切换)(全) TCH分配失败数(含切换)(全) 随机接入请求 随机接入成功数 随机接入成功率 SDCCH试呼数 SDCCH占用次数 SDCCH分配成功率 NT11931 3281000 5.68 8 0 685 133 0 0 0.00% 0 0 0.00% NT11931 3281100 4.47 6 0 586 87 0 0 0.00% 0 0 0.00% 从上表得知有可能是BCCH载频吊死,尝试重启BCCH载频后都能在NT11931小区发起呼叫,现场反馈也表示能正常占用,且统计指标正常,如下表: 小区 日期 时间 TCH试呼次数 TCH指配成功次数 SDCCH试呼次数 SDCCH话务量 接入成功 接入失败 SDCCH信道分配次数 SDCCH分配成功率 NT11931 2007-03-29 09: 00: 00 497 204 3242 2.65 3148 94 3148 96.86 NT11931 2007-03-29 10: 00: 00 473 151 3241 3.07 3231 10 3231 95.82 NT11931 2007-03-29 11: 00: 00 426 139 3309 2.90 3299 10 3300 96.79 NT11931 2007-03-29 12: 00: 00 438 161 4016 3.71 4001 15 4000 96.10 NT11931 2007-03-29 13: 00: 00 336 129 4058 3.60 4058 0 4058 95.96 4.6干扰引起用户投诉掉话 投诉问题: 横向芦村用户投诉掉严重。 问题分析: 掉话是网络优化中最难解决的问题,掉话产生既与无线网络有关,也与交换网络有关,但发生在无线网络的掉话占绝大部分的比例。 无线掉话有弱信号掉话、质差掉话、TA掉话、突然掉话。 但处理的方法很多,一般根据掉话的类型采取不同的方法,但发生掉话根本的原因有: 信号强度太弱、信号质量差(频点及外部干扰)、切换拓朴不合理、基站硬件故障等。 根据横向芦村反映的用户情况,实地核实覆盖小区为NT11633,收集统计发现掉话较高主要是突然掉话和上行质差掉话,如下表: 小区 日期 时间 TCH话务量 TCH掉话次数 TCH话务掉话比 SDCCH掉话次数 上行或下行质差掉话 TA超时掉话 突然掉话 上行弱信号掉话 下行质差掉话 上行质差掉话 NT11633 2007-3-27 18: 00: 00 2.98 20 8.93 3 0 0 18 1 0 1 NT11633 2007-3-27 19: 00: 00 4.12 60 4.12 8 0 0 48 0 0 12 NT11633 2007-3-27 20: 00: 00 4.52 43 6.31 13 0 0 31 0 0 12 NT11633 2007-3-27 21: 00: 00 2.17 49 2.65 1 0 0 49 0 0 0 NT11633 2007-3-27 22: 00: 00 3 27 6.66 0 0 0 24 0 1 2 突然掉话的原因比较复杂,用户行为、硬件、传输和切换等都可引起突然掉话;但质差掉话就有可能是同邻频干扰、XX台之间的干扰、交调干扰等。 ERRLOG统计无告警,从MOTS统计看掉话在每个载频上都有TS中断的现象(如下表),且已更换过载频,由此推断有可能是传输或干扰引起。 TS 日期 时间 尝试连接次数 异常中断次数 异常中断率(%) NNBSC20/RXOTS-105-0-0 2007-3-27 19: 00: 00 235 4 1.7 NNBSC20/RXOTS-105-0-1 2007-3-27 19: 00: 00 57 3 5.26 NNBSC20/RXOTS-105-0-2 2007-3-27 19: 00: 00 63 0 0 NNBSC20/RXOTS-105-0-3 2007-3-27 19: 00: 00 82 3 3.66 NNBSC20/RXOTS-105-0-4 2007-3-27 19: 00: 00 88 12 13.64 NN
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 最新 完美 投诉 处理 流程 案例 分析