深度解析 3GPP TS 23.558：8.4 Registration (注册流程)

本文技术原理深度参考了3GPP TS 23.558 V18.10.0 (2025-03) Release 18规范中，关于“8.4 Registration”的核心章节。在上一篇文章中，我们剖析了“智行一号”启动后如何通过服务开通流程获取到第一份“边缘地图”，明确了应该去哪个区域服务中心（EES）办理业务。本文将紧随其后，详细拆解“智行一号”到达EES大门后的第一个关键动作——注册。

引言：从“游客”到“会员”，建立信任的第一步

手握从ECS（边缘配置服务器）获取的EES地址，“智行一号”的EEC（边缘使能客户端）模块不再是无头苍蝇。它已经定位到了离它最近、最匹配其需求的“区域服务中心”——我们称之为S-EES（Source EES）。

然而，仅仅知道地址是不够的。对于一个提供关键任务服务的系统（如自动驾驶），信任和身份是第一位的。S-EES不能对任何一个发来请求的设备都敞开大门。因此，在正式开始“消费”边缘服务之前，EEC必须先进行“注册”，从一个匿名的“游客”转变为一个有身份、受管理的“会员”。

8.4章“Registration”（注册）正是为这个过程制定了详细的法律条文。它不仅仅是一个简单的登录动作，更是一个生命周期管理和上下文创建的开始。通过注册，EES能够建立起对EEC的认知，为其创建档案（EEC Context），并为后续的服务发现、能力开放和无缝切换奠定基础。

本章内容将分为三个核心部分，分别阐述生态系统中的“三方会谈”：

1. EEC向EES注册：“智行一号”如何向服务中心亮明身份。
2. EAS向EES注册：服务中心里的各个“商铺”如何向中心“报备营业”。
3. EES向ECS注册：服务中心如何向“城市规划局”登记备案。

让我们一步步揭开这三场关键“注册仪式”的神秘面纱。

---

1. 注册的本质：为何需要多方注册？ (8.4.1 General)

在深入具体流程之前，我们需要理解规范设计这套多方注册机制的根本目的。

Registration procedures allow entities in the edge deployment to deliver information to other entities. The following registrations are supported:

• EEC registration with EES;
• EAS registration with EES; and
• EES registration with ECS.

这段话清晰地指出了注册的三种类型。这三种注册共同构建了一个层级化的信息发现和信任链：

• EEC向EES注册，是为了让EES认识并管理客户端。没有这个过程，EES就无法知道“智行一号”的存在，无法为其提供个性化服务，更无法在它移动时为其保障服务连续性。

• EAS向EES注册，是为了让EES发现并管理服务端。没有这个过程，EES就是一个“空壳”经理，手下没有任何可供调度的“员工”（EAS），也就无法响应来自EEC的任何服务发现请求。

• EES向ECS注册，是为了让ECS发现并管理EES。没有这个过程，ECS的“地图”就是空白的，它无法为任何新来的EEC（如刚刚启动的“智行一号”）指明方向。

这套层层递进的注册体系，确保了整个边缘生态系统的信息能够自下而上地汇聚和被感知，从而使得自上而下的服务发现和配置下发成为可能。

---

2. EEC Registration：“智行一号”的“酒店入住”流程 (8.4.2)

这是本章最核心、最复杂的注册流程。“智行一号”的EEC向EES发起的注册，就像一个旅客拿着预订单（ECS返回的配置）来到酒店前台（EES）办理入住。

2.1 注册的目的与方式 (8.4.2.1 General & 8.4.2.2 Procedures)

An EEC performs registration with an EES in order to provide information that can be used by the EES in Edge Computing services. The procedure also enables initialization, update and removal of the EEC context information at the EES.

注册的核心目的，就是在EES侧初始化、更新和移除EEC上下文。这个上下文是EES为“智行一号”建立的专属档案，记录了它的一切。

规范定义了四种相关流程：

