企业官网建设流程全解析

简介：《爱立信5G-KPI体系介绍》是一份面向5G网络优化工程师、运营商技术人员及通信专业学习者的指标科普与实战参考材料，侧重梳理爱立信5G KPI counters在单站验证、簇优化和全网优化中的定位与用法。资源包共1个pptx文件，大小约450KB，以幻灯片形式组织，便于按章节讲解接入性、保持性、移动性、完整性、业务量、PRB利用率、上下行干扰、无线质量、小区完好率与用户面时延等指标。已有143人学习，说明其适合作为入门梳理或项目备查。内容围绕路测KPI与网管统计指标展开，覆盖NSA/SA及LTE网络中的接入、NR Leg建立与释放、切换成功率、速率完整性、驻留时长占比、覆盖优化目标值等，并区分发展期、成熟期NSA和成熟期SA的终端关注重点，可帮助读者建立从指标定义、验收要求到优化方向的整体框架。

1. 一次"没感觉"的掉线：5G KPI体系为什么要给同一张网记两本账

5G 网络里最容易被忽略的一次掉线，是 NR 辅节点悄悄释放、而业务从 LTE 锚点上继续跑完的那一次。用户没投诉，速率却从 500Mbps 掉到 80Mbps。5G KPI 体系和背后的计数器，本质上就是为这类"看不见的劣化"建账：把体验拆成接入性、保持性、移动性、完整性、业务量、无线质量、可用性七个维度，再用路测和话统两套统计口径分别记账。真正的价值在于搞清楚每个数字在什么前提下被算出来：同样叫"覆盖率"，双门限怎么定、按采样点还是按用户加权，结论可能完全相反。

2. 双轨账本：路测KPI与话统KPI为什么不能互相替代

2.1 路测KPI：抽样视角测的是能力上限

路测的核心特征是样本可控但覆盖有限。测试终端沿固定路线跑，采样点密度、测试车速、锁频锁小区策略都由人决定，所以它回答的问题很明确：这段路、这个时刻，网络能给到的最好成绩是多少。验收体系里的那一组门限就是按这个逻辑定的：无线覆盖率要求 SS-RSRP≥-100dBm 且 SS-SINR≥0dB 的数据点占比不低于 90%，单用户下行速率达标率要求 EN-DC PDCP 层速率≥100Mbps 的样点占比不低于 90%，而下行平均速率直接卡在 420Mbps、上行 60Mbps 这一档，测的是峰值能力而不是日常体验。

提示：路测里的"2.5ms 双周期"是个容易被忽略的前提。SSB 波束扫描周期变了，同一位置的采样密度和 RSRP 读数都会变，跨版本对比路测数据前先确认这个参数一致。

正因为测的是上限，路测指标对"偶发"极其不敏感。一次 SN 增加失败、一次随机接入冲突，在几百个采样点里可能连一个点都占不到，所以路测数据永远看不出稳定性问题。

2.2 话统KPI：全量视角测的是稳定性

话统走的是完全相反的路子：不挑用户、不挑位置、不挑时间，所有小区所有终端的所有尝试都进分子分母。它的价值在于暴露概率。EN-DC 建立成功率写成100*(pmEndcSetupUeSucc/pmEndcSetupUeAtt)，分子分母都来自同一个采集周期，只要尝试次数足够大，千分之几的劣化就能被稳定识别出来。代价是口径完全依赖计数器定义：分母算不算重试、失败原因怎么归类、无尝试的小区是否计入整网均值，任何一个细节变动都会让曲线跳一下。

两套账的差异可以用一张表说清：

2.3 三阶段坐标系：单站验证、簇优化、全网优化各自校准什么

KPI 体系不是一张平铺的表，它跟着网络建设节奏分三段走，每段关注点不同：

单站验证发生在基站入网前，做单站健康检查、单站建设完整性核查和业务量验证，目标是确认这个站本身没坏：小区建立正常、通道数对得上、能发起业务、能跑出接近理论值的峰值速率。这一阶段基本不看切换类指标，因为孤岛环境下邻区关系还没建起来。

