CDMA网络话统分析优化培训解析

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

CDMA网络话统分析优化
1 概述
一般来说,网络优化时,话统数据、路测数据是优化的客观依据,人为感觉是主观依据,在解决疑难杂症时就需要通过信令跟踪与分析来定位问题。

可见,话务统计数据是了解网络性能的重要手段,尤其是网络有话务量时,话务统计成为网络优化的重要参考和指导,其指标的完整准确和操作的方便性直接影响网络优化的效率。

同时,话统指标的好坏也是考察衡量优化工作是否有成效的一个重要方面。

另一方面,运营商十分的重视话统数据。

运营商决策层往往就是通过话统提供的各种网络运行的直观数据来掌握和判断网络运行情况,同时也作为下一步网络扩容的重要依据。

1.1 统计工具
主要统计工具为SMARTER38及中国电信无线网络优化平台。

2 话统分析主要关注内容
2.1 呼叫建立成功率分析
呼叫建立成功率是评价系统性能的一个非常重要的指标,反映系统接通呼叫的能力。

呼叫建立成功率低在移动用户端,反映出来就是难以打通电话或数据呼叫无法连接上网的问题,也反映系统提供业务和保证服务质量的能力。

因此,我们将通过本文的分析和研究,对提高呼叫建立成功率提出一个切实可行的解决方案。

2.1.1 影响呼叫建立成功率的主要因素及其解决方案
有可能影响到呼叫建立成功率的因素有以下这些:
➢RF Access Failures (TCCF)
➢Call Setup Failures
➢CE/PP Resource Blocking
➢Forward Power Resource Blocking
➢Reverse RF Loading Resource Blocking
➢Call Delivery Type Related Termination Failures
➢Registration Related Termination Failures
➢Other Miscellaneous Failure Component
2.1.1.1 RF Access Failure(TCCF)的呼叫建立失败分析
在小区下发CAM或ECAM消息后,意味着基站已经有了相应的硬件资源来支持该呼叫,但小区无法收到SCCM消息的时候,就会产生一次TCCF。

TCCF 的产生通常与较差的无线环境有关,因此TCCF RATE一般也称为RF Access Failure Rate。

当然也有一些硬件相关的失败会导致TCCF产生。

我们下面将讨论3G1X呼叫建立几个步骤,以及各个步骤中对TCCF产生可能存在的影响以及相应的优化方法:
1. Initial Cell Selection by Mobile in Idle Mode
2. Access Probe Sequence on Access Channel
3. Acknowledgement by Cell on Paging Channel
4. Channel Assignment Message on Paging Channel
5. Traffic Channel Acquisition by Mobile and Cell
6. Final Handshake to Confirm Service Option and Service Connection
➢Initial Cell Selection by Mobile in Idle Mode
待机模式下,手机将不断监视驻留的导频上的寻呼信道,并将当前导频强度与其他可用导频进行比较。

当发现更强的导频后,手机就会执行待机模式下的切换。

当手机起呼的时候,通常就在其待机时驻留的导频上起呼。

因此,确保手机在待机状态下始终驻留在一个最理想的导频就是十分重要的。

因此相应优化步骤包括了:
⏹确保邻区设计准确完整
⏹邻区设计是双向的
⏹通过Homax工具检查邻区及其优先级设定准确
⏹避免PN复用距离不够
➢Access Probe Sequence on Access Channel
当用户发起呼叫,或用户被叫时收到了基站寻呼的时候,终端就会进入接入探针序列
的阶段。

这时候,既要保证终端发射功率最小化,又要保证终端能够最短的时间内成功接入。

因此接入参数的设置必须符合朗讯的推荐值,也可以根据网络实际情况和需要适当的进行优化调整。

➢Channel Assignment Message on Paging Channel
这时,如果小区已经具备了硬件和功率资源能够支持新的呼叫,那么基站就会通过寻呼信道下发Channel Assignment Message(CAM)消息。

