VOLTE案例分析

1、1 優(yōu)化經(jīng)驗(yàn)總結(jié)1.1 日常優(yōu)化總結(jié)日常優(yōu)化工作主要從無(wú)線覆蓋優(yōu)化、參數(shù)優(yōu)化、系統(tǒng)內(nèi)外鄰區(qū)優(yōu)化，功能優(yōu)化四個(gè)方面著手，與ATU路網(wǎng)、工程建設(shè)緊密配合，提升整體網(wǎng)絡(luò)質(zhì)量。1.2 RLC優(yōu)先級(jí)優(yōu)化現(xiàn)象：呼叫建立與切換過(guò)程沖突，專載被MME釋放。呼叫建立過(guò)程中專載建立與切換幾乎同時(shí)發(fā)生，MME未收到NAS專載完成消息導(dǎo)致釋放專載，終端回復(fù)invite580（也有上發(fā)CANCLE的情況），專載丟失形成未接通事件。原因分析：QCI5設(shè)置的RLC優(yōu)先級(jí)為2，高于SRB=2(傳送NAS層消息)配置為3. 導(dǎo)致NAS的層3消息已經(jīng)比MR要早，但是因?yàn)閮?yōu)先級(jí)比MR和SIP低，未及時(shí)發(fā)送。優(yōu)化措施：降低QCI 5

2、優(yōu)先級(jí)，確保SIP消息及時(shí)上傳，修改后此類問(wèn)題改善明顯。1.3 QCI 5 PDCP DiscardTimer時(shí)長(zhǎng)優(yōu)化現(xiàn)象：終端業(yè)務(wù)建立過(guò)程中，出現(xiàn)SIP信息傳遞丟失的問(wèn)題，導(dǎo)致收到網(wǎng)絡(luò)下發(fā)的INVITE500或者580等原因值釋放。原因分析：UE在無(wú)線信道較差的情況下，SIP信令發(fā)送或接收不完整或者無(wú)法及時(shí)傳遞，導(dǎo)致IMS相關(guān)定時(shí)器超時(shí)而發(fā)起會(huì)話cancel。經(jīng)過(guò)分析，由于QCI5的pdcp 丟棄時(shí)長(zhǎng)過(guò)小，在無(wú)線覆蓋較差的地方，上行時(shí)延會(huì)變大，容易導(dǎo)致QCI5信令丟包。優(yōu)化措施：QCI5 PDCP DiscardTimer由300ms修改為無(wú)窮大優(yōu)化效果：VoLTE無(wú)線接通率提升明顯1.4

3、SBC傳輸協(xié)議TCP重傳次數(shù)優(yōu)化背景：被叫從2G返回4G后，主叫起呼，被叫首先bye消息，緊接著接連收到多條上一次呼叫的invite，被叫回復(fù)bye481invite486invite580，呼叫失敗。優(yōu)化措施：愛立信SBC對(duì)TCP配置進(jìn)行了修改：最大重傳次數(shù)從15次改為5次，最大重傳隔間從十幾分鐘改為15s，此類問(wèn)題已解決。1.5 系統(tǒng)間鄰區(qū)優(yōu)化LTE網(wǎng)絡(luò)的GSM鄰區(qū)關(guān)系根據(jù)工程參數(shù)、共站2G鄰區(qū)同向小區(qū)繼承進(jìn)行規(guī)劃，同時(shí)根據(jù)4G、2G道路測(cè)試數(shù)據(jù)匹配進(jìn)行鄰區(qū)補(bǔ)充：4G弱信號(hào)路段與2G拉網(wǎng)服務(wù)小區(qū)匹配：利用第三方拉網(wǎng)測(cè)試數(shù)據(jù)，將4G和2G拉網(wǎng)信號(hào)強(qiáng)度、經(jīng)緯度、服務(wù)小區(qū)等信息導(dǎo)出。通過(guò)經(jīng)緯將4

