51学通信

深度解析 3GPP TR 23.700-28：6.3 终端为王 (基于UE覆盖感知的功耗节省)

27分钟阅读

深度解析 3GPP TR 23.700-28：6.3 终端为王 (基于UE覆盖感知的功耗节省)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中，关于“第六章 Solutions”的 6.3 节 “Solution #3: Power Saving based on UE awareness of coverage information” 的核心章节，旨在为读者深度剖析一种完全颠覆传统网络中心思维、将功耗节省决策权最大限度赋予终端的“UE自主”型解决方案。

在前两篇文章中，我们见证了两种截然不同的功耗节省哲学。Solution 1中，核心网AMF是运筹帷幄的“网络先知”，为UE下发休眠指令。Solution 2则上演了一场UE与网络的“智能双人舞”，UE扮演“终端先知”，预言自己的未来位置，网络则协同验证并校准休眠节奏。

现在，我们将探索一条更为简洁、更为激进的技术路线——Solution #3。这个方案的口号可以概括为：“我的电量，我做主！”它将功耗节省的智慧和决策权，几乎完全交还给了UE。网络不再是发号施令的指挥官，也不是协同决策的舞伴，而是更像一位信任并尊重前线士兵判断的“后勤官”，其主要职责是“批准”和“支持”UE基于自身对战场环境（即卫星覆盖）的精准感知而提出的自主请求。

为了更好地理解这一模式的运作，我们的主角，生态学家伊芙琳博士，将迎来一个新的任务。她不再是移动的探险家，而是在雨林深处建立了一个名为“生态站阿尔法”（Eco-Station Alpha）的半永久性研究基地。这个基地由太阳能供电，其核心通信枢纽正是我们的老朋友——GeoLink-1终端。作为一个固定站点，它对自身位置了如指掌，对天空中的卫星过境规律更是可以做到“分秒不差”。在这个场景下，一个“终端为王”的节电方案，显得无比自然和高效。

1. 核心哲学：从“协商”到“告知”，UE掌握绝对主动权 (解读 6.3.1 Description)

Solution 3的核心思想是“信任UE的自我感知能力”。它假设UE能够通过某种方式（例如，接收卫星广播的星历数据，并结合自身精确的GNSS定位）来构建一份准确的未来“卫星覆盖时间表”。基于这份时间表，UE将成为自己功耗行为的唯一主宰。

General

This solution addresses Key Issue #2 about the power saving enhancements for UE in discontinuous coverage. The solution is based on the Rel-17 approach agreed in TS 23.401 and clarifies how it works with PSM and MICO. It is based on the following existing pre-Rel-18 features and functionalities:

  • The UE is aware of its location and the satellite coverage information

这段总述为我们划定了方案的基石：

  1. 继承Rel-17的方法： Rel-17已经确立了UE可以通过接收SIB（系统信息块）中的星历来感知覆盖的基本框架。Solution 3正是在这个基础上，将其与PSM、MICO等核心网节电机制进行深度结合。
  2. UE的“两知”： 方案成立的前提是UE必须“知己知彼”——既知道自己的精确位置（通过GNSS），也知道卫星的覆盖信息（通过星历）。对于“生态站阿尔法”这样一个固定站点，这两个条件得到了完美的满足。

接下来，方案详细阐述了UE如何利用这份“先知”能力，来智能地运用三种主要的功耗节省技术：PSM、MICO和eDRX。

1.1 智能PSM：基于未来覆盖的“量体裁衣”

Power Saving Mode (PSM)

When the UE uses PSM, the UE requests an Active Time and may request a Periodic TAU Timer value in the TAU Request. In this solution the UE can take the coverage information into account when requesting these values. … For example, if there is 15 more minutes until the UE loses coverage, and 4 hours of out-of-coverage after that, the UE could select an Active Time value of 10 minutes and Periodic TAU Timer value of 4h20min.

这段描述是理解本方案运作方式的钥匙。UE不再是盲目地向网络请求一个通用的、较长的PSM周期，而是进行了一次精密的“量体裁衣”。

伊芙琳的场景： “生态站阿尔法”的GeoLink-1终端，通过其内置的星历分析软件，得出以下结论：

  • 当前卫星“星链-A”的覆盖窗口还剩 15分钟。
  • 下一次卫星“星链-B”进入覆盖范围，需要等待 4小时。
  • “星链-B”的覆盖窗口将持续 25分钟。

