51学通信

深度解析 3GPP TR 23.700-01：7.2.4 & 7.2.8 S&F事件的订阅与应用 (Solutions #AE4 & #AE8)

20分钟阅读

好的，遵照您的指令，我们继续深入解析第7章中的下一个重要解决方案。

深度解析 3GPP TR 23.700-01：7.2.4 & 7.2.8 S&F事件的订阅与应用 (Solutions AE4 & AE8)

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“7.2.4 Solution AE4”和“7.2.8 Solution AE8”的核心章节，旨在为读者详细拆解3GPP如何通过增强SEAL（服务使能架构层），为上层应用提供一套完整的“太空物流追踪系统”，从而实现对延迟容忍型业务的智能、可靠管理。

前言：从“包裹寄出”到“全程追踪”

在上一篇文章中，我们剖析了Solution AE3，它通过一份精准的“卫星过境时刻表”，解决了物联网终端的“能源危机”，让UE能够在正确的时间“睡觉”和“工作”。这解决了“何时发送”的问题。

然而，对于数据的管理者——远在地面总部的应用服务器（AS）来说，故事才刚刚开始。数据被UE成功发送到“太空快递柜”（卫星的S&F缓存）后，AS就陷入了一片信息的“迷雾”：

  • 包裹（数据）真的进柜了吗？
  • 快递柜（卫星）现在飞到哪里了？
  • 什么时候能连接到地面？
  • 预计多久能派送（转发）成功？

如果对这些过程一无所知，AS就只能焦急地等待，或者在预设的超时后盲目地让UE重发，这会造成数据混乱和资源浪费。

为了驱散这片迷雾，3GPP SA6提出了Solution AE4和AE8。这两个方案高度相关，其共同的核心目标是将网络内部的S&F（存储转发）操作流程，转化为应用层可以实时订阅和感知的“物流事件”。它们通过增强SEAL平台，为AS提供了一套功能强大的“太空物流追踪API”。

本章，我们将看到这套API是如何被设计的。我们将跟随阿里斯博士的数据管理团队，体验如何从过去那个“包裹一旦寄出，便生死未卜”的时代，跨入一个可以实时监控每一个数据包“太空之旅”的、全透明、可管控的智能物联网新时代。 (注：#AE4主要面向5GC架构，而#AE8则考虑了与EPS/EPC的兼容性。由于核心思想一致，我们将它们融合解读，并以更面向未来的5GC场景为主。)

1. 方案#AE4：构建“物流追踪”的订阅-通知模型 (7.2.4)

Solution AE4是这套“物流追踪系统”的核心。它详细设计了应用服务器（AS）如何向网络订阅S&F事件，以及网络在各个关键节点如何向AS进行通知。

1.1 部署模型与假设 (7.2.4.1.1 Deployment model)

Figure 7.2.4.1.1-1: Deployment for satellite S&F operation for IoT services For this solution, the SEAL server… is assumed to be deployed on the ground. The VAL server is deployed on the ground. …The PGW-U to access the SEAL server is deployed on the satellite.

深度解析：

方案首先确立了一个清晰的部署模型：

  • SEAL服务器与VAL服务器在地面：负责能力开放和业务逻辑的“大脑”都在地面，便于管理和维护。
  • UPF/PGW-U在卫星：负责处理用户数据的“手脚”在太空，以便能就近接收UE的数据并执行S&F的“存储”操作。

这个模型确立了，我们讨论的“物流追踪”交互，主要发生在地面上的SEAL服务器与VAL服务器之间。

1.2 核心流程：追踪“包裹”的太空之旅 (7.2.4.1.2)

Figure 7.2.4.1.2-1: Procedure of SEAL Server exposing the S&F status to the VAL server

这是整个方案的灵魂。这张流程图描绘了一个标准的、事件驱动的订阅-通知交互过程。

第1-2步：应用发起“物流追踪”订阅

  1. The VAL server sends UE S&F status events subscription requests to the SEAL server. The subscription events may include the UE Registration status in S&F Mode, the status of Feeder Link, the expected Delivery/Delay Time, the maximum S&F data storage quota per UE, the trigger conditions, etc.
  2. The SEAL server authorizes the subscription request… and sends the subscription request to… the 3GPP CN…

深度解析：

  • 起点是AS（VAL Server）：阿里斯博士的数据中心，向SEAL服务器发起一个API请求：“你好，我想追踪gaia-node-073传感器的所有S&F物流状态，请在以下事件发生时通知我。”
  • 丰富的订阅选项：这个订阅请求不是一个简单的“开关”，而是一份详尽的“菜单”。AS可以按需选择它感兴趣的事件，包括：
    • UE Registration status in S&F Mode：包裹是否已被揽收进柜？
    • status of Feeder Link：中转卡车是否已发车？
    • expected Delivery/Delay Time：预计送达时间？
    • maximum S&F data storage quota：快递柜还剩多少空间？
  • SEAL作为代理：SEAL服务器在对AS进行鉴权后，会扮演“总代理”的角色，将这个订阅请求“翻译”成底层核心网（3GPP CN）能听懂的语言，并通过NEF等北向接口，向核心网注册这个订阅。

第3-4-5步：网络上报事件，SEAL存储并通知应用

  1. The SEAL client and/or 3GPP CN acknowledge the SEAL server with UE S&F status events subscription response. And report the requested UE S&F status events when the trigger conditions for subscription are met.
  2. The SEAL server stores or updates the received UE S&F events results.
  3. The SEAL server may notify the VAL server for the received UE S&F events… The VAL server may take them into consideration and adjust the traffic transmission policies…

深度解析：

  • 事件触发：当gaia-node-073的数据成功存入卫星缓存时，核心网会检测到这个事件（UE in S&F Mode），并立刻通知SEAL服务器。
  • 信息传递：核心网的通知中，会包含详尽的事件信息。例如，规范中举例：“UE已在S&F模式注册，馈线链路不可用，预计延迟10秒，当前卫星1上该UE的可用存储配额是10G…”
  • SEAL的“情报分发”：SEAL服务器收到这些来自底层的“原始情报”后，进行处理和存储，然后立即将格式化后的事件通知，推送给之前订阅了的AS。
  • AS的智能响应：阿里斯博士的数据中心收到通知后，立刻采取行动。例如，规范中提到：
    • Pend the DL data transition when the UE is in S&F Mode：如果此时正好有下行数据要发给这个UE，AS会暂停发送，因为知道UE现在收不到。
    • Pend... when the Feeder Link is not available：如果AS想通过网络发送一批数据到卫星的S&F缓存中，等待UE下次上线时接收，但在收到“馈线链路不可用”的通知后，它也会暂停发送，因为知道现在数据送不上天。
    • Transmit the DL data volume smaller than maximum S&F data storage quota：根据通知中的配额信息，智能地调整本次发送的数据量，避免“爆仓”。

第6-7-8步：SEAL扮演“智能调度员”（可选）

后续的步骤描绘了SEAL更高级的角色。在某些场景下，如果AS本身不够“智能”，它可能会在不恰当的时候，依然将下行数据发送给SEAL服务器。此时，SEAL可以扮演一个“智能调度员”的角色。

  1. The SEAL server checks the received UE S&F events status and takes the following corresponding actions… 8a. The SEAL server may send “Pending DL data” request to the VAL server… 8b. The SEAL server may send “Reject DL data” request to the VAL server… 8c. The SEAL server may send “Forward DL data with the priority” request…

深度解析：

当SEAL收到AS发来的下行数据时，它会先检查自己掌握的“物流状态”：

  • 如果UE处于S&F模式，馈线链路也断了，SEAL可以拒绝这个数据包，并告诉AS：“现在发不了，请等待”，或者将数据暂存在SEAL服务器的本地缓存中。
  • 如果数据量超出了卫星的存储配额，SEAL可以调整数据，例如只转发其中高优先级的部分。

这个机制为系统增加了一层额外的可靠性，即使上层应用不够完善，SEAL也能在中间层进行“兜底”。

2. 方案#AE4的另一半：智能配置S&F参数 (7.2.4.1.3)

除了“追踪”事件，#AE4还包含了另一项重要功能：由应用层来智能地配置S&F的网络参数。

Figure 7.2.4.1.3-1: Procedure of SEAL Server provisioning the satellite S&F configuration for the application layer

深度解析：

SA1的需求中提到，S&F的“数据保持期”和“存储配额”应该是可配置的。这个流程就定义了如何实现这种应用驱动的配置。

  • 第1步：应用提供“业务意图”

    1. The VAL server initiates a monitor traffic volume request for certain VAL UE… The service request may include… the expected data transmission period, the maximum volume of data transmission…

    阿里斯博士的数据中心向SEAL服务器表达了一个“业务意图”：“我手下的gaia-node系列传感器，预计每24小时上报一次数据，每次数据量最大不超过1MB。”

  • 第2步：SEAL进行“智能翻译”

    2. The SEAL server may take advantage of the service request… to decide the on-board S&F parameters…:

    • The maximum S&F data storage quota may be concluded based on the maximum volume of data…
    • The maximum S&F data retention per UE/service may be concluded via the data transmission period…

    SEAL服务器收到这份“业务意რობ”后，将其“翻译”成网络的配置参数：

    • “最大数据量1MB” → 翻译为 maximum S&F data storage quota = 1MB。
    • “传输周期24小时”（意味着两次连接间隔可能长达24小时）→ 翻译为 maximum S&F data retention = 24 hours。

  • 第4步：SEAL执行网络配置

    4. The SEAL server provisions the determined satellite S&F parameters to the VAL UE.

    SEAL服务器通过配置管理流程（可能需要与核心网交互），将这些计算出的参数，配置到网络和/或UE中。

这个流程实现了一个从“业务需求”到“网络配置”的自动化闭环，使得网络能够动态地、精细化地为不同的应用场景，分配最合适的S&F资源。

3. 方案评估与总结 (7.2.4.4 Solution evaluation)

This solution is for KI#7… This solution proposes how SEAL server… obtains UE S&F events information and then how such information is used by the SEAL server… to minimize the service interruption…

Furthermore, this solution also proposes how SEAL server… provisions the satellite S&F configuration…

The solution is feasible.

深度解析： 评估结论再次是高度肯定的——可行（feasible）。该方案通过“获取与暴露事件”和“应用驱动配置”两大核心能力，完整地解决了KI#7的挑战。

Solution AE8的核心价值，是为应用与网络在延迟容忍型业务上的协作，建立了一套完整的“契约”和“沟通机制”：

  1. “契约”（配置流程）：应用首先告诉网络“我的业务需求是这样的”，网络据此为其量身定制一套S&F资源（存储多久、空间多大）。
  2. “沟通机制”（订阅-通知流程）：在业务运行过程中，网络通过实时事件，不断地将数据的流转状态反馈给应用。

通过这套机制，应用服务器不再是一个被动的、盲目的数据收发者，而是一个全知的、主动的“物流系统管理员”。它能够：

  • 规划资源。
  • 追踪状态。
  • 响应变化。
  • 优化流程。

对于阿里斯博士的数据团队，这意味着他们终于有了一套强大的工具，来确保那数以百万计的、来自雨林深处的珍贵数据点，在经历漫长的太空之旅后，每一个都能被安全、可靠、高效地送达目的地。

FAQ环节

Q1：为什么需要SEAL服务器来配置S&F参数，而不是让运营商在后台直接配好？ A1：运营商的后台配置通常是静态的、粗粒度的，例如“所有IoT用户的默认存储期是48小时”。而通过SEAL，可以实现动态的、应用驱动的、精细化的配置。不同应用的需求天差地别：一个每天上报一次数据的土壤传感器，和一个每小时上报一次的关键设备状态传感器，它们所需的存储期和空间配额是完全不同的。让应用（通过VAL Server）来表达自己的“业务意图”，再由SEAL将其翻译为网络配置，可以实现网络资源的按需分配，极大地提升了整个系统的灵活性和资源利用效率。

Q2：Solution AE8提到了EPC，这与#AE4的5GC有什么不同？ A2：Solution AE8主要是为了确保S&F的应用使能能力能够后向兼容4G核心网（EPC），因为大量的物联网业务（特别是NB-IoT）目前仍然承载在EPC之上。其核心思想与#AE4完全一致，都是通过SEAL来订阅和暴露事件。不同之处在于SEAL与核心网的“南向”接口：在#AE4中，SEAL通过NEF与5GC交互；在#AE8中，SEAL则需要通过SCEF（服务能力开放功能）与EPC的MME/SGSN进行交互。对于上层的应用服务器（VAL Server）来说，它所调用的SEAL的“北向”API是完全相同、透明的，它无需关心底层是4G还是5G。

Q3：如果AS（应用服务器）订阅了事件后，自己宕机了怎么办？会丢失事件通知吗？ A3：这是一个关于系统可靠性的问题。一个设计良好的SEAL平台会包含事件缓存和重试机制。当SEAL向AS的回调URL推送事件通知失败时（例如HTTP 503错误），它不会立刻丢弃这个事件，而是会将其放入一个重试队列中，在稍后的时间（例如，以指数退避的策略）进行重试。同时，SEAL也会提供一个查询API，让AS在恢复上线后，可以主动查询其宕机期间错过的历史事件。通过“推送+重试+拉取查询”的组合，可以最大限度地保障事件通知的可靠送达。

Q4：这些S&F事件对应用开发者来说，是不是太复杂了？ A4：恰恰相反，它极大地简化了开发者的工作。在没有这套机制之前，开发者需要自己实现一套极其复杂的应用层逻辑来应对卫星的延迟和中断：包括自定义的、超长超时的ACK机制、复杂的状态机来猜测网络状态、以及应用层的数据缓存和重传逻辑。而有了SEAL提供的S&F事件API，开发者可以省去所有这些“猜测” 的工作，直接信任来自网络的权威通知，用更简洁、更可靠的代码，来实现更强大的功能。

Q5：这个“物流追踪系统”是免费的吗？运营商会如何收费？ A5：这涉及到商业模式。运营商很可能会将S&F事件的访问，作为一种增值能力（Value-Added Service） 来提供。可能会有不同的收费等级：1) 基础服务：免费或包含在套餐内，可能只提供有限的几个核心事件（如“已入S&F模式”）。2) 高级服务：付费订阅，提供更丰富、更实时的事件（如存储配额实时更新、预计送达时间精确预测），并享有更高的API调用频率和SLA保障。通过这种方式，运营商可以将网络能力货币化，而应用开发者则可以按需购买，以提升自己的服务质量。

关系图谱