51学通信

深度解析 3GPP TS 23.548：第1-3章 奠定边缘计算的基石 (范围、参考与术语)

27分钟阅读

好的，遵从指令。现在为您带来系列文章的第二篇，我们将从规范的开篇部分，即第1、2、3章开始，进行深入的拆解分析。

深度解析 3GPP TS 23.548：第1-3章 奠定边缘计算的基石 (范围、参考与术语)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“Chapter 1 Scope”、“Chapter 2 References”以及“Chapter 3 Definitions of terms, symbols and abbreviations”的核心章节，旨在为读者构建理解5G边缘计算增强技术的坚实地基。

在上一篇的全景概览中，我们描绘了3GPP TS 23.548为解决边缘计算“发现鸿沟”、“移动诅咒”和“协同壁垒”三大挑战所构建的宏伟蓝图。然而，任何宏伟的建筑都始于坚实的地基。今天，我们将回归本源，逐字逐句地剖析这份规范的开篇三章，它们分别是范围（Scope）、参考文献（References）和定义与缩写（Definitions and Abbreviations）。

这三个章节虽然不像后续章节那样包含复杂的流程图和信令交互，但它们的重要性不言而喻。它们定义了这份规范的边界，确立了它的技术坐标，并统一了我们赖以沟通的技术语言。可以说，透彻理解这三章，是我们后续深入探索所有技术细节的“入场券”和“地图图例”。

为了让这段奠基之旅不再枯燥，我们将引入一个贯穿全文的主角：一台名为**“智行一号”**的5G自动驾驶物流车。它的日常工作是在繁忙的智慧城市中，高效、安全地完成包裹的自动配送。它的每一次路径规划、每一次避障决策、每一次与交通系统的联动，都高度依赖于5G网络提供的低时延、高可靠的边缘计算服务。我们将以“智行一号”的视角，来审视和理解这些看似抽象的定义和范围。

1. 第一章 Scope (范围)：划定战场边界

让我们首先来看规范的第一章，它通常只有寥寥数语，却至关重要。

The present document defines the Stage 2 specifications for enhancements of 5G System to support Edge Computing.

这句话虽然简短，却蕴含了三个关键信息点，为整个规范精准地“定了性”。

1.1 “Stage 2”：蓝图的绘制阶段

在3GPP的世界里，规范的制定通常遵循三个阶段（Stage）：

  • Stage 1（阶段一）：需求定义。 这个阶段主要从业务和应用视角出发，回答“我们需要什么？”的问题。对于边缘计算，Stage 1会定义出类似“移动用户需要能够无缝连接到最近的应用服务器”这样的高层需求。

  • Stage 2（阶段二）：架构与功能设计。 这是TS 23.548所处的阶段。它负责将Stage 1的需求翻译成技术语言，回答“我们如何实现它？”的问题。它会定义出需要哪些新的网络功能（如EASDF）、现有功能需要做哪些增强、以及它们之间如何交互来满足需求。这个阶段的产出是逻辑架构图和功能流程，是我们这篇文章后续解读的核心。

  • Stage 3（阶段三）：协议与实现。 这个阶段负责将Stage 2的架构和流程进一步具体化，回答“具体怎么做？”的问题。它会定义出网元之间接口上信令消息的具体格式、参数、编码方式等，是设备厂商进行产品开发的直接依据（例如，TS 29.xxx系列的规范）。

因此，明确TS 23.548是Stage 2规范，意味着我们在这里读到的是5G系统支持边缘计算的“架构设计蓝图”和“功能说明书”，而不是具体到某个比特如何编码的“施工图纸”。

1.2 “Enhancements of 5G System”：在巨人肩膀上的进化

这个短语强调了TS 23.548并非从零开始构建一个新网络，而是对现有的5G系统（5GS）进行增强（Enhancements）。这说明它的所有设计都必须与5G的核心架构（定义在TS 23.501中）保持兼容和协同。

它不是要颠覆5G，而是要为5G这辆“超级跑车”加装一套专门用于“越野”（应对边缘计算复杂场景）的“智能悬挂和导航系统”。我们在后续章节中看到的所有新功能，都是以插件或补丁的形式，有机地融入到庞大的5G体系中。

1.3 “to support Edge Computing”：明确的核心使命

这最后一部分点明了所有这些工作的最终目的——支持边缘计算。规范并不关心边缘应用本身是什么（是“智行一号”的路径规划，还是AR眼镜的实时渲染），它关心的是，5G网络作为一个管道和平台，需要提供哪些通用能力来支撑这些上层应用。

