51学通信

深度解析 3GPP TS 23.066：第四章 MNP的通用原则与“瑞士军刀”SRF

17分钟阅读

好的，我们继续对TS 23.066的深度拆解。

这是系列文章的第三篇，我们将深入规范的第四章：通用功能 (General)。这一章是理解MNP（移动号码携带）背后各种技术方案能够协同工作的“粘合剂”，它定义了所有方案都需要遵循的通用原则和共享的功能模块。

深度解析 3GPP TS 23.066：第四章 MNP的通用原则与“瑞士军刀”SRF

本文技术原理深度参考了3GPP TS 23.066 V18.0.0 (2024-03) Release 18规范中，作为规范通用性基础的“Chapter 4 General”。本文旨在为读者揭示支撑携号转网（MNP）各种复杂实现方案的底层通用原则，并重点剖析MNP-SRF这个“瑞士军刀”般的核心网元，是如何成为多种路由方案的“万能接头”的。

引言：从“各自为战”到“协同作战”

在上一篇中，我们学习了MNP的“宪章、盟友与词典”，了解了实现携号转网的两大技术流派——IN-based（智能网）和MNP-SRF-based（信令中继）。它们就像是两支拥有不同战术的“特种部队”，都可以完成“找到携转用户”这个艰巨任务。

然而，在一个真实的、多运营商共存的“携转域（portability domain）”中，情况要复杂得多。A运营商可能选择了IN方案，而B运营商可能部署了SRF方案。当一个呼叫或短信需要跨越这两个网络时，它们如何才能“听懂”对方的语言，并进行有效的协同作战，而不是因为“战术”不同而导致通信中断？

第四章“General”，就是为这场“协同作战”制定的通用作战纲领。它首先通过一个概览（Overview）来明确各方的行政职责，然后定义了确保不同方案能够兼容（Compatibility）工作的核心原则，最后重点介绍了MNP-SRF的通用功能（Common Functionality），展示了它作为“专业中转站”和“协议翻译官”的强大能力。

1. 4.1 Overview (概述)：MNP的“行政手续”

本节首先从行政管理的角度，再次明确了携号转网的本质，并规定了在“转网过程（porting process）”中，各个网络运营商（Network Operators）需要履行的数据库操作职责。

As part of the porting process administrative actions have to be performed by the network operators of the number range holder network, donor network, recipient network and, as an option, by operators of other national UMTS or GSM networks…

  • 核心解读: 这段话强调了MNP不仅是技术活，更是严谨的“行政活”。当一个号码（如美美的号码）从A运营商（donor & number range holder）转到B运营商（recipient）时，至少需要这几方同时更新自己的“账本”：
    • Recipient network (B运营商):
      • add an entry in the HLR: 在自己的HLR中，为美美创建一个全新的用户档案。
      • add an entry in the Number Portability Database: 通知NPDB（全国数据库）：“这个号码现在归我了，请将它的路由指向我。”
    • Donor network (A运营商):
      • delete the entry related to the ported MSISDNs in the HLR: 从自己的HLR中，删除美美的档案（或将其标记为已携转）。
      • add an entry in the Number Portability Database: （根据实现）也可能需要通知NPDB，“这个号码已经从我这里转出”。
  • 同步的重要性:

    Note that the order of sequence for the administrative actions … is significant with respect to prevention of disruption in service … and prevention of looping calls…

    • 规范特别强调了这些数据库操作的顺序至关重要。如果顺序不对（例如，A运营商先删除了HLR记录，而B运营商的NPDB还未生效），就可能导致在某个时间窗口内，美美的电话打不进来也打不出去。保证这些跨运营商数据库操作的事务一致性和同步性，是MNP流程设计的核心难点之一。

2. 4.2 Compatibility (兼容性)：确保“鸡同鸭讲”也能通

本节为IN方案和SRF方案的“和平共处”，制定了基本法则。

