RRC常见问题处理思路

《RRC常见问题处理思路》由会员分享，可在线阅读，更多相关《RRC常见问题处理思路（25页珍藏版）》请在装配图网上搜索。

1、RRC 连接拥塞与无响应处理思路1. 背景随着TD-SCDMA 网络二期工程接近尾场声，全国的网络建设却紧随其后开展起来， 在网络建设的初期阶段，由于基站建设问题、基站故障问题等造成优化的困难，本文就在处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供此类问题的一种解决思路。2. RRC 连接过程的信令流程UE处于空闲模式下，当 UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。每个UE最多只有一个RRC连接。当RNC接收至ij UE的RRC CONNECTIONREQUESTW息，由其无线资源管理模块 RRM根 据特定的算法（CAC算法）确定是接受还是拒绝该 RR

2、C连接建立请求，如果接受，则再判决是 建立在专用信道还是公共信道。对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。这样一来，对于 RRC连接的信令过程可以大致分为以下几个过程：1） 呼叫接入控制过程（主要由 UE发起请求，RNC来控制）2） 无线链路的建立过程3） RRC建立完成过程RRC连接过程的基本信令流程如下图：UENode BRNC息跟踪）：In OCupLinkOiy eetTraiLEferOut MICflirectTr ansferIn阪uftg1日里£ 式 Ml m 曲AJut 必CluRel $43 templaterv eCcti i nlal

3、豆三电弧连撞过程可以分为以下凡个步骤；in rut>tcC omxe ci.i onKel e =b.eeCompl eteRJKRadi oLi itkDel eli 4?n£.e(uestIn RNUEadi oLi iLkUftleii«iJa5ponse、rrcCdiuiecti onEeque写tIn RNCrrcConnteti o通之qu的式 W名 虱i oLi nkS a tupRe qu« Et1口t orI：adi oLi nl£ e t uj>Re que s 七一二二二_3s Radi oLinkSetupKsspon

4、geIn RHTRadi oLi nl£ at uRe oils er 4、rrcConnecti oiiSetupDut咖rrcC owuecti oxSetup REK 连接过一冬 E&d.i cLi nlcRwstarelndi citi aitIn orRa-li oLi rJ<R&s tflr«Iiidi 已立ti on6 rrcConnectiiliSttupConipletfiIn OCircCLDut LHCin 电 asiur em entC Qutr q1Nt班m q餐 m 号口*qstr q)In OCini ti aLDir&a

5、mp;ctlransferDut眦Ini ti alKEMft5 5 电皂电In RNTflirectTr ansferJut RHCQi-nlinkUire ctlr wsferIn RNUuplinkDir act Trans far如果对应的TKH1动生成的C微据，则过程如下:In HHCrrcC onne ctioriRequ*stSigTjrpe=3:RULC_IIE_NAME ;Intrface=12B. UiknovruSigType=3 :EHLC_UE JfAMl ;Intrface=12S： Ualou1RHU：-.SUciiUns tS&tupSigT5Tt=3

6、RHI£_UE_NAME :工ntiirft=128: IhdmM*工EMIT <.SUci ulnE tSatujRfesjSigTypa=3 :R1ILC_UE_NAME ：Iri.ti-f4c=128: UsdcnoSigType"3 ：RWLC_UE_NAME ;Iitt«r£ace" 128" UarJcnoRM1£ -.FP£kddReLRHIJC <.FpSA.ddRspOut RNICRadi oLl nkS e tujRe que e t1FIn RNCRadi oLi nl et,u

7、pRe sp qus e-.FpSIni tKaRH1£ <.fpSIftitR到S i gT yf e- 3 ; RNLC_UE_NAfi1 E ; Zitt-sr fa,ee-12S; VxJqioytxirOut R»Crr cC Qiuie ct i onS etuptn EHC/将 di qLl nkRest orelndi cati onIIn RNCrr cC onne cti onS e LuC om pl ± t 坦TSigTyp&=3 :RNLC_UE_NAME ： Interfit e=123. UnknovrnSigTypa=

8、3 :RN1JC_IIE_HAME ;Iiiter£ace=12S: UifcmomQut KSCmeasurein HitControlOut KNC附总q £ur em »nt. Control图中：F阴帧协、议(Node B与RNM步使用，此时的同步只是针对于用户的新的无线链 路的同步，并不是整个 Node B与RNC勺同步)RRC连接一般发生在如下情况下:3. RRC失败分析RRC连接失败发生RRC连接建立的过程中,(1) UE开机(2) UE关机(3) 位置区更新(4) UE进行主叫业务(5) UE进行被叫业务参考协议25331, RRC连接失败的原因被

