VoLTE語音質(zhì)量優(yōu)化案例

1、 VoLTE語音質(zhì)量優(yōu)化案例1：VoLTE窄帶與寬帶語音質(zhì)量對比【問題現(xiàn)象】在3GPP LTE中，VoLTE業(yè)務(wù)編碼有AMR-NB窄帶和AMR-WB寬帶兩種編碼，兩種編碼速率具有不同的話音質(zhì)量，所以又分別稱為VoLTE標(biāo)清語音（或VoLTE 12.2kbps）和VoLTE高清語音（或VoLTE 23.85kbps）?！締栴}分析】AMR-NB和AMR-WB這2種編碼具有如下特點(diǎn)：l 每20ms產(chǎn)生一個(gè)語音包，包括了RTP/UDP/RLC-Security壓縮頭；l 每160ms生成一個(gè)SID語音靜默包。l 幀長20ms；AMR-NB編碼特點(diǎn)為：l 4.75kbps到12.2kbps共8個(gè)碼率，分

2、別為：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；l 采樣率為8kHz。AMR-WB編碼特點(diǎn)為：l 6.6kbps到23.85kbps共8個(gè)碼率，分別為：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；l 采樣率為16kHz?？梢妰烧唢@著的差異是采樣速率不一樣，窄帶一個(gè)語音幀是160個(gè)點(diǎn)，寬帶一個(gè)語音幀采樣320個(gè)點(diǎn)。AMR NB的語音帶寬范圍：3003400Hz，8KHz采樣。AMR WB的語音帶寬范圍：507000Hz，16KHz采樣。用戶可主觀感受到話音比以前更加自然、舒適和易于分辨。AM

3、R WB與AMR NB不同之處在于AMR WB按16kHz采樣，分別按頻率帶506400Hz和64007000Hz 進(jìn)行編碼。用來降低復(fù)雜度，AMR WB將位算法集中到更重要的頻率區(qū)。低頻帶使用ACELP算法進(jìn)行編碼。 添加幾個(gè)特征來達(dá)到一個(gè)高的主觀質(zhì)量。 線性預(yù)測（LP）算法是在每隔20ms 的幀要進(jìn)行一次線性預(yù)測算法，每5ms搜索一次自適應(yīng)碼本，這個(gè)過程是在12.8Kbs 速率下進(jìn)行。高頻帶是在解碼器端使用低帶和隨機(jī)激勵(lì)的參數(shù)重建的, 目的是調(diào)整與在聲音基礎(chǔ)上的低頻有關(guān)的高頻帶. 高頻帶的聲頻通過使用由低帶LP 過濾器產(chǎn)生的LP 濾波器進(jìn)行重建。AMR WB與AMR NB的MUSHRA評分

4、（multi-stimulustest with hidden reference and anchor，ITU-R recommendation BS.1534.)參考見下圖。利用傳統(tǒng)的MOS值進(jìn)行AMR-NB和AMR-WB進(jìn)行對比測試，結(jié)果如下圖：由以上分析可見AMR-WB比AMR-NB有更高的話音質(zhì)量。【問題解決】 在語音質(zhì)量上AMR-WB更優(yōu)于AMR-NB，因此AMR-WB又稱為高清語音。案例2：VoLTE與GSM語音質(zhì)量比較【問題現(xiàn)象】杭州現(xiàn)場使用POLQA SWB評分標(biāo)準(zhǔn)，評估GSM打GSM，VoLTE（23.85kbps）和VoLTE（12.65kbps）三種長呼語音質(zhì)量，VoL

5、TE MOS相比GSM有較大改善，MOS評分參見下表。語音撥打類型MOS(POLQA SWB)2G打2G2.64VoLTE（23.85kbps）3.98VoLTE（12.65kbps）3.84【問題分析】2G使用窄帶語音AMR-NB 12.2k和EFR編碼方式，使用POLQA SWB評分時(shí)會(huì)比傳統(tǒng)PESQ評分會(huì)低，具體映射關(guān)系如下：表從上可以看出：AMR（12.2k）/EFR POLQA評分先比PESQ評分低0.5分左右。按照上表，將2G打2G MOS(POLQA SWB)折算為PESQ MOS分應(yīng)為2.64+0.5=3.14分。分析2G MOS分值，大量2分MOS分值對應(yīng)的語音編碼方式為EF

