SDCCH拥塞率高的分析处理
上一篇 / 下一篇 2008-06-04 09:37:04 / 个人分类：mima
- 文件版本: V1.0
- 开发商: 本站原创
- 文件来源: 本地
- 界面语言: 简体中文
- 授权方式: 免费
- 运行平台: Win9X/Win2000/WinXP
SDCCH拥塞率高的分析处理
前言我们在谈到网络拥塞时，常常是指信令信道拥塞以及话务信道拥塞。信令信道拥塞也就是我们常说的SDCCH信道拥塞，发生在用户在申请网络服务开始阶段。SDCCH的全称是独立专用控制信道，用于呼叫的建立、位置更新、短信的传输等过程。一般进行的信令交互主要利用SDCCH信道承载，SDCCH信道的分配也称立即指配过程。出现SDCCH信道拥塞是说：在立即指配时，如果网络没有可用的SDCCH信道来分给手机，则系统计一次SDCCH分配失败。SDCCH信道的拥塞会直接影响到基站的性能和用户的感观。在现场用户的感觉是：当用户发出通话或其他网络服务的申请时，大部分手机没有任何反映即返回到空闲状态，有的手机发出有节奏的三声响声。当出现这种情况后，用户比较反感，意见较大。为提高SDCCH的接通率，降低无线信令信道的拥塞，在本文中，笔者主要从出现SDCCH信道拥塞可能的原因入手，提出一些解决SDCCH信道拥塞的方法和思路，以供大家参考。
3） SDCCH分配信令流程分析说明
当手机需要同系统建立联系时，要通过随机接入信道（RACH）来向网络发送信道请求消息（channel request）。这个消息中有3比特用来指示手机接入网络原因。当发生信道资源拥塞时，系统可根据这个指示来分别对待不同原因的信道申请。channel request还含有5比特是手机选择的随机数，这个随机数可以让系统区分不同的手机在同一时隙内发送的RACH消息，此后系统向手机发送的立即指派消息中会将该随机数再发给手机，手机将此随机数与自己所发送的随机数相比较，可以识别出来这个立即指配消息是否是网络发送给自己的。
BTS的Layer1进程对收到的channel request进行成功解码后（成功解出RACH后对统计ok_acc_proc_suc_rach计数），BTS的ABIS进程负责对RACH指示的原因进行解析（若解出不正确的RACH请求的原因后，对统计inv_est_cause_on_rach计数）。在BTS的RRSM中依据收到不同原因的RACH消息的个数对统计chan_req_cause_atmp进行计量。BTS的CRM进程在收到RRSM送来的channel required received后，将为此次信道请求分配一条空闲的SDCCH信道（触发统计alloc_sdcch）。RSS收到CRM送来的信道激活（channel active）消息后将相应的SDCCH激活，激活成功后将向RRSM返回信道激活响应（channel active ack）。RRSM收到RSS的激活响应后，将会利用AGCH信道发送立即指派（immediate assignment即I.A）消息（Layer1触发access_per_agch统计），此消息包含了已分配的SDCCH信道的情况、初始TA、初始的手机最大发射功率、对应的信道请求消息中的随机数、BTS收到channel request时的TDMA帧号以及基站的跳频情况等消息。RRSM在发immediate assignment后启动T3101计时器，等待手机接入SDCCH信道。
若CRM发现没有可用的资源后（触发统计alloc_sdcch_fail），将向手机发送立即分配拒绝消息immediate assignment reject，出现这种情况可能的原因有：无可用无线资源、测得的手机TA值超出系统限制、信道激活无应答等。
当收到立即指派拒绝消息后，手机启动T3122，在T3122所规定的时间内，不允许手机接入网络，同时手机将进入空闲模式并监听寻呼信道的消息。到T3122超时后，手机才可以发新的channel request。
当手机收到立即指派消息后，手机将收到的I.A消息与自己发出的信道请求中的消息字段进行比较，用于判断这个立即指配消息是否是给自己的。如果收到的立即指配是给自己的，则手机将信道调整到所分的SDCCH上，再利用SABM消息（设置异步平衡模式）通知网络手机已经成功占上SDCCH，SABM包括手机申请信道的原因、用户身份及移动设备的特性。此时手机使用的TA和发射功率来自于I.A消息的指示。Layer2（数据链路层）的SABM消息用于建立异步平衡模式，其服务接入点类别SAPI=0，Layer2工作于证实模式下。SABM承载的Layer3消息initial message是第三层的业务请求消息。BTS的Layer1在收到SABM消息后，将向MS发一个内容与initial message一样的UA消息（无序号证实），只有MS收到的UA消息的内容与SABM消息的完全一样，手机的接入才正确。UA的作用是为了处理多个手机在同一时间发送内容一样的信道请求消息的情况，以区分出不同的手机的消息。BTS的Layer1在收到Layer2的SABM后将向RRSM发送建立指示消息即establish indication，RRSM收到此消息后将T3101停止计时，触发统计ok_access_proc。此统计可以区分出用户申请服务不同的原因，包括：Connection Management的业务请求（呼叫建立即主叫、短信息、附加业务管理等）、位置更新请求（正常位置更新、周期性位置更新、IMSI附着）、IMSI分离、紧急呼叫及寻呼响应。另外，在T3101的时间内，如果手机不能正常占用SDCCH，则RRSM将触发统计chan_req_ms_fail。
下一步RRSM会向BSC的SSM发出三层业务请求消息（initial layer3 information），SSM再向MSC发CR消息（connection request），用来申请与MSC建立SCCP层连接，CR中含有申请CM业务的原因、该手机的一些物理特征以及该MS的MSISDN。在MSC收到此消息后，即向BSC的SSM发出CC消息（connection confirmed），这样MS与MSC 之间的信令链路就建立起来了，MSC已经能够控制RR管理的传输特性，BSS处于监视传输质量和随时准备切换的运行状态。
备注：
为方便理解上述流程，可参考以下备注：
BSS的呼叫处理Call Processing（CP）是L2和L3的系统应用进程的集合，用于MS呼叫的高层信令控制。CP包括
MTP L3/SCCP preprocessor (MTP L3).
Connectionless manager (CLM).
SCCP state machine (SSM).
Switch manager (SM).
Cell resource manager (CRM).
Radio resource state machine (RRSM).
Radio channel interface (RCI).
其中：
MTP L3/SCCP preprocessor (MTP L3)处理A接口上的收发消息的协议适配，还通过分析消息的包头并进行寻址，来决定消息的目标进程。
Connectionless manager (CLM)处理BSS的global控制，这个进程负责处理C7信令协议中无连接的部分。
SCCP state machine (SSM)负责处理C7信令协议中面向连接的部分，它协同处理所有intra-BSS 和 intra-cell的切换，它要确保目的小区收到了切换请求且为手机预留了资源。这个进程产生所有与切换相关的信令，当进程结束后要通知MSC，当切换成功结束后要通知源小区，让源小区释放相应的资源。
Switch manager (SM)用于控制从MSC至MS的陆地链路（由MSC指派）到MS的无线链路（由BSS中的CRM负责分配）的连接。
Cell resource manager (CRM)负责当MS接入系统时给它分配无线资源，它保留和维护着表征其管辖范围内每个信道状态的动态数据库，并根据RSS提供的信道干扰信息来分配在最好的资源，还分配用于区分每个呼叫的SCCP reference number。当一个BTS或小区的话务过高时，CRM会触发Flow Control，当话务负荷减轻时Flow Control会停止。CRM还产生空中接口上传输的系统消息。
Radio resource state machine (RRSM)负责激活和维护物理连接，它激活由CRM分配的无线信道，当MS不再需要该信道后，由RRSM负责关闭此信道。
Radio channel interface (RCI)用于将RSS中MS的地址（无线信道号）转换成Call Processing中Layer 3进程识别MS的地址（SCCP reference number）。
RSS是BSS radio subsystem的缩写，是系统应用程序的一个集合。用于管理BSS的RF硬件和与MS通信的无线链路。它包括五个进程：
Configuration and fault management.
Layer 1 interface.
Layer 2 protocol.
Abis interface.
Handover Detection and Power Control（HDPC）.
其中：
Configuration and fault management控制与它相关的无线资源的配置，并提供BTS故障管理系统的接口。
Layer 1 interface用于RSS软件与channel coding进程之间消息协议的转换，它还负责存贮paging 消息和access granted 消息，直至等到控制信道上该消息相应的时隙出现。
Layer 2 protocol用于将以MS为目的地的信令信息翻译成在空中接口上传送的以时隙为单位GSM信令，还处理MS的LAPDm信令；它还负责为MS建立连接，以在空中接口上传送MS的SMS数据（MO或MT）。
Abis interface用于将RSS内产生的消息翻译成Abis格式，以传送给Layer3应用程序。这个进程要对收到的消息进行校验来确保消息的完整性，它还对RACH信道上收到的access bursts进行计数，计数的周期可在数据库中设置，如果计数值超过了预设的门限，则此进程会通知Layer3的应用软件，由Layer3的应用软件通过Bar住某个接入级别的MS，以减少RACH上的access burst的个数。
Handover Detection and Power Control（HDPC）用于以时隙为单位控制MS的发射功率（Uplink）和相应的基站发射功率（Downlink）。这个进程还负责控制MS的timing advance以让MS能够在其所属的时隙中工作。此进程还负责触发MS的切换，依据不同的标准判决有无切换的必要。当TCH空闲时，此进程还负责测量其收到的噪声，计算出平均的噪声等级，并将数值通知Call Processing，用于在信道分配时提供参考。当MS的呼叫已经建立后，此进程还监测收到MS的SACCH消息的情况，若连续未收到某个MS一定数量（可由数据库设置）的SACCH消息，此进程要通知Call Processing来释放这个MS有关的资源。
SDCCH拥塞率计算公式
SDCCH拥塞率公式
SDCCH拥塞率（2002 中国移动集团公司公式）
=忙时SDCC溢出总次数×100 / 忙时SDCCH试呼总次数（％）
=alloc_sdcch_fail×100 / chan_req_cause_atmpt（％）
当基站的SDCCH拥塞率指标出现拥塞后（拥塞率关注的程度要视网络性能发展的阶段而定），通常优化人员要提取与SDCCH信道分配过程有关的性能统计，并结合基站的配置参数、现场测试文件或OMC的Call Trace文件等，对基站拥塞的原因进行分析定位，并采取有效的解决方法予以处理。
一、 出现突发性话务增加或者用户产生话务时间相对集中
分析出现SDCCH拥塞的小区的性能，将当前拥塞时段的话务量与小区的历史统计进行比较，判断是否是突发性的话务量，若小区话务量相对硬件配置并不高，且硬件没有故障，但仍由拥塞情况发生，则说明用户的服务需求可能比较集中。在这些情况下可以考虑采用以下的方法来缓解或解决：开启RACH流量控制功能从用户申请网络服务的最开始对用户的请求进行限制；在分析出网络SDCCH话务量的激增是由于新的极其吸引用户的增值业务的推出而引起的，则要对有大量增值业务需求的地区加大SDCCH的配置数。
1） 开启RACH流量控制功能，减少SDCCH的集中占用
1、RACH的冲撞控制：
由于GSM系统中RACH信道是一种可能出现随机碰撞的信道，网络无法知道手机何时需要通信，手机也很可能会同时占用同一个RACH时隙来用于申请接入，这时不可避免的要发生碰撞现象。为了减少手机接入系统时RACH信道上的冲突次数，提高RACH信道的效率，GSM规范中规定了手机必须采用的接入算法。该算法中应用了三个参数，即：发送分布时隙数tx_integer（参数T）、最大重发次数max_retran（参数M）和与参数T及信道组合有关的参数（参数S）。其中参数“最大重发次数（max_retran）”表示手机最多向网络发送“信道请求”消息的次数。参数T表示手机连续发送多个信道请求消息时，每次发送之间间隔的时隙数，参数S是接入算法中的一个中间变量，根据参数T和CCCH配置情况确定。
max_retran：BSS小区级参数，最大重发次数即参数M；其取值为0～3。手机在启动立即指配过程时（如手机需位置更新、启动呼叫或响应寻呼时）将在RACH信道上向网络发送“信道请求”消息。由于RACH是一个存在冲突的信道，为了提高手机接入的成功率，网络允许手机在收到立即指配消息前发送多个信道请求消息, 在经过最大重发次数后，若仍得不到系统的立即指派命令，手机则返回到空闲状态下。最多允许重发的次数则由参数“最大重发次数”确定。最大重发次数包含于信息单元“RACH控制参数”中，在每个小区广播的系统消息中周期发送。
网络中每个小区的最大重发次数可以由网络优化人员设置。一般地，重发次数越大，试呼的成功率越高，接通率也越高，但同时RACH信道、CCH信道和SDCCH信道的负荷也随之增大。在业务量较大的小区，若最大重发次数过大，容易引起无线信道的过载和拥塞，从而使接通率和无线资源利用率大大降低。相反，若最大重发次数过小，会使手机的试呼成功率降低而影响网络的接通率。因此合理地设置每个小区的最大重发次数是充分发挥网络无线资源和提高接通率的重要手段。
最大重发次数M的设置通常可以参考下列方法：
• 对于业务量较小的地区，max_retran可以设置为“3”即最多重发7次，以提高手机接入的成功率。
• 对于小区业务量一般的地区，max_retran可以设置为“2”即最多重发4次。
• 对于微蜂窝，建议max_retran设置为“1”即最多重发2次。
• 对于业务量很大的微蜂窝区和出现明显拥塞的小区，建议max_retran设置为“0”即最多重发1次。
注意：
北京移动现网的max_retran默认值为“2”，即最多重发4次channel request。
tx_integer：BSS小区级参数，发送分布时隙数即参数T；其取值范围是0～15的整数，定义参见表1，此参数在小区广播的系统消息中周期发送。。
参数S：参数S实际上是由手机根据参数T和CCH信道的组合情况自行计算得到，具体方式由表2确定。
Tx_integer(T)的编码 对应时隙数
0000 3
0001 4
0010 5
0011 6
0100 7
0101 8
0110 9
0111 10
1000 11
1001 12
1010 14
1011 16
1100 20
1101 25
1110 32
1111 50
表1——发送分布时隙数Tx_integer(T)的编码方式
CCH信道组合方式
T CCCH不与SDCCH共用 CCH与SDCCH共用
3，8，14，50 55 41
4，9，16， 76 52
5，10，20， 109 58
6，11，25， 163 86
7，12，32， 217 115
表2——参数S的取值
当手机接入网络时需启动一次立即指配过程，该过程的开始，手机将在RACH信道上发送（max_retran＋1）次信道请求消息。为了减少RACH信道上的冲突次数，手机发送信道请求消息的时间必须遵循下列规则：
• 手机启动立即指配过程开始，到第一个信道请求消息发送之间的时隙数（不包括发送消息的时隙）是一个随机数。这个随机数是属于集合{0，1，……，MAX（T，8）－1}中的一个元素。手机每次启动立即指配过程时，按均匀分布概率从上述集合中取数。
• 任意两次相邻的信道请求消息之间间隔的时隙数（不包括消息发送的时隙）由手机以均匀分布概率方式从集合{S，S＋1，……，S＋T－1}中取出。
由上述分析可知，tx_integer即参数T取值越大，手机初次发送信道请求消息之间间隔的变化范围越大，RACH冲突的次数相应减少。参数S越大，手机重复发送信道请求消息之间的间隔越大，RACH信道上的冲突减少，同时AGCH信道和SDCCH信道的利用率提高（网络每收到一次信道请求，只要有空闲信道都会分配一个信令信道而不论信道请求消息是否由同一个手机发出）。然而，参数T和S的增大却会延长手机的接入时间，从而导致整个网络的接入性能下降，因此必须选择合适的T和S。
网络优化人员可以根据系统的实际应用情况设置适当的T值以使网络的接入性能最佳。T值的选择一般可参考下列原则：
• 在一般情况下，应取参数T使参数S尽可能小（以减小手机接入时间），但必须保证AGCH信道和SDCCH信道不出现过载。操作过程中，对业务量不明的小区可以任意取一个T值使参数S最小，若小区的AGCH或SDCCH信道出现过载则改变T使S增大一次（参照表2）直到小区不再出现AGCH或SDCCH信道过载情况。
根据上述原则，可以确定T值的取值范围（对应参数S的每个取值参数T可以取数个），当小区RACH冲突数较大时，应取较大的T值（在上述范围内）；在RACH冲突数较少（定量分析需在实验以后进行）的情况下，应使T值尽可能小。
注意：
北京移动Tx_integer(T)的默认值为“12”即20个RACH时隙。
2、RACH的流量控制：
系统通过RSS来监测在一定的时间内（rach_load_period）收到的channel request消息个数。 如果收到的个数超过门限rach_load_threshold，则RSS向call processing发负载指示消息。一旦收到负载指示消息，call processing 将随机BAR住一个接入级别(0-9) 的手机。同时CP启动计时器T1和 T2 (flow_control_t1和flow_control_t2)。当T1 超时后，若CP再收到从BSS系统传来的负载指示消息，则CP将再BAR住另一个级别的手机。若在T2的时长内，CP没有再收到从BSS传来的负载指示消息 则系统将UNBAR一个级别的手机。T2的取值必须大于T1。
计时器rach_load_period和ccch_load_period都是235.5mS (1 x 51 frame)的整数倍。rach_load_period决定了rach load监测的时间周期。只有在前一个周期内(RACH or CCCH)触发了过载条件ccch_load_period才会开始计时。
门限rach_load_threshold由下面的公式计算得到：
RACH load threshold = Total number of channels (TCH/SDCCH) x100
No of RACHs in period x No of RACH timeslots
其中：
分子是小区内配置的SDCCH子时隙和TCH的个数。
分母是在4 * 51帧的复帧周期内可用的RACH时隙数。这个值取决于ccch_conf的设置。结果为rach_load_threshold，以0.01%为间隔。
注意：
由于北京移动的网络不支持用户的分级，所以上述RACH的流量控制实际效用不大。
3、启动立即指配拒绝功能缓解SDCCH拥塞：
在GSM规范中定义了立即指配拒绝的功能：当目前网络没有可以分配的SDCCH信道时，就可以通过发送给手机一条立即指派拒绝（immediate assignment reject）的 消息来拒绝手机的信道申请，并且在系统规定的时间内（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日 2078197 79734 2186.86 3.69 ％
4月24日 2135049 30097 2228.11 1.39 ％
现在的GSM网络所提供的业务中，有一部分增值业务是由SDCCH信道承载，例如短信消息等。如果增值业务在时间上集中引入，很可能导致网络SDCCH信道出现突发且较大面积的拥塞情况。
2001年5月17日，北京移动开通了神州行手机用户的短信息业务，由于当时北京移动已经拥有了相当规模的神州行用户，且公司前期市场宣传工作做的比较到位，当天大量神州行用户尝试使用短信息，引起网络内短信息的收发次数激增，无线侧引发了大量的小区SDCCH拥塞。
cm_req_sms sms_inisial_on_sd SD_BLK SDCCH话务量sum
5月16日 23032 47273 0.81 4168.54
5月17日 92303 148049 1.66 4402.21
出现这种情况后，只能及时增加具体每个出现SDCCH信道拥塞的小区的SDCCH配置，以缓解网络拥塞情况。但为了尽可能避免类似的事件再次发生，应加强网络运行维护部门与市场部门的沟通，有预见性地采取一些预防措施。接受此次教训后，我们在此后的节假日等易于引起短信息等增值业务突发的时候，及时且适量地调整了网络的配置，避免了上述在无线侧拥塞情况的再次发生。
二、 存在覆盖或话务的不均衡问题
当出现SDCCH信道拥塞后，分析得出SDCCH的拥塞率与TCH的拥塞率不均衡，或者基站的覆盖与周边基站的覆盖没有合理地进行控制，则可以采用以下的均衡方法进行处理：若TCH信道很闲，可以开启SDCCH的重配功能，调整本小区的SDCCH与TCH的信道比例；若开启了SDCCH的重配功能，但参数设置不合理或不正确也可能造成SDCCH的拥塞；由于基站的覆盖过大，引起SDCCH拥塞，可以对用户的起呼进行距离上的限制；若基站的C2设置不合理，可能造成基站过多地吸收了话务，从而导致基站SDCCH拥塞率比TCH的高。
1） 基站SDCCH与TCH信道配置不合理
（1） 若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－combined方式，CCCH使用一个基本的物理信道，不与SDCCH共用；1表示combined方式，CCCH使用一个基本的物理信道，与SDCCH共用。根据一般的经验，对于小区中的载频数为1个或2个的情况，建议公共控制信道的配置采用一个基本物理信道且与SDCCH共用；小区中的载频数超过2个的情况，建议公共控制信道的配置采用一个基本物理信道且不与SDCCH共用。
Channel_Reconfiguration_Swith： BSS小区级参数；参数的取值可以决定CRM可否进行动态信道重配。
Number_Sdcchs_Preferred：BSS小区级参数；定义了在系统重启时CRM配置SDCCH的个数，同时小区SDCCH的信道个数。这个参数的取值受限于该小区的信道配置方式是combined或non－combined。
Max_number_of_sdcch：BSS小区级参数；定义了信道重配后SDCCH的最大个数。
发生TCH至SDCCH信道重配的条件：
1、 信道重配后SDCCH的最大个数不能超过Max_number_of_sdcch；
2、 空闲的SDCCH信道个数要少于sdcch_need_high_water_mark；
3、 当前空闲的TCH信道个数要大于tch_full_need_low_water_mark；
发生SDCCH至TCH信道重配的条件：
1、 重配后的SDCCH信道个数不能少于Number_Sdcchs_Preferred；
2、 当前空闲的SDCCH信道个数要大于sdcch_need_low_water_mark；
SDCCH信道的配置一般遵循以下原则：
（1） 在小区载频数<2的情况下，此时CCCH配置方式一般为Combine方式，因为SDCCH要与CCCH共享BCCH载频的TS0，这种情况下的SDCCH的实际个数为n×8＋4，其中n代表除BCCH外又给SDCCH配置的时隙个数。对于这样的小配置基站，n取值一般为1，SDCCH最小值则为12；SDCCH最大值可以为20。
（2） 载频个数在2到4之间的小区，CCCH配置方式一般为nonCombine方式，SDCCH的实际个数为n×8，n取值一般为2，SDCCH最小值则为16；SDCCH最大值可以为24。
（3） 载频个数>4之间的小区，CCCH配置方式一般为nonCombine方式，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 拥塞状况有上升趋势，我们选定部分典型基站做实验性修改，打开CELL RECONFIGURATION SWITCH。启用SDCCH 动态分配原则，Preferred_number_of_sdcch按通常的规划方法设定,并设定相关参数：
Channel_reconfiguration_switch=1
Max_number_of_sdcch=24
Sdcch_need_high_water_mark=2
Sdcch_need_low_water_mark=12
Tch_need_low_water_mark=3
结果表明拥塞状况有明显改善，前后对比见下表。现在全网除个别基站外，此功能均已打开。
下表是全网改动前后的性能比较：
date_and_time sum_alloc_sdcch_fail sum_alloc_sdcch sum_alloc_tch sum_alloc_tch_fail TCH拥塞率 SDCCH拥塞率
8-20 45343 775083 745614 126779 14.53 5.52
8-23 41484 809852 714615 108255 13.15 4.87
8-20 64250 827936 757878 158728 17.31 7.20
8-23 27559 812103 753801 133266 15.02 3.28
2、西三旗和五棵松村在一定程度上存在TCH与SDCCH忙闲不均的情况，采取以下措施后这些小区的TCH拥塞与SDCCH拥塞得到了均衡。CID786：将Max_number_of_sdcchs从32增加到48，number_sdcchs_preferred从24增加到32；CID840：将Max_number_of_sdcchs从32增加到48，number_sdcchs_preferred从16增加到24。
site_name cell_name SDCCH拥塞 CALL_SETUP_SUCCESS_RATE TCH拥塞 TOTAL_CALLS avail_tch_max erl/chan time
WuKeSongCun_16 460-00-4112-840 7.32 96.67 0 1047 37 0.47 3-1
WuKeSongCun_16 460-00-4112-840 1.76 96.08 0.03 1104 36 0.58 3-2
XiSanQi_6 460-00-4110-786 7.44 96.86 0 990 36 0.58 3-1
XiSanQi_6 460-00-4110-786 2.66 97.10 0.05 1107 34 0.58 3-2
3、万柳桥西北DCS CID30289的SDCCH 拥塞较高，但TCH不存在拥塞情况，话务掉话比较低。
处理过程：将number_sdcchs_preferred：16——32；
max_number_of_sdcchs：32——48；
site_name cell_name 掉话次数 sd拥塞 TCH话务量 date_and_time
WanLiuQiaoXiBeiDCS 460-00-4144-30289 1 7.28 1.51 6-25
WanLiuQiaoXiBeiDCS 460-00-4144-30289 1 0.00 1.35 6-28
4、在11月18日对网上所有CELL的channel_reconfig及其有关参数进行了相应的调整，减小了TCH和SD拥塞，同时提高呼叫成功率，也可以使当前的无线资源能有更高的利用率，避免了由于TCH, SD分配不合理，造成的一方拥塞而另一方空闲的资源浪费 。
改动的具体参数如下：
number_sdcch_preferred:8, 16, 24 max_number_of_sdcchs:16, 24
sdcch_low_water_mark:10, 18, 26 sdcch_high_water_mark:2
tch_full_need_low_water_mark:3
改动前后小区性能变化如下：
SDCCH 11-16 11-25
cell_name SDCCH拥塞 SDCCH话务量 SDCCH拥塞 SDCCH话务量
460-00-4160-759 50.96 9.07 0.16 10.74
460-00-4130-81 50.35 7.05 9.54 11.38
460-00-4130-79 48.96 7.04 12.81 12.02
460-00-4160-548 31.43 5.91 0.47 5.01
460-00-4120-122 28.48 13.66 4.32 16.07
460-00-4170-626 24.10 6.82 1.22 6.11
460-00-4170-621 51.66 18.02 29.92 21.93
460-00-4170-622 23.87 13.90 2.68 13.41
TCH 11-16 11-25
cell_name TCH拥塞 TCH话务量 avail_tch_max TCH拥塞 TCH话务量 avail_tch_max
460-00-4142-785 26.43 17.43 21 6.65 15.60 22
460-00-4172-698 24.91 24.97 29 5.72 22.01 30
460-00-4172-964 27.35 25.17 29 8.81 22.98 30
460-00-4160-917 43.41 26.71 29 25.79 25.72 30
（2） 开启了SDCCH的重配功能，但参数设置不合理或不正确
如果优化人员在配置SDCCH的重配功能时，没有满足BSS的约束条件，则可能发生SDCCH不能正常重配的情况，很可能会出现SDCCH拥塞的现象。
2） 与周边基站相比本小区的覆盖不合理
相对自身信道配置以及与邻区话务来说，如果基站的实际覆盖范围过大，可能导致它实际承载了过多的手机的网络服务需求，这样很容易产生SDCCH信道拥塞。当出现这种情况后，针对基站覆盖偏大的情况，采取有效措施来收缩基站的覆盖，从而降低基站承载的用户数，减小SDCCH信道的拥塞。常用的方法有：在距离上限制距基站较远的用户接入本基站；调整基站的小区重选的参数设置。
（1） 人为限制手机接入的距离收缩基站实际覆盖范围缓解SDCCH拥塞
对于偏远的地区，由于基站建设力度不够，在有些距离基站较远的地方手机信号较弱，如果手机在这些地方尝试向网络发起服务请求或响应网络的寻呼，由于距离基站过于远，信号衰减较大，手机接收质量很差，这样手机很可能不能正常地接入到网络中，反而由于手机频繁尝试发起接入请求而造成网络资源被大量占用。为避免这种距离基站过远的手机接入到基站中，我们可以打开网络限制，将这些资源请求拒绝掉。
涉及到的参数有：
poor_initial_assignment：BSS级参数；该参数的置位可以让BSS在收到手机发来的RACH消息后，分析其TA值，若超出ms_max_range的范围后，则网络将该RACH请求放弃掉，而不作任何响应，这样做可以将一些距离较远、质量可能较差的RACH消息限制在网络接受范围之外；
ms_max_range：BSS小区级参数；当手机和基站的距离超过一定门限时，网络应启动切换过程，以维持一定的通信质量，减小小区间的干扰。参数“手机最大距离”规定了手机距离的最大门限；当超越该门限时，基站将启动切换过程；
注意：
开启了BSS的poor initial assignment功能后，可以限制信号质量较差的用户接入网络的请求，从而在一定程度上避免了这些用户可能的频繁资源请求。但是，这只是一种暂时的方法，为了根本解决问题，及时地解决网络覆盖不足的问题以及合理调整基站的覆盖范围才是最终的解决办法。
（2） C2设置不合理导致基站实际覆盖过大
对于有些基站由于基站的站址比较偏远或基站位置过矮，为了吸收话务量，优化人员有时开启C2。但是，如果C2的设置过大，且邻区的切换门限没有做及时的调整，也容易造成SDCCH拥塞。
案例分析：
6月21日，化工研究院DCS由于话务量过低，我们将该站的C2打开，设置的该cell参数cell_reselect_offset设为15，即30dB。C2打开后该小区的呼叫次数增加比较明显，但由于当时未将该站的出邻区的切换门限适当增高，造成相当数量的呼叫在此小区建立后，很快切换至别的小区。从统计上看基站的total call很多，但话务量却不高，还存在一定数量的SDCCH拥塞。当我们将该站的C2关闭后，基站的SDCCH拥塞率下降为0。
date site_name cell_name SDCCH拥塞率 SDCCH话务量 TCH拥塞 TCH话务量 TOTAL_CALLS avail_tch_max erl/chan Cell话务掉话比
6-21 HuaGongYanJiuYuanDCS 31109 0.12 2.70 0.00 2.42 617.00 29 0.08 20.78
6-22 HuaGongYanJiuYuanDCS 31109 0.00 0.16 0.00 0.86 12.00 29 0.03 51.42
当基站发生SDCCH信道拥塞后，对用户申请SDCCH信道的原因进行分析后，若基站大量SDCCH的分配是被用于手机进行位置区的更新，则在采取其他措施的同时，尽可能地降低不必要的手机位置更新的次数，可以大幅度降低SDCCH信道的占用，从而减少SDCCH信道的拥塞情况。要降低LAC更新的次数，可以从LAC的划分是否合理、位置区更新滞后参数的设置等方面进行检查，分析问题所在。
1） LAC划分不合理导致手机频繁位置更新
在进行网络LAC区规划时，如果LAC区的交界被选择在手机用户数较多，用户移动性较大的地区，则会导致频繁的手机位置更新，这样会占用大量的SDCCH信道，很可能引起SDCCH的拥塞。同时，由于大量的位置区更新会造成手机经常不在服务区的现象。所以，在对网络的LAC分区进行划分时，要充分考虑具体的道路信息、手机用户分布信息、基站的位置信息等，将LAC交界避开主干道路和话务密集的地区，减少不必要的位置更新，从而降低频繁位置更新对SDCCH信道资源过度的占用。
分析SDCCH拥塞率较高的基站其占用资源的原因，如果大量是由于位置更新造成的，则要分析LAC交界的具体情况，采取调整基站的覆盖，以较少基站覆盖的不必要交叠，适当的时候要增加CRH来降低发生位置更新的几率，或者考虑增加SDCCH信道的个数。在有些时候，可能出现基站的SDCCH信道已经达到最大配置，基站的覆盖已经调整得比较合理，CRH的取值也达到最大的情况，这种情况下只能检查LAC的划分是否合理，重新调整LAC的分区，来避开高话务地区。
2） 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 边界，LOCATION UPDATE次数较多的个别小区进行了分析，考虑到用户停留在这些小区时，要占用相对较多的SDCCH信道进行位置区更新。鉴于此，我们对这些小区的SDCCH信道进行了进一步调整（参数如下）。例如：广外关厢、丰台东大桥、庞各庄。调整后这些小区的SDCCH 拥塞率得到下降，前后对比如下：
Channel_reconfig_switch=1；
Max_number_of_sdcch=48（将最大SDCCH信道数增至最大）；
Tch_need_low_water_mark=2；
BSSName SiteName gsmcellid date_and_time SDCCH拥塞率 SDCCH到达率 TCH拥塞率 busy_sdcch alloc_sdcch alloc_sdcch_fail
BSS19 PangGeZhuang_3 460-00-4170-683 25-8 1.27 774.00 0 0.94 857 11
BSS19 PangGeZhuang_3 460-00-4170-683 27-8 0.00 675.00 0 0.88 746 0
BSS19 PangGeZhuang_3 460-00-4170-683 30-8 0.23 846.00 0 0.83 872 2
BSSName SiteName gsmcellid date_and_time SDCCH拥塞率 SDCCH到达率 TCH拥塞率 busy_sdcch alloc_sdcch alloc_sdcch_fail
BSS51 GuangWaiGuanXiang_8 460-00-4182-678 25-8 2.49 8425.00 0 9.41 9209 235
BSS51 GuangWaiGuanXiang_8 460-00-4182-678 27-8 1.52 8183.00 0 9.10 8818 136
BSS51 GuangWaiGuanXiang_8 460-00-4182-678 30-8 1.61 8445.00 0.1 9.38 9143 150
BSSName SiteName gsmcellid date_and_time SDCCH拥塞率 SDCCH到达率 TCH拥塞率 busy_sdcch alloc_sdcch alloc_sdcch_fail
BSS55 FengTaiDongDaQiao_18 460-00-4192-220 25-8 2.03 2708.00 0 2.88 2943 61
BSS55 FengTaiDongDaQiao_18 460-00-4192-220 27-8 0.00 2292.00 0 2.44 2580 0
BSS55 FengTaiDongDaQiao_18 460-00-4192-220 30-8 0.00 2407.00 0 2.46 2681 0
2、考虑到德宝饭店第三方向SDCCH拥塞严重，且多数申请SDCCH的原因是用于位置更新，所以我们将与德宝饭店第三方向不同LAC的邻区北京北站第三方向、西直门饭店三个小区的参数cell_reselet_hysteresis由10dB改为14dB，前后性能对比如下：
site_name cell_name SDCCH TCH 话务量 TOTAL_CALL date_and_time
成功分配次数 分配失败次数 拥塞 成功分配次数 分配失败次数 拥塞
北京北站3 460-00-4112-260 407 0 0 650 0 0.00 4.00 199 8-9
460-00-4112-260 588 0 0 907 0 0.00 4.22 248 8-11
西直门饭店1 460-00-4112-481 387 0 0 766 0 0.00 4.83 215 8-9
460-00-4112-481 416 0 0 699 0 0.00 3.56 202 8-11
西直门饭店2 460-00-4112-482 2537 0 0 1943 2 0.10 16.31 729 8-9
460-00-4112-482 2607 0 0 2145 0 0.00 15.19 865 8-11
西直门饭店3 460-00-4112-483 554 0 0 1084 0 0.00 6.14 278 8-9
460-00-4112-483 610 0 0 1234 0 0.00 6.52 343 8-11
德宝饭店3 460-00-4132-777 3688 7774 67.82 1599 13906 89.69 22.00 1558 8-9
460-00-4132-777 2182 4 0.18 2999 248 7.64 16.37 871 8-11
四、 基站不能正常分配SDCCH信道
当基站的软件或硬件出现故障后，就可能导致在立即指配过程中，基站无法正常分配SDCCH信道，在统计上体现为SDCCH信道的拥塞。通常有以下的这些情况：
1） 硬件问题导致基站时隙退出服务从而降低小区的可用资源
基站出现硬件故障的情况，主要是指基站的载频出现单个或几个时隙退出服务，甚至整个或几个载频不能正常提供服务的情况。当出现这种硬件故障后，很可能直接导致基站的SDCCH和TCH话务拥塞。要根本解决这种原因引起的话务拥塞，必须首先处理硬件故障。
案例分析：
9月1日半壁店的SDCCH 拥塞聚增到17%，主要由于该基站的DRI 出现[46]，[45]号告警，导致大量时隙 OOS。INS 该站有问题的DRI 后恢复。同时鉴于该站SDCCH ，TCH 拥塞不平衡，调整该站的MAX_NUMBER_OF_SDCCH=48后，其SDCCH 拥塞下降为0.99%。但是9月6日该站再次出现大量时隙OOS，致使SDCCH拥塞再次上升。
Name Date OK_ACC_PROC SDCCH_CONGESTION_KEY SDCCH_TRAFFIC TCH_CONGESTION_KEY TCH_TRAFFIC
BanBiDian_10
CI＝633 1-9 942 17.89 1.2 0 4.04
2-9 912 3.37 1.05 0 4.5
3-9 992 7.42 1.2 0.19 3.96
4-9 868 0.74 0.92 0 4.05
5-9 1075 0.99 1.27 0 4.41
6-9 1036 9.66 1.29 0 3.26
2） 基站传输闪断增加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_name cell_name SDCCH成功分配次数 SDCCH分配失败次数 SDCCH拥塞 SDCCH平均占用时长 射频丢失率 话务量 date
ChangYingLouBinGuan 82 7233 31870 81.50 12.17 0.77 22.52 3-12
ChangYingLouBinGuan 82 6352 41 0.64 5.69 0.69 9.37 3-11
3） SLEEPING CELL现象引起SDCCH的拥塞
SLEEPING CELL是摩托罗拉公司BSS基站设备在某些版本、某些运行情况下，出现的一种软件运行故障。简要地说，SLEEPING CELL一般定义为没有明显基站告警，但实际基站已经不能为手机提供基本的通话服务的情况，从统计上看基站TOTAL_CALL个数为0、SDCCH拥塞率可能较高、呼叫建立成功率可能较低。一旦出现这种情况，实际现场用户反映会比较强烈，很可能造成一定范围内的负面影响。所以应该尽可能实时监控网络中基站的性能统计，尽早排除SLEEPING CELL。
由于SLEEPING CELL很可能导致SDCCH拥塞率异常，所以我们应定期根据全网统计查看SDCCH的拥塞率，如果异常增高，需要判断改小区是否存在SLEEPING CELL的现象。在每天提取的低话务量统计数据中，如果发现既无话务量又无TOTAL _CALLS的CELL，而且不是断站又没有严重的告警，这时应立即统计此CELL收到的RACH数，以进一步确认该CELL是否为SLEEPING CELL，查看该小区的统计项：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的失败次数，得到统计数据后，若符合以下几种情况，则可确认为SLEEPING CELL：
a. 收到的RACH次数为0或与前一段时间相比有非常明显的减少；
b. 收到的RACH数较多，但无法正确解出RACH；
c. 收到的RACH数较多，也可以正确解出RACH，但无法分配SDCCH；
d. 收到的RACH数较多，也可以正确解出RACH，分配SDCCH，但无法分配TCH；
确认该CELL为SLEEPING CELL后，用MMI方式进入相应BSS内，键入chg_level进入第二层，INS该CELL中BCCH所在的DRI，一般SLEEPING CELL的现象即可恢复。
案例分析：
由于周末BSS软件版本升级，从第二天凌晨2点开始，BSS16的蒋家坟第一个小区出现与升级前表现不尽相同，但后果更为严重的SLEEPING CELL。该基站有成功的RACH请求几千次，但没有成功分配SDCCH的次数，致使CALL SETUP SUCCESS RATE 为0，TOTAL-CALL为0，TCH-TRAFFIC为0（数据如下表），发现问题后优化人员于下午INS BCCH所在DRI，基站得到恢复，工作正常。
Time ACCESS_PER_RACH ALLOC_SDCCH ALLOC_SDCCH_FAIL ALLOC_TCH
9:00 83518 0 76465 0
10:00 88118 0 81017 0
ALLOC_TCH_FAIL OK_ACC_PROC_SUC_RACH TCH_TRAFFIC TOTAL_CALLS
9:00 1989 76467 0 0
10:00 1746 81019 0 0
4） SDCCH信道吊死导致基站不能正常分配
与SDCCH拥塞率相关的统计项，其中有一项是SDCCH平均占用时长， 若某个CELL的SDCCH平均占用时长比其他CELL明显大出很多，不合常理，那么该CELL的SDCCH有可能吊死在那儿。这种情况与SLEEPING CELL比较类似，但稍有不同，发生SDCCH吊死的情况时，该基站还能分配一些资源供手机使用，但在分配SDCCH时成功率非常低。从基站的实时运行状态看，该基站的绝大部分SDCCH均长期被占有，而无正常释放。但尚存在个别SDCCH能够被正常的呼叫建立所使用。出现这种情况后，应INS 该CELL BCCH所在的DRI，通常基站都可恢复正常工作。
5） RTF与DRI的对应关系发生紊乱
由于基站软件运行故障，在BSS1614的软件版本中，存在软件BUG，有基站RTF与DRI的对应关系发生紊乱的情况，尤其是小区BCCH载频的RTF与DRI关系不正常，主要体现为小区内出现多个BCCH的RTF。出现这种情况时，通常该小区的SDCCH拥塞率会受影响。
案例分析：
以下是兆麟大厦在6月4日出现RTF与DRI的对应关系发生紊乱的案例，下面是该基站的当时状态查询和性能统计数据（有删减）：
MMI-RAM 0217 -> state 10 dri * *
DEVICE STATUS INFORMATION FOR LOCATION 10:
Device State Reason dd/mm hh:mm:ss Function
------------- ----- ------------------------- --------------- -------------
DRI 0 0 0 B-U NO REASON 03/06 15:32:13 RTF 0 2 0
DRI 0 1 0 B-U NO REASON 03/06 10:57:19 RTF 0 1 0
DRI 0 2 0 B-U NO REASON 03/06 10:56:18 RTF 0 0 0
DRI 0 3 0 B-U NO REASON 03/06 10:51:06 RTF 0 0 0
MMI-RAM 0217 -> state 10 rtf * *
FUNCTION STATUS INFORMATION FOR LOCATION 10:
Function State Reason dd/mm hh:mm:ss Device
------------- ----- ------------------------- --------------- -------------
RTF 0 0 0 B-E NO REASON 03/06 10:55:53 DRI 0 2 0
RTF 0 1 0 B-E NO REASON 03/06 10:57:01 DRI 0 1 0
RTF 0 2 0 B-E NO REASON 03/06 15:31:54 DRI 0 0 0
RTF 0 3 0 E-E NO REASON 03/06 10:50:07 None
MMI-RAM 0217 -> disp_cell_s 10
MCC 460 460 460
MNC 00 00 00
LAC 4150 (1036h) 4150 (1036h) 4150 (1036h)
CI 55 (0037h) 56 (0038h) 57 (0039h)
Status Unbarred Unbarred Unbarred
FREE INUSE UNAVL FREE INUSE UNAVL FREE INUSE UNAVL
----- ----- ----- ----- ----- ----- ----- ----- -----
SDCCH 10 30 0 22 10 0 24 8 0
Norm TCH/F 13 1 0 21 2 0 28 11 0
Ext TCH/F 0 0 0 0 0 0 0 0 0
PD CHANNEL 4 0 0 4 0 0 4 0 0
下表是该小区的性能统计，该小区在6月3日出现了RTF与DRI关系紊乱的故障，从path_balance的统计值可以看出，出现故障后，该小区有问题的RTF（即RTF 00）的path_balance异常增高，且SDCCH的拥塞次数大幅度增加。
date site_name cell_name carrier ber_mean rf_loss path_balance_mean
6-1 ZhaoLinDaSha 460-00-4150-55 RTF-00-00 0.33 0 107.60
6-4 ZhaoLinDaSha 460-00-4150-55 RTF-00-00 1.87 3 129.67
site_name cell_name SD成功分配次数 SD分配失败次数 SDCCH拥塞 SDCCH平均占用时长 射频丢失率 话务量 date
ZhaoLinDaSha 460-00-4150-55 1387 0 0 4.60 0.32 1.60 5-31
ZhaoLinDaSha 460-00-4150-55 13279 385 2.82 26.28 7.40 10.66 6-3
ZhaoLinDaSha 460-00-4150-55 14411 559 3.73 32.80 8.86 11.31 6-4
出现这种情况后，一般将出现故障的RTF所对应的DRI进行INS操作后，问题即可解决。
在立即指配完成后，网络会在指定的时间内等待手机占用SDCCH信道，但是，有时会发生因为各种原因而导致手机不能正常地占用SDCCH的情况，并且现象的存在若比较严重的话，可能引起手机在多次立即指配不成功的情况下，多次申请网络服务，引起大量的SDCCH资源请求，从统计上看SDCCH拥塞率较高。一般造成这种现象的原因有：
1） 小区载频硬件问题
由于小区硬件问题导致系统分配完SDCCH后，手机无法占上SDCCH信道，从统计上看，表现为chan_req_ms_fail的值较高。此时，手机在收到Immediate Assignment消息后尝试占用SDCCH，在网络参数T3101规定的时间内手机占用SDCCH却不成功，这样呼叫就没有建立起来。出现这种情况，很可能导致手机在多次申请网络服务不成功后，继续申请资源，从而引起不必要的SDCCH分配，可能造成SDCCH信道的拥塞。
此问题一般是由于基站的某个或某几个载频故障导致：在现场测试时可以发现，当手机被分配给固定的某个载频的TCH时隙后，在试图占用时总是出现占用不成功的现象；若要从OMC统计上观察，则可以通过将该小区的信道盘逐个LOCK住，观察每个TCU在被LOCK住后，小区性能统计chan_req_ms_fail的统计值是否还很高。如果在闭掉某个TCU后，chan_req_ms_fail的值恢复正常，则可以判断问题出在该载频上。
当发生这种问题后，在进行故障定位的基础上，只需将该载频更换即可。
2） 参数设置错误问题
由于网络在向手机发送Immediate Assignment消息后，开始计时（T3101），手机要在此计时器规定的时间内接入网络，若计时器超时而手机还未成功接入，此时系统将触发统计项chan_req_ms_fail。
T3101：BSS中小区级参数；它的取值定义了系统从发送Immediate Assignment消息后，等待手机建立SDCCH连接的时间。这个参数的大小要综合考虑手机占上SDCCH平均所需的时间和基站SDCCH信道拥塞情况。取值过大可能造成基站资源浪费，取值过小将可能引起大量手机不能正常占上SDCCH的现象。现在北京移动全网大部分基站的此参数取值为1500（1.5秒）。
3） 存在频率干扰的问题
如果基站存在严重的系统内部或系统外部的干扰时，手机在进行SDCCH的接续时，可能由于存在频率的干扰而收不到系统发来的Immediate Assignment消息，或者收到该消息后，在接入系统的时候由于干扰，网络无法正确解出手机发来的Immediate Assignment消息，从而最终造成手机无法占用系统为其所分配的SDCCH资源。这样，在一定程度上会引起手机多次申请网络服务，造成系统资源的拥塞。
要解决干扰问题，首先要判断干扰来自本系统内，还是系统外的干扰。这可以通过OMC统计观察该站的空闲情况下的干扰统计IOI，如果24小时均很高，则干扰很可能来自系统外；如果IOI只是随着网络的话务量增长而增值，则问题很可能来自系统内的频率规划。对于系统外的干扰，要具体查找干扰源，一般是电台、电力设备、非法直放站等所造成；对于系统内的干扰，则要检查该站的频率规划是否存在问题。
六、 由于基站异常原因导致用户频繁重新申请网络资源
当基站存在比较明显的单通或无声时，手机用户在打电话时若感觉到没有声音，在最初发现时，用户一般会再拨打几次才会放弃尝试。当用户话务量相对比较集中时，若遇到这种基站单通或无声的问题，则很容易发生大量用户频繁申请网络服务的现象，基站的SDCCH拥塞率指标会比基站工作正常时有所提高。
七、
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | |||||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | |||
| 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||
| 16 | 17 | 18 | 19 | 20 | 21 | 22 | |||
| 23 | 24 | 25 | 26 | 27 | 28 | 29 | |||
| 30 | |||||||||
我的存档
数据统计
- 访问量: 25718
- 日志数: 123
- 图片数: 13
- 文件数: 46
- 书签数: 1
- 建立时间: 2007-02-01
- 更新时间: 2008-10-25
