VoLTE端到端业务质量分析要点

VoLTE端到端质量分析
SIP-503错误码原因分析研究
目录
1.SIP-503消息错误码分析背景 (2)
2.SIP-503失败原因分类 (2)
3.SIP-503流程分析 (4)
3.1.无线链路失败导致掉话 (4)
3.2.VoLTE走盲重定向导致掉话 (5)
3.3.X2切换失败导致的掉话 (5)
3.4.Sip信令丢失导致未接通ue-not-available-for-ps-service (6)
3.5.2G侧资源异常导致未接通 (8)
3.6.基站弱场起呼功能导致 (8)
3.7.BSRVCC切换失败 (9)
3.8.VoLTE参数配置问题 (10)
3.9.VoLTE流程冲突问题（1） (11)
3.10.VoLTE流程冲突问题（2） (12)
3.11.VoLTE流程冲突问题（3） (13)
3.12.VoLTE流程冲突问题（4） (13)
3.13.VoLTE流程冲突问题（5） (14)
4.SIP-503失败案例总结 (15)
4.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry (15)
4.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry (16)
4.3.传输问题导致SIP-503 S1切换导致VoLTE掉话 (19)
4.4.站内切换与modify并发SIP-503导致视频失败 (23)
4.5.站内切换并发导致未接通 (24)
5.SIP-503失败原因处理流程总结 (26)
1.SIP-503消息错误码分析背景
2016年中国移动集团开展VoLTE百日会战工作期间，我司在VoLTE质量提升过程中结合炎强平台从TOP小区、DT/CQT遍历拉网测试信令分析中总结经验，旨在帮助各办事处尽快解决信令分析中遇到的问题。

随着VoLTE优化工作的开展，我们发现有些SIP-503错误码与无线测关联较大，如外部邻区、帧头偏移未对齐导致的干扰，传输时延、切换并发等问题都会导致SIP消息报错，而这些SIP消息报错的时间点之前eNB就发起了异常的信令释放。

因此，本文档希望纠正概念中泛指SIP503都是核心网的问题。

2.SIP-503失败原因分类
目前，通过甘肃、贵阳两地测试分析结果来看，SIP503错误消息也是各类无线测试中最常见的错误消息，与用户的未接通、掉话等异常行为直接相关。

基于信令平台对可能发生503错误消息的所有场景整理出SIP503消息报错为四大类13种场景，做了统一信令回溯和原因分析，并开展了对应的优化策略和研究，针对每一类问题场景给出了明确的解决方案。

四大类（eNodeB上发UE上下文释放请求、bSRVCC不兼容引发的切换失败、VoLTE参数配置问题、流程冲突承载建立\释放或者修改与切换并发失败）详细情况如下表：
3.SIP-503流程分析
3.1.无线链路失败导致掉话
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest，携带原因值radio-connection-with-ue-lost。

➢处理建议：
接续过程中，主叫或被叫UE失步，eNodeB在检测到UE无线链路异常后发起RRC连接和UE上下文释放流程，后续UE重回4G网络发起TAU和QCI5默载建立流程。

需要核查问题小区明细，排查小区覆盖、干扰问题。

➢信令流程说明：
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest ,携带原因值radio-connection-with-ue-lost , 表明eNodeB为UE失联，MME指示eNodeB释放了UE上下文，并且通过S11接口把承载失败问题传送给SAEGW, SAEGW通过Gx接口告知PCRF，PCRF通过Rx接口通知SBC，随后SBC通过Gm接口给UE发送了503 SIP错误码，造成呼叫失败。

3.2.VoLTE走盲重定向导致掉话
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest，携带原因值interrat-redirection。

➢处理建议：
该问题为UE重定向到2/3G引起，发生区域均在我司设备区域，目前我司620版本仍无法区分不同QCI的A2/B2（重定向、eSRVCC只能配置一个），部分区域考虑数据业务驻留比未部署eSRVCC。

预计6月中旬版本升级后可解决此问题。

➢信令流程说明：
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest ,携带原因值interrat-redirection, 表明UE重定向到了2/3G，MME指示eNodeB释放了UE上下文，并通过S11接口把承载失败问题传送给SAEGW, SAEGW通过Gx接口告知PCRF，PCRF通过Rx接口通知SBC，随后SBC通过Gm接口给UE发送了503 SIP错误码，造成呼叫失败。

3.3.X2切换失败导致的掉话
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest，携带原因值tx2relocoverall-expiry。

