volte测试发现503错误IMS分析报告文案
VOLTE起呼失败的案例
VOLTE起呼失败的案例1. 问题描述使用HTC M8T的VOLTE版本，升级成最新的版本–RC25、R35新版本。
升级完成后注册IMS成功，但在华为MME下无法进行VOLTE呼叫，变成了CSFB语音方案回落至2G进行通话。
2. 问题分析终端使用测试卡已注册VOLTE网络成功，进行呼叫的时候，网络侧回复503错误（SERVICE UNAVAILABLE）。
具体的SIP信令流程如下。
1、UE->NW INVITE2、NW->UE Cancel503终端发起VOLTE呼叫，且支持Silent Redial机制：当VOLTE呼叫失败后，将转成CSFB 语音方案，因此呼叫回落至2G。
而使用相同卡插入三星S6测试VOLTE呼叫，呼叫成功。
问题原因：不同VOLTE终端，采用的附着建立默认承载的方法也不同，主要有两种不同的方法：1、终端附着网络时，使用网络默认APN建立默认承载。
比如，HTC M8T。
2、终端附着网络时，使用终端侧设置的APN建立默认承载。
比如，三星S6。
3、使用终端侧设置的APN建立默认承载，按照3GPP24.301章节8.3.20.2描述，在附着络过程中，建立PDN连接请求消息如果携带“ESM information transfer flag”( ESM 信息传输标记），表示终端希望使用自己提供的APN。
三星S6使用终端侧设置的默认承载信令截图如下：1、终端在Attach request请求信令携带“ESM information transfer flag”：2、网络侧发起APN请求，ESM information request，终端通过ESM information response回复网络侧终端上设置的默认APN。
HTC M8T使用网络侧设置的默认承载信令截图如下：1、终端Attach request请求信令未携带“ESM information transfer flag”：2、网络侧发起APN请求无ESM information request：经过测试分析发现，HTC M8T，使用LTE的APN进行IMS注册期间，终端发起了3次默认承载请求，在第三次默认承载请求，PDN类型为ipv6的PDN连接请求，网络侧处理此请求时，错误地建立了IMS承载。
精品案例_传输参数tacLimitGbrNormal配置错误导致的Volte无法呼叫
传输参数tacLimitGbrNormal配置错误导致的Volte无法呼叫目录1问题描述 (3)2分析过程 (3)3优化措施 (4)4经验总结 (6)传输参数tacLimitGbrNormal配置错误导致的Volte无法呼叫【摘要】目前六安电信已经全网打开VOLTE功能，但是在VoLTE投诉处理过程中，发现个别用户有无法进行VoLTE业务的情况，经过参数对比分析，最终确定是基站侧传输参数tacLimitGbrNormal配置不合理导致volte业务无法进行，优化后问题解决。
【关键字】tacLimitGbrNormal、VoLTE1 问题描述在近期的日常优化中，个别用户反馈手机卡已开通VoLTE功能，手机亦支持VoLTE功能，但无法进行VoLTE业务。
现场测试主要体现为INVITE-tying 100后出现503错误，如下问题是该小区都无法成功拨打VoLTE电话，表现为IMS注册成功，手机有VOLTE标志，但是如果拨打电话，却会回落到2G进行通话，出现概率100%，而且如果从其他基站正常VoLTE 起呼后，再往不正常站点进行QCI1的切换，是正常的不会掉话。
2 分析过程通过抓取EMIL信令发现，在核心网对基站发起专载(QCI1)建立请求后，ENB回复传输资源不可用(transport-resource-unavailable(0))，专载建立失败。
如下：尝试操作：1、进行BTS参数模板倒换测试，无效；2、检查IP段设置，同样IP段的其他基站也是正常的；3、基站软件版本升级，无效；进行过以上操作后，问题依旧，我们可以排除基站BTS数据配置问题、软件版本问题、IP路由问题，把问题排查范围缩小到传输参数(TRS)配置问题，继续检查基站侧TRS参数，发现参数tacLimitGbrNormal都是设置的1M，于是调整为1000M后再测试，问题解决，可以正常建立QCI承载，通话正常。
3 优化措施将参数tacLimitGbrNormal调整为1000M后再测试，问题解决，可以正常建立QCI承载，问题解决。
SIP-503错误码原因分析研究VoLTE端到端业务质量分析
VoLTE端到端质量分析SIP-503错误码原因分析研究目录1.SIP-503消息错误码分析背景 (2)2.SIP-503失败原因分类 (2)3.SIP-503流程分析 (4)3.1.无线链路失败导致掉话 (4)3.2.VoLTE走盲重定向导致掉话 (5).X2切换失败导致的掉话 (5)3.4.Sip信令丢失导致未接通ue-not-available-for-ps-service (6)3.5.2G侧资源异常导致未接通 (8)3.6.基站弱场起呼功能导致 (8)3.7.BSRVCC切换失败 (9)3.8.VoLTE参数配置问题 (10)3.9.VoLTE流程冲突问题（1） (11)3.10.VoLTE流程冲突问题（2） (12)3.11.VoLTE流程冲突问题（3） (13)3.12.VoLTE流程冲突问题（4） (13)3.13.VoLTE流程冲突问题（5） (14)4.SIP-503失败案例总结 (15)4.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry (15)4.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry (16)4.3.传输问题导致SIP-503 S1切换导致VoLTE掉话 (19)4.4.站内切换与modify并发SIP-503导致视频失败 (23)4.5.站内切换并发导致未接通 (24)5.SIP-503失败原因处理流程总结 (26)1.SIP-503消息错误码分析背景2016年中国移动集团开展VoLTE百日会战工作期间，我司在VoLTE质量提升过程中结合炎强平台从TOP小区、DT/CQT遍历拉网测试信令分析中总结经验，旨在帮助各办事处尽快解决信令分析中遇到的问题。
随着VoLTE优化工作的开展，我们发现有些SIP-503错误码与无线测关联较大，如外部邻区、帧头偏移未对齐导致的干扰，传输时延、切换并发等问题都会导致SIP消息报错，而这些SIP消息报错的时间点之前eNB就发起了异常的信令释放。
VoLTE路测拉网问题经验共享
VoLTE路测拉⽹问题经验共享1、403问题（掉话后⽹络未释放导致后续多次未接通）LOG：南京-⽹格8-20150913-1.log(主叫：184********/被叫：184********) 【问题描述】TIME=08:47:35.351主被叫掉话，出现20次呼叫不通的前1个通话，主被叫都掉话了，没有bye200。
TIME=08:44:56.699主叫发送INVITE消息后，TIME=08:44:58.914被叫响应寻呼，8S后，主叫发送ACK消息，呼叫建⽴，⽆线环境良好主被叫发射功率⾼，被叫连续两次RRC重配置后，TIME=08:47:27.692发送BYE消息，主叫TIME=08:44:58.914收到消息RRCConnectionReestablishmentReject，RRC重配置拒绝，3S后，TIME=08:47:29.798主叫发送BYE消息，未收到BYE200消息，主被叫掉话。
主被叫发射功率⾼，主被叫RRC重配置失败，导致主被叫掉话。
TIME=08:48:06.386主叫发送INVITE消息后，4S后，TIME=08:48:10.957主叫回落⾄2G，并在2G⽹络发起呼叫，主叫在2G⽹络超时挂机，TIME=08:48:36.775主叫在2G⽹络未接通。
TIME=08:48:52.439主叫发送INVITE消息后，接着主叫做TAU更新，2S后，TIME=08:48:54.146主叫收到INVITE403消息，未接通。
（被叫信令缺失）TIME=08:49:11.041主叫发送INVITE消息后，被叫信令缺失，1S后，主叫TIME=08:49:12.785主叫收到INVITE403消息，主叫发送ACK消息，呼叫失败，未接通。
TIME=08:49:29.628主叫发送INVITE消息后，被叫信令缺失，4S后，主叫TIME=08:49:33.168主叫收到INVITE403消息，主叫发送ACK消息，呼叫失败，未接通。
VOLTE呼叫失败分析指导书
VoLTE呼叫失败分析指导书1VoLTE整体构架1.1网元及组网方式华为VoLTE解决方案的典型组网如图1所示。
通过在现有的CS网络上叠加部署IMS网络和LTE网络，提供端到端的QoS保障，为终端用户提供高质量的语音、视频呼叫和更为丰富的数据业务，从而帮助运营商从2G/3G网络逐步演进到LTE网络，完成纯语音到丰富语音的转型。
终端用户可以通过CSFB、Single Radio、Dual Radio等多种LTE终端设备，在LTE网络、2G/3G网络下接入。
当用户移出LTE信号区域时，系统可以将呼叫平滑切换到2G/3G网络。
除此之外，方案中还提供了统一的业务发放、网络管理、计费等功能。
图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等网络功能实体的功能。
b)当现网不使用融合HLR/HSS时，可采用分离HLR/HSS，支持在现网已存在的HLR、IMS-HSS和SAE-HSS上实现VoLTE业务。
接入层接入层主要实现LTE用户的接入，支持对LTE用户的移动性管理等功能。
VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例
VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例广东茂名+ VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例目录利用VOLTE-SIP协议分析优化VOLTE网络总结创新案例............................错误!未定义书签。
一、概述 (3)二、创新方案 (3)2.1技术原理 (3)2.1.1 SIP协议定义 (3)2.1.2 SIP协议主要概念模型 (5)2.1.3 SIP协议主要消息 (8)2.1.4 消息格式 (13)2.1.5 SIP协议主要响应码 (16)2.1.6 SIP呼叫过程实例 (17)2.2 SIP协议异常原因优化指导 (18)2.2.1网络侧下发503问题分析 (18)2.2.2呼叫前转号码签约SIP格式，前转失败 (19)2.2.3 CSCF返回的RTA消息报错 (19)2.2.4 呼叫转移失败 (19)2.2.5注册失败，ims回500错误 (20)2.2.6 SIP平台拒绝主叫的INVITE呼叫请求 (20)2.2.7 SIP呼叫主叫用户无法听回铃音 (21)2.3 茂名VOLTE经典问题分析 (21)2.3.1QCI1建立与切换流程冲突，核心网下发INVITE503问题 (21)2.3.2无线信号环境差导致网络侧未收到BYE200 (23)2.3.2 核心网信令丢失导致未收到寻呼 (25)三、经验总结 (26)VOLTE-SIP协议异常原因排查优化VOLTE网络总结创新案例【摘要】本文主要论述通过对VOLTE的SIP协议信令分析对VOLTE问题进行原因挖掘分析，总结出VOLTE优化过程中所遇到的各类异常SIP协议消息的处理思路与方法，优化网络，提升volte用户感知。
【关键字】VOLTE异常事件、SIP消息、响应码【业务类别】VoLTE、流程类一、概述VOLTE日常分析优化过程中经常会遇到出现注册异常、掉话、未接通等异常事件，而L3信令用于呈现的是SIP消息响应码，信令分析时，正确解析L3中的SIP请求或响应码是分析问题的关键，现就前期遇到的异常响应消息进行总结，与大家分享。
VOLTE测试问题点汇总
1、VOL TE测试信令流程与标准不符1.1起呼过程中主被叫在183 消息之前已完成QCI1专载建立,共有以下4种情况：被叫2种：a).被叫在收到INVITE Request之前已完成完成QCI1专载建立;b).被叫在收到INVITE的同时收到QCI=1的承载建立请求；主叫2种：c). 主叫在收到IMS的100 Trying之前就已经建立QCI=1的承载；d). 主叫在收到Trying 100后，183前已完成QCI1专载建立信令截图如下：a).被叫收到INVITE消息前就开始建立QCI1的专用承载;B).被叫在收到INVITE的同时收到QCI=1的承载建立请求；c).主叫在收到IMS的100 Trying之前就已经建立QCI=1的承载；d). 主叫在收到Trying 100后，183前已完成QCI1专载建立，被叫在INVITE Request前已完成完成QCI1专载建立。
1.2被叫侧在回复BYE-200之前，主叫就已经收到IMS下发的BYE-200消息IMS核心网反馈，SBC策略要是收到任一方BYE Reques 直接通知MME释放EPS，无需等待主被叫回复BYE 200 OK。
1.3主叫发起BYE Request挂机，但被叫先收到专载释放，且释放完成后才收到IMS下发的BYE Request，导致平台统计为掉话。
DRB-3为QCI1专载1.4主叫收到Trying 100后网络侧下发去激活QCI1专载，但主叫上次通过结束后已释放完成。
2、三次Modify EPS bearer2.1 主被叫在起呼过程中多次修改EPS Bearer测试发现起呼过程中多次修改EPS Bearer: GBrForDwLink、GBrForUpLink、MbForDwLink、MbrForUpLink 相关速率修改为49、50、96等。
QCI=1的专用承载的EPSID=8(GBR上行50、下行49，第一次MODIFY：修改GBR上下行49，第二次MODIFY：与第一次一样，第三次MODIFY与第二次一样；这种多次修改GBR保障速率主要目的是什么？帮忙看看核心网是否能答复异常呢？)value message name : Activate dedicated EPS bearer context requestvalue Activate dedicated EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc5|----LinkedEpsBearerId : 0x05|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 50|----MbrForDwLink : 49|----MbrForUpLink : 50|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第一次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 49|----MbrForDwLink : 49|----MbrForUpLink : 49|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第二次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 50|----MbrForDwLink : 49|----MbrForUpLink : 50|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第三次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 49|----MbrForDwLink : 49|----MbrForUpLink : 49|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1下图GBrForDwLink、、MbForDwLink、相关速率有修改为49、96。
中兴VoLTE优化经验的总结及案例
VoLTE优化经验总结及案例分享1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer 由300ms 修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
503校验规则未通过
503校验规则未通过摘要：1.503 校验规则的介绍2.503 校验规则未通过的原因3.解决503 校验规则未通过的方法4.总结正文：一、503 校验规则的介绍503 校验规则是指在网络访问过程中，服务器端根据访问者的请求，对请求进行校验，以判断请求是否合法。
其中，503 是服务器返回的一种状态码，表示服务器当前无法处理客户端的请求。
通常情况下，503 校验规则用于防范恶意访问、保护网站安全等方面。
二、503 校验规则未通过的原因当服务器返回503 状态码时，通常意味着客户端的请求被服务器拒绝。
导致503 校验规则未通过的原因有很多，以下是一些常见的原因：1.客户端请求过于频繁，超出了服务器的承受范围。
2.客户端请求的参数不合法，不符合服务器的校验规则。
3.服务器端的校验规则设置不合理，导致合法请求也被拒绝。
4.服务器端程序出现逻辑错误，无法正确处理客户端的请求。
5.网络环境问题，如网络延迟、带宽不足等，导致客户端请求无法及时到达服务器。
三、解决503 校验规则未通过的方法针对503 校验规则未通过的问题，可以从以下几个方面进行解决：1.优化客户端请求：降低请求频率，避免短时间内大量请求发送给服务器。
对于需要频繁请求的场景，可以考虑使用缓存、队列等技术来降低请求的实时性。
2.检查请求参数：确保发送给服务器的请求参数合法、正确。
对于需要携带参数的请求，可以对参数进行合法性校验，避免携带不合法的参数。
3.调整服务器端的校验规则：合理设置服务器端的校验规则，避免过度限制客户端的请求。
对于误报的情况，可以对服务器端的校验逻辑进行优化，提高校验的准确性。
4.修复服务器端程序逻辑错误：对于服务器端程序出现的逻辑错误，需要进行排查、修复。
可以通过日志分析、调试等方式，找出程序中存在的问题，并进行修复。
5.优化网络环境：提高网络带宽、降低网络延迟，以保证客户端请求能够及时到达服务器。
对于网络环境不稳定的情况，可以考虑使用负载均衡、CDN 等技术来提高服务的可用性。
VOLTE接通率错误优化分析案例
V O L T E接通率（500错误）优化分析案例一、问题现象某地市VOLTE接通率（信令）指标一直处于全省倒数，未达到99.5%考核值。
通过借助中兴信令平台分析发现，失败原因值主要为主要集中在500（占比39.11%）、504（占比34.47%）错误。
二、问题分析从失败反馈原因值500进行深入分析发现，500错误场景主要为VOLTE-CS 与VOLTE-固话。
而两者问题以后者为主，如下表。
故从VOLTE-固话入手分析，而且失败固话号码基本全部为移动铁通固话。
通过中兴信令平台信令来看，携带原因值解码为R eason:Q.850;cause=4;text=”Sendspecialinformationtone“,SIP;cause=500.根据此信息联系本地铁通关口局管理人员。
得知，目前IMS固定电话和VOLTE 用户拨打铁通固定电话由移动关口局完成话务转接，因前期固话业务在话务转接中，对主叫号码属性有要求，故移动关口局上，对IMS号码拨打铁通号码做有主叫号码属性变换：后在拨打测试中发现，当VOLTE用户拨打铁通固定号码时，因关口局对主叫号码进行变换为“用户号码”，此时，关口局会将主叫号码进行删除前四位的处理（关口局指定用户号码本质是删除前四位0915区号），此时主叫号码只剩下后7位，继续接续到铁通后，由于主叫号码改变，铁通关口局无法识别主叫号码，便会将此呼叫过程拒绝，在拒绝的返回原因中未指定具体原因值，此拒绝信令通过关口局透传至主叫侧，由于整个拒绝信令中都未指定拒绝原因值，VOLTE核心网变将此类失败统一归纳为：“失败值500：serverfault”。
发现此问题后，9月27日17点通过在关口局对指定主叫号码格式的参数进行修改，对主叫号码格式不再进行指定：再次进行业务测试，主叫号码位长正常，铁通关口局正常完成接续过程，VOLTE接通正常。
三、问题总结验证抽取9月27日前三天VOLTE接通失败数据与9月27日17点后数据进行对比，发现500错误中VOLTE-固话基本全部消失。
VOLTE优化经验总结
1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS 的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
5G优化案例：三类典型5G终端VOLTE呼叫失败案例分析
三类典型5G 终端VOLTE 呼叫失败案例【摘要】在政策扶持和5G 技术日益成熟的影响下，中国5G 产业发展稳步推进，企业发展态势良好，从规划环节、建设环节、运营环节到应用环节各个不同产业链相关企业2018 年第三季度营收均超亿元，实现同比增长、智能制造、车联网、无线医疗到5G 技术应用领域频获资本青睐。
分析师认为，随着5G 临时牌照发放和商用步伐的加快，未来中国5G 产业在带动中国经济产出、提供就业机会等方面将发挥重要作用。
目前，5G 时代正加速到来，中国5G 产业快速发展，在各个领域上也已取得不错的成绩。
在5G 建设初期，网络优化过程中也会发现诸多问题，发现问题解决问题是网络发展初期必经的过程，同时也为后续的网络优化提供了必要的经验。
【关键字】5G 网络优化VOLTE【业务类别】5G一、问题描述5G 初期语音网络和数据网络分离，采用NR+LTE 双连接组网，话音通过EPC+LTE 来提供，以VoLTE 作为语音解决方案。
在5G 网络深入优化后，逐步推出VoNR，VoNR 是5G 网络的目标话音解决方案，将成为主流语音技术。
2020 年将是5G 网络爆速发展的一年，及时发现问题并解决问题是网络快速良性发展的必要因素，建网初期积累的优化经验是后续5G 网络质量的有效保证。
5G NR 网络下，语音有两种方式，终极方式是VoNR，就是在5G 网络上承建语音业务，将语音数据转换成数据业务，类似OTT。
由于硬件暂不支持，现阶段我们用的还是VOLTE，即在4G 网络上承载语音业务。
在4G 无线升级到15.1SPC171 版本后，VoLTE 用户SCG 管理策略，使用volte 优先。
当5G 用户进行语音业务时，5G 连接释放，回落到4G 进行VOLTE。
手机角标有HD 标识。
VoNR 是 5G 网络的目标话音解决方案，从 5G 商用初期选择的话音方案演进到 VoNR ，存在多条路径。
截止目前，主要有 3 条 VoNR 演进路径。
IMS错误码分析
案例一
IMS-001错误码介绍：IMS-001错误码表示“未找到目 标用户”，通常是由于用户输入的被叫号码不正确或者 被叫用户不可达等原因引起的。
案例二
IMS-002错误码介绍：IMS-002错误码表示“会话建立 失败”，通常是由于主叫用户和被叫用户之间的网络连 接中断或者网络质量差等原因引起的。
典型IMS错误码案例分析
2004
服务器内部错误。
03
IMS错误码产生原因及处理措施
网络引起的IMS错误码
总结词
网络故障、路由问题、传输问题
详细描述
网络引起的IMS错误码通常是由于网络故障、路由问题以及传输问题等因素导致 的。例如，网络连接断开、路由路径错误或传输过程中出现数据包丢失等情况都 可能导致IMS系统无法正常处理请求，从而产生错误码。
终端引起的IMS错误码
总结词
终端故障、号码问题、接入问题
详细描述
终端引起的IMS错误码通常是由终端故障、号码问题以及接入问题等因素导致的。例如，终端设备出现故障或 异常情况，号码输入错误或格式不正确，以及接入IMS系统的身份验证失败等问题都可能导致IMS系统无法正 常处理请求，从而产生错误码。
系统引起的IMS错误码
IMS-001错误码分析
当出现IMS-001错误码时，需要对被叫号码 进行核实，同时检查被叫用户的可用性以及 呼叫路由是否正确。
IMS-002错误码分析
当出现IMS-002错误码时，需要检查主叫用 户和被叫用户之间的网络连接是否正常，同 时考虑网络质量以及是否受到其他因素的影
响。
典型IMS错误码案例解决方案及经验总结
IMS系统采用分组交换的技术，相比传统的 TDM(Time Division Multiplexing)技术，可以大 大节约设备和网络的投资成本。
IMS错误码分析
03
3. 常见IMS错误码案例分析
3. 常见IMS错误码案例分析
3.1 案例一：调用IMS接口返回500 Internal Server Error
在该案例中，我们遇到了一个常见的错误码-500 Internal Server Error。该错误码通常表示服务器内部错误。我们需要分析请求参数、接口实现逻辑等方面，以确定错误产生的原因，并进行相应的修复。3.2 案例二：IMS注册失败，返回408 Request Timeout
1.2 为什么需要错误码分析？
错误码分析对于IMS系统的运维和故障排查非常重要。通过分析错误码，我们可以快速定位问题，并采取正确的解决方案，提高系统的可靠性和稳定性。
02
2. 常见IMS错误码及分析
2. 常见IMS错误码及分析
2.1 401 Unauthorized
该错误码表示客户端未经授权请求，可能原因包括用户未登录、权限不足等。我们需要进一步分析请求的上下文及相关的认证信息，找出原因并采取相应的处理措施。2.2 503 Service Unavailable2.3 404 Not Found
在该案例中，用户尝试进行IMS通话时，返回了486 Busy Here错误码，意味着目标号码正忙。我们需要检查目标号码是否可通、网络连接等，进一步排查故障原因，并采取适当的解决方案。这是一份IMS错误码分析的演示文档，通过对常见错误码的解读和案例分析，帮助我们更好地理解和处理IMS系统中遇到的问题。
该错误码表示请求Βιβλιοθήκη 资源未找到。我们需要检查请求的URL是否正确、服务器是否配置正确等，进一步明确问题所在，并进行相应的修正。
2.2 503 Service Unavailable
出现该错误码通常意味着服务不可用或超负荷。我们可以通过检查服务是否正常运行、资源是否充足等方式来解决问题。还可以考虑优化服务部署结构，提高系统的扩展性。
volte测试发现503错误IMS分析报告文案
2、4、5、6、7、9、11、12、核心网分析：问题1、11月5日13:23:15.731主叫侧SBC消息，收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向主叫发503。
需要PCRF与EPC 确认原因。
问题2、11月5日13:44:52.271主叫侧SBC消息，收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向主叫发503。
需要PCRF与EPC 确认原因。
（同问题1）问题3、11月5日14:18:52.415主叫侧SBC消息，被叫侧资源预留超时：收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向被叫发503。
需要PCRF与EPC 确认原因。
问题4、11月4日13:22:33.465主叫SBC消息，主叫侧资源预留失败，RAR消息可确认：RAR消息：Epc侧分析:建立承载时,MME向enodeB E-RAB setup 请求,enodeB回复失败:enodeB ID: CE482(844930)问题1 及问题2 在EPC侧分析：提供两组此情况的enodeB ID:源enodeb id : 6635A,十进制418650,目enodeB ID F11BA, 十进制987578 源enodeb id : 663A3,十进制418723,目enodeB ID CE2F5, 十进制844533源enodeb id : 6635A响应MME E-RAB说正在发出X2切换:X2切换完成后MME向目标enodeB ID F11BA发E-RAB请求一直未得到响应导致:问题5:源enodeb id : 66398,十进制418712,目enodeB ID 66AE6, 十进制420582问题6:源enodeb id : 34360,十进制213856,目enodeB ID 66EF7, 十进制421623问题7:源enodeb id : 664C5,十进制419013,目enodeB ID CE397, 十进制844695问题8:enodeB ID: 6647F(418943)问题9:Enode ID: CE482(844930)问题10:源enodeb id : 66AEB,十进制420587,目enodeB ID 66EF7, 十进制421623大唐无线分析：11月4号苹果测试结果中涉及我司区域的有3个503错误的未接通，附件IMS分析报告中，这3个未接通的现象都是在起呼阶段QCI1的专载建立失败，原因全为”Unknown-enb-ue-s1ap-id”。
IMS故障处理案例分析
解决措施
修改SBC设置，不主动发OPTON检查SIP终端，改为由终端涮新REGISTER来检查是否在 线情况。这样，既使出现偶尔承载网丢包，也不会出现1小时左右才自动恢复。在注册涮 新周内（50或300S）收到终端发过来REGISTER即可自动恢复。
接入设备参数设置与核心网不一致导致通话异常
问题描述 中兴SBC连接的HW EPON（SIP）用户通话30分钟左右断线。客户反馈，只有HW厂家 EPON设备会出现该故障，中兴及其他EPON终端无该故障。 分析定位 从IMS核心网、SBC、终端上同时进行信令抓包分析；从SIP信令来看，在通话达30分 钟时，SBC分别向IMS核心网、EPON终端发BYE消息，通话结束。 检查BYE消息包，X-ZTE-Cause字段的值为：SBC-4416，即SBC发送BYE的原因为： 在会话检测周期内无信令检测导致呼叫释放。 检查SBC的会话检测周期设置，为1800秒，即要1800秒内没有会话信令检测，SBC会 释放该呼叫。 对华为终端呼叫信令分析，其INVITE信令中的Session-Expires设置为7200，即会话 涮新周期为7200秒，远远大于SBC上设置的会话涮新周期。 解决措施 取消HW EPON终端侧INVITE消息中的Session-Expires字段设置，由核心网网络侧下发 会话确定刷新时长。 修改HW EPON终端侧INVITE消息参数，将会话刷新时长改成小于1800秒。
后续措施 对SBC设置IP地址注册限制，禁止中国以外的IP地址注册到IMS； 对现网进行话务监控，当发现恶意呼叫国际长途电话达到一定的费用额度后，发出警 告，并通知到客户电话是否出现异常； 限制公网地址对IAD/PBX地址的访问； 加强IMS账户密码或者是IP-PBX的内部账号密码的安全性防护工作，避免由于用户、设 备厂家等人员泄露而发起的恶意呼叫。 建议用户在拿到密码之后第一时间修改密码。
VOLTE网络中异常事件的分析
VOLTE网络中异常事件分析一、概述从VoLTE开始LTE流程变得更加复杂；首先，原来的双层网络结构被新加入的IMS域搞得异常复杂；其次，21个网元和38个接口使多数人都是过目即忘；此外,多业务混合并发、QoS得到应用、专用承载不定时地做建立、修改和释放操作。
在VOLTE网络中由于专用承载的频繁管理操作、SIP消息传递丢失、重发和高延迟，以及相互之间千丝万缕的联系，相互之间缺乏相关控制机制（如同步、交互）导致了一系列极为错综复杂网络异常现象，这些给日常分析带来许多困难。
VoLTE网络的通信机制是来自4个标准化组织组合的产物，它们分别是：○1.3GPP的23系列规范；○2SIP/RTP/DIAMETER/IPSec取自IETF的RFC；○3.VoLTE Profile和RCS取自GSMA的IR；○4.Video code取自ITU-T的H.264。
目前网络中的异常事件主要与这些标准之间的兼容性相关；本文以切换与承载管理冲突形成的异常事件为样本，分析VoLTE网络中的异常事件。
二、切换与专用承载管理流程冲突导致的异常事件1、切换与专用承载建立流程冲突导致（SIP消息503）通常用户拨打电话具有随机性，网络无法准确预估专用承载建立的时间点。
当专用承载建立请求在源小区（eNB-A）发出RRC Connection Reconfigure和MME收到S1 pathswitch request之间到达时，源小区会认为UE已切出，源基站除了缓存用户的用户面数据外，不应再处理该UE的（切换）消息，以原因值“未知的eNB UE S1APID”的方式拒绝专用承载建立请求，最终SBC会下发503错误。
图1 专用承载建立与空口切换流程冲突如上图所示：该问题的解决办法是要使MME能再次向切换的目标小区（eNB-B）发专用承载建立请求，即在目标小区上发Path Switch Rquest ACK之后再发ERAB Setup Request。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2、
4、
5、
6、
7、
9、
11、
12、
核心网分析：
问题1、11月5日13:23:15.731
主叫侧SBC消息，收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向主叫发503。
需要PCRF与EPC 确认原因。
问题2、11月5日13:44:52.271
主叫侧SBC消息，收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向主叫发503。
需要PCRF与EPC 确认原因。
（同问题1）
问题3、11月5日14:18:52.415
主叫侧SBC消息，被叫侧资源预留超时：收到PCRF的AAA响应后，等了6s都没有收到RAR资源申请结果，SBC向被叫发503。
需要PCRF与EPC 确认原因。
问题4、11月4日13:22:33.465
主叫SBC消息，主叫侧资源预留失败，RAR消息可确认：
RAR消息：
Epc侧分析:
建立承载时,MME向enodeB E-RAB setup 请求,enodeB回复失败:
enodeB ID: CE482(844930)
问题1 及问题2 在EPC侧分析：
提供两组此情况的enodeB ID:
源enodeb id : 6635A,十进制418650,目enodeB ID F11BA, 十进制987578 源enodeb id : 663A3,十进制418723,目enodeB ID CE2F5, 十进制844533
源enodeb id : 6635A响应MME E-RAB说正在发出X2切换:
X2切换完成后MME向目标enodeB ID F11BA发E-RAB请求一直未得到响应导致:
问题5:
源enodeb id : 66398,十进制418712,目enodeB ID 66AE6, 十进制420582
问题6:
源enodeb id : 34360,十进制213856,目enodeB ID 66EF7, 十进制421623
问题7:
源enodeb id : 664C5,十进制419013,目enodeB ID CE397, 十进制844695
问题8:
enodeB ID: 6647F(418943)
问题9:
Enode ID: CE482(844930)
问题10:
源enodeb id : 66AEB,十进制420587,目enodeB ID 66EF7, 十进制421623
大唐无线分析：
11月4号苹果测试结果中涉及我司区域的有3个503错误的未接通，附件IMS分析报告中，这3个未接通的现象都是在起呼阶段QCI1的专载建立失败，原因全为”Unknown-enb-ue-s1ap-id”。
逐个问题分析CDL，发现3个问题的过程基本一致，都是在判决或执行站切换的过程中，EPC下发了QCI1的ERAB建立或修改请求，然后直接回复失败，导致未接通。
问题4目enode出问题: enodeB ID: CE482(844930) 闽侯-闽侯上街闽都星城搬迁-DLH 大唐问题8: enodeB ID: 6647F(418943) 闽侯-闽侯工程学院H3宿舍楼-DLH大唐问题9: Enode ID: CE482(844930) 闽侯-闽侯上街闽都星城搬迁-DLH大唐
与后方沟通确认，大唐ENB处理符合<中国移动TD-LTE无线网络主设备规—无线功能分
册>规要求，见4.1.22 P48。
详细分析说明如下：
问题4、13:22:33.135完成初始ERAB建立，240毫秒时ue上报了1条A3的MR(站)，
此时基站应该是立即进入了切换判决流程，前135毫秒时enb下发UE能力查询未得到回
复。
而2毫秒后收到EPC下发的QCI的ERAB建立请求，2毫秒后ENB直接回复ERAB建立失败，原因为unknown-enb-ue-s1ap-id。
问题8、12:58:45.078 ue上报了1条A3的MR(站)，094毫秒时ENB下发RRC重配
执行站切换。
39毫秒后收到EPC下发的QCI的ERAB修改请求，1毫秒后ENB直接回复ERAB建立失败，原因为unknown-enb-ue-s1ap-id。
问题9、13:22:33.240完成初始ERAB建立，340毫秒时ue上报了1条A3的MR(站)，343毫秒时ENB下发RRC重配执行站切换。
20毫秒后收到EPC下发的QCI的ERAB建立请求，1毫秒后ENB直接回复ERAB建立失败，原因为unknown-enb-ue-s1ap-id。
400毫秒时站切换成功，而QCI1的专载是在站切换过程中发起的建立请求。