CSFB信令案例分析报告
LTE湘潭移动CSFB问题案例
原因分析：
1：基站状态查询
查询站点无告警存在，因此排除主设备硬件告警导致；
2：测试终端问题排查
相同终端在其他已经开启CSFB功能的LTE小区，都能正常进行CSFB语音业务，因此排除终端问题。
3：无线参数排查
通过查看该站参数确认CSFB功能已开启，但查看GSM邻区关系时，发现漏配部分GSM频点。
处理方法:
由于GSM频点的漏配，导致重定向到GSM后UE无法找到对应的GSM服务小区。通过实地查看该区域GSM的频点有81、92、528、90、522，分别将河东湘潭国税局添加2G频点81、92、528、90、522，将河东新景源小区添加2G频点81、528、90到该站的邻区列表里，此时用iphone5s主叫10次均成功。
用户反映在人事局五楼办公室手机处于4G网络状态下主叫不通
投 诉 解 决措施
客服预处理
错误实例
无
客服分类
业务分类
投诉申告.基础通信.互联网业务.LTE
原因分类
网络原因
查证处理情况
用户投诉、日常测试发现：经过一段时间的测试观察，发现人事局五楼办公室由河东新景源小区和河东湘潭国税局覆盖。测试查看该区域2G频点有81、92、528、90、522，用IPHONE 5S 尝试主叫5次，存在首次呼叫不通的情况。
客户心理分析
影响日常语音业务
投诉处理难点
通过客户感知系统预处理，排查用户常驻小区，硬件无告警，需现场测试才能定位。
处理技巧分析
保证LTE基站相关数据的准确性，避免因为参数错误导致CSFB问题。
经验总结
如果出现CSFB问题，应该从基站、覆盖、参数方面一一排查。
案例主题
TD-LTE湘潭移动CSFB问题案例1
CSFB基本原理及信令分析
Redirect consists of 3 phases: – Redirection decision phase (generation trigger for redirect) – Selection of redirect target based on UE capabilities and redirect priorities – Redirect execution
MME配置的TAC—LAC配置错误
配置三： 1、假设UE在TAC20000下，同区域的2G LAC=20000。 2、在TAU或Attach 时，MME根据eNodeB上报的TAC20000，查询出该TAC所对应的LAC40000，对应的 MSS/VLR为ZZGS44。 3、MME发送LU给ZZGS44，但ZZGS44查询不到LAC40000， 位置更新拒绝，联合位置更新失败。 此时仅执行PS域跟踪区更新，无法执行CS域位 置更新。 MME的Attach Type为：EPS，正常联合位置更新的应为EPS/IMSI。
CSFB基本原理及信令分析
1 2 3
联合注册流程
联合跟踪去更新流程 CSFB主被叫流程
4
eNB参数设置
jinshaoguo
单卡双待与CSFB手机的注册
联合EPS/IMSI附着流程
a 如果UE支持CSFB功能，会发起附着类型”Combined EPS/IMSI Attach”的附着 请求。如果不支持CSFB功能，附着类型为”EPS Attach”。 b UE是否具有GERAN/UTRAN重定向能力，通知给eNodeB及MME c MME代替UE向MSS执行LU过程。 d 如果LU过程成功，SGs的状态为SGs-ASSOCIATED。为用户建立了SGs关联， 就是在VLR中存储了用户的MME地址，同时也在MME中保存了用户的VLR的地址。 e 如在联合注册过程中，MSS给用户分配了新的TMSI，却未收到SGsAP-TMSIREALLOCATION-COMPLETE，不影响该用户SGs的状态。CS Paging时用IMSI代 替TMSI。 f 如果UE驻留在GERAN/UTRAN时，MSS通过A/Iu正在Paging该UE。此时UE发 起联合注册，MSS会停止Paging，给MME返回SGsAP-LOCATION-UPDATEACCEPT 。 g LU过程不成功，MSS发SGsAP-LOCATION-UPDATE-REJECT给MME。VLR将 该用户的SGs状态置为SGs-NULL。在下一次联合注册成功之前，所有的CSFB被叫 被拒绝。
浙江绍兴联通CSFB接通时延大问题分析案例-梁刚
浙江绍兴联通CSFB接通时延大问题分析案例1．问题描述：2020年4月在工程站点开通单站验证过程中发现CSFB互拨中接通时延在7S左右，4月之前单站验证中CSFB互拨接通时延为5S左右，单站验收标准接通时延为小于6.2S。
2．问题分析：测试人员在不同场景下（城区、郊区、农村）进行CSFB呼叫接通时延验证，CSFB接通时延均在7S左右，部分场景在8S左右。
现场CSFB互拨并采集UE终端与基站交互信令，通过与之前正常接通时延UE信令对比。
发现主叫Call Proceeding至被叫收到PAGING消息进行ExtendedServiceRquest 的时间变长了2S多；正常时延的主叫流程为：异常时延的主叫流程为：对比此前验收通过的跟踪，和当前测试的数据，在此前的验收通过的数据中：从主叫侧CM Service Request到Call Proceeding的时延约1.6s；从主叫侧Call Proceeding到被叫侧ESR的时延约750ms；从被叫侧ESR到主叫收到Alerting消息的时延约2.7s；总体时延约5s。
作为对比，当前的测试结果如下：从主叫侧CM Service Request到Call Proceeding的时延约1.3s：从主叫侧Call Proceeding到被叫ESR时延约2.5s：从被叫侧ESR到主叫收到Alerting消息的时延约3.1s：因此，各阶段时延对比如下：对比多次测试数据，确认时延的主要增量来自于主叫收到Call Proceeding到被叫发起ESR 的阶段，该阶段主要是MSC的处理流程。
联合MSC侧工程师排查，确认MSC侧主、被叫分别存在一次智能网交互流程，且每次交互主被叫智能网耗时约2000ms以上，因此导致从Call Proceeding后到MSC下发Paging 的时延较长。
通过查询发现主被叫该智能网为短号业务。
3．优化建议：建议删除主被叫智能网短号业务。
4．优化方案及效果：在删除SIM卡的短号业务规避智能网交互流程后，再次测试CSFB时延基本在5s左右5．总结：呼叫测试中，由于智能网交互流程耗时较长，导致从主叫Call Proceeding到被叫收到寻呼的时延较长，从而导致测试整体时延长，建议核查智能网业务最近是做过否升级或版本更变导接语音通时延增大。
终端案例部分CSFB终端在弱覆盖环境下短信频繁重发问题案例分析
【终端案例】部分CSFB终端在弱覆盖环境下短信频繁重发问题案例分析一、故障现象用户反馈在使用过程中概率性出现短信重发现象，手机通信大师后台关于中国移动M811的详细情况如下：1. 地点：花都区三东大道飞翔商务大厦2.终端：增城客户手机；3.网络环境：所处4G网络信号比较弱，但又不会自动转到3G/2G网络4. 测试过程：终端在未打开数据连接的情况下，从16：21分开始发送短信内容到号码为的接收端，手机短信界面一直显示“正在发送...”，此时接收端则一直在接收短信“我们都要”的内容，直到16：35分结束，此时接收端一共接收了163条短信，被测手机才提示短信发送成功。
发送端和接收端的界面如下：=>二、故障原因分析2.1故障处理流程图：2.2 复测情况使用主流CSFB手机：华为D2、iPhone 5S、移动M811（商用版）、移动M811（高通改良版）进行现场复测：注：高通修改尝试次数和等待timer，将原始的每条240/5的发送频率改为150/50，即modem只负责在网络不回复ack的情况下retry 3次，而不是48次。
其他厂家大部分是按照3次或者5次来设计的重发流程。
高通发布了改良测试版。
2.3分析过程2.3.1终端侧根据RIL Log分析结论：由于终端一直未收到网络给回复的ack，导致modem启动重发机制。
而modem 重发设定240s的重试时间（5s一个周期），所以一条短信发到modem最多能重发240/5=48次。
可以通过修改重试时间与周期来减少重发的次数，但是为什么没有收到网络回复的ack还需要网络侧来调查确认。
在中国移动M811侧通过拨号*1973461#进行ril log和modem log的捕获，下面是modem log的分析过程：1、短信第一次发送后，终端定时等待网络回复rp_ackMSG 08:21:51.867 wms.c 01496 Putting 100 WMS_CMD_MSG_SEND (client 18, as_id 0, appInfo_ptr 0x0b9eecf8)MSG 08:21:51.902 wmscm_gw.c 00578 MO SMS Message Sent to MN 0MSG 08:21:51.902 wmsmsg.c 04214 wms_msg_send_gw() returns 0MSG 08:21:51.902 qmi_wms.c 03608 Ignoring send event until WMS_MSG_EVENT_SUBMIT_REPORT received2、终端未收到网络回复的rp_ack, 流程进入重发。
CSFB分析方法与实例
CSFB的分析方法及典型问题1 、CSFB问题处理思路1、基本信息收集：•CSFB问题发生地点•CSFB问题发生前后占用4G小区，TAC是否插花•CSFB回落前占用4G小区添加2G频点和2G邻区是那些•CSFB回落后占用的2G小区和频点•CSFB问题发生地点是否POOL边界2、CSFB问题主要原因：•功能开关CSFB功能没有打开•2G邻区或邻区频点没有添加•POOL边界问题•UE被寻呼期间位置更新时间过长超过10秒•4G弱覆盖/质差•2G小区本身故障/无线空口问题2、信令流程解析3、优化经验总结1.1信令优化步骤1、核对主被叫呼叫对应时间：由于手机时间不匹配，需核对时间确认主被叫寻呼对应2、找到主叫CSFB业务扩展信息，确认主叫占用LTE小区，在RRC连接释放内找到回落GSM 小区的频点信息：3、主叫发起寻呼，对应被叫收到寻呼Paging消息：4、主被叫振铃后，在2G侧正常呼叫流程1.2 日常CSFB分析优化处理经验总结日常优化工作主要从无线覆盖优化、参数优化、邻区优化，伪基站四个方面着手。
3 案例分析3.1 TAU流程冲突导致未接通案例1：被叫收到寻呼消息，LTE重选发起TAU请求【问题描述分析】主叫在11:52:50正常完成呼叫建立流程，被叫占用LTE小区沙坪坝饮水村-HLHA（TAC：13153）收到寻呼消息上发ESR（携带mobile terminating CS fallback or 1xCS fallback消息）和RRC Service Request的同时小区重选到沙坪坝饮水村2号-HLHA（TAC:13113）发起TAU流程，流程冲突导致回落流程失败至TDS小区导致未接通。
【处理建议】TAU流程无法避免，小概率事件，建议暂不处理。
案例2：TAU流程请求，被叫未收到寻呼消息【问题描述分析】主叫在14:36:11正常完成呼叫建立流程，被叫占用LTE小区江北金地126盘溪店-HLHB （TAC:13153)跨TAC重选到江北大石坝九村水塔-HLHA（TAC:13111)，TAU流程冲突未收到寻呼消息导致未接通。
关于非法基站导致CSFB失败端到端信令分析案例
问题描述（故障现象）组网环境问题原因分析名建立成功率（%）立成功率（%）率（%）率（%）重建比率（%）换成功率（%）换成功率（%）率（%）1 N M -火车站候车厅L D B -C H -1 199.9799.9799.930.190.5899.8299.5199.81 N M -火车站候车厅L D B -C H -199.899.8699.660.050.7798.2697.398.23从上表中可以看到我们可以看到这两个小区的LTE 重要KPI 指标全部正常，可以判断出现CSFB 失败的原因不在于LTE 网络，应该是在4G 与2G 的互操作过程中或者2G 网络呼叫中。
我们使用测试终端+2G 终端+CXT 测试软件在现场进行测试。
通过现场测试，使用2G 终端作为主叫，CSFB 终端作为被叫进行测试，一共呼叫50次，其中被叫失败11次，与我们在后台指标反映的指标一致。
从空口信令中可以发现，失败的CSFB 业务基本都有个共同的问题：回落之后UE 发起位置区更新请求，然后核心网拒绝位置区更新，CSFB 业务失败，可以简单判断，CSFB 失败的主要原因是GSM 侧出现问题。
业务失败的信令截图如下所示：详细分析目前现网的LTE 站点基本与周边GSM 站点的LAC 保持一致，以保持寻呼的连续性，由于出现失败时伴随位置区更新，我们对1NM-火车站候车厅LDB-CH-10和1NM-火车站候车厅LDB-CH-11的TAC 和周边GSM 站点的LAC 进行核查，全部都为34051，正常情况下不应该存在位置区更新。
带着这个疑问，我们对失败信令进行详细的分析，从测试LOG 的数据中导出一次完整的失败信令，并将GSM 小区收到的System Information Type 3中携带的小区数据标注在后面，详细信息如下：N oDi rStan dardLa y e r MessagePCTime携带小区信息1↓TDLT ERR CDLInformationTransfer16:29:20:9482↑TDLT EE MExtended service request16:29:20:950M3↑TDLTE RRCULInformationTransfer16:29:20:9514↓TDLTE RRCRRCConnectionRelease16:29:21:0085↓GSM RR System Information Type 416:29:21:3176↓GSM RR System Information Type 316:29:21:56211075-23417↓GSM RR System Information Type 216:29:21:7888↓GSM RR System Information Type 316:29:22:02311075-23419↓GSM RR System Information Type 416:29:22:2581 0↓GSMRR System Information Type 116:29:22:4951 1↑GSMMM Location Updating Request16:29:22:5011 2↓GSMRR System Information Type 216:29:22:7381 3↓GSMRR Immediate Assignment16:29:22:7571 4↑GSMRR Measurement Report16:29:23:0051↓GSM R System Information Type 516:29:25R3:1371 6↓GSMMM Identity Request16:29:23:2251 7↑GSMMM Identity Response16:29:23:2251 8↓GSMMM Identity Request16:29:23:4611 9↑GSMMM Identity Response16:29:23:4612 0↑GSMRR Measurement Report16:29:23:4752 1↓GSMMM Location Updating Reject16:29:23:6962 2↓GSMRR Channel Release16:29:23:9312 3↓GSMRR System Information Type 416:29:25:0012 4↓GSMRR System Information Type 316:29:25:08811075-23412 5↓GSMRR System Information Type 1316:29:25:2432 6↓GSMRR System Information Type 2ter16:29:25:4782 7↓GSMRR System Information Type 316:29:25:71534051-35722 8↓GSMRR System Information Type 416:29:25:9402 9↓GSMRR System Information Type 116:29:26:1763 0↓GSMRR System Information Type 216:29:26:4113 1↑GSMMM Location Updating Request16:29:26:4173 2↓GSMRR Immediate Assignment16:29:26:6063 3↓GSMRR System Information Type 516:29:26:8183 4↑GSMRR Classmark Change16:29:26:9063 5↑GSMRR GPRS Suspension Request16:29:26:9073 6↑GSMRR Measurement Report16:29:27:1573 7↓GSMRR System Information Type 5ter16:29:27:2903 8↓GSMMM Authentication Request16:29:27:3773 9↑GSMMM Authentication Response16:29:27:4954 0↑GSMRR Measurement Report16:29:27:6284 1↓GSMRR System Information Type 616:29:27:7604 2↓GSMMMLocation Updating Accept16:29:27:8474 3↑GSMMM TMSI Reallocation Complete16:29:27:8514 4↑GSMRR Measurement Report16:29:28:0984 5↓GSMRR Channel Release16:29:28:3184 6↑GSMGMMRouting Area Update Request16:29:28:5824 7↓GSMRR Immediate Assignment16:29:28:6964 8↓GSMRR System Information Type 2quater16:29:29:0224 9↓GSMRR System Information Type 2quater16:29:29:0415 0↓GSMGMMAuthentication and Ciphering Request16:29:29:8035 1↑GSMGMMAuthentication and Ciphering Response16:29:29:9525 2↓GSMRR System Information Type 316:29:30:04734051-99325 3↑GSMGMMRouting Area Update Complete16:29:30:4455 4↓GSMGMMRouting Area Update Accept16:29:30:4475 5↓GSMGSMMModify PDP Context Request16:29:30:4475 6↑GSMGSMMModify PDP Context Accept16:29:30:4515 7↓GSMRR System Information Type 316:29:31:62611075-23415 8↓GSMRR System Information Type 1316:29:32:7105 9↓GSMRR System Information Type 2ter16:29:32:9466 0↓GSMRR System Information Type 2quater16:29:34:5936 1↓GSMRR System Information Type 1316:29:36:2726 2↓GSMRR System Information Type 2ter16:29:36:5086 3↓GSMRR System Information Type 2quater16:29:38:1566 4↓GSMRR System Information Type 316:29:39:56734051-35716 5↓GSMRR System Information Type 316:29:40:19734051-99316 6↓GSMRR System Information Type 316:29:41:37834051-99376 7↓GSMRR System Information Type 316:29:42:32034051-99366 8↓GSMRR System Information Type 316:29:43:53334051-111106 9↓TDSCDMARRCsystemInformationBlockType316:29:49:8327 0↓TDSCDMARRCmasterInformationBlock16:29:49:8727 1↓TDSCDMARRCschedulingBlock116:29:49:8927 2↓TDSCDMARRCsystemInformationBlockType516:29:49:9327 3↓TDSCDMARRCmasterInformationBlock16:29:49:9527 4↓TDSCDMARRCsystemInformationBlockType716:29:49:9727 5↓TDSCDMARRCmasterInformationBlock16:29:50:0327 6↓TDSCDMARRCschedulingBlock116:29:50:0527 7↓TDSCDMARRCmasterInformationBlock16:29:50:1127 8↓TDSCDMARRCmasterInformationBlock16:29:50:1927 9↓TDSCDMARRCschedulingBlock116:29:50:2128 0↓TDSCDMARRCmasterInformationBlock16:29:50:2728 1↓TDSCDMARRCsystemInformationBlockType1116:29:50:2928 2↓TDSCDMARRCmasterInformationBlock16:29:50:352从第2条信令开始，Extended Service request 的详细原因值为service type：Mobile teminating CS fallback or 1xCS fallback，这标识这是一次CSFB-MTC，截图如下：第4条信令RRCConnectionRelease中携带回落的GSM频点，截图如下：第6和8条信令均为System Information Type 3，里面携带的小区为cellid和LAC信息已经标注在上表的最后一列，均为11075-2341，通过查询GSM小区的工参，11075不是正常的LAC号，由于回落后的小区LAC与LTE小区1NM-火车站候车厅LDB-CH-11的TAC=34051不一致，UE发起位置区更新请求，见第11条信令。
CSFB问题案例
LTE-CSFB异常原因总结及典型解决案例1 引言伴随着4G通信网商用话题的逐渐增温，运营商2014年年初酝酿的4G建设力度开始加速，使得4G网正式商用较快，用户规模增长迅速。
与传统的通信技术相比，4G通信技术以传统通信技术为基础，并利用了一些新的通信技术，CSFB就是有别于2G、3G引入的新通信技术，新技术也会有新问题，这就需要总结经验尽快处理问题，以不断提高无线通信的网络效率和功能。
2 不同场景下CSFB异常主要原因分析（1）网络覆盖正常，UE位于MSC边界，在4G网络下建立呼叫和被叫时，由于3G不同MSC 间未及时添加MTRF功能，被叫失败。
（2）网络覆盖正常，UE位于不同的LAC区，要进行跨LAC回落，由于3G和4G网络间LAC-TAC 未配置正确的对应指配数据，导致CSFB失败。
（3）网络覆盖正常，eNodeB侧CSFB数据配置不正确。
（4）网络覆盖正常，不存在跨MSC、RNC切换及回落，MME侧不支持CSFB。
如部分高通芯片只能设定语音优先或数据优先。
（5）4G网络或者3G网络覆盖弱，CSFB呼叫时延长或语音无法建立成功。
（6）2G/3G基站存在拥塞、干扰、故障等问题影响4G网络下的CSFB。
（7）UE使用插花基站信号，如占用拉远小区且TAC指向不一致。
3 CSFB异常解决建议（1）对MSC边界场景，在大规模商用前务必核查所有MSC是否开通MTRF功能，具备回落MSC与制定MSC间做好指定数据关系备份。
（2）位于3G网络LAC边界，即使做好MTRF指向功能。
当存在MME下发TA list内容或机制不合适的情况时，核心网下发Attach Accept消息中包含“CS域不可用”或“仅PS业务”或“MSC不可达”或者终端不主动发起附着。
因此需要在规划时，按LA预分配联系的TA号码资源，便于TA-LA配置。
（3）当eNodeB侧CSFB数据配置不正确时，导致终端无法联合附着在4G上，或者终端发起extanded Service Req后，网络侧无法及时响应。
LTE―CSFB技术解析及相关案例分析
LTE―CSFB技术解析及相关案例分析LTE（Long Term Evolution）是一种4G无线通信技术，其CSFB （Circuit Switched Fallback）技术是一种用于实现移动网络与传统语音业务的互操作性的解决方案。
本文将对LTE―CSFB技术进行解析，并通过相关案例分析加深理解。
首先，我们需要了解LTE和CSFB的基本概念。
LTE是一种基于OFDMA （正交频分多址）和MIMO（多输入多输出）技术的无线通信技术，其主要应用是提供高速数据传输。
而CSFB是一种从LTE网络切换到2G或3G网络以接收语音通话的技术。
由于LTE网络没有直接支持传统的2G或3G语音通信技术，因此需要通过CSFB来实现语音通信的互通。
CSFB技术的基本原理是，当LTE终端用户需要接收或发起语音通话时，LTE网络会将用户从LTE网络切换到2G或3G网络，以便进行语音通信。
这种切换会导致一定的时延，但是可以保证用户在语音通话时获得较好的通话质量和稳定性。
接下来，我们将通过一个案例来分析LTE―CSFB技术的应用。
假设地区的LTE网络已经部署并广泛应用，但是网络以前的2G和3G基站还在继续使用。
在这种情况下，用户在使用LTE网络上网时，如果接收到一个语音通话，由于LTE网络不支持语音通信，就需要通过CSFB技术进行切换。
具体过程如下：1.用户A正在使用LTE网络上网，等待接收一个重要的语音通话。
2.一旦有来电，LTE网络会将用户A从LTE网络切换到可用的2G或3G网络。
3.用户A可以接听或发起语音通话，保证通话质量和稳定性。
4.通话结束后，用户A可以重新切换回LTE网络。
通过这个案例，我们可以看出，LTE―CSFB技术可以实现高速数据网络和传统语音通信的互补和互联互通。
在实际应用中，LTE―CSFB技术已经得到了广泛的应用。
比如，中国移动在部署LTE网络时，采用了CSFB技术来保证用户在语音通信方面的体验。
CSFB案例4
案例名：MSC SGs接口采用IMSI寻呼导致被叫失败1、问题现象用户投诉：有时被叫无法接通。
终端：iPhone5S。
现场测试偶尔出现4G UE被叫能够回落GSM网络，但呼叫仍失败现象。
2、原因分析通过分析终端侧LoG，被叫4G UE在LTE网络接收到寻呼并回落至2G 网络，但是，待其返回寻呼响应Paging Response后，网络释放链路导致被叫失败，如下图所示：进一步分析终端侧及网络侧各接口Log，发现被叫失败原因在于MSC在二次寻呼时使用IMSI方式，MSC POOL场景下Paging response到另一个MSC导致。
3、问题按被叫流程的步骤描述如下：1)、终端在4G/2G完成联合注册，通过SGs接口，联合注册到SGs MSC，SGs MSC 为用户分配TMSI并返回给UE，UE保存记录2)、该用户被叫时，根据配置的寻呼策略, MSC在初次寻呼时，使用TMSI方式在SGs接口寻呼UE，给MME下发SGs-Paging（IMSI、LAI、TMSI、业务类型为CS）3)、MME根据用户的存储数据和状态，在S1接口下发寻呼消息UE空闲态时：语音业务下发S1 Paging（S-TMSI、CS域），短信业务下发S1 Paging （S-TMSI、PS域）UE连接态时：语音业务下发NAS 层CS service notificaion（TMSI标识），短信则可直接下发给UE4)、因为覆盖或其他原因，空闲态的终端没有及时响应寻呼，MME未收到该终端的CSFB呼叫建立请求（Extended Service Request消息），也未返回SGs-service-request给SGs MSC5)、根据配置的寻呼策略, SGs MSC将在寻呼间隔的定时器超时后，使用IMSI方式在SGs接口发起对该用户的二次/三次寻呼，给MME下发SGs-Paging（IMSI、LAI、业务类型为CS）6)、MME根据用户的存储数据和状态，在S1接口下发寻呼消息UE空闲态时：语音业务下发S1 Paging（IMSI、CS域），短信业务下发S1 Paging（S-TMSI、PS 域）UE连接态时：语音业务下发NAS 层CS service notificaion（IMSI标识），短信则可直接下发给UE7)、若终端此时接收到该寻呼，在LTE网络发起响应，发送Extended Service Request消息给MME；MME收到后，发送SGs-service-request给MSC，之后指示eNodeB CSFB连接释放，发送重定向命令指引终端回落8)、UE回落至GSM网络后，因为LTE寻呼使用IMSI，在GSM发送Paging Response （IMSI），若回落跨LA，则将先执行位置更新，发送LAU（IMSI、CSMT标识）消息给BSC9)、因核心网部署MSC POOL, 接收到该Paging Response（IMSI）的NNSF网元（BSC或MGW），看到IMSI，若IMSI寻呼时记录的IMSI-MSC映射表中没有发现相关记录，就按照负荷分担原则选择并路由Paging Response（IMSI）或LAU （IMSI）至MSC POOL内任意一个MSC10)、如果该MSC与UE联合注册/位置更新的SGs MSC不同，即收到IMSI寻呼响应的MSC与下发SGs-Papging（IMSI）的SGs MSC不同，被叫失败流程中第（5）步到第（10）步可参见如下示意图，图中示意了MSC SGs接口采用IMSI寻呼、MME也仅采用IMSI寻呼导致的被叫失败。
CSFB案例-20151230
CSFB信令流程
CSFB返回技术
1）终端自主FR：话音结束时触发，无需网络改造，需终端支持自主FR功能 3）2G4G小区重选：终端驻留2G，根据 2G广播的LTE邻区信息，满足信号强度条件 后直接重选回4G网络，对终端无额外功能 要求（目前未广泛要求） 2）2G3G4G桥接重选：终端驻留2G ，根据2G广播TD-S邻区信息返回3G，后根 据TD-S广播的LTE邻区信息返回4G。需终端 支持TD-S，且TD-S覆盖范围应大于TD-L
CSFB简介
现今LTE实现语音的关键技术主要有CSFB、单卡双待机、VOLTE等等。基于改造成本和商用终端出发的CSFB 技术已经成为移动TD-LTE语音主要过渡手段之一。CSFB主要通过新增SGS接口，实现了语音回落的同时， 也完成了2G和4G之间交叉数据传递的短信业务和寻呼业务。其中联合附着/位置更新、手机自主FR功能有 效缩短呼叫时延。典型的问题主要体现在MSC POOL边界TAC和LAC对应错误以及RRCConnection Release携 带频点问题导致的主叫可通，被叫不通；另一类主要问题，由于CSFB开关没开，GERANRANSHARE开关没 开、外部小区中的MCC、MNC信息标错等原因导致无法2G回落，需要到3G进行接入起呼；另外首次异频 呼叫后的挂机可能导致无法快速返回现象。总体来说，作为现有主要语音实现手段的CSFB还存在一些不边界TAC和LAC对应关系出错) 联合位置更新时，MME通过TA -LA -MSC的映射，为UE指定一个SGs MSC。同POOL内 如果TAC和LAC对应关系出错，建立呼叫请求时，则主被叫都只需要进行一次位置更 新，只是纯粹增加了呼叫时延。
但是如果在不同POOL之间的TAC和LAC对应关系弄 错，如果是主叫，则呼叫回落到相邻MSC POOL过 程中只新增一次位置更新，不产生异常事件；但 如果是被叫回落到相邻的MSC POOL进行paging响 应，由于paging 请求的POOL和Paging响应的POOL 不一一对应，则会产生未接通事件。如遇此类问 题，需要修改修正TAC和LAC的对应关系。
LTE网络CSFB指标优化小结及分析案例12-3
一、处理方法及思路此次重点针对CSFB被叫成功率进行优化，在提升被叫成功率的同时改善CSFB其他指标，如主叫成功率、回落成功率、寻呼成功率、时延等。
主要从以下几个方面进行优化，总结处理方法及流程如下：二、 工作量及成果问题分类：CSFB 被叫回落失败的主要因素有4G 弱覆盖、2G 站点故障、4G →2G 邻区规划不合理、POOL 边界等网络优化问题，从网络分布上看4G 原因占比较高。
4G 主要是邻区规划不合理造成。
整体工作量：8%1%0%2%1%1%4%0%74%4%1%4%0%原因分类（整体）pool 边界POOL 边界，GSM 站点过少pool 边界，邻区跨pool pool 边界，邻区漏配pool 边界，周围GSM 站点过少pool 外频点TAC 错误降低时延邻区漏配周边GSM 站点过少邻区过多邻区过少站点故障针对温州移动LTE网络CSFB短板指标进行系统的分析，并筛选出对全网指标贡献大的TOP小区进行重点分析和处理。
主要从4G->2G邻区频点过少（漏配）、4G->2G邻区合理性、（包括跨POOL、伪基站、过远冗余邻区等）、TAC->LAC映射关系核查三个方面分析和优化。
截止目前，共计完成125个小区错误TAC修改，109个小区4G->2G邻区频点增加，2276个小区的邻区重规划，删除冗余邻区20条等。
优化效果：从上图统计表可以得出，主叫平均时延从8月份的9218.9213ms，逐步缩短到9067.882ms，主叫时延缩短了151.0411ms。
被叫回落成功率从8月份的98.92%，逐步提升到10月的99.04%，但是从11月开始指标又下降到98.98%。
导致指标下降的主要原因为苍南区域站点纠纷和新开站点未按照规划数据配置，导致站点开通后指标较差。
三、典型案例LTE->2G邻区过少(漏配)案例：【问题描述】【分析思路】由于该小区被叫及回落有成功次数，排除CSFB开关及互操作参数问题；检查该小区告警情况：无告警，设备运行正常；检查TAC->LAC映射关系：映射关系正常，且不在边界；检查LTE->2G邻区关系：发现配置的2G频点过少，推断被叫成功率低可能为漏配2G邻区引起，如下图所示：（漏配频点566、46）【优化方法】增加LAC->2G邻区不合理（跨POOL频点）【问题描述】KPI指标监控发现，H770674瓯海便民服务中心宏站_1被叫成功率低及被叫回落成功率【分析思路】由于该小区被叫及回落有成功次数，排除CSFB开关及互操作参数问题；检查该小区告警情况：无告警，设备运行正常；检查TAC->LAC映射关系：映射关系正常，且不在边界；检查LTE->2G邻区关系，发现该小区配置了跨POOL的2G频点（48、52、46），由此推断被叫成功率低原因，详细见下图：【优化方案】删除跨POOL邻区频点（48、52、46），并同时增加漏配邻区，最终添加的2G邻区频点【效果对比】8月19日晚执行优化方案后，统计8月20日指标，被叫成功寻呼成功率及被叫成功率均提升明显。
呼市CSFB异常事件四个案例分析
呼市CSFB异常事件四个案例分析1、公交四公司北基站3小区附近因GSM频点配置不合理导致CSFB失败➢问题描述：公交四公司北基站三小区方向（方位角为330度）距离100米位置处发生，发生一次CSFB 失败事件，导致呼叫未接通，所处位置如下所示：➢问题分析：回放发生异常事件的层三信令列表，关键信令都予以红色方框标识，如下图：分析序列可得出基本情况如下：呼叫信令接续是正常的，基站给手机下发了RRCConnectionRelease信令要求重定向后，重定向的频点截图如下：查询网管的GSM频点和上述一致：手机也在收到重定向命令后1s左右读取到GSM网络的系统消息2ter，且最后一条是系统消息1，统计总共在GSM网络的持续时间为0.7s，之后迅速返回LTE网络，这说明GSM网络不稳定现象，手机无法正常驻留，为了查明本次回落时具体占用哪个GSM小区，通过查看GSM系统信息1中的频点数据：由上述截图看观察出，42号频点是本次呼叫回落GSM网络时手机终端所选的频点，为GSM基站公交四公司北-2小区，方位角为180度，也就是说42号频点处于公交四公司北基站的南边，并非手机用户所在的三小区位置方向，呈现GSM频点图如下：之所以出现这种不是选取最合适的GSM小区进行建立语音业务，这和目前的LTE网内语音业务呼叫流程有关，LTE现网实现语音呼叫是通过CSFB流程进行的，而且发送给终端的频点前都是盲重定向的，并非基于测量的，存在准确度问题，并直接关系到业务的时延和成功率，假如频点不合理会导致驻留GSM网络不稳定现象，因此有必要进行CSFB频点的优选，比如删除冗余的，增加必要的频点。
➢解决方案：删除公交四公司北-3小区的CSFB数据中的4、36、42、578号频点，增加560、589号频点。
2、鄂尔多斯大街上的南茶坊附近因越区覆盖和GSM频点配置不合理导致CSFB失败➢问题描述：鄂尔多斯大街与昭君路十字路口西边的南茶坊附近，发生一次CSFB失败事件，导致呼叫未接通，所处位置如下所示：➢问题分析：回放发生异常事件的相邻两次CSFB的层三信令列表，如下图：分析序列可得出基本情况如下：基站给手机下发了RRCConnectionRelease信令要求重定向后，手机也在0.492s后读取到GSM网络的系统消息4，接着是系统消息1，但于0.778s后返回LTE网络，在GSM网络是显示BCCH频点号为43，该频点为GSM立业大厦2小区的主频点，这个频点也是由RRC连接释放时所携带的重定向频点。
CSFB回落失败率优化案例—LTE小区TAC配置不合理导致
CSFB回落失败率优化案例—L TE小区TAC配置不合理导致——13141、13146小区处理报告一、CSFB侧问题小区挖掘问题小区数据来源：吉林移动CSFB信令监测系统所使用的功能模块：一级菜单：LTE寻呼黑洞分析；二级菜单：60s内CSFB回落黑洞小区分析；算法说明：在LTE网络下发寻呼消息后，60秒内，未在GSM核心网侧收到该用户的寻呼相应消息，而某GSM小区上报其他业务消息，则计为在该GSM小区上回落失败一次，回落总次数为在LTE 小区上下发寻呼消息总数。
二、13141/13146小区回落失败率指标详情13141、13146小区8月20日至9月17日指标趋势如下图所示，其中主坐标轴为：回落总次数、回落失败次数；次坐标轴为：回落失败率。
从下图中，可以看出恢复时间点为9月16日，回落失败率、回落失败次数明显下降，且回落总次数明显上升。
经优化处理后，指标恢复，用户感知上升，业务量提升。
三、问题定位、排查过程(一)GSM无线侧六维度指标分析注：六维度指标评估按星级进行评估，暂定分为三个等级，其中星级越多，则该维度性能指标越优越！三颗星表示优秀，两颗星为可能存在问题，一颗星为要重点解决的问题。
经评估，三道东1、三道东DCS1小区（13141、13146）六大维度指标基本正常。
评估完成六维度指标后，需要进行LTE至GSM回落的点对点分析。
(二)LTE至GSM点对点CSFB回落分析以9月14日指标为例，深入评估问题小区的点对点CSFB回落性能，详情如下(以下数据均取自吉林移动CSFB信令监测系统)：13141小区：13146小区：从上表中，可以看出，优化调整前 9月14日，LTE侧的小区73833985向13141、13146小区均存在大量回落失败。
73833985（外县小区）反查14日点对点回落指标，详情如下,可以明显看出13141小区存在两个LAC，其中LAC17317为13141小区实际LAC配置，17158为中创CSFB信令分析平台统计LAC。
CSFB典型问题分析
GSM回落小区不合理汽车在G312上由西向东行驶，占用通江大道L_3的信号。
在下图所示位置主叫手机发起呼叫，RRCConnectionRelease消息中携带了GSM频点信息。
但是手机未回落到共站址的通江大道上，而是回落到较远位置的塘头交通技校B （BCCH=70），如图2所示：然后手机测量到通江大道B（BCCH=65）并上报大量测量报告，请求切换，如图3：但是未收到切换指示，最终掉线。
掉线后手机未FR返回LTE，而是先重选到TDS，然后重选回LTE。
TDS重选到较远小区导致呼叫失败汽车在G312上由西向东行驶，主叫占用TDS小区汇坚国际T_3（频点10079），位置如图4所示：此时被叫手机驻留在LTE，占用的是汇尖国际DL_1的信号（RSRP强度-82dBm），测量到广益汽配城北L_1的信号强度是-105.9dBm。
主叫从TDS重选回LTE小区广益汽配城北L_1，而不是更强的汇尖国际DL_1。
之后手机进行异频测量，测量到汇尖国际DL_1的强信号，并上报测量报告。
但是由于是越区站点，邻区未配置，未能切换完成。
然后，主叫手机发起呼叫请求，回落到GSM小区向阳东C（BCCH=53）。
在向阳东C上手机发起CM Service Request消息，内含CSFB主叫请求标识。
但是手机未建链而是发起位置更新请求，该Location Updating Request消息中未包含CSFB请求标识。
原LAC是25105，目标LAC也是25105，位置更新成功后直接拆链，如下图所示：在本案例中存在两个问题：TDS重选到LTE，是如何判断重选到哪个小区的？回落到GSM发起CM Service Request消息后，为何会位置更新（同LAC）？回落到TDS导致呼叫失败汽车在红旗路上由南向北行驶，被叫手机占用旺庄L_1的信号。
收到寻呼后，手机向GSM回落，在RRCConnectionRelease消息中携带了GSM频点信息：其中BCCH=542是共站址的GSM小区旺庄DD。
奥体综合楼CSFB投诉问题分析报告-update
奥体综合楼投诉CSFB问题【问题描述】UE 从4G网络CSFB回落到未配置的2G小区上1月16日移动投诉在移动综合楼26楼使用华为D2在4G网络上打电话，能回落到2G(小区51)且能接通，但经常回落到2G后通话质量很差。
下午使用LG手机复测，也发现落到2G后通话质量很差，删除2g移动综合楼室分频点以外频点，复测回落2g后通话质量基本没问题。
但后来又说有问题，并通过核心网信令分析发现通话质量差时2g占用的是51频点。
晚上使用CDS测试软件和索尼测试手机在25楼进行测试，并记录log，回落时确实会回落到未配置邻区频点的小区上去。
【结论】本问题结论待研发深入分析后给出。
从UE log来看，被叫UE2收到RRC release后，接受到的SIB信息都是cell 61103（arcfn57）的，所以UE从57这个频点接入了。
根据现场测试同事反馈，当时确实观察到57这个频点比RRC release里面带的几个电平都要好，初步怀疑UE的行为，没有严格按照eNB下发的频点去回落，而是选了一个信号最好的频点完成了回落。
现场的同事可以做下测试看看，把这个没有配置的频点信号调弱一下，看看UE是否仍然会占用？如果不会占用，则证明UE是根据信号最强的小区来回落，尽管该小区不是eNB指定的，需要UE厂商根据协议调整行为（待验证）其他正常情况下，UE 都是搜索到了eNB下发的arcfn list里的某个邻区SIB信息，然后回落到指定小区，比如后面的48444（arcfn525）【问题分析】基于索尼测试手机复现的trace分析1、首先核查邻区关系，发现我们2g邻区没有配置51这个频点，基站侧2g邻区频点设置如下：2、UE log 分析，20:29:15.581到20:29:52.350时间段，一次被叫回落到了2g 57频点小区，该频点未在我们配置的邻区中，同时检查CSFB回落时基站侧下发的2G邻区频点，结果下发的频点和ENB侧配置数据一致：在20:29:17.995时UE却搜到了57频点的小区接下来UE在该小区获得了资源并完成了一次CSFB语音呼叫。
xx县郑家新村CSFB投诉分析
XX县郑家新村处理投诉报告问题描述：据XX县移动工作人员反映有当地用户投诉XX县郑家新村附近手机经常有短信来电提醒,经详细咨询具体现象为：在该区域经常有来电提醒，经常在该区域接不到电话。
测试分析：1、今日上午使用iphone5S 4G手机在现场测试，4G占用4AXGRX新干县郑家新村3小区，PCI为44，RSRP-85dbm，sinr25db，4G覆盖良好。
2、模拟用户行为进行手机拨打测试，在该区域主被叫20次，发现有3次未接通现象，均为主叫呼叫成功，但是被叫无响应，使用手机测试该区域2G信号，发现该区域由GSM 新干县粮食储备库1小区（CI：22151）覆盖，该区域属于TAC边界，如图所示：测试数据分析：手机在4G占用4AXGRX新干县郑家新村3小区，开始CSFB回落。
回落到GSM新干县粮食储备库1小区（CI：22151，TAC:26983），后下发了信道分配消息，同时伴随着下发了一个位置更新，位置更新请求的目标LAC为6496。
然后基站回复的位置更新接受消息里面下发TAC却是26983，请求位置更新的目标TAC与位置更新确定消息中下发的TAC不一致，如图：11：42：01：277 GSM直接信道释放，整个过程持续8秒钟，被叫未振铃（未接通）。
3、临时将4AXGRX新干县郑家新村基站TAC由6496修改为26983，现场进行复测，主被叫一直拨打电话均正常，被叫无响应问题得到缓解，考虑到4G新干县郑家新村基站处于TAC边界，修改TAC为26983后该基站1小区与2小区覆盖区域可能又会造成新的投诉。
解决建议：1、临时方案：将4AXGRX新干县郑家新村TAC由6496改为26983，暂时缓解投诉压力，但是该方案可能会导致4AXGRX新干县郑家新村1、4AXGRX新干县郑家新村2小区覆盖范围内出现新的投诉。
2、建议GSM将新干县新干化工厂、新干县大古山等LAC不合理的站点进行LAC割接，避免使用铁路专网LAC来减少寻呼压力。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
芙蓉里主叫成功信令：
1.UE主叫回落到3G后，RRC request显示LAC为41070；随后LA request消息LAC也为41070。
说明规划数据，对应的LAC是41070。
accept消息中，完成位置更新后的LAC为41004，说明UE回落到3G的LAC为41004。
3.在3G起呼的RRC connection setup消息中，显示3G小区扰码为275。
根据3G基础数据，，
LAC=41004，PSC=275, UARFCN=10713，可以查到华为3G基站：金源燕莎西，经纬度为116.2798，39.956947;从经纬度看，UE回落都在MSC2的LAC（41004）下3G基站，规划的是在MSC3下的LAC（41070），而主叫可以通过位置更新后在3G正常起呼，所以主叫CSFB业务可以成功。
芙蓉里被叫失败信令：
1.UE被叫回落到3G后，RRC request显示LAC为41070；随后LA request消息LAC也为41070。
说明规划数据，对应的LAC是41070。
accept消息中，完成位置更新后的LAC为41004。
3.3G起呼的RRC connection setup消息中，显示3G小区扰码为129和275，根据3G基础
数据，LAC=41004，PSC=275, UARFCN=10713和LAC=41004，PSC=129, UARFCN=10713可以查到华为3G基站：金源燕莎西，经纬度为116.2798，39.956947; 与华为3G基站:北方医院南，经纬度为116.289185，39.948212;从经纬度看，UE回落都在MSC2的LAC （41004）下3G基站，而规划的是在MSC3下的LAC（41070），导致被叫不能被正常寻呼到；CSFB被叫业务不成功。