好的，我们继续解读TR 21.918的后续章节。

深度解析 3GPP TR 21.918：8.2 Architecture for UAS Applications, Phase 2 (无人机系统应用架构第二阶段)

本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“8.2 Architecture for UAS Applications, Phase 2”的核心章节，旨在为读者深度剖析5G网络如何从底层的通信使能，迈向高层的应用赋能，为无人机（UAS）提供一个标准化的、智能的应用层架构（UAE）。

在上一篇文章中，我们跟随首席架构师王工，了解了5G-Advanced如何通过A2X通信框架，为低空无人机提供了“电子车牌”（BRID）、“精准遥控”（Direct C2）和“协同防撞”（DAA）等关键的底层通信能力。这些能力解决了无人机“如何安全地说话”的问题。然而，对于一个复杂的无人机应用生态系统而言，仅仅能“说话”是远远不够的。

今天，我们的主角，依然是“空域数智”公司的首席架构师王工。他面临着一个更棘手的挑战：他的客户——一家大型跨国物流公司，计划开通一条从深圳到香港的无人机跨境物流航线。这意味着，一架无人机在飞行途中，其监管方可能会从深圳的无人机服务供应商（USS）变更为香港的USS。同时，为了规避繁忙的商业航班，无人机需要实时获取周边其他飞行器（包括无人机和民航客机）的动态信息。

这些复杂的应用场景，已经超出了底层通信的范畴，需要在应用层进行统一的抽象和调度。这正是8.2章节的核心——定义一个无人机应用使能层（UAS Application Enabler, UAE），作为连接上层航空应用与底层3GPP网络的“智能中间件”。

1. UAE的使命：超越通信，赋能应用

如果说A2X是为无人机铺设的“信息公路”，那么UAE层就是在这条公路上运行的“智能交通系统（ITS）”。

As part of Rel-17, the overall application layer architecture to enable application support for UAS applications over 3GPP networks was specified in TS 23.255, also utilizing features in SEAL… In Rel-18, the UAS architecture has been enhanced to further extend functionality in 3GPP for improved support for the aviation industry.

规范开篇就点明了UAE的定位：它构建在Rel-17定义的基础之上，并大量复用了3GPP为垂直行业打造的通用服务使能层（SEAL）的能力，旨在为航空业提供更强大的功能支持。

王工知道，他不能直接去调用底层的A2X接口，那太复杂了。他需要一个更高层次的抽象，来解决他面临的三大核心应用难题。

The following three new functions are introduced. UAE layer assisted change of USS during flight UAE layer assisted support for DAA services and applications Tracking dynamic UAVs in an application defined area relative to a host UAV

这三大新功能，精准地回应了王工在跨境物流项目中遇到的挑战。

2. 功能一：飞行中的USS动态切换

这是王工面临的最紧迫的问题。当物流无人机从深圳飞往香港，跨越监管边界时，服务的USS必须平滑地切换。

UAE layer assisted change of USS during flight The UAE layer assisted change of USS can be initiated from the server or from the client. Assistance from the network is provided by SEAL LMS… to initiate change of USS. Assistance from the client is provided when an emergency change of USS is deemed necessary by the UAE client.

UAE层为此定义了一套标准化的USS切换流程，并且支持两种触发模式，分别在规范的Figure 1和Figure 2中进行了描绘。

2.1 服务器发起的切换（计划内）

这是最常见的场景，适用于跨境飞行等预先规划好的航线。

• 流程解读 (Ref: Figure 1: UAE server initiated change of USS):
  1. 切换请求 (Step 1): 当无人机即将到达边界时，深圳的UTM/USS平台（通过其后台的UAE server）向无人机上的UAE client发送一个“USS切换请求”。
  2. 网络协同 (Step 2): UAE server还会通过5GC的AF接口，影响网络的用户面路径选择。它会告知网络，无人机即将连接到香港的应用服务器，请将用户面路径（UPF）切换到离香港更近的边缘节点（通过DNAI变更）。
  3. 执行切换 (Step 3-6): 无人机上的UAE client收到指令后，与香港的USS建立新的连接，完成认证和业务交接，并向深圳的USS报告切换完成。

2.2 客户端发起的切换（应急）

场景：无人机在飞行中，与深圳USS的通信链路因故中断。为了保障安全，无人机必须立即切换到一个备用的、可用的USS。

