5G KPI体系与簇优化实战：计数器、门限与驻留比

简介：《爱立信5G-KPI体系介绍》面向5G网络优化工程师、运营商技术人员及希望系统理解KPI评估方法的学习者，围绕5G网络性能监测与持续优化，梳理从单站健康检查到全网优化的指标框架。资源共1个pptx文件，压缩包约450KB，以演示文稿形式组织，便于按章节浏览与汇报复用。内容涵盖接入性、保持性、移动性、完整性等维度，区分路测KPI与网络统计KPI，并展开单站验证、15至40站规模的簇优化及全网优化的关注重点；同时梳理NR NSA、NR SA与LTE网络的统计指标体系，包含切换成功率、业务量、用户数、PRB利用率、干扰、时延与小区完好率等。对不同发展期NR终端的关注指标、5G覆盖优化目标值及5G驻留时长占比等覆盖考察参数也有涉及，可帮助读者对照路测与网管数据定位覆盖、接入、切换及速率问题，作为指标口径核对与优化分析的参考。已有143人学习。

1. 一张簇优化复测表里的三个数字：这套 5G KPI 体系管的是什么

前阵子跟一个地市的簇优化复测，验收表上压着三行硬指标：NR 数据业务掉线率 ≤1.5%、NR 切换成功率 ≥98%、SS-RSRP≥-100dBm 且 SS-SINR≥0dB 的采样点占比 ≥90%。现场第一版复测，覆盖率 93% 过了，掉线率 2.1%、切换成功率 96.4% 都没过。有人提议抬功率，覆盖还能再好看一点，但抬完之后掉线率大概率更难看——因为这仨指标背后是同一张网，不是三个独立作业。

这套 5G KPI 体系干的事，就是把“路测看到的”和“网管统计到的”对齐到同一套口径上：单站验证看基站入网前健不健康，簇优化看 15~40 个站连片之后 RF 和异常事件干不干净，全网优化再把路测指标和话统指标交叉起来看。它适合两类人：一类是做单站、簇、全网三级优化的网优工程师，另一类是要把这套计数器做成自动化报表、看板和告警的开发。计数器统一以 pm 前缀命名，接入、保持、完整、移动、业务量、无线质量、可用性七类指标基本能覆盖日常 80% 的取数需求。

2. 三段式落地：单站验证、15~40 站簇优化与全网优化的分工

三级优化的边界如果划不清楚，最容易出现的情况是：单站阶段漏掉的问题，到簇优化被当成 RF 问题反复调天馈；簇优化没收敛的异常事件，到全网优化变成“偶发掉线”查不动。这套体系把三级的目标拆得比较硬，下面按实际作业顺序展开。

2.1 单站健康检查先看哪四项

单站验证是基站入网前的门槛测试，目的是确认这个站自己没毛病，别把设备问题带进簇里。实际作业里我不会一上来就跑全业务，先按四项过一遍，任何一项不过就退回整改，不进入下一步。

这四项的顺序有讲究。先看告警，是因为驻波比异常会让后面所有速率测试都白做；再看接入，是因为接入不稳定的站，速率采样本身就不具备代表性；移动性放最后，是因为单站阶段邻区还没全开，只能验证“能不能切”，切得好不好要留到簇优化。

这里有个容易被忽略的点：单站验证阶段采集的速率是“净速率”，要在空载或轻载下测。曾经有站点在晚忙时抽测，下行只跑到 200Mbps，一度怀疑是通道故障，后来换到凌晨复测直接到 800Mbps。忙时数据不是不能用，但它衡量的是“网络当前能给多少”，不是“这个站本身能跑多少”，两个结论别混。

2.2 簇优化为什么以 15~40 个基站为界

簇的规模定在 15~40 个站，不是拍脑袋。站太少，天馈下倾角一动，覆盖外溢到簇外，你在簇内看到的改善可能是把干扰推给了隔壁簇；站太多，一次 RF 调整的复测周期拉长，问题定位的因果链就断了。15~40 这个区间大致对应一个中等规模城区的连片覆盖，既能形成完整的切换链，又能在两三天内完成一轮 DT 复测。

簇优化阶段的核心动作是 RF 优化加异常事件清理，顺序上我一般这么走：

