简介《GPRS/EDGE信令流程分析》是由华为技术有限公司编写的专题技术资料面向移动通信网络维护、优化与故障排查工程师。文档围绕Um接口展开系统介绍协议栈结构以及RLC/MAC中的关键概念帮助读者建立从物理层到数据链路层的完整认知框架。信令流程方面重点解读CCCH和PACCH上的上行一阶段/两阶段接入、下行TBF建立及失败处理、上下行TBF正常与异常释放等主要流程并对扩展上行TBF、延迟释放等优化流程作出说明。资源包含1个doc文档大小2.05MB内容按“基本概念—主要流程—优化流程”组织便于按需查阅。已有83人下载学习适合具备一定GSM基础、希望深入掌握分组域信令交互细节的技术人员参考。1. GPRS/EDGE 信令流程分析指导书到底解决什么问题从一个投诉电话说起有一次凌晨值班同事转来一个投诉用户手机能打电话但上网打开网页一直转圈。无线指标查了一遍电平、质量、干扰都正常。最后在 Gb 接口抓了段信令从 PDP 上下文激活的拒绝消息里看到 SM Cause Code 26资源不足顺藤摸瓜定位到某个 GGSN 的 APN 流量配额耗尽业务才恢复。这个例子想说明在 GSM 存量网络里很多“看不见”的问题最终要靠信令流程分析来定位。“GPRS/EDGE 信令流程分析指导书2021-2022 年”就是把 GPRS/EDGE 网络里从手机附着、路由区更新到 PDP 上下文激活的整套信令流程按步骤、按字段拆开讲清楚再配上现网里常见的异常场景。它适合三类人无线网优工程师、核心网分组域维护人员以及刚入行想建立信令分析体系的通信新人。即使你现在主要做 4G/5G这套流程里控制面与用户面分离、承载协商的建模思路依然是分组域基本功。2. GPRS/EDGE 信令流程的底层基础GERAN 协议栈分层与 Gb/Gn 接口的协作边界做信令流程分析第一道坎不是消息本身而是协议栈。指导书里的“信令流程”并不是平铺直叙的一串消息而是横跨空口 Um、Gb、Gn/Gp 三条逻辑通道的多层协议协作。如果你分不清哪一层负责什么很容易把无线侧问题误判成核心网问题或者把一次正常重传当成故障。先把分层和接口协作理清楚后面的抓包定位才不走弯路。2.1 Um 接口四层协议栈物理层、MAC、RLC、LLC 各自拆什么包GPRS/EDGE 的无线侧接入网叫 GERAN手机和基站之间走 Um 接口也就是空口。和电路域语音不同GPRS/EDGE 的数据是分组调度无线资源不是独占的物理信道而是动态分配的 PDTCH分组数据业务信道。同一个物理时隙上一个用户的数据块和另一个用户的数据块可能交替出现调度权在 BSC 侧。这让空口同时表现为“多用户共享一条带宽”和“单用户高频突发”两种形态也为分析带来不少困扰。空口协议栈从下往上依次是物理层、MAC、RLC、LLC 四层信令面再叠加 GMM 和 SM。物理层负责把比特映射到射频信道GPRS 使用 GMSK 调制EDGE 引入 8PSK 调制速率提升主要发生在这一层。MAC 层负责多个用户复用同一时隙并为每次传输指明 TBF临时块流资源RLC 层把上层的 LLC PDU 切成小块加上帧头和校验通过选择性重传保证空口可靠传输。你在空口抓包里看到的那些密密麻麻的 RLC/MAC Block其实是上层数据被切碎后的样子。LLC 层在 MS 和 SGSN 之间建立一条逻辑链路负责分段重组、确认重传和 QoS 标记对上层隐藏空口和 Gb 的传输差异。LLC 之上才是你真正关心的信令消息GMM 层的 Attach Request、RAU路由区更新RequestSM 层的 Activate PDP Context Request。做流程分析时正确姿势是跳过 RLC 分片细节直接按 TLLI临时逻辑链路标识把属于同一个用户的 LLC 帧汇聚起来还原出完整信令消息。这里有一类常见误区把 RLC/MAC 层控制消息和 GMM/SM 层信令混在一起看。记住一句大白话层2 信令解决“这辆车怎么上路”GMM/SM 信令解决“你要去哪、给你什么服务”两者的消息类型、地址字段和作用范围完全不同。2.2 Gb 接口上的 NS/BSSGP/LLC 封装一条信令消息如何穿越传输网GPRS/EDGE 的信令和用户数据都要从 BSS落地在 PCU送到 SGSN这段路就是 Gb 接口。Gb 的底层承载早期走帧中继后来不少网络改造为 IP 承载但无论底网怎么变协议分层是稳定的NS网络服务、BSSGP、LLC 以及上层的 GMM/SM。你在一段 Gb 抓包里看到的通常是 BSSGP 封装着一条完整的 LLC 帧而 LLC 帧里要么是 GMM/SM 信令消息要么是经过 SNDCP 封装后的用户数据分段里面才是真正的用户 IP 包。NS 层负责在 PCU 和 SGSN 之间建立 NSE网络服务实体管理底层虚连接帧中继 PVC 或 IP 隧道并负责阻塞、解阻塞和复位。BSSGP 层则面向业务流程它把 LLC 帧装进自己的 PDU同时携带路由信息例如 RAI、小区 Cell ID、QoS 参数和 BSS 与 SGSN 之间的管理消息。打个比方BSSGP 是信封LLC 帧是信纸GMM/SM 消息才是信的内容。抓包分析时先用 BSSGP 里的 Cell ID 或 BVCI 定位是哪个小区上来的再用 LLC 层的 TLLI 定位到具体用户这套索引顺序是 Gb 接口分析的基本动作。再讲一个绕不开的 NS 层消息NS_RESET。这条消息经常出现在抓包开头属于 NS 层管理消息用于复位某个 NSE。如果你看到 NS_RESET 夹在正常 BSSGP 消息中间甚至反复出现先不要急着当成传输故障要去看 NS Reset 的原因值和触发方。NS 层的 Cause Code 会区分“NS hung”“配置错误”“瞬态条件”等不同情形后面避坑章节专门展开。这里先记住结论BSSGP 消息乱先查 NS 层NS 层稳定再往 LLC 以上找原因。2.3 Gn/Gp 接口的 GTP-C 与 GTP-U抓包如何区分控制面与用户面SGSN 和 GGSN 之间走 Gn 接口同厂家或 Gp 接口跨厂家核心协议是 GTP。GTP 明确分成 GTP-C控制面和 GTP-U用户面两个平面这是整个 GPRS 网络里“控制与承载分离”思想最直观的体现也是理解 4G/5G 接口的很好铺垫。GTP-C 负责隧道管理承载 Create PDP Context Request/Response、Update PDP Context、Delete PDP Context 等消息GTP-U 负责封装用户实际 IP 包在包头里带 TEID隧道端点标识和序号。两类报文都跑在 UDP 之上靠端口区分GTP-C 默认用 2123GTP-U 默认用 2152。在 Gn 接口抓包时最省事的过滤条件就是 UDP 端口 2123 或 2152一眼就能把信令流程和业务流量分开。为什么强调这个区分因为信令流程分析关注的是“隧道生命周期”。一次 PDP 激活会先在 GTP-C 建立隧道然后在 GTP-U 上传送用户数据最后在 GTP-C 删除隧道。如果你把 GTP-U 的用户序号当成信令来看会被里面的 TCP ACK、重传刷花眼反过来只看 GTP-C 消息才能看到从 SGSN 到 GGSN 的完整协商过程。常用的抓包工具会自动解析端口和消息类型但你要知道它按什么规则分类才不会被工具输出牵着走。3. 照着指导书抓一次真实信令流程Attach 到 PDP 激活的核心过程拆解指导书的主线很清晰手机开机 → GPRS Attach → 跨区时做 RAU → 要上网时激活 PDP 上下文。这一章把 Attach 和 PDP 激活两条流程逐条拆开把关键字段和时序关系讲清楚。你不需要记住每个字节的偏移但要记住每个阶段谁发起、谁响应、主要字段是什么、失败会落在哪一步。3.1 GPRS Attach 流程逐条讲解从 Attach Request 到 Attach CompleteMS 发起 Attach Request 时关键字段包括终端标识IMSI 或 P-TMSI、附着类型仅 GPRS 附着还是 Combined 附着、上一次所在的路由区Old RAI和签名信息。SGSN 收到后会判断这个 MS 是否认识如果带了 P-TMSI 且能在本 SGSN 或旧 SGSN 找到上下文可以跳过部分流程如果找不到上下文SGSN 就会下发 Identity Request 向 MS 要 IMSI再走鉴权。鉴权加密环节SGSN 向 HLR 取鉴权三元组RAND/Kc/SRES下发 Authentication Request 给 MS。MS 的 SIM 卡用 Ki 计算出 SRES 回给 SGSN验证通过后SGSN 再可选地下发加密模式命令通知空口开始加密。这一环节有个判断技巧抓包里出现额外的 Identity Request 或额外的鉴权轮次不一定是故障可能是旧上下文失效后的正常行为。消息多不等于有问题关键是看在不在规范允许的上下文中。最后 SGSN 回 Attach Accept分配新 P-TMSI携带当前 RAI、周期性 RAU 定时器参数、以及协商后的 LLC 参数例如 LLC SDU 最大长度。如果 P-TMSI 被更换或 SGSN 要求确认MS 会再回一条 Attach Complete。你对照指导书里的流程图会发现标准流程在鉴权这一步是有条件分支的。抓包时先看是否跳过了鉴权再看是否有额外消息这一眼能省不少排查时间。# 抓完包先看协议层级分布确认抓包范围没有跑偏 tshark -r gb_attach.pcap -q -z io,phs这条命令输出的是抓包里各协议层的包数和占比算是一个快速体检。跑完先确认有没有你预期的 GMM、BSSGP、LLC 这几层如果 LLC 层的占比异常高说明用户面数据占了多数如果 GMM 层几乎不见那很可能不是你要分析的场景先重新调整抓包位置再说。3.2 PDP 上下文激活流程拆解DNS 解析、GTP 隧道与 QoS 协商PDP 上下文激活才是用户真正“上网”的入口也是信令流程分析里出现案例最多的环节。MS 给 SGSN 发 Activate PDP Context Request携带信息包括 NSAPI、事务标识、PDP 类型一般是 IPv4、APN、请求的 QoS 和可选的 PDP 地址。这里的 QoS 是用户期望值并不代表最终值后面每一步都可能被网络侧降级这是分析协商类问题时的关键点。SGSN 收到请求后做两件事一是校验 APN 和用户订阅是否匹配二是如果 APN 是非 IP 格式通过 DNS 查询找到对应的 GGSN 地址。随后 SGSN 向 GGSN 发 Create PDP Context Request带上用户 IMSI、APN、SGSN 侧控制面 TEID、请求 QoS 等。GGSN 判断是否允许该用户接入此 APN分配一个 PDP 地址用户侧 IP 地址并把 GGSN 侧的控制面和用户面 TEID、协商后的 QoS 一并放进 Create PDP Context Response。最后两步收尾。SGSN 拿到协商结果后向 MS 发送 Activate PDP Context Accept告知用户分配的 IP 地址、协商后的 QoS、以及可选的 Packet Flow ID。如果协商结果与请求不一致此时就能看出来。MS 确认无误后可选地回一条 Activate PDP Context Complete。此后用户数据在 GTP-U 隧道里传输GTP-C 保持隧道存活直到去激活。这里要注意三个字段的走向。一是 APN从 MS 到 SGSN 再到 GGSN 一路传递中间可能被 SGSN 按订阅数据过滤所以同一手机不同号码激活到不同 APN结果可能完全不同。二是 TEIDSGSN 和 GGSN 各维护一套创建隧道后双方都用对端 TEID 来定位隧道。三是 QoS它是一个“请求 → 协商 → 重协商”的过程任何一步不满足都会反映在激活请求被拒绝或“协商后 QoS”低于请求值上。指导书里的流程图通常会在这几个字段上标注箭头实际分析时把它们串起来看比逐条看消息更容易发现问题。3.3 用 Cause Code 和定时器判断异常GMM/SM 常见原因值速查表信令流程分析最直接的经验是先看结果消息再看中间过程。结果消息里最关键的字段就是 Cause Code。无论是 Attach Reject、RAU Reject 还是 PDP Context Reject都会在 GMM 或 SM 层携带一个原因值。我把现网最常见的几个原因值整理成下面的表方便对照排查。Cause Code所属层中文含义常见排查方向3GMMIllegal MSIMSI 黑名单、HLR 数据异常7GMMGPRS services not allowed用户订阅没开通 GPRS 服务11GMMPLMN not allowed漫游限制、运营商接入白名单12GMMLocation Area not allowed位置区接入限制查 HLR 限制参数26SMInsufficient resources无线资源、传输资源或 APN 配额不足27SMMissing or unknown APNAPN 拼写错误或 SGSN 未配置该 APN29SMUser authentication failedGGSN 侧 PAP/CHAP 鉴权失败30SMActivation rejected by GGSNGGSN 策略拒绝查 GGSN 日志31SMActivation rejected by BSSBSS 无法满足 QoS查 PCU、PDCH 容量33SMNot authorized for this APN该用户不允许访问此 APN定时器同样重要。GMM/SM 在手机侧定义了多个重传定时器T3310 管理 Attach 的重传默认 15 秒一次T3330 管理 RAU 的重传T3380 管理 PDP 激活的重传。正常流程中这些定时器不该频繁超时。如果某段抓包里同一个 MS 间隔十几秒或三十秒就重发一次同一类请求说明网络侧没有及时应答问题大概率在 SGSN 与 BSS 之间的某个网元且大多是信令面拥塞或握手失败。反过来如果是手机侧主动取消请求消息里不会带重传而是直接出现 Abort。这两类表现务必分清不要一看到重复消息就去查无线先确认重传定时器还没到点。4. GPRS/EDGE 信令流程分析避坑手册五个误判现场与排查路径这一章是真正踩坑换来的实操部分。信令流程分析本身不难难的是很多现网问题在抓包第一眼时会给出误导信号。我挑五个最容易让人兜圈子的场景按现象、原因、解决三段来写每条都可以直接对照你手上的抓包。4.1 场景一Attach 成功但 PDP 激活被拒Cause Code 26 背后不一定是核心网现象用户 Attach 流程完全正常Attach Accept 和 Attach Complete 都看到了但接下去的 Activate PDP Context Request 被 SGSN 用 SM Cause Code 26资源不足拒绝。按直觉查 GGSN 资源、查 APN 配置、查配额全部正常。原因Cause Code 26 是“资源不足”但资源不只有 GGSN 容量这一种。现网里常见的是 PCU 到 BSC 的 PDCH 资源池接近满载或该区域的 Gb 传输带宽受限。SGSN 在做 PDP 激活时会向 BSS 查询可用无线资源和传输资源BSS 侧回一条带失败原因的内部消息SGSN 把它映射成 SM Cause 26 发给 MS。所以问题的真正原因可能根本不在核心网而在无线侧或传输侧。解决看 Reject 消息前面 SGSN 与 BSS 之间的 BSSGP 交互确认 SGSN 是否发起了资源查询。然后查该小区或该 BSC 的 PDCH 占用率和 Gb 接口利用率。建议把“Cause Code 26 优先怀疑 PCU 容量”写进你的检查清单能省去一上午的 GGSN 排查时间。4.2 场景二RAU 重复触发引发信令风暴但无线指标一片正常现象某区域的 Gb 接口出现大量 RAU 请求核心网处理器冲高用户上网时断时续。无线侧指标正常没有掉线、没有干扰。从现象看容易怀疑是终端批量异常或有人在测试设备。原因排除终端因素后最常见的是 RA 与位置区边界配置不一致。手机从一个路由区走到另一个路由区时会发起 RAU如果边界上的 RAC 码重叠或漏配手机在同一物理区域内反复跨 RARAU 就会被反复触发。另一个常见原因是周期 RAU 定时器配置过短大量手机周期性地同时发起更新请求形成“齐步走”式的信令高峰。解决按 RAU 消息里的 Old RAI 和 New RAI 做统计。如果某对 RAI 之间的 RAU 请求数占比异常高先对照 BSS 侧的 RAC 配置和核心网侧的 RAI 配置确认两边边界一致。再用指导书里的定时器参数表核对周期 RAU 定时器T3309设置过低就调高错峰后往往立竿见影。4.3 场景三Gb 接口抓包看到连续 NS_RESET第一反应以为是传输闪断现象抓包里 NS_RESET 和 NS_RESET_ACK 连续出现BSSGP 消息几乎被淹没业务全部中断。传输网管查了物理链路没有告警让人怀疑是不是抓包设备本身出了问题。原因除了传输闪断NS 层还有一个常见的隐性原因NSVC 配置两端不一致。比如 BSC 侧调整了 NSVC 的 DLCI 或 IP 端口但没有同步给 SGSN或者两侧的 NS 层协议参数如持活时长、复位定时器不匹配。NS 层一复位底层虚连接重建所有在这个 NSE 上的 BSSGP 消息全部中断看起来就像传输断了。解决看 NS_RESET 消息里的 NS Cause。Cause 是 0x00NS hung或 0x01配置错误时基本是配置或软件问题是 0x03瞬态条件时才要怀疑底层传输。对照两端的 NSVC 配置表确认 NSEI、DLCI/IP 端口、持活定时器一致。记住NS_RESET 可能是传输故障的警钟也可能是配置不一致的提醒别急着找传输同事。4.4 场景四LLC PDU 长度超限导致大量重传却误判为无线质量差现象某小区用户平均速率骤降统计里 LLC 层重传率升高空口质量指标正常但 Gb 抓包看到 LLC SDU 长度超限或 LLC 帧被丢弃的痕迹。第一直觉是无线环境变差开始查干扰、查弱覆盖。原因GPRS/EDGE 里 LLC 层对单个 SDU 的长度有上限约束由 N201 参数控制常见配置是上行 500 字节、下行 1500 字节这一类。当内容服务器或 GGSN 侧下发的 IP 包太大时如果 SGSN 和 MS 之间的 MTU/MSS 协商没有收敛TCP 大包会在 LLC 分段阶段超限触发 LLC 层重传甚至丢弃。这本质上是端到端拥塞加分片参数不匹配和空口质量关系不大。解决看 Activate PDP Context Accept 里“协商后的 LLC SDU 长度”字段确认该用户实际承载参数。再抓一段 Gn 侧 GTP-U 的包观察 IP 包长度分布看是否有大量超过协商值的包。一个常见补救方法是开启 GGSN 或 SGSN 的 MSS clamping把 TCP MSS 收缩到安全范围避免大包被打碎后反复重传。这个场景我见过不止一次每次都是先被“无线质量差”带偏最后才绕回承载参数上。4.5 场景五双端抓包时间戳错位把正常流程看成异常顺序现象在 BSC 侧和 SGSN 侧同时抓包合并到同一时间轴后发现 Attach Request 竟然出现在 Attach Accept 之后流程完全“倒挂”。反复重抓几次时序还都不一样很难判断是网络故障还是工具问题。原因两个抓包主机的系统时钟不同步。最常见的是抓包笔记本电脑没配 NTP或者两台机器的 NTP 同步源不一致导致时钟漂移几十甚至几百毫秒。信令流程的时序判断对毫秒级差都很敏感这种错位会让一切依赖时间戳的分析失真。解决抓包开始前先确认所有抓包主机都同步到同一 NTP 源。如果用的是离线笔记本先抓一段已知流程比如固定位置的 Attach 流程作为时间标签然后在 Wireshark 里用 Time Shift 功能手动对齐或者把每个流的“相对时间”作为内部顺序依据。还有一种更稳妥的办法不依赖绝对时间戳改用协议内部的序列号如 LLC 帧序号或 NS 层序号来还原流程顺序。内部序号是协议自带的比主机时间可靠得多。5. 把 GPRS/EDGE 信令流程分析做成肌肉记忆三个进阶验证手法分析经验多了你会发现信令流程分析难的不是某一条消息而是如何把判断从“个案”推广到“整网”。我常用的进阶手法有三个都来自长期对照抓包养成的习惯。5.1 先画一张“消息序列模板”正常几步、异常几步一目了然每次分析一个流程前我习惯先在纸上画出正常流程的消息序列模板。比如 GPRS AttachAttach Request →鉴权可选→ Attach Accept → Attach CompletePDP 激活Activate PDP Context Request → Create PDP Context Request → Create PDP Context Response → Activate PDP Context Accept。拿着模板去对照实际抓包任何一步缺失或额外消息都会立刻暴露。这个方法对新手尤其有用模板本身就是指导书里流程图的基本骨架看得多了就能背下来分析时不再需要翻书。5.2 按 Cause Code 分布反向定位从个案走向整网判断另一个习惯是把一段时间的 Reject 消息按 Cause Code 统计分布而不是只看个案。比如某个区域连续一小时内有 200 次 PDP 激活被拒如果全部集中在 Cause Code 26方向性就很明确资源不足如果 27 占一半那就要怀疑 APN 配置在 BSC 和 SGSN 两边不一致。这个统计用 tshark 转出消息列表后用脚本跑一遍就行也可以先用 Wireshark 的协议层级统计粗看一次再按 Cause Code 细分。# 从导出的 cause code 文本文件中统计分布按出现次数降序输出 codes {} with open(reject_causes.txt, encodingutf-8) as fp: for line in fp: c line.strip() codes[c] codes.get(c, 0) 1 for cause, cnt in sorted(codes.items(), keylambda kv: kv[1], reverseTrue): print(fcause{cause} count{cnt})跑完之后你会得到一张“故障原因画像”。把原因分布和无线指标、传输告警叠加往往能拼出完整的故障链路。这时再动手改配置、调参数就不是蒙着打了每一步都有信令证据支撑。5.3 用“平时正常数据”当镜子把经验沉淀成自己的基线库最后一条是我这两年一直在做的把每次正常流程的抓包参数、时序、定时器配置沉淀成一张基线表落到团队共享的文档里。方法和思路前面都讲清楚了值得投入时间把它做成一套自己团队的“指导书”。我曾经因为一个 RAU 重发问题反复排查了一个月最后发现是核心网侧把周期 RAU 定时器改短了而无线侧没有任何改动。如果当时手里有基线数据表这个问题半小时就能定位根本不用熬夜加班。信令流程分析的功力就是从一次次“正常数据”里攒出来的别怕麻烦。希望这些经验能帮到你。本文还有配套的精品资源点击获取
