VoLTE無線優(yōu)化指導(dǎo)書

1、VoLTE網(wǎng)絡(luò)優(yōu)化指導(dǎo)書目錄VoLTE網(wǎng)絡(luò)優(yōu)化指導(dǎo)書11VoLTE網(wǎng)絡(luò)結(jié)構(gòu)簡介51.1IMS相關(guān)網(wǎng)元簡介51.1.1SBC51.1.2CSCF61.1.3VoLTE AS61.1.4HSS71.1.5MGCF/IM-MGW71.1.6BGCF71.1.7DRA71.2IMS中的接口協(xié)議簡介71.2.1Diameter71.2.2RTP/RTCP81.2.3SIP簡介81.3SDP簡介91.3.1媒體協(xié)商91.3.2資源預(yù)留101.4被叫域選擇和錨定方案111.4.1VoLTE用戶被叫域選擇流程111.4.2被叫錨定方案122接入優(yōu)化132.1接入問題分類及現(xiàn)象132.2接入流程132.2.1V

2、oLTE注冊流程142.2.2VoLTE呼叫流程162.3接入問題原因分析及排查思路182.3.1IMS注冊慢/無法注冊182.3.2VoLTE終端CSFB212.3.3呼叫建立時(shí)延長222.3.4未接通232.4接入問題無線主要優(yōu)化手段322.5附錄1：VoLTE注冊端到端詳細(xì)流程332.6附錄2：VoLTE呼叫端到端詳細(xì)流程（主被叫均在VoLTE）363保持優(yōu)化383.1保持問題現(xiàn)象及分類383.2eSRVCC切換流程383.3保持問題原因分析及排查思路383.3.1eSRVCC切換準(zhǔn)備時(shí)延長383.3.2eSRVCC用戶面中斷時(shí)延長393.3.3掉話403.4保持問題無線主要優(yōu)化手段47

3、3.5附錄1：eSRVCC端到端詳細(xì)流程493.6附錄2：eSRVCC開啟導(dǎo)致4G現(xiàn)網(wǎng)的問題533.6.1eSRVCC切換功能開啟導(dǎo)致ATU設(shè)備掉線問題處理533.6.2eSRVCC開啟后CSFB偶爾失敗問題處理534附錄：案例集544.1接入案例54案例1：VoLTE SIM卡無法同時(shí)在華為中興區(qū)域使用問題處理54案例2：HTC終端IMS注冊慢55案例3：MME參數(shù)設(shè)置錯(cuò)誤導(dǎo)致VoLTE被叫CSFB問題處理58案例4：SBC的AAR消息不合規(guī)導(dǎo)致VoLTE被叫CSFB問題61案例5：SBC回復(fù)500錯(cuò)誤導(dǎo)致終端SCFB65案例6：HTC資源釋放過慢導(dǎo)致呼叫建立延過長67案例7：終端側(cè)Invi

4、te信令丟失導(dǎo)致呼叫建立過長69案例8：DRA參數(shù)配置不合理導(dǎo)致呼叫建立時(shí)延長74案例9：中興SGW尋呼未緩存導(dǎo)致呼叫建立時(shí)延長75案例10：SBC收到UPDATE的200OK后沒有轉(zhuǎn)發(fā)76案例11：基站核心網(wǎng)加密算法配置不一致導(dǎo)致呼叫失敗78案例12：中興SBC發(fā)送的AAR消息中IP地址格式錯(cuò)誤導(dǎo)致未接通問題處理79案例13：中興SBC發(fā)送的STR消息錯(cuò)誤導(dǎo)致未接通問題處理81案例14：華為LDRA參數(shù)配置錯(cuò)誤導(dǎo)致未接通問題處理84案例15：中興AAR消息錯(cuò)誤導(dǎo)致未接通問題處理864.2保持案例88案例1：eSRVCC切換準(zhǔn)備時(shí)延長問題處理88案例2：HTC終端eSRVCC用戶面中斷時(shí)延長問

5、題處理90案例3：HTC終端呼叫20秒后掉話92案例4：無線鏈路失敗導(dǎo)致VoLTE掉話分析92案例5：弱覆蓋引起VoLTE掉話95案例6：GSM鄰區(qū)參數(shù)配置錯(cuò)誤eSRVCC失敗導(dǎo)致掉話96案例7：GSM鄰區(qū)遺漏重定向引起掉話98案例8：GSM鄰區(qū)配置不完整導(dǎo)致eSRVCC切換失敗101案例9：終端未上報(bào)B2測量報(bào)告無法進(jìn)行eSRVCC切換107案例10：LTE小區(qū)鄰區(qū)漏配導(dǎo)致VoLTE掉話109案例11：eSRVCC切換收到了CCO命令110案例12：VoLTE異廠家跨MME切換失敗問題處理111案例13：eSRVCC切換功能開啟導(dǎo)致ATU設(shè)備掉線問題處理116案例14：eSRVCC開啟后CS

6、FB偶爾失敗問題處理1201 VoLTE網(wǎng)絡(luò)結(jié)構(gòu)簡介VoLTE本質(zhì)是通過EPS來提供業(yè)務(wù)接入（包括無線承載和EPC承載），通過IMS核心網(wǎng)提供業(yè)務(wù)控制（包括會(huì)話控制和業(yè)務(wù)邏輯處理及被叫域選擇），通過與GSM網(wǎng)絡(luò)協(xié)助來提供業(yè)務(wù)連續(xù)性（eSRVCC等）。其邏輯架構(gòu)如下圖：1.1 IMS相關(guān)網(wǎng)元簡介1.1.1 SBCVoLTE SBC（Session Border Controller）-會(huì)話邊緣控制器，包含P-CSCF/AGW、ATCF/ATGW功能模塊。P-CSCF（Proxy CSCF）/AGW（Application Gateway）：是IMS中與用戶的第一個(gè)連接點(diǎn)，P-CSCF提供注冊鑒權(quán)

7、、信令保護(hù)、信令壓縮、媒體授權(quán)、QoS控制、信令路由、緊急呼叫、漫游計(jì)費(fèi)等功能。為支持補(bǔ)全以及緊急呼叫，P-CSCF需能識(shí)別緊急呼叫，獲取用戶位置信息，并在SIP信令中添加相應(yīng)信息，且能將位置信息映射為區(qū)號(hào)。ATCF/ATGW是VoLTE用戶在當(dāng)前所在網(wǎng)絡(luò)的信令面和媒體面的錨定點(diǎn)，在發(fā)生eSRVCC時(shí)將VoLTE用戶接入側(cè)的媒體面從LTE切換到電路域，并保持媒體面的連接。1.1.2 CSCF CSCF（Call Session Control Function）會(huì)話控制和路由，包含I-CSCF、S-CSCF、E-CSCF：S-CSCF（Server CSCF）：S-CSCF在IMS核心網(wǎng)中處于

