好的，在完成了对9.3节异系统移动性的深入探讨之后，我们现在将目光聚焦于移动性管理中一个虽然简短但非常重要的方面——漫游与接入限制。这是确保网络安全、执行运营商策略的关键环节。
深度解析 3GPP TS 38.300：9.4 Roaming and Access Restrictions (漫游与接入限制)
本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中，关于“9.4 Roaming and Access Restrictions”的核心章节，旨在为读者阐明5G网络中漫游与接入限制信息是如何从核心网传递到RAN侧，以及RAN侧（gNB）是如何在移动性管理中执行这些策略的。
前言：UE的“旅行护照”与“签证”
我们的主角小明，暑假期间出国旅行。当他的飞机降落在异国他乡，他打开手机，手机信号从“无服务”很快变成了当地运营商的5G网络标识。他成功地连接上了网络，但可能会发现，某些应用无法使用，或者无法接入某些特定的网络（例如，当地政府或企业的专网）。
这一切的背后，是**漫游与接入限制（Roaming and Access Restrictions）**机制在发挥作用。小明的SIM卡中存储着他的“国籍”（归属运营商 HPLMN），而核心网（AMF）则像一个“海关与移民局”，根据他归属运营商与当地运营商（VPLMN）签订的漫游协议，为他签发了一份临时的“旅行签证”。这份“签证”上，详细规定了他在当地可以做什么、不可以做什么。
导师老王向小玲解释道：“漫游与接入限制是运营商实施商业策略和保障网络安全的重要手段。核心网AMF是策略的制定者，但最终的执行者，尤其是在CONNECTED态下的移动性管理中，却是我们RAN侧的gNB。gNB必须能看懂UE的这份‘签证’，并在指挥UE‘转机’（切换）时，确保不会将它引导到‘禁止入境’的区域。这份‘签证’的传递和解读规则，就定义在38.300的9.4节。”
今天，我们将化身为“边境检查官”，深入解读这份特殊的“旅行签证”，看看它是如何影响UE的移动性行为的。
1. “签证”的内容：漫游与接入限制信息
这份由AMF下发给gNB的“签证”，即漫游与接入限制信息，包含了多种类型的“条款”。
The roaming and access restriction information for a UE includes information on restrictions to be applied for subsequent mobility action during CM-CONNECTED state… It includes the forbidden RAT, the forbidden area and the service area restrictions as specified in TS 23.501. It also includes serving PLMN/SNPN and may include a list of equivalent PLMNs or a list of equivalent SNPNs.
其主要内容包括：
-
禁止的RAT（Forbidden RAT）：例如，协议可能规定，该用户不允许漫游到cdma2000等老旧的系统上。
-
禁止的区域（Forbidden Area）：一个由多个跟踪区（TA）组成的列表，UE被禁止进入这些区域。
-
服务区域限制（Service Area Restrictions）：规定UE只被允许在某些特定的TA列表内活动。
-
等效PLMN列表（Equivalent PLMNs）：这是漫游场景下非常重要的信息。它告诉gNB，除了当前服务的这个漫游地运营商网络，还有哪些其他运营商的网络，对于该UE来说是“等效”的，可以自由地进行切换和重选。
-
PNI-NPN移动性限制：
It may also include PNI-NPN mobility restrictions (i.e. list of CAGs allowed for the UE and whether the UE can also access non-CAG cells).
对于企业专网用户，这份信息会包含UE允许接入的CAG（闭合用户组）列表，以及一个关键的标志位——“CAG-only”，指示该UE是否只被允许接入CAG小区。
2. “签证”的传递与执行
这份“签证”是在UE首次接入网络，gNB与AMF建立UE上下文时，由AMF通过INITIAL CONTEXT SETUP REQUEST消息下发给gNB的。gNB收到后，会将其保存在UE的上下文中。
Upon receiving the roaming and access restriction information for a UE, if applicable, the gNB should use it to determine whether to apply restriction handling for subsequent mobility action, e.g., handover, redirection.
gNB在执行移动性管理时，必须参考这份“签证”：
场景代入： 小明（漫游用户）正在进行视频通话，他的手机向gNB上报了一份测量报告，显示邻近的一个LTE小区的信号非常好。
-
切换决策时的检查：gNB在决策是否要将小明切换到这个LTE小区之前，会检查小明上下文中的漫游限制信息。
-
如果信息中包含了“禁止接入E-UTRA”的条款，那么无论那个LTE小区的信号有多好，gNB都不会发起向该小区的切换。
-
如果信息中规定了服务区域限制，gNB会检查那个LTE小区的TAI是否在允许的区域内。
-
-
重定向时的检查：当gNB决定通过
RRCRelease消息将UE重定向到另一个频点或RAT时，同样需要遵循这些限制。
通过这种方式，gNB确保了其所有的移动性决策，都严格遵守了核心网下发的策略。
3. 切换过程中的“签证传递”
当UE从一个gNB切换到另一个gNB时，这份宝贵的“签证”也必须被一同传递下去。
Only if received over NG or Xn signalling, the roaming and access restriction information shall be propagated over Xn by the source gNB during Xn handover.
- Xn切换中的传递：在Xn切换中，源gNB会在
HANDOVER REQUEST消息中，将UE的漫游与接入限制信息，连同其他上下文，一并发送给目标gNB。目标gNB收到后，也会在本地保存这份信息，用于后续的移动性决策。
一个有趣的细节：等效PLMN列表的动态更新
If the Xn handover results in a change of serving PLMN (to an equivalent PLMN), the source gNB shall replace the serving PLMN with the identity of the target PLMN and move the serving PLMN to the equivalent PLMN list, before propagating the roaming and access restriction information.
这是一个非常精巧的设计。假设小明正在美国的运营商A网络中漫游，其EPLMN列表是[运营商B, 运营商C]。现在，他要从运营商A的一个基站，切换到运营商B的一个基站。
在准备HANDOVER REQUEST消息时，源gNB（属于A）会动态地更新小明的漫游信息：
-
将“
serving PLMN”字段，从运营商A，修改为运营商B。 -
将原来的“
serving PLMN”（运营商A），加入到“equivalent PLMN list”中。
这样，当目标gNB（属于B）收到这份上下文时，它看到的信息就是：“该UE正在我（B）的网络中服务，他的等效PLMN是[A, C]”。这个动态更新，确保了漫游信息在跨运营商切换过程中的一致性和正确性。
4. 兼容性挑战：协议版本不匹配
在实际网络中，不同厂商、不同区域的gNB，其支持的协议版本可能不同。如果一个老版本的gNB，无法识别新版本中增加的某些限制信息，该怎么办？
If NG-RAN nodes with different versions of the XnAP or NGAP protocol are deployed, information provided by the 5GC within the NGAP Mobility Restriction List may be lost… In order to avoid such loss of information… the source NG-RAN node or the old NG-RAN node may provide an 5GC Mobility Restriction List Container to the target NG-RAN node…
为了解决这个问题，3GPP引入了“容器（Container）”机制。
-
透明传递：当一个老版本的源gNB在准备切换时，如果它从AMF收到了一份它不认识或不完全认识的
Mobility Restriction List，它不会丢弃或修改它不认识的部分。相反，它可以将从AMF收到的原始的、完整的限制信息，原封不动地打包在一个“5GC Mobility Restriction List Container”中，通过Xn接口传递给目标gNB。 -
新节点解析：如果目标gNB是一个支持新版本的节点，它就可以打开这个“容器”，解析出完整的限制信息。对于容器中的信息与XnAP消息中明确承载的信息（如EPLMN）有冲突的部分，规范规定以XnAP中明确承载的为准。
这个“透明容器”机制，极大地增强了网络在协议演进过程中的前向兼容性，确保了关键的策略信息不会因为中间节点的版本老旧而丢失。
总结：保障策略落地的“最后一公里”
通过对9.4节的深入学习，我们理解了漫游与接入限制在5G移动性管理中扮演的“策略执行官”角色。
-
策略源于核心网：所有的漫游协议和接入限制策略，都由**核心网（AMF）**根据用户的签约信息和运营商间的协议来制定。
-
RAN是执行者：gNB是这些策略在连接态移动性中的最终执行者。它通过在切换、重定向等决策前，严格检查UE上下文中的限制信息，来确保策略的落地。
-
Xn接口是传递链：在RAN内部的移动过程中，Xn接口负责将这些限制信息可靠、一致地从一个gNB传递到下一个gNB。
-
兼容性设计是保障：通过“容器”等机制，确保了在版本不一的复杂网络环境中，策略信息传递的健壮性。
虽然9.4节篇幅不长，但它揭示了RAN与核心网在策略层面是如何紧密协同的。它提醒我们，RAN的移动性决策，不仅要考虑无线环境的好坏，还必须遵循来自核心网的“上层建筑”的约束。
至此，我们已经完成了对第9章移动性管理核心原理的全面学习。在下一篇文章中，我们将进入一个全新的篇章——第10章 调度（Scheduling），去探索gNB MAC层调度器的内心世界，看看它是如何做出每一个毫秒级的资源分配决策的。
FAQ
Q1：漫游与接入限制信息是在什么时候下发给gNB的？
A1：这份信息是在UE的上下文在gNB中建立时下发的。主要有两个场景：1）初始接入：当UE从IDLE状态发起连接，AMF在向gNB发送INITIAL CONTEXT SETUP REQUEST消息时，会包含这份信息。2）NG接口切换：当UE通过核心网，从另一个gNB切换过来时，AMF在向目标gNB发送HANDOVER REQUEST消息时，也会包含这份信息。一旦gNB获取了这份信息，它就会在后续该UE的所有移动性事件（如Xn切换）中，负责将其传递下去。
Q2：如果一个漫游用户被限制只能使用某些服务区（TA），当他移动到非服务区时会发生什么？
A2：这取决于UE所处的状态。
-
IDLE/INACTIVE状态：UE在小区重选时，会读取邻区的SIB1，获取其TAI。如果发现这个TAI不在其允许的服务区列表中，UE会认为这个小区是“不可接受的（unacceptable）”，即使信号再好，也不会驻留在该小区上。UE会继续搜索其他在允许区域内的小区。
-
CONNECTED状态：gNB在做切换决策时，会检查候选小区的TAI。如果发现目标小区的TAI在UE的禁止区域内，gNB就不会发起向该小区的切换。如果UE移动到了覆盖边缘，所有可切换的候选小区都不在允许区域内，gNB最终可能会选择**释放（Release）**该UE的RRC连接，让其返回IDLE状态，自行去寻找允许的网络。
Q3：等效PLMN（EPLMN）列表有什么用？
A3：EPLMN列表极大地优化了漫游用户的网络体验和网络的效率。在很多国家或地区，多个运营商可能属于同一个跨国集团，或者签订了深度的漫游共享协议。EPLMN列表就定义了这些“兄弟”运营商。当UE在一个运营商网络中漫游时，它可以将EPLMN列表中的其他运营商网络，视同自己的归属网络一样，进行无缝的小区重选和切换，而无需每次都重新进行耗时、耗资源的核心网附着和鉴权流程。这使得跨运营商的移动性变得像在同一个运营商网络内部一样“丝滑”。
Q4：PNI-NPN限制中的“CAG-only”标志位是什么意思？它如何影响UE的行为？
A4：“CAG-only”标志位是一个非常严格的限制。当一个UE的签约信息中包含这个标志位时，意味着这个UE是一个专网专用终端，它只被允许接入那些广播了其“允许CAG列表”中的CAG ID的小区。对于任何不广播CAG ID的普通公共小区，或者广播了其他CAG ID的小区，即使是自己归属运营商的，它都会将其视为“不可接受的”。这个标志位为需要最高级别接入隔离的企业专网（如工厂、港口），提供了一种强有力的保障，确保专网终端永远不会“误入”公共网络。
Q5：协议版本不匹配导致的信令丢失，在实际网络中常见吗？“容器”机制是唯一的解决方案吗？
A5：在大型运营商网络中，尤其是在网络升级的过渡阶段，不同区域、不同厂商的设备版本不一是非常常见的。“容器”机制是3GPP标准定义的、用于保证前向兼容性的优雅解决方案，它允许新定义的参数能够“穿透”老版本的节点。除了“容器”，网络运维中也会采用其他策略来应对，例如，在进行异构版本区域间的切换时，尽量采用更通用的、所有版本都支持的参数集；或者通过规划，限制UE在版本差异巨大的区域之间进行直接切换，而是引导其通过一个支持两种版本的“中间节点”进行过渡。但“容器”机制无疑是协议层面最高效、最标准的解决方案。