LTE信令流程详解：从Attach到Service Request的完整链路与排查实战

很多刚转LTE外场测试或者核心网协议开发的兄弟，可能都有过这种经历：盯着Log里面的信令窗口，消息一条条往上滚，每条消息的字段也都认识，但连起来就不知道整个流程在干什么。尤其是Attach和Service Request这两个流程，一个是终端入网的“第一脚”，一个是待机状态下重新干活的“启动键”，很多问题都藏在这两条流程的细节里。

这篇文章我想从实际从业者的角度，把从Attach到Service Request的完整链路拆开揉碎。不光是讲“谁先发谁后回”这种顺序问题，更重要的是讲清楚每一步背后在干什么、核心网侧和无线侧各自的状态发生了什么变化，以及在真实现网里最常见的那几个坑长什么样、怎么排查。这篇内容适合做LTE网优、外场测试、协议开发的同学，也适合刚入门想建立信令流程整体框架的朋友。

1. 内容整体设计与思路拆解

1.1 信令流程本质上是在“讨价还价”

先说一个我自己的理解。很多人把LTE信令流程背得滚瓜烂熟，什么Attach Request带PDN Connectivity Request、Create Session到SGW再到PGW，但遇到问题照样抓瞎。根本原因在于：把信令流程当成了“步骤列表”来记，而没有把它当成一个“状态机协商过程”来理解。

LTE的信令流程本质上就是终端、基站、核心网之间围绕三件事在反复“讨价还价”：你是谁、你能干什么、你现在要干什么。Attach流程做的是前两件事，Service Request流程做的是第三件事。

用生活里的例子类比一下。你第一次去一个园区上班，门口的保安（基站）不认识你，你得出示身份证件（Attach Request里的IMSI/随机数），园区管理处（MME）核实你的身份后，去你原单位（HSS）调档案（位置更新和签约数据获取），确认你确实有权限，然后给你办一张门禁卡（GUTI）顺便把你的工位（默认承载）安排好。之后你中午出去吃饭，再回来的时候要通过门禁（Service Request），这时候门禁系统已经认识你了，只需要刷脸确认你确实还是这个园区的人，就放你进去，工位还是你原来的那个，不用重新办手续。

这个类比基本概括了Attach和Service Request的全部精髓：Attach是“完整注册+资源预分配”，Service Request是“快速回归+资源恢复”。

1.2 从协议栈到接口的全景视角

做信令分析不能只看某一条消息，要有全局视角。LTE的信令分为两条大路：一条是空口（Uu接口）上的RRC/NAS信令，一条是核心网侧S1接口上的S1AP信令，以及MME和SGW/PGW之间的GTP-C信令。

很多外场测试的同学主要关注空口侧的RRC消息，因为Log里直接能看到。但一旦出现RRC层看起来正常、业务却建立不起来的情况，就得往S1AP或者核心网内部去找了。反过来说，做核心网侧开发的同事，也经常需要根据空口消息反推问题是否出在终端侧。

所以这篇文章的设计思路是：把一条完整的流程按照“空口RRC消息- S1AP消息- NAS消息”三层交织的方式来梳理，尽量还原一条真实信令的完整生命周期。你手里拿到一个Log，无论看的是终端侧还是基站侧，都能对应上。

2. 核心细节解析：Attach流程的完整链路

2.1 开机找网：Attach之前的前世今生

严格来说，Attach流程并不是终端开机后做的第一件事。终端上电之后，第一件大事是小区搜索和驻留。这个阶段做的事情包括：扫频找LTE小区、读MIB/SIB系统消息、发起随机接入、完成RRC连接建立，然后才在RRC连接之上发送Attach Request。

外场测试很多人不太关注这个“前戏”，但很多Attach失败的问题恰恰出在这里。比如SIB1里如果配置了IMS紧急承载相关的指示，或者小区的TAC（跟踪区码）配置错误，会导致终端反复尝试或者位置更新冲突。我记得有一次外场问题，终端始终无法完成Attach，Log里PRACH（物理随机接入信道）前导一直发不出去，最后查出来是站点侧Preamble格式配置和实际环境不匹配导致的随机接入成功率极低。所以排查Attach问题，务必先确认随机接入是否成功，再看RRC是否建立，最后才轮得到NAS层的Attach流程。

随机接入成功之后，终端会发送RRC Connection Request，Establishment Cause通常是mo-Signalling（因为Attach属于移动发起的信令流程），这条消息结束之后基站回RRC Connection Setup，终端再回RRC Connection Setup Complete。注意了，这个Setup Complete消息里面，才是真正的NAS消息——Attach Request加PDN Connectivity Request。NAS消息是封装在RRC消息里面透传的，基站看不懂里面的内容，它只负责把这条消息原封不动地通过S1接口送给MME。

