51学通信

深度解析 3GPP TR 23.700-01：7.2.2 & 7.2.5 & 7.2.7 卫星边缘计算方案簇 (AE2, AE5, AE7)

22分钟阅读

好的，我们继续深入解析第7章中关于卫星边缘计算的后续解决方案。

深度解析 3GPP TR 23.700-01：7.2.2 & 7.2.5 & 7.2.7 卫星边缘计算方案簇 (AE2, AE5, AE7)

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“7.2.2 Solution AE2”, “7.2.5 Solution AE5”和“7.2.7 Solution AE7”的核心章节，旨在为读者展示在Solution AE1的宏大框架之外，3GPP为优化卫星边缘计算所探索的、一系列更加聚焦、更具针对性的增强方案。

前言：从“宏大叙事”到“精雕细琢”

在上一篇文章中，我们详细剖析了Solution AE1，它通过引入“轨迹（Trajectory）”这一核心概念，为NGSO卫星边缘计算的动态服务发现问题，提供了一套系统性的、宏大的解决方案。它解决了“如何为移动的用户规划一条通往移动的服务的路线”这一根本性难题。

然而，一个完美的系统，不仅需要有坚实的宏观架构，还需要在每一个关键环节进行精雕细琢。本篇文章，我们将聚焦于TR 23.700-01中另外三个与卫星边缘计算相关的解决方案——AE2, AE5, 和 AE7。

这三个方案，可以看作是对#AE1方案的补充、深化和变体。它们不再追求解决所有问题，而是像三位专业的“工匠”，各自拿起工具，对卫星边缘计算这条精密的“生产线”上，某几个特定的“工位”进行优化和打磨。

  • Solution AE2：专注于“服务开通”环节，探讨如何利用卫星的物理特性，让地面的“大脑”（ECS）能够更智能地为UE选择天上的“哨所”（EES）。
  • Solution AE5 & AE7：则将目光投向了“服务发现”环节，它们提出了与#AE1不同的思路，试图通过增强信息的暴露，让UE自己拥有更强的“导航”能力，从而在某些场景下简化流程、提升效率。

我们将跟随阿里斯博士，从“雨林之翼-01”无人机项目的“首席架构师”，转变为一位深入一线的“流程优化工程师”，去审视这些精巧的改进，将如何让他的无人机在启动、飞行和重连的每一个瞬间，都获得更极致的性能体验。

1. Solution AE2: 更聪明的“大脑”——增强的服务开通 (7.2.2)

Solution AE2的核心，是增强ECS（边缘配置服务器）的智能。它要解决的问题是：当地面的ECS面对茫茫星海，如何才能为UE挑选出最合适的那个星上EES？

7.2.2.1 Solution description It is proposed to add the Satellite assistant information in the EES profile to indicating the EES(s) are placed on board the satellite, so that, the ECS could do the service provisioning based on those Satellite assistant information.

深度解析：

这个方案的“手术刀”非常精准，它作用于EES Profile（EES档案）。

  1. 引入“卫星辅助信息（Satellite assistant information）”：方案建议，在EES向ECS注册时，其提交的EES Profile中，需要增加一个新的、结构化的字段，专门用来描述它所在的卫星的物理和轨道特性。
  2. 信息内容：规范中提到，这可能包括“卫星星历信息（satellite ephemeris information）”，例如时间槽和空间位置，或者更统计性的信息，如信号质量指标和轨道要素。
  3. ECS的智能决策：地面的ECS在收到UE的服务开通请求后，不再是简单地根据UE的粗略位置进行匹配。它会利用EES Profile中新增的这些精确的“卫星辅助信息”，进行一次可用性计算（availability information calculation）。

1.1 智能开通的流程

Figure 7.2.2.1.1-1: Service provisioning

  1. EEC sends Service provisioning request.
  2. ECS calculates the EES availability information based on the Satellite assistant information, and determines the EES based on the EES availability information so that the EES is accessible to the UE.
  3. ECS sends Service provisioning response (contains EES availability information).

深度解析：

