VoLTE維護(hù)優(yōu)化叢書

1、第1章 VoLTE網(wǎng)絡(luò)配置篇無(wú)線測(cè)試涉及的網(wǎng)絡(luò)參數(shù)如下表所示：第2章 廠家個(gè)性VoLTE質(zhì)量問(wèn)題篇問(wèn)題1：IMS無(wú)法注冊(cè)的可能原因？答：手機(jī)附著LTE網(wǎng)絡(luò)并成功建立QCI9承載后PDN connectivity reject,無(wú)法建立QCI5默認(rèn)承載，將導(dǎo)致無(wú)法成功注冊(cè)IMS。如下圖所示：手機(jī)attach request -attach complete過(guò)程已經(jīng)建立QCI=9的信令承載，UE會(huì)在PDN Connectivity Request消息中包含APN信息，從HSS取得的訂閱信息中，Service-Selection=wildcard，所以MME接受UE請(qǐng)求的 APN。根據(jù)新的APN，分

2、配一個(gè)Bearer ID給default EPS，并且發(fā)送Create Session Bearer Request 到 S-GW。S-GW會(huì)在它的EPS Bearer 表中創(chuàng)建一個(gè)新的實(shí)體，并且發(fā)送Create Session Request到 P-GW中。S-GW會(huì)為Control Plane和User Plane創(chuàng)建新的DL S-GW TEID并且把他們發(fā)送到P-GW，創(chuàng)建QCI5默認(rèn)承載。因此PDN CONECTIVITY REJECT會(huì)導(dǎo)致無(wú)法建立QCI5的默認(rèn)承載，直接導(dǎo)致IMS無(wú)法注冊(cè)。1）如果是ESM過(guò)程導(dǎo)致的拒絕（比如默認(rèn)承載建立失?。艜?huì)帶PDN CONNECTIVITY

3、 REJECT消息，EMM層拒絕，只有ATTACH REJECT消息。2）如果拒絕原因值是unknown EPS bearer context，UE會(huì)本地去激活存在的默認(rèn)承載或?qū)Ｓ贸休d3）常見的拒絕原因有：IMSI中的MNC與核心網(wǎng)配置的不一致。以下為可能的解決方法：1： 檢查核心網(wǎng)和eNB側(cè)是否存在相關(guān)告警并及時(shí)處理2：查看拒絕原因，核查相應(yīng)參數(shù)是否配置正確（IMSI中的MNC與核心網(wǎng)配置的不一致, APN的設(shè)置不當(dāng)?shù)葐?wèn)題）3：是否存在SIM問(wèn)題及核心網(wǎng)對(duì)SIM卡實(shí)行限制相應(yīng)功能及接入等級(jí)4：SIM卡和核心網(wǎng)HSS記錄信息不一致導(dǎo)致無(wú)法注冊(cè)5：PDN請(qǐng)求拒絕大部分是核心網(wǎng)問(wèn)題，可以通過(guò)抓取信

4、令分析問(wèn)題2: VoLTE中呼叫前轉(zhuǎn)、呼入限制等補(bǔ)充業(yè)務(wù)由哪個(gè)網(wǎng)元提供數(shù)據(jù)配置？答: Ut AS是提供業(yè)務(wù)邏輯和業(yè)務(wù)執(zhí)行的應(yīng)用服務(wù)器，VoLTE中使用其進(jìn)行UE到業(yè)務(wù)AS的業(yè)務(wù)數(shù)據(jù)管理配置，提供設(shè)置、取消業(yè)務(wù)數(shù)據(jù)，激活、去激活業(yè)務(wù)等功能。UE與Ut AS間的接口稱為Ut接口，使用XCAP協(xié)議，提供補(bǔ)充業(yè)務(wù)數(shù)據(jù)配置功能。Ut AS包含網(wǎng)絡(luò)應(yīng)用功能（NAF, Network Application Function）與引導(dǎo)服務(wù)器功能（BSF, Boot Strapping Function）兩項(xiàng)主要功能實(shí)體，提供用戶鑒權(quán)認(rèn)證與業(yè)務(wù)鑒權(quán)認(rèn)證，AS選擇和路由重定向功能。其接口流程如下圖：UE到NAF之