6、R，AMR 12.2k編碼MOS分一般在3分左右?！締栴}解決】POLQA SWB評分按照64Kbps采樣率進(jìn)行語音質(zhì)量評分，評分標(biāo)準(zhǔn)比傳統(tǒng)PESQ高。同樣的2G語音， POLQA評分先比PESQ評分低0.5分左右。案例3：VoLTE與OTT語音質(zhì)量比較【問題現(xiàn)象】微信電話本是騰訊公司在2014年11月11日推出的基于微信的VoIP電話，其具有低接通時(shí)延、無通信費(fèi)用（僅有流量費(fèi)用）和高清晰音質(zhì)等特點(diǎn)。微信電話本對語音業(yè)務(wù)有很強(qiáng)的替代作用。對微信電話本和VoLTE電話進(jìn)行了對比測試，分析其產(chǎn)品差異?！締栴}分析】VoLTE試點(diǎn)區(qū)域內(nèi)共有4G基站400個(gè)，主覆蓋區(qū)域?yàn)镈頻段，覆蓋良好。使用設(shè)備為ASC

7、OM公司的TEMS16.1.3，測試手機(jī)為HTC M8t。1、音質(zhì)對比分析從現(xiàn)有的PDCP層速率和MoS進(jìn)行推測，微信電話本采用的編碼為skype的SILK Codec。SILK Codec是一個(gè)語音和音頻編解碼算法, 對于音頻帶寬、網(wǎng)絡(luò)帶寬和算法復(fù)雜度都具有很好的彈性，支持4種采樣率：8KHz、12KHz、16KHz、24KHz；三種復(fù)雜度：低、中、高。編碼碼率在 640kbps（不同采樣率具有不同的碼率范圍）以及還支持VAD、DTX、FEC等模塊，已經(jīng)在QQ，AIM，GOOGLE TALk上使用，性能在高掉包環(huán)境下優(yōu)于AMR-WB。為適應(yīng)其編碼方式，這里采用的打分標(biāo)準(zhǔn)使用基于48K采樣的P

8、OLQA。微信電話本在好點(diǎn)（-88.33dBm，12.67）下，其MoS可以達(dá)到3.78，在壞點(diǎn)為1.93。在壞點(diǎn)的條件下，其時(shí)延，抖動(dòng)，丟包都在急劇上漲，用戶感知急劇降低。而VoLTE具備QoS保障，其MOS比較穩(wěn)定，無明顯波動(dòng)，祥見下表。對比項(xiàng)目RSRPSINR端到端時(shí)延（POLQA）抖動(dòng)（ms）丟包率（%）最大連續(xù)丟包數(shù)（%）控制面切換中斷時(shí)延MOS微信電話本-88.3312.67無7.210.332.0035.623.78-116.970.941151.0028.444.73無數(shù)據(jù)1.93VoLTE-89.5311.72255.148.130.093.4031.313.86-114.8

9、30.53227.365.930.252.003.89為進(jìn)一步對其微信電話本的語音MOS值進(jìn)行分析，找出其能力拐點(diǎn)，優(yōu)化人員對其RSRP的從-125dBm到-110dBm，SINR從-4到10的范圍進(jìn)行測試，詳見下圖。從RSRP走勢中可以看出:在RSRP-110dBm，SINR 10的在LTE輕載網(wǎng)絡(luò)環(huán)境下，MOS可以保持在3.5以上。當(dāng)RSRP-111dBm的時(shí)候，語音質(zhì)量會(huì)出現(xiàn)大幅提升，MoS會(huì)大于3.22，已經(jīng)超過了GSM的MoS，其音質(zhì)和VoLTE AMR-WB在感知上差異不大。從SINR走勢中可以看出，其在3的時(shí)候，其質(zhì)量會(huì)出現(xiàn)大幅提升，MoS會(huì)到2.85以上，已經(jīng)超過GSM的EFR

