5G KPI体系详解：从单站验证到全网优化的指标与避坑指南

简介：围绕爱立信5G网络KPI体系整理的演示文稿，面向无线网络优化工程师、5G规划建设人员及需要理解KPI counter口径的学习者，用于梳理从单站到全网的性能评估框架。内容把KPI优化置于网络优化流程中，区分路测KPI与网络统计KPI，并说明单站验证、15至40站规模的簇优化和全网优化各自关注的指标与测试范围。演示稿还按NR NSA、NR SA及LTE接入维度组织接入性、保持性、移动性、完整性、业务量、PRB利用率、干扰、无线质量和用户面时延等统计项，补充发展期、成熟期NSA/SA终端关注重点，以及覆盖优化中的SS-RSRP/SS-SINR比例、上下行速率、切换与掉线、PING时延、5G驻留时长占比等验收指标。资源包共1个pptx文件，约450KB，结构紧凑，适合培训宣讲、指标口径对照和优化复盘时查阅。已有143人学习。

1. 5G KPI到底是什么：把网络体检报告读成一句人话

去医院体检，报告单上密密麻麻写着血压、血脂、血糖，每个数值后面还跟着一个参考区间。医生不会因为你某一项超了就直接下结论，而是把几项凑在一起看，判断整体状态。5G KPI扮演的就是这份体检报告的角色——它把一张看不见、摸不着的无线网络，翻译成一串能对比、能定位、能改进的数字。通俗地说，5G KPI 就是衡量 5G 网络"好不好用"的一组关键性能指标（Key Performance Indicators），覆盖接入、保持、完整性、移动性、业务量等几个维度。它的价值在于：把"用户觉得卡"这种模糊抱怨，变成"某小区下行平均速率掉到 200Mbps、SS-SINR 达标率不足 80%"这样能直接下手的问题。搞懂这套体系，你才知道网络优化到底在优化什么。

2. 为什么需要一套KPI体系：从单站验证到全网优化的三段式

网络优化最容易犯的错，是把整张网当成一个整体去调。几千个基站同时开动，参数一改一大片，最后指标没上去，连问题出在哪个站都说不清。KPI 体系存在的第一个理由，就是把优化拆成有先后顺序的三段：单站验证、簇优化、全网优化。每一段有独立的指标口径和判定标准，前一段不通过，后一段的数据就没有参考价值。

打个比方，这就像装修房子：先逐个检查每盏灯亮不亮（单站验证），再把一个房间的线路整体调一遍（簇优化），最后才是全屋验收（全网优化）。跳过任何一步，后面都会返工。

2.1 单站验证：基站入网前的"体检"

单站验证发生在基站正式入网之前，目的很单纯：保证这一个站的性能是正常的。检查项包括单站健康检查、单站建设完整性，以及接入性、保持性、移动性、完整性、业务量这几类基础指标。

为什么非要单独做这一步？因为一个"带病上岗"的基站会污染整网数据。比如某个站的驻波比异常、天馈接反、邻区漏配，它自己可能还能勉强工作，但在簇优化阶段，你会看到周边小区的切换成功率莫名其妙地掉，最后排查半天发现根子在它身上。血泪经验往往就是这么攒出来的：一个站的参数配错，能让一整个簇的指标看起来都像"玄学"。

单站验证的判定逻辑是"合格/不合格"，不是"好/更好"。它只回答一个问题：这个站的各项能力是否达到设计预期。合格了才允许进入下一阶段，不合格就退回去整改。

2.2 簇优化：15~40个基站为一组的"小考"

单站全部合格之后，把地理位置相邻的 15~40 个基站组成一个簇，做簇级优化。这一阶段主要依靠路测，做两件事：RF（射频）优化和异常事件优化。

RF 优化解决的是覆盖问题——天线方位角、下倾角、功率配置，目标是让信号在该有覆盖的地方有覆盖，在不该越界的地方别乱飘。异常事件优化解决的是流程问题——掉线、切换失败、接入失败这类事件，通过路测信令回溯定位到具体原因。

簇优化之所以要"成簇"而不是"成站"，是因为移动性指标天生是站与站之间的关系。切换成功率、掉线率这些指标，单看一个站没有意义，必须看它和邻居之间的配合。一个簇内的基站互相是邻居，把它们打包评估，才能看出真实的移动性表现。

