51学通信

深度解析 3GPP TS 23.548：6.5 & 6.7 & 6.8 网业协同的生态构建 (Part 6 - 上层架构、漫游协同与信息映射)

24分钟阅读

好的，遵从指令。我们已经详细探讨了5G边缘计算的架构、发现机制、移动性管理以及高级重定位技术。现在，我们将目光投向一个更宏观、更具战略意义的层面，即5G网络作为一个整体，如何与第三方应用生态进行交互，以及如何支撑一个名为“3GPP应用层架构”的上层建筑。

深度解析 3GPP TS 23.548：6.5 & 6.7 & 6.8 网业协同的生态构建 (Part 6 - 上层架构、漫游协同与信息映射)

本文技术原理深度参考了3GPP TS 23.548 V18.9.0 (2025-03) Release 18规范中，关于“6.5 Support of 3GPP Application Layer Architecture for Enabling Edge Computing”、“6.7 Support of the local traffic routing in VPLMN for Home Routed PDU Session for roaming (HR-SBO)”以及“6.8 Support for mapping between EAS address Information and DNAI”的核心章节。本文旨在为读者揭示5G边缘计算解决方案如何从一个单纯的网络能力，演进为一个开放的生态平台：它如何支撑标准化的上层应用架构，如何在复杂的漫游场景下实现跨运营商的精妙协同，以及如何为应用开发者提供“反向查询”网络拓扑信息的关键能力。

在之前的章节里，我们的主角“智行一号”在5G网络的精心调度下，实现了高效的本地计算和无缝的业务迁移。这些流程虽然强大，但大多是在一个“封闭”的系统内完成的——即UE与运营商核心网之间的互动。

然而，边缘计算的最终愿景，是构建一个开放的、跨运营商、跨云服务商的庞大生态。为了实现这一愿景，TS 23.548必须回答以下三个深层次的生态级问题：

  1. 标准化接口问题： 除了DNS和IP这些底层协议，网络能否为上层应用提供一套更标准、更丰富的应用层接口来发现和配置边缘服务？

  2. 全球化协同问题： 当“智行一号”漫游到国外，它不仅需要连接到本地的边缘服务器，还需要与当地的应用生态（如法国的交通管理平台）进行交互。归属地网络和拜访地网络之间，该如何进行复杂的信令和策略协同，来支撑这种跨国、跨生态的边缘服务？

  3. 信息不对称问题： 应用开发者（AF）知道自己的服务器IP地址，但他们并不知道这些IP地址对应到5G网络中的哪个“逻辑位置”（DNAI）。如何打通这层信息壁垒，让AF能够用“IP地址”来查询“网络位置”，从而更智能地向网络提交流量路由策略？

TS 23.548的6.5, 6.7, 6.8这三个章节，正是对上述三大生态级问题的系统性回应。它们将我们的视野从“网络内部”提升到了“网络与外部世界”的交界地带。

1. 支撑上层建筑：6.5 支持3GPP应用层架构 (Support of 3GPP Application Layer Architecture)

3GPP不仅仅定义了网络层的协议（由SA2等工作组负责），也定义了一套应用层的架构来使能边缘计算（由SA6工作组负责，核心规范为TS 23.558）。这套架构定义了三个关键的角色：

  • EEC (Edge Enabler Client): 位于UE侧，是应用的“边缘服务代理”，负责与边缘平台交互。

  • EES (Edge Enabler Server): 位于边缘网络侧，是“边缘服务平台”，负责服务的注册、发现、生命周期管理等。

  • ECS (Edge Configuration Server): 位于中心云，是“边缘配置中心”，负责告诉EEC去哪里找到合适的EES。

问题来了，UE上的EEC，在启动时，如何知道该去联系哪个ECS呢？它需要一个初始的“引导地址”。

