联通lte问题案例库nokia厂家

1、湖南LTE 问题案例库目录湖南LTE 问题案例库11网络相关原因21.11.21.31.41.54G 用户被叫时被提示用户忙或者转至 1161142GGSN6 双承载无法上网问题3SGW restartcounter 变化导致用户无法被叫问题4SGSN 修改 4G PDP context CC 字段导致第一次 TAU 失败问题5SGW PDEL TIME 超时导致用户无法被叫，需升级 MME解决72终端原因82.12.2CSFB 后无法FR，参数调整解决8登陆 4G 网络，频繁出现无法做被叫的情况，终端侧设置 3GNET长沙酷派双承载为 WONET 解决。132.3苹果设置“勿扰模式”导致做被

2、叫无法接通153优化原因183.13.23.33.4CSFB 无法正常回落18不同运营商相同频段致使网未做 TAC 和 LAC导致无法驻留问题22长沙4G 无法做被叫，无线参数调整解决23LAC 边界用户语音回落被叫无应答问题，开启 MTRF 解决271 网络相关原因1.1 4G 用户被叫时被提示用户忙或者转至 116114问题现象:通过用户，发现某些用户在 4G 网络做被叫的时候会提示用户忙或者被转至116114 的提示。具体分析：为了确认是用户无法被叫的具体原因，进行 IPDU 抓包测试分析。通过 IPDU 抓包 log 分析，发现两种现象1）主叫提示被叫忙：MSC 发送 paging 消

3、息给 MME，MME 立即回复 reject cause=imsi detach for eps servi，并未向 eNB 发送任何消息with2）转接至 116114：MSC 发送 paging 消息给 MME，MME 立即回复 rejectwithcause=moobile termination cs fallback call rejected by the user，并未向 eNB 发送任何消息查看被叫在 MME 的状态，并无异常，设备无异常告警查看整个呼叫流程，并未发现信令的异常收集 MME 相关log 及配置信息提交研发根本原因:当前系统对于 UE 在 idle 和 conne

4、ct 状态转换时错误，造成 CSFB 失败解决措施：升级问题与结论：通过对于系统转换时会发生log 分析发现，当前系统对于 UE 在 IDLE 和 Connect 状态错误，对于 UE 的当前状态判断有误，从而对于 MSC 发起的 CSFB被叫的 Paging 消息响应错误，导致 CSFB 被叫失败。该问题属于当前版本(NS30)bug，需要升级解决。1.2 GGSN6 双承载无法上网问题问题现象：通过用户，发现当 UE 在 4G 网络进行发送彩信时，当 WAP 的 APN 是在 GGSN6 建立时，承载无法建立，最终彩信发送失败。具体分析：1，为确认 WAP 的APN 无法建立，在GGSN6

5、 上进行抓包测试2，在 SAEGW 上进行信令测试，并进行大量彩信发送测试3，当直接用 3gwap 附着网络建立承载时，彩信测试无失败4，当用非 wap 的apn 附着网络建立承载，彩信发送可能出现失败5，继续测试发现，非 wap apn 附着网络建立承载，并且发送彩信时建立的第二条承载都落在 NG6 上时，发送失败6，查看 NG6 的信令结果，发现彩信发送失败是的 3gwap 承载建立过程信令异常，正常情况下 S-GW 和 P-GW 选在同台设备时 S5 口信令不应该能看到才对，并且在 S11 口的信令交换也是异常的7，因NG6 刚完成 NG3.1 的升级，并且使用了新功能 single a

6、ddres，怀疑 NG31 的问题根本原因：经研发对日志及消息 log 分析，确认该问题属于 single address 功能与 service group 功能产生，导致承载建立失败解决措施：当前版本(NG3.1)下取消 single address 功能的使用问题与结论原因是 Single address mode 的负载均衡需要在 node 之间转发信令和业务数据，node 之间相互转发消息是基于 TEID。在同一个 service group 中的node 对于同一个用户无法通过原因是Single address mode 的负载均衡需要在 node 之间转发信令和业务数据，node

