简介面向移动通信网络测试与优化人员的一份S1数据转发测试小结基于实际切换流程梳理了SGW、源/目标eNodeB之间的数据流向重点讲解TEID与Sequence Number的作用以及End Marker在用户面转发结束时的判定意义。文档以切换准备、执行、完成为主线逐一说明HANDOVER REQUEST ACKNOWLEDGE、HANDOVER COMMAND、RRCConnectionReconfiguration、HANDOVER NOTIFY等关键信令中的检查点并结合具体地址如0x01001008、0x0000115b、0x01000a09等演示如何核对数据流量转发的路径变化适合需要理解LTE切换数据面细节的测试工程师学习。资源为单份docx小结文件大小769KB内容精炼目前已有304人学习。阅读后可快速建立S1数据转发测试的检查清单掌握从测量报告到UE上下文释放全过程中的抓包验证思路与常见问题排查方向。1. S1 data forwarding测试一条容易被人忽略却决定切换体验的用例做LTE核心网测试的人对“S1 data forwarding”这个词应该都不陌生但也最容易对它掉以轻心。切换测试时大家盯得最多的是RRC重配置成功率、切换时延、掉线率数据转发这条反而经常被一笔带过。直到某一次外场测试发现切换后用户面数据丢包严重VoLTE通话断续最后查来查去根因落在转发路径没有真正打通才意识到S1 data forwarding才是切换体验的最后一道关卡。这篇小结面向的是核心网与无线侧测试工程师把一个看起来像“跑个流程、抓个包”的用例拆成可复现、可判读、可归档的测试方法覆盖从TNL隧道验证到用户面质量评估的完整链路。2. 先看数据包怎么走S1转发路径的底层逻辑2.1 转发决策是在“切换准备”阶段确定的不是执行阶段很多人以为S1 data forwarding是在eNodeB收到Handover Command后才开始的实际上转发隧道的决策发生在更早的Handover Preparation阶段。源侧eNodeB在发送Handover Required之前就已经根据测量报告和目标小区状态决定哪些E-RAB需要做数据转发并在Handover Required消息的E-RABs To Be Released List和E-RABs To Be Switched in DL Item里携带Data Forwarding IndicatorDFI。MME收到后结合SGW上下文判断是走Direct Data Forwarding还是Indirect Data Forwarding再通过Create Indirect Data Forwarding Tunnel Request等流程把转发隧道准备好。这个阶段最容易忽视的一点是转发决策和无线切出是两条并行线。无线侧信号再好如果核心网侧的转发隧道没建起来User Plane数据照样断流。测试时我会先把UE在某一个固定点打流设置A3事件触发切换在控制面消息里核对两个关键字段一个是Handover Required中的Data Forwarding Indicator是否存在且置位一个是Handover Command中是否携带了目标侧分配的下行转发TEID。这两个字段必须同时具备转发路径才算真正建立。2.2 抓包验证转发隧道四段过滤器与一条关键命令实际验证转发隧道时只盯着S1-U的GTP-U报文往往看不完整因为S1AP控制面和GTP-U用户面分别在SCTP 36412端口和UDP 2152端口上。我习惯的做法是同时抓两路包然后用以下四段Wireshark过滤表达式逐层锁定路径# 控制面只看S1AP承载上下文与切换相关消息 s1ap (s1ap.ProcedureCode 13 || s1ap.ProcedureCode 16) # 用户面只看经过特定eNodeB S1-U地址的GTP-U报文 gtp-u ip.src 192.168.10.21 gtp-u.messageType 0x01 # 进一步过滤按TEID字段精确匹配某一条E-RAB的转发流 gtp-u.teid 0x000012ab # 反向确认看转发面是否真的存在从核心网回注到目标侧的报文 gtp-u ip.addr 192.168.10.22 gtp-u.messageType 0x02第一段过滤用于确认切换类型和E-RAB列表第二段和第三段验证源侧是否真的把用户面数据封装为GTP-U隧道报文第四段对应G-PDU的Echo Response或数据包回注用来确认UDP Tunnel确实处于激活状态。参数说明ProcedureCode 13对应Handover Preparation16对应Handover Resource AllocationmessageType 0x01是Echo Request0x02是Echo Response实际数据转发时看到0x01和0x02不代表用户流量还要进一步用gtp-u.teid过滤确认。如果现场不方便开Wireshark图形界面可以用tcpdump在S1-U接口上做轻量抓包命令如下tcpdump -i eth1 -s 96 -nn host 192.168.10.21 and udp port 2152 -w /tmp/s1u_forwarding.pcap参数说明-s 96只抓每个报文前96字节GTP-U头加IP头加UDP头足够识别TEID与消息类型能显著降低高流量下的抓包丢包率-nn不做域名和端口解析保持原始地址-w直接落地为pcap文件避免终端打印损耗。注意抓包位置的时钟必须与核心网侧的抓包点同步否则后续对比转发时延会得出错误结论。2.3 三种转发场景判断表场景控制面特征用户面特征验证重点直接转发DirectHandover Command携带目标侧下行TEID无Indirect隧道建立流程源侧S1-U直接向目标侧S1-U发送GTP-U数据目标侧TEID是否与S1AP下发的TEID一致间接转发IndirectMME向SGW发起Create Indirect Data Forwarding Tunnel Request源侧S1-U发向SGWSGW再发向目标侧S1-U中间节点时延、GTP-U封装是否变化无线侧内部切换Intra-eNodeBS1AP不发生切换流程仅有RRC重配置S1-U上无转发流量X2口承担转发改用X2接口抓包验证三种场景的测试策略不一样。Direct场景要核对TEID对应关系Indirect场景要增加SGW侧抓包节点观察转发路径时延Intra-eNodeB场景则不能错误地在S1-U上寻找转发报文。这个表格我每次执行前都会打印一份贴在工位前避免抓包点选错方向。3. 用iperf3与tcpreplay搭一套转发质量测试床3.1 测试床需要的最小硬件拓扑S1 data forwarding测试不追求复杂组网但至少需要三台设备一台作为源侧eNodeB模拟器或真实基站一台作为目标侧eNodeB模拟器一台作为核心网仿真节点集成MME、SGW、PGW功能。外加两个打流客户端分别连接在S1-U的源侧和目标侧汇聚交换机上。测试床的最小要求是所有节点的时间同步误差小于50msS1-MME与S1-U接口独立镜像到抓包服务器。如果条件受限没有真实基站我一般用开源eNodeB模拟器或商用测试仪表的eNodeB模拟功能。这里有一个选型经验模拟器如果能自定义Handover Required里的DFI字段优先选择因为实际外场基站的DFI置位策略未必符合标准流程模拟器可以定向构造“置位”与“不置位”两个版本做对比测试。核心网侧不要用真实商用核心网设备直接连模拟器很多商用MME对模拟器下发的消息有健壮性校验容易把问题引向兼容性排查而不是数据转发验证。3.2 用iperf3建立UDP背景流量与丢包基线转发隧道建好之后第一步不是直接打满带宽而是先建立一条固定速率的UDP流做基线。iperf3是我用得最多的工具命令分成源侧与目标侧两步# 目标侧数据接收端监听5201端口并记录接收实时信息 iperf3 -s -i 1 -1 --json --logfile /tmp/iperf_server.json # 源侧数据发送端以10Mbps的UDP流发送180秒模拟VoLTE业务码率 iperf3 -c 192.168.20.10 -u -b 10M -t 180 -l 480 -i 1 --get-server-output参数说明-u表示UDP模式-b 10M是目标带宽-l 480是报文负载长度188字节的RTP负载加上IP/UDP头后通常接近240字节480字节可以模拟两倍于普通VoLTE报文的压力--get-server-output让客户端在结束时把服务端的统计信息一并输出省去再登录服务端收集日志。跑完之后把服务端JSON里的lost_percent字段记录下来作为转发丢包基线如果这个值超过0.01%先排查链路问题再进入切换流程测试。3.3 用tcpreplay回放真实业务报文验证“业务体验级”转发质量iperf3的UDP流能暴露丢包率但说明不了“用户真实感受”如何因为iperf3是纯构造流量报文特征过于均匀。真实业务报文有时间戳抖动、有大小交替、有TCP与UDP混合特征回放这些报文才能暴露调度器或转发队列的问题。tcpreplay是最直接的流量回放工具使用前先用tcpdump抓一段源侧eNodeB到核心网的S1-U用户面报文作为回放源# 用tcpreplay将抓取的真实业务报文循环回放到转发业务端口 tcpreplay --loop100 --pps2000 --mbps20 --duration120 \ --intf1eth1 --cachefile/tmp/s1u_cache /tmp/s1u_forwarding.pcap参数说明--pps2000控制每秒发包数--mbps20限制回放带宽两者同时设置时tcpreplay会以先达到的上限为准避免网卡突发占用带宽把转发性能问题误判为链路瓶颈--cachefile是先建立索引再回放避免重复解析pcap的时间开销。回放期间在目标侧用同一份pcap文件做对比重点看目标侧收到的报文序列与原始pcap的序列一致性。转发路径上出现乱序时回放法比iperf3更容易暴露问题因为真实业务报文带有时间戳和序号比对逻辑简单、容易定位。4. 把切换全流程跑一遍从Handover Required到E-RAB Release的转发验证4.1 三条消息串起转发路径S1切换中数据转发链路由三条关键消息串起来源侧eNodeB在Handover Required中声明需要转发的E-RABMME通过Handover Command把目标侧的“接收地址TEID”回传给源侧源侧随后开始发送GTP-U转发报文。完整验证不只盯第一条消息还要看后续的SN Status Transfer和E-RAB Release。SN Status Transfer的作用是把源侧的PDCP上行/下行序号同步给目标侧让目标侧在切换完成后能够用连续序号对转发报文重排序。这三条消息各有各的验证位置。Handover Required验证点在源侧S1-MME接口Handover Command验证点在MME与源侧之间的S1AP消息里注意此时目标侧的S1-MME接口也可能出现这条消息因为MME会把部分上下文信息转发给目标侧SN Status Transfer则只出现在MME与目标侧之间通过对比三条消息的出现顺序能反推转发的执行流程是否正确。4.2 步骤与预期七步验证法我在实际执行中把S1 data forwarding验证拆成七个明确的步骤每一步都有可通过抓包直接判定的预期结果适合让刚接触这个用例的测试人员直接照着做配置UE业务在源侧小区下建立一条UDP业务打流速率设为8Mbps持续运行不中断触发测量上报手动设置A3事件偏置与触发时延让源侧eNodeB在预定时间点收到测量报告抓取Handover Required确认E-RABs To Be Switched in DL Item中存在DFI字段且值为1抓取Handover Command查找目标侧分配的传输层地址与DL GTP TEID记录这两个值启动S1-U抓包同时在源侧与目标侧的S1-U接口上抓取GTP-U报文记录源侧发出第一个转发报文的时刻与目标侧收到第一个转发报文的时刻确认路径切换完成目标侧在Handover Complete之后收到来自核心网的直接数据后续收到转发隧道的尾部报文停止打流并统计比较源侧发出报文总数与目标侧完整接收的报文总数计算丢包率。每一步的通过标准很明确第3步的DFI必须存在第4步的TEID不能为0第5步的转发时延应在20ms以内同机房SGW场景或50ms以内跨地市SGW场景第6步两者之间不应出现超过5秒的断流窗口第7步的丢包率应小于0.1%。任何一个环节不满足都需要明确是无线切换的问题还是转发隧道的问题再进入对应方向的排查。4.3 关注SN Status Transfer乱序与重复报文的“后悔药”SN Status Transfer是S1转发验证中最容易被跳过的一环却是判断乱序能否恢复的关键。eNodeB在发送Handover Complete之后会立刻把PDCP上行下行序号状态通过SN Status Transfer发给MME再转给目标侧目标侧依据这个状态来重排转发隧道送来的报文。如果这个流程晚到或者携带的HFNHyper Frame Number与PDCP序号不连续即使GTP-U转发路径完全通畅业务也会因为乱序被PDCP层丢弃。测试时需要特别记录SN Status Transfer的到达时刻与GTP-U首个转发报文的到达时刻之差。这个差值在协议规范中没有明确规定但从业界实践来看SN Status Transfer必须在转发报文大量到达之前送达目标侧否则目标侧的PDCP重排序窗口会被打穿。我习惯把两者的时间差作为一个经验指标写进测试报告低于10ms代表时序合理10ms到50ms需要观察是否有丢包高于50ms则需要视为风险点要求核心网厂家解释消息调度延迟。5. 避坑清单S1 data forwarding测试最容易翻车的五个点5.1 现象转发时延翻倍但零丢包一切“看起来正常”有一类测试场景会把外部打流机同时接在多个接口上形成环路拓扑。此时从源侧S1-U发到目标侧的GTP-U报文可能绕经打流机的回环口再回到目标侧时延因此翻倍但抓包看丢包率是0报文完整。第一次遇到会误以为是正常路径直到对比时延才发现路径不对。解决方法是把核心里表信息列出来确认SGW到目标侧eNodeB的路由路径并在SGW的下行转发接口上做一次抓包确认没有重复路径。只要发现转发报文从SGW返回到源侧eNodeB再流向目标侧立刻检查路由配置删除回环路由重新建立隧道。5.2 现象抓包文件中出现大量TEID0的GTP-U报文GTP-U报文中TEID字段为全0表示隧道尚未建立通常出现在处理Echo Request或下行数据指示时。转发路径上如果看到大量TEID0的报文说明有节点在尝试发送数据但隧道上下文没有匹配到。排查思路是先确认Handover Command里下发的目标侧TEID是否被源侧正确写入GTP-U头再去SGW侧看隧道上下文表确认Indirect转发隧道是否真的创建成功。多数情况是MME在Create Indirect Data Forwarding Tunnel流程中响应了成功但SGW没有为该TEID分配实际的UDP端口导致数据无法完成封装。5.3 现象Handover Command里找不到Data Forwarding Indicator这个现象在模拟器测试中相对少见但真实基站与多厂家核心网对接时很容易出现。一种原因是厂家实现差异——源侧eNodeB虽然在Handover Required里带了DFI但MME在生成Handover Command时丢弃了该字段只传了需切换的E-RAB列表另一种原因是源侧eNodeB的策略配置某些厂家的基站在同频切换配置中默认不做数据转发只对异频切换或跨站切换开启转发。解决方法是先在源侧eNodeB的切换策略配置中检查数据转发开关确认开启后再让核心网侧抓包对比Handover Required与Handover Command的消息内容。如果两边都开了但字段依然缺失就要怀疑MME在S1AP消息编解码时漏掉了该IE需要核心网厂家打补丁。5.4 现象打流结束后看到大量乱序但无线侧指标全部正常乱序问题的迷惑性在于无线侧指标可能全部正常RRC重建成功率高、切换时延标准但TCP业务吞吐率上不去。实际原因是转发隧道建立得太晚源侧缓存的转发报文在隧道建立后一股脑涌向目标侧与目标侧直接收到的核心网下行业务报文在PDCP重排序窗口内产生竞争。处理方法是增大目标侧PDCP重排序定时器或调整缓存容量但最根本的解决办法是让源侧的转发报文提前发送不能等到无线切出完成再开始转发。这个经验说明抓包看“乱序”并不总是链路问题也有可能是时序配合有问题。5.5 现象转发隧道已建立但目标侧始终收不到GTP-U报文偶发场景原因是目标侧eNodeB防火墙策略阻止了来自核心网网段的UDP 2152端口报文。这个坑在物理环境或运营商内网测试时尤为常见因为网络安全策略会默认阻断非白名单地址的高位端口通信。解决方法是直接检查目标侧设备是否有相关安全策略临时放通核心网网段的UDP 2152端口后再确认GTP-U报文是否能够到达。如果放通后报文到达说明检测到的丢包不是转发隧道本身的问题而是运维策略的配置这类环境问题需要在测试前就纳入准备清单与核心网厂家、IT运维确认防火墙策略。6. 把验证过程固化成脚本一份批处理与两个检查点每次手动做S1 data forwarding测试都是重复劳动启动打流、触发切换、抓包、收包、统计。做多了之后我把整套验证逻辑固化成一份批处理脚本写在服务器上直接调用既减少误操作又能留下可复查的日志。#!/bin/bash # S1 Data Forwarding 批处理验证脚本 # 用法: ./s1_df_test.sh 源侧IP 目标侧IP SGSN侧S1-U IP 输出目录 SRC_IP$1 DST_IP$2 SGW_IP$3 OUT_DIR$4 TS$(date %Y%m%d_%H%M%S) LOG_FILE$OUT_DIR/df_test_$TS.log mkdir -p $OUT_DIR/pcap $OUT_DIR/json # 1. 源侧启动iperf3 UDP打流后台运行 iperf3 -c $DST_IP -u -b 10M -t 60 -l 480 --get-server-output \ --logfile $OUT_DIR/json/bg_flow_$TS.json # 2. 分别在源侧S1-U和核心网侧S1-U抓包 tcpdump -i eth1 -s 96 -nn host $SRC_IP and udp port 2152 \ -w $OUT_DIR/pcap/s1u_src_$TS.pcap TCPDUMP_PID$! # 3. 触发切换调用测试仪表API示例为占位命令 # /usr/local/bin/trigger_handover --target $DST_IP # 4. etc. 抓包文件按时间戳命名便于回溯 sleep 70 kill $TCPDUMP_PID echo test completed at $TS, pcap saved to $OUT_DIR/pcap/ $LOG_FILE脚本的参数说明输入参数从左到右分别是源侧、目标侧、核心网侧S1-U接口地址与输出目录--get-server-output保证打流数据在客户端退出后也能拿到服务端的丢包统计抓包进程用$!捕获PID并在打流结束后手动kill避免脚本挂死时tcpdump继续写盘。核心是把每一个步骤的控制权分开打流、抓包、触发切换互不依赖任何一步失败都不会污染前面已经收集的数据。使用这份脚本时我会额外坚持两个检查点第一个是打流开始前必须先验证基准路径即在没有切换的情况下让iperf3跑30秒确认源侧到核心网的S1-U路径本身没有隐性丢包第二个是脚本生成的pcap文件必须立即记录SHA256与其他测试记录一起归档后续复盘时确认文件没被篡改或未完整捕获。这两个检查点听起来基础但在我过去的工作中至少三次避免了“拿一份不完整抓包去反推转发丢包”的错误也在复盘时节省了几小时重新抓包的时间。测试完成后我会强制自己保留一份按时间戳命名的输出目录内部包含pcap文件、iperf3的JSON日志、以及手写的测试结论。S1 data forwarding这种用例只要路径正确、参数对得上、抓包、打流、批处理脚本能够沉淀下来后续再遇到切换丢包问题都能在十分钟内定位到转发面还是无线面。这也是我多年来养成的习惯用例可以简单验证过程必须完整、可重复、可回溯。希望这套思路能给正在做数据转发测试的你一些参考让S1 data forwarding这条用例不再只是测试报告里一个打勾的符号。本文还有配套的精品资源点击获取