51学通信

深度解析 3GPP TR 23.700-28：6.16 主动请假 (UE触发的广义不可用周期)

24分钟阅读

深度解析 3GPP TR 23.700-28：6.16 主动请假 (UE触发的广义不可用周期)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中, 关于“第六章 Solutions”的 6.16 节 “Solution #16: Solution to support a UE Triggered Generalized Unavailability Period” 的核心章节, 旨在为读者深度剖析一种将UE的“自我感知”与网络的“高级服务”深度绑定的创新机制, 即由UE主动向网络“请假”, 声明一段广义的、可预见的“不可用”时段。

在上一篇文章中, 我们见证了Solution 15如何扮演“数字气象员”, 为UE提供了精准的“卫星覆盖地图”, 让终端从一个盲目的“探索者”进化为了能够预知未来的“导航员”。现在, UE手握这份宝贵的“情报”, 知道自己将在何时、何地、持续多久失去网络连接。

然而, “知道”本身并不能解决所有问题。这份“情报”如果只停留在UE自己的“大脑”里, 网络对此一无所知, 那么当有下行数据到达时, 网络依然会徒劳地进行寻呼, 数据依然会因为超时而被丢弃。这就像一位员工已经私下规划好了自己的长假, 却没有向公司的人事系统提交正式的休假申请。结果, 在他休假期间, 公司依然会给他派发紧急任务, 造成混乱。

Solution #16, 正是为解决这个问题而生。它为UE提供了一套标准的**“请假流程”。这个方案的核心, 是将UE基于自我感知得出的“不可用”时段, 从一个“个人认知”, 升级为一个网络正式受理并为之提供特殊服务的“官方状态”。它所定义的“请假条”, 内容也远超“失联”, 而是一张“广义不可用周期”（Generalized Unavailability Period）**的申请单。

为了演绎这场正式的“请假”流程, 我们的主角将换成一台名为“智联农机-01”（AgriBot-01）的5G NTN自动驾驶拖拉机。它将在广袤的农田中执行为期一周的自主作业。期间, 它不仅会因为卫星过境而周期性地失联, 还会因为执行一些内部任务（如每日的静默自检、夜间的深度休眠以节省太阳能电力、甚至每周一次的远程软件补丁升级重启）而主动进入“离线”状态。Solution 16将向我们展示, “智联农机-01”是如何将这些五花八门的“不可用”事件, 统一打包, 向网络提交一份清晰、详尽的“休假申请”的。

1. 核心哲学：从“失联”到“广义不可用” (解读 6.16.1 Description)

Solution 16的第一个核心思想, 是对其前身——Solution #6（Unreachability Period）的一次重大**“概念升级”**。

6.16.1 Description

This solution supports portions of KI#1 and KI#2. The solution is based on “Solution #2: UE provided Unavailability Period” in clause 6.2 of TR 23.700-61 where an unavailability period for an event that is unavoidable is indicated by a UE… In that solution, the events that may be supported currently include: a) Silent reset at Modem; b) Security patch updates; c) OS upgrade; … This solution though can be generalized to indicate UE unavailability for other events that are unavoidable such as satellite discontinuous coverage or UE power savings combined with satellite discontinuous coverage.

这段描述清晰地揭示了方案的演进脉络和核心扩展：

  • 思想来源： 本方案继承自TR 23.700-61（关于无缝UE上下文恢复的研究）中的一个概念, 即UE可以为了一些“不可避免的内部事件”（如Modem重启、OS升级等）, 主动向网络声明一段“不可用”时间。
  • 核心扩展： Solution 16大胆地将这个概念**“泛化”了。它认为, 从网络的角度看, UE是因为“OS升级”而离线, 还是因为“卫星飞走”而离线, 本质上并无区别——结果都是UE在一段时间内无法被联系到。因此, 我们可以用一个“广义不可用周期” (Generalized Unavailability Period)**, 来统一描述所有这些可预见的、由UE发起的“离线”事件。

“智联农机-01”的场景： “智联农机-01”的中央控制器, 就像一位精明的日程规划师。它通过查阅“覆盖地图”（来自Solution #15）, 结合自身的任务计划, 得出了一份未来24小时的“不可用”日程表：

  • 14:00 - 18:00 (4小时): 因卫星过境, 信号中断 (事件A)。
  • 23:00 - 23:10 (10分钟): 计划执行一次夜间Modem固件自检重启 (事件B)。
  • 02:00 - 02:30 (30分钟): 接收到远程指令, 计划安装一个安全补丁并重启系统 (事件C)。

