SS7七号信令协议分析实战：从分层原理到抓包排障

简介：聚焦七号信令（SS7）协议的入门与进阶学习资料，面向通信工程学生、电信运维人员及协议研究者，以图文方式解析SS7协议栈的层次结构、信令点/转接点组网方式及MTP、SCCP、TCAP等核心模块的工作原理。压缩包共607个文件，包含465张示意图（多为协议流程与网络拓扑图）、138个htm及3个html格式的网页讲解文档，另有1个txt文件可能收录扩展阅读链接，整体仅3.43MB，便于快速下载与离线查阅。内容覆盖信令数据单元格式、智能网事务处理、SS7与IMS融合以及安全防护等要点，并配有实例分析，有助于读者从理论到实操掌握七号信令的呼叫控制与路由机制。目前已吸引373人学习，适合需要系统梳理SS7知识或备战通信类考试的读者。

1. 做网络协议分析的人，早晚会被七号信令卡住

做网络协议分析的人，早晚会撞上一个叫 SS7 的协议栈。七号信令不直接传语音，也不传数据，它管的是电话能不能通、短信能不能到、漫游位置怎么更新——通信网里所有“看不见的控制动作”都靠它在发号施令。哪怕现在大家都在讲 5G、VoNR，只要你的网络还要和存量交换网互联，就会在关口局、汇接局里看到它的身影。像 SS7.rar 这类协议分析包里，最常见的就是抓包样本、规范摘录和解析脚本，但对着它学，重点不是背消息码，而是把 MTP、SCCP、TCAP、ISUP 这条链路一层层剥出来。这篇按我实际做信令追踪的路径写：先立分层，再给抓包命令，最后把那些让人白加班的坑提前指出来。

2. 七号信令的分层设计：先看懂 MTP、SCCP 和 TCAP 谁在替谁打工

2.1 MTP1/MTP2/MTP3：链路、帧和点码三层对号入座

SS7 协议栈最底层是消息传递部分（Message Transfer Part），简称 MTP，分三层。MTP1 是物理层，管的是 E1/T1 这样的 TDM 链路，或者 IP 化之后的 SCTP 承载，这一层通常不用应用工程师去抠，因为无论是从信令链路采集还是从网管侧看，物理层的问题都会直接表现为“链路断、误码高”。MTP2 负责信号单元的定界、差错检测和重发，相当于把物理层收到的比特流切成一个又一个“信令单元”，你要是在抓包里看到一堆 FISU（填充信令单元），那就是链路在跑“心跳”，说明 MTP2 是正常的，问题可能出在上面。

真正值得花时间的是 MTP3。MTP3 做的是路由和信令网管理，它靠一个叫“信令点码”的地址来转发消息。每一条 MTP3 消息里都带着目的信令点码（DPC）和源信令点码（OPC），再加上 SLC（信令链路选择码），这一组字段就是 MTP3 层的路由标记。做信令追踪时，我一般先看 MTP3 的 DPC/OPC 对得上对不上，再往下看具体业务，这个顺序能省很多事——因为 MTP3 是承上启下的分水岭，点码错了，后面全是白看。

2.2 一个 MSU 到底长什么样：路由标记、SIO、CIC 逐字节拆

MTP3 层承载的用户消息叫 MSU（消息信令单元），它的载荷结构值得逐字节拆一遍。剥掉 MTP2 的帧头之后，第一个关键字节是 SIO（业务信息八位位组），它低四位是业务指示语（SI），高四位是网络指示语（SSF）；SI 等于 3 说明载荷是 SCCP 消息，SI 等于 5 说明载荷是 ISUP 消息。接下来是四字节的路由标记，依次是 DPC（14 比特）、OPC（14 比特）、SLC（4 比特）。从 SIO 后面的第一个字节开始，才是真正的上层数据。

如果 SI 指向 ISUP，那紧跟在路由标记后面的就是 CIC（电路识别码），占两个字节，再往后一个字节是消息类型码。IAM（初始地址消息）的消息类型是 1，ANM（应答消息）是 9，REL（释放消息）是 12，RLC（释放完成）是 16。看到这里你就能理解为什么 Wireshark 能自动把抓包拆成 mtp3、isup 两层：它只是在按这个固定偏移切字节。自己在写协议解析脚本时，最稳的做法不是硬编码偏移，而是先读 SIO，再按 SI 决定下一个解析器是 ISUP 还是 SCCP。