7、 之间相互转发消息是基于TEID。在同一个 service group 中的 node 对于同一个用户无法通过。1.3SGW restartcounter 变化导致用户无法被叫问题问题现象：通过用户具体分析：，发现部分用户在 4G 网络下被叫失败1）在进行 CSFB MT 多次测试进行问题复现发现：发现 MME 会主MSC 发送EPS Detach 消息，将该 UE 进行 Detach 操作2）当发生 detach 后，若 UE 主动发起业务请求，会发生第一次 ServiceRequest 失败，重新进行attach 到网络，进而进行业务操作，此时 CSFB MT 正常。3）当发生 detac

8、h 后，若 UE 不主动进行业务请求，此时 UE 一直处于 detached 状态，若有其它 UE 呼叫时，MME 会直接MSC 发送的Paging 消息，导致 CSFB MT失败。4）查看系统告警日志，发现在发生 MME 主动发起EPS detach 的动作时，系统有 221的告警，并且此时 S1 接口伴有大量的 MME 发起的 detach 消息。根本原因：SGW 发往 MME 的GTP 消息中带有RestartCounter 字段发生变化导致 MME 认为SGW发生重启（AHP 会看到大量 Notice=221），进而进行删除与该 SGW 相关的用户信息，处于连接态的会要求重新 Atta

9、ch，对于 Idle 态的，按照隐式去附着处理，所以当作为被叫时，MME 直接原因是隐式去附着，只有 UE 主动发起业务才能重新 attach 到网络，业务恢复解决措施：临时解决：诺基亚 MME 通过修改，对于SGW 导致的 Restart 不对用户进行detach 处理最终解决：SGW 进行升级问题与结论：SGW 发往 MME 的GTP 消息中带有RestartCounter 字段发生变化导致 MME 认为SGW发生重启（AHP 会看到大量 Notice=221），因诺基亚 MME 对于收到 SGW 重启的消息后，默认进行删除与该SGW 相关的用户信息，处于连接态的会要求重新 Attach，

10、对于 Idle 态的，按照隐式去附着处理，所以当作为被叫时，MME 直接原因是隐式去附着，只有 UE 主动发起业务才能重新attache 到网络，业务恢复1.4 SGSN 修改 4G PDP context CC 字段导致第一次 TAU失败问题问题现象：网优同事在进行日常测试时发现，经常出现 TAU 失败的现象。具体分析：1）针对网优同事发现的 UE TAU 到 4G 时会出现 TAU Reject，并且失败率很高，随之进行问题2）做多次 TAU 测试后，对信令消息解读发现，当 SGW 选在的 SAEGW 时，一定会失败，UE 必须重新attach，当Nokia 的 SAEGW 时，则成功3）

11、测试发现SGW 响应 MME 的 CreateSesResponse 消息中没有承载信息4）查看整个信令过程，发现 UE TAU 时消息中的 cc 字异常，值为 0，并不是 HSS 所签约的数据，根据整个 3/4G 切换流程怀疑诺基亚 SGSN 对 cc 字段处理有问题，发现该字段在从 3G 回到 4G 时被 SGSN 变为 0，5）随后与SAEGW 对于 CC 字段要求严格，0Request 进行工程师进行该问题确认，得到结论为字段，所以SAEGW 会对 CreateSes根本原因：当前 MME版本(NS30)在 UE 进行erSystem 切换后，对于 CC 字段的处理有误。解决措施：进行

12、系统升级问题与结论：当前 MME版本(NS30)在 UE 进行erSystem 切换后，对于 CC 字段的处理有误，导致无法正确将 UE 的签约数据中的 CC 值进行转发，因SGW 对于 CC 字段的处理机制有诺基亚 SGW 的处理机制（对于 cc=0 时会用系统配置的默认 cc 值进行覆盖），对于 cc=0直接进行处理，导致 TAU 失败。1.5 SGW PDMMEEL TIME 超时导致用户无法被叫，需升级解决问题现象:发现 4G 被叫问题，通过查询用户经常自动掉至 3G 网络，再回落最近有用户至 4G 网络。 最后就不能做 4G 被叫了具体分析：1、通过用户信令，发现当用户激活后，长时间

