小區(qū)高負荷造成無線接通率低處理案例

1、卓越品質(zhì)的創(chuàng)造者故障案例小區(qū)高負荷造成無線接通率低處理案例省公司江蘇省專業(yè)無線設(shè)備類型設(shè)備廠家中興設(shè)備型號B8300軟件版本關(guān)鍵字無線接通率低 小區(qū)高負荷 故障描述在LTE小區(qū)日常監(jiān)控中發(fā)現(xiàn)LTE市區(qū)城坤鋼材市場東_1的RRC建立成功率突然降低，從下圖可以看出，該小區(qū)RRC建立成功率從11：00開始惡化由原來的99.72%下降至94.17%，每小時RRC建立失敗800多次，指標惡化嚴重影響用戶感知。截圖如下：時間無線接通率_集團_zteRRC連接成功率_集團_zteERAB建立成功率_集團_zte切換成功率_集團_zteZJ平均底噪2015/6/7 10:0099.68%99.72%99.97

2、%99.17%-1162015/6/7 11:0095.00%95.09%99.91%99.40%-1162015/6/7 12:0094.06%94.17%99.88%98.77%-1162015/6/7 13:0094.89%94.93%99.97%99.39%-116告警信息無原因分析1、RRC失敗原因分析：影響RRC接入成功率的主要因素如下：小區(qū)故障、參數(shù)設(shè)置不合理，如PRACH參數(shù)配置，最小接入電平、小區(qū)存在干擾，上行干擾（雜散干擾、諧波干擾、寬頻干擾、大氣波導）、下行MOD3干擾、弱場接入RRC無法完成、用戶數(shù)多SR容量不足、CPU負荷高等。RRC建立失敗分析流程：1、 通過排查，

3、該小區(qū)不存在告警、參數(shù)、干擾等問題，如下圖所示通過提取TA分布發(fā)現(xiàn)該小區(qū)TA分布主要集中在0-9范圍內(nèi)，覆蓋集中在大約0-700米內(nèi)，不存在遠距離接入的情況：1TA=16Ts=16*32.55ns*300000000/2=78m基站地理分布:2、 通過查詢發(fā)現(xiàn)RRC建立失敗原因主要為“mo-Data類型RRC連接失敗次數(shù)，定時器超時”平均1小時600多次，如圖所示：日期RRC連接建立成功率mt-Access類型RRC連接失敗次數(shù)，定時器超時mo-Signalling類型RRC連接失敗次數(shù)，定時器超時mo-Data類型RRC連接失敗次數(shù)，定時器超時RRC連接釋放次數(shù)，空口定時器超時RRC連接釋放

4、次數(shù)，重建立失敗引發(fā)的釋放2015/6/7 10:0095.09%7913245927932015/6/7 11:0094.17%80247601541052015/6/7 12:0094.93%1149559424444、如下圖所示“mo-Data類型RRC連接失敗次數(shù)，定時器超時”造成的RRC連接建立失敗主要是因：CPU負荷是否偏高，用戶數(shù)多、參數(shù)、NI是否偏高、RRU輸出功率異常、是否MR任務(wù)和其他實時跟蹤任務(wù)導致接入定時器超時、是否弱場導致接入定時器超時等。RRC處理手段 計數(shù)器編號計數(shù)器名稱/描述信息建議措施C3732001mt-Access類型RRC連接失敗次數(shù)，定時器超時(次)1