5、間的補(bǔ)充業(yè)務(wù)配置消息主要是GET或PUT消息，這些消息在經(jīng)過(guò)NAF完成業(yè)務(wù)認(rèn)證通過(guò)后，轉(zhuǎn)發(fā)到相應(yīng)的AS。GET信息主要用于獲取補(bǔ)充業(yè)務(wù)的信息，PUT消息主要用于設(shè)置補(bǔ)充業(yè)務(wù)(激活/去激活/修改)，其主要攜帶參數(shù)包括：Request URI、X-3GPP-Asserted-Identity、Host、Authorization、Content-Type。其中，Authorization參數(shù)是UE發(fā)給NAF中攜帶用于鑒權(quán)，NAF(AP)發(fā)給AS(AP)的消息中不需攜帶此參數(shù)。其中Request-Line參數(shù)中攜帶的UtapplicationID信息，以及Host參數(shù)與Authorization參數(shù)

6、中攜帶的NAF與BSF域名信息，UE側(cè)配置需與網(wǎng)絡(luò)側(cè)配置相同。測(cè)試中發(fā)現(xiàn)呼入限制、呼叫轉(zhuǎn)移等補(bǔ)充業(yè)務(wù)配置失敗時(shí)，建議優(yōu)先核對(duì)相關(guān)信息。相關(guān)信息建議配置如下：NAF： BSF：UtapplicationID：?jiǎn)栴}3：為什么HTC M8終端回落至2/3G后強(qiáng)鎖4G無(wú)法正常進(jìn)行VoLTE語(yǔ)音業(yè)務(wù)？答：在現(xiàn)網(wǎng)測(cè)試中發(fā)現(xiàn)以下案例：HTC m8終端在回落至2/3G后，如果此時(shí)進(jìn)入工程模式強(qiáng)鎖至4G網(wǎng)絡(luò)后再設(shè)置

7、回234G自動(dòng)選擇，并與另外一部VoLTE終端進(jìn)行語(yǔ)音通信，那么此時(shí)會(huì)觸發(fā)CSFB流程，而不是VoLTE語(yǔ)音業(yè)務(wù)。通過(guò)抓包分析，HTC終端如果在23G下，通過(guò)設(shè)置“LTE only”強(qiáng)制選到LTE，那么終端向MME發(fā)送的attach request中不帶additional GUTI，那么MME將認(rèn)為該用戶前一次不是在2/3G SGSN附著的（依據(jù)中移動(dòng)規(guī)范的方法）。Attach request消息如下圖：這時(shí)候如果MME保存有該用戶的信息，就不發(fā)ULR給HLR。根據(jù)諾基亞的被叫域（TAS）選擇，它首先要判斷融合HSS中是否有SGSN number，如果有，則認(rèn)為該用戶在23G下，就會(huì)將被叫指

8、向23G CS域。這個(gè)方案在3GPP TS29.328有下列描述：Annex E (informative):T-ADS request handling in the HSS, If both MME and SGSN are registered but the registered SGSN is a Gn/Gp-SGSN, the HSS treats the MME as not registered in the following T-ADS request handling.對(duì)于支持LTE的雙模終端，從GnGp-SGSN移動(dòng)到MME下時(shí)，即使MME保留有用戶數(shù)據(jù)，按照TS29.

9、272規(guī)范要求，MME還是需要發(fā)起S6a-ULR，攜帶Single Registration Ind，以觸發(fā)HSS/HLR刪除用戶SGSN地址。所以說(shuō)正常情況下用戶進(jìn)入LTE覆蓋時(shí)，HLR不會(huì)保留SGSN地址。當(dāng)下次呼叫時(shí)MME會(huì)認(rèn)為此時(shí)用戶還在2/3G下，于是就會(huì)觸發(fā)CSFB。而且開關(guān)機(jī)通常也無(wú)法解決（因?yàn)镸ME已經(jīng)保存了它的用戶信息）問(wèn)題4：VoLTE語(yǔ)音AMR-NB AMR-WB 資源占有情況有何區(qū)別？答：AMR全稱Adaptive Multi-Rate，自適應(yīng)多速率編碼，主要用于移動(dòng)設(shè)備的音頻，壓縮比比較大，但相對(duì)其他的壓縮格式質(zhì)量比較差，由于多用于人聲，通話。其中AMR分為AMR-N

10、B和AMR-WB兩種，對(duì)于VoLTE而言，AMR-NB則為12.2k語(yǔ)音編碼制式，AMR-WB則為23.85k語(yǔ)音編碼制式。AMR-NB和AMR-WB的本質(zhì)區(qū)別在于其語(yǔ)音帶寬和抽樣頻率有所區(qū)別，NB的語(yǔ)音帶寬范圍為：3003400khz，抽樣頻率為8khz；而WB的語(yǔ)音帶寬為507000khz，抽樣頻率為16khz。以下為相關(guān)的AMR-NB的編碼方式，共分為16種，其中07對(duì)應(yīng)不同編碼方式，815用于噪音或者保留用，VoLTE里的AMR-NB采用的編碼方案7；而AMR-WB的編碼方式同樣也有16種，其中08對(duì)應(yīng)不同編碼方式，915保留用，當(dāng)前VoLTE語(yǔ)音的WB編碼制式采用的編碼方式8。以下為

