广州Volte指标提升过程经验总结 - 图文

1 项目概述

1.1 项目背景

VoLTE是基于IMS网络承载语音业务。广州TDD-LTE网络9000多个站eNodeB 600P04版本升级完后，能正常支持Volte功能；2014年广东移动LTE网优专项子课题之一《Volte无线网管指标研究》，主要研究Volte语音接通率低、掉话率高问题定位和解决提升方法，并对提升用户感知方法进行总结，作为后续广州移动全网开启Volte试商用优化参考思路。

1.2 VOLTE原理说明

VoIP是Voice Over Internet Protocol的简称，意为在Internet上传输语音。VoIP简而言之就是将模拟声音信号数字化，以数据封包的型式在 IP 数据网络上做实时传递。VoLTE指的是基于IMS网络承载语音业务。由于语音业务具备的特性（周期性、激活期、静默期、小数据量），eNodeB针对语音承载可以采用SPS、ROHC技术，以发挥最大的网络性能；当UE处于远点时采用TTI Bundling来提升边缘覆盖。

VoLTE的架构主要是从功能整体出发，描绘出引入VoLTE后，各个功能模块的分工。

呼叫流程

UE在IDLE下呼叫，主叫UE先触发service request流程，完后发起invite消息；核心网先给被叫UE发送paging消息，被叫UE回复service request流程，

建立链接后，核心网才能把invite转发给被叫UE。下面描述在连接下的呼叫流程图，UE1呼叫UE2：

UE1eNB1EPCIMSeNB2UE2Request: invite Status: 100 tryingRequest: invite Status: 100 tryingStatus: 180 ringingStatus: 180 ringingStatus: 200 ok核心网发起建立QCI=1的专用承载Status: 200 ok核心网发起建立QCI=1的专用承载Request: ack Request: ack 通话 挂机流程

主叫UE1发起的挂机流程：

UE1eNB1EPCIMSeNB2UE2Request: byeRequest: byeStatus: 200 okStatus: 200 ok核心网发起释放QCI=1的专用承载核心网发起释放QCI=1的专用承载检测到User Inactivity1. UE CONTEXT RELEASE REQUEST(Cause)2. UE CONTEXT RELEASE COMMAND 3. RRCConnectionRelease4. UE CONTEXT RELEASE COMPLETE 1.3 版本说明

EMS：V12.13.51P12版本； eNB :V3.30.601版本。

1.4 参数配置情况

参数中文名 参数所在表 基于语音的测量配置开关 管理网元—无线参数—TD-LTE—E-UTRAN TDD小区—测量参数 语音与数据A2事件是相互独立的，语音A2事件是测量索引号【32】，统一规范值 打开 备注 A2（32）事件判决的RSRP门限 B2（1012）事件RSRP测量时EUTRAN系统服务小区判决的绝对门限 管理网元—无线参数—TD-LTE—测量参数配置—UE系统内测量参数 -104 数据A2事件测量索引号【30】；修改语音A2事件不影响数据业务。另外，因为这次参数调整无修改A1，所以修改A2时候需要检查A1的值是否都大于-106（A2），若不是，则把A2设置成比A1小4个db。例如，A1为-106，则A2设置成-110。 管理网元—无线参数—TD-LTE—测量参数配置—UE系统间测量参数 管理网元—无线参数—-110 语音与数据B2事件是相互独立的，语音B2事件测量索引号【1012】，数据业务测量索引号【1010】，修改语音B2事件不影响数据业务。 PS切换能力 异系统GERAN邻区的DTM能力 异系统GERAN邻区的VoIP能力 服务小区与系统间邻区关系 TD-LTE—邻接小区配置—GERAN邻接小区 管理网元—无线参数—TD-LTE—邻接小区配置—GERAN邻接小区 管理网元—无线参数—TD-LTE—邻接小区配置—GERAN邻接小区 管理网元—无线参数—TD-LTE—邻接关系配置—GERAN邻接关系 管理网元—无线参数—TD-LTE—邻接关系配置—GERAN邻接关系 管理网元—无线参数—TD-LTE—无线业务配置—全局业务开关 管理网元—无线参数—TD-LTE—无线业务配置—是 支持DTM不支持DTMHO 不支持 相邻 支持切换 支持 UL SRVCC功能开关 是否支持ROHC格式关闭[0] 是，QCI=2， Profile0x0001 应用PDCP参数 管理网元—无线参数—RLC承载类型 TD-LTE—Qos配置—Qos业务类型 GERAN载频数目 频间测量和系统间测量是否同时下发 调度算法 管理网元—无线参数—TD-LTE—E-UTRAN TDD小区—测量参数 管理网元—无线参数—TD-LTE—E-UTRAN TDD小区—测量参数 管理网元—无线参数—TD-LTE—E-UTRAN TDD小区—EMLP 非确认模式 1 关闭[0] 非SPS[2] 1.5 测试设备

