S1切换数据转发验证：用TEID与End Marker检查点定位业务中断

简介：围绕S1数据转发测试的docx小结，面向移动通信核心网、无线侧测试工程师及LTE切换学习者，聚焦切换过程中用户面数据连续性验证这一关键问题。内容从数据流向入手，梳理切换前SGW经源eNodeB至终端、切换中经SGW回传再转目标eNodeB、切换后直连目标eNodeB的路径变化，并解释End Marker用于通知源侧结束转发、TEID标识GTP隧道端点、Sequence Number保障数据包顺序与重组。文中还给出Data Forwarding检查点，结合源小区数据传送地址、源与目标转发地址及HANDOVER NOTIFY后的地址变化，串联测量报告、切换决策、接纳控制、HANDOVER COMMAND、RRC重配置、数据转发、UE同步与资源释放等流程，便于建立端到端排查思路。包内为1个docx文档，约769KB，适合作为切换测试要点速查与复盘笔记。已有305人学习，适合希望把切换信令、数据转发路径与地址检查点对应起来，并据此分析丢包、转发中断等异常的中级读者。

1. 一次切换后下行断流三秒：S1 data forwarding 测试到底在验什么

见过不止一次这样的情况：信令面上 HANDOVER NOTIFY 已经上报，UE 侧也显示已接入新小区，业务面上却出现一段接近三秒的下行空洞，TCP 重传几轮之后才慢慢恢复。翻抓包才发现问题根本不在信令，而在用户面——End Marker 没在该出现的地方出现，或者转发隧道和目标隧道被当成了一条。S1 data forwarding 测试要解决的就是这类「信令成功、业务不连续」的问题：把一次切换拆成几个可观测的检查点，让「数据有没有断、断在哪一段、断了多久」变成能逐条判定的结论，而不是靠盯着 UE 屏幕看有没有卡。

这份小结适合两类人：正在做核心网与无线侧联调、要出一份切换验证结论的人；以及要做相关课题、需要一套完整测试方法与判据的学生。它不追求把 3GPP 流程从头讲一遍，而是把切换期间数据到底走哪条隧道、每个地址代表什么、哪个时刻该出现哪个包，钉成一张能对着抓包逐条打勾的表。

2. 转发链路的数据流向：四个阶段与四个隧道标识的对应关系

2.1 切换前、切换中、切换后：一条下行数据的三段旅程

把一次 S1 切换的下行路径摊开看，实际上只有三个稳定状态，中间夹着一段很短的过渡。切换前是稳态，下行数据从服务网关顺着 S1-U 隧道直接送到源 eNB，再经空口发给 UE，这条隧道用源 eNB 分配的下行 TEID 标识，在这份小结里记作 0x01001008；反向的上行数据用服务网关分配的另一套 TEID，方向不同、标识也不同，这一点后面还会再强调。

切换判决做出、源 eNB 发出 HANDOVER REQUIRED 之后，进入过渡态。此时空口还没断，但源 eNB 已经知道这个 UE 要走了，新到的下行包不再往空口送，而是先缓存起来。等到源 eNB 收到 HANDOVER COMMAND、给 UE 下发 RRCConnectionReconfiguration，空口连接开始迁移，缓存的数据就要找地方送。这里的分叉点是转发方式：直接转发时源 eNB 把数据直接怼到目标 eNB 的转发隧道；间接转发时数据要先回到服务网关，再由网关送到目标 eNB。这份小结覆盖的是后者，也就是数据走向呈「网关→源 eNB→网关→目标 eNB」这种折返形态的那一种，源侧用 0x0000115b 这条转发隧道把数据吐回网关，网关再用目标侧的转发隧道 0x01000a09 送给目标 eNB。

提示：直接转发和间接转发在抓包点位、TEID 使用、End Marker 路径上完全不同，混着看会让整张检查点表失效。开工之前先确认这次切换走的是哪一种，写在测试记录的第一行。

