简介以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 转发给 MMEMME 回 attach accept 时先回给 eNodeB再由 eNodeB 组织成 RRC Connection Reconfiguration 下发给终端。同一件事终端视角和 MME 视角看到的「响应方」完全不一样。讲义里我会建议每一组消息都加一列「逻辑归属」哪些是终端与核心网之间的 NAS 语义附着、鉴权、位置更新哪些是空口 RRC 层在干的活建立、重配、释放哪些是核心网节点之间的 S1AP/NGAP 交互初始上下文建立、UE 上下文修改。这三列一旦理清读者看任何一条信令都能立刻判断「这条消息失效了该查空口质量问题还是核心网配置问题」排错效率直接翻倍。3. 核心流程的讲义画法附着、业务请求与切换的时序拆解3.1 附着流程讲义把「默认承载建立」画成主线索LTE 附着流程是几乎所有信令讲义的第一个完整案例也是我认为最适合用来训练「读图能力」的流程。讲义里我会把流程拆成四个阶段来画而不是从头到尾一条线画到底。第一阶段是空口连接建立终端发起 RRC Connection RequesteNodeB 回 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 后迟迟等不到 SetupMME 发出鉴权请求后收不到响应SGW 发了创建会话请求后 PGW 不回。每个环节都有一个该等的定时器超时时间一到流程就按失败或被删处理。下面这组定时器参数是信令讲义里我建议至少讲清楚的核心集合数值以典型配置为例实际接入网和核心网厂商会略有差异但量级相同定时器作用位置典型时长超时后的行为T300终端→基站RRC 建立100ms~2000ms终端重发 RRC 请求T310终端 RLF 检测1s~2s触发 RRC 重建T3410终端→MME附着请求15s终端重发附着请求T3450终端→MME鉴权响应10s终端重发鉴权响应T3250MME→HSS位置更新10sMME 删除 UE 上下文或重试S1AP 等待响应eNodeB→MME5s~10seNodeB 触发 S1 连接释放这些数字不需要死记但讲义里要标注「建议画成表格旁注」讲法是把每个定时器跟它对应的消息对上号。读者将来在信令追踪系统里看到「timer expired」日志时能一眼判断是哪个环节而不需要查规范。4.2 附着流程与默认承载的必调参数信令讲义讲到承载时一定会涉及 APN、QCI、ARP 和 AMBR 四个参数。APN 决定终端接入哪个数据网络QCIQoS 类别标识决定这条承载的优先级和时延要求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/ECGIInitial Context Setup Request 对应消息类型 8消息体里的 E-RAB to Be Setup 列表是核心信息。讲义里写对照表不是让你背字段 ID而是建立「流程步骤 → 消息类型 → 关键信元」三层索引。读者在排障时打开 Wireshark看到一个 NAS 消息类型为 0xe0Attach Request马上能从讲义里反查它应该落在附着流程的哪个阶段如果看到的是 0x42Authentication 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 释放风暴的定位难度会下降一大截这也是信令讲义从「流程教学」延伸到「运维手则」的最后一个关键拼图。本文还有配套的精品资源点击获取 
长河君 · 2026/9/19 3:40:11 · 阅读 1.2k 一文讲透信令流程讲义：附着、切换与定时器排障要点
简介以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 转发给 MMEMME 回 attach accept 时先回给 eNodeB再由 eNodeB 组织成 RRC Connection Reconfiguration 下发给终端。同一件事终端视角和 MME 视角看到的「响应方」完全不一样。讲义里我会建议每一组消息都加一列「逻辑归属」哪些是终端与核心网之间的 NAS 语义附着、鉴权、位置更新哪些是空口 RRC 层在干的活建立、重配、释放哪些是核心网节点之间的 S1AP/NGAP 交互初始上下文建立、UE 上下文修改。这三列一旦理清读者看任何一条信令都能立刻判断「这条消息失效了该查空口质量问题还是核心网配置问题」排错效率直接翻倍。3. 核心流程的讲义画法附着、业务请求与切换的时序拆解3.1 附着流程讲义把「默认承载建立」画成主线索LTE 附着流程是几乎所有信令讲义的第一个完整案例也是我认为最适合用来训练「读图能力」的流程。讲义里我会把流程拆成四个阶段来画而不是从头到尾一条线画到底。第一阶段是空口连接建立终端发起 RRC Connection RequesteNodeB 回 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 后迟迟等不到 SetupMME 发出鉴权请求后收不到响应SGW 发了创建会话请求后 PGW 不回。每个环节都有一个该等的定时器超时时间一到流程就按失败或被删处理。下面这组定时器参数是信令讲义里我建议至少讲清楚的核心集合数值以典型配置为例实际接入网和核心网厂商会略有差异但量级相同定时器作用位置典型时长超时后的行为T300终端→基站RRC 建立100ms~2000ms终端重发 RRC 请求T310终端 RLF 检测1s~2s触发 RRC 重建T3410终端→MME附着请求15s终端重发附着请求T3450终端→MME鉴权响应10s终端重发鉴权响应T3250MME→HSS位置更新10sMME 删除 UE 上下文或重试S1AP 等待响应eNodeB→MME5s~10seNodeB 触发 S1 连接释放这些数字不需要死记但讲义里要标注「建议画成表格旁注」讲法是把每个定时器跟它对应的消息对上号。读者将来在信令追踪系统里看到「timer expired」日志时能一眼判断是哪个环节而不需要查规范。4.2 附着流程与默认承载的必调参数信令讲义讲到承载时一定会涉及 APN、QCI、ARP 和 AMBR 四个参数。APN 决定终端接入哪个数据网络QCIQoS 类别标识决定这条承载的优先级和时延要求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/ECGIInitial Context Setup Request 对应消息类型 8消息体里的 E-RAB to Be Setup 列表是核心信息。讲义里写对照表不是让你背字段 ID而是建立「流程步骤 → 消息类型 → 关键信元」三层索引。读者在排障时打开 Wireshark看到一个 NAS 消息类型为 0xe0Attach Request马上能从讲义里反查它应该落在附着流程的哪个阶段如果看到的是 0x42Authentication 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 释放风暴的定位难度会下降一大截这也是信令讲义从「流程教学」延伸到「运维手则」的最后一个关键拼图。本文还有配套的精品资源点击获取