• 流程解读 (Ref: Figure 2: UAE client initiated change of USS):
  1. 应急切换识别 (Step 1): 无人机上的UAE client检测到与主USS失联，自主决策需要进行紧急切换。
  2. 执行切换 (Step 2-4): UAE client根据预先配置的备用USS列表，直接与备用USS建立连接，并向其通告这是一次紧急切换。

通过这两种标准化的切换流程，UAE层确保了无人机在跨越服务和监管边界时，业务的连续性和飞行的安全性，完美解决了王工的跨境物流难题。

3. 功能二：DAA服务的应用层使能

在8.1章节中，我们知道DAA（探测与规避）依赖于PC5接口进行无人机之间的直接通信。但对于一个完整的防撞系统来说，还需要应用层的“大脑”来进行决策。

UAE layer assisted support for DAA services and applications This feature enables the UAS application enablement services for assisting the UAS application with DAA handling. The UAE layer assisted support for detect and avoid can be initiated from the server or from the client.

UAE层为DAA提供了应用层的“智能辅助”，同样支持服务器和客户端两种模式，如规范的Figure 3和Figure 4所示。

3.1 服务器发起的DAA辅助（“上帝视角”）

场景：王工的UTM平台通过地面雷达或ADS-B（广播式自动相关监视）系统，发现一架民航客机正在接近无人机的航线。

• 流程解读 (Ref: Figure 3: DAA support involving UAVs without U2X support):
  1. 风险识别 (Step 1): UAS application specific server (即UTM平台) 在后台识别出潜在的碰撞风险。
  2. 下发预警 (Step 2-5): UTM通过UAE server向无人机上的UAE client发送DAA事件信息，告知其有其他飞行器正在接近。无人机收到预警后，可以提前调整航线进行规避。

这种模式利用了地面系统的强大感知能力，为无人机提供了“上帝视角”的预警，特别适用于规避那些没有配备A2X通信能力的传统飞行器。

3.2 客户端发起的DAA辅助（自主协同）

场景：两架都配备了A2X能力的无人机，通过PC5广播相互发现了对方。

• 流程解读 (Ref: Figure 4: DAA support involving UAVs with U2X support):
  1. 自主发现 (Step 1): 无人机A上的UAE client通过底层A2X，检测到无人机B的存在。
  2. 信息交换与上报 (Step 2-5): UAE client之间可以通过PC5直接交换更详细的DAA信息（如前文所述的单播协商），同时，也可以将这些发现和协商的结果，通过Uu接口上报给UTM平台，让“上帝”也知道地面发生了什么。

通过为DAA提供应用层的使能，UAE层将底层的PC5通信能力，与上层的飞行控制决策逻辑有效地结合了起来，构建了一套完整的、多层次的防撞安全体系。

4. 功能三：动态无人机群组的跟踪

王工的另一个需求是，在物流枢纽等繁忙区域，需要实时监控某一架无人机（例如，一架正在执行紧急药品配送任务的“主机”）周边特定范围内的所有其他无人机（“僚机”），形成一个动态的“空中编队”。

Tracking dynamic UAVs in an application defined area relative to a host UAV The UAE server can track a host UAV’s dynamic information, i.e., information of other dynamic UAVs in an application defined area relative to a host UAV… This feature can be utilized by UAS applications as input to (e.g. DAA, Dynamic maps).

UAE层为此提供了动态群组跟踪的能力，其核心是复用了SEAL的位置管理服务（LMS）。

• 订阅动态信息: UTM平台或“主机”无人机，可以向UAE server订阅一个服务：“请持续告诉我‘主机’无人机周围500米范围内的所有其他无人机的位置信息”。
• SEAL LMS的威力: UAE server会将这个应用层请求，“翻译”成对SEAL位置管理服务器的调用。SEAL LMS会利用其强大的UE位置跟踪和群组管理能力，从5GC获取相关无人机的位置，并创建一个动态的“地理围栏群组”。
• 实时通知: 一旦有新的无人机进入或离开这个500米的范围，SEAL LMS就会通知UAE server，UAE server再将更新后的群组成员信息通知给订阅者（UTM或“主机”）。

这项功能为实现复杂的无人机编队飞行、动态空域管理和增强的DAA（例如，将周边飞行器的信息实时渲染到无人机的“电子地图”上）提供了强大的应用层支持。

总结

3GPP TR 21.918的8.2章节，清晰地定义了无人机应用使能层（UAE）的使命与核心功能。它作为5G赋能低空经济的“智能中间件”，成功地扮演了“翻译官”和“调度员”的角色。