A UE may host EEC(s)… and support the ability to receive ECS address(es) from the 5GC and to transfer the ECS address(es) to the EEC(s). …the UE indicates in the PCO at PDU Session establishment that it supports the ability to receive ECS address(es) via NAS… the UE may receive ECS Address Configuration Information from the SMF via PCO…

  • 深度解析： 6.5节的核心内容，就是定义了5G核心网（5GC）如何为上层的SA6架构提供这个关键的**“引导服务”**。

    • 能力表明： 支持SA6架构的“智行一号”，在建立PDU会话时，会通过PCO向网络声明：“我具备接收ECS地址的能力。”

    • 网络推送： SMF从UDM获取用户的签约数据，其中就可能包含了运营商或第三方为其配置的ECS服务器地址。SMF将这些地址信息通过PCO，在PDU会话建立或修改的响应中，推送给“智行一号”。

    • 上层消费： “智行一号”的操作系统收到这些地址后，将其提供给车机系统上运行的EEC。EEC拿到地址后，就知道该去哪里“报到”，从而启动后续的服务发现和调用流程。

  • 生态意义： 这个看似简单的地址推送机制，其意义非凡。它将SA2定义的“连接网络”与SA6定义的“应用生态”无缝地衔接了起来。5G网络不仅仅是一个数据管道，它还成为了上层应用生态的“配置分发通道”和“引导者”。通过这个机制，运营商可以为不同的用户、不同的业务（通过DNN/S-NSSAI区分），动态地配置不同的边缘应用生态入口（ECS地址），实现了网络能力与应用生态的深度绑定。

2. 漫游的巅峰之作：6.7 HR-SBO下的本地路由支持

我们在第四章已经初步了解了HR-SBO（归属地路由下的会话分离）的架构，但其内部的协同流程远比架构图所展示的要复杂。6.7节用大量的篇幅，详细定义了这场由HPLMN（归属地）和VPLMN（拜访地）两大运营商联合上演的“跨国大戏”。

“智行一号”现在正在德国汉堡港进行测试，使用着中国的SIM卡。

2.1 授权与策略的“跨国传递” (6.7.2.2 PDU Session establishment)

…the H-SMF requests and retrieves the optional VPLMN Specific Offloading Policy from H-PCF… The H-SMF generates VPLMN Specific Offloading Information (i.e. IP range(s) and/or FQDN(s) allowed to be routed to the local part of DN in VPLMN…)… H-SMF provides [it]… to the V-SMF…

  • 深度解析： 这是HR-SBO的“授权与策略”核心。

    1. HPLMN决策： 当H-SMF（中国）收到V-SMF（德国）为“智行一号”发来的HR会话建立请求时，它会首先向H-PCF（中国的策略中心）查询：“这个用户在德国漫游时，是否允许，以及允许哪些业务在本地分流？”

    2. 生成策略： H-PCF根据与德国运营商的漫游协议，返回一个“拜访地特定分流策略”。这个策略可能规定：“只有访问*.hamburg-port.de的流量，才允许在德国本地分流。”

    3. 策略传递： H-SMF将这个策略打包成“拜访地特定分流信息”，通过核心网信令，发送给德国的V-SMF。

  • 协同的精髓： 德国的V-SMF收到的，是一份来自中国H-SMF的、清晰的“授权指令书”。它明确规定了V-SMF“能做什么”和“不能做什么”。这确保了归属地运营商对用户的业务策略和计费拥有最终的控制权，即使流量是在拜访地网络进行分流。

2.2 “双重身份”的DNS发现 (6.7.2.3 EAS Discovery with V-EASDF)

现在，V-SMF已经获得了“授权书”，它可以为“智行一号”在德国的本地边缘业务保驾护航了。

If the target FQDN of the DNS query is not part of the FQDN authorized… the V-EASDF proceeds to step 12 of clause 6.2.3.2.2 where it sends the DNS query which may include the HPLMN address information as the EDNS Client Subnet option…

