你的位置：首页 > IT圈 > SIP-503错误码原因分析研究VoLTE端到端业务质量分析

SIP-503错误码原因分析研究VoLTE端到端业务质量分析

IT圈 admin 2024-07-16 67浏览 0评论

2024年7月16日发(作者：童俊爽)

VoLTE端到端质量分析

SIP-503错误码原因分析研究

SIP-503消息错误码分析背景 ........................................................................................................... 2

SIP-503失败原因分类 ....................................................................................................................... 2

SIP-503流程分析............................................................................................................................... 4

无线链路失败导致掉话 ............................................................................................................. 4

VoLTE走盲重定向导致掉话 ...................................................................................................... 5

X2切换失败导致的掉话 ............................................................................................................ 5

Sip信令丢失导致未接通ue-not-available-for-ps-service ........................................... 6

2G侧资源异常导致未接通 ........................................................................................................ 8

基站弱场起呼功能导致 ............................................................................................................. 8

BSRVCC切换失败 ........................................................................................................................ 9

VoLTE参数配置问题 ................................................................................................................ 10

VoLTE流程冲突问题（1） ...................................................................................................... 11

VoLTE流程冲突问题（2） ...................................................................................................... 12

VoLTE流程冲突问题（3） ...................................................................................................... 13

VoLTE流程冲突问题（4） ...................................................................................................... 13

VoLTE流程冲突问题（5） ...................................................................................................... 14

3.1.

3.2.

3.4.

3.5.

3.6.

3.7.

3.8.

3.9.

3.10.

3.11.

3.12.

3.13.

4. SIP-503失败案例总结 ..................................................................................................................... 15

邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry ................................... 15

干扰问题导致SIP-503失败原因：tx2relocoverall-expiry ........................................... 16

传输问题导致SIP-503 S1切换导致VoLTE掉话 ................................................................. 19

站内切换与modify并发SIP-503导致视频失败 ................................................................. 23

站内切换并发导致未接通 ....................................................................................................... 24

4.1.

4.2.

4.3.

4.4.

4.5.

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参数配置问题、流程冲突承载建立

释放或者修改与切换并发失败）详细情况如下表：

编

分类

号

radio-conn

INDICATION_

OF_RELEASE_

h-ue-lost

OF_BEARER

eNodeB

上发UE

INDICATION_

2 上下文

OF_RELEASE_

释放请

OF_BEARER

求

tx2relocov

INDICATION_

OF_RELEASE_

OF_BEARER 关系配置、邻区切换参数配置、小区覆盖及干扰问题。

erall-expi

放。需要无线侧核查切换涉及的源小区和目标小区明细，排查邻区

小区，发起重建流程，eNB侧X2切换计时器超时发起UE上下文释

该问题为X2切换过程中，UE由于无线环境较差无法成功接入目标

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

edirection eSRVCC只能配置一个），部分区域考虑数据业务驻留比未部署

interrat-r大唐eNodeB V620版本仍无法区分不同QCI的A2/B2（重定向、

该问题为UE重定向到2/3G引起，发生区域均在大唐设备区，目前

覆盖、干扰问题。

ection-wit

起TAU和QCI5默载建立流程。需要核查问题小区明细，排查小区

常后发起RRC连接和UE上下文释放流程，后续UE重回4G网络发

报错原因值

接续过程中，主叫或被叫UE失步，eNodeB在检测到UE无线链路异

SIP503消息S1口失败

解决措施

该问题多见于无线环境较差，干扰严重，或者传输异常，eNB资源

INDICATION_

OF_RELEASE_

OF_BEARER

-ps-servic

站点可以通过cdl 确定，核查邻区是否缺失，掉线指标是否正常，），

干扰，传输故障，基站是否拥塞等。

INDICATION_

OF_RELEASE_

OF_BEARER

INDICATION_

OF_RELEASE_

OF_BEARER

bSRVCC

不兼容

INDICATION_

7 引发的

OF_RELEASE_

切换失

OF_BEARER

败

VoLTE参

INDICATION_

8 数配置

OF_RELEASE_

问题

OF_BEARER

流程冲突：在e-RAB建立时，eNodeB返回e-RAB建立失败，携带

multiple-E

INDICATION_

流程冲

OF_RELEASE_

突承载

OF_BEARER

建立释

放或者

修改与

切换并

发失败

INDICATION_

OF_RELEASE_

OF_BEARER

s1-inter-s

