伍竹歆
VoLTE語音呼叫接續(xù)時(shí)延優(yōu)化淺析
伍竹歆
端到端語音接續(xù)時(shí)延是影響客戶感知的重要因素之一,本文研究VoLTE端到端語音呼叫接續(xù)時(shí)延產(chǎn)生的原因,從信令分析角度入手詳細(xì)剖析影響接續(xù)時(shí)延的各個(gè)因素。創(chuàng)新性提出在DRA上采用最小時(shí)延的SCTP工作模式及擴(kuò)大DNS緩存周期的時(shí)延優(yōu)化策略,并通過現(xiàn)網(wǎng)實(shí)踐充分驗(yàn)證了優(yōu)化策略的有效性,呼叫接續(xù)時(shí)延有效縮短一半,為VoLTE商用后客戶滿意度的持續(xù)提升提供了有力保障。
VoLTE即Voice over LTE,是通過LTE網(wǎng)絡(luò)作為業(yè)務(wù)接入IP多媒體子系統(tǒng)(IMS)網(wǎng)絡(luò)實(shí)現(xiàn)業(yè)務(wù)控制的語音解決方案,VoLTE能提供高清語音、低延遲視頻通話,是中國移動(dòng)發(fā)展融合通信業(yè)務(wù)的核心。
本文從VoLTE呼叫流程信令分析角度入手,對(duì)主被叫均附著在LTE下的VoLTE撥打VoLTE正常呼叫接續(xù)各個(gè)信令過程進(jìn)行了梳理和分析,歸納總結(jié)了影響VoLTE端到端語音呼叫各個(gè)階段呼叫時(shí)延的關(guān)鍵因素,詳細(xì)研究了IMS核心網(wǎng)時(shí)延優(yōu)化策略,提出在DRA上采用最小時(shí)延的SCTP工作模式及擴(kuò)大DNS緩存周期的時(shí)延優(yōu)化策略,并將理論研究成果應(yīng)用于實(shí)踐,通過現(xiàn)網(wǎng)驗(yàn)證方案取得了縮短呼叫建立時(shí)延的顯著成效。
呼叫建立時(shí)長的定義
VoLTE語音呼叫建立時(shí)長,在人為感知上是指從用戶撥號(hào)到聽到被叫的彩鈴音或回鈴音的時(shí)間,從信令角度是指從主叫手機(jī)發(fā)起業(yè)務(wù)請(qǐng)求(INVITE)到主叫手機(jī)收到振鈴消息(180)之間的時(shí)長。VoLTE語音呼叫的接續(xù)時(shí)長過長,會(huì)影響用戶對(duì)網(wǎng)絡(luò)服務(wù)質(zhì)量的感知。
影響呼叫建立時(shí)長的主要因素
主被叫均附著在LTE下的VoLTE TO VoLTE呼叫接續(xù)時(shí)延,由終端、無線、EPC及IMS網(wǎng)絡(luò)時(shí)延組成。從主叫終端發(fā)送第一個(gè)會(huì)話消息(INVITE)到接收到網(wǎng)絡(luò)側(cè)發(fā)送的振鈴消息(180),影響呼叫建立時(shí)長的主要因素主要有三個(gè)。
IMS消息處理部分耗時(shí):IMS消息處理主要包括消息在網(wǎng)元間的傳輸時(shí)延以及業(yè)務(wù)處理流程耗時(shí),包括主叫業(yè)務(wù)/被叫業(yè)務(wù)/錨定/域選等關(guān)鍵流程。
呼叫過程中空口+EPC來回耗時(shí):消息在網(wǎng)絡(luò)側(cè)和終端之間耗時(shí)。
PCRF承載建立耗時(shí)。
從主叫終端發(fā)送第一個(gè)會(huì)話消息(INVITE)到接收到網(wǎng)絡(luò)側(cè)發(fā)送的振鈴消息(180),信令流程可以分為14段時(shí)延。其中,IMS網(wǎng)絡(luò)時(shí)延有(3)、(5)、(7)、(9)、(11)、(13);終端、無線及EPC時(shí)延有(1)、(4)、(6)、(8)、(10)、(12)、(14);由終端、無線、EPC及IMS網(wǎng)絡(luò)的NETLOC和PRECONDITION共同產(chǎn)生的時(shí)延有(2)、(10)。除此之外,在主被叫接收到INVITE/183/UPDATE消息時(shí),都會(huì)觸發(fā)到PCRF進(jìn)行用戶面的承載建立,因此,主被叫用戶面的承載建立也需要一定的耗時(shí)。
對(duì)福建測(cè)試現(xiàn)網(wǎng)的主被叫均在LTE下的VoLTE語音互通時(shí)延進(jìn)行重點(diǎn)分析,主被叫編碼為16.65KBPS的AMR-WB,進(jìn)行了20組VoLTE音頻呼叫測(cè)試,得到總時(shí)延統(tǒng)計(jì)數(shù)據(jù)如表1(單位:s)。
現(xiàn)網(wǎng)語音呼叫時(shí)延主要分布在5.5~5.9s的區(qū)間,20次采樣的平均時(shí)延為5.6778s,下面對(duì)最接近平均時(shí)延的第14次測(cè)試時(shí)延(5.674s)進(jìn)行詳細(xì)分析,并結(jié)合信令流程對(duì)影響端到端語音呼叫接續(xù)時(shí)延的關(guān)鍵因素進(jìn)行深入分析。
通過分析,呼叫建立時(shí)長為2542+854+1437=4833ms,加上INVITE消息的一次重傳耗時(shí)500ms,以及SBC的少量處理延時(shí),總時(shí)長達(dá)到了5674ms,從各段時(shí)延分布情況看,主要耗時(shí)集中在承載建立和IMS消息處理及傳送耗時(shí),因此我們著重從IMS核心網(wǎng)的角度出發(fā)研究時(shí)延優(yōu)化策略,對(duì)于終端及無線原因可能產(chǎn)生的延時(shí),我們提出問題給終端及無線,由終端或無線采取優(yōu)化措施。IMS核心網(wǎng)耗時(shí)原因主要有以下幾個(gè)方面。
Diameter交互耗時(shí)過長
福建VoLTE測(cè)試網(wǎng)絡(luò)采用準(zhǔn)直連連接,Diameter信令接口(包括Rx、Gx、Cx、Sh等)均通過LDRA進(jìn)行轉(zhuǎn)接,從信令流程看,網(wǎng)元間需要進(jìn)行多次信息交互,因此,LDRA的路由能力與呼叫建立時(shí)延密切相關(guān)。測(cè)試發(fā)現(xiàn),SBC通過DRA和PCRF/PGW交互進(jìn)行了5次承載建立的過程平均耗時(shí)達(dá)1400ms,以及CSCF/ TAS接口的3次交互過程平均耗時(shí)達(dá)950ms。
在當(dāng)前的配置和測(cè)試環(huán)境下,Diameter交互總耗時(shí)達(dá)2350多ms,耗時(shí)過長,原因如下。
表1
表2
Diameter協(xié)議應(yīng)用在SCTP協(xié)議之上,SCTP具有如下兩種工作模式。
1.省帶寬模式,SCTP層收到一個(gè)上層來的請(qǐng)求不會(huì)立刻轉(zhuǎn)發(fā)出去,而要等到設(shè)定的緩沖區(qū)滿了之后才會(huì)轉(zhuǎn)發(fā);此模式在正式商用時(shí)使用,因?yàn)檎缴逃煤笤拕?wù)量一般都會(huì)維持在一個(gè)數(shù)量,緩沖區(qū)基本上都是滿載,一般可以認(rèn)為上層下來的消息立刻就會(huì)被SCTP層轉(zhuǎn)發(fā)出去。當(dāng)前的系統(tǒng)配置就是使用的此模式,但當(dāng)前測(cè)試的時(shí)候系統(tǒng)話務(wù)量又不夠,所以需要等待一段時(shí)間(這段時(shí)間會(huì)達(dá)到百ms)才會(huì)實(shí)際把消息發(fā)送出去。
2.最小時(shí)延模式,SCTP層每收到一個(gè)上層來的請(qǐng)求會(huì)立馬轉(zhuǎn)發(fā)出去 ;此模式在演示調(diào)試時(shí)使用,因?yàn)樵拕?wù)量達(dá)不到一定規(guī)模,緩沖區(qū)不是滿載,在這種模式下,能讓SCTP層立刻轉(zhuǎn)發(fā)消息,降低接續(xù)時(shí)延,讓使用者有接近商用后有較大話務(wù)量時(shí)的時(shí)延體驗(yàn)。
對(duì)于DRA,在一次承載建立過程中涉及到多次DRA轉(zhuǎn)發(fā),交互序列為SBC——DRA——PCRF——DRA——PGW——DRA——PCRF——DRA——SBC,如果修改DRA為模式2,將顯著降低在低話務(wù)量下的Diameter消息轉(zhuǎn)發(fā)時(shí)延;另一方面,因?yàn)镈RA非消息始發(fā)網(wǎng)元,當(dāng)話務(wù)量變大的時(shí)候,等待多消息充滿緩存區(qū)的任務(wù)由始發(fā)網(wǎng)元SBC/CSCF/TAS完成,DRA運(yùn)行在模式2下也不會(huì)有太大的性能影響。模式2對(duì)應(yīng)到DRA上的鏈路捆綁開關(guān),當(dāng)開關(guān)打開時(shí),DRA轉(zhuǎn)發(fā)消息需要滿足兩個(gè)條件之一:
每條鏈路收到的消息包的長度超過1500字節(jié);
消息等待超過50ms。
在業(yè)務(wù)量小的情況下,如果每條鏈路在50ms內(nèi)收到的消息只有一條,并且消息包長度小于1500字節(jié)時(shí),將導(dǎo)致每條消息的時(shí)延超過50ms。在開關(guān)關(guān)閉的情況下,DRA不會(huì)判定以上兩個(gè)條件,而是將收到的消息進(jìn)行處理后直接轉(zhuǎn)發(fā)。
外部DNS查詢耗時(shí)過長
測(cè)試中顯示IMS的4次外部DNS查詢平均耗時(shí)達(dá)260ms;
在當(dāng)前的配置和測(cè)試環(huán)境下,總耗時(shí)達(dá)260ms的外部DNS查詢是正常的,但正常商用用戶量上來后,耗時(shí)將大幅減少,原因如下。
DNS查詢是有緩存的,當(dāng)話務(wù)量上來后,IMS的DNS查詢主要是通過網(wǎng)元內(nèi)部緩存完成,只有當(dāng)緩存超期后才會(huì)進(jìn)行外部DNS查詢,平均到每次呼叫中外部DNS查詢的概率非常小,而當(dāng)前測(cè)試階段,話務(wù)量非常小,加上當(dāng)前的緩存周期只有1min(因?yàn)楫?dāng)前商用的DNS配置的TTL是1min),所以體現(xiàn)出來基本上每次呼叫都要進(jìn)行完整的外部DNS查詢,這就造成了外部DNS查詢耗時(shí)較長。
我們創(chuàng)新性提出在DRA上關(guān)閉鏈路捆綁開關(guān)來優(yōu)化時(shí)延,通過調(diào)整DRA的運(yùn)行模式來優(yōu)化Diameter的交互時(shí)延,并將貝爾DRA的SCTP等待時(shí)長由100ms調(diào)整為10ms,同時(shí)優(yōu)化外部DNS查詢耗時(shí),調(diào)整DNS緩存周期為5min,調(diào)整后對(duì)主被叫編碼為16.65KBPS的AMR-WB再進(jìn)行20組VoLTE音頻呼叫測(cè)試,總時(shí)延數(shù)據(jù)如表2(單位:s)。
由表2可以看出,調(diào)整DRA模式及優(yōu)化DNS緩存周期后,VoLTE語音呼叫時(shí)延可以減少到2.5~4s區(qū)間,平均時(shí)延為3.1099s,較調(diào)整前的平均時(shí)延5.6778s縮短了近一半,顯著改善了VoLTE呼叫接續(xù)時(shí)延,有利于提升終端用戶體驗(yàn)。
無線及終端問題導(dǎo)致時(shí)延
1. 無線側(cè)對(duì)被叫的第一個(gè)INVITE消息耗時(shí)差異非常大,分析結(jié)論如下:MME下發(fā)尋呼給eNB后,基站會(huì)在0~1280ms內(nèi)任一時(shí)間及某個(gè)尋呼子幀上將該尋呼消息下發(fā),因此從MME過來的尋呼直到終端收到該尋呼(不包含響應(yīng)),時(shí)延已經(jīng)可能會(huì)在0~1280ms;該問題主要受參數(shù)-缺省尋呼周期(目前設(shè)置為1280ms)影響,該參數(shù)也屬集團(tuán)規(guī)范。目前無線側(cè)暫無有效方式優(yōu)化該段時(shí)延。
2. 發(fā)現(xiàn)存在INVITE消息重發(fā)的現(xiàn)象:SBC在發(fā)送第一個(gè)INVITE后,如果沒有及時(shí)收到終端的100trying響應(yīng),將重發(fā)INVITE,重發(fā)周期為500ms,1s,……。目前發(fā)現(xiàn)由于VoLTE測(cè)試終端版本問題導(dǎo)致手機(jī)經(jīng)常出現(xiàn)尋呼無響應(yīng)等現(xiàn)象,通過VoLTE終端升級(jí)版本解決。
3.尋呼參數(shù)優(yōu)化。TD-LTE數(shù)據(jù)業(yè)務(wù)時(shí)代,MME采取首先在用戶最后駐留的eNodeB尋呼,尋呼失敗后再在TA List尋呼方式,由于尋呼并不針對(duì)TA List進(jìn)行,如果eNodeB尋呼失敗,則MME需要再啟用正規(guī)的TA List進(jìn)行第二輪尋呼,增加了接續(xù)時(shí)延。VoLTE業(yè)務(wù)時(shí),為了達(dá)到最快速的響應(yīng),修改MME在第一次尋呼就在TA List范圍內(nèi)進(jìn)行。
本文研究VoLTE端到端語音呼叫接續(xù)時(shí)延產(chǎn)生的原因,從信令分析角度入手詳細(xì)剖析影響接續(xù)時(shí)延的各個(gè)因素。創(chuàng)新性提出在DRA上采用最小時(shí)延的SCTP工作模式及擴(kuò)大DNS緩存周期的時(shí)延優(yōu)化策略,并通過現(xiàn)網(wǎng)實(shí)踐充分驗(yàn)證了優(yōu)化策略的有效性,呼叫接續(xù)時(shí)延有效縮短一半,從而達(dá)到讓終端用戶獲得更快、更好的端到端語音接續(xù)體驗(yàn),提升客戶滿意度的目標(biāo),為VoLTE商用后客戶滿意度的持續(xù)提升提供了有力保障。
10.3969/j.issn.1001-8972.2015.24.021