切换成功后回到稳态，网关把下行路径整体切到目标 eNB，用的是目标 eNB 新分配的下行 TEID，记作 0x01000a08。注意 0x01000a09 和 0x01000a08 只差最后一位，一个是转发用的、一个是正常业务用的，肉眼极易看错，这也是后面排查章节要单独拎出来讲的一个坑。转发隧道是临时通道，UE Context Release 之后就该消失；业务隧道是长期通道，会一直用到下一次切换或者去附着。判断切换是不是真的完成，看的是业务隧道上有没有持续的数据，而不是转发隧道上有没有包。

2.2 四个地址各自代表什么，怎么和信令对上

这四个值不是凭空来的，每一个都能在信令消息里找到出处。源侧的 0x01001008 来自最初建立承载时服务网关下发的 Create Session Response 或者 Modify Bearer Request 中的 S1-U 下行 F-TEID；源侧的转发地址 0x0000115b 和目标侧的转发地址 0x01000a09，来自目标 eNB 在 HANDOVER REQUEST ACKNOWLEDGE 里带回来的透明容器——目标 eNB 完成承载接纳后，会把目标侧分配的 eNB UE S1AP ID、接纳成功的 EPS 承载对应的目标小区数据传送地址和目标小区数据转发地址一并塞进这条消息，经过 MME 转成 HANDOVER COMMAND 交给源 eNB。源 eNB 拿到之后才知道「我该往哪送」。

目标侧的业务地址 0x01000a08 则要等到 HANDOVER NOTIFY 之后才真正生效：目标 eNB 通知 MME 目标侧 UE 已经成功接入，MME 再让服务网关把下行路径改到这条隧道上。所以在时间轴上，这四个值的「可观测区间」是错开的，把它们画在同一条时间线上，就能一眼看出某个时刻的包该带哪个 TEID。

这张表是整个测试的锚点。我一般会把它打印出来放在手边，抓包的时候对着看，比在几十条信令里翻字段快得多。需要提醒的是，表里只列了下行侧的 TEID，上行方向用的是服务网关分配的另一套值，不要拿这四个去匹配上行包，否则会得出「上行全丢」的错误结论。

2.3 TEID 管隧道、Sequence Number 管顺序，别混为一谈

刚接触 GTP-U 的人容易把这两个字段当成一回事，其实职责完全不同。TEID 是隧道端点标识，32 位，由接收端分配、发给发送端使用，它回答的是「这个包属于哪条隧道」；Sequence Number 是 GTP-U 头里的 16 位序号，回答的是「这个包在同一条隧道里排第几」。前者错了，包会送到错误的承载上，表现为业务串号或者直接丢弃；后者错了，包会乱序到达，表现为重组失败、时延抖动，但连接不一定断。

排查的时候两者的表现也完全不同。TEID 用错，通常是一整段隧道上的包全部异常，特征非常干净；Sequence Number 出问题，往往是零星跳号，中间夹着几个正常包，需要逐个比对。抓包工具默认不会把 GTP-U 的序号展开成列，得手动加字段，这也是为什么很多人第一次做这类测试时会漏掉乱序问题。

顺带说一句状态转移。eNB Status Transfer 和 MME Status Transfer 这两条消息传递的是 PDCP 的序列号状态和超帧号，作用是让目标 eNB 接着源 eNB 的序号继续收发，加解密和排序都不会断。它和 GTP-U 的 Sequence Number 是两层不同的东西：前者管空口 PDCP 层，后者管 S1-U 承载层。做检查点的时候要分层看，别把两层序号混在一起算。

下面的脚本把四个隧道标识映射成阶段名，然后按包统计每个隧道的出现次数和首末时间，用来快速判断「某条隧道根本没出现」这种硬故障：

# 按 TEID 统计各阶段隧道上的 G-PDU 数量与首末时间 from collections import Counter from scapy.all import rdpcap from scapy.contrib.gtp import GTP_U_Header # 四个值要与信令里下发/回报的值一一对上，改成自己这次的实测值 TUNNEL = { 0x01001008: "切换前 源小区数据传送", 0x0000115B: "切换中 源小区转发", 0x01000A09: "切换中 目标小区转发", 0x01000A08: "切换后 目标小区数据传送", } def summarize(path): count, first, last = Counter(), {}, {} for pkt in rdpcap(path): if GTP_U_Header not in pkt: continue g = pkt[GTP_U_Header] if g.gtp_type != 0xFF: # 0xFF 才是 G-PDU，跳过 Echo 等控制消息 continue if g.teid not in TUNNEL: # 上行隧道用网关分配的 TEID，不在本表内 continue count[g.teid] += 1 first.setdefault(g.teid, pkt.time) last[g.teid] = pkt.time for teid, desc in TUNNEL.items(): if count[teid] == 0: print(f"{teid:#010x} {desc:<22} 0 包 <-- 该项为 0，重点查") continue span = float(last[teid] - first[teid]) print(f"{teid:#010x} {desc:<22} {count[teid]:>6} 包 " f"首包 {float(first[teid]):.3f}s 持续 {span:.3f}s") if __name__ == "__main__": summarize("ho_s1.pcapng")

