手机满格信号，却显示"仅限紧急呼叫"，电话打不出、数据上不去，换个街区又好了。这不是手机坏了，也不一定是无线信号问题——大多数时候，是手机和核心网之间的一次"对话"失败了。本文以一起典型的注册失败故障（多起同类故障的脱敏复合复盘，参数为示例值，信令行为均以3GPP标准为准）为线索，把5G注册流程、NAS拒绝原因值、信令追踪工具链完整过一遍，回答一个运维最常遇到的问题：接入类投诉，到底该怎么查？
本文的解读主轴锚定3GPP官方标准 TS 24.501（5G移动性管理与NAS消息，5GMM原因值的唯一权威出处），辅以 TS 23.122（小区选择）、TS 38.413（NGAP信令）和 TS 32.421/32.423（信令追踪）。
今年8月一个周二上午九点半，华东某地市无线维护班的投诉工单开始堆积。投诉集中在一个开发区与老城区交界的片区，口径高度一致：手机信号满格，屏幕左上角却写着"仅限紧急呼叫"，微信发不出去，电话拨不出。
值班工程师的第一反应是基站退服——"仅限紧急呼叫"最常见的原因就是周边无可用小区。但网管一看就排除了：该片区12个基站全部在线，无告警、无退服，小区级KPI一切正常。更蹊跷的是投诉的时间分布：早晚通勤时段密集，上午十点后逐渐减少；用户移动轨迹回放显示，出问题的都是在两片覆盖区之间穿越的人，一直待在老城区的用户完全正常。
典型的"移动才坏、驻留不坏"，这基本排除了信号覆盖问题。手机满格说明小区选择没有障碍，问题大概率出在小区选择之后的环节——注册。手机要能打电话上网，光"驻留"上一个小区还不够，还得向核心网完成注册，拿到5G-GUTI（临时身份）和注册区。驻留是"进了城"，注册才是"办了暂住证"。
第一步动作不是抓包，而是看网管KPI：按TAC（跟踪区码）下钻AMF的注册成功率——这是3GPP TS 28.552里定义的标准网络性能指标。数据显示，该片区某个TAC的注册成功率从常态的99.5%掉到了42%，而相邻TAC一切正常。再下钻一层看拒绝原因值分布：该TAC下81%的注册请求被拒绝，拒绝消息里带的原因值是同一个——5GMM cause #15。
原因值，就是核心网给手机开的"死因鉴定书"。看到#15，排查方向基本就定了。
要理解#15为什么指向"TAC"，得先看一遍注册流程。5G开机注册（Initial Registration）是NAS层（非接入层）的第一场大考，简化后的消息流如下：
sequenceDiagram
participant U as 手机
participant B as 基站
participant C as AMF
U->>B: 无线接入加注册请求
B->>C: NGAP初始UE消息
C-->>C: 校验TAI与签约
C->>B: 注册拒绝原因值15
B->>U: 转发拒绝消息
Note over U: 进入仅限紧急呼叫
拆开看，每一关都可能成为故障点：
第一关：小区选择。 手机开机后扫频，按S准则选一个信号合格的小区驻留。注意，这一步只看无线条件和PLMN，不看TAC归属——手机并不知道也不关心这个小区的TAC在核心网那边有没有"户口"。这一点是本案的关键伏笔。
第二关：RRC建立与NAS透传。 手机在RRC Setup Complete里捎上NAS Registration Request（注册请求），基站把它封装进NGAP的Initial UE Message，通过N2接口交给AMF。消息里带着手机的临时标识5G-S-TMSI（或完整SUPI）、最后访问的注册TAI、请求的网络切片等信息。
第三关：核心网校验。 AMF收到注册请求后开始逐项核对：鉴权（跟UDM/AUSF要鉴权向量）、签约（5G切片允许不允许、区域限制）、以及UE所在TA的合法性——UE上报的最后访问TAI、基站侧上报的当前小区TAC，都要能在AMF自己的TAI支持列表里找到对应关系。
第四关：判决。 全部通过，AMF回Registration Accept，分配5G-GUTI并下发一组跟踪区（TA）作为注册区；任何一关不过，回Registration Reject，消息里必带一个5GMM原因值，告诉手机"你为什么被拒"。
这套流程全部定义在TS 24.501里，N2接口的消息封装在TS 38.413里。要强调的是：注册失败不等于手机坏了，也不等于没信号——它是一场"对话"的失败，而对话失败一定有原因值。
Registration Reject里的5GMM原因值，是整个排查工作中信息密度最高的一个字段。它是一组标准化的枚举值，全网络（手机、基站、核心网、测试仪表）语义统一，不存在歧义。常见的注册拒绝原因值如下：
| 原因值 | 官方名称（TS 24.501） | 常见根因 | 排查方向 |
|---|---|---|---|
| #3 | Illegal UE | 鉴权序列异常、USIM问题 | UDM鉴权数据、USIM状态 |
| #7 | 5GS services not allowed | 签约未开5G、区域限制 | UDM签约数据 |
| #11 | PLMN not allowed | 用户进入了不允许的PLMN | UE侧FPLMN列表、漫游协议 |
| #12 | Tracking area not allowed | 区域限制签约、TA禁用 | UDM区域签约数据 |
| #13 | Roaming not allowed in this tracking area | 漫游用户进入禁入TA | 漫游协议、TA规划 |
| #15 | No suitable cells in tracking area | TAC不一致、切片无覆盖、CAG限制 | gNB与AMF的TAC一致性 |
| #22 | Congestion | 网络过载 | AMF负载、过载控制参数 |
| #27 | N1 mode not allowed | 网络侧不允许N1模式 | AMF策略配置 |
重点看#15："该跟踪区内无合适小区"。字面意思是，UE在当前TA里找不到一个能给它提供正常服务的小区。什么情况下会触发？三类场景最常见：
再往深一层，是"合适小区"这个概念本身。TS 23.122对它的判定有一套完整条件：小区选择S准则达标、PLMN在允许列表、小区不被bar、TA不在禁用列表，且能支持所需服务。手机侧的判定只能用手机知道的信息，而"这个TAC核心网接不接受"这件事，手机根本不知道——它把注册请求发出去，被拒一次，就进入受限服务状态：只能紧急呼叫，屏幕显示"仅限紧急呼叫"。
这里有个用户感知的经典bug：被拒的手机不会躺平，它会重新选网——重选到隔壁老TAC的小区，注册成功，一切正常；走两步又进了新TAC的覆盖，再被拒，又"仅限紧急呼叫"。这就是本案投诉"时好时坏、移动才坏"的机理：不是玄学，是被拒手机在两个TAC之间反复横跳。
回到案例。原因值锁定#15后，剩下的就是标准动作。整个定位过程如下（脱敏示例）：
| 时间 | 动作 | 关键发现 |
|---|---|---|
| 09:30 | 按TAC下钻注册成功率KPI | 问题TAC成功率42%，#15占比81% |
| 10:20 | 对典型投诉用户激活3GPP信令追踪 | 拿到完整NAS消息，确认拒绝发生在鉴权完成后 |
| 11:10 | 提取该用户驻留小区的广播参数 | 广播TAC=62002（示例值） |
| 11:30 | 与AMF侧TAI支持列表比对 | 列表中没有62002 |
| 14:00 | 回溯工单 | 7月TAC整合扩容工单，"核心网TAI同步"检查项未闭环 |
整个排查路径可以用一棵决策树概括——这也是接入类投诉的通用打法：
flowchart TD
A[片区投诉仅限紧急呼叫] --> B[查注册成功率KPI]
B --> C[按拒绝原因值分组]
C --> D{主导原因值}
D -->|15| E[核对广播TAC]
D -->|20或21| F[查鉴权链路]
D -->|11至13| G[查PLMN与区域限制]
D -->|22| H[查AMF过载]
E --> I{TAC与AMF列表一致}
I -->|否| J[变更窗口补配置]
I -->|是| K[查切片与CAG限制]
J --> L[观察原因值KPI归零]
两个工具值得单独说。一是3GPP信令追踪（Trace）：TS 32.421/32.422/32.423定义了完整的追踪体系——网管向gNB和AMF下发追踪激活命令（带Trace Reference和待追踪用户的SUPI/IMEI），网元把该用户经过的所有信令消息按时间戳串成Trace记录，回传到追踪实体TCE。相比在N2口抓包，Trace的优势是按用户串联、跨网元连续，一张投诉工单的IMSI输进去，出来的就是这个人注册失败全过程的消息级还原。二是Wireshark：在N2口镜像抓包，用ngap和nas-5gs过滤器直接定位Initial UE Message和Registration Reject，读出5GMM cause字段——Trace靠管理面下发，抓包靠数据面镜像，两条路互为备份，Trace不可用时就靠抓包兜底。
根因链条还原如下：7月，该地市做TAC整合，把两个县级TAC合并，同时扩容12个新站，新站按新规划配置了新TAC（示例值62002）。网优侧参数表更新了，无线侧配置下发到位了，但核心网侧"AMF的TAI支持列表新增该TAC"这一项，在工单里没有对应责任人，也从未执行。
为什么上线一个多月才爆发？因为这批新站处于话务爬坡期，开通初期注册量极小，按TAC的注册成功率KPI被日间正常波动掩盖。8月话务起量，问题浮出水面。而交界片区的用户最先感知——他们恰好生活在两个TAC的重叠覆盖区，手机在"有户口的塔"和"没户口的塔"之间来回切换，体验就成了反复的"仅限紧急呼叫"。
还有个值得追问的问题：为什么NG Setup没拦住？ gNB与AMF建链时，NG Setup交互中AMF会在响应消息里携带自己支持的TAI列表。但AMF收到一个"无主"TAC的注册请求时如何处置、gNB侧对配置了AMF不支持的TAC是否告警，标准允许多种实现，具体行为以各厂家官方文档为准。本案的网络里，这条链路两端都"各自正常"，直到注册请求打过来才对不上账——配置一致性问题最阴险的地方就在这里：每一个环节单看都是绿的，连起来才是红的。
修复本身很朴素：变更窗口内，在AMF的TAI支持列表中补上该TAC，与无线侧广播值对齐。生效后按原因值下钻的KPI十分钟内归零。更重要的是回溯动作：用同一套"三方比对"逻辑扫描全网其余新站，又发现2个同隐患站点，一并闭环——一次故障暴露的不是一个错，是一类错。
这次的根因不是技术盲区，而是变更管理的缝隙。TAC整合这种"无线、核心网两头改"的变更，最容易在交界处掉链子。复盘产出的四条制度改进，值得所有做TAC规划、切片规划这类"跨域参数"的团队参考：
一句话总结这套打法：接入类投诉，KPI定片、原因值定性、Trace定人、参数比对定根因。四步走完，大部分"仅限紧急呼叫"类故障当天可闭环。
这起故障的全部技术要素——注册流程、原因值语义、追踪体系——都写在TS 24.501和TS 32.421这些标准文本里，任何一个入职三年的核心网工程师都学过。但故障还是发生了，且潜伏了一个多月。原因不在知识，在缝隙：跨域变更的责任缝隙、低话务期的监控缝隙、单点正确与整体错误的系统缝隙。
运维的功夫，一半在网内——懂协议、会抓包、能读原因值；另一半在网外——把那些"每个人都以为别人做了"的检查项，变成机器对账、变成双签工单、变成按原因值分组的告警。网络越来越复杂，5G-A的网络切片、CAG专网会让"TAC/区域/切片一致性"这类跨域配置呈指数增长，今天复盘的这道缝隙，只会更多，不会更少。
标准是确定性的，故障是确定性的，唯一不确定的是哪个缝隙先爆。排障的意义，就是把每一次爆炸都变成一次补缝。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。