《5G核心网原理与实践》实践篇 · UDM 网元功能
作者：爱卫生
在5G核心网注册流程中，服务区域限制（Service Area Restriction）是AMF基于UDM签约数据进行接入控制的重要手段。在上一篇（第24篇）中，我们详细剖析了NOT_ALLOWED_AREAS（禁止区域/黑名单模式）导致注册拒绝的场景。本篇将聚焦另一种限制模式——ALLOWED_AREAS（允许区域/白名单模式）。
与黑名单模式"列出禁止区域，其余放行"的逻辑相反，白名单模式的逻辑是"只允许在列出的区域内活动，其余区域一律禁止"。这种模式在实际网络中有广泛的应用场景：
校园卡：学生的优惠终端限制在校内区域使用，出校后不再享受服务；
工厂内网：工业5G终端限制在厂区内使用，防止设备被带离后非法使用；
区域化套餐：某些本地套餐限制用户只能在特定城市范围内使用5G服务。
本测试的场景是：UDM中该用户的serviceAreaRestriction配置为ALLOWED_AREAS模式，允许的TAC列表为["000001","000002"]。UE从TAC=000001的小区发起注册（该TAC在允许列表中），AMF检查后确认区域合法，注册成功。
在深入信令分析之前，先通过一个对比表理解两种模式的核心区别：
| 对比维度 | ALLOWED_AREAS（白名单） | NOT_ALLOWED_AREAS（黑名单） |
|---|---|---|
| 限制模式 | 白名单——只允许列出的区域 | 黑名单——只禁止列出的区域 |
| 语义 | 列出的TAC=允许，其余=禁止 | 列出的TAC=禁止，其余=允许 |
| 默认行为 | 默认拒绝（除非在允许列表中） | 默认允许（除非在禁止列表中） |
| 适用场景 | 企业专网、校园卡、工厂内网 | 漫游限制、安全管控、区域管控 |
| 区域内注册 | 允许 | 拒绝 |
| 区域外注册 | 拒绝 | 允许 |
| 配置数量 | 通常配置少量允许区域 | 通常配置少量禁止区域 |
| 安全等级 | 较高（默认不允许） | 较低（默认允许） |
sequenceDiagram
participant UE
participant RAN as gNB_TAC000001
participant AMF
participant UDM
Note over UE, UDM: UE从允许区域(TAC=000001)发起注册
UE->>RAN: Registration Request
RAN->>AMF: N2 Message (Registration Request)<br/>携带TAC=000001
rect rgb(230, 245, 255)
Note over AMF, UDM: AMF与UDM交互
AMF->>UDM: Nudm_UECM_Registration (PUT)
UDM-->>AMF: 204 No Content
AMF->>UDM: Nudm_SDM_Get (GET)<br/>获取AM-Data
UDM-->>AMF: 200 OK + AmData<br/>含serviceAreaRestriction<br/>restrictionType: ALLOWED_AREAS<br/>tacs: ["000001","000002"]
end
Note over AMF: AMF检查serviceAreaRestriction<br/>restrictionType = ALLOWED_AREAS<br/>当前TAC=000001在允许列表中<br/>区域检查通过!
AMF->>UDM: Nudm_SDM_Subscribe (POST)<br/>订阅AM-Data变更通知
UDM-->>AMF: 201 Created
AMF-->>RAN: Registration Accept<br/>含Allowed TAC列表
RAN-->>UE: Registration Accept
flowchart TD
A["AMF收到UE Registration Request"] --> B["获取UE当前TAC"]
B --> C["AMF向UDM获取AM-Data"]
C --> D["检查serviceAreaRestriction字段"]
D --> E["restrictionType = ALLOWED_AREAS"]
E --> F["比对当前TAC与允许列表areas"]
F -->|"是: TAC在允许列表中"| G["区域检查通过, 继续正常注册流程"]
F -->|"否: TAC不在允许列表中"| H["AMF发送Registration Reject: 5GMM Cause #36"]
style G fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style H fill:#ffcdd2,stroke:#c62828,stroke-width:2px
验证当UDM中用户签约数据的serviceAreaRestriction配置为ALLOWED_AREAS模式，且UE当前所在TAC在允许区域列表中时，AMF能够正确识别该区域为允许区域，允许注册成功，并在Registration Accept消息中将允许区域信息下发给UE。
SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务。
UDM中该用户的AmData配置serviceAreaRestriction为ALLOWED_AREAS模式，允许TAC为["000001","000002"]。
测试终端位于TAC=000001的NR小区覆盖范围内。
服务化接口的信令监控、分析的工具准备就绪。
在UDM中为测试用户配置serviceAreaRestriction：
restrictionType: "ALLOWED_AREAS"
areas: [{"tacs":["000001","000002"]}]
UE在TAC=000001的小区发起5G注册请求。
Frame: 680 ~ 688
检查AMF与UDM之间的信令交互，以及AMF返回给UE的注册结果。
AMF向UDM发起Nudm_UECM_Registration注册成功，返回204 No Content。
AMF向UDM发起Nudm_SDM_Get获取AM-Data，UDM返回的签约数据中包含serviceAreaRestriction，restrictionType为ALLOWED_AREAS，areas中包含允许的TAC ["000001","000002"]。
AMF检测到UE当前TAC（000001）在允许区域列表中，区域检查通过。
AMF向UDM订阅AM-Data变更通知（Nudm_SDM_Subscribe）。
AMF向UE返回Registration Accept，携带允许区域信息。
注册成功。
在本测试中，注册流程顺利完成——因为UE恰好位于允许区域内。我们将完整跟踪从注册到成功的全过程，重点关注serviceAreaRestriction（ALLOWED_AREAS模式）的处理逻辑。
（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP等敏感信息已做严格脱敏处理）
AMF收到UE从TAC=000001小区发来的Registration Request后，首先向UDM发起AMF注册。这一步与正常注册流程完全一致。
sequenceDiagram
participant AMF
participant UDM
Note over AMF, UDM: Nudm_UECM_Registration
AMF->>UDM: PUT /nudm-uecm/v1/imsi-460XX00000XXXX<br/>/registrations/amf-3gpp-access
Note right of AMF: 请求体携带：<br/>amfInstanceId<br/>guami<br/>ratType: NR
UDM-->>AMF: 204 No Content
Note left of UDM: UDM记录AMF注册信息
信令抓包解析：
# 1. AMF -> UDM（AMF注册 PUT请求）
Frame: 680
HEADERS[11]: PUT /nudm-uecm/v1/imsi-460XX00000XXXX/registrations/amf-3gpp-access
JavaScript Object Notation: application/json
Object
Member Key: amfInstanceId
String value: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
# AMF的NF Instance ID
Member Key: guami
Object
Member Key: plmnId
Object
Member Key: mcc
String value: "460"
Member Key: mnc
String value: "XX"
Member Key: amfId
String value: "XXXXXX"
Member Key: ratType
String value: "NR"
# 当前接入类型为NR
Member Key: accessType
String value: "3GPP_ACCESS"
# 2. UDM -> AMF（注册成功响应）
HEADERS[3]: 204 No Content
# AMF注册成功
AMF注册成功后，向UDM获取AM-Data。这一步返回的serviceAreaRestriction包含了ALLOWED_AREAS配置。
sequenceDiagram
participant AMF
participant UDM
Note over AMF, UDM: Nudm_SDM_Get - 获取AM-Data
AMF->>UDM: GET /nudm-sdm/v1/imsi-460XX00000XXXX<br/>/am-data
UDM-->>AMF: 200 OK
Note left of UDM: 响应体含AmData:<br/>serviceAreaRestriction<br/>restrictionType: ALLOWED_AREAS<br/>areas含允许TAC列表
信令抓包解析：
# 3. AMF -> UDM（获取AM签约数据 GET请求）
Frame: 680
HEADERS[5]: GET /nudm-sdm/v1/imsi-460XX00000XXXX/am-data
# 请求方法: GET
# 资源类型: am-data
# 4. UDM -> AMF（返回AM签约数据）
Frame: 686
HEADERS[3]: 200 OK
JavaScript Object Notation: application/json
Object
# ===== 必选参数 =====
# --- 签约UE聚合最大比特速率 ---
Member Key: subscribedUeAmbr
Object
Member Key: uplink
String value: "1000000000"
# 上行速率: 1 Gbps
Member Key: downlink
String value: "2000000000"
# 下行速率: 2 Gbps
# --- 签约网络切片标识 ---
Member Key: nssai
Object
Member Key: singleNssais
Array
Object
Member Key: sst
Number value: 1
# SST=1 eMBB切片
Member Key: sd
String value: "000001"
Member Key: defaultSingleNssais
Array
Object
Member Key: sst
Number value: 1
Member Key: sd
String value: "000001"
# --- RFSP索引 ---
Member Key: rfspIndex
Number value: 10
# --- 签约注册周期定时器 ---
Member Key: subsRegTimer
Number value: 36000
# ===== 关键参数：服务区域限制（允许区域/白名单模式） =====
# 服务区域限制（允许区域/白名单模式）
Member Key: serviceAreaRestriction
Object
Member Key: restrictionType
String value: "ALLOWED_AREAS"
# 限制类型: 允许区域（白名单模式）
# 含义: areas列表中列出的区域为允许区域
# 只有在允许区域列表中的TAC才能注册
# 不在列表中的TAC将被拒绝
Member Key: areas
Array
Object
Member Key: tacs
Array
String value: "000001"
String value: "000002"
# 允许的TAC列表
# 只有TAC=000001和TAC=000002为允许区域
# 其他任何TAC都将被拒绝注册
# --- GPSI列表 ---
Member Key: gpsis
Array
String value: "msisdn-86XXXXXXXXXXX"
关键发现：serviceAreaRestriction配置了ALLOWED_AREAS
在这个响应中，serviceAreaRestriction.restrictionType为"ALLOWED_AREAS"，且areas数组中包含：
允许的TAC列表：["000001", "000002"]
未配置plmns字段（表示适用于当前PLMN）
这意味着该用户只能在TAC为000001和000002的区域内注册。如果UE移动到其他TAC区域（如000003、000004），注册将被拒绝。
AMF获取到AM-Data后，执行区域限制检查。
AMF的允许区域判断逻辑：
1. 从N2消息中获取UE当前TAC → 000001
2. 从AM-Data中读取serviceAreaRestriction
→ restrictionType = "ALLOWED_AREAS"
→ areas[0].tacs = ["000001", "000002"]
3. 检查模式: ALLOWED_AREAS（白名单模式）
→ 逻辑: 只有在允许列表中的TAC才能注册
4. 遍历areas列表，检查当前TAC是否在tacs中:
- areas[0].tacs: ["000001", "000002"]
- 当前TAC "000001" → 在列表中找到匹配
5. 结果: 当前TAC在允许区域列表中 → 区域检查通过
6. 动作: 继续正常注册流程
ALLOWED_AREAS vs NOT_ALLOWED_AREAS的判断逻辑差异：
| 判断步骤 | ALLOWED_AREAS | NOT_ALLOWED_AREAS |
|---|---|---|
| 读取restrictionType | ALLOWED_AREAS | NOT_ALLOWED_AREAS |
| 匹配到areas中的TAC | 区域检查通过 | 区域检查失败 |
|---|---|---|
| 未匹配到areas中的TAC | 区域检查失败 | 区域检查通过 |
| 本例结果（TAC=000001在列表中） | 通过，注册成功 | 失败，注册拒绝 |
| 用户无法注册 | 检查TAC是否不在允许列表中 | 检查TAC是否在禁止列表中 |
| 修正方法 | 将用户TAC加入允许列表 | 将用户TAC从禁止列表移除 |
|---|---|---|
| 扩大服务范围 | 增加允许TAC | 减少禁止TAC |
| 缩小服务范围 | 减少允许TAC | 增加禁止TAC |
将上述步骤串联起来，AMF在注册流程中处理ALLOWED_AREAS的完整决策链如下：
flowchart TD
A["UE从TAC=000001发起Registration Request"] --> B["AMF向UDM注册: Nudm_UECM_Registration"]
B -->|"204 成功"| C["AMF获取AM-Data: Nudm_SDM_Get"]
B -->|"失败"| FAIL1["注册失败: UDM不可达"]
C -->|"200 OK"| D["AMF检查ratRestrictions"]
C -->|"失败"| FAIL2["注册失败: 无法获取签约数据"]
D -->|"RAT未被限制"| E["AMF检查serviceAreaRestriction"]
D -->|"RAT被限制"| FAIL3["注册拒绝: RAT不允许"]
E --> F["restrictionType = ALLOWED_AREAS"]
F --> G["比对当前TAC=000001与允许列表"]
G -->|"是: TAC在允许列表中"| H["区域检查通过"]
G -->|"否: TAC不在允许列表中"| FAIL4["注册拒绝: 区域不允许"]
H --> I["AMF订阅AM-Data变更: Nudm_SDM_Subscribe"]
I -->|"201 Created"| J["AMF发送Registration Accept: 携带Allowed Area List"]
J --> K["注册成功! UE可以在允许区域内正常使用"]
style K fill:#c8e6c9,stroke:#2e7d32,stroke-width:3px
style FAIL1 fill:#ffcdd2,stroke:#c62828
style FAIL2 fill:#ffcdd2,stroke:#c62828
style FAIL3 fill:#ffcdd2,stroke:#c62828
style FAIL4 fill:#ffcdd2,stroke:#c62828
值得关注的技术细节：
1) 白名单模式的"默认拒绝"语义
ALLOWED_AREAS模式的核心特征是"默认拒绝"——如果UE的当前TAC不在允许列表中，AMF将拒绝注册。这与传统的"默认允许"思维不同。在设计网络策略时，运维人员需要确保允许列表覆盖了用户所有可能活动的区域，否则可能导致合法用户被误拒绝。
2) 允许区域信息下发给UE
在白名单模式下，AMF会在Registration Accept消息中将允许区域信息下发给UE。这是非常重要的一个设计决策：
UE收到允许区域列表后，会将其存储在本地；
当UE移动到新小区时，可以快速判断新TAC是否在允许列表中；
如果新TAC不在允许列表中，UE可以避免发起不必要的注册请求，减少空口信令开销。
3) 最大TAC数量限制
根据3GPP规范，serviceAreaRestriction中的TAC列表有数量限制。对于ALLOWED_AREAS模式，areas中所有tacs数组的TAC总数不应超过16个（具体限制取决于网络设备实现）。如果需要覆盖更大的区域，应考虑使用NOT_ALLOWED_AREAS模式代替。
4) 区域限制的动态更新
通过Nudm_SDM_Subscribe订阅机制，AMF可以实时感知serviceAreaRestriction的变更。例如：
企业搬迁后，运营商更新允许TAC列表 → AMF收到变更通知 → 更新本地区域策略；
校园扩建后，新增覆盖区域的TAC → 运营商在BOSS系统中添加 → AMF实时生效。
这种动态更新机制确保了服务区域限制策略的灵活性，无需用户重新注册即可生效。
5) 与4G EPS中Equivalent PLMN的关系
在4G EPS中，区域限制主要通过"Forbidden Tracking Area"和"Equivalent PLMN"实现，但缺少白名单模式。5GC引入了restrictionType字段，明确支持ALLOWED_AREAS和NOT_ALLOWED_AREAS两种模式，提供了更精细的区域控制能力。这是5GC相比EPC在移动性管理方面的一个重要改进。
| 验证项 | 结果 | 说明 |
|---|---|---|
| AMF注册成功 | OK | Nudm_UECM_Registration返回204 No Content |
| AMF获取AM-Data成功 | OK | Nudm_SDM_Get返回200 OK |
| UDM正确返回serviceAreaRestriction | OK | restrictionType: ALLOWED_AREAS, TAC: ["000001","000002"] |
| AMF正确检测允许区域 | OK | 当前TAC=000001在允许列表中，区域检查通过 |
| AMF订阅数据变更 | OK | Nudm_SDM_Subscribe返回201 Created |
| 注册成功 | OK | Registration Accept携带Allowed Area List |
| 信令流程与协议一致 | OK | 与3GPP TS 29.503和TS 23.502规范吻合 |
本测试用例验证了服务区域限制（ALLOWED_AREAS/白名单模式）下的注册成功流程。当UDM中用户的serviceAreaRestriction配置为ALLOWED_AREAS模式，且UE当前所在的TAC在允许区域列表中时，AMF能够正确识别该区域为允许区域，允许注册成功，并在Registration Accept消息中将允许区域信息下发给UE。
关键知识点回顾：
通过本篇（第25篇）和第24篇的对比学习，读者应掌握以下核心知识：
两种区域限制模式：NOT_ALLOWED_AREAS（黑名单，默认允许）和ALLOWED_AREAS（白名单，默认拒绝）；
判断逻辑相反：同一个TAC，在黑名单模式下匹配=拒绝，在白名单模式下匹配=允许；
应用场景不同：黑名单适合"禁止少量区域"，白名单适合"限制在少量区域"；
数据变更实时生效：通过SDM订阅机制，区域限制策略的修改可以实时推送到AMF。
这三篇文章（第23篇RAT限制、第24篇禁止区域限制、第25篇允许区域限制）共同构成了5GC中基于UDM签约数据的接入控制全景。掌握这些知识，对于理解5G核心网的注册流程和排障实践具有重要意义。
作者简介：爱卫生，通信教育老兵（18年教龄），出版《5G核心网原理与实践》等4本著作。在51学通信知识星球持续分享5GC/IMS/云原生核心网技术，包含200+小时视频课程和3000+篇技术精华帖。
学5G核心网、IMS，来51学通信就对了！公众号/知识星球：51学通信，微信：gprshome201101