深度解析 3GPP TS 23.558：8.5 EAS discovery (边缘世界的“大众点评”与“高德地图”)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.5 EAS discovery”的核心章节。这是边缘计算实现其价值最关键的环节。在“智行一号”完成了服务开通和注册之后，它将如何从星罗棋布的边缘节点中，找到那个能满足其严苛需求的“天选之子”？本章将为您揭晓答案。
引言：从“办好入住”到“寻找餐厅”
在上一章中，我们跟随“智行一号”在区域服务中心（EES）成功“办理了入住”，通过注册流程，EES已经为它建立了一份详尽的客户档案（EEC Context）。至此，“智行一号”已经不再是边缘世界中的一个匿名游客，而是一位手持“房卡”（EEC Context ID）的尊贵会员。
然而，入住酒店只是开始。真正的旅程，是从走出酒店大门，去探索这个城市的美食开始的。此刻，“智行一号”的自动驾驶应用（AC）发出了一个明确的需求：“前方即将进入一个拥有‘人车混行’的复杂路口，我需要连接一个边缘服务器，它必须能提供实时视频流分析与碰撞预测服务，并且处理时延不能超过5毫秒！”
这个过程，就是EAS发现（EAS Discovery）。它如同边缘世界的“大众点评”与“高德地图”的结合体。EEC需要根据AC提出的精细化“美食需求”（服务要求），向酒店前台（EES）这位“本地通”进行咨询，EES则需要从它管理的成百上千家“餐厅”（EAS）中，筛选出评分最高、距离最近、口味最匹配的那一家，并给出清晰的导航路线（连接信息）。
8.5章，正是为这套复杂的“搜索-匹配-推荐”流程，制定了无懈可击的规则。
1. 发现的动因：何时需要寻找EAS？ (8.5.1 General)
在启动搜索之前，我们先要明白，是什么事件触发了“智行一号”的“觅食”欲望。
EAS discovery may be initiated by the EEC when a certain trigger condition at the UE is met. Some examples are as follows:
- AC related updates available at the EEC (e.g. due to AC installation/re-installation/activation), AC requesting application server access;
- Lifetime received via EAS discovery response specified in clause 8.5.3 is expired; or
- EEC detects the need of application context relocation as in clause 8.8.
规范指出了几种典型的触发条件：
- 应用需求触发: 这是最常见的场景。
- 车主新安装了一个需要边缘加速的“云游戏”应用（AC installation）。
- “智行一号”的自动驾驶应用（AC）启动，并请求连接后台服务（AC requesting application server access）。
- 缓存信息过期触发: EEC为了效率，会将上次发现的EAS信息缓存起来。但这份信息是有“保质期”的（Lifetime）。当缓存过期后，EEC必须重新发起一次发现，以获取最新的服务信息，防止连接到一个已经下线的EAS。
- 移动性触发: 这是服务连续性的前奏。当EEC检测到“智行一号”即将驶出当前S-EAS的服务范围时，它需要为下一个区域提前发现一个可用的T-EAS，为即将到来的切换做准备。这个发现流程，是ACR（应用上下文重定位）过程的一部分。
2. 发现的模式：一次性查询 vs. 持续关注 (8.5.2 Procedures)
针对不同的业务需求，规范设计了两种截然不同的发现模式。
2.1 请求/响应模式 (Request-response model - 8.5.2.2)
这是最基础的模式，就像在“大众点评”上进行一次性的搜索。
The EEC sends an EAS discovery request to the EES. … Upon receiving the request from the EEC, the EES checks if the EEC is authorized to discover the requested EAS(s). … If the processing of the request was successful, the EES sends an EAS discovery response to the EEC…
规范原文中的“Figure 8.5.2.2-1: EAS Discovery procedure”描绘了这个流程：
- EEC发送发现请求: “智行一号”的EEC向EES发起一个“EAS发现请求”。
- EES鉴权与处理: EES验证EEC的身份，并根据请求中的“发现过滤器”在自己的EAS数据库中进行搜索匹配。
- EES返回发现响应: EES将找到的一个或多个EAS的信息返回给EEC。
这个模式适用于“智行一号”到达一个新地点，需要立即找到当前可用服务的场景。
2.2 订阅/通知模式 (Subscribe-notify model - 8.5.2.3)
这是一种更高级、更智能的模式，相当于在“大众点评”上“关注”了某个菜系或商圈的动态。
This subscription enables EES to inform EEC of various EAS discovery related events of interest to EEC (e.g. EAS discovery notification and EAS dynamic information).
“智行一号”的旅程： “智行一号”正行驶在一条长达50公里的高速公路上。它不希望每隔几公里就发起一次“请求/响应”来查询，这太低效了。于是，它的EEC选择了订阅/通知模式：
- 订阅 (Subscribe): EEC向EES发起一个“EAS发现订阅请求”。请求中说：“我将在未来一小时内沿G1高速行驶，请持续为我关注V2X服务。如果有新的、更优的V2X服务器上线，或者我当前连接的服务器状态发生变化，请主动通知我。”
- 通知 (Notify): EES收到订阅后，便开始为“智行一号”充当“情报员”。当“智行一号”行驶到K50公里处时，EES发现那里有一个新开通的、性能更强的EAS，它会立刻向EEC发送一个“EAS发现通知”，将这个新机会告知“智行一号”。
- 更新与取消: EEC可以随时更新它的订阅条件（比如路线改变），也可以在驶出高速后取消订阅。
这个模式变“被动拉取”为“主动推送”，极大地降低了信令开销，并提升了系统对网络动态变化的响应速度，对于长途、高速移动的场景尤为重要。
3. 信息流的艺术：如何精准描述你的“需求” (8.5.3 Information flows)
流程的顺畅执行，依赖于信息流的精确定义。8.5.3节详细定义了发现请求和响应中每一个参数的含义，这是本章的精髓所在。
3.1 发现请求：EAS discovery request
Table 8.5.3.2-1: EAS discovery request 定义了EEC如何向EES描述它的需求。
| Information element | Status | Description |
|---|---|---|
| Requestor identifier | M | The ID of the requestor (e.g. EECID) |
| Security credentials | M | Security credentials… |
| EAS discovery filters | O | Set of characteristics to determine required EASs, as detailed in Table 8.5.3.2-2. |
| UE location | O | The location information of the UE. |
| EEC Service Continuity Support | O | Indicates if the EEC supports service continuity or not… |
| EAS selection request indicator | O | Indicates the request for EAS selection support from the EES… |
最核心的参数无疑是 EAS discovery filters。它是一套复杂的过滤器，让EEC可以像使用SQL查询一样，向EES提出极其精细的查找条件。我们来深入剖析定义这些过滤器的 Table 8.5.3.2-2: EAS discovery filters。
深度解读 Table 8.5.3.2-2: EAS discovery filters
这张表是EEC的“许愿清单”，它允许从两个维度来描述需求：“我（AC）需要什么” 或 “我想要的EAS长什么样”。
-
从“我需要什么”出发 (
List of AC characteristics):> AC profile: 这是最重要的部分，包含了AC的KPI需求，如连接带宽、时延（Response time）、可用性等。EEC会告诉EES：“我的这个AC是个‘急性子’，响应时间必须在5ms以内！”> Application group profile: 如果是车队出行，EEC会带上这个ID，告诉EES：“请为我们车队里的所有成员找同一个EAS！”
-
从“EAS长什么样”出发 (
List of EAS characteristics):> EASID: 最直接的过滤，指明要找哪个“品牌”的EAS。> EAS type / schedule / Service feature(s): 按类别、营业时间、特殊功能（如是否支持多人游戏）来筛选。> EAS Geographical Service Area / Topological Service Area: 空间过滤。EEC可以指定一个地理范围（比如一个多边形区域）或网络范围（一组小区ID），要求EAS必须能覆盖这个范围。> Service continuity support: 能力过滤。EEC可以要求：“我需要一个支持无缝切换的EAS！”
通过这些过滤器的灵活组合，“智行一号”可以向EES提出类似这样的复杂请求：“请为我的导航应用（AC Profile），在即将经过的‘人民路’路口（Geographical Service Area），寻找一个支持服务连续性（Service continuity support）的V2X服务（EASID），并且它的服务提供商最好是A公司（EAS provider identifier）。”
3.2 发现响应：EAS discovery response
Table 8.5.3.3-1: EAS discovery response 定义了EES返回的“搜索结果页”。
| Information element | Status | Description |
|---|---|---|
| Successful response | O | … |
| > Discovered EAS list | O | List of discovered EAS(s). Each element includes… |
| >> EAS profile | M | Profile of the EAS. Each element is described in clause 8.2.4 |
| >> EES Endpoint | O | The endpoint address … of the EES. |
| >> Lifetime | O | Time interval or duration during which the information… is valid… |
| > Instantiable EAS Information | O | The EAS instantiation status per EASID (e.g. instantiated, instantiable but not instantiated yet, instantiation in progress). |
| >> Instantiation criteria (NOTE 2) | O | The criteria upon which EAS can be instantiated… |
| Failure response | O | … |
核心字段深度解读:
- Discovered EAS list: 这是返回的匹配结果列表。对于每一个匹配的EAS，都会附上其完整的
EAS profile（简历）和Lifetime（信息有效期）。 - EES Endpoint: 一个有趣的细节是，如果EES-A发现“智行一号”要找的EAS实际上注册在隔壁的EES-B那里，它会在结果中附上EES-B的地址，告诉EEC“你应该去问他”。
- Instantiable EAS Information: 这是最能体现边缘计算动态性的一个字段！如果EES没有找到正在运行的EAS，但发现有一个“可以被动态创建”的EAS模板满足需求，它就会在这里告诉EEC：“现在没有现货，但可以为你‘现做一个’（
instantiable but not instantiated yet），预计需要30秒（Instantiation criteria）。” EEC收到后，就可以决定是等待这个新实例被创建，还是寻找其他替代方案。这背后，就是EES触发上层MEC-O（边缘编排系统）进行动态应用实例化的流程。
4. 统一的API：Eees_EASDiscovery (8.5.4 APIs)
和“服务开通”一样，规范将本章所有复杂的流程都统一封装在一个API中，如 Table 8.5.4.1-1: Eees_EASDiscovery API 所示。
| API Name | API Operations | Operation Semantics | Consumer(s) |
|---|---|---|---|
| Eees_EASDiscovery | Request | Request/Response | EEC |
| Subscribe | Subscribe/Notify | EEC | |
| … |
对于开发者来说，无论是进行一次性搜索，还是发起长期订阅，都只是调用Eees_EASDiscovery这同一个API的不同操作而已，极大地简化了客户端的编程模型。
总结
8.5章“EAS发现”是边缘使能层（EEL）对外体现其核心价值的关键窗口。它不仅仅是一个简单的“查找”功能，而是一个智能的、上下文感知的、动态的服务匹配与推荐引擎。
- 它通过丰富的发现过滤器，让客户端能够以多维度、极其精细化的方式描述自己的需求。
- 它通过两种发现模式（请求/响应与订阅/通知），同时满足了应用的即时性需求和移动场景下的前瞻性需求。
- 它通过支持动态实例化，实现了边缘资源的按需分配和弹性伸缩，将云计算的灵活性带到了网络边缘。
完成了EAS发现，“智行一号”已经与路口的V2X服务器成功“牵手”。然而，挑战才刚刚开始。当它高速驶向下一个路口时，一场关系到驾驶安全的服务连续性“保卫战”即将打响。在后续文章中，我们将深入探讨8.8章，揭示ACR（应用上下文重定位）这一边缘世界“皇冠上的明珠”的奥秘。
FAQ
Q1：EES返回多个匹配的EAS时，由谁来做最终选择？是EEC还是AC？ A1：规范将最终的选择权赋予了客户端，即EEC。EES负责“海选”和“精选”，提供一个候选列表。而EEC作为最了解自身实时状态（如无线信号质量、CPU负载）和AC具体偏好（可能AC Profile中都未完全描述）的实体，来进行最后的“定选”。它可能会选择列表中网络延迟最低的那个，或者根据AC的指示选择某个特定版本的EAS。
Q2：EAS发现请求中的“UE location”是强制的吗？如果不提供会怎么样？ A2：它是可选的（Optional）。
- 如果提供: EES可以进行非常精准的地理位置匹配，这是大部分场景下的推荐做法。
- 如果不提供: EES仍然可以进行匹配，但只能依赖其他过滤器，比如AC Profile或EASID。它可能会返回所有注册在它这里的、满足条件的EAS，而不管它们在地理上是否适合当前的UE。在某些对位置不敏感的应用场景（例如，访问一个逻辑上在边缘但服务范围覆盖全城的内容缓存），或者出于用户隐私考虑不想暴露精确位置时，可以选择不提供。
Q3：EAS Instantiation Triggering Suppress这个参数有什么用？为什么客户端会不希望EES触发实例化？
A3：这是一个控制EES行为的“开关”。在某些情况下，客户端可能不希望等待一个新实例的创建。例如：
- 时延敏感: “智行一号”的碰撞预警应用，需要毫秒级的响应。它无法接受等待几十秒甚至几分钟来启动一个新EAS实例。此时，它可以在发现请求中设置这个标志，告诉EES：“我只要现货，如果没有就算了，不要费时间去创建。”
- 客户端策略: 客户端可能有自己的备用策略。比如，发现边缘没有可用EAS后，它会立即切换回中心云的CAS，而不是等待边缘实例化。 这个参数给了客户端更大的控制权。
Q4：订阅/通知模式中，如果EEC订阅了事件，但之后发生了网络中断，它会丢失中断期间的通知吗？ A4：这取决于具体的实现和订阅的事件类型。通常，EES会为每个订阅维护一个状态。当EEC重新上线并再次与EES联系时（例如通过重新注册或更新订阅），EES可以检测到这个客户端“失联”过。对于一些重要的状态变更通知（比如EAS永久下线），EES可能会在EEC重连后，将“积压”的重要通知重新发送给它。但这并不是所有通知类型的保证行为。
Q5：整个EAS发现流程对用户来说是透明的吗？
A5：是的，对最终用户（驾驶员）是完全透明的。对于**应用开发者（AC的开发者）**来说，在很大程度上也是透明的。理想情况下，开发者只需调用EEC提供的一个简单的API，如 findEdgeService(service_type)，然后就能得到一个可用的服务地址。所有与EES的复杂交互、过滤器的构建、结果的选择等，都由EEC这个“代理”在后台完成了。这正是边缘使能层的核心价值——简化。