企业官网建设流程全解析

简介：这是一份聚焦5G网络优化中室分零低流量小区排查与处理的实战分享PPT，适合从事5G网络优化、室分运维及基站维护的工程师学习。内容系统梳理了故障、覆盖干扰、用户行为、工程原因四类主要成因，并给出了从告警监控、CQT测试、RF优化到物业协调、施工整改的完整处理流程；还以襄阳、宜昌2023年134个零低流量小区为案例，逐类拆解问题数量与对应措施，便于快速对标自查。资源为1个pptx文件，大小6.61MB，正文配有原因分类、处理建议表格与现场排查截图，结构清晰，可直接用于班组培训或优化工作复盘。已有123人学习下载，适合希望提升室分问题定位效率、建立系统排查思路的网优人员参考。

1. 零低流量小区：先分清是真故障还是假空闲

室分零低流量小区在5G建网初期远比大家想象得多。襄阳、宜昌两地在2023年2月第一周到3月第二周就筛出134个，其中“无用户”占了67个，表面看是没人用，但拉到现场逐个摸排，大部分是设备掉电、合路器频段错配、天馈未接、驻波告警导致没法发射信号。真正因为用户行为导致的小区反而是少数。所以排查零低流的第一原则是：先确认覆盖到底存不存在，再谈用户行为。如果NR设备根本没接入室分系统，网管上看到的零流量就是假象。下面把这些问题按故障、覆盖干扰、用户行为、工程原因四条线拆开，结合告警分析、合路器排查和整改案例，给出一套能直接复用的处理流程。

2. 故障类排查：从告警分类到驻波定位

2.1 告警归类和占比判断

RRU告警是零低流量最直接的表现。襄阳、宜昌筛出的134个小区里，RRU故障原因占比约8%，虽然不高，但处理优先级最高，因为故障不恢复，其他优化手段都白做。RRU告警大致分三类：传输类、电源类、硬件类。传输类常见的是BBU光模块收发异常、小区断链、射频单元维护链路异常；电源类就是设备掉电、BBU掉电；硬件类多表现为驻波告警和接口异常。

判断告警占比有一个技巧：把网管导出的告警数据按小区关联到KPI，标注出哪些零低流小区“带告警”，哪些“无告警”。告警小区优先派单处理，无告警小区才进入覆盖、参数和用户行为分析。实际做的时候不要只看当天告警，至少要拉一周左右的告警历史，因为有些掉电和传输闪断是间歇性的。

2.2 用KPI和告警数据做自动关联筛选

手动查告警效率太低，尤其小区数量过百的时候。我一般会从网管导出小区级日均KPI和告警历史，用Python脚本把零低流小区和告警信息合并在一起，按告警优先级排序，几秒钟就能拉出排查清单。脚本写得很简单，核心就三步：读KPI、读告警、按小区ID合并。

import pandas as pd # 网管导出的小区级日均KPI，包含小区ID、下行流量、上行流量 kpi_df = pd.read_excel("nr_cell_daily_kpi.xlsx") # 告警历史，包含小区ID、告警名称、告警级别、发生时间 alarm_df = pd.read_excel("rru_alarm_history.xlsx") # 零低流判断：上下行流量都为0，或者下行流量低于50MB且上行低于10MB zero_low = kpi_df[ (kpi_df["DLVolume"] == 0) & (kpi_df["ULVolume"] == 0) ] # 左连接告警数据，保留所有零低流小区 merged = zero_low.merge( alarm_df, left_on="CellId", right_on="CellId", how="left" ) # 按告警级别和小区id排序，便于现场派单 merged = merged.sort_values( ["AlarmLevel", "CellId"], ascending=[True, True] ) merged.to_csv("zero_low_cell_with_alarm.csv", index=False)

这段脚本里，DLVolume和ULVolume是网管里常见的流量字段，单位为MB，实际字段名可能叫PdcpDownlinkVolume或者DownlinkTraffic，需要根据网管版本做映射。AlarmLevel通常是数字或者字符串，比如“Critical”和“Major”，排序时把严重告警排前面。用左连接而不是内连接，是为了保留那些没有告警但同样是零低流的小区，避免漏掉覆盖或用户行为问题。脚本输出的CSV可以直接导入到派单系统，也可以继续喂给地图插件做GIS渲染。

