企业官网建设流程全解析

简介：这是一份上海大唐移动通信设备有限公司出品的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.7），BSC 与 BTS 之间走 LAPD，BTS 与 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 两半。

这套映射关系是信令分析的地基。新手最容易翻车的地方在 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 层的功能在 MSC 一侧实现，最容易被误认为是 BSC 的问题。CM 层是最高层，子层里 CC 管呼叫的建立、维持和清除，SS 管补充业务，SMS 管短消息。判断一条信令异常属于哪个层，可以先看消息落在哪个子层：RR 层消息异常，重点查 BSC 参数和无线资源；MM 层异常，重点查鉴权、位置更新相关的 MSC / VLR 配置和 SIM 卡状态；CC 层异常，重点查呼叫路由和号码分析。

2.3 消息清单当索引用：RR、MM、CC、BTSM、BSSMAP 的代表消息

讲义里给了五个消息列表，很多人翻过去就完了，其实这是最实用的索引。我把每层挑几条代表消息，对应到现网里最常见的场景，排查时按这张表反查消息名，比临时翻协议快得多。

使用这份清单的方法是按层反查：主叫拨号后没有回铃，先查 CC 层有没有 Setup 和 Alerting；位置更新被拒绝，到 MM 层找 Location Update Reject，并看 reject cause 是 2、3 还是 4；TCH 指配不起，去 BSSMAP 查 Assignment Request 之后有没有 Assignment Failure，failure cause 指向拥塞还是无线接口失败。讲义把这些消息名整理成表，省去了逐条翻规范确认缩写含义的功夫。

3. 三大核心流程：主叫、被叫、位置更新的消息序列对照

把协议栈的骨架立起来之后，再进流程就顺了。讲义的核心章节是移动主叫、移动被叫、位置更新、切换。主叫被叫是日常投诉最多的场景，位置更新是影响寻呼成功率的关键，先把这三个流程的消息序列背熟，再做切换。

3.1 移动主叫：从 Channel Request 到 Connect ACK

移动主叫的完整链路由接入、鉴权加密、TCH 指配、接通与释放四段组成，每段都有独立的失败点。第一步是随机接入，MS 在 RACH 上发 Channel Request，BTS 收到后通过 Abis 口向 BSC 上报 Channel Required，BSC 分配 SDCCH 并下发激活命令，BTS 在 AGCH 上回 Immediate Assignment，MS 转到 SDCCH 并建立 LAPDm 连接。这个阶段失败，要么是 Channel Request 根本没到 BTS，要么是 SDCCH 拥塞导致 Immediate Assignment Reject。

之后 MS 在 SDCCH 上发 CM Service Request，BSC 打包透传给 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 Command，MS 切到 TCH 后回 Assignment Complete。这一步是整个主叫流程里最值得盯的一段，TCH 分配失败往往表现为 Assignment Failure，原因是目标载频拥塞或干扰。之后 MSC 向 MS 发 Alerting（被叫振铃）、Connect、MS 回 Connect ACK，通话建立，挂断时按 Disconnect → Release → Release Complete 的顺序释放。

主叫流程还有一个隐形的第二步分配：SDCCH 先分配一次，确认身份后再分配 TCH，中间如果不停做加密和鉴权，SDCCH 占用时间会拖长。优化时可以看 CM Service Request 到 Assignment Command 之间用了多少条 DTAP 消息，消息越多，呼叫建立时延越大。

3.2 移动被叫：寻呼怎么落地，比主叫多了哪一段

被叫流程和主叫最大的差别是开头：MSC 通过 BSSMAP 下发 Paging，BSC 把这个寻呼命令分散到 MS 所在位置区的所有小区，BTS 在 PCH 上广播寻呼消息。MS 收到寻呼后，在 RACH 上发 Paging Response，后续鉴权、加密、TCH 指配基本与主叫相同。但 Setup 的方向反了——被叫侧是从 MSC 到 MS，而且 MS 回的是 Call Confirmed 而不是 Call Proceeding，MSC 要等被叫用户应答，所以 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 失联。

位置更新被拒绝是投诉里常见的一种情况。Location Update Reject 一般带 cause 值，3 表示 illegal MS，6 表示 illegal ME，2 表示位置区不允许。看到 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 Command，MS 切到目标小区后，目标 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 指向另一个小区。定向重试的参数与目标小区的选择策略强相关，如果参数配置激进，会导致话务被大量疏导到邻小区，形成新的拥塞点。

下表把四类切换的信令特征做个对照，排查时先对号入座再下手。

5. 信令分析避坑指南：五个我踩过的“假结论”现场

信令分析有一个尴尬的属性：消息摆在那里，但解读方式不同，结论差很远。以下五条都是我实际遇到过的误判，每一条都值得记下来。

5.1 只看网络层消息，不看链路层重传，把网络层失败误判为无线差

现象：某小区 TCH 指配失败率持续偏高，无线环境测试正常，网络层看到 Assignment Failure，cause 为无线接口失败。原因：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 内部被丢弃。三层把故障层限定，两段把故障点定位，这套顺序下来基本不存在“不知道从哪查起”的情况。

那份讲义里每一种流程都能在信令分析工具里找到对应的实例，真正要做到的是拿到一条失败信令时，先按三层两段法把消息排队，而不是一上来就看直观的失败消息。从那以后，我每次拿到一条失败信令，不管问题多急，都强制先走一遍这个顺序，再下结论。希望帮到你。

本文还有配套的精品资源，点击获取