GSM网优案例总结

1、 GSM网优案例小结移动某地市有一基站下的二小区SDCCH掉话率过高，15分钟达150次之多且无拥塞，TCH掉话率正常。 告警信息：无。 原因分析：如下几种情况都会导致SDCCH掉话：1、入局SDCCH切换HO_DETECT消息非法；2、入局SDCCH切换HO_CMP消息非法；3、入局SDCCH切换发送HO_CMP消息失败；4、TN_WAIT_HO_DETECT、TN_WAIT_HO_CMP（SDCCH切换）超时；5、TN_WAIT_INTER_HO_CMP（SDCCH切换）超时；6、TN_T8（出BSC切换完成）超时；7、由其它多种原因导致的内部清除。但导致SDCCH掉话

2、率过高原因大致有四点：1、拥塞；2、干扰；3、设备硬件故障；4、参数设置不合理。  处理过程：1、查看数据配置，未发现异常。2、将SDCCH信道换到其他时隙以及其他载频，现象依旧。3、到现场路测，发现在二、三小区交界处经常占有一小区频点（与一小区天线为背向），塔工排查天馈线，发现一、二小区天馈线接错，将馈线调整后，掉话次数为10次左右小时，最好时为6次小时，正常。 建议与总结：处理这类问题时，现场路测很重要。关键字：半速率 TCH拥塞 现象描述：某局扩容工程，首次使用华为设备，“插花”于N设备商网络中，华为设备皆采用BTS312基站，合分路单元采用EDU，扩容后发

3、现部分小区有拥塞现象，于是在客户的强烈要求下，华为网优工程师对华为3个BSC内的所有基站开通半速率功能，其后观察话统指标，发现全网TCH拥塞率（含切换）不但没有降低反而升高了10左右。 告警信息：无。 原因分析：1、观察话统指标发现TCH拥塞率高的小区多是单载频小区；2、拥塞原因为占用遇全忙；3、观察这些目标小区占用TCH信道请求次数指标，发现【只选全速率TCH信道请求次数】占TCH信道请求总次 数50以上，而且成功次数极少；4、又检查参数设置，发现【预留全速率TCH最小数目】设置为"1"，【TCH速率调整业务量忙门限（）】设置为15；5、于是

4、忙时查看这些问题小区信道状态发现问题小区的5个TCH信道中有4个都已经转换成半速率信道，但大部分时间处于Idle状态，剩下仅有的一个全速率TCH信道，大部分时间在Using中。于是可以判断出这些小区是应为在覆盖范围内只支持全速率手机用户比例大，占用全速率TCH信道遇全忙次数多，造成的拥塞！ 处理过程：1、更改【TCH速率调整业务量忙门限（）】为50；2、更改【预留全速率TCH最小数目】为3；3、更改【TCH恢复最短时间（秒）】为60；4、更改参数后观察话统发现TCH拥塞率降到0.2左右，拥塞问题解决！ 建议与总结：建议小区在开通半速率时慎重配置【预留全速率TCH最小数目】、

5、【TCH速率调整业务量忙门限（）】以及【TCH恢复最短时间（秒）】等半速率相关参数！ 现象描述：某地联通将S厂家基站替换为华为BTS30基站后话务量降低，基站话务量从5ERL降低到3左右。  告警信息：无。  原因分析：话务量降低一般有一下原因： 1、载频性能问题，导致覆盖范围减小，话务量降低；2、天馈性能故障，导致覆盖范围减小，话务量降低；3、参数设置不当、导致接入困难，影响用户接入；4、用户的变化导致话务量降低；5、周围基站分流话务量，导致话务量减少。  处理过程：1、检查基站告警，无TRX、驻波比、时钟等异常告警。 2、基站上行RACH最小接入电平

6、设置为12，修改为0后话务量没有增加。 3、测试基站驻波比，驻波比在1.2左右。 4、测试载频功率，载频功率正常。 5、对基站进行路测，和搬迁路测前对比，基站覆盖与替换前一致。 6、检查周围基站的话务量，周围基站话务量没有明显增加。    由于基站为局方自行替换，且投诉时距基站搬迁已经有1个多月，无法了解基站替换时的情况，和替换前后的具体话务对比。在仔细了解周围情况后分析有以下原因： 1、基站处于某交易市场附近，市场具有一定的季节性，造成了话务量的变动。 2、由于搬迁后基站天馈存在问题，曾有一定的用户投诉，造成部分用户的流失，导致话务量降低。  

7、;                     建议与总结：在替换前要做好基站的路测和话务统计工作，搬迁后对话务量变化及时进行分析处理。  现象描述：华为BSC，下挂7个模块，122个基站，主要覆盖区域在县城和乡村。小区上行链路边缘切换门限 15 ，下行链路边缘切换门限 20。话务掉话比80到90。  告警信息：无。  原因分析：检查小区掉话

8、性能测量，发现存在一些小区TCH掉话时平均上行电平为16-19，平均下行电平为19-24。为了减少不切换引起的边缘掉话。我们选出70个掉话时电平较低的小区，把上行链路边缘切换门限改为18，下行链路边缘切换门限改为21。边缘切换统计时间改为4，边缘切换持续时间改为3。之后几天观察话统发现，70个小区的掉话次数由260次减少到170次。整个BSC的话务掉话比达到96。BSC内小区间切换次数由25800多次上升到27000次，切换成功率基本不变。  处理过程：1、分析掉话性能话统； 2、筛选掉话时电平较低的小区； 3、修改小区切换参数； 4、检查话统确认掉话次数减少，话务掉话比升高。 &#

