本文技术原理深度参考了3GPP TS 23.501 V18.9.0 (2025-03) Release 18规范中，关于“5.38 Support for Multi-USIM UE”的核心章节，旨在为读者提供一个5G网络如何为支持多USIM卡的终端提供更智能、更高效的通信协同与资源管理的全景视图。

深度解析 3GPP TS 23.501：5.38 多USIM支持 (Support for Multi-USIM UE)

欢迎回到“解构5G核心网”系列。在之前的文章中，我们已经深入探讨了5G如何为XR等前沿应用提供极致的网络保障。今天，我们将把目光拉回到一个我们日常使用中非常普遍但又充满技术挑战的场景——双卡手机，或者更广泛地说，多USIM终端。

几乎人手一部的双卡手机，在给我们带来便利的同时，也给移动网络和手机自身带来了巨大的挑战。当一张卡正在通话或高速下载时，另一张卡如何接听电话？当两张卡的寻呼（Paging）周期恰好重叠时，手机该如何处理？传统的解决方案往往简单粗暴，例如“一卡通话，另一张断网”，或是依赖终端自身有限的能力进行规避，用户体验并不理想。

5G时代，为了优化多USIM终端的用户体验并提升网络效率，3GPP在规范的5.38章节中，定义了一套全新的、由网络和UE协同工作的多USIM特性（Multi-USIM features）。

为了让大家更直观地理解这些特性，让我们引入今天的场景。我们的主角小晴，正在使用一部支持5G双卡的旗舰手机。

• 卡1 (工作号): 签约了运营商A，主要用于工作通话和移动办公。

• 卡2 (生活号): 签约了运营商B，用于个人通信和娱乐。

我们将通过小晴在一天中遇到的几个典型场景，来揭示5G网络是如何通过这套“组合拳”，智能地管理她的双卡通信，避免冲突，并优化手机功耗的。

---

1. “亮明身份”：Multi-USIM能力协商 (5.38.1 General)

一切智能协同的开始，是UE与网络之间的“坦诚相告”。UE需要告诉网络：“我是一部多USIM手机，我希望能得到特殊照顾”。

In the Registration procedure…, when a Multi-USIM UE has more than one USIM active, supports and intends to use one or more Multi-USIM specific features, it indicates to the AMF the corresponding Multi-USIM feature(s) are supported… Based on the received indication of the supported Multi-USIM features from the UE, the AMF shall indicate to the UE the support of the Multi-USIM features based on the Multi-USIM features supported by network…

1.1 协商流程

1. UE上报能力： 当小晴的手机使用其中一张USIM（例如卡1）向AMF发起注册时，它会在Registration Request消息的UE 5GMM Core Network Capability信息单元中，明确地告诉AMF，它支持哪些多USIM特性。

2. AMF返回网络能力： AMF收到这个指示后，会检查自身以及整个网络的配置，看支持其中的哪些特性。然后，AMF会在Registration Accept消息中，告知UE网络侧所支持的多USIM特性列表。

3. 达成共识： 经过这次协商，UE和AMF就接下来可以使用哪些“特殊规则”来协同工作达成了共识。

1.2 多USIM的“能力工具箱”

规范在5.38.1中定义了多个Multi-USIM特性，我们将在后续章节逐一解析：

• Connection Release (连接释放): 允许UE主动请求释放RRC连接。

• Paging Cause Indication for Voice Service (语音业务寻呼原因指示): 在寻呼中明确告知UE这是一个语音来电。

• Reject Paging Request (拒绝寻呼请求): 允许UE明确拒绝一次寻呼。

• Paging Restriction (寻呼限制): 允许UE请求网络在一段时间内不要寻呼自己。

• Paging Timing Collision Control (寻呼时间碰撞控制): 允许UE通过请求新的GUTI来错开不同USIM的寻呼周期。

---

2. “请让我离开”：连接释放请求 (5.38.2 Connection Release)

这是多USIM场景下最基础也最重要的一个功能。当UE的一张USIM（卡A）正忙于高优先级任务时，它可能希望另一张USIM（卡B）能够主动释放其RRC连接，进入IDLE状态，从而将手机的调制解调器（Modem）资源完全让给卡A。

A Multi-USIM UE may request the network to release the UE from RRC_CONNECTED state in 3GPP access for a USIM due to activity on another USIM in 3GPP access, if both UE and network indicate the Connection Release feature is supported to each other.

2.1 核心机制

1. UE发起请求： 当UE（例如卡2）决定需要释放连接时，它会发起一个特殊的**Service Request或Registration Request（如果是移动性更新），其中包含一个Release Request Indication**。

