51学通信

深度解析 3GPP TR 21.917：9.1 Edge computing (边缘计算：让智慧更近一步)

22分钟阅读

深度解析 3GPP TR 21.917：9.1 Edge computing (边缘计算：让智慧更近一步)

本文技术原理深度参考了3GPP TR 21.917 V17.0.1 (2023-01) Release 17规范中，关于“9.1 Edge computing (边缘计算)”的核心章节。本文将揭示5G Rel-17如何通过对核心网、应用层和管理面的三位一体增强，为边缘计算构建一个强大、智能且易于管理的“高速公路”和“操作系统”。

1. 智慧港口的“时延之困”：当AI大脑跟不上“鹰眼”的速度

“滨海智慧新区”的建设进入了深水区。总设计师林工的目光，聚焦在了全自动化智慧港口的“AI视觉质检”项目上。项目的AI负责人，艾博士，一位海归的顶尖科学家，向林工提出了一个棘手的难题。

项目的核心，是由数百架名为“鹰眼-质检”系列的无人机，对进出港口的集装箱进行24小时不间断的8K超高清视频扫描，通过AI算法实时检测箱体表面的损伤、裂缝等缺陷。

“林工，我们的AI模型非常强大，但它的‘大脑’——部署在千里之外公有云上的GPU集群——离我们太远了！”艾博士在大屏幕上展示了一段测试视频，视频中，一架“鹰眼-01”无人机扫描过一个集装箱，AI算法在0.5秒后才标记出一条微小的裂缝。但此时，这个集装箱已经被桥吊抓起，即将装船。

“0.5秒的延迟，对于互联网应用来说堪称神速，但对于工业自动化来说，就是‘无效信息’。”艾博士指出了三大核心痛点：

  1. 时延之困：8K视频流从无人机，通过5G网络，回传到遥远的云端数据中心，再经过AI处理，结果返回港口控制系统，整个“感知-决策”环路的时延高达数百毫秒。我们需要的，是低于50毫秒的实时响应。

  2. 带宽之痛：数百路8K视频流，汇聚成了海啸般的上行流量，几乎要“撑爆”整个港区通往公网的出口带宽。

  3. 数据之忧：港口的所有运营视频数据，都毫无保留地传输到了外部云平台，这引发了管理层对数据主权和安全隐私的深切担忧。

林工明白，这是智慧城市建设中一个普遍的、根本性的问题：集中式云计算的“远水”，解不了边缘侧实时业务的“近渴”。解决方案只有一个：将“大脑”前移，让计算发生在离数据源最近的地方。 这，就是5G边缘计算（MEC/Edge Computing）的使命。而3GPP Rel-17在第9.1章中，正是为这场“大脑前移”的革命，提供了完整的、标准化的“迁徙指南”。

2. 5G的“智能导航”：核心网如何发现并连接到“边缘” (9.1.1)

林工向艾博士提出了解决方案：在港区内部署一台强大的边缘计算服务器，将AI算法模型直接运行在这台服务器上。无人机拍摄的视频，不再需要“漂洋过海”，而是直接在本地处理。

“这个想法太棒了！”艾博士兴奋地说，“但问题是，‘鹰眼-01’无人机如何知道要去连接这台近在咫尺的边缘服务器，而不是它之前一直连接的云端服务器呢？”

这个问题，直指边缘计算的第一个核心挑战：边缘服务的发现与接入。9.1.1节“Enhancement of support for Edge Computing in 5G Core network”给出了答案。

9.1.1 Enhancement of support for Edge Computing in 5G Core network

This Feature enhances 5G core network to support Edge Computing… The main functionalities include the discovery and re-discover of Edge Application Server (EAS), edge relocation, network exposure to EAS…

【深度解读】

这段话的核心，是赋予5G核心网一种全新的能力——感知和调度边缘流量。为此，Rel-17引入/增强了一个关键的网络功能实体：EASDF (Edge Application Server Discovery Function，边缘应用服务器发现功能)。

