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

VoLTE端到端质量 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 SIP-503错误码原因分析研究目录31.SIP-503消息错误码分析背景32.SIP-503失败原因分类53.SIP-503流程分析53.1.无线链路失败导致掉话63.2.VoLTE走盲重定向导致掉话73.3.X2切换失败导致的掉话83.4.Sip信令丢失导致未接通ue-not-available-for-ps-service93.5.2G侧资源异常导致未接通103.6.基站弱场起呼功能导致103.7.BSRVCC切换失败113.8.VoLTE参数配置问题123.9.VoLTE流程冲突问题（1）133.10.VoLTE流程冲突问题（2）143.11.VoLTE流程冲突问题（3）143.12.VoLTE流程冲突问题（4）153.13.VoLTE流程冲突问题（5）164.SIP-503失败案例总结164.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry184.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry214.3.传输问题导致SIP-503S1切换导致VoLTE掉话254.4.站内切换与modify并发SIP-503导致视频失败264.5.站内切换并发导致未接通285.SIP-503失败原因处理流程总结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参数配置问题、流程冲突承载建立\释放或者修改与切换并发失败）详细情况如下表： 编号 分类 SIP503消息报错 S1口失败原因值 解决措施 1 eNodeB上发UE上下文释放请求 INDICATION_OF_RELEASE_OF_BEARER radio-connection-with-ue-lost 接续过程中，主叫或被叫UE失步，eNodeB在检测到UE无线链路异常后发起RRC连接和UE上下文释放流程，后续UE重回4G网络发起TAU和QCI5默载建立流程。需要核查问题小区明细，排查小区覆盖、干扰问题。 2 INDICATION_OF_RELEASE_OF_BEARER interrat-redirection 该问题为UE重定向到2/3G引起，发生区域均在大唐设备区，目前大唐eNodeBV620版本仍无法区分不同QCI的A2/B2（重定向、eSRVCC只能配置一个），部分区域考虑数据业务驻留比未部署eSRVCC。预计6月中旬版本升级后V3版本可解决此问题。 3 INDICATION_OF_RELEASE_OF_BEARER tx2relocoverall-expiry 该问题为X2切换过程中，UE由于无线环境较差无法成功接入目标小区，发起重建流程，eNB侧X2切换计时器超时发起UE上下文释放。需要无线侧核查切换涉及的源小区和目标小区明细，排查邻区关系配置、邻区切换参数配置、小区覆盖及干扰问题。 4 INDICATION_OF_RELEASE_OF_BEARER ue-not-available-for-ps-service 该问题多见于无线环境较差，干扰严重，或者传输异常，eNB资源不足导致无法进行正常的VoLTE呼叫，针对该类问题主要通过排查覆盖（可通过开启MR确定是否弱覆盖小区针对VoLTE用户较少的站点可以通过cdl确定，核查邻区是否缺失，掉线指标是否正常，），干扰，传输故障，基站是否拥塞等。 5 INDICATION_OF_RELEASE_OF_BEARER radioresourcesnotavialible 在VoLTE呼叫CS域过程中，VoLTE用户资源准备并修改完成的情况下，收到MGCF响应的invite503携带的原因为“NOCircut/channelavialible”导致未接通，该问题为2g侧资源问题导致，需核查2g侧资源情况 6 INDICATION_OF_RELEASE_OF_BEARER NOCircut/channelavialible 在目前核心网不支持bSRVCC，在弱覆的情况下易导致未接通，我司与华为通过在弱覆盖情况下限制qci1的建立并利用终端和imscsRetry功能完成弱场起呼。但是这也触发invite503，建议在核心侧剔除该类问题导致的未接通 7 bSRVCC不兼容引发的切换失败 INDICATION_OF_RELEASE_OF_BEARER unspecified 由于目前IMS版本不支持bSRVCC切换，切换失败后终端触发CSFB流程，按集团要求5月底基站升级版本后，基站侧可识别并规避bSRVCC切换。目前我司暂不支持bSRVCC功能识别 8 VoLTE参数配置问题 INDICATION_OF_RELEASE_OF_BEARER not-supported-QCI-value 部分厂家未开启VOLTE功能开关导致VoLTE参数配置问题，需要从信令平台上提取相关小区明细，核查对应eNodeB上VOLTE相关参数配置。 9 流程冲突承载建立\释放或者修改与切换并发失败 INDICATION_OF_RELEASE_OF_BEARER multiple-E-RAB-ID-instances 流程冲突：在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值multiple-E-RAB-ID-instances，由于前次呼叫ERAB建立、释放与切换流程冲突导致专载释放失败，需要设备统一升级解决，同时MME、eNodeB需要增强处理机制（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）。 10 INDICATION_OF_RELEASE_OF_BEARER s1-inter-system-handover-triggered 流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值s1-inter-system-handover-triggered，在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值unknown-eNB-ue-s1ap-id为切换与ERABModify过程并发引起的流程冲突导致，需要统一升级设备版本解决。（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决） 11 INDICATION_OF_RELEASE_OF_BEARER unknown-eNB-ue-s1ap-id 流程冲突：在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值unknown-eNB-ue-s1ap-id，在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值unknown-eNB-ue-s1ap-id，（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决） 12 INDICATION_OF_RELEASE_OF_BEARER x2-handover-triggered 流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值x2-handover-triggered，为e-RAB建立或者更改流程和X2切换流程冲突引起，需要设备版本统一升级，规避该问题，（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决） 13 BEARER_RELEASED radioNetwork:unknown-eNB-ue-s1ap-id 流程冲突：专载建立消息，但是后面又收到QCI1的EPS承载释放消息；查看炎强平台，MME下发激活EPS承载消息给ENB，但是ENB回复erabsetupresponse消息携带Unknown-eNB-ue-s1ap-id；主要是UE发生了站内切换与QCI1的承载建立并发冲突，导致被叫无法正常建立专载，最终未接通。（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突由接入网解决）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发送了503SIP错误码，造成呼叫失败。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发送了503SIP错误码，造成呼叫失败。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发送了503SIP错误码，造成呼叫失败。3.4.Sip信令丢失导致未接通ue-not-available-for-ps-service在VoLTE呼叫建立阶段，存在是Sip信令丢失在SGI/S1AP/UU口导致未接通，具体现象为sip信令（如invite/183sessionprogress/prack/update/180ringing/终端未发送invite200ok等）连续发送多次之后未收到响应，触发两种现象：1.PCRF通知DRA放弃本次会话，携带的错误码为“INSUFFICIENTBEARERRESOURCES”（不足的承载资源），该类问题多见于183sessionprogress/180ringing/终端未发送invite200ok消息丢失；2.SCCAS用“SIP：Status500serverinternalError”内部错误消息携带的原因为“NOResponseFromPeer”通过SCSCF告知SBC，从而触发PCRF放弃本次会话，导致VoLTE未接通触发CSFB。该类问题多见于update/prack等消息。·处理建议：该问题多见于无线环境较差，干扰严重，或者传输异常，eNB资源不知导致无法正常的进行正常的VoLTE呼叫，针对该类问题主要通过排查覆盖（可通过开启MR确定是否弱覆盖小区针对VoLTE用户较少的站点可以通过cdl确定，核查邻区是否缺失，掉线指标是否正常），干扰，传输故障，基站是否拥塞等。·信令流程说明：在VoLTE呼叫建立阶段，主叫SBC连续下发四次180Ringing，未收到被叫响应的invite200ok，或连续多下发183sessionprogress触发PCRF通知DRA放弃本次会话，携带的错误码为“INSUFFICIENTBEARERRESOURCES”（不足的承载资源）。在VoLTE呼叫建立阶段，主叫SBC连续下发UPDATE未收到响应导致sccas定时器超时（一般设置为6s）SCCAS用“SIP：Status500serverinternalError”内部错误消息携带的原因为“NOResponseFromPeer”通过SCSCF告知SBC，从而触发PCRF放弃本次会话，导致VoLTE未接通触发CSFB。详情如下：3.5.2G侧资源异常导致未接通在VoLTE呼叫CS域过程中，VoLTE用户资源准备并修改完成的情况下，收到MGCF响应的invite503携带的原因为“NOCircut/channelavialible”导致未接通。·处理建议：该问题为2g侧资源问题导致，需核查2g侧资源情况。·信令流程说明：在VoLTE呼叫CS域过程中，VoLTE用户完成update流程后收到Mgcf的Mgcf响应的invite503携带的原因为“NOCircut/channelavialible”，释放本次会话。3.6.基站弱场起呼功能导致在目前核心网不支持bSRVCC，在弱覆的情况下易导致未接通，我司与华为通过在弱覆盖情况下限制qci1的建立并利用终端和imscsRetry功能完成弱场起呼。但是这也触发invite503。·处理建议：建议在核心侧剔除该类问题导致的未接通。在分析该类s1错误码为“radioresourcesnotavialible”，核查该站点是否开启弱场起呼功能。·信令流程说明：SBC收到主叫上发的invite消息后，通知eNB建立无线承载时收到核心eNB响应的ERABsetuprespone携带原因为“radioresourcesnotavialible”触发invite503，终端收到后触发CSFB，从而避免了bSRVCC。详情如下：3.7.BSRVCC切换失败bSRVCC切换失败，MME下发的切换准备失败消息“HandoverPreparationFailure”中，携带原因值：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，eNodeBVOLTE业务相关参数配置存在问题。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-RABID=7的E-RAB承载，之后新的呼叫开始，建立e-RABID=7的e-RAB承载，因为e-NodeB发现e-RABID重复，就回复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。·处理建议：为切换与ERABModify过程并发引起的流程冲突导致，需要统一升级设备版本解决。·信令流程说明：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重定位完成定时器超时UEContextReleaseRequestCause:radioNetwork(tx2relocoverall-expiry)。·无线空口分析在南北滨河路遍历拉网测试过程，我们在华为区域测试过中出现掉话事件，通过无线测试分析，失败原因如下图：SIP;cause=503;text='PO:RAR:INDICATION_OF_RELEASE_OF_BEARER'在的时间点15:15:37被叫终端收到网络侧下发切换的RRCConnectionReconfiguration消息后终端未回复RRCConnectionReconfigurationComplete,由于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小区，终端发起SIPINVITE会话呼叫，服务器响应并回复终端SIPINVITE100Trying，网络侧发起QCI=1，EPS承载为7建立的语音业务，无线环境良好CRC-RSRC=-90dbm，CRC-SINR=12，在11:44:22由于UE上行PUSCH功率较大，上行失步导致主叫掉话。通过主被叫信令分析，主被叫UE接通后占用崔家大滩西侧微站LTE-1小区（EARFCN:37900、PCI:390）后，无线覆盖较好，但是UE上行的PUSCHTxPower却增大至22，上行失步2s后11:44:21重选至宏润建设集团LTE-8小区(EARFCN:37900、PCI:7）进行RRC重建请求，重建请求拒绝后，UE收到网络侧下发的BYERequest消息，通过后台网管提取该小区子帧干扰情况，发现崔家大滩西侧微站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-503S1切换导致VoLTE掉话问题现象：兰州拉网测试过程中发现每次联通西固锅炉厂-3（PCI：255）向西固青少年活动中心-2（PCI：247）出现掉话，ENB给UE下发RRCconnectionRelease，原因是Other。查看无线环境，均无质差，具体如下图：问题分析：X2切换问题分析：结合大唐基站告警进行分析，发现西固锅炉厂基站和西固青少年活动中心基站SCTP链路故障，导致无法进行X2切换。通过故障处理，联通西固锅炉厂和西固青少年活动中心SCTP链路恢复正常，进一步验证，X2切换正常（以下是炎强平台log），现场无掉话现象，问题暂时规避：S1切换掉话问题分析：MME进行Trace跟踪，发现存在信令乱序问题，主要问题是MME收到源小区发送S1ENBStatusTransfer比目标小区发送的S1handovernotify晚100ms左右，MME认为信令乱系，不回复目标小区回复S1MMEStatusTransfer，源小区至目标小区SN倒换失败，最终endtimer超时造成无线链路释放掉话。查看大唐基站Trace跟踪，源小区发送S1ENBStatusTransfer比目标小区发送S1handovernotify晚58ms；基站不存在乱序问题。怀疑源小区传输时延大于目标小区，导致MME信令乱序。基站侧信令：目标小区未收到S1MMEStatusTransfer，源小区（16:12:54.463）发送S1ENBStatusTransfer后58ms目标小区才发送的（16:12:54.521）S1handovernotify，紧接着endtimer（100ms）超时，ENB主动释放承载。（源小区侧信令）（目标小区侧信令）核心网信令：MME收到源小区发送S1ENBStatusTransfer前，收到了目标小区发送的S1handovernotify（约早100ms左右），MME认为这种情况是信令乱序，所以不给目标小区回复S1MMEStatusTransfer，导致SN倒换失败，最终造成掉话。定位结论：基站发送顺序正常，而MME收到信令乱序，怀疑源小区传输时延较大而导致MME信令乱序。正常S1切换信令流程：·优化措施及效果：X2链路故障处理，掉话问题规避；传输时延定位；·经验总结通过分析S1切换导致VoLTE掉话问题，充分暴露了现网切换的两个问题，第一，X2链路维护需要进一步加强，提升X2切换占比；第二，定期核查传输故障，提升S1切换成功率。第三，华为MME对信令流程判决存在不合理性，S1ENBStatusTransfer是源小区发送的数据面倒换过程，而S1handovernotify是目标小区收到UE发送重配置完成后给MME回复的信令面切换完成的消息，和业务面倒换属于两个独立的过程，但是华为MME认为乱序，直接丢弃。建议华为MME对信令检测进行修改，不对这种情况判定为乱序。4.4.站内切换与modify并发SIP-503导致视频失败兰州视频拉网测试中，发现切换与Modify过程并发，会触发Unkown-ENB-UE-S1AP-ID错误，导致MME无法识别，MME触发ERAB释放，最终视频未接通（503错误）：INCLUDEPICTURE"cid:image004.png@01D1A133.D946E0C0"\*MERGEFORMATUE从PCI为100的小区向PCI为101的小区做站内切换，与此同时EPC给源小区发送了Modify请求，此时UE已经站内切换到目标小区，UE未能在源小区收到Modify请求，由于UE已经不再源小区，所以源小区回复EPC的modifyResponse消息携带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:50RSRP-104dBm，SINR5.2的时候由于切换并发导致一次未接通。·问题分析：通过前台主被叫信令分析，主叫UE在10:41:40发起INVITE请求，被叫UE在8秒后才收到寻呼消息进行RRC建立，并且在10:41:48收到网络下发的INVITE请求消息，被叫在10:41:48进行站内切换（PCI16—>PCI17），UE未收到QCI1专载建立消息，但是后面又收到QCI1的EPS承载释放消息；查看炎强平台，MME下发激活EPS承载消息给ENB，但是ENB恢复e-Rabsetupresponse消息携带Unknown-eNB-ue-s1ap-id；主要是UE发生了站内切换与QCI1的承载建立并发冲突，导致被叫无法正常建立专载，最终未接通。·优化建议：基站版本升级至V3版本后可解决。5.SIP-503失败原因处理流程总结综合以上分析，SIP503异常消息的分析和优化流程如下，其中包含了503消息出现的场景、原因分析及对应解决方案，可有效指导503类异常SIP消息的优化处理。第1页共27页_1526761064.vsdLegendpacketdatapacketdataULallocation2.MeasurementReports3.HOdecision5.HandoverRequest4.7.HandoverRequestAckHandoverRequired6.AdmissionControl11.MMEStatusTransfer8.HandoverCommandDataForwarding9.RRCConn.Reconf.incl.mobilityControlinformationDLallocationDataForwarding14.RRCConn.Reconf.Complete20.UEContextRelease15.PathSwitchRequestUESourceeNBTargeteNBServingGatewayDetachfromoldcellandsynchronizetonewcellDeliverbufferedandintransitpacketstotargeteNBBufferpacketsfromSourceeNB12.Synchronisation13.ULallocation+TAforUEpacketdatapacketdataL3signallingL1/L2signallingUserData1.MeasurementControl19.PathSwitchRequestAck21.ReleaseResourcesHandoverCompletionHandoverExecutionHandoverPreparationMME0.AreaRestrictionProvided16.UserPlaneupdaterequest18.UserPlaneupdateresponse17.SwitchDLpatheNBStatusTransfer10.EndMarkerEndMarkerpacketdata