VoLTE网络优化指导方案珍藏版
VoLTE网络结构简介
VoLTE本质是通过EPS来提供业务接入（包括无线承载和EPC承载），通过IMS核心网提供业务控制（包括会话控制和业务逻辑处理及被叫域选择），通过与GSM网络协助来提供业务连续性（eSRVCC等）。其逻辑架构如下图：
1.1 IMS相关网元简介
1.1.1 SBC
VoLTE SBC（SessionBorder Controller）---会话边缘控制器，包含P-CSCF/AGW、ATCF/ATGW功能模块。
P-CSCF（ProxyCSCF）/AGW（ApplicationGateway）：是IMS中与用户的第一个连接点，P-CSCF提供注册鉴权、信令保护、信令压缩、媒体授权、QoS控制、信令路由、紧急呼叫、漫游计费等功能。为支持号码补全以及紧急呼叫，P-CSCF需能识别紧急呼叫，获取用户位置信息，并在SIP信令中添加相应信息，且能将位置信息映射为区号。
ATCF/ATGW是VoLTE用户在当前所在网络的信令面和媒体面的锚定点，在发生eSRVCC时将VoLTE用户接入侧的媒体面从LTE切换到电路域，并保持媒体面的连接。
1.1.2 CSCF
CSCF（CallSession Control Function）—会话控制和路由，包含I-CSCF、S-CSCF、E-CSCF：
S-CSCF（ServerCSCF）：S-CSCF在IMS核心网中处于核心的控制地位，负责对UE的注册鉴权和会话控制，执行针对主叫端及被叫端IMS用户的基本会话路由功能，并根据用户签约IMS触发规则，在条件满足时进行到AS的增值业务路由触发及业务控制交互；
I-CSCF（interrogatingCSCF）：类似IMS的关口节点，提供S-CSCF指派、路由查询功能；
E-CSCF，从P-CSCF接受紧急会话建立请求，并完成用户接入位置信息查询和紧急呼叫路由等功能。
目前I-CSCF和S-CSCF在物理实体上是合设的
1.1.3 VoLTE AS
应用服务器（Application Server）为IMS用户提供增值业务，可以位于用户归属网，也可以由第三方提供，主要包含如下功能模块：
l MMTel AS（MultiMediaTelephony多媒体电话应用服务器）：用于为VoLTE用户提供多媒体电话基本业务和补充业务；
l SCC AS（Service Call Continuity Application Server服务集中化和连续性应用服务器）：实现VoLTE的被叫域选择，eSRVCC过程中的信令控制；
l 被叫锚定功能：支持CAP接口，提供被叫用户锚定至IMS；
l IM-SSF（IP Multimedia-Service Switch Function智能业务触发网关）：用于触发现有SCP，实现智能网业务逻辑；
l 业务配置转发（AP）：实现业务配置请求的汇聚和转发；
l MRF（Multimedia Resource Function多媒体资源功能）：负责对媒体资源的控制和处理，实现音视频播放、会议、DTMF收号和音频录音等功能。MRF包括多媒体资源控制器MRFC（Multimedia Resource Function Controller）和多媒体资源处理器MRFP（Multimedia Resource Function Processor）。
1.1.4 HSS
VoLTE中的HSS（Home Subscriber Server）---归属用户服务器是HLR/AuC、IMS-HSS、EPS-HSS三合一融合设备，统一存储VoLTE用户在2/3/4G及IMS的用户数据，处理2/3/4G及IMS网络中呼叫控制网元对用户的数据访问，还通过开通接口接收并响应BOSS业务开通指令。
1.1.5 MGCF/IM-MGW
MGCF（MediaGateway Control Function媒体网关控制功能）用于IMS域与CS域的互通，负责完成控制面信令的互通（PSTN/CS域侧ISUP/BICC协议与CM-IMS侧SIP协议的交互和互通），并控制IM-MGW（IP Multimedia-Media Gateway媒体网关）完成用户面媒体面的互通、号码规整、号码分析和路由、放音、放音抑制、视频回落等功能。
IM-MGW（媒体网关）负责在MGCF的控制下完成VoLTE用户面IP承载与CS域承载之间的转换，提供编解码转换、承载资源管理和放音功能。
1.1.6 BGCF
BGCF（BreakoutGateway Control Function出口网关控制功能）用于IMS到CS的呼叫路由，BGCF收到来自S-CSCF的呼叫请求后根据本地配置选择合适的MGCF进行转发。
1.1.7 DRA
DRA（DiameterRouting Agent路由代理节点）负责LTE Diameter信令目的地址翻译和转接, 实现LTE用户的鉴权、位置更新、计费管理。
1.2 IMS中的接口协议简介
1.2.1 Diameter
Diameter协议包括基本协议，NAS（网络接入服务）协议，EAP（可扩展鉴别）协议，MIP（移动IP）协议，CMS（密码消息语法）协议等
1.2.2 RTP/RTCP
应用层承载面协议，会话建立后，RTP（Real-time Transport Protocol实时传输协议）协议保证媒体流的实时传输；RTCP（Real-time Transport Control Protocol实时传输控制协议）协议对实时传输的媒体流进行监控。
1.2.3 SIP简介
会话（Session）：描述两个用户之间的媒体连接
会话流程：实现主叫UE和被叫UE之间的多媒体会话
会话流程中包括媒体的协商（包括媒体类型和编码方式的协商）和双方的资源预留过程。
会话初始协议（Session Initial Protocol）是一个在IP网络上进行多媒体通信的应用层控制协议，它被用来管理创建、修改和终结一个或多个参加者参加的会话进程，与SDP、RTP/RTCP、DNS等协议配合，共同完成IMS中的会话建立及媒体协商。
终端和网络互为客户端和服务器，使用标准的基于文本的请求（Request），然后以标准的基于文本的回复来应答（Response）。
1.2.3.1 请求（客户端）
REGISTER 注册
INVITE 邀请
PRACK 提供临时确认
UPDATE 更新连接状态
ACK 对INVITE消息的最终确认
BYE 挂断电话
SUBSCRIBE 订阅事件通知
NOTIFY 通知订阅者新的事件
CANCEL 取消
1.2.3.2 应答（服务端）
1XX--临时响应。表示请求已接收，接收方正在处理。
常见的有：100Trying、183ProvisionalAcknowledge、180 Ringing
2 XX --成功响应。请求已成功收到、理解并被接受。
常见的有：200 OK、202Accepted、204No Notification
3 XX --重定向响应。请求方需要采取进一步动作以完成请求。
4 XX --客户端响应错误。客户端提供了错误的语法或者无法从服务端得到响应。
常见的有：401Unatuhorized、486Busy Here、481Call transaction does not exist
5 XX --服务端响应错误。服务器无法提供合法的请求。
常见的有：500 Server Internal Error、503ServiceUnavailable、580Precondition Failure
6 XX --全局失败响应。请求不能再任何一个服务器上得到满足，产生该响应的服务器需要知道有关用户的确切信息。
1.3 SDP简介
会话描述协议SDP（SessionDescription Protocol）协议为应用层的控制协议，用于会话建立过程中的媒体协商。
1.3.1 媒体协商
主叫和被叫UE在会话的建立过程汇总需要对媒体的类型和编码方式达成一致，为此使用SDP请求和应答机制对媒体进行协商。
双方协商的媒体类型包括视频、音频、文本、聊天等。
每种媒体类型包括多种编码方式，如音频包括PCMU、G.726编码、AMR-WB（自适用多速率宽带）编码等。
双方需要协商都支持的媒体类型以及所使用的编码方式。
1.3.2 资源预留
为保证双方所协商的媒体会话可以建立，空口需要为主叫和被叫用户分配资源，在资源被成功预留之前，不能保证媒体会话可以建立
一般情况下进行SDP提供/应答的协商确定了媒体格式和编码方式后可进行资源预留。
1.3.2.1 主叫资源预留的开始和结束
主叫UE发送Invite消息后，启动资源预留过程。
主叫UE发送UPDATE请求表明资源预留成功
UPDATE请求发送的前提：
（1）主叫UE通过空口流程获知通话资源预留成功
（2）收到被叫针对PRACK的200OK响应
1.3.2.2 被叫资源预留的开始和结束
被叫UE收到主叫UE的Invite消息后，返回183响应并启动资源预留过程。
被叫发送UPDATE200表明资源预留成功，前提为主叫和被叫的资源预留均成功。
（1）被叫UE收到主叫的UE的UPDATE请求后得知主叫UE的资源预留成功。
（2）被叫UE通过空口流程获知通话资源预留成功。
1.4 被叫域选择和锚定方案
1.4.1 VoLTE用户被叫域选择流程
T-ADS（TerminatingAccess Domain Selection），即被叫域选择功能。
VoLTE手机既有可以在电路域使用语音业务，也可在IMS域使用语音业务，且使用同样的码号，因此存在“被叫接续网络选择”的问题，即网络如何识别被叫用户当前的驻留网络，并接续到该用户。
三融合HSS/HLR执行如下域选择过程：
若用户仅在IMS注册，则应选择IMS域
若用户尽在CS注册，则应选择CS域
若用户在IMS和CS均未注册，则应选择IMS域
若用户在IMS和CS均已注册，则应进一步判断用户在SGSN和MME的注册状态：
若有用户在SGSN的注册信息，无论用户是否在MME注册，则应选择CS域
若无用户在SGSN的注册信息，而有用户在MME的注册信息，则向MME查询用户状态和终端能力
若无用户在SGSN的注册信息，也无用户在MME的注册信息（用户在电路域关闭了所有APN），则应选择CS域
被叫锚定是指对于被叫VoLTE用户无论处于LTE还是GSM覆盖下，均先将呼叫送至其归属省的IMS网络进行处理，此处的锚定即固定送至IMS网络的意思。
被叫锚定的原因为无论被叫VoLTE用户处于LTE覆盖还是GSM覆盖均可保持补充业务（如呼叫等待、呼叫保持、呼叫转移、号码显示、多方通话等）的一致性。在VoLTE网络中用户补充业务的处理由AS负责完成，MSC不掌握VoLTE用户被叫补充业务信息，所以即便被叫用户处于GSM覆盖下，仍然要由AS来触发和提供补充业务，需要将呼叫送至IMS网络
2 接入优化
2.1 接入问题分类及现象
接入问题主要包括以下四类（从用户感知角度）：
（1）IMS注册慢/无法注册
开机后IMS图标不出现或出现较慢，IMS未出现时VoLTE终端相当于CSFB手机，拨打电话会回落到GSM
（2）VoLTE终端CSFB
VoLTE终端有IMS图标，拨电话前有4G图标，拨电话后回落到GSM，图标变成2G，电话可以拨通，但是接通时间长
（3）呼叫建立时延长
VoLTE终端有IMS图标，拨电话时手机一直显示4G，主叫从开始拨电话开始到听到振铃声时间较久。
（4）未接通
VoLTE终端有IMS图标，拨电话时手机一直显示4G，但是无法拨通。
注：IMS图标为IMS或者VoLTE（苹果无类似标志）
2.2 接入流程
接入流程分为注册流程和呼叫流程两部分：
（1） VoLTE注册流程（开机后即建立，包括LTE注册、默认承载建立、IMS承载建立、IMS注册过程）
（2） VoLTE呼叫流程（每次通话均需建立，通话结束后释放）
2.2.1 VoLTE注册流程
注：测试软件和eNB可以看到的流程
VoLTE注册流程（测试软件和eNB可以看到的流程）
1~2 UE发起EPC附着请求，包含PDN连接请求。
关注点：
VoLTE终端Voice DomainPreference为IMS PS VoicePreferred，CS VoiceSecondary，而LTE终端该字段为PS only
VoLTE终端和LTE终端都是联合注册，UE_usage_setting都是Voice centric
3~5 EPC网络对用户进行认证鉴权。
6~11完成默认承载建立流程
12 UE在发起IMS注册前需要建立IMS PDN连接。
13 UE发起新的PDN连接建立请求，其中携带APN为IMS，PCO获取P-CSCF地址。
14-15 MME返回PDN Connectivity accept包含P-SCSF地址列表（地址为IPV6）
16~19完成IMS PDN连接建立后续流程
20 UE通过IMS PDN默认承载发起IMS 注册请求，该SIP不加密，但其中包含通过IMSI导出的IMPU/IMPI，P-SCSF临时存储SIP消息中的安全参数
21 注册请求经SBC转发至S-CSCF，S-SCSF从HSS获取鉴权向量（XRES、IK、CK、AUTN、RAND），保留XRES
22 S-SCSF发送401未鉴权消息到P-SCSF，里边包含完整性和加密密钥（IK、CK、AUTN、RAND）
23 P-SCSF保留IK和CK，用于UE和S-SCSF间的IPSEC，将AUTN和RAND发送给终端
24 终端校验AUTN成功即对网络校验成功，然后计算XRES，重新发送的Register消息中携带XRES
25 S-SCSF对终端重发Register中的XRES和本地存储的XRES进行匹配，如果匹配成功，向UE返回注册成功响应
2.2.2 VoLTE呼叫流程
注：测试软件可以看到的流程
VoLTE呼叫流程（测试软件可以看到的流程）：
1 主叫如果在空闲态，随机接入后建立RRC连接，发送Invite消息，呼叫请求中包含所希望媒体类型和所有编码方式，precondition相关参数，其中主叫侧和被叫侧均为none
（注：RACH和RRC连接建立是由Invite消息触发的）
2 P-SCSF收到后回复100 trying给主叫，确认收到Invite消息，避免主叫Invite重发
3-5同时主叫侧申请通话资源（临时），触发网络建立专用承载
6-7被叫如果在空闲态，收到寻呼，随机接入后建立RRC连接后，收到Invite消息，先回复100 trying，对P-SCSF确认收到Invite消息，
8-12 183 SessionProgress消息按照呼叫路径回复支持的媒体类型和编码方式给主叫，同时被叫侧申请通话资源，触发网络建立专用承载
13-14主叫收到183消息后，发送PRACK（ProvisionalACK）消息，包含双方协商的媒体类型和编码方式，被叫收到后回复PRACK 200 OK，对所协商的媒体类型和编码方式进行确认
（注：PRACK是请求而非响应，是对临时响应的确认，因此被叫方收到请求后，需要发200OK确认）
15-17 主叫侧根据协商结果修改资源申请
18主叫UE通过空口流程获知通话资源预留成功，向被叫侧发起UPDATE，其中的precondition参数主叫侧为sendrecv，被叫侧为none。
19 被叫UE通过空口流程获知通话资源预留成功，向主叫返回200 OK，其中的precondition参数主被叫均为sendrecv
20-22 被叫振铃，发送180 Ringing消息给主叫，触发主叫听到被叫铃声，再发送200OK，对最初的INVITE的确认
23主叫回复ACK，通话建立，主被叫双方完成呼叫信令流程，双方开始通话
24 主叫侧挂机，UE向SBC发送BYE消息，之后消息转发至被叫SBC和UE。
25~28 主叫侧进行资源释放。
29~32 被叫侧进行资源释放。
2.3 接入问题原因分析及排查思路
2.3.1 IMS注册慢/无法注册
2.3.1.1 IMS注册慢/无法注册原因分析
IMS无法注册有以下原因：
终端设置问题，导致未发起注册
HTC手机“设置”—“数据连接”—“IMS服务”未勾选
苹果手机“设置”—“蜂窝移动网络”—“语音与数据”未勾选
三星手机“设置”—“移动网络”—“VoLTE电话”未勾选
B. 终端不支持VoLTE，无法发起注册
n 终端发起的Attach Request中Voice DomainPreference不为IMS PS Voice Preferred，CS Voice Secondary，将不支持VoLTE
n 终端能力显示不支持ROHC、FGI字段显示终端不支持eSRVCC切换、RLC UM模式、5bit RLC UM SN和7bit PDCP SN等功能，终端将不支持VoLTE
C. 网络不支持VoLTE，不支持IMS注册
网络下发的Attach Accept中IMSVoPS不为IMS VoPS Sessionin S1 Mode supported，网络将不支持VoLTE
D. IMS签约数据问题，导致无法注册
E. IMS注销失败，导致IMS后续无法注册
HSS未配置2G/3G 的IPV6 APN，导致终端从4G到2G后，RAU accept中删除了IMS PDP上下文，终端从2G重选到4G后，发起重新注册，由于IMS有fork功能，可以允许用户重复注册5次，第6次将无法注册。HSS上配置2G/3G 的IPV6 APN后问题解决。
F. 异厂家对接，导致注册消息未发送到SBC
华为DRA按照测试号段进行转发路由，而异厂家Gx（SBC与PCRF的接口）对接存在问题，导致USIM卡无法在中兴和华为区域同时注册。通过DRA修改配置解决问题。详见《VoLTE USIM卡无法同时在华为中兴区域使用问题处理》
IMS注册慢
终端版本问题。升级版本后可以解决，详见《HTC终端注册慢》
2.3.1.2 IMS注册慢/无法注册问题排查思路
A、首先确认终端设置是否正确（参考原因分析）
B、通过eNB或EPC上跟踪信令，确认终端和网络是否支持VoLTE（参考原因分析）
C、核查HSS中2G/3G/4G签约数据，确认是否签约IPV6 APN
D、确认IMS签约数据（将USIM卡装载在其他可以正常使用的手机中进行测试，确认USIM卡签约是否正常）
E、如果上述方法还无法定位问题，在eNB、IMS和EPC、DRA、PCRF等网元跟踪数据包，检查终端是否已经发出Register消息，消息已经路由到已经到哪个网元，终端是否已经注册多次
E、最后在终端上抓取信令，确认终端问题
2.3.2 VoLTE终端CSFB
2.3.2.1 VOLTE终端CSFB原因分析
A、终端在2/4G或者3/4G同时有状态信息，会被叫域选择到GSM。这种情况主要是MME与HSS交互问题；
华为MME“INTRAFORCE”未设置为“ULR”，当终端从2G 回到4G时，如果在同一个融合核心网网元下，TAU过程中不会发起Update Location流程，导致HSS同时存在2/4G状态，根据规范，被叫域选择到GSM。华为MME修改参数后解决问题。详见《MME参数设置导致VoLTE被叫CSFB问题处理》
华为MME“INTRASINGLEREG”未设置为“ENABLE”，在用户重新附着时，位置更新消息中携带的Single-Registration-Info标志位未置位，导致中兴HSS没有删除2G位置信息，被叫因此回落2G。华为MME修改参数后解决问题。问题处理同上。
B、终端收到错误消息（如500/503）后进行异常处理，发起silentRedial，回落到GSM。这种情况主要为SBC和EPC交互问题。
SBC转发INVITE消息给被叫RCRF时，会触发被叫终端鉴权请求确认，SBC发给PCRF的鉴权请求消息中携带的流描述信息中被叫UE的IP为IPV4，与集团规范要求为IPV6不一致，导致被叫域选择到GSM。中兴SBC修改参数后解决问题。详见《SBC的AAR消息不合规范导致VoLTE被叫CSFB》
EPC按照3GPP规范产生的计费标识中包含“0a”的内容，在IMS网络中，按照SIP协议将“0a”解析成换行符（ASCII码中，0a为换行符，非显性字符），造成对计费标识的误读，导致S-CSCF回复500（服务器内部错误）错误给主叫终端，主叫终端进行异常处理，进入CSFB流程。中兴SBC打补丁后解决问题。详见《SBC回复500错误导致终端CSFB》
在4G下的VoLTE用户做主叫，并向主叫中兴SBC发送初始invite消息后，由于主叫UE未携带相关带宽参数，因此中兴SBC在向PCRF申请资源时，未携带“Max-Requested-Bandwidth-ULAVP”，导致华为PCRF建立承载失败，中兴SBC在收到华为PCRF错误响应后，向UE回复503（ServiceUnavailable），导致部分终端CSFB。中兴SBC打补丁后解决问题。
2.3.2.2 VoLTE终端CSFB排查思路
A、如果终端有4G但无IMS图标，则终端未在IMS注册
B、如果终端有IMS图标，仅做被叫叫时回落GSM（4G图标变为2G图标），一般是IMS被叫域选择到GSM。需要在MME、HSS上进行信令跟踪，确认终端是否在多个域有状态
C、如果终端有IMS图标，做主叫或被叫都可能回落到GSM（4G图标变为2G图标），一般是收到错误消息后进行了异常处理。需要在IMS、EPC上进行信令跟踪，确认IMS发送什么类型错误消息，IMS与EPC进行联合分析
注：VoLTE终端CSFB
2.3.3 呼叫建立时延长
呼叫建立流程涉及较多网元，需要开展端到端分析，呼叫建立时延长主要为终端、DRA、MME、SGW问题。
如果VoLTE终端进入CSFB流程，呼叫建立时延也会相应变长，该问题详见上节《2.3.2 VoLTE终端CSFB》
2.3.3.1 呼叫建立时延统计方法
主叫发送Invite消息----主叫收到180振铃消息的时间
2.3.3.2 呼叫建立时延长原因分析
A. 终端
n 测试短呼时，两次时间间隔设置过短，被叫用户无法完全进入IDLE态，新的呼叫发起，被叫还处于连接态转IDLE过程暂态，收不到寻呼，通过网络多次寻呼才能成功，导致整体端到端呼叫延迟达6-9s。详见《HTC资源释放过慢导致呼叫建立时延过长》
n 终端版本问题，导致发送多次Invite消息。升级版本后问题解决。详见《终端侧invite消息丢失导致呼叫建立时延过长》
B. DRA
DRA“关于链路的数据捆绑开关”未打开，如果每条链路在50ms内收到的消息只有一条，并且消息包长度小于1500字节时，将导致每条消息的时延超过50ms。将“关于链路的捆绑数据开关 ”关闭，DRA与SBC交互时间降低到10ms。由于交互次数共24次，可以缩短时间24*40=960ms。详见《DRA参数配置不合理导致呼叫建立时延长》
C. MME
MME寻呼策略为首次eNB list（最近活动的7个eNB）寻呼，第二到六次为基于GUTI的TA list寻呼（包含一个TA），寻呼间隔为2.5s。eNB list寻呼成功率低，改为基于TA list寻呼后，呼叫建立时延大于5s的比例从25%降低到7%。
D. SGW
中兴SGW“报文缓存开关”未打开，导致invite消息丢失，必须要等待SBC重传。打开“报文缓存开关”开关后，可以缩短500ms~1s。详见《中兴SGW寻呼未缓存导致呼叫建立时延长》
2.3.3.3 呼叫建立时延长问题排查思路
A、eNB、EPC、IMS网元进行时间校准；
B、将IMS相关网元（P-SCSF、PCRF、AS、S-SCSF、HSS、DRA）的数据包汇聚到一个CE，抓取该CE中IP数据包，同步抓取SGW、MME的数据包，获取各SIP信令在不同的网元的时间点，从网元和SIP信令两个维度进行分段统计，统计时长占比较大的网元和SIP信令；
C、针对疑似问题网元开展相关SIP信令专项分析及问题定位。
2.3.4 未接通
2.3.4.1 未接通统计方法
主叫UE发送第一条SIP INVITE后收到网络侧下发的SIP 200 OK消息为成功完成呼叫，其他都算未接通
2.3.4.2 未接通问题分析方法
1、在主叫的事件中，找到Outgoing call block/Call blocked事件，记录时间点
2、在主叫信令中，找到Invite消息（Invite消息会比RRC连接建立请求消息时间早，因为点击拨号按钮时，首先触发Invite消息，而Invite消息再触发RRC连接建立），记录时间点
3、查看Invite消息到Block事件之间的时间段内，主被叫出现的异常信令
2.3.4.3 未接通原因分析
呼叫建立流程涉及终端、eNB、EPC、IMS等网元，所有网元的问题都可能导致未接通。
A、终端
HTC M8t某版本寻呼成功率低
HTC M8t某版本主叫终端收到PRACK 200 OK后未上报UPDATE
苹果终端暂不支持振铃中的eSRVCC，振铃中或振铃后，只要是接通前发起eSRVCC流程都会导致未接通
B、无线
SINR差（由于邻区、干扰等导致）
被叫无线环境恶化，SINR降低到-3dB，UE上报的invite183网络侧未收到，最终导致主被叫同时未接通
被叫LAU /RAU /TAU
主叫14:18:03发送INVITE消息，14:18:18超时主动上发Cancel消息。被叫该时段在进行G-T-L重选,包括LAU、RAU、TAU过程。
RRC连接异常释放
终端收到RRC连接释放，原因为other，然后进入空闲模式
C、IMS
SBC收到被叫的UPDATE 200OK后没有转发，详见《SBC收到UPDATE的200OK后没有转发》
目前所有厂家的IMS不支持振铃前eSRVCC，振铃前发起eSRVCC，都会导致未接通
D、端到端
SIP消息发送失败（在测试软件上看到的现象为终端发送多次SIP消息）
被叫手机在11:48.45.821接收到Invite消息后，分别在11:48.45.930、11:48:48.973、11:48:54.918发送了3次183消息，但是主叫一直没有收到183。
SIP消息丢失（在测试软件上看到的现象为无线环境良好的情况下，一个终端已发送消息，另一方未收到）
主叫14:50:11上发UPDATE消息，被叫一直未收到。此时无线环境良好，RSRP值在-93dBm以上，SINR值在17dBm以上。
被叫寻呼无响应，主叫收到480消息
主叫手机起呼后长时间未能成功建立通话，网络侧下发480Temporarily Unavailable（当前不可用）错误码，指示用户无响应。
被叫上报486 Busy Here
被叫在上报INVITE180振铃后，上报了Invite 486（Busy Here）。
专用承载未建立或丢失，终端上发580 Preconditionfailure
被叫专用承载未建立，在发送UPATE200OK后，被叫发送580消息给主叫。
主叫11:59:43.939发起呼叫,被叫11:59:48.248发送PRACK200 OK给网络。被叫11:59:48.967从PCI448(38100) 切换到 PCI 393(37900), 然后网络主动去激活专用承载。
基站核心网加密算法配置不一致
基站配置了祖冲之算法，但核心网未配置，导致未接通。核心网配置祖冲之算法后问题解决，详见《基站核心网加密算法配置不一致导致呼叫失败》
中兴SBC发送的AAR消息中IP地址格式错误导致未接通问题处理
中兴SBC发送的AAR消息的flow-description部分中的IPV6地址携带了“[]”书写格式，华为PCRF在转换过程中不识别解析失败，导致呼叫失败。中兴SBC打补丁后问题解决，详见《中兴SBC发送的AAR消息中IP地址格式错误导致未接通问题处理》
中兴SBC发送的STR消息存在异常
中兴SBC发送的STR消息未携带D-Host信息，华为LDRA转发不成功导致未接通。SBC发送的STR携带D-Host消息后问题解决，详见《中兴SBC发送的STR消息错误导致未接通问题处理》
华为LDRA参数设置不合理
华为LDRA“检查D-Host是否为本局开关”参数值为“1”，检测消息中的D-Host为本局的主机名时，需要做错误处理并返回DIAMETER_APPLICATION_UNSUPPORTED错误码，导致未接通。修改为“0”后问题解决，详见《华为LDRA参数配置导致未接通问题处理》
中兴SBC发送的AAR消息存在异常
中兴SBC发送的AAR消息携带了D-Host信息，DRA会直接根据目的主机名进行消息转发而不再走会话绑定查询流程，导致未接通。SBC发送的AAR消息不携带D-Host信息后问题解决，详见《中兴SBC发送的AAR消息错误导致未接通问题处理》
2.3.4.4 未接通问题排查思路
A、暂时无法解决的问题
由于目前所有厂家的IMS不支持振铃前eSRVCC，振铃前发起eSRVCC，肯定会导致未接通，该问题暂时无法解决
苹果终端暂不支持振铃中的eSRVCC，振铃中或振铃后，只要是接通前发起eSRVCC流程都会导致未接通，该问题暂时无法解决
B、无线原因排查：
主叫/被叫多次发送信令或者异常进入空闲模式，查看当时的SINR和RSRP，确认是否由于越区覆盖、邻区漏配、PCI模3干扰、弱覆盖等无线问题导致
主叫寻呼期间，被叫发起RAU/LAU/TAU，需要分析之前终端如何从4G重选或切换到GSM/TD
RRC连接异常释放，需要进行eNB信令跟踪，查看无线原因
C 、终端问题排查：
对比相同芯片的不同终端、异芯片终端，如果某款终端接通成功率低，则疑似终端问题，需要对终端进行排查
如果终端收到并正确解码某SIP消息，但未发出后续的SIP消息，则疑似终端问题
D、端到端原因排查：
主被叫发生SIP消息发送失败、SIP消息发送多次问题，则需要在eNB、EPC、IMS上同步抓取数据包，检查消息在哪些网元之间丢失，针对相关网元进行问题排查
如果主叫收到480消息（当前不可用）、603（谢绝邀请），一般为被叫未收到寻呼问题，需要在终端、eNB、EPC、PCRF、SBC上跟踪寻呼消息触发及发送情况
如果主叫收到486消息（被叫忙），一般为被叫终端发送，需要跟踪终端、EPC、HSS上信令，确认被叫忙原因
如果主叫或被叫发送580消息（资源准备失败），一般为专用承载未建立或承载丢失，需要在EPC、PCRF、SBC上跟踪信令，排查承载问题
A、加强LTE覆盖优化，让终端尽可能多驻留LTE网络，尽量避免由于G-L重选、振铃前eSRVCC导致的未接通
B、加强LTE 模3干扰排查，系统内邻区等优化，避免SINR差导致的未接通
C、由于GSM可能存在LAI插花问题，而LTE按照GSM的LAI同步规划了TAI，需要排查LAI插花导致的TAI插花问题，避免不必要的TAU导致的未接通
D、规范GSM重选LTE参数，使终端容易从GSM回到LTE，尽量避免G-T-L重选导致的未接通
E、与核心网、终端协同排查寻呼无响应、SIP消息丢失、SIP消息发送失败问题
F、与核心网协同排查RRC连接异常释放问题
G、联系核心网协同优化MME寻呼策略
H、定期升级终端版本
2.5 附录1：VoLTE注册端到端详细流程
VoLTE注册端到端详细流程：
1~2 UE发起EPC附着请求。
3~6 EPC网络对用户进行认证鉴权。
7~8 认证通过后，MME向HSS进行用户的EPC位置更新，并告知HSS IMS Voice homogeneous support。
9 MME根据用户签约发起默认PDN连接建立（默认APN为CMNETAPN）
10~11 SAE GW向PCRF获取默认规则，PCRF返回QCI=9。
12~20 完成默认承载建立后续流程。
21 UE在发起IMS注册前需要建立IMS PDN连接。
22 UE发起新的PDN连接建立请求，其中携带APN为IMS，PCO获取P-CSCF地址。
23 MME向SAEGW发起PDN连接建立请求，其中携带APN为IMS，PCO获取P-CSCF地址。
24~25 SAE GW向PCRF获取默认规则，PCRF返回QCI=5.
26 SAE GW返回PDN连接建立响应，其中包含P-CSCF地址
27~34 完成IMS PDN连接建立后续流程
35 UE通过IMS PDN默认承载发起IMS 注册请求，其中包含通过IMSI导出的IMPU/IMPI
36 注册请求经SBC转发至I-CSCF
37~38 I-CSCF向HSS发起查询，HSS返回S-CSCF的能力集
39 I-CSCF根据HSS返回的能力集选择S-CSCF并向其转发注册请求
40~41 S-CSCF向HSS查询用户的鉴权信息
42~44 S-CSCF向UE返回401响应，发起鉴权挑战
45~49 UE计算鉴权结果后再次发起注册请求
50~51 UE鉴权通过，S-CSCF向HSS获取用户签约信息
52~53 S-CSCF向AS发起第三方注册，并在其中携带UE发起的核心网注册请求消息
54~56 S-CSCF向UE返回注册成功响应
57~60 AS根据三方注册消息中的ATCF management URI向其发送MESSAGE请求，包含ATU-STI和C-MSISDN
61~62 AS向HSS更新STN-SR
63~64 HSS向MME推送STN-SR
2.6 附录2：VoLTE呼叫端到端详细流程（主被叫均在VoLTE）
VoLTE呼叫端到端详细流程（主被叫均在VoLTE）：
1 主叫用户UE(O)的呼叫请求发送到主叫SBC。呼叫请求中包含precondition相关参数，其中主叫侧和被叫侧均为none。
2 主叫SBC向PCC申请通话资源（临时），同时请求主叫用户位置信息。
3~4 主叫侧PCRF向S/P-GW下发策略。
5 主叫侧PCRF向SBC返回AAA响应。
6~8 主叫侧预留无线侧资源，MME在消息8中携带主叫位置信息（TAI+E-CGI）。
9~10 S/P-GW向PCRF返回主叫位置信息。
11~12 PCRF向SBC上报主叫位置信息。
13~16 主叫侧完成业务触发，主叫AS进行被叫号码补齐，之后主叫S-CSCF通过查询ENUM/DNS获取被叫I-CSCF地址并将呼叫请求发送至被叫I-CSCF。
17~18 被叫I-CSCF查询HSS获取被叫用户注册的S-CSCF。
19 被叫触发至VoLTE AS，基本呼叫和补充业务触发完成后触发SCCAS。
20 SCC AS进行被叫域选择，向HSS查询T-ADS信息。
23 HSS向SCCAS返回T-ADS信息，包含IMS Voice over PS supported。
24~26 呼叫请求转发至被叫UE。
27 被叫UE返回183其中包含被叫SDP信息，precondition参数中主叫侧和被叫侧均为none。
28~34 被叫侧申请通话资源。
35~42 183响应按照呼叫路径被转发至主叫。
44~50 主叫侧根据协商结果修改资源申请。
51~59 主叫UE通过空口流程获知通话资源预留成功，向被叫侧发起UPDATE，其中的precondition参数主叫侧为sendrecv，被叫侧为none。
60~68 被叫UE通过空口流程获知通话资源预留成功，向主叫返回200 OK，其中的precondition参数主被叫均为sendrecv。
69~71 主被叫双方完成呼叫信令流程，双方开始通话。
72~74 主叫侧挂机，UE向SBC发送BYE消息，之后消息转发至被叫SBC和UE。
75~81 主叫侧进行资源释放。
82~88 被叫侧进行资源释放。
3 保持优化
3.1 保持问题现象及分类
保持问题主要包括以下三类（从用户感知角度）：
（1）eSRVCC切换准备时延长
eSRVCC切换准备时延较长虽然不影响用户感知，但是可能会导致掉话
（2）eSRVCC用户面中断时延长
eSRVCC切换时，出现短暂的漏字问题
（3）掉话
VoLTE语音无法保持
3.2 eSRVCC切换流程
注：测试软件上可以看到的流程
3.3 保持问题原因分析及排查思路
3.3.1 eSRVCC切换准备时延长
3.3.1.1 eSRVCC切换准备时延统计方法
终端发出第一条B2上报的异系统MR---UE收到mobility form EUTRA的时长
3.3.1.2 eSRVCC切换准备时延长原因
中兴eMSC私有定时器设置异常，导致eMSC与MSC交互时间占eSRVCC切换准备时间的91%，而其中CS 侧局间承载建立时长（eMSC发送IAM给MSC----eMSC接收MSC的ACM）占比达到84%。修改定时器设置后，问题得到解决。详见《eSRVCC切换准备时延长问题处理》
3.3.1.3 eSRVCC切换准备时延问题排查方法
A、eNB、EPC、IMS、eMSC、MSC、BSC网元进行时间校准；
B、跟踪eSRVCC切换准备信令，获取各网元的时间点，从网元和信令两个维度进行分段统计，统计时长占比较大的网元和信令；
C、针对疑似问题网元开展专项分析及问题定位。
3.3.2 eSRVCC用户面中断时延长
3.3.2.1 eSRVCC用户面中断时延统计方法
终端在IMS收到最后一个上/下行RTP包---终端在GSM收到第一个上/下行语音包
3.3.2.2 eSRVCC用户中断时延长原因
eSRVCC用户面终端时延长主要是终端及芯片原因：
A、HTC终端
测试发现HTC终端eSRVCC用户面中断时延达到1700ms，远高于协议规定的300ms。对比同为高通芯片的SONY终端，时延仅为380ms，判断为HTC终端原因。HTC终端升级后问题解决。详见《HTC终端eSRVCC用户面中断时延长问题处理》
B、高通芯片
测试发现海思芯片的华为Mate7用户面中断时延仅为265ms，分析发现高通与海思芯片终端在业务面恢复时间上存在差异，eSRVCC到2G后，语音包编码器模式要做转换，高通芯片收到4个语音包之后才开始语音包译码，所以用户面中断时间比海思多出4*20=80ms。高通芯片正在进行补丁开发
3.3.2.3 eSRVCC用户中断时延问题排查方法
A、进行同芯片异终端厂家对比测试，确定是否某款终端存在问题
B、进行异芯片终端厂家对比测试，确定是否某芯片存在问题
3.3.3 掉话
3.3.3.1 掉话统计方法
主叫主动挂机时，主叫未收到SIP_BYE-OK或被叫未发送SIP_BYE-OK，均计算一次掉话
3.3.3.2 掉话问题分析方法
1、在主叫或被叫的事件中，找到Call Dropped事件，记录时间点
2、在主叫信令中，找到invite 200ok消息，记录时间点
3、查看invite 200ok消息到Call Dropped事件之间的时间段内，主被叫出现的异常信令
3.3.3.3 掉话原因
终端、无线、EPC、IMS等网元的问题都可能导致掉话。
A、终端
HTC终端呼叫20秒后掉话
由于HTC终端版本问题，呼叫20s后掉话。升级版本后问题解决。详见《HTC终端呼叫20秒后掉话》。
B、无线
异频重定向后，专用承载丢失
无线环境正常情况下（RSRP：-111dBm，SINR：7dB），从38400重定向到37900后，异频重定向掉话。该问题为中兴eNB已知bug，将打补丁解决。
TM3与TM8转换，概率性专用承载丢失
12:09:14秒的RRC连接重配置消息中天线传输模式为TM3
在12:09:26秒终端发送RRC连接重建请求，基站侧在进行TM3到TM8转换，拒绝RRC连接重建。
12:09:26秒终端上发BYE掉话，这时专用承载丢失。
无线链路失败、RRC连接重建失败
系统内切换后无线链路失败，详见《无线链路失败导致VoLTE掉话分析》
RRC连接重建失败
弱覆盖
问题路段无站点覆盖，且周边基站天线已无法调整，RSRP达到-126dBm，SINR降低到-8.9dB，导致掉话。详见《弱覆盖引起VoLTE掉话》
干扰（重叠覆盖、越区覆盖、PCI模3干扰）
UE占用跨越咸嘉湖占用小区474586（156）之后缺失附近邻区关系导致无线环境逐步恶化，最后导致掉话。需要控制越区覆盖小区覆盖。
参数配置（eSRVCC的GSM BSIC配置错误、eSRVCC邻区漏配、eSRVCC切换参数配置不合理、系统内邻区漏配）
eSRVCC的GSMBSIC配置错误
B2测量报告中GSM邻区为BCCH 525，BSIC码为12，而网管配置的GSM邻区的BCCH为525，BSIC码为7。详见《GSM邻区参数配置错误eSRVCC失败导致掉话》
eSRVCC邻区漏配：
eSRVCC邻区漏配造成掉话。详见《GSM邻区遗漏重定向引起掉话》、《GSM邻区配置不完整导致eSRVCC切换失败》
eSRVCC切换参数配置不合理
终端开始A2测量后，RSRP弱到-120dBm后还没来得及上报B2事件，导致掉话。详见《终端未上报B2测量报告无法进行eSRVCC切换》
系统内邻区漏配
详见《LTE小区邻区漏配导致VoLTE掉话》
eSRVCC切换收到了CCO命令
GERAN邻接关系中支持切换配置为“不支持”，eSRVCC切换收到了CCO命令。详见《eSRVCC切换收到了CCO命令》
eSRVCC切换失败
华为区域PS to CS eSRVCC切换失败（终端未在GSM上报切换完成命令）后发生1次掉话。由于目前华为暂不支持eSRVCC回滚，切换失败后肯定会掉话。
基站故障
车辆行驶在岳华路与岳麓大道交叉口处，终端UE2占用4625261小区长沙科技大厦（学海阅江酒楼拉远）上产生掉话事件，掉话时无线环境差（RSRP：-122dBm，SINR：-0.1dB）。经核查，发现长沙岳麓大道与岳华路路口基站出现故障导致基站占用其他小区信号，弱覆盖掉话。
B、EPC
专用承载丢失
终端在无线环境较好的情况下(RSRP:-69dBm，SINR:23)，忽然收到网络侧下发的去激活专有承载请求导致掉话，携带的原因值为：Regulardeactivation，需要核查PCRF、EPC
核心网下发Detach Request
核心网下发detach请求导致掉话
异厂家MME切换掉话
中兴MME对华为MME送过来的切换请求消息中的可选字段进行了误判，导致切换掉话。中兴MME打补丁后问题得到解决，详见《VoLTE异厂家跨MME切换失败问题处理》
TAUReject/Service Reject（我省暂未出现）
C、端到端
RRC连接异常释放
无线环境良好的情况下(RSRP:-88dBm，SINR:13)，由频点37900，PCI 10的小区切换到频点37900，PCI 155的小区后，收到网络下发的RRC ConnectionRelease，原因值为other
3.3.3.4 保持问题排查思路
A、无线原因排查：
终端异常进入空闲模式或者无线链路失败、RRC重建失败，需要查看当时的SINR和RSRP，确认是否由于越区覆盖、邻区漏配、PCI模3干扰、弱覆盖、基站故障等无线问题导致
eSRVCC切换失败需要对GSM邻区频点和BSIC码数据进行核查；
异频重定向和TM3/8转换为已知基站问题，需要升级基站版本解决；
B、EPC原因排查：
如果保持期间发生专用承载丢失、核心网下发Detach Request，跟踪MME、S/PGW、PCRF信令查找问题原因
C 、终端问题排查：
对比相同芯片的不同终端、异芯片终端，如果某款终端掉话率高，则疑似终端问题，需要对终端进行排查
D、端到端原因排查：
RRC连接异常释放，则需要在eNB、EPC、IMS上同步抓取信令和数据包，检查消息在哪些网元之间丢失，针对相关网元进行问题排查
3.4 保持问题无线主要优化手段
A、加强LTE覆盖优化，在弱覆盖区域配置eSRVCC邻区，优化eSRVCC的异系统切换门限，规范GSM邻区频点及BSIC的配置，与2G数据保持一致，优化eSRVCC的异系统切换门限，确保VoLTE通话保持连续
B、加强LTE 模3干扰排查，系统内邻区等优化，避免SINR差导致的掉话
C、升级基站版本，解决异频重定向和TM3/8转换导致的掉话问题
D、及时排除基站故障
E、与核心网协同排查RRC连接异常释放问题、专用承载丢失、网络发起的Detach问题
F、定期升级终端版本
3.5 附录1：eSRVCC端到端详细流程
1.用户终端向E-UTRAN发送测量报告
2.基于用户终端的测量报告，E-UTRAN决定触发一个到GERAN的SRVCC切换
3.源E-UTRAN向源MME发送切换需求（目标ID，源到目标的透明容器，SRVCC切换指示），E-UTRAN在源到目标透明容器中为 CS域设置“Old BSS to New BSS information IE”,SRVCC切换指示向MME表明目标只有CS能力，因此这是一个只面向 CS域的SRVCC切换操作。该消息包含一个 UE在目标蜂窝中PS服务不可用的标识
4.基于与语音承载相关联的QCI和SRVCC切换指示，源MME将语音承载从非语音承载中分离出来，并对MSC Server启动语音承载的PS-CS切换流程
5.MME向MSC Server发送一个SRVCC PS to CS Request消息(国际移动用户标识符IMSI，目标 ID，STN-SR,C-MSISDN，源到目标透明容器， MM上下文，紧急标识)，如果正在进行的是紧急会话，则消息中将包含紧急标识。对于 UE在受限服务模式下操作的情况，MME也将在请求消息中包含设备识别符。如果认证过的 IMSI和C-MSISDN可用的话，也被包含在请求消息中。MME从HSS接收在E-UTRAN附着流程期间下载的C-MSISDN和STN-SR作为 Subscriptionprofile的一部分。MME上下文包含相关的安全信息，CS安全密钥由MME从E- UTRAN/EPS域密钥派生，并在MM上下文中发送
6.MSC Server通过向目标MSC发送准备切换请求(Prepare Handover Request)消息，使 PS-CS切换请求和MSC之间的切换请求实现互操作。MSC Server分配一个默认SAI作为在到目标MSC的接口上的源ID。并用BSSMAP为准备切换请求进行封装。 NOTE1:SAI的默认值是在MSC中配置的，它允许release 8及其后的BSC识别SRVCC切换的源是E-UTRAN.为了保证在目标BSS中准确的统计量，默认的SAI应该跟UTRAN中使用的SAIs区别开来。 SAI:Service Area Identifier
7.目标MSC通过与目标BSS交换切换请求/确认消息来进行资源分配
8.目标MSC向MSC Server发送一个准备切换响应消息(Prepare Handover Response)
9.在目标MSC和与MSC Server关联的MGW之间建立电路连接。例如使用ISUP IAM和 ACM messages.ISUP IAM:ISDN User Part Initial Address Message
10. 对于非紧急会话，MSC Server用STN-SR 启动会话迁移(Session Transfer)。例如：向 IMS发送一个ISUP IAM(STN-SR)。对于紧急会话，MSC Server用本地配置的E-STN-SR 启动会话迁移。在会话迁移过程中执行标准的IMS业务连续性或紧急IMS业务连续性。 NOTE2:该步骤可在8后就开始。 NOTE3:如果MSCServer正在使用一个ISUP 接口，则在用户平面(subscriberprofile)包含的CAMEL触发器对于优先切换不可用的情况下，非紧急会话的会话迁移可能失败
11.远端(remote end)在会话迁移流程期间被 CS access leg的SDP更新。此时，VoIP分组的下行数据流被交换到CS access leg
12.源IMS access leg被释放。 NOTE4:Step 11、12与13相独立
13.MSC Server发送一个SRVCC PS to CS响应消息(目标到源透明容器)到源MME
14.源MME发送一个切换命令(Handover Command)消息到源E-UTRAN，该消息只包含语音组件的相关信息
15.源E-UTRAN发送一个Handover from E- UTRAN Command 消息到UE
16.UE调整(tunes to)到GERAN
17.目标BSS进行切换检测(Handover Detection).UE通过目标BSS发送一个切换完成(Handover complete)消息到目标MSC，如果目标MSC不是MSCServer,则目标MSC 发送一个SES(HandoverComplete)消息到 MSC Server
18.UE开始挂起(Suspend)流程。从GUTI中派生TLLI和RAI对。这将触发目标SGSN向源MME发送挂起通知消息，MME向目标 SGSN返回挂起确认。 NOTE5:MME也许不能从接收到的P-TMSI和 RAI对中派生出GUTI，因此它可能不能辨识出与挂起通知消息相关联的是哪一个UE的上下文，在这种情况下，承载也将被在step 22a去激活或挂起
19.目标BSS向目标MSC发送切换完成(Handover Complete)消息
20.目标MSC发送一个SES(Handover Complete)消息到MSC Server.语音电路在 MSC Server/MGW中完成连接
21.用到MSC Server的ISUP Answer 消息完成建立流程
22.MSC Server发送一个SRVCC PS to CS Complete Notification到源MME，通知它 UE已经到达目标侧。源MME发送一个SRVCC PS to CS Complete Acknowledge 消息到MSC Server进行应答
22a.MME修改语音承载，并设置PS to CS 切换指示器，移除其他的GBR承载，MME还将到S-GW和P-GW的非GBR承载挂起，将所有EPS承载的S1-U承载释放。所有GBR承载通过在MME、S-GW、P-GW中删除GBR承载上下文而被去激活。至于GTP-based s5/s8,S-GW通过发送Modify BearerRequest Message请求P-GW删除所有GBR承载上下文。 GBR:Guaranteed Bit Rate PCC:Policy and Charging Control
23a.如果IMSI在VLR(拜访位置寄存器)中未知，则MSC Server将执行到HSS/HLR的 MAP Update Location,一种例外是不存在认证过的IMSI(例如对于一个用认证IMSI的紧急会话服务)
23b.如果MSC Server执行MAP Update Location，并且如果多个MSC/VLR为相同的 LAI服务，则MSCServer用一个带有它自己的网络资源标识符(NRI)的非广播LAI执行到 UE的TMSI重分配。LAI:Location Area Identity
24.对于紧急服务会话，在切换完成以后，源MME或MSC Server可能向源或目标侧关联的GMLC(Gateway Mobile Location Center)发送一个MSCServer 标识的用户位置报告(Subscriber Location Report)
在CS语音会话结束后，如果UE仍在GERAN中，则UE 将通过向SGSN发送一个路由区域更新请求(Routing Area Update Request )来恢复PS服务。更新类型依赖于GERAN网络的操作模式，如果UE在CS语音会话结束后已经返回到E-UTRAN，则UE将通过发送TAU(Track Area Update)到MME来恢复PS服务。 MME将通知S-GW和P-GW恢复挂起的承载
3.6 附录2：eSRVCC开启导致4G现网的问题
3.6.1 eSRVCC切换功能开启导致ATU设备掉线问题处理
目前仅VoLTE终端才具备支持eSRVCC能力，中兴未先判断终端是否支持VoLTE，仅根据终端能力中“支持4G到2G切换”，错误判断ATU设备支持eSRVCC。ATU发起普通数据业务时，4G连接态到2G使用使用CCO，导致掉线。eNB版本升级后问题解决。详见《eSRVCC切换功能开启导致ATU设备掉线问题处理》
3.6.2 eSRVCC开启后CSFB偶尔失败问题处理
中兴发现网管600版本将2G邻区中900/1800频点配置在同一组时，会概率性导致eSRVCC切换失败。因此，为了规避该问题，中兴网管将900/1800频点分组配置，在进行语音业务CSFB过程中随机下发4G小区所配置的900频点组或者1800频点组，两组不能同时下发，CSFB有一定概率回落到距离远电平弱的2G频点，被叫无法收到寻呼消息，导致未接通。中兴网管601版本完善功能，问题得到解决。详见《eSRVCC开启后CSFB偶尔失败问题处理》
网优联盟投稿邮箱：wygcs1818@126.com
长按二维码可关注
网优路上，有你更精彩............
