5GC实践篇之UDM篇第24篇：禁止区域限制导致注册拒绝

校园卡/企业专网：限制终端只能在特定区域使用，超出区域则拒绝服务；
漫游管控：禁止用户在特定区域（如边境区域、竞对强覆盖区域）注册；
安全管控：对特殊用户（如丢失设备的远程锁定）实时禁止其接入特定区域；
物联网区域控制：限制智能终端只能在部署区域内工作。

禁止区域限制的数据结构

在深入信令分析之前，我们先理解forbiddenAreas的数据结构。forbiddenAreas并不是一个独立的字段，而是serviceAreaRestriction中restrictionType为NOT_ALLOWED_AREAS时的areas列表。

JSON数据结构示例：


{

  "serviceAreaRestriction": {

    "restrictionType": "NOT_ALLOWED_AREAS",

    "areas": [

      {

        "tacs": ["000003", "000004"],

        "plmns": [

          {

            "mcc": "460",

            "mnc": "88"

          }

        ]

      }

    ]

  }

}

字段含义解读：

字段	含义

`restrictionType: NOT_ALLOWED_AREAS`	黑名单模式——列出的区域为禁止区域
`areas[].tacs`	被禁止的跟踪区域码（TAC）列表
`areas[].plmns`	所属PLMN标识列表（MCC+MNC）

当AMF收到这份签约数据后，会将UE当前所在小区的TAC与forbiddenAreas中的TAC列表逐一比对。如果匹配，则拒绝注册。

禁止区域限制导致注册拒绝的完整信令流程


sequenceDiagram

    participant UE

    participant RAN as gNB_TAC000003

    participant AMF

    participant UDM

    Note over UE, UDM: UE从禁止区域(TAC=000003)发起注册

    UE->>RAN: Registration Request

    RAN->>AMF: N2 Message (Registration Request)<br/>携带TAC=000003

    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/>含forbiddenAreas<br/>TAC=["000003","000004"]

    end

    Note over AMF: AMF检查serviceAreaRestriction<br/>restrictionType=NOT_ALLOWED_AREAS<br/>当前TAC=000003在禁止列表中<br/>判定为禁止区域!

    AMF-->>RAN: Registration Reject<br/>5GMM Cause: 36

    RAN-->>UE: Registration Reject

禁止区域判断逻辑


flowchart TD

    A["AMF收到UE Registration Request"] --> B["获取UE当前TAC"]

    B --> C["AMF向UDM获取AM-Data"]

    C --> D["检查serviceAreaRestriction字段"]

    D --> E["restrictionType = NOT_ALLOWED_AREAS"]

    E --> F["比对当前TAC与areas禁止列表"]

    F -->|"是: TAC在禁止列表中"| G["AMF发送Registration Reject: 5GMM Cause #36, 携带退避定时器"]

    F -->|"否: TAC不在禁止列表中"| H["继续正常注册流程"]

    style G fill:#ffcdd2,stroke:#c62828,stroke-width:3px

    style H fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

测试目的

验证当UDM中用户签约数据包含forbiddenAreas（NOT_ALLOWED_AREAS模式的serviceAreaRestriction），且UE当前所在TAC在禁止区域列表中时，AMF能够正确检测到该限制，并向UE返回Registration Reject消息。

测试前置条件

SA网络中各网元系统及操作维护台运行正常。
终端和网络连接正常。
UE在UDM开户，签约5G业务。
UDM中该用户的AmData配置serviceAreaRestriction为NOT_ALLOWED_AREAS模式，禁止TAC为["000003","000004"]，PLMN为MCC=460/MNC=88。
测试终端位于TAC=000003的NR小区覆盖范围内。
服务化接口的信令监控、分析的工具准备就绪。

测试步骤

在UDM中为测试用户配置serviceAreaRestriction：
restrictionType: "NOT_ALLOWED_AREAS"
areas: [{"tacs":["000003","000004"],"plmns":[{"mcc":"460","mnc":"88"}]}]
UE在TAC=000003的小区发起5G注册请求。
Frame: 62308 ~ 62324
检查AMF与UDM之间的信令交互，以及AMF返回给UE的注册结果。

测试结果验证（预期）

