51学通信

深度解析 3GPP TS 23.003：25, 26 & 27 OCS, MC Services & V2X的标识

20分钟阅读

好的，我们继续解读规范。在探索了从2G到5G，从蜂窝网到Wi-Fi、D2D的各种身份标识之后，我们将进入一个与计费和策略紧密相关的领域——OCS（在线计费系统）的寻址。

深度解析 3GPP TS 23.003：25, 26 & 27 OCS, MC Services & V2X的标识

本文技术原理深度参考了3GPP TS 23.003 V18.7.0 (2024-09) Release 18规范中，关于“Chapter 25 Identification of Online Charging System”、“Chapter 26 Numbering, addressing and identification for Mission Critical Services”和“Chapter 27 Numbering, addressing and identification for V2X”的核心章节。由于这三章内容相对独立且聚焦于特定业务的寻址和标识，我们将在一篇文章中进行整合解读，旨在为读者展示3GPP如何为计费、关键任务通信和车联网这些重要垂直领域设计专用的“路标”。

在之前的章节中，我们已经构建了一个庞大的移动通信标识“宇宙”。然而，这个宇宙的运转离不开两大驱动力：商业（计费）和应用（服务）。用户为何能打电话、能上网？因为他们付费了。网络如何知道该收多少钱？这就需要实时、精确的计费系统。用户使用手机又能做什么？这就催生了如关键任务通信、车联网等各种创新的垂直应用。

本篇，我们将聚焦于这些驱动力背后的标识体系。我们将引入三位新的“一日”主角：

  1. 财务总监陈女士，她正在核对公司上万张物联网卡的实时账单。
  2. 消防指挥官张队，他正在一场紧急救援中，需要确保通信的高度安全。
  3. 自动驾驶工程师李工，他正在测试车辆如何从云端获取实时的交通预警。

他们三人的工作，将分别揭开OCS、MC Services和V2X这三大领域核心标识的神秘面纱。

1. “钱包”的地址：OCS的Home Network Domain Name (章节 25)

陈女士的公司为旗下的物流车队配备了数万张物联网SIM卡，用于实时追踪车辆位置和货物状态。这些卡采用的是预付费模式，每消耗1MB流量，都需要实时地从账户中扣除费用。这个实时扣费的“账房先生”，就是OCS（Online Charging System - 在线计费系统）。

当一辆物流车的数据流量经过核心网的网关（如PGW/UPF）时，网关必须暂停流量，先去问一下OCS：“这个用户（SIM卡）的账户里还有钱吗？我能放行多少流量？” 这个“去问一下”的过程，就需要知道OCS的地址。

25.2 Home network domain name The home network domain name of the OCS shall be in the form of an Internet domain name… If the home network domain of the OCS is not known…, it shall be:

  • in the form of “ocs.mnc.mcc.3gppnetwork.org”… or
  • derived from the subscriber’s IMSI… 3. add the label “ocs” to the beginning of the domain name.

与我们之前看到的GAA, GAN, IMS等系统的寻址方式一样，OCS的地址也是一个FQDN（全限定域名），并且其发现机制同样遵循了3GPP标准化的“祖传秘方”。

构建规则： 如果网络节点（如PGW/UPF）没有静态配置OCS的地址，它将根据当前处理的用户的IMSI，动态地构建出OCS的FQDN。

  1. 解析IMSI：从用户信令中获取IMSI，提取MCC和MNC。
  2. 构建运营商域：拼接出mnc<MNC>.mcc<MCC>.3gppnetwork.org。
  3. 添加业务前缀：在最前面加上ocs.标签。

场景串联： 一辆隶属于陈女士公司的、使用中国移动物联网卡的货车，刚刚产生了一笔数据流量。

  1. 中国移动的UPF截获了这笔流量。SMF决定需要向OCS进行信用授权。
  2. SMF根据这张卡的IMSI（MCC=460, MNC=00），构建出OCS的FQDN：ocs.mnc000.mcc460.3gppnetwork.org。
  3. SMF通过内部DNS查询这个域名，获得了OCS服务器集群（通常是CHF - Charging Function）的IP地址。
  4. SMF向OCS发起Diameter/HTTP请求，查询该卡的账户余额，并申请了一定额度的流量配额。
  5. OCS检查账户，确认有余额，向SMF批准了10MB的配额。
  6. SMF指示UPF放行该货车的流量，并开始精确计量，直到10MB配额用完，再重复上述流程。

通过这套标准化的寻址机制，确保了无论用户在哪里、使用什么业务，其计费请求总能被准确地路由到其归属运营商的“钱包”——OCS进行处理，这是运营商实现商业闭环的根本保障。

2. “加密频道”的域名：MC Services的机密性保护 (章节 26)

消防指挥官张队正在指挥一场高层建筑的灭火救援。他与队员之间的通信，内容涉及战术部署、被困人员位置等高度敏感信息，绝不能被窃听。他们使用的是MC Services（Mission Critical Services - 关键任务服务），如MCPTT（关键任务一键通）、MCVideo（关键任务视频）。

