51学通信

深度解析 3GPP TR 23.700-01：7.2.1 解决方案#AE1：当边缘计算遇见移动的卫星

21分钟阅读

好的，遵照您的指令，我们继续对规范第7章中关于应用使能器的解决方案进行深度解析。由于内容较长，我们将按照逻辑，首先聚焦于与卫星边缘计算相关的解决方案。

深度解析 3GPP TR 23.700-01：7.2.1 解决方案#AE1：当边缘计算遇见移动的卫星

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“7.2.1 Solution AE1: Satellite edge computing”的核心章节，旨在为读者详细拆解3GPP如何通过增强现有的EDGEAPP架构，来应对在高速移动的NGSO卫星上部署、发现和使用边缘服务的复杂挑战。

前言：为“天空列车”上的乘客规划“服务路线图”

在前面的章节中，我们已经深刻理解了在高速移动的NGSO卫星（KI#5）上部署边缘计算的巨大潜力与严峻挑战。它不再是KI#2中那个静止的“天空灯塔”，而是一列列飞驰的“天空列车”。对于需要使用星上服务的用户（如阿里斯博士的“雨林之翼-01”无人机）来说，这带来了一个前所未有的难题：

我该上哪趟车？上了车之后，下一站又该换乘哪趟车？

传统的、为地面固定边缘节点设计的服务发现机制，在这种“用户在动，服务器也在动”的双重移动场景下，彻底失效。它无法回答上述问题，只会导致频繁的服务中断和糟糕的用户体验。

Solution AE1，是3GPP SA6为解决这一核心矛盾而提出的第一个、也是最系统的一个解决方案。它的核心思想，是将一次边缘服务的交互，从一次性的“找餐馆”，升级为一次动态的、贯穿全程的“规划服务路线图”。这套方案通过引入“轨迹（Trajectory）”这一关键概念，并将其深度整合到服务开通（Provisioning）和发现（Discovery）的每一个环节，为动态世界中的边缘计算，提供了前所未有的智能与可预测性。

1. 场景与架构：大脑在地面，哨所和服务在太空 (7.2.1.1.1 General)

在提出具体方案前，首先要明确我们讨论的场景和架构部署模型。Solution AE1选择了一种非常典型且现实的混合部署模式。

Figure 7.2.1.1.1-1: satellite EDN deployment In this deployment option, ECS is deployed on ground… UPF to access satellite EDN is deployed on satellite, EAS and EES are deployed in one or more satellites. RAN (e.g. gNB) can either be deployed on ground/sea… or be deployed on regenerative satellite…

深度解析：

这张架构图（我们不重绘，但解读其精髓）描绘了如下部署场景：

  • “大脑”在地面（ECS on ground）：边缘配置服务器（ECS），作为整个系统的最高指挥官和策略中心，部署在运营商的地面数据中心。
  • “哨所”和服务在太空（EES and EAS on satellite）：负责区域服务发现的“哨所”——边缘使能服务器（EES），以及提供具体应用的“工厂”——边缘应用服务器（EAS），都部署在卫星上。
  • UPF也在太空：用户面功能（UPF）也部署在卫星上，这使得星上EAS与UE之间的超低延迟数据闭环成为可能。
  • UE在移动：用户（如无人机）可能在地面、海上或空中移动。

这个部署模型非常清晰地模拟了阿里斯博士的“雨林之翼-01”无人机项目。无人机需要连接卫星上的“飞行控制AI”（EAS），而整个服务的配置和初始引导，则由地面的运营商数据中心（ECS）来完成。

初始服务发现的挑战：

During initial service discovery, the EEC (in UE) contacts the ECS via EDGE-4 (on ground or via space) to find an appropriate EES, then an appropriate EAS instance is selected during EAS discovery via EDGE-1 interaction.

这段话描述了未经优化的流程，其痛点在于，UE第一次找服务，必须先通过一次漫长的星地往返，联系到地面的ECS，问到EES的地址后，再回来联系卫星上的EES。这正是#AE1方案要着力优化的起点。

2. 引入“轨迹”：从静态匹配到动态规划

为了解决双重移动问题，#AE1方案引入了“轨迹（Trajectory）”这一核心概念，并将其贯穿于服务开通和发现的始终。

2.1 为移动的EAS/EES赋予身份：轨迹ID

7.2.1.1.3 EAS discovery for EAS on board satellite …for MEO and LEO satellites, the EAS(s) are mobile… This can be accomplished by adding mobility information and trajectory ID for the EAS in its profile.

  1. EAS mobility: to indicate the mobile EASs… and non-mobile EAS…
  2. Trajectory ID: to indicate the trajectory of the EAS on board MEO and LEO satellites. This trajectory ID is unique for each satellite and its trajectory.

7.2.1.1.4 Service provisioning for EES on board satellite Similar to EAS on board a MEO or LEO satellite, the EES will also be mobile…

  1. Dynamic service area indication: Indicates if the service area is dynamic or not.
  2. Trajectory ID: to indicate the trajectory of the EES on board MEO and LEO satellites.

