小区高负荷造成无线接通率低处理案例.
VoLTE高掉线差小区处理案例
VoLTE高掉线差小区处理案例发布时间：2022-04-24T12:58:16.730Z 来源：《中国建设信息化》2022年1期作者：蒋馥珍李磊李海娣[导读] LTE网络相对以前3G的使用感知有较大提升，其中采取了关键技术之一就是V oLTE技术蒋馥珍李磊李海娣中国联合网络通信有限公司潍坊市分公司一、摘要LTE网络相对以前3G的使用感知有较大提升，其中采取了关键技术之一就是V oLTE技术，目前5G语音解决方案VONR还不成熟，仍需VOLTE打底。
V oLTE语音相对之前语音方案具有接通快，通话音质更清晰，保持性好等优点，但V oLTE掉话对用户使用语音感知影响较大。
V oLTE掉话主要有：覆盖问题、干扰问题、切换问题、邻区问题、参数配置问题以及终端设备问题。
日常优化并减少掉话可以提高语音感知，提升用户使用感知。
二、关键词V oLTE、掉话、电联共享、冗余邻区外部三、案例正文（一）案例背景根据集团考核标准，例行周级统计质差发现昌乐宝城西崔区域9个小区突发高掉话，查询小区其他无线侧KPI正常，无干扰，无告警；查询周边站点传输侧业务也无异常，查询掉话原因值发现小区因传输层问题导致的语音业务异常释放占比较高，无线侧未发现异常，需进一步分析。
（二）案例描述1、无线侧指标查询：后台网管核查该站点无异常告警和干扰告警，用户数占用正常，小区无线侧指标，负荷情况均正常，小区WFCL0237-HW-F1HD02-(北局-宝城西崔)-B1 的最大用户数、同频切换成功率、RRC连接成功率、ERAB建立成功率、掉话率、无线接通率、系统每PRB接收的干扰噪声平均值、上行PRB平均利用率、下行PRB平均利用率、平均TA（米）分别为：64、99.96%、99.98%、99.97%、0.04%、99.96%、-112.14、9.67、13.37、1105.99。
2、掉话失败原因值定位：提取周边小区QCI1掉话原因值发现，小区因传输层问题导致的语音业务异常释放占比较高。
TD无线优化案例：干扰导致接通率低优化案例
故障案例干扰导致接通率低优化案例（中学）公司移动专业优化设备类型RNC设备厂家中兴设备型号8300/8800 软件版本V.200.V300编制时间2010-08-10 作者作者电话关键字干扰;接通率故障现象近日后台话务统计发现,XX中学基站_2小区CS域接通率持续较低（接通率90%左右），针对这种情况，前台优化人员对XX中学基站_2进行了现场测试。
XX中学基站站点过高，约102米（山高大约70米、楼高约12米、铁塔20米）。
针对上述问题，前台对XX中学基站_2进行50次CQT测试，测试时PCCPCH_RSCP=-70dBm,PCCPCH_C/I=20dB,50次全接通，未发现任何异常情况。
如下图：关系截图告警信息无原因分析后台优化人员跟踪XX中学_2小区级信令,从信令流程上来分析发现：RNC下发RRC connection setup后，由于UE未做出响应,使得RNC侧未收到RRC connection setup Connection Complete消息，最终导致未接通。
➢异常信令流程如下:➢正常信令流程如下：RNC下发RRC connection setup， UE收到该消息后上发rrcConnectionSetupComplete 至RNC。
➢RRC连接建立信令流程：后台信令跟踪，确认了终端发送的RRC CONNECTION REQUEST 已成功发送至RNC，且RNC也下发了RRC CONNECTION SET UP，但终端并未给RNC回发RRC CONNECTION SET UP COMPLETE消息，我们知道：RRC connection setup从RNC的控制面发出，经过内部处理，通过传输线路到Node B，在Node B内部处理，通过RRU经过空口到UE，在这个环节中每一个环节出现问题都会出现无响应并最终导致未接通现象。
常见原因1）干扰可能导致UE不能将RRC Connection Setup Complete信令发送给RNC；2）传输存在问题从RNC到Node B之间的传输存在问题，传输误码较大，丢包较多，造成不能正确地将RRC Connection Setup信令发送给Node B；3）Node B存在问题Node B的某个板子（在这里主要是指UPBI板，UPBI板为承载和传送信令板，承载及正确的传送信令是建立在UPBI板正常的基础上，UPBI板存在问题可能导致信令流程无法正常完成；4）RRU存在问题RRU不能正确地接收UE上发的RRC Connection Setup Complete信令，或是不能正确地将RRC Connection Setup信令作传送给UE；对XX中学基站附近区域进行了DT测试,RSCP图、C/I图如下：RSCP图CI图处理步骤怀疑在XX中学_2覆盖的居民区内, XX中学_2与城郊法庭_3存在同频干扰,将XX中学_2。
LTE无线接通率优化提升案例
无线接通率低优化案例一、问题描述西安长庆宾馆-HLH-XAAO133TL-2无线接通率指标7月24号开始严重下滑，根据失败counter主要是由于RRC重建失败较高造成，其中该小区接入失败主要集中在早晚忙时间段。
二、问题分析针对该项指标进行相关的counter指标提取，发现问题主要集中在“小区内因为无上下文导致的RRC重建拒绝的次数(无)”和“UE无应答而导致RRC重建失败次数(无)”这两个counter，结合现场情况需逐步排查分析。
用户接入失败分析过程：基站告警核查当前无告警，历时告警无。
基础参数核查（随机接入、上行功控、重选）◆SRI自适应开关，自适应调整SRI调度周期◆小区级子帧树重配开关，根据小区资源使用情况，动态调整SRS的子帧配置◆PUCCH算法开关，当PUCCH资源不足时可以发起资源配置调整◆将SRS资源配置方式的接入优先◆上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率PRB上行干扰核查无干扰，全天均值-118左右。
是否存在弱覆盖核查该站位置，怀疑是由于周边楼宇比较密集有阻挡导致覆盖不足以及深度覆盖不够，需提升调整上行功控参数路径损耗因子以及PUSCH标称P0值提升UE发射功率以及由于资源分配不足导致的RRC失败。
三、解决方案SRS/PUCCH资源分配而导致RRC连接建立失败1.打开SRI自适应开关，自适应调整SRI调度周期MOD GLOBALPROCSWITCH: SRIADAPTIVESWITCH=ON;2.打开小区级子帧树重配开关，根据小区资源使用情况，动态调整SRS的子帧配置MOD CELLALGOSWITCH: SRSALGOSWITCH=SrsSubframeRecfSwitch-1;3.打开PUCCH算法开关，当PUCCH资源不足时可以发起资源配置调整MOD CELLALGOSWITCH: LOCALCELLID=2, PUCCHALGOSWITCH=PucchSwitch-1;4.将SRS资源配置方式修改为接入优先MODSRSCFG:LOCALCELLID=0,SRSCFGIND=BOOLEAN_TRUE,TDDSRSCFGMODE=ACCESS_FIRST;UE无应答导致RRC建立失败调整上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率MOD CELLULPCCOMM:LOCALCELLID=2,PASSLOSSCOEFF=0.8,P0NOMINALPUCCH=-105;四、实施效果对比7月27日对该小区进行参数调整，调整后指标明显提升，如下图：五、总结a)在问题分析过程中若发现失败次数集中在某个counter，需考虑整体性的原因，如是否存在故障以及干扰或者某类参数设置不当导致等。
接通率低指标优化案例
丰台科丰桥FD小区接通率低指标优化案例
问题描述
性能工单中出现丰台科丰桥FDD-131，-133小区接通率低，同时持续发生。
问题分析
从接通率指标来看1,3小区接通率指标低于90%，但是无告警，无干扰，其他指标也正常，没有发现异常情况。
问题处理
通过后台统计继续分析，发现FDD 双通道上行RSSI电平差值较大，于是安排塔工上塔检查RRU和天馈连接。
中兴FDD 1800M RRU通常都是四口，2T4R，但是考虑到天馈一般都是2个口，所以数据制作的过程中只会用到1,4口，组成1T2R的配置。
但是上站后发现这个站点天线有4个1800M
的天馈口，四个天馈口的天线阵子是分布在天馈两侧，中间是GSM900的两个口。
这就造成了后台配置的1,4口天馈实际覆盖上存在差异。
造成接通率低原因。
处理过程截图
通过天馈检查后，基本知道天馈问题不大，将后台2通道天馈系统，配置为4通道天馈系统，接通率指标恢复正常。
处理结果:
处理后接通率指标基本保持在99%以上。
问题总结:
后续FDD的配置情况，需要跟现场连接吻合，同时如果存在问题，需要现场核实硬件连接情况。
LTE无线接通率优化提升案例
无线接通率低优化案例一、问题描述西安长庆宾馆-HLH-XAAO133TL-2无线接通率指标7月24号开始严重下滑，根据失败counter主要是由于RRC重建失败较高造成，其中该小区接入失败主要集中在早晚忙时间段。
二、问题分析针对该项指标进行相关的counter指标提取，发现问题主要集中在“小区内因为无上下文导致的RRC重建拒绝的次数(无) ”和“UE无应答而导致RRC重建失败次数(无)”这两个counter，结合现场情况需逐步排查分析。
➢用户接入失败分析过程：➢基站告警核查当前无告警，历时告警无。
➢基础参数核查（随机接入、上行功控、重选）◆SRI自适应开关，自适应调整SRI调度周期◆小区级子帧树重配开关，根据小区资源使用情况，动态调整SRS的子帧配置◆PUCCH算法开关，当PUCCH资源不足时可以发起资源配置调整◆将SRS资源配置方式的接入优先◆上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率➢PRB上行干扰核查无干扰，全天均值-118左右。
➢是否存在弱覆盖核查该站位置，怀疑是由于周边楼宇比较密集有阻挡导致覆盖不足以及深度覆盖不够，需提升调整上行功控参数路径损耗因子以及PUSCH标称P0值提升UE发射功率以及由于资源分配不足导致的RRC失败。
三、解决方案SRS/PUCCH资源分配而导致RRC连接建立失败1.打开SRI自适应开关，自适应调整SRI调度周期MOD GLOBALPROCSWITCH: SRIADAPTIVESWITCH=ON;2.打开小区级子帧树重配开关，根据小区资源使用情况，动态调整SRS的子帧配置MOD CELLALGOSWITCH: SRSALGOSWITCH=SrsSubframeRecfSwitch-1;3.打开PUCCH算法开关，当PUCCH资源不足时可以发起资源配置调整MOD CELLALGOSWITCH: LOCALCELLID=2, PUCCHALGOSWITCH=PucchSwitch-1;4.将SRS资源配置方式修改为接入优先MODSRSCFG:LOCALCELLID=0,SRSCFGIND=BOOLEAN_TRUE,TDDSRSCFGMODE=ACCESS_FIRST;UE无应答导致RRC建立失败调整上行功控参数路径损耗因子、PUSCH标称P0值提升UE发射功率MOD CELLULPCCOMM:LOCALCELLID=2,PASSLOSSCOEFF=0.8,P0NOMINALPUCCH=-105;四、实施效果对比7月27日对该小区进行参数调整，调整后指标明显提升，如下图：五、总结a)在问题分析过程中若发现失败次数集中在某个counter，需考虑整体性的原因，如是否存在故障以及干扰或者某类参数设置不当导致等。
濮阳联通案例边缘覆盖导致低接入质差小区处理案例
濮阳联通案例边缘覆盖导致低接入质差小区处理案例一、问题描述濮阳市濮阳县王称堌乡马章庄L小区PYLZO2A56_4，RRC接通率低于98%，导致无线接通率低。
查询RRC建立成功率指标得知，主要的失败原因为等待RRC 建立完成定时器超时。
如下表：二、问题分析RRC建立的counter中其他原因和等待RRC建立完成定时器超时，多为无线环境导致。
基站侧收不到RRCConnectionSetupComplete，可能来源于两方面：（1）系统下发了RRCConnectionSetup消息，但终端没有收到；（2）终端发送了RRCConnectionSetupComplete消息，但终端没有收到。
进一步查看网管侧性能指标，核查站点无故障告警情况，MR>-112dBm采样点占比较低，存在弱覆盖情况。
干扰噪声在-119分贝毫瓦，无干扰情况。
TA>3000米用户数占比超过10%。
继续查看站点位置信息，该小区为边界小区，无线环境复杂，L900覆盖过远造成弱覆盖，导致RRC建立定时器超时。
三、处理建议措施1：将小区电子下倾角由3度下压到10度，RS功率由15.2调整到12.2措施2：将等待RRC建立完成的定时器由2秒优化为15秒，延长定时器时长，避免边缘UE定时器超时。
措施3：控制面user-inactivity定时器由40秒优化为10秒；缩短UE不活动定时器，可增大RRC连接建立次数，进而提升RRC接入成功率。
措施4：小区选择所需的最小RSRP接收水平（selQrxLevMin）：由-128dBm 优化为-120dBm，减少边缘用户接入，提升接通率。
四、优化效果优化调整后问题小区濮阳县王称堌乡马章庄L小区PYLZO2A56_4，RRC接通率提升至99%以上，问题小区解决：。
NB-IoT性能劣化小区处理方法及优化案例
NB-IoT性能恶化小区分析处理方法为及时有效处理NB-IoT性能恶化小区，现针对四项NB-IoT重要性能指标的分析处理方法进行归纳总结，集结成优化处理方法，具体指标如下：➢NB高干扰小区1、排查小区及周边小区是否存在GPS告警、基站晶振告警，GPS跑偏、基站晶振问题会导致区域性小区上行干扰抬升，若存在告警，则进行故障排除；2、通过小区干扰与业务忙闲时趋势关系，以及小区周边基站的干扰情况，判断是网内干扰还是外部干扰；3、对于底噪抬升导致的内部干扰，通过现场测试查看是否存在重叠覆盖情况，如存在，调整覆盖优化网络结构。
也可通过功控参数调整降低用户初始发射功率、或临时频率调整解决（注：频率调整不能作为常规优化手段使用）。
4、对于外部干扰，使用扫频设备进行扫频，确认干扰源，协调相关部门清除干扰源；5、对于室内小区的干扰，可以重点排查各类器件显隐性故障。
➢RRC低接通率小区1、排查小区是否存在硬件、传输告警，若存在告警，则进行故障排除；2、核查小区RRC建立相关参数，查看设置是否在合理范围内；3、查看RRC建立拒绝相关Counter，查找RRC建立拒绝原因：✓对于小区资源分配失败导致的RRC建立拒绝，可以通过容量参数适当调整控制小区覆盖范围：如延长RRC接入惩罚时间、降低PRACH重发次数、缩短UE不活动定时器时长、抬高覆盖等级RSRP门限、接入电平或功率调整等；若参数调整无效，则考虑下倾角调整等天馈调整方案；对于长期高业务负荷的小区可考虑边新建基站等。
✓对于MME过载导致的RRC建立拒绝，协同核心网一起排查；✓对于小区流控导致的RRC建立拒绝，可通过容量参数适当收缩小区覆盖范围；如仍无法改善，需查看小区硬件负荷，对于硬件负荷高的单板或BBU，进行扩展；4、排查小区是否存在上下行干扰，对于上下行干扰导致的RRC建立拒绝，确认干扰类型，结合无线环境进行相应的优化调整；5、对于无法明确判断的RRC建立失败，可以通过对小区进行信令跟踪，进一步分析RRC建立失败原因。
拥塞导致小区接入性差案例
TD语音业务 无线接通率
(%)
PS域无线接 通率(%)
语音拥塞次 数
数据拥塞次数
2014-2-23 景洪市州师范逸夫楼_3 21.7912
0.3628
99.58%
99.58%
0
0
2014-2-24 景洪市州师范逸夫楼_3 34.6726
0.6703
99.78%
99.78%
0
0
2014-2-25 景洪市州师范逸夫楼_3 88.6040
景洪市州师范逸夫楼_3接通率走势
180
TD语音业
160 140
务无线接 120
通率(%) 100
80
PS域无线 60 接通率(%) 40
20
0
景洪市州师范逸夫楼_3拥塞次数走
语音拥 塞次数
数据拥 塞次数
2014/3/3 2014/3/5 2014/3/7 2014/3/9 2014/3/11 2014/3/13 2014/3/15 2014/3/17
三、解决措施：板件扩容
解决措施：3月7日添加FS板件一块、PM电源模块1个，UBPM板件一块，3小区扩 容至最大配置12载频。扩容后CS接通率达到99.80%左右，PS接通率99.75%，拥 塞次数降至10以下。考虑到小区的TD终端驻留比情况，关闭基于资源预警的异系 统切换。
100.00% 98.00% 96.00% 94.00% 92.00% 90.00% 88.00% 86.00%
94.69%
96.96%
139
54
2014-3-4 景洪市州师范逸夫楼_3 184.8140 11.1209
93.89%
96.93%
148
36
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
故障案例小区高负荷造成无线接通率低处理案例省公司江苏省专业无线设备类型设备厂家中兴设备型号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.结合用户投诉情况，安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；指标是否正常保存跟踪信令及测试数据，提交问题排查交付件至华为研发定位问题。
检查操作，是否存在告警，传输问题，是否存在网络变动和升级行为等；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%，确定小区存在高误码；1、 通过排查，该小区不存在告警、参数、干扰等问题，如下图所示通过提取TA 分布发现该小区TA 分布主要集中在0-9范围内，覆盖集中在大约0-700米内，不存在远距离接入的情况：1TA=16Ts=16*32.55ns*300000000/2=78m基站地理分布:2、通过查询发现RRC建立失败原因主要为“mo-Data类型RRC连接失败次数，定时器超时”平均1小时600多次，如图所示：日期RRC连接建立成功率mt-Access类型RRC连接失败次数，定时器超时mo-Signalling类型RRC连接失败次数，定时器超时mo-Data类型RRC连接失败次数，定时器超时RRC连接释放次数，空口定时器超时RRC连接释放次数，重建立失败引发的释放2015/6/7 10:00 95.09% 79 132 459 27 93 2015/6/7 11:00 94.17% 80 247 601 54 1052015/6/7 12:00 94.93% 114 95 594 24 444、如下图所示“mo-Data类型RRC连接失败次数，定时器超时”造成的RRC连接建立失败主要是因：CPU负荷是否偏高，用户数多、参数、NI是否偏高、RRU输出功率异常、是否MR任务和其他实时跟踪任务导致接入定时器超时、是否弱场导致接入定时器超时等。
RRC处理手段计数器编号计数器名称/描述信息建议措施C3732001 mt-Access类型RRC连接失败次数，定时器超时(次)1.检查CPU负荷是否偏高，用户数是都很多，如是调整SR容量进行优化2.检查上\下行功控类参数3.检查NI是否偏高4.检查RRU输出功率5.检查是否MR任务和其他实时跟踪任务导致接入定时器超时6.检查是否弱场导致接入定时器超时。
C373200002 mt-Access类型RRC连接失败次数，eNB接纳失败(次)1.检查接纳控制类参数设置C373200003 mt-Access类型RRC连接失败次数，其他原因(次1.检查是否CPU冲高导致2.提交故障单交研发处理C373200005 mo-Signalling类型RRC连接失败次数，定时器超时(次)1.检查CPU负荷是否偏高，用户数是都很多，如是调整SR容量进行优化2.检查上\下行功控类参数3.检查NI是否偏高4.检查RRU输出功率5.检查是否MR任务和其他实时跟踪任务导致接入定时器超时6.检查是否弱场导致接入定时器超时。
C373200006 mo-Signalling类型RRC连接失败 1.检查接纳控制类参数设置次数，eNB接纳失败(次)C373 00007 mo-Signalling类型RRC连接失败次数，其他原因(次)1.检查是否CPU冲高导致2.提交故障单交研发处理C373200009 mo-Data类型RRC连接失败次数，定时器超时(次)1.检查CPU负荷是否偏高，用户数是都很多，如是调整SR容量进行优化2.检查上\下行功控类参数3.检查NI是否偏高4.检查RRU输出功率5.检查是否MR任务和其他实时跟踪任务导致接入定时器超时6.检查是否弱场导致接入定时器超时。
C373200010 mo-Data类型RRC连接失败次数，eNB接纳失败(次)1.检查接控类参数设置C373200011 mo-Data类型RRC连接失败次数，其他原因(次)1.检查是否CPU冲高导致2.提交故障单交研发处理C373200013 highPriorityAccess类型RRC连接失败次数，定时器超时(次)1.检查CPU负荷是否偏高，用户数是都很多，如是调整SR容量进行优化2.检查上\下行功控类参数3.检查NI是否偏高4.检查RRU输出功率5.检查是否MR任务和其他实时跟踪任务导致接入定时器超时6.检查是否弱场导致接入定时器超时。
C373200014 highPriorityAccess类型RRC连接失败次数，eNB接纳失败(次)1.检查接纳控制类参数设置C373200015 highPriorityAccess类型RRC连接失败次数，其他原因(次)1.检查是否CPU冲高导致2.提交故障单交研发处理C373200017 emergency类型RRC连接失败次数，定时器超时(次)1.检查CPU负荷是否偏高，用户数是都很多，如是调整SR容量进行优化2.检查上\下行功控类参数3.检查NI是否偏高4.检查RRU输出功率5.检查是否MR任务和其他实时跟踪任务导致接入定时器超时6.检查是否弱场导致接入定时器超时。
C373200018 emergency类型RRC连接失败次数，eNB接纳失败(次)1.检查接纳控制类参数设置C373200019 emergency类型RRC连接失败次数，其他原因(次)1.检查是否CPU冲高导致2.提交故障单交研发处理5、通过分析发现该小区每小时空口流量在7GB左右，PRB利用率最高在49%左右，RRC最大用户数250人左右，为严重高负荷小区。
通过以上分析最终确认RRC建小区高负荷导致RRC建立成功率低。
时间空口总业务字节数(GB)空口上行业务字节数GB空口下行业务字节数GB[TDD]上行信道PRB资源利用率[TDD]下行信道PRB资源利用率RRC连接建立最大用户数RRC连接建立平均用户数2015/6/7 10:00 7.33 0.48 6.85 38.54% 49.02% 187 152.24 2015/6/7 11:00 7.11 0.51 6.6 42.59% 48.49% 254 193.12 2015/6/7 12:00 6.49 0.37 6.12 37.05% 45.12% 236 166.23 2015/6/7 13:00 5.27 0.32 4.95 37.65% 35.75% 268 213.25处理步骤:未避免指标继续恶化造成用户投诉临时对以下参数进行了调整:1、CRS参考信号功率由18->12：2、A1、A2门限由-92、-95改为-79、-823、进行负荷分担3、如下图所示，随后提取指标发现RRC用户由250下降至170左右，无线接通率指标也恢复正常：4、该小区因用户较多，造成高负荷，临时调整并不能彻底解决问题，还需扩容吸收话务量。
但该站位于空军后勤学院内，工程队到现场后经过协调整仍无法进入，不能扩容。
因在原站上不能进行扩容所以计划调整附近的站点方位角吸收话务，该站最近的两个点为LTE市区后勤学院和LTE市区空后院搬迁，但因LTE市区后勤学院1、3覆盖区域为网格和空军后勤学院比较敏感不符合条件，而LTE市区空后院搬迁为D频段小区覆盖范围较小，综合以上因因素，最终确定在LTE市区空后院搬迁上扩容F频段小区增强覆盖吸收话务。
如下图所示：物理视图，在BBU10槽位新增一了块BPN2板，下挂了3台(M1920A)RRU拓图视图：5、扩容前后LTE市区城坤钢材市场东_1小区指标与用户数对比：6、LTE市区空后院搬迁F_2扩容后用户数。