8、核心的控制地位，負(fù)責(zé)對(duì)UE的注冊鑒權(quán)和會(huì)話控制，執(zhí)行針對(duì)主叫端及被叫端IMS用戶的基本會(huì)話路由功能，并根據(jù)用戶簽約IMS觸發(fā)規(guī)則，在條件滿足時(shí)進(jìn)行到AS的增值業(yè)務(wù)路由觸發(fā)及業(yè)務(wù)控制交互；I-CSCF（interrogating CSCF）：類似IMS的關(guān)口節(jié)點(diǎn)，提供S-CSCF指派、路由查詢功能；E-CSCF，從P-CSCF接受緊急會(huì)話建立請求，并完成用戶接入位置信息查詢和緊急呼叫路由等功能。目前I-CSCF和S-CSCF在物理實(shí)體上是合設(shè)的1.1.3 VoLTE AS 應(yīng)用服務(wù)器（Application Server）為IMS用戶提供增值業(yè)務(wù)，可以位于用戶歸屬網(wǎng)，也可以由第三方提供，主要包含

9、如下功能模塊：l MMTel AS（MultiMediaTelephony多媒體應(yīng)用服務(wù)器）：用于為VoLTE用戶提供多媒體基本業(yè)務(wù)和補(bǔ)充業(yè)務(wù)；l SCC AS（Service Call Continuity Application Server服務(wù)集中化和連續(xù)性應(yīng)用服務(wù)器）：實(shí)現(xiàn)VoLTE的被叫域選擇，eSRVCC過程中的信令控制；l 被叫錨定功能：支持CAP接口，提供被叫用戶錨定至IMS；l IM-SSF（IP Multimedia-Service Switch Function智能業(yè)務(wù)觸發(fā)網(wǎng)關(guān)）：用于觸發(fā)現(xiàn)有SCP，實(shí)現(xiàn)智能網(wǎng)業(yè)務(wù)邏輯；l 業(yè)務(wù)配置轉(zhuǎn)發(fā)（AP）：實(shí)現(xiàn)業(yè)務(wù)配置請求的匯聚和轉(zhuǎn)

10、發(fā)；l MRF（Multimedia Resource Function多媒體資源功能）：負(fù)責(zé)對(duì)媒體資源的控制和處理，實(shí)現(xiàn)音視頻播放、會(huì)議、DTMF收號(hào)和音頻錄音等功能。MRF包括多媒體資源控制器MRFC（Multimedia Resource Function Controller）和多媒體資源處理器MRFP（Multimedia Resource Function Processor）。1.1.4 HSS VoLTE中的HSS（Home Subscriber Server）-歸屬用戶服務(wù)器是HLR/AuC、IMS-HSS、EPS-HSS三合一融合設(shè)備，統(tǒng)一存儲(chǔ)VoLTE用戶在2/3/4G及

11、IMS的用戶數(shù)據(jù)，處理2/3/4G及IMS網(wǎng)絡(luò)中呼叫控制網(wǎng)元對(duì)用戶的數(shù)據(jù)訪問，還通過開通接口接收并響應(yīng)BOSS業(yè)務(wù)開通指令。1.1.5 MGCF/IM-MGWMGCF（Media Gateway Control Function媒體網(wǎng)關(guān)控制功能）用于IMS域與CS域的互通，負(fù)責(zé)完成控制面信令的互通（PSTN/CS域側(cè)ISUP/BICC協(xié)議與CM-IMS側(cè)SIP協(xié)議的交互和互通），并控制IM-MGW（IP Multimedia-Media Gateway媒體網(wǎng)關(guān)）完成用戶面媒體面的互通、規(guī)整、分析和路由、放音、放音抑制、視頻回落等功能。IM-MGW（媒體網(wǎng)關(guān)）負(fù)責(zé)在MGCF的控制下完成VoLTE

12、用戶面IP承載與CS域承載之間的轉(zhuǎn)換，提供編解碼轉(zhuǎn)換、承載資源管理和放音功能。1.1.6 BGCF BGCF（Breakout Gateway Control Function出口網(wǎng)關(guān)控制功能）用于IMS到CS的呼叫路由，BGCF收到來自S-CSCF的呼叫請求后根據(jù)本地配置選擇合適的MGCF進(jìn)行轉(zhuǎn)發(fā)。1.1.7 DRA DRA（Diameter Routing Agent路由代理節(jié)點(diǎn)）負(fù)責(zé)LTE Diameter信令目的地址翻譯和轉(zhuǎn)接, 實(shí)現(xiàn)LTE用戶的鑒權(quán)、位置更新、計(jì)費(fèi)管理。1.2 IMS中的接口協(xié)議簡介1.2.1 DiameterDiameter協(xié)議包括基本協(xié)議，NAS（網(wǎng)絡(luò)接入服務(wù)）協(xié)

13、議，EAP（可擴(kuò)展鑒別）協(xié)議，MIP（移動(dòng)IP）協(xié)議，CMS（密碼消息語法）協(xié)議等1.2.2 RTP/RTCP應(yīng)用層承載面協(xié)議，會(huì)話建立后，RTP（Real-time Transport Protocol實(shí)時(shí)傳輸協(xié)議）協(xié)議保證媒體流的實(shí)時(shí)傳輸；RTCP（Real-time Transport Control Protocol實(shí)時(shí)傳輸控制協(xié)議）協(xié)議對(duì)實(shí)時(shí)傳輸?shù)拿襟w流進(jìn)行監(jiān)控。1.2.3 SIP簡介會(huì)話（Session）：描述兩個(gè)用戶之間的媒體連接會(huì)話流程：實(shí)現(xiàn)主叫UE和被叫UE之間的多媒體會(huì)話會(huì)話流程中包括媒體的協(xié)商（包括媒體類型和編碼方式的協(xié)商）和雙方的資源預(yù)留過程。會(huì)話初始協(xié)議（Sessio

14、n Initial Protocol）是一個(gè)在IP網(wǎng)絡(luò)上進(jìn)行多媒體通信的應(yīng)用層控制協(xié)議，它被用來管理創(chuàng)建、修改和終結(jié)一個(gè)或多個(gè)參加者參加的會(huì)話進(jìn)程，與SDP、RTP/RTCP、DNS等協(xié)議配合，共同完成IMS中的會(huì)話建立及媒體協(xié)商。終端和網(wǎng)絡(luò)互為客戶端和服務(wù)器，使用標(biāo)準(zhǔn)的基于文本的請求（Request），然后以標(biāo)準(zhǔn)的基于文本的回復(fù)來應(yīng)答（Response）。1.2.3.1 請求（客戶端）REGISTER 注冊INVITE 邀請PRACK 提供臨時(shí)確認(rèn)UPDATE 更新連接狀態(tài)ACK 對(duì)INVITE消息的最終確認(rèn)BYE 掛斷SUBSCRIBE 訂閱事件通知NOTIFY 通知訂閱者新的事件CANC