基于这份精准的时间表，GeoLink-1的协议栈将发起一次TAU（跟踪区更新）请求，并在其中携带它精心计算出的两个关键参数：

  • 请求的周期性TAU定时器 (T3412): 它需要覆盖整个“失联”时段。UE会选择一个略大于4小时的值，比如4小时 + 20分钟 = 260分钟。这20分钟的余量是为了应对可能的网络延迟或时钟误差。这样设置可以确保，在长达4个多小时的休眠期内，这个定时器不会超时，从而避免了任何无效的唤醒和注册尝试。
  • 请求的激活时间 (Active Time, T3324): 这是UE进入PSM休眠前，网络可以寻呼到它的时间窗口。传统的PSM用户为了尽快进入休眠，通常会请求一个很短的Active Time。但在NTN场景下，UE的策略完全不同。GeoLink-1知道当前还有15分钟的宝贵连接时间，它可能会请求一个例如 10分钟 的Active Time。这意味着在接下来的10分钟里，它依然保持可达，可以接收来自地面研究中心的任何紧急指令或数据查询。直到10分钟后，它才正式进入长达4个多小时的深度睡眠。

这就是Solution 3的革命性之处：UE将对未来覆盖的精准预测，直接转化为了对PSM参数的个性化、动态化请求。

1.2 智能MICO：与PSM异曲同工

MICO

MICO mode is very similar to PSM with the difference that the use of Active Time is optional and that the UE cannot request a Periodic Registration Timer value. In this solution the UE enters MICO mode based on current specification. The UE can initiate transition to CM-CONNECTED… but only when it has coverage…

MICO（仅移动发起连接）模式下的逻辑与PSM高度相似。UE同样会基于自己对覆盖的感知，来决定何时发起连接（必须在有覆盖的时候），以及（如果使用了Active Time）请求一个多长的Active Time来保持一小段可达时间。其核心思想一脉相承：一切行为，皆以“我有覆盖”为前提。

1.3 智能eDRX：确保“醒在有信号时”

eDRX

In this solution, the UE can request eDRX parameters based on its awareness of the coverage information. The eDRX cycle length is defined in TS 24.008 and can only express certain fixed values. The available eDRX cycles may therefore not match the timing of the coverage… The UE may in this case request a eDRX cycle length that is less than the coverage window to ensure that the UE is reachable within the window.

eDRX的运用场景与PSM/MICO有所不同。它不是为了长达数小时的“失联”设计的，而是为了在“空闲态”下的周期性休眠。但其智能化改造的思路是相同的。

伊芙琳的场景： 假设“生态站阿尔法”进入了一个连续覆盖期，有多颗卫星接力服务。但基站本身没有下行数据，为了省电，GeoLink-1启用了eDRX。它通过分析星历得知，接下来的几个小时内，每颗卫星的单次过境覆盖时长大约是 12分钟。

面对规范中定义的固定eDRX周期值（如5.12秒, 10.24秒, …, 17.4分钟等），GeoLink-1会如何选择？

  • 错误的选择： 选择17.4分钟的eDRX周期。这意味着它会休眠17.4分钟，然后在一个极短的寻呼窗口（PTW）醒来。这17.4分钟的休眠周期，远大于12分钟的单次卫星覆盖时长。极有可能当它醒来时，服务的卫星早已飞走，而下一颗还未到来，导致监听失败。
  • 智能的选择： GeoLink-1会选择一个小于12分钟的eDRX周期，例如 10.24分钟。这样，它就能确保自己的每一次“醒来”（PTW），都大概率落在同一个卫星的有效覆盖窗口之内，从而不会错过任何可能的网络寻呼。

1.4 网络的角色：从“指挥官”到“信任者”

在UE如此智能和主动的背景下，网络（AMF/MME）的角色发生了根本性的转变。

Common to PSM and MICO … TAI or RAT specific MME configuration is used to ensure that the UE is not deregistered in those cases… eDRX … TAI or RAT specific AMF/MME configuration can be used to allow the AMF/MME to use the UE requested value when assigning the eDRX parameter in the reply to the UE.

这两段话暗示了网络侧需要做的关键适配：

  1. 防止UE被“误杀”： 当UE因为执行自己的长周期PSM而长时间不与网络联系时，网络侧的默认机制可能会认为该UE已经失活或离开，从而将其上下文删除（隐式分离，Implicit Detach）。为了支持Solution #3，网络需要有一种特殊的配置（例如，基于TAI或RAT类型），对于来自NTN的UE，极大地延长其“隐式分离”定时器，以容忍它们的长时间“静默”。
  2. 信任并采纳UE的请求： 对于UE发起的、经过深思熟虑的eDRX/PSM参数请求，网络侧的策略应该是尽可能地“批准”和“采纳”（honour the UE requested value）。网络需要信任，这个来自NTN的UE，比网络自己更清楚什么样的节电参数最适合它当前的环境。

2. 操作流程：复用经典的“两步走” (解读 6.3.2 Procedures)

Solution 3的优美之处，不仅在于其思想的简洁，更在于其实现的优雅。它几乎没有引入任何新的信令流程。

