51学通信

深度解析 3GPP TS 38.509：5.11-5.13 高级资源管理 (功率极限、结果汇报与多卡协同)

21分钟阅读

深度解析 3GPP TS 38.509：5.11-5.13 高级资源管理 (功率极限、结果汇报与多卡协同)

本文技术原理深度参考了3GPP TS 38.509 V18.0.0 (2025-06) Release 18规范中，关于“5.11 UE Power Limit Function (UPLF)”、“5.12 MBMS Packet Counter reporting procedure”和“5.13 Set MUSIM UAI test function”的核心章节。本文将这些高级控制功能进行整合解读，旨在为读者揭示5G终端在极限条件下进行自我资源管理的深层机制。

引言：从极限体能到智慧自律

在之前的“毕业大考”中，我们的主角“小五”手机已经向考官（SS）证明了其全面的作战能力。无论是数据面的狂飙，还是物理层的精准操控，亦或是对测试环境的“清扫”与“设定”，它都表现得无可挑剔。

“李工，‘小五’的基础科目和专业技能看起来都达标了。接下来还有什么更高难度的挑战在等着它吗？”工程师小王的好奇心愈发浓厚。

“当然，”资深专家李工的表情变得严肃起来，“之前的考验，好比是让一名士兵在资源充足的情况下完成任务。但真正的精英，不仅要在顺境中表现出色，更要在资源受限的极限压力下，展现出卓越的自我管理和智慧协同能力。今天，‘小五’将迎来三场高级资源管理能力的终极考验：”

  1. 5.11 功率极限功能 (UPLF) - 极限冲刺中的“内力”调配： 在毫米波上行载波聚合的极限速度下，当总“燃料”（发射功率）有限时，“小五”必须学会如何智能地为两个“引擎”（主载波和辅载波）分配动力，这考验的是它的功率自律能力。
  2. 5.12 MBS计数器上报 - 考后的“答卷”提交（短章节合并解读）： 在完成了模式C的“广播听力大赛”后，“小五”需要按照规定，准确无误地将“答卷”（计数值）上交。这是一个简短但关键的流程，考验的是它的结果汇报准确性。
  3. 5.13 多卡协同功能 (MUSIM UAI) - 一心二用的“分身术”： 作为一部支持多SIM卡的手机，“小五”必须学会在为一张卡通话上网的同时，兼顾另一张卡的来电。这需要在性能和可用性之间做出艰难的权衡，考验的是它的多任务协同智慧。

1. 5.11 UE Power Limit Function (UPLF) - 功率自律的艺术

“想象一下，”李工打了个比方，“一辆拥有主引擎（PCell）和涡轮增压器（SCell）的赛车。它的总油箱容量是固定的。在直道上，为了跑出最快速度，它需要同时开启两个引擎。但如果涡轮增压器太‘贪吃’，耗尽了所有燃料，导致主引擎熄火，赛车就会失控。UPLF测试，就是要验证‘小五’是否是这样一位懂得精妙控制油门的‘老司机’。”

1.1 5.11.1 General - 为何需要功率极限控制

The UE Power Limit Function is intended for the SS to communicate to the UE to apply a backoff of transmitted power on the NR primary component carrier when in FR2 carrier aggregation mode. On activation of this test function, the UE shall apply a configured power backoff on the primary component carrier to provide sufficient power head room for the other (secondary) component carrier(s).

这段话点明了UPLF的核心目的：在毫米波（FR2）上行载波聚合（UL CA）时，UE的总发射功率受到严格限制。为了确保辅载波（SCell）有足够的功率可用，不至于因为主载波（PCell）“用力过猛”而被“饿死”，SS可以通过UPLF功能，命令UE主动地、有控制地降低主载波的发射功率（apply a backoff）。

The UE power limit function is mandatory for applicable UEs operating in Frequency Range 2 (FR2) and supporting UL CA from Rel-16.

