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

1、3g寻呼量较少网络下寻呼成功率指标较低问题分析专题拟制王雨坤、金一、王育伟日期2011-3-11评审人批准签发日期日期日期目录一、背景介绍 .3二、故障现象描述 .3三、原因分析及定位 .4四、处理方法介绍 .12五、经验总结 .122 / 122专业进取协作共享一、背景介绍随着全省 3g 网络建设步伐的加快，各地3g 网络覆盖范围快速增加，紧跟建设步伐的网络优化活动也大规模开展。盐城公司在本地的3g 网络优化过程中遇到了一些端局下3g 寻呼成功率较低问题。例如在njgs24 等 2/3g 融合端局， 在 3g 无线覆盖水平明显较2g 存在较大差距的情况下，从端局话务统计上看， 3g 网络的寻

2、呼成功率明显偏低，本文就此问题进行了分析。本专题主要包含如下内容：现象描述原因分析与定位处理方法介绍 经验总结二、故障现象描述对象实例开始时间iu 口第一次发寻呼次数iu 口第一次寻呼响应次数iu 接口重复发寻呼次数iu 口重复寻呼响应次数一次寻呼成功率3g 寻呼成功率3 / 123端局接入 rnc 数据增加后，近日交换侧指标监控发现，建湖 njgs24 下一个 rnc 下挂的 5 个 3g lac 的寻呼成功率较低，最低的甚至为 0。相关的统计指标如下。46000d1552011-3-8 18:9.23%19.23%46000d1552011-3-8 19:0080682800.00%0.0

3、0%46000d1552011-3-8 20:.88%5.88%46000d1552011-3-8 21:.70%3.70%46000d1562011-3-8 18:3185.03%85.63%46000d1562011-3-8 19:083.62%83.62%46000d1562011-3-8 20:0188.43%89.26%46000d1562011-3-8 21:67.02%70.21%46000d1572011-3-8 18:.70%8.70%46000d1572011-3-8 19:0070682800.00%0.00%46000d1572011-3-8 20:.00%0.00%4

4、6000d1572011-3-8 21:.00%0.00%46000d1582011-3-8 18:.45%3.45%46000d1582011-3-8 19:6.36%36.36%46000d1582011-3-8 20:5.38%15.38%46000d1582011-3-8 21:3.33%13.33%46000d1592011-3-8 18:.70%8.70%46000d1592011-3-8 19:0070682800.00%0.00%46000d1592011-3-8 20:.00%0.00%46000d1592011-3-8 21:.70%3.70%表 13 月 8 日晚间寻呼统

5、计表从上表中，我们可以得出一个规律：1、iu 口的第一次寻呼次数低。 5 个 lac 中只有 1 个覆盖县城的 lac 的一次寻呼次数达到 100 次以上，其他乡镇的 lac 一次寻呼次数都在 30 次一下， 甚至有的一个晚忙时只有 7 次。2、重复寻呼次数远远高于一次寻呼总次数。3、一次寻呼次数越多的 lac ，它的寻呼成功率越高。这 5 个 lac 中，次数较多的成功率越高， 次数越少成功率越低。例如 d156,3 个时段的成功率在 80 以上，其他 4 个 lac 最高的只有 36，最低的只有 0。下面是市区一个端局下的 3g lac 寻呼指标统计：对象实例开始时间iu 口第一次发iu

6、口第一次响应iu 接口重复发iu 口重复响应一次寻呼成功率3g寻呼成功率46000d1542011-3-8 18:49113389.89%93.42%46000d1542011-3-8 19:8897492.68%96.00%46000d1542011-3-8 20:2518392.41%96.37%表 2寻呼较多的一个lac 的成功率统计从上表可以看出，市区的一个lac 下的寻呼次数在达到几千次后，一次寻呼成功率的指标明显高于寻呼次数只有几十次的乡镇覆盖区的lac 。三、原因分析及定位分析指标偏低可能出现的原因：核心网和无线侧关于寻呼相关的软参设置不合理； 实际寻呼次数与端局话统的数据有误差

7、；无线环境特别恶劣，造成寻呼得不到用户终端的响应； 其他可能性，如核心网统计指标点的定义问题等。4 / 124根据可能存在的原因，我们一一进行了核查与分析，具体如下：1、核心网和无线侧寻呼参数设置核查图 1寻呼策略5 / 125检查端局的寻呼策略设置。结果显示与2g网络下的设置情况一致，语音业务和短信均采用3 次寻呼， 前两次为本 lac寻呼， 第三次为全网寻呼。 寻呼时长分别为 6、6、4，采用 tmsi、imsi 、tmsi方式。交换侧核心参数检查无问题。图 2周期性位置更新配置无线侧反馈 rnc配置检查也无问题：网元指令内容lst fcmsgqthd查询消息包队列占用率流量控制门限lst

8、 tfrc查询面向 rnc 的基本信道配置算法参数lst fccputhd查询 cpu 占用率流量控制门限rnc 级小区级lst tdpucfgdata查询 dpu 配置数据lst tstatetimer查询呼叫流程状态保护定时器lst fcsw查询流量控制开关lst tpch查询寻呼信道lst tpich查询寻呼指示信道表 3 rnc 配置查询指令具体查询结果可参考以下附件，重点部分已经用黄色标注。rnc寻呼相关软参 .x ls2、实际寻呼次数与端局话统的数据是否有误差在统计指标异常低的情况下， 通常会对用户感知造成较为明显的影响，但是一直未收到用户投诉。 因此判断是否有可能是统计数据存在异

