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承载，问题解决。

错误代码CREATE BEARER RESPONSE(Cause:73)解释：Create Bearer Response（MME通过S11接口给SGW发送此消息，作为Dedicated Bearer Activation流程的一部分）73：No resources available在LMT上进行用户跟踪或S11接口跟踪，UGW9811收到USN9810发送的Create Bearer Request消息后，回应拒绝响应，原因值为73跟踪后发现原因值为No resources available（无可用资源）查看现网中QOS相关参数设置：GBR和Non-GBR根据QCI的不同，承载（Bearer）可以划分为两大类：GBR（Guaranteed Bit Rate，保证比特速率）类承载和Non-GBR类承载。

GBR类承载，用于对实时性要求较高的业务，需要调度器对该类承载保证最低的比特速率，其QCI的范围是1-4。

有了这个最低速率外，还需要一个最高速率进行限制。

对于GBR承载来说，使用MBR来限制该承载的最大速率。

MBR（Maximum Bit Rate，最大比特速率）参数定义了GBR承载在RB资源充足的条件下，能够达到的速率上限。

MBR的值大于或等于GBR 的值。

Non-GBR类承载，用于对实时性要求不高的业务，不需要调度器对该类承载保证最低的比特速率，其QCI的范围是5-9。

在网络拥挤的情况下，业务需要承受降低速率的要求。

对于Non-GBR，使用UE-AMBR（Aggregate Maximum Bit Rate，聚合最大比特速率）来限制所有Non-GBR承载的最大速率（注意，不是限制某个Non-GBR承载，而是针对UE级别的。

贝尔相关业务参数：从TD-LTE QOS参数里可以查到不同业务索引，9种QCI值各有一种索引。

支持VoLTE，基站要建三个承载，默认承载+QCI5承载+QCI1承载。

(1) QCI1QCI=1的为VoLTE语音业务，属于GBR(Guranteed Bit Rate) 类QOS，QCI=1: trafficRadioBearerConfName: VOIP① DRB RLC模式②头压缩使用指示③ PDCP SN配置。

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用户的移动性管理等功能。

成功解决因E-RAB尝试修改失败导致的VoLTE无法接通目录第一章项目创新背景 (3)第二章项目创新总体思路 (4)第三章项目创新方案和实施过程 (5)第四章项目创新成效 (8)第一章项目创新背景1.1创新现状随着Volte的大力发展将在5.17号进行全网商用，为了解决商用前用户使用Volte通话过程中遇到的问题，急需要集中精力进行专项分析解决。

在面对新技术快速迭代且无有效参考经验的前提下，根据所学理论联系实际通过大量的数据分析和规范的流程进行经验总结和提炼，梳理出日常用户遇到的问题。

VOLTE高清语音通话，是完全基于4G承载的语音，网络质量的好坏对于语音的接通和体验影响很大。

本创新通过用户反映的打不通电话为切入点进行信令跟踪分析和参数核查，找到影响VOLTE通话功能的相关参数。

其中发现对QCI更新之后的E-RAB修改有影响的参数开关为QCI更新参数校验开关，用于控制QCI更新时是否开启相关参数校验。

当开关开启，不支持QCI动态更新前后相关的RLC和PDCP参数变化，导致E-RAB修改成功率降低。

该用户拨打失败的问题就是此参数导致，通过关闭此开关E-RAB的修改成功率恢复正常，用户拨打电话正常，问题得到解决。

该创新就是在日常的优化问题中发现并进行提炼出来的，通过发现Volte的参数问题成功解决了用户电话打不通的问题。

1.2背景知识VOLTE是一个面向手机和数据终端的高速无线通信标准。

它基于IP多媒体子系统（IMS）网络，在LTE上使用为控制层面（Control plane）和语音服务的媒体层面（Media plane）特制的配置文件（由GSM协会在PRD IR.92中定义）[1]，这使语音服务（控制和媒体层面）作为数据流在LTE数据承载网络中传输，而不再需维护和依赖传统的电路交换语音网络。

第二章项目创新总体思路通过用户反映的打不通电话为切入点进行信令跟踪分析和参数核查，找到影响VOLTE 通话功能的相关参数。