13、无上下行流量时超过 30 分钟后，到达诺基亚 SGW PDP IDEL TIME 时， SGW 踢掉该用户。 此时 MME 会向用户发起DetachRequest(type=2,cause=re-attach not required。此时用户会短暂的回落至 3G，大约 1-2分钟后，会回落至 4G。查看此时用户在 MME 中的状态发现 TAI 信息异常,为 4 个F。2、通过 MME信令分析：被 MME 踢掉后，短暂回落至 3G 后，重新 attach 到 4G MME 时，会从老的 sgsn取 context 信息。在此过程中，MME 的 MMDU 单元错误的用取到的数据覆盖attach

14、时带上来的 tai 数据(把它置为F)，然后 CPPU 处理 SGS-PAGING 时，从 MMDU 里取出错误的 TAI(F)，再转发给 IPDU，IPDU 向外转发 paging 消息时，会检查 paging 消息里的TAI 字段，以决定向那些 ENB 发送，当 IPDU 发现 TAI 字段为F 时，就会丢弃 paging消息，导致4G 被叫失败。根本原因:研发分析确认在 SGW PDP 老化时间到了后向 MME 发起用户去附着操作，如果用户回落到 3G，再次向 4G 发起 TAU 时，由于会更换 MME,新的 MME 在数据库内没能正确填写TAC 信息，导致 MSC 发向 MME 的寻呼

15、无法下发到用户所在的 TAC,因而导致无法被叫。解决措施：新版补丁 NS3.0 CD4001CM 内含有该问题的补丁。1 月 23 日凌晨已经完成 2 台MME 升级，2 月 5 日将完成所有湖南8 台 MME 升级，届时将彻底解决本问题。2 终端原因CSFB 后无法 FR，参数调整解决2.1 长沙问题现象:近日接到长沙运维反馈部分三星 S3、5 等出现在 CSFB 到 3G 进行语音后不回 4G 的现象。使用三星 9305也出现了相同情况：在通过PSHO 的CSFB 从 4G 回落 3G 后后出现了没能触发Fast Return 的情况，致使不返回 4G 网络。具体分析：针对以上情况，应客户

16、要求将 CSFB 的方式由 PSHO 改为 R8 重定向:重定向的 CSFB，后可以触发 FR 回 4G，初步解决了问题。根本原因:从LOG 分析中看到主要问题来自UE。在 PSHO 的 CSFB 过程中，在Relocation Request 里面，包含了 UE 所支持的 LTE band 信息。v860NonCriticalExtens erRAndoverInfoWith erRATCapabilities-v860ext ue-RATSpecificCapability eutra-RadioAcsCapability ue-EUTRA-Capability 81 20 00 00 0

17、8 04 08 7E BE 1F B9 01 10 00 04 74 A8H但是当 RNC 查询 UE 能力信息时，UE 没有上报它所支持的LTE band 信息。244RRC:UeCapabilityEnquiry 249-14:37:51.65RRC:UeCapabilityInformation14:37:51.81这样会让 RNC 认为 UE 是不支持 LTE 的，从而没有触发 fast return 的流程。而在 R8 的过程中，由于需要重新建立 RRC 连接，UE 总是能够正确的上报 LTE 能力信息的。解决措施：诺基亚 RNC 有针对 Smart Layer (FAST RETU

18、RN) 的 PRFILE parameter 002:1916PARAMETER CLASS: 2SYSTEM_FUNCT_CONFIGURIDENTIFIERNAME OF PARAMETERVALUEYESCHANGESIBILITY01916RN60_MA_410第二位字节，定义了是否检查重定向回 LTE 网络的UE 能力这个参数的修正，可以从根本上解决部分终端在 PSHO 的 CSFB 后不能 FR 回 4GValueoftheparameter002:1916RN60_MA_41 1)Descriptionx0 x (default)Redirection can be done o

