好的,我们继续进行系列的下一篇深度解读。
深度解析 3GPP TS 28.552:5.1.1.18 & 5.1.1.19 RRC Connection Resuming & PEE Measurements (休眠唤醒与绿色节能)
本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中,关于“5.1.1.18 RRC Connection Resuming”和“5.1.1.19 Power, Energy and Environmental (PEE) measurements”的核心章节,旨在为读者提供一个关于5G网络能效管理与连接恢复效率的性能测量全景解析。
引言:智慧水表的“马拉松”与网络的“节能之道”
在城市的物联网示范区,数以万计的智能水表“水滴-5G”被部署在各个角落。它们的任务很简单:每天凌晨3点准时“醒来”,连接到5G网络,上报一天的数据,然后再次“沉睡”。对于这些依靠电池供电、设计寿命长达十年的设备来说,每一次“醒来”和“沉睡”的功耗,都直接关系到它们能否跑完这场“生命马拉松”。
“王哥,物联网公司那边反馈,我们网络下的一部分水表,电池消耗速度比预期的要快一倍,可能撑不到十年。”小林拿着一份告警报告,向导师老王请教,“我们怎么才能知道,是水表自己的问题,还是我们的网络配置不够节能?”
老王指着监控大屏上一组平时不太引人注意的图表:“小林,5G不仅要快,更要‘绿’。尤其是在万物互联的时代,为海量终端提供低功耗的连接,是我们网络的一项核心能力。要诊断‘水滴-5G’的‘续航’问题,我们需要从两个方面入手:第一,它的‘休眠-唤醒’过程是否高效?第二,支撑它的基站自身是否足够节能?”
他将TS 28.552的屏幕切换到5.1.1.18和5.1.1.19节。“RRC Connection Resuming(RRC连接恢复),就是衡量‘水滴-5G’从RRC Inactive这种‘浅睡眠’状态被唤醒的效率。而PEE Measurements(功耗、能源和环境测量),则是对我们基站自身的‘电费账单’和‘健康体检报告’进行的一次全面审计。今天,我们就化身‘能效审计师’,通过这两节的内容,来揭示5G网络的‘绿色密码’。”
1. “一秒唤醒”的承诺:RRC Connection Resuming (5.1.1.18)
RRC Inactive状态是5G为物联网等需要频繁、快速收发小包数据的业务设计的“法宝”。它允许UE在释放无线连接的同时,在gNB和AMF保留其核心上下文,从而在下次需要通信时,跳过复杂的信令流程,实现“秒级”恢复。
“水滴-5G”每天凌晨的上报,就是一次典型的“休眠-唤醒”过程。
1.1 “唤醒”的尝试与结果:attempts, successful, failed (5.1.1.18.1 - 5.1.1.18.3)
这个测量体系与我们上一章学习的RRC连接重建(Re-establishment)在逻辑上高度一致,但触发场景完全不同。
1.1.1 尝试唤醒:Number of RRC connection resuming attempts (5.1.1.18.1)
a) This measurement provides the number of RRC connection resuming attempts. c) On Receipt of the RRCResumeRequest message or RRCResumeRequest1 from UE.Each RRCResumeRequest is added to the relevant subcounter per resume cause. e) The measurement name has the form RRC.ResumeAtt.cause
-
深度解析:
RRC.ResumeAtt(Resume Attempt) 的触发点是gNB收到了UE发来的RRCResumeRequest消息。这是UE从Inactive状态发出的“我醒了,我要恢复连接”的信号。与RRC建立类似,它也按**resume cause**进行细分,原因包括mt-Access(被网络寻呼唤醒)、mo-Signalling(主动上报信令)、mo-Data(主动上报数据)等。 -
场景化举例: 凌晨3点整,gNB通过RAN Paging唤醒了“水滴-5G”。“水滴-5G”立刻发送了
RRCResumeRequest (cause=mt-Access)。此时,基站的RRC.ResumeAtt.cause_mt-Access子计数器加1。这个指标的总和,反映了网络中Inactive用户的活跃程度。
1.1.2 完美唤醒:Successful RRC connection resuming (5.1.1.18.2)
c) On Receipt of a RRCResumeComplete message from UE for RRC connection resuming. e) The measurement name has the form RRC.ResumeSucc.cause
- 深度解析:
这是最理想的唤醒流程。gNB成功找到了UE的上下文,通过简单的信令交互就恢复了连接。成功的标志是gNB收到了UE回复的
RRCResumeComplete消息。RRC.ResumeSucc计数器同样按cause细分,用于计算分业务的恢复成功率。
1.1.3 降级后成功:Successful RRC connection resuming with fallback (5.1.1.18.3)
c) On Receipt of a RRCSetupComplete message from UE for RRC connection resuming by fallback to RRC connection establishment. e) The measurement name has the form RRC.ResumeSuccByFallback.cause.
- 深度解析:
这是唤醒失败后的“B计划”。当gNB收到
RRCResumeRequest,却因为种种原因(如UE上下文丢失、UE移动到了新的RAN通知区域)找不到该UE的“档案”时,它无法快速恢复连接。此时,gNB会将流程降级(fallback) 为一次全新的RRC连接建立,向UE发送RRCSetup。如果这次新建流程最终成功了(收到RRCSetupComplete),RRC.ResumeSuccByFallback计数器就会加1。
1.1.4 场景化诊断:“水滴-5G”的“续航”之谜
小林调取了物联网专区的网络数据,他要计算RRC恢复成功率:
RRC Resume Success Rate = (RRC.ResumeSucc / RRC.ResumeAtt) * 100%
他发现,这个成功率高达99.9%,说明绝大部分唤醒都是完美的。但他接着查看了RRC.ResumeSuccByFallback的计数,发现虽然绝对值不高,但在凌晨3点这个时间点有规律地出现。
“王哥,这意味着有一小部分水表,在唤醒时经历了‘降级’,走了更耗时、更耗电的完整RRC建立流程!”小林找到了线索。
老王进一步分析:“这很可能是因为我们的RAN通知区域(RNA)配置得太小了。有些水表可能被安装在了两个RNA的交界处,信号的微弱漂移就导致它跑到了gNB不认识的新区域,恢复时自然就找不到上下文了。每一次降级,都意味着额外的信令交互和更长的无线信号发射时间,对水表的电池都是一次额外的损耗。”
洞察: RRC连接恢复的测量体系,不仅能评估Inactive功能的整体成功率,更能通过对“降级成功”这种次优场景的监控,精准地发现网络配置(如RNA范围)中可能存在的问题,从而指导优化,为海量物联网终端节省宝贵的电量。
2. 基站的“体检报告”:PEE Measurements (5.1.1.19)
解决了终端侧的能效问题,老王将目光转向了基站自身。“小林,运营一张网络,电费是巨大的成本。降低基站的功耗,是我们‘绿色5G’的另一个重要课题。5.1.1.19节,就是我们给基站做的‘体检’,看看它的‘新陈代谢’是否健康。”
PEE (Power, Energy and Environmental) 测量,是针对物理网络功能(PNF),即硬件基站设备的一组测量。
2.1 核心能耗指标:功耗与能耗
5.1.1.19.2 PNF Power Consumption (PNF功耗)
- 5.1.1.19.2.1
Average Power(PEE.AvgPower)- 5.1.1.19.2.2
Minimum Power(PEE.MinPower)- 5.1.1.19.2.3
Maximum Power(PEE.MaxPower) a) This measurement provides the average/minimum/maximum power consumed over the measurement period.
5.1.1.19.3 PNF Energy consumption (PNF能耗) a) This measurement provides the energy consumed. e) The measurement name has the form PEE.Energy
-
深度解析: 这组指标是基站能效管理的基础。
- 功耗 (Power): 单位是瓦特 (W),反映的是某一时刻设备消耗能量的速率。
AvgPower是平均功耗,MinPower是空闲时的基础功耗,MaxPower是满负荷时的峰值功耗。 - 能耗 (Energy): 单位是千瓦时 (kWh),即我们常说的“度”。它是在一段时间内消耗能量的总量,是运营商最终要付给电力公司的真金白银。
PEE.Energy = PEE.AvgPower * 测量时长。
- 功耗 (Power): 单位是瓦特 (W),反映的是某一时刻设备消耗能量的速率。
-
场景化应用:评估节能特性效果 现代基站都具备多种节能技术,如符号关断、通道关断、深度休眠等。通过对比开启和关闭这些功能前后,
PEE.AvgPower和PEE.Energy的变化,运营商可以量化评估每项节能技术的真实效果。例如,小林发现,在凌晨业务量极低时,开启“深度休眠”功能后,PEE.MinPower从200W降低到了50W,PEE.Energy的小时读数也显著下降,证明了节能策略的有效性。
2.2 运行环境监控:温度、电压、电流、湿度
5.1.1.19.4 PNF Temperature (PNF温度) 5.1.1.19.5 PNF Voltage (PNF电压) 5.1.1.19.6 PNF Current (PNF电流) 5.1.1.19.7 PNF Humidity (PNF湿度)
-
深度解析: 这组测量是基站的“生命体征”监控。它们虽然不直接反映通信性能,但对设备的稳定性和寿命至关重要。
- 温度 (Temperature):
PEE.AvgTemperature,PEE.MinTemperature,PEE.MaxTemperature。过高的温度是电子设备的第一杀手,会严重影响设备性能和寿命。监控温度峰值,可以及时发现散热系统(如风扇、空调)的故障。 - 电压 (Voltage)、电流 (Current): 监控供电系统的稳定性。异常的波动可能预示着电源模块或外部电网的问题。
- 湿度 (Humidity):
PEE.Humidity。过高的湿度可能导致设备内部短路和腐蚀。
- 温度 (Temperature):
-
场景化应用:预测性维护 老王的团队利用AI平台,对这些PEE数据进行长期趋势分析。他们发现,某个站点的
PEE.AvgTemperature在过去三个月里,即使在相同的负载和外部气温下,也呈现出缓慢上升的趋势。 “小林,你看这个趋势,”老王指出,“这很可能意味着这个基站的散热风扇积了太多灰尘,或者风扇轴承开始老化,散热效率在下降。我们可以在它彻底过热告警之前,就派发一个‘预测性维护’工单,让维护人员去现场进行清洁或更换。这就是从‘被动救火’到‘主动预防’的转变。”
结论:效率与能耗——5G网络的两翼
通过对“水滴-5G”续航问题和基站自身能耗的深入探究,我们掌握了5G网络“绿色”性能的两大测量维度:
- 连接恢复效率 (
RRC.Resume测量): 它量化了5G Inactive模式的性能,是保障海量物联网终端“长效续航”和“快速响应”的关键。通过分析其成功率与Fallback率,可以指导网络配置的精细化优化。 - 网络基础设施能效 (PEE测量): 它提供了对基站功耗、能耗和运行环境的全面监控,是运营商实现“降本增效”、迈向“绿色5G”的基础数据。更重要的是,通过对这些环境数据的长期趋势分析,可以实现从“故障后维修”到“故障前预测”的智慧运维转型。
这两组测量,一个面向终端,一个面向网络自身,共同构成了5G能效管理的完整闭环。它们确保了5G网络在追求极致性能的同时,也能以更经济、更环保、更可持续的方式运行。
FAQ 环节
Q1:RRC连接恢复(Resuming)失败并降级(Fallback)到RRC新建,对物联网终端的功耗影响有多大? A1:影响非常显著。一次成功的RRC恢复,通常只涉及几条简短的RRC信令交互,整个过程UE的射频发射时间可能只有几十毫秒。而一次完整的RRC新建,则需要经历随机接入、RRC三步握手、安全模式协商、能力上报、核心网信令交互等一系列复杂流程,UE的射频发射总时长可能会增加数倍甚至一个数量级。对于一天只通信一次的智能水表来说,如果每次唤醒都是“降级”,其电池寿命可能会从十年缩短到两三年。
Q2:PEE测量中的功耗(Power)和能耗(Energy)有什么区别?为什么需要同时监控两者? A2:功耗 (Power) 是一个瞬时或平均速率的概念(单位:瓦),它告诉你设备“此刻”或“平均”消耗能量有多快。能耗 (Energy) 是一个总量的概念(单位:千瓦时/度),它告诉你设备在一段时间内总共消耗了多少能量。同时监控两者至关重要:
- 功耗用于性能分析和故障诊断。例如,
MaxPower可以验证设备是否达到了其设计的最大功耗,MinPower可以评估节能功能的深度。 - 能耗用于成本核算和能效评估。
Energy是运营商需要支付电费的直接依据。通过Energy除以同期的Data Volume(数据量),可以计算出网络的核心能效指标——“每比特能耗”,用于横向比较不同设备、不同技术的能效水平。
Q3:基站温度的测量,在实际运维中有什么特别的应用吗?
A3:有非常重要的应用,尤其是在节能和硬件故障诊断方面。1)智能温控节能: 许多机房的空调系统会与基站的温度监控联动。在业务低谷期,如果基站温度不高,可以适当调高空调温度或降低风扇转速,从而节省大量的辅助设备能耗。2)故障关联分析: 当一个小区出现吞吐率下降、掉线率升高等性能问题时,如果同时观察到该小区的PEE.MaxTemperature异常升高,那么问题很可能出在射频单元(RRU)的过热降额上。过热的RRU会自动降低发射功率以自我保护,从而导致无线性能下降。
Q4:为什么规范将RRC重建(Re-establishment)和RRC恢复(Resuming)的失败都设计了一个“降级后成功”的测量项?
A4:这是为了提供一个更完整的连接恢复能力漏斗模型。以恢复为例,总的恢复请求是ResumeAtt。其中一部分ResumeSucc完美成功了。剩下失败的里面,又有一部分通过降级到RRC新建,最终ResumeSuccByFallback也成功了。这样,运维人员就可以清晰地看到:总共有多少请求?有多少是“优等生”?有多少是“补考生”?还有多少是彻底“挂科”的?这个漏斗模型,比一个简单的总成功率,能提供更丰富的诊断信息,帮助我们判断问题是出在“快速恢复”这个环节,还是出在更基础的“连接建立”环节。
Q5:这些PEE测量数据是如何采集的?是由基站自己上报的吗? A5:是的,这些PEE测量数据是由支持相关功能的物理网络功能(PNF),即硬件基站设备,通过内置的传感器采集,然后通过标准的管理接口向网管系统(OAM)上报的。根据ETSI的相关标准(如ETSI ES 202 336),现代通信设备都应具备对功耗、温度等关键环境参数的监控能力。3GPP TS 28.552则将这些能力标准化为性能测量项,纳入到统一的5G性能管理框架中。