CAM消息主要用于通知终端使用指定的Walsh Code和指定的载频。

这里主要是要尽量避免跨载频的分配产生;如果跨载频的分配无法避免,应尽量减少跨载频分配失败,避免跨载频TCCF。

➢Traffic Channel Acquisition by Mobile and Cell
这里是大量TCCF产生的阶段。

当手机收到了CAM消息后,就开始将按照指定的载频和Walsh码进行信号调制,并且成功获得基站发送的空数据。

这时手机就会发出一个业务信道探针,基站必须能够应答该探针才能结束这个阶段。

这个过程中的任何一次失败,都会产生一条TCCF纪录,通常是TCCF2或TCCF1,不过一般超过80%的TCCF都是TCCF2。

主要有如下这些因素可能会导致失败:
1. 基站按照系统定义的功率发送空数据的时候,发射功率不足以抵消干扰带来的影响,
从而导致手机无法成功获取基站发送的空数据,这时候会产生TCCF;
2. 手机最初起呼的导频不再是主导频,按照IS95A的标准,手机在整个起呼过程中仍
然必须驻留在该导频上,这时其他导频对其就会形成强干扰,从而导致TCCF产生。

3. 起呼区域内业务量高或者导频污染严重会导致干扰水平较高,导致业务信道或寻呼
信道无法克服干扰,导致TCCF产生。

4. 高的路径损耗,可能导致各个信道无法支持呼叫建立,通常是由于无线信号覆盖不
好或室内覆盖不足。

因此我们的主要优化手段包括了:
▪参数nom_gain的设置对TCCF十分关键,如果设置过低,会导致手机无法成功获得业务信道,放弃呼叫尝试,产生TCCF;如果设置过高,会导致系
统容量下降。

▪减少不必要的软切换区域:
▪避免越区覆盖
▪控制高负载的小区,特别是那些忙时TCCF显著升高的小区
▪避免导频污染
➢Final Handshake to Confirm Service Option and Service Connection
在最后的服务协商(Service Negotiate)阶段的失败,会产生TCCF7(Service Negotiate Failure)。

在基站收到SCCM(Service Connect Compete Message)消息之前,可能会由于无线链路的问题,产生TCCF3。

不过这个阶段的TCCF3应该比较少,因为经过Traffic Channel Acquisition阶段后,无线环境的问题已经被大多排除了,而且SCM和SCCM消息交换前,终端已经可以进入软切换了。

这一阶段的优化主要是确保交换机上的Service Option设置正确,对于TCCF3而言,其优化手段和Traffic Channel Acquisition阶段一样。

除了以上各个阶段的优化建议外,提出了一些新的Feature用来改善接入过程,包括了AEHO,AHO和CAMSHO。

2.1.1.2 系统硬件资源或功率资源限制导致的呼叫建立失败分析
这一类呼叫建立失败包括了以下三种情形:
➢CEBlocking
➢Forward Power Resource Blocking
➢Reverse RF Loading Resource Blocking
在呼叫建立过程中,只有基站的硬件资源以及前向和反向功率没有过载的条件下,系统才会下发Channel Assignment Message,对应的RF Assignment计数器开始进行计数统计。

我们在这一部分将主要讨论,这一类资源限制导致的呼叫失败的原因以及解决的方法和优化的建议:
1. CE Blocking
首先我们应该确保目前网络中资源是合理配置的,需要遵循以下的一些基本原则:
➢确保不同的载频上的分配了与各载频话务量对应的CE信道数目;
➢经常检查小区的CE信道的最高占用数目(比例);
➢保证硬件设备的及时升级或更新;
➢确认拥塞小区是否使用了VvsD的Feature,如果使用了,确保参数设置合理,并经过了优化。

除了以上的一些基本原则需要注意外,我们还将分析资源拥塞的其他可能,以及解决方案:
➢基站的硬件资源满负荷占用:
这时新的呼叫发起后,基站将按照一定的算法对其分配用于业务信道的信道资源,如果没有空闲的资源可用,那么该呼叫就会被拥塞。