15、EL 取消1.2.3.2 應(yīng)答（服務(wù)端）1XX-臨時(shí)響應(yīng)。表示請求已接收，接收方正在處理。常見的有：100Trying、183Provisional Acknowledge、180 Ringing2 XX -成功響應(yīng)。請求已成功收到、理解并被接受。常見的有：200 OK、202Accepted、204 No Notification3 XX -重定向響應(yīng)。請求方需要采取進(jìn)一步動(dòng)作以完成請求。4 XX -客戶端響應(yīng)錯(cuò)誤。客戶端提供了錯(cuò)誤的語法或者無法從服務(wù)端得到響應(yīng)。常見的有：401Unatuhorized、486Busy Here、481Call transaction does not ex

16、ist5 XX -服務(wù)端響應(yīng)錯(cuò)誤。服務(wù)器無法提供合法的請求。常見的有：500 Server Internal Error、503Service Unavailable、580Precondition Failure6 XX -全局失敗響應(yīng)。請求不能再任何一個(gè)服務(wù)器上得到滿足，產(chǎn)生該響應(yīng)的服務(wù)器需要知道有關(guān)用戶的確切信息。1.3 SDP簡介會(huì)話描述協(xié)議SDP（Session Description Protocol）協(xié)議為應(yīng)用層的控制協(xié)議，用于會(huì)話建立過程中的媒體協(xié)商。1.3.1 媒體協(xié)商ü 主叫和被叫UE在會(huì)話的建立過程匯總需要對(duì)媒體的類型和編碼方式達(dá)成一致，為此使用SDP請求和應(yīng)答

17、機(jī)制對(duì)媒體進(jìn)行協(xié)商。ü 雙方協(xié)商的媒體類型包括視頻、音頻、文本、聊天等。ü 每種媒體類型包括多種編碼方式，如音頻包括PCMU、G.726編碼、AMR-WB（自適用多速率寬帶）編碼等。ü 雙方需要協(xié)商都支持的媒體類型以及所使用的編碼方式。1.3.2 資源預(yù)留ü 為保證雙方所協(xié)商的媒體會(huì)話可以建立，空口需要為主叫和被叫用戶分配資源，在資源被成功預(yù)留之前，不能保證媒體會(huì)話可以建立ü 一般情況下進(jìn)行SDP提供/應(yīng)答的協(xié)商確定了媒體格式和編碼方式后可進(jìn)行資源預(yù)留。1.3.2.1 主叫資源預(yù)留的開始和結(jié)束ü 主叫UE發(fā)送Invite消息后，啟動(dòng)資

18、源預(yù)留過程。ü 主叫UE發(fā)送UPDATE請求表明資源預(yù)留成功UPDATE請求發(fā)送的前提：（1）主叫UE通過空口流程獲知通話資源預(yù)留成功（2）收到被叫針對(duì)PRACK的200OK響應(yīng)1.3.2.2 被叫資源預(yù)留的開始和結(jié)束ü 被叫UE收到主叫UE的Invite消息后，返回183響應(yīng)并啟動(dòng)資源預(yù)留過程。ü 被叫發(fā)送UPDATE200表明資源預(yù)留成功，前提為主叫和被叫的資源預(yù)留均成功。（1）被叫UE收到主叫的UE的UPDATE請求后得知主叫UE的資源預(yù)留成功。（2）被叫UE通過空口流程獲知通話資源預(yù)留成功。1.4 被叫域選擇和錨定方案1.4.1 VoLTE用戶被叫域選擇流

19、程T-ADS（Terminating Access Domain Selection），即被叫域選擇功能。VoLTE手機(jī)既有可以在電路域使用語音業(yè)務(wù)，也可在IMS域使用語音業(yè)務(wù)，且使用同樣的碼號(hào)，因此存在“被叫接續(xù)網(wǎng)絡(luò)選擇”的問題，即網(wǎng)絡(luò)如何識(shí)別被叫用戶當(dāng)前的駐留網(wǎng)絡(luò)，并接續(xù)到該用戶。三融合HSS/HLR執(zhí)行如下域選擇過程：ü 若用戶僅在IMS注冊，則應(yīng)選擇IMS域ü 若用戶盡在CS注冊，則應(yīng)選擇CS域ü 若用戶在IMS和CS均未注冊，則應(yīng)選擇IMS域ü 若用戶在IMS和CS均已注冊，則應(yīng)進(jìn)一步判斷用戶在SGSN和MME的注冊狀態(tài)：l 若有用戶在SGSN

20、的注冊信息，無論用戶是否在MME注冊，則應(yīng)選擇CS域l 若無用戶在SGSN的注冊信息，而有用戶在MME的注冊信息，則向MME查詢用戶狀態(tài)和終端能力ü 若無用戶在SGSN的注冊信息，也無用戶在MME的注冊信息（用戶在電路域關(guān)閉了所有APN），則應(yīng)選擇CS域1.4.2 被叫錨定方案被叫錨定是指對(duì)于被叫VoLTE用戶無論處于LTE還是GSM覆蓋下，均先將呼叫送至其歸屬省的IMS網(wǎng)絡(luò)進(jìn)行處理，此處的錨定即固定送至IMS網(wǎng)絡(luò)的意思。被叫錨定的原因?yàn)闊o論被叫VoLTE用戶處于LTE覆蓋還是GSM覆蓋均可保持補(bǔ)充業(yè)務(wù)（如呼叫等待、呼叫保持、呼叫轉(zhuǎn)移、顯示、多方通話等）的一致性。在VoLTE網(wǎng)絡(luò)中用

21、戶補(bǔ)充業(yè)務(wù)的處理由AS負(fù)責(zé)完成，MSC不掌握VoLTE用戶被叫補(bǔ)充業(yè)務(wù)信息，所以即便被叫用戶處于GSM覆蓋下，仍然要由AS來觸發(fā)和提供補(bǔ)充業(yè)務(wù)，需要將呼叫送至IMS網(wǎng)絡(luò)2 接入優(yōu)化2.1 接入問題分類及現(xiàn)象接入問題主要包括以下四類（從用戶感知角度）：（1）IMS注冊慢/無法注冊開機(jī)后IMS圖標(biāo)不出現(xiàn)或出現(xiàn)較慢，IMS未出現(xiàn)時(shí)VoLTE終端相當(dāng)于CSFB手機(jī)，撥打會(huì)回落到GSM（2）VoLTE終端CSFBVoLTE終端有IMS圖標(biāo)，撥前有4G圖標(biāo)，撥后回落到GSM，圖標(biāo)變成2G，可以撥通，但是接通時(shí)間長（3）呼叫建立時(shí)延長 VoLTE終端有IMS圖標(biāo)，撥時(shí)手機(jī)一直顯示4G，主叫從開始撥開始到聽到

