LTE外场测试信令排查：Attach与Service Request流程深度拆解

干LTE外场测试这几年，我见过最多的画面不是设备故障，而是一群工程师对着LOG里一屏红色信令干瞪眼。手机信号格明明满着，业务就是起不来，测试计划卡在那里，客户在旁边越催越急。这种时候，能不能把这屏信令从上到下读明白，直接决定了你是提出问题的人，还是解决问题的人。

先说个基本定律：数据不动，信令先行。UE每一次从无网络状态到注册成功，从空闲态恢复数据业务，背后都是NAS层和AS层两条信令链在协同工作。而其中最核心的两条流程，就是Attach（附着）和Service Request（业务请求）。只要你把这两条链吃透，后面查VoLTE时延、5G回落、VoNR信令，用的都是同一个底子。

这篇东西不打算写教科书式的协议原文，而是按外场测试的真实视角来拆：Attach到底怎么一步步完成的，Service Request为什么经常在空闲态翻车，出问题时日志里该看哪条消息、哪个字段，以及我踩过的一些坑。

1. 为什么Attach与Service Request是测试里最值得先啃掉的两条信令链

1.1 外场测试里最常见的困境：手机有信号但业务起不来

测试中经常遇到的现象是：终端显示LTE信号满格，但拨不了电话、点不开网页、拉不起视频流。很多人第一反应是“核心网故障”或者“基站问题”，其实很多时候问题就出在信令流程本身——要么Attach没有成功，UE根本没注册进网络；要么Service Request触发了，但空口上下文建立失败，用户面数据通道压根没搭起来。

我在项目里带过不少新人，发现他们有个共同习惯：看到失败第一件事是截图，然后问别人“这是什么原因”。但你要问他“这条失败消息是从哪个网元发出来的”“它属于NAS层还是AS层”“之前一条消息是什么”，往往答不上来。信令排查的第一步不是猜原因，而是先把流程位置定住——就像看病先分科，你至少得知道是骨科还是内科的问题。

Attach和Service Request恰恰覆盖了两种完全不同的定位场景。Attach解决的是“网络认不认你”的问题，涉及签约、鉴权、位置更新、默认承载建立，失败原因大多在NAS层能直接看到原因值。Service Request解决的是“网络怎么把你从挂起状态叫醒”的问题，涉及RRC建立、UE上下文恢复、DRB重建，失败原因往往分散在空口和S1接口两侧，排查思路跟Attach有本质区别。

1.2 NAS层与AS层：信令流程里的两条腿

要读懂LTE信令，脑子里必须绷着一根弦：信令是分层的，一条完整流程往往要穿过AS（Access Stratum）和NAS（Non-Access Stratum）两层。

打个比方。AS层是小区门口的保安，负责你进小区这一段的秩序——随机接入、RRC连接建立、无线承载配置，都归他管。NAS层是物业中心，负责更上层的事务——你叫什么名字、住哪栋楼、有没有交物业费、门禁卡能开哪几扇门，这些由MME（移动性管理实体）和UE之间的对话决定。Attach Request、Authentication、Attach Accept这些都是NAS消息，但它们不能自己飞，必须搭在AS层建立的RRC连接上走。

这个关系在LOG里非常直观。你打开测试软件看到的第一条信令往往是RRC Connection Request，然后是RRC Connection Setup Complete——这条消息里面就藏着一个NAS信封（dedicatedInfoNAS），里面装的可能就是Attach Request。eNodeB不拆这个信封，直接把它打包进S1AP的Initial UE Message转发给MME。所以你在空口LOG上看到的“Attach Request”，和核心网后台看到的“Initial UE Message”，其实是同一件事的两面。

理解这个分层逻辑之后，排查就有方向了：如果RRC连接都建立不起来，那是AS层的问题，先查覆盖、干扰、随机接入参数。如果RRC建立了但MME一直不回NAS响应，那就是S1链路或核心网的问题，你得跑到MME侧去跟踪。很多新手卡在“信号满但业务不通”这个死结，就是因为没分清到底该看哪一层。