一旦发现这类问题,通常表示硬件设备资源缺乏,需要通过新增资源来解决这类问题。

如果是由于硬件上软件版本所支持的CE数目低,建议立即更换硬件,升级软件来解决。

一般现在对通过CE Pooling,实现了不同扇区上CE的共享,避免基站上个别扇区由于负荷高导致的CE Blocking。

➢硬件故障:
如果CCU,CDM/CCC中任何一个硬件出现故障,均会导致可用的CE数目下降,从而可能会导致CE Blocking。

一般可以通过OMP上的ECP Control&Display page来观察这类问题,也可以通过ROP 中的HEH信息来发现这类问题。

如果硬件运行不稳定,可能从ECP Control&Display界面不能发现问题,那么必须通过ROP中的HEH信息来发现这类问题。

由于这是硬件问题,我们需要将这类问题提供给基站维护工程师。

2. Forward/Reverse Power Resource Blocking
这类问题出现发生在基站处理呼叫申请时,没有足够的前向功率资源来支持呼叫,通常可能是由于前向功率过载。

和前向功率过载类似的是,反向链路同样会出现由于反向功率过载导致新的呼叫或切换要求被拒绝。

对于前/反向功率过载,短期内,我们通常会采用天线调整(方位角,下倾角以及天线型号)和参数(功率衰减参数,切换参数等)来降低高负荷小区的负荷;另外可以调整过载控制算法中的门限设置,不过通常不推荐,因为这种方式没有根本解决功率过载的问题,只是推迟了功率过载算法发生的时间。

长远考虑的话,会建议新加载频或者周边新增基站来解决前向过载所带来的问题。

我们下面具体讨论各种导致前/反向功率过载的可能原因及其解决建议:
➢扇区达到其最大容量限制:
当一个扇区上所有载频上可用的前向链路或反向链路功率全部被占用,那么新的呼叫或切换就会被拒绝。

一般会表现为基站的所有扇区的话务量都非常高,并且所有载频上的话务量十分近似的
时候。

这类问题就是前面提到的短期内通过天线和参数调整来优化,长期考虑新增载频和基站来解决。

➢过大的软切换区域
切换区域过大,过多的不必要的软切换同样会占用前向链路/反向链路的功率分配,使得前向/反向链路功率更容易出现过载。

从Service Measurement中的切换比例以及Homax体现出来的越区覆盖类的问题可以发现这类问题。

建议通过优化减少切换区域。

➢VAF设置不合理
对于某些特定型号的功率放大器,可能某些参数设置会导致在正常的话务量的情形下,出现前向功率过载控制。

我们需要检查每扇区每载频的最高话务量和最大功率,检查各扇区性能指标,确认不同放大器的参数设置。

3. Call Setup Failure 的呼叫建立失败分析
这一类Call Setup Failures在正常系统中应该是很少的,因此如果小区上突然出现大量的Call Setup Failure,我们需要通过ROP的记录来确定问题。

➢Call Shutdown (CS-[43])
这类CS[43]的失败通常只与CCC(CDMA Cluster Controller –主控板)故障有关,一般表现一个载频的所有扇区的Call Setup Failure突然显著升高。

解决方法:可以通过交换上restore这个CCC,如果不能恢复正常有必要去现场进行诊断或更换硬件。

➢Call Shutdown Type10 (CS-[10])
如果切换过程中由于Unanswered 状态导致失败,会产生CS[10],在Service Measurement中记为一个Call Setup Failure。

除了Service Measurement中Call Setup Failure可以参考外,在ROP中的Unanswered Origination or Termination states 下记为Call Shutdown Type 10。

解决方法:由于绝大部分CS[10]表现为CP Fail Drops,因此解决CP Fail Drops问题能够改善CS[10],从而改善Established Call Rate。

