室分零低流排查全攻略：从话统分析到现场复测的完整路径

简介面向5G网络优化工程师的室分零低流量小区排查处理分享以演示文稿形式系统梳理了零低流量小区的成因与处置方法。内容涵盖故障、覆盖干扰、用户行为、工程原因四大类问题并给出告警长期监控、CQT测试与RF优化、功率计算、扫频排查等处理手段针对设备掉电、合路器频段不符、天馈线未接通、新建站无用户等情况也提供了对应协调和整改思路。课件结合2023年襄阳、宜昌两地134个零低流量小区的真实排查数据剖析了各类问题占比及处理闭环对日常优化排障、排查报告编写和内部培训均有直接借鉴价值。资源为1个pptx文件大小6.61MB结构清晰已有123人学习。1. 室分零低流不是“等一等”的问题先给小区做体检室分零低流在移动网络优化里是长期存在的盲区后台看某个室分小区连续一周下行流量不足一条视频流忙时RRC连接建立次数也少得可怜。多数人第一反应是“这个商场都没人了”但我在一线排查时发现真正因为潮汐人流导致零低流的比例并不高反而是RRU通道隐性故障、光模块劣化、小区被BAR掉、最小接入电平配置过高这些工程侧问题占了大多数。零低流不是结束指标而是开始信号。这篇文章就从数据口径入手把从网管告警、MR覆盖、参数驻留到现场复测的排查路径走一遍最后给一个可以日常套用的快速评估脚本。适合做网优、基站运维和室分专项改造的同事照着层级过滤能省掉大半重复工单。2. 室分零低流的识别指标与数据口径先分清“没人用”和“用不了”2.1 从网管话统里提取小区级流量与用户数圈定疑似目标做零低流排查的第一步不是跑现场而是先把后台策略口径定下来。不同区域对“零低流”的定义差异很大有的按每小区日均流量小于50MB算有的按忙时流量长期为零算。我一般建议用“连续7天、室内小区、日均流量低于100MB且日均RRC连接数低于10次”作为初始过滤条件后续根据设备型号和室分场景收敛阈值。网管话统里需要关注的关键计数器是下行数据流量、上行数据流量、RRC连接建立成功次数、E-RAB建立成功次数和平均在线用户数。下面这个SQL模拟从汇整话统表里取一周数据的写法实际库表字段会有厂商差异但过滤逻辑通用。SELECT c.cell_name, c.earfcn, c.pci, SUM(c.rrc_conn_succ) AS rrc_conn_cnt, SUM(c.erab_succ) AS erab_cnt, SUM(c.dl_traffic_bytes c.ul_traffic_bytes) / 1024 / 1024 AS total_mb, AVG(c.avg_active_users) AS avg_active_users FROM day_cell_traffic c WHERE c.stat_date DATE 2025-05-01 AND c.stat_date DATE 2025-05-07 AND c.cell_type INDOOR GROUP BY c.cell_name, c.earfcn, c.pci HAVING SUM(c.dl_traffic_bytes c.ul_traffic_bytes) / 1024 / 1024 100 AND SUM(c.rrc_conn_succ) 70 ORDER BY total_mb ASC;这里day_cell_traffic是假设的天级话统表rrc_conn_succ统计成功建立RRC连接次数erab_succ是E-RAB建立成功次数avg_active_users是平均激活用户数。筛选条件是按一周70次RRC连接折算日均10次同时满足总流量低于100MB。注意HAVING里的聚合条件在WHERE之后执行所以不能把SUM写在WHERE里这是我常见到的新手错误。如果网管自带报表也可以用“室内站型”过滤条件快速导出。但建议保留pci字段后面到现场查PCI混淆和切换关系时要用。2.2 用MR数据评估覆盖与干扰区分“真没人”和“驻留不上”话统只能证明小区不忙不能证明覆盖没问题。室分零低流经常出现的典型情况是“有信号但驻留不上”终端收到这个室分小区的信号但因为重选参数、最小接入电平或干扰导致无法正常注册于是所有业务都挤到旁边另一个小区上。要判断这种情况必须把MR测量报告数据拉出来看RSRP和SINR的分布。MR数据一般按采样点汇总可以从网管的MR统计模块导出小区级RSRP区间占比和SINR区间占比。常见做法是把RSRP低于-105dBm的采样点占比超过50%或者SINR低于0dB的采样点占比超过30%作为覆盖或干扰异常标记。下面这个查询逻辑是从原始MR采样表里按小区聚合弱覆盖占比SELECT m.cell_name, COUNT(*) AS total_samples, SUM(CASE WHEN m.rsrp -105 THEN 1 ELSE 0 END) AS weak_samples, SUM(CASE WHEN m.sinr 0 THEN 1 ELSE 0 END) AS interference_samples, ROUND(SUM(CASE WHEN m.rsrp -105 THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 2) AS weak_ratio FROM mr_raw_sample m WHERE m.stat_date DATE 2025-05-07 GROUP BY m.cell_name HAVING SUM(CASE WHEN m.rsrp -105 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) 50;如果话统已经是零低流同时MR的弱覆盖占比很高问题大概率在射频通道或天线系统上。如果MR覆盖正常但SINR差干扰或参数问题占主要。如果MR和话统都正常那这个小区可能本身是覆盖盲区内的无主小区或者用户业务被邻区吸走需要结合下一步的驻留分析看。逐条对比后可以给每个小区打一个初步标签然后再进网管查告警。2.3 零低流小区画像表用数据模型判断故障方向把话统和MR数据并排之后我习惯先把结果填成一张画像表这样排查路径会更清晰。不同特征组合对应的方向差异很大下面这张表是这几年现场排查后总结出来的典型情况。话统特征MR覆盖干扰情况大概率问题方向流量为零RRC极少RSRP正常SINR正常小区被BAR、最小接入电平过高、基带板通道故障流量为零RRC极少RSRP弱SINR正常RRU驻波告警、天线口松动、无源器件损坏流量极低RRC有一定量RSRP正常SINR差邻区同频干扰、上行底噪抬升、外部干扰源流量极低RRC极少RSRP正常SINR正常潮汐效应但阈值设置过严或被邻区信号覆盖竞争流量为零RRC为零无MR数据无MR数据小区状态Fault、时钟失步、光链路断这张表的前两行对应硬件和射频风险第三行对应干扰风险第四行对应参数和覆盖竞争最后一行则要先解决小区可用性问题。零低流排查本质上就是把这张表里的问号一个个填掉。填完之后下一章进入后台逐层过滤。3. 室分零低流排查路径告警、驻留与业务模型的逐层过滤3.1 先查告警和硬件状态排查“假零低流”和隐性故障画像是想出来的告警是查出来的。零低流室分里有一类最坑的情况小区和RRU都显示正常但某条光链路上的模块已经降级只有低速率业务能通高速率业务全部失败。这种现象在话统上表现为流量累计缓慢但RRC成功次数并不少。所以无论话统多干净第一层过滤永远是告警和硬件状态确认。常见的动作是登入网管查询小区状态和小区所在RU的实时告警。我通常把查询命令做成一个模板后台巡检时直接复用。以类MML命令风格的网管为例# 查询小区状态确认小区是否闭塞或BAR DSP CELL:LOCALCELLID0; # 查询RRU光口和驻波状态确认射频链路健康 DSP RRU:CN0,SRN0,SN0; # 导出最近7天小区级告警过滤关键网元 LST ALMLOG:CGI460-00-12345-1, BEGINTIME2025-05-01, ENDTIME2025-05-07;DSP CELL用于查看小区是否处于Cell Barred或小区重选禁止状态如果状态显示“未禁用”但实际被BAR需要看小区参数里的cellBarred字段。DSP RRU是射频单元健康检查重点看驻波比和光模块收发光功率。驻波比高于1.5且持续不下降时无源系统故障概率极高。LST ALMLOG导出后把输出重定向到本地再过滤避免在网管页面上卡死。成功过滤掉告警项后需要看小区是否存在“无告警但指标畸变”的隐性故障。常见做法是在凌晨低话务时段对怀疑的RRU做通道测试对比各通道的接收功率和上行底噪差值超过3dB就视为异常。这个测试通常要用厂商OMC的远程维护功能这里不展开命令但结论要记入下一层的排查依据。3.2 核查重选与切换参数解决“有覆盖但驻留不进来”的零低流硬件和告警都干净后把重心放到小区广播参数和重选参数上。室分系统一个典型问题是小区最小接入电平qRxLevMin设置过高导致弱信号终端根本无法接入。另外一个高频问题是小区重选优先级配置错误室分小区优先级低于宏站时即使信号强度足够终端也会因为优先级差异长时间驻留在宏站。下面是排查参数时的核心配置项和检查标准# 查看小区系统消息里的最小接入电平和重选参数 LST CELLSEL: LOCALCELLID0; # 查看小区频点优先级和重选门限 LST EUTRANINTERNFREQ: LOCALCELLID0; # 查看异频邻区关系确认切换触发条件是否合理 LST EUTRANEXTERNALCELL: LOCALCELLID0;qRxLevMin一般按-124dBm或-128dBm配置如果查到配置反而高于-120dBm室分场景下要立即修改。CellReselPriority是小区重选优先级室内小区在所属频点上应高于或等于宏站同频优先级否则容易造成驻留困难。ThreshXHighP是异频高门限如果宏站和室分使用不同频点门限配置偏低会压缩室分的驻留范围。参数修改前必须保留原始配置截图修改命令要带执行时间。以类MML风格为例MOD CELLSEL: LOCALCELLID0, QRXLEVMIN-128, CELLBARREDBAR04; MOD EUTRANINTERNFREQ: LOCALCELLID0, DL_EARFCN38098, CELLRESELPRIORITY6;上面将qRxLevMin降低到-128dBm同时把重选优先级调整到6让终端在满足条件时更倾向驻留室分。需要注意CELLBARREDBAR04在3GPP里对应not barred状态这个值要和厂商文档核对不要靠记忆填。参数修改后我一般会观察忙时RRC连接建立次数是否上升而不是只看流量。3.3 按业务模型排查“空载但有用户”的异常室分还有一类零低流小区很特殊RRC连接成功次数有一定量但E-RAB建立次数为零导致流量始终拉不起来。这通常是用户终端完成了驻留和随机接入但业务请求没有建立成功。这类现象和配置相关度低更多指向核心网或QoS参数问题。排查时可以对比RRC连接建立成功率与E-RAB建立成功率两者差距超过20%就要警惕。按我个人的经验室分零低流中有5%左右会落在这个模型上典型表现是手机能显示4G/5G信号但网页转圈、微信收不了消息。后台一般看不到无线侧明显异常需要查小区所在基站的S1或NG建立链路、PLMN配置和TA跟踪区是否与核心网一致。这个层级的排查建议联合核心网同事一起做不要自己改无线参数。否则容易把配置正常的小区改成“表面上能用、实际上发烫”的状态。排查结果要记录是外部原因还是无线侧原因方便在验收报告里定位责任边界。4. 室分零低流的现场复测与参数修正把优化动作落到小区4.1 用扫频、驻留测试和模拟业务复测现场覆盖后台参数和告警过滤到只剩一到两个候选小区后就必须去现场了。室分零低流尤其依赖现场验证因为后台MR是抽样数据而室分环境的衰减、器件老化和天线覆盖方向只能靠仪器确认。我一般带扫频仪、测试终端和笔记本电脑围着小区的分布范围走一遍弱覆盖点同时用手机工程模式看实际驻留和重选行为。现场第一个动作是锁频到室分小区的频点测试终端驻留情况和信号强度。如果锁频后可以直接驻留并做FTP下载说明无源链路基本正常。如果锁频后无法驻留看手机显示的网络拒绝原因常见的是PLMN不允许或TAC不一致这两个原因在后台看都是零流量但告警全无。如果锁频后能驻留但无法发起业务再测上行底噪和天线驻波。现场第二个动作是模拟业务不需要找专门测试软件用手机连续播放一个线上视频或发起几轮大文件下载就行。重点记录业务建立失败概率和速率波动曲线。若业务成功但速率极低需要检查室分系统有无混合接入老旧无源器件导致的高频损耗。现场数据与后台MR对照后才能决定是调整天线、更换器件还是只切换参数。4.2 参数调整后的观察窗口什么数据能证明优化生效现场修正完成后参数不能马上定论。零低流优化的验证周期至少要看连续24小时话统且要避开节假日和工作日的人流差异。我看指标时按三个层级观察第一层是小区可用性是否持续正常第二层是RRC连接建立次数是否有上行拐点第三层是流量是否稳定超过预定阈值。以下调整记录表的格式是我在项目里常用的用来避免改完参数后忘了跟进小区名问题标签修改时间修改参数修改前日均RRC修改前日均流量修改后72小时日均RRC修改后72小时日均流量结论0101-商场-3F-A驻留困难05-08 02:00qRxLevMin -124 → -12830.2MB261.8GB有效0102-办公楼-B1干扰05-08 02:10外部干扰排查815MB918MB无效转排查外部干扰这张表的价值是把零低流的动作和结果绑在一起。有效项可以进入台账归档无效项目要重新回到MR和告警层检查是否有未发现的隐性故障。观察窗口内不要同时修改多个小区的同参数否则无法区分到底哪个改动生效。4.3 避免零低流排查中的常见误判零低流排查最容易被误导的是“信号满格但没人用”。信号满格只能说明路测点收到该室分的信号不能代表全楼宇覆盖均衡。室分设计时通常有泄漏覆盖电梯口或楼道口的信号可能比房间内更好而后台统计的是小区整体表现。因此不要在门口测一次满格就下结论要覆盖室分天线的顶吸位置、房间内角、卫生间门口等关键采样点。另一个常见误判是把室分和宏站同频点误认为同小区。现场锁频测试时手机可能锁到窗边渗透的宏站信号而不一定是室分信号。确认的方法是查看手机显示的PCI是否与后台导出的室分小区PCI一致不同厂家手机工程模式的查看位置不同但要养成先记录PCI再分析数据的习惯。最后参数修改后如果48小时内出现告警回退需要先恢复现场再排查不要强行让零低流小区“硬扛”。5. 把室分零低流排查脚本化一个实用的快速评估模板零低流排查大量重复性工作在处理话统报表。手动导出一个周报表再筛选低流量小区每次要花十分钟而且口径不一致。我把过滤逻辑写成了一个独立脚本放在网管话统导出的CSV文件上直接跑输出一份按优先级排序的候选小区清单。这样每次排查都是从同一套标准出来的不会因人而异。#!/usr/bin/env python3 # -*- coding: utf-8 -*- 室分零低流快速评估脚本读取话统CSV输出候选小区及问题标签 import csv import sys from collections import defaultdict def evaluate(csv_path): cell_stats defaultdict(lambda: { rrc: 0, dl: 0, ul: 0, days: 0 }) with open(csv_path, newline, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: cell row[cell_name] stats cell_stats[cell] stats[rrc] int(row[rrc_conn_succ]) stats[dl] int(row[dl_traffic_bytes]) stats[ul] int(row[ul_traffic_bytes]) stats[days] 1 candidates [] for cell, stats in cell_stats.items(): if stats[days] 7: continue total_mb (stats[dl] stats[ul]) / 1024 / 1024 rrc_avg stats[rrc] / stats[days] if total_mb 100 and rrc_avg 10: candidates.append((cell, total_mb, rrc_avg, CANDIDATE)) candidates.sort(keylambda x: x[1]) print(f{CELL_NAME:24} {TOTAL_MB:10} {RRC_AVG:10} {TAG:10}) for c in candidates: print(f{c[0]:24} {c[1]:10.2f} {c[2]:10.2f} {c[3]:10}) return candidates if __name__ __main__: evaluate(sys.argv[1])这段脚本从CSV里读取小区名、RRC连接成功次数和上下行流量字节数按天累计后计算日均值。判定逻辑是连续七天内日均RRC小于10次且总流量低于100MB并将结果按流量升序输出。执行方式为python3 zero_low_flow.py daily_traffic_7d.csv前提是CSV表头必须包含cell_name、rrc_conn_succ、dl_traffic_bytes、ul_traffic_bytes四列。如果你的网管导出字段名不同只需要改row[...]里的键名不必改判定函数。脚本要在输出后回填到项目台账标注每个候选小区的MR覆盖、干扰和告警状态。回填过程通常才是真正拉长耗时的环节因此我建议每季度跑一次把历史候选和新候选横向对比找出“已优化但反复零低流”的小区。这类小区往往存在设计问题比如天线点位不足或无源器件老化单靠后台参数改不回来。脚本本身不替代告警和MR分析它只是把第一层筛选从“人看表格”变成“机器过滤”让有限的时间留给真正需要现场判断的小区。本文还有配套的精品资源点击获取