简介这是一份聚焦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掉电硬件类多表现为驻波告警和接口异常。告警类别常见告警名称对流量的影响处理建议传输类BBU光模块收发异常、小区断链、不可用告警小区完全不可用流量为0检查光模块、尾纤、传输端口配合传输侧核对电源类设备掉电、BBU掉电、直流输入异常设备离线流量掉0现场确认供电空开和蓄电池状态协调物业硬件类驻波告警、射频单元维护链路异常功率回退或关闭覆盖变差检查天馈接头、馈线、合路器和天线判断告警占比有一个技巧把网管导出的告警数据按小区关联到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_onCellId, right_onCellId, howleft ) # 按告警级别和小区id排序便于现场派单 merged merged.sort_values( [AlarmLevel, CellId], ascending[True, True] ) merged.to_csv(zero_low_cell_with_alarm.csv, indexFalse)这段脚本里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系统之间相互干扰。问题现象常见原因现场验证手段处理建议室分天馈只覆盖电梯和停车场天线点位少、方向错误逐层CQT测试对比RSRP必要时增加天线点位调整馈线连接覆盖区域存在明显弱场器件接错、线路断连、驻波功率计测试各节点输出功率用功率计算定位断点更换合路器和功分器扫频发现高干扰未清频、异系统邻频干扰扫频仪拉网测试上行底噪协调2.1G清频调整频点或加滤波器3.2 合路器频段不匹配最典型的工程硬伤襄阳和宜昌的案例里合路器问题有7个小区数量不算特别多但每个都是“现场测试无NR覆盖”的典型。最直观的是环球金融城1号楼15FNR设备功率输出正常SSB频点428910但合路器接口是2110-2125MHz和NR 2.1G频段不符导致信号根本合不出去。换个2130-2170MHz的合路器接口覆盖立即恢复。这类问题排查思路很简单先看NR设备支持哪些频段再看合路器上标注的频率范围两者必须匹配。比如RRU5515支持1.8G和2.1G双频段但合路器输入端口如果只标了1.8GNR 2.1G信号就进不去。遇到这种情况要么更换为对应频段的合路器要么增加功分器把NR出线直接合到室分系统上但要注意增加功分器会引入额外的插损需要重新核算功率预算。3.3 CQT测试与RF优化的标准步骤覆盖问题确认后RF优化需要按步骤来。CQT呼叫质量测试是室内覆盖优化的主要手段我一般会按以下流程走在网管上确认小区状态正常、无驻波和断链告警后记录PCI、SSB频点、小区ID。使用路测软件锁定待测小区频点和PCI在楼层内逐点打点测试记录RSRP、SINR、上下行速率。对RSRP低于-105dBm的区域先用频谱仪或扫频仪确认是否存在外部干扰排除干扰后再调整天线方向或功率。若覆盖偏弱但天线点位少需要计算天馈各节点功率用信号源从RRU输出端逐级向下测找到衰减异常的中点。整改完成后现场复测并同时观察网管上的用户数和上下行流量确认是否由零低流转为正常流量小区。每一步都要拍照存档尤其是天线方向和合路器接口照片。因为室分问题往往是多个原因叠加现场和网管信息对不上就会反复跑站。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号楼15FPCI 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 现场整改后的验证清单整改完成不等于问题闭环。我建议每次现场整改后都按下面这个清单做二次验证避免漏项和返工。验证项验证方法通过标准小区状态网管查询小区状态和告警无断链、不可用、驻波告警覆盖恢复楼层CQT测试目标区域RSRP均值高于-105dBm合路器频段现场核对接头标签和频段与NR频段完全一致驻波比RRU驻波比查询或仪表测试驻波比低于1.5流量恢复网管查看整改后3天日均流量下行流量不再为0且用户数大于0有两点容易被忽视一是“设备功率输出正常”不等于“天馈系统正常工作”功率再大送不出去也白搭二是整改后不要当天就下结论至少观察三天因为有些驻波告警和掉电是间歇性的当天正常不代表后续稳定。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)这个脚本的核心是给每个小区打上“原因倾向”标签有掉电告警的标为供电问题有驻波告警的标为天馈问题无告警且覆盖测试正常的标为用户行为。标签和派单系统打通后零低流小区数量会快速下降剩下的就是真正需要市场侧介入的长期无用户小区需要持续跟踪用户量变化和话务增长趋势。本文还有配套的精品资源点击获取