KPI問(wèn)題分析案例總結(jié)1.1.1S1告警引起的s1切換成功率問(wèn)題概述：在處理KPI時(shí)發(fā)現(xiàn)存在MME內(nèi)S1接口切換成功率低的問(wèn)題，從性能告警上來(lái)看經(jīng)常白天該指標(biāo)降到80%以下，通過(guò)分析主要是部分基站出現(xiàn)S1告警導(dǎo)致的。1.1.2問(wèn)題分析通過(guò)對(duì)NBYY富巷北FHTL-1小區(qū)1月5日的KPI和告警分析如下：小區(qū)可用率從16點(diǎn)開(kāi)始-16點(diǎn)45分下降到0%；從16點(diǎn)45分-17點(diǎn)15分逐步恢復(fù)100%；告警分析：MME告警開(kāi)始時(shí)間告警信息告警結(jié)束時(shí)間MRBTS-402334/LNBTS-40233405.01.201609:44:06FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201609:49:07MRBTS-40233405.01.201616:10:48ConnectionlostforIP=100.67.50.6105.01.201616:53:21MRBTS-402334/LNBTS-40233405.01.201616:10:16FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201616:54:06MRBTS-402334/LNBTS-40233405.01.201616:10:25FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201616:54:06MRBTS-402334/LNBTS-402334/LNMME-005.01.201616:14:18TransportlayerconnectionfailureinS1interface05.01.201616:54:06MRBTS-402334/LNBTS-402334/LNMME-105.01.201616:11:52TransportlayerconnectionfailureinS1interface05.01.201616:54:06MRBTS-402334/LNBTS-402334/LNMME-505.01.201616:11:52TransportlayerconnectionfailureinS1interface05.01.201616:54:06MRBTS-402334/LNBTS-402334/LNMME-305.01.201616:11:55TransportlayerconnectionfailureinS1interface05.01.201616:54:09MRBTS-402334/LNBTS-402334/LNMME-405.01.201616:11:55TransportlayerconnectionfailureinS1interface05.01.201616:54:09MRBTS-402334/LNBTS-402334/LNMME-205.01.201616:11:57TransportlayerconnectionfailureinS1interface05.01.201616:54:12MRBTS-402334/LNBTS-402334/LNMME-605.01.201616:14:17TransportlayerconnectionfailureinS1interface05.01.201616:54:30MRBTS-402334/LNBTS-402334/LNMME-005.01.201616:54:05TransportlayerconnectionfailureinS1interface05.01.201616:54:31MRBTS-402334/LNBTS-402334/LNADJ-1905.01.201623:21:22TransportlayerconnectionfailureinX2interface05.01.201623:25:02MRBTS-402334/LNBTS-402334/LNADJ-3305.01.201623:21:30TransportlayerconnectionfailureinX2interface05.01.201623:25:12MRBTS-402334/LNBTS-402334/LNADJ-3605.01.201623:46:13TransportlayerconnectionfailureinX2interface05.01.201623:49:42MRBTS-402334/LNBTS-402334/LNADJ-005.01.201623:46:13TransportlayerconnectionfailureinX2interface05.01.201623:50:01MRBTS-402334/LNBTS-402334/LNADJ-1205.01.201623:46:13TransportlayerconnectionfailureinX2interface05.01.201623:50:06從告警的時(shí)間來(lái)看在05.01.201616:10:48-05.01.201616:53:21，出現(xiàn)ConnectionlostforIP=100.67.50.61告警和小區(qū)可用率出現(xiàn)問(wèn)題的時(shí)間對(duì)應(yīng)；告警在16:53:21時(shí)結(jié)束，同時(shí)小區(qū)可用率在17點(diǎn)的時(shí)候恢復(fù)。問(wèn)題1:斷站的告警在05.01.201616:10:48-05.01.201616:53:21期間站點(diǎn)處于斷站的狀態(tài)，為什么在05.01.201616:10:48-之后還會(huì)收到每條MME上報(bào)的S1告警。問(wèn)題2:在16點(diǎn)15分-16點(diǎn)30分時(shí)，站點(diǎn)已經(jīng)斷站問(wèn)什么還有出現(xiàn)S1的切入準(zhǔn)備失敗INHO_INTER_HO_PREP_FAIL_OTH31755多次，而在下一個(gè)15分鐘粒度INHO_INTER_HO_PREP_FAIL_OTH0次通過(guò)對(duì)NBYY富巷北DHTL-1小區(qū)1月5日的KPI和告警分析如下：NBYY富巷北DHTL-1小區(qū)也是和NBYY富巷北FHTL-1小區(qū)同樣的問(wèn)題小區(qū)可用率從16點(diǎn)開(kāi)始-16點(diǎn)45分下降到0%；從16點(diǎn)45分-17點(diǎn)15分逐步恢復(fù)100%；告警分析：MME告警開(kāi)始時(shí)間告警信息告警結(jié)束時(shí)間MRBTS-738277/LNBTS-73827705.01.201609:44:05FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201609:44:15MRBTS-738277/LNBTS-73827705.01.201609:44:07FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201609:48:37MRBTS-73827705.01.201616:10:32ConnectionlostforIP=100.67.48.9505.01.201616:52:22MRBTS-738277/LNBTS-738277/LNMME-605.01.201616:11:55TransportlayerconnectionfailureinS1interface05.01.201616:52:35MRBTS-738277/LNBTS-73827705.01.201616:10:16FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201616:52:36MRBTS-738277/LNBTS-738277/LNMME-305.01.201616:11:52TransportlayerconnectionfailureinS1interface05.01.201616:52:36MRBTS-738277/LNBTS-738277/LNMME-505.01.201616:11:52TransportlayerconnectionfailureinS1interface05.01.201616:52:36MRBTS-738277/LNBTS-73827705.01.201616:10:26FailureinconnectionbetweenBTSandiOMSor3rdpartytool05.01.201616:52:37MRBTS-738277/LNBTS-738277/LNADJ-1305.01.201616:13:39X2interfacesetupfailure05.01.201616:52:37MRBTS-738277/LNBTS-738277/LNMME-005.01.201616:11:54TransportlayerconnectionfailureinS1interface05.01.201616:52:39MRBTS-738277/LNBTS-738277/LNMME-105.01.201616:11:54TransportlayerconnectionfailureinS1interface05.01.201616:52:39MRBTS-738277/LNBTS-738277/LNMME-405.01.201616:11:54TransportlayerconnectionfailureinS1interface05.01.201616:52:39MRBTS-738277/LNBTS-738277/LNMME-205.01.201616:11:55TransportlayerconnectionfailureinS1interface05.01.201616:52:40MRBTS-738277/LNBTS-738277/LNADJ-1605.01.201616:13:41X2interfacesetupfailure05.01.201616:53:01MRBTS-738277/LNBTS-738277/LNADJ-1805.01.201616:13:43X2interfacesetupfailure05.01.201616:53:01MRBTS-738277/LNBTS-738277/LNADJ-2005.01.201616:13:43X2interfacesetupfailure05.01.201616:53:01MRBTS-738277/LNBTS-738277/LNADJ-605.01.201616:13:39X2interfacesetupfailure05.01.201616:53:01MRBTS-738277/LNBTS-738277/LNADJ-2905.01.201616:13:43X2interfacesetupfailure05.01.201616:53:05MRBTS-738277/LNBTS-738277/LNADJ-005.01.201616:13:38X2interfacesetupfailure05.01.201616:53:06MRBTS-738277/LNBTS-738277/LNADJ-1205.01.201616:13:39X2interfacesetupfailure05.01.201616:53:06MRBTS-738277/LNBTS-738277/LNADJ-2005.01.201623:21:30TransportlayerconnectionfailureinX2interface05.01.201623:25:12MRBTS-738277/LNBTS-738277/LNADJ-2104.01.201614:44:59TransportlayerconnectionfailureinX2interface05.01.201623:49:44MRBTS-738277/LNBTS-738277/LNADJ-3004.01.201614:44:59TransportlayerconnectionfailureinX2interface05.01.201623:49:44MRBTS-738277/LNBTS-738277/LNADJ-704.01.201614:44:59TransportlayerconnectionfailureinX2interface05.01.201623:49:44MRBTS-73827705.01.201623:47:02NEdisconnectedbeforeuploadfinished05.01.201623:49:53MRBTS-738277/LNBTS-738277/LNADJ-1805.01.201623:49:56TransportlayerconnectionfailureinX2interface05.01.201623:50:06MRBTS-738277/LNBTS-738277/FTM-105.01.201623:50:3705.01.201623:51:37存在的疑問(wèn)和上述的一樣就不重復(fù)。1.1.3解決方案在SCTP建立失敗后，出現(xiàn)6202、6203告警的機(jī)制如附件描述。根據(jù)現(xiàn)場(chǎng)參數(shù)”