2. Attach流程逐层拆解：从开机到默认承载建立

2.1 Attach的信令全景：一条RRC连接串起四次握手

Attach流程的最终目标是完成两件事：一是让MME确认UE的身份和签约权限，二是在UE和PGW之间建好一条默认承载，让UE有“路”可以走数据。整个流程如果从空口LOG看，消息顺序大概是这样的：

不同设备商的实现细节会有顺序差异，但整体骨架不变。你只要记住：整个Attach流程就是“先建路（RRC）、再验人（鉴权）、后发证（安全模式）、最终通水通电（建承载）”。

2.2 关键消息里的隐性信息

看LOG不能只看消息名，关键字段才是排查的重点。

第一条要盯的是RRC Connection Request里的establishmentCause。如果大量Attach请求的原因是mo-ExceptionData或者delayTolerantAccess，那说明终端行为不太正常，可能是应用层在频繁触发异常数据上报，不是网络问题。

第二条是Attach Request里的EPS attach type。它有三种取值：EPS attach、combined EPS/IMSI attach、EPS emergency attach。外场测试里如果发现终端一直发起emergency attach，说明USIM卡状态异常或者PLMN被禁止了，这是一个很容易被忽略的信号。

第三条是Initial UE Message里的TAI和ECGI。这两个字段能告诉你UE从哪个小区发起附着，是验证小区规划、跟踪区配置是否合理的第一手数据。我遇到过很多次“附着失败但后台MME看不到任何记录”的情况，最后检查发现是eNodeB配置的TAC（Tracking Area Code）和MME侧的TAL（Tracking Area List）对不上，导致MME直接丢弃了消息。

鉴权环节也要多看两眼。Authentication Request里的UMTS/EPS鉴权参数RAND和AUTN，一般LOG软件会直接显示。如果经常出现Authentication Failure，SSIM卡密钥和核心网的鉴权数据不一致，历史原因多出在测试卡写卡环节或者HSS数据同步异常。外场碰到这种问题，不要急着让核心网重新导数据，先从测试仪表或终端侧把USIM的ICCID、IMSI抄下来核对，十有八九是卡数据配错了。

2.3 附着成功后，为什么还要做TAU

很多外场工程师有个误区，以为Attach Accept收到就万事大吉。实际上在Attach流程里还隐含了一个过程——MME可能在Attach Accept里分配了GUTI，同时下发了TAI List。如果UE发现当前小区不在TAI List里，会在Attach完成后立刻发起Tracking Area Update（TAU）。

这个细节非常重要。我见过有人做外场测试，Attach明明成功了，但业务就是一直起不来。后来抓LOG发现，Attach Accept后紧跟着就是一次TAU Request，而TAU被核心网拒绝了，UE直接回到LIMITED_SERVICE状态。整个问题的根源是TAI List规划不合理，并非Attach本身失败。所以分析日志的时候，不能只看单条流程，要把Attach和后面的TAU连起来看成一个完整的故事。

3. Service Request：空闲态到连接态的业务恢复之路

3.1 Service Request和Attach的本质差异

Attach完成后，UE其实并没有一直占据空口资源。为了省电和降低信令负载，网络会把长时间不传数据的UE释放到空闲态（ECM-IDLE，RRC_IDLE）。这时候UE和网络之间没有RRC连接，也没有S1连接，但核心网还保留着UE的上下文（包括签约信息、安全上下文、默认承载信息）。

当UE侧有上行数据要发送，或者网络侧有下行数据到达并触发寻呼（Paging）时，UE就需要从空闲态回到连接态，这个过程就是Service Request。

所以两者的本质区别是：Attach是从“无注册状态”到“已注册状态”，Service Request是从“已注册但空闲”到“已注册且连接”。Service Request不需要重新做完整的鉴权和默认承载建立，它要把原来留在网络里的上下文重新激活起来，快速搭好空口数据通道。