22、振鈴聲時(shí)間較久。（4）未接通VoLTE終端有IMS圖標(biāo)，撥時(shí)手機(jī)一直顯示4G，但是無法撥通。注：IMS圖標(biāo)為IMS或者VoLTE（蘋果無類似標(biāo)志）2.2 接入流程接入流程分為注冊流程和呼叫流程兩部分：（1） VoLTE注冊流程（開機(jī)后即建立，包括LTE注冊、默認(rèn)承載建立、IMS承載建立、IMS注冊過程）（2） VoLTE呼叫流程（每次通話均需建立，通話結(jié)束后釋放）2.2.1 VoLTE注冊流程注：測試軟件和eNB可以看到的流程VoLTE注冊流程（測試軟件和eNB可以看到的流程）12UE發(fā)起EPC附著請求，包含PDN連接請求。 關(guān)注點(diǎn)：ü VoLTE終端Voice Domain Pre

23、ference為IMS PS Voice Preferred，CS Voice Secondary，而LTE終端該字段為PS onlyü VoLTE終端和LTE終端都是聯(lián)合注冊，UE_usage_setting都是Voice centric 35EPC網(wǎng)絡(luò)對(duì)用戶進(jìn)行認(rèn)證鑒權(quán)。611完成默認(rèn)承載建立流程12UE在發(fā)起IMS注冊前需要建立IMS PDN連接。13UE發(fā)起新的PDN連接建立請求，其中攜帶APN為IMS，PCO獲取P-CSCF地址。14-15 MME返回PDN Connectivity accept包含P-SCSF地址列表（地址為IPV6）1619完成IMS PDN連接建立后

24、續(xù)流程20 UE通過IMS PDN默認(rèn)承載發(fā)起IMS 注冊請求，該SIP不加密，但其中包含通過IMSI導(dǎo)出的IMPU/IMPI，P-SCSF臨時(shí)存儲(chǔ)SIP消息中的安全參數(shù)21 注冊請求經(jīng)SBC轉(zhuǎn)發(fā)至S-CSCF，S-SCSF從HSS獲取鑒權(quán)向量（XRES、IK、CK、AUTN、RAND），保留XRES22 S-SCSF發(fā)送401未鑒權(quán)消息到P-SCSF，里邊包含完整性和加密密鑰（IK、CK、AUTN、RAND）23 P-SCSF保留IK和CK，用于UE和S-SCSF間的IPSEC，將AUTN和RAND發(fā)送給終端24終端校驗(yàn)AUTN成功即對(duì)網(wǎng)絡(luò)校驗(yàn)成功，然后計(jì)算XRES，重新發(fā)送的Registe

25、r消息中攜帶XRES25 S-SCSF對(duì)終端重發(fā)Register中的XRES和本地存儲(chǔ)的XRES進(jìn)行匹配，如果匹配成功，向UE返回注冊成功響應(yīng)2.2.2 VoLTE呼叫流程注：測試軟件可以看到的流程VoLTE呼叫流程（測試軟件可以看到的流程）：1 主叫如果在空閑態(tài)，隨機(jī)接入后建立RRC連接，發(fā)送Invite消息，呼叫請求中包含所希望媒體類型和所有編碼方式，precondition相關(guān)參數(shù)，其中主叫側(cè)和被叫側(cè)均為none（注：RACH和RRC連接建立是由Invite消息觸發(fā)的）2 P-SCSF收到后回復(fù)100 trying給主叫，確認(rèn)收到Invite消息，避免主叫Invite重發(fā)3-5同時(shí)主叫側(cè)

26、申請通話資源（臨時(shí)），觸發(fā)網(wǎng)絡(luò)建立專用承載6-7被叫如果在空閑態(tài)，收到尋呼，隨機(jī)接入后建立RRC連接后，收到Invite消息，先回復(fù)100 trying，對(duì)P-SCSF確認(rèn)收到Invite消息，8-12 183 Session Progress消息按照呼叫路徑回復(fù)支持的媒體類型和編碼方式給主叫，同時(shí)被叫側(cè)申請通話資源，觸發(fā)網(wǎng)絡(luò)建立專用承載13-14主叫收到183消息后，發(fā)送PRACK（Provisional ACK）消息，包含雙方協(xié)商的媒體類型和編碼方式，被叫收到后回復(fù)PRACK 200 OK，對(duì)所協(xié)商的媒體類型和編碼方式進(jìn)行確認(rèn)（注：PRACK是請求而非響應(yīng)，是對(duì)臨時(shí)響應(yīng)的確認(rèn)，因此被叫方收

27、到請求后，需要發(fā)200OK確認(rèn)）15-17 主叫側(cè)根據(jù)協(xié)商結(jié)果修改資源申請18主叫UE通過空口流程獲知通話資源預(yù)留成功，向被叫側(cè)發(fā)起UPDATE，其中的precondition參數(shù)主叫側(cè)為sendrecv，被叫側(cè)為none。19 被叫UE通過空口流程獲知通話資源預(yù)留成功，向主叫返回200 OK，其中的precondition參數(shù)主被叫均為sendrecv20-22 被叫振鈴，發(fā)送180 Ringing消息給主叫，觸發(fā)主叫聽到被叫鈴聲，再發(fā)送200 OK，對(duì)最初的INVITE的確認(rèn)23主叫回復(fù)ACK，通話建立，主被叫雙方完成呼叫信令流程，雙方開始通話24主叫側(cè)掛機(jī)，UE向SBC發(fā)送BYE消息，之

28、后消息轉(zhuǎn)發(fā)至被叫SBC和UE。2528主叫側(cè)進(jìn)行資源釋放。2932被叫側(cè)進(jìn)行資源釋放。2.3 接入問題原因分析及排查思路2.3.1 IMS注冊慢/無法注冊2.3.1.1 IMS注冊慢/無法注冊原因分析ü IMS無法注冊有以下原因：A. 終端設(shè)置問題，導(dǎo)致未發(fā)起注冊n HTC手機(jī)“設(shè)置”“數(shù)據(jù)連接”“IMS服務(wù)”未勾選 n 蘋果手機(jī)“設(shè)置”“蜂窩移動(dòng)網(wǎng)絡(luò)”“語音與數(shù)據(jù)”未勾選 n 三星手機(jī)“設(shè)置”“移動(dòng)網(wǎng)絡(luò)”“VoLTE”未勾選B. 終端不支持VoLTE，無法發(fā)起注冊n 終端發(fā)起的Attach Request中Voice Domain Preference不為IMS PS Voice

29、Preferred，CS Voice Secondary，將不支持VoLTEn 終端能力顯示不支持ROHC、FGI字段顯示終端不支持eSRVCC切換、RLC UM模式、5bit RLC UM SN和7bit PDCP SN等功能，終端將不支持VoLTEC. 網(wǎng)絡(luò)不支持VoLTE，不支持IMS注冊網(wǎng)絡(luò)下發(fā)的Attach Accept中IMSVoPS不為IMS VoPS Session in S1 Mode supported，網(wǎng)絡(luò)將不支持VoLTED. IMS簽約數(shù)據(jù)問題，導(dǎo)致無法注冊E. IMS注銷失敗，導(dǎo)致IMS后續(xù)無法注冊HSS未配置2G/3G 的IPV6 APN，導(dǎo)致終端從4G到2G后，

