职务晋级文档

1、初级晋级考试 高汇科 2009年10月案例案例1 1 切换成功率低切换成功率低 对每日的统计数据进行分析，发现太阳山连续两日的切换成功率均较低，最低只有70%多，如下图所示： 为了检查该问题是否属于偶然因素导致，查看GUI统计，发现该小区除以上统计的20：00的切换成功率较低外，其他时段也存在这样的情况，因此排除偶然因素所致。查看小区的切换返回统计： 从上表可看出该小区的切换返回次数较高，达到了100多次，如此高的小区切出返回导致了切换成功率的恶化。 out_intra_bss_ho_return 统计的是源小区向目标小区发起切换请求，未能成功接入目标信道，而rr_t3103尚未超时，成功返回

2、源信道的次数。 处理思路处理思路 导致切出返回次数较高主要有以下几个因素：目标小区存在硬件故障，手机不能接入；存在和目标小区同BCCH同BSIC的小区；切换参数设置不正确。 此类问题的处理最直接的思路就是找出切向哪个小区导致了返回，也就是说要找出目标小区。可以从in_intra_bss_ho_return统计项找出目标小区，该统计项反映的是未成功切入该小区而返回的次数。 处理过程处理过程 第一步：查找目标小区第一步：查找目标小区 查找目标小区有两种方法： 1、可以通过打开邻区间的切换统计，来找出切换失败多的小区； 2、可以根据经验，直接在bsc内的小区中找in_intra_bss_ho_ret

3、urn值较 大的，并且和源小区有邻区关系的小区。 根据第二种方法，很快找到了长岭岗1区，该小区和太阳山1区有邻区关系，而且切换返回次数也和太阳山相仿。 从下图可以看出44151的切入返回和太阳山的切出返回次数基本相同，而且两个小区之间有邻区关系：第二步：检查目标小区性能第二步：检查目标小区性能 查看长岭岗1的小区指标发现，该小区除切入返回高之外，均正常。载频级统计的各项指标也均处于正常水平。第三步：检查邻区参数设置第三步：检查邻区参数设置 查看两个小区的切换参数设置，发现均采取默认值，也没有问题。第四步：查看地理位置信息第四步：查看地理位置信息 通过GOOGLE EARTH查看发现太阳山为高山

4、站，和长岭岗基站分别位于山的两侧，因此这两个小区不应该存在如此多的切换关系。 第五步：检查同第五步：检查同BCCHBCCH同同BSICBSIC现象现象 通过查看发现，长岭岗1和桃树岗1存在同BCCH同BSIC情况。 而太阳山因为是高山站，到桃树岗方向无阻挡，因此可以覆盖较远也属于正常。手机会测量到桃树岗1信号强，而发起向该BCCH-BSIC组合的小区发起切换请求，bsc会认为该组合为长岭岗1，而发起向它的切换，而手机因为和长岭岗相距太远，不能成功切入而返回。 第六步：重新调整切换关系第六步：重新调整切换关系 1、删除太阳山1区到长岭岗1的切换关系； 2、添加桃树岗方向的邻区关系。 调整后的邻区

5、关系如下图所示：问题解决问题解决 通过以上调整，太阳山1的切换成功率已经恢复正常。案例案例2 2 合理利用合理利用”孤岛效应孤岛效应” 统计发现观音尖1小区的指标异常,呼建、掉话、切换均比较差，具体统计指标见下表：CINAMEDateCALL_SETUP_SUCCESS_RATEDROP_CALL_RATEHANDOVER_SUCCESS_RATESDCCH_RF_LOSS_RATETCH_TRAFFIC_CARRIEDRF_LOSSES_SD11991观音尖9.478.184.0558.912.796.912311991观音尖9.579.775.8172.894.186.213511991观

6、音尖9.678.203.8678.823.318.8827告警信息告警信息 小区没有告警 查看小区载频级统计发现，该小区的平均TA有15左右，最大TA为50多，有明显的过覆盖现象。查看Googleearth，发现该小区为高山基站，海拔较周围高出好几百米，因此覆盖较远也属正常现象。从下图能明显的看出，观音尖1小区会在太平铺-李龙-卢家冲-七里冲一线形成较强的覆盖。 现网定义的邻区关系如下图所示： 也就是说观音尖基站在以上区域形成了一个“孤岛”。在这个孤岛内，手机会因为观音尖基站的信号较强，而重选到观音尖；因为和周围基站间的干扰，会导致有较多的sd掉话；起呼后，而因为不能切换到邻近小区而产生掉话。

