简介《S1 data forwarding测试小结》是一份面向移动通信核心网与无线侧测试人员、网优工程师及通信专业学习者的专题小结文档聚焦LTE切换过程中S1数据转发的测试方法与关键检查点。文档围绕数据流向、TEID与Sequence Number、切换信令流程展开重点梳理End Marker、源小区与目标小区转发地址变化、HANDOVER NOTIFY等观察点可帮助读者建立从测量报告、切换决策到数据转发与资源释放的完整链路认知并理解如何验证转发完整性与连续性。配套文件为1个docx压缩包约769KB体量轻便适合作为实验记录、测试对照或面试复习材料。目前已有305人学习内容虽精简但检查点明确便于在现网或实验室排障时快速定位用户面转发问题也可作为整理测试用例与信令分析笔记的参考。1. S1 数据转发为什么切换时最怕的不是断链而是“多出来的最后一包”做移动网络测试的人都有个共识切换成功率漂亮不代表用户没骂人。真正让人翻车的是切换完成后那几百毫秒里业务层悄悄丢了几包、乱了几包——统计报表上看不见用户却在视频卡顿里感受得到。S1 data forwarding 这套机制解决的就是这件事在 UE 从源小区挪到目标小区、空口链路重建的窗口期让还没送到的下行数据不丢。它的核心思路有点反直觉切换期间业务数据并不直接从源基站“飞”到目标基站而是先回吐给服务网关再由网关重新分发给目标侧。这里面 TEID 标记隧道端点、Sequence Number 维持包序、End Marker 划清“最后一包”的界限三者咬合起来才让“无损切换”从口号变成可验证的行为。搞懂这套转发路径和检查点才算是真正摸到了 S1 切换的底层。2. 三条数据路径切换前后流量到底从哪儿走2.1 切换前、切换中、切换后的下行路径差异要理解 S1 转发先把下行数据的走向钉死。切换前下行数据从服务网关SGW直接灌到源 eNB路径是SGW → Source eNB → UEGTP-U 隧道的对端就是源侧的数据传送地址。触发切换后目标侧完成接纳并回送确认源 eNB 开始把缓冲的和还在途中的包往前送但送的方向不是目标 eNB而是回到 SGW——这就是很多人第一次看抓包时觉得别扭的地方SGW → Source eNB → SGW → Target eNB一个包在网元之间绕了一圈。切换成功后路径收敛成SGW → Target eNB → UE源侧彻底退出用户面。为什么非要绕回 SGW因为 S1 接口的 GTP 隧道是 SGW 与 eNB 之间点对点建的源 eNB 和目服 eNB 之间没有直接的 S1 承载跨基站转发只能借助 SGW 这个“中转站”做一次隧道重封装。这属于典型的以控制面复杂度换用户面可靠性——多一跳转发换来的是路径切换过程中不丢包。2.2 数据回吐与重分发的时序约束这个“绕一圈”不是随便绕的时序上有硬约束。目标 eNB 在完成资源接纳后会把目标侧的数据传送隧道标识和转发隧道标识一并带给 MME再经 HANDOVER COMMAND 传到源 eNB。源 eNB 拿到这两组地址才知道该往哪儿发、发的是哪条流。常见的实现思路是源 eNB 在向 UE 下发 RRCConnectionReconfiguration 之前用户面还在用源小区的数据传送地址消息下发之后数据流量改由源小区的转发地址送出而目标侧接收端则使用目标小区的转发地址。等到目标 eNB 发 HANDOVER NOTIFY 通知 MME“UE 已成功接入”数据流量就切到目标小区的数据传送地址。三个地址、三个阶段、一次都不能错位。提示测试时如果只盯“切换成功”这一个事件很容易漏掉转发阶段的地址偷换。真正要核的是每个阶段实际承载数据的是哪一对地址。2.3 用地址三元组验证转发是否真的发生这段机制最适合用具体地址来固化理解。原文给的抓包检查点里出现了三组关键地址阶段承载数据地址含义切换前0x01001008源小区数据传送地址转发中0x0000115b源小区转发地址转发中0x01000a09目标小区转发地址切换后0x01000a08目标小区数据传送地址这套三元组的价值在于它把“数据到底有没有转发”从主观判断变成了可枚举的客观事实。抓包时只要确认转发阶段的包确实出现在0x0000115b → 0x01000a09这条隧道上就说明源侧在按规矩回吐如果这些包直接跳到了0x01000a08那要么转发被跳过要么抓包位置不对。3. End Marker 与 TEID转发收尾和隧道寻址的底层机制3.1 End Marker 为什么必须由 SGW 发起End Marker 是 GTP-U 里的一个特殊包本身不带业务载荷作用只有一个告诉对端“这是我发的最后一个数据包收到后就不用再转发业务了”。它的发起者是 SGW时机是在把下行切换到目标侧之前。之所以由 SGW 发而不是源 eNB 发原因在隧道语义SGW 是下行数据的源头只有它清楚自己这一侧还有没有在途包由它划句号最权威。源 eNB 收到 End Marker 后把它转发给目标 eNB源侧用户面的转发使命到此结束。这里有个容易忽略的细节End Marker 本身也是要转发的不能就地吞掉。因为目标侧需要借助这个标记确认“前序的转发数据流到此为止了”从而在包序上做一个干净的切分。少了这一包目标侧就无法判断后续从 SGW 直发的数据从哪一包开始算新流。3.2 TEID 与 Sequence Number 的分工很多排查卡壳是因为把 TEID 和 Sequence Number 混为一谈。TEID 是 GTP 隧道的端点标识用于区分不同的隧道和承载它决定“这个包属于哪条流、该往哪个端点送”Sequence Number 则是数据面的包序号用于保证包序和检测丢包、乱序。举个具体场景转发阶段同一个 UE 的下行数据可能同时存在于“源侧转发的隧道”和“目标侧新隧道”上如果只看五元组可能分不清但 TEID 能明确区分。反过来如果 Sequence Number 出现跳变或者回退那基本就是转发和直发两条流在衔接处出了问题。两者的关系可以这么理解TEID 管“路由到哪里”Sequence Number 管“顺序对不对”。3.3 从 HANDOVER REQUEST ACKNOWLEDGE 看参数是怎么传下来的目标 eNB 完成资源接纳后会给 MME 回 HANDOVER REQUEST ACKNOWLEDGE消息里带的是目标侧分配的 eNB UE S1AP ID以及接纳成功的 EPS 承载对应的目标侧数据传送地址——包括目标小区的数据隧道标识和目标小区的数据转发隧道标识。这些参数就是后续转发隧道的“坐标”。源 eNB 收到 HANDOVER COMMAND从中获知接纳成功的承载信息以及切换期间业务数据转发的目标侧地址。整条参数链是目标 eNB 分配 → MME 中转 → 源 eNB 使用。链路上任何一环参数被覆盖或丢失转发就会失联。测试时如果发现转发没发生先别怀疑转发功能本身回头核对这条参数链更高效。4. 从信令到转发一次完整切换的时序与检查点4.1 17 步信令流程拆解为四个阶段原流程可以拆成准备、执行、完成、释放四段。准备阶段从 UE 上报测量报告开始源 eNB 做切换判决后发 HANDOVER REQUIRED 给 MMEMME 向目标 eNB 发 HANDOVER REQUEST目标侧做接入控制和资源接纳成功后回 HANDOVER REQUEST ACKNOWLEDGE。执行阶段MME 发 HANDOVER COMMAND 给源 eNB源 eNB 下发 RRCConnectionReconfiguration 并携带移动性控制信息UE 与目标小区同步、完成随机接入回 RRCConnectionReconfiguration Complete。完成阶段目标 eNB 发 HANDOVER NOTIFY 通知 MME同时通过 eNB Status Transfer 与 MME Status Transfer 传递 PDCP 状态。释放阶段MME 触发 UE Context Release源 eNB 释放资源。4.2 抓包如何锁定 Data Forwarding 区间抓包定位的关键是找“转发开始”和“转发结束”两个锚点。开始锚点是源 eNB 下发 RRCConnectionReconfiguration 的那一刻——此前走源小区数据传送地址此后走转发地址。结束锚点是目标 eNB 发出 HANDOVER NOTIFY 的时刻——此后数据走目标小区数据传送地址。中间这段就是 Data Forwarding 区间期间应该能看到源侧转发地址到目标侧转发地址的 GTP-U 包以及那一枚 End Marker。如果区间内一个转发包都没有说明转发根本没触发如果有转发包但没有 End Marker说明收尾不完整目标侧可能残留旧流。4.3 用脚本核对 Sequence Number 连续性手工比对包序容易看花眼用一段脚本按 TEID 分组检查连续性更稳。下面这段逻辑演示如何从抓包导出的事件序列里找出不连续的区间# 输入按时间排序的 GTP-U 包记录每条含 teid、seq、src、dst packets load_gtpu_packets(pcap_path) # 按 TEID 分组不同隧道分别校验包序 groups {} for p in packets: groups.setdefault(p[teid], []).append(p) for teid, seq_list in groups.items(): expect seq_list[0][seq] for p in seq_list: # Sequence Number 应由 0 到 65535 循环递增 if p[seq] ! expect % 65536: print(fTEID{teid} 包序跳变: 期望 {expect % 65536}, 实际 {p[seq]}, f来自 {p[src]} - {p[dst]}) expect (expect 1) % 65536这段脚本做的判断很朴素同一条 TEID 上的 Sequence Number 必须连续。teid用于分组seq做 16 位循环比对输出里带上源和目的地址方便判断这个跳变发生在转发段还是直发段。常见误用是把不同 TEID 的包混在一起比对那样必然报错所以分组这一步不能省。4.4 End Marker 的边界判定与常见误判End Marker 的判定要注意两点一是它在 GTP-U 头里以特定标志位标识不是靠载荷内容判断二是判定要结合隧道方向SGW 发往源 eNB 的 End Marker 和源 eNB 转发给目标 eNB 的 End Marker 是两份不同的报文。常见误判是把转发段正常的数据包当成 End Marker或者漏掉源侧转发出去的那一份。稳妥的做法是在抓包里同时看消息类型和隧道端点两个条件都对上才认定。5. 避坑与排查S1 转发测试里的五类高频翻车5.1 转发包数为零但切换显示成功现象切换流程完整走完报表显示成功但转发阶段抓不到任何 GTP-U 包。原因多半是转发地址参数没传到源 eNB或者源侧根本没触发转发逻辑。解决先核对 HANDOVER REQUEST ACKNOWLEDGE 里的转发隧道标识是否有效再确认源 eNB 收到 HANDOVER COMMAND 后是否切换到了转发地址发送最后检查 UE 是否真的处在有下行数据在途的状态——空载切换本来就没有数据可转发。5.2 有转发包但目标侧收不到现象源侧转发地址上有包发出但目标侧转发地址上没有对应入包。原因通常是两侧隧道标识不匹配或者中间 SGW 未正确做隧道映射。解决把源侧转发地址和目标侧转发地址当作一对坐标去核对确认 GTP-U 报文的外层目的地址确实是目标侧转发地址再检查 SGW 侧的隧道映射配置。5.3 End Marker 缺失导致旧流不清现象切换后目标侧持续收到两条流的数据或者旧流数据在切换很久后才消失。原因是 SGW 未在切换下行前发送 End Marker或源 eNB 收到后未转发。解决在 SGW 到源 eNB 的方向找 End Marker再在源 eNB 到目标 eNB 的方向找转发的那一份两处缺一不可。5.4 Sequence Number 在衔接处跳变现象转发结束、直发开始的位置包序不连续业务侧出现短暂乱序。原因是转发流和直发流的包序上下文未衔接好PDCP 状态传递不完整。解决结合 eNB Status Transfer 和 MME Status Transfer 核对状态传递内容确认源侧最后一包与目标侧第一包的序号关系是否符合预期。5.5 误把直发数据算作转发数据现象抓包分析时以为转发正常实际上抓到的是切换完成后 SGW 直发的数据。原因是抓包点选错或者分析时没区分隧道端点。解决严格按阶段划分时间窗转发区间只认源小区转发地址到目标小区转发地址这一对切换后的数据走目标小区数据传送地址两者不能混算。6. 设计取舍为什么宁愿多绕一跳也不用基站间直连转发站在协议设计角度S1 转发选择“绕回 SGW”而不是让源、目标基站直接建隧道本质是在路径最优和状态可控之间做取舍。基站间直连看起来少一跳、时延更低但要求任意两个 eNB 之间都能建立临时隧道承载管理和资源释放的复杂度会指数上升而借助 SGW 中转隧道仍然是“eNB 与网关”这一固定关系转发只是换了端点地址控制面几乎不用改。这套设计把复杂度收敛到网关侧代价是多一跳转发延迟和网关侧的带宽压力。这也解释了为什么 End Marker 必须由 SGW 发起它是路径收敛的仲裁者只有源头节点有能力宣布“我的流结束了”。如果让源 eNB 发目标侧无法确认这是转发结束还是中间某段结束边界就模糊了。验证这套机制是否真正工作我不太信单一指标一般会做三件事一是按地址三元组核对阶段切换是否发生二是按 TEID 分组跑一遍包序连续性检查三是确认 End Marker 在 SGW→源、源→目标两段都出现过。三条都过才敢说这次转发是干净的。早年我吃过一次亏只看了切换成功率就判定通过结果用户侧反馈视频卡顿回头抓包才发现转发包数为零、切换成功是靠空口重建硬扛过去的。从那以后我每次做 S1 切换验证都会强制把转发地址三元组和包序连续性走一遍不再拿一个成功率数字当结论。这套检查点的思路希望帮到你。本文还有配套的精品资源点击获取