• EEC registration (注册): 首次“办理入住”。
• EEC registration update (注册更新): “续房”或更新住宿要求。
• EEC de-registration (去注册): 主动“退房”。
• EEC Context relocation procedure (上下文重定位): “换酒店”时的档案转移。

2.1.1 首次注册 (EEC registration - 8.4.2.2.2)

规范原文中的“Figure 8.4.2.2.2-1: EEC registration procedure”描绘了这一过程。

“智行一号”的旅程：

1. 发送注册请求: “智行一号”的EEC向目标EES发送一个“EEC注册请求”。这个请求携带了它的“身份证”和“需求清单”。
2. EES验证与处理: EES收到请求后，首先进行严格的安全验证，确认EEC的合法性。然后，它会检查EEC提交的“需求清单”（即AC Profile），评估自己是否有足够的资源（如匹配的EAS、算力等）来满足这些需求。
3. （可选）上下文拉取: 如果“智行一号”是从另一个酒店（S-EES）转过来的，它的注册请求中会携带前一个酒店的地址和它的“旧房卡号”（EEC Context ID）。此时，当前的酒店（T-EES）会执行一个“EEC Context Pull”操作，主动向前台（S-EES）拉取“智行一号”的完整客户档案。
4. 发送注册响应: 一切处理完毕后，EES向EEC返回一个“注册响应”。如果成功，响应中会包含本次注册的ID和EES为它分配的新“房卡号”（EEC Context ID）。

2.1.2 注册更新与去注册 (Update & De-registration)

• 注册更新: 注册通常是有有效期的。在“房卡”过期前，“智行一号”的EEC需要发送一个更新请求来“续房”。此外，如果车主新安装了一个应用，EEC也需要通过更新请求，将新的AC Profile告知EES。
• 去注册: 当“智行一号”准备长时间关机时，EEC会主动发送去注册请求，通知EES可以清理它的档案，释放资源。这是一个优雅的“退房”流程。如果EEC异常掉线，EES也会在注册超时后，将其隐式地去注册。

2.2 注册信息流详解 (8.4.2.3 Information flows)

流程的背后是精确的数据交换。我们来深度解读注册请求和响应中携带的关键信息。

2.2.1 请求消息：EEC registration request

Table 8.4.2.3.2-1: EEC registration request 是EEC递交给EES的“入住登记表”。

Information element	Status	Description
EECID	M	Unique identifier of the EEC.
UE Identifier	O	The identifier of the hosting UE (i.e., GPSI)
Security credentials	M	Security credentials resulting from a successful authorization…
AC Profile(s)	O	Profiles of ACs for which the EEC provides edge enabling services…
EEC Service Continuity Support	O	Indicates if the EEC supports service continuity or not…
EEC context ID (NOTE)	O	Identifier of the EEC context obtained from a previous registration.
Source EESID (NOTE)	O	Identifier of the EES that provided EEC context ID.
Source EES Endpoint (NOTE)	O	The endpoint address … of the EES that provided EEC context ID.
UE Mobility Support Requirement	O	Indicates UE requires mobility support or not

核心字段深度解读:

• AC Profile(s): 这是EES进行资源评估的核心依据。EEC会告诉EES：“我车上有个‘AR导航’应用，它需要小于10ms的时延和50Mbps的带宽。”EES会检查自己手下有没有EAS能满足这个苛刻的KPI。
• EEC context ID / Source EESID / Source EES Endpoint: 这“三件套”是实现服务连续性的关键！当“智行一号”从S-EES移动到T-EES时，它向T-EES发起的注册请求就会携带这三项信息。这等于告诉T-EES：“我是老客户，我之前的档案在S-EES那里，档案号是EEC context ID，请你去取一下。” 这就触发了T-EES向S-EES的上下文拉取流程。
• UE Mobility Support Requirement: 这个标志位允许EEC告知EES，自己是一个高速移动的终端，对移动性支持有特殊要求。EES收到后，可能会为其激活更灵敏的位置追踪或更积极的ACR预测机制。

