去年在外场做LTE拉网测试测试车刚拐进一条城乡结合部的小路手里的测试终端突然出现一种很“拧巴”的状态状态栏明明显示着4G满格可数据业务就是起不来浏览器转圈圈下拉状态栏里数据连接一直卡在“正在激活”。我下意识开关了一次飞行模式才恢复正常。回放log的时候问题锁定在一次attach上——网络侧回了Attach Reject拒绝原因值写着#19。刚看到这个值的时候我还闹了个笑话翻遍了EMM cause列表也没找到#19是啥意思。后来才反应过来这个#19根本不是EMM层的cause而是ESM层的cause #19ESM information not received翻译成人话就是“网络在等UE上报ESM信息结果UE一直没给”。这篇文章就把这个拒绝码的来龙去脉、信令表现、定位方法和规避建议掰开揉碎讲一遍给做LTE外场测试、终端协议栈或者核心网维护的朋友做个参考。1. 第一眼看到#19别去EMM cause表里找1.1 两套cause code最常见的坑就在这LTE的NAS信令里cause code是分层的。EMMEPS Mobility Management管移动性ESMEPS Session Management管会话。Attach流程从消息名上看是EMM层的活但Attach Request里会裹着一个PDN Connectivity Request那属于ESM流程。所以当网络要拒绝一次attach时拒绝原因可能有两种落点落在EMM cause里比如常见的#7 EPS services not allowed、#11 PLMN not allowed、#13 roaming not allowed、#15 no suitable cells in tracking area这些大家都熟。落在ESM cause里比如#8 operator determined barring以及今天要说的#19 ESM information not received。问题就出在这很多人习惯性拿着#19去24.301的EMM cause表里查翻到最后也没这个值。因为EMM cause表里压根没有#19。这个#19是ESM cause真正的语义是“ESM信息没收到”。这在现场定位时是第一道坎也是很多人觉得#19“冷门”“不好查”的根本原因。我自己的习惯是看到这种不在预期位置出现的cause值先别急着怀疑规范版本先确认log窗口里到底是哪条消息携带了这个cause。很多时候看着像Attach Reject带#19其实是Attach Reject消息里嵌套的ESM cause字段。层Cause值常见语义拒绝节奏EMM#7EPS服务不允许立即拒EMM#11该PLMN不允许立即拒EMM#13该跟踪区不允许漫游立即拒EMM#22拥塞延迟后拒ESM#8运营商阻断立即拒ESM#19ESM信息未收到等超时后拒这张表是我自己在现场总结的看cause先看层再看节奏方向基本不会跑偏。1.2 网络为什么要中途向UE要“ESM信息”正常的attach流程里UE发出的Attach Request是打包了几层信息的外层是EMM的attach类型内层是一个PDN Connectivity Request里面带着APN、PCOProtocol Configuration Options等会话参数。但UE并不是每次都把话说明白。比如UE上报的APN是空的或者网络侧基于用户签约策略必须让UE明确提供一个APN这时候MME就不能继续往下走了它得先向UE单独发起一条ESM Information Request问UE要缺失的信息。这条消息里可能包含“请提供APN”“请提供PCO”等请求项。网络发出这条请求后会启动一个等待定时器规范里叫ESM information request timer具体时长不同设备商配置不一样常见在数秒到十几秒量级。在这个时间内UE必须回一条ESM Information Response把APN等信息补上来。如果超时了还没等到MME就只能中断attach流程下发Attach Reject携带ESM cause #19。这里面有个容易被忽略的点如果核心网配置了Default APN兜底UE带空APN也没关系网络自己会补一个签约默认APN往下走。但如果MME被设置成“必须由UE上报APN”这种强制策略那UE一旦APN为空又没有及时回ESM信息#19就是顺理成章的结果。换句话说#19的出现往往不是网络“无缘无故拒人”而是网络“等了该等的信息没等到”。2. 被cause #19拒绝时整条链路长什么样2.1 信令表现先等一段时间再拒绝被#19拒绝的最大特征不是“秒拒”而是“等了一会儿才拒”。我们可以对比一下如果UE非法、签约不对、PLMN不允许MME收到Attach Request后几乎立刻就能回EMM cause毫秒级到几百毫秒级就下来了这个节奏很快。但#19的Attach Reject一般会出现在Attach Request发出后的数秒之后。中间的间隔就是网络侧在等ESM Information Response的定时器窗口。整体信令时间线基本是固定的UE发Attach Request内含PDN Connectivity RequestAPN为空或信息不全。MME下发ESM Information Request请求UE补交APN/PCO等信息。之后没有任何来自UE的有效响应。定时器超时MME下发Attach RejectESM cause为#19。抓包时最扎眼的不是最后的Reject而是第2步到第4步之间那一大段“空白”——正常的attach流程此时应该在鉴权、加密、上下文建立等环节飞快推进而#19场景下整条链路像是卡住了一样直到超时才吐出一个Reject。有个细节需要提醒并不是所有#19前都必然能看到ESM Information Request。外场log如果只在UE侧抓偶发情况下下行这条NAS消息可能因为空口问题没到UE看起来就像是“网络无端拒绝”。所以判断时必须结合网络侧log或至少结合时间间隔来推断。2.2 终端表现有信号、没数据、时好时坏从终端侧看#19的表现很有迷惑性。状态栏显示4G/LTE信号满格但数据业务完全起不来。图标上可能出现“感叹号”或“x”部分终端会一直显示“正在连接”。有些终端在attach reject后不自动重试必须开关飞行模式或者重启才能再发起一次attach。有些终端则会周期性自动重试表现为信号栏在“4G—无服务—4G”之间来回跳整机功耗明显上升。最坑的是如果你只盯着UE状态看很容易误判成“覆盖不好”或者“网络拒绝服务”。因为信号是满的但业务就是起不来。这种“看起来像覆盖问题、实际是NAS层拒绝”的情况在外场测试报告里特别容易写错方向。2.3 两个真实复现画面场景A外场拉网。某款测试终端配着一张测试卡到了一个固定路段必现“有信号无数据”。我把另一部手机拿出来同一个位置、同一张卡附着正常业务正常。反复验证几次后确定是这款测试终端的APN配置被刷空了重新填上运营商默认APN后问题消失。场景B实验室核心网仿真。MME侧开启了“UE必须上报APN”的策略测试SIM卡的默认APN是空的。UE每次attach都带着空APN发送PDN Connectivity RequestMME下发ESM Information Request后由于终端应用层拿不到可用的APN始终没有回ESM Information Response。结果就是每轮attach都以#19收场。把SIM卡默认APN补上后问题同样消失。这两个场景一个在外场、一个在实验室但根因本质上完全一样UE没法向网络提供它想要的那份ESM信息。3. 定位#19的完整排查链路3.1 先切故障域网络、空口还是终端遇到#19我建议先别急着下结论先做一次“故障域切分”。切分方法很简单就三个问题网络到底有没有下发ESM Information Request如果下发了UE有没有收到如果UE收到了UE为什么没回或者回了但网络为什么没收到这三个问题分别对应网络侧、空口侧、终端侧三个故障域。排查顺序建议按照“先看时间间隔再做替换实验最后抓log细看”的节奏走。时间间隔是最容易看的。如果Attach Request和Attach Reject之间的间隔在数秒量级基本可以先认定是“等待ESM信息超时”。如果间隔只有几十毫秒那多半是另一个cause的立即拒绝只是log工具显示上让人误读了。3.2 空口弱覆盖导致的有发无收怎么证实外场偶发的#19有相当一部分和空口质量脱不开干系。ESM Information Request是网络下发给UE的下行NAS消息它承载在SRB上。如果当时下行质量很差这条消息在空口丢了UE压根不知道网络在问它要信息自然不会有响应。另一种情况是UE确实回了ESM Information Response但上行PUSCH连续误块、重传耗尽消息没能到达网络网络照样等到超时。怎么证实是空口的问题看这几项RSRP和SINR如果RSRP低于-115dBm甚至-120dBmSINR低于0dB空口因素优先级直接拉满。上行重传率和PUSCH BLER上行质量差的直接证据。RACH过程看UE是否经历了多次前导码重试才完成随机接入。该位置下是否多部终端都偶发同样问题如果换几部手机都偶发空口嫌疑更大。一个比较灵验的判断技巧空口引起的#19往往是偶发的不是每次attach都必现而且多伴随弱覆盖、高重传、切换等场景。如果你发现某个位置“命中率100%”那大概率不是空口问题而是卡或终端APN这种确定性因素。3.3 终端协议栈与APN配置的典型死穴如果空口没问题把目光收回终端侧最常见的坑有这么几类第一UE的NAS状态机没有正确处理ESM Information Request。有些终端在收到ESM Information Request后因为内部模块协调问题直接忽略了这条消息连log里都看不到任何处理痕迹。这类问题通常要靠升级终端基带版本解决。第二UE收到了Request但内部没有可用的APN应用层和NAS层之间没能协调出有效响应。这部分终端会比较“犟”它知道自己没有APN可交干脆就不回ESM Information Response而不是回一条带空APN的响应。从网络侧看就是“要信息要不到”。第三终端APN配置界面为空尤其是测试终端。测试终端在刷机、恢复出厂设置后APN配置经常会被清空而默认的“空APN”并不可靠。很多测试工程师习惯性地忽略这一步结果就栽在这种基础配置上。第四定制ROM或测试软件篡改了APN配置。比如某些抓log工具、自动化测试工具会强制清除APN造成attach时无法携带有效APN。3.4 SIM卡和测试卡责任比想象中更大外场测试里测试卡背的锅真的不少。运营商开卡的时候如果SIM卡/USIM卡内部没有写入默认APN或者写入的APN格式不正确UE在attach时能拿到的APN就是空的。落到信令上就是PDN Connectivity Request里的APN字段为空。这时如果网络侧没有默认APN兜底也不主动分配签约APN而是反过来向UE要那一拍即合的#19就出现了。所以排查#19时不要把换卡当成最后手段直接从一开始就纳入替换实验。换一张普通商用手机卡如果问题立刻消失那测试卡开户数据就是根因。卡商那边主要确认两件事一是默认APN是否写入二是APN的接入点名称是否与当地运营商网络匹配。3.5 核心网侧的配置与定时器影响最后再给网络侧留个位置。虽然我遇到的#19大部分是终端或卡的问题但网络侧也确实有“贡献”。有些MME被配置成强制要求UE上报APN这一策略本身就会放大终端侧APN为空的故障面。ESM信息等待定时器如果配置过短遇到UE反应稍慢或者空口一次重传就容易超时误杀。核心网版本bug或者信令面处理异常出现“ESM Information Request发出后没有正确监控响应”的情况。这种情况比较罕见但我也在实验室见过表现为网络定时器超时记录和实际消息时间对不上。确认方式就一条去MME侧抓该用户完整信令看ESM Information Request的发送时间、定时器启动记录、以及超时时间点。如果网络侧日志里显示Request根本没发出去那就是网络的问题如果发了但UE没收到重点查空口链路。4. 外场与实验室的复现和抓log实操4.1 抓log的正确姿势和关键观察点在外场复现#19抓log的方式和普通掉线问题不太一样因为问题点集中在NAS层且往往只发生在attach这一下错过就没有了。终端侧log建议这样抓先把log工具打开并处于记录状态然后通过开关飞行模式触发一次完整attach。如果怀疑是空口因素可以多开关几次、换个弱信号位置多试几轮。抓完之后重点看以下四个观察点PDN Connectivity Request里的APN字段是否为空。UE是否收到了ESM Information Request。UE是否发出了ESM Information Response。如果UE发了ResponseRRC层有没有确认这条上行消息发送成功。网络侧log则直接看这个IMSI在MME侧的完整流程确认ESM Information Request是否发出、定时器是否正常启动、超时记录是否准确。这里尤其要注意如果只抓UE侧log发现UE收到了ESM Information Request但没有发出Response也别急着100%断定是UE问题还得结合空口上行质量一起判断。有时候UE内部生成了Response但一直没能被RRC层调度发送出去从NAS层看就是“没发”。4.2 一条典型的#19时间线到底该怎么读下面是一条典型的#19信令时间线示意我在log里见过很多次类似结构t0.000 UE - MME ATTACH REQUEST PDN CONNECTIVITY REQUEST APN: (empty) t0.120 MME - UE ESM INFORMATION REQUEST (request APN) ...... 静默 ...... t5.232 MME - UE ATTACH REJECT ESM cause: #19 (ESM information not received)注意这里的时间数值只是示意真实的等待时长取决于MME的定时器配置。但结构是高度统一的中间那段“静默”才是关键证据。如果看到这种时间线优先检查UE为什么没有在收到ESM Information Request后及时回Response。读log还有一个技巧看Attach Reject消息里的EMM cause和ESM cause是不是同时存在。有些log工具会把cause显示得很简洁只漏出一个数字#19容易让人误以为这是EMM cause。把消息内容完全展开你才能看清到底是哪个IE携带了#19。4.3 快速定位三板斧换机、换卡、看APNlog能给你证据但外场问题讲究“快”。我总结了一个三步替换法遇到#19时直接按顺序执行大多数情况下不用等到详细log分析就能定位。第一步换一张正常的商用手机卡。问题消失说明测试卡开户数据或默认APN有问题。问题还在进入下一步。第二步换一部不同的终端同一个位置、同一张测试卡。问题消失说明终端APN配置或协议栈实现有问题。问题还在重新考虑空口和网络侧。第三步不换机不换卡手动把终端的APN设置为运营商默认值然后重新attach。问题消失说明原APN配置为空或错误。三步走完十有八九能砍掉90%的根因。剩下的少数情况再结合MME侧日志和空口质量进一步排查。5. 解决、规避以及我在实践中总结的经验5.1 终端侧和卡侧怎么修如果定位在终端侧修复手段按优先级排在终端APN设置界面手工补全运营商默认APN。升级终端基带版本或NAS协议栈版本修复ESM状态机异常。恢复出厂设置清理测试软件对APN配置的篡改。如果终端插的是测试卡联系卡商确认默认APN是否写入、是否和现网匹配。卡侧也是一样不要只盯着“电话能打、短信能收”这种基本功能APN参数是独立开户项必须单独确认。5.2 核心网侧怎么优化和兜底网络侧的优化核心是“不要让UE的信息缺失成为不可绕过的坎”MME或用户签约数据中配置Default APN做兜底UE空APN也能正常建会话。如果必须走ESM Information流程把等待定时器设置在一个合理范围内避免太短误杀。具体取值不同厂商有不同的推荐值我之前接触过的设备普遍在5秒到15秒之间具体按设备商建议来。谨慎开启“强制UE上报APN”策略。这个策略本身不是问题但它会让所有终端APN为空的用户一起撞墙放大故障面。网络侧的修改通常要经过程序变更和回归测试但其中“配置Default APN”这一项对消除#19非常有效。5.3 外场遇到#19如何先让测试跑起来外场测试遇到#19如果只是为了先让业务跑起来、保证测试进度有几个临时手段开关飞行模式强制UE重新发起attach。多数情况下一次重启附着就能恢复。锁定信号较好的band或小区后重新附着。弱覆盖引起的偶发#19锁band之后往往就不再出现。如果用的是CPE、无线路由器这类插卡设备优先检查设备后台的APN设置不要默认它自动配置。这类设备没有手机那么智能APN留空的问题我见得太多了。复位测试卡数据或重新插拔SIM卡排除接触不良导致的USIM读取失败。个人体会在LTE外场测试里attach被cause#19拒绝属于那种“看着像网络问题、实际多半是终端和卡的问题”的场景。我踩过最深的坑就是一开始对着MME日志查了半天最后发现只是测试终端的APN被刷空了。现在我在外场测试前都会先确认三件事测试卡默认APN、终端APN界面、以及该型号终端是否有已知的ESM信息处理bug。这三件事确认完#19基本不会成为意外惊喜。