L.RRC.SetupFail.Rej.FlowCtrl 流控导致的发送RRC Connection Reject消息次数；
L.RRC.ConnReq.Msg.disc.FlowCtrl 流控导致的RRC Connection Request 消息丢弃次数（不发RRC拒绝，直接丢MSG3，但终端在竞争解决定时器超时后会重发MSG3）。 话统中关于CPU负荷的打点，预设门限为85%: 指标ID 指标名称 指标描述 单板CPU占用率高于预设门限的次数 1593835630 VS.BBUBoard.CPULoad.CumulativeHighloadCount1593835632 VS.BBUBoard.CPULoad.Max单板CPU占用率最大值 1593835633 VS.BBUBoard.CPULoad.Mean单板CPU占用率平均值 1593835634 VS.BBUBoard.CPULoad.Over单板CPU占用率超过门限的百分比 CHR中和MSG1、MSG3流控相关的打点如下表： 模块 L2 L2 L2 CELLM CELLM CELLM 事件 L2CellChr 字段 ulRachMsgFlwCtlCnt ulPreambleFlwCtlCnt ulCcchMsg3FlwCtlCnt CHR_CELL_RES_INFO ulDiscardRachReqCnt ulDiscardPreambleCnt 含义 Rach流控Msg1数统计 Rach流控preamble数统计 Rach流控Msg3数统计 流控丢弃的CCHP_L3_CRNTI_REQ总数 流控丢弃的前导总数 流控丢弃的 UEM_LCEM_CELL_RR_REQ 消息数 ulCellRrReqNumDiscard 如果CPU负荷增加，且暂时无法扩容，应急方案如下：
第11页, 共22页
措施 解释 拉长不活动定时器，让部分用户保持在线，减少CPU的消耗。 MOD 命令 拉长UE不活动定时 MOD RRCCONNSTATETIMER: UEINACTIVETIMER=30; CELLALGOSWITCH:LOCALCELLID=x,ACBARALGOSWITCH=ACBAR_SWITCH_STATIC; MOD AC Bar 随机阻止部分用户接入 CELLACBAR:LOCALCELLID=x,ACBARRINGINFOCFGIND=CFG,ACBARRINGFORMODATACFGIND=CFG,ACBARRINGFACTORFORCALL=P70,ACBARTIMEFORCALL=ACCESS_BARRING_TIME_S4,ACBARRINGFORMOSIGCFGIND=CFG,ACBARRINGFACTORFORSIG=P70,ACBARTIMEFORSIG=ACCESS_BARRING_TIME_S4; 如果是可调电下倾天线，调整电调天线倾角： 调整下倾角，或减小RS功率，减少重载小区覆盖（可选） 将部分用户迁移至负载较轻的邻区。 MOD RETTILT: RETCLASS=RET, OPMODE=SECTOR, SECTORNO=x, TILT=M; 降低参考信号功率： MOD PDSCHCFG:LOCALCELLID=x, REFERENCESIGNALPWR=N; 关闭FAST ANR 此类特性会触发大量的空口信令，会加重CPU负荷。 MOD ENODEBALGOSWITCH: ANRSWITCH=IntraRatFastAnrSwitch-0&UtranFastAnrSwitch-0&GeranFastAnrSwitch-0&CdmaFastAnrSwitch-0; 关闭UL COMP 此类特性会触发大量的空口信令，会加重CPU负荷。 MOD CELLALGOSWITCH: LOCALCELLID=x, ULCOMPSWITCH=DISABLE; MOD CELLALGOSWITCH: LOCALCELLID=x, DLSCHSWITCH=FreqSelSwitch-0; 关闭下行频选 此类特性会触发大量的空口信令，会加重CPU负荷。
第12页, 共22页
4）RRC NO REPLY问题分析
通常的RRC NO REPLY问题可以通过下述的思维图来排查：
首先通过eNodeB是否收到MSG4的ACK来隔离是MSG4问题还是MSG5问题
如果eNodeB没有收到MSG4的ACK，即很可能是MSG4接收问题，也可能是MSG4的反馈问题。如下图所示，通过L2_CHR_USER_SRB_INFO可以看出，这次RRC NO REPLY的MSG4为DTX，比如图：
MSG4支持HARQ机制，对初始接入和RRC重建过程而言，只有竞争解决成功的UE才会反馈MSG4的ACK，其它情况均不进行反馈，所以初始接入的MAG4理论上不存在NACK，只有ACK和DTX两种结果。但是DTX有实际对应两种情况，一种是终端接收MSG4失败，是真实的DTX；另一种是终端反馈了ACK，但是由于PUCCH等上行干扰导致被eNodeB误解成DTX。
协议36.321- if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or（初始接入、RRC重建使用T-CRNTI调度MSG4，而其它场景的随机接入用CRNTI调度MSG4） - if ……
- do not indicate the generated positive or negative acknowledgement to the physical layer. FMA可以统计MSG4中ACK的比例，如下图所示，FMA给出了MSG4为ACK/NAK（下图中MSG4有8次NACK可能是误检）和DTX的次数和比例。
第13页, 共22页
1、竞争解决定时器超时
FMA接入专家系统中，有竞争解决定时器超时的统计，如果此项统计较多，则可以判断是竞争解决定时器问题。
2、上行干扰导致MSG4的ACK漏检
上行干扰会导致终端MSG4在PUCCH或PUSCH（预调度场景可能）上的ACK反馈被漏检，导致错解成DTX。基带的上行用户CHR记录了终端反馈ACK时的上行NP值，可以利用这些信息来判断是否存在明显的干扰。如下图所示，在基带的LBBPdL1SegInfo记录中找到初始ACK信息，通过L2对MSG3和MSG4调度的记录，可以得到MSG4 ACK所在的TTI，找到这些TTI上基带检测到的上行干扰噪声NP和ACK/NACK结果。可以看到，这几次TTI的PUCCH的Np达到了-95，比底噪高出了30db左右，说明PUCCH上存在严重的干扰，导致终端的ACK反馈被检测成了DTX。
第14页, 共22页
另外，如果系统的上行干扰一直存在，那不会只干扰MSG4的ACK，其它下行调度的反馈也会被干扰，所以需要关联分析下行IBLER，PDCCH的DTX比例是否存在异常，另外也可以分析干扰话统或者反向频谱来分析上行干扰。
分析参数是否设置合理，和上行干扰效相关的参数主要有PassLossCoeff（路径损耗因子）和PUSCH标称P0值，这两个参数是控制UE发射功率的，这两个值设置越大，UE的发射功率越大，对其他小区的干扰也就越严重，需要参看参数是否设置合理
参数 PassLossCoeff P0NominalPusch 3、弱覆盖导致MSG4或者MSG5失败
下行弱覆盖也会导致终端解调MSG4失败，因为RRC建立时eNodeB没有终端CQI的反馈信息，所以无法知道下行实际信号质量。但一般认为上行和下行的路损相当，所以可以通过CHR中记录的MSG3的RSRP和SINR，来确定是否弱覆盖。如果上行的上行平均RSRP的最大值都在-130dBm或以下，则可以认为是上行弱覆盖；上行路损计算时，假设终端已经使用
第15页, 共22页
建议值 0.7 -67
36、广东省-江门RRC连接建立成功率优化报告推广案例(2024年双提升项目推广案例)