2.3 驻波告警与天馈的关联判断

驻波告警在零低流小区里非常隐蔽。设备可能没断，但驻波比过高会导致RRU功率严重回退，覆盖面积缩水，用户终端无法驻留。比如玲珑国际这个案例，NR主设备驻波告警，现场增加衰减器后告警消失，楼层恢复覆盖，但要彻底解决还需要排查电梯井内天馈线和无源器件。驻波告警最常见的成因是三类：馈线接头松动或进水、天线本身损坏、合路器端口阻抗不匹配。

排查驻波时建议做以下动作：先在网管上查看RRU的驻波比当前值和告警历史，看是持续告警还是间隙性告警；再到现场用SiteMaster或驻波测试仪从RRU输出端向天线侧打，逐段排查接头和馈线。如果手头没有测试仪，可以临时换一根跳线或用负载代替天馈测试RRU本身是否正常，这是区分“RRU坏”还是“天馈坏”的最快办法。

3. 覆盖干扰与工程原因：合路器频段、天馈方向与CQT验证

3.1 覆盖问题怎么区分不合理、弱覆盖和干扰

覆盖问题在零低流小区中成因很杂，常见三种：天馈覆盖不合理、覆盖区域弱覆盖、系统内外干扰。天馈覆盖不合理指方向不对，比如楼顶射灯天线对着楼道打，或者只覆盖了电梯、地下室，对外围公共区域覆盖不到；弱覆盖指器件接错、线路断连、驻波导致功率损耗；干扰问题则集中在NR2.1G未完成清频，和LTE或者其他NR系统之间相互干扰。

3.2 合路器频段不匹配：最典型的工程硬伤

襄阳和宜昌的案例里，合路器问题有7个小区，数量不算特别多，但每个都是“现场测试无NR覆盖”的典型。最直观的是环球金融城1号楼15F：NR设备功率输出正常，SSB频点428910，但合路器接口是2110-2125MHz，和NR 2.1G频段不符，导致信号根本合不出去。换个2130-2170MHz的合路器接口，覆盖立即恢复。

这类问题排查思路很简单：先看NR设备支持哪些频段，再看合路器上标注的频率范围，两者必须匹配。比如RRU5515支持1.8G和2.1G双频段，但合路器输入端口如果只标了1.8G，NR 2.1G信号就进不去。遇到这种情况，要么更换为对应频段的合路器，要么增加功分器把NR出线直接合到室分系统上，但要注意增加功分器会引入额外的插损，需要重新核算功率预算。

3.3 CQT测试与RF优化的标准步骤

覆盖问题确认后，RF优化需要按步骤来。CQT（呼叫质量测试）是室内覆盖优化的主要手段，我一般会按以下流程走：

1. 在网管上确认小区状态正常、无驻波和断链告警后，记录PCI、SSB频点、小区ID。
2. 使用路测软件锁定待测小区频点和PCI，在楼层内逐点打点测试，记录RSRP、SINR、上下行速率。
3. 对RSRP低于-105dBm的区域，先用频谱仪或扫频仪确认是否存在外部干扰，排除干扰后再调整天线方向或功率。
4. 若覆盖偏弱但天线点位少，需要计算天馈各节点功率，用信号源从RRU输出端逐级向下测，找到衰减异常的中点。
5. 整改完成后现场复测，并同时观察网管上的用户数和上下行流量，确认是否由零低流转为正常流量小区。

每一步都要拍照存档，尤其是天线方向和合路器接口照片。因为室分问题往往是多个原因叠加，现场和网管信息对不上就会反复跑站。

4. 襄阳、宜昌134个案例复盘：数据分布和典型整改过程

4.1 134个零低流小区的成因占比

襄阳、宜昌两地排查范围是2023年2月第一周至3月第二周期间，2021年以后入网的室分5G零低流量小区，共134个。按原因分类看，无用户67个，占比最高；新建室分问题38个；天馈线路问题8个；合路器问题7个；未测到覆盖区域7个；干扰问题5个；设备掉电2个。这个分布很能说明当前阶段的问题：新建室分和用户行为加起来超过75%，真正属于传统覆盖弱场的小区反而少。

