河南EGPRS 典型案例

2021年04月01日河南EGPRS網(wǎng)絡優(yōu)化

經(jīng)驗分享典型案例案例總結(jié)針對休眠小區(qū)處理的主要手段有：1. 檢查有無硬件告警，檢查GB/BVCI的狀態(tài)是否正常；2. 有7725告警沒，有就直接調(diào)NSEI；3.GPRS流量正常，沒EGPRS流量，重啟EGENA。4.重啟BCF，對有7738(BTSWITHNOTRANSACTIONS)告警〔告警原因是10nosuccessfulGPRStransactions的小區(qū)首先建議重啟BCF;5. 如果是建有EDAP的小區(qū)，建議檢查BSC側(cè)和基站側(cè)EDAP時隙寬度是否一致；6. 對NSEI下多個小區(qū)出現(xiàn)休眠的情況建議倒換BCSU7.一直都沒有數(shù)據(jù)流量也無話音話務量，建議檢查基站的硬件TRX出現(xiàn)7743告警倒換載頻。檢查TBF_success%指標低于95%重啟載頻或檢查硬件案例總結(jié)道路測試個別涉及到的問題小區(qū)需要做檢查，擁塞等問題。提高EGPRS覆蓋率。開通EGPRS小區(qū)，檢查BCCH-TRX是否支持EDGE。減少LAC間的小區(qū)頻繁重選。主要是控制小區(qū)的頻繁重選〔特出主控小區(qū))。檢查半速率GPRS不支持半速率信道〔TCHH〕。如果開了半速率〔TCHD〕，開GTRX的載頻建議最少有一個信道開TCHF。如果BCCH載頻開了半速率〔TCHD〕，開GTRX的載頻必須有一個信道開TCHD。檢查EDGE的GTRX+DAP_ID，ET_PCM開通EDGE功能的GTRX=Y載頻必需配對一個DAP_ID而且必需在同一個ET線上無GP信道的小區(qū)小區(qū)的BTS的GP為0，BVCI的狀態(tài)是UNBLOCKD。檢查GTRX有沒有過多導致PCU由于資源缺乏而分配不了GP信道。嘗試調(diào)小GTRX或CDEF區(qū)域。沒測量數(shù)據(jù)測量C_SCHEME被關(guān)。OMC統(tǒng)計中發(fā)現(xiàn)LHBSC8有GPRS流量但是沒有EDGE流量，但是在BSC8的EDGE小區(qū)下現(xiàn)場測試情況正常。檢查EDGE小區(qū)的數(shù)據(jù)設置和EDAP的情況正常；BSC有傳輸方面的告警，聯(lián)系機房人員得知有告警的傳輸都是空口傳輸，沒有建EDAP。疑心是數(shù)據(jù)沒有成功上傳到OMC或者是數(shù)據(jù)收集失敗或者是沒有收集。檢查BSC測量情況，發(fā)現(xiàn)LHBSC8關(guān)于EDGE的測量C_SCHEME的狀態(tài)是DISABLED。此測量被關(guān)致使MCS編碼方式的流量情況無法統(tǒng)計，從而使LHBSC8下的EDGE小區(qū)都無法統(tǒng)計出EGPRS的流量BSC割接和頻率割接 主要原因:小區(qū)割接后出現(xiàn)數(shù)據(jù)吊死，重啟BCF后恢復正常。割接后小區(qū)的EDAP時隙基站數(shù)據(jù)和BSC數(shù)據(jù)配對不上，造成EGPRS無流量。EDAP時隙數(shù)據(jù)重新配對后，功能恢復正常。沒備份基站數(shù)據(jù)，BSC割接后，靜態(tài)或動態(tài)數(shù)據(jù)區(qū)域=0，造成無數(shù)據(jù)流量。更正后，恢復正常。