9、分成了两类：(1) Unspecified (未定义)(2) Congestion (拥塞)但在我司的RRC连接失败的原因则根据信令过程，同时参考协议被分成了三类：(1) Unspecified (未定义)(2) Congestion (拥塞)(3) NoReply (未响应)在日常优化白过程中，RRC连接失败则增加了一种情况，变成了一种现象和三种原因，这新增的一种现象就是在路测中UE已经发起了 RRC Connection Request但经过T300超时并且N300超数，从而造成起呼失败。但这种情况也有可能系统侧已经进行了处理，RNC已经下发了 RRC Connection Setup但终

10、端没有收到。(注：前两种失败的原因在信令表示中均表现为RRC Connection Reject,只是其Cause值不同，需要展开信令来看失败的原因)下面针对各个阶段的失败，结合相关的信令与硬件组成，逐个分析各种失败的原因。3.1 RRC Connection Request N300+T300 超时(数)一路测UE 一直上报RRC CONNECTION REQ|后台信令跟踪上看不到任何信令过程(使用RTV工具的小区信令跟踪，不要使用IMSI进行信令跟踪，如果使用IMSI进行信令的跟踪，则有可能造成由于Common ID没有下来而不显示相关的信令，本原因针对系统侧根据没有收到 任何信令的情况)

11、。3.1.1 信令流程阶段3.1.2 常见原因可能是由于UpPch 所在位置存在干扰， 。 如果是特定终端出现该现象， 而其他终端没有问题，则1）随机接入过程出现问题，可能存在UpPCH勺干扰，导致网络侧解错终端上行包，使彳#RNC看不到任何消息（1） 首先检查NODEBRACHB十有无上行数据包，如果没有，但签名个数与签名碰撞个数一直在不停地增加，则可能存在上行UpPCHT扰。或者是统计LMTXUpISCP勺测量（其测量与在KP统计的POS扰统计一致，但精 度更高，测量为500ms一次统计，取整个测量时段的平均值，而 KP统计 的测量为15分钟粒度取平均值）（2） 通过CTT具本查UPPCH

12、k的干扰（3） 通过性能统计，查看UPPOSk的U叶扰统计（ 4 ）可以利用扫频仪在特定终端天线口处检测终端上行信号强度是否正常；如果是普遍现象，则需要检查UpPch 所在位置的干扰，如存在干扰则需要考虑对 UpPch 位置进行漂移。2）终端问题，重启UERf能否接入3） Node B 问题：重启基站3.1.3 解决办法对各地外场的数据分析后， Up 干扰有两大类型：1） 出现干扰平台（从当地整个网络来说，出现平台的概率并不高）， 但除去干扰平台 后的干扰曲线基本正常， 对于这类干扰通过基带匹配是能判断出干扰信号源构成的， 这 样基带可以：（ 1 ）匹配出干扰源小区，网优调整（方位角、俯仰角或

13、扰码、频点）（ 2 ）基带做干扰消除，以消除干扰。2） 干扰曲线整体抬高（从当地整个网络来说，出现干扰曲线整体抬高的概率较高）。对于这种情况可以采集数据看看基带匹配处理后的结果，需要以 Upsfifting 的方式来克 服此问题。3.2 RRC Connection Reject （ Congestion ）UE上报 RRC CONNECTION REQ但很快 RNC就回了信令 RRE Connection Reject,并且 其所带的Cause值为“Congestion”，产生这种原因主要是因为RRM算法的进行判决的结果，呼叫接纳控制（CAQ是无线资源管理（RRM）中的一个重要组成部分。CA

14、CM模块根据小区当前的无线资源和负荷情况以及呼叫的服务质量（QoS）,按照一定的算法，对新的呼叫请求可能产生的负荷增加量进行预测， 然后依据一定的随入准则， 决定对新的呼叫是允许随 入还是拒名接入。CAC的目的是在防止系统出现负荷过载和保证呼叫的服务质量（QoS）的前提下，尽可能保证并提高系统的容量。3.2.1 信令流程阶段信令发生的阶段如下图所示（图中标注的）NumRRCC ounKt J具体的信令节点如下:根据信令流程也就是说当RL Setup Response已经完成后，才会出现这种情况。重要信令解释信令消息过程解释rrcConnectionRequestUE发送RRC连接请求，请求接入

