32.广东-VOLTE语音质量端到端优化经验总结_第1页
32.广东-VOLTE语音质量端到端优化经验总结_第2页
32.广东-VOLTE语音质量端到端优化经验总结_第3页
32.广东-VOLTE语音质量端到端优化经验总结_第4页
32.广东-VOLTE语音质量端到端优化经验总结_第5页
已阅读5页,还剩15页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第第页,共15页VOLTE语音质量端到端优化经验总结2019年8月目录TOC\o"1-5"\h\zVOLTE语音质量端到端优化经验总结2一、问题描述2二、分析过程3RTP和RTCP协议介绍3感知平台利用RTP/RTCP丢包统计分析VoLTE语音丢包方法.4感知丢包率与空口丢包率指标关联5基于感知的载波间VOLTE质量对比6三、解决措施7感知质差TOP小区分析.7基于感知的VOLTE质量投诉处理11优化结果14四、经验总结14VOLTE语音质量端到端优化经验总结【摘要】VOLTE商用后,现网VOLTE用户逐渐增多,影响VOLTE端到端感知的因素很多,站在无线优化的角度,大致可分为无线侧和非无线侧的原因。广东电信借助端到端感知平台,利用感知部署在IMS和EPC网络各接口的探针,快速分段定界语音感知问题。在无线侧通过问题分析和特性参数优化提升用户感知。本文总结了广东电信利用感知端到端平台和无线性能优化提升VOLTE语音质量和处理投诉的相关经验。【关键字】VOLTE,感知,语音质量,投诉【业务类别】VoLTE一、问题描述随着VOLTE商用,越来越多的VOLTE用户接入网络,相关的语音质量投诉也增多。鉴于VOLTE端到端系统的复杂,广东电信借助感知平台能有效进行分析和处理投诉,实现跨域、全流程、多接口分析。1-MMEUECx/DxI:□隔^■,MMw■■匚輕?1-MMEUECx/DxI:□隔^■,MMw■■匚輕?kFMwLUinAN-si-U!•數堆采换口Sv/SGsP-CSCF/A-SBCB&ZFTM&CFMn11•罷i:i今m闪两根据实测数据来看,VoLTE丢包对语音质量影响最大。现网中抖动和时延对语音质量较小,主要影响因素是VOLTE丢包率。丢包^vsIVlQS抖动vsMOS

时延俯MOSSSm'jiJSnhji55™*5时延俯MOSSSm'jiJSnhji55™*5175ms*$5・*因此为模拟终端用户感知,通过端到端感知平台定义了3个VOLTE质量评估指标:吞字呼叫比例、断续呼叫比例和单通呼叫比例。吞字呼叫:连续20个语音包RTCP丢包率大于60%。断续呼叫:连续50个语音包RTCP丢包率大于60%。单通呼叫:5s内RTCP丢包率大于80%。VOLTERTCP丢包率反映了端到端丢包情况。根据感知统计,吞字呼叫比例、断续呼叫比例和单通呼叫比例都非常高,语音质差问题语音端到端质量指标统计2019/1/62019/1/72019/1/82019/1/92019/1/102019/1/112019/1/122019/1/13严重。语音端到端质量指标统计2019/1/62019/1/72019/1/82019/1/92019/1/102019/1/112019/1/122019/1/133.50%3.00%2.50%2.00%1.50%1.00%0.50%0.00%吞字呼叫比例断续呼叫比例单通呼叫比例二、分析过程1.1RTP和RTCP协议介绍volte语音数据采用rtp承载。rtp通过引入承载的媒体类型、序列码、时间戳等参数增强UDP对数据承载的功能。RTP本身只保证实时数据的传输,并不提供可靠的传送机制,也不提供流量控制或拥塞控制。VOLTE语音RTP包间隔是20ms。RTP的控制由RTCP协议来完成。RTCP主要用于对传输质量的回馈,各个媒体流之间的同步,RTCP周期性地汇报RTP的传输质量,虽然媒体数据包都是在毫秒级内发送,但是控制协议数据包都是在秒级间隔发送的,RTCP包间隔是5soRTP协议头部结构如下。其中关键字段感知uencenumber可以被接收者用来检查是否