4.2 典型案例拆解：从网管数据到现场定位

案例一：城市印象四期，PCI 389。网管显示零低流，现场测试无NR覆盖，排查主设备HUAWEI5916e为4T4R，发现设备掉电、传输未接通。处理方式就是协调物业恢复供电并重新做传输数据，这类问题没有优化空间，只能靠推进度。

案例二：环球金融城1号楼15F，PCI 503。设备在弱电井内，NR设备功率正常，SSB频点428910，但合路器接口2110-2125MHz与设备频段不符。更换为2130-2170MHz合路器后覆盖恢复。这个案例对后续排查很有参考价值：看到“设备正常但无覆盖”时，第一反应应该查合路器频率范围和天馈连接。

案例三：樊西衡庄还建房，PCI 370。主设备HUAWEI5916 4T4R，现场测试无NR覆盖，原因是设备反开4G。也就是说NR设备默认配置为LTE模式，没有开通NR小区。这种情况在网管上表现为小区状态正常，但实际发射的是LTE信号。排查时要重点看小区的载波配置和SSB频点是否存在。

案例四：襄州人民医院急诊楼，PCI 373。NR设备天馈未连接，需要核查联通清频状态。这个案例和合路器问题类似，属于工程施工未完成。区别在于这里不是频段匹配问题，而是馈线压根没接到室分系统上。

案例五：玲珑国际地下室，PCI 751。原名为玲珑国际，后更名维也纳智好酒店。现场测试NR只覆盖B1F停车场，发现部分天馈未连接，接入信源后出现驻波告警，增加衰减器后告警消失。电梯井内天馈线和器件驻波问题仍需进一步处理。这个案例展示了同一站点叠加两个故障的处理节奏：先消除驻波告警，再排查天馈驻波根源。

4.3 新建室分占比高是阶段性特征

新建室分问题38个，是仅次于无用户的第二大原因。新建站批量入网后，RRU告警、天馈未接、传输断链、覆盖不合理都会集中暴露。不少站点因为物业纠纷掉电，还有站点覆盖区域本身就是未交付的新小区。对这类站点，建议把整改优先级按物理资源成本排序：设备掉电和传输断链优先处理，天馈未接次之，覆盖不合理最后通过RF优化调整。

新建站还有一个容易忽略的问题：同一栋楼不同楼层可能由不同RRU覆盖，但网管小区配置可能张冠李戴。环球金融城1号楼案例里，18F弱电井内没有电信NR设备，实际覆盖18F的是15F的设备，网管小区位置数据却写成了18F。遇到这种“网管有小区，现场找不到设备”的情况，要先核对PCI和楼层对应关系，避免误判为设备丢失。

5. 零低流小区验证与长期监控的实操技巧

5.1 现场整改后的验证清单

整改完成不等于问题闭环。我建议每次现场整改后都按下面这个清单做二次验证，避免漏项和返工。

有两点容易被忽视：一是“设备功率输出正常”不等于“天馈系统正常工作”，功率再大送不出去也白搭；二是整改后不要当天就下结论，至少观察三天，因为有些驻波告警和掉电是间歇性的，当天正常不代表后续稳定。

5.2 每日监控指标的建立方法

长期监控不能只看流量绝对值，要建立一个能自动预警的指标组合。我在网管上做了一套简易模板，每天定时导出以下几项数据：小区是否零流量、是否低流量（阈值按地市情况定义）、是否存在重要告警、活跃用户数、上下行PRB利用率。用前面提到的Python脚本做关联后，把结果分三个等级：有功告警的派单处理；无告警但流量为0的进行CQT复测；只存在低流量的合并到周度RF优化任务。

# 伪代码示意：每日巡检输出重点排查小区 output = zero_low_cells \ .filter(alarm_level in ["Critical", "Major"]) \ .group_by(city, station_name) \ .sort_by(priority)

这个脚本的核心是给每个小区打上“原因倾向”标签：有掉电告警的标为供电问题，有驻波告警的标为天馈问题，无告警且覆盖测试正常的标为用户行为。标签和派单系统打通后，零低流小区数量会快速下降，剩下的就是真正需要市场侧介入的长期无用户小区，需要持续跟踪用户量变化和话务增长趋势。

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