“对于所有支持FR2上行载波聚合的Rel-16及以后版本的UE，这项‘自我克制’的能力是强制性的。”

1.2 5.11.2 Activate Power Limit Procedure - 如何施加“功率契约”

我们来看考官SS是如何与“小五”签订这份“功率分配契约”的。

参考规范中的 “Figure 5.11.1-1: Activate Power Limit test mode procedure”，这是一个简单的“请求-响应”流程。

5.11.2.2 Reception of ACTIVATE POWER LIMIT REQUEST by UE When the UE receives the ACTIVATE POWER LIMIT REQUEST message, then the UE shall: 1> if the UE is operating in FR2 AND is in RRC_CONNECTED state: 2> UE limits power on PCell according to a back-off defined by Xmax,PCell.

“契约”生效的条件依然是FR2和RRC连接态。核心动作是，“小五”必须根据REQUEST消息中携带的Xmax,PCell值，来限制其主载波的功率。

这个Xmax,PCell是如何定义的呢？答案藏在第六章的消息定义中。ACTIVATE POWER LIMIT REQUEST消息（6.11.1节）会携带两个关键信息：TOTAL NR AGGREGATED BANDWIDTH（聚合总带宽）和PCELL NR BANDWIDTH（主载波带宽）。根据规范在6.2节的公式，Xmax,PCell的计算方式是：

Xmax,PCell = 10 * log10(聚合总带宽 / 主载波带宽)

场景推演： 假设考官SS为“小五”配置了FR2上行载波聚合，PCell和SCell的带宽都是100MHz，聚合总带宽为200MHz。

  1. SS发送ACTIVATE POWER LIMIT REQUEST消息，其中TOTAL NR AGGREGATED BANDWIDTH字段编码为200MHz，PCELL NR BANDWIDTH字段编码为100MHz。
  2. “小五”收到后，计算Xmax,PCell = 10 * log10(200 / 100) = 10 * log10(2) ≈ 3dB。
  3. 这意味着，“小五”必须将其主载波（PCell）的最大发射功率，从其能力上限（PCMAX,f,c）降低3dB。
  4. 这降低的3dB功率余量（Power Headroom），就可以被动态地分配给辅载波（SCell）使用，从而保证了在总功率受限的情况下，两个载波都能健康工作，达到载波聚合提升吞吐量的目的。

1.3 5.11.3 Deactivate Power Limit Procedure - 解除“契约”与安全保障

测试完成后，需要解除功率限制。DEACTIVATE POWER LIMIT REQUEST的流程与激活类似。但同样，规范也为UPLF设计了强大的“安全保障”机制。

5.11.3.3 Removal of power limits by UE When the UE leaves the RRC_CONNECTED state, the UE shall: 1> if the UE is operating in FR2 AND the UE Power limit test Function is active 2> remove UE power limit on PCell;

“这条规则与波束锁定的自动解除如出一辙，是鲁棒性设计的典范。”李工强调，“如果‘小五’在功率受限的状态下意外掉线，它必须在下次尝试接入网络前，自动清除这个功率限制。否则，一个带着‘自我封印’的UE去入网，其发射功率会低于正常水平，可能导致接入失败。这项自动解除机制，确保了UE在任何时候都能以其最强的‘嗓门’去呼叫网络。”

2. 5.12 MBMS Packet Counter reporting procedure - 提交广播听力“答卷”

在紧张的功率管理测试之后，我们迎来一个轻松但必要的环节。

Same as TS 36.509, subclause 5.6 with the following exception:

  • MBMS Packet is replaced by MBS Packet

“这个章节非常短，因为它只做一件事：为我们之前在Mode C中学到的‘广播计数’功能，提供一个官方的‘交卷’渠道。”李工解释道。