AMF向UDM发起Nudm_UECM_Registration注册成功，返回204 No Content。
AMF向UDM发起Nudm_SDM_Get获取AM-Data，UDM返回的签约数据中包含serviceAreaRestriction，restrictionType为NOT_ALLOWED_AREAS，areas中包含TAC ["000003","000004"]。
AMF检测到UE当前TAC（000003）在禁止区域列表中，判定为禁止区域。
AMF向UE返回Registration Reject，携带适当的5GMM拒绝原因值和退避定时器。

2 信令深度解析

在本测试中，整个注册流程因forbiddenAreas限制而被中断。与第23篇的RAT限制不同，禁止区域限制是基于UE地理位置（TAC）的判断——即使RAT类型没有问题，只要UE出现在被禁止的跟踪区域中，注册就会被拒绝。

（注：为保护网络安全，以下log中的SUPI/IMSI标识、网元IP等敏感信息已做严格脱敏处理）

2.1 AMF向UDM注册（Nudm_UECM_Registration）

与正常注册流程一致，AMF在收到UE的Registration Request后，首先向UDM发起AMF注册。注意请求中携带了UE当前的位置信息（TAC），这些信息在后续的区域限制判断中至关重要。


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<br/>支持3GPP接入

    UDM-->>AMF: 204 No Content

    Note left of UDM: UDM记录AMF注册信息

信令抓包解析：


# 1. AMF -> UDM（AMF注册 PUT请求）

Frame: 62308

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（RAT未被限制）

    Member Key: accessType

      String value: "3GPP_ACCESS"

# 2. UDM -> AMF（注册成功响应）

HEADERS[3]: 204 No Content

# AMF注册成功

注意：在AMF注册请求中，ratType为"NR"，这意味着RAT接入限制不会触发拒绝（因为用户的ratRestrictions中没有"NR"）。但区域限制的检查将在下一步进行。

2.2 AMF获取签约数据（Nudm_SDM_Get）

AMF注册成功后，向UDM获取AM-Data。这一步返回的serviceAreaRestriction包含了forbiddenAreas信息，是触发注册拒绝的关键。


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

    Note right of AMF: HTTP GET请求<br/>资源路径: /am-data

    UDM-->>AMF: 200 OK

    Note left of UDM: 响应体含AmData:<br/>serviceAreaRestriction<br/>restrictionType: NOT_ALLOWED_AREAS<br/>areas含禁止TAC列表

信令抓包解析：


# 3. AMF -> UDM（获取AM签约数据 GET请求）

Frame: 62308

HEADERS[5]: GET /nudm-sdm/v1/imsi-460XX00000XXXX/am-data

# 请求方法: GET

# 资源类型: am-data（Access and Mobility Management Data）

# 4. UDM -> AMF（返回AM签约数据）

Frame: 62324

HEADERS[3]: 200 OK

JavaScript Object Notation: application/json

  Object

    # ===== 必选参数 =====

    # --- 签约UE聚合最大比特速率 ---

    Member Key: subscribedUeAmbr

      Object

        Member Key: uplink

          String value: "500000000"

          # 上行速率: 500 Mbps

        Member Key: downlink

          String value: "1000000000"

          # 下行速率: 1 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: "NOT_ALLOWED_AREAS"

          #  限制类型: 禁止区域（黑名单模式）

          # 含义: areas列表中列出的区域为禁止区域

          # UE不允许在这些区域内注册

        Member Key: areas

          Array

            Object

              Member Key: tacs

                Array

                  String value: "000003"

                  String value: "000004"

                  #  被禁止的TAC列表

                  # TAC=000003 和 TAC=000004 为禁止区域

              Member Key: plmns

                Array

                  Object

                    Member Key: mcc

                      String value: "460"

                    Member Key: mnc

                      String value: "88"

                      # 禁止区域适用的PLMN: MCC=460, MNC=88

    # --- RAT接入限制（本例未配置）---

    # 注意: 本例中ratRestrictions未配置或为空

    # 即RAT不做限制，但区域有限制

    # --- GPSI列表 ---

    Member Key: gpsis

      Array

        String value: "msisdn-86XXXXXXXXXXX"

关键发现：serviceAreaRestriction配置了NOT_ALLOWED_AREAS

