51学通信

深度解析 3GPP TS 23.558：8.6 EES能力开放 (EES的“百宝箱”：网络能力的开放与赋能)

22分钟阅读

深度解析 3GPP TS 23.558：8.6 EES能力开放 (EES的“百宝箱”：网络能力的开放与赋能)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.6 EES capability exposure to EAS and EEC”的核心章节。在上一篇中，“智行一号”已经通过EAS发现流程，成功与路口的V2X服务器建立了连接。然而，这仅仅是边缘计算旅程的开始。一段简单的连接，并不能完全发挥5G与边缘融合的威力。真正的魔力在于，应用如何与网络深度对话，利用网络独有的“超能力”。本章，我们将打开边缘使能服务器（EES）的“百宝箱”，一探究竟。

引言：从“连接”到“协同”，EES的角色升华

“智行一号”已经与路口的V2X服务器（S-EAS）成功“牵手”，实时数据流正在两者之间奔涌。但S-EAS很快发现了一些力不从心的地方：

  • 它知道“智行一号”在附近，但它不知道精确到亚米级的实时位置，这使得碰撞预警不够精准。
  • 它感知到“智行一号”正在高速移动，但它无法预测车辆何时会脱离自己的服务范围，导致切换准备措手不及。
  • 它希望为“智行一号”的关键协同驾驶指令提供VIP级的网络保障，但它无权指挥网络。

这些难题，应用本身无法解决。答案，深藏于网络之中。8.6章的核心使命，就是将EES从一个单纯的“服务中介”（负责EAS发现），升华为一个强大的**“能力代理”和“数据中心”**。EES将打开它珍藏的“百宝箱”，向经过授权的EAS和EEC暴露出3GPP核心网的强大能力。

This clause describes service capability APIs exposed by the EES to the EAS(s) and EEC(s). The service capability APIs exposed include EES capabilities and exposed 3GPP Core Network capabilities.

通过这些API，EAS不再是一个孤立的计算节点，而是变成了一个能“听懂”网络心跳、能“指挥”网络脉搏的智能体。“智行一号”的边缘之旅，也将从简单的“连接”，迈向应用与网络深度“协同”的全新境界。

1. UE Location API：“智行一号”的厘米级“网络GPS” (8.6.2)

EAS遇到的第一个难题，就是精确的位置。虽然“智行一号”自带GPS，但在隧道、城市峡谷等场景下，GPS信号并不可靠。而网络，始终知道UE在哪里。

The EES exposes the UE location API to the EAS in order to support tracking or checking the valid location of the UE. The UE location API exposed by the EES relies on the 3GPP core network capabilities as specified in clause 8.10.3.

EES提供的UE Location API，正是将3GPP核心网的LCS（定位服务）能力，封装后提供给EAS使用。它支持两种模式：

1.1 一次性查询 (Request-response model)

这就像向网络发问：“‘智行一号’现在在哪？”。适用于需要即时确认位置的场景。规范原文中的“Figure 8.6.2.2.2-1: UE location API request-response model”描绘了此流程。

流程再现：

  1. EAS发起请求: V2X服务器EAS向EES发送一个“UE location request”。请求中必须包含它想查询的车辆标识（UE ID），并且可以指定期望的位置格式（Location granularity），比如“我需要GPS坐标”，或者“给我它所在的小区ID就行”。
  2. EES查询核心网: EES收到请求后，会向3GPP核心网的定位功能实体（如GMLC/AMF）发起定位请求，获取“智行一号”的最新位置。
  3. EES返回响应: EES将从核心网获取的位置信息，按照EAS要求的格式进行转换，然后返回给EAS。响应中可能还会包含位置信息的时间戳和精度。

1.2 持续追踪 (Subscribe-notify model)

对于自动驾驶这类需要持续监控车辆轨迹的应用，一次次查询效率太低。订阅/通知模式允许EAS向EES提出一个长期需求：“持续追踪‘智行一号’，只要它的位置发生变化，就立即告诉我。”

