VoLTE异常问题分析_呼叫建立时发生网络侧多次异常下发Modify EPS Bearer指令导致时延过长

Volte用户做被叫主叫为volte、CS用户状态不一致问题分析案例1.问题描述近日接到某volte 用户投诉，手机 volte 业务自开通后，无条件前转业务使用异常，主叫是 volte 用户拨打能够正常转接，主叫为非volte 用户拨打则仍是本机接听，在手机上取消无条件前转业务，或手机关闭volte 功能后问题仍存在。

2.问题分析接到用户投诉后，现场人员进行模拟测试复现了该场景，在U31 网管上查询该用户的签约数据，发现用户确实签约无条件前转业务，且该业务处于激活状态，即手机上取消前转业务操作失败。

将用户问题手机开关机、反复取消无条件前转业务，网管仍处于激活状态，IMS信令跟踪未跟到任何取消激活的信令，将手机卡换至测试手机终端重新取消，无条件前转业务成功取消，判断是用户终端问题导致Ut 业务异常，所以手机取消呼转业务失败。

继续跟踪用户处于 volte状态CS用户呼叫时不能前转的问题，经现场测试及后台 IMS 网管信令跟踪，发现 volte用户拨打时网管上能跟踪到呼叫信令并成功触发前转，CS用户呼叫时IMS网管跟踪不到信令，被叫用户以 CSFB方式接通，未触发前转业务。

（应用户要求，）由业支暂时取消该问题号码的volte 业务，并继续进行遍历场景测试，发现该号码主叫业务正常，被叫时仍然存在问题。

CS用户拨打能够正常接通，volte用户拨打则呼叫失败，主叫侧拨打后直接中断，被叫终端无响应。

信令跟踪发现，主叫 volte用户呼叫问题时，主叫 SCSCFBU DNS后被叫号码指向IMS 域，主叫侧SCSC畸invite消息转发至被叫ICSCF被叫业务 AS响应0x26037-用户未开户。

M ，,3乏B汗珈，■■一朝 口!❾* ■■, ―WMTIH1热刖加曲”『M12gE 工期忖硼如睥2 州*1。

W +叵画画3吐山洞播5MM*,B-| L 叫上期:* '对———tgmEH Mn* M 也 4prrfw*jrjp 广― I 匕曲.商11心1，川工********，对mwillfijn 血晶小喈则gKM 如式EMdl.嘘H 电曲《於f*"।f 鼾111匚的工的141的；囚时由升力在怛IL |.| 小工匕力iHhrfe 场础蛔w1ut鼻出时 LPCil 心 馀F心上冷即网K硼10 iflpjah .'i E” 4r £才 K 中‘丽解 R* J%. 5 ： mi ：讣J ；17 DL2EB?5EI> CSCF 1E-]414^ DM9 XI ■山 Fqg 1M RTF T?D1B723] 29111 翦 GEZI Ei 工$g ，，d*=产，1,・=至 *7= =1a- ian^ufir ¥；”才：♦ kiCA2£g3的. 谢H.—L OhE•皿加-叫 4Ilf.风金也M-J.或 官阑崎加维*13鸟2!£:第11*体小即TM «HE 国-- W收现咽工 HMM 媾 鼾宛1MM 州川忸1时七口■ ! ,i ■ ■,■ •■,■ -it- -1 ；m MT —加g 注:口出. “1।湖也£lkW £TE9ft*PliTKij'j^Cn的明“盛6 ，L 可t 三二％叫曲加工：何用,飞歌 耳料W4,用｛号转21 曜眩；CJQ。

Volte故障分析手册1. 前言随着通信技术的不断发展，Voice over LTE (VoLTE)已成为现代通信中普遍采用的标准。

然而，由于复杂的网络结构和通信设备的多样性，VoLTE服务在一些情况下可能会遇到故障。

本文将介绍一些常见的VoLTE故障及其分析方法，以帮助读者更好地解决和排查故障。

2. 故障一：通话质量差2.1 故障描述在VoLTE通话过程中，用户可能会遇到通话质量差的问题，如杂音、断续和声音不清晰等。

2.2 分析方法a) 检查网络信号强度：VoLTE通话对网络信号强度要求较高，低信号强度可能导致通话质量差。

使用信号测试工具检查信号强度并与基准值进行比较。