9、常？为了验证具体的统计值是否有异常，我们在端局上定义了15 分钟的统计报告，同时打开了端局 iu 口的信令跟踪，现场安排人员配合测试。注：由于本局3g用户数量较少， 所以打开了 iu 口进行 paging消息的跟踪，如用户量较大需要视实际情况决定是否进行相应操作。我们在开始信令跟踪前发现2g的全网寻呼对 3g的寻呼跟踪有一定影响，便在开始跟踪前关闭了全网寻呼。对象实例开始时间iu 口第一iu 口第一iu 接口重iu 口重复一次寻呼次发次响应复发响应成功率46000d1552011-3-9 16:30761085.71%46000d1562011-3-9 16:3039345287.18%460

10、00d1572011-3-9 16:3031274187.10%46000d1582011-3-9 16:301091090.00%46000d1592011-3-9 16:30431075.00%表 4 9日下午配合信令跟踪统计寻呼次数通过信令跟踪发现在15 分钟内，端局统计到的寻呼次数与信令消息中的数量相同，从而验证了端局统计数据无异常。下面是信令跟踪截图：6 / 126图 3 15 分钟统计报告中相应的寻呼信令3 、无线环境特别恶劣，造成寻呼得不到用户终端的响应寻呼成功率低的问题， 通常在核心网寻呼参数无异常的情况下， 无线环境是最重要的影响因素。 无线网优人员首先检查了该地区的无线网络

11、覆盖情况， 可以排除在无线覆盖方面存在有严重影响寻呼成功率的因素。为了验证网络覆盖情况，我们协调无线优化厂家安排现场测试，并确保在各lac下均进行呼叫测试。结果显示被叫接通率很高， 未出现被叫接通率低的情况，由此我们排除了无线环境特别恶劣造成寻呼得不到用户终端响应的可能性。4、其他可能性本地发现除了一个njgs24端局的 3g寻呼指标较低外，本地的 10 个下挂 rnc 的端局中还有很多的端局有同样的情况。但是覆盖市区的3 个端局的 3g寻呼成功率明显高于其他覆盖乡镇的端局。本地 10 套端局， 4 套采用的 atm对接， 6 套采用 ip 方式接入核心网，均存在指标较差的情况。是否是什么软参

12、设置不一样造成指标出现如此大的差异呢？我们本地的所有端局进行了软件比对，结果显示一致。至此，我们的分析好像陷入了困境。但是，我们在查询统计报告时发现 了一点问题。7 / 127次发次响应发响应呼次数46000d1552011-3-10 11:001000146000d1552011-3-10 11:152000246000d1562011-3-10 11:00343300146000d1562011-3-10 11:15403710246000d1572011-3-10 11:001000146000d1572011-3-10 11:152000246000d1582011-3-10 11:0

13、01000146000d1582011-3-10 11:154200246000d1592011-3-10 11:001000146000d1592011-3-10 11:1520002表 5统计表对象实例开始时间iu 口第一iu 口第一iu 口重复iu 口重复全网寻上表中可以看到， 在进行统计前我们已经将本局的全网寻呼进行了关闭。但是在统计表中确发现了有全网寻呼次数。而且发现了这 5 个 lac的全网寻呼次数相同，业务量小的 d155/d157/d158/d159的一次寻呼次数相同， 且都等于全网寻呼次数。那么，否可以理解为：在 11：00 的这个时段， d155/d157/d158/d15

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

15、钟内确实发现了1 次全网寻呼消息：8 / 128图 4用户数据恢复过程中下发的全网paging消息其 中 只 包 含 了 被 叫 的imsi号 码 ， 给 出 的pagingcause为:terminating-conversational-call。正常情 况下的paging消息 应该会 包含 有被叫的imsi,tmsi ， lai和pagingcause:terminating-low-priority-signalling。具体信令打开如下：图 5 正常 paging消息解析9 / 129那么究竟在什么场景下会出现用户数据丢失，还需要vlr下发 paging消息进行用户数据修复的呢？我们

16、模拟了一种情况，就是 vlr在删除用户数据后， 相关的 purge消息未能正常发送到hlr，导致 hlr中登记信息不准确。我们在端局上进行了验证，首先在端局上使用del ms命令删除 vlr中的被叫用户信息，注意 pruge选项需要选择“否” ，也就是不通知 hlr。图 6在端局中删除用户数据具体指令为： delms: unt=msisdnf, lag=no此; 时进行呼叫该号码，我们在信令消息中获取到了相关信令，验证了我们的分析是正确的。10 / 1210图 7呼叫过程中主叫的setup消息图 8呼叫过程中的paging消息正如前面跟踪到的用于用户数据修复paging消息内容，在 vlr清除

17、用户数据，并且不通知hlr的情况下，用户再次被叫时，原被叫端局就会发全网寻呼。11 / 1211四、处理方法介绍鉴于初步分析的结果，我们判断此问题应该是在所有华为端局下，3g 覆盖用户较少的端局上普遍存在的现象。我们对其他地市的3g寻呼指标也进行了比较：发响应数46000d1642011-3-10 3:003835767046000d1652011-3-10 3:0021697046000d1662011-3-10 3:0010697046000d1672011-3-10 3:0010697046000d1682011-3-10 3:00106970对象实例开始时间iu 口第一次iu 口第一次iu 口重复发全网寻呼次表 6其他地市端局下3g 寻呼指标由表 6 可以看出，在 3 点钟这个时段确实是出现了一次由于用户数据修复而发起的全网寻呼。如果排除这次寻呼，实际的3g寻呼指标是正常的。至此，对于 3g局下寻呼成功率低的问题我们找出了真正的原因。就是在用户量较少的情况下，由于“用户数据修复”发起的全网寻呼次数，