60惠州Volte接通率研究和经验总结.docx
《60惠州Volte接通率研究和经验总结.docx》由会员分享,可在线阅读,更多相关《60惠州Volte接通率研究和经验总结.docx(30页珍藏版)》请在冰豆网上搜索。
![60惠州Volte接通率研究和经验总结.docx](https://file1.bdocx.com/fileroot1/2023-6/28/cfcfaf1f-c745-4b7a-923d-5f4f0b40c4e4/cfcfaf1f-c745-4b7a-923d-5f4f0b40c4e41.gif)
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接通率优化时,先确认呼叫失败类型,再根据呼叫失败类型和信令跟踪,进行端到端异常流程定位,最终确定未接通根因,给出解决方案。