脚本里gtp_type != 0xFF这个过滤条件是关键，GTP-U 隧道上除了业务包还会有 Echo Request/Response、Error Indication，这些包也带 TEID，不过滤掉会把统计数字撑大。teid是 scapy 解析出的 32 位整数字段，直接和字面量比对即可。打印结果里，如果某条转发隧道是 0 包，先别急着怀疑转发没生效，去确认这次切换是不是走了直接转发——直接转发下 0x0000115b 本来就不会有包。如果业务隧道首包时间点明显晚于 HANDOVER NOTIFY，那就是路径切换慢了，属于要往下追的异常。

3. 信令流程与检查点：从 Measurement Report 到 UE Context Release 的 17 步怎么拆

3.1 准备、执行、完成三段：17 步流程的分段读法

完整流程从空口测量开始，到源侧资源释放结束，中间要经过 MME、源 eNB、目标 eNB 和服务网关四个角色的来回交互。把它一口气顺下来很容易记乱，按三段切分就清楚了。准备段做的是「协商」：UE 上报 Measurement Reports，源 eNB 做 HO decision，向 MME 发 HANDOVER REQUIRED；MME 找到目标侧，发 HANDOVER REQUEST；目标 eNB 做 Admission Control，资源够了就回 HANDOVER REQUEST ACKNOWLEDGE，把目标侧的 S1AP ID、数据传送地址、数据转发地址一并带回来；MME 转成 HANDOVER COMMAND 给源 eNB。这一段的产物，就是源 eNB 手上那三个「该往哪送」的地址。

执行段做的是「搬迁」：源 eNB 给 UE 下发 RRCConnectionReconfiguration，里面带 mobilityControlInfo；UE 收到后断开旧小区、向目标小区同步，完成随机接入拿到上行授权和定时提前量，再回 RRCConnectionReconfigurationComplete。同一段时间里，源 eNB 通过 eNB Status Transfer 经 MME 转给目标 eNB 一条 MME Status Transfer，把 PDCP 状态交过去；同时缓存的数据开始沿转发路径往目标侧走。这一段是整条流程里唯一会同时存在三条数据路径的时刻，也是最容易出问题的地方。

完成段做的是「收尾」：目标 eNB 发 HANDOVER NOTIFY 告诉 MME 目标侧 UE 已经成功接入；MME 让服务网关把下行路径从源侧切到目标侧，网关随即在旧路径上补一个 End Marker；MME 下发 UE Context Release Command，源 eNB 释放资源。三段各自的判据不一样：准备段看信令参数对不对，执行段看数据有没有连续，完成段看旧路径有没有干净退出。

3.2 End Marker 的三次转发与它在抓包里的样子

End Marker 的作用非常朴素：告诉对端「这是我这条旧隧道上发的最后一个业务包，你收完就可以歇了」。服务网关在把下行路径切到目标 eNB 之前，先在旧路径上发一个 End Marker 给源 eNB；源 eNB 收到之后，知道自己的用户面转发任务到此为止，把这个包送出去，然后停手。如果走的是间接转发，源 eNB 把它交给网关，网关再送到目标 eNB；如果走的是直接转发，源 eNB 直接塞进目标侧的转发隧道。

在抓包里它长什么样？GTP-U 的消息类型仍然是 0xFF（G-PDU），但负载为空，长度字段为 0。就因为「长度为 0」这一点，很多统计脚本会把它当成异常包丢掉，或者当成畸形包过滤掉，结果就是怎么算都对不上。判断一个包是不是 End Marker，看的是 GTP-U 头之后还有没有内容，而不是看它有没有进业务统计。

