河南EGPRS 典型案例

2021年04月01日河南EGPRS网络优化

经验分享典型案例案例总结针对休眠小区处理的主要手段有：1. 检查有无硬件告警，检查GB/BVCI的状态是否正常；2. 有7725告警没，有就直接调NSEI；3.GPRS流量正常，没EGPRS流量，重启EGENA。4.重启BCF，对有7738(BTSWITHNOTRANSACTIONS)告警〔告警原因是10nosuccessfulGPRStransactions的小区首先建议重启BCF;5. 如果是建有EDAP的小区，建议检查BSC侧和基站侧EDAP时隙宽度是否一致；6. 对NSEI下多个小区出现休眠的情况建议倒换BCSU7.一直都没有数据流量也无话音话务量，建议检查基站的硬件TRX出现7743告警倒换载频。检查TBF_success%指标低于95%重启载频或检查硬件案例总结道路测试个别涉及到的问题小区需要做检查，拥塞等问题。提高EGPRS覆盖率。开通EGPRS小区，检查BCCH-TRX是否支持EDGE。减少LAC间的小区频繁重选。主要是控制小区的频繁重选〔特出主控小区)。检查半速率GPRS不支持半速率信道〔TCHH〕。如果开了半速率〔TCHD〕，开GTRX的载频建议最少有一个信道开TCHF。如果BCCH载频开了半速率〔TCHD〕，开GTRX的载频必须有一个信道开TCHD。检查EDGE的GTRX+DAP_ID，ET_PCM开通EDGE功能的GTRX=Y载频必需配对一个DAP_ID而且必需在同一个ET线上无GP信道的小区小区的BTS的GP为0，BVCI的状态是UNBLOCKD。检查GTRX有没有过多导致PCU由于资源缺乏而分配不了GP信道。尝试调小GTRX或CDEF区域。没测量数据测量C_SCHEME被关。OMC统计中发现LHBSC8有GPRS流量但是没有EDGE流量，但是在BSC8的EDGE小区下现场测试情况正常。检查EDGE小区的数据设置和EDAP的情况正常；BSC有传输方面的告警，联系机房人员得知有告警的传输都是空口传输，没有建EDAP。疑心是数据没有成功上传到OMC或者是数据收集失败或者是没有收集。检查BSC测量情况，发现LHBSC8关于EDGE的测量C_SCHEME的状态是DISABLED。此测量被关致使MCS编码方式的流量情况无法统计，从而使LHBSC8下的EDGE小区都无法统计出EGPRS的流量BSC割接和频率割接 主要原因:小区割接后出现数据吊死，重启BCF后恢复正常。割接后小区的EDAP时隙基站数据和BSC数据配对不上，造成EGPRS无流量。EDAP时隙数据重新配对后，功能恢复正常。没备份基站数据，BSC割接后，静态或动态数据区域=0，造成无数据流量。更正后，恢复正常。

