廣州中興VoLTE優(yōu)化案例

廣州中興VoLTE優(yōu)化案例

ID:35683553

大小:1.52 MB

頁數(shù):13頁

時間:2019-04-12

廣州中興VoLTE優(yōu)化案例_第1頁
廣州中興VoLTE優(yōu)化案例_第2頁
廣州中興VoLTE優(yōu)化案例_第3頁
廣州中興VoLTE優(yōu)化案例_第4頁
廣州中興VoLTE優(yōu)化案例_第5頁
資源描述:

《廣州中興VoLTE優(yōu)化案例》由會員上傳分享,免費在線閱讀,更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、案例1:異頻重定向掉話案例【問題描述】主叫占用廣州天河區(qū)魚珠木材市場D-ZLH-3(EARFCN=38100PCI=83CELLID=135693)小區(qū)通話時,信號強度為-101dbm左右,出現(xiàn)一次RRCConnectionRelease,導(dǎo)致承載拆除,引起一次主叫掉話?!締栴}分析】分析測試數(shù)據(jù),發(fā)現(xiàn)UE占用服務(wù)小區(qū)廣州天河區(qū)魚珠木材市場D-ZLH-3(EARFCN=38100PCI=83CELLID=135693)在通話的過程中信號越來越差,之后上報測量報告A2事件,eNODEB收到報告后發(fā)起異頻重定向判決,下發(fā)RRCConnectionRelease,由異頻

2、重定向后,eNodeB向MME發(fā)送uecontextreleaserequest,mme釋放專用承載。當UE被重定向后在新的小區(qū)發(fā)起RRC連接,網(wǎng)絡(luò)只建立了默認承載,UE發(fā)送BYE消息,導(dǎo)致掉話。從地理環(huán)境上看,服務(wù)小區(qū)與UE重定向目標小區(qū)相距較遠,不需配鄰區(qū)關(guān)系,UE在該路段僅是偶爾測量到目標小區(qū)的信號,這種環(huán)境極容易觸發(fā)異頻重定向。【解決方案】關(guān)閉異頻重定向,復(fù)測問題解決,服務(wù)小區(qū)后臺統(tǒng)計指標無異常?!締栴}總結(jié)】根據(jù)拉網(wǎng)統(tǒng)計,目前該類掉話占總掉話次數(shù)的80%以上,對測試指標影響非常嚴重。異頻重定向觸發(fā)原理:小區(qū)間沒定義鄰區(qū)關(guān)系,當鄰區(qū)滿足切換條件時,主服務(wù)小

3、區(qū)無法切換到鄰區(qū),基站會給UE下發(fā)系統(tǒng)內(nèi)重定向。優(yōu)化辦法:通過關(guān)閉異頻重定向的功能來規(guī)避該事件,除此之外,異頻鄰區(qū)的完善需要加大優(yōu)化力度。后續(xù)解決辦法:除了做好鄰區(qū)優(yōu)化外,中興將在下個版本加入基于QCI的異頻重定向功能,禁止專用承載的業(yè)務(wù)發(fā)生異頻重定向。。案例2:異系統(tǒng)重定向掉話案例【問題描述】VoLTE測試eSRVCC過程中,發(fā)現(xiàn)eSRVCC執(zhí)行的是CCO,而不是PS切換。而CCO對于VoLTE語音來說,必然導(dǎo)致掉話。【問題分析】具體如下圖所示。1.對于PSHO、CCO、重定向,優(yōu)先級為PSHO>CCO>重定向。那么現(xiàn)在的問題就是eSRVCC過程執(zhí)行的為什么是

