TD-最坏小区优化指引

TD最坏小区优化指引（华为）目录1最坏小区定义22指标意义与定义22.1 CS无线接通率22.2 CS域无线掉话率22.3 RRC拥塞率33指标优化建议33.1 RRC连接成功率(业务相关)33.1.1 影响的因素33.1.2 涉及的参数33.1.3 优化建议33.1.4 案例33.2 CS RAB建立成功率33.2.1 影响的因素33.2.2 涉及的参数33.2.3 优化建议33.2.4 案例33.3 CS域无线掉话率33.3.1 影响的因素33.3.2 涉及的参数33.3.3 优化建议33.3.4 案例33.4 RRC拥塞率33.4.1 影响的因素33.4.2 涉及的参数33.4.3 优化建议33.4.4 案例31最坏小区定义TD 最坏小区指的是： （电路域RRC建立尝试次数（业务相关）+语音业务RAB建立请求的 RAB 数目（个） 100 且 TD 语音无线接通率50 且 TD 语音无线掉话率 5% 的小区或者是RRC 拥塞率 10% 的小区 TD最坏小区比例区域内 TD最坏小区数/考核区域内TD总小区数100 2指标意义与定义从最坏小区定义看，涉及的指标有TD语音无线接通率、TD无线掉话率和RRC拥塞率。2.1 CS无线接通率该指标衡量CS域用户接入网络的难易程度，直接影响客户拨打电话时的感知，该指标偏低导致用户接入困难，无线接入性下降等问题。CS域无线接通率= RRC连接成功率(业务相关)* CS域RAB建立成功率2.2 CS域无线掉话率CS域无线掉话率反映了系统CS域业务的通讯保持能力、通讯的稳定性和可靠性，是用户直接感受的重要性能指标之一。当系统CS域的掉话率高时，会严重降低用户对语音业务的满意度，从而导致用户投诉。CS域无线掉话率=RNC请求释放的电路域RAB总数目 / 电路域RAB指派建立成功的RAB数目*100%2.3 RRC拥塞率反映小区RRC连接的拥塞程度，该指标偏高说明客户的信令连接受到影响，将出现用户接入困难，无线接入性下降等问题。RRC拥塞率(业务相关)由于容量控制而导致RRC连接失败次数 / 按原因分RRC连接请求次数 *100%注：因为容量控制而被系统拒绝的RRC请求数量：由于容量控制的原因，UERNC：“RRC连接建立拒绝”（RRC CONNECTION REJECT ）消息，其中原因为“congestion”3指标优化建议3.1 RRC连接成功率(业务相关)RRC 连接建立可以分两种情况：一种是与业务相关的RRC 连接建立；另一种是与业务无关（如位置更新、系统间小区重选、注册等）的RRC 连接建立。前者是衡量呼叫接通率的一个重要指标，其结果可以作为调整信道配置的依据。后者可用于考察系统负荷情况。RRC连接建立成功率（业务相关）RRC连接建立成功次数（业务相关）/ RRC连接建立尝试次数（业务相关）*100% 影响的因素1） 上行干扰，观察上行ISCP值是否正常。2） 小区资源不够，小区是否拥塞，通过话统提取RRC建立失败原因是否为congestion。3） 用户无响应，终端问题。4） 终端和NB同步问题。5） 弱覆盖 涉及的参数1） 无 。2） 载波数量 。3） RRCUERSPTMR，等待RNC下发RRC SETUP时间，超时接入失败。4） PRXprachdes：期望在小区接收机得到的PRACH接收功率。5） PCCPCHPOWER，pccpch功率。 优化建议1） 查找干扰源，或在调整uppts位置暂时规避。2） 扩容，可以把A频点改为F频点增加容量。3） RRCUERSPTMR，适当增加此参数，避免时延大导致超时建立失败。4） 提高PRXprachdes期望值，增加UE发给NB信息成功率。5） 适当提高pccpch功率，增加覆盖。RRC问题分析流程图：图1RRC连接建立问题分析图 案例关键字：GSM直放站，干放，室分，ISCP 故障类别：干扰问题现象描述：在某市TD三期项目中，网优人员测试CS和PS业务时，发现PCCPCH和DPCH的RSCP及C/I都正常，但DPCH的ISCP很高，导致接通率低，CS域话音及视频质量差，PS域速率低，空口掉话掉线率高。背景介绍：新建TD网络，华为采用RNC类型：RNC820；RNC版本：RNC820V004R000C01SPC300告警信息：无原因分析1、TD网内同频干扰。2、TD网内基站存在时钟源GPS失步问题。3、基站硬件故障或室分设备故障。4、相邻小区存在时隙配比不一致问题。5、TD射频输出段的干放故障。6、其它无线系统的网外干扰。处理过程首先联系测试人员，请其提供现场第一手资料进行分析。现场测试CS64K业务截图如下所示：从上图可以看到，在占用10055频点时，PCCPCH及DPCH的C/I都在11dB以上，RSCP良好，误块率为0，但存在DPCH的ISCP过高的问题。从载干比良好的情况来看基本可以排除网内同频干扰问题，为慎重起见，修改主频点为较高频段的10020进行测试，发现也是存在相同问题。在后台使用LMT-R跟踪UE信令，并与现场测试工程师连续，发现经常无法收到UE上报的RRC_CONNECTION_REQUEST的消息，呼叫建立后，出现掉话现象，掉话原因为空口失败：从路测数据来看，发现测试区域邻区电平为-116dBm，即无法收到邻区信号，从现场环境来看，该室内站点的相邻站与其相距100米左右，应该可以收到信号，怀疑该站或其相邻站点存在GPS故障导致时隙干扰问题。为验证是否存在此类问题，采取了以下几个步骤进行测试。偏移该室内小区的UPPCH的位置，由0改为22，进行测试验证。查询该站及其相邻站点的时钟同步方式，并查询附近站点的告警情况，检查是否存在时钟失步的问题。检查该小区和邻区的时隙配比是否都为2：4。修改载频优先级，使其占用其它载频，现场进行测试，并在后台观察所有载频的ISCP情况。测试及查询结果如下：偏移UPPCH后，ISCP仍然较高，掉话问题还是没有解决（掉话原因为UE无线连接丢失）：检查发现相邻站点没有时钟源告警，产品侧反馈附近站点也已安装GPS，采取自动同步方式，站点锁星正常。检查发现全网时隙配比都为规范的2：4，没有问题。修改载频优先级，UE占用优先级最高的辅载频，发现问题仍然存在，所有载频的ISCP都为-80dBm左右：采取以上的检查方法后，发现在整个TD网络的B频段带宽内都存在底躁较高的问题，基本可以判断该站的干扰由基站硬件模板、室分系统或网外无线系统干扰导致。联系客户咨询该室内站是否存在同覆盖的宽频直放站等GSM信源，如有请其短暂关闭10分钟进行测试。后从客户GSM部门了解到，该室内站点所在楼宇安装有客户的测试直放站，并在远端使用干放引入室分。关闭直放站远端干放进行测试，并在后台跟踪ISCP如下图所示：从上图可以看到，三个频点的ISCP都已从-80dBm下降至-102dBm左右，现场测试效果良好，通话质量正常，没有再发现掉线掉话情况，业务恢复正常。建议与总结发现业务时隙干扰应首先从网内寻找原因，首先从频率干扰和告警等容易实现的方式开始检查，排除网内干扰的原因后再去分析硬件故障和异系统干扰问题。3.2 CS RAB建立成功率RAB建立成功是成功为用户分配了用户平面的连接，是建立业务连接的最后一个步骤。该指标衡量电路域RAB建立成功情况，影响TD网络语音业务的接入性能。该指标偏低时将直接导致客户无法接入网络。RAB建立成功率（CS域RAB指派建立成功RAB数目）/（CS域RAB建立请求的RAB数目）*100% 3.2.1 影响的因素1） 上行干扰，ISCP过高。2） RB建立超时。3） 用户接入阶段主动挂机。4） 弱覆盖。5） ALL2PATH配置错。6） 开环功率不足。7） 激活时间太短。 涉及的参数。1） 无。2） RBSETUPRSPTMR：UE等待RB建立完成时间，如果超时则接入失败。 3） 无。4） Pccpchpower功率，可以提高相应得信道功率增加覆盖。5）无。6）MINDLINITPWR,DLINTERFERERSV提高下行最小初始发射功率,提高上下行开环功率，降低开环功率不足造成的失败。MIDRATERLACTTIMEDEFOFFVAL,HIGHRATERLACTTIMEDEFOFFVAL增加激活时间时长。 优化建议1） 查找干扰源。2） 增加RBSETUPRSPTMR时间，避免时延过大超时导致接入失败。3） 无线侧无解决方案。4） 做好RF优化，无法调整可以提高相应信道功率。5） 开站的数据核查工作。RAB是指用户平面的承载，用于UE和CN之间传送语音，数据及多媒体业务。UE首先要完成RRC连接建立，然后才能建立RAB。RAB建立是由CN发起，UTRAN执行的功能，基本流程： 首先由CN向UTRAN发送RAB指配请求消息，请求UTRAN建立RAB。 RNC发起建立Iu接口与Iub接口的数据承载。 RNC向UE发起RB建立请求。 UE完成RB建立，向RNC回应RB建立完成消息。 RNC向CN应答RAB指配响应消息，结束RAB建立流程。当RAB建立成功后，一个基本的呼叫即建立。流程如下图所示：图2RAB正常建立流程 案例IU口AAL2阻塞导致RAB建立失败案例：IU口AAL2阻塞导致RAB建立失败某RNC现场反馈在多个小区发现偶尔呼叫不成功，原因为资源阻塞。小区无告警信息资源阻塞有可能是业务量大导致AAL2拥堵，也有可能是AAL2被屏蔽，这里并不是每次RAB被拒，说明肯定不是所有AAL2被屏蔽。从后台信令上看，RNC在收到RAB指配请求之后就向CN回了RAB指配响应，但RNC未向NodeB发送无线链路重配置，而RAB指配响应的原因是iu-transport-connection-failed-to-establish，这说明可能为传输链路有异常。图1通过附件图1初步断定为IU口问题后，跟踪RNC8的IU口，发现两个小时内有7次RAB建立失败，原因值都一样而且都是CS域RAB指配。于是在跟踪IU口的同时跟踪QAAL2，在IU口发往CN失败的RAB指配对应的时间查看AAL2的链路状况。图2通过附件图2（cause：switching-equipment-conges）可以得知，接入业务的该条AAL2链路阻塞，而RNC这边没有将任何链路block掉，于是联系核心网侧，核心网人员表示误操作远端闭塞了16条AAL2中的3条，将这3条AAL2链路解蔽塞之后恢复正常。呼叫不成功的原因很多，和网络环境、无线参数等多种因素有关，通常遇到这样的问题，要结合无线环境和信令等多种方法结合解决。CS域RAB指配遇到概率性不通的情况下，并且iu-transport-connection-failed-to-establish，可以查下是否RNC与CN间链路被闭塞。同小区内立即激活缺省偏移值设置不当造成并发业务失败案例：同小区内立即激活缺省偏移值设置不当造成并发业务失败在秦淮西路-3小区经行并发业务测试时，如果先进行H业务之后尝试语音业务会导致RAB建立失败，同时H业务掉话。在OMC上查看小区无告警完整信令流程如下图所示：上图中可以看出，其共进行了2次RB建立申请。第一次申请的是PS业务如下图所示：且建立成功UE返回RRC_RB_SETUP_CMP。第二次RB建立申请CS业务，如下图所示：此次CS业务没有建立成功，5秒后RNC申请IU RELEASE，PS业务掉话。原因值为：无线进程接口失败。如下图所示：1.根据其后台跟踪RB建立的具体信令可以看出RB建立失败原因为ulWatiRbFailTimer is too short。5秒后RB建立超时，IU释放。如下图所示：2与其他小区进行参数对比，发现该小区同小区内立即激活缺省偏移值设置为40，远小于基线参数设置的150，如下图所示：该参数指示 UE 新配置生效的时间点，便于UE、NodeB 和RNC 在该时间点同时使用新的配置信息，保证数据的可靠传输。RNC 建立新配置时根据当时的帧号推算新配置的生效时间点，既要考虑携带该参数的信令在Iub 和Uu 口的传输时延，又要考虑新配置建立时间不能过长。如果新配置的建立时间和生效时间间隔过短，可能会出现在UE 未收到配置信息之前网络侧新配置已经生效，而UE 依然使用旧配置，导致数据传输出现错误。3.将该小区同小区内立即激活缺省偏移值更改为150。如下图:4.复测发现并发业务可以正常建立，如下图所示：对于异常事件的小区参数配置进行核查和比对可以有效地定位和解决问题。3.3 CS域无线掉话率 影响的因素1） 弱覆盖。2） 干扰。3） 切换。4） 终端问题。5） AAL2PATH配置。 涉及的参数1） Pccpchpower。无。2） HYSTFOR1G：邻区信号测量值比本区高出该门限值时，才可能触发切换 。 TRIGTIME1G：该参数越大，误判概率越小，但会减小对测量信号变化的响应速度，因而切换操作不能及时响应的概率也越大；该参数越小，可能会带来误判和乒乓切换HYSTFOR2A：邻区信号测量值比本区高出该门限值时，才可能触发切换 该参数越大，抵抗信号波动的能力越强，可以减少乒乓和误判，但会导致切换的不及时 该参数越小，可以使得切换条件更异满足，但带来乒乓和误判的概率增大TIMETOTRIG2A：该参数越大，误判概率越小，但会减小对测量信号变化的响应速度，因而切换操作不能及时响应的概率也越大；该参数越小，可能会带来误判和乒乓切换3） 无。4） AAL2PATH配置问题。 优化建议1） 通过RF调整，增加覆盖，如果解决不了增加信道发射功率。2） 查找干扰源，调整频点扰码。3） 根据现场情况调整切换门限，解决切换慢问题。4） 终端问题，回访用户了解用户行为，指导用户正确使用。5） 检查ALL2PATH配置问题。 案例案例1现象描述：在某市TD三期指标提升中，优化提升后全网所有RNC掉话率降至0.2%左右，但是RNC07掉话开始在3，后经过产品帮忙处理topN降至1左右。处理万topN小区之后的掉话极为分散，没有top小区可以处理。背景介绍：新建TD网络，华为采用RNC类型：RNC820；RNC版本：RNC820V004R000C01SPC410本市三期13个RNC，共有11个MSC，5个华为，6个E厂家。RNC07为单独的一个爱立信server55。告警信息：GCU/GCG单板锁相环状态改变告警，GCU/GCG单板锁相环状态改变告警，E1/T1信号丢失告警。原因分析1、RNC级性能参数设置不当。2、RNC07区域干扰较大，网优优化不充分。3、产品配置的RNC链路或者传输数据问题。4、RNC07所在的SERVER55问题。处理过程核查RNC级的掉话相关的参数。开环功控，闭环功控参数核查。个别参数如：上下行干扰余量，无线链路最大最小发射功率等与LCR4.1基线有差异，但是我们全网RNC都配置了相同的参数。SRB复位相关参数核查。之前所有RNC全部更改，和其它RNC相同。干扰核查。导出RNC07的UP和ISCP干扰，发现测量值大于95的小区很少，同时RNC07的切换成功率也不比其它RNC差。所有干扰应该不是造成RNC07掉话高的主要原因。产品问题核查及top小区处理。发现RNC07存在好多GCU/GCG单板告警，GCU/GCG单板与RNC的时钟相关，所有有可能导致掉话。于是产品同时提单与研发一起定位，最后的结论是这个告警跟掉话没有关系。况且其它所有RNC都有这个告警，只是其它RNC这个告警数量稍少而已。E1/T1信号丢失告警，是因为所有绝大多数站点物理上只配置了2条传输，但是数据已经做了8条或者10条，没有拥塞的情况下这个告警是不会影响业务的。观察当日的掉话top N小区，发现有RNC07的5个站点失败较高，并且失败原因类似。派人现场对长坑1小区测试，发现此小区接入也存在问题。失败的典型信令如下：RAB建立完后马上释放，释放的原因未知错误。同时长屯收费站和牛山新村也出现相同的问题。这些站点实际只配置2条E1，配置在主控板上， S666站型应该配置10条E1，主控上配8条E1，UTRP两条E1。UTRP上的两条E1物理环回。两个IMA组，分别关联主控上的8条E1和UTRP的两条E1。两个IMA组上分别有4条AAL2PATH。失败的接入都是建立在了传输扩展板上。但是传输扩展板实际上是没有配置E1。之前的处理措施是删除建立在UTRP上的AAL2PATH后，恢复正常。或者将此IMA组BLK，等E1线连通后，UBK此IMA组。检查这些站点发现数据都是S666配置，于是对RNC07的所有S666站重新加载NODE-B侧脚本，并在脚本中BLK传输扩展板的IMR组。观察TOPN掉话小区，掉话次数明显下降。这时RNC07的掉话率已经下降为0.5左右，得到很大改善。案例2：问题描述：从话统信息中可以获知某个RNC CS掉话的Top小区，但这些Top小区确切的掉话原因从话统中不易获取，比如是Top小区中的Top终端造成的还是Top小区离散用户，借助PCHR工具可以精确定位。问题分析：以RNC1T为例：1) 从话统中看到莲北村T1（20281）一直位于CS掉话的Top小区列表；2) 通过PCHR工具，插入UE标示，发现这个小区的掉话并不集中于Top终端,如图1所示；莲北村T1小区掉话信息分析某个终端掉话前的信令流程，发现掉话原因为链路质量变差，疑似UE没有收到Measurement Control，层2收不到ack消息导致SRB复位。见图2、图3链路释放前的链路信息信令释放流程3) 经过分析，其他掉话终端与以上现象类似，基本可以确定是小区无线环境导致了掉话。经过核查，该小区属于未替换站，根据之前的测试经验，新老站之间的切换会存在概率性的切换失败，从而导致掉话。解决措施：1) 根本解决措施是替换该站点；2) 如果替换站点进度受限，同时该站点周围新站点密集，可以采取关闭该站点调整周围小区的覆盖尝试解决；3) 如果以上两项措施均无法实施，可以采取对该小区提高CS异系统切换门限，使得潜在掉话用户尽早切至2G。3.4 RRC拥塞率3.4.1 影响的因素这里请列出影响该指标可能的原因。也是日常优化需要关注和分析的地方。载波资源不够，同一时间用户量过多。 涉及的参数载波数量。RRCESTCAUSE，控制RRC建立在那个信道上，控制RRC建立的资源。 优化建议增加载波数量，对一些RRC建立流程（注册，2G重选回3G，附着等），改为建立在FACH上。 案例案例名称：手机工厂大业务量站点接通率优化案例现象描述：在D市接通率优化过程中，发现A小区的RRC建立成功率很低，并且RRC建立请求次数比一般小区多的多：（不区分业务）RRC连接建立成功的次数（不区分业务）RRC连接请求次数（不区分业务）RRC连接失败次数（不区分业务）RRC连接失败次数（不区分业务）RRC连接失败次数（不区分业务）RRC连接失败次数（不区分业务）RRC连接失败次数RRC建立成功率23670261222452004226190.61%该小区的RRC失败次数大约是全网RRC失败次数的95，导致全网的RRC建立成功率低。告警信息：无原因分析：RRC建立成功率低原因有多种：1、 数据配置问题导致RRC建立成功率低；2、 NodeB硬件问题；3、 无线环境干扰问题；4、 网优参数问题；5、 拥塞问题。处理过程：1、 我们通过话统进行分析，发现该小区失败的原因是由于拥塞导致，而AAL2建立失败、FP同步失败和RL建立失败很少；2、 因此这个站点主要是拥塞原因，据了解这个位置是宇龙计算机通信公司，该处属于手机生产测试地方，怀疑存在终端测试导致；3、 通过PCHR分析该小区的起呼发现，这个小区所有的起呼都是一款终端，并且没有IMEI号码，并且存在几百个测试号码同时进行业务：用户标识RRC请求次数终端IMEI460078026111375H994460078026110750H895460078026111370H839460077119580830H703460078026110745H666460078026110746H635460078026110857H598460001831411708H597460020724338304H577460078026111372H571460078026111371H566460078026111376H566460078026110747H561460001831411882H534460078026110744H524460079145510585H396460079145510627H349460078026110753H340460077119581874H310460078026111358H306460078026110739H302460078026111354H301460079145510612H301460078026111357H292460078026111360H270460078026110858H242460078026111304H226460078026110734H222460078026110735H221460079145510634H217460020724337061H214460078026110738H213460078026110754H209460078026110856H209460001721270892H2084、 因此，这个站点的问题主要是同时用户较多进行业务导致的拥塞，我们进行了RRC请求原因的分析，RRC请求（原因为）大约占整体请求的30，说明该小区下存在较多的终端进行开关机操作。5、 由于目前我们的RRC建立都在主载波进行，而现网的RRC建立是在13.6K的DCH上，这样如果同时有大量的手机开关机，我们的主载波DCH资源有限，会导致RRC的资源拥塞；6、 因此，我们将注册类的RRC请求和IMSI分离类的RRC建立在FACH上，减少与有用RRC建立的资源强占，提高RRC接入成功率：SET RRCESTCAUSE:RRCCAUSE=REGISTEST,SIGCHTYPE = DCH_13.6K_SIGNALLING;SET RRCESTCAUSE:RRCCAUSE=DETACHEST, SIGCHTYPE = DCH_13.6K_SIGNALLING;修改为SET RRCESTCAUSE:RRCCAUSE=REGISTEST, SIGCHTYPE=FACH;SET RRCESTCAUSE:RRCCAUSE=DETACHEST, SIGCHTYPE=FACH;7、 修改后小区的接通率明显提升。建议与总结：对于某些特定的场景，通过相关特定的参数设置来优化整个小区，使指标和用户感知最优。附件：