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

.VoLTE端到端质量分析SIP-503错误码原因分析研究目录1.SIP-503消息错误码分析背景32.SIP-503失败原因分类33.SIP-503流程分析53.1.无线链路失败导致掉话53.2.VoLTE走盲重定向导致掉话63.3.X2切换失败导致的掉话73.4.Sip信令丢失导致未接通ue-not-available-for-ps-service83.5.2G侧资源异常导致未接通93.6.基站弱场起呼功能导致103.7.BSRVCC切换失败103.8.VoLTE参数配置问题113.9.VoLTE流程冲突问题（1）123.10.VoLTE流程冲突问题（2）133.11.VoLTE流程冲突问题（3）143.12.VoLTE流程冲突问题（4）143.13.VoLTE流程冲突问题（5）154.SIP-503失败案例总结164.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry164.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry184.3.传输问题导致SIP-503 S1切换导致VoLTE掉话214.4.站内切换与modify并发SIP-503导致视频失败254.5.站内切换并发导致未接通265.SIP-503失败原因处理流程总结281. 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口失败原因值解决措施1eNodeB上发UE上下文释放请求 INDICATION_OF_RELEASE_OF_BEARERradio-connection-with-ue-lost接续过程中，主叫或被叫UE失步，eNodeB在检测到UE无线链路异常后发起RRC连接和UE上下文释放流程，后续UE重回4G网络发起TAU和QCI5默载建立流程。需要核查问题小区明细，排查小区覆盖、干扰问题。2 INDICATION_OF_RELEASE_OF_BEARERinterrat-redirection该问题为UE重定向到2/3G引起，发生区域均在大唐设备区，目前大唐eNodeB V620版本仍无法区分不同QCI的A2/B2（重定向、eSRVCC只能配置一个），部分区域考虑数据业务驻留比未部署eSRVCC。预计6月中旬版本升级后V3版本可解决此问题。3 INDICATION_OF_RELEASE_OF_BEARERtx2relocoverall-expiry该问题为X2切换过程中，UE由于无线环境较差无法成功接入目标小区，发起重建流程，eNB侧X2切换计时器超时发起UE上下文释放。需要无线侧核查切换涉及的源小区和目标小区明细，排查邻区关系配置、邻区切换参数配置、小区覆盖及干扰问题。4 INDICATION_OF_RELEASE_OF_BEARERue-not-available-for-ps-service该问题多见于无线环境较差，干扰严重，或者传输异常，eNB资源不足导致无法进行正常的VoLTE呼叫，针对该类问题主要通过排查覆盖（可通过开启MR确定是否弱覆盖小区针对VoLTE用户较少的站点可以通过cdl 确定，核查邻区是否缺失，掉线指标是否正常，），干扰，传输故障，基站是否拥塞等。5 INDICATION_OF_RELEASE_OF_BEARERradio resources not avialible在 VoLTE呼叫CS域过程中，VoLTE用户资源准备并修改完成的情况下，收到MGCF响应的invite 503携带的原因为“NO Circut/channel avialible”导致未接通，该问题为2g侧资源问题导致，需核查2g侧资源情况6 INDICATION_OF_RELEASE_OF_BEARERNO Circut/channel avialible在目前核心网不支持bSRVCC，在弱覆的情况下易导致未接通，我司与华为通过在弱覆盖情况下限制qci 1的建立并利用终端和ims cs Retry功能完成弱场起呼。但是这也触发invite 503，建议在核心侧剔除该类问题导致的未接通7bSRVCC不兼容引发的切换失败 INDICATION_OF_RELEASE_OF_BEARERunspecified由于目前IMS版本不支持bSRVCC切换，切换失败后终端触发CSFB流程，按集团要求5月底基站升级版本后，基站侧可识别并规避bSRVCC切换。目前我司暂不支持bSRVCC功能识别8VoLTE参数配置问题 INDICATION_OF_RELEASE_OF_BEARERnot-supported-QCI-value部分厂家未开启VOLTE功能开关导致VoLTE参数配置问题，需要从信令平台上提取相关小区明细，核查对应eNodeB上VOLTE相关参数配置。9流程冲突承载建立释放或者修改与切换并发失败 INDICATION_OF_RELEASE_OF_BEARERmultiple-E-RAB-ID-instances流程冲突： 在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值multiple-E-RAB-ID-instances，由于前次呼叫ERAB建立、释放与切换流程冲突导致专载释放失败，需要设备统一升级解决，同时MME、eNodeB需要增强处理机制（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）。10 INDICATION_OF_RELEASE_OF_BEARERs1-inter-system-handover-triggered流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值s1-inter-system-handover-triggered，在e-RAB建立时，eNodeB返回e-RAB建立失败，携带原因值unknown-eNB-ue-s1ap-id为切换与ERAB Modify过程并发引起的流程冲突导致，需要统一升级设备版本解决。（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）11 INDICATION_OF_RELEASE_OF_BEARERunknown-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_BEARERx2-handover-triggered流程冲突：在e-RAB建立或者更改时，eNodeB返回e-RAB建立或者更改失败，携带原因值x2-handover-triggered，为e-RAB建立或者更改流程和X2切换流程冲突引起，需要设备版本统一升级，规避该问题，（集团建议：站间信令冲突由EPC-MME解决，站内信令冲突又接入网解决）13 BEARER_RELEASEDradioNetwork: unknown-eNB-ue-s1ap-id流程冲突：专载建立消息，但是后面又收到QCI1的EPS承载释放消息；查看炎强平台，MME下发激活EPS承载消息给ENB，但是ENB回复erab setup response消息携带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发送了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切换信令流程： 优化措施