1. 簇划分与边界确认：按地理连片和切换关系划簇，明确簇边界小区，边界小区只做保守调整。
2. 基础数据核查：PCI、PRACH 根序列、TAC、邻区关系，这四项在路测前必须过一遍，否则路测数据里一半的“切换失败”都是配置问题。
3. DT/CQT 采集：主干道、网格道路、重点室内入口各跑一遍，车速和路线固定，保证两轮复测可比。
4. RF 优化：下倾角、方位角、RS 功率三件套，每次只动一个维度，动完立刻小范围复测。
5. 异常事件处理：掉话、切换失败、接入失败、NR 辅节点添加失败逐条回溯信令。
6. 簇内复测与收敛判定：覆盖率、掉线率、切换成功率三项同时达标才算收敛。

RF 调整这块有个血泪经验：下倾角和功率不要同时动。两个变量一起改，覆盖上去了你分不清是哪个起的作用，下一轮出问题也找不到回退点。我一般先把机械下倾角调到位，再考虑 RS 功率微调，每一步留一次复测记录。

异常事件里，NSA 组网下 NR 辅节点添加失败是最容易被低估的一类。它不表现为掉线，用户侧感知是“网还在，但速率掉到 LTE 水平”。如果只看掉线率和切换成功率，这类问题会整片漏过去，所以簇优化阶段必须单独统计辅节点添加成功率。

2.3 全网优化的双指标：路测与话统怎么交叉验证

全网优化建立在簇优化收敛的基础上，测试范围从单簇扩到全城，指标体系也从单一的路测扩展成“路测 KPI + 网管性能指标”双轨。这两套数据各有盲区：路测采样点有限，覆盖不到室内和偏远路段；话统覆盖全量用户，但口径受计数器定义和用户行为影响。交叉验证的价值就在补盲。

一个典型的交叉场景：话统显示某片区 NR 掉线率偏高，但路测在该片区跑了三轮都正常。这时候不要急着怀疑话统，先拆维度——按时间段拆，看是不是集中在忙时；按终端类型拆，看是不是集中在某几款终端；按小区拆，看是不是集中在某几个站的边缘。我遇到过的一次是掉线集中在两个相邻小区的重叠区，路测路线刚好从重叠区正中穿过没触发，换成沿边线走立刻复现，最后是切换参数偏保守导致的晚切换。

反过来也成立：路测发现某段路速率上不去，话统看该小区 PRB 利用率长期低于 20%，说明不是容量问题，而是覆盖或干扰问题，这时候再看 RANK 分布和编码方式比例，基本能定位到是单流为主还是高阶调制用不上。

交叉验证的落地形式是一张对照表，左边路测指标，右边对应的话统计数器，中间写清楚两者的统计周期和采样口径。这张表建一次，后面每次全网优化都能复用。

3. NR 统计指标拆解：接入性、保持性、完整性、移动性怎么落到计数器

指标体系如果只记名字，用的时候一定乱。真正要落的是“这一类指标在 NSA 和 SA 下分别对应哪个计数器、分母是什么、什么情况下会失真”。下面按类别拆，最后给一段能直接跑的计算脚本。

3.1 NSA 与 SA 的指标继承关系

NSA 和 SA 的指标不是两套独立的体系，而是继承加扩展的关系。NSA 下用户同时挂在 LTE 锚点和 NR 辅节点上，所以指标天然分成三层：LTE 层、NR Leg 层、端到端层。

这张表里最关键的一列是“LTE 对应指标”。NSA 阶段很多 NR 问题会先在 LTE 侧露出苗头，比如 LTE 锚点掉线率突然抬升，往下挖往往是 NR 辅节点释放异常把锚点带崩了。反过来，NR Leg 建立失败在用户侧感知不到接入性下降，但会实打实影响速率和时延——这是这套体系里专门标注过的一点，做 KPI 看板时不能把它和“接入失败”混成一个告警等级。

SA 阶段少了 LTE 锚点这层，指标链变短，但新增了会话建立和 NG 接口相关的维度。从 NSA 迁到 SA 的时候，原有的话统报表不能直接平移，接入性和保持性的分母都要重算，这一点后面避坑章节会展开。

3.2 发展期到成熟期：指标重点怎么迁移

同一张网在不同建设阶段，该盯的指标是不一样的。这套体系把 NR 终端相关指标按“发展期（NR 不连续）→ 成熟期 NSA（NR 连续）→ 成熟期 SA（NR 连续）”划了三段，重点迁移大致是这样：

读这张表的正确姿势是看“哪些指标从支路级升到了用户级”。发展期 NR 覆盖不连续，用户经常在 NR 和 LTE 之间来回，这时候盯支路级指标是为了保证“能加上、别掉太快”；到了成熟期 NR 连续覆盖，支路级指标的波动被覆盖连续性吸收，用户级指标才有考核意义。如果阶段判断错了，会出现两种典型误判：发展期拿用户级速率考核，全网都在及格线附近晃；成熟期还盯着支路建立成功率，把已经不影响感知的偶发失败当成重大问题追。