Discovery and re-discovery of Edge Application Server: Before an UE accessing to edge service, a suitable EAS needs to be discovered by the UE considering different factors, e.g. UE location, UPF serving the UE and also the EAS deployment. … An EASDF (Edge Application Server Discovery Function) is introduced to support these mechanisms.

【深度解读】

EASDF，可以被理解为5G核心网内置的一个“边缘服务DNS”或“智能导航仪”。让我们看看“鹰眼-01”在引入EASDF后的工作流程：

  1. “鹰眼-01”无人机开机，其上搭载的AI质检应用需要连接到AI服务器。它会像访问普通网站一样，发起一个对特定域名（如ai-inspection.smartport.com）的解析请求。

  2. 这个请求，被5G核心网的用户面功能（UPF）截获，并转发给EASDF。

  3. EASDF开始它的“智能导航”：

    • 它知道“鹰眼-01”当前的地理位置。

    • 它知道正在为“鹰眼-01”提供服务的UPF是哪一个（即它接入了哪个5G网络的“本地出口”）。

    • 它还维护着一张“边缘地图”，上面注册了所有可用的边缘应用服务器（EAS）的位置、IP地址以及它们所能服务的UPF列表。

  4. EASDF进行匹配，发现港区本地的边缘服务器，正是服务“鹰眼-01”当前所在UPF的最佳选择。

  5. 于是，EASDF不再返回云端服务器的IP地址，而是将本地边缘服务器的IP地址返回给无人机。

  6. 同时，EASDF会通知SMF/UPF，建立一条从无人机到这台本地边缘服务器的直通路由（Traffic Offload）。

最终，“鹰眼-01”的8K视频流，在离开UPF后，直接被“引流”到了几米之外的本地服务器上，实现了流量的本地卸载。整个“感知-决策”环路的时延，瞬间从数百毫秒降到了30毫秒以内。

Edge relocation: When EAS or PSA UPF relocates due to e.g. UE mobility, 5GS user plane path may be re-configured coordinating with AF to keep the path optimized… Both AF and network triggered edge relocation mechanisms are specified…

【深度解读】

如果“鹰眼-01”从港口的A区飞到了B区，其服务的UPF和最佳的边缘服务器都可能发生变化。此时，边缘重定位（Edge Relocation） 机制会被触发。5G网络（在AF的协助下）会自动地、平滑地将无人机的业务流，从旧的边缘服务器切换到新的、更近的边缘服务器上，确保了服务的连续性和最优路径。

3. 边缘的“应用商店”：让边缘应用即插即用 (9.1.2)

解决了接入问题，艾博士又提出了新的挑战：“我们有上千架无人机，还有成百上千的地面摄像头和传感器，未来都可能需要运行各种边缘应用。难道我们要一台台手动去配置IP地址、更新软件吗？而且，如何确保我的AI应用，只能被授权的‘鹰眼’无人机使用，而不能被其他设备访问？”

他需要的是一个边缘应用的“应用商店”和“管理后台”。这正是9.1.2节“Enabling Edge Applications”所定义的内容。

9.1.2 Enabling Edge Applications

…the overall application layer architecture needs supporting environment (such as provisioning, discovery, registration, enabler layer capability exposure…) to enable edge applications over 3GPP networks.

【深度解读】

SA6工作组为此设计了一套全新的应用层架构，引入了三个核心角色，它们共同构成了一个边缘应用的“生态系统”：

  • ECS (Edge Configuration Server)：边缘配置服务器。它如同整个生态的“大脑”和“管理后台”。艾博士的应用团队，只需要将他们的AI质检应用，在ECS上进行一次注册，并配置好服务策略（如“只允许‘鹰眼’系列无人机访问”、“在港区A区使用模型A，在B区使用模型B”）。

  • EES (Edge Enabler Server)：边缘使能服务器。它部署在每一个边缘站点（如港区的本地数据中心），是ECS策略的“现场执行官”。它从ECS同步配置，并负责管理本站点的边缘应用。

  • EEC (Edge Enabler Client)：边缘使能客户端。它是一个嵌入在“鹰眼-01”等终端设备中的轻量级客户端软件，是终端与边缘生态“对话”的“信使”。