11、VoLTE相關(guān)測(cè)試中的高標(biāo)清占用資源對(duì)比情況:從趨勢(shì)圖來(lái)看，在SINR大于5的時(shí)候，整體MOS值比較平穩(wěn)，其中高清MOS值穩(wěn)定在3.5以上，標(biāo)清語(yǔ)音MOS值穩(wěn)定在3.2左右，而在SINR值小于5之后，高清和標(biāo)清語(yǔ)音的MOS值均呈現(xiàn)波動(dòng)且整體均值下降的趨勢(shì)。另外由于在SINR差點(diǎn)打點(diǎn)數(shù)較少的原因，其MOS均值會(huì)出現(xiàn)隨著SINR均值下降而抬升的異常情況。在下行PDCP速率里對(duì)比中標(biāo)清語(yǔ)音在7kb左右，在SINR小于0之后開始出現(xiàn)明顯的波動(dòng)情況，直至掉0。高清語(yǔ)音PDCP速率則在15kbps左右，同樣在SINR小于0后開始出現(xiàn)劇烈的波動(dòng)情況。從高清和標(biāo)清的下行PRB數(shù)對(duì)比情況來(lái)看，整體占用的RB數(shù)差

12、距不明顯,另外下行PRB個(gè)數(shù)隨著SINR值惡化逐級(jí)抬升。從高標(biāo)清的指標(biāo)和資源對(duì)比來(lái)看，本身AMR-NB和AMR-WB對(duì)于網(wǎng)絡(luò)資源的利用程度來(lái)看差距不大（PRB上占用差不多），但AMR-WB對(duì)于網(wǎng)絡(luò)資源的利用率會(huì)相對(duì)高些（高清的碼率更高），且AMR-WB的用戶體驗(yàn)更好（MOS值高于AMR-NB一截），且抗干擾性上并沒有明顯差別，因此在VoLTE將來(lái)部署中，更推薦采用AMR-WB編碼制式。問(wèn)題5：終端正確設(shè)置下仍無(wú)法進(jìn)行高清語(yǔ)音通話的原因？答：TAS License過(guò)期使得VoLTE高清不支持，用戶無(wú)法進(jìn)行高清語(yǔ)音通話。以現(xiàn)網(wǎng)測(cè)試案例為例，外場(chǎng)測(cè)試發(fā)現(xiàn)設(shè)置為23.85k的速率，看到PDCP速率只有

13、12.2kbps左右，與23.85kbps預(yù)期24kbps的速率不一致。AMR和AMR-WB是終端和網(wǎng)絡(luò)側(cè)協(xié)商的結(jié)果。需要從終端和網(wǎng)絡(luò)側(cè)兩側(cè)分析解決。1）需要先排查終端側(cè)設(shè)置是否正確。在主叫的invite消息里發(fā)現(xiàn)主叫是支持AMR和AMR-WB。說(shuō)明NV參數(shù)設(shè)置正確且已生效。2）從被叫測(cè)試查看invite消息發(fā)現(xiàn)，網(wǎng)絡(luò)側(cè)未下發(fā)AMR-WB速率?；旧洗_認(rèn)是網(wǎng)絡(luò)側(cè)把AMR-WB丟棄。3）通過(guò)IMS核心抓包分析得知，經(jīng)過(guò)TAS后，AMR-WB被丟棄。確認(rèn)為TAS的問(wèn)題。經(jīng)確認(rèn)9月初TAS版本升級(jí)，AMR-WB LICENSE 沒有及時(shí)打上。TAS 添加license后，外場(chǎng)驗(yàn)證，高清電話可以正常撥

14、通：?jiǎn)栴}6：手機(jī)通話中出現(xiàn)FAST BOOT的可能原因是什么？答：基站側(cè)zuc算法打開后可能會(huì)導(dǎo)致手機(jī)通話出現(xiàn)FAST BOOT問(wèn)題。以現(xiàn)網(wǎng)測(cè)試案例為例，用HTC M8對(duì)在目前LTE弱覆蓋或信號(hào)質(zhì)量差的網(wǎng)絡(luò)環(huán)境下的通話質(zhì)量進(jìn)行MOS評(píng)估時(shí)，發(fā)現(xiàn)通話撥打8S左右通話中斷，手機(jī)進(jìn)入FAST BOOT工程模式。更換站點(diǎn)后恢復(fù)，再回到問(wèn)題站點(diǎn)撥打電話，分析EMIL包后發(fā)現(xiàn)該基站ZUC加密算法開關(guān)打開，且ZUC算法優(yōu)先級(jí)為最高，讓后臺(tái)修改為現(xiàn)網(wǎng)站點(diǎn)基本設(shè)置后恢復(fù)正常。更改站點(diǎn)后手機(jī)通話恢復(fù)正常，可以判斷為站點(diǎn)問(wèn)題。在后臺(tái)檢查后發(fā)現(xiàn)該基站并無(wú)告警，排除由硬件故障造成的通話問(wèn)題。由EMIL包中ATTACH

