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

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

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

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

4、（multi-stimulustest with hidden reference and anchor，ITU-R recommendation BS.1534.)參考見下圖。利用傳統(tǒng)的MOS值進行AMR-NB和AMR-WB進行對比測試，結(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評分標準，評估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評分時會比傳統(tǒng)PESQ評分會低，具體映射關(guān)系如下：表從上可以看出：AMR（12.2k）/EFR POLQA評分先比PESQ評分低0.5分左右。按照上表，將2G打2G MOS(POLQA SWB)折算為PESQ MOS分應為2.64+0.5=3.14分。分析2G MOS分值，大量2分MOS分值對應的語音編碼方式為EF

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

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

8、OLQA。微信電話本在好點（-88.33dBm，12.67）下，其MoS可以達到3.78，在壞點為1.93。在壞點的條件下，其時延，抖動，丟包都在急劇上漲，用戶感知急劇降低。而VoLTE具備QoS保障，其MOS比較穩(wěn)定，無明顯波動，祥見下表。對比項目RSRPSINR端到端時延（POLQA）抖動（ms）丟包率（%）最大連續(xù)丟包數(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為進一步對其微信電話本的語音MOS值進行分析，找出其能力拐點，優(yōu)化人員對其RSRP的從-125dBm到-110dBm，SINR從-4到10的范圍進行測試，詳見下圖。從RSRP走勢中可以看出:在RSRP-110dBm，SINR 10的在LTE輕載網(wǎng)絡環(huán)境下，MOS可以保持在3.5以上。當RSRP-111dBm的時候，語音質(zhì)量會出現(xiàn)大幅提升，MoS會大于3.22，已經(jīng)超過了GSM的MoS，其音質(zhì)和VoLTE AMR-WB在感知上差異不大。從SINR走勢中可以看出，其在3的時候，其質(zhì)量會出現(xiàn)大幅提升，MoS會到2.85以上，已經(jīng)超過GSM的EFR

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

11、的資源占用情況。微信電話本和VoLTE高清語音的網(wǎng)絡好點資源占用對比類型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)絡差點資源占用對比（下行）類型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微信語音包走默認承載，沒有RoHC功能，語音包大于VoLTE，與不打開RoHC的 VoLTE語音包相似）。RoHC功能開啟對VoLTE語音包壓縮參見下表。語音AMR封裝負荷RTPUDPIPPDCP頭R

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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