2.2.2 响应消息：EEC registration response

Table 8.4.2.3.3-1: EEC registration response 是EES返回给EEC的“入住凭证”。

Information element	Status	Description
Successful response	O	…
> Registration ID	M	Identifier of the EEC registration.
> Expiration time (NOTE)	O	Indicates the expiration time of the registration.
> EEC context ID	O	Identifier of the EEC Context information available at the EES…
> EEC Context Relocation status	O	Indicates whether the EEC context retrieval from the S-EES was successful or not.
> Discovered EAS list	O	List of EASs discovered to provide the capabilities required by the AC Profiles.
> list of unfulfilled AC information	O	List of ACIDs of the AC Profile(s) for which the requirements … cannot be fulfilled
Failure response	O	…

核心字段深度解读:

• EEC context ID: 这是本次注册后，EES为EEC分配的新的“会话ID”或“房卡号”。EEC必须妥善保管，在后续与该EES的交互（如发起EAS发现）以及未来向下一个EES迁移时，都需要用到它。
• EEC Context Relocation status: 如果本次注册涉及到了上下文迁移，EES会在这里明确告知迁移是否成功。这对EEC决定后续行为至关重要。
• Discovered EAS list: 这是一个非常实用的优化机制。如果EEC在注册时就提交了AC Profile，EES在完成注册的同时，可以“顺手”把匹配的EAS信息直接返回给EEC。这就像办理酒店入住时，前台直接给了你一张周边热门餐馆的优惠券，省去了你再去大众点评搜索的步骤，将“注册”和“发现”两个流程合二为一，提升了效率。
• list of unfulfilled AC information: 如果EES无法满足EEC提交的所有AC Profile需求，它会在这里明确告知：“你那个‘超高清VR’应用的需求我满足不了，因为我这里没有支持的EAS”。这为EEC和AC提供了明确的反馈。

---

3. EAS & EES Registration：服务商们的“工商登记” (8.4.3 & 8.4.4)

一个完整的生态，不仅需要客户端的注册，更需要服务端的主动登记。

3.1 EAS向EES注册 (8.4.3 EAS Registration)

一个V2X应用服务器（EAS）被部署在路口并启动后，它的第一个动作，就是向其管理者EES进行注册。

The EAS Registration procedure allows an EAS to provide its information to an EES in order to enable its discovery.

核心信息流： EAS发送的注册请求（Table 8.4.3.3.2-1）中，最核心的信息是EAS Profile。这份Profile是EAS的“简历”，详细描述了：

• 我是谁（EASID）
• 我的联系方式（EAS Endpoint）
• 我属于哪个服务套餐（EAS bundle information）
• 我的服务范围是多大（EAS Geographical/Topological Service Area）
• 我的营业时间（EAS Schedule）
• 我的性能承诺（EAS Service KPIs）
• 我是否支持服务连续性（EAS Service continuity support）

EES收到并验证后，会将这份“简历”存入自己的数据库，等待着“智行一号”这样的客户端前来“招聘”。

3.2 EES向ECS注册 (8.4.4 EES Registration)

同理，一个EES节点被新建并激活后，也需要向更上层的ECS进行注册。

The EES Registration procedure allows an EES to provide information to an ECS in order to enable provisioning EES(s) to an EEC.

核心信息流： EES发送的注册请求（Table 8.4.4.3.2-1）中，核心信息是EES Profile。这份Profile是EES向“城市规划局”提交的“区域中心简介”，主要描述了：

• 我是谁（EESID）
• 我的联系方式（EES Endpoint）
• 我负责哪个数据网络（EDN information）
• 我的服务范围内主要提供哪些类型的应用服务（EASIDs）
• 我是否支持服务连续性（EES Service continuity support）