9、160;建议与总结：有些默认的切换参数需要根据实际情况尝试修改。 现象描述：某联通公司接用户投诉，在A基站附近手机无信号或者信号很差，无法打电话。此基站在用户投诉前一天，刚刚和另外一个基站互换，互换后，此基站配置为：BTS30 O1。  告警信息：无。  原因分析：导致无信号或者无法通话的原因很多：1、基站超忙，SDCCH和TCH严重拥塞，导致手机无法位置更新； 2、基站单板存在问题，例如TRX无功率发射出去；3、基站附近存在严重的干扰，导致DSC减小到零而掉网；4、BSC数据配置问题，例如CGI错误等。  处理过程：由于通常用户投诉不太准确，而且此基站

10、是由其他基站搬迁过来的，肯定和这次搬迁基站有关系，所以基站工程师和联通员工一起到现场测试。到现场确实如用户投诉，在基站附近的一个厂子里面没有信号，当然也打不了电话。网优工程师在机房检查数据，最后确定数据没有错误，基站工程师在现场检查硬件也没发现问题。但网优工程师在机房观察基站运行状态和话务统计后，发现此基站有话务量，而且存在呼叫占用成功次数和切换占用成功次数。推测可能是在远处可以打电话，基站工程师到200米的远处后，果然可以打通电话。于是基站工程师从远处拨通电话后，向基站方向走，到某个距离后，突然掉话，没信号。由此可以判断，基站设备是没有问题的。由于基站督导没有SAGEM测试手机，而无法判断是

11、否存在DSC逐步减小的情况。计划第二天调整天线和用SAGEM手机测试空闲态参数的变化，就在要离开基站的时候，了解到此地方原来用的是E厂家的移动通信车，而此通信车是一个简单的BSS系统，包括BSC和BTS，在华为基站搬迁到这里的时候，移动通信车只是简单的断掉了A接口，而BSC和BTS还在运行。我们的基站搬迁过来后，沿用老的频率计划。移动通信车还以同样的频率发射功率，由于移动通信车没有了天馈系统，所以只对对华为基站在近处造成严重干扰，导致手机无法上网，而在远处通话正常。关掉该移动通信车后，问题解决。  建议与总结：在处理问题的过程中，一定要了解尽可能多的现场信息，从细节中发现问题。比如：

12、基站搬迁，改造前后周围的情况等。  现象描述：某地区基站用户反映在室内有2-3格信号，但既打不出电话，电话也不能呼入。 至现场实测后发现，用户反映的室内场强约为-92dbm左右，但用户拔打电话很难打，经常听“嘟嘟”音，打进时听到“用户暂时无法接通”的录音通知。   告警信息：无。  原因分析：1、首先分析其干扰情况，分析其OMC统计数据的干扰带情况：干扰带1=0.03 干扰带2=0 干扰带3=0 干扰带4=0。排除受干扰的可能。2、重新规划频点后亦不能解决问题。3、于是对网优数据中的“最低允许接入电平”和“RACH

13、忙门限”参数进行检查。查看该两项数据，“最低允许接入电平”为8，比较正常，而“RACH忙门限”参数设置为12，将其改为8后，再拨打电话，问题仍未得到解决。  处理过程：利用网络优化进行拨打测试，同时对用户信令进行跟踪，发现上行信号电平较低，为-100dbm左右，而且接收有误码，FER最高达到50，能够接通的电话质量也达6级。基站上下行明显不平衡。观察地形，基站与问题出现地点间有较高建筑物阻挡。于是将该基站的“随机接入错误门限”由200改为160。再进行拨打测试，问题解决。  建议与总结：“随机接入错误门限”参数的调整是通过判断训练序列(41bit)的相关性来判断所收到的信号

14、是否为MS的随机接入信号（同时用来计算TA值）。本参数规定了训练序列的相关性。本参数设置过小，对随机接入信号的错误允许程度高，MS随机接入容易，但误报率较高；设置过大，则MS误报率低，但正常接入难以上报。本案例中因上行有一定误码，基站“随机接入错误门限”设置较高，使基站对手机的接入信息不予识别。  现象描述：某局用户投诉在一郊区基站覆盖处信号经常波动，手机经常在室内无故脱网。跟随局方优化工程师到现场实地测试，发现确有用户反映的现象。测试手机可以测到该站1、2小区信号，两小区电平值都在-87dBm，两小区经常发生重选，但不影响通话。进入室内时，电平值跌至-100dBm左右，一段时间后手

15、机脱网。  告警信息：无。  原因分析：1、基站硬件故障或手机问题维护台查看基站无告警信息，且在室外时通话都正常。用测试手机在室内测试时也会发生脱网。 2、干扰造成系统内或系统外有强干扰，造成手机脱网。查看话统数据中干扰带情况，全部落在干扰带一中，现场实际扫频也未发现干扰。室外通话质量良好。 3、数据配置问题。 1）MSC漏做小区CGI数据，导致用户可以通过切换和小区重选到该小区，但位置更新后被拒绝导致脱网。但与MSC核对数据后两边CGI数据一致。 2）检查影响手机接入的参数MS最小接收信号等级、RACH最小接入电平等参数，发现MS最小接收信号等级设置为12，参数设置可能过

