简介这是一份SS7七号信令协议学习资料包面向通信工程专业学生、网络运维与信令研究工程师适合用于协议原理学习、组网方案梳理与信令排障入门。压缩包共607个文件含465张图片、138个HTM页面、3个HTML文件及1个TXT文档图片与网页形式便于查阅信令消息格式、协议分层结构及信令网组网案例。内容覆盖MTP、SCCP、TCAP等核心层次涉及七号信令网络架构中SP/STP的职责、信令数据单元与SIE解析、SCCP的面向连接服务、TCAP在智能网中的应用、SS7与IP网络融合以及安全风险与防护等关键议题可辅助读者从概念理解走向实际排障。包内另附www.pudn.com.txt资源链接便于拓展阅读。压缩包整体仅3.43MB轻量便携目前已有370人浏览学习适合需要系统梳理七号信令知识或进行通信技术调研的从业者与研究者。1. 七号信令SS7为什么到现在还死不掉先搞清楚这份资源装的是什么SS7全称Signalling System No.7中文叫七号信令是一套专门用来控制电话网络的信令协议栈。你可能会觉得它是上个世纪的遗产但到今天每一次跨网呼叫、每一次国际漫游底层靠的都是SS7在交换机之间传话。这份压缩包里装的是整理好的SS7协议资料以html网页文档为主从MTP传输层一路讲到SCCP、TCAP和信令网组网对做VoIP网关开发、信令运维以及通信项目交付的人来说比啃教材更贴近工程现场。先提醒一句这是文档型资源不是代码工程解压出来是一批htm页面按章节顺序读别指望解压就能跑。附带的那份txt链接清单文件里也收了不少SS7相关参考资料可以当索引用。2. 从MTP到TCAP把SS7协议栈的分层逻辑一次讲透2.1 MTP Level 1与Level 2信令链路是怎么保证传不错的在所有还在大规模运行的网络协议里SS7是最不像IP的那一套。它的底层MTPMessage Transfer Part消息传递部分承包了信令的传输任务Level 1就是物理层在传统TDM网络里对应一条64kbps的DS0时隙。这个数字值得记牢SS7的基本信令链路只有64k带宽所以每条信令单元都设计得非常紧凑能少传一个字节就少传一个字节。后来为了应对信令业务量增长出现了2Mbps的高速信令链路HSL但理解SS7的绝大部分逻辑仍然要站在64k的视角上。Level 2才是SS7可靠传输的真正核心它做的事情比局域网里的二层协议细得多。一条信令单元在链路上以标志位0x7E开头和结尾中间依次是长度指示码、序号、校验位和消息主体。Level 2管三件事信令单元定界Delimitation、差错检测Error Detection和差错校正Error Correction。差错检测用16位CRC思路跟以太网FCS类似但差错校正机制很特别。基本校正法Basic Error Correction依赖正向确认和重发接收方收到正确信令单元就回一条肯定确认发现错误回否定确认NAK发送方从出错位置开始重发。预防循环校正法Preventive Cyclic Retransmission则更激进不等否定确认只要有空闲带宽就把未确认的信令单元循环重发。前者带宽利用率高后者时延抖动小。TDM链路上用哪种校正法开局时就定死了中途想换基本等于重做一次链路割接。排障时最容易忽略的是Level 2的初始定位Initial Alignment。链路启动要经过空闲、定位、验证、就绪几个阶段每个阶段都有独立定时器。我处理过一次信令链路反复起不来的故障物理层光功率正常误码率测试也正常最后查出来是验证阶段定时器T4配得太短远端还没回应本端就判定链路失效。这类问题跟线路没关系就是Level 2参数不匹配不看初始定位流程根本发现不了。2.2 MTP Level 3信令消息处理与信令网管理的分工Level 3是MTP的大脑分信令消息处理Signalling Message Handling和信令网管理Signalling Network Management两大块这两块的职责边界必须拎清。消息处理内部又拆三步鉴别Discrimination、路由Routing、分配Distribution。一句话区分鉴别是判断这条消息是不是发给我的路由是如果不需要我处理从哪条链路转发出去分配是消息是我的交给上层哪个用户部分。STP上三步全走普通端点上主要走鉴别和分配。有些教材把三步的顺序写成鉴别-分配-路由我建议按实际消息走向记成鉴别-路由-分配因为STP上根本不会走到分配只有终点才分配。信令网管理才是电信级可靠性的精髓。链路管理管链路的启用、停用、恢复路由管理负责路由可用状态在网内传播典型消息是TFPTransfer Prohibited禁止转接和TFATransfer Allowed允许转接业务管理负责在链路或路由故障时把信令业务倒换到备用链路上。实际排查话务量异常下降第一件事就是看网管系统里有没有TFP/TFA频繁交替。这种抖动通常意味着STP上某条路由在震荡常见的根因是相邻节点对某个点码的可达性判断不一致本端认为路由可用对端认为不可用两边不停交换TFP和TFA。异厂家互通时这种问题特别多因为各厂商对路由不可用的触发条件判定有细微差别这属于典型的厂商实现差异不看规范原文根本对不上。2.3 SCCP与TCAP从链路可靠到业务可用MTP只负责把信令单元从A节点搬到B节点不关心里面装的是什么业务。SCCPSignalling Connection Control Part信令连接控制部分在MTP之上补了两块能力一是端到端寻址支持基于GTGlobal Title全局码的翻译寻址二是同时提供无连接和面向连接两种传输服务。GT翻译是移动核心网里用得最勤的机制。一个MSC想找另一个MSC时往往只知道自己有对方的GT号码不知道真实点码。于是SCCP把GT塞进消息发给STPSTP查GTTGlobal Title Translation翻译表得到目的地真实点码后重新封装再转发。这个设计的好处是核心网拓扑变化时端局配置不用跟着全改只需要在STP上更新翻译表。TCAPTransaction Capabilities Application Part是个事务壳子不处理具体业务只管把一组相关对话组织成一个事务分配事务ID保证多轮请求和响应能对上号。移动网络里的位置更新、智能网里的业务查询实际业务逻辑跑在MAP或INAP层而它们全部寄生在TCAP的事务机制上。可以这么记MTP管传输、SCCP管寻址、TCAP管事务。这个分层关系是整份资料最值得反复咀嚼的地方。很多做SIP/RTP的工程师习惯把SS7想象成老版SIP实际差得很远。SIP是端到端的应用层协议SS7是一套分工明确的协议栈尤其MTP三层的设计在IP网络里几乎没有对应物。资料里的htm文档对每层的描述方式不一样MTP讲流程和定时器SCCP讲寻址和翻译表TCAP讲事务状态机阅读时注意这层差别更容易抓住重点。3. 信令网拓扑与点码寻址SP、STP怎么连OPC/DPC怎么配3.1 三类节点、两级链路先在心里画一张信令网的图学SS7和学IP最大的差别是IP网络你可以从一台路由器开始理解SS7则必须从整张网开始。这张网由三类节点组成信令端点SEP比如交换机、MSC、信令转接点STP和用于和IP域对接的信令网关。端点是信令消息的产生者和终结者STP是纯转发设备不产生业务消息只负责把消息从一条链路转到另一条链路。别小看这个定位差异实际配置时STP上很多跟业务相关的字段根本不用配但链路、路由表、点码这三样必须配到分毫不差。现网里STP几乎都成对部署每个端点至少要连到两个STP上这样才能保证单台STP故障时业务不受影响。链路也分两类直联Associated和准直联Quasi-associated。直联是两个端点之间直接拉信令链路消息不经转接准直联是端点把消息发给STP由STP逐跳转接到目的地。现网中大部分是准直联因为局间全拉直联的话链路数量会爆炸组网成本完全不可接受。但直联也有它的位置两个局之间话务量特别大、时延要求极高时直联就是刚需。多个链路聚在一起叫链路集Linkset一个链路集里的每条链路在配置时被赋予一个编码这个编码配合SLS一起决定消息走哪条物理链路。链路集的负荷分担不是简单的轮询而是按SLS哈希的后面细说。3.2 点码寻址14位和24位的差别以及OPC/DPC怎么理解点码Point Code是SS7网络层节点的地址相当于IP地址但机制完全不同。最常见的国内制式用14位点码北美用24位国际网用14位但编号空间另有分配规则。配置点码时最容易出错的是三级结构的换算。14位点码按3-8-3拆分前3位主信令区中间8位分信令区后3位信令点编号。看到2-120-3这样的点码要能立刻换算成十六进制。很多老交换机的配置界面只收十六进制数不会换算就没法开局。换算也不难主信令区左移11位分信令区左移3位再加上信令点编号得到14位的二进制值再转十六进制。2-120-3算出来就是0x0D03自己动手算一遍比背公式管用。OPC源点码和DPC目的点码存在每条MSU的路由标签里顺序是DPC在前、OPC在后紧接着是SLS总共4个字节。这个排列跟IP报文头完全相反IP是源地址在前目的地址在后SS7反着来。我见过不止一个新手第一次抓包把OPC和DPC看反最后得出消息方向错了的错误结论。每个节点还要配自己的点码集合。正常情况下一个信令点只有一个点码但用信令网关跟多个独立网络对接时一个物理节点可能要同时拥有多个点码这叫伪点码配置。伪点码场景下最容易犯的错是OPC配置忘了改成对端认可的值导致对端做反向路由时查不到源地址。3.3 SLS与负荷分担信令链路选择逻辑SLSSignalling Link Selection信令链路选择码是SS7实现负荷分担的钥匙。它由业务层在发起消息时填一个4位值需要更大分担粒度时可以扩展到8位MTP Level 3根据这个值在通往目的地的多条链路里选一条。规则一句话同一对OPC/DPC之间SLS相同的消息必须走同一条链路SLS不同的消息尽量分散到不同链路。这个设计的精妙在于SLS保证同一呼叫的多条消息严格按序到达不同呼叫又能共享链路带宽。因为同一呼叫的所有信令消息会用同一个SLS所以不会出现先发的IAM后到、后发的ACM先到的乱序问题。链路扩容时也不用改业务层配置只需要在新链路上配好映射规则把部分SLS值引过去就能分担流量。排障时如果发现某个呼叫的消息始终走同一条链路先别急着怀疑链路质量问题看看是不是SLS映射被固定或者链路集只剩一条可用链路。SLS字段只有4位理论上最多16种取值如果链路集里链路数超过16条有些链路就分不到流量这是设计上限不是故障。3.4 读资料时怎么快速提炼组网参数这些htm文档会包含一些信令网结构示意和参数表格。我读这类文档的习惯是边看边做一张参数速查表把点码格式、SLS位宽、定时器默认值、SIO里业务指示语的取值列出来。因为htm是网页格式内容分散在多个文件里检索效率很低。我的做法是先把所有htm转成纯文本或合并成一个文件再用关键字搜索。命令很简单下面给一个可用的流程。# 把当前目录下所有htm合并成一个html便于全文检索 cat *.htm ss7_all.html # 用sed把标签剥掉生成纯文本 sed s/[^]*//g ss7_all.html ss7_all.txt # 检索定时器相关段落 grep -n -i timer\|T4\|initial alignment ss7_all.txt | head -50第一条命令把散落的htm内容合并再用sed剥掉HTML标签生成的纯文本可以用grep或编辑器直接搜效率比一个个点开htm高很多。如果你手头正好有对应的抓包文件还能用tshark对照验证过滤器写法是mtp3.sio.si 5意思是只看业务指示语为ISUP的信令单元也就是下一章要拆解的MSU类型。工欲善其事必先利其器。文档资料配合抓包验证是自学SS7最省力的组合。4. 从SIO到SIF逐字节拆开MSU路由标签、H0/H1与ISUP IAM4.1 三种信令单元FISU、LSSU、MSU怎么一眼区分MTP Level 2处理的信令单元Signal Unit只有三种填充单元FISU、链路状态单元LSSU、消息信令单元MSU。抓包时一眼区分它们看长度指示码LI就行。FISU的LI固定为0它没有业务内容专门用来维持链路同步和传递确认信息。链路上没有业务消息时FISU会持续不断地填充相当于HDLC里的空闲标志。LSSU的LI是1或2承载链路状态信息比如链路忙、链路故障、初始定位进行中。MSU的LI大于2是真正携带业务消息的信令单元。判断消息属于哪一层业务要看SIO里的业务指示语SI。常见的取值里3是SCCP5是ISUPIsup协议就是它4是TUP0是信令网管理。抓包时如果发现MSU的SIO字段是0说明这是上一章讲的信令网管理消息比如TFP、TFA而不是话务消息。很多新手一看到MSU就以为是自己关心的呼叫信令结果分析半天才发现是网络管理消息。三种信令单元里FISU最常见但最容易被忽略因为它的内容对业务分析没有直接价值。但链路质量分析恰恰离不开它。FISU同样带FSN/BSN和校验位观察FISU的序号能算出链路的确认时延和重发率这是判断链路是否拥塞的重要指标。4.2 路由标签和H0/H1SIF内部的组织顺序从MTP视角看一条MSU剥掉标志位、序号和校验位之后剩下的核心部分是SIO加SIF。SIO已经讲过SIF才是业务消息的载体。SIF内部的组织顺序是固定的先是4字节路由标签也就是DPC加OPC加SLS然后才是各种业务字段。路由标签之后TUP和ISUP的组织方式不同。TUP电话用户部分用H0和H1两个半字节标识消息H0表示消息组比如IAM相关的振铃、应答消息组H1表示该组里的具体消息号各占4位拼成一个字节。ISUP则不叫H0/H1它用一个独立的消息类型字段比如IAM的编码是0x01ACM是0x06REL是0x0C。很多资料会把TUP的H0/H1和ISUP的消息类型并列讲读的时候要分清说的是哪个用户部分。按下不表H0/H1这套标题码机制虽然看起来古老但逻辑非常清晰先按组分类再在组内定位具体消息。用惯了REST风格的开发者第一次看会觉得繁琐但电信协议讲究的就是确定性和可查表性宁可多一个分类层级也不允许语义模糊。4.3 拆一条ISUP IAM消息CIC、消息类型与号码编码搭个简单场景主叫用户摘机拨号交换机A向交换机B发起呼叫建立。A发出的第一条ISUP消息叫IAMInitial Address Message初始地址消息它的使命是告诉对端我要建立一个呼叫被叫号码是这些。一条IAM的核心字段可以看下面这张表这是从实际抓包里提炼的简化版字段取值含义MTP3.DPC2-120-3目的点码被叫所在交换机MTP3.OPC2-120-1源点码主叫所在交换机MTP3.SLS0xA链路选择码决定走哪条链路ISUP.CIC0x0010电路识别码标识占用哪条语音中继ISUP.MessageType0x01IAM初始地址消息BearerCapability3.1kHz承载能力说明是语音呼叫CalledPartyNumber8613800138000被叫号码按E.164编码表里的DPC和OPC先出现跟4.2节说的路由标签顺序一致。CIC是电路识别码它标识被这条呼叫占用的语音中继。SS7里信令和话音是分离的信令消息里必须带CIC告诉对端这个呼叫要用哪条话路。如果CIC配错会出现呼叫建立成功但接续到错误电路的问题这种故障非常难查。接入侧排查时通常要做呼叫追踪配合链路测试实际走一通话路才能定位。被叫号码字段的编码也值得注意按E.164规范每两个数字压一个字节最后一个字节的高半位放填充符。所以看到的字节串跟电话号码不是一一对应的别对着ASCII码去读。表里的8613800138000在SIF里实际占7个字节最后补一个0xF收尾。4.4 做一张字段速查表把htm文档变成可检索手册这类文档型资源最大的价值是字段定义但htm格式翻起来太费劲。我的做法是把散落的字段表整理成一张自己的速查手册格式不用复杂Markdown表格就够用。整理的过程本身就是一次深度学习因为你要判断哪些字段是基础必填项哪些是任选参数。做完这张表后面读抓包基本不用再翻原始文档了。举个示例模板| 层 | 字段 | 取值/说明 | 典型值 | | --- | --- | --- | --- | | MTP2 | LI | 0:FISU 1-2:LSSU 2:MSU | 0 | | MTP3 | SIO.SI | 0:SNM 3:SCCP 4:TUP 5:ISUP | 5 | | MTP3 | SLS | 4bit链路选择 | 0xA | | ISUP | MessageType | 0x01:IAM 0x06:ACM 0x0C:REL | 0x01 | | SCCP | MessageType | 0x01:UDT 0x02:UDTS | 0x01 | | TCAP | Tag | 0x6B:DialoguePortion | 0x6B |建议每列都写清楚取值来源是哪个htm文件这样以后遇到疑问能反查原始出处。实际上制作这份表格的过程比表格本身更有价值因为字段间的关系在整理时会不自觉记住。5. 自学SS7最常踩的五个坑概念混淆、抓包误判与解压翻车5.1 把ISUP当成MTP的一部分分层对象搞错了现象看到抓包里一条IAM消息张口就说MTP出了条IAM。原因搞混了MTP和ISUP的职责边界。MTP是传输层负责把信令单元可靠送达ISUP是用户部分负责呼叫控制。IAM是ISUP的消息只是被MTP当普通载荷运输。解决嘴上改个习惯说这条MSU携带的是ISUP的IAM。写分析报告时明确区分MTP3层字段和ISUP层字段。判断一条信令消息属于哪层看SIO里的SI值SI为5是ISUPSI为3是SCCP。这个字段永远在MTP3的尾巴上抓包时一眼能看到。5.2 看到CRC错误就判断链路故障误读了Level 2的校验机制现象抓包里出现连续CRC错误立刻断定链路物理质量差申请光路整治。原因SS7链路本身就承载在TDM上误码确实可能来自物理层但Level 2的差错校正机制允许个别错误被重发消化。更常见的场景是抓包工具本身在高速链路上丢帧导致校验失败或者对端误码检测点设置过严。解决先统计错误率再看校正机制是否生效。如果错误是偶发的且没有伴随重传风暴和链路倒换大概率不影响业务。真正的链路故障表现为信令单元持续丢失、LSSU里出现链路故障状态字、链路进入初始定位流程。以FISU的序号连续性为准连续丢多个序号才是问题。5.3 用IP思维理解点码与路由地址空间和路由粒度完全不同现象配置STP路由时习惯性按IP路由表的方式去理解目的点码是网段下一跳是链路掩码是点码长度。原因IP路由是逐跳寻址、可变长子网SS7路由是固定点码空间加静态路由。SS7的信令路由表其实更像一张精确匹配表除了少量特殊用途的通配点码不存在CIDR式的聚合和最长前缀匹配。解决把点码当成一个完整的14位整数看待路由表按目的点码链路集精确配置。异厂家互通时点码的字节序处理可能不同配完一定要用TFP/TFA或信令链路连通性测试消息验证双向可达。别把一个点码拆成主信令区分信令区当网段用会出大问题。5.4 rar解压后htm文件全是乱码编码与浏览器兼容问题现象用默认方式解压rar后打开htm文件中文内容全是乱码。原因这些htm文档生成年代较早采用的是GB2312或GBK编码而现代浏览器默认按UTF-8解析导致中文显示成乱码。另外rar解压时如果文件名编码没有被正确转换也可能出现文件名乱码但这属于解压工具的编码处理问题。解决不要用系统的文本编辑器直接打开用带编码检测的编辑器比如VS Code或Notepad打开后手动切换编码到GBK。浏览器打开时先看页面charset声明没有声明就手动指定中文编码。我一般会先批量转码再阅读命令如下# 批量把GBK编码的htm转成UTF-8解决乱码 for f in *.htm; do iconv -f GBK -t UTF-8 $f $f.utf8.html done这段for循环遍历当前目录所有htm用iconv按GBK转UTF-8输出到新文件。执行前确认源文件确实是GBK否则会转出一堆错误标记。用file命令可以先看编码再决定要不要转。解压后第一时间做这件事能省很多事。提示iconv转码前先用file -i确认源文件编码误转会把原本正常的文件也搞乱。5.5 分不清TCAP与MAP事务机制与应用协议的分界现象把位置更新、鉴权这些MAP操作说成TCAP消息。原因TCAP是承载事务的通用外壳MAP、INAP才是具体业务协议。一个MAP的位置更新请求确实会出现在TCAP的Begin消息里但TCAP本身并不知道位置更新是什么它只是提供了一个事务容器。解决读文档时把TCAP状态机Begin/Continue/End/Abort和具体业务字段分开记。TCAP只有事务控制业务字段全部在它之上的应用层。抓包时看到TCAP层有Begin消息再往下翻一层才是MAP的Invoke组件两层都要分析。分不清的话写报告时逻辑会乱。6. 验证自己真懂SS7的四个方法从抓包到给自己出题6.1 用Wireshark对抓包做分层体检拿到一份SS7抓包后我推荐的验证顺序是从MTP2一直读到TCAP先看FISU和MSU的比例判断链路是否空闲再看SIO里的SI分布统计哪些业务占主导然后挑一条IAM消息用手动方式把路由标签、CIC、被叫号码逐字段拆出来对照自己整理的速查表核对。这一步能发现绝大多数文档没读懂的地方。6.2 手算点码十遍给出一组十进制点码如2-120-3要求在30秒内写出十六进制。这个速度在开局配置时非常有用。14位点码按3-8-3结构左移相加再转十六进制算完再用printf %x验证。手算十遍之后点码结构就不会再忘。6.3 把文档里的组网图重画一遍挑一个文档里出现的典型信令网结构两个端点、一对STP、四条链路自己在纸上画出链路集标出每条链路的SLS取值范围。画完再闭上眼睛回想如果一条链路断开消息会走哪条备选路径。这个推演过程直接对应信令网管理的倒换逻辑。6.4 给自己出三道信令题例如给出一份TCAP抓包判断它是Begin还是End是位置更新还是短消息给出一组OPC/DPC/SLS说出这条消息从哪个节点来、要去哪、走哪条链路给出一条LSSU说出当前链路状态是忙还是故障。这三道题能覆盖传输、寻址、事务三层全答对说明这块资料是真吃透了。我从那以后但凡拿到一份新的信令协议资料都会强制自己走一遍先分层、再拆包、后画图的流程光看不练等于白看。这套验证方法希望能帮到你尤其在做压测和协议对接前提前用抓包验证一遍能少踩一大半的坑。本文还有配套的精品资源点击获取