在旧的思维模式下, 这三个事件性质迥异。但在Solution 16的“广义”框架下, 它们都可以被视为“Generalized Unavailability”。

1.1 “化零为整”的智慧

更进一步, 方案还提出了一种“化零为整”的智能合并策略。

NOTE 1: UE power savings combined with satellite discontinuous coverage refers to a period of power savings for a UE that includes one or more periods of (expected) no satellite coverage. The UE can then determine a preferred period of unavailability that starts at or before a first period of no satellite coverage and ends after this period and possibly subsequent periods of no satellite coverage have ended… The network… does not need to know the details of the one or more periods of no satellite coverage and can just support a single overall period of UE unavailability.

“智联农机-01”的场景（续）： 假设在14:00到18:00的信号空窗期内, 16:00时有一颗非服务卫星会短暂飞过, 带来5分钟的微弱信号。

  • “化零为整”前： 农机需要向网络请两次假：14:00-16:00 和 16:05-18:00。这增加了信令复杂性。
  • “化零为整”后： 农机可以做出一个更宏观的决策：“尽管中间有5分钟的微弱信号, 但为了实现一次不间断的、长达4小时的深度休眠, 我决定忽略它。” 于是, 它直接向网络提交了一份**14:00-18:00的、完整的“广义不可用”申请**。

这种“化零为整”的智慧, 赋予了UE极大的灵活性, 使得它能够根据自身的功耗策略, 将碎片化的“不可用”时段, 合并为一次性的、更长、更高效的“深度休眠”。

2. 操作流程：一套标准的“请假与销假”制度 (解读 6.16.2 Procedures)

Figure 6.16.2-1: UE Triggered Generalized UE Unavailability Period 为我们展示了一套标准的、由UE发起的“请假-批准-休假-销假”全流程。

场景复现：“智联农机-01”的休假申请

  • 步骤 1: “入职”时的能力声明

    1. During an initial Registration procedure, the UE provides an indication of support of “Generalized Unavailability Period”… and the AMF indicates whether this is supported… “智联农机-01”首次开机注册时, 会在信令中“亮明身份”：“报告, 我支持‘广义不可用周期’请假制度。” AMF收到后, 也会回复：“收到, 本网络支持该制度。” 这是一次“双向奔赴”的能力确认。

  • 步骤 2 & 3: “请假” - 提交申请单

    2. The UE determines a period of impending unavailability… 3. The UE sends a Registration Request sometime before the unavailability starts indicating the Unavailability period and may indicate an event or events causing the unavailability. “智联农机-01”计算出, 它将在1小时后, 开始一段长达4小时的“不可用”周期 (因信号中断)。于是, 它立即发起一次Registration Request (类型为Mobility Update), 并在其中包含了核心的“请假信息”：

    • Unavailability period: {start_time: +1h, duration: 4h}
    • event(s) (可选): SATELLITE_DISCONTINUOUS_COVERAGE

  • 步骤 4 & 5: “批假” - 网络批准并调整监管策略

    4. The AMF responds with a Registration Accept. The AMF may set the periodic registration timer to a value equal or slightly greater than the unavailability period provided by the UE. AMF收到了这份“请假单”。它执行了两个关键动作：

    1. 批准： 在回复的Registration Accept中, 确认收到了该申请。
    2. 调整监管策略： AMF将该UE的周期性注册定时器（T3512）, 临时调整为一个大于4小时的值（例如, 4.5小时）。这确保了在农机“休假”期间, 网络不会因为没收到它的周期性“打卡”而认为它失联了。

    5. The AMF stores the information that the UE is in unavailability period in the UE context, and considers the UE unreachable until the UE performs a registration update again. In this state, all HLCom features apply if supported, e.g. extended data buffering… AMF在农机的“档案”中正式盖章：“休假中, 勿扰！” 并自动激活了所有高级通信（HLCom）功能, 如扩展下行数据缓存。

  • 步骤 6: “销假” - 主动回归

    6. The UE becomes available either due to normal termination of the unavailability period or because the UE became available earlier… 4小时后, 卫星信号恢复, “智联农机-01”的“假期”结束。

  • 步骤 7 & 8: 恢复常态

    7. The UE triggers a registration update to resume regular service. The UE does not include an unavailability period in the Registration Request. 8. The AMF responds with Registration Accept. The AMF assigns a new periodic registration timer not applicable to an unavailability period. 农机立即发起一次新的Registration Request, 但这次不再包含Unavailability period信息。这就像员工休假归来后, 去人事部门“销假”。AMF收到后, 知道它已“官复原职”, 于是将其状态改回“可达”, 并将它的周期性注册定时器, 恢复为常规的值（例如, 54分钟）。

