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

无线网络疑难投诉案例分析摘要：对无线网络投诉中质量类疑难投诉进行了分析，主要对话音拥塞、掉话和串话的疑难案例进行了探讨。关键词：无线网络 质量类 话音拥塞 掉话 串话随着通信行业的竞争愈发激烈，各大通信公司都在努力提高网络水平，开拓新的业务，但客户是企业的生命所在，让客户满意，以市场为导向，以客户为中心，才是经营的根本，提高服务水平，及时有效的处理好用户的投诉问题一直受到大家的重视。移动公司一直以来的宗旨是“追求客户满意服务”，通过不断的努力开展技术，采用各种手段来解决用户的困难。在无线网络类的投诉中，掉话、话音拥塞、通话杂音以及串话单通等问题均属于质量类投诉，这部分投诉一直是较难处理的部分，本文将选取这类投诉中部分疑难的案例进行分析探讨。1. 话音拥塞及掉话案例分析1.1. 投诉问题简介有用户投诉近期在某道路附近拨打电话困难，经常不能打出或者打进电话。通过检查话务统计发现用户投诉区域的某一基站的确存在话音拥塞的情况，而且掉话也很严重，检查该基站本身无基站故障，而且该基站周围也没有其它基站退服情况，因此排除了由信道退服导致的话音拥塞的原因以及由基站故障导致掉话的原因，进一步检查发现该基站试呼次数要远远大于TCH指配成功次数，一般都要在10多倍以上，这样的指标是很不正常的。从掉话原因上看，该基站的掉话绝大多数为突然掉话类型（爱立信将掉话时BSC收不到手机上行的统计报告的掉话都归为突然掉话类型）。1.2. 问题疑难点通过数据分析初步判断为该地有大量集中的用户群导致此处拥塞和掉话，可是现场测试结果并非如此。在投诉区域测试人员进行了拨打测试，在测试中未发现掉话现象，但该处确实存在话音拥塞严重的情况，因此测试人员对该基站覆盖的企业和校区进行了测试和走访，通过测试发现该基站覆盖的企业和校区主要为某科技园、某电子公司和某中学，路测结果是该区域覆盖场强和话音质量均良好，无掉话发生，测试情况如图1所示： 场强测试图话音质量测试图图1 投诉区域路测图通过询问了解到这些地区并未有明显的掉话现象发生，而且员工在公司多使用固定电话，同时在测试时段学校正是放假期间，未见有学生在校园里，这就与该地区话音拥塞和指标上高掉话的现象完全不符。1.3. 问题处理由于未能从现场找到问题原因，因此决定在A口（MSC与BSC连接端口）挂表分析信令，找到占用该基站信号并掉话的电话号码，通过对用户进行回访进而找到掉话的区域，再进一步找寻掉话原因以及拥塞的原因。在该基站所在的BSC的A口挂表之后，发现在上午，问题基站所产生的掉话绝大多数是手机拨打1861客服免费电话引起的，在上午10：0011：00的具体数据如表1所示。掉话次数拨打1861时产生掉话的比例拨打其它号码产生掉话的比例11896.61%3.39%表1 手机掉话号码比例表通过对掉话号码的数据分析，可以发现部分号码拨打1861掉话的比例特别高，多个号码在一个小时内拨打1861掉话在10次以上。工作人员尝试拨打这些高掉话的电话号码，但均不能接通。根据以往的经验，这种情况多发生在手机修理市场或手机厂家的维修人员拨打客服免费服务电话进行故障手机测试时，不正常挂断手机导致大量突然掉话，而问题基站覆盖范围内的某电子公司就是一个手机制造公司，因此怀疑该地区的掉话与该公司有关。在与该公司相关人员联系后，了解到该公司在一周之前搬到此处，与问题基站掉话突然增长的时间相吻合，同时还了解到该厂每天都要做生产手机的抽检工作，所用测试卡为移动神州行号码，通过核对可以发现前面提到的多个高掉话号码正是其部分测试号码。选取其中两个号码的相关数据，做出如下分析，见表2（数据采样时间为10：0011：00）手机号试呼次数拨打1861掉话次数CM拒绝次数号码11057827号码21059312表2 高掉话号码话务指标统计表从以上数据可以看到，这两个做手机抽检测试的号码在一个小时之内（10：0011：00）均试呼了105次，除了因拥塞被拒绝外，都发生了掉话，由这两个号码的数据可以认为是该公司在手机检测期间不断的进行拨打测试导致了该基站的话务量增长，发生话音拥塞现象，同时由于其操作人员的非正常挂机导致了该基站的掉话严重。1.4. 总结分析由路测分析、A口挂表测试、话务统计数据分析和了解的相关情况，可以认为该地区指标上高掉话及话音拥塞的主要原因是此处的电子公司在对手机抽检时非正常挂机导致了基站的掉话严重，同时该公司在工作期间频繁的拨打1861免费客服电话进行手机测试也增加了基站的话务负担，给该基站造成话音拥塞。面对这样的情况，希望检测人员在手机检修中不要直接拔手机电源，而要先按停止键，减少维修中由于用户行为原因而产生的掉话。2. 无法接通案例分析2.1. 投诉问题简介有用户投诉在某大学附近电话难打，呼出正常，但无法接听电话，通过了解发现问题区域范围不大，主要集中在某一基站附近。检查该区域的服务基站指标均正常，未有话音拥塞或者信令拥塞的现象。2.2. 问题疑难点到用户投诉地点测试，发现投诉区域信号及话音质量均较好，主叫正常，但是被叫很难接通，且主要集中在某基站的A、B小区，根据这种情况，怀疑是此处的寻呼下发消息上出了问题，检查该基站寻呼下发消息的统计数据，但是并未发现异常。在测试时，起初让主叫手机（记为MS1）占用该基站B小区信号，被叫手机（记为MS2）占用该基站A小区信号，主叫手机进行了多次呼叫，但是被叫手机始终处于空闲模式，无法进行正常通话，网络提示“您呼叫的用户暂时无法接通”。进一步分析呼叫信令，发现在MS1主叫挂机前，MS2收到多条寻呼消息，两部TEMS手机的呼叫信令如图2所示：图2 主叫及被叫手机第三层信令图（MS1为主叫，MS2为被叫）由测试信令可以看出，MS1的从起呼到挂机信令完全正常，但在MS1的呼叫过程中， MS2没有向网络发送“Paging response”消息，最终导致通话无法建立。通过仔细检查测试文件中的信令流程，发现在MS2收到的寻呼消息中，没有网络对MS2的 IMSI号码发出的寻呼指令，也就是说在MS1呼叫期间，由于MS2未收到对自己IMSI的“Paging request”消息,所以MS2没有向网络发送“Paging response”消息，也就没有了之后的呼叫流程。2.3. 问题处理为何被叫手机无法收到对自己IMSI的“Paging request”消息呢？测试人员随之对拨打测试过程进行信令跟踪，发现MSC对被叫手机的寻呼消息已经发送了，但是手机却没有收到。检查小区无线参数，发现问题基站的A、B这两个小区的BCCH TYPE为COMB的类型。我们知道移动台作被叫时，MSC向同一LAC内的所有小区发送寻呼命令，由各小区在PCH信道上发出寻呼消息，其他过程与移动台主叫相同。在爱立信的设备规范中，当小区BCCH TYPE为COMB类型时， 1BCCH+3CCCH位于Timeslot0，当小区BCCH信道使用NCOMB类型时，1BCCH9CCCH位于Timeslot0，因此，当小区其它参数相同时，使用COMB信道类型时要比使用NCOMB信道类型时的PCH block数目少6个。这样使用COMB信道类型时，单位时间内小区发送寻呼消息的数量要比使用NCOMB时要小很多，导致部分寻呼消息未发送出。将这两个小区的BCCH TYPE改为NCOMB后，在这两个小区的覆盖内进行了多次拨测，均能正常接通。2.4. 总结分析爱立信设备R9以及之前的版本中，SDCCH信道的数目受到载频个数的限制，其最大的数目为：载频数目81。但可以通过设置BCCH TYPE为COMB类型，从而多增加4个SDCCH信道，这样的参数修改通常发生在某一小区话音拥塞不明显而信令拥塞严重的情况下，可以在不增加载频数目的同时增多SDCCH信道。但是多增加的4个SDCCH信道实际上是占用是原来的PCH信道，这样在话务量很大的区域，对该类型的小区来说，由于PCH信道的减少，导致了寻呼消息无法及时发出，部分寻呼消息就会丢失，从而出现本节提到的在某小区覆盖范围内无法接通电话的问题。因此在话务量较高，寻呼次数较多的小区，即使信令拥塞也不适合采用BCCH TYPE为COMB的方式。目前在爱立信R10的版本中，SDCCH信道的数目可以不受载频个数的限制，更方便优化人员进行优化调整。3. 串话案例分析3.1. 投诉问题简介用户反映在某小区内经常出现通话串线及听不到对方声音的现象。检查投诉区域内基站的指标及运行状态，未发现问题，各小区传输数据均定义正确，且没有发现传输误码和滑码。3.2. 问题疑难点在与用户联系上后测试人员对投诉位置开始进行拨打测试，拨打电话包括固定电话及移动电话，但没有出现串话现象，当再次拨打用户电话时出现串话现象，即在电话接通后测试人员听到的是陌生人的声音而不是投诉用户的声音，事后询问用户，他表示当时接通电话也听到的是陌生人的声音。随后决定在拨叫过程中进行信令跟踪测试，在投诉位置拨打测试号码20次后未出现串话现象，而且信令跟踪上也未发现异常。3.3. 问题处理目前的问题是在测试人员自己互拨时未出现串话现象，但拨打用户手机时却存在串话现象。通过比较，发现投诉用户为彩铃用户，而测试人员拨打的测试号码均无彩铃功能，因此将部分测试号码开通彩铃功能后，在投诉区域重新进行拨打测试，测试内容包括无彩铃手机与有彩铃手机间互拨，无彩铃手机间互拨及有彩铃手机间互拨，通过大量的拨打测试可以发现只有拨叫开通了彩铃功能的手机时才有可能出现串话现象。对其中一次串话现象记录如下：主叫： 0s 25s 30s 挂机 听到回铃音 一直处于无声音状态 听到背景音乐 听到陌生人的声音 手机显示被叫摘机 被叫： 0s 27s 挂机 震铃后接通电话 一直处于无声音状态 听到陌生人的声音通过以上测试，可以认为问题基本确定在彩铃系统上。对彩铃系统进行排查，发现是MSC到彩铃设备的两条传输线交叉错接导致串话发生，在正确接线后，故障消失。3.4. 总结分析导致串话现象的原因有服务小区存在硬件故障或数据定义错误，传输存在高误码，BTS参数设置不当导致上下功率差别过大等，但多数原因是传输中存在鸳鸯线。两对传输