GSM信令流程实战:从协议栈到呼叫、位置更新与切换的深度解析

发布时间:2026/9/30 3:40:18
GSM信令流程实战:从协议栈到呼叫、位置更新与切换的深度解析 简介本讲义面向移动通信网络运维、优化及故障诊断方向的初中级技术人员系统梳理GSM信令流程的核心知识体系。资源为单个PPT文件压缩包约1.65MB内容以图文并茂的幻灯片形式呈现便于课堂讲解与自学查阅。讲义从GSM网络拓扑结构切入依次讲解TMSC、MSC、BSC、BTS、HLR、VLR、AUC等网元的功能定位再深入7号信令协议群与GSM专用协议群的分层结构涵盖MTP、SCCP、TUP、ISUP、MAP、TCAP、BSSAP、DTAP等关键协议。后半部分重点展开呼叫建立与清除、位置更新、切换等典型信令流程并介绍T3101、T3192等重要定时器及鉴权请求、身份请求等信令消息内容。此外还涉及Wireshark等常用信令分析软件与实时捕获、离线解析、异常检测等基本分析方法。目前已有101人学习适合需要建立完整信令分析框架、提升网络排障能力的读者参考。1. 从一通电话的“黑匣子”说起这份 GSM 信令讲义到底能解决什么你有没有遇到过这种情况用户投诉“打不通电话”你登上 MSC 查告警设备一切正常查话务统计指标也没明显恶化。问题像幽灵一样抓不住。这时候真正能救命的不是 KPI 报表而是把那一通失败呼叫的信令流程完整地“回放”出来——从 MS 发起 Channel Request到 BTS、BSC、MSC 之间的每一层协议交互再到 HLR 鉴权、VLR 位置更新、TUP/ISUP 出局接续每一步都看得见问题才藏不住。这份《信令流程讲义.ppt》就是干这个用的。它不是那种泛泛而谈的通信原理教材而是一套从 GSM 网络拓扑、NO.7 信令协议栈、TUP/ISUP 消息结构一直讲到具体信令流程、重要定时器和常用分析软件的实操型资料。目录里 11 个章节覆盖了从物理层 Um 接口到应用层 MAP/TCAP 的完整协议群还专门有一章讲“基本信令分析方法”。适合谁核心网运维、无线网优、交换工程师以及正在准备通信专业面试或认证考试的人。如果你只想背几个名词应付考试这份资料可能偏重但如果你需要真正动手抓包、解码、定位呼叫失败或切换异常它的价值就出来了。2. 协议栈不是背出来的从 Um 口到 A 口的信令分层拆解2.1 为什么 GSM 要拆成两套协议群GSM 的信令协议结构讲义里明确分成两个主要协议群一是 7 号信令协议群跑在 A 接口、NSS 内部接口以及 GSM 与其余网络的接口上二是 GSM 专用协议群专门管 Abis 接口和 Um 接口。这个划分不是学术分类而是工程上的必然。A 接口是 BSC 和 MSC 之间的接口它承载的是“交换机级别”的信令需要和 PSTN、ISDN 互通所以必须用标准的 NO.7 信令体系——MTP、SCCP、TUP、ISUP 这一套。而 Um 接口是 MS 和 BTS 之间的空中接口Abis 是 BTS 和 BSC 之间的接口它们要解决的是无线资源管理、移动性管理、呼叫控制这些“接入侧”的问题所以 GSM 定义了自己的协议栈RR无线资源管理、MM移动性管理、CM呼叫管理以及底层的 LAPDm 和 LAPD。讲义里那张协议栈对照图很关键MS 侧有 RR、MM、CMBTS 侧在 Um 接口上终结 LAPDm在 Abis 接口上换成 LAPDBSC 侧要处理 BSSMAP 和 DTAP 的分离到了 MSCDTAP 里的 CM 和 MM 消息被送上去BSSMAP 则终结在 MSC 的 BSSAP 层。这个“逐层终结、逐层封装”的过程就是信令流程分析的底层逻辑。2.2 各层协议的分工与关键参数讲义第 4 章把各层协议拆得很细这里把工程上最需要关注的几个点拎出来。MTP 分三层MTP1 是物理层定义 2Mb/s 中继上的信令链路MTP2 是数据链路层负责信令单元的定界、定位和差错检测MTP3 是网络层负责信令消息的路由和网管。MTP3 的路由基于 DPC目的点码和 OPC源点码这是排查“信令送错局向”的第一道线索。SCCP 在 MTP3 之上提供端到端的信令连接。它有两种服务模式无连接CL和面向连接CO。GSM 里的 MAP 和 BSSAP 大多走 SCCP 的无连接服务但某些切换流程会用到面向连接的服务。SCCP 的地址由 GT全局码、SSN子系统号和 PC点码组成SSN 特别重要——比如 HLR 的 SSN 是 6VLR 是 7MSC 是 8。如果你抓包看到 SSN 不对消息根本送不到目标网元。TCAP 是事务处理能力部分它把 MAP 的操作封装成“成分”Component支持请求/响应模式。MAP 是移动应用部分负责位置更新、鉴权、切换、补充业务等。BSSAP 则分成两部分DTAP 直接透传 MS 的 CM/MM 消息BSSMAP 处理 BSC 和 MSC 之间的资源管理消息。TUP 和 ISUP 是用户部分。TUP 用于 PSTN 电话呼叫消息类型包括 IAM初始地址消息、ACM地址全消息、ANC应答消息、CLF拆线消息等。ISUP 是 TUP 的增强版增加了 ISDN 特性比如多方通话、主叫号码显示、用户到用户信令。讲义里特别提到ISUP 的 IAM 消息比 TUP 的 IAM 携带更多参数比如传输介质要求、呼叫性质、主叫用户类别等。这些参数在排查“跨网呼叫失败”时非常关键——比如传输介质要求不匹配对端可能直接拒绝。2.3 用 Wireshark 解码一份 A 接口信令讲义第 10 章提到常用信令分析软件Wireshark 是其中之一。下面用 Wireshark 解码一份 A 接口信令的典型操作步骤。# 假设你已经通过端口镜像或 TDM 采集卡抓到了 A 接口的 MTP2 数据 # 在 Wireshark 中打开捕获文件先设置解码规则 # 1. 打开 Wireshark进入 Analyze - Decode As # 2. 把 MTP2 的 payload 解码为 MTP3 # 3. 把 MTP3 的 payload 解码为 SCCP # 4. 把 SCCP 的 payload 解码为 BSSAP 或 MAP # 5. 如果 SSN6 解码为 MAPSSN8 解码为 BSSAP逻辑说明Wireshark 默认可能把 MTP2 之上的数据识别为其他协议需要手动指定解码链。参数说明MTP2 的 FCS 校验如果失败Wireshark 会标红这时候先检查采集卡是否丢帧SCCP 的 SSN 字段在解码后可以直接看到如果 SSN 不是预期的 6/7/8说明路由配置可能有问题。提示抓 A 接口信令时如果只抓到一个方向的消息先检查采集卡的收发方向是否都配置了。单向抓包会导致流程分析时“只看到问看不到答”。3. 信令流程实战呼叫、位置更新与切换的逐条消息拆解3.1 呼叫建立流程从 Channel Request 到 Alerting讲义第 7 章讲 GSM 信令流程呼叫建立是最核心的一条。下面按消息顺序拆解。第一步MS 在 Um 接口发起 Channel RequestRR 消息请求一条信令信道。BTS 收到后通过 Abis 接口的 LAPD 链路向 BSC 发 Channel Required。BSC 分配信道后回 Channel Activation 给 BTSBTS 确认后MS 在分配的信道上发 SABMLAPDm 的建链请求BTS 回 UA无编号确认LAPDm 链路建立。第二步MS 发 CM Service RequestCM 消息里面包含 TMSI 或 IMSI、CM 业务类型比如移动主叫、紧急呼叫。BSC 通过 DTAP 把这条消息透传给 MSC。MSC 如果决定鉴权就发 Authentication RequestMAP 消息通过 BSC、BTS 到 MS。MS 用 SIM 卡里的 Ki 和 A3/A8 算法算出 Sres 和 Kc回 Authentication Response。MSC 比对 AUC 算出的 Sres一致则鉴权通过。第三步MSC 发 Cipher Mode Command要求 MS 进入加密模式。MS 回 Cipher Mode Complete。之后 MSC 发 TMSI Reallocation Command分配新的 TMSIMS 确认。第四步MS 发 SetupCM 消息包含被叫号码。MSC 收到后回 Call Proceeding然后根据被叫号码分析出局路由。如果出局到 PSTNMSC 发 IAMISUP 或 TUP 消息给对端交换机。对端回 ACM 后MSC 给 MS 发 Alerting主叫听到回铃音。被叫应答后对端发 ANCMSC 给 MS 发 ConnectMS 回 Connect Acknowledge通话建立。这个流程里每一步消息都有对应的定时器。比如 T3101 用于等待 Channel Activation 的确认T3103 用于切换过程中的信道保持T305 用于呼叫建立阶段的超时。讲义第 8 章专门讲定时器这些值在 MSC 和 BSC 的数据配置里可以查但调整需要非常谨慎——改大了可能导致资源长时间占用改小了可能导致正常流程被误判为超时。3.2 位置更新流程VLR 和 HLR 的交互细节位置更新是移动性管理的核心。当 MS 从一个 LA位置区移动到另一个 LA或者周期性位置更新定时器超时MS 会发起 Location Updating Request。消息路径MS - BTS - BSC - MSC/VLR。VLR 收到后如果发现 TMSI 不是自己分配的或者没有该用户的上下文就向 HLR 发 Update LocationMAP 消息。HLR 收到后把用户的签约数据插入 VLRInsert Subscriber DataVLR 确认后HLR 回 Update Location Acknowledge里面包含用户的 IMSI 和签约业务。VLR 再给 MS 发 Location Updating Accept并分配新的 TMSI。这里有个关键点HLR 和 VLR 之间的 MAP 消息走 SCCP 无连接服务但消息里携带的 TCAP 事务 ID 必须匹配。如果抓包看到 Update Location 发出去了但 HLR 没有回 Insert Subscriber Data先检查 SCCP 的 DPC 和 SSN 是否正确——HLR 的 SSN 是 6如果错配成 7消息就送到 VLR 去了。3.3 切换流程BSC 间切换的信令交互切换分多种同一 BSC 内的切换、BSC 间的切换、MSC 间的切换。讲义里重点讲了 BSC 间切换。当 MS 上报的测量报告显示邻区信号更好BSC 决定发起切换。源 BSC 向 MSC 发 Handover RequiredBSSMAP 消息里面包含目标小区 ID。MSC 向目标 BSC 发 Handover Request目标 BSC 分配信道后回 Handover Request Acknowledge。MSC 再向源 BSC 发 Handover Command源 BSC 通过 Um 接口告诉 MS 切换到目标信道。MS 切换到目标 BSC 后发 Handover Complete目标 BSC 通知 MSCMSC 释放源 BSC 的资源。这个流程里T3103 定时器在源 BSC 侧启动等待 Handover Complete。如果超时源 BSC 会释放信道但 MS 可能已经切过去了——这时候会出现“掉话”但信令上显示切换完成。排查这种问题需要同时看源 BSC 和目标 BSC 的信令跟踪。注意切换成功率低不一定是无线问题。如果 Handover Required 发出后 MSC 没有回 Handover Request先查 MSC 的局数据——目标小区是否在 MSC 的切换允许列表里。4. 避坑与排查信令分析中最容易翻车的五个点4.1 抓包位置不对看到的消息全是“半截”现象抓到的信令流程只有上行没有下行或者只有 DTAP 没有 BSSMAP。原因采集点选在了 BSC 和 MSC 之间的某一段但 A 接口的信令是双向的如果只镜像了一个方向或者 TDM 采集卡的收发端口配置反了就会丢一半。解决抓包前先用已知的正常呼叫验证采集点确认上下行都能看到。如果是 IP 化后的 A 接口检查镜像端口是否配置了 both。4.2 SCCP 的 SSN 配错消息送到错误的网元现象Update Location 发出后HLR 没有响应但 SCCP 层显示消息已送达。原因MSC 里配置的 HLR 点码对应的 SSN 不是 6而是其他值。解决在 MSC 的七号信令数据里查 HLR 的 SSN 配置标准值是 6。同样VLR 的 SSN 是 7MSC 的是 8。如果 SSN 错SCCP 层可能仍然完成路由但上层协议无法处理。4.3 定时器 T3101 设置过短正常流程被误判超时现象呼叫建立成功率突然下降信令跟踪显示 Channel Activation 后 BTS 还没回确认BSC 就发了 Channel Release。原因T3101 设置过短BTS 在忙时处理慢正常流程被误判为超时。解决查 BSC 的定时器配置T3101 的典型值是 10 秒如果设成 3 秒忙时必然出问题。调整前先统计 BTS 的响应时间分布。4.4 ISUP 的 IAM 消息里 CIC 冲突导致呼叫串线现象用户投诉“打 A 号码接通了 B 号码”。原因MSC 出局的 ISUP 中继上CIC电路识别码配置冲突两个呼叫占用了同一个 CIC。解决查 MSC 的中继电路数据确保每个 CIC 在同一个中继群内唯一。抓包时看 IAM 消息里的 CIC 字段如果两个 IAM 的 CIC 相同且时间接近基本可以确认。4.5 鉴权失败但用户仍能起呼原因是 AUC 和 SIM 卡的 Ki 不一致现象鉴权流程显示 Authentication Response 的 Sres 和 MSC 算出的不一致但用户偶尔能起呼。原因AUC 里存的 Ki 和 SIM 卡里的 Ki 不匹配但某些 MSC 配置了“鉴权失败允许紧急呼叫”或“鉴权失败尝试次数”参数导致部分呼叫放行。解决核对 AUC 和 SIM 卡的 Ki如果批量不一致联系卡商重新写卡。同时检查 MSC 的鉴权失败处理策略生产环境不建议放行鉴权失败的非紧急呼叫。5. 从定时器到消息内容把信令分析做成可复用的排查习惯讲义第 8 章和第 9 章的内容是很多人的盲区。定时器不是孤立的值它和消息流程是绑定的。比如 T305 在呼叫建立阶段启动如果 MSC 发出 Setup 后 MS 没有回 Call ConfirmedT305 超时后 MSC 会发 Release Complete。但如果你只看到 Release Complete不知道 T305 的存在就会误以为是 MS 主动拆线。我自己的习惯是每分析一个异常流程先把涉及的定时器列出来然后对照消息时间戳看哪个定时器先超时。下面这张表是我常用的定时器对照基于讲义内容和常见工程配置整理。定时器启动位置典型值超时后果T3101BSC10s释放已分配的信道T3103BSC10s切换失败释放源信道T305MSC30s呼叫建立失败发 Release CompleteT308MSC20s释放呼叫发 ReleaseT3192MS5s位置更新失败重新尝试重要信令消息的内容详解讲义第 9 章讲得比较细。这里补充一个实操技巧用 Wireshark 的“Apply as Filter”功能把 Authentication Request 的 Sres 字段过滤出来和 AUC 的预期值比对。如果 Sres 长度不对正常是 4 字节说明 A3 算法实现有问题。另外Identity Request 里的 Identity Type 字段如果值是 1 表示 IMSI2 表示 IMEI3 表示 IMEISV。排查“设备合法性检查”时看 Identity Type 和后续的 Identity Response 是否匹配。最后一个技巧把常用信令流程做成 Wireshark 的 Coloring Rule。比如把 Release Complete 标红把 Handover Required 标黄把 Location Updating Request 标绿。这样打开一个抓包文件异常流程一眼就能看到。从那以后我每次分析信令都强制先跑一遍 Coloring Rule再开始逐条看消息——这个习惯帮我省了至少一半的排查时间。希望帮到你。本文还有配套的精品资源点击获取