51学通信

深度解析 3GPP TS 23.335：Annex A.1 查询流程实例 (CS呼叫 & IMS注册)

22分钟阅读

深度解析 3GPP TS 23.335：Annex A.1 查询流程实例 (CS呼叫 & IMS注册)

本文技术原理深度参考了3GPP TS 23.335 V18.0.0 (2024-03) Release 18规范中，关于“Annex A (informative): Information flows”中的 A.1 章节，旨在通过两个经典通信场景——CS域被叫和IMS网络注册，将前面章节中理论化的数据查询流程，转化为具体、生动、可触摸的信令交互实例。

在过去的几篇文章中，我们已经系统地学习了UDC（用户数据融合）架构下的数据操作理论，包括增、删、改、查（CRUD）以及精妙的订阅/通知机制。理论是骨架，而实例是血肉。3GPP规范的附录（Annex）部分，正是为我们提供了这些宝贵的“血肉”，它们将抽象的流程具象化为工程师们日常工作中熟悉的信令交互。

今天，我们将深入研读附录A的第一个核心部分，聚焦于最常见的数据操作——查询。我们将继续跟随我们的老朋友，用户张伟，和他背后的运维专家李工的视角，亲历两个里程碑式的通信事件：一次传统的电路域（CS）电话呼叫，和一次现代化的IP多媒体子系统（IMS）网络注册。

通过这两个实例，您将清晰地看到，UDC架构是如何在不改变外部接口协议（如MAP、Diameter Cx）的前提下，将内部数据访问模式革命性地重构为FE与UDR之间的Ud接口查询。

1. 实例解析开篇：通用原则 (A.1.1 General)

在深入具体场景之前，规范首先在A.1.1章节重申了查询流程的核心原则，为后续的实例分析定下基调。

When user data (temporary or permanent) has to be fetched, the application front-end shall perform a query towards the UDR. The following flows show an example of a terminating call in CS network and an example of a re-registration procedure 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.

这段话包含三个关键信息：

  1. 查询是必须：任何时候，只要FE需要用户数据（无论是永久性的签约数据，还是临时性的状态数据），它都必须向UDR发起一次查询操作。
  2. 两大经典场景：接下来将通过CS被叫和IMS注册这两个最具代表性的场景来展示查询流程。
  3. 聚焦于流程本身：为了简化模型，这些示例将不会深入探讨UDR内部复杂的鉴权和授权细节，而是专注于展示在真实业务触发下，FE与UDR之间的信息流是如何运转的。

现在，让我们进入第一个实战场景。

2. 经典永不落幕：CS域被叫流程中的Ud查询 (A.1.2)

场景设定：张伟正在外出拜访客户的路上，他的同事王经理需要紧急联系他，于是拨打了张伟的手机号码。这是一个典型的移动用户被叫（Mobile Terminating Call）场景，在2G/3G网络中，这将通过CS域的信令流程来完成。

在UDC架构下，HLR（归属位置寄存器）的业务逻辑由无状态的HLR-FE承载，其所有用户数据都存储在UDR中。让我们参考规范中的“Figure A.1.2-1: CS terminating call example with Ud Query from HLR-FE”，看看这通电话是如何接通的。

2.1 步骤 1: GMSC发起路由信息查询 (MAP SRI)

王经理的呼叫请求首先到达了网关移动交换中心（GMSC）。GMSC知道张伟的手机号码，但不知道他当前漫游在哪个移动交换中心（MSC）下，因此无法直接将呼叫路由过去。于是，它向张伟的归属HLR发送了一条MAP协议的“发送路由信息”（Send Routing Info, SRI）请求。

  1. The GMSC initiates MAP Send Routing Info towards the HLR

在UDC网络中，这个请求实际上被路由到了一个可用的HLR-FE。对于GMSC而言，它完全感知不到后端的UDC化改造，它看到的仍然是一个标准的HLR接口。

2.2 步骤 2 & 3: HLR-FE向UDR发起核心查询

HLR-FE收到了GMSC的SRI请求，它知道自己需要回答“如何找到张伟”这个问题。但作为一个无状态的实体，它手头没有任何关于张伟的信息。于是，它立刻转向其唯一的数据源——UDR。

  1. Upon reception of SRI, the application specific front-end (HLR-FE) fetches all the user data it needs to perform its application logic (e.g. VLR number, barring indicators, call forwarding data) from the UDR through a Ud Query procedure.
  2. After applying the proper access control (i.e. the front-end is allowed to read that type of data), the UDR responds with the requested user data.

