VoLTE撥打視頻炫鈴用戶通話回屏問題分析

摘要：運(yùn)營商在做某地市網(wǎng)絡(luò)優(yōu)化撥打測試時，發(fā)現(xiàn)當(dāng)被叫用戶簽約視頻炫鈴，主叫是VOLTE用戶，并且在LTE網(wǎng)絡(luò)下呼叫時，概率性出現(xiàn)主叫終端回屏，呼叫失敗。通過信令分析發(fā)現(xiàn)某地市VoLTE通話時，主叫終端撥打簽約視頻炫鈴業(yè)務(wù)被叫概率性出現(xiàn)主叫終端回屏、通話失敗和主叫終端與視頻炫鈴平臺的媒體協(xié)商有關(guān)。當(dāng)主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴沒有成功時，炫鈴平臺為主叫播放音頻炫鈴，此時可正常通話，當(dāng)主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴成功，但由于部分無線側(cè)eNodeB基站視頻炫鈴需求的帶寬大于部分無線側(cè)eNodeB基站配置的帶寬，所以承載無法建立，導(dǎo)致主叫通話失敗。通過調(diào)整無線側(cè)eNodeB基站配置的帶寬來解決此問題。

關(guān)鍵詞：視頻炫鈴;eNodeB帶寬;max-br

（一）問題描述

運(yùn)營商在做某地市網(wǎng)絡(luò)優(yōu)化撥打測試時，發(fā)現(xiàn)當(dāng)主叫是VOLTE用戶，并且在LTE網(wǎng)絡(luò)下呼叫、被叫用戶簽約視頻炫鈴，概率性出現(xiàn)主叫終端回屏，呼叫失敗。通過信令分析發(fā)現(xiàn)某地市VoLTE通話時，主叫終端撥打簽約視頻炫鈴業(yè)務(wù)被叫概率性出現(xiàn)主叫終端回屏、通話失敗和主叫終端與視頻炫鈴平臺的媒體協(xié)商有關(guān)，測試現(xiàn)象分為以下兩種情況 ：

1. 當(dāng)主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴沒有成功時，炫鈴平臺為主叫播放音頻炫鈴，此時可正常通話。

2. 主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴成功，但由于視頻炫鈴需求的帶寬大于部分無線側(cè)eNodeB基站配置的帶寬，所以承載無法建立，導(dǎo)致主叫通話失敗。

VoLTE視頻炫鈴基本流程如下：

（1）主叫發(fā)出初始INVITE，被叫IMS域的炫鈴AS收到INVITE消息，炫鈴AS透傳主被叫消息，完成主被叫資源預(yù)留;

（2）被叫返回180，到達(dá)被叫歸屬域炫鈴AS;

（3）炫鈴AS向主叫域update炫鈴的SDP，此時炫鈴AS需判斷：主叫初始INVITE消息中的contact頭域是否包含video標(biāo)簽或SDP攜帶視頻媒體行，如果攜帶，則發(fā)起視頻炫鈴媒體更新請求;若未攜帶，則發(fā)起音頻炫鈴媒體更新請求;若主被叫初始媒體協(xié)商為視頻通話，則video媒體行下需要攜帶a=sendrecv，audio媒體行下需要攜帶a=sendrecv;若主被叫初始媒體協(xié)商為音頻通話，則video媒體行下需要攜帶a=sendonly，audio媒體行下需要攜帶a=sendrecv。媒體更新消息需攜帶support：precondition、conf要求，及precondition協(xié)商所需相關(guān)參數(shù)，不可攜帶require：precondition;

（4）主叫終端根據(jù)自身能力及狀態(tài)回復(fù)200 update，若主叫不支持precondition，將忽略炫鈴平臺update消息中的precondition參數(shù)，炫鈴平臺應(yīng)支持對該種應(yīng)答的正確處理;

（5）炫鈴AS根據(jù)主叫應(yīng)答的媒體能力播放音頻或視頻炫鈴，并轉(zhuǎn)發(fā)180消息，攜帶PEM：sendrecv;

（6）被叫UE摘機(jī)回復(fù)200 OK，炫鈴AS停止炫鈴播放，并回復(fù)ACK;

（7）炫鈴AS向被叫UE發(fā)送re-INVITE請求，不攜帶SDP信息;

（8）被叫UE對re-INVITE消息進(jìn)行應(yīng)答。此處，終端判斷本地沒有發(fā)生過網(wǎng)絡(luò)切換或視頻電話音頻摘機(jī)，終端回復(fù)與主叫初始協(xié)商時相同的媒體能力或直接回復(fù)全媒體能力。另注：此處終端也可能使用200 OK進(jìn)行應(yīng)答，也可能使用183進(jìn)行應(yīng)答，炫鈴平臺應(yīng)根據(jù)SIP協(xié)議，進(jìn)行相應(yīng)的處理。