ECS将这些信息汇总，形成一张覆盖全网的“边缘服务资源总图”，从而可以在“智行一号”发起服务开通请求时，为其提供最精准的引导。

---

总结

8.4章“注册”为我们揭示了边缘世界中信任链和信息链的构建过程。它通过三个层次的注册流程，将原本孤立的EEC、EAS、EES、ECS实体，紧密地联系在一起，形成了一个有序、可管理、信息可追溯的系统。

• 对于“智行一号”（EEC）：注册是它从“匿名”走向“实名”的关键一步，是建立EEC上下文、享受个性化和连续性服务的前提。
• 对于服务（EAS/EES）：注册是它们“宣告存在”、使其能力可被发现的唯一途径。
• 对于整个系统：这套层级化的注册机制，是实现大规模、广域边缘计算资源管理和调度的基石。

完成了注册，“智行一号”已经成功“入住”了边缘服务的“酒店”，并且前台（EES）也对它的需求了如指掌。接下来，它将开始真正精彩的边缘探索之旅——EAS发现。

FAQ

Q1：EEC注册为什么会有一个“Expiration time”（过期时间）？一直有效不行吗？ A1：设置过期时间是一种重要的健壮性（Robustness）机制。在移动网络中，UE可能会因为没电、信号丢失、故障等原因突然下线，而无法发送“去注册”消息。如果没有过期时间，EES中会积累大量永远不会再上线的“僵尸”上下文，耗尽服务器资源。通过设置过期时间，EES可以定期清理那些没有按时“续房”（发送注册更新请求）的EEC上下文，保证系统的健康运转。

Q2：在EEC注册响应中，为什么“Discovered EAS list”是可选的？ A2：这是为了提供灵活性。

• 提供: 如果EEC在注册时就明确给出了AC Profile，EES“顺便”完成发现并返回结果，可以减少一次后续的往返交互，提升效率，适用于对启动速度要求高的应用。
• 不提供: 在某些场景下，注册和发现可能是两个独立的逻辑步骤。比如，EEC可能想先完成注册，建立好与EES的连接，然后再根据AC的实时触发，发起多次不同的EAS发现请求。将两者分开，可以增加流程的灵活性。

Q3：如果一个EAS不向EES注册，会发生什么？ A3：如果一个EAS“特立独行”，不向EES注册，那么从TS 23.558定义的边缘使能层的角度来看，这个EAS就不存在。任何通过标准流程（EEC → EES → EAS Discovery）的客户端都将无法发现它。它就像一个没有进行工商登记的“黑店”，虽然物理上存在，但在官方的商业黄页上是找不到的。因此，注册是EAS被纳入边缘生态、对外提供服务的前提。

Q4：EES向ECS注册时，为什么需要上报它支持的EASID列表？ A4：这是为了实现在ECS层面的粗粒度过滤。一个运营商可能有成百上千个EES，有的专为视频业务优化，有的专为车联网业务优化。当“智行一号”（其AC Profile明确需要V2X服务）向ECS请求服务开通时，ECS可以直接查看每个EES上报的所支持的EASID列表，迅速过滤掉那些完全不提供V2X服务的EES，只将真正相关的EES地址返回给EEC。这大大提升了服务开通过程的精准度和效率。

Q5：整个8.4章看下来，感觉有很多“请求-响应”对，这些交互的安全性是如何保证的？ A5：非常好的问题！所有这些注册请求和响应的安全性都由TS 23.558的“兄弟”规范——TS 33.558 (Security aspects) 来保障。简单来说，在发起任何请求之前，通信双方必须先通过一系列的安全程序（通常基于TLS和O-Auth 2.0等框架）建立一个安全的信道，并完成身份认证和授权。请求消息中的“Security credentials”字段就是用于携带这些认证和授权信息的。这确保了只有合法的实体才能发起注册，并且注册信息在传输过程中是加密的，不会被窃听或篡改。