网络优化学习总结.docx

资源描述

网络优化学习总结.docx

《网络优化学习总结.docx》由会员分享，可在线阅读，更多相关《网络优化学习总结.docx（26页珍藏版）》请在冰豆网上搜索。

网络优化学习总结.docx

网络优化学习总结

网络优化总结

1指标和公式

1．1TCH掉话次数

1．2SDCCH拥塞次数

1．3TCH拥塞次数

1．4分配失败次数

1．5切换成功次数

2基本算法

2．1TCH分配算法

2．2小区选择和重选

2．3功率控制

2．4切换算法

3OMCR参数

3．1BSC参数

3．2小区参数

4实用点滴

指标和公式

1．1TCH掉话次数

=MC136+MC139+MC14C+MC21

MC136为射频信号丢失次数，MC139为传输波动掉话次数，MC14C为BSS问题造成的掉话次数，MC21为切换造成的掉话次数。

正常情况下，掉话主要集中在空中接口（MC136+MC21），中继链路（MC14C+MC139）造成的掉话应与之有数量级的差别。

掉话的定位一般是首先看小区的每一个TRX的平均占用时长（MC380A/MC370A），即可找出是由于某个TRX的原因或者是该小区普遍不好。

MC136的原因可能是干扰，信号覆盖不好，或者BTS的天馈系统VSWR过高造成。

在网优过程中，对以上几种原因的查找和解决方法主要为以下几种：

干扰过大。

如果网络采用BBH或未跳频，在PM报告中查看C320的分布（C320为个干扰带的分布情况）或切换cause的分布.干扰主要可从两方面来考虑解决：

在保证覆盖的前提下，加大ANT的下倾角，或者对RNP重新调整，以及检查天线的方位角。

VSWR则由硬件排障人员解决。

MC139是由于REMOTETRANSCODER引起的CONNECTIONFAILURE而造成的掉话。

如果是A口的问题，则会造成整个BSC掉话偏高；如果是A-BIS的问题，则相应的该CHAIN上的CELL掉话偏高。

在BSC的模块中，TCU，FUMO（G2），SUM，SMBI均会造成MC139的现象，这种情况往往也伴随着MC14C比较高。

遇到这种情况，在确认更换相关的模块前，先RESET，再观察是否会变好。

历次优化过程中，有部分小区的MC136偏高，经查，这些小区中有个别TRX的平均占用时长有异（MC380A/MC370A）。

关闭相应TRX后指标正常。

主要由两种原因造成：

用户定义的监控时隙与TCH或RSL冲突；在升版的过程中，一些小区的MAPING发生了错误，也产生了MC139过高的掉话。

在临汾优化的过程中，发现自3/15日下午15时起，BSC2的C139异常，达到1000多次，经信令跟踪发现系局方传输DDF架割接，造成一路PCM接头虚焊所致。

MC14C产生的原因有：

”O&Mintervention”“Messagesequenceerror”“LAPDfailure”“TCHcallreleaseinitiatedbyBSSO&MFAULTMANAGEMENTapplicationpartorbyBSSTELCOMapplicationpartastheresultofasystemdefenseactionwhichmaybeduetoBSSequipmentfailuresexternaltotheBSC（e.g.RSLfailureorCUfailure）,orduetoBSSinternalhardwareproblems（e.g.TCUfailureorDTCfailure）orduetoBSSinternalsoftwareproblems（e.g.inconsistenciesdetectedbetweensoftwaremodulesorlackofsoftwareresource（memory,timereference,filereference）orcommunicationproblemsbetweendifferentprocessorboard。

简单的说，如果由于传输的原因发生了一次掉话，如果传输迅速恢复，则MC139计数，如果在一定时间内没有恢复，则MC14C增加，如临汾优化过程中，3/16日市区发生大面积停电，造成20个小区退出服务，从PM报告上看，MC14c的掉话次数有140余次，当晚间电力恢复后，MC14c的次数又减少为2次。

MC21是切出时的掉话次数。

切换种类的有关COUNTER如下：

EXT

INT

INTRA

INCOMING

OUTGOING

INCOMING

OUTGOING

REQ

MC820

MC645

MC830

MC655A

MC870

ATPT

MC821

MC650

MC831

MC660

MC871

SUCC

MC642

MC646

MC652

MC656

MC662

FAILEXECREV

MC647

MC657

