开机的状态栏一直卡在“正在激活数据连接”等了一分多钟没动静用户以为卡槽接触不良重启一下又好了。这种反馈在现网排障里出现的频率比想象中高真把信令拉出来看十有八九是一条 ATTACH REJECT 里带着EMM cause #19ESM failure紧接着终端就彻底安静了整整十二分钟期间不发起任何附着、不发起任何路由区更新直到一个叫T3402的定时器走完才重新探头。很多人第一次看到这段 log 会以为是终端挂了、协议栈死循环了其实终端活得好好的它只是被规范要求“闭嘴”十二分钟。这篇内容想聊的就是这条链路EMM cause #19 为什么会让终端进入 T3402 的长静默期、这十二分钟里终端到底做了什么、排障时怎么把定时器的起止点从 log 里钉死、以及网络侧在什么情况下才会选择丢 #19 而不是回一条普通的 ESM 拒绝。写给正在做终端协议栈、网络侧核心网优化、或者现场支撑无线数据业务的人看基础一点的读者也能从中拿到一份“看到这个 cause 该怎么往下查”的路线图。1. 一条 ATTACH REJECT 之后那十二分钟终端到底在干什么1.1 cause #19 的语义ESM 层失败被抬到了 EMM 层要理解 T3402得先把 #19 这个 cause 的语义掰开。LTE 的 NAS 协议分成两层EMM 管移动性和注册附着、去附着、TAU、鉴权、安全ESM 管承载和会话PDN 连接建立、默认承载、专用承载。平时这两个层次各管各的ESM 层出错就走 ESM 的拒绝消息带上 ESM cause比如“缺少或未知的 APN”“资源不足”“服务网关或 PDN 网关拒绝请求”这些终端收到之后只影响这一条 PDN已经注册上的其他业务不受牵连。#19 ESM failure的特殊之处在于它是用 EMM 层的话筒说出 ESM 层的事故。网络侧在附着流程里发现默认承载建不起来本来可以只回一条 PDN CONNECTIVITY REJECT 了事但它选择了更重的手段直接一条 ATTACH REJECTcause 填 0x13也就是十进制 19。这一条消息发出去终端收到的信号不是“这个 APN 有问题”而是“你这次附着整体失败了而且失败原因在会话层我没法告诉你什么时候能好”。从十进制 19 这个编码本身看不出情绪但它在整张 cause 表里的位置很特殊。它不像 #11PLMN 不允许那样把终端赶进禁用名单也不像 #22拥塞那样明说“我等会儿再来”它给的是一种模糊的、指向网络内部故障的结论。正因为模糊终端只能采取最保守的策略——把注册状态整体回退然后拉起一个足够长的定时器等网络自己缓过来。这个保守策略的执行者就是 T3402。现场判断时有个很实用的分辨点ATTACH REJECT 里带的是 EMM causePDN CONNECTIVITY REJECT 里带的是 ESM cause两者在 log 里的消息名完全不同但 cause 数值可能撞车比如都出现 26、27 这种数字。看 log 时如果不确认消息类型光看 cause 数字非常容易误判成 #19 场景。我见过有同事把 ATTACH ACCEPT 之后跟着的一条 ESM 拒绝当成 #19从而错误地认为终端该起 T3402结果对着 log 找了半天没找到定时器启动点。1.2 收到 #19 的一瞬间终端改了四笔账并起了一个表终端收到携带 #19 的 ATTACH REJECT 之后动作是一连串的不是单一动作。按规范的处理逻辑它大致要完成这么几件事我按重要性从高到低排第一笔账是EPS update status 置为 EU3ROAMING NOT ALLOWED。这个状态存在 USIM 的 EPS 位置信息文件里值 3 表示“未更新且漫游不允许”。它会影响终端后续对网络选择的判断逻辑不是简单的一个标志位。第二笔账是删掉网络分配的临时身份和位置信息包括 GUTI全球唯一临时标识、最近访问的注册跟踪区、跟踪区列表。这一删很关键意味着下次附着要从 IMSI 附着重新走一遍鉴权和加密流程都得重来没法再用临时身份省事。第三笔账是清空等价 PLMN 列表。这一条经常被忽略但它直接决定了“换个地方能不能立刻好”后面第 5 节会展开。第四笔账是把 EMM 状态退回 DEREGISTERED同时把附着尝试计数器清零。注意这里是清零而不是加一因为 #19 不是“尝试失败了一次”而是“这次尝试的失败性质决定了不用再试”。做完这些之后终端启动T3402。这个定时器在规范里给的值是12 分钟固定值不像 T3346 那样由网络通过消息里的定时器 IE 动态下发也不像 T3396 那样分场景给不同长度。它就是一个常量。定时器跑起来之后终端进入一种“冷处理”状态不再发起普通的附着、不再发起跟踪区更新也不会去尝试重建 PDN 连接因为它连注册都没了没有可重建的对象。有一点容易搞混T3402 的启动并不等于终端彻底停止所有无线行为。小区测量、重选、系统消息接收这些照常进行射频也没有关。所以从外部看终端“还在网上”但它不会向网络发任何注册类请求。这就是为什么有些测试仪表上看不到终端有任何动作会误判成终端把协议栈卡死了。1.3 用户侧的表现为什么是“过一会儿自己好了”把这套机制翻译成用户语言就是开机 → 附着 → 被拒原因不明→ 十二分钟不理网络 → 突然自己好了。这个体验非常具有迷惑性因为中间没有任何提示状态栏可能显示 4G 图标射频注册在小区上是成功的只是 NAS 层没注册上用户会以为“有信号但网卡了”然后不断开关飞行模式。这里有个非常重要的现场细节开关飞行模式或者重启往往能让它立刻恢复。原因不是“重启修复了问题”而是 T3402 的运行状态不跨断电保存重启后定时器没了终端会立刻重新发起一次附着这时候如果网络侧的临时故障刚好过去了就成功了。这个现象在网络侧故障是间歇性的时候特别明显也是造成“用户说重启就好、你去看的时候一切正常”这种扯皮局面的根本原因。反过来如果网络侧故障是持续性的比如 APN 配置错了、签约数据缺了重启会立刻再被拒一次用户就会觉得“重启也没用”。这两种表现背后其实是同一套机制只是网络侧状态不同。分辨这两种情况看 log 里的时间戳就够如果两次 ATTACH REJECT 之间的间隔是几秒到几十秒说明是重启触发的如果间隔精确到 720 秒左右说明是 T3402 正常到期。从用户抱怨的分布看还有一类表现是“每天早上第一次上网特别慢要等十几分钟”。这种情况往往不是 T3402而是终端在夜间待机时被网络隐式去附着早上唤醒后重新附着失败了几次累计到附着尝试计数器上限才启动 T3402。看起来像同一个现象实际走的路径完全不同第 2 节会把这两条路径对比清楚。2. 把 #19 放到 cause 家族里对比才知道它有多“重”2.1 同样是拒绝#22 只让终端等几秒#19 要等十二分钟单看 #19 没什么感觉把它和其他常见 cause 摆在一起轻重立现。我整理了一张自己排障时常用的对照表覆盖了 ATTACH REJECT 和 TAU REJECT 场景里出现频率最高的几个 causeEMM cause语义终端主要动作关联定时器典型时长#19ESM failure清 GUTI/TAI 列表/ePLMN、状态置 EU3、回 DEREGISTEREDT340212 分钟#22Congestion保持当前部分状态等待后重试T3346由网络下发常见几十秒到几分钟#15No suitable cells in TA把该 TA 加入禁用列表T344224 分钟#11PLMN not allowed该 PLMN 加入禁用列表无直到手动选网或换卡#12Tracking area not allowed该 TA 加入禁用列表无同上#14EPS services not allowed视为 USIM 对该网络无效无需换网或换卡#25CS domain not available仅影响 CS 回落相关无不阻断 PS从这张表能看出一个规律cause 越“模糊”定时器越长。#11、#12 这类原因明确的终端直接拉黑名单不需要定时器等#22 这种明确说“我忙”的等一小会儿就行而 #19 说的是“会话层失败了具体为什么我不告诉你”终端只能猜网络需要多久恢复于是给了 12 分钟这个相当长的保守值。还有一个容易被忽略的差别#19 是立即启动 T3402而其他很多失败是要累计到 5 次才启动。规范里对附着尝试计数器有明确上限连续失败达到 5 次之后终端才会清身份信息并启动 T3402。#19 跳过了这个累计过程一次就把终端打进长静默。这意味着在网络侧偶发故障的场景里如果 MME 选择用 #19 而不是让终端多试几次用户体验的损失会被放大好几倍——本来试第三次就成功的附着被 #19 一搞直接变成等十二分钟。这是网络侧参数选择上很值得权衡的一个点第 4 节会详细说。2.2 T3402 取值 12 分钟的由来以及为什么不做随机化12 分钟这个数字不是拍脑袋定的它背后是一个挺典型的工程权衡。设想核心网某个网元出现短时故障如果所有终端都在几秒内疯狂重试信令面会瞬间被淹没本来就 congestion 的网元会被彻底压垮恢复时间被无限拉长。反过来如果定时器设得太长比如半小时那么网络已经恢复了终端还在那儿干等用户感知直接崩掉。12 分钟大致落在“给网络留出恢复窗口”和“用户还能忍”这两条线的交集上。有意思的是这个定时器没有做随机化。规范给的是固定值理论上如果一批终端在同一时刻被同一台 MME 拒绝它们会在同一时刻到期、同一时刻发起附着形成一个整齐的尖峰。在实际网络里我确实观察到过这种同步重试的现象一批物联网模组在同一小区几乎同时上线被拒之后又在 720 秒后几乎同时发起对基站来说那一瞬间的接入请求是密集的。有些终端实现会在到期后叠加一段随机的短延迟来打散这个尖峰这属于实现层面的取舍规范里并没有这个要求。做终端测试的时候如果发现某款设备到期后不是精确的 720 秒而是 720 加几十秒先别急着判 bug有可能是故意加的抖动。判断方法很简单连续测多次如果是固定偏移就说明是设计如此如果是每次都不一样且离散度大那才可能是计时精度问题。另外提一句 2G/3G 体系的对应关系方便做跨制式排障的人对照。老体系里也有类似的重试抑制机制量级同样是十分钟上下触发条件也包含“网络侧无法建立 PDP 上下文”这类场景。所以当你看到一个多模终端在 LTE 上被拒、切到 3G 之后又安静很久很可能不是两个独立的故障而是两套机制在各自生效。2.3 三种最容易被误认成 #19 的现场排障中最耗时间的往往不是定位问题而是先要排除“看起来像但不是”的情况。我列三个踩过的坑第一种把 ESM 拒绝当成 #19。ATTACH ACCEPT 之后紧跟一条 PDN CONNECTIVITY REJECTcause 是 ESM 层的“资源不足”或者“未知 APN”终端会走 ESM 层的退避逻辑可能带一个网络下发的定时器值不会启动 T3402。表面上都是“附着之后上不了网”但终端的行为完全不同这种情况终端保持已注册可以重试其他 APN而 #19 是彻底回到未注册。log 里一条看消息名就能区分别只看 cause 数值。第二种把附着尝试计数器耗尽当成 #19。终端连续附着失败 5 次第 5 次之后清身份、起 T3402。从终端的最终状态看和 #19 一模一样都是清 GUTI 加 12 分钟静默。区别在时间轴这种情况前面会有 4 次失败的 REJECT间隔通常是几十秒量级可能有 T3411 之类的短定时器介入而 #19 是一次到位。把前面几条消息翻出来看如果 reject 的 cause 是 #22 或者其他值那这就是累计失败不是 #19 直接触发。第三种把网络侧的隐式去附着当成 #19。终端从待机唤醒后发现被隐式去附着重新发起附着又被拒如果拒的 cause 恰好是 #19 就会同时出现两个现象。这种场景下用户感知是“待机久了就上不了网”和纯粹的 #19 场景开机即失败在时间特征上不一样。判断方法是看第一条 ATTACH REQUEST 之前有没有一段长时间的静默以及有没有 Detach Request/Accept 或者寻呼未响应的记录。这三种情况的共同点是只看终端最终状态都会得到“12 分钟静默”这个结论但根因和修复方向完全不同。我在排查时养成的习惯是无论现象多像都先把 T3402 启动点之前的那 30 秒信令完整拉出来看一遍确认最后一条驱动消息到底是哪一条。这一步花两分钟能省掉后面两个小时的瞎猜。3. 排障时怎么把 T3402 的起止时间钉死3.1 只在 NAS 层看是不够的三层信令要对着看很多人排这类问题只抓终端的 NAS 消息能看到 ATTACH REJECT 和 cause但看不到“为什么被拒”。原因很简单NAS 消息是终端和 MME 之间的对话MME 拒绝终端的时候它自己往往只是在转发一个更底层的失败。真正的根因通常在 S1 接口之外也就是 MME 和网关之间的会话建立过程。我一般的抓取范围是三层空口侧 NAS 消息确认 reject 的类型、cause 值、时间戳以及后续终端有没有异常动作。S1 接口信令看整个附着流程走到哪一步断的。正常的附着流程是Attach Request → Identity/Authentication → Security Mode → Update Location → Create Session → Initial Context Setup → Attach Accept。如果断在 Create Session 之后那问题基本锁定在核心网侧。S5/S8 接口的会话消息看 Create Session Response 里携带的原因值这是最接近根因的一层。三层对着看的好处是能把“终端看到的现象”和“网络内部的真相”串成一条线。我见过一个案例终端侧看到的是 #19S1 上看到 Create Session 请求发出去了但没等到响应S5/S8 上看到对端设备压根没回——三层信息拼起来根因是会话网关侧的一个地址解析问题和终端毫无关系。如果只看终端 log可能会一直怀疑终端定时器实现有问题。3.2 用 720 秒做标尺几种典型的时间偏差说明什么T3402 是个固定值这就给了排障一个非常好用的标尺从 ATTACH REJECT 的时间戳往后推 720 秒看终端是不是在这个点附近发起下一次附着。偏差的类型直接指向不同的问题层面。观察到的间隔可能原因排查方向约 720 秒±几秒定时器正常工作问题在网络侧查为什么被拒远小于 720 秒几秒到几十秒有事件提前解锁了定时器检查期间是否有 PLMN 变化、飞行模式、USIM 重插远小于 720 秒且多次重复定时器未生效或实现缺陷确认是否真的收到 #19检查协议栈状态机720 秒到 1200 秒之间跨睡眠计时漂移查待机场景下的计时补偿实现超过 1200 秒甚至不发起被其他禁用列表挡住查禁用 PLMN、禁用 TA 列表状态第三行那种“几秒就重试”的情况要特别警惕。这不一定就是 bug很可能终端在等待期间又收到了新的触发条件比如小区重选到了一个不属于等价 PLMN 列表的新 PLMN。因为 #19 会把等价 PLMN 列表清掉原来那些“不算换了网”的邻区现在都算新网了终端会提前解锁。这个机制是规范要求的设计上合理但在排障时容易误导人。第四行的漂移问题在物联网设备上尤其常见。这些设备大量时间在待机协议栈的定时器如果基于某种会随睡眠暂停的计数源实现实际经过的时间就会被拉长。有些平台会用真实时钟戳做补偿醒来后一次性把欠的时间补上这种情况下 720 秒还是准的。有些平台没做补偿就会看到 15 分钟、20 分钟这样的结果。这属于实现质量问题需要终端侧确认。3.3 一次完整排查链路的复盘说个具体的分析过程把前面的方法串起来。现象是某类终端在某个区域反复出现“开机后长时间无法上网”重启能恢复但不重启的话要等十几分钟。第一步抓终端 NAS 日志。确认每次失败的驱动消息都是 ATTACH REJECTcause 值为 0x13也就是 #19。并且确认了 REJECT 之后终端确实没有再发任何 ATTACH REQUEST直到约 720 秒后才重发。这一步排除了“协议栈卡死”的猜测坐实了 T3402 在正常工作。第二步看 S1 接口。发现附着流程走到 Create Session 这一步MME 向网关发了会话建立请求但返回的是失败响应随后 MME 才组了 ATTACH REJECT 回给终端。这就把责任从终端排除了问题在核心网侧。第三步看 S5/S8 的会话响应里的原因值。这一步是关键得到的值指向“资源不可用”这一类。再往上游查发现是某个地址池在特定时段被耗尽新接入的终端拿不到地址网关直接回了资源不可用的原因。第四步验证。在地址池耗尽的时间窗内做定点测试能稳定复现在非高峰时段测试复现率极低。同时观察到一个细节同样的网络条件下不同终端的行为不完全一样——有些终端拿到的是 #19有些拿到的是 ATTACH ACCEPT 加 ESM 拒绝这说明 MME 对不同终端的处理路径有差异下一节会讲原因。第五步修复与回归。网络侧扩容地址池之后复测附着成功率恢复正常T3402 不再被触发。整个链路从现象到根因大概用了两天其中大部分时间花在协调多方同时抓包和对齐时间戳上真正定位的过程其实不长。这次排查给我最大的教训是#19 这个名字有很强的误导性。它叫 ESM failure会让人下意识地去查会话层的配置但实际根因可能在更上游的资源分配。排障时不能被 cause 的命名带着走得顺着信令一层层往下钻。4. 网络侧为什么选择丢 #19 而不是回 ESM reject4.1 MME 的两条岔路拒整次附着还是只拒这个 PDN这是整个话题里最值得深挖的一点。当终端在 ATTACH REQUEST 里同时带了 PDN 连接建立请求而这个 PDN 建不起来的时候MME 面前有两条路第一条路回 ATTACH ACCEPT只做 EPS 附着 PDN CONNECTIVITY REJECT带 ESM cause。这样终端注册成功了拿到了 GUTI只是这个 PDN 没建起来。终端可以保持注册状态尝试其他 APN或者过一段时间重试这个 PDN重试的节奏由 ESM 层的退避机制控制通常比 12 分钟短得多。对用户来说最坏情况是某些应用上不了网但基础的注册、语音回落这些还是正常的。第二条路回 ATTACH REJECT #19。终端整个回到未注册接受 12 分钟静默。用户的体感是从“部分功能不可用”变成“完全不可用”。规范允许两种做法选择权在 MME。实际操作中不同网络设备厂商、不同运营策略下选择不一样。我见过的场景里选择 #19 的情况大致有几类一是网络侧配置为不允许“仅 EPS 附着”也就是没有默认承载就不让注册二是签约数据里没有该 APN 的授权MME 认为这不是临时故障让终端等也没意义三是 MME 在会话建立失败后拿不到足够的信息判断该回哪个 ESM cause索性回一个笼统的 #19。站在用户体验的角度第二条路的代价明显更大。所以做网络侧参数优化的时候如果发现某类失败被频繁映射成 #19值得评估一下能不能改成走第一条路。特别是那种“特定 APN 失败但用户其实还用着别的 APN”的多 APN 场景一次 #19 会把整个终端打瘫十二分钟损失被严重放大。4.2 S5/S8 上的 GTP cause 是怎么变成 #19 的从底层原因到 #19中间有一层映射关系理解这层映射对定位很有帮助。会话建立失败时网关回的原因值大致有这几类它们向上映射的路径不同会话层原因含义常见上游问题向上映射倾向上下文未找到网关侧没有该 APN 的上下文签约缺失、APN 配置不一致可能映射为 #19资源不可用地址池耗尽、承载资源不足容量规划不足可能映射为 #19 或 ESM 资源不足缺少或未知 APNAPN 名字对不上终端配置与网络配置不一致通常映射为 ESM 层 APN 错误请求被拒绝策略侧拒绝策略配置冲突视策略而定对端无响应超时链路问题、对端设备异常可能映射为 #19系统故障内部错误软件异常可能映射为 #19规律大致是原因越“不知道该怎么办”越容易被映射成 #19。因为 #19 本质上是一个“我这边出问题了但说不清具体是什么”的表达。而原因明确、能对应到具体 ESM cause 的比如 APN 名字错了MME 更倾向于走 ESM 拒绝让终端知道该改配置。这个规律对排障有实际指导意义如果问题是稳定复现的往往对应的是配置类错误可能走的是 ESM 路径如果是间歇性的、时段性的更容易看到 #19。因为间歇性故障超时、资源竞争恰恰是“说不清”的那一类。我在现场遇到 #19 时的第一反应就是去查时段分布看看是不是和某个高峰时间吻合。还有一层细节MME 在决定映射方式时还会考虑终端在 ATTACH REQUEST 里带的 PDN 连接请求是不是“唯一的”请求。如果终端只请求了一个 PDN而这个 PDN 失败MME 倾向于认为整个附着没有意义回 #19 更直接如果终端请求了多个虽然 LTE 附着阶段通常只带一个或者网络知道终端还有别的业务需求走 ESM 拒绝的动机就强一些。4.3 签约、APN、地址池三个高发源头从根因分布看#19 的来源高度集中在三块实际排障时可以按这个顺序查签约数据问题排第一。用户开了某个 APN 的业务但签约数据没有同步到归属服务器或者同步了但 MME 缓存的是旧版本。这种情况下MME 在会话建立时发现本地没有对应的签约信息会话建立直接失败映射成 #19 的可能性很高。特征是换一张卡在同一位置正常或者同一个用户换到别的 MME 覆盖区正常。这种“跟人走而不跟位置走”的特征是签约类问题最典型的标志。APN 配置不一致排第二。终端侧配置的 APN 名字、鉴权方式、IP 类型和网络侧预期的不一致。这种情况下起因很明确理论上应该映射成 ESM 层的 APN 错误但实际中如果 MME 没有做精细映射也可能笼统地回 #19。特征是特定型号终端或特定配置的终端出问题其他终端正常。这种“跟终端走”的特征和签约问题正好相反很好区分。地址池耗尽排第三也是最容易被忽略的。它的特征是时段性极强忙时出问题、闲时正常而且往往影响面广、不分终端型号。这类问题在物联网场景里特别常见因为物联网设备大量集中在某些时段上线比如深夜批量抄表瞬时并发远高于人网。我遇到过一次某区域每天晚上固定时段出现批量 #19查了两天才定位到地址池容量。除了这三块还有一个隐性的第四类MME 与网关之间的链路或解析问题。这类问题最隐蔽因为它是间歇性的出现在特定链路或特定网元组合上。特征是同一个用户在移动位置后可能恢复正常换了服务网元或者问题集中在某个时间段内新增的会话上链路抖动期间。这类问题往往需要多接口同时抓包才能定位单看某一层永远看不出问题。5. 终端实现里几个容易翻车的细节5.1 定时器跨睡眠漂移与“十二分钟变成二十分钟”终端侧实现 T3402 时最实际的工程问题是计时源的选择。如果协议栈用的是系统 tick 计数而这个 tick 在深度睡眠时被暂停那么实际经过的物理时间就会远远超过 12 分钟。这在手机上不太明显屏幕亮着的时候不睡眠但在物联网模组上非常突出。有些平台的处理方式是在定时器启动时记一个真实时间戳唤醒后重新计算剩余时间有些平台则简单地让 tick 停在那醒来后继续数。后者就会出现前面表格里提到的漂移现象。判断一款设备用的是哪种方式测法很简单让设备在被拒之后立刻进入待机等 15 分钟再唤醒看它是不是立刻发起附着。如果是说明用了时间戳补偿如果还要再等好几分钟说明 tick 被暂停了。这个差异对用户体验的影响不小。本来十二分钟能恢复的业务变成二十分钟甚至更久在需要定时上报的场景里会造成明显的数据缺口。做终端选型或者问题定位时这一条值得专门测一次。还有一个更隐蔽的问题定时器被意外重置。有些实现在收到某些非相关消息时会把 T3402 重新计时导致它永远走不完。典型触发是小区重选之后收到系统消息更新或者收到一条寻呼。这类问题在 log 里表现为明明应该 720 秒到期但每次快到点的时候就“重新开始”实际永远恢复不了。判断方法是看有没有周期性的某个消息反复出现且每次出现后定时器剩余时间被拉满。5.2 重启能治好的原因以及它为什么是排障陷阱前面提过T3402 的运行状态不跨断电保存。这个设计本身是合理的规范里 EMM 的很多上下文都不持久化只把必须保留的信息比如 GUTI、禁用列表写进 USIM。终端重启后从 USIM 读出状态发现没有正在运行的定时器就重新发起附着。这给现场排障带来一个很麻烦的循环用户报障 → 你去现场 → 用户说我重启过了现在好了 → 你什么都抓不到 → 过两天又报。要打破这个循环得让用户或者一线人员知道下次出问题时先别重启直接抓 log 或者拨个诊断码看状态。我一般会给一线一份简单的操作卡片写清楚“出现无法上网时先别重启保持现状记录时间点”这样才有机会抓到现场。从另一个角度看重启能恢复这个特性本身是有价值的信息。它说明问题不是永久性的否则重启也没用而是有时效的。结合 T3402 的 12 分钟周期可以推断出如果重启能恢复说明在重启那一刻网络侧是可用的中间那段时间网络发生了什么变化才是根因所在。顺着这个思路去查网络侧在那段时间的告警和日志往往能找到线索。还有一点值得提醒做测试的人验证 T3402 行为时千万不要用重启来“清零”。正确的做法是等定时器自然到期或者在测试仪表上重新构造拒绝场景。用重启清零会让测试结果失去意义因为你验证的其实是“重启后能不能附着”而不是“定时器到期后能不能附着”。5.3 换 PLMN、紧急呼叫这些可以提前解锁的例外路径T3402 虽然是个长静默但不是绝对的封锁。规范里留了几个口子理解这些口子对分析现场现象很有帮助第一个口子是 PLMN 变化。因为 #19 会清空等价 PLMN 列表终端重新选网时如果选到了一个原来在等价列表里、现在不在的 PLMN就会认为这是“新网络”从而停止 T3402 并重新发起附着。这解释了为什么用户“换个地方就好了”或者“坐地铁到下一站就好了”。反过来说如果故障是区域性的用户在该区域内怎么移动都不会好因为候选小区都属于同一个 PLMN。第二个口子是紧急业务。紧急附着不受 T3402 限制这是安全相关的设计要求任何时候都得让用户能打紧急电话。做测试时如果发现终端在 T3402 期间发起了紧急附着别当成 bug。第三个口子是用户干预。手动选网、重新插拔卡、开关飞行模式这些操作都会重置或绕过定时器状态。这也是为什么现场支撑时“开关飞行模式”成了万能第一招——它确实有效但它只是绕过不是修复。我在分析一个反复出现的现场问题时就是靠这个口子找到线索的。现象是用户在某个园区内无法上网走出园区就好。一开始怀疑是园区内的基站问题但基站侧看一切正常。后来注意到“走出园区就好”其实是因为走出了那个 PLMN 的覆盖边界触发了 PLMN 变化从而提前解锁了 T3402。真正的根因是园区内某台网元在特定时段不可用导致持续的 #19。如果不是理解了这条例外路径可能还在基站侧绕圈子。6. 怎么在实验室把这套行为完整验证一遍6.1 最小验证集四个用例覆盖全部关键分支如果要在实验室验证一款终端对 #19 的处理是否符合预期不需要把整张 cause 表都测一遍四个用例能覆盖全部关键分支用例构造方式预期行为判定要点基础触发仪表在附着流程中回 ATTACH REJECTcause 填 0x13清身份信息、状态置 EU3、启动 T3402后续 720 秒内无普通附着请求到期恢复同上保持网络可用观察 720 秒后到期后自动发起新附着时间偏差在合理范围附着能成功提前解锁触发后改变 PLMN 环境停止 T3402立即发起附着确认不是靠重启实现的不持久化触发后断电重启重启后立即发起附着验证定时器状态未保存这四个用例跑下来基本能判断终端的实现质量。第一和第二个用例验证核心逻辑第三和第四个验证边界处理。实际测试中第二个用例最花时间因为要真等 12 分钟建议用自动化脚本记录时间戳别靠人盯着。有个细节要注意构造 REJECT 时cause 值的编码要填对。#19 的十进制和十六进制容易搞混如果仪表配错成别的值测出来的行为完全不同而且不容易发现。测试前先确认仪表配置界面用的是哪种进制测完在 log 里再核对一次实际下发的字节。6.2 观察窗口和判定标准验证时的观察窗口不能只盯着 720 秒这个点要留出前后余量。我的习惯是记录三个时间点REJECT 时刻 T0、预期到期时刻 T0720s、实际发起附着的时刻。三者对齐才算通过。判定标准我一般这么定实际发起时刻落在 T0715s 到 T0740s 之间算正常超出这个范围就要看具体偏差原因。如果是固定偏移比如总是多 30 秒多半是到期后加了抖动或者有前置检查流程如果是离散的、每次都不一样的偏差那就要查计时源。还有一个容易漏掉的判定点到期后发起的那次附着流程是否完整。有些实现会在到期后发一个不完整的请求比如漏了 PDN 连接请求或者用了过期的身份信息。这种情况在仪表上表现为附着失败容易被误判成“定时器到期了但网络还不行”实际上是终端状态清理得不干净。检查方法是看那次 ATTACH REQUEST 里的身份字段是不是空的应该用 IMSI 而不是已删除的 GUTI以及 PDN 连接请求是否正常携带。最后分享一个我在实际排障中养成的习惯每次遇到 #19不管最后查到什么原因都把这一条的完整时间线记下来——REJECT 时刻、cause 值、上游原因、T3402 是否正常到期、到期后是否恢复。攒够十几条之后你会发现规律非常明显哪些是网络侧配置问题、哪些是容量问题、哪些是终端实现问题分布一目了然。这个过程比看任何文档都管用因为它是从你自己的网络里长出来的经验。 ATTACH REJECT cause #19与T3402静默排障
开机的状态栏一直卡在“正在激活数据连接”等了一分多钟没动静用户以为卡槽接触不良重启一下又好了。这种反馈在现网排障里出现的频率比想象中高真把信令拉出来看十有八九是一条 ATTACH REJECT 里带着EMM cause #19ESM failure紧接着终端就彻底安静了整整十二分钟期间不发起任何附着、不发起任何路由区更新直到一个叫T3402的定时器走完才重新探头。很多人第一次看到这段 log 会以为是终端挂了、协议栈死循环了其实终端活得好好的它只是被规范要求“闭嘴”十二分钟。这篇内容想聊的就是这条链路EMM cause #19 为什么会让终端进入 T3402 的长静默期、这十二分钟里终端到底做了什么、排障时怎么把定时器的起止点从 log 里钉死、以及网络侧在什么情况下才会选择丢 #19 而不是回一条普通的 ESM 拒绝。写给正在做终端协议栈、网络侧核心网优化、或者现场支撑无线数据业务的人看基础一点的读者也能从中拿到一份“看到这个 cause 该怎么往下查”的路线图。1. 一条 ATTACH REJECT 之后那十二分钟终端到底在干什么1.1 cause #19 的语义ESM 层失败被抬到了 EMM 层要理解 T3402得先把 #19 这个 cause 的语义掰开。LTE 的 NAS 协议分成两层EMM 管移动性和注册附着、去附着、TAU、鉴权、安全ESM 管承载和会话PDN 连接建立、默认承载、专用承载。平时这两个层次各管各的ESM 层出错就走 ESM 的拒绝消息带上 ESM cause比如“缺少或未知的 APN”“资源不足”“服务网关或 PDN 网关拒绝请求”这些终端收到之后只影响这一条 PDN已经注册上的其他业务不受牵连。#19 ESM failure的特殊之处在于它是用 EMM 层的话筒说出 ESM 层的事故。网络侧在附着流程里发现默认承载建不起来本来可以只回一条 PDN CONNECTIVITY REJECT 了事但它选择了更重的手段直接一条 ATTACH REJECTcause 填 0x13也就是十进制 19。这一条消息发出去终端收到的信号不是“这个 APN 有问题”而是“你这次附着整体失败了而且失败原因在会话层我没法告诉你什么时候能好”。从十进制 19 这个编码本身看不出情绪但它在整张 cause 表里的位置很特殊。它不像 #11PLMN 不允许那样把终端赶进禁用名单也不像 #22拥塞那样明说“我等会儿再来”它给的是一种模糊的、指向网络内部故障的结论。正因为模糊终端只能采取最保守的策略——把注册状态整体回退然后拉起一个足够长的定时器等网络自己缓过来。这个保守策略的执行者就是 T3402。现场判断时有个很实用的分辨点ATTACH REJECT 里带的是 EMM causePDN CONNECTIVITY REJECT 里带的是 ESM cause两者在 log 里的消息名完全不同但 cause 数值可能撞车比如都出现 26、27 这种数字。看 log 时如果不确认消息类型光看 cause 数字非常容易误判成 #19 场景。我见过有同事把 ATTACH ACCEPT 之后跟着的一条 ESM 拒绝当成 #19从而错误地认为终端该起 T3402结果对着 log 找了半天没找到定时器启动点。1.2 收到 #19 的一瞬间终端改了四笔账并起了一个表终端收到携带 #19 的 ATTACH REJECT 之后动作是一连串的不是单一动作。按规范的处理逻辑它大致要完成这么几件事我按重要性从高到低排第一笔账是EPS update status 置为 EU3ROAMING NOT ALLOWED。这个状态存在 USIM 的 EPS 位置信息文件里值 3 表示“未更新且漫游不允许”。它会影响终端后续对网络选择的判断逻辑不是简单的一个标志位。第二笔账是删掉网络分配的临时身份和位置信息包括 GUTI全球唯一临时标识、最近访问的注册跟踪区、跟踪区列表。这一删很关键意味着下次附着要从 IMSI 附着重新走一遍鉴权和加密流程都得重来没法再用临时身份省事。第三笔账是清空等价 PLMN 列表。这一条经常被忽略但它直接决定了“换个地方能不能立刻好”后面第 5 节会展开。第四笔账是把 EMM 状态退回 DEREGISTERED同时把附着尝试计数器清零。注意这里是清零而不是加一因为 #19 不是“尝试失败了一次”而是“这次尝试的失败性质决定了不用再试”。做完这些之后终端启动T3402。这个定时器在规范里给的值是12 分钟固定值不像 T3346 那样由网络通过消息里的定时器 IE 动态下发也不像 T3396 那样分场景给不同长度。它就是一个常量。定时器跑起来之后终端进入一种“冷处理”状态不再发起普通的附着、不再发起跟踪区更新也不会去尝试重建 PDN 连接因为它连注册都没了没有可重建的对象。有一点容易搞混T3402 的启动并不等于终端彻底停止所有无线行为。小区测量、重选、系统消息接收这些照常进行射频也没有关。所以从外部看终端“还在网上”但它不会向网络发任何注册类请求。这就是为什么有些测试仪表上看不到终端有任何动作会误判成终端把协议栈卡死了。1.3 用户侧的表现为什么是“过一会儿自己好了”把这套机制翻译成用户语言就是开机 → 附着 → 被拒原因不明→ 十二分钟不理网络 → 突然自己好了。这个体验非常具有迷惑性因为中间没有任何提示状态栏可能显示 4G 图标射频注册在小区上是成功的只是 NAS 层没注册上用户会以为“有信号但网卡了”然后不断开关飞行模式。这里有个非常重要的现场细节开关飞行模式或者重启往往能让它立刻恢复。原因不是“重启修复了问题”而是 T3402 的运行状态不跨断电保存重启后定时器没了终端会立刻重新发起一次附着这时候如果网络侧的临时故障刚好过去了就成功了。这个现象在网络侧故障是间歇性的时候特别明显也是造成“用户说重启就好、你去看的时候一切正常”这种扯皮局面的根本原因。反过来如果网络侧故障是持续性的比如 APN 配置错了、签约数据缺了重启会立刻再被拒一次用户就会觉得“重启也没用”。这两种表现背后其实是同一套机制只是网络侧状态不同。分辨这两种情况看 log 里的时间戳就够如果两次 ATTACH REJECT 之间的间隔是几秒到几十秒说明是重启触发的如果间隔精确到 720 秒左右说明是 T3402 正常到期。从用户抱怨的分布看还有一类表现是“每天早上第一次上网特别慢要等十几分钟”。这种情况往往不是 T3402而是终端在夜间待机时被网络隐式去附着早上唤醒后重新附着失败了几次累计到附着尝试计数器上限才启动 T3402。看起来像同一个现象实际走的路径完全不同第 2 节会把这两条路径对比清楚。2. 把 #19 放到 cause 家族里对比才知道它有多“重”2.1 同样是拒绝#22 只让终端等几秒#19 要等十二分钟单看 #19 没什么感觉把它和其他常见 cause 摆在一起轻重立现。我整理了一张自己排障时常用的对照表覆盖了 ATTACH REJECT 和 TAU REJECT 场景里出现频率最高的几个 causeEMM cause语义终端主要动作关联定时器典型时长#19ESM failure清 GUTI/TAI 列表/ePLMN、状态置 EU3、回 DEREGISTEREDT340212 分钟#22Congestion保持当前部分状态等待后重试T3346由网络下发常见几十秒到几分钟#15No suitable cells in TA把该 TA 加入禁用列表T344224 分钟#11PLMN not allowed该 PLMN 加入禁用列表无直到手动选网或换卡#12Tracking area not allowed该 TA 加入禁用列表无同上#14EPS services not allowed视为 USIM 对该网络无效无需换网或换卡#25CS domain not available仅影响 CS 回落相关无不阻断 PS从这张表能看出一个规律cause 越“模糊”定时器越长。#11、#12 这类原因明确的终端直接拉黑名单不需要定时器等#22 这种明确说“我忙”的等一小会儿就行而 #19 说的是“会话层失败了具体为什么我不告诉你”终端只能猜网络需要多久恢复于是给了 12 分钟这个相当长的保守值。还有一个容易被忽略的差别#19 是立即启动 T3402而其他很多失败是要累计到 5 次才启动。规范里对附着尝试计数器有明确上限连续失败达到 5 次之后终端才会清身份信息并启动 T3402。#19 跳过了这个累计过程一次就把终端打进长静默。这意味着在网络侧偶发故障的场景里如果 MME 选择用 #19 而不是让终端多试几次用户体验的损失会被放大好几倍——本来试第三次就成功的附着被 #19 一搞直接变成等十二分钟。这是网络侧参数选择上很值得权衡的一个点第 4 节会详细说。2.2 T3402 取值 12 分钟的由来以及为什么不做随机化12 分钟这个数字不是拍脑袋定的它背后是一个挺典型的工程权衡。设想核心网某个网元出现短时故障如果所有终端都在几秒内疯狂重试信令面会瞬间被淹没本来就 congestion 的网元会被彻底压垮恢复时间被无限拉长。反过来如果定时器设得太长比如半小时那么网络已经恢复了终端还在那儿干等用户感知直接崩掉。12 分钟大致落在“给网络留出恢复窗口”和“用户还能忍”这两条线的交集上。有意思的是这个定时器没有做随机化。规范给的是固定值理论上如果一批终端在同一时刻被同一台 MME 拒绝它们会在同一时刻到期、同一时刻发起附着形成一个整齐的尖峰。在实际网络里我确实观察到过这种同步重试的现象一批物联网模组在同一小区几乎同时上线被拒之后又在 720 秒后几乎同时发起对基站来说那一瞬间的接入请求是密集的。有些终端实现会在到期后叠加一段随机的短延迟来打散这个尖峰这属于实现层面的取舍规范里并没有这个要求。做终端测试的时候如果发现某款设备到期后不是精确的 720 秒而是 720 加几十秒先别急着判 bug有可能是故意加的抖动。判断方法很简单连续测多次如果是固定偏移就说明是设计如此如果是每次都不一样且离散度大那才可能是计时精度问题。另外提一句 2G/3G 体系的对应关系方便做跨制式排障的人对照。老体系里也有类似的重试抑制机制量级同样是十分钟上下触发条件也包含“网络侧无法建立 PDP 上下文”这类场景。所以当你看到一个多模终端在 LTE 上被拒、切到 3G 之后又安静很久很可能不是两个独立的故障而是两套机制在各自生效。2.3 三种最容易被误认成 #19 的现场排障中最耗时间的往往不是定位问题而是先要排除“看起来像但不是”的情况。我列三个踩过的坑第一种把 ESM 拒绝当成 #19。ATTACH ACCEPT 之后紧跟一条 PDN CONNECTIVITY REJECTcause 是 ESM 层的“资源不足”或者“未知 APN”终端会走 ESM 层的退避逻辑可能带一个网络下发的定时器值不会启动 T3402。表面上都是“附着之后上不了网”但终端的行为完全不同这种情况终端保持已注册可以重试其他 APN而 #19 是彻底回到未注册。log 里一条看消息名就能区分别只看 cause 数值。第二种把附着尝试计数器耗尽当成 #19。终端连续附着失败 5 次第 5 次之后清身份、起 T3402。从终端的最终状态看和 #19 一模一样都是清 GUTI 加 12 分钟静默。区别在时间轴这种情况前面会有 4 次失败的 REJECT间隔通常是几十秒量级可能有 T3411 之类的短定时器介入而 #19 是一次到位。把前面几条消息翻出来看如果 reject 的 cause 是 #22 或者其他值那这就是累计失败不是 #19 直接触发。第三种把网络侧的隐式去附着当成 #19。终端从待机唤醒后发现被隐式去附着重新发起附着又被拒如果拒的 cause 恰好是 #19 就会同时出现两个现象。这种场景下用户感知是“待机久了就上不了网”和纯粹的 #19 场景开机即失败在时间特征上不一样。判断方法是看第一条 ATTACH REQUEST 之前有没有一段长时间的静默以及有没有 Detach Request/Accept 或者寻呼未响应的记录。这三种情况的共同点是只看终端最终状态都会得到“12 分钟静默”这个结论但根因和修复方向完全不同。我在排查时养成的习惯是无论现象多像都先把 T3402 启动点之前的那 30 秒信令完整拉出来看一遍确认最后一条驱动消息到底是哪一条。这一步花两分钟能省掉后面两个小时的瞎猜。3. 排障时怎么把 T3402 的起止时间钉死3.1 只在 NAS 层看是不够的三层信令要对着看很多人排这类问题只抓终端的 NAS 消息能看到 ATTACH REJECT 和 cause但看不到“为什么被拒”。原因很简单NAS 消息是终端和 MME 之间的对话MME 拒绝终端的时候它自己往往只是在转发一个更底层的失败。真正的根因通常在 S1 接口之外也就是 MME 和网关之间的会话建立过程。我一般的抓取范围是三层空口侧 NAS 消息确认 reject 的类型、cause 值、时间戳以及后续终端有没有异常动作。S1 接口信令看整个附着流程走到哪一步断的。正常的附着流程是Attach Request → Identity/Authentication → Security Mode → Update Location → Create Session → Initial Context Setup → Attach Accept。如果断在 Create Session 之后那问题基本锁定在核心网侧。S5/S8 接口的会话消息看 Create Session Response 里携带的原因值这是最接近根因的一层。三层对着看的好处是能把“终端看到的现象”和“网络内部的真相”串成一条线。我见过一个案例终端侧看到的是 #19S1 上看到 Create Session 请求发出去了但没等到响应S5/S8 上看到对端设备压根没回——三层信息拼起来根因是会话网关侧的一个地址解析问题和终端毫无关系。如果只看终端 log可能会一直怀疑终端定时器实现有问题。3.2 用 720 秒做标尺几种典型的时间偏差说明什么T3402 是个固定值这就给了排障一个非常好用的标尺从 ATTACH REJECT 的时间戳往后推 720 秒看终端是不是在这个点附近发起下一次附着。偏差的类型直接指向不同的问题层面。观察到的间隔可能原因排查方向约 720 秒±几秒定时器正常工作问题在网络侧查为什么被拒远小于 720 秒几秒到几十秒有事件提前解锁了定时器检查期间是否有 PLMN 变化、飞行模式、USIM 重插远小于 720 秒且多次重复定时器未生效或实现缺陷确认是否真的收到 #19检查协议栈状态机720 秒到 1200 秒之间跨睡眠计时漂移查待机场景下的计时补偿实现超过 1200 秒甚至不发起被其他禁用列表挡住查禁用 PLMN、禁用 TA 列表状态第三行那种“几秒就重试”的情况要特别警惕。这不一定就是 bug很可能终端在等待期间又收到了新的触发条件比如小区重选到了一个不属于等价 PLMN 列表的新 PLMN。因为 #19 会把等价 PLMN 列表清掉原来那些“不算换了网”的邻区现在都算新网了终端会提前解锁。这个机制是规范要求的设计上合理但在排障时容易误导人。第四行的漂移问题在物联网设备上尤其常见。这些设备大量时间在待机协议栈的定时器如果基于某种会随睡眠暂停的计数源实现实际经过的时间就会被拉长。有些平台会用真实时钟戳做补偿醒来后一次性把欠的时间补上这种情况下 720 秒还是准的。有些平台没做补偿就会看到 15 分钟、20 分钟这样的结果。这属于实现质量问题需要终端侧确认。3.3 一次完整排查链路的复盘说个具体的分析过程把前面的方法串起来。现象是某类终端在某个区域反复出现“开机后长时间无法上网”重启能恢复但不重启的话要等十几分钟。第一步抓终端 NAS 日志。确认每次失败的驱动消息都是 ATTACH REJECTcause 值为 0x13也就是 #19。并且确认了 REJECT 之后终端确实没有再发任何 ATTACH REQUEST直到约 720 秒后才重发。这一步排除了“协议栈卡死”的猜测坐实了 T3402 在正常工作。第二步看 S1 接口。发现附着流程走到 Create Session 这一步MME 向网关发了会话建立请求但返回的是失败响应随后 MME 才组了 ATTACH REJECT 回给终端。这就把责任从终端排除了问题在核心网侧。第三步看 S5/S8 的会话响应里的原因值。这一步是关键得到的值指向“资源不可用”这一类。再往上游查发现是某个地址池在特定时段被耗尽新接入的终端拿不到地址网关直接回了资源不可用的原因。第四步验证。在地址池耗尽的时间窗内做定点测试能稳定复现在非高峰时段测试复现率极低。同时观察到一个细节同样的网络条件下不同终端的行为不完全一样——有些终端拿到的是 #19有些拿到的是 ATTACH ACCEPT 加 ESM 拒绝这说明 MME 对不同终端的处理路径有差异下一节会讲原因。第五步修复与回归。网络侧扩容地址池之后复测附着成功率恢复正常T3402 不再被触发。整个链路从现象到根因大概用了两天其中大部分时间花在协调多方同时抓包和对齐时间戳上真正定位的过程其实不长。这次排查给我最大的教训是#19 这个名字有很强的误导性。它叫 ESM failure会让人下意识地去查会话层的配置但实际根因可能在更上游的资源分配。排障时不能被 cause 的命名带着走得顺着信令一层层往下钻。4. 网络侧为什么选择丢 #19 而不是回 ESM reject4.1 MME 的两条岔路拒整次附着还是只拒这个 PDN这是整个话题里最值得深挖的一点。当终端在 ATTACH REQUEST 里同时带了 PDN 连接建立请求而这个 PDN 建不起来的时候MME 面前有两条路第一条路回 ATTACH ACCEPT只做 EPS 附着 PDN CONNECTIVITY REJECT带 ESM cause。这样终端注册成功了拿到了 GUTI只是这个 PDN 没建起来。终端可以保持注册状态尝试其他 APN或者过一段时间重试这个 PDN重试的节奏由 ESM 层的退避机制控制通常比 12 分钟短得多。对用户来说最坏情况是某些应用上不了网但基础的注册、语音回落这些还是正常的。第二条路回 ATTACH REJECT #19。终端整个回到未注册接受 12 分钟静默。用户的体感是从“部分功能不可用”变成“完全不可用”。规范允许两种做法选择权在 MME。实际操作中不同网络设备厂商、不同运营策略下选择不一样。我见过的场景里选择 #19 的情况大致有几类一是网络侧配置为不允许“仅 EPS 附着”也就是没有默认承载就不让注册二是签约数据里没有该 APN 的授权MME 认为这不是临时故障让终端等也没意义三是 MME 在会话建立失败后拿不到足够的信息判断该回哪个 ESM cause索性回一个笼统的 #19。站在用户体验的角度第二条路的代价明显更大。所以做网络侧参数优化的时候如果发现某类失败被频繁映射成 #19值得评估一下能不能改成走第一条路。特别是那种“特定 APN 失败但用户其实还用着别的 APN”的多 APN 场景一次 #19 会把整个终端打瘫十二分钟损失被严重放大。4.2 S5/S8 上的 GTP cause 是怎么变成 #19 的从底层原因到 #19中间有一层映射关系理解这层映射对定位很有帮助。会话建立失败时网关回的原因值大致有这几类它们向上映射的路径不同会话层原因含义常见上游问题向上映射倾向上下文未找到网关侧没有该 APN 的上下文签约缺失、APN 配置不一致可能映射为 #19资源不可用地址池耗尽、承载资源不足容量规划不足可能映射为 #19 或 ESM 资源不足缺少或未知 APNAPN 名字对不上终端配置与网络配置不一致通常映射为 ESM 层 APN 错误请求被拒绝策略侧拒绝策略配置冲突视策略而定对端无响应超时链路问题、对端设备异常可能映射为 #19系统故障内部错误软件异常可能映射为 #19规律大致是原因越“不知道该怎么办”越容易被映射成 #19。因为 #19 本质上是一个“我这边出问题了但说不清具体是什么”的表达。而原因明确、能对应到具体 ESM cause 的比如 APN 名字错了MME 更倾向于走 ESM 拒绝让终端知道该改配置。这个规律对排障有实际指导意义如果问题是稳定复现的往往对应的是配置类错误可能走的是 ESM 路径如果是间歇性的、时段性的更容易看到 #19。因为间歇性故障超时、资源竞争恰恰是“说不清”的那一类。我在现场遇到 #19 时的第一反应就是去查时段分布看看是不是和某个高峰时间吻合。还有一层细节MME 在决定映射方式时还会考虑终端在 ATTACH REQUEST 里带的 PDN 连接请求是不是“唯一的”请求。如果终端只请求了一个 PDN而这个 PDN 失败MME 倾向于认为整个附着没有意义回 #19 更直接如果终端请求了多个虽然 LTE 附着阶段通常只带一个或者网络知道终端还有别的业务需求走 ESM 拒绝的动机就强一些。4.3 签约、APN、地址池三个高发源头从根因分布看#19 的来源高度集中在三块实际排障时可以按这个顺序查签约数据问题排第一。用户开了某个 APN 的业务但签约数据没有同步到归属服务器或者同步了但 MME 缓存的是旧版本。这种情况下MME 在会话建立时发现本地没有对应的签约信息会话建立直接失败映射成 #19 的可能性很高。特征是换一张卡在同一位置正常或者同一个用户换到别的 MME 覆盖区正常。这种“跟人走而不跟位置走”的特征是签约类问题最典型的标志。APN 配置不一致排第二。终端侧配置的 APN 名字、鉴权方式、IP 类型和网络侧预期的不一致。这种情况下起因很明确理论上应该映射成 ESM 层的 APN 错误但实际中如果 MME 没有做精细映射也可能笼统地回 #19。特征是特定型号终端或特定配置的终端出问题其他终端正常。这种“跟终端走”的特征和签约问题正好相反很好区分。地址池耗尽排第三也是最容易被忽略的。它的特征是时段性极强忙时出问题、闲时正常而且往往影响面广、不分终端型号。这类问题在物联网场景里特别常见因为物联网设备大量集中在某些时段上线比如深夜批量抄表瞬时并发远高于人网。我遇到过一次某区域每天晚上固定时段出现批量 #19查了两天才定位到地址池容量。除了这三块还有一个隐性的第四类MME 与网关之间的链路或解析问题。这类问题最隐蔽因为它是间歇性的出现在特定链路或特定网元组合上。特征是同一个用户在移动位置后可能恢复正常换了服务网元或者问题集中在某个时间段内新增的会话上链路抖动期间。这类问题往往需要多接口同时抓包才能定位单看某一层永远看不出问题。5. 终端实现里几个容易翻车的细节5.1 定时器跨睡眠漂移与“十二分钟变成二十分钟”终端侧实现 T3402 时最实际的工程问题是计时源的选择。如果协议栈用的是系统 tick 计数而这个 tick 在深度睡眠时被暂停那么实际经过的物理时间就会远远超过 12 分钟。这在手机上不太明显屏幕亮着的时候不睡眠但在物联网模组上非常突出。有些平台的处理方式是在定时器启动时记一个真实时间戳唤醒后重新计算剩余时间有些平台则简单地让 tick 停在那醒来后继续数。后者就会出现前面表格里提到的漂移现象。判断一款设备用的是哪种方式测法很简单让设备在被拒之后立刻进入待机等 15 分钟再唤醒看它是不是立刻发起附着。如果是说明用了时间戳补偿如果还要再等好几分钟说明 tick 被暂停了。这个差异对用户体验的影响不小。本来十二分钟能恢复的业务变成二十分钟甚至更久在需要定时上报的场景里会造成明显的数据缺口。做终端选型或者问题定位时这一条值得专门测一次。还有一个更隐蔽的问题定时器被意外重置。有些实现在收到某些非相关消息时会把 T3402 重新计时导致它永远走不完。典型触发是小区重选之后收到系统消息更新或者收到一条寻呼。这类问题在 log 里表现为明明应该 720 秒到期但每次快到点的时候就“重新开始”实际永远恢复不了。判断方法是看有没有周期性的某个消息反复出现且每次出现后定时器剩余时间被拉满。5.2 重启能治好的原因以及它为什么是排障陷阱前面提过T3402 的运行状态不跨断电保存。这个设计本身是合理的规范里 EMM 的很多上下文都不持久化只把必须保留的信息比如 GUTI、禁用列表写进 USIM。终端重启后从 USIM 读出状态发现没有正在运行的定时器就重新发起附着。这给现场排障带来一个很麻烦的循环用户报障 → 你去现场 → 用户说我重启过了现在好了 → 你什么都抓不到 → 过两天又报。要打破这个循环得让用户或者一线人员知道下次出问题时先别重启直接抓 log 或者拨个诊断码看状态。我一般会给一线一份简单的操作卡片写清楚“出现无法上网时先别重启保持现状记录时间点”这样才有机会抓到现场。从另一个角度看重启能恢复这个特性本身是有价值的信息。它说明问题不是永久性的否则重启也没用而是有时效的。结合 T3402 的 12 分钟周期可以推断出如果重启能恢复说明在重启那一刻网络侧是可用的中间那段时间网络发生了什么变化才是根因所在。顺着这个思路去查网络侧在那段时间的告警和日志往往能找到线索。还有一点值得提醒做测试的人验证 T3402 行为时千万不要用重启来“清零”。正确的做法是等定时器自然到期或者在测试仪表上重新构造拒绝场景。用重启清零会让测试结果失去意义因为你验证的其实是“重启后能不能附着”而不是“定时器到期后能不能附着”。5.3 换 PLMN、紧急呼叫这些可以提前解锁的例外路径T3402 虽然是个长静默但不是绝对的封锁。规范里留了几个口子理解这些口子对分析现场现象很有帮助第一个口子是 PLMN 变化。因为 #19 会清空等价 PLMN 列表终端重新选网时如果选到了一个原来在等价列表里、现在不在的 PLMN就会认为这是“新网络”从而停止 T3402 并重新发起附着。这解释了为什么用户“换个地方就好了”或者“坐地铁到下一站就好了”。反过来说如果故障是区域性的用户在该区域内怎么移动都不会好因为候选小区都属于同一个 PLMN。第二个口子是紧急业务。紧急附着不受 T3402 限制这是安全相关的设计要求任何时候都得让用户能打紧急电话。做测试时如果发现终端在 T3402 期间发起了紧急附着别当成 bug。第三个口子是用户干预。手动选网、重新插拔卡、开关飞行模式这些操作都会重置或绕过定时器状态。这也是为什么现场支撑时“开关飞行模式”成了万能第一招——它确实有效但它只是绕过不是修复。我在分析一个反复出现的现场问题时就是靠这个口子找到线索的。现象是用户在某个园区内无法上网走出园区就好。一开始怀疑是园区内的基站问题但基站侧看一切正常。后来注意到“走出园区就好”其实是因为走出了那个 PLMN 的覆盖边界触发了 PLMN 变化从而提前解锁了 T3402。真正的根因是园区内某台网元在特定时段不可用导致持续的 #19。如果不是理解了这条例外路径可能还在基站侧绕圈子。6. 怎么在实验室把这套行为完整验证一遍6.1 最小验证集四个用例覆盖全部关键分支如果要在实验室验证一款终端对 #19 的处理是否符合预期不需要把整张 cause 表都测一遍四个用例能覆盖全部关键分支用例构造方式预期行为判定要点基础触发仪表在附着流程中回 ATTACH REJECTcause 填 0x13清身份信息、状态置 EU3、启动 T3402后续 720 秒内无普通附着请求到期恢复同上保持网络可用观察 720 秒后到期后自动发起新附着时间偏差在合理范围附着能成功提前解锁触发后改变 PLMN 环境停止 T3402立即发起附着确认不是靠重启实现的不持久化触发后断电重启重启后立即发起附着验证定时器状态未保存这四个用例跑下来基本能判断终端的实现质量。第一和第二个用例验证核心逻辑第三和第四个验证边界处理。实际测试中第二个用例最花时间因为要真等 12 分钟建议用自动化脚本记录时间戳别靠人盯着。有个细节要注意构造 REJECT 时cause 值的编码要填对。#19 的十进制和十六进制容易搞混如果仪表配错成别的值测出来的行为完全不同而且不容易发现。测试前先确认仪表配置界面用的是哪种进制测完在 log 里再核对一次实际下发的字节。6.2 观察窗口和判定标准验证时的观察窗口不能只盯着 720 秒这个点要留出前后余量。我的习惯是记录三个时间点REJECT 时刻 T0、预期到期时刻 T0720s、实际发起附着的时刻。三者对齐才算通过。判定标准我一般这么定实际发起时刻落在 T0715s 到 T0740s 之间算正常超出这个范围就要看具体偏差原因。如果是固定偏移比如总是多 30 秒多半是到期后加了抖动或者有前置检查流程如果是离散的、每次都不一样的偏差那就要查计时源。还有一个容易漏掉的判定点到期后发起的那次附着流程是否完整。有些实现会在到期后发一个不完整的请求比如漏了 PDN 连接请求或者用了过期的身份信息。这种情况在仪表上表现为附着失败容易被误判成“定时器到期了但网络还不行”实际上是终端状态清理得不干净。检查方法是看那次 ATTACH REQUEST 里的身份字段是不是空的应该用 IMSI 而不是已删除的 GUTI以及 PDN 连接请求是否正常携带。最后分享一个我在实际排障中养成的习惯每次遇到 #19不管最后查到什么原因都把这一条的完整时间线记下来——REJECT 时刻、cause 值、上游原因、T3402 是否正常到期、到期后是否恢复。攒够十几条之后你会发现规律非常明显哪些是网络侧配置问题、哪些是容量问题、哪些是终端实现问题分布一目了然。这个过程比看任何文档都管用因为它是从你自己的网络里长出来的经验。