河南EGPRS 典型案例

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

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

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