二维四象限驱动分频段弱覆盖簇智能识别：5G网优从人工到平台化

简介：面向5G网络优化工程师的专题方案文档，聚焦二维四象限法在分频段弱覆盖簇智能识别与优化中的落地应用。方案基于云瞰数字化平台，针对700M与2.6G频段覆盖差异，将全网区域簇划分为四类象限并给出差异化优化策略：微调TOP小区、调整异频异系统切换门限、功率抬升挖潜以及700M双波束覆盖增强（SCENARIO_201场景），有效解决传统RF优化潜力枯竭、调整周期长成本高的痛点。全文共1个doc文件，压缩包约1.54MB，内容涵盖四象限全景方案说明、Python算法筛选核心代码、门限配置参数表及典型区域实施案例。文中还给出量化效益数据，如全网云瞰覆盖率提升0.48%、单区域优化周期由2周缩短至4天等。目前已有143人学习下载，适合从事4G/5G网络优化、覆盖质量提升及无线课题研究的技术人员参考。

1. 二维四象限法驱动分频段弱覆盖簇智能识别：5G 网络优化从路测到平台化的关键一步

5G 网络优化做到今天，功率、倾角、RF 天馈这些传统手段基本都调过一轮了，再往上抠覆盖，性价比越来越低，RF 整改和室分改造又慢又贵，弱覆盖区域往往等不起。这篇要拆的项目，思路是反过来：不跟单一频段较劲，把 700M 和 2.6G 的覆盖好坏当成两个独立维度，用二维四象限把所有弱覆盖簇自动分成四类，每一类给一套对应的优化动作。配合云瞰平台的 MR 数据和一段 Python 脚本，分频段弱覆盖簇的筛选从人工逐个观察变成自动分类输出。适合正在做 5G 覆盖提升、被上百个簇数据压得头疼的网优工程师，也适合想了解平台化网优思路的同行。

2. 为什么是"700M+2.6G"双频段四象限：覆盖互补原理与问题簇分类标准

2.1 频段与终端支持度：四象限的物理依据

先想清楚一件事：为什么偏偏拿 700M 和 2.6G 两个频段做象限，而不是单看某一个频段的覆盖率？这来自两个频段完全相反的物理性格。700M 频率低，绕射能力强、穿透损耗小，覆盖距离远，在城区高层楼宇和郊区开阔地都吃得开；但短板是终端支持度低，很多手机不一定占得上 700M，空口覆盖好不代表用户真用上了。2.6G 频率高，带宽大，容量足，终端支持度普遍高，可恰恰因为频率高，信号被楼体一挡就掉得厉害，深度覆盖场景经常飘红。

用云瞰平台导出来的 MR 数据，能同时看到每个区域簇在 700M 和 2.6G 两个频段上的覆盖表现。把"700M 覆盖率是否达标"当作横轴，"2.6G 覆盖率是否达标"当作纵轴，自然就切成四个象限。这个做法的价值在于：它把原来"这个区域弱覆盖"这样一个笼统的黑匣子，拆成了"到底哪个频段拖后腿"这样有明确指向的工程问题。象限不同，优化手段完全不同，甚至互相矛盾——同一个弱覆盖区域，如果是 700M 差而 2.6G 好，加 2.6G 功率是浪费；如果是 2.6G 差而 700M 好，硬抬 2.6G 可能还不如调互操作让用户早点切到 700M。

2.2 覆盖率门限与采样点规则：怎么定义"好"和"差"

四象限的切分不是拍脑袋画个十字，它依赖两个关键参数的设定。第一个是覆盖率门限。云瞰平台在自定义弱覆盖簇规则时，覆盖率门限可以按需设置为 90%、95%、98% 等不同档位。门限设得越高，被判定为"差"的区域簇就越多，问题清单越长；门限设得太低，又会漏掉一批覆盖边缘区。我一般建议先用 95% 做全省基线跑一遍，输出结果后再用 90% 和 98% 各跑一轮做敏感性对比，看哪些簇在门限变化时象限稳定，那些稳定落在同一象限的簇才是真正的重点。

第二个是 MR 采样点规则。不是所有簇都值得分析——如果某个区域簇总共没几个采样点，算出来的覆盖率随机性很大，今天 96%、明天 88% 都有可能，这种簇进了象限也没意义。项目里定的筛选条件是：区域簇 MR 总采样点数大于 100，并且 700M 采样点占该区域的比例在 10% 以上，或者 700M 总采样点大于 30。满足这个条件，才认为该区域簇的 700M 覆盖数据有统计意义，可以进入四象限分类。这两个条件卡掉大量噪音簇，实际操作时不要省。