15、REQUEST里UE CAPBILITY列出終端支持使用ZUC算法。（注意EEA3與EIA3的值都為1）為確定M8在該站下是否使用ZUC算法，通話先在其他站點(diǎn)建立后再切換進(jìn)問(wèn)題站點(diǎn)，從切換請(qǐng)求中可以看出切換后進(jìn)入問(wèn)題站點(diǎn)選擇的加密算法為EEA3、EIA3，且切換完成6S后手機(jī)進(jìn)入FAST BOOT模式。確定問(wèn)題為ZUC算法的啟用導(dǎo)致。（下圖為切換入問(wèn)題站點(diǎn)后選擇的加密算法，基站R10以前的版本是spare5， R11后改成了eea3和eia3）通過(guò)后臺(tái)關(guān)閉ZUC算法，問(wèn)題解決。由于ZUC是3GPP R9才加入的算法，故R9之前的終端并不支持ZUC算法。同時(shí)R9的終端如HTC M8也并不完全支持

16、在使用ZUC算法的前提下進(jìn)行所有業(yè)務(wù)。問(wèn)題7：專用承載MAX GBR值對(duì)通話質(zhì)量有什么影響？答：專用承載MAX GBR太小將導(dǎo)致的通話質(zhì)量差。以現(xiàn)網(wǎng)測(cè)試案例為例，用CDS 48KMOS盒對(duì)在目前LTE網(wǎng)絡(luò)下的通話質(zhì)量進(jìn)行MOS評(píng)估時(shí)，發(fā)現(xiàn)當(dāng)通話建立在專用承載（GBR）下時(shí)CDS MOS打分值偏低。偶然間發(fā)現(xiàn)建立在默認(rèn)承載上的通話MOS值正?？梢赃_(dá)到4分。估計(jì)為專用承載問(wèn)題，再用8K語(yǔ)音文件進(jìn)行MOS打分又恢復(fù)正常，確定為速率問(wèn)題，調(diào)整QCI1 MAXGBR參數(shù)后恢復(fù)正常。VOLTE通話評(píng)估軟件反映通話質(zhì)量分值低，經(jīng)監(jiān)控基站無(wú)告警，接入指標(biāo)正常，更換站點(diǎn)并重新導(dǎo)入?yún)?shù)后仍存在問(wèn)題。曾嘗試在默認(rèn)承

17、載下進(jìn)行語(yǔ)音通話發(fā)現(xiàn)質(zhì)量評(píng)估并無(wú)問(wèn)題。初步判定為專用承載問(wèn)題。如下圖所示（左圖為QCI1下，右圖為QCI9下）。選用8K采樣的語(yǔ)音文件再次進(jìn)行MOS打分時(shí)發(fā)現(xiàn)QCI1下的MOS值恢復(fù)正常采樣率不同的區(qū)別在于傳輸時(shí)速率不同定位問(wèn)題點(diǎn)于QCI1專用承載的最高速率沒有達(dá)到48K語(yǔ)音的傳輸要求。在對(duì)比查看QCI1與QCI9的MAX GBR后確定了問(wèn)題原因。下圖是QCI1修改前的參數(shù)（圖中MAX GBR數(shù)值為換算后結(jié)果，下同）下圖為QCI9的參數(shù)：核心網(wǎng)QCI1承載的MAX GBR改為150：修改后QCI1:由于VOLTE是VOIP業(yè)務(wù)所以速率的大小直接影響了通話的質(zhì)量，速率太小語(yǔ)音業(yè)務(wù)就會(huì)出現(xiàn)卡頓和失

