VOLTE关键性能指标优化

VOLTE关键性能指标优化第1页/共37页内容提要VOLTE接通率VOLTE掉话率RRC重建优化呼叫建立时延和MOS优化第2页/共37页接通率-定义和信令流程接通率定义:成功完成呼叫次数/终端发起呼叫总数。处于RRC空闲态的终端由于有业务要传输，将首先发起ServiceRequest流程，回到RRC连接态，然后发送SIPINVITE消息建立会话连接。第3页/共37页接通率-RRC连接成功率优化RRC连接不管是主叫发起INVITE后还是被叫收到PAGING,首先需要上行同步并经过PRACH\PUSCH\PDSCH几个信道的信令传输,最后有相关定时器控制,因此可能导致RRC连接失败的原因:1、上行底躁影响，下行SINR质量2、信道功率影响3、T300定时器时长4、EUTRAN异常、时钟告警、GPS问题优化手段：1、干扰排查，无线环境优化2、功率优化3、增大T300定时器时长4、站点排障，多为RRU问题、时钟告警第4页/共37页接通率-SIPINVITE消息建立优化注意事项：1、主被叫信令交互都是通过IMS完成的2、CSFB实际也是VOLTE未接通3、寻呼机制4、起呼过程中主/被叫RL失败导致RRC重建5、流程冲突，比如起呼后收到上一通专载去激活/RRC连接释放等。6、起呼过程中发生切换导致未收到激活专载请求优化手段：1、RL失败无线环境优化（RSRP，SINR）2、协助核心网/IMS抓LOG定位和解决问题3、协商过程中不支持VOLTE，检查终端支持情况4、手机注册VOLTE失败，检查SIM卡数据权限5、被叫TAU，TAC合理规划和TALIST引入网元定位：IMS：SIP信令转发过程中在IMS侧出现问题EPC：1、在建立专载过程中出现问题且从TRACE信令分析问题出在EPC无线空口：RRC连接、切换、基站故障等且因无线出现问题（上行底躁大、下行SINR差等）根据跟踪的信息定位问题是否出现在ENODEB，联合分析。终端：信令分析中是否终端侧信令丢失或有段时间无信令或信令在发往终端后出现问题软件：因软件原因在测试过程中流程冲突，比如通话过程中主叫起呼被叫等。人为或设备丢失：起呼过程中不小心挂机或被叫手机连接出现问题等第5页/共37页案例:EPC

现象描述:UE2占用844199PCI：69，RSRP=-97SINR=7，收到主叫INVITE呼叫建立流程走到被叫上发180ringing，网络层未下发ModifyEPSBearerContextRequest，同时终端在做A3切换（目标小区417950PCI:61），可能网络侧发送ModifyEPSBearerContextRequest到源小区导致终端切换到目标小区收不到。20s网络侧返回503ServiceUnavailable，主叫callblocked。问题分析:无线分析:可能ModifyEPSBearerContextRequest发到源小区，同时终端发起A3请求切换到目标小区导致软件判断未接通。IMS分析:IMS发的503响应由PCC侧发的ASR消息触发，一般ASR是EPC侧发的EPC分析:MME下发给UEModifyEPSBearerContextRequest给源enodeB,UE没有响应且后继才发生切换导致:问题处理:

