上海贝尔WCDMA 常用COUNTER

RRC连接RRC.FailConnEstab.TimeoutRepeat重传超时系统下发RRC connection setup后在规定时间内（T300*N300）没有收到手机上传的RRC connection setup complete .有可能手机发送RRC connection request后，移动至其他小区。RRC.FailConnEstab.DLCodeRsrc下行码资源受限RRC连接建立时分配码资源失败。这个一般是网络用户太多引起，在室内等微蜂窝覆盖的高业务量场景下，可能出现。可进一步在关联话统指标中查询此时的码有效利用率，若低于30%，则可能码分配算法异常RRC.FailConnEstab.DLPowRsrc下行功率受限RRM准入判决无法建立新的RRC连接，这主要因为小区无线负载太高所致，需查询此时的小区的最大RTWP和最大TCP，确认上行还是下行拥塞，判断是否需要扩容，同时还要查看相关准入策略设置是否合理，比如DCCC等RRC.FailConnEstab.Unspec未特别指出的本计数器统计特定小区未知原因的RRC连接失败次数RRC.FailConnEstab.RSSI接收信号强度RRC.FailConnEstab.FACH_CAC_or_UnspecCAC或未特别指出的原因，不包括缺少上下文情况RRC.FailConnEstab.Overload过载RRC.FailConnEstab.3G2GRedirectEmergency因紧急电话发生3G 2G改变RRC.FailConnEstab.CACCAC:呼叫允许控制RRC.FailConnEstab.DCH_LackContextCELL_DCH缺少上下文RRC.FailConnEstab.NoRespNodeB从NodeB无应答RRC.FailConnEstab.CPNTI除C-RNTI原因外RNTI：无线网络临时鉴定（RNTI）是在UTRAN 和UE 和UTRAN 之间的信号信息内部作为UE 标识的1)服务RNC RNTI（S-RNTI） 2)转移RNC RNTI（d-RNTI） 3)小区RNTI(C-RNTI) 4)UTRAN RNTI(u-RNTI) 5）DSCH RNTI (DSCH-RNTI)c-RNTI 是用来： -通过UE 以在控制RNC 内标识自身 -通过控制RNC 以定位UE C-RNTI 由主控RNC 分配，供UE 接入新的小区。此外，对于要接入的这个小区，此C-RNTI 必须是唯一的。 主控RNC 应该知道在一个逻辑RNC 内与一个C-RNTI 相关的D-RNTI 参数（如果存在的话）。RRC.FailConnEstab.UE_EcNoUE EC/NO低于qQualityMin(服务小区最小导频接入质量值)RRC.FailConnEstab.ReselectRRC.FailConnEstab.Filtered_RLS_CAC过载控制RRC.FailConnEstab.Cong.SumRRC连接失败次数,网络拥塞本计数器统计特定小区的网络拥塞的RRC连接失败次数RRC.FailConnEstab.Cong.OrigConvCallRRC在连接建立过程中失败:主叫会话类业务RRC.FailConnEstab.Cong.TermConvCallRRC在连接建立过程中失败:被叫会话类业务RRC.FailConnEstab.Cong.OrigStrmCallRRC在连接建立过程中失败:主叫流式业务RRC.FailConnEstab.Cong.TermStrmCallRRC在连接建立过程中失败:被叫流式业务RRC.FailConnEstab.Cong.OrigIntactCallRRC在连接建立过程中失败：主叫交互类业务RRC.FailConnEstab.Cong.TermIntactCallRRC在连接建立过程中失败：被叫交互类业务RRC.FailConnEstab.Cong.OrigBgrdCallRRC在连接建立过程中失败：主叫背景类业务RRC.FailConnEstab.Cong.TermBgrdCallRRC在连接建立过程中失败:被叫背景类业务RRC.FailConnEstab.Cong.OrigHighPrioSigRRC在连接建立过程中失败：主叫高优先级信令业务（彩信主叫）RRC.FailConnEstab.Cong.OrigSubscCallRRC在连接建立过程中失败：主叫用户订制的业务RRC连接问题分析RRC连接建立失败的问题通过UE的信令流程和RNC的单用户跟踪可以获得。RRC连接建立的过程主要包括几个步骤： UE通过RACH信道发送RRC Connection Request消息。 RNC通过FACH信道发送RRC Connection Setup消息； UE在建立下行专用信道并同步后通过上行专用信道发送RRC Connection Setup Complete消息。RRC 建立失败一般有下面几类原因： 上行 RACH 的问题 下行 FACH 功率配比问题 小区重选参数问题 下行专用初始发射功率偏低 上行初始功控问题 拥塞问题 设备异常问题等在这些问题中尤其上行RACH的问题、下行FACH功率配比问题、小区重选参数问题、设备异常问题出现的概率比较高。RRC连接建立问题分析流程UE发出RRC Connection Request消息RNC没有收到 如果此时下行CPICH的Ec/Io较低，则是覆盖的问题。 如果此时下行CPICH的Ec/Io不是太低（比如大于-14dB），一般都是RACH的问题。通常有以下可能的原因：- Preamble的功率攀升不够：可以增加Preamble攀升次数。- UE的输出功率比要求值偏低：属于UE本身性能问题，更换UE。- NodeB设备存在驻波：检查NodeB是否存在驻波告警。- 小区半径设置参数不合理：小区半径参数设置过小，会导致NodeB无法同步小区半径范围外的UE，造成接入失败，这主要发生在农村、郊区等广覆盖场景。RNC收到RRC建立请求消息后下发了RRC Connection Reject消息当出现RRC Connection Rreject消息时，需要检查具体的拒绝原因值。一般有以下两种原因： RNC控制面单板CPU负荷太高，需要增加单板。 DCH、FACH接纳被拒，这中情况一般不会发生。RNC下发的RRC Connection Setup消息UE没有收到该问题的可能原因有以下几种： 覆盖差 小区选择与重选参数不合理具体检查方法可以查看此时CPICH的Ec/Io，如果低于-12dB（因为缺省是基于Ec/Io为-12dB配置的），而且监视集中没有质量更好的小区，那么是覆盖的问题；如果此时监视集中有更好的小区，则可能是小区重选的问题。覆盖差可以通过增强覆盖的方法解决覆盖问题，如增加站点补盲、工程参数调整等。在无法增强覆盖的情况下，可参照现网PCPICH Ec/Io的覆盖情况适当提高FACH的功率。例如如果整个网络优化后的覆盖区域导频Ec/Io全部大于-12dB，那么公共信道功率的配比按照Ec/Io大于-12dB来配置，可以保证UE从idle状态接入时的成功率 。对于小区选择与重选引起的接入问题，可以通过调整小区选择与重选参数，加快小区选择与重选的速度，可以解决小区选择与重选参数不合理造成的RRC连接建立失败问题。注：RRC CONNECTION SETUP消息是由FACH承载。由于UE发出RRC CONNECTION REQUEST是在PRACH信道的前导（preamble）被UTRAN侧收到之后，以当时preamble的功率为基准，再在RACH信道上发出的。而前导（preamble）的发射功率可以不断攀升直至收到响应（受到preamble最大重传次数限制）。因此在某些覆盖较差的区域，有可能出现RACH信道和FACH信道的覆盖不平衡，使得UTRAN侧能够收到UE的RRC建立请求，而UE不能收到RNC发出的RRC CONNECTION SETUP。UE收到RRC Connection Setup消息没有发出RRC Setup Complete消息如果此时下行的信号质量正常，那么可能是手机异常。否则可能是下行专用信道初始功率过低导致下行不能同步，可以通过调整业务下行 Eb/No 解决。UE发出RRC Setup Complete消息RNC没有收到由于上行初始功控会让UE的发射功率上升，这种问题出现的概率很小。如果出现这类问题可以适当提高专用信道的Constant Value值，从而提高UE的上行DPCCH初始发射功率。同时还与上行链路SIR初始目标值设置是否合理有关，对于初始建链时的上行初始同步有较大的影响。该参数如果设置过大，有可能会使得用户初始建链时带来的上行干扰过大；如果设置过小，则会使得上行同步时间加长，甚至导致初始同步失败。该参数为RNC级的参数，对网络性能影响较大，调整时需要谨慎。注：RRC CONNECTION SETUP COMPLETE是通过上行DPCH发送的，而UE根据收到的IE“DPCCH_Power_offset”和测量得的CPICH_RSCP的值计算出上行DPCCH的初始功率。DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP其中DPCCH_Power_offset=Primary CPICH DL TX Power + UL Interference + Constant Value，Constant Value是一个后台可以配置的参数，如果该值设置过低，就有可能使得UE在发送RRC CONNECTION SETUP COMPLETE时功率不够。RAB连接VS.RadioBearerSetupUnsuccess.Timeout超时VS.RadioBearerSetupUnsuccess.RadioBearerSetupFailure在建立无线承载过程中失败无线承载建立失败.无线承载失败VS.RadioBearerSetupUnsuccess.Other其他原因VS.RadioBearerEstablishmentUnsuccess.InvalidRabParametersValue无效的无线接入承载参数值VS.RadioBearerEstablishmentUnsuccess.UnavailableDlCodeResources下行码资源受限RAB连接建立时分配码资源失败。这个一般是网络用户太多引起，在室内等微蜂窝覆盖的高业务量场景下，可能出现。可进一步在关联话统指标中查询此时的码有效利用率，若低于30%，则可能码分配算法异常VS.RadioBearerEstablishmentUnsuccess.UnavailableDlPowerResources下行功率受限准入算法判决，因为小区负载太高进行了上行或者下行准入判决拒绝，导致无法建立新的RAB，可进一步在关联话统指标中查询此时的小区的最大RTWP和最大TCP，确认上行还是下行拥塞，在确认准入算法参数合理的情况下需要考虑覆盖优化和容量优化Tcp：Transmit Channel Processing 发送信道处理VS.RadioBearerEstablishmentUnsuccess.Unspecified无线承载建立失败.未定义VS.RadioBearerEstablishmentUnsuccess.RlFailOrRlcErr无线承载建立失败.无线链路失败or无线链路控制错误VS.RadioBearerEstablishmentUnsuccess.5Unused未使用VS.RadioBearerEstablishmentUnsuccess.LackOfRncProcessingResources无RNC资源可用VS.RadioBearerEstablishmentUnsuccess.NodeBCEMLackofL1ResourceNodeB （CEM）缺少L1资源VS.RadioBearerEstablishmentUnsuccess.LackTransportIdIu缺少IU传输标识符VS.RadioBearerEstablishmentUnsuccess.LackBwthIuIU带宽资源不足VS.RadioBearerEstablishmentUnsuccess.LackTransportIdIur缺少IUR传输标识符VS.RadioBearerEstablishmentUnsuccess.LackBwthIurIUR带宽资源不足VS.RadioBearerEstablishmentUnsuccess.LackTransportIdIub缺少IUB传输标识符VS.RadioBearerEstablishmentUnsuccess.LackBwthIubIUB带宽资源不足VS.RadioLinkReconfigurationPrepareUnsuccess.RadioLinkReconfigurationFailure无线链路重配置准备失败.无线链路管理拒绝VS.RadioLinkReconfigurationPrepareUnsuccess.RrmRefusal无线资源管理拒绝RRM:无线资源管理（Radio Resource Management，RRM）的目标是在有限带宽的条件下，为网络内无线用户终端提供业务质量保障，其基本出发点是在网络话务量分布不均匀、信道特性因信道衰弱和干扰而起伏变化等情况下，灵活分配和动态调整无线传输部分和网络的可用资源，最大程度地提高无线频谱利用率，防止网络拥塞和保持尽可能小的信令负荷。无线资源管理(RRM)的研究内容主要包括以下几个部分：功率控制、信道分配、调度、切换、接入控制、负载控制、端到端的QoS和自适应编码调制等。VS.RadioLinkReconfigurationPrepareUnsuccess.NodeBCEMLackL1Rsrc无线链路重配置准备失败.无线资源NodeB信道单元不足VS.RadioLinkReconfigurationPrepareUnsuccess.LackBwthIub无线链路重配置准备失败.IUB带宽不足RAB或RB建立问题分析当RAB或RB建立失败时，RNC会在RAB Assignment Response信令中回RAB指配建立失败。通过相关信元中携带的失败原因值，可以得到具体失败原因。常见的RAB/RB建立失败问题包括： 参数配置错误导致RNC直接拒绝RAB的建立请求 准入拒绝 UE回应RB建立失败造成的RAB 建立失败 空中接口RB建立失败造成的RAB 建立失败RAB问题分析流程图参数配置错误导致RNC直接拒绝RAB的建立请求参数设置非法导致RNC直接回应RAB建立失败在商用网络的发生概率较小，一般是由特殊用户的特殊操作造成的。主要场景是用户PS业务的上行开户和激活申请信息超过了手机的能力，导致RNC 直接回应拒绝。例如：某特殊用户的开户能力是上下行384K，而其使用的手机上行最大能力只是64K，在用户使用AT命令或者手机终端软件设置激活PDP的QoS信息中上下行最大速率均为384K，这样在RNC收到RAB指派请求时，发现请求的上行最大速率超过了UE的能力，将直接返回RAB建立失败，不发起RB建立过程。由于参数设置错误超过UE能力的情况造成的RAB建立失败后，SGSN会重新协商发起新的RAB指派，直到UE能力可以支持，最终完成RAB指派。对于用户来说，这次PDP激活仍然可以成功，指示获得的最大速率为UE能力所能支持的最大速率。但是，如果UE的PDP激活请求中QoS设置要求的最小保证速率都超过了UE的能力，那么虽然网络协商了较低的速率接受UE的PDP激活请求，但是当UE发现PDP激活接受消息中网络协商的速率小于其最小保证速率时，会发起去激活PDP请求，最终无法完成PDP激活。准入拒绝对于非HSDPA用户，当系统资源不足时（包括功率、信道码、Iub 传输资源、CE），会发生准入拒绝导致呼叫建立失败。此时，需要检查当前网络负载情况、码资源、Iub 传输资源、CE资源占用情况，确定是哪种资源受限导致的拥塞，并给出相应的扩容手段。 当小区不支持HSDPA业务时，R99用户的准入直接根据设定的R99准入门限进行判断。当小区支持HSDPA业务时，HSDPA和R99动态功率分配时，非HSDPA用户的上行的准入判断是基于RTWP或者等效用户数，如果上行负载过高，也会导致非HSDPA用户准入失败。 当Iub接口带宽配置不足，激活R99数据业务时，Iub接口会因为带宽受限拒绝。 NodeB Credit资源的准入控制与功率准入控制类似，根据新接入用户的扩频因子，判断当前剩余的Credit是否能够支持当前请求的业务。根据RAB Downsizing Switch开关的打开情况，RNC进行不同的处理，具体参见上面有关Iub 带宽配置不足处理说明。对于HSDPA用户，在动态功率分配方式下，准入拒绝考虑除了上述功率、信道码、Iub传输资源、CE等系统资源以外，还需要考虑NodeB支持的H用户数，小区支持的H用户数是否超过规定的门限。对于HSDPA用户，当Iub接口带宽配置不足，不会发生准入拒绝，但是速率会降低。另外HSDPA和R99的AAL2PATH是分别配置的，并且HSDPA AAL2PATH必须配置成HSDPA_RT或者HSDPA_NRT类型，如果HSDPA AAL2PATH配置成R99 AAL2PATH类型RT或者NRT，不会发生RAB指配失败，但RNC会直接把HSDPA业务建立成R99 384Kbps。对于下行功率准入， DCH业务需要考虑R99业务负载是否超过非HSDPA业务准入门限外，同时还要考虑非HSDPA功率和HSDPA GBP（保证速率所需最小功率）是否超过小区总功率门限。 HSDPA业务，需要检查小区提供的HSDPA吞吐率是否超过所有用户GBR和的门限要求，或者流业务和背景业务的GBP是否超过小区的HSDPA功率，同时也要考虑非 HSDPA 功率和 HSDPA GBP（保证速率所需最小功率）是否超过小区总功率门限。对于Iub准入： DCH业务，按照峰值速率业务激活因子进行准入HSDPA业务，按照GBR（保证速率）进行准入。 如果Iub达到拥塞门限会触发DCCC降速，同时如果RLC_AM重传率超过一定的门限，可以打开Iub Overbooking开关，触发限制R99的TF或者把HSDPA业务按照一定的系数降速。UE回RB建立失败造成的RAB建立失败UE回应RB建立失败主要是由于用户的错误行为造成，如以下案例： 用户在已经有下行128K的数据业务时，收到了VP业务的RB建立请求（VP主叫或者被叫），由于终端不支持下行同时进行VP和高速PS业务，UE直接回RB建立失败，原因是unsupported configuration。 主叫WCDMA终端进行VP业务的被叫方驻留在GSM网络，不支持VP业务。这样在RNC收到RAB指派请求后，核心网Call Proceeding后立刻下发Disconnect命令，原因为Bearer capability not authorized。而此时UE刚收到RB SETUP命令，还没来得及完成RB建立，收到该Disconnect后会马上发起回应RB建立失败，RNC返回RAB建立失败，原因为failure in radio interface procedure。空中接口RB建立失败造成的RAB建立失败RB建立命令没有响应，导致RNC认为RB建立失败，表现为RB建立命令没有收到ACK或者没有收到RB建立完成命令。这样的情形主要出现在弱信号区，造成信号弱的原因有两种情况，一种是UE没有驻留在最优小区发起接入，另一种是覆盖不好。 UE没有驻留在最优小区发起接入，会在RB建立过程中希望活动集更新加入最优小区（同时信号快速变化导致驻留小区信号快速下降），但是由于流程不能嵌套进行（网络和终端都不支持），活动集更新只能等待RB建立完成后进行，导致RB建立过程在弱信号小区进行，容易出现失败。对于这种情况需要提高同频小区重选的启动门限和速度，使得UE尽快驻留在最优小区，在最优小区发起接入。覆盖不好造成的RB建立失败分为上行和下行质量不满足两种情况。下行覆盖引起的情况表现为UE无法收到RB建立命令，这种情况有可能是上行干扰造成的，可以通过检查 RTWP 确定；下行覆盖质量不满足部分原因是UE的解调性能不佳造成，部分原因是需要RF优化来解决的。CS掉话VS.IuReleaseReqCs.OamInterventionRNC请求释放电路域Iu连接对应的RAB数目,操作维护干预VS.IuReleaseReqCs.UnspecifiedFailureCS域IU口释放.未定义失败VS.IuReleaseReqCs.RepeatedIntegrityCheckFailureCS域IU口释放.重复整形检查错误VS.IuReleaseReqCs.UeGeneratedSignallingConnectionReleaseCS域IU口释放.Ue产生的信号连接释放VS.IuReleaseReqCs.RadioConnectionWithUeLostCS域IU口释放.Ue丢失导致连接释放VS.IuReleaseReqCs.AbnormalConditionTimerRelocExpiryRNC请求释放电路域Iu连接对应的RAB数目,重定位完成定时器超时VS.IuReleaseReqCs.OtherCauseCS域IU口释放.其他原因VS.IuReleaseReqCs.DlRLCErrSRBCS域IU口释放.下行无线链路控制信令承载错误VS.IuReleaseReqCs.UlRLCErrSRBCS域IU口释放.上行无线链路控制信令承载错误VS.IuReleaseReqCs.T360ExpiryT360计时器超时VS.IuReleaseReqCs.ConnectionWithNodeBLostCS域IU口释放.UE与NodeB连接丢失VS.IuReleaseReqCs.ReleaseDueToUtranGeneratedReasonCS域IU口释放.释放原因为Utran通用原因VS.IuReleaseReqCs.NoRemainingRAB无剩余的无线承载资源VS.IuReleaseReqCs.FailureInTheRadioInterfaceProcedureRNC请求释放电路域Iu连接对应的RAB数目,无线接口流程失败VS.IuReleaseReqCs.NoResourceAvailable无可用资源掉话的定义从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个，则判断为掉话： 没有收到RRC释放消息，但UE状态由连接态（CELL_DCH）转移到空闲态( IDLE )。 收到RRC Release消息且释放的原因值为Not Normal。收到Disconnect， Release Complete，Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。广义的掉话包含CN和UTRAN的掉话率，UTRAN侧掉话主要包括两个方面： 业务建立成功后，RNC向CN发送RAB RELEASE REQUEST消息。 业务建立成功后，RNC向CN发送IU RELEASE REQUEST消息，其后收到CN发送的IU RELEASE COMMAND。需要说明的是RAN话统掉话的定义只从Iu接口信令的角度进行统计，统计了RNC主动发起的RAB release请求次数和Iu release请求次数。而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致。CS掉话分析流程图PS