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 信道发...