这是整个流程中最关键的一步，它将外部的MAP信令流无缝地转换为了内部的Ud查询：

  • HLR-FE的内心独白：“我需要处理一个SRI请求。为此，我需要知道张伟（由MSISDN或IMSI标识）当前的VLR（拜访位置寄存器）地址，他是否设置了呼入限制（barring indicators），以及他是否设置了无条件呼叫转移（call forwarding data）。”
  • 构造Ud查询请求：HLR-FE构造一个Query data request消息，其中包含了张伟的用户标识，以及它需要的具体数据项列表（VLR number, barring indicators, call forwarding data）。
  • UDR的处理：UDR收到请求，在执行完严格的访问控制后，从数据库中检索出这些数据，打包成Query data answer返回给HLR-FE。

HLR-FE将查询到的数据临时保存在自己的内存中。现在，它掌握了处理SRI请求所需的所有情报。

2.3 步骤 4 & 5: HLR-FE与VLR交互，获取漫游号码

手握从UDR获取的数据，HLR-FE开始执行传统的HLR业务逻辑。它发现张伟没有设置呼叫转移，并且当前登记在某个VLR下。于是，它向该VLR发送一条MAP协议的“提供漫游号码”（Provide Roaming Number, PRN）请求，要求分配一个临时的漫游号码（MSRN）用于路由。

  1. The HLR-FE sends MAP Provide Roaming Number to get a MSRN from the VLR.
  2. If the user is reachable, the VLR provides a MSRN in the response. This MSRN is not stored in the UDR, since it is temporarily reserved and consumed in the VLR.

VLR收到请求后，分配了一个MSRN并通过PRN响应消息返回给HLR-FE。这里规范特别强调，MSRN是一个非常临时的动态数据，它只在本次呼叫建立过程中有效，因此它不会被存储在UDR中。这体现了UDR存储数据的原则：主要存储相对稳定或需要在不同FE间共享的数据。

2.4 步骤 6: HLR-FE完成使命并“清空记忆”

HLR-FE拿到了宝贵的MSRN，它随即将其封装在SRI的响应消息中，返回给GMSC。GMSC根据这个MSRN，就可以成功地将呼叫路由到张伟所在的MSC，最终张伟的手机响铃。

  1. The HLR-FE responds to GMSC with the provided roaming number. No user data is kept in the front-end after the procedure is ended.

在发送完SRI响应后，HLR-FE的本次会话（FE-Session）结束。它会立即删除本地内存中所有关于张伟的临时数据（包括从UDR查询到的VLR地址、业务状态，以及从VLR获取的MSRN）。它又恢复了那个纯粹的、无状态的自己，静待处理下一个完全无关的业务请求。这个“事了拂衣去，深藏身与名”的特性，正是UDC架构下FE的核心工作模式。

3. 迈向全IP时代：IMS注册流程中的Ud查询 (A.1.3)

场景设定：CS通话的场景略显“复古”，让我们快进到5G时代。张伟刚刚结束了他的客户会议，他拿出支持VoNR（Voice over New Radio）的5G手机，准备给家人打个高清视频电话。在此之前，他的手机必须先在IMS网络中完成注册。

IMS网络的核心是HSS（归属签约用户服务器），在UDC架构下，其逻辑由HSS-FE承载。IMS注册流程比CS呼叫要复杂，它完美地展示了UDC架构如何支撑现代复杂信令。让我们参考“Figure A.1.3-1: IMS re-registration flow example with Ud Query from HSS-FE”。

3.1 步骤 1-5: I-CSCF的查询与第一次Ud交互

张伟的手机发出SIP REGISTER请求，该请求首先到达IMS网络中的查询CSCF（I-CSCF）。I-CSCF的职责是找到应该为张伟服务的S-CSCF（服务CSCF）。

  1. I-CSCF receives an incoming REGISTER request.
  2. The I-CSCF sends the Cx-Query/Cx-Select-Pull to the HSS with the Public User Identity.