15、网络；rrcConnectionRejectRNC可能因一些原因无法为 UE建立RRC资源，因 此发送RRC连接拒绝，拒绝 UE的接入请求；3.2.2 常见原因小区码道资源不足，没有足够的码道为UE分配（特殊地：UE只支持单载频，而主载频上已没有剩余的码道资源）；干扰或功率受限，软资源接纳失败；传输资源申请或带宽接纳失败；3.2.3 解决方法针对两种不同的原因采用不同的措施来解决，下面分别进行描述1）资源不足造成的失败查看小区的话务量 （PS业务流量），看一下小区是不是真的存在资源不足（码道资源）；通过LMT查看一下功率资源情况，是否存在TCP资源不足的问题。如果存在小区的话务量不多，而且TC

16、P占用正常仍会出现拥塞造成的起呼失败，同时又不存在任何告警信息，则在动态数据库管理中查看服务小区状态，是不是 存在载频资源被闭塞的现象（在此处闭塞是不存在任何告警信息的）。查看公共测量值和配置的接纳门限，是否为功率干扰等软资源受限；查看小区剩余的码道资 源数看是否有足够的剩余资源如果是真正存在资源不足的情况，可以建议进行扩 容。2）小区硬件故障一般存在两种故障，一种是可以通过告警管理进行显示的故障，一种是小区本身 没有任何告警信息，属于隐性故障。对于有告警存在的，解决之；如果不存在故障，不得己而为之的方法是对小区或 RRU进行重启，以验证。3） CAC参数检查：如下图检查CAC相关参数。4）传

17、输资源受限查看Iub 口带宽大小是否受限；3.3 RRC Connection Reject (Unspecified )一旦RNC通过了 CAC的验证，RNC会请激Node B配置相应的无线链路资源，一般情 况下最少建立一条无线链路，在这个过程中，由于各种不同的原因造成的失败，RNC将给UE发送 Cause为"Unspecified”的 Reject。3.2.1 信令流程阶段信令发生的阶段如下图所示(图中标注的H.J.lir Ji：NEAPNBAFDCH-FPDCHPLX' H b-F心UXRKTlh>rfir|nrd | I xnrl I，-iramrlirrSu

18、n RXRR_C CYinncLTiiif etupJTAl'H 1KWC t.iinncLtinrj厘-4F lii r：Lili Trn.FBrt Iv.nr r、加，/RAlin L iiikTiulitfi Rafm：RRC (JaimiXon SetupCamptrfic jiJDCCH)-根据信令流程也就是说出现RL Setup Failure的现象，才会出现这种情况。3.2.2 常见原因基站小区的故障造成。3.2.3 解决方法解决基站小区的故障。3.4 No Reply原因造成RRC失败在CAC和RL Setup都已经完成后，RNC将发送RRC Connection Se

19、tup信令给UE,如果在规定的时间，没有收到UE的RRC Connection Complete信令，那么系统侧将会判断本次RRC过程失败，并且其原因值为“ No Reply”3.2.1 信令流程阶段信令发生的阶段如下图所示（图中标注的）SsrfirLvil | ! ajiH I，jirajTK-|rr重要信令解释信令消息过程解释rrcConnectionRequestUE发送RRC连接请求，请求接入网络；RadioLinkSetupReqeustIUB 口消息，建立无线链路RadioLinkSetupResponserrcConnectionSetup空口消息，RNC向UE发送RRC建立，建

20、立信令无 线承载资源RadioLinkDeleteReqeustIUB 口消息，删除无线链路RadioLinkDeleteResponse根据信令流程也就是说出现在RNC发出了 RRC Connection Setup信令后，并且在规定的时间没有收到 UE的回应消息，才会出现这情况。从整个信令的流程来看，RRC Connection Setup信令首先从RNC的控制面发出，经过部处理，通过 RNC与Node B之间的接口板，再经过传输线路到Node B与RNC的接口板，然后在Node B部处理，再通过 RRU经Uu 口到UE。在这个环节中每一个环节出现问题都会出 现没有响应的现象。从路测终端侧

21、看，终端未收到RRC连接建立消息，由于终端在上报RRC请求后，收不到网络侧 RRC建立，会重发 RRC请求，据此可以判断网络侧下发的 RRC建立消息终端未收到，需要在下行方向，排查问题，如 Iub 口传输丢包、FACH信道 配置不正确。3.2.2 常见原因1) RNC硬件存在故障RNC部处理板或对外的接口板正在问题，不能正确地将 RRC Connection Setup信令发送给 Node B2)传输存在问题从RNC到Node B之间的传输存在问题，传输误码较大，丢包较多，造成不能正确地 将 RRC Connection Setup信令发送给 Node B3) Node B存在问题Node B

