简介这是一份面向LTE新手与进阶者的信令流程梳理文档适合通信工程专业学生、网络优化工程师以及刚接触LTE协议的技术人员目标是帮助读者快速建立4G信令的整体框架。包内共1个docx文档压缩包仅为1.83MB内容精炼便于随时翻阅。文档前半部分系统讲解协议层与概念覆盖控制面与用户面区别、NAS/RRC/PDCP/RLC/MAC/PHY等接口协议、空闲态与连接态转化及网络标识和承载概念后半部分详细展开开机附着、随机接入、UE发起的业务请求、寻呼、切换含站内、X2、S1及异系统和CSFB回落等主要信令流程。整份文档形成从开机到业务建立的完整信令链路章节目录清晰适合作为LTE自学笔记、面试复习或日常排障参考。已有1934人学习/下载适合需要系统梳理4G信令的同学收藏对照。1. 4G信令不只是抓包把UE从开机到关机的状态机跑一遍半夜被拉起来处理高铁投诉业务时断时续网管指标全绿领导要你一句话说清到底是谁的问题——这种场合光看指标是顶不住的得把 4G 信令从头到尾过一遍。所谓全流程就是把 UE 从开机附着Attach、空闲态登记TAU、业务激活Service Request、小区切换Handover到去附着Detach的控制面轨迹串成一条完整时间线。它解决的是「这一单投诉到底卡在终端、无线还是核心网」的问题。适合每天跟 S1AP、NAS、GTPv2-C 打交道的人无线网优、核心网维护、协议栈开发、测试和后台排障的工程师都算。抓包不等于看信令能按流程顺序把消息对上号才算真正入了门。2. 协议栈与接口信令全流程的主干和关键标识2.1 控制面协议栈NAS、S1AP、GTPv2-C 与 Diameter 的分工信令全流程不是一条协议走到底而是三段拼接。UE 和 MME 之间真正管移动性和会话的是 NAS 层它拆成 EMM移动性管理和 ESM会话管理两个子层eNodeB 在中间基本只负责搬运不解析 NAS 内容。所以你会看到 NAS 消息出现在两个地方空口上被 RRC 包着走核心网侧被 S1AP 包着走。同一个 Attach Request在 Uu 口看是 RRC Connection Setup Complete 里的一截负载到 S1-MME 口看就变成了 Initial UE Message 里的 NAS PDU。eNodeB 和 MME 之间跑 S1AP底层是 SCTP默认端口 36412。MME 和 SGW/PGW 之间控制面走 GTPv2-C底层是 UDP端口 2123MME 和 HSS 之间走 Diameter底层也是 SCTP端口 3868。这三段协议各自独立又靠同一个用户的标识串在一起。排障时最忌讳拿着一份日志从头翻到尾正确姿势是先分清当前看的是哪一段看到 SCTP 36412 就是 S1AP看到 UDP 2123 就是 GTP-C看到 SCTP 3868 就是 Diameter端口一确认排查范围立刻缩小。为什么要拆成这样移动性管理收敛到 MME承载管理下沉到 SGW/PGW好处是核心网可以分层扩容坏处是排障时必须在三段协议之间来回跳。一个 Attach 流程在 S1AP 里看初始上下文在 GTP-C 里看承载建立在 Diameter 里看鉴权取签约少看哪一段都拼不出完整因果。我一般会先把三个口的 pcap 同时打开再按用户标识对齐而不是像看小说一样顺序翻。2.2 接口与端口速查表Uu、S1-MME、S11、S5/S8、S6a 各自传什么这张表建议存下来排查时先对照接口再打开报文能省一半时间接口两侧网元控制面协议默认端口典型信令UuUE ↔ eNodeBRRC透传 NAS无固定端口RRC Setup、Measurement ReportS1-MMEeNodeB ↔ MMES1AP over SCTP36412Initial UE Message、Paging、Handover RequiredS11MME ↔ SGWGTPv2-C over UDP2123Create Session Req/Resp、Modify BearerS5/S8SGW ↔ PGWGTPv2-C / GTP-U2123 控制面Create Session Req/Resp跨网元转发S6aMME ↔ HSSDiameter over SCTP3868AIR/AIA、ULR/ULA、Insert Subscriber DataS10MME ↔ MMEGTPv2-C over UDP2123Context Request/Response跨 MME 取上下文端口识别有个实际经验抓包时很多同事只用「s1ap」或「gtpc」过滤但如果不知道底层端口容易漏掉非标准端口部署。拿到报文先看 IP 和端口确认这一段是哪个接口再做协议过滤。S10 和 S11 底层都是 GTPv2-C端口相同区分办法是看消息里携带的用户标识和上下文类型S10 里是 Context Request/ResponseS11 里是 Create/Modify/Delete Session。2.3 三组关键标识GUTI、E-RAB ID 与 TEID 怎么对齐信令里最让人头晕的不是协议栈而是标识符太多。记住一个原则GUTI 认人E-RAB ID 认连接TEID 认隧道。标识生成方作用范围出现位置容易混淆点GUTIMMEUE 与 MME 之间NAS 的 Attach/TAU/Service Request与 IMSI 的对应关系要走 S6a/S10 查EPS Bearer IDMME/UE 协商UE 到一个 PDN 连接NAS ESM 层默认承载通常为 5值域 1-15常见值E-RAB IDMME/eNodeB一个 S1 接口承载S1AP 消息与 EPS Bearer ID 要做映射不是同一个数TEIDeNodeB/SGW/PGW 各自分配一段 GTP 隧道GTP-C 消息头控制面 TEID 与用户面 TEID 是两套实际串流程时线头是 GUTI。比如 Attach 排障先在 NAS 第一条 Attach Request 里拿到 old GUTI 或 IMSI然后到 S1AP 的 Initial Context Setup Response 里找 E-RAB ID再回头在 GTP-C 的 Create Session Request 里看 SGW 分配的控制面 TEID。只要能证明这几个 ID 属于同一条流程协议栈之间的跳转就完成了。TEID 的坑在于GTP-C 每个消息都同时带发送方 TEID 和接收方 TEID抓包时看到 TEID 变了不代表隧道断了可能只是对端网元分配的接收 TEID。3. Attach 全流程拆解从第一条 RRC 到默认承载建立3.1 Attach Request 如何到达 MMEeNodeB 选 MME 与 Initial UE MessageUE 开机的第一条信令不是发给 MME 的而是先跟 eNodeB 建 RRC 连接。RRC Setup Complete 消息里带着第一条 NAS PDU——Attach Request。eNodeB 看到这条 NAS 消息后要根据其中携带的 GUMMEIGlobal Unique MME Identifier决定把消息转给哪个 MME。如果 UE 没有旧 GUTIeNodeB 就按本地配置的 MME 负载均衡策略选一个如果带了旧 GUTI就尽量选到同一个 MME减少上下文迁移。这个选择过程直接决定后面会不会出现 S10 Context Request。S1AP 的 Initial UE Message 里有两个字段很重要TAI 和 ECGI。MME 靠 TAI 判断 UE 当前在哪个跟踪区靠 ECGI 知道在哪个小区。NAS 层的 Attach Request 里要盯这些字段字段含义排障价值EPS attach type是 EPS only 还是 combined attachcombined 失败常和 CS 域相关old GUTIUE 上次注册的临时标识决定 S10 上下文是否可查UE network capability支持的加密算法算法协商失败时先看这里TAIUE 上报的当前跟踪区和网络规划比对判断是否跨区一个常见误解UE 带了 old GUTIMME 就一定不用再向 UE 要 IMSI。不是这样。如果 MME 解析旧 GUTI 发现对应不到旧 MME 的地址或者 S10 上下文请求失败还是会发 Identity Request 下来。所以看到 Identity Request 不代表 UE 有问题多数情况是 GUTI 对应的 MME 不可达或上下文丢了。3.2 鉴权与安全模式AKA 向量、SMC 与 KSI 的作用MME 收到 Attach Request 后如果本地没有这个 UE 的安全上下文就走 S6a 向 HSS 取鉴权向量。Diameter 的 AIR/AIA 消息里带的是 RAND、AUTN、XRES 和 KASME 这一组参数这些参数不是随便生成的而是根密钥 Ki 和 SQN 经过 AKA 算法算出来的。MME 把 RAND 和 AUTN 通过 Authentication Request 发给 UEUE 用 USIM 里的 Ki 验证 AUTN验证通过说明网络是真的然后回 Authentication Response 带上 RESMME 拿 RES 跟 HSS 给的 XRES 比对。两边都通过鉴权才算完。之后是 NAS Security Mode Command。MME 在这里选定 NAS 的加密算法和完整性算法常见组合是 EEA0/EEA2 和 EIA1/EIA2。UE 回 Security Mode Complete之后 NAS 消息才受安全保护。这里有一个容易被忽略的点NAS SMC 完成不代表空口 AS 层也加密了eNodeB 随后还要发起 RRC Security Mode Command空口数据面加密是这一条消息生效的。后台日志里经常看到 NAS SMC 成功但 RRC 重配失败用户侧自然表现为附着卡住第一反应别去查核心网先看空口测量报告小区是否正常。KSIKey Set Identifier是这一段的省钱机制。整个流程跑完后MME 和 UE 各自记住 KSI后面 TAU 或 Service Request 时只要双方 KSI 一致就不必再重复跑完整鉴权直接用旧密钥派生新密钥。所以 KSI 对不上时MME 才会重新触发鉴权流程。排障时看到每次 TAU 都要鉴权优先怀疑 KSI 在两侧未同步。3.3 默认承载建立Update Location、Create Session 与 Modify Bearer鉴权通过后MME 要做两件事登记位置、建立承载。位置登记走 S6a 的 Update Location Request/ResponseHSS 侧会回 Insert Subscriber Data把用户的签约数据推给新 MME包括默认 APN、QCI、AMBR、允许的漫游协议等。跨 MME 的场景里新 MME 在此之前还会通过 S10 向旧 MME 要用户上下文把鉴权结果和安全上下文一起拿过来省得再找 HSS 取向量。承载建立走 GTPv2-C。MME 根据签约数据里的 APN 构造 Create Session Request 发给 SGW里面带着 IMSI、APN、Bearer QoS、UE IP 地址请求、Serving Network 等信息。SGW 转发到 PGWPGW 分配 UE IP 地址回 Create Session Response 带上 PDN 地址和 APN-AMBR。这条消息回来之后MME 才能给 UE 发 Attach Accept激活默认承载。UE 回 Attach CompleteeNodeB 回 Initial Context Response到这为止 UE 侧已经认为自己在线了。但最后一步最容易漏MME 还要发 Modify Bearer Request 给 SGW把 eNodeB 分配给这条承载的 S1-U TEID 告诉 SGW。如果没有这步SGW 没有下行方向的用户面隧道信息下行数据包仍发到旧地址表现就是「信令正常、附着成功、下行业务不通」。这类问题单看 NAS 和 S1AP 全绿必须到 GTP-C 里确认 Modify Bearer Request 是否发出且被 SGW 接受。3.4 用 tshark 把一次 Attach 串出来过滤表达式与关键观察点抓包建议在 S11 口或 S1-MME 口各做一份两个口同时抓才能看到完整的协议跳转。tcpdump 过滤语句tcpdump -i any -s 0 -w attach.pcap sctp port 36412 or udp port 2123 or sctp port 3868用 Wireshark 或 tshark 打开后第一件事不是去看某一条消息而是把整个流程的消息列出来tshark -r attach.pcap -Y s1ap || gtpc || nas-eps || diameter \ -T fields -e frame.number -e frame.time_relative \ -e _ws.col.Protocol -e _ws.col.Info -E headery有的版本里 nas-eps 过滤器可能不识别直接把 nas-eps 拿掉靠 s1ap 和 gtpc 也能看出主干。观察点按顺序先找第一条 NAS Attach Request再找 Authentication Request/Response 和 Security Mode Complete然后找两条 GTP-CCreate Session Request/Response最后找 Modify Bearer Request。只要这五类消息都有且顺序正确附着就是通的。卡在鉴权之后没有 SMC重点查算法协商Create Session 发出后没有 Response去查 SGW 到 PGW 的转发和 PGW 日志。GTP-C 专用命令可以快速确认 S11 隧道tshark -r attach.pcap -Y gtpc -T fields \ -e frame.number -e gtpc.msg_type -e gtpc.teid -e gtpc.apn \ -E headerygtpc.msg_type 里 32 对应 Create Session Request33 对应 Create Session Response34 对应 Modify Bearer Request具体值记不住也没关系Info 列会直接显示消息名。看 TEID 是否成对出现是判断隧道是否建立的最直接办法。4. TAU、Service Request、切换与去附着后半段流程怎么串4.1 TAU 的触发条件跨 TA、周期 TAU 与 TAI list 的关系附着完成后MME 会在 Attach Accept 里给 UE 下发一个 TAI list这个列表允许 UE「在列表内自由移动而不通知网络」。UE 发现自己所在的小区 TA 不在 TAI list 里就会触发 TAU Request另一种触发是周期 TAU由 MME 在 TAU Accept 里下发的 T3412 定时器控制常见网络配置在 30 到 90 分钟之间终端在这个时间内即使没跨区也要上报一次让网络知道它还活着。TAU 流程长得像 Attach但语义完全不同。UE 发 TAU Request带 old GUTI、old TAI、update type给 MME如果跨了 MME新 MME 通过 S10 Context Request 把旧 MME 里的移动性上下文要过来要回来之后如果 KSI 对得上直接跳过鉴权发 TAU AcceptUE 回 TAU Complete。所以看 TAU 日志时发现没有鉴权消息反而是好事——说明安全上下文无缝迁移了。只有 S10 取上下文失败才需要重新鉴权这时日志里会看到 Identity Request/Authentication Request 跟上。排障中要区分两种 TAU一种是带 Active Flag 的UE 置位表示「我不仅要做位置更新还想马上建立用户面」网络侧在 TAU Accept 后要立刻发起 Initial Context Setup另一种是纯信令的 TAU不涉及用户面。很多后台同事把这两种混在一起统计误以为 TAU 完成后一定跟着空口重配其实纯 TAU 根本不会建 DRB。4.2 Service Request空闲态回到连接态的两条路与下行首包时延UE 在空闲态ECM-IDLE时S1 接口的用户面隧道是释放的只保留核心网侧 S11/S5 隧道。此时上行要发数据UE 发起 Service RequestMME 检查上下文后向 eNodeB 发 Initial Context Setup Request带上一串要建立的 E-RAB 和 QoS 参数eNodeB 建 SRB2 和 DRB用户面才恢复。这里要看的重点是 Initial Context Setup Request 里有没有列出 E-RAB ID如果列表为空说明网络只想恢复信令连接不想恢复数据承载。被叫流程多一条下行触发PGW 来包了SGW 发现没有下行 S1-U TEID就向 MME 发 Downlink Data NotificationDDNMME 在 UE 登记的 TAI list 范围内向所有 eNodeB 发 S1AP Paging。UE 收到寻呼后发起 Service Request网络再恢复用户面。这条路径比上行多了一轮寻呼接入所以「下行首包时延」天然比上行高这不是无线差是空闲态被叫的正常代价。排查被叫不通时先确认 Paging 的 TAI 列表是否覆盖 UE 当前所在位置再查寻呼周期配置。很多被叫失败其实是 UE 已经移出 Paging 覆盖范围MME 还在旧位置上反复分页。4.3 切换与去附着的信令特征切换的信令特征是「不重建承载」。同一 MME 内切换时源 eNodeB 发 Handover RequiredMME 协调目标侧资源目标 eNodeB 回 Handover Request AcknowledgeMME 发 Handover CommandUE 到目标小区随机接入并回 RRC Reconfiguration Complete目标 eNodeB 发 Handover NotifyMME 收到后发 Modify Bearer Request 把下行 S1-U TEID 从源侧切到目标侧。整个过程里 EPS Bearer ID 和 TEID 基本不变变的只是 eNodeB 侧的用户面端点。跨 MME 或跨 SGW 的切换才会看到上下文和隧道的迁移此时 S10 和 S11 会同时忙碌Modify Bearer 的频率明显变高。去附着分两类。UE 关机时主动发 Detach RequestMME 回 Detach Accept随后发起 Delete Session Request 到 SGW/PGW释放所有默认和专用承载。网络侧也会主动踢人HSS 更新签约数据比如用户被销户、签约变更、运营商主动管理、MME 侧 Mobile Reachable Timer 超时隐式去附着。现实排障里「被网络侧 Detach」容易被误判成终端问题判别方法是看 Detach Request 里有没有 UE 的原因为空或 cause 置 0网络上发起的 Detach 通常没有 Request 阶段直接是 Detach Accept 加 Delete Session。5. 信令排障避坑5 个高频误判与对应根因5.1 Attach 频繁失败但无线指标正常根因在 HSS 签约不在空口现象某一批 UE 反复 AttachMME 日志里 EMM Cause 显示 #2 IMSI unknown in HSS无线侧指标完全正常。原因SIM 卡数据没写进 HSS或者写在临时区没激活。还有一种情况是 UE 在 Attach Request 里带了 old GUTI但新 MME 解析不了发起 Identity Request 拿到 IMSI 后去 HSS 查询才发现查无此人。解决别先怀疑空口和终端直接到 HSS 侧按 IMSI 查签约确认号码、APN、QCI 是否齐全。修改完等 HSS 同步完成再测试刚改完立刻重试会看到同样的失败。5.2 看到 Paging 但手机不响应根因常在寻呼范围和 DRX 周期现象被叫失败S1AP Paging 连续发出多帧UE 始终不上来用户侧看到的是“打不通”。原因MME 在错误的 TAI list 上分页UE 实际已经不在覆盖区或 UE 侧 DRX 周期与网络下发的寻呼周期不匹配导致寻呼帧错过。解决先看 Paging 消息里携带的 TAI list 与 UE 最终注册位置是否一致再看 MME 配置的默认寻呼 DRX 周期。空口侧有 trace 的话直接确认 UE 有没有收到 Paging Indication终端已经脱网的情况只能等网络侧 Mobile Reachable Timer 超时后启动隐式去附着这是设计内的行为不是故障。5.3 割接后出现 TAU 风暴根因在 TAI list 规划不在 MME现象新增小区割接完成后TAU Request 量暴涨MME 负荷升高。原因新小区被规划进了一个独立 TA而周边邻区在另一个 TAUE 一跨边界就触发 TAU或者 TAU Accept 下发的 TAI list 太短UE 稍微移动就会出界。解决用 TAU Request 里的 old TAI 和 last visited TAI 统计跨 TA 占比找出 TA 边界上的高流量小区。一般调整目标是把跨 TA 触发 TAU 的占比控制在总业务量 5% 以下同时适当拉长 TAI list让 UE 在更大范围内不用上报。周期 TAU 的 T3412 不建议调太短省电和寻呼时延要权衡。5.4 信令全绿但下行业务不通根因在 Modify Bearer 未完成现象Attach 成功S1AP 和 NAS 都正常用户能发不能收。原因MME 发了 Modify Bearer Request但 SGW 侧没回 Response或者回包里带的 eNodeB TEID 与 eNodeB 实际分配的 S1-U TEID 不一致常见于负载均衡设备把 GTP-U 引流到另一台 SGW。解决在 SGW 侧抓 S11 口的 GTP-C 报文核对 Modify Bearer Request 里的 eNodeB TEID 与 S1AP Initial Context Setup Response 里的传输层地址是否指到同一个 eNodeB。两侧 IP 和 TEID 能对上问题就在下行数据面路由对不上优先查 GTP-U 负载策略和 NAT 配置。5.5 多接口时间对不齐根因在时钟不同源不在信令顺序现象核心网三个网元的日志时间差几秒同一流程的 S1AP 和 GTP-C 消息对不上序。原因网元没有统一 NTP日志时间戳来自各自本地时钟协议层不会帮你补偿时差。解决统一 NTP 源并做校验。对比时间线时不要用绝对时间戳做关联键改用 S1AP 里的 Procedure Code 加 UE 关联 ID 作为主键先把时间轴对齐再判断因果。另外如果你拿到的是平台聚合后的“手机信令数据 CSV”——比如区县级别的统计结果那是经过栅格化和聚合处理的产物不能当单用户原始信令用来复盘流程这一类数据适合看分布不适合看过程。6. 用抓包从 Attach 到 Detach 串出全流程一次复盘的时间线技巧日常排查里一个用户一天会产生几十甚至上百条信令要复盘完整流程第一步不是看消息内容而是先把这个人「摘」出来。如果抓包里能看到明文 IMSI比如首次 Attach 或身份请求阶段直接按 IMSI 过滤加密之后只能靠 GUTI 和时间窗口去圈定做法是先找一条明确的 Attach 或 TAU 消息拿到 GUTI再以这个 GUTI 关联后续消息。tshark -r trace.pcap -Y frame contains \460001234567890\ \ -T fields -e frame.time_relative -e _ws.col.Protocol -e _ws.col.Info \ -E headery把 IMSI 换成实际值。这一步跑完你会看到一个人的信令从头到尾的顺序而不是一锅乱炖的全网消息。第二步是算过程时延。还是用 tshark把过滤结果导成 CSVtshark -r trace.pcap -Y s1ap || gtpc || nas-eps \ -T fields -e frame.time_relative -e frame.number -e _ws.col.Protocol \ -e _ws.col.Info -E headery -E separator, ue-flow.csvCSV 拖进 Excel 后按 frame.time_relative 做差值就能算出几个关键指标Attach 总时延等于 Attach Complete 与 Attach Request 的时间差TAU 时延等于 TAU Complete 与 TAU Request 的差被叫建立时延用 Paging 到 Initial Context Setup Response 的间隔来衡量。差值计算时用时间戳而不是 frame.number因为 SCTP 重传和乱序会让帧号顺序不等于实际时序这个坑我踩过不止一次。我的习惯是先锁 IMSI/GUTI再看过程时延最后才猜根因。如果一上来就盯某一条 EMM Cause 看很容易被假象带偏——比如 HSS 签约错误导致的 Attach 失败里Cause #2 是结果不是原因。后续调 TA、调寻呼、调承载释放策略也都是先拉同一个用户的前后几十帧确认状态机走到哪一步才停的再动手改配置。把这一套时间线串法练熟4G 信令全流程才算真正长在手里希望帮到你。本文还有配套的精品资源点击获取