简介面向移动通信网络维护、优化与故障定位工程师的GPRS/EDGE信令流程专题资料出自华为官方技术文档。文档先讲Um接口协议栈与RLC/MAC核心概念RLC负责数据分段、重组与可靠传输MAC管理无线资源访问分配再按流程拆解上下行接入、TBF建立与释放、延迟释放及异常处理等真实场景。内容包括CCCH上的上行一阶段/两阶段接入、CCCH与PACCH上的下行TBF建立及失败处理、上行/下行TBF的正常与异常释放以及扩展上行TBF、上行/下行TBF延迟释放等优化流程并提供对应的信令时序与排错思路帮助读者定位无线侧问题、理解网络资源调度机制。资源共1个doc文件大小约2.05MB内部目录按接口、流程、优化三层组织便于快速翻查。目前已有84人学习浏览属于面向专业场景的实用技术资料。1. 一份GPRS/EDGE信令流程分析指导书能帮你解决什么做GPRS/EDGE网络优化的人最怕的不是参数不会配而是手机上报“能注册但上不了网”“附着失败”“PDP激活被拒”时手里只有一段看不懂的 trace 日志。GPRS/EDGE信令流程分析指导书这类资料就是把从 Um 口到 Gn 口的主要信令交互按场景拆开讲清楚MS 怎么附着、SGSN 怎么找 HLR、GGSN 怎么分配 IP、失败时回的 cause 值是什么意思。它解决的是“黑匣子”问题——让你拿到一段信令记录时知道先看哪条消息、下一步查哪个网元。适合刚接手核心网维护的新人也适合做网格优化的老手在跨网元定位问题时拿来对照。2. GPRS/EDGE信令分析先立框架接口、协议栈与关键网元信令分析最容易翻车的地方是拿着 IP 网络的报文习惯去解移动网信令。GPRS/EDGE 的信令是分层且带状态机的每层有独立的寻址和确认机制。不先把“这段报文出现在哪个接口、属于控制面还是用户面”搞清楚后面所有判断都会跑偏。所以拿到指导书第一件事不是翻流程而是看它的接口拓扑和协议栈分层。2.1 四类接口与两个平面先分清在哪抓包GPRS/EDGE 网络里信令主要出现在四条接口上。指导书一般会按接口分章节实际排查时我们也是按接口选抓包点。接口位置主要承载的信令抓包可行性UmMS 到 BSSGMM/SM承载在 LLC 之上终端路测可达GbBSS 到 SGSNBSSGP/NS上面跑 LLC 里的 GMM/SMSGSN 侧可达GnSGSN 到 GGSNGTP-C 控制面与 GTP-U 用户面核心网侧可达GrSGSN 到 HLRMAP 信令鉴权、位置更新需在 HLR/SGSN 侧看日志四条接口的分工很明确Um 口信令直接反映终端行为附着请求、PDP 激活请求都是从这里发起Gb 口是无线侧和分组核心网的分界线BSSGP 在这里终结Gn 口是 SGSN 和 GGSN 之间的 GTP 信令PDP 上下文能不能建立成功看这一口的 Create PDP Context 消息就够了Gr 口走 MAP 信令负责 SGSN 从 HLR 拉签约数据和做位置登记。实际分析优先级我一般按 Gn 口优先、Gb 口其次、Um 口最后来排。原因很简单Gn 口报文标准化程度最高Wireshark 直接解码cause 值齐全最容易快速区分“核心网问题”还是“无线/终端问题”。在 Gn 口看到 Create PDP Context Response 返回成功基本可以排除核心网侧会话管理的问题剩下就该去查用户面和无线质量。控制面和用户面的区分也很关键。GMM/SM、BSSGP、GTP-C 属于控制面负责移动性管理和会话管理用户面是 LLC 的数据部分和 GTP-U负责真正承载业务。很多初级分析把 PDP 激活失败归到无线侧其实在 Gn 口看一眼 GTP-C 响应里的 cause 值就能把问题圈定在核心网。2.2 协议栈分层先解 LLC 还是先看 GTP-CGPRS/EDGE 的协议栈是理解信令的骨架。控制面从 MS 往上走是 GMM/SM、LLC、RLC/MAC、GSM RF到 Gb 口变成 LLC、BSSGP、NS、Frame Relay 或 IP到 Gn 口则是 GTP-C、UDP、IP。这里最容易绕晕的是 LLC 层。早期 GPRS 里 GMM/SM 信令封装在 LLC 帧中到了 Gb 口由 BSSGP 承载所以 Gb 口抓包要先解 BSSGP 才能看到上层的 LLC 和 GMM/SM。后来不少设备做了 Gb over IP 改造NS 层跑到 UDP/IP 上解析思路不变只是底层从帧中继换成 IP。EDGE 的引入主要动的是 Um 口物理层和 RLC/MAC编码调制方式从 GMSK 扩展到 8PSK引入了 MCS-1 到 MCS-9 的调制编码等级单时隙吞吐从十几 kbps 提到五十多 kbps。但信令流程本身没有变GMM/SM 的消息类型、状态机和 GPRS 完全相同。所以拿这类指导书分析 EDGE 场景时重点要放在无线侧的编码方式、链路质量和 RLC 重传而不是重新学一遍信令交互顺序。判断一段 trace 该先解哪一层有个通用做法看抓包位置。Gn 口直接解 GTPGb 口先解 NS/BSSGP再去解 LLC 里的 GMM/SMUm 口路测软件通常已经帮你解好 LLC导出时能看到 GMM/SM 层字段。别在不该解 LLC 的 Gn 口报文里找 LLC 头这是新手最常见的无效操作。2.3 两条主线流程附着与 PDP 上下文激活指导书里信令流程列得很多但主线只有两条GPRS Attach 和 PDP Context Activation。附着解决“网络认不认识我”PDP 激活解决“能不能给我一条上网通路”。这两条走通了其他流程比如路由区更新、去附着、PDP 去激活都是在这两个状态机上做迁移。分析时先确定当前处于哪个状态。MS 在 SGSN 里有 IDLE、STANDBY、READY 三种移动性状态PDP 上下文状态是 INACTIVE 还是 ACTIVE。状态判断错了后面解读全错。比如手机在 STANDBY 状态下发送数据会先触发 Service Request 或 RAU不是直接建 PDP如果忽略了这一步就会觉得“流程少了消息”。所以我的习惯是拿到指导书先背状态迁移图再去看逐条消息。状态机是纲消息是目。纲举目张分析 trace 时才不会在细节里迷路。3. 把核心信令流程拆开附着、PDP激活、路由区更新的每一步框架立住之后就可以逐条流程拆解。这一章把三个最常用来做信令分析主线的流程讲透附着、PDP 上下文激活、路由区更新与小区更新。每条流程都按“消息顺序—关键字段—失败点”三层来看。3.1 GPRS附着流程从Attach Request到Accept的7步GPRS 附着是终端进入分组网络的第一步。常见流程是这么走的MS 在 Um 口发起 Attach Request携带 IMSI 或 P-TMSI、附着类型、MS 网络能力。SGSN 收到后如果 MS 携带的是 P-TMSI 且原 SGSN 不是自己SGSN 向旧 SGSN 发 SGSN Context Request把用户上下文取回来。SGSN 根据网络配置决定是否做鉴权。做鉴权时SGSN 从 HLR/AuC 取鉴权三元组向 MS 发 Authentication RequestMS 回 Authentication Response。SGSN 向 HLR 发 Update Location登记当前 SGSN 地址。HLR 返回 Insert Subscriber Data携带用户签约的 QoS、APN 列表。SGSN 向 HLR 确认收到签约数据然后向 MS 发 Attach Accept分配 P-TMSI 和新的 RAI。MS 回 Attach Complete附着流程完成。关键字段有三个需要盯。一是 Attach Type区分是 GPRS Attach 还是 Combined GPRS/IMSI Attach二是 MS Network Capability里面带了终端支持的 GEA 加密算法三是 Attach Accept 里的 P-TMSI Signature后续的 RAU 和 PDP 激活请求都要带上它丢了会导致 SGSN 重新走一遍鉴权和上下文检查。附着失败最常见三类原因加密算法不匹配典型现象是鉴权完成后 SGSN 发 Attach Rejectcause 是 GMM #7GPRS services not allowedHLR 签约数据异常Insert Subscriber Data 带不出 APN 列表终端附着成功但后续 PDP 激活一定失败跨 SGSN 附着时旧 SGSN 不可达SGSN Context Response 超时Attach Request 被静默丢弃。提示Attach Request 重发 N 次而 SGSN 完全无响应时优先怀疑 SGSN 与 HLR 的 MAP 链路或 SGSN 全局资源问题不要窝在 Um 口查覆盖。3.2 PDP上下文激活断开“能上网”的最后一道门附着成功只能说明终端注册到了 SGSN真正要上网必须激活 PDP 上下文。激活流程比附着短但每一步失败的含义更明确MS 发 Activate PDP Context Request携带 APN、请求的 QoS、NSAPI、PDP 类型。SGSN 根据 APN 做 DNS 解析或查本地 APN 配置确定 GGSN 地址。SGSN 向 GGSN 发 Create PDP Context Request带上 IMSI、APN、QoS 协商参数。GGSN 检查用户签约和 APN 配置返回 Create PDP Context Responsecause 为 0success即成功。SGSN 向 MS 回 Activate PDP Context Accept携带 GGSN 分配的 PDP 地址。这里有几个必须会读的字段字段作用出问题时的表现APN决定走哪个 GGSN 和外部 PDN解析失败时 SGSN 回 SM cause #26NSAPI标识终端上的 PDP 上下文重复时上下文冲突激活失败QoS Negotiated协商后的 QoS 参数比请求值低说明资源受限PDP AddressGGSN 给 MS 分配的 IP分配失败则激活被拒排查 PDP 激活失败有一个非常高效的做法在 Gn 口抓包过滤 Create PDP Context 消息看 Request 和 Response 是否配对出现。只有 Request 没有 Response说明 GGSN 没回应或链路中断有 Response 但 cause 不为 0就按 SM cause 表查原因。SM cause #26 是 APN 缺失或未知#29 是用户鉴权失败#31 是请求的服务未签约#32 是服务暂时不可用。这组 cause 值背下来现场能少翻很多文档。提示激活成功后马上被去激活多半是计费或策略问题例如 GGSN 侧流量配额用尽、在线计费系统无响应。此时要看 Gn 口的 Delete PDP Context Request 是谁发的由 SGSN 发起还是 GGSN 发起方向不同排查对象完全不同。3.3 路由区更新与小区更新移动场景的信令细节路由区更新分两类SGSN 内 RAU 和 SGSN 间 RAU。SGSN 内 RAU 流程短RAU Request、鉴权、RAU Accept 三步SGSN 间 RAU 要把用户上下文从旧 SGSN 拉到新 SGSN再向 HLR 做位置更新HLR 还会向旧 SGSN 发 Cancel Location。周期性 RAU 是指导书里一定会写到的点。MS 里的 T3312 定时器控制周期性 RAU在 STANDBY 状态下超时没做 RAUSGSN 会认为用户不可达。实际运维里 T3312 配太短信令量暴涨BSSGP 和 GTP-C 的负荷都上来配太长寻呼失败率升高。城区一般配 30 到 60 分钟农村可以放到 120 分钟左右具体以寻呼成功率统计为准。小区更新只在 READY 状态发生因为 READY 状态下 SGSN 要求精确知道用户在哪个小区。信令上它很短MS 发 Cell UpdateBSC/SGSN 确认。但这个流程最容易在无线侧失败尤其在切换参数配错、小区拥塞的场景里Cell Update 失败会直接导致 READY 状态悬挂用户表现为“信号满格但业务断流”。遇到掉线率高的小区先查小区更新成功率不要直接去查 Gn 口信令。4. 信令分析实操抓包位置、过滤表达式与参数判读流程拆完接下来是动手环节。信令分析最值钱的能力不是看消息名字而是知道在一堆报文的哪一层、哪个字段里找答案。这一章给出我日常定位问题的固定套路。4.1 抓包位置选择Um口、Gb口还是Gn口抓包位置由问题现象决定不是哪里方便抓哪里。三类常见场景的选择如下。用户投诉上网慢或打不开网页优先 Um 口路测拿到终端侧 RLC/MAC 的调制编码等级、重传率、BLER同时 Gn 口抓 GTP-U 看用户面吞吐。两侧对照能快速确认瓶颈在无线口还是核心网。附着失败或 PDP 激活失败优先 Gb 口和 Gn 口同时抓。Gb 口看 SGSN 有没有收到 BSSGP 上行的 Attach RequestGn 口看 SGSN 有没有向 GGSN 发 Create PDP Context以及 GGSN 回了什么 cause。这样的好处是每一步都有据可查不用猜。频繁跨 SGSN RAUGn 口抓 GTP-C 看 SGSN Context Request/ResponseGr 口看 HLR MAP 信令。多数运营商在 SGSN 侧有后台 trace 工具能直接按 IMSI 打点。没有后台工具时Gn 口镜像是最可行的降级方案。实操里最难的抓包点是老的 Gb 口 Frame Relay 链路。改用 Gb over IP 后容易得多端口镜像就能拿全 NS/BSSGP 报文。如果现场只有 SGSN 一侧的抓包条件Gn 口是性价比最高的点GTP-C 报文字段完整、解码标准、因果清晰。4.2 三个必会的Wireshark过滤表达式与字段判读假设 Gn 口已经抓到 pcap我常用的三个过滤表达式如下# 只看GTP-C控制面信令过滤掉GTP-U用户面流量 gtp.type 0 # 只看某个用户或某个APN的PDP上下文创建消息 frame contains cmnet gtp.type 0 # 只看Create PDP Context Response消息类型17定位GGSN回的成功/失败原因 gtp.type 0 gtp.message_type 17第一条过滤把所有 GTP-U 数据报文滤掉只留控制面直接少掉 95% 的流量。第二条在控制面里按 APN 字符串过滤适合单个用户投诉时按 IMSI 或 APN 快速圈定会话。第三条精确到 PDP 创建响应适用于批量排查激活成功率。GTP-C 消息类型是必须记住的基础数字16 是 Create PDP Context Request17 是 Response18 和 19 是 Update PDP Context 的请求与响应20 和 21 是 Delete PDP Context 的请求与响应。在 Wireshark 里可以直接用 gtp.message_type 做过滤比手工翻包快得多。另一个技巧是列表里右键选中一条 GTP-C 消息用 Follow Stream 把整个 GTP 隧道里的相关消息串起来看比在包里逐条找清晰。一个重要的判读习惯每条请求必须有响应。Gn 口大量出现“只有 Request 没有 Response”时先查 GTP 回包路径上的防火墙和负载均衡设备这类设备经常只放行 TCP 不放行 UDP造成控制面单向丢包。4.3 关键参数表PDP类型、QoS与定时器怎么读对照指导书做分析时以下参数出现频率最高值得单独记住参数常见取值排查要点PDP TypeIPv4 / IPv6 / PPP类型与网络配置不符时直接拒绝QoS Delay class1 到 4协商值比请求值高说明资源受限QoS Throughput class1 到 9EDGE 场景常见协商到较低等级T3310秒级定时器可配PDP 激活超时超时重发多次即放弃T3330秒级定时器可配RAU 流程超时频繁 RAU 时重点看T3380秒级定时器可配Attach 超时反复重发说明 SGSN 未回复定时器具体数值不要死记出厂默认值在不同版本设备上有差异必须查本网设备配置。但定时器超时后的行为是一致的MS 端定时器超时会重发原消息重发超过次数上限就 abort 当前流程状态回退。所以 trace 里看到同一请求消息每隔 5 秒或 10 秒规律性重发就说明对端没有回应问题在网络链路或对端网元不在发起端。还有一个容易误读的参数协商 QoS。MS 请求的是上行/下行最大 bitrateGGSN 和 SGSN 按资源配置给一个协商值。协商值低于请求值不一定有问题可能只是无线资源紧张或用户签约等级限制但连续大量用户协商降级就要检查小区资源或 APN 限速配置。5. GPRS/EDGE信令分析避坑指南5个高频误判与排查经验这一章是实际项目里反复踩出来的坑。每条都按“现象、原因、解决”三段写对照自己的 trace 排查时会快很多。5.1 Attach Request反复重发原因却不在无线侧现象Um 口路测看 MS 一直发 Attach Request间隔稳定重发五六条后终端放弃显示无服务。无线指标、覆盖、干扰都正常。原因最初怀疑是无线侧问题但 Gn 和 Gr 口抓包后发现 SGSN 没有发出任何响应。根因是 SGSN 到 HLR 的 MAP 链路中断SGSN 无法完成 Update Location于是对 Attach Request 静默丢弃MS 端 T3380 超时反复重发。解决遇到规律性重发且无线指标正常直接去 SGSN 侧看 Gb 口有没有 BSSGP 上行再看 Gr 口 MAP 信令有没有 Update Location。链路恢复后附着立即成功。这个案例说明信令分析不能只看发起端要看响应端为什么不回话。5.2 PDP激活失败但错误码是Missing or unknown APN现象用户能正常附着但每次 PDP 激活都被拒终端提示无法上网。SGSN 日志显示 SM cause #26。原因APN 解析不到 GGSN。刚开始查 SGSN 的 APN 配置和 DNS发现配置都对。最后抓到 Activate PDP Context Request 原始报文发现 MS 发上来的 APN 带了尾部空格且大小写混杂SGSN 按精确匹配找不到。解决Gn 口用 frame contains 过滤出激活请求看 APN 字段的原始字节去掉空格并统一小写。SGSN 侧把 APN 配置改成宽松匹配或在 DNS 里补一条别名记录。这类问题排查时容易被“配置看着没问题”骗过去实际是终端侧组包不规范。5.3 Gb口抓包看到“乱序”就怀疑传输丢包现象Gb over IP 链路上抓包Wireshark 大量提示 UDP 乱序或丢包重传传输同事怀疑链路质量差。原因Gb 接口的 NS 层跑在 UDP/IP 之上不是 TCP。Wireshark 按 IP 包到达顺序做的统计提示不能代表 NS 层真的乱序。BSSGP 和 NS 有各自的序号和确认机制真正有问题时会看到 NS Status PDU 或 BSSGP 上下行帧数不对称。解决判断 Gb 口质量以 NS 层统计为准。查看 NS Status、NS-U 帧的上行下行计数忽略 IP 层的乱序提示。这个教训价值很大避免了一次完全没有必要的传输链路整改。5.4 RAU频繁且业务卡顿问题出在路由区规划现象用户沿主干道移动信令 trace 里 RAU 次数异常多数据业务时断时续。单看 SGSN 统计Gn 口 GTP-C 信令占比明显偏高。原因路由区边界切割太碎很多小区被分到不同 RAI。用户在一条街上移动连续触发 RAU每次 RAU 都伴随 SGSN 上下文交互和 HLR 位置更新业务面被信令挤压。解决用 SGSN counter 按小区统计 RAU 次数把高频 RAU 小区的 RAI 与周边小区核对重划路由区边界让主干道沿线的连续小区落在同一 RAI 内。这个问题改参数治不了必须动规划数据。信令分析在这里的意义是把“业务卡顿”翻译成“信令风暴”给规划侧一个明确抓手。5.5 信令全部正常但吞吐上不去别只盯信令面现象Gn 口信令全部成功附着和 PDP 激活都正常用户测速只有 20 kbps 左右EDGE 网络理论吞吐远不止这些。原因控制面健康不代表用户面健康。查 Um 口路测发现编码方式被固定到低阶 MCS-2RLC 重传率超过 30%无线侧才是瓶颈。Gn 口 GTP-U 反而没有任何丢包和乱序。解决在 Gn 口过滤 gtp.type 1 看 GTP-U 序列号跳变和重传同时看 Um 口路测的 MCS 分布和 RLC 重传。信令分析把问题圈定在无线侧后就不再怀疑核心网和传输。信令面正常时不要继续在信令里找原因直接换用户面指标去验证。这个“先信令后用户面”的顺序能省掉大量无效排查时间。6. 进阶用法把静态指导书变成日常排查的活字典6.1 把指导书改造成三列cause速查表指导书读一遍记不住最好的用法是改造成工具。我会把里面的失败流程和 cause 值整理成一张三列速查表第一列是 cause 值或消息名第二列是失败原因第三列是下一步动作。比如 GMM #7 对应“GPRS 服务不允许”动作为查 HLR 签约和 SGSN 黑名单SM #26 对应“APN 缺失或未知”动作为查 APN 组包和 DNS 解析。这张表贴在工位上比翻原文档快得多。6.2 用现网trace回放验证你的理解更进阶的做法是拿现网真实 trace 回放验证。选一个投诉案例从 Gb 口抓包一路解到 Gn 口对照指导书把每条消息的功能标出来标完一遍后这些流程就真正属于你了。我个人的教训是最早看这类资料从头翻到尾看完就忘后来改成“一次案例标一段流程”反而记住了大部分关键 cause 和定时器行为。信令分析是手艺活指导书是图纸动手拆一台机器才算学会。另外提醒一个习惯做信令分析时记录当时的基线数据比如 Gn 口 Create PDP Context 的平均响应时延、RAU 成功率。网络调整后拿新数据和基线对比才能知道改动是有效还是“玄学”。只定性不定量会让经验停留在感觉层面无法复制给团队。希望这个思路对你的排查工作有帮助也希望这套方法能帮你把手里那份静态指导书变成真正能解决问题的活字典。本文还有配套的精品资源点击获取 GPRS/EDGE信令流程分析指导书：从附着到PDP激活的排查实战
简介面向移动通信网络维护、优化与故障定位工程师的GPRS/EDGE信令流程专题资料出自华为官方技术文档。文档先讲Um接口协议栈与RLC/MAC核心概念RLC负责数据分段、重组与可靠传输MAC管理无线资源访问分配再按流程拆解上下行接入、TBF建立与释放、延迟释放及异常处理等真实场景。内容包括CCCH上的上行一阶段/两阶段接入、CCCH与PACCH上的下行TBF建立及失败处理、上行/下行TBF的正常与异常释放以及扩展上行TBF、上行/下行TBF延迟释放等优化流程并提供对应的信令时序与排错思路帮助读者定位无线侧问题、理解网络资源调度机制。资源共1个doc文件大小约2.05MB内部目录按接口、流程、优化三层组织便于快速翻查。目前已有84人学习浏览属于面向专业场景的实用技术资料。1. 一份GPRS/EDGE信令流程分析指导书能帮你解决什么做GPRS/EDGE网络优化的人最怕的不是参数不会配而是手机上报“能注册但上不了网”“附着失败”“PDP激活被拒”时手里只有一段看不懂的 trace 日志。GPRS/EDGE信令流程分析指导书这类资料就是把从 Um 口到 Gn 口的主要信令交互按场景拆开讲清楚MS 怎么附着、SGSN 怎么找 HLR、GGSN 怎么分配 IP、失败时回的 cause 值是什么意思。它解决的是“黑匣子”问题——让你拿到一段信令记录时知道先看哪条消息、下一步查哪个网元。适合刚接手核心网维护的新人也适合做网格优化的老手在跨网元定位问题时拿来对照。2. GPRS/EDGE信令分析先立框架接口、协议栈与关键网元信令分析最容易翻车的地方是拿着 IP 网络的报文习惯去解移动网信令。GPRS/EDGE 的信令是分层且带状态机的每层有独立的寻址和确认机制。不先把“这段报文出现在哪个接口、属于控制面还是用户面”搞清楚后面所有判断都会跑偏。所以拿到指导书第一件事不是翻流程而是看它的接口拓扑和协议栈分层。2.1 四类接口与两个平面先分清在哪抓包GPRS/EDGE 网络里信令主要出现在四条接口上。指导书一般会按接口分章节实际排查时我们也是按接口选抓包点。接口位置主要承载的信令抓包可行性UmMS 到 BSSGMM/SM承载在 LLC 之上终端路测可达GbBSS 到 SGSNBSSGP/NS上面跑 LLC 里的 GMM/SMSGSN 侧可达GnSGSN 到 GGSNGTP-C 控制面与 GTP-U 用户面核心网侧可达GrSGSN 到 HLRMAP 信令鉴权、位置更新需在 HLR/SGSN 侧看日志四条接口的分工很明确Um 口信令直接反映终端行为附着请求、PDP 激活请求都是从这里发起Gb 口是无线侧和分组核心网的分界线BSSGP 在这里终结Gn 口是 SGSN 和 GGSN 之间的 GTP 信令PDP 上下文能不能建立成功看这一口的 Create PDP Context 消息就够了Gr 口走 MAP 信令负责 SGSN 从 HLR 拉签约数据和做位置登记。实际分析优先级我一般按 Gn 口优先、Gb 口其次、Um 口最后来排。原因很简单Gn 口报文标准化程度最高Wireshark 直接解码cause 值齐全最容易快速区分“核心网问题”还是“无线/终端问题”。在 Gn 口看到 Create PDP Context Response 返回成功基本可以排除核心网侧会话管理的问题剩下就该去查用户面和无线质量。控制面和用户面的区分也很关键。GMM/SM、BSSGP、GTP-C 属于控制面负责移动性管理和会话管理用户面是 LLC 的数据部分和 GTP-U负责真正承载业务。很多初级分析把 PDP 激活失败归到无线侧其实在 Gn 口看一眼 GTP-C 响应里的 cause 值就能把问题圈定在核心网。2.2 协议栈分层先解 LLC 还是先看 GTP-CGPRS/EDGE 的协议栈是理解信令的骨架。控制面从 MS 往上走是 GMM/SM、LLC、RLC/MAC、GSM RF到 Gb 口变成 LLC、BSSGP、NS、Frame Relay 或 IP到 Gn 口则是 GTP-C、UDP、IP。这里最容易绕晕的是 LLC 层。早期 GPRS 里 GMM/SM 信令封装在 LLC 帧中到了 Gb 口由 BSSGP 承载所以 Gb 口抓包要先解 BSSGP 才能看到上层的 LLC 和 GMM/SM。后来不少设备做了 Gb over IP 改造NS 层跑到 UDP/IP 上解析思路不变只是底层从帧中继换成 IP。EDGE 的引入主要动的是 Um 口物理层和 RLC/MAC编码调制方式从 GMSK 扩展到 8PSK引入了 MCS-1 到 MCS-9 的调制编码等级单时隙吞吐从十几 kbps 提到五十多 kbps。但信令流程本身没有变GMM/SM 的消息类型、状态机和 GPRS 完全相同。所以拿这类指导书分析 EDGE 场景时重点要放在无线侧的编码方式、链路质量和 RLC 重传而不是重新学一遍信令交互顺序。判断一段 trace 该先解哪一层有个通用做法看抓包位置。Gn 口直接解 GTPGb 口先解 NS/BSSGP再去解 LLC 里的 GMM/SMUm 口路测软件通常已经帮你解好 LLC导出时能看到 GMM/SM 层字段。别在不该解 LLC 的 Gn 口报文里找 LLC 头这是新手最常见的无效操作。2.3 两条主线流程附着与 PDP 上下文激活指导书里信令流程列得很多但主线只有两条GPRS Attach 和 PDP Context Activation。附着解决“网络认不认识我”PDP 激活解决“能不能给我一条上网通路”。这两条走通了其他流程比如路由区更新、去附着、PDP 去激活都是在这两个状态机上做迁移。分析时先确定当前处于哪个状态。MS 在 SGSN 里有 IDLE、STANDBY、READY 三种移动性状态PDP 上下文状态是 INACTIVE 还是 ACTIVE。状态判断错了后面解读全错。比如手机在 STANDBY 状态下发送数据会先触发 Service Request 或 RAU不是直接建 PDP如果忽略了这一步就会觉得“流程少了消息”。所以我的习惯是拿到指导书先背状态迁移图再去看逐条消息。状态机是纲消息是目。纲举目张分析 trace 时才不会在细节里迷路。3. 把核心信令流程拆开附着、PDP激活、路由区更新的每一步框架立住之后就可以逐条流程拆解。这一章把三个最常用来做信令分析主线的流程讲透附着、PDP 上下文激活、路由区更新与小区更新。每条流程都按“消息顺序—关键字段—失败点”三层来看。3.1 GPRS附着流程从Attach Request到Accept的7步GPRS 附着是终端进入分组网络的第一步。常见流程是这么走的MS 在 Um 口发起 Attach Request携带 IMSI 或 P-TMSI、附着类型、MS 网络能力。SGSN 收到后如果 MS 携带的是 P-TMSI 且原 SGSN 不是自己SGSN 向旧 SGSN 发 SGSN Context Request把用户上下文取回来。SGSN 根据网络配置决定是否做鉴权。做鉴权时SGSN 从 HLR/AuC 取鉴权三元组向 MS 发 Authentication RequestMS 回 Authentication Response。SGSN 向 HLR 发 Update Location登记当前 SGSN 地址。HLR 返回 Insert Subscriber Data携带用户签约的 QoS、APN 列表。SGSN 向 HLR 确认收到签约数据然后向 MS 发 Attach Accept分配 P-TMSI 和新的 RAI。MS 回 Attach Complete附着流程完成。关键字段有三个需要盯。一是 Attach Type区分是 GPRS Attach 还是 Combined GPRS/IMSI Attach二是 MS Network Capability里面带了终端支持的 GEA 加密算法三是 Attach Accept 里的 P-TMSI Signature后续的 RAU 和 PDP 激活请求都要带上它丢了会导致 SGSN 重新走一遍鉴权和上下文检查。附着失败最常见三类原因加密算法不匹配典型现象是鉴权完成后 SGSN 发 Attach Rejectcause 是 GMM #7GPRS services not allowedHLR 签约数据异常Insert Subscriber Data 带不出 APN 列表终端附着成功但后续 PDP 激活一定失败跨 SGSN 附着时旧 SGSN 不可达SGSN Context Response 超时Attach Request 被静默丢弃。提示Attach Request 重发 N 次而 SGSN 完全无响应时优先怀疑 SGSN 与 HLR 的 MAP 链路或 SGSN 全局资源问题不要窝在 Um 口查覆盖。3.2 PDP上下文激活断开“能上网”的最后一道门附着成功只能说明终端注册到了 SGSN真正要上网必须激活 PDP 上下文。激活流程比附着短但每一步失败的含义更明确MS 发 Activate PDP Context Request携带 APN、请求的 QoS、NSAPI、PDP 类型。SGSN 根据 APN 做 DNS 解析或查本地 APN 配置确定 GGSN 地址。SGSN 向 GGSN 发 Create PDP Context Request带上 IMSI、APN、QoS 协商参数。GGSN 检查用户签约和 APN 配置返回 Create PDP Context Responsecause 为 0success即成功。SGSN 向 MS 回 Activate PDP Context Accept携带 GGSN 分配的 PDP 地址。这里有几个必须会读的字段字段作用出问题时的表现APN决定走哪个 GGSN 和外部 PDN解析失败时 SGSN 回 SM cause #26NSAPI标识终端上的 PDP 上下文重复时上下文冲突激活失败QoS Negotiated协商后的 QoS 参数比请求值低说明资源受限PDP AddressGGSN 给 MS 分配的 IP分配失败则激活被拒排查 PDP 激活失败有一个非常高效的做法在 Gn 口抓包过滤 Create PDP Context 消息看 Request 和 Response 是否配对出现。只有 Request 没有 Response说明 GGSN 没回应或链路中断有 Response 但 cause 不为 0就按 SM cause 表查原因。SM cause #26 是 APN 缺失或未知#29 是用户鉴权失败#31 是请求的服务未签约#32 是服务暂时不可用。这组 cause 值背下来现场能少翻很多文档。提示激活成功后马上被去激活多半是计费或策略问题例如 GGSN 侧流量配额用尽、在线计费系统无响应。此时要看 Gn 口的 Delete PDP Context Request 是谁发的由 SGSN 发起还是 GGSN 发起方向不同排查对象完全不同。3.3 路由区更新与小区更新移动场景的信令细节路由区更新分两类SGSN 内 RAU 和 SGSN 间 RAU。SGSN 内 RAU 流程短RAU Request、鉴权、RAU Accept 三步SGSN 间 RAU 要把用户上下文从旧 SGSN 拉到新 SGSN再向 HLR 做位置更新HLR 还会向旧 SGSN 发 Cancel Location。周期性 RAU 是指导书里一定会写到的点。MS 里的 T3312 定时器控制周期性 RAU在 STANDBY 状态下超时没做 RAUSGSN 会认为用户不可达。实际运维里 T3312 配太短信令量暴涨BSSGP 和 GTP-C 的负荷都上来配太长寻呼失败率升高。城区一般配 30 到 60 分钟农村可以放到 120 分钟左右具体以寻呼成功率统计为准。小区更新只在 READY 状态发生因为 READY 状态下 SGSN 要求精确知道用户在哪个小区。信令上它很短MS 发 Cell UpdateBSC/SGSN 确认。但这个流程最容易在无线侧失败尤其在切换参数配错、小区拥塞的场景里Cell Update 失败会直接导致 READY 状态悬挂用户表现为“信号满格但业务断流”。遇到掉线率高的小区先查小区更新成功率不要直接去查 Gn 口信令。4. 信令分析实操抓包位置、过滤表达式与参数判读流程拆完接下来是动手环节。信令分析最值钱的能力不是看消息名字而是知道在一堆报文的哪一层、哪个字段里找答案。这一章给出我日常定位问题的固定套路。4.1 抓包位置选择Um口、Gb口还是Gn口抓包位置由问题现象决定不是哪里方便抓哪里。三类常见场景的选择如下。用户投诉上网慢或打不开网页优先 Um 口路测拿到终端侧 RLC/MAC 的调制编码等级、重传率、BLER同时 Gn 口抓 GTP-U 看用户面吞吐。两侧对照能快速确认瓶颈在无线口还是核心网。附着失败或 PDP 激活失败优先 Gb 口和 Gn 口同时抓。Gb 口看 SGSN 有没有收到 BSSGP 上行的 Attach RequestGn 口看 SGSN 有没有向 GGSN 发 Create PDP Context以及 GGSN 回了什么 cause。这样的好处是每一步都有据可查不用猜。频繁跨 SGSN RAUGn 口抓 GTP-C 看 SGSN Context Request/ResponseGr 口看 HLR MAP 信令。多数运营商在 SGSN 侧有后台 trace 工具能直接按 IMSI 打点。没有后台工具时Gn 口镜像是最可行的降级方案。实操里最难的抓包点是老的 Gb 口 Frame Relay 链路。改用 Gb over IP 后容易得多端口镜像就能拿全 NS/BSSGP 报文。如果现场只有 SGSN 一侧的抓包条件Gn 口是性价比最高的点GTP-C 报文字段完整、解码标准、因果清晰。4.2 三个必会的Wireshark过滤表达式与字段判读假设 Gn 口已经抓到 pcap我常用的三个过滤表达式如下# 只看GTP-C控制面信令过滤掉GTP-U用户面流量 gtp.type 0 # 只看某个用户或某个APN的PDP上下文创建消息 frame contains cmnet gtp.type 0 # 只看Create PDP Context Response消息类型17定位GGSN回的成功/失败原因 gtp.type 0 gtp.message_type 17第一条过滤把所有 GTP-U 数据报文滤掉只留控制面直接少掉 95% 的流量。第二条在控制面里按 APN 字符串过滤适合单个用户投诉时按 IMSI 或 APN 快速圈定会话。第三条精确到 PDP 创建响应适用于批量排查激活成功率。GTP-C 消息类型是必须记住的基础数字16 是 Create PDP Context Request17 是 Response18 和 19 是 Update PDP Context 的请求与响应20 和 21 是 Delete PDP Context 的请求与响应。在 Wireshark 里可以直接用 gtp.message_type 做过滤比手工翻包快得多。另一个技巧是列表里右键选中一条 GTP-C 消息用 Follow Stream 把整个 GTP 隧道里的相关消息串起来看比在包里逐条找清晰。一个重要的判读习惯每条请求必须有响应。Gn 口大量出现“只有 Request 没有 Response”时先查 GTP 回包路径上的防火墙和负载均衡设备这类设备经常只放行 TCP 不放行 UDP造成控制面单向丢包。4.3 关键参数表PDP类型、QoS与定时器怎么读对照指导书做分析时以下参数出现频率最高值得单独记住参数常见取值排查要点PDP TypeIPv4 / IPv6 / PPP类型与网络配置不符时直接拒绝QoS Delay class1 到 4协商值比请求值高说明资源受限QoS Throughput class1 到 9EDGE 场景常见协商到较低等级T3310秒级定时器可配PDP 激活超时超时重发多次即放弃T3330秒级定时器可配RAU 流程超时频繁 RAU 时重点看T3380秒级定时器可配Attach 超时反复重发说明 SGSN 未回复定时器具体数值不要死记出厂默认值在不同版本设备上有差异必须查本网设备配置。但定时器超时后的行为是一致的MS 端定时器超时会重发原消息重发超过次数上限就 abort 当前流程状态回退。所以 trace 里看到同一请求消息每隔 5 秒或 10 秒规律性重发就说明对端没有回应问题在网络链路或对端网元不在发起端。还有一个容易误读的参数协商 QoS。MS 请求的是上行/下行最大 bitrateGGSN 和 SGSN 按资源配置给一个协商值。协商值低于请求值不一定有问题可能只是无线资源紧张或用户签约等级限制但连续大量用户协商降级就要检查小区资源或 APN 限速配置。5. GPRS/EDGE信令分析避坑指南5个高频误判与排查经验这一章是实际项目里反复踩出来的坑。每条都按“现象、原因、解决”三段写对照自己的 trace 排查时会快很多。5.1 Attach Request反复重发原因却不在无线侧现象Um 口路测看 MS 一直发 Attach Request间隔稳定重发五六条后终端放弃显示无服务。无线指标、覆盖、干扰都正常。原因最初怀疑是无线侧问题但 Gn 和 Gr 口抓包后发现 SGSN 没有发出任何响应。根因是 SGSN 到 HLR 的 MAP 链路中断SGSN 无法完成 Update Location于是对 Attach Request 静默丢弃MS 端 T3380 超时反复重发。解决遇到规律性重发且无线指标正常直接去 SGSN 侧看 Gb 口有没有 BSSGP 上行再看 Gr 口 MAP 信令有没有 Update Location。链路恢复后附着立即成功。这个案例说明信令分析不能只看发起端要看响应端为什么不回话。5.2 PDP激活失败但错误码是Missing or unknown APN现象用户能正常附着但每次 PDP 激活都被拒终端提示无法上网。SGSN 日志显示 SM cause #26。原因APN 解析不到 GGSN。刚开始查 SGSN 的 APN 配置和 DNS发现配置都对。最后抓到 Activate PDP Context Request 原始报文发现 MS 发上来的 APN 带了尾部空格且大小写混杂SGSN 按精确匹配找不到。解决Gn 口用 frame contains 过滤出激活请求看 APN 字段的原始字节去掉空格并统一小写。SGSN 侧把 APN 配置改成宽松匹配或在 DNS 里补一条别名记录。这类问题排查时容易被“配置看着没问题”骗过去实际是终端侧组包不规范。5.3 Gb口抓包看到“乱序”就怀疑传输丢包现象Gb over IP 链路上抓包Wireshark 大量提示 UDP 乱序或丢包重传传输同事怀疑链路质量差。原因Gb 接口的 NS 层跑在 UDP/IP 之上不是 TCP。Wireshark 按 IP 包到达顺序做的统计提示不能代表 NS 层真的乱序。BSSGP 和 NS 有各自的序号和确认机制真正有问题时会看到 NS Status PDU 或 BSSGP 上下行帧数不对称。解决判断 Gb 口质量以 NS 层统计为准。查看 NS Status、NS-U 帧的上行下行计数忽略 IP 层的乱序提示。这个教训价值很大避免了一次完全没有必要的传输链路整改。5.4 RAU频繁且业务卡顿问题出在路由区规划现象用户沿主干道移动信令 trace 里 RAU 次数异常多数据业务时断时续。单看 SGSN 统计Gn 口 GTP-C 信令占比明显偏高。原因路由区边界切割太碎很多小区被分到不同 RAI。用户在一条街上移动连续触发 RAU每次 RAU 都伴随 SGSN 上下文交互和 HLR 位置更新业务面被信令挤压。解决用 SGSN counter 按小区统计 RAU 次数把高频 RAU 小区的 RAI 与周边小区核对重划路由区边界让主干道沿线的连续小区落在同一 RAI 内。这个问题改参数治不了必须动规划数据。信令分析在这里的意义是把“业务卡顿”翻译成“信令风暴”给规划侧一个明确抓手。5.5 信令全部正常但吞吐上不去别只盯信令面现象Gn 口信令全部成功附着和 PDP 激活都正常用户测速只有 20 kbps 左右EDGE 网络理论吞吐远不止这些。原因控制面健康不代表用户面健康。查 Um 口路测发现编码方式被固定到低阶 MCS-2RLC 重传率超过 30%无线侧才是瓶颈。Gn 口 GTP-U 反而没有任何丢包和乱序。解决在 Gn 口过滤 gtp.type 1 看 GTP-U 序列号跳变和重传同时看 Um 口路测的 MCS 分布和 RLC 重传。信令分析把问题圈定在无线侧后就不再怀疑核心网和传输。信令面正常时不要继续在信令里找原因直接换用户面指标去验证。这个“先信令后用户面”的顺序能省掉大量无效排查时间。6. 进阶用法把静态指导书变成日常排查的活字典6.1 把指导书改造成三列cause速查表指导书读一遍记不住最好的用法是改造成工具。我会把里面的失败流程和 cause 值整理成一张三列速查表第一列是 cause 值或消息名第二列是失败原因第三列是下一步动作。比如 GMM #7 对应“GPRS 服务不允许”动作为查 HLR 签约和 SGSN 黑名单SM #26 对应“APN 缺失或未知”动作为查 APN 组包和 DNS 解析。这张表贴在工位上比翻原文档快得多。6.2 用现网trace回放验证你的理解更进阶的做法是拿现网真实 trace 回放验证。选一个投诉案例从 Gb 口抓包一路解到 Gn 口对照指导书把每条消息的功能标出来标完一遍后这些流程就真正属于你了。我个人的教训是最早看这类资料从头翻到尾看完就忘后来改成“一次案例标一段流程”反而记住了大部分关键 cause 和定时器行为。信令分析是手艺活指导书是图纸动手拆一台机器才算学会。另外提醒一个习惯做信令分析时记录当时的基线数据比如 Gn 口 Create PDP Context 的平均响应时延、RAU 成功率。网络调整后拿新数据和基线对比才能知道改动是有效还是“玄学”。只定性不定量会让经验停留在感觉层面无法复制给团队。希望这个思路对你的排查工作有帮助也希望这套方法能帮你把手里那份静态指导书变成真正能解决问题的活字典。本文还有配套的精品资源点击获取