MC667

FAILEXECNOREV

MC648

MC658

MC663

MSACCESSFAIL

MC643

MC653

HOPREPDUETOCONG

MC41A

MC51

MC61

与掉话相关的COUNTER为MC648，MC658，MC663，从这三个COUNTER的分布可以看出是哪种切换造成的切换失败次数偏高。

以临汾3/9CELL3051为例：

CELL

LAC

MC136

MC139

MC14C

MC21

MC648

MC658

MC663

Cell13680_17112

17112

13680

显然，MC648是切换掉话的主要原因，因此查找该小区的EXTHO表中的邻小区，发现邻区中有一MOTOROLA小区16131的BCC实际上已经由0改为2。

更改后该小区切换掉话正常。

通常切换掉话的原因有以下几种：

●切换关系不合理

●切换关系的邻区表的数据与现网中的实际情况有出入。

●切换关系的邻区表中有多个小区有相同的BCCH和BSIC。

切换关系不合理，由RNP做出调整；若是网内的邻区数据，BSS会自动更新，若是网间数据（EXT），则由用户提供；邻区表中有多个小区有相同BCCH和BSIC的情况，可根据A口跟踪的结果对邻区表进行冗余删除。

另外，切换的cause也有以下几种：

MC670NB_HO_2_TooLowQualUp

MC671NB_HO_3_TooLowLevUp

MC672NB_HO_4_TooLowQualDown

MC673NB_HO_5_TooLowLevDown

MC674NB_HO_6_TooLongDistance

MC675NB_HO_MSC_TRIG

MC676NB_HO_15_TooHighLevInterfUp

MC677NB_HO_16_TooHighLevInterfDown

MC678NB_HO_12_TooLowPowBudg

MC679NB_HO_21_HighLevNeigCellPrefBand

MC785aNB_HO_7_ConsBadSACCHmicroCell

MC785dNB_HO_17_TooLowLevUpMicroCell

MC785eNB_HO_18_TooLowLevDownMicroCell

MC785fNB_HO_14_HighLevNeigLowCellSlowMS

MC670

MC671

MC672

MC673

MC674

MC675

MC676

MC677

MC678

MC679

MC785A

MC785D

MC785E

MC785F

查看这些counter，也可以对切换的原因作出分析，并对症下药进行解决。

同时，从这些切换的原因也可以间接评估出甚至是全网的干扰和覆盖情况。

1.2SDCCH拥塞次数

=MC8CD

SDCCH的试呼分为主叫（MC02）和被叫（MC01）。

一般来说，SDCCH的试呼大多数为主叫，主叫又分为几类：

●MC02A位置更新

●MC02B主叫短消息

●MC02C主叫补充服务

●MC02DFOLLOWON

●MC02E呼叫重建

●MC03FL3INFOUNKNOW

●MC02GIMSIDETACH/ATTACH

●MC02H呼叫建立

SDCCH的拥塞主要分为两种情况：

确实有大量的试呼次数和存在大量的ghost试呼。

实际存在SDCCH的拥塞大都发生LAC边界，主要由于大量的LU引起。

长治优化过程中发现郊区有个别CELL的SDCCH拥塞很严重，从MAPINFO上查出该站深入另一LAC内，发生了大量的LU，更改后SD拥塞情况正常。

这类SDCCH拥塞的解决办法一般如下：

1．规划合适的LAC边界

2．查看该CELL的话务量，若话务量并不高，可尽量满配置SDCCH。

3．设置相关参数。

提高最小接入电平，减小TAFILTER，增加相临CELL和本小区的CRH值，调整CRO和PT参数。

对于ghost的SDCCH试呼，有几种情况：

●若某小区的AGCH和PAGINGblock配置不平衡，会产生接入允许信息信息不能及时被MS接收到。

而MS在规定的时间内没有接受到该信息后，会再次发出channelrequired。

如此往复，就会使得SDCCH得拥塞急剧上升。

吕梁优化过程中，发现凡是1个或2个TRX的小区，大多配置为combine小区，AGCHblock设为1，造成部分小区SDCCH拥塞。

改为nocombine后，部分小区恢复正常。

●相同的BCCH和BSIC小区距离太近，造成虚假接入请求。

临汾网络优化过程中，28312小区配置为combine，拥塞严重，将其改为nocombine后，拥塞仍然无改变，后请RNP修改BSIC后，试呼次数由500多次降为50多次。