“我们回顾一下，在Mode C测试中，‘小五’的任务是默默地对接收到的MBS广播包进行计数。但当时我们留下一个疑问：考官SS如何知道计数值是多少？5.12节就回答了这个问题。它定义了一个Request MBMS Packet Counter value的流程（实际上在5G中应理解为MBS）。SS通过这个流程，正式向‘小五’索要‘听力大赛’的成绩单。‘小五’则会将内部存储的MBMS_PACKET_COUNTER的值上报给SS。”

“这里的唯一例外，再次体现了技术的演进：将4G时代的术语MBMS（多媒体广播多播业务）更新为5G时代的MBS（多播广播业务）。”

3. 5.13 Set MUSIM UAI test function - 多卡协同的“分身术”

最后一项考验，进入了现代手机一个非常普遍但技术上极其复杂的领域——多卡支持（MUSIM, Multi-USIM）。

3.1 5.13.1 General - 一心二用的困境

“‘小五’支持双卡双待。当卡1正在进行高速数据下载时，卡2突然来了一个电话，怎么办？”李工抛出了MUSIM的核心矛盾，“为了能及时听到卡2的来电（寻呼Paging），‘小五’必须定期地从卡1的数据传输中‘开小差’，腾出它的接收机去监听卡2的寻呼信道。这个‘开小差’的时间，就叫做测量/监听间隙 (Gap)。”

“这个Gap带来了根本性的冲突：

  • 如果不创建Gap： 卡1的数据传输性能可以达到最大化，但可能会漏掉卡2的来电。
  • 如果创建Gap： 能保证卡2的可用性，但会频繁中断卡1的数据流，导致吞吐率下降和时延增加。”

“UE会根据自己的实现和用户设置，形成一种对Gap的‘偏好’（Preference），并通过UAI上报给网络。但测试时，我们需要验证这两种极端情况下的性能。于是，Set MUSIM UAI功能就诞生了。”

3.2 5.13.3 Reception of SET MUSIM UAI REQUEST message by UE - 设定“多任务”策略

SS通过SET MUSIM UAI REQUEST消息，可以像一位心理导师一样，为“小五”设定它在多任务处理中的“行事风格”。

1> if the MUSIM UE is operating in RRC_CONNECTED state: 2> set its preferred RRC state within the release preference, to the equivalent value as received in the musim-PreferredRRC-State-r17 … 1> if the UE has a preference for MUSIM periodic gap(s): 2> set its preferred gap preference, to the equivalent value as received in the musim-GapPreferenceList …

“考官可以设定两种关键的‘性格’：”

  1. 设定RRC状态偏好 (musim-PreferredRRC-State): 这与我们之前在5.8节学到的类似，但它是在MUSIM的场景下。考官可以命令“小五”：“在处理多卡任务时，你要表现得更‘激进’（偏好CONNECTED），以保证性能；或者更‘保守’（偏好IDLE），以保证兼顾。”

  2. 设定Gap偏好 (musim-GapPreferenceList): 这是MUSIM测试的核心。SS可以直接告诉“小五”：“我命令你，现在你偏好创建Gap”，或者“现在你偏好不创建Gap”。

    • 测试场景一（性能优先）： SS设定“不偏好Gap”，然后进行吞吐量测试，验证“小五”在无中断情况下的最大数据性能。
    • 测试场景二（可用性优先）： SS设定“偏好Gap”，然后SS在卡1传输数据的同时，在卡2的寻呼信道上发送寻呼消息，验证“小五”是否能成功创建Gap并接收到这个寻呼。

这个musim-GapPreferenceList参数的结构在6.13节中有详细定义，它包含了Gap的起始时间（SFN, subframe）、长度（length）、重复周期（repetition period）等一系列精细化的信息，使得SS可以构建出极其复杂的Gap模式，全面地考验UE的MUSIM调度能力。

总结：从“硬实力”到“软智慧”

“今天的三项大考，标志着对‘小五’的考核，已经从单纯的‘硬实力’（速度、力量），上升到了考验‘软智慧’（自律、协同、权衡）的全新高度。”李工总结道。

