60惠州Volte接通率研究和经验总结.docx

60惠州Volte接通率研究和经验总结.docx

《60惠州Volte接通率研究和经验总结.docx》由会员分享，可在线阅读，更多相关《60惠州Volte接通率研究和经验总结.docx（30页珍藏版）》请在冰豆网上搜索。

60惠州Volte接通率研究和经验总结

Volte接通率研究和经验总结

2019年9月

【摘要】随着LTE快速发展，电信VoLTE已商用近一年；聚焦VOLTE的差异化优势、竞争力可比的要求，着重于给VoLTE用户提供“打得通”、“接得快”、“听得清”、“不掉话”的优势端到端感知体验。

用户对VoLTE高清语音需求将越来越大，伴随着网络规模的进一步扩大以及网络结构的日渐复杂，如何对VoLTE端到端问题进行优化及分析定位，总结VoLTE端到端问题优化处理经验，为VoLTE高清语音业务提供良好的使用感知。

【关键字】VoLTE、接通率

【业务类别】VoLTE

一、概述

随着Volte的不断放号，Volte用户不断增加，如何提升Volte接通率将至关重要。

本文将介绍Volte接通率优化方法以及惠州电信Volte接通率优化成果。

下图所示为Volte呼叫流程：

Volte接通率定义如下：

接通率：

呼叫建立成功次数/呼叫建立尝试次数

路测软件呼叫建立尝试次数定义：

主叫向IMS发INVITE消息。

路测软件呼叫建立成功次数定义：

主叫向IMS发INVITE消息后，主叫终端发送ACK消息。

二、Volte接通率分析思路

Volte接通率问题涉及到UE，EnodeB，EPS，IMS端到端网元，需要各个网元联合分析和定位具体原因。

Volte接通率分析思路如下图所示：

Volte端到端详细流程如下图所示，共涉及58个信令流程。

在出现未接通问题时，各网元出现异常问题表现如下表所示：

网元

分析数据源

问题表现

UE

测试数据

1、因空口质量问题或MME不发QCI1承载建立请求，导致终端TCALL或TQOS定时器超时，终端发CANCEL或发580资源预留失败错误码。

2、终端异常，直接发CANCEL消息终止呼叫。

3、终端在QCI1建立后，RRC异常释放，导致IMS相关定时器超时

4、终端收到IMS发的480、487、499、500、503等错误码，导致呼叫建立流程中断。

5、被叫终端未响应寻呼。

6、被叫终端响应呼叫发603消息终止呼叫。

eNodeB

虚用户跟踪信令

1、RRC异常释放，通过虚用户跟踪可看到RRC异常释放原因。

2、QCI5未建立，或QCI5承载建立失败。

3、MME未向ENODEB下QCI1承载建立请求。

4、QCI1建立失败。

5、QCI1承载被删除。

MME

MME侧单用户跟踪

1、MME和HSS的IDR/IDA（流程14、15）异常。

2、MME有没有向ENODEB发QCI5/QCI1承载建立请求。

3、QCI5/QCI1承载建立失败。

4、MME没有收到P/SGW发的CBRequest消息（流程27）。

5、MME释放QCI1承载。

P/SGW

PGW或SGW侧单用户跟踪

1、和PCRF的RAR/RAA交互流程异常（流程24/25）。

2、没有向MME发送CBRequest消息（流程27），导致QCI1承载无法正常建立。

3、向MME发送CBRequest消息后，没有收到MME回应的CBResponse（流程30）。

PCRF

PCRF侧单用户跟踪或抓包文件

1、和PGW的RAR/RAA交互流程异常（流程24/25）。

2、和P-CSCF的AAR/AAA交互流程异常（流程23/26）

IMS

P-CSCF单用户跟踪或抓包文件

1、和PCRF的AAR/AAA交互流程异常（流程23/26），导致QCI1承载无法正常建立。

2、收到终端发的CANCEL/580/603等导致呼叫中断的消息。

3、SIP信令流程异常，IMS等待终端发送SIP消息时间超时，发送CANCEL或480/499等错误码。

4、P-CSCF向PCRF发AAR，等待AAA消息超时，发送503错误码。

5、IMS内部异常，或取其它网元交互异常，发送500/503等错误码，导致呼叫中断。

测试

工具

测试数据

1、因测试暂停等原因，导致事件打点丢失。

2、软件异常导致事件打点乱序、错误、丢失。

三、接通率问题分析方法

分析VOLTE接通率，通过测试软件记录空口LOG，同时需要进行ENODEB、MME、P/SGW、PCRF、IMS多点信令跟踪，进行端到端问题分析。