I-CSCF通过Diameter协议的Cx接口，向HSS（实际上是HSS-FE）发送了一个用户授权请求（UAR），其中包含了张伟的公共用户标识（IMPI）。

  1. Upon reception of Cx-Query, the application specific front-end (HSS-FE) fetches all the user data it needs to perform its application logic (e.g. capabilities associated to the user subscription, list of visited networks allowed, S-CSCF name, etc.) in the UDR through a Ud Query procedure.
  2. After applying the proper access control …, the UDR responds with data requested (user location, required capabilities, etc.).

这是第一次关键的Ud查询。HSS-FE收到I-CSCF的请求后，立即转身向UDR查询处理该请求所需的数据：

  • 用户能力：张伟的终端和签约是否支持IMS注册？
  • 漫游限制：他当前所在的网络是否被允许接入IMS服务？
  • S-CSCF名称：如果张伟之前已经注册过，UDR中会记录着上次为他服务的S-CSCF的地址。

UDR在鉴权后，将这些信息返回给HSS-FE。

  1. The HSS-FE includes the S-CSCF name in the response. No user data is kept in the HSS FE.

HSS-FE将查询到的S-CSCF名称放在用户授权应答（UAA）中返回给I-CSCF。同样地，在完成这一步后，这个HSS-FE的会话结束，它清空了所有关于张伟的临时数据。

3.2 步骤 6-10: S-CSCF的注册与第二次Ud交互

I-CSCF拿到了S-CSCF的地址，便将SIP REGISTER请求转发给这个指定的S-CSCF。S-CSCF是IMS会话控制的核心，它需要获取张伟完整的IMS用户档案（IMS Profile）才能完成注册。

  1. The I-CSCF sends the REGISTER request to the received S-CSCF.
  2. The S-CSCF sends to HSS Cx-Put/Pull. This request, in this example, is received by a different HSS-FE.

S-CSCF通过Cx接口向HSS发送一个服务器分配请求（SAR），意在声明“我将为这个用户服务”，并请求下载他的完整档案。规范在这里特别指出，这个请求可能被路由到一个与处理上一步请求完全不同的HSS-FE。这再次印证了FE集群的负载均衡能力。

  1. Upon reception of Cx-Put/Pull, the HSS-FE fetches the user profile, S-CSCF name, etc. from the UDR through a Ud Query procedure .
  2. After applying the proper access control, the UDR responds with data requested (e.g. user profile).

这是第二次，也是更深入的一次Ud查询。这个新的HSS-FE收到了S-CSCF的请求，它向UDR查询：

  • 完整的用户档案（User Profile）：这包含了张伟所有IMS相关的业务数据，如初始过滤规则（iFC）、业务触发点、计费信息等。
  • S-CSCF名称：再次查询已分配的S-CSCF名称，用于一致性校验。

UDR返回了张伟详尽的IMS档案。

  1. The HSS- FE detects that this is a re-registration, so it sends Cx-Put/Pull Resp to S-CSCF. No user data is kept in the front-end after the procedure is ended.

HSS-FE将用户档案封装在服务器分配应答（SAA）中，发送给S-CSCF。S-CSCF下载并解析这份档案后，就完全掌握了如何为张伟提供IMS服务。此后，这个HSS-FE的会话也结束了，它同样清空了所有临时数据。

3.3 步骤 11-12: 注册成功

S-CSCF成功完成了注册流程，向I-CSCF返回一个SIP 200 OK响应，该响应最终送达张伟的手机。至此，张伟的手机成功注册到了IMS网络，可以发起VoNR高清视频通话了。

4. 实例背后的深刻启示

通过这两个截然不同但内部逻辑相似的实例，我们可以得到关于UDC架构的几个深刻启示：

  1. 外部接口的稳定性：UDC的引入是核心网内部的架构演进。对于外部网元（如GMSC、I-CSCF），它们所交互的接口（MAP、Cx）和协议保持不变，这极大地保证了网络演进的平滑性和兼容性。
  2. FE的“翻译官”与“协调员”角色：FE（无论是HLR-FE还是HSS-FE）的核心作用，是将外部传统的、面向特定业务的协议请求（如MAP SRI, Cx UAR/SAR），“翻译”成内部统一的、面向数据的Ud接口查询。它从UDR获取数据，协调完成业务逻辑，然后返回符合外部协议的响应。
  3. Ud查询的按需与精确：FE向UDR发起的查询是高度按需和精确的。它只在需要时查询，并且只查询当前业务逻辑所必需的数据子集，这保证了内部数据交互的高效性。
  4. 无状态带来的极致彈性：两个例子都反复强调，FE在完成一次业务会话后，不保留任何用户数据。这意味着处理张伟IMS注册第一步和第二步的可以是两个不同的HSS-FE实体。这种无状态特性是实现负载均衡、故障切换和资源池化（Cloud Native）的基石。

