好的，我们继续启程，从识别问题走向构建蓝图。
深度解析 3GPP TR 23.700-01：第5章 架构需求：为天地一体化网络绘制蓝图
本文技术原理深度参考了3GPP TR 23.700-01 V19.0.0 (2024-09) Release 19规范中，关于“Chapter 5 Architecture requirements”的核心章节，旨在为读者清晰地展示，在完成了对八大关键问题（Key Issues）的深入剖析之后，3GPP如何将这些“问题清单”转化为一份指导未来系统设计的、纲领性的“设计任务书”。
前言：从“问题清单”到“设计任务书”
在过去的八篇文章中，我们跟随阿里斯博士在亚马逊雨林的科考项目，逐一解剖了5G应用使能走向太空所面临的八大核心挑战。我们理解了应用如何“感知”网络，边缘计算如何飞向“天空之城”，如何驯服“非连续覆盖”，以及如何在星辰之间建立起拯救生命的“通信线”。
至此，我们已经拥有了一份详尽的“问题清单”。现在，是时候从“发现问题”阶段，迈向“解决问题”的第一步——定义需求。3GPP TR 23.700-01的第5章“架构需求（Architecture requirements）”，扮演的正是这个承前启后的关键角色。
这一章内容言简意赅，没有复杂的流程图，也没有冗长的描述。它由一系列以“[AR-x.y-z]”格式开头的、高度凝练的陈述句组成。每一句话，都是对前面一个或多个关键问题的直接回应；每一句话，都是未来标准化工程师在设计系统架构时必须遵守的“军规”。
本章，我们将把这些看似枯燥的“军规”，翻译成阿里斯博士能够理解的“项目需求文档”。我们将看到，他的每一个痛点，都如何在这里被转化为一个明确的、必须被满足的系统设计目标。这不再是“我们遇到了什么麻烦”，而是“我们的新系统必须做到什么”。
1. 总体设计原则 (5.1 General architecture requirements)
本节只包含一条需求，但它却是整份“设计任务书”的最高指导原则，是所有后续需求的基石。
[AR-5.1-a] The architecture shall support deployment of application enablers and services over satellite connectivity.
深度解析：
这句话看似是一句“正确的废话”，但其在标准化文档中的意义却至关重要。它以一种不容置疑的、强制性的口吻（shall support），为整个研究项目定了性：我们必须设计出一个能够支持应用使能器和服务在卫星连接上部署的架构。
这排除了任何“因为太难而放弃”的可能性，将“支持卫星”从一个“nice-to-have”的选项，提升到了一个“must-have”的系统原生能力的高度。
对阿里斯博士的意义：
这意味着，他向5G系统集成商提出的所有关于“雨林之声”、“美洲豹守望者”、“盖亚之眼-节点”等应用在卫星环境下运行的需求，都是合理且必须被满足的。整个5G系统的后续演进，都将以支持他这样的用户为核心目标之一。
2. 关键任务的铁律 (5.2 Mission Critical service architecture requirements)
在识别了关键任务（MC）业务在卫星环境下的严苛挑战（KI#4 & KI#8）之后，架构需求必须对此做出强有力的回应。
[AR-5.2-a] The architecture shall support deployments to obtain MC services over satellite connectivity.
深度解析：
这条需求直接回应了KI#4和KI#8。它强制要求，最终设计出的架构，必须能够支持关键任务业务的部署，并让用户能够通过卫星连接获得这些服务。
- “支持部署（support deployments）”：这涵盖了我们在KI#4中探讨的多种MC服务器部署场景（地面中心化、区域化、甚至星上部署）。架构设计必须具备足够的灵活性，以适应不同的部署策略。
- “获得服务（obtain MC services）”：这不仅仅是“能用”，而是要“好用”。它隐含地要求，最终的解决方案必须能够应对混合接入带来的KPI下降问题（KI#8），通过诸如信息通知、应用适配等机制，确保用户获得可接受的、可管理的服务体验。
对阿里斯博士的意义：
在队员被蛇咬伤的紧急救援中，这条需求就是技术层面的“生命保障”。它意味着：
- 他使用的MCPTT系统，其后台架构必须经过专门设计或增强，以兼容卫星接入。
- 当他发起呼叫时，网络必须提供符合MC业务等级的QoS保障。
- 当救援直升机（GEO用户）加入群聊时，系统必须有机制来处理延迟差异，避免指挥混乱。
这条铁律，确保了“生命线”业务在架构设计层面，拥有不可动摇的最高优先级。
3. “天空之城”的建造规范 (5.3 EDGEAPP architecture requirements)
针对KI#2（GEO星上边缘计算）和KI#5（NGSO星上边缘计算）的复杂挑战，本节提出了三条具体、可操作的建造规范。
3.1 规范一：必须支持“星上组件”
[AR-5.3-a] The EDGEAPP shall support satellite connectivity enabled with deployment of EDGEAPP architecture components onboard satellite.
深度解析：
这是对星上边缘计算最直接的架构授权。它明确要求，EDGEAPP（5G边缘计算）的架构必须支持其组件（如EAS、EES）被部署在卫星上。
这意味着，工程师在演进TS 23.558（EDGEAPP标准）时，不能再仅仅基于“服务器都在地面”的假设。他们必须考虑并设计出能够让边缘节点“上天”的流程和接口。
对阿里斯博士的意义：
他的“美洲豹守望者”AI应用（一个EAS）和“雨林之翼-01”无人机实时飞行控制AI（另一个EAS），在系统设计层面，获得了在卫星上运行的“准生证”。架构必须为这些应用的太空部署，提供标准化的支持。
3.2 规范二：必须支持“多种盖法”
[AR-5.3-b] The EDGEAPP shall support satellite connectivity enabled with multiple deployment options of EDGEAPP architecture components onboard satellite.
深度解析：
这条需求回应了我们在KI#2和KI#5中探讨的部署策略问题。它认识到，不存在一种“放之四海而皆准”的星上部署方案。
- 对于简单的GEO场景，可能是“大脑在地面，哨所在太空”的混合部署。
- 对于复杂的LEO星座，可能是“所有卫星都有哨所（EES），部分卫星有工厂（EAS）”的功能分层部署。
因此，架构必须具备灵活性（multiple deployment options），不能写死某一种部署模式。这要求相关的接口和流程设计得足够通用和可扩展。
对阿里斯博士的意义：
他的IT架构师可以根据不同任务的成本、性能和可靠性需求，与运营商一起，灵活地选择最适合的边缘计算部署方案，而不是被一个僵化的架构所束缚。
3.3 规范三：必须支持“快速重连”
[AR-5.3-c] The EDGEAPP shall support satellite connectivity enabled with EAS re-discovery.
深度解析：
“重发现（Re-discovery）”这个词是本条需求的关键。它直面了卫星网络（尤其是NGSO）的动态性和不稳定性。连接可能会因为卫星切换、信号遮挡、天气等原因短暂中断。
当连接恢复时，如果UE每次都要从零开始，走一遍完整的、包含星地往返的冗长发现流程（联系ECS → 联系EES → 找到EAS），那么业务体验将是灾难性的。
因此，架构必须支持一种优化的、快速的重发现机制。例如，UE或网络可以缓存（cache）上一次的发现结果。当连接恢复后，UE可以先尝试直接连接之前缓存的EAS地址，如果成功，则完全跳过了发现过程。或者，网络可以在UE重连时，主动将EAS的信息快速下发给UE。
对阿里斯博士的意义：
这对于“雨林之翼-01”无人机是生死攸关的。无人机在复杂的冠层下飞行，信号可能被浓密的树叶短暂遮挡。如果每次信号恢复，飞行控制AI都需要经历半秒多的“重新发现”才能重新连接，无人机早就失控坠毁了。这条需求，确保了系统必须设计出一种“闪电般”的重连能力，保障了高动态业务的连续性。
4. “信息管道”的功能规格 (5.4 SEAL functional requirements)
SEAL（服务使能架构层）是连接网络和应用的核心“管道”。本节为这个管道在卫星场景下，定义了五个必须具备的核心功能。
4.1 规格一：杠杆作用
[AR-5.4-a] The SEAL architecture shall leverage satellite connectivity.
深度解析：
这是一个原则性的要求，即SEAL必须能够利用（leverage）卫星连接的特性，来增强其提供的所有服务。例如，SEAL的位置服务，在卫星环境下，应该能够结合卫星辅助定位信息；SEAL的群组管理服务，应该能够感知群组成员的卫星接入类型。
4.2 规格二 & 三：必须提供“卫星时刻表”
[AR-5.4-b] The SEAL architecture shall support satellite coverage availability information during discontinuous coverage of satellite connectivity.
[AR-5.4-c] The SEAL architecture shall support UE unavailability information during discontinuous coverage of satellite connectivity.
深度解析：
这两条需求，是对KI#3（非连续覆盖）最直接、最强有力的回应。它们强制要求SEAL必须具备向应用层提供“卫星时刻表”的能力。
[AR-5.4-b]要求SEAL能够提供覆盖可用性信息（例如，未来24小时的可用窗口列表）。[AR-5.4-c]更进一步，要求SEAL能够提供更直接的UE不可用信息（例如，该UE在接下来的8小时内将无法连接）。
对阿里斯博士的意义：
他的“盖亚之眼-节点”的“能源危机”得到了根本性的解决。SEAL架构必须为他的传感器提供这份“救命”的时间表，使其能够实现“计划性离线”的智能工作模式，从而将电池寿命延长至设计预期。
4.3 规格四 & 五：必须提供“太空物流追踪”
[AR-5.4-d] The SEAL architecture shall support obtaining and exposing S&F events information regarding satellite connectivity in EPS.
[AR-5.4-e] The SEAL architecture shall support managing S&F message delivery regarding satellite connectivity in EPS.
注：这里的EPS（Evolved Packet System，即4G核心网）是因为在Rel-19早期研究时，S&F主要在EPS for IoT上进行标准化。这个需求同样适用于5GC。
深度解析：
这两条需求，是对KI#7（S&F事件信息）最直接的回应。它们强制要求SEAL必须扮演“太空物流追踪系统”的角色。
[AR-5.4-d]要求SEAL必须能够从底层网络获取（obtaining） S&F事件，并将其暴露（exposing） 给上层应用。[AR-5.4-e]要求SEAL必须能够参与到S&F消息的管理（managing） 中，例如，基于从应用服务器收到的策略，来影响S&F消息的优先级或生命周期。
对阿里斯博士的意义：
他那套用于回收海量传感器数据的后台系统，其可靠性得到了保障。SEAL架构必须为他的应用服务器提供每一个数据包的“物流追踪”信息（是否被揽收、何时发车、预计何时送达、是否已签收）。这让他能够建立起一套可靠、高效、智能的物联网数据管理流程。
5. 总结：从痛点到需求的升华
第5章“架构需求”在整份技术报告中，起到了一个至关重要的“转换器”作用。它将第4章中那些生动的、场景化的用户“痛点”，升华为一份份清晰、明确、具有强制性的技术“需求”。
- 阿里斯博士对实时性的渴求，催生了对星上边缘计算组件和快速重发现的架构需求。
- 他对传感器电池寿命的忧虑，催生了对SEAL提供覆盖可用性信息的功能需求。
- 他对数据可靠回收的期盼，催生了对SEAL暴露S&F事件的功能需求。
- 他对救援指挥效率的担忧，催生了对支持关键任务业务部署的架构需求。
这份“设计任务书”的诞生，标志着5G天地一体化应用使能的研究，已经完成了从“为什么要做”到“要做成什么样”的关键跨越。它为后续第6章（架构选项）和第7章（解决方案）的详细技术设计，提供了不可动摇的、必须被严格遵守的“最高纲领”。
FAQ环节
Q1： “架构需求（Architecture Requirement）”和“功能需求（Functional Requirement）”有什么区别？ A1：在3GPP的语境中，这是一个很好的问题。架构需求通常关注的是系统的结构和组成，即“系统应该由哪些部分构成，以及它们之间应该如何组织”。例如，[AR-5.3-a]要求架构“支持组件被部署在卫星上”，这是一个关于系统结构形态的要求。而功能需求更关注系统需要做什么，即“系统应该提供什么样的行为或服务”。例如，[AR-5.4-b]要求SEAL“支持提供覆盖可用性信息”，这是一个关于系统必须具备的外部可见功能的要求。通常，架构需求决定了系统的“骨架”，而功能需求决定了系统的“能力”。
Q2：什么是EAS“重发现（re-discovery）”，为什么它对卫星边缘计算如此关键？ A2：“重发现”是指在一个已建立的边缘计算会话因网络连接中断而恢复后，UE重新找到并连接到为其服务的EAS的过程。它之所以关键，是因为卫星网络（尤其是LEO）的连接中断是常态（例如卫星切换）。如果每次重连，UE都必须走一遍从头开始的、包含与遥远地面ECS交互的漫长“首次发现”流程，那么业务的实时性将荡然无存。因此，架构必须支持一种优化的、快速的重发现机制（如利用缓存或网络主动通知），以实现秒级甚至毫秒级的业务恢复，这对于无人机控制等高动态业务是生死攸TAIN的。
Q3：SEAL和EDGEAPP在卫星应用使能中是什么关系？是竞争还是协作？ A3：它们是协作互补的关系，共同构成了应用使能的两个层面。EDGEAPP（由TS 23.558定义）更偏向于基础设施层，它负责边缘计算资源的部署、发现、和生命周期管理，可以看作是“太空中的IaaS/PaaS平台”。而SEAL（由TS 23.434定义）更偏向于通用能力层，它将网络中各种通用的能力（如位置、群组、配置、以及我们这里讨论的卫星特性）打包成标准的API，可以看作是“网络能力超市”。它们会协同工作：例如，一个部署在EDGEAPP平台上的EAS应用，可以调用SEAL提供的API，来获取它所在卫星的覆盖预测信息，从而更好地服务其连接的用户。
Q4：这些需求中提到了“shall support”，它的强制性有多强？ A4：在3GPP规范中，“SHALL”和“SHALL NOT”是具有最高法律效力的强制性词语，等同于“必须”和“绝不允许”。当一个架构需求使用“shall support”时，意味着任何声称符合该标准的系统实现，都必须满足这一要求。它为后续的标准化、产品研发和一致性测试提供了不容置疑的依据。
Q5：这些高层级的需求，是如何一步步变成我们手机里能用的具体功能的？ A5：这是一个从需求到实现的过程：1) 研究报告（TR）：如我们正在解读的TR 23.700-01，它首先提出高层级的架构需求（本章内容）。2) 标准化工作（TS）：基于TR的结论，3GPP的相关工作组（如SA6）会在对应的技术规范（TS）中，对这些需求进行细化，定义出具体的流程、接口、参数和编码。例如，SEAL提供覆盖信息的需求，会被细化为TS 23.434中的一个新API，包含具体的HTTP方法、URL、请求/响应体的数据结构。3) 产品研发：设备商（如爱立信、华为）和芯片商（如高通、联发科）根据TS标准，在其网络设备和终端芯片中实现这些功能。4) 部署与应用：运营商部署支持这些功能的网络，同时，应用开发者（如阿里斯博士的团队）调用手机操作系统或SDK提供的、遵循3GPP标准的API，来开发能够感知卫星网络的智能应用。最终，这些功能就呈现在了用户的手机上。