TD网络TOP小区处理指导书

TD-SCDMA TOP小区处理指导书目 录第一章 概述4一、TD网络建设4二、TD优化遇到的挑战4三、TD网络关注指标4四、关于处理流程的说明5第二章 后台分析方法介绍（CT）6一、后台信令文件的获取6二、后台文件分析8第三章 CS域掉话处理12一、CS域掉话处理流程12二、CS域掉话（弱覆盖）12三、CS域掉话（导频污染）15四、CS域掉话（邻区设置不合理）17五、CS域掉话（UP干扰&切换失败）20六、CS域掉话（扰码&频率）22七、CS域掉话（功率设置）25八、CS域掉话（终端问题）27九、CS域掉话（其他）29第四章 CS域无线接通率处理31一、CS域无线接通率处理流程31二、CS域无线接通率（微蜂窝干放）32三、CS域无线接通率（资源不足）35四、CS域无线接通率（高话务拥塞）37五、CS域无线接通率（设备故障）39六、CS域无线接通率（UP干扰）42七、CS域无线接通率（弱覆盖）42八、CS域无线接通率（参数设置）43第五章 系统间切换成功率处理45一、系统间切换成功率处理流程45二、系统间切换成功率（终端问题）46三、系统间切换成功率（邻区设置）48四、系统间切换成功率（2G高话务）50五、系统间切换成功率（2G邻区参数配置）50第六章 UE测试和CT联合分析53一、掉话类案例53第七章 结束语58第一章 概述一、TD网络建设 北京的TD网络已经进行到三期建设阶段，同时网络覆盖基本成形，业务量稳步上升，从原先的少量用户，到目前大量的数据用户和个别热点地区的语音用户，这个我们网络优化部门提出了新的调整，我们的重点也逐渐的从关注网络覆盖方面慢慢向关注网络指标和优化方面过渡。建网初期，TD网络用户少，关注KPI指标不够，同时也意义不大，少量的数据对于统计的分析毫无意义，但是现在PS业务的突飞猛进，同时还有象鑫隆百货2小区全天88erlCS话务量的热点地区。所以KPI的优化工作应该提到议事日程上来了。二、TD优化遇到的挑战TD网络建设从2007年开始到现在刚2年的时间，对于TD优化工作，特别是性能KPI优化，也才刚刚起步。而且没有国外的现行经验供参考。这给我们从事TD网络优化工作的工程师提出了更大的挑战。TD产业起步较晚，从系统设计到产品成型，再到网络商用，加起来还不到5年，这个经历了10多年的WCDMA无法相比。所以在日常优化中也不可避免的出现设备BUG和终端问题，这就给我们提出了更高的要求，我们在分析问题需要多一个心眼。加入TD阵营快4个月了，有幸在这四个月中，从事北京TD TOP处理工作，从中总结了一部分案例和经验，同时也从中兴通讯工程师那边学习了不少经验。这里迫不及待的总结给大家共享。希望大家一同讨论，一同进步，为了东南的TD网络质量的提高贡献能量。三、TD网络关注指标现阶段我们关注的指标：CS域掉话率 CS域无线接通率 CS域系统间切换成功率 PS域系统间切换成功率这些指标网络部会每月提取全网TOP50小区做为关注和处理的重点，需要将处理结果反馈网络部。后期根据网络的发展可能会出现新的关注指标需要大家优化，此次文档首先针对现阶段关注指标做出总结，今后如有增加，再更新版本。四、关于处理流程的说明3G网络各单元接口统一，所以协议的内容大致相同，且多数厂家支持异常信令记录功能，这个我们TOP小区处理提供了强有力的工具，这个2G的处理流程不同，2G小区处理是后处理，为了找到问题原因往往需要使用试探法。而3G的问题小区处理流程却可以有所不同，我们可以直接找到问题的根源，这就是信令分析的方法。下面的处理流程大致只是进行了原因分类，并没有做事的流程，因为根据信令大家都能基本确定问题原因，不需要再去试探。另外，针对每个原因，都列举了相关案例，供大家处理TOP小区时对应参考。第二章 后台分析方法介绍（CT）一、后台信令文件的获取单击“开始”菜单，选择“运行”： 在弹出的对话框中写入相应RNC地址：例如RNC7地址，写入地址后“确认”确认之后会显示对应RNC的界面，因为我们将“CTbakeup”文件夹设置为共享，因此可以直接显示出来。其中我们会看到“CTbakeup”文件夹，其中包含本RNC中所有有问题的信令CT文件，但要注意：RNC3， 4，5，中要找CT文件时，需要双击NetNumen-TOMC文件夹，：双击“ums-svr”找到：双击打开，我们也会发现：“CTBAKEUP”（CT备份文件夹）。打开后如图：我们可根据掉话时间，用户IMSI，及掉话RNC在所有CT中找到用户在3G网的对应时间点的掉话信令，我们将其复制到自己机上。然后解压，打开“信令工具”分析。二、后台文件分析1、运行runsignal，打开*.std或CT信令（如果是*.csv文件需要通过“sbcx查询结果”转成runsignal支持的数据格式）；2、筛选去除内部交互信令，简化信令：通过“历史数据查看”打开CT数据后，信令格式如下：(10万行一个文件)这里的信令很多，包含了RNC内部交互信令。因此，过滤掉这些内部交互信令，可以简化信令，如下所示：（右键选择）简化后的信令如下：3：统计CT中各 消息名称 数量，总体上了解一下异常信令组成情况：通过信令数据统计，可以大概了解KPI指标异常主要是哪些消息类型引起。4、按照最差小区发生的时段，找到该小区所在的异常信令。例如问题小区为2513，发生时段是23：0024：00，如下：例如：分析掉话问题，寻找掉话信令点，可以刷选“消息名称”中的“IuReleaseRequest”,如果筛选条件多的话，可以使用与关系同时刷选。5、分析最差小区信令终止点（按照类型区分，呼通率为RRC连接失败，RAB指派失败/掉话类为RAB释放/切换类为物理信道重配失败），以该信令作为分析起始点，首先向上看信令寻找失败原因。建议从本次呼叫的起始信令开始。从起始信令可知，该起呼的业务类型和起呼的RSCP，而下面的信令则可知道是业务速率，分配的频点和时隙等。详细可参看 信令包含内容。6、可采用对比分析的方式，如为知道某UE是否在所有小区都存在问题，可双击“UEID”，会出现“是否排序”的询问。如下图：7、对比正常信令，看问题信令的代码含义，如下图所示：第三章 CS域掉话处理一、CS域掉话处理流程 1、CS域掉话率高：一般为TOP小区，新技术中心定期公布，同时东南也可以按照东南区域随时提取掉话率TOP小区； 2、单小区KPI统计，主要包括掉话率，RAB Assign，IuReleaseRequest，以及和切换相关的，最好按小时统计，这样可以确定掉话比较严重的时间段，方便CT文件的提取； 3、根据CT的分析，基本能够确定掉话的原因，对于一些难以判断的问题点，还需要结合路侧中UE上报的信令一同分析，以最终确定问题原因； 4、按照日常处理的经验，掉话的一些原因值主要分为了如上图所示的10大类，其中将设备原因或者GPS故障等归纳到“其他”中。二、CS域掉话（弱覆盖）1、问题现象KPI：RNCCELLIDCS CDRRAB SuccessIuReleaseRequest17671412.24%9812CT分析无线链路失败导致掉话，失败原因：RadioLinkFailureIndication（同步失败），此原因多和覆盖相关。此案例中UE未上报Measurement Report消息，检查周边邻区设置正常，因此周边应该没有信号更好的小区，同时查看RRCConnectionRequest消息可以知道服务小区的RSCP值一般都很差。还有一种情况，UE上报Measurement Report消息，从该消息中可以发现无信号强小区，从而导致切换超时失败，该类问题的原因也是弱覆盖。另外，还可以通过KPI统计中的RRC请求RSCP电平分布确认该小区的起呼场景电平。服务小区 IDRRC连接请求次数，RSCP-95dbmRRC连接请求次数，-95dbmRSCP-90dbmRRC连接请求次数，-90dbmRSCP-85dbmRRC连接请求次数，-85dbmRSCP-80dbmRRC连接请求次数，-80dbmRSCP-75dbmRRC连接请求次数，-75dbmRSCP-70dbmRRC连接请求次数，-70dbmRSCP-65dbmRRC连接请求次数，-65dbmRSCP6714219327614806683749961969869327可以看出-85dBm以下，RRC请求的概率占到40%，且-80dBm至-85dBm之间所占比例过高，可见覆盖并不理想。另外，如果该区域不存在强小区或者未配置强小区作为邻区，UE在弱覆盖情况下就会出现CellUPdate的情况。2、解决措施A、了解客户可能发生位置，有重点地加强覆盖；B、天线调整，减少覆盖区域，从而加强覆盖区域的信号；C、对于缺站区域，提交新建议，建设新站点或者新建微蜂窝站点；D、通过3/2G切换设置，规避弱覆盖带来的影响；E、对于建站困难区域，可以通过天线水平波束设置，加强覆盖；F、对于调整困难的站点，可以通过参数调整规避问题，例如：QOffsetSN或者CIO避免在弱覆盖小区占用过多。注：3db水平波瓣的宽度是网优工作中经常需要调整的重要参数。在110b（BBU的版本）之前，由于广播信道水平波瓣宽度90度时天线是等幅， 而水平波瓣宽度65度时天线是非等幅的，且没有进行功率补偿，因此，90度时的天线法线方向的功率强于65度。而110b版本之后，TS0权值无论多少度都采用了非等幅权值并且进行了功率补偿,因此在法线方向的增益30度大于65度大于90度大于120度。三、CS域掉话（导频污染）1、问题现象在CDMA系统中，引入了一种干扰叫多址干扰，这是和码相关的，所以控制覆盖成为CDMA系统优化的一项重要作用。过覆盖往往会导致导频污染现象，其特征就是，没有一个明确的覆盖小区，且小区信号之间差别不大，即没有明确覆盖小区。KPI统计：日期时间粒度TD RNC 管理网元服务小区 IDRRC连接建立成功率无线接通率小区电路域掉话率电路域RAB指配建立成功的RAB数目(个)RNC请求释放的电路域RAB总数目(个)2009-06-2224小时RNC17301553.57%57.22%100.00%132009-06-2324小时RNC17301562.34%56.76%66.67%642009-06-2424小时RNC17301562.78%58.02%0.00%012009-06-2524小时RNC17301560.95%44.12%100.00%112009-06-2624小时RNC17301567.86%68.78%25.00%412009-06-2724小时RNC17301584.68%76.01%54.55%1162009-06-2824小时RNC17301556.44%58.86%100.00%242009-06-2924小时RNC17301534.69%43.75%100.00%142009-06-3024小时RNC17301573.48%75.23%100.00%392009-07-0124小时RNC17301572.41%60.96%100.00%12在测量报告里发现该区域导频污染严重C/I差导致切换频繁，且切换链复杂。上面截图可以看出扰码36、112、95、76、85几个小区的RSCP分别为-71dbm, -68dbm, -71dbm, -73dbm, -68dbm。已经完全满足导频污染定义的4个或者4个以上小区大于-85dbm且最强和最差小区相差小于6db的要求。实际布点图：2、解决措施A、天线方位角调整，减少对同一地区的覆盖；B、天线下倾角调整，对于基站安装过高，或者空旷站点，且又不想让该站覆盖的，需要调整天线下倾角；C、加强覆盖，明确需要覆盖该区域的小区，加强该小区在该区域的覆盖（如：增大功率），同时是进行天线调整，或者新建站点，将其他小区在此处的覆盖降低。四、CS域掉话（邻区设置不合理）1、问题现象KPI:RNCCELL IDCS CDRRAB ASSIGNIU Release17182750.00%126查看当日的CT可以看出UE上发的测量报告中目标小区的RSCP=-100dbm已经很差了。由于弱场UE和目标小区上行同步失败，而在原小区的下行也已经失步了，物理信道重配置下发10S后IU口释放（定时器到时），导致掉话。失败原因为UE超时，RNLC_UE_Operate_Timeout(192)。可以发现这类问题，如果周边有强信号，但是测量报告未上报，可见邻区漏配。基站布点可以发现可能由于新开站点，所以该区域邻区设置不合理。需要进行邻区优化。2、解决措施A、使用扫频仪和UE联合测试可以在日常优化中发现这类邻区漏配的情况；B、经过邻区优化和整理可以解决这类问题带来的掉话；C、可以从测量控制消息中的邻区列表判断邻区是否漏配。五、CS域掉话（UP干扰&切换失败）1、问题现象日期RNCCELLRRCREQ无线接通率小区电路域掉话率电路域RAB指配建立成功的RAB数目(个)RNC请求释放的电路域RAB总数目(个)2009-07-07RNC170663683.27%80.79%4.81%10452009-07-08RNC170663642.12%29.73%9.48%116112009-07-09RNC170663662.17%52.40%6.58%7652009-07-10RNC170663636.43%27.77%10.34%8792009-07-11RNC170663663.95%79.28%9.16%131122009-07-12RNC170663671.71%83.69%8.41%10792009-07-13RNC170663634.12%27.70%0.00%6402009-07-14RNC170663686.60%75.81%8.45%7162009-07-15RNC170663642.45%42.24%7.04%7152009-07-16RNC170663685.16%82.49%8.16%9882009-07-17RNC170663673.06%60.73%10.91%5562009-07-18RNC170663638.25%36.53%6.67%6042009-07-19RNC17066367.71%16.65%7.41%2722009-07-20RNC170663642.30%68.85%10.09%109112009-07-21RNC170663662.37%87.95%5.88%342RNC17_6636小区无线接通率很低，电路域掉话率半个月平均达到7.85%。从UE上发的测量报告可以看出，目标小区的RSCP约为-80左右。问题都是CS域掉话都是接力切换失败，定时器超时。IU释放原因是cause.non_Standard = RNLC_Ue_Operate_TimeOut(192)该NODEB的3个小区UP干扰严重，从网管上查看到，UP都已经偏移到53（TS1时隙）。在LMT上开启测量，可以看出在UE没有接入的情况下6636小区的TS1和TS2有时候干扰也达到-90dbm左右。另外，从RadioLinkSetRespone信令中可以看出ISCP值来判断干扰值的大小。如上图所示，ISCP=47-116=-69dBm。2、解决措施 A、目前对于干扰还不能区分是系统外干扰还是系统内干扰，我们目前能够判断干扰的方法就是从NodeB的LMT进行UP干扰的提取，前提是当前无使用用户。 B、UP Shifting的使用，通过牺牲上行容量，来换取质量；（注：新功能UPPCH与业务信道共时隙，在容量和质量上得到了弥补，但是做完UPShifting，应该要把PRACH配置到TS2上。） C、归根到底，如果是系统内干扰，还是覆盖未控制好，所以出现了Up干扰，解决的关键还是找到造成干扰的站点进行RF调整。所以可以结合现场扫频结果进行天线调整工作。六、CS域掉话（扰码&频率）1、问题现象 A 邻区同频同扰 提取5月30日的KPI指标发现主要是由于RNC15_10632 切向RNC15_1316小区失败导致该小区切换成功率很低。TD RNC 管理网元服务小区 IDUTRANRELATION IDRNC内异频接力切换出准备次数RNC内异频接力切换出失败次数，physical channel failureRNC15_管理网元(15)1063210632_460_0_15_13166258进行扰码核查发现10632的邻区黄河京都大酒店 3（10633）和华威供热厂 3（1316）同频同码，频点都是10120，扰码92。由于10632和10633共站，切换次数会比较多，而另外的小区1316同频同扰，所以出现了切换的误判断，而导致切换失败和掉话。 B、异频同扰异频同扰在多频点组网的情况下，很容易出现同频同扰的情况，例如：Cell1和Cell2同扰码，但是不同频，但是Cell1的辅载波和Cell主载波同频，这种情况也极容易导致同频同扰。 C、同频CELL IDUTRANRELATION IDRNC内异频硬切换出尝试次数RNC内异频硬切换出失败次数，physical channel failureRNC内异频硬切换出切换成功率22962296_460_0_14_150651138623.89%分析CT查看原因,2296小区切向15065小区时由于同步失败导致切换失败。观察频点发现切换失败都是由2296小区的辅频点10096切向其他小区失败的，且只干扰该频点，其他频点切换正常。怀疑该频点附近有很强的同频干扰。查看基站信息发现邻区15065小区的主频点正是10096.而且距离很近只有280米左右。2、解决措施 A、修改频率或者扰码；（建议先扰码，后频率） B、加强频率和扰码的规划和核查工作； C、规划过程中考虑扰码的相关性； D、核查过程中增加和距离相关的扰码核查。 E、对邻区进行核查，删除距离过远或并无发生切换的邻区，控制邻区数量，增强邻区配置的正确性。从以前的优化中发现，当邻区优化完后，更容易找到合适的扰码。七、CS域掉话（功率设置）1、问题现象KPI：CT分析查看CT可以看出掉话主要出现在跨RNC切换失败导致的掉话。跨RNC小区切向6583小区频繁出现切换掉话。IU释放原因是TRANAP_relocation_failure_in_target_CN_RNC_or_target_system(29)，怀疑目标小区6583参数配置有问题。 小区最大发射功率和PCCPCH发送功率都配成了37dbm，功率在CDMA系统中也是一种资源，所以功率的规划也尤为重要。该处就是功率配置错误导致信道功率不正常。2、解决措施 A、修改PCCPCH功率为33dbm； B、将功率核查作为日常工作传输信道物理信道功率配置DCH专用物理信道(DPCH)0dBBCH主公共控制物理信道(P-CCPCH)33dbmPCH辅助公共控制物理信道(S-CCPCH)3dBFACH辅助公共控制物理信道(S-CCPCH)3dBRACH物理随机接入信道(PRACH)0dBUSCH物理上行共享信道(PUSCH)0dBDSCH物理下行共享信道(PDSCH)0dB下行导频信道(DwPCH)上行导频信道(UpPCH)寻呼指示信道（PICH）0dB快速物理接入信道F-PACH0dB 如果配置三条SCCPCH， SCCPCH功率也可以设置为3（相对于PCCPCH增加3db）。因为TS0总功率为2W*8通道=16W（小区最大发射功率可以配置为42dBm），而PCCPCH=2W，SCCPCH=4W这样配置3条SCCPCH一共12W，这样配置功率没有超过总功率。 参照：在WCDMA系统中，小区载波最大发射功率一般为20W，这样小区最大发射功率为43dBm，但是和TD不同的是，WCDMA没有时隙的概念，所有的信道（包括业务信道）共用这些功率，WCDMA的PCCPCH也是配置的2W（33dBm），其他信道都是和PCCPCH的偏置。 八、CS域掉话（终端问题）1、问题现象判断掉话是否是由于终端问题引起，从CT的分析角度来看，可以进行IMSI统计，可以发现所有的失败都是由于同一个IMSI导致，而且在该IMSI无服务申请时，小区指标正常。目前在处理TOP小区的过程中发现，对于PS掉线很多是由于终端原因引起的，而对于CS掉话发现的还比较少。 所以这里例举一个PS掉线的案例，以后碰到CS掉话处理思路一样开始时间RNC IDNODEB ID本地小区识别码RNC请求释放分组域Iu连接对应的RAB数目，无线网络层原因- Release due to UE generated signalling connection release2009-08-0115951953392009-08-0215951953472009-08-03159519532402009-08-0415951953462009-08-051595195345在后台KPI指标里统计了CELL953从8月1日到8月5日，5天的指标，发现每日平均掉线次数是45次左右，只有8月3日一天掉线次数突增。开始时间RNC IDNODEB ID本地小区识别码Release due to UE generated signalling connection releaseUe_Operate_TimeOutUCIU_error2009-08-03 00:00:00159519531152009-08-03 02:00:001595195323002009-08-03 08:00:00159519534102009-08-03 09:00:001595195311112009-08-03 10:00:00159519533222009-08-03 11:00:001595195347112009-08-03 12:00:001595195359032009-08-03 13:00:001595195322012009-08-03 14:00:001595195328242009-08-03 15:00:001595195328202009-08-03 16:00:00159519532112009-08-03 17:00:00159519531012009-08-03 18:00:00159519533202009-08-03 19:00:00159519534022009-08-03 21:00:00159519533032009-08-03 23:00:0015951953102统计了CELL953 8月3日一天的掉线时间和原因，发现掉线原因主要是Release due to UE generated signalling connection release，并且时间集中在11点到下午4点。通过CT查看该时段PS域掉线原因，发现都是由同一号码460001544121632的终端频繁掉线所致。通过CT可以看出他在Iureleaserequest前，手机上发了一条signallingConnectionReleaseIndication，这样可以确定手机终端问题导致的PS掉线。而依照中兴外场测试结果此款终端为多普达S700旧版本终端。2、解决措施针对手机终端出现的问题导致的掉话，目前对于网优部门来说办法不多，除了联系终端厂家进行版本升级外，只能在KPI考核过程中剔除这部分内容。九、CS域掉话（其他）1、问题现象A、GPS问题导致CS掉话 GPS故障往往影响的不只是一个小区，而是一片区域，因为GPS失步后对于时分系统来说就是致命的，会带来交叉时隙的干扰，还有就是切换过程中的同步失败。 从CT的信令分析角度来看，切换过程中失败原因中t=2 （同步失败），另外由于干扰原因往往也会影响起呼成功率，因为在RRC建立请求时，随后的接纳控制就无法通过而拒绝。 B、设备故障 三方期间KPI监控发现广渠门附近掉话指标异常：日期RNCIDCELLIDCELLNAMECSRAB释放CSRAB建立成功CSRAB建立请求CS掉话率CS话务量07260726154845全福德烤鸭店225484952.08%0.68720726072615807环境大厦123868826.74%1.1360726072615758金桥公寓220464643.48%0.81360726072615825广渠门213525325.00%1.092207260726151376潘家园3102172214.61%6.2711 通过CT分析发现所有的IuReleaseRequest都是发生在切换至全福德烤鸭店1方向，物理信道重配置过程出现超时，问题出在这个小区上，结果发现该小区虽然公共信道建立成功，但是AAL2PATH出现问题，这样导致RL建立失败，从而物理信道重配置超时而掉话。 C、UICU_ERROR（211）在前期优化过程中发现中兴设备经常会出现UICU，现象是切换成功后过10秒左右会出现掉话情况，原因值就是：UICU_ERROR（211）这个问题出现在RNC信令处理内部，是RNC内部控制面和RNC内部的用户面交互过程中出现的错误，而且该原因值是厂家定义原因，无相关资料可查。只能让厂家研发部门定为问题。在现在优化过程中发现，此类现象不只出现在切换过程中，在单个小区正常通话中也会莫名其妙的出现这种问题。通过咨询厂家，答复可能存在3方面原因：AAL2承载没对上，用户面初始化失败，或者RUB单板出了问题。2、解决措施 A、对于设备问题和GPS故障，还是要加强维护告警处理工作，还有就是TOP小区处理过程中，要关注基站故障察看和处理，还有就是历史告警的查询和处理（因为有些故障间隙性发作）； B、对于厂家内部设备问题，需要对问题进行升级，由相关部门对该类问题进行跟踪和督促厂家产品升级。第四章 CS域无线接通率处理一、CS域无线接通率处理流程1、CS域无线接通率低：一般为TOP小区，新技术中心定期公布，同时东南也可以按照东南区域随时提取无线接通率低的TOP小区；2、单小区KPI统计，主要包括RRC请求成功率和RAB请求成功率，最好按小时统计，这样可以确定掉话比较严重的时间段，方便CT文件的提取；3、根据CT的分析，基本能够确定无法接通的原因，对于一些难以判断的问题点，还需要结合路侧中UE上报的信令一同分析，以最终确定问题原因；4、无线接通率定义： TD无线接通率=RRC连接成功率*RAB连接成功率RRC连接成功率=RRC连接成功次数（RRC Connection Setup Complete）/RRC连接请求次数（RRC Connection Request）RRC连接请求分为：业务相关（CS和PS），非业务相关（Location Update）RAB连接成功率=RAB分配成功次数（RAB Assign Respone）/RAB连接请求次数（RAB Assign REQ）二、CS域无线接通率（微蜂窝干放）1、问题现象无线接通率低KPI日期RNCIDCELLIDCSRAB建立成功CSRAB建立请求CS话务量CSRRC建立成功CSRRC建立请求CS无线接通率2009-7-13620505110.012511010.00%2009-7-14620505220.20942825.00%2009-7-15620505560.0369121376.92%2009-7-16620505560.393762718.52%2009-7-1762050515160.2458161693.75%2009-7-1862050532351.56477458.07%2009-7-1962050516220.9516326933.73%2009-7-20620505150.008961012.00%2009-7-2162050510150.7017152245.45%异常信令：rrcConnectionSetupComplete的消息很少。信号强度很好：46-115=-69dbm信令流程从流程上看，最后一步rrcConnectionSetupComplete是走得DCCH信道，即上行专用信道。所以导致RRC连接超时，或者UE发送的该条消息无法正确送达RNC。应该是干放设置问题。更换干放后的效果2、解决措施 A、现场排查干放时隙配置是否正确（2：4）；现场曾经发现有因为修改2：4未保存导致的实习配比错误，也有2：4设置成4：2导致的错误，也有干放故障导致的问题。 B、对于微蜂窝的干放问题一般都是干放问题导致，根据信令判断，如果是其它原因不应该只影响rrcConnectionSetupComplete，一般更换干放或者修改时隙配置都能解决； C、更换RRU代替干放，优点：可以监控，不存在时隙配比错误问题，供电和体积基本相同，维护成本也低，所以建议今后微蜂窝使用RRU组网，对于原先维护困难的带干放站点，可以考虑替换。三、CS域无线接通率（资源不足）1、问题现象由于资源不足导致的无线接通低主要有两种种情况：RRC请求失败，和RAB分配失败。这主要和RNC的接纳控制相关（对于TD来说，上行衡量干扰，下行衡量功率）。A、RAB分配失败RAB分配失败原因值为：RRM_PhyResourse_Shortage_Failed或者TRANAP_release_due_to_Utran_generated_reason (15)案例：RAB指标失败，由RNC发给CN，具体失败原因：TRANAP_release_due_to_Utran_generated_reason (15) 跟踪该小区的码道占用情况：由于该小区做了UPShifting，所以TS1无法作为上行业务信道使用，而单载波就剩下了TS2可做为上行业务信道（16个码道），对于码资源暂用较大的业务例如CS64K，PS64K以上，RAB建立经常会失败。B、IuB口资源不足另外，还有一种情况会影响无线接通率，那就是IuB口资源不足，这属于硬接纳的内容。我们可以从KPI里统计出来。RNC IDNODEB ID站点名称激活E1数配置E1数站点配置IuB带宽利用率Iub下行配置带宽(Kbps)实际带宽利用率166914碧海公园15S33321.04%8622100.00%612664人保大厦15S33319.70%913498.50%620637崇文区金伦大厦TDM12S247.63%366095.26%176904博大路东15S33318.67%913493.35%注意：提取力度越小越好，并且取全天最大值，IuB实际带宽需要根据配置带宽和激活带宽进行转换。2、解决措施 A、RAB失败：扩容或减小覆盖； B、IuB口资源不足：传输扩容。四、CS域无线接通率（高话务拥塞）1、问题现象A、RRC请求失败由于站点业务量较高，在RRC请求阶段通过接纳控制，直接拒绝RRC请求，失败原因为：RRC Congestion具体案例：日期RNCIDCELLIDCELLNAMECSRAB建立成功CSRAB建立请求CSRRC建立成功CSRRC建立请求CS无线接通率CS话务量2009-6-22216755通州市政管理24547394877.79%1.05232009-6-23216755通州市政管理25256528358.18%1.07872009-6-24216755通州市政管理23737282996.55%0.64762009-6-25216755通州市政管理24243385962.91%1.02862009-6-26216755通州市政管理23738414981.47%0.70452009-6-27216755通州市政管理22020202195.24%0.4642009-6-28216755通州市政管理22728264852.23%0.66542009-6-29216755通州市政管理234462917812.04%0.5404拒绝原因统计：结束时间RRC连接尝试计数器，注册RRC连接尝试计数器，紧急呼叫RRC连接尝试计数器，系统间小区重选RRC连接尝试计数器，系统间小区重入RRC连接尝试计数器，DetachRRC连接尝试计数器，呼叫重建RRC连接失败计数器，congestionRRC连接失败计数器，unspecifiedRRC连接失败计数器，NO REPLY2009-06-202530169018060072009-06-2143402150250347052009-06-22474015903102550212009-06-2326401500280500152009-06-24566022702104110132009-06-25236011501809032009-06-26494021702004050212009-06-2725401280240860292009-06-282720151031040142009-06-295620134016037509上面的Congestion并不能直接推导出导致无线接通率低，但是当我们将小区覆盖收缩后，我们发现问题得以解决，就可以证明是拥塞导致的无线接通率低。日期RNCIDCELLIDCELLNAMECSRAB建立成功CSRAB建立请求CSRRC建立成功CSRRC建立请求CS无线接通率CS话务量2009-6-28216755通州市政管理22728264852.23%0.66542009-6-29216755通州市政管理234462917812.04%0.54042009-6-30216755通州市政管理223231919100.00%0.25392009-7-1216755通州市政管理22929242596.00%0.4142009-7-2216755通州市政管理22021171795.24%0.76752、解决措施 A、扩容； B、调整天线减小覆盖； C、降低功率，减小覆盖。五、CS域无线接通率（设备故障）1、问题现象KPI：日期本地小区识别码RRC连接建立成功率RRC连接建立成功率(业务相关)CS域RRC连接建立成功率PS域RRC连接建立成功率小区RAB建立成功率电路域RAB建立成功率(C类12.2/12.2)无线接通率2009-07-10142298.86%97.80%96.12%100.00%99.48%98.98%97.30%2009-07-11142298.33%99.43%98.68%100.00%100.00%100.00%99.43%2009-07-1214224.12%6.12%7.87%5.22%100.00%100.00%6.12%2009-07-1314220.00%0.00%0.00%0.00%60.00%66.67%0.00%2009-07-1414220.00%0.00%0.00%0.00%100.00%100.00%0.00%2009-07-1514220.00%0.00%0.00%0.00%100.00%100.00%0.00%提取7月14日的CT发现无论是UE发起注册类位置更新还是RNC间的切换，RRC连接都无法建立。发起RRC连接时候的RSCP都很好能达到-55dbm左右。RNC向NODEB发起radiolinksetuprequest后，正常信令应该是NODEB向RNC发起radiolinksetupcomplete，但是却上发radiolinksetupfailure。失败原因是cause.misc = TNBAP_hardware_failure(1)。怀疑该小区硬件故障导致无线链路无法建立，但是在OMC上查看告警没有任何设备告警。查看历史告警：查看历史告警发现7月10日22点开始就有小区1422的TBPE单板链路通讯断告警导致无线链路无法建立。虽然现在没有告警，但从信令分析上来看怀疑TBPE有隐性问题。 另外，在长沙也出现过因为无PRACH信道发射功率，导致的接通率低问题，这类问题可以从路测过程中发现。2、解决措施 A、重启TBPE板件尝试； B、更换TBPE板件； C、基站硬件故障监控和处理； D、对于历史告警的查询（包括板件和GPS）。六、CS域无线接通率（UP干扰）1、问题现象 对于UP干扰主要发生在上行导频时隙，而UE都是通过上行导频时隙进行上行同步的，因此UP干扰往往会造成上行同步失败而起呼失败，但是对于KPI统计来说，还未到RRC请求阶段，因此接通率影响较小，但是如果干扰出现在上行DCCH时隙的话，那就会影响RRC Complete消息的发送（DCCH）。2、解决措施 A、KPI统计中发现接通率低，可以先进行UPshifting操作，观察效果； B、对于上行同步失败问题，需要通过UE的现场测试跟踪来观察分析； C、对于干扰影响性能的情况，归根到底还是要找到干扰源，才能对症下药。七、CS域无线接通率（弱覆盖）1、问题现象在RRC连接请求指令中会上报服务小区的RSCP值，所以KPI里面有统计：本地小区识别码RRC连接建立成功率(业务相关)RRC连接失败计数器，congestionRRC连接失败计数器，unspecifiedRRC连接失败计数器，NO REPLYRSCP-90比例876425.12%001213361.63%1128364.60%485804650.38%661662.84%1440807249.32%835465.59%3541015549.11%673239.29%43746021645.80%661862.54%4306010942.62%687657.17%11735023941.13%843461.59%7296022740.01%Cell 8764 RSCP-90dBm比例高大61.63%，而RRC失败原因都为No Reply，对于该类问题和弱覆盖有关系。而其他小区，既有No Reply又有Congestion，应该是双重原因作用。同时RSCP-90dBm的比例也较大。对于弱覆盖导致的无线接通率，从两个方面去分析，1个就是信令当中的RSCP值，另外一个就是KPI的RSCP统计。2、解决措施 A、完善覆盖； B、天线调整，降低小区覆盖范围； C、2/3G切换场景设计，避免弱场起呼。八、CS域无线接通率（参数设置）1、问题现象和无线接通率相关的几个重要参数有：A、上行UPPCH信道期望功率；B、PCCPCH和SCCPCH功率设置；C、系统定时器和计数器参数N300和T300。下面分别说明：A、对于上行UPPCH信道期望功率，是RNC发给UE的，供UE开环功控使用，优化过程中可以提高该值PUpPCH = LPCCPCH + PRXUpPCHdes + (i-1)* Pwrramp优点： 可以提升无线接通率。缺点： UE功率抬升，耗电，对其他用户就是干扰。B、PCCPCH功率设置是整个小区功率的基准，该值设置大了可以改善下行覆盖，设置小了，减小覆盖，还有SCCPCH配置为PCCPCH+3dB（原则），还有就是时隙内的所有信道的功率配置不应该大于小区最大允许发射功率。C、N300和T300的使用在北京网络已经修改，例如：N300从3到4，可以改善道路测试的感知。但是对于性能指标的统计却有恶化。所以也是有利有弊。2、解决措施A、关于上述参数的设置，建议按照参考值设置；B、如果有特殊场景需要特殊设置，也需要考虑到弊端，结合现场反复测试结果进行设置；C、对于已经带来的影响，参照上面的分析，可适当进行调整。第五章 系统间切换成功率处理一、系统间切换成功率处理流程1、系统间切换成功率低：一般为TOP小区，新技术中心定期公布，同时东南也可以按照东南区域随时提取系统间切换成功率低的TOP小区；2、单小区KPI统计，主要包括CS域和PS域的切换成功率，最好按小时统计，这样可以确定掉话比较严重的时间段，方便CT文件的提取；3、根据CT的分析，基本能够确定切换失败的原因，对于一些难以判断的问题点，还需要结合路侧中UE上报的信令一同分析，或者是2G的信令，以最终确定问题原因；（2G现在获取信令难度较大）4、切换指令： CS域：HandoverFromUtranCommand_GSM PS域：CellChangeOrderFromUtran 根据信令可以判断是CS域业务还是PS域和切换目标2G小区信号强度。注：邻区设置主要指2G邻区设置的合理性；（如：是否应该配置该2G邻区。） 2G邻区参数设置主要指邻区设置的相关参数；（如：门限，迟滞，触发方式等。）二、系统间切换成功率（终端问题）1、问题现象KPI：CT分析：问题