30、RAU accept中刪除了IMS PDP上下文，終端從2G重選到4G后，發(fā)起重新注冊，由于IMS有fork功能，可以允許用戶重復(fù)注冊5次，第6次將無法注冊。HSS上配置2G/3G 的IPV6 APN后問題解決。F. 異廠家對(duì)接，導(dǎo)致注冊消息未發(fā)送到SBC華為DRA按照測試號(hào)段進(jìn)行轉(zhuǎn)發(fā)路由，而異廠家Gx（SBC與PCRF的接口）對(duì)接存在問題，導(dǎo)致USIM卡無法在中興和華為區(qū)域同時(shí)注冊。通過DRA修改配置解決問題。詳見VoLTE USIM卡無法同時(shí)在華為中興區(qū)域使用問題處理ü IMS注冊慢終端版本問題。升級(jí)版本后可以解決，詳見HTC終端注冊慢2.3.1.2 IMS注冊慢/無法注冊問題排

31、查思路A、首先確認(rèn)終端設(shè)置是否正確（參考原因分析）B、通過eNB或EPC上跟蹤信令，確認(rèn)終端和網(wǎng)絡(luò)是否支持VoLTE（參考原因分析）C、核查HSS中2G/3G/4G簽約數(shù)據(jù)，確認(rèn)是否簽約IPV6 APND、確認(rèn)IMS簽約數(shù)據(jù)（將USIM卡裝載在其他可以正常使用的手機(jī)中進(jìn)行測試，確認(rèn)USIM卡簽約是否正常）E、如果上述方法還無法定位問題，在eNB、IMS和EPC、DRA、PCRF等網(wǎng)元跟蹤數(shù)據(jù)包，檢查終端是否已經(jīng)發(fā)出Register消息，消息已經(jīng)路由到已經(jīng)到哪個(gè)網(wǎng)元，終端是否已經(jīng)注冊多次E、最后在終端上抓取信令，確認(rèn)終端問題2.3.2 VoLTE終端CSFB2.3.2.1 VOLTE終端CSFB

32、原因分析A、終端在2/4G或者3/4G同時(shí)有狀態(tài)信息，會(huì)被叫域選擇到GSM。這種情況主要是MME與HSS交互問題；n 華為MME“INTRAFORCE”未設(shè)置為“ULR”，當(dāng)終端從2G 回到4G時(shí)，如果在同一個(gè)融合核心網(wǎng)網(wǎng)元下，TAU過程中不會(huì)發(fā)起Update Location流程，導(dǎo)致HSS同時(shí)存在2/4G狀態(tài)，根據(jù)規(guī)，被叫域選擇到GSM。華為MME修改參數(shù)后解決問題。詳見MME參數(shù)設(shè)置導(dǎo)致VoLTE被叫CSFB問題處理n 華為MME“INTRASINGLEREG”未設(shè)置為“ENABLE”，在用戶重新附著時(shí)，位置更新消息中攜帶的Single-Registration-Info標(biāo)志位未置位，導(dǎo)

33、致中興HSS沒有刪除2G位置信息，被叫因此回落2G。華為MME修改參數(shù)后解決問題。問題處理同上。B、終端收到錯(cuò)誤消息（如500/503）后進(jìn)行異常處理，發(fā)起silent Redial，回落到GSM。這種情況主要為SBC和EPC交互問題。n SBC轉(zhuǎn)發(fā)INVITE消息給被叫RCRF時(shí)，會(huì)觸發(fā)被叫終端鑒權(quán)請求確認(rèn)，SBC發(fā)給PCRF的鑒權(quán)請求消息中攜帶的流描述信息中被叫UE的IP為IPV4，與集團(tuán)規(guī)要求為IPV6不一致，導(dǎo)致被叫域選擇到GSM。中興SBC修改參數(shù)后解決問題。詳見SBC的AAR消息不合規(guī)導(dǎo)致VoLTE被叫CSFBn EPC按照3GPP規(guī)產(chǎn)生的計(jì)費(fèi)標(biāo)識(shí)中包含“0a”的容，在IMS網(wǎng)絡(luò)中

34、，按照SIP協(xié)議將“0a”解析成換行符（ASCII碼中，0a為換行符，非顯性字符），造成對(duì)計(jì)費(fèi)標(biāo)識(shí)的誤讀，導(dǎo)致S-CSCF回復(fù)500（服務(wù)器部錯(cuò)誤）錯(cuò)誤給主叫終端，主叫終端進(jìn)行異常處理，進(jìn)入CSFB流程。中興SBC打補(bǔ)丁后解決問題。詳見SBC回復(fù)500錯(cuò)誤導(dǎo)致終端CSFBn 在4G下的VoLTE用戶做主叫，并向主叫中興SBC發(fā)送初始invite消息后，由于主叫UE未攜帶相關(guān)帶寬參數(shù)，因此中興SBC在向PCRF申請資源時(shí)，未攜帶“Max-Requested-Bandwidth-UL AVP”，導(dǎo)致華為PCRF建立承載失敗，中興SBC在收到華為PCRF錯(cuò)誤響應(yīng)后，向UE回復(fù)503（Service

35、Unavailable），導(dǎo)致部分終端CSFB。中興SBC打補(bǔ)丁后解決問題。2.3.2.2 VoLTE終端CSFB排查思路A、如果終端有4G但無IMS圖標(biāo)，則終端未在IMS注冊B、如果終端有IMS圖標(biāo)，僅做被叫叫時(shí)回落GSM（4G圖標(biāo)變?yōu)?G圖標(biāo)），一般是IMS被叫域選擇到GSM。需要在MME、HSS上進(jìn)行信令跟蹤，確認(rèn)終端是否在多個(gè)域有狀態(tài)C、如果終端有IMS圖標(biāo)，做主叫或被叫都可能回落到GSM（4G圖標(biāo)變?yōu)?G圖標(biāo)），一般是收到錯(cuò)誤消息后進(jìn)行了異常處理。需要在IMS、EPC上進(jìn)行信令跟蹤，確認(rèn)IMS發(fā)送什么類型錯(cuò)誤消息，IMS與EPC進(jìn)行聯(lián)合分析注：VoLTE終端CSFB 2.3.3 呼叫