（9）炫鈴平臺將被叫對re-INVITE消息應(yīng)答的媒體能力作為SDP offer向主叫進(jìn)行媒體更新。炫鈴平臺應(yīng)將被叫SDP的媒體行類型與主叫側(cè)當(dāng)前通話類型進(jìn)行匹配處理，再發(fā)給主叫側(cè);

（10）主叫對媒體更新進(jìn)行應(yīng)答，返回200 OK;

（11）炫鈴平臺主叫對媒體更新消息的應(yīng)答中，若主叫本地狀態(tài)已經(jīng)達(dá)到其期望的狀態(tài)，則炫鈴平臺向主叫轉(zhuǎn)發(fā)被叫摘機(jī)200 OK;若主叫本地狀態(tài)未達(dá)到其期望狀態(tài)，則炫鈴平臺根據(jù)precondition參數(shù)要求，決定是否需要等待主叫確認(rèn)資源后再轉(zhuǎn)發(fā)被叫摘機(jī)200 OK;若主叫以非precondition方式進(jìn)行應(yīng)答，則炫鈴平臺炫鈴平臺無需判斷，直接轉(zhuǎn)發(fā)被叫摘機(jī)200 OK;

（12）炫鈴平臺向被叫返回re-INVITEACK，攜帶主叫對媒體更新消息應(yīng)答的SDP信息。終端在收到該消息后，若發(fā)現(xiàn)視頻媒體行端口變?yōu)?，則需要提示被叫用戶：主叫已發(fā)生網(wǎng)絡(luò)切換，視頻通話將回落為語音通話。

（二）問題分析

關(guān)于某地市eNodeB配置的帶寬，H廠家配置10Mbps，Z廠家配置自適應(yīng)，N廠家配置3017K。測試發(fā)現(xiàn)此類呼叫失敗都集中在配置視頻業(yè)務(wù)帶寬3017K的N廠家eNodeB，并且配置3017K的N廠家eNodeB下測試主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴成功時，通話有失敗又有成功情況，信令跟蹤發(fā)現(xiàn)失敗和主叫終端回復(fù)視頻炫鈴平臺update時的200 OK消息差異有關(guān)。

N廠家eNodeB下進(jìn)行測試，信令分析詳情：

1、主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴成功時，視頻炫鈴平臺為主叫播放視頻炫鈴，后續(xù)通話正常。

根據(jù)vIMS核心網(wǎng)信令消息、EPC核心網(wǎng)信令消息、eNodeB基站信令消息看出vIMS核心網(wǎng)側(cè)SBC AAR請求消息中攜帶“codec-data： max-br=2176”，其中“max-br”為主叫終端回復(fù)炫鈴update時回復(fù)的200 OK攜帶。EPC核心網(wǎng)信令消息顯示PCRF RAR指示帶寬2176k、PGW建立的承載帶寬2176k，小于eNodeB針對QCI=2的視頻業(yè)務(wù)帶寬配置3017 k，此時視頻炫鈴平臺為主叫播放視頻炫鈴，后續(xù)通話正常。

呼叫信令里會準(zhǔn)備建立QCI=2的視頻炫鈴承載，承載建立和SBC、PCRF、PGW、eNodeB基站有關(guān)，具體帶寬請求建立詳情如下：

SBC AAR消息里帶寬請求： ‘Max-Requested-Bandwidth-DL= 2968k 且 Codec-Data 攜帶max-br=2176 k’;

PCRF RAR消息里指示帶寬：根據(jù)SBC AAR消息里帶寬請求里攜帶的“Codec-Data ?max-br=2176 k”，下發(fā)規(guī)則為承載帶寬2176 k;

PGW建立的承載帶寬：根據(jù)Gx接口中PCRF下發(fā)規(guī)則承載帶寬2176 k，建立承載帶寬2176 k;

eNodeB基站帶寬配置及分配情況：eNodeB針對QCI=2的視頻業(yè)務(wù)帶寬配置為3017 k，大于PGW建立的承載帶寬2176 k。

此時承載正常建立，播放視頻炫鈴以及后續(xù)通話正常。

2、主叫終端和視頻炫鈴平臺媒體協(xié)商視頻炫鈴成功時，由于視頻炫鈴需求的帶寬大于eNodeB配置的帶寬，所以承載無法建立，導(dǎo)致主叫通話失敗。

根據(jù)vIMS核心網(wǎng)信令消息、EPC核心網(wǎng)信令消息、eNodeB基站信令消息看出vIMS核心網(wǎng)側(cè)SBC AAR請求消息為‘Max-Requested-Bandwidth-DL=2968k’未攜帶“max-br”，（“max-br”為主叫終端回復(fù)炫鈴update時回復(fù)的200 OK攜帶）。EPC核心網(wǎng)信令消息顯示PCRF RAR指示帶寬3117k、PGW建立的承載帶寬3117k，大于eNodeB針對QCI=2的視頻業(yè)務(wù)帶寬配置3017 k，此時此時承載無法建立，導(dǎo)致主叫通話失敗。

呼叫信令里會準(zhǔn)備建立QCI=2的視頻炫鈴承載，承載建立和SBC、PCRF、PGW、eNodeB基站有關(guān)，具體帶寬請求建立詳情如下：