簇优化以 15~40 个基站为一个簇，是真正意义上的入网测试。手段以路测为主，做 RF 优化和异常事件优化，重点看覆盖、切换、掉线这些只有多站交叠才会暴露的问题。单站验证全部通过、簇优化一跑就翻车，是这一阶段最常见的剧本，原因往往不在设备而在邻区规划和 PCI 复用。

全网优化在簇优化基础上扩大范围，此时单靠路测已经跑不过来，必须同时看路测指标和网管性能指标。这一阶段的判据从"这段路行不行"变成"整张网的行不行"，话统的权重明显上升。

三个阶段对应三种判据，把它们的结论混着用，是最容易得出错误结论的做法。

3. leg 解耦：NSA为什么把一条连接拆成三段来算

3.1 双连接下一条链路的三段生命周期

NSA 的本质是一条业务同时挂在两个基站上：LTE 侧做 MN 锚点，NR 侧做 SN 辅节点。这条链路并不是"一个连接"，而是三段可控的生命周期叠加：MN 锚点建立属于 LTE 接入流程，SN 辅节点增加是 NR 侧的独立信令过程，最后数据承载在 PDCP 层分流。指标体系据此把一次会话切成接入性、保持性、完整性、移动性四组，每组都对应生命周期里的一段。

这个切法的直接后果是：同一个用户的一次业务，会同时出现在 LTE 和 NR 两套 KPI 里。看报表时如果不去重，整网用户数会凭空多出一截。指标体系里专门列了 ENDC 用户数、NR 用户数、ENDC 能力用户数三个口径，就是为了区分"驻留用户""能力用户"和"实际使用用户"这三件事。

3.2 为什么接入性要用三层指标而不是一个成功率

路测验收表里，接入这一栏从来不是一个数字：EN-DC MN 锚点连接建立成功率卡 99%，EN-DC NR 辅节点连接建立成功率卡 98%，NR 辅节点连接建立时延单独列为待定项。三层指标拆开看，是因为失败点不同，根因完全不同：

• MN 锚点建不起来，问题在 LTE 覆盖、PRACH 配置或核心网侧，属于基础接入问题；
• SN 辅节点加不上去，问题在 NR 覆盖门限、Xn 传输、辅节点资源或 B1 事件配置，属于双连接特有的问题；
• Msg3 收不到，问题在随机接入资源竞争或上行覆盖，属于信道质量问题。

如果把三层压成一个"接入成功率"，定位时就只能看到一个笼统的劣化，还得回头重跑一遍原始数据。拆开之后，哪一层掉了一眼就能看出来。这也是指标体系设计上的一条通用经验：能分开定位的失败点，就不要在指标层合并。

注意：NR 辅节点连接建立时延的定义是"从终端收到 RRC Connection Reconfiguration 消息，到成功接收 5G Msg3 消息"的时间差。它跨了两条信令链路，不能直接和 LTE 的接入时延做横向对比。

3.3 保持性分裂：用户感知不到的那次掉线

整套体系里最反直觉的一条，是原文注释里点明的事实：接入性下降用户感知不到，保持性下降用户也感知不到，但两者都会影响完整性，也就是速率和时延。原因在于 NSA 的分流结构：NR 辅节点释放后，LTE 锚点还在，业务不会断，只是从双连接退回单连接，速率从几百兆掉到几十兆。用户侧的体感是"网变慢了"，不是"网断了"。

所以保持性必须按 leg 拆开算。LTE 锚点掉线率卡在 ≤0.5%，这是真正的掉线，用户会看到业务中断；NR 数据业务掉线率卡在 ≤1.5%，这是"降级"，用户感知不到但速率会掉。两个门限相差三倍，反映的正是它们对体验的破坏程度不同。如果只看锚点掉线率，网络会显得非常健康，而实际上大量用户每天都在经历 NR leg 的反复释放与重建。

3.4 移动性的两跳：锚点切换与辅节点变更

