简介《GPRS/EDGE信令流程分析指导书》是一份面向移动通信网络维护与优化工程师的华为技术专题资料系统梳理了Um接口上的信令交互机制适用于GPRS/EDGE网络故障定位、参数调优及日常巡检场景。文档从Um接口协议栈和RLC/MAC基本概念切入逐步展开上行一阶段/两阶段接入、CCCH与PACCH上的下行TBF建立及失败处理、上下行TBF正常/异常释放等核心流程并对扩展上行TBF、延迟释放等优化流程给出说明能帮助读者厘清数据业务异常时的信令脉络。资源打包为单个doc文件文件类型简洁体积约2.05MB下载后可离线查阅。目前已吸引83人浏览学习适合需要深入理解2.5G/2.75G数据业务信令细节的网优、网维人员作为案头参考。1. GPRS/EDGE信令流程分析这块硬骨头卡在“跨层关联”上从GSM时代过来的工程师都有印象GPRS/EDGE信令流程分析的难度不在抓包而在把十几层协议穿起来。和LTE/5G的纯分组核心不同GPRS/EDGE信令面跨Um、Gb、Gn/Gp、Gi四个逻辑段无线侧要看RLC/MACGb口要看NS和BSSGP到了Gn口又变成GTP-C一个Attach失败可能是无线覆盖、P-TMSI冲突或GGSN配置同时制造的假象。所谓2021-2022年专题资料里的GPRSEDGE信令流程分析指导书做的就是把常见附着、路由区更新、PDP上下文激活、去激活流程里的消息顺序、关键信元、计时器和原因码整理成一张可对照的图。它更像工作手册不是规范原文。如果你是核心网维护、无线优化、物联网接入调试或者要做信令自动回溯的工程师下面这套分析框架可以照着搭一遍。2. GPRS/EDGE信令分析前置接口、协议栈和关键标识对齐2.1 Um到Gi的四个关键接口先在心里画成一条消息流一次完整的分组数据业务在GPRS/EDGE网络里从终端走到Internet至少要穿过四段接口。手机和基站之间的Um接口承载RLC/MAC、LLC和GMM/SM消息BSS和SGSN之间的Gb接口是核心网分水岭从帧中继时代的NS到NS over IP变化比信令内容本身更大SGSN和GGSN之间的Gn接口用GTP-C/GTP-U承载Gp接口则是跨PLMN时的Gn走法GGSN出去到PDN的那段Gi已经不在GPRS标准约束范围内。分析信令时每一段抓包工具能看到的字段完全不同但归属的判断逻辑是同一套端着“消息从哪来、要往哪去、携带什么身份”去看。所以在打开抓包文件之前先确认这次分析的是哪个接口。Gn口抓包最常见的过滤器是udp.port 2123GTP-C控制面承载于UDP 2123用户面是UDP 2152Gb口若是IP化网络要先确定NS层的UDP端口不同厂家的PCU到SGSN端口并不一致通常可以在SGSN侧看BSSGP的源端口反推。端口不确认就抓包至少挡掉一半定位工作。2.2 接口对应的协议栈和常见抓包位置先拉一张对应表后续看字段名时会经常用到。接口协议栈常见抓包位置典型信令承载UmGSM RF / MAC / RLC / LLC / SNDCP / GMM/SMAbis口或BSS侧LMT跟踪RR、GPRS MM、SMGbNS帧中继或IP/ BSSGP / LLC / SNDCP / GMM/SMPCU与SGSN之间BSSGP PDU、LLC帧Gn/GpUDP/IP / GTP-C、GTP-USGSN与GGSN之间的汇聚交换机Create PDP Context Request/ResponseGiIP / GRE / L2TPGGSN上行用户IP包一般不分析信令这段对应关系决定了后面用Wireshark时应该展开哪层。在Abis口上看到的是RR和ABM链路在Gb口上看到的是NS和BSSGP在Gn口上则看到的是GTP。分析人员最常犯的错是在Gn口抓包后去找LLC层字段那永远找不到因为Gb口和Gn口之间的协议栈已经在SGSN内部做了转换。2.3 信令消息能对上号全看这几个标识GPRS/EDGE信令分析里大量时间花在“匹配多个接口的同一用户”上。手机一开机先在Um口上报IMSI或P-TMSIBCCH广播的RAC和LAC合成RAIRAI和GCI就是用户位置标签。SGSN分配了P-TMSI之后后续消息里很少再带IMSI取而代之的是P-TMSI加RAI校验在Gb口上还要用TLLI来区分NS层的逻辑链路。到Gn口时GTP-C的消息里已经没有IMSI了SGSN和GGSN主要靠TEID和NSAPI来标识PDP上下文。每当多个TEID、TLLI、IMSI交织在一起时先列一张标识关联表比反复打开消息片段找字段更可靠。标识作用范围主要关联IMSI全网唯一用户归属、计费P-TMSI当前RAI内唯一隐式识别MS减少IMSI暴露TLLIGb接口LLC链路识别MS和SGSN之间的逻辑链路RAI/GCI无线位置RAU和Cell Update判断NSAPI移动端到GGSN关联PDP上下文和SNDCPTEIDGTP隧道端点Gn接口上下行数据面关联后面章节里提到的“挂起流程”“重复T3380”这类问题本质都是在这些标识匹配不上时出现的。2.4 先拿tshark把GTP-C消息拉成表工具安装之后第一步不是开图形界面而是用命令行把信令帧变成表格。过滤抓包文件中的GTP-C流量是Gn口最常见的操作。执行下面的命令会把报文关键信息放在CSV格式的控制台输出里tshark -r /data/gn_capture.pcap -Y udp.port 2123 \ -T fields -E headery -E separator, \ -e frame.number -e frame.time_relative -e ip.src -e ip.dst \ -e gtp.message_type -e gtp.teid -e gtp.sequence_number这里-Y参数是显示过滤器udp.port 2123能把GTP-C协议报文全部筛出来前提是抓包时没有剥离VLAN或叠加隧道-E headery让tshark输出文件头便于后续脚本直接读取。gtp.message_type字段输出十六进制的GTP消息类型数字gtp.teid是隧道端点标识gtp.sequence_number是GTP事务序号。这三列放在一起已经能拼出“谁在什么时候、对哪个TEID做了什么操作”。3. 用Wireshark把GPRS/EDGE信令流程拆成可对照的序列3.1 分析前先定三条基线时间、方向和上下文信令分析最容易被“一条消息一对参数”带偏。你打开一个抓包文件如果只盯着某个字段看往往不知道这条消息是请求还是重传也不知道是不是另一条失败流程的旁证。我在拿到任何GPRS/EDGE信令抓包后会先对齐三件事时间基准、消息方向、用户上下文。时间基准放在frame.time_relative上而不是绝对时间戳。一个完整流程可能跨好几分钟纯时间看不出重传间隔相对时间可以精准看到T3310/T3380这类定时器的超时。消息方向看ip.src/ip.dstG b口上则按NS层BSSGP的PDU类型区分UL-UNITDATA表示上行DL-UNITDATA表示下行。用户上下文则是前面说的TLLI、TEID、P-TMSI组合先把这列建出来后面每看一条消息都往这个索引里填。3.2 Wireshark显示过滤器里最常用的三组口子在Wireshark界面里最快的方式是直接用三组过滤器切换视角。抓包位置显示过滤器用途Gn/Gp口gtp或udp.port 2123查看GTP-C控制面Gb口llc.sapi 1查看LLC上的GMM/SM信令Gb口tlli 0x2916按TLLI锁定某个用户llc.sapi 1是把LLC层的SAPI字段限定为1GMM和SM消息都承载在SAPI 1上用户面数据通常走SAPI 3、5、9等这样可以快速把信令和业务分开。tlli字段在Wireshark里会同时显示多个变种例如本地TLLI和全UL TLLI建议把tlli.type也放出来否则同一个逻辑链路的帧可能被拆成两段。3.3 事务合并用CSV输出把请求和响应拼成一行显示过滤器只是缩小范围真正要看的是同一个用户、同一次流程的请求和响应是否成对出现。给一个可复现的命令组合用于快速找到Gn口某个PDP激活流程的起止tshark -r gn.pcap -Y gtp.message_type 16 || gtp.message_type 17 \ -T fields -E headery -E separator, \ -e frame.number -e frame.time_relative -e ip.src -e ip.dst \ -e gtp.teid -e gtp.message_type -e gtp.cause | awk -F, NR1{if($616){start[$5]$0} else if($617){print start[$5] - $0}}awk脚本以TEID作为key先将消息类型16的请求行存入start数组等到同TEID出现消息类型17的响应时把请求和响应打印在同一行。输出中会看到请求帧号和响应帧号以及相对时间这两帧之间的时间差就是GTP-C层的建链耗时。在大量重复PDP激活的场景里这个脚本能快速把每次激活的耗时列出来哪次超过3秒就优先点开看中间丢了什么消息。如果中途还有Update PDP Context需要把18/19号消息一起纳入匹配逻辑否则可能漏看SGSN和GGSN之间的协商过程。4. GPRS/EDGE信令流程逐段拆解附着、PDP激活和路由区更新4.1 GPRS Attach流程从Attach Request的TLLI到Attach AcceptGPRS附着的目的是让网络知道MS已经具备无线接入能力然后分配P-TMSI和TLLI。这里要强调虽然GPRS Attach经常和IMSI附着一起做也就是Combined Attach但GPRS附着本身不建立用户面承载它只建立MM上下文。一个标准的附着流程通常有9条消息但分析时不必背消息名而是抓“MS标识变化”这条主线。首条Attach Request往往携带P-TMSI如果网络不认得这个P-TMSISGSN会在Identity Request里要求回传IMSI接着做鉴权、加密模式切换最后SGSN下发Attach Accept。Attach Accept中最关键的两个字段是TLLI和P-TMSITLLI用于Gb口的LLC链路P-TMSI用于下一次快速附着。最后MS返回Attach Complete整个流程才算结束。步骤方向消息关键字段1MS - SGSNAttach RequestP-TMSI或IMSI、MS Network Capability、RAI2SGSN - MSIdentity Request可选Identity Type IMSI3MS - SGSNIdentity ResponseIMSI4SGSN - MSAuthentication RequestRAND5MS - SGSNAuthentication ResponseRES6SGSN - MSSecurity Mode Command加密算法列表7MS - SGSNSecurity Mode Complete无8SGSN - MSAttach AcceptP-TMSI、TLLI、RAU定时器9MS - SGSNAttach Complete无实际网络中如果Attach Request里已经带IMSIIdentity Request/Response可以省略如果网络允许不带IMSI附着甚至不会触发鉴权。分析时发现只有Attach Request没有Auth Request不一定是设备异常先看SGSN是否配置了低鉴权级别。反而要警惕的是Attach Complete先于Attach Accept出现这种情况多半是解析错位直接看原始十六进制字节。4.2 Activate PDP Context从APN请求到TEID双向建立PDP上下文激活才是真正创建用户面承载的流程。在GMM完成后MS通过Activate PDP Context Request发起SGSN判断签约数据和APN地址解析后向GGSN发GTP-C的Create PDP Context RequestGGSN返回Create PDP Context ResponseSGSN再给MS回Activate PDP Context Accept。分析这条流程时要同时跟踪MS侧NAS消息和Gn口的GTP消息。tshark -r gn.pcap -Y gtp.message_type 16 || gtp.message_type 17 \ -T fields -E headery \ -e frame.number -e frame.time_relative -e ip.src -e ip.dst \ -e gtp.teid -e gtp.message_type -e gtp.cause -e gtp.apngtp.apn只在GTP-C的消息体内存在Wireshark能解析出来。Create PDP Context Request里通常能看到APN名称、QoS、SGSN地址Response里则能看到GGSN分配的PDP地址和下行TEID。如果Request里有APNResponse里却带PDP地址这条流程基本就成功了若Response里带Cause且没有PDP地址说明GGSN拒绝了会话。关键警觉点Gn口抓包时Create PDP Request的TEID字段通常为零因为这是SGSN发给GGSN的第一个GTP-C消息还没有分配下行TEID。如果此处发现TEID非零说明传递的是经过用户面绑定的TEID不是纯新建流程。第4步回到MS侧时如果MS主动发Deactivate PDP Context Request多半是手机本地配置的APN和网络侧协商的QoS不匹配例如网络返回的QoS profile版本不被终端接受。4.3 Routing Area Update跨SGSN的RAU要看GTP-C是否出现路由区更新是GPRS里最高频的移动性流程。MS跨路由区时要汇报新的RAI跨SGSN时还要做SGSN context transferGn口会出现Update PDP Context Request/Response成对消息。单从信令数量看RAU比Attach还要多几种。分析RAU最重要的一点是确认上下文是否在SGSN间完成切换。同一SGSN内RAU过程中SGSN不会重新分配P-TMSI跨SGSN的RAU则会在RAU Accept里带新的P-TMSI并释放旧SGSN上的LLC和PDP信息。如果RAU Request里的旧RAI和新RAI相同但TLLI不是网络侧分配的TLLI多半是MS刚重新开机或离开覆盖一段时间后回到原路由区网络会把这次RAU当作新附着处理必要时发起Identity Request。抓包看到RAU Request后紧跟Identity Request是这一类的典型标记不要误判为异常。实操上RAU流程在Gn口产生的GTP-C消息通常只有跨SGSN时才出现。如果Gn口抓包没有Update PDP Context相关消息那RAU只停留在G b口和SGSN内部之后要去检查无线端或新SGSN的邻区配置而不是在核心网侧继续找原因。4.4 Detach和PDP去激活主动与被动在信令里的区别Detach分成两类MS发起的GPRS Detach以及网络侧发起的Detach Request后者通常带Cause值3或10。PDP去激活的关键字段是NSAPI而不是APN。多PDP场景中去激活一条PDP上下文时只带NSAPI不带APN。检查时如果发现去激活的NSAPI和前面激活时的NSAPI不一致比如激活的是NSAPI 5但去激活消息里写的是NSAPI 6说明终端又建立了一条独立承载这不是同一条流程需要把两条承载先后关系排出来再看。5. 从GPRS/EDGE信令流程异常反推问题原因码、计时器和验证点5.1 原因码仍然是第一突破口信令分析里原因码分三层GMM层原因码出现在Attach或RAU的响应和拒绝消息中SM层原因码出现在PDP上下文激活的拒绝消息中GTP-C原因码出现在Create PDP Context Response等消息中。三层原因码名称相似但含义范围完全不同分析时先分清是哪一层。常见的GMM/SM原因码和处理方向如下表。所在层值含义一般处理方向GMM7GPRS services not allowed检查HLR签约和SGSN黑名单GMM11/12/13PLMN/LAC/Roaming not allowed检查RA、MCC/MNC和漫游协商GMM30Authentication failure检查鉴权参数和HLR数据SM26Insufficient resources检查GGSN容量和APN限流SM27Missing or unknown APN检查UE的APN和SGSN APN数据库大小写SM31Requested service option not subscribed检查签约中PDP上下文订阅列出的值对应TS 24.008的GMM和SM层Cause。拿到一个数值后先看它出现在哪条消息里。如果Cause出现在GTP-C响应中就不能再按24.008来解读而要去看TS 29.060的GTP-C Cause值定义两者不能混用。很多刚入门的排查者把GTP-C Response里返回的某个数字当成SM层原因码导致在GGSN配置里找了半天无线侧问题。5.2 计时器和重复请求从时序看超时GPRS/EDGE信令的计时器是另一个重要的诊断维度。MS侧和网络侧都有T3310、T3380、T3390这类计时器分别管辖Attach、RAU、PDP激活的重传。当请求发出后计时器超时请求会被重发重发多次仍无响应流程最终被放弃。使用frame.time_relative能直接看到两次相同TLLI的Attach Request之间是否相隔约15秒。如果间隔接近15秒说明这是T3310触发的重传不是终端重新发起的第二个流程。计时器关联流程常见设置T3310GPRS Attach15秒T3380Routing Area Update15秒T3390PDP Context Activation15秒重传出现时逐条看Response方向的消息是否有任何故障。如果只有Request和重传的Request却没有网络侧任何回包问题多半在网络侧没有把消息送给对端或对端处理卡死如果每次Request后都有明确的拒绝消息那就要转去分析原因码而不是计时器。5.3 “挂起流程”的判断方法MS短暂掉网时SGSN可能会启动挂起流程保留用户上下文但暂停数据转发。恢复后MS可能在同一个路由区直接恢复服务。抓包中判断挂起流程要留意Gb口的LLC帧是否出现某种层次的无响应常见表现是同一TLLI上的信令帧突然停住接下来没有任何GMM/SM消息也不去激活。这时要结合无线侧覆盖日志看MS是否进入盲区而不是在核心网信令上继续等下一跳消息。tshark -r gb.pcap -Y llc.sapi 1 -T fields \ -e frame.time_relative -e tlli -e bssgp.pdu_type -e llc.command \ -E headery | awk -F\t $2previous{...}这里的awk示意并不追求完整逻辑而是表达一个思路把同一TLLI的相邻消息按时间排序通过相邻帧时间差超过阈值来找断层。真实环境中我一般会把阈值设在15秒以上超过这个间隔又没有其他信令就可以判定流程存在中断窗口。6. 用一个小工具把GPRS/EDGE信令流程分析固化成可复现检查6.1 用tshark导出GTP-C事务交给python核对当前面的流程拆解开始重复执行时再手工看每一条抓包就很低效。常见做法是导成CSV后交给python脚本判断关键消息类型是不是成对出现。下面这个脚本可以处理tshark的-E headery输出把Create/Update/Delete PDP Request和Response按TEID合并显示import csv import sys # GTP-C消息类型到名称的映射只列关键类型 gtp_names { 16: Create PDP Context Request, 17: Create PDP Context Response, 18: Update PDP Context Request, 19: Update PDP Context Response, 20: Delete PDP Context Request, 21: Delete PDP Context Response, } reader csv.DictReader(sys.stdin) for row in reader: msg_type row.get(gtp.message_type, ).strip() if msg_type in gtp_names: teid row.get(gtp.teid, ) time row.get(frame.time_relative, ) print(f{time:10} {gtp_names[msg_type]:28} TEID{teid})使用这个脚本时先用tshark把指定字段导出为CSV再pipe给python脚本tshark -r gn.pcap -Y gtp -E headery -T fields \ -e frame.time_relative -e gtp.message_type -e gtp.teid \ | python3 gtp_flow.py这个脚本的价值不是替代分析而是让同一套过滤和判断每次保持一致。它在流程比对和回归验证时特别好用昨天定位的APN问题改完后第二天重新抓包再跑一遍它就能确认16/17、18/19、20/21这三级消息是否全部正常出现。6.2 给一段抓包做“快速验尸”的三条命令当拿到一段来路不明的抓包时可以先执行三条命令做初步定性。第一条看GTP-C保活是否正常tshark -r gn.pcap -Y gtp.message_type 1 -c 5第二条看该文件里是否存在Create PDP请求tshark -r gn.pcap -Y gtp.message_type 16 -c 10第三条看是否有网络侧返回的GTP-C出错tshark -r gn.pcap -Y gtp.message_type 17 gtp.cause ! 16 -T fields -e gtp.cause -e gtp.teid。这三条命令跑完基本能判断问题属于“网络没处理”“网络拒绝”还是“纯粹抓到了奇怪的包”。6.3 和指导书对照时的三个检查点手头有指导书时真正有效的对照不是逐条匹配消息名而是重点看三处。第一处是流程发起原因例如PDP激活时使用的APN和签约数据是否一致指导书里通常画在消息表格上方的前提条件里。第二处是特定场景的旁路分支如P-TMSI不匹配时会不会触发Identity RequestRAU跨SGSN时是否必须出现GTP-C消息这些分支是排查的“临界点”。第三处是计时器和Cause值指导书里的每个流程图都会标出超时重发条件和抓包里的实际间隔拿在一起看可比单纯看文字更早确认故障方向。这样下来信令流程分析就不再是靠感觉翻包而是一套每次都能复现的检查动作。本文还有配套的精品资源点击获取