VOLTE關(guān)鍵性能指標(biāo)優(yōu)化

VOLTE關(guān)鍵性能指標(biāo)優(yōu)化第1頁/共37頁內(nèi)容提要VOLTE接通率VOLTE掉話率RRC重建優(yōu)化呼叫建立時延和MOS優(yōu)化第2頁/共37頁接通率-定義和信令流程接通率定義:成功完成呼叫次數(shù)/終端發(fā)起呼叫總數(shù)。處于RRC空閑態(tài)的終端由于有業(yè)務(wù)要傳輸，將首先發(fā)起ServiceRequest流程，回到RRC連接態(tài)，然后發(fā)送SIPINVITE消息建立會話連接。第3頁/共37頁接通率-RRC連接成功率優(yōu)化RRC連接不管是主叫發(fā)起INVITE后還是被叫收到PAGING,首先需要上行同步并經(jīng)過PRACH\PUSCH\PDSCH幾個信道的信令傳輸,最后有相關(guān)定時器控制,因此可能導(dǎo)致RRC連接失敗的原因:1、上行底躁影響，下行SINR質(zhì)量2、信道功率影響3、T300定時器時長4、EUTRAN異常、時鐘告警、GPS問題優(yōu)化手段：1、干擾排查，無線環(huán)境優(yōu)化2、功率優(yōu)化3、增大T300定時器時長4、站點(diǎn)排障，多為RRU問題、時鐘告警第4頁/共37頁接通率-SIPINVITE消息建立優(yōu)化注意事項：1、主被叫信令交互都是通過IMS完成的2、CSFB實際也是VOLTE未接通3、尋呼機(jī)制4、起呼過程中主/被叫RL失敗導(dǎo)致RRC重建5、流程沖突，比如起呼后收到上一通專載去激活/RRC連接釋放等。6、起呼過程中發(fā)生切換導(dǎo)致未收到激活專載請求優(yōu)化手段：1、RL失敗無線環(huán)境優(yōu)化（RSRP，SINR）2、協(xié)助核心網(wǎng)/IMS抓LOG定位和解決問題3、協(xié)商過程中不支持VOLTE，檢查終端支持情況4、手機(jī)注冊VOLTE失敗，檢查SIM卡數(shù)據(jù)權(quán)限5、被叫TAU，TAC合理規(guī)劃和TALIST引入網(wǎng)元定位：IMS：SIP信令轉(zhuǎn)發(fā)過程中在IMS側(cè)出現(xiàn)問題EPC：1、在建立專載過程中出現(xiàn)問題且從TRACE信令分析問題出在EPC無線空口：RRC連接、切換、基站故障等且因無線出現(xiàn)問題（上行底躁大、下行SINR差等）根據(jù)跟蹤的信息定位問題是否出現(xiàn)在ENODEB，聯(lián)合分析。終端：信令分析中是否終端側(cè)信令丟失或有段時間無信令或信令在發(fā)往終端后出現(xiàn)問題軟件：因軟件原因在測試過程中流程沖突，比如通話過程中主叫起呼被叫等。人為或設(shè)備丟失：起呼過程中不小心掛機(jī)或被叫手機(jī)連接出現(xiàn)問題等第5頁/共37頁案例:EPC

現(xiàn)象描述:UE2占用844199PCI：69，RSRP=-97SINR=7，收到主叫INVITE呼叫建立流程走到被叫上發(fā)180ringing，網(wǎng)絡(luò)層未下發(fā)ModifyEPSBearerContextRequest，同時終端在做A3切換（目標(biāo)小區(qū)417950PCI:61），可能網(wǎng)絡(luò)側(cè)發(fā)送ModifyEPSBearerContextRequest到源小區(qū)導(dǎo)致終端切換到目標(biāo)小區(qū)收不到。20s網(wǎng)絡(luò)側(cè)返回503ServiceUnavailable，主叫callblocked。問題分析:無線分析:可能ModifyEPSBearerContextRequest發(fā)到源小區(qū)，同時終端發(fā)起A3請求切換到目標(biāo)小區(qū)導(dǎo)致軟件判斷未接通。IMS分析:IMS發(fā)的503響應(yīng)由PCC側(cè)發(fā)的ASR消息觸發(fā)，一般ASR是EPC側(cè)發(fā)的EPC分析:MME下發(fā)給UEModifyEPSBearerContextRequest給源enodeB,UE沒有響應(yīng)且后繼才發(fā)生切換導(dǎo)致:問題處理:

