51学通信

深度解析 3GPP TS 23.335：Annex A.2 更新流程实例 (CS位置更新 & IMS业务变更)

20分钟阅读

深度解析 3GPP TS 23.335：Annex A.2 更新流程实例 (CS位置更新 & IMS业务变更)

本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“Annex A (informative): Information flows”中的 A.2 章节，旨在通过两个核心通信场景——CS域位置更新和IMS业务数据变更，实战化地展示UDC架构下的数据更新（Update）流程。

在上一篇解析中，我们通过CS被叫和IMS注册两个实例，深入剖析了UDC架构下最核心的“查询”操作。我们看到，无状态的前端（FE）如何通过向UDR（用户数据存储库）“拉取”数据来驱动业务逻辑。然而，网络不仅需要读取信息，更需要动态地写入和修改信息。当用户的位置发生变化，或者当用户主动更改业务设置时，网络必须能够实时、准确地更新UDR中的数据。

今天，我们将继续我们的旅程，聚焦于附录A的第二部分，探索数据“更新”流程在真实世界中的应用。我们将再次跟随用户张伟的脚步，见证他的每一次移动和每一次业务选择，是如何在UDC后台转化为一次次精准的数据更新操作。

1. 更新流程的通用范式 (A.2.1 General)

规范在A.2.1章节为我们点明了更新流程的通用原则，为后续的实例分析奠定了基础。

When user data (temporary or permanent) has to be modified, the application front-end shall perform an update procedure towards the UDR.

这句话的核心思想是：任何时候，当一个FE（无论是处理核心网络逻辑的HLR-FE/HSS-FE，还是处理应用逻辑的AS-FE）需要修改UDR中的任何数据时，它都必须通过Ud接口执行一个标准化的更新流程。

The following flows show an example of a location update in CS network and an example of a service data update in an IMS network. These scenarios do not address the mechanisms for access authorisation in the UDR. These scenarios only address the specific actions of traffic events that are currently in effect.

与查询实例类似，更新实例也将聚焦于两个经典场景，并暂时忽略UDR内部复杂的权限校验细节，以便我们能将全部注意力集中在业务触发下的核心信令交互上。

2. 动感地带：CS位置更新流程中的Ud更新 (A.2.2)

场景设定：我们的主角张伟正在跨市出差的高铁上。随着列车高速行进，他的手机不断地从一个VLR（拜访位置寄存器）的服务区移动到另一个VLR的服务区。为了保证通信的连续性（例如，能随时接听电话），网络必须实时跟踪他的位置。每一次跨VLR的移动，都会触发一次CS域的位置更新流程。

在UDC架构下，HLR的逻辑由HLR-FE承载。让我们跟随规范中的“Figure A.2.2-1: CS location update with Ud Update from HLR-FE”，详细拆解这次位置更新的全过程。

2.1 更新前的“两步舞”：查询先行

一个常见的误解是，更新流程就是简单地向UDR写入新数据。但规范的实例告诉我们，一次严谨的更新，往往始于一次查询。

步骤 1: 新VLR发起位置更新请求 (UPDATE LOCATION)

  1. The VLR initiates MAP Update Location message towards HLR.

当张伟的手机进入一个新的VLR覆盖区，这个新VLR会向张伟的归属HLR（即一个HLR-FE）发送一条MAP Update Location消息，通报自己的地址，请求更新用户位置。

步骤 2 & 3: HLR-FE向UDR查询当前状态 (Fetch subscriber data)

  1. Upon reception of UL, the application specific front-end (HLR-FE) fetches all the user data it needs to perform its application logic (e.g. barrings, VLR number, etc.) from the UDR through a Ud query procedure.
  2. After applying the proper access control…, the UDR responds with the user data requested.

HLR-FE收到请求后，并没有立即去更新数据。相反，它首先执行了一次Ud查询。这是一个至关重要的“读-改-写”（Read-Modify-Write）模式的开端。HLR-FE需要知道张伟的当前状态才能做出正确的处理，例如：

  • 业务限制 (barrings)：张伟是否被禁止漫游？如果禁止，位置更新应被拒绝。
  • 旧的VLR地址 (VLR number)：HLR-FE需要知道用户之前在哪个VLR，以便后续通知旧VLR删除用户信息。
  • 其他签约数据：需要下发给新VLR的用户签约信息。

UDR在鉴权后，将这些数据返回给HLR-FE。现在，HLR-FE才掌握了执行位置更新所需的全部上下文。

2.2 执行更新：核心的Ud交互

步骤 4 & 5: HLR-FE为新VLR提供用户数据

  1. If the request is allowed (e.g. no barring is to be applied), the HLR-FE sends MAP Insert Subscriber Data to provide the user data to VLR.
  2. The VLR acknowledges the request.