发生丢包、乱序。每发送一个RTP发生丢包、乱序。每发送一个RTP包,感知uencenumber就加1,如果感知uencenumber不连续则判断有丢包。0123^01234567890123456789012345678901^+-+-+-+-H|V=2|PXF--H-+-+-+-4-4cc|m|+-+-4-+——+-+TPTF-+-+-+-+-+-+-+-4-+-+-+-+-4sequenceliumbei'1丄丄L丄LIL丄L丄JIL1111111111timestainp-1LILI].丄J1111111111II111L丄丄丄JL丄丄丄JLJL丄丄丄Lsynchronisationsource(SSRC)identifier十二一二十二_二_二_二_二十二十二一二_二_二十二十二十二一二_二_二十二十二十二一二_二_二十二十二十二一二_二_二十二十二十contributingsource(CSRC)identifiersRTCP接收者报告报文格式如下。RR报文的关键字段cumulativenumberofpacketslost(丢包数量)用于累计丢失的包的个数,是接收方发送出来的表征接收方接收报文的情况(所以RTCPRR报告与RTP报文的方向是相反的)。计算方法是:丢包数量=期待接收的包数-实际接收的包数。VfapRCaisPT--3C1LengthReports56RCLoss^actionCufnuhtivenjjnb^refp^cke-tsIMtrsJiLExtendedhighestsequencenumberre<eivodrsJiLIriterarrivsljitterTirreM^p吋唁StrtpoTr£Q$i哺日(L£R>DebysinceIastsenderreportreceiwed(DLSR)r頁审iv^rr頁审iv^rrepQrfV-vWMnnu<nbe«P■RC■"叫mlxr*1rpQGvcrr^xprtIJk^Jqi^PT■pa■如E>pt1.2感知平台利用RTP/RTCP丢包统计分析VoLTE语音丢包方法感知平台通过在各个网络接口部署探针,抓取双向RTP和RTCP报文,判断RTP丢包。以主叫GM口为例,共定义了4个丢包指标:上行RTP丢包数;上行RTP丢包数(RTCP);下

