資源描述：
《廣州中興VoLTE優(yōu)化案例》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫(kù)。
1、案例1：異頻重定向掉話案例【問(wèn)題描述】主叫占用廣州天河區(qū)魚(yú)珠木材市場(chǎng)D-ZLH-3（EARFCN=38100PCI=83CELLID=135693）小區(qū)通話時(shí)，信號(hào)強(qiáng)度為-101dbm左右，出現(xiàn)一次RRCConnectionRelease，導(dǎo)致承載拆除，引起一次主叫掉話。【問(wèn)題分析】分析測(cè)試數(shù)據(jù)，發(fā)現(xiàn)UE占用服務(wù)小區(qū)廣州天河區(qū)魚(yú)珠木材市場(chǎng)D-ZLH-3（EARFCN=38100PCI=83CELLID=135693）在通話的過(guò)程中信號(hào)越來(lái)越差，之后上報(bào)測(cè)量報(bào)告A2事件，eNODEB收到報(bào)告后發(fā)起異頻重定向判決，下發(fā)RRCConnectionRelease，由異頻
2、重定向后，eNodeB向MME發(fā)送uecontextreleaserequest，mme釋放專(zhuān)用承載。當(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在該路段僅是偶爾測(cè)量到目標(biāo)小區(qū)的信號(hào)，這種環(huán)境極容易觸發(fā)異頻重定向。【解決方案】關(guān)閉異頻重定向，復(fù)測(cè)問(wèn)題解決，服務(wù)小區(qū)后臺(tái)統(tǒng)計(jì)指標(biāo)無(wú)異常。【問(wèn)題總結(jié)】根據(jù)拉網(wǎng)統(tǒng)計(jì)，目前該類(lèi)掉話占總掉話次數(shù)的80%以上，對(duì)測(cè)試指標(biāo)影響非常嚴(yán)重。異頻重定向觸發(fā)原理：小區(qū)間沒(méi)定義鄰區(qū)關(guān)系，當(dāng)鄰區(qū)滿(mǎn)足切換條件時(shí)，主服務(wù)小
3、區(qū)無(wú)法切換到鄰區(qū)，基站會(huì)給UE下發(fā)系統(tǒng)內(nèi)重定向。優(yōu)化辦法：通過(guò)關(guān)閉異頻重定向的功能來(lái)規(guī)避該事件，除此之外，異頻鄰區(qū)的完善需要加大優(yōu)化力度。后續(xù)解決辦法：除了做好鄰區(qū)優(yōu)化外，中興將在下個(gè)版本加入基于QCI的異頻重定向功能，禁止專(zhuān)用承載的業(yè)務(wù)發(fā)生異頻重定向。。案例2：異系統(tǒng)重定向掉話案例【問(wèn)題描述】VoLTE測(cè)試eSRVCC過(guò)程中，發(fā)現(xiàn)eSRVCC執(zhí)行的是CCO，而不是PS切換。而CCO對(duì)于VoLTE語(yǔ)音來(lái)說(shuō)，必然導(dǎo)致掉話?！締?wèn)題分析】具體如下圖所示。1.對(duì)于PSHO、CCO、重定向，優(yōu)先級(jí)為PSHO>CCO>重定向。那么現(xiàn)在的問(wèn)題就是eSRVCC過(guò)程執(zhí)行的為什么是
4、CCO而不是PSHO。2.重點(diǎn)排查的就是eSRVCC相關(guān)配置：（1）eSRVCC功能開(kāi)關(guān)：未發(fā)現(xiàn)問(wèn)題。（2）系統(tǒng)間鄰區(qū)配置：a.GSM鄰區(qū)配置：重點(diǎn)查看“PS切換能力”配置的是否為：“是[1]”。PS切換能力表示GSM鄰區(qū)的PS?HO能力。當(dāng)GSM鄰區(qū)支持PS?HO能力，服務(wù)小區(qū)可以向該鄰區(qū)發(fā)起PS切換。未發(fā)現(xiàn)錯(cuò)誤。b.GSM鄰區(qū)關(guān)系:重點(diǎn)查看“支持切換”配置的是否為“支持[1]”。是否“支持切換”代表服務(wù)小區(qū)是否支持向GERAN鄰區(qū)發(fā)起切換的指示。發(fā)現(xiàn)配置的是“不支持”。問(wèn)題就在這里。如下圖所示。【解決方案】修改GSM鄰區(qū)關(guān)系中，支持切換為“支持[1]”后，在
5、進(jìn)行eSRVCC切換，eSRVCC切換成功，VoLTE未出現(xiàn)掉話?！締?wèn)題總結(jié)】對(duì)于VoLTE語(yǔ)音來(lái)說(shuō)，無(wú)論是系統(tǒng)內(nèi)還是系統(tǒng)間eSRVCC，只要執(zhí)行的不是“切換”都會(huì)導(dǎo)致語(yǔ)音的掉話，包括重定向和CCO。因此，需要開(kāi)通的時(shí)候，保持GSM鄰區(qū)配置和GSM鄰區(qū)關(guān)系配置正確，嚴(yán)格按照中興的VoLTE開(kāi)通指導(dǎo)書(shū)來(lái)執(zhí)行。案例3：切換過(guò)程中專(zhuān)載被MME釋放【問(wèn)題描述】主被叫在呼叫建立的過(guò)程中，專(zhuān)載建立與切換幾乎同時(shí)發(fā)生，專(zhuān)載剛剛建立完成又在切換過(guò)程中被釋放，終端回復(fù)invite580，呼叫未接通?！締?wèn)題分析】1、主叫收到invite183消息并建立專(zhuān)載，但在專(zhuān)載建立前主叫已上報(bào)
6、A3測(cè)報(bào)，所以幾乎在主叫上發(fā)承載建立成功的NAS消息的同時(shí)（10:19:29.959），主叫收到了基站下發(fā)的切換重配消息，消息中包含釋放QCI1的信息：2、再看基站側(cè)信令，基站收到終端上報(bào)的A3測(cè)報(bào)后，從源小區(qū)發(fā)給MME的HandoverRequired里面，有三條承載，分別是QCI9/QCI5/QCI1：3、從MME發(fā)給目標(biāo)小區(qū)的HandoverRequest消息里面e_RABInformationList有三條承載，但是e_RABToBeSetupListHOReq里面只有兩條，少了QCI1的：4、由于HandoverRequest消息的e_RABToBeS
7、etupListHOReq里面只有兩條承載，所以目標(biāo)小區(qū)回給MME的HandoverRequestAcknowledge消息里面，也只有兩條承載：5、那么，在MME回給源小區(qū)的HandoverCommand里面ToAdd兩條承載QCI9和QCI5，Release了QCI1的承載，這就導(dǎo)致專(zhuān)載被釋放并導(dǎo)致未接通：終端專(zhuān)載建立成功后上發(fā)NAS消息給MME，但由于切換流程在前，MME收到NAS消息之前，MME已經(jīng)發(fā)給目標(biāo)小區(qū)的HandoverRequest消息，里面e_RABToBeSetupListHOReq少了QCI1的承載，所以ReleaseQCI1的承載?！窘?/p>
8、決方案】開(kāi)啟X2接口，使
