简介《爱立信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 单站健康检查先看哪四项单站验证是基站入网前的门槛测试目的是确认这个站自己没毛病别把设备问题带进簇里。实际作业里我不会一上来就跑全业务先按四项过一遍任何一项不过就退回整改不进入下一步。检查项判据常见异常来源小区建立状态与告警小区全激活、无驻波/传输/时钟告警光模块、时钟源、传输闪断接入性随机接入成功率、RRC 建立成功率达标PRACH 根序列冲突、初始功率偏置完整性近/中/远点单用户上下行速率达标天馈接反、通道故障、参数配错移动性与规划邻区可正常切换、Xn/X2 链路通邻区漏配、PCI 冲突、传输路由这四项的顺序有讲究。先看告警是因为驻波比异常会让后面所有速率测试都白做再看接入是因为接入不稳定的站速率采样本身就不具备代表性移动性放最后是因为单站阶段邻区还没全开只能验证“能不能切”切得好不好要留到簇优化。这里有个容易被忽略的点单站验证阶段采集的速率是“净速率”要在空载或轻载下测。曾经有站点在晚忙时抽测下行只跑到 200Mbps一度怀疑是通道故障后来换到凌晨复测直接到 800Mbps。忙时数据不是不能用但它衡量的是“网络当前能给多少”不是“这个站本身能跑多少”两个结论别混。2.2 簇优化为什么以 15~40 个基站为界簇的规模定在 15~40 个站不是拍脑袋。站太少天馈下倾角一动覆盖外溢到簇外你在簇内看到的改善可能是把干扰推给了隔壁簇站太多一次 RF 调整的复测周期拉长问题定位的因果链就断了。15~40 这个区间大致对应一个中等规模城区的连片覆盖既能形成完整的切换链又能在两三天内完成一轮 DT 复测。簇优化阶段的核心动作是 RF 优化加异常事件清理顺序上我一般这么走簇划分与边界确认按地理连片和切换关系划簇明确簇边界小区边界小区只做保守调整。基础数据核查PCI、PRACH 根序列、TAC、邻区关系这四项在路测前必须过一遍否则路测数据里一半的“切换失败”都是配置问题。DT/CQT 采集主干道、网格道路、重点室内入口各跑一遍车速和路线固定保证两轮复测可比。RF 优化下倾角、方位角、RS 功率三件套每次只动一个维度动完立刻小范围复测。异常事件处理掉话、切换失败、接入失败、NR 辅节点添加失败逐条回溯信令。簇内复测与收敛判定覆盖率、掉线率、切换成功率三项同时达标才算收敛。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 层、端到端层。类别NSA 主要指标SA 主要指标LTE 对应指标接入性ENDC 建立成功率eNB 侧/gNB 侧会话建立成功率、RRC 建立成功率RRC 建立成功率保持性LTE 锚点掉线率、NR 数据业务掉线率、异常释放比例会话掉线率连接释放、E-RAB 掉线率完整性NR 速率、LTE Leg 速率用户速率LTE 速率移动性gNB 内/间辅节点切换成功率、NR 与 LTE 互操作NR 内同频/异频切换、IRAT 切换同频/异频、异系统切换业务量ENDC 用户数、ENDC 流量、PRB 利用率NR 用户数、流量LTE 用户数、流量无线质量RANK 分布、编码方式比例、上下行干扰同左同左可用性小区完好率小区完好率小区完好率这张表里最关键的一列是“LTE 对应指标”。NSA 阶段很多 NR 问题会先在 LTE 侧露出苗头比如 LTE 锚点掉线率突然抬升往下挖往往是 NR 辅节点释放异常把锚点带崩了。反过来NR Leg 建立失败在用户侧感知不到接入性下降但会实打实影响速率和时延——这是这套体系里专门标注过的一点做 KPI 看板时不能把它和“接入失败”混成一个告警等级。SA 阶段少了 LTE 锚点这层指标链变短但新增了会话建立和 NG 接口相关的维度。从 NSA 迁到 SA 的时候原有的话统报表不能直接平移接入性和保持性的分母都要重算这一点后面避坑章节会展开。3.2 发展期到成熟期指标重点怎么迁移同一张网在不同建设阶段该盯的指标是不一样的。这套体系把 NR 终端相关指标按“发展期NR 不连续→ 成熟期 NSANR 连续→ 成熟期 SANR 连续”划了三段重点迁移大致是这样类别发展期成熟期 NSA成熟期 SA接入性会话建立成功率、NR 支路建立成功率会话建立成功率会话建立成功率保持性会话掉线率、NR 支路掉线率会话掉线率会话掉线率完整性NR 支路速率用户速率用户速率移动性锚点 LTE 切换成功率锚点 LTE 切换、NR 切换NR 切换、IRAT 成功率业务量NR 用户数NR 用户数、PRB 利用率同左读这张表的正确姿势是看“哪些指标从支路级升到了用户级”。发展期 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, encodingutf-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}, fRANK2{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, encodingutf-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 终端的用户属于潜在发展对象不能算进驻留比分母里否则指标永远做不上去。从那以后我每次做驻留比专项都强制先跑一遍终端能力分层再跑小区级倒流排名最后才动参数。顺序反了改完参数指标涨了两个点过一周又掉回去连是终端换机还是参数回退都分不清。希望这套拆法能帮到你。本文还有配套的精品资源点击获取