深度解析 3GPP TS 23.558：8.13 Charging (边缘世界的“收银台”：计费的原则与挑战)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18及相关计费规范TS 32.257的核心概念，旨在为读者阐明在复杂的边缘计算场景下，3GPP是如何构建其计费体系的。我们将探讨边缘计费的独特性，以及系统如何为每一次智能服务打上清晰的“价签”。

引言：没有商业，不成生态

在之前的章节中，我们已经为“智行一号”构建了一个技术上几近完美的边缘智能世界。它能自动发现服务、无缝切换连接、甚至按需“创造”服务。然而，支撑这一切运转的，是运营商和第三方服务商投入的巨额成本——遍布各地的边缘服务器、复杂的软件平台、以及高昂的运维费用。

如果这些付出无法获得回报，整个边缘生态系统就只是一个昂贵的“实验室玩具”，无法形成可持续发展的商业模式。因此，一个灵活、公平、精细化的计费系统，是边缘计算从技术走向商业的“最后一公里”，是整个生态的“收银台”和“发动机”。

8.13章“Charging”（计费）虽然在规范中只有短短一句话，但它像一个传送门，将我们引导向了3GPP庞大计费体系中的一颗新星——TS 32.257: “Edge computing domain charging”。

The charging procedures are specified in 3GPP TS 32.257.

本章，我们将化身为一名“商业模式设计师”，深入解读TS 23.558架构下的计费原则与挑战，看一看“智行一号”在享受每一次边缘服务时，幕后的“计费引擎”是如何精准地记录下每一笔“消费”。

---

1. 边缘计费的独特性：不再是简单的“流量费”

传统的移动网络计费，核心模型非常简单：按流量（GB）、按时长（分钟）、或按月固定收费。但在边缘计算的世界里，事情变得复杂起来。

“智行一号”的一天，产生了哪些“新型消费”？

• 它请求ECS发现了一次EES。
• 它向EES注册了会话，并发现了EAS。
• 它调用了EES的UE Location API 1000次。
• 它使用的V2X服务（EAS）申请了一条10ms时延保障的QoS通道。
• 它在高速上完成了3次ACR切换，其中涉及了EEC上下文的迁移。
• 它在小镇上触发了一次动态EAS实例化。
• 它使用的EAS，不仅消耗了网络流量，还占用了边缘服务器2个CPU核心和4GB内存。

这些“消费”行为，都远远超出了传统“流量费”的范畴。边缘计费必须能够对这些应用层服务调用和计算资源消耗进行量化和计费。

---

2. 计费架构：谁向谁收费？

根据TS 32.257的原则，边缘计算的计费关系链主要是：

ECSP (边缘计算服务提供商) ⇐向— ASP (应用服务提供商)

• ECSP (Edge Computing Service Provider): 通常是移动网络运营商（MNO），但也可能是拥有边缘基础设施的第三方。它提供了边缘使能层（EEC/EES/ECS）、网络能力和计算资源。
• ASP (Application Service Provider): 即应用开发者，例如“智行一号”的AR导航应用开发商。它开发了EAS和AC，是边缘服务的最终“消费者”。

**最终用户（车主）**通常不直接为边缘服务付费，他购买的是ASP的应用服务（例如，AR导航的年度订阅费）。而ASP再根据其应用消耗的边缘资源，向ECSP支付费用。

---

3. 计费的触发点与信息收集

为了实现精细化计费，边缘使能层的每一个关键实体，都化身为了“计费信息采集员”。它们在执行核心功能的同时，会生成详细的CDR（Charging Data Record，计费数据记录）。

关键的“计费探针”：

• ECS (边缘配置服务器):

  • 计费事件: 每当处理一次来自EEC的**服务开通（Service Provisioning）**请求，就可以生成一条CDR。
  • 计费维度: 可以按请求次数计费，也可以根据请求的复杂性（如是否涉及跨域查询）进行差异化计费。

• EES (边缘使能服务器): 这是最核心的计费信息来源。

  • 计费事件:
    • EAS发现: 每次处理EAS Discovery请求。
    • 注册: 每次处理EEC Registration和EAS Registration。
    • 能力调用: 每次处理来自EAS的UE Location API、Session with QoS API等能力调用请求。可以按调用次数、订阅时长等计费。
    • ACR协调: 每次成功协调一次ACR流程。可以根据ACR的复杂度（如是否涉及边云协同、是否是bundle切换）来差异化计费。
    • 动态实例化触发: 每次成功触发一次Dynamic EAS instantiation。
  • 计费维度: 除了按次计费，EES还可以根据API调用的输入/输出参数、服务质量等进行精细化计费。例如，QoS API的费用，可以与申请的带宽和时延等级挂钩。

