寻呼成功率专题报告.docx

1、寻呼成功率专题报告鄂尔多斯移动寻呼优化专题报告鄂尔多斯网络优化项目组2007年10月31日目 录一、概述 1二、专题分析 12.1寻呼指标分析： 12.2寻呼统计点分析： 22.2.1 第一次发寻呼次数： 22.2.2 第一次寻呼响应次数： 22.2.3重复发寻呼次数： 22.2.4 重复寻呼响应次数： 32.3触发寻呼的原因； 32.4寻呼成功率的分析 32.4.1 寻呼成功率低原因： 32.4.2 常用话务统计： 42.5寻呼参数设置策略 42.5.1 基本参数设置策略； 42.5.2 T3212以及IMSI隐式分离时间的设置 42.5.3 用IMSI或者TMSI进行寻呼 52.6寻呼方面

2、常见问题 52.6.1 寻呼时长的设置 52.6.2 RACH最小接入电平的设置 62.6.3 隐含关机时间的设置 72.6.4 MS最大重发次数 72.6.4 SDCCH指配问题 7三、典型案例 83.1鄂尔多斯寻呼问题分析 83.1.1 关于不同MSC同时出现两个相同LAC的问题分析 8 问题背景 8 问题描述 8 问题分析 9 优化调整 11 优化效果 113.1.2 从寻呼黑洞小区的角度来提高寻呼成功率 13 问题背景 13 问题描述 13 问题分析 14 优化调整 14 优化效果 143.1.3 从位置更新的角度来提高寻呼成功率 15 问题背景 15 问题描述 15 问题分析 17

3、优化调整 18 优化效果 18四、总 结 19一、概述寻呼成功率考核各地无线覆盖情况、网络运行维护优化的质量等。这项指标的高低反映网络的覆盖规模，网络覆盖本质上是无线的问题，应归于基站的密度、发射接收功率的设置等。通常，每期工程的顺利完成寻呼成功率就会有所提高，而且这个提高幅度同工程的规模成正比。网络优化的目的是尽可能使得寻呼成功率达到工程设计应该达到的水平。那么这项反映网络覆盖的指标如何优化呢？BSS当然是这项指标的理想跟踪对象，可以将大的系统指标分解到各个小区来定点分析，通过对各个小区或基站的障碍清除、参数调整、高度调整及俯仰角变换等等手段来达到无线的最佳覆盖，从而优化寻呼成功率。其次在N

4、SS一边也有一些优化手段可以提高这项指标。二、专题分析2.1寻呼指标分析： 寻呼成功率定义：寻呼成功率=寻呼响应次数/寻呼请求次数*100%；寻呼响应次数：指本地区所有MSC收到的PAGING RES消息的响应总和。包括重复寻呼的响应。统计点为MSC。寻呼请求次数：定义：指本地区所有MSC发出的首次PAGING消息（不包括重复寻呼）的总和，统计点为MSC。 寻呼成功率话务统计：在MSC基本业务测量中，定义寻呼过程测量任务，在此任务中，有如下测量指标：测量指标含义测量点A接口第一次发寻呼次数每次呼叫时向A接口第一次发PAGING消息的次数MSC向BSC发 PAGING 消息时统计A接口第一次寻呼

5、响应次数向A接口第一次PAGING消息发出后，成功收到响应的次数MSC向BSC发送的第一次PAGING消息发出后，MSC收到被叫发的PAGING RESPONSE消息时统计A接口重复发寻呼次数每次呼叫时MSC向A接口非第一次发PAGING消息的次数MSC 向BSC非第一次发BSSMAP PAGING消息时统计A接口重复寻呼响应次数每次呼叫向A接口非第一次PAGING消息发出后，成功收到MT响应的次数MSC向BSC非第一次PAGING消息发出后，MSC收到被叫发的PAGING RESPONSE消息时统计根据寻呼成功率的定义，在交换机上统计的指标即为：（A接口第一次寻呼响应次数A接口重复寻呼响应次