起呼過程中發(fā)生切換，UE已經(jīng)切換至目標(biāo)小區(qū)，核心網(wǎng)繼續(xù)發(fā)專載建立至源小區(qū)，導(dǎo)致UE根本就無法收到核心網(wǎng)下發(fā)的建立專載，待后續(xù)核心網(wǎng)優(yōu)化在volte呼叫過程中切換，最后向目標(biāo)小區(qū)加發(fā)一條建立專載第6頁/共37頁問題描述：福建移動進(jìn)行VoLTE語音呼叫路測時，發(fā)現(xiàn)被叫終端在LTE重新附著后，偶爾存在SAEGW不發(fā)送Downlinkdatanotification給MME的情況，造成部分SIP消息丟失，常見為SIP-INVITE消息不能轉(zhuǎn)發(fā)到被叫終端，最終導(dǎo)致呼叫失敗。問題定位：在分析現(xiàn)網(wǎng)采集到的VoLTE呼叫失敗記錄中，我們發(fā)現(xiàn)SAE-GW一個已知問題會引發(fā)SAE-GW丟棄SIP消息的場景：LTE附著后S-GW收到IMS下行數(shù)據(jù)包時沒有立即觸發(fā)DDN（DOWNLINK_DATA_NOTIFICATION）流程，具體場景如下：1）LTE附著時創(chuàng)建CMNET默認(rèn)承載（EBI-5）;2）VoLTE終端發(fā)起IMSAPN的PDN連接（IPv6地址）建立第二個默認(rèn)承載（EBI-6）；3）為完成IPv6地址分配，P-GW需要向終端側(cè)發(fā)送IPv6RouterAdvertisement消息，由于發(fā)送該下行數(shù)據(jù)時，EBI-6還沒激活（Modify_Bearer_Request消息尚未收到），所以S-GW置位尋呼標(biāo)志（EBI-5和EBI-6）及啟動尋呼時長（60s）；4）S-GW在EBI-6收到Modify_Bearer_Request消息，清除EBI-6的尋呼標(biāo)志，下發(fā)IPv6RouteAdvertisement消息后，eNB釋放無線連接（收到Release_Access_Bearer_Request），但此時EBI-5的尋呼標(biāo)志還在置位。（改進(jìn)2）5）當(dāng)SIP下行數(shù)據(jù)（例如被叫側(cè)第一個SIP消息-INVITE）到達(dá)時，緩存指示會觸發(fā)尋呼流程（發(fā)起DDN請求），但由于此時EBI-5的尋呼標(biāo)志尚未清除（尋呼定時器未超時），所以S-GW不會發(fā)起新的尋呼請求，導(dǎo)致SIP消息因緩存溢出而丟失。（改進(jìn)1）6）直到S-GW的尋呼定時器超時后，S-GW才會真正發(fā)出DDN請求以下發(fā)SIP下行數(shù)據(jù)。解決方案：經(jīng)過安裝新補(bǔ)丁，SAE-GW在上述步驟4和5的處理機(jī)制中作了改變，即:改進(jìn)1）當(dāng)S-GW上緩存指示觸發(fā)尋呼流程時，將清除尋呼指示并終止尋呼定時器，以保證S-GW可以觸發(fā)DDN消息；改進(jìn)2)當(dāng)收到Release_Access_Bearer請求消息時，S-GW將重置尋呼標(biāo)志。SAE-GW上安裝了補(bǔ)丁實現(xiàn)了上述S-GW尋呼機(jī)制改進(jìn)。案例:EPC

第7頁/共37頁MMEpaging機(jī)制現(xiàn)網(wǎng)MMEpaging機(jī)制：第一次PSpaging后如未收到響應(yīng)，每隔4s重復(fù)一次，共重復(fù)兩次(間隔8s)；如仍未收到響應(yīng)則通過SGs接口開始請求CSpaging。通常終端未收到PSpaging后會在10s-12s左右收到Cspaging開始進(jìn)行CSFB。第8頁/共37頁案例:終端