b) 检查网络负载：高网络负载可能会降低VoLTE通话质量。

使用网络分析工具检查网络负载情况，确保网络资源足够用于VoLTE通话。

c) 检查设备兼容性：某些设备可能不兼容VoLTE技术，导致通话质量下降。

确保设备支持VoLTE功能并进行升级或更换。

d) 检查网络配置：网络配置错误可能导致VoLTE通话质量差。

检查各个网络节点的配置是否正确，并进行必要的修改。

3. 故障二：呼叫无法接通3.1 故障描述用户在进行VoLTE呼叫时，可能会遇到呼叫无法接通的问题。

无法接通的呼叫可能包括呼叫失败、长时间等待或无法连接对方等。

3.2 分析方法a) 检查设备设置：确保用户设备的呼叫设置正确，如是否开启飞行模式、是否设置了呼叫转移等。

b) 检查呼叫号码：检查呼叫的号码是否正确，可能是输入错误导致无法接通呼叫。

c) 检查网络状态：当网络状态不稳定或网络连接中断时，呼叫可能无法接通。

使用网络分析工具检查网络状态，并进行必要的修复。

d) 检查网络中断：网络中断可能是导致呼叫无法接通的原因之一。

检查网络设备和线路是否正常工作，确保网络连接畅通。

e) 检查呼叫服务器状态：呼叫服务器故障可能导致呼叫无法接通。

检查呼叫服务器的状态，并与运营商联系以修复问题。

终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。

终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。

被叫上发的183里不携带SDP信息，正常的是会携带Session Description Protocol 信息的，导致SBC不发起承载建立。

主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。

1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMedia Attribute (a): curr:qos local sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local sendrecv| | Media Attribute (a): curr:qos remote none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote none| | Media Attribute (a): des:qos mandatory local sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv | | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 但在终端返回的183和update 200ok消息中，终端没有完成承载预留Media Attribute (a): curr:qos local none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local none| | Media Attribute (a): curr:qos remote sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote sendrecv| | Media Attribute (a): des:qos mandatory local sendrecv| | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv| | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。

VoLTE无法寻呼案例分析一、问题现象：在进行VoLTE测试时，在做UE主被叫测试时，发现UE处在idle状态下，无法被寻呼到。

二、问题分析1.基站故障问题：对测试基站进行告警查看，无任何告警，查询历史告警，也无异常。

在该基站下作数据业务，也为发行异常，排除基站故障引起的可能性；2.核心网设置问题：对核心网侧发端进行抓包，确定Paging已经发出。

3.参数设置问题：在基站侧，确定是否收到Paging包。

若收不到，那么，就要排查传输。

若收到，就是eNodeB本身的问题。

4.而确定基站是否收到Paging方法有2种。

可以上前台用Wireshark抓包，也可以后台通过信令确定是否收到Paging消息。

使用后台系统工具-----统一信令跟踪，对Paging进行跟踪。

因此，确定，基站自身收到核心网发来的Paging消息，问题排查，关注基站本身。

三、优化方案1.终端UE收到的寻呼消息中如果带有UE ID列表，终端需要用自己的UE ID来跟寻呼消息中携带的UE ID一一进行匹配，以判断此寻呼消息是否是在呼叫自己。

同时，在寻呼消息中如果所指示Paging ID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果Paging ID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此种情况下终端需要重新做一次附着(Attach)过程。

2.从传输信道角度来看，最终由PDSCH下行共享物理信道承载寻呼信息。

在接收寻呼消息之前，终端UE需要先去监听PDCCH物理信道，然后根据PDCCH物理信道上是否有携带P-RNTI，来判断网络在本次寻呼周期是否有发寻呼消息给自己。

3.终端在一个DRX的周期内，可以只在相应的寻呼无线帧(PF)上的寻呼时刻(PO)先去监听PDCCH上是否携带有P—RNTI，进而去判断相应的PDSCH上是否有承载寻呼消息。

如果在PDCCH上携带有P—RNTI，就按照PDCCH上指示的PDSCH的参数去接收PDSCH上的数据；如果终端在PDCCH上未解析出P—RNTI，则无需再去接收PDSCH物理信道，就可以依照DRX周期进入休眠。