10、的MoS，當(dāng)SINR提升到9的時(shí)候，其值已經(jīng)和VoLTE差距不大。下圖4個(gè)波形分為標(biāo)準(zhǔn)語料，GSM波形，VoLTE波形和微信波形。微信語音壓縮方法與2G/4G不一樣，微信語音對標(biāo)準(zhǔn)語料毛刺部分壓縮比較干凈，將標(biāo)準(zhǔn)語音樣本中的背景噪聲被簡單給過濾掉了，故MOS峰值較低。在同樣的MOS分下，用戶可能會(huì)覺得微信聲音更加干脆清澈。 測試標(biāo)準(zhǔn)語料GSM語音波形 VoLTE 23.85高清語音波形 微信電話本語音波形2、容量對比分析微信電話本采用SLIK編碼，具備VAD、DTX、FEC能力，具備不連續(xù)發(fā)射，靜默期檢查，前向糾錯(cuò)能力。微信電話本傳輸效率要低于VoLTE。下表為微信電話本和VoLTE在好點(diǎn)時(shí)候

11、的資源占用情況。微信電話本和VoLTE高清語音的網(wǎng)絡(luò)好點(diǎn)資源占用對比類型SINR下行上行物理層速率（kbps）PDCP速率（kbps）平均MCSRB數(shù)TB size（bite）物理層速率（kbps）PDCP速率（kbps）MCSRB數(shù)TBsize（bite）微信電話本18.2658.1440.2719.773.281268.2452.7640.3322.452.51285.14VoLTE20.0218.211.1315.262.8819.4721.8211.2122.011.681086.69微信語音每TTI調(diào)度RB數(shù)和VoLTE（23.85k）基本近似，微信沒有語音靜默包，每TTI調(diào)度次數(shù)明

12、顯高于VoLTE，微信語音總調(diào)度RB數(shù)明顯高于VoLTE。微信電話本和VoLTE高清語音的網(wǎng)絡(luò)差點(diǎn)資源占用對比（下行）類型SINR物理層速率（下行）PDCP速率（下行）傳輸模式MCS每TTI RB數(shù)總調(diào)度RB數(shù)TB size微信電話本-0.0950.4836.232.006.3111.94910.89668.44VoLTE0.0215.6110.442.154.958.78227.22590.79微信語音包走默認(rèn)承載，沒有RoHC功能，語音包大于VoLTE，與不打開RoHC的 VoLTE語音包相似）。RoHC功能開啟對VoLTE語音包壓縮參見下表。語音AMR封裝負(fù)荷RTPUDPIPPDCP頭R

13、LC頭MAC頭TotalVoLTE 23.85477+21966432088161010VoLTE 23.85（RoHC）477+21408816570微信語音沒有語音靜默包，不具備頭壓縮功能，導(dǎo)致微信PDCP速率（40k左右）高于VoLTE（10k左右）。按好點(diǎn)的包大小計(jì)算，微信語音每分鐘消耗流量為（40.27+40.33）*60/8=600kbyte，其通話一個(gè)小時(shí)占用流量為35Mbytes。如按移動(dòng)的50元1G進(jìn)行收費(fèi)，其50元可以通話1700分鐘左右，折合3分錢/分鐘，且無長途，漫游費(fèi)用，其資費(fèi)優(yōu)勢明顯。在差點(diǎn)時(shí)，微信語音掉包和時(shí)延會(huì)惡化，資源占用會(huì)加大。從現(xiàn)網(wǎng)測試情況看：在-110d

