TOP小区处理流程总结1TOP小区处理流程及整体处理情况1.1 TOP小区分解TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。
1. 2 问题处理流程TOP小区问题处理流程中，原因分析是流程中的关键点和重点。
2无线接通率TOP小区分析处理无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB建立成功率两块进行分析。
RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。
每次RRC和RAB建立失败，话统都会输出一个失败原因统计。
2.1RRC建立失败处理2.1.1RRC建立失败原因RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。
表3是RRC建立失败的对应原因打点。
表4为RRC失败对应的原因分析。
表3：RRC失败原因打点表4：RRC失败对应的原因分析2.1.2RRC建立失败处理1)拥塞在RRC建立出现拥塞时，可以进行下面的操作：✓将主要业务的RRC建立在公共信道上，修改命令行为：✧主叫流媒类体RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH；✧主叫交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH；✧主叫背景类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH；✧终止流媒体类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH；✧终止交互类RRC建立在FACH上SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH；✧终止流媒体类RRC建立在FACH上RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH；✧去附着信令承载建立在FACH上SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH；✧注册登记承载在FACH上SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH；✓提高拥塞小区的最小接入电平，限制部分低电平用户的接入：修改命令：MOD CELLSELRESEL: QRXLEVMIN=-96；✓打开LDC开关；✓对于业务量持续较大的小区，可以考虑建议扩容。
2)RL建立失败针对RL建立失败比较多，可采取下面的措施进行处理：✓首先确认Node B小区运行是否正常，小区载波的运行状态，检查告警信息，检查是否存在小区退服、GPS失步或者公共传输信道不可用等告警，如果存在首先进行处理。
✓现场复测，分析Radio Link Setup Failure消息，定位失败原因，针对失败原因进行相应的处理；✓检查DOFFC开关，保证关闭；DOFFC是专用信道偏移开关，用来交叉错开帧号，由于功能还不好用，都建议关闭；✓分析是否属于产品问题，请产品帮助定位解决。
3)无应答针对无应答问题，可以进行以下的处理：✓查看上下行ISCP值，确定和处理干扰问题；✓增大上行干扰余量ULINTERFERESV，该值用来调整和计算上行期望接受功率的大小，间接提高SRB/RB建立时上行期望接收功率；✓对于由于系统间重选导致的大量RRC失败，可以提高最小接入电平QRXLEVMIN或者降低空闲异系统重选门限IDLESEARCHRAT，使用户尽量驻留在T网。
4)FP同步失败FP同步失败可能的原因：✓可能是Iub接口传输层配置错误；✓或者Iub接口的接线存在问题，导致FP同步失败；✓或者Iub带宽配置错误，在Iub接口出现拥塞；可能的大都是产品故障，提交产品维护部进行解决；在出现FP同步失败问题时，提交产品维护人员处理。
5)AAL2建立失败出现Node B和RNC两个网元的传输层参数配置不一致的情况，导致出现RRC建立失败TOP小区。
✓首先确认AAL2的参数配置是否正确；✓检查RNC和NodeB侧的PATH ID配置是否一致；检查RNC和NodeB侧的PATH ID配置是否一致。
2.2RAB建立失败处理2.2.1CS RAB建立失败原因CS RAB建立失败的原因可以通过RAB原因统计的细化Counter进行确定。
表5是CS RAB建立失败的对应原因打点。
表6为CS RAB失败对应的原因分析。
表5：CS RAB失败原因打点表6：CS RAB失败对应的原因分析2.2.2PS RAB建立失败原因PS RAB建立失败的原因可以通过RAB原因统计的细化Counter进行确定。
表7是PS RAB建立失败的对应原因打点。
表8为PS RAB失败对应的原因分析。
表7：PS RAB失败原因打点表8：PS RAB失败对应的原因分析2.2.3CS/PS RAB建立失败处理1)最大速率不支持在出现因为最大速率不支持导致PS域RAB建立失败时，占用的比例过大，可采用下面的措施进行优化：✓调整下行的最大初始接入速率，使接入的时候避免RAB拥塞；✓调整金/银/铜用户的保证速率，使大速率的PS用户如384K用户不至于由于超过满码道而导致接入失败和掉话的其它问题，将其最大初始接入速率调整为128K；✓针对不支持R5业务的数据卡，不能配置为大速率的上行数据业务。
2)无可用资源/拥塞无可用资源，先要确定，是否存在码资源拥塞情况，或是通过查询IUB口传输资源配置情况，分别进行处理。
码资源拥塞处理：✓针对TOP小区，查看载频和相对应的DSP使用情况,确定载频状态正常；✓对比小区业务量,如果发现是因为业务量过高导致，可以适度提高“最小接收电平/QRXLEVMIN”，减少部分用户接入；✓调整上下行最大初始接入速率，“ULBETRAFFINITBITRATE”和“DLBETRAFFINITBITRATE”，如果H业务上行码资源受限，可是将上行初始接入速率降到16K；✓根据拥塞用户的下行传输信道类型确定拥塞用户中H和D的用户比例，如果是D用户拥塞较多，可以限定金银铜用户的最大速率；如果是H用户较多，可以针对个别小区扩容一个H频点，但要注意扩容H频点对周围小区的干扰；✓)如果是H用户，建议将H频点的最大接入用户数设置为频点码资源最大能力，不建议设置超过最大能力的值。
现网绝大大多数的H载频设置的最大用户数仍为8，可以将该值设置为7、或者6；✓RRC信令连接建立建立在FACH上面，减少由于随机接入如注册、附着、短信等占有DPCH信道的专用码道资源。
IUB口带宽拥塞处理：✓查询IUB口传输资源配置情况，是否存在资源配置不足情况；另外通过查询告警信息，确定是否存在E1/T1告警，导致可用E1/T1减少；✓话统Counter无法打点，IUB口带宽拥塞的打点可以通过PCHR定位，并且带宽拥塞特征是某个基站下所有小区都有所体现。
RAB异常错误编码CountNBM_CRA_CELL_RR_IUB_DL_FAIL(168724457) 59✓确定E1/T1资源不足或者E1/T1告警，需推动E1/T1扩容或者告警处理。
3)UE无相应✓跟踪用户CDT定位问题，确认RNC是否收到UE上报的RB配置完成消息；✓观测TOP小区的上下行干扰水平，避免由于个别小区干扰较大导致UE无相应；✓如果存在弱覆盖，优化重选参数，使UE尽快选到信号更好的小区；✓提高上行干扰余量“ULINTERFERERSV”，以增大开环功率；✓确定是否由于问题终端导致。
2.3接通率TOP小区一般处理过程1)查询和分析TOP小区的话统，确定是RRC建立成功率问题还是RAB建立成功率问题，并通过对应的话统原因Counter，确定失败的原因类型，以便下一步的分析；2)查询TOP小区是否存在告警或者故障：特别注意驻波比告警和载波是否可用，GPS告警（GPS失步）是引起上下行干扰的重要原因，这些告警将严重的影响RRC建立成功。
3)上下行干扰：上行干扰可以通过后台查询和统计上行ISCP值状态，如果出现较大的波动或者持续大于－95dBm以上，可以确定存在上行干扰，需需要对干扰进行分析；首先，进行对问题小区的频率和扰码进行分析，是否同频、同扰干扰；其次，需要现场进行测试核查，是否存在较大干扰源，特别地，对于室内分布系统，需要排查分布系统是否存在干放和合路器，干放及合路器问题通常是重要的上行干扰问题源；下行干扰，可以通过现场测试，通过C/I状况进行确定，频率、扰码分析是重要的手段。
4)无线环境因素：PS业务主要在室内使用，如果没有分布系统，室外站点的PCCPCHRSCP的接受电平相对较低，或者直接是弱覆盖，是RRC的建立成功的直接原因，因此，可能要提高PCCPCH功率，或者调整最小接入电平QRXLEVMIN（将此部分用户迁移至覆盖更好的2G系统）；5)针对现场测试和后台分析，可以通过调整部分参数，提升RRC/RAB成功率。
3无线掉线率TOP小区分析处理3.1CS掉线处理3.1.1CS掉线话统打点原因CS 掉线的原因可以通过话统原因统计的细化Counter进行确定。
表9是CS掉线的对应原因打点。
表9：CS掉线的对应原因打点3.1.2CS掉线原因分布全网的CS掉线的主要原因是：✓RL失步；✓SRB复位；✓UE侧信令释放；✓UE RB重配无响应。
CS掉线的TOP小区的主要问题原因集中于RL失步和SRB复位。
RL失步：RNC收到NodeB上报的RL Failure，RL失步的判断机制为处于CELL_DCH状态的UE，NB检测到上行连续接收到来自物理层的NOUTSYNCIND 个连续”our of sync”指示时，启动定时器TRLFAILURE ，在此过程中若连续接收到来自物理层的NINSYNCIND 个连续”in sync”指示，TRLFAILURE停止，否则TRLFAILURE 超时，视为无线链路失败。
NB发起Radio Link Failure Indication过程，RNC等待IUCSRELNORABTMR超时发起Iu release request，请求释放Iu连接；SRB复位：SRB复位是针对使用AM 模式的SRB而言，在RLC AM模式下，当某个PDU 经过Max_DAT-1 次重传后，都没有成功发送，发送端上报RLC不可恢复错误，RAB 释放。