很多刚转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跟踪区码配置错误会导致终端反复尝试或者位置更新冲突。我记得有一次外场问题终端始终无法完成AttachLog里PRACH物理随机接入信道前导一直发不出去最后查出来是站点侧Preamble格式配置和实际环境不匹配导致的随机接入成功率极低。所以排查Attach问题务必先确认随机接入是否成功再看RRC是否建立最后才轮得到NAS层的Attach流程。随机接入成功之后终端会发送RRC Connection RequestEstablishment 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 RequestSGW再转发给PGWPGW给终端分配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 SetupService 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态终端如果有上行数据要发是先发SRScheduling Request或者BSRBuffer Status Report请求基站给自己分配上行授权压根不用重新建立RRC连接。只有当RRC状态真的从IDLE转CONNECTED时才需要Service Request帮忙。所以判断是否需要关注Service Request流程先看终端当前的RRC状态。RRC_IDLE状态下发起业务才会触发RRC_CONNECTED状态下只是普通的数据调度不需要走完整信令流程。4. 常见问题与排查技巧实录4.1 问题排查速查表以下这张表是我在实际外场测试和后台信令分析中总结出来的高频问题场景先给各位一个全局速查后面再挑几个典型场景展开聊。问题现象涉及阶段优先排查点常见根因RRC建立失败率高随机接入/RRC建立PRACH配置、干扰、PCI混淆邻区关系错误、同频干扰严重RRC正常但ATTACH不成功NAS Attach核心网侧鉴权/位置更新消息HSS签约异常、IMSI异常Attach成功但无速率Initial Context SetupQCI参数、DRB是否建立专用承载缺失或QoS协商异常从IDLE回业务慢Service Request寻呼时延、核心网上下文保活时长核心网保活定时器过短、S1链路闪断被叫无法接通寻呼/Service RequestPaging消息是否下发、UE是否响应UE在弱信号区、MME寻呼策略不当4.2 经典场景一Attach成功率低与TAU冲突的死循环先说一个我实际遇到过的场景很有代表性。外场测试时发现某个区域终端Attach成功率很低终端表现是上报Attach Request之后收不到Attach Accept或者可以收到但随后立刻断链又重新Attach。后台查S1AP信令发现MME发的Attach Accept已经到达基站了但基站侧把这条消息发给终端之后终端的响应却是重新发起Attach。反复对比终端Log之后定位到根因核心网配置的TAC列表和终端之前缓存的不一致终端在Attach过程中发现当前小区所属的TATracking 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来一起聊聊。