ADA_河南EGPRS 网络优化经验分享

ADA组,河南EGPRS网络优化经验分享,目录,参数调整网元扩容GPRS无线参数规范建议典型案例,参数调整,GPRS区域原理,静态数据区域是动态数据区域的子集数据区域时隙必须是连续性的,CDEF调整,流量增加，无线充足率下降。.经过调整CDEF时隙后，无线充足率恢复正常。,流量增加,增加CDEF时隙,GAMMA调整,GAMMA参数的作用是控制手机GPRS上行发射功率。把GAMMA值调由34调到26后，TBF建立成功率明显的提升。,GAMMA调整，由34调到26,DIRE调整(1/2),DIRE从0调到1,河南EGPRS是使用分层的概念，也就是计划把GPRS和EGPRS分开在两个BTS上，和把GPRS分配到BCCH-BTS。而DIRE参数的作用就是把EGPRS用户优先分配到那个BTS上。把DIRE设成大于NBL后，就可以把EGPRS用户优先分配到NON-BCCH-BTS上。,DIRE调整(2/2),把DIRE从0调到1后:EGPRS流量提升,下行下载速率提升。PCU和EDAP拥塞的情况上升，因为增加了EGPRS流量。,MCA/MCU调整,MCA从6调成9MCU从5调成6:上传速率从37提升到40kbit/s下传速率没太大改进，因为下行比上行的要求高，需要跟多的PCU和EDAP资源。所以流量上升，各个网元的资源也要相对的跟进。,CSU调整,高数据区域升级拒绝率主要原因是由于语音区域的拥挤，话务量高。载频扩容是基本解决的方法。但是如果扩容不能行的情况下，多个同BSC的小区又有高数据区域升级拒绝率，可以考虑调CSU。BSC参数CSU的调整主要是减少SEGMENT下系统需要保持的空闲时隙。调试了CSU从4到2在到1，减少了空闲时隙，增加可用时隙数，数据区域升级拒绝率下降。,MBP调整,调整MBP从0到5后:编码MCS6到9的使用比例增加下行速率增加。-BLER提升，但是影响不明显。,TFD/TFU调整,为了把从BTS上的GPRS流量推向主BTS，从而缓解从BTS的数据拥塞情况。我们修改了从BTS的TFU2.检查有无硬件告警，检查GB/BVCI的状态是否正常；3.GPRS流量正常，少EGPRS流量，重启GTRX。4.重启BCF，对有7738(BTSWITHNOTRANSACTIONS)告警（告警原因是10nosuccessfulGPRStransactions的小区首先建议重启BCF;5.重启不能解决的调整NSEI，调整NSEI时要考虑到PCU的负荷情况和主要道路NSEI的连续性；6.如果是建有EDAP的小区，建议检查BSC侧和基站侧EDAP时隙宽度是否一致；7.对NSEI下多个小区出现休眠的情况建议切换此PCU到其他的BCSU8.一直都没有数据流量也无话音话务量，建议检查基站的硬件GTRX多个时隙出现信道激活失败告警（7725）调整NSEI，调整NSEI时要考虑到PCU的负荷情况和主要道路NSEI的连续性TRX出现7743告警，时隙7725告警倒换载频。,案例总结,检查TBF_success%指标低于95%需要检查频率规划，低于50%需要检查硬件道路测试个别涉及到的问题小区需要做检查，拥塞等问题。提高EGPRS覆盖率。开通EGPRS小区，检查BCCH-TRX。减少BSC间的小区重选；做好PCU规划。主要是控制小区的频繁重选（特出主控小区)。检查半速率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，造成无数据流量。更正后，恢复正常。,GPRS/EGPRS总流量大幅度下降,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也正常使用。,BCCH不支持EDGE的载频,第一案例：市区紫金花(CI34913)EDGE无流量日常睡眠小区的监控中，小区34913出现无EDGE流量现象，此小区的GPRS流量一直正常，查看基站无任何告警，在重启BTS，激活GENA操作后流量没有恢复。询问客户得知，在18日上午对主BTS的BCCH进行了倒换，倒换后的BCCH不支持EDGE的载频，因此立即发单将BCCH倒换到另外一块支持EDGE的载频上，EDGE流量恢复了正常。,升级拒绝失败率高,升级拒绝失败率高小区的处理在最差小区的处理中，对PCU无拥塞而小区的升级决绝失败率高的小区进行了增加数据域的处理。处理的主要方法是：对高话务的小区BTS进行增加CDED/CDEF，对话务不高的小区增加GTRX，增加CDEF.增加前后小区的对比情况如下,GTRX开启半速率,不能上网，经核查，无告警，但EDGE层GTRX开启半速率，关闭半速率GTRX，恢复正常,远端未及时修改数据,小区无流量处理日常监控中发现，小区34914无任何流量，指标上看只有上行的TBF建立与分配，但是没有流量，经查此小区为微蜂窝，频率修改后，直放站的远端未及时修改造成，在10月28日厂家修改了频点后，小区的各项KPI指标恢复正常。,7735载频故障,不能上网，经核查EDGEGTRX有7735告警，经过EDGEGTRX重启，恢复