14、Bm，SINR=0的情況下，會(huì)占用12個(gè)RB,資源占用增加了三倍，VoLTE占用9個(gè)RB。在資源緊張時(shí)，VoLTE有QoS保障機(jī)制，語音各項(xiàng)指標(biāo)會(huì)遠(yuǎn)好于微信電話本。從無線環(huán)境和微信電話本語音包大小進(jìn)行走勢對比，可以清楚的發(fā)現(xiàn)：當(dāng)其無線環(huán)境好的時(shí)候，其語音包較大，語音采樣編碼方式越高，語音越清晰，用戶感知越好。當(dāng)無線環(huán)境惡化時(shí)，語音采樣編碼方式變差，用戶感知不好。案例4：小區(qū)邊緣通話時(shí)下行BLER較高導(dǎo)致質(zhì)差【問題現(xiàn)象】統(tǒng)計(jì)發(fā)現(xiàn)，愛立信VoLTE測試的DL BLER在SINR低于-2dB后嚴(yán)重下降，高于10%?！締栴}分析】其他廠家多在8天線的環(huán)境下測試，而愛立信的測試結(jié)果都是在2天線的環(huán)境下測試

15、得出，少了波束賦形的增益?！締栴}解決】在8天線的環(huán)境下，DL BLER有了較大的提高，在SINR=-6左右也沒有達(dá)到10%?！締栴}后續(xù)建議】在8天線的環(huán)境下，DL BLER的指標(biāo)有大幅提升，BLER控制在10%之內(nèi)。廠家應(yīng)針對2天線環(huán)境提出相應(yīng)的算法改進(jìn)，保證網(wǎng)絡(luò)質(zhì)量。案例5： ZUC算法開啟導(dǎo)致R8終端通話8S自動(dòng)中斷【問題現(xiàn)象】用HTC M8對在目前LTE弱覆蓋或信號(hào)質(zhì)量差的網(wǎng)絡(luò)環(huán)境下的通話質(zhì)量進(jìn)行MOS評估時(shí)，發(fā)現(xiàn)通話撥打8S左右通話中斷，手機(jī)進(jìn)入FAST BOOT工程模式。更換站點(diǎn)后恢復(fù)，再回到問題站點(diǎn)撥打電話，分析基站側(cè)EMIL包（EMIL為諾基亞內(nèi)部用于分析基站側(cè)log的一個(gè)工具）

16、后發(fā)現(xiàn)該基站祖沖之ZUC加密算法開關(guān)打開，且ZUC算法優(yōu)先級(jí)為最高?！締栴}分析】更改站點(diǎn)后手機(jī)通話恢復(fù)正常，可以判斷為站點(diǎn)問題。在后臺(tái)檢查后發(fā)現(xiàn)該基站并無告警，排除由硬件故障造成的通話問題。由EMIL包中ATTACH REQUEST里UE CAPBILITY列出終端支持使用ZUC算法。（注意EEA3與EIA3的值都為1）為確定M8在該站下是否使用ZUC算法，通話先在其他站點(diǎn)建立后再切換進(jìn)問題站點(diǎn)，從切換請求中可以看出切換后進(jìn)入問題站點(diǎn)選擇的加密算法為EEA3、EIA3，且切換完成6S后手機(jī)進(jìn)入FAST BOOT模式。確定問題為ZUC算法的啟用導(dǎo)致。（下圖為切換入問題站點(diǎn)后選擇的加密算法，基站R

17、10以前的版本是spare5，R11后改成了eea3和eia3）由于ZUC是3GPP R9才加入的算法，故R9之前的終端并不支持ZUC算法。部分R9的終端（如HTC M8）并不完全支持在ZUC算法開啟下進(jìn)行所有業(yè)務(wù)?！締栴}解決】通過后臺(tái)關(guān)閉ZUC算法，問題解決。案例6：基站不支持VoLTE功能導(dǎo)致切換掉話【問題現(xiàn)象】終端無線鏈路失敗后在PCI329上重新建立RRC連接，網(wǎng)絡(luò)側(cè)沒有建立專用承載，5s之后網(wǎng)絡(luò)側(cè)發(fā)送SIP BYE 503 導(dǎo)致掉話?！締栴}分析】問題出現(xiàn)的過程如下圖，當(dāng)MO/MT UE在PCI 343上出現(xiàn)無線鏈路失敗后，在PCI 329上進(jìn)行重建，被拒絕。之后同時(shí)在PCI 329上