测试软件使用Pioneer9.5，终端使用HTC M8t手机（高通芯片）。

测试软件使用CDS7.1/鼎利9.4，终端HTC M8t（高通芯片）进行前后对比。 测试软件 终端名称 终端类别 CDS7.1/鼎利9.5 HTC M8t手机 四类 2 未接通问题分析

未接通问题的主要包括无线参数问题（异频重定向、异系统重定向）、无线覆盖问题、专载异常问题（包括切换过程中专载被MME释放和终端未收到专载建立请求）、Paging问题、esrvcc问题（Alerting中eSRVCC导致的未接通、Alerting前eSRVCC导致的未接通）、设备故障问题、核心网问题（IMS信令异常、INVITE500及INVITE580）等，其中：

1. 无线参数问题、无线覆盖问题属于无线问题，已经通过关闭系统内异频重定向、核查添加4到2G邻区以及区域优化等手段解决。 2. 专载异常问题： 1、

切换过程中专载被MME释放类问题：a、已经通过修改QCI 5信令优先级，提高SRB2的优先级来优先传送NAS信息，解决切换过程中专载被释放问题；b、开启X2切换功能，

S1切换需要MME参与，开启X2后切换过程不需要MME控制，降低该问题发生的概率；c、R5o小版本：基站等待NAS消息，专载建立过程中，基站收到MR测量报告，将缓存200ms，等NAS消息上报后再发起切换控制，可以降低该问题发生的概率，目前版本正在试用阶段。

2、

终端未收到专载建立请求：需要结合基站侧信令分，a基站是否收到专载建立请求，基站收到专载建立请求下发给终端但终端未收到专载建立请求，原因可能是下行链路太差导致终端无法收到；b核心网未下发专载建立请求，联系核心网排查未下发专载建立请求原因。

3. Paging问题：被叫无法响应寻呼导致的未接通的原因包括终端自身问题、无线问题及核心网问题，通过排查终端故障，优化覆盖及联系核心网协助解决。 4. ESRVCC问题： 1、

Alerting前eSRVCC导致的未接通：主被叫流程还未进行到振铃，此时主叫或被叫达到了eSRVCC切换条件并进行切换，切换后会话中断，未能接通。

2、

Alerting中eSRVCC导致的未接通：被叫已振

铃，此时主叫或被叫达到了eSRVCC切换条件并进行切换，切换后会话中断，未能接通。

由于IMS及核心网功能或版本问题，在呼叫振铃后ACK消息前发生ESRVCC会导致未接通，上述两类问题需优化4G网络覆盖，尽量让UE驻留在LTE小区内，根据无线环境实际情况调整B2异系统门限，减少终端切换至2G造成未接通的几率。

5. 核心网问题：属于端对端问题分类，包括IMS信令异常、INVITE500及580等SIP流异常造成的未接通。UE在无线信道较差的情况下，SIP信令在传递的过程中，发送或接收的数据不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancal。经过分析，

可能是由于QCI5的pdch discardtimer过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包，现在已经修改全网CQI 5的discartimer由300ms修改为无穷大，修改后很少发生SIP信令丢失的问题，问题基本解决。

2.1 切换过程中专载被MME释放导致未接通

【问题描述】

主叫或被叫在呼叫时的专载建立过程中，MME若未收到UE反馈专载建立完成的消息，此时发生切换，MME将在目标小区发起专载释放的请求，导致未接通。 【问题分析】

