电子鱼 发表于 2009-10-5 00:36:09

TD网络优化--寻呼优化



寻呼是移动网络重要组成部分,用于寻找并呼叫那些分布在不同位置区中自由移动的注册用户终端,终端在各种状态下响应并完成网络发起的信令或业务过程,直接影响用户实际使用网络的体验。所以寻呼对TD-SCDMA系统来说至关重要。
      寻呼优化流程
      网络运行一段时间后就可以收集相关网络数据,通过分析网络数据发现问题,并对网络进行优化处理。``寻呼优化流程如图1所示:
http://www.cww.net.cn/upLoadFile/2009/3/3/200933145940734.gif


v对于TD网络,可能出现的寻呼问题主要是以下几点:
      (1)寻呼信道容量不够,RNC没有下发寻呼消息;
      (2)由于功率或干扰,UE没有接收到寻呼消息;
      (3)UE频繁发生小区重选或位置更新,无法接收到寻呼消息;
      (4)CN原因没有下发寻呼给RNC。
      常规的寻呼问题如2、3、4条一般都是无线和核心网侧的问题,这里不再赘述。而资源不足是TD系统联调方面的情况,比如由于短信群发导致寻呼拥塞,该问题是TD网络在奥运期间出现的,下面我们重点讨论寻呼拥塞的相应优化措施。
      寻呼拥塞案例
      在奥运期间,部分TD外场出现过由于群发短信业务导致网络侧寻呼拥塞的情况,中兴通讯优化团队对其进行了分析并提出优化方法。根据统计,奥运期间外场寻呼拥塞率统计如表1。
http://www.cww.net.cn/upLoadFile/2009/3/3/200933145941580.gif


      从表1可以看到有两个城市的寻呼拥塞率都在10%左右,这意味着拨打10次电话或者发送短消息只有9次寻呼成功。该问题直接影响到用户使用网络的实际体验。
      拥塞原因分析
      我们在后台通过CN侧的CS短信寻呼图与RNC侧寻呼统计图可以看出,短信寻呼下发次数的超高峰(11:30~11:40,20:30~20:40)和高峰(13:35~13:45,22:30~22:40)在CN侧与RNC侧出现的时间点完全吻合,说明拥塞并在RNC侧和CN侧同时存在,可以认为拥塞是整个系统的问题。
      对CN侧CS域语音寻呼进行统计,可知CS域语音寻呼(以5分钟为粒度)一天的变化趋势是正常的,说明现网中的寻呼拥塞并没有影响客户对语音业务的主观感受。对CN侧PS域语音也进行了寻呼统计,可知PS域寻呼(以5分钟为粒度)一天的变化趋势也是正常的,说明现网中的寻呼拥塞,也没有影响PS域业务的客户主观感受。
      而后统计了CN侧在CS域的短信寻呼指标,发现CS域短信寻呼(以5分钟为粒度)一天的变化趋势有异常,短信的寻呼次数远远大于语音的寻呼次数,每天都有2个超高峰、2个高峰,同时伴随若干次高峰,这表示有严重的突发情况。在高峰期寻呼响应率只有约30%左右,若再加上MSC二次寻呼及RNC二次重发的次数,更加重了RNC侧的拥塞。我们认为在这5分钟时间段(目前统计最小的粒度为5分钟)中的几十秒内有大量的寻呼消息同时下发,导致网络侧出现较严重的拥塞。

      解决方案
      我们可以用以下方法解决外场寻呼拥塞问题:
      (1)优化放号规则,提高寻呼信道利用率(根据TD寻呼机制来做调整)。
      (2)CN寻呼机制采用TMSI寻呼,寻呼能力提高1/3(根据TD寻呼机制调整) 。
      (3)优化CN的短消息处理机制,降低突发寻呼量(根据网络性能调整)。
      降低CN每秒下发的寻呼需求,可以降低寻呼冲突的概率,提高寻呼成功率;
      降低CN对短消息寻呼的重发机制,取消重发;
      延长CN对短消息寻呼的等待时间,RNC优化处理流程,提高短消息的寻呼成功率;
      如果短消息中心采取的寻呼策略能考虑接入网寻呼的限制,适当进行流控和均匀化,能够避免或缓解寻呼拥塞的程度。
      (4)优化LAC配置,减少LAC中寻呼的UE数目(根据网络寻呼能力调整)
      CS域寻呼消息是按LAC进行下发的,一类寻呼消息在LAC中的每个小区都进行下发,如每个LAC规划的用户容量适中,则可减少寻呼冲突的概率。
      (5)提升系统寻呼能力(根据厂商终端能力调整)
      优化相关系统参数,如减少重发次数等。
      结果
      通过以上的优化方案,目前各个外场寻呼拥塞问题基本解决。
页: [1]
查看完整版本: TD网络优化--寻呼优化