109---CDMA网“被叫振铃后摘机听不到对方声音”问题的分析与解决.doc

CDMA网“被叫振铃后摘机听不到对方声音”问题的分析与解决陈晓明中国联通辽宁分公司运维部摘要：通过对CDMA网手机用户“被叫振铃后摘机无反映”的问题的分析，结合实际测试，跳出了通常情况下的无线环境恶劣导致接入失败或话务中继链路发生单通原因的惯常思维，发现了CDMA交换子系统存在与彩铃中心之间配合出现问题时对用户接听的影响，提出了具体解决方案。关键词：振铃 无反映 分析 解决作者简介：陈晓明，1965-09-17，男，大学本科。1987年毕业于复旦大学电子工程系，现任辽宁联通运维部网优中心主任。0引言：采用CDMA双待双模手机（三星W579）的VIP用户投诉其做被叫时，手机振铃一声、二声后就感觉掉线了或立即摘机后不论对主叫方还是被叫方都听不到对方声音，而且主叫多来自多个局向且来电显示正常。发生频率很低。该用户是智能网用户且开通了彩铃业务。该问题被提交到省运维部无线网优中心。1初步分析： 从用户双方之后的沟通来看：主叫方表示听不到任何反映后约十几秒后才释放的，被叫表示听到振铃后摘机听不到对方声音。由于主叫方听不到任何反映，但被叫却振铃了；说明并不是主叫手机由于无线环境恶劣长时间未能接入系统，因为只有系统接收到主叫手机的接入消息后才会寻呼被叫手机。而且被叫被寻呼到且无线信道和中继信道都已经分配给被叫手机，否则被叫手机不会振铃。因此根据规程要求“CRBT（即彩铃业务）适用于CDMA普通用户，也适用于CDMA智能网用户。当被叫用户为智能网用户时，只在对被叫寻呼的时候为主叫发送CRBT，所有的与智能网业务有关的业务交互流程已在对被叫寻呼之前完成。”说明与SCP的信令交互没有问题。问题重点应该是：为何主叫手机即未听到被叫的彩铃也未听到普通铃声？即便主叫手机未听到被叫彩铃，按照彩铃工作规范，在由于某种原因被叫端局与彩铃中心的信令交互出现问题时，应不影响正常信令和话务的接续。在被叫手机振铃后，可以听到被叫局的回送铃声。但实际上主叫手机并未能听到，为什么呢？2测试：我们因此进行了大量的实际随机测试，但一直未能发现此现象；证明该问题出现几率偏低。同时我们调出系统的呼叫测量报告PCMD（PER CALL MEASURMENT DATA），来分析当时手机呼叫时地小区信号情况。从报告上当时通讯记录看，出现此种情况的被叫在“呼叫结束原因”的标识代码均为“7”，即：主叫侧（无线及交换）的提前释放造成。同时对当时被叫手机所处无线环境进行了分析，从当时的EC/IO看，主被叫手机处于一个良好的无线环境中，且首次寻呼就已经寻呼到了，且不可能是刚一摘机一方就掉话。即可以排除无线侧的掉话因素。由于缺乏问题出现时的信令消息，我们再次采取大量拨打测试的方式，人为模拟如何能在PCMD报告出现“呼叫结束原因”的标识代码均为“7”的此现象，通过对测试呼叫进行信令跟踪，我们可以模拟出主叫方发起呼叫后，当被叫手机所在MSC发出寻呼消息并且得到了被叫手机的寻呼响应消息后，此时主叫方MSC的不明原因释放（对附图“g“之后到“m“之前的过程中），将导致此种现象的发生，与通过PCMD得到的结果一致。而由于主叫方来自其它局向，我们当时暂无法监控其信令消息，因此对主叫方的释放原因尚需进一步确认。主叫方未能听到被叫彩铃或普通回铃是否是因为局间中继产生了单通呢？我们对某次主叫是大连C网用户而被叫是该沈阳C网VIP用户也出现此类现象的情况安排了如下测试：对大连CDMA端局到省分T局（辽宁联通CDMA网各端局都是通过汇接局通过分群连接到彩铃中心）的话务中继进行了按时隙的测试，没有发现单通的现象。3实际信令流程与标准信令流程的对比：2007年1月某日，该手机做被叫时再一次发生了听到振铃无法接起来的情形。由于我们预先征得用户的同意对该手机进行了呼叫流程的跟踪，因此抓到了发生当时情形式的信令消息。下面是TRACE到的消息：（主叫与被叫在同一个局内），由于我省采用的是朗讯公司的CDMA设备，没有通常意义下的BSC，而是DCS、ECP、AP共同组成了呼叫处理单元及移动性管理单元。下面称其为交换子系统。在该交换子系统内可以TRACE到的也不是标准A接口消息，而是朗讯系统内部信令流程。通过对朗讯系统内部信令流程的分解分析可以了解到呼叫事件的接续细节。下面通过对跟踪到的信令消息的注释分析了当时接续的情形。首先；列出智能网用户被叫流程 SCP MSC/VLRb LOCREQ locreq HLR MSC/VLRa anlyzd ANLYZD LOCREQ locreq ROUTREQ routreq anlyzd ANLYZD TANSWER TDISCONNECT tdisconnect 在呼叫接续开始阶段，就体现了上述过程，见下面注释。 15:36:16.250 START被叫局接收到INCOMING CALL 15:36:16.250 Received MG_INCALL_S7X (ae) from DCS 16 Incoming call on TNN 16-1402-474 Sent MG_IMLOCREQ (5a01) to PCRID 2157 (86d)完成被叫摘机前与HLR及SCP的信令交互。参见上面智能网用户的被叫流程图。-正常 15:36:16.547 Received MGTCAP_RPLY (5a0c) from PCRID 2159 (86f) 15:36:16.646 MT410 (CPmt410) Signal - MSRSP CPWIN030 (CPwin030) Signal - TASK_BEGIN Sent MG_IMWIN (59e8) to PCRID 4157 (103d) 15:36:16.844 CPWIN040 (CPwin040) Signal - ITT_RSP MT410 (CPmt410) Signal - TASK_BEGIN Sent MG_IMLOCREQ (5a01) to PCRID 2157 (86d) 15:36:17.240 Received MGTCAP_RPLY (5a0c) from PCRID 2159 (86f) Incoming call on TNN 16-1402-474 to 1-333-24x-xxxx NOCINC (CPncinc) Signal - TASK_BEGIN MT000 (CPmt000) Signal - TASK_BEGIN Start normal mobile termination Sent MG_SETUP_S7X (af) to DCS 16（DCS应随即向彩令中心发IAI） Network/Cell TNN: 16-1402-474（LOOP ROUND） Candidate Trunk Group List: 1510 1511 （端局经T局中继到彩铃中心）1500 1501（端局经T局中继到其他局向） Called Party Number: 11111-333-24x-xxxx交换机发给彩铃中心IAI的同时，向SCP报告本次通话属性。 CPWIN250 (CPwinX50) Signal - TASK_BEGIN Sent MG_IMWIN (59e8) to PCRID 4157 (103d) （SCP） Operation Code: analyzed information DMH Redirection Indicator: call delivery local 15:36:17.636 CPWIN260 (CPwinX60) Signal - RAA_RSP MT000 (CPmt000) Signal - RETURN_TASK 对被叫寻呼成功并成功分配空中业务信道和声码器器处理单元。 Sent PAGE_C (8d) to CS 0 15:36:19.814 Received PGRSP_C (8e) from CS 180 MT030 (CPmt030) Signal - PAGE_RSP Sent TCSETUP_C (96) to CS 180 CDMA normal setup for EVRC on cell 180 15:36:19.914 Received MG_SH_ASGN_X (b6) from DCS 16 Assigned speech handler TNN 16-997-549 to the call Alert mobile with medium pitch long cadence （被叫振铃） Calling Party Number: 1-333-24y-yyyy (presentation allowed)（被叫振铃消息中带上主叫号码） 15:36:20.706 Received TCCONF_C (94) from CS 180 15:36:22.488 Received ANSWER (5a) from CS 180 （被叫摘机了） MT050 (CPmt050) Signal - CS_MSG ANSWER 将被叫摘机信息通知SCP。 Sent MG_IMWIN (59e8) to PCRID 4157 (103d) Transaction ID: none Component Type: invoke Operation Code: terminating answer 15:36:33.577 MT050 (CPmt050) Signal - TIMEOUT （在此消息之前，在Sent MG_SETUP_S7X (af) to DCS 16后约1S应有Received MG_CONNACK_X (6e) from DCS 16-该条消息是在DCS收到彩铃中心回ACM后发出的-但直至交换子系统15秒计时器超时未收到该条消息）送释放消息给基站 Sent FRCRLS (44) to CS 180 Sent FRCRLS (44) to CS 164 15:36:34.468 Received MURLS (5c) from CS 180 （响应前面基站释放REALEASE消息） Event Information: in-band information available Cause Indicator: (41) - Temporary Failure NOC600 (CPnc600) Signal - SUCCESS MTK400 (CPtk400) Signal - TASK_BEGIN 15:36:37.141 Received MG_DISC_X (70) from DCS 16 （手机接到系统的正常（不是掉话或切换失败）释放消息） Normal disconnect received on TNN 16-1402-474 Cause Indicator: (16) - Normal Clearing 15:36:37.240 MTK400 (CPtk400) Signal - DCSMSG MG_DISC_X NOC610 (CPnc610) Signal - DISCONNECT MDS080 (CPds080) Signal - TASK_BEGIN Sent MG_CLEAR_X (6b) to DCS 16 Clear request on TNN 16-0-0 (all trunks) Cause Indicator: (41) - Temporary Failure （但释放原因是一个临时错误（指未收到彩铃中心的回应） 15:36:37.438 Received MG_CLRACK_X (6c) from DCS 16 15:36:37.438 END (Total Duration 00:00:21.485)再比照下面的规范的彩铃业务呼叫处理流程：其中标准流程第h-j步：h：如果判断为CRBT用户，被叫用户的服务MSC向ORG MSC发出ACM；i： 利用来自VLR的Routing Digits发起设定与CRBT系统的通道，此过程中，被叫用户的服务MSC应同时设定和管理两个通道：被叫用户的服务MSC被叫终端，被叫用户的服务MSCCRBT系统。；j：CRBT系统向交换机回ACM；但从跟踪得到上面的信令消息中， DCS给彩玲中心发出IAI消息后，在15S内没有收到彩铃中心返回的ACM消息。这证明确实在端局和彩铃中心由于某种偶然因素使之间的信令交互出现了问题，因此主叫方未能听到彩铃。我们又在T局到彩铃中心的信令链路上挂表进行了监测，结果发现在T局转发280000次的IAI情况下有140次没有收到彩铃中心返回的ACM消息，概率占0.05%，应该是极小的概率。但为何在此时被叫用户已被寻呼到，并发出振铃声且被叫用户摘机时，主叫用户仍在等待彩铃中心的回应，因而无法进行正常的通话呢？。中国联通个性化回铃音业务交换子系统修改规范规定：交换子系统对各种相关故障的处理，应以返回发送普通回铃音处理流程为处理原则。在CRBT系统发生故障或中继线路全忙等问题发生时，MSC按照原有的回铃音处理方式来处理，所以不会对呼叫处理产生影响。即不发送CRBT，当被叫用户发回寻呼响应时送出一般的回铃音。但在此例中，没有送出一般的回铃音，说明被叫局交换子系统的相应修改不符合