华为技术培训资料-MF000405 拥塞率专题.ppt

MF000405拥塞率专题,ISSUE2.0,Page2,学习完此课程，您将会：掌握TCH拥塞率、SDCCH拥塞率的计算公式掌握TCH拥塞率、SDCCH拥塞率的统计点掌握TCH拥塞率问题、SDCCH拥塞率问题的原因以及常用处理方法,目标,Page3,内容介绍,第一章TCH拥塞率第二章SDCCH拥塞率,Page4,第一章TCH拥塞率1.1基本原理1.2原因及定位方法1.3案例,内容介绍,Page5,1.1TCH拥塞率基本原理,TCH拥塞率的定义TCH拥塞率(不包括切换)=TCH占用失败次数(不包括切换)/TCH占用请求次数(不包括切换)*100%=(TCH呼叫占用失败次数+极早指配的TCH占用失败次数)/(TCH呼叫占用请求次数+极早指配的TCH占用请求次数)*100%,Page6,1.1TCH拥塞率基本原理,TCH拥塞率的定义TCH拥塞率(包括切换)=TCH占用失败次数(包括切换)/TCH占用请求次数(包括切换)*100%=(TCH呼叫占用失败次数+极早指配的TCH占用失败次数+BSC内入小区切换TCH占用失败次数(由于拥塞)+BSC间入小区切换TCH占用失败次数(由于拥塞)/(TCH呼叫占用请求次数+极早指配的TCH占用请求次数+BSC内入小区切换TCH占用请求次数+BSC间入小区切换TCH占用请求次数)TCH拥塞率(遇全忙拥塞),Page7,1.1TCH拥塞率基本原理,TCH拥塞率的话务统计点：,Page8,1.1TCH拥塞率基本原理,TCH拥塞率的请求次数统计点TCH呼叫占用请求次数：(1)收到MSC的指配请求消息极早指配的TCH占用请求次数：(1)在分配SDCCH无资源时且及早指配允许时(2)在收到信道请求时信道类型为TCH时BSC内入小区切换TCH占用请求次数：(1)收到BSC内小区间入小区切换请求消息时(非SDCCH切换)BSC间入小区切换TCH占用请求次数：(1)收到入局切换请求消息时（切换类型为非SDCCH）,Page9,1.1TCH拥塞率基本原理,TCH拥塞率的失败统计点TCH呼叫占用失败次数:(1)在指配过程中收到CONN_FAIL消息(2)在出BSC切换过程中收到CLEAR_CMD,且切换原因为直接重试(3)在指配过程中收到CLEAR_CMD(4)在出BSC切换过程中收到RR_ABORT_REQ,且切换原因为直接重试(5)在指配过程中收到RR_ABORT_REQ(6)在出BSC切换(直接重试)中收到MSG_HO_REQ_REJ(7)在出BSC切换(直接重试)中收到HO_FAIL(8)在指配过程中收到ERR_IND(9)发送指配失败消息时(10)TN_T7(直接重试)超时(出BSC切换请求)(11)TN_T8(直接重试)超时(出BSC切换完成),Page10,1.1TCH拥塞率基本原理,TCH拥塞率的失败统计点极早指配TCH占用失败次数:(1)极早指配过程中收到CH_ACT_NACK(其中包括在卫星传输中的状态为WAIT_RR_EST时收到CH_ACT_NACK)(2)极早指配过程中分配信道时返回原因为(内部错误)CVI_INTERNAL_ERR(3)极早指配过程中分配信道时返回原因为(信道请求非法)CVI_NO_ACCEPT(4)极早指配过程中分配信道时未分配到信道(5)极早指配过程中的TN_WAIT_CH_ACT超时,Page11,1.1TCH拥塞率基本原理,TCH拥塞率的失败统计点BSC内入小区切换TCH占用失败次数(由于拥塞)：BSC内小区间入小区切换时分配到TCH信道失败BSC间入小区切换TCH占用失败次数(由于拥塞)：BSC间入小区切换时发送切换失败消息时原因为未分配到TCH信道时,Page12,1.1TCH拥塞率基本原理,TCH拥塞率的失败统计点分析A接口：MSC发来Asigment_req指配请求后，若A口中继电路故障，导致BSC直接回Assigment_refuse此情况一般为中继电路CIC数据配置错误,Page13,1.1TCH拥塞率基本原理,TCH拥塞率的失败统计点分析ABIS口与UM口：1、载频板故障或性能不稳定2、基站上下行电平不平衡引起的3、因存在干扰，上下行信号质量差引起的4、因SDCCH与SACCH(TCH)不属于同一块载频板，即两块载频板覆盖范围不同或SACCH(TCH)载频板故障,Page14,1.2TCH拥塞率原因及定位方法,TCH拥塞率高的原因：A口中继电路数据配置错误跳频小区的TSC与BCC不一致同频同BSIC导致切换时TCH指配失败单板故障或性能不稳定，引起高拥塞率基站硬件安装不规范，引起上下行电平不平衡，导致TCH拥塞小区下挂直放站，小区扩容后，直放站未扩容同一小区的主BCCH所在载频的发射功率大于TCH载频干扰引起拥塞孤站及地形复杂，TCH指配失败导致拥塞率,Page15,1.2TCH拥塞率原因及定位方法,TCH拥塞率高几种定位方法：远端分析拥塞率原因1、通过话统初步分析2、查看告警3、基站远端维护台4、使用信令分析仪测试分析ABIS口消息到基站近端进行检查,Page16,1.2TCH拥塞率原因及定位方法,远端分析之一：通过话统初步分析通过话统“小区TCH性能测量”，检查TCH拥塞率是否因遇全忙拥塞，若因遇全忙拥塞，可通过话务均衡手段，或建议扩容。若非遇全忙拥塞，分析拥塞率是否与干扰有关，即检查干扰带一干扰带五，此时该小区受干扰其掉话率也会相应偏高。登记“接收性能测量”话统任务：1、按照对象查询话统结果，同一载频板上下行测量报告数是否均衡，可初步判断为该单板上下行硬件支路不平衡；2、按照时间查询话统结果，检查同一小区内是否存在某载频测量报告数异常情况，初步可判断拥塞率与该单板相关。,Page17,1.2TCH拥塞率原因及定位方法,远端分析之二：查看告警检查拥塞率高的小区所属站点告警，是否存在异常告警，如存在驻波比告警、PCM失步告警、上行数据总线告警等，结合话统判断拥塞率是否与告警存在关联性。,Page18,1.2TCH拥塞率原因及定位方法,远端分析之三：基站远端维护台检查基站各单板软件是否统一，确认版本配套。使用基站远端维护台，轮流闭塞拥塞率高的小区载频板TCH信道，观察拥塞率是否与该小区载频板有关。,Page19,1.2TCH拥塞率原因及定位方法,远端分析之四：使用信令分析仪测试分析ABIS口消息跟踪拥塞基站的ABIS口消息，分析在SDCCH下发的指配命令AssignmentCMD，判断指配失败是否集中在某块TRX板上：若指配失败固定在某块TRX单板上，可以确定以下几种情况中的一种：1）TRX单板故障或性能不稳定2）上下行电平差导致，上行支路或下行支路硬件问题3）上下行信号质量差，结合手机TA值，初步确定哪路存在干扰。若指配失败随机分布在整个小区内的载频板上，分析测量报告，一般可能存在以下几种可能：1）因基站覆盖范围内，地形复杂2）存在整个小区内频点的干扰，如直放站的干扰；,Page20,1.2TCH拥塞率原因及定位方法,Page21,1.2TCH拥塞率原因及定位方法,基站近端检查近端维护，查看是否存在异常告警，并及时处理。检查上下行天馈支路是否存在硬件问题，如接头松动、天线是否接反、电缆连接错误、背板连线松动等同一地点用测试手机拨测，指配失败是否集中在某一频点，或随机分布通过网络优化软件ANT-PLOT进行路测，检查是否存在切换关系异常、下行干扰，从中找到拥塞率问题的切入点。使用频谱仪查找干扰源观察是否基站覆盖地形复杂,Page22,1.3TCH拥塞率问题案例,A口数据配置问题-案例一载频板单板故障或性能不稳定，引起高拥塞率-案例二上行硬件问题-案例三、四下行硬件问题-案例五、六小区下挂直放站的影响-案例七其它数据配置-案例八、九孤站及地形复杂导致拥塞率-案例十,Page23,1.3TCH拥塞率问题案例,现象描述某本地网有1个BSC，从某天开始，整网的TCH拥塞率变高（频率计划一直未做调整），全网TCH拥塞率（不包括切换）达4（遇全忙拥塞率很低）。且拥塞率变高的小区不是集中在某几个小区，而是很多小区。,Page24,1.3TCH拥塞率问题案例,分析思路：1、由于频率计划未做调整，所以排除无线口原因；2、大部分基站出现拥塞率异常，缩小范围，检查拥塞率异常的是否与模块、数据修改等有关；3、通过话统分析TCH占用失败的主要原因，最终定位数据或硬件故障问题。,Page25,1.3TCH拥塞率问题案例,处理过程：1、查看话统，在BSC数据修改加载后出现该现象，估计与此加载BSC有关。2、分析话统，发现拥塞率高的小区基本集中在BSC的1模块，大致定位到1模块。3、查看该模块TCH占用失败次数主要因地面资源不可用，说明地面资源不可用是造成1模块TCH拥塞率高的主要原因。4、地面资源不可用的主要原因可能在Abis或A接口电路上，因为1模块下很多小区都有此现象，Abis接口同时出现故障的可能很小，集中在A接口上硬件或数据上。5、A口硬件检查正常，排除A口硬件的可能6、检查A口中继电路数据配置，发现1模块0群前32个时隙CIC编号为65535，而在中继群表中1模块0群对应电路为BSC至MSC的电路，显然CIC号配错。将其改为031后再动态设定。拥塞率恢复正常。,Page26,1.3TCH拥塞率问题案例,结论：1、A口中继电路数据配置，CIC不能错误，否则会导致TCH指配失败，拥塞率高。2、同样，当两块FTC单板的CIC重复，即多条中继电路的CIC编号一样，也会出现该现象。,Page27,1.3TCH拥塞率问题案例,现象描述：某基站的配置为S6/4/2，一直都正常运行。从某天开始，该基站话务统计结果显示，1小区（6载频）的TCH信道溢出非常严重，拥塞率达到20%。1、该小区的话务量都非常低，一般忙时只有0.8Erl左右；2、同时，TCH占用遇全忙的次数为0；3、观察该1小区所有基带的信道状态，全部为“Idle”。,Page28,1.3TCH拥塞率问题案例,分析思路：1、由于未做任何数据调整，且该小区未跳频，有6块载频采用不同频点，同时收到外界干扰的可能性不大，所以排除无线口干扰和数据原因；2、重点检查硬件。由于只有1小区有问题，可通过轮流闭塞载频来确认是哪几块载频指配失败。3、确定指配失败载频的相关硬件是否有故障，通过复位、更换相关单板等一一确认。,Page29,1.3TCH拥塞率问题案例,处理过程：1、通过在基站远端维护中查看BT的信道状态，初步判断出该1小区的BT4、BT5有TCH占用失败的表象；2、闭塞BT4和BT5，同时闭塞RC4和RC5，发现全天的所有时段已没有TCH拥塞，表明确实是RC4、RC5两个载频有问题；3、解闭BT4、BT5、RC4、RC5，复位RC4（TRX4）、RC5（TRX5），仍然存在高拥塞；4、去该基站现场插拔TRX4、TRX5，进行锁频拨打测试（在TRX4、TRX5上），仍有TCH占用失败；对TRX4、TRX5互换槽位，进行锁频拨打测试（在TRX4、TRX5上），仍有TCH占用失败；5、更换TRX4、TRX5，进行锁频拨打测试（在TRX4、TRX5上），没有TCH占用失败现象，已没有TCH拥塞现象，问题解决。,Page30,1.3TCH拥塞率问题案例,结论：1、TCH载频板故障会导致TCH指配失败，拥塞率高。2、很多时候，载频板出现故障在基站维护台上无法看出，且TCH可用率也正常，可以通过轮流闭塞来确认。,Page31,1.3TCH拥塞率问题案例,现象描述：某基站配置为S6/6/6，从基站开通之后，3个小区拥塞率一直较高。通过检查确定不存在干扰。,Page32,1.3TCH拥塞率问题案例,分析思路：由于不存在干扰，且从基站开通之后一直都存在拥塞，每个小区都拥塞，其它基站没有类似现象，所以重点检查该基站硬件。1、硬件故障：每个小区都能够正常通话，每个小区硬件都故障的可能性不大。2、硬件连接：重点检查硬件连接。可通过话统分析故障出现在上行或下行，再检查上行或下行的硬件连接。,Page33,1.3TCH拥塞率问题案例,处理过程：1、登记话统“接收电平性能测量”，按照时间查询话统结果。发现同小区内不同TRX单板的相同接收电平、接收质量条件下，下行测量报告数比较均衡，但上行测量报告数明显的不平衡，且有一定的规律性。2、检查发现同一小区两个SPL级连半刚性电缆连接错误，更改后，问题解决。,Page34,1.3TCH拥塞率问题案例,Page35,1.3TCH拥塞率问题案例,Page36,1.3TCH拥塞率问题案例,结论：硬件连接错误会导致TCH指配失败。通过不同的话统任务分析可以准确定位问题。本案例利用“接收电平性能测量”定位出上行硬件接收存在问题。,Page37,1.3TCH拥塞率问题案例,现象描述：某基站（S6/6/6配置，BTS20)在正常运行一段时间后，发现1小区的拥塞率（不含切换）升高，达到20，经过轮流闭塞发现是第三块载频板TCH指配失败，且更换相应的单板无效。,Page38,1.3TCH拥塞率问题案例,分析思路：由于在出现故障前后没有做任何参数调整，且只有第三块TCH载频指配失败，所以要重点检查与第三块载频板相关的硬件是否出现故障，是否有相关告警。,Page39,1.3TCH拥塞率问题案例,处理过程：1、查询告警，通过近端维护查看TRX告警信息为CUI链路告警，该类告警一般都是硬件故障导致，更换TRX3和FPU3单板，故障依旧；2、将该槽位上的单板和正常槽位的单板互换，该槽位现象依旧，而更换过去的单板则工作正常，说明单板没有问题，但槽位有问题。3、观察3号槽位的FPU告警为上行链路告警，估计是槽位接触不良或者母板出现问题，将该机柜拆下，把机柜内通信电缆重新插拔一遍后重新上电，发现FPU告警消失。观察20分钟后，故障不再出现，拥塞率恢复正常，以为故障已经排除；4、第二天观察话统，故障又出现，时间为重新安装机柜后两个小时后。于是更换基带框母板和载频框母板，但是出现的情况和上面一样。5、更换机柜内部通信电缆，观察两天，故障不再出现，问题解决。,Page40,1.3TCH拥塞率问题案例,结论：硬件故障不仅是TRX板故障，也有可能是母板、内部通信电缆、槽位等有故障，这些都会导致TCH指配失败。,Page41,1.3TCH拥塞率问题案例,现象描述：某基站S6/6/5，从某天开始，有一个小区出现高拥塞率，期间没有做任何调整。,Page42,1.3TCH拥塞率问题案例,分析思路：由于在出现故障前后没有做任何参数调整，重点关注硬件是否出现故障，是否有相关告警。,Page43,1.3TCH拥塞率问题案例,处理过程：1、使用信令分析仪MA10跟踪该基站的ABIS口消息，分析信令发现，在出现TCH指配失败过程中，BSC下发ASSINMENTCMD指配命令后，测量报告中上行信号很好，但下行信号电平无法解析，即上下行信号电平不平衡，然后回ASSIFAILURE指配失败消息。并且发现都是指配该小区的最后一块TRX单板上。2、临时闭塞该TRX单板信道，该小区拥塞率降低到1%左右。估计该TRX单板及其下行链路硬件存在问题。3、检查发现，该TRX单板所连的合路器上有发射天馈驻波比超过2.5告警，解决天馈驻波比告警问题解决。,Page44,1.3TCH拥塞率问题案例,结论：天线驻波比告警导致损耗大，覆盖范围减少，从而指配失败。当手机处于小区BCCH覆盖范围，但不在驻波比告警单板覆盖范围时，一旦指配到该载频，很容易导致指配失败，造成小区拥塞率过高。,Page45,1.3TCH拥塞率问题案例,现象描述：某基站S6/6/6，在开通后，前两个小区的拥塞率较高，第三小区拥塞率正常。经过确认，不存在干扰。,Page46,1.3TCH拥塞率问题案例,分析思路：由于在开通后拥塞率就异常，且有一个小区正常，可以重点检查数据和硬件。,Page47,1.3TCH拥塞率问题案例,处理过程：1、用信令跟踪仪跟踪这两小区的ABIS口消息，发现指配失败一般在后两块载频上，当ASSIGNMENTCMD中指配到每个小区的后两块TRX单板时，上下行信号不平衡，导致指配失败。2、在距基站50米处，对每小区最后两块载频板每个时隙进行拨测，未出现指配失败情况；3、再次跟踪分析ABIS口消息，发现指配失败时一般手机在TA=2（即1.1Km处）；于是在距基站12Km处拨测，发现当指配到后两块载频板上的TCH时，基站下行电平有明显降低，怀疑为后两个载频发射支路的问题。4、从下行发射支路TRXHPA合路器避雷器天线，逐段检查，最终发现问题在两个小区后两块载频的发射支路馈线接反，更改后问题解决。,Page48,1.3TCH拥塞率问题案例,结论：由于在同一小区内主BCCH载频的发射的方向和后两块载频的发射的方向不同，导致覆盖范围不同，所以会引起指配失败。,Page49,1.3TCH拥塞率问题案例,现象描述：某基站O2扩容为O4后，出现高拥塞率，最高时达到40%。,Page50,1.3TCH拥塞率问题案例,分析思路：由于在扩容后拥塞率出现异常，可以：1、先检查出现拥塞的是否为所有载频，如果是，则重点检查基站的新增硬件的连接，故障等。2、如果出现拥塞的为其中之一个或几个载频，则重点检查这几个载频的硬件。3、排除硬件原因后，要考虑是否存在外界原因，如存在直放站没有扩容，导致指配失败。,Page51,1.3TCH拥塞率问题案例,处理过程：1、远端基站维护台闭塞后两块新增载频TRX，发现拥塞率大幅度降低到正常水平，估计与这两块单板有关；2、跟踪分析ABIS口的信令，指配失败发生在新增两块载频上。当指配失败时，从SDCCH上的测量报告分析，SDCCH上的电平正常，且TA值较大，即一般发生在较远的地方，但无SACCH（TCH）上的测量报告，估计这两块单板上下行支路硬件故障。但这两块单板也有指配成功的情况，排除了单板故障情况。3、因该小区采用了四合一合路器及一分四分路器，排除了天馈部分硬件故障；检查TRX单板到合分路器的半刚性电缆，未发现硬件问题。基本排除硬件原因。4、通过询问得知在此小区下挂了一个直放站，扩容后直放站没有锁定新增两个载频，导致指配失败。解决直放站频点问题后，拥塞问题解决。,Page52,1.3TCH拥塞率问题案例,结论：由于直放站关系，同一小区后两个载频与前两个载频的覆盖范围不一致，引起指配失败。,Page53,1.3TCH拥塞率问题案例,现象描述：某地州进行网络规划，修改一些网规参数后，观察话务统计指标，发现有一个基站的TCH指配成功率变低。,Page54,1.3TCH拥塞率问题案例,分析思路：由于在修改了网规参数后，这两个小区的指标变差，重点检查已修改的数据。看是否对TCH指配有影响。,Page55,1.3TCH拥塞率问题案例,处理过程：1、观察话统其它指标均正常，且指配失败中立即指派失败次数和切换指派失败次数都很高，而其它站点规划后指标正常；2、检查网络规划拓扑图，发现该基站网络规划后没有与其它基站存在同频和邻频干扰；3、现场检查该基站干扰情况，未发现有较大的异常干扰，该基站各小区话务量中等，未出现遇全忙拥塞现象。4、检查所更新的数据表，跳频数据表、频点号等未发现错误；5、检查BSC小区表和跳频数据表，发现基站色码与跳频训练序列号不一致，修改数据，使二者一致，动态设定整表，观察话统情况，故障消除。,Page56,1.3TCH拥塞率问题案例,结论：在跳频小区里，TSC与BCC一定要保证一致，否则会导致SDCCH和TCH指配失败。话统指标表现为：TCH拥塞率升高，SDCCH占用失败次数增多。,Page57,1.3TCH拥塞率问题案例,现象描述：在某本地网的优化过程中，有两个小区忙时小区的拥塞率（含切换）很高10，“不含切换的拥塞率”和“占用遇全忙拥塞率”正常。其中“指配占用失败次数（所有的）”很高，分别为89次和61次，但是“TCH呼叫占用失败次数”却均为0。话务量比优化前有所下降。干扰带正常。优化之前拥塞率正常。,Page58,1.3TCH拥塞率问题案例,分析思路：由于在优化修改网规参数后，两个小区的拥塞率变差，且只有含切换的拥塞率变差，所以可以排除无线干扰、硬件故障等原因，重点分析切换是否异常。,Page59,1.3TCH拥塞率问题案例,处理过程：1、登记这两个小区的15分钟“入小区切换性能测量”，发现都是一个特定小区（CGI=*1768）向这两个小区的切换全部失败，而且不是因为真正拥塞导致的切换失败。2、切换全部失败，说明切换数据存在问题，检查这两个小区的切换数据，果然是同频同BSIC，这两个小区同时是特定小区的邻小区，所以导致特定小区切向其中任何一个小区时都失败，且失败是在指配TCH信道时就指配失败。3、修改了这两个小区的BCCH和BSIC后，切换正常，拥塞率正常。,Page60,1.3TCH拥塞率问题案例,结论：1、同频同BSIC的两个小区（这两个小区都是某一小区的邻区时）不仅会导致入小区切换成功率低，同样会导致TCH拥塞率（包括切换）很高。2、该案例显示了TCH拥塞率（包括切换）与TCH拥塞率（不包括切换）的区别。,Page61,1.3TCH拥塞率问题案例,现象描述：在某郊县O2站从开通之后拥塞率（不含切换）就比较高，310（与话务量成正比），但占用遇全忙拥塞率为0。1、轮流闭塞2块载频，拥塞率没有改观。2、其它指标：掉话率偏高（5左右），干扰带正常。,Page62,1.3TCH拥塞率问题案例,分析思路：1、由于拥塞率不是很高，所以数据问题和硬件故障的可能性不大。2、干扰带也正常，无线口的干扰原因也可以不考虑。3、重点分析指配失败是什么原因，结合掉话率高一起考虑，分析上下行的接收性能，包括电平、质量等。,Page63,1.3TCH拥塞率问题案例,处理过程：1、查看“掉话性能测量”，发现掉话时TA值比较大，在离基站25.6km到31.1km处。2、查看“接收电平性能测量”发现电平等级低的测量报告数比较多。3、通过分析其ABIS口的信令，发现指配失败时上行电平都很低（98dbm左右）。4、到基站实地路测，此站为一个孤站，覆盖范围很大，地形条件很复杂。当手机离基站距离25公里以上，还能收到90dbm的下行信号，但由于上行信号不够，导致TCH指配失败。,Page64,1.3TCH拥塞率问题案例,结论：1、上行覆盖差导致拥塞率高。可以通过：增加基站，形成连续覆盖；全向站改为定向站，通过调整天线方向角及倾角；增强发射电平和基站接收灵敏度，同时避免产生越区覆盖。2、在基站维护台上通过跟踪Abis口的消息，可以分析指配情况。,Page65,内容介绍,第一章TCH拥塞率第二章SDCCH拥塞率,Page66,第二章SDCCH拥塞率2.1基本原理2.2原因及定位方法2.3案例,内容介绍,Page67,2.1SDCCH拥塞率基本原理,计算公式：SDCCH拥塞率SDCCH占用遇全忙次数/SDCCH占用请求次数SDCCH占用遇全忙次数：SDCCH占用失败是因为遇全忙SDCCH占用原因包括：1）主叫的指配命令下发通道2）被叫的寻呼响应上发通道3）位置更新4）短消息5）IMSI分离、附着过程,Page68,2.1SDCCH拥塞率基本原理,Page69,2.2SDCCH拥塞率原因及定位方法,位置区边缘导致SDCCH位置更新过多导致策略：修改位置区选择修改CRH（小区重选滞后参数）修改周期位置更新的参数设置修改双频网的频繁切换问题过多的发短消息、天气预报策略：不要集中发射增配SDCCH信道,Page70,2.2SDCCH拥塞率原因及定位方法,系统容量不够大：SDCCH配置过少策略:扩容系统参数设置不好、RACH的系统参数、实际多重指配SDCCH。策略：适当加大RACH接入门限（应付干扰）适当减小最大重发次数、加大扩展传输时隙数单板（TRX/FPU）故障、传输故障导致SDCCH拥塞,Page71,2.3SDCCH拥塞率问题案例,【现象描述】某本地网无线接通率偏低，从话统上分析其主要原因为少数几个站SDCCH拥塞。,Page72,2.3SDCCH拥塞率问题案例,【分析思路】由于拥塞集中在几个基站，通过登记“SDCCH性能测量”分析这些小区SDCCH占用时各类占用原因的比例，着重解决。,Page73,2.3SDCCH拥塞率问题案例,【解决过程】1、分析话统：出现拥塞的小区忙时有300-400次SDCCH占用，均为S1/1/1基站，每个小区均配置8个SDCCH/8信道，按常理足够应付3、4百次SDCCH占用，奇怪的每个小区忙时均是出现了几十次不等的SDCCH拥塞。2、登记“SDCCH性能测量”：发现SDCCH占用中，绝大部分为位置更新造成。结合基站所处位置，发现上述拥塞基站大部分处在铁路线两个位置区交界处，由此联想到可能是突发的位置更新导致SDCCH拥塞。3、登记五分钟的“SDCCH性能测量”话统，发现位置更新大部分集中在某五分钟之内。后查询列车时刻表，该时段有四到五列客车经过，原来列车经过时，大量的突发位置更新集中在很短的时间内进行，导致拥塞。4、增加SDCCH配置，或者打开SDCCH动态分配功能。,Page74,2.3SDCCH拥塞率问题案例,【结论】位置更新导致的SDCCH拥塞需要查明是否是位置区设置不当。本案例属于特殊情况，可通过增加SD的配置或开启动态分配功能来解决。,Page75,2.3SDCCH拥塞率问题案例,【现象描述】某基站最近由O2站改为S2/1/1站（BTS20），一段时间来用户投诉通话断断续续，听不清楚。近2日该站2小区突然出现SDCCH严重拥塞，忙时SDCCH拥塞次数达到35000次/60分钟，拥塞率为60，且有用户投诉话音断续。,Page76,2.3SDCCH拥塞率问题案例,【分析思路】扩容之后，不仅SDCCH拥塞，通话也有断续。说明SDCCH不是真正遇忙拥塞，而是单板或者传输出现故障，导致SDCCH占用失败。先排除干扰，重点检查硬件。通过查询告警、复位、更换单板等手段定位。,Page77,2.3SDCCH拥塞率问题案例,【处理过程】1、用户投诉话音断续问题后，远端查看该基站无任何告警。2、SDCCH严重拥塞问题出现后，远端复位基带无效，SDCCH拥塞仍达30000次/60分钟。再四级复位基站，SDCCH异常拥塞问题基本解决（降为5左右）。但用户仍然投诉话音断续和失真。偶有OMU主备通信故障，有时有FPU单板通信告警，但持续时间只有3-4秒钟。3、到基站现场处理，机柜面板无告警灯点亮，近端维护未见任何告警，单板状态全部正常。4、到现场锁频拨测2小区，发现有时很容易拨通，但有时不易拨通。拨通后通话质量不好，话音失真，断断续续。,Page78,2.3SDCCH拥塞率问题案例,【处理过程】5、经检查确认无网内和网外干扰。6、检查天馈系统，包括驻波是否正常，有没有小区馈线接反带来的上下行不平衡问题，有无打开上下行功控和DTX等。以确定是否信号强度问题导致通话质量下降。结果发现都很正常。7、更换2小区载频的FPU，与旁边正常工作的FPU交换，发现该载频话音质量马上变得清晰。但旁边的载频话音失真、断续。证明是FPU故障引起话音失真和断续。8、更换故障FPU，问题解决。SDCCH拥塞率也降为0.1。,Page79,2.3SDCCH拥塞率问题案例,【结论】1、SDCCH严重拥塞，常见原因有FPU故障，传输中断但功放开启，传输闪断，软件运行不正常等因素。在确认传输没有问题的情况下，一般需要检查单板是否正常，以及基带软件运行是否正常。本例中未发现传输闪断，应是单板故障或SCP软件运行故障。单板自身硬件或软件工作不正常，导致SCP部分上报很多虚假的SDCCH占用信息。软件运行失常可以通过复位FPU单板或基站软件解决。2、话音断续，应是话音通道问题。手机话音通道为：MS空中接口基站天馈TRXFPU42BIE（BSMU）两侧的DDF架和传输线路32BIEBNETOPT-FBICTNE3MTCSMMSC。本例中该基站其它两个小区与2小区共用一对传输，应可排除ABIS接口以上部分问题（如果网板交换有误，则3个小区甚至整个BM模块都会出现话音问题。而A接口也是共用的，BM模块的HW线虽是怀疑对象，但由于该小区只占用了8个时隙，HW线导致问题的可能性很小），排除干扰，天馈等原因后定位为单板问题。,Page80,2.3SDCCH拥塞率问题案例,【现象描述】新开BTS30基站，开通后SDCCH信道一直基本上处于全忙状态（A），TCH信道为（I）或（A）状态，能拨通后通话正常。观察话统SDCCH分配失败次数在一千次左右（忙时）。,Page81,2.3SDCCH拥塞率问题案例,【分析思路】1、由于从基站开通SDCCH就拥塞，但TCH正常，且通话也正常，先检查数据和硬件。整个基站都拥塞，可通过与其它同类型基站端口对调，确认是否存在数据或Abis口以下的硬件问题。逐段检查确认。2、如果排除数据和硬件原因，可重点检查传输是否存在故障。,Page82,2.3SDCCH拥塞率问题案例,【处理过程】1、检查告警：LAPD链路故障告警和恢复告警（在一秒之内），告警频度在十分钟左右出一次。2、检查数据没有问题，同时在夜间与其它同型基站32BIE端口对换，其他基站工作正常，该站现象依旧，可以排除数据问题和BSC侧硬件问题；3、由于基站距市区较远首先进行传输有关话统登记，察看结果（传输相关）没有异常，但SDCCH话统依然异常；4、更换基站TMU、TRX单板现象依旧；5、测量传输，自环32BIE端口指示灯有时会闪，发现传输有误码，后通过逐段测试定位在某县到基站所走一段接入网有一2M传输单板有问题，更换该单板问题解决（两基站在同一块单板）。,Page83,2.3S