寻呼被叫无响应
CSFB失败问题总结
可能原因1）MSC从SGs接口下发寻呼消息中通过IMSI进行寻呼，导致UE在回到GU网络后，通过IMSI回复寻呼响应，无线BSC/RNC通过IMSI寻找到的MSC可能不是发起寻呼的MSC，从而导致被叫失败。
MSC通过软参P1156Bit7控制从SGs接口下寻呼时携带TMSI信元，确保寻呼响应时正确选择MSC Server 。
CPCI V100R007C10SPH711ATCA V200R009C02SPH113或者MSC开启CSFB MTRF特性(会增加时延)。
2）UE做了detach流程，MSC和MME上将用户状态置为detach，同时MME上会将UE之前的TMSI信息删除，然后UE发起了一次新的联合位置更新，发现MSC在SGs上回复的Location Update Response里没有分配TMSI，但是在做被叫时，MSC又是以TMSI发起寻呼，由于MME上此用户的TMSI信息已经删除，认为该TMSI不合法，转而以IMSI寻呼，导致UE在回落到GU网络后，IMSI的寻呼响应被随机分配到了MSC Pool 中的任意一台，出现概率性被叫失败。
但是测试发现三星S3与苹果iphone5的终端无问题，猜测其原因是虽然网络侧以IMSI寻呼，但是终端上存在TMSI，在CSFB回到GU后，仍然以TMSI做寻呼响应，所以可以寻找到正确的MSC。
MSC为异厂家设备，MME为华为设备。
USN V900R012C00SPC300+SPH316补丁解决，MME不检测TMSI合法性，直接转发寻呼。
3）MSC通过SGs接口发起TMSI寻呼失败，后续发起IMSI寻呼，寻呼成功导致UE回落到GU后无法发送paging response到正确MSC。
MSC为异厂家设备，MME为华为设备。
UE做联合位置更新时，MSC给MME发送的SGsAP-LOCATION-UPDATE-ACCEPT消息中的new-tmsi-or-imsi信元指示为IMSI，但是发送SGs接口paging request消息里却使用TMSI寻呼，导致UE无法匹配TMSI，无法响应CSFB paging。
VoLTE手机被叫未接通案例分析及处理
VoLTE手机被叫未接通案例分析【摘要】VoLTE试商用时出现大概率被叫无法接通现象，通过现场测试排查和端到端信令分析，将问题锁定在核心网侧。
省NOC根据故障报告进行排查，针对核心网TLDN回落机制分析，最终确认核心侧TLDN数据配置不全。
【关键字】VoLTE 被叫TLDN 回落背景：随着网络优化和VoLTE商用的推进，安徽电信内部开通VoLTE用户预商用，要求各分公司试用并进行网络质量分析和疑难问题反馈，协助省公司完成VoLTE商用指导。
【故障现象】：省公司开通VoLTE测试卡后，概率性出现VoLTE测试卡作为被叫无法接通现象，未接通时主叫保持呼叫状态，被叫手机无响应，直至主叫手机提示“无声、空号、无法接通、未开通此项业务、增值业务被终止”等各种声音通话结束：图1：测试被叫无响应【告警信息】：登录基站无告警，网元测试，基站与MME、SGW等网元连接正常：图2：网元节点测试【原因分析】：（一）终端排查现场倒换终端进行测试验证，发现开通VoLTE功能终端在CS域做被叫出现大概率未接通，主叫正常：表1：终端排查（二）无线环境分析CQT测试，选取RSRP：-60dbm、SINR：30db覆盖正常，无线环境良好的测试点进行测试，依然出现被叫CS域无法接通现象：图3：无线环境（三）信令对比分析通过以上分析可以看出本次未接通与无线环境无关，只是VoLTE 功能终端在CS域被叫引起的未接通，计划通过CS域被叫正常通话和未接通信令对比来分析差异。
正常接通时：IMS域主叫发起INVITE Request后，2s∽5s左右被叫在C网收到寻呼消息，进而发起CSFB回落到C网通话，信令流程如下：图4：正常呼叫被叫CS域未接通时：信令来看IMS域主叫15:33:48发起INVITE Request请求，15:34:18发起呼叫取消，随后IMS下发呼叫取消确认，并下发INVITE 487呼叫终止，主被叫信令流程如下：此时，发起呼叫到终止经过30s时间，主叫超时释放，造成未接通，信令如下：图5：被叫无法接通主叫终端收到IMS下发的487呼叫终止消息，被叫未收到寻呼导致主叫超时终止通话，可以判断问题出在eNB上层网元IMS寻呼处理阶段。
贵阳联通4G用户作被叫无法接通分析报告(20150628)
贵阳联通4G用户作被叫无法接通故障分析报告一、问题描述6月27日12时许，贵阳联通接到部分用户反馈,主叫拨打贵阳联通用户听到炫铃音,但被叫方无任何反应，最终无法接通后通话释放。
故障发生后经现场处理人员测试发现，该故障只发生在4G用户作被叫时出现，2/3G 用户不会出现该故障。
二、问题处理接到故障反馈后，我司PS维护人员及时赶到现场，由于是4G用户出现故障， PS维护人员通过信令跟踪排除CSFB回落存在故障的可能，同时现场其他处理人员发现当故障出现时，贵阳MSCS1上发给MGW的H248消息发到了安顺MGW上（正常时是发到贵阳MGW1上），于是通过搭建远程环境，CS维护人员通过远程环境进行了故障定位，在贵阳MSCS1上配置贵阳MGW1和安顺MGW NB口之间的承载后，13点10分许，故障解决，经测试，即使建立通话时MSCS1把H248消息发到安顺MGW，通话建立不受影响。
三、问题分析本次故障从现象来看，只与4G用户有关，且都是作被叫时出现，故障出现时都是MSCS发送的H248消息没有发到被叫用户所在的MGW，该MGW 与被叫用户所在无线无任何拓扑关系，导致MGW不能建立承载导致通话建立失败，联想到6月26日凌晨进行的MSC组POOL Mc口互联操作，该故障可能与该操作有关，经进一步信令跟踪分析，在4G CSFB回落过程中，MSCS 建立H248消息与2/3G 用户通话过程中建立H248消息的时间点是不同的，在2/3G通话过程中，MSCS是在被叫用户寻呼响应后才下发H248消息让MGW 建立承。
而4G用户为了缩短CSFB回落过程中信令建立的时间，在接收到MME的业务请求回应，还没收到用户的寻呼响应时就开始发送H248消息要求MGW开始建立承载。
这样一来，对于2/3G用户，MSCS在收到用户寻呼响应后才建立H248消息，MSCS知道被叫用户所在的MGW，所以建立H248消息时始终选择正确的MGW，但对于4G用户，MSCS还没等到被叫寻呼响应就开始建立H248消息，当MSCS下有多个MGW注册时，MSCS就会随机选择一个MGW建立承载，当用户所在无线与MSCS所选择的MGW不存在拓扑关系，各个MGW间又没开启NB口承载时，承载建立就会失败，最终通话信令建立失败。
呼转语音信箱导致语音无响应处理案例
呼转语音信箱导致语音无响应处理案例
一、问题描述
XX用户在8月12日16点03分呼叫被叫，被叫侧无任何反应。
二、处理过程
查询CS单据，如下图所示：
1、查询问题时段单据，被叫用户1828870**** 16:03:30-16:03:45时段与其他用户通话中，于16:03:45时段结束通话。
2、主叫侧16:03:39时段对1828870****发起通话请求，由于被叫用户忙进行呼叫转移，呼转至12599语音信箱，导致被叫侧无任何反应。
3、2021-08-12 16:03:39.576 回铃音过长问题分析
2021-08-12 16:03:39 主叫发起INVITE，发起语音通话，被叫用户正在通话中，用户忙。
由于被叫手机设置为遇忙呼转，触发呼转流程
该通话呼转至12599语音信箱，由于该语音信箱异常原因导致被叫无响应。
三、问题根因
主叫侧16:03:39时段对1828870****发起通话请求，由于被叫用户忙进行呼叫转移，网络侧去CS域寻呼被叫号码，导致被叫侧无任何响应，主叫侧16:03:44时段取消通话。
四、解决方案
手机设置→通话设置→来电转接：重新进行设置，不转移至语音信箱。
五、建议与总结
无。
寻呼失败分析
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%。
FDD-LTE被叫概率性无响应处理
FDD LTE网络被叫概率性无响应问题处理FDD-LTE网络开通后，语音业务的承载采取CSFB方式进行，在测试中发现被叫在CSFB 时概率性出现寻呼无响应现象。
主要现象为主叫无响应或提示“无法接通”。
为提升用户感知，分别在空口、RNC侧、MSC侧、MME侧进行了信令抓取及分析。
通过无线侧及核心网联合排查，最终发现导致问题的原因。
经过对调整后网络反复多场景测试验证，确定顺利解决该问题。
在FDD-LTE建网初期，基于网络改造代价及参数配置工作量最小化考虑，采取CSFallBack方式回落至GSM网络或UMTS网络进行语音、短信、定位等电路域业务。
在CSFB过程中出现网络问题。
在FDD-LTE网络中，被叫CSFB时概率性发生无法响应的现象。
主要现象有：1、主叫听到振铃音，同时被叫网络指示由LTE变为UMTS并快速返回至LTE，但未接通；2、主叫收到系统提示音“您拨的用户暂时无法接通”。
通过在不同网络环境、不同终端情况下的测试，排除无线信号及终端原因。
无响应的现象出现概率为10%左右。
分析与对策根据实际问题产生的情况，分别在无线侧及核心网侧进行了联合的排查及分析。
以找出导致问题的原因及解决办法。
处理过程第一步：核查参数设置结果：正常现网采用基于FDD到UMTS盲重定向的CSFB，经核查全网基站小区参数设置无误。
第二步：确认联合ATTACH成功结果：正常有Combine类型的A TTACH的请求，CS域和PS域均附着成功。
ATTACH ACCEPT无问题。
第三步：测试软件+被叫手机信令排查结果：异常以下为正常情况下信令：UE收到CS Service Notification然后发起Extended Service request之后在LTE网络下进行RRC连接释放，进入UMTS网络发起被叫会话类业务相关的RRC连接请求。
经过鉴权、加密、安全模式等直传消息后，先后收到setup、alerting，呼叫接通。
中国联通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消息造成被叫失败。
未接通原因归类
未接通原因归类未接通原因归类：导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。
1、RxLev连续小于-90dBm2、（GSM）RxQual连续5级-7级3、（GSM）No route to destination\拥塞\No circuit/channel available 主叫在起呼期间，被叫在位置更新，无法响应主叫寻呼，导致主叫呼叫建立超时（超过15S)，上发Disconnect。
4、主叫起呼期间，完成了SDCCH信道以及TCH指配，但被叫一直处于空闲模式下。
（无线环境良好）Call rejected/CM Service Reject（如果信令解码有明确原因请归入前面类别）5、起呼期间，下行电平弱（BCCHLEV\Rxlevsub连续小于-90DBM) 起呼期间所指配的SDCCH信道或者TCH信道受到干扰。
6、无SDCCH或者TCH信道指配，导致呼叫建立超时，主叫上发disconnect；或者指配TCH信道时出现指配失败。
（RR Assignment Failure）原因1:是当前服务小区的Pch信道拥塞，无法下发寻呼消息;原因2：被叫收到寻呼寻呼消息，但无法占用SDCCH信道上发寻呼响应。
归为信道拥塞。
7、重选不及时会导致主叫起呼失败。
8、被作为被叫的时候分配了TCH后呼叫，会导致碰撞，进而无法接通；未接通主要原因如下：1、路段覆盖差1）本身覆盖差2）孤岛效应导致覆盖差3）重选不及时导致覆盖差4）硬件故障，TCH载频问题，跳线问题；2、参数设置问题1）重选关系2）接入电平门限3）呼入呼出限制等等3、容量问题：无空闲信道等4、硬件故障问题4、手机本身问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
GSM
0.5%
的差距。
DT 测试长期趋势见Figure-1。
Edward Ruan Page 1 of 2 Performance Improvement
Figure-3 寻呼响应失败时BCCH 下行BER 差
寻呼解码失败经常发生在BCCH 下行质量(BER)较差的情况下，同时有错误报告提示此时产生手机无法解码Paging 。
Call Attempts 7474 Call Connection Failure 112 98.50%Paging Timeout 53 47.32%SDCCH Loss 18
16.07%Data Source: TEMS logs from 4.23 to 6.23
Figure-2 TEMS 测试呼叫失败主要原因 寻呼无响应在移动网中较常见，主要发生在郊区盲区和弱覆盖区，对长途来话接通率（TICR ）也有严重影响。
在市区覆盖良好的小区中，同样可能发生寻呼无响应，
原因是BCCH 下行C2I 较差的点上，因为BER 恶化，被叫解码包含寻呼消息的CCCH 帧连续失败，导致无法响应寻呼。
如Figure-3 所示，被叫驻留小区在BCCH 下行有较差的BER ，最终导致寻呼无响应即呼叫建立失败。
Figure-4 BCCH 的下行BER 差时不能解码paging
BCCH 下行信令质量无法通过任何统计和通话测试来得到准确计量，但可通过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 ）是寻呼无响应的根本原因。
GSM 规范规定下行信令失败计数器DSC=inter(90/bs_pa_mfrms),当MS 能成功解码寻呼子信道，DSC 加1，当MS 解码寻呼子信道失败（Failed to decode paging 或BFI ）,DSC 减4，若DSC<0，不论当前小区电平和C1、C2是多少，立即作一次小区重选以躲避当前小区的BCCH 下行信令失败。
比如BS_PA_MFRMS=3=5,那么DSC=18,MS 最坏时连续四次以上解码寻呼子信道失败，才作紧急重选；比如BS_PA_MFRMS=5=7,那么DSC=12，MS 最坏时连续三次以上解码寻呼子信道失败，就作紧急重选。
BS_PA_MFRMS 寻呼子信道设置越多，意味着DSC 门限越小，MS 遭遇BCCH 下行信令失败时作出躲避越快。
毕竟这个系统内BCCH 下行好的小区在时间和空间上比BCCH 下行差的小区要多得多，所以理论上设置较多的寻呼子信道对确保MS 能响应寻呼，对TICR 和对GPRS 的小区重选有统计意义上的好处。
但对小区重选的准确度有影响。
鉴于当前的情况，T3113增大会导致主叫用户提前挂机反而影响TICR ，以下三种方法可供参考用于减少被叫无响应进而提高路测接通率。
1． TEMS 的IDLE-MODE 测试BCCH 下行信令
质量(最好用RS320评估PCH) 2． Agilent GSM receiver IDLE-MODE 测试
BCCH 下行干扰和下行BER ；
3． 用以上两步识别BCCH 恶劣区域并整治覆
盖，干扰和频率，如1883/1871区域；
4． 将BS_PA_MFRMS 从3提高至5，牺牲小区
重选精度，减少寻呼无响应的几率；
5． MTC 尽最大可能驻留在最好的BCCH 上也
可减少SDCCH 的掉话几率。
Figure-5 TEMS2.0所测GSM900的BCCH 下行质量
TEMS2.0的IDLE 测试结果见Figure-5，红点表示CCCH 下行信令Qband 为7，即MS 连续4个51复帧不能解码，即在1秒内对该MS 的所有寻呼不能解码。
而对每一个被叫来说，最多被寻呼两次，寻呼消息分别包含在该MS 所属的前后间隔5秒的两个寻呼子信道内，即MS 在每一个红点和黄点处有很大的机会不能响应寻呼。
即MS 在红点处有可能错失第一次或T3113后的第二次寻呼，而导致成功响应寻呼的几率减少。
TEMS2.0的IDLE 测试结果可用于计量BCCH 、SDCCH 、PCH 下行的频率干扰特性,与计量C2I 是相关的，这是话务统计和通话测试无法完成的。
通过反复的IDLE 测试后，BCCH 下行信令恶劣的部分小区和地点可被识别，通过限制接入和覆盖、频率控制后，不但可以提高PCH 的性能，对提高路测C2I ，以及GPRS 下行质量也有帮助。
因MS 作LUP 时一定不能解码Paging ， 此时产生的BER 应被去除掉。