22、的某个板子存在问题，有可能不能正确地接收 RNC传送来的信令，也能可能不 能将信令在FACH完整地传送给 RRU4) RRU存在问题RRU不能正确地接收 UE上发的RRC Connection Setup Complete信令，或是不能正确地 将RRC Connection Setup信令作传送给 UE5)参数设置存在问题? SCCPCH勺功率参数设置存在问题，导致 UE无确接收RRU传来的信令?由于下行功率不足或存在下行干扰等原因，UE未收到 RNC发送的 RRCCONNECTIONSETUP 消息；? UE 收至U了 RRC CONNECTION SETUP 消息，也上发了 RRC CON

23、NECTION SETUP COMPLETE 消息，但由于上行功率不足或存在上行干扰等原因，RNC未收到该消息；6)终端问题UE收到了 RRC CONNECTION SETUP 消息，但由于消息错误或 UE部错误等原因， UE 未发送 RRC CONNECTION SETUP COMPLETE 消息；排查方法：3.2.3解决方法查看RRC建立的上行时隙干扰情况，如果发现时隙干扰很大，查看 NODEB载扇是否正常，同时查看邻小区是否有大量同频邻区，若在话务量小的情况下，ISCP仍然很高，则干扰可能来自异系统，如：GSM, PHS等；若网络侧没有收到 RRC建立完成消息：则调整后台DPCH的期望接

24、收功率，同时利用网规网优手段，降低上行方向上的干扰；无效配置、配置不支持等配置错误：换个手机测试，若各厂家手机测试都有问题，将 本小区RRC建立消息和正常小区的 RRC建立消息进行对比，查看配置是否正确；若UE未收到RRC建立消息：调整后台下行最小发送功率，增加 UE接收到RRC建 立消息的几率，或者调整周围网络的覆盖、频点、功率等，尽量降低下行方向上的干扰，或 调整小区PCCPCH功率及公共信道、共享信道相关功率，确认 Iub 口传输无问题；一般采用逐步判断的方法来定位问题，步骤如下：1) 确定 RNC已经收到了 RRC Connection Request请求，并且已经发出了RRCConn

25、ection Setup 信令2) 确定RNC部的各个处理板之间数据传输没有出现问题，可以使用系统工具 RDS进行各个处理板之间数据包的传输统计，评估其丢包率。3) 查看传输告警，以及传输的部告警，确保传输没有问题4) 查看Node B的收包情况与 RNC的送包数量一致，同时确定Node B在FACH上正确完整地将数据传出。(使用工具LOGVIW和LMT)5) 如果上以都不存在问题，重启 RRU或更换RRU进行指标观察6) 确定终端是否收到 Node B传来的信令7) 增加SCCPCH勺功率，观察指标4.案例集锦本文汇总了 TD外场出现过的RRC!立成功率低的部分案例，并按照原因进行分类整理，

26、 以期对外场问题排查提供借鉴。本文所选案例中，部分参考了各地用服网优整理的RRC全立成功率低问题处理总结。4.1 CONGESTION原因：码资源不足【故障现象】RRC乎通率低，从信令跟踪上看，RNC攵到rrcConnectionRequest 请求之后，直接 下发了 rrcConnectionReject 消息。RRC!立 KPI 统计失败原因为 CONGESTION.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。【排查方法】(1) 在OMCR性能管理中，筛选 CONGESTION的小区；(2)提取KPI综合分析(CS/PS流量)，初步分析是否和码资源相关；

27、如下表CONGESTION次数高的时段，PS流量很大，很有可能是码资源不够。19:00:001小时197119713室外小区214201124865.220:00:001小时197119713室外小区489473194474.921:00:001小时197119713室外小区56650117139222:00:001小时197119713室外小区602557168818.323:00:001小时197119713室外小区301291165699.8（3） 通过LMT小区载波测量查看小区码资源配置及使用情况，并检查一下有没有载波（或时隙）被闭塞现象（也可在 OMCR NodeB动态数据管理中查看

28、）。【处理建议】如有载波（或时隙）被闭塞，则解开。小区扩容【典型案例】4.2 NOREPLY原因：BBU TBPH FPGA 异常【故障现象】RRC乎通率低，从信令跟踪上看，RNC出rrcConnectionSetup 请求之后，但没有 收到基站上报的 RadioLinkRestorelndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】1、在LMT上开启本地小区载波测量，看在小区空载情况下，同时存在以下情况a） UPISCP1 全为 127注：UpIscp值在50以下属于正常，

29、前四个值不使用。b）上行时隙ISCP （底噪）值很大注：空载时，Iscp值在-110左右属于正常c） 上行时隙RTWP后四天线值很大注：空载时，BBU RTWP值在-110左右属于正常）2、在OMCB上查询基站通知消息，可以看到 TBPH单板有大量“上行 IQ Link链路误码 （198081164）” 通知上报。3、采集RRU命令日志， 看到testRTWP命令输出值正常注：正常情况无 UE接入时，RRU Shell显示的RTWP是底躁，应该在-69左右（此时DSP 监控工具显示的底躁应该在 -110dB左右），若低于-80dBm,则基本可认为 RRU无上行信号； 若大于-60dBm,则底躁