MSU 载荷结构（从 SIO 开始）： SIO : 1 字节，SI=3 表示 SCCP，SI=5 表示 ISUP 路由标记 : 4 字节，DPC(14bit) + OPC(14bit) + SLC(4bit) ISUP : CIC(2字节) + 消息类型(1字节) + 参数体 SCCP : 消息类型(1字节) + 地址/参数体

这段结构说明的是抓包数据在 IP 网里的真实排列顺序。写解析脚本时，如果你从帧的某个固定位置硬算 SIF 偏移，一旦前面插入 M3UA 头或者链路状态单元，偏移就全错了；正确做法是让解析器按“SIO 决定下一步”的方式走，这样即使中间增加适配层，也只是多剥一层头。

2.3 SCCP 和 TCAP：把“找谁”和“办什么事”分开，才能扛住大话务

SCCP（信令连接控制部分）是在 MTP3 之上提供更灵活的寻址能力。MTP3 只认点码，但业务侧关心的是用户的电话号码、IMSI、或者某个网元里的具体业务模块。所以 SCCP 引入了全局码（GT）和子系统号（SSN）：GT 可以是 E.164 号码格式，SCCP 负责把 GT 翻译成“点码 + SSN”，这样上层业务就不需要关心你落在哪个物理网元上，号码搬家、网络割接对业务无感。

TCAP（事务能力应用部分）则负责更上层的事务管理，位置更新、短消息、智能网业务都在 TCAP 里以“对话 + 操作”的方式交互。一个 TCAP 事务由事务 ID 标识，Begin 消息带上发起方事务 ID，Continue 和 End 消息通过事务 ID 把同一个业务的多条消息串起来。做信令分析时，SCCP 层让你找到“这条消息发给谁”，TCAP 层让你看到“这个业务办到哪一步了”，两个视角配合才能还原一次完整的业务交互。

2.4 一张对应表：业务、协议层和寻址字段各就各位

这张表基本覆盖了日常能见到的七号信令业务。ISUP 只管电话呼叫的接续和释放，用 CIC 来标记某一条电路；而位置更新、短信这类业务走的是 SCCP + TCAP，因为它们的诉求是“找到某个用户当前所在的网元”，而不是绑定某条物理电路。理解这个区别后，你在 Wireshark 里看到 ISUP 和 TCAP 同时出现在一个呼叫里就不会慌——它们一个是呼叫控制面，一个是业务控制面，各干各的活。

3. 抓七号信令别去碰 E1：用 SIGTRAN 把信令流量拉回 IP 网再分析

3.1 为什么现在的 SS7 抓包几乎都是 SIGTRAN

早期做七号信令分析要用高阻探针搭在 E1 线路上，链路误码、时钟同步、插拔位置都会影响采集质量，而且一套采集设备只能覆盖有限的链路，扩容成本很高。核心网 IP 化之后，SIGTRAN 协议族把 SS7 的载荷搬到了 SCTP 上传输，M3UA 承载 MTP3 消息、SUA 承载 SCCP 消息，抓包这件事一下子就变成了以太网抓包——只要交换机能镜像端口，或者直接在服务器上 tcpdump，就能拿到完整的信令面数据。

这对做网络协议分析的人来说是巨大的便利。SCTP 本身是可靠传输协议，所以不用再关心 MTP2 的重发逻辑；M3UA/SUA 的头部结构清晰，Wireshark 原生支持解析。换句话说，你不需要凑齐一屋子 TDM 设备，一台服务器加一块网卡就能开始做七号信令的追踪和排障。现在很多厂商的采集方案，本质也是把 SIGTRAN 流量汇聚后转发给解码平台，原理和 tcpdump 抓包没有区别。

3.2 tcpdump 抓 SCTP 的最小命令：一条命令连抓带存

sudo tcpdump -i eth0 -s 0 -w ss7_sigtran.pcap 'sctp and (port 2905 or port 2904)'