另外，在边界地区GSM信号强度的分布不同可能会造成极大的LU。

因此，应将CRH增大。

1.3TCH拥塞次数

=C181D+MC612C

C181D为A口拥塞次数，MC612C为BSS针对每个小区的统计。

TCH拥塞的原因有：

CELL的配置过小，小区覆盖过大，热点地区集中，参数设置不够合理等。

解决的方法主要为：

1.对热点地区，采用多层网（微蜂窝），平衡话务分布。

2.合理加大天线的下倾角，减小覆盖范围。

3.设置参数。

例如提高ACCESS_LEVEL_MIN，减小TA_FILTER。

若考虑到切换，还应对切换门限等加以调整。

4.开启强制直接重使试，开启tafficload切换。

1.4分配失败次数

=C181a+C181b+C181c+C181d+C181e+C181f+C181g+C181h+C181i+C181j+C181k+C181l

为A口统计数据。

1.5切换成功次数

=（MC652-C92）+（MC656-C96）+（MC642-C82）+（MC646-C86）

上式中未包含DR的次数。

MC642，MC652，MC646，MC656分别为EXT，INT，切入和切出的成功次数。

切换成功率依赖于切换关系的定义、切换参数的设置等。

切换成功率的分析，可以参考pm180报告。

后台处理可以使用Search_Bad_HORelation.xls中所包含的宏。

从切换的信令流程上看，与SDCCH试呼类似。

对于相隔不远的cell，若使用相同的BCCH和BSIC，则会产生类似GHOST的请求，这类切换一般均不会成功。

关于切换的叙述，另见CELL参数和切换关系的整理内容。

基本算法

2．1TCH分配算法

2．2小区选择和重选

GSM小区选择/重选使用的参数:

PHASE1

PHASE2

小区选择

小区重选

C1/C2（注）

注:

C1和C2的使用取决于CELL_RESELECT_PARAM_IND,当设为PRESENT时,使用C2;设为NOTPRESENT时,使用C1.

C1和C2公式

1．C1

C1=平均接收电平-最小接入电平-MAX（（手机最大CCH功率-手机最大RF发射功率）,0）

平均接收电平：

RXAverageLevel为实测的手机接收电平

最小接入电平：

RXLEV_ACCESS_MIN系统定义的最小接入电平，由系统广播

手机最大CCH功率：

MS_TXPWR_CCH手机在接入控制信道上允许的最大发射功率，由系统广播

手机最大发射功率：

MAXRFPOWEROFMS手机的最大发射功率

如果使用C1作为小区重选参数，有两种情况可使MS从原小区选择到目标小区。

一.原小区和目标小区属于同一LAC，则只要目标小区的C1值在一段时间内大于原小区即可。

二.若原小区和目标小区归属于不同的LAC，则需加重选滞后因子CELL_RESELECT_HYSELECT_HYSTERESIS（CRH）.即:

C1（目标）>C1（原）+CRH一段时间后,MS重选到目标小区.

2．C2

C2是GSMPHASE2的可选参数，仅用于小区重选，若C2未被广播，则使用C1做重选参数。

C2=C1+重选补偿参数+临时补偿参数*H（惩罚时间-实测时间）

重选补偿参数：

CELL_RESELECT_OFFSET（CRO）由系统广播

临时补偿参数：

TEMPORARY_OFFSET由系统广播

惩罚时间：

PENALTY_TIME由系统广播

实测时间：

TMS测量到某一候选小区电平值为TOPSIXCELL中最大的时间

若：

惩罚时间-实测时间>0，则H=1

若：

惩罚时间-实测时间<0，则H=0

若PENALTY=31，则C2=C1-CRO

同样，相同LAC的小区重选只要目标C2>原C2即可，不同LAC的小区重选需加滞后后因子。

使用C2的原因：

C2比C1多了两项因子，CRO和TO*H

CRO：

使用CRO可以人为的补偿某个小区的可选择性。

例如在某个信号质量好，用户又相对少的小区，可设置其CRO大一些，以便MS尽可能占用该小区。

TO*H：

TO*H的设置主要是考虑MS运动速度的补偿。

若PT设置的较小，则H为零的可能性越大，即C2=C1+CRO，被选择的可能性就越大。

这种情况比较适用于高速公路等周围的小区。

反之亦然。