2.3 四象限的工程含义与方案映射关系

四个象限各自代表一类典型的覆盖病理，优化动作完全不同。象限一，700M 好、2.6G 也好的区域，整体覆盖没问题，但还是会有弱覆盖采样点集中在少数 TOP 小区，属于"锦上添花"类，做邻区重定向、5-5 邻区增补这类无害微调即可。象限二，700M 好、2.6G 差，多出现在城区高层楼宇密集区，2.6G 信号被楼体阻挡，需要优先调整 2.6G 小区的异频/异系统互操作门限，让用户尽快切到覆盖良好的 700M 小区。象限三，两个频段都差，基本是覆盖空洞或深度阻挡，临时手段是把站功率升到满配、抬倾角，长期要看现场增补站点。象限四，700M 差、2.6G 好，是本项目最值得讲的场景——郊区或居民区 700M 站间距偏远、深度覆盖不足，但 2.6G 反而够用，这类区域的重点是发挥 700M 频段优势做波束增强。

这一层的判断逻辑在传统单频段分析里完全看不到。单看整体覆盖率，你可能只会笼统地觉得"这片覆盖不行"，然后去调倾角、加功率，方向都可能搞反。分频段四象限的价值就是先把问题定性，再决定下什么药。

3. 把云瞰平台的簇数据搬进 Python：二维四象限自动分类脚本

3.1 云瞰平台自定义规则导出：门限配置与多边形簇

云瞰平台本身不自带分频段弱覆盖簇的地理化呈现，这是这个项目要突破的第一个点。实际做法是先在云瞰平台上自定义问题规则，把全网区域按固定的覆盖率门限统一切分，导出每个多边形簇的分频段覆盖率数据。自定义规则里最核心的配置参数是 SSB-RSRP（dBm），这是判断弱覆盖的基准信号强度门限，按当地覆盖基线来定。其他辅助门限比如是否结合业务量、是否结合终端类型，可以根据现场需求决定配不配。

导出的数据一般是一张表，每一行是一个多边形簇，字段至少包含簇 ID、700M 覆盖率、2.6G 覆盖率、MR 总采样点数、700M 采样点数这样几列。这一步的关键是保持规则一致：全省所有区域必须用同一套门限去切，否则不同地市导出来的簇粒度不一样，后面合并分析时会出现同一片区域被切成不同大小簇的问题，象限分类就乱了。

3.2 Python 判断问题簇：核心代码与参数逻辑

拿到云瞰导出的簇数据后，问题变成：全网可能有上百个簇，逐个打开看象限分布太慢，而且人眼判断容易漏，必须用脚本自动标记。下面这段是我按照项目逻辑整理的分类代码，基于 pandas 实现，输入一张包含簇级覆盖率与采样点的表格，输出每个簇对应的象限标签。

import pandas as pd # 读取云瞰平台导出的多边形簇数据 # 假设表里已有的列：簇ID、700M覆盖率、2.6G覆盖率、MR总采样点数、700M采样点数 df = pd.read_excel("cloud_kan_clusters.xlsx") # 门限参数 - 可配置区域 cov_threshold = 95 # 覆盖率门限，单位：%，可按 90/95/98 调整 sample_total_th = 100 # MR 总采样点数门限，小于该值视为样本不足 ratio_700m_th = 0.10 # 700M 采样点数占比门限，10% sample_700m_abs_th = 30 # 700M 采样点数绝对门限 # 第一步：过滤掉采样点不足的簇，避免小样本簇的象限误判 df = df.dropna(subset=["700M覆盖率", "2.6G覆盖率", "MR总采样点数", "700M采样点数"]) df = df[df["MR总采样点数"] > sample_total_th] # 第二步：过滤出 700M 数据有统计意义的簇 # 满足 700M 采样点占比 > 10% 或 700M 绝对采样点 > 30 mask_700m = (df["700M采样点数"] / df["MR总采样点数"] > ratio_700m_th) | \ (df["700M采样点数"] > sample_700m_abs_th) df = df[mask_700m].copy() # 第三步：根据覆盖率门限判定各频段好坏 df["700M好"] = df["700M覆盖率"] >= cov_threshold df["2_6G好"] = df["2.6G覆盖率"] >= cov_threshold # 第四步：四象限分类 def mark_quadrant(row): if row["700M好"] and row["2_6G好"]: return "Q1_双好" elif row["700M好"] and not row["2_6G好"]: return "Q2_700M好_2.6G差" elif not row["700M好"] and row["2_6G好"]: return "Q4_700M差_2.6G好" else: return "Q3_双差" df["象限"] = df.apply(mark_quadrant, axis=1) # 输出各象限簇数量统计 print(df["象限"].value_counts()) # 按象限导出清单，供后续优化排期使用 df.to_excel("quadrant_result.xlsx", index=False)