18、真的現(xiàn)象。專用承載的最大保證比特率應(yīng)該先由在不受限條件下的業(yè)務(wù)最高速率來(lái)確定。問(wèn)題8：QCI=1開關(guān)不打開或打開但maxGBR配置過(guò)低對(duì)Volte電話的影響？答：當(dāng)撥打volte電話時(shí)，QCI=1開關(guān)未打開，沒有建立QCI=1的專用承載，電話撥通5S后會(huì)自動(dòng)掛斷如圖所示：所以判斷必須打開QCI=1的專用承載開關(guān)，才能正常撥打電話。在后臺(tái)配合下，開啟QCI=1的專用承載，并配置maxGBR=20k。再次撥打volte電話，發(fā)現(xiàn)專用承載仍未建立，volte電話依然是5s掛斷，如下圖所示：推斷無(wú)法正常撥打電話的原因是maxGBR=20k不滿足核心網(wǎng)配置要求，經(jīng)確認(rèn)，核心網(wǎng)要求的minGBR值必須大于

19、40，于是將基站側(cè)maxGBR值改為256；再次撥打volte電話，專用承載建立成功。能正常通話；如圖所示：所以為了保證Volte語(yǔ)音電話能正常撥打，需打開QCI=1的開關(guān)，切配置大于核心網(wǎng)要求的maxGBR值。問(wèn)題9：QCI=2下maxGBR配置過(guò)小對(duì)視頻電話有什么影響？答：基站側(cè)打開QCI=1及QCI=2的開關(guān)，并將qciTab2maxGbrDl及qciTab2maxGbrul均設(shè)置為100k，撥打Volte視頻電話,QCI=1專載成功建立，但QCI=2的專用承載未建立，視頻電話呼叫失敗。如下圖所示：懷疑為qciTab2maxGbr配置過(guò)低，未能達(dá)到視頻電話保障最低要求，經(jīng)查證，核心網(wǎng)要求

20、的maxGBR值需大于512k，通過(guò)后臺(tái)修改qciTab2maxGbr值為2048之后，再進(jìn)行Volte視頻電話撥打，能正常進(jìn)行視頻通話，如圖所示：所以Volte視頻電話，需同時(shí)打開QCI=1.QCI=2的開關(guān)，且maxGBR值需配置大于核心網(wǎng)要求的值方可正常通話。第3章 VoLTE關(guān)鍵功能優(yōu)化篇問(wèn)題10：終端注冊(cè)異地MME對(duì)eSRVCC會(huì)產(chǎn)生什么影響？答：手機(jī)注冊(cè)異地MME可能導(dǎo)致不能完成sSRVCC切換。以福州某測(cè)試場(chǎng)景為例，下表為eNB參數(shù)配置。在無(wú)線環(huán)境滿足切換條件情況下，ms只上報(bào)測(cè)量報(bào)告，未發(fā)生切換。MS只上報(bào)測(cè)量，未發(fā)生切換問(wèn)題，查看基站無(wú)相關(guān)告警，檢查鄰區(qū)無(wú)漏配，參數(shù)配置一致情

21、況下，未切換問(wèn)題還是存在。后續(xù)測(cè)試中,通過(guò)抓取核心網(wǎng)，eNB側(cè)log分析,核心網(wǎng)側(cè)查看eNB未發(fā)送handover command，通過(guò)多方面分析后，發(fā)現(xiàn)MS注冊(cè)的MME code歸屬地屬于廈門,MS注冊(cè)到廈門MME不能切換原因可能是相應(yīng)參數(shù)未配置完整。eNB側(cè)刪除廈門MME后，測(cè)試中切換問(wèn)題解決。問(wèn)題11：HSS參數(shù)設(shè)置是否會(huì)對(duì)eSRVCC產(chǎn)生影響？答：HSS參數(shù)設(shè)置不恰當(dāng)可能會(huì)導(dǎo)致無(wú)法執(zhí)行eSRVCC。正常的eSRVCC流程如下：以現(xiàn)網(wǎng)測(cè)試發(fā)現(xiàn)的某個(gè)案例為例，無(wú)線環(huán)境滿足切換條件，UE卻并沒有執(zhí)行切換，直至SINR過(guò)差發(fā)生掉話。通過(guò)分析log發(fā)現(xiàn)，UE未觸發(fā)eSRVCC原因?yàn)椋琫NB沒有下

22、發(fā)eSRVCC相關(guān)測(cè)控消息。更換HTC測(cè)試終端發(fā)現(xiàn)，SIM卡尾號(hào)為19的終端可收到eNB下發(fā)的測(cè)控消息并正常eSRVCC，而SIM卡尾號(hào)為55的終端無(wú)法收到eSRVCC測(cè)控消息，以此排除終端原因。正常重配置信令中eSRVCC測(cè)控消息如下，SIM卡尾號(hào)為55的終端無(wú)以下消息。GSM頻點(diǎn)信息A2事件及B2事件：對(duì)比19、55兩部終端能力信息，發(fā)現(xiàn)eNB收到的UE Capability Information信令完全相同，且FGI第9位、第23位設(shè)置為1，表示終端支持eSRVCC（根據(jù)3GPP 36331 B.1 Feature group indicators規(guī)定，比特位9為EUTRA RRC_C

