好的，我们继续深入探索3GPP的星辰大海。

深度解析 3GPP TR 23.700-01：4.5 关键问题#5：当“天空之城”开始移动 (Edge on board NGSO Satellite)

本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“4.5 Key issue #5: Edge on board NGSO Satellite”的核心章节，旨在为读者揭示在高速移动的非对地静止轨道（NGSO）卫星上部署边缘计算所面临的独特且深刻的挑战。

前言：从静止的灯塔到飞驰的列车

在前面的篇章中，我们已经探讨了将边缘计算部署在GEO卫星（KI#2）上的构想。GEO卫星如同一座悬于天际的、静止的“灯塔”，其网络拓扑是稳定和可预测的。然而，为了追求更低的延迟和更高的带宽，通信的未来正越来越多地寄望于由成百上千颗低轨（LEO）或中轨（MEO）卫星组成的非对地静止轨道（NGSO）星座。

这带来了一个全新的维度——移动。这些卫星不再是静止的灯塔，而是以每小时超过27,000公里的速度飞驰的“天空列车”。将边缘计算平台（EAS/EES）部署在这些高速移动的列车上，无疑将带来革命性的性能提升，但也引入了前所未有的复杂性。

这便是3GPP SA6研究的第五个关键问题（KI#5）——NGSO卫星上的边缘计算。它不再是KI#2的简单重复，而是将其置于一个高度动态、瞬息万变的环境中进行拷问。为了应对这一挑战，我们的主角阿里斯博士启动了一个更激进、对网络性能要求也更极致的子项目——“雨林之翼-01（Rainforest Wing-01）”，一架需要实时AI辅助飞行的无人机，用于穿梭在复杂的雨林冠层之下。这架无人机的生死，将完全系于NGSO卫星边缘计算的毫秒级响应能力之上。

1. 速度与激情：NGSO边缘计算的极致诱惑 (4.5.1 Description)

为何要挑战在NGSO卫星上部署边缘计算这一难题？规范在4.5.1节的描述中给出了直接的答案——追求极致的低延迟。

NGSO satellites are satellites moving with respect to the earth surface and they can be deployed in MEO (8,000 km – 20,000 km) or LEO (400 km – 2000 km) orbits. This will reduce the one way latency. To utilize these reduced latencies UPFs as well as gNBs can be deployed on the NGSO.

深度解析：

这段描述的核心就是“reduce the one way latency”。NGSO卫星，特别是LEO卫星，其轨道高度极低，这意味着信号往返的时间被压缩到了极致。

让我们再次回顾那个决定性的延迟数据：

• GEO卫星单向延迟：~120-140 ms
• LEO卫星单向延迟：~3-15 ms

这个数量级的差异，对于某些应用来说，是“可用”与“不可用”甚至“生”与“死”的区别。

“雨林之翼-01”的生死毫秒：

阿里斯博士的“雨林之翼-01”无人机，其任务是贴近地面飞行，利用激光雷达和高清摄像头，绘制雨林下层植被的三维地图。这个环境充满了不可预测的障碍物：突然倒下的树木、茂密的藤蔓、飞过的鸟群。

• 飞行控制模型：无人机的飞行控制AI（一个EAS应用）需要实时处理机载传感器传回的数据，并以毫秒级的速度向无人机下发规避指令。
• GEO边缘计算的局限：如果这个AI应用部署在GEO卫星上，一次完整的“感知-决策-响应”回路，将经历至少240ms的星地往返延迟。假设无人机以36公里/小时（即10米/秒）的速度飞行，在这240ms的“反应时间”里，它已经向前飞行了2.4米。这足以让它一头撞上任何突然出现的障碍物。
• LEO边缘计算的优势：现在，将这个AI应用部署在飞过无人机上空的LEO卫星上。一次完整的交互回路，延迟可能被压缩到20ms以内。在这20ms里，无人机只向前移动了20厘米。这个距离，为成功规避障碍留下了充足的余地。