这个流程相比传统流程，增加了关键的智能环节：

  • 第2步：计算！ ECS的核心增强就在这里。它不再是一个简单的“查表”服务器，而是一个具备计算能力的分析引擎。它会根据UE的位置、时间和EES Profile里的星历数据，动态地计算出每个星上EES对于这个UE的“可用性窗口”。
  • 第3步：返回“时刻表”！ ECS返回给UE的，不再仅仅是一个EES的地址，而是包含了EES可用性信息（EES availability information） 的详细“时刻表”。这与我们在KI#3中讨论的“覆盖时刻表”思想一脉相承。

对阿里斯博士的意义：

当他的“雨林之翼-01”无人机在地面准备起飞时，它的EEC向ECS发起请求。ECS通过计算后，返回一个极其有价值的响应：“在接下来的15分钟内，为你提供服务的最佳EES是EES_on_Sat-A，其可用窗口是从14:00到14:12；备选EES是EES_on_Sat-B，其可用窗口是从14:08到14:20。”

这使得UE在任务开始之初，就对未来的服务切换有了清晰的、量化的预期。

1.2 对API的增强

为了实现这一流程，方案#AE2提出，需要在EES Profile和EDN configuration information（服务开通响应的核心内容）中增加新的字段。

Table 7.2.2.1.1-1: EES Profile

  • Satellite assistant information: Assistant information indicating the EES is on-board, and could be used to calculate the satellite’s position and movement.

Table 8.3.3.3.3-2 (from TS 23.558): EDN configuration information (Referenced implicitly)

  • EES Availability information: The available information of the EES… indicates when and where the EES would be available.

深度解析：

  • 在EES注册时，通过新增的Satellite assistant information字段，向ECS提供了做出智能决策所需的“原料”。
  • 在ECS向UE响应时，通过新增的EES Availability information字段，将智能决策的“结果”下发给了UE。

这一“进”一“出”的接口增强，就构成了Solution AE2的全部核心。

2. AE5 & AE7: 更聪明的“终端”——增强的服务发现

如果说#AE2是让“大脑”（ECS）变得更聪明，那么#AE5和#AE7则探讨了另一条思路：能不能让“终端”（UE/EEC）也变得更聪明，从而在某些场景下，可以不那么依赖远在天边的“大脑”？

这两个方案的部署场景、核心思想和API增强都高度相似，我们将其合并解读。

  • AE5：关注EES在地面，EAS在天上的场景。
  • AE7：关注EES和EAS都在天上的场景（与#AE1类似）。

它们的共同核心思想是：在EAS发现阶段，让信息更透明，赋予UE更多的决策权。

7.2.5.1.1 & 7.2.7.1.1 General …in the EAS discovery procedure, the EES can determine a list of EAS based on the UE (predicted/expected) location, Prediction expiration time, Satellite ID and EAS ephemeris information and the EES provide list of EAS information in the EAS discovery response message. Upon receiving a list of EAS information, the UE can determine the EAS…

深度解析：

这里描绘的流程，与#AE1的“ECS主导规划”模式有所不同。它更强调EES和UE之间的动态协商。

  1. EES的角色增强：当UE向一个星上EES（#AE7）或地面EES（#AE5）请求服务时，这个EES不再是简单地返回一个静态的EAS地址列表。它会扮演一个“区域领航员”的角色。
  2. EES提供“带航行信息的地图”：EES的响应中，会包含一个增强的EAS列表。这个列表中的每一项，除了EAS的地址，还附带了额外的重要“航行信息”，例如：
    • Satellite ID：这个EAS在哪颗卫星上。
    • EAS ephemeris information：这颗卫星的星历数据。
  3. UE的角色增强：UE的EEC在收到这份“带航行信息的地图”后，就具备了自主决策的能力。它可以根据自己当前的位置、未来的移动计划，以及列表中每个EAS附带的“航行信息”，来自己计算和判断：
    • “EAS_1虽然信号强，但它的卫星马上要飞走了。”
    • “EAS_2所在的卫星，将能覆盖我接下来10分钟的航程，我应该选它。”
    • “当我飞到C点时，我应该重新连接EAS_3，因为它所在的卫星正好会从那里经过。”