规范原文中的“Figure 8.6.2.2.3.2-1: UE location API: Subscribe operation”展示了订阅过程。

流程再现：

  1. EAS发起订阅: EAS向EES发送“UE location subscribe request”，请求中包含UE ID以及订阅的有效期、位置上报的触发条件（例如，位置变化超过10米，或者每秒上报一次）。
  2. EES向核心网订阅: EES将EAS的订阅请求，转化为向核心网（NEF）的长期事件订阅。
  3. EES发送通知 (Notify): 一旦核心网检测到“智行一号”的位置满足了上报条件，就会通知EES。EES再将这个位置更新通过“UE location notification”消息推送给EAS。

通过这个API，V2X服务器EAS获得了持续、可靠、高精度的车辆位置信息，其碰撞预测算法的精准度得到了质的飞跃。

2. ACR Management Events：“服务切换”的“预警雷达” (8.6.3)

“智行一号”正以100公里/小时的速度在高速上飞驰，S-EAS的服务范围可能只有几公里，这意味着短短几分钟内就必须完成切换。如何提前预知并准备切换？这就需要ACR管理事件这个“预警雷达”。

The EES exposes ACR management event notifications of one or more UEs to an EAS. … This event supports to detect user plane path change for the application traffic, discover the T-EAS(s), and report the corresponding notification with the discovered T-EAS(s).

EAS可以通过向EES订阅ACR管理事件，让EES和核心网来为它“站岗放哨”。一旦发现需要切换的蛛丝马迹，EES就会立刻向EAS“报警”。

规范定义了多种事件类型，我们来看几个核心的：

  • “User plane path change”: 这是最直接的信号。当核心网（UPF/SMF）检测到UE的用户面路径即将或已经发生改变时（比如，锚定UPF要变了），就会触发此事件。这通常意味着UE已经发生了显著的位置移动。
  • “ACR monitoring”: 更智能的事件。EAS可以告诉EES：“帮我盯着‘智行一号’，一旦你发现它进入了一个新的、有更好EAS的区域，就告诉我那个新EAS是谁。” EES会利用网络能力（如NWDAF的移动性预测）来完成这个任务。
  • “ACR facilitation”: 这是“保姆级”服务。订阅此事件后，EES不仅会帮忙发现T-EAS，还会主动去影响网络路由，提前为AC到T-EAS的数据路径“铺路”，实现更平滑的切换。

流程再现（基于Figure 8.6.3.2.2-1: ACR management event API: Subscribe operation）：

  1. S-EAS发起订阅: “智行一号”连接的V2X服务器S-EAS，向S-EES订阅了针对“智行一号”的“ACR monitoring”事件。
  2. S-EES与核心网交互: S-EES向核心网（NEF/PCF）订阅了“智行一号”的用户面路径变更事件。
  3. 事件发生: “智行一号”即将驶出S-EES的服务区，核心网检测到了路径变更事件，并通知了S-EES。
  4. S-EES处理并通知: S-EES收到通知后，立即执行T-EAS发现流程，找到了目标区域的T-EAS。然后，它向S-EAS发送一个ACR管理事件通知，内容是：“警报！‘智行一号’即将离开，我已经为你找到了接替者T-EAS，它的地址是…，请准备交接！”

有了这个“预警雷达”，S-EAS就能从容不迫地启动ACR流程，提前进行应用上下文的转移，实现“兵马未动，粮草先行”。

3. Session with QoS API：为关键业务申请“VIP通道” (8.6.6)

对于自动驾驶中的“车辆协同编队”等高阶功能，数据传输的任何抖动和延迟都可能是致命的。此时，普通的“尽力而为”网络连接已无法满足要求。EAS需要为这些关键业务申请一条“VIP通道”。

The EES exposes the Session with QoS API to the EAS in order to support the setup of a data session between AC and EAS with a specific QoS and the modification of the QoS of this data session.

这个API将3GPP核心网强大的QoS控制能力（通过PCF实现）开放给了边缘应用。

