gsm参数优化文档格式.docx
《gsm参数优化文档格式.docx》由会员分享，可在线阅读，更多相关《gsm参数优化文档格式.docx（24页珍藏版）》请在冰豆网上搜索。
（2）硬件原因造成的掉话。
18
（3）切换时间过长造成的掉话。
4，上下行信号质量及强度的调整来优化整个网络性能。
（1）分流1800M用户。
（2）信道的优先分配。
（3）打开干扰降低参数。
19
（4）调整天线。
20
（包括排队等待时间长的情况）
********************************************************************
A）SDCCHBlockingRate=C1036/（C1036+C1034+C1051/2）
B）Doubleallocationratio=
C）SDCCH话务量（爱尔兰）=C1607
D）NumberofSDCCHallocationrequest
=C1191/0+C1191/1+C1191/2+C1191/3+C1191/4+C1191/4+C1191/5+C1191/6+C1191/7
E）NumberofsuccessfulSDCCHimmediateassignments
=C1192/0+C1192/1+C1192/2+C1192/3+C1192/4+C1192/4+C1192/5+C1192/6+C1192/7
F）Numberof“EstablishIdication”messagesreceivedonSDCCHorTCH（noSDCCHAVALIBLE）
=C1193/0+C1193/1+C1193/2+C1193/3+C1193/4+C1193/4+C1193/5+C1193/6+C1193/7
*****************************************************************************
C1034：
小区的SDCCH分配次数。
（allocation）
C1036：
因为缺乏SDCCH的SDCCH分配失败次数。
C1051/2：
在没有SDCCH可供使用的情况下转化成SDCCH使用的TCH数目。
C1195：
在I类手机中接受到的SDCCH”EstablishIndication”messages的数目（Establishindication）
C1196：
在II类手机中接受到的SDCCH”EstablishIndication”messages的数目（Establishindication）
C1607：
小区的SDCCH话务量。
C119x/0：
对I类手机是“其他原因”；
II类手机是“位置更新”。
C119x/1：
对II类手机是回“PAGINGREQUEST”。
（I类手机不用该计数器）
C119x/2：
对II类手机用于“在TCH/FR上传输数据或话音”。
C119x/3：
对II类手机用于“CallReestablishmentonTCH/FR”。
C119x/4：
对两类手机均用于接收“ChannelRequired”信息，该信息用于回Pagingrequest。
C119x/5：
对两类手机均用于接收“ChannelRequired”信息，该信息用于回emergencycall。
C119x/6：
对两类手机均用于接收“ChannelRequired”信息，该信息用于回callreestablishment。
C119x/7：
对I类手机是“手机发起的所有服务：
MOC；
SMS；
SS”；
II类手机是“TCH/FR上的MOC服务”。
C1191：
channelallocationrequest；
C1192：
successfulimmediateassignment；
C1193：
EstablishIndication
*******************************************************************************
下图是CT7200中CQ表关于各种原因分配SDCCH的比例：
根据counter可以判断SDCCH主要分配给什么行为了：
******************************************************************************
SDCCH分配图流程如下：
当BSC根据«
ChannelActivationNack
»
而每发送一次«
ImmediateAssignmentReject
时，计数器C1036«
SDCCH分配失败
将累加一次。
实际上，当没有可用SDCCH时，BSC将向移动台发出«
AssignmentReject
，该消息还包含T3122，它定义了暂时禁止移动台发出下次呼叫的最小时间间隔。
***********************************************************************
SDCCH拥塞情况可由下表表述：
（A）对于用户起呼数量多的情况，检查该小区的TCH是否拥塞，如果TCH不拥塞，则可以改动配置增加SDCCH信道的数量。
（B）其中如果LOCATIONUPDATING的比例过大，说明其在LAC区边缘可以修改cellReselectHysteresis，但对SDCCH拥塞高等情况效果不明显。
（C）如果TCH同时也拥塞，可以适当减小该小区的Cellreselectoffset值，同时提高邻小区的Cellreselectoffset值设置，使空闲状态下的手机在小区选择时尽量多选择其它小区，从而减小本小区的用户起呼请求，降低SDCCH拥塞。
当网络为双频网时，用1800M小区来分担SDCCH拥塞也是采用该方法。
（D）对于位置区周期更新时间过短而造成的SDCCH拥塞的情况，延长位置区周期更新的时间timerPeriodicUpdateMS即可解决该问题。
注意与BSC的配合问题。
（E）适当增加T3122的值，避免SDCCH拥塞时手机不断发请求，而不断被计数造成拥塞指标高。
t3122立即分配失败时（nosdcch），手机重发下一次要求所需间隔的时间。
当T3122=30系统自动在t3122于10和30秒间选取最佳值。
（F）检查双分配率，对双分配率高的站进行优化，可以减少资源浪费，缓解SDCCH拥塞。
见下图：
通过减小rndACCTimeThreshold值来减少双分配率。
（缺省35km）
6kmforurbanarea
15kmforsurbanarea
该参数用于表述手机可以接入一个小区的最远距离。
超出该距离，就算手机用户可以清楚解调出小区信息也不能接入。
但能否切换进入目前无定论。
（G）扩容DRX以根本解决拥塞。
（唯一可能受频率限制而不能扩容）
（H）有一种其他原因造成SDCCH拥塞的假象。
可能性一：
当小区修改了LAC和CI值之后（BSS级），如果这两种值中的任何一种在NSS级并没有定义补充或定义错误，那么就可能造成SDCCH不断尝试位置更新或小区重选，这时TCH溢出严重，现象是任何用户无法拨进或拨出。
但可占用SDCCH信道。
SDCCH资源占用次数可能增大百倍。
可能性二：
小区数据混乱，这种情况下锁闭一下小区然后重新解闭后如果还不行则将小区重新装载一下新数据。
（拆掉旧的再装新的）
TCHBlockingRate=（C1039+C1163/30）/（C1039+C1163/30+C1051/0+C1051/1+C1051/2）
TCH信道话务量（爱尔兰）=C1611/0+C1611/1
************************************************************************************
C1039：
由于没有TCH资源而造成TCH分配失败的次数，相当于C1613。
C1163/30：
当排序超时（T11）而释放的TCH分配请求。
C1051/0：
用作话务需求的TCH分配的数目。
C1051/1：
用作callreestablishment需求的TCH分配的数目。
C1611/0：
话务的TCH话务量。
C1611/1：
callreestablishment的TCH话务量。
可以由下面的图中看出拥塞的情况：
**********************************************************************************
方法一：
普通而见效明显的方法是扩容，增加载频的硬件数量。
方法二：
适当调低该小区对邻小区（无拥塞状况）的HoMargin值。
将其话务适当分流向其他小区，同时适当增加邻小区对该拥塞小区的Homargin值，使其他小区的话务不易切入本小区，从而降低该小区的TCH拥塞率（注意必须适度，当设置过大时切换失败率会上升）。
当调节小区的MARGIN时小区的切出切入边界都会改变。
参考下图：
方法三：
是打开HoTraffic的功能。
A:
对应开关键：
BSC及BTS上的“hotraffic”设为“enabled”。
B:
判断本小区是否拥塞：
numberOfTCHQueuedBeforeCongestion=1（建议值）
numberOfTCHQueuedToEndCongestion=2（建议值）
设置这两个参数才能使hotraffic功能真正有效，设置太大会造成频繁切换，降低切换成功率。
这两个参数只是一种内部判据，并非在统计中计入真正的拥塞，不对统计产生影响。
C:
偏置：
homargintrafficoffset=1/2/3dB
建议不要超过3，否则会造成切换失败增大。
D:
要切换去的待选目标小区的拥塞情况下的信号强度偏置：
offsetload=10dB
注：
开通homargintrafficoffset时，尽量用同一个BSS下的站来分担话务，这样可以在因拥塞切换前系统自动检测对方小区的话务拥塞状况再决定切换与否，尽量减小乒乓切换的几率。
打开阻止频繁切换的功能：
timebetweenHoconfiguration----BSC级，
btstimebetweenHOconfiguration---BTS级。
方法四：
是调高该小区对邻小区的RxlevDLPBGT，使手机更易切换到其它相邻小区。
（这种方法必须注意控制好限度，否则可能造成其它邻小区拥塞。
方法五：
调节一个区域内的各基站小区的天线，通过无线环境的改变来改变各基站的服务区从而改变话务承担方式。
方法六：
检查小区和它的邻小区是否工作正常，检查TCH可用性以确定不稳定设备。
如邻小区工作不正常，本小区会额外承担其部分话务。
下图可以表述TCH不稳定的情况：
****************************************************************************
（未考虑双频情况和基于SDCCH切换的情况）
下图列出了BSC内切换的信令流程：
（1）切换成功率=（C1073+C1074+C1067+C1068）/（C1071+C1065+C1072+C1066）
（很难反映因为目标小区拥塞而未执行的HANDOVERINDICATION；
在某些切换指标中可能会反映出来）
（2）NUMBEROFHANDOVERINDICATION
（1）
=C1138/0+C1138/1+C1138/2+C1138/3+C1138/4+C1138/5+C1138/6…+C1138/16
（3）NUMBEROFHANDOVERINDICATION
（2）
=C1075+C1076
（4）NUMBEROFHANDOVERCOMMAND（INTRABSS）=C1065
（5）NUMBEROFHANDOVERCOMPLETE（INTRABSS）=C1067
（6）NUMBEROFHANDOVERCOMMAND（INTERBSS）=C1066
（7）NUMBEROFHANDOVERCOMPLETE（INTERBSS）=C1068
（8）HANDOVERSELECTIONFAILURE=NUMBEROFHANDOVERINDICATION（1OR2）-（NUMBEROFHANDOVERCOMMAND（INTRABSS）+NUMBEROFHANDOVERCOMMAND（INTERBSS））
=SUM（C1138/X）-（C1065+C1066）OR=（C1075+C1076）-（C1065+C1066）
（9）HANDOVEREXECUTIONFAILURE=（NUMBEROFHANDOVERCOMMAND（INTRABSS）+NUMBEROFHANDOVERCOMMAND（INTERBSS））-（NUMBEROFHANDOVERCOMPLETE（INTRABSS）+NUMBEROFHANDOVERCOMPLETE（INTERBSS））
=（C1065+C1066）-（C1067+C1068）
*******************************************************************
（全部基于TCH的切换）
C1073：
BSC内部成功入切换的次数。
（HANDOVERCOMPLETE）
C1074：
BSC间成功入切换的次数。
C1071：
BSC内部执行入切换的次数。
（HANDOVERCOMMAND）
C1072：
BSC间执行入切换的次数。
C1065：
服务小区接收到的要从其切出的“HANDOVERCOMMAND”的数目（intraBSC）。
C1066：
MSC接收到的要从其切入的“HANDOVERCOMMAND”的数目（interBSC）。
C1067：
目标小区接收到的从其切出的“HANDOVERCOMPLETE”的数目（intraBSC）。
C1068：
因为切换成功而MSC接收到的从其切入的“CLEARCOMMAND”的数目（interBSC）。
C1075：
在HANDOVERINDICATION后BSC根据切换算法在备选小区中尝试选择一个目标小区的次数（INTRABSCOUTGING）。
C1076：
在HANDOVERINDICATION后当A接口上收到HANDOVERREQUIRED后BSC根据切换算法在备选小区中尝试选择一个目标小区的次数（INTERBSCOUTGING）。
C1138/0：
基于上行信号强度触发的“HANDOVERINDICATION”。
C1138/1：
基于下行信号强度触发的“HANDOVERINDICATION”。
C1138/2：
基于上行信号质量触发的“HANDOVERINDICATION”。
C1138/3：
基于下行信号质量触发的“HANDOVERINDICATION”。
C1138/4：
基于距离触发的“HANDOVERINDICATION”。
C1138/5：
基于PBGT触发的“HANDOVERINDICATION”。
C1138/X。
问题分析：
切换失败可以划分为两方面的问题：
即信道容量、无线链路失败。
HandoverSelectionFailure是从BSC到BTS的HO_COMMAND数与BTS收到的HO_INDICATION数之差。
它可以帮我们找出由于目标小区信道资源不足引起的切换失败。
HandoverExecutionFailure是数与BSC发向BTS的HO_COMMAND数与BSC收到的HO_COMPLETE之差。
主要反映了空中无线接口的质量。
注意切换失败次数决定一切，一定要搞清是那个站对本小区的切换失败占绝对影响。
首先查找空间位置，分析切换邻小区的定义是否合理。
（在CT7200中的HOANALYSIS表中可以清楚察看该情况）
如DRX或CMCF板或传输问题。
还有可能是天线方位错误；
天线端口对应错误或机柜上的DRX发射连线接错，被耦合到其它小区去发射了。
现象如下图所示：
（硬件问题在上下性的质量切换上体现的尤其明显）
如果两个小区有相同的（BSIC，BCCH），在正常的情况下这样的两个小区的相距距离应该足够大，他们之间不应该有什么关系。
但由于孤岛现象的存在，一旦孤岛覆盖周围的小区的邻小区表上定义了与孤岛小区同BSIC、BCCH的邻小区）位于的通话手机将会收到孤岛小区的BCCH信号并上报BSC，这个虚假的邻小区测试报告将会误导切换控制程序发出切换指令，这样就使得这些小区内的通话频频尝试向实际信号并不好的小区发出切换请求。
其结果往往造成乒乓切换，并导致孤岛覆盖周边小区的切出切换失败率大幅提高。
而与孤岛小区具有相同BSIC、BCCH的小区的切入切换失败率也将大幅提高。
检查切换执行失败率过高是否由孤岛效应引起。
作Abis测试并重点检查时间提前量（TA）有助于找出孤岛效应。
可增加孤岛小区的天线下倾角以减轻孤岛效应或改变它的BSIC以消除同BCCH，BSIC的现象。
找TA可以通过路测或者统计CT7100实现。
如果Hoselectionfailurerate切换选择失败率很高，原因可能是要切换的邻小区负荷高,目标小区已经没有可用TCH。
此时，BSC虽然收到HO_INDICATION信息但并不向目标小区发送任何HO_COMMAND消息。
对于一对邻小区上的高切换选择失败率，可查看目标小区的负荷以确认是否为负荷问题。
解决目标小区的话务拥塞就可以有效的改善该类切换失败。
路侧中发现的乒乓切换的现象见下图：
硬件问题。
排除硬件故障来解决。
在周围几个小区信号强度都差不多的情况下，往往容易发生乒乓切换；
体现为切换量大而且易掉话，切换失败高，信号质量差。
对于可能性二：
调整天线俯仰角使某个小区信号在该区处于最强（比其他小区强），有主服务区后乒乓切换的数量会减少。
在该处建新站或微蜂窝。
目的与方法一一样。
选取最佳信号的小区（RXQUAL）作为处理对象。
当入切换失败高时，调小切入本小区的其它小区对应的HOMargin值，提高邻小区（对切换次数影响大）对本小区的RXLEVPBGT门限。
当出切换失败率高时，对本小区到邻小区的参数采用类似方法设置。
方法四：
打开防乒乓切换的功能。
参数组为：
timebetweenHoconfiguration=used/notused：
在BSC级决定hopingpongtimerejection是否有效。
btstimebetweenHOconfiguration=0/1：
乒乓切换的拒绝时间能否在BTS级实现。
0：
乒乓拒绝时间无效
1：
乒乓拒绝时间有效。
HopingpongCombination=hoinitialcauseandhononessentialcause
：
表明禁止pingpong切换的具体切换类型。
Hopingpongtimerejection=18（s）乒乓切换的禁止时间。
覆盖；
如果目标小区与源小区之间没有足够的重叠覆盖区域，切换可能应无法登陆目标小区的TCH而失败。
在这种情况下，重新回到旧小区的概率会较低。
一旦怀疑，最好进行路测以便确认。
并采取相应的无线优化手段改善覆盖。
提高小区的覆盖可以通过减小下倾角或增加天线高度来实现。
但是这样可能会干扰其它邻小区。
如下图：
干扰；
干扰会造成即使目标小区的电平很好，但上/下行信号质量很差的情况移动台将难以占上目标小区的TCH。
如果来切换执行失败率很高，必须检查小区的干扰情况。
对每一对邻小区检查来/去切换执行失败率能够指明干扰是存在于某一对小区还是很多小区，并进而大致判断干扰区域和干扰性质。
如果去切换执行失败率很高，可能是因为切换发起小区的下行干扰。
移动台无法解码BTS发出的HANDOVER_COMMAND消息，这时由于T3103超时（计数器C1164/24），将产生掉话。
还有可能是目标小区的下行或上行干扰。
因此，需要认真检查每一对相邻小区，以帮助判断干扰原因。
同时检查目标小区的切换执行失败率和分配失败率的相关性。
干扰造成的高切换失败率往往伴随着高分配失败率。
为了确认小区的干扰，检查计数器“AverageLevelofNondecodedRACH
”，并且同时查看“RatioofHOonULQuality”和“RatioofHOonDLQuality”。
未解码RACH平均水平：
（averagelevelofnondecodedRACH）=C1033.
C1033：
仅针对未解码RA
升级会员 