尧图网站建设 
简介爱立信5G-KPI体系介绍是一份面向5G网络优化工程师、运营商运维人员及通信专业学习者的技术资料系统梳理了5G网络性能评估的量化指标体系。内容覆盖接入性、保持性、移动性、完整性等维度并区分NR NSA与NR SA两大类统计指标涉及NR Leg建立与释放、切换成功率、PRB利用率、上下行干扰、用户面时延、小区完好率等关键计数器。资料还结合单站验证、簇优化与全网优化三个层次说明路测KPI与网管性能指标的关注重点并给出不同时期NR终端发展期、成熟期NSA/SA的指标差异以及5G覆盖优化中SS-RSRP、SS-SINR、上下行平均速率、5G驻留时长占比等目标值参考。资源包为1个pptx文件约450KB以幻灯片形式呈现便于培训讲解与快速查阅。目前已有143人学习适合需要建立5G KPI整体认知、对照指标定义与验收要求的读者参考使用。1. 爱立信5G-KPI体系从NSA到SA一套指标怎么把网络问题钉死在坐标上NSA组网下用户投诉网速慢你登上EMIL页面一看NR小区的平均下行吞吐率明明有300Mbps可用户就是刷不动视频。问题出在哪答案往往藏在KPI的“定义域”里——爱立信5G-KPI体系不是一堆指标的简单堆砌而是一套从NSA双连接锚点、NR小区级、UE级到QoS流级的四层观测坐标系。它解决的核心问题是把“网络感觉不好”这种模糊描述翻译成可定位、可对比、可回溯的数字证据。这套体系适合谁日常跑EMIL、ENM或北向性能接口的网优工程师做5G基站gNB开通验收的集成人员以及需要从KPI反推参数配置是否合理的规划人员。你不需要背下所有计数器但必须理解每个KPI背后的测量点和触发条件否则就会像我当年一样拿着错的口径去怼核心网最后发现是自己没搞清NSA场景下Split Bearer的PDCP层统计归属。2. 爱立信5G-KPI的四层坐标系从NSA锚点到SA独立承载的指标映射2.1 NSA与SA下KPI统计对象的本质差异NSA架构里UE同时连接LTE锚点MeNB和NR辅节点SgNB用户面数据可以通过Split Bearer分流。爱立信的性能计数器在NSA场景下NR小区级吞吐率只统计经由NR的PDCP SDU字节数而LTE侧统计的是锚点承载部分。如果你直接拿NR小区下行吞吐率和SA组网下的同名字段对比数值会系统性偏低因为NSA下部分数据走了LTE。SA组网后NR成为唯一服务节点所有QoS Flow的PDCP层统计都归到NR小区此时KPI才真正反映NR空口能力。常见做法是在NSA验收阶段必须同时看E-UTRAN和NR两套计数器用Split Bearer流量占比做加权还原SA阶段则直接看NR小区级PDCP吞吐率。2.2 爱立信KPI的命名规则与计数器层级爱立信性能管理模型里KPI通常由多个PM计数器聚合而成。命名上常见前缀如pmRadioThrptDl、pmRadioThrptUl后缀区分小区级、UE级、QoS流级。以pmRadioThrptDl为例它统计的是NR小区下行PDCP SDU吞吐量单位kbps采样周期默认15分钟或5分钟。UE级计数器如pmUeThrptDl则按UE粒度聚合适合做用户感知分析。QoS流级计数器如pmQosFlowThrptDl用于5QI维度的业务质量监控。理解这些层级的关键是小区级看容量趋势UE级看用户分布QoS流级看业务质量。选型时如果你要做覆盖与容量联合优化小区级UE级足够如果要诊断VoNR或云游戏卡顿必须下钻到QoS流级。2.3 从OSS北向接口拉取KPI的实操步骤爱立信OSSENM/EMIL提供北向性能接口通常基于SOAP/XML或REST。以下是一个用Python通过SOAP接口拉取PM数据的简化示例实际地址和认证方式以你所在网络为准。# 爱立信OSS北向性能接口拉取PM计数器示例 # 依赖zeep (pip install zeep) from zeep import Client from zeep.transports import Transport from requests import Session from requests.auth import HTTPBasicAuth # OSS北向接口地址通常形如 https://enm-host:port/pm/ws wsdl https://enm.example.com:8443/pm/ws?wsdl session Session() session.auth HTTPBasicAuth(your_user, your_pass) session.verify False # 实验环境跳过证书校验生产环境务必开启 client Client(wsdl, transportTransport(sessionsession)) # 构造查询指定网元、计数器、时间范围 request { neName: NRCellDUCellA, pmCounters: [pmRadioThrptDl, pmRadioThrptUl, pmUeThrptDl], startTime: 2025-01-01T00:00:00, endTime: 2025-01-01T01:00:00, granularity: 5min } # 实际方法名以WSDL定义为准此处为示意 result client.service.getPmData(**request) for row in result: print(row.counterId, row.value, row.timestamp)逻辑说明先建立带认证的Session再通过zeep加载WSDL生成客户端。查询参数里neName指定网元对象pmCounters列出需要的计数器granularity决定采样粒度。参数说明startTime和endTime建议不超过24小时避免单次响应过大granularity常用5min或15min做实时优化用5min做日报用15min。失败时先看HTTP状态码401是认证问题500多半是网元名或计数器名写错。注意生产环境不要关闭证书校验实验环境可临时跳过。2.4 小区级与UE级KPI的聚合口径小区级KPI是UE级数据的聚合但聚合方式有坑。爱立信计数器里pmRadioThrptDl是小区内所有UE的PDCP SDU字节数总和除以统计周期而pmUeThrptDl是每个UE的平均吞吐率。如果你用UE级平均值去反推小区级会忽略UE数量变化的影响。正确做法是小区级吞吐率 总字节数 / 统计周期UE级平均吞吐率 总字节数 / 活跃UE数 / 统计周期。做容量规划时看小区级做用户感知投诉分析时看UE级分布尤其是5%分位值。常见误用是拿UE级平均值当小区级用导致扩容判断偏乐观。3. 爱立信5G-KPI核心指标拆解接入性、保持性、移动性、吞吐率3.1 接入性KPIRRC连接建立成功率与NG接口成功率接入性KPI反映UE能否顺利接入网络。核心计数器包括pmRrcConnEstabSucc、pmRrcConnEstabAtt以及NG接口的pmNgSigConnEstabSucc。RRC连接建立成功率 RRC建立成功次数 / RRC建立尝试次数。NSA场景下还要看SgNB添加成功率pmSgnbAddSucc和pmSgnbAddAtt。SA场景下NG接口成功率直接反映gNB与5GC之间的信令面健康度。参数设置上RRC建立尝试次数包含所有触发原因如mo-Signalling、mo-Data、mt-Access分析时要按原因拆分。如果mo-Data成功率低而mo-Signalling正常多半是无线覆盖或随机接入问题如果mt-Access成功率低检查寻呼容量和Paging DRX配置。3.2 保持性KPI掉线率与QoS Flow释放原因保持性KPI看掉线率和异常释放。爱立信计数器pmRrcConnRelAbnormal统计异常释放次数pmRrcConnRelNormal统计正常释放。掉线率 异常释放 / (异常释放 正常释放)。SA下还要关注QoS Flow释放原因pmQosFlowRelCause按原因分类常见原因有RadioConnectionWithUeLost、NgApCause等。如果RadioConnectionWithUeLost占比高说明空口链路失败查上行覆盖和干扰如果NgApCause高查核心网或NG接口传输。参数上掉线率统计周期内样本数太少时如小于100数值波动大建议至少观察24小时。3.3 移动性KPI切换成功率与Xn接口切换移动性KPI包括站内切换、Xn口切换、NG口切换成功率。爱立信计数器pmHoExeSucc、pmHoExeAtt按切换类型细分。切换成功率 切换执行成功 / 切换执行尝试。SA组网下Xn口切换是主流NG口切换用于Xn不可用场景。如果Xn口切换成功率低先查Xn传输链路和邻居关系如果NG口切换成功率低查AMF和NG接口。参数上切换尝试次数包含同频、异频、异系统分析时要过滤。常见坑是切换门限配置过晚导致UE来不及切换就掉线此时切换成功率可能正常但掉线率会升高。3.4 吞吐率KPI下行/上行PDCP吞吐率与调度效率吞吐率KPI是用户感知最直接的指标。爱立信计数器pmRadioThrptDl和pmRadioThrptUl统计PDCP SDU吞吐量。下行吞吐率受限于调度RB数、MCS、MIMO层数和BLER。上行吞吐率还受限于UE功率和PUSCH配置。分析时要结合pmRadioPrbUsedDlPRB利用率和pmRadioBlerDlBLER。如果PRB利用率高但吞吐率低查MCS和BLER如果PRB利用率低查调度策略和UE数量。参数上pmRadioThrptDl单位是kbps做对比时统一换算成Mbps。常见误用是拿峰值吞吐率当平均值忽略统计周期内的波动。4. 爱立信5G-KPI避坑与排查那些年我踩过的计数器口径坑4.1 坑一NSA下NR吞吐率偏低误判为NR覆盖问题现象NSA组网验收NR小区下行吞吐率只有150Mbps远低于理论值但RSRP和SINR都很好。原因NSA下Split Bearer分流部分数据走LTE锚点NR侧PDCP只统计经NR的字节数。解决同时拉取LTE侧吞吐率计算Split Bearer流量占比用总吞吐率评估NR能力。如果总吞吐率达标NR覆盖没问题只是统计口径问题。4.2 坑二RRC连接建立成功率突然下降实际是参数修改导致现象某小区RRC建立成功率从99%掉到85%无告警。原因前一天有人修改了preambleInitialReceivedTargetPower导致随机接入成功率下降进而影响RRC建立。解决查参数修改日志对比修改前后的pmRaSucc和pmRaAtt。如果随机接入成功率同步下降定位为参数问题。回退参数后恢复。4.3 坑三切换成功率正常但掉线率升高切换门限过晚现象切换成功率99%但掉线率从0.5%升到2%。原因切换门限如A3 Offset配置过大UE直到信号很差才触发切换切换成功后很快又掉线。解决查切换尝试次数和掉线时的RSRP如果掉线时RSRP低于-120dBm说明切换过晚。调整A3 Offset或TimeToTrigger提前切换。4.4 坑四QoS Flow释放原因统计为0实际是计数器未开启现象SA下想分析QoS Flow释放原因但pmQosFlowRelCause全为0。原因该计数器需要License或功能开关开启默认可能关闭。解决查OSS性能管理里该计数器的采集状态联系爱立信支持开启。开启后重新采集。4.5 坑五UE级吞吐率平均值正常但用户投诉网速慢现象UE级平均下行吞吐率200Mbps但部分用户投诉慢。原因平均值掩盖了分布5%分位值可能只有10Mbps。解决拉取UE级吞吐率分布看5%分位值和最差值。如果低分位值差查这些UE的RSRP、SINR和调度RB数定位是覆盖问题还是调度问题。5. 爱立信5G-KPI进阶用KPI反推参数与自动化监控5.1 用KPI趋势反推参数配置是否合理KPI不是孤立的数字趋势里藏着参数配置的线索。比如下行吞吐率在一天内周期性波动但PRB利用率平稳查MCS和BLER是否随温度或时间变化可能是外部干扰。再比如切换成功率在特定时间段下降查邻区关系是否漏配或者Xn链路是否拥塞。我一般会做一张KPI与参数的关联表把常见KPI异常映射到可能的参数集比如RRC建立成功率低映射到随机接入参数、切换成功率低映射到移动性参数、吞吐率低映射到调度和MIMO参数。这样排查时不用盲猜。5.2 基于Python的KPI自动化监控脚本框架手动拉KPI做日报效率低我一般写个脚本定时拉取并告警。以下是一个框架示例实际使用时替换OSS地址和计数器。# 爱立信KPI自动化监控框架示例 import schedule import time from zeep import Client from zeep.transports import Transport from requests import Session from requests.auth import HTTPBasicAuth # 阈值配置 THRESHOLDS { pmRrcConnEstabSuccRate: 0.98, # RRC建立成功率低于98%告警 pmHoExeSuccRate: 0.97, # 切换成功率低于97%告警 pmRadioThrptDl: 100000 # 下行吞吐率低于100Mbps告警 } def fetch_kpi(): session Session() session.auth HTTPBasicAuth(user, pass) session.verify False client Client(https://enm.example.com:8443/pm/ws?wsdl, transportTransport(sessionsession)) # 拉取最近5分钟数据 data client.service.getPmData( neNameNRCellDUCellA, pmCounters[pmRrcConnEstabSucc, pmRrcConnEstabAtt, pmHoExeSucc, pmHoExeAtt, pmRadioThrptDl], startTime2025-01-01T00:00:00, endTime2025-01-01T00:05:00, granularity5min ) return data def check_and_alert(): data fetch_kpi() # 计算成功率 rrc_succ sum(d.value for d in data if d.counterId pmRrcConnEstabSucc) rrc_att sum(d.value for d in data if d.counterId pmRrcConnEstabAtt) if rrc_att 0: rate rrc_succ / rrc_att if rate THRESHOLDS[pmRrcConnEstabSuccRate]: print(f告警RRC建立成功率 {rate:.2%} 低于阈值) # 吞吐率检查 thrpt [d.value for d in data if d.counterId pmRadioThrptDl] if thrpt and max(thrpt) THRESHOLDS[pmRadioThrptDl]: print(f告警下行吞吐率 {max(thrpt)} kbps 低于阈值) # 每5分钟执行一次 schedule.every(5).minutes.do(check_and_alert) while True: schedule.run_pending() time.sleep(1)逻辑说明脚本用schedule库定时触发fetch_kpi拉取指定计数器的5分钟粒度数据check_and_alert计算成功率并对比阈值。参数说明THRESHOLDS里的阈值根据网络基线调整新站可放宽成熟站收紧。失败时先看网络连通性和认证再看计数器名是否拼写正确。注意生产环境不要关闭证书校验脚本部署在OSS侧或跳板机上避免跨网段访问。5.3 KPI下钻分析的一个具体技巧从小区级到UE级当你发现小区级KPI异常时不要停在小区级。我一般按这个顺序下钻先看小区级吞吐率和PRB利用率判断是容量问题还是覆盖问题如果PRB利用率高但吞吐率低拉UE级吞吐率分布看是普遍低还是个别UE低如果个别UE低查这些UE的RSRP、SINR和调度RB数定位是远点用户还是干扰如果普遍低查MCS和BLER看是否调制编码策略保守或误块率高。这个下钻路径能帮你从“小区有问题”快速定位到“具体哪个UE、哪个参数、哪个原因”。我自己的习惯是每次处理投诉先拉UE级数据再回头看小区级这样不容易被平均值骗。希望帮到你。本文还有配套的精品资源点击获取 爱立信5G-KPI体系深度解析：从NSA到SA的指标映射与避坑指南
简介爱立信5G-KPI体系介绍是一份面向5G网络优化工程师、运营商运维人员及通信专业学习者的技术资料系统梳理了5G网络性能评估的量化指标体系。内容覆盖接入性、保持性、移动性、完整性等维度并区分NR NSA与NR SA两大类统计指标涉及NR Leg建立与释放、切换成功率、PRB利用率、上下行干扰、用户面时延、小区完好率等关键计数器。资料还结合单站验证、簇优化与全网优化三个层次说明路测KPI与网管性能指标的关注重点并给出不同时期NR终端发展期、成熟期NSA/SA的指标差异以及5G覆盖优化中SS-RSRP、SS-SINR、上下行平均速率、5G驻留时长占比等目标值参考。资源包为1个pptx文件约450KB以幻灯片形式呈现便于培训讲解与快速查阅。目前已有143人学习适合需要建立5G KPI整体认知、对照指标定义与验收要求的读者参考使用。1. 爱立信5G-KPI体系从NSA到SA一套指标怎么把网络问题钉死在坐标上NSA组网下用户投诉网速慢你登上EMIL页面一看NR小区的平均下行吞吐率明明有300Mbps可用户就是刷不动视频。问题出在哪答案往往藏在KPI的“定义域”里——爱立信5G-KPI体系不是一堆指标的简单堆砌而是一套从NSA双连接锚点、NR小区级、UE级到QoS流级的四层观测坐标系。它解决的核心问题是把“网络感觉不好”这种模糊描述翻译成可定位、可对比、可回溯的数字证据。这套体系适合谁日常跑EMIL、ENM或北向性能接口的网优工程师做5G基站gNB开通验收的集成人员以及需要从KPI反推参数配置是否合理的规划人员。你不需要背下所有计数器但必须理解每个KPI背后的测量点和触发条件否则就会像我当年一样拿着错的口径去怼核心网最后发现是自己没搞清NSA场景下Split Bearer的PDCP层统计归属。2. 爱立信5G-KPI的四层坐标系从NSA锚点到SA独立承载的指标映射2.1 NSA与SA下KPI统计对象的本质差异NSA架构里UE同时连接LTE锚点MeNB和NR辅节点SgNB用户面数据可以通过Split Bearer分流。爱立信的性能计数器在NSA场景下NR小区级吞吐率只统计经由NR的PDCP SDU字节数而LTE侧统计的是锚点承载部分。如果你直接拿NR小区下行吞吐率和SA组网下的同名字段对比数值会系统性偏低因为NSA下部分数据走了LTE。SA组网后NR成为唯一服务节点所有QoS Flow的PDCP层统计都归到NR小区此时KPI才真正反映NR空口能力。常见做法是在NSA验收阶段必须同时看E-UTRAN和NR两套计数器用Split Bearer流量占比做加权还原SA阶段则直接看NR小区级PDCP吞吐率。2.2 爱立信KPI的命名规则与计数器层级爱立信性能管理模型里KPI通常由多个PM计数器聚合而成。命名上常见前缀如pmRadioThrptDl、pmRadioThrptUl后缀区分小区级、UE级、QoS流级。以pmRadioThrptDl为例它统计的是NR小区下行PDCP SDU吞吐量单位kbps采样周期默认15分钟或5分钟。UE级计数器如pmUeThrptDl则按UE粒度聚合适合做用户感知分析。QoS流级计数器如pmQosFlowThrptDl用于5QI维度的业务质量监控。理解这些层级的关键是小区级看容量趋势UE级看用户分布QoS流级看业务质量。选型时如果你要做覆盖与容量联合优化小区级UE级足够如果要诊断VoNR或云游戏卡顿必须下钻到QoS流级。2.3 从OSS北向接口拉取KPI的实操步骤爱立信OSSENM/EMIL提供北向性能接口通常基于SOAP/XML或REST。以下是一个用Python通过SOAP接口拉取PM数据的简化示例实际地址和认证方式以你所在网络为准。# 爱立信OSS北向性能接口拉取PM计数器示例 # 依赖zeep (pip install zeep) from zeep import Client from zeep.transports import Transport from requests import Session from requests.auth import HTTPBasicAuth # OSS北向接口地址通常形如 https://enm-host:port/pm/ws wsdl https://enm.example.com:8443/pm/ws?wsdl session Session() session.auth HTTPBasicAuth(your_user, your_pass) session.verify False # 实验环境跳过证书校验生产环境务必开启 client Client(wsdl, transportTransport(sessionsession)) # 构造查询指定网元、计数器、时间范围 request { neName: NRCellDUCellA, pmCounters: [pmRadioThrptDl, pmRadioThrptUl, pmUeThrptDl], startTime: 2025-01-01T00:00:00, endTime: 2025-01-01T01:00:00, granularity: 5min } # 实际方法名以WSDL定义为准此处为示意 result client.service.getPmData(**request) for row in result: print(row.counterId, row.value, row.timestamp)逻辑说明先建立带认证的Session再通过zeep加载WSDL生成客户端。查询参数里neName指定网元对象pmCounters列出需要的计数器granularity决定采样粒度。参数说明startTime和endTime建议不超过24小时避免单次响应过大granularity常用5min或15min做实时优化用5min做日报用15min。失败时先看HTTP状态码401是认证问题500多半是网元名或计数器名写错。注意生产环境不要关闭证书校验实验环境可临时跳过。2.4 小区级与UE级KPI的聚合口径小区级KPI是UE级数据的聚合但聚合方式有坑。爱立信计数器里pmRadioThrptDl是小区内所有UE的PDCP SDU字节数总和除以统计周期而pmUeThrptDl是每个UE的平均吞吐率。如果你用UE级平均值去反推小区级会忽略UE数量变化的影响。正确做法是小区级吞吐率 总字节数 / 统计周期UE级平均吞吐率 总字节数 / 活跃UE数 / 统计周期。做容量规划时看小区级做用户感知投诉分析时看UE级分布尤其是5%分位值。常见误用是拿UE级平均值当小区级用导致扩容判断偏乐观。3. 爱立信5G-KPI核心指标拆解接入性、保持性、移动性、吞吐率3.1 接入性KPIRRC连接建立成功率与NG接口成功率接入性KPI反映UE能否顺利接入网络。核心计数器包括pmRrcConnEstabSucc、pmRrcConnEstabAtt以及NG接口的pmNgSigConnEstabSucc。RRC连接建立成功率 RRC建立成功次数 / RRC建立尝试次数。NSA场景下还要看SgNB添加成功率pmSgnbAddSucc和pmSgnbAddAtt。SA场景下NG接口成功率直接反映gNB与5GC之间的信令面健康度。参数设置上RRC建立尝试次数包含所有触发原因如mo-Signalling、mo-Data、mt-Access分析时要按原因拆分。如果mo-Data成功率低而mo-Signalling正常多半是无线覆盖或随机接入问题如果mt-Access成功率低检查寻呼容量和Paging DRX配置。3.2 保持性KPI掉线率与QoS Flow释放原因保持性KPI看掉线率和异常释放。爱立信计数器pmRrcConnRelAbnormal统计异常释放次数pmRrcConnRelNormal统计正常释放。掉线率 异常释放 / (异常释放 正常释放)。SA下还要关注QoS Flow释放原因pmQosFlowRelCause按原因分类常见原因有RadioConnectionWithUeLost、NgApCause等。如果RadioConnectionWithUeLost占比高说明空口链路失败查上行覆盖和干扰如果NgApCause高查核心网或NG接口传输。参数上掉线率统计周期内样本数太少时如小于100数值波动大建议至少观察24小时。3.3 移动性KPI切换成功率与Xn接口切换移动性KPI包括站内切换、Xn口切换、NG口切换成功率。爱立信计数器pmHoExeSucc、pmHoExeAtt按切换类型细分。切换成功率 切换执行成功 / 切换执行尝试。SA组网下Xn口切换是主流NG口切换用于Xn不可用场景。如果Xn口切换成功率低先查Xn传输链路和邻居关系如果NG口切换成功率低查AMF和NG接口。参数上切换尝试次数包含同频、异频、异系统分析时要过滤。常见坑是切换门限配置过晚导致UE来不及切换就掉线此时切换成功率可能正常但掉线率会升高。3.4 吞吐率KPI下行/上行PDCP吞吐率与调度效率吞吐率KPI是用户感知最直接的指标。爱立信计数器pmRadioThrptDl和pmRadioThrptUl统计PDCP SDU吞吐量。下行吞吐率受限于调度RB数、MCS、MIMO层数和BLER。上行吞吐率还受限于UE功率和PUSCH配置。分析时要结合pmRadioPrbUsedDlPRB利用率和pmRadioBlerDlBLER。如果PRB利用率高但吞吐率低查MCS和BLER如果PRB利用率低查调度策略和UE数量。参数上pmRadioThrptDl单位是kbps做对比时统一换算成Mbps。常见误用是拿峰值吞吐率当平均值忽略统计周期内的波动。4. 爱立信5G-KPI避坑与排查那些年我踩过的计数器口径坑4.1 坑一NSA下NR吞吐率偏低误判为NR覆盖问题现象NSA组网验收NR小区下行吞吐率只有150Mbps远低于理论值但RSRP和SINR都很好。原因NSA下Split Bearer分流部分数据走LTE锚点NR侧PDCP只统计经NR的字节数。解决同时拉取LTE侧吞吐率计算Split Bearer流量占比用总吞吐率评估NR能力。如果总吞吐率达标NR覆盖没问题只是统计口径问题。4.2 坑二RRC连接建立成功率突然下降实际是参数修改导致现象某小区RRC建立成功率从99%掉到85%无告警。原因前一天有人修改了preambleInitialReceivedTargetPower导致随机接入成功率下降进而影响RRC建立。解决查参数修改日志对比修改前后的pmRaSucc和pmRaAtt。如果随机接入成功率同步下降定位为参数问题。回退参数后恢复。4.3 坑三切换成功率正常但掉线率升高切换门限过晚现象切换成功率99%但掉线率从0.5%升到2%。原因切换门限如A3 Offset配置过大UE直到信号很差才触发切换切换成功后很快又掉线。解决查切换尝试次数和掉线时的RSRP如果掉线时RSRP低于-120dBm说明切换过晚。调整A3 Offset或TimeToTrigger提前切换。4.4 坑四QoS Flow释放原因统计为0实际是计数器未开启现象SA下想分析QoS Flow释放原因但pmQosFlowRelCause全为0。原因该计数器需要License或功能开关开启默认可能关闭。解决查OSS性能管理里该计数器的采集状态联系爱立信支持开启。开启后重新采集。4.5 坑五UE级吞吐率平均值正常但用户投诉网速慢现象UE级平均下行吞吐率200Mbps但部分用户投诉慢。原因平均值掩盖了分布5%分位值可能只有10Mbps。解决拉取UE级吞吐率分布看5%分位值和最差值。如果低分位值差查这些UE的RSRP、SINR和调度RB数定位是覆盖问题还是调度问题。5. 爱立信5G-KPI进阶用KPI反推参数与自动化监控5.1 用KPI趋势反推参数配置是否合理KPI不是孤立的数字趋势里藏着参数配置的线索。比如下行吞吐率在一天内周期性波动但PRB利用率平稳查MCS和BLER是否随温度或时间变化可能是外部干扰。再比如切换成功率在特定时间段下降查邻区关系是否漏配或者Xn链路是否拥塞。我一般会做一张KPI与参数的关联表把常见KPI异常映射到可能的参数集比如RRC建立成功率低映射到随机接入参数、切换成功率低映射到移动性参数、吞吐率低映射到调度和MIMO参数。这样排查时不用盲猜。5.2 基于Python的KPI自动化监控脚本框架手动拉KPI做日报效率低我一般写个脚本定时拉取并告警。以下是一个框架示例实际使用时替换OSS地址和计数器。# 爱立信KPI自动化监控框架示例 import schedule import time from zeep import Client from zeep.transports import Transport from requests import Session from requests.auth import HTTPBasicAuth # 阈值配置 THRESHOLDS { pmRrcConnEstabSuccRate: 0.98, # RRC建立成功率低于98%告警 pmHoExeSuccRate: 0.97, # 切换成功率低于97%告警 pmRadioThrptDl: 100000 # 下行吞吐率低于100Mbps告警 } def fetch_kpi(): session Session() session.auth HTTPBasicAuth(user, pass) session.verify False client Client(https://enm.example.com:8443/pm/ws?wsdl, transportTransport(sessionsession)) # 拉取最近5分钟数据 data client.service.getPmData( neNameNRCellDUCellA, pmCounters[pmRrcConnEstabSucc, pmRrcConnEstabAtt, pmHoExeSucc, pmHoExeAtt, pmRadioThrptDl], startTime2025-01-01T00:00:00, endTime2025-01-01T00:05:00, granularity5min ) return data def check_and_alert(): data fetch_kpi() # 计算成功率 rrc_succ sum(d.value for d in data if d.counterId pmRrcConnEstabSucc) rrc_att sum(d.value for d in data if d.counterId pmRrcConnEstabAtt) if rrc_att 0: rate rrc_succ / rrc_att if rate THRESHOLDS[pmRrcConnEstabSuccRate]: print(f告警RRC建立成功率 {rate:.2%} 低于阈值) # 吞吐率检查 thrpt [d.value for d in data if d.counterId pmRadioThrptDl] if thrpt and max(thrpt) THRESHOLDS[pmRadioThrptDl]: print(f告警下行吞吐率 {max(thrpt)} kbps 低于阈值) # 每5分钟执行一次 schedule.every(5).minutes.do(check_and_alert) while True: schedule.run_pending() time.sleep(1)逻辑说明脚本用schedule库定时触发fetch_kpi拉取指定计数器的5分钟粒度数据check_and_alert计算成功率并对比阈值。参数说明THRESHOLDS里的阈值根据网络基线调整新站可放宽成熟站收紧。失败时先看网络连通性和认证再看计数器名是否拼写正确。注意生产环境不要关闭证书校验脚本部署在OSS侧或跳板机上避免跨网段访问。5.3 KPI下钻分析的一个具体技巧从小区级到UE级当你发现小区级KPI异常时不要停在小区级。我一般按这个顺序下钻先看小区级吞吐率和PRB利用率判断是容量问题还是覆盖问题如果PRB利用率高但吞吐率低拉UE级吞吐率分布看是普遍低还是个别UE低如果个别UE低查这些UE的RSRP、SINR和调度RB数定位是远点用户还是干扰如果普遍低查MCS和BLER看是否调制编码策略保守或误块率高。这个下钻路径能帮你从“小区有问题”快速定位到“具体哪个UE、哪个参数、哪个原因”。我自己的习惯是每次处理投诉先拉UE级数据再回头看小区级这样不容易被平均值骗。希望帮到你。本文还有配套的精品资源点击获取