它的三个检查点是递进的。第一，服务网关到源 eNB 的旧下行隧道（0x01001008）上必须出现 End Marker，且它之后这条隧道上不应再有业务包；如果 End Marker 之后还有数据，说明网关侧的路径切换和停止发送没对齐，UE 侧会收到重复包。第二，源侧的转发隧道（0x0000115b）上应该能看到 End Marker 被送出来，这是源 eNB「已经完成转发使命」的直接证据。第三，目标侧转发隧道（0x01000a09）上要能收到这个 End Marker，目标 eNB 收到它之后才会认为转发数据到此结束，可以放心只用新路径的数据。

注意：End Marker 丢失不一定导致切换失败，但会导致目标侧一直「等」下去，表现为转发隧道上始终有零星的重传包，或者切换完成后短时间内出现重复的下行包。这种问题在只看信令的验收里完全查不出来，必须看用户面。

还有一点容易忽略：End Marker 是有方向性的。上面说的是下行。上行方向在同一次切换里也有对应的结束标记，但它走的是另一条隧道、另一个方向，不能拿同一套 TEID 去套。做检查点表时把上下行分开列，能省掉大量反复。

3.3 把检查点写成过滤器：两条命令覆盖 80% 的排查

人工在几千个包里翻 End Marker 效率极低，用 tshark 的显示过滤直接筛出来最快。下面两条命令，一条看目标转发隧道上的数据流，一条看旧下行隧道上的收尾情况：

# 命令一：目标转发隧道上的 G-PDU，看转发数据是否存在、End Marker 落在第几包 tshark -r ho_s1.pcapng -n \ -Y "gtp.teid == 0x01000a09 && gtp.message == 255" \ -T fields -e frame.number -e frame.time_relative \ -e ip.src -e ip.dst -e gtp.seq -e gtp.length # 命令二：旧下行隧道，确认 End Marker 之后不再有业务包 tshark -r ho_s1.pcapng -n \ -Y "gtp.teid == 0x01001008 && gtp.message == 255" \ -T fields -e frame.number -e frame.time_relative -e gtp.length -e gtp.seq

参数逐个说清：-r指定离线抓包文件，-n关掉名字解析省时间，-Y是显示过滤器，-T fields让输出变成制表符分隔的列，方便直接粘进表格软件。gtp.message == 255等价于只要 G-PDU，把 Echo 之类挡在外面。gtp.length那一列为 0 的行就是 End Marker，gtp.seq用来判断这条隧道上序号是否连续。

字段名在不同版本的 Wireshark 里偶有出入，比如序号字段有的版本叫gtp.seq、有的叫gtp.seqno。取不到值的时候先跑一次tshark -G fields | grep -i "gtp\."核对真实字段名，比反复改命令快。另外gtp.length在某些实现里填的是 GTP 头长度而非负载长度，这种情况下改用gtp.payload是否存在来判断更稳妥——有内容就是业务包，没有就是 End Marker。

如果这两条命令的输出能对上三件事——目标转发隧道上有数据、旧下行隧道上 End Marker 之后干净、两条隧道上的序号都连续——那这次切换的用户面基本可以判为通过。剩下要做的就是把这个判据固化成脚本，别每次都靠人眼扫。

4. 测试环境与用例设计：让每一次切换都能复现

4.1 组网与打点位置：抓包点选错，后面全白做

这类测试最怕「测出来了但复现不了」。复现的前提是抓包点位固定、时间基准统一。通常的做法是在 S1 接口上做镜像，源 eNB 与 MME/SGW 之间、目标 eNB 与 MME/SGW 之间各取一个点，两个点最好接在同一台采集设备上，避免因为设备时钟不同步导致时序判断反向。如果条件有限只能取一个点，就取服务网关侧那个，因为四条下行隧道里有三条会经过它——代价是看不到源 eNB 内部的缓冲行为。

空口侧要不要抓？如果测试目标只是验证 S1 转发是否生效，空口日志不是必须的，但 UE 侧的 RRC 消息时间戳能帮你判断「切换中断了多久」，这个数字是验收报告里最直观的一项。我一般会让 UE 侧也单独存一份日志，事后和核心网抓包按绝对时间对齐。

