企业官网建设流程全解析

简介：针对S1数据转发测试的中文技术小结，面向移动通信网络优化、LTE切换测试及GTP协议排查人员。内容以切换场景下用户面转发为主线，先归纳数据流在SGW、源eNB、目标eNB之间的走向，再解释TEID与Sequence Number如何标识及排序数据包，随后按切换准备、执行、完成三个阶段梳理HANDOVER REQUEST ACK、HANDOVER COMMAND、RRC重配置、HANDOVER NOTIFY等信令衔接。文中列出Data Forwarding关键检查点，如End Marker发送时机、数据流经源小区传送地址0x01001008、转发地址0x0000115b与目标小区地址等细节，可直接对照现场日志验证。资源共1个docx文档，约769KB，适合在测试复盘、故障定位或专题培训时参考。已有304人学习下载。该小结将协议流程转化为可操作的验证清单，能帮助读者快速定位转发异常节点，提升S1切换问题排查效率。

1. S1数据转发测试：先看数据流再看信令，别被三条路径绕进去

做过S1切换测试的人大概都遇到过这种尴尬：信令面显示切换完成，业务也通了，可复盘用户面时发现数据走的路径和预期的不一样。这个问题背后正是S1数据转发（S1 Data Forwarding）在切换前、切换中、切换后的路径切换。手头这份《S1 data forwarding测试小结.docx》把数据流向、GTP-U隧道标识（TEID）、承载接纳参数，以及从RRCConnectionReconfiguration到HANDOVER NOTIFY期间的用户面地址变化，整理成了一套可以直接照做的检查清单。适合要验证S1切换用户面连续性、或者刚开始接触核心网与接入网联调的工程师。按这套检查点去抓包和核对信令，能省掉不少来回翻消息的时间。

2. 数据流向与GTP隧道：切换数据走向和TEID的作用

2.1 切换前、切换中、切换后的三条数据路径

把S1数据转发讲明白之前，得先把“数据绕路”这件事说清楚。切换前，下行数据从SGW直接进源eNB，由源eNB发给UE，路径只有一条：SGW→源eNB→UE。切换一旦开始，情况就变了。原文写得直白：“切换前，数据走向sgw→source eNb，过程中sgw→source eNb→sgw→target eNb，切换成功后是sgw→target eNb。”也就是说，切换中多出来一段从源eNB回到SGW的转发链路。源eNB从SGW收到下行数据后，不直接发给UE，而是先送回SGW，由SGW再把这份数据转到目标eNB。

为什么这么绕？因为UE在切换执行阶段要做随机接入和定时提前调整，没法稳定接收下行数据，目标eNB又需要从源侧接续在途包。通过SGW中转，能保证切换完成前的下行用户面不丢包，同时也让SGW的下行路径切换有个缓冲时间。把三条路径放在一起对照更直观：

测试时要抓的关键就是“切换中”这一段。如果抓包看不到源eNB往SGW方向回传的业务包，说明转发链路没有建立；如果切换完成后目标侧还能收到来自源侧的转发包，说明转发隧道没有释放。这两个方向一个代表“没转起来”，一个代表“没停下来”，都是S1数据转发测试里最常见的异常。

2.2 TEID与Sequence Number：在哪看、怎么用

GTP-U隧道在S1用户面上承载业务数据，TEID就是GTP-U头里的隧道端点标识。每个eNB分配TEID后，SGW或对端eNB把数据包放进对应隧道，接收端根据TEID区分这个包属于哪个UE、哪条承载。之所以强调这一点，是因为后面第4章里0x01001008、0x0000115b、0x01000a09、0x01000a08这四个值不是IP地址，而是GTP-U层看到的TEID。测试报告里写“地址”，实际抓包界面上显示的就是“TEID”一栏。理解这一点，才能把信令里下发的内容和报文里的字段对应上。

Sequence Number在GTP-U头里承担数据流量顺序标记。需要提醒的是，它并不是所有报文都有：只有带扩展头的GTP-U包才可能携带序列号，很多实现里普通G-PDU的序列号直接填0。所以排查丢包和乱序时，千万别把Sequence Number当成唯一证据，我更习惯把它和抓包时间戳、S1AP信令里的COUNT值放在一起看，互相印证。