23、ONNECTED to GERAN GSM_Dedicated handover，比特位23為GERAN measurements, reporting and measurement reporting event B2 in E-UTRA connected mode，設(shè)置為1表示支持該功能）。對(duì)比EMIL log發(fā)現(xiàn)，SIM卡尾號(hào)為19的終端附著時(shí)，eNB收到MME下發(fā)的Initial Context Setup Request中存在SRVCCOperationPossible : possible字段，而SIM卡尾號(hào)為55的終端確沒有該字段，導(dǎo)致eNB認(rèn)為UE不支持eSRVCC，因此不

24、下發(fā)eSRVCC測(cè)控消息。在附著流程中，測(cè)控消息下發(fā)前，UE會(huì)通過(guò)上發(fā)NAS：Attach Request進(jìn)行信息的交互，其中包含UE能力的相關(guān)信息。對(duì)比兩部終端上發(fā)的Attach Request信令，結(jié)果發(fā)現(xiàn)，Attach Request中除隨機(jī)個(gè)性化參數(shù)不同外，其他參數(shù)完全相同，且MS NETWORK CAPABILITY (OPTIONAL)中SRVCC to GERAN/UTRAN capability字段設(shè)置為1，表示UE支持eSRVCC。由上可知，UE無(wú)論是與eNB還是與MME交互過(guò)程中，不存在終端能力上報(bào)的差異， 判斷應(yīng)該不是終端的問(wèn)題，懷疑是否為SIM卡本身的問(wèn)題。對(duì)調(diào)兩部終端

25、SIM卡發(fā)現(xiàn)，問(wèn)題會(huì)伴隨尾號(hào)為55的SIM卡，與終端無(wú)關(guān)。聯(lián)系HSS工程師核查SIM卡參數(shù)，發(fā)現(xiàn)尾號(hào)為55的SIM卡Session Transfer Number參數(shù)為空，此字段為eSRVCC切換時(shí)核心網(wǎng)的一個(gè)標(biāo)識(shí)的初始值。若字段為空，則表示不支持eSRVCC。重新設(shè)置尾號(hào)為55的SIM卡后，問(wèn)題消失。問(wèn)題12：地下車庫(kù)-115場(chǎng)景eSRVCC優(yōu)化參數(shù)如何設(shè)置？答：地下車庫(kù)-115場(chǎng)景下，參數(shù)采用初始配置1，A2判決門限為：LTE-110dBm，B2判決門限為：LTE-85dBm。UE進(jìn)入地下車庫(kù)，當(dāng)LTE信號(hào)低于-120dBm時(shí)觸發(fā)B2事件，但在1秒內(nèi)RSRP由-120dBm降低至-139d

26、Bm以下，SINR由-2dB降低至-14.7dB以下，無(wú)法完成eSRVCC流程，導(dǎo)致信號(hào)惡化掉話。UE觸發(fā)B2時(shí)信號(hào)截圖如下：UE掉話時(shí)信號(hào)截圖：調(diào)整B2判決門限，將B2 LTE門限由-120改為-116，發(fā)現(xiàn)成功率有大幅度提升，成功率大于70%。分析log發(fā)現(xiàn)，該場(chǎng)景UE會(huì)占用PCI=33、34兩個(gè)小區(qū)，當(dāng)占用PCI=34的小區(qū)時(shí)，與鄰區(qū)PCI=115的小區(qū)MOD3沖突，SINR差導(dǎo)致無(wú)法及時(shí)完成eSRVCC切換。鄰區(qū)列表如下：將三個(gè)小區(qū)PCI由34/33/35調(diào)整為33/35/34，eSRVCC切換成功率達(dá)90%以上。問(wèn)題13：RoHC是否應(yīng)該啟用？答：RoHC通過(guò)壓縮IP包頭的方式，在V

27、oLTE用戶較多時(shí)，提高了空口傳輸效率。1）RoHC技術(shù)僅對(duì)QCI=1的業(yè)務(wù)有效包頭壓縮支持IPv4和IPv6格式支持以下格式的壓縮(3GPP R8):0x0000 ROHC uncompressed (RFC 4995)0x0001 ROHC RTP (RFC 3095, RFC4815)0x0002 ROHC UDP (RFC 3095, RFC4815)以上格式需要具備VoLTE能力的終端支持2）RoHC的實(shí)現(xiàn)高標(biāo)清理論速率計(jì)算RoHC理論速率計(jì)算3）RoHC外場(chǎng)驗(yàn)證測(cè)試由以上分析可看出，標(biāo)清AMR壓縮比為51.39%，高清AMR壓縮比為65.35%，建議全網(wǎng)開啟RoCH。問(wèn)題14：VO

