CDMA网络话统分析优化培训

CDMA网络话统分析优化1概述一般来说，网络优化时，话统数据、路测数据是优化的客观依据，人为感觉是主观依据，在解决疑难杂症时就需要通过信令跟踪与分析来定位问题。可见，话务统计数据是了解网络性能的重要手段，尤其是网络有话务量时，话务统计成为网络优化的重要参考和指导，其指标的完整准确和操作的方便性直接影响网络优化的效率。同时，话统指标的好坏也是考察衡量优化工作是否有成效的一个重要方面。另一方面，运营商十分的重视话统数据。运营商决策层往往就是通过话统提供的各种网络运行的直观数据来掌握和判断网络运行情况，同时也作为下一步网络扩容的重要依据。1.1统计工具主要统计工具为SMARTER38及中国电信无线网络优化平台。2话统分析主要关注内容2.1呼叫建立成功率分析呼叫建立成功率是评价系统性能的一个非常重要的指标，反映系统接通呼叫的能力。呼叫建立成功率低在移动用户端，反映出来就是难以打通电话或数据呼叫无法连接上网的问题，也反映系统提供业务和保证服务质量的能力。因此，我们将通过本文的分析和研究，对提高呼叫建立成功率提出一个切实可行的解决方案。2.1.1影响呼叫建立成功率的主要因素及其解决方案有可能影响到呼叫建立成功率的因素有以下这些：RFAccessFailures(TCCF)CallSetupFailuresCE/PPResourceBlockingForwardPowerResourceBlockingReverseRFLoadingResourceBlockingCallDeliveryTypeRelatedTerminationFailuresRegistrationRelatedTerminationFailuresOtherMiscellaneousFailureComponent2.1.1.1RFAccessFailure(TCCF)的呼叫建立失败分析在小区下发CAM或ECAM消息后，意味着基站已经有了相应的硬件资源来支持该呼叫，但小区无法收到SCCM消息的时候，就会产生一次TCCF。TCCF的产生通常与较差的无线环境有关，因此TCCFRATE一般也称为RFAccessFailureRate。当然也有一些硬件相关的失败会导致TCCF产生。我们下面将讨论3G1X呼叫建立几个步骤，以及各个步骤中对TCCF产生可能存在的影响以及相应的优化方法：1.InitialCellSelectionbyMobileinIdleMode2.AccessProbeSequenceonAccessChannel3.AcknowledgementbyCellonPagingChannel4.ChannelAssignmentMessageonPagingChannel5.TrafficChannelAcquisitionbyMobileandCell6.FinalHandshaketoConfirmServiceOptionandServiceConnectionInitialCellSelectionbyMobileinIdleMode待机模式下，手机将不断监视驻留的导频上的寻呼信道，并将当前导频强度与其他可用导频进行比较。当发现更强的导频后，手机就会执行待机模式下的切换。当手机起呼的时候，通常就在其待机时驻留的导频上起呼。因此，确保手机在待机状态下始终驻留在一个最理想的导频就是十分重要的。因此相应优化步骤包括了：确保邻区设计准确完整邻区设计是双向的通过Homax工具检查邻区及其优先级设定准确避免PN复用距离不够AccessProbeSequenceonAccessChannel当用户发起呼叫，或用户被叫时收到了基站寻呼的时候，终端就会进入接入探针序列的阶段。这时候，既要保证终端发射功率最小化，又要保证终端能够最短的时间内成功接入。因此接入参数的设置必须符合朗讯的推荐值，也可以根据网络实际情况和需要适当的进行优化调整。ChannelAssignmentMessageonPagingChannel这时，如果小区已经具备了硬件和功率资源能够支持新的呼叫，那么基站就会通过寻呼信道下发ChannelAssignmentMessage(CAM)消息。CAM消息主要用于通知终端使用指定的WalshCode和指定的载频。这里主要是要尽量避免跨载频的分配产生；如果跨载频的分配无法避免，应尽量减少跨载频分配失败，避免跨载频TCCF。TrafficChannelAcquisitionbyMobileandCell这里是大量TCCF产生的阶段。当手机收到了CAM消息后，就开始将按照指定的载频和Walsh码进行信号调制，并且成功获得基站发送的空数据。这时手机就会发出一个业务信道探针，基站必须能够应答该探针才能结束这个阶段。这个过程中的任何一次失败，都会产生一条TCCF纪录，通常是TCCF2或TCCF1，不过一般超过80%的TCCF都是TCCF2。主要有如下这些因素可能会导致失败：1.基站按照系统定义的功率发送空数据的时候，发射功率不足以抵消干扰带来的影响，从而导致手机无法成功获取基站发送的空数据，这时候会产生TCCF；2.手机最初起呼的导频不再是主导频，按照IS95A的标准，手机在整个起呼过程中仍然必须驻留在该导频上，这时其他导频对其就会形成强干扰，从而导致TCCF产生。3.起呼区域内业务量高或者导频污染严重会导致干扰水平较高，导致业务信道或寻呼信道无法克服干扰，导致TCCF产生。4.高的路径损耗，可能导致各个信道无法支持呼叫建立，通常是由于无线信号覆盖不好或室内覆盖不足。因此我们的主要优化手段包括了：参数nom_gain的设置对TCCF十分关键，如果设置过低，会导致手机无法成功获得业务信道，放弃呼叫尝试，产生TCCF；如果设置过高，会导致系统容量下降。减少不必要的软切换区域：避免越区覆盖控制高负载的小区，特别是那些忙时TCCF显著升高的小区避免导频污染FinalHandshaketoConfirmServiceOptionandServiceConnection在最后的服务协商(ServiceNegotiate)阶段的失败，会产生TCCF7（ServiceNegotiateFailure）。在基站收到SCCM(ServiceConnectCompeteMessage)消息之前，可能会由于无线链路的问题，产生TCCF3。不过这个阶段的TCCF3应该比较少，因为经过TrafficChannelAcquisition阶段后，无线环境的问题已经被大多排除了，而且SCM和SCCM消息交换前，终端已经可以进入软切换了。这一阶段的优化主要是确保交换机上的ServiceOption设置正确，对于TCCF3而言，其优化手段和TrafficChannelAcquisition阶段一样。除了以上各个阶段的优化建议外，提出了一些新的Feature用来改善接入过程，包括了AEHO，AHO和CAMSHO。2.1.1.2系统硬件资源或功率资源限制导致的呼叫建立失败分析这一类呼叫建立失败包括了以下三种情形：CEBlockingForwardPowerResourceBlockingReverseRFLoadingResourceBlocking在呼叫建立过程中，只有基站的硬件资源以及前向和反向功率没有过载的条件下，系统才会下发ChannelAssignmentMessage，对应的RFAssignment计数器开始进行计数统计。我们在这一部分将主要讨论，这一类资源限制导致的呼叫失败的原因以及解决的方法和优化的建议：1.CEBlocking首先我们应该确保目前网络中资源是合理配置的，需要遵循以下的一些基本原则：确保不同的载频上的分配了与各载频话务量对应的CE信道数目；经常检查小区的CE信道的最高占用数目（比例）；保证硬件设备的及时升级或更新；确认拥塞小区是否使用了VvsD的Feature，如果使用了，确保参数设置合理，并经过了优化。除了以上的一些基本原则需要注意外，我们还将分析资源拥塞的其他可能，以及解决方案：基站的硬件资源满负荷占用：这时新的呼叫发起后，基站将按照一定的算法对其分配用于业务信道的信道资源，如果没有空闲的资源可用，那么该呼叫就会被拥塞。一旦发现这类问题，通常表示硬件设备资源缺乏，需要通过新增资源来解决这类问题。如果是由于硬件上软件版本所支持的CE数目低，建议立即更换硬件，升级软件来解决。一般现在对通过CEPooling，实现了不同扇区上CE的共享，避免基站上个别扇区由于负荷高导致的CEBlocking。硬件故障：如果CCU，CDM/CCC中任何一个硬件出现故障，均会导致可用的CE数目下降，从而可能会导致CEBlocking。一般可以通过OMP上的ECPControl&Displaypage来观察这类问题，也可以通过ROP中的HEH信息来发现这类问题。如果硬件运行不稳定，可能从ECPControl&Display界面不能发现问题，那么必须通过ROP中的HEH信息来发现这类问题。由于这是硬件问题，我们需要将这类问题提供给基站维护工程师。2.Forward/ReversePowerResourceBlocking这类问题出现发生在基站处理呼叫申请时，没有足够的前向功率资源来支持呼叫，通常可能是由于前向功率过载。和前向功率过载类似的是，反向链路同样会出现由于反向功率过载导致新的呼叫或切换要求被拒绝。对于前/反向功率过载，短期内，我们通常会采用天线调整（方位角，下倾角以及天线型号）和参数（功率衰减参数，切换参数等）来降低高负荷小区的负荷；另外可以调整过载控制算法中的门限设置，不过通常不推荐，因为这种方式没有根本解决功率过载的问题，只是推迟了功率过载算法发生的时间。长远考虑的话，会建议新加载频或者周边新增基站来解决前向过载所带来的问题。我们下面具体讨论各种导致前/反向功率过载的可能原因及其解决建议：扇区达到其最大容量限制：当一个扇区上所有载频上可用的前向链路或反向链路功率全部被占用，那么新的呼叫或切换就会被拒绝。一般会表现为基站的所有扇区的话务量都非常高，并且所有载频上的话务量十分近似的时候。这类问题就是前面提到的短期内通过天线和参数调整来优化，长期考虑新增载频和基站来解决。过大的软切换区域切换区域过大，过多的不必要的软切换同样会占用前向链路/反向链路的功率分配，使得前向/反向链路功率更容易出现过载。从ServiceMeasurement中的切换比例以及Homax体现出来的越区覆盖类的问题可以发现这类问题。建议通过优化减少切换区域。VAF设置不合理对于某些特定型号的功率放大器，可能某些参数设置会导致在正常的话务量的情形下，出现前向功率过载控制。我们需要检查每扇区每载频的最高话务量和最大功率，检查各扇区性能指标，确认不同放大器的参数设置。3.CallSetupFailure的呼叫建立失败分析这一类CallSetupFailures在正常系统中应该是很少的，因此如果小区上突然出现大量的CallSetupFailure，我们需要通过ROP的记录来确定问题。CallShutdown(CS-[43])这类CS[43]的失败通常只与CCC（CDMAClusterController–主控板）故障有关，一般表现一个载频的所有扇区的CallSetupFailure突然显著升高。解决方法：可以通过交换上restore这个CCC，如果不能恢复正常有必要去现场进行诊断或更换硬件。CallShutdownType10(CS-[10])如果切换过程中由于Unanswered状态导致失败，会产生CS[10]，在ServiceMeasurement中记为一个CallSetupFailure。除了ServiceMeasurement中CallSetupFailure可以参考外，在ROP中的UnansweredOriginationorTerminationstates下记为CallShutdownType10。解决方法：由于绝大部分CS[10]表现