32.廣東-VOLTE語音質(zhì)量端到端優(yōu)化經(jīng)驗總結(jié)

第第頁,共15頁VOLTE語音質(zhì)量端到端優(yōu)化經(jīng)驗總結(jié)2019年8月目錄TOC\o"1-5"\h\zVOLTE語音質(zhì)量端到端優(yōu)化經(jīng)驗總結(jié)2一、問題描述2二、分析過程3RTP和RTCP協(xié)議介紹3感知平臺利用RTP/RTCP丟包統(tǒng)計分析VoLTE語音丟包方法.4感知丟包率與空口丟包率指標(biāo)關(guān)聯(lián)5基于感知的載波間VOLTE質(zhì)量對比6三、解決措施7感知質(zhì)差TOP小區(qū)分析.7基于感知的VOLTE質(zhì)量投訴處理11優(yōu)化結(jié)果14四、經(jīng)驗總結(jié)14VOLTE語音質(zhì)量端到端優(yōu)化經(jīng)驗總結(jié)【摘要】VOLTE商用后，現(xiàn)網(wǎng)VOLTE用戶逐漸增多，影響VOLTE端到端感知的因素很多，站在無線優(yōu)化的角度，大致可分為無線側(cè)和非無線側(cè)的原因。廣東電信借助端到端感知平臺，利用感知部署在IMS和EPC網(wǎng)絡(luò)各接口的探針，快速分段定界語音感知問題。在無線側(cè)通過問題分析和特性參數(shù)優(yōu)化提升用戶感知。本文總結(jié)了廣東電信利用感知端到端平臺和無線性能優(yōu)化提升VOLTE語音質(zhì)量和處理投訴的相關(guān)經(jīng)驗?！娟P(guān)鍵字】VOLTE,感知，語音質(zhì)量，投訴【業(yè)務(wù)類別】VoLTE一、問題描述隨著VOLTE商用，越來越多的VOLTE用戶接入網(wǎng)絡(luò)，相關(guān)的語音質(zhì)量投訴也增多。鑒于VOLTE端到端系統(tǒng)的復(fù)雜，廣東電信借助感知平臺能有效進行分析和處理投訴，實現(xiàn)跨域、全流程、多接口分析。1-MMEUECx/DxI：□隔^■，MMw■■匚輕?1-MMEUECx/DxI：□隔^■，MMw■■匚輕?kFMwLUinAN-si-U!?數(shù)堆采換口Sv/SGsP-CSCF/A-SBCB&ZFTM&CFMn11?罷i：i今m閃兩根據(jù)實測數(shù)據(jù)來看，VoLTE丟包對語音質(zhì)量影響最大?，F(xiàn)網(wǎng)中抖動和時延對語音質(zhì)量較小，主要影響因素是VOLTE丟包率。丟包^vsIVlQS抖動vsMOS

時延俯MOSSSm'jiJSnhji55?*5時延俯MOSSSm'jiJSnhji55?*5175ms*$5?*因此為模擬終端用戶感知，通過端到端感知平臺定義了3個VOLTE質(zhì)量評估指標(biāo)：吞字呼叫比例、斷續(xù)呼叫比例和單通呼叫比例。吞字呼叫：連續(xù)20個語音包RTCP丟包率大于60%。斷續(xù)呼叫：連續(xù)50個語音包RTCP丟包率大于60%。單通呼叫：5s內(nèi)RTCP丟包率大于80%。VOLTERTCP丟包率反映了端到端丟包情況。根據(jù)感知統(tǒng)計，吞字呼叫比例、斷續(xù)呼叫比例和單通呼叫比例都非常高，語音質(zhì)差問題語音端到端質(zhì)量指標(biāo)統(tǒng)計2019/1/62019/1/72019/1/82019/1/92019/1/102019/1/112019/1/122019/1/13嚴重。語音端到端質(zhì)量指標(biāo)統(tǒng)計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%吞字呼叫比例斷續(xù)呼叫比例單通呼叫比例二、分析過程1.1RTP和RTCP協(xié)議介紹volte語音數(shù)據(jù)采用rtp承載。rtp通過引入承載的媒體類型、序列碼、時間戳等參數(shù)增強UDP對數(shù)據(jù)承載的功能。RTP本身只保證實時數(shù)據(jù)的傳輸，并不提供可靠的傳送機制,也不提供流量控制或擁塞控制。VOLTE語音RTP包間隔是20ms。RTP的控制由RTCP協(xié)議來完成。RTCP主要用于對傳輸質(zhì)量的回饋，各個媒體流之間的同步，RTCP周期性地匯報RTP的傳輸質(zhì)量，雖然媒體數(shù)據(jù)包都是在毫秒級內(nèi)發(fā)送，但是控制協(xié)議數(shù)據(jù)包都是在秒級間隔發(fā)送的，RTCP包間隔是5soRTP協(xié)議頭部結(jié)構(gòu)如下。其中關(guān)鍵字段感知uencenumber可以被接收者用來檢查是否

