简介围绕S1数据转发测试整理的docx小结面向移动通信核心网、无线侧测试人员及协议分析学习者聚焦切换过程中用户面数据连续性验证。内容从切换前后的数据流向入手梳理SGW、源eNodeB与目标eNodeB间的转发路径结合TEID与Sequence Number说明GTP隧道标识和包序判断并按测量报告、切换决策、接纳控制、HANDOVER COMMAND、RRC重配置、数据转发、UE同步至资源释放的主线拆解各信令节点的观察重点。文中列出Data Forwarding检查点包括End Marker的触发与转发、源小区数据传送地址向源与目标转发地址切换以及HANDOVER NOTIFY后目标小区数据传送地址的变化便于对照抓包判断转发是否完整。包内共1个docx文件约769KB适合作为测试记录与排错参考。已有305人学习可帮助初、中级测试人员建立S1切换数据转发的检查思路。1. 一次切换后业务静默 30 msS1 data forwarding 的测试到底在测什么上个月在一套模拟项目里做切换压测UE 从 source eNB 切到 target eNB信令面一路顺畅HANDOVER NOTIFY 按时落地可下行速率曲线在切换点还是凹了一块静默大约 30 ms。信令全绿、业务掉坑这类问题最后多半要回到 S1 data forwarding 的转发链路里找原因——抓包一看SGW 发出的 End Marker 停在源侧没有被转发出去目标侧一直在等那个“没有更多数据”的信号。S1 data forwarding 就是切换期间在源侧和目标侧之间搬用户面报文的那段机制测的是切换过程中有没有丢包、乱序、多转。正在做切换特性验证、S1 接口测试或者要定位切换掉话和速率凹坑的工程师都绕不开它尤其是手里已经有抓包、却不知道从哪几个字段下手的同学。2. 数据流向的三段路从 sgw→source eNB 到 sgw→target eNB 的路径切换2.1 切换前、切换中、切换后三条下行路径把一次切换拆成时间轴下行用户面其实只有三段路测试的全部难点在于第二段路要走多久、走哪条隧道、什么时候收尾。切换前SGW 把下行 G-PDU 打到源 eNB 为这个 E-RAB 分配的 S1-U 下行 TEID 上文档里记的是0x01001008这是源小区正常的数据传送隧道业务全程走它跟切换流程没有关系。这段时间的检查点是“源小区 DL 传送 TEID 上的包必须连续”一旦在测量报告之前就出现空洞问题不在转发要去查空口和承载配置。切换执行阶段是整条链路最容易翻车的地方。SGW 收到 MME 的路径切换相关信令之前仍然把下行数据发往源 eNB但源 eNB 已经通过 RRCConnectionReconfiguration 让 UE 往目标小区走了它不能把这些包继续往空口上灌只能在自己的转发隧道上重新封装送出去。如果源和目标之间没有直接可达的 IP 路径这些包要先回到 SGW再由 SGW 转到目标 eNB于是路径就变成了 sgw→source eNB→sgw→target eNB。文档里0x0000115b和0x01000a09这两个值就是这段绕行路上的两个端点前者是源侧转发隧道用的标识后者是目标侧为转发分配的隧道标识。切换成功后SGW 收到 HANDOVER NOTIFY 触发的路径切换完成把下行改到目标小区正常的数据传送隧道文档里记的是0x01000a08。注意这个值和0x01000a09只差一个低位很多人在抓包里一眼扫过去就混了结果把转发阶段的包算进了切换后得出一堆“切换后仍然乱序”的假结论。两者的角色完全不同0x01000a09只在转发窗口内有效0x01000a08是切换后长期承载业务的隧道。角色文档中的值分配方谁往这个隧道发生效时刻源小区 DL 传送 TEID0x01001008源 eNBSGW切换前长期源侧转发 TEID0x0000115b源 eNB间接转发时由 SGW 侧对接源 eNBRRC 重配之后目标侧转发 TEID0x01000a09目标 eNB源 eNB 或 SGW切换准备完成、源侧收到 HANDOVER COMMAND 之后目标小区 DL 传送 TEID0x01000a08目标 eNBSGWHANDOVER NOTIFY 之后表里的四个值来自这份测试小结的记录实际抓包里以gtp.teid字段为准。测试时把这四个值提前写进过滤脚本的常量表比每次现场翻文档靠谱得多。2.2 直接转发与间接转发选型依据不是偏好是可达性数据转发有两条实现路径测试方法完全不一样混着测就会得出互相矛盾的结论。直接转发是源 eNB 拿到目标 eNB 分配的转发隧道标识后直接把用户面报文封进去发给目标 eNB中间的 SGW 完全不参与间接转发是源 eNB 把报文发回 SGW由 SGW 再转给目标 eNB也就是文档里那条“绕一圈”的路径。判定走哪条核心看源 eNB 与目标 eNB 之间有没有可用 IP 通路以及切换类型。S1 切换场景下源和目标往往属于不同厂家的设备池中间隔着安全域和防火墙策略直接转发经常不具备条件常见做法是走间接转发。X2 切换时源和目标之间本来就有 X2 接口直接转发的概率高得多。但这不是铁律S1 切换也允许直接转发前提是核心网侧给源 eNB 下发的透明容器里带上了可直达的目标侧转发地址。所以在测试用例设计时不要按“S1 间接转发”去写死预期应该从 HANDOVER REQUEST ACKNOWLEDGE 里的传输层地址去判断本次实际走的是哪条。对比项直接转发间接转发报文路径source eNB → target eNBsource eNB → SGW → target eNB依赖条件源与目标 IP 可达源与 SGW、SGW 与目标均可达转发隧道数量1 条源到目标2 条源到 SGW、SGW 到目标多一跳带来的影响无增加时延与乱序概率常见场景X2 切换、同池同域S1 切换、跨域跨厂家测试关注点目标侧转发 TEID 是否用对两段隧道是否都建起来、End Marker 是否逐跳传递如果现场抓包发现只有一条转发隧道的流量、且目的 IP 直接就是目标 eNB 的地址那就是直接转发如果看到源侧发出的转发包目的地址是 SGW再由 SGW 发出另一组包到目标就是间接转发。这个判断只需要看ip.dst和gtp.teid两列一分钟能确认。2.3 End Marker 的语义它不是业务包是转发链路的收尾信号End Marker 这个包里没有用户数据它的作用只有一个告诉对端“我这边没有需要转发的数据了你可以停止转发业务”。文档里写得很清楚SGW 在把下行路径切到 target 之前向 source 发一个 End Markersource 收到后把它在转发隧道上继续送给 target源侧用户面的转发任务到这里就算完成。少了这一步目标侧不知道转发流什么时候结束要么一直等着要么提前把转发隧道的包丢掉两种都会造成切换点的业务空洞。在 GTP-U 里End Marker 的类型值是 0xfe普通 G-PDU 是 0xff。这两个值必须记牢很多人写了gtp.message 0之类的过滤条件自然是抓不到。另外End Marker 这个包的 TEID 字段按规范是填 0 的部分实现会填隧道值所以过滤时最好不要只靠 TEID直接用消息类型更稳。End Marker 是双向的上行和下行各有一个测试时容易只盯下行。上行方向由源 eNB 在切换前向 SGW 发 End Marker表示上行转发结束下行方向由 SGW 在切换前向源 eNB 发。两个方向的时间点不一致是正常的但只要有一个方向的 End Marker 丢了对应的那半边业务就会在切换点出现一段“多发”或者“早停”。我在模拟项目里遇到的那次 30 ms 静默根因就是下行 End Marker 在源侧被丢弃目标侧一直到 RRC 重配完成之后才开始正常收包。测试 End Marker 的关键检查有三条一是有没有发源侧和 SGW 侧各抓一次二是有没有转发看源侧转发隧道上是否出现同类型的包三是发完之后还有没有业务包正常情况 End Marker 之后该方向的转发隧道上不应再出现 G-PDU。第三条最容易漏测也最容易暴露源侧“以为切完了”提前停转发的问题。3. TEID 与 Sequence NumberGTP-U 隧道端点的识别与乱序判定3.1 TEID 是本地标识不是全局地址TEID 用来标记 GTP 隧道的端点一条承载的每个方向各有一个 TEID由接收侧分配、对端使用。这意味着同一个业务在源侧和目标侧看到的 TEID 必然不同而且同一个 TEID 值在不同网元上可能被复用。测试时把 TEID 当成“会话 ID”去全局追是最常见的误解之一。文档里那四个十六进制值之所以要单独列出来就是因为它们分别属于不同的端点和不同的阶段离开上下文单看一个值说明不了任何问题。正确做法是建立“隧道四元组”源 IP、目的 IP、TEID、方向。一条下行转发隧道的四元组是源 eNB 地址 SGW 地址 源侧转发 TEID对应的反向隧道四元组完全不同。抓包分析时先按四元组归类再看每类的包数和时间窗口比按单个 TEID 过滤可靠得多。S1AP 侧传递的 GTP-TEID 字段和 GTP-U 头里的 TEID 必须能对上对不上就说明承载映射错了这一类错误在跨厂家组网里出现频率不低。还有一类边界要提前知道TEID 值 0 是保留的用于 End Marker 和 Echo 这类没有承载语义的消息。所以看到gtp.teid 0的包不要当成异常先看消息类型。同样如果某个本该有业务的隧道上出现了 TEID 0 的 G-PDU那才是真的异常多半是转发实现里把隧道标识填错了。3.2 Sequence Number 与 PDCP SN 不是一回事GTP-U 头部带一个可选的 Sequence Number只有在 E、S、PN 标志位置位时才存在。它由发送侧为每条隧道独立维护逐包递增16 位回绕作用是对端做乱序检测和重复包丢弃。这个字段在转发测试里非常有用因为转发隧道是新建的SN 从哪个值开始、是否连续直接反映了源侧转发实现的质量。需要特别提醒的是GTP-U 的 SN 和 PDCP 层的 COUNT 是两套完全独立的编号。前者只在本跳 GTP 隧道内有效出了这个隧道就没有意义后者是端到端的靠 SN Status Transfer 在源和目标之间同步。测试时经常有人拿 GTP-U 的 SN 去比对 SN Status Transfer 里的 PDCP SN发现对不上就报缺陷实际上是两回事。文档里第 3 点提到的“sequence number 是数据流量”指的就是 GTP-U 这一层的计数它服务于转发链路的连续性检查不承担端到端排序职责。真正要检查的是三件事转发隧道上的 SN 是否单调递增且无明显跳变切换后目标小区新隧道上的 SN 起始值是否符合实现预期有的实现从 0 开始有的延续计数同一 SN 是否在短时间内重复出现。第三条如果命中基本可以判定为转发路径上存在重传或双份投递配合抓包点的位置可以快速定位到是源侧重复发还是 SGW 重复转。3.3 用 tshark 把隧道、序列号和 End Marker 一次导出来现场抓包通常是多个网元同时抓时间基准不一致先做一次字段级导出比直接看 Wireshark 界面高效得多。下面三条命令分别解决“全量导出”“只看 End Marker”“按 TEID 聚合”三件事。# 1) 全量导出 GTP-U 关键字段输出 CSV 供后续脚本处理 tshark -r ho_s1u.pcapng -n -Y gtp \ -T fields -E headery -E separator, \ -e frame.number -e frame.time_relative \ -e ip.src -e ip.dst -e udp.srcport -e udp.dstport \ -e gtp.message -e gtp.teid -e gtp.seq \ gtp_s1u.csv # 2) 只保留 End MarkerGTP-U 消息类型 0xfe确认两个方向都发了 tshark -r ho_s1u.pcapng -n -Y gtp.message 0xfe \ -T fields -e frame.number -e frame.time_relative \ -e ip.src -e ip.dst -e gtp.teid # 3) 按 TEID 聚合 G-PDU输出包数与首末时间用于对齐四个隧道 tshark -r ho_s1u.pcapng -n -Y gtp.message 0xff \ -T fields -e gtp.teid -e frame.time_relative \ | awk {c[$1]; if(!($1 in f)) f[$1]$2; l[$1]$2} END{for(t in c) printf %s,%d,%.3f,%.3f\n, t, c[t], f[t], l[t]} \ | sort -t, -k3 -n第一条命令的-Y gtp是显示过滤器只保留 GTP 协议报文-e gtp.message输出消息类型0xff 是业务包、0xfe 是 End Marker-e gtp.seq输出序列号若该包没置 S 位这一列会是空值空值本身也是一个检查点说明发送侧没开序列号。第二条命令把 End Marker 单独拎出来重点看ip.src和ip.dst是不是符合预期的转发路径间接转发下应该能看到两段。第三条命令用 awk 做聚合f[]记录每个 TEID 的首包时间、l[]记录末包时间排序后一眼就能看出哪个隧道的时间窗口偏了。导出之后不要急着下结论。先确认抓包点S1-U 上的抓包只能看到 SGW 与 eNB 之间的流量如果本次是直接转发源到目标的转发流量根本不经过 S1-U 抓包点导出的结果里会缺一大块此时应该去 X2-U 或源与目标之间的互联链路上补抓。抓包点选错是转发测试里成本最高的错误因为所有后续分析都会建立在残缺数据上。4. 从 HANDOVER REQUIRED 到 HANDOVER NOTIFY转发参数是怎么传下来的4.1 信令序列与每一步的观察点切换流程的编号在文档里已经列全了从 0 的 Area Restriction Provided 一直到 17 的 Release Resources。测试时把这串编号贴在抓包软件的书签栏按号找包比凭记忆翻快得多。真正与转发强相关的只有其中几步4 的 HANDOVER REQUIRED、5 的 HANDOVER REQUEST、7 的 HANDOVER REQUEST ACKNOWLEDGE、8 的 Handover Command、10 和 11 的 Status Transfer、15 的 HANDOVER NOTIFY。步骤消息方向转发相关的观察点2Measurement ReportsUE → 源 eNB触发切换的无线条件与转发无关但决定时间窗4HANDOVER REQUIRED源 eNB → MME源侧提出的目标小区与承载列表5HANDOVER REQUESTMME → 目标 eNB携带源侧的上行转发隧道信息6Admission Control目标 eNB 内部决定哪些承载被接纳7HANDOVER REQUEST ACKNOWLEDGE目标 eNB → MME目标侧 eNB UE S1AP ID、目标小区数据隧道标识、目标小区数据转发隧道标识8Handover CommandMME → 源 eNB源侧从这里拿到转发目标地址9RRC Conn. Reconf.源 eNB → UE这一包发出后源侧下行应切到转发隧道10/11eNB/MME Status Transfer源 → MME → 目标PDCP SN 与 HFN 的同步15HANDOVER NOTIFY目标 eNB → MME触发路径切换SGW 改发目标小区隧道16/17UE Context Release / Release ResourcesMME → 源 eNB源侧资源释放转发隧道随之拆除第 7 步是整条链路的参数源头。目标 eNB 在完成资源分配和切换入的承载接纳处理后如果资源满足、小区接入允许就给 MME 回 HANDOVER REQUEST ACKNOWLEDGE里面带目标侧分配的 eNB UE S1AP ID以及接纳成功的每个 EPS 承载对应的目标侧数据传送地址具体是两个值目标小区数据隧道标识用于切换完成后 SGW 直接发目标小区数据转发隧道标识用于切换期间接收转发数据。这两个值必须成对出现缺一个就意味着该承载只能转不能接或者只能接不能转。第 8 步源 eNB 收到 HANDOVER COMMAND从中解析出接纳成功的承载信息和目标侧转发地址到这一刻它才具备开始转发的条件。测试时经常看到源侧在收到 HANDOVER COMMAND 之前就开始往转发隧道发包这种提前转发在目标侧会因为隧道未建好而被丢弃表现为切换前的一段丢包。判断方法很简单把 HANDOVER COMMAND 的时间戳和转发隧道首包的时间戳一比前者必须早于后者反过来就是实现顺序错了。4.2 源侧收到 HANDOVER COMMAND 之后做哪几件事源侧的动作可以拆成四步顺序不能乱。第一步是停止在源小区空口上发送新的下行数据避免 UE 已经走了还在旧空口上灌包第二步是把自己缓冲区里的在途报文通过转发隧道送出去第三步是发 SN Status Transfer把 PDCP 的计数状态告诉目标侧第四步是在转发隧道上发出或转发 End Marker宣告转发结束。四步里任何一步顺序颠倒都会在切换点留下痕迹。缓冲区大小是个容易忽略的参数。缓冲区太小UE 一走在途报文直接丢缓冲区太大切换时延被拉长End Marker 迟迟发不出去目标侧等得久。现场调优一般会结合业务类型给一个折中值语音类偏小、数据类偏大具体数值各厂家不一样测试时不要在文档里写死记录实际配置值即可。真正需要验证的是“缓冲区里的包有没有全部转出去”这个可以用转发隧道上的包数减去源小区隧道在切换时刻之后的包数来估算。SN Status Transfer 这一步的坑在于它走的是控制面不经过用户面转发隧道所以只抓 S1-U 是看不到的。要在 S1-MME 上同时抓才能把 PDCP 状态同步和用户面转发对齐。文档里第 10、11 两步分别对应源 eNB 发和 MME 转中间隔着一个 MME时间差通常在几毫秒量级如果超过几十毫秒说明 MME 处理或者链路有问题会直接影响目标侧对重复包的判断。4.3 四个 TEID 的时序检查点把四个 TEID 的生效时刻做成一条时间线是这套测试里最值得固化下来的动作。切换前只有0x01001008上有下行流量RRC 重配之后0x0000115b上开始出现包同时0x01001008上的包逐渐减少源侧收到转发数据后0x01000a09上出现对应流量HANDOVER NOTIFY 之后0x01000a08接棒0x01000a09上的流量归零。任何一条不符合就是一处缺陷。用一段 Python 把导出的 CSV 按这四段时间切开比人工比对可靠。下面的脚本读的是上一节导出的gtp_s1u.csv按 TEID 归类并输出每个隧道的首末包时间与包数。import csv from collections import defaultdict # 四个 TEID 角色取自测试小结记录实际使用时替换为现场值 ROLE { 0x01001008: src_dl_normal, # 源小区正常下行隧道 0x0000115b: src_fwd, # 源侧转发隧道 0x01000a09: tgt_fwd, # 目标侧转发隧道 0x01000a08: tgt_dl_normal, # 目标小区正常下行隧道 } stat defaultdict(lambda: {cnt: 0, first: None, last: None}) with open(gtp_s1u.csv, newline, encodingutf-8) as f: for row in csv.DictReader(f): teid (row.get(gtp.teid) or ).lower() if not teid: continue key 0x%08x % int(teid, 16) # 统一成 8 位十六进制避免大小写与前导零问题 t float(row[frame.time_relative]) s stat[key] s[cnt] 1 if s[first] is None or t s[first]: s[first] t if s[last] is None or t s[last]: s[last] t for teid, s in sorted(stat.items(), keylambda kv: kv[1][first]): print(%s,%s,%d,%.3f,%.3f % ( teid, ROLE.get(teid, unknown), s[cnt], s[first], s[last]))脚本只做三件事把 TEID 归一化成 8 位小写十六进制避免0x1001008和0x01001008被当成两个隧道统计每个隧道的包数与首末时间按首包时间排序输出。逻辑很朴素但它把“四个隧道是否按预期顺序出现”这件事变成了可以直接看的一行行数据。ROLE字典里出现unknown就要警惕说明抓到了预期之外的隧道可能是其他业务的流量串进来也可能是承载映射错了。参数上唯一需要注意的是frame.time_relative是相对文件首包的时间不是绝对时间。多文件对比时必须先做时间基准对齐否则跨网元的先后关系全是错的。对齐方法在最后一章展开。5. 避坑与排查五类翻车现场的现象、成因与处置5.1 抓不到 End Marker业务却在切换点丢最后一个包现象S1-U 抓包里搜遍gtp.message 0xfe一个都没有但切换点的速率曲线确实有一个窄坑重传计数上涨。原因通常有两种一是抓包点不在 End Marker 经过的路径上间接转发时 End Marker 会在源与 SGW 之间、SGW 与目标之间各出现一次只在其中一段抓就会漏二是过滤条件写错用 TEID 去过滤而 End Marker 的 TEID 字段按规范填 0直接过滤不到。解决方式是先改用消息类型过滤确认两个方向、两段路径都覆盖再回去看 TEID。如果确实一个都没发就要查源侧和 SGW 的转发停止逻辑看是不是在 RRC 重配后就直接停了转发而没有走收尾流程。5.2 把 TEID 当成 IP 地址填进配置或脚本现象脚本里按0x01001008去找对应的网元结果匹配不上或者把四个十六进制值当成四个 IP画出来的拓扑完全对不上。原因是文档里这几个值写的是“地址”实际对应的是 GTP-U 头里的隧道端点标识不是 IP。解决方式是在任何分析脚本里都把 TEID 和 IP 分成两列处理四元组的形式是源 IP、目的 IP、TEID、方向缺一不可。这个坑我踩过一次当时用 TEID 去 grep 抓包文本把一串完全无关的十六进制也匹配进来了结论整整错了半天。5.3 HANDOVER REQUEST ACKNOWLEDGE 里承载不全源侧没检查现象多承载业务在切换后只有部分业务恢复其余业务在目标侧一直起不来。原因是目标侧接纳控制只接纳了部分 EPS 承载HANDOVER REQUEST ACKNOWLEDGE 里只带回了成功的那些源侧如果按“全部成功”去处理没被接纳的承载仍然往转发隧道上发目标侧没有对应隧道全丢。解决方式是在源侧解析 HANDOVER COMMAND 时逐承载比对对未接纳的承载停止转发并记录原因值测试用例里也要专门构造资源受限场景去覆盖这一条。文档里第 6 步“Admission Control”被单独列出来就是为了提醒这一步的结果会改变后续转发行为。5.4 拿 GTP-U 的 Sequence Number 去对 PDCP 的 SN现象测试报告里写“转发隧道序列号与状态转移消息不一致”研发一看就退回。原因是两层编号体系被混用了GTP-U 的 SN 是逐跳的、每隧道独立、16 位回绕PDCP 的 COUNT 是端到端的靠 SN Status Transfer 同步。解决方式是分析时明确标注每个 SN 属于哪一层GTP-U 的 SN 只用来看转发隧道内的连续性端到端的排序问题去看 PDCP 状态和空口侧的重传统计。这一条几乎是新人必踩写进测试规范能省不少来回。5.5 抓包点选错整份数据分析建立在残缺样本上现象导出的 CSV 里只有源小区正常隧道和目标小区正常隧道转发隧道一条都没有于是得出“本次切换没有发生数据转发”的结论。原因是本次走的是直接转发流量根本不经过 S1-U而抓包只布在 S1-U 上。解决方式是在测试执行前先确认转发模式从 HANDOVER REQUEST ACKNOWLEDGE 里的传输层地址判断再决定抓包点布在 S1-U、X2-U 还是源与目标之间的互联链路。多网元同时抓时统一用绝对时间或者做 NTP 对齐否则后面的时间窗比较没有意义。6. 用一份回放脚本验收转发四个 TEID 的时间窗对齐与判定阈值把前面几章的动作串起来验收一份切换抓包其实就三步对齐时间、切分窗口、套阈值。时间对齐这一步最容易被跳过也最容易让结论失真。多网元抓包时我用相对时间做一次线性校正以 HANDOVER REQUIRED 这个信令包为锚点把各文件的相对时间平移到同一基准再去做隧道窗口比较。锚点选它是因为它在源侧和 MME 侧都能抓到且时间戳精度足够。窗口切分沿用四个 TEID 的角色表。判定阈值我一般会设这么几条作为回归基线而不是硬标准具体项目按业务类型调整源侧转发隧道的首包必须晚于 HANDOVER COMMAND早于则判顺序错误目标侧转发隧道的末包必须早于 HANDOVER NOTIFY晚于则说明路径切换后仍有转发流量属于多转下行 End Marker 必须出现在目标侧转发隧道上且其后该隧道上不再有 G-PDU源小区正常隧道的末包与目标小区正常隧道的首包之间的间隔就是切换中断时长超过设定门限就报警。def check_windows(stat, sig, max_gap_ms100.0): stat: {teid_role: (cnt, first, last)}sig: 关键信令时间字典 errs [] src_fwd stat.get(src_fwd) tgt_fwd stat.get(tgt_fwd) src_dl stat.get(src_dl_normal) tgt_dl stat.get(tgt_dl_normal) # 1) 转发必须发生在 HANDOVER COMMAND 之后 if src_fwd and src_fwd[1] sig[ho_cmd]: errs.append(src_fwd starts before HANDOVER COMMAND) # 2) 转发必须在 HANDOVER NOTIFY 之前收尾 if tgt_fwd and tgt_fwd[2] sig[ho_notify]: errs.append(tgt_fwd still active after HANDOVER NOTIFY) # 3) 切换中断时长用两条正常隧道的间隙估算 if src_dl and tgt_dl: gap_ms (tgt_dl[1] - src_dl[2]) * 1000.0 if gap_ms max_gap_ms: errs.append(interrupt gap %.1f ms exceeds %.1f ms % (gap_ms, max_gap_ms)) return errs这段函数只做断言不做统计输入是上一节脚本产出的隧道窗口和人工填入的信令时间点。max_gap_ms是中断门限默认给 100 ms 是个宽松值语音场景通常要压到 50 ms 以内数据场景可以放到 200 ms 以上按业务定。返回的字符串列表为空才判通过非空就按提示回抓包定位。代码短但它把“有没有转发、转得对不对、断了多久”三件事固化成了可重复执行的判断比每次靠眼睛看曲线稳定。一个具体技巧把ROLE字典和这份断言函数放进同一个模块每份抓包只改输入路径和信令时间跑完直接出结论。我还会额外打印一条“未知隧道”清单凡是没在角色表里出现的 TEID 都列出来因为串扰流量往往就是从这里暴露的。从那以后我每次做切换验证都强制先跑一遍时间窗对齐再动手看图哪怕只有一份抓包也不跳过省下来的返工时间远比写脚本的时间多。希望帮到你。本文还有配套的精品资源点击获取