51学通信

深度解析 3GPP TS 23.558：8.8.3 Service Continuity Procedures (Part 1 - ACR的“开战三部曲”)

17分钟阅读

深度解析 3GPP TS 23.558：8.8.3 Service Continuity Procedures (Part 1 - ACR的“开战三部曲”)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.3 Procedures”中服务连续性核心流程的前半部分。在之前的系列文章中，我们已经全面学习了ACR的各种“战术剧本”——由EEC、S-EAS、S-EES等不同角色主导的场景。我们知道了“谁”可以发起和指挥这场“换防战役”。现在，我们将深入“军事学院的战术手册”，学习打赢这场战役所必须掌握的、标准化的“单兵作战技能”和“小队协同战术”。

引言：从“战略”到“战术”，解构ACR的DNA

我们已经跟随“智行一号”见证了多种ACR（应用上下文重定位）的宏伟战略：无论是EEC的“自主突击”，还是S-EAS/S-EES的“远程指挥”，亦或是复杂的“集团军协同”和“边云战略转移”。这些都是高层面的“作战计划”。

然而，任何宏伟的作战计划，最终都需要分解为一系列标准、可执行的战术动作。士兵需要知道如何索敌、如何联络、如何发起冲锋。8.8.3章“Procedures”，正是ACR流程的“标准作业程序（SOP）手册”。它将之前各个场景中反复出现的动作，如“发现目标”、“请求支援”、“发起总攻”，抽象出来，定义为一个个独立的、可复用的标准流程。

理解了这些基础流程，就等于掌握了ACR的“DNA”。我们才能真正看懂，在那些复杂的场景图中，每一个箭头背后，到底发生了怎样精确的信令交互。

本文作为8.8.3章的第一部分，将聚焦于ACR打响前的“开战三部曲”——三个最核心的准备与启动流程。我们将再次扮演“智行一号”的作战参谋，看一看当切换决策下达后，我方（无论是EEC还是网络侧）是如何一步步完成“索敌”、“联络”和“宣战”的。

1. 战术动作一：Discover T-EAS (发现目标EAS) - 精准的“战场侦察” (8.8.3.2)

这是所有网络侧主导或协调的ACR流程的第一步。当S-EAS或S-EES决定需要切换时，它必须先知道“往哪里切”。“Discover T-EAS”流程，就是由S-EAS或S-EES发起的，用于发现目标T-EAS的“战场侦察”行动。

Figure 8.8.3.2-1 illustrates the procedure for fetching T-EAS information. This procedure may be utilized by a S-EAS, which undertakes the transfer of application context information to a T-EAS directly, or can be invoked by the S-EES itself on deciding to execute ACR.

规范原文中的“Figure 8.8.3.2-1: Discover T-EAS”描绘了这次侦察行动的详细步骤。

Figure 8.8.3.2-1: Discover T-EAS

(NOTE: This is a placeholder for the explanation of Figure 8.8.3.2-1)

“智行一号”的场景再现： 假设S-EES（作为“总指挥”）检测到“智行一号”即将进入金融街区域，它决定为“智行一号”寻找一个新的V2X服务器。

  1. S-EES发起内部侦察 (Step 1b): S-EES作为决策者，启动了T-EAS发现流程。
  2. S-EES检查本地情报 (Step 2): S-EES首先会检查自己的“情报库”（本地缓存或注册列表），看看是否已经有关于金融街区域T-EAS的信息。
  3. S-EES请求“总部”支援 (Step 2 → Step 3): 如果本地没有情报，S-EES就需要向它的上级——ECS——请求支援。这一步，它将调用我们接下来要讲的Retrieve T-EES流程。
  4. T-EES执行“抵近侦察” (Step 3 → Step 4): S-EES从ECS那里获得了金融街区域T-EES的联系方式后，它会向T-EES发起一次EAS发现请求。这个请求的内容与我们在8.5章学习的EEC发起的发现请求非常类似，包含了AC Profile、预测位置等信息。T-EES收到后，会在自己的管辖范围内，为“智行一号”寻找最匹配的T-EAS。
  5. 情报汇总与返回 (Step 4 → Step 5): T-EES将侦察结果（T-EAS信息）返回给S-EES。如果最初的发起者是S-EAS，S-EES还会将最终结果转发给S-EAS。

核心要点：

  • 这是一个嵌套流程，它内部调用了Retrieve T-EES（如果需要）和EAS Discovery（在T-EES上执行）两个子流程。
  • 它的发起者是S-EAS或S-EES，是网络内部的行为。
  • 它的核心目的是为一次ACR找到一个或多个候选的T-EAS。

