srvcc切换深入分析及实战解决方案
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
eSRVCC切换成功率指标优化
1、eSRVCC概述
实现原理
SRVCC(Single Radio Voice Call Continuity),解决语音控制与移动到CS网络切换时语音连续性问题。
为基于IMSVOIP呼叫解决方案,利用IMS核心网络提供LTE VoIP语音业务路由、控制与业务触发,并提供LTE向2G/3G切换时语音连续性保证。
SRVCC实现过程实质上就是一个切换过程,在LTE网络中终端是通过IMS来实现语音功能,当终端离开LTE网络后,那么通过MSC server(Mobile Switching Center server)切换到2G/3G 网络中从而实现在2G/3G网络中语音功能。
eSRVCC:相比于SRVCC,媒体切换点改为更靠近本端设备。
具体方案就是增加ATCF/ATGW功能实体作为媒体锚定点,无论是切换前还是切换后会话消息都要经过ATCF/ATGW转发。
后续在发生eSRVCC切换时,只需要创立UE与ATGW之间承载通道,对端设备与ATGW之间媒体流还是通过原承载通道传输。
这样其创立新承载通道消息交互路径明显短于SRVCC方案,减少了切换时长。
eSRVCC方案相对于SRVCC方案增强在于减少了切换时长〔切换时长小于300ms〕,使用户获得更好通话体验。
信令流程
当网络或者终端不支持DTM,那么网络只可以使用普通切换命令HANDOVER COMMAND,仅进展cs域切换,Ps业务与流程挂起,切换完成后终端将请求挂起GPRS。
流程分析如下:
(4)基于语音承载相关QCI与SRVCC HO指示,源MME将语音承载从非语音承载中别离出来,且仅向MSCServer发起语音承载Ps—CS切换流程
(5)MME向MSC Server发送一个SRVCC PS to CS Request 消息。
cs域平安秘钥可以通过包含在MM上下文中E—UTRANE—UTRAN/EPS域秘钥由MME推导出。
(6)MSC Server通过发送Prepare Handover Request消息给目标MSC,让Ps—cs切换请求与cs—inter—MSC切换请求相互作用。
MSC Server对目标BSS在接口上分配一个默认SAI作为源ID,且对Prepare Handover Request使用BSSMAP encapsulatedo
(7)目标MSC与目标BSS之间交换切换请求消息及响应消息,以执行资源分配。
(8)目标MSC向MSC Server发送Prepare Handover I/e—sponse消息。
(9)建立目标MSC与MSC/MGW 之间电路域连接,可以通过使用ISUP IAM与ACM消息来建立。
(10)MSC Server通过使用STN—SR来发起会话转移流程,通过发送ISUP IMA消息至IMS网络,在会话转移过程中执行标准IMS 业务连续性流程。
(11)在会话转移流程过程中,由CS access legSDP更新远端,此时VolP分组包下行数据流转换至CS access leg。
(12)源IMS access leg被释放。
(13)MSC Server发送一个SRVCC PS to CS Response消息给源MME。
(14)源MME发送一个切换命令消息给源E—UTRAN,该消息中仅包含话音组件消息。
(15)—UTRAN发送一个切换命令消息给UE。
(16)UE转移至GERAN。
(17)目标BSS进展切换检测,UE通过目标BSS向目标MSC 发送切换完成消息。
(18)UE开场挂起操作流程。
从GUTI获取TLu与RAI pair,将触发目标SGSN向源MME发送Suspend Notifieation消息,MME向目标SGSN回复Suspend Acknowledge。
(19)目标BSS向目标MSC发送切换完成消息。
(20)目标MSC向MSC Server发送SES消息。
(21)通过发送ISUP Answer message给MSC Server完成建立过程。
(22)MSC Server发送SRVCC PS to CS Complete Notifi—cation消息给源MME,通知其UE已经到达目标侧。
源MME通过发送SRVCC IX5 to CS Complete Acknowledge消息给MSCServer来确认该消息。
(22a)MME通过话音或GBR承载去激活所有承载。
(23a)假设HLR更新,IMSI已被鉴定,但是在VLR中未知,MSC Server将对UE进展TMSI重分配,使用其自身未播送IAI,假设MSC Server与其他MSC/VLRs效劳一样LAI,那么使用其自身Network ResourceIdentifier(NRI)。
(23b)假设MSC Server执行TMSI重分配成功,那么MSCServer向HSS/HLR执行MAP UpdateLocation。
(24)对于紧急效劳会话,切换完成之后,源MME或者MSC Server向与源或者目标侧相关联GMLC发送一个携带MSC Server 识别Subscriber Location Report。
在上述场景中,核心网需要将非语音承载挂起,以便UE在短时间内切换回E—UTRAN网络时可以迅速恢复相关承载资源。
但是由于UE切回时间不确定,所以为了防止切换时间过长导致E—UTRAN 无法释放其相关资源情况,需要在E—UTRAN网络MME上启动承载资源释放定时器,定时器超时后删除UE在E—UTRAN网络中资源。
2、现网情况
网管指标定义:
eSRVCC成功率= LTE到GSM切换出执行成功次数
〔C373333312〕/LTE到GSM切换出准备请求次数
〔C373333330〕*100%
指标走势:
3、提升方案
网管指标eSRVCC切换失败统计有2个计数器:LTE到GSMSRVCC切换出准备失败次数〔C373333405〕、LTE到
GSMSRVCC切换出执行失败次数〔C373333407〕,减少准备与执行失败次数才能从根本上提升eSRVCC切换成功率。
eSRVCC切换成功率与邻接GSM小区配置准确性与合理性有直接关系。
具体优化建议如下:
1、根据现网配置CSFB测量频点,规划eSRVCC加邻接关系。
〔注意:在配置过程中需要注意邻接站点小区配置数据准确性〔比方:TAC/LAC、PCI、主频等等〕。
如果配置GSM小区不合理,上报GSM小区满足不了LTE切换至GSM条件,将导致掉话。
〕
2、定期核查LTE-GSM邻区关系配置,结合现网LTE、GSM 最新公参,更新不一致eSRVCC邻区定义,核查GSM小区参数是否与现网一致,如发现不一致参数及小区,需要及时更改。
3、核查单小区中GSM邻区同频同BSIC情况,如发生此类问题,需要及时协调GSM侧优化调整。
结合测试进展补充、删除不合理邻区关系,此项工作为日常优化工作重要组成局部。
4、根据不同场景设置合理切换参数,eSRVCC异系统门限设置不合理会导致过早切换到异系统、来不及切换到异系统等问题,容易引发通话质量下降、掉话、重定向等事件发生,下面为现网主要门限推荐值,可以根据具体环境验证最正确取值〔需注意:假设A1门限配置过低,易导致删除B2事件,不触发eSRVCCC切换〕。
5、无线环境导致切换失败、掉话。
LTE无线环境、GSM无线环境,大致包括以下几种情况将导致切换失败掉话。
a、在eSRVCC过程中,当UE仍处于无线环境中,由于重叠覆盖、干扰等原因导致L网络质量过低,使UE不能够准确地解读信令,从而使RRC断链,中断切换过程,导致掉话。
b、GSM拥塞导致UE不能够接入,使eSRVCC失败。
6、中兴602版本升级后,新增“弱场eSRVCC语音切换延迟〞功能,尽可能减少LTE到GSMSRVCC切换出准备失败次数;实现原理如下:
VOLTE业务QCI1建立后到180Ringing之前这片时间内,一旦发生了eSRVCC切换,就好引起未接通与切换失败,当前基于事件〔测量报告〕触发移动性管理策略,网络侧无法防止eSRVCC发起时机,呼叫成功率也会因此受到一定影响,从提升用户VOLTE业务感知及改善网络KPI指标角度出发,控制呼叫过程中eSRVCC是十分必要
eSRVCC发起,至少要等QCI1承载建立后,在主叫终端收到180Ringing消息之前这段时间间隔内发生eSRVCC,面临着呼叫流程被eSRVCC流程打断问题,因为网络无法控制eSRVCC发起时间,所以呼叫成功率会有所影响,控制呼叫过程中eSRVCC发起时间,就显得必要。
设置定时器对此功能进展异常保护,同时也用于解决SIP信令加密场景,设置定时器默认设置为8s,如果一直未收到180Ringing 或者SIP加密,最多保护8s内部启动eSRVCC流程,即定时器到期后,杀死定时器,且允许执行eSRVCC
4、指标及问题点跟踪
指标跟踪〔模板〕
问题分析跟踪〔模板〕。