Volte掉话案例在对已经升级为14.3版本的网格10进行拉网测试时发现，仍出现主叫与被叫先后上发BYE，去激活专用承载后收到BYE487导致掉话问题，具体情况如下：被叫，主被叫先后发起Bye消息，去激活专用承载后，网络侧下发Bye 487导致掉话（截图如下）：（A）核心网消息跟踪上看，被叫在15:35:51.470先上发BYE，核心侧未等到主叫回BYE200，就在15:35:51.556又收到主叫上发的BYE消息。

导致核心侧发BYE487：Glare BYE condition encountered，原因：在下发一个bye请求(来自被叫)，但还没有收到应答，收到一个上行的bye请求（来自主叫）。

（B）之前已经出现BYE487掉话的问题，是因为与华为站点的PDCP-SN-SIZE设置不同导致的掉话，但是网格10进行升版之后已经全部修改一致。

为了对问题更好的定位，次日我们对网格10又进行了一次拉网测试，并留意观察在掉话之前是否有声音以最终确定问题现象与PDCP-SN-SIZE导致的问题是否一致！结果发现在BYE487问题导致掉话前10s是没有声音的。

所以依然是单通和不通导致的掉话。

在对拉网数据进行分析时发现，在黄浦路二试扩L-1小区下进行起呼时在下发重配消息中的PDCP-SN-SIZE还是12bit。

（C）所以我们再一次进行了参数的核查，发现14.3版本的站点的应该和LR13.3一样指向DedicatedConf/0 PdcpConf/1，因为DedicatedConf/0 PdcpConf/2中定义的PDCPPDUSNSIZE=12,所以指向到了DedicatedConf/0 PdcpConf/2，就出错了。

截图如下：（D）最终核查结果又一百多个站点的指向错误，在修改指向后进行了复测，BYE487掉话没有出现。

原因值呼叫类型失败原因失败呼叫次数其他51unassigned number16850-255-183-4801user is busy 114internal error 42user is busy 8internal error 6unassigned number 850-255-183-486unassigned number 850-255-183-486850-255-183-487原因值呼叫类型warning码第一拆线网元失败次数No appropriate session for SRVCC/eSRVCC 3null2Internal error 1No appropriate session for SRVCC/eSRVCC10 RELEASE FROM CC!101Internal error 142null30 RELEASE FROM CC!5Internal error 13null3原因值呼叫类型warning码第一拆线网元失败次数Internal error 134null8SCSCF released the session because of PERMANENT1Cancel received on initial invite10 RELEASE FROM CC!1视频403Forbidden语音视频486 Busy Here语音403 Forbidden、486 Busy Here、480 Temporarily Unavailable、received cancel message语音unassigned number 2163480Temporarily Unavailable语音ASInternal error 10A-SBCMGCF视频2020SCSCF 487Request Terminated语音device506SIPSL_ReleaseForMgcf SuppressTone():release mgcf and cs.ims should send tone based on status 3back system reject state: 481原因值呼叫类型warning码第一拆线网元失败次数Internal error6Glare condition1Internal error 2416sipsl_nc_sipi_bearer _time_out.8Internal errorP-CSCF 1原因值呼叫类型warning码第一拆线网元失败次数Internal error 或 0RELEASE FROM CC!SCSCF 72原因值呼叫类型warning码第一拆线网元失败次数Alerting switchrelease split call.18991 RELEASE COMPLETE FROM CC!95Get basic data failed.27Internal error5语音deviceMGCFRequest Terminated504Gateway Time-out语音Internal error 或 0RELEASE FROM CC!MGCF 580Precondition Failure404 not found语音deviceRoute Address Not Found700 RELEASE FROM CC!379Internal error PSBC 4188视频Internal error 或 91RELEASE COMPLETEFROM CC!21原因值呼叫类型被叫号码情况第一拆线网元失败次数被叫号码异常107被叫号码正常6视频被叫号码异常1原因值呼叫类型warning码第一拆线网元失败次数0 RELEASE FROM CC!或 Internal errorThe callee is notregistered10视频Internal error 或The callee is notregistered8原因值呼叫类型被叫号码情况第一拆线网元失败次数被叫号码为外省固话2被叫号码为外省移动号码2被叫为本省移动号码1视频被叫号码为外省移动号码1484 Address Incomplete5001 DIAMETER_ ERROR_USE R_UNKNOWN 语音HSS173语音device被叫为1259023+短号23488 Not Acceptabl e Here 语音I-CSCFable、487 Request Terminated、分析抽查了20条Q850原因为：unassigned number的记录都是由于发起呼叫后很短时间内早释引起。

