20140726 寻呼未响应导致CSFB失败
CSFB流程及常见问题.
CSFB流程与常见问题1TD-LTE语音解决方案根据终端形态不同，TD-LTE语音终端包括多模单待和多模双待两种形态多模单待终端话音分为由LTE提供和不通过LTE提供两种解决方案多模双待终端话音由2G/TD电路域提供.2CSFB基本原理中文名：电路域回落CSFB技术是针对TD-LTE多模单待终端提供语音服务的临时解决方案，主要思想是终端驻留在LTE，呼叫建立前先重定向到2/3G，由23G提供CS域语音服务，当语音结束后，根据网络的指示，返回LTE网络驻留；回落2G和返回4G是重点关注的过程。
回落方案：R8 RRC重定向回落(实现简单、性能一般）R9 RRC重定向回落（RIM）（实现复杂、性能好）通话结束，返回4G：空闲态小区重选（小区重选机制,返回时间长，时延较长）快速返回Fast Return （手机支持，无需配置4G邻区，返回时间短，时延较短）。
•开机选网：终端开机—>LTE及2G/3G电路域联合注册—>驻留LTE。
•数据业务：由LTE直接承载,数据传输过程若有话音业务需求，（回落过程将导致数据业务中断）。
•短信业务：可由LTE直接承载，短消息利用SGs接口，通过LTE无线信道传递给UE，UE不需要重选至2/3G。
网络拓扑：3CSFB相关流程3.1联合附着CS Fallback语音主要是通过SGs接口实现的，用户在附着网络时，MME和MSC Server 需要对该用户的SGs连接进行维护。
在E-UTRAN开机驻留的UE，开机后发起联合的EPS/IMSI 附着流程。
联合附着流程如图1所示，由MME通过SGs接口完成UE在UTRAN/GERAN核心网的位置区更新流程，使得UTRAN/GERAN核心网感知到UE的位置.图1联合附着流程图1：UE发起网络附着请求，向MME发送Attach Request消息。
其中参数Attach Type指示这是一个联合的EPS/IMSI附着流程，并且参数指示UE具备CS Fallback能力。
安徽阜阳移动CSFB主叫失败问题报告
安徽阜阳移动CSFB主叫失败问题报告上海贝尔股份公司2014/9/2目录1.问题描述 (3)2.问题处理过程 (3)3.问题原因分析 (3)4.后续措施 (4)1.问题描述阜阳移动4G LTE系统下部分用户反映华为X1终端从移动大楼室外切换到办公室内有时候会出现无法做主叫情况。
2.问题处理过程1)根据现象描述,8月12日在WCS设备上跟踪了MsgTrace,通过WCS跟踪到的MsgTrace发现,主叫手机发送CM Service Request消息后,交换机回了CM Service Reject消息拒绝了呼叫.2)发生这种情况的原因可能出现在联合位置更新异常,仅只通过WCS信令跟踪无法确诊问题,8月13日联合MME共同跟踪SGs口信令3)通过SGs口消息发现在2G、3G、4G网络共存的情况下,确实触发了联合位置更新异常的问题.4)通过实验室场景模拟重现了现场case,并最终确认了root cause.3.问题原因分析在2G、3G、4G网络共存的情况下,如果存在以下情况时会触发本案问题:1)因无4G网络或4G覆盖差，或手机原因未能锁定在4G网络，或发起CSFB后未能直接返回4G，从而使手机登记到了3G网络；2)从3G网络再往4G登记；3)登记到4G后在发起CSFB呼叫前发生了SMS-MT业务；因从3G登记到4G网络时,WCS根据规范只更新了MMLAI,没有更新GLOBALCELLID. 但是接下来WCS在SMS-MT的过程中,会错误的将GLOBALCELLID覆盖到MMLAI,从而造成了VLR中手机用户的LAC信息变为3G LAC,导致在CSFB主叫时因位置信息不匹配使得呼叫失败.4.后续措施1）实验室进行解决方案测试、程序封装及验证，预计中秋节前将完成实验室验证后发布；2）根据贵公司实际需求安排现场实施及验证。
【大神放招】CSFB被叫寻呼成功率指标提升(1)-原因分析
【大神放招】CSFB被叫寻呼成功率指标提升(1)——原因分析最近经常有小伙伴来问CSFB被叫寻呼成功率，有没什么绝招能提升指标？小编虽然不才，能力有限，但是小编有人，就这个问题，请来高手为大家放几个大招，希望可以帮助到大家工作上遇到的问题。
掌声有请辉大神，艾老湿，丁老板，GG姐……小编先来抛砖引玉一下，CSFB是一个全流程的业务，涉及多个网元的交互与配合，需要无线与核心网联动来保障用户感知。
由于CSFB终端做被叫的信令过程包含其做主叫的信令过程，为了便于统计分析，集团公司为CSFB定制了指标，主要针对被叫CSFB过程，分别为CSFB寻呼成功率、CSFB回落成功率、CSFB呼叫接通率。
各项指标具体计算方法如下。
CSFB被叫寻呼成功率＝SGS接口语音业务请求次数／（SGS接口语音业务一次寻呼次数－SGS接口业务取消次数）按照定义可知CSFB被叫寻呼成功率为LTE网络负责信令控制的移动性管理实体（MME：MobilityManagementEntity）向交换机MSC回SERVICERE-QUEST的次数，与MSC向MME下发的寻呼次数相比得到的值。
如图1所示，当UE处于空闲态时，MME下发寻呼手机上报扩展服务请求后，MME回SERVICEREQUEST给MSC，信令流程如图１所示；UE处于业务态时，MME 收到MSC的寻呼消息时直接先回SERVICEREQUEST给MSC。
诸大神主要针对CSFB寻呼过程，从寻呼成功率指标及寻呼关键信令来阐述CSFB寻呼失败的原因，提出相应的优化解决方案。
首先来看一下各位大神分析的影响CSFB被叫寻呼成功率的原因。
从信令流程可以看出，CSFB寻呼过程涉及MSC、MME和LTE无线三大网元部分。
目前，MME处于轻载状态，MSC与MME的SGS接口也没有负荷告警，所以最终几位大神将造成CSFB寻呼失败的原因聚焦在LTE 无线侧。
艾老湿很激动，第一个发言：“被叫UE处于小区边缘弱覆盖区域，会导致下行寻呼接收困难，由于小区边缘下行导频覆盖电平较差，使得PCH的覆盖一样较差，会导致这种场景下UE接收寻呼困难（特别是农村场景和LTE覆盖边界区域）。
寻呼失败分析
10分钟内改为2分钟内，这样统寻呼失败问题分析1.概述在寻呼无响应分析中，通常可以分为以下几个原因：位置更新原因：即当发生寻呼时，手机恰巧进行跨局位置更新，导致寻呼失败。
呼叫建立冲突：MS 在开始建立通话到 SDCCH 言道分配前的时间段，VLR 还未标记MS 状态，系统将寻呼 MS ,但MS 未监听寻呼消息。
终端断电：MS 非正常关机到 MSC/VLR 中隐关机计时器超时前的时间内，对该 MS 的寻呼，MS 无法相应，终端异常操作反映在终端发生寻呼失败后的第一个成功的网络事件 是 IMSI ATTACH弱覆盖或盲区：MS 处于弱覆盖或盲区内，造成 MS 的寻呼无响应。
根据后续发生业务 的时间，暂时起名为瞬间弱覆盖（10分钟内）或长期弱覆盖（10分钟后）。
其它：手机异常，手机死机，寻呼丢失，基站工作异常等G1寻呼失败错误原因统让■位置更新冲突 ■呼叫建立冲突 ■手机终端异常 ■瞬间弱覆盖 ■长期弱覆盖 ■其他原因从G1的寻呼失败错误分布看，其中弱覆盖或盲区的原因，占总寻呼失败的 90%以上，因此对弱覆盖的研究是寻呼失败的主要原因之一。
我们认为，引起这种弱覆盖的原因可能有以下两种情况：1. 手机进入弱覆盖区，容易脱网和入网的边界区2. 基站的paging 丢失、SDCCH 拥塞、AGCH 阻塞，导致无法分配到 SDCCH 信道，无法 上发 pagingresponse 消息。
前者，受限于现有网络的覆盖状况；后者，设备性能、配置、参数等设置有关。
为了更加精确的了解瞬间弱覆盖小区，我们将时间从 计的结果可能更加接近实际弱覆盖小区。
统计结果如下：寻呼失败后2分钟内发生新业务的小区排序如下:2寻呼失败后2-5分钟内发生新业务的小区排序如下:2.数据分析我们选择17157_1313和17157_6071两个小区为例，分析可能的产生原因。
2.1 RMS报告弱覆盖数据分析17157_1313:园丁花园 3上行：质量电平分布如下：上行弱覆盖(-95dBm以下)的比例为(67179+17380)/258038仁3.28%下行：质量电平分布如下:EBPinwoE丄EBPOW-G2.EBWGWO 0?一EBPO°?-S1EBPinror--丄EBPo\Gg丄EBPingJog丄-thh恤迂a6 5 4 3 2 di Ol丄EBPOCILGE■上行电平分布1+上行质量分布|DL_RXLEV (dBm) Qual|0 Qual|1 Qual|2 Qual|3 Qual|4 Qual|5 Qual|6 Qual|7 Tot_MEAS Avg_Qual [-47,-60) 47585 465 394 314 250 186 234 3266 52694 0.54 [-60,-65) 93958 1366 1060 895 598 426 369 369 99041 0.16 [-65,-70) 233301 2901 2241 1749 1267 1191 913 913 244476 0.15 [-70,-75) 749529 4982 3920 3910 2952 2952 2942 2942 774129 0.12 [-75,-80) 589858 6149 5837 3857 3203 2468 2323 2323 616018 0.14 [-80,-85) 375956 5589 5474 4452 3271 2451 1554 1480 400227 0.19 [-85,-90) 203862 4540 3813 3825 3066 2243 1315 853 223517 0.27 [-90,-95) 82239 3282 2918 2888 2580 1991 1305 625 97828 0.51 [-95,-100) 29111 1978 1953 2208 2007 1775 1170 569 40771 0.99 [-100,-110)122441378146817992044224919261299244072.04下行弱覆盖(-95dBm 以下)的比例为(40771+24407) /258038仁2.53%上行质量电平分布图: 步区名 fy¥_YuaiJ)ingHuaYuaii3_：3：31 ▼ |IACCI |1T15T_1313 三|TRX 信息小区信息上行口untEf 上行图形下行Counter 下行图形下行质量电平分布图:RXQLJAL 飓LEV 的详细分析上行-电平质量分布團从弱覆盖电平的比例看，该小区弱电平比例为2.53%。
寻呼被叫无响应
GSM0.5%的差距。
DT 测试长期趋势见Figure-1。
Edward Ruan Page 1 of 2 Performance ImprovementFigure-3 寻呼响应失败时BCCH 下行BER 差寻呼解码失败经常发生在BCCH 下行质量(BER)较差的情况下，同时有错误报告提示此时产生手机无法解码Paging 。
Call Attempts 7474 Call Connection Failure 112 98.50%Paging Timeout 53 47.32%SDCCH Loss 1816.07%Data Source: TEMS logs from 4.23 to 6.23Figure-2 TEMS 测试呼叫失败主要原因 寻呼无响应在移动网中较常见，主要发生在郊区盲区和弱覆盖区，对长途来话接通率（TICR ）也有严重影响。
在市区覆盖良好的小区中，同样可能发生寻呼无响应，原因是BCCH 下行C2I 较差的点上，因为BER 恶化，被叫解码包含寻呼消息的CCCH 帧连续失败，导致无法响应寻呼。
如Figure-3 所示，被叫驻留小区在BCCH 下行有较差的BER ，最终导致寻呼无响应即呼叫建立失败。
Figure-4 BCCH 的下行BER 差时不能解码pagingBCCH 下行信令质量无法通过任何统计和通话测试来得到准确计量，但可通过TEMS 的IDLE-MODE 模式来测试，MS 收到每4个BCCH_BLOCKS 即4个51复帧后送出一个idle mode report ，内即包含BCCH 的rxqual 。
如果有条件用TEMS3.1+RS320作IDLE 测试，每8个51复帧才给出一个测量值，可确保BCCH 下行信令质量测试结果的高可靠性。
被叫寻呼无响应（Paging Timeout ）减少寻呼无响应可能的方法减少盲区；减少弱覆盖区；减少BCCH 上下行频率干扰； 增大T3113时长；对BCCH 下行信令质量恶化作出快速躲避反应：强制手机立即无条件重选小区；BCCH 下行信令失败（Downlink Signalling Failure ）是寻呼无响应的根本原因。
中国联通LTECSFB失败原因分析201811
CSFB失败原因与信令特征对应表目录1概述 (4)1.1前言 (4)2失败类型：CSFB主叫失败 (4)2.1失败原因：终端回落到了弱覆盖的2G小区,终端在2G的接续过程中掉话 (4)A接口： (6)3失败类型：CSFB被叫失败 (7)3.1失败原因：用户处在2个TA重叠的覆盖范围, 经常在两个TA之间来回重选，做被叫时正在重选过程中导致的CSFB被叫时失败 (7)3.2失败原因：未部署MTRF功能情况下 UE跨MSC Pool回落，导致的CSFB被叫失败73.3失败原因：诺西ENodeB的CSFB功能未打开，导致的CSFB被叫失败 (8)3.4失败原因：阿朗ENodeB的CSFB LICENSE功能未打开，导致的CSFB被叫失败。
93.5失败原因：诺西MME软件缺陷，当用户正在进行X2切换时，MME并没有等待该切换完成后重新下发Paging消息，最终导致寻呼未正常下发.诺西计划在14年6月的NS31中解决。
(11)3.6失败原因：手机终端设置黑名单或来电防火墙引起CSFB被叫失败 (12)3.7失败原因：回落2G后发生LAC改变,改变后的LAC所属BSC(华为）的GSM小区未开启CSFB功能，导致主叫失败 (13)3.8失败原因：阿朗ENODEB采用BitMap方式下发GSM回落频点导致CSFB接通失败153.9失败原因： .回落邻区漏配、少配或者优先级不当引起回落失败 (16)3.10失败原因：诺西MME的BUG造成7108D等单卡双待手机存在联合附着. 引起双待手机被叫失败 (17)3.11失败原因： ENODEB将ESR(TAU)错误分发至另外一个SGSN，引起被叫无法接续（大唐、中兴ENDOBE) (17)3.12失败原因：伪基站干扰，CSFB手机做被叫时回落至伪基站，造成被叫失败193.13失败原因： 4G网络弱覆盖寻呼无响应造成被叫失败。
(20)3.14失败原因： 4G网络SINR值差，导致iPhone手机终端无法收到Paing消息造成被叫失败。
CSFB未接通分析
CSFB未接通分析参考LOG：LTE本地网_广州_语音_Iphone5s_广深高速广州往深圳下午_主叫_1300014_{35802805-6084-6910-0000-000000000000}Out20140831-122204-语音主叫.rcu(02) LTE本地网_广州_语音_Iphone5s_广深高速广州往深圳下午_被叫_1300024_{35802805-4064-9270-0000-000000000000}Out20140831-122202-语音被叫.rcu(02)一、省第三方测试指标二、CSFB流程介绍1、当CSFB终端驻留在TD-LTE网络时，需要发起语音主叫或者被叫过程时，网络会通过RRC 重定向过程，将CS语音业务回落到GSM网络中来完成，而正在进行的PS域数据业务（如果有）需要暂时挂起。
2、CSFB主要流程包括三个步骤：第一步，通过重定向回落至GSM；第二步，在GSM中读取系统消息（System Information Type 1/2/3/4）；第三步，是在GSM中进行语音呼叫。
3、根据进行语音呼叫时用户手机是否在4G做PS业务，CSFB可分为idle状态的CSFB和RRC-Connected状态的CSFB两种。
4、详细流程如下图：分别给出了空闲态和业务态下的主被叫手机侧信令流程。
（1）空闲态下主叫手机侧流程（RRC建立原因：mo-data）（2）RRC连接态下主叫手机侧流程（3）空闲态下被叫手机侧流程（RRC建立原因：mt-access）（4）RRC连接态下被叫手机侧流程三、异常案例1、案例一：CSFB回落到3G偶尔发现主叫（或被叫）下沉到3G正常起呼，跟终端有关，跟未接通没有直接的关系。
2、案例二：被叫跨POOL（4G起呼小区所在TAC与回落的2G小区所在LAC分别属于不同POOL）一定会出现未接通。
（相应的信令流程见附件）原因：目标2G小区所在MSC没有用户信息，网络侧无法执行后续流程。
CSFB指标详解
CSFB指标详解CSFB指标全称为Call Setup Failure率(Call Setup Failure Rate)，是衡量手机网络通话建立失败率的指标。
在移动通信网络中，CSFB指标对保证手机网络通话质量起着重要的评估作用。
下面将详细介绍CSFB指标的含义、计算方法以及影响因素。
CSFB指标是指在LTE网络中，当用户需要建立语音通话时，由于其支持VoLTE的手机无法直接建立通话连接，需要先切换到GSM或WCDMA网络进行通话，然后再切换回LTE网络。
因此，CSFB指标衡量了这个过程中建立通话失败的概率。
其中，CSFB呼叫失败次数是在通话建立过程中，由于各种原因（如信号弱、网络繁忙等）导致通话建立失败的次数；总CSFB呼叫次数是指通话建立过程中，所有尝试连接到GSM或WCDMA网络的次数。
1.网络覆盖：移动通信网络的覆盖范围决定了用户在不同地域能否接收到稳定的信号。
如果网络覆盖不到位，信号弱，就会导致CSFB呼叫失败率升高。
2.网络负载：网络负载过大会导致网络资源紧张，无法满足用户的语音通话需求，从而增加了CSFB呼叫失败的可能性。
4.网络切换时间：LTE网络切换到GSM或WCDMA网络，需要一定的时间来完成切换过程。
如果切换时间过长，就会增加CSFB呼叫失败的可能性。
5.手机终端性能：手机终端在切换到GSM或WCDMA网络时的性能表现，例如收发信号质量、通话稳定性等，会影响CSFB呼叫的成功率。
为了提高CSFB呼叫成功率，移动通信运营商需采取以下措施：1.优化网络覆盖：加强基站建设，增加网络覆盖范围，提高网络信号质量，从而降低CSFB呼叫失败率。
2.提高网络容量：通过升级网络设备，增加网络容量，提供更多的资源来支持语音通话需求，降低网络负载，减少CSFB呼叫失败的概率。
3.调整切换参数：对CSFB切换参数进行调整，优化切换时间，减少通话建立过程中的等待时间，提高CSFB呼叫成功率。
4.优化手机终端：与手机厂商合作，优化手机终端的性能，提高其在切换网络过程中的稳定性和表现，减少通话建立失败的可能性。
CSFB寻呼
谈一些个人对寻呼的理解寻呼是指终端在空闲态时，当有下行数据业务到达或做被叫时，网络侧发送消息给UE终端的过程。
TD-LTE系统中的寻呼消息由网络向空闲态或连接态的UE发起，可参考3GPP 36.300协议。
在TA范围内，Paging消息会在UE注册的所有小区发送。
寻呼消息根据使用场景既可以由MME触发也可以由eNodeB触发。
寻呼与广播有区别，寻呼是针对单个UE，而广播针对覆盖区域内所有的UE。
在传统的网络优化中，寻呼是一个无线优化与核心网优化的边缘地带，在无线优化工作中，一般把寻呼过程作为核心网的一部分；而在核心网优化中，寻呼是最末端的一步，和无线息息相关，因此，寻呼的优化经常会被忽视。
在现有的234G网络中，有三种形式的寻呼。
第一类是CS寻呼，用于23G与4G的CS域（适用于单卡双待终端），由MSC发起寻呼过程，寻呼的单位是LAC；第二类是PS寻呼，用于23G与4G网络的PS域，23G的PS寻呼由SGSN发起，寻呼单位是RAC；4G的PS寻呼由MME发起，寻呼单位是TAC；第三类CSFB寻呼，由于LTE网络是纯IP网络，不支持电路交换业务，语音业务需适用CSFB（Circuit Switch Fall Back）回落到2G网络，需新增SGs接口，CSFB终端联合注册（LA/TA）到2G/4G网络中，在有语音业务到达时，由MSC通过SGs接口向被叫UE所在MME发出寻呼消息，MME通过S1-mme接口向UE登记的TA区发送Paging。
总的来说，在23G网络，可通过空口的寻呼消息负荷来监控LAC区下用户量以及业务量的多少，来评估节假日信令负荷或预测大型场馆的信令风暴。
4G网络目前用户量较少，在规划CSFB业务时，进行了TA与LA在无线覆盖中的重合，TA区域的范围较小，所以，4G目前寻呼负荷并不高。
从端到端的业务分析来看，寻呼是一个衔接主叫与被叫、服务器与终端的必要的过程，而且，对寻呼的分析可以关注到不同接口的寻呼信令负荷，对信令风暴的规避可达到自然而然的预防；寻呼的分析还可以作为无线网络网络覆盖评估的一个非常有效的方法。
CSFB异常点分析总结
1 问题现象1：R9盲重定向后读取3G系统消息接入如下图所示：UE发起CSFB后，接入3G后读取系统消息，说明R9的FLASH CSFB未生效分析LTE侧RRC连接释放消息，可以看到ENB只下发了频点，没有下发相应小区信息分析LTE侧SIB1消息，可以看到此时接入的LTE ENB为9，小区为1结论：9号enb为集锦饭店，此站的RIM流程有问题，DSP UTRANRIMINFO中，未包含最高优先级的3G邻区，由于测试版本BUG，导致rrc release消息中未携带系统消息，接入3G 小区后读取了系统消息。
2 问题现象2：CSFB至3G后发起LAU，并且无法快速返回4G，并且未发现alerting问题如下所示，UE在3G侧发起LAU从呼叫开始分析，在16:16:40.135，LTE发起RRC连接释放触发CSFB动作，由于RRC连接释放消息中只携带频点，因此是R8的重定向CSFB，UE在3G侧读取系统消息接入UE在16:16:41.300发起RRC连接请求，此次RRC连接请求是CSFB的接入请求，可以看到RRC连接请求携带的原因为conversation callUE在16:16:42.957发送RB SETUP CMP消息完成CS RAB的建立，但从UE侧信令上看，过了6秒之后，UE进入空闲态UE在16:16:48.742发送cell update重新接入，携带原因为unrecoverableError，并且报AM-RLC在RB 2-3or4上错误指示为1，因此判断链路发生SRB复位掉话，UE后续通过cell update 重新接入。
从当时的信号强度和质量来看，下行Ec/Io较好，因此判断是上行失败导致UE掉话。
怀疑RNC未收到UE发送的RB SETUP CMP消息。
由于UE掉话，后续UE接入后重新发起RRC连接请求，此时携带原因值为注册。
表示此时UE认为该次RRC连接并非CSFB业务。
UE在16:16:49.509发起RRC连接请求，原因为注册。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1
名称：寻呼无响应引起未接通
问题描述：
现象标题：被叫终端寻呼无响应
基站配置：SCTE+BPOH+3台338D
现象描述：
测试车辆于临汾网格3沿福利路由西向东行驶至斯麦尔酒店附近，此时主叫处于LTE网
络占用小区A2_YD福利巷斯麦尔DLD_H-3，在该小区主叫UE发起Extended Service Request，
核心网直接下发服务拒绝， 3s后主叫发起LAU，随后主叫UE再次发起CM SERVICE REQUEST
（消息内容未解码）,从接下来的SETUP消息中看到是成功建立了主叫业务，在成功建立业务后
27s，主叫收到网络下发的Alerting，此时被叫于LTE网络占用A2_YD福利巷斯麦尔DLD_H-3，
连续3次接收到了寻呼消息，经核对被叫TMSI与寻呼消息携带TMSI一致，接收到最后一条寻呼
消息后50s内丢失信令，在此期间内主叫Disconnect，cause：16：normal call clearing（正常清除），
造成未接通。
问题分析：
1、 核查主叫核心网直接下发服务拒绝原因
2、 核查被叫是否收到寻呼消息
问题排查：
核查主叫核心网直接下发服务拒绝原因
方法步骤：通过信令分析主叫UE发起Extended Service Request时空口环境良好，但随后核心网
直接下发Service Reject（消息内容未解码），3s后主叫发起LAU，可以判断主叫发起回落的目标
小区归属的MSC与UE附着EPS网络时登记的MSC不同（即服务MSC与EPS/IMSI登记的MSC
不同），因此核心网拒绝了该UE的业务，如下图所示：
2
（主叫核心网拒绝）
（主叫发起LAU）
核查被叫是否收到寻呼消息
方法步骤：通过信令分析查看UE正常接收到了网络下发的寻呼消息，且寻呼TMSI与网络给被叫
UE下发的TMSI一致，可以确认网络寻呼的正是被叫手机；但是UE在连续收到3条寻呼消息后
并未响应，且在随后50s内的信令均丢失，结合主叫UE信令分析，主叫在建立业务27s后收到了
3
2G侧CC层下发的Alerting消息，因此可以判断被叫应该是做出了响应，且被叫向网络上发了
Alerting消息，只是被叫UE测试软件并未记录到此时间段内的信令消息，同时在上发了Alerting消
息后并未向网络上发Connect消息，直到最终主叫断开；而根据现场测试时终端行为的观察，主叫
收到振铃音后被叫UE却毫无反应，一直是待机界面，可以得出结论此时被叫UE出现了问题，未
能作出响应寻呼后的反应，导致测试脚本未能执行接通命令，从而导致未接通。
（UE最近一次所分配的M-TMSI）
（被叫接收到寻呼消息）
4
处理过程：
更换测试终端复测
处理效果
在倒换后多次复测验证正常，未在出现类似事件