2.1 避免重复发现的智慧

这两个方案还提出了一个非常实用的优化：利用Satellite ID来避免不必要的重复发现。

In addition, when a serving satellite is providing EAS and due to discontinuous coverage the same satellite comes back for serving, then the EEC connects to same EAS… without needing to discover EAS endpoints again.

深度解析：

这是一个针对稀疏星座非连续覆盖场景的“记忆”功能。

  • 场景：阿里斯博士的无人机，之前由Sat-A提供服务。后来Sat-A飞走了，无人机进入了短暂的“服务盲区”。几小时后，Sat-A绕地球一圈，又重新回到了服务区。
  • 传统流程：无人机会像遇到一个全新网络一样，重新发起完整的发现流程。
  • AE7优化后：无人机的EEC在其缓存中记录了：“我上次是由Satellite ID为A的卫星上的EAS_on_Sat-A提供服务的”。当它检测到重新进入覆盖区，并且广播的系统信息表明当前服务的卫星ID仍然是A时，它就会跳过发现流程，直接尝试重新连接EAS_on_Sat-A。

这个小小的“记忆”功能，极大地提升了在非连续覆盖场景下的服务恢复速度和效率。

2.2 对API的增强

为了实现上述功能，#AE5和#AE7同样提出了对Profile的增强。

Table 8.2.4-1 (in AE5) & Table 8.2.6-1 (in AE7)

  • Satellite ID: The Satellite ID corresponding to the EAS/EES.
  • ephemeris information: The ephemeris information of the satellite…

深度解析：

这两个方案的API增强点高度一致，都是要求在EAS Profile（#AE5）和EES Profile（#AE7）中，明确地加入Satellite ID和ephemeris information。

这个增强，与#AE1中加入Trajectory ID的思路异曲同工，但侧重点不同：

  • AE1的Trajectory ID：更抽象，像“公交线路号”，主要服务于地面的ECS进行宏观的、多步的旅程规划。
  • AE7的Satellite ID + ephemeris：更具体，像“车辆的实时GPS坐标”，主要服务于UE和本地EES之间，进行实时的、战术性的路径选择。

3. 方案评估与比较

