RRC常见问题处理思路

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

2、C连接建立请求，如果接受，则再判决是 建立在专用信道还是公共信道。对于RRC连接建立使用不同的信道，则RRC连接建立流程也不一样。这样一来，对于RRC连接的信令过程可以大致分为以下几个过程：1）呼叫接入控制过程（主要由UE发起请求，RNC来控制）2）无线链路的建立过程3） RRC建立完成过程RRC连接过程的基本信令流程如下图：.部消息跟踪）：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 oLinkSetupKsspongeIn RHTRadi

4、 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&ctlransferD

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

6、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,upRe sp qus e-

7、.FpSIni tKaRH1£ <.fpSIftitR到S i gT 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 anS t LuC om pl ± t 坦TSigTyp&=3 :RNLC_UE_NAME ： Interfit e=123. UnknovrnSigTypa=3 :RN1JC_IIE_HAM

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

9、ecified (未定义)(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没有下来而不显示相关的信令，本原因针对系统侧根据没有收到 任何信令的情况)。3.1.1 信令流程阶段3

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

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

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

14、S ,按照一定的算法，对新的呼叫请求可能产生的负荷增加量进行预测，然后依据一定的接入准则，决定对新的呼叫是允许接入还是拒名接入。CAC的目的是在防止系统出现负荷过载和保证呼叫的服务质量（QoS）的前提下，尽可能保证并提高系统的容量。3.2.1 信令流程阶段信令发生的阶段如下图所示（图中标注的）MiimKRr上 ail具体的信令节点如下:2针）NUAP! t No也 Ufadlb l Ink U|jp 的阴根据信令流程也就是说当RL Setup Response已经完成后，才会出现这种情况。重要信令解释信令消息过程解释rrcConnectionRequestUE发送RRC连接请求，请求接入网络；

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

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

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

18、XRR_C CYinncLTiiif etupJTAl'H 1KWC t.iinncLtinrj厘-4F lii r：Lili Trc.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 Setu

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

20、ionSetup空口消息，RNC向UE发送RRC建立，建立信令无 线承载资源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 S

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

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

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

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

26、文汇总了 TD外场出现过的RRC!立成功率低的部分案例，并按照原因进行分类整理, 以期对外场问题排查提供借鉴。本文所选案例中，部分参考了各地用服网优整理的RRC全立成功率低问题处理总结。4.1 CONGESTION原因：码资源不足【故障现象】RRC乎通率低，从信令跟踪上看，RNC攵至ij rrcConnectionRequest请求之后，直接下发了 rrcConnectionReject 消息。RRC!立 KPI 统计失败原因为 CONGESTION.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。【排查方法】(1) 在OMCR性能管理中，筛选 CONGESTI

27、ON的小区；(2) 提取KPI综合分析(CS/PS流量)，初步分析是否和码资源相关；如下表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小区载波测量查看小区码资源配置及使用情况，并检

28、查一下有没有载波（或时隙）被闭塞现象（也可在 OMCR NodeB动态数据管理中查看）。【处理建议】如有载波（或时隙）被闭塞，则解开。小区扩容【典型案例】a东水西调3扇区.doc4.2 NOREPLY原因：BBU TBPH FPGA 异常【故障现象】RRC乎通率低，从信令跟踪上看，RNC出rrcConnectionSetup 请求之后，但没有 收到基站上报的 RadioLinkRestorelndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】1、在LMT上开启本地小区载波测量，

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

30、应该在 -110dB左右），若低于-80dBm,则基本可认为 RRU无上行信号； 若大于-60dBm,则底躁过高，存在干扰。【处理建议】规避方法：复位小区所在 TBPH单板。具体原因仍在定位。类似问题如果需要采集数据，请按以下文档采集.aRR建立成功率低数据采集要求（0703更新【典型案例】石家庄市电炉厂.do c4.3 NOREPLY原因：干放干扰【故障现象】RRC乎通率低，从信令跟踪上看，RNC已经下发了 rrcConnectionSetup 请求，且能 收到基站上报的 RadioLinkRestorelndication 消息，但收不至U UE上报的 rrcConnectionCompl

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