起呼过程中发生切换，UE已经切换至目标小区，核心网继续发专载建立至源小区，导致UE根本就无法收到核心网下发的建立专载，待后续核心网优化在volte呼叫过程中切换，最后向目标小区加发一条建立专载第6页/共37页问题描述：福建移动进行VoLTE语音呼叫路测时，发现被叫终端在LTE重新附着后，偶尔存在SAEGW不发送Downlinkdatanotification给MME的情况，造成部分SIP消息丢失，常见为SIP-INVITE消息不能转发到被叫终端，最终导致呼叫失败。问题定位：在分析现网采集到的VoLTE呼叫失败记录中，我们发现SAE-GW一个已知问题会引发SAE-GW丢弃SIP消息的场景：LTE附着后S-GW收到IMS下行数据包时没有立即触发DDN（DOWNLINK_DATA_NOTIFICATION）流程，具体场景如下：1）LTE附着时创建CMNET默认承载（EBI-5）;2）VoLTE终端发起IMSAPN的PDN连接（IPv6地址）建立第二个默认承载（EBI-6）；3）为完成IPv6地址分配，P-GW需要向终端侧发送IPv6RouterAdvertisement消息，由于发送该下行数据时，EBI-6还没激活（Modify_Bearer_Request消息尚未收到），所以S-GW置位寻呼标志（EBI-5和EBI-6）及启动寻呼时长（60s）；4）S-GW在EBI-6收到Modify_Bearer_Request消息，清除EBI-6的寻呼标志，下发IPv6RouteAdvertisement消息后，eNB释放无线连接（收到Release_Access_Bearer_Request），但此时EBI-5的寻呼标志还在置位。（改进2）5）当SIP下行数据（例如被叫侧第一个SIP消息-INVITE）到达时，缓存指示会触发寻呼流程（发起DDN请求），但由于此时EBI-5的寻呼标志尚未清除（寻呼定时器未超时），所以S-GW不会发起新的寻呼请求，导致SIP消息因缓存溢出而丢失。（改进1）6）直到S-GW的寻呼定时器超时后，S-GW才会真正发出DDN请求以下发SIP下行数据。解决方案：经过安装新补丁，SAE-GW在上述步骤4和5的处理机制中作了改变，即:改进1）当S-GW上缓存指示触发寻呼流程时，将清除寻呼指示并终止寻呼定时器，以保证S-GW可以触发DDN消息；改进2)当收到Release_Access_Bearer请求消息时，S-GW将重置寻呼标志。SAE-GW上安装了补丁实现了上述S-GW寻呼机制改进。案例:EPC

第7页/共37页MMEpaging机制现网MMEpaging机制：第一次PSpaging后如未收到响应，每隔4s重复一次，共重复两次(间隔8s)；如仍未收到响应则通过SGs接口开始请求CSpaging。通常终端未收到PSpaging后会在10s-12s左右收到Cspaging开始进行CSFB。第8页/共37页案例:终端

信令流程分析：S1ap消息跟踪MME已将s1paging下发到正确eNBEmil消息跟踪eNB已收到s1paging并将rrcpaging通过空口发向被叫UEUElog显示被叫终端未收到eNB下发的paging消息pagingnoresponse终端未收到pagingRrcpaging终端问题，已通过HTC终端补丁解决第9页/共37页内容提要VOLTE接通率VOLTE掉话率RRC重建优化呼叫建立时延和MOS优化第10页/共37页掉话率-定义和涉及流程掉话率定义为：掉话次数/成功建立呼叫次数通话保持过程中会出现切换和ESRVCC。通话结束后主叫上发BYE，收到网络BYE200，后去激活专载，最后RRC连接释放。第11页/共37页掉话率-原因分析和优化措施掉话出现原因：切换出现问题/ESRVCC出现问题；上/下行无线链路失步导致RRC重建；非正常去激活承载QCI1或QCI9；非正常上发BYE；

BYE后流程问题；通话过程中主叫起呼被叫

IMS周期注册其他；优化措施：EPC/IMS：1、非正常去激活承载QCI1或QCI9，非正常上发BYE；BYE后流程问题；IMS周期注册无线空口：RRC连接重建、切换、基站故障等引起的问题（上行底躁大、下行SINR差等）软件：因软件原因在测试过程中流程冲突，比如通话过程中主叫起呼被叫等。设备丢失：MOS丢失等。第12页/共37页问题1描述：在跨厂家区域做切换验证，从诺基亚到中兴切换都成功，中兴小区(PCI=29)到诺基亚小区（PCI=264），切换均失败，原因为网路侧配置错误。问题1定位：如下图所示的信令，当UE驻留在PCI29小区时，该eNB为UE配置的AntennaInfo参数为AntennaInfo-r10格式：当UE切换至诺基亚小区PCI=264的时候，eNB下发给UE的重配置消息中的AntennaInfo字段为AntennaInfo格式（即r8格式），而不是一个完整的配置，如下图信令：案例:切换掉话