HLR-FE检查从UDR获取的数据，确认张伟允许漫游，于是向新VLR发送MAP Insert Subscriber Data消息，将用户的签约数据下发过去。新VLR确认收到。

步骤 6 & 7: HLR-FE向UDR发起核心更新 (Update VLR number)

  1. If the previous and new VLR are not the same, the HLR-FE updates the new user data (e.g. VLR number) in the UDR through a Ud Update procedure.
  2. If the front-end is allowed to modify the type of data, the UDR updates the new VLR number.

现在，流程进入了核心的Ud更新阶段。HLR-FE构造一个Update data request消息，通过Ud接口发送给UDR，请求将张伟的位置信息（VLR number）更新为新VLR的地址。UDR在校验了HLR-FE的写权限后，执行了数据更新操作。

NOTE: Step 6 can be done immediately after step 3

规范中的这个附注非常有价值。它指出，Ud更新操作（步骤6）理论上可以在查询完成后（步骤3之后）立即执行，而不必等到与新VLR交互完毕。这体现了流程设计的灵活性，运营商可以根据网络性能和策略进行优化。

2.3 更新后的清理工作

步骤 8 & 9: HLR-FE通知旧VLR删除数据 (CANCEL LOCATION)

  1. The HLR-FE sends MAP CANCEL LOCATION to cancel the location in the old VLR.
  2. The old VLR acknowledges the request and remove all data related.

为了释放网络资源，HLR-FE必须通知用户之前所在的那个旧VLR，告知它：“张伟已经离开，你可以删除他的临时数据了”。发送这条CANCEL LOCATION消息所需的“旧VLR地址”，正是HLR-FE在步骤2中从UDR查询得来的。这完美地展示了“查询先行”的必要性。

步骤 10: HLR-FE完成使命，回归无状态

  1. The HLR-FE informs the new VLR about the result of the Update Location procedure. No user data is kept in the front-end after the procedure is ended.

最后，HLR-FE向新VLR确认整个位置更新流程成功。随后，它会清除本地内存中所有关于本次交易的临时数据，再次变回一个干净的、无状态的实体。

3. 我的地盘听我的：IMS业务变更中的Ud更新 (A.2.3)

场景设定：张伟在使用VoNR高清通话时，发现一个问题：当他正在通话时，另一个朋友打不进来，也收不到任何提示。他通过运营商的手机营业厅App，决定为自己的号码开通“呼叫等待”（Call Waiting）功能。

这个看似简单的自助服务操作，将在后台触发一次IMS业务数据的更新流程。处理这个请求的，将是一个HSS-FE。让我们参考“Figure A.2.3-1: IMS service data change information flow example with Ud Update from HSS-FE”。

3.1 同样始于查询的更新流程

步骤 1 & 2: 用户通过AS发起业务变更 (HTTP PUT / Sh-Update)

  1. UE initiates a service data configuration update (e.g. activates call waiting) via Ut interface towards the AS.
  2. AS performs Sh-update to store the new service data (i.e. transparent data) in the HSS.

张伟在App上的操作，被转换为一个HTTP PUT请求发送给了运营商的应用服务器（AS）。AS随即通过Diameter Sh接口，向HSS（即一个HSS-FE）发送了一个Sh-Update请求，要求更新用户的业务数据。

步骤 3 & 4: HSS-FE向UDR查询，引入“序列号”

  1. Upon reception of Sh-Update, the application specific front-end (HSS-FE) checks the AS permission list. If AS is allowed, the HSS-FE fetches the service data for the user from the UDR through a Ud Query procedure. These data include the sequence number to synchronize the writing of data among different ASs.
  2. If the front-end is allowed to read the type of data, the UDR responds with service data.

HSS-FE收到请求后，同样先执行了一次Ud查询。它不仅查询了张伟当前的IMS业务数据，还获取了一个非常关键的字段——序列号（sequence number）。这个序列号是用来解决并发更新问题的。想象一下，如果张伟同时在两个不同的App上修改业务设置，网络如何保证数据的一致性？序列号就像一个版本锁，每次数据更新后都会加一。

3.2 带条件的精确更新

步骤 5 & 6: HSS-FE向UDR发起带条件的更新

  1. If sequence number is correct, the application specific front-end (HSS-FE) updates the service data for the user in the UDR through a Ud Update procedure. The update data request message contains an update condition to ensure that the data is to be updated if the sequence number was not updated by other FEs.
  2. If the front-end is allowed to update the type of data and the update condition is satisfied, the UDR stores the new service data configuration and the new sequence number

这是整个流程的精华所在。HSS-FE在向UDR发起Update data request时，附带了一个更新条件（update condition）：“仅当当前数据库中的序列号与我在步骤3中读到的一致时，才执行本次更新。”

  • 成功场景：UDR检查发现序列号未变，说明没有其他并发写入。于是，它接受更新（激活呼叫等待），并将序列号加一。
  • 失败场景：如果另一个操作恰好在HSS-FE查询之后、更新之前修改了数据，那么UDR中的序列号已经被改变。HSS-FE的更新条件将不满足，UDR会拒绝本次更新。HSS-FE需要重新执行查询-更新流程。这种“乐观锁”机制，是保障分布式数据一致性的经典方法。

