简介专题资料由上海大唐移动通信设备有限公司出品是一份GSM信令流程的系统性讲义目标读者为移动通信网络优化工程师、通信专业学生以及从事BSS系统维护的技术人员。资料从BSS系统信令应用入手先后介绍七号信令、LAPD、LAPDm三类信令的传送区间解释基于OSI低三层的信令模型并重点讲解RR、MM、CM子层及BSSMAP、DTAP等协议的作用。随后逐一展开移动主叫、移动被叫、位置更新、小区内切换、小区间切换、外部切换和定向重试等关键呼叫流程可用于网络故障排查、切换参数优化及信令链路分析。包体为单份doc文档共1个文件大小约768KB结构完整、便于按目录查阅目前已吸引96人学习下载。掌握这些内容有助于深入理解GSM网络运作机制为实际网络优化和运维排障提供参考。1. 把GSM信令流程讲透的讲义为什么放到现在还值得逐条复盘GSM信令流程这个名词乍一听像是二十年前的教科书内容但在2G/4G/5G并存的现网里每一次VoLTE回落、每一张物联网卡上线最终都可能排到GSM信令这条底网上。专门讲信令流程的讲义类资料是现网排查里最好用的底图手机上电后为什么先做位置更新拨号后网络为什么先建SDCCH切换失败该看哪条消息这些答案不会因为网络升级而过时。这份讲义型材料的切入点是把Um、Abis、A接口的时序拆成一张张可对照的流程图适合做日常优化的工程师、核心网维护人员和刚开始读3GPP吃力的研发新人。读完它你得到的核心能力是拿到一串log后能把GSM信令从消息名到责任网元完整对起来。2. 拆GSM信令流程之前四条链路、三层协议与一组定时器GSM信令讲义里最容易被跳过的部分恰恰是最值钱的部分协议栈。信令流程图看得再熟只要抓包位置切换一下同一个消息在你面前的表现就完全不一样。2.1 四条信令链路的分工Um管用户Abis管基站A管核心网L管数据库先记住一个原则GSM信令不是一条链而是四段。以手机主叫为例信令依次穿过Um、Abis、A最后在核心网侧还牵扯到L接口上的MAP信令。Um接口是手机到基站的空中接口。物理层走无线数据链路层是LAPDm网络层同时承载RR、MM、CC三类消息。这里出现的是Channel Request、Immediate Assignment、Location Update Request这类最原始的消息。Abis接口是基站到BSC的接口。BTS本身基本上不做呼叫控制它把Um口收到的LAPDm帧转成BSC认识的LAPD帧RR消息在Abis上几乎透明传输。大多数厂家的Abis实现不开放所以日常分析多在看Um或A口。A接口是BSC到MSC的接口。这里用BSSAP协议跑在SCCP之上BSSAP又分成两个子集DTAP传递手机侧的三层信令BSSMAP传递BSC和MSC之间的网络管理信令。判断信令流程卡在无线侧还是核心网侧A口log是最关键的切分点。L接口是MSC到HLR的接口。位置更新、取鉴权三元组、注销旧位置全走MAP协议。L接口出问题表现往往是位置更新请求有去无回。抓包位置决定了你能看得见哪一层协议。在Um口抓到的信令与在A口抓到的信令同一个流程消息层的表现完全不一样。看GSM信令流程图之前先确定这张图的抓包位置再谈判读否则很容易把不同接口的消息混在一起。2.2 从RR到MM再到CC一个三层消息从头到尾怎么穿衣服GSM网络层的L3消息可以简单分成三件外套RR、MM、CC。RR负责无线资源管理。寻呼、立即指配、信道释放、切换命令这些都是RR的活。手机能打电话的前提是先有无线信道RR就是干这个的。MM负责移动性管理。位置更新、鉴权、TMSI重分配机身不动但你身份信息在核心网里的登记状态由MM管。CC负责呼叫控制。Setup、Alerting、Connect、Disconnect这些和通话业务直接相关的消息属于CC。在实际信令里这三层消息是混杂出现的寻呼请求是RR层收到后手机回寻呼响应网络侧把它当作一条MM层消息往MSC推而A接口的BSSMAP消息可能同时携带RR和MM信息。这里最容易犯的错是把Um口看到的RR消息当成网络决策的结果去理解。一次典型的位置更新Um口先出RR层的Immediate Assignment再出MM层的Location Update Request而到了A口BSC把这些三层消息打包成COMPLETE L3 INFO发送给MSC。如果没有这层封装意识你会以为BSC在直接替用户做位置更新其实它只是中转。区分DTAP和BSSMAP也有同样的作用。DTAP消息在A接口上保持MS到MSC的透明传输MSC直接看到手机发来的内容BSSMAP则是BSC和MSC之间的管理消息比如Assignment Request、Handover Required手机根本不知道它们的存在。抓A口log时先用SCCP层的消息类型把DTAP和BSSMAP分开再逐层往T33往下译码顺序就不会乱。2.3 开始看流程前先认准这几个定时器信令流程的失败往往不是消息丢失而是某个定时器超时。GSM讲义里反复出现的几个定时器建议先背住。定时器所在流程典型作用常见失败表现T3212周期位置更新以6分钟为单位下发在系统消息里控制手机每隔多久主动上报一次位置值设置过大网络侧对用户位置感知滞后设置过小SDCCH被位置更新消息占满T3101寻呼和呼叫建立BSC在寻呼流程中等待手机寻呼响应或后续接入的定时器寻呼响应没回来BSC定时器超时后主动释放呼叫T3103切换流程切换执行阶段等待无线侧完成切换的定时器超时判定切换失败Handover Complete迟迟不上报触发切换失败流程T309/T310释放流程呼叫释放阶段等待无线链路释放确认释放消息不回信道一直挂在TCH上造成隐性拥塞T3212是所有人都会碰到的定时器。它在系统消息里广播给手机数值2大概等于12分钟一次位置更新数值12等于72分钟一次。工程上常用的调整思路是漫游用户多、跨LA频繁的场景T3212适当放大以减少SDCCH的信令压力相反需要精确定位的场景T3212要收小。T3101超时更常见于被叫流程核心网寻呼下发后手机在弱覆盖区一直收不到寻呼消息BSC等到超时只能释放这次呼叫。你在log里看到Paging Request之后长时间没有Paging Response随后出现BSSMAP CLEAR COMMAND基本就是T3101作祟。看信令流程图时记住一句话流程图上的一条线代表一条消息但真正让流程失败的往往是那条没有画出来的线——定时器等不到回应的那段空白。3. 三大流程的手动复盘位置更新、呼叫建立、切换的判读顺序讲义里最常见的三张流程图为位置更新、主叫、切换这三张图吃透了GSM信令的八成功底就在手上。3.1 位置更新判读三问为什么发起、数据对不对、核心网做了什么判读位置更新信令不要一上来就按消息名从头读到尾先问三个问题。第一为什么发起位置更新GSM的位置更新有三种触发开机搜网后的IMSI Attach跨位置区时的LAI变更以及T3212周期更新时间到的周期更新。看信令时可以向上追溯到触发源开机流程的log往往能看见MS前面还有System Information和小区重选跨LA变更的流程中MS通常先报告当前LAI再发出Location Update Request周期更新最规整消息里直接带Periodic。第二信令数据对不对这条流程的正确顺序是手机在RACH上发起Channel RequestBTS上报Channel Required。BSC分配SDCCH下发Immediate Assignment手机跳到SDCCH上。手机在SDCCH上发出Location Update Request携带TMSI或IMSI、旧LAI、更新类型。BSC把完整L3消息封装成COMPLETE L3 INFO上传MSC。MSC处理鉴权、位置登记给手机返回Location Update Accept手机回Location Update Complete。大部分失败发生在第3步和第5步之间。第3步失败看上行有没有干扰或SDCCH拥塞第5步失败核心网嫌疑大重点查HLR里有没有用户数据、MSC和HLR的MAP链路通不通。第三核心网做了什么位置更新信令里手机侧能看到的消息只占一半。A口log能看到鉴权请求、加密模式命令再往后就要看MSC和HLR之间的MAP流程。MAP_UPDATE_LOCATION发出后HLR会向旧的VLR发Cancel Location这一步能让全网位置信息保持一致。你要是只在Um口抓包永远看不到MSC做了什么这也是为什么位置更新问题一定要A口和Um口对照看。3.2 呼叫建立从CM Service Request到Alerting每次“指配”都要盯呼叫建立流程是最完整的信令链路值得按步骤过一遍手机在SDCCH上发出CM Service RequestMM层连接建立MSC返回CM Service Accept。网络发起鉴权请求手机回鉴权响应必要时做加密模式命令。主叫手机发Setup消息携带被叫号码MSC经ISUP把呼叫接到被叫侧。MSC给主叫侧BSC下发Assignment Request要求分配TCH业务信道。BSC在Um口下发指配命令手机跳到TCH上回指配完成BSC向MSC报Assignment Complete。被叫侧振铃MSC向主叫手机发Alerting主叫听到回铃音。被叫接听MSC发Connect手机回Connect Acknowledge通话建立。新手找问题最喜欢的切入点是第7步之后但实践中90%的呼叫建立问题卡在第4步和第5步Assignment Request发出后迟迟等不到Assignment Complete最后BSC报分配失败。Assignment Request里最核心的参数是信道类型和语音版本。语音版本协商不上BSC可能找不到匹配的编解码器只能在Um口下发信道释放。A口看到Assignment Request里的电路标识码和后续Assignment Complete里的时隙不一致也要警惕BSC内部资源分配错位。呼叫建立阶段还有一类慢问题每步都成功但总时延偏长。这种排查要从信令图里找时间戳最宽的一段——往往是鉴权流程太久或者核心网被叫分析过程太慢。建议复盘呼叫建立时把每次Assignment消息出现的时间点单独列一列。正常流程里从Assignment Request到Assignment Complete的时延在几百毫秒级超过一秒就要怀疑TCH资源分配异常。3.3 切换判读先分清BSC内切换、BSC间切换、MSC间切换切换失败排查里最大的混淆点是把所有切换当成同一套信令流程来读。至少分三种情况。BSC内部切换是BSC自己说了算的手机上报测量报告BSC判断目标邻区更合适直接通过Um口给手机下发Handover Command手机切到目标小区后回Handover Complete。A口不会出现明显的切换请求整个流程只在无线侧闭环。BSC间切换就多了一套BSSMAP消息源BSC上报Handover Required给MSCMSC向目标BSC发Handover Request目标BSC分配资源后回Handover Request Acknowledge源BSC再给手机下发Handover Command。手机切过去后目标BSC上报Handover CompleteMSC再让源BSC释放资源。MSC间切换则要经过核心网MAP流程L接口上的MAP Prepare Handover、MAP Send Handover Report都会出现流程更重时延也更长。判读切换信令时先问自己三个问题这是哪一级的切换切向小区的配置是否在邻区关系里Handover Command有没有下发最常见的失败形态是Handover Required消息反复出现MSC也发了Handover Request但目标BSC始终不回Handover Request Acknowledge。这种大概率是目标小区拥塞或者目标BSC上邻区配置缺失。还有一种是手机收到Handover Command后切不过去持续在信道上报失败——问题往往在目标小区的同步参数、上行干扰带或者频点配置上。三张流程图侧重点不同位置更新看“网络认不认你”呼叫建立看“资源给没给够”切换看“邻区关系对不对”。把这三个角度分清楚GSM信令流程的判读思路就成型了。4. 避坑GSM信令流程复盘四个最容易翻车的细节信令流程本身不难难的是错误判读。下面几条踩坑记录来自大量日常话单分析每条都是真实出现过、且容易被反复踩中的坑。4.1 把Um口L3信令当成A口全局信令DTAP与BSSMAP责任错位现象手里只有一份手机侧抓包却断言是MSC没下发Assignment Request搞得核心网和无线侧互相甩锅。原因Um口只看得见手机和基站之间的RR、MM、CC消息。BSC到MSC之间的BSSMAP管理消息比如Assignment Request、Handover Required根本不会出现在Um口log里。手机侧看不到的流程段不能直接推断成“核心网没发”。解决先确认log的采集点。Um口log分析无线侧决策A口log分析核心网交互两套log时间对齐后再下结论。没有A口log时不要在信令图里补画BSSMAP消息只描述能观察到的部分。4.2 只记得成功主线失败消息、释放原因和拒绝码全没接住现象按教科书上的成功流程逐条比对一张失败信令图感觉每条消息都有却没有发现异常点。原因讲义里画的大多是成功路径而现网失败流程走得是另一套分支Location Update Reject、CM Service Reject、Assignment Failure、Handover Failure、Disconnect这些分支消息各带原因值。只对成功路径等于拿着地图找一条不存在的死路。解决复盘时单独开一排失败分支列表。每个流程先把拒绝消息、释放原因值查出来。比如CM Service Reject里的原因是“呼叫控制拒绝”可以顺着手机状态往前追看是加密模式未完成还是网络侧禁止接入。原因值具体到数字逐条对照3GPP 24.008里的原因分类别靠猜。4.3 把三种切换揉成一种“切换”拿到Handover Failure后不知该看哪一段现象切换失败log里同时出现了Handover Required和Handover Command有人就以为这是完整的BSC间切换去查MSC配置结果问题出在目标小区的频点同频干扰上。原因不同切换级别的消息链不同。BSC内部切换根本不产生Handover RequiredBSC间切换才需要MSC中转MSC间切换还要叠加MAP流程。消息一混杂排查方向必然跑偏。解决先用消息链给切换分级。看到Handover Required出现在A口这是BSC间切换重点查MSC在两BSC之间的电路配置和目标小区资源Handover Command下发后迟迟收不到Handover Complete重点查无线侧目标小区有没有干扰、UpPCH接入窗口对不对。4.4 T3212被当成“降SDCCH负荷的万能药”整个寻呼节奏跟着乱现象小区SDCCH拥塞率飙升有人立刻把T3212调大结果拥塞没好反而出现了新的寻呼无响应问题。原因T3212管的是手机主动周期位置更新的频率不是寻呼响应的速度。SDCCH拥塞要区分是位置更新占用的还是呼叫建立占用的。把周期拉长确实能减少位置更新消息但会让网络侧对手机位置的感知变模糊被叫寻呼范围扩大PCH负荷反而上来了。解决先看SDCCH占用原因分布。如果统计显示位置更新占比确实高再动T3212且每次按一到两档调整如果是呼叫建立导致的拥塞改的是寻呼信道配置和SDCCH数量不是T3212。关键提示T3212设置为0表示不发起周期位置更新这种配置会导致网络侧失去对终端的周期了解IMSI寻呼比例上升高危场景下不要轻易尝试。5. 从讲义到判断力建立一套自己的信令判读模板读完信令讲义只是入门真正能靠它干活需要把静态流程转成自己的判读模板。5.1 给每次复盘做一张四层对照表我在处理GSM信令问题时习惯不以消息流程为单位记笔记而是做一张四层对照表时间、接口、消息、责任网元。每次遇到异常不计其数的log先把这张表填起来再谈诊断。时间接口关键消息责任网元00:00:00.000UmChannel RequestMS00:00:00.120UmImmediate AssignmentBSC00:00:00.180UmLocation Update RequestMS00:00:00.240ACOMPLETE L3 INFOBSC00:00:01.200AAuthentication RequestMSC这张表的本质是把时序还原成“谁在等谁”的逻辑链。遇到问题时先看表里哪一行的时间间隔异常放大再看两行之间的网元有没有能力做出响应。做了两三次之后你会形成自己的判读习惯比如先看SDCCH分配、再看核心网确认、最后看TCH指配。5.2 用一次小区级故障把验证顺序固化下来我常用的验证顺序也很简单先找失败消息段反推失败原因再用其他接口的log核实。比如某小区TCH分配成功率低我会先按这个顺序走一遍看A口Assignment Request数量是否正常看Um口Assignment Command有没有下发看MS有没有上报Assignment Failure最后才去查频率规划。这套顺序的背后逻辑是每次只看一段链路把责任网元框死。信令判读最忌讳一次看好几个接口八爪鱼式地抓消息最后哪条都没看全。从2021年到2022年这张GSM信令流程讲义我反复读过三遍每一遍都盯着解不同的流程。真正让我把GSM信令这张图纸印在脑子里的不是背下消息名而是每次看完一条失败log都去本子里找一次“谁在等谁”。这个习惯把信令从黑匣子变成了地图也希望这个方法能帮到你。本文还有配套的精品资源点击获取