GSM网规网优案例汇总专题(2005年第3季度)-20051015-A-1.0.doc

资料编码产品名称使用对象产品版本编写部门无线网络规划部资料版本V1.0GSM网规网优案例汇总（2005年第3季度）（密级：内部公开）拟 制：网络规划GSM技术支持组日 期：2005年10月15日审 核：司法忠日 期：2005年10月15日审 核：日 期：批 准：日 期：华 为 技 术 有 限 公 司版权所有 侵权必究目 录1.某局开通半速率后TCH拥塞率（含切换）上升问题的处理32.无线信道配置表中配置相同的ABIS口子时隙号导致单通和串话33.因切换号码在被叫号码分析表中的业务属性配置错误导致MSC间切换失败54.EDU通道故障引起掉话65.合理提高边缘切换门限减少掉话76.干扰导致基站附近无法通话77.动态半速率引起的外圆拥塞88.修改随机接入错误门限解决用户有信号但不能打电话问题99.CGI配错导致移动网用户上联通网1010.通过修改网优参数提高寻呼成功率的方法1011.改变单载频小区CDU连接方式增强覆盖降低掉话率。1112.小区仅配置动态PDCH导致查询信道状态时提示“设备未初始化”13iiiGSM网规网优案例汇总（2005年第3季度）内部公开1. 某局开通半速率后TCH拥塞率（含切换）上升问题的处理【现象描述】某局网络扩容后发现部分小区有拥塞现象，在客户的要求下，华为网优工程师对华为3个BSC内的所有基站开通半速率功能，其后观察话统指标，发现全网TCH拥塞率（含切换）不但没有降低反而升高了10左右。【原因分析】1、观察话统指标发现TCH拥塞率高的小区多是单载频小区；2、拥塞原因为占用遇全忙；3、观察这些目标小区占用TCH信道请求次数指标，发现【只选全速率TCH信道请求次数】占TCH信道请求总次数50以上，而且成功次数极少；4、检查参数设置，发现【预留全速率TCH最小数目】设置为1，【TCH速率调整业务量忙门限（）】设置为15；5、查看问题小区忙时信道状态，发现小区5个TCH信道中有4个都已经转换成半速率信道，但大部分时间处于Idle状态，剩下仅有的一个全速率TCH信道，大部分时间在Using中。综上可知，这些小区覆盖范围内只支持全速率的手机用户较多，造成全速率TCH信道遇全忙次数多，拥塞率上升。【处理过程】1、更改【TCH速率调整业务量忙门限（）】为50；2、更改【预留全速率TCH最小数目】为3；3、更改【TCH恢复最短时间（秒）】为60；4、更改参数后观察话统，发现TCH拥塞率降到0.2左右，拥塞问题解决。【建议与总结】建议小区在开通半速率时慎重配置【预留全速率TCH最小数目】、【TCH速率调整业务量忙门限（）】以及【TCH恢复最短时间（秒）】等半速率相关参数。2. 无线信道配置表中配置相同的ABIS口子时隙号导致单通和串话【现象描述】某个基站下扩容一个TRX后发现存在单通和串话现象。【原因分析】1、TMU故障；2、TRX故障，DBUS总线故障；3、MSC交换机引入的串话和单通现象；4、分析故障出现前后的操作，可以基本断定单通和串话的出现是由于新增TRX导致。【处理过程】1、检查数据配置台的无线信道配置表发现，此TRX8个时隙所占ABIS口时隙是2个64k时隙，但是后面对应的abis子时隙号都为0，因此就动态配置中先删除TRX，再增加此TRX，最后发现是手工配置的基站，可以断定以前扩容TRX时在修改无线信道配置时疏忽了ABIS口子时隙的配置，导致默认都为0，这次重新增加TRX后，问题解决。2、为了模拟出现的故障现象，了解无线信道配置表对TMU的SD539芯片交换机制的影响，就在通过如下组网和数据配置来重新现象：在机房调测BSC中将1个BTS3001C基站挂在1模块0组BIE（15:1方式下），占用0号端口，BSC只有1个模块，1条N0.7LINK，1条A口链路，（CIC=031,其中16时隙为7号信令时隙。）基站手工添加，无线信道配置表特意配置成下面的数据：TRX号 时隙号 中继电路号 ABIS时隙号 ABIS子时隙号。0 0 65535 255 255.0 1 65535 255 255.0 2 0 1 0.0 3 1 1 1.0 4 2 1 0.0 5 3 1 0.0 6 4 2 0.0 7 5 2 1.让两部手机锁频在此BTS3001C基站下，A呼叫B，让A主叫占用了TRX0的2时隙和B被叫占用了TRX0的3时隙想进行正常通话，但是发现单通现象：即主叫的A用户只能听到被叫B用户声音，被叫B听不到主叫A的声音，（这个现象很奇怪，因为在无线信道配置表中TRX0的2、3时隙数据配置是没有问题的！按理是可以正常通话的才是。）于是我们又让第三部手机C打117接入网络（占用了TRX0的4时隙），发现C听不见117报时，倒是单方面听到了B的说话声音很清楚（此时B没有听见任何人的话音）；然后我们又接入第4部手机D拨117占用在TRX0的5时隙上，奇迹发现：D能听到B的声音，而且B此时居然也可以听到D的声音，这样一来成了B和D能正常通话，故障重现了！3、分析对ABIS下行方向：基站交换网板从0号端口RX收到ABIS口的1时隙0号子时隙有话音数据，就开始查无线信道配置表中的Abis时隙号1和Abis子时隙号0是对应哪个TRX的哪个时隙来发射空口下行话音，按上面的无线信道配置表数据，可以查到TRX0的2、4、5时隙都是和Abis时隙号1和Abis子时隙号0对应关系，所以就会导致基站交换网板把Abis时隙号1和Abis子时隙号0上的话音（是B对A的说话声）分别复制转发到TRX的2、4、5时隙，即前面A、C、D都能收听到B的说话声音了。4、对B和D能正常通话，分析如下：按照无线信道配置表所描述的把TRX0的5时隙上行话音被基站网板交换到Abis时隙号1和Abis子时隙号0上行中了，（SD539芯片特性决定在查询无线信道配置表时发现：上行对Abis时隙号1和Abis子时隙号0有3条重复数据，软件只允许把TRX的5时隙的DBUS数据交换到Abis时隙号1和Abis子时隙号0中。）导致A用户占在TRX0的2时隙上行话音数据包无法插入Abis时隙号1和Abis子时隙号0上行，即：D用户上行语音通过A用户的BS1中继电路0GNET板A用户的A接口CIC电路上行MSC转发此语言数据B用户的A口CIC电路下行GNETB用户的BS1接口中继电路1Abis时隙号1和Abis子时隙号1的下行基站交换网板TRX0的3号时隙调制下行发射到B用户手机，最后出现串话，且相互通话的现象了。5、最后核实到如下结论：TMU使用SD539芯片实现AbisDBus的信息交换。芯片可以实现一个ABIS时隙到多个DBUS时隙的下行数据交换。但是多个DBUS时隙到一个ABIS时隙的上行数据交换是不行的，上行交换时只有无线信道配置表中重复数据的最后一条设置才生效。【建议与总结】1、在配置手工基站扩容的TRX，配置无线信道表一定要十分细心，避免出现单通和串话，甚至RSL链路断链的现象；2、TMU使用SD539芯片实现AbisDBus的信息交换。芯片可以实现一个ABIS时隙到多个DBUS时隙的下行数据交换。但是多个DBUS时隙到一个ABIS时隙的上行数据交换是不行的，上行交换时只有无线信道配置表中重复数据的最后一条设置才生效。3. 因切换号码在被叫号码分析表中的业务属性配置错误导致MSC间切换失败【现象描述】组网如下：某局有两个MSC，其中一个MSCA为MSC60，下带BSC1的A小区BCCH=28，BSIC=72,CGI=4600047792F12;另有一个MSCB为G9，下带BSC2的B小区BCCH=15，BSIC=60,CGI=4600050002850,A和B小区都做了外部相邻小区关系，在测试局间切换时发现，手机可以从B小区局间切换到A小区，但是从A小区发起出BSC切换到B小区时失败。【原因分析】1. A和B小区的外部相邻小区配置错误，比如：BCCH、NCC、BCC、CGI；2. MSC中增加CGI出错导致切换失败；3. MSC中增加LAI时选择位置区类型时未选择“相邻VLR”；4. 切换号码格式问题，导致出现MSC间切换号码兼容性问题；5. MSCB下发给BSC2的handoverrequest中可能携带多个SPEECHVERSION，可能BSC没有选择合适的SPEECHVERSION，导致切换失败；6. MSC中被叫号码分析表中对漫游号码分析的“业务属性”配置错误。【处理过程】1、检查A和B小区的相邻关系，检查外部小区描述表BCCH、NCC、BCC、CGI结果正确；2、因为手机可以在A和B小区下都可以上网，且主被叫正常，因此MSC中CGI配置正确；3、检查MSCA中增加LAI460005000，和MSCB中增加LAI460004779时选择位置区类型“相邻VLR”正确无误，同时LAI归属的MSC信令点也正确无误；4、在A切换到B小区时跟踪MSCA的E接口发现已经获取到切换号码且是带86的，因此不存在MSC间对切换号码兼容性问题；5、同时在BSC2跟踪入切换失败时的A接口消息发现，MSCB已经给BSC2下发了handoverrequest同时BSC2也已经回复了handoverrequestacknowledge且BSC2和MSCB的A接口为PHASE2，不存在携带多个语言版本的问题；6、在目标BSC2跟踪A接口消息发现，BSC2收到HO Request后向MSCB回送HandoverRequestAcknowledge，MSCA没有给MSC B发送IAM消息而是紧接着向BSC1 下发HANDOVERRQDREJECT，其原因值为设备故障。随后，MSCB向 BSC2 下发CLEARCOMMAND，其原因值为设备故障；7、于是断定是MSCA在获取到切换号码（PREPARE HO ACK）后拒绝BSC1发起的切换请求，通过查询MSCB中被叫号码分析表中对漫游号码分析的“业务属性”配置错误，将“本地”修改为“移动网本地局”后，A小区通过局间切换到B小区成功，问题得到解决！【建议与总结】对局间切换失败问题要充分利用MSC上的用户接口跟踪功能，把E接口和A接口的消息要跟踪完全，有利于分析问题。4. EDU通道故障引起掉话【现象描述】华为BTS312基站S224配置，1小区话务量4.8erl，忙时掉话13次以上。【原因分析】检查基站硬件无告警。检查小区性能话统，发现小区TCH占用失败较多，30次以上。入小区切换成功率不高，小于83。表明小区的TCH占用异常，导致切换差、掉话等。检查小区干扰带正常，小区周围频点规划无同邻频现象。进一步检查载频级话统TCH信道分配性能测量，发现TCH占用失败和掉话集中在载频1。载频1的上下行平衡话统可以看出载频下行弱于上行，而小区内载频0上行弱于下行，且载频0的测量报告数远大于载频1。由此确定载频1有问题。基站现场1小区锁频测试发现占到TCH载频1时，接收电平比占用主BCCH载频0时电平低7dB。对调两个载频天馈线、问题没有解决。对调两个载频到EDU的发射端口后测试，发现载频1的接收电平高于载频0的接收电平。由此确定EDU的一个通道损耗较大。更换EDU单板后，现场测试正常。检查话统中掉话次数减少到3次以下，各项指标正常。【处理过程】1、 检查硬件告警； 2、 检查小区话统； 3、 检查小区各载频话统；4、 现场锁频测试；5、 调整连线；6、 更换EDU；7、 检查话统确认问题解决。【建议与总结】EDU单个通道损耗大而不告警的故障较隐蔽，有时小区掉话不高，可以通过小区内两个载频板话务不均衡来定位。5. 合理提高边缘切换门限减少掉话【现象描述】华为BSC，下挂7个模块，122个基站，主要覆盖区域在县城和乡村。小区上行链路边缘切换门限15，下行链路边缘切换门限20。话务掉话比80到90。【原因分析】检查小区掉话性能测量，发现存在一些小区TCH掉话时平均上行电平为16-19，平均下行电平为19-24。为了减少不切换引起的边缘掉话。我们选出70个掉话时电平较低的小区，把上行链路边缘切换门限改为18，下行链路边缘切换门限改为21。边缘切换统计时间改为4，边缘切换持续时间改为3。之后几天观察话统发现，70个小区的掉话次数由260次减少到170次。整个BSC的话务掉话比达到96。BSC内小区间切换次数由25800多次上升到27000次，切换成功率基本不变。【处理过程】1、分析掉话性能话统； 2、筛选掉话时电平较低的小区； 3、修改小区切换参数； 4、检查话统确认掉话次数减少，话务掉话比升高。【建议与总结】有些默认的切换参数需要根据实际情况尝试修改。6. 干扰导致基站附近无法通话【现象描述】某局接用户投诉，在A基站附近手机无信号或者信号很差，无法打电话。此基站在用户投诉前一天，刚刚和另外一个基站互换。【原因分析】导致无信号或者无法通话的原因很多：1、基站超忙，导致手机无法位置更新而掉网；2、基站单板存在问题，例如TRX无功率发射出去；3、基站附近存在严重的干扰，导致DSC减小到零而掉网；4、BSC数据配置问题，例如CGI错误等。【处理过程】此基站是由其他基站搬迁过来的，推测和这次搬迁基站有关系，经过现场测试，在基站附近没有信号，也打不了电话。数据检查和硬件检查，均无错误。网优工程师在机房观察基站运行状态和话务统计，发现此基站有话务量，而且存在呼叫占用成功次数和切换占用成功次数。推测可能是在远处可以打电话，基站工程师到200米的远处后，果然可以打通电话。于是基站工程师从远处拨通电话后，向基站方向走，到某个距离后，突然掉话，没信号。由此可以判断，基站设备是没有问题的。后来，了解到此地方原来用的是E厂家的移动通信车，在华为基站搬迁到这里的时候，移动通信车只是简单的断掉了A接口，而BSC和BTS还在运行,和我们的基站同频，由于移动通信车没有了天馈系统，所以只对华为基站在近处造成严重干扰，导致手机无法上网，而在远处通话正常。关掉该移动通信车后，问题解决。【建议与总结】在处理问题的过程中，一定要了解尽可能多的现场信息，从细节中发现问题。如基站搬迁，改造前后周围的情况等。7. 动态半速率引起的外圆拥塞【现象描述】华为BSS系统，一个多模块BSC，下带BTS312基站，版本为G3OMC32.0A501.06.1120A。用户将此BSC下的几个话务量比较大的BTS312基站开通半速率后，发现几个基站的拥塞率在忙时不降反而上升了。这几个开通半速率的基站是S333或S222配置，覆盖U国西部乡村地区，采用同心圆，外圆加PBU。【原因分析】1、小区开通半速率以后，按照常理TCH拥塞率应该降低。2、因为用户修改半速率前后没有做其它任何操作，初步怀疑是数据配置上出了问题。检查用户修改的半速率相关的数据，发现用户将 IdleThrshforTCH/FPriority（优选全速率TCH空闲门限）设置为4；TCHrateadjusttrafficThrsh（TCH速率调整业务量忙门限(%)）设置为80。3、通过话务统计查看小区的拥塞次数，发现拥塞次数基本都在全速率TCH上发生的，半速率TCH/H基本没有拥塞。而且这些拥塞是发生在外圆（Underlaidsubcell），但是外圆的话务量并不高，通过ErlangB来算，外圆的信道支撑外圆的话务是没问题的，然而拥塞却发生了。通过观察BTS的信道，根据系统配置的同心圆参数和MS接入时的电平、TA等情况，当话务达到TCH/F向TCH/H转换门限时，MS经常优先接入外圆信道。这样很容易出现当话务量达到一定值时，整个BCCH（外圆）的TCH/F全部转化TCH/H的情况。此时如果在外圆接入范围有只支持全速率的MS申请全速率信道，肯定系统无法满足，造成没有信道可用，以至于在调整为半速率后，整个小区的拥塞不降反升。【处理过程】1、把半速率的动态调整功能改为静态配置，平均每个载波上配置3个半速率。2、修改完后观察话务统计，(CallBlockingRate)(BH)降低到00.4，指标正常。【建议与总结】说明：配置成静态的TCH要定期观察话务情况，如果话务有所增加，再次出现拥塞的话需要继续增加静态的TCH/H信道个数，平衡内外圆的话务。8. 修改随机接入错误门限解决用户有信号但不能打电话问题【现象描述】某地区基站用户反映在室内有2-3格信号，但既打不出电话，电话也不能呼入。至现场实测后发现，用户反映的室内场强约为-92dBm左右，但用户拔打电话很难打，经常听“嘟嘟”音，做被叫时对方听到“用户暂时无法接通”的录音通知。【原因分析】1、首先分析其干扰情况，分析其OMC统计数据的干扰带情况正常，排除受干扰的可能。2、重新规划频点后问题依旧。3、影响上行接入的参数 “RACH最小接入电平” 和“随机接入错误门限”设置不合理；【处理过程】利用网络优化进行拨打测试，同时对用户信令进行跟踪，发现上行信号电平较低，为-100dBm左右，而且接收有误码，FER最高达到50，能够接通的电话质量也达6级。基站上下行明显不平衡。观察地形，基站与问题出现地点间有较高建筑物阻挡。将“RACH最小接入电平”由5改为1 和“随机接入错误门限” 由200改为180。再进行拨打测试，问题解决。【建议与总结】“RACH最小接入电平”参数表示系统判断MS随机接入的电平阀值。当接收到的随机接入突发时隙的电平大于门限时，BTS才认为这个时隙有接入请求，并且与“随机接入错误门限”一起确定该RACH接入是否有效。本参数需要结合基站实际灵敏度以及手机最低接入电平进行设置，避免有信号打不了电话的现象。“随机接入错误门限”参数的调整是通过判断训练序列(41bit)的相关性来判断所收到的信号是否为MS的随机接入信号（同时用来计算TA值）。本参数规定了训练序列的相关性。本参数设置过小，对随机接入信号的错误允许程度高，MS随机接入容易，但误报率较高；设置过大，则MS误报率低，但正常接入难以上报。本案例中因上行有一定误码，基站“随机接入错误门限”设置较高，使基站对手机的接入信息不予识别。9. CGI配错导致移动网用户上联通网【现象描述】某地移动公司向联通公司投诉，在T村联通基站附近移动网用户经常上到联通网上。T村联通基站为华为BTS312基站，挂在NT交换机下，基站版本为06.1130。【告警信息】小区有无线链路提示告警，告警的支路号为1，告警解释为：无线信道的异常释放比例超过告警门限。【原因分析】1、当手机不在归属网络(HPLMN)的覆盖区时，手机会进行拜访网络(VPLMN)的选择，故怀疑在T村联通基站附近移动没有覆盖到，但据移动工程师反馈在T村联通基站附近，移动的信号为80dBm左右，因此可以排除此原因；2、怀疑可能是个别手机或SIM卡故障造成，移动工程师在现场换手机和SIM卡测试，仍出现此问题，可以排除手机或SIM卡的问题；3、移动工程师在现场用测试手机换上联通的SIM卡，发现T村-1在70dBm时，可以看到其频点，但解不出其他信息，并无法拨出，而T村-2和T村-3正常，可以排除TMU板问题；4、登记T村信道分配性能测量话统，发现T村-1在15分钟里占用SDCCH达1000多次，且全部是位置更新引起。其他2个小区只有60几次SDCCH占用请求，TCH占用正常，据客户工程师反馈T村周围并不是很繁华，也不在公路附近，因此T村-1在15分钟里有多达1000多次的位置更新不大可能，怀疑T村-1的CGI数据可能有问题。【处理过程】检查T村-1小区描述数据，发现T村-1CGI错配为4600000010001，据查前段时间BSC2有一批基站割接到BSC3下，T村是其中之一，可能是督导在做数据时不仔细所致，修改后经现场拨测正常，告警消失，观察话统，T村-1SDCCH占用降为20几次，TCH占用正常。至此问题解决。10. 通过修改网优参数提高寻呼成功率的方法【现象描述】某局华为BSS设备下挂在S厂家MSC下，从交换机侧统计寻呼成功率在84%85%左右，而考核指标是90%，故需对寻呼成功率这个指标进行优化。【原因分析】寻呼成功率是一个系统级问题，涉及MSC、BSC、BTS、MS。其中任何一环节发生异常，都可能会影响到寻呼成功率。影响MSC寻呼成功率的因素主要有：A. MSC的寻呼策略：需要MSC侧的寻呼方式、寻呼次数、寻呼时间间隔设置合理。 B. 参数设置情况：1、需要MSC侧和BSC侧与寻呼相关的参数设置合理。例如：MSC和BSC位置更新周期时间、MSC和BSC寻呼定时器设置、MSC和BSC对于CGI数据配置正确。2、MSC侧T3113参数作用：寻呼等待定时器启动：MSC向BSC发送PAGINGREQUEST消息停止：收到BSC发来的PAGINGRESPONE消息超时：定时器超时后，MSC重发寻呼消息，并重新启动T3113定时器；重发次数由网络侧自定义。 C. 信令拥塞会影响寻呼成功率：如果出现信令信道拥塞，就可能造成寻呼消息丢失，直接影响寻呼成功率。例如：A口信令链路拥塞、PCH拥塞、SDCCH拥塞都会导致寻呼成功率下降。 D. 位置区划分的合理性、基站覆盖情况、上下行平衡情况：位置区划分不合理、基站覆盖不理想，也会影响寻呼成功率。另外，如果上下行信号不平衡，可能出现上行或下行信号很差，导致寻呼不到。 E. 手机质量问题：有些手机由于接收灵敏度问题或者其它质量问题，在边缘覆盖区也会出现寻呼不到的情况，造成整体寻呼成功率下降。F. 该地区三面被其它省环抱，不同地区之间周期性位置更新时间不一致，也会造成寻呼不到用户，导致寻呼成功率低。 所以解决寻呼成功率低的问题，要综合考虑上述因素。【处理过程】优化主要采取的方法： A、 RACH最小接入电平参数调整：通过降低RACH最小接入电平，提高上行接收灵敏度来提高寻呼成功率。由于在寻呼成功率与掉话率指标之间的网优参数是互相制约的，通过修改此网优参数可以改善寻呼成功率指标，需权衡掉话率和立即指配成功率等指标。B、 增加MS最大重发次数。由于目前华为BSC几乎没有出现拥塞情况，可以将系统消息数据表中的“MS最大重发次数”由4次修改为7次，需关注SDCCH的拥塞率变化。C、 打开基站寻呼重发功能，将小区属性表中的“寻呼次数”由1次改为4次。通过上述方法，将寻呼成功率优化到91%左右，达到该局的要求。【建议与总结】无。11. 改变单载频小区CDU连接方式增强覆盖降低掉话率。【现象描述】华为BTS 3.0基站配置为O1，使用CDU方式。基站为山区广覆盖，掉话一直较高。【原因分析】基站掉话一般有以下原因：1、干扰原因，包括网内的频率规划、互调、杂散干扰和网外干扰造成的掉话；2、数据配置不合理造成的掉话； 3、基站硬件问题，包括载频、时钟、CDU以及基站工程质量造成的掉话；4、覆盖不好造成的掉话；5、传输问题造成的掉话；6、其它原因造成的掉话。【处理过程】1、 检查基站告警，未发现异常告警； 2、 检查基