以“智行一号”为例：

  • Stage 1需求： “智行一号”需要在城市中移动时，其实时视频流和传感器数据能被发送到时延最低的交通AI分析平台进行处理，并接收回传的驾驶指令。

  • TS 23.548 (Stage 2) 的任务： 设计一套机制，让“智行一号”无论行驶到哪个路口，5G网络都能帮它找到并连接到那个“时延最低的AI分析平台”。这份规范定义了EASDF、L-PSA、Session Breakout等一系列架构和流程来实现这一目标。

2. 第二章 References (参考文献)：构建技术坐标系

第二章列出了一系列被本文档引用的其他规范。这就像一幅学术论文的参考文献列表，它告诉我们TS 23.548的技术根基在哪里，它依赖哪些“前人”的工作，并与之构成了怎样的技术网络。

我们无需逐一罗列所有文献，但理解其中几个关键的引用，能帮助我们构建起一个清晰的知识坐标系：

  • TS 23.501 “System architecture for the 5G System (5GS)”: 这是“圣经”级别的规范，定义了5G系统的整体架构、核心网元（AMF, SMF, UPF, PCF等）及其基本功能。TS 23.548中提到的所有网元和基本概念，都源于此。可以说，TS 23.501是主干，TS 23.548是上面长出的一个重要分支。

  • TS 23.502 “Procedures for the 5G System (5GS)”: 这份规范详细描述了5G系统中的各种核心流程，如注册、PDU会话建立、移动性管理等。TS 23.548中定义的边缘发现和重定位流程，都是在这些基础流程上进行的修改和扩展。例如，它会在PDU会话建立流程中增加“下发EASDF地址”的步骤。

  • TS 23.503 “Policy and Charging Control Framework”: 定义了5G的策略控制框架。我们之前提到的AF影响流量路由、URSP规则等，都离不开PCF（策略控制功能）的参与。这份规范解释了PCF是如何工作的，以及策略是如何生成的。

  • TS 23.558 “Architecture for enabling Edge Applications (EA)”: 这份规范由3GPP SA6工作组制定，它从应用层的视角来定义边缘应用的架构，引入了EEC（边缘使能客户端）、EES（边缘使能服务端）等概念。TS 23.548作为SA2制定的核心网规范，需要与之协同，确保网络层提供的能力能够支撑上层应用架构的实现。

通过这些参考文献，我们能清晰地看到，TS 23.548并非孤立存在，而是深深植根于整个3GPP 5G规范体系之中，是系统工程思想的完美体现。

3. 第三章 Definitions and Abbreviations (术语与缩写)：统一技术语言

这是本文的核心。规范的语言以其精确性和无歧义性著称，而这正是通过严格的术语定义和缩写来实现的。我们将逐一解析本章定义的关键术语，并始终以“智行一号”的场景来赋予它们生命。

3.1 Terms (术语)

Edge Application Server (EAS)

An Application Server resident in the Edge Hosting Environment.

  • 深度解析： 这是边缘计算中最核心的应用实体。它就是运行具体业务逻辑的服务端程序。值得注意的是，3GPP的定义非常“克制”，它只关心这个服务器的“位置”——位于边缘托管环境中。至于服务器里面运行的是什么、用什么技术栈，规范完全不关心。

  • 场景代入(“智行一号”)： 对于“智行一号”，可能存在多个EAS为它服务：

    • 高精地图与定位EAS： 实时接收“智行一号”的GPS和传感器数据，结合高精度地图进行亚米级定位。

    • AI视觉分析EAS： 处理“智行一号”上传的实时摄像头视频流，识别行人、车辆、交通信号灯。

    • 路径规划与调度EAS： 综合定位信息、视觉分析结果和全局交通态势，为“智行一号”规划出最优行驶路径。

    这些EAS都必须部署在“边缘”，才能满足毫秒级的响应需求。

Edge Hosting Environment (EHE)

An environment providing support required for Edge Application Server’s execution.

  • 深度解析： EHE是EAS赖以生存的“土壤”。它是一个物理或虚拟化的计算和存储资源池，通常位于运营商的边缘数据中心（Edge Data Center）。它提供了计算、存储、网络等基础设施，让EAS可以部署和运行。可以将其理解为IaaS（基础设施即服务）或PaaS（平台即服务）的边缘版本。

  • 场景代入(“智行一号”)： 部署上述多个EAS的那个物理机房，就是EHE。这个机房可能就建在“智行一号”运营区域（如一个大型港口或物流园区）的5G基站旁边，通过极短的光纤与5G的UPF连接，实现了物理上的“近”。

Central DNS resolver/server (C-DNS)