2.2 S1AP Initial UE Message：基站向核心网“交人”

eNodeB收到RRC Connection Setup Complete后，会解析出里面的NAS消息，然后把整个NAS消息封装到S1AP的Initial UE Message消息里发给MME。这条消息在S1AP里非常关键，因为对MME来说，这是它第一次“认识”这个终端。

Initial UE Message里携带了两个重要东西：

• eNodeB分配的S1AP UE ID（用于后续S1接口上的UE级信令标识）；
• 完整的NAS消息（Attach Request），以及ECGI（小区全局标识）和TAI（跟踪区标识）。

MME收到Initial UE Message后，会先做一步很关键的动作：根据Attach Request里带的GUTI或者IMSI判断这个终端是否曾经注册过。如果终端有旧的GUTI，但MME查不到对应的上下文，就会走到Identity Request/Response流程向终端要IMSI，或者直接走鉴权流程让终端“自证身份”。

空口正常建立之后，UE会先去做真正的鉴权和加密。核心网会给UE发Authentication Request，里面带有鉴权参数RAND和AUTN。UE用自己的密钥Ki和算法算出RES返回核心网。这个步骤完成后，进入Security Mode Command流程，激活NAS层的加密和完整性保护。到这一步，核心网和UE之间就有了信任关系。

2.3 鉴权与位置更新：核心网侧的两个关卡

鉴权通过之后，MME接着做两件事。第一件事是向HSS发起位置更新请求（Diameter协议，走S6a接口），注册UE当前所在的MME信息。在这个请求里面，HSS会把用户的签约数据下发给MME，包括默认APN、QoS参数、允许的PDN类型等等。

这个步骤有个常见的坑：如果HSS里签约数据异常，或者MME和HSS之间的路由配置有问题，Update Location Request就可能会超时失败，终端会卡在鉴权通过之后的某一步，表现为空口信令已经走到NAS Security Mode Command了，但后续的Attach Accept迟迟不来。

第二件事是MME向SGW发起Create Session Request，SGW再转发给PGW，PGW给终端分配IP地址，并通过Create Session Response把IP地址一路带回来。在这个流程中，PGW和PCRF之间还可能交互PCC策略（如果部署了策略控制的话），决定这个用户能使用什么QoS等级和带宽上限。

从终端视角来看，鉴权和位置更新这两个核心网侧步骤对它完全是透明的。终端只知道自己在收发NAS消息，并不知道MME在后台查了什么、建了什么。这也是为什么排查问题的时候一定要看两部分：空口侧信令和核心网侧信令，缺一不可。

2.4 Initial Context Setup：无线侧真正开始分配资源

核心网侧的位置更新和默认承载创建都搞定之后，MME会向eNodeB下发S1AP Initial Context Setup Request。这条消息是“无线侧和核心网侧握手成功”的标志：MME告诉基站，这个终端的上下文我已经建立好了，你可以为它分配无线资源了。

注意整个Attach里的上下文含义，核心网侧已经建立了默认承载（EPS Bearer）。但当S1AP消息到达基站，接入层无线资源还没建立，需要基站为默认承载创建无线侧的DRB（数据无线承载）。在Initial Context Setup Request里，携带了需要建立的EPS Bearer的QoS参数，包括QCI、ARP、AMBR等。基站的调度器就会按这些参数决定给用户分配多少资源、优先级多高。

Initial Context Setup Request里面还带了一个细节——UE Capability Enquiry指示。NM话语就是：让基站问一下终端支持哪些频段、支持哪些协议版本、最大速率是多少。基站在收到终端的UE Capability Information后，再通过UE CAPABILITY INFO INDICATION消息告诉MME。很多空口速率不及预期的问题，查到最后往往就出在这个环节——终端上报的能力集里最大速率比预期低。

Initial Context Setup Request下发之后，基站会向UE发起两条重要的空口消息。一条是AS层的Security Mode Command，建立接入层的加密和完整性保护；另一条是RRC Connection Reconfiguration，里面配置了DRB参数，同时把核心网的Attach Accept和Activate Default EPS Bearer Context Request两条NAS消息一起带下来。UE完成重配后回RRC Connection Reconfiguration Complete。到这个地方，空口和核心网之间的连接才算真正打通了。

最后一步是UE回复NAS层的ATTACH COMPLETE。这条消息非常短，但它是整个Attach流程的收官信号，表示终端确认默认承载已激活、IP地址已生效。ATTACH COMPLETE之后，终端就正式进入了LTE网络，可以开始进行数据业务了。注意，ATTACH COMPLETE这条NAS消息也是封装在RRC消息（ULInformationTransfer）里面发的，千万不要在空口Log里直接找一条叫ATTACH COMPLETE的RRC消息，它只是ULInformationTransfer里携带的一个NAS-PDU字段。