16、大。该参数为了避免移动台在接收信号电平很低的情况下接入系统（接入后的通信质量往往无法保证正常的通信过程），而无法提供用户满意的通信质量且无谓的浪费网络的无线资源，在GSM系统中规定，移动台需接入网络时，其接收电平必须大于一个门限电平，即移动台允许接入的最小接收电平，否则移动台将无法接入。即当服务小区电平低于-98dBm时手机就不允许接入网络，而当前服务小区已经为-100dBm，C1值小于0发生小区重选，但邻区C1值也低于门限，重选失败因而会发生手机脱网。指导机房修改MS最小接收信号等级为8后，用户投诉基本解决。  处理过程：1、经过查看分析告警和话统，以及现场拨测扫频测试，排除硬件故

17、障和干扰问题。 2、与MSC侧核对CGI数据，两边数据一致，不是由于MSC漏做CGI造成。 3、考虑到是接入类问题，分析小区数据发现MS最小接收信号等级的值设置过大，将参数调小后问题解决。  建议与总结：网络优化时，修改MS最小接收信号等级、RACH最小接入电平等参数降低掉话问题的同时一定要考虑到对覆盖的影响。现象描述：某局BSS设备下挂在S厂家MSC下，从交换机侧统计寻呼成功率在84%85%左右，而考核指标是90%，故需对寻呼成功率这个指标进行优化。  告警信息：BSS设备上无任何告警。  原因分析：寻呼成功率是一个系统级的问题，涉及MSC、BSC、BTS、MS

18、。其中任何一环节发生异常，都可能会影响到寻呼成功率。影响MSC寻呼成功率的因素主要有：A、 MSC的寻呼策略：需要MSC侧的寻呼方式、寻呼次数、寻呼时间间隔设置合理。 B、 参数设置情况：1、需要MSC侧和BSC侧与寻呼相关的参数设置合理。例如：MSC和BSC位置更新周期时间、MSC和BSC寻呼定时器设置、MSC和BSC对于CGI数据配置正确。2、MSC侧T3113参数作用：寻呼等待定时器启动：MSC向BSC发送PAGING REQUEST消息停止：收到BSC发来的PAGING RESPONE消息超时：定时器超时后，MSC重发寻呼消息，并重新启动T3113定时器；重发次数由

19、网络侧自定义。 C、 信令拥塞会影响寻呼成功率：如果出现信令信道拥塞，就可能造成寻呼消息丢失，直接影响寻呼成功率。例如：A口信令链路拥塞、PCH拥塞、SDCCH拥塞都会导致寻呼成功率下降。 D、位置区划分的合理性、基站覆盖情况、上下行平衡情况：位置区划分不合理、基站覆盖不理想，也会影响寻呼成功率。另外，如果上下行信号不平衡，可能出现上行或下行信号很差，导致寻呼不到。 E、手机质量问题：有些手机由于接收灵敏度问题或者其它质量问题，在边缘覆盖区也会出现寻呼不到的情况，造成整体寻呼成功率下降。  处理过程：优化主要采取的方法： A、 RACH 最小接入电平参数调整：通过降低RAC

20、H最小接入电平，提高上行接收灵敏度来提高寻呼成功率。由于在寻呼成功率与掉话率指标之间的网优参数是互相制约的，通过修改此网优参数可以改善寻呼成功率指标，但会造成掉话率增加。 B、 增加MS最大重发次数。由于目前华为BSC几乎没有出现拥塞情况，可以将系统消息数据表中的“MS最大重发次数”由4次修改为7次。 C、 对于华为BTS312型基站，可以打开寻呼重发功能。将小区属性表中的“寻呼次数”由1次改为4次。通过上述方法，将寻呼成功率优化到91%左右，达到该局的要求。  建议与总结：A、 寻呼成功率和话务量存在一定的对应关系，同一位置区下，一般话务量越高，寻呼成功率越高，该地区由于话务量比较

21、低，所以寻呼成功率低于其他高话务地区。 B、 农村的基站，站与站之间相距较远，信号覆盖不连续，因此由于无线链路失败的原因引起的掉话，不可避免，导致寻呼成功率降低。 C、 该地区三面被其它省环抱，不同地区之间周期性位置更新时间不一致，也会造成寻呼不到用户，导致寻呼成功率低。 所以解决寻呼成功率低的问题，要综合考虑上述因素。  现象描述：部分用户投诉发现自己的手机近期在通话超过4分50秒到5分钟时就会出现自动断线，而通话在4分50秒以下则正常。 告警信息：无。 原因分析：1、可能为用户手机设置问题。 2、可能为该基站软硬件问题。 3、可能为BSC问

22、题。通过以上分析：1、联系用户将手机设置为初始状态，设置完成后，联系用户进行测试，发现问题依旧，通过A信令消息跟踪发现，到4分50秒BSC向MSC提出CLEAR  REQUEST  消息，原因值为：设备故障。2、维护人员去该站进行对主控板进行了更换，更换完成后，经过测试问题依旧。3、BSC工程师经过对该基站数据的检查发现，数据制作无误。通过对该基站所属BIE板所带另外三个基站进行拨测发现，该现象在其它三个站上均存在，由于该GLAP板所带基站基本为偏远山区基站，对4分50秒到5分钟时出现自动掉线的现象感觉不到，投诉量较少。通过对A口消息的分析发现，可能是该