在这个响应中，serviceAreaRestriction.restrictionType为"NOT_ALLOWED_AREAS"，且areas数组中包含了一个区域配置：

禁止的TAC列表：["000003", "000004"]
适用的PLMN：MCC=460, MNC=88

这意味着在该PLMN下，TAC为000003和000004的区域为禁止区域。UE如果从这些区域发起注册，将被拒绝。

2.3 AMF执行禁止区域检查

AMF获取到AM-Data后，需要执行区域限制检查。AMF已知UE当前的位置信息（从N2消息中获取），可以提取出当前小区的TAC值。

AMF的禁止区域判断逻辑：


1. 从N2消息中获取UE当前所在小区的TAC → 000003

2. 从AM-Data中读取serviceAreaRestriction

   → restrictionType = "NOT_ALLOWED_AREAS"

   → areas[0].tacs = ["000003", "000004"]

   → areas[0].plmns = [{"mcc":"460","mnc":"88"}]

3. 检查当前PLMN是否匹配: MCC=460, MNC=88 → 匹配

4. 遍历areas列表，检查当前TAC是否在tacs中:

   - areas[0].tacs: ["000003", "000004"]

   - 当前TAC "000003" → 在列表中找到匹配

5. 结果: 当前TAC在禁止区域列表中 → 判定为禁止区域

6. 动作: AMF决定拒绝注册

forbiddenAreas字段的协议定义：

属性	说明
所属字段	serviceAreaRestriction
限制类型	restrictionType = "NOT_ALLOWED_AREAS"
数据类型	对象，含restrictionType和areas数组
areas元素	包含tacs（TAC数组）和plmns（PLMN数组）
语义	areas中列出的TAC为该用户禁止活动的区域
来源	3GPP TS 29.503 第5.3.2.2.2节

协议参考：根据3GPP TS 29.503 第5.3.2.2.2节，serviceAreaRestriction字段定义在AccessAndMobilitySubscriptionData数据结构中。当restrictionType为NOT_ALLOWED_AREAS时，areas列表中的所有TAC均为禁止区域。AMF在注册流程中必须检查UE当前TAC是否在禁止区域列表中，如果匹配则按照3GPP TS 23.502第4.2.2.3.2节的规定拒绝注册。

forbiddenAreas的JSON结构详解：


{

  "serviceAreaRestriction": {

    "restrictionType": "NOT_ALLOWED_AREAS",

    "areas": [

      {

        "tacs": ["000003", "000004"],

        "plmns": [

          {

            "mcc": "460",

            "mnc": "88"

          }

        ]

      }

    ]

  }

}

层级	字段	说明
第1层	serviceAreaRestriction	服务区域限制顶层对象
第2层	restrictionType	值为"NOT_ALLOWED_AREAS"表示黑名单模式
第2层	areas	区域列表数组，可包含多个区域配置
第3层	tacs	被禁止的TAC列表（字符串数组）
第3层	plmns	适用的PLMN列表（对象数组，含mcc和mnc）

2.4 AMF返回Registration Reject

AMF确认UE当前TAC在forbiddenAreas列表中后，向UE返回Registration Reject消息。


sequenceDiagram

    participant AMF

    participant RAN as gNB_TAC000003

    participant UE

    Note over AMF, UE: 禁止区域触发注册拒绝

    AMF->>RAN: Registration Reject<br/>5GMM Cause: 36

    Note right of AMF: 拒绝原因值: #36<br/>携帯退避定时器

    RAN->>UE: Registration Reject

    Note left of UE: UE收到拒绝后:<br/>1. 启动退避定时器<br/>2. 在定时器超时前不重试

信令抓包解析：


# 5. AMF -> UE（Registration Reject）

Frame: 62324

NAS-5GS Message: Registration Reject

  Protocol Discriminator: 5GS Mobility Management (0x7)

  Security Header Type: 0 (No Security)

  Message Type: Registration Reject (0x44)

  # --- 5GMM Cause ---

  Member Key: 5GMM Cause

    Value: 36 (Backoff timer)

    #  注册拒绝原因: #36

    # 需要等待退避定时器超时后再尝试注册

  # --- T3346 Value ---

  Member Key: T3346Value

    Value: 300 (seconds)

    #  退避定时器: 300秒 = 5分钟

    # UE在此期间不应尝试注册

