VOLTE案例分析.doc

1 優(yōu)化經(jīng)驗總結(jié)1.1 日常優(yōu)化總結(jié)日常優(yōu)化工作主要從無線覆蓋優(yōu)化、參數(shù)優(yōu)化、系統(tǒng)內(nèi)外鄰區(qū)優(yōu)化，功能優(yōu)化四個方面著手，與ATU路網(wǎng)、工程建設(shè)緊密配合，提升整體網(wǎng)絡(luò)質(zhì)量。1.2 RLC優(yōu)先級優(yōu)化現(xiàn)象：呼叫建立與切換過程沖突，專載被MME釋放。呼叫建立過程中專載建立與切換幾乎同時發(fā)生，MME未收到NAS專載完成消息導致釋放專載，終端回復invite580（也有上發(fā)CANCLE的情況），專載丟失形成未接通事件。原因分析：QCI5設(shè)置的RLC優(yōu)先級為2，高于SRB=2(傳送NAS層消息)配置為3. 導致NAS的層3消息已經(jīng)比MR要早，但是因為優(yōu)先級比MR和SIP低，未及時發(fā)送。優(yōu)化措施：降低QCI 5優(yōu)先級，確保SIP消息及時上傳，修改后此類問題改善明顯。1.3 QCI 5 PDCP DiscardTimer時長優(yōu)化現(xiàn)象：終端業(yè)務(wù)建立過程中，出現(xiàn)SIP信息傳遞丟失的問題，導致收到網(wǎng)絡(luò)下發(fā)的INVITE500或者580等原因值釋放。原因分析：UE在無線信道較差的情況下，SIP信令發(fā)送或接收不完整或者無法及時傳遞，導致IMS相關(guān)定時器超時而發(fā)起會話cancel。經(jīng)過分析，由于QCI5的pdcp 丟棄時長過小，在無線覆蓋較差的地方，上行時延會變大，容易導致QCI5信令丟包。優(yōu)化措施：QCI5 PDCP DiscardTimer由300ms修改為無窮大優(yōu)化效果：VoLTE無線接通率提升明顯1.4 SBC傳輸協(xié)議TCP重傳次數(shù)優(yōu)化背景：被叫從2G返回4G后，主叫起呼，被叫首先bye消息，緊接著接連收到多條上一次呼叫的invite，被叫回復bye481invite486invite580，呼叫失敗。優(yōu)化措施：愛立信SBC對TCP配置進行了修改：最大重傳次數(shù)從15次改為5次，最大重傳隔間從十幾分鐘改為15s，此類問題已解決。1.5 系統(tǒng)間鄰區(qū)優(yōu)化LTE網(wǎng)絡(luò)的GSM鄰區(qū)關(guān)系根據(jù)工程參數(shù)、共站2G鄰區(qū)同向小區(qū)繼承進行規(guī)劃，同時根據(jù)4G、2G道路測試數(shù)據(jù)匹配進行鄰區(qū)補充：4G弱信號路段與2G拉網(wǎng)服務(wù)小區(qū)匹配：利用第三方拉網(wǎng)測試數(shù)據(jù)，將4G和2G拉網(wǎng)信號強度、經(jīng)緯度、服務(wù)小區(qū)等信息導出。通過經(jīng)緯將4G弱信號(RSRP-95dbm）在50米范圍內(nèi)擬合，根據(jù)擬合度對2G鄰區(qū)進行補漏工作。剔除現(xiàn)網(wǎng)已配置的鄰區(qū)關(guān)系，補漏鄰區(qū)關(guān)系對后，eSRVCC切換提升明顯，且由于2G鄰區(qū)不準確導致的異系統(tǒng)重定向大大減少。1.6 重定向掉話XX區(qū)域掉話最嚴重屬于重定向掉話，在XX基站算法中，以下三種可能發(fā)生重定向，重定向釋放RRC后，專載同時被拆除，VoLTE業(yè)務(wù)產(chǎn)生掉話。1.7 上行PUSCH功控參數(shù)優(yōu)化背景：xx區(qū)域拉網(wǎng)測試發(fā)現(xiàn)上行PUSCH發(fā)射功率偏高，對現(xiàn)網(wǎng)參數(shù)檢查發(fā)現(xiàn)，xx區(qū)域上行期望功率值設(shè)置過高。優(yōu)化措施： 進行功控相關(guān)參數(shù)優(yōu)化，現(xiàn)網(wǎng)配置： p0NominalPUSCH =-75 ；puschPCAdjType=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)化背景：測試發(fā)現(xiàn)，XX區(qū)域RTP丟包率偏高，個別網(wǎng)格甚至達到2%以上。原因分析：在無線質(zhì)量較好的情況下基本無丟包；無線質(zhì)量較差的情況下上行丟包現(xiàn)象較為嚴重，PDCP重傳時間超時，數(shù)據(jù)包將被丟棄；外場測試表明QCI 1 PDCP Discardtimer 配置與RTP丟包率及Jitter有密切關(guān)系，QCI 1 PDCP Discardtimer 配置越大，RTP丟包率越低，但Jitter也隨之變大。MOS值與RTP丟包及Jitter關(guān)系都較大，目前正在進行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的對比驗證。1.9 MME專載保存功能（可選）功能描述：在基站發(fā)起UE-lost原因值的上下文釋放請求時，MME保持專載2s不釋放，等待空口重建。驗證情況：已在某MME下成功驗證了該功能。當時無線環(huán)境較差，UE發(fā)起RRC重建失敗，通過MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過程中，RRC重配中建立包括專載QCI1的3條DRB，不會發(fā)生掉話。（本次測試中專載保持時長約1.358s）功能總結(jié)：1）當無線環(huán)境較差時，UE發(fā)生RRC重建，若RRC重建成功，手機將不會掉話。2）MME側(cè)也可以在RRC重建失敗后，通過MME專載QCI1保持功能使得在新發(fā)起的業(yè)務(wù)過程中，專載QCI1繼續(xù)保持，也可使得手機不掉話。3）此功能為愛立信MME非必選功能，建議打開。但是該功能不在集采目錄，暫時無法采購。1.10 專載釋放與切換沖突，通話結(jié)束未收到專載釋放掉話問題描述：在拉網(wǎng)測試過程中，通話掛機后，主叫上報BYE消息，IMS回BYE200消息前后，同時手機發(fā)生切換，未收到EPS專載釋放請求，1s后軟件統(tǒng)計掉話。問題分析：經(jīng)分析MME log，發(fā)現(xiàn)MME未收到PGW下發(fā)的delete bearer request消息。當X2切換觸發(fā)SGW-initiated bearer modification procedure（完整信令是CCR-CCA），如果此時SIP掛機觸發(fā)PCRF也發(fā)RAR給PGW，由于Gx鏈路時延等原因，使得RAR先于CCA到達PGW，根據(jù)協(xié)議規(guī)定，PGW會繼續(xù)SGW-initiated bearer modification procedure而reject RAR (result code DIAMETER_OUT_OF_SPACE)。優(yōu)化措施：當前解決辦法：（1）縮短DRA時延配置。（2）修改SAPC到DRA鏈路為主-備模式，保證CCA和RAR走同一路徑和到達PGW的先后順序。優(yōu)化結(jié)果：近期調(diào)整后的網(wǎng)格測試，暫時沒有發(fā)現(xiàn)BYE200消息前后發(fā)生的切換沒釋放QCI 1專載的情況。1.11 通話結(jié)束MME收到del bearer req，專載釋放與切換沖突，基站未下發(fā)NAS問題描述：通話掛機后，主叫上報BYE消息，IMS回BYE200消息前后，同時手機發(fā)生切換，EPS專載沒有釋放，1s后軟件統(tǒng)計掉話。問題分析：主叫掛機后，MME收到del bearer req，下發(fā)Deactivate EPS bearer context Request給源eNB攜帶NAS釋放專載，但同時源eNB觸發(fā)X2切換，向MME響應(yīng)ERAB release response （X2-Handover-Triggered），NAS消息未下發(fā)到手機。根據(jù)協(xié)議36.413 中8.6.2.4有描述當eNB在觸發(fā)X2切換時，eNB將不傳遞NAS消息。優(yōu)化措施：屬測試軟件統(tǒng)計問題，建議軟件加以剔除該問題。2 案例分析2.1 典型案例案例1：LTE弱覆蓋，eSRVCC切換不及時掉話10:57:29.710基站下發(fā)異頻異系統(tǒng)測量報告，包含2G頻點及B2門限（LTE:-110，GERAN:-95）10:57:38.479，主叫達到B2門限10:57:42.109，主叫RSRP已惡化至-117dBm，SINR至-3，但終端仍沒有上報B2事件10:58:05.587，RTP包不能正常收發(fā)，10s后RTP inactivity定時器觸發(fā)，會話中斷，出現(xiàn)掉話：解決建議：規(guī)范LTE頻點配置，清理多余異頻頻點，縮短終端測量周期；終端芯片提高測量能力，盡快實現(xiàn)CDRX休眠期測量功能。案例2：VoLTE單通現(xiàn)象VoLTE單通現(xiàn)象分為兩類：一是VoLTE打VoLTE單通，二是VoLTE撥打GSM單通。經(jīng)分析，第一類主要是終端問題，第二類主要是網(wǎng)絡(luò)問題。注：紅圈為RTP包抓包位置案例3：eNodeB參數(shù)配置不合理，導致eSRVCC失敗問題現(xiàn)象：終端發(fā)生eSRVCC時，在LTE向GSM切換過程中產(chǎn)生掉話。問題分析：終端可以正常收到測控消息，并上報測量報告，且掉話發(fā)生在向GSM切換過程中，是GSM或者和基站側(cè)參數(shù)設(shè)置問題。問題解決：基站BsCAccess-ID項中的管理狀態(tài)為Locked，設(shè)置有誤。將該狀態(tài)修改為Unlock后，對該站點進行重啟后發(fā)現(xiàn)eSRVCC功能正常。2.2 空口信令判斷案例案例1：RRC重建失敗，無線網(wǎng)問題現(xiàn)象：切換失敗導致RRC釋放，重建RRC未成功，重新進行RRC申請，QCI=1的承載未建立成功，導致掉話分析：呼叫重建失敗后，新小區(qū)重新申請RRC，未能建立VOLTE專載，導致掉話。該流程均由ENODEB控制執(zhí)行。而切換失敗的原因往往是無線環(huán)境問題、參數(shù)配置不合理、鄰區(qū)漏配、非競爭隨機接入異常等，均為無線網(wǎng)問題。結(jié)論：切換失敗與RRC重申請流程均與EUTRAN相關(guān)，因此認定為無線網(wǎng)問題。案例2：基站異常導致雙端無下行信令及RTP包斷傳，無線網(wǎng)問題現(xiàn)象：主被叫VOLTE接通后，在同一小區(qū)同時發(fā)生缺失下行信令20秒，此后數(shù)秒發(fā)生終端上發(fā)bye request掛斷。分析：丟信令之前，主被叫雙端處于同一小區(qū)，且RTP包雙向傳輸正常。丟信令期間，終端測量信息完整，但在2秒后發(fā)生RTP包只有終端向網(wǎng)絡(luò)單向傳輸，未再有任何網(wǎng)絡(luò)下發(fā)的RTP包，高度懷疑基站臨時故障導致。結(jié)論：軟件顯示丟信令，但通過進一步分析確認應(yīng)為基站故障導致。無線網(wǎng)問題。案例3： VOLTE接通下發(fā)生IMS注冊掉話，IMS網(wǎng)絡(luò)問題現(xiàn)象： VOLTE接通后，被叫發(fā)生IMS注冊且成功，此時主叫收到網(wǎng)絡(luò)下發(fā)的bye request內(nèi)含注冊超時字樣分析：按照3GPP協(xié)議，終端應(yīng)在3000秒上發(fā)注冊，本次華為SBC于3600秒才收到注冊請求，此時IMS認為注冊超時，對主叫下發(fā)了sip bye消息釋放了。但通過進一步確認，終端實際于600秒前已上發(fā)了注冊消息（UDP），但此時恰好在G網(wǎng)下，未收到回復：注：同樣類型的掉話也有600秒前處于LTE網(wǎng)（TCP），而未收到OK或未鑒權(quán)回復的情況結(jié)論：前10分鐘的注冊失敗，導致了后續(xù)的IMS通話中釋放，雖然終端前一次的失敗處理機制可能存在問題，但仍然體現(xiàn)出IMS對通話中發(fā)生注冊時直接釋放會話的措施欠妥。2.3 網(wǎng)元流程判斷案例案例1：被叫收到尋呼但未收到INVITE請求，核心網(wǎng)問題現(xiàn)象：主叫上發(fā)了invite，被叫收到了尋呼且建立RRC成功，此時應(yīng)收到下行的invite，但始終未收到。分析：被叫響應(yīng)尋呼并進行了RRC申請，表明MME已收到由SGW觸發(fā)的數(shù)據(jù)業(yè)務(wù)請求，即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通過S11觸發(fā)MME進行尋呼被叫被叫被尋呼到，并完成RRC連接與建立默認承載所需RAB，接收數(shù)據(jù)結(jié)論：收到尋呼消息表示sip invite數(shù)據(jù)包已經(jīng)到達了LTE核心網(wǎng)，未能繼續(xù)下發(fā)當前懷疑是sip數(shù)據(jù)在S/PGW異常丟失。案例2：重配置消息釋放DRB承載，無線網(wǎng)與核心網(wǎng)配合問題現(xiàn)象：被叫上發(fā)sip183后，在激活EPS承載之前，終端上報了1條A3測報，激活EPS后，發(fā)生切換重配置消息中釋放了QCI=1的DRB。分析：起呼時MME進行激活EPS承載流程過程中，恰好發(fā)生S1切換時，由于EPS承載建立未完成，MME在切換準備階段，對下發(fā)到目標小區(qū)的切換準備的請求消息中不攜帶QCI=1的VOLTE專載，導致VOLTE專載源小區(qū)完成的情況下，在目標小區(qū)被釋放，切換完成后呼叫中斷切換準備時，MME向目標小區(qū)發(fā)切換請求，RAB建立請求表只有2條，無QCI=1的專載目標小區(qū)收到MME的切換請求后，回復的切換確認消息里僅有2條RAB建立MME向源小區(qū)下發(fā)的切換命令消息中，只建立2條承載，導致ENODEB釋放了QCI=1的VOLTE專載。結(jié)論：切換與EPS激活流程碰撞，無線網(wǎng)與核心網(wǎng)配合問題。在進行激活EPS專載過程中，發(fā)生切換時，均會造成上述問題，目前還無較好的解決辦法。2.4 網(wǎng)絡(luò)設(shè)備問題案例總結(jié)案例1：中興ENODEB異頻重定向掉話，無線網(wǎng)問題現(xiàn)象：主被叫VOLTE接通后，服務(wù)小區(qū)信號較差，但未配置異頻鄰區(qū)；通過重定向消息RRC connection release攜帶頻點，由D頻段重定向到F頻段，但VOLTE呼叫不支持重定向方式的RTP包接續(xù)，導致掉話。設(shè)備：中興ENODEB分析：中興設(shè)備為了防止鄰區(qū)漏配情況下，影響用戶在LTE數(shù)據(jù)業(yè)務(wù)下的感知質(zhì)量，默認具備異頻重定向功能，但未曾考慮對VOLTE呼叫的接續(xù)保持。結(jié)論：完善鄰區(qū)配置，在VOLTE呼叫區(qū)域考慮關(guān)閉中興設(shè)備的異頻重定向功能。案例2：華為基站到卡特切換導致的RTP包傳輸中斷問題，無線網(wǎng)問題現(xiàn)象：主被叫接通狀態(tài)下，在發(fā)生一次由華為設(shè)備到卡特設(shè)備的切換后，20秒后主被叫終端同時上發(fā)了bye request消息，網(wǎng)絡(luò)側(cè)回復bye(487 Request Terminated)，后網(wǎng)絡(luò)去激活了EPS承載，掉話。設(shè)備：華為ENODEB與卡特ENODEB分析：PDCP SN SIZE長度有12bit和7bit，目前華為基站配置為12bit,貝爾配置為7bit，兩個廠家配置數(shù)據(jù)不統(tǒng)一。華為enodeb設(shè)備具有自適應(yīng)功能。在華為小區(qū)起呼時，切換到卡特小區(qū)時，卡特無自適應(yīng)功能，PDCP SN不一致導致組包混亂。當在貝爾小區(qū)起呼時，切換到華為小區(qū)時，華為PDCP SN自適應(yīng)為7bit，通話正常。結(jié)論：臨時解決方案：華為PDCP SN Size修改為7bit，進行拉網(wǎng)測試主叫呼叫56次，未出現(xiàn)終端主動上發(fā)bye的掉話。異常掉話及切換后單通問題基本解決案例3：愛立信IMS網(wǎng)元CS域呼叫處理能力不足問題，IMS網(wǎng)絡(luò)問題現(xiàn)象：在做互通測試過程中，主叫VOLTE起呼后，被叫始終在TD下未收到尋呼消息，主叫收到網(wǎng)絡(luò)側(cè)下發(fā)trying后，立即收到網(wǎng)絡(luò)下發(fā)的invtie 604（Does Not Exist Anywhere），呼叫失敗。設(shè)備：愛立信IMS分析：空口信令僅能確認，被叫端處于TD網(wǎng)，發(fā)INVITE到MGCF，MGCF回復604 Does Not Exist Anywhere。該問題為愛立信IMS網(wǎng)元MGCF默認配置僅能同時容納32個CS域呼叫，導致互通測試過程中，由于容量不足，造成大量連續(xù)未接通。結(jié)論：愛立信IMS網(wǎng)元MGCF默認配置容量偏小，發(fā)生以上問題后，經(jīng)過擴容已達可處理2、3G呼叫320個。案例4：華為EPC修改EPS與切換碰撞，拒絕承載修改。核心網(wǎng)問題現(xiàn)象：主叫VOLTE起呼后，收到網(wǎng)絡(luò)回復trying，激活了EPS承載后，又進行了1次EPS承載的修改，此時主叫側(cè)在發(fā)生了1次LTE的切換后，收到IMS網(wǎng)絡(luò)下發(fā)的sip503消息，服務(wù)不可得。設(shè)備：華為EPC分析：某地在激活EPS完成后，仍需要進行2次EPS承載的修改，本次呼叫時第2次EPS的修改（空口信令不可見）恰好與切換同時發(fā)生，當IMS要求核心網(wǎng)PCRF需要對EPS承載進行修改時，由于切換具有更高的優(yōu)先級，華為EPC拒絕了承載更新，而只執(zhí)行切換，導致IMS下發(fā)sip 503消息中斷呼叫該市合適的CQI=1的EPS承載建立需要3個步驟：CQI=1的初始EPS承載建立，GBR=40kbps但TFT無IPV6地址修改GBR49kbps支持高清語音并對TFT內(nèi)的增加IPV6地址以及 UDP端口進行修改在現(xiàn)有TFT中再新建兩個ptf。結(jié)論：冗余的EPS承載修改TFT，一方面導致了呼叫建立時延長；同時增加了與切換發(fā)生沖突的幾率；華為EPC在切換與修改EPS承載沖突時，不具備同時處理或排隊處理的能力，導致直接以“資源臨時不可得”拒絕了承載更新。一方面建議降低EPS承載修改次數(shù)，減少切換碰撞幾率與時延；另一方面建議華為EPC進行升級。案例5：華為EPC、中興IMS協(xié)議理解不一致。IMS網(wǎng)絡(luò)問題