专载释放与eSRVCC切换流程冲突问题分析建模及优化方法.ppt

专载释放与eSrvcc切换流程冲突 问题分析建模及优化方法 * 现网几分钟内，几十上百次“前仆后继”的SRVCC失败 为何陷入没完没了的SRVCC？ 专载 释放 用户使用习惯：eSRVCC质差挂话重播、aSRVCC振铃等待拒接挂话、对方挂话时主叫发生SRVCC、以及bSRVCC事件发生时；都会出现MME侧专载释放和Bye流程冲突，造成“前仆后继”的失败。 流程 冲突 MME机制 MME冲突解决机制 MME厂家 “前仆后继”准备失败 专载是否 释放 流程冲突“下沉”至eNB 盲目用户优先 诺基亚 爱立信 是 否 是 移动会话优先 华为 否 否 Emsc~eNB 冲突量化 如何量化指标影响程度：结合大数据平台“溯源平台”“S1-MME代码统计”“SV口统计”，形成流程冲突模型识别和统计，评估冲突对全网指标的影响程度，同时提出解决办法。 现状主要制约因素 现网存在两种冲突流程： 1、专载释放与切换流程冲突后会话管理优先机制（影响切换准备阶段成功率） 2、专载释放与切换流程冲突后移动性管理优先机制（影响切换执行阶段成功率） * MME冲突后，“粗暴”方式将原丢弃的e-RAB release消息与Handover Preparationfailure 打包发送eNB；完全不顾及下一级eNB的失败“候选机制”，将冲突转移至eNB，造成eNB频繁发起切换请求，MME“前仆后继”回切换准备失败 粗暴的解决机制 会话管理优先机制——冲突后处理机制及流程 eNB测量上报切换候选小区机制 eNB测量上报切换候选小区机制 eNB测量上报候选机制，当上报满足＞1个邻区条件后，选取最佳进行切换请求，当收到准备失败后，立即触发候选机制，上报第二个最优邻区进行切换请求。（无需等待UE再上报） * 会话管理优先机制——建模评估（诺基亚MME） 冲突模型识别诺基亚 Bye或被叫振铃挂机（603）和eSRVCC请求，冲突溯源日志信令识别，建立S1-MME代码原则： 准备失败[6]后，因为候选机制，冲突下沉后MME收到基站上发的e-rab release response 错误码为：[34]“_s1_inter_system_handover_triggered” 因为专载未删除，后续UE一直 进行切换请求，但是MME直接回切换准备失败：[772]“Root_semantic_error” 当未触发候选机制情况下，如下图，e-rab 是正常释放的。 模型识别 大量溯源分析，诺基亚MME核心网处理冲突机制为，MME向eNB同时发送三条信令： 1、nas透传删除专用承载的Deactivate EPS bearer context request消息 2、ERAB释放的命令：ERabReleaseCommand 3、Root_ho_failure_in_target_EPC_eNB_or_target_system[6]诺基亚； 冲突模型识别及举措_爱立信 流程类型 开始时间 结束时间 流程状态 失败原因 Dedicated EPS bearer context activation 2016-10-24 00:05:53.786 2016-10-24 00:05:53.835 成功 255 S1 handover out 2016-10-24 00:05:55.138 2016-10-24 00:05:55.630 失败 4 EPS bearer context deactivation 2016-10-24 00:05:55.630 2016-10-24 00:05:55.774 成功 255 E-RAB release 2016-10-24 00:05:55.630 2016-10-24 00:05:55.773 成功 　 Dedicated EPS bearer context activation 2016-10-24 00:06:07.036 2016-10-24 00:06:07.078 成功 255 E-RAB release 2016-10-24 00:06:08.894 2016-10-24 00:06:09.052 成功 　 EPS bearer context deactivation 2016-10-24 00:06:08.894 2016-10-24 00:06:09.053 成功 255 Dedicated EPS bearer context activation 2016-10-24 00:06:18.204 2016-10-24 00:06:18.253 成功 255 S1 handover out 2016-10-24 00:06:19.513 2016-10-24 00:06:20.066 失败 4