3. 实操过程与核心环节实现：Service Request的快速回归

3.1 为什么待机态回业务要重新“敲门”

接下来聊一聊Service Request。前面提到了，终端在Attach完成后会进入连接态，但如果一段时间没有数据业务，网络侧会通过RRC Connection Release让终端进入IDLE态。IDLE态下，空口无线资源全部释放，但核心网侧用户上下文仍然在MME里存活，默认承载也仍然存在。

这时如果终端要发一个微信消息或者打开一个网页（上行触发），或者被叫来一个电话/一条推送（下行触发），终端需要从IDLE态回到连接态，这个“敲门”动作就是Service Request。

为什么不能在IDLE态直接发数据？因为终端在IDLE态没有任何专用无线资源，连C-RNTI都没有，物理层根本找不到一个可以调度它的身份标识。必须先通过随机接入拿到RRC连接，重新建立DRB，才能传输数据。这个过程就是从IDLE态到CONNECTED态的状态迁移，Service Request就是完成这个迁移的钥匙。

3.2 Service Request的空口与S1信令配合

Service Request的近端过程是随机接入，这和Attach时的随机接入完全一样。区别在于，Attach时终端没有网络身份，而Service Request时终端已经有核心网分配的GUTI和上下文，只是无线侧暂时丢了。

终端通过随机接入建立RRC连接后，在RRC Connection Setup Complete消息里携带Service Request NAS消息，请求核心网恢复用户面承载。这里有一个值得注意的细节：此时RRC Establishment Cause一般会是mo-Data（如果是上行业务触发）或mt-Access（如果是下行寻呼触发），而不再是Attach时候的mo-Signalling。在外场测试看Log的时候，通过RRC Connection Request里的Establishment Cause就能快速判断终端发起这个流程的原始动机。

eNodeB收到RRC Connection Setup Complete后，同样通过S1AP Initial UE Message把Service Request透传给MME。注意这里依然是Initial UE Message，因为对MME来说，这是一个新的S1连接——之前的S1连接已经随着RRC释放被释放掉了。MME根据NAS消息里的GUTI找到之前保存的UE上下文，确认这个终端确实处于已注册状态，然后直接向eNodeB下发Initial Context Setup Request，消息里面带上了这个用户的所有EPS Bearer QoS参数，包括之前Attach时候建立的那个默认承载。

eNodeB收到Initial Context Setup Request之后，通过RRC Connection Reconfiguration给终端重配DRB，把默认承载的空口承载重新建立起来。UE回RRC Connection Reconfiguration Complete之后，整个Service Request流程在空口侧就完成了。此时用户面通道恢复，数据可以跑了。

3.3 “小数据快速通道”机制：RRC Suspend/Resume

不过，标准的Service Request流程其实有点“重”——每次都要走随机接入、RRC连接建立、S1AP Initial UE Message、MME查上下文、Initial Context Setup，这一整套下来通常需要几十毫秒到上百毫秒。对于微信心跳这种极其频繁的小包场景来说，这个时延和信令开销成本太高了。

于是LTE引入了一个优化机制：RRC Connection Suspend/Resume（挂起/恢复）。简单说，就是当终端长时间没有业务时，基站不发RRC Connection Release让终端彻底进入IDLE态，而是发一个RRC Connection Suspend，告诉终端“你的上下文我先帮你存着，暂时挂起”；终端进入一种“轻连接”状态。之后终端要想发数据，只需要在随机接入后发一个RRC Connection Resume Request，基站本地就能恢复上下文，不需要再经过MME做Initial Context Setup，时延大幅降低。

这个机制在实际网络中很常见。外场Log里如果看到RRC Connection Resume而不是完整的RRC Setup＋Service Request，说明终端和网络都支持这个优化，属于正常的快速回归流程，不是问题。但需要注意的是，如果核心网侧配置了较短的MME保活定时器，或者基站侧不缓存UE上下文，即使终端发了Resume Request，基站也可能拒绝并让它走完整的Service Request流程。这种场景下从Log表面看是Resume失败，实际上不是故障，而是流程回退。

3.4 连接态的小动作：称不上Service Request的“轻量传输”

另外要区分一个概念：Service Request只在IDLE态到CONNECTED态切换时发生。如果终端已经处于CONNECTED态，只是短时间没有上下行数据（比如网页读取间隔），此时缓冲区为空，终端想再发数据时直接通过上行调度请求就行了，不需要走Service Request。