抓包时建议这样起抓包任务：

# 抓S1-U用户面，默认端口2152；-s 0 保证完整报文 tcpdump -nn -i eth0 -s 0 "udp port 2152" \ -G 60 -w /tmp/s1u_%Y%m%d_%H%M%S.pcap

这里-G 60表示每60秒自动滚动一个新的pcap文件，避免长时间抓包产生超大文件；-w指定原始报文落盘；-s 0是抓整包，不截断。如果只想看某个隧道的流量，可以先抓到文件里再过滤：

# 单独筛出目标小区转发隧道，例如TEID 0x01000a09 tshark -r /tmp/s1u_xxx.pcap \ -Y "gtp.teid == 0x01000a09" \ -T fields -e frame.time -e frame.len

-Y后面是显示过滤器，gtp.teid == 0x01000a09表示只留下匹配该隧道标识的GTP-U报文；-T fields -e frame.time -e frame.len把时间戳和长度打成表格，便于后续核对数据路径切换的先后顺序。常见做法是源侧、目标侧各起一路抓包，再按TEID分别统计，这样能直接看出数据是从哪个隧道流入的。

3. 切换信令与承载接纳：HANDOVER REQUEST ACK中的关键参数在哪里看

3.1 目标侧的承载接纳：从HANDOVER REQUIRED到HANDOVER REQUEST ACK

先列切换准备阶段的大流程。UE上报测量报告后，源eNB做切换判决，然后向MME发送HANDOVER REQUIRED。MME收到后向目标eNB发送HANDOVER REQUEST，目标侧要先做接纳控制，检查目标小区资源、无线承载可接纳性，再决定是否接受这个切换请求。如果目标小区资源够，且UE接入被允许，目标eNB才会返回HANDOVER REQUEST ACK。

这是S1切换的核心握手：目标侧没有回ACK，源eNB就不能给UE发切换命令。实际测试里经常看到切换失败在“HANDOVER REQUEST ACK一直不回”或“回的是HANDOVER FAILURE”，原因多集中在目标小区接纳算法、PRB资源和承载并发数上。所以做S1数据转发验证之前，先确认这条ACK链路是通的，否则后面看数据面没有任何意义。

3.2 ACK中的关键参数：eNB UES1AP ID、数据隧道标识、转发隧道标识

HANDOVER REQUEST ACK消息不是简单回个“成功”，它携带的参数直接决定后续用户面怎么走。原文里提到“包含目标侧分配的eNBUE S1AP ID，接纳成功的EPS承载对应的目标eNodeB侧数据传送的地址（目标小区数据隧道标识、目标小区数据转发隧道标识）等参数”。把这些参数拆开看：

这些参数在用户面报文里显现为TEID或GTP-U地址。目标eNB返回ACK后，MME再回HANDOVER COMMAND给源eNB，源eNB才获知目标侧分配的转发目的地址，并根据该地址构造数据转发隧道。如果某条承载接纳失败，该承载就不会携带转发地址，切换期间源侧不转发这条承载的数据，而是由SGW处理缓冲数据，这个细节在测试时容易漏。

3.3 HANDOVER COMMAND之后：源侧拿到目标地址后怎么用

源eNB收到HANDOVER COMMAND后，会解析出目标侧分配的转发地址，然后把所有未发送的下行用户面数据按EPS承载重新封装，发到目标侧转发隧道。如果是间接转发，数据会先到SGW，再由SGW转到目标eNB；如果是直接转发，源eNB直接发给目标eNB，路径上不会有SGW这一跳。

原文里“source eNb → sgw → target eNb”这个回环形态，说明这套测试环境配置的是间接转发路径，或者SGW还没完成下行路径切换。测试时如果发现转发包出现在SGW侧，不用慌张，这是间接转发的正常形态。要关注的是：这个转发过程是否在RRCConnectionReconfiguration之后才启动、在收到END MARKER之后是否停止。这两条时间线对上了，数据转发才算真正闭环。