If VPLMN Specific Offloading Information does not include FQDN range and the EAS IP address of the DNS response is not part of the IP range(s) authorized… The V-SMF indicates the V-EASDF to construct and to send another DNS query…

  • 深度解析： 这里的V-EASDF（拜访地的EASDF）扮演了一个极其聪明的“双面间谍”角色。

    • 场景一（访问本地服务）： “智行一号”查询crane-control.hamburg-port.de。V-EASDF收到后，发现这个域名在H-SMF下发的“授权书”范围内。于是，它执行本地发现流程，就像我们在Part 2中分析的那样，与V-SMF配合，为这个流量动态建立一条通往汉堡港EAS的本地分流路径。

    • 场景二（访问归属地边缘服务）： 假设“智行一号”需要访问一个部署在中国北京的、只有归属地用户才能访问的边缘服务beijing-traffic.chinamobile.com。这个域名显然不在“授权书”范围内。此时，V-EASDF会怎么做？

      1. 它会再次发起一次DNS查询。

      2. 但这次查询，它会巧妙地加上ECS选项，而ECS的内容，则是代表“智行一号”归属地网络出口的IP地址（这个地址由H-SMF提供给V-SMF）。

      3. 这个请求最终会被路由到中国的DNS系统。中国的DNS系统看到这个来自归属地的ECS，就会返回北京的EAS IP地址。

      4. 这个流量，最终会通过N9隧道，回到中国进行路由。

  • 生态意义： HR-SBO下的EAS发现机制，完美地解决了漫游用户的“双重身份”问题。它既能让UE享受到拜访地网络的本地低时延服务，又能让其在需要时，无缝地穿透回其归属地网络，访问归属地的专属边缘服务。这为构建全球化的、运营商之间互联互通的边缘计算漫游生态奠定了坚实的技术基础。

3. 打破信息壁垒：6.8 EAS地址与DNAI的映射支持

至此，我们所有的讨论都基于一个前提：当AF向网络提出请求时，它需要告诉网络一个target DNAI。但现实中，应用开发者（AF）往往只关心自己的应用，他们知道EAS的IP地址，却对运营商内部的网络拓扑（如DNAI的划分）一无所知。

In order to make sure the AF can query for DNAIs, the 5GS may help determine proper DNAI(s) and notify the information to AF based on AF request providing EAS address information (i.e. IP address(es), EAS IP range(s) or FQDN(s)).

  • 深度解析： 6.8节定义了一个“逆向查找”服务。它允许AF用自己所知的EAS地址信息，来向网络查询这些地址属于哪个DNAI。

  • 实现机制：

    1. 数据配置： 运营商在OAM系统中，预先配置好EAS IP地址/FQDN与DNAI的映射关系。这份“地图”被存储在NEF或UDR中。

    2. AF查询： AF通过NEF调用Nnef_DNAIMapping_Subscribe服务，发起查询。查询的输入是EAS的IP地址或FQDN，期望的输出是对应的DNAI列表。

    3. NEF响应： NEF查询本地或UDR中的映射数据库，将结果返回给AF。

    4. 订阅-通知： AF还可以订阅这份映射关系的变更。当运营商在某个DNAI下新增或变更了EAS部署时，NEF会主动通知AF。

构建智能应用的基石

The EAS address and DNAI Mapping Information record in UDR is shown Table 6.8.1-1.

这个看似简单的查询服务，对于构建真正智能的边缘应用至关重要。

  • 场景代入(“智行一号”)：

    1. 运营中心（AF）的监控系统发现，部署在IP_range_A的服务器集群负载过高。

    2. 在过去，AF对此无能为力，因为它不知道IP_range_A在网络拓扑中的意义。

    3. 现在，AF可以先向NEF查询：IP_range_A对应哪个DNAI？NEF返回：DNAI-A。

    4. 然后，AF可以继续查询：DNAI-A附近还有哪些可用的DNAI？网络可能会返回DNAI-B和DNAI-C。

    5. 最后，AF向NEF发起一个AF触发的边缘重定位请求：“请将‘智行一号’的业务，从DNAI-A迁移到负载较低的DNAI-B。”

  • 生态意义： 这个“地址-位置”的映射服务，第一次真正将**应用开发者（IT世界）的语言（IP地址）与网络运营商（CT世界）的语言（DNAI）**之间，建立了一座可以双向翻译的桥梁。它赋予了应用前所未有的“网络拓扑感知能力”，让应用能够基于网络的状态，做出更深层次、更智能的调度决策，是实现高级“云网融合”的必要前提。

4. 总结：从封闭网络到开放生态

通过对6.5, 6.7, 6.8章节的联合剖析，我们看到了3GPP TS 23.548在构建开放边缘生态方面的深远布局：

  • 向上兼容 (6.5): 通过为SA6应用层架构提供引导服务，确保了网络层能力能够被标准化的上层应用框架所消费，促进了产业链的成熟。

  • 横向互通 (6.7): 通过定义精妙的HR-SBO协同流程，解决了漫游场景下的业务体验和运营商管控难题，为边缘计算的全球化部署铺平了道路。

  • 向下开放 (6.8): 通过提供EAS地址到DNAI的映射服务，向应用暴露了必要的网络拓扑抽象信息，打破了信息孤岛，使能了更高级的应用层智能调度。