信令流程分析：S1ap消息跟蹤MME已將s1paging下發(fā)到正確eNBEmil消息跟蹤eNB已收到s1paging并將rrcpaging通過空口發(fā)向被叫UEUElog顯示被叫終端未收到eNB下發(fā)的paging消息pagingnoresponse終端未收到pagingRrcpaging終端問題，已通過HTC終端補(bǔ)丁解決第9頁/共37頁內(nèi)容提要VOLTE接通率VOLTE掉話率RRC重建優(yōu)化呼叫建立時延和MOS優(yōu)化第10頁/共37頁掉話率-定義和涉及流程掉話率定義為：掉話次數(shù)/成功建立呼叫次數(shù)通話保持過程中會出現(xiàn)切換和ESRVCC。通話結(jié)束后主叫上發(fā)BYE，收到網(wǎng)絡(luò)BYE200，后去激活專載，最后RRC連接釋放。第11頁/共37頁掉話率-原因分析和優(yōu)化措施掉話出現(xiàn)原因：切換出現(xiàn)問題/ESRVCC出現(xiàn)問題；上/下行無線鏈路失步導(dǎo)致RRC重建；非正常去激活承載QCI1或QCI9；非正常上發(fā)BYE；

BYE后流程問題；通話過程中主叫起呼被叫

IMS周期注冊其他；優(yōu)化措施：EPC/IMS：1、非正常去激活承載QCI1或QCI9，非正常上發(fā)BYE；BYE后流程問題；IMS周期注冊無線空口：RRC連接重建、切換、基站故障等引起的問題（上行底躁大、下行SINR差等）軟件：因軟件原因在測試過程中流程沖突，比如通話過程中主叫起呼被叫等。設(shè)備丟失：MOS丟失等。第12頁/共37頁問題1描述：在跨廠家區(qū)域做切換驗證，從諾基亞到中興切換都成功，中興小區(qū)(PCI=29)到諾基亞小區(qū)（PCI=264），切換均失敗，原因為網(wǎng)路側(cè)配置錯誤。問題1定位：如下圖所示的信令，當(dāng)UE駐留在PCI29小區(qū)時，該eNB為UE配置的AntennaInfo參數(shù)為AntennaInfo-r10格式：當(dāng)UE切換至諾基亞小區(qū)PCI=264的時候，eNB下發(fā)給UE的重配置消息中的AntennaInfo字段為AntennaInfo格式（即r8格式），而不是一個完整的配置，如下圖信令：案例:切換掉話

UE對收到的切換命令進(jìn)行檢查時，發(fā)現(xiàn)對antennaInfo參數(shù)的配置不正確而導(dǎo)致切換失敗，從而觸發(fā)RLF。解決方案：9月中旬外場升級了基站版本。升級后用高通終端驗證室內(nèi)外切換均正常。第13頁/共37頁案例:異常RRC連接釋放

問題描述：被叫UE占用PCI：61，收到來自主叫的BYE后,回BYE200,緊接著發(fā)生切換,1S后RRC連接釋放.問題原因：

1、為什么被叫收到BYE后1S在沒有回復(fù)去專載接收情況下，網(wǎng)絡(luò)又下發(fā)RRC連接釋放。處理進(jìn)展：已抓取LOG，定位中第14頁/共37頁案例:IMS注冊引起掉話

現(xiàn)象描述:UE2占用988419PCI：323，異常發(fā)起IMS注冊請求，導(dǎo)致無法走IMSSIP通話流程，導(dǎo)致主叫掉話。問題分析:無線側(cè)分析:無線RSRP:-80dBm,SINR:17以上，無線服務(wù)質(zhì)量良好，懷疑IMS問題IMS分析:手機(jī)問題，網(wǎng)絡(luò)側(cè)設(shè)置注冊周期為3600s，手機(jī)到了注冊周期仍未完成注冊導(dǎo)致IMS強(qiáng)行釋放當(dāng)前VOLTE呼叫,IMS側(cè)信令:問題處理:

正常情況下，終端會在注冊周期前完成注冊，或者注冊不應(yīng)影響正在進(jìn)行的本次通話，聯(lián)系終端廠家,待終端廠家解決第15頁/共37頁案例:異常去激活QCI9

