CSFB日常优化工作指引_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
CSFB日常优化工作指引
上传于||文档简介
&&C​S​F​B​日​常​优​化​工​作​指​引
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩2页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢LTE中e-rab建立成功率 - 问通信专家
已解决问题
LTE中e-rab建立成功率
LTE中e-rab建立成功率怎么计算？希望可以给解释一下！！
提问者: &提问时间: &
• 在VOLTE中ERAB异常释放会导致掉话吗？
• LTEERABAbnormalRel什么意思
• VOLTE中E-RAB建立失败次数，消息参数错误导致的E-RAB（QCI=1）建立失败是什么原因啊
• VOLTE中有个counter为QCI1增加的E-RAB建立失败次数，消息参数错误
• 华为LTE设备，RRC建立正常，E-RAB建立失败较多
• LTE中E-RAB的优化
• 爱立信LTE中F频段和D频段共用电路后，D频段的ERAB失败次数较多，什么原因？
• LTE小区初搜、附着，随机接入，RRC连接、RAB建立、DRX
其他答案&(2)
不知道楼主想知道那方面的，E-RAB建立成功率和RAB建立成功率定义和公式基本都是一样的（建立成功次数/请求次数）；LTE连接时间是非常短的，所以一般默认的是一直是连接状态的。
&&&&专家指数：70&&&&
谢谢回答！！！
ERAB Setup Success Rate计算公式ErabSetupSuccessRate=（L.E-RAB.SuccEst）/(L.E-RAB.AttEst)*100%其中：(L.E-RAB.AttEst)是：当eNodeB收到来自MME的E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息时统计该指标。如果E-RAB SETUP REQUEST或者INITIAL CONTEXT SETUP REQUEST消息中要求同时建立多个E-RAB，则相应指标按各个业务的QCI分别进行累加。&&
&&&&专家指数：19772&&&&
谢谢哦！！！
• 在VOLTE中ERAB异常释放会导致掉话吗？
• LTEERABAbnormalRel什么意思
• VOLTE中E-RAB建立失败次数，消息参数错误导致的E-RAB（QCI=1）建立失败是什么原因啊
• VOLTE中有个counter为QCI1增加的E-RAB建立失败次数，消息参数错误
• 华为LTE设备，RRC建立正常，E-RAB建立失败较多
• LTE中E-RAB的优化
• 爱立信LTE中F频段和D频段共用电路后，D频段的ERAB失败次数较多，什么原因？
• LTE小区初搜、附着，随机接入，RRC连接、RAB建立、DRX
相关资料下载
<font color="#6人关注
<font color="#7人关注
<font color="#77人关注
<font color="#43人关注
<font color="#9人关注
<font color="#2人关注
<font color="#48人关注
<font color="#9人关注
<font color="#6人关注
<font color="#47人关注
聘： 需求人数：12 人
地点：广州市,佛山市
聘： 需求人数：10 人
地点：海外
聘： 需求人数：5 人
地点：福州市,厦门市,龙岩市
聘： 需求人数：2 人
地点：广州市
聘： 需求人数：5 人
地点：保山市
聘： 需求人数：5 人
地点：陕西省
聘： 需求人数：5 人
地点：山东省
聘： 需求人数：10 人
地点：重庆市,广州市,深圳市,长沙市,昆明市
聘： 需求人数：5 人
地点：天津市
聘： 需求人数：3 人
地点：曲靖市
赞助商链接
Powered by君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口只需一步，快速开始
扫一扫，访问微社区
微信名称：网优雇佣军
微 信 号：hropt_com
微信ＱＱ：
查看: 5876|回复: 1
CSFB问题排查手册（下）
帖子军饷威望
微信号：hroptcom
通信路上，我们一起走！案例7：4G网络将终端的Last Visited TA加入TA List，导致终端回落跨MSC Pool而被叫失败
1. 现象描述
某市路测时，偶尔有被叫CSFB手机失败现象，从终端LoG发现，被叫失败是由于回落跨MSC Pool造成，且呼叫失败前的TAU Accept中的TA List包含了分属不同TA List的TAC。
2. 问题分析
测试区域TA、LA规划如下图所示，其中BSC006的LA为 22548，BSC103的LA为22552，BSC177的LA为22457；MME将TAC 50配置在TA List 1中，TAC 51和52配置在TA List 3中，且TA List和LA映射关系为TA List 1对应LA 22552，TA List 3对应LA 22548。
测试时终端在正确的TAC 50小区进行电话拨打，TAC 50属于TA List 1，映射的LA为 22552，终端挂机后需要返回LTE小区，由于无线信号漂移等原因，终端返回LTE时接入的LTE小区属于TAC 51/TAC 52，这两个TAC均属于TA List 2，映射的LA为22548。从终端侧LoG发现，终端返回LTE时的TAU Accept消息中的TA List不但有TAC 51/TAC 52，还包含了之前所在的Last Visited TA，即TAC 50。当终端再次重选回到TAC 50下的小区进行拨打测试时，因对于终端而言TAC 50在TA List中，因此不会重新执行TAU，此时映射的LA仍为22548，但是在TAC 50 LTE小区下发的GSM频点对应小区LA为22552，故形成跨MSC Pool场景，因此被叫失败。
图 测试区域TAC与TA List分布示意图
因此，本案例中CSFB被叫失败，是由于4G网络MME将UE的Last Visited TA加入到给UE下发的TA List中，导致UE再次移动到Last Visited TA区域时不会发起TAU请求， 也就无法更新终端联合附着/位置更新的LA以及对应的MSC，从而导致跨MSC Pool回落，被叫失败。
3. 问题分类：核心网设备实现
4. 解决方案
根据3GPP协议，引入CSFB后，TA List尽量不要跨多个LA区域，而MME设备将UE Last Visited TA加入到TA List中的方式，会造成TA List跨多个LA区域，从而可能导致回落跨MSC Pool。
因此，通过规范MME实现，即不将UE的Last Visited TA加入TA List，从而避免本案例问题再次发生。
5. 效果评估
升级MME版本，通过软参配置方式关闭Last Visited TA加入TA List功能。之后的测试过程中，未发生因TA List跨多个LA导致回落跨MSC Pool，导致被叫失败案例发生。
案例8：回落至GSM后，鉴权失败
1. 现象描述
现象1：HZ外场，使用诺西USIM卡，回落2G建立语音业务，会出现第一次鉴权失败，第二次鉴权才成功的现象
现象2：QD外场，4G网络使用46008网号，主叫回落后，终端不发起CM service request，无法发起CSFB呼叫
2. 问题分析
在跨LA场景中，回落过程中需要进行LAU。测试发现呼叫总是有鉴权失败的场景，经分析发现CSFB主叫侧100%成功，但CSFB被叫侧100%失败。后分析因呼叫流程不同，导致鉴权的场景不同，最终导致鉴权的失败、之后的重同步过程。
USIM卡可以根据网络侧下发的鉴权参数（RAND、AUTN）计算出网络下发的SQN，其中SQN = SEQ || IND， 与终端中存储的SQNMS做比较，验证时以IND做为索引值，即新收到的SEQ只与SEQMS（IND）进行比较，若超出其允许的范围将返回鉴权失败消息。 比较的关键是：L和Δ。
●L 表示USIM允许的可接受序列号的最大寿命，即新接收到的SQN和SQNMS之间的最大允许数值差，要求SEQ > SEQMS – L。
●Δ 表示USIM可接受的序列号跳跃的最大值，即USIM只接受满足条件SEQ-SEQMS ≤ D的SQN。
怀疑卡商提供的卡和厂家提供的HLR/HSS/AuC中数据不一致，或卡中参数设置有问题，问题交给厂家和卡商共同研究和解决。
QD外场有2个特点：1) 4G网络与2/3G网络广播使用不同的网号：4G为4G为4G HSS/AuC与2/3G HLR/AuC分设，用户的鉴权数据同时存储与2/3G HLR/AuC和4G HSS/AuC中。
终端在4G鉴权成功且联合注册成功， 但是主叫回落后，终端无法发起CM service request消息。 经分析UE侧log发现终端在2/3G网络鉴权总是失败，2/3G网络对应的网络46000已经在终端侧为roaming not allowed网络，但4G网络依然可以接入。
经分析，认为测试用USIM卡的鉴权参数与2/3G HLR/AuC中的设置应该不一致，导致2/3G网络的鉴权失败，在网络侧发起Authentication reject消息后UE会自动将网络设置为禁止，因为2/3G使用与4G不同的网络号，所以依然可以接入4G网络。需要卡商、设备厂商和省公司共同检查核对USIM卡和HLR/AuC中的参数设置。
3. 问题分类：核心网参数设置
4. 解决方案
HZ外场：卡商认为是旧COS中，Delta和L值设置与HLR/HSS/AuC中不同，造成同步失败无法登录网络。重新做卡后，问题基本得到解决。
QD外场：卡商定位为USIM卡中R值与现网HLR/AuC中R值不符， 但是与HSS/AuC中R值相符。为了修改R值，与现网HLR/AuC中一致，需要重新做USIM卡，同时修改HSS/AuC的R值。新做的USIM卡最终在2/3G网络鉴权通过，证实确为R值问题。
5. 效果评估
问题基本得到解决。
案例9：UE在TAU流程中拨打电话导致呼叫失败
1. 现象描述
某城市外场测试过程中，4G UE拨打4G UE，L2L共拨打了60次，出现8次呼叫不成功，主叫在20s-30s左右的时延后听到“被叫无法接通”的录音通知。
2. 问题分析
检查终端侧和网络侧MME跟踪和记录的log，发现
(1)在快速拨打的过程中，因TA-LA匹配，终端在呼叫前没有发起LAU流程，因此SGs接口状态在MSC依然保持为associated；挂机后，终端支持自主快速返回功能，在UE返回LTE网络过程中，被拨打当被叫时，MSC依然会在SGs接口下发寻呼消息
(2)虽然用户在MME状态设置为悬挂，但MME依然在空口下发寻呼
(3)UE返回LTE网络，尚未发起TAU流程，但看到空口的寻呼消息后，会立即发起寻呼响应消息
(4)接收到UE的寻呼响应消息后，MME给MSC返回SGs-ServiceRequest消息。但MME因UE尚在悬挂状态，立即给UE返回Service Reject消息，同时给MSC发送SGs-IMSI-detach消息
(5)因为接收到Service Reject， UE发起Attach request消息
(6)接收到Attach消息后，MME在SGs接口发送SGs-LAU request消息
(7)MSC因为内部实现的bug，会一直悬挂入呼叫，直至超时（大约20s）释放呼叫
3. 问题分类：核心网设备实现
4. 解决方案
从问题分析中可看出，MME在用户悬挂状态时寻呼了用户， 之后又因用户悬挂状态拒绝用户的寻呼响应，并先后给MSC返回SGs-ServiceRequest和SGs-IMSI-detach消息，导致MSC内部的bug被激活，处理异常。
在此场景下，有两种可能的实现方式
方式1） 因用户悬挂，MME直接给MSC返回SGsAP-UE-UNREACHABLE消息，这样的话，本次呼叫失败，因为寻呼无响应，但MSC中用户SGs接口和状态都不会被修改， 不影响下次呼叫
方式2）MME依然在S1接口寻呼用户，增加LTE网络寻呼量，寻呼后可能失败，也可能寻呼成功。若用户返回寻呼响应，MME正常处理后续呼叫，呼叫正常。
两种实现方式均可，各有优缺点，需商讨。
5. 效果评估
后续，建议在外场测试时验证各厂商的实现方式，并商讨决策。
三 “CSFB手机挂机返回LTE异常”的原因及案例分析
3.1 原因分析
目前，CSFB返回方案采用两种并行的方案：终端自主返回和2G->3G->4G桥接返回方案。部分城市区域还采用第三种方案：2G->4G返回方案。
终端自主返回功能需要芯片支持，具体实现与厂家芯片实现相关，自主返回失败因素与LTE无线信号覆盖、挂机区域频点是否已被终端记忆有关。当终端自主返回失败后，终端将在2G驻留。若2G配置4G邻区，则由2G通过小区重选返回4G；若2G未配置4G邻区，则通过3G桥接返回4G。2G->3G->4G桥接返回和2G->4G过程与数据业务互操作流程相同，相关影响因素与数据业务互操作类似，可参见《LTE与TD-SCDMA数据业务互操作性能影响因素分析》案例库；除此之外，因CSFB流程造成的重选返回失败因素主要为LTE网络侧定时器超时导致隐式detach，导致TAU失败。
部分特殊终端及国漫入终端不支持终端自主返回功能，CSFB通话挂机后将在2G驻留。若该终端也不支持TD-S模式，且2G又未配置4G邻区，则该终端将不能返回4G驻留；若终端支持TD-S模式，将根据2G是否配置了4G邻区，选择2G->3G->4G桥接方式或2G->4G方式返回方式。
通常情况，回落2G网络，通话过程中不能进行数据业务，挂机后
●若终端通过自主快速返回方式返回4G，可在LTE发起TAU并恢复数据业务
●若终端自主返回失败，将驻留2G网络并尝试恢复数据业务，连接态时：
◇可通过NC0方式返回3G（需终端支持），
◇若3G网络支持到4G连接态重定向，可返回4G继续数据业务
◇若否，终端需待数据业务完成进入空闲态后，通过小区重选2G->3G->4G桥接方式或2G->4G方式返回4G（需2G配置4G邻区）
●特殊场景，若终端回落3G网络，通话过程中能够并行进行数据业务，挂机后终端将驻留在3G，返回4G行为与上面相同
3.2 案例分析
案例1：挂机区域LTE弱覆盖，导致终端自主返回失败
1. 现象描述
LTE弱覆盖区，CSFB手机通话后挂机，不能通过终端自主返回功能返回4G网络。
2. 问题分析
终端自主返回时，需LTE信号RSRP满足开机驻留门限（一般设置为-120dBm～-124dBm）才能接入4G网络，在LTE弱覆盖区，4G信号低于开机驻留门限，终端自主返回将失败，此后终端将返回2G网络驻留，在信号强度满足条件情况下，可通过3G桥接返回4G网络。
3. 问题分类：网络覆盖条件
4. 解决方案
通过网络建设及网络优化，提升4G网络覆盖质量，避免覆盖空洞，提高终端自主返回成功率。
5. 效果评估
在LTE典型强覆盖区域，终端自主返回成功率较高，用户体验较好。
案例2：挂机区域频点与起呼区域不同，导致终端自主返回失败
1. 现象描述
某芯片CSFB手机，在室外D频段起呼，在室内E频段挂机，挂机后不能通过终端自主返回功能返回4G网络。
2. 问题分析
本案例问题与芯片实现相关，其终端自主返回方案为挂机搜索曾经记忆的LTE频点，如果挂机区域频点未曾记忆，则不能自主返回4G网络，此后UE将永久记忆这一频点，并且关机也不消除。测试时，UE从未在E频段频点驻留，当在室外起呼室内挂机时，不能搜索室内E频段该LTE频点，导致自主返回失败，定时器超时后（测试时设置为2s），UE驻留2G网络，此后UE记忆此E频段频点，再次在室外起呼室内挂机，终端自主返回成功。
3. 问题分类：终端实现
4. 解决方案
终端自主返回功能无需改动GSM无线网络，但存在一定失败概率。若此芯片终端未记忆挂机区域LTE频点，终端自主返回将失败。但未来部署LTE频点数量最多5~6个，且终端能够永久记忆曾驻留或读取的频点，该问题对用户体验影响不会太大。
5. 效果评估
终端能够永久记忆曾驻留或读取的频点，且不随开关机取消，在LTE部署频点数量5~6个前提下，因频点未记忆导致的终端自主返回失败对用户体验有影响，但影响不会太大。
案例3：SGSN向MME发出的PDP context Request中携带GBR，导致TAU完成后，LTE网络将用户Detach
1. 现象描述
在2G电话结束后，终端通过重选返回LTE，TAU结束后，网络将用户Detach。
2. 问题分析
在2G电话结束后，终端在2/3G发起RAU，SGSN收到RAU REQ后，通过SGSN context request流程从MME侧获取用户的上下文，从消息中可以看到，MME发送给SGSN UE的GBR是0：
图MME发给SGSN的SGSN context Response中UE GBR为0
但是SGSN给P-GW发起的update PDP消息中，给UE分配的GBR是640：
图 SGSN发给P-GW的Update PDP消息中UE GBR为640
终端通过重选返回LTE TAU时，MME从SGSN获取的用户的上下文，在SGSN回给MME的SGSN Context Response消息里， GBR UL/DL都是640：
图 SGSN发给MME的SGSN Context Response中UE GBR为640
而对于default bearer，GBR应该为0，所以MME检查到用户的上下文不合法，从而发起Detach流程，将UE去附着。
3. 问题分类：核心网设备实现
4. 解决方案
SGSN更新版本，对于默认承载的GBR值不做修改。
5. 效果评估
SGSN更新版本后，案例中出现问题未复现。
案例4：SGSN关闭根据UE能力选择锚点功能，导致TAU失败
1. 现象描述
终端从2G重选返回到4G时，出现概率性TAU失败，需在4G重新Attach后成功接入，导致重选到4G的时延较长。
2. 问题分析
因BOSS计费改造进度原因，SGSN临时关掉根据UE能力选择功能，所以当用户在SGSN下一旦发起PDP激活，SGSN将会把该用户选择到现网GGSN。然后当用户重选到4G做TAU时，MME从SGSN获取该用户的上下文，其中包含UE所在的网关IP地址，并发起承载建立，这里获取的IP地址实际是GGSN的地址，而MME发起承载建立时需要向SAE-GW发起。但是现网GGSN不支持P-GW功能，导致承载建立失败，TAU拒绝；用户需要在4G重新Attach后成功接入。
如果UE初始接入在4G，由于P-GW支持GGSN功能，用户在系统间来回移动时，网关永远是融合节点，不管TAU还是RAU都不会失败。
3. 问题分类：网络改造进度
4. 解决方案
该问题出现时是由于全国BOSS未改造完毕，有计费漏洞，所以部分省份将SGSN根据UE能力选择功能临时关掉。所以一旦BOSS改造完毕，同时将该功能打开，这个问题将不复存在。在BOSS改造完成前，有下面几个临时方案：
方案一：SGSN根据IMSI/MSISDN号段区分出LTE签约用户，并将其锚定到P-GW，其余用户仍锚定到GGSN。具体实施时：①SGSN可以根据其中静态配置的号段选择网关；②也可以通过在DNS中指定不同号段的不同网关地址后，SGSN通过重构APN的方式扩展DNS查询消息，获取合适的网关，将非LTE用户路由到GGSN；
方案二：对LTE用户增加ARD的签约信息，SGSN根据UE能力和ARD签约信息选择合适的网关，将非LTE用户路由到GGSN。该方案涉及到HLR的改造，不建议使用。
5. 效果评估
待核心网改造完毕即可解决。
案例5：QoS修改时MME第一次Paging无响应，导致网络Detach UE
1. 现象描述
终端返回4G，TAU流程结束后，网络发起寻呼，一次寻呼失败后网络就发起了detach流程。
2. 问题分析
终端回落到GSM后，通话结束后快速返回LTE失败，因此在2G/3G网络发起RAU流程，之后返回4G发起TAU流程，因TAU REQ消息中active flag=0，TAU流程结束后MME立即发起S1释放流程，终端进入空闲态。
之后，MME发现该用户在LTE的QoS签约比该用户在2/3G网络实际使用的QoS高，MME发起QoS更新流程，由于UE已经处于空闲态，所以MME首先发起paging流程。
图 为修改Qos，MME发起Paging流程
第一次 Paging时，恰好UE此时（同1秒时刻）在同频切换（跨TA list触发TAU），导致终端无法收到该Paging。
图 第一次Paging时，UE同时进行同频切换
MME在一次Paing无响应的情况下，就给S-GW回Update Bearer Response，携带UE not responding原因，导致网络主动发起detach流程，将UE去激活。
图 MME在一次Paging无响应后，发给S-GW的Update Bearer Response
3. 解决方案：核心网设备实现
4. 解决方案
MME更新实现方式，只有在多次寻呼均失败时，才可以给SAE GW回Update Bearer Response。
5. 效果评估
仅在多次寻呼失败，确实异常时网络才会将用户去附着。
案例6：SGSN未配置4G EPLMN导致UE无法返回4G
1. 现象描述
CSFB手机（测试时不支持终端自主返回功能）在2G挂机后通过小区重选返回LTE失败，原因是MSC下发的EPLMN list（46008）无效
2. 问题分析
测试区域2G PLMN ID为46000，4G PLMN ID为46008。CSFB手机挂机后，因暂不支持终端自主返回功能，驻留2G网络，依次进行LAU和RAU过程，之后通过小区重选返回4G网络。由于MSC配置了EPLMN，2G网络在LAU Accept消息中下发的EPLMN list中包含46008，如下图：
-- 有46008的EPLMN
但SGSN未配置EPLMN，因此在RAU Accept消息中下发的EPLMN中不包含46008，如下图：
--没有携带EPLMN
UE仅能根据最后一次LAU或RAU Accept获得的EPLMN刷新并保存EPLMN list，因此RAU流程后刷新EPLMN list，删除了LAU Accept时下发的EPLMN list，4G PLMN ID46008不在UE的EPLMN list中。
当终端小区重选返回4G时，因4G PLMN与UE的RPLMN不同，且不在UE的EPLMN list中，重选4G网络失败。
3. 问题分类：核心网参数配置
4. 解决方案
SGSN配置4G PLMN ID为EPLMN，从而在RAU Accept消息的EPLMN list中携带4G PLMN ID，使得UE能够返回后成功接入4G。
5. 效果评估
SGSN配置4G PLMN ID为EPLMN后，CSFB手机能够正常从2G重选返回4G。
四 “CSFB呼叫建立时延异常”的原因及案例分析
4.1 原因分析
CSFB呼叫建立时延是CSFB用户体验的重要部分，因CSFB额外引入流程将在GSM现网呼叫建立时延基础上增加时延。在网络部署成熟时，CSFB呼叫建立时延应趋于稳定，但在部署过程中，CSFB呼叫建立时延可能存在过短或者过长等异常情况。
在网络部署CSFB R8重定向回落方案（终端支持缓读SI13功能）时，通过五城市联合测试摸索到CSFB呼叫建立时延范围如下：
●CSFB单端呼叫（CSFB UE拨打GSM UE或者GSM UE拨打CSFB UE）：
◇额外时延：相比GSM现网基准时延，额外时延约1.7~2.9s，且80%的呼叫增加时延在2.5秒以内
◇总时延：单端总时延为6.9~12.3s，其中 85%在7s和10s之间
●CSFB双端呼叫（CSFB UE拨打CSFB UE）：
◇额外时延：相比GSM现网基准时延，额外时延约3.5~4.9s，且80%的呼叫增加时延在4.5秒以内
◇总时延：单端总时延为8.3~13.7s，其中90%在9s和12s之间
CSFB呼叫建立时延主要包括三个部分：UE在LTE侧起呼/接收寻呼到收到重定向命令、UE收到重定向命令后搜索接入GSM小区并读取GSM系统广播、建立GSM通话等，下面将详细介绍每个部分时延的影响因素。
1、UE在LTE侧起呼/接收寻呼到收到重定向命令
本阶段对时延的影响主要因素包括MSC开启Early Alerting/ACM功能、eNodeB开启基于测量的重定向功能、LTE侧二次寻呼等。
(1)MSC开启Early Alerting/ACM功能
MSC开启Early Alerting/ACM功能是指MSC在收到MME的寻呼响应后即给主叫用户放回铃音，将导致主叫呼叫建立时延过短，但会对网管指标统计及主叫用户体验产生影响。
(2)eNodeB开启基于测量的重定向功能
eNodeB开启基于测量重定向功能后，eNodeB需给UE下发测量控制消息，并根据UE测量报告中GSM频点情况下发重定向命令，UE连接态测量异系统频点时延较长，会额外增加CSFB呼叫建立时延。通常情况下，为保证CSFB时延，eNodeB开启盲重定向即可。
(3)LTE侧二次寻呼
因LTE侧无线信号弱等因素，存在二次寻呼概率，将增加CSFB呼叫建立时延。
2、UE收到重定向命令后搜索接入GSM小区并读取GSM系统广播
本阶段对时延的影响因素包括重定向命令中配置的GSM频点不合理导致UE搜索GSM小区时延过长。
3、建立GSM通话
本阶段对时延的影响因素包括GSM网络索要IMEI、BSC开启UTRAN ECSC功能等。针对CSFB UE的通话建立过程，网络可以有优化方案以减小呼叫建立时延。
4.2 案例分析
案例1：SGs MSC开启early Alerting或ACM，导致呼叫建立时延过短
1. 现象描述
CSFB手机拨打CSFB手机时，呼叫建立时延仅为6~7s，比正常时延11~13s短5~6s。
2. 问题分析
根据3GPP协议，若被叫用户位于LTE网络，LTE寻呼响应后，若用户为连接态，MSC必须立即给主叫侧返回Alerting或ACM消息，MSC就给主叫用户发送Alerting并放音（如果配置了放音文件的话），因此，主叫侧呼叫建立时延仅为6~7s。部分厂家根据协议实现了此Early Alerting功能，具体信令流程如下图所示：
Early Alerting/ACM功能虽能一定程度提高主叫用户通话体验（呼叫建立时延短），但存在一些问题，如其一会影响GSM现网KPI统计的Alerting/ACM数量，其二被叫LTE用户寻呼响应后回落呼叫依然可能失败，但主叫方已经听到回铃音，可能会导致主叫用户对被叫用户不必要的误会，其三如果被叫用户签约了彩铃业务，主叫侧可能将先听到回铃音，后听到彩铃（与MSC实现相关），也会影响用户体验。
目前，对于Early Alerting/ACM功能，部分厂家认为标准不合理，没有实现；部分厂家实现该功能并可开关控制；部分厂家完全按照标准实现，且无开关控制（后续将推动支持开关控制）。综合评估时延性能、网管统计和用户体验，在现网应用时，建议MSC可通过开关控制关闭Early Alerting/ACM功能，以提升KPI考核准度和用户体验。
3. 问题分类：核心网参数配置
4. 解决方案
MSC关闭Early Alerting/ACM功能后，呼叫建立时延恢复正常水平。
5. 效果评估
针对已经支持开关控制Early Alerting/ACM功能的厂家设备，已通过测试验证其实现方式，在关闭Early Alerting/ACM功能后，呼叫建立时延符合正常时延范围。
案例2：eNodeB开启基于测量重定向，导致呼叫建立时延略长
1. 现象描述
外场测试时，CSFB手机拨打2G手机25次，呼叫建立总时延平均约11.8s，略长。测试区域GSM网络开启了扩展BCCH功能，呼叫建立时延应与终端支持缓读SI13优化功能接近。
2. 问题分析
对25次呼叫的主叫侧LoG进行了分段分析，分析结果如下：
从分段时延中可以看出，本案例测试中的第一段分段（Extended Service Request->RRC Connection Release）比正常时延范围长约2.7~2.8s。后检查eNodeB配置，发现设备开启了基于测量的CSFB重定向功能，即UE在LTE侧发起呼叫/响应寻呼后，eNodeB会先给UE下发携带GSM频点的测量控制信息，待UE上报了异系统测量报告后，eNodeB根据UE测量GSM频点情况，下发重定向命令指引UE回落GSM网络，信令流程图下图所示。而通常情况下，为保证CSFB时延性能，eNodeB针对CSFB功能需开启盲重定向功能，且根据实际网络规划，合理配置盲重定向命令中的GSM频点，进而保证CSFB盲重定向的成功率。因此，相比于正常时延，本案例测试的第一段分段多了UE测量异系统并上报测量报告的过程，而该过程的时延与UE实现、网络覆盖情况相关，测试表明，该过程时延约2.7~2.8s。——测量报告中上报GSM频点762的RSSI
3. 问题分类：无线参数配置
4. 解决方案
eNodeB针对CSFB功能关闭基于测量的重定向功能，仅开启盲重定向功能。基于测量重定向比盲重定向的重定向成功率略高，但会增加CSFB通话的呼叫建立时延。为保证盲重定向的成功率，在配置重定向命令中GSM频点时，需根据LTE与GSM的网络规划配置，从而使重定向命令中GSM频点尽量涵盖LTE小区覆盖范围内所有GSM小区频点。
5. 效果评估
eNodeB关闭CSFB基于测量重定向功能后，CSFB手机拨打2G手机的呼叫建立总时延约9s，在正常时延8s~10s范围内，分析分段时延，第一段分段（Extended Service Request->RRC Connection Release）约300ms，符合盲重定向时延范围。
案例3：4G UE回落至GSM后，网络主动索要IMEI导致呼叫时延增加
1. 现象描述
CSFB手机拨打2G手机，回落至GSM网络后，网络主动索要UE IMEI导致呼叫建立时延增加约0.2~0.4s。
2. 问题分析
GSM现网在UE通话建立过程中，MSC会索要UE IMEI以便于话单统计。CSFB UE回落至GSM网络后，与现网流程相同，MSC会索要CSFB UE的IMEI，该流程时延约0.2~0.4s。
但对于CSFB UE，存在优化方案，即UE在LTE网络接入时提供IMEISV，且通过SGs接口告知MSC，从而避免在GSM呼叫建立过程中再次索要IMEI，进而缩短CSFB呼叫建立时延。该优化方案的基本流程如下图所示：
(1)UE回落前，LTE网络MME可要求UE上报并存储IMEISV，
(2)MME在SGs联合附着/位置更新的SGsAP-LOCATION-UPDATE-REQUEST消息可携带可携带IMEISV参数（被叫及短信流程涉及的SGsAP-SERVICE-REQUEST、SGsAP-UPLINK-UNITDATA消息也可携带），并告知MSC并存储；
(3)MSC在SGs接口接收并存储后，当UE回落后，MSC可无需再次索要IMEISV。
3. 问题分类：核心网参数配置
4. 解决方案
MME及MSC均已支持通过SGs接口传递IMEISV的优化功能，在部署CSFB时，建议MME及MSC开启此功能。
5. 效果评估
开启优化功能后，MSC在通话过程中不再索要CSFB UE的IMEI，从而缩短呼叫建立时延。但目前部分厂家MSC即使有存储的IMEISV信息，也会每次呼叫、LAU流程都再次索要IMEISV信息，需进一步规范MSC设备实现。
案例4：4G弱覆盖导致终端未收到重定向命令，导致呼叫建立时延过长
1. 现象描述
在LTE弱覆盖区域测试时，CSFB手机拨打2G手机呼叫建立时延长达20s左右，且CSFB手机回落3G网络。
2. 问题分析
通过分析终端LoG，CSFB UE在4G网络并未收到重定向命令（RRC Connection Release），在LTE弱覆盖区域，UE存在一定概率漏收部分信令。根据协议规定，当UE未收到重定向命令时，UE将启动定时器T3417ext（协议规定该定时器为10s），当UE为主叫方时，T3417ext超时后，UE主动搜索其他RAT小区并尝试接入，一般地，UE将先搜索3G小区，后搜索2G小区；当UE为被叫方时，T3417ext超时后，UE释放无线链路并不回落2G/3G。
3. 问题分类：网络覆盖条件
4. 解决方案
在LTE布网初期，存在部分LTE弱覆盖区域，可能会导致UE收取部分信令不全。需通过网络建设及网络优化，不断提高LTE网络覆盖水平，以解决案例中出现问题。
5. 效果评估
在LTE强覆盖区域，UE未收到4G网络重定向命令概率较低，因此，随着LTE网络覆盖水平不断完善，本案例问题出现概率会不断下降。
案例5：eNodeB未开启CSFB，导致CSFB呼叫失败或呼叫建立时延过长
1. 现象描述
测试区域内，MME已开启和支持CSFB功能，并在Attach 和TAU Accept消息中告知UE，这样的话CSFB终端将认为LTE网络支持CSFB，驻留LTE网络。
设备厂家A eNodeB未开启CSFB，在其测试区域中：
●CSFB UE处于空闲态
◇CSFB UE拨打2G UE，CSFB UE回落至TD-S，呼叫建立时延略长，约11s；
◇2G UE拨打CSFB UE，CSFB UE回落至TD-S，呼叫建立时延略长，约11s；
●CSFB UE处于连接态
◇CSFB UE拨打2G UE，CSFB UE回落至TD-S，呼叫建立时延过长，约20s；
◇2G UE拨打CSFB UE，CSFB UE不回落2G/3G网络，呼叫失败；
设备厂家B eNodeB未开启CSFB，在其测试区域中：
●CSFB UE处于空闲态
◇CSFB UE拨打2G UE，CSFB UE回落至TD-S，呼叫建立时延过长，约20s；
◇2G UE拨打CSFB UE，CSFB UE不回落2G/3G网络，呼叫失败；
●CSFB UE处于连接态
◇CSFB UE拨打2G UE，CSFB UE回落至TD-S，呼叫建立时延过长，约20s；
◇2G UE拨打CSFB UE，CSFB UE不回落2G/3G网络，呼叫失败。
2. 问题分析
当eNodeB未开启CSFB功能，CSFB呼叫在不同设备厂家测试区域表现不同，这与不同设备的实现有关。
在设备厂家A测试区域，CSFB UE处于空闲态时，发起呼叫或者响应LTE寻呼后，eNodeB会下发重定向命令（RRC Connection Release），但由于eNodeB未开启CSFB功能，重定向命令中不携带GSM频点，CSFB UE收到重定向命令后，根据终端实现，先搜索3G小区并尝试接入，TD-S频点较少，UE搜索较快，因此呼叫建立总时延约11s；CSFB UE处于连接态时，作为主叫UE并发起呼叫，eNodeB不会下发重定向命令（RRC Connection Release），UE将启动定时器T3417ext（协议规定该定时器为10s），T3417ext超时后，UE主动搜索其他RAT小区并尝试接入，一般地，UE将先搜索3G小区，后搜索2G小区，作为被叫UE响应寻呼时，T3417ext超时后，UE释放无线链路并不回落2G/3G。
在设备厂家B测试区域，CSFB UE无论处于连接态还是空闲态，当其作为主叫UE并发起呼叫，eNodeB不会下发重定向命令（RRC Connection Release），同上，UE将启动T3417ext，T3417ext超时后，UE先搜索TD-S并尝试接入，因此呼叫建立时延约20s；当其作为被叫UE并响应寻呼后，T3417ext超时后，UE释放无线链路并不回落2G/3G。
3. 问题分类：网络建设进度
4. 解决方案
3GPP协议未规范eNodeB未开启CSFB功能时网络设备的行为，因此不同厂家的实现均合理。因此，某一开启CSFB的MME区域中所有eNodeB都需支持并开启CSFB后，MME方可激活CSFB功能并将CSFB支持能力下发给UE，以保证CSFB用户尤其是CSFB用户当被叫时的用户体验。
5. 效果评估
eNodeB开启CSFB功能后，CSFB呼叫建立时延恢复正常水平。
上一篇：下一篇：
帖子军饷威望
新兵, 积分 60, 距离下一级还需 140 积分
新兵, 积分 60, 距离下一级还需 140 积分
很详细&&好贴
注册账号后积极发帖的会员
经常参与各类话题的讨论，发帖内容较有主见
经常帮助其他会员答疑
积极宣传本站，为本站带来更多注册会员
积极宣传本站，为本站带来更多的用户访问量
经常在论坛发帖，且发帖量较大
长期对论坛的繁荣而不断努力，或多次提出建设性意见
活跃且尽责职守的版主
为论坛做出突出贡献的会员
为论坛做出突出贡献的会员
Powered by
本站统一服务邮箱：}