简介聚焦七号信令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高四位是网络指示语SSFSI 等于 3 说明载荷是 SCCP 消息SI 等于 5 说明载荷是 ISUP 消息。接下来是四字节的路由标记依次是 DPC14 比特、OPC14 比特、SLC4 比特。从 SIO 后面的第一个字节开始才是真正的上层数据。如果 SI 指向 ISUP那紧跟在路由标记后面的就是 CIC电路识别码占两个字节再往后一个字节是消息类型码。IAM初始地址消息的消息类型是 1ANM应答消息是 9REL释放消息是 12RLC释放完成是 16。看到这里你就能理解为什么 Wireshark 能自动把抓包拆成 mtp3、isup 两层它只是在按这个固定偏移切字节。自己在写协议解析脚本时最稳的做法不是硬编码偏移而是先读 SIO再按 SI 决定下一个解析器是 ISUP 还是 SCCP。MSU 载荷结构从 SIO 开始 SIO : 1 字节SI3 表示 SCCPSI5 表示 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和子系统号SSNGT 可以是 E.164 号码格式SCCP 负责把 GT 翻译成“点码 SSN”这样上层业务就不需要关心你落在哪个物理网元上号码搬家、网络割接对业务无感。TCAP事务能力应用部分则负责更上层的事务管理位置更新、短消息、智能网业务都在 TCAP 里以“对话 操作”的方式交互。一个 TCAP 事务由事务 ID 标识Begin 消息带上发起方事务 IDContinue 和 End 消息通过事务 ID 把同一个业务的多条消息串起来。做信令分析时SCCP 层让你找到“这条消息发给谁”TCAP 层让你看到“这个业务办到哪一步了”两个视角配合才能还原一次完整的业务交互。2.4 一张对应表业务、协议层和寻址字段各就各位业务场景主要协议承载路径关键寻址字段固定/移动呼叫控制ISUPMTP3 直接承载CIC DPC/OPC位置更新MAP over TCAPSCCP MTP3GT SSN短消息MAP over TCAPSCCP MTP3GT SSN智能网触发INAP/CAP over TCAPSCCP MTP3GT 事务 ID这张表基本覆盖了日常能见到的七号信令业务。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指定输出文件名抓完按 CtrlC 停止。实际抓包前我一般会先不加-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 headery -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 和 TCAPISUP 负责主叫到被叫的电路接续TCAP 里的 MAP 消息负责查询被叫当前所在的位置区。这两类消息走不同的协议层但通过一个共同的“主叫号码”能关联起来。分析时不要试图在一个显示过滤器里同时解出所有信息而是分别过滤isup和tcap先各自还原流程再交叉对比时间点。很多让人困惑的现象比如“ISUP 显示呼叫已接通但用户没收到振铃”其实答案藏在 TCAP 的位置更新或寻呼响应里。5. SS7 协议分析的避坑记录5 个让我白加过班的问题5.1 用 isup 过滤器筛出的消息解不开先把 SIO 对齐现象明明抓到了 M3UA 流量用-Y isup过滤也能出包但点开看没有 ISUP 层只有一串 M3UA Data 原始字节。原因M3UA 的 Data 参数里装的并不都是 ISUP 消息。SIO 的 SI 值决定了载荷类型如果 SI3那载荷是 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 把自己拼的十六进制字节转成 pcapWireshark 打开后要么不认 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希望帮到你。本文还有配套的精品资源点击获取