这段代码的逻辑分四步走。第一步先做数据清洗，把缺失字段和样本量不足的簇剔掉，避免脏数据进入分类；第二步专门处理 700M 采样点的问题，因为 700M 终端支持度低，很多区域簇里 700M 采样点稀少，如果不加这个过滤条件，700M 覆盖率会极度不稳定；第三步才真正做象限判定，用同一套覆盖率门限分别给两个频段打上"好/差"标签；第四步通过一个简单的象限映射函数，把布尔组合转成可读的分类标签，并导出 Excel 清单供优化排期使用。

3.3 输出四象限分类：从聚类到落地清单

脚本跑完以后，不要直接拿分类结果去调网。先花十分钟做一次人工抽检：随机抽 5 到 10 个簇，回到云瞰平台上看地图形态，确认这些簇确实和象限标签一致。比如标成"Q4_700M差_2.6G好"的簇，在地图上应该能对应到一片 700M 覆盖偏弱、但 2.6G 信号尚可的居民区或郊区；如果出现簇边界明显横跨两种地形，说明云瞰平台的切簇规则还需要调整，而不是脚本的问题。

在实际项目中，全网 N41（2.6G）和 N28（700M）叠加后涉及上百个簇，脚本的价值就是把"上百个簇逐一观察"压缩成"输出一张带象限标签的 Excel 清单"。接下来优化排期直接按象限分组：Q1 数量通常最少，只挑 TOP 弱覆盖小区；Q2 和 Q4 是主要工作量来源；Q3 由于需要协调增站资源，往往要单独立项。这个排序在项目里直接决定了分批次实施的节奏。

4. 四类象限的优化落地：互操作门限、功率挖潜与 700M 双波束增强

4.1 象限一与象限二：微调 TOP 小区与异频/异系统互操作参数

象限一属于覆盖底子好的区域，不要做激进动作。正确姿势是提取该象限簇内弱覆盖采样点，筛出弱覆盖采样点 TOP 小区，对这几个小区做"无害微调"——把 TOP 弱覆盖小区的最强邻区重定向打开，补 5-5 邻区，必要时微调下倾角。这个象限的目标不是大幅提升覆盖率，而是把漏网的弱覆盖采样点压下去，让本来就不错的区域"好上加好"，避免因为个别小区拖累整体指标。

象限二的优化重点在互操作参数。这种场景集中在城区高层楼宇密集区，2.6G 信号被阻挡后应该尽快让用户切到覆盖良好的 700M 或 4G 小区。项目的做法是调整异频/异系统互操作门限：降低 2.6G 小区的启测门限，让弱场用户更早触发测量、更快完成切换。具体门限配置如下表所示。

这些门限的作用是给 2.6G 小区划定一个"放手区间"：信号低于某个阈值后不再硬扛，主动把用户交给更好的可用网络。A1/A2 门限控制的是测量触发时机，B2 门限控制的是切换执行条件，两者配合才能既保证及时切换，又不至于频繁乒乓。参数配置上我习惯分两步走：先把 A2 从默认值下调 3 到 5 个 dB 试一批簇，观察弱覆盖采样点和切换成功率，再决定要不要动 B2 门限；一次全动容易把切换指标搞坏，翻车了很难定位是哪条参数的问题。

4.2 象限三：功率应升尽升与 AAU 功率挖潜

象限三是两个频段都差的硬骨头，多数是覆盖空洞或楼宇阻挡造成的深度覆盖不足，单靠参数调整很难根治。项目的临时优化手段是"功率应升尽升"：把该区域内所有可升功率站点升到满配，对小区倾角做抬升操作，扩大覆盖半径，先把 MR 覆盖率拉起来，长期方案则通过现场勘察增补站点。象限三的坑在于，很多站点名义上显示"已满配"，实际还有功率余量，尤其是原来 45G 共 AAU 的站点，在 4G 退网后释放出来的功率没有被 5G 完全继承。