➢处理建议：
该问题为X2切换过程中，UE由于无线环境较差无法成功接入目标小区，发起重建流程，eNB 侧X2切换计时器超时发起UE上下文释放。

需要无线侧核查切换涉及的源小区和目标小区明细，排查邻区关系配置、邻区切换参数配置、小区覆盖及干扰问题。

➢信令流程说明：
在呼叫建立阶段，eNodeB上发UEContextReleaseRequest ,携带原因值tx2relocoverall-expiry, 表明发生了X2切换请求，但是X2切换计时器tx2relocoverall超时，MME指示eNodeB释放了UE上下文，并通过S11接口把承载失败问题传送给SAEGW, SAEGW通过Gx 接口告知PCRF，PCRF通过Rx接口通知SBC，随后SBC通过Gm接口给UE发送了503 SIP错误码，造成呼叫失败。

3.4.Sip信令丢失导致未接通ue-not-available-for-ps-service
在VoLTE呼叫建立阶段，存在是Sip信令丢失在SGI/S1AP/UU口导致未接通，具体现象为sip 信令（如invite/183session progress/prack/update/180 ringing/终端未发送invite 200ok 等）连续发送多次之后未收到响应，触发两种现象：
1.PCRF通知DRA放弃本次会话，携带的错误码为“INSUFFICIENT BEARER RESOURCES”（不
足的承载资源），该类问题多见于183 session progress/180ringing/终端未发送invite 200ok消息丢失；
2.SCCAS用“SIP：Status 500 server internal Error”内部错误消息携带的原因为“ NO
Response From Peer”通过SCSCF告知SBC，从而触发PCRF放弃本次会话，导致VoLTE 未接通触发CSFB。

该类问题多见于update/prack等消息。

➢处理建议：
该问题多见于无线环境较差，干扰严重，或者传输异常，eNB资源不知导致无法正常的进行正常的VoLTE呼叫，针对该类问题主要通过排查覆盖（可通过开启MR确定是否弱覆盖小区针对
VoLTE用户较少的站点可以通过cdl 确定，核查邻区是否缺失，掉线指标是否正常），干扰，传输故障，基站是否拥塞等。

➢信令流程说明：
在VoLTE呼叫建立阶段，主叫SBC连续下发四次180 Ringing，未收到被叫响应的invite 200ok，或连续多下发183 session progress触发PCRF通知DRA放弃本次会话，携带的错误码为“INSUFFICIENT BEARER RESOURCES”（不足的承载资源）。

在VoLTE呼叫建立阶段，主叫SBC连续下发UPDATE未收到响应导致scc as定时器超时（一般设置为6s）SCCAS用“SIP：Status 500 server internal Error”内部错误消息携带的原因为“ NO Response From Peer”通过SCSCF告知SBC，从而触发PCRF放弃本次会话，导致VoLTE未接通触发CSFB。

详情如下：
3.5.2G侧资源异常导致未接通
在 VoLTE呼叫CS域过程中，VoLTE用户资源准备并修改完成的情况下，收到MGCF响应的invite 503携带的原因为“NO Circut/channel avialible”导致未接通。

➢处理建议：
该问题为2g侧资源问题导致，需核查2g侧资源情况。

➢信令流程说明：
在 VoLTE呼叫CS域过程中，VoLTE用户完成update流程后收到Mgcf的Mgcf响应的invite 503携带的原因为“NO Circut/channel avialible”，释放本次会话。

3.6.基站弱场起呼功能导致
在目前核心网不支持bSRVCC，在弱覆的情况下易导致未接通，我司与华为通过在弱覆盖情况下限制qci 1的建立并利用终端和ims cs Retry功能完成弱场起呼。

但是这也触发invite 503。

➢处理建议：
建议在核心侧剔除该类问题导致的未接通。

在分析该类s1错误码为“radio resources not avialible”，核查该站点是否开启弱场起呼功能。

➢信令流程说明：
SBC收到主叫上发的invite消息后，通知eNB建立无线承载时收到核心eNB响应的ERAB setup respone携带原因为“radio resources not avialible”触发invite 503，终端收到后触发CSFB，从而避免了bSRVCC。

详情如下：
3.7.BSRVCC切换失败
bSRVCC切换失败，MME下发的切换准备失败消息“Handover Preparation Failure”中，携带原因值：un-specified。