The Edge Data Network (EDN) is a local Data Network. Edge Application Server(s) and the Edge Enabler Server (EES) are contained within the EDN. … The Edge Configuration Server, providing configurations to the EEC.

【深度解读】

让我们看看这套“应用商店”是如何为“鹰眼-01”自动完成应用配置的：

  1. “鹰眼-01”开机后，其内置的EEC首先向全网统一的ECS发起“我是谁，我能干什么”的注册和能力上报。

  2. ECS识别出这是一架“鹰眼-质检”无人机，根据艾博士预设的策略，告诉EEC：“根据你的身份和位置，你应该去联系位于港区A区的那个EES。”

  3. EEC遵从指令，与本地的EES建立连接。

  4. EES如同一个“店小二”，热情地向EEC介绍本店的“特色服务”：“欢迎光临！本店（本边缘站点）为您准备了‘AI集装箱质检v2.1’服务，它的服务地址是…，您需要使用X.509证书进行认证…”

  5. EEC获取到所有信息后，自动配置好上层的AI质检应用。

通过这套架构，上千台设备的应用程序部署、更新、配置和认证，都实现了全自动化。艾博士不再需要关心底层网络的复杂性，他只需要像一个“App开发者”一样，在ECS这个“应用商店后台”发布和管理他的AI应用即可。

4. 边缘的“守护神”：对边缘基础设施的全面监控 (9.1.3)

“太棒了！”林工和艾博士对这套体系赞不绝口。但作为总设计师，林工还必须考虑最后一个问题：运维。

“我们部署在港区、工厂、交通枢纽的成百上千个边缘服务器，以及上面运行的五花八门的应用，如何进行统一的监控和管理？当‘鹰眼-01’的应用出现卡顿时，我如何能快速判断，是无人机的问题，是5G网络的问题，还是边缘服务器过载了？”

他需要的是一个能够洞察边缘基础设施健康状况的“中央仪表盘”。这正是9.1.3节“Edge Computing Management”所解决的问题。

9.1.3 Edge Computing Management

The ECM Work Item … provides management provisions and solutions for edge computing considering related requirements from SA6 EDGEAPP WI including lifecycle management, provisioning, performance assurance and fault supervision for EDGEAPP defined entities.

【深度解读】

SA5（管理面工作组）将传统的网管理念，延伸到了边缘计算领域。它定义了一套针对边缘实体（ECS, EES, EAS）的管理模型和接口，主要涵盖：

  • 生命周期管理 (LCM)：林工的运维团队，可以通过统一的管理平台，远程完成对一台新的边缘服务器的部署、应用安装、软件升级、启停、卸载等全生命周期操作。

  • 性能保障 (Performance Assurance)：运维平台可以从EES和EAS上，采集一系列关键的性能指标（KPI），例如：

    • 边缘服务器的CPU、内存、存储使用率。

    • AI质检应用的处理时延、吞吐量、并发会话数。

    • 边缘网络（EDN）的内部通信质量。

    这些KPI会呈现在林工的“中央仪表盘”上，让他对整个边缘系统的运行状态一目了然。

  • 故障监督 (Fault Supervision)：当港区的边缘服务器因为过热而降频，导致AI处理时延超过告警阈值时，EES/EAS会主动上报一个告警（Alarm）。运维人员可以第一时间介入处理，保障了业务的连续性。

通过这套管理体系，分散在城市各个角落的边缘“大脑”，都被一个统一的“中枢神经系统”连接和监控了起来，实现了边缘计算的可管、可控、可视。

5. 总结：三位一体，构筑5G边缘计算的坚实地基

