1、专载流程冲突

现网 VoLTE 终端发生移动的过程中，不可避免会发生 Handover、 TAU 等空口过程， EPC 在触发专载建立过程，在尚未收到 Active Dedicated EPS Bearer Context Accept 反馈前，可能先收到了基站的切换请求。
典型空口信令如下，终端在发出 Active Dedicated EPS Bearer Context Accept 响应 EPC 下发的 Active Dedicated EPS Bearer Context Request 时，正好发生切换， Active Dedicated EPS Bearer Context Accept 第二次实际通过目标基站发出，即在专载建立过程中出现了切换流程：

如果不做处理， MME 会认为专载建立过程异常并释放承载，基站通过 RRC Connect Release 释放上下文，导致 VoLTE 呼叫失败， SIP 错误码 580 Precondition Failure，实质就是专载建立失败：

从核心侧流程看， MME 需要收到终端的 Direct Transfer（即 ActiveDedicated EPS Bearer Context Accept），才认为专用承载建立完成：

对于专载建立过程中的流程冲突， EPC 侧需要进行相应处理，缓存 Create Bearer Request(CBR)流程，在 X2 切换/S1 切换/TAU 等流程处理完成后再继续。

2、专载保持

在接入过程专载建立后，终端会并发 QCI9/QCI5/QCI1 三个承载，如果因为切换失败等问题，空口发生 RRC 重建，会有 3 种可能：
（ 1）重建至源基站，此时大概率会保留终端上下文，承载能够恢复， VoLTE业务继续；
（ 2）重建至目标基站，也能通过 X2 接口从源基站索取到终端上下文；
（ 3）重建至其他基站，同样有一定概率能通过 X2 接口从源基站索取到终端上下文。
对于第 2、 3 两种情况，如果新基站没有联系到源基站：
（ 1）源基站一定时间后（和 RLF 定时器时长有关）会反馈 MME，申请删除终端上下文（包含 QCI1 专载）。
（ 2）如果 MME 已删除终端的 QCI1 专载，新基站不可能再恢复。因为 QCI1专载建立是终端通过 QCI5 承载送出 INVITE 消息到 P-CSCF， P-CSCF 通过 GX/RX接口的 AAR/RAR 等消息再通知 EPC、基站逐段建立 S1 承载和对应 DRB。没有机制
使得 IMS 层感知到空口段的异常过程，再触发一遍专载建立过程，因此 VoLTE通话必断。
各类原因导致的空口 RRC 重建现象只能通过优化尽量减少，不可能完全消失。从机制角度，要在出现 RRC 重建失败时尽可能保持 VoLTE 业务不中断，在于源基站向 MME 申请删除终端上下文时（不包括 User Inactivity 、 Inter-RAT Redirection、 CS Fallback Triggered 之类正常释放原因）， MME 有意等待一段时间不要立即执行，让新基站有机会能恢复原先的承载信息。这段时间，核心侧通常称为专载保持或延迟释放。

3、寻呼策略

EPC 侧寻呼流程如下图：

（ 1） MME 收到 S-GW 发送的 Downlink Data Notification 后，向 S-GW 发送Downlink Data Notification Ack 消息。
（ 2） MME 根据终端上次接入的 TA，获取所有为这个 TA 服务的基站信息，并向这些基站发送 Paging 消息。如果寻呼失败则继续在 TA LIST 范围内进行寻呼。
（ 3） MME 收到终端发送的 Paging Response 消息后，继续完成普通寻呼流程处理。
考虑到寻呼负荷，每次寻呼范围通常由小及大，例如最近发生过业务的基站、TA、 TA List。
现网 EPC 数据业务寻呼一般是基于 TA 的智能寻呼。对于 VoLTE 业务， MME可以独立配置不同于数据业务的 VoLTE 业务寻呼策略。 MME 可以启用基于 QCI 寻呼的策略，对于 VoLTE（ QCI1、 2、 5）业务，寻呼间隔、重复寻呼次数等可单独配置。