CP Fail Drops主要是Handoff (HO) Complete Timeouts ,即在切换过程中的掉话。


部分内容需要参考Drop Call Rate的分析部分。

2.2 掉话率分析
2.2.1 掉话率改善指标思路
根据平时的工作经验,在研究掉话率问题时,主要的目标是放在尽可能的减少分子中各计数器的数值,即减少掉话个数。

而分母中的一些计数器则牵涉到话务量,和呼叫建立成功率。

一般来说,对于网络主要指标的改善都可分为3大步骤:
•问题定位
•原因分析
•针对原因的改善措施及实施
以下,我们分别就针对掉话率的改善,具体说明一下,在每个大步骤中,具体需要作一些什么样的工作。

我们将会采用提一系列的问题,并介绍一些如何回答这些问题的方法来逐步阐述改善指标的主要思路和方法。

➢问题定位
在这个阶段,优化人员主要的工作是回答下列一些问题:
1.关于掉话率,网络的现状如何?
2.掉话率整体较高还是局部(部分基站,扇区)较高?
3.掉话率高的扇区有无地域特性,或其它规律性?
4.掉话率持续较高还是突然变化?
以下,我们将分别介绍回答每一个问题时可以进行的工作:
1.关于掉话率,网络的现状如何?
•定义研究范围,单位
2.掉话率整体较高还是局部(部分基站,扇区)较高?
•依据经验判断整体掉话率或每个ECP的掉话是否偏高,以及偏高的程度?
•通过分站/扇区/载频的列表初步判断对掉话率的贡献由少数基站引起还是大部分扇区全面贡献?
o判断方法:可以将掉话率靠前的若干基站或扇区的掉话数量之和除以总掉话数量的
到的比例
o也可以通过方差大小进行判断
3.掉话率高的扇区有无地域特性,或其它规律性?
•依据分站,扇区掉话率信息作Mapinfo专项地图,并观察有无地域特点,或其它规律性。

需要重点关注的特点可以包括:
o是否处于集中区域?
o是否有交换机边界的特点?
o是否有载频边界的特点?
o是否有SM相关或SM边界相关的特点?
4.掉话率持续较高还是突然变化?
•尽可能收集历史数据或向熟悉的维护人员了解过去的情况,判断是否近期突变还是情况持续较长时间。

➢原因分析与针对性措施
基于前段问题定位所得到的结果,近一步分析原因。

在问题定位阶段,我们大致可以得到几种结果:
1.掉话率普遍异常升高。

――― 通常在紧急情况下出现
2.掉话率普遍偏高,但特别突出的扇区不多,且掉话数量占总掉话数量比例不高。

3.掉话集中于一些掉话率较高的扇区,且呈一些明显规律的分布。

4.掉话集中于一些掉话率较高的扇区,但无明显分布规律。

接下来,我们即对上述每一种情况,大致说明一下它们各自不同的分析思路。

●情况一:掉话率普遍异常升高
这种情况通常在紧急状况下出现。

一般表现的特点是所有基站或大量基站的掉话率在某一时刻突然整体陡升,或从某一时间点进入一个明显的上升通道。

在这种情况下,如果确认无线环境没有突然的变化,通常原因会和系统硬件或软件的故障或更新会有密切关系。

RF工程师在这种情况下,首先应密切配合交换或系统的工程师密切注意网络的动态。

其次,可配合系统工程师,进行下列一些结果,以分析根本原因。

1.尽可能根据历史数据作出掉话率相对时间的变化曲线,以确认变化出现的确切时间点。

为迅速判断原因提供依据。

2.统计掉话数量的各相关计数器。

判断是Lostcall还是Cpfailure的大量上升。

如果
发现是Lostcall激增(这种情况较少),可考虑大面积干扰的可能性,可继续观察RSSI等相关指标作进一步确认。

如果发现是CS激增,可进行以下第三步分析
3.依据apx文件的分析,统计各种CS类型的数量。