4、G弱信號(hào)(RSRP-95dbm）在50米范圍內(nèi)擬合，根據(jù)擬合度對(duì)2G鄰區(qū)進(jìn)行補(bǔ)漏工作。剔除現(xiàn)網(wǎng)已配置的鄰區(qū)關(guān)系，補(bǔ)漏鄰區(qū)關(guān)系對(duì)后，eSRVCC切換提升明顯，且由于2G鄰區(qū)不準(zhǔn)確導(dǎo)致的異系統(tǒng)重定向大大減少。1.6 重定向掉話XX區(qū)域掉話最嚴(yán)重屬于重定向掉話，在XX基站算法中，以下三種可能發(fā)生重定向，重定向釋放RRC后，專載同時(shí)被拆除，VoLTE業(yè)務(wù)產(chǎn)生掉話。1.7 上行PUSCH功控參數(shù)優(yōu)化背景：xx區(qū)域拉網(wǎng)測(cè)試發(fā)現(xiàn)上行PUSCH發(fā)射功率偏高，對(duì)現(xiàn)網(wǎng)參數(shù)檢查發(fā)現(xiàn)，xx區(qū)域上行期望功率值設(shè)置過(guò)高。優(yōu)化措施： 進(jìn)行功控相關(guān)參數(shù)優(yōu)化，現(xiàn)網(wǎng)配置： p0NominalPUSCH =-75 ；puschPC

5、AdjType=0優(yōu)化值： p0NominalPUSCH =-87 ；puschPCAdjType=2同等路損情況下，參數(shù)修改后，ue發(fā)射功率大約下降23dB。目前終端平均上行發(fā)射功率仍高于10db，仍需完善現(xiàn)有功控方式。修改后，PUSCH TxPower（10dbm以上）占比由40%下降到30%左右。1.8 RTP丟包率優(yōu)化背景：測(cè)試發(fā)現(xiàn)，XX區(qū)域RTP丟包率偏高，個(gè)別網(wǎng)格甚至達(dá)到2%以上。原因分析：在無(wú)線質(zhì)量較好的情況下基本無(wú)丟包；無(wú)線質(zhì)量較差的情況下上行丟包現(xiàn)象較為嚴(yán)重，PDCP重傳時(shí)間超時(shí)，數(shù)據(jù)包將被丟棄；外場(chǎng)測(cè)試表明QCI 1 PDCP Discardtimer 配置與RTP丟包率及

6、Jitter有密切關(guān)系，QCI 1 PDCP Discardtimer 配置越大，RTP丟包率越低，但Jitter也隨之變大。MOS值與RTP丟包及Jitter關(guān)系都較大，目前正在進(jìn)行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的對(duì)比驗(yàn)證。1.9 MME專載保存功能（可選）功能描述：在基站發(fā)起UE-lost原因值的上下文釋放請(qǐng)求時(shí)，MME保持專載2s不釋放，等待空口重建。驗(yàn)證情況：已在某MME下成功驗(yàn)證了該功能。當(dāng)時(shí)無(wú)線環(huán)境較差，UE發(fā)起RRC重建失敗，通過(guò)MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過(guò)程中，RRC重配中建立包括專載QC

7、I1的3條DRB，不會(huì)發(fā)生掉話。（本次測(cè)試中專載保持時(shí)長(zhǎng)約1.358s）功能總結(jié)：1）當(dāng)無(wú)線環(huán)境較差時(shí)，UE發(fā)生RRC重建，若RRC重建成功，手機(jī)將不會(huì)掉話。2）MME側(cè)也可以在RRC重建失敗后，通過(guò)MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過(guò)程中，專載QCI1繼續(xù)保持，也可使得手機(jī)不掉話。3）此功能為愛立信MME非必選功能，建議打開。但是該功能不在集采目錄，暫時(shí)無(wú)法采購(gòu)。1.10 專載釋放與切換沖突，通話結(jié)束未收到專載釋放掉話問(wèn)題描述：在拉網(wǎng)測(cè)試過(guò)程中，通話掛機(jī)后，主叫上報(bào)BYE消息，IMS回BYE200消息前后，同時(shí)手機(jī)發(fā)生切換，未收到EPS專載釋放請(qǐng)求，1s后軟件統(tǒng)計(jì)掉話。問(wèn)題分析：經(jīng)

8、分析MME log，發(fā)現(xiàn)MME未收到PGW下發(fā)的delete bearer request消息。當(dāng)X2切換觸發(fā)SGW-initiated bearer modification procedure（完整信令是CCR-CCA），如果此時(shí)SIP掛機(jī)觸發(fā)PCRF也發(fā)RAR給PGW，由于Gx鏈路時(shí)延等原因，使得RAR先于CCA到達(dá)PGW，根據(jù)協(xié)議規(guī)定，PGW會(huì)繼續(xù)SGW-initiated bearer modification procedure而reject RAR (result code DIAMETER_OUT_OF_SPACE)。優(yōu)化措施：當(dāng)前解決辦法：（1）縮短DRA時(shí)延配置。（2）修改

9、SAPC到DRA鏈路為主-備模式，保證CCA和RAR走同一路徑和到達(dá)PGW的先后順序。優(yōu)化結(jié)果：近期調(diào)整后的網(wǎng)格測(cè)試，暫時(shí)沒(méi)有發(fā)現(xiàn)BYE200消息前后發(fā)生的切換沒(méi)釋放QCI 1專載的情況。1.11 通話結(jié)束MME收到del bearer req，專載釋放與切換沖突，基站未下發(fā)NAS問(wèn)題描述：通話掛機(jī)后，主叫上報(bào)BYE消息，IMS回BYE200消息前后，同時(shí)手機(jī)發(fā)生切換，EPS專載沒(méi)有釋放，1s后軟件統(tǒng)計(jì)掉話。問(wèn)題分析：主叫掛機(jī)后，MME收到del bearer req，下發(fā)Deactivate EPS bearer context Request給源eNB攜帶NAS釋放專載，但同時(shí)源eNB觸發(fā)

10、X2切換，向MME響應(yīng)ERAB release response （X2-Handover-Triggered），NAS消息未下發(fā)到手機(jī)。根據(jù)協(xié)議36.413 中8.6.2.4有描述當(dāng)eNB在觸發(fā)X2切換時(shí)，eNB將不傳遞NAS消息。優(yōu)化措施：屬測(cè)試軟件統(tǒng)計(jì)問(wèn)題，建議軟件加以剔除該問(wèn)題。2 案例分析2.1 典型案例案例1：LTE弱覆蓋，eSRVCC切換不及時(shí)掉話10:57:29.710基站下發(fā)異頻異系統(tǒng)測(cè)量報(bào)告，包含2G頻點(diǎn)及B2門限（LTE:-110，GERAN:-95）10:57:38.479，主叫達(dá)到B2門限10:57:42.109，主叫RSRP已惡化至-117dBm，SINR至-3，但

11、終端仍沒(méi)有上報(bào)B2事件10:58:05.587，RTP包不能正常收發(fā)，10s后RTP inactivity定時(shí)器觸發(fā)，會(huì)話中斷，出現(xiàn)掉話：解決建議：規(guī)范LTE頻點(diǎn)配置，清理多余異頻頻點(diǎn)，縮短終端測(cè)量周期；終端芯片提高測(cè)量能力，盡快實(shí)現(xiàn)CDRX休眠期測(cè)量功能。案例2：VoLTE單通現(xiàn)象VoLTE單通現(xiàn)象分為兩類：一是VoLTE打VoLTE單通，二是VoLTE撥打GSM單通。經(jīng)分析，第一類主要是終端問(wèn)題，第二類主要是網(wǎng)絡(luò)問(wèn)題。注：紅圈為RTP包抓包位置案例3：eNodeB參數(shù)配置不合理，導(dǎo)致eSRVCC失敗問(wèn)題現(xiàn)象：終端發(fā)生eSRVCC時(shí)，在LTE向GSM切換過(guò)程中產(chǎn)生掉話。問(wèn)題分析：終端可以正常

12、收到測(cè)控消息，并上報(bào)測(cè)量報(bào)告，且掉話發(fā)生在向GSM切換過(guò)程中，是GSM或者和基站側(cè)參數(shù)設(shè)置問(wèn)題。問(wèn)題解決：基站BsCAccess-ID項(xiàng)中的管理狀態(tài)為L(zhǎng)ocked，設(shè)置有誤。將該狀態(tài)修改為Unlock后，對(duì)該站點(diǎn)進(jìn)行重啟后發(fā)現(xiàn)eSRVCC功能正常。2.2 空口信令判斷案例案例1：RRC重建失敗，無(wú)線網(wǎng)問(wèn)題現(xiàn)象：切換失敗導(dǎo)致RRC釋放，重建RRC未成功，重新進(jìn)行RRC申請(qǐng)，QCI=1的承載未建立成功，導(dǎo)致掉話分析：呼叫重建失敗后，新小區(qū)重新申請(qǐng)RRC，未能建立VOLTE專載，導(dǎo)致掉話。該流程均由ENODEB控制執(zhí)行。而切換失敗的原因往往是無(wú)線環(huán)境問(wèn)題、參數(shù)配置不合理、鄰區(qū)漏配、非競(jìng)爭(zhēng)隨機(jī)接入異常

13、等，均為無(wú)線網(wǎng)問(wèn)題。結(jié)論：切換失敗與RRC重申請(qǐng)流程均與EUTRAN相關(guān)，因此認(rèn)定為無(wú)線網(wǎng)問(wèn)題。案例2：基站異常導(dǎo)致雙端無(wú)下行信令及RTP包斷傳，無(wú)線網(wǎng)問(wèn)題現(xiàn)象：主被叫VOLTE接通后，在同一小區(qū)同時(shí)發(fā)生缺失下行信令20秒，此后數(shù)秒發(fā)生終端上發(fā)bye request掛斷。分析：丟信令之前，主被叫雙端處于同一小區(qū)，且RTP包雙向傳輸正常。丟信令期間，終端測(cè)量信息完整，但在2秒后發(fā)生RTP包只有終端向網(wǎng)絡(luò)單向傳輸，未再有任何網(wǎng)絡(luò)下發(fā)的RTP包，高度懷疑基站臨時(shí)故障導(dǎo)致。結(jié)論：軟件顯示丟信令，但通過(guò)進(jìn)一步分析確認(rèn)應(yīng)為基站故障導(dǎo)致。無(wú)線網(wǎng)問(wèn)題。案例3： VOLTE接通下發(fā)生IMS注冊(cè)掉話，IMS網(wǎng)絡(luò)問(wèn)

14、題現(xiàn)象： VOLTE接通后，被叫發(fā)生IMS注冊(cè)且成功，此時(shí)主叫收到網(wǎng)絡(luò)下發(fā)的bye request內(nèi)含注冊(cè)超時(shí)字樣分析：按照3GPP協(xié)議，終端應(yīng)在3000秒上發(fā)注冊(cè)，本次華為SBC于3600秒才收到注冊(cè)請(qǐng)求，此時(shí)IMS認(rèn)為注冊(cè)超時(shí)，對(duì)主叫下發(fā)了sip bye消息釋放了。但通過(guò)進(jìn)一步確認(rèn)，終端實(shí)際于600秒前已上發(fā)了注冊(cè)消息（UDP），但此時(shí)恰好在G網(wǎng)下，未收到回復(fù)：注：同樣類型的掉話也有600秒前處于LTE網(wǎng)（TCP），而未收到OK或未鑒權(quán)回復(fù)的情況結(jié)論：前10分鐘的注冊(cè)失敗，導(dǎo)致了后續(xù)的IMS通話中釋放，雖然終端前一次的失敗處理機(jī)制可能存在問(wèn)題，但仍然體現(xiàn)出IMS對(duì)通話中發(fā)生注冊(cè)時(shí)直接釋放會(huì)

15、話的措施欠妥。2.3 網(wǎng)元流程判斷案例案例1：被叫收到尋呼但未收到INVITE請(qǐng)求，核心網(wǎng)問(wèn)題現(xiàn)象：主叫上發(fā)了invite，被叫收到了尋呼且建立RRC成功，此時(shí)應(yīng)收到下行的invite，但始終未收到。分析：被叫響應(yīng)尋呼并進(jìn)行了RRC申請(qǐng)，表明MME已收到由SGW觸發(fā)的數(shù)據(jù)業(yè)務(wù)請(qǐng)求，即sip invite消息應(yīng)由IMS網(wǎng)元的SBC下發(fā)給了PGW、SGW。Sip invite消息由IMS網(wǎng)元SBC下發(fā)到被叫核心網(wǎng)網(wǎng)元PGWPGW轉(zhuǎn)發(fā)給SGW，SGW通過(guò)S11觸發(fā)MME進(jìn)行尋呼被叫被叫被尋呼到，并完成RRC連接與建立默認(rèn)承載所需RAB，接收數(shù)據(jù)結(jié)論：收到尋呼消息表示sip invite數(shù)據(jù)包已經(jīng)到達(dá)

16、了LTE核心網(wǎng)，未能繼續(xù)下發(fā)當(dāng)前懷疑是sip數(shù)據(jù)在S/PGW異常丟失。案例2：重配置消息釋放DRB承載，無(wú)線網(wǎng)與核心網(wǎng)配合問(wèn)題現(xiàn)象：被叫上發(fā)sip183后，在激活EPS承載之前，終端上報(bào)了1條A3測(cè)報(bào)，激活EPS后，發(fā)生切換重配置消息中釋放了QCI=1的DRB。分析：起呼時(shí)MME進(jìn)行激活EPS承載流程過(guò)程中，恰好發(fā)生S1切換時(shí)，由于EPS承載建立未完成，MME在切換準(zhǔn)備階段，對(duì)下發(fā)到目標(biāo)小區(qū)的切換準(zhǔn)備的請(qǐng)求消息中不攜帶QCI=1的VOLTE專載，導(dǎo)致VOLTE專載源小區(qū)完成的情況下，在目標(biāo)小區(qū)被釋放，切換完成后呼叫中斷切換準(zhǔn)備時(shí)，MME向目標(biāo)小區(qū)發(fā)切換請(qǐng)求，RAB建立請(qǐng)求表只有2條，無(wú)QCI=

17、1的專載目標(biāo)小區(qū)收到MME的切換請(qǐng)求后，回復(fù)的切換確認(rèn)消息里僅有2條RAB建立MME向源小區(qū)下發(fā)的切換命令消息中，只建立2條承載，導(dǎo)致ENODEB釋放了QCI=1的VOLTE專載。結(jié)論：切換與EPS激活流程碰撞，無(wú)線網(wǎng)與核心網(wǎng)配合問(wèn)題。在進(jìn)行激活EPS專載過(guò)程中，發(fā)生切換時(shí)，均會(huì)造成上述問(wèn)題，目前還無(wú)較好的解決辦法。2.4 網(wǎng)絡(luò)設(shè)備問(wèn)題案例總結(jié)案例1：中興ENODEB異頻重定向掉話，無(wú)線網(wǎng)問(wèn)題現(xiàn)象：主被叫VOLTE接通后，服務(wù)小區(qū)信號(hào)較差，但未配置異頻鄰區(qū)；通過(guò)重定向消息RRC connection release攜帶頻點(diǎn)，由D頻段重定向到F頻段，但VOLTE呼叫不支持重定向方式的RTP包接續(xù)

18、，導(dǎo)致掉話。設(shè)備：中興ENODEB分析：中興設(shè)備為了防止鄰區(qū)漏配情況下，影響用戶在LTE數(shù)據(jù)業(yè)務(wù)下的感知質(zhì)量，默認(rèn)具備異頻重定向功能，但未曾考慮對(duì)VOLTE呼叫的接續(xù)保持。結(jié)論：完善鄰區(qū)配置，在VOLTE呼叫區(qū)域考慮關(guān)閉中興設(shè)備的異頻重定向功能。案例2：華為基站到卡特切換導(dǎo)致的RTP包傳輸中斷問(wèn)題，無(wú)線網(wǎng)問(wèn)題現(xiàn)象：主被叫接通狀態(tài)下，在發(fā)生一次由華為設(shè)備到卡特設(shè)備的切換后，20秒后主被叫終端同時(shí)上發(fā)了bye request消息，網(wǎng)絡(luò)側(cè)回復(fù)bye(487 Request Terminated)，后網(wǎng)絡(luò)去激活了EPS承載，掉話。設(shè)備：華為ENODEB與卡特ENODEB分析：PDCP SN SIZE長(zhǎng)

19、度有12bit和7bit，目前華為基站配置為12bit,貝爾配置為7bit，兩個(gè)廠家配置數(shù)據(jù)不統(tǒng)一。華為enodeb設(shè)備具有自適應(yīng)功能。在華為小區(qū)起呼時(shí)，切換到卡特小區(qū)時(shí)，卡特?zé)o自適應(yīng)功能，PDCP SN不一致導(dǎo)致組包混亂。當(dāng)在貝爾小區(qū)起呼時(shí)，切換到華為小區(qū)時(shí)，華為PDCP SN自適應(yīng)為7bit，通話正常。結(jié)論：臨時(shí)解決方案：華為PDCP SN Size修改為7bit，進(jìn)行拉網(wǎng)測(cè)試主叫呼叫56次，未出現(xiàn)終端主動(dòng)上發(fā)bye的掉話。異常掉話及切換后單通問(wèn)題基本解決案例3：愛立信IMS網(wǎng)元CS域呼叫處理能力不足問(wèn)題，IMS網(wǎng)絡(luò)問(wèn)題現(xiàn)象：在做互通測(cè)試過(guò)程中，主叫VOLTE起呼后，被叫始終在TD下未收到

