无线网络疑难投诉案例分析

上传人:pu****.1 文档编号:553929717 上传时间:2023-08-25 格式:DOCX 页数:6 大小:126.01KB
返回 下载 相关 举报
无线网络疑难投诉案例分析_第1页
第1页 / 共6页
无线网络疑难投诉案例分析_第2页
第2页 / 共6页
无线网络疑难投诉案例分析_第3页
第3页 / 共6页
无线网络疑难投诉案例分析_第4页
第4页 / 共6页
无线网络疑难投诉案例分析_第5页
第5页 / 共6页
点击查看更多>>
资源描述

《无线网络疑难投诉案例分析》由会员分享,可在线阅读,更多相关《无线网络疑难投诉案例分析(6页珍藏版)》请在金锄头文库上搜索。

1、无线网络疑难投诉案例分析摘要:对无线网络投诉中质量类疑难投诉进行了分析,主要对话音拥塞、掉话和串话的疑难案例进行了探 讨。关键词:无线网络 质量类 话音拥塞 掉话 串话随着通信行业的竞争愈发激烈,各大通信公司都在努力提高网络水平,开拓新的业务, 但客户是企业的生命所在,让客户满意,以市场为导向,以客户为中心,才是经营的根本, 提高服务水平,及时有效的处理好用户的投诉问题一直受到大家的重视。移动公司一直以来 的宗旨是“追求客户满意服务”,通过不断的努力开展技术,采用各种手段来解决用户的困 难。在无线网络类的投诉中,掉话、话音拥塞、通话杂音以及串话单通等问题均属于质量类 投诉,这部分投诉一直是较难

2、处理的部分,本文将选取这类投诉中部分疑难的案例进行分析 探讨。1. 话音拥塞及掉话案例分析1.1. 投诉问题简介有用户投诉近期在某道路附近拨打电话困难,经常不能打出或者打进电话。通过检查话 务统计发现用户投诉区域的某一基站的确存在话音拥塞的情况,而且掉话也很严重,检查该 基站本身无基站故障,而且该基站周围也没有其它基站退服情况,因此排除了由信道退服导 致的话音拥塞的原因以及由基站故障导致掉话的原因,进一步检查发现该基站试呼次数要远 远大于 TCH 指配成功次数,一般都要在 10 多倍以上,这样的指标是很不正常的。从掉话原 因上看,该基站的掉话绝大多数为突然掉话类型(爱立信将掉话时 BSC 收不

3、到手机上行的 统计报告的掉话都归为突然掉话类型)。1.2. 问题疑难点通过数据分析初步判断为该地有大量集中的用户群导致此处拥塞和掉话,可是现场测试 结果并非如此。在投诉区域测试人员进行了拨打测试,在测试中未发现掉话现象,但该处确实存在话音 拥塞严重的情况,因此测试人员对该基站覆盖的企业和校区进行了测试和走访,通过测试发 现该基站覆盖的企业和校区主要为某科技园、某电子公司和某中学,路测结果是该区域覆盖 场强和话音质量均良好,无掉话发生,测试情况如图 1 所示:J二IMrNS1L1 Jf FLMQLyJB眞STLEB?刖匚51阳话音质量测试图场强测试图 0 S3(IZI) 3 壬岸(1:30)占至

4、Bi細点至丁g HftifilCZI7 /图 1 投诉区域路测图通过询问了解到这些地区并未有明显的掉话现象发生,而且员工在公司多使用固定电 话,同时在测试时段学校正是放假期间,未见有学生在校园里,这就与该地区话音拥塞和指 标上高掉话的现象完全不符。1.3. 问题处理由于未能从现场找到问题原因,因此决定在A 口(MSC与BSC连接端口)挂表分析信令, 找到占用该基站信号并掉话的电话号码,通过对用户进行回访进而找到掉话的区域,再进一 步找寻掉话原因以及拥塞的原因。在该基站所在的BSC的A 口挂表之后,发现在上午,问题基站所产生的掉话绝大多数是 手机拨打1861客服免费电话引起的,在上午10: 00

5、11: 00的具体数据如表1所示。掉话次数拨打1861时产生掉话的比例拨打其它号码产生掉话的比例11896.61%3.39%表 1 手机掉话号码比例表通过对掉话号码的数据分析,可以发现部分号码拨打 1861 掉话的比例特别高,多个号 码在一个小时内拨打1861 掉话在10次以上。工作人员尝试拨打这些高掉话的电话号码,但 均不能接通。根据以往的经验,这种情况多发生在手机修理市场或手机厂家的维修人员拨打 客服免费服务电话进行故障手机测试时,不正常挂断手机导致大量突然掉话,而问题基站覆 盖范围内的某电子公司就是一个手机制造公司,因此怀疑该地区的掉话与该公司有关。在与该公司相关人员联系后,了解到该公司

6、在一周之前搬到此处,与问题基站掉话突然 增长的时间相吻合,同时还了解到该厂每天都要做生产手机的抽检工作,所用测试卡为移动 神州行号码,通过核对可以发现前面提到的多个高掉话号码正是其部分测试号码。选取其中 两个号码的相关数据,做出如下分析,见表 2(数据采样时间为 10: 0011: 00)手机号试呼次数拨打1861掉话次数CM拒绝次数号码11057827号码21059312表 2 高掉话号码话务指标统计表从以上数据可以看到,这两个做手机抽检测试的号码在一个小时之内(10: 0011: 00) 均试呼了 105 次,除了因拥塞被拒绝外,都发生了掉话,由这两个号码的数据可以认为是该 公司在手机检测