➢处理建议：
由于目前IMS版本不支持bSRVCC切换，切换失败后终端触发CSFB流程，按集团要求5月底基站升级版本后，基站侧可识别并规避bSRVCC切换。

➢信令流程说明：
振铃以前进行bSRVCC切换,IMS不支持导致MME回复“HandoverPreparationFailure”携带原因值：un-specified。

3.8.VoLTE参数配置问题
在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值not-supported-QCI-value
➢处理建议：
VoLTE参数配置问题，需要从信令平台上提取相关小区明细，核查对应eNodeB上VOLTE相关参数配置。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABSetupRequest消息给eNodeB请求建立QCI=1的e-RAB，eNodeB回复E-RABSetupResponse给MME，携带原因值not-supported-QCI-value，eNodeB VOLTE 业务相关参数配置存在问题。

3.9.VoLTE流程冲突问题（1）
在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值multiple-E-RAB-ID-instances ➢处理建议：
由于前次呼叫ERAB建立、释放与切换流程冲突导致专载释放失败，需要设备统一升级解决，同时MME、eNodeB需要增强处理机制（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABSetupRequest消息给eNodeB请求建立QCI=1的e-RAB ，eNodeB回复E-RABSetupFailure给MME，携带原因值multiple-E-RAB-ID-instances，需要进一步分析该用户S1-MM1之前的行为。

在上次VOLTE呼叫结束时，MME下发E-RABReleaseCommand消息给eNodeB，eNodeB因为用户正在切换，返回E-RABReleaseFailed, 携带原因值“s1-inter-system-handover-triggered”，后续MME再没有再次下发E-RABReleaseCommand消息给eNodeB，尝试释放QCI=1，e-RAB ID=7的E-RAB承载，之后新的呼叫开始，建立e-RAB ID=7的e-RAB承载，因为e-NodeB发现e-RAB ID 重复，就回复E-RABSetupFailure给MME，携带原因值multiple-E-RAB-ID-instances。

3.10. VoLTE流程冲突问题（2）
在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值s1-inter-system-handover-triggered。

➢处理建议：
为e-RAB建立或者更改流程和SRVCC切换流程冲突引起，需要设备统一版本升级解决该问题。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABModifyRequest消息给eNodeB请求更改QCI=1的e-RAB 承载，eNodeB回复E-RABModifyFailure给MME，携带原因值s1-inter-system-handover-triggered 。

通过信令流程，在e-RAB更改请求和e-RAB响应之间eNodeB上发了系统间的切换请求，发生了bSRVCC切换，因此，eNodeB针对更改QCI=1的e-RAB 请求，回复了失败响应。

3.11. VoLTE流程冲突问题（3）
在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值unknown-eNB-ue-s1ap-id。

➢处理建议：
为切换与ERAB Modify过程并发引起的流程冲突导致，需要统一升级设备版本解决。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABSetupRequest消息给eNodeB请求建立QCI=1的e-RAB 承载，eNodeB回复E-RABSetupFailure给MME，携带原因值unknown-eNB-ue-s1ap-id ，告知MME 不识别MME下发的eNB-UE-S1AP-ID，在此之前，S1-MME接口并没有释放UE上下文，UE一直处于连接态，沿用之前的eNB-UE-S1AP-ID，之前的消息交互都没有问题，因此需要eNodeB厂家调查不识别eNB-UE-S1AP-ID的原因。

3.12. VoLTE流程冲突问题（4）
在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值x2-handover-triggered。

➢处理建议：
为e-RAB建立或者更改流程和X2切换流程冲突引起，需要设备版本统一升级，规避该问题。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABSetupRequest消息给eNodeB请求建立QCI=1的e-RAB 承载，eNodeB回复E-RABSetupFailure给MME，携带原因值x2-handover-triggered 。

通过信令流程，在MME下发e-RAB建立请求的同时发生了X2切换，因此，eNodeB针对建立QCI=1的e-RAB 请求，回复了失败响应。

3.13. VoLTE流程冲突问题（5）
在e-RAB建立时，eNodeB返回e-RAB建立或者更改失败，携带原因值radioNetwork: unknown-eNB-ue-s1ap-id，在RSRP-104dBm，SINR5.2的时候由于切换并发导致一次未接通。

➢处理建议：
为e-RAB建立或者更改流程和X2切换流程冲突引起，需要设备版本统一升级，规避该问题。