FAQ 环节

Q1：Annex A在TS 23.335规范中扮演了什么角色？ A1：Annex A扮演了“理论联系实际”的桥梁角色。在规范的主体部分（如Chapter 5）定义了UDC信息流的抽象模型和通用流程之后，Annex A通过选取通信网络中最典型、最广为人知的业务流程（如CS呼叫、IMS注册等），将这些抽象模型实例化。它向读者具体展示了，在真实的信令交互中，Ud接口的查询、更新等操作是如何被嵌入和触发的，从而极大地增强了对规范理论的理解。

Q2：在CS被叫流程中，HLR-FE具体向UDR查询了哪些关键信息？为什么需要这些信息？ A2：HLR-FE向UDR查询了三类关键信息：

  1. VLR号码：这是用户当前的位置信息，HLR-FE需要它来联系VLR以获取用于呼叫路由的漫游号码（MSRN）。
  2. 呼叫限制指示（barring indicators）：用于判断用户是否设置了“禁止所有呼入”等业务，如果设置了，则需直接拒绝呼叫。
  3. 呼叫前转数据（call forwarding data）：用于判断用户是否设置了呼叫转移（如无条件转移、遇忙转移等），如果设置了，则需要将呼叫转接到预设的号码，而不是用户的当前位置。 这些信息是处理一个被叫请求所必需的全部签约和状态数据。

Q3：IMS注册流程中为什么会发生两次独立的Ud查询？ A3：这是由IMS注册流程本身的两阶段特性决定的：

  1. 第一阶段（I-CSCF → HSS）：此阶段的目标是“寻址”，即I-CSCF需要知道应该由哪个S-CSCF来为用户服务。因此，HSS-FE向UDR的第一次查询，主要是为了获取已经为该用户分配的S-CSCF地址（如果存在）以及一些基本的签约能力信息。
  2. 第二阶段（S-CSCF → HSS）：此阶段的目标是“下载档案”，即S-CSCF在确认自己将为用户服务后，需要获取该用户完整的IMS业务配置档案（IMS User Profile）来完成注册和后续的业务处理。因此，HSS-FE向UDR的第二次查询，请求的是一个更大数据量的、完整的用户业务档案。 这两个阶段由不同的外部实体发起，逻辑上独立，因此触发了两次独立的Ud查询。

Q4：这些实例如何体现UDC架构对“无状态”（Stateless）设计的支持？ A4：这些实例通过两个关键点体现了对无状态设计的支持：

  1. 事后清除：在两个实例的流程描述中，规范都明确指出“No user data is kept in the front-end after the procedure is ended”，即FE在完成一次业务会话后，会清除所有相关的临时用户数据。
  2. 处理实体可变：在IMS注册实例中，规范特别说明处理第一阶段和第二阶段请求的可以是两个不同的HSS-FE。这清晰地表明，由于用户数据集中在UDR，任何一个HSS-FE都可以按需获取数据来处理任何用户的任何请求片段，处理的连续性不依赖于某个特定的FE实例，这是无状态设计的核心优势。

Q5：从这两个例子看，UDC架构的引入，对GMSC、I-CSCF、S-CSCF这些“外部”网元有影响吗？ A5：没有直接影响。这两个例子清晰地表明，UDC是核心网内部的架构演进。GMSC仍然使用标准的MAP接口与“HLR”交互，而I-CSCF和S-CSCF也仍然使用标准的Diameter Cx接口与“HSS”交互。它们完全感知不到其后端已经从一个集成的、有状态的HLR/HSS演变成了一个分布式的、由无状态FE和统一UDR组成的系统。这种“向后兼容”的演进方式是UDC能够平滑引入现有网络的重要前提。

关系图谱