无线网络优化经验研究报告系列报告-SDCCH拥塞率高的分析处理

-.zSDCCH拥塞率高的分析处理目录TOC\o"1-6"\h\z\uSDCCH拥塞率高的分析处理〕直到小区不再出现AGCH或SDCCH信道过载情况。根据上述原则，可以确定T值的取值*围〔对应参数S的每个取值参数T可以取数个〕，当小区RACH冲突数较大时，应取较大的T值〔在上述*围内〕；在RACH冲突数较少〔定量分析需在实验以后进展〕的情况下，应使T值尽可能小。注意：移动T*_integer(T)的默认值为“12〞即20个RACH时隙。2、RACH的流量控制：系统通过RSS来监测在一定的时间内〔rach_load_period〕收到的channelrequest消息个数。如果收到的个数超过门限rach_load_threshold，则RSS向callprocessing发负载指示消息。一旦收到负载指示消息，callprocessing将随机BAR住一个接入级别(0-9)的手机。同时CP启动计时器T1和T2(flow_control_t1和flow_control_t2)。当T1超时后，假设CP再收到从BSS系统传来的负载指示消息，则CP将再BAR住另一个级别的手机。假设在T2的时长内，CP没有再收到从BSS传来的负载指示消息则系统将UNBAR一个级别的手机。T2的取值必须大于T1。FigureRACHflowcontrol第一个被BAR住的级别是由CP随机选择的，此后被BAR住的级别遵循循环的原则，从低级别到高级别。随后被UNBAR的级别在其它所有级别均被BAR过前，不会再被BAR住。第一个被UNBAR的级别是BAR住时间最长的级别。计时器rach_load_period和ccch_load_period都是235.5mS(1*51frame)的整数倍。rach_load_period决定了rachload监测的时间周期。只有在前一个周期内(RACHorCCCH)触发了过载条件ccch_load_period才会开场计时。门限rach_load_threshold由下面的公式计算得到：RACHloadthreshold=Totalnumberofchannels(TCH/SDCCH)*100NoofRACHsinperiod*NoofRACHtimeslots其中：分子是小区内配置的SDCCH子时隙和TCH的个数。分母是在4*51帧的复帧周期内可用的RACH时隙数。这个值取决于ccch_conf的设置。结果为rach_load_threshold，以0.01%为间隔。注意：由于移动的网络不支持用户的分级，所以上述RACH的流量控制实际效用不大。3、启动立即指配拒绝功能缓解SDCCH拥塞：在GSM规*中定义了立即指配拒绝的功能：当目前网络没有可以分配的SDCCH信道时，就可以通过发送给手机一条立即指派拒绝〔immediateassignmentreject〕的消息来拒绝手机的信道申请，并且在系统规定的时间内〔Wait_indication_parameters即T3122〕制止手机接入网络，通过这种功能可防止在系统没有SDCCH资源的情况下用户频繁的发送信道请求的消息，而不必要地增大网络的负荷。Wait_indication_parameters：BSS小区级参数，即定时参数T3122；参数“等待指示〞的取值*围是0～255的整数，以秒为单位，表示手机必须等待的时间。参数“等待指示〞包含于下行消息“立即指配拒绝〞之中。当网络收到手机发送的信道请求消息后，假设没有空闲的SDCCH信道分配给手机，则网络通过AGCH信道发送“立即指配拒绝消息〞给手机。为了防止手机不断进展信道请求而造成无线信道的进一步阻塞，在立即指配拒绝消息中包含定时参数T3122，即所谓的等待指示信息单元。手机在收到立即指配拒绝消息后必须经过T3122指示的时间后才能发起新的呼叫。参数“等待指示〞〔T3122〕实际上是当网络中的无线资源缺乏时，强制手机在一次试呼失败后、发起新一次试呼前必须等待的时间。因此它的取值对网络性能的影响较大。T3122设置过短，则在无线信道负荷较大时容易引起信道的进一步阻塞；但假设T3122设置过大则使网络的平均接入时间增加而导致网络平均的效劳性能下降。注意：T3122设置的原则是：在网络的公共控制信道〔CCCH〕不发生过载的情况下，应使T3122尽可能小。一般建议T3122的一般设置为10～15秒，在业务量密集地区设置为15～25秒。但是，由于在T3122生效的时间内用户的手机外表看没有任何反响，此参数的设置一般不要取值过大，防止引起用户的强烈反映。案例分析：为了减小SD的拥塞，4月21日，我们对全网的T_3122参数进展了尝试性调整，将局部SDCCH拥塞率较高的基站的T_3122由8秒调整到了15秒。从4月17日与4月24日的统计比照来看全网的SDCCH的拥塞率有所减少。全网SDCCH成功分配次数SDCCH分配失败次数SDCCH话务量SDCCH拥塞率4月17日2078197797342186.863.69％4月24日2135049300972228.111.39％增大SDCCH配置缓解由于增值业务量的增加导致的拥塞现在的GSM网络所提供的业务中，有一局部增值业务是由SDCCH信道承载，例如短信消息等。如果增值业务在时间上集中引入，很可能导致网络SDCCH信道出现突发且较大面积的拥塞情况。2001年5月17日，移动开通了神州行手机用户的短信息业务，由于当时移动已经拥有了相当规模的神州行用户，且公司前期市场宣传工作做的比拟到位，当天大量神州行用户尝试使用短信息，引起网络内短信息的收发次数激增，无线侧引发了大量的小区SDCCH拥塞。cm_req_smssms_inisial_on_sdSD_BLKSDCCH话务量sum5月16日23032472730.814168.545月17日923031480491.664402.21出现这种情况后，只能及时增加具体每个出现SDCCH信道拥塞的小区的SDCCH配置，以缓解网络拥塞情况。但为了尽可能防止类似的事件再次发生，应加强网络运行维护部门与市场部门的沟通，有预见性地采取一些预防措施。承受此次教训后，我们在此后的节假日等易于引起短信息等增值业务突发的时候，及时且适量地调整了网络的配置，防止了上述在无线侧拥塞情况的再次发生。存在覆盖或话务的不均衡问题当出现SDCCH信道拥塞后，分析得出SDCCH的拥塞率与TCH的拥塞率不均衡，或者基站的覆盖与周边基站的覆盖没有合理地进展控制，则可以采用以下的均衡方法进展处理：假设TCH信道很闲，可以开启SDCCH的重配功能，调整本小区的SDCCH与TCH的信道比例；假设开启了SDCCH的重配功能，但参数设置不合理或不正确也可能造成SDCCH的拥塞；由于基站的覆盖过大，引起SDCCH拥塞，可以对用户的起呼进展距离上的限制；假设基站的C2设置不合理，可能造成基站过多地吸收了话务，从而导致基站SDCCH拥塞率比TCH的高。基站SDCCH与TCH信道配置不合理假设TCH信道很闲，可以开启SDCCH的重配功能，调整本小区的SDCCH与TCH的信道比例由于在基站的资源分配中，SDCCH与TCH均要占用基站的物理信道资源，在基站构造配置中实际上存在SDCCH与TCH的平衡问题，通常SDCCH与TCH在开站时被固定分给一定的信道，但由于网络承载的话务是不断变化开展的，为了适应这种变化，保持SDCCH与TCH在资源的使用上的合理分配，启用基站的SDCCH信道重配功能，可以有效地、动态地根据实时的用户需求，调整SDCCH与TCH之间的资源分配，尽可能地防止出现二者忙闲不均的情况。信道重配：在呼叫处理的过程中BSS的软件CRM进程可以进展动态信道重配，例如：SDCCH信道的使用比例很大，同时还继续有SDCCH信道的申请，此时当满足一定门限后，CRM可以将TCH信道重新配置成SDCCH信道，以满足SDCCH的需求。涉及到的BSS参数：ccch_conf：BSS小区级参数；参数ccch_conf由3比特组成，常用的取值有：0表示non－bined方式，CCCH使用一个根本的物理信道，不与SDCCH共用；1表示bined方式，CCCH使用一个根本的物理信道，与SDCCH共用。根据一般的经历，对于小区中的载频数为1个或2个的情况，建议公共控制信道的配置采用一个根本物理信道且与SDCCH共用；小区中的载频数超过2个的情况，建议公共控制信道的配置采用一个根本物理信道且不与SDCCH共用。Channel_Reconfiguration_Swith：BSS小区级参数；参数的取值可以决定CRM可否进展动态信道重配。Number_Sdcchs_Preferred：BSS小区级参数；定义了在系统重启时CRM配置SDCCH的个数，同时小区SDCCH的信道个数。这个参数的取值受限于该小区的信道配置方式是bined或non－bined。Ma*_number_of_sdcch：BSS小区级参数；定义了信道重配后SDCCH的最大个数。发生TCH至SDCCH信道重配的条件：信道重配后SDCCH的最大个数不能超过Ma*_number_of_sdcch；空闲的SDCCH信道个数要少于sdcch_need_high_water_mark；当前空闲的TCH信道个数要大于tch_full_need_low_water_mark；发生SDCCH至TCH信道重配的条件：重配后的SDCCH信道个数不能少于Number_Sdcchs_Preferred；当前空闲的SDCCH信道个数要大于sdcch_need_low_water_mark；SDCCH信道的配置一般遵循以下原则：在小区载频数<2的情况下，此时CCCH配置方式一般为bine方式，因为SDCCH要与CCCH共享BCCH载频的TS0，这种情况下的SDCCH的实际个数为n×8＋4，其中n代表除BCCH外又给SDCCH配置的时隙个数。对于这样的小配置基站，n取值一般为1，SDCCH最小值则为12；SDCCH最大值可以为20。载频个数在2到4之间的小区，CCCH配置方式一般为nonbine方式，SDCCH的实际个数为n×8，n取值一般为2，SDCCH最小值则为16；SDCCH最大值可以为24。载频个数>4之间的小区，CCCH配置方式一般为nonbine方式，SDCCH的实际个数为n×8，n取值一般为3，SDCCH最小值则为24；SDCCH最大值可以为32。注意：sdcch_need_low_water_mark>=Number_Sdcchs_Preferred；sdcch_need_low_water_mark－sdcch_need_high_water_mark>=9；在日常的优化中，要观察每天的SDCCH和TCH拥塞的情况，对于不正常的配置情况要及时纠正，防止出现一边空闲，一边拥塞的现象。从全网统计到的数据按照SDCCH拥塞作为主关键字，TCH拥塞作为次关键字，进展从高到低排序，在TCH信道无拥塞，而SDCCH信道拥塞严重时，可考虑将一个TCH信道重配为8个SDCCH信道。案例分析：1、由于近几周全网SDCCH拥塞状况有上升趋势，我们选定局部典型基站做实验性修改，翻开CELLRECONFIGURATIONSWITCH。启用SDCCH动态分配原则，Preferred_number_of_sdcch按通常的规划方法设定,并设定相关参数：Channel_reconfiguration_switch=1Ma*_number_of_sdcch=24Sdcch_need_high_water_mark=2Sdcch_need_low_water_mark=12Tch_need_low_water_mark=3结果说明拥塞状况有明显改善，前后比照见下表。现在全网除个别基站外，此功能均已翻开。下表是全网改动前后的性能比拟：date_and_timesum_alloc_sdcch_failsum_alloc_sdcchsum_alloc_tchsum_alloc_tch_failTCH拥塞率SDCCH拥塞率8-204534377508374561412677914.535.528-234148480985271461510825513.154.878-206425082793675787815872817.317.208-232755981210375380113326615.023.282、西三旗和五棵松村在一定程度上存在TCH与SDCCH忙闲不均的情况，采取以下措施后这些小区的TCH拥塞与SDCCH拥塞得到了均衡。CID786：将Ma*_number_of_sdcchs从32增加到48，number_sdcchs_preferred从24增加到32；CID840：将Ma*_number_of_sdcchs从32增加到48，number_sdcchs_preferred从16增加到24。site_namecell_nameSDCCH拥塞CALL_SETUP_SUCCESS_RATETCH拥塞TOTAL_CALLSavail_tch_ma*erl/chantimeWuKeSongCun_16460-00-4112-8407.3296.6701047370.473-1WuKeSongCun_16460-00-4112-8401.7696.080.031104360.583-2*iSanQi_6460-00-4110-7867.4496.860990360.583-1*iSanQi_6460-00-4110-7862.6697.100.051107340.583-23、万柳桥西北DCSCID30289的SDCCH拥塞较高，但TCH不存在拥塞情况，话务掉话比拟低。处理过程：将number_sdcchs_preferred：16——32；ma*_number_of_sdcchs：32——48；site_namecell_name掉话次数sd拥塞TCH话务量date_and_timeWanLiuQiao*iBeiDCS460-00-4144-3028917.281.516-25WanLiuQiao*iBeiDCS460-00-4144-3028910.001.356-284、在11月18日对网上所有CELL的channel_reconfig及其有关参数进展了相应的调整，减小了TCH和SD拥塞，同时提高呼叫成功率，也可以使当前的无线资源能有更高的利用率，防止了由于TCH,SD分配不合理，造成的一方拥塞而另一方空闲的资源浪费。改动的具体参数如下：number_sdcch_preferred:8,16,24ma*_number_of_sdcchs:16,24sdcch_low_water_mark:10,18,26sdcch_high_water_mark:2tch_full_need_low_water_mark:3改动前后小区性能变化如下：SDCCH11-1611-25cell_nameSDCCH拥塞SDCCH话务量SDCCH拥塞SDCCH话务量460-00-4160-75950.969.070.1610.74460-00-4130-8150.357.059.5411.38460-00-4130-7948.967.0412.8112.02460-00-4160-54831.435.910.475.01460-00-4120-12228.4813.664.3216.07460-00-4170-62624.106.821.226.11460-00-4170-62151.6618.0229.9221.93460-00-4170-62223.8713.902.6813.41TCH11-1611-25cell_nameTCH拥塞TCH话务量avail_tch_ma*TCH拥塞TCH话务量avail_tch_ma*460-00-4142-78526.4317.43216.6515.6022460-00-4172-69824.9124.97295.7222.0130460-00-4172-96427.3525.17298.8122.9830460-00-4160-91743.4126.712925.7925.7230开启了SDCCH的重配功能，但参数设置不合理或不正确如果优化人员在配置SDCCH的重配功能时，没有满足BSS的约束条件，则可能发生SDCCH不能正常重配的情况，很可能会出现SDCCH拥塞的现象。与周边基站相比本小区的覆盖不合理相对自身信道配置以及与邻区话务来说，如果基站的实际覆盖*围过大，可能导致它实际承载了过多的手机的网络效劳需求，这样很容易产生SDCCH信道拥塞。当出现这种情况后，针对基站覆盖偏大的情况，采取有效措施来收缩基站的覆盖，从而降低基站承载的用户数，减小SDCCH信道的拥塞。常用的方法有：在距离上限制距基站较远的用户接入本基站；调整基站的小区重选的参数设置。人为限制手机接入的距离收缩基站实际覆盖*围缓解SDCCH拥塞对于偏远的地区，由于基站建立力度不够，在有些距离基站较远的地方手机信号较弱，如果手机在这些地方尝试向网络发起效劳请求或响应网络的寻呼，由于距离基站过于远，信号衰减较大，手机接收质量很差，这样手机很可能不能正常地接入到网络中，反而由于手机频繁尝试发起接入请求而造成网络资源被大量占用。为防止这种距离基站过远的手机接入到基站中，我们可以翻开网络限制，将这些资源请求拒绝掉。涉及到的参数有：poor_initial_assignment：BSS级参数；该参数的置位可以让BSS在收到手机发来的RACH消息后，分析其TA值，假设超出ms_ma*_range的*围后，则网络将该RACH请求放弃掉，而不作任何响应，这样做可以将一些距离较远、质量可能较差的RACH消息限制在网络承受*围之外；ms_ma*_range：BSS小区级参数；当手机和基站的距离超过一定门限时，网络应启动切换过程，以维持一定的通信质量，减小小区间的干扰。参数“手机最大距离〞规定了手机距离的最大门限；当超越该门限时，基站将启动切换过程；注意：开启了BSS的poorinitialassignment功能后，可以限制信号质量较差的用户接入网络的请求，从而在一定程度上防止了这些用户可能的频繁资源请求。但是，这只是一种暂时的方法，为了根本解决问题，及时地解决网络覆盖缺乏的问题以及合理调整基站的覆盖*围才是最终的解决方法。C2设置不合理导致基站实际覆盖过大对于有些基站由于基站的站址比拟偏远或基站位置过矮，为了吸收话务量，优化人员有时开启C2。但是，如果C2的设置过大，且邻区的切换门限没有做及时的调整，也容易造成SDCCH拥塞。案例分析：6月21日，化工研究院DCS由于话务量过低，我们将该站的C2翻开，设置的该cell参数cell_reselect_offset设为15，即30dB。C2翻开后该小区的呼叫次数增加比拟明显，但由于当时未将该站的出邻区的切换门限适当增高，造成相当数量的呼叫在此小区建立后，很快切换至别的小区。从统计上看基站的totalcall很多，但话务量却不高，还存在一定数量的SDCCH拥塞。当我们将该站的C2关闭后，基站的SDCCH拥塞率下降为0。datesite_namecell_nameSDCCH拥塞率SDCCH话务量TCH拥塞TCH话务量TOTAL_CALLSavail_tch_ma*erl/chanCell话务掉话比6-21HuaGongYanJiuYuanDCS311090.122.700.002.42617.00290.0820.786-22HuaGongYanJiuYuanDCS311090.000.160.000.8612.00290.0351.42手机过多的位置更新占用了基站的SDCCH信道当基站发生SDCCH信道拥塞后，对用户申请SDCCH信道的原因进展分析后，假设基站大量SDCCH的分配是被用于手机进展位置区的更新，则在采取其他措施的同时，尽可能地降低不必要的手机位置更新的次数，可以大幅度降低SDCCH信道的占用，从而减少SDCCH信道的拥塞情况。要降低LAC更新的次数，可以从LAC的划分是否合理、位置区更新滞后参数的设置等方面进展检查，分析问题所在。LAC划分不合理导致手机频繁位置更新在进展网络LAC区规划时，如果LAC区的交界被选择在手机用户数较多，用户移动性较大的地区，则会导致频繁的手机位置更新，这样会占用大量的SDCCH信道，很可能引起SDCCH的拥塞。同时，由于大量的位置区更新会造成手机经常不在效劳区的现象。所以，在对网络的LAC分区进展划分时，要充分考虑具体的道路信息、手机用户分布信息、基站的位置信息等，将LAC交界避开主干道路和话务密集的地区，减少不必要的位置更新，从而降低频繁位置更新对SDCCH信道资源过度的占用。分析SDCCH拥塞率较高的基站其占用资源的原因，如果大量是由于位置更新造成的，则要分析LAC交界的具体情况，采取调整基站的覆盖，以较少基站覆盖的不必要交叠，适当的时候要增加CRH来降低发生位置更新的几率，或者考虑增加SDCCH信道的个数。在有些时候，可能出现基站的SDCCH信道已经到达最大配置，基站的覆盖已经调整得比拟合理，CRH的取值也到达最大的情况，这种情况下只能检查LAC的划分是否合理，重新调整LAC的分区，来避开高话务地区。LAC分界处的基站覆盖交叠过大且此处的手机用户密度较大在LAC分界的基站如果覆盖交叠过大或用户密度较大，可能存在大量的位置更新。在调整基站覆盖使之趋于合理的同时，通过调整网络参数可以在一定程度上缓解频繁位置更新的发生。当手机进展小区重选时，假设原小区和目标小区属不同的位置区，则手机在小区重选后必须启动一次位置更新过程。由于无线信道的衰落特性，通常在跨LAC的相邻小区交界处，测量得到的两个小区的C2值会有较大的波动，从而使手机频繁地进展小区重选。尽管按照GSM规*，手机两次小区重选的间隔时间不会小于15秒，但对位置更新发生在手机用户数量较多的地区时,15秒的保护时间还是不够的。手机用户过多的位置更新不但使网络的信令流量大大增加、无线资源得不到充分利用，并且由于手机在位置更新的过程中无法响应寻呼，因而使系统的接通率降低。为了减小这一问题的影响，GSM规*设立了一个参数，称为小区重选滞后cell_reselect_hysteresis。此参数是BSS小区级参数；它要求邻区〔位置区与本小区不同〕信号电平必须比本区信号电平大，其差值必须大于小区重选滞后规定的值，并且要保持5秒以上，手机才再启动小区重选。小区重选滞后包含于信息单元“小区选择参数〔CellSelectionParameter〕〞中。该信息单元在每个小区播送的系统消息中周期性发送。选择适宜的小区重选滞后电平对网络优化有重要的意义。小区重选滞后通常建议设置为8dB或10dB。在以下情况下建议作适当的调整：当*地区的业务量很大，经常出现信令流量过载现象，建议将该地区中属于不同LAC的相邻小区的小区重选滞后参数增大。假设属于不同位置区的相邻小区其重叠覆盖*围较大时，建议增大小区重选滞后参数。假设属于不同LAC的相邻小区在邻接处的覆盖较差，即出现覆盖的“缝隙〞时，或这种邻接处地理位置处于高速公路等慢速移动物体较少的地区，建议将小区重选滞后参数设置在2～6dB之间。注意：小区重选滞后〔CRH〕的设置一般应结合小区重选C2的取值，统一考虑。另外，对于网络调整尤其是割接比拟频繁的情况，应及时观察网络以及小区SDCCH拥塞率的变化，随着网络LAC分区的改变来调整位于LAC交界的小区的SDCCH信道配置，并且调整这些小区的CRH参数的设置。案例分析：1、8月20日和26日，我们对局部处于LAC边界，LOCATIONUPDATE次数较多的个别小区进展了分析，考虑到用户停留在这些小区时，要占用相对较多的SDCCH信道进展位置区更新。鉴于此，我们对这些小区的SDCCH信道进展了进一步调整〔参数如下〕。例如：广外关厢、丰台东大桥、庞各庄。调整后这些小区的SDCCH拥塞率得到下降，前后比照方下：Channel_reconfig_switch=1；Ma*_number_of_sdcch=48〔将最大SDCCH信道数增至最大〕；Tch_need_low_water_mark=2；BSSNameSiteNamegsmcelliddate_and_timeSDCCH拥塞率SDCCH到达率TCH拥塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS19PangGeZhuang_3460-00-4170-68325-81.27774.0000.9485711BSS19PangGeZhuang_3460-00-4170-68327-80.00675.0000.887460BSS19PangGeZhuang_3460-00-4170-68330-80.23846.0000.838722BSSNameSiteNamegsmcelliddate_and_timeSDCCH拥塞率SDCCH到达率TCH拥塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS51GuangWaiGuan*iang_8460-00-4182-67825-82.498425.0009.419209235BSS51GuangWaiGuan*iang_8460-00-4182-67827-81.528183.0009.108818136BSS51GuangWaiGuan*iang_8460-00-4182-67830-81.618445.000.19.389143150BSSNameSiteNamegsmcelliddate_and_timeSDCCH拥塞率SDCCH到达率TCH拥塞率busy_sdcchalloc_sdcchalloc_sdcch_failBSS55FengTaiDongDaQiao_18460-00-4192-22025-82.032708.0002.88294361BSS55FengTaiDongDaQiao_18460-00-4192-22027-80.002292.0002.4425800BSS55FengTaiDongDaQiao_18460-00-4192-22030-80.002407.0002.46268102、考虑到德宝饭店第三方向SDCCH拥塞严重，且多数申请SDCCH的原因是用于位置更新，所以我们将与德宝饭店第三方向不同LAC的邻区北站第三方向、西直门饭店三个小区的参数cell_reselet_hysteresis由10dB改为14dB，前后性能比照方下：site_namecell_nameSDCCHTCH话务量TOTAL_CALLdate_and_time成功分配次数分配失败次数拥塞成功分配次数分配失败次数拥塞北站3460-00-4112-2604070065000.004.001998-9460-00-4112-2605880090700.004.222488-11西直门饭店1460-00-4112-4813870076600.004.832158-9460-00-4112-4814160069900.003.562028-11西直门饭店2460-00-4112-482253700194320.1016.317298-9460-00-4112-482260700214500.0015.198658-11西直门饭店3460-00-4112-48355400108400.006.142788-9460-00-4112-48361000123400.006.523438-11德宝饭店3460-00-4132-7773688777467.8215991390689.6922.0015588-9460-00-4132-777218240.1829992487.6416.378718-11基站不能正常分配SDCCH信道当基站的软件或硬件出现故障后，就可能导致在立即指配过程中，基站无法正常分配SDCCH信道，在统计上表达为SDCCH信道的拥塞。通常有以下的这些情况：硬件问题导致基站时隙退出效劳从而降低小区的可用资源基站出现硬件故障的情况，主要是指基站的载频出现单个或几个时隙退出效劳，甚至整个或几个载频不能正常提供效劳的情况。当出现这种硬件故障后，很可能直接导致基站的SDCCH和TCH话务拥塞。要根本解决这种原因引起的话务拥塞，必须首先处理硬件故障。案例分析：9月1日半壁店的SDCCH拥塞聚增到17%，主要由于该基站的DRI出现[46]，[45]号告警，导致大量时隙OOS。INS该站有问题的DRI后恢复。同时鉴于该站SDCCH，TCH拥塞不平衡，调整该站的MA*_NUMBER_OF_SDCCH=48后，其SDCCH拥塞下降为0.99%。但是9月6日该站再次出现大量时隙OOS，致使SDCCH拥塞再次上升。NameDateOK_ACC_PROCSDCCH_CONGESTION_KEYSDCCH_TRAFFICTCH_CONGESTION_KEYTCH_TRAFFICBanBiDian_10CI＝6331-994217.891.204.042-99123.371.0504.53-99927.421.20.193.964-98680.740.9204.055-910750.991.2704.416-910369.661.2903.26基站传输闪断增加SDCCH分配失败次数基站传输闪断在很大程度上会影响到SDCCH等信道的分配，对于闪断严重，尤其是在话务顶峰闪断严重的情况，该站的SDCCH拥塞率会大幅度增加。案例分析：长缨楼宾馆基站闪断严重1800M全天闪断510次，900M全天闪断300次，造成该站SDCCH和TCH拥塞严重，同时也影响到周围其他基站。仅长缨楼宾馆一个站的SDCCH拥塞就高达81%，SDCCH分配失败次数增加到38268次，严重影响SDCCH的接通率。该站所在BSC的SDCCH拥塞率由平时的0%增加到37%，也使全网的SDCCH的拥塞率从原来的0.1%增长到0.95%，增加了近1个百分点。所以直接导致全网指标的下降。site_namecell_nameSDCCH成功分配次数SDCCH分配失败次数SDCCH拥塞SDCCH平均占用时长射频丧失率话务量dateChangYingLouBinGuan8272333187081.5012.170.7722.523-12ChangYingLouBinGuan826352410.645.690.699.373-11SLEEPINGCELL现象引起SDCCH的拥塞SLEEPINGCELL是摩托罗拉公司BSS基站设备在*些版本、*些运行情况下，出现的一种软件运行故障。简要地说，SLEEPINGCELL一般定义为没有明显基站告警，但实际基站已经不能为手机提供根本的通话效劳的情况，从统计上看基站TOTAL_CALL个数为0、SDCCH拥塞率可能较高、呼叫建立成功率可能较低。一旦出现这种情况，实际现场用户反映会比拟强烈，很可能造成一定*围内的负面影响。所以应该尽可能实时监控网络中基站的性能统计，尽早排除SLEEPINGCELL。由于SLEEPINGCELL很可能导致SDCCH拥塞率异常，所以我们应定期根据全网统计查看SDCCH的拥塞率，如果异常增高，需要判断改小区是否存在SLEEPINGCELL的现象。在每天提取的低话务量统计数据中，如果发现既无话务量又无TOTAL_CALLS的CELL，而且不是断站又没有严重的告警，这时应立即统计此CELL收到的RACH数，以进一步确认该CELL是否为SLEEPINGCELL，查看该小区的统计项：ACCESS_PER_RACH、ALLOC_SDCCH、ALLOC_SDCCH_FAIL、ALLOC_TCH、ALLOC_TCH_FAIL、OK_ACC_PROC_SUC_RACH等，分析此时段内该CELL收到RACH数，正确解出的RACH数，分配SDCCH、TCH的次数和分配SDCCH、TCH的失败次数，得到统计数据后，假设符合以下几种情况，则可确认为SLEEPINGCELL：收到的RACH次数为0或与前一段时间相比有非常明显的减少；收到的RACH数较多，但无法正确解出RACH；收到的RACH数较多，也可以正确解出RACH，但无法分配SDCCH；收到的RACH数较多，也可以正确解出RACH，分配SDCCH，但无法分配TCH；确认该CELL为SLEEPINGCELL后，用MMI方式进入相应BSS内，键入chg_level进入第二层，INS该CELL中BCCH所在的DRI，一般SLEEPINGCELL的现象即可恢复。案例分析：由于周末BSS软件版本升级，从第二天凌晨2点开场，BSS16的蒋家坟第一个小区出现与升级前表现不尽一样，但后果更为严重的SLEEPINGCELL。该基站有成功的RACH请求几千次，但没有成功分配SDCCH的次数，致使CALLSETUPSUCCESSRATE为0，TOTAL-CALL为0，TCH-TRAFFIC为0〔数据如下表〕，发现问题后优化人员于下午INSBCCH所在DRI，基站得到恢复，工作正常。TimeACCESS_PER_RACHALLOC_SDCCHALLOC_SDCCH_FAILALLOC_TCH9:0083518076465010:00881180810170ALLOC_TCH_FAILOK_ACC_PROC_SUC_RACHTCH_TRAFFICTOTAL_CALLS9:001989764670010:0017468101900SDCCH信道吊死导致基站不能正常分配与SDCCH拥塞率相关的统计项，其中有一项为哪一项SDCCH平均占用时长，假设*个CELL的SDCCH平均占用时长比其他CELL明显大出很多，不合常理，则该CELL的SDCCH有可能吊死在那儿。这种情况与SLEEPINGCELL比拟类似，但稍有不同，发生SDCCH吊死的情况时，该基站还能分配一些资源供手机使用，但在分配SDCCH时成功率非常低。从基站的实时运行状态看，该基站的绝大局部SDCCH均长期被占有，而无正常释放。但尚存在个别SDCCH能够被正常的呼叫建立所使用。出现这种情况后，应INS该CELLBCCH所在的DRI，通常基站都可恢复正常工作。RTF与DRI的对应关系发生紊乱由于基站软件运行故障，在BSS1614的软件版本中，存在软件BUG，有基站RTF与DRI的对应关系发生紊乱的情况，尤其是小区BCCH载频的RTF与DRI关系不正常，主要表达为小区内出现多个BCCH的RTF。出现这种情况时，通常该小区的SDCCH拥塞率会受影响。案例分析：以下是兆麟大厦在6月4日出现RTF与DRI的对应关系发生紊乱的案例，下面是该基站的当时状态查询和性能统计数据〔有删减〕：MMI-RAM0217->state10dri**DEVICESTATUSINFORMATIONFORLOCATION10:DeviceStateReasondd/mmhh:mm:ssFunctionDRI000B-UNOREASON03/0615:32:13RTF020DRI010B-UNOREASON03/0610:57:19RTF010DRI020B-UNOREASON03/0610:56:18RTF000DRI030B-UNOREASON03/0610:51:06RTF000MMI-RAM0217->state10rtf**FUNCTIONSTATUSINFORMATIONFORLOCATION10:FunctionStateReasondd/mmhh:mm:ssDeviceRTF000B-ENOREASON03/0610:55:53DRI020RTF010B-ENOREASON03/0610:57:01DRI010RTF020B-ENOREASON03/0615:31:54DRI000RTF030E-ENOREASON03/0610:50:07NoneMMI-RAM0217->disp_cell_s10MCC460460460MNC000000LAC4150(1036h)4150(1036h)4150(1036h)CI55(0037h)56(0038h)57(0039h)StatusUnbarredUnbarredUnbarredFREEINUSEUNAVLFREEINUSEUNAVLFREEINUSEUNAVLSDCCH10300221002480NormTCH/F1310212028110E*tTCH/F000000000PDCHANNEL400400400下表是该小区的性能统计，该小区在6月3日出现了RTF与DRI关系紊乱的故障，从path_balance的统计值可以看出，出现故障后，该小区有问题的RTF〔即RTF00〕的path_balance异常增高，且SDCCH的拥塞次数大幅度增加。datesite_namecell_namecarrierber_meanrf_losspath_balance_mean6-1ZhaoLinDaSha460-00-4150-55RTF-00-000.330107.606-4ZhaoLinDaSha460-00-4150-55RTF-00-001.873129.67site_namecell_nameSD成功分配次数SD分配失败次数SDCCH拥塞SDCCH平均占用时长射频丧失率话务量dateZhaoLinDaSha460-00-4150-551387004.600.321.605-31ZhaoLinDaSha460-00-4150-55132793852.8226.287.4010.666-3ZhaoLinDaSha460-00-4150-55144115593.7332.808.8611.316-4出现这种情况后，一般将出现故障的RTF所对应的DRI进展INS操作后，问题即可解决。手机不能正常占用SDCCH，引起手机重新申请网络效劳在立即指配完成后，网络会在指定的时间内等待手机占用SDCCH信道，但是，有时会发生因为各种原因而导致手机不能正常地占用SDCCH的情况，并且现象的存在假设比拟严重的话，可能引起手机在屡次立即指配不成功的情况下，屡次申请网络效劳，引起大量的SDCCH资源请求，从统计上看SDCCH拥塞率较高。一般造成这种现象的原因有：小区载频硬件问题由于小区硬件问题导致系统分配完SDCCH后，手机无法占上SDCCH信道，从统计上看，表现为chan_req_ms_fail的值较高。此时，手机在收到ImmediateAssignment消息后尝试占用SDCCH，在网络参数T3101规定的时间内手机占用SDCCH却不成功，这样呼叫就没有建立起来。出现这种情况，很可能导致手机在屡次申请网络效劳不成功后，继续申请资源，从而引起不必要的SDCCH分配，可能造成SDCCH信道的拥塞。此问题一般是由于基站的*个或*几个载频故障导致：在现场测试时可以发现，当手机被分配给固定的*个载频的TCH时隙后，在试图占用时总是出现占用不成功的现象；假设要从OMC统计上观察，则可以通过将该小区的信道盘逐个LOCK住，观察每个TCU在被LOCK住后，小区性能统计chan_req_ms_fail的统计值是否还很高。如果在闭掉*个TCU后，chan_req_ms_fail的值恢复正常，则可以判断问题出在该载频上。当发生这种问题后，在进展故障定位的根底上，只需将该载频更换即可。参数设置错误问题由于网络在向手机发送ImmediateAssignment消息后，开场计时〔T3101〕，手机要在此计时器规定的时间内接入网络，假设计时器超时而手机还未成功接入，此时系统将触发统计项chan_req_ms_fail。T3101：BSS中小区级参数；它的取值定义了系统从发送ImmediateAssignment消息后，等待手机建立SDCCH连接的时间。这个参数的大小要综合考虑手机占上SDCCH平均所需的时间和基站SDCCH信道拥塞情况。取值过大可能造成基站资源浪费，取值过小将可能引起大量手机不能正常占上SDCCH的现象。现在移动全网大局部基站的此参数取值为1500〔1.5秒〕。存在频率干扰的问题如果基站存在严重的系统内部或系统外部的干扰时，手机在进展SDCCH的接续时，可能由于存在频率的干扰而收不到系统发来的ImmediateAssignment消息，或者收到该消息后，在接入系统的时候由于干扰，网络无法正确解出手机发来的ImmediateAssignment消息，从而最终造成手机无法占用系统为其所分配的SDCCH资源。这样，在一定程度上会引起手机屡次申请网络效劳，造成系统资源的拥塞。要解决干扰问题，首先要判断干扰来自本系统内，还是系统外的干扰。这可以通过OMC统计观察该站的空闲情况下的干扰统计IOI，如果24小时均很高，则干扰很可能来自系统外；如果IOI只是随着网络的话务量增长而增值，则问题很可能来自系统内的频率规划。对于系统外的干扰，要具体查找干扰源，一般是电台、电力设备、非法直放站等所造成；对于系统内的干扰，则要检查该站的频率规划是否存在问题。由于基站异常原因导致用户频繁重新申请网络资源当基站存在比拟明显的单通或无声时，手机用户在打时假设感觉到没有声音，在最初发现时，用户一般会再拨打几次才会放弃尝试。当用户话务量相比照拟集中时，假设遇到这种基站单通或无声的问题，则很容易发生大量用户频繁申请网络效劳的现象，基站的SDCCH拥塞率指标会比基站工作正常时有所提高。MSC侧等有线局部原因造成基站SDCCH信道拥塞SDCCH拥塞率较高，通常是由于无线局部的原因造成的。但是，在*些特殊情况下，由于MSC的资源状态设置或参数设置等不正确，也会造成无线局部的SDCCH信道拥塞。这种情况一般发生在基站割接、新BSC或新站入网的时候，此时出现异常的SDCCH拥塞，则需要关注MSC或A接口的设置。MSC上基站参数设置不正确，造成基站SDCCH信道拥塞在网络割接调整时，可能发生小区的LAC在割接后有了变化，但是在MSC中却未更改，造成用户手机有信号，但无法通话；从统计上看，SDCCH拥塞率很高。具表达象：拨打测试中发现测试小区有信号，但无法做主叫，被叫，不能正常切换，从OMC上观测该小区状态可发现该小区长时间只有SDCCH分配，没有TCH分配〔如图一所示〕。图一：MMI-RAM0213->disp_cell_st1StartofreportforLOCATION1:GSMCELLIDMCC460460460MNC000000LAC4144(1030h)4144(1030h)4144(1030h)CI3121(0C31h)3122(0C32h)3123(0C33h)RAC139(008Bh)139(008Bh)139(008Bh)FrequencyTypePGSMPGSMPGSMBCCHFrequency263237StatusUnbarredUnbarredUnbarredFREEINUSEUNAVLFREEINUSEUNAVLFREEINUSEUNAVLSDCCH364022201510NormTCH/F300042004300E*tTCH/F000000000PDCHANNEL200200200EndofReport.从统计看，则表现为该小区的total_calls为0。产生原因：通常在割接时由于基站LAC重新分配，但其他数据没有变动，只是LAC更改，但MSC却没有及时修改MSC上的基站数据，从而造成MSC数据与BSC数据不一致。解决方法：核查MSC中该小区数据，将错误LAC更正后即可。MSC上未及时在基站开通后做该站的数据造成基站SD拥塞这种情况表现出来的现象以及处理方法与1〕类似。MSC上基站操作维护状态设置不正确，造成基站SD信道拥塞在网络基站割接时，可能由于工作疏忽，会出现有个别的小区在MSC上的操作维护状态为LOCK，造成无线侧表现为用户手机有信号，但无法通话；从统计上看SDCCH拥塞率会很高。具表达象：现场拨打测试中发现被测试小区有足够可以通信的信号，却无法做主叫和被叫；但是可以进展局部切换〔即切换过程中不需要MSC参与的切换在这种情况下可以进展〕。在OMC上观测该小区统计可发现SDCCH占用很多，但TCH占用较少，甚至没有占用。如果在OMC上对该小区进展call_trace则可发现trace到的call均为切换的情况，没有主叫和被叫的call。另外，从统计指标上看，该小区的total_calls为0，即没有MOC和MTC。解决方法：核查MSC中该小区数据，查看该小区在MSC中的状态是否为LOCK或者查看在相应的MSC中是否有该小区的正确数据。如果状态为LOCK则UNLOCK即可，如果无此小区数据，则参加该小区数据即可。MSC侧CIC被异常BAR住，造成基站SD信道拥塞具表达象：拨打测试发现测试小区有信号，但无法主、被叫，也无法进展切换。从OMC观察小区状态发现该小区只有SDCCH分配，无TCH分配，具表达象如图一所示。在OMC上对该小区做Call_trace发现手机的呼叫没有得到CIC电路的分配，信令流程在SETUP消息后，立刻从网络侧发送Disconnect[即：Disconnect(network->MS)：Cause-Resourceunavailable；Requestedcircuit/channelnotavailable.]，具体log见下面〔正常情况和非正常情况的比照，中间局部信令流程省略〕。从统计看，该BSC中所有小区TCH分配次数为0，total_calls为0。产生原因：通常是由于一个新的BSC初次投入使用时，由于没有及时将所带的CIC电路翻开，而造成在该BSC下的基站开通后，CIC电路仍被BAR的情况。解决方法：在MSC中将该BSC的CIC电路设为工作状态即可。资源分配异常的接续情况：___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.210CALLDURATION00:00:00.000LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:pletelayer3information(BSS->MSC).Cell-LAC:04182CI:00678(RR:Pagingresponse(MS->network).)___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.245CALLDURATION00:00:00.035LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Setup(network->MS)Speech.Circuitmode.___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.905CALLDURATION00:00:00.695LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Callconfirmed(MS->network):Causenotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:52.930CALLDURATION00:00:00.720LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Disconnect(network->MS):Cause-Resourceunavailable;Requestedcircuit/channelnotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.615CALLDURATION00:00:01.405LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Release(MS->network):Cause-Normalevent;Normalcallclearing.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.630CALLDURATION00:00:01.420LAC:04182CI:00678CARRIER31MESSAGE:DTAP:Releaseplete(network->MS):Causenotavailable.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.635CALLDURATION00:00:01.425LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:Clearmand(MSC->BSS)Cause-Normalevent;Callcontrol.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.695CALLDURATION00:00:01.485LAC:04182CI:00678CARRIER31MESSAGE:RR:Channelrelease(network->MS):RRCause-Normalevent.___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.710CALLDURATION00:00:01.500LAC:04182CI:00678CARRIER31MESSAGE:ABIS:DeactivateSACCH(BSC->BTS):Timeslot:1Channel:SDCCH/8+ACCH___________________________________________________________________________TIMESTAMP:30/10/200101:48:53.720CALLDURATION00:00:01.510LAC:04182CI:00678CARRIER31MESSAGE:BSSMAP:Clearplete(BSS->MSC).正常的接续过程：___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.725CALLDURATION00:00:00.000LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:pletelayer3information(BSS->MSC).Cell-LAC:04124CI:00786(RR:Pagingresponse(MS->network).)___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.755CALLDURATION00:00:00.030LAC:04124CI:00786CARRIERHoppingMESSAGE:DTAP:Setup(network->MS)Speech.Circuitmode.NumberofCaller-Type:National.Number:___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.900CALLDURATION00:00:00.175LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:Classmarkupdate.___________________________________________________________________________TIMESTAMP:25/10/200115:19:13.925CALLDURATION00:00:00.200LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Classmarkchange(MS->network).___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.360CALLDURATION00:00:00.635LAC:04124CI:00786CARRIERHoppingMESSAGE:DTAP:Callconfirmed(MS->network):Causenotavailable.___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.385CALLDURATION00:00:00.660LAC:04124CI:00786CARRIERHoppingMESSAGE:BSSMAP:Assignmentrequest(MSC->BSS)CIC=859___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.445CALLDURATION00:00:00.720LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Physicalconte*trequest(BSC->BTS):Timeslot:3Channel:SDCCH/8+ACCH___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.460CALLDURATION00:00:00.735LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Physicalconte*tconfirm(BTS->BSC):Timeslot:3Channel:SDCCH/8+ACCHBSPowerPn-4MSPower-10(33dBmforGSM900,20dBmforDCS1800)TimingAdvance:3___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.490CALLDURATION00:00:00.765LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Channelactivation(BSC->BTS):Timeslot:0Channel:Bm+ACCH'sIntra-cellchannelchange(Normalassignment)UplinkDT*isnotapplied.DownlinkDT*isnotapplied.Speech.HalfrateTCHchannelLmGSMspeechcodingalgorithmversion1BSPowerPn-4MSPower-10(33dBmforGSM900,20dBmforDCS1800)TimingAdvance:3___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.525CALLDURATION00:00:00.800LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Channelactivationacknowledge(BSC->BTS):Timeslot:0Channel:Bm+ACCH'sFrameNumber:9813___________________________________________________________________________TIMESTAMP:25/10/200115:19:14.555CALLDURATION00:00:00.830LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Assignmentmand(network->MS)Carrier:HoppingTimeslot0TypeTCH/F+FACCH/FandSACCH/F___________________________________________________________________________TIMESTAMP:25/10/200115:19:15.080CALLDURATION00:00:01.355LAC:04124CI:00786CARRIERHoppingMESSAGE:ABIS:Establishindication(BTS->BSC):Timeslot:0Channel:Bm+ACCH'sSAPI:0Channeltype:FACCHorSDCCH___________________________________________________________________________TIMESTAMP:25/10/200115:19:15.210CALLDURATION00:00:01.485LAC:04124CI:00786CARRIERHoppingMESSAGE:RR:Assignmentplete(MS->network):RR