提示：簇的划分不是随机的，通常沿地理边界和话务边界切分，避免把密集城区和郊县强行塞进同一个簇，否则指标会被平均得看不出问题。

2.3 全网优化：路测与话统双线并行

簇优化全部达标后，进入全网优化。测试范围从一个簇扩大到整张网络，关注点也从"只看路测"变成"路测指标和网管性能指标同时看"。

这一步的区别很关键。路测是抽样，跑的是几条固定路线，样本量有限但能反映真实用户感知；网管性能指标（也就是话统）是全量统计，覆盖所有小区所有时段，但它是网络侧自己记的账，和用户实际体验之间可能有偏差。两者必须互相印证：路测发现某段路速率低，就去话统里查对应小区在那个时段有没有拥塞、有没有干扰；话统显示某小区掉线率高，就去路测里看是不是特定路段、特定终端才复现。

三个阶段的对比如下：

看懂这张表，就明白为什么很多优化工作会翻车：明明是在做全网优化，用的却是单站验证的思路，一个站一个站地抠，抠完发现整网指标没动——因为问题本来就在站与站之间。

3. 五大指标类别：接入、保持、完整、移动、业务量

5G KPI 的统计指标体系可以归成几大类：接入性、保持性、完整性、移动性、业务量，再加上无线质量和可用性。每一类回答一个非常朴素的问题。

3.1 接入性与保持性：能不能连上、会不会掉

接入性回答"能不能连上"。在 NSA 组网下，它不是一个指标，而是一串：NR 网络中接入、NR Leg 建立、LTE 网络中接入。因为 NSA 终端要同时挂上 LTE 锚点和 NR 辅节点，任何一条腿没接上，业务就起不来。

话统里最常看的两个计数器是pmEndcSetupUeAtt（ENDC 建立尝试次数）和pmEndcSetupUeSucc（ENDC 建立成功次数），eNB 侧和 gNB 侧各有一套，两侧的成功率要分开算、分开看。两侧数字对不上，通常意味着接口或者配置有问题。

保持性回答"连上之后会不会掉"。对应的指标是会话掉线率、NR 连接释放、NR Leg 释放、LTE 连接释放，以及 LTE 侧的异常释放比例。

这里有一处特别容易被忽略的注释：NSA 场景下，NR Leg 的建立失败或释放，用户是感知不到接入性、保持性下降的——因为 LTE 那条腿还在，业务会回落到 LTE 继续跑。但用户的速率和时延会实打实地变差。也就是说，这类问题不会体现在接入类和保持类指标上，只会悄悄体现在完整性指标里。做优化的人如果只盯着接入成功率，就会漏掉一整片问题。

3.2 完整性与移动性：速率够不够、切换顺不顺

完整性管的是"用起来爽不爽"，核心是速率和时延。指标包括 NR 速率、LTE 速率、LTE Leg 速率，以及用户面时延、添加 NR Leg 的时延。速率类指标通常要同时看平均值和达标率，前者反映整体水平，后者反映体验的一致性。

移动性管的是"走动的时候顺不顺"。NR 内同频切换、异频切换、NR 与 LTE 互操作、LTE 异系统互操作都在这一类。NSA 下还要再拆细：gNB 内切换成功率和 gNB 间切换成功率，分别对应同一 gNB 内部和跨 gNB 的辅节点变更。

话统里对应的计数器名字很长，但结构很清楚：

# NSA 场景下几个移动性与接入性指标的算法示意 att_intra = 8600 # pmEndcPSCellChangeAttIntraSgnb：gNB内辅节点变更尝试次数 succ_intra = 8450 # pmEndcPSCellChangeSuccIntraSgnb：gNB内辅节点变更成功次数 att_inter = 3100 # pmEndcPSCellChangeAttInterSgnb：gNB间辅节点变更尝试次数 succ_inter = 2980 # pmEndcPSCellChangeSuccInterSgnb：gNB间辅节点变更成功次数 print(f"gNB内切换成功率: {succ_intra / att_intra * 100:.2f}%") print(f"gNB间切换成功率: {succ_inter / att_inter * 100:.2f}%")