18、建立RRC連接，但是網(wǎng)絡(luò)側(cè)并沒有建立專用UM承載，RTP在AM承載上傳輸5s之后，MO/MT UE收到IMS發(fā)送的SIP BYE 503消息，原因是“Session released - loss of bearer”。進(jìn)一步確定站點(diǎn)的位置，如下圖，我們可以發(fā)現(xiàn)PCI 329在試驗(yàn)區(qū)域之外，存在越區(qū)覆蓋現(xiàn)象。該站未開啟VoLTE功能。【問題解決】首先應(yīng)保證測試過程中終端收到信號(hào)的所有基站均支持VoLTE功能。其次應(yīng)對網(wǎng)絡(luò)進(jìn)行優(yōu)化，盡量減少越區(qū)覆蓋。此外，在VoLTE開通的過程中，應(yīng)保證成片開通。案例7：跨MME定時(shí)器超時(shí)導(dǎo)致切換失敗率高【問題現(xiàn)象】麗水VoLTE測試區(qū)域采用新建D頻段基站區(qū)域，

19、為避免對現(xiàn)網(wǎng)影響，核心網(wǎng)側(cè)采用單獨(dú)的MME進(jìn)行管理，與現(xiàn)網(wǎng)F頻段基站分屬不同的MME。測試中通過網(wǎng)管統(tǒng)計(jì)發(fā)現(xiàn)F頻段與D頻段間的S1切換成功率較低，從核心網(wǎng)側(cè)信令看基站側(cè)頻繁進(jìn)行S1切換請求和切換取消，見下圖： 【問題分析】根據(jù)核心網(wǎng)信令對應(yīng)失敗的基站ID，分析基站側(cè)的日志文件，發(fā)現(xiàn)目標(biāo)基站每收到一條HO REQUEST都回復(fù)了HO REQUEST ACK，沒有FAILURE的消息，表明目標(biāo)側(cè)沒有處理失敗的；而源側(cè)基站發(fā)送了HO REQURIED消息后，沒有收到MME反饋回來的Ho Command消息，之后S1切換準(zhǔn)備定時(shí)器超時(shí)后，源基站發(fā)起了Ho Cancel，從而導(dǎo)致切換失敗，即切換的消息交

20、互需要的時(shí)間較長，原因是兩個(gè)基站處在不同的MME下?！締栴}解決】麗水VoLTE測試基站下掛在杭州MME下，與本地MME不在同一個(gè)POOL內(nèi)，切換需要時(shí)間較長。為了避免定時(shí)器切換超時(shí)，可以將基站側(cè)的S1切換準(zhǔn)備定時(shí)器修拉長進(jìn)行規(guī)避解決?！締栴}后續(xù)建議】因該類切換為跨MME切換，完成切換需交互時(shí)間變長，為了避免定時(shí)器切換超時(shí)造成切換失敗，將基站側(cè)的S1切換準(zhǔn)備定時(shí)器調(diào)整到3s解決。案例8：基站版本不同導(dǎo)致站間切換失敗【問題現(xiàn)象】在進(jìn)行室內(nèi)外切換測試中，室外站為Band 38（EARFCN 37900，PCI 48），R10版本，室內(nèi)站為Band40（EARFCN 38950，PCI 0），R8版本

