前几天一个项目现场的群里炸了锅用户投诉4G信号满格但刷不了视频、微信只能收个“正在连接”VoLTE也注册不上。后台工程师拉指标一看MME的Attach Reject次数蹭蹭涨按Cause值一分类排第一的就是cause#19。我当时第一反应也以为是普通附着失败结果越查越发现这条原因值和EMM层的cause完全是两码事。排查到后面锁定问题出在MME等待ESM信息超时前后绕了不少弯路。今天把整个分析过程写透帮大家把LTE网络attach被cause#19拒绝的表现、定位思路和典型案例一次性讲明白。1. 先搞清楚cause#19到底是谁发出来的1.1 cause#19的标准定义和触发位置cause#19在协议里的正式名字是“ESM information not received”翻译过来就是“ESM信息没有收到”。它属于ESM cause也就是EPS会话管理层的返回值定义在3GPP TS 24.301的9.9.4.1里。很多人一看到“cause”就默认是EMM层的原因值这个直觉在这里会带偏方向。EMM层管的是移动性管理比如位置更新、附着流程本身是否被接受ESM层管的是会话管理比如PDN连接请求里的APN、PCO、QoS参数能不能被网络接受。attach虽然是一个EMM层流程但在这个流程里会内嵌一个ESM消息容器用来承载UE的PDN Connectivity Request所以两个层的cause会同时出现。ESM information not received这个返回值字面意思已经很清晰网络侧等它需要的ESM信息但没等到或者等到的内容被协议栈判定为“不完整”。最常见的场景是MME已经向UE下发了ESM Information RequestUE却没有返回ESM Information Response或者UE返回了但消息里的关键信息域缺失、长度异常被MME的解析模块丢弃。无论哪种情况MME最终都会在Attach Reject消息里把ESM cause置为19。这里还要注意一个相近原因值cause#20“ESM information is invalid”意思是“收到了但内容非法”。现场经常看到#19和#20混在一起出现但根因完全不同。#19更偏向“消息没到”或“被判定为没到”#20更偏向“消息到了但格式或取值有问题”。排障时先把这个区分开能少走很多弯路。1.2 为什么EMM cause是18ESM cause才单独看还有一个非常容易忽略的点当MME因为ESM层的原因拒绝attach时它在EMM层填写的cause通常是#18即“ESM failure”而真正的拒绝原因放在ESM消息容器里也就是我们关心的ESM cause#19。所以抓包的时候你会看到一条Attach Reject消息里同时出现两个原因值EMM cause18、ESM cause19。我见过不少同事拿着信令只看EMM cause看到#18还在奇怪“ESM failure是什么东西”完全没注意到下面还有一层ESM cause。实际上EMM cause#18只是一个“总括性”提示告诉你“问题出在会话管理层”具体是什么会话管理问题必须展开ESM message container才能看到。这也是为什么很多网上文章只写“attach被cause#19拒绝”却不说明白来龙去脉直接导致新手排查时被带偏。理解了这个层级关系后面所有排查步骤才有意义。2. 被#19拒掉之后终端侧、无线侧、核心网侧各是什么表现2.1 终端侧表现信号满格业务“假活”用户感知层面的表现很有迷惑性。手机状态栏上4G/LTE图标是正常的信号格数也是满的因为网络侧并没有把终端踢出LTE也没有让它重选到别的制式。但真正要建立数据PDN连接或者IMS PDN连接时终端会被MME拒绝于是出现“有信号但上不了网”的典型症状网页转圈、微信收不到消息、VoLTE拨号失败或者拨出后被静默挂断。部分终端的处理更激进收到Attach Reject后不会停在原地而是按自己的退避策略定时重试。我实测过一款手机每12秒到30秒左右就会重新发起一次attach状态栏的4G图标会间歇性变成“无服务”又恢复用户看着像“信号不稳定”实际上无线覆盖完全正常。还有一个容易误判的点如果终端同时请求多个PDN比如默认APN加IMS APN可能默认数据PDN先成功了IMS PDN被#19拒绝。这时候用户打电话会失败但上网是好的状态栏4G也是正常的。很多人会往VoLTE注册和IMS配置方向排查如果一下子扎进终端IMS设置里很容易忽略真正问题在网络侧ESM流程。所以记录现象时一定要分业务类型数据业务能不能通、语音业务能不能注册、短信能不能收发分开测避免被“部分成功”带跑。2.2 网络侧表现KPI不一定会炸但信令一定有异常从无线侧看问题往往没有存在感。因为NAS层消息在空口和S1口上对eNB来说只是透传RRC连接建立成功率、切换成功率这些常规无线KPI基本不会劣化。eNB侧顶多能看到某几个小区下UE发起的RRC连接请求频率略高但如果拒绝事件分散在各小区这点波动根本不会引起注意。这也是#19问题经常在前期排查中被当成“无线质量差”或“终端问题”压下来的原因。真正能看到异常的地方在MME侧。按IMSI做单用户信令跟踪会看到一串规律性的循环结构UE发Attach RequestMME回Attach RejectEMM cause#18ESM cause#19UE等一段时间再发Attach Request又被拒。从MME的Attach成功率指标看可能从正常的99.8%掉到95%甚至更低具体掉多少取决于受影响用户占全部附着用户的比例。如果只是个别漫游用户受影响总指标可能根本看不出来。核心网侧还有一个隐蔽现象MME和PGW之间的接口上可能根本看不到这条用户触发的Create Session Request。因为#19是MME在ESM流程早期就拒绝的还没走到去PGW建会话那一步。这个特征可以用来区分故障环节如果MME已经发了ESM Information Request但没收到响应PGW侧肯定没有信令如果PGW侧有Create Session Request但返回了失败那ESM cause往往不是#19而是#26“资源不足”或#31“非特定原因”之类。这一点在现场非常有用。2.3 一张症状速查表现场直接对照观察层面常见表现初判方向用户侧4G信号满格数据/语音无法使用图标正常网络或终端排除无线覆盖终端信令Attach Request → Attach Reject循环重试网络侧ESM流程或终端参数异常空口/RRCRRC建立成功率正常eNB无告警问题不在无线接入侧S1口可见NAS透传的正常/拒绝消息重点看MME是否下发ESM Info RequestMME侧Attach Reject计数上升Cause分类中#19比例高MME配置、HSS签约、链路时延PGW侧无该用户的Create Session请求确认为ESM早期拒绝非PGW侧负载问题3. 现场排查实操从IMSI级跟踪到ESM信息核对3.1 第一步先做归类而不是盲查拿到“大量用户被#19拒”的反馈我习惯先按三个维度归类时间、用户、APN。时间上要区分是持续发生还是忙时发生忙时发生往往和核心网侧链路负载、HSS响应时延相关用户维度要区分是不是都集中在某个终端品牌、某个软件版本、某类漫游用户如果只有某款车机或某批定制终端出问题终端协议栈的嫌疑会立刻上升APN维度则要看被拒的是默认数据APN、IMS APN还是其他专网APN这样的判断直接对应不同的PGW选择策略和签约数据。归类这一步看起来简单却能快速缩小范围。我在现场见过最典型的错误是一上来就让网管把所有被拒绝用户筛出来拿着一张几万行的Excel列表发呆既没有时间聚类也没有型号聚类最后只能逐条看信令效率极低。合理的做法是先拉一个小样本比如随机取50个被拒IMSI把时间、终端型号、漫游状态、请求的APN列个交叉表再决定下一步查谁。3.2 第二步抓包抓对地方MME侧和终端侧都必须有日志IMSI级信令跟踪是必须做的。网管侧先把故障时段、故障IMSI拿到手在MME上做单用户信令跟踪能看到这条用户从附着开始到被拒的全部NAS消息。核心要点是保存Attach Reject的完整原始消息体不要只看解码后的summary。因为解码界面可能会把ESM message container收起来不主动展开就看不到ESM cause#19。终端侧日志同样重要。用路测软件抓LTE log或者直接在终端上开工程模式抓modem日志。高通平台的手机用QXDM/QCAT抓海思平台用自带LOG工具目的只有一个确认终端是否收到了MME下发的ESM Information Request以及终端有没有回ESM Information Response。这里有个实操细节抓终端log时要把“定时器超时”和“3GPP NAS消息”都打上开关否则modem层收到Reject后可能只记一条原因值看不到完整的消息流转。如果条件允许S1-MME口的信令也最好抓一份用核心网侧或者分光器在SCTP链路上抓。抓S1口的目的不是看NAS内容——那是透传的而是为了判断eNB和MME之间是否出现了丢包、乱序、SCTP断链重连等传输层问题。很多#19最终定位到“UE回了一条ESM Information Response但没到MME”这种丢包在物理层和IP层都可能发生没有S1口抓包根本说不清。3.3 第三步核对ESM Information Request/Response的对账结果这是整个排查的核心判断点。把MME侧和终端侧的日志放到一起按消息交换的先后顺序做一张时间线重点回答三个问题第一MME有没有下发ESM Information Request第二如果下发了终端有没有收到第三终端如果收到了并回了ESM Information Response这条响应到底到没到MME如果MME压根没发ESM Information Request那就不存在“等不到响应”的问题MME是主动拒绝的根因大概率在MME的初始解析逻辑、HSS签约数据或APN授权策略。如果MME发了终端侧log却完全没有收到记录那问题在空口或eNB透传可能RRC层丢了NAS容器也可能eNB在S1口转发时出了问题。如果终端回了MME却没收到那问题集中在传输链路或MME收包解析环节。如果MME收到了却仍然判#19那就要仔细核对ESM Information Response里的具体参数APN是否带空格、大小写是否和签约一致、PCO里的TLV是否完整、PDN类型是否无效。这种逐级对账的方法能把一个看似玄学的问题拆成几个明确的物理环节每次排查都能有明确结论。3.4 常用过滤和分析语句拿去就能用排查时经常要筛选信令这里给几个我自己常用的小工具Wireshark里过滤Attach Reject消息可以这样写nas_eps.nas_msg_emm_type 0x44过滤EMM cause为18且ESM cause为19的Attach Reject可以写成nas_eps.nas_msg_emm_type 0x44 nas_eps.esm_cause 19提示不同版本的Wireshark字段名可能有细微差别如果过滤不到先在某个Attach Reject消息上右键“Decode As”确认实际字段名。后台网管侧如果用脚本辅助统计可以拉MME的Attach Reject按Cause分类数据伪代码思路如下select MME_ID, APN, EMM_CAUSE, ESM_CAUSE, COUNT(IMSI) from ATTACH_FAIL_STAT where TIME_SLOT in (故障时段) group by MME_ID, APN, EMM_CAUSE, ESM_CAUSE order by COUNT(IMSI) desc;实际操作时各家网管的表结构不一样但按MME、APN、EMM cause、ESM cause四个维度分组统计能最快找出受影响用户群的规律。4. 两个真实案例复盘4.1 案例一漫游用户批量被拒根因在MME定时器与HSS链路时延某地市项目反馈部分漫游用户到达本地后无法使用数据业务4G图标正常但PDP/PDN始终建不起来。MME按原因值统计发现#19占比接近30%故障集中在每天上午9点到11点以及下午3点到5点这两个时段恰好是HSS接口业务高峰期。抓取单个漫游用户的IMSI级信令发现MME确实下发了ESM Information Request但终端迟迟没有返回ESM Information Response过了一段时间MME直接回Attach RejectESM cause#19。这里有个关键细节终端侧log显示终端已经收到了ESM Information Request并且在一两百毫秒内就回了ESM Information Response。也就是说响应是发出去的但MME没收到。继续往链路查发现STa接口MME与HSS之间的接口在忙时出现偶发的高时延APN授权过程从平时的100毫秒左右飙到3秒以上。MME侧配置的ESM等待定时器被前一个维护人员从默认10秒改成了3秒结果漫游用户在忙时恰好触发了“授权链路高时延 等待定时器偏短”的组合MME的ESM流程判定超时直接拒绝。解决办法分两步第一步把MME的ESM等待定时器调回厂商推荐值10秒第二步协调HSS侧优化STa接口链路质量。调整后#19次数立刻下降第二天恢复正常。这个案例给我们的教训是定时器参数不是随便调的尤其是ESM层面这类由网络侧主动等响应的流程缩短等待时间会牺牲大量本可以成功的用户不是网络优化是自找麻烦。4.2 案例二同一车型集中爆发根因在终端PCO长度字段写错另一个项目里某运营商新接入一批车联网终端车机在开通当天有大量集中attach被拒后台统计同样指向ESM cause#19。和常规情况不同的是这个故障不挑时段、不挑位置只要用这款车机就会出现同批次其他品牌终端全部正常。按“终端型号”维度聚类时问题已经比较明显了。抓取该车机的modem日志再对比同场景下正常终端的日志差异点落在PDN Connectivity Request消息的ProtocolConfigurationOptionsPCO字段上。异常车机在PCO里添加了厂商自定义的扩展TLV但计算TLV总长度时用了单字节计数导致长度字段溢出整个PCO区域被MME的ASN.1/协议解析模块判定为不完整。MME在ESM流程里把这个“不完整的ESM信息”当成“没收到ESM信息”处理统一回#19。这个案例里无线侧和核心网侧都没有改动任何配置最终的解决办法是联系车机厂商升级基带协议栈版本。排查过程中最耗时间的不是定位到终端而是确认“消息确实到了MME且格式被拒”这一步靠的是MME侧抓包和终端侧log逐字段比对。如果一开始就怀疑核心网配置而忽略终端侧日志可能要多折腾好几天。5. 排障中积累的几条冷门经验和常见误区5.1 经验一ESM Information Request/Response是否出现是整个排障的分水岭我排查#19的固定动作是先把这条时间线上的“ESM对话”完整画出来MME有没有问、终端有没有答、网络有没有收到。这三个问题的答案直接决定了下一步是查MME配置、查空口传输还是查终端协议栈。这条规则看起来简单但在实际操作中非常高效。如果MME没有下发过ESM Information Request核心问题就是“MME为什么在信息不完整的情况下直接拒绝”一般看HSS签约、APN匹配、MME对PDN Connectivity Request的首包解析。如果MME下发了但终端没收到问题在RRC/S1透传那一层。如果终端回了但MME没收到问题在传输层或SCTP链路。如果终端回了MME也收到了还继续拒再去查消息体内部的参数细节也不迟。按这条主线走基本不会出现“查了半天不知道查哪”的尴尬。5.2 经验二一定要双层看cause别被EMM cause带到沟里再强调一次Attach Reject的EMM cause字段填#18只是提示“ESM failure”真正的故事在ESM message container里。有些网管平台的日志展示只解析到EMM层显示一个淡淡的“#18”不点开内部容器看ESM cause很容易让人误以为问题是“EPS业务不允许”之类的EMM级错误。我在一台MME的告警导出里就见过“Cause: EMM#18”这种让人一头雾水的描述。所以拿到故障反馈时第一件事就是确认成功抓到的Attach Reject原始消息里ESM层的cause值是这个值才决定后续排查方向。如果是19按本文思路走如果是20重点放到“信息无效”而不是“信息未收到”。这两个cause的处理路径差异很大合并处理容易错过真正根因。5.3 常见误区速查表误区实际可能情况建议看到#19先怀疑无线覆盖eNB透传NAS无线KPI可能完全正常先抓IMSI信令再谈无线只看EMM cause#18就结束真正的信息在ESM层cause里展开ESM message container把所有#19用户堆一起处理可能分属不同根因漫游/终端/APN按时间、终端、APN聚类重试后恢复就认为不用管了UE会按退避时间自动重试网络侧故障仍存在抓故障时的信令别等“自愈”只查MME不查终端日志很多#19是终端私有参数写错双端日志对账缺一不可后来我把这类ESM层#19问题做成了排查卡片固定在每次处理类似投诉时先跑一遍“ESM对话对账”。说实话这类问题最坑的不是技术难度而是现象和无线质量太像容易让人在错误的方向上消磨时间。我个人最深的一个体会是遇到attach被拒先别急着跑路测先看信令里有没有ESM Information Request/Response的影子。只要这一步对了后面无论查到哪一层都能说清楚为什么处理起来自然也就快了。