简介面向运营商网络优化工程师与无线网规人员这份演示文稿系统梳理了爱立信5G-KPI体系用于帮助读者理解5G网络性能评估的量化指标框架。内容涵盖从单站健康检查、簇优化到全网优化的层级划分并覆盖接入性、保持性、移动性、完整性等评估维度路测KPI侧重覆盖范围、信号强度与质量网络统计KPI用于基站性能验证簇优化一般以1540个基站为一组开展RF优化与异常事件处理。同时详解NR NSA与SA统计指标体系以及LTE接入情况包括NR Leg建立与释放、切换成功率、PRB利用率、编码方式比例、上下行干扰、用户面时延、小区完好率等关键参数不同时期NR终端的指标重点各有侧重如发展期、成熟期NSA/SA的会话建立成功率、保持性、速率完整性与移动性。5G覆盖优化还给出SS-RSRP/SS-SINR门限、上下行平均速率、5G驻留时长占比等典型验收要求。资源共1个pptx演示文稿约450KB结构清晰、重点突出便于直接用于知识讲解或内部培训。已有143人学习浏览适合作为5G网络优化、KPI设置与考核工作的简明参考。1. 爱立信5G-KPI体系指标全绿用户却投诉问题出在哪某省5G规模试验网项目验收时所有KPI报表漂亮得能直接进PPT——RRC建立成功率99.8%、切换成功率99.5%、CQI均值10.5但用户投诉视频卡顿、游戏掉线的工单堆了一整屏。排查了三天最后发现是KPI体系本身的口径和聚合粒度出了问题指标不是越多越好而是要看它们怎么分层、怎么互证。爱立信5G-KPI体系的价值不在于那一串计数器名字而在于把“接入、保持、体验、资源”四层指标串成一条可追踪的链路让任何一层异常都能顺着链路找到病根。这篇笔记给网优工程师、性能管理人员和刚转5G优化的人讲清楚这套体系怎么搭、每个指标怎么算、坑在哪以及怎么把报表变成能定位问题的工具。2. 5G-KPI体系分层架构接入、保持、体验、资源四层指标怎么串起来2.1 为什么按“接入-保持-体验-资源”分层而不是按网元分层很多刚接触5G优化的朋友拿到KPI清单第一反应是按网元分类空口指标归基站、核心网指标归核心网、传输指标归传输。这个思路在排查单一网元故障时好用但遇到端到端用户感知问题就抓瞎。爱立信体系更常用的做法是按用户业务的生命周期分层因为5G的KPI体系设计初衷是服务于“用户能不能连上、能不能稳住、能不能跑出速率、资源够不够支撑”这条业务链。接入层回答“用户能不能进得来”保持层回答“用户能不能待得住”体验层回答“用户感知好不好”资源层回答“小区还有没有余量”。四层之间天然存在因果联动资源层拥塞会导致保持层掉线率抬升保持层异常会直接拉低体验层速率。分层之后问题排查就从“猜哪个网元坏了”变成了“看哪一层指标先恶化”排查效率完全不是一个量级。我一般建议团队把KPI分成两级来看一级叫监控KPI每15分钟盯一次异常触发告警二级叫分析KPI出问题后深挖用粒度更细。监控KPI控制在每层2到3个分析KPI每层准备5到10个。表格是常见分层方式层级监控KPI示例分析KPI示例对应业务问题接入层RRC建立成功率、NGAP初始化上下文建立成功率RRC建立时延、NGAP建立时延、gNB间N2切换成功率用户能不能接入网络保持层无线掉线率、切换成功率站内/站间切换成功率、RLF触发率、RRC重建成功率业务进行中会不会中断体验层下行平均速率、CQI均值、MCS均值BLER、CQI分布、MCS分布、时延用户实际感受好不好资源层PRB利用率、RRC连接数CCE利用率、上行/下行PRB利用率、PUSCH/PDSCH BLER小区容量是否耗尽2.2 一个投诉工单进来四层KPI按什么顺序查实际排查时四层指标不是平行看的而是有一条固定路径。某运营商项目里A同学每次收到“用户视频卡顿”投诉第一件事不是查速率而是先查接入层再查保持层最后才看体验和资源。这个顺序有讲究如果接入层都进不来体验层速率再高也没有意义。排查路径是确认用户当前驻留小区和频段 → 查该小区的RRC建立成功率接入层→ 查切换成功率和掉线率保持层→ 查CQI均值和下行平均速率体验层→ 查PRB利用率和RRC连接数资源层。每一层有异常就停下先处理没有异常才往下走。这个顺序还有一个附带作用它能快速界定问题边界。接入层异常说明是覆盖或参数配置问题保持层异常说明是移动性参数或邻区关系问题资源层异常说明是容量问题体验层异常则可能是干扰或调度问题。四层定位下来问题归属的类别基本就圈定了不会出现“不知道该叫无线组还是核心网组来一起开会”的扯皮场面。2.3 爱立信体系里KPI的分工逻辑一句话说清每个指标负责任务把四层指标串起来之后还有一个更细的分工逻辑值得留意每个KPI背后对应一个“计数器组合”而这个组合定义了指标到底在量什么。同一个指标名在不同厂商网管里的计算公式可能不同这是跨厂商对比时最容易被坑的地方。爱立信体系的计数器命名一般遵循“对象事件结果”的模式比如RRC建立相关计数器会有Attempts和Successes两类上报告警系统时直接算比值。但要注意的是“成功”的定义在不同厂商间有差异有的把RRC建立成功定义为收到UE的RRC Setup Complete有的定义为下发RRC Setup之后就算成功。差这一个定义成功率可能差0.5个百分点。所以做KPI体系时第一步不是看指标名而是把每个指标的计算口径从网管里导出来确认一遍。3. 核心KPI指标与计算口径手把手对一遍统计逻辑3.1 接入类KPIRRC建立成功率与NGAP建立成功率的分子分母边界RRC建立成功率是5G网优最常用也最容易误读的指标。公式本身不复杂RRC建立成功率 RRC建立成功次数 / RRC建立尝试次数 × 100%。问题是“尝试次数”到底从哪里开始算。在爱立信体系里RRC建立尝试一般从gNB收到UE的RRC Setup Request消息开始统计到gNB向UE发送RRC Setup消息算一次成功响应再到UE回RRC Setup Complete才算完整成功。三个阶段里任何一个中断都会影响最终成功率。这里有个细节很多人不看爱立信网管里RRC建立成功率分了两个子计数器——一个是gNB侧RRC建立成功率只看空口一个是包含核心网交互的端到端RRC建立成功率RRC Setup Complete之后还要等NGAP初始化上下文建立完成。排查时要先确认用的是哪一个口径否则会出现空口指标99.9%、端到端指标只有97%的现象两边拿着报表互怼。NGAP初始化上下文建立成功率是接入层另一个容易被忽略的指标。它反映的是gNB与核心网之间的信令交互是否顺畅分母是NGAP INITIAL CONTEXT SETUP REQUEST的尝试次数分子是收到INITIAL CONTEXT SETUP RESPONSE成功的次数。这个指标异常时问题往往不在无线侧而在核心网配置或传输链路排查方向要立刻转向。3.2 保持类KPI切换成功率和掉线率的统计窗口别混用切换成功率看起来谁都会算但“切换”这个词下面藏了至少三种场景站内切换gNB内部小区间、站间Xn切换两个gNB之间走Xn接口、N2切换走核心网AMF转发。爱立信体系里这三个场景的计数器完全分开但很多项目组的报表里把它们揉成一个“总切换成功率”。这个总指标最大的坏处在于站内切换占比高时会掩盖站间切换的问题。举个实际翻车案例某个网格内站内切换占比85%站间切换成功率只有70%但总切换成功率算出来是94%报表看着一切正常。后来用户反映开车过站时业务频繁中断一查才发现是Xn切换的问题被稀释了。所以做KPI体系时我一般会强制要求把站内、站间Xn、N2三类切换成功率分开统计每个单独设置监控阈值。掉线率的统计窗口是另一个高频踩坑点。5G里掉线通常指RRC连接异常释放但“异常释放”的判定涉及计时器UE侧触发RLF无线链路失败后如果在一定时间内没有完成RRC重建才会计一次掉线。这个“一定时间”在不同配置下可能是2秒、5秒或10秒。时间窗口设得短掉线率看起来偏高设得长问题被延时掩盖。爱立信体系里一般有个gNB侧RLF计时器配置项改之前先确认网络侧和终端侧的计时器是否匹配两边不一致时掉线率指标本身就没有可比性。3.3 体验类KPICQI、MCS与BLER怎么关联起来看体验类指标里CQI均值是最常被拿来做PPT的但也是最容易被平均掩盖问题的。CQI是UE上报的信道质量指示范围0到15数值越大代表信道质量越好。单看CQI均值很容易忽略“分布”一个小区CQI均值10可能对应的是90%的用户CQI 11、10%的用户CQI 3也可能对应全部用户CQI 10。两种场景下网络体验完全不同前者是局部覆盖黑洞后者是整体干扰抬升。MCS调制编码方案是gNB根据CQI选择的调制编码等级范围0到27左右。关注MCS分布比关注MCS均值更有价值低MCS占比比如MCS小于10的占比能直接反映边缘用户或干扰区域的规模。实操中我一般把“CQI ≥ 7的占比”和“MCS ≥ 15的占比”作为体验层监控指标比均值灵敏得多。BLER误块率的判读要特别注意初传BLER和重传BLER的区别。很多体系里监控的是初传BLER目标值通常设在10%左右对应的是外环调整的目标误块率。但如果只盯初传不看重传BLER就会忽略HARQ重传对时延和速率的拖累。正常小区重传BLER应该在个位数如果重传BLER超过20%调度器可能频繁重传下行速率会明显下滑。3.4 资源类KPIPRB利用率高不代表“资源不够”资源层指标最容易产生误判的是PRB利用率。很多刚入行的同事看到PRB利用率80%就断定小区容量拥塞但这个指标要结合MCS一起看。MCS为20时的高PRB利用率和MCS为5时的高PRB利用率含义完全不同前者是满负荷跑高吞吐后者可能是在干扰环境下用低效编码硬撑。CCE利用率是下行控制信道的占用情况和PRB利用率数据信道是两条独立的资源维度。一个小区数据信道很空、CCE利用率却到90%说明公共控制信道资源受限常见于配置了过多聚合级别或PDCCH符号被压缩的场景。RRC连接数则代表小区当前的在线用户规模它本身不是瓶颈指标但结合PRB利用率看能区分“真拥塞”和“假拥塞”RRC连接数只有50、PRB利用率80%大概率是干扰和调度问题不是容量问题RRC连接数300、PRB利用率80%才需要考虑扩容。4. 从计数器到指标KPI采集、汇聚与计算的落地路径4.1 原始PM数据怎么拿网管导出与计数器命名规则KPI体系落地第一步是把网管里的原始计数器PM数据导出来。爱立信网管支持按小区粒度导出15分钟粒度的PM文件文件里每个计数器有独立字段名。实际项目中我一般直接用网管自带的报表模板先跑一遍确认字段后再写自动化脚本做二次加工。计数器命名有规律可循RRC建立相关计数器常以rrcConnEstab开头切换相关以hoConn或xnHo开头CQI相关以cqi开头PRB相关以prbDL或prbUL开头。每个计数器的末尾有Succ或Att的后缀区分成功和尝试。但厂商不同版本命名会有调整导出的PM文件里一般附带字段字典第一次对接时务必先拉一遍字典别手敲字段名。4.2 聚合计算15分钟粒度先算比率还是先加总数再算比率KPI聚合计算看似简单其实有个顺序问题从15分钟粒度汇聚到小时、天粒度时不能先算每个15分钟的成功率再求平均而应该先把分子和分母分别求和最后再算比率。为什么因为每个15分钟时段的业务量不同时段的权重不同。直接平均等于给每个时段相同的权重忙时的异常会被闲时拉低。例如三个15分钟时段的RRC建立尝试分别为100、200、50失败次数分别为5、10、5各时段成功率分别为95%、95%、90%直接平均得到的成功率是93.3%正确算法是分子分母先分别相加15/30得94.3%。差异看着不大但在切换成功率这类分母较大的指标上按天聚合时差异能到0.3到0.5个百分点这个误差足以触发或掩盖告警。4.3 用Python写一个最小KPI计算与异常标记脚本下面这个脚本是模拟项目里实际在用的KPI计算流程的简化版读入PM记录按小区聚合正确计算比率再和基线阈值比对并标记异常。数据格式模拟为CSV字段包含小区ID、时间戳、RRC尝试次数、RRC成功次数、切换尝试次数、切换成功次数。import pandas as pd # 模拟读取PM文件实际项目中路径通常来自网管导出目录 df pd.read_csv(pm_5g_sample.csv, parse_dates[timestamp]) # 按小区日期聚合分子分母分别求和避免先算比率再平均的坑 df[date] df[timestamp].dt.date grouped df.groupby([cell_id, date]).agg( rrc_att(rrc_attempts, sum), rrc_succ(rrc_successes, sum), ho_att(ho_attempts, sum), ho_succ(ho_successes, sum) ).reset_index() # 正确计算聚合后的比率 grouped[rrc_success_rate] grouped[rrc_succ] / grouped[rrc_att] * 100 grouped[ho_success_rate] grouped[ho_succ] / grouped[ho_att] * 100 # 基线阈值RRC建立成功率低于99%切换成功率低于98.5%则标记异常 grouped[rrc_alarm] grouped[rrc_success_rate] 99.0 grouped[ho_alarm] grouped[ho_success_rate] 98.5 # 筛出异常小区输出告警清单 alarm_df grouped[(grouped[rrc_alarm]) | (grouped[ho_alarm])] print(alarm_df.head())逻辑说明先按小区和日期做分子分母聚合再算比率这保证了聚合口径正确。阈值只是示例实际项目里要根据网络阶段调整——新建网的RRC建立成功率阈值可以放到98%成熟期网络应放到99.5%以上。脚本里用布尔掩码筛异常实际生产中可以替换为将告警结果写入数据库或推送消息系统。参数调试建议cell_id字段在爱立信PM里通常是全局小区标识类似PLMNENBCI的组合不同版本的字段名可能是cellId或eutranCellRelation导出PM文件时确认一下时间字段时区要统一跨时区项目用UTC时间戳最稳阈值建议分忙时和闲时两套因为闲时的小样本波动会让比率指标剧烈跳动。5. KPI体系落地中的几个坑从配置错误到口径玄学5.1 凌晨KPI大面积掉坑但业务毫无影响现象每天晚上凌晨2点到4点某个区域所有小区的RRC建立成功率和切换成功率同时下跌4到5个百分点白天恢复。看业务量这段时间几乎没用户。原因排查发现运营商操作维护窗口在这个时段批量执行配置更新配置下发过程中的计数器重置或信令拥塞导致统计异常而非真实业务故障。这是典型的“统计窗口干扰”不是网络问题。解决在统计脚本里排除维护时段或者单独建一个“维护时段专用KPI基线”不和白天业务时段混用。更稳妥的做法是把维护操作记录和KPI数据关联起来看到某个小区在维护时间窗内有指标异常先查操作记录再判断是否派单。5.2 切换成功率总指标很高但跨站切换一塌糊涂现象网格整体切换成功率99.2%但用户投诉沿高架路行驶时业务频繁中断拉网测试发现高架路段每到一个站点边界就断一次。原因总切换成功率把站内切换占比约70%和站间Xn切换混在一起算站间问题被站内好指标稀释。高架场景车速快、信号变化剧烈跨站切换对时延和参数配置高度敏感。解决指标拆开统计站内切换成功率、站间Xn切换成功率、N2切换成功率各设各的阈值。同时检查高架路段邻区关系是否完整、测量报告触发参数是否匹配车速场景。这个坑的根源不是KPI本身而是KPI的聚合粒度掩盖了场景差异。5.3 CQI均值正常但高MCS占比掉得厉害现象小区CQI均值稳定在10.5抄表看指标一切正常但用户反馈下载速率只有正常值的一半。深入核查发现CQI均值没变但MCS ≥ 15的占比从70%掉到了40%。原因CQI均值有“幸存者偏差”效应——信道条件好的用户贡献了高CQI但干扰区域的用户上报低CQI被平均掉了。均值指标对分布变化不敏感MCS分布才是真正反映调度结果和用户感知的指标。解决监控指标从“CQI均值”调整为“CQI ≥ 7占比 MCS ≥ 15占比”两个分布指标同时盯。这类问题在异频干扰场景最常见排查时还要顺带看PUSCH和PDSCH的干扰噪声值NI值是否抬升。5.4 KPI计算脚本丢小区新开站数据被静默过滤现象每周例行报表里某几个新建小区的KPI一直缺失但网管上能看到这些小区有PM数据。脚本不报错不告警数据就是不出来。原因脚本用小区配置表和PM数据做内连接inner join新建小区在配置表里更新延迟PM数据先到、配置表后到内连接直接把新小区数据丢了。这个坑容易出现在新站入网割接期间。解决把脚本里的join策略改成全连接full outer join并以PM数据侧为准配置表缺失时先用站名占位并标记告警。加一个数据完整性校验步骤——统计每天参与计算的小区数和网管小区总数是否一致不一致就报缺失清单。5.5 PRB利用率高但吞吐量低资源“假忙”现象某个室分小区PRB利用率长期在80%以上但下行平均速率只有正常小区的三分之一用户投诉网速慢。按常规思路扩容扩容后速率并没有明显提升。原因深入分析后发现该小区存在强外部干扰干扰导致MCS被压低gNB用低阶MCS调度同样多的PRB实际承载的比特数大幅下降。PRB利用率的“忙”是虚的真正的问题是干扰。解决遇到PRB利用率高但吞吐量低的情况先查MCS分布和NI值再决定是否扩容。NI值干扰噪声抬升超过某阈值时优先排查干扰源不要急着扩容量。这个经验在密集城区和室分场景尤其重要血泪教训。6. 把KPI从被动报表变成主动筛查滑动窗口基线和地理化关联KPI体系做到能看、能算、能告警还只是及格线。更进一步的做法是把历史KPI数据变成基线库让指标自己和自己比而不是拿一套固定阈值打天下。固定阈值的问题是不同区域、不同时段、不同网络阶段的“正常”标准完全不同一套阈值必然误报漏报。我一般用滑动窗口基线法对每个小区、每个KPI取过去7天相同时段的P95和P5作为上下边界当前15分钟指标落在边界外就触发异常。基线算法的参数设置很关键。时间窗口取7天而不是3天是为了跨过周末和工作日的业务差异P95和P5比均值和标准差更抗离群点个别小时段的突发不会污染基线更新频率我一般设每天一次凌晨用前一天完整数据重算基线。对于KPI异常的判断光看单点越过阈值还不够建议连续两个15分钟时段都越界才告警这能滤掉很多瞬时抖动。参数推荐值说明基线窗口7天覆盖工作日与周末差异上下边界P95 / P5抗离群点比平均值±标准差稳健基线更新频率每日1次凌晨低峰期用昨日数据重算告警确认连续2个时段越界滤除瞬时抖动地理化关联是把KPI从“数字”变成“位置”的关键一步。把小区级KPI叠加到地图上按异常程度着色一眼就能看出干扰是点状还是面状、掉线是集中在特定路段还是覆盖大片区域。再把道路测试数据和KPI异常放在同一个地理坐标系里对能快速验证“用户投诉的高架路段是不是刚好对应某小区切换成功率跌到90%的地带”。这套做法的好处是把四层指标从“网管里的数字”变成了“地图上的位置”排查会议上的分歧立刻少了一半。回看这些年做KPI体系折腾过的项目最深的教训是指标口径统一比指标数量重要聚合粒度比美化报表重要分布指标比均值指标重要。先把自己系统里的分类框架、计算边界和聚合规则定死再上自动化工具顺序反了就会在报表上花掉大量不应该花的时间。希望这篇笔记能帮你在搭KPI体系时少走几趟弯路。本文还有配套的精品资源点击获取