19、nly to LTE frequency t belongs to LTE band t is indicated to be supported by the UE.x1xLTE frequency is not checked against LTE bands supported by the UE.在参数开启后，通过 PSHO 的 CSFB 回落 3G 的 S34G，没有上报 4G 能力，也能重定向回使用多款测试了许多次，没有出现无法 FR 的现象。问题与结论：目前使用重定向的 CSFB ，可以初步解决CSFB后不能触发 Fast Return 的情况最终，还是建议使用 PSHO 的

20、CSFB，因为它可以保证在 3G 网络的通话质量。同时需要开启 3G RNC 的 PRFILE parameter 002:1916 ： 0110这样可以忽略能力，保证这些终端能够触发 FR 回 4G 。2.2 酷派双承载登陆 4G 网络，频繁出现无法做被叫的情况，终端侧设置 3GNET 为 WONET 解决。问题现象:岳阳发现酷派登陆 4G 网络，频繁出现不能被叫的情况。而在相同的环境下测试，其他终端未出现类似情况。具体分析：为了查明酷派在 4G 网络中频繁出现不能被叫，在诺基亚的 MME 中了酷派的完整信令发现如下问题：1、端。登陆 4G 网络时上网时，存在两个APN，WONET 和 3G

21、NET。酷派是双承载终2、当因为做被叫，CSFB 至 3G 网络后，重新回落至 4G 时，酷派发起的 TAU 请求消息中缺失了 3GENT 这个 APN，只有WONET 一个 APN。发起的 Tracking area update request 消息中 EBI=6（3GNET）是 inactive 的。发起的 Tracking area update request 消息中 EBI=5（WONET）是 active 的。3、而后续 3G SGSN 向 4G MME SGSN CONTEXT RESPONSE 消息中可以看到是有两个APN，即WONET 和 3GNET。4、因 TAU 消息中

22、 EBI=6 是 INACTIVE，MME 后续发起对 EBI=6 的 delete消息，即删除 3GNET 这个 PDP CONTEXT。sesrequest5、但是最还是以 3GNET APN 来建立PDN 连接，因 MME 中已经没有 3GNET 这个APN了，所以承载建立就失败了。最终终端不能正常的回落到 4G。根本原因:终端从 3G 回落 4G 过程中，发起的 TAU 请求信令中异常的丢失了 3GENT 这个APN，而后在建立 PDN 连接中，却又使用 3GNET APN 建立默认承载，导致默认承载建立失败。最终不能正常的回落到 4G，导致 4G 被叫失败。解决措施：因酷派是双承载终

23、端，在终端设置APN 处,把 3GNET 设置为WONET。上网时就只激活WONET 一个 APN，避免在 TAU 过程中丢失 APN，最终避免 4G 被叫问题。2.3 苹果设置“勿扰模式”导致做被叫无法接通问题现象:1 月初省公司某位话。反馈，在开会期间有几个人打他，均没有接到电具体分析：通过调取当时的博瑞德的分析发现，主叫呼叫了早释。全部正常，在被叫阶段用户进行核查被叫阶段的博瑞德呼叫，从上可以看到，被叫呼叫信令正常，但在Alerting 后1 秒钟收到对端发来的 Disconnect 消息，消息的原因为“User busy”。用户忙测试现象通过模拟设置并测试分析发现，苹果有“勿扰模式”设

24、置。当设置成：手动启用该模式；同时选定好静音模式开的设定时间（如从 XX 点到 XX 点之间开启静音模式）；设置是否启动重复来电则不设置为静音的选择（启用后，相同来电者在三分钟内的第二个来电不会被设为静音）；静音模式选择是总是还是仅当启用。已锁定时当你有拨”，而你在你设置的设定时间内打进来时，对方会听到“对不起用户正忙，请稍后再机不会直接在上显示有未接来电；如果在三分钟内第二次拨打你的，则能正常接通。如果三分钟后第二次拨打你的，则与第一次拨打的提示一样。由于不响铃，只是在上显示未接来电的提示，导致用户感觉没有接打成功。问题与结论：根本原因为智能科端如苹果有“勿扰模式”设置，只要用户开启该模式后