3.1空口质量优化

通过路测软件记录空口数据，重点查看测试软件记录的SIP信令、RRC信令、NAS信令及表征空口质量的RSRP、SINR、BLER等指标。

分析方法如下：

1、查看主叫终端是否存在TCALL定时器超时的问题

终端TCALL定时器：

当主叫终端发出INVITE消息后，TCALL定时器开始计时，当主叫收到IMS下发的100TRYING消息后，定时器停止。

若该定时器超时，主叫终端发CANCEL消息。

2、接下来的分析思路如下：

①首先查看主叫终端发INVITE消息后，RRC是否未能正常建立或RRC建立后异常释放。

②RRC未能正常建立，看是否存在RSRP过低，上行干扰，PRACH功控参数设置不合理等问题。

③RRC建立后异常中断，看是否RSRP过低或SINR过低导致上行或下行失步导致RRC异常释放，如果空口质量无问题，需要查看ENODEB的虚用户跟踪，来判断RRC异常释放的原因。

3、若RRC建立成功且未正常释放的话，需要查看P-CSCF侧信令，看主叫终端发送的INVITE消息P-CSCF是否收到，P-CSCF是否发100TRYING。

①查看主被叫终端是否存在TQOS定时器超时。

TQOS定时器在主叫收到183SESSIONPROGRESS或被叫发送183SESSIONPROGRESS后计时，当主叫或被叫QCI1承载成功建立后停止计时。

若该定时器超时，主叫终端发CANCEL消息；被叫终端发580PRECONDITIONFAILURE消息，终止呼叫。

主叫VoLTE终端TQOS定时器超时异常流程：

被叫终端TQOS定时器超时异常流程：

4、接下来的分析思路如下：

①首先查看是否存在RRC异常释放。

若存在RRC异常释放，需要查看是否存在RSRP和SINR值偏低的空口质量问题，必要时结合虚用户跟踪判断RRC异常释放的原因。

5、RRC己建立，但终端未收到QCI1承载建立请求。

这有两种情况：

从虚用户跟踪或MME侧跟踪上，可以看到MME根本没有向终端发QCI1承载建立请求。

RRC已建立，但QCI1承载建立失败。

需要查看ENODEB虚用户跟踪和MME侧单用户跟踪来判断QCI1承载建立失败的原因。

6、查看终端在QCI1正常建立后，是否存在RRC异常释放，导致SIP信令中断，IMS相关流程定时器超时导致呼叫建立失败。

需要查看是否存在RSRP和SINR值偏低的空口质量问题，导致RRC异常释放，必要时结合虚用户跟踪判断RRC异常释放的原因。

这里要明确是RRC异常释放导致SIP信令中断还是SIP信令中断，不活动定时器超时导致RRC释放。

对于RRC异常释放导致SIP信令中断场景，一般是RRC异常释放在前，IMS发的错误码在后（或者终端中断时间过长根本收不到IMS发的错误码）。

而SIP信令中断，不活动定时器超时导致RRC释放，则必是终端或IMS发CANCEL或错误码在前，不活动定时器超时后，RRC才释放。

7、终端QCI1建立后又被EPC释放

终端QCI1建立后又被释放，可能是由本侧的呼叫异常导致的，也可能是对端的呼叫异常导致的。

通过查看测试软件或P-CSCF跟踪的SIP信令，如果是本端先发CANCEL、580PRECONDITIONFAILURE，或先收到IMS发的错误码的话，则认为呼叫建立失败是本端引起的，否则呼叫建立失败可能是由对端引起的。

8、被叫不响应寻呼

被叫不响应寻呼导致主叫出现的未接通，这个场景产生原因是IMS将INVITE转给被叫后，无法得到被叫回应，IMS超时释放呼叫，根因是终端问题。

9、终端问题或异常操作导致未接通

①主叫终端异常终止呼叫

如下图，终端在发送INVITE消息后马上发CANCEL，并且连续多次，明显是终端异常导致。

注意该问题要和主叫TQOS定时器超时现象要区分开。

主叫TQOS定时器超时一定是183SESSIONPROGRESS后，QCI承载未建立，主叫发CANCEL。

②呼叫未建立前，被叫终端终止呼叫

如下图，MS2是主叫，MS1是被叫。

被叫在未摘机前就主动挂机，上报603DECLINE消息。

③主叫拨打被叫，被叫正在响应其它呼叫

如下图，MS2是主叫，MS1是被叫。

07：

58:

11.092，MS1呼叫MS2，但实际上MS2正在拨打另外一个电话。