移动性同样被拆成两条独立的路径。LTE 锚点切换走的还是 LTE 那套流程，验收卡 ≥99%；NR 辅节点切换则分同锚点和跨锚点两种，都卡 ≥98%。这两条路径的信令链路不同，任何一跳慢下来都会拖累体验，所以时延指标也分开定义：SN 变更的控制面平均时延要求 ≤20ms，从终端收到 RRC Connection Reconfiguration 开始，到向目标小区发出 RRC Connection Reconfiguration Complete 结束；用户面平均时延要求 ≤40ms，基于 PDCP 的数据包序号统计，下行看从收到源辅节点最后一个包到收到目标辅节点第一个包的间隔，上行反向计算。

用户面时延之所以用 PDCP SN 而不是时间戳，是因为它要回答的问题不是"信令走了多久"，而是"这条数据流断了多久"。序号连续性是业务连续性的直接证据，时间戳只能说明时刻差异。

4. 计数器落地：64 × pmMacVolDlDrb 这类公式到底在算什么

4.1 成功率的分子分母：pmEndcSetupUeAtt 与 pmEndcSetupUeSucc

话统侧最基础的两个计数器是pmEndcSetupUeAtt（ENDC 建立尝试次数）和pmEndcSetupUeSucc（ENDC 建立成功次数），eNB 侧和 gNB 侧各自维护一套，成功率都是100*(succ/att)。看起来简单，实际用起来有两个坑：一是分母为 0 的周期，很多报表工具会直接补 0，把无尝试的小区算成"成功率 0%"，一条曲线瞬间被拉低；二是两侧成功率含义不同，锚点侧失败意味着用户根本没进双连接，辅节点侧失败意味着用户进来了但没加上 NR，排查方向完全不同。

# 依据计数器原始定义还原几个常用 KPI，字段名沿用设备侧 pm* 前缀 # 实际字段以本地版本的话统字典为准，跨版本先核对定义再对比 def endc_setup_success_rate(att: int, succ: int) -> float: """EN-DC 建立成功率，分子分母必须来自同一采集周期""" if att == 0: return float("nan") # 无尝试周期记为 NaN，不要补 0，否则污染整网均值 return 100.0 * succ / att def ue_dl_avg_thp_kbps(vol_drb: int, time_drb: int) -> float: """小区内用户下行平均速率 vol_drb：DRB 上累计流量；time_drb：累计承载/调度时长 乘 64 是计数器粒度还原，除时长后单位为 kbps """ if time_drb == 0: return 0.0 return 64.0 * vol_drb / time_drb def cell_mac_dl_thp_kbps(vol_dl: int, sched_activity: int) -> float: """小区 MAC 层下行吞吐 分母是 PDSCH 调度活跃时长，不是墙钟时间 """ if sched_activity == 0: return 0.0 return 64.0 * vol_dl / sched_activity

参数说明只有一句但很关键：分母选谁，决定了这个指标在回答什么问题。pmMacTimeDlDrb统计的是承载存在的时间，算出来的是"用户实际拿到的速率"；pmPdschSchedActivity统计的是调度活跃时间，算出来的是"有数据要发的时候能跑多快"。后者天然高于前者，因为空闲期被剔除了。很多报表把这两个数放在一起做趋势对比，得出的"速率提升"其实是调度占比变化，不是真实体验改善。

至于那个 64，常见的实现思路是：MAC 层流量计数器以固定粒度累加（例如 64 的整数倍或 64bit 为步长），乘回 64 才能还原成 bit 量；如果某个版本的计数器本身就以 kbit 为单位，这个因子就不该出现。跨版本对齐数据前，先拿一个已知流量的小区反算一次，比看文档快。

4.2 无线质量不能只看均值：RANK 分布与编码方式比例

业务量和速率之外，体系里还专门列了无线质量这一组：PRB 利用率、上下行干扰、编码方式比例、RANK 比例。这几个指标的共同点是它们都是分布，不是均值。下行单流占比写成100*pmRadioUeRepRankDistr_0/(pmRadioUeRepRankDistr_0+...+pmRadioUeRepRankDistr_3)，两流占比取 Rank1 那一项，256QAM、64QAM、16QAM、QPSK、BPSK 的传输比例同理。