主叫发起INVITE请求后，收到网络转发的100trying消息，接下来进行专载建立与激活流程，在收到网络下发的专载建立请求之前，主叫上报了A3测量报告，随后进行专载建立流程，在激活专载并上报NAS确认消息后，主叫收到网络下发的切换重配置命令，在重切换配置消息中携带了QCI 1专载释放命令，随后主叫上报cancel取消本次通话。

【问题定位】

由于终端上报A3时间在上报NAS确认消息之前，基站侧在收到A3测量报告后向MME发起切换请求，在切换过程中MME发给目标小区的

handoverRequest消息中e_RABToBeSetupListHOReq少了QCI1的承载，所以Release QCI1的承载。 【解决措施】

目前主要通过修改QCI5优先级，提高SRB2的优先级来优先传送NAS信息，解决切换过程中专载被释放问题。

2.2 终端未收到专载建立请求导致未接通

【问题描述】

主叫或被叫在呼叫过程中，未收到系统下发的专载建立请求导致未接通。 【问题分析】

上次正常通话结束后，本次通话主叫发送trying100消息后，核心网下发专业承载请求后主叫开始建立和激活专载流程。被叫在上报183后，正常流程应该是由核心网下发专业承载建立请求后被叫开始建立专载过程，但实际上被叫一直未收到核心网下发的QCI1建立请求，主叫在上报PRACK后收到网络下发的481Call leg transaction does not exist消息，随后主叫上报cancel消息取消本次通话。

【问题定位】

终端未收到专载建立请求原因可能有：1、无线环境太差，基站转发了核心网下发的专载建立请求但终端未收到；2、核心网未下发专载建立请求。 【解决措施】

需结合基站测CTS信令查看核心网是否下发专载建立请求消息，如下发了专载建立请求但终端未收到需要检查下行链路是否太差导致，需要优化下行覆盖。核心网问题导致核心网未下发专载建立请求，需要核心网侧查找未下发专载建立请求原因。

2.3 Alerting中eSRVCC导致的未接通设备故障问题

【问题描述】

被叫已振铃，此时主叫或被叫达到了eSRVCC切换条件并进行切换，切换后会话中断，未能接通。 【问题分析】

主被叫呼叫流程正常进行至振铃阶段，被叫在上报180ringing后，收到网络了转发的ACK确认消息前，也就是振铃后接通通话前，被叫上报B2测量报告(BCCH 67 BSIC 2 BCCH Level -86dBm)，核查上报MR已满足B2判决门限，ENB下发eSRVCC命令指示UE切换至2G网络，13：55：45.956上发Handover Complete，13：55：46.156收到网络下发Disconnect 释放原因: (50)Requested facility not subscribed，导致未接通。

【问题定位】

对于Alerting中或Alerting前eSRVCC导致的未接通，主要是由于IMS及核心网功能或版本问题，在呼叫流程进行至ACK之前发生ESRVCC后都会造成未接通情况。 【解决措施】

需要联系IMS和核心网侧研发解决这类问题，无线侧优化手段有提升该路段覆盖，合理设置B2门限，使终端尽量占用LTE网络进行通话。

2.4 设备故障问题导致的未接通

【问题描述】

会话流程正常接续，终端上报Cancel，导致会话未接通 【问题分析】

1、主叫在14：53：03.998起呼，信令流程正常，且被叫上发Ringing 180，

主叫收到网络侧转发的Ringing 180，主被叫都已经振铃。但是主叫突然在14：53：06.510上发Cancel，被叫也收到网络侧转发的Cancel，会话接续停止，导致未接通。

【问题定位】

主被叫会话流程正常，无线环境良好，信令转发正常。主叫上报Cancel，导致会话未接通，定位为终端问题 【解决措施】

测试前调试终端设备，确认无问题或者更换终端测试再查看结果.

2.5 580 Precondition Failure导致未接通

【问题描述】

测试和分析中，有时会遇到Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。

【问题分析】

1、 呼叫过程中，被叫发送Ringing 180后，收到网络下发的专载去激活命令，QCI 1被

释放，被叫随后上报580 Precondition Failure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。

