关于CMSERVICEREJECT未接通的典型案例分析
关于CM SERVICE REJECT未接通的典型案例分析
问题描述：在近期的测试中，主叫手机占用到和田街客运站(39199-45451)小区呼叫因为受到严重干扰无线链路超时掉话，而被叫在很长一段时间内（主叫手机20s再次起呼）仍然处于专用模式下。
主叫手机掉话20s后重选到富丽华大酒店(39199-45291)再次起呼，系统下发“CM SERVICE REJECT”主叫未接通。
Reject cause：Message not compatible with the protocol state—
问题分析：相关资料对此次服务请求拒绝的解释如下：
因此怀疑此次未接通和无线侧没有任何关系，将相关信息发送给交换核查人员，得到的反馈为：主叫再次起呼的时候主被叫均处于专用模式下。
因此经推断分析，主叫下行无线链路超时要早于上行无线链路超时（可以理解为上行无线质量更加优于下行无线质量），主叫无线链路超时后释放信道，而上行网络侧并不清楚手机已经释放信道，仍然处于通话模式下，同时网络对RLT超时的设置为64（即64×0.48＝30.72s），即考虑最好的情况下，主叫下行
掉话后有可能BSC在30s以后才会向MSC发送强行拆链信息，交换侧释放信道。
主叫20s 以后再次起呼，因为网络侧仍然没有释放信道，故下行发送“CM SERVICE REJECT”，拒绝本次起呼。
综上，以上现象只能发生在无线链路超时掉话且上行质量优于下行质量，即主被叫无线链路超时严重不一致的情况下；同时，发生此种掉话必定会发生一次未接通，这对于集团公司测试的考核来说，大大放大了网络问题，对接通率是一个很大的考验。
因此控制干扰、改善网络无线质量是网络优化的重中之重。
CM_Service_Reject未接通问题分析
CM Service Reject未接通问题分析ATU测试发现CM Service Reject导致的未接通问题，拒绝原因为Message not compatible with the protocol state，经过分析，定位问题是前一次切换失败掉话IU还没来得及释放导致。
因为ATU测试呼叫间隔时间20S，切换超时定时器目前设置30s，切换失败掉话后，在下一次CM Service Request时，IU还没来得及释放，需要评估切换超时定时器设置。
【问题描述】在凫洲大桥桥底路段终端占用到13742_广州三姓围T2小区进行起呼，终端在发起CM Service申请时被网络拒绝后，造成主叫未接通。
【问题截图】图1：主叫前台截图图2：被叫前台截图图3：主叫前一次呼叫切换失败掉话截图图4：后台信令截图【原因分析】1、终端在凫洲大桥桥底由南往北行驶，主叫UE占用到13742_广州三姓围村T2<10063、45>小区进行起呼，PCCPCH RSCP在-74dbm，从测试情况看出，PCCPCH C/I和DPCH C/I值都比较好，如主叫测试图，在主叫呼叫过程中成功建立RRC连接后进行CM Service Request时被拒绝，造成主叫未接通。
2、分析主叫信令得出，主叫在发起CM Service Request后被拒绝，出现未接通，从层3信令看到拒绝原因为:Message not compatible with the protocol state（主叫业务申请与之前正在进行的业务发生了冲突被拒接,网络侧认为手机此时状态不适合发起呼叫）。
3、分析前一次呼叫发现主叫有掉话，查看后台信令，掉话原因IntraRNCHO_timeout(RNC内切换超时)。
具体信令过程是：网络侧下发切换消息物理信道重配置以后，没有收到UE上报的物理信道重配置完成信息，切换等待定时器T_HowaitCU（设置为30秒）超时，这是RNC才上报Iureleaserequest请求CN释放，计为掉话一次。
关于CMSERVICEREJECT未接通的典型案例分析
关于CM SERVICE REJECT未接通的典型案例分析
问题描述：在近期的测试中，主叫手机占用到和田街客运站(39199-45451)小区呼叫因为受到严重干扰无线链路超时掉话，而被叫在很长一段时间内（主叫手机20s再次起呼）仍然处于专用模式下。
主叫手机掉话20s后重选到富丽华大酒店(39199-45291)再次起呼，系统下发“CM SERVICE REJECT”主叫未接通。
Reject cause：Message not compatible with the protocol state—
问题分析：相关资料对此次服务请求拒绝的解释如下：
因此怀疑此次未接通和无线侧没有任何关系，将相关信息发送给交换核查人员，得到的反馈为：主叫再次起呼的时候主被叫均处于专用模式下。
因此经推断分析，主叫下行无线链路超时要早于上行无线链路超时（可以理解为上行无线质量更加优于下行无线质量），主叫无线链路超时后释放信道，而上行网络侧并不清楚手机已经释放信道，仍然处于通话模式下，同时网络对RLT超时的设置为64（即64×0.48＝30.72s），即考虑最好的情况下，主叫下行
掉话后有可能BSC在30s以后才会向MSC发送强行拆链信息，交换侧释放信道。
主叫20s 以后再次起呼，因为网络侧仍然没有释放信道，故下行发送“CM SERVICE REJECT”，拒绝本次起呼。
综上，以上现象只能发生在无线链路超时掉话且上行质量优于下行质量，即主被叫无线链路超时严重不一致的情况下；同时，发生此种掉话必定会发生一次未接通，这对于集团公司测试的考核来说，大大放大了网络问题，对接通率是一个很大的考验。
因此控制干扰、改善网络无线质量是网络优化的重中之重。
网络未接通问题点分析流程指导书
网络未接通问题点分析流程指导书一、路测未接通问题点产生机制未接通主若是在电话向系统发送呼唤请求，可是在呼唤进程中由于某种缘故，主叫或被叫电话没有分派到TCH信道，致使未接通。
路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应付的一个重要工作.在日常的测试当中, 咱们常常碰到各类各样的未接通情形。
缘故也是多种多样。
致使未接通的常见的缘故要紧有：被叫电话位置更新、主叫电话TCH拥塞、被叫电话TCH拥塞、主叫电话SDCCH拥塞、被叫电话SDCCH拥塞、SDCCH 掉话、呼唤号码错误、CIC 分派错误、寻呼失败。
从测试中主叫与被叫的信令流程分析，要完成一个完整的接续进程，一共有以下几步的信令流程：主叫的信令流程：MS BTS说明RACH Channel requestAGCH Immediate assignmentSDCCH CM service requestSDCCH CM service acceptSDCCH Authentication RequestSDCCH Authentication response（鉴权响应）SDCCH Ciphering commandSDCCH Ciphering completeSDCCH SetupSDCCH Call proceeding（进程、程序）SDCCH Assignment commandFACCH Assignment completeFACCH ProgressFACCH AlertingFACCH ConnectFACCH Connect acknowledgeTCH Speech被叫的信令流程：MS BTS说明PCH Paging RequestRACH Channel requestAGCH Immediate assignmentSDCCH Paging response（响应）SDCCH Authentic requestSDCCH Authentic responseSDCCH Ciphering commandSDCCH Ciphering completeSDCCH SetupSDCCH Call proceedingSDCCH Assignment commandFACCH Assignment completeFACCH ProgressFACCH AlertingFACCH ConnectFACCH Connect acknowledgeTCH Speech从上面的主叫和被叫的信令流程比较来看，被叫在互换机一侧以下几步流程，在无线上主叫比被叫多了PAGING 那个流程：E|GMSC -> HLR UDT(BEG(INV(Send Routing Info)))D|HLR -> VLR UDT(BEG(INV(Provide Roaming Number)))D|VLR -> HLR UDT(END(RES-L(Provide Roaming Number))) Roaming NumberE|HLR -> GMSC UDT(END(RES-L(Send Routing Info))) Roaming NumberA|MSC -> BSS UDT(Paging)在路测进程中，L3接续流程和故障判定流程：二、未接通问题点分析及处置方式致使未接通的常见的缘故将结合实际情形，依照信令流程，一步一步对未接通的缘故进行分析：1.channel request 拒绝channel request 拒绝在路测中很少碰到，若是小区被BAR （禁止）的情形下，会显现电话channel request 发送不出的现象。
未接通事件分析汇总
未接通事件分析汇总任琳一、定义：起呼：以channel request和CM service request同时出现来确定试呼开始。
接通：当一次试呼开始后出现了Connect，Connect Acknowledge消息中的任何一条就计数为一次接通。
未接通定义：以channel request和CM service request同时出现来确定一次试呼开始，当connect或Connect Acknowledge信令出现之前手机由专用模式转为空闲模式，计为一次未接通。
二、呼叫流程>Paging过程（仅用于被叫流程中）>RACH随机接入过程>SD立即分配过程>TCH建立过程Channel Request消息是通过_RACH___信道传送；Immediate AssignmentCommand消息在_AGCH___信道上传送；Assignment Command是在_SDCCH__信道上传送；Assignment Complete消息是在_FACCH___信道上传送；Handover Command消息是通过_FACCH___信道传送；Location Update Request 消息是在SDCCH____信道上传送；MC925F agch拥塞，修改BS_AG_BLKS_RES参数上调MC925H paging拥塞，修改BS_AG_BLKS_RES参数下调、BS_PA_MFRMS参数下调三、未接通原因分类：1、被叫位置更新2、被叫路由更新3、无线环境差，分配TCH失败4、无线环境差，分配SD失败5、TCH拥塞6、SD 拥塞Immediately Assignment Reject7、信令丢失四、异常事件案例：1、TCH请求放入队列中直到超时A、主叫手机在TCH发生拥塞, MS收到BSC下发channel release(cause: normal event)，MSC不会向被叫手机发送寻呼消息,因此被叫手机处于空闲状态。
关于CM SERVICE REJECT问题的分析
关于CM 业务拒绝问题的分析和优化山东移动通信公司济南分公司展俊云一、概述CM SERVICE REJECT消息在通信过程中的主要位置如下图：CM SERVICE REQUEST消息是MS和MSC之间信令流程（包括位置更新、主叫、被叫和短消息等）的第一个消息，该消息中包含了该次业务的类型等相关内容，但是在MSC收到该消息时，存在立即回复CM SERVICE REJECT消息的情况，并且其中包含该次CM SERVICE REJECT的原因，原因值为1个字节（即8BIT）,其原因值有如下：Test system;on ia mmm h'5934;on ia do:p pr0;p 20 l j,;MMREJECTCOUTACK该信号返回CM SERVICE REJECT的拒绝消息，该信号主要包含LU REJECT和CM SERVICE REJECT 2种类型的拒绝原因，可以依据不同的调转地址进行判断,在功能块mmmmh中。
CM SERVICE REJECT消息中拒绝原因是由MMM功能块负责，根据PLEX的解释对于Message type not compatible with protocol state 也就是原因值为ZMESSTYPENOTCOMPPROTSTATE98，根据指令执行的地址的不对于现网网络是否对每一种原因都存在呢？还是某一种比较多而其它的原因相对比较少呢？对此，通过如下的TEST SYSTEM指令进行跟踪分析：TEST SYSTEM;INIT;其MMM功能块的版本为：<lasip:block=mmm;SOFTWARE UNIT IDENTITYBLOCK BN BS FCODE IDMMM H'260 ACTIVE 7PHA/CAAZA 107 1356/MQRT R1A03END跟踪的结果示例如下：ON OUTSIGMMM (B) COMBSIG SSP=H'192 MMSENDMSGCB ON THLTO MMMMH (B) WITHH'0000 19B9, H'0000 6002, H'0000 19B9, H'0000 6002,H'0000 0022, H'0000 0001, H'0000 0000JAM PRINTOUTLEVEL BLOCK IATHL MMM H'24B5 H'2489 H'2485 H'246B H'2457 H'2453 H'242D H'2427 H'2414 H'23FC H'23F0 H'03C4 H'03B8MRRM H'2E39 H'2E31 H'2E25 H'2E25 H'0F16 H'0F07MSCCO H'1442 H'1428 H'1412 H'13FD H'01AD H'019AC7CO H'7A1A H'7A04 H'1884 H'187A H'A82B H'A81C H'1878END在6月2日13：45-14：45 一个小时的时间内，对JNGS21（R12版本）进行了跟踪分析，分析结果如下：由此可以看出：在CM SERVICE REJECT的消息中，Message type not compatible with protocol state原因的拒绝消息所占的比例达到96%，而根据前面对产生该类拒绝消息的原因中，MCCC NOT LINKED的原因为最多(也就是CALL HOLD OR MULTI PARTY HA VE NOT BEEN INVOKED用户的呼叫保持或多方通话没有被激活)。
IMSI UNKNOWN IN VLR导致未接通
IMSI UNKNOWN IN VLR导致未接通
【事件描述】
车辆由南向北行驶在丰谭路上，在丰谭路左转至天目山路路口处，主叫UE由亚洲城2(40701)重选至国力大酒店2(40262)，未能及时进行位置更新即起呼，造成CM SERVICE REJECT，cause为IMSI UNKNOWN IN VLR。
主叫路测截图
【事件原因】
该用户在其他的Server上做了位置更新，且HLR通知了本Server删除掉用户数据。
由于该用户没有在本Server上做位置更新，也就是说，本Server上是没有该用户的数据的，所以当该用户在本Server上发起呼叫时，核心网直接拒掉，拒绝原因值为”IMSI Unknown in VLR”。
【解决措施】
关于该问题，核心网的MAP功能配置里有个选项可以解决此问题：
该开关的说明如下：
使用的效果如下：
若将该参数设为“是”，则当移动用户向网络发起位置更新请求时，如果正常的由HLR执行的位置更新操作出现失败的情况，MSOFTX3000可以直接通过VLR继续执行位置更新流程。
确保了UE进行重新登记。
即：如果遇到”IMSI Unknown in VLR”的现象，则本次呼叫不会直接拒绝掉，而是由VLR发起一次位置更新，位置更新成功后，呼叫继续，确保了用户可以正常接入。
因此，该参数的修改是可以提高AMR和VP的接通率的。
注：此开关的打开只适用于华为的交换，此开关的打开可能会带来充值出错、串话的问题，此开关的打开要慎重，此可以在集团测试期间打开即可。
交换拥塞导致未接通问题分析报告
交换设备拥塞导致未接通问题分析报告问题描述：8月13日一8月15日期间，在路测中发现主叫呼叫建立成功后，CN 下发Disconnect(Cause_value ： (42)Switching equipment congestion 交换设备拥塞)导致发生 3 次未接通。
问题分析：1.乐山钟楼-2未接通发生时间：2012-8-1309:39:26UE 在乐山钟楼-2小区下完成 RB 建立后，CN 下发Disconnect ( Cause_value ：(42)Switching equipment congestion 交换设备拥塞)导致本次呼叫未接通。
从路测数据来看，当 时无线环境较好(PCCPCH RSCP=-45dbm,PCCPCH C/l=20db)。
具体路测信令如下图所示：2.岷江中街245号-3未接通发生时间：2012-8-1315:22:35UE 在岷江中街245号-3小区下完成 RB 建立后，CN 下发Disconnect(Cause_value ： (42)Switching equipment congestion 交换设备拥塞)导致本次呼叫未接通。
从路测数据来看，当时无线环境较好 (PCCPCH RSCP=-51dbm,PCCPCH C/I=19db)。
具体路 测信令如下图所示：IL F存ANfl 軒BR bl rr F qMJrsfle--HzM 斗工“眼酣刊聆时13朝罚r —穴ba:旺珂臥CiH«^Prf*K迪邸戡Hdt.i ikiMh CiW)j rCC"Q1 T ■曲 U JUJ ■*I J 1M ： WK *T M kitH■um d；l 」*^awE# MAH>£iKM|j FOCPOCirtlilion EE711 ICnflMffl3MI WRea*?倾丨一…dr Edr«nuiv.TKI^I ■aAWW■MiGlIflinipi-aa山£f T »1 W-M中e 和"inW B'1 * " ■ 1 1 r, I"「*■£.*ihE-h»l* - H E ・■ F*" r •」: I■< 1J Ji ?J B.—1-◎ =-*•建毡 a -ir 一 c 4'• I F 41 E 2 占« i.蠡広』R门■辖r 出w 吕豪■ ■ v園雷Aj — ： 4 ::: BH-n-k«»n^ljB9llra fajj ■* h-J L£ _L i.*JCH 歸f ：啤1J ^4MLtf hw*S*Ti4 •■ M 玛尸 * B 1*』(I0 \ ^Tste-J m ：y 4.' I:吐 m*「・■■an -^ w* 11黑赴■«i ：TtB i-i j. ：j■! (i)1 ”二+j.- I N 1b«,UE 在乐山卫校-1小区下完成 RB 建立后，CN 下发Disconnect( Cause_value ：(42)Switching equipment congestion 交换设备拥塞)导致本次呼叫未接通。
ATU掉话导致频繁未接通问题分析处理
1、问题描述：在7月ATU测试中曾经出现主叫在1次掉话后，连续发生3次未接通。
为了彻底分析问题原因，测试时通过ATU、BSC、MSC对Um口、ABIS口、A口进行信令跟踪，重现该问题并予以解决。
在本次异常事件中，终端首先发生了一次掉话，之后出现4次未接通。
在这4次未接通中都是在终端发了CM SERVICE REQUEST信令后，系统下发CM SERVICE REJECT消息，说明网络侧拒绝了本次呼叫，且此时CM SERVICE REJECT消息携带原因值为：Reject cause Message compatible with（可理解为消息不兼容或呼叫不能识别），具体原因是系统认为终端正在进行某项业务（比如通话或短消息等），此时不能发起呼叫业务。
由于当时终端没有短消息和彩信等其他业务，因此可以判断是系统认为终端在掉话后，没有正常拆线仍然保持通话状态。
2、问题解决方案：经分析，华为公司在BSC9.0版本下，为了减少掉话，在BSC向BTS发了Handover Command之后，如果在T3103超时前收到BTS上报的Error Indication，为了挽救本次通话，BSC继续在原信道上等待MS上报的测量报告，在被叫主动挂机后才会清除本次通话连接。
也就是说在这种情况下，BSC向BTS发切换命令后T3103超时，BSC会向MSC发Clear Request；BSC没有下发切换命令，收到了BTS的Error Indication，也会向MSC发Clear Request；但是BSC向BTS发切换命令后，在T3103超时前收到了BTS 的Error Indication，则不会向MSC发Clear Request。
具体解决方案可以通过设置小区保留参数1的0bit来解决，将该bit位由0改成1，这样BSC收到Error Indication或T3103超时后，BSC立即向MSC发送CLEAR REQUEST进行拆线。
未接通、掉话简析及案例分析
未接通、掉话简析及案例分析―范智浩目录1前言 (2)2路测指标分析 (2)3未接通 (3)3.1位置更新过程中的未接通 (4)3.1.1主叫位置更新引起的未接通 (4)3.1.2被叫位置更新引起的未接通 (4)3.2无线链路建立过程中的未接通 (4)3.2.1SDCCH拥塞引起的未接通 (4)3.2.2SDCCH掉话引起的未接通 (5)3.3TCH分配过程中的未接通 (5)3.3.1TCH分配失败引起的未接通 (5)3.3.2TCH拥塞引起的未接通 (5)3.4其它未接通 (5)4掉话 (6)4.1无线链路质量差掉话 (6)4.1.1接收电平低且TA值较大 (6)4.1.2接收电平低但TA值正常 (6)4.1.3接收电平正常但质量很低 (6)4.2切换掉话 (6)4.2.1误切换 (6)4.2.2Handover Command等无后续信令 (7)5案例分析 (7)5.1清河路北河口2掉话问题 (7)5.2湖西街茶亭新村2掉话问题 (9)5.3龙园东路古平岗3未接通问题 (10)5.4长江大桥大桥四处2未接通问题 (11)5.5虎踞路艺术学校2未接通问题 (12)5.6江东路聚福园1未接通问题 (13)5.7绕城公路江宁气象学院3未接通问题 (14)5.8中山北路下关2掉话问题 (15)5.9清凉门大桥汉中门1掉话问题 (15)5.10清凉门大街省邮科所2、赛天皇星2同BCCH问题 (17)5.11定淮门大街定淮门2未接通问题 (18)1前言路测主要是分析空中接口接收到的网络电平质量，从而可以了解一些网络无线情况：基站分布、覆盖情况，是否存在盲区；切换关系、切换参数、门限设置是否合理；下行链路是否有同邻频干扰；天线扇区是否接反；天线下倾角、方位角及天线高度是否合理；以及网络的其它情况，为制定网络优化方案和实施网络优化提供依据。
测试方法可以采用长通话测试方式（检查通话质量、切换参数）；空闲模式测试方式（检查小区重选参数、LAC区分布的合理性）；扫频测试方式（同邻频干扰、C/I）、自动重拨呼叫测试方式（评估整网性能），各种测试方法依据需要结合使用。
CSFB测试未接通事件分析汇总
CSFB测试未接通事件分析CSFB未接通事件原因分类：序号原因分类1 被叫没有鉴权响应导致主叫未接通2 被叫响应超时导致主叫未接通3 主叫手机业务中断导致主叫未接通4 被叫脱网导致主叫未接通5 被叫由3G重选至4G导致主叫未接通6 主叫干扰质差导致未接通7 主叫TCH拥塞导致未接通8 2G与4G小区TAC/LAC不一致导致未接通1、被叫没有鉴权响应导致主叫未接通问题分析：主叫终端在10:14:10.885起呼，于10:14:12.412时上发Setup消息。
主叫Setup 后被叫进行CSFB呼叫流程，在10:14:15.819寻呼响应之后收到鉴权请求Authentication Request，但未鉴权响应（Authentication Response）。
被叫未鉴权响应导致回落2G失败，又重选至4G网络，导致主叫未接通。
2、被叫响应超时导致主叫未接通问题分析：主叫在14:49:57.657时起呼，于14:49:59.381时上发Setup消息。
主叫Setup 后进入CSFB呼叫流程，但被叫过了12s后才收到Paging消息。
主叫20s后上发Disconnect 消息，超时挂机。
由于被叫响应超时（延迟12s）导致主叫发生未接通。
3、主叫手机业务中断导致主叫未接通问题分析：主叫终端在07:09:56.913发起CSFB呼叫，在07:10:05:064时上发CM Service Aboert消息，CM业务中断，从网络到移动台，指示被CM的业务中断。
怀疑主叫手机挂机导致业务中断，造成未接通。
4、被叫脱网导致主叫未接通问题分析：主叫终端在06:40:11.668发起CSFB呼叫，于06:40:16.223时上发Setup消息。
在主叫呼叫过程中，被叫由于脱网丢失36s信令，导致主叫在06:40:31.997时上发Disconnect消息。
被叫脱网丢失信令导致主叫未接通。
5、被叫由3G重选至4G导致主叫未接通问题分析：主叫终端在10:11:02.998时起呼，主叫在10:11:05.164时上发Setup消息，主叫呼叫过程中被叫正在由3G重选至4G，被叫在10:11:05重新进行业务附着（Attach），导致主叫未接通。