A DNS resolver/server centrally deployed by the 5GC operator or 3rd party and is responsible for resolving the UE DNS Queries into suitable Edge Application Server (EAS) IP address(es).

  • 深度解析： 这是我们传统认知中的DNS服务器，部署在网络的核心位置。在没有边缘计算增强机制时，所有的DNS查询都可能被发送到这里。规范提到它也可以解析出EAS的IP地址，但由于其“中心化”的部署位置，它缺乏对UE精确网络位置的感知，因此解析结果可能不是最优的。

  • 场景代入(“智行一号”)： 假设“智行一号”的系统尝试解析ai_vision.operator.com，如果请求被发往了位于集团总部的C-DNS。C-DNS可能只知道这个服务在北京、上海、广州都有节点，它可能会根据一些粗略的策略返回北京节点的IP。但此时“智行一号”可能正行驶在北京的海淀区，而C-DNS返回的却是朝阳区的EAS地址，这就不是最优选择。

Local DNS resolver/server (L-DNS)

A DNS resolver/server that may be locally deployed by 5GC operator or 3rd parties within the Local DN, and is responsible for resolving UE DNS Queries into suitable EAS IP address(es) within the local DN.

  • 深度解析： L-DNS是相对于C-DNS而言的，它被部署在网络的“本地”或“边缘”，靠近用户。由于地理位置上的优势，它天然就比C-DNS更了解本地的网络拓扑和EAS部署情况。它可以更精确地将DNS查询解析到本地数据网络（Local DN）内的EAS IP。在某些架构下，L-DNS是实现边缘发现的一种方式。

  • 场景代入(“智行一号”)： 同样是解析ai_vision.operator.com，“智行一号”的请求如果被引导到了部署在海淀区网络机房的L-DNS，这个L-DNS就会“心知肚明”：“哦，这个请求来自海淀区，那我应该返回部署在海淀边缘机房（EHE）的那个AI视觉分析EAS的IP地址。” 这个结果显然比C-DNS的要精准得多。

Local part of DN (L-DN)

The set of network entities of a DN that are deployed locally. The local access to the DN provides access to the local part of DN.

  • 深度解析： DN（Data Network）是5G系统外部的数据网络，例如互联网或企业专网。而L-DN特指这个数据网络中，部署在“本地”的那一部分。它包含了本地的路由器、交换机，以及我们的主角EAS和EHE。5G核心网中的L-PSA UPF，其N6接口（连接外部DN的接口）就是直接与L-DN相连的。

  • 场景代入(“智行一号”)： L-DN就是连接L-PSA UPF与海淀边缘机房（EHE）之间的那段局域网络。当“智行一号”的边缘业务流量从L-PSA UPF这个“高速出口”下来后，就是通过L-DN这条“辅路”，最终抵达EAS这个“目的地”的。

3.2 Abbreviations (缩写)

缩写是3GPP规范的灵魂，掌握它们是流畅阅读的必备技能。

| 缩写 | 全称 | 核心角色与解读（以“智行一号”为例） |

| :--- | :--- | :--- |

| EASDF | Edge Application Server Discovery Function | 边缘发现的“智能大脑”。这是TS 23.548引入的核心网元。它是一个超级智能的DNS，能与SMF联动，获取“智行一号”的精确网络位置，从而解析出最优EAS的IP。L-DNS更侧重于部署位置带来的“本地知识”，而EASDF则更侧重于与5GC核心网元联动带来的“网络智能”。 |

| EDC | Edge DNS Client | UE侧的“忠诚代理”。位于“智行一号”车载终端内的功能，确保所有边缘应用的DNS请求，都会乖乖地发往网络指定的EASDF，而不是随便找个公共DNS问路。 |

| ECS | Edge Configuration Server | 边缘配置的“信息中心”。这是由SA6定义的，负责告诉UE上的EEC（边缘使能客户端）关于边缘应用平台的一些配置信息，比如EES的地址等。5GC可以通过NAS消息将ECS的地址推送给“智行一号”。 |

| EEC | Edge Enabler Client | UE应用侧的“使能管家”。位于“智行一号”上的一个客户端软件，负责与网络边缘平台交互，发现和使用边缘服务。 |

| EES | Edge Enabler Server | 网络边缘侧的“使能平台”。部署在EHE中，与EEC对应，管理和开放边缘服务。 |

| C-PSA UPF | Central PSA UPF | 中央数据“枢纽站”。处理“智行一号”访问普通互联网（如查询天气API）流量的UPF，位于核心网。 |

| L-PSA UPF | Local PSA UPF | 边缘数据“立交桥”。处理“智行一号”访问本地EAS（如AI视觉分析）流量的UPF，部署在网络边缘，是实现流量下沉的关键。 |

| UL CL | Uplink Classifier | 上行流量的“智能分拣员”。位于UPF上的一个功能，能够识别出“智行一号”发往EAS的数据包，并将其从主路（去往C-PSA）引导到通往L-PSA的支路。 |