32、报的 RadioLinkRestoreIndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。 【排查方法】1、打开LMT本地小区载波管理，如下图；2、选中RRC建立失败的小区载波，点击资源分配查询，查询载波所在基带板，如下图，载 波0在TBPE2上；Ifil E * c d 口壮包胖 箱叫鼻幅看媒由1图ST同!tt*w，口史luMTnl周总力: 2制工地丁区：." 露器 占最感 管 Cdlj.'3、在Logview中打开相应的基带板，待界面左上角的指示由红色变成蓝色之后，输入

33、 TbpaInfoShow （注意大小写）命令，确认目标小区是否在该基带板上处理。如图：日 *T2.14.4、确认基带板上只有目标小区，没有其它小区（注：上图中，还有另一个小区 20289驻留）之后，输入FpmShowFachInfo （注意大小写）查询该基带板的收发包情况： Uifl 4和虫 石仰。.T Hl-i诲匚口 杂肋Q）j： L理亘典亘血雪画miUMlHO口码 fWi 12 11 ：;Ai?ligF|iii$hnir4Chli)ro=4=当="=Fpm FachJ n t DF nin 1 a.r hNkv*- ma 11 nfiH.d M dch Uwe uPF r ii

34、iiuHu ii 59110rdrf 鼻七hM 1川口勺 igt Jdirt*d ” 411 R ec yCP L痴 de Sy n 匚Mun=*diff achKec vEL FrDhSyncFtun-1Z8734MdiMd 11 w A<d ju< t M>un审“IV FMh=oduiFach m LE uf FFu 11 HurdiM achuf FHa xS ize LrrHu n=u*dirt acnliltiiitlHiillrtuA-B*dwFjchDL GuFFMiWrrHun 口FrjniprFftFrrlliiM=a.dtif dcti DLFrd in

35、eC rc Lrr Mu m-u duff ecnlltf rjrwLBnL!Fr-HuH« diM jtirhDlFidjm*l .irlHNn* iluiFdchDI Frdnrl .itPHura* aclil?LFrdme I QaLdrlyHum* dut achUiLt rd w I do Late Nun, dwficMLfFlErrMiri* ditfFhHTKFrrWifii* dwFacIi F r 用 eBuff Inripw Erribii i n，d ath !£ en dh I-nt rr btun-。* duf jchStmdULf rm

36、87;rohUclLrr Nuni -餐 dK cnm cit3i* 口* duHiPCQBfn Err Mura= ft* d Lif dch l>L 1 ti Err liu ro= u* di4t ach Jni aHuliHum-。* 1力WHiirnnnKFifiFNu%* d mFach S pin iW a ta To Dsp FrrNi i ra- ft* = Fpn Fach Infu ,= = ujiufe oi3 a uw 巾r5、如果该图显示红色区域值数值相差很少，说明FACH几乎没有出窗；否则，说明FACH出窗严重（即 dwFachDLFrameTooEarly

37、Num, dwFachDLFrameTooLateNum 两个值比较大）。由于rrcConnectionSetup消息是走FACH信道的，这可能导致 rrcConnectionSetup消息发不到UE,从而导致 RRC建立成功率降低。6、如果该基带板上同时存在其它小区，可以先闭塞其它小区相应载波，使得该基带板上只 有目标小区，然后输入 FpmClear （注意大小写）将基带板原来保存的数据清空，过一定 时间之后重新统计基带板 FACH收发包情况。注：上述方法只能排查 FACH是否存在出窗。若要检查 FACH从RNC到NodeB有没有丢失，需要与RNC侧该小区FACH收发情况进行比对。【处理建议