为什么必须看分布？因为平均速率上不去，可能是所有用户都慢一点，也可能是大部分用户很快、一小部分用户极慢。前者多半是容量或干扰问题，后者往往是覆盖边缘或个别小区的问题。单看均值这两个场景完全分不开，看 RANK 分布和调制阶数分布，一眼就能判断信道条件：单流占比高说明多径不够或 SNR 不足，高阶调制比例低说明信道质量撑不住。

def rank_ratio(distr: dict, rank: int) -> float: """distr 形如 {0: r0, 1: r1, 2: r2, 3: r3}，对应 Rank0~Rank3 上报次数""" total = sum(distr.values()) if total == 0: return float("nan") return 100.0 * distr.get(rank, 0) / total # 下行单流占比与两流占比是两条互补曲线， # 单流高 + 两流低 = 信道条件差；两条同时高说明小区内用户分层明显

4.3 用户数与流量：分子分母的口径决定结论

业务量这一组看着最无害，其实最容易出错。最大用户数取pmRrcConnLevelMaxEnDc，平均用户数写成pmRrcConnLevelSumEnDc / pmRrcConnLevelSamp，后者是采样点累加除以采样次数，本质上是时间加权平均。流量则统一按 MAC 层统计：(pmMacVolUl+pmMacVolDl)/8/1024/1024/1024，除 8 是把 bit 换成 Byte，再连除三次 1024 换成 GB。

问题出在"用户数"和"流量"不是同一时刻的口径：平均用户数是整个周期的平均，流量是周期累计。用累计流量除以平均用户数得到的"户均流量"，和真实单用户流量能差出几倍，因为忙时用户多、闲时用户少，两者被平均掉了。做容量规划时更可靠的做法是取忙时那一个小时的数据单独算。

4.4 时延类指标的边界定义

时延指标最难的不是算，是定边界。NR 辅节点连接建立时延的起点是"终端收到 RRC Connection Reconfiguration"，终点是"成功接收 5G Msg3"，中间跨了信令解析、随机接入前导发送、资源分配几个环节；SN 变更的控制面时延起终点则落在两条 RRC 消息之间。这些定义看似吹毛求疵，实际决定了指标能不能横向对比：起点差一个消息，数值可能差出十几毫秒。

PING 包这一类指标相对干净，成功率 ≥98%、平均时延 ≤40ms，包长固定 1500byte，从发出 Request 到收到 Reply 计时。它的价值在于跨层验证：如果空口 KPI 都很好但 PING 时延超标，问题多半在传输或核心网侧，不在无线。

5. 避坑与排查：指标对不上时先查这五处

5.1 三类根因：口径、样本、时间窗

指标对不上，九成情况出在这三处。口径指分子分母的定义，比如掉线率的分母写的是"成功完成连接建立次数"，那么建立失败的用户根本不计入掉线统计；样本指数据来源，路测样本和话统样本的权重完全不同，覆盖率按采样点算和按用户算能差出十几个百分点；时间窗指聚合周期，15 分钟粒度和小时粒度的曲线形态可能完全相反，短周期里的瞬时抖动会被长周期抹平。

排查顺序建议固定成：先确认口径一致，再确认样本范围一致，最后对齐时间窗。跳过前两步直接看时间窗，基本是白忙。

5.2 五条现场踩坑记录

坑一：覆盖率报表很漂亮，用户投诉没断过。现象是全网覆盖率稳定在 95% 以上，但边缘区域投诉集中。原因是覆盖率用的是 SS-RSRP≥-100dBm 且 SS-SINR≥0dB 的双门限，但 SSB 波束扫描会让 RSRP 读数偏高，覆盖看起来好而实际 SINR 跟不上。解决方式是把覆盖率与驻留比、速率达标率交叉看，三个指标同时达标才算真覆盖，单看一个一定会误判。