s1InducedCellDeactDelayTime

“設(shè)置成900s，S1

中斷timer900S(15min)內(nèi)，基站應(yīng)該還有信號(hào)，但是根據(jù)附件描述，在這15分鐘內(nèi)UE是可以切進(jìn)來(lái)的，且120s(2min)中后會(huì)出現(xiàn)6202或者6203告警。在1月25日修改參數(shù)s1InducedCellDeactDelayTime

從900s調(diào)整到60s后鎮(zhèn)海區(qū)域的S1切換成功率有明顯提升，而且波動(dòng)也小了很多。

1.2.1UE上報(bào)安全模式時(shí)由于加密算法導(dǎo)致ERAB建立成功率問(wèn)題概述：在前期top小區(qū)處理時(shí)發(fā)現(xiàn)RL45版本室分站點(diǎn)接通率較低，從指標(biāo)上看都是ERAB建立失敗Counter都是EPS_BEARER_SETUP_FAIL_RNL（無(wú)線(xiàn)原因失?。┩ㄟ^(guò)DO分析主要是由于大神X7終端導(dǎo)致的問(wèn)題1.3.2問(wèn)題分析從現(xiàn)場(chǎng)對(duì)問(wèn)題基站的EMILlog來(lái)看，的確存在大量的RABAccess失敗，而且從TMSI/MSIN來(lái)看都基本上是同一個(gè)用戶(hù)造成的，和DO分析結(jié)果相同。從具體失敗的信令來(lái)看，全部都是在RRCSecurityModeCommand這步導(dǎo)致的失敗，而且全部都是因?yàn)榉峙淞薳ea3加密算法和eia3完整性保護(hù)算法導(dǎo)致的失敗。具體失敗的信令如下圖所示：該問(wèn)題現(xiàn)場(chǎng)通過(guò)關(guān)閉eea3加密算法還無(wú)法解決，后通過(guò)研發(fā)的分析和定位，該問(wèn)題是由于R11終端和RL45MP1的兼容性問(wèn)題導(dǎo)致的，1.2.3解決方案通過(guò)驗(yàn)證對(duì)4個(gè)基站升級(jí)到RL45MP2補(bǔ)丁后其中ERAB建立成功率指標(biāo)在升級(jí)后得到明顯的提升，具體如下圖所示：該問(wèn)題在RL45MP2補(bǔ)丁和RL55中得到解決。1.3.1初始上下文請(qǐng)求失敗引起的ERAB建立成功率問(wèn)題分析概述：在處理top小區(qū)時(shí)發(fā)現(xiàn)有好幾個(gè)小區(qū)無(wú)線(xiàn)接通率低都是由于ERAB建立成功率導(dǎo)致根據(jù)counter描述都是EPS_BEARER_SETUP_FAIL_OTH（其他原因?qū)е拢?。而且結(jié)合工單發(fā)現(xiàn)ERAB成功率低導(dǎo)致性能工單問(wèn)題也明顯增多。1.3.2問(wèn)題分析通過(guò)對(duì)問(wèn)題站點(diǎn)抓取Emil-log進(jìn)行分析發(fā)現(xiàn)都是由于在ERAB建立過(guò)程中InitialContextSetupFailure從原因值來(lái)看都是semantic-error主要原因我們看了是由于InitialContextSetupRequest消息帶下來(lái)的簽約速率為0所導(dǎo)致的通過(guò)OMCKPI的分析以及結(jié)合DO平臺(tái)的分析，基本確認(rèn)是部分用戶(hù)在EPC發(fā)送InitialContextSetupRequest消息給ENB時(shí)里面的uEaggregateMaximumBitRateDL=0和uEaggregateMaximumBitRateUL=0所導(dǎo)致，正常情況下應(yīng)該是將簽約速率或其它非0值下發(fā)下來(lái)的。DO平臺(tái)信令跟蹤文件分析MME下發(fā)給ENB的InitialContextSetupRequest消息UEAGGMAXBITRATE=0，導(dǎo)致ENB回復(fù)失敗消息。一旦出現(xiàn)該問(wèn)題后該UE會(huì)不斷地進(jìn)行ERAB建立請(qǐng)求不斷地失敗，從而會(huì)因?yàn)閭€(gè)別用戶(hù)而導(dǎo)致小區(qū)級(jí)別的ERAB建立成功率指標(biāo)下降明顯，而當(dāng)該用戶(hù)離開(kāi)該小區(qū)后小區(qū)指標(biāo)即可恢復(fù)。另外從單個(gè)用戶(hù)信令來(lái)看，當(dāng)用戶(hù)出現(xiàn)這種問(wèn)題后，如果終端進(jìn)行detach和attch的話(huà)該終端可以恢復(fù)正常，具體如下圖信令所示：工單小區(qū)InitialContextSetupRequest消息UEAGGMAXBITRATE=0的分析InitialContextSetupRequest消息UEAGGMAXBITRATE取值ERAB建立請(qǐng)求次數(shù)044163非0值179294匯總223457InitialContextSetupFailure原因值ERAB失敗次數(shù)失敗占比semantic-error4417799.6%空1890.4%工單小區(qū)InitialContextSetupRequest消息UEAGGMAXBITRATE=0的ERAB請(qǐng)求次數(shù)和原因值為semantic-error的InitialContextSetupFailure消息次數(shù)基本是吻合的。所以基本可以確定是由于核心網(wǎng)EPC給ENB發(fā)送InitialContextSetupRequest消息中UEAGGMAXBITRATE=0導(dǎo)致ENB建立ERAB失敗。從信令跟蹤來(lái)看，用戶(hù)出現(xiàn)這種問(wèn)題后如果終端進(jìn)行detach和attach可以恢復(fù)業(yè)務(wù)1.3.3解決方案通過(guò)OMC指標(biāo)和DO平臺(tái)分析，5月10日上午ERAB建立失敗工單問(wèn)題是由于核心網(wǎng)EPC在給ENB發(fā)送InitialContextSetupRequest消息中UEAGGMAXBITRATE=0的請(qǐng)求時(shí)，ENB反饋原因值為semantic-error的InitialContextSetupFailure消息所導(dǎo)致的。而正常情況下EPCMME發(fā)送的InitialContextSetupRequest消息中的UEAGGMAXBITRATE不應(yīng)該為0。經(jīng)過(guò)和核心網(wǎng)MME專(zhuān)家確認(rèn)，目前該問(wèn)題核心網(wǎng)側(cè)將會(huì)在NS3.16升級(jí)解決。InitialContextSetupRequest消息UEAGGMAXBITRATE取值升級(jí)前升級(jí)后ERAB建立請(qǐng)求次數(shù)0441630非0值179294240743匯總2234572407431.4.1MR測(cè)量添加聯(lián)通、電信頻點(diǎn)引起的切換準(zhǔn)備成功率問(wèn)題概述：在處理基于MR的競(jìng)對(duì)覆蓋評(píng)估是指在移動(dòng)eNodeB中添加異運(yùn)營(yíng)商的FDD頻點(diǎn)/鄰區(qū)，晚上對(duì)鎮(zhèn)海區(qū)域第一批