23、基站所属GLAP板有故障。 处理过程：晚间1:00对该GLAP板进行了更换，经过拨打测试发现问题得到了解决。 建议与总结：对于该种故障，分析起来比较麻烦，测试起来也较复杂，还是建议维护人员在发现故障时，一步一步进行分析定位 现象描述：某地客户投诉该地在部分街道手机有信号，但无法打通电话；手机开机后，有时能选上网络，有时选择不到网络，出现无网络字样。  告警信息：无 原因分析：该地区网络一直运行正常，各项话统指标也很好，BSS数据也未修改过。接到投诉后，现场工程师在数管台上对BSS数据和话统进行了分析，未发现有异常；并对覆盖该街道基站的

24、信道状态进行了观察，也未发现有异常。在这种情况下，维护工程师赶往该街道，发现的故障现象和以上描述的一致。       在街道和机房对覆盖该街道的一个基站进行了锁频测试，都能成功地占用TCH信道，并能通话。但是，当手机不断地开关机，手机有时能上网，有时不能上网。从而可以初步判断目前网络对空闲的手机有影响，对通话态的手机没有影响。并从测试可以看出，手机只能选择该基站的一个小区，不能选择该基站的其它小区。 随后用MA10对该基站的Abis口的信令进行了跟踪，发现出现大量Location upding 

25、reject,查原因值是Network failer,看来问题出在MSC侧，在现场不断开关机，通过OMC跟踪该用户的信令，发现有两个小区位置更新被拒绝。  处理过程：由于BSS的数据没有发现异常，于是检查MSC的数据，发现MSC侧“位置区小区表”中这个基站3个小区的CGI的完全一样，后查操作回顾，发现由于修改其它数据，误操作把该站的三个小区的的CGI修改成一样的。修改其它两个小区的CGI，与BSC侧一致，问题得到解决。通过拨打测试，和不断的开关机，没有发现故障。  建议与总结：1、任何数据的修改都要非常小心，稍有不慎就会引起其它问题。2、遇到问

26、题时，多跟踪信令，以便更好地定位问题。 现象描述：某局登记24小时话统（统计周期1440分钟），指标为“TCH话务强度”。想要将24个小时的话务量累加。一个周期后（此周期未作动态修改操作）得到结果值很小，认为是统计错误。 告警信息：无。 原因分析：对“TCH话务强度（不含极早指配）”指标理解错误，误认为24小时话统就是简单的将24个小时的话务量累加。根据指标定义：本指标反映单位时间内MS占用TCH信道的时长。公式：小区TCH测量报告次数（不含极早指配）*0.48统计周期（秒）。所以登记24小时话统得到的结果是全天话务强度的一个平均值，而非汇总。 处理过程

27、：登记统计周期为60分钟的任务，将结果累加后得到全天话务量。 建议与总结：定义话统要正确理解话统指标的含义。现象描述：开局中经常会遇到设置BSC、MSC周期性位置更新的时间问题，那么如何才能正确的设置BSC、MSC周期性位置更新的时间呢？请参考下面的分析与处理过程。 告警信息：无。 原因分析：周期性位置更新的时间在MSC、BSC都有设置，其中BSC设置的位置更新时间是确实要求手机要进行的周期性位置更新时间，也就是说如果BSC设置的周期性位置更新时间为1小时，则手机上接收到的系统要求的周期性位置更新时间就是1小时，手机如果在1小时没有呼叫或者位置更新时，就会自己发起

28、周期性的位置更新。而MSC中设置的周期性位置更新的意思是：如果手机在这段时间内没有位置更新，则在VLR中将手机置位为关机。也就是说如果MSC的周期性位置更新时间设为2小时，则如果MSC在2小时内没有与手机联系过（包括呼叫、短消息、位置更新等），则在VLR中将手机的状态置位为关机状态。因此MSC设置的周期性位置更新的时间手机以及BSC都是不知道的。下面假设BSC的周期性位置更新时间为1小时。1、当MSC的周期性位置更新时间为40分钟，则如果手机超过40分钟没有与网络联系，MSC将手机状态置位为关机，由于BSC的周期性位置更新时间为1小时，因此问题将会经常发生。2、当MSC的周期性位置更新时间为8

29、0分钟时，由于BSC的周期性位置更新时间为1小时，因此如果手机状态正常，则1小时之内手机即使不进行呼叫，也会进行一次位置更新，所以MSC一般不会将手机状态置位为关机。但是如果由于偶然情况，手机丢失了一次周期性位置更新的消息，则可能会出现手机状态正常，但是MSC将其置位为关机的情况。3、MSC的周期性位置更新时间为140分钟时，此时同情况2基本类似，只是可以运行手机连续丢失两次周期性位置更新的消息。 处理过程：根据上面的分析过程得出结论，如果将MSC的周期性位置更新时间设为BSC的周期性位置更新时间的3倍以上，则出现问题的概率将很小很小。当然，理论上只要MSC的周期性位置更新时间大于B

30、SC的周期性位置更新时间就可以了，但是此时出现问题的概率将比较大。由于MSC的周期性位置更新时间设置的大一点对系统造成的影响比较小，因此建议将其设置成BSC的周期性位置更新时间的3倍。  现象描述：某局割接后，发现部分时候出现呼叫出现杂音，杂音没有规律，杂音出现在大部分基站下。杂音形式，类似为弹棉花的声音。我们在机房内拨测也出现杂音，这里信号不错，附近楼房上就有基站，而且杂音不固定时间，不固定位置。通过分析，我们定位问题在A接口上，再次经过A接口单条E1和时隙级测试，发现几个时隙不一致，主要是MSC未安装，通过修改MSC的状态和BSC一致，没有改善。所以我们的局内呼叫是没有

