企业官网建设流程全解析

简介：GSM网络拓扑结构讲义以PPT课件形式，系统梳理移动通信核心网架构与信令体系，适合通信工程专业学生、网络优化与运维工程师快速建立整体认知。全篇围绕基站子系统、网络交换子系统和运营支持子系统展开，先解析拓扑中移动交换中心、基站控制器、基站收发信台等关键节点，并说明其呼叫处理、移动性管理与无线资源控制功能；随后深入介绍七号信令网的协议分层，涵盖消息传递部分、信令连接控制部分、移动应用部分和事务处理应用部分，并对比电话用户部分与ISDN用户部分在语音、数据业务上的差异。内容还覆盖典型信令流程、位置更新定时器、关键信令消息内容，以及Wireshark等常用信令分析软件与基本分析方法，帮助读者从拓扑到协议、从流程到排错形成完整知识链。资源为单个PPTX文件，大小约1.27MB，已有77人学习，可作课件自学、入职培训或通信类面试前的快速复习材料。

1. GSM网络拓扑结构：看懂这张图，才能看懂信令

拿到这份GSM网络拓扑结构讲义，我最先做的事，是把PPT里那张网元关系图按“谁存数据、谁传信令、谁控无线”重新画了一遍。GSM的复杂不在射频，而在网元和接口的咬合：TMSC管跨局转接，MSC管呼叫处理，HLR存用户归属，VLR记临时位置，BSC/BTS管无线资源，每一对网元之间都有一条明确标注的接口——A口、Abis口、Um口、C/D/E口，以及一套对应的信令协议。整份讲义其实就是“拓扑→协议→流程→分析”的完整闭环，适合刚入核心网或网优、做信令分析但没系统捋过协议栈的人。把这套骨架理清楚，后面看抓包、对故障、调定时器都会顺很多。

2. 核心网元与接口：MSC/HLR/VLR/AUC的分工与A/Abis/Um口映射

看信令抓包最难受的一点，是不知道每条消息的“主语”和“宾语”是谁。GSM把功能拆到了不同网元上，每个网元只负责一部分事，消息在网元之间流动时，协议栈也跟着变。所以第一步不是背协议，而是先把网元职责和接口协议认全。

2.1 网元功能与数据归属：HLR存归属，VLR记拜访

网元之间的本质区别，是它们各自保存的数据不同。HLR是永久数据，VLR是临时数据，搞清楚这一点，后面所有MAP消息的流向都能推断出来。

HLR和VLR的分工，可以简单记成：HLR永远知道用户“应该在哪”，VLR知道用户“现在在哪”。用户漫游到新MSC/VLR区域时，新VLR会向HLR要签约数据，HLR留下新VLR地址，同时通知旧VLR把临时数据清掉。这一来一回就是MAP的Update Location和Cancel Location操作，是全网位置更新信令的基本盘。

AUC和SIM卡之间的关系是鉴权链路的起点。SIM卡里写死了Ki，AUC里也存着同一个Ki。AUC生成一个随机数RAND，用Ki和RAND跑A3算法得到Sres，跑A8算法得到Kc；Sres用来鉴权，Kc用来给空口加密。这张卡能不能通过网络认证，完全取决于两边的Ki是否一致、算法是否兼容。

提示：现网里HLR和AUC经常做成同一个物理平台，H接口更多是逻辑概念。抓包里看不到独立的H口信令，别在H口上浪费时间。

2.2 接口协议映射：A口走BSSAP，D口走MAP

接口决定了信令协议的长相。同一个位置更新请求，在Um口是RR层的帧，到了A口被裹成BSSAP，再到D口变成MAP操作，内容没变，承载方式一直在变。

A口是新手最容易看晕的接口。BSC和MSC之间跑的是BSSAP，它内部拆成两半：DTAP负责把MS的CM、MM消息原样透传给MSC，BSSMAP负责BSS自身的资源管理，比如Assignment Request分配TCH、Paging寻呼。区分DTAP和BSSMAP，看SCCP层的子系统号和消息第一个字节就能判断：BSSAP的SSN一般是62，消息首字节为0x06或0x07时是DTAP，0x00到0x03附近是BSSMAP。

