深度解析 3GPP TS 23.558：5 Architectural requirements (奠定边缘世界的法则)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“Chapter 5 Architectural requirements”的核心章节，旨在为读者深入解读构建边缘应用世界的各项基本法则。这些要求是后续所有架构设计和流程定义的基石。
引言：无规矩不成方圆，边缘世界的“宪法”
在上一篇《边缘计算能力概览》中，我们跟随“智行一号”体验了边缘使能层提供的“七种武器”，对服务开通、发现、服务连续性等核心能力有了宏观的认识。然而，任何一个稳定、开放、繁荣的生态系统，都离不开一套严谨的顶层设计原则——一部“宪法”。
3GPP TS 23.558的第五章“Architectural requirements”（架构要求）就扮演了这样一部“宪法”的角色。它用一系列精炼而严谨的“shall”（必须）条款，为整个边缘应用世界立下了规矩。这些要求并非凭空想象，而是针对边缘计算的每一个痛点，从兼容性、安全性、移动性等多个维度提出的根本性约束。
对于“智行一号”的设计团队而言，理解这些要求，就如同理解自动驾驶系统必须遵守的基本物理定律和交通法规。它们决定了架构的“能”与“不能”，是保证“智行一号”无论驰骋在哪家运营商的网络上，都能获得一致、可靠、安全边缘服务的根本保障。
本文将化身为一名“立法者”，逐条解读这部边缘世界的“宪法”，并继续通过“智行一号”的场景，阐述每一条“法律”背后的深意及其对最终用户体验的巨大影响。
1. 通用法则：兼容并包，与网共生 (5.2.1 General requirements)
宪法的开篇，往往是奠定基本国策的总纲。5.2.1节的通用要求，就为边缘应用架构定下了“开放兼容、与网共生”的总基调。
[AR-5.2.1.2-a] The application layer architecture shall support deployment of EAS(s) and AC(s) with or without modifications compared to their existing deployments.
解读与场景化： 这条要求是边缘计算能否快速普及的关键。它向广大的应用开发者承诺：你们现有的很多云应用，不需要大规模重构，只需少量甚至无需修改，就可以平滑地迁移到边缘。
想象一下，为“智行一号”提供V2X服务的应用（EAS），其核心算法早已在中心云上开发和验证过。如果部署到边缘需要重写所有代码，那成本将是巨大的。这条要求确保了架构必须足够友好，能够兼容现有的应用部署模式，比如容器化部署。开发者可以专注于业务逻辑，而不是疲于应付边缘环境的特殊性，这极大地降低了生态门槛。
[AR-5.2.1.2-b] The application layer architecture shall support different deployment models in conjunction with an operator’s 3GPP network. [AR-5.2.1.2-c] The application layer architecture shall be compatible with the 3GPP network system.
解读与场景化： 这两条共同强调了架构的灵活性和原生性。运营商的网络形态各异，有的可能采用LADN（本地数据网络），有的可能采用普通DNN配合边缘UPF。无论底层网络如何实现，“智行一号”的应用层架构都必须能够适配。
更重要的是，它必须与3GPP网络系统“兼容”。这意味着边缘使能层的实体（如EES）在与核心网交互时，必须扮演一个标准定义的角色——AF（Application Function），使用标准的接口和流程，而不是自成一派。这种“与网共生”的设计，保证了边缘能力开放的安全可控。
2. 配置法则：授人以渔，指明方向 (5.2.2 Edge configuration data)
当“智行一号”（EEC）启动时，它如同一个初入陌生城市的旅人，需要一张地图才能找到目的地。配置数据的要求，就是确保这张“地图”能够被安全、准确地送达。
[AR-5.2.2.2-a] The application layer architecture shall provide mechanisms to provide configuration parameters to an authorized EEC to access the EES(s).
解读与场景化： 这条要求的核心是“授权”和“提供”。
- 授权（authorized）: 意味着不是任何设备都能随意获取边缘网络的信息。只有像“智行一号”这样经过认证、合法的EEC，才有权获得这份“地图”。这防止了恶意设备探测和攻击运营商的边缘基础设施。
- 提供（provide）: 架构必须有一套明确的流程（即我们在第四章提到的“服务开通”），让EEC能够从ECS那里获取到它需要的配置参数，最核心的就是EES的地址。
没有这条法则，“智行一号”启动后将陷入迷茫，因为它不知道该与网络中的哪个EES进行下一步交互。这条规定，正是“服务开通”流程的法理基础。
3. 注册法则：户籍管理，井然有序 (5.2.3 Registration)
一个城市需要有户籍系统，才能管理居民和商铺。边缘世界同样如此。注册法则是为了建立一套有序的“户籍”管理制度，让每一个参与者都有名有姓，有迹可循。
[AR-5.2.3.2-a] The application layer architecture shall provide mechanisms for an EEC to register onto the EES. [AR-5.2.3.3-a] The application layer architecture shall provide mechanisms for an EAS to register to the EES.
解读与场景化： 这两条要求确立了双向注册机制。
- EEC注册: “智行一号”的EEC必须向EES“报到”，EES才会为它建立档案（EEC Context），承认它的合法身份。
- EAS注册: 路口的V2X服务器（EAS）也必须向EES“登记”，上报自己的服务能力、地址、范围等信息。
这个双向注册机制，使得EES成为了一个动态更新的信息中心，为后续的精准发现服务奠定了数据基础。
[AR-5.2.3.2-c] The application layer architecture shall provide mechanisms for the EES to detect an abnormal termination of an EEC registration. [AR-5.2.3.3-e] The application layer architecture shall provide mechanisms for the EES to detect an abnormal termination of an EAS registration.
解读与场景化： 这是保证系统鲁棒性的“生命周期管理”法则。想象一下，如果“智行一号”在行驶中突然发生故障断电，它的EEC注册信息不能永远“挂”在EES上，否则会成为占用资源的“僵尸链接”。同样，如果一个EAS服务器宕机了，EES必须能及时发现并将其从服务列表中移除，否则就会把用户导向一个无法服务的“空店铺”。
这条要求强制架构必须具备心跳检测、超时或类似的机制，确保注册信息的时效性，维持整个系统的健康运转。
4. 发现法则：按需匹配，优中选优 (5.2.4 EAS discovery)
发现是边缘计算的核心价值所在。发现法则确保了“智行一号”总能找到那个“最合适”的服务。
[AR-5.2.4.2-a] The application layer architecture shall provide mechanisms for an EEC to discover available EASs.
解读与场景化： 这条看似简单，但“available”（可用）一词内涵丰富。它不仅指EAS正在运行，还意味着它在地理上、拓扑上对“智行一号”是可达的，并且其负载、性能等状态满足服务要求。架构必须提供一套机制（即EAS Discovery流程）来实现这一点。
[AR-5.2.4.2-b] The application layer architecture shall provide relevant configuration information of the EASs to the EEC, in order to enable communication between ACs and the EASs.
解读与场景化： 这条要求强调了发现结果的“可用性”。EES返回给EEC的，不能仅仅是一个名字，而必须是“智行一号”的AC能够直接使用的“连接说明书”，包括IP地址、端口、URI等。这确保了从发现到连接的无缝衔接，AC拿到结果后，可以直接与EAS建立通信，无需二次转换。
5. 能力开放法则：打破壁垒，应用赋能 (5.2.5 Capability exposure to EASs)
现代汽车的强大，在于其开放的CAN总线，允许各种传感器和控制器协同工作。边缘应用的强大，同样在于它能调用网络的能力。
[AR-5.2.5.2-a] The application layer architecture shall support exposure of 3GPP network’s capabilities to the EASs. [AR-5.2.5.2-b] The application layer architecture shall support exposure of EES’s capabilities to the EASs. [AR-5.2.5.2-c] The application layer architecture shall support exposure of EAS’s capabilities to the other EASs.
解读与场景化： 这是一个“三向开放”的法则：
- 网络→应用: 核心网的定位、QoS、用户面管理等能力，必须能够通过EES这个“翻译官”，安全地开放给EAS使用。
- 使能层→应用: EES自身的管理能力，比如通知EAS某个用户（EEC）已经上线或下线，也必须开放。
- 应用←>应用: 一个EAS的服务能力，也可以通过EES作为中介，开放给另一个EAS调用，实现边缘应用之间的微服务协同。
这个法则打破了应用与网络之间的信息孤岛，让边缘应用不再是简单的“计算节点”，而是能够与网络深度互动、感知网络状态、利用网络能力的“智能体”。
6. 安全法则：信任与隐私的守护神 (5.2.6 Security)
对于“智行一号”这样的生命攸关应用，安全是“1”，其他都是后面的“0”。安全法则为整个边缘世界建立了信任的基石。
[AR-5.2.6.2-a] The application layer architecture shall provide mechanisms for the Edge Computing Service Provider to authorize the usage of Edge Computing services by the EEC. [AR-5.2.6.2-f] The application layer architecture shall support mutual authentication and authorization check between clients and servers or servers and servers that interact.
解读与场景化： 这两条确立了“先授权、后使用”和“双向认证”的基本原则。
- “智行一号”的EEC在访问任何边缘服务前，都必须经过运营商（ECSP）的授权。
- 不仅是客户端和服务端，任何两个需要交互的实体（如EES与EES之间），都必须相互确认对方的合法身份。这就像特工接头，必须先对上正确的暗号。
[AR-5.2.6.2-h] The application layer architecture shall provide mechanisms to support privacy protection of the user.
解读与场景化： 这条是用户隐私的“保护伞”。当EAS需要获取“智行一号”的位置、行驶轨迹等敏感信息时，架构必须提供机制来确保已获得用户（车主）的同意。这在日益强调数据主权的今天至关重要，确保了技术的便利不会以牺牲个人隐私为代价。
7. 订阅/通知法则：从“拉”到“推”的演进 (5.2.7 Subscription service)
如果“智行一号”每秒都要去问EES：“我附近的服务有变化吗？”，这将产生巨大的信令开销。订阅/通知法则，引入了更高效的“发布-订阅”模式。
[AR-5.2.7.2-a] The application layer architecture shall provide subscription and notification mechanisms enabling an EEC to receive changes in dynamic information of EASs from an EES. [AR-5.2.7.2-e] The application layer architecture shall provide subscription and notification mechanisms enabling an EAS to receive information about relevant reports in UE location.
解读与场景化：
- EES → EEC: “智行一号”的EEC可以向EES订阅“EAS状态变化”事件。当A路口的V2X服务器因维护而下线时，EES会主动通知EEC，让它可以提前准备切换到备用服务器。
- EES → EAS: V2X服务器EAS也可以向EES订阅“智行一号”的“位置更新”事件。这样，只要“智行一号”的位置发生显著变化，EES就会主动将新位置推送给EAS，而无需EAS不断地轮询查询。
这种从“拉（Pull）”到“推（Push）”的模式转变，极大地提升了系统的实时性和效率。
8. 其他关键法则：保障服务质量与生命周期
除了上述核心法则，第五章还定义了其他一些关键要求，共同构成了完整的治理体系。
- 流量管理 (5.2.8 Traffic management): 要求架构能支持AF影响N6接口的流量路由，这意味着EAS可以通过EES向核心网UPF建议最优的数据路径，以满足低时延等KPI要求。
- 生命周期管理 (5.2.9 Lifecycle management): 要求架构能与生命周期管理系统交互，支撑动态EAS实例化等高级功能。
- KPI上报 (5.2.10 Edge application KPIs): 要求EAS能够发布和更新自己的KPI（如时延、吞吐量等），这为EES进行智能的负载均衡和最优服务选择提供了决策依据。
- 服务连续性 (5.2.11 Service continuity): 这是最重要的法则之一，它在法律层面强制规定了架构必须提供应用上下文从S-EAS转移到T-EAS（或CAS）的机制，为8.8节中详细的ACR流程提供了法理依据。
总结
第五章“架构要求”是TS 23.558的纲领性文件。它没有陷入具体实现的细节，而是从最高层面定义了边缘应用架构必须遵守的“公理”。这些“公理”确保了系统：
- 开放兼容: 对现有应用友好，能适应不同网络部署。
- 有序可控: 通过注册和授权，管理每一个参与者。
- 智能高效: 通过精准发现和订阅通知，实现资源的最佳匹配。
- 安全可靠: 保护通信安全和用户隐私。
- 无缝移动: 强制支持服务连续性，保障移动用户体验。
正是这些看似抽象的要求，共同构筑了边缘世界的“法治社会”，为“智行一号”以及未来亿万的边缘设备和应用，提供了一个可以信赖、可以预期、可以自由驰骋的标准化环境。
FAQ
Q1：为什么规范要花一整章来定义这些“要求”，而不是直接给出架构和流程？ A1：这是标准制定工作的基本范式，即“需求驱动设计”。首先明确目标和约束（即“要求”），然后再设计出满足这些要求的架构和流程。这样做的好处是：
- 逻辑清晰: 保证了设计的每一个部分都是为了解决一个或多个明确的需求，避免了功能冗余或缺失。
- 便于演进: 当未来出现新的需求时，可以先在“要求”层面进行增补，然后再审视现有架构是否需要修改，使得标准演进更加有条不紊。
- 利于评估: 可以用这些“要求”作为“验收标准”，来检验最终设计的架构和流程是否合格。
Q2：这些“shall”（必须）的要求是由谁来强制执行的？ A2：3GPP本身是一个标准组织，它不负责强制执行。这些要求的“强制力”体现在市场和产业协同上。设备商（如爱立信、华为）、终端制造商（如高通、联发科）、运营商（如移动、电信、联通）在开发其边缘计算相关的产品和解决方案时，为了保证产品的互联互通性和市场竞争力，会自觉遵守这些“shall”条款。通过行业认证和运营商的集采测试，不符合规范的产品将难以进入市场。
Q3：5.2.8节提到的“AF influence on traffic routing”（AF影响流量路由）具体指什么？它如何帮助“智行一号”？ A3：这是5G核心网的一项重要能力（在TS 23.501中有详细定义），允许应用功能（AF，在此场景下是EAS通过EES扮演）向核心网策略控制功能（PCF）提供流量路由的“建议”。例如，EAS可以告诉PCF：“对于‘智行一号’发往我的数据流，请务必通过位于城市东区、具有最低时延路径的UPF进行转发。” PCF收到这个建议后，会生成相应的策略下发给会话管理功能（SMF），由SMF控制UPF选择最优的转发路径。这项能力使得应用能够主动参与到网络路径的选择中，是实现端到端低时延保障的关键技术。
Q4：5.2.9节的“生命周期管理”和5.2.3节的注册信息“异常终止检测”有什么区别？ A4：两者层面不同。5.2.3节的“异常终止检测”关注的是一个已注册会话的生命周期，是运行时的管理，比如通过心跳或超时来清理断开的连接。而5.2.9节的“生命周期管理”概念更广，它指的是与EAS应用实例本身的生命周期管理系统的交互，是编排和运维层面的管理。这包括应用的部署、启动（实例化）、扩容/缩容、停止和销毁等。动态EAS实例化就是生命周期管理的一个典型应用场景。
Q5：这些架构要求看起来非常全面，是否有遗漏或者尚未完善的地方？ A5：标准总是在不断演进的。尽管TS 23.558 V18版本已经相当完善，但仍有一些领域在持续探讨中，例如：
- 更精细化的安全模型: 如何处理跨运营商、跨第三方云的复杂信任关系。
- 意图驱动: 如何让AC用更“自然语言”的方式表达需求（如“我需要最佳游戏体验”），而不是技术化的KPI，由网络去自动解析和匹配。
- AI/ML的深度融合: 如何将AI/ML能力更原生、更标准化地融入到边缘使能层，以实现更智能的预测性切换和资源调度。 这些都可能是未来Release版本中会进一步增强的内容。