拓冰网站定制 
简介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消息的流向都能推断出来。网元核心职责关键数据MSC呼叫处理、切换、移动性管理、操作维护、网间互通、计费当前服务小区、话路状态、呼叫记录HLR用户归属数据库跨MSC/VLR的权威数据源IMSI、MSISDN、用户状态、补充业务签约、当前所在VLR地址VLR服务区内的临时位置登记负责TMSI和漫游号管理TMSI、LAI、移动台状态、部分补充业务数据、MSRNAUC生成鉴权三元组/五元组Ki、RAND、Sres、Kc跑A3/A8算法BSC管理一组BTS分配无线资源控制频率和功率小区配置、切换候选列表、信道占用BTS空口收发直接与MS通信载频配置、时隙状态、无线链路测量HLR和VLR的分工可以简单记成HLR永远知道用户“应该在哪”VLR知道用户“现在在哪”。用户漫游到新MSC/VLR区域时新VLR会向HLR要签约数据HLR留下新VLR地址同时通知旧VLR把临时数据清掉。这一来一回就是MAP的Update Location和Cancel Location操作是全网位置更新信令的基本盘。AUC和SIM卡之间的关系是鉴权链路的起点。SIM卡里写死了KiAUC里也存着同一个Ki。AUC生成一个随机数RAND用Ki和RAND跑A3算法得到Sres跑A8算法得到KcSres用来鉴权Kc用来给空口加密。这张卡能不能通过网络认证完全取决于两边的Ki是否一致、算法是否兼容。提示现网里HLR和AUC经常做成同一个物理平台H接口更多是逻辑概念。抓包里看不到独立的H口信令别在H口上浪费时间。2.2 接口协议映射A口走BSSAPD口走MAP接口决定了信令协议的长相。同一个位置更新请求在Um口是RR层的帧到了A口被裹成BSSAP再到D口变成MAP操作内容没变承载方式一直在变。接口连接网元主要协议用途Um口MS ↔ BTSLAPDm RR/MM/CM空口信令最复杂的一段Abis口BTS ↔ BSCLAPD BTSM基站管理、RR透传A口BSC ↔ MSCBSSAPDTAP BSSMAP无线资源控制与移动性消息承载B口MSC ↔ VLR内部接口通常合设无独立信令C口MSC ↔ HLRMAP取路由信息、被叫处理D口VLR ↔ HLRMAP位置更新、取签约数据E口MSC ↔ MSCMAP / TUP / ISUP局间切换、跨局呼叫接续F口MSC ↔ EIRMAP移动设备身份检查G口VLR ↔ VLRMAP漫游用户位置恢复A口是新手最容易看晕的接口。BSC和MSC之间跑的是BSSAP它内部拆成两半DTAP负责把MS的CM、MM消息原样透传给MSCBSSMAP负责BSS自身的资源管理比如Assignment Request分配TCH、Paging寻呼。区分DTAP和BSSMAP看SCCP层的子系统号和消息第一个字节就能判断BSSAP的SSN一般是62消息首字节为0x06或0x07时是DTAP0x00到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这些网元都是SPSP不转接别人的信令只管自己收发。LSTP负责省内转接一般每省设2到4个HSTP负责大区之间的转接每个大区一套。可靠性靠冗余叠出来每个SP至少连两个LSTP每个LSTP至少连两个HSTPHSTP再分A、B两个平面。平时话务按SLS字段做负荷分担一个平面断了另一个平面能把信令全部接住。组网结构直接决定了DPC目的信令点编码和OPC源信令点编码怎么规划很多“消息发不出去”的问题最后都查回到GT翻译表或者DPC路由配置上。3.2 MTP1MTP3传输、链路与路由MTP是消息传递部分分三层对应OSI的下三层。MTP1是物理层跑在2Mbps PCM链路的某个64kbps时隙上MTP2是信令数据链路层负责帧定界、差错检测和重发MTP3是信令网功能层负责路由选择和信令网管理。层职责关键点MTP1物理传输64kbps时隙PCM系统里时隙16常用于信令链路MTP2链路层可靠传输信令单元定界、CRC校验、基本/预防性循环重发MTP3路由与网络管理DPC/OPC/SLS路由标签、信令路由管理、信令链路管理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与MAPA接口和网内接口各管一段BSSAP只在A口出现承载DTAP和BSSMAPMAP在C/D/E/F/G口出现承载所有网元间的业务数据。两者的边界其实就是无线侧和网络侧的边界。MS发起的呼叫管理、移动性管理消息走到A口时是DTAPBSC自己做的资源分配、寻呼、切换控制是BSSMAPMSC和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/H1H0决定消息组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先算电路对比项TUPISUP服务对象传统PSTN语音呼叫ISDN及任意承载业务承载能力单一语音多承载支持高速数据主叫号码传递支持有限字段丰富可靠性高释放原因简单Cause值丰富利于定位问题与MTP关系直接承载于MTP3承载于MTP3可配合SCCP演进状态存量为主逐步退网现网主流分析TUP/ISUP消息时很多人习惯盯着主被叫号码我一般先看CIC电路识别码。CIC是话路识别的钥匙每条中继电路在信令消息里都以CIC编号出现PCM系统号加时隙号通过厂商公式换算成CIC。看到一个呼叫的IAM先确认CIC是不是预期电路再往下看被叫号码能省下大量找错时间。5. 信令流程与定时器排查位置更新、鉴权加密里的5个常见坑前四章讲完网元和协议这一章把网元和协议串起来。GSM信令流程的主角是位置更新、鉴权和呼叫建立而定时器是这些流程的“超时保险丝”。我带项目时踩过不少坑整理下来其实就集中在数据和定时器两处。5.1 位置更新与起呼流程先走哪条消息再走哪条消息位置更新的完整链路是这样的MS在Um口发起信道请求BTS上报给BSCBSC分配SDCCH并下发立即指配MS在SDCCH上建LAPDm链路发出Location Updating Request这条消息以DTAP形式从A口透传到MSCMSC交给VLR处理VLR发现MS是新来的就向HLR发Update LocationHLR记录新的VLR地址下发Insert Subscriber Data把签约数据灌给VLR再通知旧VLR做Cancel Location最后VLR给MS分配TMSIMSC回Location Updating Accept。起呼流程则是在位置更新的基础上加一段MS发CM Service Request网络侧先做鉴权再做加密通过后BSC分配TCH然后Alerting、Connect、Connect Acknowledge完成呼叫建立。鉴权回路是AUC生成RANDVLR下发鉴权请求MS用Ki和RAND算出Sres回传VLR比对一致才放行加密则用A8算出的Kc配合A5算法在BTS和MS之间加扰。建议把这两条流程按消息顺序背下来看抓包时一条条对照能立刻定位是哪一步断了。5.2 定时器参数T3212、T3210、T3192这些数字决定什么定时器所在网元作用常见配置超时行为T3212网络侧广播MS执行周期性位置更新间隔60240分钟步长6分钟最大25.5小时MS重新发起位置更新T3210MS侧等待位置更新接受响应默认约8秒重发或放弃位置更新T3192MS侧等待后续RR消息数秒释放RR连接T3101BSC侧等待立即指配确认110秒释放SDCCH信道T3103BSC侧等待切换完成210秒释放原信道T305MSC侧等待移动台确认释放约30秒强制释放呼叫T308MSC侧等待对端确认释放约4秒重发REL或强制复位电路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和SSNGT翻译对不对、子系统号是不是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地址最后才审业务消息。反复几次位置更新、鉴权失败这类问题的排查时间能砍掉一半。希望帮到你。本文还有配套的精品资源点击获取 GSM信令协议栈与核心网元：从七号信令到MAP位置更新分析
简介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消息的流向都能推断出来。网元核心职责关键数据MSC呼叫处理、切换、移动性管理、操作维护、网间互通、计费当前服务小区、话路状态、呼叫记录HLR用户归属数据库跨MSC/VLR的权威数据源IMSI、MSISDN、用户状态、补充业务签约、当前所在VLR地址VLR服务区内的临时位置登记负责TMSI和漫游号管理TMSI、LAI、移动台状态、部分补充业务数据、MSRNAUC生成鉴权三元组/五元组Ki、RAND、Sres、Kc跑A3/A8算法BSC管理一组BTS分配无线资源控制频率和功率小区配置、切换候选列表、信道占用BTS空口收发直接与MS通信载频配置、时隙状态、无线链路测量HLR和VLR的分工可以简单记成HLR永远知道用户“应该在哪”VLR知道用户“现在在哪”。用户漫游到新MSC/VLR区域时新VLR会向HLR要签约数据HLR留下新VLR地址同时通知旧VLR把临时数据清掉。这一来一回就是MAP的Update Location和Cancel Location操作是全网位置更新信令的基本盘。AUC和SIM卡之间的关系是鉴权链路的起点。SIM卡里写死了KiAUC里也存着同一个Ki。AUC生成一个随机数RAND用Ki和RAND跑A3算法得到Sres跑A8算法得到KcSres用来鉴权Kc用来给空口加密。这张卡能不能通过网络认证完全取决于两边的Ki是否一致、算法是否兼容。提示现网里HLR和AUC经常做成同一个物理平台H接口更多是逻辑概念。抓包里看不到独立的H口信令别在H口上浪费时间。2.2 接口协议映射A口走BSSAPD口走MAP接口决定了信令协议的长相。同一个位置更新请求在Um口是RR层的帧到了A口被裹成BSSAP再到D口变成MAP操作内容没变承载方式一直在变。接口连接网元主要协议用途Um口MS ↔ BTSLAPDm RR/MM/CM空口信令最复杂的一段Abis口BTS ↔ BSCLAPD BTSM基站管理、RR透传A口BSC ↔ MSCBSSAPDTAP BSSMAP无线资源控制与移动性消息承载B口MSC ↔ VLR内部接口通常合设无独立信令C口MSC ↔ HLRMAP取路由信息、被叫处理D口VLR ↔ HLRMAP位置更新、取签约数据E口MSC ↔ MSCMAP / TUP / ISUP局间切换、跨局呼叫接续F口MSC ↔ EIRMAP移动设备身份检查G口VLR ↔ VLRMAP漫游用户位置恢复A口是新手最容易看晕的接口。BSC和MSC之间跑的是BSSAP它内部拆成两半DTAP负责把MS的CM、MM消息原样透传给MSCBSSMAP负责BSS自身的资源管理比如Assignment Request分配TCH、Paging寻呼。区分DTAP和BSSMAP看SCCP层的子系统号和消息第一个字节就能判断BSSAP的SSN一般是62消息首字节为0x06或0x07时是DTAP0x00到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这些网元都是SPSP不转接别人的信令只管自己收发。LSTP负责省内转接一般每省设2到4个HSTP负责大区之间的转接每个大区一套。可靠性靠冗余叠出来每个SP至少连两个LSTP每个LSTP至少连两个HSTPHSTP再分A、B两个平面。平时话务按SLS字段做负荷分担一个平面断了另一个平面能把信令全部接住。组网结构直接决定了DPC目的信令点编码和OPC源信令点编码怎么规划很多“消息发不出去”的问题最后都查回到GT翻译表或者DPC路由配置上。3.2 MTP1MTP3传输、链路与路由MTP是消息传递部分分三层对应OSI的下三层。MTP1是物理层跑在2Mbps PCM链路的某个64kbps时隙上MTP2是信令数据链路层负责帧定界、差错检测和重发MTP3是信令网功能层负责路由选择和信令网管理。层职责关键点MTP1物理传输64kbps时隙PCM系统里时隙16常用于信令链路MTP2链路层可靠传输信令单元定界、CRC校验、基本/预防性循环重发MTP3路由与网络管理DPC/OPC/SLS路由标签、信令路由管理、信令链路管理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与MAPA接口和网内接口各管一段BSSAP只在A口出现承载DTAP和BSSMAPMAP在C/D/E/F/G口出现承载所有网元间的业务数据。两者的边界其实就是无线侧和网络侧的边界。MS发起的呼叫管理、移动性管理消息走到A口时是DTAPBSC自己做的资源分配、寻呼、切换控制是BSSMAPMSC和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/H1H0决定消息组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先算电路对比项TUPISUP服务对象传统PSTN语音呼叫ISDN及任意承载业务承载能力单一语音多承载支持高速数据主叫号码传递支持有限字段丰富可靠性高释放原因简单Cause值丰富利于定位问题与MTP关系直接承载于MTP3承载于MTP3可配合SCCP演进状态存量为主逐步退网现网主流分析TUP/ISUP消息时很多人习惯盯着主被叫号码我一般先看CIC电路识别码。CIC是话路识别的钥匙每条中继电路在信令消息里都以CIC编号出现PCM系统号加时隙号通过厂商公式换算成CIC。看到一个呼叫的IAM先确认CIC是不是预期电路再往下看被叫号码能省下大量找错时间。5. 信令流程与定时器排查位置更新、鉴权加密里的5个常见坑前四章讲完网元和协议这一章把网元和协议串起来。GSM信令流程的主角是位置更新、鉴权和呼叫建立而定时器是这些流程的“超时保险丝”。我带项目时踩过不少坑整理下来其实就集中在数据和定时器两处。5.1 位置更新与起呼流程先走哪条消息再走哪条消息位置更新的完整链路是这样的MS在Um口发起信道请求BTS上报给BSCBSC分配SDCCH并下发立即指配MS在SDCCH上建LAPDm链路发出Location Updating Request这条消息以DTAP形式从A口透传到MSCMSC交给VLR处理VLR发现MS是新来的就向HLR发Update LocationHLR记录新的VLR地址下发Insert Subscriber Data把签约数据灌给VLR再通知旧VLR做Cancel Location最后VLR给MS分配TMSIMSC回Location Updating Accept。起呼流程则是在位置更新的基础上加一段MS发CM Service Request网络侧先做鉴权再做加密通过后BSC分配TCH然后Alerting、Connect、Connect Acknowledge完成呼叫建立。鉴权回路是AUC生成RANDVLR下发鉴权请求MS用Ki和RAND算出Sres回传VLR比对一致才放行加密则用A8算出的Kc配合A5算法在BTS和MS之间加扰。建议把这两条流程按消息顺序背下来看抓包时一条条对照能立刻定位是哪一步断了。5.2 定时器参数T3212、T3210、T3192这些数字决定什么定时器所在网元作用常见配置超时行为T3212网络侧广播MS执行周期性位置更新间隔60240分钟步长6分钟最大25.5小时MS重新发起位置更新T3210MS侧等待位置更新接受响应默认约8秒重发或放弃位置更新T3192MS侧等待后续RR消息数秒释放RR连接T3101BSC侧等待立即指配确认110秒释放SDCCH信道T3103BSC侧等待切换完成210秒释放原信道T305MSC侧等待移动台确认释放约30秒强制释放呼叫T308MSC侧等待对端确认释放约4秒重发REL或强制复位电路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和SSNGT翻译对不对、子系统号是不是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地址最后才审业务消息。反复几次位置更新、鉴权失败这类问题的排查时间能砍掉一半。希望帮到你。本文还有配套的精品资源点击获取