30、过高，存在干扰。【处理建议】规避方法：复位小区所在 TBPH单板。具体原因仍在定位。类似问题如果需要采集数据，请按以下文档采集【典型案例】4.3 NOREPLY原因：干放干扰【故障现象】RRC乎通率低，从信令跟踪上看，RNC已经下发了 rrcConnectionSetup 请求，且能 收到基站上报的 RadioLinkRestorelndication 消息，但收不至U UE上报的 rrcConnectionComplete 消息。RRC1 立 KPI 统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】2、从LMT小区

31、载波测量观察，UpIscp和上行时隙ISCP功率正常。3、测试终端为凯明，测试时发现在R01覆盖区域，各业务连接正常，但在干放覆盖区域，手机一直无法接通。【处理建议】形成书面报告递交移动，推动干放厂家积极解决。【典型案例】4.4 NOREPLY原因：FACH 出窗RRC乎通率低，从信令跟踪上看，RNC已经下发了 rrcConnectionSetup 请求，但没 有收到基站上报的 RadioLinkRestoreIndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】1、打开LMT本

32、地小区载波管理，如下图；2、选中RRC建立失败的小区载波，点击资源分配查询，查询载波所在基带板，如下图，载 波0在TBPE2上；3、在Logview中打开相应的基带板，待界面左上角的指示由红色变成蓝色之后，输入 TbpaInfoShow （注意大小写）命令，确认目标小区是否在该基带板上处理。如图：4、确认基带板上只有目标小区，没有其它小区（注：上图中，还有另一个小区 20289驻留）之后，输入FpmShowFachInfo （注意大小写）查询该基带板的收发包情况：克冲4 后讲口 工反工，鼻匚C WHtlC '1 I担ll 的 *_*!lualue - 7H « HK4P -

33、"HBCOmW :29M-W=I2 11:5A :2/：F” 喈仙咛 whl 时修町pn Farh mm Kji.iCii_iflh 匚 Zh 而 hMftar 1* ;3?fl1 nJCfy _ 1卜1q一 drffdch ftfcijpFPlFrdineHu n=Jr d席就11 安igHlimtMlUilli*JtciiRpcuDi iHciiirSarmin-a* dLiFachRecuDLTrc：h41fiii7HLJii- dSen di i mF fid jus tfHun二 9Lrrur In+口 二“一三一三一“ dirt ichDitiufffniiMB-修

34、71; 口* duFFdchDliufFHun Him=Q* d bfl- dch Li； ut l-Hu lit rrHui n-V« duff acnuif raneel nlrr Hur-«事 dchDlFi-JivrCrctrrHiiH. 口* 4底前eihfg*1 i>nFrrHiiBH 0* d uf ach DlLF rd met dr ly Hui n二。* ditf acnuniF raneL atPMLin 口 dW jch DI r i"diii>Tiiiardrl ifMiJfi »* drfdChDI FKdim&g

35、t;TDul a<r i"iHi.in- 9* dllf iChHUTfiErrMura=a* d lM ac h UL1 Fs Lrr hflu m=9* duff dchFreiGuff IndeMEirirlNiJii-Me a* clwf dChStniiULFr-vwTcIIjcEfrKim=0* duff actiDLDataLoEthiuR-g* d lvR i>I2U B Fr Er r!Hli it a* dirfdcn&LTtlErrftiiii=A* d*d口iliituHuklrfcM* II* wfn de u r r i n utx E