2. 战术动作二：Retrieve T-EES (检索目标EES) - 寻找“新战区的联络官” (8.8.3.3)

这个流程是“Discover T-EAS”的关键一环，它回答了“当我不知道目标区域的负责人（T-EES）是谁时，我该问谁？”的问题。答案是：问“总指挥部”——ECS。

Figure 8.8.3.3-1 illustrates the procedure for the S-EES to retrieve the T-EES information from the ECS. This procedure is also applicable for the CES to retrieve the T-EES information.

规范原文中的“Figure 8.8.3.3-1: Retrieve T-EES procedure”描绘了S-EES向ECS“问路”的过程。

Figure 8.8.3.3-1: Retrieve T-EES procedure

(NOTE: This is a placeholder for the explanation of Figure 8.8.3.3-1)

“智行一号”的场景再现： S-EES接到为“智行一号”寻找金融街V2X服务的任务后，发现自己并不管理金融街区域，也不知道那里的EES是谁。

  1. S-EES发送请求 (Step 1): S-EES向其配置的ECS发送一个“Retrieve EES request”。请求中包含了关键的“寻人启事”：
    • 目标位置: “智行一号”即将到达的金融街区域的地理坐标。
    • 目标业务: 需要EASID为“V2X-Service-01”的服务。
    • 客户信息: “智行一号”的UE ID、AC Profile等。
  2. ECS处理请求 (Step 2): ECS作为“城市规划局”，查阅它的“全城资源地图”。它根据位置和业务类型，找到了负责金融街区域的T-EES-B。
  3. ECS返回响应 (Step 3): ECS向S-EES返回T-EES-B的详细信息，包括其地址（Endpoint）、它所管理的EDN的网络参数（DNN/S-NSSAI）等。

核心要点：

  • 这是一个基础查询服务，由ECS提供。
  • 它的调用者通常是S-EES（在边到边切换中）或CES（在云到边切换中）。
  • 它的核心目的是根据位置和业务，找到对应的T-EES。

3. 战术动作三：ACR Launching Procedure (ACR启动流程) - 吹响“总攻的号角” (8.8.3.4)

“侦察”和“联络”都已完成，目标T-EAS也已锁定。现在，必须有一个明确的、标准化的动作，来正式宣告ACR流程的启动。这就是“ACR启动流程”的使命。

Figure 8.8.3.4-1 illustrates the ACR launching procedure by the EEC or the S-EAS or the S-EES. If this procedure is triggered by the EEC, depending on the ACR action indicated in the ACR request, the procedure is used for ACR initiation, ACR determination or ACR modification…

这个流程是决策者向执行协调者下达命令的“官方渠道”。

规范原文中的“Figure 8.8.3.4-1: ACR launching procedure”展示了这个“下命令”的过程。

Figure 8.8.3.4-1: ACR launching procedure

(NOTE: This is a placeholder for the explanation of Figure 8.8.3.4-1)

谁向谁下命令？

  • EEC → S-EES: 在8.8.2.3场景中，EEC决定后，向S-EES发起此流程，命令S-EES开始协调。
  • EEC → T-EES: 在8.8.2.6场景中，EEC决定后，绕过S-EES，直接向T-EES发起此流程，命令T-EES开始协调。
  • S-EAS → S-EES: 在8.8.2.4场景中，S-EAS决定后，向S-EES发起此流程，请求S-EES批准并协调。
  • Detection Entity → S-EES: 在8.8.2.5场景中，侦测到事件的EEC或S-EAS，向S-EES发起此流程，请求S-EES做出决策。

请求中最重要的参数：ACR action ACR启动请求的核心，在于ACR action这个参数，它定义了本次请求的“意图”。

  • An ACR request for ACR initiation sent by the EEC…
  • An ACR request for ACR determination sent either by the EEC or the EAS…
  • An ACR request for ACR modification sent by the EEC…
  • ACR initiation (ACR启动): 这是最强烈的命令。通常由EEC在已经自己选定T-EAS后发出，意为：“目标已锁定，立即执行！” 请求中会包含T-EAS的详细信息。
  • ACR determination (ACR决策请求): 这是一个“提请”的动作。通常由侦测到事件但无权决策的实体（如8.8.2.5中的EEC或S-EAS）向决策者（S-EES）发出，意为：“我发现情况，请您定夺！”
  • ACR modification (ACR修改): 用于对一个已经启动的ACR流程的参数进行修改，例如，“智行一号”因为堵车，预测到达时间需要推迟。

