【文章內(nèi)容簡(jiǎn)介】 查可能的問(wèn)題原因。常規(guī)的4G尋呼問(wèn)題分析流程如下所示 各環(huán)節(jié)分析要點(diǎn)（1）確認(rèn)核心網(wǎng)尋呼是否下發(fā)現(xiàn)象：216。 主叫側(cè)聽(tīng)到“用戶正在通話中”或“用戶已關(guān)機(jī)”的錄音通知分析要點(diǎn)：216。 從主叫側(cè)CALL Proceeding時(shí)間，推算被叫側(cè)尋呼下發(fā)時(shí)間。，一共發(fā)3次，因此從開(kāi)始尋呼到尋呼失敗約有10秒的周期，分析尋呼失敗原因時(shí)需要重點(diǎn)分析這10秒期間終端的狀態(tài)。216。 從被叫MME的SGs口和S1口確認(rèn)是否有Paging Request。如果沒(méi)有發(fā)現(xiàn)尋呼消息，或在尋呼超時(shí)前，尋呼消息下發(fā)小于3次，則進(jìn)一步檢查以下兩項(xiàng)n 檢查被叫側(cè)當(dāng)時(shí)是否正在發(fā)起數(shù)據(jù)業(yè)務(wù)請(qǐng)求（service request）、正在進(jìn)行TAU或3/4互操作。目前諾西MSC的并發(fā)處理機(jī)制不完善，當(dāng)尋呼與用戶主叫業(yè)務(wù)或TAU并發(fā)時(shí)，將直接停止尋呼，并給主叫側(cè)播放“用戶通話中”的錄音通知。n 檢查eNodeB是否存在S1口閃斷告警或RRU偶斷連告警，會(huì)影響空口尋呼消息的下發(fā)。（2）確認(rèn)尋呼消息下發(fā)的TAC是否正確現(xiàn)象：216。 用戶所處地點(diǎn)無(wú)線環(huán)境良好，移動(dòng)性低，平時(shí)CSFB尋呼成功率也較高，但偶爾出現(xiàn)“您撥打暫時(shí)無(wú)法接通”的情況分析要點(diǎn)：216。 核查用戶是否處于TAC/LAC邊界、3/4G覆蓋邊緣，以及TAU頻次是否過(guò)高，如果尋呼下發(fā)時(shí)用戶正重選到新TAC還未發(fā)起TAU則網(wǎng)絡(luò)側(cè)會(huì)將尋呼發(fā)往舊TAC/LAC。216。 檢查用戶上一次CSFB通話后是否及時(shí)返回4G進(jìn)行了TAU，如果用戶未能返回4G，且在2G側(cè)未及時(shí)LAU，則MSC仍然將用戶關(guān)聯(lián)在4G網(wǎng)絡(luò)上，會(huì)造成后續(xù)尋呼由于核心網(wǎng)不清楚用戶已返回2G，還會(huì)將尋呼發(fā)往4G側(cè)。216。 此類問(wèn)題可通過(guò)CSFB平臺(tái)的SGs口詳單進(jìn)行確認(rèn)，篩選SGs口詳單上CDR TYPE=1（即SGsAPPAGING）和CDR TYPE=5（即SGsAPLOCATIONUPDATE）的詳單，并根據(jù)詳單上尋呼下發(fā)的TAC和TAU后的NEW LAI判斷尋呼是否下發(fā)正確。其中LAI需先轉(zhuǎn)為16進(jìn)制，取最后四位就是TAC。（3）尋呼消息解碼失敗現(xiàn)象：216。 用戶所處環(huán)境長(zhǎng)期尋呼成功率低，主叫側(cè)聽(tīng)到“暫時(shí)無(wú)法接通”的錄音通知216。 現(xiàn)場(chǎng)明顯弱覆蓋RSRP115dbm，或SINR0分析要點(diǎn)：216。 從終端底層LOG可看到PDCCH上收到PRNTI DCI但PDSCH解碼失敗，主要原因在于終端在空閑態(tài)只能根據(jù)6個(gè)RE來(lái)進(jìn)行信道估計(jì)，因此SINR低于3時(shí)，尋呼消息解碼高概率失敗。216。 通常弱覆蓋和低SINR地點(diǎn)均位于室內(nèi)，測(cè)試人員難以直接發(fā)現(xiàn)問(wèn)題地點(diǎn)，可根據(jù)路測(cè)LOG和經(jīng)驗(yàn)值判斷是否存在室內(nèi)低SINR隱患。SINR與RSRP基本是線性相關(guān)的，即RSRP減少1dbm，SINR降低1db，因此，若路測(cè)中發(fā)現(xiàn)RSRP=100dbm時(shí)，SINR10，或RSRP=90時(shí)，SINR20，則可推算用戶位于室內(nèi)110dbm以下的環(huán)境時(shí)，一定會(huì)出現(xiàn)SINR0的問(wèn)題216。 造成低SINR的主要原因是4G重疊覆蓋度高，當(dāng)4G重疊覆蓋度超過(guò)5時(shí)，SINR將小于5，因此覆蓋調(diào)整是解決低SINR的根本方法。目前新開(kāi)站機(jī)械下傾角普遍較小，建議站間距小于500米且地形開(kāi)闊的地區(qū)，站高超過(guò)35米的站點(diǎn)總下傾（機(jī)械+內(nèi)置）不小于12度，如遇天線美化罩或下傾已調(diào)至最大的情況，需工程改造拆除美化罩、更換大傾角天線支架或下降天線高度。（4）核心網(wǎng)用戶狀態(tài)變更不及時(shí)現(xiàn)象：216。 用戶處于連接態(tài)時(shí)，正常情況下CSFB的尋呼消息應(yīng)以Service Notification信令從專用信道下發(fā)，此時(shí)終端對(duì)于從共用信道下發(fā)的Paging不響應(yīng)。分析要點(diǎn)：216。 檢查尋呼消息是否與終端發(fā)起數(shù)據(jù)業(yè)務(wù)和釋放信道同時(shí)發(fā)生，諾西MME采用并發(fā)機(jī)制處理用戶的連接狀態(tài)變更請(qǐng)求和尋呼消息，因此導(dǎo)致將Paging信息發(fā)給連接態(tài)用戶的BUG。216。 此類問(wèn)題可通過(guò)增加不活動(dòng)計(jì)時(shí)器時(shí)長(zhǎng)，降低數(shù)據(jù)業(yè)務(wù)發(fā)起和釋放頻次進(jìn)行緩解。但修改不活動(dòng)計(jì)時(shí)器會(huì)引起掉線率的惡化。（5）檢查TMSI是否有效現(xiàn)象：216。 用戶已收到paging消息，其中攜帶的TMSI與用戶一致，但終端不發(fā)起Extend Service Request。216。 TMSI失效會(huì)導(dǎo)致用戶連續(xù)多次尋呼失敗，直至下一次正常的TAU后恢復(fù)正常。分析要點(diǎn)：216。 在2G弱覆蓋或干擾的情況下，如果終端在2G進(jìn)行LAU時(shí)發(fā)生失敗，終端會(huì)認(rèn)為TMSI已失效，當(dāng)用戶返回4G后進(jìn)行TAU的TAU Request信令中會(huì)攜帶“TMSI not available ”屬性，要求MSC重新分配TMSI。但由于諾西MSC存在位置更新信令流程粘連的BUG，可能不響應(yīng)這次聯(lián)合TAU的TMSI分配請(qǐng)求，導(dǎo)致TAU ACCEPT信令中未包含TMSI值。而終端因?yàn)闆](méi)有可用TMSI所以不響應(yīng)尋呼消息。216。 此類問(wèn)題易出現(xiàn)在2G高干擾地區(qū)，在用戶前一次CSFB通話回落失敗時(shí)，終端會(huì)自動(dòng)在2G發(fā)起原因?yàn)镮MSI ATTACH的LAU，但由于高干擾會(huì)繼續(xù)導(dǎo)致LAU失敗，從而引發(fā)TMSI失效。（6）ESR發(fā)送失敗現(xiàn)象：216。 用戶在4G側(cè)RRC接入失敗，導(dǎo)致Extend Service Request消息無(wú)法發(fā)出分析要點(diǎn)：216。 檢查eNodeB是否存在硬件故障216。 4G側(cè)參數(shù)核查，重點(diǎn)檢查時(shí)隙、子幀、功率類參數(shù)設(shè)置216。 根據(jù)網(wǎng)管RRC失敗原因的分類統(tǒng)計(jì)，確認(rèn)RRC接入性差的原因 第二步：4G釋放分析 分析流程4G釋放階段是從終端上發(fā)Extend Service Request開(kāi)始，到網(wǎng)絡(luò)下發(fā)RR Connection Release結(jié)束，主要影響因素在于4G側(cè)eNodeb參數(shù)設(shè)置和設(shè)備故障，但也存在由于4G規(guī)范對(duì)并發(fā)流程考慮不足導(dǎo)致的并發(fā)流程沖突問(wèn)題。其常規(guī)分析流程如下 各環(huán)節(jié)分析要點(diǎn)（1）未收到RR Connection Release信令現(xiàn)象：216。 終端上發(fā)Extend Service Request信令后，在上下文建立階段、釋放請(qǐng)求階段出現(xiàn)異常，導(dǎo)致終端未能收到RR Connection Release信令，無(wú)法進(jìn)行回落。問(wèn)題分析：216。 此類問(wèn)題主要與S1口的eNodeb和MME設(shè)備相關(guān)，4G網(wǎng)管統(tǒng)計(jì)能夠提供CSFB上下文建立成功率和CSFB釋放準(zhǔn)備成功率的指標(biāo)，%左右，如發(fā)現(xiàn)有小區(qū)該指標(biāo)低于99%，則需要進(jìn)行硬件故障和參數(shù)核查。（2）4G并發(fā)流程沖突現(xiàn)象：216。 終端收到RR Connection Release信令中未攜帶CSFB頻點(diǎn)信息。問(wèn)題分析：216。 檢查終端發(fā)出Extend Service Request信令后，是否發(fā)生了切換。由于4G協(xié)議中未明確定義切換后MME要將CSFB請(qǐng)求轉(zhuǎn)至新eNodeB，所以導(dǎo)致新小區(qū)由于不知道用戶要進(jìn)行CSFB業(yè)務(wù)，從而在釋放信令中不攜帶CSFB頻點(diǎn)。216。 檢查終端發(fā)出Extend Service Request信令前，是否正在進(jìn)行TAU。4G協(xié)議并為明確定義TAU與CSFB業(yè)務(wù)沖突時(shí)的處理機(jī)制，因此當(dāng)TAU與CSFB并發(fā)時(shí)，網(wǎng)絡(luò)側(cè)下發(fā)的TAU流程的RR Connection Release會(huì)被終端認(rèn)為是CSFB的RR Connection Release。（3）CSFB開(kāi)關(guān)或頻點(diǎn)設(shè)置錯(cuò)誤現(xiàn)象：216。 終端上發(fā)Extend Service Request信令后，沒(méi)有收到RR Connection Release信令。問(wèn)題分析：216。 檢查eNodeB的CSFB開(kāi)關(guān)、網(wǎng)絡(luò)優(yōu)先級(jí)、頻點(diǎn)組序號(hào)參數(shù)為空或?yàn)? 第三步：2G接入分析 分析流程相比普通的2G呼叫，CSFB業(yè)務(wù)流程的差異主要發(fā)生在UE從4G側(cè)回落2G過(guò)程中的駐留小區(qū)選擇過(guò)程，大部分問(wèn)題也都發(fā)生在這個(gè)過(guò)程中，一旦選擇好合適的2G小區(qū)進(jìn)行接入，后續(xù)的過(guò)程與普通2G呼叫是一致的。4G小區(qū)占用的合理的情況下，UE回落2G過(guò)程中可能存在的問(wèn)題如以下流程所示： 各環(huán)節(jié)分析要點(diǎn)（1）駐留2G小區(qū)失敗現(xiàn)象：4G的RRC Connection Release消息中包括2G頻點(diǎn)組，但UE駐留2G失敗返回4G，或者在TD發(fā)起呼叫 分析要點(diǎn)：216。 4G小區(qū)配置的2G頻點(diǎn)組是否合理，有無(wú)缺少應(yīng)有頻點(diǎn)的問(wèn)題216。 2G側(cè)覆蓋是否存在問(wèn)題，如弱覆蓋或者下行C/I較差216。 2G側(cè)C1參數(shù)設(shè)置是否合理 （2）LAU失敗 現(xiàn)象：216。 占用不合理的小區(qū)，如與UE距離遠(yuǎn)、場(chǎng)強(qiáng)非最好216。 成功占用SD發(fā)起LAU，但SD掉話未能完成LAU過(guò)程216。 發(fā)起接入請(qǐng)求后SD占用失敗，有下行系統(tǒng)消息5ter，但是沒(méi)有上行的MR發(fā)送216。 發(fā)起接入請(qǐng)求后，系統(tǒng)沒(méi)有響應(yīng)，未能占用SD信道216。 鑒權(quán)請(qǐng)求不下發(fā)，核心網(wǎng)計(jì)時(shí)器超時(shí)后結(jié)束LAU過(guò)程216。 鑒權(quán)請(qǐng)求延時(shí)很長(zhǎng)時(shí)間下發(fā)，由于SD信道沒(méi)有開(kāi)啟切換，導(dǎo)致SD掉話分析要點(diǎn)：216。 占用的小區(qū)的頻率是否在RRC Connection Release消息中；更好的小區(qū)的頻點(diǎn)是否在RRC Connectio