我们掌握了三项高级资源管理功能：

  1. UPLF (功率极限功能): 在FR2 UL CA场景下，通过主动降低主载波功率（Backoff），为辅载波预留功率空间，是保证极限性能下系统稳定性的关键自律机制。
  2. MBS计数器上报: 作为Mode C测试的闭环，它提供了一个标准化的结果汇报流程，是保证测试流程完整性的“最后一公里”。
  3. MUSIM UAI设定: 通过让SS强制设定UE对Gap的偏好，解决了MUSIM测试中性能与可用性不可兼得的矛盾，实现了对多卡协同行为的精确场景控制。

“‘小五’的毕业大考至此已接近尾声。它不仅证明了自己是一名优秀的‘战斗员’，更证明了自己是一名懂得自我管理和团队协作的‘智慧精英’。在最后的篇章里，我们将对整部TS 38.509规范进行一次全面的回顾与总结，为这场漫长而精彩的毕业大考，画上一个圆满的句号。”

FAQ环节

Q1：UPLF功能中，UE为什么要降低PCell（主载波）的功率，而不是SCell（辅载波）？ A1：这是因为PCell是“主”载波，它承载着关键的RRC信令，是UE与网络保持连接的生命线。在任何情况下，保证PCell的可靠通信都是第一位的。SCell是“辅”载波，纯粹用于提升数据速率，即使暂时不可用，也只会影响速率，不会导致掉线。因此，功率分配的策略是：首先保证PCell的“基本口粮”，然后在此基础上，通过对PCell施加backoff，“挤出”一部分功率余量去“喂饱”SCell，从而在保证连接稳定的前提下，最大化聚合吞吐量。

Q2：如果一款手机不支持上行载波聚合（UL CA），它还需要实现UPLF功能吗？ A2：不需要。规范5.11.1节明确指出：“The UE power limit function is mandatory for applicable UEs operating in Frequency Range 2 (FR2) and supporting UL CA from Rel-16.” UPLF是专门为了解决UL CA场景下的功率分配问题而设计的。如果UE本身不支持UL CA，这个功能对它来说就没有意义，也无需实现。

Q3：MUSIM测试中，SS如何知道UE是否真的按要求创建了Gap？ A3：SS有多种方法可以验证。一种典型的方法是：

  1. SS命令UE偏好创建Gap。
  2. SS在卡1上持续下发高速数据，并要求UE上报CQI等信道状态信息。
  3. 同时，SS在卡2的寻呼信道（PO）上发送一条针对卡2的寻呼消息。
  4. SS观察：首先，卡1上行链路的CQI上报或者PUSCH传输会出现周期性的中断，这就是Gap的表现。其次，UE在收到卡2的寻呼后，会发起相应的响应流程（如Service Request）。如果这两点都发生了，就证明UE成功地创建了Gap并完成了监听。

Q4：Set UAI function (5.8) 和 Set MUSIM UAI function (5.13) 有什么区别？ A4：Set UAI function (5.8) 是一个通用的功能，用于设定UE在单卡工作模式下的RRC状态偏好，主要目的是在功耗和性能之间进行权衡。而Set MUSIM UAI function (5.13) 是一个专用的功能，它只适用于支持多卡的UE，并且在通用RRC状态偏好的基础上，增加了更核心的Gap偏好设定。可以说，5.13是5.8在多卡场景下的一个“超级增强版”。

Q5：这些高级管理功能对手机的日常使用有什么影响？ A5：这些功能经过严格测试，能直接提升用户的日常体验。通过UPLF测试的手机，在未来部署了FR2 UL CA的网络中，能提供更高、更稳定的上行速率。通过MUSIM测试的手机，能更好地平衡双卡使用，在你用一张卡高速下载时，不会轻易漏掉另一张卡的重要来电，其“双卡双待”的体验会更加智能和可靠。

关系图谱