简介这份GSM接口与呼叫流程课件系统梳理了移动通信核心网的组网逻辑适合通信专业学生、网络优化及运维人员学习。课件先介绍协议栈中的移动台、基站控制器、移动交换中心、无线资源管理等网元并说明MTP、SCCP、LAPD等信令模块的作用随后重点讲解A、Abis、Um三大接口的职责、承载链路及开放式接口属性Abis接口还涉及2.048Mb/s或64kbit/s的PCM链接。呼叫流程部分逐条拆解位置更新、鉴权加密、释放、移动主被叫及切换其中位置更新区分开机附着、正常更新和周期更新补充TMSI分配等细节。资源为单个PPT文件压缩包仅493KB下载后可直接打开查阅目前已有84人学习。整体内容精炼、层次分明适合课程复习、面试准备或日常排障参考学完可快速建立GSM信令知识框架。1. 当你要向新人讲清 GSM 网络接口和呼叫流程为什么值得花一晚上精读如果你接手过 GSM 网络的维护或优化一定被问过类似的问题手机拨号后信令到底走了哪条路A 接口和 Abis 接口有什么区别为什么同一个 MSC 下切换很快跨 MSC 切换就慢半拍这些问题的答案全部收敛在“GSM 接口与呼叫流程”这一份 PPT 标题里。它讲的不是某一条命令也不是某一个参数而是一张完整的网络拓扑和一次呼叫从发生到结束的状态迁移图。这个方向适合三类人刚入行的网优工程师需要把“接口”和“流程”从名词变成脑子里能跑起来的图核心网维护人员需要搞清楚 MAP、TCAP、SCCP 这些协议栈在呼叫流程中各自承担什么以及要给别人做技术培训的工程师——你只有把接口和呼叫流程讲透新人才不会把 BSC 和 MSC 当成同一个盒子。这篇笔记就按我给别人讲这套内容的思路拆开先理清接口家族和协议栈再逐步拆解主叫、被叫和切换流程最后落在信令跟踪和参数调整的实战上。2. 接口全景BSS 与 NSS 之间到底有哪几条路每条路上跑什么2.1 从 Um 到 A 接口一张拓扑图对应一套协议栈GSM 网络的接口不是凭空定义的每个接口都对应着两个网元之间的物理连接和逻辑信令通道。最常被问到的三个接口Um 接口是手机与 BTS 之间的无线接口也叫空中接口Abis 接口是 BTS 与 BSC 之间的接口承载在 T1/E1 或 IP 传输上A 接口是 BSC 与 MSC 之间的接口。三者串起来就是一次呼叫的“前半程”。先看 Um 接口。它用的协议栈和后面两个接口完全不一样——物理层是 TDMA 帧结构数据链路层是 LAPDm 协议。LAPDm 和有线侧的 LAPD 最大的差别是它没有完整的 D 信道而是把信令插入到业务信道的空闲帧里所以叫“偷帧”。在 Um 接口上信令和业务在同一个物理信道上分时复用这正是 GSM 空中接口的省资源设计。你在信令跟踪软件里看到的 RRRadio Resource消息比如 Channel Request、Immediate Assignment都是封装在 LAPDm 帧里的。Abis 接口的协议栈相对规整物理层是 E1 的 64K 时隙或 IP 承载数据链路层是 LAPD网络层是 DTAPDirect Transfer Application Part和 OMTOperation and Maintenance消息。DTAP 消息是透明传输的BSC 不做解析直接转发给 MSC所以你在 Abis 接口上能看到完整的 CCCall Control和 MMMobility Management消息。注意一个细节Abis 接口上的 DTAP 帧里有一个“Channel Number”字段标识这个信令属于哪条无线信道这个字段在 A 接口的 BSSAP 消息里也有用于关联无线资源和有线连接。A 接口协议栈更复杂一些底层是 64K 时隙或 IP往上是 MTPMessage Transfer Part和 SCCPSignaling Connection Control Part再往上是 BSSAPBase Station System Application Part。BSSAP 分两类DTAP 和 BSMAPBase Station Management Application Part。DTAP 负责透传 CC 和 MM 消息BSMAP 负责 BSS 管理比如 Assignment、Handover、Paging 等。这里有一个最常见的混淆点很多人以为 BSSAP 就是 DTAP其实 BSSAP 是容器DTAP 只是其中的一部分。2.2 核心网侧接口A 接口之后信令开始走 MAP呼叫过了 A 接口进入 MSC后面还有一串接口B 接口是 MSC 与 VLR 之间的内部接口实际上在一个物理实体里走的是 MAP/B 协议C 接口是 MSC 与 HLR 之间的接口用于取路由信息和计费D 接口是 VLR 与 HLR 之间的接口用于位置更新和用户数据检索E 接口是 MSC 与 MSC 之间的接口用于跨 MSC 切换。这几个接口中D 接口和 E 接口是现网维护中最常打交道的。D 接口走 MAP 协议底层是 TCAPTransaction Capabilities Application Part和 SCCP。移动用户漫游到新区时VLR 通过 D 接口向 HLR 发起 MAP_UPDATE_LOCATION 请求HLR 更新位置后返回用户签约数据。这个过程里涉及的 TCAP 事务处理是核心网信令跟踪中最难啃的部分。TCAP 的“对话”概念和 SCCP 的“连接”概念不是一回事SCCP 提供端到端的面向连接或无连接传输TCAP 在 SCCP 之上管理事务的发起和结束。有一次排障时我盯着 MAP_UPDATE_LOCATION 的超时看了一个小时最后才发现是 SCCP 的子系统号SSN配置错了——HLR 的 SSN 配成了 6而标准规定 MAP 的 SSN 是 7HLR和 8VLR。E 接口在跨 MSC 切换时用到走 MAP_PREPARE_HANDOVER 等消息。这里有个重要参数叫“切换号码HON”由目标 MSC 分配用于建立 MSC 之间的语音电路。如果你在信令跟踪里看到 MAP_PREPARE_HANDOVER_Req 之后长时间没有响应大概率是 HON 分配失败或电路资源不足。2.3 接口选型与排障一个参数表帮你快速定位问题网元接口连接网元主要协议常见消息故障定位关键点UmMS ↔ BTSLAPDm / RRChannel Request, Immediate Assignment无线环境RACH 拥塞AbisBTS ↔ BSCLAPD / DTAPChannel Activation, DTAP (CC, MM)E1 时隙是否完好LAPD 链路状态ABSC ↔ MSCBSSAP (DTAPBSMAP)Assignment, Paging, HandoverSCCP 连接是否建立CIC 分配BMSC ↔ VLR内部MAP/BUPDATE_LOCATION一般随 MSC 版本走不需单独排障CMSC ↔ HLRMAP/CSEND_ROUTING_INFOGT 号码翻译是否正确DVLR ↔ HLRMAP/DUPDATE_LOCATION, INSERT_SUBSCRIBER_DATATCAP 超时SSN 配置EMSC ↔ MSCMAP/EPREPARE_HANDOVER切换号码资源是否耗尽实际维护中如果你在一个接口上看到大量消息超时第一件事不是查对端设备而是查本端到对端的传输层。比如 D 接口频繁超时先看 SCCP 层有没有建立连接、GTGlobal Title翻译是否正确。GT 翻译是核心网排障的高频故障点——HLR 的 GT 号码在 MSC 侧配错或者号段没加全都会导致 MAP 消息石沉大海。我自己的习惯是先在 MSC 侧用“TRC”指令查 GT 分析表确认被叫号码能翻译到正确的 HLR 地址再往上查 TCAP 层。这套思路对 PPT 里的接口章节同样适用关键是把“接口”理解成“协议栈 传输链路 地址翻译”三件事而不是一根线。3. 协议栈拆解从物理层到 MAP 每一层在呼叫里干什么活3.1 无线侧的 RR 和 MM呼叫的第一跳和第二跳一次呼叫在 Um 接口上的启动首先是 RR无线资源管理层的活。手机开机或发起呼叫时先在 RACH 上发送 Channel RequestBTS 收到后在 AGCH 上回复 Immediate Assignment给手机分配一个专用信道SDCCH 或 TCH。这条消息里关键信息是“信道描述”和“初始时间提前量TA”。TA 是 GSM 特有的机制因为手机离基站的距离不同信号传播时延不同基站必须告诉手机提前多少时间发数据。熟悉射频优化的工程师常常通过 TA 分布判断是否存在越区覆盖——TA 值大于 2 的小区占比高说明覆盖半径异常大可能吸收了远处的信号。RR 层建立无线信道后MM移动性管理层开始干活。MM 的核心任务包括鉴权Authentication、加密Ciphering、位置更新Location Update和 TMSI 重分配。呼叫建立前MSC/VLR 会发起鉴权流程MSC 向手机发送 Authentication Request里面携带 RAND随机数手机用 SIM 卡里的 Ki 密钥和 A3 算法算出 SRES 回传MSC 与 VLR 里的期望值对比。这整条链路是 GSM 安全的基石但要注意的是GSM 的鉴权是单向的——网络鉴权手机手机不鉴权网络这就给后来的伪基站留下了空子。在实际维护中你不会看到鉴权细节但会看到 MM 消息里的 Cipher Mode Command这条消息代表加密已开启如果某个小区大量呼叫在 Cipher Mode 之前就释放说明加密配置异常或手机不支持加密算法。3.2 呼叫控制 CC 层与 DTAP 透传Setup 消息里最重要的三个字段CCCall Control层是呼叫流程里最直观的部分。它负责建立、维持和释放呼叫消息类型和 ISDN 的 Q.931 非常像。主叫侧典型的消息序列是CM Service Request在 SDCCH 上发→ Setup携带被叫号码→ Call ProceedingMSC 回执→ Alerting被叫开始振铃→ Connect被叫接听。这套消息全部封装在 DTAP 里从手机到 BSC 再到 MSCBSC 基本不做处理只做透传。这里要关注 Setup 消息里的三个字段被叫号码Called Party BCD Number、主叫号码Calling Party BCD Number和承载能力Bearer Capability。承载能力字段决定这通电话是语音还是数据如果是语音还会带语音编码方式。现网里常见的四个编码FR全速率 13kbps、HR半速率 5.6kbps、EFR增强全速率 12.2kbps和 AMR自适应多速率。AMR 是现网主力因为它能根据无线质量动态调整编码速率。你如果看到 Setup 里 Bearer Capability 的语音编码是 AMR 2说明是 AMR 12.2kbps 模式。这个细节对定位“接通率低但掉话率正常”的问题很有用——如果某个小区 AMR 模式没启用用户在弱信号下语音质量会急剧下降但信令层面看不到失败。3.3 MAP 层和 TCAP 层的交互一个位置更新消息的完整旅程MAPMobile Application Part层是 GSM 核心网协议栈的顶层它跑在 TCAP 之上TCAP 跑在 SCCP 之上。以位置更新为例手机进入新位置区后通过 BSS 向 MSC 发 Location Updating RequestMSC 发现当前 VLR 没有这个用户的记录就向 HLR 发 MAP_UPDATE_LOCATION。这条消息里的关键参数是 IMSI 和 MSC/VLR 号码。HLR 收到后做三件事更新用户位置、向旧 VLR 发 MAP_CANCEL_LOCATION 删除旧记录、向新 VLR 发 MAP_INSERT_SUBSCRIBER_DATA 下发签约数据。整个过程的 TCAP 对话是一来一回的HLR 必须在规定时间内应答否则 MSC/VLR 侧会报“TCAP 超时”或“MAP 错误”。排障中典型的 MAP 层问题是 GT 翻译走到错误的 HLR。这时你看到的现象是用户位置更新失败但信令跟踪里没有显式的错误码。解决办法是查 MSC/VLR 到 HLR 的 GT 分析表确认被叫 GT 号码的号段翻译是否完整。另外一个常踩的坑是 TCAP 的 Transaction ID 不匹配——如果对端设备响应时把事务 ID 搞错了本端会认为这是新事务而丢弃。这种情况多见于厂商设备互联时TCAP 协议版本不一致导致。我处理过一起这样的问题某局 MSC 和 HLR 之间频繁掉事务抓包看 TCAP 层发现对端回复时把 Originating Transaction ID 和 Responding Transaction ID 的位置搞反了升级对端软件版本后才解决。这类问题在 PPT 里不会讲但实操里很常见。4. 主叫呼叫流程逐步图解从按键到振铃中间经过的七个关键点4.1 信道请求RACH 上的第一次握手和冲突主叫流程不是从 Setup 开始的而是从手机在 RACHRandom Access Channel随机接入信道上发 Channel Request 开始的。这一步的物理层机制值得展开RACH 是一个上行公共信道所有手机共享所以必然存在冲突。GSM 用“ALOHA 协议”来解决冲突——手机先随机等一段时间再发如果冲突了再重试。这也是为什么高话务量区域容易出现“RACH 冲突导致呼叫建立慢”的情况。Channel Request 消息里只带两个核心信息建立原因Establishment Cause和随机参考号Random Reference。建立原因包括“紧急呼叫”“主叫”“被叫应答”“位置更新”等。随机参考号是手机自己挑的一个随机数用于后续基站分配信道时确认“这个立即指派是给我的”。BTS 收到 Channel Request 后如果资源充足会在 AGCHAccess Grant Channel上回复 Immediate Assignment 消息。这条消息里最重要的字段是信道描述——指定了手机跳到哪条频率、哪个时隙去建立专用信道。如果你在做路测看到一个事件标记为“Immediate Assignment Reject”说明基站没有空闲信道了直接原因是 SDCCH 拥塞。SDCCH 拥塞的统一解法是增加 SDCCH 配置数量或者核查 T3212 周期位置更新时间是否过短导致 SDCCH 被位置更新占满。4.2 鉴权与加密网络确认“你不是别人冒充的”Immediate Assignment 之后手机转入 SDCCH 专用模式。此时网络侧发起鉴权流程。我这里要强调下顺序GSM 规范里鉴权可以在 CM Service Request 之后立刻做也可以在位置更新时做。实际网络中MSC/VLR 会根据用户状态决定是否需要鉴权。如果用户有 TMSI 且 VLR 里有有效的三元组RAND、SRES、Kc可能就不重新鉴权了直接跳加密。鉴权通过后MSC 发 Cipher Mode Command 给 BSCBSC 把这个消息封装在 RR 层消息里发给手机。手机收到后启动加密并回 Cipher Mode Complete。这个“启动加密”的动作不是瞬间完成的——手机在发 Complete 消息之前所有消息都是明文只有网络收到 Complete 并下发确认后后续消息才加密传输。在空口抓包时你能看到一条非常明显的“加密开始”边界在 Cipher Mode Command 之后所有无线信令的 CC 和 MM 消息都变成密文你只能看到 RR 层帧头看不到内容。这是正常的不要以为是抓包软件解码失败。4.3 呼叫建立核心序列Setup → Call Proceeding → Alerting → Connect信道建立完成、鉴权加密完成后真正“打电话”的消息序列开始了。手机在 SDCCH 上发 CM Service Request这是给网络看的“我要开始打电话了”的通知。MSC 收到后回 CM Service Accept接着手机发 Setup。Setup 消息里有被叫号码、主叫号码和承载能力等关键信息。MSC 收到 Setup 后要做几件事分析被叫号码、确定被叫归属、选择路由。如果被叫在本 MSC 内MSC 直接向被叫侧发起寻呼如果被叫在别的网络比如固网或其它移动网络MSC 通过 ISUP 信令向外部网络发 IAMInitial Address Message。这里要区分GSM 网络内部的呼叫控制消息是 CC 消息用 DTAP 传但 GSM 网络到外部网络的呼叫是 ISUP 消息用 MTP 传)这两套消息序列完全不同。很多新人看到信令跟踪里出现了 IAM 和 ACM 就懵其实那是到外部网络的 ISUP 信令。MSC 成功分析号码后向手机回 Call Proceeding 表示“正在处理”。如果是本局呼叫MSC 会通过 BSS 向被叫手机发寻呼消息。被叫收到寻呼后回寻呼响应网络完成连接建立然后被叫侧开始振铃MSC 向主叫发 Alerting。主叫手机开始放回铃音。被叫接听时网络收到 Connect 消息MSC 向主叫发 Connect或 Connect Acknowledge此时语音通路真正建立。这里有一个容易找不到北的点主叫侧收到的 Alerting 消息里的“Progress Indicator”字段可能带值表示回铃音是网络放还是手机本地放。如果是网络放PI8且你抓到的 Alerting 消息没有带任何音频信息别慌那是正常的——回铃音由 MSC 的语音电路提供不走信令。4.4 主叫侧信令序列与超时参数一句话讲清每个等待点主叫流程中每个等待点都有对应的定时器。手机发完 Channel Request 后等 Immediate Assignment等待超时受 T3126 控制默认值因厂商而异常见 5 秒左右。手机发完 CM Service Request 后等 CM Service Accept超时由 T3210 控制。手机发 Setup 后等 Call Proceeding超时由 T310 控制。MSC 发 Alerting 后等 Connect超时由 T301 控制。这些定时器任何一个触发都会导致呼叫释放或重发。实际优化时我们一般动得最多的是 T310 和 T301。T310 太短容易造成“接通前掉话”表现为主叫听到回铃音后突然断线但被叫其实已经振铃了。T301 太短则会导致“被叫接听但主叫侧已经放弃”。另一个与主叫直接相关的参数是 T3113它控制 MSC 发寻呼后等待被叫响应的时间。T3113 太短被叫在弱信号区来不及响应寻呼就会出现“主叫听到回铃音但被叫还没反应”的现象——实际上是寻呼已经超时了。把这些超时参数映射到信令流程图上你会发现每条消息之间的空隙都有对应的定时器这就是定时器参数和呼叫流程图必须合在一起看的原因。5. 被叫流程、切换与位置更新网络侧怎么找到用户并把路改到新小区5.1 被叫接入寻呼消息为什么在 LAC 范围内广播被叫流程最核心的步骤是寻呼Paging。MSC 收到入局呼叫请求后根据被叫用户所在的 VLR 记录确定其当前所在的位置区LAC然后通过 BSS 在位置区内所有小区下发 Paging 消息。这里可以看到两个寻呼模式TMSI 寻呼和 IMSI 寻呼。如果 VLR 里有被叫的 TMSIMSC 用 TMSI 寻呼这样空口上的用户身份不容易被截获如果没有 TMSI比如刚开机还没做 TMSI 重分配就用 IMSI 寻呼。Paging 消息在空口上是 PCHPaging Channel下发的位置区内所有小区都会发。手机在空闲态下周期性监听 PCH收到包含自己 TMSI/IMSI 的寻呼消息后发起 Channel Request 并携带“被叫应答Call Answered”的建立原因。这就是为什么被叫流程的第一步和主叫流程一样也是一条 Channel Request但建立原因不同。寻呼策略里有个常用参数叫“寻呼重发次数Paging Retry”和“寻呼间隔Paging Interval”。如果被叫大量“寻呼无响应”先看这两个参数是否配置合理再看位置区是否过大、PCH 容量是否够用——位置区越大PCH 负担越重寻呼延迟越高。5.2 跨 LAC 的位置更新T3212 是个双刃剑位置更新是网络找到用户的另一条路径。GSM 里分三种位置更新正常位置更新跨 LAC、周期性位置更新T3212 触发、IMSI Attach/Detach。正常位置更新的触发条件是手机发现当前小区的 LAC 与 SIM 卡里存的 LAC 不一致就会发起位置更新请求。这个流程之前讲过关键在 VLR/HLR 的数据交互。T3212 周期位置更新是网络维持“用户在线”状态的保险机制。手机在 T3212 定时器超时后即使跨 LAC 也会发起位置更新告诉网络“我还活着”。T3212 设得越短网络越能及时知道用户的位置但 SDCCH 和核心网信令的负载也越高。T3212 设得太长用户实际已经离开很久网络还不知道会导致被叫寻呼到处广播都找不到人。我一般建议在城区设 60 分钟以内郊区可以放宽到 120 分钟但超过 240 分钟就明显不合适了。排查寻呼类问题时T3212 优先检查。5.3 切换流程与边界先建后切还是先切后建切换是呼叫保持的关键环节。GSM 切换分三类BSC 内切换、MSC 内跨 BSC 切换、跨 MSC 切换。BSC 内切换最干净——BSC 自己就能完成资源分配和无线信道切换核心网不感知。MSC 内跨 BSC 切换需要 MSC 参与把 A 接口的电路从旧 BSC 改到新 BSC。而跨 MSC 切换最复杂涉及 E 接口和切换号码的分配。这里必须区分两种切换信令流程 “先建后切”又叫“无缝切换”和“先切后建”。先建后切是 GSM 最常用的方式目标小区先分配好无线信道和地面电路等手机完成切换后才释放旧资源。好处是切换中断时间短坏处是切换期间同时占两份无线资源容量利用率低。BSC 内切换基本都用先建后切跨 MSC 切换因为涉及远端电路分配更多用先切后建——先断旧路再接新路资源利用率高但中断时间稍长。切换信令的核心消息序列是源 BSC 发 Handover RequiredBSMAP 消息给 MSCMSC 根据目标小区分析切换类型。如果是跨 BSCMSC 给目标 BSC 发 Handover Request目标 BSC 分配信道后回 Handover Request AcknowledgeMSC 给源 BSC 发 Handover Command源 BSC 把切换命令给手机手机在目标小区发 Handover Access目标 BSC 向 MSC 发 Handover Complete最后 MSC 通知源 BSC 释放旧无线资源。整个流程中你要盯住的三个关键参数是目标小区信道是否可用、A 接口电路CIC是否可分配、切换号码资源是否充足。任何一个资源池见底都会表现为切换失败率升高。5.4 位置更新和切换的边界条件一个容易被忽略的“乒乓”问题边界条件最容易出的问题是位置更新和切换之间的交互。比如用户在两个 LAC 边界反复移动一会触发位置更新一会触发切换导致信令面压力增大用户感知就是时延不稳。优化手段一般是调整 LAC 边界与小区覆盖边界对齐——尽量让 LAC 边界落在覆盖空洞或车流少的区域避免用户在同一条路上往复穿越两个 LAC。另一个常见问题是在位置更新过程中来了切换请求。手机正在做位置更新时网络端发起切换命令手机可能因状态不匹配而掉话——它只有一张 SIM 卡、一根天线无法同时进行位置更新和切换。处理办法是让 MSC 在寻呼响应或位置更新期间挂起切换请求等位置更新完成后再处理。这是核心网侧的定时器匹配问题不同厂商设备的默认策略不同联调时要特别关注。6. 避坑指南GSM 呼叫信令排查里最常翻车的五个场景6.1 寻呼无响应但手机信号满格现象被叫长时间无响应信令跟踪显示 MSC 已发送 Paging但 BSC 侧没有收到 Paging Response。原因之一是手机在分组域GPRS/EDGE上做数据业务而网络配置了“寻呼协同”但没生效——MSC 的寻呼消息发到了 BSC但手机所在的小区正在用 PDCH 做数据传输PCH 监听被跳过。解决方法是核查 BSC 是否开启“寻呼与分组业务协同”功能且 MSC 和 BSC 的寻呼配合参数一致。另一个原因是 VLR 里用户的 LAC 已经过期比如用户从 A 区漫游到 B 区后位置更新失败VLR 仍存着 A 区 LACMSC 把寻呼发到 A 区但用户实际在 B 区——此时你会在 A 区所有小区看到寻呼消息但 B 区没有任何寻呼。排障时先用指令查 VLR 里用户的编号和 LAC。6.2 主叫听到回铃音但被叫没反应现象主叫侧已经收到 Alerting 且听到回铃音但被叫侧其实没有振铃。原因是 MSC 侧的 T301 时长设置不当或者被叫侧在 Alerting 和 Connect 之间的定时器T310先超时了。具体到信号层面MSC 向被叫发 Alerting 后开始等待 Connect如果被叫手机振铃时间过长比如超过 30 秒且 T301 设置过短比如 15 秒主叫侧就会先释放表现为“听了一会儿回铃音就断了”。解决方法是核对 MSC 侧 T301 参数和被叫手机侧振铃时长阈值。这里有个血泪经验VLR 里用户号码的“无应答转语音邮箱”参数如果和 T301 冲突可能导致 MSC 认为呼叫失败而释放尽管用户已经在接听边缘了。6.3 DTAP 和 BSMAP 消息在 Abis 接口上怎么区分现象在 Abis 接口抓包时按 DTAP 解码失败大量未知消息。原因是把 BSMP 消息当 DTAP 解析了。Abis 接口上BSC 和 MSC 之间的消息有明确分类DTAP 的协议鉴别语Protocol Discriminator是“呼叫控制/移动性管理”而 BSMAP 的协议鉴别语是“BSS 管理”。抓包软件如果自动识别失败需要手动指定层二帧里的“帧控制字段”来选择 SAPI。排查时先确认 LAPD 帧里的 SAPI业务接入点标识——SAPI0 是 DTAPSAPI3 是 BSMAP有些厂商用 SAPI3 传 OMT 消息如果 SAPI 都不对说明 LAPD 链路本身有问题。还有一种常见情况是 Abis 接口用了 IP 承载抓包时要确认 UDP 端口对应关系是否配置正确否则解出来的全是乱码。6.4 位置更新频繁触发导致 SDCCH 拥塞现象某个小区的 SDCCH 占用率持续偏高位置更新请求量大但话务量不高。原因是 T3212 设置过短或者 LAC 边界跨度过大。处理办法是先查该小区的位置更新统计次数区分正常位置更新和周期性位置更新。如果是周期性位置更新导致的拥塞把 T3212 从 30 分钟调大到 60 分钟立竿见影。如果是正常位置更新过多则是 LAC 边界划分问题需要调整边界位置而非调参数。注意T3212 调太大会影响寻呼成功率所以不是越大越好——我一般做法是 T3212 和寻呼重发次数一起调保证寻呼成功率不下降。6.5 跨 MSC 切换成功但语音单通现象切换完成后双方都能听到对方但只有一路有声音。原因通常是切换号码HON指配的电路有问题或 MSC 之间的语音电路没有正确接通。排障顺序先在 MSC 侧查看切换后的电路号CIC再到对端 MSC 确认同一 CIC 是否对应了同一物理电路。如果是 IP 承载的语音VoIP over Nb还要检查编解码协商是否一致——如果主叫侧用了 AMR 而目标 MSC 只支持 FR两边编码不匹配就会造成“无声但有连接”。解决方法是确认端到端的编解码列表协商一致或在 MSC 侧配置转码资源。这个场景在纯 TDM 网络里很少见但 IP 化后成了跨 MSC 切换掉话的常客。7. 落地技巧用一张信令跟踪表把呼叫流程“钉”在屏幕上最后分享一个我用这套流程排查问题时积累的落地习惯——把呼叫流程画成交互图每一步对应一条实际消息标注携带的关键参数。你不用把整条信令流程背下来而是让参数和消息在脑子里“自动配对”。比如步骤消息方向关键消息必看参数失败时的典型表现1MS → BTSChannel Request建立原因随机参考RACH 冲突无响应2BTS → MSImmediate Assignment信道描述TA 值SDCCH 拥塞3MS → MSCCM Service RequestTMSI/IMSI服务类型无响应时查 T32104MSC → MSAuthentication RequestRAND鉴权失败率升高5MS → MSCSetup被叫号码承载能力号码格式错误6MSC → MSAlerting无被叫寻呼超时查 T3017MS → MSCConnect无被叫挂机早于 T310这个表的用法不是查字典而是建立“消息-参数-失败”的三角关系。我排查问题时一般先看失败发生在表的哪一步再逆推到这一步相关的参数和资源池。如果失败在步骤 1-2 之间重点看 SDCCH 资源和 RACH 拥塞失败在步骤 5-6 之间重点看被叫寻呼、T301 和 VLR 里的 LAC 记录。每次排查完把根因标注在表格对应步骤旁边时间长了就是自己的排障手册。另一个技巧是熟练使用信令跟踪软件的过滤功能。大多数跟踪工具支持按 IMSI、MSISDN 或 TMSI 过滤一次呼叫的所有消息还会自动关联 A 接口和 Abis 接口。建议你在开启跟踪前先确认“自动关联”功能已打开否则同一通电话在 Abis 和 A 接口的消息是割裂的需要自己对着时间戳拼。有一次我排查一个呼叫建立慢的问题跟踪了 30 分钟数据最后发现是 Abis 接口上 LAPD 层的重传太多导致 BSC 转发 DTAP 消息延迟而光看 A 接口消息是发现不了这个问题的——因为 A 接口消息时间戳都正常问题出在 BSC 内部排队。所以排查思路是先看 A 接口整体时延分布再看 Abis 接口是否有异常重传两者交叉比较才能定位是传输、BSC 还是 MSC 的问题。我自己的习惯是每做完一个呼叫流程相关的专项优化就把那次的信令跟踪关键截图保存一份用图表注明“正常消息序列”和“异常点”。这个习惯帮我避免了大量重复排障——第一次查跨 MSC 切换单通花了四个小时第二次再遇到类似问题翻老图十分钟就定位到编解码协商了。GSM 的接口和呼叫流程虽然已经是个老技术但它的思路——分接口拆协议栈、按流程找失败点、用参数调行为——到今天做 4G/5G 排障依然通用。希望这篇笔记对你有用。本文还有配套的精品资源点击获取