6、数）/ A接口第一次发寻呼次数。2.2寻呼统计点分析：2.2.1 第一次发寻呼次数： 当每次呼叫，MS被成功查询到后，返回漫游号码的同时，被叫所在交换机就会向用户当前所在的BSC第一次下发寻呼消息，此时统计为第一次发寻呼消息。2.2.2 第一次寻呼响应次数： MSC向BSC发送的第一次PAGING消息发出后，MSC收到被叫发的PAGING RESPONSE消息时统计，在PAGING消息下发后，直到收到寻呼响应消息，均是在SDCCH上进行的，因此保持SDCCH的指配成功率至关重要。2.2.3重复发寻呼次数： MSC 向BSC非第一次发BSSMAP PAGING消息时统计。此项统计源于各个地方的交

7、换机的寻呼策略各不相同，一般情况下，均设置为多次寻呼，即：当第一次寻呼下发后，收不到针对此次寻呼的响应，那么则根据设置的策略，进行第二次寻呼下发，以此类推。由此我们可以知道，出现了重复的寻呼下发次数，是由于上次的寻呼超时导致。2.2.4 重复寻呼响应次数： MSC向BSC非第一次PAGING消息发出后，MSC收到被叫发的PAGING RESPONSE消息时，即为收到了重复寻呼响应。该统计只有在交换机设置了多次寻呼策略后，才会出现。2.3触发寻呼的原因； 当一个端局MSC收到它局发送的IAI消息后，为了确定被叫用户是否能够接受此次呼叫，MSC会首先向相应的VLR查询有关该被叫用户的用户信息，如果

8、VLR通过查询用户信息，发现该用户可以接受此次呼叫(未关机且允许接受呼叫)，会向MSC发送寻呼命令消息，在该消息中，含有用户的位置信息（LAI），MSC收到此信息后，查询数据，得到控制此位置区的BSC的信令点编码，向相应的BSC下发寻呼命令，BSC通知所控制的BTS在寻呼信道（PCH）下发寻呼消息。手机一直在侦听该信道，当收到寻呼自身的消息后，在随机接入信道（RACH）上报寻呼响应消息。2.4寻呼成功率的分析2.4.1 寻呼成功率低原因：寻呼成功率的高低直接影响着手机做被叫的接通率，同时也影响着用户的感知，影响寻呼成功率的因素有许多种： 无线因素1、 基站覆盖情况；2、 SDCCH是否拥塞；3

9、、 位置区划分的合理性、上下行不平衡基站的情况等； 影响指标的参数4、 T3212，CRH；5、 IMSI隐式分离时间；6、 RACH最小接入电平；7、 MS最大重发次数；8、 接入允许保留块数；9、 寻呼时长的设置； 数据的规范性10、 小区CGI数据的准确性；11、 相邻的MSC是否存在相同的LAC数据；12、 冗余数据的清理；2.4.2 常用话务统计： 寻呼过程测量此测量中包括：13、 第一次发寻呼次数；14、 第一次寻呼响应次数；15、 重复寻呼响应次数；可以将此任务定义成按照LAC进行的统计，这样就可以看的具体哪的位置区的指标较差，从而可以有针对性的进行优化。2.5寻呼参数设置策略2

10、.5.1 基本参数设置策略； 对寻呼设置策略的制定应从如下几个方面来进行：16、 针对寻呼时长的设置，可以通过跟踪信令统计出各次寻呼的时长，进而据此设置每次寻呼的时间长度；17、 针对寻呼次数的设置，一般可以设置为2到3次寻呼，以保证在第一次寻呼超时无响应的情况下，进行多次寻呼；18、 针对位置区边缘的小区，统计中如果发现存在频繁位置更新的情况，会一定程度上影响寻呼，可以根据具体情况适当设置小区重选滞后参数；2.5.2 T3212以及IMSI隐式分离时间的设置对于周期性位置更新时间来说，设置的越小越好，但是会带来网络的负荷，可以根据当地的实际情况来设置，一般建议设置为4070分钟；IMSI隐式

11、分离时间是同T3212相配合设置的计时器，由于网络做不到无缝隙覆盖，手机自然会有脱网的情况发生，或者由于网络覆盖、系统故障等问题造成手机正常关机消息不能送到VLR，这些实际情况会导致VLR不能及时将用户状态反映出来，克服这个问题方法是缩短系统诊断开机变关机的时间隐含关机定时器，隐含关机定时器超时没有收到用户的周期性位置更新请求，MSC会将用户的状态置为关机。2.5.3 用IMSI或者TMSI进行寻呼以TMSI寻呼可提高安全性，还可以增大无线信道上的寻呼合并比（提高PCH的利用率），对于这种情况一般是先用TMSI进行寻呼，最后一次使用IMSI进行寻呼。另外以IMSI寻呼还可解决个别用户TMSI临