这段代码只做一件事：用成功次数除以尝试次数。参数含义已经在注释里标出，Att是 attempt（尝试），Succ是 success（成功），IntraSgnb和InterSgnb区分的是同一个 gNB 内部还是跨 gNB。分母用错是最常见的错误——有人拿成功次数去除以"总用户数"或者"总呼叫数"，算出来的数字看着挺好看，其实没有物理意义。

3.3 业务量与无线质量：用户数和PRB利用率说明了什么

业务量类指标包括 ENDC 用户数、NR 用户数、ENDC 流量、NR 流量、ENDC 能力用户数。话统里常用的三个：最大用户数pmRrcConnLevelMaxEnDc、平均用户数pmRrcConnLevelSumEnDc / pmRrcConnLevelSamp、上下行总流量(pmMacVolUl + pmMacVolDl)/8/1024/1024/1024（换算成 GB）。最后一串除法的意思是：字节转比特除以 8，转 KB 除以 1024，一路除到 GB。

无线质量类指标更能说明"为什么慢"。PRB 利用率反映资源占用程度，上下行干扰反映底噪水平，编码方式比例（256QAM、64QAM、16QAM、QPSK、BPSK）和 RANK 比例（单流、两流占比）反映空口条件好坏。一个小区速率上不去，可能是 PRB 打满了，可能是干扰太大导致只能跑低阶调制，也可能是信道条件差只能单流传输——这三种原因对应的处理手段完全不同。

举一个具体的算法例子，小区内用户下行平均速率：

# 小区内用户下行平均速率，结果单位为 kbps pmMacVolDlDrb = 7_500_000_000 # DRB 下行 MAC 层字节数 pmMacTimeDlDrb = 18_000 # DRB 下行持续时长，单位 ms thp_kbps = 64 * pmMacVolDlDrb / pmMacTimeDlDrb print(f"下行平均速率: {thp_kbps / 1024:.2f} Mbps")

系数 64 来自"字节转比特（8）× 毫秒转秒的倒数（1000/125）"这一串单位换算的合并结果，所以分子用字节、分母用毫秒，直接乘 64 得到的就是 kbps。第一次看到这个公式的人大多会愣一下，但把单位拆开推一遍就通了。同理，小区 MAC 层下行速率用64 * pmMacVolDl / pmPdschSchedActivity，区别在于分母换成了 PDSCH 实际调度时长——一个有业务就计时，一个只在有调度时计时，两者算出来的数值天然不同，不能混着比。

4. NSA、SA与LTE：三套指标体系怎么对上

5G 的指标体系之所以看起来复杂，根源在于组网方式不止一种。NSA（非独立组网）、SA（独立组网）、以及作为底座的 LTE，三套体系并存，指标名字相似但口径不同，混用就会得出错误结论。

4.1 NSA的双连接结构：MN锚点与SN辅节点

NSA 下终端同时连接两个节点：MN（Master Node，主节点，通常是 LTE 基站）和 SN（Secondary Node，辅节点，即 NR 基站）。这种结构叫 EN-DC。理解了这一点，就能理解为什么 NSA 的 KPI 里到处是"锚点"这个词——LTE 锚点连接建立成功率、LTE 锚点掉线率、LTE 锚点切换成功率，这些指标评价的其实是"那条保命的腿"稳不稳。

也正因为有两条腿，NSA 的指标必须分腿统计。NR 辅节点连接建立成功率 = NR 辅节点成功增加次数 / 辅节点尝试增加次数，这个指标只看 NR 那条腿；而 EN-DC MN 锚点连接建立成功率只看 LTE 那条腿。两条腿的达标要求也不一样，前者常见要求是 98%，后者是 99%——锚点更严格，因为它一旦断了，整个业务就没了。

SN 变更的时延指标同样分控制面和用户面。控制面看的是从终端收到 RRC Connection Reconfiguration 信令开始，到向目标小区发送 RRC Connection Reconfiguration Complete 完成的时间差；用户面看的是基于 PDCP 数据包序号统计的断流时长——下行从收到源 SN 最后一个包，到收到目标 SN 第一个包；上行反过来。这两个时延的门槛通常在 20ms 和 40ms 量级，超出就意味着用户在切换瞬间会感到明显的卡顿。

4.2 从发展期到成熟期：指标关注点怎么迁移