7、期间不断的进行拨打测试导致了该基站的话务量增长,发生话音拥塞现象, 同时由于其操作人员的非正常挂机导致了该基站的掉话严重。1.4. 总结分析由路测分析、A 口挂表测试、话务统计数据分析和了解的相关情况,可以认为该地区指 标上高掉话及话音拥塞的主要原因是此处的电子公司在对手机抽检时非正常挂机导致了基 站的掉话严重,同时该公司在工作期间频繁的拨打 1861 免费客服电话进行手机测试也增加 了基站的话务负担,给该基站造成话音拥塞。面对这样的情况,希望检测人员在手机检修中 不要直接拔手机电源,而要先按停止键,减少维修中由于用户行为原因而产生的掉话。2. 无法接通案例分析2.1. 投诉问题简介有用户投诉

8、在某大学附近电话难打,呼出正常,但无法接听电话,通过了解发现问题区 域范围不大,主要集中在某一基站附近。检查该区域的服务基站指标均正常,未有话音拥塞 或者信令拥塞的现象。2.2. 问题疑难点到用户投诉地点测试,发现投诉区域信号及话音质量均较好,主叫正常,但是被叫很难 接通,且主要集中在某基站的 A、 B 小区,根据这种情况,怀疑是此处的寻呼下发消息上出 了问题,检查该基站寻呼下发消息的统计数据,但是并未发现异常。在测试时,起初让主叫手机(记为MSI)占用该基站B小区信号,被叫手机(记为MS2) 占用该基站 A 小区信号,主叫手机进行了多次呼叫,但是被叫手机始终处于空闲模式,无 法进行正常通话,

9、网络提示“您呼叫的用户暂时无法接通”。进一步分析呼叫信令,发现在MS1主叫挂机前,MS2收到多条寻呼消息,两部TEMS 手机的呼叫信令如图2所示:|s Layer 3RE冥1-Injxll| SourceDfrettipnJSource.DirectionMessageDownlinkPaging Request Type 1 lM5tUplinkChannel RequestM52Downlink,Paging Request Type 1MSIDoKilinkImmediate AssignmentMS2Downlink.Paging Request Type 1M51DownlinkAu

10、thentication RequestM52DownlinkPaging Request Type 1M51DownlinkCiphering Mode Cnmmant-M52Downlink.Paging Request Type LM51UplinkCiphering Mode CompleteM52DowhlinkPaging Request Type 1UplinkSetupM52Downlink.Paging Request Type 1M51DownlinkIdentity RequestM52DownlinkPaging Request Type 1M51Uplink.Iden

11、tity ResponseM52Downlink.Paging Request Type 1M51Downlink匚日II ProceedingM32DownlinkPaging Request Type 1MSIDoKilinkAssignment Comm白ndMS2Downlink.Paging Request Type 1M51DownlinkProgressM52DownlinkPaging Request Type 1M51Uplink.DisconnectM52Downlink.Paging Request Type LM51DownlinkReleaseM52DowhlinkP

12、aging Request Type 1M51UplinkRelease CompleteM52Downlink.Paging Request Type 1M51DownlinkReleaseM52DownlinkPaging Request Type 1M51Uplink.Relsase CompleterV nr-is* T-1?|- iLl.1 lTH_J图2主叫及被叫手机第三层信令图(MSI为主叫,MS2为被叫)由测试信令可以看出,MS1的从起呼到挂机信令完全正常,但在MS1的呼叫过程中, MS2没有向网络发送“Paging response”消息,最终导致通话无法建立。通过仔细检查测

13、试 文件中的信令流程,发现在MS2收到的寻呼消息中,没有网络对MS2的IMSI号码发出的 寻呼指令,也就是说在MS1呼叫期间,由于MS2未收到对自己IMSI的“Paging request” 消息,所以MS2没有向网络发送“Paging response”消息,也就没有了之后的呼叫流程。2.3. 问题处理为何被叫手机无法收到对自己IMSI的“Paging request”消息呢?测试人员随之对拨打测 试过程进行信令跟踪,发现 MSC 对被叫手机的寻呼消息已经发送了,但是手机却没有收到。 检查小区无线参数,发现问题基站的A、B这两个小区的BCCH TYPE为COMB的类型。 我们知道移动台作被叫

14、时,MSC向同一 LAC内的所有小区发送寻呼命令,由各小区在PCH 信道上发出寻呼消息,其他过程与移动台主叫相同。在爱立信的设备规范中,当小区BCCH TYPE为COMB类型时,1BCCH+3CCCH位于TimeslotO,当小区BCCH信道使用NCOMB 类型时,1BCCH+9CCCH位于Timeslot。,因此,当小区其它参数相同时,使用COMB信 道类型时要比使用NCOMB信道类型时的PCH block数目少6个。这样使用COMB信道类 型时,单位时间内小区发送寻呼消息的数量要比使用 NCOMB 时要小很多,导致部分寻呼 消息未发送出。将这两个小区的BCCH TYPE改为NCOMB后,在

15、这两个小区的覆盖内进 行了多次拨测,均能正常接通。2.4. 总结分析爱立信设备R9以及之前的版本中,SDCCH信道的数目受到载频个数的限制,其最大 的数目为:载频数目X8 1。但可以通过设置BCCH TYPE为COMB类型,从而多增加4 个SDCCH信道,这样的参数修改通常发生在某一小区话音拥塞不明显而信令拥塞严重的情 况下,可以在不增加载频数目的同时增多SDCCH信道。但是多增加的4个SDCCH信道实 际上是占用是原来的PCH信道,这样在话务量很大的区域,对该类型的小区来说,由于PCH 信道的减少,导致了寻呼消息无法及时发出,部分寻呼消息就会丢失,从而出现本节提到的 在某小区覆盖范围内无法接通电话的问题。因此在话务量较高,寻呼次数较多的小区,即使 信令拥塞也不适合采

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 学术论文 > 其它学术论文

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号