简介GSM网络中ABIS接口基站与基站控制器之间是无线通信的关键环节资源围绕其信令机制展开覆盖信令传输、数据传输、资源管理以及协议栈各层从物理层、第二层到第三层均有材料适合无线网络运维工程师、通信专业学生和信令分析人员借助其补全理论并对照实操。包体共99个文件、33.57MB以PDF规范文档和讲解为主另含32个hpp、20个cpp代码文件、3个doc笔记、rar压缩包等既有ITU-T Q系列标准原文也有ABIS信令流程与SCCP解码参考便于按需查阅。已有91人学习使用属于细分但专业性较强的资料集。通过文档与代码可系统学习E1/T1时隙分配、BSSAP消息解析、SCCP寻址等关键技能还可用于网络拥塞分析、干扰排查和基站—BSC通信异常定位是一份可直接落地的学习与排错参考。1. Abis 无线信令为什么值得从一堆乱码里翻出来“掉话先查 Abis别急着抓空口。” 这句话我第一次听时觉得反直觉后来连续两天被同一条路段的切出失败困住才明白 Abis 无线信令的价值。Abis 口夹在 BTS 和 BSC 之间相当于无线侧的腰空口上传不上来的干扰、控制信道过载、信道激活超时在 Abis 口都留了更完整、更早的证据。很多人拿到Abis.rar这类压缩包里面有解码文档、抓包片段和零星脚本却因为没人把解包、文件识别、字段解析串起来最后只当资料存了。这篇文章就把这套流程拆开讲从协议定位到最小可跑解析脚本再到踩坑记录给正在搞 GSM 无线优化、信令分析或者课程设计的从业者一条能直接复现的路。2. Abis 无线接口信令协议结构与抓包前的三张表2.1 从 Um 到 AAbis 在无线网络里的确切位置做优化的人都熟悉 Um 口因为大部分路测数据来自那里但 Um 口看到的是最终结果话质差、掉话、切出失败。真正的原因经常发生在空口之外比如 Abis 口时隙配置错误、LAPD 链路拥塞、RSL 消息没有按时隙送到指定 BTS。Abis 口是 GSM 网络里 BTS 到 BSC 的接口物理上常用 E1/T1 承载后来也有基于 IP 的组网方式但信令层面的结构没有本质变化。Abis 口传输的不只是信令还有 TCH 业务数据、OM 管理数据和同步信息。一个 2M 的 E1 上经常是几个 BTS 通过级联方式共用时隙划分随工程配置变化。这也是分析 Abis 口信令比分析 A 口信令麻烦的原因A 口消息按七号信令的格式来规整、好找Abis 口更像一块拼盘时隙、专用信道、LAPD 链路的关系必须拿到现场配置才能对齐。对无线网优来说Abis 口的价值在于它比空口更靠近控制器。空口上报的测量报告最终要透过 Abis 汇总到 BSC如果 Abis 把测量报告帧丢了BSC 就不够及时地做功率控制和切换判决。换句话说很多看起来是覆盖问题、干扰问题的现象根源可能是这段“腰”上出了问题这正是Abis.rar_Abis_abis 无线_信令这类资源会被反复搜索的原因。2.2 协议栈LAPD 负责搬运RSL 负责指挥Abis 信令链路层基本是 LAPD 协议它负责在一个 64kbps 的时隙上建立可靠连接、给消息排队、做重传。LAPD 的帧头里有 SAPI 和 TEI 两个关键值SAPI 区分承载的是信令还是分组数据TEI 区分不同的对端设备或逻辑终端。很多新手第一次打开 Abis 抓包会看到不少 SABME、UA、RR 这类帧那是 LAPD 在建立链路和保活并不承载业务内容。再往上一层是 RSL也就是无线信令链路控制协议。日常分析关心的信道激活、激活确认、测量报告、切换命令、信道释放都属于 RSL 层消息。RSL 消息不是裸的一条字符串它由协议鉴别语、消息类型、消息体以及若干信息元素IE组成。信息元素用编号标识常见的有信道号、TSC、训练序列码、测量结果向量等。解析时要抓的反而不是业务载荷而是这些 IE。如果拿到的 Abis 抓包里出现大量无法对应到 RSL 的帧先别急着怀疑软件漏解很可能是 LAPD 链路刚建立或者把 OM 管理消息混进来了。OM 消息同样走 LAPD但不属于无线信令范畴分析无线问题时应先按 SAPI 和消息类型筛掉。2.3 抓包前先列三张表时隙、TEI、消息类型我一般不会直接拿解码器去读整个 Abis 码流而是先用手边资料列三张映射表。第一张是物理时隙表每个 E1 时隙分别对应哪些载频、哪个逻辑信道信令链路落在哪个时隙上。这张表在压缩包里的配置文件里通常都有只是没人愿意去翻。第二张是 TEI/SAPI 表要清楚哪个 TEI 代表 BTS 侧哪个代表 BSC 侧SAPI 等于 0 和等于其他值时分别承载什么。第三张是消息类型表现场这次抓包里最关心的消息是信道激活、测量报告还是切换以及它们的正常时序。这三张表不需要多严格但能帮你少走一大截弯路。拿到一段 Abis 码流先回答三个问题这段码流来自哪条 E1 的哪个时隙对端的 TEI 是哪个期望看到的 RSLet消息类型有哪些答不上来就去查配置和协议文档不要硬解。表关键字段在 Abis.rar 里的常见来源物理时隙映射E1号、时隙号、BTS号、逻辑信道.cfg、.conf、维护终端导出TEI/SAPI 映射TEI、SAPI、方向、用途解码脚本里的常量、工程说明消息类型映射消息英文名、方向、关联无线流程协议规范、变量输出表3. Abis.rar 解包与文件识别先别急着导入解码器3.1 解包前三分钟看文件系统结构而不是直接双击解压拿到Abis.rar之后我习惯把它先复制到一个独立工作目录再去看它到底是什么。很多同名压缩包其实内容差距很大有人放的是基站的维护日志有人放的是协议文档也有人放的是经过预处理的 txt 码流。第一步先做文件系统层面的确认免得后面脚本解析时踩到编码和结构问题。mkdir -p ~/work/abis_analysis cp Abis.rar ~/work/abis_analysis/ cd ~/work/abis_analysis file Abis.rar ls -l Abis.rar这段命令里cp的关键是保留原始压缩包不动如果解压后文件被脚本误改还能回到最初的包。cd到独立目录是为了让后面递归查找时不会被无关文件干扰。file用来确认它确实是一个 RAR 压缩档如果这一行输出提示是 ASCII 文本或者 zip就说明文件后缀和内容不一致继续用解压工具反而会出问题。ls -l看体积如果只有几 KB大概率是纯文档如果有几十 MB多半是抓包或者日志。3.2 用 find 和 file 给文件分类解压之后不要立刻打开每个文件先用find做一次全量索引通过大小和类型把内容摊开看。find ~/work/abis_analysis -maxdepth 3 -type f -printf %s\t%p\n | sort -n file $(find ~/work/abis_analysis -maxdepth 2 -type f) 2/dev/null | head -50-maxdepth 3防止递归太深一次看不完。-printf %s\t%p\n把文件大小和完整路径按制表符输出再配合sort -n按大小升序排列能一眼看出哪些文件是核心码流哪些是文本说明。第二条命令把前两层所有文件丢给file它会根据文件内容判断格式避免被后缀骗了。比如一个.txt文件实际可能是 UTF-16 编码的导出日志或者一个.dat文件实际是标准 PCAP 抓包这些信息在file输出里都能看到。做完这两步压缩包里面谁是大头、谁是辅助基本就清楚了。如果发现解出来的文件里有一个巨大的.dat而旁边全是几十 KB 的脚本分析重心就应该是那个大文件如果整个包都是.txt那就直接进文本解析流程。3.3 识别码流还是导出文本两类文件的差异化处理Abis 相关资源里出现的文件大致可以分成四类处理方式完全不同。第一类是码流文件后缀常见.dat、.bin、.hex、.pcap需要用协议解析工具或者脚本按帧结构去读。第二类是导出文本常见.txt、.log、.csv一般已经有人帮我们做了一层解码里面可以直接搜消息名。第三类是配置文件常见.cfg、.conf主要用来还原时隙映射和 TEI 分配。第四类是脚本常见.py、.pl、.sh阅读成本低但坑最多因为路径和字段名往往是按原作者现场硬编码的。grep -inE CHAN_ACT|MEASURE|HANDO|RELEASE abis_log.txt | head -20这是处理导出文本时最常用的一条命令-i忽略大小写-n显示行号后跟的head -20限制输出条数。它能在不解析二进制的情况下快速判断这份 Abis 日志是不是以 RSL 层消息为主的无线信令还是以 OM 为主的管理日志。如果 grep 结果一片空白但文件确实很大就要考虑它可能是二进制或特殊编码不能当普通文本处理。对于二进制码流不要一上来就写完整解码器。先看文件头部有没有固定帧头、每帧长度是否一致、有没有 FCS 校验字节。用十六进制查看起止区块各一百字节比盲目试协议更高效。常见情况是文件已经被抓包工具剥离了 E1 物理层信息直接就是 LAPD/RSL 逐帧排布这种反而省事。4. 用 Python 做一条 Abis 信令的原始字节解析4.1 最小解析脚本输入一行十六进制输出字段清单Abis 的 RSL 消息从 L3 层看并不复杂第 1 个字节是协议鉴别语第 2 个字节是消息类型第 3 个字节开始是消息体和 IE 信息。真正复杂的是 LAPD 帧头剥离线以及多帧重组。下面这个脚本假设你手里已经有一份按帧导出的文本每行格式很规整包含时间、时隙、TEI、方向和 L3 十六进制载荷。这是很多Abis.rar资源里常见的导出形态脚本可以直接存下来改成自己的文件名跑。import csv import re from collections import Counter LINE_RE re.compile( r^(?Pbsc\S) r\s(?Pts\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) r\sTS(?Ptimeslot\d) r\sTEI(?Ptei\d) r\s(?PdirTX|RX) r\sL3(?Phex[0-9a-fA-F])$ ) def parse_hex_payload(payload): raw bytes.fromhex(payload) if len(raw) 2: return None return { pd: raw[0], msg_type: raw[1], next_iei: raw[2] if len(raw) 2 else None, } rows [] for line in open(abis_log.txt, encodingutf-8, errorsreplace): line line.strip() m LINE_RE.match(line) if not m: continue info parse_hex_payload(m.group(hex)) if info is None: continue rows.append({ bsc: m.group(bsc), time: m.group(ts), timeslot: int(m.group(timeslot)), tei: int(m.group(tei)), dir: m.group(dir), pd: info[pd], msg_type: info[msg_type], next_iei: info[next_iei] if info[next_iei] is not None else , }) with open(abis_parsed.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesrows[0].keys()) writer.writeheader() writer.writerows(rows) counter Counter((r[tei], r[msg_type]) for r in rows) for (tei, mt), count in counter.most_common(20): print(fTEI{tei} MSG_TYPE{mt} COUNT{count})这段代码的逻辑很直白正则先按空格和时间格式把一行文本拆成字段parse_hex_payload把十六进制字符串转成字节再取前三个字节作为协议鉴别语、消息类型和第一个 IE 标识。最后把全表写到 CSV并按 TEI 和消息类型聚合输出数量排行。这样不需要知道每条消息的完整含义就能先看到哪些 TEI 在频繁发什么消息。几个参数要按现场改\S是 BSC 或基站标识字段如果原文没有这个位置就删掉第一组。正则里的时间格式必须和日志里的完全一致差一个空格都会匹配失败。pd和msg_type是十进制数字方便排序next_iei不是最终信道号只是消息体里的首个 IE 标识正式解析时还要根据该 IE 的格式再读下一个字节。4.2 怎么把多条消息按 TEI 和时隙聚合单条消息看懂不算本事Abis 分析的价值在关联。同一个 TEI 下面的消息时序能还原一次完整的信道分配过程先激活再收到激活确认接着测量报告周期性地来最后释放。把相同 TEI 的消息抽出来按时间排序是定位“激活了但没确认”这类问题的第一步。from itertools import groupby rows_sorted sorted(rows, keylambda r: (r[tei], r[time])) for tei, group in groupby(rows_sorted, keylambda r: r[tei]): lines list(group) print(fTEI{tei} 共 {len(lines)} 条) for r in lines[:10]: print(f {r[time]} {r[dir]} msg_type{r[msg_type]} iei{r[next_iei]})groupby要求数据先排过序所以第一行先按 TEI 和时间同时排序否则分组会错乱。每组只打印前 10 条防止某个 TEI 的数据量太大刷屏。如果看到某个 TEI 只有激活请求没有确认大概率是无线侧没有响应或者 Abis 时隙丢帧如果激活确认后面紧跟着大串测量报告说明这条链路工作正常可以继续往下看切换或释放流程。4.3 把解析结果写到 CSV再由电子表格做二次透视把结果导成 CSV 不是多此一举。Excel 透视表对 TEI 和消息类型做交叉统计比在终端里看数字直观很多。我一般会在 CSV 里加一列“业务类型”把常见的消息类型映射成中文名映射关系可以直接从协议文档抄。注意 CSV 指定utf-8-sig编码是为了让电子表格软件打开时不出现中文乱码。column -s, -t abis_parsed.csv | head -20column -s, -t把 CSV 按逗号分隔并对齐成表格视图head -20只取前 20 行用来快速确认生成结果是否完整。这一步常用于检查脚本输出和源日志之间是否行数一致。如果column命令在你的系统里没有可以直接用less abis_parsed.csv代替反正目的只是预览格式。5. Abis 信令分析避坑手册抓包、解包、解码的 5 个常见问题5.1 解压后文件名全是乱码脚本读到一半中断现象Abis.rar在某个环境里解压后目录里的文件名变成锟斤拷一类乱码用 Python 打开其中某个文件时直接报UnicodeDecodeError。原因压缩包里的文件名和目录名大多按 Windows 简体中文环境编码而解压环境默认按 UTF-8 解码两边的字符集对不上文件名和文件内容都可能被错误解释。很多日志内容本身也带着 GBK 编码的设备名称直接被当 UTF-8 读就会出现中断。解决先不急着写脚本用支持代码页选择的解压工具重新解压指定字符集为简体中文或 GB18030再进入工作目录用file确认当前文本编码。脚本里打开文件时统一带encodingutf-8, errorsreplace遇到个别坏字符宁可替换掉也不要让整个解析进程中断。5.2 把 LAPD 握手帧当成 RSL 消息统计结果失真现象解析 CSV 里msg_type大量集中在 0、1、63 这类区间翻原文发现全是 SABME 帧和 UA 帧看不到任何信道激活、测量报告。原因LAPD 链路建立和保活是二层帧没有完整的三层无键信令载荷。直接按十六进制解析时把二层控制字段当成三层协议鉴别语自然解出大量无意义数字。解决解析时判断方向和控制字段只保留信息帧或可以确定为携带 L3 数据的帧。判断依据是 LAPD 帧头里的地址字段和控制字段数值范围不要用消息类型反推。最省事的做法是先在文本日志里过滤L3这个字段没有 L3 载荷的帧直接丢弃再进入 RSL 解析。5.3 多个 BTS 级联在同一套 E1 上TEI 和时隙对不上现象同一份 Abis 码流里TEI5 一会儿出现激活请求一会儿出现另一个基站的测量报告统计结果乱成一锅粥。原因Abis E1 链路上级联了多个远端站同一个 TEI 可能在不同时隙被复用也可能不同 TEI 指向相同物理设备。只看 TEI 不看时隙无法唯一确定对端。解决分析前必须把时隙和 TEI 做成联合主键也就是处理每一条消息时同时保留timeslot和tei。分组统计时按(timeslot, tei)而不是单独按 TEI。如果配置里没有完整映射就用配置文件里的 DIP 信息补齐设备号绝不靠猜。5.4 消息被切分成多段单帧解析只看得到半条现象一条完整的 RSL 消息在日志里分成两行或者同一个逻辑帧分布在相邻几个时间戳脚本解析后出现首尾不全的二进制碎片。原因Abis 口在低速率时隙上承载多路信令帧会被链路层的分段和重组机制切块。导出文本如果按物理帧导出就会把一个 L3 长消息拆成多条而不是合并成一条。解决解析前先确认源文件里每个逻辑帧是否有总长度字段。如果有按长度字段做缓冲拼接等到一个完整逻辑单元后再进 RSL 解析如果没有长度字段就用消息类型对应的 IE 长度表来计算边界。长度表可以从协议规范里抄不要用猜的。5.5 别人脚本能跑通换到自己的包就输出空文件现象从Abis.rar里找到一个解码脚本直接改文件名运行输出 CSV 或者日志文件是空的但脚本本身没有任何报错。原因原作者写的正则、字段分隔符、时间格式都是针对他自己的导出工具而你的导出文本可能用制表符而不是空格时间多了毫秒后缀或者 BSC 字段的位置不同。解决每次拿到脚本先打印原始文件的前 5 行找到时间戳和 L3 字段之间的真实分隔符再修改正则。不要一次改完全部的解析逻辑先解析 10 行作为样本确认pd、msg_type有值之后再全量运行。这是我在 Abis 分析里最常用也最省时间的排查策略。6. 进阶用一页“信令素描”验证 Abis 数据的完整性深度解析之前我会先用一条命令把整个 csv 压缩成一个极简清单我管它叫“信令素描”。信令素描只有两列TEI 和消息类型再加一个出现次数。它看不出具体的 IE 细节但能快速暴露数据源是否完整链路方向是否正常。cut -d, -f4,6,7 abis_parsed.csv | sort | uniq -c | sort -rn | head -20cut的-d,表示按逗号切列-f4,6,7取出 TEI、协议鉴别语、消息类型。后面的sort | uniq -c先按组合排序再计数避免uniq只合并相邻行。最后的sort -rn让出现最多的组合排在最前head -20只看前 20 行即可。输出里每个组合前面的数字就是该组合的消息条数。如果抓的是忙时数据某个 TEI 的激活类消息和释放类消息数量却差了很多说明数据在抓取或导出阶段就有丢帧不能直接拿去评估无线性能。如果某些 TEI 几乎只有上行消息没有下行消息也要停下来检查方向字段是否在导出时被写反或者链路只是单向抓取。这种验证花不了两分钟却常常能避免后面拿着残缺数据查半天。做 Abis 信令分析这几年我最大的体会是不把黑匣子当玄学。一个包拿到手先列映射、再做素描、再解析字段每一步都先给数据照一次 X 光而不是直接扎进细节里翻找。希望这篇笔记帮到你尤其是那些兜里压着好几个 Abis 压缩包、却一直没有找对解压顺序的人。本文还有配套的精品资源点击获取