31、什么问题了。通过再次，将BSC和MSC重新加载后，情况好一些，但是还是有杂音，同时将基站升级版本，重启，也没有改善。最后通过MSC的告警台，发现一条E1有告警，于是尝试闭塞E1后，再次通过几个小时拨测和观察，没有发现杂音。于是问题定位为这条E1传输质量不好。问题出现在局内手机拨打局内手机，拨打外局手机，拨打固话等。本地MSC拨打固化，是通过其他MSC转接的，拨打附件基站的用户手机，也是需要出局呼叫的。 告警信息：无。 原因分析：通过对现场拨测信息和告警，我们认为，问题出现在下列一些问题点：1、A接口对接不准，于是重新检查A接口数据和链路，和MSC一起检查CIC；2、BSC和

32、MSC加载不完善；3、BTS软件版本升级不完善，数据下发到基站不完善；4、A接口传输质量和接地问题；5、Abis接口传输质量和接地问题；6、外部局点传输质量问题。 处理过程：针对问题出现的情况和拨测的结果分析：1、传输质量问题，我们检查了A接口的传输，再次将所有120Ohm中继线都再打一遍，确保连接稳定。 但是没有解决问题。2、检查Abis接口，同时确保到基站的传输是没有问题的。重启基站，问题没有解决。3、检查A接口数据，确保一致。 检查出几个CIC不一致的地方，通过MSC修改后，没有改善问题。4、再次升级BTS，但是没有改善语音。5、重启MSC和BSC，同时测试

33、了每条E1和大部分时隙，没有出现杂音。初步确认局内呼叫没有问题。6、通过MSC观测出E1告警，通过紧急闭塞E1，大量拨测，但是没有出现杂音，通过观察，没有再次出现问题。于是定位问题为外部局点传输，印象局内呼叫，同时局方的传输是通过传输到另外一个局点后，再传回来，需要使用外局传输。所以忙时比较容易占用这条E1，所以就会容易出现杂音。 建议与总结：定位问题，需要定位问题再局内还是局外，这样才更好的确定问题的解决问题。现象描述：    同频同BSIC 往往会导致小区间切换失败、TCH占用失败，因此GSM 网络中的同频同BSIC现象一直是我们

34、进行数据检查时的重点。 在大型网络中同频同BSIC的复用比较多，无论是使用GSM2000 的同频同BSIC查找功能还是Nastar的同频同BSIC查找功能都要花费很多时间，并且如果同频同BSIC的复用距离足够远的话我们也无须关注。    笔者所维护的尼日利亚某网络包含6个BSC，近5000块TRX，同频同BSIC复用的小区多达几百对，如果手工进行一次同频同BSIC检查需要几个小时时间。如果每周进行例行数据检查更是会占用很多时间。  告警信息：无  原因分析：     如果同频同BSIC

35、的复用距离足够远的话是正常的形象，所以我们可以先得到同频同BSIC复用小区，然后再计算出这些复用对（两个复用小区）之间的距离。     现在现场工程师都使用Nastar进行网络维护，我们可以使用Nastar（G-Nastar 2.0及以上版本）和EXCEL实现在10分钟内完成大型网络同频同BSIC查找。  处理过程：一、 打开当前工程，使用“网优分析”“同频同BSIC检查”“全网同频同BSIC小区检查”得到同频同BSIC小区列表，然后保存结果为txt文件。二、 使用EXCEL打开保存的txt文件，使用“vlookup”分别得到两列小区

36、的经度和纬度，然后使用计算地球上两点之间距离的公式得到两个小区之间的距离。地球   上两点之间距离的计算公式如下：SQRT(ABS(小区1经度-小区2经度)*60)*1.9)2+(ABS(小区1纬度-小区2纬度)*60)*1.9)2)至于“vlookup”、“SQRT”、“ABS”等公式请参考EXCEL帮助文件。三、 设定一个距离门限，然后筛选出小于该门限的复用小区，进行修改。该门限因各地网络不同而不同，如果是使用大功率载频和PBU的网络该数值应该设置稍大。根据实际的维护经验建议使用40w载频网络该数值设置5070Km，使用60、80w载频网络设置100120Km

37、（考虑天线相对情况）。  建议与总结：建议一、对于定期进行数据检查的情况可以做好模板，一个EXCEL文件按照固定格式存放小区名称、经度、纬度等信息，另一个EXCEL文件包含“vlookup”、“距离计算公式”这样每次只要把新的小区粘贴进第二个文件就自动计算出结果，并且还可以把时间缩短至5分钟。建议二、建议Nastar新版本开发是内置此功能，支持用户设定距离进行全网同频同BSIC查找 现象描述：为了提高全网的切换成功率，我们对一些切换差的小区进行了优化分析。华为BTS312基站， S121配置，3小区的出小区切换成功率较低，不到60%。  告警信息：无 &

38、#160;原因分析：检查基站单板，3小区单板工作正常，基站无异常告警，TMU单板外时钟锁定状态。 检查小区话统，话务量2.4erl，掉话次数3次，小区的干扰带也正常。登记该小区详细的 小区间切换性能测量 话统，发现小区的出切换中负荷切换较多，忙时 发起切换尝试次数（负荷） 达55次， 发起切换尝试次数（上行信号强度） 有 10多次，发起切换尝试次数（更好小区） 60次左右。 按照资料说明小区的负荷切换对目标小区的接收电平没有要求，而是把切换带（边缘切换门限边缘切换门限负荷切换带宽）均分多个切换步