• EAS (边缘应用服务器):

  • 计费事件: EAS本身除了消耗网络流量，更重要的是消耗计算和存储资源。
  • 计费维度:
    • 资源占用: 按CPU、内存、存储的占用时长计费（类似于AWS/Azure的虚拟机/容器计费）。
    • 应用层指标: ASP可以定义更高级的业务计费指标，如“AR渲染帧数”、“AI模型调用次数”等。

这些由ECS、EES、EAS生成的CDR，最终会被送到运营商的**CHF（Charging Function，计费功能）**进行汇聚、处理，生成给ASP的最终账单。

---

总结：商业闭环，驱动未来

8.13章虽然只是一个“引子”，但它所指向的计费体系，是边缘计算能否从一个“技术概念”走向一个“繁荣生态”的命脉所在。

• 精细化: 边缘计费告别了“一刀切”的流量模式，转向了基于API调用、资源占用、服务等级（SLA）的多元化、精细化计费模型。
• 价值驱动: 计费的核心，是为“能力”和“资源”定价。谁使用了更高价值的网络能力（如低时延QoS），谁占用了更稀缺的边缘算力，谁就应该支付更高的费用。
• 生态赋能: 一套清晰、公平的计费体系，能够激励运营商更积极地开放网络能力、优化边缘资源，也能引导应用开发者更高效地利用资源、创造出更具商业价值的创新应用。

当“智行一号”结束了一天的旅程，它在边缘世界留下的，不仅是一串数字化的轨迹，更是一份清晰的“消费账单”。这份账单上的每一笔交易，都在为构建一个更智能、更高效、商业上可持续的边缘计算未来，注入着源源不断的动力。

FAQ

Q1：最终用户（比如“智行一号”的车主）完全不需要为边缘服务付费吗？ A1：通常是间接付费。车主购买的是ASP的应用或服务（比如AR导航的订阅套餐）。ASP在给这个套餐定价时，已经将它需要向运营商（ECSP）支付的边缘服务成本，核算在了里面。但也存在一些创新的商业模式，比如运营商可能会推出“5G边缘加速会员包”，用户购买后，他所使用的所有支持的应用，都能享受到更高优先级的边缘服务。

Q2：边缘计费如此复杂，ASP（应用开发者）如何能够预估和控制自己的成本？ A2：这是一个非常关键的商业问题。ECSP（运营商）需要提供一套清晰的“价目表”和“成本管理工具”：

1. 公开的API定价: 每一次API调用（如位置查询、QoS申请）的价格应该是公开透明的。
2. 资源套餐: 提供不同规格的边缘计算资源套餐（如不同vCPU/内存的容器实例），明码标价。
3. 成本预警与配额: ASP可以为自己的应用设置消费配额或预警阈值。例如，“当我的位置API调用费用超过100元/天时，请向我告警。”
4. 沙箱与模拟器: 提供测试环境，让ASP在应用上线前，能够模拟真实负载，预估其边缘服务成本。

Q3：动态EAS实例化是如何计费的？ A3：动态实例化通常会涉及两种费用：

1. 触发费: EES成功触发一次实例化，可以收取一笔固定的API调用费。
2. 资源使用费: 新创建的EAS实例，从启动到销毁，会按其占用的CPU、内存、存储等资源时长进行计费。这种模式与当前主流的云函数/Serverless计算的计费模式非常相似。

Q4：ACR（服务连续性）流程本身会产生费用吗？ A4：会的。ACR是一个由多个API调用和网络交互组成的复杂流程，ECSP完全有理由对其进行计费。计费点可以包括：

• ACR协调费: S-EES每成功协调一次ACR，收取一笔服务费。
• 上下文迁移费: 按照EEC Context或Application Context的迁移数据量来计费。
• 捆绑包附加费: 如果是一次复杂的EAS bundle切换，由于协调难度更高，可以收取更高的费用。 通过对ACR计费，可以激励ASP在应用设计时，更合理地规划服务范围，避免不必要的、过于频繁的切换。

Q5：3GPP的计费体系（如TS 32.257）是强制性的吗？运营商可以有自己的计费模式吗？ A5：3GPP提供的是一个标准化的计费框架和信息模型。它定义了应该采集哪些计费信息（如API调用事件）、这些信息的格式（CDR字段），以及这些信息如何在网络实体间传递。这保证了不同厂商的设备能够生成统一格式的计费话单。 然而，具体的定价策略和商业模式，则完全由运营商（ECSP）自己决定。例如，运营商可以决定对位置API免费以吸引开发者，而对高价值的QoS API收取高额费用。标准只提供“记账”的工具，而“如何定价”和“如何打包销售”，则是运营商的商业决策。