行RTP行RTP丢包数;下行RTP丢包数(RTCP)。主叫上行RTP丢包数:探针抓取主叫发往被叫的RTP数据包,解析RTP包的序列号判断是否存在丢包。主叫上行RTP丢包数(RTCP):探针抓取被叫反馈的RTCP报文,在被叫反馈给主叫的RTCP报文中,统计了主叫发给被叫的RTP包端到端丢包数。主叫下行RTP丢包数:探针抓取被叫发往主叫的RTP数据包,解析RTP包的序列号判断是否存在丢包。主叫下行RTP丢包数(RTCP):探针抓取主叫反馈的RTCP报文,在主叫反馈给被叫的RTCP报文中,统计了被叫发给主叫的RTP包端到端丢包数。析RTP报立,逸过RTP包序列号削断RTP丟包主叫语音上行RTP敷嗚包主叫上行析RTP报立,逸过RTP包序列号削断RTP丟包主叫语音上行RTP敷嗚包主叫上行显主叫eNcdeBS/PGWIMSIMSehodeB主叫上行kTCPRR反谥包主叫下行主叫下行RTP主叫下行主叫下行RTP丢包数:探針彳祈RTP磁,通过RTP包序列号判断RTP丢也RTtIPR眼齟」匕壬叫下行RTP丢回鼎RTCP):疣计丰叫反啜的RKP拎制包.统计丢破通过各个接口的主被叫“RTP丢包数”和“RTP丢包数(RTCP)”统计,可定界丢包问题。方法如下。口-U/Gm口RTP上行天何:菲Q在本端口WGm口检测到的本端UE呈本端弭ULI的丟包£1-U/Gm口RTP下行人包:SEQS本端Sl-U/Gm口检测到的对端UE至本端5L-U口的关包RTCP上行丢包:对端UE反馈的本■端UE发给对端的UE的丢抿数RTCP下行丢包:本端UE反惯的对揣UE发给本端的UE的丢抿数结论:1本端上行UE至Sl-UfGm口丢包:本端舁-U/Gm口RTP上行丢包2本揣上行S1-U口至本端石m口丟包:本湍3m口RTP上行丢包-本端S1-U口FITP上行丢包孑本揣Gm口至对湍Sm口去包:对端Gm口下行RTP丢就[本端Gm口上行RTP丢包却对端右m口至对端S1-U口下行丢包:对端51-U口下行RTP丢包-对端Gm口下行RTP丢包5型赧1-U口以下下行丢包:竺戦R匹P占辽丢包or对端RTtP下戶丟包-对端SI-U口RTP下行丢包1.3感知丢包率与空口丢包率指标关联如下图用户面协议栈所示,VOLTE的IP业务包在空口转发给PDCP层,PDCP是空口用

户面协议的最高层,空口各层的丢包都会反映在PDCP层上。因此eNodeB定义了PDCP层相关的丢包率指标:QCI1业务上行空口丢包率和QCI1业务下行空口丢包率。QCI1业务上行空口丢包率:小区QCI为1的DRB业务PDCPSDU上行丢弃的总包数/小区QCI为1的DRB业务上行期望收到的总包数。QCI1业务下行空口丢包率:小区QCI为1的DRB业务PDCPSDU下行空口丢弃的总包数/小区QCI为1的DRB业务PDCPSDU下行空口发送的总包数。UEmNodeEUEmNodeEServingGWFDNGW以小区维度关联RTP上行丢包率和QCI1业务上行空口丢包率,这二者呈正向对应关系,因此分析RTP丢包率指标,可以相对应地优化无线侧QCI1业务的空口丢包率。1.4基于感知的载波间VOLTE质量对比RTP上行丢包率800M高于2.1G和1.8G。RTP上行丢包率傑)0£D%RTP上行丢包率傑)0£D%0.75%高。上行单通的通话比例(%)、上行吞字的通话比例(%)和上行断续的通话比例(%):800M最4.685%4.500%4.000%3.503%4.685%4.500%4.000%3.503%3.000^2.500%2.000%1.500%1.000^0.500%0,003%■上行单通的通话比例傑)■上行手孚的通话比例佻)■上行斷续的通话比例(删5,000%三、解决措施2.1感知质差TOP小区分析2.1.1小区级分析统计上下行丢包率较严重的217个小区,分别从告警影响、干扰底噪、覆盖问题、切换问题、链路质量、功率配置、站间距多个维度展开分析,统计小区存在问题如下:

丢包率TOP丢包率TOP小区分析(小区数)■告警影响■上行干扰■过覆盖■弱覆盖■切换问题■上行链路质量差■上下行功率不平衡■站间距过大■重叠覆盖从中可以看出,存在上行干扰问题的小区占比达35.48%。其次重叠覆盖和过覆盖小区占比也很多。2.1.2基于感知和CHR的用户级分析举例根据感知多维指标查询确定VOLTE吞字断续单通TOP小区“杏坛高赞800_0”,通过VOLTE用户面单据查询,可以看到在该小区下2019-02-1420:45~20:48的呼叫中,无线空口上行丢包数达1839个,无线空口下行丢包数正常。捉口矣32上厅JTF上抒fllFF行R1F下行RTF卑直至叔生包垃E虫包放岂匡钗l:STCP:li.ilCF)l.JTCP)I.HKPJ上打肛F上嗣F舌包®下行册Glfl岂0下™?壬加上行E較下厅宜E.頼20LS-02-I1a:45:07^lS-fi2-]J帥:眄::0&杏丘蔓曲帥Ojj•杏民需费聞0」5l笫]L17龙炳051471妙■:02CiLW>l43):^507引裁:妁百坛基毆腑」杏坛葺3!卿』SHJ肌鋪3L17羽荷06147I.卿mi0根据感知综合单据查询的信令流程信息,可知此次呼叫UE-S1-APID是836344,据此从CHR中查找到此次呼叫的CallID是35411296。UEWS15.1.129253GD-GZ-Cl-PSB.GD-GZ-SJ-OW.2019-0(2-1420:45:010110QD.INVrTE2019^220:45:010130M』1DOTRYING20119^-^20^50101MQ0坐11十2019-02-1120-4501017000INW2019^-1-H2D45:01342W0.100-TRYING書一毎I爼.一毎I后一毎I晨后■—条iDOODOOM)jaritiralztyireje口七fO]I100D00CDjEKB-UE-SLAT--工in日丄£34七I000C-LIC-O|EKB-UE-SlAT-IDl」ihodooioiEKB-UE-rSiLfiJ-ID:1miIOC-0iEKB-UE-rSiLAF-ID:-厂UserCommlnfo厂verifyflag:0x6D736730_lgt¥w:U0e「CommInf口ulC曰IIID:35411296|厂uIC9llID:870334_16(222S05520)厂loglength:158厂DATE2019-02-14厂TIME:20:53:36厂Ticks:771-厂UEPubliclnfo……厂TOFTLV:0厂LOFTLV:46厂enUeld匸hogBOTH_WLJD(2)rulMmeUeSlapId:297797538|rulEnbUeSlapId:836344|4I-InitUeld查找CHR下CallId35411296用户的语音质量话单,可以看到该用户上行丢包率非常高,呼叫中该用户上行覆盖非常差,DMRSRSRP和SRSRSRP在-142~-130之间。