这个区别直接决定了排查思路。Service Request失败时，不要一上来就去查签约和APN配置，而要先检查UE上下文在网络侧还在不在、状态是否一致。

3.2 Service Request时序拆解：一次从空闲到激活的完整过程

一个典型的Service Request流程，从空口LOG看大概是这样的：

1. UE发RRC Connection Request，establishmentCause一般填mo-Data或者mo-Signalling（如果是响应寻呼发起的，也可能是mt-Access）。
2. eNodeB回RRC Connection Setup，分配SRB1。
3. UE发RRC Connection Setup Complete，里面携带NAS消息Service Request。
4. eNodeB把Service Request封装在S1AP Initial UE Message里发给MME。
5. MME收到后，检查UE上下文是否有效，向eNodeB发送S1AP Initial Context Setup Request，里面携带需要建立的E-RAB列表（通常是默认承载的E-RAB）以及安全上下文参数。
6. eNodeB配置AS安全，向UE下发RRC Connection Reconfiguration，里面包含DRB配置。
7. UE回RRC Connection Reconfiguration Complete。
8. eNodeB回S1AP Initial Context Setup Response给MME。
9. 此时空口用户面通道建立，UE可以正常发送PDCP数据。

这个流程的关键在第5步。如果MME发现UE上下文不在了——比如eNodeB侧因为长时间无数据已经释放了UE上下文，或者MME侧因为定时器超时把UE上下文删掉了——那么MME就不能直接建上下文，而是会走一遍网络侧的Service Request拒绝，或者触发重新认证流程。

3.3 常被忽视的状态不一致：网络侧悄悄释放了UE上下文

我实际排查过大量Service Request失败案例，发现最普遍的一个问题就是：UE认为自己在空闲态，但网络侧的UE上下文状态却不一样。

举一个真实场景。UE在某个小区做完业务后被释放到空闲态，但释放流程只有eNodeB本地执行了，没有正确通知MME，导致MME认为UE还处于连接态。这时UE收到寻呼并触发Service Request，MME拿旧状态回应，eNodeB侧根本没有UE上下文——表现在前台LOG上就是Service Request发出去，S1AP Initial Context Setup Request很长时间不下来，最后RRC连接被释放，UE回到空闲态重试。

这种问题排查起来最坑，因为空口侧没有任何异常消息，RRC建立成功、Service Request发出成功，就是等不到回包。遇到这种“消息发出去石沉大海”的情况，不要反复重测浪费外场时间，直接拉MME侧的信令跟踪，对比MME看到的UE状态和eNodeB上报的状态，不一致的话就是异常释放流程导致的上下文残留。

解决思路也简单：让基站或核心网把异常UE上下文清掉，或者等MME的移动性定时器超时后重新寻呼。商用网络上这类问题容易出现在切换失败后的释放阶段、S1链路闪断后的恢复阶段。

4. 常见问题排查：从一条失败消息反推根因

4.1 排查方法论：四步定位法

在外场排一个信令问题，我一般按固定套路走，不靠猜：

第一步，定位置。先在LOG里找到失败消息本身，确认它是哪条消息、哪个网元发的、哪个方向（上行还是下行）。RRC层的失败还是NAS层的失败，直接决定了后续方向。

第二步，看现象。是收到了显式的拒绝消息，还是超时等不到响应？是每台终端都失败，还是特定终端失败？是固定在一个小区失败，还是每个小区都失败？这几个问题能快速区分网络问题和终端问题。

第三步，读原因值。NAS拒绝消息里一般带着EMM Cause或ESM Cause，这是核心网给终端的“官方解释”，优先看这个。常见原因值的含义我放在下面。

第四步，联动核心网。空口LOG只能看到UE侧行为，要确认是MME拒绝还是eNodeB没传上去，必须拿S1-MME接口的跟踪数据（比如华为U2020、中兴NetNumen、或者独立信令监测平台的Trace）来对比。很多外场排查都是卡在“空口侧没看到错误、不知道去哪里找原因”这一步。

4.2 Attach失败案例复盘：MME原因值背后的链路

