串话单通问题分析和解决方案.docx
《串话单通问题分析和解决方案.docx》由会员分享，可在线阅读，更多相关《串话单通问题分析和解决方案.docx（19页珍藏版）》请在冰点文库上搜索。
串话单通问题分析和解决方案
概述
针对最近河南网络出现的一系列与话音质量有关的问题，主要表现为单通/串话等问题，我们认为这个问题应该不是一个简单的原因造成的，很有可能是由于交换、无线等各种因素综合作用而产生的结果。
从MOTOROLA公司在各地处理单通/串话等问题的经验来看，问题原因分布情况基本是这样的。
除去复测正常部分，MSC和长途，手机终端占大约50％-60%比例，属于BSS无线侧原因占大约40%-50%比例，主要体现在网络中硬件问题，直放站，载频，基站，KSW板，分布系统，弱覆盖，外部干扰等原因。
所有发现的问题都是可以得到有效的解决的。
解决这类话音问题，MOTOROLA公司已经积累了相当的经验，也制定出了一个比较科学的流程。
希望能和河南移动公司网络部积极配合，准确定位故障现象，发现问题产生的原因。
下面首先介绍一下我们在某地处理单通、串话问题的经验，供大家参考。
1.2005.12－2006.2月份1860单通/串话投诉分析
某地在2005年下半年投诉网络话音问题严重，通过近3个月的1860单通/串话投诉原因分析和排查，投诉从12月份的88起降低到2月份的14起，减少84%。
由此可见，经过多方精诚合作，网络中的单通、串话问题是可以得到有效控制的。
从产生单通串话的原因看，除去复测正常，MSC，传输和手机终端占大约50％-60%比例，属于BSS无线侧原因占大约40%-50%比例，主要体现在网络中硬件问题，直放站，载频，基站，KSW板，分布系统，弱覆盖，外部干扰等原因。
需要说明的是，出现单通/串话投诉复测正常可能会占到50%以上的比例，但这不代表就一定没有问题。
在我们处理的故障中就有这样的例子，初次测试没有问题，但投诉依旧。
经过调动大量测试人员进行现场测试，同时挂表进行信令跟踪和监听，最终找到了是直放站的问题。
经厂家的解决后，彻底解决了该地区单通/串话问题。
1.112-2月份单通/串话对比
从下表中，可以看出从2005年12月份到2006年2月份，单通/串话问题投诉的次数分别为44->19->9次；现场复测正常的次数分别为44->18->5次。
1.2单通/串话投诉原因分类
从产生单通串话的原因看，除去复测正常，MSC，传输和手机终端占大约50％-60%比例，属于BSS无线侧原因占大约40%-50%比例，而这部分绝大部分都可以通过常规的无线优化方案进行解决。
2.单通/串话具体问题分析及其解决方案举例
对1860单通/串话的投诉，我们进行问题的分析和定位，同时进行现场的拨打测试。
我们认为，造成单通串话的主要原因可以分成两大类：
网外原因和网内原因。
2.1网外原因
a.发生在移动和其他运营商间通话。
可能是各个长途电路局之间的电路故障和数据故障。
b.移动和接口运营商间数据协商故障。
c．网络投诉原始记录不够详细，此类问题较难统计。
d.大部分非网络原因的单通无声投诉均测试正常，可能没有真实模拟用户和外网通话情况而没有发现问题。
2.2网内原因
a.交换原因：
交换机和BSC之间，交换机和汇接局、智能网设备之间、彩铃服务器之间的配合协商或第三方设备故障等引起的原因
b.无线原因：
由于无线设备、无线环境方面引起原因，下表是主要无线原因和解决方案举例：
投诉地点
问题原因
解决方案
世贸大厦A座写字楼
载频PB低,BER高
更换载频
频率干扰
修改频点
市公安局4号楼
直放站
整改直放站
省移动公司
参数设置不当
优化数据库参数
曙光路外东山弄
弱覆盖
安装直放站加强覆盖
BSC04-BTS22
BSS/[47]/Circuit_Fault_Detected_On_PATH_Channel和[39]/Circuit_Fault_Detected_on_Radio_Channel告警
更换基站MCU板
BSC68
BSS/[43]/CircuitFaultDetectedonPCMCircuit
更换MSI板
3.近期单通问题SR总结
3.1SR2077618
经过路测确认，单通问题发生在一块固定的CTU2模块上，执行INS操作后问题消失。
我们已经与硬件（hardware）和固件（firmware）部门进行了讨论和研究，决定从固件firmware入手，收集相关数据加以分析，以断定是硬件还是固件的问题。
附数据收集步骤。
此数据要求在问题发生时收取。
3.2SR2086720
单通问题出现在一个固定基站下，此基站是一个室内分布系统。
经过现场测试，此次单通问题与基站设备无关，而是由于室内分布天线系统造成的，现已经由天线厂家解决。
4.鹤壁近期单通问题测试总结和故障原因分析
为了更清楚的描述鹤壁濮阳出现的串话投诉问题，我们将收集到的比较详细的串话投诉汇总一下，包括现场现象详细描述和分析的可能原因：
第一、6月3日晚1次投诉
投诉现象：
用户A作主叫在“蔡庄”基站，用户B作被叫在“蒋村”第1扇区，双方在21:
39:
56建立正常通话；
用户C作主叫在“蒋村”第1扇区，用户D作被叫在浚县县城（联通号码），双方在21:
39:
56建立正常通话。
通话1分钟后，用户A与用户C竟然直接对话，而原来2个正常通话都中断。
投诉分析：
“蔡庄”基站在鹤壁北部边界，与安阳汤阴县接壤，它本身在BHB11，是BHB11、BHB13、BHB14的交界处。
“蒋村”基站在鹤壁南部边界，与安阳滑县接壤，它本身在BHB14，是BHB11、BHB12、BHB14的交界处。
检查当时的SWFM和EVENT_LOG，CNRC没有发现异常现象。
从GI上看也不存在同频同BSIC问题。
但由于这2个基站所处位置的特殊性，我们分析认为这次串话应当与切换有关，尤其是BSC之间的切换。
第二、6月20日上午2次投诉
投诉现象：
用户A作主叫在鹤壁移动1楼营业厅，用户B作被叫在营业厅对面的博物馆，中间仅隔着一条马路，双方在12:
08建立呼叫，电话接通时，被叫B首先听到的是第三人的声音，大约3秒钟后恢复正常通话；
用户C作主叫在郑州，用户C作被叫在鹤壁移动2楼办公室，双方在14:
08建立呼叫，电话接通时，被叫C首先听到的是第三人的声音，大约5秒钟后恢复正常通话。
投诉分析：
通过对2次通话的通话清单和A口信令分析，发现2次投诉有共同点：
这3个鹤壁手机都是处于“移动公司”基站的覆盖区域，但是在刚接通的瞬间，都发生了频繁的BSC内部切换，涉及到的小区有5508（移动公司基站）、5526（信用联社基站）、5554（市政府基站）。
通过这2次投诉分析，我们更加确定串话与切换有关，切换是串话发生的必要条件，但不是充分条件。
第三、6月20日晚上5次投诉
投诉现象：
用户6月20日晚上投诉在鹤壁老区奔流街中段1小时内遇到5次串话，这次串话比较有代表性，是目前投诉最密集的地点。
通过与主被叫客户逐个联系并详细询问，通过NOKIA工程师对通话清单的认真分析，我们基本上搞清了这5次串话的详细特征：
时间
主叫
被叫
主叫位置
被叫位置
主叫起呼小区－>结束小区
被叫起呼小区－>结束小区
clear_code值
备注
20:
57
鹤壁老区公园八角亭
鹤壁老区奔流街中段
35513－>35513
25556－>15501
B13:
RadioInterfaceFailure
通话3分钟后串话主叫听不清第三个声音，被叫听清第三个声音在说：
“刚才还说话好好的，现在怎么不说了？
”然后过了4秒左右主被叫都听到“您拨打的号码无法接通”自动挂机
21:
09
鹤壁老区公园八角亭
鹤壁老区奔流街中段
35513－>35513
15501－>15501
B1A:
BSSMAPprotocolerror
21:
20
1860
鹤壁老区奔流街中段
郑州
25556－>15501
B13:
RadioInterfaceFailure
21:
24
1860
鹤壁老区奔流街中段
郑州
15501－>15501
B13:
RadioInterfaceFailure
21:
52
1860
郑州
鹤壁老区奔流街中段
1860证实发生串话，但没有查到话单
投诉分析：
（1）通过EVENTLOG，我们明显可以看出15501扇区的载频DRI07在6月20日晚21:
35:
07～21:
37:
35近3分钟的时间里，出现了告警并发生自动重启现象，可以确定这种现象会导致掉话产生，影响手机用户通话质量。
（2）通过PM统计指标明显可以看出，15501在6月20日晚21:
00～22:
00时段的掉话明显升高，掉话总次数达到66次，是平时正常值的30倍左右，全网最高；MA_FAIL_FROM_MS统计值比平时正常值要高出1倍；INTRA_CELL_HO_RETURN统计值比平时正常值也高出1倍之多。
总之PM指标表现异常变差。
因此，从以上2点的异常情况看，这5次串话应该与载频自动重启有因果关系。
摩托罗拉从接到该CASE至今所作的努力：
（1）在CNRC的建议下，进行了BSC/XCDR的TDM主备用倒换和MSC的主备用倒换；
（2）收取串话发生时的SWFM和EVENT_LOG，CNRC对其进行分析；
（3）与MSC对参数，与安阳参数设置进行对比；
（4）配合客户进行现场拨打测试；
（5）成立了远端技术支持小组专门处理串话问题；
（6）147258动员；
（7）检查RCI告警（circuitfaultdetectedonpathchannel/radiochannel/PCM），鹤壁现网很少几乎没有；
（8）检查时钟同步问题，没有发现失锁基站或RXCDR、BSC；
（9）对比鹤壁濮阳与安阳的Feature，确实各不相同，但CNRC确定不会因为缺少某一项CODE而导致串话，否则投诉量肯定很大很大；
（10）检查“TRAU帧同步丢失”告警，有但是与串话发生的时间不对应，有的投诉时间根本没有；
（11）将BHB11、BHB13的所有基站在7月7日晚上进行了重启。
鹤壁濮阳串话投诉现象汇总：
现象1：
双方正在通话突然出现第三方声音，但只有一方（主叫或被叫）能听到，而且原通话还可以正常进行；
现象2：
双方正在通话突然出现第三方声音，只有一方（主叫或被叫）能听到，但原正常通话中断，听到串话者与串话人不能通话；
现象3：
双方正在通话突然出现第三方声音，只有一方（主叫或被叫）能听到，原正常通话中断，但听到串话者与串话人能通话到主动挂机。
现象4：
被叫方刚一开始接听时，听到的是第三人的声音，三方都不能正常通话，但经过5秒左右主被叫双方又能正常通话，直到挂机结束没有再遇到串话。
现象5：
双方通话3分钟后主被叫同时听到第三个人的声音，双方正常通话中止，4秒钟后主被叫同时听到“您拨打的号码暂时无法接通”，然后自动挂机。
MSC上查通话清单发现通话终止的原因值不是正常释放而是“无线接口失败”或“BSSMAP协议错误”。
5.现场处理单通/串话问题测试流程
5.1处理流程示意图
5.2处理流程详解：
1．1860接到用户单通、无声或串话的投诉后，应尽量询问到下列详细信息：
a．所处位置
b．电话另一方所处位置
c．主叫无声还是被叫无声
d．问题出现的频率
2．在获得上述信息后，立即通知移动公司维护人员及摩托罗拉相关人员，以便及时组织人员进行现场路测。
3．对1860的单通投诉进行汇总，并结合现场测试结果确定单通发生的范围是在：
a．集中在某个特定的基站下
b．集中在某个BSC/RXCDR下
c．集中在某个MSC下
d．集中在某特定局向：
如CMCC－UNICOM，TELECOM－CMCC，......
4．如果发生在某一基站下，首先查看EVENT历史记录有无RCI告警，如：
39.BSS:
CircuitFaultDetectedonRadioChannel
告警会给出详细信息，如：
RCIFaultforRCI1234
BTSSite2
DRIID030
DRITimeslot4
尝试更换相关硬件，依次包括：
a．载频
b．NIU
c．T43
d．MCU（F）或SC
e．BSC侧的MSI
5．如果基站上无告警，则要通过拨打测试来断定问题所在：
a．集中在一块或多块特定载频，请先收集VCAT数据（具体收集方法另行说明），然后执行INS操作或更换载频。
b．集中在某一小区的全部载频上，请检查天馈线（分布式、直放站）系统、覆盖及干扰情况。
c．集中在某一条传输上的RTF上，请检查传输是否连接正确及有无接触不良问题。
6．如果单通发生在某一个BSC下的多个基站，则问题应该出现在BSC和RXCDR侧。
首先查看EVENT历史记录确定是否存在CIC相关的告警，如：
#0-NOTAPPL-*NONE*.
communicationFailureEvent-BSS-BSS11（BSS11:
SITE-0:
）:
0BSS0-16/09/200515:
42:
21.
[43]CircuitFaultDetectedonPCMCircuit-FMIC-Investigate-/-.
CIC#661
通过MMI命令确定CIC的物理通路，然后更换相应板件（MSI/GDP/XCDR）：
在BSC,
state0cic
disp_conn
disp_eq0cic
disp_mms_ts_usage0
在RXCDR,
disp_conn
disp_mms_ts_usage
disp_eq0cic
7．在BSC和RXCDR分别查看有无KSW/TDM告警，如有应先进行排除，然后执行SWAP0TDM以确定是否是为TDM硬件造成的单通。
8．检查数据库CIC配置是否有错，并尝试在BSC侧INS相关AXCDR，以排除可能的软件故障。
目前CNRC正在对软件可能性进行详细调查，稍后会与杭州移动沟通进展情况。
9．如果没有CIC和KSW告警，请使用仪表分别对A接口、Ater接口对所有CIC进行逐一监听，以确定出问题的CIC，然后更换MSI/GDP/XCDR板，并检查XCDR－MSC、BSC－XCDR之间的电路鸳鸯线、接头阻抗大等。
10．如果问题发生在特定局向，请确定无声问题具体发生在上下行那个方向。
如从MSC侧来的下行链路无声，则问题应该不在我们BSS侧。
如果上行无声则根本不会固定在特定的局向，请参考上面的步骤予以排查。
11．如果是一个MSC下的多个BSC产生单通现象，可对所有BSC逐一采用上面6到9步进行排查。
同时应该在MSC侧也开展调查。
12．如果不同MSC下的BSC都出现单通，除了对相关BSC和MSC进行调查外，还应检查MSC之间电路的配置和连接是否正常。
5.3注意事项
单通，无声和串音的故障属于比较难预防的故障。
但是，我们认为，做好以下的工作，可以及时预防故障出现：
∙及时收集和处理告警（MSC，GDP，RCI，CIC，KSW传输等告警）；
∙统计分析（是否有TCH占用时间十分短的小区）；
∙话单分析（是否有占用时间很短的CIC）；
∙新加CIC电路先测试好在开通；
∙新入网的网元严格按照ATP进行测试，保证每一个CIC的完好。
另外，如果发现单通问题，请及时与摩托罗拉河南分公司及CNRC联系，我们会提供必要的帮助并尽最大努力来解决现网中的单通故障。
6.123456行动内部单通投诉处理流程
1、在鹤壁、濮阳的各个BSC中。
在每个BSC的L3下输入：
connection_code“123456”
2、在收到同事的单通、串话、无声的投诉后，根据所附列表，详细记录投诉现象。
表格如下：
3、根据同事的投诉信息，在该BSC下的SWFM中查找该投诉的nonfault信息。
并记录所附列表信息。
表格如下如：
查找信息步骤如下：
A、通过投诉信息查找到该区域的BSC。
如果没有在该区域的BSC下找到相关SWFM信息。
则到该区域的相邻BSC下查找。
B、登到该BSC下BSP的EMON中。
用命令swfmra查找出投诉者在输入123456是出现的nonfault消息。
该消息格式如下：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
SWFMLogEntry91
555NonfatalSWFMErrorRoutine:
CallResourceInformation
555Area:
0x00008000Error:
0x00000000PC:
0xc003ba3ePID:
0x40（SMBSC）
555BSSRelease:
1.7.6.f0.36ObjVersion:
1.7.6.17.2ExecVersion:
1.7.6.17.1
55507-Feb-200611:
11:
20.070Subsystem:
0x01CPU:
0x0119Board:
GPROC3RAM
555
555STATICCallInfo
555----------------
555
555RCIID:
0x040b0104
555LocalCell:
4
555LocalCarrier:
11*该站的DRI号，从第一扇区开始计算
555（Sub）channel:
1
555AirTimeslot:
4*该载频的TS
555CICID:
0121*本次通话的CIC号，16进制
555CallOrigBTS:
31*通话的基站号
555
555MSC-BoundBSCMMSInfo
555----------------------
555MMSID:
160*BSC到RXCDR间的传输号
555MMSTimeslot:
12TDMTS0x0189*该条传输上的TS
555MMSBitNum:
4
555
555BTS-BoundBSCMMSInfo
555----------------------
555MMSID:
170*BSC到BTS间的传输号
555MMSTimeslot:
12TDMTS0x0187*该条传输上的TS
555MMSBitNum:
0
555
555
EndoftheNONFATALSWFMqueue.
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
C、通过以上信息，添写完上面的表格（注意在检查CIC时，需关注该CIC所在的MMS在投诉时的前后时间内有无状态变化，比如有无复位过、MMS是否处在故障状态等），如果发现该CIC所在的传输状态有所改变，说明该CIC号有可能飘移。
则需在旁边标注。
而对SWFM中查找出的CIC、MMS中TS也需要求发工单监听。
4、记录人员要求MOTOROLA工程师检查涉及到的硬件告警，并跟踪检查情况。
这些硬件信息包括：
涉及到的DRI、Abis口MSI、Ater口MSI、A口MSI、RXCDR的DSW等单通告警。
告警列表要附在记录的EXCEL表上。
5、记录人员要求河南移动/MOTOROLA安排相关人员现场测试，并跟踪测试结果。
测试要求为：
提交A口跟踪建议给交换机工程师，要求在A口跟踪测试人员消息。
尽量模拟投诉人员的拨打情况（比如双方的位置）。
要求完成问题小区的每个载频拨打测试。
问题载频的每个TS拨打测试。
并且在现场模拟用户正常通话不少于20次。
6、记录人员发检查工单给HNMCC，要求HNMCC监听涉及到CIC通话情况。
并跟踪
7、HNMCC监听结果。
要求提交给HNMCC的监听工单包含Abis口、Ater口、A口上MMS的TS。
及相关CIC。
工单要求HNMCC协助完成每个问题点的TS监听。
8、根据调查结果，记录人员完善EXCEL表格。
并在每周把记录表格定期发给全组优化人员。
9、记录EXCEL表格如下：
7.交换机超短话单检查
当用户在发生单通、无声或串话等问题时，由于不能正常完成通话，所以一般都是喂几声后就挂断电话了，所以这样的通话一般都只能维持几秒钟。
由于信令上正常，所以都会正常计费，只是话单显示通话时长很短。
通过这个特点，我们可以考虑从交换机超短话单入手，找到这些话单，并从话单中读取重要信息，以便我们排查问题。
下面是一个典型话单的例子：
首先我们可以根据经验尝试设置话单时长门限（4秒～7秒），从滤出的话单中我们可以找到对应cellid,BSCCIC，TKGCIC，然后再检查相关无线和交换设备，可以得到良好的效果。
8.1860投诉工单调整建议
现在的1860投诉记录已经对投诉人的联系方式、投诉时间、投诉地点、投诉用户的级别、投诉要求解决时间、问题类别、及投诉问题的内容都已经做了详细的记录。
投诉问题的解决流程也比较完善。
我们对1860投诉的记录建议仅站在后台系统优化工程师的角度，希望前台的1860投诉受理人员尽可能的从投诉客户哪里获取更详尽的信息。
从方便后台维护、优化工程师问题判断和处理、并为今后问题的总结和归类提供依据。
从而可以有效的避免类似的问题和故障发生，减少系统的故障率、提高客户的满意度。
从客户投诉中，只有用户投诉有关手机拨打、通话方面的问题。
都直接记录下面的信息。
在完成记录信息后，1860客服人员根据客户初步描述选择问题归类。
●时间：
●地点：
●故障号码：
●手机机型：
●对方号码：
（如果不提供可记录一下对方是市话、小灵通、联通手机、外地手机、、、等）
●信号强度：
好不好差
（根据手机信号几格来描述）
●是否经常出现：
是否
●周围朋友情况：
●预处理情况：
●问题分类
附件1.1860投诉工单建议表格
升级会员 