VOLTE呼叫失败分析指导书文档名称文档密级VoLTE呼叫失败分析指导书2021-1-19华为保密信息,未经授权禁止扩散第1页, 共11页1 1.1文档名称文档密级VoLTE整体构架网元及组网方式华为VoLTE解决方案的典型组网如图1所示。

通过在现有的CS网络上叠加部署IMS 网络和LTE网络，提供端到端的QoS保障，为终端用户提供高质量的语音、视频呼叫和更为丰富的数据业务，从而帮助运营商从2G/3G网络逐步演进到LTE网络，完成纯语音到丰富语音的转型。

终端用户可以通过CSFB、Single Radio、Dual Radio等多种LTE终端设备，在LTE 网络、2G/3G网络下接入。

当用户移出LTE信号区域时，系统可以将呼叫平滑切换到2G/3G网络。

除此之外，方案中还提供了统一的业务发放、网络管理、计费等功能。

2021-1-19华为保密信息,未经授权禁止扩散第2页, 共11页文档名称图1 华为VoLTE解决方案网络架构文档密级? 运营支撑层运营支撑层主要提供网管、签约数据存放、Web Portal统一操作、计费、设备管理等功能，由EMS、SPG、CCF、DM Server等功能实体组成。

? 业务层业务层主要由各种不同的应用服务器与资源服务器组成，提供各种业务（如融合Centrex、会议、IP短消息等）及业务能力（传统智能触发，锚定等）。

? 核心层核心层分为如下3个部分：IMS域、CS域和用户数据库。

1)IMS域各网元主要完成LTE用户注册、鉴权、会话路径控制、业务触发、路由选择、资源控制、域间互通、接入资源控制等功能。

2)CS域各网元主要实现LTE用户在2G/3G网络下的移动性管理和基本语音业务，包括注册、鉴权、锚定、传统智能、切换、CS语音回落等功能。

3)用户数据库按照部署方式，可分为融合HLR/HSS和分离HLR/HSS： a)融合HLR/HSS具有USCDB、HLR、IMS-HSS、SAE-HSS、DNS/ENUM等网络功能实体的功能。

VPN业务导致Volte呼叫异常案例XXXX年XX月目录VPN业务引起Volte呼叫异常案例 (3)一、问题描述 (3)一、分析过程 (4)二、解决措施 (9)三、经验总结 (11)VPN业务引起Volte呼叫异常案例XX【摘要】语音通话在日常生活、工作中仍是不可或缺的部分，语音通话质量仍是用户对电信网络感知满意度的重要组成部分。

近期突然出现较多用户反应主被叫无法正常接入，严重影响使用感知。

通过分析发现主要是由于用户同时订购了Volte业务、VPN虚拟网业务，用户在注册时出现异常，用户VPN的数据缺失导致无法正常订阅注册，导致用户主被叫无法正常接入。

针对用户无法主被叫的问题通常先进行现场测试、话单分析、信令分析等，先确认无线侧信号无问题，然后再协调核心网侧进行数据排查，导致问题分析处理周期较长，影响用户的使用体验。

本文通过对该类问题处理、分析过程进行总结，建议对该类问题用户采用核心网与无线侧同步进行核查分析的方法，优化处理流程，缩短问题处理周期，提升用户使用感知。

【关键字】vpn、虚拟网、volte【业务类别】数据问题、优化分析、流程问题一、问题描述近日综调、客服等多渠道接收到用户手机开通volte无法接打电话的情况。

联系用户，进行现场测试分析，发现现场信号良好，测试手机及其他终端均能正常呼叫，仅投诉用户手机确实出现无法接打电话的情况，机卡交换测试发现用户手机正常，用户手机卡问题导致无法正常使用，且用户表示手机卡已经更换了，出现不能正常使用的情况后，用户已经更换过手机卡，但是仍然不能正常使用。

二、 分析过程2.1现场测试在接收到用户申告后，测试人员根据用户预留号码跟用户沟通，上门测试现场信号强度。

通过对现场信号进行测试。

测试结果如下：根据测试结果发现现场无线信号良好，volte 通话也正常。

但在验证用户手机时发现用户手机确实无法正常拨打电话（可正常进行数据业务，网页浏览、即时通信、视频观看均正常）。

幽灵对话主叫已经取消，被叫却能接通！被叫在和谁通话？呼叫概述：场景为VoLTE呼叫VoLTE。

