深度解析 3GPP TS 23.558：8.8 Service continuity (Part 1 - 核心理念与架构总览)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8 Service continuity”的第一部分——8.8.1 General (通用原则)的核心章节。在系列的前几篇文章中，我们已经为“智行一号”装备了发现和连接边缘服务的能力。然而，真正的考验现在才开始。当汽车在高速上飞驰，穿梭于一个又一个边缘节点的覆盖范围时，我们如何保证它的“智能大脑”——边缘应用服务——永不掉线？本章，我们将深入探讨边缘计算领域“皇冠上的明珠”：服务连续性。
引言：移动性，边缘计算的“阿喀琉斯之踵”？
“智行一号”正平稳地行驶在智慧高速上，通过连接路旁的V2X服务器（S-EAS），它能够实时感知前方数百米的路况，与其他车辆“心意相通”，做出厘米级的精准决策。这一切，都得益于边缘计算带来的超低时延。
但是，一个严峻的现实摆在眼前：S-EAS的服务范围可能只有几公里。几分钟后，“智行一号”就将驶出其覆盖区。如果此时连接突然中断，然后在新区域重新发起一次完整的“发现-连接”流程，会发生什么？
- 服务中断: 在这几秒甚至更长的中断窗口期，“智行一号”将变回一个“信息孤岛”，失去对超视距危险的感知能力。
- 状态丢失: 即使在新区域快速连接上了新的服务器（T-EAS），T-EAS对“智行一号”也一无所知。它之前积累的所有行驶历史、驾驶意图、环境模型（即应用上下文）都已丢失，一切都需要从零开始。
对于自动驾驶这种关键任务应用，这样的中断是不可接受的。移动性，这个5G最引以为傲的能力，似乎成为了边缘计算稳定服务的最大障碍——它的“阿喀琉斯之踵”。
为了治愈这个“痛点”，3GPP SA6在TS 23.558中倾注了大量心血，设计了一套精妙绝伦的解决方案——服务连续性（Service Continuity），其核心流程被称为应用上下文重定位（ACR, Application Context Relocation）。8.8章，正是这部流程的详细说明书。本文作为ACR系列的第一篇，将首先聚焦于8.8.1节，阐述服务连续性的核心理念、三大核心角色，以及最具前瞻性的“服务连续性规划”思想。
1. ACR的核心使命：一辆永不停歇的“数字搬家车” (8.8.1.1 High level overview)
ACR的使命，简单来说，就是在不影响“住户”（AC）正常生活的前提下，完成一次超快速、无感知的“搬家”。
When a UE moves to a new location, different EASs can be more suitable for serving the ACs in the UE. Such transitions can result from a non-mobility event also, requiring support from the enabling layer to maintain the continuity of the service. This clause describes the features that support service continuity for ACs in the UE to minimize service interruption while replacing the S-EAS, with a T-EAS.
这里的“家”，就是源端服务器S-EAS；“新家”，就是目标服务器T-EAS；而“家具”，就是宝贵的应用上下文（Application Context）。ACR要做的，就是把这些“家具”从S-EAS安全、完整、快速地搬到T-EAS，并让“住户”AC感觉就像只是换了个房间一样流畅。
这个过程可能由UE移动触发，也可能由非移动事件触发（例如S-EAS过载或维护）。为了系统性地完成这次“搬家”，规范将ACR流程抽象为三个逻辑角色和四个主要阶段。
1.1 ACR的三大核心角色：“侦察兵”、“指挥官”与“行动队”
To support the need of ACR, following entity roles are identified:
- detection entity, detecting or predicting the need of ACR;
- decision-making entity, deciding that the ACR is required; and
- execution entity, executing ACR.
ACR不是一个单一的动作，而是一场精心策划的“军事行动”，需要不同角色协同作战：
-
侦察兵 (Detection entity): 负责发现或预测需要ACR的“战机”。谁能扮演这个角色？EEC、EES、EAS都可以。
- EEC侦察：“智行一号”的EEC监测到底层网络位置更新，或GPS显示即将进入新区域，它最先发现需要切换。
- EES侦察：S-EES从核心网收到了“智行一号”用户面路径即将变更的通知，它提前预警。
- EAS侦察：S-EAS通过分析“智行一号”的应用数据（如导航目的地），预测出它即将离开自己的服务区。
-
指挥官 (Decision-making entity): 负责在收到“侦察兵”的情报后，正式下达“执行ACR”的命令。这个角色同样灵活，可以是EEC、EAS或EES，这取决于具体的ACR场景（我们将在后续文章中详细剖析不同场景下的决策者）。
-
行动队 (Execution entity): 负责执行具体的ACR操作，主要是发现T-EAS和转移上下文。
1.2 ACR的四大执行阶段
规范原文中的“Figure 8.8.1.1-1: High level overview of ACR”是理解ACR流程的“总纲”，它将整个“搬家”过程划分为四个阶段：
(NOTE: This is a placeholder for the explanation of Figure 8.8.1.1-1)
对 Figure 8.8.1.1-1 的解读： 这张图描绘了一次ACR行动的标准流程：
- Detect that application context relocation may be required: “侦察兵”发现敌情（需要切换），并将情报（Inform decision making entity）上报给“指挥官”。
- Decide if application context relocation is needed: “指挥官”分析情报，做出决策，下达“执行搬家”的命令（Inform execution entity）。
- Perform application context relocation: “行动队”接到命令，开始执行具体的搬家任务，包括找到新家（发现T-EAS）、打包家具（准备应用上下文）、运输（转移上下文）等。在完成后，需要向所有相关方汇报（Inform all relevant entities）。
- Perform post application context relocation actions: 搬家完成后，进行“打扫战场”工作，例如释放旧家的资源、更新注册信息等。
这个“侦察-决策-执行-善后”的闭环流程，为所有复杂的ACR场景提供了一个统一的、可遵循的行动框架。
2. 运筹帷幄：决胜千里之外的服务连续性规划 (8.8.1.2 ACR with service continuity planning)
如果说标准的ACR是在“智行一号”即将撞墙时才猛打方向盘，那么“服务连续性规划”则是在出发前就已经规划好了全程的每一个转弯。这是一种前瞻性、预测性的ACR，是实现极致用户体验的关键。
Service continuity planning is an Edge Enabler Layer value-add feature of providing support for seamless service continuity, when information about planned, projected, or anticipated behaviour is available at EESs or provided by EECs.
“智行一号”的旅程升级： “智行一号”在出发前，已经将完整的导航路线输入给了车载系统。它的EEC不仅仅知道现在的位置，更知道未来5分钟、10分钟后将到达哪里。
EEC可以将这个“预知未来”的能力，分享给边缘网络。
核心机制：应用上下文的复制与同步
In service continuity planning, the Application Context may be duplicated and sent from the S-EAS to the T-EAS before the UE moves to the expected location. In this case, the Application Contexts in S-EAS and T-EAS are synchronized when the Application Context is updated until the AC connects to the T-EAS.
这正是“规划”的精髓所在。
- 提前“备房”: 当“智行一号”还在A路口时，S-EES根据EEC提供的预测路线，就已经为它在B路口找到了T-EAS，并完成了T-EAS的准备工作。
- 提前“搬运”: S-EAS将“智行一号”当前的应用上下文复制一份，提前发送给了T-EAS。此时，A、B两个路口的服务器，都拥有了“智行一号”的“用户档案”。
- 状态“同步”: 在“智行一号”从A驶向B的过程中，它仍然与S-EAS通信。但S-EAS上应用上下文的任何变化，都会被实时同步给T-EAS。这就像你在旧电脑上工作，所有修改都通过云盘实时同步到了新电脑上。
- 无感“切换”: 当“智行一号”真正到达B路口时，它需要做的，仅仅是将网络连接从S-EAS切换到T-EAS。由于T-EAS早已拥有了最新的、完全同步的应用上下文，AC可以瞬间恢复工作，没有任何状态丢失和业务中断。
这种“规划式”ACR，将切换带来的冲击降到了最低，是实现自动驾驶、云游戏等超低时延移动业务的关键技术。
3. 意外处理：应对计划赶不上变化的复杂现实
现实世界的道路总是充满意外。“智行一号”的旅程也不会总是一帆风顺。规范同样为这些“意外”设计了处理预案。
3.1 预判失误：被“放鸽子”的T-EAS (8.8.1.3 Unused contexts handling)
“智行一号”原计划在下一个路口右转，边缘网络已经为它在右转后的区域准备好了T-EAS，并迁移了上下文。但它却临时决定直行了。那么，那个被“放鸽子”的T-EAS怎么办？
The interval between ACT initiation and ACR status update message from EAS to EES (i.e. taking the context into use) can be significant (e.g. in the predicted case). During this interval, the following events are possible: a) The UE remains communicating with the S-EAS… b) The UE moves to a service area served by a different T-EAS…
规范要求，对于这些被创建但最终未被使用的“闲置上下文”，必须有清理机制。通常会通过超时机制来处理。如果T-EAS在预定的时间窗口内没有等到“智行一号”的连接，它就会自动清除为其准备的上下文，释放资源。同时，相关方（如EEC和S-EES）需要有机制能取消或更新之前的ACR请求，避免造成混乱。
3.2 计划延迟：堵在路上的“智行一号” (8.8.1.4 Modification of ACR parameters)
“智行一号”的路线没变，但路上遇到了交通拥堵，到达B路口的时间从原定的5分钟后，延迟到了15分钟后。
During an ACR for service continuity planning, the circumstances can change which results in the changes in the parameters related to ACR. In such cases modification of the ACR will be required. For example, the EEC or EES can monitor the UE’s mobility and obtain updates in the predicted location or other ACR parameters e.g. prediction expiration time.
此时，无需取消整个ACR。规范提供了ACR参数修改流程。EEC或EES可以向相关方（特别是T-EAS）发送一个更新通知，将预测到达时间等参数进行修改。T-EAS收到后，就会延长其上下文的等待超时时间。这种“微调”机制，使得服务连续性规划能更好地适应现实世界的不确定性。
4. 边界扩展：云、边协同与服务捆绑 (8.8.1.5 & 8.8.1.6)
4.1 边云协同：驶出边缘覆盖区
当“智行一号”驶出城市，进入没有边缘覆盖的乡村地带时，服务不能就此中断。
Service continuity between CAS and EAS can be supported… ACR scenarios between CAS and EAS are described in clause 8.8.2A and clause 8.8.2B.
规范的ACR架构原生支持边-云协同。此时，T-EAS的角色将由中心云的**CAS（Cloud Application Server）**来扮演。应用上下文将从最后一个边缘节点，无缝迁移到中心云。虽然时延会增加，但保证了业务的连续性。当车辆再次驶入另一个城市的边缘覆盖区时，又可以从云端无缝切换回边缘。
4.2 服务捆绑：复杂应用的“集体搬家”
“智行一号”的AR导航应用，同时依赖于地图EAS、渲染EAS和V2X EAS。这三个EAS组成了一个“EAS bundle”。在ACR时，它们必须“同进同退”。
This clause describes solution of relocating EASs in a bundle together instead of individual relocation for AC-EAS sessions one by one. … a main EAS may be used and a main EES is used correspondingly.
规范为此引入了**主EAS（main EAS）和主EES（main EES）**的概念。由这个“主”实体，来统一协调和触发整个“捆绑包”的ACR流程，确保所有相关的EAS实例能够作为一个整体，被同步地迁移和切换。
总结
8.8章的开篇，为我们揭示了3GPP为解决移动性这一边缘计算核心挑战所设计的顶层思想。它远不止是一个简单的“切换”协议，而是一套智能、前瞻、且富有弹性的服务保障体系。
- 通过角色化（侦察兵、指挥官、行动队）和阶段化，它为复杂的ACR流程建立了清晰的逻辑框架。
- 通过引入服务连续性规划，它将ACR从被动的“事后补救”提升到了主动的“事前预判”，实现了对用户体验的极致追求。
- 通过设计异常处理机制，它保证了系统在面对现实世界不确定性时的鲁棒性。
- 通过支持边云协同和服务捆绑，它将ACR的应用场景从单一服务、纯边缘环境，扩展到了更广阔、更复杂的异构世界。
掌握了这些核心理念，我们就拥有了解读后续具体ACR场景的“钥匙”。在下一篇文章中，我们将用这把钥匙，打开第一个具体的ACR场景大门，详细剖析“由EEC发起，通过S-EES执行的ACR流程”，看一看信令的交互和参数的传递，是如何将这些精妙的思想，转化为真实的代码逻辑。
FAQ
Q1：ACR（应用上下文重定位）和ACT（应用上下文转移）到底是什么关系？ A1：ACR是一个过程，ACT是这个过程中的一个动作。ACR（Application Context Relocation）是端到端的服务连续性流程，它包括了检测、决策、发现目标、执行转移、清理资源等所有步骤。而ACT（Application Context Transfer）特指其中将应用上下文数据从源EAS（S-EAS）发送到目标EAS（T-EAS）的这一个具体动作。可以说，ACT是ACR最核心的组成部分，但ACR包含了比ACT更广泛的内涵。
Q2：服务连续性规划听起来对UE的电量消耗会更大，因为它需要与网络进行更多交互（如上报预测路径、同步上下文等），规范是如何考虑这个平衡的？ A2：这是一个非常实际的工程权衡。规范本身提供了机制，但如何使用则取决于策略。
- 按需开启: 并非所有应用都需要开启服务连续性规划。只有那些对中断极其敏感的应用（如自动驾驶、云游戏）才会在其AC Profile中声明需要此功能。
- 智能触发: EEC和EES可以智能地决定何时上报预测。比如，只在进入高速巡航状态时才上报长途路线，在市内走走停停时则不开启。
- 增量同步: 在上下文同步阶段，可以采用增量同步技术，只同步发生变化的数据，而不是每次都全量复制，以减少网络开销。 最终，这是一个由应用特性、用户体验要求和终端能力共同决定的策略选择。
Q3：ACR流程中，谁来决定最终选择哪个T-EAS？ A3：决策权是分布式的，取决于具体的ACR场景。
- EEC发起的ACR: 最终选择权在EEC。EES可能会推荐多个候选T-EAS，由EEC根据更实时的网络状况等信息做出最终选择。
- 网络侧发起的ACR (EAS/EES发起): 决策权主要在网络侧。例如，S-EES在发现需要切换后，它会负责完成T-EAS的发现和选择，然后将结果（选定的T-EAS）通知给EEC。 这种灵活的决策机制，适应了不同场景下信息不对称的情况。
Q4：应用上下文（Application Context）具体包含什么内容？是由3GPP定义的吗？ A4：应用上下文的具体内容不由3GPP定义，它完全由**应用自身（AC和EAS）**来决定。3GPP边缘使能层只负责提供一个透明的“容器”和“搬运工具”，但从不关心“容器”里装的是什么。
- 对于“智行一号”的V2X应用，上下文可能是车辆传感器数据、轨迹预测模型。
- 对于云游戏，上下文可能是用户的游戏存档、当前场景的渲染状态。
- 对于视频通话，上下文可能是通话状态、编解码器参数。 这种设计实现了业务逻辑与使能层的完美解耦。
Q5：为什么处理“未使用上下文”如此重要？直接让它超时不就行了吗？ A5：处理未使用上下文不仅仅是资源回收的问题，更是逻辑一致性和用户体验的问题。
- 逻辑一致性: 如果EEC决定取消对T-EAS-1的ACR，并转向了T-EAS-2，它必须有一种机制能明确告知S-EES和T-EAS-1“之前的计划作废了”，否则S-EES可能会继续向一个错误的目标同步上下文，造成状态混乱。
- 快速响应: 通过主动的取消流程（如重发ACR请求并指明是取消），可以立即释放T-EAS-1的预留资源，并让S-EES马上开始为新的目标T-EAS-2做准备，而不是傻等一个漫长的超时，这对于需要快速连续切换的场景至关重要。