SIP-503失败案例总结
来源：优橙教育 时间：2021-02-25 12:02:47
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后，在二次验证中再无掉话的问题。
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都新开站点，未及时修改帧头偏移。
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切换信令流程：
Ø 优化措施及效果：
X2链路故障处理，掉话问题规避；传输时延定位；
Ø 经验总结
通过分析S1切换导致VoLTE掉话问题，充分暴露了现网切换的两个问题，第一，X2链路维护需要进一步加强，提升X2切换占比；第二，定期核查传输故障，提升S1切换成功率。
第三，华为MME对信令流程判决存在不合理性，S1 ENBStatus Transfer是源小区发送的数据面倒换过程，而S1 handover notify是目标小区收到UE发送重配置完成后给MME回复的信令面切换完成的消息，和业务面倒换属于两个独立的过程，但是华为MME认为乱序，直接丢弃。建议华为MME对信令检测进行修改，不对这种情况判定为乱序。
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并发，已经解决，具体如下：
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版本后可解决。