MAP则跑在C、D、E、F、G口上，是MSC/VLR/HLR之间交换业务数据的协议。它不关心无线资源，只关心用户数据怎么查、怎么更新。位置更新失败的排障，一半时间花在区分“DTAP里MS的请求”和“MAP里VLR对HLR的操作”上——前者是用户在说话，后者是数据库在同步，别混在一起看。

3. 七号信令网与协议栈：从HSTP/LSTP到MTP/SCCP/TCAP逐层拆解

GSM的信令协议分成两大群：七号信令协议群负责A口和NSS内部接口，GSM专用协议群负责Abis口和Um口。七号信令网本身和话路网是两张独立的网，信令网只负责搬信令消息。要理解这句话，得先看信令网怎么组，再看协议栈怎么分。

3.1 三级信令网与双平面冗余

七号信令网采用三级结构：HSTP（高级信令转接点）、LSTP（低级信令转接点）、SP（信令点）。MSC、HLR、VLR、EIR这些网元都是SP，SP不转接别人的信令，只管自己收发。LSTP负责省内转接，一般每省设2到4个，HSTP负责大区之间的转接，每个大区一套。

可靠性靠冗余叠出来：每个SP至少连两个LSTP，每个LSTP至少连两个HSTP，HSTP再分A、B两个平面。平时话务按SLS字段做负荷分担，一个平面断了，另一个平面能把信令全部接住。组网结构直接决定了DPC（目的信令点编码）和OPC（源信令点编码）怎么规划，很多“消息发不出去”的问题，最后都查回到GT翻译表或者DPC路由配置上。

3.2 MTP1～MTP3：传输、链路与路由

MTP是消息传递部分，分三层，对应OSI的下三层。MTP1是物理层，跑在2Mbps PCM链路的某个64kbps时隙上；MTP2是信令数据链路层，负责帧定界、差错检测和重发；MTP3是信令网功能层，负责路由选择和信令网管理。

MTP3最值得记住的是路由标签里的三件套：DPC、OPC、SLS。DPC决定消息去哪，OPC决定消息从哪来，SLS用来在多条链路间做负荷分担。MTP3只保证“从A点搬到B点”，不保证应用层语义，所以上层才需要SCCP和TCAP来做更细的寻址和事务管理。

3.3 SCCP与TCAP：寻址和事务处理都在这一层

SCCP补足了MTP3的两块短板：一是用GT（全局码）做网络层寻址，可以在不知道对端DPC的情况下先翻译地址；二是用SSN（子系统号）区分同一信令点上的不同应用，比如MSC上同时有MAP和ISUP，靠SSN分开。SCCP有无连接和面向连接两类服务，GSM核心网绝大多数场景用0类无连接服务。

TCAP再往上走一层，负责“事务”。一个TCAP事务里包含对话部分和组件部分，组件里有Invoke ID，把请求和响应一一对应。MAP就寄生在TCAP之上，每个MAP操作都被封装成TCAP的组件。看抓包时，TCAP层的对话ID和组件ID能帮你把一条MAP请求和它的响应配对起来，这是分析响应时延的基本功。

3.4 BSSAP与MAP：A接口和网内接口各管一段

BSSAP只在A口出现，承载DTAP和BSSMAP；MAP在C/D/E/F/G口出现，承载所有网元间的业务数据。两者的边界其实就是无线侧和网络侧的边界。MS发起的呼叫管理、移动性管理消息，走到A口时是DTAP；BSC自己做的资源分配、寻呼、切换控制，是BSSMAP；MSC和HLR之间的签约数据同步、位置更新操作，才是MAP。

这个分层关系看着繁琐，但排查方向就是靠它定的：A口解密失败，先查DTAP和加密算法；VLR不回Insert Subscriber Data，直接查MAP链路和TCAP事务；切换异常，同时盯BSSMAP和MAP两个方向的响应，先确认是哪一段没回包。

4. TUP与ISUP：电话用户部分和ISDN用户部分差在哪

A口和网内接口解决的是移动性管理，但用户真正打电话时，MSC之间、MSC和PSTN之间的呼叫接续要靠TUP或ISUP。这两个协议处理的是同一件事——电路交换呼叫的建立和释放，实现思路却差了一代。