UE对收到的切换命令进行检查时，发现对antennaInfo参数的配置不正确而导致切换失败，从而触发RLF。解决方案：9月中旬外场升级了基站版本。升级后用高通终端验证室内外切换均正常。第13页/共37页案例:异常RRC连接释放

问题描述：被叫UE占用PCI：61，收到来自主叫的BYE后,回BYE200,紧接着发生切换,1S后RRC连接释放.问题原因：

1、为什么被叫收到BYE后1S在没有回复去专载接收情况下，网络又下发RRC连接释放。处理进展：已抓取LOG，定位中第14页/共37页案例:IMS注册引起掉话

现象描述:UE2占用988419PCI：323，异常发起IMS注册请求，导致无法走IMSSIP通话流程，导致主叫掉话。问题分析:无线侧分析:无线RSRP:-80dBm,SINR:17以上，无线服务质量良好，怀疑IMS问题IMS分析:手机问题，网络侧设置注册周期为3600s，手机到了注册周期仍未完成注册导致IMS强行释放当前VOLTE呼叫,IMS侧信令:问题处理:

正常情况下，终端会在注册周期前完成注册，或者注册不应影响正在进行的本次通话，联系终端厂家,待终端厂家解决第15页/共37页案例:异常去激活QCI9

问题分析：发生这个问题是因为UE建立了两个承载,一个为ipv4承载给正常上网用的，另一个是ipv6承载，这个ipv6承载是无法上ipv6网(因为没有对接ipv6

骨干网),UE得到的ipv6地址与其他UE有冲突触发UPCC删除这个多余的ipv6承载，这个不会影响正常业务(IPV4的承载还在)。另外不是所有的UE都会建两个承载，和UE的终端类型有关，当前大部分的终端都只是建一个ipv4承载。刚也和测试人员陈斌电话确认，这种现象不影响正常上网。核心网可以根据测试号只让ue建立ipv4承载,如果只是为了测试的话，可以按这个方案先规避。

现象描述:UE1通话过程中接收来自网络数据业务寻呼，去激活QCI9，但是无BYE上报，还是在通话结束后上发BYE，不影响用户感知。第16页/共37页内容提要VOLTE接通率VOLTE掉话率RRC重建优化呼叫建立时延和MOS优化第17页/共37页RRC重建-RRC重建触发时机RRCsecurityactiveRRC重建只能由已经激活了接入层安全算法的UE触发（时间点如右图所示），在此之前UE只能回到RRC_IDLE状态，触发小区重选和TAU；现网有不少ERAB建立过程中收不到securitycommandcomplete消息导致ERAB建立失败，这种情况下，无法进行RRC重建，网络会记为无线掉线，LTE_5004a指标也会恶化，如下图所示：第18页/共37页RRC重建-触发条件RRC重建只能由UE触发，可能的触发条件有以下几种：UE发现上行无线链路失败T310expiryasresultofout-of-syncproblemscontrolledbyn310(LNCEL),n311(LNCEL),

t310(LNCEL)uponrandomaccessproblemindicationfromMACuponindicationfromRLCthatthemaximumnumberofretransmissionshasbeenreached切换失败handoverfailureduetot304expiryforintraLTEHOcontrolledbyt304IntraLte(LNCEL))mobilityfromE-UTRAfailureduetot304expiryapplicableforinter-RAThandovertypes;controlledbyt304InterRAT(LNCEL)forPSHOandSRVCCtoWCDMA,t304InterRatTd(LNCEL)forPSHOtoTD-SCDMA;t304InterRATGsm(LNCEL)