25、，有主叫用户拨打该后，被叫系统会在主叫接通后会自动进行，所以主叫提示为“对不起用户正忙，请稍后再拨”，但实际上整个呼叫已正常建立。如果在设定的时间内拨打二个，则系统不会主动。3 优化原因3.1 不同运营商相同频段致使CSFB 无法正常回落问题现象:1 月 6 日湘潭韶山永义、区域陆续有个别用户反映在镇上偶尔能占用上 4G，但上网速率很慢，在 4G 拔打后无法占用 4G 的情况，过很长时间才能回落至4G，而在韶山县城区域无此问题。反映的区域如下：具体分析：为了确认是用户回落 4G 问题，核查如下：永义、为湘潭乡镇站点，入网较早，在 11 月就已入网，对两站的单站验证过程中，上网速率与 CSFB

26、回落都正常，由于近期 LTE 未进行割接及其它操作，因此 LTE 侧的参数可以确保正常；查看 LTE 的运行状态及告警情况，未发现异常情况。由于两站为覆盖乡镇站点，日常用户较少，检查两站的运行指标也未发现异常；区域近期新开了 W 站点，通知 W 优化，对 3G 关于 LTE 的参数及开关核查，反馈W 方面无问题；通过以上核查，未找出具体原因，需现象测试，以确定的真实性及问题产生的原因。网优组于 8 日对韶山测试现象现场测试，发现如下现象：永义区域进行了测试。发现占用韶山市工行小区后，信号SINR 明显偏低，发起业务速率偏低；CSFB 存在无法回落的情况，能正常回落的概率在 20%左右，不能回落

27、概率达 80%。不能回落时需重起，才能正常占用 4G。能正常回落时延较长，回落时延达到 10S 以上。测试问题排查1、测试中邻小区内新增加了 PCI 为 57、58、59 站点，且信号好于主服务小区，下行频点都为 1650，在信令中发现系统中发生测量成不了切换。对周边和工参信息无此站点信息。，A3 事件不停上报且完2、为了排除是否新建站点没有更新数据，进行了以下操作，闭锁主服务小区LHF-工行站点，检查是否会占用 PCI 为 57、58、59 的站点。经测试占用了PCI 为 57 小区后，无法发起业务，情况如下：3、从信令中发现占用PCI 为 57 的站点后，UE 向ENODEB 发起 RRC

28、CONNECTIONRE 消息，UE 又重新发起随机接入。随后接入失败，启动了异频测量，重选至 1825 电信频点上，然后建立连接失败。4、从信令中分析，NOBLE NETWORK CODE 为 00，为中国移动的网络识别号，怀疑移动使用的频点。通过测试定位出，在、永义周边移动使用的 LTE 频点，LTE 受到干扰，造成 4G 回落与上网速率慢。解决措施问题定位后，湘潭运维部门与移动公司协商，确认移动在永义与设了两个试验站点，使用的频率为 1840-1860，经要求移动对频点进行更改后，对现场测试，速回落正常：问题与结论重定项回落时终端在 LTE 侧发起呼叫或者接收到寻呼，LTE 网络通过 R

29、8 重定向命令（RRC Connection Release）下发 3G 频点，指引终端回落到 3G 网络。当接入相同频点且非所在运营商时，无法从而导致接入失败，无法正常回落。3.2网未做 TAC 和 LAC导致无法驻留问题问题现象:2014-05-16 日测试在 517 前在“海底世界”保障时发现，和 D2 等终端无法占用 LTE 网络，经过网和无线侧共同抓取信令 log 分析得出，由于此区域新开的站点使用了一个新入网 TAC 号，没有及时通知网在 MME、DNS 上做TAC 和 LAC关系，导致和 D2 等终端在 MME 上失败。具体分析：测试测试分析：网优工程师到现场用和 D2 终端测试

