NOKIA统计数据分析及系统优化.doc

nokia统计数据分析及系统优化目录目录2第一章概 述41.1nokia网络优化流程41.1.1数据收集整理41.1.2优化实施41.1.3系统微调和总结51.2 nokia网络优化配置51.3优化周期5第二章 kpi指标及优化62.1tch掉话率7211 rf掉话7212 abis掉话7213 tr掉话7214 aif掉话8215 lapd掉话8216 bts fail掉话8217 切换掉话82.2话务掉话比92.3 无线接通率102.4 最差小区比例112.5 sd掉话率12第三章告警收集及处理143.1bsc告警143.2bts告警14第四章 网络安全分析164.1 trx负荷分析174.2 话务负荷分析184.2.1 网络话务负荷184.2.2 bsc话务负荷224.3 bcsu负荷244.4 寻呼负荷29第五章 优化发展和延伸305.1 优化深入发展315.1.1 优化转型315.1.2 优化工具315.1.3 优化深入发展325.2 优化全面延伸335.2.1 直放站和室内分布系统335.2.2传输设备部分335.2.3 交换部分39附录一omcr统计数据40附录二参数简要描述（第五分册nokia部分）41第一章概 述东信网络从事移动通信系统的网络优化，已经有多年经验，2004年之前主要从事moto系统的工程建设及网络规划优化，从2004年3月介入上海联通网络优化试点开始，东信网络优化跨入nokia优化逐渐发展时期。从全国范围来看，nokia系统的优化尚处于起步阶段，主要原因归结于nokia公司的技术保密及技术分割，对于东信网络这个拥有丰富优化经验及中层人员储备的公司，2005年之后开始是个极大的机会。本文试图将本人这几年做moto系统和nokia系统的经验及知识加以整理，希望能够为今后的nokia系统gsm网络优化做参考。另外本文中涉及系统部分的，gsm系统共通的，就不再赘述，会一笔带过，如系统初学者，请先参考公司其他优化文档，如系统优化等。1.1nokia网络优化流程 优化的流程对于每个系统都是类似的，可以将网络优化过程大致分为三个阶段：1. 数据收集整理2. 优化实施3系统微调和总结1.1.1数据收集整理本阶段的主要内容包括：1.cm数据收集整理（包含基站物理信息及系统参数设置等信息），来源omcpar.mdb或者omcpar.dat自行转换，物理信息可以由用户处直接取得。2.pm数据采集分析，也就是通常所说的omc统计数据分析，来源d1、q1、h1、trxq1及cell doctor等，也可自行编写sql语言采集。3.告警数据采集整理，整理网络中各级网元告警，来源各bsc告警命令执行。4. dt及cqt测试分析，通过网络普查和问题点定点测试手段，提高用户感知度。 根据以上数据收集整理及分析，及时提出解决方案，有计划有步骤实施。1.1.2优化实施本阶段根据优化方案，主要通过采取：参数修改；告警排障；硬件检查；天馈调整；频率规划；干扰排除等手段达到优化的目的，各系统分析方法是类似的，不再详述。1.1.3系统微调和总结通过集中优化，系统将运行在较良好且稳定的状态，此时进入系统微调和总结阶段。本阶段对于网络的各项参数不再进行大的调整，主要工作在于处理突发的指标恶化或者故障，整理集中优化阶段的资料及日志文件，对项目进行总结。1.2 nokia网络优化配置 主要分为人员配置和设备配置，设备配置和其他系统一样。只是人员的配置上，由于nokia培训人员的独立性，一般来说优化系统工程师和bsc工程师是不同的概念，并且bsc工程师和bts工程师知识层面上也泾渭分明，而在moto系统中有些优化系统工程师可以兼任bsc工程师，大部分bsc工程师可以兼任bts工程师。所以一个严谨的nokia系统优化配置是必需bsc工程师、bts工程师和优化系统工程师的，视各地不同需求可以进行适当的调整。1.3优化周期优化周期完全受合同约束。第二章 kpi指标及优化各地优化的目标就是kpi能够等到提升，而当中最关心的可能是掉话率，无线接通率和最差小区比等，这些在各种系统中都是基本一致的，但是统计中稍有不同之处在此有所介绍，本章主要讨论以下内容:tch掉话率话务掉话比无线接通率最差小区比例sd掉话率 在nokia系统中基本所有的无线统计项都产生在bsc，所以不可避免的包含了固定链路的部分掉话等，这些在moto系统中都是作为分配失败来统计的，因为moto的考核的掉话基本都来自bts级的统计。也就是说在掉话统计上，nokia系统的掉话率会高于moto系统的掉话率，包括tch掉话率和sd掉话率。2.1tch掉话率 tch掉话率是各个运营商都非常关心的指标，直接关系到他们自身网优部门的考核，所以往往网优项目中，这个指标是最关键的。但是gsm网络发展到现在，中国移动已经开始12期工程建设，部分联通也进入12期规划中，可以说多年的工程优化、厂家优化和第三方优化已经使得渐趋完善的网络很难挖掘掉话率方面的提升潜力，传统网优受到严峻的挑战。 以下为nokia系统最常用到的800系统掉话的原始统计公式：以上具体统计项含义请查询bsc measurements_t12.pdf。熟悉系统的从以上公式不难发现，nokia的掉话统计项将a接口以及陆地链路的掉话全部归结进来，所以nokia系统的掉话率会比moto系统要高不少。下面重点介绍几项掉话：211 rf掉话 rf的掉话是掉话中比例最高的，也是最难解决的部分，因为形成的原因很多，各系统基本一致，在此不详述。212 abis掉话在这些分类统计项中，abis的掉话仅次于rf掉话，在nokia系统中abis掉话部分包含：丢失了ack of channel activation 信道激活命令和丢失了establishment indication 建立指示命令。反观moto系统中，这里包含了经常看到的ma_fail_from_ms，而看到这个指标偏高的第一动作，往往是重启尝试，因为导致ma_fail_from_ms偏高原因绝大部分是由于硬件故障或者干扰，ioi不高的情况下，一般重启载频会好，或者调站就基本能解决问题了。这是moto的处理方法，但是在nokia系统中不存在调测线性动作，虽然也有校准，但是需要在故障非常明显的情况下，包括告警等，并且校准深度不够，所以通常也就是更换出故障的硬件，然后仅仅靠abis的掉话就定性硬件故障，这对于nokia系统来说工作量是非常恐怖的，因为这个掉话的比例相当高，往往是rf的1/6左右，何况abis掉话不单单是呼叫建立阶段的，还包含释放阶段的。在nokia的统计项中无法继续细分统计项，也就是说无法具体定位到每个信令流程阶段，不过这也是以后nokia优化的可以突破的一个方向。最后需要说明的是：象类似ma_fail_from_ms，在moto系统中仅影响tch分配成功率，以及呼叫建立成功率等呼叫建立统计指标，根本不算掉话。熟悉moto系统的都知道，把这项统计加入掉话的话，对于指标的影响的不言而喻的。213 tr掉话 tr掉话在有些地方也称为tc掉话，是transcode的意思。发生tr掉话的原因为硬件故障，日常监控中需对该项掉话引起重视，经常会出现tr掉话异常增高现象。分为两类： a、个别小区tr掉话高 小区级的统计数据分析发现个别小区tr掉话高，需查看bsc告警（zaho,zahp），会有2993告警，掉话发生在abis口上，故障位置在bsc以下，可以将故障定位至tc板或者载频时隙，tc板故障可以通过更换tc板得到解决，载频时隙的需要将该trx删除重新配置，然后重启bcf才可以解决，再不行就需要更换载频槽位，配置新载频。 b、bsc的tr掉话高，但是没有高tr掉话小区 如果发现tr掉话是分散的，几乎是平均分配至较多小区，这种情况下的硬件故障最容易被忽视，需查看bsc告警（zaho,zahp），如果有2992告警，掉话发生在a口上，故障位置在bsc以上，可以将故障定位至bcsu、tc板或者pcm电路等。还有一种情况是tr掉话一直存在的，也比较平均的，但是没有任何告警，这也有很有可能的，比如该bsc的半速率开的比较多，而bcsu的负荷很高，伴随的情况就是tr掉话高。在某地区移动的bsc22在五一过后，将半速率减少大半，tr掉话减少100多次，但是该bsc的负荷较高，所以也是tr掉话一直无法消除的原因。214 aif掉话 a 口掉话就是inter_bsc的掉话，如果出现突发异常需查看告警（zaho,zahp），看是否有a口电路出现故障；如果一直偏高，需进行邻区优化，查看是否存在数据错误邻区，否则需进行外部切换优化。215 lapd掉话 lapd掉话基本是固定链路的掉话，由传输故障引起的，大多数情况是传输退服，可以查看bts和bsc的告警确认（zaho,zahp.zeol.zeoh）。216 bts fail掉话 由于基站退服造成的掉话，另外锁时隙、锁载频、锁基站的操作如果不加“：fho;”强制切换命令，也会导致bts fail掉话。可以通过告警查找重启原因，如果是非人为操作原因，需要检查传输、电源等硬件设备。217 切换掉话 nokia 系统主要有tch_rf_old_ho、tch_abis_fail_old、tch_a_if_fail_old、tch_tr_fail_old 四种。 2.2话务掉话比话务掉话比公式为：mtbd=tch traffic*60/drop calls,单位为分钟，表征全网两次掉话之间，平均持续的通话时长。其实只是掉话率考核的变相公式，从公式也可以看出话务量为不可控制因素，网优的目标还是只有一个：降掉话。或者将公式稍微演算一下： 经过演变之后，分子变成平均通话时长，分母变成掉话率，最后还是回到掉话率上面来。当然考核掉话的形式很多，有些区域采用掉话概率，也就是话务掉话比的倒数；有些地区采用其他掉话公式，主要的目标都是一样的：降掉话。2.3 无线接通率无线接通率是体现网络无线侧接通情况的综合指标，主要涉及两个指标：tch 拥塞率和sd拥塞率。公式为：radio success rate(1tch block rate)*(1-sdcch block rate)。从公式也可以看出，无线接通率主要是反应出网络中拥塞的状况，而这正是无线侧的接通状况。 拥塞的产生大部分是由于网络设计的容量满足不了现网的话务而产生的（部分是由于小区不合理覆盖或者参数设置不合理产生的，只要不合理得到矫正就可以解决），根本解决之道是扩容，当然对付拥塞也存在很多微调手段，包括双频网话务均衡，及邻区话务分流等，sd拥塞也可以加配信道来达到目的，这里就不详述拥塞缓解的手段了。无线接通率一般是一个优化项目中比较容易达到的指标，但是目前在联通的g网中也存在部分地区此项指标偏低而无法达到，主要是联通目前的投资重点是cdma，对于g网的投资不愿意继续增加，而实际的话务却在不断增加，导致无线接通率较低。2.4 最差小区比例最差小区，顾名思义是网络中指标最差的那部分小区，涉及网络运营商的角度最关注的两大指标：掉话和拥塞。一般最差小区的定义为：1、tch拥塞率大于5的小区；2、掉话率大于3的小区，并且每线话务量大于0.12erlang的小区。只要两条中满足一条即为最差小区，最差小区比例就是最差小区的数目在全网小区中的比例，大部分地区考核最差小区比例为1以下。 最差小区比例一般也是各优化项目比较容易达到的指标，处理方法就是处理掉话和拥塞的方法。大幅度降低全网的掉话难度是非常大的，但是降低个别小区的掉话手段还是比较丰富的，也是最差小区比例指标容易做好，然而全网掉话率或者话务掉话比比较难以达标的原因。2.5 sd掉话率nokia系统的sd掉话率相比其他系统会高很多，先来看一下其公式： 从公式的分母来看，含有sdcch_assign 和sdcch_ho_seiz两项，其中sdcch 的切换数量很少，主要由sdcch_assign 组成。而sdcch_assign 是bsc 在immediate assignment 信令消息之后触发，此时手机还没有真正占用在sdcch 信道上。按此公式，此后由于某种原因手机没有收到该immediateassignment 消息或bsc 没有收到establish indication 消息，都算sdcch 掉话。而在moto的sdcch 掉话率公式中，其掉话是从bsc 收到establish indication 之后才开始算的，此时手机真正占用在sdcch 信道上，故二者的掉话率数值存在差别。公式的分子中abis的sd掉话就是bsc未能收到bts送来的establish indication消息，造成t3101超时，记录为sdcch_abis_fail_call,下面为某地区耀华基站的sd掉话统计： 由上可以看出，abis掉话占了sd掉话的90以上，而熟悉moto系统的都知道，这里已经包含了channal_request_ms_fail，一般造成这项指标偏高的原因为干扰和硬件故障。再回到nokia系统，sdcch_abis_fail_call 主要由于t3101 超时或bsc 收到的establish indication 中的内容有误造成。t3101 定义是当bsc发出immediate assignment 之后触发，当收到establish indication 后停止计时，t3101 默认值是3 秒。造成t3101 超时的原因有以下几种：1、外部干扰。即当干扰噪声具有rach 相同的特性，使bts 误认为手机发出，从而使bsc 分配相应的sd信道。2、硬件故障。载频故障或者sd所在载频通路的故障都会导致abis掉话高。3、同bcch 同bsic 的2 个小区相距较近。当手机向小区1 发出rach 时，小区2 也同时收到该rach 消息，造成2 个小区都分配sdcch信道。4、小区1 的bcch 频点和小区2 的tch 频点相同，且具有同样的bsic， 2个小区的距离较近。当手机向小区2 的tch 发出切换接入请求时，小区1误认为手机发出rach 信号，从而使bsc 分配相应的sdcch 信道。5、无线环境恶劣，覆盖差，导致无线丢失。 针对如上几点，处理sd掉话的基本思路为：1、 查看干扰情况。查看是否存在外部干扰，通过190报告或者zero监控。确认有干扰存在可以改频尝试，如改频无效需查找外部干扰源。系统内干扰通过wp等工具确认，改频就可以解决。2、 采载频级统计。统计载频的误码情况，可以进一步确定sd掉话产生在哪块载频。3、 硬件故障处理。重启高误码载频，如为软硬件配合故障，通过重启操作就可以降低误码率，降低掉话率；如果重启无效，需更换载频。4、 硬件故障暂时避免。并不是每次故障确认都能够及时更换载频的，可以通过将sd信道配置至另外载频或者另外时隙来避开高sd掉话，也是检查硬件故障的一种尝试办法。第三章 告警收集及处理 告警的处理一直是优化中比较重要的过程，尤其在一些性能指标不是很全面的情况下，判断故障的主要来源就是告警，系统本身的告警设置也是提醒维护人员及时处理故障。主要日常监控的告警分为两大类：bsc告警和bts告警。3.1bsc告警 bsc告警使用zaho命令采集当前告警，zahp命令采集历史告警，告警信息显示格式如下，以下为bts告警的界面，但是格式是一样的： 其中2993、2992等告警均为较重要的告警，能够直接指出现网中存在问题的故障单元，为排除故障提供准确的参考。采集告警之后，部分告警需要查看告警手册才能精确定位故障，告警手册存在于ned中的告警章节或者bsc s8等文档中。3.2bts告警 告警的文档格式如上节bsc告警中图片。bts告警使用zeol采当前告警，zeoh采历史告警。每天的bts告警信息量是非常大的，不可能每个告警都去关注，而往往丰富的网络经验在查看告警的时候起到关键作用，这不是三言两语能够表达明白的，还是需要靠平常的不断摸索，为自己积累经验。 查看告警手册对应上图中7602告警的解释如下： 一般告警手册的解释也比较规范，如上图，能够直接指出故障单元的具体位置以及消除告警的操作方法。 告警的处理在日常的优化及指标监控中非常重要，如果能够及时整理分类或者有处理工具的情况下，最好每天采集一次。第四章 网络安全分析本章涉及的内容是本人在做nokia系统得出的一些看法和小结，觉得和moto系统的优化思路有所区别，但是从网络角度来看，基层的道理都是互通的，也希望能够给优化带来一些参考。因为在以前moto的优化中，较少的考虑这方面的东西，可能部分工程师在做，但是整体的优化流程和报告中甚少涉及这方面的，在此希望起到抛砖引玉的效果。一般在特殊的节日来临，或者区域内有大型活动等突发的话务增长出现时候，网络安全的分析对于运营商是比较有指导意义的，或者在整体规划设计中，预期的网络负荷情况可以从本章得到一点思路。4.1 trx负荷分析 trx负荷也称bsc容量负荷，即一个bsc所能容纳的trx数目。bsc的trx容量由bsc类型决定，现在最普遍的是512容量的bsc，也就是最多可以配置512块载频，另外有330，480，660等容量的。以下为某地区的nokia各bsc的trx负荷表：paradatebsc_idbsc_nametotal_trxbsc_typetrx_load可加载频数2005-7-2553744nokia_bsc20549351296.29%192005-7-2599010nokia_bsc22248951295.51%232005-7-2599003nokia_bsc21548551294.73%272005-7-2599002nokia_bsc21343251284.38%802005-7-2599009nokia_bsc22142551283.01%872005-7-2553849nokia_bsc20641451280.86%982005-7-2542793nokia_bsc21140851279.69%1042005-7-2542186nokia_bsc21238951275.98%1232005-7-2553848nokia_bsc20338551275.20%1272005-7-2599006nokia_bsc21837651273.44%1362005-7-2543384nokia_bsc21037451273.05%1382005-7-2542443nokia_bsc20932344872.10%1252005-7-2544048nokia_bsc21436751271.68%1452005-7-2599004nokia_bsc20435351268.95%1592005-7-2542187nokia_bsc20834951268.16%1632005-7-2542184nokia_bsc21634751267.77%1652005-7-2599005nokia_bsc21732051262.50%1922005-7-2599008nokia_bsc22025051248.83%2622005-7-2599007nokia_bsc21919651238.28%316 nokia优化中trx负荷的安全线为80，因为考虑到网络的弹性和bsc的bcsu负荷安全性（bcsu负荷在下面章节讨论），比如bsc范围内考虑突发的局部话务需要留够余量，下一期的扩容需要留够余量，规划站临时站等都需要留有余量等。而上表中的bsc222已经出现了无法继续增配载频的情况，给该bsc的一批基站扩容带来障碍，这还不包括该区域的话务增长带来的运行压力。 以上是全速率的情况下的trx负荷计算，有些地区已经开启半速率功能，而在计算trx负荷的时候就需要考虑半速率的情况。目前通用的算法有两种：1、（现网载频数）（半速率的信道数/8）作为trx的总数；2、（全速率信道数半速率信道数2）/8作为trx的总数。 两种算法出来的结果偏差非常小，可以忽略不计，目前还没有没有绝对的规范，只是业内的一种通用的算法，只要双方认可就可以。4.2话务负荷分析 话务负荷分为多个层面，包括网络的话务负荷、bsc的话务负荷和小区的话务负荷，小区的话务负荷（小区利用率）就不在这里讨论了。4.2.1 网络话务负荷 网络话务负荷也称为网络利用率，也就是全网吸收话务的能力，在各个系统中都是类似的，在此不再详述计算方法。一般来说，按2的呼损率计算，全网利用率达到50是相当高的，需要引起重视，会有网络不稳定因素出现，特别需要预防bsc重启。网络利用率是在每一期的规划中的重点考虑因素。以下为某地区的晚忙时全网利用率情况，目前已经出现大面积拥塞。 从全国的网络情况来看，移动运营商和联通运营商战略发展角度不一样,投资力度也有较大差异,所以对于利用率的各地要求也会有所差异,整体来说联通的利用率要高一些,也就是网络的话务负荷会相对高一些。下图为晚忙时某地区联通的gsm900、dcs1800以及micro的各自利用率，可以明显看出dc1800的利用率是非常高的，利用率最低的是微蜂窝的，但是考虑到微蜂窝的最忙话务并不是出现在晚忙时，而是白天上班时间段中，所以微蜂窝的利用率一般建议采用早忙时。从双频网的利用率角度来看网络的话务负荷有时对于网络的话务分布，分析全网的话务均衡等起到指导作用。 最后网络话务负荷还有一个分析方法，就是区域分析法，将话务分区域统计，可以知道网络的规划发展重点和发展方向。以下为某地区联通的区域统计，由于该地区较大，分为内环之内，内外环之间和外环以外三个区域，发现内环之内（市区）话务负荷较低，外环之外话务负荷非常高，所以从网络角度可以分析出，郊区的话务发展已经成为该地区的重点发展方向，因为以下还是采用呼损率为5的利用率算法，郊区的话务负荷已经达到60。对于其他网络，一般来说郊区的话务负荷会低于市区的话务负荷，分区域的话务分析方法在每期的规划之前是非常有意义的，并且对于优化指标的重点也能够提供有效的参考。本节对于话务负荷的三种分析方法也同样适用于其他统计项的分析，以下例子为切换成功率的分析示例：该地区在8月13日，切换成功率指标出现下降趋势： 细分到区域的切换成功率情况如下： 至此已经可以确定故障区域是在内外环之间，还可以继续细化该统计项，分为intra_bsc和inter_bsc的切换，分析故障是出在哪个环节，如下图： 可见是由于该区域的inter_bsc的切换成功率明显下降导致，分析到这一步，再具体定位到下一级单元已经非常容易，只需找出inter_bsc切换差的小区就可以精确定位。4.2.2 bsc话务负荷 bsc话务负荷分为两部分：bsc话务利用率和a口电路的话务负荷。 bsc话务利用率： bsc的话务利用率也就是bsc的话务负荷，能反应一个bsc话务规划的合理性和话务吸收能力，以下为某地区的两个bsc的话务负荷情况，以2的呼损计算： 这两个bsc有特殊性，因为bsc212为室内分布和微蜂窝的bsc，但是这个例子为了说明，bsc之间的话务负荷之差是明显存在的，网络优化的工作是要对话务负荷极高的bsc作出合理的优化调整建议或者规划方案。运营商一般会在每一期的规划中考虑到部分话务负荷高的bsc，会进行bsc分裂或者增加bsc的计划，但是当该地区有较明显的话务增长时，可能bsc难以承受，最好情况是导致无法吸收有效话务，拥塞严重；比较糟糕的情况是，bsc负荷过高而导致部分功能单元运行瘫痪，甚至bsc重启。a口话务负荷： 一般从无线优化的角度来看，a口的电路情况不是无线部分需要关注的，但是从网络优化的服务角度来说，自身可以做到的，完全可以为运营商提供正确的网络建议，而这部分是无线侧和交换侧交接部分，所以在可能的情况下还是应该提供这一项的分析。 当然如果是大型网络，一般无线和交换的分工比较明确，这部分是由交换部门监控，在此提供此项分析的目的，是为了拓宽网络优化服务。 a口的电路情况可以登陆bsc，使用zcel命令查看，因为是固定链路，只要不过载就是安全的，一般来说负荷达到90是告警线，需要运营商引起高度重视。或者预算的话务增长使得a口负荷达到告警线，也需引起重视，以下为某地区在五一黄金周到来之际对于区域的话务负荷分析及话务增长预测情况，表格中含具体公式，可以点入查看： 该区域的现网话务负荷还算比较合理，但是如果按照往年的话务增长预测就有点难以承受，所以部分bsc增加了a口电路，有些区域的话务增长实际也根本达不到这个增长率，所以部分bsc就维持现状。4.3 bcsu负荷bscu和moto里面的gproc差不多，就是bsc中的处理单元。bcsu负荷过高将导致rach消息被删除（呼叫难以发起）、bcsu重启（掉话）、隐性故障（部分abis掉话由此而来），甚至增加bsc的不安全因素。以下为某地区的bcsu负荷分析：第一部分：问题提出寻呼统计情况：la_id_lactimepagingpaging_delrach_del21812005072619361320362182200507261934727012183200507261932393002184200507261931479002185200507261919321027232812005072619625520653283200507261959738062424184200507261948458010141922005072619467010134193200507261965915053419420050726194643103241952005072619738460285725180200507261925426005181200507261965269025182200507261933173005183200507261946700019518420050726194204602185518520050726192051000上表中：bcsu_overload_deleted_rach：bcsu 过载所删除的rach 信道数；高bcsu_overload_deleted_rach 是当bcsu 负载过高时，网络为了保护mcmu （bsu主处理器）以防网络过度负载而将rach 信息删除。由此怀疑，部分bsc是否存在bcsu负荷过高的问题。第二部分：bsc的trx负荷bcsu负荷由话务量和trx数目决定，当然一块bcsu所挂的trx数越多，相对来说话务量也越高。统计全网各bsc的trx负荷如下（在trx负荷分析中出现过）：bsc_idbsc_nametotal_trxbsc_tyetrx_load可加载频数53744nokia_bsc20549351296.29%1999010nokia_bsc22248951295.51%2399003nokia_bsc21548551294.73%2799002nokia_bsc21343251284.38%8099009nokia_bsc22142551283.01%8753849nokia_bsc20641451280.86%9842793nokia_bsc21140851279.69%10442186nokia_bsc21238951275.98%12353848nokia_bsc20338551275.20%12799006nokia_bsc21837651273.44%13643384nokia_bsc21037451273.05%13842443nokia_bsc20932344872.10%12544048nokia_bsc21436751271.68%14599004nokia_bsc20435351268.95%15942187nokia_bsc20834951268.16%16342184nokia_bsc21634751267.77%16599005nokia_bsc21732451262.50%19299008nokia_bsc22025051248.83%26299007nokia_bsc21919651238.28%316 可见部分bsc的trx负荷已经快达到顶点，而bsc222已经出现trx数据无法增加的情况，对于bsc的trx负荷，系统建议保持在80以下，为下期规划及临时扩容等预留空间，并且过大的trx负荷必然导致过大的bcsu负荷，从而导致网络系统的故障出现，比如rf掉话增高，tr掉话的增高，bcsu重启等。目前全网bsc222为话务量最高的bsc，晚忙时基本在1700erlang以上，也是rach_del最严重的区域，在12期规划中该bsc将进行分裂，增加新bsc，可望在下半年得到解决。如近期需解决trx负荷导致的该bsc无法扩容情况，只能先将该bsc下辖部分基站割接至相邻bsc。同时bsc221情况也类似，负荷相对稍低。第三部分：bsc的bcsu负荷对应以上trx负荷分析，从如下bcsu负荷数据可以印证，高trx负荷的bsc，bcsu运行的负荷也较高：statbsc_nameavg_loadmax_loadmin_load20050726-19nokia_bsc21528.2424243120050726-19nokia_bsc22230.7878843120050726-19nokia_bsc22126.2424241020050726-19nokia_bsc21324.6363640120050726-19nokia_bsc20526.6363638120050726-19nokia_bsc20416.8484837020050726-19nokia_bsc21419.1818235120050726-19nokia_bsc21716.1212131120050726-19nokia_bsc21019.7878831120050726-19nokia_bsc21619.7575829120050726-19nokia_bsc21115.9090924120050726-19nokia_bsc2189.39393922020050726-19nokia_bsc2196.57575818120050726-19nokia_bsc20311.4848517120050726-19nokia_bsc20910.8275917120050726-19nokia_bsc2207.42424217020050726-19nokia_bsc20810.0909115120050726-19nokia_bsc2069.12121214120050726-19nokia_bsc2124.54545590 bcsu的系统安全运行负载的警戒线为40，在目前nokia区域中有4个bsc忙时最大负荷超过警戒线，系统运行存在安全隐患，需在日常监控过程中引起高度重视，特别需要提前预估在这些区域出现大幅的话务增长情况，比如一些大型活动等，以此做好应对方案。如万一出现有大幅话务增长情况，需改变测量周期以应付突增的bsc负荷。 目前如上几个bcsu负荷较高的bsc在12期规划中均有分裂bsc或者割接的考虑。第四部分：bcsu的trx分配在第一部分中提到的几个rach_del较高的bsc中，bsc222、bsc221因为本身bcsu的负荷确实较高，需增加bsc才能解决，而bsc217在上述的trx负荷及bsc整体的bcsu负荷分析中均不在高负荷之列，但是基于bcsu负荷过载的rach_del却较高。 由此，需回到bcsu的负荷来源的分析，如上已有所述，bcsu的负荷来自话务量和trx的数目，因此需要考虑是否在bsc中存在bcsu负荷不均的现象，统计bsc217的bcsu负荷情况如下：statobj_nameobj_indexbsc_nameavg_loadmax_load20050726-19bcsu3nokia_bsc21725.753120050726-19bcsu0nokia_bsc21724.253020050726-19bcsu1nokia_bsc21722.52720050726-19bcsu6nokia_bsc217172120050726-19bcsu7nokia_bsc217172120050726-19bcsu4nokia_bsc21710.751420050726-19bcsu5nokia_bsc21710.251320050726-19bcsu8nokia_bsc2175.57 可见在bsc217当中确实存在3块bcsu负荷相比其余5块bcsu负荷明显偏低的情况，由此再做一次推断，这3块bcsu下挂的trx较其余bcsu明显偏少，如下图：上图可见bcsu4、5、8和其余bcsu之间的trx数目之差达到30块之多，这也是导致bsc整体的bcsu负荷不高，而rach_del较高的原因。与此同时，检查全网的bcsu的trx分配情况，发现其他bsc也有类似情况： 可见bsc204、213、214、219、220和221都存在bcsu的trx分配不均衡现象。以下为各bcsu负荷情况的统计，可以对照印证。 如上bcsu负荷分析，该区域的bcsu运行情况并不乐观，但是从分析也可以看到，网络分析是一个综合的过程，并不是仅仅的bcsu的负荷问题，涉及到trx负荷，寻呼情况等。4.4 寻呼负荷 在分析寻呼负荷之前，需要了解：对于nokia系统，由于信令链路直接绑定到时隙，信令链路的负荷也是一个重要考虑因素。对于每个载频的信令链路，可以设置为16kb/s、32kb/s、64kb/s，具体设置需要视网络容量需要而定，这在以下分析中比较关键。gsm 规范里，lapd 消息有as7 寄存器保存，as7 里面只能有两个同时未被证实的信令消息，所有的其他排队的消息必须等其中一个被证实，gsm 推荐lapd window size 大小为2。对于16kb/s 的信令链路，最大信令话务负荷不应该超过8kbit/s(1000byte/sec).如果超过1200byte/sec，as7 有溢出的危险。paging message 消息的长度大约为21byte。根据bsc 正常负荷和呼叫比例，大约60%信令链路的容量用于paging message，那么，平均的pagingmessage 的负荷count/sec/link 为0.6*1000/21=29，也就是100,000pages/hour，这是对正常的呼叫模型。对于64kbit/s 的link，同样的应用原理，推荐的最大的平均信令话务为4000byte/sec。只有bcch 的载频的信令信道会有pch，目前很多网络采用了16k 的信令速率，所以lac的寻呼负荷容量也是我们平时着重注意的因素，与moto 系统关注空中接口的paging 负荷不同的是，nokia 系统更多的是关注abis 信令链路的容量负荷。 以下为某地区移动五一黄金周之前对于寻呼负荷的预测和分析：la_id_lacpagingpaging_delabis paging容量（按16k信令计算）abis paging负荷按32增长率计算(abis)按绝对增长值计算(abis)223706760701000000.68 0.89 0.83 223747197501000000.72 0.95 0.89 223775649611000000.56 0.75 0.69 223787384951000000.74 0.97 0.91 223793619601000000.36 0.48 0.45 223802500901000000.25 0.33 0.31 2238263892151000000.64 0.84 0.79 224975328231000000.53 0.70 0.66 2250330231131000000.30 0.40 0.37 225055983401000000.60 0.79 0.74 现网的寻呼负荷是准确的数据，能够反应目前的寻呼负荷情况，一般系统推荐寻呼负荷告警线为80%。而寻呼的增长预算是不标准的，因为寻呼量的增长和话务的增长并不是同样比例的关系，所以按照话务量的增长率来作为寻呼的增长率是基本不吻合的，但是现在行业内尚没有找到准确的寻呼话务增长模型预测方法，一般也就用话务增长模型来顶替使用，但是在分析预测之后肯定会说明这只是话务的增长预测。第五章 优化发展和延伸本章内容全部为个人看法，为公司的战略发展提供部分的参考，有些想法有失偏面、浅薄之处，请予以谅解，也可将本章略过，以免贻笑方家。网络优化的发展方向比较明显：深入发展和全面延伸。这个观点在业内很早已经提出，但是具体落到实处或者有心致力与此的公司寥寥无几，本章就这两点阐述个人观点。5.1 优化深入发展gsm移动通信网络现状：1、经过多期的网络建设，网络趋于成熟和饱和，但是需要长期的优化；2、经过多期的网络优化，网络性能指标趋于稳定，可挖掘的潜力逐步减少。由此不禁想到未来的优化如何发展，如何找到优化新的增长点，或者起飞点；如何深入发展优化，提高客户的满意度。5.1.1 优化转型在此提出一个观点：优化需要转型，需要从指标性优化向资源性优化转型。这个观点在几年前曾经出现过雏形，但是实际市场反响并不大，在部分地区甚至出现相反的执行效果。这里提出的转型模式并不是纯粹的资源性优化，而是在传统优化基础上，思路慢慢往资源性优化方向上转。因为传统指标性优化目前受到了较大的挑战，往往指标是压在优化公司头上不可挣脱的枷锁，只能依赖其他动作来达到目标，这不是优化公司愿意看到的。资源性优化涉及的基本思路就是网络的利用率和网络的安全性监控及发展建议，具体的操作流程或者优化模型可以深入探讨流程化，或者形成报告模板。目前爱立信已经在网络优化上往资源性优化方向上转变，因为资源性优化可以不受厂家设备的限制，不会遭遇操作障碍或者系统熟悉程度等方面的尴尬。而比较明显的例子是美国现观科技的移动性分析优化（也是资源性优化的一个方向），其优化过程只需一周，投入人力3人以内（当然可以多派人手增加阵容），其价格为90万，而当地东信网络投入的优化人手同样3人一车，价格只有45万，况且优化周期是半年！这里抛开市场的其他因素，至少现观科技提出的优化概念运营商之前没接触过，省公司允许操作高价位，而传统的优化价格已经过于透明，就算有再好的市场关系也无法实现高利润。 可以提供现观科技的优化文档共大家讨论。5.1.2 优化工具 优化过程中经常会处理大量的数据，而初期的优化工程师只是使用excel对于数据进行简单的筛选排序，随着优化的深入，部分工程师自己制作一些小工具以提高自身的工作效率，但是这些远远满足不了大数据量的网络分析。我们日常使用的wp或者net_in_hand软件已经能够实现较多的网络功