深度解析：

这是方案的第一个关键增强点：为所有部署在NGSO卫星上的EAS和EES，增加一个新的身份标识——轨迹ID（Trajectory ID）。

  • 轨迹ID是什么？ 它是一个由卫星运营商生成的、唯一的字符串，用于标识一颗卫星及其精确的运行轨道。同一个星座中，每一颗卫星的轨迹ID都是不同的。
  • 它有什么用？ 它将一个物理上高速移动的、难以捉摸的服务器，抽象成了一个逻辑上稳定、可预测的实体。我们不再关心这颗卫星此刻的经纬度，我们只关心它的“路线编号”，就像我们关心一趟公交车是“302路”而不是它此刻在哪条街上一样。
  • 如何实现？ 解决方案提出，需要在现有的EAS Profile（TS 23.558 Table 8.2.4-1）和EES Profile（Table 8.2.6-1）中，增加Trajectory ID和Dynamic service area indication这两个新的信息元素（IE）。

2.2 智能的服务开通（Provisioning）：匹配UE与卫星的轨迹

有了“轨迹ID”这个工具，服务开通（Provisioning）过程就从一次简单的信息查询，升级为一次智能的“行程匹配”。

The “Expected AC Geographical Service Area” in the AC profile… can be used by the ECS to request the external server (by the satellite service provider or operator) with list of trajectory IDs that match the UEs planned route and its location. The ECS then uses the list of the trajectory ID for the UE to provision EES(s) by matching the trajectory IDs in the EES profile with the list of the trajectory ID determined for the UE…

深度解析：

这个过程描绘了一幅极其智能的交互图景：

  1. UE上报“我的行程”：阿里斯博士的无人机在起飞前，将其计划的飞行路线（planned route），包含在一份AC Profile（应用客户端档案） 中，发送给地面的ECS。
  2. ECS请求“卫星行程”：ECS收到无人机的路线后，转身向卫星运营商的后台系统（external server）发起一个请求：“请给我一份能够覆盖这条飞行路线的、所有卫星的‘轨迹ID列表’”。
  3. ECS进行“行程匹配”：ECS拿到了无人机路线对应的“卫星轨迹ID列表”，然后在其注册的所有EES中，寻找那些EES Profile中也包含了这些轨迹ID的EES。
  4. ECS下发“服务路线图”：ECS最终向无人机返回一个经过精心规划的服务开通响应。这个响应不再是“请联系这个EES”，而是“在你的航程中，你将依次遇到轨迹ID为A、B、C的EES，它们的地址分别是…”。

通过这个过程，一次性的服务开通，就为无人机的整个任务，提供了一份可预测的、多步的服务切换路线图。

2.3 优化的EAS发现（Discovery）：按“路线图”寻找服务

拿到了这份“服务路线图”后，后续的EAS发现过程也变得极为高效。

The Trajectory ID provided during the service provisioning response… can be provided by the EEC in the EAS discovery filters… In case of EAS and EES deployed on the same satellite, the Trajectory ID provided matches the Trajectory ID of both EAS and the EES on board the satellite.

深度解析：

  1. UE按图索骥：无人机的EEC不再是盲目地向周围的EES广播“我需要服务”，而是带着明确的目的，向“服务路线图”中当前阶段的那个EES（例如，轨迹ID为A的EES）发起一个定向的EAS发现请求。
  2. 在请求中加入“轨迹过滤器”：更进一步，无人机可以在EAS发现请求的过滤器（filters） 中，直接加入自己后续航程所需的“轨迹ID”。
  3. EES的智能响应：卫星上的EES收到这个请求后，就可以返回一个同样经过智能规划的EAS列表。例如：“在你当前所在的这颗卫星上，有EAS-1可用；当你10分钟后切换到下一颗卫星（轨迹ID为B）时，那里有EAS-2在等你。”

方案总结（见7.2.1.3.1）：

规范最终通过修改三张核心表格，将上述思想落地为具体的标准增强：

  • Table 8.2.4-1: EAS Profile：增加Dynamic service area indication和Trajectory ID (NOTE 1)。
  • Table 8.2.6-1: EES Profile：增加Dynamic service area indication和Trajectory ID (NOTE 2)。
  • Table 8.5.3.2-2: EAS discovery filters：在过滤器中，增加一个可以按Trajectory ID进行筛选的字段。

3. 方案评估：可行且有效 (7.2.1.4 Solution evaluation)

在提出了这套精巧的、基于“轨迹”的解决方案后，规范对其进行了评估。

This solution is for KI#2 and addresses the open issue about deployment option for EDGEAPP and related enhancements to the EDGEAPP procedures… The solution does not impact the architecture entity in EDGEAPP.

…EEC contacts the ECS to find appropriate EES and EAS is discovered considering trajectory of the EES and EAS using Trajectory ID to match with the movement of the UE, to avoid frequent interruption, and/or service degradation.

The solution is feasible.

深度解析：

