简介面向电信网络工程师、通信专业学生及SS7技术研究者这份压缩包系统整理了七号信令SS7协议栈的学习资料核心涵盖消息传递部分MTP的三层结构、信令连接控制部分SCCP的面向连接服务、事务处理应用部分TCAP的复杂事务处理机制可帮助理解呼叫建立、路由选择、计费及信令网组织等关键业务。包内共607个文件以465张JPG图片和138个HTM网页为主辅以少量HTML与TXT文本JPG多用于展示信令流程图、网络拓扑与报文截图HTM网页则提供分层协议详解压缩包整体仅3.43MB便于快速下载学习。已有371人浏览学习。资料还进一步讨论SS7与IP网络的融合方式、安全漏洞及防护手段并附有实例分析既可作高校通信课程补充教材也能为一线维护人员的信令排障和网络优化提供参考学习价值较为突出。1. 七号信令SS7协议资料包从协议栈到工程落地能挖出什么做通信的人对七号信令这四个字都不陌生尤其是搞过核心网、程控交换或者信令监测的。SS7Signalling System No.7不是某一台设备的协议而是一整套电信级信令协议栈电话能不能接通、来电显示对不对、漫游计费准不准背后全是它在干活。这套资料包是htm网页存档按编号排列了一批关于SS7协议栈、信令网组织、SCCP和TCAP应用、以及IP网络融合的文档适合两类人一类是刚进核心网或信令方向的工程师需要快速把MTP、SCCP、TCAP这些概念串起来另一类是做信令监测、计费对接、异网互通的老手拿来当案头参考查消息格式和寻址细节。先说结论这包资料的价值在于它把「协议长什么样」和「实际组网怎么用」放在一起讲比单纯看协议规范原文好读得多。很多人学SS7卡在同一个地方规范文档太散ITU-T的Q.700系列、Q.701到Q.714每本一个主题翻完还是不知道一条呼叫从主叫到被叫经过了哪些信令节点、每个节点查什么表、消息里哪几个字段决定路由。这份资料恰好是反过来的组织方式按信令网实际工作的顺序来讲先有网络架构再谈每层协议职责最后落到消息格式和案例基本可以当一本结构化手册用。2. SS7协议栈的分层逻辑MTP、SCCP、TCAP各管哪一段2.1 为什么说MTP是SS7的地基而不是全部接触SS7的第一课永远是MTPMessage Transfer Part消息传递部分但很多人把MTP直接等同于SS7这是常见的认知偏差。MTP管的是信令消息在信令网里怎么可靠地从A点搬到B点它分三层——MTP1是物理层对应E1里的某个64kbit/s时隙或者模拟信令链路MTP2是数据链路层负责信令单元的定界、差错检测和重传核心机制是信号单元格式里的FSN前向序号、BSN后向序号和重传队列MTP3才是真正的网络层做信令消息的路由选择、链路倒换和信令网管理。这个分层和TCP/IP协议栈有可比性但别硬套MTP1和MTP2合起来更像数据链路层的职责而MTP3更接近IP层的寻址逻辑。SS7里没有「IP地址」这回事节点靠的是OPC源点码和DPC目的点码来标识点码长度随信令网规格不同有所差异14位点码是常见配置24位点码用在国际网段。从工程角度看这份资料最有用的部分是MTP3的信令网管理功能包括信令链路管理、信令路由管理和信令业务管理。开局调测时候最容易出问题的就是信令路由集和链路集的配置关系——一条信令路由可以包含多条链路多条链路组成链路集倒换和倒回的动作都是基于链路优先级和路由状态来触发的。资料里对这类管理流程的编址和状态迁移讲得比较细适合对着现网数据看。2.2 信令单元格式FISU、LSSU、MSU的差别和用途信令消息在链路上不是裸奔的它被封装成三种信令单元Signal Unit来传输。填充信令单元FISU用于链路空闲时保持同步和连续校验长度只有6个字节链路状态信令单元LSSU用于链路状态的对齐、正常/紧急定位和业务中断通告消息信令单元MSU才是真正承载用户信令消息的载体包含SIO业务信息八位位组和SIF信令信息字段长度可变最长能到272个字节。三种信令单元的区分靠长度指示码LILI0是FISULI1或2是LSSULI≥3是MSU。实际排查链路问题时抓包看两种典型状态就够判断大半一直发FISU说明链路空闲或对端没起来出现紧急定位LSSU说明对端告警或参数不匹配。这里有个容易误判的点——FISU里的BSN和FSN不是没用的填充它们是链路接收状态的对端确认抓包时数FISU的序号能判断对端有没有正常回确认。2.3 业务八位位组SIOSS7网络怎么区分业务类型SIO是整个SS7消息里很小但很关键的1个字节分服务指示语和子业务字段两半。服务指示语SI高4位告诉MTP3这条消息要交给哪个用户部分处理——3是SCCP5是TUP6是ISUP子业务字段低4位用于区分国内和国际网段网络管理消息和常规消息的处理路径差别也在这体现。为什么说SIO是排查消息丢转的第一关键字段因为MTP3是傻转发它根据DPC把消息从一条链路搬到另一个节点至于搬上去之后给谁处理完全看SIO。很多时候抓包发现SCCP消息被当成ISUP处理或者ISUP消息被丢进SCCP队列原因就是SIO配错或改包时动了这个字节。资料的实例分析部分对SIO在各业务场景下的取值有对应表建议把这些值复制成自己的速查表贴工位上。2.4 从ISUP到INAP用户部分的职责切分MTP干完搬运工的活剩下的事交给用户部分。ISUP负责电话业务的建立和释放消息类型包括IAM初始地址消息、ACM地址全消息、ANM应答消息、REL释放消息和RLC释放完成消息一条普通本地呼叫只靠ISUP就能走完。但一旦涉及智能网、移动性管理或者短消息这类业务ISUP就不够用了这时候SCCP和TCAP必须出场因为业务节点之间要传的不是简单的电路控制信息而是带参数的操作请求和响应。TUP是ISUP的上一代电话用户部分现在现网里TUP基本退网或只在个别老局向里残留新开的局点全部是ISUP。这份资料对两者的差异说得比较清楚——TUP没有端到端透明传输能力也没有主叫号码的灵活传送ISUP在这两方面是质的改进。学习这类协议最怕照着教科书背消息名更好的是拿一个真实呼叫流程来逐条对消息资料里恰好有这类实例分析。3. 信令网工程配置点码、子系统、路由表怎么落到现网3.1 点码与子系统号SS7的寻址体系拆解SS7寻址不是单一维度而是两个层次配合。第一层是信令点编码SPC用于MTP3寻址识别的是物理信令节点第二层是子系统号SSN用于SCCP寻址识别的是节点内部的具体应用——比如MSC里的VLR是SSN7HLR是SSN6MSC的MAP应用是SSN8。消息从MSC到HLR查位置信息DPC填HLR所在STP下的HLR点码SSN填6SCCP到了HLR节点后把消息投给HLR应用而不是SS7协议栈里的其他模块。点码格式常见的有14位和24位两种14位点码写成x.y.z形式是惯例比如1.2.3换算成二进制后按点码字段位宽拆分。不同厂商设备对点码的配置方式不太一致华为的MSC里点码是全局配置的而诺基亚的设备里点码跟网络指示语绑定同一个物理节点在不同网络里可能有不同点码值。开局对数据时最容易出错的就在这里——两侧点码互换了OPC和DPC消息发出去后发现回不来抓包看Up方向的消息OPC/DPC和Down方向正好是一对反的才算正常。3.2 信令链路选路链路集、路由集和负载分担的配置逻辑一个大型信令点通常不会只有一条信令链路而是把多条链路组织成链路集再通过路由集关联到不同目的信令点。MTP3对链路的选择规则是先根据DPC找到对应的信令路由路由里按优先级排序链路集同一条消息的收发必须走同一对链路收发方向绑定从链路集里选一条具体链路时按SLS信令链路选择码做负载分担。SLS是MSU里的4位字段取值范围0~15理想情况下16条链路每条分担约1/16的负荷。工程上要让负载分配均匀关键在于上层业务消息里能参与SLS计算的字段要足够离散——ISUP的SLS通常拿CIC电路识别码低4位来生成一个局向开了几百条电路的话CIC分布本身就够散SLS不太会扎堆。但如果电路数少于链路数SLS覆盖不全部分链路就可能空转或者某些链路拥塞这是扩容电路时必须评估的。3.3 信令点编码与网络指示语的组合选择网络指示语NI是SIO子业务字段里的核心位取值有国际网、国内网等几种。NI的作用不只是标识网络类型它还参与点码的管理域隔离——同一个点码数值可以出现在多个NI下互不冲突前提是设备支持按NI独立管理路由表。现网里处理国际呼叫时经常遇到点码冲突问题两个运营商不同网段用了相同点码值如果不靠NI隔离路由表就会打架。资料对这部分有明确的场景说明开局做国际局数据时国际呼叫的消息和国内呼叫的消息不要混在同一条CIC里走ISUP因为后续计费、号码变换、主叫鉴权的处理路径不同。我一般会建议把国内和国际电路分组CIC段各自对应独立的电路识别码范围这样ISUP消息的SLS分布自然分开链路负载也更均匀。3.4 信令网管理消息在开局调测里的作用开局调测看的最多的不是业务消息而是MTP3的管理消息。信令点启动时候发的是信令点活跃测试和信令路由集测试链路启动时候发的是定位、对齐和验证流程这些管理消息能直接反映对端设备的信令点状态和链路状态。如果链路起不来先把管理消息抓全看停在哪一步——是定位一直达不到正常状态还是验证阶段一直失败对应的原因通常分别指向链路参数不匹配和时隙配置错误。信令路由管理里有一类专门的消息叫禁止传递TFP和允许传递TFASTP往信令点发TFP说明该STP暂时不能转发到某个目的点码区域的业务。调测时遇到甩话务或者某局向呼叫全不通先看STP侧有没有发TFP有TFP就是转发路径断了没有TFP但仍不通问题大概率出在SCCP层那就换抓包维度去查GT翻译。4. SCCP与TCAP实战GT翻译、子系统路由和事务管理4.1 SCCP的两种服务面向连接与无连接怎么选SCCP是MTP3的增强层因为MTP3只认点码不认识「业务叫什么名字」。SCCP在MTP3的点码寻址之上叠加了GT全局标题和SSN的寻址维度能力是让信令消息可以不依赖点码直接通过GT找到目标节点。SCCP提供两类服务无连接服务类别0和类别1和面向连接服务类别2和类别3。现网里99%的SCCP消息走的是无连接服务包括MAP里几乎所有操作、INAP的触发查询和CAP的智能业务交互。面向连接的使用场景很少主要用于承载数据量较大的临时交互比如某些厂商网元间的文件传送或长事务。组网设计阶段如果谈SCCP先确认用哪种服务类别因为面向连接涉及连接建立、释放、分片重组等完整状态机对节点内存和定时器要求都不一样把无连接业务配到面向连接资源上是开局里经常翻车的地方。4.2 GT翻译怎么做全局标题到点码的转换逻辑GT翻译是SCCP里最核心的工程概念。上层业务比如MAP发消息时根本不知道HLR的点码是什么只知道自己要找某个IMSI或MSISDN对应的HLR于是把这个号码填成GT填入SCCP的被叫地址。SCCP收到后在本地做GT翻译按翻译规则确认地址性质、翻译类型和编号计划把GT翻译成DPCSSN然后交给MTP3去寻址。翻译规则的配置顺序有讲究。先判地址性质是不是能直接路由再判翻译类型GT还是点码SSN然后按编号计划匹配规则序号。匹配过程中最容易出问题的是号码分析表的优先级和最长匹配原则——如果两条规则前缀相同长度不同分析表必须把长前缀规则放在前面否则号码段短的规则先命中长号码就被错误路由。资料里对这类分析逻辑有举例实际配置时建议用一个测试GT串逐条跑匹配验证而不是直接信配置结果。4.3 TCAP事务层ID管理、对话终止和超时处理TCAP是SCCP上面的应用层基础设施为MAP、INAP、CAP这些业务提供统一的「事务」语义。一个TCAP事务由事务ID对来标识——发起方分配源事务ID接收方分配对应事务ID后续消息靠这对ID路由到正确的应用实例。事务ID不是永远递增的它有自己的生命周期管理空闲ID会被复用两端必须在超时后正确释放ID资源否则ID分配耗尽会导致新事务无法建立。TCAP的超时参数在现网故障里经常背锅。等待响应超时Timer A、对话空闲超时Timer I、事务终止等待超时Timer T这组参数如果配得太短在HLR响应稍慢或者网络瞬时拥塞时MSC就直接放弃事务发起释放用户侧能看到呼叫失败或者位置更新不成功。配参数的原则是给对端留足处理时间但也不能长到把异常事务堆在内存里不释放。不同业务的超时要求不同比如位置更新和鉴权中心交互的超时要短一些而移动终结呼叫的取路由可能要等更久。4.4 一次位置更新的完整信令交互拆解拿手机开机做位置更新来串一遍SS7各层协作手机发起位置更新请求到BSC/RNCMSC收到后要向VLR要用户数据VLR发现不认识这个用户就通过MAP消息向HLR发位置更新请求。这条MAP消息封装在TCAP里TCAP信息放进SCCP的无连接数据包SCCP按GT翻译找到HLR的点码和SSN整个包再交给MTP3按DPC寻址转发到HLR所在信令点HLR侧的SCCP收到后按SSN6投给MAP用户TCAP把事务ID解析后把操作交给HLR应用处理HLR更新位置后原路返回响应。这条链路上任何一层出错都会导致位置更新失败但表象可能完全不同。MTP3层出问题表现为信令链路正常但消息到不了HLRSCCP层出问题表现为GT翻译失败或者SSN投递错误HLR侧抓不到任何MAP消息TCAP层出问题表现为消息到了HLR但事务ID对不上或者等待响应超时。排查时按这个分层维度逐步收窄范围比盲目抓包重放高效得多。资料的实例分析部分对这类典型场景有完整走查建议对着信令监测平台的跟踪记录一条一条看。5. SS7组网与调测避坑五个最容易翻车的高频问题5.1 信令链路起不来定位消息一直发现象链路状态停留在定位阶段对端收到定位消息后不回验证或者回了验证但对端SIO里的网络指示语不匹配。原因通常是两个方向——物理时隙配错A口的E1时隙和B口的实际时隙不一致或链路参数里网络指示语两侧配置不一致国内网和国际网混配。解决先ping物理层确认E1的时隙有信号且帧同步再逐项核对两侧的网络指示语、链路编号和信令点编码注意点码最高位是不是被设备默认按网络指示语掩掉了。这类问题80%是开局数据录入时复制粘贴错了行建议配置后用脚本比对两侧整条链路数据而不是人眼检查。5.2 GT翻译命中错误前缀导致消息被路由到隔壁局现象SCCP消息在信令监测上看是发出去了但对端局怎么都收不到或者收到了但业务应用说地址不对。原因号码分析表里两条规则前缀接近短前缀规则排在长前缀规则前面导致长号码被截断匹配。解决把分析表规则按前缀长度降序排列同时确保每条规则的地址性质、翻译类型、编号计划和后缀处理都完整配置加一条测试GT从源节点端到端追踪一次确认经过的每个STP都做了预期的翻译。做号码分析表我习惯在交付前用现网话单里的真实号码抽几十条批量验证路由结果光靠配置页面看是看不出毛病的。5.3 电路正常但电话呼不通信令监测上看到REL带原因值现象ISUP的IAM发出去对端回了REL释放释放原因值显示未分配的电路或电路故障。原因本端CIC配置和对端不匹配或者两侧电路状态不一致——一侧在维护态另一侧还在空闲态。解决先查CIC的奇偶属性ISUP电路识别码的奇偶性必须两端一致再查电路状态用电路维护命令逐个电路探测两侧状态位。实际工作中发现这类问题大概率是电路开通流程里一侧做完硬环回测试后忘了恢复状态把电路从测试态切回空闲态再做一次状态核对就好了。5.4 TCAP事务ID耗尽新业务无法建立对话现象业务平台侧出现大量事务建立失败日志显示事务ID分配失败或者ID冲突。原因对端响应慢导致等待队列堆积ID被占用后不能及时释放加上本地设置的超时时间过长ID资源被拖死。解决先把超时参数调短让异常事务尽快终止释放ID再检查对端的处理能力是否下降比如HLR有数据库性能问题避免在故障排查时把原因全算到己方配置上。TCAP事务ID资源池的监控最好纳入日常巡检别等业务刚呼不通才去看。5.5 信令链路负荷不均衡部分链路拥塞现象同一个信令路由集下几条链路中某一条的占用率明显高于其他几条业务高峰时段出现消息排队延迟。原因SLS生成方式不散从上层的CIC取值集中在个别数值段上导致散列结果不饱和。解决检查上层业务消息的SLS计算来源ISUP看CIC分布SCCP看SCCP层是否做了负载分担配置如果链路数大于SLS的散列空间超过16条必须依赖上层消息里的更高位参与散列部分设备支持配置SLS重映射。开多链路时我一般要求先做一轮链路负荷仿真或者现场压测把SLS分布打印出来看均匀度再放业务。6. 从七号信令到SIGTRANM3UA对接的必调参数与验证方法SS7要往IP网络演进靠的是SIGTRAN协议族其中最常用的是M3UAMTP3用户适配层。M3UA干的事是把MTP3的寻址语义映射到IP网络上信令点编码依然保留但底层承载从E1链路上的64k时隙换成基于SCTP流控制传输协议的连接。SCTP和TCP相比多了多归属和多流特性更适合承载信令——多条流之间互不阻塞某个流的丢包重传不影响其他流。M3UA对接里必须盯的参数有几个本端和对端的信令点编码在IP世界里依然按点码算、路由上下文Route Context、以及SCTP偶联参数中的流数量。M3UA消息里的网络指示语依然还在对接时两侧必须一致。对接测试时用真实业务各跑一遍比如发一条MAP位置更新、发一条ISUP的IAM/REL分别验证IP侧的信令链路状态、路由状态和业务消息的端到端正确性。有很多人对接SIGTRAN一直用TCP思维去看什么重传超时、拥塞窗口但对信令而言更重要的是SCTP多流里的流ID分配策略——被叫号码和主叫号码的散列要尽量分配到不同流上否则单个流的拥塞会把整个局向的消息全拖住。从那以后我做SIGTRAN对接强制走一遍完整检查点码、路由上下文、SCTP偶联数、流数量然后用测试消息从源端到目的端全链路追踪一次确认每个转接点都对。信令这东西参数配错一个位消息转错一个节点都是批量生产事故没有后悔药可吃。希望这套资料里的实例分析和排查思路能帮你少走这些弯路。本文还有配套的精品资源点击获取