4.1 TUP：传统电话的信令骨架

TUP是电话用户部分，脱胎于传统PSTN模拟电话时代，只服务语音呼叫。国内早期GSM网普遍用TUP做局间中继信令，后来才逐步演进到ISUP，但存量电路和互联互通场景里仍然常见。

TUP的消息结构比ISUP简单，MTP路由标签后面跟标题码H0/H1，H0决定消息组，H1决定具体消息。常见消息有IAI（初始地址消息，带主被叫信息）、ACM（地址全消息）、ANC（应答并计费）、CLF（释放）、RLG（释放监护）。在抓包里看到H0/H1就能快速判断消息类型，比硬记英文缩写更快。

4.2 ISUP：承载无关的呼叫控制

ISUP是ISDN用户部分，可以理解为TUP的升级版。它是承载无关的，一条ISUP电路能跑语音，也能跑数据，支持B通道管理、主叫号码传递、用户到用户信令这些TUP难以完成的功能。

基本呼叫流程固定在五条消息上：IAM发起呼叫，ACM表示路由找到且被叫振铃，ANM表示被叫应答（计费从这一刻开始），任一方挂机发REL，对方回RLC确认释放。IAM里带被叫号码、主叫号码、承载能力等字段；REL里的原因值（Cause）是排障的第一线索，比如Cause 16是正常释放，Cause 3是无路由到目的地，Cause 17是用户忙。

4.3 选型与识别：看到CIC先算电路

分析TUP/ISUP消息时，很多人习惯盯着主被叫号码，我一般先看CIC（电路识别码）。CIC是话路识别的钥匙，每条中继电路在信令消息里都以CIC编号出现，PCM系统号加时隙号通过厂商公式换算成CIC。看到一个呼叫的IAM，先确认CIC是不是预期电路，再往下看被叫号码，能省下大量找错时间。

5. 信令流程与定时器排查：位置更新、鉴权加密里的5个常见坑

前四章讲完网元和协议，这一章把网元和协议串起来。GSM信令流程的主角是位置更新、鉴权和呼叫建立，而定时器是这些流程的“超时保险丝”。我带项目时踩过不少坑，整理下来其实就集中在数据和定时器两处。

5.1 位置更新与起呼流程：先走哪条消息，再走哪条消息

位置更新的完整链路是这样的：MS在Um口发起信道请求，BTS上报给BSC，BSC分配SDCCH并下发立即指配；MS在SDCCH上建LAPDm链路，发出Location Updating Request，这条消息以DTAP形式从A口透传到MSC；MSC交给VLR处理，VLR发现MS是新来的，就向HLR发Update Location；HLR记录新的VLR地址，下发Insert Subscriber Data把签约数据灌给VLR，再通知旧VLR做Cancel Location；最后VLR给MS分配TMSI，MSC回Location Updating Accept。

起呼流程则是在位置更新的基础上加一段：MS发CM Service Request，网络侧先做鉴权再做加密，通过后BSC分配TCH，然后Alerting、Connect、Connect Acknowledge完成呼叫建立。鉴权回路是AUC生成RAND，VLR下发鉴权请求，MS用Ki和RAND算出Sres回传，VLR比对一致才放行；加密则用A8算出的Kc配合A5算法，在BTS和MS之间加扰。建议把这两条流程按消息顺序背下来，看抓包时一条条对照，能立刻定位是哪一步断了。

5.2 定时器参数：T3212、T3210、T3192这些数字决定什么

T3212的设置是日常优化里最纠结的参数之一。设太长，MS掉出覆盖区后网络长时间不知道，寻呼无响应率升高；设太短，大量终端频繁做周期性位置更新，SDCCH和A口信令负荷猛增。城区有PCH拥塞或寻呼无响应问题时，先看它，再动寻呼策略。

5.3 五个常踩的坑：现象、原因、解决

坑一：位置更新失败率高，VLR反复报Unknown Subscriber。现象是MS附着被拒，用户在VLR查无此人。原因通常是HLR侧用户数据异常，IMSI在HLR里不存在，或者VLR里残留了过期数据。解决方式是先查HLR里该IMSI的签约状态，再核对VLR的删除流程是否执行到位，别一上来就怀疑空口。