2、 从信令中可以看到，被叫回复Ringing 180且主叫也已经收到Ringing 180，被叫随后

收到网络侧下发的RRC重配，携带有QCI 1被释放的信息，被叫去激活专有承载。由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。主叫收到网络侧下发的580，接续被中止，导致了会话未接通。

3、 从MME下发到Node B的E-RAB RELEASE COMMAND，原因上看是Nas层

nomal_release，导致专载QCI 1被释放。

4、 专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE

580，会话流程中断，导致未接通。

【问题定位】

在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。

【解决措施】

需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。

2.6 Server Internal Error 500导致未接通

【问题描述】

在测试和分析过程中有时候会遇到Server Internal Error 500导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。

【问题分析】

1、 主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，

主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。

2、 然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放，去激活，

导致会话未接通。

12:09:18.389，基站下发TM8模式转换的重配消息，如下图：

该消息一直未发出，在12:09:25.089秒出现错误的标示，原因是该重配未下发，达到最大重传次数。

【问题定位】：

经过分析，该问题是由于A2测量上报后发送的测量控制消息和TM3/8模式切换的重配消息时间间隔太近，导致基站控制面提前通知底层TM模式切换程序，切换到下行发送模式，后果就是TM3/8模式切换的重配消息是使用TM8模式发送的，而此时UE还工作在TM3状态，导致UE无法正确解调模式切换消息。

【解决措施】：

该问题已经在新版本解决，目前规避措施是改为强制TM3模式。

3.6 eSRVCC至2G后掉话

【问题描述】

主被叫正常通话后，主叫或被叫成功ESRVCC至2G后，在2G出现掉话。 【问题分析】

主被叫通话正常后，主叫在上报B2测量报告后，随后收到系统下发的Mobility from Eutran command消息指示终端进行esrvcc切换至2G，主叫回复handover complete后随后占用2G进行通话。

随后在占用2G通话后，主叫所占用的2G信号逐渐变差，邻区存在较强信号可以接入，终端不断上报测量报告但未发生切换，最终无线环境逐渐恶化出现连续7级质差，网络下发RR channel release释放连接导致掉话。

【问题定位】

造成此次通话原因在于终端邻区存在最优接续小区，在上报MR测量报告后未能及时切换，最终拖死造成无线环境极差导致掉话。 【解决措施】

需要优化2G网络邻区关系，优化2G网络切换关系。

3.7 eSRVCC失败导致掉话

【问题描述】

主叫或被叫在esrvcc失败后，恢复4G通话失败导致掉话。 【问题分析】

主被叫正常接通后，在通话过程中，主叫上报B2测量报告后，随后收到系统下发的Mobility from Eutran comman和RR handover command消息，但终端未正常回复handover complete，esrvcc失败返回4G重新发起INVITE请求希望能恢复4G通话，正常情况下网络收到INVITE请求，回复100trying后，并发起专载修改流程后，下发INVITE200就可回复通话，但主叫在发起INVITE

请求，随后发起RRC重建，重建失败后返回空闲态并重新发起rrcconnection request，在终端上报rrc connection setup complete后系统下发rrc connection release,终端无法建立rrc连接，未能进入连接态接受100try等SIP信令恢复承载，连续出现多次rrc连接建立后网络侧又释放rrc连接，由于长时间未能恢复承载通话结束造成掉话。

【解决措施】

需要查看2G核心网是否支持ESRVCC功能，核查4G小区站点是否存在故障导致无法接入，优化4G网络覆盖情况。

3.8 设备故障导致掉话

【问题描述】

终端在12:03:37 092 再发出INVINT，而且连续上发2次invite后，才收到核心网下发的上一次的BYE消息后导致掉话。 【原因分析】 具体如下图所示：

在12:03:23 259 发出INVINT后，被叫SIP信令流程正常，主叫信令缺失，后被叫未收到BYE,终端在12:03:37 092 再发出INVINT主叫信令缺失，但是，被

叫SIP信令正常，被叫接通后，就改为主叫进行拨测，而且连续上发2次invite后，才收到核心网下发的上一次的BYE消息，导致本次通话掉话。 【解决措施】

更换终端进行验证测试。