電信聯(lián)通頻點(diǎn)添加后，添加完成后觀(guān)察指標(biāo)發(fā)現(xiàn)出現(xiàn)大量切換準(zhǔn)備失敗都是

INTER_HO_PREP_FAIL_OTH、INTER_HO_PREP_FAIL_TIME，當(dāng)晚進(jìn)行參數(shù)回退，并重新調(diào)整方案。1.4.2問(wèn)題分析晚上對(duì)鎮(zhèn)海區(qū)域第一批電信聯(lián)通頻點(diǎn)添加后，與前一天同時(shí)段指標(biāo)對(duì)比如下：加完頻點(diǎn)后切換準(zhǔn)備成功率從98.46%，下降至72.11%。sdateCell_Avail(%)Radio_SR(%)RRC_SR(%)E-RAB_SR(%)Drop_Rate(%)PREP_HOSR(%)HO_SR(%)UL_VOL(MB)DL_VOL(MB)2016080810099.7999.8199.98098.4698.484355.3541140.432016080999.699.799.7599.95072.1199.434201.3646968.52立即對(duì)問(wèn)題進(jìn)行分析，首先提取15分鐘級(jí)點(diǎn)對(duì)點(diǎn)切換指標(biāo)發(fā)現(xiàn)都是添加頻點(diǎn)后出現(xiàn)的大量切換準(zhǔn)備失敗，通過(guò)對(duì)端的切換準(zhǔn)備失敗小區(qū)ECI驗(yàn)證，發(fā)現(xiàn)在現(xiàn)網(wǎng)上無(wú)法找到，立即登站在鄰區(qū)ADJ里找到相應(yīng)的ENBID發(fā)現(xiàn)x2LinkStatus狀態(tài)都是unavailable，同樣在現(xiàn)網(wǎng)無(wú)法找到相應(yīng)的ENBID，這時(shí)可以確認(rèn)在添加聯(lián)通電信頻點(diǎn)后，會(huì)同時(shí)生成ADJ鄰區(qū)，聯(lián)通電信站點(diǎn)未加移動(dòng)鄰區(qū)，無(wú)法形成X2鏈路導(dǎo)致大量切換準(zhǔn)備失敗。通過(guò)查看點(diǎn)對(duì)點(diǎn)切換，有大量的切換準(zhǔn)備請(qǐng)求次數(shù)，都沒(méi)有到達(dá)切換嘗試階段。1.4.3解決方案找到原因后立即對(duì)參數(shù)倒回，倒回成功后立即對(duì)指標(biāo)進(jìn)行對(duì)比如下：sdateCell_Avail(%)Radio_SR(%)RRC_SR(%)E-RAB_SR(%)Drop_Rate(%)PREP_HOSR(%)HO_SR(%)UL_VOL(MB)DL_VOL(MB)2016080810099.7999.8199.98098.2298.272528.5725072.122016080999.699.7699.8199.96098.9199.12765.1535452.24參數(shù)回退后對(duì)比指標(biāo)，切換準(zhǔn)備成功率回到之前水平，但在添加聯(lián)通電信頻點(diǎn)后，已經(jīng)自動(dòng)生成的ADJ同時(shí)也需要?jiǎng)h除，怎么樣快速找到這些新生成的ADJ，比較重要，ADJ信息里面包含移動(dòng)的MNC（移動(dòng)網(wǎng)絡(luò)碼）為00，所以只要在配置表中找到移動(dòng)網(wǎng)絡(luò)碼不為00的ADJ進(jìn)行刪除就可以了。后續(xù)方案：為了解決異頻周期性MR上報(bào)的功能，所以要做這個(gè)測(cè)量的話(huà)，只有通過(guò)觸發(fā)A3/A5事件性的MR測(cè)量來(lái)實(shí)現(xiàn)。另外，需要將現(xiàn)網(wǎng)的ANR關(guān)閉，不然會(huì)導(dǎo)致切換準(zhǔn)備失敗的問(wèn)題(因?yàn)锳NR會(huì)將聯(lián)通電信的鄰區(qū)給加上的)。所以，需要做這個(gè)事情需要做如下內(nèi)容的修改：1)

關(guān)閉基站異頻ANR功能(增加異頻ANR功能都關(guān)閉)

actUeBasedAnrInterFreqLte=false2)

增加聯(lián)通電信的切換異頻頻點(diǎn)，就用A5方式：LNHOIF中本小區(qū)門(mén)限threshold3InterFreq<-43dBm，鄰區(qū)門(mén)限threshold3aInterFreq>-140dBm，同時(shí)A5事件MR上報(bào)間隔事件a5ReportIntervalInterFreq設(shè)置為5120ms，這樣和同頻周期MR上報(bào)周期相同，LNHOIF中帶寬需要修改正確,電信75PRB（頻點(diǎn)1825），聯(lián)通100PRB（頻點(diǎn)1650）。3)

修改異頻起測(cè)門(mén)限，讓終端盡早起測(cè)。異頻A2門(mén)限可以設(shè)置為最大值threshold2Inter