MS2收到IMS发送的INVITE消息，发486BUSYHERE消息。

3.2ENODEB侧问题分析

IMS信令流程对ENODEB是透传的，我们一般通过ENODEB侧的虚用户跟踪，来判断RRC和QCI1承载、QCI5承载未建立或建立失败的原因。

1、判断终端侧和ENODEB侧信令交互是否正常

将终端侧信令和ENODEB信令做对比，是否存在终端侧发的信令，ENODEB侧未收到，或反之的情况。

如终端发多条A3测量报告，但没有触发切换，这时就要通过虚用户跟踪看测量报告消息ENODEB侧有无正常收到，ENODEB侧有无正常发RRC重配置消息。

2、通过虚用户跟踪判断RRC释放原因

在ENODEB发RRCCONNECTIONRELEASE消息前，会向MME发送UECONTEXTRELREQ消息，其中带有RRC释放的原因，如下图RRC释放的原因为USERINACTVITY（UE不活动定时器超时）

3、通过虚用户跟踪看QCI1、QCI5承载是否正常建立

如果在QCI1承载建立时，ENODEB已经收到MME发送的ERABSETUPREQUEST，但终端侧没有收到ActivateDedicatedEPSBearerContextRequest的话，说明QCI1承载未建立可能为空口原因。

如果ENODEB根本就没有收到MME发送的ERABSETUPREQUEST的话，则说明QCI1未建立和MME未发承载建立请求相关，和空口问题不大。

如下图，起呼RRC建立后MME没有发QCI1承载请求。

下图为MME发送QCI1承载请求的信令，消息内容中可以看到ERABID为7，QCI为QCI1。

3.3MME侧问题分析

MME侧信令跟踪重点关注如下两个流程：

1、HSS和被叫方MME的IDR/IDA（流程14、流程15）是否正常

HSS应向被叫方MME发送Insertsubscriberdatarequest（IDR）消息，MME应回Insertsubscriberdataanswer消息

2、QCI1/QCI5承载建立是否正常。

其中包括MME和P/SGW、ENDEB和终端的交互。

P/SGW向MME发送Createbearerrequest消息，MME向P/SGW回Createbearerresponse消息。

下图为Createbearerrequest的信令详细内容，LABEL-QCI信元显示是请求哪种QCI的承载。

MME向ENODEB发送E-RABsetuprequest消息，ENODEB向MME回E-RABsetupresponse消息。

MME向UE发送ActivatededicatedEPSbearercontextrequest消息，UE向MME回ActivatededicatedEPSbearercontextaccept消息。

下图为一个通话正常的流程，HSS首先和被叫方MME进行IDR/IDA流程，然后P/SGW向MME发送Createbearerrequest消息，启动QCI1承载建立流程。

下图为一个通话异常的场景，MME和HSS进行IDR/IDA流程（流程14、15）交互后，P/SGW未向MME发送Createbearerrequest消息，导致QCI1承载未建立。

3.4P/SGW侧问题分析

P/SGW信令跟踪应重点关注如下流程是否有异常：

1、P/SGW与PCRF的RAR/RAA流程（流程24、25）是正常。

该流程异常会导致QCI1承载无法建立。

PCRF根据认证/授权请求消息AAR消息中携带的媒体类型和媒体描述信息做策略决策，提供授权的QoS，并通过重新认证/授权请求消息RAR消息将QoS（QCI/ARP/GBR/MBR）和PCC规则发送至P-GW；P-GW_B收到重新认证/授权请求消息RAR，上报重新认证/授权应答消息RAA响应给PCRF_B。

RAR消息的关键信元如下图：

2、P/SGW和MME交互的CBREQUEST和CBRESPONSE流程是否存在异常（流程27、30）

在P/SGW与PCRF完成RAR/RAA流程（流程24、25）交互后，P/SGW向MME发送Createbearerrequest消息要求建立QCI1承载，MME向P/SGW回Createbearerresponse消息，表示QCI1承载已完成。

3.5PCRF侧问题分析

PCRF网元信令交互重点关注两点：

1、PCRF和PGW网元的RAR/RAA流程（流程24、25）是否正常

PCRF根据认证/授权请求消息AAR消息中携带的媒体类型和媒体描述信息做策略决策，提供授权的QoS，并通过重新认证/授权请求消息RAR消息将QoS（QCI/ARP/GBR/MBR）和PCC规则发送至P-GW_B；P-GW_B收到重新认证/授权请求消息RAR，上报重新认证/授权应答消息RAA响应给PCRF_B。