39、长，依次由低向高把落在切换步长中MS切换到邻近小区，显然切换的成功率较低。小区的负荷切换多，而小区的话务量并不高，表明小区的话务比较集中，高峰时TCH负载较大，容易发生负荷切换。扩容载频虽然可以解决问题，但是考虑到小区话务量不高，我们的解决办法是提高小区的 MS最小接收电平 ，由 8 改到 11，通过减小 C1 值达到减少小区话务的目的，同时我们闭掉了小区的负荷切换。  处理过程：1、检查基站载频、TMU板等；2、检查小区切换性能话统，分析切换原因；3、小区的 MS最小接收电平 由 8

40、 改到 11，闭掉小区的负荷切换；4、跟踪之后的话统，小区话务量降到2.1erl，小区TCH没有拥塞；5、小区的出切换成功率达到了87%。  建议与总结：负荷切换实际效果并不好，建议将小区的负荷切换默认值改为闭掉。现象描述：某局用户反映网上设备寻呼成功率，拨打用户经常联系不上，寻呼成功率低造成一定的用户流失，统计交换侧寻呼成功率，早忙时一般在75%左右，低于一般的水平。  告警信息：无  原因分析：寻呼成功率寻呼响应总次数/寻呼总次数，寻呼响应总次数：指本地区MSC收到的PAGING RES消息的响应总和。包括二次寻呼响应。寻呼总次数

41、：指本地区MSC发出的PAGING消息的总和,不包括二次寻呼的消息。寻呼成功率与交换侧和基站侧都密切相关，与无线环境也密不可分，交换侧设置合理的录呼策略和机制，包括MSC和BSC的位置更新时间，以及BSC的网优参数都可以影响寻呼成功率。  处理过程：1、检查MSC的寻呼机制，保留二次寻呼下发功能。2、设置MSC和BSC的位置更新时间，根据信令负荷情况，适当减少位置更新时间。3、设置BSC的网优参数，包括RACH最小接入门限，提高用户手机的接入性能，减少部分因为覆盖信号弱造成的无法接通现象。通过以上的调整，在一定程度上提高了寻呼成功率。4、打开基站的寻呼重下发功能，将基站的寻呼下发次数

42、由1次改为2次。这样可以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时无法正确接收寻呼命令问题，另外，由于基站侧实现了寻呼重发，减少了MSC侧寻呼重发量，一定程度上降低了整个网络侧的信令负载。通过以上的调整，再统计MSC侧的寻呼成功率已经达到了87%左右，提高了10多个百分点。  建议与总结：提高寻呼成功率可以有多种方式，通过打开基站重下发功能可以在一定程度上提高系统的寻呼成功率，这样可以解决一些由于偶尔的无线链路传输质量差而造成的移动台暂时无法正确接收寻呼命令问题，另外，由于基站侧实现了寻呼重发，减少了MSC侧寻呼重发量，一定程度上降低了整个网络侧的信令负载。  

43、现象描述：河北沧州现有两个华为BSC，BSC1主要覆盖郊县和乡村，BSC2覆盖市区范围。其中BSC1的整体指标中 BSC内小区间切换成功率 较低 (<93%)。  告警信息：无  原因分析：通过BSC整体性能指标话统发现，发起切换尝试次数（更好小区） 和 发起切换尝试次数（下行信号强度） 两个值相对较大，这说明小区切换的主要原因为边缘切换和PBGT切换。同时注意到 BSC内部切换失败但重建成功的次数 较高，而 BSC内部切换失败重建也失败的次数 较低， 这说明

44、可以提高切换门限来减少一些切换。考虑到调整边缘切换门限会影响到掉话指标，我们决定提高PBGT切换门限。我们检查了邻区关系表，4500多条邻区数据中，小区间切换磁滞全部为5，3500多条PBGT切换门限为70，有900多条PBGT切换门限为68。我们筛选出PBGT切换门限为68的小区后，统一改成了70。  处理过程：1、检查BSC整体性能测量话统。2、检查小区切换数据配置。3、筛选出邻区中PBGT切换门限为68的小区，修改PBGT切换门限为70。4、检查话统确认掉话没有增加，BSC内小区间切换次数 由43000多次降到了38000多次， BSC内小区间切换成功率&#

45、160;上升到了95%。  建议与总结：PBGT门限的默认值是68，在密集市区可以有效降低网内干扰，减少越区覆盖；在郊县建议统一调整到70以上。对于一些需要话务均衡的个别小区再做个别调整。 现象描述：用户反映手机信号频繁波动。  告警信息：无  原因分析：1、多径原因造成的信号电平波动；2、干扰造成的当前服务区手机的DCS计数器跌为零，而发生小区重选；3、传输闪断造成的基站开、关功放的现象；4、TRX载频板故障或各载频合路方式不同等情况导致载频功率在天线口输入功率不一致，从而致使指配后信号指示的变化；5、由于小区重选出现信号电平指示的变化。  

46、处理过程：1、观察周围地形和建筑，排除多径原因；2、查看话统，TCH的干扰带二、三、四、五的值都为0；3、查看告警，不存在LAPD-OML告警和E1远端告警，排除传输闪断原因；4、用功率计检查载频功率和机顶功率，正常；5、在投诉点用测试手机测试发现不断的发生小区重选，其中电平稍低小区的CRO设置为3；6、在维护台将电平稍低小区的CRO改为0后，信号频繁波动现象消失。  建议与总结：在使用调整CRO参数进行话务调整时，需要考虑可能带来的小区重选等方面的影响。现象描述：某日发现华为某1800站1小区A掉话比较严重，几乎白天每个时段掉话都有6、7次之多，话务量不大在0.4ERL左右，从维护

