《GSM网络SDCCH掉话分析报告》由会员分享，可在线阅读，更多相关《GSM网络SDCCH掉话分析报告（9页珍藏版）》请在金锄头文库上搜索。
1、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 Esta
2、blish_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 之后，在 T3
3、101 的时限内如果没有收到上行的 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”错
4、误提示。该问题在信令分析仪中已有明确说明，为 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
5、 掉话均为 T3101 超时导致。符合先前依据 NOKIA 的 OMC 统计的分析结果。同时观察无上行建立指示情况下的测量报告中（系统强制释放 SDCCH 资源以前），观察到的所有的上行质量测量均为 7（BER12.8%），场强也普遍较弱（基本在-100dBm 左右）。这部分由 T3101 超时导致的 SDCCH Abis 掉话在请求业务类型上的分配比例如下图所示：Figure 2: SDCCH 掉话原因分类（NETTEST 结果）*在主叫的 SDCCH 占用失败中，需要考虑由于重发导致的再次掉话，这在信令中已经观察得到。SDCCH NEEDED 目前没有确定是何种业务类型。由上图可见，挂表的
6、结果显示超过一半的 SDCCH_Abis 接口掉话发生在位置更新过程。上图为梧田社保局在 3 月 15 日早忙时的 OMC 数据，第二部分和第三部分的差值453 次基本反映了 SDCCH_Abis 掉话的量值，当日同时段依据传统公式计算出来的 SDCCH_Abis 掉话次数为 449 次，表明了在此中间也有 4 次的失败事件并非由 T3101 超时引起。进一步分析 OMC 数据：在 OMC 的 CounterSDCCH_MOC_SEIZ_ATT无法区分位置更新请求次数和主叫请求次数，但是可以得知被叫请求次数，按主被叫概率基本相同来考虑，位置更新请求次数约为 1886 次，和成功的位置更新请求个
7、数SDCCH_LOC_UPD来对比，相差 400 次左右（Abis 掉话），可以认为449 次 SDCCH_Abis 掉话中，位置更新过程中的掉话占了主要部分，这也和 Figure 2 中挂表采集的信令中的观察结果相一致。同时，大致计算该基站位置更新过程中 SDCCH_Abis 的掉话率为 400/1800=22%。采取的实验措施：1.调整同 BCCH 同 BSIC。2.开启 SDCCH 切换。3.将 CBCH 信道转移到 MBCCH 上。效果不明显，该站客观存在 13 级的带外干扰，上行 Q0 也很差。后续建议请参考后面总结部分的内容。附加图示： Figure 3: SDCCH 掉话率 Vs
8、 平均通话距离Figure 4: SDCCH 掉话率 Vs 下行误码率Figure 5: SDCCH 掉话率 Vs 上行误码率Figure 6: SDCCH 掉话率 Vs 上行场强Figure 7: SDCCH 掉话率 Vs 下行场强 结论：1.目前网络主要的 SDCCH 掉话集中在 Abis 接口。2.Abis 接口的绝大部分掉话为 T3101 超时导致，比例在 80%左右。3.T3101 超时的主要原因是立即指配过程中收不到上行的建立指示。4.在无上行建立指示的测量报告中，观察到的所有的上行质量测量均为 7（BER12.8%），场强也普遍较弱（基本在-100dBm 左右）。5.弱覆盖或网内
9、外干扰是导致 SDCCH 掉话的主要原因。6.SDCCH 掉话行为主要发生在 Location Update 过程，并且在此过程中 SDCCH 的掉话率也明显高于主被叫过程。7.目前统计到的 SDCCH 掉话不会对主被叫过程的客户感知度造成明显的影响。建议：1.有效控制网内干扰。温州城区的站点密度较大，站高相对较高，同时基站全部为满功率发射，再加上建筑地形比较复杂，由此产生的越区覆盖容易导致孤岛效应并造成弱场强服务区或频率冲突，将对网络性能产生比较明显的负面影响。目前可以通过如下手段来控制该负面因素：a. 充分利用功率控制，总体上降低网内上行发射水平。如目前温州的质量原因下降功率控制难以触发。
10、b. 优化 RACH 及 HO Access 过程中的初始功率发射水平，通过 POPT，LEV，LEVD 等参数可以达到优化目的。*温州以前的 POPT 实验没有开启 MsPwrOptLevel 的 Feature，因而实际是无效的，建议重新开始该方面的实验工作。 c. 合理控制天线下倾，避免严重越区覆盖的问题出现。2.规划新站频点时注意区域内的同频同 BSIC 现象，该问题会导致 BTS 错误的将周边 BTS 间的切换接入脉冲当作本小区的 RACH 接入脉冲（HO overhearing），而错误的为其分配 SDCCH资源并导致 SDCCH 掉话或拥塞。该点可以结合天线下倾（防止越区覆盖）的控制工作一起进行。