發(fā)生丟包、亂序。每發(fā)送一個RTP發(fā)生丟包、亂序。每發(fā)送一個RTP包，感知uencenumber就加1,如果感知uencenumber不連續(xù)則判斷有丟包。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報文的關(guān)鍵字段cumulativenumberofpacketslost(丟包數(shù)量)用于累計丟失的包的個數(shù),是接收方發(fā)送出來的表征接收方接收報文的情況(所以RTCPRR報告與RTP報文的方向是相反的)。計算方法是：丟包數(shù)量=期待接收的包數(shù)-實際接收的包數(shù)。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丟包統(tǒng)計分析VoLTE語音丟包方法感知平臺通過在各個網(wǎng)絡(luò)接口部署探針，抓取雙向RTP和RTCP報文，判斷RTP丟包。以主叫GM口為例，共定義了4個丟包指標(biāo)：上行RTP丟包數(shù)；上行RTP丟包數(shù)(RTCP)；下

行RTP行RTP丟包數(shù)；下行RTP丟包數(shù)（RTCP）。主叫上行RTP丟包數(shù)：探針抓取主叫發(fā)往被叫的RTP數(shù)據(jù)包，解析RTP包的序列號判斷是否存在丟包。主叫上行RTP丟包數(shù)（RTCP）：探針抓取被叫反饋的RTCP報文，在被叫反饋給主叫的RTCP報文中，統(tǒng)計了主叫發(fā)給被叫的RTP包端到端丟包數(shù)。主叫下行RTP丟包數(shù)：探針抓取被叫發(fā)往主叫的RTP數(shù)據(jù)包，解析RTP包的序列號判斷是否存在丟包。主叫下行RTP丟包數(shù)（RTCP）：探針抓取主叫反饋的RTCP報文，在主叫反饋給被叫的RTCP報文中，統(tǒng)計了被叫發(fā)給主叫的RTP包端到端丟包數(shù)。析RTP報立,逸過RTP包序列號削斷RTP丟包主叫語音上行RTP敷嗚包主叫上行析RTP報立,逸過RTP包序列號削斷RTP丟包主叫語音上行RTP敷嗚包主叫上行顯主叫eNcdeBS/PGWIMSIMSehodeB主叫上行kTCPRR反謚包主叫下行主叫下行RTP主叫下行主叫下行RTP丟包數(shù):探針彳祈RTP磁,通過RTP包序列號判斷RTP丟也RTtIPR眼齟」匕壬叫下行RTP丟回鼎RTCP）：疣計豐叫反啜的RKP拎制包.統(tǒng)計丟破通過各個接口的主被叫“RTP丟包數(shù)”和“RTP丟包數(shù)（RTCP）”統(tǒng)計，可定界丟包問題。方法如下?？?U/Gm口RTP上行天何：菲Q在本端口WGm口檢測到的本端UE呈本端弭ULI的丟包￡1-U/Gm口RTP下行人包：SEQS本端Sl-U/Gm口檢測到的對端UE至本端5L-U口的關(guān)包RTCP上行丟包：對端UE反饋的本■端UE發(fā)給對端的UE的丟抿數(shù)RTCP下行丟包：本端UE反慣的對揣UE發(fā)給本端的UE的丟抿數(shù)結(jié)論：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感知丟包率與空口丟包率指標(biāo)關(guān)聯(lián)如下圖用戶面協(xié)議棧所示，VOLTE的IP業(yè)務(wù)包在空口轉(zhuǎn)發(fā)給PDCP層，PDCP是空口用