21、。當(dāng)進(jìn)行室外站至室內(nèi)站切換時(shí)，出現(xiàn)RLF導(dǎo)致切換失敗?！締栴}分析】如下圖所示的信令，當(dāng)UE駐留在PCI48（室外站）站上時(shí)，該eNB為UE配置的AntennaInfo參數(shù)為AntennaInfo-r10格式。但是當(dāng)UE切換至R8版本的PCI0（室內(nèi)站）的過程中，eNB下發(fā)給UE的重配置消息中的AntennaInfo字段為AntennaInfo格式（即r8格式），而不是一個(gè)完整的配置，如下圖信令：UE對收到的切換命令進(jìn)行檢查時(shí)，發(fā)現(xiàn)對antennaInfo參數(shù)的配置不正確而導(dǎo)致切換失敗，從而觸發(fā)RLF?！締栴}解決】按照標(biāo)準(zhǔn)要求，在往低版本基站的切換命令中再增加一個(gè)內(nèi)容為空的AntennaInfo

22、-r10字段。附：3GPP 36.311中如下規(guī)定此種情形。案例9：跨廠家站點(diǎn)間切換失敗【問題現(xiàn)象】在跨廠家區(qū)域做切換驗(yàn)證，從諾基亞到中興切換都成功，中興小區(qū)(PCI=29)到諾基亞小區(qū)（PCI=264），切換均失敗，原因?yàn)榫W(wǎng)路側(cè)配置錯(cuò)誤?！締栴}分析】如下圖所示的信令，當(dāng)UE駐留在PCI29小區(qū)時(shí)，該eNB為UE配置的AntennaInfo參數(shù)為AntennaInfo-r10格式。當(dāng)UE切換至諾基亞小區(qū)PCI=264的時(shí)候，eNB下發(fā)給UE的重配置消息中的AntennaInfo字段為AntennaInfo格式（即r8格式），而不是一個(gè)完整的配置，如下圖信令：UE對收到的切換命令進(jìn)行檢查時(shí)，發(fā)現(xiàn)

23、對antennaInfo參數(shù)的配置不正確而導(dǎo)致切換失敗，從而觸發(fā)RLF?！締栴}解決】9月中旬外場升級(jí)了基站版本。升級(jí)后用高通終端驗(yàn)證室內(nèi)外切換均正常。案例10：QoS配置不全導(dǎo)致切換失敗【問題現(xiàn)象】測試發(fā)現(xiàn)愛立信pci440小區(qū)與pci89小區(qū)之間切換失敗。【問題分析】復(fù)測之后回放log，發(fā)現(xiàn)VoLTE掉話頻繁出現(xiàn)在pci440與pci89的兩個(gè)小區(qū)切換的時(shí)候。UE在從pci440的小區(qū)往pci89的小區(qū)切換的時(shí)候，專載被釋放。檢查了pci89的配置，雖然在同一個(gè)MME pool下，雖打開了VoLTE功能，但基站側(cè)并沒有做VoLTE所需的QoS配置（Multiple ERAB per user

24、，RoHC，RLC UM等）。其中如果沒有Multiple ERAB per user的話，基站側(cè)將不會(huì)支持多個(gè)ERAB的建立，從而導(dǎo)致專用承載的釋放。在VoLTE站點(diǎn)pci440與非VoLTE站點(diǎn)pci89的切換過程中，由于關(guān)鍵的VoLTE QoS配置的缺失，造成網(wǎng)絡(luò)側(cè)釋放專載?！締栴}解決】該站點(diǎn)做了VoLTE所需的QoS配置后，切換正常。案例11：上行鏈路干擾導(dǎo)致VoLTE呼叫成功率低【問題現(xiàn)象】在定點(diǎn)測試所選擇的某干擾嚴(yán)重基站，基站所接收到的干擾功率高達(dá)-69dBm，導(dǎo)致RRC連接不能正常建立，VoLTE的呼叫建立成功率僅為5%?！締栴}分析】我們分析測試log也可以看出，在此上行干擾嚴(yán)重