同一张网络，处在不同建设阶段，该重点看的指标是不一样的。NR 不连续覆盖的发展期、NR 连续覆盖的成熟期 NSA、成熟期 SA，三者的关注点存在明显迁移：

这张表的读法是：发展期网络还没连成片，终端经常要在 NR 和 LTE 之间来回跳，所以移动性上只能看锚点 LTE 的切换，NR 自身的切换还谈不上；到了成熟期 NSA，NR 连成片了，NR 切换成功率才成为主角；进入 SA 之后，"支路"这个维度消失了，取而代之的是端到端的用户速率和 NR 自身的异系统切换。

搞错阶段会闹笑话。比如在发展期盯着 NR 切换成功率看，数据样本少得可怜，指标忽高忽低全是噪声；又比如在 SA 阶段还按 NSA 的口径去找"锚点掉线率"，根本找不到对应的计数器。

4.3 覆盖类KPI：SS-RSRP与SS-SINR的门槛

覆盖是 5G 优化的地基，覆盖类 KPI 的判定通常用"比例"而不是"平均值"。原因很直白：一段路上 95% 的位置信号很好、5% 的位置完全没信号，平均值可能依然漂亮，但用户体验是"每隔几百米断一次"。

常用的两个门限指标是 SS-RSRP（同步信号参考信号接收功率）和 SS-SINR（同步信号信噪比）。建设初期的典型要求是：SS-RSRP 高于 -88dBm 的比例大于 90%，SS-SINR 高于 3dB 的比例大于 90%。这两个数字必须成对出现——只看 RSRP 会漏掉"信号很强但干扰很大"的情况，那种场景下终端显示的格数满格，实际速率却上不去，是最容易被投诉的一种。

验收口径上还有一组更宽松但更强调"能用"的门槛：无线覆盖率定义为 SS-RSRP ≥ -100dBm 且 SS-SINR ≥ 0dB 的数据点百分比，要求不低于 90%。注意这里是"且"，两个条件同时满足才算一个有效覆盖点。

速率方面的验收目标通常按运营商分别设定，比如某运营商要求 NSA/SA 下行平均 500Mbps，另一家要求 420Mbps；上行某运营商 NSA 50Mbps、SA 80Mbps，另一家 60Mbps。这类数值会随网络规模和当地要求动态调整，属于典型的"以当地客户要求为准"。

还有一个容易被当成覆盖率用的指标：5G 驻留时长占比 = 5G 网络驻留时长 / 总体测试时长，常被作为覆盖考察指标。它和覆盖率的区别在于，覆盖率看的是"信号够不够强"，驻留比看的是"终端愿不愿意待在 5G 上"。信号够强但终端被参数赶回 LTE，覆盖率满分、驻留比很难看，这种情况在实际网络中并不罕见。

5. 常见误区：这几个概念最容易混

KPI 体系里有一批"长得像、名字像、算法不像"的概念，初学者混用之后，往往做出错误的优化决策。下面五组是最典型的。

5.1 路测KPI 与 话统KPI

易混点：两个都叫 KPI，都能算出成功率和速率，很多人以为只是数据来源不同，指标本身是一回事。

为什么混：它们的名字确实重合度很高，都有接入、保持、速率、切换这几类，指标名甚至一模一样。

怎么区分：路测 KPI 来自测试终端在固定路线上跑出来的样本，是抽样数据，反映的是"用户在这条路上感知如何"；话统 KPI 来自网络侧计数器的全量统计，反映的是"所有小区所有时段发生了什么"。路测样本量小但贴近真实体验，话统覆盖全但可能和体验脱节。判断标准也不同：路测看的是达标率（比如单用户下行速率 ≥100Mbps 的样点占比 ≥90%），话统看的是全量比值。分析问题时，路测负责"发现问题路段"，话统负责"定位问题小区"，顺序不能颠倒。

5.2 接入成功率 与 会话建立成功率

易混点：两者都描述"业务能不能起来"，常被当成同义词互换使用。

为什么混：在 LTE 单连接时代，二者几乎是同一件事，很多人带着这个习惯进了 5G。