3.9 核心网问题掉话

【问题描述】

主被叫11:58:44都正常收到BYE回复后，,主叫叫收到BYE 200信令随后拆除承载，但被叫在收到BYE 200回复后，11:58:49在间隔5s后还没有拆除承载后导致掉话。

【原因分析】

主被叫11:58:44都正常收到BYE回复后，,主叫叫收到BYE 200信令随后拆除承载，但被叫在收到BYE 200回复后，11:58:49在间隔5s后还没有拆除承载后导致掉话。 【解决措施】

需要爱立信核心网根据问题的描述列表以及终端Log进行分析确认，若有疑问，可以和中兴无线人员联合分析

4 指标提升

4.1 网格19指标优化

网格19 经过了4轮优化，主要通过梳理了27个小区切换关系，添加处理了12对4到2G邻区关系，核查2 告警小区，通过对功率调整3个小区增强道路覆盖，3个小区B2门限调整esrvcc切换，网格19优化指标如下：

测试日期网格平均RSRP平均SINRRSRP>-110且SINR>-32015/4/282015/5/132015/5/232015/6/919191919-93.23-90.59-89.55-90.2313.5213.7214.0713.9286.30?.00?.57?.07%呼叫在LTE系统LTE系统呼叫在LTE系统内eSRVCCLTE接通LTE拨打掉话次内语音内语音LTE拨打掉话率语音切换切换成功成功率成功的数切换次切换成的次数成功率率次数数功次数85.71I4211.90Q00.00e765796.15?.61G446.8299.4564362100.00?.449382.6300.00w7777100.000.00D442.279.85e8657100.00% 1、RSRP优化前后对比

网格19 Volte区域内弱覆盖区域，由于塔工及相关资源不足无法调整天馈改善弱覆盖区域，区域内遍历道路优化前后RSRP平均信号覆盖强度相差不大。 2、SINR优化前后对比

网格19 Volte区域内弱覆盖区域，由于塔工及相关资源不足无法调整天馈改善弱覆盖区域，区域内遍历道路优化前后RSRP平均信号覆盖强度相差不大,覆盖无法优化导致SINR值无法有效提升。 3、掉话情况对比

网格19 Volte区域故障站点处理，以及对邻区添加和邻区优化等处理方式，网格19 Volte试点试点区域掉话次数5次，优化后掉话次数为1次，减少了4次。

4、未接通情况对比

网格19 Volte区域经过调整QCI5优先级、修改QCI5的pdch discardtimer以及邻区优化及门限优化，优化前后接通率有逐步提升。

5 总结

网格19经过一段时间的优化，从最近拉网测试数据可以看到，在相同网格的测试发现指标有稳步的提升，其中主要的优化手段包括： 1）

修改全网QCI 5信令优先级，提高SRB2的优先级来优先传送NAS信息，解决切换过程中专载被释放问题。 2）

修改全网CQI 5的discartimer：由300ms修改为无穷大，避免UE在无线信道较差的情况下，SIP信令在传递的过程中，发送或接收的数据不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancal。在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包，出现SIP乱流导致未接通，修改后该类问题基本解决。 3）

核查网格内站点基本参数配置情况，包括B2-1、B2-2、A1(10)、A2(20)、A2(30)、A2(32)等基本门限参数是否设置正常。 4）

eSRVCC优化，检查2G邻区准确性，增加异系统切换成功率。根据路网通2G测试数据与网格内4G站点匹配4到2G邻区关系，核查4到2G邻区关系是否配置正常，2G邻区参数是否配置正常，避免因2G翻频后邻区内参数未及时更新导致无法esrvcc导致的重定向掉话。

5） 核查网格内站点异频重定向关闭情况，对于未关闭异频重定向的站点通过DV表关闭系统内重定向开关，对某些邻区配置为不支持切换的小区，通过后台小区切换属性能力的核查，打开邻区切换功能，解决配置了邻区但没打开切换功能的重定向。

6） 现网版本暂时关闭TM3/8切换，避免因此类问题导致的掉话。 基础优化，包括覆盖优化、切换优化、邻区补漏、干扰排查等。

本文来源：https://www.bwwdw.com/article/koot.html