VoLTE端到端业务质量分析 - 图文

更新时间:2024-03-27 21:09:01 阅读量: 综合文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

VoLTE端到端质量分析

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

目录

1. 2. 3.

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.3. 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 页 共 27 页

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-connINDICATION_1 OF_RELEASE_h-ue-lost OF_BEARER eNodeB 上发UEINDICATION_2 上下文OF_RELEASE_释放请OF_BEARER 求 tx2relocovINDICATION_3 OF_RELEASE_ry 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口失败解决措施 第 2 页 共 27 页

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

INDICATION_

4

OF_RELEASE_OF_BEARER

-ps-servic

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

e

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

INDICATION_

5

OF_RELEASE_OF_BEARER

INDICATION_

6

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_

9

流程冲

OF_RELEASE_

突承载

OF_BEARER

建立\\释放或者修改与10

切换并发失败

INDICATION_OF_RELEASE_OF_BEARER

s1-inter-system-handover-triggered

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参数配置问题,需要从

d

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

unspecifie

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

nnel avialible

Retry功能完成弱场起呼。但是这也触发invite 503,建议在核心侧剔除该类问题导致的未接通

not avialible NO 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用户较少的

第 3 页 共 27 页

unknown-eN

11

INDICATION_

B-ue-s1ap-OF_RELEASE_

id

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

12

INDICATION_

r-triggere

OF_RELEASE_

d

OF_BEARER

冲突又接入网解决)

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

radioNetwo

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

1

BEARER_RELE

3

ASED

B-ue-s1ap-法正常建立专载,最终未接通。(集团建议:站间信令冲突由EPC-MME

id

解决,站内信令冲突由接入网解决)

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. 无线链路失败导致掉话 在呼叫建立阶段,eNodeBradio-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错误码,造成呼叫失败。

第 4 页 共 27 页

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。

第 5 页 共 27 页

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。

第 11 页 共 27 页

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请求,回复了失败响应。

第 12 页 共 27 页

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请求,回复了失败响应。

第 13 页 共 27 页

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请求,回复了失败响应。

第 14 页 共 27 页

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=\

继续通过PCAP包信令分析发现在时间点15:15:49, eNB主动进行拆链释放原因为X2重定位

完成定时器超时UEContextReleaseRequest Cause: radioNetwork (tx2relocoverall-expiry)。

? 无线空口分析

在南北滨河路遍历拉网测试过程,我们在华为区域测试过中出现掉话事件,通过无线测试分析,失败原因如下图:

第 15 页 共 27 页

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终端上

第 16 页 共 27 页

发Request-ACK表示会话已经接通,但在时间点15:44:19终端收到网络下发的BYE消息携带的失败原因为承载资源释放。导致一次未接通事件如下图:

(Reason: SIP;cause=503;text=\

继续通过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功率较大,上行失步导致主叫掉话。

第 17 页 共 27 页

通过主被叫信令分析,主被叫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)

第 18 页 共 27 页

= {-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。查看无线环境,均无质差,具体如下图:

第 19 页 共 27 页

问题分析: X2切换问题分析:

结合大唐基站告警进行分析,发现西固锅炉厂基站和西固青少年活动中心基站SCTP链路故障,导致无法进行X2切换。

通过故障处理,联通西固锅炉厂和西固青少年活动中心SCTP链路恢复正常,进一步验证,X2切换正常(以下是炎强平台log),现场无掉话现象,问题暂时规避:

第 20 页 共 27 页

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主动释放承载。

(源小区侧信令)

第 21 页 共 27 页

(目标小区侧信令)

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

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

正常S1切换信令流程:

第 22 页 共 27 页

UESource eNBTarget eNBMMEServing Gateway0.Area Restriction Provided1.Measurement Controlpacket datapacket dataLegendL3 signallingL1/L2 3.HO decision4.Handover Required5. Handover Request6.DL allocation9. RRC Conn. Reconf. incl. mobilityControlinformationDetach from old cell and synchronize to new cellDeliver buffered and in transit packets to target eNB10.eNB Status TransferData Forwarding11. MME Status TransferData ForwardingBuffer packets from Source eNBAdmission Control User Datasignalling UL allocation2.Measurement Reports7. Handover Request Ack8. Handover Command12.13.14.SynchronisationUL allocation + TA for UERRC Conn. Reconf. Completepacket datapacket data15.Path Switch Request16.User Plane update requestEnd Markerpacket dataEnd Marker19.Path Switch Request Ack20. UE Context Release21.Release Resources18.User Plane update responseHandover Completion17.Switch DL pathHandover ExecutionHandover Preparation ? 优化措施及效果:

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错误):

第 23 页 共 27 页

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=\

第 24 页 共 27 页

继续通过PCAP包信令分析发现在时间点10:41:48, eNB建立失败的原因为radioNetwork: unknown-eNB-ue-s1ap-id (14)

? 无线空口分析

主被叫UE占用EARFCN:38400、PCI:17的小区,在10:41:50 RSRP-104dBm,SINR5.2的时候由于切换并发导致一次未接通。

第 25 页 共 27 页

? 问题分析:

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

第 26 页 共 27 页

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

本文来源:https://www.bwwdw.com/article/4l0r.html

Top