戶面協(xié)議的最高層，空口各層的丟包都會反映在PDCP層上。因此eNodeB定義了PDCP層相關(guān)的丟包率指標(biāo)：QCI1業(yè)務(wù)上行空口丟包率和QCI1業(yè)務(wù)下行空口丟包率。QCI1業(yè)務(wù)上行空口丟包率：小區(qū)QCI為1的DRB業(yè)務(wù)PDCPSDU上行丟棄的總包數(shù)/小區(qū)QCI為1的DRB業(yè)務(wù)上行期望收到的總包數(shù)。QCI1業(yè)務(wù)下行空口丟包率:小區(qū)QCI為1的DRB業(yè)務(wù)PDCPSDU下行空口丟棄的總包數(shù)/小區(qū)QCI為1的DRB業(yè)務(wù)PDCPSDU下行空口發(fā)送的總包數(shù)。UEmNodeEUEmNodeEServingGWFDNGW以小區(qū)維度關(guān)聯(lián)RTP上行丟包率和QCI1業(yè)務(wù)上行空口丟包率，這二者呈正向?qū)?yīng)關(guān)系,因此分析RTP丟包率指標(biāo)，可以相對應(yīng)地優(yōu)化無線側(cè)QCI1業(yè)務(wù)的空口丟包率。1.4基于感知的載波間VOLTE質(zhì)量對比RTP上行丟包率800M高于2.1G和1.8G。RTP上行丟包率傑）0￡D%RTP上行丟包率傑）0￡D%0.75%高。上行單通的通話比例（％）、上行吞字的通話比例（％）和上行斷續(xù)的通話比例（％）: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%■上行單通的通話比例傑）■上行手孚的通話比例佻）■上行斷續(xù)的通話比例（刪5,000%三、解決措施2.1感知質(zhì)差TOP小區(qū)分析2.1.1小區(qū)級分析統(tǒng)計上下行丟包率較嚴重的217個小區(qū)，分別從告警影響、干擾底噪、覆蓋問題、切換問題、鏈路質(zhì)量、功率配置、站間距多個維度展開分析，統(tǒng)計小區(qū)存在問題如下：