問題分析：發(fā)生這個問題是因為UE建立了兩個承載,一個為ipv4承載給正常上網(wǎng)用的，另一個是ipv6承載，這個ipv6承載是無法上ipv6網(wǎng)(因為沒有對接ipv6

骨干網(wǎng)),UE得到的ipv6地址與其他UE有沖突觸發(fā)UPCC刪除這個多余的ipv6承載，這個不會影響正常業(yè)務(wù)(IPV4的承載還在)。另外不是所有的UE都會建兩個承載，和UE的終端類型有關(guān)，當(dāng)前大部分的終端都只是建一個ipv4承載。剛也和測試人員陳斌電話確認(rèn)，這種現(xiàn)象不影響正常上網(wǎng)。核心網(wǎng)可以根據(jù)測試號只讓ue建立ipv4承載,如果只是為了測試的話，可以按這個方案先規(guī)避。

現(xiàn)象描述:UE1通話過程中接收來自網(wǎng)絡(luò)數(shù)據(jù)業(yè)務(wù)尋呼，去激活QCI9，但是無BYE上報，還是在通話結(jié)束后上發(fā)BYE，不影響用戶感知。第16頁/共37頁內(nèi)容提要VOLTE接通率VOLTE掉話率RRC重建優(yōu)化呼叫建立時延和MOS優(yōu)化第17頁/共37頁RRC重建-RRC重建觸發(fā)時機(jī)RRCsecurityactiveRRC重建只能由已經(jīng)激活了接入層安全算法的UE觸發(fā)（時間點(diǎn)如右圖所示），在此之前UE只能回到RRC_IDLE狀態(tài)，觸發(fā)小區(qū)重選和TAU；現(xiàn)網(wǎng)有不少ERAB建立過程中收不到securitycommandcomplete消息導(dǎo)致ERAB建立失敗，這種情況下，無法進(jìn)行RRC重建，網(wǎng)絡(luò)會記為無線掉線，LTE_5004a指標(biāo)也會惡化，如下圖所示：第18頁/共37頁RRC重建-觸發(fā)條件RRC重建只能由UE觸發(fā)，可能的觸發(fā)條件有以下幾種：UE發(fā)現(xiàn)上行無線鏈路失敗T310expiryasresultofout-of-syncproblemscontrolledbyn310(LNCEL),n311(LNCEL),

t310(LNCEL)uponrandomaccessproblemindicationfromMACuponindicationfromRLCthatthemaximumnumberofretransmissionshasbeenreached切換失敗handoverfailureduetot304expiryforintraLTEHOcontrolledbyt304IntraLte(LNCEL))mobilityfromE-UTRAfailureduetot304expiryapplicableforinter-RAThandovertypes;controlledbyt304InterRAT(LNCEL)forPSHOandSRVCCtoWCDMA,t304InterRatTd(LNCEL)forPSHOtoTD-SCDMA;t304InterRATGsm(LNCEL)

forSRVCCtoGSM,t304eNaccGsm(LNCEL)

foreNACCtoGSM)其他原因integritycheckfailureRRCconnectionreconfigurationfailure關(guān)掉Nokia一些私有下行無線鏈路失敗檢測的方法，并不能減少RRC重建的觸發(fā)第19頁/共37頁RRC重建-請求的原因分類3GPPTS36.331規(guī)定RRC重建請求消息reestablishmentCause

字段有以下分類：ifthere-establishmentprocedurewasinitiatedduetoRRCreconfigurationfailure(i.e.,theUEisunabletocomplywiththereconfiguration),UEsetsthereestablishmentCausetothevalue'reconfigurationFailure‘ifthere-establishmentprocedurewasinitiatedduetointra-LTEhandoverfailureorinter-RATmobilityfromEUTRAfailure,UEsetsthereestablishmentCausetothevalue'handoverFailure'OtherwiseUEsetsthereestablishmentCausetothevalue'otherFailure‘.NOTE:ThisincludesT310RLFfailure.Nokia定義了以下幾種RRC重建請求的類型：M8008C4RRC_CON_RE_ESTAB_ATT所有重建請求M8008C6RRC_CON_RE_ESTAB_ATT_HO_FAIL對應(yīng)規(guī)范handoverFailureM8008C8RRC_CON_RE_ESTAB_ATT_OTHER對應(yīng)規(guī)范otherFailure暫定reconfigurationFailure=M8008C4-M8008C6-M8008C8，以廈門網(wǎng)絡(luò)為例：

otherFailure占大部分，

handoverFailure有一定比例，