SBC AAR消息里帶寬請求： ‘Max-Requested-Bandwidth- DL= 2968k’;

PCRF RAR消息里指示帶寬：由于SBC AAR未攜帶Codec-Data： max-br，PCRF需要按照‘Max-Requested- Bandwidth -DL=2968k’進(jìn)行適配，加上“RTCP適配149 =0.5*2968”，總計下發(fā)規(guī)則為承載帶寬3117 k;

PGW建立的承載帶寬：根據(jù)Gx接口中PCRF下發(fā)規(guī)則承載帶寬3117 k，建立承載帶寬3117 k;

eNodeB基站帶寬配置及分配情況：eNodeB針對QCI=2的視頻業(yè)務(wù)帶寬配置為3017 k，小于PGW建立的承載帶寬3117 k。

承載無法建立，導(dǎo)致主叫通話失敗。

QCI=2 SBC 發(fā)送AAR消息對比：Max-Request-Bandwidth UL/DL 一致，呼叫失敗時SBC AAR 消息未攜帶 “codec-data： max-br=2176”。

Max-br 消息來源：

“max-br” 取決于主叫終端回復(fù)炫鈴update時的200 OK消息中是否攜帶。

（三）問題分析

當(dāng)被叫用戶簽約視頻炫鈴，主叫是VOLTE用戶，并且在LTE網(wǎng)絡(luò)下呼叫時，視頻炫鈴平臺與主叫終端進(jìn)行媒體協(xié)商，當(dāng)主叫終端回復(fù)200 OK不攜帶“max-br”時，SBC網(wǎng)元向PCRF 網(wǎng)元發(fā)送的AAR請求消息中不攜帶“max-br”，PCRF依據(jù)規(guī)則，按照SBC AAR請求消息中Max-Request-Bandwidth UL/DL 及RTCP RS/RR帶寬，針對QCI=2視頻業(yè)務(wù)下發(fā)規(guī)則確定承載帶寬為3117 k。PGW網(wǎng)元根據(jù)Gx接口中PCRF下發(fā)規(guī)則承載帶寬3117 k建立對應(yīng)承載，若出現(xiàn)EPC側(cè)建立承載帶寬大于無線側(cè)eNodeB基站配置帶寬，會出現(xiàn)EPC承載釋放、通話失敗。此類呼叫失敗都集中在配置視頻業(yè)務(wù)QCI=2帶寬為3017K的N廠家eNodeB。

當(dāng)視頻炫鈴平臺與主叫終端進(jìn)行媒體協(xié)商，主叫終端回復(fù)200 OK攜帶“max-br”時，SBC網(wǎng)元向PCRF 網(wǎng)元發(fā)送的AAR請求消息中攜帶“max-br”，PCRF依據(jù)規(guī)則，根據(jù)SBC AAR消息里帶寬請求里攜帶的“Codec-Data ?max-br”，針對QCI=2視頻業(yè)務(wù)下發(fā)規(guī)則為承載帶寬2176 k;PGW網(wǎng)元根據(jù)Gx接口中PCRF下發(fā)規(guī)則承載帶寬2176 k建立承載帶寬，EPC側(cè)建立承載帶寬小于無線側(cè)eNodeB基站配置帶寬，此時承載正常建立，播放視頻炫鈴以及后續(xù)通話正常。

（四）問題解決

1、手機(jī)終端型號繁多，處理的信令消息不便調(diào)整;

2、vIMS核心網(wǎng)SBC網(wǎng)元針對“Max-Requested -Bandwidth- DL=2968k” 帶寬設(shè)置全國一致，不建議更改;

3、呼叫失敗都集中在配置視頻業(yè)務(wù)QCI=2帶寬為3017K的N廠家eNodeB。通過調(diào)整N廠家eNodeB參數(shù)配置，增加N廠家eNodeB視頻業(yè)務(wù) QCI=2的帶寬，解決此類呼叫失敗問題。

參考文獻(xiàn)

[1]魏宗靜;;VOLTE語音質(zhì)量優(yōu)化方法研究[J];科技經(jīng)濟(jì)導(dǎo)刊;2016年05期

[2]3GPP TS 23.228 V12.3.0 IP Mutimedia Subsystem （IMS）

[3]倪浩蕩;鄧壽提;韋文仁;孫兵;蘇均垣;;VoLTE語音分組丟失原因分析及優(yōu)化策略[J];電信科學(xué);2018年S1期

[4]秦蓁，劉牧寅，孫記明.5G消息與VoLTE視頻客服業(yè)務(wù)融合方案探討[J].郵電設(shè)計技術(shù)，2021（05）：9-12.

[5]辛建國，劉洪波，王浩.VoLTE語音質(zhì)量（MOS）提升研究[J].山東通信技術(shù)，2021，41（01）：40-45.

作者簡介：郭本綎（1983.01）男，漢，甘肅蘭州，本科，高級工程師，通信