4. RRCConnectionReconfiguration前后：从0x01001008到0x01000a08的数据路径检查

4.1 分界点：RRCConnectionReconfiguration命令

源eNB下发RRCConnectionReconfiguration给UE后，UE才开始脱离旧小区、同步到新小区，所以这条信令是切换执行阶段的明确分界点。原文的检查点口径是：源eNB向UE发送RRCConnectionReconfiguration消息之前，数据流量通过源小区的数据传送地址0x01001008；消息发送之后，数据流量切换到数据转发隧道，源小区侧的转发地址是0x0000115b，目标小区侧的转发地址是0x01000a09。

这里要澄清一个容易误解的点：RRC命令的作用不只是“让UE切小区”，它也给了源eNB一个明确的执行时刻，在这一时刻之后，源eNB把下行用户面从原始数据隧道切到数据转发隧道。目标eNB收到转发隧道里的包后，在UE随机接入完成前先缓存，等上行同步完成后再按序交给UE。测试者拿到这些地址时，要看的是“切换时刻前后数据是否按预期换路”，不要用单纯的ping通与否来判断用户面切换成功。

4.2 四个GTP-U地址的对应关系与验证时机

把原文里出现的四个地址放到时间轴上，对应关系会更清楚：

注意0x01000a08虽然在HANDOVER REQUEST ACK阶段就已被目标eNB分配，但它不能提前承载业务数据。若SGW下行路径尚未切换，业务包就走到0x01000a08，会把本应承接在转发路径上的包和正常下行包混在一起，切换完成后反而容易出现乱序和重复包。测试判断依据是：RRC重配置前，源小区0x01001008有包；RRC重配置后，转发隧道0x0000115b与0x01000a09有包；HANDOVER NOTIFY之后，0x01000a08才成为持续数据来源。

4.3 抓包验证：一条命令看清数据路径变化

实操可以在目标侧抓pcap的同时过滤这四个TEID，一次把路径切换过程拉出来：

# 四个地址放同一个过滤器里，按时间顺序看路径切换 tshark -r /tmp/target_s1u.pcap \ -Y "gtp.teid == 0x01001008 || gtp.teid == 0x0000115b || gtp.teid == 0x01000a09 || gtp.teid == 0x01000a08" \ -T fields -e frame.time -e gtp.teid

输出结果是每一行时间戳加隧道标识，能直观看到四条地址出现的先后顺序。如果发现顺序反了，比如RRC重配置前就出现0x01000a08，大概率是抓包时间不同步或路径切换提前完成，别急着下结论，先用同一台服务器上的抓包对齐时间轴，再回看信令时间点。

5. 常见问题排查：S1数据转发容易翻车的四个现场

5.1 END MARKER之后源侧还在转：先查SGW切换时机

现象：END MARKER已经从SGW发给源eNB，源eNB也把它转发给了目标侧，但抓包里依然能看到源eNB继续往转发隧道推普通G-PDU。

原因：END MARKER只告诉源eNB“这是最后一条数据”，没告诉它“你现在就停”。如果源侧转发状态机没有把END MARKER当作停止条件，或者SGW下行路径切换和END MARKER发送两条流程没有严格按顺序执行，源eNB就会在END MARKER之后继续发缓冲包。

解决：把SGW下行路径切换信令、END MARKER到达源侧时间、源eNB最后一条转发G-PDU时间放在同一时间轴上比对。通过标准是：END MARKER之后源侧不再出现新业务包，目标侧在收到END MARKER后把缓存包全部提交给UE。

5.2 RRC重配置后仍走源小区地址：先查转发指示

现象：RRCConnectionReconfiguration已经发给UE，但目标侧抓包发现0x01001008这个源小区数据传送地址上还在持续出现下行业务。

原因：源eNB没有在RRC重配置命令之后把用户面切到转发隧道，常见于该承载没有配置“数据转发指示”，或者HANDOVER COMMAND里带了“Data Forwarding Not Possible”。这种情况下源eNB并不认为自己需要转发数据，SGW也没有建立转发通道，所以下行数据还在原隧道上排队。