12、时出错的情况。寻呼必须有IMSI，利用TMSI寻呼也必须携带IMSI，TMSI寻呼并不是减少寻呼数量，而是节约资源。2.6寻呼方面常见问题2.6.1 寻呼时长的设置 寻呼时长是在寻呼消息下发后，等待寻呼响应的时间，如果MSC设置为多次寻呼，那么当第一次寻呼在设置的时长内没有收到响应，则进行第二次寻呼消息下发。下面我们来看一个具体的寻呼时长的例子：上图是根据某个BSC的信令，分析得出的第一次寻呼的时间分布，横坐标单位是毫秒，纵坐标是寻呼响应出现的次数，可以看出该BSC的第一次寻呼响应基本在3秒之内就能被MSC收到，那么根据这个统计，我们可以将第一次寻呼的时间设置为3秒即可。上图是根据某个BSC的

13、信令，在第一次寻呼的基础上，分析得出的寻呼响应后的时间分布，横坐标单位是毫秒，纵坐标是寻呼响应出现的次数，可以看出该BSC在第一次寻呼响应后，还出现了后续的响应，从上图中，我们可以看出从5秒到12秒均有次数不等的寻呼响应上报。根据这个分析，我们可以将寻呼设置为3次，第一次时间为3秒，第二次时间为4秒，第三次时间为4秒，这样一来可以确保将前11秒内的寻呼响应收到，而从图中可以看到，绝大部分的响应均在前11秒之内，这样的设置对于寻呼是非常有好处的。 对位置区容量较大的位置区，建议寻呼重发次数不能太大，且寻呼重发间隔不能太短。原因是这样做容易造成基站过载和BSC CPU过载，导致大量的寻呼消息被丢弃

14、，从而造成寻呼成功率的下降。另外，如果寻呼重发间隔设置太短，则在所指定的寻呼次数内还没有收到寻呼响应，MSC就认为寻呼失败并清除寻呼信息。之后，即使寻呼响应又上来，但由于寻呼信息已清除，则MSC会通过CLEAR_COMMAND拆除被叫侧无线信道。寻呼间隔设置时间太长将导致主叫用户听不到Paging Time Out录音通知（播放用户不在服务区的录音通知），时间太短将不能收到手机终端的寻呼响应。寻呼时间间隔必须和BSS侧的寻呼响应时间配合合理，才能提高寻呼成功率。2.6.2 RACH最小接入电平的设置 参数“RACH最小接入电平”设置越小，对提高寻呼成功率越有利。由于影响寻呼成功率和掉话率的网优

15、参数是互相制约的，通过降低“RACH 最小接入电平”可以提高寻呼成功率，但会造成掉话率增加。这个参数的设置可以从N侧和B侧同时入手，找到一个平衡点，最终达到在提高寻呼成功率的同时有不至于使掉话太恶化。2.6.3 隐含关机时间的设置 寻呼成功率低的原因有多种，从参数的角度来看，隐含关机时间的设置会一定程度上影响寻呼成功率，如果交换侧隐含关机时间的设置是周期性位置更新时间T3212的2到3倍，或者比T3212多出几十分钟，那么会一定程度上影响寻呼成功率指标。一般情况下，隐含关机时间比T3212高出10分钟到15分钟即可，影响负荷的因素只是T3212的设置会起作用，隐含关机时间只是对那些进入盲区的极

16、少量用户起作用，因此在不发生过载的情况下，应该尽量减小隐含关机的时间设置。2.6.4 MS最大重发次数 参数“MS最大重发次数”表示MS在同一次立即指配进程中允许发送Channel Request消息次数的上限。参数设置值越大，试呼的成功率越高，接通率越高，但同时RACH信道的负荷也越大。参数“MS最大重发次数”缺省值为4次，为了提高“寻呼成功率”，可以设置该参数为7次，但要密切关注RACH信道的负荷。 【注】 MS最大重发次数 表示允许手机在收到立即指配消息前重新发送的信道请求消息的个数，即手机可以发送的信道请求个数为M1。它是2比特编码，范围03对应的最大重发次数为1、2、4、7次。增大该