36、rrNw n-0* du+achS;er 1 iJDataTaDspn-01*r|pn i-jcnIflrif I) =!= =2i=-=i=-=-UdlUP &J a (1工3中岳?5、如果该图显示红色区域值数值相差很少，说明FACH几乎没有出窗；否则，说明FACH出窗严重（即 dwFachDLFrameTooEarlyNum, dwFachDLFrameTooLateNum 两个值比较大）。由于rrcConnectionSetup消息是走FACH信道的，这可能导致 rrcConnectionSetup消息发 不到UE,从而导致 RRC建立成功率降低。6、如果该基带板上同时存在其它小

37、区，可以先闭塞其它小区相应载波，使得该基带板上只 有目标小区，然后输入 FpmClear （注意大小写）将基带板原来保存的数据清空，过一定 时间之后重新统计基带板FACH收发包情况。注：上述方法只能排查FACH是否存在出窗。若要检查 FACH从RNC到NodeB 有没有丢失，需要与RNC侧该小区FACH收发情况进行比对。【处理建议】FACH包出窗有几种原因RNC侧老的用户面处理板 RUB板晶振有问题，按附件排查。典型案例：升级 V2.00.200版本之后，有一块 RUB单板晶振异常，导致该 RUB板上一块DSP芯片上所有小区 RRC建立成功率降低。RNC的控制面发给 NodeB的TOWS和TO

38、WE跟发给用户面的不一致，导致 NodeB 这边FACH出窗。按附件排查。备注：现场修改后证明对出窗没有改善，建议出现出窗问题时在目前非卫星传输配置下不必修改。传输丢包问题按照传输问题解决。4.5 NOREPLY原因：RNC GUIM单板异常【故障现象】RRC乎通率低，从信令跟踪上看，RNC已经下发了 rrcConnectionSetup 请求，但没 有收到基站上报的 RadioLinkRestorelndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】1、OMCR RRC KP

39、统方f TOP10显示，多个小区出现 NOREPLYM因的RRC连接失败，没有找 到明显较多的TOP小区。一12009-05-0112712001002009-05-0210652002422009-05-0214303001012009-05-0311322001442009-05-0310652001182009-05-0410652002042009-05-0414303001392009-05-0414303001082009-05-0511482002142009-05-0515611001732009-05-0513593001092009-05-0512253001022、从No

40、deB侧观察，UpIscp、ISCP RTWP功率水平都处于正常围。3、在RNC侧用户面板上观察 FACH传输信道同步帧收发情况，收到的传输信道同步响应帧 数目明显小于发出的请求数目。4、从NodeB基带板FACH统计看，不存在 FACH出窗现象。【处理建议】可能原因RNC GUIM单板异常处理方法：对问题小区 RUB板经过的GUIM单板发起正常倒换操作。 【典型案例】4.6 NOREPLY原因：传输问题导致的RRC接入成功率低【故障现象】3-5944站点 RRCU半也率低，从筑计上看存衽FACHf多的FACH出直。(1)分析告警，发现该站点在版本升级后，一直有传输告警未恢复。站点名称(局向)

41、单板类型发生位置告警码05944_六里桥IIASUBNET3,TP725944,MODULE1,1/2/15E1链路电信号丢失(LOS ) (1029)05944_六里桥IIASUBNET3,TP725944,MODULE1,1/2/15E1链路电信号丢失(LOS ) (1029)05944_六里桥IIASUBNET3,TP725944,MODULE1,1/2/15E1链路电信号丢失(LOS ) (1029)05944_六里桥IIASUBNET3,TP725944,MODULE1,1/2/15E1链路电信号丢失(LOS ) (1029)(2)分析该站点配置，可以知道：由于该站只有一条 E1是好

42、的，怀疑是IMA带宽 不够，业务数据传输占用带宽较大情况下，FACH信道带宽不足导致传输延迟，从而出窗。现场在排除传输告警后，性能恢复为正常了。【排查方法】略。【处理建议】略。【典型案例】吴海洋处理5944站点。4.7 CONGESTION REJ原因：RNC6接入成功率降低至 90%【故障现象】从7月1日起RR诞接建立成功率下降 6%£右。7月1日到22日RR诞接建立成功率在90虬 右。经确认，6月30日RNC6F未做任何相关的操作修改。根据RRC!接失败原因值进行分析，发现 RR选接失败原因值为congestion占的比例最 大.连续三日对呼通率低 TM占点进行扫频，都未发现有外

43、部干扰， 同时最严重的5个小区LMT跟踪在不存在干扰、 RR端度不高、无告警情况下，进行。拨测发现RR圆接Reject还存在一定的概率。【排查方法】1,抓取信令跟踪和管理日志，发现并没有RRMJ打印，缩小围为UCPMC块出错。2, 打开DCM康统的UCPMC印，发现是UCPMC wNumOfDchUe过最大值2500而引起的 RRC REJ.(2)2009.07.24 21:05:56模块：RNLC_UCPMC - Recieve arrcConnectionRequest,Start to Check is the UeId already existing in the RNC? in R

44、nlcC2DRrcConnReqMsgHandler(1)2009.07.24 21:05:56模块：RNLC_UCPMC - No SamUe in the RNC,continueRRC connect proceed in RnlcC2DRrcConnReqMsgHandler.(1)2009.07.24 21:05:56模块：RNLC_UCPMC - -UCPMC-gptImsiUeStatusList->wNumOfDchUe >= RNL_maxNrOfDchUe!(2)2009.07.24 21:05:56模块：RNLC_UCPMC - -UCIC- The numb

45、er ofNoPchUser reach max count in RnlcC2DRrcConnReqMsgHandler!3, 对于不能才T开全部DCPMT印的采用存检查方法来确认该值是否异常。【处理建议】目前初步怀疑是该单板RC版的个体问题。【典型案例】:经过昨晚前后方排查，已经定位，是1/2/6槽位RCB2号CPUK统gptImsiUeStatusList全局变量超出2500最大值引起，当UE择到该RCBI板时，会导致RRCREJ,其他单板则不会。 现场已经通过复位 RC规避，经过测试未发现 RRC REJt况。外场目前把该单板寄回所测试存复现。4.8 NO REPLY原因：10241小

46、区 RRC REQ同时重复上报【故障现象】(1)接入成功率小时平均在80%£右10241室外小区0.00%53.85%10241室外小区0.00%26.92%10241室外小区100.00%93.33%10241室外小区100.00%68.75%10241室外小区100.00%100.00%10241室外小区100.00%94.44%10241室外小区100.00%100.00%10241室外小区100.00%100.00%10241室外小区100.00%89.66%10241室外小区93.75%90.91%10241室外小区100.00%95.74%10241室外小区100.00%

47、92.86%(2)无告警，通知，FACHE窗也不明显【排查方法】 获取该小区的彳t令，发现 RRC REQ隔10ms或者同时上来。2OiO9-O7-20 21 22 53 059It Wrrct*TiMieii 口nJ；电电u*工七 Rr cR* qV*l =Tm-TBOl W9BitK4i限ZOOS-OT-ZB 21：ZZ 50.059La ANUrrcC ojin« c li ord* qn些工t!KrdK*qY*L =.THSl：?dOlSe9B1DEZ4LUu2003-07-20 21-22 5J. 130RHCRadi bLi rdf t tupR* qs±e 3

48、 ;TBSIiTSOlCCCiB10241lul£1)09-07-26 2r22.5fl.21UIn AHLBftdi 0L1t tuipKt spons 电THSI:76ClLSe9B341工心2009 O7-2S 21: £2,S3.309OS RHCFl 晅C uaUHE C I I1电THH7CI。1侬 R10241Uu20O9-O7-2E 21:22 52,109In SHErrcConMcti 0DBaw»tRr由eqYil =.THSI:7e01K9B10241Un2003 07-28 21 £2 &E.119Out EHCflCu