30、显示无信号，连接 CDS 后显示，不停的上报随机接入失败。从KPI 分析：KPI 上查看 PRACH 指标发现，成功率为 0。网侧分析：网在抓 log 时发现，每次做附着时，网马上被拒，提示网络不可用，网经过分析得出，配置的 TAC 号不在 MME 配置的 TAC 列表内，所以导致用户无法接入。根本原因:配置的 TAC 号不在 MME 配置的 TAC 列表内，所以导致用户无法接入。解决措施：网将新入网的TAC 加入到MME 列表内，并根据TAC 和LAC 物理覆盖范围，在 MME、DNS 上配置 TAC 和 LAC 的关系。问题与结论：网配置完成后，通知前台再次测试验证，测试在现场测试反馈，手

31、机可以正常驻留网络，并且可以正常做数据业务和 CSFB 语音拨打测试LNBTSIDLRIDDATETIMEBTSNAMEPRACH_SUC_RATOPRACH_SUCPRACH_ATT72216612014/5/15LFH-长沙县世界之窗新天鹅城堡006872216622014/5/15LFH-长沙县世界之窗新天鹅城堡005272216632014/5/15LFH-长沙县世界之窗新天鹅城堡004772216712014/5/15LFH-长沙县世界之窗办公楼004272216722014/5/15LFH-长沙县世界之窗办公楼003472216732014/5/15LFH-长沙县世界之窗办公楼00

32、3472216412014/5/15LFH-长沙县 YD 世界之窗海底世界路灯003072216422014/5/15LFH-长沙县 YD 世界之窗海底世界路灯002972216432014/5/15LFH-长沙县 YD 世界之窗海底世界路灯00264G 无法做被叫，无线参数调整解决3.3 长沙问题现象:长沙运维反馈 4G 网络下漏接的，智能出现 4G 脱网和语音被叫提示正忙现象。在 CSFB 从 4G 回落 3G 后，FR 回 4G 时，出现了后再次上发 TAU 才成功上发 TAU 没反应情况，相隔 10S 之在这 10S 时间内，显示的是 4G 脱网和语音被叫提示正忙这两次 TAU_req

33、 网侧在十几秒后才回 TAU_accept 消息，这会导致这段时间内不能处理寻呼，从而接不到来电。具体分析：从 UE 测试 LOG 分析中看到出线问题bar 概率 5%，应该是网络设置问题。被 Bar，SIB2 中配置了 ac-barringinfo，被根本原因:ac-BarringFactor 参数是为了避免95%这会随机5%的正常业务接入超负荷工作而设置的，规范中是可选参数，最大取值在现阶段 4G 网络并不繁忙的情况下，为了避免不必要的 4G 用户准入限制，建议取消 4G 网络中 ac-barring 的参数设置，保证 100% 接入不被BAR 住；解决措施：针对UE 测试中的 SIB2

34、中配置问题，检查参数如下:1 ac-BarringFactor Nokia 参数对应是 probFac 现网为 95%Defines the probability for a UE to establish an RRC connection.The acsprobability factor defines the probability for a UE to establish an RRCconnection.The UE draws a random number (0 = rand 1). If rand is higher n the value indi-cated by t

35、he acs probability factor, the UE considers theacs barring check to be unsucsful.2 规范说明如果 UE 建立 RRC 连接的目的是移动始发呼叫（mobile originating call）：如果定时器 T302 或T303 正在运行：认为接入该小区受限。否则如果SystemInformationBlockType2 包含 ac-BarringInfo，且 ac-BarringForMo-Data 存在：如果 UE 有一个或个范围为 1115 的接入级别（在 USIM 中），按照3GPP TS 22.011v9

