(2) 使用Message Trace跟踪该小区所在CCMP系统的RNLC-AGENT的板间消息
发现在149ms时同一个UE的RRC REQ从10241和10161小区上来。 Message Trace工具暂时未发布给外场，出现类似问题时向家里要。
(3) 分析10241和10161小区配置的异同点 10241小区主频2022.4，扰码90；
10161小区主频2022.4，扰码90；
两者相同。站点距离相隔1.6KM。
这两个小区建立在同一个RUB板和CCMP系统中，所以能通过小区基本的信令跟踪
跟上，如果小区建立在不同的CCMP系统，则信令跟踪无法跟到重复现象。 【处理建议】
(1) 临时手段是修改RACH的时隙或者码道，避免了同时解调的可能。
(2)网优优化处理，需要修改扰码频点规划, 把其中一个站点的小区扰码改掉。
【典型案例】
沈阳 RRC连接成功率低
4.9 NOREPLY原因：北京3015小区(未定位)
【故障现象】
本地小区开始时间 结束时间 识别码 小区类别 RRC连接建立成功率 100.00% 12.50% 100.00% 20.00% 28.57% 11.11% 25.00% RRC连接建立成功率(业务相关) 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00% 2009-07-15 00:00:00 2009-07-15 01:00:00 2009-07-15 01:00:00 2009-07-15 02:00:00 2009-07-15 02:00:00 2009-07-15 03:00:00 2009-07-15 03:00:00 2009-07-15 04:00:00 2009-07-15 04:00:00 2009-07-15 05:00:00 2009-07-15 05:00:00 2009-07-15 06:00:00 2009-07-15 06:00:00 2009-07-15 07:00:00 3014 室外小区 3014 室外小区 3014 室外小区 3014 室外小区 3014 室外小区 3014 室外小区 3014 室外小区 1、 统计指标该站的3个扇区RRC连接失败率较高：
2、 对该站点告警信息进行统计，在7月份该站点无任何告警； 3、 对后台LMT进行跟踪：
3015扇区：
主载波UPISCP基本正常，干扰功率在-110左右，但观察一段时间发现UPISCP和干扰功率会在某一时间会有突发性的较大波动，
辅载波：经LMT观察UPISCP一直较高，干扰功率也较大，
UpIscp测量值 干扰功率 42:119:118:113:111:109:103:101:95:96:94:89:85:84:82:78: 0.0:-103.2:-109.1:0.0:0.0:0.0:0.0: 49:119:118:112:111:108:103:101:96:96:94:87:84:84:83:76: 0.0:-102.5:-107.2:0.0:0.0:0.0:0.0: 53:119:119:114:112:109:104:101:96:95:93:88:83:83:82:76: 0.0:-103.7:-107.9:0.0:0.0:0.0:0.0: 52:119:118:112:110:107:103:100:97:96:94:88:83:85:80:78: 0.0:-102.9:-108.4:0.0:0.0:0.0:0.0: 45:119:118:112:108:108:103:100:96:95:93:88:84:82:79:78: 0.0:-104.7:-108.6:0.0:0.0:0.0:0.0: 41:119:119:113:108:108:103:101:97:96:93:86:85:83:81:75: 0.0:-102.3:-108.0:0.0:0.0:0.0:0.0: 47:118:119:112:109:109:103:100:96:94:94:88:84:85:81:77: 0.0:-105.5:-108.7:0.0:0.0:0.0:0.0: 41:118:119:113:112:108:103:101:96:96:95:86:84:83:82:78: 0.0:-103.4:-108.9:0.0:0.0:0.0:0.0: 4、 对站点的TBPE板出窗情况进行查询，出窗现象不明显。
小区3014、3016也同有3的现象。 但RecvBfnErr数目较多。
* dwRecvBfnErrNum = 62193 【排查方法】[庄荣海]
从KPI统计看，该站RRC建立成功率很低，失败原因为NOREPLY 从历史告警看，RRC建立失败期间，没有历史告警。
但是，通知查询中可以看到，存在大量的“锁相环源时钟瞬时抖动过大(4101)” 怀疑是这个原因导致TBPE上出现大量的BFN Err。
--未有结论，版本升级后继续观察。 【处理建议】
【典型案例】
4.10 NOREPLY原因：手机侧由于DPCH同步失败而重发RRC
ConnectionRequest时间间隔同协议不符
【故障现象】
系统设置的T300为2秒，T312为3秒。根据331协议，如果手机收到RRC Setup消息，但DPCH同步失败，则间隔T312时间后重发，RNC系统建立无线链路等待同步的时间也和T312相同为3秒。但是，通过对于大量CT的分析，以及针对几种不同芯片的终端测试发现，手机由于DPCH同步失败重发RRC ConnectionRequest的时间是T300+T312，按照目前的设置就是5秒。如下图：
此时由于RNC DPCH早已经删除，每次重发都分配新的GID，按照新发统计，因此在进行KPI统计的时候，对于连续多次的重发，每次都算作一次失败，导致了个别用户在短时间内贡献大量的RRC连接失败。 【排查方法】
抓信令确认。 【处理建议】
1、RNC侧同步定时器从3秒延长为5秒。 TIMER: tRrcConnSetup 3s ->5s;
2、T312修改为2秒，这样RRC重发的时间可以缩短为4秒，不会超过5秒。
3、N300由原来的3次修改为2次。因为RNC还有其他的定时器，限定了GID最长时间为15秒，因此，重传时间相加最长不能超过15秒，重发两次，则一共时间为12秒，可以满足要求。 【典型案例】
厦门RRC 接入成功率提升。