➢信令流程说明：
VoLTE呼叫建立时，MME通过下发E_RABSetupRequest消息给eNodeB请求建立QCI=1的e-RAB 承载，eNodeB回复E-RABSetupFailure给MME，携带原因值unknown-eNB-ue-s1ap-id 。

通过信令流程，在MME下发e-RAB建立请求的同时发生了X2切换，因此，eNodeB针对建立QCI=1的e-RAB 请求，回复了失败响应。

4.SIP-503失败案例总结
4.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry
➢炎强PCAP包信令分析
通过PCAP包信令分析如下，在时间15:15:14发起INVITE-Request,时间点15:15:17终端上发Request-ACK表示会话已经接通,但在时间点15:15:49终端收到网络下发的BYE消息携带的失败原因为承载资源释放。

导致一次未接通事件如下图：
(Reason: SIP;cause=503;text="PO: RAR: INDICATION_OF_RELEASE_OF_BEARER")
继续通过PCAP包信令分析发现在时间点15:15:49, eNB主动进行拆链释放原因为X2重定位完成定时器超时UEContextReleaseRequest Cause: radioNetwork (tx2relocoverall-expiry)。

➢无线空口分析
在南北滨河路遍历拉网测试过程，我们在华为区域测试过中出现掉话事件，通过无线测试分析，失败原因如下图：
SIP;cause=503;text='PO: RAR: INDICATION_OF_RELEASE_OF_BEARER'
在的时间点15:15:37被叫终端收到网络侧下发切换的RRC Connection Reconfiguration消息后终端未回复RRC Connection Reconfiguration Complete,由于RSRP=1104dbm左右，SINR=-7左右终端触发RRC重建后掉话。

➢解决方案
通过与华为工程师进行沟通确认由于修改了目标小区的PCI，但未及时同步修改外部邻区数据导致本次切换失败，后经华为修改PCI后，在二次验证中再无掉话的问题。

4.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry
➢炎强PCAP包信令分析
通过PCAP包信令分析如下，在时间11:42:53发起INVITE-Request,时间点11:42:57终端上
发Request-ACK表示会话已经接通,但在时间点15:44:19终端收到网络下发的BYE消息携带的失败原因为承载资源释放。

导致一次未接通事件如下图：
(Reason: SIP;cause=503;text="PO: RAR: INDICATION_OF_RELEASE_OF_BEARER")
继续通过PCAP包信令分析发现在时间点11:44:19, eNB主动进行拆链释放原因为无线链路失败UEContextReleaseRequest 。

Cause: radioNetwork (failure-in-radio-interface-procedure(26))
➢无线空口分析
主叫占用EARFCN:37900、PCI:390小区，终端发起SIP INVITE会话呼叫，服务器响应并回复终端SIP INVITE 100 Trying，网络侧发起QCI=1，EPS承载为7建立的语音业务，无线环境良好CRC-RSRC=-90dbm，CRC-SINR=12，在11:44:22 由于UE上行PUSCH功率较大，上行失步导致主叫掉话。