forSRVCCtoGSM,t304eNaccGsm(LNCEL)

foreNACCtoGSM)其他原因integritycheckfailureRRCconnectionreconfigurationfailure关掉Nokia一些私有下行无线链路失败检测的方法，并不能减少RRC重建的触发第19页/共37页RRC重建-请求的原因分类3GPPTS36.331规定RRC重建请求消息reestablishmentCause

字段有以下分类：ifthere-establishmentprocedurewasinitiatedduetoRRCreconfigurationfailure(i.e.,theUEisunabletocomplywiththereconfiguration),UEsetsthereestablishmentCausetothevalue'reconfigurationFailure‘ifthere-establishmentprocedurewasinitiatedduetointra-LTEhandoverfailureorinter-RATmobilityfromEUTRAfailure,UEsetsthereestablishmentCausetothevalue'handoverFailure'OtherwiseUEsetsthereestablishmentCausetothevalue'otherFailure‘.NOTE:ThisincludesT310RLFfailure.Nokia定义了以下几种RRC重建请求的类型：M8008C4RRC_CON_RE_ESTAB_ATT所有重建请求M8008C6RRC_CON_RE_ESTAB_ATT_HO_FAIL对应规范handoverFailureM8008C8RRC_CON_RE_ESTAB_ATT_OTHER对应规范otherFailure暂定reconfigurationFailure=M8008C4-M8008C6-M8008C8，以厦门网络为例：

otherFailure占大部分，

handoverFailure有一定比例，

reconfigurationFailure非常少，几乎可以忽略不计。第20页/共37页RRC重建-比例优化重建比例定义为：RRC重建请求次数/RRC建立请求次数重建比例劣化小区：重建比例高于5%RRC重建本质上是由无线质量差引起的，无线环境优化是关键，任何参数优化都不可能使无线环境变好RRC重建比例相关参数优化，具体见后面4页胶片：随机接入过程优化，可以改善切换失败以及其他随机接入失败导致的RRC重建；上行无线链路失步相关参数优化；切换定时器t304优化；上行RLC最大重传次数优化；第21页/共37页1.RLFduetoT310expiryatUEForUE“normaloperation”inthefigureabovemeans:UEnotwaitingforRRCConnectionSetup/Reject(T300notrunning)UEnotwaitingforRRCRe-establishmentEstablishment/Reject(T301notrunning)handovernotongoing(T304notrunning)NoRLFrecoveryongoing(T311notrunning)n310consecutiveout-of-syncindicationsn311consecutivein-syncindicationsduringt310RRCconnectionre-establishmentattemptedduringt311CellreselectionandTrackingAreaUpdateifRRCRe-Establishmentfails减少此类RRC重建：上行失步检测条件更严格，恢复更容易RRC重建-原理1第22页/共37页2.RLFduetomaximumULRLCreTxreachedfromRRCConnectionReconfiguration:drb-ToAddModListdrb-ToAddModListvalue1drb-Identity :1rlc-Configamul-AM-RLCt-PollRetransmit :ms40pollPDU :p32pollByte :kB25

maxRetxThreshold :t8RLCretransmissionsuntilmaxRLCretxthresholdisreachedRRCconnectionre-establishmentattemptedduringt311CellreselectionandTrackingAreaUpdateifRRCRe-Establishmentfails减少此类RRC重建：增加ULRLC最大重传次数maxRetxThreshold增加最大HARQ重传次数harqMaxTrUl，可以减少RLC重传次数Vendor参数：<pname="drbAmMxRtxTh">16</p>RRC重建-原理2第23页/共37页3.RLFduetonon-HOrandomaccessfailureExample:RandomAccesstriggeredduetomissingPUCCHSRresources,orPDCCHorderRRCconnectionre-establishmentattemptedtoservingcellduringt311CellreselectionandTrackingAreaUpdateifRRCRe-EstablishmentfailsUEattemptingrandomaccesstoservingcell.RACHfailure“Non-HOrandomaccess”meansPDCCHorder-triggeredRA(RL30/RL25)RandomAccessSchedulingRequest减少此类RRC重建：增强随机接入过程的鲁棒性RRC重建-原理3第24页/共37页4.RLFduetoHOfailurefromRRCConnectionReconfiguration:mobilityControlInfotargetPhysCellId :33