如发现除CS10以外其它一种或多种类型的CS(call shutdown)激增,可将相应的CS类型和统计结果提供给系统工程师,以助进一步分析。

●情况二:掉话率普遍偏高,但特别突出的扇区不多,且掉话数量占总掉话数量比
例不高
这种情况,平时碰到的比较多。

多数针对掉话率进行的优化,可以归为这种类型。

在这种情况下,RF工程师可以通过以下工作,进一步进行指标优化。

1.与情况一相同,统计历史数据,以及Lostcall和Call shutdown的比例。

如发现突变时间点,可以追溯当时相关的系统操作,作为判断的依据。

同时也根据经验判断CallShutdown的比例是否合理,以及是否有较大比例非CS10的callshutdown。

如有发现,配合系统工程师尽力消除。

再进行下一步骤。

2.配合检查系统软切换,及其它种类的切换成功率,以及拥塞相关指标。

如发现切换成功率普遍较低,或拥塞严重现象,则配合系统工程师尽力排除。

3.请求系统工程师对系统告警分析和过滤,尽可能排除可能存在的其它系统问题。

4.根据HOMAX结果检查网络中邻区关系内容和优先级的合理性,以及CDHNL表中设置内容的合理性。

并作出合理调整。

5.完成上述步骤后,可继续根据情况四中的步骤,对排名较高的站作进一步的分析与改善。

●情况三:掉话集中于一些掉话率较高的扇区,且呈一些明显规律的分布
如果找到的规律与设备有关,可以顺着规律进一步,要求系统工程师一起进一步检查相关设备的状态和告警。

例如发现交换机边界普遍掉话率较高,可进一步检查interMSC切换成功率等指标,并要求系统工程师检查局间中继,系统告警等。

如发现掉话和某SM密切相关,或与拥塞相关,可继续分析相关硬件设备状态或负荷情况。

以此类推。

另一种情况是,掉话较高的区域集中与某一区域,但无明显设备相关的证据。

则可以,依据经验首先判断是否站间距造成的弱覆盖问题。

这种情况下使用PCMD工具,进一步分析掉话较为集中的地点,将会有很大帮助。

此外参照情况四的步骤作进一步分析,也会有较
大发现。

情况四:掉话集中于一些掉话率较高的扇区,但无明显分布规律
日常优化工作中,常采用Top10的方式对此中情况进行分析。

具体方法,即列出网络中指标最差的10个或是20个扇区,进行重点研究。

分析原因,加以改善。

在初步解决后在进行下10个或20个扇区的分析,循环往复,逐步改善。

针对列出的基站,RF工程师可进行下列分析工作:
1.排除硬件原因。

在ROP中,收集相关基站在一段时间内的告警或相关事件信息。

并请求基站工程师通过OMC检查相应基站的状态,告警。

确保基站正常工作。

常见的故障包括基站GPS,或时钟模块故障产生的Flywheeling告警。

2.通过指标判断基站发射功率,天馈等是否可能出问题。

通常检查天线的发射功率需要到基站上进行功率测量,或天馈测量。

但这项工作工作量较大,周期较长。

受到较多的限制。

RF工程师也可以通过一些指标分析,锁定一些较可能有问题的基站或扇区,以大幅度提高工作效率。

具体可分析的指标包括:
o基站/扇区的话务量
o每用户平均的前向功率(Average forward power per User)
o软切换比例等
这是因为,通常如果基站发射功率发生问题或天馈发生问题,导致的结果就是空中发射的功率变小,伴随出现的现象可能是基站吸收的话务量减小,软切换比例增高,每用户平均前向功率升高的现象。

因此如果和周边其它扇区比较,有上述现象发生的,或某时刻起出现逐步出现上述现象的应列为重点检查对象。

如有发现及时排除。

3.排除干扰可能性。

主要通过检查分析,RSSI,上行平均误帧率起呼成功率等指标,以及配合直放站资料进行分析。