Time■W*V—■A-VoeNodeBEDwfrC«lltdCalU770*■■—TMS1ftCodeRateULPatiketlsssDL'Vl'WTl2019-02-1420.44.11(000}870334135411296F0S7F0BDAL1RWB23.85L85.714%D.0(2019-02-142€:J4:U{000;870334LB35411296FD87FDBDAMRWBiS.BSk85.714%2019-02-1420:44:44(000}8703J41635411296FOS7F0BDAMRWB2S.85k59.7>6%3.C:2019-02-1420.45111(000)S7O3341635411296F087F0BDAMRNEl^Jk38.596%J.0:2019-02-1420-45-11(000;8703341635411296F0S7FOBDAMRNB12.2k38.596%"C:2019-02-1420.45.H(000;8703341635411296FOB7FOBDAMRNB12.2k&2.113%:.c:2019-02-1420:45:43(000;37O3M茁35411296F0$7FOBDAMRNBlZ2k43243%X2019-02-1420:45:51(000)8703J41635411296F0S7F0BDAMRNBL2.2k42.105%3.C:2019-02-1430.45.51{000;8703541635411^^6FOa?FOBDAMRNBl^Jk43.105%:.c:2019-02-1420-45-S4(000)8709341$95411296FO87FOBDAMRNB12.?k18750%0CK2018-12-2510:51:41(000}8703MIB950725038RsandomValueAMRWB2J.85kO.ODQ%0.(K2019-01-0317:59:31(000)870334179S2S5S988RandomV^lueAMRWB2J.35k0.000%o.a?niA-oi-7n17-70-5H7刍巧皆眄能iRflnrlnmVrIhpATJRftEknmrs%OCXinDRBS12MSCalllDTHERRCULAverageOMRSRSRPULDMASSINRULAverageSRSRSRPJLAv^ra^iDRR512MS&3383247620510朋-122001?56000000□RB_512MS1354112962147B.4X14L40-1.73-141.290.62DR8_512M$2m却口2昶214100.C-142.78-2.44-142.61119DREFSUMS33541129621456.5;■140.97■1.40■L40s65a23DRB.512M543541125621413.6(138.21-0.14137*11.26nRe.512M$5354112962140.00^-128128.57-128098.23DRB_512MS6354112962140.0OS-130.906.60-131.055.70?RB_512MS73541129621420.43-137.520.72137.461.09DRE512MS£554112962149^.^-142.56-2.19-1A2.&7106nDB监irhwui">1>1"FjIC_1HQrcmurAArtftAn该用户下行无丢包,查询该小区RS功率设置为252,下行功率设置过大,确认是上下行覆盖不平衡导致的上行丢包问题。2.1.3上下行功率不平衡优化为提升800M小区的深度覆盖能力,除频段自身传播优势外,功率设置也较大,大量小区RS功率设置在182以上。导致当下行覆盖范围大于上行在小区边缘产生伪覆盖区。在伪覆盖区内手机能够正常接收基站的信号,但是因上行覆盖受限导致通话质量差。因此从VOLTE质差小区中,排除存在下行覆盖差、上行干扰和站点告警等问题的小区后,挑选10个功率设置过大的小区将导频降功率3dB,验证VOLTE质量变化。降功率后,质差通话比例大幅降低。小区1月31日调整功率后指标统计:通话次数单通次数断续次数吞字次数质差比例通话次数单通次数断续次数吞字次数质差比例I容桂广龙路R0通话次数64单通次数9断续次数5吞字次数8质差比例3438%通话次数14单通次数1断续次数1吞字次数1质差比例2143%容桂丿龙路RU容桂高黎工业区1160233丄・38%3125%500021.丄3%000%容桂高黎丄业区丄容桂东逸湾北D01532253丄・2U%580%9000U.UU%000%容^桂东逸湾北伦教电信5502310000%4000000%伦电^信龙江保利上城三期4154013333%12000000%丿龙江保V利丄城—二••期」4乐从新华村北R1811351111%2000000%丿乐丿丿UJ新华村」J|UR丄大良五沙联盛172228571%0000000%丿'、11»^L/v.1111*丄大良大象山491225556%9000000%北滘永恒焊接Lr0250242400%23000000%•4U11—j■»I-EL7-TU北窖碧江2——3122219.35%—810-1丄——2.47%

2.2基于感知的VOLTE质量投诉处理无线侧基于感知的VOLTE质量投诉处理流程如下所示。基于“语音质量单据”查询结果确认丢包网络位置请参选2.1.2节。质莖问世问题宦位?荻8S"Iffi斥用户详单/信令潮星“小区话短査询质差话单5£分片确认问题小区和时间给合单据奁询星否肓质莖问世问题宦位?荻8S"Iffi斥用户详单/信令潮星“小区话短査询质差话单5£分片确认问题小区和时间给合单据奁询星否肓”一键式日志"混入分折邇过”越育质星单据“碑认丢包网堀位空盖排复测『区吿警查询*2.2.1用户投诉接通后无声音用户投诉接听后长时间无声音,最后用户自己挂断电话重拨。根据用户户投诉描述信息,初步归类为语音质量问题,查询感知“语音质量单据”根据查询结果发现无丢包。查询感知“综合单据”,主叫在12:14:57发起呼叫:12:14:59,主叫收到振铃消息:

其后主叫一直未收到被叫接听的200OK消息,振铃16s后,13:12:15主叫等待时间过长,取消这次呼叫。被叫接听发送2000K和主叫取消呼叫发送cancel的时间几乎相同,即被叫接听的同时主叫恰好取消呼叫。如下图S-CSCF处理被叫接听的2000K消息和主叫取消呼叫的cancel消息几乎同步:IMS取消完主叫通话后,并不同步取消被叫通话,直到接听16s后,即12:15:31被叫才主动挂断此次呼叫:

定位结论:被叫接听的同时主叫恰好取消呼叫,S-CSCF处理被叫接听的200OK消息和主叫取消呼叫的cancel消息几乎同步。但是S-CSCF取消主叫通话后,并没有同步正确地取消被叫通话,导致被叫误以为已经接通,保持通话状态但是听不到任何声音。将此问题反馈给IMS核心网S-CSCF网元进一步处理。定位结论:2.2.2用户投诉单通用户投诉接听后单通,根据用户投诉描述信息,初步归类为语音质量问题,查询感知<0Q0破叫兰叫兰叫16:29:00被叫振铃,因为是VOLTE打CDMA,时延较大:16:29:08被叫接听,通话正

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论