17、参数即允许手机收到寻呼后多次进行信道请求次数来响应寻呼，适用于无线环境较差的情况下使用。2.6.4 SDCCH指配问题 因为寻呼消息的下发是利用的SDCCH，因此SDCCH能否成功地分配至关重要。由于拥塞导致占不上SDCCH是影响寻呼成功率的一个主要原因，此外SDCCH上的掉话也是一个重要的因素。三、典型案例3.1鄂尔多斯寻呼问题分析3.1.1 关于不同MSC同时出现两个相同LAC的问题分析 问题背景针对寻呼指标，我们从统计观察了现网各个MSC下各个LAC的寻呼情况，发现MSC1、MSC2下同时存在LAC=4772的位置区。 问题描述位置区4772同时存在于MSC1、MSC2中，而且此位置区的

18、寻呼指标很差，严重影响了寻呼的总体指标。我们认为同一个位置区同时存在于两个不同的MSC中，这种数据配置是极其不合理的，提取的话务统计如下：归属MSC位置区统计时间A接口第一次发寻呼次数A接口第一次寻呼响应次数A接口重复发寻呼次数A接口重复寻呼响应次数本位置区寻呼总体指标MSC1位置区号: 4600047722007-8-5 9:00325114426242145.00%52.35%位置区号: 4600047722007-8-5 10:00305712685592842.39%位置区号: 4600047722007-8-5 11:00256610854632643.30%位置区号: 460004

19、7722007-8-5 19:00113886361182711056.82%位置区号: 4600047722007-8-5 20:0010165537915446053.51%位置区号: 4600047722007-8-5 21:00667535998374454.58%位置区号: 4600047722007-8-6 9:009089512112977457.16%51.41%位置区号: 4600047722007-8-6 10:0098545195152112353.97%位置区号: 4600047722007-8-6 11:008532418812468550.08%位置区号: 4600

20、047722007-8-6 19:006950330210894448.14%位置区号: 4600047722007-8-6 20:00621527859674845.58%位置区号: 4600047722007-8-6 21:00476623507192849.90%MSC2位置区号: 4600047722007-8-5 8:003531728760647946782.76%78.78%位置区号: 4600047722007-8-5 9:004193234135770963282.91%位置区号: 4600047722007-8-5 10:004181833207850961280.87%位

21、置区号: 4600047722007-8-5 18:0042212314771062861476.02%位置区号: 4600047722007-8-5 19:0042936310621179565173.86%位置区号: 4600047722007-8-5 20:0044654337581074467877.12%位置区号: 4600047722007-8-6 8:003710428487855850678.14%74.35%位置区号: 4600047722007-8-6 9:0045738336851190164775.06%位置区号: 4600047722007-8-6 10:005348

22、1348291856072366.48%位置区号: 4600047722007-8-6 18:0048086352541272269974.77%位置区号: 4600047722007-8-6 19:0044336336211059069377.40%位置区号: 4600047722007-8-6 20:0044647334501108067276.43%从统计中，我们不难发现，位置区4772在MSC1的统计中，每小时寻呼成功率大约为50左右，在MSC2的统计中每小时寻呼成功率早忙时为80左右，晚忙时为75左右。 问题分析 寻呼的过程首先我们先来看一下寻呼的流程HUAWEI的MSC/BSC/B

23、TS寻呼过程配合分析图上面是寻呼的流程，寻呼是针对某一位置区进行的，那么在发起寻呼之前的流程是什么样的呢？我们先来看一下。当主叫MS1拨打被叫MS2时，主叫侧MSC/VLR将通过被叫号码等信息寻址，最终查询被叫所归属的HLR，HLR在其数据库中将查询到被叫所在的当前MSC/VLR的MSCID号，并据此找到被叫当前登记的MSC/VLR，由此建立主被叫MSC的链接；而被叫是通过位置更新来登记到当前所在的VMSC/VLR上的，并会将当前的位置信息、当前登记的MSCID等信息通知其所归属的HLR，供其做被叫查询。当被叫所在的当前MSC收到来自HLR的分配漫游号请求后，将会给其回复一个漫游号码，由此建立