案例一：EMM Cause #11（PLMN not allowed）

现象是UE发起Attach Request后，MME回了一条Attach Reject，Cause值是#11。这个原因值的意思是网络不接受UE所在的PLMN。

排查链路：先看UE选择的PLMN跟SIM卡签约的PLMN是不是同一张网。外场测试卡经常有签约限制，或者卡在写卡的时候只开了某个运营商的MCC/MNC。我当时查了一个“一台终端在所有站点都附着失败”的案例，最后把卡拔出来插到另一台普通手机上就能正常入网，再对比IMSI开头和PLMN配置，确认是测试卡签约数据和目标网络不匹配，联系卡商重新开卡解决。

如果多台终端都失败，那问题在网络侧。检查MME配置的PLMN列表是否包含当前TAC所属的PLMN，检查HSS里签约的 subscribed PLMN（有些场景是漫游限制）。

案例二：RRC正常但MME侧始终没有Initial UE Message

现象是LOG里RRC连接建立成功，UE也发了Attach Request，但MME后台信令跟踪里什么都查不到。

排查链路：这基本可以断定问题出在S1接口传输层。检查eNodeB和MME之间的SCTP链路状态（通常用eNodeB网管查S1链路状态），确认S1接口是否已经建立（S1 Setup流程是否完成）。如果S1接口正常，再检查eNodeB上配置的MME IP、端口和SCTP偶联配置是否有问题。

这个案例的教训是：信令流程是端到端的，空口消息发出去不等于核心网能收到。外场排查不能只看空口LOG，一定要有后台联动能力。

案例三：Attach Accept之后立刻掉网

现象是流程走完，Attach Accept收到，但UE马上释放RRC连接，接着重新选择小区，甚至报“No suitable cell”。

排查链路：先看Attach Accept里下发的TAI List，确认UE当前所在小区是否包含在TAI List里。如果核心网把TAI List配错了，UE会认为当前TA不允许驻留，触发重新选网。再看释放原因，如果是RRC Connection Release消息里携带的释放原因指示异常，那要查eNodeB侧是否在Initial Context Setup阶段配置失败。

4.3 Service Request失败案例复盘：上下文丢失与寻呼响应

案例四：下行数据触发寻呼，但UE响应寻呼呼叫失败

现象是核心网下发寻呼，UE收到Paging后发起Service Request，但网络迟迟不回Initial Context Setup Request，最终UE侧RRC被释放。

排查链路：这类问题要先区分是核心网主动拒绝还是没收到。空口LOG里Service Request发出去后，如果MME侧能看到这条NAS消息，说明空口传输正常，问题在MME对UE上下文状态的判断。MME下发Paging时，如果UE在MME侧显示为已连接（ECM-CONNECTED），那么MME会认为UE上下文应该在某个eNodeB上，从而通过该eNodeB下发寻呼，不会做空口寻呼。如果eNodeB侧其实已经释放了上下文，寻呼就送不到UE。从UE行为看起来就像“没收到Paging”。

这种情况的根因往往是eNodeB的UE上下文释放流程没有正确通知MME，或者S1释放失败，两边上下文状态不一致。排查方向是检查MME上这个UE的S1AP ID是否还挂在某个已释放的eNodeB上，然后做MME侧UE上下文清理。商用网偶尔在eNodeB重启或S1链路闪断后会批量触发这种问题，严重时会影响整片区域。

案例五：Service Request之后一直等不到RRC Connection Reconfiguration

现象是Service Request发出成功，S1AP Initial Context Setup Request也到了eNodeB，但UE就是收不到承载配置消息。

排查链路：这一步卡在eNodeB侧。常见原因有三个：一是无线资源不足，eNodeB分配 DRB 失败；二是UE和eNodeB在AS层安全模式配置上失败，导致后续重配置没法进行；三是eNodeB配置的QoS参数与自己实现的承载能力不匹配，比如CSFB和VoLTE的QCI配置错误。