流程再现（基于Figure 8.6.6.2.2-1: Session with QoS API: create operation）：

  1. EAS发起创建请求: 当“智行一号”车队需要进入“协同编队”模式时，主控车辆连接的EAS向EES发起一个“Session with QoS create request”。请求中明确指出：
    • 为谁申请: “智行一号”的UE ID。
    • 哪条业务流: 通过IP五元组或应用标识符，精确定义需要保障的业务流（如车队协同的心跳信令）。
    • 需要什么保障: 明确的QoS参数，比如5QI（5G QoS Identifier），或具体的GFBR/MFBR（保证/最大流比特率）、时延要求等。
  2. EES与PCF交互: EES将这个应用层请求，“翻译”成核心网的语言，向PCF发起策略授权请求。
  3. 核心网执行QoS保障: PCF进行策略决策，如果允许，它会生成PCC规则下发给SMF，再由SMF配置UPF和gNB，为该业务流建立专用的无线承载和数据流策略，保证其QoS。
  4. EES返回结果: EES将核心网的处理结果返回给EAS，告知“VIP通道已为你开通”。

此外，EAS还可以通过此API更新QoS（比如，退出编队模式时，降低QoS等级）或撤销QoS会话。这个API是实现5G“网络切片”价值在应用层落地的关键一环。

4. 其他关键API：构建完整的协同工具箱

除了上述三大“法宝”，8.6章的“百宝箱”里还有其他几样同样重要的工具。

4.1 AC information exposure API (8.6.4)

AC information exposure enables EASs to obtain information about capabilities of ACs from the EESs.

解读: 这提供了一个反向查询的能力。通常是EEC告诉EES自己的信息，但有时EAS也想了解客户端。比如，一个游戏EAS想知道当前连接的客户端（AC）支持何种画质，以便推送最合适的渲染参数。它就可以通过这个API向EES查询该AC在注册时上报的AC Profile信息。

4.2 UE Identifier API (8.6.5)

EES exposes UE Identifier API to the EAS and EEC in order to provide an identifier uniquely identifying a UE.

解读: 这是一个至关重要的“翻译服务”。EAS在与EES交互时，可能只知道“智行一号”的接入IP地址。但IP地址在移动网络中是可能变化的，且经过NAT后可能不是唯一的。EAS可以通过这个API，用IP地址向EES查询该UE的稳定标识符（如我们之前介绍的隐私保护的Edge UE ID或实名的GPSI）。获取到这个稳定ID后，EAS才能去调用Location API、QoS API等其他与UE强相关的能力。

4.3 Application traffic influence trigger from EAS (8.6.7)

An EAS can explicitly request EES to influence the EAS traffic from UE(s) with necessary information.

解读: 这是比QoS API更进一步的“专家建议”。EAS作为应用方，有时比网络更懂自己的流量模型。比如，一个视频EAS知道它的某条流是交互性极强的信令流，另一条是可缓存的视频数据流。它可以通过这个API向EES（进而影响核心网）建议：“请将我的信令流，通过A路径（某个特定DNAI）转发；将视频流通过B路径转发。” 这让应用得以在更精细的颗粒度上影响网络行为，实现极致的流量优化。

总结

如果说8.5章的“EAS发现”是为“智行一号”找到了服务它的“人”，那么8.6章的“能力开放”就是赋予了这个“人”一套强大的“工具”。通过本章定义的系列API，边缘应用（EAS）被彻底“赋能”，它不再是一个被动的计算资源，而是：

  • 一个拥有**灵敏“触角”**的观察者（通过UE Location API和ACR Events）。
  • 一个可以主动**申请“特权”**的VIP用户（通过Session with QoS API）。
  • 一个能够为网络提供**“专家建议”**的智能顾问（通过Traffic Influence API）。