| HR-SBO | Home Routed Session BreakOut | 漫游时的“本地捷径”。当“智行一号”被跨国运输到德国进行测试时，它依然使用归属在中国（HPLMN）的SIM卡。HR-SBO允许“智行一号”在访问德国本地的边缘测试服务时，流量在德国（VPLMN）就近分流，而无需绕回中国。 |

通过将这些枯燥的术语和缩写融入到“智行一号”的实际运营场景中，我们不仅记住了它们的名字，更重要的是理解了它们在整个边缘计算生态系统中所扮演的鲜活角色和承担的关键职责。

4. 总结：奠定坚实的第一步

通过对TS 23.548前三章的深度剖析，我们完成了后续探索之旅的所有必要准备：

  • 我们通过第一章“范围”，明确了我们的研究对象是5G系统的Stage 2架构增强，目标是为边缘计算提供通用支撑。

  • 我们通过第二章“参考文献”，将TS 23.548精准地放置在了5G规范体系的宏大坐标系中，理解了它与TS 23.501等核心规范的传承与发展关系。

  • 我们通过第三章“定义与缩写”，借助“智行一号”的生动案例，掌握了边缘计算场景下的核心技术词汇，统一了我们沟通的语言。

地基已经夯实，图纸的图例也已解读完毕。从下一篇文章开始，我们将正式进入这座“5G边缘计算大厦”的主体结构，从第四章“参考架构与连接模型”开始，一步步揭示其内部精巧的设计和复杂而高效的运作机制。

FAQ环节

Q1：L-DNS（本地DNS）和EASDF（边缘应用服务器发现功能）是什么关系？它们会同时存在吗？

A1：它们是实现边缘发现的两种不同但可能共存的机制。L-DNS更多是一种基于“部署位置”的优化，它因为离用户近，所以更了解本地情况。而EASDF是一种基于“网络智能”的优化，它是核心网的一个功能，能与SMF等网元交互，获取UE的动态网络上下文信息，做出更精准的判断。在规范的流程中，两者都可能被使用。例如，网络可能先通过EASDF进行初步的发现，然后在建立本地分流路径后，将UE的DNS服务器地址切换为更靠近新路径的L-DNS，以优化后续的DNS查询。

Q2：为什么需要一个专门的术语“边缘托管环境（EHE）”？它和我们常说的“边缘数据中心”有什么区别？

A2：在概念上，它们非常接近，但“EHE”是3GPP从网络规范视角给出的定义，更强调其“功能性”。EHE是一个逻辑概念，指代“能够支持EAS运行的环境”，它包含了计算、存储、网络等一系列资源。而“边缘数据中心”则更偏向于一个物理概念，指代部署这些资源的物理场所。一个物理的边缘数据中心里，可以承载一个或多个逻辑上的EHE。使用EHE这个术语，使得规范可以不关心底层的具体物理实现，保持了技术的通用性。

Q3：HR-SBO这个缩写看起来很复杂，它只在漫游场景下有用吗？

A3：是的，HR-SBO（Home Routed Session Breakout）是专门为漫游场景设计的核心技术。在非漫游时，我们可以直接使用LBO（Local Breakout，本地分流）或者前面提到的几种连接模型。但在漫游时，默认的归属地路由（HR）会把所有流量都带回用户的归属国网络，这对于时延敏感的边缘业务是致命的。HR-SBO的精妙之处在于，它能在保持HR会话基本属性（如IP地址由归属地分配、计费策略由归属地控制）的同时，允许拜访地网络（VPLMN）“智能”地将特定的、访问本地边缘服务的流量在本地进行分流，从而解决了漫游用户的边缘计算体验问题。

Q4：作为一名应用开发者，我需要直接和L-PSA UPF或UL CL这些网络功能打交道吗？

A4：不需要。L-PSA UPF和UL CL是5G核心网用户面的功能实体，对应用开发者是完全透明的。开发者的应用只需和EAS（你自己的应用服务器）通信。你可能需要做的，是通过运营商提供的北向接口（通常通过AF/NEF），将你的应用部署信息（如EAS的IP地址范围、服务的FQDN等）和路由策略偏好（如希望哪些用户流量被边缘分流）“告知”5G网络。网络内部的SMF会根据这些信息，自动去配置UPF上的UL CL和L-PSA，完成底层的流量工程。

Q5：学完这前三章，最重要的收获应该是什么？

A5：最重要的收获是建立起一个清晰的概念框架和统一的词汇表。你应该能清晰地区分EAS、EHE、L-DN这些外部实体，以及EASDF、L-PSA UPF这些5G系统内部的增强功能。理解这些基本构件各自的角色和定位，就像学习下棋前认清“车、马、炮”一样，是理解后续复杂“棋局”（即信令流程）的基础。没有这个基础，后续的章节将会变得晦涩难懂。

关系图谱