2.1 应对“惊群效应”的附加智慧

Solution 16还巧妙地融入了应对“惊群效应”的机制。

(e) When the period of unavailability ends at the expected time and is due to an unavoidable event common to many UEs (e.g. discontinuous satellite coverage), the UE, if requested by the MME or AMF, can delay sending of the registration update… by a time delay indicated by the MME or AMF.

在步骤4“批假”时, AMF如果识别出这是一个由“卫星覆盖中断”引起的、具有“集体性”的“公共假期”, 它可以在Registration Accept中, 附带一个“延迟销假”的指令, 例如, 一个随机等待范围。这样, 当假期结束时, 所有的农机就不会在同一时刻涌向网络“销假”, 而是会各自延迟一个随机的时间, 从而完美地实现了“错峰上班”, 避免了信令拥塞。这与Solution 14的思想异曲同工, 但实现方式更为整合。

3. 系统影响分析：一次职责明确的升级 (解读 6.16.3 Impacts)

UE:

  • Determination of a generalized unavailability period.
  • Negotiating and signalling an unavailability period to an AMF (or MME).
  • Notifying an AMF (or MME) after exiting unavailability…

UE的影响： 需要成为一个**“日程规划与沟通专家”**。它必须能够：

  1. 统一规划： 将来自不同源头（覆盖地图、内部任务）的不可用事件, 整合为一个统一的“广义不可用周期”。
  2. 主动沟通： 具备通过NAS信令, 向网络“请假”和“销假”的能力。

AMF/MME:

  • Support of an unavailability period indication in Registration or TAU procedure.
  • Storing unavailability period in UE context.
  • Handling of MT data and control plane procedures for an unreachable UE (no new procedures compared to HLCom).
  • Assigning a time delay to a UE for re-accessing the PLMN.

AMF/MME的影响： 需要升级为**“智能人事主管”**。它必须能够：

  1. 处理申请： 解析并受理UE的“请假单”。
  2. 管理档案： 在UE上下文中维护“休假”状态。
  3. 启动特殊服务： 在UE“休假”期间, 自动为其激活数据缓存等高级服务。
  4. 疏导交通： 具备在“批假”时, 附带“错峰销假”指令的能力。

4. 方案评估：通用性与前瞻性的胜利 (解读 6.16.4 Solution evaluation)

6.16.4 Solution evaluation

The solution does not require any support for satellite discontinuous coverage in an MME or AMF e.g. the AMF or MME does not need to receive data on satellite coverage or determine itself whether and when a UE will have a coverage gap. The solution is multi-purpose and can support UE unavailability for several different unavoidable types of events and not just for satellite coverage gaps. The solution can avoid a large number of UEs re-accessing a serving PLMN at the same time after a coverage gap has ended.

评估部分高度赞扬了本方案的**“通用性”和“解耦性”**。

  • 优点：

    1. 架构解耦： 这是一个巨大的优点。网络（AMF/MME）无需关心UE“请假”的原因。它不需要自己去获取和解析复杂的卫星覆盖数据。所有的“感知”和“决策”责任, 都被优雅地“下放”给了UE。这使得核心网的功能模型变得异常简洁。
    2. 多功能性（Multi-purpose）： 这是其“广义”思想的直接体现。同一套“请假”流程, 可以无缝地服务于“卫星失联”、“系统升级”、“节电休眠”等多种场景。这是一种高度可复用、面向未来的设计。
    3. 内置拥塞控制： 方案内建了“延迟销假”的机制, 一站式地解决了“休眠”和“回归拥塞”两大难题。

  • 兼容性： 方案还考虑了与旧版本网络的后向兼容性, 确保了新老设备和网络可以平滑共存。

总结：从“技术事件”到“业务状态”的升华