RAR/RAA流程流程异常，会导致QCI1承载无法正常建立。

2、PCRF和P-CSCF的AAR/AAA流程（流程23、26）是否正常

P-CSCF收到被叫侧返回的183（SDP）后，下发认证/授权请求消息AAR消息给PCRF_B开始建立专有承载。

AAR包括用户的信令地址、媒体带宽等信息；PCRF根据P-GW返回的重新认证/授权应答消息RAA消息，向P-CSCF发送认证/授权应答消息AAA响应授权请求结果。

3.6P-CSCF侧问题分析

拿到P-CSCF侧单用户信令，主要从两方面进行分析：

1、查看P-CSCF与PCRF的AAR/AAA流程是否异常

P-CSCF与PCRF的AAR/AAA流程用于QCI1承载的建立或修改。

P-CSCF将用户的信令地址、媒体带宽等信息通过认证/授权请求消息AAR消息发送给PCRF，通知PCRF建立专有承载。

从AAR消息中的内容可以看到终端的IP地址，可以据此判断该AAR消息是用于主叫的QCI1承载建立或修改，还是被叫侧的。

PCRF_B向P-CSCF_B发送认证/授权应答消息AAA响应。

从消息内容中，可以看到流程是否成功，如下图：

2、P-CSCF侧信令和路测软件侧SIP信令做对比，判断SIP流程异常原因

首先观察终端发送的SIP信令，P-CSCF是否正常收到，或P-CSCF发出的信令，终端有无正常收到,通话SIP信令流程在哪一步存在信令缺失或异常。

第二看IMS是否发送错误码，导致呼叫建立失败，根据错误码来判断呼叫建立失败原因。

一些常见错误码列举如下：

1、487RequestTerminated，IMS在发现异常（出现CANCEL消息或其它错误码）后用487RequestTerminated终止呼叫。

2、481Call/TransactionDoesNotExist，IMS收到UE发送消息后，发现呼叫已不存在，发此错误码

3、480TemporarilyUnavailable，IMS长期得不到UE响应，相关定时器超时发此错误码。

4、486BUSYHERE，当成功联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话（如正在或其它呼叫业务），发此错误码。

5、500ServerInternalError，服务器遇到了未知的情况，并且不能继续处理请求，一般为IMS内部问题或和其它网元交互异常。

6、503ServiceUnavailable，服务不可用，一般为IMS内部问题或和其它网元交互异常。

7、603Decline，寻呼到被叫后，被叫在摘机前终止此次呼叫，一般发此错误码。

四、经典案例

4.1183消息响应超时导致Volte未接通处理总结

【问题描述】

在江北对VoLTE拉网例测中，发现在惠州大道云山花园段距离云山花园站点200米处，出现一次未接通，位置如下图所示：

【问题分析】

Volte呼叫建立过程涉及SIP信令交互，SIP信令交互基本是串行进行，前面的信令没有走完，会导致后面的信令无法进行，如果某一信令流程超时就会造成未接通。

下图为VolteSIP信令交互过程，针对未接通问题，下一步将排查是否存在信令流程超时情况。

✓主被叫信令流程分析

下图可以看出被叫发送三次183消息，均未收到主叫的PRACK响应，导致UE超时并发送ServerInternalError500，造成网络侧去激活被叫的QCI1，造成未接通，下一步将主被叫联合分析。

下图所示主叫响应了被叫的第一次183消息，主叫发送了2次PRACK，被叫均未收到。

正常情况下，主叫应该发送3次PRACK，怀疑第三次PRACK未被分析软件解析出，同时被叫也未收到第三次PRACK，需进一步分析，主叫发送三次PRACK时上行信道质量是否正常，被叫在接收时段，下行信道质量是否正常。

下图所示主叫发送3次PRACK时的上行MCS均正常，对应时间段被叫SINR均小于0dB，被叫下行信道质量较差导致被叫未收到主叫发送的PRACK，需要分析优化。

下图所示为被叫预计第一次接收PRACK时干扰情况，此时SINR为-1.4dB，HZHC_D电信实业室外FLRRU02干扰较大需要优化。

下图所示为被叫预计第二次接收PRACK时的干扰情况，此时SINR为-6.3dB，HZHC_D江北双子星大厦室外FLRRU01干扰较大，需要优化。

下图所示为被叫预计第三次接收PRACK时的干扰情况，此时SINR为-6.4dB，可以看到干扰小区较多，需要根据周边覆盖情况进行优化。