25、的場景下，下行物理層重傳比例很大，BLER非常高。同時(shí)，由下圖可以看出，由于未配置TPC Command或TPC Command=0，網(wǎng)絡(luò)無法快速地提高PUSCH的發(fā)射功率。針對干擾功率高的問題，首先排查該站點(diǎn)天面情況如下圖，我們可以發(fā)現(xiàn)在移動(dòng)TD-LTE站點(diǎn)天面的旁邊存在電信FDD-LTE站點(diǎn)，兩者天線距離較近，隔離度不夠，電信Band 3 FDD-LTE的下行信號(hào)(1860 -1875MHz)對中國移動(dòng)Band 39 TD-LTE的上行信號(hào)(1880 -1900MHz)存在干擾。從TD-LTE的eNB側(cè)統(tǒng)計(jì)的底噪（見下圖）也可以看出，此站點(diǎn)存在明顯的雜散干擾，與FDD頻段對TDD頻段的雜散

26、干擾相吻合?！締栴}解決】建議全面排查Band 39基站上行鏈路的干擾水平。對于干擾嚴(yán)重的站點(diǎn)，采取相應(yīng)措施，如調(diào)整天線位置，增加隔離度等?！締栴}后續(xù)建議】對于異常項(xiàng)目測試，修改配置未能做好記錄和管理，導(dǎo)致影響到正常用例測試。后續(xù)將做好配置修改的記錄和管理工作。案例12：VoLTE終端被叫按CSFB接通【問題現(xiàn)象】 在高通測試的過程中，被叫經(jīng)常收到CS paging，發(fā)生CS fall back。【問題分析】 在VoLTE普通撥測過程中，經(jīng)常出現(xiàn)被叫CSFB的情況，如信令截圖所示，收到CS paging，然后開始CSFB的流程，并不是預(yù)期的VoLTE通話。復(fù)現(xiàn)問題，從IMS節(jié)點(diǎn)抓包分析：可以看到

27、在主叫發(fā)起invite之后，被叫回復(fù)的SIP信令100trying當(dāng)中，這個(gè)通話并不被認(rèn)為是VoLTE通話。再追溯原因，發(fā)現(xiàn)IMS在TADS查詢的時(shí)候失敗，繼續(xù)查CSRN時(shí)返回“diameter unable to comply”，因此TADS回復(fù)的是2/3G，這個(gè)通話被認(rèn)為是2/3G的通話產(chǎn)生這個(gè)現(xiàn)象的原因是：l 被叫終端設(shè)置為2/3/4G模式，因而在經(jīng)過某些4G弱信號(hào)點(diǎn)時(shí)，會(huì)暫時(shí)重選登上2G網(wǎng)絡(luò)，回到4G信號(hào)好點(diǎn)時(shí)會(huì)自動(dòng)返回4G。l 2G回到4G的過程中，4G TAU流程會(huì)觸發(fā)網(wǎng)絡(luò)側(cè)流程，通過HSS向HLR發(fā)起Cancel Location清除用戶原本在2G的位置信息。在GZUDC06的默

28、認(rèn)配置里，HSS以輪詢方式選擇HLR13、HLR14執(zhí)行Cancel Location操作。由于南沙HSS13（包括HLR13）VoLTE調(diào)測并未完成，導(dǎo)致HSS選擇HLR13進(jìn)行Cancel Location時(shí)不能完全成功，用戶在2G的位置信息會(huì)殘留在系統(tǒng)中。l 雖然該用戶早已經(jīng)回到4G并成功注冊，上述的2G位置信息殘留會(huì)導(dǎo)致錯(cuò)誤的被叫域選，因此出現(xiàn)了被叫CSFB的情況?！締栴}解決】 該問題在調(diào)整HSS配置后解決，網(wǎng)絡(luò)Cancel Location功能恢復(fù)正常，VoLTE被叫域選正確，不再出現(xiàn)CSFB呼叫。案例13：不同速率自適應(yīng)語音編碼【問題現(xiàn)象】在RTP包的凈荷中包含四個(gè)bit表達(dá)CMR