丟包率TOP丟包率TOP小區(qū)分析(小區(qū)數(shù))■告警影響■上行干擾■過覆蓋■弱覆蓋■切換問題■上行鏈路質(zhì)量差■上下行功率不平衡■站間距過大■重疊覆蓋從中可以看出，存在上行干擾問題的小區(qū)占比達35.48%。其次重疊覆蓋和過覆蓋小區(qū)占比也很多。2.1.2基于感知和CHR的用戶級分析舉例根據(jù)感知多維指標(biāo)查詢確定VOLTE吞字斷續(xù)單通TOP小區(qū)“杏壇高贊800_0”,通過VOLTE用戶面單據(jù)查詢，可以看到在該小區(qū)下2019-02-1420:45~20:48的呼叫中，無線空口上行丟包數(shù)達1839個，無線空口下行丟包數(shù)正常。捉口矣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根據(jù)感知綜合單據(jù)查詢的信令流程信息，可知此次呼叫UE-S1-APID是836344，據(jù)此從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用戶的語音質(zhì)量話單，可以看到該用戶上行丟包率非常高,呼叫中該用戶上行覆蓋非常差，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監(jiān)irhwui">1>1"FjIC_1HQrcmurAArtftAn該用戶下行無丟包，查詢該小區(qū)RS功率設(shè)置為252，下行功率設(shè)置過大，確認是上下行覆蓋不平衡導(dǎo)致的上行丟包問題。2.1.3上下行功率不平衡優(yōu)化為提升800M小區(qū)的深度覆蓋能力，除頻段自身傳播優(yōu)勢外，功率設(shè)置也較大，大量小區(qū)RS功率設(shè)置在182以上。導(dǎo)致當(dāng)下行覆蓋范圍大于上行在小區(qū)邊緣產(chǎn)生偽覆蓋區(qū)。在偽覆蓋區(qū)內(nèi)手機能夠正常接收基站的信號，但是因上行覆蓋受限導(dǎo)致通話質(zhì)量差。因此從VOLTE質(zhì)差小區(qū)中,排除存在下行覆蓋差、上行干擾和站點告警等問題的小區(qū)后,挑選10個功率設(shè)置過大的小區(qū)將導(dǎo)頻降功率3dB,驗證VOLTE質(zhì)量變化。降功率后，質(zhì)差通話比例大幅降低。小區(qū)1月31日調(diào)整功率后指標(biāo)統(tǒng)計:通話次數(shù)單通次數(shù)斷續(xù)次數(shù)吞字次數(shù)質(zhì)差比例通話次數(shù)單通次數(shù)斷續(xù)次數(shù)吞字次數(shù)質(zhì)差比例I容桂廣龍路R0通話次數(shù)64單通次數(shù)9斷續(xù)次數(shù)5吞字次數(shù)8質(zhì)差比例3438%通話次數(shù)14單通次數(shù)1斷續(xù)次數(shù)1吞字次數(shù)1質(zhì)差比例2143%容桂丿龍路RU容桂高黎工業(yè)區(qū)1160233丄?38%3125%500021.丄3%000%容桂高黎丄業(yè)區(qū)丄容桂東逸灣北D01532253丄?2U%580%9000U.UU%000%容^桂東逸灣北倫教電信5502310000%4000000%倫電^信龍江保利上城三期4154013333%12000000%丿龍江保V利丄城—二??期」4樂從新華村北R1811351111%2000000%丿樂丿丿UJ新華村」J|UR丄大良五沙聯(lián)盛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質(zhì)量投訴處理無線側(cè)基于感知的VOLTE質(zhì)量投訴處理流程如下所示?；凇罢Z音質(zhì)量單據(jù)”查詢結(jié)果確認丟包網(wǎng)絡(luò)位置請參選2.1.2節(jié)。質(zhì)莖問世問題宦位？荻8S"Iffi斥用戶詳單/信令潮星“小區(qū)話短査詢質(zhì)差話單5￡分片確認問題小區(qū)和時間給合單據(jù)奩詢星否肓質(zhì)莖問世問題宦位？荻8S"Iffi斥用戶詳單/信令潮星“小區(qū)話短査詢質(zhì)差話單5￡分片確認問題小區(qū)和時間給合單據(jù)奩詢星否肓”一鍵式日志"混入分折邇過”越育質(zhì)星單據(jù)“碑認丟包網(wǎng)堀位空蓋排復(fù)測『區(qū)吿警查詢*2.2.1用戶投訴接通后無聲音用戶投訴接聽后長時間無聲音，最后用戶自己掛斷電話重撥。根據(jù)用戶戶投訴描述信息，初步歸類為語音質(zhì)量問題，查詢感知“語音質(zhì)量單據(jù)”根據(jù)查詢結(jié)果發(fā)現(xiàn)無丟包。查詢感知“綜合單據(jù)”，主叫在12:14:57發(fā)起呼叫：12:14:59,主叫收到振鈴消息：

其后主叫一直未收到被叫接聽的200OK消息，振鈴16s后，13:12:15主叫等待時間過長，取消這次呼叫。被叫接聽發(fā)送2000K和主叫取消呼叫發(fā)送cancel的時間幾乎相同，即被叫接聽的同時主叫恰好取消呼叫。如下圖S-CSCF處理被叫接聽的2000K消息和主叫取消呼叫的cancel消息幾乎同步：IMS取消完主叫通話后，并不同步取消被叫通話，直到接聽16s后，即12:15:31被叫才主動掛斷此次呼叫：

定位結(jié)論：被叫接聽的同時主叫恰好取消呼叫，S-CSCF處理被叫接聽的200OK消息和主叫取消呼叫的cancel消息幾乎同步。但是S-CSCF取消主叫通話后，并沒有同步正確地取消被叫通話，導(dǎo)致被叫誤以為已經(jīng)接通，保持通話狀態(tài)但是聽不到任何聲音。將此問題反饋給IMS核心網(wǎng)S-CSCF網(wǎng)元進一步處理。定位結(jié)論：2.2.2用戶投訴單通用戶投訴接聽后單通，根據(jù)用戶投訴描述信息，初步歸類為語音質(zhì)量問題，查詢感知<0Q0破叫蘭叫蘭叫16:29:00被叫振鈴，因為是VOLTE打CDMA，時延較大:16:29:08被叫接聽，通話正