廣州中興VoLTE優(yōu)化案例自然科學(xué)_第1頁
廣州中興VoLTE優(yōu)化案例自然科學(xué)_第2頁
廣州中興VoLTE優(yōu)化案例自然科學(xué)_第3頁
廣州中興VoLTE優(yōu)化案例自然科學(xué)_第4頁
廣州中興VoLTE優(yōu)化案例自然科學(xué)_第5頁
已閱讀5頁,還剩4頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1/1廣州中興VoLTE優(yōu)化案例-自然科學(xué)

案例1:異頻重定向掉話案例

【問題描述】

主叫占用廣州天河區(qū)魚珠木材市場D-ZLH-3(EARFCN=38100PCI=83CELLID=135693)小區(qū)通話時,信號強(qiáng)度為-101dbm左右,消失一次RRCConnectionRelease,導(dǎo)致承載拆除,引起一次主叫掉話。

【問題分析】

分析測試數(shù)據(jù),發(fā)覺UE占用服務(wù)小區(qū)廣州天河區(qū)魚珠木材市場D-ZLH-3(EARFCN=38100PCI=83CELLID=135693)在通話的過程中信號越來越差,之后上報測量報告A2大事,eNODEB收到報告后發(fā)起異頻重定向判決,下發(fā)RRCConnectionRelease,由異頻重定向后,eNodeB向MME發(fā)送uecontextreleaserequest,mme釋放專用承載。當(dāng)UE被重定向后在新的小區(qū)發(fā)起RRC連接,網(wǎng)絡(luò)只建立了默認(rèn)承載,UE發(fā)送BYE消息,導(dǎo)致掉話。

從地理環(huán)境上看,服務(wù)小區(qū)與UE重定向目標(biāo)小區(qū)相距較遠(yuǎn),不需配鄰區(qū)關(guān)系,UE在該路段僅是間或測量到目標(biāo)小區(qū)的信號,這種環(huán)境極簡單觸發(fā)異頻重定向。

【解決方案】

關(guān)閉異頻重定向,復(fù)測問題解決,服務(wù)小區(qū)后臺統(tǒng)計指標(biāo)無特別。

【問題總結(jié)】

依據(jù)拉網(wǎng)統(tǒng)計,目前該類掉話占總掉話次數(shù)的80%以上,對測試指標(biāo)影響特別嚴(yán)峻。異頻重定向觸發(fā)原理:小區(qū)間沒定義鄰區(qū)關(guān)系,當(dāng)鄰區(qū)滿意切換條件時,主服務(wù)小區(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ā)覺eSRVCC執(zhí)行的是CCO,而不是PS切換。而CCO對于

VoLTE語音來說,必定導(dǎo)致掉話。

【問題分析】

詳細(xì)如下圖所示。

1.對于PSHO、CCO、重定向,優(yōu)先級為PSHO>CCO>重定向。那么現(xiàn)在的問題就是eSRVCC過程執(zhí)行的為什么是CCO而不是PSHO。

2.重點排查的就是eSRVCC相關(guān)配置:(1)eSRVCC功能開關(guān):未發(fā)覺問題。(2)系統(tǒng)間鄰區(qū)配置:

a.GSM鄰區(qū)配置:重點查看“PS切換力量”配置的是否為:“是[1]”。PS切換力量表示GSM鄰區(qū)的PSHO力量。當(dāng)GSM鄰區(qū)支持PSHO力量,服務(wù)小區(qū)可以向該鄰區(qū)發(fā)起PS切換。未發(fā)覺錯誤。

b.GSM鄰區(qū)關(guān)系:重點查看“支持切換”配置的是否為“支持[1]”。是否“支持切換”代表服務(wù)小區(qū)是否支持向GERAN鄰區(qū)發(fā)起切換的指示。發(fā)覺配置的是“不支持”。問題就在這里。如下圖所示。

【解決方案】

修改GSM鄰區(qū)關(guān)系中,支持切換為“支持[1]”后,在進(jìn)行eSRVCC切換,eSRVCC切換勝利,VoLTE未消失掉話。

【問題總結(jié)】

對于VoLTE語音來說,無論是系統(tǒng)內(nèi)還是系統(tǒng)間eSRVCC,只要執(zhí)行的不是“切換”都會導(dǎo)致語音的掉話,包括重定向和CCO。因此,需要開通的時候,保持GSM鄰區(qū)配置和GSM鄰區(qū)關(guān)系配置正確,嚴(yán)格根據(jù)中興的VoLTE開通指導(dǎo)書來執(zhí)行。

案例3:切換過程中專載被MME釋放

【問題描述】

主被叫在呼叫建立的過程中,專載建立與切換幾乎同時發(fā)生,專載剛剛建立完成又在切換過程中被釋放,終端回復(fù)invite580,呼叫未接通。

【問題分析】