这条命令抓取 eth0 网卡上的 SCTP 报文，并写入 ss7_sigtran.pcap 文件。BPF 过滤表达式里的sctp关键字让 tcpdump 只保留 SCTP 报文，端口条件 2905 是 M3UA 的默认端口，2904 是 SUA 的默认端口；如果你所在网络的端口做了修改，把端口号替换成实际配置即可。-s 0表示不截断报文，抓全包，这一点在信令分析里很重要——SCCP 层经常有大载荷，截断会导致 Wireshark 无法重组上层消息。-w指定输出文件名，抓完按 Ctrl+C 停止。

实际抓包前，我一般会先不加-w，跑一条sudo tcpdump -i eth0 'sctp' -c 20确认网卡上确实有 SCTP 流量，避免对着一个镜像口抓半天全是空包。如果端口也不是默认端口，可以先抓全量 SCTP 看一眼端口号，再回去用精确过滤重新抓。

3.3 用 tshark 验货：确认抓到的是不是 M3UA/SUA

抓回来的文件，先用 tshark 快速看一眼结构：

tshark -r ss7_sigtran.pcap -c 20

-r读取文件，-c 20只显示前 20 个包。这一步能确认抓包文件里确实有 SCTP 层，并且能看到 Protocol 列是否出现了 M3UA 或 SUA。接下来要用显示过滤器精确筛：

tshark -r ss7_sigtran.pcap -Y "m3ua || sua" -T fields -e frame.number -e sctp.srcport -e sctp.dstport -e m3ua.opc -e m3ua.dpc

这条命令把 M3UA 和 SUA 消息都过滤出来，输出帧号、SCTP 源端口、目的端口以及 M3UA 层的点码信息。要注意的是，不同版本的 Wireshark 对 M3UA 字段的命名略有差异，如果某个字段名解析不出来，可以先跑tshark -G fields | grep -i m3ua查看当前版本支持的字段名，再替换到命令里。这也是我比较推荐的做法——不要死记字段名，要会用 tshark 的元数据查询命令。

3.4 没有现网流量时，这两条路都能练

没有现网流量不等于不能练。一条路是去 Wireshark 官网的 Sample Captures 页面，搜索 SS7 或 SIGTRAN 相关的抓包文件，下载后用 Wireshark 或 tshark 打开分析，这是学习协议解码最直接的素材。另一条路是自己构造报文，但对新手来说，自己拼一个 MSU 的十六进制字节很容易在比特序和 CRC 上翻车，翻车的细节我在后面的避坑章节里会专门讲——如果只是想熟悉解析流程，先从现成抓包开始更省时间。

4. 追踪一通呼叫：从 IAM 到 RLC，把 ISUP 和 TCAP 串成时间线

4.1 找对三把钥匙：CIC、OPC/DPC 和事务 ID

一通电话在 ISUP 层会有 IAM、ACM、ANM、REL、RLC 这一串消息，这些消息靠什么串在一起？靠三把钥匙。第一把是 DPC/OPC 点码对，它告诉你消息在哪两个信令点之间流动；第二把是 CIC，它唯一标识了这条呼叫占用的是哪一条电路；第三把是事务 ID，只在 TCAP 层出现，用于关联同一业务流程的对话。实际追踪时，先用点码对找到目标局向，再在目标局向内按 CIC 过滤，就能把一通呼叫的消息序列完整拉出来。

这里有个容易被忽略的点：CIC 不是全局唯一，它只在同一对点码之间有意义。不同局向之间的 CIC 可能相同，但代表的是完全不同的电路。所以在过滤 ISUP 消息做呼叫关联时，一定要带上 OPC/DPC 条件，否则会把不同局向的呼叫混在一起。

4.2 用显示过滤器快速定位指定局向和电路

tshark -r ss7_calls.pcap -Y "mtp3.dpc == 100 && mtp3.opc == 200 && isup.cic == 1024" -T fields -e frame.number -e frame.time -e mtp3.opc -e mtp3.dpc -e isup.message_type -e isup.cic