36、建立時(shí)延長呼叫建立流程涉及較多網(wǎng)元，需要開展端到端分析，呼叫建立時(shí)延長主要為終端、DRA、MME、SGW問題。如果VoLTE終端進(jìn)入CSFB流程，呼叫建立時(shí)延也會(huì)相應(yīng)變長，該問題詳見上節(jié)2.3.2 VoLTE終端CSFB2.3.3.1 呼叫建立時(shí)延統(tǒng)計(jì)方法主叫發(fā)送Invite消息-主叫收到180振鈴消息的時(shí)間2.3.3.2 呼叫建立時(shí)延長原因分析A. 終端n 測試短呼時(shí)，兩次時(shí)間間隔設(shè)置過短，被叫用戶無法完全進(jìn)入IDLE態(tài)，新的呼叫發(fā)起，被叫還處于連接態(tài)轉(zhuǎn)IDLE過程暫態(tài)，收不到尋呼，通過網(wǎng)絡(luò)多次尋呼才能成功，導(dǎo)致整體端到端呼叫延遲達(dá)6-9s。詳見HTC資源釋放過慢導(dǎo)致呼叫建立時(shí)延過長n 終端

37、版本問題，導(dǎo)致發(fā)送多次Invite消息。升級(jí)版本后問題解決。詳見終端側(cè)invite消息丟失導(dǎo)致呼叫建立時(shí)延過長B. DRADRA“關(guān)于鏈路的數(shù)據(jù)捆綁開關(guān)”未打開，如果每條鏈路在50ms收到的消息只有一條，并且消息包長度小于1500字節(jié)時(shí)，將導(dǎo)致每條消息的時(shí)延超過50ms。將“關(guān)于鏈路的捆綁數(shù)據(jù)開關(guān) ”關(guān)閉，DRA與SBC交互時(shí)間降低到10ms。由于交互次數(shù)共24次，可以縮短時(shí)間24*40=960ms。詳見DRA參數(shù)配置不合理導(dǎo)致呼叫建立時(shí)延長C. MMEMME尋呼策略為首次eNB list（最近活動(dòng)的7個(gè)eNB）尋呼，第二到六次為基于GUTI的TA list尋呼（包含一個(gè)TA），尋呼間隔為2.

38、5s。eNB list尋呼成功率低，改為基于TA list尋呼后，呼叫建立時(shí)延大于5s的比例從25%降低到7%。D. SGW中興SGW“報(bào)文緩存開關(guān)”未打開，導(dǎo)致invite消息丟失，必須要等待SBC重傳。打開“報(bào)文緩存開關(guān)”開關(guān)后，可以縮短500ms1s。詳見中興SGW尋呼未緩存導(dǎo)致呼叫建立時(shí)延長2.3.3.3 呼叫建立時(shí)延長問題排查思路A、 eNB、EPC、IMS網(wǎng)元進(jìn)行時(shí)間校準(zhǔn)；B、 將IMS相關(guān)網(wǎng)元（P-SCSF、PCRF、AS、S-SCSF、HSS、DRA）的數(shù)據(jù)包匯聚到一個(gè)CE，抓取該CE中IP數(shù)據(jù)包，同步抓取SGW、MME的數(shù)據(jù)包，獲取各SIP信令在不同的網(wǎng)元的時(shí)間點(diǎn)，從網(wǎng)元和S

39、IP信令兩個(gè)維度進(jìn)行分段統(tǒng)計(jì)，統(tǒng)計(jì)時(shí)長占比較大的網(wǎng)元和SIP信令；C、 針對(duì)疑似問題網(wǎng)元開展相關(guān)SIP信令專項(xiàng)分析及問題定位。2.3.4 未接通2.3.4.1 未接通統(tǒng)計(jì)方法主叫UE發(fā)送第一條SIP INVITE后收到網(wǎng)絡(luò)側(cè)下發(fā)的SIP 200 OK消息為成功完成呼叫，其他都算未接通2.3.4.2 未接通問題分析方法1、在主叫的事件中，找到Outgoing call block/Call blocked事件，記錄時(shí)間點(diǎn)2、在主叫信令中，找到Invite消息（Invite消息會(huì)比RRC連接建立請求消息時(shí)間早，因?yàn)辄c(diǎn)擊撥號(hào)按鈕時(shí)，首先觸發(fā)Invite消息，而Invite消息再觸發(fā)RRC連接建立），

40、記錄時(shí)間點(diǎn)3、查看Invite消息到Block事件之間的時(shí)間段，主被叫出現(xiàn)的異常信令2.3.4.3 未接通原因分析呼叫建立流程涉及終端、eNB、EPC、IMS等網(wǎng)元，所有網(wǎng)元的問題都可能導(dǎo)致未接通。A、終端n HTC M8t某版本尋呼成功率低n HTC M8t某版本主叫終端收到PRACK 200 OK后未上報(bào)UPDATE主叫n 蘋果終端暫不支持振鈴中的eSRVCC，振鈴中或振鈴后，只要是接通前發(fā)起eSRVCC流程都會(huì)導(dǎo)致未接通B、無線n SINR差（由于鄰區(qū)、干擾等導(dǎo)致）被叫無線環(huán)境惡化，SINR降低到-3dB，UE上報(bào)的invite183網(wǎng)絡(luò)側(cè)未收到，最終導(dǎo)致主被叫同時(shí)未接通n 被叫LAU

41、/RAU /TAU主叫14:18:03發(fā)送INVITE消息，14:18:18超時(shí)主動(dòng)上發(fā)Cancel消息。被叫該時(shí)段在進(jìn)行G-T-L重選,包括LAU、RAU、TAU過程。n RRC連接異常釋放終端收到RRC連接釋放，原因?yàn)閛ther，然后進(jìn)入空閑模式C、IMSn SBC收到被叫的UPDATE 200OK后沒有轉(zhuǎn)發(fā)，詳見SBC收到UPDATE的200OK后沒有轉(zhuǎn)發(fā)n 目前所有廠家的IMS不支持振鈴前eSRVCC，振鈴前發(fā)起eSRVCC，都會(huì)導(dǎo)致未接通D、端到端n SIP消息發(fā)送失?。ㄔ跍y試軟件上看到的現(xiàn)象為終端發(fā)送多次SIP消息）被叫手機(jī)在11:48.45.821接收到Invite消息后，分別在

42、11:48.45.930、11:48:48.973、11:48:54.918發(fā)送了3次183消息，但是主叫一直沒有收到183。n SIP消息丟失（在測試軟件上看到的現(xiàn)象為無線環(huán)境良好的情況下，一個(gè)終端已發(fā)送消息，另一方未收到）主叫14:50:11上發(fā)UPDATE消息，被叫一直未收到。此時(shí)無線環(huán)境良好，RSRP值在-93dBm以上，SINR值在17dBm以上。n 被叫尋呼無響應(yīng)，主叫收到480消息主叫手機(jī)起呼后長時(shí)間未能成功建立通話，網(wǎng)絡(luò)側(cè)下發(fā)480Temporarily Unavailable（當(dāng)前不可用）錯(cuò)誤碼，指示用戶無響應(yīng)。n 被叫上報(bào)486 Busy Here被叫在上報(bào)INVITE18