NOTE 2: If the HSS-FE knows from step 4 that no other AS has subscribed to be notified when transparent data change, the HSS-FE does not send Sh-PNR to any other AS…

附注2还揭示了更新与通知的联动。HSS-FE在步骤4查询时，可能也获取了“谁订阅了这项数据”的信息。如果发现没有其他AS订阅，它就知道这次更新无需触发任何对外的Sh推送通知（Sh-PNR），从而避免了不必要的信令。

3.3 流程结束

步骤 7: HSS-FE完成并返回

  1. The HSS-FE sends the response to Sh-Update to AS. No user data is kept in the front-end after the procedure is ended.

UDR成功更新数据后，HSS-FE向AS返回成功响应。AS再通知张伟的App“呼叫等待已成功开通”。HSS-FE再次清除本地临时数据，功成身退。

FAQ 环节

Q1：为什么在CS位置更新和IMS业务变更这两个实例中，FE都不是直接更新UDR，而是要先执行一次查询？ A1：这种“查询-再更新”（或称“读-改-写”）的模式是出于严谨性和业务逻辑的需要。FE在执行更新前，必须先了解用户的当前状态。在CS位置更新中，HLR-FE需要查询旧的VLR地址以便后续通知其删除数据；在IMS业务变更中，HSS-FE需要查询当前的序列号以实现并发控制。这种模式确保了更新操作是在掌握了完整上下文信息的基础上进行的，保证了数据的准确性和一致性。

Q2：IMS业务变更实例中提到的“序列号（sequence number）”和“更新条件（update condition）”是如何协同工作的？ A2：它们协同工作以实现一种“乐观锁”，防止并发写入导致的数据覆盖问题。流程是：

  1. HSS-FE先从UDR读取当前的业务数据及其关联的序列号（版本N）。
  2. HSS-FE在本地处理逻辑后，向UDR发起更新请求，请求中附带一个条件：“仅当数据库中的序列号仍然是版本N时，才允许更新”。
  3. UDR收到请求后，会先检查这个条件。如果满足，说明在此期间没有其他写入操作，UDR就执行更新并将序列号更新为N+1。如果不满足，说明数据已被其他进程修改，本次更新失败。 这种机制在不阻塞数据库的情况下，高效地保证了数据的一致性。

Q3：在CS位置更新流程中，HLR-FE既要和新VLR交互，也要和旧VLR交互，还要和UDR交互。这个复杂的流程是如何体现UDC架构优势的？ A3：这个流程恰恰完美体现了UDC的优势：

  1. 逻辑与数据分离：HLR-FE专注于处理复杂的MAP信令交互逻辑（与新旧VLR的对话），而将所有的数据存储和一致性问题都交给了UDR。HLR-FE自身不需维护庞大而复杂的用户数据库。
  2. 数据集中化：HLR-FE完成位置更新所需要的所有信息（用户签约数据、旧VLR地址）都可以从UDR这一个源头获取，无需再去查询其他系统，简化了内部数据交互。
  3. 无状态和弹性：处理这次位置更新的可以是任何一个可用的HLR-FE，处理完成后它不保留任何状态。这使得运营商可以轻松地对HLR-FE进行扩容、缩容或升级，而不影响业务。

Q4：这些实例中，像VLR、AS这些外部网元，需要为了配合UDC架构进行修改吗？ A4：不需要。这也是UDC架构平滑演进的关键优点之一。从实例中可以看出，VLR仍然使用标准的MAP协议与HLR-FE交互，AS仍然使用标准的Diameter Sh协议与HSS-FE交互。UDC的变革是核心网内部的，对外的接口和协议保持了高度的向后兼容性。外部网元感觉自己仍在与一个传统的、集成的HLR或HSS对话。

Q5：从这两个更新实例来看，UDR中存储了哪些类型的数据？ A5：UDR中存储的数据类型非常广泛，涵盖了用户生命周期中的各类信息。从这两个例子中我们可以看到：

  • 永久性签约数据：如用户的业务限制（barrings）、IMS业务配置档案（transparent data）。
  • 半永久性状态数据：如为用户分配的S-CSCF名称。
  • 动态但需在FE间共享的状态数据：如用户当前的VLR地址。这个地址虽然是动态变化的，但任何需要知道用户位置的FE（如处理被叫的HLR-FE、处理位置更新的HLR-FE）都需要访问它，因此适合存储在UDR中。而像MSRN这样生命周期极短且无需共享的数据则不存储在UDR。

关系图谱