• 对于复杂的应用场景，如飞行中的USS切换，UAE提供了标准化的流程，屏蔽了底层网络切换的复杂性，确保了业务的连续性。
• 对于关键的安全应用，如探测与规避（DAA），UAE提供了应用层的决策辅助和信息协同，将底层的通信感知转化为了有效的规避动作。
• 对于高级的协同应用，如动态编队跟踪，UAE通过复用强大的SEAL平台能力，为无人机群的智能协同管理提供了无限可能。

对于像王工这样的应用平台架构师而言，UAE层的出现，意味着他们不再需要关心底层的通信细节，而是可以专注于开发更丰富、更智能的上层航空应用。他们只需要调用UAE server提供的标准化API，就可以轻松地实现跨域管理、协同防撞、动态组队等复杂功能。这无疑将极大地加速5G在无人机和城市空中交通领域的创新与商业落地。

---

FAQ - 常见问题解答

Q1：UAE（无人机应用使能层）和上一章的A2X（空对万物通信）是什么关系？ A1：它们是“应用层”与“通信层”的关系。A2X是底层的通信框架，它定义了无人机如何通过PC5和Uu接口进行数据传输，解决了“怎么说”的问题，属于OSI模型的下面几层。而UAE是高层的应用使能框架，它定义了上层应用（如UTM平台、飞行控制App）如何利用底层的通信能力来实现具体的业务逻辑，例如“谁有权切换USS”、“如何协商规避动作”等。UAE会调用A2X提供的通信服务，但它本身更关注业务流程和应用逻辑，属于OSI模型的上面几层。

Q2：什么是SEAL？为什么UAE要复用SEAL的能力？ A2：SEAL（Service Enabler Architecture Layer for Verticals）是3GPP为垂直行业定义的通用服务使能层。你可以把它理解为一个“能力工具箱”，里面包含了许多垂直行业应用都会用到的通用能力，如群组管理（GMS）、位置管理（LMS）、**配置管理（CMS）**等。UAE复用SEAL的能力，是为了避免“重复造轮子”。例如，动态跟踪无人机群组的需求，其本质就是一个基于位置的动态群组管理问题，这正是SEAL LMS的专长。通过复用SEAL，UAE可以快速地获得这些成熟、标准化的能力，而无需重新设计一套复杂的位置和群组管理系统，这大大加快了UAS应用架构的标准化进程。

Q3：在飞行中切换USS（无人机服务供应商），为什么还需要5GC的用户面路径（UPF）也跟着切换？ A3：这是为了优化业务体验和满足监管要求。当无人机从深圳飞到香港，服务的USS切换后，其主要的应用服务器（如数据存储、飞行控制后台）也从深圳切换到了香港。如果此时用户面路径（UPF）还停留在深圳的边缘节点，那么无人机的数据就需要“深圳 → 香港USS → 深圳UPF → 互联网”这样绕一个大圈，时延会非常高。通过将UPF也切换到离香港更近的节点，可以确保数据以最短路径进行传输。此外，这也可能涉及到数据主权的监管要求，即在香港空域产生的数据，必须在香港本地的节点进行处理和落地。

Q4：UAE层定义的这些功能，是强制无人机必须支持的吗？ A4：不全是。3GPP标准通常采用分级、可选的方式来定义功能。对于一个无人机系统（UAS）来说：1）基础的通信能力（如A2X）可能是必须支持的，以满足最基本的安全和监管要求（如BRID）。2）UAE层的应用功能则可能是可选的。例如，一架只在单一国家、单一USS下飞行的无人机，可能就不需要支持“飞行中USS切换”功能。一个只进行低空航拍、不进入繁忙航线的无人机，可能只需要支持基础的DAA广播，而不需要支持复杂的协同规避。设备商可以根据其产品的市场定位和目标应用场景，选择性地实现UAE层定义的各项功能。

Q5：作为一名应用开发者，我如何使用UAE层提供的服务？ A5：作为应用开发者，你将主要与UAE server提供的北向API进行交互。你不需要关心UAE server是如何与5GC、SEAL或无人机上的UAE client通信的。例如，你想开发一个“一键返航并切换到备用机场”的功能，你可能只需要调用一个类似uaeServer.requestUssChange(uavId, targetUssInfo)的API。UAE server会负责处理所有后续复杂的流程，包括通知无人机、协调网络路径切换等。3GPP SA6工作组正在对这些北向API进行标准化，未来开发者将可以基于这些开放、统一的API，为无人机开发丰富多彩的创新应用。