简介这份文档面向移动通信与 GSM 网络协议的学习者、工程师及通信专业学生聚焦 Um 接口协议这一 MS 与 BTS 之间的关键无线接口规范帮助读者理解信令在空口上的传输机制与协议分层设计。资源为单个 PDF 文档压缩包体积约 15KB内容围绕 LapDm 协议与 RR 协议展开。文中系统讲解了 LapDm 与 LapD 的差异包括 23 字节与 SACCH 上 21 字节的帧长限制、填充值 00101011 的作用、分段与重组所用的附加位、260 字节的报文长度约束以及不确认与确认两种纠错模式和窗口大小恒为 1 的发送—等待机制并说明 SAPI0 信令流与 SAPI3 短消息流的区分。RR 协议部分则涵盖空闲模式下的系统信息广播、寻呼、MS 信道请求与立即指配等过程以及 SACCH 上的测量报告与短消息传送。目前已有 194 人学习适合需要夯实 GSM 空口协议基础、查阅接口细节的读者参考。1. 为什么 LAPDm 只有 23 字节却撑起了整个 GSM 空口信令很多人第一次翻 GSM 的 Um 接口资料看到 LAPDm 帧最大只有 23 字节、窗口固定为 1、还不做前向纠错直觉是这也太简陋了。但把整条链路摆出来看就明白了MS 和 BTS 之间的介质是无线接口不是 64Kb/s 的电路物理层已经用卷积编码、交织和块校验把可靠性做掉了大半链路层如果再做一遍纠错纯属重复劳动。LAPDm 的设计哲学就是只做该做的——分段重组、确认/不确认两种模式、SAPI 多流复用剩下的交给底层。这份《GSM协议 Um接口协议》文档把 LAPDm 和 RR 两层讲得比较完整从帧结构、填充图案、SAPI0/SAPI3 的允许组合到系统信息广播、寻呼、立即指配、切换、加密模式设置、类标更新这一整套 RR 过程还提到了 MM 和 CC 两层的位置。它适合做网优、核心网信令分析、或者要从零理解空口流程的人读完之后你在 Wireshark 里抓到一条 Channel Request能说清它在 Abis 侧变成了什么、BSC 又是怎么回 Immediate Assignment 的。下面按链路层怎么搭 → RR 空闲态怎么走 → RR 专用态怎么走 → 怎么抓包验证的顺序拆下去。2. LAPDm 帧结构、分段重组与 SAPI 复用2.1 23 字节从哪里来填充值为什么是 00101011Um 接口的物理层已经把同步信息带过来了所以 LAPDm 不需要 HDLC 那套 0x7E 帧起始/结束标志也不需要比特填充。它直接借用物理层的块边界一个 LAPDm 帧塞进一个物理块长度 23 字节。到了 SACCH 上只剩 21 字节少掉的两个字节被时间提前量和发送功率控制占用——这两个量每个 SACCH 块都必须带。帧里有效信息未必填满所以要有一个长度指示器告诉对端读到哪为止。剩下的用缺省填充值001010110x2B补齐。这个值不是随便挑的如果一帧信息很少、填充很长重复的填充图案可能长得像 FCCH 的频率校正突发而 FCCH 是 MS 用来做同步的后果就是干扰正在找网的小区。历史上行链路还保留11111111作为填充图案属于兼容遗留。信道类型帧最大长度特殊占用字节典型用途TCH/F、TCH/H 上的 FACCH23 字节无快速随路信令抢占业务块SACCH21 字节时间提前量 功控测量报告、SI5/5bis/6SDCCH23 字节无呼叫建立、鉴权、位置更新2.2 附加位怎么做分段重组260 字节是哪来的21 或 23 字节装不下一条 RR 消息所以 LAPDm 必须分段。它靠一个附加位More bit区分这帧后面还有和这是最后一帧置位表示后续还有帧清零表示报文结束。接收端按顺序拼接中间不需要长度协商也不需要重传整条消息——哪个分片错了就重发哪个。拼完之后长度上限不是 23 的整数倍而是 260 字节。原因在于同一条消息还要经过 Abis、A 接口转发那些接口的规范对单条消息长度有约束无线侧的 260 字节就是跟着那个约束定的。写分段代码的时候别按 23 字节硬切最后一段要保证分片边界和 More bit 一致否则对端拼出来的是半条消息。2.3 确认/不确认模式与窗口大小 1 的取舍LAPDm 不用前向纠错走的是类似 HDLC 的后向纠错两种模式不确认模式UI 帧只发一次不管对端收没收到适合系统信息广播这类丢了也无所谓反正周期性重发的场景。确认模式I 帧靠重传纠正错误帧用于需要可靠传输的信令和短消息。计数周期是 8但窗口大小恒为 1等价于最简单的发送-等待协议发一帧等应答收到再发下一帧。SDCCH 上这么做不吃亏因为信道编排本身就是交替的接收帧和下一个发送机会之间留足了组应答的时间。换到 TCH/F 上就是另一回事了——每 120ms 才有一个信令帧的机会连续几帧的分段消息会被这个一发一等拖慢实际速率不会比 SDCCH 好过两倍。注意窗口为 1 不是配置项是协议常量。看到资料说可以调大窗口先确认是不是把 LAPD 或别的链路层协议混进来了。2.4 SAPI0 与 SAPI3两条独立流怎么共存一条信道上可以同时跑两条互不干扰的流用 SAPI 区分SAPI0 传信令报文SAPI3 传短消息。二者的模式组合不是随便配的下面这张表是文档里给出的允许情况。信道类型SAPI0信令SAPI3短消息TCH/F确认模式不允许SDCCH确认模式确认模式SACCH不确认模式确认模式SACCH 上的 SAPI0 之所以是不确认模式是因为 SACCH 承载的是周期性测量报告和系统信息丢了等下一轮即可重传反而浪费本就稀缺的 SACCH 容量。空闲时如果确实没东西发就发一条信息长度为 0 的 UI 帧当填充帧保持链路活跃感。链路建立和释放走的都是固定两条消息的简单过程没收到完成交换之前上层信息不允许下传。3. RR 空闲模式从系统信息广播到立即指配3.1 BCCH 系统信息的分层组装与广播周期空闲态的第一步是让 MS 知道这个小区能不能用、怎么用。BSC 负责组装 SYSTEM INFORMATION TYPE 1、2、2bis、2ter、3、4以及可选的 7、8、13、15、16、17放到 Abis 接口的 BCCH Information 消息里发给 BTSBTS 再在 BCCH 上周期性地吐出去。注意分工内容的决定权在 BSC节拍由 BTS 控制BSC 不参与每次定时发送。排查MS 不选这个小区的问题时通常要看 SI3 里的 cell selection 参数和 SI2 里的邻区频点列表是否下发完整。一个常见做法是在 BTS 侧确认 BCCH Information 是否真的收到了、是否带全了 SI2ter而不是一上来就怀疑天线。3.2 寻呼链路BSSMAP → Abis → PCH 的消息变形MSC 要寻呼某个 MS先在 A 接口发 BSSMAP 的 Paging 给 BSCBSC 把它包进 Abis 的 Paging Command 发给一个或多个 BTS消息里带 TMSI 或 IMSI 作为 MS 标识BTS 最后在 PCH 上用 Paging Request 发出去。一条寻呼消息在三个接口上有三个名字形状也在变但 MS 标识是贯穿始终的锚点。抓包验证时如果 A 口能看到 Paging、Abis 口看不到 Paging Command问题多半在 BSC 的寻呼分发逻辑或某个 BTS 的寻呼组配置如果 Abis 发出了但 MS 没响应就要看 paging group 和 DRX 参数是否匹配。3.3 信道请求、Abis 封装与立即指配的完整落地MS 主动发起呼叫、位置更新或被动响应寻呼之后在 RACH 上发 Channel Request。BTS 检测到就在 Abis 的 Channel Required 里包一层送给 BSC。BSC 收到后做的动作是三步争取一条可用信道、把信道激活、发 Immediate Assign Command 给 BTS——这条命令里装的是完整的 Um 接口 RR 层消息即 Immediate Assignment、Immediate Assignment Extended或者没信道可用时的 Immediate Assignment Reject。BTS 只负责在 CCCH 的时机上把它发出去。BSC 侧的信道激活可以这样理解以常见的 Abis 层 3 流程为例# 在 BSC 网管/维护终端上查看某小区的信道激活与立即指配计数 # 具体命令名随设备厂商不同这里给出的是排查思路对应的字段 show cell cell_id channel-usage # 看 SDCCH 占用率判断是否被占满 show stats immediate-assignment cell_id # 统计 IA 成功/拒绝次数第一行的作用是确认 SDCCH 是否被占满导致无信道可分第二行是看 Immediate Assignment Reject 的比例。如果拒绝率持续偏高常见根因是 SDCCH 配置条数不足或接入突发过多而不是空口覆盖差。把这两组数据和 A 口的 Assignment Request 时间点对齐就能区分没信道和MS 没收到。一旦 BSC 决定把 SDCCH 换成 TCH会先做 Abis 层 3 的物理上下文请求和信道激活再通过 SDCCH 下发 RR 消息 Assignment CommandMS 在新信道建链成功后回 Assignment CompleteBSC 再往 MSC 回 BSSMAP 的 Assignment Complete。整条链路只有最后那一步看着像切换信道前面全是准备工作。4. RR 专用模式切换、加密与类标管理4.1 跨 BSC 切换的四方消息流转专用态最复杂的过程是跨 BSC 切换。旧 BSC 决定发起时发 BSSMAP 的 Handover Required 给所属 MSC消息里带目标小区。MSC 在新 BSC 建好信道后回 Handover Command 给旧 BSC里面装一条 Um 接口 RR 层的 Handover Command由旧 BSC 在旧信道上发给 MS。新 BSC 那一侧收到 MSC 的 Handover Request分配并激活信道组装 RR 层 Handover Command 塞进 A 口应答 Handover Request Acknowledge 返回。MS 切过去的过程里可能先发 Handover Access 突发建链成功后发 Handover Complete新 BSC 用 BSSMAP 的 Handover Complete 通知 MSC。失败路径有两条切换失败但 MS 回到旧信道MS 在旧信道上发 Handover Failure切换失败且回不来旧 BSC 收到 MSC 的清除命令。分析切换掉话时重点看新 BSC 是否收到了 Handover Access 却始终没等到 Handover Complete——那通常是目标小区上行干扰或时间提前量配错。4.2 加密模式设置上下行什么时候开始换钥MSC 决定改加密模式时A 口下发 BSSMAP 的 Cipher Mode Command 给 BSC。BSC 向 BTS 发 Encryption Command里面既包含 BTS 要用的全部信息也带一条完整的 Um 接口 RR 层 Ciphering Mode Command——因为加密要双方都掌握参数BTS 必须先以原加密模式把这条消息透传给 MS传完之后才开始启动新的上行解密。MS 收到后同时启动新加密上行和新解密下行回 Ciphering Mode Complete。BTS 只要正确解出任意一条新加密模式下的报文就说明 MS 切过来了于是把自己的下行发送也切到新密钥收到 Ciphering Mode Complete 后放进 Abis 的 Data Indication 交给 BSC作为肯定应答。注意这个过程的顺序很敏感。BTS 提前切下行加密MS 会解不出来滞后切MS 已经切完了 BTS 却在用旧钥表现为单通或立即掉话。4.3 频率重定义、信道模式修改与半速率信道增删频率重定义用于 BSC 要改 BTS 频点或跳频参数、又不想打断在跑的业务的场景。它给 MS 发 Frequency Redefine说明什么时刻开始变成什么频点到点后 BTS 和 MS 同时调整业务不中断。通知 BTS 不走 Abis 层 3 消息而是走 BSC 到 BTS 的 OM 通道。信道模式修改比如话音转数据从 A 口的 Assignment Request 开始BSC 同时发两条给 BTS 的 Mode Modify给 MS 的 RR 层 Channel Mode Modify。BTS 改完回 Mode Modify AcknowledgeMS 改完回 Channel Mode Modify Acknowledge两边都齐了 BSC 才回 Assignment Complete 给 MSC。附加信道指配和部分信道释放是一对反向操作前者把 TCH/H ACCH 扩成 TCH/H TCH/H ACCHsMS 激活新增的 TCH/H 后回 Assignment Complete后者把两信道缩回单信道MS 释放在被释放信道上的底层连接、在剩下信道上重建然后在主 TCH/H 上回 Partial Release Complete。两者都不中断原有业务实现的关键是先建后拆。过程Um 接口消息Abis/A 接口对应中断风险点信道模式修改Channel Mode ModifyMode Modify / Assignment Request两侧应答未齐就上报完成附加信道指配Additional Assignment信道激活 Assignment Complete新信道激活失败部分信道释放Partial Release无独立 Abis 消息释放侧连接未迁移完成4.4 类标改变与询问的双向触发类标是 MS 能力频段、功率等级、加密算法支持的声明走两条路。一条是 MS 自发专用模式下如果 BCCH 系统信息要求上报或者 MS 自身类标变了MS 尽快用 RR 层 Classmark Change 通知网络BSC 收到后发 BSSMAP 的 Classmark Update 给 MSC。另一条是 MSC 主动问MSC 发 Classmark RequestBSC 转成 RR 层 Classmark Enquiry 发给 MSMS 回 Classmark ChangeBSC 再用 Classmark Update 通知 MSC。给 MS 配错类标最典型的后果是该用某加密算法时用不了、或者功率控制按错误的等级下发表现是特定机型在特定小区接入困难。核对方法就是在 A 口把 Classmark Update 的内容和机型实际能力比对一遍。5. 抓包定位 LAPDm/RR 问题的几个技巧5.1 用 SAPI 和信道类型先做分流抓包环境下面临的第一个问题是数据太杂。有效的办法是先按信道类型和 SAPI 分流SDCCH 上的 SAPI0 基本都是呼叫建立相关的确认模式帧SACCH 上的 SAPI0 是周期性测量报告和系统信息SAPI3 则专属于短消息。把 SAPI3 过滤掉之后剩下的信令帧序列会清爽很多。判定填充帧也有用信息长度为 0 的 UI 帧表示信道空闲但链路保持看到连续填充帧说明这段时间没有实际信令活动不必逐帧分析。# 常见过滤思路只看某条链路上的信令流排除短消息 # SAPI 字段取值 0 表示信令3 表示短消息 filter lapdm.sapi 0 and lapdm.channel ! sacch上面的过滤条件里lapdm.sapi 0把短消息流排掉channel ! sacch把周期性的测量报告和系统信息排掉剩下的就是呼叫建立、切换、加密这些一次性过程。分析掉话时先用这套过滤把整个流程的消息序列拉出来再从断点往前找最后一条没等到应答的消息。5.2 分段重组是否完整的判断方法确认模式下的分段报文判断完整性靠两条一是 More bit 序列是否连续前面全是置位最后一条清零二是拼起来的字节数是否等于长度指示器之和减去填充。如果中间丢了一帧重传会补上但如果重传始终不成功导致链路释放你会在抓包里看到同一序号反复出现后直接跳到释放过程。一个常被忽略的坑是填充值判断00101011和上行遗留的11111111都可能出现在有效数据里不能纯靠内容识别填充必须严格按长度指示器截断。写解析脚本时先读长度指示器再按这个长度取有效载荷剩下的直接忽略.5.3 从 RR 连接释放反推故障根因RR 连接释放有三种触发源反推根因时先分清楚是哪一种。第一种是 MSC 下发 BSSMAP 的 Clear CommandBSC 用 RR 层 Channel Release 命令 MS 释放同时启动 SACCH 去激活再回 Clear Complete 给 MSC之后走链路释放指示、无线信道释放最后在 A 口完成 SCCP 断链。这种是网络主动清通常有明确的上层原因。第二种是 BTS 检测到与 MS 的连接已经失败通过 Abis 的连接失败过程通知 BSCBSC 向 MSC 发 Clear Request 请求释放。这条路径上不涉及任何 RR 层消息如果只盯空口抓包会完全看不到原因必须把 Abis 侧的数据一起拉进来对齐时间戳。第三种是 BSS 因其他原因主动释放同样发 Clear Request 给 MSC。把三种释放路径和前面 RR 过程的完成情况对起来看就能快速判断是空口覆盖问题、参数配置问题还是上层主动干预。MM 和 CC 两层的消息都跑在这条已经建好的 RR 连接之上所以 RR 层一旦定位清楚上层的异常往往就是结果而不是原因。本文还有配套的精品资源点击获取 23字节LAPDm如何撑起GSM空口RR信令全流程
简介这份文档面向移动通信与 GSM 网络协议的学习者、工程师及通信专业学生聚焦 Um 接口协议这一 MS 与 BTS 之间的关键无线接口规范帮助读者理解信令在空口上的传输机制与协议分层设计。资源为单个 PDF 文档压缩包体积约 15KB内容围绕 LapDm 协议与 RR 协议展开。文中系统讲解了 LapDm 与 LapD 的差异包括 23 字节与 SACCH 上 21 字节的帧长限制、填充值 00101011 的作用、分段与重组所用的附加位、260 字节的报文长度约束以及不确认与确认两种纠错模式和窗口大小恒为 1 的发送—等待机制并说明 SAPI0 信令流与 SAPI3 短消息流的区分。RR 协议部分则涵盖空闲模式下的系统信息广播、寻呼、MS 信道请求与立即指配等过程以及 SACCH 上的测量报告与短消息传送。目前已有 194 人学习适合需要夯实 GSM 空口协议基础、查阅接口细节的读者参考。1. 为什么 LAPDm 只有 23 字节却撑起了整个 GSM 空口信令很多人第一次翻 GSM 的 Um 接口资料看到 LAPDm 帧最大只有 23 字节、窗口固定为 1、还不做前向纠错直觉是这也太简陋了。但把整条链路摆出来看就明白了MS 和 BTS 之间的介质是无线接口不是 64Kb/s 的电路物理层已经用卷积编码、交织和块校验把可靠性做掉了大半链路层如果再做一遍纠错纯属重复劳动。LAPDm 的设计哲学就是只做该做的——分段重组、确认/不确认两种模式、SAPI 多流复用剩下的交给底层。这份《GSM协议 Um接口协议》文档把 LAPDm 和 RR 两层讲得比较完整从帧结构、填充图案、SAPI0/SAPI3 的允许组合到系统信息广播、寻呼、立即指配、切换、加密模式设置、类标更新这一整套 RR 过程还提到了 MM 和 CC 两层的位置。它适合做网优、核心网信令分析、或者要从零理解空口流程的人读完之后你在 Wireshark 里抓到一条 Channel Request能说清它在 Abis 侧变成了什么、BSC 又是怎么回 Immediate Assignment 的。下面按链路层怎么搭 → RR 空闲态怎么走 → RR 专用态怎么走 → 怎么抓包验证的顺序拆下去。2. LAPDm 帧结构、分段重组与 SAPI 复用2.1 23 字节从哪里来填充值为什么是 00101011Um 接口的物理层已经把同步信息带过来了所以 LAPDm 不需要 HDLC 那套 0x7E 帧起始/结束标志也不需要比特填充。它直接借用物理层的块边界一个 LAPDm 帧塞进一个物理块长度 23 字节。到了 SACCH 上只剩 21 字节少掉的两个字节被时间提前量和发送功率控制占用——这两个量每个 SACCH 块都必须带。帧里有效信息未必填满所以要有一个长度指示器告诉对端读到哪为止。剩下的用缺省填充值001010110x2B补齐。这个值不是随便挑的如果一帧信息很少、填充很长重复的填充图案可能长得像 FCCH 的频率校正突发而 FCCH 是 MS 用来做同步的后果就是干扰正在找网的小区。历史上行链路还保留11111111作为填充图案属于兼容遗留。信道类型帧最大长度特殊占用字节典型用途TCH/F、TCH/H 上的 FACCH23 字节无快速随路信令抢占业务块SACCH21 字节时间提前量 功控测量报告、SI5/5bis/6SDCCH23 字节无呼叫建立、鉴权、位置更新2.2 附加位怎么做分段重组260 字节是哪来的21 或 23 字节装不下一条 RR 消息所以 LAPDm 必须分段。它靠一个附加位More bit区分这帧后面还有和这是最后一帧置位表示后续还有帧清零表示报文结束。接收端按顺序拼接中间不需要长度协商也不需要重传整条消息——哪个分片错了就重发哪个。拼完之后长度上限不是 23 的整数倍而是 260 字节。原因在于同一条消息还要经过 Abis、A 接口转发那些接口的规范对单条消息长度有约束无线侧的 260 字节就是跟着那个约束定的。写分段代码的时候别按 23 字节硬切最后一段要保证分片边界和 More bit 一致否则对端拼出来的是半条消息。2.3 确认/不确认模式与窗口大小 1 的取舍LAPDm 不用前向纠错走的是类似 HDLC 的后向纠错两种模式不确认模式UI 帧只发一次不管对端收没收到适合系统信息广播这类丢了也无所谓反正周期性重发的场景。确认模式I 帧靠重传纠正错误帧用于需要可靠传输的信令和短消息。计数周期是 8但窗口大小恒为 1等价于最简单的发送-等待协议发一帧等应答收到再发下一帧。SDCCH 上这么做不吃亏因为信道编排本身就是交替的接收帧和下一个发送机会之间留足了组应答的时间。换到 TCH/F 上就是另一回事了——每 120ms 才有一个信令帧的机会连续几帧的分段消息会被这个一发一等拖慢实际速率不会比 SDCCH 好过两倍。注意窗口为 1 不是配置项是协议常量。看到资料说可以调大窗口先确认是不是把 LAPD 或别的链路层协议混进来了。2.4 SAPI0 与 SAPI3两条独立流怎么共存一条信道上可以同时跑两条互不干扰的流用 SAPI 区分SAPI0 传信令报文SAPI3 传短消息。二者的模式组合不是随便配的下面这张表是文档里给出的允许情况。信道类型SAPI0信令SAPI3短消息TCH/F确认模式不允许SDCCH确认模式确认模式SACCH不确认模式确认模式SACCH 上的 SAPI0 之所以是不确认模式是因为 SACCH 承载的是周期性测量报告和系统信息丢了等下一轮即可重传反而浪费本就稀缺的 SACCH 容量。空闲时如果确实没东西发就发一条信息长度为 0 的 UI 帧当填充帧保持链路活跃感。链路建立和释放走的都是固定两条消息的简单过程没收到完成交换之前上层信息不允许下传。3. RR 空闲模式从系统信息广播到立即指配3.1 BCCH 系统信息的分层组装与广播周期空闲态的第一步是让 MS 知道这个小区能不能用、怎么用。BSC 负责组装 SYSTEM INFORMATION TYPE 1、2、2bis、2ter、3、4以及可选的 7、8、13、15、16、17放到 Abis 接口的 BCCH Information 消息里发给 BTSBTS 再在 BCCH 上周期性地吐出去。注意分工内容的决定权在 BSC节拍由 BTS 控制BSC 不参与每次定时发送。排查MS 不选这个小区的问题时通常要看 SI3 里的 cell selection 参数和 SI2 里的邻区频点列表是否下发完整。一个常见做法是在 BTS 侧确认 BCCH Information 是否真的收到了、是否带全了 SI2ter而不是一上来就怀疑天线。3.2 寻呼链路BSSMAP → Abis → PCH 的消息变形MSC 要寻呼某个 MS先在 A 接口发 BSSMAP 的 Paging 给 BSCBSC 把它包进 Abis 的 Paging Command 发给一个或多个 BTS消息里带 TMSI 或 IMSI 作为 MS 标识BTS 最后在 PCH 上用 Paging Request 发出去。一条寻呼消息在三个接口上有三个名字形状也在变但 MS 标识是贯穿始终的锚点。抓包验证时如果 A 口能看到 Paging、Abis 口看不到 Paging Command问题多半在 BSC 的寻呼分发逻辑或某个 BTS 的寻呼组配置如果 Abis 发出了但 MS 没响应就要看 paging group 和 DRX 参数是否匹配。3.3 信道请求、Abis 封装与立即指配的完整落地MS 主动发起呼叫、位置更新或被动响应寻呼之后在 RACH 上发 Channel Request。BTS 检测到就在 Abis 的 Channel Required 里包一层送给 BSC。BSC 收到后做的动作是三步争取一条可用信道、把信道激活、发 Immediate Assign Command 给 BTS——这条命令里装的是完整的 Um 接口 RR 层消息即 Immediate Assignment、Immediate Assignment Extended或者没信道可用时的 Immediate Assignment Reject。BTS 只负责在 CCCH 的时机上把它发出去。BSC 侧的信道激活可以这样理解以常见的 Abis 层 3 流程为例# 在 BSC 网管/维护终端上查看某小区的信道激活与立即指配计数 # 具体命令名随设备厂商不同这里给出的是排查思路对应的字段 show cell cell_id channel-usage # 看 SDCCH 占用率判断是否被占满 show stats immediate-assignment cell_id # 统计 IA 成功/拒绝次数第一行的作用是确认 SDCCH 是否被占满导致无信道可分第二行是看 Immediate Assignment Reject 的比例。如果拒绝率持续偏高常见根因是 SDCCH 配置条数不足或接入突发过多而不是空口覆盖差。把这两组数据和 A 口的 Assignment Request 时间点对齐就能区分没信道和MS 没收到。一旦 BSC 决定把 SDCCH 换成 TCH会先做 Abis 层 3 的物理上下文请求和信道激活再通过 SDCCH 下发 RR 消息 Assignment CommandMS 在新信道建链成功后回 Assignment CompleteBSC 再往 MSC 回 BSSMAP 的 Assignment Complete。整条链路只有最后那一步看着像切换信道前面全是准备工作。4. RR 专用模式切换、加密与类标管理4.1 跨 BSC 切换的四方消息流转专用态最复杂的过程是跨 BSC 切换。旧 BSC 决定发起时发 BSSMAP 的 Handover Required 给所属 MSC消息里带目标小区。MSC 在新 BSC 建好信道后回 Handover Command 给旧 BSC里面装一条 Um 接口 RR 层的 Handover Command由旧 BSC 在旧信道上发给 MS。新 BSC 那一侧收到 MSC 的 Handover Request分配并激活信道组装 RR 层 Handover Command 塞进 A 口应答 Handover Request Acknowledge 返回。MS 切过去的过程里可能先发 Handover Access 突发建链成功后发 Handover Complete新 BSC 用 BSSMAP 的 Handover Complete 通知 MSC。失败路径有两条切换失败但 MS 回到旧信道MS 在旧信道上发 Handover Failure切换失败且回不来旧 BSC 收到 MSC 的清除命令。分析切换掉话时重点看新 BSC 是否收到了 Handover Access 却始终没等到 Handover Complete——那通常是目标小区上行干扰或时间提前量配错。4.2 加密模式设置上下行什么时候开始换钥MSC 决定改加密模式时A 口下发 BSSMAP 的 Cipher Mode Command 给 BSC。BSC 向 BTS 发 Encryption Command里面既包含 BTS 要用的全部信息也带一条完整的 Um 接口 RR 层 Ciphering Mode Command——因为加密要双方都掌握参数BTS 必须先以原加密模式把这条消息透传给 MS传完之后才开始启动新的上行解密。MS 收到后同时启动新加密上行和新解密下行回 Ciphering Mode Complete。BTS 只要正确解出任意一条新加密模式下的报文就说明 MS 切过来了于是把自己的下行发送也切到新密钥收到 Ciphering Mode Complete 后放进 Abis 的 Data Indication 交给 BSC作为肯定应答。注意这个过程的顺序很敏感。BTS 提前切下行加密MS 会解不出来滞后切MS 已经切完了 BTS 却在用旧钥表现为单通或立即掉话。4.3 频率重定义、信道模式修改与半速率信道增删频率重定义用于 BSC 要改 BTS 频点或跳频参数、又不想打断在跑的业务的场景。它给 MS 发 Frequency Redefine说明什么时刻开始变成什么频点到点后 BTS 和 MS 同时调整业务不中断。通知 BTS 不走 Abis 层 3 消息而是走 BSC 到 BTS 的 OM 通道。信道模式修改比如话音转数据从 A 口的 Assignment Request 开始BSC 同时发两条给 BTS 的 Mode Modify给 MS 的 RR 层 Channel Mode Modify。BTS 改完回 Mode Modify AcknowledgeMS 改完回 Channel Mode Modify Acknowledge两边都齐了 BSC 才回 Assignment Complete 给 MSC。附加信道指配和部分信道释放是一对反向操作前者把 TCH/H ACCH 扩成 TCH/H TCH/H ACCHsMS 激活新增的 TCH/H 后回 Assignment Complete后者把两信道缩回单信道MS 释放在被释放信道上的底层连接、在剩下信道上重建然后在主 TCH/H 上回 Partial Release Complete。两者都不中断原有业务实现的关键是先建后拆。过程Um 接口消息Abis/A 接口对应中断风险点信道模式修改Channel Mode ModifyMode Modify / Assignment Request两侧应答未齐就上报完成附加信道指配Additional Assignment信道激活 Assignment Complete新信道激活失败部分信道释放Partial Release无独立 Abis 消息释放侧连接未迁移完成4.4 类标改变与询问的双向触发类标是 MS 能力频段、功率等级、加密算法支持的声明走两条路。一条是 MS 自发专用模式下如果 BCCH 系统信息要求上报或者 MS 自身类标变了MS 尽快用 RR 层 Classmark Change 通知网络BSC 收到后发 BSSMAP 的 Classmark Update 给 MSC。另一条是 MSC 主动问MSC 发 Classmark RequestBSC 转成 RR 层 Classmark Enquiry 发给 MSMS 回 Classmark ChangeBSC 再用 Classmark Update 通知 MSC。给 MS 配错类标最典型的后果是该用某加密算法时用不了、或者功率控制按错误的等级下发表现是特定机型在特定小区接入困难。核对方法就是在 A 口把 Classmark Update 的内容和机型实际能力比对一遍。5. 抓包定位 LAPDm/RR 问题的几个技巧5.1 用 SAPI 和信道类型先做分流抓包环境下面临的第一个问题是数据太杂。有效的办法是先按信道类型和 SAPI 分流SDCCH 上的 SAPI0 基本都是呼叫建立相关的确认模式帧SACCH 上的 SAPI0 是周期性测量报告和系统信息SAPI3 则专属于短消息。把 SAPI3 过滤掉之后剩下的信令帧序列会清爽很多。判定填充帧也有用信息长度为 0 的 UI 帧表示信道空闲但链路保持看到连续填充帧说明这段时间没有实际信令活动不必逐帧分析。# 常见过滤思路只看某条链路上的信令流排除短消息 # SAPI 字段取值 0 表示信令3 表示短消息 filter lapdm.sapi 0 and lapdm.channel ! sacch上面的过滤条件里lapdm.sapi 0把短消息流排掉channel ! sacch把周期性的测量报告和系统信息排掉剩下的就是呼叫建立、切换、加密这些一次性过程。分析掉话时先用这套过滤把整个流程的消息序列拉出来再从断点往前找最后一条没等到应答的消息。5.2 分段重组是否完整的判断方法确认模式下的分段报文判断完整性靠两条一是 More bit 序列是否连续前面全是置位最后一条清零二是拼起来的字节数是否等于长度指示器之和减去填充。如果中间丢了一帧重传会补上但如果重传始终不成功导致链路释放你会在抓包里看到同一序号反复出现后直接跳到释放过程。一个常被忽略的坑是填充值判断00101011和上行遗留的11111111都可能出现在有效数据里不能纯靠内容识别填充必须严格按长度指示器截断。写解析脚本时先读长度指示器再按这个长度取有效载荷剩下的直接忽略.5.3 从 RR 连接释放反推故障根因RR 连接释放有三种触发源反推根因时先分清楚是哪一种。第一种是 MSC 下发 BSSMAP 的 Clear CommandBSC 用 RR 层 Channel Release 命令 MS 释放同时启动 SACCH 去激活再回 Clear Complete 给 MSC之后走链路释放指示、无线信道释放最后在 A 口完成 SCCP 断链。这种是网络主动清通常有明确的上层原因。第二种是 BTS 检测到与 MS 的连接已经失败通过 Abis 的连接失败过程通知 BSCBSC 向 MSC 发 Clear Request 请求释放。这条路径上不涉及任何 RR 层消息如果只盯空口抓包会完全看不到原因必须把 Abis 侧的数据一起拉进来对齐时间戳。第三种是 BSS 因其他原因主动释放同样发 Clear Request 给 MSC。把三种释放路径和前面 RR 过程的完成情况对起来看就能快速判断是空口覆盖问题、参数配置问题还是上层主动干预。MM 和 CC 两层的消息都跑在这条已经建好的 RR 连接之上所以 RR 层一旦定位清楚上层的异常往往就是结果而不是原因。本文还有配套的精品资源点击获取