38、】FACH包出窗有几种原因RNC侧老的用户面处理板 RUB板晶振有问题，按附件排查。VTCDJ DS时钟手动 检测方法.doc典型案例：秦皇岛升级 V2.00.200版本之后，有一块 RUB单板晶振异常，导致该RUB板上一块DSP芯片上所有小区RRC建立成功率降低。RNC的控制面发给 NodeB的TOWS和TOWE跟发给用户面的不一致，导致 NodeB 这边FACH出窗。按附件排查。a修康UALH窗口大小方案V2.doc备注：现场修改后证明对出窗没有改善，建议出现出窗问题时在目前非卫星传输配置下不必修改。传输丢包问题按照传输问题解决。4.5 NOREPLY原因：RNC GUIM单板异常【故障现

39、象】RRC乎通率低，从信令跟踪上看，RNC已经下发了 rrcConnectionSetup 请求，但没 有收到基站上报的 RadioLinkRestoreIndication 消息。RRC建立KPI统计失败原因为 NOREPLY.RNO本：V2.00.200e2 ,基站版本： V2.00.200fP003 。【排查方法】1、OMCR RRC KP统方f TOP10显示，多个小区出现 NOREPLY（因的RRC连接失败，没有找 到明显较多的TOP小区。2009-05-0112712001002009-05-0210652002422009-05-0214303001012009-05-03113

40、22001442009-05-0310652001182009-05-0410652002042009-05-0414303001392009-05-0414303001082009-05-0511482002142009-05-0515611001732009-05-0513593001092009-05-0512253001022、从NodeB侧观察，UpIscp、ISCP RTWP功率水平都处于正常范围。3、在RNC侧用户面板上观察 FACH传输信道同步帧收发情况，收到的传输信道同步响应帧 数目明显小于发出的请求数目。4、从NodeB基带板FACH统计看，不存在 FACH出窗现象。【处理

41、建议】可能原因RNC GUIM单板异常处理方法：对问题小区 RUB板经过的GUIM单板发起正常倒换操作。【典型案例】S长沙R即连接成功率低问题处理息结日4.6 NOREPLY原因：传输问题导致的RRC接入成功率低【故障现象】北京3-5944站点RRC呼通率低，从统计上看存在 FACH较多的FACH出窗。（1）分析告警，发现该站点在版本升级后，一直有传输告警未恢复。单板类站点名称（局向）型发生位置告警码SUBNET3,TP7205944_,六里桥IIA5944,MODULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MO

42、DULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MODULE1,1/2/15SUBNET3,TP72E1链路电信号丢失(LOS ) (1029)05944_,六里桥IIA5944,MODULE1,1/2/15E1链路电信号丢失(LOS ) (1029)a当前所有告警SUBNET 3,TP72 =51)(2)分析该站点配置，可以知道：由于该站只有一条 E1是好的，怀疑是IMA带宽 不够，业务数据传输占用带宽较大情况下，FACH信道带宽不足导致传输延迟，从而出窗。现场在排除传输告警后，性能恢复为正常了。【排查方法】略。

43、【处理建议】略。【典型案例】吴海洋处理北京5944站点。4.7 CONGESTION REJ原因：长沙 RNC6接入成功率降低至 90%【故障现象】从7月1日起RRC1接建立成功率下降 6%£右。7月1日到22日RRCi接建立成功率在90虬 右。经确认，6月30日RNC6F未做任何相关的操作修改。根据RRC!接失败原因值进行分析，发现RRC1接失败原因值为congestion占的比例最大.连续三日对呼通率低 TM占点进行扫频，都未发现有外部干扰，同时最严重的5个小区LMT跟踪在不存在干扰、RRU1度不高、无告警情况下，进行。拨测发现RRCI接Reject还存在一定的概率。【排查方法】

44、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 RnlcC2DRrcConnReqMsgHandler(1)2009.07.24 21:05:56模块：RNLC_UCPMC - No SameUe

45、 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 number of NoPchUser reach max count in RnlcC2DRrcConnReqMsgHandler!3, 对于不能才