遇到这个现象，建议先看eNodeB告警和无线资源状态，再拉eNodeB侧的UE信令跟踪，看看是无线侧主动放弃建立，还是配置参数错误导致内部失败。一般eNodeB侧都有比较明确的原因值。

4.4 容易忽略的非信令因素：频段、覆盖与终端能力

排查过程中我发现，很多信令层看起来正常的失败，根因不在信令协议里，而在射频和配置层面。

一个是频段（Band）匹配问题。如果终端Band不支持或没开对应Band，它根本不会发起Attach，或会在Attach后立刻脱网。外场测试要确认测试终端支持的LTE Band列表，以及当前小区的Band与终端能力是否匹配。测Band 41/40的时候特别容易踩到终端天线切换导致的掉网问题，这种情况信令LOG上往往看不出任何拒绝，就是单纯物理层失步。

另一个是终端网络能力指示。Attach Request里有UE Network Capability字段，里面包含了终端支持的安全算法、加密算法。如果测试终端和网络侧支持的算法差异过大，安全模式协商就会失败。有一种很常见的坑：外场用了某些定制终端或老旧终端，EEA0（不加密）被网络侧禁用了，但终端仍只上报EEA0，导致安全模式建立失败。这个问题在LOG上会显示为Security Mode Command反复重传或者直接释放。

还有覆盖边缘的随机接入失败。UE发RRC Connection Request之后没有收到RRC Connection Setup，多半是PRACH信道覆盖不足或者上行干扰过高。这时不要往核心网想，直接看扫频数据、上行干扰指标、以及终端上行发射功率是否到了极限。

5. 测试日志抓取与信令分析的实用工具箱

5.1 外场LOG抓取：设备选型与参数设置

外场测试终端一般选支持工程模式的商用机，市面上主流方案是高通、海思、MTK芯片的终端。高通方案配合QXDM/QCAT抓LOG最通用，能同时解NAS层和AS层，而且空口消息齐全。MTK方案也有自己的LOG工具，但解析能力相对弱一点。建议项目里至少备两台不同芯片平台的终端，防止单平台问题和厂商兼容性问题干扰判断。

LOG抓取时，重点勾选LTE相关模块：RRC、NAS、S1AP（终端侧一般没有直接S1AP，但工具箱可以关联）、PDCP、RLC、MAC、PHY层调度信息。很多测试软件默认不开NAS层，导致LOG里面看不到Attach Request内容，只看到RRC包，排查难度会大很多。

有一点要提醒：抓LOG要带上时间戳和GPS经纬度，不然回来后对现场问题小区都定不了位。外场测试经常是“当时没在意，回来看LOG发现异常”，没有位置信息基本就只能重测。

5.2 快速定位有效信令的过滤技巧

拿到一份动辄几万条消息的LOG，从头翻是不现实的。我的做法是先用关键字过滤。

在Wireshark里如果解的是PCAP格式，过滤表达式可用nas-eps，直接筛出所有NAS消息，然后找Attach Request、Authentication Request、Security Mode Command、Attach Accept、Attach Reject这类关键消息。如果用商用路测软件（鼎利、华虎、万绿等），一般有信令树形视图，按流程分组，直接点流程节点看失败位置。

实际排查我一般只看三个视图：

1. 时间线视图，按时间把整个测试过程拉出来，快速看在哪一秒发生了什么失败。
2. 信令列表视图，过滤出NAS和RRC层关键消息，看消息间的先后顺序。
3. 事件列表，看测试软件自己判断的异常事件，比如掉线、切换失败、建立失败，省去自己找的时间。

需要强调：测试软件判断的失败未必是真失败。比如它会因为终端在短时间内发起多次Attach而报“反复附着”，但有可能只是测试脚本正常重启了应用。最终要以信令流程本身的因果顺序为准。

5.3 与核心网侧联动的排查方法

单靠空口LOG只能定位到“消息发出去没回来”这个层面，想要进一步定位是哪个网元吞了消息，必须和核心网侧配合。

操作上分三步：