为了实现端到端的最高级别安全，MC Services不仅对通信内容进行加密，还对通信双方的“身份”本身进行加密保护。

26.2 Domain name for MC services confidentiality protection of MC services identities A Domain Name for MC Services confidentiality protection used in a host part of a SIP URI indicates that the user part of the SIP URI contains a confidentiality protected MC Services identity. This Domain Name shall be the string “mc1-encrypted.3gppnetwork.org”.

当张队呼叫他的队员“王伟”时，他在MCPTT终端上点击的联系人“王伟”，其背后并不是一个公开的SIP URI（如sip:[email protected]）。为了保护“王伟”这个身份不被网络中的无关节点甚至窃听者知晓，他的身份被加密成了一串看似无意义的乱码。

那么，接收这个呼叫请求的网络节点（如IMS核心网）如何知道这是一个加密后的身份，并将其正确路由到MC服务平台进行解密和处理呢？答案就是使用一个特殊的、约定好的域名。

mc1-encrypted.3gppnetwork.org

场景串联：

  1. 张队的MCPTT终端要呼叫王伟。终端首先将王伟的MC身份（MCPTT ID）进行加密，得到一串密文，例如Abc123Def456。
  2. 然后，终端构造一个特殊的SIP URI。这个URI的username部分就是这串密文，而domain部分，正是那个约定好的特殊域名。最终的呼叫目标地址是：sip:[email protected]。
  3. 当IMS核心网收到这个呼叫请求时，它看到@mc1-encrypted.3gppnetwork.org这个特殊的域名，就像看到了一个“机密文件”的标签。它自己不会尝试去解析Abc123Def456，而是根据预设的路由规则，立即将这个请求直接转发给专门的MC服务平台（MCPTT Server）。
  4. MCPTT服务器收到请求后，用自己的密钥解密Abc123Def456，还原出王伟的真实MCPTT ID，然后再继续后续的呼叫流程。

这个特殊的域名，就像是一个“路标”，告诉沿途的所有网络节点：“不要打开这个包裹，直接送到保密局！”。它通过DNS路由机制，巧妙地实现了对加密身份的“盲转发”，确保了端到端的身份机密性。

3. “车路协同”的信标：V2X控制功能的寻址 (章节 27)

自动驾驶工程师李工正在测试“智行一号”的V2X（Vehicle-to-Everything - 车联万物）功能。车辆需要实时地从网络中获取前方路口的红绿灯状态、行人预警等信息。这些信息是由一个名为**V2X Control Function（V2X控制功能）**的网络实体来分发的。车辆如何找到这个至关重要的“交通信息中心”呢？

27.2.1 General In order to retrieve V2X communication parameters, the UE needs to connect to the V2X Control Function… If the address of the V2X Control Function is not provisioned… the UE self-constructs the V2X Control Function FQDN…

与OCS一样，如果车辆没有被预配置V2X控制功能的地址，它也需要一套自构造FQDN的机制。

27.2.2 Format of V2X Control Function FQDN The V2X Control Function FQDN shall be constructed as follows: “v2xcontrolfunction.epc.mnc.mcc.3gppnetwork.org”

其构建规则依然是我们熟悉的配方： v2xcontrolfunction.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

  • 业务前缀：v2xcontrolfunction，清晰地表明了要寻找的服务类型。
  • 网络域：这里使用的是epc.域，因为早期的V2X是基于4G-EPC架构（LTE-V2X）定义的。在5G时代（NR-V2X），这个域名结构也可能演进为基于5gc.域。

场景串联：

  1. “智行一号”的V2X模组启动，它需要获取通信参数。
  2. 模组根据SIM卡信息，构建出V2X控制功能的FQDN：v2xcontrolfunction.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org。
  3. 通过DNS查询，车辆获得了V2X控制功能的IP地址。
  4. 车辆向该地址发起请求，获取V2X通信所需的配置信息，如通信模式（是使用PC5直连通信还是Uu蜂窝通信）、无线资源池、安全证书等。
  5. 配置完成后，“智行一号”便能够与路边的基础设施（RSU）或其他车辆进行通信，接收实时的交通信息。

这个标准化的FQDN，确保了任何一辆符合3GPP规范的汽车，在任何一个部署了V2X服务的运营商网络中，都能通过统一的方式，自动地找到并连接上“车路协同”的大脑。

4. 总结：为垂直应用铺设标准化的“寻址轨道”

本篇整合解读的25、26、27三章，虽然各自针对的是完全不同的业务领域，但它们共同揭示了3GPP在推动移动通信赋能垂直行业时的一个核心设计哲学：标准化寻址。

  • OCS FQDN (ocs.)：为最基础的**商业化（计费）**需求，提供了统一的寻址方案，是运营商实现“流量变现”的技术基础。
  • MC Services加密域名 (mc1-encrypted.)：为要求最苛刻的**公共安全（关键任务）**通信，通过一个巧妙的“约定域名”，解决了端到端身份保密这一难题。
  • V2X Control FQDN (v2xcontrolfunction.)：为前景最广阔的**车联网（智能交通）**应用，提供了统一的服务发现入口，是实现“车路协同”的第一步。