7、 至于切换成功率低，主要是因为观音尖二区和卢家冲二区有bcch同bsic现象。在此区域测量到卢家冲二区信号较强，进而会发起向观音尖二区的切换请求，因此会导致切换失败。处理步骤处理步骤 要解决此问题，可以考虑控制观音尖的过覆盖，以消除“孤岛”，也可以考虑将该孤岛加以利用。鉴于观音尖基站较高，因此采取后一种方案使得孤岛和周围基站连接起来。1、添加观音尖一区和周围小区的邻区关系；2、修改观音尖二区的bsic，添加卢家冲二区和观音尖一区的邻区关系；3、修改观音尖一区的tch频点。 从统计指标可以看出，观音尖一区的呼建和切换成功率均有明显提升，tch掉话和sd掉话也有所改善：CINAMEDateCALL

8、_SETUP_SUCCESS_RATEDROP_CALL_RATEHANDOVER_SUCCESS_RATETCH_TRAFFIC_CARRIEDSDCCH_RF_LOSS_RATERF_LOSSES_SD11991观音尖9.791.212.3495.617.281.561311991观音尖9.890.812.1194.415.181.1612小结小结 高山站的过覆盖现象是非常普遍的，往往指标也较差，因此合理解决过覆盖而形成的孤岛现象，对小区的指标提升有着重要的意义。而对孤岛的有效利用，不但可以解决指标异常的问题，有时候也能解决覆盖问题，加强在孤岛区域的覆盖。案例案例3 3 长鹰国际长鹰国际微

9、小区拥塞微小区拥塞 下表为长鹰国际微连续五天的忙时统计数据，根据全网统计数据，取忙时为20：0021：00。NAMECIdateTotal_calls_keyTch_traffic_carrierTch_blocking_rateCell_barAvailable_tch_maxIntra_cell_ho_req长鹰国际_微189509.42294.515.823.497213长鹰国际_微189509.52715.1311.58.027300长鹰国际_微189509.62994.656.545.77276长鹰国际_微189509.72094.224.331.57188长鹰国际_微189509.

10、82034.095.271.577217 从上表可以看出，话务量高时18950小区的tch拥塞和cell_bar两项指标很高。而且小区内切次数很高。NAMECIDATERTFBERIOI长鹰国际_微189509.5rtf001.130.04长鹰国际_微189509.6rtf000.950.04长鹰国际_微189509.7rtf000.770.03长鹰国际_微189509.8rtf000.720.02长鹰国际_微189509.9rtf000.810.02长鹰国际_微189509.5rtf010.112.44长鹰国际_微189509.6rtf010.342.62长鹰国际_微189509.7rtf0

11、10.382.16长鹰国际_微189509.8rtf010.232.08长鹰国际_微189509.9rtf010.361.62下表为长鹰国际微的部分载频级统计： 小区内切一般是由于质量不好，主要由干扰导致，但是从上表可以看出，小区所有载频的BER和IOI都很低，可见如此高的小区内切是由tch全速率与半速率话音信道的频繁转换导致的。 用Disp_eq 3 dri * *full命令查看小区配置，发现用的是一块ctu2，double模式。在dri00上配置了3条静态的64k的PDTCH信道，2条动态的64k的PDTCH信道，直接导致rtf01的5个时隙退服，所以最大可用tch数目只有7。 小区静态

12、SD信道数配置为16，查看1024的BUSY_SDCCH_MAX，发现最大不会超过8，所以将sd信道减少为8，增加一个tch信道。 查看小区参数，发现最小接入电平为5，对于微蜂窝来说过小，会吸收原本不属于它的话务，因此将此参数改为15。 下表为最小接入电平更改后的统计数据：基站名 小区号日期Total_calls_keyTch_traffic_carrierTch_blocking_rateCell_barAvailable_tch_maxIntra_cell_ho_req长鹰国际_微189509.72094.224.331.57188长鹰国际_微189509.82034.095.271.57

13、7217长鹰国际_微189509.91014.084.132.338173 从上表可以发现，修改后同时段小区total_calls_key减少一半，但是话务量几乎不变，tch拥塞依然存在。说明这些用户属于该小区的覆盖范围，只是该小区容量偏小而已。接入半径过小，导致total_calls_key与话务量不成正比。将最小接入电平改为10，total_calls_key正常。 下表为更改后的统计数据：NAMECIDATETotal_calls_keyTch_traffic_carrierTch_blocking_rateCell_barAVAILABLE_TCH_MAXINTRA_CELL_HO_R

14、EQ长鹰国际_微189509.72094.224.331.57188长鹰国际_微189509.82034.095.271.577217长鹰国际_微189509.91014.084.132.338173长鹰国际_微189509.101855.923.035.048339拥塞释放拥塞释放 开启拥塞切换功能，将ho_exist_congest从0改为2，enhanced_relief从0改到1，同时将小区59082 、9712、9713的congest_ho_margin从5改到0。由于小区的半速率比已经比较高，因此不调整reconfig_fr_to_hr和new_calls_hr。拥塞释放开启后，