47、台上未发现任何异常告警。  告警信息：从维护台上未发现任何异常告警。  原因分析：分析掉话常见的原因：1、干扰； 2、载频硬件故障； 3、天馈合路器问题； 4、传输问题；5、时钟问题；6、切换原因；7、覆盖不足或越区覆盖等原因。  处理过程：1、检查告警，在维护台上未发现该站异常告警，由于是2.0站，检查了各板件版本是否一致，确认各个板件版本一致。2、具体分析是哪块载频掉话较多，从话统上看到主B载频干扰带正常，在干扰带一、二中，几乎没什么掉话；掉话主要集中在这个小区得TCH载频上，并且该载频的干扰带5中空闲TCH数目异常得高达到7点多

48、，而干扰带一四则没有。3、此时基本可以排除由于天馈等其它原因造成的掉话，因为主B的话务量及掉话情况正常，基本定位小区A的TCH载频受到强干扰导致掉话，由于附近邻小区B刚好发生时钟、下行总线告警等故障，并且其中一个频点与小区A的TCH同频，怀疑此小区对小区A造成干扰，就把小区A的TCH换了个跨度较大的干净频点，登记15分钟的话统发现小区A的干扰带还是在干扰带五里。4、此时排除频率规划带来的小区间同邻频干扰，基本断定由于载频自激引起的干扰掉话，换了块载频后，观察话统干扰带降到了干扰带一中，并且话务量达到了1.5Erl左右。  建议与总结：如果是外部干扰一般从话统上看干扰带是干扰带15都有

49、，而载频自激导致的自干扰从话统上看干扰带上比较集中于干扰带5中。  现象描述：某局扩容工程，首次使用华为设备，“插花”于N设备商网络中，华为设备皆采用BTS312基站，合分路单元采用EDU，扩容后发现部分小区有拥塞现象，于是在客户的强烈要求下，华为网优工程师对华为3个BSC内的所有基站开通半速率功能，其后观察话统指标，发现全网TCH拥塞率（含切换）不但没有降低反而升高了10左右。 告警信息：无。 原因分析：1、观察话统指标发现TCH拥塞率高的小区多是单载频小区；2、拥塞原因为占用遇全忙；3、观察这些目标小区占用TCH信道请求次数指标，发现【只选全速率TCH信道请求

50、次数】占TCH信道请求总次 数50以上，而且成功次数极少；4、又检查参数设置，发现【预留全速率TCH最小数目】设置为"1"，【TCH速率调整业务量忙门限（）】设置为15；5、于是忙时查看这些问题小区信道状态发现问题小区的5个TCH信道中有4个都已经转换成半速率信道，但大部分时间处于Idle状态，剩下仅有的一个全速率TCH信道，大部分时间在Using中。于是可以判断出这些小区是应为在覆盖范围内只支持全速率手机用户比例大，占用全速率TCH信道遇全忙次数多，造成的拥塞！ 处理过程：1、更改【TCH速率调整业务量忙门限（）】为50；2、更改【预留全速率TCH最小

51、数目】为3；3、更改【TCH恢复最短时间（秒）】为60；4、更改参数后观察话统发现TCH拥塞率降到0.2左右，拥塞问题解决！ 建议与总结：建议小区在开通半速率时慎重配置【预留全速率TCH最小数目】、【TCH速率调整业务量忙门限（）】以及【TCH恢复最短时间（秒）】等半速率相关参数！ 现象描述：LAPDm N200参数开关的作用？此参数打开有什么注意事项？  告警信息：无  原因分析：LAPDm N200参数开关的作用：在由于建筑物阻挡而局部网络覆盖不好或者有较多的信号干扰的地区，适当增大T200×N200（即基站侧链路保留）

52、的总时间长度，链路重建的可能性就变大，网络指标有可能够得到提高。如果选择增大T200，信令的交互会变慢，不利于在无线环境比较差消息确实丢失的情况下尽快的重发消息，此时，可以适当增大N200。  处理过程：注意事项：1、N200不宜设置过大，手机如果已经掉网并发起新的建链，老信道继续保持会降低信道的利用率。2、"LAPDm N200参数开关"是控制BSC是否下发LAPDm N200参数到BTS。该开关配置为是则下发LAPDm N200参数，否则不下发。只有BTS3X宏基站和BTS3002C支持，其它类型基站均不支持。该功能须在下列版本及

53、以后版本才支持：BSC：G3BSC32.10101.06.1120，BTS3X：G3BTS32.30000.04.1130，BTS3002C：G3BTS36.30000.03.0820 现象描述：Y地移动MSC为S厂家设备下挂华为边际网BSC，BSC版本为G3BSC32.10101.06.1120A，边际网基站全部为华为BTS3002C小基站，版本为3.06R002.20020820，基站已经全部开通GPRS业务，某日上午突然大量用户投诉电话难打，拨后无反应或拨不通，手机信号显示正常和以前一样，反映将近60个基站出现这个现象，其余基站正常  告警信息：实时告警里只有几条UPS告警和L

54、APD_OML告警，实时及历史告警都没有MC2/MCCS通信链路故障或流控告警，告警参考意义不大  原因分析：问题出现在信令阶段（接入阶段）而非通话阶段，检查信令通路和接入参数设置，重点是影响全局的信令单板和接入参数1、集中大话务量或群发短消息冲击或信令故障过载2、BSC单板硬件原因  MC2、MCCS、MCCM、SNT、LPN7故障或其中通信链路故障3、MSC过载或修改参数不当4、BTS版本问题5、BSC工程数据配置问题   主要是流控参数被误修改，如主机流控、TCH流控等6、BSC网优数据配置问题  CGI、R

