林立引
基于VOLTE的網(wǎng)絡(luò)語音切換問題
林立引
在VOLTE網(wǎng)絡(luò)建設(shè)初期,VOLTE無線覆蓋不足,發(fā)生eSRVCC切換次數(shù)較高,語音切換問題較多,嚴(yán)重影響著VOLTE業(yè)務(wù)的正常開展。本文根據(jù)實際運(yùn)營中遇到的VOLTE語音切換問題,在深入分析問題原因的基礎(chǔ)上,提出了相應(yīng)的解決方案,并取得了良好的效果。
VoLTE(Voice over LTE)是一種基于全I(xiàn)P數(shù)據(jù)傳輸技術(shù),可實現(xiàn)數(shù)據(jù)與語音業(yè)務(wù)同時在同一網(wǎng)絡(luò)下承載1,換言之,VOLTE網(wǎng)絡(luò)下不僅僅提供高速率的數(shù)據(jù)業(yè)務(wù),同時還提供高質(zhì)量的音視頻通話,是提升網(wǎng)絡(luò)業(yè)務(wù)能力、應(yīng)對互聯(lián)網(wǎng)競爭的重要手段,是移動核心網(wǎng)演進(jìn)的目標(biāo)架構(gòu)。在VOLTE建網(wǎng)初期,支持VOLTE功能的無線基站覆蓋不足、不連續(xù),為了保證用戶感知,保證語音呼叫連續(xù)性,中國移動部署eSRVCC (Enhanced Single Radio Voice Call Continuity,增強(qiáng)的單一無線語音呼叫連續(xù)性)切換技術(shù), 在VOLTE業(yè)務(wù)部署初期,eSRVCC語音切換成功率較低,仍有較多技術(shù)問題亟需解決。
SRVCC(Single Radio Voice Call Continuity)是3GPP提出的一種VoLTE語音業(yè)務(wù)連續(xù)性方案2,主要是為了解決當(dāng)單射頻UE 在LTE/Pre-LTE 網(wǎng)絡(luò)和2G/3G CS 網(wǎng)絡(luò)之間移動時,如何保證語音呼叫連續(xù)性的問題,即保證單射頻UE 在IMS 控制的VoIP 語音和CS 域語音之間的平滑切換3。在用戶從4G網(wǎng)絡(luò)向2G/3G網(wǎng)絡(luò)漫游時由用戶終端通過Sv接口觸發(fā)PS到CS的語音業(yè)務(wù)切換4。 本端用戶呼叫時發(fā)生移動,允許本端終端的IP地址重新分配。MSC會代替終端發(fā)起SRVCC切換請求,同時,本端手機(jī)與MSC之間的CS域連接也會建立,并與SCC-AS(TAS)之間建立一個新的本端呼叫路徑,提供一個新的本端媒體地址給SCC-AS,SCC-AS會通過媒體切換過程讓通話兩端的媒體層連接重新建立。切換后,SIP層信令連接和RTP層媒體連接會在原通話兩端重建,如圖1所示。
為了提升用戶感知,中國移動采用eSRVCC語音切換方案,作為SRVCC的增強(qiáng)版本5,eSRVCC在SRVCC網(wǎng)絡(luò)架構(gòu)的基礎(chǔ)上增加了接入側(cè)的信令(ATCF)和媒體錨定點(ATGW),媒體的錨定由ATGW完成,信令的錨定由ATCF和SCC-AS共同完成,這個改變可以減少遠(yuǎn)端更新(Remote Update)的信令傳輸時間,從而減少切換時延,如圖2所示。
在eSRVCC方案中,在信令面,用戶通過ATCF進(jìn)行信令面的錨定,與2/3G的MSC server建立信令連接;而在媒體面,則通過ATGW進(jìn)行媒體錨定,并分配CS域的媒體資源,信令流程如圖3所示。
(1)本端用戶發(fā)生LTE覆蓋向2/3覆蓋的移動時,IP地址重新分配。
(2)MSC server向ATCF發(fā)起切換請求(攜帶STN-SR和C-MSISDN)。
(3)ATCF信令錨定后通過ATGW媒體錨定分配媒體資源。
(4)ATCF向I/S-CSCF、SCC AS請求建立新的呼叫路徑(攜帶ATU-STI和C-MSISDN),并提供新的本端地址。
(5)SIP層信令連接和RIP層媒體連接重建,新的呼叫會話建立。
圖1 SRVCC工作原理圖
圖2 eSRVCC工作原理圖
通過分析VOLTE語音呼叫切換流程,可以將可能導(dǎo)致VOLTE語音切換成功率下降的要素分為以下幾個方面:用戶IP地址解析失敗、信令消息解析失敗、信令消息的接收與發(fā)送失敗、錨定失敗、切換時延過長導(dǎo)致失敗和網(wǎng)元接口不匹配導(dǎo)致失敗。
會話描述協(xié)議(SDP)媒體描述配置不當(dāng)
根據(jù)中國移動VOLTE語音切換流程,呼叫的錨定由ATCF與SCC-AS共同完成,ATCF使用Megaco協(xié)議調(diào)用ATGW完成媒體資源的重新分配后(使用原主叫的context-ID,目的是建立原呼叫與切換呼叫的媒體通道),ATCF發(fā)送invite(被叫是ATU-STI,主叫是用戶PUI)給SCC-AS(啟用與切換Invite請求不同的新Call-leg)。切換后原信令leg被ATCF或SCC-AS釋放。而跟蹤切換信令發(fā)現(xiàn),ATCF并沒有調(diào)用ATGW,向SCC-AS發(fā)出的Invite請求仍然使用eMSC切換Invite請求的Call-ID,沒有啟用新的Call-leg,媒體面地址也只是透傳了eMSC的媒體面地址。上述流程可以看出,ATCF并沒有起到錨定作用。信令包截圖如圖4所示。
通過更廣泛的信令包檢查發(fā)現(xiàn),由于主叫用戶在注冊入網(wǎng)時所分配的媒體參數(shù)的不同,ATCF在向ATGW申請媒體資源時所發(fā)送的INVITE切換請求的媒體編碼存在差異,原呼叫回應(yīng)消息(183)與切換請求INVITE必須攜帶相同的媒體組合才能成功觸發(fā)媒體資源的建立。原呼叫回應(yīng)消息(183)攜帶的媒體編碼為AMR 8000和telephone-event 8000,而部分切換請求INVITE存在telephone-event 8000編碼缺失的情況,這就導(dǎo)致了媒體參數(shù)在此處的不匹配,進(jìn)而引起切換的失敗。
ATCF中的接入域(access realm)參數(shù)設(shè)置不當(dāng)
VOLTE語音切換前后的媒體面均由ATCF調(diào)用ATGW分配。SAE-GW分配給主被叫的均為IPv6地址。ATCF調(diào)用ATGW使用realm的Megaco協(xié)議分配媒體資源實現(xiàn)互通,realm分為access realm(與用戶分配的IP地址互聯(lián)(IPv6)),以及core realm(內(nèi)部互聯(lián),實現(xiàn)主被叫媒體面互通(IPv4))。由于目前移動網(wǎng)絡(luò)中的UE使用的是雙棧協(xié)議的模式,因此在用戶在注冊到網(wǎng)絡(luò)時,會被隨機(jī)分配兩個格式(Ipv4、Ipv6)的IP地址之一。當(dāng)通過ATCF進(jìn)行了信令面的錨定后,就開始通過ATGW建立媒體面的連接,并由eMSS分配媒體GSM的媒體資源。而eMSS和對端用戶使用的是Ipv4協(xié)議,這就可能導(dǎo)致了如果主叫端被分配的IP地址為Ipv6格式,那么與遠(yuǎn)端的媒體連接就可能無法成功建立,導(dǎo)致切換失敗。媒體連接建立交互圖如圖5所示。
通過抓取信令包來具體分析,以看出媒體面建立的工作原理。
圖3 VOLTE語音切換流程圖
圖4 錨定失敗信令包截圖
圖5 媒體連接建立示意圖
圖6 被叫送達(dá)失敗信令包截圖
(1)ATGW為屬于同一組realm內(nèi)的媒體實現(xiàn)連接,然后再與主被叫或切換呼叫的媒體地址連接,實現(xiàn)媒體互通。
(2)初始呼叫access realm(2)分配IPv6地址與主被叫地址互聯(lián),core realm(101)分配IPv4地址互聯(lián)。
(3)被叫切換后,仍然使用access realm(2)實現(xiàn)對外連接,而被叫地址換成了eMSS的IPv4地址。
首先從切換后的兩組realm分析,access realm(2)在切換前的呼叫中保存主被叫的IPv6地址,切換后全部替換成了IPv4地址,此時主叫的IPv6地址對應(yīng)關(guān)系也未能保存,查看rtp媒體流也可以發(fā)現(xiàn)切換后主叫媒體為單向流,而且未能送達(dá)被叫,信令截圖如圖6所示。
解決對策一:修改編碼,使SBC/TAS為INVITE添加telephone-event/8000編碼使之與被叫的183回復(fù)消息相匹配。
為解決SDP媒體參數(shù)問題,制定圖7所示的對策實施流程圖。
圖7 對策實施一流程圖
圖8 ATCF錨定失敗信令包截圖
圖9 原呼叫信令包截圖
實施步驟一:鎖定錨定失敗的環(huán)節(jié)
通過對ATCF網(wǎng)元內(nèi)部消息的跟蹤發(fā)現(xiàn)如下抓包記錄(見圖8):
從信令抓包中能夠看出,ATCF能夠匹配原呼叫的信息,在試圖進(jìn)行eSRVCC切換時報如下錯誤:
[SDP codec check][RETURN] DTR/eSRVCC is NOT possible.Enum returned value:CmpEqual_mismath
ATCF報錯后無法啟用錨定功能,只作為代理中轉(zhuǎn)了呼叫。
實施步驟二:分析具體原因
進(jìn)一步跟蹤信令發(fā)現(xiàn),ATCF未實現(xiàn)錨定功能是由于SDP codec檢查不通過。查看原呼叫的信令,被叫回復(fù)的183消息攜帶協(xié)商后的媒體攜帶AMR/8000與telephone-event/8000編碼,183消息到達(dá)主叫的ATCF后,ATCF使用這兩種編碼請求ATGW修改媒體面地址和編碼(見圖9)。
參考RFC2833與RFC2198的描述,ATCF僅僅采用單個RTP靜荷向ATGW請求分配媒體面地址。系統(tǒng)參數(shù)如下:
RFC2833:
audio/AMR
圖10 SBC現(xiàn)有媒體編碼
圖11 添加TELEPHONE-8000媒體編碼
圖12 發(fā)起錨定成功信令包截圖
MIME media type name: audio
MIME subtype name: AMR
Required parameters: none.RFC2198:
m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 AMR/8000/1
a=fmtp:121 0/5
實施步驟三:修改配置,解決問題
進(jìn)入SBC的系統(tǒng)MM腳本可以看到目前系統(tǒng)中現(xiàn)有的媒體編碼(見圖10):
從中發(fā)現(xiàn),系統(tǒng)中并未開啟telephoneevent 8000的添加功能。接著進(jìn)入?yún)?shù)配置頁面對telephone-event 8000編碼進(jìn)行添加,結(jié)果如圖11。
實施效果
編碼添加之后,再次對切換時的信令進(jìn)行跟蹤,發(fā)現(xiàn)INVITE消息已經(jīng)成功添加了telephone-event 8000編碼,ATCF正常向發(fā)起了ATGW媒體錨定請求,信令截圖如圖12。
圖13 對策二實施流程圖
圖14 核心側(cè)realm配置圖
圖15 修改接入側(cè)realm配置圖
圖16 切換成功信令包截圖
解決對策二:將接入側(cè)的realm調(diào)整為與核心側(cè)realm相同的配置
為解決接入域(access realm)參數(shù)問題,制定圖13所示的對策實施流程圖。
實施步驟一:鎖定連接建立失敗的環(huán)節(jié)
通過跟蹤信令流程鎖定了問題發(fā)生的節(jié)點:主叫方在進(jìn)行切換時需要通過ATCF向eMSS申請媒體資源,在媒體資源分配后,則開始通過eMSS建立主被叫之間的媒體通道,而問題就發(fā)生在主叫與eMSS之間的媒體建立。
實施步驟二:確認(rèn)核心側(cè)的realm配置
為了使接入側(cè)的realm配置與核心測相同,從而成功建立主被叫之間的媒體連接,首先需要明確核心側(cè)的realm配置。通過跟蹤過往語音切換流程,可以確認(rèn)當(dāng)前現(xiàn)網(wǎng)環(huán)境下的GSM核心側(cè)realm配置為realm 101,信令包如圖14所示。
實施步驟三:對接入側(cè)realm采用realm 101配置方式
要與原有呼叫媒體建立關(guān)聯(lián),在ATCF的ACCESS NETWORK表中關(guān)于eMSS行使用的接入側(cè)realm(realm2)置為與原來呼叫核心側(cè)realm(realm101)相同。修改后信令包結(jié)果如圖15。
實施步驟三:效果檢查
采取設(shè)置后,接著對語音切換信令流程進(jìn)行跟蹤,發(fā)現(xiàn)ATCF會使用eMSS發(fā)出的切換請求里面的媒體地址與端口替換掉切換方原來呼叫存在于核心側(cè)realm中的媒體地址與端口,并且與被叫方access realm建立關(guān)聯(lián),切換成功,主被叫雙方能正常通話,媒體流交互正常,對策實施成功。信令包如圖16所示。
通過以上兩項對策后,VOLTE語音切換成功率達(dá)到了93.62%,提升10.7%,取得不錯的效果。
語音切換是VOLTE網(wǎng)絡(luò)中的一項基本業(yè)務(wù)場景,本文分析了語音切換問題在現(xiàn)網(wǎng)中具有一定的典型性,隨著VOLTE技術(shù)的不斷成熟,基于VOLTE網(wǎng)絡(luò)中的語音切換的各項技術(shù)也將不斷規(guī)范和進(jìn)一步完善。
林立引
中國移動通信集團(tuán)福建公司福州分公司
林立引,中級工程師,2006年北京郵電大學(xué)計算機(jī)科學(xué)與技術(shù)專業(yè)本科專業(yè)畢業(yè),現(xiàn)任職于中國移動集團(tuán)福建公司福州分公司,主要從事軟交換、VOLTE等移動核心網(wǎng)的維護(hù)管理工作。
10.3969/j.issn.1001-8972.2016.09.016