15、拥塞切换40次左右，缓解了一定程度的拥塞，但是tch拥塞和cell_bar还是比较高。由于小区话务并非很高，不过由于tch较少才导致的拥塞，可以将载频ctu2更换为ctu2d来缓解拥塞。 下表为更换载频为ctu2d后小区的统计数据：NAMECIDATETotal_calls_keyTch_traffic_carrierTch_blocking_rateCell_barAVAILABLE_TCH_MAXINTRA_CELL_HO_REQ长鹰国际_微189509.131984.175.271.578217长鹰国际_微189509.142766.8900130长鹰国际_微189509.152696.

16、7200131 主叫Ms沿箭头方向行驶,占用李家铺基站2小区,时隙3,跳频,质量持续5级左右,有掉话隐患。随着Ms离李家铺基站越来越远,接收电平从-50dBm逐渐降低到-88dBm,最终切换到庙基3小区。然而在此过程中,无论电平高低,通话质量一直为4-5级。案例案例4 4 李家铺基站硬件问题李家铺基站硬件问题 查看被叫，被叫占用小区以及跳频频点与主叫类似，时隙为4，接收电平与主叫近似，但是质量几乎持续0级。查看邻区定义及频率规划，未发现明显频率干扰。查看统计，统计项IOI很低，基本排除外部干扰。 查看统计项BER发现rtf12、dri12的BER大于9，平均每个时隙并不是特别高。再查看每个时隙

17、的BER，发现偶数时隙的BER很低，而奇数时隙BER全天高于2.5。将rtf12倒换到dri11上观察，发现统计项BER有明显变化。统计数据如下表所示：CINAMERTFDATEBER10652李家铺RTF1120-09-20091.2210652李家铺RTF1121-09-20091.3410652李家铺RTF1122-09-20091.0810652李家铺RTF1123-09-20099.8210652李家铺RTF1124-09-200912.4610652李家铺RTF1220-09-20099.4410652李家铺RTF1221-09-20099.5810652李家铺RTF1222-09

18、-20099.6810652李家铺RTF1223-09-20092.5610652李家铺RTF1224-09-20090.95 从上表可以发现，dri12硬件有问题，而且分奇偶时隙，一般这样的情况可以试着拧紧螺丝，如果无效，更换载频。 案例案例5 5 直放站与源小区重叠覆盖直放站与源小区重叠覆盖 如上图所示被叫ms沿箭头方向行驶，占用关山3小区通话，跳频，质量持续7级，最终无线链路超时掉话。此路段共产生两次掉话。接收电平在-70-80dBm左右，邻区信号比服务小区低10dBm左右，而载干比却小于-6。主叫占用bcch频点，质量比被叫好，3、4级左右。查看频率规划及邻区定义，未发现明显频率干扰。

19、 从下图可以看出TA变化太大，从5突然变到16，而ms距离关山基站的距离才不到3.5公里。这种情况应该是直放站导致。TA为5时接收到的是源小区的信号，TA为16时接收到的是直放站的信号，因为直放站有时延，所以TA值会比较大。检查发现直放站与源小区覆盖重叠，造成强干扰。调整源小区和直放站的覆盖使之合理。案例案例6 SD6 SD掉话高的处理掉话高的处理 统计发现大楠湖2区的sd掉话率偏高,连续多天达到了7%左右,具体指标见下图所示:CINAMEDateCALL_SETUP_SUCCESS_RATESDCCH_RF_LOSS_RATETCH_TRAFFIC_CARRIEDTOTAL_CALLS_KE

20、YRF_LOSSES_SD10012大楠湖20-07-200996.746.169.014156710012大楠湖21-07-200996.517.5110.683046410012大楠湖22-07-200997.276.769.733567610012大楠湖23-07-200997.137.737.9127173告警信息告警信息小区没有告警 当手机发起rach后，基站允许手机继续接入，会用agch信道给手机分配sdcch信道。主被叫、位置更新、收发短信息、开关机是sdcch信道占用的主要方式，如果发生sdcch掉话，会导致相应业务中断，影响网络的服务性能。造成sdcch掉话的主要原因是分配sdcch信道的rtf性能差，常见的有硬件故障和频率干扰两种类型。原因分析处理步骤处理步骤 查看分配sdcch的载频的统计数据发现，rtf13为承载sdcch信道的rtf，该rtf的ber统计值为7左右，和其他的rtf相比稍微偏高。下表为统计数据 CINAME RTF DateALLOC_SDCCH_CARRALLOC_TCH_CARRBER10012大楠湖RTF-01-0320-07-200914353126.2910012大楠湖RTF-01-0321-07-200912352