第一步，在MME侧开启端到端信令跟踪，筛选条件用IMSI或者终端手机号。这样能把这个UE从空口到核心网的完整信令全拉出来，不用跨系统对时间戳。

第二步，对比空口LOG和MME跟踪中同一时间点的消息。比如空口显示UE发了Attach Request，但MME侧的Initial UE Message有没有对应记录，立刻就能判断是传输问题还是MME处理问题。

第三步，如果MME侧也没有记录，就往上排查SGW、PGW、HSS之间的Diameter消息。不同厂家后台界面不一样，但思路一致：从UE往核心网逐级对比，找到最先消失的那条消息，问题就出现在它上下游之间。

还有一个技巧是善用信令监测平台（DPI探针或者核心网信令面采集）。大型项目一般都有独立信令监测系统，可以把S1-MME、S6a、S11等接口的信令全部还原。在外场不确定问题归属时，我通常会先查监测平台，用IMSI拉这个UE最近几小时的信令全貌，比自己跑后台快得多。

5.4 外场测试中的关键参数记录

一个容易被忽视的问题是：外场测试完发现异常，却缺少关键参数记录，导致事后无法复现。

我的建议是每次测完至少记录以下几个维度：

• 测试时间点（精确到秒）
• 测试终端型号、SIM卡ICCID/IMSI、终端软件版本
• 所在地点、小区CGI、Band、频点
• 测试业务类型（FTP下载、视频、VoLTE语音）
• RSRP、SINR、TA（时间提前量）等基础RF指标

这些数据配合信令LOG，能在排查时快速排除变量。比如同一小区两台终端一个Attach成功一个失败，那基本就是终端问题或者SIM卡问题，不用往基站上折腾。

我还见过一个项目，反复出现Service Request失败，但就是定位不到原因，后来发现是测试终端处于省电模式，应用层数据被推迟触发，看起来像是信令流程卡死。这种问题如果没有业务层数据配合，单看信令很容易误判。

6. 从一个功能点延伸到系统级思维：LTE信令分析的意义

6.1 从Attach到5G：为什么你会学得越来越轻松

掌握LTE的Attach和Service Request流程，对后续学习5G信令有直接帮助。5G的注册流程、Service Request流程在整体思路上跟LTE高度相似，只是把MME拆成了AMF/SMF/UPF，把 EPS Bearer 变成了 QoS Flow，消息名称换了，但“先认证后建承载”的核心逻辑没变。

在网络热词里看到很多人关注5G信令流程详解、VoNR信令流程，其实这些内容追根溯源，都是建立在LTE时代这套信令分析基本功上的。我在项目里带人做VoNR问题分析时，经常让他们先把LTE/VoLTE的端到端流程画一遍，能把LTE画明白的人，切到5G无非是换了一套参数和节点名，思路完全相通。

6.2 把信令当成系统级调试工具，而不是死记硬背的协议

还有一种心态要扭转：信令分析不是背消息，不是把几十条流程记下来就行。它是你观察无线通信系统内部状态的一台“显微镜”。

很多时候用户上报的“上网慢”“掉线”“电话不通”，映射到系统里都是某条信令流程失败或者时延过大。比如网页打不开可能是Service Request之后DRB建立时间太长，也可能是Attach后默认承载一直没有真正激活——这两种情况在用户侧表现一样，但排查方向完全不同。

我建议你在日常测试中养成的习惯是：每处理完一个问题，就在自己的问题库里记一条，格式是“现象—信令表现—根因—解决方案—验证结果”。时间长了，你会发现自己能“闻”到问题。看到某条消息迟迟不出现，或者某个原因值反复出现，脑子里立刻能调出几个候选根因，排查速度会快非常多。

这也算是我个人在LTE外场摸爬滚打多年的一点体会。信令是枯燥的，但每一屏LOG背后的故事都不同。拿到一份失败日志，别急着下结论，先把消息排好顺序，把流程位置定住，让信令自己告诉你它在哪里断了，答案往往比你想象的要近。