43、0振鈴后，上報(bào)了Invite 486（Busy Here）。n 專用承載未建立或丟失，終端上發(fā)580 Precondition failure被叫專用承載未建立，在發(fā)送UPATE200OK后，被叫發(fā)送580消息給主叫。主叫11:59:43.939發(fā)起呼叫,被叫11:59:48.248發(fā)送PRACK 200 OK給網(wǎng)絡(luò)。被叫11:59:48.967從PCI 448(38100) 切換到 PCI 393(37900), 然后網(wǎng)絡(luò)主動(dòng)去激活專用承載。n 基站核心網(wǎng)加密算法配置不一致 基站配置了祖沖之算法，但核心網(wǎng)未配置，導(dǎo)致未接通。核心網(wǎng)配置祖沖之算法后問題解決，詳見基站核心網(wǎng)加密算法配置不一致導(dǎo)致

44、呼叫失敗n 中興SBC發(fā)送的AAR消息中IP地址格式錯(cuò)誤導(dǎo)致未接通問題處理中興SBC發(fā)送的AAR消息的flow-description部分中的IPV6地址攜帶了“”書寫格式，華為PCRF在轉(zhuǎn)換過程中不識(shí)別解析失敗，導(dǎo)致呼叫失敗。中興SBC打補(bǔ)丁后問題解決，詳見中興SBC發(fā)送的AAR消息中IP地址格式錯(cuò)誤導(dǎo)致未接通問題處理n 中興SBC發(fā)送的STR消息存在異常中興SBC發(fā)送的STR消息未攜帶D-Host信息，華為LDRA轉(zhuǎn)發(fā)不成功導(dǎo)致未接通。SBC發(fā)送的STR攜帶D-Host消息后問題解決，詳見中興SBC發(fā)送的STR消息錯(cuò)誤導(dǎo)致未接通問題處理n 華為LDRA參數(shù)設(shè)置不合理華為LDRA“檢查D-H

45、ost是否為本局開關(guān)”參數(shù)值為“1”，檢測消息中的D-Host為本局的主機(jī)名時(shí)，需要做錯(cuò)誤處理并返回DIAMETER_APPLICATION_UNSUPPORTED錯(cuò)誤碼，導(dǎo)致未接通。修改為“0”后問題解決，詳見華為LDRA參數(shù)配置導(dǎo)致未接通問題處理n 中興SBC發(fā)送的AAR消息存在異常中興SBC發(fā)送的AAR消息攜帶了D-Host信息，DRA會(huì)直接根據(jù)目的主機(jī)名進(jìn)行消息轉(zhuǎn)發(fā)而不再走會(huì)話綁定查詢流程，導(dǎo)致未接通。SBC發(fā)送的AAR消息不攜帶D-Host信息后問題解決，詳見中興SBC發(fā)送的AAR消息錯(cuò)誤導(dǎo)致未接通問題處理2.3.4.4 未接通問題排查思路A、暫時(shí)無法解決的問題n 由于目前所有廠家的

46、IMS不支持振鈴前eSRVCC，振鈴前發(fā)起eSRVCC，肯定會(huì)導(dǎo)致未接通，該問題暫時(shí)無法解決n 蘋果終端暫不支持振鈴中的eSRVCC，振鈴中或振鈴后，只要是接通前發(fā)起eSRVCC流程都會(huì)導(dǎo)致未接通，該問題暫時(shí)無法解決B、無線原因排查：n 主叫/被叫多次發(fā)送信令或者異常進(jìn)入空閑模式，查看當(dāng)時(shí)的SINR和RSRP，確認(rèn)是否由于越區(qū)覆蓋、鄰區(qū)漏配、PCI模3干擾、弱覆蓋等無線問題導(dǎo)致n 主叫尋呼期間，被叫發(fā)起RAU/LAU/TAU，需要分析之前終端如何從4G重選或切換到GSM/TDn RRC連接異常釋放，需要進(jìn)行eNB信令跟蹤，查看無線原因C 、終端問題排查：n 對(duì)比相同芯片的不同終端、異芯片終端，

47、如果某款終端接通成功率低，則疑似終端問題，需要對(duì)終端進(jìn)行排查n 如果終端收到并正確解碼某SIP消息，但未發(fā)出后續(xù)的SIP消息，則疑似終端問題D、端到端原因排查：n 主被叫發(fā)生SIP消息發(fā)送失敗、SIP消息發(fā)送多次問題，則需要在eNB、EPC、IMS上同步抓取數(shù)據(jù)包，檢查消息在哪些網(wǎng)元之間丟失，針對(duì)相關(guān)網(wǎng)元進(jìn)行問題排查n 如果主叫收到480消息（當(dāng)前不可用）、603（絕邀請），一般為被叫未收到尋呼問題，需要在終端、eNB、EPC、PCRF、SBC上跟蹤尋呼消息觸發(fā)及發(fā)送情況n 如果主叫收到486消息（被叫忙），一般為被叫終端發(fā)送，需要跟蹤終端、EPC、HSS上信令，確認(rèn)被叫忙原因n 如果主叫或被

48、叫發(fā)送580消息（資源準(zhǔn)備失?。?，一般為專用承載未建立或承載丟失，需要在EPC、PCRF、SBC上跟蹤信令，排查承載問題2.4 接入問題無線主要優(yōu)化手段A、加強(qiáng)LTE覆蓋優(yōu)化，讓終端盡可能多駐留LTE網(wǎng)絡(luò)，盡量避免由于G-L重選、振鈴前eSRVCC導(dǎo)致的未接通B、加強(qiáng)LTE 模3干擾排查，系統(tǒng)鄰區(qū)等優(yōu)化，避免SINR差導(dǎo)致的未接通C、由于GSM可能存在LAI插花問題，而LTE按照GSM的LAI同步規(guī)劃了TAI，需要排查LAI插花導(dǎo)致的TAI插花問題，避免不必要的TAU導(dǎo)致的未接通D、規(guī)GSM重選LTE參數(shù)，使終端容易從GSM回到LTE，盡量避免G-T-L重選導(dǎo)致的未接通E、與核心網(wǎng)、終端協(xié)同排

49、查尋呼無響應(yīng)、SIP消息丟失、SIP消息發(fā)送失敗問題F、與核心網(wǎng)協(xié)同排查RRC連接異常釋放問題G、聯(lián)系核心網(wǎng)協(xié)同優(yōu)化MME尋呼策略H、定期升級(jí)終端版本2.5 附錄1：VoLTE注冊端到端詳細(xì)流程VoLTE注冊端到端詳細(xì)流程：12UE發(fā)起EPC附著請求。 36EPC網(wǎng)絡(luò)對(duì)用戶進(jìn)行認(rèn)證鑒權(quán)。78 認(rèn)證通過后，MME向HSS進(jìn)行用戶的EPC位置更新，并告知HSS IMS Voice homogeneous support。9MME根據(jù)用戶簽約發(fā)起默認(rèn)PDN連接建立（默認(rèn)APN為CMNET APN）1011SAE GW向PCRF獲取默認(rèn)規(guī)則，PCRF返回QCI=9。1220 完成默認(rèn)承載建立后續(xù)流程。