GPRSANDEGPRSPAYLOADREDUCEAFTERFREQCUTOVEREGPRSandGPRSPayloadwasrenewedaftermanybcfwasrestardedandmanydapwasconsistentGPRS/EGPRS总流量大幅度下降GB丢包从2021年2月2号开始，投诉量明显上升，很多用户投诉上不去网，上网速度慢，上去了也是时断时续，我们首先针对投诉小区做了重启GENA,调整时隙，重启BCF，倒换TRX，倒换NSEI等操作，都没有明显效果，当现场测试发现，占到问题小区之后，电平值很好，占用的也是高编码方式，就是下载文件过程中速度很低而且很不稳定，后来观察发现，投诉小区都是BSC2的小区，排除了BTS级的问题，我们取了GB口的一些参数发现，整个BSC2的GB口丢包率很高，立刻通知客户联系交换班检查原因，当天晚上做了ESD板的检查，第二天恢复了正常。GB负荷高小区高拥塞分析日常KPI监控中，小区40943的上下行硬阻塞很高，最高时到达了30%，检查小区的信道配置，配置充足，专用信道6个，每小时最高流量80M，完全能满足。进一步检查小区所在NSEI10202的GB负荷，CIR为320K的，最高负荷高达80%，GB负荷太高，直接导致了信道分配失败率过高，将此小区调整到负荷较轻的10208下，小区的各项KPI恢复到正常，拥塞消失。PCU负荷均匀降CDEF到2个时隙PCU负荷均匀紧急短期减少PCU拥塞的优化案例：下调CDEF=2。PCU负荷均匀。解决了高PCU拥塞所引起的个别小区高时隙分配拒绝率。但是速率和无线充足率下降。长期方按应该增加PCU。PCU内频繁出现休眠小区NSEI=5024频繁出现休眠小区在上周的休眠小区监控中我们发现：在NSEI=5024的PCU下的小区频繁的出现休眠小区〔小区无数据流量或者是无EGPRS流量〕，休眠小区常伴随出现3273告警，重启GENA和BCF都不能恢复，把小区换到其他的PCU后恢复正常。最初疑心是PCU负荷过高，切换两个小区后NSEI=5024的PCU负荷只有60%，但还是会出现休眠小区的情况。在确定不是PCU负荷的因素后，提工单建议重切BCSU。重切后NSEI=5024下没有再出现休眠小区。总结：PCU的工作状态或者是硬件问题也是导致休眠小区多发的一个因素。PCU吊死PCUBL-RC导致小区无法上网日常监控中发现，小区36321/2/3(延津郭庄)无GPRS流量,因此立即查看基站运行状态,GPRS功能已翻开，但GPRS虚链路处于BL-SYS状态，进一步查看所在PCU,发现PCU吊死，立即通知机房处理，处理完毕后各个小区流量恢复正常。PCU隐性故障不能上网，经检查未告警，EDGE无流量，判断为PCU隐性故障，经NSEI更改，恢复正常高低行TBFFlush小区没流量，发现高低行TBFFlush和告警“7604BTSoperationdegraded〞。重启BTS后，恢复正常。频率干扰TBF成功率低，高误码率。调整频率后，指标正常。DAP设置错误42553DAP错误导致小区无EDGE流量日常KPI监控发现，小区有上行的EGPRSTBF建立，但却没有流量，而GPRS流量一直保持正常，查看基站告警，没有告警，检查小区参数设置，小区共有3块TRX，开了2块GTRX，但其中的一块TRX9虽然翻开了GTRX,却没有绑定DAP,此小区为GPRS与EGPRS共用一个BTS设置，此时必须所有的GTRX都绑定了DAP，小区的EGPRS才能正常使用，在分析此小区的流量后，一块载频的GPRS已经够用，因此，关闭了这块没有绑定DAP的GTRX，小区的EDGE流量也恢复了正常DAP配置不符开启EDGE后无流量在激活小区的EGENA后，这个三个小区都没有EDGE流量，查看基站配置，此站为3个小区共用一个BCF，也共用一条DAP，进一步查看DAP,DAP时隙配置为4个TSL，这和规划的DAP配置不符〔规划配置：多小区共用DAP时配置为6个TSL〕，因此立即修改了BSC数据，并在重启基站后，三个小区都有EDGE流量，EGPRS也正常使用。DAP配置不符由于EDAP时隙配置不一致〔BSC与BTS之间〕，造成EGPRS不能正常使用BTS工程师已经修改EDAP时隙配置为48但是BTS侧修改后，由于BSC侧未作任何修改导致EGPRS不能正常使用3月16日，BSC侧修改EDAP配置，BTS工作正常，用户能够正常使用EGPRS.BTS和BSC间配置不一致（EDAP)DAP扩容须重启BCFDAP扩容如果不重启BCF会导致以下两种问题(1)导致BCF吊死，无法使用EGPRS，如以下小区在DAP扩容后无法使用EDGE，在重启GENA,切换PCU后,仍然不能使用EDGE,经检查，BSC和基站侧绑定DAP一致,无任何告警，在重启BCF后恢复正常，如以下数据：升级拒绝失败率高升级拒绝失败率高小区的处理在最差小区的处理中，对PCU无拥塞而小区的升级决绝失败率高的小区进行了增加数据域的处理。处理的主要方法是：对高话务的小区BTS进行增加CDED/CDEF，对话务不高的小区增加GTRX，增加CDEF.增加前后小区的比照情况如下升级拒绝失败率高升级拒绝率高的BSC优化处理在对BSCkip指标进行检查时，发现局部BSC域拒绝率较高，检查参数时发现，局部高拒绝率的BSC其参数设置存在问题：TRP和BFG设置都为1，不能很好的对数据和话音进行分割处理，在一定程度上影响数据域的升级，我们对BSC3进行了实验性参数修改优化，初见成效：GTRX开启半速率不能上网，经核查，无告警，但EDGE层GTRX开启半速率，关闭半速率GTRX，恢复正常远端未及时修改数据小区无流量处理日常监控中发现，小区34914无任何流量，指标上看只有上行的TBF建立与分配，但是没有流量，经查此小区为微蜂窝，频率修改后，直放站的远端未及时修改造成，在10月28日厂家修改了频点后，小区的各项KPI指标恢复正常。7735载频故障不能上网，经核查EDGEGTRX有7735告警，经过EDGEGTRX重启，恢复正常7725时隙故障影响GP的连续性时隙故障影响GP的连续性导致的时隙分配高拒绝发现小区20216的多时隙分配拒绝率突然上升，检查告警发现GTRX〔TRX3〕的RTSL5有7725告警。而此小区的主BTS只有一个TRX。而GPRS〔EDGE〕用户的时隙占用需要具有连续性，RTSL5的故障会影响用户对分配时隙的占用。因为数据时隙的分配会优先分配5，6，7时隙。重启BCF后告警消除，多时隙分配成功率也恢复正常。7723告警，休眠小区优化日常睡眠小区监控中发现，37991小区没有任何流量，无任何信道请求信息，查看基站告警，BCCH载频有7723告警，附加字段为10，提示为由于GB口的原因造成BCCH系统信息的下发错误，查看与此小区同一NSEI下的其它小区，指标正常，因此应该是此小区与PCU间的配合出现了问题，立即调整此小区到其它NSEI下，指标恢复正常，流量正常。7745告警，小区TBF成功率低优化日常最坏小区处理中发现，小区的TBF成功率很低，为80%左右；立即查看基站运行状态，发现两块GTRX载频中TRX17745告警严重，载频工作不稳定造成TBF成功低，因此立即倒换此块GTRX到另外一块TRX上，更换之后TBF成功率恢复到99%，各项GPRS指标也恢复正常。TBF成功率降低(1)用户投诉自24日开始，上网不正常，经常掉线，接到反映之后，我们立即查看了KPI，发现3扇区从24日开启跳频之后，TBF成功率明显降低，因此立即关闭了跳频，关闭之后，指标恢复正常，回访用户也上网正常了，疑心为跳频单元单元的问题。(2)用户投诉最近上网老是掉线，经常该站的三个扇区指标，确实这几天的TBF成功率较低，流量也明显降低，查看基站也无任何告警，这三个小区共同一BCF，因此重启BCF，但TBF成功率仍然没有恢