55、ACH、BCCH信道组合不当  处理过程：1、有反馈的近60个基站分布相对分散，不可能是大话务量冲击，首先登录话统台查看TCH话统发现指配很正常，TCH只有几个小区拥塞，排除大话量影响，局里使用的是小区广播，群发短消息早已不用了，维护台所有NO7信令都正常且无历史告警或实时告警； 2、 请督导查询近三天的BSC历史告警，没有发现影响全局呼叫的MC2/MCCS/SNT/NO7故障或链路告警，也没有NO7链路告警，可以排除BSC硬件影响； 3、MSC过载会对BSC限呼且BSC会上报MSC过载告警，MSC容量足够大，BSC也无MSC过载告警；MSC打开了BSC

56、不支持的EFR/HR导致BSC无法识别完不成指配或指配不成功，但局里说没有做中继电路操作； 4、前段我们的BTS3002C刚刚发生过开通GPRS后引发的电话难打问题，但是BTS3002C现网用的版本已经解决了该问题，按照研发以前的指导查看了几个基站日志，没有发现相应日志，也没有其它异常日志；  5、查看流控参数设置规范，没有打开TCH流控，如果发生流控，维护台会上报相应告警，但是没有发现流控告警，排除流控影响；  6、因为该地正在进行网优，首先就是问的就是有没有单方修改CGI，网优答复近期没有修改CGI数据，RACH近期也没有修改，现在只有接入

57、参数影响了，查看小区随机接入话统发现SDCCH占用失败很多，PCH过载严重（陡升了4倍，主要是0X9124位置区，该位置区单载频为组合BCCH），RACH也过载很多，可以肯定是接入参数或BCCH信道组合，获取了一下现场数据发现接入允许保留块数改为1了，判定是该参数影响，公司数据配置规范对接入允许保留块数解释如下：BTS3X 03.1130版本以前的程序AGCH处理过程与BTS20一样，当AGCH信道占用完时，如果此时PCH信道空闲，可以借用PCH信道来进行立即指配命令的下发。AGCH保留块如果配置为0，那立即指配等就得在空闲的寻呼信道发送；所以，需要为AGCH固定分配一定的容量。BT

58、S3X 03.1130实现了立即指配优先功能，但是为了与现有网上情况一致，缺省情况下仍然为寻呼优先，此时建议AGCH保留块保持不变；只有配置为立即指配优先，才会优先发送立即指配消息，此时可以配置AGCH保留块为0，但由于我们的BSC版本不支持该配置，即使配置为0，下发的系统消息中会指示为1。另外，协议中也有明确规定，一些情况下AGCH保留块不能为0，包括如下：1） 有系统消息需要在Extended BCH上发送时；2） 配置有CBCH信道时；3） GSM-R情况下，配置有NCH信道时。将所有小区接入允许保留块数由1修改为2，并将0X9124小区

59、的组合BCCH修改为主BCCH，问题解决经了解问题过程如下，局里为了解决GPRS引入后的信道拥塞问题，自行将各个单载频小区的主BCCH全部修改为组合BCCH，随后发生了PCH过载，但不是很大，每个小时约上千次，但是事发前天晚上有人将接入允许保留块数错误修改为1，因为我们的设计是寻呼优先，这样本来PCH就过载（0X9124组合BCCH小区最明显），不可能有空闲PCH给接入用，AGCH开始拥塞，这样用户越呼叫不通越拨电话产生了“雪崩”效应，从信令看有大量CCCH_OVERLOAD上报  建议与总结：根据用户反映首先判断是接入影响还是通话影响，然后查相关参数和话统然后咨询现场做了哪些数据修

60、改或维护台告警可以迅速定位问题， 以前一直跟研发定位BTS3002C呼叫可能问题，版本成见影响延误了一点时间  现象描述：1小区向2、3小区切换正常，但2、3小区向1小区切换失败率很高。  告警信息：无  原因分析：检查话统数据发现1小区切换性能测量BSC内入小区切换失败次数（其它原因）很多，与TCH性能测量中TCH占用失败次数相当，造成载频的射频丢失率很高，怀疑硬件问题。 处理过程：闭锁载频，发现与载频无关。更换CDU后，现场拨测切换正常，话务统计结果正常  现象描述：为什么手机从900重选到1800后，10s内只能看到1800的邻

61、区，10s后才能看到900的邻区  告警信息：无  原因分析：同步一个BCCH载频最大为0.5s，读取一个同步的BCCH载频数据的最大时间为1.9s（8个51复帧），获取系统消息的最大时间是n*1.9s。对于获取本频段BA的系统消息2，n=1；对于获取其它频段BA的系统消息2ter，n=4。小区发生重选时，手机将尽快同步和读取6个信号最强的非服务区BCCH载频的信息。对于多频手机，最强信号载频可能处于不同的频段。由于手机处理协议方法不同，有的手机可能优先处理本频段信息，或者从效率考虑优先同步本频段小区，因此导致先看到本频段邻区，稍晚才能看到其它频段的信息。下面从极端分析这个现象：1、对于系统消息2，手机重选后2.4s内即可获取，如果手机在获取系统消息2后开始处理邻区信息，对于异频段需要接收系统消息2ter，最大可能需