尧图网页设计 
简介这是一份上海大唐移动通信设备有限公司出品的GSM信令流程专题讲义内容覆盖2021-2022年通信网络优化岗位的核心知识点适合移动通信工程师、网络优化人员及通信专业学生研读。资料从BSS系统信令应用讲起区分七号信令、LAPD、LAPDm三类链路并基于OSI低三层构建信令模型分别说明物理层电气特性、链路层帧传递与网络层寻址路由功能同时对RR、MM、CM等子层职责作了归纳。后续还详细梳理移动主叫/被叫、位置更新、小区内外切换、外部切换、定向重试等关键流程配有分章节目录便于按需查阅。压缩包共1个doc文件约768KB文件结构紧凑便于离线阅读与打印。该资源已有96人学习浏览是理解GSM网络运作机制和开展故障排查、网络优化工作的实用参考资料。1. GSM 信令流程的底稿为什么一份 2000 年的大唐讲义至今还能定位问题做 GSM 网络优化的人早晚会遇到一个尴尬时刻指标上看到主叫失败率高可路测无线环境正常交换侧也说没问题。这时候能把问题钉死的只有信令。这份上海大唐移动 2000 年 11 月的《GSM 信令流程讲义》讲的是从 Um 口到 A 口的整套 BSS 信令拆解——移动主叫、被叫、位置更新、小区内切换、小区间切换、外部切换、定向重试每个流程的消息顺序都画成了可对照的时间线。资料作为 2021-2022 年专题整理底稿是二十多年前的但 GSM 信令流程这二十多年骨架没怎么变。适合刚入行的网优新人背流程、做 BSC 参数优化的工程师查消息序列以及要写信令分析报告的一线人员。2. BSS 信令体系NO.7、LAPD、LAPDm 与 BSSAP 的各管一段拿到这份讲义第一个建议是先别看流程图先把协议栈啃完。因为后面所有流程都是用消息名讲的消息名认不全流程看了也白看。BSS 里的信令按传输位置分三类MSC 与 BSC 之间走七号信令NO.7BSC 与 BTS 之间走 LAPDBTS 与 MS 之间走 LAPDm。这三段接口的物理形态完全不同信令封装也不一样所以定位问题时第一步永远是“这条消息该出现在哪一段”而不是拿着消息名到处找。2.1 为什么 GSM 信令要分三段走Um、Abis、A 口各管一段GSM 的 BSS 系统从 MS 到 MSC 要经过三段接口信令在每一段上都“换一次皮”。第一段是 Um 口MS 和 BTS 之间的空中接口物理层就是无线载波链路层跑 LAPDm网络层直接承载 RR、MM、CC 消息。第二段是 Abis 口BTS 和 BSC 之间物理层通常是 E1链路层跑 LAPD网络层消息有个容易忽略的处理RR 层的消息并不是裸传的而是封装在 BTSM 的数据请求消息里。第三段是 A 口BSC 和 MSC 之间底层走 MTP上层是 SCCP最上层是 BSSAP而 BSSAP 又拆成 BSSMAP 和 DTAP 两半。接口物理层链路层网络层承载UmMS-BTS无线载波LAPDmRR / MM / CCAbisBTS-BSCE12048 kbit/sLAPDRR经 BTSM 封装ABSC-MSCMTP 1MTP 2/3 SCCPBSSAPBSSMAP DTAP这套映射关系是信令分析的地基。新手最容易翻车的地方在 Abis 口抓包软件里看到的不是你熟悉的 RR 消息正文而是 BTSM 的 Data Request、Data Indication。很多人在 Abis 上找不到“立即指配”就开始怀疑抓包没抓全其实立即指配被包在 BTSM 的 Immediate Assignment Command 里得先解开这层封装才能看到 RR 层字段。讲义正文里写 Abis 物理层是“2048bps”这应该是转录错误实际就是 E1 的 2048 kbit/s。DTAP 和 BSSMAP 的分工也要先刻在脑子里。BSSMAP 用于 MSC 与 BSC 之间的资源管理比如寻呼、指配、切换、复位这类消息 BSC 收到后会自己消化改格式在 Abis 口不一定能看到。DTAP 负责 MSC 与 MS 之间的 MM、CM 层消息透明传递BSC 不做解析只管搬运所以在 A 口抓到的一条 Setup 或 Location Updating Request内容与 MS 发出来的一模一样。2.2 低三层与网络层的三个子层RR、MM、CM 到底归谁管讲义按 OSI 低三层把 BSS 信令模型拆成物理层、链路层、网络层这个分层不是摆样子每一层对应一种排查手段。物理层负责物理数据单元的无错传送定义了传输路径上的电气特性对应到现网就是载频、时隙、E1 链路的状态。链路层负责帧传递、无错传送和连接实体的建立维持LAPD 的 SABME、UA、DISC 都在这一层干活。网络层负责端到端连接、寻址和路由选择GSM 里被进一步拆成 RR、MM、CM 三个子层。网络层子层主要职责实现位置现网对应事件RR无线资源建立、维持、释放物理连接主要在 BSC部分在 BTS立即指配、切换、加密、测量报告MM移动管理注册、鉴权、位置更新、TMSI 重分配在 MSC / VLR位置更新、鉴权、IMSI 分离CM连接管理呼叫控制、补充业务、短消息在 MS 与 MSC呼叫建立、释放、DTMFRR 层是与其他层的“基本接口”它的功能分布在 BSC 和 BTS 两侧。MM 层的功能在 MSC 一侧实现最容易被误认为是 BSC 的问题。CM 层是最高层子层里 CC 管呼叫的建立、维持和清除SS 管补充业务SMS 管短消息。判断一条信令异常属于哪个层可以先看消息落在哪个子层RR 层消息异常重点查 BSC 参数和无线资源MM 层异常重点查鉴权、位置更新相关的 MSC / VLR 配置和 SIM 卡状态CC 层异常重点查呼叫路由和号码分析。2.3 消息清单当索引用RR、MM、CC、BTSM、BSSMAP 的代表消息讲义里给了五个消息列表很多人翻过去就完了其实这是最实用的索引。我把每层挑几条代表消息对应到现网里最常见的场景排查时按这张表反查消息名比临时翻协议快得多。所属层代表消息对应现网事件RR立即指配Immediate Assignment、寻呼响应、切换命令、加密模式命令、测量报告、系统消息 1-6接入失败、寻呼无响应、切换失败、加密失败、覆盖与干扰判断MM位置更新请求 / 接受 / 拒绝、鉴权请求 / 响应 / 拒绝、TMSI 重分配、CM 业务请求位置更新失败、鉴权失败、TMSI 乱分配、主叫被叫建立慢CCSetup、Call Proceeding、Alerting、Connect、Disconnect、Release呼叫接续、振铃与接通、挂断与释放异常BTSMData Request、Data Indication、信道激活、RF 信道释放、测量结果、SACCH 填充Abis 口封装、信道激活失败、功率控制异常BSSMAP指配请求 / 完成 / 失败、寻呼、切换请求 / 命令 / 完成、清除命令、复位、阻塞寻呼、TCH 指配失败、切换执行失败、BSC 复位使用这份清单的方法是按层反查主叫拨号后没有回铃先查 CC 层有没有 Setup 和 Alerting位置更新被拒绝到 MM 层找 Location Update Reject并看 reject cause 是 2、3 还是 4TCH 指配不起去 BSSMAP 查 Assignment Request 之后有没有 Assignment Failurefailure cause 指向拥塞还是无线接口失败。讲义把这些消息名整理成表省去了逐条翻规范确认缩写含义的功夫。3. 三大核心流程主叫、被叫、位置更新的消息序列对照把协议栈的骨架立起来之后再进流程就顺了。讲义的核心章节是移动主叫、移动被叫、位置更新、切换。主叫被叫是日常投诉最多的场景位置更新是影响寻呼成功率的关键先把这三个流程的消息序列背熟再做切换。3.1 移动主叫从 Channel Request 到 Connect ACK移动主叫的完整链路由接入、鉴权加密、TCH 指配、接通与释放四段组成每段都有独立的失败点。第一步是随机接入MS 在 RACH 上发 Channel RequestBTS 收到后通过 Abis 口向 BSC 上报 Channel RequiredBSC 分配 SDCCH 并下发激活命令BTS 在 AGCH 上回 Immediate AssignmentMS 转到 SDCCH 并建立 LAPDm 连接。这个阶段失败要么是 Channel Request 根本没到 BTS要么是 SDCCH 拥塞导致 Immediate Assignment Reject。之后 MS 在 SDCCH 上发 CM Service RequestBSC 打包透传给 MSC。MSC 回鉴权请求MS 用 SIM 卡里的 Ki 和 A3/A8 算法算 SRES 回响应MSC 比对通过后下发加密模式命令。这一段最值得关注的是鉴权请求之后有没有响应以及响应里的 SRES 是否匹配。如果鉴权响应超时或拒绝常见原因是 SIM 卡数据与 HLR/VLR 不一致而不是无线问题。现在许多网络能用 TMSI 和加密参数跳过部分鉴权看到流程里没有鉴权请求不必惊讶。加密完成后是呼叫建立的核心段MS 发 Setup 携带被叫号码MSC 回 Call Proceeding同时向 BSC 下发 Assignment Request 分配 TCH。BSC 在空口发 Assignment CommandMS 切到 TCH 后回 Assignment Complete。这一步是整个主叫流程里最值得盯的一段TCH 分配失败往往表现为 Assignment Failure原因是目标载频拥塞或干扰。之后 MSC 向 MS 发 Alerting被叫振铃、Connect、MS 回 Connect ACK通话建立挂断时按 Disconnect → Release → Release Complete 的顺序释放。主叫阶段关键消息失败观察点随机接入Channel Request → Immediate AssignmentRACH 接入失败、SDCCH 拥塞鉴权加密Authentication Request / ResponseCipher Mode Command鉴权拒绝、加密失败TCH 指配Assignment Request → Assignment Command → Assignment CompleteTCH 拥塞、指配失败接通释放Setup → Alerting → Connect → Disconnect → Release被叫侧无响应、释放异常主叫流程还有一个隐形的第二步分配SDCCH 先分配一次确认身份后再分配 TCH中间如果不停做加密和鉴权SDCCH 占用时间会拖长。优化时可以看 CM Service Request 到 Assignment Command 之间用了多少条 DTAP 消息消息越多呼叫建立时延越大。3.2 移动被叫寻呼怎么落地比主叫多了哪一段被叫流程和主叫最大的差别是开头MSC 通过 BSSMAP 下发 PagingBSC 把这个寻呼命令分散到 MS 所在位置区的所有小区BTS 在 PCH 上广播寻呼消息。MS 收到寻呼后在 RACH 上发 Paging Response后续鉴权、加密、TCH 指配基本与主叫相同。但 Setup 的方向反了——被叫侧是从 MSC 到 MS而且 MS 回的是 Call Confirmed 而不是 Call ProceedingMSC 要等被叫用户应答所以 Alerting 由被叫侧发起Connect 也由被叫侧发起。被叫流程里最多人忽略的是“寻呼响应”这个点的定位价值。Paging 发出去之后如果 Paging Response 在超时时间内没回来问题在无线侧PCH 拥塞、MS 不在服务区或位置区数据错误MS 实际所在的 LA 与 VLR 里登记的 LA 不一致如果 Paging Response 回来了但 Setup 之后没有 Alerting问题在被叫用户端或 MSC 到被叫侧的局数据。判断被叫问题先确认有没有 Paging Response再往下查这一条能过滤掉一半的无用排查。被叫流程和主叫流程在业务信道上完全一致差别只在寻呼这一段这也解释了为什么 GSM 优化里寻呼成功率和被叫接通率强相关。位置区不合理导致寻呼消息在多个小区重复下发整体寻呼负荷上去后PCH 拥塞会直接拖累被叫接通率。3.3 位置更新TMSI 与 IMSI 的切换、鉴权与 LA Accept位置更新流程在故障定位里常被忽视其实很多主叫被叫异常的根因都在位置更新。MS 从旧位置区进入新位置区时会在 RACH 上发 Location Updating Request消息里携带旧 LAI 和 TMSI 或 IMSI。新 MSC/VLR 收到后如果判断需要鉴权就下发鉴权请求通过后做位置更新登记再回 Location Update Accept。注意这个流程中没有 TCH 指配全程在 SDCCH 上完成所以对 SDCCH 资源的消耗很明显。位置更新的关键看三个点。第一消息里用的是 TMSI 还是 IMSI用户第一次开机入网或 VLR 里没有该 TMSI 记录时会用 IMSI正常漫游切换时用 TMSI减少 IMSI 在空中接口暴露。第二Location Update Accept 之后通常紧跟 TMSI Reallocation Command 和 Complete新 TMSI 由 VLR 分配MS 确认后下一次更新就用新 TMSI。第三周期性位置更新由 T3212 定时器控制到时间后 MS 即使不跨区也会做周期性更新T3212 设置过小会加重 SDCCH 负荷过大会导致网络侧认为 MS 失联。位置更新步骤消息方向观察点发起MS → BTS / BSC → MSCLocation Updating Request携带旧 LAI、TMSI 或 IMSI鉴权MSC → MSAuthentication RequestMS → MSCAuthentication ResponseSRES 不匹配、鉴权拒绝接受MSC → MSLocation Update AcceptLA 边界、VLR 数据是否一致TMSI 重分配MSC → MSTMSI Reallocation Command / CompleteTMSI 分配失败导致反复发起更新位置更新被拒绝是投诉里常见的一种情况。Location Update Reject 一般带 cause 值3 表示 illegal MS6 表示 illegal ME2 表示位置区不允许。看到 cause 2多数是 MSC/VLR 的 LA 白名单没配好cause 3 或 6 则要查 SIM 卡的 IMSI 和设备的 IMEI 在黑名单里的状态。这个地方最容易踩的坑是直接下结论说“用户卡坏了”实际 VLR 侧把用户状态置成了 detached清一下用户数据往往就恢复了。4. 四类切换差异小区内、小区间、外部切换与定向重试的判定依据讲义把切换分成小区内、小区间、外部切换、定向重试四类这四类的触发机制和执行路径完全不同信令特征也不一样。判断切换问题前先认清楚是哪一类切换再去抓对应接口的消息。4.1 小区内切换为什么同站还要切信道小区内切换发生在同一个 BTS 内甚至同一个载频的不同时隙之间。触发原因是质量差或者干扰而不是信号弱——如果 MS 还在原小区内但某条信道的 BER 持续恶化BSC 会在同一小区内找一条空闲信道切过去。信令特征是在 Abis 口上能看到信道激活指向的是同一载频的另一个时隙而 BTS 侧通过测量结果和 MS 功率控制辅助判断。4.2 小区间切换从 Handover Required 到 Handover Complete小区间切换按执行主体可以分为 BSC 内和 BSC 间。BSC 内切换由测量报告触发BSC 自己就能决策信令上能看到 BTS 上报的测量结果触发 BSC 下发切换命令。BSC 间切换会出现在 A 口BSC 判断需要切换后向 MSC 发 Handover Required携带目标小区标识MSC 把 Handover Request 发给目标 BSC目标 BSC 激活目标信道后回 Handover Request ACK源 BSC 通过无线链路下发 Handover CommandMS 切到目标小区后目标 BTS 检测到接入上报 Handover Detect最终由目标侧完成 Handover Complete。注意这个流程里 Handover Complete 的发送方是目标侧而不是源侧切换完成后源信道要等 Clear Command 来释放。4.3 外部切换与定向重试跨 MSC 的消息走向差异外部切换是跨 MSC 的场景。源 MSC 收到 Handover Required 后通过 MAP/E 接口向目标 MSC 发起 Prepare Handover目标 MSC 返回 Handover Request ACK之后由源 MSC 通过 BSSMAP 下发 Handover Command。跨 MSC 切换的失败点通常分两段前半段在 MAP 层后半段在 BSSMAP 层。A 口信令里看 BSSMAP 的 Handover Required 与 Handover Request 是否成对出现不成对就说明 MSC 之间的协商没通。定向重试则和前两类完全不同。它不是切换而是呼叫建立阶段的一种资源挽救手段MS 在原小区请求 TCH但该小区 TCH 全忙BSC 不直接发 Assignment Failure而是通过立即指配或重定向消息把 MS 引到相邻小区的空闲 TCH 上。信令特征是在 Assignment Request 之后没有 Assignment Command而是出现了 Immediate Assignment 指向另一个小区。定向重试的参数与目标小区的选择策略强相关如果参数配置激进会导致话务被大量疏导到邻小区形成新的拥塞点。下表把四类切换的信令特征做个对照排查时先对号入座再下手。类型触发场景关键信令特征主要观察接口小区内切换同小区内质量差、干扰信道激活指向同一载频其他时隙Abis小区间切换BSC 内邻区信号更好BSC 直接下发切换命令Abis小区间切换BSC 间跨 BSCHandover Required → Handover RequestA外部切换跨 MSCMAP Prepare Handover BSSMAPA / MAP定向重试TCH 全忙Assignment 后出现指向邻小区的 Immediate AssignmentAbis / Um5. 信令分析避坑指南五个我踩过的“假结论”现场信令分析有一个尴尬的属性消息摆在那里但解读方式不同结论差很远。以下五条都是我实际遇到过的误判每一条都值得记下来。5.1 只看网络层消息不看链路层重传把网络层失败误判为无线差现象某小区 TCH 指配失败率持续偏高无线环境测试正常网络层看到 Assignment Failurecause 为无线接口失败。原因Abis 链路的 E1 存在滑码或误码LAPD 层不停重传网络层消息到达时间超时最终报无线接口失败。解决抓 Abis 口数据数 LAPD 层的 I 帧重传次数和帧校验错误确认链路质量问题后更换 E1 通道或检查传输设备。从那以后我看到“无线接口失败”这个 cause 不再第一时间怀疑空口而是先看链路层有没有重传。5.2 主叫失败全甩给空口没查被叫侧寻呼现象主叫测试中多次未接通测试软件显示主叫侧已发出 Setup但一直没有 Alerting现场工程师判断是空口覆盖问题。原因被叫侧寻呼响应没回来实际上是位置区更新失败导致 VLR 里被叫位置信息错误。解决切换到被叫侧抓信令确认 Paging 下发后是否有 Paging Response没有的话查被叫所在位置区与 VLR 登记是否一致。主叫呼叫建立失败先分清是主叫侧消息断了还是被叫侧没反应别让主叫侧测试数据替你背锅。5.3 位置更新没鉴权就断定异常现象某用户频繁主叫失败信令里看到位置更新流程直接跳过了鉴权工程师据此认为网络侧鉴权参数配置错误。原因网络侧允许基于 TMSI 和加密模式的免鉴权位置更新MS 的 TMSI 有效时不一定每次都触发完整鉴权。解决位置更新失败与否以 Location Update Accept 或 Reject 为准不要以有没有鉴权请求来判断过程是否正常。免鉴权更新不是故障是网络参数策略看到一个流程里没有鉴权就报警属于对流程理解不到位。5.4 把 Handover Complete 当作切换已经成功现象切换成功率指标很高但掉话率也高工程师想不通“切都切成功了怎么还掉话”。原因Handover Complete 只代表 MS 在目标小区完成了接入源侧信道要等 Clear Command 才正式释放如果源信道未及时释放且 MS 在目标小区质量不稳定会形成瞬间的双连接状态最终导致掉话。解决看完整切换链路确认 Handover Complete 之后有 Clear Command 释放源侧资源再下“切换成功”的结论。信令分析看的是整条链路的闭环一个中间消息的成功不代表流程成功。5.5 用 2000 年流程硬套现代网络现象按照讲义里的完整流程去抓包发现某些消息在 Abis 口根本不存在怀疑抓包工具配置不对。原因现代 BSC 把部分 RR 功能下沉到 BTS测量报告和功率控制等消息在 BTS 侧直接处理Abis 口不再承载所有 RR 消息。解决以实际抓包的接口为准把讲义当作流程模板而不是抓包清单Abis 口看不到某条消息不代表流程没发生可能是封装方式变了。这份讲义的价值是流程骨架不是协议实现的完整镜像。6. 把一张失败信令拆出结论三层两段式分析流程看得再多最终要落到“拿一条失败信令怎么分析”。我日常用的是一套三层两段式分析方法先把消息按物理层、链路层、网络层三个层次分层归类再把流程拆成请求链路和响应链路两段来对齐。第一层物理层看 RxLev、RxQual、TA 和传输链路状态。RxLev 低说明覆盖问题RxQual 高说明干扰问题TA 异常超限要怀疑边界小区和直放站。第二层链路层看 LAPD 和 LAPDm 的 SABME、UA、DISC 以及 I 帧重传。链路层出现大量重传即使网络层消息看起来正常也要把问题记在传输上。第三层网络层看 RR、MM、CC 消息的内容和 cause 值。判完这一层基本能区分问题出在接入、鉴权、寻呼还是 TCH 分配阶段。两段式是把同一流程的请求方向和响应方向对齐来看。主叫流程里MS 发 Setup 是请求段MSC 回 Call Proceeding 是响应段MSC 发 Alerting 是请求段但没有对应的最终响应时就要看两段之间断在哪一条消息上。这条断点就是故障的直接位置。用这个办法我遇到过一条主叫失败案例网络层看 Setup 已经发出但 Call Proceeding 一直没到物理层和链路层都正常最后发现是 MSC 对被叫号码的号码分析配置缺失导致 Setup 在 MSC 内部被丢弃。三层把故障层限定两段把故障点定位这套顺序下来基本不存在“不知道从哪查起”的情况。那份讲义里每一种流程都能在信令分析工具里找到对应的实例真正要做到的是拿到一条失败信令时先按三层两段法把消息排队而不是一上来就看直观的失败消息。从那以后我每次拿到一条失败信令不管问题多急都强制先走一遍这个顺序再下结论。希望帮到你。本文还有配套的精品资源点击获取 GSM信令流程实战解析：从协议栈到主被叫与切换
简介这是一份上海大唐移动通信设备有限公司出品的GSM信令流程专题讲义内容覆盖2021-2022年通信网络优化岗位的核心知识点适合移动通信工程师、网络优化人员及通信专业学生研读。资料从BSS系统信令应用讲起区分七号信令、LAPD、LAPDm三类链路并基于OSI低三层构建信令模型分别说明物理层电气特性、链路层帧传递与网络层寻址路由功能同时对RR、MM、CM等子层职责作了归纳。后续还详细梳理移动主叫/被叫、位置更新、小区内外切换、外部切换、定向重试等关键流程配有分章节目录便于按需查阅。压缩包共1个doc文件约768KB文件结构紧凑便于离线阅读与打印。该资源已有96人学习浏览是理解GSM网络运作机制和开展故障排查、网络优化工作的实用参考资料。1. GSM 信令流程的底稿为什么一份 2000 年的大唐讲义至今还能定位问题做 GSM 网络优化的人早晚会遇到一个尴尬时刻指标上看到主叫失败率高可路测无线环境正常交换侧也说没问题。这时候能把问题钉死的只有信令。这份上海大唐移动 2000 年 11 月的《GSM 信令流程讲义》讲的是从 Um 口到 A 口的整套 BSS 信令拆解——移动主叫、被叫、位置更新、小区内切换、小区间切换、外部切换、定向重试每个流程的消息顺序都画成了可对照的时间线。资料作为 2021-2022 年专题整理底稿是二十多年前的但 GSM 信令流程这二十多年骨架没怎么变。适合刚入行的网优新人背流程、做 BSC 参数优化的工程师查消息序列以及要写信令分析报告的一线人员。2. BSS 信令体系NO.7、LAPD、LAPDm 与 BSSAP 的各管一段拿到这份讲义第一个建议是先别看流程图先把协议栈啃完。因为后面所有流程都是用消息名讲的消息名认不全流程看了也白看。BSS 里的信令按传输位置分三类MSC 与 BSC 之间走七号信令NO.7BSC 与 BTS 之间走 LAPDBTS 与 MS 之间走 LAPDm。这三段接口的物理形态完全不同信令封装也不一样所以定位问题时第一步永远是“这条消息该出现在哪一段”而不是拿着消息名到处找。2.1 为什么 GSM 信令要分三段走Um、Abis、A 口各管一段GSM 的 BSS 系统从 MS 到 MSC 要经过三段接口信令在每一段上都“换一次皮”。第一段是 Um 口MS 和 BTS 之间的空中接口物理层就是无线载波链路层跑 LAPDm网络层直接承载 RR、MM、CC 消息。第二段是 Abis 口BTS 和 BSC 之间物理层通常是 E1链路层跑 LAPD网络层消息有个容易忽略的处理RR 层的消息并不是裸传的而是封装在 BTSM 的数据请求消息里。第三段是 A 口BSC 和 MSC 之间底层走 MTP上层是 SCCP最上层是 BSSAP而 BSSAP 又拆成 BSSMAP 和 DTAP 两半。接口物理层链路层网络层承载UmMS-BTS无线载波LAPDmRR / MM / CCAbisBTS-BSCE12048 kbit/sLAPDRR经 BTSM 封装ABSC-MSCMTP 1MTP 2/3 SCCPBSSAPBSSMAP DTAP这套映射关系是信令分析的地基。新手最容易翻车的地方在 Abis 口抓包软件里看到的不是你熟悉的 RR 消息正文而是 BTSM 的 Data Request、Data Indication。很多人在 Abis 上找不到“立即指配”就开始怀疑抓包没抓全其实立即指配被包在 BTSM 的 Immediate Assignment Command 里得先解开这层封装才能看到 RR 层字段。讲义正文里写 Abis 物理层是“2048bps”这应该是转录错误实际就是 E1 的 2048 kbit/s。DTAP 和 BSSMAP 的分工也要先刻在脑子里。BSSMAP 用于 MSC 与 BSC 之间的资源管理比如寻呼、指配、切换、复位这类消息 BSC 收到后会自己消化改格式在 Abis 口不一定能看到。DTAP 负责 MSC 与 MS 之间的 MM、CM 层消息透明传递BSC 不做解析只管搬运所以在 A 口抓到的一条 Setup 或 Location Updating Request内容与 MS 发出来的一模一样。2.2 低三层与网络层的三个子层RR、MM、CM 到底归谁管讲义按 OSI 低三层把 BSS 信令模型拆成物理层、链路层、网络层这个分层不是摆样子每一层对应一种排查手段。物理层负责物理数据单元的无错传送定义了传输路径上的电气特性对应到现网就是载频、时隙、E1 链路的状态。链路层负责帧传递、无错传送和连接实体的建立维持LAPD 的 SABME、UA、DISC 都在这一层干活。网络层负责端到端连接、寻址和路由选择GSM 里被进一步拆成 RR、MM、CM 三个子层。网络层子层主要职责实现位置现网对应事件RR无线资源建立、维持、释放物理连接主要在 BSC部分在 BTS立即指配、切换、加密、测量报告MM移动管理注册、鉴权、位置更新、TMSI 重分配在 MSC / VLR位置更新、鉴权、IMSI 分离CM连接管理呼叫控制、补充业务、短消息在 MS 与 MSC呼叫建立、释放、DTMFRR 层是与其他层的“基本接口”它的功能分布在 BSC 和 BTS 两侧。MM 层的功能在 MSC 一侧实现最容易被误认为是 BSC 的问题。CM 层是最高层子层里 CC 管呼叫的建立、维持和清除SS 管补充业务SMS 管短消息。判断一条信令异常属于哪个层可以先看消息落在哪个子层RR 层消息异常重点查 BSC 参数和无线资源MM 层异常重点查鉴权、位置更新相关的 MSC / VLR 配置和 SIM 卡状态CC 层异常重点查呼叫路由和号码分析。2.3 消息清单当索引用RR、MM、CC、BTSM、BSSMAP 的代表消息讲义里给了五个消息列表很多人翻过去就完了其实这是最实用的索引。我把每层挑几条代表消息对应到现网里最常见的场景排查时按这张表反查消息名比临时翻协议快得多。所属层代表消息对应现网事件RR立即指配Immediate Assignment、寻呼响应、切换命令、加密模式命令、测量报告、系统消息 1-6接入失败、寻呼无响应、切换失败、加密失败、覆盖与干扰判断MM位置更新请求 / 接受 / 拒绝、鉴权请求 / 响应 / 拒绝、TMSI 重分配、CM 业务请求位置更新失败、鉴权失败、TMSI 乱分配、主叫被叫建立慢CCSetup、Call Proceeding、Alerting、Connect、Disconnect、Release呼叫接续、振铃与接通、挂断与释放异常BTSMData Request、Data Indication、信道激活、RF 信道释放、测量结果、SACCH 填充Abis 口封装、信道激活失败、功率控制异常BSSMAP指配请求 / 完成 / 失败、寻呼、切换请求 / 命令 / 完成、清除命令、复位、阻塞寻呼、TCH 指配失败、切换执行失败、BSC 复位使用这份清单的方法是按层反查主叫拨号后没有回铃先查 CC 层有没有 Setup 和 Alerting位置更新被拒绝到 MM 层找 Location Update Reject并看 reject cause 是 2、3 还是 4TCH 指配不起去 BSSMAP 查 Assignment Request 之后有没有 Assignment Failurefailure cause 指向拥塞还是无线接口失败。讲义把这些消息名整理成表省去了逐条翻规范确认缩写含义的功夫。3. 三大核心流程主叫、被叫、位置更新的消息序列对照把协议栈的骨架立起来之后再进流程就顺了。讲义的核心章节是移动主叫、移动被叫、位置更新、切换。主叫被叫是日常投诉最多的场景位置更新是影响寻呼成功率的关键先把这三个流程的消息序列背熟再做切换。3.1 移动主叫从 Channel Request 到 Connect ACK移动主叫的完整链路由接入、鉴权加密、TCH 指配、接通与释放四段组成每段都有独立的失败点。第一步是随机接入MS 在 RACH 上发 Channel RequestBTS 收到后通过 Abis 口向 BSC 上报 Channel RequiredBSC 分配 SDCCH 并下发激活命令BTS 在 AGCH 上回 Immediate AssignmentMS 转到 SDCCH 并建立 LAPDm 连接。这个阶段失败要么是 Channel Request 根本没到 BTS要么是 SDCCH 拥塞导致 Immediate Assignment Reject。之后 MS 在 SDCCH 上发 CM Service RequestBSC 打包透传给 MSC。MSC 回鉴权请求MS 用 SIM 卡里的 Ki 和 A3/A8 算法算 SRES 回响应MSC 比对通过后下发加密模式命令。这一段最值得关注的是鉴权请求之后有没有响应以及响应里的 SRES 是否匹配。如果鉴权响应超时或拒绝常见原因是 SIM 卡数据与 HLR/VLR 不一致而不是无线问题。现在许多网络能用 TMSI 和加密参数跳过部分鉴权看到流程里没有鉴权请求不必惊讶。加密完成后是呼叫建立的核心段MS 发 Setup 携带被叫号码MSC 回 Call Proceeding同时向 BSC 下发 Assignment Request 分配 TCH。BSC 在空口发 Assignment CommandMS 切到 TCH 后回 Assignment Complete。这一步是整个主叫流程里最值得盯的一段TCH 分配失败往往表现为 Assignment Failure原因是目标载频拥塞或干扰。之后 MSC 向 MS 发 Alerting被叫振铃、Connect、MS 回 Connect ACK通话建立挂断时按 Disconnect → Release → Release Complete 的顺序释放。主叫阶段关键消息失败观察点随机接入Channel Request → Immediate AssignmentRACH 接入失败、SDCCH 拥塞鉴权加密Authentication Request / ResponseCipher Mode Command鉴权拒绝、加密失败TCH 指配Assignment Request → Assignment Command → Assignment CompleteTCH 拥塞、指配失败接通释放Setup → Alerting → Connect → Disconnect → Release被叫侧无响应、释放异常主叫流程还有一个隐形的第二步分配SDCCH 先分配一次确认身份后再分配 TCH中间如果不停做加密和鉴权SDCCH 占用时间会拖长。优化时可以看 CM Service Request 到 Assignment Command 之间用了多少条 DTAP 消息消息越多呼叫建立时延越大。3.2 移动被叫寻呼怎么落地比主叫多了哪一段被叫流程和主叫最大的差别是开头MSC 通过 BSSMAP 下发 PagingBSC 把这个寻呼命令分散到 MS 所在位置区的所有小区BTS 在 PCH 上广播寻呼消息。MS 收到寻呼后在 RACH 上发 Paging Response后续鉴权、加密、TCH 指配基本与主叫相同。但 Setup 的方向反了——被叫侧是从 MSC 到 MS而且 MS 回的是 Call Confirmed 而不是 Call ProceedingMSC 要等被叫用户应答所以 Alerting 由被叫侧发起Connect 也由被叫侧发起。被叫流程里最多人忽略的是“寻呼响应”这个点的定位价值。Paging 发出去之后如果 Paging Response 在超时时间内没回来问题在无线侧PCH 拥塞、MS 不在服务区或位置区数据错误MS 实际所在的 LA 与 VLR 里登记的 LA 不一致如果 Paging Response 回来了但 Setup 之后没有 Alerting问题在被叫用户端或 MSC 到被叫侧的局数据。判断被叫问题先确认有没有 Paging Response再往下查这一条能过滤掉一半的无用排查。被叫流程和主叫流程在业务信道上完全一致差别只在寻呼这一段这也解释了为什么 GSM 优化里寻呼成功率和被叫接通率强相关。位置区不合理导致寻呼消息在多个小区重复下发整体寻呼负荷上去后PCH 拥塞会直接拖累被叫接通率。3.3 位置更新TMSI 与 IMSI 的切换、鉴权与 LA Accept位置更新流程在故障定位里常被忽视其实很多主叫被叫异常的根因都在位置更新。MS 从旧位置区进入新位置区时会在 RACH 上发 Location Updating Request消息里携带旧 LAI 和 TMSI 或 IMSI。新 MSC/VLR 收到后如果判断需要鉴权就下发鉴权请求通过后做位置更新登记再回 Location Update Accept。注意这个流程中没有 TCH 指配全程在 SDCCH 上完成所以对 SDCCH 资源的消耗很明显。位置更新的关键看三个点。第一消息里用的是 TMSI 还是 IMSI用户第一次开机入网或 VLR 里没有该 TMSI 记录时会用 IMSI正常漫游切换时用 TMSI减少 IMSI 在空中接口暴露。第二Location Update Accept 之后通常紧跟 TMSI Reallocation Command 和 Complete新 TMSI 由 VLR 分配MS 确认后下一次更新就用新 TMSI。第三周期性位置更新由 T3212 定时器控制到时间后 MS 即使不跨区也会做周期性更新T3212 设置过小会加重 SDCCH 负荷过大会导致网络侧认为 MS 失联。位置更新步骤消息方向观察点发起MS → BTS / BSC → MSCLocation Updating Request携带旧 LAI、TMSI 或 IMSI鉴权MSC → MSAuthentication RequestMS → MSCAuthentication ResponseSRES 不匹配、鉴权拒绝接受MSC → MSLocation Update AcceptLA 边界、VLR 数据是否一致TMSI 重分配MSC → MSTMSI Reallocation Command / CompleteTMSI 分配失败导致反复发起更新位置更新被拒绝是投诉里常见的一种情况。Location Update Reject 一般带 cause 值3 表示 illegal MS6 表示 illegal ME2 表示位置区不允许。看到 cause 2多数是 MSC/VLR 的 LA 白名单没配好cause 3 或 6 则要查 SIM 卡的 IMSI 和设备的 IMEI 在黑名单里的状态。这个地方最容易踩的坑是直接下结论说“用户卡坏了”实际 VLR 侧把用户状态置成了 detached清一下用户数据往往就恢复了。4. 四类切换差异小区内、小区间、外部切换与定向重试的判定依据讲义把切换分成小区内、小区间、外部切换、定向重试四类这四类的触发机制和执行路径完全不同信令特征也不一样。判断切换问题前先认清楚是哪一类切换再去抓对应接口的消息。4.1 小区内切换为什么同站还要切信道小区内切换发生在同一个 BTS 内甚至同一个载频的不同时隙之间。触发原因是质量差或者干扰而不是信号弱——如果 MS 还在原小区内但某条信道的 BER 持续恶化BSC 会在同一小区内找一条空闲信道切过去。信令特征是在 Abis 口上能看到信道激活指向的是同一载频的另一个时隙而 BTS 侧通过测量结果和 MS 功率控制辅助判断。4.2 小区间切换从 Handover Required 到 Handover Complete小区间切换按执行主体可以分为 BSC 内和 BSC 间。BSC 内切换由测量报告触发BSC 自己就能决策信令上能看到 BTS 上报的测量结果触发 BSC 下发切换命令。BSC 间切换会出现在 A 口BSC 判断需要切换后向 MSC 发 Handover Required携带目标小区标识MSC 把 Handover Request 发给目标 BSC目标 BSC 激活目标信道后回 Handover Request ACK源 BSC 通过无线链路下发 Handover CommandMS 切到目标小区后目标 BTS 检测到接入上报 Handover Detect最终由目标侧完成 Handover Complete。注意这个流程里 Handover Complete 的发送方是目标侧而不是源侧切换完成后源信道要等 Clear Command 来释放。4.3 外部切换与定向重试跨 MSC 的消息走向差异外部切换是跨 MSC 的场景。源 MSC 收到 Handover Required 后通过 MAP/E 接口向目标 MSC 发起 Prepare Handover目标 MSC 返回 Handover Request ACK之后由源 MSC 通过 BSSMAP 下发 Handover Command。跨 MSC 切换的失败点通常分两段前半段在 MAP 层后半段在 BSSMAP 层。A 口信令里看 BSSMAP 的 Handover Required 与 Handover Request 是否成对出现不成对就说明 MSC 之间的协商没通。定向重试则和前两类完全不同。它不是切换而是呼叫建立阶段的一种资源挽救手段MS 在原小区请求 TCH但该小区 TCH 全忙BSC 不直接发 Assignment Failure而是通过立即指配或重定向消息把 MS 引到相邻小区的空闲 TCH 上。信令特征是在 Assignment Request 之后没有 Assignment Command而是出现了 Immediate Assignment 指向另一个小区。定向重试的参数与目标小区的选择策略强相关如果参数配置激进会导致话务被大量疏导到邻小区形成新的拥塞点。下表把四类切换的信令特征做个对照排查时先对号入座再下手。类型触发场景关键信令特征主要观察接口小区内切换同小区内质量差、干扰信道激活指向同一载频其他时隙Abis小区间切换BSC 内邻区信号更好BSC 直接下发切换命令Abis小区间切换BSC 间跨 BSCHandover Required → Handover RequestA外部切换跨 MSCMAP Prepare Handover BSSMAPA / MAP定向重试TCH 全忙Assignment 后出现指向邻小区的 Immediate AssignmentAbis / Um5. 信令分析避坑指南五个我踩过的“假结论”现场信令分析有一个尴尬的属性消息摆在那里但解读方式不同结论差很远。以下五条都是我实际遇到过的误判每一条都值得记下来。5.1 只看网络层消息不看链路层重传把网络层失败误判为无线差现象某小区 TCH 指配失败率持续偏高无线环境测试正常网络层看到 Assignment Failurecause 为无线接口失败。原因Abis 链路的 E1 存在滑码或误码LAPD 层不停重传网络层消息到达时间超时最终报无线接口失败。解决抓 Abis 口数据数 LAPD 层的 I 帧重传次数和帧校验错误确认链路质量问题后更换 E1 通道或检查传输设备。从那以后我看到“无线接口失败”这个 cause 不再第一时间怀疑空口而是先看链路层有没有重传。5.2 主叫失败全甩给空口没查被叫侧寻呼现象主叫测试中多次未接通测试软件显示主叫侧已发出 Setup但一直没有 Alerting现场工程师判断是空口覆盖问题。原因被叫侧寻呼响应没回来实际上是位置区更新失败导致 VLR 里被叫位置信息错误。解决切换到被叫侧抓信令确认 Paging 下发后是否有 Paging Response没有的话查被叫所在位置区与 VLR 登记是否一致。主叫呼叫建立失败先分清是主叫侧消息断了还是被叫侧没反应别让主叫侧测试数据替你背锅。5.3 位置更新没鉴权就断定异常现象某用户频繁主叫失败信令里看到位置更新流程直接跳过了鉴权工程师据此认为网络侧鉴权参数配置错误。原因网络侧允许基于 TMSI 和加密模式的免鉴权位置更新MS 的 TMSI 有效时不一定每次都触发完整鉴权。解决位置更新失败与否以 Location Update Accept 或 Reject 为准不要以有没有鉴权请求来判断过程是否正常。免鉴权更新不是故障是网络参数策略看到一个流程里没有鉴权就报警属于对流程理解不到位。5.4 把 Handover Complete 当作切换已经成功现象切换成功率指标很高但掉话率也高工程师想不通“切都切成功了怎么还掉话”。原因Handover Complete 只代表 MS 在目标小区完成了接入源侧信道要等 Clear Command 才正式释放如果源信道未及时释放且 MS 在目标小区质量不稳定会形成瞬间的双连接状态最终导致掉话。解决看完整切换链路确认 Handover Complete 之后有 Clear Command 释放源侧资源再下“切换成功”的结论。信令分析看的是整条链路的闭环一个中间消息的成功不代表流程成功。5.5 用 2000 年流程硬套现代网络现象按照讲义里的完整流程去抓包发现某些消息在 Abis 口根本不存在怀疑抓包工具配置不对。原因现代 BSC 把部分 RR 功能下沉到 BTS测量报告和功率控制等消息在 BTS 侧直接处理Abis 口不再承载所有 RR 消息。解决以实际抓包的接口为准把讲义当作流程模板而不是抓包清单Abis 口看不到某条消息不代表流程没发生可能是封装方式变了。这份讲义的价值是流程骨架不是协议实现的完整镜像。6. 把一张失败信令拆出结论三层两段式分析流程看得再多最终要落到“拿一条失败信令怎么分析”。我日常用的是一套三层两段式分析方法先把消息按物理层、链路层、网络层三个层次分层归类再把流程拆成请求链路和响应链路两段来对齐。第一层物理层看 RxLev、RxQual、TA 和传输链路状态。RxLev 低说明覆盖问题RxQual 高说明干扰问题TA 异常超限要怀疑边界小区和直放站。第二层链路层看 LAPD 和 LAPDm 的 SABME、UA、DISC 以及 I 帧重传。链路层出现大量重传即使网络层消息看起来正常也要把问题记在传输上。第三层网络层看 RR、MM、CC 消息的内容和 cause 值。判完这一层基本能区分问题出在接入、鉴权、寻呼还是 TCH 分配阶段。两段式是把同一流程的请求方向和响应方向对齐来看。主叫流程里MS 发 Setup 是请求段MSC 回 Call Proceeding 是响应段MSC 发 Alerting 是请求段但没有对应的最终响应时就要看两段之间断在哪一条消息上。这条断点就是故障的直接位置。用这个办法我遇到过一条主叫失败案例网络层看 Setup 已经发出但 Call Proceeding 一直没到物理层和链路层都正常最后发现是 MSC 对被叫号码的号码分析配置缺失导致 Setup 在 MSC 内部被丢弃。三层把故障层限定两段把故障点定位这套顺序下来基本不存在“不知道从哪查起”的情况。那份讲义里每一种流程都能在信令分析工具里找到对应的实例真正要做到的是拿到一条失败信令时先按三层两段法把消息排队而不是一上来就看直观的失败消息。从那以后我每次拿到一条失败信令不管问题多急都强制先走一遍这个顺序再下结论。希望帮到你。本文还有配套的精品资源点击获取