28、LTE下的DRX模式與普通LTE下的DRX模式有何不同？答：DRX分兩種，一種是IDLE DRX，就是當(dāng)UE處于IDLE狀態(tài)下的非連續(xù)性接收，由于處于IDLE狀態(tài)時(shí)，已經(jīng)沒有RRC連接以及用戶的專有資源，因此這個(gè)主要是監(jiān)聽呼叫信道與廣播信道，只要定義好固定的周期，就可以達(dá)到非連續(xù)接收的目的。但是UE要監(jiān)聽用戶數(shù)據(jù)信道，則必須從IDLE狀態(tài)先進(jìn)入連接狀態(tài)。而另一種就是ACTIVE DRX，也就是UE處在RRC-CONNECTED 狀態(tài)下的DRX，可以優(yōu)化系統(tǒng)資源配置，更重要的是可以節(jié)約手機(jī)功率，而不需要通過(guò)讓手機(jī)進(jìn)入到RRC_IDLE 模式來(lái)達(dá)到這個(gè)目的，例如一些非實(shí)時(shí)應(yīng)用，像web瀏覽，即時(shí)通

29、信等，總是存在一段時(shí)間，手機(jī)不需要不停的監(jiān)聽下行數(shù)據(jù)以及相關(guān)處理，那么DRX就可以應(yīng)用到這樣的情況。ACTIVE DRX的基本機(jī)制是為處于RRC_CONNECTED態(tài)的UE配置一個(gè)DRX cycle。DRX cycle由“On Duration”和“Opportunity for DRX”組成：在“On Duration”的時(shí)間內(nèi)，UE監(jiān)聽并接收PDCCH（激活期）；在“Opportunity for DRX”時(shí)間內(nèi)，UE不接收下行信道的數(shù)據(jù)以節(jié)省功耗（休眠期）。在大多數(shù)情況下，當(dāng)一個(gè)UE在某個(gè)子幀被調(diào)度并接收或發(fā)送數(shù)據(jù)后，很可能在接下來(lái)的幾個(gè)子幀內(nèi)繼續(xù)被調(diào)度，如果要等到下一個(gè)DRX cycl

30、e再來(lái)接收或發(fā)送這些數(shù)據(jù)將會(huì)帶來(lái)額外的延遲。為了降低這類延遲，UE在被調(diào)度后，會(huì)持續(xù)位于激活期，即會(huì)在配置的激活期內(nèi)持續(xù)監(jiān)聽PDCCH。其實(shí)現(xiàn)方法是：每當(dāng)UE被調(diào)度時(shí)，就會(huì)啟動(dòng)一個(gè)定時(shí)器drx-InactivityTimer，在該時(shí)間內(nèi)不會(huì)釋放連接。drx-InactivityTimer指定了當(dāng)UE成功解碼一個(gè)指示初傳的UL或DL用戶數(shù)據(jù)的PDCCH后，持續(xù)位于激活態(tài)的連續(xù)子幀數(shù)。為了允許UE在HARQ RTT期間內(nèi)休眠，每個(gè)DL HARQ process定義了一個(gè) “HARQ RTT(Round Trip Time) timer”。當(dāng)某個(gè)下行HARQ process的TB解碼失敗時(shí)，UE可以

31、假定至少在“HARQ RTT”子幀后才會(huì)有重傳，因此當(dāng)HARQ RTT timer正在運(yùn)行時(shí)，UE沒必要監(jiān)聽PDCCH。當(dāng)HARQ RTT timer超時(shí)，且對(duì)應(yīng)HARQ process接收到的數(shù)據(jù)沒有被成功解碼時(shí)，UE會(huì)為該HARQ process啟動(dòng)一個(gè)drx-RetransmissionTimer。當(dāng)該timer運(yùn)行時(shí)，UE會(huì)監(jiān)聽用于HARQ重傳的PDCCH。drx-RetransmissionTimer的長(zhǎng)度與eNodeB調(diào)度器的靈活度要求相關(guān)。如果是要達(dá)到最優(yōu)的電池消耗，就要求eNodeB在HARQ RTT timer超時(shí)之后，立即調(diào)度HARQ重傳，這就也要求eNodeB為此預(yù)留無(wú)線