坑二：鉴权频繁失败，Sres永不匹配。现象是鉴权请求发下去，回传的Sres每次都不一样或都对不上。原因大概率是HLR/AUC里的Ki和SIM卡里写死的Ki不一致，或者两边A3/A8算法版本不兼容。解决方法是核对开卡数据，确认算法版本；COMP128-1存在已知弱点，新开卡应避免使用，否则即便成功鉴权也存在安全风险。

坑三：寻呼无响应、被叫建立时延高。现象是主叫侧振铃前等待时间明显变长，寻呼成功率统计下降。原因可能是T3212设置过长，大量MS实际已失联但网络仍以为它们在网。解决方法是结合寻呼成功率调整T3212，城区网络一般压到60到120分钟，郊区可以放宽到180分钟以上。

坑四：A口SCCP消息拥塞丢失，MTP2误码率高。现象是BSSMAP消息大面积超时重发，信令链路闪断。原因往往是2M传输时隙质量恶化，误码率超过门限，MTP2重发次数打满后判定链路故障。解决方法是看MTP2链路的误码率和重发计数，检查对应PCM时隙的传输质量；同时留意SCCP是否对BSSAP子系统发了SST探活，一旦SST判定子系统不可达，A口信令会整体中断，这个现象经常被误报成“MSC宕机”。

坑五：呼叫听“网络忙”，MSC侧却查不到呼叫记录。现象是主叫很快听到释放音，但MSC没有本次呼叫的呼叫详细记录。原因多是TUP/ISUP的CIC映射错位，IAM发到了错误的中继方向，或者中继电路被闭塞。解决方法是按CIC反查电路与PCM时隙对应关系，确认电路状态是Idle还是Blocked，再做一次测试呼叫跟踪电路占用。CIC在各厂商设备上的换算公式不统一，遇到这类问题先把公式表找出来，别凭经验猜。

6. 信令分析三板斧：一条位置更新流程的验证顺序

最后聊一个实际验证方法，把前面所有知识落到抓包上。我做信令分析时固定走三板斧：先画拓扑，再看MTP3路由，最后看业务消息。直接点TCAP层找操作码是最容易翻车的做法，因为消息的“主语宾语”还没搞清楚。

第一板斧是确认网元关系，抓包前先画出BSC、MSC、VLR、HLR的物理连接，标好DPC/OPC和接口类型。第二板斧是看MTP3层的OPC/DPC，确认消息确实走在你预期的路由上；再往下看SCCP层的GT和SSN，GT翻译对不对、子系统号是不是BSSAP或MAP，这里能挡住一半的“消息发错地方”问题。第三板斧才是看业务消息本身，打开TCAP或MAP层，找操作名和响应时间。

tshark -r gsm_a_interface.pcapng -Y "gsm_map.update_location" \ -T fields -e frame.time -e mtp3.opc -e mtp3.dpc \ -e sccp.called_party -e sccp.calling_party

这条命令把A口抓包里所有位置更新操作筛出来，只看时间戳、源目的信令点和SCCP地址字段。-r指定抓包文件，-Y是显示过滤器，-T fields把指定字段按行导出，方便直接粘到表格里对比。不清楚字段名时，在Wireshark里右键目标字段选Apply as Filter，它会自动生成标准的字段名，抄过来就行。

拿到筛选结果后，对比每条Update Location的时间戳。如果请求发出到收到响应的时间接近T3210甚至反复重发，多半是HLR或VLR处理慢，顺着DPC去查目的网元的负荷；如果消息压根没到HLR，那就是SCCP GT翻译或路由表的问题。这套顺序看着多了一步，实则每条消息的来龙去脉都清楚了。我以前看信令喜欢直接点TCAP层，结果经常被一段“看起来没毛病”的消息带偏。从那以后我每次做信令分析都强制走一遍：先画拓扑定网元，再查MTP3路由，再看SCCP地址，最后才审业务消息。反复几次，位置更新、鉴权失败这类问题的排查时间能砍掉一半。希望帮到你。

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