EES的“百宝箱”彻底打破了应用与网络之间的壁垒，构建了一个信息互通、能力互补、智能协同的全新生态。正是有了这些强大的API，我们对“智行一号”所期待的那些高阶自动驾驶功能——如远程遥控、协同避障、编队行驶——才真正拥有了坚实的技术基础。

FAQ

Q1：EAS为什么不直接使用UE上报的GPS位置，而要大费周章地调用网络的UE Location API？ A1：有几个关键原因：1) 可靠性：在隧道、地下车库、城市高楼峡谷等GPS信号弱或无信号的区域，网络定位（基于小区ID、信号到达时间差等）依然有效，可以作为GPS的补充或替代。2) 功耗: 持续开启GPS对UE（尤其是IoT设备）的电量消耗很大。如果EAS的定位需求不频繁，通过网络按需获取可以节省终端功耗。3) 可信度: 网络侧提供的位置信息经过运营商的管理和验证，对于某些计费或合规性场景，其可信度可能高于终端上报的位置。4) 协同性: EES可以获取多个UE的位置，进行聚合分析，这是单个EAS难以做到的。

Q2：ACR Management Events (8.6.3) 和下一章将要讲的ACR Procedure (8.8) 是什么关系？ A2：它们是“侦察兵”和“主力部队”的关系。8.6.3定义的ACR Management Events是ACR的“侦察”和“预警”阶段。EAS通过订阅这些事件，能够提前检测到可能需要进行ACR的信号。而8.8章定义的ACR Procedure，是接收到“警报”后，真正执行应用上下文重定位的“作战计划”，包括发现目标、迁移数据、切换连接等一系列具体步骤。前者是“发现问题”，后者是“解决问题”。

Q3：Session with QoS API 和 Application traffic influence 有什么区别？ A3：两者都是应用影响网络，但作用的层面和目的不同。

  • Session with QoS API 关注的是服务质量保障。它向网络申请的是一种“承诺”，比如“请保证我这条流的带宽不低于10Mbps，时延不高于5ms”。网络会为此分配资源（如建立专用承载）来兑现这个承诺。它作用于单个数据流的传输属性。
  • Application traffic influence 关注的是路径选择和路由策略。它向网络提供的是一种“建议”，比如“请将我的这条流导向A数据中心的入口（DNAI）”。网络会根据这个建议去选择最优的用户面路径（UPF）。它作用于数据流的转发路径。通常，两者会结合使用，先选择一个最优路径，再在该路径上申请QoS保障。

Q4：为什么需要一个独立的UE Identifier API？EAS在和AC通信时不知道对方的IP地址吗？ A4：知道IP地址，但IP地址在移动网络中有几个问题：1) 不唯一性: 大量UE可能经过运营商的NAT（网络地址转换）后，EAS看到的都是同一个公网IP地址，无法区分。2) 不稳定性: UE每次重建PDU会话，其IP地址都可能改变。3) 隐私问题: 直接使用和存储UE的长期IP地址可能涉及隐私合规风险。UE Identifier API解决了这些问题，它提供了一个“IP地址到稳定、唯一、可控的UE ID”的翻译服务，是EAS调用其他需要精确识别UE的API（如Location, QoS）的必要前提。

Q5：EES开放这么多强大的网络能力给EAS，如何保证安全？一个恶意的EAS会不会滥用这些API攻击网络？ A5：安全是能力开放的生命线。3GPP设计了多重安全机制：

  1. 严格的认证授权: 任何EAS在调用API前，都必须通过CAPIF框架或类似机制进行认证和授权。EES会严格检查该EAS是否有权限调用某个API、以及是否有权限对某个特定的UE执行操作。
  2. 策略控制: 所有的能力开放请求最终都会经过核心网的策略功能（PCF）的校验。PCF会根据用户的签约信息、运营商的策略、网络当前的负载状态来决定是否批准该请求。
  3. 用户同意: 对于涉及用户隐私的API调用（如位置查询），规范要求必须获得用户的明确授权。
  4. 监控与审计: 所有的API调用都会被记录和审计，任何异常行为都会被检测和阻止。

关系图谱