时间同步这件事值得单开一段说。多设备抓包如果没有统一时钟，几台设备的帧时间戳可能差几百毫秒，而你关心的转发窗口本身也就几百毫秒到一两秒，误差和信号一个量级，时序结论会直接反掉。开测前把所有采集设备对一次时间源，记录下对时结果，这一步花不了多少时间，但能省掉后面几小时的扯皮。

4.2 用例矩阵：正常、边界、异常三类怎么排

只测一次顺利切换就下结论，是这类验证里最常见的问题。一次成功只证明「这条路在理想条件下能走通」，证明不了系统在拥塞、弱覆盖、大包、连续切换下的表现。用例要按三类来排：正常场景建立基线，边界场景压系统极限，异常场景验证容错。

表里的判据只是示例，实际阈值要按项目要求定，别照搬。要强调的是 HO_03：连续切换最容易暴露「上一次的转发隧道没清干净」的问题，表现为第二次切换时目标侧收到来源不明的包。这种问题单次切换永远测不出来，但在真实网络里并不罕见。

用例数量不在多，在于每条都能独立复现。每跑一条，记录四个隧道是否按预期出现、End Marker 位置、切换中断时长、以及是否有重传包，四组数据齐了，这条用例才算跑完。

4.3 日志与归档：让三个月后的你还能看懂

归档规范听着琐碎，但真出事的时候它就是救命的那根绳子。文件命名至少带上用例号、执行时间、抓包点位三样信息，比如HO_03_20250311_1420_sgw.pcapng；每个用例配一个同名的 check 文本，把脚本跑出来的检查结论直接落盘；失败用例单独记一个 fail.log，写明失败在哪个检查点、当时的现象是什么。

下面是一个批量跑用例的框架，把触发、等待、抓包、检查串起来：

#!/bin/bash # 一轮回归：逐条跑切换用例，抓包与检查结果按用例号落盘 set -u RUN_ID=$(date +%Y%m%d_%H%M%S) OUT="./result/$RUN_ID" mkdir -p "$OUT" for CASE in HO_01 HO_02 HO_03 HO_04 HO_05; do echo "[$(date +%H:%M:%S)] start $CASE" # 触发动作按实际手段替换：拨测脚本、程控衰减器、或人工走到指定点位 ./trigger_handover.sh "$CASE" || { echo "$CASE 触发失败" >> "$OUT/fail.log"; continue; } sleep 8 # 留足 UE Context Release 走完的时间，避免提前停抓包 python3 check_points.py "$OUT/$CASE.pcapng" > "$OUT/$CASE.check.txt" 2>&1 done echo "结果目录：$OUT"

sleep 8这个等待时间不是拍脑袋定的，它要覆盖从触发到 UE Context Release 完成的全过程，短了会把释放阶段的包截掉，长了只是浪费时间。判断依据是基线用例 HO_01 的实测总时长再留一点余量。check_points.py就是前面那个统计脚本加上判据断言，两部分拼在一起用。set -u是为了在变量拼错名时直接报错而不是静默跑完，这种小细节在批量脚本里能省掉很多「跑完了但结果是空的」的困惑。

5. 避坑与常见问题：五类最容易翻车的现象排查

5.1 信令全对但业务断了：只验信令不验用户面

现象：切换流程走完，HANDOVER NOTIFY、UE Context Release 一条不落，验收看着没问题，但 UE 侧业务出现明显卡顿，长连接甚至断开。

原因：信令面和用户面是两套独立的验证对象。信令只证明「控制面协商成功」，不证明「数据真的从新路径走了」。转发隧道没生效、路径切换延迟、End Marker 丢失，这些问题都不会让信令失败。

解决：把用户面检查点做成验收的必选项，四个隧道逐个确认出现时机与包数，任何一项为 0 都要单独说明原因。验收表里信令一列和用户面一列必须同时打勾，只有信令打勾的一律记为「待确认」，不能记通过。

5.2 End Marker 被当成丢包：长度为 0 的包被脚本过滤