2. AMF执行释放： AMF收到这个“请让我离开”的请求后，如果网络支持该功能，它就会正常处理完当前请求，然后立即启动AN Release Procedure，释放UE的N2连接，从而使UE的RRC连接被释放，进入CM-IDLE状态。

2.2 场景代入：工作优先，生活让路

小晴正在使用**卡1（工作号）进行一场非常重要的视频会议，占用了大量的无线资源。此时，她的卡2（生活号）**虽然没有数据业务，但仍然保持着RRC连接（处于RRC_CONNECTED的非活跃状态）。

• 资源冲突： 手机的Modem检测到，维持卡2的RRC连接正在消耗一定的处理和射频资源，可能会对卡1的视频会议质量产生潜在影响。

• 主动释放： 于是，手机的卡2主动向其服务的AMF（运营商B的AMF）发送了一个带有Release Request Indication的Service Request。

• 网络配合： 运营商B的AMF收到请求后，立即释放了卡2的N2连接，使其进入了CM-IDLE状态。

• 资源独占： 现在，手机的整个Modem资源可以完全专用于卡1的视频会议，确保了会议的稳定流畅。

这个功能将连接管理的“主动权”部分下放给了UE，使得UE能够根据其内部的资源调度优先级，智能地管理其在不同网络上的连接状态。

---

3. “谁的电话？”：语音业务寻呼原因指示 (5.38.3)

在网络拥塞时，每一次不必要的网络唤醒都会消耗宝贵的资源和电量。如果能提前知道寻呼的“目的”，UE就能做出更明智的决策。

The network that supports Paging Cause Indication for Voice Service feature shall provide a Voice Service Indication for IMS voice service in the Paging message, only if the UE indicates the Paging Cause Indication for Voice Service feature is supported to the network.

核心机制：

当网络需要寻呼UE以进行一次IMS语音来电时，如果UE和网络都支持此功能，AMF会在发送给RAN的N2 Paging消息中，包含一个Paging Cause，指示这是一次**“Voice Service”**。RAN在向UE发送的Uu口寻呼消息中，也会携带这个指示。

场景代入：

小晴正在使用**卡2（生活号）沉浸式地玩着云游戏，占用了手机的主要通信资源。此时，她的卡1（工作号）**来了一个电话。

• 带原因的寻呼： 运营商A的AMF在寻呼小晴的卡1时，明确地在寻呼消息中加入了“Voice Service”的指示。

• UE的智能决策： 手机收到了这个寻呼。操作系统看到这是一个语音来电，而不是一个无关紧要的APP后台数据推送。它立即判断这是一个高优先级事件。

• 资源切换： 操作系统可能会立即暂停云游戏的数据流（通知卡2的应用和网络），将Modem资源快速切换给卡1，以确保电话能够被及时接听。

如果没有这个指示，手机可能会认为这只是一次普通的低优先级数据寻呼，从而选择忽略它或延迟处理，导致重要电话的漏接。

---

4. “现在没空”：拒绝寻呼与寻呼限制 (5.38.4 & 5.38.5)

这两个功能赋予了UE在特定场景下，主动拒绝或限制网络寻呼的能力。

4.1 拒绝寻呼请求 (Reject Paging Request)

Upon being paged by the network, the Multi-USIM UE in CM-IDLE state attempts to send a Service Request message to the paging network including the Reject Paging Indication as the response to the paging…

核心机制：

当UE收到一次寻呼，但由于内部原因（例如，另一张USIM正在进行更高优先级的活动）无法或不愿响应时，它可以快速地建立一个RRC连接，然后立即发送一个带有**Reject Paging Indication**的Service Request消息。网络收到这个“拒绝”后，就知道了UE当前无法响应，便会停止后续的寻呼重试。

4.2 寻呼限制 (Paging Restriction)

A Multi-USIM UE… may indicate Paging Restriction Information in the Service Request or Registration Request message…

核心机制：

这是一个更主动的机制。UE可以在Service Request或Registration Request中，向AMF提供**Paging Restriction Information**，请求在接下来的一段时间内，对寻呼进行限制。限制的类型可以包括：

• all paging is restricted (禁止所有寻呼)

• all paging is restricted, except paging for voice service (只允许语音来电寻呼)

AMF会将这个限制信息存储在UE的上下文中。在限制生效期间，AMF将不会为受限的业务类型向该UE发起寻呼。

4.3 场景代入：“免打扰”模式