3.3 用计数器还原 KPI：一份可跑的计算脚本

网管导出的原始计数器是裸数字，要变成能看的 KPI 得做一层换算。这套体系里给出的换算式不复杂，麻烦的是分母口径和异常值处理。下面这段脚本处理一个小时粒度的计数器 CSV，输出小区级 KPI。

# 从网管导出的 pm 计数器 CSV 计算小区级 KPI # 输入列名与网管导出口径保持一致，缺失值按 0 处理 import csv def div(a, b): """安全除法：分母为 0 时返回 None，避免把无采样小区算成 0%""" return a / b if b else None with open("pm_counters_hourly.csv", newline="", encoding="utf-8") as f: reader = csv.DictReader(f) for r in reader: cell = r["cell_id"] # 接入类：ENDC 建立成功率 att = float(r.get("pmEndcSetupUeAtt") or 0) succ = float(r.get("pmEndcSetupUeSucc") or 0) endc_sr = div(succ, att) # 完整性：小区内用户下行平均速率，64 为该体系给出的换算系数 vol_dl = float(r.get("pmMacVolDlDrb") or 0) # MAC 层下行数据量 time_dl = float(r.get("pmMacTimeDlDrb") or 0) # DRB 有效调度时长 dl_thp = div(64 * vol_dl, time_dl) # 无线质量：下行双流占比，Rank 分布四个桶求和做分母 r0 = float(r.get("pmRadioUeRepRankDistr_0") or 0) r1 = float(r.get("pmRadioUeRepRankDistr_1") or 0) r2 = float(r.get("pmRadioUeRepRankDistr_2") or 0) r3 = float(r.get("pmRadioUeRepRankDistr_3") or 0) rank_total = r0 + r1 + r2 + r3 rank2_ratio = div(r1, rank_total) # 业务量：上下行总流量换算成 GB vol_ul = float(r.get("pmMacVolUl") or 0) total_gb = (vol_ul + vol_dl) / 8 / 1024 / 1024 / 1024 print(f"{cell},ENDC_SR={endc_sr},DL_THP={dl_thp}," f"RANK2={rank2_ratio},TRAFFIC_GB={total_gb:.3f}")

逻辑上分四步：先把计数器读成浮点并兜住空值，再按类别套换算式，然后对分母为 0 的小时做 None 处理，最后统一输出。参数上有三处要按现网口径确认：64是这套体系里给出的 MAC 层换算系数，不同计数器手册可能有差异，上线前必须拿一个已知小区对一遍；pmMacTimeDlDrb是有效调度时长而不是统计周期，用统计周期当分母会把速率算低一个量级；Rank 分布的四个桶在部分版本里还会多出_4及以上的桶，如果直接按四桶求和，分母会偏小、双流占比虚高。

脚本跑通只是第一步，真正花时间的是把输出和路测数据对上。我一般会挑三个典型小区——一个近点、一个中远点、一个高负荷——拿脚本结果和现场实测速率比对，偏差在 10% 以内才认为口径可信。

4. 覆盖与速率门限取值：SS-RSRP/SS-SINR 与 2.5ms 双周期速率达标率

KPI 体系里最容易被“套错”的不是计数器，是门限。同一张表上的-88dBm和-100dBm看起来只是数字差异，背后是两套完全不同的考核口径。

4.1 覆盖门限：-88dBm 与 3dB 的来历

这套体系在 NSA 建设初期给出的覆盖目标大致是两条线：一条是“好覆盖”口径，SS-RSRP > -88dBm 的比例大于 90%、SS-SINR > 3dB 的比例大于 90%；另一条是“有效覆盖”口径，SS-RSRP ≥ -100dBm 且 SS-SINR ≥ 0dB 的数据点占比 ≥90%。前一条用于网络质量评估和规划，后一条用于工程验收。

两条线并存的理由是：RSRP 达标不代表能用。SS-RSRP 到 -95dBm 但 SS-SINR 只有 -2dB 的点，信号是有的，解调质量不够，速率上不去还容易掉线。所以有效覆盖必须把 SINR 拉进来做与条件，单看 RSRP 的覆盖率在干扰重的片区会虚高。