4、CCO而不是PSHO。2.重點排查的就是eSRVCC相關(guān)配置:(1)eSRVCC功能開關(guān):未發(fā)現(xiàn)問題。(2)系統(tǒng)間鄰區(qū)配置:a.GSM鄰區(qū)配置:重點查看“PS切換能力”配置的是否為:“是[1]”。PS切換能力表示GSM鄰區(qū)的PS?HO能力。當GSM鄰區(qū)支持PS?HO能力,服務(wù)小區(qū)可以向該鄰區(qū)發(fā)起PS切換。未發(fā)現(xiàn)錯誤。b.GSM鄰區(qū)關(guān)系:重點查看“支持切換”配置的是否為“支持[1]”。是否“支持切換”代表服務(wù)小區(qū)是否支持向GERAN鄰區(qū)發(fā)起切換的指示。發(fā)現(xiàn)配置的是“不支持”。問題就在這里。如下圖所示。【解決方案】修改GSM鄰區(qū)關(guān)系中,支持切換為“支持[1]”后,在

5、進行eSRVCC切換,eSRVCC切換成功,VoLTE未出現(xiàn)掉話?!締栴}總結(jié)】對于VoLTE語音來說,無論是系統(tǒng)內(nèi)還是系統(tǒng)間eSRVCC,只要執(zhí)行的不是“切換”都會導(dǎo)致語音的掉話,包括重定向和CCO。因此,需要開通的時候,保持GSM鄰區(qū)配置和GSM鄰區(qū)關(guān)系配置正確,嚴格按照中興的VoLTE開通指導(dǎo)書來執(zhí)行。案例3:切換過程中專載被MME釋放【問題描述】主被叫在呼叫建立的過程中,專載建立與切換幾乎同時發(fā)生,專載剛剛建立完成又在切換過程中被釋放,終端回復(fù)invite580,呼叫未接通?!締栴}分析】1、主叫收到invite183消息并建立專載,但在專載建立前主叫已上報

6、A3測報,所以幾乎在主叫上發(fā)承載建立成功的NAS消息的同時(10:19:29.959),主叫收到了基站下發(fā)的切換重配消息,消息中包含釋放QCI1的信息:2、再看基站側(cè)信令,基站收到終端上報的A3測報后,從源小區(qū)發(fā)給MME的HandoverRequired里面,有三條承載,分別是QCI9/QCI5/QCI1:3、從MME發(fā)給目標小區(qū)的HandoverRequest消息里面e_RABInformationList有三條承載,但是e_RABToBeSetupListHOReq里面只有兩條,少了QCI1的:4、由于HandoverRequest消息的e_RABToBeS

7、etupListHOReq里面只有兩條承載,所以目標小區(qū)回給MME的HandoverRequestAcknowledge消息里面,也只有兩條承載:5、那么,在MME回給源小區(qū)的HandoverCommand里面ToAdd兩條承載QCI9和QCI5,Release了QCI1的承載,這就導(dǎo)致專載被釋放并導(dǎo)致未接通:終端專載建立成功后上發(fā)NAS消息給MME,但由于切換流程在前,MME收到NAS消息之前,MME已經(jīng)發(fā)給目標小區(qū)的HandoverRequest消息,里面e_RABToBeSetupListHOReq少了QCI1的承載,所以ReleaseQCI1的承載?!窘?/p>

8、決方案】開啟X2接口,使

當前文檔最多預(yù)覽五頁,下載文檔查看全文

此文檔下載收益歸作者所有

當前文檔最多預(yù)覽五頁,下載文檔查看全文
溫馨提示:
1. 部分包含數(shù)學(xué)公式或PPT動畫的文件,查看預(yù)覽時可能會顯示錯亂或異常,文件下載后無此問題,請放心下載。
2. 本文檔由用戶上傳,版權(quán)歸屬用戶,天天文庫負責(zé)整理代發(fā)布。如果您對本文檔版權(quán)有爭議請及時聯(lián)系客服。
3. 下載前請仔細閱讀文檔內(nèi)容,確認文檔內(nèi)容符合您的需求后進行下載,若出現(xiàn)內(nèi)容與標題不符可向本站投訴處理。
4. 下載文檔時可能由于網(wǎng)絡(luò)波動等原因無法下載或下載錯誤,付費完成后未能成功下載的用戶請聯(lián)系客服處理。