坑二：掉线率突然下降，其实是分母变小了。现象是某天掉线率从 1.2% 掉到 0.6%，全网欢呼。查下来是统计周期内有小区退服，业务接通次数被清洗掉一部分，分母缩水导致比率下降。解决办法是永远把尝试次数的绝对值一起看，比率和基数同时观察，只看比率等于给自己吃后悔药。

坑三：速率公式算出来比实测高一大截。现象是话统算出的小区下行速率 600Mbps，路测只能跑 400Mbps。原因是话统分母用的是 PDSCH 调度活跃时长，空闲期不计入，而路测跑的是端到端 PDCP 层速率，包含调度等待。两个指标本来就不同义，硬比没有意义。定位时应统一到 PDCP 层口径，或者明确区分"调度速率"和"体验速率"两个概念。

坑四：单站验证全过，簇优化一开就崩。现象是新站单站验证各项指标达标，并入簇之后切换成功率掉到 80% 以下。原因是单站验证是孤岛环境，邻区关系没配、PCI 冲突没暴露、切换压根没触发过。单站验证只该看接入和峰值速率这一类站内指标，切换、掉线这类多站耦合的指标必须留到簇优化阶段验证。

坑五：驻留比提上去了，速率和掉线率一起恶化。现象是实施锚点优先驻留策略后，5G 驻留比从 70% 提到 90%，但下行平均速率下降、NR 掉线率上升。原因是策略把边缘用户也强留在 NR 上，这些用户 SNR 本来就低，占着资源跑不动，还把掉线率带上去了。解决办法是给驻留策略加边缘门限，驻留比和覆盖率、速率达标率联合定标，不能单指标考核。

5.3 交叉验证的固定动作

每次指标异常，固定做三件事：一是把同一时间段的另一个口径数据拉出来对比，路测异常查话统、话统异常查路测；二是看关联指标是否同步变化，速率掉了要看 RANK 分布和调制阶数有没有跟着变；三是回到原始计数器，确认公式里每一个字段的取值都符合预期。这三步做完，绝大多数"玄学"波动都能落到具体原因上。

6. 复合指标的取舍：驻留比为什么没有唯一答案

5G 驻留比是整套体系里最像"人造指标"的一个，也是最能体现设计取舍的一个。它的定义是5G 网络驻留时长 / 总体测试时长，看上去毫无歧义，实际落地时至少有三套算法在并行：按测试时长算、按用户在线时长算、按有业务发生的时长算。三套算法在同一张网上能差出十个百分点，谁都不算错，取决于你想回答什么问题。

指标体系的应对方式是把它挂到"感知"这条主线上，用三层映射把复合指标拆回可观测的量：

这张表最关键的地方在于目标值之间的张力：驻留比定 95%，掉线率却容忍到 5%，这两个数字放在一起意味着体系默认接受"为了留在 5G 上，可以多掉一点线"。这不是拍脑袋，而是 NSA 架构下的必然选择：留在 5G 上哪怕降级，速率也比纯 LTE 高。但如果把这个逻辑推到极致，边缘用户全被强留，速率和掉线率会同步恶化，所以优化思路里同时列了锚点优先接入配置优化、锚点与 NR 邻区规划优化、5G 驻留问题精确定位三条线，互相牵制。

驻留比优化的另一个维度是终端能力。体系里明确区分了"有 5G 终端的 2G/4G 用户"和"5G 终端但未使用 5G 网络的用户"，前者是发展目标，后者是配置问题，处理手段完全不同：前者靠套餐引导，后者靠设置引导和客服触达。把这两类用户混在一个驻留比数字里，优化动作就会失焦。

我自己的习惯是，每次拿到一个新版本的 KPI 报表，先不看数值，先把每个指标的分子分母和采集周期在纸上写一遍，写完再对照数据。这个动作看起来笨，但帮我省掉了太多"指标突然变好"的假象——指标从来不会无缘无故变好，它只是在某个环节换了口径。希望帮到你。

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