简介这份PPT资料聚焦5G网络优化中的室分零低流量小区排查与处理面向从事室分维护、网络优化及运维管理的技术人员帮助其系统梳理零低流量成因并掌握对应处置方法。内容从故障、覆盖干扰、用户行为、工程四类原因切入配套告警监控、CQT测试、RF优化、功率核算、扫频排查等处理流程并附襄阳、宜昌134个小区的实测案例与分类数据。资源包共1个pptx文件约6.61MB以图文幻灯片形式呈现便于培训分享与现场查阅。目前已有123人学习。读者可借此建立从原因归类到处理建议的完整排查思路结合真实案例理解设备掉电、合路器频段不符、天馈未接通等典型问题的定位与整改方式提升室分资源利用效率与用户感知。1. 室分零低流排查一份把134个小区拆到器件级的实战复盘做5G网络优化的同行大概都有过这种经历网管上某个室分小区连续几天流量挂零派单下去现场兄弟跑一趟回来说“设备正常、传输正常、覆盖正常”然后单子就卡在那儿了。问题出在哪出在“正常”这两个字太笼统。室分零低流量从来不是一个单一故障它是故障、覆盖、干扰、用户行为、工程遗留五类问题交织出来的结果你不把它拆到合路器接口频段、跳线弯曲角度、甚至电梯井里那根馈线的驻波比这个粒度就永远只能反复派单、反复“正常”。这份《室分零低流排查分享》的价值就在这儿。它把2023年2月到3月间某区域134个零低流量小区的排查过程做了完整归因设备掉电2个、合路器问题7个、干扰5个、天馈线路8个、未测到覆盖区域7个、新建室分问题38个、无用户67个。注意这个分布真正需要动硬件的问题加起来不到30个而“无用户”占了整整一半。这意味着如果你拿到一个零流量小区第一反应是查告警、查驻波方向可能从一开始就偏了。这份材料适合两类人一是刚接手室分优化、面对零低流量工单不知道从哪下手的工程师二是已经做了几年但排查效率上不去、想建立一套标准流程的老手。它不教你5G原理它教你怎么在最短时间内判断一个零流量小区到底值不值得修、该派谁去修、修完怎么验证。2. 零低流量归因从四类原因到可执行的判断树2.1 故障类问题的分层排查逻辑故障是零低流量最“硬”的原因也是最好确认的。但“故障”这个词太宽实际排查中需要按告警类型分成三层来看。第一层是电源和传输。设备掉电断站、BBU掉电、传输光接口异常这三类问题在网管上通常表现为小区退服或断链不会只体现为零流量。如果你看到的是“小区不可用”而不是“小区可用但流量为零”那基本可以直接归到这一层。处理方式也简单联系维护人员现场确认供电和传输链路不需要优化人员亲自跑。第二层是RRU硬件告警。这是最容易被忽略的一层因为小区状态可能是“可用”的但实际射频通道已经出了问题。材料里明确列出了四类关键告警BBU光模块收发异常、小区断链及不可用、射频单元维护链路异常、驻波告警。其中驻波告警尤其隐蔽它不一定导致小区退服但会让射频功率大幅回退覆盖范围缩到天线口几米之内用户根本搜不到信号。134个小区里RRU故障占比约8%这个比例不算高但考虑到告警站点如果不长期监控很容易在统计周期内被遗漏。第三层是接口和时钟。系统时钟不可用、BBU接口异常、射频接口异常这些问题往往不会单独出现而是伴随其他告警一起。排查时建议按“先电源传输、再RRU硬件、后接口时钟”的顺序过一遍不要跳步。注意驻波告警的处理不能只看告警是否消除。材料里有一个案例是设备接入信源后出现驻波告警增加衰减器后告警消失、全楼覆盖恢复但电梯井内天馈线及器件的驻波问题仍需进一步排查。衰减器只是临时手段不解决根本问题。2.2 覆盖与干扰问题的现场判断方法覆盖和干扰是零低流量里最考验现场经验的一类。材料把覆盖问题分成了三种天馈覆盖不合理、覆盖区域不合理、覆盖区域弱覆盖。这三种在网管上看起来一模一样都是“小区有功率输出但用户少”必须到现场才能区分。天馈覆盖不合理的典型场景是室分只覆盖了电梯和地下停车场。这种设计在4G时代很常见因为当时语音业务是重点电梯和地库是覆盖盲区。但5G时代流量主要产生在办公区和住宅区只覆盖电梯地库的室分自然没有流量。判断方法很简单拿测试手机沿楼栋走一圈看主服务小区PCI是否始终是该室分小区。如果只在电梯里占用出电梯就切到室外站那就是天馈覆盖范围问题。覆盖区域不合理的典型表现是天馈方向不对。材料里提到楼顶射灯天线覆盖方向不合理的情况这种问题在网管上完全看不出来必须结合楼宇结构和天线安装位置判断。一个实用的方法是在楼顶找到射灯天线看它的朝向是否对准了对面楼栋的窗户或阳台。如果对着天空或墙壁那覆盖效果可想而知。覆盖区域弱覆盖的原因更偏工程细节驻波、器件接错、线路断连。材料里给出的处理建议是通过功率计算排查天馈线路及合路器。具体操作是在信源端口测发射功率然后逐级往下测看哪一级出现了异常衰减。正常情况下一段馈线损耗在3dB以内一个功分器损耗在3到5dB如果某一级衰减远超预期那问题就在那一级。干扰问题在室分场景里主要来自系统内和系统外。系统内干扰最常见的是NR2.1G未完成清频导致与LTE2.1G相互干扰。系统外干扰则需要扫频排查。材料里对高干扰小区的建议就是扫频这个没有捷径。2.3 用户行为和工程原因的区分标准用户行为和工程原因造成的零低流量在网管上的表现几乎一样小区状态正常、无告警、有功率输出、但流量为零或极低。区分它们的关键在于时间维度和区域属性。用户行为导致零低流量的典型特征是有明显的周期性。高校场景在寒暑假期间流量归零开学后恢复体育场馆在无赛事期间流量极低有活动时流量飙升。这类小区不需要优化需要的是长期监控和等待。材料里给出的处理建议是推送高价值资讯、广告宣传、资费促销这属于市场手段不是网络优化能解决的。另一个容易被忽略的用户行为是终端不支持5G或未打开5G开关。这种情况在网管上表现为该区域有4G流量但5G流量为零。处理方式是通过投诉处理发现用户使用习惯问题给予操作指导。听起来简单但在实际排查中很多工程师会先入为主地认为是网络问题绕一大圈才发现是用户手机设置问题。工程原因造成的零低流量则集中在新建站。材料列出了四种典型情况物业纠纷导致掉电、传输断链、天馈线未接通、开通后覆盖不合理。这四种问题的共同点是都发生在新建站入网初期且往往伴随施工未完成或验收不严格。134个小区里新建室分问题占了38个接近三成这个比例说明新建站的质量管控存在明显短板。区分用户行为和工程原因的一个实用判断树是先看入网时间如果是近三个月内新建的优先排查工程原因再看时间规律如果有明显周期性优先考虑用户行为最后看区域属性新建小区、新建写字楼在入住率低时流量低是正常的不需要过度优化。3. 排查流程落地从网管筛选到现场验证的完整链路3.1 网管侧的数据筛选与告警关联排查的第一步不是去现场而是在网管上把零低流量小区筛出来并且和告警数据做关联。材料里的做法是筛选2023年2月第一周至3月第二周的数据范围是21年至今新建的室分。这个时间窗口的选择有讲究两周的数据可以排除单日波动只保留持续零低流量的小区限定新建室分则是因为老站如果突然零流量大概率是故障而非工程遗留问题。筛选出小区列表后下一步是关联告警。重点看四类BBU光模块收发异常、小区断链及不可用、射频单元维护链路异常、驻波。这四类告警在网管上通常有独立的告警ID可以直接用脚本批量提取。如果手工做建议按告警级别排序高级别告警优先处理。# 网管零低流量小区与告警关联筛选示例 # 输入零低流量小区列表、告警日志 # 输出带告警标记的小区清单 import pandas as pd # 读取零低流量小区清单 zero_low_cells pd.read_csv(zero_low_cells.csv) # 字段示例cell_name, pci, enodeb_id, 入网日期, 2月流量, 3月流量 # 读取告警日志 alarms pd.read_csv(alarms.csv) # 字段示例cell_name, alarm_id, alarm_name, alarm_level, occur_time # 关键告警ID映射根据实际网管定义调整 key_alarms { BBU光模块收发异常: ALM-1001, 小区断链: ALM-1002, 小区不可用: ALM-1003, 射频单元维护链路异常: ALM-1004, 驻波告警: ALM-1005 } # 筛选关键告警 key_alarm_records alarms[alarms[alarm_id].isin(key_alarms.values())] # 按小区聚合告警 alarm_summary key_alarm_records.groupby(cell_name)[alarm_name].apply( lambda x: |.join(x.unique()) ).reset_index() alarm_summary.columns [cell_name, 告警类型] # 关联零低流量小区和告警 result zero_low_cells.merge(alarm_summary, oncell_name, howleft) result[告警类型] result[告警类型].fillna(无关键告警) # 输出分类结果 result.to_csv(zero_low_with_alarms.csv, indexFalse) print(f共筛选零低流量小区 {len(result)} 个) print(f有关键告警的小区 {len(result[result[告警类型] ! 无关键告警])} 个)这段代码的逻辑是先加载零低流量小区清单和告警日志然后按预设的关键告警ID筛选再按小区聚合告警类型最后与零低流量清单做左连接。参数方面key_alarms字典需要根据实际网管的告警ID定义调整不同厂商的告警编码不同。输出结果里“无关键告警”的小区就是需要进一步从覆盖、干扰、用户行为、工程原因四个方向排查的对象。3.2 现场排查的标准化步骤到了现场之后排查顺序直接影响效率。材料里的案例虽然分散但归纳起来有一套标准步骤可以复用。第一步是确认设备状态。看主设备是否掉电、传输是否接通、小区是否激活。这一步对应的是故障类问题也是最容易确认的。材料里“城市印象四期”的案例就是设备掉电加传输未接通现场一看便知。第二步是测覆盖。拿测试手机沿楼栋走一圈重点看三个位置电梯、地下停车场、楼栋中间层。如果这三个位置都占用不到室分小区说明天馈系统存在断点或信源未接入。材料里“碧桂园北区”的案例就是NR设备未接入室分系统连接后覆盖恢复。第三步是查合路器。这一步最容易被跳过但材料里合路器问题占了7个小区是硬件问题中占比最高的。合路器的问题主要是频段不匹配。比如“环球金融城1号楼”的案例NR设备功率输出正常SSB频点428910但合路器接口是2110-2125MHz与NR2.1G的2130-2170MHz不匹配更换合路器接口后覆盖恢复。另一个“东辰心语A区”的案例是合路器输入接口为1.8G与NR2.1G频段不符需要更换合路器或增加功分器。第四步是查天馈线路。重点看跳线弯曲角度、接头是否拧紧、馈线是否有断点。材料里“东辰心语A区”的案例提到NR设备端跳线为1/2普通跳线弯曲角度过大建议更换。这个细节说明现场施工质量对覆盖的影响非常大。第五步是测驻波。如果信源接入后出现驻波告警说明天馈系统存在阻抗不匹配。材料里“玲珑国际”的案例是增加衰减器后告警消失但电梯井内天馈线及器件的驻波问题仍需进一步排查。衰减器只是临时手段根本解决需要找到驻波点并更换器件。3.3 典型场景的处理建议对照材料里针对不同问题类型给出了处理建议我把它们整理成一张对照表方便现场排查时快速定位。问题类型典型现象处理建议责任方设备掉电小区退服、网管无功率输出联系物业协调供电规范新建站流程维护物业传输断链小区不可用、BBU接口异常告警督促施工人员整改严格要求施工质量施工方天馈未接通小区可用但无覆盖督促监理和施工人员按方案完成施工施工监理合路器频段不符信源功率正常但无覆盖更换对应频段合路器或增加功分器优化施工天馈覆盖不合理仅电梯地库有信号排查覆盖范围必要时增加天线优化覆盖方向不合理目标区域弱覆盖CQT测试后RF优化调整天线方向优化弱覆盖全楼信号弱功率计算排查天馈线路及合路器优化施工干扰高干扰、SINR差扫频排查确认干扰源优化用户行为周期性零流量长期监控市场手段配合市场优化新建站未完成入网初期零流量加快整改进度严格验收施工监理这张表的使用方法是先根据网管筛选和告警关联确定问题类型然后按对应的处理建议派单。如果一个问题同时命中多个类型按“故障 工程 覆盖 干扰 用户行为”的优先级处理。4. 避坑与常见问题那些排查单上不会写的细节4.1 设备反开4G导致零流量材料里“樊西衡庄还建房”的案例是一个典型的反直觉问题现场测试发现站点无NR覆盖排查主设备为HUAWEI59164T4R设备反开4G造成零低流量小区。所谓“反开4G”是指设备硬件支持5G但实际配置为4G模式运行。这种情况在网管上可能显示为NR小区但实际射频通道跑的是LTE信号5G终端自然搜不到。现象网管显示NR小区状态正常但现场测试无NR覆盖周边用户占用室外站。 原因设备被配置为4G模式或软件版本不支持NR或小区参数中NR载波未正确配置。 解决登录设备确认当前运行模式检查小区配置中NR载波是否激活必要时重新配置并重启小区。这个坑的隐蔽性在于如果你只看网管状态和告警完全看不出问题。必须到现场用测试手机确认实际广播的信号类型。4.2 合路器频段不匹配的隐蔽性合路器频段不匹配是材料里出现频率最高的硬件问题但它在网管上没有任何告警。设备功率输出正常、驻波正常、小区状态正常唯一的表现就是没有覆盖。现象信源设备功率输出正常但天线口无信号或信号极弱。 原因合路器输入接口频段与NR设备输出频段不匹配信号在合路器内部被滤除或大幅衰减。 解决核对合路器铭牌上的频段范围确认与NR设备频段一致。材料里两个案例分别是2110-2125MHz和1.8G接口都需要更换为2130-2170MHz或增加功分器。排查时建议随身带一个频谱仪或功率计在合路器输入和输出端口分别测功率。如果输入正常但输出异常基本可以确定是合路器问题。4.3 天馈未接通与驻波告警的先后关系材料里“襄州人民医院急诊楼”和“玲珑国际”两个案例都涉及天馈未接通。前者是NR设备天馈未连接后者是NR设备部分天馈未连接。这两个案例的共同点是设备本身正常但信号出不去。现象小区状态正常无驻波告警但现场无覆盖。 原因天馈线未连接到设备端口或连接了但接头未拧紧。 解决逐段检查天馈线路从设备端口开始确认每一级连接可靠。这里有一个容易搞反的逻辑驻波告警通常在天馈接通后才会出现。如果天馈完全没接驻波检测电路可能检测不到异常反而不会告警。所以“无驻波告警”不等于“天馈正常”。正确的做法是现场确认每一段馈线的连接状态而不是依赖网管告警。4.4 网管设备位置与实际不符材料里“环球金融城1号楼18F”的案例非常典型网管查询设备安装位置为18F弱电井现场测试发现18F NR信源为15F NR设备弱电井内无电信NR设备全楼弱电井内未发现该设备。最后通过PCI和覆盖关系推断出设备实际位置。现象按网管位置找不到设备或找到的设备与网管信息不符。 原因网管数据录入错误、设备被迁移但未更新、多运营商共用弱电井导致混淆。 解决通过PCI和覆盖关系反推设备位置。材料里的方法是列出各楼层PCI和对应设备位置通过覆盖关系判断实际信源。这个坑的教训是网管数据只能作为参考现场必须以实际测试为准。建议在排查前先打印一份网管设备清单到现场后逐项核对发现不符立即记录并反馈更新。4.5 用户行为问题的过度优化材料里“无用户”占了67个小区接近一半。这意味着如果你拿到一个零流量小区有50%的概率它根本不需要优化。但实际工作中很多工程师会习惯性地去调功率、调天馈、甚至加设备结果流量没上来反而增加了干扰。现象小区状态正常、无告警、覆盖正常但流量持续为零。 原因区域实际用户少或用户终端不支持5G或用户未打开5G开关。 解决先查区域属性新建小区、新建写字楼、高校假期再查用户终端类型最后才考虑网络优化。对于确实无用户的小区建议长期监控不要过度优化。判断方法如果小区覆盖区域内4G流量正常但5G流量为零大概率是终端或开关问题如果4G和5G流量都低那就是用户少。这两种情况都不需要网络优化。5. 从排查到闭环用PCI反查和功率计算把问题钉死排查做到最后最怕的是“看起来恢复了但实际没恢复”。材料里“玲珑国际”的案例就是典型增加衰减器后驻波告警消失、全楼覆盖恢复但电梯井内天馈线及器件的驻波问题仍需进一步排查。这说明表面恢复不等于根本解决。我一般会在排查收尾时做两件事一是用PCI反查确认覆盖关系二是用功率计算验证天馈链路。PCI反查的操作方法是在问题楼栋的每一层用测试手机记录主服务小区PCI然后和网管上的PCI清单做对照。如果某层的主服务PCI不是该室分小区说明该层没有被室分覆盖或者被室外站抢占了。材料里“环球金融城1号楼”的案例就是通过PCI反查发现18F实际信源是15F设备从而修正了网管数据。# PCI反查覆盖关系示例 # 输入现场测试的楼层-PCI对应表、网管PCI清单 # 输出覆盖异常楼层清单 import pandas as pd # 现场测试数据 field_test pd.DataFrame({ 楼层: [B1, 1F, 5F, 9F, 13F, 15F, 18F, 22F, 28F], 主服务PCI: [501, 501, 502, 502, 503, 503, 503, 584, 584] }) # 网管PCI清单 pci_list pd.DataFrame({ PCI: [501, 502, 503, 584], 设备位置: [B1F弱电井, 9F弱电井, 15F弱电井, 28F弱电井], 覆盖楼层: [B1-4F, 5-12F, 13-23F, 22-35F] }) # 关联现场测试和网管数据 result field_test.merge(pci_list, left_on主服务PCI, right_onPCI, howleft) # 检查覆盖异常现场占用PCI与网管预期不符 # 例如18F预期占用50315F设备实际占用503正常 # 如果18F占用58428F设备则说明15F设备覆盖不足 print(result)这段代码的逻辑是把现场测试的楼层-PCI对应关系和网管PCI清单做关联然后人工检查每一层的实际占用PCI是否与网管预期一致。参数方面field_test需要现场逐层测试填写pci_list从网管导出。输出结果中如果某层的实际PCI与预期不符就需要进一步分析是覆盖不足还是室外站抢占。功率计算验证天馈链路的操作方法是在信源端口测发射功率然后按天馈链路逐级往下算。正常链路损耗包括馈线损耗约0.1dB/m、功分器损耗3dB或5dB、合路器插损约1dB、接头损耗约0.5dB/个。如果某一级的实测功率远低于计算值说明该级存在问题。材料里“东辰心语A区”的案例提到NR设备端跳线为1/2普通跳线弯曲角度过大。1/2跳线的弯曲半径如果小于规定值会导致阻抗不匹配和额外损耗。这个细节在功率计算中往往被忽略但实际影响可能达到2到3dB。从那以后我每次做完室分零低流量排查都会强制走一遍“PCI反查功率计算”的收尾流程。PCI反查确认覆盖关系没有漏洞功率计算确认天馈链路没有隐性损耗。这两步做完才能说这个问题真正闭环了。希望帮到你。本文还有配套的精品资源点击获取