项目里通过筛选潜在功率余量小区和已退网 45G 共 AAU 站点，一共找出 474 个可提升功率的小区，覆盖场景大部分是低层和高层居民区。对比调整前后三天数据，该批次小区覆盖率从 97.49% 提升到 97.82%，功率挖潜的部分整体提升 0.32%。要注意的是，功率抬升不是越高越好——抬升后如果出现越区覆盖或干扰抬升，反而会影响邻区指标。所以功率类操作必须配合 KPI 监控，至少观察切换成功率、上行干扰电平有没有恶化。

4.3 象限四：700M 双波束 SCENARIO_201 的容量与覆盖权衡

象限四是整个项目里最值得展开的部分：700M 差、2.6G 好，典型场景是郊区 700M 站间距偏远，或者居民区 700M 深度覆盖不足。面对这类区域，常规思路是加站或调整天馈，但成本高、周期长。项目采用的做法是 700M 双波束覆盖增强：现网 700M 小区全部使用默认覆盖场景 DEFAULT，对应 SSB 波束个数为 1；而现网 700M 小区都是 4T4R 设备，支持另一种立体覆盖场景 SCENARIO_201，对应 SSB 波束个数为 2，覆盖能力相比单波束有显著提升。

双波束不是白拿的，代价是小区容量降低，因为两个波束会占用更多资源。所以这个功能不能全网批量开，必须挑场景——项目里选的是连片的居民区、郊区等深度覆盖不足的弱覆盖簇做试点。试点区域实施后，问题区域整体 700M 下行弱覆盖 MR 比例从 4.94% 改善到 4.61%，云瞰覆盖率提升 0.33%，效果明显。选择 SCENARIO_201 前要核对设备类型，只有 700M-4TR 小区才支持该场景；4TR 以下设备强行配置会造成波束配置失败，这是配置时最容易踩的坑。

4.4 分批次实施节奏：300 个小区一批的工程化经验

全量问题簇一次性调整，风险很大——一旦某个门限参数配错，影响面会迅速扩散，反向定位时连是哪个批次引入的问题都说不清。项目的做法是分批次分区县实施：前期先聚焦 TOP 问题小区，以 300 个小区为一个批次进行调整，观察调整后各项指标稳定了，再扩大到全量问题簇小区。这里的"指标稳定"不光看云瞰覆盖率，还要看切换成功率、无线掉线率、上下行干扰等常规 KPI，至少要观察一个完整业务周期。

另一个工程化细节是农村乡镇场景的处理。这类场景 2.6G 站点数量少，700M 终端支持度也低，用户实际占用的是距离较远的 2.6G 站点，导致 5G 云瞰覆盖和驻留比都很差。项目用 Python 工具做了全域采样点和终端支持度的协同分析，识别出 36 个问题点，最终通过增补 2.6G 站点解决。这说明四象限方法并不是万能的——当某个频段的终端支持度本身很低时，单纯优化覆盖动作可能不如补站来得直接，这时候要把"终端支持度"作为一个额外的分析维度纳入考虑。

5. 分频段弱覆盖簇识别避坑指南：覆盖率门限、采样点与波束配置的五个教训

5.1 坑 1：MR 采样点总数过小导致象限误判

现象：某个簇今天测是 700M 差、2.6G 好，明天再看变成了两个频段都好，象限标签反复横跳，优化排期跟着乱套。原因：该簇 MR 总采样点数只有几十个，700M 采样点更是只有个位数，覆盖率算出来完全是随机波动。解决：一律按"MR 总采样点大于 100、700M 采样点占比大于 10% 或 700M 绝对采样点大于 30"的规则先过滤，不满足条件的簇直接丢弃，不参与象限分类。宁可少分析几个簇，也不能让随机噪声污染决策。

5.2 坑 2：覆盖率门限随意改导致问题簇数量爆炸

现象：门限从 95% 改成 98% 后，问题簇数量翻了一倍，优化资源根本铺不开。原因：98% 门限把大量"整体覆盖尚可、只有零星弱覆盖采样点"的区域也判定成了差象限，这类区域其实只需要微调，不需要投入重资源。解决：门限按区域用途区分，城区和乡镇不要共用同一套标准；另外用 90% 和 98% 各跑一遍敏感性分析，只挑那些在门限变化下象限保持稳定的簇列入重点优化。门限不是越低越省事，适合场景才是关键。

5.3 坑 3：700M 波束增强后只顾覆盖不看容量损失

现象：给一片居民区开了 SCENARIO_201 双波束后，700M 弱覆盖 MR 比例确实降了，但用户反馈下载速率明显变慢。原因：双波束提升了覆盖的同时占用了更多资源，小区容量被压缩，对业务量大的区域影响明显。解决：波束增强只用于覆盖是主要矛盾的区域，比如低业务量的郊区、居民区；如果该小区忙时 PRB 利用率已经偏高，就不要开双波束，改用互操作参数或现场补点。每开一个双波束小区，都要做容量和覆盖的权衡评估，这是 700M 频段优化最容易忽略的一环。