怎么区分：会话建立成功率是从用户业务角度看的端到端指标；而在 NSA 下，一次成功的会话可能包含 MN 锚点建立和 NR 辅节点建立两步，各自有独立的成功率。NR 辅节点建立失败时，业务可能仍然建立成功，只是跑在 LTE 上。所以会出现"会话建立成功率 99%，但 NR 支路建立成功率只有 95%"这种组合，此时用户能上网，但速率明显偏低。看接入类指标，必须明确问一句：这是端到端的，还是某条支路的。

5.3 掉线率 与 异常释放比例

易混点：都涉及"连接断掉"，看起来只是叫法不同。

为什么混：异常释放听起来就像是掉线的另一种说法，字面意思高度接近。

怎么区分：掉线率的分母是"成功完成连接建立次数"，分子是"掉线次数"，它是一个面向用户感知的比率，衡量的是"连上之后非正常断开的概率"。异常释放比例则是话统侧的一个统计量，统计的是各类异常释放原因在总释放中的占比，它可以包含用户主动释放、网络侧因资源或拥塞触发的释放等多种情形，粒度更细但不直接等于用户感知的掉线。掉线率适合对外汇报，异常释放比例适合对内定位——前者告诉你"有多严重"，后者告诉你"为什么"。

5.4 覆盖率 与 驻留比

易混点：都用来评价"5G 铺得好不好"，经常在同一张汇报表里并列出现。

为什么混：在理想情况下，有覆盖就应该有驻留，两个数字确实应该接近。

怎么区分：覆盖率是信号强度的空间统计，问的是"这个地方信号够不够强"；驻留比是时间的统计，问的是"终端在这里待了多久"。覆盖率 95% 而驻留比只有 80%，说明网络信号没问题，但终端被某些策略赶回了 LTE——可能是锚点优先接入策略、可能是邻区配置让终端过早重选、也可能是终端能力或套餐限制。覆盖率低而驻留比高，则说明测试区域选得偏乐观。两个指标一起看，才能区分"建设问题"和"策略问题"。

5.5 平均值 与 达标率

易混点：都能描述速率，汇报时随手挑一个用。

为什么混：平均值算起来简单，达标率要设门限，很多人图省事只用平均值。

怎么区分：平均值把所有样本一锅烩，一段高速加一段断流，平均下来可能还挺好看；达标率设一条线（比如 ≥100Mbps 的样点占比），专门暴露分布的不均匀。做验收和对比时必须用达标率，因为它是"最差那部分体验"的守门员；做容量规划时可以看平均值，因为关心的是总量。同一批数据，平均值 420Mbps 可能对应达标率 85%，也可能是 98%，两者背后的网络状态天差地别。

6. 什么时候该看KPI、什么时候别被KPI牵着走

KPI 是工具，不是目标。判断什么时候该用、什么时候该停，可以按场景分：

一个具体的例子。某段道路用户反馈"看视频总转圈"，路测数据显示该路段 SS-RSRP 达到 -85dBm、覆盖率指标漂亮得很，但单用户下行速率达标率只有 70%。切到话统看对应小区，PRB 利用率在忙时长期贴着高位，上行干扰也偏高。这时候如果只盯覆盖率，结论会是"覆盖没问题，可能是终端或服务器问题"，然后就卡住了；把覆盖率、达标率、PRB 利用率、上行干扰四个指标串起来看，问题才清晰：不是信号不够，是资源不够外加干扰压着调制阶数上不去。对应动作是扩容和干扰排查，跟加功率、调天馈一点关系都没有。

反过来，也有不该迷信 KPI 的时候。用户投诉集中在某个时段、某类终端，而全网指标纹丝不动，这恰恰说明指标口径没有覆盖到那个维度。这时候该做的是缩小统计粒度——按时段、按终端类型、按小区拆开看，而不是继续盯着那张全网红绿报表自我安慰。

我自己踩过最深的一个坑，是早期做簇优化时只看了切换成功率，指标 99% 以上，觉得一切正常，结果用户投诉不断。后来把异常释放比例和 NR 辅节点建立成功率一起拉出来，才发现有一批站点的 NR 腿压根就没建起来几次，用户全程跑在 LTE 上，切换当然"成功"——因为根本没有 NR 可切。从那以后我每次看一组 KPI，都强制走一遍"这个指标的分母是谁、失败的那部分去哪了"的检查，宁可多问一句，也不让数字替我做决定。希望帮到你。

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