“总攻号角”吹响之后： 当执行协调者（如S-EES）收到一个ACR initiation请求后，它便会立即启动一系列的后续动作，如：

  • 通知S-EAS: 向S-EAS发送“ACT start”通知，命令其准备转移上下文。
  • 执行EEC Context Push: 将EEC上下文推送到T-EES。
  • 影响网络路由: 向核心网申请调整流量路径。

总结：“三部曲”如何支撑起宏伟的ACR战略

“Discover T-EAS”、“Retrieve T-EES”、“ACR Launching”，这三个标准化的战术动作，共同构成了ACR流程启动阶段的“三部曲”。它们就像齿轮一样，环环相扣，将之前各个宏观场景中的战略意图，转化为具体、可执行的信令交互。

  1. S-EAS/S-EES通过Discover T-EAS进行“战场侦察”，锁定目标。
  2. Discover T-EAS内部，通过Retrieve T-EES向“总部”ECS请求“联络官”信息。
  3. 决策者（EEC/S-EAS/S-EES）通过ACR Launching吹响“总攻号角”，正式启动整个作战流程。

掌握了这“开战三部曲”，我们才算真正从“纸上谈兵”的战略家，迈向了能够理解一线战场信令细节的“战地指挥官”。在下一篇文章中，我们将继续深入8.8.3章，学习在“战斗”打响后，如何进行“战况监控”、“情报更新”和“战果确认”等一系列的流程管理战术。

FAQ

Q1：为什么需要把“Discover T-EAS”和“Retrieve T-EES”拆分为两个独立的流程？ A1：这是为了实现逻辑的解耦和复用。

  • Retrieve T-EES是一个非常基础和通用的查询服务，它的功能很纯粹：根据位置和业务，找到对应的EES。
  • Discover T-EAS则是一个更复杂和上层的业务流程。它不仅需要找到T-EES，还需要与T-EES交互，进行更精细的EAS匹配，并考虑负载、KPI等更多因素。 将两者分开，使得S-EES在其他场景下（不仅仅是ACR），如果只需要查询T-EES信息，也可以直接调用Retrieve T-EES这个基础服务。这种模块化的设计，是优秀架构的共同特点。

Q2：在Discover T-EAS流程中，如果S-EES的本地缓存里已经有了T-EES的信息，它还会去联系ECS吗？ A2：通常不会。这正是缓存的意义所在。如果S-EES的缓存中有关于目标区域T-EES的、且仍在有效期内的信息，它会直接使用该信息，跳过向ECS查询的步骤（即跳过Retrieve T-EES流程），直接进入到与T-EES交互的阶段。这大大减少了信令交互，缩短了ACR的准备时间。

Q3：ACR Launching请求中的ACR action参数，是如何决定ACR场景的？ A3：ACR action参数是区分不同ACR模式的关键。

  • 如果EEC发出的请求中ACR action是initiation，并且目标是S-EES，这就对应了8.8.2.3场景。如果目标是T-EES，则对应8.8.2.6场景。
  • 如果EEC或S-EAS发出的请求中ACR action是determination，并且目标是S-EES，这就对应了8.8.2.5（S-EES主导）场景的触发阶段。
  • 如果EEC发出的请求中ACR action是modification，这就对应了8.8.1.4中定义的ACR参数修改流程。 通过这个小小的参数，EES就能够准确地理解请求者的意图，并启动正确的内部处理逻辑。

Q4：为什么ACR launching procedure的发起方可以是EEC、S-EAS或S-EES？这不会造成混乱吗？ A4：不会。因为在任何一个具体的ACR场景中，谁是决策者，谁就是ACR启动的发起者，这是唯一确定的。

  • 在EEC主导的场景，只有EEC会发起initiation请求。
  • 在S-EAS主导的场景，只有S-EAS会发起determination请求（请求S-EES决策并执行）。
  • 在S-EES主导的场景，S-EES自己就是决策者，它会在内部“发起”这个流程，即进入后续的执行步骤。 所以，虽然这个流程的“输入端”有多个，但在一个确定的ACR剧本中，指挥链是清晰的，不会发生混乱。

Q5：如果Discover T-EAS流程最终失败了（例如，ECS和T-EES都找不到任何匹配的EAS），ACR会怎么样？ A5：如果“战场侦察”失败，那么“总攻”就不会被打响。Discover T-EAS流程会向上游调用者（S-EAS或S-EES）返回一个失败的响应。

  • 如果S-EAS/S-EES是决策者，它就会终止这次ACR，并可能启动备用方案（如切换到CAS）。
  • 如果S-EES只是协调者（如8.8.2.3场景），它会向EEC报告发现失败。EEC收到后，也可以决定是放弃切换，还是尝试切换到CAS。 总之，Discover T-EAS的成功，是后续所有ACR执行动作的前提。

关系图谱