51学通信

深度解析 3GPP TR 23.700-28：6.14 有序的迁徙 (管理大规模寻网的等待定时器)

21分钟阅读

深度解析 3GPP TR 23.700-28：6.14 有序的迁徙 (管理大规模寻网的等待定时器)

本文技术原理深度参考了3GPP TR 23.700-28 V18.1.0 (2023-03) Release 18规范中，关于“第六章 Solutions”的 6.14 节 “Solution #14: Wait timer for discontinuous coverage” 的核心章节，旨在为读者深度剖析当大量UE被允许同时寻找新网络时，如何通过重用现有机制，引入一个“等待定时器”，来避免对目标网络造成灾难性的信令冲击。

在上一篇文章中，我们探讨了充满“经济学智慧”的Solution #13。它为网络运营商（HPLMN）提供了一把精密的“遥控器”——DisCoNoserviceapplicability参数，使其能够根据商业成本，远程指导其遍布全球的终端，在主网络信号中断时，是应该“原地等待”还是“主动寻网”。

这引出了一个激动人心又充满风险的场景。想象一下，由物联网运营总监艾力克斯（Alex）管理的那艘满载着数千个“智能货箱”的远洋货轮，正缓缓驶出A国海域。根据Alex的配置，在A国（漫游费昂贵），所有追踪器的DisCoNoserviceapplicability参数都为True（原地等待）。然而，当货轮驶入B国海域（有漫游优惠协议）的瞬间，所有追踪器的策略自动切换为False（允许寻网）。就在此时，主服务卫星的信号恰好消失了。

一瞬间，数千个被“解禁”的追踪器，如同听到了发令枪，同时开始扫描并尝试注册到B国的卫星网络上。这场由“商业策略”触发的、可预见的“数字迁徙”，如果没有任何秩序，将瞬间演变成一场“数字踩踏”，对B国的卫星网络这个“新家园”的“欢迎系统”（接入信道）造成毁灭性的冲击。

如何为这场大规模的“数字迁徙”引入秩序，让成千上万的“新访客”变得文明而有序？这，正是Solution #14——“非连续覆盖的等待定时器”——所要解决的核心问题。它为我们带来的，不是一项全新的发明，而是一种“他山之石，可以攻玉”的智慧。

1. 核心哲学：重塑“旧工具”，应对“新挑战” (解读 6.14.1 Description)

Solution 14的哲学根基，在于**“重用”与“类比”**。3GPP的专家们敏锐地发现，当前面临的这个问题，与他们曾经解决过的另一个难题，在本质上惊人地相似。

6.14.1 Description

When discontinuous coverage occurs this will happen for all the UEs which were served by satellite access in a given area, if all these (or at least majority) of this UEs look for alternate PLMN or RAT then it can create spike of signalling load on the target system… Similar problem was studied as part of the MINT work item.

这段描述清晰地指出了问题的根源和解决思路的来源。

  • 问题的根源： “集体性”的“寻网”行为，对**目标系统（target system）造成信令尖峰。这与Solution 7所解决的、对原系统（source system）**的回归拥塞，是同一个问题的不同表现形式。
  • 思路的来源：MINT（Massive IoT for NTN）工作项目。在MINT的研究中，3GPP曾深入研究过一个名为“灾难漫游”（Disaster Roaming）的场景：当某个地区的地面网络因地震、洪水等灾害而大面积瘫痪时，该区域的所有幸存UE会同时尝试漫游到邻近的、仍在工作的网络上。为了保护那个“幸存网络”不被这突如其来的流量洪峰冲垮，3GPP引入了“灾难漫游等待范围”（disaster roaming wait range）机制。

Clause 5.40.6 of TS 23.501: “To prevent signalling overload in PLMN providing Disaster Roaming, the HPLMN or registered PLMN:

  • may provide disaster roaming wait range information to control when the UE can initiate the registration for Disaster Roaming service…”

It is proposed to reuse the same solution even for discontinuous coverage.

这两段引文，是整个Solution 14的“灵魂”。它大胆地提出：非连续覆盖下的“集体寻网”，在信令模型上，就等同于一场小规模的、可预见的“数字灾难漫游”。因此，我们完全可以重用为“灾难漫游”设计的那套成熟的、基于“等待定时器”的拥塞控制方案。

2. 操作流程：从“一拥而上”到“随机排队” (解读 6.14.2 Procedures)

这套“旧工具”的运作流程非常简洁，其核心是在UE发起注册之前，强制插入一个由网络控制的、UE自主随机化的“冷静期”。

6.14.2 Procedures

Either reuse the disaster roaming wait range configuration (hereafter called as discontinuous coverage wait range) or the new discontinuous coverage wait range is configured in the UE by the HPLMN as part of registration procedure or using UE Parameters Update… When the UE detects discontinuous coverage, selects the different PLMN… and if the UE has a stored discontinuous coverage wait range, the UE shall generate a random number within the… wait range and start a timer… While the timer is running, the UE shall not initiate registration…