解决：回头查HANDOVER COMMAND里的承载信息。如果消息里没有转发地址，说明这一条承载切换期间不做数据转发，SGW会通过缓冲加路径切换来保证下行不丢。测试补充一点：这种场景下SGW仍然会发END MARKER，但源eNB不再转发它给目标侧，看起来像“END MARKER没传到”，其实是正常行为，别把它当成丢包处理。

5.3 目标侧提前收到业务数据：HANDOVER NOTIFY才是基准

现象：HANDOVER NOTIFY还没送出去，目标侧0x01000a08地址上就已经出现了业务G-PDU。

原因：某些目标eNB在接纳完成后会先建好S1-U数据面，SGW下行路径也提前切到了目标，导致目标小区数据隧道提前有流量。对单个UE来说影响不大，但大量UE并发切换时会放大乱序风险。

解决：判断切换完成与否，必须以HANDOVER NOTIFY和后续的UE CONTEXT RELEASE作为信令基准，不能只看“目标侧有没有业务包”。我一般会要求测试记录里单独列出“0x01000a08首包时间”和“HANDOVER NOTIFY发送时间”两个字段，两者差值超过阈值就要提醒开发确认路径切换时序。

5.4 END MARKER混进普通GTP-U数据统计：别把0xFF和0xFE搞混

现象：统计目标侧吞吐时把END MARKER也算进去了，导致结果比实际值偏高。END MARKER其实没有用户数据，负载长度为0，消息类型是GTP-U的0xFE，而普通G-PDU是0xFF。有的数据面解析器只按IP加端口分类，看到UDP端口是2152就当成用户流量，于是把它记进了吞吐统计。

解决：抓包脚本里加一条显式规则，过滤gtp.message_type == 0xfe，做吞吐统计前把长度为零的GTP-U消息剔除。

注意：END MARKER和GTP-U Echo Request都可能在S1-U端口上周期性出现，Echo Request本身是保活机制，会反复上报；END MARKER只在下行路径切换时出现一次。抓包时看到GTP-U端口上的零负载报文，先分辨消息类型再下结论。

6. 进阶验证：把END MARKER和转发地址检查固化成一条命令

6.1 用tshark把End Marker与TEID检查做成一段脚本

与其每次翻信令，不如把S1数据转发的关键检查点固化成一段小脚本，输入一个pcap文件，直接输出两条关键证据：END MARKER出现时间，以及四条隧道流量的先后顺序。

#!/bin/bash # 用法: ./s1_data_forwarding_check.sh /tmp/target_s1u.pcap PCAP=$1 echo "=== 1) End Marker 报文 ===" tshark -r "$PCAP" -Y "gtp.message_type == 0xfe" \ -T fields -e frame.time -e gtp.teid echo "=== 2) 四条隧道流量顺序 ===" tshark -r "$PCAP" \ -Y "gtp.teid == 0x01001008 || gtp.teid == 0x0000115b || gtp.teid == 0x01000a09 || gtp.teid == 0x01000a08" \ -T fields -e frame.time -e gtp.teid

第一段筛出End Marker，用来确认它有没有出现以及出现次数；第二段按时间加TEID组合输出，能直观看清“源数据隧道→转发隧道→目标数据隧道”的切换顺序。实际使用时，把脚本里的TEID替换成被测小区的实际分配值即可。

6.2 把检查点固化成验收清单

脚本输出之后，落到验收清单上，测试结论会清晰很多：

我以前做S1切换测试，总习惯一条条点开信令看，直到有一次版本验证漏掉了RRC重配置后的转发地址切换，一条链路从下午查到深夜，最后发现是源eNB没有切隧道，白白浪费了一晚上。从那以后，每次做S1切换复测，我都会先在目标侧抓一份pcap，跑一遍上面的脚本，把四个隧道和END MARKER的先后顺序打印出来再继续。数据路径对了，后面信令分析才有意义。希望帮到你。

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