规范中还提到，可以将UPF（用户面功能）和gNB（5G基站）也部署在NGSO卫星上。这被称为“再生载荷（Regenerative Payload）”，意味着卫星本身就是一个功能完备的、移动的5G基站。这使得“无人机 → LEO卫星（gNB→UPF→EAS） → 无人机”的超低延迟闭环成为可能。

2. 动态世界中的四大难题 (4.5.2 Open issues)

极致的性能诱惑背后，是极致的技术挑战。规范在4.5.2节中，一针见血地指出了在动态的NGSO环境中部署边缘计算所必须解决的四大核心难题。

2.1 难题一：服务器的部署策略 (EES/EAS Placement)

• How the EES(s) are placed on board the Satellite.
• How the EAS(s) are placed on board the Satellite.

深度解析：

这个问题探讨的是边缘计算组件在整个卫星星座中的分布策略。一个NGSO星座由数十到数千颗卫星组成，我们该如何部署EES（边缘使能服务器）和EAS（边缘应用服务器）？

• 策略A：普遍部署 (Ubiquitous Deployment)

  • 方案：星座中的每一颗卫星，都搭载相同的、全套的EES和EAS实例。
  • 优点：最简单直接。无论UE连接到哪颗卫星，都能获得一致的服务。服务发现和连续性问题相对简单。
  • 缺点：成本极高，资源浪费。并非所有应用都需要在所有卫星上运行。这好比为了让一个城市的每个路口都能叫到出租车，就在每个路口都停放一排出租车，显然不经济。

• 策略B：功能性分层部署 (Functional Tiered Deployment)

  • 方案：星座中的卫星被赋予不同角色。例如，所有卫星都部署轻量级的EES用于服务发现，但只有一部分拥有更强计算能力的“增强型”卫星，才部署资源消耗大的EAS（如AI推理服务器）。
  • 优点：资源利用率高，成本可控。
  • 缺点：架构更复杂。当UE连接到一颗没有EAS的“普通”卫星时，它的业务请求可能需要通过星间链路（Inter-Satellite Link, ISL） 转发到最近的“增强型”卫星去处理，这会引入额外的延迟和路由复杂性。

2.2 难题二：如何找到飞驰的服务器？(Discovery and Provisioning)

• Whether and how the discovery and the service provisioning are impacted.

深度解析：

这是KI#5的核心挑战之一。在地面边缘计算中，EAS是静止的，UE发现它，就像在地图上找一个固定的餐馆。但在NGSO场景下，UE在移动，EAS所在的卫星也在高速移动。这变成了一个动态的“移动目标拦截”问题。

“雨林之翼-01”的启动时刻：

1. 无人机在A点开机，它的EEC需要找到最优的“飞行控制AI”服务。
2. 此时，头顶上有三颗LEO卫星（Sat-1, Sat-2, Sat-3）都可见。Sat-1离得最近，信号最好，但1分钟后就要飞出服务区。Sat-2信号稍弱，但能提供长达8分钟的稳定覆盖。Sat-3上没有部署所需的AI应用。
3. 无人机计划的飞行路线将使其在5分钟后进入Sat-4的覆盖范围。

一个“愚笨”的发现机制会简单地选择信号最强的Sat-1，结果1分钟后连接中断，无人机失控。

一个“智能”的发现与服务开通（Provisioning）机制必须是预测性的和轨迹感知的：

• 输入：UE（无人机）上报自己的计划飞行路线。地面的ECS（边缘配置服务器）掌握整个星座的实时轨道数据。
• 决策：ECS进行一次复杂的时空联合计算，得出一个最优的**“服务卫星序列”**。
• 输出：ECS向无人机下发一个服务配置：“在航程的前5分钟，请连接Sat-2上的EAS（地址XXX）；在第5分钟，请准备切换到Sat-4上的EAS（地址YYY）”。
• 影响：整个服务发现和开通过程，从一次性的、静态的查询，演变为一次动态的、贯穿任务全程的**“旅程规划”**。这要求对现有的EDGEAPP（TS 23.558）的服务发现流程进行重大增强。