1、主叫收到invite183消息并建立專載,但在專載建立前主叫已上報A3測報,所以幾乎在主叫上發(fā)承載建立勝利的NAS消息的同時(10:19:29.959),主叫收到了基站下發(fā)的切換重配消息,消息中包含釋放QCI1的信息:

2、再看基站側(cè)信令,基站收到終端上報的A3測報后,從源小區(qū)發(fā)給MME的HandoverRequired里面,有三條承載,分別是QCI9/QCI5/QCI1:

3、從MME發(fā)給目標(biāo)小區(qū)的HandoverRequest消息里面e_RABInformationList有三條承載,但是e_RABToBeSetupListHOReq里面只有兩條,少了QCI1的:

4、由于HandoverRequest消息的e_RABToBeSetupListHOReq里面只有兩條承載,所以目標(biāo)小區(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ā)給目標(biāo)小區(qū)的HandoverRequest消息,里面e_RABToBeSetupListHOReq少了QCI1的承載,所以ReleaseQCI1的承載。

【解決方案】

開啟X2接口,使用X2接口削減流程沖突導(dǎo)致的專載丟失。依據(jù)外省及深圳的閱歷,開啟X2后此類問題概率大大削減。

需要對專載建立過程中的切換流程進(jìn)行優(yōu)化。

需要檢查相關(guān)參數(shù)配置是否合理。

【問題總結(jié)】

VoLTE業(yè)務(wù)關(guān)系RRC層信令、S1信令、X2信令、NAS消息,SIP信令,需要綜合考慮問題。

案例4:eSRVCC至2G掉話

【問題描述】

在集團(tuán)測試網(wǎng)格9LOG中,eSRVCC至2G導(dǎo)致掉話的大事,表現(xiàn)為呼叫建立后,由于達(dá)到異系統(tǒng)B2門限,終端上報B2大事,網(wǎng)絡(luò)下發(fā)eSRVCC切換配置命令,但在2G側(cè)切入失敗,隨后呼叫中止,消失掉話大事。

【問題分析】

1、主叫11:19:48.223正常起呼,流程正常,在11:19:53.242發(fā)出SIPACK,且在11:19:49.931時刻在小區(qū)PCI373配B2門限如下圖

2、主叫終端在11:20:05.224時刻上報測量,如下圖,2G信號約為-94,達(dá)到B2門限

3、eNB基站在14:47:05.527下發(fā)MoblityFromEUTRACommand,內(nèi)容如下:

4、eSRVCC至2G后,在11:20:06.517掉話;切換失敗緣由為:Radiolinkfailure無線鏈路失敗,2G的無線環(huán)境較差導(dǎo)致。

總的來說,4G流程正常且已正常建立會話,eSRVCC切換至GSM,2G小區(qū)信號較差,切換失敗,導(dǎo)致掉話。

【解決方案】

1、eSRVCC配置的B2門限GSM的RSSI是-95,設(shè)置不合理,修改B2門限;2、檢查2G鄰區(qū)配置是否合理

【問題總結(jié)】

開通VoLTE業(yè)務(wù)的狀況,部分4G掩蓋不好的地方,需要2G信號來補(bǔ)充,因此,需要合理正確的配置2G鄰區(qū),以及設(shè)置合理的4G切換2G的門限。

案例5:無線鏈路失敗的掉話

【問題描述】

主叫RRC重建被拒后,重新發(fā)起RRC建立,網(wǎng)絡(luò)側(cè)下發(fā)的RRC重配攜帶QCI9和QCI5,QCI1丟失,導(dǎo)致掉話。

【問題分析】

1、主叫11:21:17.458發(fā)INVITE,11:21:24.266回ACK,會話建立。

CallId=649147781_175370312@2409:8809:8280:99:4e62:643d:cff7:9d9d主叫11:22:45.670收到網(wǎng)絡(luò)側(cè)的bye,Reason:SIP;cause=503

2、被叫11:21:24.424收到ACK,會話建立。

SIPCallID=p65543t1428981679m222868c482102s4

被叫11:22:39.119上報B2,沒有進(jìn)行eSRVCC,懷疑eNodeB未收到,或者eNodeB收到了下發(fā)切換命令后終端未收到

被叫11:22:40.439發(fā)A3,但是沒有切換,目標(biāo)小區(qū)未配為服務(wù)小區(qū)的鄰區(qū),上行eNodeB未收到或eNodeB收到了下發(fā)切換命令終端未收到。后服務(wù)小區(qū)信號質(zhì)量變差,UE掉線釋放上下文

被叫所在小區(qū)的eNodeBID173045,TAC9450,PhysicalcellID=409

3、11:22:44.903rrcConnectionReestablishmentRequest,重建拒絕之后,由于有數(shù)據(jù)要上傳,UE重新建立了RRC,但是由于mme上下文被釋放,網(wǎng)絡(luò)側(cè)無法恢復(fù)建立QCI=1專載,依據(jù)芯片的實現(xiàn),終端向網(wǎng)絡(luò)側(cè)發(fā)送SIPBYE發(fā)起拆線,判決掉話。

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論