Solution 16以其“广义不可用周期”的创新概念, 将我们对UE“离线”状态的认知, 从一个底层的“技术事件”（如信号丢失）, 提升到了一个上层的、可管理的“业务状态”（如休假中）。这不仅仅是一次术语上的改变, 而是一场深刻的架构思想变革。

通过建立一套标准的“请假-销假”制度, 方案成功地将“感知”的复杂性留在了终端, 而将“服务”的确定性赋予了网络。网络不再需要成为无所不知的“先知”, 它只需要成为一个高效、可靠的“人事主管”, 即可为成千上万个行为各异的UE, 提供稳定、智能的后台服务。

“智联农机-01”的故事, 正是这场变革的缩影。它所提交的每一份“请假单”, 都是一次UE与网络之间, 基于信任和规则的高度协同。

然而, 无论是UE自己计算, 还是网络下发地图, 所有这些方案都离不开一个最根本的“原材料”——覆盖信息。我们至今的讨论, 更多是聚焦于“如何使用”这些信息。但这些信息本身, 是否还有更丰富的内涵？它是否可以不仅仅是“有/无”的二进制, 而是包含更详细的事件、轨迹和类型？

这, 正是我们将要在下一篇文章中探索的、一个关于“信息本身”的深度方案——Solution #17, “通过NAS传递的事件列表覆盖信息”。一场关于“信息维度”的升维之旅, 即将开启。

FAQ

Q1：Solution 16和Solution #6（Unreachability Period）都提出了“不可用周期”的概念, 它们是同一个方案吗？ A1：可以将Solution 16视为Solution 6的**“正式版”和“增强版”**。Solution 6首次引入了由UE上报“不可达周期”的核心思想。而Solution 16在此基础上, 进行了两大关键增强：1) 概念泛化：将其从单纯的“因卫星覆盖中断而不可达”, 扩展为可以包含任何UE可预见的“广义不可用”。2) 流程完善：明确了“能力协商”、“网络侧定时器调整”、“延迟回归以避免拥塞”等更完整的流程细节。可以说, Solution 16是将Solution 6的初步构想, 发展成了一个更成熟、更通用的架构方案。

Q2：“广义不可用周期”是否意味着UE可以随心所欲地“请假”？ A2：并非如此。“请假”的权利, 首先需要得到网络的“授权”（通过初始注册时的能力协商）。其次, “请假”的内容必须是“不可避免的事件”。一个UE不能因为“我想省电”就随意向网络申请一段不可用周期。它必须有合理的、可预见的理由, 如已知的覆盖中断、计划中的系统维护等。网络侧也保留了对“请假”申请的最终解释权和管理权。

Q3：为什么说这个方案让核心网（AMF/MME）“解耦”了？ A3：因为AMF/MME的决策, 不再需要依赖于具体的“不可用原因”。在之前的方案（如Solution #1）中, AMF需要获取卫星星历, 自己去计算覆盖中断时间。而在Solution 16中, AMF只需处理UE提交的、一个抽象的“不可用周期”即可。它无需关心这个周期是由于卫星、OS升级还是其他任何原因造成的。这种对“原因”的无知, 使得AMF的功能模型变得更通用、更简洁, 不再与特定的接入技术（NTN）或UE的内部行为深度耦合。

Q4：方案中内置的“延迟销假”机制, 和Solution #7（DCW定时器）相比, 哪个更好？ A4：两者思想一致, 都是通过随机延迟来避免拥塞, 但集成度不同。Solution 7是一个独立的、专门的拥塞控制方案。而Solution 16则是将拥塞控制, 作为“请假-销假”流程的一个内建（built-in）环节。从架构的优雅性来看, Solution 16的集成度更高, 它将“休眠管理”和“回归拥塞管理”这两个强相关的问题, 在一个统一的流程中闭环解决了。但Solution 7作为一个独立的模块, 其部署可能更灵活。

Q5：这个方案对UE的实现复杂度要求高吗？ A5：要求相对较高。UE需要成为一个“智能的日程规划师”。它的软件需要能够：1) 访问来自不同源头（覆盖地图、应用层任务调度器、底层Modem状态机）的事件信息。2) 将这些不同原因、不同时长的“不可用”事件, 智能地合并（如“化零为整”）成一个或多个统一的“广义不可用周期”。3) 在正确的时机, 通过NAS信令将这些周期上报给网络。这对UE的内部软件架构和跨层信息交互, 提出了不低的要求。

关系图谱