46、T开全部DCPMT印的采用内存检查方法来确认该值是否异常。.查看内存力怯，mr【处理建议】目前初步怀疑是该单板RC版的个体问题。【典型案例】RRC长沙：经过昨晚前后方排查，已经定位，是 1/2/6槽位RCB2号CP田统 gptImsiUeStatusList 全局变量超出2500最大值引起，当UE5择到该RCBI板时，会导致 REJ,其他单板则不会。现场已经通过复位 RC规避，经过测试未发现 RRC REJt况。外场目前把该单板寄回所内测试内存复现。4, 8 NO REPLY原因:沈阳10241小区RRC REQ同时重复上报【故障现象】(1)接入成功率小时平均在80%£右10241室

47、外小区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%92.86%(2)无告警，通知，FACHB窗也不明显【排查方法】 获取该小区的彳t令，发现 RRC

48、REQ1隔10ms或者同时上来。moni t oredtellsFre ent = 0(2Oi(K-O7-20 21 22 53 059In WrrctoTUWicit 口曲电u*tli! Rr cR* qV-d. sTfl5I-78aig?9B10241Uufeo'Oy-07-ZS 21.'£2 53.069ia merr-cC ojim c ti ord迪 quasiWch*qY*L =.THS1：?8OI£29B10241.Uu20OD-O7-2E 51:02 S3, HOOut RHCReWi oLi rJ£ t lupRt qs±

49、;c s ;TH£I:7901CeOB102412009-07-26 21:22 &J 2iyIl祝R " di oLi rtkS ± tupK 史 spons $THSI:78dLS29B341工赴£MH 07-20 ”住 300Gut RHCft uaUME C II 白tuyT«CI:70OLa!5B10241必E0O9-OT-2e 21:22 52,109In SHErrcCoiMcti onf；eflu*E.tlRrcR*flY*l =.TIISI: 7001929510241Un2009 07-20 21 22 52.119

50、Gut RHCfiCuJLXhec 11 uuSelUpTHSI.70Olffi9I>10241IM20O9-O7-2F ”竺 S? 119Out RHTrrct onne cit12TFSI'Taai 英相341lAiZOOB-OT-ZB £1.22 52.109In BM1：rr-cC ojim c ti gf隹 qu* 工 t1RtcR*<1Y*1.THSI.T6O1SZ9B13241w20O9-C7-2E 21:22 51.1 钝Out RHCrr-eConMcti 白/«：1 呼TBSI:70aiKe&1341瓜2UD9-CJ7-2E

51、21:22 54.1In XNCrrcC onn« c ti ord*；。u*itIKrcKtqYil =.insi：7eciLfezyB10241Ihi2000-07-2E 21:22 Bt. HOI n MICfr-eC bhn曲 c ti crJ；也电壮士 二也ERreR电4丫皿，.TISI:78OKe9B侬41W2009-07-28 21:22 &5,2A9In SHCrrcConMcti onB«<u«t<Br(£W =.THSI:76OL929B10241Uu2009 07-20 21.ZZ M.2I9u me上也 Cuj

52、lkhk li inJMqsitHBj cRfe<1VJ.THSZ.70O19E9»113241Mi2DO9-C7-2E 21 22 57 17AOut RNTRsdi oLi nlcD ele t i *nfieai si. tTRSIFOI 笈晒ia?4i工小ZOOB-OT-Z6 21.22 5T.Z19in meEltdiciiLirLkDikltti«nfL#s>u.THSI.T6O19ZIB1024 L32DO9-O7-2B 21 23 DIm RMrrct®nrb*cti onBsvLfcut电RtnR 巾Y曝】=TRSI'78ai0P9B10241IRiZQO9-OT-2B El：E3 01.360I> BMCrrcC ojim c tiu*itlKrdft*qY*l =.TIISl：7Baiffi9B1OZ4IUu2003-07-26 21:23:O1.58Q1I> MIUfi *t 4：wr 的 ciktRtj-frr t工RSI:4g口77”段 一loeiiUu2MB-O7-26 21:23 01.&19Out幽Ktdi oLi niS etupfi* q'lts:THSI:7eaiK9B1D24I工心2003