简介：以GSM信令流程为主线的完整讲义PPT，面向通信工程专业学生、网络运维与优化人员，也适合作为企业内训或高校教学的辅助材料，帮助读者系统建立移动核心网信令分析框架。内容从GSM网络拓扑入手，阐释MSC、BSC、BTS、HLR、VLR、AUC等网元与A接口、Abis接口、Um接口的关系；在此基础上介绍7号信令网分级结构，并按协议栈分层讲解MTP、SCCP、TUP、ISUP、MAP、TCAP、BSSAP、DTAP的定位与作用。随后聚焦典型信令流程，包括呼叫建立、呼叫清除、位置更新、切换等完整步骤，给出T3101、T3192等重要定时器的含义，以及鉴权请求/响应、身份请求/响应等关键消息的解析思路；同时还说明了常用信令分析软件和基本分析方法，便于读者在故障排查、性能优化时直接参考。资源包包含1个PPT文件，压缩后约1.65MB，目录清晰、图示完整；目前已有101人浏览学习，可作为GSM信令从入门到进阶的系统讲义。
1. 把「信令流程」做成讲义，难的不是画图，是把时序讲成因果
做过通信或核心网的人都有体会：信令流程的 PPT 不难找，难找的是「看完能自己复述一遍」的讲义。网上大量材料要么直接贴规范里的状态机，要么把抓包结果堆成一屏时序图，读者记住了一堆英文缩写，却回答不了三个最基础的问题——这条信令要解决什么问题、谁先发起、如果某一步超时会发生什么。与其说这是排版问题，不如说是「讲义思维」缺失：把协议栈当作流水账来写，却没把每个消息放到「对端为什么会回这条」的因果链里。
要把一份信令流程讲义.ppt做出真正的工程价值，关键不在于多贴几张规范截图，而在于先把承载网、核心网和终端三者的视角区分开。同样的附着流程，终端看的是「我能不能拿到网络许可」，核心网看的是「用户上下文该建在哪」，承载网看的是「这条 GTP-U 隧道两端到底通没通」。一份讲义如果只站在单一视角画消息箭头，读者换到另一个网元排查时就完全对不上号。这篇文章就按「先立框架、再拆流程、后讲参数与排错、最后补抓包视角」的顺序，把一份信令讲义该有的结构、画法和常见坑讲清楚。适合正在写内部分享材料、准备认证考试、或者刚接手核心网信令排查的工程师，无论你是写 PPT 的人还是被 PPT 培训的人，这套拆法都能直接用上。
2. 信令流程讲义的内容骨架：从分层模型到状态机
2.1 协议栈分层是讲义的第一页，不是凑页数
一份能用的信令流程讲义，第一页放什么很有讲究。常见做法是放一张协议栈分层图：终端和网络侧之间的空口信令走 RRC（无线资源控制），核心网内部走 S1AP / NGAP，用户面走 GTP-U，控制面和用户面分离这件事必须一开始就讲透。很多初学者把「信令」天然理解为控制面消息，但实际上排查数据不通的问题时，十有八九要同时盯住控制面的会话建立和用户面的转发隧道是否就绪。
我把协议栈这页的讲解顺序固定为「三层四面」：物理层和 L1 的时频资源只是背景，L2 的 MAC/RLC/PDCP 解决的是「这段空口怎么可靠地传」，真正决定业务逻辑的是 L3 的 RRC/NAS。NAS 消息透传在 RRC 容器里，记住这个封装关系，后面看抓包才不会被「为什么 S1AP 消息里能看到 attach request」问住。
2.2 状态机是信令流程的「目录」，不是附注
正经的信令讲义必须有一页状态机转移图。以 LTE 附着流程为例，终端侧是 EMM-DEREGISTERED 到 EMM-REGISTERED、ECM-IDLE 到 ECM-CONNECTED 两条线在交替推进；网络侧则是 MME 维护的 UE 上下文从空到有。讲义里把状态机放在每条流程前面，读者就有了「当前看到的消息是在推进哪个状态变迁」的锚点。
| 状态机维度 | 空闲态（IDLE） | 连接态（CONNECTED） |
|---|---|---|
| 用户面承载 | 无 S1-U 承载 | S1-U 已建立 |
| 终端位置精度 | 跟踪区级别 | 小区级别 |
| 寻呼触发 | 下行数据到达 SGW 触发 | 不需要寻呼 |
| 状态迁移触发 | RRC 连接建立 / 业务请求 | RRC 释放 / 定时器超时 |
这页表格的作用不是让读者背诵四个状态，而是建立「承载跟着连接走的观念迁移」：连接建立不只是 RRC 的事，它还连带决定了核心网侧 S1 信令连接、S1-U 用户面隧道和默认承载的完整生命周期。讲义里如果能用一页画清楚「RRC 连接 → S1 信令连接 → S1-U 隧道」三层生命周期的对应关系，后面讲任何流程都会顺手很多。
2.3 信令流程的「主语」必须标清楚：谁在跟谁说话
写信令流程最容易犯的错是画出满屏箭头却不标注主语。比如 Attach 流程里，终端发出的 attach request 是发给 eNodeB 的，但 eNodeB 只是把它封装进 Initial UE Message 转发给 MME；MME 回 attach accept 时，先回给 eNodeB，再由 eNodeB 组织成 RRC Connection Reconfiguration 下发给终端。同一件事，终端视角和 MME 视角看到的「响应方」完全不一样。
讲义里我会建议每一组消息都加一列「逻辑归属」：哪些是终端与核心网之间的 NAS 语义（附着、鉴权、位置更新），哪些是空口 RRC 层在干的活（建立、重配、释放），哪些是核心网节点之间的 S1AP/NGAP 交互（初始上下文建立、UE 上下文修改）。这三列一旦理清，读者看任何一条信令都能立刻判断「这条消息失效了，该查空口质量问题还是核心网配置问题」，排错效率直接翻倍。
3. 核心流程的讲义画法：附着、业务请求与切换的时序拆解
3.1 附着流程讲义：把「默认承载建立」画成主线索
LTE 附着流程是几乎所有信令讲义的第一个完整案例，也是我认为最适合用来训练「读图能力」的流程。讲义里我会把流程拆成四个阶段来画，而不是从头到尾一条线画到底。
第一阶段是空口连接建立：终端发起 RRC Connection Request，eNodeB 回 RRC Connection Setup，终端回 RRC Connection Setup Complete。这阶段讲义要特别标注：此时 NAS 消息 attach request 是作为 setup complete 里的一个信元带上来的，初学者最容易漏看这条「捎带」关系。第二阶段是核心网侧身份与鉴权：MME 向 HSS 取鉴权向量，向终端发起鉴权请求，终端回鉴权响应；如果终端有合法身份且之前已注册过，这一步可能在附着请求里直接携带 GUTI 而省去部分交互。第三阶段是安全模式与上下文建立：MME 触发 SMC（安全模式命令），空口开始加密和完整性保护，同时 MME 向 SGW/PGW 发起创建会话请求，核心网侧默认承载建立完毕。第四阶段是附着完成：MME 通过 Initial Context Setup Request 让 eNodeB 建立 S1 承载，eNodeB 下发 RRC Connection Reconfiguration 给终端配置默认承载，终端回 attach complete。
# 附着流程关键消息的抓包过滤示意（tcpdump / wireshark 显示过滤器） # 1) 只看 S1AP 消息 s1ap # 2) 只看某个 UE 相关的 S1AP（按 MME UE S1AP ID） s1ap.mme_ue_s1ap_id == 12345678 # 3) 只看 NAS 消息（attach / auth / security 全在里面） nas-eps这段过滤器的用途是让你在成千上万条信令里快速把「一条附着流程」圈出来。实际排障时，我习惯先按s1ap过滤，再通过 mme_ue_s1ap_id 锁定单用户，最后双击任意一条 NAS 消息看消息类型，就能定位流程停在哪一步。
附着流程讲义里最容易讲砸的是鉴权链路。不少人把 MME 和 HSS 之间的交互画得很细，但读者看完只记住了十几个信元名字。我的讲法是反过来：先讲「鉴权要解决的问题是网络证明自己、终端证明自己」，再讲「为什么要有 AUTN 和 RES 两个方向」，最后才落到具体消息名。这样读者即使忘了信元名称，也能自己推导出鉴权流程的大致帧结构。
3.2 业务请求流程讲义：空闲态到连接态的最短路径
业务请求（Service Request）流程常被当作附着流程的「简化版」一带而过，但实际工作中它出现的频率远超附着。终端在空闲态要发数据或收数据时，先发起 RRC 连接建立，然后通过服务请求消息告知 MME「我要干活了」，MME 把 S1-U 隧道和 RRC 连接重建起来，数据面随即打通。这份讲义与附着流程最大的差别在于：默认承载的上下文在核心网还在，不需要重新创建会话，只需要重建空口和 S1 的连接。讲义里画这一步时，我会明确标出「MME 不回创建会话请求，而是回 Initial Context Setup Request，指示 eNodeB 依据已存上下文重建承载」。
这个流程还有一个必须专门讲的变体：下行数据触发寻呼。如果服务请求是因为网络侧要下发数据而发起的，MME 会先通过寻呼消息找终端，终端收到寻呼后再发起服务请求。讲义里要把「网络侧等数据触发的寻呼流程」和「终端主动要发数据的服务请求流程」分成两条子流程画，避免读者误以为寻呼是服务请求的一个固定环节。
3.3 切换流程讲义：别把 X2 和 S1 切换讲成一笔糊涂账
切换是信令讲义里最容易「图太多、理太乱」的章节。我的讲义结构是：先用一句话区分触发场景——X2 切换用于基站间有 X2 接口的场景，切换信令不经过核心网；S1 切换用于跨 MME/SGW 或无法使用 X2 的场景，信令必须绕行核心网。然后分别画两个时序图。
X2 切换的核心步骤是源基站发 Handover Request 给目标基站，目标基站准备好资源后回 Handover Request Acknowledge，源基站通知终端切到目标小区。这边的关键参数是「目标基站要预留的承载资源列表」，讲义里的时序图应该标注每个承载对应的 TEID 和 QoS 参数。S1 切换则要讲清楚「路径切换过程」：核心网侧的 SGW 要更新下行隧道，把目标基站的地址和 TEID 写到承载里。这条流程的排障意义特别大——S1 切换后数据断流，八成是 SGW 侧的下行隧道没更新成功，或者目标基站没收到 End Marker。
# 切换流程讲义里的常用工具：查看 X2/S1 切换相关告警或日志 # 以某厂商 eNodeB 为例，过滤切换相关信令（实际字段以现网设备为准） show call-status | include HO show x2-link status # 空口侧确认 UE 是否完成随机接入（通过 UE 上报的 RRC 消息时间戳）这两组命令的作用是帮助读者从「只看信令图」过渡到「对着设备实测」：第一组查看基站间 X2 链路健康状态和切换次数统计，第二组确认切换后终端是否在目标小区完成随机接入。讲义写到这里，已经不只是讲规范，而是在给读者一套可以落地的故障定位路径。
4. 讲义里的关键参数与超时定时器：这些数字必须背下来
4.1 信令流程会用到哪些定时器，各自看什么指标
一份信令讲义如果只画了箭头没标定时器，读者看完能懂流程却不会排障。实际排查中，绝大多数「信令流程异常」都是定时器超时导致的：终端发出 RRC Connection Request 后迟迟等不到 Setup，MME 发出鉴权请求后收不到响应，SGW 发了创建会话请求后 PGW 不回。每个环节都有一个该等的定时器，超时时间一到，流程就按失败或被删处理。
下面这组定时器参数是信令讲义里我建议至少讲清楚的核心集合，数值以典型配置为例，实际接入网和核心网厂商会略有差异但量级相同：
| 定时器 | 作用位置 | 典型时长 | 超时后的行为 |
|---|---|---|---|
| T300 | 终端→基站，RRC 建立 | 100ms~2000ms | 终端重发 RRC 请求 |
| T310 | 终端 RLF 检测 | 1s~2s | 触发 RRC 重建 |
| T3410 | 终端→MME，附着请求 | 15s | 终端重发附着请求 |
| T3450 | 终端→MME，鉴权响应 | 10s | 终端重发鉴权响应 |
| T3250 | MME→HSS，位置更新 | 10s | MME 删除 UE 上下文或重试 |
| S1AP 等待响应 | eNodeB→MME | 5s~10s | eNodeB 触发 S1 连接释放 |
这些数字不需要死记，但讲义里要标注「建议画成表格旁注」，讲法是把每个定时器跟它对应的消息对上号。读者将来在信令追踪系统里看到「timer expired」日志时，能一眼判断是哪个环节，而不需要查规范。
4.2 附着流程与默认承载的必调参数
信令讲义讲到承载时，一定会涉及 APN、QCI、ARP 和 AMBR 四个参数。APN 决定终端接入哪个数据网络，QCI（QoS 类别标识）决定这条承载的优先级和时延要求，ARP 决定承载之间的抢占关系，AMBR 则限制聚合最大比特率。讲义里我会专门强调：默认承载通常是 QCI 8/9 的非 GBR 承载，专用承载才可能用 QCI 1/2/3/4 的 GBR 承载。这个区分直接决定了「为什么通话期间视频卡顿」——语音专用承载 QoS 高，但视频走默认承载被人为限速。
# 从 Wireshark 中导出某用户默认承载的 QoS 参数（显示过滤器示例） # 只看 Create Session Response 消息里的 EPS Bearer Context eps_bearer.qci == 9 && eps_bearer.arp == 2 # 如果关心 APN 与 PGW 地址 s1ap.message == 8 # E-RAB SETUP REQUEST这段过滤器的逻辑是：先在创建会话响应里找到默认承载的 QCI 和 ARP，确定这条承载的优先级；再看 E-RAB 建立请求里携带的 APN 和 PGW 地址。讲义里如果能把「QCI 9 + ARP 2」这种组合直接等同于「普通上网默认承载」，读者以后看任何抓包都会先本能地扫一遍这几个信元。
4.3 参数写错会带来什么现象级故障
信令讲义最有价值的部分不是「正确参数表」，而是「错误参数导致的故障现象」。我见过最多的问题是 TAC（跟踪区码）配置不一致，导致终端每跨一个小区就触发一次 TAU（跟踪区更新），信令面被位置更新刷爆，用户感知就是「刚断网又好了，好了一下又断」。另一个高频问题是 SGW 与 PGW 的 TEID 冲突或地址配置错误，导致 GTP-U 隧道建立成功但数据包被丢弃，表现为信令流程全程正常但用户 ping 不通外网。
讲义里讲错误参数时，我会用「现象 → 可能原因 → 用哪条信令验证」的三段式。比如「用户附着失败、终端一直重试」的现象，先确认是不是 HSS 里签约数据没配默认 APN，再看 MME 日志里有没有 unknown APN 的拒绝原因值。这种写法比罗列几十个原因值容易被记住得多。
5. 信令流程讲义的高阶用法：从规范图到可交互的排障手册
5.1 给每张时序图配上「失败分支」而不是只画成功路径
大部分信令讲义只画了成功流程，这是我认为最需要补的一块。真实网络中一张时序图的成功率能到 99% 已经非常理想，剩下的 1% 失败恰恰是工程师最需要的东西。讲义里我会建议每张时序图配一个「中断点清单」：如果某个消息超时未收到，流程停在哪一步、失败后续是什么、该查哪个网元的日志。
以附着流程为例，较常见的分支包括：鉴权失败（AUTN 校验不过，通常涉及 HSS/终端 SIM 卡参数），位置更新失败（HSS 里用户不存在或者被销户），承载资源不足（MME 返回资源不足的拒绝原因值），接入侧拥塞（RRC 建立失败后终端背靠背重试）。每个分支只需要一到两行说明，但能让读者在看日志时第一时间知道「这不是意外，是某个已知场景」，排障心态完全不同。
# 排查附着失败时，从 eNodeB 侧收集关键信息 # 查看 RRC 建立成功率 show rrc-status # 查看 S1 信令连接建立情况 show s1ap-status # 查看最近一次 UE 上下文失败原因 show ue-context failure last这三条命令的顺序是先看空口是否已经打通，再看 S1 信令连接是否建立，最后定位核心网侧上下文建立失败的具体原因。讲义里如果能把失败分支和命令查询路径配合起来，读者就等于拿到了一本「决策树」，而不是一张需要网元协作才能读懂的图。
5.2 把抓包与流程对应起来：每个消息在报文里长什么样
信令讲义做得好不好，最终检验标准是读者能否用它直接在抓包里找到对应消息。我建议在讲义最后附一页「消息 ↔ 抓包字段」对照表。以 S1AP 为例，Initial UE Message 对应 Wireshark 里的消息类型 13，消息体里包含 NAS-PDU 和 TAI/ECGI；Initial Context Setup Request 对应消息类型 8，消息体里的 E-RAB to Be Setup 列表是核心信息。
讲义里写对照表不是让你背字段 ID，而是建立「流程步骤 → 消息类型 → 关键信元」三层索引。读者在排障时打开 Wireshark，看到一个 NAS 消息类型为 0xe0（Attach Request），马上能从讲义里反查它应该落在附着流程的哪个阶段；如果看到的是 0x42（Authentication Response），就知道鉴权流程已经走到第二步。这套索引建立起来之后，信令讲义就从「教学材料」变成了「工具书」，这正是工程讲义和教科书的本质区别。
6. 信令流程排错的三个实用套路：TAC 不匹配、默认承载丢包与 S1 释放风暴
6.1 套路一：TAC 不匹配导致 TAU 风暴的判别与修正
TAC 不匹配的典型现象是终端在一个小区反复做 TAU，信令面负荷飙升。判别方法很简单：在 MME 上跑一条按原因值分类的 TAU 失败统计。如果 TAU 拒绝原因集中是「跟踪区无效」或「位置更新失败」，再比对小区广播的 TAC 与 MME 配置的 TAC 是否一致即可。
修正动作通常只需要在基站侧改 TAC 配置。要领是改完后要触发一次小区或 PLMN 信息更新，否则终端驻留到该小区时读取的还是旧 SIB1。讲义里我会专门提醒：TAC 配置错误导致的 TAU 风暴，排查时不要一上来就查核心网，先看这个小区周边是否最近改过 TAC 或新开过小区。
6.2 套路二：默认承载看起来建立成功但丢包的几层排查顺序
信令面完全正常、业务面不通时，按下面的顺序排查可以快速缩小范围。
# 第一层：确认 S1-U 隧道参数是否一致 # 在 eNodeB 上查看该 UE 的下行 TEID 和上行 TEID show gtpu tunnel ue-id <ue_id> # 第二层：Ping 对端核心网用户面节点 ping -c 4 <sgw-user-plane-ip> # 第三层：在核心网用户面节点抓包，确认下行数据是否到达 tcpdump -i any ip host <ue-ip> -c 100第一层查隧道参数，确认 eNodeB 和 SGW 各自记录的 TEID 是否成对；第二层查链路连通性，排除物理链路或路由问题；第三层查数据是否到达核心网用户面节点。信令流程正常但业务不通的故障，按这三层走下来基本能在半小时内定位。讲义里如果能把这三层写成固定的排查 Sequence，读者遇到同类问题就不会层层上报。
6.3 套路三：S1 释放风暴的套路化定位
S1 释放风暴通常表现为大量 UE 在短时间内被释放，且集中在某个小区或某台 MME。判别方法是看释放原因值构成，S1AP UE Context Release 的原因值如果集中在 radio network layer 里的「user inactivity」且数量异常，基本是终端侧业务行为触发；如果集中在「transport resource unavailable」，则要检查 S1 链路和传输层。
针对这类问题，我建议在讲义里附一张「释放原因值 → 处理动作」的对照表。原因值 fine（正常释放）不用管；timeout 看定时器配置是否过短；handover 成功后释放属正常；network optimization 要查负荷均衡策略是否过于激进。把释放原因值看懂，S1 释放风暴的定位难度会下降一大截，这也是信令讲义从「流程教学」延伸到「运维手则」的最后一个关键拼图。
本文还有配套的精品资源，点击获取