In general, IN-based and MNP-SRF (call-related) solutions are compatible and may coexist in the same portability domain.

  • 核心原则: 两种方案可以兼容共存。这意味着，即使在一个国家内，不同运营商选择了不同的呼叫处理方案，整个系统依然能够正常工作。
  • 兼容性的基石:
    1. 统一的ISUP/IAM:

      The IAM sent to the subscription network may contain additional routeing information. …the method how to convey the Routeing Number in the IAM … shall be agreed upon by the two network operators involved…

      • 无论一个呼叫是经过IN查询，还是SRF中继，当它最终被路由到正确的签约网络时，它都需要通过标准的ISUP IAM（初始地址消息）来承载。运营商之间必须就“如何在IAM消息中携带路由号码（RN）”达成一致。有了这个统一的“信封格式”，接收方网络（签约网络）就不关心这个“信封”是IN邮局送来的，还是SRF快递送来的。
    2. 统一的SCCP接口:

      The SCCP interfaces between networks in a portability domain must be agreed. This refers to the SCCP addressing mechanism being used…

      • 对于非呼叫相关信令（如短信），所有运营商之间必须就SCCP的寻址方式达成一致。例如，统一规定全局码翻译（GTT）的规则，确保发往一个手机号码的SCCP消息，能够被正确地路由到该号码归属网络的MNP-SRF或相应的网关。

场景关联: 即使A运营商使用IN方案，B运营商使用SRF方案，只要他们都遵守国家统一的IAM和SCCP接口规范，那么当A网用户呼叫已转到B网的美美时，A网的GMSC可以通过IN查询获得路由号，然后生成一个符合统一规范的IAM消息，B网的GMSC就能正确接收和处理，反之亦然。

3. 4.3 Common Functionality of the MNP-SRF：“瑞士军刀”的功能展示

本节是第四章的重中之重，它将MNP-SRF从一个抽象的概念，具象化为一个拥有清晰功能逻辑的核心网元。SRF之所以被称为“瑞士军刀”，是因为它具备多种能力，可以应对不同的信令场景。

In a PLMN that supports mobile number portability, SCCP messages sent to an HLR may be relayed by an MNP-SRF. Depending on … the MNP-SRF may modify the SCCP called party address and route the message to a different HLR or to the subscription network, or terminate the dialogue and response to the INE.

  • 核心能力:
    • 中继与修改 (Relay & Modify): 这是SRF最核心的功能。它像一个“智能路由器”，截获发往一个号码的SCCP消息，查询NPDB，然后修改消息的目标地址，将其转发到正确的目的地。
    • 终结与响应 (Terminate & Respond): 在某些情况下，SRF也可以直接“终结”一个信令交互，并自己构造一个响应消息，返回给始发实体（INE, Interrogating Network Entity）。

图示解读 (Figure 1: Steering Function for SCCP Message routeing): 这张图是理解SRF通用行为逻辑的关键。它描绘了一个名为Process SCCP_Steering_Function的“中央决策引擎”。

  1. 入口: 一个发往手机号码（MSISDN）的SCCP消息到达。
  2. 第一层决策：方案选择 (OPTION)
    • IN-based: 如果本网络采用IN方案处理呼叫相关信令，那么这类信令不会经过SRF。
    • MNP-SRF-based: 如果采用SRF方案，或者消息是非呼叫相关的，那么信令将进入SRF进行处理。
  3. 第二层决策：信令类型判断 (call related)
    • SRF内部会判断收到的消息是呼叫相关（如SRI）还是非呼叫相关（如SRI-for-SM）。
  4. 执行路由:
    • 对于非呼叫信令，SRF会执行Procedure MNP_SRF_Non_Call_Related（在附录B中定义），查询NPDB，然后将消息中继到正确的HLR或签约网络。
    • 对于呼叫信令（仅在SRF方案中），SRF会执行Procedure MNP_SRF_MATF_Call_Related（在附录C中定义），完成类似的中继功能。
    • 对于MNP信息查询请求（如ATI），SRF也可能直接查询NPDB并终结响应。

图示解读 (Figure 2: Process MNP_SRF): 这张图进一步深入到SRF内部，展示了其处理逻辑。当一个SCCP消息进入SRF后：

  1. MNP信息请求？: 首先判断是否是一个纯粹的MNP信息查询请求。如果是，则直接查询NPDB并响应（MNP_SRF_MATF_Info_Request）。
  2. 呼叫相关？: 如果不是信息查询，再判断是否是呼叫相关信令。
    • 是: 执行呼叫相关的处理逻辑（MNP_SRF_MATF_Call_Related）。
    • 否: 执行非呼叫相关的处理逻辑（MNP_SRF_Non_Call_Related）。
  3. 终结还是中继？ (terminate?): 在每个处理逻辑内部，SRF都会根据查询结果和消息类型，决定是直接终结并响应，还是修改地址后中继出去。

