简介这份PPT讲义以GSM网络拓扑与信令协议为主线面向移动通信专业学生、网络优化工程师及通信运维人员系统梳理GSM系统结构、七号信令网及核心接口流程。资源包内含一个PPTX演示文稿压缩后约1.27MB共11个章节依次覆盖网络拓扑、信令协议结构、NO.7信令网、各层协议、TUP/ISUP、信令流程、重要定时器、信令消息内容及常用分析软件。讲义对TMSC、MSC、BSC、BTS、HLR/VLR/AUC等网元的功能划分以及MTP、SCCP、MAP、TCAP、BSSAP等协议层次作了图文对照说明并结合鉴权与加密、位置更新、呼叫建立、切换等场景展示信令消息交互逻辑。其中定时器与典型信令消息的讲解尤其适合排查位置更新、切换异常等实际问题。目前已有78人学习浏览适合通信初学者作为入门教材也便于有经验者快速回顾网络架构、理解信令流程为网络优化和故障排查提供支撑。1. GSM网络拓扑结构从BTS到TMSC一张拓扑图里的分工逻辑GSM网络拓扑结构常被画成一张满是BOX和连线的图很多刚转核心网的人第一反应是背缩写BTS、BSC、MSC、HLR、VLR、AUC、TMSC……真到处理信令问题时才发现背了名字不等于知道它们之间怎么协作。换个角度理解就顺了BTS管无线信号BSC管无线资源和基站维护MSC管呼叫接续与计费HLR/VLR管用户身份与当前位置AUC管鉴权数据TMSC负责MSC之间的信令转接。这份讲义的价值是把这张拓扑图里的每个网元职责、接口类型、七号信令协议分层和典型信令流程串成一条完整的学习链适合要做网络优化、信令分析或核心网运维的人从头把GSM的骨架搭起来。2. 七号信令协议栈MTP、SCCP、TCAP、MAP、BSSAP的分层与封装关系2.1 接口决定协议Um、Abis、A口的协议分工GSM网络里的协议不是凭空分的而是按接口走的。一共三类接口MS到BTS之间的Um口、BTS到BSC之间的Abis口、BSC到MSC之间的A口。接口不同二层承载和三层消息写法也不同。Um口物理层是无线空中接口二层用LAPDm三层承载的是CM呼叫管理、MM移动性管理、RR无线资源管理消息。Abis口BTS与BSC之间通常是PCM链路二层用LAPD传输的既有呼叫控制消息也有基站维护管理消息BTSM。A口BSC与MSC之间走2M中继底层用MTP上层用BSSAP承载DTAP和BSSMAP消息。接口位置二层协议三层主要内容UmMS – BTSLAPDmRR / MM / CMAbisBTS – BSCLAPDBTSM 用户业务ABSC – MSCMTP2BSSAPDTAP BSSMAPNSS内部MSC / HLR / VLR之间MTP SCCPTCAP MAP / ISUP理解了接口归属再看协议栈就不乱了。A口和NSS内部都属于七号信令协议群用的是MTP、SCCP、TCAP这些基础承载Um口和Abis口属于GSM专用协议群侧重无线资源的分配和无线链路管理。讲义把这层分得很清楚GSM专用协议群解决“无线侧怎么把消息送到BSC”七号信令协议群解决“BSC以上的节点之间怎么可靠地传消息”。在实际抓包分析时第一件事就是确认消息从哪个接口抓的。同一个“位置更新请求”在Um口看是MM层的消息在A口看是BSSMAP/DTAP承载在MSC与HLR之间看则是MAP操作。如果不知道接口归属很容易拿A口的报文去套Um口的字段定位就会偏。2.2 MTP1/2/3信令网的物理、链路与路由MTP是整个七号信令的基础。它分成三层对应OSI下面的三层但实际用起来要比OSI更贴近传输设施。MTP1是信令数据链路层最底下那层。在GSM里通常是2Mbit/s的PCM中继上抽一个时隙跑64kbit/s信令链路。它只管把比特流从一端搬到另一端不做任何校验和重传。物理层告警、滑码、误码都在这层体现。MTP2是信令链路层负责把比特组织成信令单元做定界、定位、差错检测和重传。一条信令链路是否可用看MTP2的状态就知道。常见问题里“链路反复倒换”多半是MTP2的定位或重传参数贴边误码率一高就掉线。MTP3是信令网功能层负责信令消息的路由选择、信令链路管理、信令点间消息的转发。它认的是信令点编码DPC/OPC即目的地/源点编码和电路识别码CIC。中国规范里信令点编码是24位写作“主信令区-副信令区-信令点”例如1-2-3。换算成十进制时要注意165536 2256 3这个值在Wireshark里配置DPC/OPC时直接体现。提示MTP3里有SLS信令链路选择码用于选路SLS相同的一条会话通常走同一条链路这在分析单通或时延不均时很有用。2.3 SCCP与TCAP在MTP之上的传输与事务层MTP3只负责按DPC把消息送到一个信令点但一个信令点上可能同时驻留着MSC、VLR、HLR等多个“子系统”MTP不知道消息该给谁。SCCP就是解决这个问题的用子系统号SSN区分同一信令点内的不同功能实体。SCCP的寻址有两种按DPCSSN直接寻址或者按GT全局码寻址。MAP消息在NSS内部走时几乎都用GT寻址因为HLR、MSC的GT是网络规划统一编排的不容易随组网变化。STP的GT翻译表负责把全局码翻译成DPCSSN。抓包时如果看到SCCP层提示“GT translation failed”基本是STP表没配或配错。TCAP在SCCP之上提供事务处理能力。它有点像一个轻量级的会话管理框架给每个操作分配事务ID把“请求-响应”或“对话-多操作”组织起来。MAP的所有操作都跑在TCAP里。在Wireshark里看TCAP层里面会显示当前是“Invoke”还是“Return result”对应到业务上就是“发出请求”和“收到响应”。SCCP还有一个容易被忽略的点是它可以提供无连接服务和面向连接服务。GSM里MAP和BSSAP大多用无连接服务但某些承载业务需要端到端信令时会用面向连接类。排查超时问题时先确认用的是哪种服务类型再决定从哪个定时器下手。2.4 BSSAP与MAPA口和NSS内部的应用消息BSSAP是A口的应用协议分为DTAP和BSSMAP两部分。DTAP是“透传”消息把MS和MSC之间的CM/MM/RR消息原封不动穿过BSC送到MSCBSC只是搬运工。BSSMAP则是BSC与MSC之间的控制消息比如寻呼请求、切换命令、电路分配这些消息不是给MS看的而是BSC和MSC之间协调用的。一个典型的寻呼过程是这样MSC收到被叫呼叫后在BSSMAP里发一个寻呼请求给BSCBSC在对应LAI下所有小区下发寻呼信道消息MS在寻呼信道响应BSC通过DTAP把MS的响应透传给MSC。这里如果MSC发到BSC的LAI和MS实际注册的LAI不一致寻呼就会一直无响应。MAP是NSS内部的应用协议负责移动性管理和业务控制包括位置更新、鉴权、切换、补充业务操作等。它跑在TCAP之上常见操作有更新位置请求、发送鉴权参数、提供漫游号码等。因为MAP操作天然是请求-响应模式所以每个MAP操作都有对应的超时定时器超时后TCAP层会报对话中止。协议封装顺序可以做一个非常直观的示意MS侧发出CM/MM消息后先包成RR帧再压到LAPDm里过Um口到BTSBTS解掉LAPDm后在Abis口用LAPD和BTSM承载送到BSCBSC再把消息塞进SCCP经MTP到MSC。整个过程像洋葱一样一层套一层哪一层封装不匹配消息就在哪一层丢。3. TUP与ISUP电话用户部分与ISDN用户部分的呼叫接续差异3.1 TUP基本呼叫的消息集合TUP是电话用户部分由MTP直接承载不经过SCCP。它处理的是最基本的电话呼叫呼叫建立、应答、释放。TUP消息集不大常用的就几个IAM初始地址消息、IAI带附加信息的IAM、ACM地址全消息、ANC应答消息带计费、CLF前向释放、CBK后向释放、REL释放、RLC释放完成。TUP用CIC电路识别码标识一条中继电路。两个MSC之间如果有多条PCM中继CIC就用来区分具体是哪一条时隙。打电话时IAM里带的被叫号码决定呼叫去哪里ACMA表示被叫开始振铃ANC表示被叫摘机并启动计费。释放时由任一方发起REL对端回RLC后才算把电路释放干净。TUP比较“朴素”它不太支持主叫号码透传、多方通话、呼叫转接这类补充业务。很多老PSTN交换机还在跑TUPGSM MSC和这类老设备对接时主叫号码往往要在MSC侧做号码变换或通过IAI传递否则到对端就是匿名。3.2 ISUP从TUP扩展出的参数与业务能力ISUP是在TUP基础上发展起来的为ISDN业务设计支持语音、数据、图像等多种承载服务。它和TUP最大的区别在两点一是消息参数丰富二是支持端到端信令。TUP消息里主要就是被叫号码、主叫类别这些基础字段ISUP的IAM可以携带主叫号码、被叫号码、转接网络选择、传输媒介要求、用户业务信息等几十个参数。传输媒介要求这个参数特别值得注意它告诉对端这条呼叫是语音、64kbit数据还是3.1kHz音频如果MSC间配置不一致接通后可能听不到声音。另一个实际差异是ISUP支持SUS/RES暂停/恢复和CPR呼叫进行等消息可以支撑呼叫保持、呼叫等待这类业务。TUP里做这些业务就很别扭。对比项TUPISUP承载方式MTP直接承载MTP SCCP部分情况典型消息IAM / ACM / ANC / CLF / RELIAM / ACM / ANM / SUS / RES / REL主叫号码支持有限需IAI扩展IAM直接携带补充业务弱强支持端到端信令适用场景老PSTN对接MSC间中继、ISDN用户现在的GSM网MSC之间和MSC到PSTN的呼叫基本都切到ISUP了只有存量老设备还在跑TUP。分析信令时认识TUP不是要维护它而是为了在老设备对接场景里能看懂并且判断是TUP字段不足还是MSC数据配置漏了。3.3 一个完整本地呼叫的TUP/ISUP交互过程拿一个GSM用户呼叫PSTN用户来举例假设主叫侧MSC用ISUP和中继局对接整个呼叫接续的消息顺序如下步骤方向消息含义1主叫MSC - 对端IAM携带被叫号码、主叫号码、传输媒介要求2对端 - 主叫MSCACM对端已找到被叫开始振铃3对端 - 主叫MSCANM / ANM被叫摘机主叫MSC启动计费4任一方挂机REL发起释放携带释放原因值5对端回应RLC电路释放完成这套流程里最容易出问题的是第1步和第4步。IAM里主叫号码字段没透传就会导致被叫侧来电显示空白REL里的释放原因值如果是不认识的数值对接双方可能理解不一致出现“一边已经释放一边还在等应答”的状态。我处理这类问题时的习惯是先看IAM字段全不全再看REL之后的RLC有没有正常返回两步走完基本能筛掉八成中继接续故障。4. GSM信令流程与定时器鉴权、位置更新、寻呼与切换的节点排查避坑4.1 鉴权与加密A3/A8/A5如何配合完成身份核验GSM的鉴权机制是挑战-响应模式核心参数有KiSIM卡密钥、RAND随机数、SRES鉴权响应、Kc加密密钥、A3/A8算法。流程是MSC/VLR从AUC取一组RAND和对应的SRES把RAND发给MSSIM卡用内部存的Ki跑A3算法算出SRES回传MSC侧比对两边SRES是否一致。一致就通过不一致就拒绝注册。加密部分用A8算法基于同样的RAND和Ki生成KcKc再交给A5算法在Um口做加密。A3和A8在SIM卡里往往是同一个复合算法的两个输出实际参数是AUC生成RAND、SRES、Kc三件套发给VLRVLR在需要时下发RAND给MS。这里面有个运维上的常见坑AUC里存的Ki和SIM卡里的Ki如果不同用户就永远鉴权失败。现象是手机能收信号但一注册就被拒信令消息里反复出现鉴权失败。处理办法是把SIM卡和HLR/AUC的Ki数据做一致性核验特别是补卡后经常出这种问题。4.2 位置更新流程从MS到HLR的消息走向与T3212位置更新分三种正常位置更新跨LAI、IMSI附着开机、周期性位置更新定时器触发。前两种是事件驱动周期性的则是网络用T3212强制用户定期报到。流程上MS发起位置更新请求到BSCBSC通过BSSMAP接入MSC/VLRMSC/VLR分析用户IMSI或TMSI后向HLR发起MAP更新位置请求HLR记录当前所在VLR地址并通知旧VLR删除该用户数据。整个过程在信令上能看到一串消息MM层的位置更新请求、SCCP承载、MAP上的更新位置操作。T3212是周期性位置更新的核心参数。它由网络在系统消息里广播单位为6分钟取值范围0到255所以最大是25.5小时。取值越小用户报到越频繁网络越容易感知用户状态但信令负荷和手机耗电都会上升。一般商用网取40到70之间也就是4到7小时一次。4.3 呼叫建立与寻呼T3113、T3192及消息交互主叫呼叫被叫时MSC收到IAM后先看被叫用户登记在哪个VLR然后通过BSSMAP向对应BSC下发寻呼请求BSC在被叫当前LAI的所有小区发寻呼。被叫MS响应后MSC做鉴权和加密随后建立无线资源和中继电路双方进入通话态。这条链路上的定时器很多MSC侧等待寻呼响应通常看T3113一般设在3到10秒过了就只能拆线被叫侧MS在收到释放指令后等待网络释放无线资源的定时器是T3192取值常见1到2秒设长了会让人觉得挂机后手机半天没反应。这些都是设备商实现里的参数讲义里直接列了名称但具体数值每家略有差异核查时以现场网元配置为准。切换信令也值得提一句。MSC内切换走BSSMAP流程相对短MSC间切换要走MAP目标MSC/VLR要向HLR申请MSRN漫游号码然后两个MSC之间用ISUP建立中继电路。MSRN分配慢或号码池不够切换就会超时失败。4.4 避坑指南信令流程中最容易翻车的五个场景场景一T3212设太小引发位置更新风暴现象BSC的CCCH负荷飙升位置更新请求量骤增用户待机掉电快。 原因T3212以6分钟为单位如果被配置成5全网每半小时就周期登记一次信令量直接翻几倍。 解决核查系统消息里的T3212取值商用网一般不低于404小时并和核心网寻呼时长配合评估。场景二寻呼无响应T3113超时现象被叫呼叫建立失败MSC侧报寻呼超时。 原因常见是BSC下发的LAI与MS实际注册的LAI不一致或者TMSI重分配后旧TMSI还没被全网清除。 解决抓A口消息对比寻呼请求里的LAI和MS当前注册位置必要时让用户在目标LAI下重新开关机注册。场景三IAM消息里没有主叫号码现象被叫来电显示为空或外网统计主叫号码不规范。 原因主叫MSC在IAM里没填主叫号码参数或者做了号码变换后没放回IAM。 解决抓MSC出局中继的IAM核对主叫号码字段检查MSC数据里的主叫号码透传和号码变换配置。场景四SCCP层GT翻译失败现象MAP操作发出去石沉大海TCAP超时后业务释放。 原因STP上的GT翻译表没配或配错把全局码翻成了错误的DPC。 解决查看SCCP层返回的翻译失败指示核对STP的GT分析表再Ping一下目的信令点确认MTP3可达。场景五MSC间切换时MSRN分配延迟现象切换请求发出后长时间无响应随即失败。 原因目标VLR向HLR申请MSRN的MAP信令时延过大或MSRN号码池剩余太少。 解决检查HLR到VLR的MAP链路时延查看VLR的MSRN号码段占用率及时扩容号码资源。注意定时器核查不能只看一张PPT截图上写的默认值。不同厂商的MSC在T3113、T3192上的实现粒度不同有的按秒、有的按百毫秒统一按秒理解会犯低级错误。5. 信令分析实战从抓包配置到判断网络问题的三个习惯5.1 抓包前先做解码配置Wireshark抓SS7消息最影响效率的就是点编码配置。默认情况下它不知道DPC/OPC怎么显示抓出来的MTP3层是一串纯数字看不懂。正确做法是先查清楚网络规划里的信令点编码表把主信令区、副信令区、信令点编号全部录入再把解码显示切到点分格式这样一眼就能看出消息是发给哪个局的。5.2 判断问题的层次归属收到一个“呼叫接不通”的投诉先别急着看应用层。我的排查顺序是MTP2状态正不正常MTP3路由通不通SCCP的GT有没有翻译对TCAP里操作有没有响应最后才看MAP/ISUP参数对不对。这个顺序就是协议栈顺序哪一层断了就在哪一层解决不要跨层猜。5.3 定时器联动核查的一个实用技巧我自己养成的习惯是把T3212、T3113、T3192三个参数放在一张表里一起看。T3212决定的周期位置更新间隔必须远大于T3113的寻呼等待时间否则会出现“网络正在寻呼用户用户恰好去做周期性位置更新”的撞车窗口表现为偶发寻呼无响应。这个分析思路在投诉里的说法叫“周期性位置更新与寻呼碰撞”解决方式通常是把T3212调长给寻呼留出干净窗口。从那以后我每次做核心网核查都会强制把这几组定时器摆在一起过一遍先看单位、再看关联关系最后才落到具体消息字段上。信令分析的门槛不在背消息名而在养成从物理层往上逐层确认的习惯。希望帮到你。本文还有配套的精品资源点击获取