24、与主叫MSC的连接，接着被叫MSC将会对MS所属的LAC下发寻呼消息，在收到被叫寻呼响应后，将进行资源信道的分配，随后将进行通话的流程。 可能导致的风险鄂尔多斯网络当前共分为14个LAC，14个BSC，4个交换机，经过我们检查，发现了在EDSG1和EDSG2下同时出现了4772的位置区，此位置区在EDSG1下归属于BSC8，在EDSG2下归属于BSC1，而且这些同位置区的基站均相隔不远，下面我们来分析一下这种数据规划可能导致的风险。为了方便理解，我们画了示意图，如下：假设某用户通过位置更新在MSC2下BSC1的A小区登记，位置区为4772，那么用户将会将此位置上报其归属HLR，HLR就会确定其

25、当前所在位置是MSC2；如果此用户在未做任何动作的情况下，运动到MSC1下BSC8的B小区，而根据当前的数据规划，这两个小区的位置区同为4772，那么手机就不会做跨LAC的位置更新（前提是在手机还没有到周期性位置更新的时间内），此时虽然用户已经在MSC1的覆盖范围内，但由于用户位做任何动作，那么MSC2仍旧会认为用户还是在其下的A小区，未发生位置的变化；而与此同时MSC1也同样不会认为用户已经在它的下面登记，这样就会导致用户虽然占用的是MSC1的信号，但其位置信息还是处在MSC2下。如果在此时有用户在拨打这个位置出现错误的手机，会出现什么情况呢？根据上面我们分析的手机做被叫时的过程，那么我们可

26、以知道，HLR会查询到用户当前的位置是在MSC2下，MSC2会对其所控制的4772位置区的部分进行寻呼，而手机并未在MSC2下的4772位置区内，而是在MSC1下的4772位置区内，所以主叫用户就会听到“用户不在服务区”或者“无法接通”的录音通知。这就会导致可能会存在某些用户虽然开机却无法接通，并会导致用户的投诉。我们于8月7日进行了实地模拟测试，用的就是上面提到的步骤，听到的确实是无法接通的录音通知。 优化调整对于此类情况，我们建议进行如下数据规划： 将BSC8下的归属于4772位置区的基站割接到BSC1下的4772位置区内，同时修改交换侧数据； 将BSC1下的归属于4772位置区的基站割接

27、到BSC8下的4772位置区内，同时修改交换侧数据； 对于上面两条建议，我们认为还是将基站数量少的一方割接到基站数量多的一方，这样可以减少数据的修改，同时也可以照顾到大多数用户的感知； 优化效果经过数据上的修改，我们在随后提取的话务统计中与修改前的进行了对比，效果明显：归属MSC位置区统计时间A接口第一次发寻呼次数A接口第一次寻呼响应次数A接口重复发寻呼次数A接口重复寻呼响应次数本位置区寻呼总体指标修改数据前MSC1位置区4600047722007-8-5 9:00325114426242145.00%52.35%位置区4600047722007-8-5 10:0030571268559284

28、2.39%位置区4600047722007-8-5 11:00256610854632643.30%位置区4600047722007-8-5 19:00113886361182711056.82%位置区4600047722007-8-5 20:0010165537915446053.51%位置区4600047722007-8-5 21:00667535998374454.58%位置区4600047722007-8-6 9:009089512112977457.16%51.41%位置区4600047722007-8-6 10:0098545195152112353.97%位置区460004772

29、2007-8-6 11:008532418812468550.08%位置区4600047722007-8-6 19:006950330210894448.14%位置区4600047722007-8-6 20:00621527859674845.58%位置区4600047722007-8-6 21:00476623507192849.90%MSC2位置区4600047722007-8-5 8:003531728760647946782.76%78.78%位置区4600047722007-8-5 9:004193234135770963282.91%位置区4600047722007-8-5 10:004181833207850961280.87%位置区4600047722007-8-5 18:0042212314771062861476.02%位置区4600047722007-8-5 19:0042936310621179565173.86%位置区4600047722007-8-5 20:0044654337581074467877.12%位置区4600047722007-8-6 8:0037104