被叫183后上行失步，经历消息重传和RRC重配后，MTAS判断呼叫建立超时，于是通知主叫媒体改路，并发Cancel给被叫。

被叫侧在下发取消(Cancel)后，上行收到了回铃(180 Ringing)和摘机(200OK for invite)，于是MTAS 应答接通(ACK)并立即挂机(BYE)。

终端上行回应200OK for bye但发送失败，于是最后又经历了掉话(ASR)。

VoLTE呼叫失败后，网络侧发起CS Retry，MGCF回复480错误（非SRLTE终端）。

此时主叫听完放音后发的取消（Cancel）也送达被叫侧，经多次重发无法下行送达。

被叫侧的遭遇包括：1.因下行失步/RRC重建，导致呼叫建立超时2.因在AS取消时“回铃+摘机”，所以能够“接通”，AS回复“接通+挂机”3.因不是SRLTE终端，CS Retry失败（480）4.因“无线连接丢失”，触发一次掉话（ASR）5.因“空口流程失败”，导致业务请求被拒绝呼叫过程：主叫侧：主叫呼叫入局，SBC通过PCC触发专载建立被叫侧：INVITE送达PGW，发DDN通知MME发起寻呼，被叫发起业务请求主叫侧：专载建立完毕后SBC转发INVITE到S-CSCF，之后进行业务触发(IMS域流程略去)被叫侧：接收INVITE之后发送183 for invite响应呼叫，SBC通过PCC触发专载建立过程被叫侧：收到AAA之后SBC转发183去S-CSCF，同时EPC继续走完专载建立流程主叫侧：183被转发到主叫侧（蓝色辅助线），收到被叫返回的183，本端开始专载更新主叫侧：专载更新完毕，下发183至终端，发送PRACK去被叫侧，但是等待200OK for prack 超时，有两次PRACK的重发。

被叫侧：被叫侧的两次PRACK下发去终端，但未收到响应（右图第66-67帧/第71-80帧），根据路测消息判断，终端接收到了PRACK但是上行发送响应失败。

VoLTE三方通话失败解决案例【摘要】VoLTE内部体验测试中，多次出现双方通话正常、三方通话失败。

通过跟踪S1口信令分析和参数排查，确定基站QCI=1的承载修改过程中速率协商失败，导致三方通话异常。

通过端到端参数协同，保证业务顺利进行。

【关键字】VoLTE三方通话建立失败端到端参数协同一、问题描述VoLTE业务测试时，多次出现双方通话正常、三方通话失败：主叫A呼叫被叫B正常通话。

A与B呼叫保持，主叫A呼叫被叫C时，C终端无响应，主叫A等待6s挂机。

图1：三方通话呼叫失败二、三方通话过程Step1：主叫A呼叫被叫B；Step2：主叫A呼叫被叫C，此时A与B之间处于Hold状态。

该过程需要协商QCI=1的GBR，保证满足三部终端合并通话要求。

Step3：点击“合并”通话，A、B、C合并到会议组建立三方通话。

被叫B、C挂机不影响通话业务，主叫A挂机则通话结束。

图2：三方通话建立过程三、问题分析过程针对VoLTE三方通话失败问题，首先排除终端问题和小区故障，结合终端Log、Wireshark S1信令、Trace LOG进行分析，查找异常原因，有针对性的分析参数设置问题。

尤其是VoLTE业务涉及网元众多，流程复杂，需要详细了解各个环节才能迅速准确的定位问题，从用户SIM卡、终端、基站、无线环境、参数检查、信令流程等分析，具体流程如下：图3：分析流程1、终端、SIM卡、eNB版本排查主叫A单独呼叫被叫B通话正常，单独呼叫被叫C时通话正常；被叫C倒换为主叫终端测试呼叫正常。

同样的终端在其它基站测试，现象一致，因此排除终端、SIM卡、eNB版本问题。

2、覆盖分析选择一个小区，使用VoLTE终端连接PC端软件测试：RSRP、SINR 良好，Attach、FTP、ping、VoLTE双方通话等各项业务均正常。

因此排除基站业务异常和无线环境问题。

只有在进行VoLTE三方通话业务异常。

3、设备侧核查传输检查：eNB能够正常ping通，eNB ping MME、源基站ping 邻基站、邻基站ping源基站，均能ping通，时延均正常，说明网元之间链路正常。