TR 21.917的9.1章节，通过三个环环相扣的子章节，为5G边缘计算构建了一个三位一体的、完整而强大的技术底座。它彻底解决了林工和艾博士面临的所有难题。

  1. 核心网（9.1.1） 扮演了“智能导航员”的角色，通过EASDF等机制，解决了流量如何去往边缘的“寻路”问题。

  2. 应用层（9.1.2） 扮演了“应用生态平台”的角色，通过ECS/EES/EEC架构，解决了应用如何部署和管理的“安家”问题。

  3. 管理面（9.1.3） 扮演了“健康监测系统”的角色，通过LCM、性能和故障管理，解决了边缘如何运维的“体检”问题。

这三者的完美结合，使得5G边缘计算不再是一个孤立的、需要大量定制化集成工作的“盒子”，而是一个与5G网络深度融合的、标准化的、电信级的“分布式算力平台”。对于林工的智慧新区，这意味着无论是港口的AI质检、路口的V2X协同计算，还是体育场的VR/AR渲染，都将拥有一个坚实、可靠、智能的数字地基。5G的革命，也因此从“连接万物”，真正走向了“赋智万物”。

FAQ

Q1：5G边缘计算（Edge Computing）和我们常说的云计算（Cloud Computing）有什么区别？

A1：核心区别在于物理位置和应用场景。云计算是将计算和存储资源集中在大型的、远端的数据中心，适合处理非实时、大并发的业务。而边缘计算则是将计算和存储能力下沉到靠近用户和数据源的网络边缘（如基站、企业园区内），专门处理对低时延、大带宽、数据隐私有极高要求的业务，如工业控制、AR/VR、自动驾驶等。两者是互补关系，而非替代关系。

Q2：EASDF和我们电脑里的DNS有什么相似和不同之处？

A2：相似之处在于，它们都扮演着“地址解析”的角色。DNS将我们输入的网址（域名）解析成服务器的IP地址。EASDF将应用的“服务名”解析成边缘应用服务器（EAS）的IP地址。不同之处在于，EASDF的解析是动态和智能的。它不仅仅是做简单的域名-IP映射，而是会综合考虑UE的实时位置、所连接的UPF、边缘服务器的负载等多种因素，为UE动态地选择一个“最佳”的边缘服务器，并指挥网络建立最优路由。

Q3：边缘应用服务器（EAS）是属于运营商的网络，还是属于企业的网络？

A3：两者皆有可能，这取决于部署模式。1）运营商MEC：EAS由运营商部署在其边缘数据中心，企业可以像购买云服务一样，租用这些边缘算力。2）企业边缘（On-Premise）：EAS由企业（如“灯塔工厂”）自己购买并部署在自己的园区内，通过专线或切片与运营商的5G UPF直连。Rel-17定义的架构，对这两种部署模式都能很好地支持。

Q4：9.1.1节的核心网增强和9.1.2节的应用层架构是什么关系？

A4：是“修路”和“建房”的关系。9.1.1节的核心网增强（如EASDF），主要解决的是网络层面的问题，即如何把UE的业务数据流，高效、准确地“路由”到正确的边缘物理服务器上，如同修好了一条通往新开发区的“高速公路”。而9.1.2节的应用层架构（ECS/EES/EEC），主要解决的是应用层面的问题，即在这片开发区上，如何自动化地部署、配置和管理各种“房子”（边缘应用），并形成一个繁荣的“社区”（应用生态）。

Q5：部署了5G边缘计算，是不是我的数据就绝对安全了？

A5：安全性得到了极大的提升，但并非绝对。边缘计算，特别是企业私有边缘部署，通过将数据处理限制在企业园区内部，避免了数据流经公共互联网，极大地降低了数据在传输链路中被窃取或攻击的风险，满足了数据主权和隐私合规的要求。但这并不意味着边缘节点自身是免疫的。边缘服务器和其上运行的应用，仍然需要配置防火墙、入侵检测、身份认证等完善的安全措施，来抵御针对节点本身的攻击。

关系图谱