场景复现：艾力克斯的“智能货箱”们的文明迁徙

  1. 阶段一：HPLMN下发“排队规则”

    • 动作： 在“智能货箱”追踪器首次注册或后续的参数更新中，艾力克斯的公司（HPLMN）通过UDM → AMF → UE的路径，为其下发了一个“非连续覆盖等待范围”（discontinuous coverage wait range），例如 [0, 120 seconds]。
    • 含义： 这份规则的潜台词是：“当你被允许去寻找新家园时，不要心急。请在找到新家门口后，先在门口的广场上随机溜达0到120秒，然后再去敲门。”

  2. 阶段二：触发“迁徙”

    • 动作： 货轮驶入B国海域，主网络信号中断。追踪器的内部逻辑（由Solution 13的参数决定）告诉它：“可以开始寻找新的网络了。”

  3. 阶段三：执行“排队”

    • 动作： 追踪器启动PLMN搜索，并成功发现了B国的卫星网络。**就在它准备发起注册请求的前一刻，**它的协议栈检查到，自己脑中存有那份“排队规则”。
    • 随机化： 追踪器立即在[0, 120]这个范围内，生成一个随机数，比如 73.5秒。
    • 启动等待： 它启动一个时长为73.5秒的内部定时器。
    • “静默”等待： 在这73.5秒内，追踪器将严格抑制自己发起注册的冲动，保持在无线电静默状态。这不仅避免了对目标网络的冲击，也节省了自身的电量。
    • 集体效应： 与此同时，船上的其他数千个追踪器，也在各自执行着同样的流程，但它们每一个都随机到了一个不同的等待时间。

  4. 阶段四：有序“敲门”

    • 动作： 73.5秒的等待结束后，这个追踪器的“排队”时间到了。**只有在此时，**它才正式向B国的卫星网络，发起Registration Request。
    • 最终效果： 原本会在同一秒钟内发生的数千次注册请求，被均匀地“摊平”到了一个长达120秒的时间窗口内。B国的卫星网络所面对的，不再是一场汹涌的“海啸”，而是一波平缓、可控的“浪潮”。

If the UE does not have stored discontinuous coverage wait range timer then UE will attempt registration procedure on selected PLMN or alternate RAT immediately following the legacy procedures.

这段话指出了“例外”情况：如果一个UE没有被HPLMN配置这个“排队规则”，那么它将继续扮演那个“不文明的访客”，直接“一拥而上”。这更凸显了HPLMN进行策略配置的重要性。

3. 系统影响分析：一次轻量级的“策略注入” (解读 6.14.3 Impacts)

UE:

  • If the preference is to reuse the existing disaster roaming wait range configuration then UE can re-use the same configuration…
  • If the preference is to go with new discontinuous coverage wait range configuration then UE can use respective configuration…

UE的影响： 需要成为**“规则的识别与执行者”**。它需要升级软件，能够：

  1. 接收并存储这个（新的或复用的）wait range参数。
  2. 在“寻网并准备注册”这一特定时机，触发等待逻辑。
  3. 在定时器运行时，抑制注册行为。

AMF or UDM:

  • To provide discontinuous coverage wait range configuration to the UE.

AMF/UDM的影响： 成为**“规则的制定与下发者”**。它需要在签约数据中，增加对这个wait range参数的管理能力，并能通过标准的UE参数更新流程将其下发。这是一个非常轻量级的增强。

4. 方案评估：重用的智慧与未来的抉择 (解读 6.14.4 Solution evaluation)

6.14.4 Solution evaluation

The solution proposes randomization of UE attempts on the target PLMN/RAT when UE enters discontinuous coverage. The solution keeps open to either re-use the “disaster roaming wait range configuration” or to create a similar new configuration “discontinuous coverage wait range configuraton” which can be configured by network. Given the end purpose are same and solution does not propose any disadvantages of re-using the existing configuration. Existing configuration can be used to solve this issue.

评估部分高度肯定了本方案的简洁与高效，并点出了其唯一的“开放性问题”：是直接重用，还是新建一个？

  • 优点：

    1. 根本性解决问题： 它从NAS层入手，在信令风暴形成之前就将其化解，是一种“釜底抽薪”式的优雅方案。
    2. 极简的实现： 方案的核心思想是“重用”，这意味着它可以直接利用已经为“灾难漫游”标准化了的信令参数和UE行为逻辑，大大降低了标准化的工作量和厂商的实现成本。

  • 开放性问题与权衡：

    • 直接重用（Re-use）：
      • 优点： 实现最快，影响最小。UE和网络甚至不需要定义新的参数。
      • 潜在缺点： 可能会导致“语义混淆”。一个参数被用于两种不同的场景，可能会给未来的策略管理带来一定的复杂性。例如，一个运营商可能希望为“灾难漫游”和“NTN寻网”配置不同的等待范围，直接重用就无法做到。
    • 新建一个（Create a similar new configuration）：
      • 优点： 语义清晰，职责单一。disaster_wait_range 和 ntn_disco_wait_range 两个参数互不干扰，便于进行独立的策略配置。
      • 缺点： 需要在标准中定义新的IE，UE和网络都需要进行相应的软件修改来支持这个新参数。

  • 评估的倾向： 评估报告的最后一句——“Existing configuration can be used to solve this issue”——强烈地暗示，直接重用现有配置是一个完全可行的、且可能更受青睐的选择，因为它完美地契合了“最小化影响”的黄金原则。