通过主被叫信令分析，主被叫UE接通后占用崔家大滩西侧微站LTE-1小区（EARFCN:37900、PCI:390）后，无线覆盖较好，但是UE上行的PUSCH TxPower却增大至22，上行失步2s后11:44:21重选至宏润建设集团LTE-8小区 (EARFCN:37900、PCI:7）进行RRC重建请求，重建请求拒绝后，UE收到网络侧下发的BYE Request消息，通过后台网管提取该小区子帧干扰情况，发现崔家大滩西侧微站LTE-1小区2、7子帧有强干扰，由于上行干扰失步导致掉话。

网元友好名:崔家大滩607018
小区本地ID = 4
小区子帧号= 1
小区上行底噪测量值
= {0,0,0,4,0,0,0,0,4,5,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13} 小区上行通道总功率测量值(dBm)
= {-94,-92,-127,-127,-127,-127,-127,-127,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区上行无用户通道总功率测量值(dBm)
= {-94,-92,-127,-127,-127,-127,-127,-127,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区子帧号= 2
小区上行底噪测量值
= {24,24,24,25,24,23,23,22,20,18,19,21,20,17,19,21,20,20,22,21,20,19,19,21,20,21,21 ,20,18,19,20,20,19,20,18,21,19,20,21,22,21,20,21,19,21,23,22,21,23,22,22,22,20,20,21 ,20,19,18,19,19,20,19,20,19,20,20,20,22,20,20,20,19,19,20,21,20,19,20,20,19,22,22,21 ,21,19,20,20,21,21,19,19,19,21,20,21,21,20,20,20,21}
小区上行通道总功率测量值(dBm)
= {-55,-53,-116,-116,-116,-116,-116,-116,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区上行无用户通道总功率测量值(dBm)
= {-81,-81,-116,-116,-116,-116,-116,-116,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区子帧号= 6
小区上行底噪测量值
= {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,1,11,12,12,14,0,0,8,0,0}
小区上行通道总功率测量值(dBm)
= {-83,-85,-127,-127,-127,-127,-127,-127,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区上行无用户通道总功率测量值(dBm)
= {-79,-82,-127,-127,-127,-127,-127,-127,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区子帧号= 7
小区上行底噪测量值
= {21,20,21,22,20,18,19,19,19,18,19,21,20,18,18,20,21,21,22,20,20,19,19,20,20,21,21 ,20,18,18,19,20,20,20,19,21,19,21,21,22,21,20,21,20,22,23,22,22,23,22,22,21,21,20,19 ,19,21,18,19,19,20,19,20,19,20,20,20,22,20,20,19,18,19,20,21,20,19,21,19,19,21,21,20 ,21,20,19,20,20,20,18,18,19,21,21,20,21,19,20,20,20}
小区上行通道总功率测量值(dBm)
= {-55,-53,-116,-116,-116,-116,-116,-116,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
小区上行无用户通道总功率测量值(dBm)
= {-54,-51,-116,-116,-116,-116,-116,-116,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
解决方案: D+F都新开站点，未及时修改帧头偏移。

4.3.传输问题导致SIP-503 S1切换导致VoLTE掉话
问题现象：
兰州拉网测试过程中发现每次联通西固锅炉厂-3（PCI：255）向西固青少年活动中心-2（PCI：247）出现掉话，ENB给UE下发RRC connection Release，原因是Other。

查看无线环境，均无质差，具体如下图：
问题分析：
X2切换问题分析：
结合大唐基站告警进行分析，发现西固锅炉厂基站和西固青少年活动中心基站SCTP链路故障，导致无法进行X2切换。

通过故障处理，联通西固锅炉厂和西固青少年活动中心SCTP链路恢复正常，进一步验证，X2切换正常（以下是炎强平台log），现场无掉话现象，问题暂时规避：
S1切换掉话问题分析：
MME进行Trace跟踪，发现存在信令乱序问题，主要问题是MME收到源小区发送S1 ENBStatus Transfer比目标小区发送的S1 handover notify晚100ms左右，MME认为信令乱系，不回复目标小区回复S1 MMEStatus Transfer，源小区至目标小区SN倒换失败，最终endtimer超时造成无线链路释放掉话。

查看大唐基站Trace跟踪，源小区发送S1 ENB Status Transfer 比目标小区发送S1 handover notify晚58ms；基站不存在乱序问题。

怀疑源小区传输时延大于目标小区，导致MME信令乱序。

基站侧信令：目标小区未收到S1 MMEStatus Transfer，源小区（16:12:54.463）发送S1 ENB Status Transfer 后58ms目标小区才发送的（16:12:54.521）S1 handover notify，紧接着endtimer（100ms）超时，ENB主动释放承载。

（源小区侧信令）
（目标小区侧信令）
核心网信令：MME收到源小区发送S1 ENBStatus Transfer前，收到了目标小区发送的S1 handover notify（约早100ms左右），MME认为这种情况是信令乱序，所以不给目标小区回复S1 MMEStatus Transfer，导致SN倒换失败，最终造成掉话。

定位结论：基站发送顺序正常，而MME收到信令乱序，怀疑源小区传输时延较大而导致MME信令乱序。

正常S1切换信令流程：
H a n d o v e r C o m p le t io n
H a n d o v e r E x e c u t io n H a n d o v e r P r e p a r a t io n
➢ 优化措施及效果：
X2链路故障处理，掉话问题规避；传输时延定位； ➢ 经验总结
通过分析S1切换导致VoLTE 掉话问题，充分暴露了现网切换的两个问题，第一，X2链路维护需要进一步加强，提升X2切换占比；第二，定期核查传输故障，提升S1切换成功率。

第三，华为MME 对信令流程判决存在不合理性，S1 ENBStatus Transfer 是源小区发送的数据面倒换过程，而S1 handover notify 是目标小区收到UE 发送重配置完成后给MME 回复的信令面切换完成的消息，和业务面倒换属于两个独立的过程，但是华为MME 认为乱序，直接丢弃。

建议华为MME 对信令检测进行修改，不对这种情况判定为乱序。

4.4. 站内切换与modify 并发SIP-503导致视频失败
兰州视频拉网测试中，发现切换与Modify 过程并发，会触发Unkown-ENB-UE-S1AP-ID 错误，导致MME 无法识别，MME 触发ERAB 释放，最终视频未接通（503错误）：
UE从PCI为100的小区向PCI为101的小区做站内切换，与此同时EPC给源小区发送了Modify 请求，此时UE已经站内切换到目标小区，UE未能在源小区收到Modify请求，由于UE已经不再源小区，所以源小区回复EPC的modify Response消息携带Unkown-ENB-UE-S1AP-ID错误。

MME 不识别该ENB-UE-S1AP-ID,给目标小区回复E-RAB释放消息，最终视频未接通。

➢优化建议：
由于该切换为站内切换，我司在6.00.50.05版本优化了站内切换与承载建立、删除、修改过程并发的处理方式，在切换并发情况下，优先切换，在目标小区进行建立、删除、修改过程。

站间切换华为MME已经升级，在定西测试遇到过站间切换与建立QCI1并发，已经解决，具体如下：
4.5.站内切换并发导致未接通
➢炎强PCAP包信令分析
通过PCAP包信令分析如下，在时间10:41:40发起INVITE-Request ,但在时间点10:41:48终端收到网络下发的BYE消息携带的失败原因为承载资源释放。

导致一次未接通事件如下图：Reason: SIP;cause=503;text="PT: ASR: BEARER_RELEASED"
继续通过PCAP包信令分析发现在时间点10:41:48, eNB建立失败的原因为radioNetwork: unknown-eNB-ue-s1ap-id (14)
➢无线空口分析
主被叫UE占用EARFCN:38400、PCI:17的小区，在10:41:50 RSRP-104dBm，SINR5.2的时候由于切换并发导致一次未接通。

➢问题分析：
通过前台主被叫信令分析，主叫UE在10:41:40发起INVITE请求，被叫UE在8秒后才收到寻呼消息进行RRC建立，并且在10:41:48收到网络下发的INVITE请求消息，被叫在10:41:48进行站内切换（PCI 16—>PCI 17），UE未收到QCI1专载建立消息，但是后面又收到QCI1的EPS承载释放消息；查看炎强平台，MME下发激活EPS承载消息给ENB，但是ENB恢复e-Rab setup response 消息携带Unknown-eNB-ue-s1ap-id；主要是UE发生了站内切换与QCI1的承载建立并发冲突，导致被叫无法正常建立专载，最终未接通。

➢优化建议：
基站版本升级至V3版本后可解决。

5.SIP-503失败原因处理流程总结
综合以上分析，SIP 503异常消息的分析和优化流程如下，其中包含了503消息出现的场景、原因分析及对应解决方案，可有效指导503类异常SIP消息的优化处理。

在承载建立和更改
时的失败
SRVCC过程中的
失败
eNodeB上发携带异常原因的UE上下文释放请求
not-supported-QCI-value
1、s1-inter-system-handover-
triggered
2、multiple-E-RAB-ID-instances
3、unknown-enb-ue-s1ap-id
4、x2-handover-triggered
5、s1-intra-system-handover-
triggered
invalid-qos-combination
unknown-E-RAB-ID
un-specified
tx2relocoverall-expiry
interrat-redirection
radio-connection-with-ue-lost
参数配置问题
流程冲突问题
设备配合问题
维护操作行为
无线链路失败
bSRVCC不兼容问题
异常重定向
邻区优化问题
从信令平台上提取相关小区明细，核
查对应eNodeB上VOLTE开关和相关
参数配置
上海贝尔eNodeB和爱立信MME配合
问题，需要上海贝尔eNodeB增强兼
容性，爱立信MME更改e-RAB更改请
求下发机制
维护人员手动释放用户所致，属特
例，无需处理
流程冲突问题：需要设备升级解决
基站升级版本后，基站侧可识别并规
避bSRVCC切换
大唐eNB当前版本不支持分QCI的
A2/B2，版本升级后可解决此问题
从信令平台上提取相关小区明细
，排查对应小区的无线覆盖和
干扰问题
503出现阶段相关流程中的错误原因码原因定位解决方案
排查切换涉及的邻区关系配置、切换
参数配置、小区覆盖及干扰问题。