3G寻呼量较少网络下寻呼成功率指标较低问题分析专题

3G寻呼量较少网络下寻呼成功率指标较低

问题分析专题

目录

一、背景介绍 (3)

二、故障现象描述 (3)

三、原因分析及定位 (4)

四、处理方法介绍 (12)

五、经验总结 (12)

2

一、背景介绍

随着全省3G网络建设步伐的加快，各地3G网络覆盖范围快速增加，紧跟建设步伐的网络优化活动也大规模开展。盐城公司在本地的3G网络优化过程中遇到了一些端局下3G寻呼成功率较低问题。例如在NJGS24等2/3G融合端局，在3G无线覆盖水平明显较2G存在较大差距的情况下，从端局话务统计上看，3G网络的寻呼成功率明显偏低，本文就此问题进行了分析。

本专题主要包含如下内容：

◆现象描述

◆原因分析与定位

◆处理方法介绍

◆经验总结

二、故障现象描述

端局接入RNC数据增加后，近日交换侧指标监控发现，建湖NJGS24下一个RNC下挂的5个3G LAC的寻呼成功率较低，最低的甚至为0。相关的统计指标如下。

3

4

表1 3月8日晚间寻呼统计表 从上表中，我们可以得出一个规律：

1、Iu 口的第一次寻呼次数低。5个LAC 中只有1个覆盖县城的LAC 的一次寻呼次数达到100次以上，其他乡镇的LAC 一次寻呼次数都在30次一下，甚至有的一个晚忙时只有7次。

2、重复寻呼次数远远高于一次寻呼总次数。

3、一次寻呼次数越多的LAC ，它的寻呼成功率越高。这5个

LAC 中，次数较多的成功率越高，次数越少成功率越低。例如D156,3个时段的成功率在80％以上，其他4个LAC 最高的只有36％，最低的只有0％。

下面是市区一个端局下的3G LAC 寻呼指标统计：

表2 寻呼较多的一个LAC 的成功率统计

从上表可以看出，市区的一个LAC 下的寻呼次数在达到几千次后，一次寻呼成功率的指标明显高于寻呼次数只有几十次的乡镇覆盖区的LAC 。

三、原因分析及定位

分析指标偏低可能出现的原因：

✧ 核心网和无线侧关于寻呼相关的软参设置不合理； ✧ 实际寻呼次数与端局话统的数据有误差；

✧ 无线环境特别恶劣，造成寻呼得不到用户终端的响应； ✧ 其他可能性，如核心网统计指标点的定义问题等。

5

根据可能存在的原因，我们一一进行了核查与分析，具体如下： 1、核心网和无线侧寻呼参数设置核查

检查端局的寻呼策略设置。结果显示与2G 网络下的设置情况一致，语音业务和短信均采用3次寻呼，前两次为本LAC 寻呼，第三次为全网寻呼。寻呼时长分别为6、6、4，采用TMSI 、IMSI 、TMSI 方式。交换侧核心参数检查无问题。

图1 寻呼策略

图2 周期性位置更新配置无线侧反馈RNC配置检查也无问题：

表3 RNC配置查询指令

具体查询结果可参考以下附件，重点部分已经用黄色标注。

RNC寻呼相关软参.x

ls

2、实际寻呼次数与端局话统的数据是否有误差

在统计指标异常低的情况下，通常会对用户感知造成较为明显的影响，但是一直未收到用户投诉。因此判断是否有可能是统计数据存在异常？为了验证具体的统计值是否有异常，我们在端局上定义了15分钟的统计报告，同时打开了端局Iu口的信令跟踪，现场安排人员配合测试。注：由于本局3G用户数量较少，所以打开了Iu口进行PAGING消息的跟踪，如用户量较大需要视实际情况决定是否进行相应操作。我们在开始信令跟踪前发现2G的全网寻呼对3G的寻呼跟踪有一定影响，便在开始跟踪前关闭了全网寻呼。

表4 9日下午配合信令跟踪统计寻呼次数

通过信令跟踪发现在15分钟内，端局统计到的寻呼次数与信令消息中的数量相同，从而验证了端局统计数据无异常。下面是信令跟踪截图：

6

图3 15分钟统计报告中相应的寻呼信令

3、无线环境特别恶劣，造成寻呼得不到用户终端的响应

寻呼成功率低的问题，通常在核心网寻呼参数无异常的情况下，无线环境是最重要的影响因素。无线网优人员首先检查了该地区的无线网络覆盖情况，可以排除在无线覆盖方面存在有严重影响寻呼成功率的因素。为了验证网络覆盖情况，我们协调无线优化厂家安排现场测试，并确保在各LAC下均进行呼叫测试。结果显示被叫接通率很高，未出现被叫接通率低的情况，由此我们排除了无线环境特别恶劣造成寻呼得不到用户终端响应的可能性。

4、其他可能性

本地发现除了一个NJGS24端局的3G寻呼指标较低外，本地的10个下挂RNC 的端局中还有很多的端局有同样的情况。但是覆盖市区的3个端局的3G寻呼成功率明显高于其他覆盖乡镇的端局。本地10套端局，4套采用的ATM对接，6套采用IP方式接入核心网，均存在指标较差的情况。是否是什么软参设置不一样造成指标出现如此大的差异呢？我们本地的所有端局进行了软件比对，结果显示一致。至此，我们的分析好像陷入了困境。但是，我们在查询统计报告时发现

了一点问题。

7

表5 统计表

上表中可以看到，在进行统计前我们已经将本局的全网寻呼进行了关闭。但是在统计表中确发现了有全网寻呼次数。而且发现了这5个LAC的全网寻呼次数相同，业务量小的D155/D157/D158/D159的一次寻呼次数相同，且都等于全网寻呼次数。那么，否可以理解为：在11：00的这个时段，D155/D157/D158/D159这4个LAC的真正一次寻呼次数应该为0，统计到的一次寻呼次数应该是全网寻呼的次数。

那么在已经关闭了全网寻呼的情况下，为何又会产生全网寻呼呢？通过查询资料，了解到华为端局交换机在“用户数据修复”时会向全网发送PAGING。那么究竟在哪些情况下会出现“用户数据修复”呢。主要内容可概括为：在VLR 中没有相关用户数据，但是被叫归属HLR中存储的VLRNB指向了本VLR，并向本VLR来请求漫游号码，这时VLR会向本端局下的所有位置区发PAGING消息，以便获取被叫号码的位置信息后进行其他后续流程。为了验证我们的分析，我们分析了表5同时段的Iu口PAGING消息，在15分钟内确实发现了1次全网寻呼消息：

8