reconfigurationFailure非常少，幾乎可以忽略不計。第20頁/共37頁RRC重建-比例優(yōu)化重建比例定義為：RRC重建請求次數(shù)/RRC建立請求次數(shù)重建比例劣化小區(qū)：重建比例高于5%RRC重建本質(zhì)上是由無線質(zhì)量差引起的，無線環(huán)境優(yōu)化是關(guān)鍵，任何參數(shù)優(yōu)化都不可能使無線環(huán)境變好RRC重建比例相關(guān)參數(shù)優(yōu)化，具體見后面4頁膠片：隨機(jī)接入過程優(yōu)化，可以改善切換失敗以及其他隨機(jī)接入失敗導(dǎo)致的RRC重建；上行無線鏈路失步相關(guān)參數(shù)優(yōu)化；切換定時器t304優(yōu)化；上行RLC最大重傳次數(shù)優(yōu)化；第21頁/共37頁1.RLFduetoT310expiryatUEForUE“normaloperation”inthefigureabovemeans:UEnotwaitingforRRCConnectionSetup/Reject(T300notrunning)UEnotwaitingforRRCRe-establishmentEstablishment/Reject(T301notrunning)handovernotongoing(T304notrunning)NoRLFrecoveryongoing(T311notrunning)n310consecutiveout-of-syncindicationsn311consecutivein-syncindicationsduringt310RRCconnectionre-establishmentattemptedduringt311CellreselectionandTrackingAreaUpdateifRRCRe-Establishmentfails減少此類RRC重建：上行失步檢測條件更嚴(yán)格，恢復(fù)更容易RRC重建-原理1第22頁/共37頁2.RLFduetomaximumULRLCreTxreachedfromRRCConnectionReconfiguration:drb-ToAddModListdrb-ToAddModListvalue1drb-Identity :1rlc-Configamul-AM-RLCt-PollRetransmit :ms40pollPDU :p32pollByte :kB25

maxRetxThreshold :t8RLCretransmissionsuntilmaxRLCretxthresholdisreachedRRCconnectionre-establishmentattemptedduringt311CellreselectionandTrackingAreaUpdateifRRCRe-Establishmentfails減少此類RRC重建：增加ULRLC最大重傳次數(shù)maxRetxThreshold增加最大HARQ重傳次數(shù)harqMaxTrUl，可以減少RLC重傳次數(shù)Vendor參數(shù)：<pname="drbAmMxRtxTh">16</p>RRC重建-原理2第23頁/共37頁3.RLFduetonon-HOrandomaccessfailureExample:RandomAccesstriggeredduetomissingPUCCHSRresources,orPDCCHorderRRCconnectionre-establishmentattemptedtoservingcellduringt311CellreselectionandTrackingAreaUpdateifRRCRe-EstablishmentfailsUEattemptingrandomaccesstoservingcell.RACHfailure“Non-HOrandomaccess”meansPDCCHorder-triggeredRA(RL30/RL25)RandomAccessSchedulingRequest減少此類RRC重建：增強(qiáng)隨機(jī)接入過程的魯棒性RRC重建-原理3第24頁/共37頁4.RLFduetoHOfailurefromRRCConnectionReconfiguration:mobilityControlInfotargetPhysCellId :33

