简介：这份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消息。

理解了接口归属，再看协议栈就不乱了。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的寻址有两种：按DPC+SSN直接寻址，或者按GT（全局码）寻址。MAP消息在NSS内部走时几乎都用GT寻址，因为HLR、MSC的GT是网络规划统一编排的，不容易随组网变化。STP的GT翻译表负责把全局码翻译成DPC+SSN。抓包时如果看到SCCP层提示“GT translation failed”，基本是STP表没配或配错。

TCAP在SCCP之上，提供事务处理能力。它有点像一个轻量级的会话管理框架：给每个操作分配事务ID，把“请求-响应”或“对话-多操作”组织起来。MAP的所有操作都跑在TCAP里。在Wireshark里看TCAP层，里面会显示当前是“Invoke”还是“Return result”，对应到业务上就是“发出请求”和“收到响应”。

SCCP还有一个容易被忽略的点，是它可以提供无连接服务和面向连接服务。GSM里MAP和BSSAP大多用无连接服务，但某些承载业务需要端到端信令时会用面向连接类。排查超时问题时，先确认用的是哪种服务类型，再决定从哪个定时器下手。

2.4 BSSAP与MAP：A口和NSS内部的应用消息

BSSAP是A口的应用协议，分为DTAP和BSSMAP两部分。DTAP是“透传”消息，把MS和MSC之间的CM/MM/RR消息原封不动穿过BSC送到MSC，BSC只是搬运工。BSSMAP则是BSC与MSC之间的控制消息，比如寻呼请求、切换命令、电路分配，这些消息不是给MS看的，而是BSC和MSC之间协调用的。

一个典型的寻呼过程是这样：MSC收到被叫呼叫后，在BSSMAP里发一个寻呼请求给BSC，BSC在对应LAI下所有小区下发寻呼信道消息，MS在寻呼信道响应，BSC通过DTAP把MS的响应透传给MSC。这里如果MSC发到BSC的LAI和MS实际注册的LAI不一致，寻呼就会一直无响应。

MAP是NSS内部的应用协议，负责移动性管理和业务控制，包括位置更新、鉴权、切换、补充业务操作等。它跑在TCAP之上，常见操作有更新位置请求、发送鉴权参数、提供漫游号码等。因为MAP操作天然是请求-响应模式，所以每个MAP操作都有对应的超时定时器，超时后TCAP层会报对话中止。

协议封装顺序可以做一个非常直观的示意：MS侧发出CM/MM消息后，先包成RR帧，再压到LAPDm里过Um口到BTS；BTS解掉LAPDm后，在Abis口用LAPD和BTSM承载，送到BSC；BSC再把消息塞进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交换机还在跑TUP，GSM MSC和这类老设备对接时，主叫号码往往要在MSC侧做号码变换或通过IAI传递，否则到对端就是匿名。

3.2 ISUP：从TUP扩展出的参数与业务能力

ISUP是在TUP基础上发展起来的，为ISDN业务设计，支持语音、数据、图像等多种承载服务。它和TUP最大的区别在两点：一是消息参数丰富，二是支持端到端信令。

TUP消息里主要就是被叫号码、主叫类别这些基础字段；ISUP的IAM可以携带主叫号码、被叫号码、转接网络选择、传输媒介要求、用户业务信息等几十个参数。传输媒介要求这个参数特别值得注意，它告诉对端这条呼叫是语音、64kbit数据还是3.1kHz音频，如果MSC间配置不一致，接通后可能听不到声音。

另一个实际差异是ISUP支持SUS/RES（暂停/恢复）和CPR（呼叫进行）等消息，可以支撑呼叫保持、呼叫等待这类业务。TUP里做这些业务就很别扭。

现在的GSM网MSC之间和MSC到PSTN的呼叫，基本都切到ISUP了，只有存量老设备还在跑TUP。分析信令时，认识TUP不是要维护它，而是为了在老设备对接场景里能看懂，并且判断是TUP字段不足还是MSC数据配置漏了。

3.3 一个完整本地呼叫的TUP/ISUP交互过程

拿一个GSM用户呼叫PSTN用户来举例，假设主叫侧MSC用ISUP和中继局对接，整个呼叫接续的消息顺序如下：

这套流程里最容易出问题的是第1步和第4步。IAM里主叫号码字段没透传，就会导致被叫侧来电显示空白；REL里的释放原因值如果是不认识的数值，对接双方可能理解不一致，出现“一边已经释放，一边还在等应答”的状态。我处理这类问题时的习惯是：先看IAM字段全不全，再看REL之后的RLC有没有正常返回，两步走完基本能筛掉八成中继接续故障。

4. GSM信令流程与定时器：鉴权、位置更新、寻呼与切换的节点排查避坑

4.1 鉴权与加密：A3/A8/A5如何配合完成身份核验

GSM的鉴权机制是挑战-响应模式，核心参数有Ki（SIM卡密钥）、RAND（随机数）、SRES（鉴权响应）、Kc（加密密钥）、A3/A8算法。流程是MSC/VLR从AUC取一组RAND和对应的SRES，把RAND发给MS，SIM卡用内部存的Ki跑A3算法算出SRES回传，MSC侧比对两边SRES是否一致。一致就通过，不一致就拒绝注册。

加密部分用A8算法基于同样的RAND和Ki生成Kc，Kc再交给A5算法在Um口做加密。A3和A8在SIM卡里往往是同一个复合算法的两个输出，实际参数是：AUC生成RAND、SRES、Kc三件套发给VLR，VLR在需要时下发RAND给MS。

这里面有个运维上的常见坑：AUC里存的Ki和SIM卡里的Ki如果不同，用户就永远鉴权失败。现象是手机能收信号但一注册就被拒，信令消息里反复出现鉴权失败。处理办法是把SIM卡和HLR/AUC的Ki数据做一致性核验，特别是补卡后经常出这种问题。

4.2 位置更新流程：从MS到HLR的消息走向与T3212

位置更新分三种：正常位置更新（跨LAI）、IMSI附着（开机）、周期性位置更新（定时器触发）。前两种是事件驱动，周期性的则是网络用T3212强制用户定期报到。

流程上，MS发起位置更新请求到BSC，BSC通过BSSMAP接入MSC/VLR，MSC/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取值，商用网一般不低于40（4小时），并和核心网寻呼时长配合评估。

场景二：寻呼无响应，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调长，给寻呼留出干净窗口。

从那以后，我每次做核心网核查都会强制把这几组定时器摆在一起过一遍，先看单位、再看关联关系，最后才落到具体消息字段上。信令分析的门槛不在背消息名，而在养成从物理层往上逐层确认的习惯。希望帮到你。

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