其中覆盖区域内存在的直放站和干扰源的排除是关键。

4.排除不合理参数设置。

常见的包括检查PN设计,切换参数设置,搜索窗设置,接入参数设置等。

RF工程师应根据分析小区的覆盖目标区域,基站数据库中站址位置,站高,天线方向等信息综合判断基站参数设置是否合理。

RF工程师同时也应对常规的系统参数有较全面的了解。

5.排除系统资源不足,如检查相应基站,及周边基站是否出现前向功率不足的记录。

6.检查邻区关系设置和优先级设置。

检查主要根据HOMAX输出结果以及基站数据库中的站址位置,站高,天线方向,站址周围环境照片等信息。

检查的目的是发现:包括是否可能天线接反,或站高不合理,以及邻区关系添加是否合适,优先级是否正确等内容。


要时,可上站检查。

7.过滤APX文件中相关扇区掉话记录,分析MIN号规律。

必要时,进行电话访问。

这项工作可以帮助排除手机问题可能造成的高掉话率问题。

以及精确定位产生掉话的具体位置。

8.改善导频污染。

在通过所有上述检查和调整步骤后,仍未明显改善的可继续考虑采用PCMD工具对可能产生掉话的区域加以初步定位,并配合路测数据。

调整天馈,功率改善导频污染。

9.经过天线的合理调整,以及路测数据额各方面数据的研究,对于由于具体原因仍无法改善的区域,进行必要的说明和准备相应的加站,加室内覆盖或加直放站方面的建议。

2.3 拥塞率分析
拥塞分析的主要目的是寻找网络瓶颈,从而进行针对性的扩容,提高网络性能。

对于RF而言,以下将拥塞分析可分为语音部分和数据部分。

目前1x数据业务已经很少了,这里主要集中于语音方面的常规分析。

在CDMA网络的众多拥塞原因中,无线方面主要可分为基站资源CE,基站前向功率,基站反向噪声负荷,Walsh码等原因。

当然除了这些无线原因以外,还可能是交换系统方面其它的一些原因。

在此我们主要对无线方面的原因进行分析并讨论相应的解决方案。

1. CE不足导致拥塞
由于业务配置CE短缺,导致基站的所有载频无法支持起呼或软切换请求,从而使该起呼或软切换请求拥塞。

➢CE资源阻塞原因及解决建议
1)硬件资源故障,更换硬件
2)基站容量资源的缺乏,扩容CE
2. 前向功率资源拥塞分析
由于前向功率负载,没有足够的前向功率资源来支持起呼,从而导致扇区拒绝终端呼叫请求,引起拥塞。

➢向功率资源阻塞原因及解决建议
1)扇区达到了极限容量
确认方法:
表现为该扇区的所有载频承载着很高的话务量;软切换比例/更软切换比例都相对较低;如果是一个扇区中几个载频业务较高或功率过载,不能说是真意义上的功率过载,更多可能是由其他问题引起,如基站的配置或硬件。

解决方法:
A.天线的调整(方向,下倾角,天线类型等);
B.过载门限参数修改---该方法不推荐,只能作为最后的调整手段(因为该方法并非是从根本上解决问题,仅仅是延迟了问题的发生);
C.加载频;
D.加站。

2)过多的软切换
确认方法:
软切换比例较高:可以通过分析软切换比例;越区覆盖:可以使用Homax或路测来有效的分析越区信号。

解决方法:
A.天线的调整(方向,下倾角,天线类型等);
B.修改BCR/CBR的参数,降低功率;
C.使用BAHO软切换功能;
3. 外部干扰
对与外部干扰表现为反向负载不高,但基站RSSI较高,手机不能正常通话,会出现手机信号很好,但不能正常接入网络或通话断续极易产生掉话现象。

解决建议:使用频谱分析仪排查,找出干扰源,协商处理。

相关文档
最新文档