实际取值上，不同客户分支会有差异。有的客户把好覆盖线定在 -88dBm，有的放宽到 -90dBm；速率目标也是分档的，NSA 下行 500Mbps、SA 下行 500Mbps、上行 NSA 50Mbps、SA 80Mbps 是这套体系里的参考值，落到具体项目要按频段带宽和终端能力分布再核一遍。带宽 100MHz 和 60MHz 跑同一个速率目标，后者基本没戏。

4.2 速率达标率：为什么要限定 2.5ms 双周期

速率类指标在验收表里通常有三行：单用户下行速率达标率（PDCP 层速率 ≥100Mbps 的样点占比 ≥90%）、单用户下行平均速率（≥420Mbps）、单用户上行平均速率（≥60Mbps）。括号里那句“2.5ms 双周期”经常被抄漏，但它是口径的一部分。

EN-DC 下 PDCP 层聚合了 LTE 和 NR 两条腿的速率，采样周期直接影响峰值捕获能力。采样间隔太长，瞬时调度间隙会被平滑掉，平均速率看起来稳但达标率算不准；采样太密，信令开销和落盘量又扛不住。2.5ms 双周期是这套体系给出的折中口径，测试仪表和路测软件按这个周期采集，不同项目之间的数据才有可比性。我见过一次验收争议，两边数据差 8%，最后查出来是一边用了 1ms 采样、一边用了 10ms，同一段路测出来的达标率天然不同。

达标率的分子是“速率 ≥100Mbps 的样点”，不是“平均速率 ≥100Mbps”。这两个算法在好点和差点混杂的路段上结果能差 20 个百分点。做自动化统计时，一定要按样点逐条判定再求占比，不能先平均再判定。

# 按样点判定速率达标率，避免“先平均后判定”的口径错误 import csv THP_THRESHOLD = 100.0 # 下行达标门限，单位 Mbps，按项目合同调整 total, hit = 0, 0 with open("dt_samples.csv", newline="", encoding="utf-8") as f: for s in csv.DictReader(f): # pdcp_thp_dl 为每个采样点的 PDCP 层下行速率 thp = float(s["pdcp_thp_dl"]) total += 1 if thp >= THP_THRESHOLD: hit += 1 print(f"采样点 {total}，达标 {hit}，达标率 {hit / total:.2%}" if total else "无有效采样")

这段脚本的重点不在代码本身，而在THP_THRESHOLD这个参数必须来自合同而不是默认值，以及total只统计有效采样点——路测中断、GPS 丢失期间的样点要剔除，否则分母虚大、达标率被拉低。

4.3 门限按本地客户调整的三条原则

参考门限不能直接当验收门限用，调整时我守三条：

一是按合同优先。客户合同里写死的数字就是唯一标准，体系里的参考值只用来判断合同是否合理。曾经有项目拿体系参考值去质疑合同门限偏低，最后还是要按合同执行。

二是按频段和带宽折算。同样的覆盖门限，3.5GHz 和 2.6GHz 的传播特性不同，700MHz 更不用说。速率门限要按带宽线性折算后再留 10%~15% 余量，不要拿 100MHz 的目标去卡 60MHz 的小区。

三是按终端能力分布校准。现网如果还有大量不支持高阶调制或双流的终端，速率达标率会被终端能力拖住，这时候要么在统计时按终端能力分层，要么在验收口径里明确终端类型。混在一起算，最后一定是互相扯皮。

5. 避坑排查：计数器口径、门限套用与驻留比统计的五个翻车点

5.1 分母取错导致成功率虚高

现象：某片区 ENDC 建立成功率连续一周 99.8%，现场测试却频繁出现辅节点加不上。

原因：统计时用了 gNB 侧的pmEndcSetupUeSucc/pmEndcSetupUeAtt，但该口径只统计已经到达 gNB 的请求，LTE 侧发起但因锚点问题没送到 gNB 的尝试根本没进分母。

解决：eNB 侧和 gNB 侧两个口径同时出报表，取较小值作为对外口径；两侧差值超过 1 个百分点就触发锚点侧排查。

5.2 把 NSA 的建立成功率当成 SA 接入成功率

现象：NSA 迁 SA 之后，接入类指标看着还行，用户投诉却集中在“打不开页面”。

原因：报表沿用了 NSA 的 ENDC 建立成功率，SA 下的会话建立成功率没接进来，两套分母完全不同，前者是辅节点添加尝试，后者是会话请求。

解决：迁移时按类别逐项核对分母定义，接入性至少要有 RRC 建立、会话建立、NG 接口三个维度；旧报表不要直接改标题复用。

5.3 路测采样点混入弱覆盖导致速率不达标

