rrc接入成功率低是由什么原因造成的
“UE无应答”导致RRC建立失败无线接通率低问题的分析优化
“UE无应答”导致RRC建立失败无线接通率低问题的分析优化“UE无应答”导致RRC建立失败无线接通率低问题的分析优化目录一、问题描述二、问题分析三、原因定位四、处理效果五、优化总结一、问题描述日常处理无线接通TOP小区优化，问题小区“大磡怡华F-HLH-3”的“无线接通率(%)”为97.00%左右，“RRC连接建立成功率（包括重发）（%）”为98.50%左右，“E-RAB建立成功率（%）”为99.60%以上，整体接通性能偏低。
二、问题分析结合网管和其它平台数据，分别从故障、覆盖、干扰、容量以及其它性能指标等多个维度对“大磡怡华F-HLH-3”小区进行无线层问题排查。
故障排查经过网管统计发现，指标劣化期间，问题小区无任何告警信息。
MR覆盖排查经平台查询：“大磡怡华F-HLH-3”小区覆盖良好，小区RSRP 在-110dbm以下采样点占比为99.50%以上，不存在MR弱覆盖问题。
干扰排查经平台查询：“大磡怡华F-HLH-3”小区性能指标劣化期间，上行干扰平均值在-110dBm左右，不存在上行干扰。
容量排查在PRS查询问题小区指标劣化期间，“大磡怡华F-HLH-3”小区下行PRB平均利用率（%）保持在6%左右，上行PRB平均利用率（%）保持在19%左右，小区内的最大用户数在70人左右，不存在高负荷问题。
其他KPI指标分析“大磡怡华F-HLH-3”小区无线接通低主要为RRC建立成功率低，E-RAB建立情况良好，进一步分析RRC建立失败原因，几乎都由于UE 无应答而导致RRC连接建立失败次数过多引起。
综上，问题小区低接通主要由于“UE无应答而导致RRC连接建立失败次数”较多，导致的“RRC建立成功率低”导致的，需要进行针对性优化。
三、原因定位综上，针对问题小区“大磡怡华F-HLH-3”的上行功控参数（“路径损耗因子”和“PUSCH标称PO值”）以及小区RACH配置参数（“前导初始接收目标功率值”和“Msg3的HARQ最大传输次数”）进行优化，减少UE无应答而导致RRC连接建立失败次数，提升RRC连接建立成功率从而提升无线接通率。
NB—IoT网络RRC连接成功率问题分析与处理
NB—IoT网络RRC连接成功率问题分析与处理作者：程闽明叶蔼笙陈潇来源：《移动通信》2018年第10期【摘要】随着NB-IoT技术的快速发展，NB-IoT网络RRC连接成功率问题的分析与处理成为无线优化面临的难题。
首先对日常影响NB-IoT网络RRC连接成功率的原因进行分析，然后提出定位原因的分析方法以及相应的处理方案，并以广州高沙村NB-IoT基站为例进行实践验证。
通过大量实践，研究出一套实际可行的RRC连接成功率问题分析与处理方案。
目前该方案已在广州得到全面应用，为NB-IoT业务项目售前评估提供了有力保障。
NB-IoT；RRC连接成功率；弱覆盖；同频/MOD 3干扰1 引言随着通信技术由2G、3G发展到如今的4G、5G阶段，人们的生活方式已悄然发生了巨变，生活中衣、食、住、行的方方面面都离不开移动通信技术。
从早期的短信和语音电话，到现在的图片、视频、高清语音通话，甚至是同步互联网游戏，人与人之间已实现高速、高效的信息传递。
近几年，NB-IoT由于其低功耗、广覆盖及海量连接的优势，得到了快速发展。
中国电信已在2017年开启NB-IoT商用阶段[1]，相关业务如智能抄表、智慧消防、停车等。
大量NB-IoT业务接入，亟需保障用户长期、稳定的网络服务质量。
在实际的NB-IoT网络维护工作中，为了提升客户感知，需对NB-IoT网络的接入、保持、完整性能等各项关键指标进行定期监管[2]。
NB-IoT无线网络的RRC连接成功率是检验NB-IoT网络接入性能的主要指标。
因此，在实际场景中，遇到RRC连接成功率较低的情况该如何进行有效分析与处理的方案亟需完善。
2 RRC原理简介NB-IoT是R13阶段LTE的一项重要增强技术，在蜂窝网络中构建，频段仅约180 kHz，上行采用SC-FDMA，下行采用OFDM。
NB-IoT的设计原则都是基于“妥协”的态度，将LTE 技术进行设计简化、信令简化，并降低功耗。
因此，NB-IoT网络的RRC连接协议原理与LTE 相似。
改善RRC连接建立成功率案例
改善RRC连接建立成功率案例1 问题描述 RRC连接建立成功率是反映小区的UE接纳能力，RRC连接建立失败的原因主要有：在初始接入时或者信令交互时发生的eNB接纳失败、定时器超时、ENB RRC连接个数不足或者其他原因导致的。
这些问题通常同邻区错配或者漏配、信号快衰落、导频污染、弱覆盖、强干扰、室内室外转换，资源不足或者用户拔卡等联系在一起。
查询5月第1周RRC连接TOPN差小区(室分)指标如下：1 问题分析定时器超时主要是指系统没有收到终端发送的RRCConnectionSetupComplete消息导致的失败。
RRC统计相关的信令流程如下：在步骤1，系统收到一次RRCConnectionRequest消息，计为一次RRC连接建立请求。
在步骤3，系统收到RRCConnectionSetupComplete消息时，计为一次RRC连接建立成功；如果收不到此消息，则按失败原因，统计为一次相应的RRC连接建立失败。
系统收不到RRCConnectionSetupComplete，可能来源于两方面：系统下发了RRCConnectionSetup消息，但终端没有收到；终端发送了RRCConnectionSetupComplete消息，但终端没有收到。
优化等待RRC建立完成的定时器(ms)，优化此定时器对于提升弱覆盖用户接入有一定的好处。
负面影响是可能会影响用户接入时长；2 优化措施【等待RRC建立完成的定时器（rrcSetupTimer）】：由2秒优化为15秒。
RRC连接建立时，eNB给UE发送RRC连接建立消息后，启动该定时器，收到UE的RRC 连接建立完成消息，停止该定时器；定时器超时，进行异常处理。
优化此定时器对于提升覆盖不稳定区域的用户接入有一定的好处。
3【效果验证】: 取5月最后1周指标可以看出大部分小区指标都有所提升，效果还是挺好的。
5、小结 1、RRC建立成功率比较低小区，进行KPI分项指标分析后，可以看出某些小区定时器超时引起的连接失败较多，于是对等待RRC建立完成的定时器参数进行了一些调整，观察后表明对于提升弱覆盖用户接入有一定的好处，也达到了改善TOP小区RRC连接成功率的目的。
站点RRC建立成功率低分析
站点RRC建立成功率低案例分析1.1.1一．现象描述2011年8月21日，统计指标发现H站点两个小区CS和PS RRC建立成功率均在80%左右，客户反映在现场有一部分通话无法进行。
西区测试人员到现场后，占用这两个小区进行拨打测试，后台跟踪TRACE信令均正常，每个小区20次通话均成功，但是在跟踪小区IUB口信令的时候，发现部分用户出现RRC CONNECTION REJECT（原因值为：未定义）现象。
1.1.2二．问题分析可能造成RRC连接拒绝的常见原因有：●小区码道资源不足，没有足够的码道为UE分配（特殊地：UE只支持单载频，而主载频上已没有剩余的码道资源）；●干扰或功率受限，软资源接纳失败；●传输资源申请或带宽接纳失败；排查方法：●查看小区剩余的码道资源数看是否有足够的剩余资源；●查看公共测量值和配置的接纳门限，是否为功率干扰等软资源受限；●查看Iub口带宽大小是否受限；1.1.3三．处理过程：●查询两个小区RRC建立失败原因统计，没有出现拥塞导致RRC建立失败的情况，载波配置均为每小区3个R4,3个H，排除拥塞导致RRC建立被拒绝的情况。
●提取454和50454两个小区8月21日0时到下午6时的UPPCH ISCP和上行时隙ISCP情况，如下图：从上图可以看出，454和50454两个小区没有明显的干扰现象，排除干扰受限的情况。
●核查该小区功率配置情况，没有发现功率配置不合理，排除功率受限的情况。
●该站点为ATM站点，传输为6条，在RNC侧执行MML命令LST AAL2PATH查询到AAL2PATH的类型配置正确（如下图）根据上图所示AAL2PATH流量索引，查询对应的信元速率。
在RNC侧执行MML命令LST ATMTRF查询流量索引150~157对应的信元速率如下图：上图所示的峰值速率和平均速率都属于信元速率。
在对应站点的NODEB侧执行LST AAL2PATH命令查询到的信元速率和RNC侧一致（如下图）：由此，可判断AAL2PATH配置正确。
中兴无线KPI指标分析解决思路
目录一、无线接通率 (5)RRC建立成功率低（常见原因及处理思路） (5)1.RRC连接失败，定时器超时 (6)2.RRC连接失败，ENB接纳失败 (6)3.RRC连接失败，其他原因 (6)ERAB建立成功率低（常见原因及处理思路） (7)1.ERAB建立失败，空口失败 (7)2.ERAB建立失败，RRC重建立原因 (8)3.ERAB建立失败，安全激活失败 (8)4.ERAB建立失败，ENB接纳失败 (8)5.ERAB建立失败，切换引起 (8)6.ERAB建立失败，其他原因 (8)二、切换成功率 (8)切换准备成功率低（常见原因及处理思路） (9)ZTE网管计数器异常原因值和处理方法： (9)1.切换出准备失败，等待切换响应定时器超时 (9)2. 切换出准备失败，目标侧准备失败 (9)3.切换出准备失败，源侧发生重建立 (10)4.切换出准备失败，其他原因 (10)切换执行成功率低（常见原因及处理思路） (10)ZTE网管计数器异常原因值和处理方法： (11)1.切换出执行失败，源侧发生重建立 (11)2.切换出执行失败，目标侧发生重建立 (11)3. 切换出执行失败，RRC重配完成超时 (12)4. 切换出执行失败，其他原因 (12)5. 切换出执行失败，等待UE context Release消息超时 (12)三、掉线率 (12)无线掉线率高（常见原因及处理思路） (12)ZTE网管计数器异常原因值和处理方法： (13)1.Context释放，ENB空口失败引发释放 (13)2.Context释放，ENB切换失败引发释放 (13)3. Context释放，由于小区关断或复位引发释放 (14)4.Context释放，ENB由于其他原因引发释放 (14)5. Context释放，ENB重建立失败导致释放 (14)6.Context释放，ENB由于S1链路故障失败导致释放 (14)7.Context释放，空口定时器超时 (14)8.Context释放，空口质量差触发RLF (15)9.Context释放，RLC达到最大重传次数 (15)10. Context释放，PDCP完整性保护失败 (15)11. Context释放，Gtpu ErrInd触发释放 (15)12. Context释放，Path故障触发释放 (16)13.Context释放，光口故障触发释放 (16)ERAB掉线率高(常见原因及处理思路） (16)ZTE网管计数器异常原因值和处理方法： (16)1.E-RAB切换出失败次数 (16)2.E-RAB释放，由于ENB过载控制导致的释放 (17)3.E-RAB释放，由于ENB其他异常原因 (17)4.E-RAB释放，由于ENB小区拥塞导致的释放 (17)5. E-RAB释放，由于UE切换失败 (17)6.E-RAB释放，由于ENB的无线链路失败 (18)7. E-RAB释放，由于ENB重建立失败 (18)8.E-RAB释放，由于小区关断或复位 (18)9. E-RAB释放，ENB由于S1链路故障发起释放 (18)10. ERAB释放，空口定时器超时 (19)11. ERAB释放，空口质量差触发RLF (19)12. ERAB释放，RLC达到最大重传次数 (19)13. ERAB释放，PDCP完整性保护失败 (19)14. Context释放，Gtpu ErrInd触发释放 (19)15.Context释放，Path故障触发释放 (20)16. Context释放，光口故障触发释放 (20)一、无线接通率RRC建立成功率低（常见原因及处理思路）1.基站故障；2.PRACH参数配置、最小接入电平设置；3.上行干扰NI过高；4.弱场接入，RRC无法接入；5.用户过多导致，SR资源不足；6.上行功控参数设置不合理；7.CPU负荷过高；ZTE网管计数器异常原因值和处理方法：1.RRC连接失败，定时器超时1.检查CPU负荷是否偏高，用户数是否很多，如是则调整SR容量进行调整；2.检查上下行功控类参数；3.检查NI是否过高；4.检查RRU输出功率；5.检查是否MR任务或其他实时跟踪任务导致接入定时器超时；6.检查是否弱场导致接入定时器超时。
多维RRC连接重建成功率优化整治案例
多维RRC连接重建成功率优化整治案例多维CRRC连接重建成功率优化整治案例【摘要】在LTE网络中，重建是终端恢复RRC连接的一种行为，降低掉线率；但是重建成功率低与重建比例高会影响小区的性能和用户感知度。
本案例通过实际的优化整治手段，从多个维度分析RRC重建成功率低原因，通过告警处理、邻区核查、干扰核查、覆盖问题、参数优化调整等多个维度的方法，提升RRC连接重建成功率和压降RRC连接重建比例，提升用户感知。
1.问题描述1.1RRCRC连接重建成功率偏低通过综合网管提取重建指标数据，对全网的RRC连接重建指标进行分析发现，当前东莞的整体RRC连接重建指标明显偏低，其中华为厂家区域的RRC连接重建成功率71.3%，爱立信厂家区域为80.2%，整体的RRC连接重建成功率在77.1%左右徘徊；通过提取相关小区级的数据发现，大量的小区RRC连接重建成功率低于50%，达到3164个，占全网总小区数的10%左右，需开展针对性的优化整治。
1.2RRCRC重建原因分类通过统计RRC连接重建成功率低于50%的小区重建原因进行分析，TOP小区的RRC重建原因可分为6大类，各类的比例如下图：上图看出，当前TOP小区引起RRC连接重建的最大三个原因分别为激活的RRC重建请求次数（78.84%）、切换失败触发RRC重建请求的次数（14.71%）和切换失败触发无上下文RRC重建尝试次数（6.00%）。
2.分析过程2.1RRC重建概述RRC重建（RRCconnectionre-etablihment）是UE处于RRC_CONNECTED状态，因为一些移动性管理或底层链路故障，导致连接中断，UE发起的空口资源重新建立的过程，以继续空口的RRC连接。
重建是UE在连接状态下，空口异常时重新恢复空口的过程。
重建成功的前提是收到重建请求的小区有UE的上下文。
重建的意义在于快速恢复空口业务，提高业务的连续性。
CRRC重建成功流程：CRRC重建完成消息：如果目标小区无该UE的上下文信息，此时UE的RRC重建请求可能会被拒绝，从而引发失败。
108、广东省-快速定位光缆中断导致RRC连接成功率低问题
广东省-快速定位光缆中断导致LTE RRC连接成功率低问题2019年9月目录一、问题现象描述 (2)二、RRC连接建立影响因素 (3)三、问题分析定位 (3)四、问题优化整治 (5)五、问题闭环评估 (5)六、案例总结 (6)摘要RRC连接建立过程是LTE用户连接到网络的第一步，连接建立的成功或失败直接影响用户的感知。
因基站设备故障、举办大型活动等，导致用户数大量增多时，每个用户的感知速率将逐渐下降。
当用户总数超过系统设计容量时，可能导致部分用户无法接入，大量用户同时接入网络可能出现RRC连接建立失败次数增多，导致RRC连接建立成功率降低。
本案例将以一个突发TOP问题点为例，分析定位RRC连接建立成功率低的原因，总结TOP问题点的分析、优化和闭环评估方法。
关键词：RRC连接建立，TOP问题，分析定位一、问题现象描述RRC连接失败TOP：HW_484750_F花东河联LTE-BBU01_3扇区(室外)，RRC连接建立成功率67%，RRC连接建立失败次数67406次。
地理地点：广州市花都区花东镇河联村空地（113.34876，23.45072）附近基站信息：二、RRC连接建立影响因素一般而言，网络RRC连接建立成功率主要受以下5大因素影响，在分析RRC类异常问题中，需着重注意对这5个因素进行核查。
1.空口信号质量2.参数配置（定时器、功率控制等）3.干扰影响4.网络拥塞、资源不足5.设备故障等三、无线侧及现场排查定位1.无线侧KPI关联分析1）关键指标分析发现，“F花东河联LTE-RRU01/GZV0657”小区全天的RRC连接建立成功率为67%，RRC连接建立失败次数67406次。
缩小时间粒度，分析发现RRC连接成功率指标突发异常在12月13号8点至15点之间；2）细致分析发现，因UE无应答而导致RRC连接建立失败次数累计67301次。
排除用户自己造成的原因（如：拔插终端，终端异常吊死），除此之外，这个子原因一般都是空口侧干扰或覆盖问题，表明当前接入用户无线环境出现明显恶化。
基站越区覆盖导致RRC连接成功率低
越区覆盖导致RRC连接成功率过低1 问题描述XC-泾县-如海超市属于近期新开站点（7月13日开通），分析最近的TOP 小区发现，XC-泾县-如海超市-ZFTA-446176-51小区的RRC连接失败次数一直处于TOP小区前列，详细查看此小区的性能指标发现，该小区每天的失败次数大概接近1000次，每小时失败次数大概在30~50次之间，且分布相对均匀，详细情况如下表指标查询结果：表1-1 站点开通之后的指标查询（按天查询）表1-2 XC-泾县-如海超市-ZFTA-446176-51小区一天指标查询2 问题分析2.1RRC连接失败类型根据现网处理该问题的案例和现网实施的经验，导致RRC连接失败的因素一般有以下几类：1.基站设备异常问题；2.干扰问题；3. 参数配置问题；4.拥塞问题；5.无线环境问题；2.2详细分析过程1.故障告警分析通过网管查询并未发现有基站设备告警情况、也没有发现驻波，由此可以排除基站硬件故障导致RRC连接性能指标差的原因。
2.干扰问题分析检查底噪发现RSSI值处于正常范围，也没有MOD3干扰等问题出现，由此可以排除上行干扰及MOD3干扰。
3.配置参数核查对该站点网管各项参数进行对比核查，未发现异常参数设置。
4.拥塞分析对于网络拥塞而导致RRC 连接失败，需要检查接纳参数设置是否合理，小区用户数是否达到饱和状态，同时拥塞导致的RRC接纳失败一般表现为“ENB 接纳失败”，通过话统指标查询发现并没有出现“ENB接纳失败”，同时用户数也没有出现饱和，参数设置也正常，由此可以排除拥塞导致。
5.无线环境分析从提取的KPI指标可以发现大部分失败都表现为“RRC连接建立失败次数(UE 无应答)”失败，以及其他原因失败，一般这种情况都是由于弱覆盖或者有大量用户处于覆盖边缘导致，下面对该站点所处的无线环境进行分析：图2-1XC-泾县-如海超市周边无线环境通过查看站点周边无线环境发现在距离XC-泾县-如海超市-ZFTA-446176-51小区覆盖方向340M处就有一基站（XC-泾县-稼祥中学BBU）进行覆盖，而我们通过用户上报的TA（一个TA大约为78M）值进行查询发现用户数在350M以内上报的次数并不多，而是大量的用户都集中的700~1000M这个距离，而这个距离刚好是XC-泾县-稼祥中学BBU_2小区的覆盖范围，也就是说出现了严重的越区覆盖。
开环功控参数设置不合理导致RRC建立成功率过低的案例分析
故障案例开环功控参数设置不合理导致RRC建立成功率过低的案例分析省公司辽宁省专业TD无线设备类型RNS设备厂家华为设备型号DRNC82软件版本V004R000C01SPC100编制时间2010-06 作者王天琦作者电话入库时间审核人审核人电话厂商审核人联系方式关键字开环功控、RRC建立成功率故障现象在室分下，UE发起RRC CONNECTION REAUEST，在接收RRC CONNECTION SETUP后，没有发送RRC CONNECTION SETUP COMPLETE。
计时器超时后，重新发起RRC CONNECTION REAUEST，如此重复长达数十次后，最终才发送RRC CONNECTION SETUP COMPLETE，并成功建立RAB连接，开始业务。
同时，在这种情况下，主叫挂断后，不断出现UE读取Masterinfoblock，大约20秒左右，才能完成下行同步。
注：以上情况出现概率约80%，即20%的概率UE可以一次接入成功。
告警信息无原因分析1、从现象上看，判断可能是干扰引起。
①、由于干扰的存在，造成SIR较高，导致UE无法正确解析NodeB下发的Special Burst而始终没有上报RRC CONNECTION SETUP COMPLETE。
②、由于干扰的存在，导致主叫挂断后，UE无法正常解析MIB信息块信息，不能及时完成下行同步。
2、设备硬件问题造成。
3、参数设置不合理。
处理步骤1、排查邻区干扰。
①、该室内小区使用的是低5M的频点，因此，关闭周边室外低5M频点的小区，并使用扫频仪测试，确定室内没有受到邻小区的同频干扰。
但是，干扰现象仍然存在。
2、室外干扰因素排除后，将重点放到了室内系统的自干扰和硬件隐性故障排查。
①、首先，对NodeB和RRU进行重启，但是，没有任何改观。
②、该室内系统采用了多级RRU级联的设计，没有任何干放设备。
因此，怀疑可能是RRU级联引入了干扰，造成下行同步问题。
4G优化案例：多维度提升RRC重建成功率
多维度提升 RRC 重建成功率【摘要】通过对TOP 小区进行优化，对RRC 重建失败率高小区进行分析，从而定位出导致RRC 重建失败率高的原因，进行逐个排查处理，提升指标。
【关键字】RRC 重建、掉话率、X2 链接【业务类别】移动网、基础维护1.问题描述前期通过 TOP 小区取数分析，对RRC 重建失败率高小区进行分析，通过网管取数分析，发现为邻区漏配、X2 连接等参数配置问题，进行优化后指标得到显著提升。
2.分析过程2.1问题定位流程RRC 连接建立成功率用 RRC 连接建立成功次数和 RRC 连接建立请求次数的比来表示. 该指标反映或者小区的 UE 接纳能力，RRC 连接建立成功意味着 UE 与网络建立了信令连接。
RRC 连接建立，包括（如位置更新、系统间小区重选、注册等）的RRC 连接建立。
RRC 重建定义：1. RrcConnectionReestablishmentRequest2. RLF Indication （携带跨eNB 重建立标识）3. Handover Request4. RrcConnectionReestablishmentdge12. UE Context Releaseequest Acknowledge11. Path Switch Romplete10. Path Switch Request8. SN Status Transfer9. RrcConnectionReconfigurationC6. RrcConnectionReconfiguration5. RrcConnectionReestablishment 7. Handover Request Acknowle Complete匹配到UE 实例并确定与eNB_1同MME没有UE 上下文，根据重建立请求消息中PCI 确定源eNB ，并确定建立有X2口MMEeNB_2eNB_1UERRC 连接重建请求次数： 在统计时段内， 当 eNodeB 收到 UE 发起的RRCConnectionReestablishment Request 消息时计数器加 1。
小区高负荷造成无线接通率低处理案例
告警信息NONONONONONOYES结束RRC建立成功率低1、高负荷小区定义：RRC最大用户数≥200；2、RRC平均用户数≥30且上行PRB利用率大于50%且上行流量大于1G；3、RRC平均用户数≥30且下行PRB 利用率大于50%且下行流量大于5G；4、主控板CPU最大利用率>80%是否存在资源不足1、参数调整，流量均衡；2、天馈调整，分担流量；3、热点区域，增补基站；是否终端、用户行为异常1.结合用户投诉情况，安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；指标是否正常保存跟踪信令及测试数据，提交问题排查交付件至华为研发定位问题。
检查操作，是否存在告警，传输问题，是否存在网络变动和升级行为等；2.查询单板运行情况；3.传输及EPC侧有网络变动（升级，割接，参数修改等）。
1、通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；2、检查小区时隙配比是否设置准确（DE:SA2\SSP7;F:SA2\SSP5）3、如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；最后干扰处理。
是否存在干扰 1.通过统计TA与RSRP接入确认用户的接入环境，是否为弱场发起RRC请求；3、邻区告警、故障等导致TOP小区存在弱覆盖；4、天馈问题；5、无线环境差；6、基站规划、建设、施工问题；7，天线权值配置与现场天线参数不一致。
8.核查参考信号功率是否偏低（常规设置92,122，需结合现场设置）；是否存在覆盖问题是否存在高质差1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；2、通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；基站地理分布:通过查询发现RRC建立失败原因主要为“mo-Data类型RRC连接失败次数，定时器超时小时600多次，如图所示：RRC连接建立成功率mt-Access类型RRC连接失败次数，定时mo-Signalling类型RRC连接失败次数，定时mo-Data类型RRC连接失败次数，定RRC连接释放次数，空口定时器RRC释放次数，立失败2015/6/7 12:00 94.93% 114 95 594 24 442、A1、A2门限由-92、-95改为-79、-823、如下图所示，随后提取指标发现RRC用户由250下降至170左右，无线接通率指标也恢复正常：物理视图，在BBU10槽位新增一了块BPN2板，下挂了3台(M1920A)RRU5、扩容前后LTE市区城坤钢材市场东_1小区指标与用户数对比：市区空后院搬迁F_2扩容后用户数。
RRU隐性故障导致无线接通率较低
RRU隐性故障导致无线接通率较低一、投诉内容：受理投诉：近日，接到民权电业局人员反映，在民权电业局内使用3G信号经常出现未接通现象。
严重影响了客户的感知度。
客户要求尽快进行处理。
二、投诉分析：1、处理流程图：2、分析投诉问题判断可能原因：从后台网管指标统计来看，17585小区一直存在无线接通率较低的问题，对17585小区的接通率较差原因进行分析，发现RRC失败原因几乎全部为NO REPLAY，原因值为RRCsetup time out，即为RRC连接超时，且从RRC 起呼场强来看，周围并不存在弱场现象。
表一：17585小区接通率指标表二：RRC连接失败原因排除弱场后，导致RRC连接超时的可能原因一、干扰（系统内和系统外）二、用户终端原因三、无线环境原因三、传输侧问题四、基站硬件故障可能原因1：干扰查询该站点的上行干扰情况，该站点上行时隙干扰值在-109dbm左右，上行并不存在干扰问题。
查看17585小区的底噪情况，底噪正常。
●可能原因2：用户终端原因可能为用户终端原因所导致，通过询问用户得知办公室其他用户在该区域也存在占用TD信号打电话未接通的现象。
并且在现场进行测试，测试终端大唐8142也经常性的出现未接通现象。
用户在其它区域使用正常。
用户终端问题排除。
●可能原因3：无线环境较差现场用鼎利+大唐8142进行测试。
一直稳定占用17585小区信号，场强在-65dbm左右，PCCPCH C/I在10左右，无线环境良好，无其它外部干扰存在，无线环境较差因素排除。
●可能原因4：传输侧故障出现未接通的现象，在传输侧表现为传输误码，传输链路告警等现象。
通过传输人员查询，17585小区传输侧完全正常，不存在问题，该原因排除。
●可能原因5：硬件故障查询该小区站点告警情况，无任何告警，由于其他原因均已经排除，怀疑故障原因可能为UBPM板、CC板、RRU的隐性故障或者是光纤、光模块的问题。
对故障进行逐一排查。
将该小区（17585）的光口和17584小区的光口互换，现场进行测试，17585小区无未接通现象，17584小区出现未接通。
小区高负荷造成无线接通率低处理案例
故障案例小区高负荷造成无线接通率低处理案例省公司江苏省专业无线设备类型设备厂家中兴设备型号B8300 软件版本关键字无线接通率低小区高负荷故障描述在LTE小区日常监控中发现LTE市区城坤钢材市场东_1的RRC建立成功率突然降低，从下图可以看出，该小区RRC建立成功率从11：00开始恶化由原来的99.72%下降至94.17%，每小时RRC建立失败800多次，指标恶化严重影响用户感知。
截图如下：时间无线接通率_集团_zteRRC连接成功率_集团_zteERAB建立成功率_集团_zte切换成功率_集团_zteZJ平均底噪2015/6/7 10:00 99.68% 99.72% 99.97% 99.17% -1162015/6/7 11:00 95.00% 95.09% 99.91% 99.40% -1162015/6/7 12:00 94.06% 94.17% 99.88% 98.77% -1162015/6/7 13:00 94.89% 94.93% 99.97% 99.39% -116告警信息无原因分析1、RRC 失败原因分析：影响RRC 接入成功率的主要因素如下：小区故障、参数设置不合理，如PRACH 参数配置，最小接入电平、小区存在干扰，上行干扰（杂散干扰、谐波干扰、宽频干扰、大气波导）、下行MOD3干扰、弱场接入RRC 无法完成、用户数多SR 容量不足、CPU 负荷高等。
RRC 建立失败分析流程：NONONONONONOYES结束RRC建立成功率低1、高负荷小区定义：RRC最大用户数≥200；2、RRC平均用户数≥30且上行PRB利用率大于50%且上行流量大于1G；3、RRC平均用户数≥30且下行PRB 利用率大于50%且下行流量大于5G；4、主控板CPU最大利用率>80%是否存在资源不足1、参数调整，流量均衡；2、天馈调整，分担流量；3、热点区域，增补基站；是否终端、用户行为异常1.结合用户投诉情况，安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；指标是否正常保存跟踪信令及测试数据，提交问题排查交付件至华为研发定位问题。
由于SRS配置不正确导致RRC成功率低
由于SRS配置不正确导致RRC成功率低【Product Information】LTE【Product Version】BTS3900 SRAN12.1SPC220【Problem Description】I国A运营商，由于业务的覆盖需求，开通了L900小带宽1.4MHz后，网络级的RRC 建立成功率只有95%左右，低于验收标准99.5%，客户要求提升该指标到验收标准。
【Handling Process】从网络级的KPI统计报告来看，RRC SR的指标维持在96%左右，网络存在一定的异常，导致用户接入不成功。
通过对TOP基站的RA(随机接入)过程分析，发现RRC建立成功率低是由于用户数较多，并且1.4M带宽仅有6个可用PRB，导致调度时延增加影响RRC建立成功率。
通过修改如下参数后减少用于TA测量的SRS分配时延，提升RRC建立成功率。
MOD SRSCFG: LOCALCELLID=10, SrsCfgInd=BOOLEAN_TRUE, FDDSRSCFGMODE =DEFAULTMODE (Current: ADAPTIVEMODE);参数修改后，RRC SR达到验收水平：参数FDDSRSCFGMODE是的MO SRSCFG的一个参数，当SrsCfgInd配置为TRUE时，需要配置此参数。
此参数有两个选项：DEFAULTMODE(默认分配方式)和ADAPTIVEMODE(自适应分配方式)，在8.1版本前默认为DEFAULTMODE，但是在8.1版本后默认为ADAPTIVEMODE。
当配置为DEFAULTMODE表示小区建立后默认就启动SRS配置并为接入用户分配SRS资源；当配置为ADAPTIVEMODE(自适应分配方式)时，表示使用自适应SRS功能，即小区可以根据负载状态自适应地配置和去配置SRS，建议在大话务量、小区用户数较多场景下打开，该取值针对LBBPc基带板不生效。
实际上，设置为此模式后，新接入的用户用DMRS测TA，基站会监控每秒的同步态用户，当在监控到在XX分钟内同步态用户个数一直大于X，则对新接入的用户分SRS资源。
上行干扰导致RRC建立成功率低问题
上行干扰导致RRC建立成功率低问题分析1【背景】V国D运营商于2013年初开始建设全国首张LTE商用网络，新建过程中开始商用，涉及和Z，E等友商竞争。
客户反映按最终接入成功率来看，我司有一个区域站点接入成功率很低，且全国最差14个站点我司有11个。
2【基本信息】网络制式：20MHz FDD LTE 网络。
站点数目：目前有135个开通站点分布在4个城市。
组网情况：无线站点为我司设备，部分传输为我司设备，核心网为E///设备。
用户量：基本无用户，平均每小区用户数在3到5个。
3【告警信息】部分站点有IP时钟链路异常和时钟参考源丢失告警，但是不影响RRC建立。
4【原因分析】1、通过分析话统指标，应用FMA工具，确认为TOP站点问题：下表是TOP站点RRC建立成功率指标：2、确认为TOP站点问题后，针对TOP站点进行X板斧规定动作核查告警和重要外部事件：3、核心参数核查，未发现异常配置。
4、网规网优排查：FMA上行干扰的判断条件：(MSG3 RSRP大于-130，但MSG3 SINR<=0) ；或者(MSG3 SINR<=5 并且MSG3 RSRP – (-130) -6 >= MSG3 SINR) 或者在CHR_L2_DRB中，如果MIN{ UL Average Rsrp }>-130dBm，且MAX{ lUlDmrsSinrAvg}<=0dB）(如果“UL Average Rsrp”>=0，则认为该行数据无效)；发现有上行干扰：5、不涉及传输等问题。
至此基本已经明了是上行干扰问题导致RRC接入成功率较低。
5【处理过程】1、对TOP站点进行RSSI跟踪和UL INTERFERENCE跟踪，结果如下：CALLE72ZUL5站点前30个RB干扰较为严重，从31RB开始干扰基本消除。
另外一个TOP站点SANRAMON5也有相同的干扰趋势，但是程度较轻。
2、进一步确认是内部干扰还是外部干扰。
小区高负荷造成无线接通率低处理案例要点
告警信息NONONONONONOYES结束RRC建立成功率低1、高负荷小区定义：RRC最大用户数≥200；2、RRC平均用户数≥30且上行PRB利用率大于50%且上行流量大于1G；3、RRC平均用户数≥30且下行PRB 利用率大于50%且下行流量大于5G；4、主控板CPU最大利用率>80%是否存在资源不足1、参数调整，流量均衡；2、天馈调整，分担流量；3、热点区域，增补基站；是否终端、用户行为异常1.结合用户投诉情况，安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；指标是否正常保存跟踪信令及测试数据，提交问题排查交付件至华为研发定位问题。
检查操作，是否存在告警，传输问题，是否存在网络变动和升级行为等；2.查询单板运行情况；3.传输及EPC侧有网络变动（升级，割接，参数修改等）。
1、通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；2、检查小区时隙配比是否设置准确（DE:SA2\SSP7;F:SA2\SSP5）3、如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；最后干扰处理。
是否存在干扰 1.通过统计TA与RSRP接入确认用户的接入环境，是否为弱场发起RRC请求；3、邻区告警、故障等导致TOP小区存在弱覆盖；4、天馈问题；5、无线环境差；6、基站规划、建设、施工问题；7，天线权值配置与现场天线参数不一致。
8.核查参考信号功率是否偏低（常规设置92,122，需结合现场设置）；是否存在覆盖问题是否存在高质差1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；2、通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；基站地理分布:通过查询发现RRC建立失败原因主要为“mo-Data类型RRC连接失败次数，定时器超时小时600多次，如图所示：RRC连接建立成功率mt-Access类型RRC连接失败次数，定时mo-Signalling类型RRC连接失败次数，定时mo-Data类型RRC连接失败次数，定RRC连接释放次数，空口定时器RRC释放次数，立失败2015/6/7 12:00 94.93% 114 95 594 24 442、A1、A2门限由-92、-95改为-79、-823、如下图所示，随后提取指标发现RRC用户由250下降至170左右，无线接通率指标也恢复正常：物理视图，在BBU10槽位新增一了块BPN2板，下挂了3台(M1920A)RRU5、扩容前后LTE市区城坤钢材市场东_1小区指标与用户数对比：市区空后院搬迁F_2扩容后用户数。
RRC重建成功率低
RRC重建成功率低NA05936049 / (LBTS7.0 Flexi) RRC reconstruction success rate is low 主要现象:基站向UE发RRC Release和基站删除UE上下文几乎在一个时间点,基站内UE上下文和RRC 状态（idle态）不同步，UE重建请求时,基站无UE上下文而失败,该现象在全网RRC重建拒绝中占主要原因。
1、下表是江苏电信各地市各厂家RRC建立成功2016年第28周数据从下表中可以看出诺基亚比华为、中兴低很多，比华为常州要低21.7%。
2、诺基亚区域在中国电信RRC重建整体情况以及诺基亚在全球部分项目情况51.04%。
重建成功率两个台湾项目和另外两个未知Nokia项目做了解，最好的在60%，最差的在45%，均较差，和江苏类似。
Taiwan mobile: Around 46%Taiwan Star: Around 58%Other project: Around 45%3、RRC重建失败主要原因----EMIL LOG分析现象表现为RRC Release和基站删除上下文几乎在一个时间点,基站内UE上下文和RRC状态（idle态）不同步，UE重建请求时,基站无UE上下文而失败,该现象在全网RRC重建拒绝中占主要原因。
1）、RRC重建Reject失败下图为EMIL LOG截图：PCI 177为IP 7.98.98.72站点1小区，重建小区为该站的2小区，重建前对应的C-RNTI为44304。
2）、找到RRC重建前C-RNTI为44304 LOG，UE inactivity Time时间内SRB2和DRB上下行检测无数据就会触发S1AP :Context Release Request, 从图中可以看出基站删除UE上下文和向UF发RRCConnectionRelease时间点基本重合；如果UE接受到RRCConnectionRelease，UE就回到idle态，后面就不会发测量报告或其他消息到eNodeB,但是从抓到的LOG看，UE没有回到idle态，依然在后面时间段发测量报告。
RRC常见问题处理思路
RRC连接拥塞与无响应处理思路1. 背景随着TD-SCDMA网络二期工程接近尾场声，全国的网络建设却紧随其后开展起来，在网络建设的初期阶段，由于基站建设问题、基站故障问题等造成优化的困难，本文就在长沙处理RRC相关的部分问题，结合现场实际情况，为现场的网优人员提供此类问题的一种解决思路。
2. RRC 连接过程的信令流程UE处于空闲模式下，当UE的非接入层请求建立信令连接时，UE将发起RRC连接建立过程。
每个UE最多只有一个RRC连接。
当RNC接收到UE的RRCCONNECTIONEQUES消息，由其无线资源管理模块RRM艮据特定的算法（CAC算法）确定是接受还是拒绝该RRC连接建立请求，如果接受，则再判决是建立在专用信道还是公共信道。
对于RRC 连接建立使用不同的信道，则RRC连接建立流程也不一样。
这样一来，对于RRC连接的信令过程可以大致分为以下几个过程：1）呼叫接入控制过程（主要由UE发起请求，RNC来控制）2）无线链路的建立过程3）RRC建立完成过程RRC连接过程的基本信令流程如下图：相对应在，在信令跟踪工具内看到的过程如下图 (此为手动信令跟踪得来， 没有打开内部消息跟踪)：UE Node B RNCuest(RACH )RRC Conn ection ReqRRCRRCRadio Link Setup RequestNBAP NBAPStart RXRadio Link Setup Resp oneNBAP NBAPACAP Iu Data Tra nsport Bearer SetupDL SyncDCH-FPDCH-FPUL SyncDCH-FPDCH-FPStart TXRRC Conn ection Setup (FACH )RRCRRCRRC Conn ection SetupRRCAllocate RNTISeclect L1 and L2 Parameter随机接入过程(UpPCH SYNC )Complete (DCCH )RRCIn OC uplinkOiTeetTraiLsfer]u*t RJJC EirectTranEfer In Kjn? H U K E I E 鼻E 丈和口如心 Jut KBC luRne^stemplate皈连接过程可以分対以下几个步璃：」、rrcCcnnecti wifieQuest 七 Ead.i cLi nkSatnpR»qu«Et P 、Radi uLi nkS@ tupK@on s Q■"4、 rroCcnn$c t.i anSetup -5、 Rail cLi nl 浪色mtor$Indi catioh *6、 rrcConiiKti^nS^t-upCompletAIn OCJu 七 KNC neas'V'^ni entX oxitrol J 41 KJilC mu 色旨临 umwEACQiitr Q 1In KNU ini tiaLDir&ctlransfer Jnt FLHC Im ti alUZMM In RHE tifeiztrraxisferJut KK 4ai-nlinkDire ctlr wsfer [n BSC mplinkDir^crtrruLEfaTIn EtHCrrcC onne ctionEequ 电言 tSigTjrpe=3:RULC_IIE_NAME :Int^rface=12B. Uikno ttnSigType=3:EHLC_UE JfAMl;Int^rface=12S: UaEo 灿RHK -. SUciiUns tS&tupSigT5Tt=3:RHI£_UE_NAME :Tid irft^=128:社朋沁EMIT <.. SUci ulnE tSatujRfesjSigTypa=3 :R1ILC_UE_NAME ：Iri.t^i-f4c^=128: Usdcno™SigType"3 :RWLC_UE_NAME :Iitt «r £ac e" 128' Uardtno™RM1£ -... F P £kddRe LRHIJC <.. FpSA-ddRspni R^di O L L nkS e tujRe que E t 1 FIn RNCRadi oLi nl^ et,u^pRe sp QUS eRJH£ -... FpSInitKa^RH1£ <... fpSIftitRs 卫SigT^s-^ ； RNLC UE NAfi1E ; Zitt-srfa.ee-12S :V JFOut RflC rr cC oiaie c t i onS etuptn he Mmdi Q L L iLkRest orelndi cati onIn RNCrr cC onne cti onS e lup 匚TSigTyp&=3 :RNLC_UE_NAME ： Interfit e=123. UnknovrnSigTypa=3 :RNLC 」IE 」J AM E :Interface=12S: IhdmomOut KSCmeasurein HitControlOut 颐measur&m »nt. Control图中：FP 为帧协议（Node B 与RN （同步使用，此时的同步只是针对于用户的新的无线链 路的同步，并不是整个 Node B 与RNC 勺同步）3. RRC 失败分析RRC 连接失败发生 RRC 1接建立的过程中，RRC 连接一般发生在如下情况下:（1） UE 开机Out 磴 ITeC4Mk4ftiIn R1T >_r cC omxe cti onKel e =B .E eCompl ete叶RJK Radi oLi itkDel eli o itRes tIn RNUEadi oLi iLkUftleiL^iJ^a^ponseIn RNC 'rrcConntcti oqud ~~Oti+ or Jkm&i oLi& t uj>Re que E t 丄1 一In RHT Ra4i oLi nJ£ e t uj>Re sp OILS e Out 咄U rrcCowuecti oxSetuy KEC 连接过丄 In or Ra-li oLi rJ<R&it*ir«Ii ,Lili cati 皿宓 uC oraxti onS 戢 urUompgg（2）UE关机（3）位置区更新（4）UE进行主叫业务（5）UE进行被叫业务参考协议25331, RRC连接失败的原因被分成了两类：（1）Un specified （未定义）（2）Con gestion （拥塞）但在我司的RRC连接失败的原因则根据信令过程，同时参考协议被分成了三类：（1）Un specified （未定义）（2）Con gestion （拥塞）（3）NoReply （未响应）在日常优化的过程中，RRC连接失败则增加了一种情况，变成了一种现象和三种原因，这新增的一种现象就是在路测中UE已经发起了RRC Conn ection Request 但经过T300超时并且N300超数，从而造成起呼失败。