2.3 难题三：如何在列车间无缝换乘？(Service Continuity)

• Whether and how the service continuity procedures are impacted while the UE is only connected with NTN.

深度解析：

这个问题探讨的是卫星切换（Handover） 期间，如何保证边缘业务的连续性。这比传统的网络层切换要复杂得多。网络层切换只保证IP地址不变，数据链路不断。但对于边缘计算，我们还需要保证应用会话（Application Session） 的连续。

“雨林之翼-01”的飞行途中： 无人机正由Sat-2提供服务，飞行控制AI在Sat-2上运行得很好。现在，它即将飞出Sat-2的覆盖区，进入Sat-4的范围。

• 挑战：Sat-2上的AI已经根据前几分钟的传感器数据，在内存中建立了一个关于周围环境的实时3D模型。如果切换到Sat-4时，Sat-4上的AI实例是从零开始的“冷启动”，它对环境一无所知，可能会做出错误的判断。
• 解决方案：必须实现应用上下文（Application Context）的迁移。在网络层切换的同时，Sat-2上的EAS需要将关键的会话状态数据（即那个3D模型、无人机的飞行状态向量等“记忆”）通过星间链路（ISL）快速地传递给Sat-4上的EAS实例。Sat-4的EAS用这个上下文来“预热”自己，从而实现无缝接管。

这个过程对星间链路的带宽和延迟，以及对EAS应用本身的可迁移性设计，都提出了极高的要求。

2.4 难题四：应用本身能否“随风而动”？(EAS Relocation)

• Whether and how the EAS can be relocated while the UE can be connected with NTN/TN.

深度解析：

这是最前沿、也最具挑战性的一个问题。它探讨的不仅是应用上下文的“迁移”，而是整个应用实例（EAS instance）的动态“搬家”。

场景想象： “雨林之翼-01”的飞行任务非常关键，运营商决定为其提供“VIP”服务。

• 问题：无人机的飞行路线非常灵活，可能会临时改变，无法提前完美规划出“服务卫星序列”。
• EAS重定位（Relocation）方案：
  1. 一个强大的地面边缘编排器（Edge Orchestrator） 实时监控无人机的位置和星座状态。
  2. 当编排器预测到无人机即将切换到Sat-4时，它会主动发出指令。
  3. 这个指令不是让Sat-4启动一个新的AI实例，而是将当前运行在Sat-2上的整个EAS容器（Container），“动态迁移”到Sat-4上。
  4. 这就像云计算中的虚拟机热迁移（vMotion），但在以27,000公里/小时运行的卫星之间进行。

这种动态重定位，可以确保应用永远运行在离UE最近的、最优的卫星节点上，实现了极致的服务伴随（Service Following）。这需要网络、编排层和应用本身之间极度紧密的协同，是NGSO卫星边缘计算的终极形态。

3. 总结：为动态世界构建敏捷大脑

“关键问题#5”将我们带入了卫星边缘计算最激动人心、也最富挑战性的前沿。它将KI#2的静态“天空之城”，变成了一支高速移动、协同作战的“天空舰队”。

面对NGSO星座的“移动”这一核心特性，3GPP的研究指出，解决方案必须从根本上转变思维：

• 从静态到动态：部署策略必须考虑星座的整体性和功能分层。
• 从被动到预测：服务发现必须基于UE和卫星的双重轨迹进行智能规划。
• 从连接到会话：服务连续性必须超越网络层，实现应用上下文的无缝迁移。
• 从固定到流动：终极形态是实现应用实例本身的动态重定位，构建一个真正敏捷、随需而动的太空边缘云。

