简介：这份资料围绕LTE信令全流程展开，面向通信工程专业学生、无线网络优化与核心网运维人员，以及准备相关认证或面试的从业者，帮助系统梳理4G网络中控制面与用户面的交互逻辑。内容从协议层与概念切入，覆盖NAS、RRC、PDCP、RLC、MAC、PHY各层职责，并延伸至空闲态与连接态、网络标识、承载概念等基础认知，再进入开机附着、随机接入、Service Request、寻呼、切换及CSFB等主要信令流程，目录结构按章节递进，便于按模块查阅与对照学习。资源包为1个docx文档，压缩后约1.83MB，以文字讲解与流程说明为主，适合作为案头速查与知识汇总材料。目前已有1934人学习下载，可帮助读者建立从协议分层到典型流程的完整框架，理解各接口信令的触发条件与先后关系，为后续网优分析、故障排查或技术面试提供可复用的知识底稿。
1. 4G信令全流程：从开机到上网，一条信令链路上到底跑了什么
很多人做4G模块调试或核心网对接时，遇到问题第一反应是“看日志”，但日志里那一长串 NAS、RRC、S1AP、GTPv2 消息，如果没有一条完整链路串起来，基本等于看天书。4G信令的全流程解释及汇总，要解决的就是这个问题：把从终端开机、附着、鉴权、建立承载，到真正跑起业务、再到释放的全过程，按接口和协议栈拆开，告诉你每条消息是谁发给谁、带什么参数、卡住时该看哪一段。它适合做物联网终端、CPE、车联网T-Box、4G仪表测试的工程师，也适合刚接触核心网信令分析的新手。下面按真实抓包顺序，把这条链路一层层剥开。
2. 先分清接口和协议栈：4G信令到底分几层跑
2.1 从UE到EPC，信令经过哪些接口
4G信令不是一条线跑到底，而是分段接力。终端侧先和基站（eNodeB）通过空口Uu接口交互，这一段跑的是RRC和NAS；基站再通过S1接口连到核心网MME，S1接口上跑S1AP承载控制面信令；MME和SGW之间用S11接口，跑GTPv2-C；SGW和PGW之间用S5/S8，同样跑GTPv2-C。用户面数据走GTP-U，和信令面分开。
常见做法是：抓包时在S1-MME口抓S1AP，在S11口抓GTPv2-C，在Uu口用终端侧QXDM或基站侧跟踪。三处时间戳对齐，才能拼出完整流程。如果只抓一处，很容易出现“消息对不上”的玄学问题。
| 接口 | 端点 | 主要协议 | 承载内容 |
|---|---|---|---|
| Uu | UE-eNodeB | RRC / NAS | 空口信令、NAS消息透传 |
| S1-MME | eNodeB-MME | S1AP / SCTP | 初始上下文、承载建立 |
| S11 | MME-SGW | GTPv2-C / UDP | 会话创建、修改、删除 |
| S5/S8 | SGW-PGW | GTPv2-C / UDP | 会话管理、IP分配 |
| S6a | MME-HSS | Diameter | 鉴权向量、签约数据 |
这张表建议打印出来贴在工位。排查时先确认问题落在哪个接口，再决定抓哪段包，比盲目全抓效率高得多。
2.2 NAS和RRC各管什么，别混在一起看
RRC管的是终端和基站之间的无线资源控制，包括系统消息广播、RRC连接建立、无线承载配置、测量上报、切换。NAS管的是终端和核心网MME之间的移动性管理和会话管理，包括附着、鉴权、安全模式、PDN连接建立、TAU、去附着。
关键区别：RRC消息在空口就终结，基站解析后不会原样透传给核心网；NAS消息对基站透明，基站只负责在RRC消息里透传。所以你在S1AP里看到的NAS-PDU，其实就是终端发出来的NAS消息被基站打包上来的。
提示：抓包时如果只看到RRC看不到NAS，检查基站是否开启了NAS透传，或者终端是否已经进入空闲态。
3. 附着流程逐条拆：从Attach Request到Attach Accept
3.1 开机后第一条NAS消息：Attach Request里有什么
终端开机搜到小区，先读SIB拿到PLMN和TAC，然后发起RRC连接建立。RRC连接建好后，终端在RRC Connection Setup Complete里携带第一条NAS消息：Attach Request。
这条消息里关键字段包括：EPS Attach Type（EPS attach还是combined attach）、EPS Mobile Identity（IMSI或GUTI）、UE Network Capability（支持的加密算法）、PDN Type（IPv4/IPv6/IPv4v6）、APN。如果终端之前有过附着，会用GUTI而不是IMSI，减少空口暴露。
# 在S1-MME口用tcpdump抓S1AP，过滤初始UE消息 tcpdump -i eth0 -s 0 -w s1ap_attach.pcap 'sctp port 36412' # 抓完后用Wireshark打开，过滤表达式： # s1ap.procedureCode == 12 (InitialUEMessage) # 再看里面的NAS-PDU，过滤：nas_eps.emm.message_type == 0x41 (Attach Request)逻辑说明：S1AP跑在SCTP上，端口36412。InitialUEMessage是基站发给MME的第一条S1AP消息，里面嵌了NAS-PDU。参数上，-s 0表示抓完整包，避免截断导致NAS解析失败。如果抓不到，先确认SCTP端口是否被防火墙拦了。
3.2 鉴权和安全模式：MME和HSS怎么配合
MME收到Attach Request后，如果本地没有终端上下文，会向HSS发Diameter AIR（Authentication-Information-Request），HSS返回AIA，里面带鉴权向量RAND、AUTN、XRES、KASME。MME选一组向量，通过Authentication Request发给终端。终端用USIM算RES，回Authentication Response。MME比对RES和XRES，一致则鉴权通过。
接着MME发起Security Mode Command，终端回Security Mode Complete。这一步之后，NAS消息开始加密和完整性保护。很多“附着失败”卡在这里，现象是终端反复发Attach Request但收不到Accept，原因可能是USIM鉴权算法不匹配，或者KASME推导出错。
# 在S6a口抓Diameter，过滤AIR/AIA tcpdump -i eth0 -s 0 -w s6a_auth.pcap 'tcp port 3868' # Wireshark过滤：diameter.cmd.code == 318 (AIR) || diameter.cmd.code == 318 (AIA) # 看AIA里的Experimental-Result，如果带5001错误码，说明鉴权向量获取失败参数说明：Diameter默认端口3868。AIR里的User-Name通常是IMSI，Visited-PLMN-Id是当前TAC对应的PLMN。如果AIA返回结果码不是2001，优先查HSS里该IMSI的签约数据是否存在。
3.3 初始上下文建立：S1AP和GTPv2的接力
鉴权通过后，MME发Initial Context Setup Request给基站，里面带UE Aggregate Maximum Bit Rate、E-RAB to Be Setup List、NAS-PDU（Attach Accept）。基站收到后配置无线承载，回Initial Context Setup Response，里面带基站侧的TEID和传输层地址。
同时MME向SGW发Create Session Request（GTPv2-C），SGW再向PGW发同样消息。PGW分配UE IP地址，返回Create Session Response。MME拿到SGW的TEID后，通过Modify Bearer Request更新基站侧信息。这一串走完，用户面通道才真正打通。
# 在S11口抓GTPv2-C tcpdump -i eth0 -s 0 -w s11_create.pcap 'udp port 2123' # Wireshark过滤：gtpv2.message_type == 32 (Create Session Request) # 看IE：IMSI、MSISDN、RAT Type、Serving Network、PDN Address Allocation逻辑说明：GTPv2-C默认UDP端口2123。Create Session Request里的F-TEID字段决定用户面隧道端点。如果PGW返回的Cause值不是16（Request accepted），常见原因是APN配置错误或IP池耗尽。
4. 业务跑起来之后：TAU、切换和去附着怎么走
4.1 TAU流程：终端移动时信令怎么更新
终端从一个TAI移动到另一个TAI，会发起Tracking Area Update。流程和附着类似，但少了鉴权（如果GUTI有效），多了TAU Request里的Old GUTI和TAI。MME如果发现MME变了，会向旧MME要上下文，再向HSS更新位置。
TAU分两种：周期性TAU（T3412超时）和移动性TAU。周期性TAU如果失败，终端会重试，重试次数超限后可能去附着。排查时看TAU Request里的EPS Update Type，如果是“periodic updating”，说明是定时器触发，不是移动触发。
# 过滤TAU消息 # Wireshark: nas_eps.emm.message_type == 0x48 (TAU Request) # 看EPS update type value: 0=TA updating, 1=combined TA/LA, 2=periodic4.2 S1切换和X2切换的信令差异
X2切换是基站之间直接协商，信令走X2口，MME只做路径更新。S1切换是基站通过MME中转，信令走S1口。X2切换快，但要求两个基站之间有X2链路。S1切换慢，但兼容性好。
切换失败常见现象是终端在目标小区重建RRC，但核心网侧没收到Path Switch Request。原因可能是目标基站没配邻区关系，或者X2口SCTP偶联断了。抓包时在源基站、目标基站、MME三处同时抓，对比Handover Request和Handover Request Acknowledge的时间差。
4.3 去附着：终端主动和网络侧发起的区别
终端主动去附着发Detach Request，MME回Detach Accept，然后MME向SGW/PGW发Delete Session Request。网络侧发起去附着时，MME直接发Detach Request给终端，终端回Detach Accept。如果是HSS发起Cancel Location，MME会触发去附着。
去附着不干净会导致“幽灵会话”，现象是PGW侧还有用户面隧道，但终端已经重新附着。解决方法是MME定期审计会话，或者PGW侧配 idle timeout。
5. 避坑与排查：4G信令分析里最容易翻车的5个点
5.1 抓包时间不同步，消息对不上
现象：S1AP里看到Attach Request，但S11里找不到对应的Create Session Request。原因：三台设备时钟没同步，时间戳差几秒。解决：所有抓包点开NTP，或者用同一台机器做端口镜像，保证时间基准一致。
5.2 NAS消息加密后看不懂
现象：Wireshark里NAS-PDU显示为Encrypted NAS Message。原因：Security Mode Complete之后NAS加密，没有密钥解不开。解决：在MME侧抓包时导出KASME，或者用终端侧QXDM抓空口，空口有明文NAS。如果都没有，只能看消息类型和长度做推断。
5.3 GTPv2 Cause值误读
现象：Create Session Response里Cause=16，以为失败。原因：GTPv2里16是“Request accepted”，不是错误码。解决：对照GTPv2规范，Cause值0-15是错误，16-31是成功和接受类。常见错误：64=Context Not Found，72=Preferred PDN Type Not Supported。
5.4 S1AP Initial Context Setup失败但无明确原因
现象：基站回Initial Context Setup Failure，Cause是“Radio Network Layer”，但没具体原因。原因：空口资源不足，或者UE Capability不匹配。解决：看基站侧小区级PRB利用率，同时对比UE Capability Information里支持的频段和基站配置。
5.5 终端反复TAU但每次都被拒
现象：TAU Request后跟TAU Reject，Cause是“EPS services not allowed”。原因：HSS里该IMSI的签约数据被删了，或者MME的TAI List和终端不匹配。解决：查HSS签约，确认MME的TAI List包含终端当前TAC。
6. 用Wireshark做一条完整信令链的过滤与验证
6.1 把S1AP、GTPv2、Diameter拼成时间线
Wireshark支持多文件合并。把S1-MME、S11、S6a三个抓包文件用Merge打开，按时间排序，然后加过滤表达式：
# 合并后过滤关键信令 (s1ap || gtpv2 || diameter) && !(gtpv2.message_type == 255) # 排除GTP-U的echo，只看控制面 # 再按IMSI过滤：diameter.User_Name contains "310150123456789"逻辑说明：合并后时间线能看到MME在收到Attach Request后多久发AIR，HSS多久回AIA，再多久发Initial Context Setup。如果AIR和AIA之间超过500ms，说明HSS响应慢，可能是签约数据查询走了慢路径。
6.2 用tshark批量提取关键字段做统计
# 提取所有Attach Request的IMSI和时间 tshark -r merged.pcap -Y "nas_eps.emm.message_type == 0x41" \ -T fields -e frame.time -e nas_eps.emm.imsi -e nas_eps.emm.attach_type # 输出示例： # 2025-01-15 10:23:45.123 310150123456789 1 # 2025-01-15 10:24:12.456 310150987654321 1参数说明：-Y是显示过滤器，-T fields指定输出字段。attach_type=1表示EPS attach，2表示combined attach。如果大量终端attach_type=2但网络不支持CS Fallback，会看到Attach Reject。
6.3 验证方法：用已知正常终端做基线对比
我一般会先抓一个已知正常的终端做基线，记录从Attach Request到Attach Accept的时间、经过的接口、每条消息的Cause值。然后抓故障终端，逐条对比。差异点就是问题点。这个方法比盲查规范快得多，也是我踩过多次坑后养成的习惯。
注意：基线抓包要在同一基站、同一MME、同一时间段做，否则负载不同会导致时间差异，误判为故障。
希望帮到你。
本文还有配套的精品资源，点击获取
