企业官网建设流程全解析

简介：《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（路由区更新）Request，SM 层的 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 默认用 2123，GTP-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 Complete

MS 发起 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，结果可能完全不同。二是 TEID，SGSN 和 GGSN 各维护一套，创建隧道后双方都用对端 TEID 来定位隧道。三是 QoS，它是一个“请求 → 协商 → 重协商”的过程，任何一步不满足都会反映在激活请求被拒绝或“协商后 QoS”低于请求值上。指导书里的流程图通常会在这几个字段上标注箭头，实际分析时把它们串起来看，比逐条看消息更容易发现问题。

3.3 用 Cause Code 和定时器判断异常：GMM/SM 常见原因值速查表

信令流程分析最直接的经验是：先看结果消息，再看中间过程。结果消息里最关键的字段就是 Cause Code。无论是 Attach Reject、RAU Reject 还是 PDP Context Reject，都会在 GMM 或 SM 层携带一个原因值。我把现网最常见的几个原因值整理成下面的表，方便对照排查。

定时器同样重要。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 码重叠或漏配，手机在同一物理区域内反复跨 RA，RAU 就会被反复触发。另一个常见原因是周期 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 是 0x00（NS 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 Attach：Attach Request →（鉴权可选）→ Attach Accept → Attach Complete；PDP 激活：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", encoding="utf-8") as fp: for line in fp: c = line.strip() codes[c] = codes.get(c, 0) + 1 for cause, cnt in sorted(codes.items(), key=lambda kv: kv[1], reverse=True): print(f"cause={cause} count={cnt}")

跑完之后你会得到一张“故障原因画像”。把原因分布和无线指标、传输告警叠加，往往能拼出完整的故障链路。这时再动手改配置、调参数，就不是蒙着打了，每一步都有信令证据支撑。

5.3 用“平时正常数据”当镜子：把经验沉淀成自己的基线库

最后一条是我这两年一直在做的：把每次正常流程的抓包参数、时序、定时器配置，沉淀成一张基线表，落到团队共享的文档里。方法和思路前面都讲清楚了，值得投入时间把它做成一套自己团队的“指导书”。我曾经因为一个 RAU 重发问题反复排查了一个月，最后发现是核心网侧把周期 RAU 定时器改短了，而无线侧没有任何改动。如果当时手里有基线数据表，这个问题半小时就能定位，根本不用熬夜加班。信令流程分析的功力就是从一次次“正常数据”里攒出来的，别怕麻烦。希望这些经验能帮到你。

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