深度解析 3GPP TS 23.558：8.8.4 Information flows (ACR的“作战指令”：情报元素的终极解密)
本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.8.4 Information flows”的核心章节。在之前的系列中，我们已经学习了ACR的各种“战略剧本”。现在，我们将戴上“显微镜”，深入剖析这些战略背后的具体“作战指令”——信息流与信息元素（IEs），揭示ACR流程中每一次通信的精确内涵。
引言：从“作战计划”到“电报原文”
在过去的几篇文章中，我们如同在沙盘上推演战局，跟随“智行一号”演练了多种ACR（应用上下文重定位）的作战计划。我们知道了由谁（EEC/S-EAS/S-EES）来制定计划，以及在不同敌情下（边到边/边到云/服务捆绑）该采用何种战略。
然而，真正的战争，是由一封封精确无误的电报指令来驱动的。当指挥部下达“发起总攻”的命令时，电报上必须清晰地写明：哪个部队、何时、向何地、以何种方式发起攻击。
8.8.4章“Information flows”（信息流），正是ACR这本“战术手册”中，对这些“电报原文”的终极解密。它不再描述“做什么”，而是精确定义了“说什么”。本章将之前所有流程中涉及的消息（如ACR请求、ACR响应），拆解为其最基本的组成部分——信息元素（Information Elements, IEs），并详细规定了每个IE的含义、格式和可选性。
对于“智行一号”的系统工程师来说，本章是他们将ACR流程从“PPT”转化为“代码”的直接依据。让我们化身为一名密码破译员，逐一解读这些ACR“作战指令”的核心情报。
1. ACR的“超级指令”：ACR Request (8.8.4.4)
在所有信息流中，ACR request无疑是最核心、最复杂、最关键的一个。它如同一份“万能作战指令表”，通过不同参数的组合，可以下达ACR启动、ACR决策请求、ACR修改等多种命令。
Table 8.8.4.4-1 describes information elements for the ACR request sent either from the EEC to the S-EES or T-EES, or by the S-EAS to the S-EES. In the EAS bundle case, the ACR request is sent by the main S-EES to its associated S-EES(s).
为了彻底搞懂这张庞大的“指令表”，我们不能走马观花。我们将把它分解为几个关键的“作战模块”，并结合“智行一号”的场景来理解每个模块的作用。
Table 8.8.4.4-1: ACR request (模块化深度解读)
1.1 模块一：基础身份信息 (From, To, Subject)
这是任何一份指令都必须具备的抬头，明确了“谁”在对“谁”下达关于“谁”的指令。
| Information element | Status | Description |
|---|---|---|
| Requestor Identifier | M | Identifier of the requestor (i.e. EECID or EASID). |
| Security credentials | M | Security credentials resulting from a successful authorization… |
| UE identifier | M | The identifier of the UE (i.e. GPSI). |
| ACID (NOTE 10) | O | The identifier of the AC. |
| > EASID | O | Identifier of the EAS |
场景解读:
- 当EEC发起请求时，
Requestor Identifier就是它的EECID。 - 请求中必须携带合法的安全凭证，证明自己有权下达指令。
UE identifier（“智行一号”的GPSI）和ACID（AR导航应用）明确了本次ACR行动是针对哪辆车的哪个应用。
1.2 模块二：核心行动指令 (The Command)
这是指令的“动词”，定义了本次请求的根本目的。
| Information element | Status | Description |
|---|---|---|
| ACR action (NOTE 3) | M | Indicates the ACR action (ACR initiation, ACR determination or ACR modification) |
| ACR initiation data (NOTE 2) | O | ACR initiation IEs to be included in an ACR request message when ACR action indicates it is ACR initiation request. |
| ACR determination data (NOTE 2) | O | ACR determination IEs to be included… |
| ACR modification data (NOTE 2) | O | ACR modification IEs to be included… |
场景解读:
- ACR initiation (启动): 当EEC或S-EES已经做出决策，需要立即执行ACR时，action就是
initiation。此时，请求中必须附带一个“作战计划包”——ACR initiation data。 - ACR determination (决策请求): 当侦察兵（如EEC）发现了情况，但需要指挥官（如S-EES）来做决策时，action就是
determination。此时，请求中附带的是“敌情报告”——ACR determination data。 - ACR modification (修改): 当需要更新一个已启动的ACR计划时（如“智行一号”堵车了），action就是
modification。
1.3 模块三：“作战计划包” - ACR initiation data
这是ACR action为initiation时携带的核心参数，详细描述了“如何打”。
T-EAS Endpoint (M): Endpoint information (e.g. URI, FQDN, IP 3-tuple) of the T-EAS. Previous T-EAS Endpoint (NOTE 7) (O): Endpoint information … of the T-EAS of the previous ACR. Simultaneous EAS connectivity information (O): Indicates if simultaneous EAS connectivity is needed and the inactive time guidance… EAS notification indication (M): Indicates whether to notify the EAS about the need of ACR. EEC context relocation details (O): Information required for EEC context relocation using the EEC context push or EEC context pull mechanisms.
场景解读:
T-EAS Endpoint: 明确告知执行方，我们的攻击目标是哪个T-EAS。EAS notification indication: 指示执行方（EES），“务必通知我方阵地S-EAS，让它准备交接！”Simultaneous EAS connectivity information: 这是一个高级战术指令。如果携带此信息，意味着请求一种“先建后断（Make-Before-Break）”的切换模式。网络将尝试为“智行一号”同时建立到S-EAS和T-EAS的连接，确保在数据流完全切换到T-EAS之前，旧的连接始终保持，实现零丢包。EEC context relocation details: 这是“档案转移”的具体指令，包含了S-EES的地址和EEC Context ID，指示T-EES去哪里、用什么凭证来拉取档案（对应8.8.2.6场景）。Previous T-EAS Endpoint: 这是一个“撤销”指令。如果EEC之前发起了一个到T-EAS-1的ACR，但现在决定取消并转向T-EAS-2，它会在新的ACR请求中带上这个参数，告知网络“放弃之前的目标T-EAS-1”。
1.4 模块四：“集团军”协同指令
这个模块用于指挥EAS bundle的整体“换防”。
| Information element | Status | Description |
|---|---|---|
| EAS bundle information (NOTE 12) | O | EAS bundle information. |
| > Bundle ID (NOTE 12) | O | Bundle ID as described in clause 7.2.10. |
| > List of EASIDs | O | A list of the EASIDs of the EASs in the bundle. |
场景解读:
当“智行一号”的AR导航系统（一个EAS bundle）需要整体切换时，ACR请求中会包含这个EAS bundle information，明确告知S-EES：“本次行动的目标，不是单个士兵，而是整个集团军！” S-EES据此便会启动我们之前学习的8.8.2.7-9的协同流程。
1.5 重绘完整的“作战指令表”
以下是规范中Table 8.8.4.4-1的完整Markdown重绘，它将上述所有模块组合在了一起。
Table 8.8.4.4-1: ACR request
| Information element | Status | Description |
|---|---|---|
| Requestor Identifier | M | Identifier of the requestor (i.e. EECID or EASID). |
| Security credentials | M | Security credentials resulting from a successful authorization for the edge computing service. |
| EASID | O | Identifier of the EAS |
| EAS bundle information (NOTE 12) | O | EAS bundle information. |
| > Bundle ID (NOTE 12) | O | Bundle ID as described in clause 7.2.10. |
| > List of EASIDs | O | A list of the EASIDs of the EASs in the bundle. |
| UE identifier | M | The identifier of the UE (i.e. GPSI). |
| Predicted/Expected UE location or Expected AC Geographical Service Area (NOTE 8) | O | The predicted/expected location information of the UE. |
| ACID (NOTE 10) | O | The identifier of the AC. |
| > EASID | O | Identifier of the EAS |
| > EAS endpoint | M | Endpoint information of the T-EAS |
| ACR action (NOTE 3) | M | Indicates the ACR action (ACR initiation, ACR determination or ACR modification) |
| ACR initiation data (NOTE 2) | O | ACR initiation IEs to be included in an ACR request message when ACR action indicates it is ACR initiation request. |
| > T-EAS Endpoint | M | Endpoint information (e.g. URI, FQDN, IP 3-tuple) of the T-EAS. In case of ACR to cloud, Endpoint information is of CAS. |
| > Previous T-EAS Endpoint (NOTE 7) | O | Endpoint information of the T-EAS of the previous ACR. |
| > DNAI of the T-EAS | O | DNAI information associated with the T-EAS. |
| > N6 Traffic Routing requirements | O | The N6 traffic routing information and/or routing profile ID corresponding to the T-EAS DNAI. |
| > Simultaneous EAS connectivity information | O | Indicates if simultaneous EAS connectivity is needed and the inactive time guidance for keeping connectivity towards the S-EAS. |
| > EAS notification indication | M | Indicates whether to notify the EAS about the need of ACR. |
| > Previous EAS notification indication (NOTE 7) | O | Indicates whether to notify the EAS about the cancellation of a previous ACR. |
| > S-EAS endpoint (NOTE 1) | O | Endpoint information of the S-EAS |
| > Bundled T-EAS endpoint list (NOTE 11) | O | A list of associated EAS endpoints in a EAS bundle. |
| > ACR parameters (NOTE 9) | O | Parameters of the ACR |
| >> Prediction expiration time | O | The estimated time the UE may reach the Predicted/Expected UE location or EAS service area at the latest |
| > EEC context relocation details | O | Information required for EEC context relocation using the EEC context push or EEC context pull mechanisms. |
| >> EEC Context ID (NOTE 5) | O | Identifier of the EEC Context |
| >> S-EES ID (NOTE 5) | O | Identifier of the EES that provided EEC context ID. |
| >> S-EES endpoint (NOTE 5) | O | The endpoint address (e.g. URI, IP address) of the EES that provided EEC context ID. |
| >> T-EES ID (NOTE 6) | O | Identifier of the T-EES. |
| >> T-EES endpoint (NOTE 6) | O | The endpoint address (e.g. URI, IP address) of the T-EES. |
| ACR determination data (NOTE 2) | O | ACR determination IEs to be included in an ACR request message when ACR action indicates it is ACR determination request. |
| > S-EAS endpoint | M | Endpoint information of the S-EAS |
| ACR modification data (NOTE 2) | O | ACR modification IEs to be included in an ACR request message when ACR action indicates it is ACR modification request. |
| > S-EAS Endpoint | M | Endpoint information of the S-EAS. |
| > T-EAS Endpoint | M | Endpoint information of the T-EAS. |
| > ACR parameters | M | ACR parameters |
| >> Prediction expiration time | O | The estimated time the UE may reach the Predicted/Expected UE location or EAS service area at the latest |
2. 简单的“回执”：ACR Response (8.8.4.5)
与复杂的请求相比，ACR的响应则非常简单，它只是一份确认“收到”或“拒绝”的“回执”。
Table 8.8.4.5-1: ACR response
| Information element | Status | Description |
|---|---|---|
| Successful response (NOTE) | O | Indicates that the ACR request was successful. |
| Failure response (NOTE) | O | Indicates that the ACR request failed. |
| > Cause | O | Indicates the cause of ACR request failure |
场景解读: 当EEC或S-EAS向EES发起了ACR请求后，EES会立即返回一个ACR响应。
- 如果成功: EES会返回
Successful response，这并不代表ACR已经完成，而仅仅表示“你的指令我已收到，并且格式正确、权限合法，我已开始处理。” - 如果失败: EES会返回
Failure response，并附上明确的Cause（原因），例如“安全验证失败”、“参数缺失”、“你请求的目标不存在”等。
这个即时响应机制，确保了请求方能够第一时间知道自己的指令是否被执行方所接受。
3. 其他情报电文 (8.8.4.6 - 8.8.4.27)
8.8.4章还定义了ACR战场管理中其他各种“电报”的格式，我们在此简要概览，其详细字段在规范中有具体表格，原理与ACR Request类似。
- Retrieve EES request/response: S-EES向ECS“问路”的电文格式。
- ACR information subscription request/response/notification: EEC与EES之间建立和使用“战情专线”的电文格式。
- EELManagedACR service request/response: EAS向EES签署“全权委托协议”的电文格式。
- Selected target EAS declaration request/response: S-EAS向S-EES“备案”的电文格式。
- ACR status update request/response: EAS向EES“汇报战果”的电文格式。
- ACT status subscription/notification: T-EAS向T-EES订阅和接收“上下文就绪”通知的电文格式。
- ACR parameter information request/response: S-EES向T-EES/T-EAS更新“作战计划”的电文格式。
这些标准化的信息流，共同确保了在复杂的ACR流程中，每一个实体之间的每一次通信，都有据可依、有章可循。
总结：信息流——ACR流程的血液
8.8.4章“Information flows”是ACR流程的“血液”。它将之前章节中定义的抽象概念和宏观流程，物化为一行行具体的、可编码、可传输的信息元素。
- 统一与复用: 核心的
ACR request消息，通过ACR action参数，巧妙地复用了一套数据结构来承载多种不同的业务意图，展现了高超的设计技巧。 - 精确与完备: 每一个IE的设计，都精确地对应了ACR流程中的一个特定需求，从身份、安全，到目标、源头，再到上下文、捆绑包，几乎涵盖了所有可能遇到的场景。
- 流程的基石: 没有这些标准化的信息流，ACR的各个流程就如同空中楼阁，无法落地。开发者正是依据这些表格，来构建和解析消息，从而实现不同厂商、不同运营商设备之间的互联互通。
掌握了这些“电报原文”的解读方法，我们对ACR的理解，已经深入到了其最底层的“神经末梢”。
FAQ
Q1：ACR request中的S-EAS endpoint和T-EAS endpoint是如何获取的？
A1：
S-EAS endpoint: 对于EEC来说，这是它当前正在连接的EAS，地址是已知的。对于S-EES来说，S-EAS是向它注册的，地址也是已知的。T-EAS endpoint: 这是通过EAS发现流程获取的。在ACR的准备阶段，无论是EEC、S-EAS还是S-EES，都会执行一次针对目标区域的EAS发现，从而获得T-EAS的地址信息。
Q2：ACR modification和重发一次ACR initiation有什么区别？
A2：ACR modification是对一个已存在ACR会话的更新，它更轻量。执行方（如EES）只需要在原有ACR流程的基础上，更新部分参数。而重发一次ACR initiation则意味着取消旧的ACR，启动一个全新的ACR，这通常涉及到更重的资源操作。使用modification可以更高效地处理计划的动态调整。
Q3：NOTE 12提到EAS bundle information中Bundle ID和List of EASIDs至少要出现一个，它们有什么区别？
A3：两者描述“集团军”的方式不同。
Bundle ID: 更抽象，它是一个“套餐名称”。当EEC或S-EAS只知道套餐名时，它们会使用Bundle ID。EES收到后，需要自己去查询这个套餐具体包含哪些EAS。List of EASIDs: 更具体，它直接列出了“集团军”的所有“部队番号”。当请求方已经明确知道bundle包含的所有EAS成员时，可以直接使用这个列表。Bundle ID更常用，因为它对请求方更简单。
Q4：为什么在ACR request中，UE identifier是M（强制），而ACID是O（可选）？
A4：因为ACR的核心主体是UE的移动性。网络侧必须知道这次ACR是为哪个UE服务的，以便进行定位、策略查询等网络层面的操作。而ACID标识的是UE上的具体应用，在某些场景下，网络侧可能不需要知道。例如，如果一个ACR请求只是为了迁移EEC上下文，而暂时不涉及具体的EAS，那么ACID就可以省略。但在绝大多数需要迁移应用上下文的场景中，ACID是必不可少的。
Q5：Table 8.8.4.19-1: ACR status update request中有一个ACT result字段，而Table 8.8.4.20-1: ACR status update response中却没有，这是为什么？
A5：这是一个很好的观察。
- ACR status update request: 这是EAS向EES的“战果汇报”，核心内容就是汇报ACT（应用上下文转移）的结果是成功还是失败，所以
ACT result是这个消息的核心载荷。 - ACR status update response: 这是EES对EAS汇报的**“回执”**。它只表示“你的汇报我收到了”，而不对ACT的结果本身做出评论。EES在收到汇报后，会自己记录ACT的状态，并根据这个状态去执行后续流程（如通知EEC）。因此，它的响应中只需要包含“成功收到”或“失败收到”（例如，格式错误）的信息，而无需再重复ACT的结果。