企业官网建设流程全解析

简介：面向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数据并排之后，我习惯先把结果填成一张画像表，这样排查路径会更清晰。不同特征组合对应的方向差异很大，下面这张表是这几年现场排查后总结出来的典型情况。

这张表的前两行对应硬件和射频风险，第三行对应干扰风险，第四行对应参数和覆盖竞争，最后一行则要先解决小区可用性问题。零低流排查本质上就是把这张表里的问号一个个填掉。填完之后，下一章进入后台逐层过滤。

3. 室分零低流排查路径：告警、驻留与业务模型的逐层过滤

3.1 先查告警和硬件状态，排查“假零低流”和隐性故障

画像是想出来的，告警是查出来的。零低流室分里有一类最坑的情况：小区和RRU都显示正常，但某条光链路上的模块已经降级，只有低速率业务能通，高速率业务全部失败。这种现象在话统上表现为流量累计缓慢，但RRC成功次数并不少。所以无论话统多干净，第一层过滤永远是告警和硬件状态确认。

常见的动作是登入网管，查询小区状态和小区所在RU的实时告警。我通常把查询命令做成一个模板，后台巡检时直接复用。以类MML命令风格的网管为例：

# 查询小区状态，确认小区是否闭塞或BAR DSP CELL:LOCALCELLID=0; # 查询RRU光口和驻波状态，确认射频链路健康 DSP RRU:CN=0,SRN=0,SN=0; # 导出最近7天小区级告警，过滤关键网元 LST ALMLOG:CGI="460-00-12345-1", BEGINTIME="2025-05-01", ENDTIME="2025-05-07";

DSP CELL用于查看小区是否处于Cell Barred或小区重选禁止状态，如果状态显示“未禁用”但实际被BAR，需要看小区参数里的cellBarred字段。DSP RRU是射频单元健康检查，重点看驻波比和光模块收发光功率。驻波比高于1.5且持续不下降时，无源系统故障概率极高。LST ALMLOG导出后，把输出重定向到本地再过滤，避免在网管页面上卡死。

成功过滤掉告警项后，需要看小区是否存在“无告警但指标畸变”的隐性故障。常见做法是在凌晨低话务时段对怀疑的RRU做通道测试，对比各通道的接收功率和上行底噪，差值超过3dB就视为异常。这个测试通常要用厂商OMC的远程维护功能，这里不展开命令，但结论要记入下一层的排查依据。

3.2 核查重选与切换参数，解决“有覆盖但驻留不进来”的零低流

硬件和告警都干净后，把重心放到小区广播参数和重选参数上。室分系统一个典型问题是小区最小接入电平（qRxLevMin）设置过高，导致弱信号终端根本无法接入。另外一个高频问题是小区重选优先级配置错误，室分小区优先级低于宏站时，即使信号强度足够，终端也会因为优先级差异长时间驻留在宏站。

下面是排查参数时的核心配置项和检查标准：

# 查看小区系统消息里的最小接入电平和重选参数 LST CELLSEL: LOCALCELLID=0; # 查看小区频点优先级和重选门限 LST EUTRANINTERNFREQ: LOCALCELLID=0; # 查看异频邻区关系，确认切换触发条件是否合理 LST EUTRANEXTERNALCELL: LOCALCELLID=0;

qRxLevMin一般按-124dBm或-128dBm配置，如果查到配置反而高于-120dBm，室分场景下要立即修改。CellReselPriority是小区重选优先级，室内小区在所属频点上应高于或等于宏站同频优先级，否则容易造成驻留困难。ThreshXHighP是异频高门限，如果宏站和室分使用不同频点，门限配置偏低会压缩室分的驻留范围。

参数修改前必须保留原始配置截图，修改命令要带执行时间。以类MML风格为例：

MOD CELLSEL: LOCALCELLID=0, QRXLEVMIN=-128, CELLBARRED=BAR04; MOD EUTRANINTERNFREQ: LOCALCELLID=0, DL_EARFCN=38098, CELLRESELPRIORITY=6;

上面将qRxLevMin降低到-128dBm，同时把重选优先级调整到6，让终端在满足条件时更倾向驻留室分。需要注意，CELLBARRED=BAR04在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连接建立次数是否有上行拐点，第三层是流量是否稳定超过预定阈值。

以下调整记录表的格式是我在项目里常用的，用来避免改完参数后忘了跟进：

这张表的价值是把零低流的动作和结果绑在一起。有效项可以进入台账归档，无效项目要重新回到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='', encoding='utf-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(key=lambda 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分析，它只是把第一层筛选从“人看表格”变成“机器过滤”，让有限的时间留给真正需要现场判断的小区。

本文还有配套的精品资源，点击获取