5.4 坑 4：功率抬升漏掉已退网的 45G 共 AAU 站点

现象：功率应升尽升筛选完，一批小区覆盖率没有明显变化，复查发现大量 45G 共 AAU 站点根本不在清单里。原因：这些站点在 4G 退网后释放了功率余量，但网管上 5G 侧功率配置没有同步更新，常规漏检根本发现不了。解决：筛选功率余量小区时，单独拉一份已退网 45G 共 AAU 的站点清单，逐个核对 5G 侧功率配置；同时在脚本里增加一个标记字段，把这部分站点单独归为一类，方便后续跟踪功率挖潜效果。功率余量这事，靠人工翻配置太慢，用脚本批量对比才是正道。

5.5 坑 5：Python 脚本没处理簇字段缺失和脏数据

现象：脚本跑一半报 KeyError，检查发现云瞰导出的表里部分簇的 700M 覆盖率字段是空的，或者采样点列里有非数字字符。原因：云瞰平台自定义规则导出的数据不是标准格式，某些簇因为覆盖面积太小没有 MR 数据落点，字段直接留空。解决：脚本里第一步就用 dropna 丢弃缺失行，同时把覆盖率列强制转为数值类型，转换失败的行也过滤掉；另外导出文件可能有多个 sheet，读取时显式指定 sheet 名，避免 pandas 默认读错位置。数据清洗会占掉整个脚本一多半的代码量，这不是浪费，是给自己省排查时间。

6. 效果验证与复盘：用调整前后三天 MR 数据判断方案是否真的有效

6.1 覆盖率对比的统计口径

方案实施后做效果评估，最忌讳的是拿一天数据对比另一天数据——无线环境每天都在变，单日波动很容易掩盖真实提升。项目里的做法是取调整前三天和调整后三天的 MR 数据做对比，两个时间窗口的统计口径完全一致：都用云瞰平台导出的同一套覆盖率指标，都用同一个 MR 采样点过滤条件。我自己复盘时还会额外看两个指标：700M 下行弱覆盖 MR 比例，以及分象限的问题簇数量变化。覆盖率是结果指标，弱覆盖 MR 比例是过程指标，两者同时改善才能证明优化动作真的起到了作用。

以象限三为例，功率挖潜批次调整前后三天对比，小区覆盖率从 97.49% 改善到 97.82%，提升 0.32%，这个幅度单独看不大，但考虑到该批次有 474 个小区、覆盖场景以居民区为主，能从功率余量里挖出这个提升，投入产出比是划算的。象限四的波束增强验证则看 700M 下行弱覆盖 MR 比例，从 4.94% 改善到 4.61%，0.33% 的降幅说明双波束确实补上了深度覆盖短板。验证时要分象限统计，不要把所有簇混在一起看总量——混在一起会掩盖"某个象限有效、另一个象限无效"的真相。

6.2 从 98.2% 到 98.74%：一次完整的四象限复盘

这套机制跑完后，全网云瞰覆盖率从 98.2% 左右提升到 98.74% 左右，0.48% 的提升幅度在接近 98% 基线的水平上已经相当可观，而且是在没有大规模 RF 天馈整改和室分改造的前提下实现的。复盘时值得记下来的几点：第一，方案是分批次分区县实施的，前期 300 个小区一批次，确认稳定后才铺开全量，这保证了每一步的收益和风险都可控；第二，互操作参数、功率抬升、波束增强三类手段叠加后会有交互效应——比如某簇同时做了互操作门限调整和功率抬升，最后看覆盖率提升很难分清是哪一项的功劳，所以批次内尽量保持单一变量，不要在一个批次里同时改互相干扰的参数；第三，农村乡镇场景暴露了终端支持度这个约束，2.6G 站点少、700M 终端支持度低时，四象限分析会失真，必须用 Python 把采样点和终端支持度协同分析补进去。

从那以后，我每次拿到云瞰平台的簇数据，都会强制走一遍这条流程：先定门限和采样点过滤规则，再跑四象限分类脚本，然后按象限分批实施、分象限验证，最后用前后三天数据说话。这套方法不一定适合所有地市，但把"分频段弱覆盖簇识别"从人工逐个点开的低效劳动变成可复制的标准化动作，这个思路本身是通用的。希望帮到你，少走几个我踩过的坑。

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