现象：统计脚本算出来转发隧道的包数比预期少，或者日志里报告「检测到 0 字节异常包若干」，但人工翻抓包能看到那个包。

原因：End Marker 的负载为空，长度字段为 0。很多统计脚本用「负载长度大于 0」作为有效业务包的条件，正好把它排除了；一些解析库遇到空负载也可能直接判为畸形。

解决：把 End Marker 当成一类独立事件来识别，判断依据是「G-PDU 且无负载」，而不是长度阈值。统计时单列一行，不要混进业务包计数里。用了第三方解析库的，先在已知含 End Marker 的样本上跑一遍，确认它没被丢掉再上生产。

5.3 转发隧道和目标隧道记混：只差最后一位的两个值

现象：抓包里明明有包，但时序对不上，或者切换完成后仍然有数据走转发隧道，看起来像「没切过去」。

原因：0x01000a09 和 0x01000a08 只差最后一位，肉眼扫过去几乎一样。手抄到脚本里抄错一个字符，整张表就全错了，而且错得很隐蔽——包数不为零，脚本不会报警。

解决：所有 TEID 值从抓包文件里直接复制，不要手敲；脚本里用十六进制字面量加注释，注释写清归属和用途；跑完之后做一次反向校验，用「切换前必须命中 A、切换后必须命中 B」这种互斥条件卡一遍，能挡住绝大多数抄错。

5.4 时序全反：多设备抓包没对时

现象：源侧抓包显示数据早就停了，目标侧抓包显示数据还在来，两边对不上，怎么分析都自相矛盾。

原因：多台采集设备各自用自己的本地时钟，没做统一对时。切换窗口本身只有几百毫秒到一两秒，设备之间差几百毫秒，先后关系就会完全颠倒。

解决：开测前统一对时并记录对时结果，抓包文件头里的时间戳精度也确认一遍。条件允许的话，把多个点位汇到同一台采集设备上，从根上消除跨设备时差。已经抓完的包如果发现没对时，就别在时序上下结论，只做单设备内的因果分析。

5.5 只测一次就下结论：连续切换和边界场景缺失

现象：单次切换跑了十遍都通过，上了真实移动场景就出问题，尤其是快速穿过多个小区的时候。

原因：单次切换测不到状态残留。转发隧道有没有按时释放、End Marker 有没有漏、上一次的缓存有没有清干净，这些只有在连续切换里才会暴露。同样，弱覆盖边界触发、满负荷大包这些场景，单次顺利切换也覆盖不到。

解决：用例矩阵里强制保留至少一条连续切换和一条边界触发，作为回归必跑项。连续切换的判据要加一条「上一次的转发隧道在本次切换开始前已经没有任何包」，这条能卡住大部分状态残留问题。

6. 验收与答辩：用一张检查点表把结论钉死

验收这件事，最怕的是讲了一大段流程，评委或者甲方问一句「所以到底过没过」，答不上来。有效的做法是把所有检查点收成一张表，每行一个判据，每列一个证据来源，过与不过一目了然。表不用长，十来行足够，但每一行都要能从抓包里找到对应的包或者从日志里找到对应的时间戳。

答辩的时候，顺序比内容更重要。不要从协议栈讲起，直接放 C8 那个数字——「这次切换的中断时长是 180 毫秒」——先给结论，再解释这个数字是怎么算出来的，最后才展开流程。评委的注意力就那么几分钟，先让他看到你有一个可量化的结论，后面的流程讲解他才愿意听。遇到被问到没测过的场景，老实说「这条用例没覆盖，是我这轮的缺口」，比硬编一个说法强得多，被追问两句就露馅了，反而扣分。

还有个小技巧：把失败用例也放进答辩材料里，一条就够。挑一条能清楚说明「现象—定位—根因—修复后复测通过」的，比如连续切换时旧转发隧道没清干净那种。全绿的报告看着漂亮但不可信，一条讲得透的失败案例，反而能证明这套检查点是真的能抓到问题，而不是走过场。

从那以后我每次做切换验证，都强制先走一遍「地址映射表先画、抓包点位先对表、时间源先统一」这三步，哪怕时间再紧也不跳。跳过这三步省下的半小时，后面通常要用半天去补。希望帮到你。

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