这条命令筛选出从信令点 200 发往信令点 100、CIC 为 1024 的所有 ISUP 消息，并输出帧号、时间、点码和消息类型。mtp3.dpc、mtp3.opc是 MTP3 层的点码字段，isup.cic是电路识别码字段，isup.message_type是消息类型。输出后你就能看到这个消息序列里先出现 IAM，然后 ACM、ANM，最后 REL 和 RLC。如果中间缺了某个消息，那通常就是定位问题的突破口——比如只有 IAM 没有 ACM，说明被叫侧一直没应答，大概率是中继或终端侧卡住。

要以 CSV 格式导出，可以加-E header=y -E separator=,，这样就能直接导入表格工具做进一步分析。

4.3 把消息按时间排成流程，判断呼叫卡在哪一跳

上面命令输出的结果已经把消息按帧号排好了，帧号顺序近似时间顺序。更精确的做法是加-e frame.time_relative输出相对时间，然后用脚本或表格工具计算相邻消息的间隔。正常情况下，IAM 到 ACM 应该在几百毫秒内完成，如果间隔到了秒级，说明交换机或核心网元在处理上出了问题。

我个人的习惯是先肉眼扫一遍完整列表，确认消息类型序列符合预期的状态机——例如电话呼叫应该是 IAM→ACM→ANM→REL→RLC，然后才去看时间间隔。如果序列本身就不完整，比如没有 ACM 直接出现 REL，那问题多半不是性能，而是被叫侧直接拒绝了呼叫，这时要看 REL 消息里的原因值。Wireshark 的 ISUP 解析器会自动把原因值翻译成“正常呼叫清除”“用户忙”之类的话术，非常方便。

4.4 ISUP 和 TCAP 同时出现时，怎么分开看

移动网络里一个呼叫常常同时涉及 ISUP 和 TCAP：ISUP 负责主叫到被叫的电路接续，TCAP 里的 MAP 消息负责查询被叫当前所在的位置区。这两类消息走不同的协议层，但通过一个共同的“主叫号码”能关联起来。分析时不要试图在一个显示过滤器里同时解出所有信息，而是分别过滤isup和tcap，先各自还原流程，再交叉对比时间点。很多让人困惑的现象，比如“ISUP 显示呼叫已接通，但用户没收到振铃”，其实答案藏在 TCAP 的位置更新或寻呼响应里。

5. SS7 协议分析的避坑记录：5 个让我白加过班的问题

5.1 用 isup 过滤器筛出的消息解不开，先把 SIO 对齐

现象：明明抓到了 M3UA 流量，用-Y "isup"过滤也能出包，但点开看没有 ISUP 层，只有一串 M3UA Data 原始字节。

原因：M3UA 的 Data 参数里装的并不都是 ISUP 消息。SIO 的 SI 值决定了载荷类型，如果 SI=3，那载荷是 SCCP，用 isup 过滤器自然解不出；另外 M3UA 的 Protocol Data 参数如果带的是 MTP3 网络管理消息，也属于正常现象。问题不在抓包，在解码预期。

解决：先看这条消息的 MTP3 层协议列显示的是什么，再决定下一步。排查顺序应该是：MTP3 点码对不对 → SIO 的 SI 指向哪一层 → 用对应层解。每次抓到“解不开”的包，先问自己“我是不是拿错了解析器”。

5.2 点码显示成一大串数字，怎么都对不上

现象：抓包里 MTP3 层的 DPC/OPC 显示成几百到几千之间的一个大数，和自己记的网元编号完全对不上。

原因：MTP3 点码是 14 比特，但不同的信令网有不同切分格式，常见的有 3-8-3、4-4-6 等。同一个点码值，用 3-8-3 格式显示和用 4-4-6 格式显示，呈现出来的数字完全不同。Wireshark 默认按某一种格式解码，没对准你所在网络的格式，就会出现“认识的网元不认识了”的怪事。

解决：Wireshark 里 Edit → Preferences → Protocols → MTP3，把 point code format 改成你网络实际使用的格式，改完再回去看 DPC/OPC 就顺眼了。这个坑很小，但第一次遇到时足够让人怀疑自己抓错网元。不同运营商、不同厂商的规范可能不一致，做跨网分析前务必确认双方的点码格式约定。

5.3 自己拼十六进制 MSU，十次有八次在比特序上翻车