小晴正在使用**卡1（工作号）进行一场长时间、大流量的文件上传。她不希望卡2（生活号）**的任何推送通知、APP更新等非紧急的下行数据打扰到这个过程。

1. 请求寻呼限制： 在上传开始前，手机的卡2向运营商B的AMF发送了一个Service Request，其中包含了Paging Restriction Information，请求**“禁止除语音外的所有寻呼”**。

2. AMF执行限制： 运营商B的AMF接受了这个请求。

3. 效果：

   • 此时，如果小晴的朋友通过微信给她发消息，由于微信的数据需要通过寻呼来唤醒UE，AMF会发现该UE处于寻呼限制状态，于是不会发起寻呼。这条微信消息会被SMF/UPF缓存起来。

   • 但是，如果小晴的妈妈给她打来VoNR电话，由于这是“voice service”，AMF会豁免这个限制，正常发起寻呼，小晴的手机依然会响铃。

4. 业务完成后解除限制： 当卡1的文件上传完成后，卡2会再次发起一个Service Request，其中不再包含寻呼限制信息，AMF随之解除限制。之前被缓存的微信消息，此时才会被网络通过寻呼推送下来。

---

5. FAQ

Q1: Connection Release功能，是UE想什么时候释放连接，网络就必须同意吗？

A:

不完全是。虽然UE发起了请求，但最终的决定权仍在AMF。AMF会根据网络策略来决定是否执行释放。在大多数情况下，如果这是一个合法的Multi-USIM UE发出的请求，AMF会予以配合。但是，如果网络正在进行一些关键的信令流程（如安全模式命令），或者有高优先级的下行数据正在等待发送，AMF可能会延迟或忽略这个释放请求，以保证网络流程的完整性。

Q2: “Paging Cause Indication for Voice Service”和我们手机通知栏里的“VoLTE/VoNR”标识有什么关系？

A:

它们是两个不同层面的概念，但有内在联系。

• “VoLTE/VoNR”标识是UE在成功注册到IMS网络，并且网络确认支持IMS语音后，由手机操作系统在界面上显示的一个状态标志。它告诉用户“您的手机已具备高清通话能力”。

• “Paging Cause Indication for Voice Service”是当有一个实际的语音来电时，网络在寻呼信令中携带的一个事件指示。它告诉UE“现在来的这个寻呼，就是为了一个语音电话”。

前者是“能力状态”，后者是“实时事件”。正因为UE看到了“VoLTE/VoNR”标识，知道自己可能会接到高清语音电话，所以它在与网络协商时，才会声明自己支持“Paging Cause Indication”功能，希望网络在来电时能明确告知。

Q3: 如果我开启了“Paging Restriction”（寻呼限制），别人给我打电话会打不通吗？

A:

这取决于您设置的限制级别。

• 如果您请求的是**“禁止所有寻呼”**，那么是的，别人给您打电话时，网络将不会寻呼您，对方可能会听到“您拨打的用户暂时无法接通”的提示。

• 如果您请求的是**“禁止除语音外的所有寻呼”，那么别人给您打电话依然可以接通**，因为语音业务被豁免了。但微信、QQ等APP的消息推送，则会被网络暂时屏蔽。

这个功能给了用户在特定场景下（如专注工作、避免打扰）更精细的控制权。

Q4: Reject Paging Request和Paging Restriction有什么主要区别？

A:

主要区别在于主动性和持续时间。

• Reject Paging Request是被动的、一次性的。它是在网络已经发起寻呼之后，UE才做出的“拒绝响应”。它只对当前这一次寻呼有效，网络在稍后可能还会重试寻呼。

• Paging Restriction是主动的、持续性的。它是UE提前向网络“报备”，请求在未来的一段时间内不要对自己进行（某些类型的）寻呼。这是一个在AMF侧生效的“免打扰”状态，在此期间网络不会主动发起寻Oreal。

Q5: 这些Multi-USIM功能需要手机硬件支持吗？

A:

是的，这些功能不仅需要5GC的支持，也对手机的基带芯片（Modem）和操作系统提出了更高的要求。

• Modem： 需要具备更智能的资源管理能力，能够监控两张USIM的活动状态，并根据优先级做出决策（如请求连接释放）。

• 操作系统/协议栈： 需要实现新的NAS信令逻辑，能够正确地生成和解析Release Request Indication、Paging Restriction Information等新的信息单元，并根据网络的响应来控制自身的行为。

因此，这些高级的Multi-USIM功能，通常只有在较新的、高端的5G手机上才能得到支持。