49、JLXKl 11 UUtlUpTHSI.70Olffi9I>10£41Uu2009-07-20 2J 22 52 119h ± WCl!"rctcit 仃的 1 呼TISI'TSOI 或10241限2003-07-28 21.22 52.109In BHCrrcC onm c t: gf是lRrcft*QY*l .THSI.TeOlSZSB10241W2003-07-26 31:22.54.1591Xi e EHCrr-eC立e ti白49i呼T临1:78。1国年10241Ifti2期4JT-2E 21:没54的In XNLrrcC ojim c t

50、i ord( qu* 工 tIKrcKtqYd.=.iFisi：7eciiyB1D24IUu2000-07-26 21:22 51 140工, MCltcC ohm c ti orJ；虺二七RrcR 电=,=TKSL78。19gB341IJuZ0O9-S-2E 21:22 55,209Ii SHCrarcCMMcti onB«<UAxttRrcR(flY*l =.TIISI: 7801629B10241Uu2009 OT'ZO 21.22 S4.Z19In MCE-iCuJLl；H!U 11HBj cRt qY*l j 一THSI.TOOlD10241Vu20D9-C7

51、-2E 21 22 57 17QOut RNCRfldi oLi rdcD el# t i *nRtai st tTRSIT m 1929B10241工小2009-07-25 2J.22 5T.ZI9In XHCKidiciiLirdd>el«ti4nILestu. aTflSI.T6aiffi9B10241工tfb2DO9-OT-2B 21 23 DI 569g R HErrctonMcti cinE电电1u*tlfeRrReqVil =TBSI-78aiSP9B10241UuZQO8-OT-2B El:E3 01.960I> ABUrrcCoiiMclL Qhl渔 q

52、u*slWdfttqYil =.TflSl：78aiBZ9B10241Uu2000-07-26 21:23 01,589工鱼MUM e&=ur 5 ciktRtE&r t工hj江邓口th 1乐1041的20O9-C7-2I- 2：£3 01 &I9Out KKtdi 静 Li nkS 电 tupK- q'its:THSI:70O1K9B1024 L工心磔m 07'2C ei o Ol.MQIn MCRcdiL vLl LlllS E tugR/ 3修3h1 eTFICI:7QOia：5B10241工皿2009-07-28 2123 rli 75

53、QOut ENTFTcCoMecti onSl TRSF7H 匿9B1®4L岫£009 07-20 21ng百Oilt BHCE-j-cCujllheC 11THSI.70Oiee9I>10£4l如2009-07-20 P123 01 63AOut rutrrctoju»cti 仃n£*，upTFST 7001 中年ia?4i11ZQO8-OT-2B Z1：Z3 ：03.&39Is KMCrrcC&nMcti dhl庵 qu青 itiKrcRiYil =.TIISI：78giBZ9B1OZ4IUu20CS-C7-26 21

54、:23 Q3.»Q工 q KHCrr-eCctiqun u tqRrcR电qV4.TRSI:70O1KQBUu2UOa-O7-2l: 2：23 05.MyIn AHCrrcCoimscti ohi；mu*s.tlKrcK(Y*l =.TflSI：70OlK9B10241Uu2OO0-O7-2S 因:33 05 看叩捻电EHCLT-cCC <1。店"呼TI£I:7801CeOB341Uu2000-07-26 21:23 O5.6S9In XHCrrcCoimsdi ohf；tu*ittRrcfiiqYal =.THSI:76O16e9B10241UuZOOB

55、OT-ZO £1.23 0T,T29Iji SHUri-cGuJuwc li(Hi=. _THSX.7Q0L629B1OZ4IVu一ncni t oredlCell srre? ent = Q9 .currentCellicdeSeci ficlnfo机 J tdd65atimislcitlSCPTresnt - 0LQpr g nr yCCFCM_ESC FFr 心号 nt = 1. J vSdOlInCri ti c-J.Ek tens ionsprifftftryCCPCH_ESCF = 33(2)使用Message Trace跟踪该小区所在 CCM隘统的RNLC-AGENT勺

56、板间消息 发现在149ms时同一个UERRC REa10241和10161小区上来。Message Trace工具暂时未发布给外场，出现类似问题时向家里要。 分析10241和10161小区配置的异同点10241小区主频2022.4 ,扰码90;10161小区主频2022.4 ,扰码90;两者相同。站点距离相隔1.6KM。这两个小区建立在同一个 RU皈和CCMP统中，所以能通过小区基本的信令跟踪跟上，如果小区建立在不同的 CCMP统，则信令跟踪无法跟到重复现象。【处理建议】(1)临时手段是修改RACHJ时隙或者码道，避免了同时解调的可能。(2)网优优化处理，需要修改扰码频点规划，把其中一个站点的

57、小区扰码改掉。【典型案例】RRC1接成功率低4.9 NOREPLY原因：3015小区(未定位)【故障现象】1一2009-07-15 00:00:002009-07-15 01:00:003014室外小区100.00%100.00%2009-07-15 01:00:002009-07-15 02:00:003014室外小区12.50%100.00%2009-07-15 02:00:002009-07-15 03:00:003014室外小区100.00%100.00%2009-07-15 03:00:002009-07-15 04:00:003014室外小区20.00%100.00%2009-07

58、-15 04:00:002009-07-15 05:00:003014室外小区28.57%100.00%2009-07-15 05:00:002009-07-15 06:00:003014室外小区11.11%100.00%2009-07-15 06:00:002009-07-15 07:00:003014室外小区25.00%100.00%1、2、3、统计指标该站的3个扇区RRC连接失败率较高：3014站点各小区RRC连接成功率走势图90.0DH 惭70 00% 5ao幅 5000/40 00% 3ag帮20 OOKr-RM强接建立成功率-3白工耳胴生 养建立式功率-3。1510.8% Q8%对

59、该站点告警信息进行统计，在7月份该站点无任何告警；对后台LMT进行跟踪：3015扇区:主载波UPISCP基本正常，干扰功率在-110左右，但观察一段时间发现UPISC刖干扰功0. 0：-109. a：-lc>9. 9：U. DiOl OiO. D:IL De-109b 8 =-109.4:0. 0*0.0*0. OsOLO：0：-lO9. 5;-1 g, E：Q, 0：0k r：0. 0：(i一inQ9一1dn ivn门*力rt-1 0 ：-TOr B：-7X2：Or 0:0. 0:0B 0：0. ：' l：-79. 8：-33.9:0, :0. 0:0, 0:0.。：尸技工力且工 D_lz3 心电.5 1138.电 t 广.I。二 fL Qid Q :d 立:0. 0;-101> 47:0. 0:0> 0:0. 0:0. 0:0. D !-109. 3 :-109. 也 必0:0. 0：a. :率会在某一时间会有突发性的较大波动,24:24:2曜：2U: J4:24:24:2J:2i :2J:24;Le：I.J:23:24.2L:24124 :24:56:68:G9:6B :S6:G6:87:的U击：24:24:23: