企业官网建设流程全解析

前几天一个项目现场的群里炸了锅：用户投诉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 Request，UE却没有返回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是18，ESM cause才单独看

还有一个非常容易忽略的点：当MME因为ESM层的原因拒绝attach时，它在EMM层填写的cause通常是#18，即“ESM failure”，而真正的拒绝原因放在ESM消息容器里，也就是我们关心的ESM cause#19。所以抓包的时候你会看到一条Attach Reject消息里同时出现两个原因值：EMM cause=18、ESM cause=19。

我见过不少同事拿着信令只看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 Request，MME回Attach Reject（EMM cause#18，ESM cause#19），UE等一段时间再发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 一张症状速查表，现场直接对照

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 Reject，ESM 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消息的ProtocolConfigurationOptions（PCO）字段上。异常车机在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 常见误区速查表

后来我把这类ESM层#19问题做成了排查卡片，固定在每次处理类似投诉时先跑一遍“ESM对话对账”。说实话，这类问题最坑的不是技术难度，而是现象和无线质量太像，容易让人在错误的方向上消磨时间。我个人最深的一个体会是：遇到attach被拒，先别急着跑路测，先看信令里有没有ESM Information Request/Response的影子。只要这一步对了，后面无论查到哪一层都能说清楚为什么，处理起来自然也就快了。