现象：用 text2pcap 把自己拼的十六进制字节转成 pcap，Wireshark 打开后要么不认 MTP2 帧，要么 MTP3/SCCP 层完全解乱。

原因：SS7 链路帧的比特序和以太网不同，很多字节是反比特序传输的，而且链路层抓包在什么时候开始算帧、要不要带上 FISU 和 CRC，取决于采集点的位置。自己拼接时，任何一位对错都会让后面全乱，而且报错还不直观。

解决：学习阶段不要自己拼链路帧，直接抓 SIGTRAN 报文分析；如果需要构造数据做测试，优先在 M3UA 层构造 Data 消息，因为 SCTP/M3UA 是字节流的，没有链路层的比特序问题。如果你确实需要从零构造信令消息，最稳的方式是用抓到的真实消息改字段，而不是凭空写一段字节流。

5.4 SIO 的 SSF 没设对，SCCP 地址翻译跟着乱

现象：SCCP 层能解出来，但地址里的全局码显示异常，或者本该是“国内网络”的消息被按“国际网络”解析，导致 GT 翻译结果不对。

原因：SIO 高四位是 SSF，用于区分国际网络和国内网络；不同组的解析偏好设置不一致，就会让同一个 SCCP 消息在你的 Wireshark 里和同事的 Wireshark 里呈现出不同结果。

解决：分析前先确认抓包来源的网络类型，在协议偏好里把对应的网络指示语设对。更重要的是，组内几个人最好统一 Wireshark 的配置模板，否则同一个 pcap 文件在两个人的电脑上打开，点码、SIO、地址翻译全不一样，排查问题时会互相怀疑对方的结论。

5.5 SCTP 报文抓全了，但上层消息还是“缺胳膊少腿”

现象：tcpdump 抓到的是 SCTP 包，Wireshark 里也能看到 M3UA，但 SCCP/TCAP 层一直提示数据不完整，有些消息根本不解码。

原因：最常见的两种情况：一是抓包时用了-s 96之类的截断值，SCTP 报文被切短，后续分片丢了自然重组不了；二是交换机端口镜像在负载较高时丢了少量包，而 TCAP 层对消息完整性要求很高，丢一个包整个事务就断了。

解决：抓包必须加-s 0抓全包；端口镜像丢包的话，考虑提高镜像口带宽或者只在低峰期抓。另外我有个习惯是抓完包先看 SCTP 层有没有 TCP 一样的“分片重组完成”提示，如果有大量类似提示，说明上游抓包链路不可靠，这份 pcap 做全量分析的价值已经打折扣了。

6. 把抓包分析固化成统计脚本：用 tshark 给七号信令做体检

日常维护里最有用的一件事，是把零散的抓包分析变成一个可以重复跑的统计脚本。你不需要每次都打开 Wireshark 图形界面，用 tshark 的-z统计模块就能快速出一份协议分布和呼叫动向的概览。

tshark -r "$1" -q -z io,stat,60,"isup||sccp||tcap"

-q表示安静模式，不显示逐包列表；-z io,stat,60按 60 秒间隔做流量统计，后面的过滤器统计的是 ISUP、SCCP、TCAP 三类消息在时间轴上的分布。输出的结果能直接看出信令峰值出现在哪个时段。

再进一步，把单包消息类型也统计出来：

tshark -r "$1" -T fields -e isup.message_type 2>/dev/null | sort | uniq -c | sort -rn | head -20

这条命令提取所有 ISUP 消息的消息类型字段，排序后统计出现次数，前面几行就是占比最高的几类消息。正常情况下 IAM、ACM 应该是前几，如果 REL 数量异常大，那说明呼叫失败比例偏高，值得立刻深挖。把这个脚本封装起来，入参改成当天抓包文件，再挂一条 crontab，每天凌晨跑一次，早上一来就能看到昨晚的信令健康度。

我早期做信令分析时，习惯打开 Wireshark 就到处点，后来改成先跑一遍脚本看整体统计，再针对异常局向和电路做定向过滤。这个顺序帮我少走了很多弯路——先看面，再看线，最后才看点。如果你也在啃 SS7，希望帮到你。

本文还有配套的精品资源，点击获取