GPRSANDEGPRSPAYLOADREDUCEAFTERFREQCUTOVEREGPRSandGPRSPayloadwasrenewedaftermanybcfwasrestardedandmanydapwasconsistentGPRS/EGPRS總流量大幅度下降GB丟包從2021年2月2號開始，投訴量明顯上升，很多用戶投訴上不去網(wǎng)，上網(wǎng)速度慢，上去了也是時斷時續(xù)，我們首先針對投訴小區(qū)做了重啟GENA,調(diào)整時隙，重啟BCF，倒換TRX，倒換NSEI等操作，都沒有明顯效果，當現(xiàn)場測試發(fā)現(xiàn)，占到問題小區(qū)之后，電平值很好，占用的也是高編碼方式，就是下載文件過程中速度很低而且很不穩(wěn)定，后來觀察發(fā)現(xiàn)，投訴小區(qū)都是BSC2的小區(qū)，排除了BTS級的問題，我們?nèi)×薌B口的一些參數(shù)發(fā)現(xiàn)，整個BSC2的GB口丟包率很高，立刻通知客戶聯(lián)系交換班檢查原因，當天晚上做了ESD板的檢查，第二天恢復了正常。GB負荷高小區(qū)高擁塞分析日常KPI監(jiān)控中，小區(qū)40943的上下行硬阻塞很高，最高時到達了30%，檢查小區(qū)的信道配置，配置充足，專用信道6個，每小時最高流量80M，完全能滿足。進一步檢查小區(qū)所在NSEI10202的GB負荷，CIR為320K的，最高負荷高達80%，GB負荷太高，直接導致了信道分配失敗率過高，將此小區(qū)調(diào)整到負荷較輕的10208下，小區(qū)的各項KPI恢復到正常，擁塞消失。PCU負荷均勻降CDEF到2個時隙PCU負荷均勻緊急短期減少PCU擁塞的優(yōu)化案例：下調(diào)CDEF=2。PCU負荷均勻。解決了高PCU擁塞所引起的個別小區(qū)高時隙分配拒絕率。但是速率和無線充足率下降。長期方按應該增加PCU。PCU內(nèi)頻繁出現(xiàn)休眠小區(qū)NSEI=5024頻繁出現(xiàn)休眠小區(qū)在上周的休眠小區(qū)監(jiān)控中我們發(fā)現(xiàn)：在NSEI=5024的PCU下的小區(qū)頻繁的出現(xiàn)休眠小區(qū)〔小區(qū)無數(shù)據(jù)流量或者是無EGPRS流量〕，休眠小區(qū)常伴隨出現(xiàn)3273告警，重啟GENA和BCF都不能恢復，把小區(qū)換到其他的PCU后恢復正常。最初疑心是PCU負荷過高，切換兩個小區(qū)后NSEI=5024的PCU負荷只有60%，但還是會出現(xiàn)休眠小區(qū)的情況。在確定不是PCU負荷的因素后，提工單建議重切BCSU。重切后NSEI=5024下沒有再出現(xiàn)休眠小區(qū)?？偨Y(jié)：PCU的工作狀態(tài)或者是硬件問題也是導致休眠小區(qū)多發(fā)的一個因素。PCU吊死PCUBL-RC導致小區(qū)無法上網(wǎng)日常監(jiān)控中發(fā)現(xiàn)，小區(qū)36321/2/3(延津郭莊)無GPRS流量,因此立即查看基站運行狀態(tài),GPRS功能已翻開，但GPRS虛鏈路處于BL-SYS狀態(tài)，進一步查看所在PCU,發(fā)現(xiàn)PCU吊死，立即通知機房處理，處理完畢后各個小區(qū)流量恢復正常。PCU隱性故障不能上網(wǎng)，經(jīng)檢查未告警，EDGE無流量，判斷為PCU隱性故障，經(jīng)NSEI更改，恢復正常高低行TBFFlush小區(qū)沒流量，發(fā)現(xiàn)高低行TBFFlush和告警“7604BTSoperationdegraded〞。重啟BTS后，恢復正常。頻率干擾TBF成功率低，高誤碼率。調(diào)整頻率后，指標正常。DAP設置錯誤42553DAP錯誤導致小區(qū)無EDGE流量日常KPI監(jiān)控發(fā)現(xiàn)，小區(qū)有上行的EGPRSTBF建立，但卻沒有流量，而GPRS流量一直保持正常，查看基站告警，沒有告警，檢查小區(qū)參數(shù)設置，小區(qū)共有3塊TRX，開了2塊GTRX，但其中的一塊TRX9雖然翻開了GTRX,卻沒有綁定DAP,此小區(qū)為GPRS與EGPRS共用一個BTS設置，此時必須所有的GTRX都綁定了DAP，小區(qū)的EGPRS才能正常使用，在分析此小區(qū)的流量后，一塊載頻的GPRS已經(jīng)夠用，因此，關(guān)閉了這塊沒有綁定DAP的GTRX，小區(qū)的EDGE流量也恢復了正常DAP配置不符開啟EDGE后無流量在激活小區(qū)的EGENA后，這個三個小區(qū)都沒有EDGE流量，查看基站配置，此站為3個小區(qū)共用一個BCF，也共用一條DAP，進一步查看DAP,DAP時隙配置為4個TSL，這和規(guī)劃的DAP配置不符〔規(guī)劃配置：多小區(qū)共用DAP時配置為6個TSL〕，因此立即修改了BSC數(shù)據(jù)，并在重啟基站后，三個小區(qū)都有EDGE流量，EGPRS也正常使用。DAP配置不符由于EDAP時隙配置不一致〔BSC與BTS之間〕，造成EGPRS不能正常使用BTS工程師已經(jīng)修改EDAP時隙配置為48但是BTS側(cè)修改后，由于BSC側(cè)未作任何修改導致EGPRS不能正常使用3月16日，BSC側(cè)修改EDAP配置，BTS工作正常，用戶能夠正常使用EGPRS.BTS和BSC間配置不一致（EDAP)DAP擴容須重啟BCFDAP擴容如果不重啟BCF會導致以下兩種問題(1)導致BCF吊死，無法使用EGPRS，如以下小區(qū)在DAP擴容后無法使用EDGE，在重啟GENA,切換PCU后,仍然不能使用EDGE,經(jīng)檢查，BSC和基站側(cè)綁定DAP一致,無任何告警，在重啟BCF后恢復正常，如以下數(shù)據(jù)：升級拒絕失敗率高升級拒絕失敗率高小區(qū)的處理在最差小區(qū)的處理中，對PCU無擁塞而小區(qū)的升級決絕失敗率高的小區(qū)進行了增加數(shù)據(jù)域的處理。處理的主要方法是：對高話務的小區(qū)BTS進行增加CDED/CDEF，對話務不高的小區(qū)增加GTRX，增加CDEF.增加前后小區(qū)的比照情況如下升級拒絕失敗率高升級拒絕率高的BSC優(yōu)化處理在對BSCkip指標進行檢查時，發(fā)現(xiàn)局部BSC域拒絕率較高，檢查參數(shù)時發(fā)現(xiàn)，局部高拒絕率的BSC其參數(shù)設置存在問題：TRP和BFG設置都為1，不能很好的對數(shù)據(jù)和話音進行分割處理，在一定程度上影響數(shù)據(jù)域的升級，我們對BSC3進行了實驗性參數(shù)修改優(yōu)化，初見成效：GTRX開啟半速率不能上網(wǎng)，經(jīng)核查，無告警，但EDGE層GTRX開啟半速率，關(guān)閉半速率GTRX，恢復正常遠端未及時修改數(shù)據(jù)小區(qū)無流量處理日常監(jiān)控中發(fā)現(xiàn)，小區(qū)34914無任何流量，指標上看只有上行的TBF建立與分配，但是沒有流量，經(jīng)查此小區(qū)為微蜂窩，頻率修改后，直放站的遠端未及時修改造成，在10月28日廠家修改了頻點后，小區(qū)的各項KPI指標恢復正常。7735載頻故障不能上網(wǎng)，經(jīng)核查EDGEGTRX有7735告警，經(jīng)過EDGEGTRX重啟，恢復正常7725時隙故障影響GP的連續(xù)性時隙故障影響GP的連續(xù)性導致的時隙分配高拒絕發(fā)現(xiàn)小區(qū)20216的多時隙分配拒絕率突然上升，檢查告警發(fā)現(xiàn)GTRX〔TRX3〕的RTSL5有7725告警。而此小區(qū)的主BTS只有一個TRX。而GPRS〔EDGE〕用戶的時隙占用需要具有連續(xù)性，RTSL5的故障會影響用戶對分配時隙的占用。因為數(shù)據(jù)時隙的分配會優(yōu)先分配5，6，7時隙。重啟BCF后告警消除，多時隙分配成功率也恢復正常。7723告警，休眠小區(qū)優(yōu)化日常睡眠小區(qū)監(jiān)控中發(fā)現(xiàn)，37991小區(qū)沒有任何流量，無任何信道請求信息，查看基站告警，BCCH載頻有7723告警，附加字段為10，提示為由于GB口的原因造成BCCH系統(tǒng)信息的下發(fā)錯誤，查看與此小區(qū)同一NSEI下的其它小區(qū)，指標正常，因此應該是此小區(qū)與PCU間的配合出現(xiàn)了問題，立即調(diào)整此小區(qū)到其它NSEI下，指標恢復正常，流量正常。7745告警，小區(qū)TBF成功率低優(yōu)化日常最壞小區(qū)處理中發(fā)現(xiàn)，小區(qū)的TBF成功率很低，為80%左右；立即查看基站運行狀態(tài)，發(fā)現(xiàn)兩塊GTRX載頻中TRX17745告警嚴重，載頻工作不穩(wěn)定造成TBF成功低，因此立即倒換此塊GTRX到另外一塊TRX上，更換之后TBF成功率恢復到99%，各項GPRS指標也恢復正常。TBF成功率降低(1)用戶投訴自24日開始，上網(wǎng)不正常，經(jīng)常掉線，接到反映之后，我們立即查看了KPI，發(fā)現(xiàn)3扇區(qū)從24日開啟跳頻之后，TBF成功率明顯降低，因此立即關(guān)閉了跳頻，關(guān)閉之后，指標恢復正常，回訪用戶也上網(wǎng)正常了，疑心為跳頻單元單元的問題。(2)用戶投訴最近上網(wǎng)老是掉線，經(jīng)常該站的三個扇區(qū)指標，確實這幾天的TBF成功率較低，流量也明顯降低，查看基站也無任何告警，這三個小區(qū)共同一BCF，因此重啟BCF，但TBF成功率仍然沒有恢