简介S1数据转发测试小结是一份面向移动通信协议测试与网络优化工程师的技术笔记聚焦LTE与5G切换场景下S1接口数据转发的验证方法。文档从数据流向切入梳理了切换前后服务网关、源基站、目标基站之间的数据路径变化并结合TEID与序列号说明GTP隧道标识和报文顺序在转发中的作用。内容深入讲解了切换流程中切换请求确认、切换命令等关键信令以及数据转发核心检查点如End Marker的发送时机、源小区与目标小区数据传送地址和转发地址的切换判断等同时概述测量报告、切换决定、接纳控制、无线资源控制重配置等完整流程。资源为一份Word文档大小约769KB内容结构清晰适合需要系统理解S1数据转发原理及测试要点的研发与测试人员参考学习已有304人浏览学习。1. S1数据转发下行数据为什么要先绕回SGW最后靠End Marker喊停在LTE切换的用户面里最反直觉的一幕发生在S1接口上SGW明明已经把目标小区的话握在了手里却要把下行数据先送到源eNB再由源eNB把数据“原路退回”SGW最后由SGW送到目标eNB。数据在S1-U上画了一个完整的U型弯。更耐人寻味的是这场接力不是靠“切换完成”这类确认信号收场而是靠一个净荷为空的GTP-U包——End Marker——来宣告“这是最后一个包你可以歇了”。它丢了也没人重传全凭各网元自觉。搞懂这个S1 data forwarding机制是做切换测试、定位切换断流、理解为什么“绕路”和“空包”恰好能换来不丢包的底层前提。2. 数据面路径与GTP隧道TEID和Sequence Number在转发中各管什么2.1 三个阶段的数据路径直连、拐弯、再直连切换前下行只有一条路SGW → 源eNB → UE。这条隧道终点是源eNB的数据传送地址就是文档里反复出现的0x01001008。此时MME可能已经把测量报告收走、甚至已经发出了HANDOVER REQUIRED但用户面纹丝不动——切换准备阶段的信令再多也不影响数据继续走老路。切换执行开始后路径变成两段SGW → 源eNB旧隧道以及源eNB →(经SGW)→ 目标eNB转发隧道。注意转发隧道的方向源eNB把数据往“回”发先送回SGW再由SGW递到目标eNB的转发地址0x01000a09。这就是间接数据转发indirect data forwarding。为什么不是源eNB直发目标eNB因为S1切换场景下两个eNB之间不一定存在可用的直连转发路由MME在收到HANDOVER REQUIRED时要判断直接转发是否可行判断依据包括两端eNB能否在用户面直连、是否经过同一个SGW等。判断为否时就建立一条“源→SGW→目标”的间接转发隧道。等于把SGW当转发锚点用一跳额外的传输时延换取了“任何S1切换都能转发”的通用性。切换完成后路径又变回直连SGW → 目标eNB终点是目标eNB的数据传送地址0x01000a08源eNB彻底退出用户面。这期间源eNB还要干两件脏活把到达的、来不及调度的下行包缓冲起来再通过转发隧道送往目标目标eNB则把转发来的包缓冲住等UE随机接入成功后按序下发。文档图例里的“Deliver buffered and in transit packets to Serving Gateway”和“Buffer packets from Serving Gateway”说的就是这两个动作。三条路径对应三个测试观察点也就是文档检查点4.2想表达的看RRC重配消息前后、HO NOTIFY前后数据分别打在哪个地址上。2.2 TEID隧道端点由接收方分配检查时要认完整F-TEIDGTP-U隧道是单向的每一方向用独立的隧道端点标识TEID标记。关键是这个分配规则谁收包谁分配TEID。SGW→源eNB这条下行隧道的TEID由源eNB在承载建立时分配通过S1AP信令交给SGWSGW→目标eNB的新下行隧道TEID由目标eNB在HANDOVER REQUEST ACK里分配转发隧道两端的TEID也分别由各自端点分配。发包方没有任何选择权只能按信令里拿到的TEID填进GTP头。我在测试里见过最多次的乌龙就是把“源侧看到的TEID”和“目标侧看到的TEID”当成同一个值去比对实际上GTP-U每个方向各用各的TEID本来就是两个数。GTP-U v1的固定头只有8字节结构很紧凑GTP-U固定头8字节 Byte 0: version(3bit) | PT(1bit) | 0 | E | S | PN Byte 1: Message Type0xFF表示GTP-U数据PDU Byte 2-3: LengthEnd Marker时为0 Byte 4-7: TEID 当S位为1时Byte 8-9为Sequence Number文档里的0x01001008、0x0000115b这类值是测试平台对F-TEIDIP地址TEID的合称的一种简写展示。检查时不能只对TEID数字要核对完整的IPTEID二元组。这跟寄快递一个道理IP是小区门牌TEID是楼内房间号两个都对得上包裹才送得到人手上。另外注意目标侧两个地址0x01000a08和0x01000a09只差最后一位在实现里通常就是从同一块资源池里给“数据传送”和“数据转发”各取一个端点抓包看到两个地址同源同段非常正常别当成同一个地址。2.3 Sequence NumberGTP-U的SN管对账PDCP的SN才管顺序GTP-U头里的16位Sequence Number可选很多实现默认填0不仔细看文档的话很容易在这里白耗一晚上。它的用途不是接收端排序——GTP-U本身不保证顺序、也不做重排SN实际是给丢包检测、时延测量这类“对账”需求用的。转发测试里发现GTP-U SN一直是0不代表数据有问题只说明该实现没启用这个字段。真正决定切换后数据顺序的是PDCP层的Sequence Number。切换执行阶段源eNB通过eNB Status Transfer消息在S1口上由MME转发给目标eNB的SN Status Transfer把“下一个待发送的下行PDCP SN”和上行接收状态带到目标侧目标eNB据此接着编号继续发。测试里最容易翻车的地方就在这拿GTP-U的SN去对比两个eNB的PDCP SN完全是两个维度比不出任何结果。SN Status Transfer里那个数值一旦对不上UE在目标小区就会遭遇RLC重传风暴业务恢复慢得肉眼可见。3. 切换准备与接纳控制HANDOVER REQUEST ACK带回了哪三个关键参数3.1 Admission Control目标eNB在答应切换前先掂量什么源eNB不是在收到测量报告后就立刻放行的。它先做切换判决然后向MME发HANDOVER REQUIRED消息里带着UE上下文、需要切换的EPS承载列表、每个承载的QoS参数QCI、GBR、MBR、ARP和聚合速率上限UE-AMBR。MME把它透传给目标eNB也就是HANDOVER REQUEST。目标eNB随后要做Admission Control掂量三件事目标小区当前负载能不能容纳新承载QoS要求能不能满足UE的接入等级和小区接入控制允不允许进来。这些判断全部发生在S1AP信令里用户面上没有任何动静——所以测试时经常看到信令已经走到目标侧了DL数据还老老实实打在源小区这是正常的不是故障。一旦目标小区接纳失败目标eNB回HANDOVER PREPARATION FAILURE切换还没开始就结束UE继续留在源小区。麻烦的是“部分接纳”只有一部分承载被接纳成功其余被拒绝。被拒绝的专用承载在切换完成后可能直接被释放业务表现为某个数据流突然断了但信令流程一切正常。这个分支最容易被测试用例漏掉也是“切换成功但业务劣化”的隐藏来源。3.2 HANDOVER REQUEST ACK里的三个关键参数目标eNB接纳成功后回HANDOVER REQUEST ACK里面与数据面直接相关的参数可以整理成一张表参数含义对应文档地址eNB UE S1AP ID目标侧目标eNB为UE分配的S1AP标识后续S1AP消息都靠它寻址—目标小区数据传送地址DL S1-U TEID切换完成后SGW发送下行数据的目标端点0x01000a08目标小区数据转发隧道标识DL Forwarding TEID切换执行期间转发数据送达目标端的隧道终点0x01000a09注意区分“数据传送地址”和“数据转发隧道标识”前者是切换完成后长期使用的下行隧道终点后者是切换执行期间临时使用的转发隧道终点。两个都在目标eNB侧但生命周期完全不同。转发隧道在UE Context Release和Release Resources流程里就会被拆除而数据传送隧道会一直活到承载释放。测试时要在心里给这两个地址贴上不同的标签一个是“常住地址”一个是“临时借道”。3.3 HANDOVER COMMAND源eNB收到命令才知道往哪转MME收到HO REQ ACK后把目标侧信息封装进HANDOVER COMMAND发给源eNB。消息里的Target to Source Transparent Container携带RRC重配所需的mobilityControlInfo同时消息本身把接纳成功的承载列表和目标侧转发地址带给源eNB。关键是这个时点到这一刻源eNB才知道哪些承载被接纳了、转发数据该发到哪个F-TEID。此前它对目标侧的一切猜测都不作数一切都以HANDOVER COMMAND为准。所以测试里有个非常实用的检查点拿HANDOVER COMMAND里携带的目标转发地址与HO REQ ACK里的0x01000a09逐一比对。MME在这里只做透传不该改写地址。两条消息对不上优先怀疑MME侧承载上下文同步问题而不是无线侧。文档第7步“Handover Command”到第8步“RRC Conn. Reconf.”之间留出的信令空隙就是给源eNB“消化”这条信息用的。4. 切换执行与地址接力RRC重配前后四个F-TEID怎么交接4.1 RRC重配前后数据从传送地址切到转发地址执行阶段以源eNB发出RRCConnectionReconfiguration带mobilityControlInfo为分界点。消息发出之前UE还在源小区正常收发下行数据打在源eNB的数据传送地址0x01001008消息发出之后UE开始脱离旧小区、向新小区同步源eNB停止向这个UE调度新数据同时把SGW陆续发来的下行包转入转发通道先用源侧转发地址0x0000115b把它退回给SGWSGW再用目标转发地址0x01000a09送给目标eNB目标eNB把转发包缓冲起来等UE过来。整个0~17号流程里第8步RRC重配是用户面的“关门”信号第15步HANDOVER NOTIFY是“换门”信号第16~17步UE Context Release和Release Resources负责拆掉临时通道。这个分界点在测试里的价值特别大抓包时以RRC重配消息为时间锚点看同一条业务GTP隧道的数据包目标地址是否从0x01001008切换为转发路径。如果RRC重配发出去很久数据还打在源传送地址上说明源eNB的转发行为没被触发大概率是HANDOVER COMMAND里的转发地址没生效或源侧没建立起对应的转发隧道上下文。4.2 四元组接力一张表理清四个地址的登场顺序文档检查点4.2把四个地址放在一起相当于给S1数据转发用户面画了一张“舞台布景”地址归属与角色生效时点0x01001008源eNB数据传送地址SGW→源的下行隧道终点切换前一直在用切换完成后退役0x0000115b源eNB转发地址源侧转发隧道的端点RRC重配后启用资源释放时拆除0x01000a09目标eNB转发地址SGW→目标的转发隧道终点RRC重配后启用切换完成后拆除0x01000a08目标eNB数据传送地址切换后SGW→目标的新下行隧道终点HANDOVER NOTIFY触发改承载后启用切换测试的验收标准之一就是“四元组按序登场”切换前看到0x01001008切换执行期看到0x0000115b和0x01000a09成对出现切换完成后再也看不到前三个地址上有UE业务数据。任何一步地址没变用户面就一定还有问题。我在实际抓包里遇到过“0x01001008和0x01000a08同时有数据”的情况那不是负载均衡是SGW还没执行下行路径切换源eNB还在一边收新包、一边往转发通道里塞目标侧则同时从两条路收数据UE必然乱序。4.3 End Marker空净荷GTP-U包怎么给转发喊停SGW在把下行切换到目标之前会先在旧隧道SGW→源eNB上发一个End MarkerGTP-U头净荷为空Message Type是0xFFGTP-U数据PDULength字段为0。语义只有一句这是我发往这个方向上的最后一个包你收到后就不用再转发业务了。源eNB收到End Marker后做的事很关键——不是丢弃而是把它沿转发隧道再转给目标eNB。源eNB自己的用户面使命就此结束目标eNB收到End Marker后知道转发流已经排空不再干等后续转发包可以按序递交缓冲数据准备拆除转发隧道。这就是文档检查点4.1说的“source将此数据包转发给targetsource用户面就完成转发数据包的使命了”。End Marker不是可靠投递丢了也没人重传。它丢了怎么办目标eNB不会干等转发隧道最终会随UE Context Release流程被MME/SGW释放目标eNB拿“隧道资源释放”当兜底End Marker没到就多等一会儿、多缓冲一点。测试中出现“End Marker消失”时业务不一定马上断但目标侧可能在切换完成后的第一时间出现短暂的不下发——这是End Marker丢失的典型症状。抓包时可以用下面的过滤条件找它# 在S1-U上抓GTP-U空净荷包End Marker # End Marker没有净荷IP总长为 以太头14IP20UDP8GTP8 50字节 tcpdump -i s1u -nn -l udp port 2152 and ip[2:2] 50 -vv过滤原理是End Marker不带用户数据GTP-U固定头只有8字节IP总长字段正好等于50带业务数据的包总长一定大于50。抓到之后再核对TEID和转发隧道是否匹配就能确认它走的是不是预期路径。提示如果抓包口带VLAN标签以太头会变成18字节上面的IP偏移和长度判断会失效。稳妥的做法是先剥掉VLAN再过滤或者直接看GTP头的Length字段是否为0、净荷长度是否为0这两个判断在任何场景下都可靠。5. S1转发测试避坑End Marker丢失、地址不匹配与PDCP SN错位的排查清单5.1 现象End Marker出现在源侧抓包里目标侧却一直等不到原因源eNB的转发隧道表项没建成或者实现只在特定条件下转发End Marker例如按承载逐个判断空包被源eNB自己消化间接转发模式下End Marker还要穿过SGW某些实现把它当普通转发包处理不做特殊转发也会在目标侧消失。 解决在源eNB和目标eNB的S1-U两侧同时抓包。先在源侧确认收到End Marker再在转发路径源→SGW或源→目标上确认它被发出如果穿过SGW还要在SGW出口侧确认它确实被转出去。定位按“源入口→源出口→目标入口”三段夹逼哪一段断了问题就在哪一段。5.2 现象转发数据命中“TEID not found”包被对端直接丢弃原因HO REQ ACK里某个承载带了接纳信息却没带转发地址或者MME建立间接转发隧道时只覆盖了部分承载而源eNB把所有承载的数据都塞进了同一个转发通道。对端GTP-U协议栈查不到对应TEID的上下文直接丢包并回错误指示。 解决逐个承载核对三张表——HO REQ ACK里每个承载的DL Forwarding TEID、SGW侧转发隧道上下文里的承载列表、源eNB实际转发数据的承载列表。三张表必须一一对上。对不上的时候回查MME在收到HANDOVER REQUIRED后有没有正确决定“直接转发不可用”并建立间接转发隧道。5.3 现象UE在目标小区出现RLC层大量重传业务恢复慢原因十有八九是PDCP SN没衔接上。转发数据从某个PDCP SN开始而目标eNB从SN Status Transfer即eNB Status Transfer消息里拿到的“下一个下行PDCP SN”对不上要么Status Transfer没发要么MME没透传要么目标侧没有按接收状态等待缓冲而是直接按自己维护的SN下发造成重复或空洞。 解决在S1AP信令里核对eNB Status Transfer的Next DL PDCP SN与源eNB实际转发数据的起始SN是否一致。再次强调GTP-U的Sequence Number在这里没有排序意义别拿它来判断顺序判断顺序只看PDCP SN。5.4 现象HANDOVER NOTIFY已经发出下行数据却仍绕回源eNB原因目标eNB发HANDOVER NOTIFY只是通知MME“UE到了”真正让SGW切换下行路径的是MME随后发往SGW的Modify Bearer Request。这条S11信令如果因为承载上下文问题被拒SGW会继续把下行打向源eNB的0x01001008源eNB再转发回SGW。抓包看起来像数据在SGW和源eNB之间来回绕其实不是环路是路径切换没生效。 解决在S11接口上确认Modify Bearer Request把DL TEID更新成了目标eNB的0x01000a08。如果某个承载的Modify Bearer被拒绝检查SGW里该承载是否处于合适状态例如转发隧道上下文是否已经被错误删除导致SGW无法完成新旧路径的“改投”。5.5 现象GTP-U Sequence Number全为0丢包统计一片空白原因GTP-U头里的SN是可选字段很多实现默认不开启。没有SN转发链路两端的丢包对账只能靠PDCP SN或业务层重传统计来间接判断直接看GTP-U SN会得出“没有任何丢包”的假象。 解决需要精确丢包统计时在源eNB和目标eNB两侧用PDCP层的收发计数做对比确认设备支持并开启GTP-U SN后再把它作为统计口径。血泪经验把“哪个SN域能说明顺序”这件事在测试方案里写清楚再动手否则排查到深夜才发现是统计口径错了。6. 设计取舍转发为什么要绕路End Marker为什么只发不确认S1转发这套设计本质上是用“多余的路程”换“确定的不丢包”。UE从脱离源小区到随机接入目标小区之间有一个几十毫秒的通信空窗这期间到达源eNB的下行包如果直接扔掉TCP或许能靠重传救回来但实时语音、视频这类业务会立刻劣化到不可接受。转发隧道的作用就是给这段空窗铺一段临时轨道让包在空窗期间继续前进在目标侧排队等待。至于为什么绕SGW而不是源直接发目标前面说过eNB之间不一定有可直连的转发路由而SGW作为用户面锚点天然可达两端。通用性优先多一跳时延是买通用性的价格这个取舍在S1切换场景下几乎没得选。End Marker的“只发不确认”也值得单独品味。如果给End Marker加确认机制SGW就得为每个承载维护一个“等待转发确认”的状态机还要处理超时重发投入很大收益却很有限因为End Marker丢失的后果是有界的目标eNB最多多等一会儿最终会被转发隧道释放流程兜底。协议设计者因此选择了一个零净荷的告知包把复杂度推给最外层的资源管理流程。这是电信系统里典型的取舍哲学能用“告知超时兜底”解决的问题不轻易引入新的可靠传输状态机。理解了这一点再看S1数据转发测试里的各种异常判断依据就清晰了地址按不按序切换、End Marker走没走对路径、SGW有没有执行Modify Bearer这三件事就是用户面正确性的全部。验证方法也固定。从那以后我每次做切换业务测试都强制走一遍“三阶段路径确认”切换前记录源小区数据传送地址RRC重配后确认转发地址成对出现HO NOTIFY后在S11上确认SGW把下行TEID换成了目标小区传送地址。End Marker只要没在预期位置出现我绝不先怀疑无线侧而是回到HANDOVER COMMAND和转发隧道建立的S1AP信令里找原因。这个“先看地址、再下结论”的习惯帮我少翻了很多次车希望帮到你。本文还有配套的精品资源点击获取