评估结论是清晰而积极的：

  1. 解决了问题：该方案有效地解决了在动态NGSO场景下，边缘服务部署、开通和发现的核心难题。
  2. 无架构影响：它遵循了第6章确立的“复用和增强”原则，没有引入新的功能实体或参考点，对现有EDGEAPP架构（TS 23.558）是向前兼容的。
  3. 核心价值：其核心价值在于，通过匹配UE和卫星的轨迹，实现了可预测的服务规划，从而避免了频繁的服务中断和服务质量下降。
  4. 最终结论：可行（feasible）。这意味着，这个方案已经足够成熟和清晰，可以作为后续标准化工作（Normative Work）的基础。

4. 总结：为双重移动世界绘制“动态地图”

Solution AE1是整份TR 23.700-01中，最具代表性和系统性的解决方案之一。它直面了NGSO卫星边缘计算最核心的“双重移动”挑战，并给出了一个优雅而深刻的答案。

这个答案的核心，就是将“轨迹”这一概念，提升到了与“地址”同等重要的地位。

  • 在静态的地面世界，我们通过地址（IP Address, FQDN） 来定位服务。
  • 在动态的天基世界，我们必须通过“轨迹ID”，来规划一条通往服务的路线。

通过对EDGEAPP的服务开通和发现流程进行端到端的增强，#AE1方案成功地构建了一套“动态服务地图”系统。这套系统能够：

  1. 理解用户（UE）的移动意图（planned route）。
  2. 匹配星座（Satellites）的运行规律（Trajectory ID）。
  3. 生成一份个性化的、多步的“服务路线图”（provisioning response）。
  4. 引导用户沿着这份路线图，无缝地、高效地获取服务。

对于阿里斯博士和他的“雨林之翼-01”无人机，这意味着它终于有了一位聪明的“太空领航员”。这位领航员不仅能告诉它当前的服务在哪里，更能为它规划好未来整个旅程中，所有服务的“换乘站点”。这，正是实现高动态、广域覆盖场景下，智能边缘服务的关键所在。

FAQ环节

Q1：“轨迹ID（Trajectory ID）”和“卫星ID（Satellite ID）”有什么区别？ A1：卫星ID是一个静态的标识，就像一辆车的“车牌号”，它唯一地标识了这颗物理卫星实体。而轨迹ID是一个动态的、与轨道相关的标识，更像是这辆车的“公交线路号”（例如“302路”）。一颗卫星在其生命周期中，可能会因为轨道调整等原因，被分配到不同的轨道平面或任务中，此时它的轨迹ID可能会发生变化，但卫星ID不变。在服务发现中，我们更关心的是它的“线路”，即它将飞往哪里，而不是它的“车牌”。

Q2：如果UE（比如无人机）没有一个“计划好的路线”，这个方案还能工作吗？ A2：可以，但效果会打折扣。如果UE无法提供计划路线，它仍然可以上报其当前的实时位置。地面的ECS可以基于这个当前位置，为其匹配一个“当前最优”的EES。但这只能解决“现在”的问题，无法进行前瞻性的规划。UE下一次请求服务时，可能又需要重新走一遍发现流程。因此，这个方案对于有可预测轨迹的UE（如航班、远洋货轮、按规划路线飞行的无人机） 价值最大。对于随机移动的UE，虽然也能用，但无法发挥其全部威力。

Q3：谁来负责计算和生成这些“轨迹ID”？这个过程复杂吗？ A3：生成和管理轨迹ID是卫星网络运营商的责任。这个过程非常复杂，它需要基于精确的卫星星历数据（Ephemeris），通过专业的轨道动力学模型进行计算。运营商的后台系统（报告中称为“external server”）会维护一个实时的“轨道数据库”，并将这些轨道抽象成标准化的“轨迹ID”，通过安全的接口提供给5G核心网的ECS等功能实体。对于5G系统和应用开发者来说，他们是轨迹ID的“消费者”，无需关心其背后的复杂计算。

Q4：这个方案对星间链路（ISL）有依赖吗？ A4：这个方案本身（#AE1）的核心在于服务发现和开通，它不直接依赖星间链路。它解决的是“如何找到服务”的问题。但是，它所服务的业务（比如我们在KI#5中讨论的服务连续性），则严重依赖星间链路。例如，当无人机从Sat-2切换到Sat-4时，#AE1方案帮助它提前“知道”要去Sat-4找服务。而应用会话上下文的无缝迁移，则需要通过Sat-2和Sat-4之间的星间链路来完成。它们是解决同一个大问题的、不同层面的两个关键技术。

Q5：这个方案对UE的功耗有什么影响？ A5：有积极的影响。通过一次性的、前瞻性的服务开通，UE可以获得一份未来一段时间的服务路线图。这避免了在任务过程中，因为卫星飞过、连接中断而需要频繁地、盲目地重新发起服务发现流程。每一次完整的服务发现都涉及到大量的无线信令交互，是主要的功耗来源之一。通过“规划”，UE的无线行为变得更加高效和“有的放矢”，从而有助于降低整体功耗。

关系图谱