现象：某路段平均速率只有 380Mbps，复测三次都过不了 420Mbps 的线。

原因：路测路线包含一段地下通道入口，SS-RSRP 掉到 -115dBm，几十个样点把整段平均值拉下来了。

解决：速率类指标按覆盖区间分层统计，弱覆盖样点单独出报告；验收路线在测试前由双方确认，中途不临时加测点。

5.4 驻留比统计把“有覆盖未驻留”算成“无覆盖”

现象：5G 驻留比只有 62%，但覆盖率报表显示 5G 覆盖 95%。

原因：驻留比分母把“5G 终端在 5G 覆盖区内的总时长”和“全量时长”混用了，导致有覆盖但驻留在 LTE 的时段被算成无覆盖。

解决：分母严格限定为“5G 终端且处于 5G 覆盖区内”的时长，分子为其中驻留 NR 的时长；同时单独输出高倒流小区清单，区分“覆盖不足”和“有覆盖不驻留”。

5.5 SN 变更时延的统计边界没对齐

现象：SN 变更控制面时延统计出来 35ms，超过 20ms 的门限，但信令跟踪看单次变更都在 15ms 以内。

原因：统计时把“UE 收到 RRC Connection Reconfiguration”到“向目标小区发送 Reconfiguration Complete”整段都算进去了，中间夹了一次不相关的测量上报等待。

解决：严格按体系定义起止点取时间戳，控制面只算信令往返，用户面按 PDCP 序号取首末包，两段分开统计；采样时剔除因无线质量触发的重传等待。

6. 5G 驻留比优化：高倒流小区定位、锚点策略与终端能力分层

驻留比是这套体系里少数几个“路测测不出来、只能靠话统和软采”的指标，也是实际优化里最容易被做成数字游戏的指标。它的定义不复杂：5G 驻留时长占 5G 终端在 5G 覆盖区内总时长的比例。难的是把“覆盖区”和“驻留”两个口径同时对平。

6.1 高倒流小区的三级定位

第一级看面：按网格统计驻留比，找出低于目标值的网格。第二级看线：在网格内按小区统计倒流时长，排出 TOP 小区。第三级看点：对 TOP 小区做 MR 或软采回溯，看倒流发生在小区边缘还是小区内部。边缘倒流多半是覆盖或切换参数问题，内部倒流往往是锚点优先级、频点配置或终端设置问题。

-- 按小区统计 5G 终端驻留比，分母限定在 5G 覆盖区内 SELECT cell_id, SUM(CASE WHEN rat_type = 'NR' THEN duration_sec ELSE 0 END) AS nr_sec, SUM(duration_sec) AS covered_sec, SUM(CASE WHEN rat_type = 'NR' THEN duration_sec ELSE 0 END) / NULLIF(SUM(duration_sec), 0) AS dwell_ratio FROM ue_rat_trace WHERE is_5g_capable = 1 -- 只统计 5G 终端 AND in_nr_coverage = 1 -- 只统计处于 5G 覆盖区内的时段 GROUP BY cell_id ORDER BY dwell_ratio ASC;

这段 SQL 的两个 WHERE 条件就是口径本身，去掉任何一个，算出来的都不是驻留比。in_nr_coverage一般由 MR 或路测覆盖栅格匹配得到，匹配精度直接决定结果可信度。

6.2 锚点优先驻留与邻区配置

NSA 下提升驻留比最直接的两个抓手是锚点优先接入和邻区规划。锚点侧要保证 LTE 锚点频点优先级高于普通 LTE 频点，让 5G 终端优先 camp 在锚点上；NR 侧要保证辅载波添加门限和删除门限之间留够迟滞，避免在覆盖边缘反复添加删除。邻区这块，锚点邻区和 NR 邻区要分别规划，漏配一条 NR 邻区，对应方向的倒流就会集中出现。

6.3 终端能力分层与引导策略

统计 5G 终端能力分布是驻留比优化的前置动作。持有 5G 终端但长期驻留 4G 的用户，一部分是终端设置问题（比如开了省电模式、关了 5G 开关），一部分是套餐或签约问题。前者靠客服引导和设置提示，后者要靠套餐侧配合。另外还有一批高流量但用 4G 终端的用户，属于潜在发展对象，不能算进驻留比分母里，否则指标永远做不上去。

从那以后我每次做驻留比专项，都强制先跑一遍终端能力分层，再跑小区级倒流排名，最后才动参数。顺序反了，改完参数指标涨了两个点，过一周又掉回去，连是终端换机还是参数回退都分不清。希望这套拆法能帮到你。

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