这三大支柱，共同将5G边缘计算从一个运营商内部的“网络功能”，提升为了一个能够支撑上层标准、连接全球伙伴、赋能开发者创新的开放生态平台。对于“智行一号”而言，它所依赖的，不再是某一个运营商的孤立网络，而是一个潜力无限的、全球互联的边缘计算星辰大海。

FAQ环节

Q1：3GPP SA2和SA6两大工作组在边缘计算上是如何分工的？它们制定的规范会冲突吗？

A1：它们的分工非常清晰，互为补充。SA2（负责系统架构）的核心是TS 23.548，它关注“网络如何支持边缘计算”，定义的是5GC核心网的增强，解决的是流量路由、移动性、网络能力开放等网络层问题。SA6（负责应用使能）的核心是TS 23.558，它关注“应用如何利用边缘计算”，定义的是一套应用层的API和框架（EEC/EES/ECS），解决的是边缘服务的注册、发现、生命周期管理等应用层问题。两者通过6.5节定义的ECS地址推送机制等进行衔接，确保了底层网络能力可以被上层应用框架顺利调用，不存在冲突。

Q2：在HR-SBO场景下，计费是如何处理的？流量在VPLMN分流了，是按本地流量计费，还是按国际漫游计费？

A2：计费是漫游协议的核心，非常复杂。通常情况下，即使流量在VPLMN本地分流，其计费策略和费率的制定权仍然属于HPLMN。H-SMF在向V-SMF下发“分流信息”时，可以附带相关的计费策略标识。VPLMN的UPF会根据这些标识，生成计费话单，并将其上报给VPLMN的计费系统。最终，两个运营商之间会通过漫游清算协议（如TAP/RAP）进行结算。对用户而言，账单仍然是由其归属运营商HPLMN出具的，账单上可能会将这部分流量单独列为“漫游地本地业务流量”，其费率由HPLMN根据与VPLMN的协议来制定。

Q3：AF查询EAS地址到DNAI的映射，这是否意味着运营商的网络拓扑对第三方应用完全透明了？

A3：不是完全透明，而是一种受控的、抽象的开放。首先，AF必须通过NEF的安全认证和授权，不是任何应用都能查询。其次，暴露给AF的DNAI本身就是一个逻辑标识，而非物理地址。运营商可以通过DNAI的命名，向应用暴露必要的拓扑信息（如DNAI-Frankfurt-DC1），但隐藏了底层的UPF ID、路由器IP等内部细节。这是一种在“信息开放”与“网络安全”之间取得的精妙平衡。

Q4：为什么在HR-SBO场景下，V-EASDF需要具备那么复杂的双重DNS解析能力？

A4：因为漫游中的UE，其业务需求是双重的。它既可能需要访问拜访地的本地化服务（如“智行一号”使用汉堡港的调度系统），也可能需要访问只有其归属地网络才能提供的专属服务（如访问公司内部的数据库）。V-EASDF的复杂性，正是为了同时满足这两种需求。通过检查域名是否在“授权列表”中，它能判断出这是一个“本地业务”还是一个“归属地业务”，并采取截然不同的解析策略（本地解析 vs. 带ECS转发回国），从而实现了对用户业务意图的精准识别和路由引导。

Q5：这些生态构建的章节，对于一个初级的网络工程师来说，学习的重点应该是什么？

A5：对于初级工程师，重点在于理解“接口”和“边界”的理念。

  • 理解6.5节，重点是明白5GC不仅仅是数据管道，它还可以通过PCO向UE推送上层配置，这是“网络赋能应用”的一种具体体现。

  • 理解6.7节，重点是理解H-SMF和V-SMF之间的角色划分，即HPLMN负责“决策和授权”，VPLMN负责“执行和本地优化”，这是跨域协同的基本原则。

  • 理解6.8节，重点是理解NEF作为“API网关”的价值，以及应用可以用“自己熟悉的信息（IP）”来换取“网络内部的信息（DNAI）”，这是一种重要的信息解耦和翻译功能。

掌握这些宏观的、接口化的思想，比一开始就陷入具体的信令参数更有助于建立对整个生态的认知。

关系图谱