20、尋呼消息，主叫收到網(wǎng)絡(luò)側(cè)下發(fā)trying后，立即收到網(wǎng)絡(luò)下發(fā)的invtie 604（Does Not Exist Anywhere），呼叫失敗。設(shè)備：愛立信IMS分析：空口信令僅能確認(rèn)，被叫端處于TD網(wǎng)，發(fā)INVITE到MGCF，MGCF回復(fù)604 Does Not Exist Anywhere。該問(wèn)題為愛立信IMS網(wǎng)元MGCF默認(rèn)配置僅能同時(shí)容納32個(gè)CS域呼叫，導(dǎo)致互通測(cè)試過(guò)程中，由于容量不足，造成大量連續(xù)未接通。結(jié)論：愛立信IMS網(wǎng)元MGCF默認(rèn)配置容量偏小，發(fā)生以上問(wèn)題后，經(jīng)過(guò)擴(kuò)容已達(dá)可處理2、3G呼叫320個(gè)。案例4：華為EPC修改EPS與切換碰撞，拒絕承載修改。核心網(wǎng)問(wèn)題現(xiàn)象：主叫

21、VOLTE起呼后，收到網(wǎng)絡(luò)回復(fù)trying，激活了EPS承載后，又進(jìn)行了1次EPS承載的修改，此時(shí)主叫側(cè)在發(fā)生了1次LTE的切換后，收到IMS網(wǎng)絡(luò)下發(fā)的sip503消息，服務(wù)不可得。設(shè)備：華為EPC分析：某地在激活EPS完成后，仍需要進(jìn)行2次EPS承載的修改，本次呼叫時(shí)第2次EPS的修改（空口信令不可見）恰好與切換同時(shí)發(fā)生，當(dāng)IMS要求核心網(wǎng)PCRF需要對(duì)EPS承載進(jìn)行修改時(shí)，由于切換具有更高的優(yōu)先級(jí)，華為EPC拒絕了承載更新，而只執(zhí)行切換，導(dǎo)致IMS下發(fā)sip 503消息中斷呼叫該市合適的CQI=1的EPS承載建立需要3個(gè)步驟：CQI=1的初始EPS承載建立，GBR=40kbps但TFT無(wú)IPV6地址修改GBR49kbps支持高清語(yǔ)音并對(duì)TFT內(nèi)的增加IPV6地址以及 UDP端口進(jìn)行修改在現(xiàn)有TFT中再新建兩個(gè)ptf。結(jié)論：冗余的EPS承載修改TFT，一方面導(dǎo)致了呼叫建立時(shí)延長(zhǎng)；同時(shí)增加了與切換發(fā)生沖突的幾率；華為EPC在切換與修改EPS承載沖突時(shí)，不具備同時(shí)處理或排隊(duì)處理的能力，導(dǎo)致直接以“資源臨時(shí)不可得”拒絕了承載更新。一方面建議降低EPS承載修改次數(shù)，減少切換碰撞幾率與時(shí)延；另一方面建議華為EPC進(jìn)行升級(jí)。案例5：華為EPC、中興IMS協(xié)議理解不一致。IMS網(wǎng)絡(luò)問(wèn)題