GSM网络SDCCH掉话分析报告.docxVIP

GSM网络SDCCH掉话分析报告 　2007-05-11 17:52　 来源：中国通信运维网 ??????? 综述：本次工作任务旨在对SDCCH掉话的机理及其对网络的影响进行分析。在分析过程中，力求做到采用多途径及综合手段进行验证及分析，报告在最后部分针对当前发现的问题，提出了相应的优化和改进建议，希望能对移动公司的网络性能改善起到积极的作用。 ??????? OMC部分的初步分析（BSC级）： 从P_NBSC_SERVICE，P_NBSC_TRAFFIC，P_NBSC_CC三个数据表中的BSC级测量统计来看，P_NBSC_CC中的Phase 1下的Clear code 21（Corrupted Establish_Indication）的次数为9011次，P_NBSC_SERVICE中的T3101超时计数为9023次，P_NBSC_TRAFFIC中SDCCH_Abis接口掉话值为9283（也包括其它一些Clearcode导致的掉话，由于NOKIA OBS测量数据不可用，暂时无法通过CauseCode精细验证）。这三组数据具有比较明显的吻合性，初步证明T3101超时是导致SDCCH Abis接口掉话的主要原因。 T3101的超时原理如下图表示： Figure 1: T3101超时原理 ??????? 如上图所示，在BSC下发Imm_assign_cmd之后，在T3101的时限内如果没有收到上行的Establishment_Indication建立指示，则由系统下发强制SDCCH拆线指令，以及时释放SDCCH资源。 ??????? 案例：梧田社保局 CELLID：10552，BSC15，BTS22，TRX-2??????? 过程描述：分别在3月10日，15日进行了两次Abis接口挂表信令跟踪（BTS22的TRX2，BCCH载频），通过对结果的观察分析，有如下发现： ??????? 1.实际捕获的SDCCH占用请求次数为803次，拥塞2次，立即指配命令下发为801次。??????? 2.有9次存在“TRX having “Error Indication”case”错误提示。??????? 该问题在信令分析仪中已有明确说明，为LAPD链路计数器T200超时导致，由于该部分占SDCCH掉话的比重很小，不再做具体分析。??????? 3.有128次存在“TRX where assigned SDCCH are not used”错误提示。 ??????? 详细分析信令内容，发现在系统发送Imm_Assign_Cmd之后没有收到上行的Establish_Ind消息，而是直接对SDCCH资源进行释放。观察Imm_Assign_Cmd至Channel_Rel之间的时长，全部为5秒。检查BSC15的T3101设置值为5秒，基本确定目前几乎所有的SDCCH_Abis掉话均为T3101超时导致。符合先前依据NOKIA的OMC统计的分析结果。同时观察无上行建立指示情况下的测量报告中（系统强制释放SDCCH资源以前），观察到的所有的上行质量测量均为7（BER12.8%），场强也普遍较弱（基本在-100dBm左右）。 ??????? 这部分由T3101超时导致的SDCCH Abis掉话在请求业务类型上的分配比例如下图所示： Figure 2: SDCCH掉话原因分类（NETTEST结果） ??????? *在主叫的SDCCH占用失败中，需要考虑由于重发导致的再次掉话，这在信令中已经观察得到。SDCCH NEEDED目前没有确定是何种业务类型。 ??????? 由上图可见，挂表的结果显示超过一半的SDCCH_Abis接口掉话发生在位置更新过程。 ??????? 上图为梧田社保局在3月15日早忙时的OMC数据，第二部分和第三部分的差值[453次]基本反映了SDCCH_Abis掉话的量值，当日同时段依据传统公式计算出来的SDCCH_Abis掉话次数为449次，表明了在此中间也有4次的失败事件并非由T3101超时引起。进一步分析OMC数据： ??????? 在OMC的Counter[SDCCH_MOC_SEIZ_ATT]无法区分位置更新请求次数和主叫请求次数，但是可以得知被叫请求次数，按主被叫概率基本相同来考虑，位置更新请求次数约为1886次，和成功的位置更新请求个数[SDCCH_LOC_UPD]来对比，相差400次左右（Abis掉话），可以认为449次SDCCH_Abis掉话中，位置更新过程中的掉话占了主要部分，这也和Figure 2中挂表采集的信令中的观察结果相一致。同时，大致计算该基站位置更新过程中SDCCH_Abis的掉话率为400/1800=22%。 ??????? 采取的实验措施： ??????? 1.调整同BCCH同BSIC。