总结：为“数字迁徙”铺设的文明之路

Solution 14以其“重用”的智慧，为我们展示了3GPP标准化工作中的一种高效范式。它告诉我们，面对新的挑战，我们不必总是去发明全新的、复杂的工具，有时，环顾四周，将一个为旧问题设计的“旧工具”，巧妙地应用到新场景中，可能会收获事半功倍的奇效。

通过引入这个简单的“等待定时器”，艾力克斯的数千个“智能货箱”，在跨越网络边界时，完成了一场从“混乱的踩踏”到“有序的迁徙”的文明进化。这场进化的背后，没有复杂的实时协同，没有高昂的信令开销，只有一份由HPLMN预设的、简单的“排队规则”，和UE们基于这份规则的、自觉的“随机等待”。

至此，我们已经探讨了多种管理“覆盖中断”的方案。它们有的关注个体休眠，有的关注集体接入，有的依赖网络，有的依赖终端。但它们中的大多数，都基于一个共同的、但至今仍未深入探讨的基石：UE或网络，必须能够获取到准确的“覆盖信息”。

我们一直在说“UE解析星历”、“AMF查询覆盖数据库”，但这些“覆盖信息”本身，到底应该长什么样？它们仅仅是原始的、晦涩的轨道参数，还是可以是更直观、更智能的“覆盖地图”？网络和UE又该通过怎样的渠道，来最高效、最可靠地获取这些“战略级”的情报？

这，正是我们下一篇文章将要开启的、一个全新的、至关重要的篇章——Solution #15，“为UE提供覆盖数据的解决方案”。一场关于“信息赋能”的探索，即将拉开帷幕。

FAQ

Q1：Solution 14和Solution #7（DCW定时器）的核心机制几乎一样，为什么它们是两个独立的解决方案？ A1：因为它们应对的场景和目标网络完全不同。Solution 7解决的是大量UE在覆盖空窗期结束后，**回归到同一个原服务网络（Source PLMN）时造成的拥塞。而Solution 14解决的是大量UE在主网络覆盖中断后，被允许去寻找并注册到一个全新的目标网络（Target PLMN）**时造成的拥塞。虽然工具都是“等待定时器”，但“战场”和“要保护的对象”是不同的。

Q2：这个等待定时器对UE的功耗有什么影响？ A2：正面影响为主。虽然它引入了一段“等待”时间，看似增加了业务的接入延迟，但在这段等待期间，UE处于无线电静默状态，功耗极低。更重要的是，它通过避免信令拥塞，极大地提高了UE一次性注册成功的概率。相比之下，如果没有这个机制，UE可能会因为接入碰撞而进行多次耗电的“退避-重传”，总功耗反而会更高。

Q3：HPLMN是如何知道应该为目标网络（Target PLMN）配置多大的wait range的？ A3：这主要依赖于运营商之间的漫游协议和技术协商。例如，艾力克斯的公司（HPLMN）在与B国的卫星运营商（VPLMN）签订漫游合同时，VPLMN会告知其接入网络的容量参数，并可能建议一个合适的wait range值。HPLMN再将这个协商好的值，配置到自己的UDM中，下发给自己的用户。这背后，既有技术层面的容量考量，也有商业层面的服务等级约定。

Q4：如果一个UE同时被配置了“灾难漫游等待范围”和“非连续覆盖等待范围”，它该如何区分使用？ A4：这正是“重用还是新建”这个问题所要解决的核心。如果标准最终决定新建一个独立的参数，那么UE就可以清晰地区分：当触发“灾难漫游”（通常由网络广播特殊指示）时，使用参数A；当触发“NTN寻网”时，使用参数B。如果标准决定直接重用，那么UE可能需要根据触发事件的上下文来判断。例如，当UE是因为自身逻辑（Solution #13）决定去寻网时，就启用这个等待定时器。这种方式对UE的逻辑实现要求更高一些。

Q5：这个方案是否只适用于物联网（IoT）设备？ A5：虽然方案的描述和评估场景更偏向于大规模物联网，但它对普通的手机用户同样适用。想象一下，一架搭载数百名乘客的国际航班，在飞入某个国家的NTN覆盖区时，如果所有乘客的手机在同一时刻都尝试向当地的卫星网络进行漫游注册，同样会造成信令拥塞。通过为这些手机配置一个“等待范围”，就可以有效地平滑这数百个用户的接入请求，保障所有人的网络体验。

关系图谱