32、資源，此時(shí)drx-RetransmissionTimer也就可以配得短些。drx-RetransmissionTimer指定了從UE期待收到DL重傳的子幀（HARQ RTT之后）開始，連續(xù)監(jiān)聽PDCCH的最大子幀數(shù)。諾基亞LTE設(shè)備中允許ENodeB對(duì)不同的QCI業(yè)務(wù)設(shè)置不同的DRX PROFILE參數(shù)集，每一個(gè)參數(shù)集會(huì)包括longDRX-Cycle (ms)、 On Duration Timer (psf) 、DRX Inactivity Timer(psf)、DRX Retrans Timer(psf) 4個(gè)參數(shù)。UE在進(jìn)行不同的QCI業(yè)務(wù)時(shí)會(huì)執(zhí)行最高優(yōu)先級(jí)的業(yè)務(wù)的DRX PROFILE。

33、而在VOLTE的業(yè)務(wù)下，QCI=1的時(shí)延不能超過(guò)100ms，所以DRX cycle不能設(shè)置得過(guò)長(zhǎng)，不能使用原先QCI=9的long DRX-cycle設(shè)置（160ms），又由于UE在進(jìn)行語(yǔ)音業(yè)務(wù)時(shí)，用戶正在通話時(shí)會(huì)每20ms產(chǎn)生一個(gè)采樣包，宜為設(shè)置long DRX-cycle為40ms，為20ms的整數(shù)倍。同時(shí)，由于語(yǔ)音業(yè)務(wù)都是20ms產(chǎn)生一個(gè)采樣包進(jìn)行下發(fā)，用戶在接受到語(yǔ)音數(shù)據(jù)包后并不需要連續(xù)監(jiān)聽，且由于longdrxcycle更變，DRXinactivityTimer也不宜設(shè)置過(guò)大（原QCI=9該參數(shù)為60/200（psf），宜為設(shè)置為4（psf），以達(dá)到節(jié)電功能。故VOLTE推薦的DRX

34、 PROFILE為第4章 2/3/4G互操作優(yōu)化篇問(wèn)題15：如何實(shí)現(xiàn)2G快速重選回4G？答：處于2G網(wǎng)絡(luò)的終端可通過(guò)小區(qū)重新返回4G，而重選頻點(diǎn)信息將由2G系統(tǒng)廣播的SI2quater消息提供。系統(tǒng)消息分為多種類型：type1、2、2bis、2ter、3、4、5、5bis、5ter、6、7、8、9、13。當(dāng)終端處于IDLE態(tài)下，將用BCCH信道來(lái)收聽系統(tǒng)消息1至4及7，8，13。UE處于空閑時(shí), 系統(tǒng)消息以每8個(gè)復(fù)幀重復(fù)發(fā)送一次的循環(huán)方式在主BCCH信道和擴(kuò)展BCCH信道中發(fā)送。因此引入循環(huán)序號(hào)TC: 其中FN是TDMA的幀號(hào)，以個(gè)TDMA幀為周期循環(huán)編號(hào)，取值范圍（0）；(FN/51)是TD

35、MA幀號(hào)對(duì)一個(gè)復(fù)幀長(zhǎng)度的整除，可以確定幀號(hào)為FN的TDMA幀所歸屬的復(fù)幀的編號(hào)；正如上文提到的系統(tǒng)消息以每8個(gè)復(fù)幀重復(fù)一次的循環(huán)方式發(fā)送，(FN/51)%8是復(fù)幀編號(hào)對(duì)8求模，可以確定該復(fù)幀在以8個(gè)復(fù)幀為周期的循環(huán)中的位置；因此TC表示特定的系統(tǒng)消息在循環(huán)中的第幾個(gè)復(fù)幀中發(fā)送。 一個(gè)復(fù)幀的長(zhǎng)度為235ms， 8個(gè)復(fù)幀的周期時(shí)長(zhǎng)為1883ms，所以系統(tǒng)消息下發(fā)的最短間隔為8個(gè)復(fù)幀的時(shí)長(zhǎng)1883ms。 各種系統(tǒng)消息發(fā)送的循環(huán)號(hào)TC和對(duì)應(yīng)得發(fā)送信道如下表所示：從上表可以看出，SI2Quarter在BCCH Norm當(dāng)TC=5或4時(shí)發(fā)送，或者在擴(kuò)展BCCH(BCCH Ext)當(dāng)TC=5時(shí)發(fā)送。如果BCCH Norm上發(fā)送SI2Quarter，會(huì)和其他系統(tǒng)消息存在較大的發(fā)送碰撞，需要進(jìn)行輪流發(fā)送。由于SI2queter消息提供的內(nèi)容較多，必須分多條消息發(fā)送，這樣一來(lái)，發(fā)送小區(qū)重選需要的多條SI2quater消息將消耗大量不確定時(shí)間。以諾基亞網(wǎng)絡(luò)中的SI2quater發(fā)送