ystem-hand

over-trigg

ered

EPC-MME解决，站内信令冲突又接入网解决）。

流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者

更改失败，携带原因值s1-inter-system-handover-triggered，在

e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值

unknown-eNB-ue-s1ap-id为切换与ERAB Modify过程并发引起的流

程冲突导致，需要统一升级设备版本解决。（集团建议：站间信令

冲突由EPC-MME解决，站内信令冲突又接入网解决）

stances 同时MME、eNodeB需要增强处理机制（集团建议：站间信令冲突由

-RAB-ID-in释放与切换流程冲突导致专载释放失败，需要设备统一升级解决，

原因值multiple-E-RAB-ID-instances，由于前次呼叫ERAB建立、

lue 数配置。

ted-QCI-va信令平台上提取相关小区明细，核查对应eNodeB上VOLTE相关参

not-suppor部分厂家未开启VOLTE功能开关导致VoLTE参数配置问题，需要从

bSRVCC切换。目前我司暂不支持bSRVCC功能识别

unspecifie

流程，按集团要求5月底基站升级版本后，基站侧可识别并规避

由于目前IMS版本不支持bSRVCC切换，切换失败后终端触发CSFB

nnel

avialible

Retry功能完成弱场起呼。但是这也触发invite 503，建议在核心

侧剔除该类问题导致的未接通

not

avialible

Circut/cha

Circut/channel avialible”导致未接通，该问题为2g侧资源问

题导致，需核查2g侧资源情况

在目前核心网不支持bSRVCC，在弱覆的情况下易导致未接通，我司

与华为通过在弱覆盖情况下限制qci 1的建立并利用终端和ims cs

radio

resources

在 VoLTE呼叫CS域过程中，VoLTE用户资源准备并修改完成的情

况下，收到MGCF响应的invite 503携带的原因为“NO

ue-not-ava

不足导致无法进行正常的VoLTE呼叫，针对该类问题主要通过排查

ilable-for

覆盖（可通过开启MR确定是否弱覆盖小区针对VoLTE用户较少的

unknown-eN

INDICATION_

B-ue-s1ap-

OF_RELEASE_

OF_BEARER

流程冲突：在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原

因值unknown-eNB-ue-s1ap-id，在e-RAB建立时，eNodeB返回e-RAB

建立失败，携带原因值unknown-eNB-ue-s1ap-id，（集团建议：站

间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）

流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者

x2-handove

INDICATION_

r-triggere

OF_RELEASE_

OF_BEARER

冲突又接入网解决）

流程冲突：专载建立消息，但是后面又收到QCI1的EPS承载释放

radioNetwo

消息；查看炎强平台，MME下发激活EPS承载消息给ENB，但是ENB

BEARER_RELE

ASED B-ue-s1ap-

法正常建立专载，最终未接通。（集团建议：站间信令冲突由EPC-MME

解决，站内信令冲突由接入网解决）

unknown-eN

要是UE发生了站内切换与QCI1的承载建立并发冲突，导致被叫无

rk:

回复erab setup response消息携带Unknown-eNB-ue-s1ap-id；主

避该问题，（集团建议：站间信令冲突由EPC-MME解决，站内信令

者更改流程和X2切换流程冲突引起，需要设备版本统一升级，规

更改失败，携带原因值x2-handover-triggered，为e-RAB建立或

3. SIP-503流程分析

3.1. 无线链路失败导致掉话

在呼叫建立阶段，eNodeB

radio-connection-with-ue-lost。

➢ 处理建议：

接续过程中，主叫或被叫UE失步，eNodeB在检测到UE无线链路异常后发起RRC连接和UE上

下文释放流程，后续UE重回4G网络发起TAU和QCI5默载建立流程。需要核查问题小区明细，排

查小区覆盖、干扰问题。

➢ 信令流程说明：

在呼叫建立阶段，eNodeB上发UEContextReleaseRequest ,携带原因值

上发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，。

➢ 处理建议：

为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，源小区（）发送S1 ENB Status Transfer

后58ms目标小区才发送的（）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.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释放消息，最终视频未接通。

➢ 优化建议：

由于该切换为站内切换，我司在版本优化了站内切换与承载建立、删除、修改过程并发的处

理方式，在切换并发情况下，优先切换，在目标小区进行建立、删除、修改过程。

站间切换华为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。

➢ 问题分析：

通过前台主被叫信令分析，主叫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消息的优化处理。