企业官网建设流程全解析

简介：这份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, on='cell_name', how='left') result['告警类型'] = result['告警类型'].fillna('无关键告警') # 输出分类结果 result.to_csv('zero_low_with_alarms.csv', index=False) 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 典型场景的处理建议对照

材料里针对不同问题类型给出了处理建议，我把它们整理成一张对照表，方便现场排查时快速定位。

这张表的使用方法是：先根据网管筛选和告警关联确定问题类型，然后按对应的处理建议派单。如果一个问题同时命中多个类型，按“故障 > 工程 > 覆盖 > 干扰 > 用户行为”的优先级处理。

4. 避坑与常见问题：那些排查单上不会写的细节

4.1 设备反开4G导致零流量

材料里“樊西衡庄还建房”的案例是一个典型的反直觉问题：现场测试发现站点无NR覆盖，排查主设备为HUAWEI5916，4T4R，设备反开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_on='PCI', how='left') # 检查覆盖异常：现场占用PCI与网管预期不符 # 例如18F预期占用503（15F设备），实际占用503，正常 # 如果18F占用584（28F设备），则说明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反查确认覆盖关系没有漏洞，功率计算确认天馈链路没有隐性损耗。这两步做完，才能说这个问题真正闭环了。希望帮到你。

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