【文章內(nèi)容簡(jiǎn)介】 主叫UE發(fā)送第一條SIP INVITE后收到網(wǎng)絡(luò)側(cè)下發(fā)的SIP 200 OK消息為成功完成呼叫，其他都算未接通 未接通問(wèn)題分析方法在主叫的事件中，找到Outgoing call block/Call blocked事件，記錄時(shí)間點(diǎn)在主叫信令中，找到Invite消息（Invite消息會(huì)比RRC連接建立請(qǐng)求消息時(shí)間早，因?yàn)辄c(diǎn)擊撥號(hào)按鈕時(shí)，首先觸發(fā)Invite消息，而Invite消息再觸發(fā)RRC連接建立），記錄時(shí)間點(diǎn)查看Invite消息到Block事件之間的時(shí)間段內(nèi)，主被叫出現(xiàn)的異常信令 未接通原因分析呼叫建立流程涉及終端、eNB、EPC、IMS等網(wǎng)元，所有網(wǎng)元的問(wèn)題都可能導(dǎo)致未接通。A、終端n HTC M8t某版本尋呼成功率低n HTC M8t某版本主叫終端收到PRACK 200 OK后未上報(bào)UPDATE主叫n 蘋果終端暫不支持振鈴中的eSRVCC，振鈴中或振鈴后，只要是接通前發(fā)起eSRVCC流程都會(huì)導(dǎo)致未接通B、無(wú)線n SINR差（由于鄰區(qū)、干擾等導(dǎo)致）被叫無(wú)線環(huán)境惡化，SINR降低到3dB，UE上報(bào)的invite183網(wǎng)絡(luò)側(cè)未收到，最終導(dǎo)致主被叫同時(shí)未接通n 被叫LAU /RAU /TAU主叫14:18:03發(fā)送INVITE消息，14:18:18超時(shí)主動(dòng)上發(fā)Cancel消息。被叫該時(shí)段在進(jìn)行GTL重選,包括LAU、RAU、TAU過(guò)程。n RRC連接異常釋放終端收到RRC連接釋放，原因?yàn)閛ther，然后進(jìn)入空閑模式C、IMSn SBC收到被叫的UPDATE 200OK后沒(méi)有轉(zhuǎn)發(fā)，詳見《SBC收到UPDATE的200OK后沒(méi)有轉(zhuǎn)發(fā)》n 目前所有廠家的IMS不支持振鈴前eSRVCC，振鈴前發(fā)起eSRVCC，都會(huì)導(dǎo)致未接通D、端到端n SIP消息發(fā)送失?。ㄔ跍y(cè)試軟件上看到的現(xiàn)象為終端發(fā)送多次SIP消息）被叫手機(jī)在11:，分別在11:、11:48:、11:48:，但是主叫一直沒(méi)有收到n SIP消息丟失（在測(cè)試軟件上看到的現(xiàn)象為無(wú)線環(huán)境良好的情況下，一個(gè)終端已發(fā)送消息，另一方未收到）主叫14:50:11上發(fā)UPDATE消息，被叫一直未收到。此時(shí)無(wú)線環(huán)境良好，RSRP值在93dBm以上，SINR值在17dBm以上。n 被叫尋呼無(wú)響應(yīng)，主叫收到480消息主叫手機(jī)起呼后長(zhǎng)時(shí)間未能成功建立通話，網(wǎng)絡(luò)側(cè)下發(fā)480Temporarily Unavailable（當(dāng)前不可用）錯(cuò)誤碼，指示用戶無(wú)響應(yīng)。n 被叫上報(bào)486 Busy Here被叫在上報(bào)INVITE180振鈴后，上報(bào)了Invite 486（Busy Here）。n 專用承載未建立或丟失，終端上發(fā)580 Precondition failure被叫專用承載未建立，在發(fā)送UPATE200OK后，被叫發(fā)送580消息給主叫。主叫11:59:,被叫11:59: 200 OK給網(wǎng)絡(luò)。被叫11:59: 448(38100) 切換到 PCI 393(37900), 然后網(wǎng)絡(luò)主動(dòng)去激活專用承載。n 基站核心網(wǎng)加密算法配置不一致 基站配置了祖沖之算法，但核心網(wǎng)未配置，導(dǎo)致未接通。核心網(wǎng)配置祖沖之算法后問(wèn)題解決，詳見《基站核心網(wǎng)加密算法配置不一致導(dǎo)致呼叫失敗》n 中興SBC發(fā)送的AAR消息中IP地址格式錯(cuò)誤導(dǎo)致未接通問(wèn)題處理中興SBC發(fā)送的AAR消息的flowdescription部分中的IPV6地址攜帶了“[]”書寫格式，華為PCRF在轉(zhuǎn)換過(guò)程中不識(shí)別解析失敗，導(dǎo)致呼叫失敗。中興SBC打補(bǔ)丁后問(wèn)題解決，詳見《中興SBC發(fā)送的AAR消息中IP地址格式錯(cuò)誤導(dǎo)致未接通問(wèn)題處理》n 中興SBC發(fā)送的STR消息存在異常中興SBC發(fā)送的STR消息未攜帶DHost信息，華為L(zhǎng)DRA轉(zhuǎn)發(fā)不成功導(dǎo)致未接通。SBC發(fā)送的STR攜帶DHost消息后問(wèn)題解決，詳見《中興SBC發(fā)送的STR消息錯(cuò)誤導(dǎo)致未接通問(wèn)題處理》n 華為L(zhǎng)DRA參數(shù)設(shè)置不合理華為L(zhǎng)DRA“檢查DHost是否為本局開關(guān)”參數(shù)值為“1”，檢測(cè)消息中的DHost為本局的主機(jī)名時(shí)，需要做錯(cuò)誤處理并返回DIAMETER_APPLICATION_UNSUPPORTED錯(cuò)誤碼，導(dǎo)致未接通。修改為“0”后問(wèn)題解決，詳見《華為L(zhǎng)DRA參數(shù)配置導(dǎo)致未接通問(wèn)題處理》n 中興SBC發(fā)送的AAR消息存在異常中興SBC發(fā)送的AAR消息攜帶了DHost信息，DRA會(huì)直接根據(jù)目的主機(jī)名進(jìn)行消息轉(zhuǎn)發(fā)而不再走會(huì)話綁定查詢流程，導(dǎo)致未接通。SBC發(fā)送的AAR消息不攜帶DHost信息后問(wèn)題解決，詳見《中興SBC發(fā)送的AAR消息錯(cuò)誤導(dǎo)致未接通問(wèn)題處理》 未接通問(wèn)題排查思路A、暫時(shí)無(wú)法解決的問(wèn)題n 由于目前所有廠家的IMS不支持振鈴前eSRVCC，振鈴前發(fā)起eSRVCC，肯定會(huì)導(dǎo)致未接通，該問(wèn)題暫時(shí)無(wú)法解決n 蘋果終端暫不支持振鈴中的eSRVCC，振鈴中或振鈴后，只要是接通前發(fā)起eSRVCC流程都會(huì)導(dǎo)致未接通，該問(wèn)題暫時(shí)無(wú)法解決B、無(wú)線原因排查：n 主叫/被叫多次發(fā)送信令或者異常進(jìn)入空閑模式，查看當(dāng)時(shí)的SINR和RSRP，確認(rèn)是否由于越區(qū)覆蓋、鄰區(qū)漏配、PCI模3干擾、弱覆蓋等無(wú)線問(wèn)題導(dǎo)致n 主叫尋呼期間，被叫發(fā)起RAU/LAU/TAU，需要分析之前終端如何從4G重選或切換到GSM/TDn RRC連接異常釋放，需要進(jìn)行eNB信令跟蹤，查看無(wú)線原因C 、終端問(wèn)題排查：n 對(duì)比相同芯片的不同終端、異芯片終端，如果某款終端接通成功率低，則疑似終端問(wèn)題，需要對(duì)終端進(jìn)行排查n 如果終端收到并正確解碼某SIP消息，但未發(fā)出后續(xù)的SIP消息，則疑似終端問(wèn)題D、端到端原因排查：n 主被叫發(fā)生SIP消息發(fā)送失敗、SIP消息發(fā)送多次問(wèn)題，則需要在eNB、EPC、IMS上同步抓取數(shù)據(jù)包，檢查消息在哪些網(wǎng)元之間丟失，針對(duì)相關(guān)網(wǎng)元進(jìn)行問(wèn)題排查n 如果主叫收到480消息（當(dāng)前不可用）、603（謝絕邀請(qǐng)），一般為被叫未收到尋呼問(wèn)題，需要在終端、eNB、EPC、PCRF、SBC上跟蹤尋呼消息觸發(fā)及發(fā)送情況n 如果主叫收到486消息（被叫忙），一般為被叫終端發(fā)送，需要跟蹤終端、EPC、HSS上信令，確認(rèn)被叫忙原因n 如果主叫或被叫發(fā)送580消息（資源準(zhǔn)備失?。?，一般為專用承載未建立或承載丟失，需要在EPC、PCRF、SBC上跟蹤信令，排查承載問(wèn)題 接入問(wèn)題無(wú)線主要優(yōu)化手段A、加強(qiáng)LTE覆蓋優(yōu)化，讓終端盡可能多駐留LTE網(wǎng)絡(luò)，盡量避免由于GL重選、振鈴前eSRVCC導(dǎo)致的未接通B、加強(qiáng)LTE 模3干擾排查，系統(tǒng)內(nèi)鄰區(qū)等優(yōu)化，避免SINR差導(dǎo)致的未接通C、由于GSM可能存在LAI插花問(wèn)題，而LTE按照GSM的LAI同步規(guī)劃了TAI，需要排查L(zhǎng)AI插花導(dǎo)致的TAI插花問(wèn)題，避免不必要的TAU導(dǎo)致的未接通D、規(guī)范GSM重選LTE參數(shù)，使終端容易從GSM回到LTE，盡量避免GTL重選導(dǎo)致的未接通E、與核心網(wǎng)、終端協(xié)同排查尋呼無(wú)響應(yīng)、SIP消息丟失、SIP消息發(fā)送失敗問(wèn)題F、與核心網(wǎng)協(xié)同排查RRC連接異常釋放問(wèn)題G、聯(lián)系核心網(wǎng)協(xié)同優(yōu)化MME尋呼策略H、定期升級(jí)終端版本 附錄1：VoLTE注冊(cè)端到端詳細(xì)流程VoLTE注冊(cè)端到端詳細(xì)流程：1~2 UE發(fā)起EPC附著請(qǐng)求。 3~6 EPC網(wǎng)絡(luò)對(duì)用戶進(jìn)行認(rèn)證鑒權(quán)。7~8 認(rèn)證通過(guò)后，MME向HSS進(jìn)行用戶的EPC位置更新，并告知HSS IMS Voice homogeneous support。9 MME根據(jù)用戶簽約發(fā)起默認(rèn)PDN連接建立（默認(rèn)APN為CMNET APN）10~11 SAE GW向PCRF獲取默認(rèn)規(guī)則，PCRF返回QCI=9。12~20 完成默認(rèn)承載建立后續(xù)流程。21 UE在發(fā)起IMS注冊(cè)前需要建立IMS PDN連接。22 UE發(fā)起新的PDN連接建立請(qǐng)求，其中攜帶APN為IMS，PCO獲取PCSCF地址。23 MME向SAE GW發(fā)起PDN連接建立請(qǐng)求，其中攜帶APN為IMS，PCO獲取PCSCF地址。24~25 SAE GW向PCRF獲取默認(rèn)規(guī)則，PCRF返回QCI=5.26 SAE GW返回PDN連接建立響應(yīng)，其中包含PCSCF地址27~34 完成IMS PDN連接建立后續(xù)流程35 UE通過(guò)IMS PDN默認(rèn)承載發(fā)起IMS 注冊(cè)請(qǐng)求，其中包含通過(guò)IMSI導(dǎo)出的IMPU/IMPI36 注冊(cè)請(qǐng)求經(jīng)SBC轉(zhuǎn)發(fā)至ICSCF37~38 ICSCF向HSS發(fā)起查詢，HSS返回SCSCF的能力集39 ICSCF根據(jù)HSS返回的能力集選擇SCSCF并向其轉(zhuǎn)發(fā)注冊(cè)請(qǐng)求40~41 SCSCF向HSS查詢用戶的鑒權(quán)信息42~44 SCSCF向UE返回401響應(yīng)，發(fā)起鑒權(quán)挑戰(zhàn)45~49 UE計(jì)算鑒權(quán)結(jié)果后再次發(fā)起注冊(cè)請(qǐng)求50~51 UE鑒權(quán)通過(guò)，SCSCF向HSS獲取用戶簽約信息52~53 SCSCF向AS發(fā)起第三方注冊(cè)，并在其中攜帶UE發(fā)起的核心網(wǎng)注冊(cè)請(qǐng)求消息54~56 SCSCF向UE返回注冊(cè)成功響應(yīng)57~60 AS根據(jù)三方注冊(cè)消息中的ATCF management URI向其發(fā)送MESSAGE請(qǐng)求，包含ATUSTI和CMSISDN61~62 AS向HSS更新STNSR63~64 HSS向MME推送STNSR 附錄2：VoLTE呼叫端到端詳細(xì)流程（主被叫均在VoLTE）VoLTE呼叫端到端詳細(xì)流程（主被叫均在VoLTE）：1 主叫用戶UE(O)的呼叫請(qǐng)求發(fā)送到主叫SBC。呼叫請(qǐng)求中包含precondition相關(guān)參數(shù)，其中主叫側(cè)和被叫側(cè)均為none。2 主叫SBC向PCC申請(qǐng)通話資源（臨時(shí)），同時(shí)請(qǐng)求主叫用戶位置信息。 3~4 主叫側(cè)PCRF向S/PGW下發(fā)策略。5 主叫側(cè)PCRF向SBC返回AAA響應(yīng)。6~8 主叫側(cè)預(yù)留無(wú)線側(cè)資源，MME在消息8中攜帶主叫位置信息（TAI+ECGI）。9~10 S/PGW向PCRF返回主叫位置信息。11~12 PCRF向SBC上報(bào)主叫位置信息。13~16 主叫側(cè)完成業(yè)務(wù)觸發(fā)，主叫AS進(jìn)行被叫號(hào)碼補(bǔ)齊，之后主叫SCSCF通過(guò)查詢ENUM/DNS獲取被叫ICSCF地址并將呼叫請(qǐng)求發(fā)送至被叫ICSCF。17~18 被叫ICSCF查詢HSS獲取被叫用戶注冊(cè)的SCSCF。19 被叫觸發(fā)至VoLTE AS，基本呼叫和補(bǔ)充業(yè)務(wù)觸發(fā)完成后觸發(fā)SCC AS。20 SCC AS進(jìn)行被叫域選擇，向HSS查詢TADS信息。23 HSS向SCC AS返回TADS信息，包含IMS Voice over PS supported。24~26 呼叫請(qǐng)求轉(zhuǎn)發(fā)至被叫UE。27 被叫UE返回183其中包含被叫SDP信息，precondition參數(shù)中主叫側(cè)和被叫側(cè)均為none。28~34 被叫側(cè)申請(qǐng)通話資源。35~42 183響應(yīng)按照呼叫路徑被轉(zhuǎn)發(fā)至主叫。44~50 主叫側(cè)根據(jù)協(xié)商結(jié)果修改資源申請(qǐng)。51~59 主叫UE通過(guò)空口流程獲知通話資源預(yù)留成功，向被叫側(cè)發(fā)起UPDATE，其中的precondition參數(shù)主叫側(cè)為sendrecv，被叫側(cè)為none。60~68 被叫UE通過(guò)空口流程獲知通話資源預(yù)留成功，向主叫返回200 OK，其中的precondition參數(shù)主被叫均為sendrecv。69~71 主被叫雙方完成呼叫信令流程，雙方開始通話。72~74 主叫側(cè)掛機(jī)，UE向SBC發(fā)送BYE消息，之后消息轉(zhuǎn)發(fā)至被叫SBC和UE。75~81 主叫側(cè)進(jìn)行資源釋放。82~88 被叫側(cè)進(jìn)行資源釋放。3 保持優(yōu)化 保持問(wèn)題現(xiàn)象及分類保持問(wèn)題主要包括以下三類（從用戶感知角度）：（1）eSRVCC切換準(zhǔn)備時(shí)延長(zhǎng) eSRVCC切換準(zhǔn)備時(shí)延較長(zhǎng)雖然不影響用戶感知，但是可能會(huì)導(dǎo)致掉話（2）eSRVCC用戶面中斷時(shí)延長(zhǎng)eSRVCC切換時(shí)，出現(xiàn)短暫的漏字問(wèn)題（3）掉話VoLTE語(yǔ)音無(wú)法保持 eSRVCC切換流程注：測(cè)試軟件上可以看到的流程 保持問(wèn)題原因分析及排查思路 eSRVCC切換準(zhǔn)備時(shí)延長(zhǎng) eSRVCC切換準(zhǔn)備時(shí)延統(tǒng)計(jì)方法終端發(fā)出第一條B2上報(bào)的異系統(tǒng)MRUE收到mobility form EUTRA的時(shí)長(zhǎng) eSRVCC切換準(zhǔn)備時(shí)延長(zhǎng)原因 中興eMSC私有定時(shí)器設(shè)置異常，導(dǎo)致eMSC與MSC交互時(shí)間占eSRVCC切換準(zhǔn)備時(shí)間的91%，而其中CS 側(cè)局間承載建立時(shí)長(zhǎng)（eMSC發(fā)送IAM給MSCeMSC接收MSC的ACM）占比達(dá)到84%。修改定時(shí)器設(shè)置后，問(wèn)題得到解決。詳見《eSRVCC切換準(zhǔn)備時(shí)延長(zhǎng)問(wèn)題處理》 eSRVCC切換準(zhǔn)備時(shí)延問(wèn)題排查方法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)元和信令兩個(gè)維度進(jìn)行分段統(tǒng)計(jì)，統(tǒng)計(jì)時(shí)長(zhǎng)占比較大的網(wǎng)元和信令；C、 針對(duì)疑似問(wèn)題網(wǎng)元開展專項(xiàng)分析及問(wèn)題定位。 eSRVCC用戶面中斷時(shí)延長(zhǎng) eSRVCC用戶面中斷時(shí)延統(tǒng)計(jì)方法終端在IMS收到最后一個(gè)上/下行RTP包終端在GSM收到第一個(gè)上/下行語(yǔ)音包 eSRVCC用戶中斷時(shí)延長(zhǎng)原因eSRVCC用戶面終端時(shí)延長(zhǎng)主要是終端及芯片原因：A、HTC終端測(cè)試發(fā)現(xiàn)HTC終端eSRVCC用戶面中斷時(shí)延達(dá)到1700ms，遠(yuǎn)高于協(xié)議規(guī)定的300ms。對(duì)比同為高通芯片的SONY終端，時(shí)延僅為380ms，判斷為HTC終端原因。HTC終端升級(jí)后問(wèn)題解決。詳見《HTC終端eSRVCC用戶面中斷時(shí)延長(zhǎng)問(wèn)題處理》B、高通芯片測(cè)試發(fā)現(xiàn)海思芯片的華為Mate7用戶面中斷時(shí)延僅為265ms，分析發(fā)現(xiàn)高通與海思芯片終端在業(yè)務(wù)面恢復(fù)時(shí)間上存在差異，eSRVCC到2G后，語(yǔ)音包編碼器模式要做轉(zhuǎn)換，高通芯片收到4個(gè)語(yǔ)音包之后才開始語(yǔ)音包譯碼，所以用戶面中斷時(shí)間比海思多出4*20=80ms。高通芯片正在進(jìn)行補(bǔ)丁開發(fā) eSRVCC用戶中斷時(shí)延問(wèn)題排查方法A、