《VoLTE小经验》：VoLTE打VoLTE语音呼叫失败的分析思路1、若主叫VoLTE SBC未收到invite消息时，需检查主叫侧EPC及无线问题。

2、若主叫VoLTE SBC收到invite消息后，未转发至主叫S-CSCF时，则主叫资源预留失败，需检查：1) 主叫PGW是否开启带宽向上取整功能。

2) 主叫VoLTE SBC发送至主叫PCRF的AAR消息中，是否携带主叫上下行带宽信息、UE的IP地址等。

3) 主叫VoLTE SBC是否收到主叫PCRF的AAA消息和RAR消息（携带UE位置信息）。

4) 主叫L-DRA是否正确转发VoLTE SBC与PCRF之间的信令消息。

3、若主叫计费错误或被叫号码识别错误，需检查主叫VoLTE SBC发送至主叫S-CSCF消息中，PANI头域是否填写sbc-domain且GCID是否翻译正确。

4、若被叫路由至CS域，需检查：1) 主叫S-CSCF号码分析局数据配置是否正确。

2) 主叫ENUM/DNS码号数据配置是否正确。

5、若主/被叫业务触发错误（如未触发/重复触发AS等），需检查：1) 主叫/被叫S-CSCF触发主叫/被叫AS顺序（即SiFC配置）是否正确。

2) 被叫SCCAS收到HSS的T-ADS信息，是否包含IMS Voice over PS Supported。

6、被叫UE回落2G接续，需检查HSS中UE能力是否为支持SRVCC及MME在UE注册过程中是否上报了此能力。

7、若被叫SCC AS收到100trying但未收到183消息至定时器超时，SCC AS在电路域重试导被叫UE回落，需检查CS retry的定时器是否大于EPC寻呼超时定时器。

8、若被叫VoLTE SBC未收到183消息时，需检查被叫侧EPC及无线问题。

9、若被叫VoLTE SBC收到488消息，则编解码信息协商失败，需检查主被叫UE支持编解码信息情况。

10、若被叫VoLTESBC收到183消息后，未转发至被叫S-CSCF时，则被叫资源预留失败，需检查：1) 被叫PGW是否开启带宽向上取整功能。

VOLTE接通率（500错误）优化分析案例一、问题现象某地市VOLTE接通率（信令）指标一直处于全省倒数，未达到99.5%考核值。

通过借助中兴信令平台分析发现，失败原因值主要为主要集中在500（占比39.11%）、504（占比34.47%）错误。

二、问题分析从失败反馈原因值500进行深入分析发现，500错误场景主要为VOLTE-CS与VOLTE-固话。

而两者问题以后者为主，如下表。

故从VOLTE-固话入手分析，而且失败固话号码基本全部为移动铁通固话。

通过中兴信令平台信令来看，携带原因值解码为R eason:Q.850;cause=4;text=”Send special information tone “,SIP;cause=500.根据此信息联系本地铁通关口局管理人员。

得知，目前IMS固定电话和VOLTE用户拨打铁通固定电话由移动关口局完成话务转接，因前期固话业务在话务转接中，对主叫号码属性有要求，故移动关口局上，对IMS号码拨打铁通号码做有主叫号码属性变换：后在拨打测试中发现，当VOLTE用户拨打铁通固定号码时，因关口局对主叫号码进行变换为“用户号码”，此时，关口局会将主叫号码进行删除前四位的处理（关口局指定用户号码本质是删除前四位0915区号），此时主叫号码只剩下后7位，继续接续到铁通后，由于主叫号码改变，铁通关口局无法识别主叫号码，便会将此呼叫过程拒绝，在拒绝的返回原因中未指定具体原因值，此拒绝信令通过关口局透传至主叫侧，由于整个拒绝信令中都未指定拒绝原因值，VOLTE核心网变将此类失败统一归纳为：“失败值500：server fault ”。

发现此问题后，9月27日17点通过在关口局对指定主叫号码格式的参数进行修改，对主叫号码格式不再进行指定：再次进行业务测试，主叫号码位长正常，铁通关口局正常完成接续过程，VOLTE接通正常。

三、问题总结验证抽取9月27日前三天VOLTE接通失败数据与9月27日17点后数据进行对比，发现500错误中VOLTE-固话基本全部消失。