手机满格信号，却显示"仅限紧急呼叫"，电话打不出、数据上不去，换个街区又好了。这不是手机坏了，也不一定是无线信号问题——大多数时候，是手机和核心网之间的一次"对话"失败了。本文以一起典型的注册失败故障（多起同类故障的脱敏复合复盘，参数为示例值，信令行为均以3GPP标准为准）为线索，把5G注册流程、NAS拒绝原因值、信令追踪工具链完整过一遍，回答一个运维最常遇到的问题：**接入类投诉，到底该怎么查？** 本文的解读主轴锚定3GPP官方标准 **TS 24.501**（5G移动性管理与NAS消息，5GMM原因值的唯一权威出处），辅以 TS 23.122（小区选择）、TS 38.413（NGAP信令）和 TS 32.421/32.423（信令追踪）。 ## 目录 - 一、现象：满格信号，只打得通110 - 二、先补课：注册这条路上有哪些关卡 - 三、原因值15：NAS里的死因鉴书 - 四、四小时定位：KPI、追踪与三方比对 - 五、根因：一个没人闭环的检查项 - 六、复盘：把"配置一致"变成制度 - 结语：排障的功夫在网外 ## 一、现象：满格信号，只打得通110 今年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层（非接入层）的第一场大考，简化后的消息流如下： ```mermaid 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里。要强调的是：**注册失败不等于手机坏了，也不等于没信号**——它是一场"对话"的失败，而对话失败一定有原因值。 ## 三、原因值15：NAS里的死因鉴定书 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里找不到一个能给它提供正常服务的小区。什么情况下会触发？三类场景最常见： 1. **TAC配置不一致**：基站广播的TAC，核心网不认识——本案的主角； 2. **切片限制**：UE请求的S-NSSAI在当前TA内没有小区支持，找不到"合适"小区； 3. **CAG/网络封闭组限制**：专网用户进入了不支持其CAG的公网区域。 再往深一层，是"合适小区"这个概念本身。TS 23.122对它的判定有一套完整条件：小区选择S准则达标、PLMN在允许列表、小区不被bar、TA不在禁用列表，且能支持所需服务。**手机侧的判定只能用手机知道的信息，而"这个TAC核心网接不接受"这件事，手机根本不知道**——它把注册请求发出去，被拒一次，就进入受限服务状态：只能紧急呼叫，屏幕显示"仅限紧急呼叫"。 这里有个用户感知的经典bug：被拒的手机不会躺平，它会重新选网——重选到隔壁老TAC的小区，注册成功，一切正常；走两步又进了新TAC的覆盖，再被拒，又"仅限紧急呼叫"。这就是本案投诉"时好时坏、移动才坏"的机理：**不是玄学，是被拒手机在两个TAC之间反复横跳**。 ## 四、四小时定位：KPI、追踪与三方比对 回到案例。原因值锁定#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同步"检查项未闭环 | 整个排查路径可以用一棵决策树概括——这也是接入类投诉的通用打法： ```mermaid 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规划、切片规划这类"跨域参数"的团队参考： 1. **三方比对纳入割接基线**。网优规划表、gNB实际配置、AMF的TAI支持列表，三份东西定期脚本化比对，任何差异直接生成高优先级工单。比对脚本不复杂——三个接口导出，按PLMN+TAC做集合差，百行代码的事，价值是把"人肉核对"变成"机器对账"。 2. **拒绝原因值KPI告警**。注册成功率只看总量是不够的，要按5GMM cause分组下钻，#15、#12这类"TAC/区域类"原因值单独设阈值。原因值告警的优势是**自带根因方向**，值班看到#15飙升，不用等专家会诊就知道往哪查。 3. **跨域工单强制双检**。凡涉及新增TAC、新增切片、CAG变更的工单，检查项里必须有"核心网侧同步"条目，无线与核心网双方签字闭环，不允许单侧宣布完成。 4. **新站开通拨测**。话务爬坡期KPI失真，新站开通必须做注册类业务拨测（含驻留切换穿越测试），不能只看话务量。用主动拨测补上被动KPI的盲区。 一句话总结这套打法：**接入类投诉，KPI定片、原因值定性、Trace定人、参数比对定根因**。四步走完，大部分"仅限紧急呼叫"类故障当天可闭环。 ## 结语：排障的功夫在网外 这起故障的全部技术要素——注册流程、原因值语义、追踪体系——都写在TS 24.501和TS 32.421这些标准文本里，任何一个入职三年的核心网工程师都学过。但故障还是发生了，且潜伏了一个多月。原因不在知识，在**缝隙**：跨域变更的责任缝隙、低话务期的监控缝隙、单点正确与整体错误的系统缝隙。 运维的功夫，一半在网内——懂协议、会抓包、能读原因值；另一半在网外——把那些"每个人都以为别人做了"的检查项，变成机器对账、变成双签工单、变成按原因值分组的告警。网络越来越复杂，5G-A的网络切片、CAG专网会让"TAC/区域/切片一致性"这类跨域配置呈指数增长，今天复盘的这道缝隙，只会更多，不会更少。 标准是确定性的，故障是确定性的，唯一不确定的是哪个缝隙先爆。排障的意义，就是把每一次爆炸都变成一次补缝。 ## 参考来源 1. [3GPP TS 24.501 — Non-Access-Stratum (NAS) protocol for 5GS](https://www.3gpp.org/dynareport/24501.htm) — 5G注册流程与5GMM原因值的官方权威出处，本文原因值表均出自该规范的5GMM cause values章节 2. [ETSI TS 124 501 免费下载页](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/) — 同一规范的ETSI官方免费PDF版本 3. [3GPP TS 23.122 — NAS functions related to Mobile Station](https://www.3gpp.org/dynareport/23122.htm) — 小区选择、"合适小区"判定与受限服务状态的定义出处 4. [3GPP TS 38.413 — NG-RAN; NG interface specification](https://www.3gpp.org/dynareport/38413.htm) — NGAP信令、NG Setup与TAI支持列表交互的标准依据 5. [ShareTechnote 5G/NAS 5GMM](https://www.sharetechnote.com/html/5G/5G_NAS_5GMM.html) — 工程师视角的5G NAS消息与IE速查手册，适合对照Wireshark报文阅读 --- > 本文由「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 等场景全覆盖。