禁止区域拒绝的原因值选择：

与RAT限制不同，禁止区域限制通常使用5GMM Cause #36（Backoff timer）而非#39（PLMN not allowed）。原因是：禁止区域是一种临时性限制——如果UE移动到非禁止区域，应该能够正常注册。使用退避定时器而非"PLMN不可用"的语义更加准确。

场景	常用原因值	语义
RAT限制	#39 PLMN not allowed	该PLMN不允许接入（较永久）
禁止区域	#36 Backoff timer	暂时不可用，等退避后可重试
核心网类型限制	#7 5GS services not allowed	5GS服务不被允许

2.5 【硬核附加】用curl模拟查询forbiddenAreas

在实际排障中，如果怀疑用户因禁止区域限制导致注册失败，可以直接查询UDM中的签约数据：


curl -i -X GET http://10.XX.XX.XX:31381/nudm-sdm/v1/imsi-460XX00000XXXX/am-data

UDM返回的JSON响应（关键字段）：


{

  "gpsis": [

    "msisdn-86XXXXXXXXXXX"

  ],

  "subscribedUeAmbr": {

    "uplink": "500000000",

    "downlink": "1000000000"

  },

  "nssai": {

    "singleNssais": [

      {

        "sst": 1,

        "sd": "000001"

      }

    ],

    "defaultSingleNssais": [

      {

        "sst": 1,

        "sd": "000001"

      }

    ]

  },

  "rfspIndex": 10,

  "subsRegTimer": 36000,

  "serviceAreaRestriction": {

    "restrictionType": "NOT_ALLOWED_AREAS",

    "areas": [

      {

        "tacs": [

          "000003",

          "000004"

        ],

        "plmns": [

          {

            "mcc": "460",

            "mnc": "88"

          }

        ]

      }

    ]

  }

}

禁止区域排障快速指南：

步骤	操作	说明
1	确认UE当前TAC	从N2消息或小区信息中获取
2	查询UDM的serviceAreaRestriction	使用curl或网管系统
3	检查restrictionType	确认为NOT_ALLOWED_AREAS
4	比对TAC	当前TAC是否在areas[].tacs中
5	修正配置	移除误配的TAC或调整区域限制策略

禁止区域 vs 允许区域的区别预览：

对比项	NOT_ALLOWED_AREAS（本篇）	ALLOWED_AREAS（下篇）
限制模式	黑名单	白名单
语义	列出的区域禁止，其余允许	列出的区域允许，其余禁止
适用场景	漫游限制、安全管控	企业专网、校园卡
区域外行为	区域外可以正常注册	区域外注册被拒绝
配置灵活性	适合禁止少量区域	适合限制在少量区域

2.6 禁止区域限制的完整决策链

将上述步骤串联起来，AMF在注册流程中处理forbiddenAreas的完整决策链如下：


flowchart TD

    A["UE从TAC=000003发起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 = NOT_ALLOWED_AREAS"]

    F --> G["比对当前TAC=000003与禁止列表"]

    G -->|"是: TAC被禁止"| H["AMF发送Registration Reject: 5GMM Cause #36, 退避300秒"]

    G -->|"否: TAC未被禁止"| I["继续正常注册流程"]

    style H fill:#ffcdd2,stroke:#c62828,stroke-width:3px

    style I fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px

    style FAIL1 fill:#ffcdd2,stroke:#c62828

    style FAIL2 fill:#ffcdd2,stroke:#c62828

    style FAIL3 fill:#ffcdd2,stroke:#c62828

值得关注的技术细节：

1) 禁止区域检查的优先级

在AMF的接入控制检查链中，RAT限制检查通常在区域限制检查之前执行。即：

先检查ratRestrictions（RAT是否被限制）；
再检查serviceAreaRestriction（区域是否被限制）；
最后执行切片选择等其他逻辑。

这种顺序设计是合理的——RAT限制是"大颗粒度"的检查（只区分NR/EUTRA等），而区域限制是"小颗粒度"的检查（精确到TAC级别）。先执行大颗粒度检查可以尽早过滤掉明显不合法的请求。

2) 多区域配置的处理

