简介一份围绕4G LTE信令全流程编写的技术文档适合移动通信工程师、网络优化人员以及刚接触LTE协议栈的学习者。内容先梳理协议层与核心概念包括控制面与用户面区分、NAS/RRC/PDCP/RLC/MAC/PHY各层职责、空闲态与连接态、网络标识和承载概念随后按场景讲解主要信令流程如开机附着、随机接入、UE发起Service Request、网络寻呼、切换以及CSFB流程并附有流程步骤与协议层交互说明。资源为单个docx文档包体大小1.83MB便于离线阅读和按章节检索已有1935人学习。文档以“协议层—概念—流程”为线索能够帮助读者快速建立4G信令全景框架加深对UE与网络之间交互过程的理解也可作为日常排障和面试复习的参考材料。1. 4G信令全流程这套汇总资料能帮你少走哪些弯路拿到一份4G/LTE信令log你是先看附着流程还是先看切换我自己踩过的坑是一开始总喜欢从中间某个“看起来奇怪”的消息开始查绕了半天最后发现根因在前面三步就埋下了。这份《4G信令的全流程解释及汇总》就是干这个用的——把UE从开机附着、业务请求、切换、TAU到去附着的一整条信令链按消息顺序逐条解释、按场景分类汇总成册。它适合做无线网优、基站侧、核心网侧的朋友也适合刚从数通转过来、对S1AP和NAS还犯迷糊的新人。资料里既有消息字段说明也有流程时序归纳属于那种拿到手就能对着log开始对表的工具型内容。2. 先看懂信令骨架LTE协议栈、接口与信令类型的对应关系2.1 从UE到核心网的三条关键路径LTE信令看着繁琐其实消息只跑在三条固定路径上其余的都是在这三条路径上的排列组合。第一条是Uu口也就是UE和基站之间的无线空口承载RRC消息和NAS消息的透传第二条是S1-MME口基站和MME之间的逻辑接口跑S1AP消息底层走SCTP第三条是X2口基站和基站之间的直连接口主要跑切换准备和上下文释放。搞清楚一条消息是从哪个口进来、再往哪个口出去读起来就不容易迷路。这份汇总资料里对每条流程都标注了信令面走向比如“Attach流程涉及Uu和S1-MME两个接口其中NAS消息在Uu口是封装在RRC里、在S1MME口是封装在S1AP里”能把接口逻辑讲清楚的资料不多。接口连接两端承载协议典型信令角色UuUE 与 eNBRRC / NAS透传建立与重配无线承载、透传NASS1-MMEeNB 与 MMES1APSCTP初始UE消息、上下文管理、承载管理X2eNB 与 eNBX2APSCTP切换准备、序列号状态传输、UE上下文释放2.2 三层信令的职责边界LTE信令按协议栈分三层RRC、S1AP、NAS。很多新手看log时搞混的原因就是把三层消息当成同一类。RRC层跑在UE和eNB之间管的是无线资源——RRC连接建立、重配、释放都在这一层。S1AP跑在eNB和MME之间管的是UE在基站和核心网之间的上下文——初始上下文建立、UE上下文修改、释放都在这层。NAS则横跨UE和MMEeNB对它只做透传不解析内容。这三层的包含关系是NAS在Uu口被RRC包着走在S1-MME口被S1AP包着走。所以你在wireshark里看到一条S1AP消息里面有NAS字段是很正常的不是重复是封装。资料里有一张三层包含关系的对照表把每条具体消息属于哪一层标得很清楚对照看会少很多困惑。2.3 抓包与日志字段从文件里快速定位消息实际工作中拿到的信令文件格式五花八门有从eNB导出的原始日志有从核心网抓的PCAP也有路测软件导出的文本表格。无论哪种格式快速定位消息的关键是抓四个字段时间戳、消息类型、方向、UE标识GUTI或S-TMSI。用wireshark打开PCAP时Uu口的RRC消息可以直接按rrc过滤S1-MME口的S1AP消息按s1ap过滤但要看到里面的NAS内容需要展开S1AP层里的NAS-PDU字段。我自己的习惯是把过滤语法存成常用过滤按钮比如s1ap.nas_pdu可以直接把带NAS的S1AP消息筛出来配合frame.time_delta看相对时延。资料里对常用过滤器列了一张速查表对刚上手wireshark的人比较友好。另外提醒一句抓S1-MME口数据时如果用的是镜像口一定要确认SCTP的偶联没被过滤掉否则很多S1AP消息会看不到。3. 附着流程逐条拆解从开机到默认承载的十四个关键动作3.1 附着流程的标准时序与消息清单附着流程是UE第一次进入网络时最完整的信令过程这份汇总把附着拆成了十四个动作可以比对着log一步步看。序号方向消息作用1UE → eNBRRC Connection Request发起RRC连接2eNB → UERRC Connection Setup分配SRB1和C-RNTI3UE → eNBRRC Connection Setup Complete携带NAS Attach Request4eNB → MMES1AP Initial UE Message把NAS传送给MME5MME → UENAS Authentication Request发起鉴权6UE → MMENAS Authentication Response返回鉴权结果7MME → UENAS Security Mode Command激活加密与完整性保护8UE → MMENAS Security Mode Complete确认安全激活9MME → eNBS1AP Initial Context Setup Request建S1承载并下发NAS Accept10eNB → UERRC Connection Reconfiguration建立DRB和SRB211UE → eNBRRC Connection Reconfiguration Complete确认DRB建立12eNB → MMES1AP Initial Context Setup Response通知eNB侧上下文完成13UE → eNBUL Information Transfer携带NAS Attach Complete14eNB → MMES1AP Uplink NAS Transport把Attach Complete转给MME第1步到第3步是RRC建立阶段第4步是关键转折点——eNB把UE的NAS信息打包成Initial UE Message交给MME从这一步开始才真正进入核心网流程。第5步到第8步是鉴权和安全激活很多附着失败卡在这一段后面避坑章节会展开说。第9步到第12步是上下文建立核心网把默认承载信息连同附着接受一起发下来基站侧完成无线侧承载映射。第13步和第14步的Attach Complete只是确认消息但如果看不到说明之前的承载可能已经异常。3.2 关键字段与参数GUTI、TAI、EPS Bearer ID附着流程里必须读懂的四个参数是GUTI、TAI、EPS Bearer ID和APN。GUTI是核心网给UE的临时标识长度是MMEI加M-TMSI的组合在wireshark的NAS层里能看到完整的GUTI结构。它的作用是让UE在后续流程中不需要每次都上传IMSI保护身份同时减轻核心网查询压力。TAI则是MCC、MNC、TAC三段的组合表示UE当前所在的跟踪区域TAU流程是否触发就看TAI是否变了。EPS Bearer ID是0到15的数值默认承载通常从5开始分配Dedicated Bearer会递增。ARP分配保留优先级和QCI决定了这个承载在空口和核心网里的调度优先级QCI1通常用于语音QCI9用于默认承载的互联网业务。资料里对每个字段给出了取值范围和典型取值比如GUTI里M-TMSI一般是32位随机数看到全0或重复值基本可以判定MME分配异常。3.3 附着失败先看哪条消息附着失败排查有个先后顺序先看RRC是否建立成功再看S1AP Initial UE Message是否发到MME最后才看NAS层的拒绝原因。很多工程师一上来就翻NAS的Reject原因但真实情况往往是RRC根本没建立成功。如果RRC Setup Request之后没有RRC Setup问题大概率在空口查上行干扰或覆盖。如果RRC建立成功但S1AP Initial UE Message发出后没收到MME的任何响应问题在S1链路或MME侧需要检查SCTP偶联和MME配置的PLMN是否匹配。如果NAS层返回了Rejectwireshark里可以直接读EMM Cause值比如#2表示IMSI未知#7表示EPS服务不允许。资料里附了一张EMM Cause的常见值对照表比翻规范快得多。4. 业务请求与切换流程空闲态恢复和移动性管理4.1 业务请求流程从空闲态到连接态的五个关键动作UE完成附着后进入空闲态是省电设计但一旦有上行数据需求就必须通过Service Request流程恢复连接。这个流程比附着短得多但同样容易出问题。Service Request的触发是UE在RRC层发RRC Connection Request里面携带Establishment Cause设为mo-Data或mo-Signaling。RRC建立完成后UE在RRC Connection Setup Complete里携带NAS Service Request消息eNB把它封装成S1AP Initial UE Message转发给MME。MME收到后检查UE上下文是否存在如果合法就下发S1AP Initial Context Setup Request把之前挂起的承载恢复到eNB。整个流程的核心判断点在于MME是否能在本地找到该UE的上下文。资料里对Service Request流程的三种结果做了分支式说明成功、MME拒绝、eNB侧建立失败这三种情况分别看哪条消息、核心网和无线侧该怎么配合排查。实际操作中最常看到的情况是Initial Context Setup Request下发后eNB回Initial Context Setup Failure原因是无线资源不足或QCI参数不支持这类问题要从基站侧配置查。4.2 X2切换与S1切换两种路径的信令差异切换是移动性管理的核心场景LTE里分X2切换和S1切换两条路径。X2切换的前提是源基站和目标基站之间存在X2接口且都能解析对端地址源eNB直接通过X2AP Handover Request把切换请求发给目标eNB。目标eNB准备好资源后回Handover Request Ack源eNB通过RRC重配把切换命令下发给UE。UE切到目标小区后发送RRC重配完成目标eNB随后向MME发Path Switch Request通知核心网更新下行数据路径。S1切换则用于不存在X2接口或X2切换失败的情况。源eNB先向MME发S1AP Handover RequiredMME选择目标eNB后发Handover Request目标eNB准备好资源后回Handover Request AckMME再把Handover Command转发给源eNB。从消息数量上看S1切换比X2切换多绕一跳核心网时延通常会高几十毫秒。资料里把两种切换的触发条件、消息走向、核心网参与程度做了对比表判断切换卡在哪一步之前先确认走的是哪种切换路径。4.3 A3事件、TTT和迟滞参数切换触发不是随便定的A3事件是最常用的同频切换触发条件。A3表示邻区质量高于服务小区质量一定偏移量公式是邻区RSRP减去服务小区RSRP大于offset。但为了防止乒乓切换协议里加了两个关键参数TTTTime-to-Trigger和迟滞Hysteresis。参数典型值作用A3 Offset2~4 dB邻区质量超过当前小区的门限Hysteresis0~3 dB抑制测量波动带来的误触发TTT160~480 ms条件持续满足一段时间才上报CIO0~6 dB单小区的个性化偏置设置参数时要看场景。城市密集区域干扰大TTT设太短容易频繁切换我一般会把TTT调到320ms以上并加大迟滞。高铁场景相反TTT太长会导致切换不及时通常UE在重叠覆盖区停留时间短TTT缩短到160ms更合适。资料里对不同场景的参数推荐值有单独一小节可以直接套用。5. 信令排查避坑五个常见误判与对应解法5.1 附着刚成功又立刻发起新附着现象UE完成Attach流程后几秒内又发一条新的Attach Request并且里面携带的是旧GUTI。原因MME在Attach Accept里下发了新GUTI但UE没有保存成功或者MME分配的GUTI在本地数据库里已被占用导致MME拒绝该GUTI触发重新附着。解决先看Attach Accept里的GUTI IE是否携带完整值再看UE侧日志里的存储动作是否执行成功。如果GUTI值重复出现检查MME的GUTI分配策略确认M-TMSI随机范围是否过小产生碰撞。资料里对这种情况专门标注了“重复附着”的排查路径按此顺序能快速定位。5.2 切换后业务中断且目标小区无上下文现象切换信令全部显示成功RRC重配也完成了但下行数据断流在目标eNB查UE上下文为空。原因X2切换后Path Switch Request没有触发核心网修改承载或者目标eNB的S1接口数据面地址没有更新到SGW。还有一种情况是SN Status Transfer消息丢失导致数据面序列号乱序。解决先在目标eNB抓X2口的Path Switch Request和Response确认MME是否回了Path Switch Response。如果回了但数据仍断去核心网侧查Modify Bearer Request是否执行成功重点看SGW分配的TEID是否变化。资料里对切换后数据断流给了三层定位法先X2再S1最后查空口值得记下来。5.3 TAU请求频繁触发导致信令负荷飙升现象统计时段内TAU请求次数异常高位置更新成功率下降MME信令面负荷过高。原因TAI list配置不合理例如TAC边界规划重叠、相邻小区的TAC频繁变化或者UE在多个TA边界来回移动。解决把TAI list的合并策略打开让MME一次给UE分配多个TA减少UE跨TA时的TAU次数。同时检查TAC规划图避免同一区域出现交替重叠的TAC边界。资料里给出的经验值是同一UE的TAU周期不应小于平均业务间隔低于这个值就说明TAI list或TAC规划需要调整。5.4 Wireshark里过滤不到NAS消息现象用nas关键字在wireshark里过滤一条消息都没有但明明能正常看到S1AP消息。原因NAS消息在S1-MME口是嵌套在S1AP层里的直接用nas过滤不生效。在Uu口则是嵌套在RRC层里过滤语法也不一样。解决S1-MME口用s1ap.nas_pdu过滤Uu口用rrc.ul_dcch或rrc.dl_dcch过滤。如果要看所有NAS消息可以组合过滤s1ap.nas_pdu || rrc.ul_dcch || rrc.dl_dcch。资料里对wireshark过滤语法专门列了个表照着抄就行。5.5 RRC建立成功但业务仍然无法进行现象RRC Connection Setup Complete发出来了但之后既没有RRC重配也没有任何NAS响应消息。原因eNB的S1链路配置异常Initial UE Message没有成功发给MME或者MME已经拒绝对话但eNB没有把NAS拒绝消息透传给UE。解决先查eNB和MME之间的SCTP偶联状态确认偶联建立成功。再查eNB配置里MME的IP和PLMN是否匹配如果偶联断了所有新接入的UE都会卡在这一步。这类问题基站侧日志通常会有SCTP断链记录按这个方向查能省不少时间。6. 用一套完整日志做反向复盘验证信令理解的实操技巧读信令读多了会发现一个规律正向读流程只能验证“成功长什么样”反向复盘才能暴露“失败从哪里开始”。我现在的做法是拿到一份log先翻到流程末尾找到最终结果消息比如Attach Accept或Handover Complete然后一条一条往回追把每条消息的时间戳、方向、关键ID记下来最后形成一张时间线表。这么做的好处是能清楚看到哪一步耗时异常、哪条消息缺失、哪个环节在反复重试。有了时间线表就可以写简单的脚本做统计分析。下面这个Python脚本可以读CSV格式的信令日志按UE标识分组统计每个流程的耗时import pandas as pd # 读取信令日志CSV至少包含timestamp、msg_name、direction、ue_id四列 df pd.read_csv(signaling_log.csv) # 将时间戳转换为datetime类型方便做差值计算 df[timestamp] pd.to_datetime(df[timestamp]) # 按ue_id分组对每一组计算流程起止时间差 for ue_id, group in df.groupby(ue_id): group group.sort_values(timestamp) start group.iloc[0][timestamp] end group.iloc[-1][timestamp] duration (end - start).total_seconds() print(fUE {ue_id}: 全程耗时 {duration:.2f}s f共 {len(group)} 条消息)这段代码的逻辑很简单先按ue_id把同一个UE的所有信令拉出来按时间戳排序后取首尾消息的时间差作为整个流程的耗时。实际使用时可以把首条和末条消息名打印出来确认取的是对的流程。如果发现某个UE耗时明显偏长就回到时间线表里看中间哪两条消息之间间隔最大那个位置就是排查重点。参数方面要注意如果日志里同一时刻对应多条消息排序时加一个序号列保证顺序稳定。CSV的列名不一定叫timestamp和ue_id导日志时先确认表头再跑脚本不然pandas会报KeyError。对不熟悉脚本的朋友直接在Excel里筛选ue_id后看时间差也一样脚本只是省去手工操作。从那以后我每次拿到新log都会强制自己先拉时间线表再决定从哪条消息开始深挖。这样看似多花几分钟实际省掉了很多“从中间开始查结果绕回起点”的冤枉路。希望帮到你。本文还有配套的精品资源点击获取