6.3.2 Procedures

The call flow below illustrates an example for PSM. The handling of MICO mode and eDRX is similar. All signalling is based on existing procedures and protocols.

规范明确指出，所有信令都基于现有流程。我们需要解读Figure 6.3.1-1: Example of PSM usage in case of discontinuous coverage，这张图虽然简单，却完美地展示了Solution 3的交互精髓。

场景复现：“生态站阿尔法”的一天

  1. 早晨8:00 (覆盖窗口开启): “星链-A”进入服务范围。“生态站阿尔法”的GeoLink-1从长达4小时的PSM休眠中醒来。

    • 动作： 发起TAU Request（图中步骤1）。这次TAU有两个目的：一是向网络“报到”，告知自己已恢复可达；二是在这次请求中，基于对未来覆盖的新一轮预测，携带上为下一个休眠周期计算好的PSM参数。

  2. 早晨8:01 (网络响应): 核心网MME收到请求。

    • 动作： MME的策略是“信任NTN UE”。它批准了UE请求的PSM参数，并通过TAU Accept（图中步骤2）消息将其回传给UE，完成了“授权”。

  3. 早晨8:01 - 8:15 (数据传输与激活期):

    • 动作： UE与网络完成TAU流程后，进入了它自己请求的、例如10分钟的Active Time。在此期间，它上传了夜间积累的所有科研数据。网络也可以在这段时间内向其下发任何指令。

  4. 早晨8:15 (覆盖窗口关闭前):

    • 动作： MME/RAN释放连接（图中步骤3b AN Release），GeoLink-1正式进入它在新一轮协商中获得的、长达数小时的PSM休眠状态（图中MME considers UE unreachable due to PSM）。

  5. 中午12:35 (下一次覆盖窗口开启):

    • 动作： “星链-B”进入服务范围。GeoLink-1的PSM定时器到期，它准时醒来，再次发起TAU Request，开始新一轮的“上线-协商-休眠”循环。

这个流程，完美地利用了最常规的TAU流程，通过在消息中智能地填充内容，就实现了一个高度动态和自主的功耗节省闭环。

3. 系统影响分析：UE的“升维”与网络的“降维” (解读 6.3.3 Impacts on existing nodes and functionalities)

The solution has no protocol impacts.

UE and AMF/MME functional impacts:

  • The UE to take coverage info into account to 1) stay in PSM/MICO mode while out of coverage and 2) (optionally) request Active Time, Periodic TAU Timer and eDRX parameters based on coverage info.
  • The MME/AMF to honour the UE requested Active Time value…, Periodic TAU Timer value… and eDRX parameters… when using satellite RAT type.

这份影响分析，是对本方案“优雅”的最好注解。

  • 协议影响：无！ 这意味着不需要定义新的信令消息，不需要修改消息的底层结构，互操作性风险极低。
  • UE的功能影响： 这是**“升维”**。UE不再是一个简单的执行者，它需要被赋予新的“智慧”——一个能够解析星历、计算覆盖、并基于此进行智能决策的功能模块。这对终端的软件实现提出了更高的要求。
  • AMF/MME的功能影响： 这是**“降维”**。与Solution 2中需要成为“计算者”或“协调者”不同，这里的核心网功能被大大简化了。它只需要增加一个新的策略配置能力：当识别到这是一个来自卫星RAT的UE时，就“无条件”信任并批准其节电参数请求。

4. 方案评估：简约而不简单 (解读 6.3.4 Solution evaluation)

6.3.4 Solution evaluation

The solution is based on existing EPS/5GS power saving solutions and protocols and has therefore minimal impact to Rel-17. Letting the UE handle the awareness of coverage information has the following benefits:

  • The UE can be aware of its location also during out-of-coverage times… The network would however need to rely on predicted UE mobility information that is not always available…
  • The UE anyway needs satellite ephemeris information in order to access NTN.
  • No need for MME/AMF to be aware of satellite-specific information such as ephemeris, that is more RAN related than CN related.

评估部分高度赞扬了这种“UE自主”模式带来的诸多好处：

  1. 信息优势： UE永远是自己位置信息的最权威来源，尤其是在它移动之后。任何网络侧的预测，都存在滞后性和不确定性。将决策权交给信息最准确的一方，是最高效的设计。
  2. 能力复用： 无论如何，一个NTN终端为了能接入卫星网络，本身就需要具备解码星历和定位的能力。本方案只是将这个“接入”所需的能力，巧妙地“复用”到了“功耗节省”上，没有增加额外的硬件需求。
  3. 架构解耦： 这是一个非常重要的架构设计原则。卫星星历和轨道计算，本质上是与无线接入（RAN）强相关的物理层信息。让核心网（CN）去处理这些信息，实际上是一种“职责不清”的架构“坏味道”。Solution 3让核心网从这些复杂的物理层计算中解脱出来，回归到其信令和移动性管理的本职工作上来，使得整个系统架构更为清晰、更为解耦。