t304 :ms1000newUE-IdentityBin :14EB(=5355)RRCConnReConfwithMobilityInfo(”HOcommand”)RRCconnectionre-establishmentattemptedtosourceortargetcellduringt311CellreselectionandTrackingAreaUpdateifRRCRe-EstablishmentfailsT304runningwhileUEattemptingaccesstotargetcell.T304expires減少此類RRC重建：增加t304；增強(qiáng)非競爭隨機(jī)接入過程的魯棒性RRC重建-原理4第25頁/共37頁UEeNBRRCConnectionReestablishmentRequest(Msg3)RRCConnectionReestablishment(Msg4)RRCConnectionReestablishmentComplete(Msg5)PRACHRandomAccess(Msg1)PRACHRandomAccessResponse(Msg2)隨機(jī)接入Cellselectionprocessacc.to36.304RLF,HOfailure,mobilityfromE-UTRAfailure,integritycheckfailure,RRCconnectionreconfigurationfailuredetectedRRC重建RRC重建-劣化小區(qū)分析3GPP規(guī)定UE發(fā)起RRC重建的目標(biāo)小區(qū)必須是擁有UE上下文信息的小區(qū)，因此RRC重建的目標(biāo)小區(qū)有以下要求：FornohandoverprocedureongoingservingcellForongoinghandoverproceduresourcecell（切換過程取消）targetcell（切換過程完成）UE發(fā)起RRC重建的目標(biāo)小區(qū)，很可能不是符合條件的目標(biāo)小區(qū)：發(fā)生RRC重建的場景一般在無線比較差，小區(qū)邊界或者信號雜亂的地方；無線失步或者切換失敗后，UE首先要進(jìn)行小區(qū)選擇，選擇合適的小區(qū)駐留，這種情況下，駐留的小區(qū)可能是不符合條件的小區(qū)；如果目標(biāo)小區(qū)不符合條件，RRC重建會被拒絕掉，有時候符合條件的目標(biāo)小區(qū)如果已經(jīng)釋放UE上下文信息，這時RRC重建請求也會被拒絕掉，廈門現(xiàn)網(wǎng)RRC重建拒絕比例接近40%。第26頁/共37頁RRC重建-終端異常情況個別終端如中興MF91S2對DRX支持有問題，會導(dǎo)致短時間出現(xiàn)大量的RRC重建，日常指標(biāo)監(jiān)控，如果發(fā)現(xiàn)有短時間大量RRC重建統(tǒng)計，需要分析是否是終端原因引起的：關(guān)閉DRX后RRC重建是否大幅減少？如果判斷是終端不支持DRX，在不關(guān)閉DRX情況下，打開上行預(yù)調(diào)度可以減少，終端進(jìn)入DRX休眠，改善RRC重建比例；LTE815上行預(yù)調(diào)度打開的影響：ULresourcesareassignedwithasufficienthighfrequencyandUEcannotbetransitedintoDRXSleepasDRXInactivityTimerwillbestillrunningGainfromLTE815isareduceddelayinULschedulingasUEhasalwaysgrantassigned(withinspecifiedtimeperiod)evenifnonewtransmissionisbufferedOncetheUEhasgoneintoDRXsleep,itwillnotbelongeravailabletobeconsideredforproactiveresourceassignmentuntilthenextphaseofbeingDRXActiveoccurs第27頁/共37頁內(nèi)容提要VOLTE接通率VOLTE掉話率RRC重建優(yōu)化呼叫建立時延和MOS優(yōu)化第28頁/共37頁呼叫建立時延-指標(biāo)定義和流程呼叫建立時延定義:呼叫建立時延-RRC(s)：呼叫時終端隨機(jī)接入Message1直到收到RRCComplete進(jìn)行DRB配置和SecurityMode配置呼叫建立時延-IMS(s)：SIPINVITE到180RING。第29頁/共37頁問題現(xiàn)象描述：被叫收到paging或INVITErequest消息很慢，約5-10s網(wǎng)絡(luò)信令分析：被叫側(cè)TAS在做TADS預(yù)選的時候，HSS發(fā)ATI但是PCC沒有響應(yīng)，最終導(dǎo)致5秒以后LDRA超時返回3002后，TAS才轉(zhuǎn)發(fā)INVITE問題定位&解決：NTHLR數(shù)據(jù)未完全配置，導(dǎo)致HSS發(fā)ATI到未配置的SE時NTHLR不響應(yīng)。將NTHLR的18塊SE板數(shù)據(jù)配全后解決數(shù)據(jù)配置時間點(diǎn)呼叫建立時延-案例分析第30頁/共37頁問題描述：在同一個小區(qū)內(nèi)進(jìn)行測試占用同一個小區(qū)，但是每次呼叫過程中主叫都會頻繁發(fā)起combinedTAU過程。而且TAU發(fā)生的時機(jī)也有好幾種：1.首次TAU發(fā)生在終端上發(fā)IMS_SIP_INVITE->OK之后；2.首次TAU發(fā)生在終端上發(fā)IMS_SIP_INVITE->OK之前，這時會發(fā)現(xiàn)主被叫不同步現(xiàn)象，具體表現(xiàn)為被叫顯示已接通但是主叫在撥號中，主叫接通時間遲于被叫10s；3.在終端掛機(jī)后連續(xù)TAU。問題分析：對于第一種情況，combinedTAU發(fā)生在終端上發(fā)IMS_SIP_INVITE->OK之后并未對通話照成影響，但是如第二種情況combinedTAU發(fā)生在終端上發(fā)IMS_SIP_INVITE->OK之前，在TAU這段時間內(nèi)用戶平面內(nèi)不進(jìn)行任何業(yè)務(wù)，所以在這段時間內(nèi)就導(dǎo)致了主叫接通時延，這個時間剛好在10s左右，這也是導(dǎo)致主被叫不同步的原因之一。至于為什么剛好在10s左右著就與inactivatetimer設(shè)置為10s有關(guān)。TAU過程中只建立srb進(jìn)行信令交互，整個過程沒有數(shù)據(jù)包發(fā)送，基站側(cè)設(shè)置inactivetimer10s，基站檢測到數(shù)據(jù)面無數(shù)據(jù)10s后發(fā)送release給終端釋放rrc連接。之后servicerequest（時延100ms內(nèi)）重新建立rrc連接后收到被叫的200OK，完成建立通話。呼叫建立時延-TAU案例分析進(jìn)一步分析發(fā)現(xiàn)UE上發(fā)的TAU請求為combinedTA/LATAU，而聯(lián)合TAU請求需要在CS域和PS域都進(jìn)行更新。由于終端在測試時設(shè)置成PSONLY（按理說設(shè)置成PSONLY后不會進(jìn)行combinedTAU，具體是什么原因?qū)е陆K端還會發(fā)起請求還需終端工程師進(jìn)一步排查），從流程上看TAUcomplete，但實際上只有PS域的更新而CS域并未更新成功，也就是說聯(lián)合更新實際上并未成功，這就引發(fā)了頻繁TAU請求。解決方案：核心網(wǎng)與CS核心網(wǎng)調(diào)通，聯(lián)合位置更新成功。目前已解決第31頁/共37頁MOS優(yōu)化對于VoLTE語音質(zhì)量，一般以MOS值作為參考考核指標(biāo)。LTE的RF優(yōu)化是VoLTE優(yōu)化之本，做好弱SINR（-6到6）區(qū)域的優(yōu)化可以有效的提升VoLTEMOS值；避免乒乓切換，減少TM模式切換及TAU是VoLTEMOS優(yōu)化工作的關(guān)鍵；減少CSFB幾率及選擇合適的AMR速率可以得到合理的MOS值結(jié)果，在測試前期，整網(wǎng)的VoLTE語音MOS值波動較大，一方面是MOS盒穩(wěn)定性問題，另外一方面則是無線/核心網(wǎng)參數(shù)設(shè)置導(dǎo)致；案例1描述：外場VoLTE測試，主被叫終端設(shè)置為高清23.85k后可以使用高清23.85k語音編碼速率。在9月中旬外場測試發(fā)現(xiàn)設(shè)置為23.85k的速率，看到PDCP速率只有14kbps左右，與23.85kbps預(yù)期24kbps的速率不一致。懷疑終端未使用高清通話。問題1定位：1）初步懷疑終端NV值修改錯誤。跟HTC工程師確認(rèn)，查詢高清的QXDMLog發(fā)現(xiàn)NV值修改沒問題，確認(rèn)編碼速率的確為12.2k。在主叫的invite消息里發(fā)現(xiàn)主叫是支持AMR和AMR-WB。說明NV參數(shù)設(shè)置正確且已生效2）從被叫測試查看invite消息發(fā)現(xiàn)，網(wǎng)絡(luò)側(cè)未下發(fā)AMR-WB速率?；旧洗_認(rèn)是網(wǎng)絡(luò)側(cè)把AMR-WB丟棄。3）聯(lián)系IMS核心網(wǎng)同事抓包分析，經(jīng)過TAS后，AMR-WB被丟棄。確認(rèn)為TAS的問題。經(jīng)確認(rèn)9月初TAS版本升級，AMR-WBLICENSE沒有及時打上。解決方案：TAS添加license后，外場驗證，高清電話可以正常撥通：第32頁/共37頁問題描述：用CDS48KMOS盒對在目前LTE網(wǎng)絡(luò)下的通話質(zhì)量進(jìn)行MOS評估時，發(fā)現(xiàn)當(dāng)通話建立在專用承載（GBR）下時CDSMOS打分值偏低，一直在3.5以下。問題定位：1