t304 :ms1000newUE-IdentityBin :14EB(=5355)RRCConnReConfwithMobilityInfo(”HOcommand”)RRCconnectionre-establishmentattemptedtosourceortargetcellduringt311CellreselectionandTrackingAreaUpdateifRRCRe-EstablishmentfailsT304runningwhileUEattemptingaccesstotargetcell.T304expires减少此类RRC重建：增加t304；增强非竞争随机接入过程的鲁棒性RRC重建-原理4第25页/共37页UEeNBRRCConnectionReestablishmentRequest(Msg3)RRCConnectionReestablishment(Msg4)RRCConnectionReestablishmentComplete(Msg5)PRACHRandomAccess(Msg1)PRACHRandomAccessResponse(Msg2)随机接入Cellselectionprocessacc.to36.304RLF,HOfailure,mobilityfromE-UTRAfailure,integritycheckfailure,RRCconnectionreconfigurationfailuredetectedRRC重建RRC重建-劣化小区分析3GPP规定UE发起RRC重建的目标小区必须是拥有UE上下文信息的小区，因此RRC重建的目标小区有以下要求：FornohandoverprocedureongoingservingcellForongoinghandoverproceduresourcecell（切换过程取消）targetcell（切换过程完成）UE发起RRC重建的目标小区，很可能不是符合条件的目标小区：发生RRC重建的场景一般在无线比较差，小区边界或者信号杂乱的地方；无线失步或者切换失败后，UE首先要进行小区选择，选择合适的小区驻留，这种情况下，驻留的小区可能是不符合条件的小区；如果目标小区不符合条件，RRC重建会被拒绝掉，有时候符合条件的目标小区如果已经释放UE上下文信息，这时RRC重建请求也会被拒绝掉，厦门现网RRC重建拒绝比例接近40%。第26页/共37页RRC重建-终端异常情况个别终端如中兴MF91S2对DRX支持有问题，会导致短时间出现大量的RRC重建，日常指标监控，如果发现有短时间大量RRC重建统计，需要分析是否是终端原因引起的：关闭DRX后RRC重建是否大幅减少？如果判断是终端不支持DRX，在不关闭DRX情况下，打开上行预调度可以减少，终端进入DRX休眠，改善RRC重建比例；LTE815上行预调度打开的影响：ULresourcesareassignedwithasufficienthighfrequencyandUEcannotbetransitedintoDRXSleepasDRXInactivityTimerwillbestillrunningGainfromLTE815isareduceddelayinULschedulingasUEhasalwaysgrantassigned(withinspecifiedtimeperiod)evenifnonewtransmissionisbufferedOncetheUEhasgoneintoDRXsleep,itwillnotbelongeravailabletobeconsideredforproactiveresourceassignmentuntilthenextphaseofbeingDRXActiveoccurs第27页/共37页内容提要VOLTE接通率VOLTE掉话率RRC重建优化呼叫建立时延和MOS优化第28页/共37页呼叫建立时延-指标定义和流程呼叫建立时延定义:呼叫建立时延-RRC(s)：呼叫时终端随机接入Message1直到收到RRCComplete进行DRB配置和SecurityMode配置呼叫建立时延-IMS(s)：SIPINVITE到180RING。第29页/共37页问题现象描述：被叫收到paging或INVITErequest消息很慢，约5-10s网络信令分析：被叫侧TAS在做TADS预选的时候，HSS发ATI但是PCC没有响应，最终导致5秒以后LDRA超时返回3002后，TAS才转发INVITE问题定位&解决：NTHLR数据未完全配置，导致HSS发ATI到未配置的SE时NTHLR不响应。将NTHLR的18块SE板数据配全后解决数据配置时间点呼叫建立时延-案例分析第30页/共37页问题描述：在同一个小区内进行测试占用同一个小区，但是每次呼叫过程中主叫都会频繁发起combinedTAU过程。而且TAU发生的时机也有好几种：1.首次TAU发生在终端上发IMS_SIP_INVITE->OK之后；2.首次TAU发生在终端上发IMS_SIP_INVITE->OK之前，这时会发现主被叫不同步现象，具体表现为被叫显示已接通但是主叫在拨号中，主叫接通时间迟于被叫10s；3.在终端挂机后连续TAU。问题分析：对于第一种情况，combinedTAU发生在终端上发IMS_SIP_INVITE->OK之后并未对通话照成影响，但是如第二种情况combinedTAU发生在终端上发IMS_SIP_INVITE->OK之前，在TAU这段时间内用户平面内不进行任何业务，所以在这段时间内就导致了主叫接通时延，这个时间刚好在10s左右，这也是导致主被叫不同步的原因之一。至于为什么刚好在10s左右着就与inactivatetimer设置为10s有关。TAU过程中只建立srb进行信令交互，整个过程没有数据包发送，基站侧设置inactivetimer10s，基站检测到数据面无数据10s后发送release给终端释放rrc连接。之后servicerequest（时延100ms内）重新建立rrc连接后收到被叫的200OK，完成建立通话。呼叫建立时延-TAU案例分析进一步分析发现UE上发的TAU请求为combinedTA/LATAU，而联合TAU请求需要在CS域和PS域都进行更新。由于终端在测试时设置成PSONLY（按理说设置成PSONLY后不会进行combinedTAU，具体是什么原因导致终端还会发起请求还需终端工程师进一步排查），从流程上看TAUcomplete，但实际上只有PS域的更新而CS域并未更新成功，也就是说联合更新实际上并未成功，这就引发了频繁TAU请求。解决方案：核心网与CS核心网调通，联合位置更新成功。目前已解决第31页/共37页MOS优化对于VoLTE语音质量，一般以MOS值作为参考考核指标。LTE的RF优化是VoLTE优化之本，做好弱SINR（-6到6）区域的优化可以有效的提升VoLTEMOS值；避免乒乓切换，减少TM模式切换及TAU是VoLTEMOS优化工作的关键；减少CSFB几率及选择合适的AMR速率可以得到合理的MOS值结果，在测试前期，整网的VoLTE语音MOS值波动较大，一方面是MOS盒稳定性问题，另外一方面则是无线/核心网参数设置导致；案例1描述：外场VoLTE测试，主被叫终端设置为高清23.85k后可以使用高清23.85k语音编码速率。在9月中旬外场测试发现设置为23.85k的速率，看到PDCP速率只有14kbps左右，与23.85kbps预期24kbps的速率不一致。怀疑终端未使用高清通话。问题1定位：1）初步怀疑终端NV值修改错误。跟HTC工程师确认，查询高清的QXDMLog发现NV值修改没问题，确认编码速率的确为12.2k。在主叫的invite消息里发现主叫是支持AMR和AMR-WB。说明NV参数设置正确且已生效2）从被叫测试查看invite消息发现，网络侧未下发AMR-WB速率。基本上确认是网络侧把AMR-WB丢弃。3）联系IMS核心网同事抓包分析，经过TAS后，AMR-WB被丢弃。确认为TAS的问题。经确认9月初TAS版本升级，AMR-WBLICENSE没有及时打上。解决方案：TAS添加license后，外场验证，高清电话可以正常拨通：第32页/共37页问题描述：用CDS48KMOS盒对在目前LTE网络下的通话质量进行MOS评估时，发现当通话建立在专用承载（GBR）下时CDSMOS打分值偏低，一直在3.5以下。问题定位：1