areas是一个数组，可以包含多个区域配置。每个区域配置可以有独立的tacs列表和plmns列表。AMF需要逐一检查所有区域配置：


配置示例（多个禁止区域）:

{

  "areas": [

    {

      "tacs": ["000003", "000004"],

      "plmns": [{"mcc": "460", "mnc": "88"}]

    },

    {

      "tacs": ["000010", "000011", "000012"],

      "plmns": [{"mcc": "460", "mnc": "00"}]

    }

  ]

}

AMF的逻辑是：对于每个区域配置，先检查当前PLMN是否匹配，如果匹配再检查TAC是否在禁止列表中。只要任何一个区域配置匹配成功，就判定为禁止区域。

3) PLMN匹配的重要性

forbiddenAreas中的plmns字段指定了该禁止区域配置适用的PLMN。这意味着同一个禁止区域配置可以跨PLMN生效。例如，如果配置了两个PLMN（MCC=460/MNC=88 和 MCC=460/MNC=00），则该禁止TAC列表在这两个PLMN下都生效。

4) 与4G EPS中Forbidden Tracking Area的关系

在4G EPS中，MME也维护一个"Forbidden Tracking Area List"，但其数据来源和更新机制与5GC有所不同。5GC中，forbiddenAreas直接来自UDM的签约数据，而4G中通常由OSS配置或通过SGs接口更新。5GC的做法更加灵活，支持通过SDM订阅机制实时更新区域限制策略。

3 测试结论

验证项	结果	说明
AMF注册成功	OK	Nudm_UECM_Registration返回204 No Content
AMF获取AM-Data成功	OK	Nudm_SDM_Get返回200 OK
UDM正确返回forbiddenAreas	OK	restrictionType: NOT_ALLOWED_AREAS, TAC: ["000003","000004"], PLMN: MCC=460/MNC=88
AMF正确检测区域限制	OK	当前TAC=000003在禁止列表中
AMF返回Registration Reject	OK	5GMM Cause #36，携带T3346退避定时器
信令流程与协议一致	OK	与3GPP TS 29.503和TS 23.502规范吻合

本测试用例验证了禁止区域限制（forbiddenAreas）导致注册拒绝的完整流程。当UDM中用户的serviceAreaRestriction配置为NOT_ALLOWED_AREAS模式，且UE当前所在的TAC在禁止区域列表中时，AMF能够在获取签约数据后正确检测到该限制，并按照3GPP TS 23.502第4.2.2.3.2节的规定，向UE返回Registration Reject消息。

排障建议：在实际网络运维中，如果用户投诉"在某个区域无法注册5G网络"，排障步骤应包括：

确认用户所在位置对应的TAC值；
查询UDM中的serviceAreaRestriction配置；
检查restrictionType是否为NOT_ALLOWED_AREAS；
比对用户当前TAC是否在禁止区域列表中；
如果是误配，修正UDM中的区域限制配置。

与第25篇的关系：本篇讲解的是NOT_ALLOWED_AREAS（黑名单模式），下一篇将讲解ALLOWED_AREAS（白名单模式）。两种模式虽然都通过serviceAreaRestriction字段配置，但语义和处理逻辑完全不同，建议对照阅读。

作者：爱卫生（18年通信教学经验，4本专业书籍作者）

学5G核心网、IMS，来51学通信就对了！知识星球：200+小时视频 · 3000+精华文章 · 1年答疑群

本文为《5G核心网原理与实践》实践篇之UDM系列。欢迎转发分享，转载请联系作者。

5GC实践篇之UDM篇第24篇：禁止区域限制导致注册拒绝

5GC实践篇之UDM篇第24篇：禁止区域限制导致注册拒绝

1 测试背景与用例简介

禁止区域限制的数据结构

禁止区域限制导致注册拒绝的完整信令流程

禁止区域判断逻辑

测试目的

测试前置条件

测试步骤

测试结果验证（预期）

2 信令深度解析

2.1 AMF向UDM注册（Nudm_UECM_Registration）

2.2 AMF获取签约数据（Nudm_SDM_Get）

2.3 AMF执行禁止区域检查

2.4 AMF返回Registration Reject

2.5 【硬核附加】用curl模拟查询forbiddenAreas

2.6 禁止区域限制的完整决策链

3 测试结论

查看完整内容