解决这些难题，将为无人机、自动驾驶船舶、物联网等需要在广域范围内实现超低延迟智能服务的应用，打开一个全新的可能性空间。阿里斯博士的“雨林之翼”能否自由翱翔，取决于我们能否为这个动态的世界，构建一个同样敏捷、智能的“天空大脑”。

---

FAQ环节

Q1：LEO和MEO卫星在部署边缘计算时，各有什么优劣？ A1：LEO（低轨）的优势是极致的低延迟（<15ms单向），非常适合像“雨林之翼”无人机这种需要实时反应的应用。但其缺点是单颗卫星的覆盖范围小、过境时间短，导致需要非常频繁的切换，对服务连续性挑战极大。MEO（中轨）的优势是轨道更高，单颗卫星覆盖范围大、可见时间长（可达数小时），因此切换频率低，服务连续性更容易保障。但其代价是延迟相对较高（27-43ms单向），虽然远好于GEO，但可能无法满足最严苛的实时控制应用。因此，选择LEO还是MEO，取决于应用对延迟和连续性的权重平衡。

Q2：什么是星间链路（Inter-Satellite Link, ISL），它在NGSO边缘计算中为什么如此重要？ A2：星间链路，就是卫星与卫星之间直接通信的激光或毫米波链路。它将整个星座编织成一个太空中的“网状网络（Mesh Network）”。在NGSO边缘计算中，ISL扮演着“太空高速公路”的角色，其重要性体现在：1) 支撑应用上下文迁移：在服务连续性场景中，Sat-2上的EAS必须通过ISL，将“记忆”快速传给Sat-4。2) 实现功能性分层部署：当UE连接到没有EAS的“普通”卫星时，它的业务请求可以通过ISL，被路由到最近的“增强型”卫星进行处理。没有高速、低延迟的ISL，NGSO边缘计算的很多核心优势将无法实现。

Q3：应用上下文（Application Context）到底指什么？迁移它有多难？ A3：应用上下文，就是应用在处理一个会话时，保存在其内存中的所有状态信息。对于“雨林之翼”的飞行AI，上下文可能包括：已经构建的周边环境3D点云地图、无人机当前的姿态/速度/加速度向量、AI模型内部神经网络的权重状态、以及正在执行的任务指令序列等。迁移它的难度在于：1) 实时性：必须在两次通信的间隙（毫秒级）内完成，否则就会造成业务中断。2) 一致性：要确保迁移过去的数据是完整和一致的。3) 应用设计：应用本身必须被设计成“无状态”或“易于状态分离”的，才能方便地将其上下文打包和迁移。传统的单体式应用很难做到这一点。

Q4：谁来负责管理和决策如此复杂的卫星切换和EAS重定位？ A4：这通常由一个被称为“编排器（Orchestrator）”的后台大脑来负责。在5G边缘计算中，这可能是增强版的MECo（移动边缘计算编排器）或ECS。这个编排器会从网络（核心网、RAN）获取UE和网络的实时状态，从应用层获取业务需求，并掌握整个卫星星座的拓扑和资源信息。它基于这些全局视图，利用复杂的算法做出最优决策，例如决定何时触发切换、上下文应该迁移到哪颗卫星、甚至是否需要重定位整个EAS实例。

Q5：这些NGSO卫星边缘计算技术是纯理论研究，还是已经有实际部署了？ A5：目前正处于从前沿研究走向早期商业实践的阶段。像SpaceX的Starlink、Amazon的Kuiper等巨型LEO星座，已经建设了包含ISL的强大物理网络基础。微软等云服务商已经与卫星运营商合作，推出了“Azure Space”等产品，尝试将云服务延伸至太空，其中就包含了边缘计算的早期形态（如在地面关口站部署边缘节点）。3GPP的这项工作，其核心价值在于标准化，即定义一套通用的架构和接口，让任何应用开发者、任何设备制造商、任何运营商，都能基于一套共同的“语言”来开发和部署NGSO边缘计算业务，从而推动整个生态的成熟和繁荣。