总结：UE自主模式的辉煌与前提

Solution 3为我们描绘了一幅“终端为王”的理想图景。在这个模型中，UE凭借其对自身位置和卫星覆盖的精准感知，化身为自己功耗命运的主宰者。它不再被动，不再需要复杂的协商，而是以一种近乎“告知”的方式，主动向网络申请最适合自己的“休眠”方案。网络的角色则化繁为简，从一个决策者，转变为一个信任并支持UE自主决策的赋能者。

这种模式的优点是显而易见的：极简的网络影响、清晰的架构职责、充分利用UE的信息优势。对于像“生态站阿尔法”这样的固定或准固定物联网设备，这几乎是一个完美的解决方案。

然而，这种辉煌的背后，也隐藏着一个至关重要的前提：UE必须有能力、且愿意承担起“自我感知”的全部责任。如果UE是一个计算能力极弱的微型传感器，或者其GNSS模块因遮挡而无法定位，亦或是它在一个完全不可预测的轨迹上移动，那么Solution 3的根基便会动摇。

正是这些场景的限制，催生了我们将在后续文章中探讨的其他解决方案。例如，当UE的能力不足时，我们是否可以设计一种机制，让UE可以向网络“求助”，请求网络提供覆盖信息？这就是Solution 15等“信息服务型”方案将要回答的问题。敬请期待。

FAQ

Q1：Solution 3和Solution 2都依赖UE的位置信息，它们的核心区别是什么？ A1：核心区别在于决策流程和网络所扮演的角色。在Solution #2（终端先知）中，流程是“UE预测 → 网络验证 → 网络校准”。UE提出一个包含未来位置的“休眠”请求，网络需要调用外部服务器来验证这个预测的有效性，并可能通过“Signed Offset”来对UE的计划进行微调。而在Solution #3（终端为王）中，流程简化为“UE决策 → 网络批准”。UE基于自己的计算，直接请求一套它认为最优的PSM/eDRX参数，网络的主要职责是基于策略（如识别为NTN用户）来“信任”并批准这个请求，而无需自己进行复杂的外部验证和计算。

Q2：UE如何获取“卫星覆盖信息”？如果这些信息不准确会怎样？ A2：根据Rel-17的基线，UE主要通过解码卫星广播的系统信息块（SIB）来获取星历数据。然后结合自身的GNSS定位，通过算法计算出覆盖时间。如果这些信息不准确（例如，星历过时，或者GNSS定位有漂移），将会直接影响UE决策的准确性。UE可能会在错误的时间醒来尝试接入网络，导致失败并浪费电量；或者错过一个真实的覆盖窗口，导致数据上传延迟。这凸显了该方案对UE信息获取和计算能力的强依赖性。

Q3：网络侧“honour the UE requested value”（采纳UE请求的值）在实际中是如何实现的？网络真的会完全信任UE吗？ A3：这通常是通过在AMF/MME上配置特定的策略来实现的。例如，运营商可以设置一条策略：“对于所有通过TAI（跟踪区标识）识别为来自NTN接入的UE，当它们在TAU/Registration Request中请求T3412（PSM周期）或eDRX参数时，只要该值在规范允许的范围内，就予以批准。” 这不是技术上的“盲目信任”，而是一种商业和技术上的权衡。运营商认为，对于NTN场景，UE自主决策带来的功耗节省收益，远大于其偶尔决策失误可能带来的风险。

Q4：这个方案是否意味着网络对UE的功耗完全失去了控制？ A4：并非完全失控。首先，UE请求的参数必须在3GPP规范定义的合法范围内。其次，网络在最终的TAU/Registration Accept消息中，依然是“批准方”，它保留了拒绝UE请求或分配不同参数的最终权力，尽管本方案的指导思想是“倾向于批准”。例如，如果网络出于全局负载均衡的考虑，不希望某个区域的UE休眠太久，它理论上仍然可以否决UE的超长PSM请求。

Q5：相比于Solution #1，Solution 3对物联网（IoT）设备来说是更好还是更坏的选择？ A5：这取决于物联网设备的“能力”。对于那些计算能力较强、配备了可靠GNSS模块的“高端”物联网设备（如车载追踪器、高端环境监测站），Solution 3是更好的选择，因为它更精准、更自主、网络开销更小。但对于那些成本和功耗极其敏感、计算能力极弱的“低端”物联网设备（例如，微型动物标签），让它自己去进行复杂的轨道计算可能是一种负担。对于这类设备，由网络完成所有计算、UE只负责执行的Solution 1可能是一个更合适的、成本更低的选择。

关系图谱