对问题区域进行整体分析，问题区域RSRP在-85dBm至-100dBm波动，SINR在-15dB至-10dB之间波动，该区域存在3个主导频，建议根据实际无线环境确定主控小区和切换带，减少频繁切换提升SINR。

【优化效果】

增加HZHC_D云山花园云华阁室外FLRRU03小区下倾角至8°，增加HZHC_D电信实业室外FLRRU03小区下倾角至6°，调整HZHC_D云山花园云华阁室外FLRRU03小区方位角至250°。

优化后问题区域SINR由-1.2dB提升至11.3dB，多次测试无未接通。

【推广价值】

针对未接通问题，需要按照信令流程一步步排查，定位问题子流程，再分解影响子流程的因素，逐个排查每个因素，最终确定问题根因。

4.2TAU更新和QCI1建立冲突问题处理

【问题描述】

在金湖路附近，HZHC_D张屋山室外FLRRU02小区（TAC:

31745）向HZHC_D上马庄新址室外FLRRU03小区（TAC31747）主叫发生X2切换后，收到RRC重配置消息携带QCI1建立消息，终端答复RRC重配置完成后，发起TAU，TAUrequest消息EPSbearercontextstatus消息包含3个承载，但是TAUaccept的EPSbearercontextstatus只有2个承载，TAU结束后，终端发上行直传消息，消息内容为ActiveDedicatedEPSBearerContextAccept，但是由于和TAU冲突，MME认为QCI1没有建立成功。

【问题分析】

正常的QCI1建立流程如下，MME下发E-RABSetupRequest消息给eNB，eNB下发包含QCI1建立的RRC连接重配置消息给UE，UE回复RRC重建完成消息给eNB，通知QCI1建立完成，eNB发送E-RABSETUPRESPONSE消息通知MMEQCI1建立完成，UE还会发一条上行直传消息通知MMEQCI1承载激活成功，MME收到这两条消息会继续QCI1建立流程。

主叫X2切换成功后，收到QCI1建立消息，并且答复了RRC重建完成。

终端后续没有立即发送包含QCI1承载建立完成的上行直传消息，而是发送TAURequest的上行直传消息，并且认为QCI1已经建立成功，显示有3个EPS承载。

MME因为没有收到终端发的激活QCI1承载接收的上行直传消息，认为QCI1没有建立成功，TAUAccept里只包含2个EPS承载：

实际上TAURequest之前MME已经收到了eNB给发送的ERABResponse消息，只是没有收到终端发的激活QCI1承载接收的上行直传消息，而eNB已经收到RRC连接重配置完成消息，并且发送ERABResponse消息给MME，终端和eNB都认为QCI1承载已经建立，但是MME认为QCI1承载没有建立：

22:

34:

38.026eNB给MME发送ERABresponse，表示QCI1建立成功

22:

34:

38.07MME收到UE发的TAU请求

TAU结束后，UE才发送上行直传消息，包含QCI1激活成功消息：

22:

34:

38.095MME收到UE发送的QCI1激活消息

MME认为必须eNB和UE消息的RRC重配置完成和激活QCI1承载接受的上行直传消息都收到了，才会在createbearerresponse里才会回复成功。

但是eNB收到RRC重配置完成就会认为QCI1建立成功。

后续MME再次发起QCI1建立消息，eNB因为已经存在QCI1承载，答复失败，原因：

MultipleE-RABIDinstances

按照协议规定MME和eNB的行为都是正确的：

eNB已经收到UE回的eRAB=7的QCI1的承载建立消息，所以再收到MME下发的E-RABSETUPREQUEST要求建立eRAB=7的QCI1承载时，答复MultipleE-RABIDinstances。

协议23.401规定，MME必须收到eNB和UE的两个消息，才认为承载建立。

【优化效果】

该问题的根本原因是UE发送QCI1建立的RRC重配置消息后没有立即回激活QCI1的上行直传消息给MME，而是先发送了TAU消息，导致eNB和MMEQCI1承载建立状态不对称。

eNB和MME实现都符合协议，也没有好的规避措施，需要推动终端解决：

方案一：

UE发送QCI1建立的RRC重配置消息后，先发送激活QCI1的上行直传消息给MME，在发送TAUrequest。

方案二：

UE收到eNB下发的建立QCI1的RRC重配置消息，不要响应，发送完TAU后，等待MME再次执行QCI1建立流程。

【推广价值】

在VoLTE优化过程中一定要重点关注终端匹配问题。

五、经验总结

进行Volte接通率优化时，先确认呼叫失败类型，再根据呼叫失败类型和信令跟踪，进行端到端异常流程定位，最终确定未接通根因，给出解决方案。