防环机制:

…the SCCP hop counter may be used to prevent indefinite looping of messages between PLMNs. The MNP-SRF would then decrement the SCCP hop counter for every message that is relayed.

  • 由于不同运营商的NPDB数据可能存在短暂的不一致，信令有可能在两个网络的SRF之间形成“循环路由”。为了防止这种情况，SRF每中继一次消息，都会将SCCP消息头中的**跳数计数器（hop counter）**减1。当计数器减到0时，消息将被丢弃，从而打破了无限循环。

FAQ环节

Q1：在4.1节的行政流程中，为什么“其他网络”也可能需要更新NPDB？ A1：这主要与**直接路由（Direct Routeing）**的实现有关。为了实现最高效的呼叫，一个运营商（如C运营商）可能希望在自己的网络内部，也维护一份NPDB的副本或缓存。这样，当C网用户拨打一个已携转号码（即使这个号码与C网无关）时，C网可以直接查询自己的本地数据库，直接将呼叫路由到正确的签约网络，而无需经过号码范围持有网络进行中转。为了实现这一点，C运营商就需要参与到全国的NPDB同步机制中。

Q2：MNP-SRF是一个物理设备吗？它通常部署在哪里？ A2：MNP-SRF是一个逻辑功能实体。在实际部署中，它通常与信令转接点（Signalling Transfer Point, STP）合设，或者作为一个独立的、基于IP的信令网关设备存在。它的物理位置通常在运营商核心网的信令汇接层面，因为所有跨网的SCCP信令，理论上都应经过STP进行路由，这是部署SRF进行“拦截”和“中继”的最佳位置。

Q3：Figure 1中的IN-based分支，为什么call-related消息不经过SRF？ A3：因为在纯粹的IN-based呼叫方案中，MNP查询的智能被赋予了GMSC。GMSC在收到呼叫的ISUP IAM消息后，自己会去触发一个到NPDB的IN查询。这个查询过程，以及后续基于查询结果的路由，都是在GMSC的呼叫控制逻辑中完成的，不涉及SCCP层的信令中继。因此，这条路径完全绕过了MNP-SRF。但是，该运营商的非呼叫相关信令（如短信），仍然需要依赖MNP-SRF来进行路由，因为GMSC的呼叫逻辑处理不了这些信令。

Q4：为什么规范要区分呼叫相关和非呼叫相关的信令？它们在技术上有什么根本区别？ A4：它们的根本区别在于承载协议、应用场景和性能要求。

  • 呼叫相关信令 (Call-related): 主要是指为建立一个实时的、电路域或IMS的会话（电话）而进行的信令交互。它的核心目标是获取一个用于接续呼叫的路由号码（如MSRN）。典型的信令是MAP SRI (Send Routing Information)。
  • 非呼叫相关信令 (Non-call-related): 指所有其他使用MSISDN作为地址的SCCP消息。它的目标多种多样，可能是传递一条短信 (SRI_for_SM)，获取用户状态信息 (ATI)，或管理补充业务。这些信令不直接导致一个媒体流的建立。 由于应用目标不同，SRF在处理它们时，需要调用的内部逻辑、查询NPDB后所需采取的动作（是获取路由号，还是直接中继到目标HLR），都是完全不同的。因此，必须对它们进行区分。

Q5：4.3节提到的“the test ‘MNP info-request’”和“the test ‘call-related’”是如何在技术上实现的？ A5：这通常是通过**SCCP的翻译类型（Translation Type, TT）**来实现的。SCCP GTT的规则，不仅可以基于被叫号码（CdPA），还可以基于TT的值来进行路由决策。运营商可以在自己的网络中，为不同类型的信令，分配不同的TT值。

  • 例如，可以规定：所有SRI_for_SM消息的TT=10，所有SRI（呼叫相关）消息的TT=11，所有ATI（MNP信息查询）消息的TT=12。
  • 当一个SCCP消息到达STP/SRF时，路由引擎就可以通过检查TT的值，来精确地判断这条消息是属于“非呼叫”、“呼叫相关”还是“信息查询”，并将其导向SRF内部正确的处理流程（如图2所示）。

关系图谱