寻呼成功率的分析与提高-贾志刚

无线寻呼成功率专项分析无线寻呼成功率专项分析 寻呼成功率是衡量网络质量的重要指标 也是网络优化工作的重点之一 值得指出的 是寻呼成功率虽然是一项交换统计指标 但是该指标的提高需要通过交换和无线优化的共 同努力 根据以往实战经验和众多成功范例 结合某地移动的实际 从交换和无线优化两 方面共同入手提高现网寻呼成功率 交换方面通过 A 接口寻呼时长信令专项分析确立了现 网寻呼模型及寻呼时间参数的最佳值 修改了交换机隐含关机时长参数 无线方面通过对 交换方面所提供的信令分析结果 寻呼黑洞 进行细致分析 找到了 寻呼黑洞 的成因 并提出了相关调整建议 以期提高全网寻呼成功率 一一 交换侧关于寻呼黑洞的描述交换侧关于寻呼黑洞的描述 交换机对所有的 BSC 的 A 接口进行长时间信令跟踪 对于寻呼无相应的手机 我们 将其 IMSI 或 TMSI 和相应发生时间记入黑名单 当在设定时长 Time Gap5 分钟 内若同 一用户进行某种业务 位置更新 主叫或被叫 我们将此用户所在的小区计入一次 Counter 项加一 我们最后将所有小区作此类统计 那么 Counter 值大且话务量 寻 呼量 Paging Res Number 大的小区便是寻呼黑洞 即 Paging loss rate Counter Pag Res Number Paging loss rate 是一个相对的寻呼不好指示比例 并非寻呼失败率 用户可能会出现被寻呼的时候在某小区 而 5 分钟内进行业务的时候在另一 小区而造成小区误判 为尽量抵消此类情况的负面影响 我们跟踪尽量长的 时间 3 小时 作以统计分析 为避免同一用户短时间进行多次业务 如重复试呼 使统计中所在小区的 Counter 项异常偏大 因此我们设定在 60 秒 Look Back time 内的多次业务 Counter 只计一次 使结果更为客观 小区列表当中存在寻呼失败的小区当中可能的原因如下 一些小区存在覆盖盲区 一些小区存在上行干扰问题 一些小区的上下行不平衡 个别小区存在不同程度的信令信道的拥塞问题 二二 无线侧寻呼成功率的分析无线侧寻呼成功率的分析 2 12 1 无线关于寻呼的统计项描述无线关于寻呼的统计项描述 在无线方面的统计中 关于寻呼的统计项主要有以下几项 Page req from msc 该统计项表明 BSC 从交换处收到的 paging 的数目 其中包括一 次和二次寻呼的寻呼数目 并且包含话音寻呼和短消息的寻呼数目 在同一个 LAC 下的小 区 该统计项的数值相同 Page response 寻呼响应的数目 同样包含了话音寻呼和短消息的寻呼响应数目 Pch Q page Discard 该统计项表明的是在寻呼队列中在寻呼消息发送以前被清除的 寻呼消息的数目 在 MOTO 的系统中 该统计项只有一种情况被触发 那就是由于寻呼队列 排队时间过长 新的寻呼消息到达 造成的寻呼溢出 最后被清除 Access per pch cs 该统计项表明在空中接口上发送的 CS 域的 paging request 的数 目 该数目是经过了空中接口上的压缩 Paging overflow rate paging 消息溢出被清除的比例 2 22 2 交换机发出的寻呼与交换机发出的寻呼与 BSCBSC 收到的寻呼收到的寻呼 通过以上的描述 我们了解了一些 MOTO 无线系统的初步的知识 下面我们就益阳网络 中的寻呼进行分析 我们采集了一段时间内网络中的寻呼数据 早忙时 10 00 11 00 晚忙时 19 00 20 00 同时结合交换方面的数据进行比较 由于本次只对 YYG1 进行了 信令录制 因此我们下面的无线数据也只是 G1 下的 8 个 BSC 数据 交换录制的信令和无线进行比较 8 月 2 日早忙时数据 一次寻呼 131987 交换 二次寻呼 8335 140322 LAC2944744132 LAC2946361477 无线 LAC2955934730 140339 在上表中 我们看到交换侧共进行了 140332 次寻呼 G1 局无线收到的寻呼次数为 140339 次 两者相差 17 次 这是由于我们从交换得到的寻呼数据来自于 OCEAN 的信令 录制 而无线的数据来自于统计 两者之间存在时间上的略微差异 因此寻呼的次数 相差 17 次 从比例上来看 仅为 0 012 从统计学角度来看 也可以认为相同 另外 在上表中提到的数据中 无线和交换全部包括了短消息的寻呼 由于交换 机方面的统计中得不到真正的短信的寻呼次数 而 OCEAN 信令的录制中却能得到准确 的数据 因此从录制的信令中我们可以得到这样的结论如前面在分析中提到的 BSC 收到了交换方面发来的全部的寻呼消息 中间没有丢失 收到了交换方面发来的全部的寻呼消息 中间没有丢失 2 32 3 BSCBSC 收到的寻呼在空中接口消息的发送收到的寻呼在空中接口消息的发送 在 BSC 收到交换发送的寻呼消息后 经过有线传输到达基站 然后再次在空中接口上 发送出去 在整个过程中 可能存在传输的不稳定等造成没有及时的进行发送 但是我们 看到在此过程中 PAGING 消息可以放在寄存器中缓冲 在条件许可后 排队队列中等待 再进行发送 下面我们采集了一周早 晚忙时的寻呼数据进行分析 LACDATETIME PAGE REQ FRO M MSC PAGING OVERFL OW RATE PCH Q PAGE DIS CARD 01 084868400 02 084413200 03 084603800 04 084797800 05 085017400 29447 06 08 早忙时 5048400 01 087840700 02 085099500 03 088452900 04 085117000 05 088541500 29447 06 08 晚忙时 5240700 01 086550000 02 086147700 03 085845700 04 086117100 05 085633900 29463 06 08 早忙时 5646300 01 087403700 02 085578800 03 086823600 04 085615400 29463 05 08 晚忙时 7043000 06 085666600 01 083756600 02 083473000 03 083273200 04 083350900 05 083141700 29559 06 08 早忙时 2982400 01 084139500 02 083118400 03 083688800 04 083141700 05 083864800 29559 06 08 晚忙时 3157400 从上表的数据来看 在 BSC 接收到交换的 PAGING 消息后 传送到 BTS 然后又在空中 接口上发送 没有数据的丢失 也没有由于排队队列过长造成的 paging 消息的溢出 通过 paging 消息压缩比的计算也可以得出上述的结论 另外我们可以按照现网中 PCH 和 AGCH 的配置数据来看 绝大多数 CCCH CONFG 0 BS ag blks res 1 Bs pa mfrms 4 N1 9 1 0 33 2 4 25 3600 80784 按 33 的寻呼效率和 IMSI 寻呼 N2 9 1 0 33 4 4 25 3600 161568 按 33 的寻呼效率和 TMSI 寻呼 以上仅是理论计算的一个 LAC 的寻呼量既理论上的一个 LAC 的承受能力 实际上 一个 LAC 的寻呼效率应该大于 33 而且也不可能是单纯的 IMSI 或 TMSI 寻呼 而是两者 的结合 因此我们也可以从理论上看出 G1 的寻呼消息应该不会过载溢出 综合以上我们可以这样说 BTSBTS 成功收到成功收到 BSCBSC 传送的传送的 pagingpaging 消息 然后又全部的在消息 然后又全部的在 空中接口上进行了发送 在此过程中没有空中接口上进行了发送 在此过程中没有 PCHPCH 信道上的消息溢出 信道上的消息溢出 2 42 4 MSMS 的寻呼消息的接收的寻呼消息的接收 在 BTS 下发 paging 消息后 ms 通过广播信道以及同步等过程后 得到了自己所在的 寻呼组并侦听自己的寻呼消息 然后通过 RACH 信道介入系统并通过系统分配的 SDCCH 信道 回应寻呼消息 在此过程中 一般来说手机的上行方向随时可以介入 RACH 不太可能存在 由于 RACH 的拥塞造成不能介入系统 而在下行的方向上手机通过 AGCH 信道为手机分配 SDCCH 信道 通过以上的分析 我们看到在现网的参数 CCCH CONFG 0 BS ag blks res 1 在 9 个 CCCH 信道中已经为手机保留了 1 个的 AGCH 因此也几乎不可能存在 AGCH 的拥塞 因为即使不保留 AGCH 按照 GSM 的规范 在同时有 PCH 寻呼和 SDCCH 的指派时系统优先进行在 AGCH 上对 SDCCH 信道的指派 如果存在小区短 消息的广播 则必须保留 AGCH 并且 MOTO 系统也没有提供 AGCH 是否过载的统计 在此过程中 比较严重的影响寻呼的就是 SDCCH 的拥塞 以及由于无线环境以及基站 的硬件等问题造成手机没有接受到基站下发的寻呼消息 下面我们就该问题进行分析 LACDATETIME PAGE R EQ FRO M MSC CHAN RE Q PAGE RESPONS E PAGE RE SPONSE Page rec eive suc cess rat e Page retu rn succes s rate Page respon se success rate respons e rate AVE 8 月 1 日 48684393323832480 79 97 44 78 72 8 月 2 日 44132365603538682 84 96 79 80 18 8 月 3 日 46038384333717183 48 96 72 80 74 8 月 4 日 47978393153811081 94 96 94 79 43 8 月 5 50174411213991081 96 97 06 79 54 29447 8 月 6 日 早忙时 50484420844074283 36 96 81 80 70 79 89 8 月 1 日 78407565625441872 14 96 21 69 40 8 月 2 日 50995414963997281 37 96 33 78 38 8 月 3 日 84529755885282389 42 69 88 62 49 8 月 4 日 51170423654108082 79 96 97 80 28 8 月 5 85415605165793270 85 95 73 67 82 29447 8 月 6 日 晚忙时 52407433064153882 63 95 92 79 26 72 94 8 月 1 日 65500587775818489 74 98 99 88 83 8 月 2 日 61477568045613392 40 98 82 91 31 8 月 3 日 58457543005379392 89 99 07 92 02 8 月 4 日 61171568725631792 97 99 02 92 06 8 月 5 56339520675163092 42 99 16 91 64 29463 8 月 6 日 早忙时 56463519665145992 04 99 02 91 14 91 17 8 月 1 日 74037674766681491 14 99 02 90 24 8 月 2 日 55788505605000690 63 98 90 89 64 8 月 3 日 68236625366188691 65 98 96 90 69 8 月 4 日 56154508095026890 48 98 94 89 52 8 月 5 70430644306372291 48 98 90 90 48 29463 8 月 6 日 晚忙时 56666512875068290 51 98 82 89 44 90 00 8 月 1 日 37566339813346390 46 98 48 89 08 8 月 2 日 34730317173130691 32 98 70 90 14 8 月 3 日 32732301372977292 07 98 79 90 96 29559 8 月 4 日 早忙时 33509311283076192 89 98 82 91 80 90 23 其中 CHAN REQ PAGE RESPONSE 统计项为手机成功的在 RACH 上申请 SD 信道做被叫的比 例 含短信 我们定义了两个统计项 Page receive success rate CHAN REQ PAGE RESPONSE PAGE REQ FROM MSC Page return success rate PAGE RESPONSE CHAN REQ PAGE RESPONSE 前一个 paging 接收率 可以表征手机能接收到的 paging 消息的比例 后一个 paging 返回率 表征手机在 SD 信道上返回 paging response 消息的比例 我们看到 LAC29447 的寻呼成功率都是相对的较低 在早 晚忙时的寻呼成功率 含短 信 均是在 80 以下 这与我们掌握的其它地方的数据来看 大概低了 5 个百分点左右 另外 通过以上的对比发现 寻呼接收率上 LAC29447 平均 80 寻呼返回率为 96 6 3 日晚忙时异常由于八子哨基站故障引起 与其它两个 LAC 相比分别低了 10 和 2 这可能与 LAC29447 覆盖区域电平较差 并且与其它多个 LAC 产生交接 交界面大 有较大关系 从寻呼接收率上我们可以得到结论 29447 的寻呼成功率低是由于寻呼接收率低导致 的 而寻呼接收率低最大可能的问题是由于覆盖较差 根据以上分析的问题和交换提供的寻呼黑洞结果 我们具体分析如下 SDCCHSDCCH 信道的拥塞信道的拥塞 在交换提供的寻呼黑洞小区中 29447 53250 小区的 2 日早忙时 3 个小时 寻呼数 118 次 寻呼失败数 8 次 失败率 6 78 通过我们的观察 该小区存在较大的 SDCCH 拥塞 可能是造成寻呼失败的一个主要原因 Device NameDate AVAILA BLE SD CCH MA X AVAILABL E TCH MA X BUSY S DCCH M AX BUSY T CH MAX LOCATI ON UPD ATE SDCCH BLOCKI NG RAT E SDCCH TRAFFI C CARR IED TCH BL OCKING RATE TCH TR AFFIC CARRIE D 53250 8 月 1 日 241124812016 411 9702 24 8 月 2 日 241124592841 681 501 06 8 月 5 31417286622819591 23 98 37 89 74 8 月 6 日 29824271232673290 94 98 56 89 63 8 月 1 日 41395371623661289 77 98 52 88 45 8 月 2 日 31184282482778590 58 98 36 89 10 8 月 3 日 36888336693314691 27 98 45 89 86 8 月 4 日 31417287722832191 58 98 43 90 15 8 月 5 38648343843376888 97 98 21 87 37 29559 8 月 6 日 晚忙时 31574282542742589 49 97 07 86 86 88 63 8 月 3 日 3210321212315 932 0201 89 8 月 4 日 3210321084410 581 240 742 48 8 月 5 日 321032129603 111 4502 8 月 6 日 3210321013075 352 2102 33 8 月 7 日 3210321288713 111 3301 29 通过该小区的地理位置 我们发现 该小区在益阳界内 但是由于处于其它 LAC 区的 包围之中 因此 SDCCH 主要用于位置更新 拥塞也由此产生 同时由于频繁的位置更新也 造成了手机未能正常的回应寻呼消息 这种现象是由于 LAC 的划分不合理造成的 通过小区数据库的检查发现 目前该小区的 CRH 参数已经为 7 CRO 参数为 0 因此只 能通过增加 SDCCH 信道 降低 SDCCH 的拥塞 因为 TCH 几乎不拥塞 需要修改载频中的 sd load 参数 在在 LACLAC 区边缘造成的手机未能响应区边缘造成的手机未能响应 在交换提供的一些寻呼黑洞的列表中 还有一些小区 它们处在 LAC 的边缘 它们的 基站硬件不存在问题 同时 SD 的介入成功率也在正常的范围内 因此这些小区可能是由于 频繁的位置更新造成不能响应寻呼 LacCI Lost Pagi ngs PagResNumbe r LostRa te SD access f ail ratereason 2946353872202248 93 13 01 LAC 边缘 覆盖较差 2946353873485588 60 4 09 LAC 边缘 29559280729012337 30 3 79 LAC 边缘 2955928071172965 74 2 8 LAC 边缘 2946333143274196 44 6 5 LAC 边缘 2946333142376575 63 1 9 LAC 边缘 如上图所示 交换提供的这些小区处在 LAC 的边界地带 有的甚至进入到了其它 LAC 的内部 造成位置更新较多 很容易造成寻呼的未能正确响应 53872 所在的基站明显的 由于 LAC 的分布不合理造成 因此建议以后的工程中割接该基站到 BSC603 LAC29559 覆盖不好造成的未能正确接收寻呼覆盖不好造成的未能正确接收寻呼 另外 我们看到 在交换提供的寻呼黑洞列表中 还有一些小区 它们的 SD 和 TCH 介 入失败率比较高 并且几个基站相对集中的在一起 因此这些基站小区在一定的程度上存 在一定的相关性 我们把它们覆盖的交叉地区称为真正的 黑洞 地区 一般来说 这些 交叉的区域覆盖较差 这样就为我们以后的工作提供了一个指导思路 这些 黑洞 地区 成为以后覆盖调整以及基站增加的重点地区 28071 33143 53872 在这里我们提到的是 SD 的介入失败率 我们通过 MOTO 提供的统计项 chan req ms fail roll 与 alloc sdcch 的比值来定义为 SD 的介入失败率 它表明了在系 统成功的分配了 SDCCH 信道后 手机未能成功占用的比例 可能造成的原因有覆盖较差 干扰 硬件问题以及定时器的超时 因此 在排除了一些其它的问题后 我们可以把该统 计项比值看作覆盖率的一个表征 LacCILost PagingsPagResNumberLostRateSD access fail rate 2944718783688847 69 18 22 29447340126612265 38 8 32 2944734011629176 76 5 82 29447181433825041 52 5 93 2944733210146962 01 10 34 2944728173157272 06 7 71 29447281722211031 99 4 19 上表中的黄色部分为交换提供的寻呼黑洞较差小区 8 0 KM LacCI Lost Pag ings PagR esNu mberLostRate SD acces s fail r atereason 2944733271508715 74 8 2 覆盖较差 SD 介入失败率较高 29447332732120410 29 15 63 RTF2 1 所对应载频的 BER 较大 SD 介入失败率非常高 覆盖较差 2944733272111567 05 0 28 话务量小 处于边界 从上图来看 这些小区集中覆盖的地区的 paging 成功率较低 因此 交叉地带的 黑 洞 存在 需要在以后的工作中增强信号覆盖 2 52 5 BTSBTS 的寻呼响应消息的接收的寻呼响应消息的接收 在手机正确接收了 paging 消息后 它会在 SDCCH 信道上以 paging response 的消息响 应寻呼 BTS 接受后传送给 BSC 然后再上传至 MSC 一次寻呼完成 在这个过程中 可能 存在一些异常的情况导致手机未能正确的响应 paging 同时还会造成 BTS 不能及时的接收 手机发送的 paging response 消息 7 9KM 7 0KM 7 1KM 7 6KM 定时器超时定时器超时 在 BTS 成功的为手机分配了 SDCCH 信道后 它会启动一个定时器 RR T3101 以监视手机 成功占用 SDCCH 的情况 如果在 T3101 到时时 手机仍未返回正确的 page response 消息 系统便会进行拆线 收回分配的信道资源 我们通过检查益阳现网的小区数据库发现 现网中绝大多数的 3101 定时器设置为 1500 1 5 秒 应该说这个时长基本上正常 在覆盖较好的市区 1 5 秒内手机应该可以 返回响应 paging 的消息 但是在覆盖较查的山区 3101 的设置则显得稍短 对于手机的 反应时间应该增长 因此建议对山区 尤其是 G1 的 LAC29447 所属的小区 RR T3101 的值 设置为 2000 2 秒 以延长手机的响应等待时长 上行干扰严重上行干扰严重 在系统成功的分配了 SDCCH 信道后 手机去占用该信道 在此过程中 由于存在较强的 干扰 导致手机未能成功的占用 或者即使手机已经成功的占用了 SDCCH 信道 但是由于 干扰过于强大 系统未能准确的接收到返回的 page response 消息 对应以这种现象的是 BCCH 载频的干扰较大或有 SDCCH 信道的载频干扰较大 在交换提交的寻呼黑洞列表中存在这样的小区 LacCILost PagingsPagResNumberLostRateSD access fail 2944728151133014 32 39 56 无线检查的结果 Device NameDate PATH BALA NCE MEAN RF LOSSES T CH TOTAL ber me an chan req ms failioi mean 28151 RTF 00 0001 08 110 5110 1700 17 02 08 112 0330 0700 02 03 08 113 0700 0800 01 04 08 109 6420 0900 02 05 08 111 0220 1200 02 06 08 108 9700 1400 28151 RTF 00 0101 08 106 4300 815838 49 02 08 105 1500 22122915 72 03 08 107 0600 745427 73 04 08 106 0110 532360 98 05 08 104 2700 492903 96 06 08 106 6100 762552 37 28151 RTF 00 0201 08 106 0320 4803 44 02 08 105 6120 1900 27 03 08 00009 74 04 08 000021 83 05 08 000017 44 06 08 000021 94 28151 RTF 00 0301 08 108 0200 6100 33 02 08 108 9500 3200 16 03 08 11300 2900 18 04 08 105 0600 3400 58 05 08 114 5100 7200 14 06 08 108 400 0600 37 在如上表的检查中 我们发现的 28151 小区的 RTF0 1 载频上行干扰 IOI 过大 我们 定义的 IOI 为一个载频 8 个时隙的平均值 而且 SDCCH 信道正好又配置在该载频 当干 扰过大时造成手机未能成功的占用 也造成系统的未能准确及时的接受响应消息 结合 RTF0 2 的 IOI 同样较大的现象 因此建议开启该小区的跳频同时注意观察后续的效果 然 后再进行相应的频率调整或干扰的查找排除 载频硬件存在问题载频硬件存在问题 显然载频硬件等存在问题会造成手机和系统不能正确的接收对方的消息 同时容易造 成 SDCCH 的掉话 导致寻呼的失败 在交换提交的寻呼黑洞列表中也存在这样的小区 LacCILost PagingsPagResNumberLostRateSD access fail 294473317381375 84 25 55 无线检查的结果 Device NameDate PATH BALANC E MEAN RF LOSSES T CH TOTAL ber me an chan req ms fail ioi mea n 33173 RTF 02 00 8 月 2 日 120 8410 31810 02 8 月 3 日 119 6810 261900 01 8 月 4 日 121 410 171760 01 8 月 5 日 124 5110 263020 01 8 月 6 日 122 2910 221520 01 33173 RTF 02 01 8 月 2 日 123 5900 2800 8 月 3 日 121 9920 1200 8 月 4 日 124 0400 3100 8 月 5 日 120 7901 5500 8 月 6 日 118 8700 100 33173 RTF 02 02 8 月 2 日 119 8200 200 8 月 3 日 115 5700 0600 8 月 4 日 118 4100 1800 8 月 5 日 120 3400 6800 8 月 6 日 119 5700 0700 33173 RTF 02 03 8 月 2 日