3GPP通过为这些关键的垂直应用预定义标准化的FQDN构建规则，极大地降低了产业链（终端制造商、应用开发者、网络设备商）的集成和部署复杂性。无论背后的业务逻辑有多么复杂，“如何找到服务的第一个入口”这一根本问题，都被一套统一、简洁、基于DNS的机制解决了。这就像是为各种不同的“火车”（垂直应用）铺设了标准轨距的“轨道”（寻址机制），使得它们能够顺利地驶入并驰骋在广阔的移动通信网络之上。

FAQ - 常见问题解答

Q1：OCS（在线计费）和OFCS（离线计费）有什么区别？ A1：区别在于计费的实时性和对用户行为的控制能力。

  • OCS (Online Charging)：实时计费。在用户使用业务之前或之中，网络必须先向OCS申请配额（如10MB流量，5分钟通话）。配额用完后，必须再次申请。如果账户余额不足，OCS会拒绝授权，业务会被立即中断。它主要用于预付费用户和需要精确实时控制的场景。
  • OFCS (Offline Charging)：非实时计费。网络节点（如PGW/UPF）会在业务结束后，生成一份包含本次业务使用量的话单（CDR），然后定期地、成批地发送给计费中心。计费中心在事后对这些话单进行处理，生成用户的月度账单。它主要用于后付费用户。

Q2：MC Services的加密域名机制，是如何保证安全的？ A2：它保证的是身份隐私安全，其机制的巧妙之处在于解耦。

  1. 加密：由终端和MC服务器这对“业务层”的实体负责，它们共享一套密钥体系，用于加密和解密身份。
  2. 路由：由底层的IMS/IP网络这些“传输层”的实体负责。它们完全不关心username部分是什么，也不需要知道解密的密钥。它们唯一的任务就是识别出@mc1-encrypted.3gppnetwork.org这个“特殊标记”，然后像“快递员”一样，把这个“加密包裹”原封不动地送到预先配置好的MC服务器地址。 这种机制避免了在中间网络节点（它们可能不属于高安全域）暴露用户的真实身份，实现了端到端的隐私保护。

Q3：V2X通信有两种模式，Uu接口和PC5接口，它们都需要寻找V2X控制功能吗？ A3：都需要。

  • Uu接口模式：车辆通过传统的蜂窝网络接口（经过基站）与V2X应用服务器通信。在这种模式下，寻找V2X控制功能是获取服务配置和发起通信的前提。
  • PC5接口模式：车辆之间或车辆与路边单元（RSU）之间进行直接通信。虽然数据不经过基站，但在通信开始之前，车辆仍然需要通过Uu接口连接到V2X控制功能，来获取PC5通信所需的授权和资源配置（例如，可以使用哪些频率、发射功率、安全证书等）。 因此，V2X控制功能是两种通信模式的总“指挥官”，通过标准化的FQDN找到它是所有V2X业务的起点。

Q4：为什么这些垂直业务的FQDN大多都构建在.3gppnetwork.org这个域下？ A4：这是为了利用GSMA建立的**全球运营商间IP互联网络（GRX/IPX）**的DNS解析能力。.3gppnetwork.org是这个专网的“根域名”。将FQDN构建在这个域下，可以确保：

  1. 全球可达：无论用户漫游到全球哪个运营商网络，只要该网络连接到GRX/IPX，就能正确解析这些域名，找到用户归属的服务节点。
  2. 安全可信：GRX/IPX是一个私有的、由运营商组成的网络，其DNS服务比公共互联网DNS更安全、更可靠，不易受到攻击。
  3. 策略路由：运营商可以在GRX/IPX DNS中实现复杂的策略，例如根据漫游地位置，将用户请求解析到不同地理区域的服务器。

Q5：这些在TS 23.003中定义的标识，与具体业务（如MCPTT, V2X）的详细协议（如TS 24.379 for MCPTT）是什么关系？ A5：TS 23.003扮演的是“总纲”和“路标”的角色。

  • TS 23.003：定义了**“如何找到服务的入口”**。它定义了用于服务发现的顶层、全局性的标识符和FQDN，解决了“从0到1”的引导问题。例如，它告诉你V2X控制功能的FQDN格式，但不管你找到它之后跟它具体“聊什么”。
  • 具体业务的TS (如TS 24.379)：定义了**“找到入口后该如何交互”**。它详细规定了业务层的信令流程、消息格式、媒体编码以及业务内部使用的各种ID（如MCPTT Group ID, MCPTT User ID等）。 两者相辅相成，前者负责“引路”，后者负责“办事”。

关系图谱