LTE案例(数据andCSFB).docx

1. 案例一：远见智能第1小区下载速率偏低问题u 【现象描述】在远见智能基站1小区下载速率偏低（20Mbps), RSRP很高，下行SINR很好，MCS偏低，16QAM比例很高、BLER很低。【问题分析】 关闭ATB/UL PC等问题依然存在。 关闭远见智能第2、3小区问题依然存在； 初步分析问题不是由于干扰问题，检查SCF文件发现DLTARGETBLER设置为1%，可能与此有关，由于BLER要求太高，OLLA会调低MCS以保证BLER目标，而对于FTP等业务不需要如此高的BLER要求，并且会导致不能够使用高阶MCS及64QAM，从而导致下载速率偏低。u 【解决方案】 将第1小区恢复成DLTARGETBLER=10%。2. 案例二：室分小区随机接入失败-误包率u 【问题分析】 1. 怀疑定时器设置或者切换参数问题，但是核查参数发现336和337的定时器设置相同，切换参数也相同，故排除定时器设置和切换参数问题； 2. 怀疑无线环境问题，336小区和337小区做的是同层的2个小区，在同层测试RSRP/RSRQ/SINR都比较好，排除无线环境问题； 3. 怀疑随机接入参数设置有问题，由于336向337切换都正常而反向切换337向336会出现失败，因此对比这两个小区的PRACH参数，发现prachConfigIndex参数不同。将336小区的prachConfigIndex从51修改到3，多次测试切换成功率和接入成功率明显提高。4. 进一步定位发现海思终端在prachConfigIndex=51(preamble format 4)时随机接入的成功率较低。u 【解决方案】 prachConfigIndex与preamble format对应表如下： prachConfigIndex=51时，对应的preamble format为4，prachConfigIndex=3时，对应的preamble format为0。u 【解决方案】preamble format 规范定义的格式如下： preamble format 4时PRACH在UPPTS发送，这种格式的CP时域长度和Sequence的时域长度都比preamble format 0小很多，被基站成功解调的几率也小很多，所以选择format 0会比选择format 4切换成功率高。因此修改参数prachConfigIndex从51修改到3。问题解决。3. 案例三：初始接入MSG1多次发送未响应的处理案例 1 问题描述 在短呼测试中，出现UE发出attach req和RRC Connection Request后未收到RRC Connection Setup，造成呼叫未接通的情况，查看路测信令，如图1所示，在小区PCI11，8次msg1发送未收到MSG2。 图1 MSG1多次重发无响应 2 原因分析 首先检查后台告警此时无GPS失锁告警，排查上行交叉时隙干扰导致的MSG1解调失败。在路测软件上查看起呼失败时的接收电平和信噪比，下行RSRP为-91 dBm，接收电平良好；SINR较差-9.8 dB，说明起呼点无线信道质量较差。如图2、图3所示。 精诚服务 TD-LTE 无线侧专刊 2013 年第 1 辑 17 图2 接入失败点RSRP 图3 接入失败点RS-INR 在无线信道质量较差的位置起呼，基站收到的PRACH信号过弱，导致基站侧将接收的PRACH信号当做无用信号不解调，造成MSG1无响应。通过降低“eNodeB对PRACH的绝对前缀检测门限”，提高PRACH信号的检测概率，在上行无线信道质量较差的情况下，提升MSG1正确解调的概率。 3 处理过程 将“eNodeB对PRACH的绝对前缀检测门限”从2000改为50，修改后进行短呼测试，RRC Connection Success为100%。在小区PCI11，从MSG1发送的间隔上观察，再未出现MSG1重发无响应的现象。如表1所示。 参数：eNodeB对PRACH的绝对前缀检测门限 PRACH Absolute Preamble Threshold for Enode B Detecting Preamble 取值范围：1-65535 4. 案例四：调度不满a) 传输问题l 传输明显丢包；l 传输端口模式配置错误；由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M，将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。l 传输链路不稳；b) 参数设置问题：上行BO设置不合理；c) 测试点空口环境查，BLER高导致速率持续偏低；d) 传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低；e) 终端问题l 终端性能问题导致业务长时间保持中收到数据处理不过来而丢弃，引发重传；l 终端反馈0窗口报文，导致速率偏低。5. 案例五：TD内部干扰【问题描述】在对师大食堂站点进行SSV验证时，出现UE（HISI E5776）无法接入的情况，UE显示“无服务”，信令流程如下图所示。此时的参数配置如下：SubframeAssignment=2、SpecialSubframePattern=7、TimeOffset=700000，后台查询，该站点存在严重上行干扰。【问题分析】与GSM900一样，TD-LTE的干扰也分外部干扰和内部干扰两大类，外部干扰包括TD-S同频阻塞干扰、DCS阻塞/杂散干扰、GSM谐波/互调干扰、天馈和器件故障导致干扰以及其他未知干扰；内部干扰包括TD-LTE同频干扰和TD-LTE主设备故障引起的干扰。对此，需逐一排查，同时也须验证如何设置时隙配比和TimeOffset才能规避TD-LTE与TD-S之间的互相干扰。【排查步骤】步骤1：验证是否由主设备故障导致干扰初始连接加入200W负载干扰截图干扰截图结论：TD-LTE设备正常，干扰可能来自合路器、1/2跳线、天线或外部。（注：干扰判决门限-116dBm。）步骤2：验证干扰是否由合路器引起初始连接RRU（F）直连基站天线干扰截图干扰截图结论：合路器性能正常，并非干扰源。步骤3：验证干扰是否由基站天线引起RRU（F）直连基站天线RRU（F）直连吸顶天线干扰截图干扰截图结论：由后台干扰数据分析，RRU（F）直连吸顶天线后干扰减弱，但考虑到吸顶天线的增益为3dBi，小于基站天线增益17dBi，干扰减弱在情理之中，至此判定基站天线性能正常，并非干扰源。步骤4：验证同站点的DCS1800、TD-S是否干扰TD-L开启DCS1800; 开启TDS开启DCS1800; 关闭TDS连接方式关闭DCS1800; 关闭TDS结论：同站点DCS1800、TD-S并未对TD-L造成明显干扰。步骤5：验证同站点的GSM900是否干扰TD-LGSM900开启连接示意图GSM900闭站结论：同站点GSM900并未对TD-L造成明显干扰。补充说明：1、 排除TD-LTE同频干扰在整个排查过程中，除师大食堂_3开启之外，同站点师大食堂_1、师大食堂_2及其他TD-LTE（F）站点均处于关闭状态，故排除LTE同频干扰。2、 外部扫频本次外部扫频使用的是安利MS2732B扫频仪，在开启均方根检波时，无论设置VBW/RBW为何值，其自然底噪均在-100dBm左右，该底噪电平甚至强于师大食堂_3后台统计的干扰电平，所以其扫频结果参考价值不大，建议采用底噪小于-120dBm、灵敏度更高的扫频仪进行扫频。3、 ENodeB版本升级后问题得到解决。6. 案例六：速率不稳定问题分析a) 问题描述某站-3小区覆盖的区域RSRP在-60,86之间、SINR在23,33之间，BLER及双流MCS正常，但是速率常常低至10Mbps以下或无速率。问题地点如下：b) 2.问题分析问题区域由某站-3小区（PCI 329）覆盖，该区域信号较强，无线环境相对较好，RSRP平均值在-75dbm左右，SINR平均值在-25dB左右，BLER也正常，但是下行速率不稳定，有时候会降低至10Mbps，甚至完全没有速率。如上图所示，该时刻RSRP为-66dbm，RSRQ为-3dB，SINR为33dB，但是RB数只有16，下行速率为0.31Mbps。下图为问题路段速率图：c) 3.问题排查问题小区覆盖路段RSRP、SINR好，BLER及双流MCS均正常，但是速率上不去。对此做了以下排查工作：1、 检查了后台无线参数（邻区配置、功率、带宽、时隙配比等）及告警，未发现异常；2、 更换电脑及测试终端，问题依旧；3、 怀疑BPL单板故障，复位BPL，问题依然存在；4、 远程telnet登录基站CC单板，复位板件，问题依然存在；5、 更换FTP服务器进行测试，问题依旧；FTP+迅雷多线程下载，问题依旧；6、 上站检查RRU与天线之间馈线的线序，发现线序有误，RRU4口接到了天线的8口，RRU8口接到了天线的4口。如下图所示：怀疑是天线线序接错，使得数据流和BBU PORT口映射错误导致下行速率不稳定，故联系工程人员将线序进行了调整，调整后速率恢复正常，没有再出现速率不稳定现象，如下图所示：d) 4问题处理在上面的问题排查中，将可能影响TD-LTE下载速率的几个相关因素进行了排查，最终将问题原因定位在天线与RRU之间的线序。工程人员将线序调整正确后，复测发现速率不稳定的现象得到了解决。在以后出现速率不稳定问题时，建议可以检查RRU与天线之间线序，提高问题排查效率，提升TD-LTE的网络指标。e) 5原理目前常规定向智能天线有8个天线阵元,提供8个通道，共8根馈线，第9根线为校准线，其通过内部的耦合网络与8个通道相连，进行基本的校准。8天线线阵双极化天线与RRU通道映射关系如下图所示：其中天线1至4端口为-45极化，依次连接RRU TRX1至TRX4，映射数据流Data1至Data4，汇聚到BBU的PORT1；天线5至8端口为+45极化，依次连接RRU TRX5至TRX8，映射数据流Data5至Data8，汇聚到BBU的PORT2。硬件连接关系、软件数据流走向和端口之间的映射关系相对固定，不能随意配置。7. 案例七：调度不满导致下载速率低问题问题描述：近期，在网格大会战过程中， LTE网格组发现多个站点在无线环境良好的情况下，下载速率无法达到峰值的情况，如下为金陵城二-1小区测试速率，速率始终只能在50M-60M上下。而该站点的配置在正常情况下应该在80M以上。共发现该问题的有：郭家山二搬迁、新生圩港、金陵村二、伊刘村、浦口二、柳塘村、浦江学院、燕江路、宝塔街T、大桥村、浦口审计学院试扩、林家凹试扩等12个站点。问题分析：针对该问题进行了长达1个月的反复抓包、测试定位，分析发现引发该问题的原因有多种情况，下面是详细分析。1. 无线侧初步分析l 排除终端和笔记本、FTP服务器问题：对这几个站点，进行更换终端、笔记本等方法进行测试，现象一样，且同样的笔记本、终端在其他站点上速率正常，可达到峰值。排除这方面的问题l 排除无线环境因素:测试时对测试位置进行多次选点，在RSRP/SINR等都远大于极好点的位置进行测试，MCS等级可基本维持在27以上，但是速率表现一样。同样的位置进行UDP灌包，速率可达到峰值。如下图，至此可基本排除无线环境问题。l 测试组对问题站点的小区PRB数限制为48/24，测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上，怀疑进入基站的数据不足。l 在基站的S1口做镜像抓包，同时在FTP服务器上也做WIRESHARK抓包，发现S1口的下行数据存在乱序和丢包的现象，丢包率大约为千分之一，这个有可能导致速率的下降。金陵村二 伊刘村2. 传输链路不稳及丢包问题根据以上分析，首先怀疑传输侧问题，将存在问题站点提交传输分析，传输侧反馈郭家山二搬迁、新生圩港链路不稳，并进行处理；燕江路传输侧存在明显丢包，并对异常进行处理；根据传输侧反馈，项目安排复测：新生圩港和燕江路问题解决，郭家山二搬迁1、2小区速率恢复正常，3小区下载速率依然较低；由于同站所有小区共用传输，因此该站3小区问题非传输导致；站点中兴答复当前版本郭家山二链路不稳，已处理3.20.01新生圩港链路不稳，已处理3.20.01燕江路存在明显丢包,已处理3.20.013. 参数设置问题 传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村二存在同样问题，修改后也恢复正常。4. 传输侧带宽设置不合理由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M，将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。对全网进行核查发现还有浦江学院、浦口审计学院试扩、林家凹试扩等站点存在同样问题。传输侧反馈如下，经处理几个站点均恢复正常：站点中兴答复伊刘村传输侧配置为强制100M浦江学院传输侧配置为强制100M浦口审计学院试扩传输侧配置为强制100M林家凹试扩基站上PTN设备安装为155M光模块以下是该种情况下，OMC上核查的节点：5. 上行BLER导致速率持续偏低针对柳塘村速率持续偏低的问题，上站抓包：该站没有明显丢包，但是从基站可以看到空口有心电图状的BLER毛刺，峰值约10%，从拉网速率趋势看，曾有一小段时间空口无BLER，对应的速率可以稳定在80M左右，因此可以看出，下载速率高低，与测试点空口BLER有直接关系，空口BLER会导致下载速率持续偏低。经过外场测试人员寻找，在柳塘村可以找到空口环境较好的测试点，这些测试点空口无明显BLER，测试速率可在90M，这一现象也能说明，下载速率与BLER的关系。6. 上行反馈晚点到达服务器和终端丢包通过在柳塘村寻找无线环境好的测试点，测试速率可在90M以上，但也有偶尔掉坑现象，针对此种情况进行抓包和CDL业务日志分析，发现掉坑的时候有突发重传，重传的原因有2中：l 上行ACK到达服务器时间点晚导致服务器重传终端侧抓包分析：在500746行收到了SN为904789478的原始包紧接着在500748行对500746行和500747行报文进行确认ACK（ipid : 30556），如图：在501077行，收到SN为904789478的重传包服务器侧：在939644行对SN：904789478包首次进行发送在939931对SN：904789478包进行重传，此时按照TCP协议，超时重传会导致速率陡降。然而，在服务器对SN： 904789478重传后的939936行收到了终端对原始包的确认，说明原始包的ACK（ipid: 30556）并没有丢，只是到服务器时晚了上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。在做业务过程中，基站对EPC进行长PING操作，会偶尔出现超大时延现象，如图：l 终端接收丢包在126424行，抓包看终端已收到SN为3564609387的原始包，然而终端后续却一再确认SN为3564609387的包丢失（红色部分）直到在126917行收到服务器的对SN为3564609387报文的快速重传才恢复正常总结上述抓包分析：1） 上行TCP ACK晚点到达服务器导致重传；2） 业务过程中PING EPC存在超大时延是导致ACK晚点的最重要原因；3） 重传为瞬时突发，绝大部分时间无重传，且重传发生时伴随速率下降；4） 怀疑终端或笔记本性能问题会导致在业务长时间保持中收到数据处理不过来而丢掉；上述四点解释了测试过程中出现的现象：业务较长时间能够保持锋速，偶尔出现掉坑，长时间持续业务时速率波动幅度会变大。7. 终端反馈0窗口报文导致速率低针对宝塔街站上站测试抓包，经过分析，该站点BLER相对较高，但导致业务速率低的更重要原因为终端会反馈0窗长报文，一旦出现该问题，当前下载线程则处于停滞状态直至终端上报窗长恢复，每次发生停滞时间120ms-900ms不等，停滞时间内速率为0。 5线程下载测试，57秒的抓包中，发生约20次0窗口事件，而且，0窗长发生时往往伴随着丢包，如此，必然会导致速率低，如图，在65419行发生0窗口事件，直到65466行恢复，停滞时长约800ms。解决措施及结果：综上多种情况分析：调度不满导致速率低问题，经过传输整改链路、改配端口模式均能有效解决该问题。问题结论;引起调度不满导致速率低问题有以下几种因素：f) 传输问题l 传输明显丢包；l 传输端口模式配置错误；l 传输链路不稳；g) 参数设置问题：上行BO设置不合理；h) 测试点空口环境查，BLER高导致速率持续偏低；i) 传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低；j) 终端问题l 终端性能问题导致业务长时间保持中收到数据处理不过来而丢弃，引发重传；l 终端反馈0窗口报文，导致速率偏低。 CSFB失败原因分类总结根据集团案例库、各省经验及现网相关情况，CSFB失败的原因总结主要有几类：数据配置问题、弱覆盖或干扰、设备未开启CSFB功能、设备功能缺陷、终端原因等，针对以上各类原因详细分析如下：1、数据配置问题CSFB流程较长，其中涉及无线网的ENODEB、BSC、RNC；EPC核心网的MME、DNS；CS域核心网的HLR、MSC等网元。其中一个网元上的数据配置有误或不当，均会造成CSFB联合位置更新失败、主叫、被叫失败及无法返回LTE网络的问题。由于目前大部分的CSFB失败仍与数据配置问题相关，在此对每个网元上需配置的数据进行梳理，并对有可能造成失败的数据配置问题进行总结：1)ENODEB:ENODEB上需开启CSFB功能，新增至2G小区的重选回落功能，配置相应的2G重选参数、邻区关系等。2)BSC:除原有的2/3G邻区关系外，在无3G有4G区域的设备上新增2G到4G的小区重选功能，并配置相应的重选参数、邻区关系等。3)RNC:针对2G-3G-4G桥接返回LTE，共用数据业务对3G、4G互操作的配置要求，新增连接态互操作功能。4)MME:MME上主要配置以下数据：定义SGS物理接口；定义SGS IP层数据；定义SGS OSPF路由；定义SGSAP层及MSC 数据；开启license功能；配置与对接的MSC的SCTP链路；激活CSFB、SMS over SGS；TA与LA对应关系；LA与MSC对应关系；SGs接口触发寻呼参数。与MSC对接的SGS接口的数据配置示例如下：类别参数名称取值样例获取方法VLR相关配置VLR号（VN）111111111111111全网规划SGs链路配置参数IP地址类型（IPTYPE）IPV4全网规划本地IPv4地址1（LOCALIPV4_1）06全网规划本地IPv4地址2（LOCALIPV4_2）07全网规划VLR号（VN）111111111111111全网规划VLR IPv4地址1（VLRIPV4_1）05全网规划VLR IPv4地址2（VLRIPV4_2）04全网规划SCTP协议参数索引（SCTPINDX）0全网规划5)MSC:MSC上主要配置以下数据：对接MME的SGs接口实体配置；对接MME的SGs接口SCTP链路配置；MSC Server license开启；定义对端MME host数据；定义CSFB所用LA 相关数据；配置SGs paging策略；LTE连接态和空闲态寻呼响应软参配置；回落定时器时长配置。MSC上配置对接MME的SGS接口数据：本局信息VLR号码8613901004该参数由运营商统一规划本局VLR号码本地IP地址6该参数由运营商统一规划用于指定本局分发SGs接口协议消息的IP地址本地端口号29118该参数由运营商统一规划用于指定本局在SGs接口协议消息中的SCTP端口号WBSG模块号140该参数由运营商统一规划用于指定本局处理该SGs接口协议消息的WBSG模块号对接数据MME号码460004333322该参数由运营商统一规划与本局对接的MME设备的号码对端IP地址00该参数由运营商统一规划用于指定与本局对接的MME设备的IP地址对端端口号29118该参数由运营商统一规划用于指定对接的MME设备在SGs接口协议消息中所使用的SCTP端口号6）DNS：在未开启FAST RETURN时，需支持GL小区重选，UE回落后将发起PS域的RAU流程，以及小区重选回LTE时的TAU流程，这时融合DNS或本地DNS上需配置正确的RAI和TAI对应关系数据，否则通过桥接方式2G-3G-4G返回LTE的过程将会失败。7）HSS：在默认前提： MSC/SGSN和HLR对接基础配置已完成（包括数据配置，相关7号信令网配置等已完成）的情况下，将开户用户配置成2/3/4G融合用户即可。根据以上需进行的数据配置，结合案例及各省经验，数据配置问题导致的CSFB失败主要有以下几类：、MME上 SGS接口数据配置错误由于MME上对接MSC的SGS接口数据配置错误，如：VLR号配置错误、SGS链路配置参数错误（IP地址类型、IP地址、SCTP端口号）等造成CSFB联合注册失败。一般情况下，该失败情况会出现在有新MME或新MSC入网时，并且出现问题时失败区域有共同特性，即ENODEB对接的MME相同且失败区域对应的LAI相同等。失败区域一般范围较大。以下为MME上配置的LAI与VLR对应关系出错导致联合位置更新失败的案例：以下为核心网侧MSC SGs接口采用IMSI寻呼导致被叫失败的案例：、MSC上SGS接口数据配置错误由于MSC上对接MME的SGS接口数据配置错误，如：MME号配置错误、对接协议类型配置错误等造成CSFB失败。一般情况下，该失败情况会出现在有新MME或新MSC入网时，并且出现问题时失败区域有共同特性，即失败区域对应的LAI相同或LAI所属MSC相同或MME相同等。以下为MSC上对接MME的数据配置错误导致CSFB被叫寻呼失败的案例：、MME上TA与LA对应关系、LA与MSC对应关系错误 用户附着时，进行联合位置更新，MME 上存储TA （LTE Tracking Area ）与LA（2G Location Area ）的对应关系，根据TA 将用户注册在LA 对应的MSC 上。当TA对应错误的LA，会导致UE回落到不同的LAI甚至MSC时，将导致呼叫建立时延增加、用户被叫失败。当两个LA属于相同的MSC，每次主叫、被叫前均需进行局内的LAU，增加呼叫建立时延约0.5s；当两个LA属于不同的MSC时，主叫：每次主叫前需进行LAU、Insert Subscriber Data，TMSI、reallocation等流程，增加呼叫时延约2s，而被叫寻呼失败，直接导致被叫不通。CSFB要求同覆盖下的2G小区LAC和4G小区TAC配置一致，该数据配置由无线侧提供给核心网侧，核心网侧在MME上进行配置实现。因此TA与LA对应关系错误有可能是最先无线侧提供的数据就是错误的，也有可能是MME上配置时人工出错。当有该问题出现时，一般会集中在某个MME上或TA相同，具有区域性的特征。以下为MME配置TA映射LA有误，导致UE联合注册失败的案例：、MSC、 MME的寻呼方式、寻呼次数、寻呼时间间隔等参数设置不合理MSC、MME上寻呼方式、寻呼次数、寻呼时间间隔等参数设置不合理或有优化较大空间时，SGS接口的寻呼成功率不高，或出现被叫失败。以下为MME上可达定时器超时导致CSFB被叫失败的案例：以下为吉林省针对相关寻呼参数、定时器设置的SGS接口寻呼优化措施：、ENODEB、BSC或RNC上邻区关系、重选参数等错配或漏配除2/3G、3/4G邻区关系外，还需要新增4G到2G的邻区配置关系以及局部地区（无3G有4G区域）2G到4G的邻区关系，全网邻区关系复杂，配置工作量大。4G侧错配或漏配2G频点、3G侧错配或漏配3/4G互操作参数等问题均会导致CSFB失败。当4G侧漏配2G频点时，会导致主叫时延增大甚至不通（取决于终端实现），被叫无法接通，类似于eNB未打开CSFB开关；当错配2G频点时，会导致主叫时延增加（回到2G后先位置更新）再接续，被叫接续时延增加（同Pool不同LAC时）或者失败（跨Pool）。当3G侧错配或漏配3/4G互操作参数时，无自主FR能力或FR失败的终端CSFB通话结束，无法回到4G。以下为4G配置2G重选参数不合理，导致终端不能在TD-LTE网络稳定驻留的案例：以下为ENODEB的TAC配置与LAC配置区域不一致导致CSFB失败的案例：、其他核心网数据配置问题由于核心网侧一些参数的配置与协议不符或参数配置不当，会导致CSFB过程时延增加甚至超过定时器时间失败。以下为MME上的IMEISV配置错误导致时延增加的案例：2、 相关网元未开启CSFB功能、核心网侧相关网元未开启CSFB功能如果CSFB手机设置为语音优先模式，CSFB手机在尝试五次联合附着失败后（高通芯片），将关掉4G能力，降级为2/3G手机并在2G/3G网络驻留。如果CSFB手机设置为数据优先模式，当驻留在LTE网络时，仅能进行数据业务，无法进行语音主被叫。当有MME