Solution evaluation (#AE2, AE5, AE7) The solution is feasible. Editor’s note: The procedures and the use of the satellite ID and ephemeris information in the procedures is FFS.

深度解析：

  • 可行性：这三个方案都被认为是“可行（feasible）”的，表明它们在技术逻辑上是成立的。
  • FFS（For Further Study）：编者注中提到，具体如何使用这些新增信息（Satellite ID, ephemeris）的详细流程，还需要进一步的研究。这再次体现了TR的探索性质。

方案簇比较

方案核心思想谁更“聪明”？优点缺点适用场景
AE1基于“轨迹ID”的宏观旅程规划ECS (地面大脑)规划性强，适合有明确计划的长任务初始开销大，依赖UE上报计划航班、货轮、长航时无人机
AE2基于“星历”的智能服务开通ECS (地面大脑)在初始阶段就提供可用性预测，优化首次连接聚焦于开通环节，对后续发现影响不大所有场景的首次服务建立
AE7基于“Satellite ID/星历”的实时自主导航UE/EES (终端/哨所)灵活性高，实时性好，能快速恢复连接缺乏全局规划，可能导致“局部最优”选择随机移动的UE、非连续覆盖下的重连

4. 总结：工具箱中的多样化利器

如果说Solution AE1是卫星边缘计算解决方案中的“主战坦克”，它系统性、全局性地解决了核心挑战。那么，#AE2、#AE5和#AE7就是工具箱中三件小巧而锋利的“特种工具”：

  • AE2 是一把“卡尺”，它在服务开通的源头，就对服务的可用性进行了精确的测量和预测。
  • AE5 和 AE7 像是一部“GPS导航仪”和一本“航行日志”，它们赋予了UE更强的自主导航和记忆能力，让它在动态变化的星海中，能够更敏捷、更高效地找到回家的路。

这三个方案，与#AE1并非互相排斥，而是高度互补的。一个完善的、成熟的5G卫星边缘计算系统，很可能会将它们的核心思想进行融合：

  1. 在服务开通时，采用**#AE2**的智能计算，为UE提供初始的可用性信息。
  2. 对于有长远规划的任务，采用**#AE1**的轨迹匹配，下发全局的服务路线图。
  3. 在实时飞行和连接恢复时，利用**#AE5/#AE7**的机制，进行敏捷的本地发现和快速重连。

通过这一套“组合拳”，3GPP为阿里斯博士的“雨林之翼”无人机，打造了一套全方位、多层次的智能服务保障体系，确保了它在每一次起飞、每一次转向、每一次信号重连的瞬间，都能得到最优的网络支持。

FAQ环节

Q1：为什么#AE5要把EES放在地面，而EAS放在天上？这种部署有什么特别的考虑吗？ A1：这种部署模式考虑的是一种成本和能力的平衡。EES作为区域的“服务目录”，其逻辑相对复杂，且可能需要与地面的ECS进行频繁的同步。将其部署在地面，可以利用地面数据中心强大的计算和存储能力，也便于维护升级。而EAS，特别是像AI推理这种对延迟极度敏感的应用，则必须部署在离用户最近的卫星上。这种“哨所在地面，前线工厂在天上”的模式，是一种在技术现实和性能需求之间进行折衷的、非常务实的部署选项。

Q2：“星历信息（ephemeris information）”由谁提供，更新频率有多高？ A2：星历信息由卫星运营商的地面运控中心精确测量和计算后提供。它是描述卫星在特定时间精确位置和速度的一组数据。对于需要高精度定位和预测的场景，星历信息需要被频繁更新，可能是几分钟到几小时一次。在Solution AE2和AE7的架构中，这些信息会由运营商后台实时地推送给5G系统的相关网元（如ECS、EES），以确保决策的准确性。

Q3：UE如何根据EAS列表和星历信息，自主决策选择哪个EAS？这对UE的能力有什么要求？ A3：UE的EEC（边缘使能客户端）需要内置一个轻量级的“轨道预测和决策引擎”。当它收到包含多个EAS及其星历信息的列表后，它会：1) 运行一个简化的轨道模型，预测出每个EAS所在的卫星，在未来一段时间内相对于UE自身的轨迹（何时可见、仰角多高、距离多远）。2) 结合UE自身的移动计划。3) 根据一个预设的策略（例如，“选择总可用时间最长的”、“选择未来5分钟内平均信号质量最好的”）做出最优选择。这对UE的计算能力有一定要求，但这些计算相对简单，现代智能手机或专用终端的处理器完全可以胜任。

Q4：这些方案都提到了“Editor’s note: FFS (For Further Study)”。这是否意味着这些方案还不成熟，可能不会被采纳？ A4：“FFS”在3GPP的TR（技术报告）中非常常见，它不代表方案不成熟，而是代表研究的严谨性。TR的目的是“探路”，它负责提出创新的、可行的宏观思路（如“通过暴露星历来赋能UE决策”）。但这个思路具体落地成标准时的每一个细节（如星历的数据格式、API的具体参数、流程中的每一个异常处理等），都需要在后续的“标准化工作（Normative Work）”阶段，在对应的TS（技术规范）中，经过所有成员公司逐行逐句的详细讨论和确认。FFS正是为这些后续的、更精细的工作，预留出了空间。

Q5：Solution AE1、#AE2、#AE5、#AE7，哪个方案最终会成为标准？ A5：很可能都不是以“单一方案”的形式成为标准，而是它们的核心思想会被融合吸收到最终的TS 23.558（EDGEAPP）的演进版本中。标准化过程是一个“取其精华、融会贯通”的过程。最终的标准很可能会：采纳#AE1的Trajectory ID作为宏观规划的工具；采纳#AE2的服务开通可用性计算流程；采纳#AE5/#AE7的Satellite ID和星历信息作为战术性发现和快速重连的依据。它们共同构成了解决NGSO边缘计算挑战的完整“答案集”。

关系图谱