SDCCH接通率低原因分析一例.docVIP

SDCCH接通率低原因分析一例 摘 要：本文根据实际工作中个别小区SDCCH接通率低的情况利用MPA7300及COMPASS软件对随机接入的信令流程进行具体分析及验证，确定同频同BSIC小区之间可能存在接入干扰的原因，并提出解决的方法。 关键词：干扰 信令 随机 接通率 现象： 近一年多来，随着GSM扩容工程的不断进行，一批又一批的新建基站投入运行，市区基站频点的复用距离越来越短。我们在BSC的STS中发现SDCCH接通率有逐渐下降的趋势，约下降了3%。其中有几个小区的SDCCH接通率在55%--75%间。于是我选了较为典型的一个小区（厦岭路1）来具体分析。 初步分析： 用MPA7300在小区厦岭路1的Abis接口录了近一小时的信令，通过COMPASS 软件处理后，在“OVERALL ANALYSIS REPORT”中看到有约500次的“TRX where assigned SDCCH are not used”,它直接造成了SDCCH接通失败。通过对照，发现其次数与BSC STS 中SDCCH分配不成功的数量相差不大，可见这是导致SDCCH接通率低的主要原因。其具体的信令过程如图一： 图一：TRX where assigned SDCCH are not used（厦岭路1）。 从图一的信令流程来看: BSC收到MS在RACH(Random Access Channel )发出的channel request消息后， 要求BTS激活一个SDCCH，BTS 激活信道并向BSC 确认，接着BSC通过BTS 在AGCH 上向MS发出Immediate Assignment消息，然后BTS在指定的SDCCH等了1.9秒都收不到MS的任何回应，于是BSC要求BTS释放刚才已激活的SDCCH。 进一步解码RACH上Channel Required消息的内容，见图二： 图二：厦岭路1收到的Channel Required消息的具体内容。 由上图可见，Access delay 为31（由BTS通过RANDOM ACCESS BURST计算出来的TA值，在即时分配时发送给MS，MS在接入专用信道时使用），似乎是MS在距离厦岭路基站17公里外的地方发来的。我对这500次的“TRX where assigned SDCCH are not used”信令流程进行抽查统计，发现其中Access delay值等于30或31的占90%以上，其余的基本在0与5间。观察该小区的测量报告在TA轴上的分布情况，见图三： 图三：厦岭路1的测量报告在TA轴上的分布图。 由图三可见，在TA=30或31处没有实际话务，可初步认为BTS收到的这种Channel Request 消息是干扰信号。在BSC限定MAXTA参数为28（2830）后，再统计，该小区的SDCCH接通率由原来的55%左右上升到90%以上，在信令上分析，原来的“TRX where assigned SDCCH are not used”变成了“TRX where “Channel Required” get no “Immediate Assignment””,即BSC判断实际的TA值大于MAXTA，就拒绝分配SDCCH给MS，于是避免了SDCCH接入失败的发生。 进一步分析： 厦岭路1的SDCCH的接通率恢复了正常，但问题仍然存在：因为在距离厦岭路基站17公里的区域没有与厦岭路1同BCCHNO且同BSIC的小区。究竟上述的“干扰信号”是什么设备在哪儿发射出来的呢？ 经过分析与思考，我怀疑“干扰信号”是处于陵海基站第一小区（与厦岭路1同BCCHNO和BSIC，距离厦岭路基站2.6公里）内的MS所发出的。为了验证，我用两台MPA7300信令仪同时录下厦岭路1和陵海1在Abis口的信令。 用COMPASS软件分析录得的上述两个小区的信令，可完全确定“干扰信号”确实是处于陵海1内的MS所发出的。理由是：在厦岭路1基本上所有的“干扰信号”（Channel Request且其中Access delay约为30）都有在陵海1录得的同一时间的Channel Request消息与之相对应，而且消息中的“Random access information”完全相同。另外，与之对应的陵海1的Channel Request消息都是正常信令流程中的消息。下面举一对相对应的消息解释。图四是厦岭路1收到“干扰信号”的一个信令流程（已将MAXTA设为28）。 图四：厦岭路1收到“干扰信号”的一个信令流程 在COMPASS上双击图四中的时间区域，解码Channel Required中的具体内容，MS发出的消息中的随机号码（Random access information）是09。下面再来看在陵海1录得的同一时间的一