36、30-2009 和 3GPP TS 23.122 v930-2010 的要求，该范围对 UE是有效的；其中至少一种接入级别，ac-BarringForMo-Data 中 ac-BarringForSpelAC 的相应比特位值为 0，则认为可以接入该小区。否则：在 0 rand 1 范围内均匀随机抽取 rand 值；如果rand 低于ac-BarringForMo-Data 中ac-BarringFactor 所指示的值，则认为可以接入该小区；否则认为接入该小区受限。否则：认为可以接入该小区。因为 ac-BarringFactor 参数，95%是这个参数的最大值了，如要以保证 100% 不被 B

37、AR住，建议将这组参数删除。选定一个小区，将 ac-BarringFactor 参数删除，解除 4G5%的 BAR 设置。参数修正后，测试了几百次呼叫，没有出现被叫无法接通现象。问题与结论：长沙 4G 全网进行了 ac-barring 的参数修正，避免 4G 用户的准入限制到目前为止，经过现象。半个月的，没有再出现由于准入限制造成的 4G 用户无法做被叫3.4 LAC 边界用户语音回落被叫无应答问题，开启 MTRF 解决问题现象用户在衡阳御景新城 4G终端经常出现被叫无法接通，而做主叫正常，能正常重定向至 UMTS 并在呼叫结束快速返回 LTE，但在做被叫时经常出现提示用户暂时无法接通的情况。

38、处理过程现场测试发现用户所处位置 3G 信号比较杂乱，驻留小区有归属 LAC58204 的WD-蒸湘区蒸水花苑-3，WD-八角亭-2，归属 LAC58205 的 WD-蒸湘区雨母校区美化树-1,LAC58204 属于 HYMSS1，LAC58205 属于HYMSS3。4G 信号驻留小区为 LFH-蒸湘区客运站-3，当用户做被叫回落到 WD-蒸湘区雨母校区美化树-1 时就出现无法接通现象。置LAC，TAC及MSC用户所处位分布情况：被叫漫游前转特性，简称 MTRF（Mobile Terminating Roaming Forwarding），用于解决 MSC 边界（非 POOL 组网）或 MSC

39、 POOL 边界 CSFB 被叫跨 MSC 或跨 POOL 呼叫失败的问题，使呼叫能够继续接续，从而提高呼叫成功率。MSC 边界（非 POOL 组网）或 MSC POOL 边界 CSFB 被叫跨 MSC 或跨 POOL 呼叫失败的触发场景：TAI-LAI 规划错误，存在 TAI 跨LAI 情况，且两个 LAI 分属不同 MSC（非 POOL 组网）或不同 MSC POOL，此种场景建议优先通过优化 TAI-LAI 对应关系来解决；TAI-LAI 规划正确，MSC1 的位置区 LAI1 和 MSC2 的位置区 LAI2（非 POOL 组网）存在交叠区域，或 POOL1 内 MSC1 的位置区 L

40、AI1 和 POOL2 内 MSC2 的位置区LAI2 存在交叠区域， CSFB 被叫回落时：当 LAI2 与 LAI1 为同频覆盖，LAI2 信号好于LAI1；当 LAI2 与 LAI1 为非同频覆盖，但 UE 测量发现LAI1 的信号强度低于门限值，而 LAI2的信号较好高于门限值；在这两种情况下，UE 都会在 LAI2 接入 MSC2 导致被叫失败。MTRF 原理：MTRF 的实现有两种方式：MSC 方式（当前阶段）、MSC+HLR 方式。2.1 MSC 方式 MTRF 流程图：场景 1：普通非 POOL 组网，oldMSC 与 newMSC 为两个独立的物理 MSC。流程简明：1、 流程 11：UE 在位置更新消息中，携带 CSMT 标识为 CSFB 被叫，携带 TMSI 与 PLAI用于流程 12 new MSC 发起取局间识别流程；2、 流程 12：New MSC 发送Send Identification 消息到Old MSC，并在 SI 消息中携带MTRF Support（表示本局支持 MTRF 功能）、New msc Number、New vlr Number信元（用于 old MSC 发起