29、(codec mode request)編碼模式請求，由發(fā)送者向接受者的請求發(fā)送者編碼器將來的編碼速率模式，保存幀類型索引，如果是AMR，取值范圍為0-7，表示8種速率模式，如果為AMR-WB，取值范圍為0-8，表示9種速率。取值15意味著當(dāng)前是沒有指定哪個(gè)模式的請求。【問題分析】寬帶語音編碼速率自適應(yīng)有兩種方式：（1）終端自身觸發(fā)；（2）基站側(cè)的ECN（Explicit Congestion Notification）顯示擁塞指示來觸發(fā)UE修改自己的編碼速率。對于ECN，在IMS SDP協(xié)商時(shí)，終端需要將其支持ECN機(jī)制的能力通知給網(wǎng)絡(luò)。通過IP使用包頭中的未使用字段來支持ECN。IP包頭中

30、的8位的服務(wù)類型域(TOS)原先在RFC791中被定義為表明包的發(fā)送優(yōu)先級(jí)，時(shí)延，吞吐量，可靠性和消耗等特征。在RFC2474中被重新定義為包含一個(gè)6位的區(qū)分服務(wù)碼點(diǎn)(DSCP)和兩個(gè)未用的位。當(dāng)UE B決定激活ECN時(shí)， UE B就在IP頭ECN位打上“01”或“10”，當(dāng)eNB A擁塞時(shí)，就會(huì)將ECN位設(shè)置為“11”。當(dāng)UE A收到“11”的IP后，UE A就會(huì)在TCP的Ack 消息里面設(shè)置 ECN-echo標(biāo)識(shí)。當(dāng) UE B收到ECN-Echo標(biāo)識(shí)的ACK消息后，UE B就會(huì)降低速率。ECN功能用于語音在TS 26.114中有描述，當(dāng)發(fā)生大量丟包時(shí)，可以采用ECN功能降低包大小，需要通過

31、CMR告知編碼端，從而增加覆蓋語音的覆蓋。編碼速率越高，語音質(zhì)量越好，但是抗干擾能力越弱，所以根據(jù)信道傳輸狀況優(yōu)化編碼類型，可以提供更好的話音質(zhì)量。AMR在傳輸情況較好的情況下，更多的bit用來傳送話音。增加網(wǎng)絡(luò)容量及提升覆蓋：在弱覆蓋區(qū)域采用bit數(shù)目較少的編碼方式可吸收更多話務(wù)提高網(wǎng)絡(luò)容量且能保證一定的語音質(zhì)量。在邊緣的時(shí)候采用較少bit數(shù)目的編碼方式對網(wǎng)絡(luò)的干擾也會(huì)減少。如下圖所示，寬帶編碼速率自適應(yīng)，主要是在近點(diǎn)采用較高的編碼速率，在邊緣采用較低的編碼速率，Link Adaptation可以和Power Control并行，對切換也沒有影響，因?yàn)閳?zhí)行兩者的輸入不同?！締栴}解決】采用自適

32、應(yīng)速率編碼設(shè)置，以使得語音的容量和質(zhì)量達(dá)到合理的目標(biāo)。案例14：終端側(cè)Invite信令丟失導(dǎo)致呼叫建立過長【問題現(xiàn)象】在呼叫時(shí)延問題排查中，出現(xiàn)由于invite信令丟失多次重發(fā)導(dǎo)致時(shí)延過長現(xiàn)象?！締栴}分析】1、抓取UE側(cè)的原始報(bào)文，在wireshark中通過 (sip) & (sip.Method = INVITE)過濾出所有的invite信令，發(fā)現(xiàn)UE側(cè)接著發(fā)了下圖標(biāo)記的三條一樣invite信令（包序號(hào)分別為2194、2196、2198，每條invite信令都分成了兩片，第一片分別是2193、2195、2197）。在第一條invite 信令前有一個(gè)ACK信令（包序號(hào)為2192）。 對比這三條invite信令，除了IPV6頭擴(kuò)展頭的Identification字段不一樣(第一個(gè)invite信令是的Identification是0x0163,第二個(gè)是0x0164，第 三個(gè)是0x0165