很多初学信令的朋友会在CONNECTED态的空口Log里看到终端发RRC Connection Request，以为又触发了Service Request，其实不是。CONNECTED态终端如果有上行数据要发，是先发SR（Scheduling Request）或者BSR（Buffer Status Report）请求基站给自己分配上行授权，压根不用重新建立RRC连接。只有当RRC状态真的从IDLE转CONNECTED时，才需要Service Request帮忙。

所以判断是否需要关注Service Request流程，先看终端当前的RRC状态。RRC_IDLE状态下发起业务才会触发；RRC_CONNECTED状态下只是普通的数据调度，不需要走完整信令流程。

4. 常见问题与排查技巧实录

4.1 问题排查速查表

以下这张表是我在实际外场测试和后台信令分析中总结出来的高频问题场景，先给各位一个全局速查，后面再挑几个典型场景展开聊。

4.2 经典场景一：Attach成功率低与TAU冲突的死循环

先说一个我实际遇到过的场景，很有代表性。

外场测试时发现某个区域终端Attach成功率很低，终端表现是：上报Attach Request之后，收不到Attach Accept，或者可以收到但随后立刻断链又重新Attach。后台查S1AP信令，发现MME发的Attach Accept已经到达基站了，但基站侧把这条消息发给终端之后，终端的响应却是重新发起Attach。

反复对比终端Log之后定位到根因：核心网配置的TAC列表和终端之前缓存的不一致，终端在Attach过程中发现当前小区所属的TA（Tracking Area）不在自己保存的TAI列表里，于是在Attach流程还沒有完成的时候又插入了一个Tracking Area Update流程。两个流程在NAS层打架，最终导致Attach一直无法完成。

这种问题的排查思路：先看S1AP消息里MME下发的Attach Accept中带的TAI List，再对比终端的Log里是否有并发TAU请求。如果发现终端在Attach流程未完成前发起TAU，重点检查核心网规划的TAC与邻区配置是否一致，尤其是边界区域跨MME的场景。

4.3 经典场景二：Service Request频繁失败与RRC重建

另一个高频问题是Service Request时延高甚至失败。现象是：终端在IDLE态发起业务，RRC连接建立完成后，MME也下发了Initial Context Setup Request，但DRB迟迟建不起来，最终业务失败或者重试。

排查这类问题时，先看空口侧RRC Connection Reconfiguration是否正常发出、终端是否回复了Complete。如果基站发了重配但终端没回，终端侧Log会显示重配失败，重点检查DRB配置里有没有终端不支持的能力项，比如终端只支持Cat.4，而网络侧配置了256QAM上行（虽然标准里上行256QAM是Cat.11才引入的），有些老终端就会导致重配失败。

还有一个很常见的坑是RRC重建。如果UE在Service Request过程中发生无线链路失败，终端会自动发起RRC重建流程，重建成功后可能重新触发Service Request，导致信令翻倍。这种场景下从统计看Service Request失败次数会增加，但从无线侧排查就回到了链路质量本身：是否有弱覆盖、干扰、切换失败等等。

4.4 排查效率和终端侧观察技巧

最后分享几个实际工作中压箱底的小技巧。

第一，看信令一定要养成“先看总览再看细节”的习惯。很多平台（比如鼎利、Pioneer或者后台U2000）都有信令流程总览图，先看流程是否走完，再看中间卡在哪一步，最后才点进去逐字段分析。直接一头扎进字段里，很容易被细节带偏。

第二，注意区分IDLE态和CONNECTED态下的同一条消息含义。比如ULInformationTransfer这条RRC消息，在CONNECTED态只是透传NAS，但在IDLE态触发流程时它承载的往往是Service Request或TAU Request。同样是ULInformationTransfer，承载的内容完全不同，分析思路也完全不同。

第三，排查S1AP问题记得同时看MME和eNodeB两侧日志。MME侧看SCTP链路状态和Diameter消息时延，基站侧看S1AP消息收发时戳。如果两侧时戳差距大，优先怀疑中间传输链路存在丢包或拥塞；如果时戳对得上但流程就是错误，再看消息里的Cause值和携带参数。

我还想说一点，做信令分析，工具是次要的，关键是状态机思维。每一个流程的本质都是在多个网元之间迁移状态。遇到问题先问一句：UE当前应该在什么状态？核心网认为它是什么状态？基站认为它是什么状态？这三者只要有不一致，就是问题所在。这个思路无论排查Attach、Service Request还是其他任何信令流程都适用。最后再分享一个实际操作的体会：处理信令问题不要迷恋那种“一条命令定位根因”的捷径说法，大多数时候问题都是多个因素叠加的结果。我习惯的做法是先把一条失败流程的完整信令链拉出来，按时间线标注每个网元的动作，再逐段问“这一步的判断对吗”，往往比直接套用经验更有效。你手头如果也遇到过什么奇怪的Attach或者Service Request问题，欢迎拿Log来一起聊聊。