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

i资料编码产品名称使用对象产品版本编写部门无线网络规划部资料版本V1.0GSM网规网优案例汇总（2005年第3季度）（密级：内部公开）拟制：网络规划GSM技术支持组日期：2005年10月15日审核：司法忠日期：2005年10月15日审核：日期：批准：日期：华为技术有限公司版权所有侵权必究ii目录1.某局开通半速率后TCH拥塞率（含切换）上升问题的处理............................................32.无线信道配置表中配置相同的ABIS口子时隙号导致单通和串话.................................33.因切换号码在被叫号码分析表中的业务属性配置错误导致MSC间切换失败................54.EDU通道故障引起掉话.................................................................................................65.合理提高边缘切换门限减少掉话....................................................................................76.干扰导致基站附近无法通话...........................................................................................87.动态半速率引起的外圆拥塞...........................................................................................98.修改随机接入错误门限解决用户有信号但不能打电话问题............................................99.CGI配错导致移动网用户上联通网..............................................................................1010.通过修改网优参数提高寻呼成功率的方法................................................................1111.改变单载频小区CDU连接方式增强覆盖降低掉话率。...........................................1212.小区仅配置动态PDCH导致查询信道状态时提示“设备未初始化”..........................14GSM网规网优案例汇总（2005年第3季度）内部公开2005-10-20华为机密，未经许可不得扩散第3页，共15页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后发现存在单通和串话现象。【原因分析】GSM网规网优案例汇总（2005年第3季度）内部公开2005-10-20华为机密，未经许可不得扩散第4页，共15页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=0~31,其中16时隙为7号信令时隙。）基站手工添加，无线信道配置表特意配置成下面的数据：TRX号时隙号中继电路号ABIS时隙号ABIS子时隙号。0065535255255.0165535255255.02010.03111.04210.05310.06420.07521.让两部手机锁频在此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的说话声音了。GSM网规网优案例汇总（2005年第3季度）内部公开2005-10-20华为机密，未经许可不得扩散第5页，共15页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中继电路0－》GNET板－》A用户的A接口CIC电路上行－》MSC转发此语言数据－》B用户的A口CIC电路下行－》GNET－》B用户的BS1接口中继电路1－》Abis时隙号＝1和Abis子时隙号＝1的下行－》基站交换网板－》TRX0的3号时隙调制下行发射到B用户手机，最后出现串话，且相互通话的现象了。5、最后核实到如下结论：TMU使用SD539芯片实现Abis《－》DBus的信息交换。芯片可以实现一个ABIS时隙到多个DBUS时隙的下行数据交换。但是多个DBUS时隙到一个ABIS时隙的上行数据交换是不行的，上行交换时只有无线信道配置表中重复数据的最后一条设置才生效。【建议与总结】1、在配置手工基站扩容的TRX，配置无线信道表一定要十分细心，避免出现单通和串话，甚至RSL链路断链的现象；2、TMU使用SD539芯片实现Abis《－》DBus的信息交换。芯片可以实现一个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间切换号码兼容性问题；GSM网规网优案例汇总（2005年第3季度）内部公开2005-10-20华为机密，未经许可不得扩散第6页，共15页5.MSCB下发给BSC2的handoverrequest中可能携带多个SPEECHVERSION，可能BSC没有选择合适的SPEECHVERSION，导致切换失败；6.MSC中被叫号码分析表中对漫游号码分析的“业务属性”配置错误。【处理过程】1、检查A和B小区的相邻关系，检查外部小区描述表BCCH、NCC、BCC、CGI结果正确；2、因为手机可以在A和B小区下都可以上网，且主被叫正常，因此MSC中CGI配置正确；3、检查MSCA中增加LAI＝460005000，和MSCB中增加LAI＝460004779时选择位置区类型＝“相邻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收到HORequest后向MSCB回送HandoverRequestAcknowledge，MSCA没有给MSCB发送IAM消息而是紧接着向BSC1下发HANDOVERRQDREJECT，其原因值为设备故障。随后，MSCB向BSC2下发CLEARCOMMAND，其原因值为设备故障；7、于是断定是MSCA在获取到切换号码（PREPAREHOACK）后拒绝BSC1发起的切换请求，通过查询MSCB中被叫号码分析表中对漫游号码分析的“业务属性”配置错误，将“本地”修