50、21UE在發(fā)起IMS注冊前需要建立IMS PDN連接。22UE發(fā)起新的PDN連接建立請求，其中攜帶APN為IMS，PCO獲取P-CSCF地址。23MME向SAE GW發(fā)起PDN連接建立請求，其中攜帶APN為IMS，PCO獲取P-CSCF地址。2425 SAE GW向PCRF獲取默認(rèn)規(guī)則，PCRF返回QCI=5.26SAE GW返回PDN連接建立響應(yīng)，其中包含P-CSCF地址2734完成IMS PDN連接建立后續(xù)流程35UE通過IMS PDN默認(rèn)承載發(fā)起IMS 注冊請求，其中包含通過IMSI導(dǎo)出的IMPU/IMPI36注冊請求經(jīng)SBC轉(zhuǎn)發(fā)至I-CSCF3738I-CSCF向HSS發(fā)起查詢，HSS

51、返回S-CSCF的能力集39I-CSCF根據(jù)HSS返回的能力集選擇S-CSCF并向其轉(zhuǎn)發(fā)注冊請求4041S-CSCF向HSS查詢用戶的鑒權(quán)信息4244S-CSCF向UE返回401響應(yīng)，發(fā)起鑒權(quán)挑戰(zhàn)4549UE計(jì)算鑒權(quán)結(jié)果后再次發(fā)起注冊請求5051UE鑒權(quán)通過，S-CSCF向HSS獲取用戶簽約信息5253S-CSCF向AS發(fā)起第三方注冊，并在其中攜帶UE發(fā)起的核心網(wǎng)注冊請求消息5456S-CSCF向UE返回注冊成功響應(yīng)5760AS根據(jù)三方注冊消息中的ATCF management URI向其發(fā)送MESSAGE請求，包含ATU-STI和C-MSISDN6162AS向HSS更新STN-SR6364H

52、SS向MME推送STN-SR2.6 附錄2：VoLTE呼叫端到端詳細(xì)流程（主被叫均在VoLTE）VoLTE呼叫端到端詳細(xì)流程（主被叫均在VoLTE）：1主叫用戶UE(O)的呼叫請求發(fā)送到主叫SBC。呼叫請求中包含precondition相關(guān)參數(shù)，其中主叫側(cè)和被叫側(cè)均為none。2主叫SBC向PCC申請通話資源（臨時(shí)），同時(shí)請求主叫用戶位置信息。 34主叫側(cè)PCRF向S/P-GW下發(fā)策略。5主叫側(cè)PCRF向SBC返回AAA響應(yīng)。68主叫側(cè)預(yù)留無線側(cè)資源，MME在消息8中攜帶主叫位置信息（TAI+E-CGI）。910S/P-GW向PCRF返回主叫位置信息。1112PCRF向SBC上報(bào)主叫位置信息。

53、1316主叫側(cè)完成業(yè)務(wù)觸發(fā)，主叫AS進(jìn)行被叫補(bǔ)齊，之后主叫S-CSCF通過查詢ENUM/DNS獲取被叫I-CSCF地址并將呼叫請求發(fā)送至被叫I-CSCF。1718被叫I-CSCF查詢HSS獲取被叫用戶注冊的S-CSCF。19被叫觸發(fā)至VoLTE AS，基本呼叫和補(bǔ)充業(yè)務(wù)觸發(fā)完成后觸發(fā)SCC AS。20SCC AS進(jìn)行被叫域選擇，向HSS查詢T-ADS信息。23HSS向SCC AS返回T-ADS信息，包含IMS Voice over PS supported。2426呼叫請求轉(zhuǎn)發(fā)至被叫UE。27被叫UE返回183其中包含被叫SDP信息，precondition參數(shù)中主叫側(cè)和被叫側(cè)均為none。2

54、834被叫側(cè)申請通話資源。3542183響應(yīng)按照呼叫路徑被轉(zhuǎn)發(fā)至主叫。4450主叫側(cè)根據(jù)協(xié)商結(jié)果修改資源申請。5159主叫UE通過空口流程獲知通話資源預(yù)留成功，向被叫側(cè)發(fā)起UPDATE，其中的precondition參數(shù)主叫側(cè)為sendrecv，被叫側(cè)為none。6068被叫UE通過空口流程獲知通話資源預(yù)留成功，向主叫返回200 OK，其中的precondition參數(shù)主被叫均為sendrecv。6971主被叫雙方完成呼叫信令流程，雙方開始通話。7274主叫側(cè)掛機(jī)，UE向SBC發(fā)送BYE消息，之后消息轉(zhuǎn)發(fā)至被叫SBC和UE。7581主叫側(cè)進(jìn)行資源釋放。8288被叫側(cè)進(jìn)行資源釋放。3 保持優(yōu)化3

55、.1 保持問題現(xiàn)象及分類保持問題主要包括以下三類（從用戶感知角度）：（1）eSRVCC切換準(zhǔn)備時(shí)延長 eSRVCC切換準(zhǔn)備時(shí)延較長雖然不影響用戶感知，但是可能會(huì)導(dǎo)致掉話（2）eSRVCC用戶面中斷時(shí)延長eSRVCC切換時(shí)，出現(xiàn)短暫的漏字問題（3）掉話VoLTE語音無法保持3.2 eSRVCC切換流程注：測試軟件上可以看到的流程3.3 保持問題原因分析及排查思路3.3.1 eSRVCC切換準(zhǔn)備時(shí)延長3.3.1.1 eSRVCC切換準(zhǔn)備時(shí)延統(tǒng)計(jì)方法終端發(fā)出第一條B2上報(bào)的異系統(tǒng)MR-UE收到mobility form EUTRA的時(shí)長3.3.1.2 eSRVCC切換準(zhǔn)備時(shí)延長原因 中興eMSC私有定時(shí)器設(shè)置異常，導(dǎo)致eMSC與MSC交互時(shí)間占eSRVCC切換準(zhǔn)備時(shí)間的91%，而其中CS 側(cè)局間承載建立時(shí)長（eMSC發(fā)送IAM給MSC-eMSC接收MSC的ACM）占比達(dá)到84%。修改定時(shí)器設(shè)置后，問題得到解決。詳見eSRVCC切換準(zhǔn)備時(shí)延長問題處理3.3.1.3 eSRVCC切換準(zhǔn)備時(shí)延問題排查方法A、 eNB、EPC、IMS、eMSC、MSC、BSC網(wǎng)元進(jìn)行時(shí)間校準(zhǔn)；B、 跟蹤eSRVCC切換準(zhǔn)備信令，獲取各網(wǎng)元的時(shí)間點(diǎn)，從網(wǎng)元和信