5、.檢查CPU負荷是否偏高，用戶數(shù)是都很多，如是調(diào)整SR容量進行優(yōu)化2.檢查上下行功控類參數(shù)3.檢查NI是否偏高4.檢查RRU輸出功率5.檢查是否MR任務(wù)和其他實時跟蹤任務(wù)導致接入定時器超時6.檢查是否弱場導致接入定時器超時。C373200002mt-Access類型RRC連接失敗次數(shù)，eNB接納失敗(次)1.檢查接納控制類參數(shù)設(shè)置C373200003mt-Access類型RRC連接失敗次數(shù)，其他原因(次1.檢查是否CPU沖高導致2.提交故障單交研發(fā)處理C373200005mo-Signalling類型RRC連接失敗次數(shù)，定時器超時(次)1.檢查CPU負荷是否偏高，用戶數(shù)是都很多，如是調(diào)整SR容

6、量進行優(yōu)化2.檢查上下行功控類參數(shù)3.檢查NI是否偏高4.檢查RRU輸出功率5.檢查是否MR任務(wù)和其他實時跟蹤任務(wù)導致接入定時器超時6.檢查是否弱場導致接入定時器超時。C373200006mo-Signalling類型RRC連接失敗次數(shù)，eNB接納失敗(次)1.檢查接納控制類參數(shù)設(shè)置C37300007mo-Signalling類型RRC連接失敗次數(shù)，其他原因(次)1.檢查是否CPU沖高導致2.提交故障單交研發(fā)處理C373200009mo-Data類型RRC連接失敗次數(shù)，定時器超時(次)1.檢查CPU負荷是否偏高，用戶數(shù)是都很多，如是調(diào)整SR容量進行優(yōu)化2.檢查上下行功控類參數(shù)3.檢查NI是否偏

7、高4.檢查RRU輸出功率5.檢查是否MR任務(wù)和其他實時跟蹤任務(wù)導致接入定時器超時6.檢查是否弱場導致接入定時器超時。C373200010mo-Data類型RRC連接失敗次數(shù)，eNB接納失敗(次)1.檢查接控類參數(shù)設(shè)置C373200011mo-Data類型RRC連接失敗次數(shù)，其他原因(次)1.檢查是否CPU沖高導致2.提交故障單交研發(fā)處理C373200013highPriorityAccess類型RRC連接失敗次數(shù)，定時器超時(次)1.檢查CPU負荷是否偏高，用戶數(shù)是都很多，如是調(diào)整SR容量進行優(yōu)化2.檢查上下行功控類參數(shù)3.檢查NI是否偏高4.檢查RRU輸出功率5.檢查是否MR任務(wù)和其他實時跟

8、蹤任務(wù)導致接入定時器超時6.檢查是否弱場導致接入定時器超時。C373200014highPriorityAccess類型RRC連接失敗次數(shù)，eNB接納失敗(次)1.檢查接納控制類參數(shù)設(shè)置C373200015highPriorityAccess類型RRC連接失敗次數(shù)，其他原因(次)1.檢查是否CPU沖高導致2.提交故障單交研發(fā)處理C373200017emergency類型RRC連接失敗次數(shù)，定時器超時(次)1.檢查CPU負荷是否偏高，用戶數(shù)是都很多，如是調(diào)整SR容量進行優(yōu)化2.檢查上下行功控類參數(shù)3.檢查NI是否偏高4.檢查RRU輸出功率5.檢查是否MR任務(wù)和其他實時跟蹤任務(wù)導致接入定時器超時6

9、.檢查是否弱場導致接入定時器超時。C373200018emergency類型RRC連接失敗次數(shù)，eNB接納失敗(次)1.檢查接納控制類參數(shù)設(shè)置C373200019emergency類型RRC連接失敗次數(shù)，其他原因(次)1.檢查是否CPU沖高導致2.提交故障單交研發(fā)處理5、通過分析發(fā)現(xiàn)該小區(qū)每小時空口流量在7GB左右，PRB利用率最高在49%左右，RRC最大用戶數(shù)250人左右，為嚴重高負荷小區(qū)。通過以上分析最終確認RRC建小區(qū)高負荷導致RRC建立成功率低。時間空口總業(yè)務(wù)字節(jié)數(shù)(GB)空口上行業(yè)務(wù)字節(jié)數(shù)GB空口下行業(yè)務(wù)字節(jié)數(shù)GB TDD上行信道PRB資源利用率TDD下行信道PRB資源利用率RRC連

10、接建立最大用戶數(shù)RRC連接建立平均用戶數(shù)2015/6/7 10:007.330.486.8538.54%49.02%187152.242015/6/7 11:007.110.516.642.59%48.49%254193.122015/6/7 12:006.490.376.1237.05%45.12%236166.232015/6/7 13:005.270.324.9537.65%35.75%268213.25處理步驟:未避免指標繼續(xù)惡化造成用戶投訴臨時對以下參數(shù)進行了調(diào)整:1、 CRS參考信號功率由18->12：2、 A1、A2門限由-92、-95改為-79、-823、進行負荷分擔3、 如下圖所示，隨后提取指標發(fā)現(xiàn)RRC用戶由250下降至170左右，無線接通率指標也恢復正常：4、 該小區(qū)因用戶較多，造成高負荷，臨時調(diào)整并不能徹底解決問題，還需擴容吸收話務(wù)量。但該站位于空軍后勤學院內(nèi)，工程隊到現(xiàn)場后經(jīng)過協(xié)調(diào)整仍無法進入，不能擴容。因在原站上不能進行擴容所以計劃調(diào)整附近的站點方位角吸收話務(wù)，該站最近的兩個點為LTE市區(qū)后勤學院和LTE市區(qū)空后院搬遷，但因LTE市區(qū)后勤學院1、3覆蓋區(qū)域為網(wǎng)格和空軍后勤學院比較敏感不符合條件，而LTE市區(qū)空后院搬