★ FEATURED ARTICLE 简介这份S1数据转发测试小结文档面向移动通信核心网与无线侧测试人员、LTE切换流程学习者聚焦切换过程中S1数据转发如何保持业务连续性。内容先说明切换前数据从服务网关到源eNodeB、切换中经服务网关转往目标eNodeB、切换后直连目标eNodeB的流向变化再解释TEID对GTP隧道端点的标识作用与Sequence Number对数据包顺序的记录方式并梳理目标eNodeB承载接纳、HANDOVER REQUEST ACKNOWLEDGE消息中的隧道参数以及End Marker检查点和源小区数据传送地址、源与目标转发地址、目标小区数据传送地址之间的切换关系帮助读者建立从测量报告、切换决策到数据转发、UE同步和资源释放的完整信令脉络。资源包共1个docx文件大小约769KB便于查阅和整理笔记。已有305人学习适合需要理解S1切换数据转发验证要点、排查转发异常与梳理测试检查项的中级技术人员参考。1. 为什么先做数据转发测试切换成功率数字背后的用户面连续性切换成功率往往被当成一次网络调优的最终分数但做过现场的人都知道真正让用户掉线、卡顿、重连的常常不是信令没走通而是信令走通了、用户面却断了那一两秒。S1 数据转发测试要解决的正是这个盲区UE 从一个小区切到另一个小区时源侧缓存的数据、在途的数据、切换完成后新到的数据能不能一条不丢、不乱、不重地送到目标侧并在正确的时间点完成隧道地址切换。这套方案适合两类人一类是要交移动通信方向毕设或课设的学生需要一份能跑通、能自圆其说的测试流程另一类是在做切换问题定位的工程师手里有抓包却不知道从哪几个检查点切入。下面按信号流程、隧道映射、检查点判定、避坑到验收把整条链路拆开讲清楚。2. S1切换信令全景17条消息里的准备、执行、完成三段先给结论S1 切换的 17 条消息不是均匀推进的它被三个时间锚点切成三段——HANDOVER REQUIRED 之前是准备RRCConnectionReconfiguration 到 RRCConnectionReconfiguration Complete 是执行HANDOVER NOTIFY 之后是完成。数据转发的四个地址阶段就嵌在这三个锚点之间。不先把三段划清楚后面看抓包会乱。2.1 准备阶段HANDOVER REQUIRED 到 HANDOVER REQUEST ACK准备阶段的起点是 UE 上报 Measurement ReportseNB 内部做 HO decision然后源 eNB 向 MME 发 HANDOVER REQUIRED把源侧承载、UE 上下文、切换原因等带上去。MME 收到后向目标 eNB 发 HANDOVER REQUEST这一步是整个流程里对数据转发影响最大的环节因为目标 eNB 要在这一步做 Admission Control。目标 eNB 分配完目标侧资源后做切换入的承载接纳处理。如果资源满足、小区接入允许它给 MME 回 HANDOVER REQUEST ACKNOWLEDGE。这条消息里有三样东西必须盯住一是目标侧分配的 eNB UE S1AP ID它是目标侧对这个 UE 的临时身份二是接纳成功的 EPS 承载里目标 eNodeB 侧的数据传送地址也就是目标小区数据隧道标识三是同一批承载里的数据转发隧道标识也就是给源侧转发用的那组端点。这两组标识分开是后面数据不丢的前提——切换期间用转发隧道切换完成后再切到目标小区自己的传送隧道。源 eNB 收到 HANDOVER COMMAND才真正知道哪些承载被接纳、目标侧转发地址是什么。做测试时我一般在这里卡一个点抓 HANDOVER REQUEST ACK 和 HANDOVER COMMAND 这两条消息逐承载比对里面带的隧道标识any 一条对不上后面 End Marker 就会发到没人收的地址上。2.2 执行阶段RRC重配置与上下行同步源 eNB 收到 HANDOVER COMMAND 后向 UE 发 RRCConnectionReconfiguration消息里包含 mobilityControlInformation。注意这个时刻也是数据走向的分水岭发这条消息之前用户面数据走源小区的数据传送地址发之后源 eNB 开始在转发隧道上把收到的下行数据往目标侧送同时上行数据开始往源侧缓存或转发。执行阶段还有几个容易被忽略的动作。UE 收到 RRCConnectionReconfiguration 后从旧小区 detach与新小区做同步走的是 L1/L2 信令这一步只是物理层对齐不涉及 S1 用户面。目标 eNB 在完成同步后发 UL allocation TA for UE给 UE 上行授权和时间提前量。UE 回 RRCConnectionReconfiguration Complete执行阶段结束。中间还会穿插 eNB Status Transfer 和 MME Status Transfer源 eNB 把 PDCP 的上下行 count 状态通过 MME 转给目标 eNB让目标侧知道哪些包已经收过、哪些还没收这是避免重复和乱序的关键。很多同学在这里把 Status Transfer 当成“可选信令”其实它在数据转发里承担的是黑匣子的角色——一旦出现丢包回查这条消息里的 count 值就能判断是源侧发多了还是目标侧收少了。2.3 完成阶段Status Transfer、HANDOVER NOTIFY 与资源释放目标 eNB 在 UE 成功接入后向 MME 发 HANDOVER NOTIFY通知 MME 目标侧 UE 已经成功接入。从这一刻起目标侧的用户面隧道正式启用数据流量通过目标小区的数据传送地址发送而不是转发地址。MME 随后向源 eNB 发 UE Context Release源 eNB 释放资源整个 S1 切换收尾。完成阶段要验证的是“双地址并存的时间窗是否干净”。如果在 HANDOVER NOTIFY 之后还有包被发到源侧转发地址上说明源侧的下行路径没干净切换通常是 End Marker 没被正确识别或者转发隧道的定时器关得太晚。这个时间窗在测试记录里通常只持续几百毫秒但对抓包分析来说足够明显——按 GTP-U 的 TEID 过滤就能看到同一个承载在两个隧道标识上短暂并存然后收敛到目标侧那一个。把三段锚点画在一张时间轴上四个地址阶段就自然落位切换前是源小区数据传送地址切换中是源侧转发地址接收、目标侧转发地址转出切换后是目标小区数据传送地址。后面第 4 章的所有检查点都是在这张图上取点。3. 转发隧道设计TEID、传输地址与四个地址阶段的映射关系S1 数据转发测试能不能讲清楚核心在于把“隧道标识”和“传输地址”分开理解。原文的测试小结里把这几个十六进制值都叫“地址”但在抓包里它对应的是 GTP-U 隧道端点标识这一类字段。TEID 用于标记 GTP 隧道端点它标识的是“这条隧道是谁”而不是“这台设备在哪”真正把包送到对端的是承载在 S1-U 上的 IP 传输地址。把这两层搞混是转发测试里最常见的概念翻车。3.1 四类地址的分工传送地址、转发地址与目标侧接收地址按测试小结记录的四个阶段可以先整理成一张对照表。这张表是整篇方案里最值得直接抄走的一页因为它是后面抓包过滤和检查点判定的索引。阶段触发信令用户面出口测试记录标识切换前HANDOVER COMMAND 之前源小区数据传送0x01001008切换中上行方向RRCConnectionReconfiguration 之后源小区转发接收0x0000115b切换中下行方向同上目标小区转发接收0x01000a09切换后HANDOVER NOTIFY 之后目标小区数据传送0x01000a08这张表的读法是按时间从左往右走但注意中间一行实际上是两个方向并存的源侧把上行数据往 SGW 送同时把 SGW 下来的下行数据往目标侧转发。测试时如果只抓一个方向很容易得出“转发正常”的错误结论另一边其实已经断了。目标侧转发标识 0x01000a09 和目标侧传送标识 0x01000a08 只有最后一位不同这类“长得像”的标识在手工比对时最容易看错通常的做法是写进脚本按承载 ID 逐条比对不靠肉眼。3.2 TEID 与 Sequence Number区分隧道归属和数据顺序TEID 解决的是“这个包属于哪个隧道”Sequence Number 解决的是“这个包在数据流里排第几”。GTP-U 的 SN 是逐包递增的PDCP 的 SN 则在 Status Transfer 里被显式传递。转发过程中如果出现重包先看 GTP-U 的 SN 有没有断再看 PDCP 的 count 有没有重叠如果出现乱序先看是不是上下行两个方向在抓包时被混在了一起再看目标侧是不是把转发隧道和传送隧道的数据合并时没有按 SN 排序。一个实用习惯在测试脚本里把每个承载的四个标识和对应 SN 区间登记成结构体每抓一段包就回填一次。这样出了问题时可以直接回答“哪个承载、在哪个阶段、丢在第几个 SN”而不是笼统地说“转发有丢包”。# 承载级隧道登记表一个 EPS 承载对应四条隧道端点 bearer_map { bearer_id: 5, teid_pre_ho_src: 0x01001008, # 切换前源小区数据传送 teid_fwd_src_rx: 0x0000115b, # 切换中源侧转发接收 teid_fwd_tgt_rx: 0x01000a09, # 切换中目标侧转发接收 teid_post_ho_tgt: 0x01000a08, # 切换后目标小区数据传送 expected_sn_range: (0, 0) # 抓包后回填用于判定丢包区间 }这段结构体本身不复杂价值在于它把“一个承载、四条隧道、一个 SN 区间”固定成可复用的数据结构。参数上teid 字段用十六进制记录与抓包工具里显示的 gtp.teid 保持一致expected_sn_range 留空等抓包完成后按实际首末包回填再和 Status Transfer 里的 count 做交叉验证。3.3 从 HANDOVER REQUEST ACK 里取出目标侧转发参数回到信令层目标侧转发参数在 HANDOVER REQUEST ACKNOWLEDGE 里下发但它是嵌在 E-RAB 级别的结构里的不是单独一条消息。做测试脚本解析时要按 E-RAB ID 逐条取出“目标侧数据传送地址”和“目标侧数据转发地址”两组字段前者对应切换后的 teid_post_ho_tgt后者对应切换中的 teid_fwd_tgt_rx。我一般会在这条消息解析完之后加一道自检目标侧转发标识不能和目标侧传送标识相同。如果相同说明目标侧没有为转发单独分配端点切换期间的下行数据会直接走传送隧道End Marker 发过去后目标侧只会当成普通数据包处理转发阶段的收敛判断就失去意义了。这类配置错误在小规模测试环境里并不罕见往往在实验室里跑得好好的一上规模就暴露。另外注意HANDOVER REQUEST ACKNOWLEDGE 里带的是目标侧分配的参数源侧要等 HANDOVER COMMAND 才知道。测试记录里不要把这两条消息的字段合并成一份否则排查时无法判断是目标侧配错还是源侧解析错。4. End Marker 与三个检查点抓包怎么证明转发链路走通了数据转发测试的验收证据最终都要落到抓包上。但抓包不是打开 tcpdump 就完事得先知道在哪个接口抓、按什么字段过滤、三个检查点分别看什么。这一章按抓包位置、End Marker 识别、三个检查点判定顺序展开。4.1 End Marker 的作用与抓包位置选择End Marker 的目的很直接SGW 在把下行路径切换到目标侧之前向源侧发一个 End Marker 包源 eNB 收到后把它转发给目标 eNB等于告诉目标侧“这是我经源侧发来的最后一个包了收到它之后就不用再等转发数据了”。这个小包在抓包里是 GTP-U 消息类型 254不带用户载荷但它决定了目标侧什么时候可以把转发隧道关掉。抓包位置通常选三处源 eNB 与 SGW 之间的 S1-U、目标 eNB 与 SGW 之间的 S1-U、以及源 eNB 到目标 eNB 的转发路径如果测试环境里这条路径经过可抓包的交换点。三处同时抓才能把“SGW 发出 End Marker → 源侧转发 → 目标侧收到”这条链完整串起来。只抓源侧一处看到 End Marker 出现只能证明它到了源侧证明不了它被转发出去。# 在源 eNB 与 SGW 之间的 S1-U 接口抓包只保留 GTP-U tcpdump -i eth1 -s 0 -w /tmp/s1u_source.pcap udp port 2152 # 抓完后用 tshark 过滤 End MarkerGTP-U 消息类型 254 tshark -r /tmp/s1u_source.pcap \ -Y gtp.messageType 254 \ -T fields -e frame.number -e ip.src -e ip.dst -e gtp.teid2152 是 GTP-U 的标准 UDP 端口-s 0表示抓完整包避免大包被截断导致 GTP 头解析失败。tshark 那行只输出帧号、源 IP、目的 IP 和 TEID 四列这样一条承载的 End Marker 是否出现、从哪来到哪去一眼就能看出来。命令里的-Y是显示过滤器语法gtp.messageType 254精确匹配 End Marker不要把 254 写成 255后者是 G-PDU会把所有业务包都筛进来。4.2 检查点一切换前数据走源小区数据传送地址第一个检查点定位在 HANDOVER COMMAND 之前。这一段用户面应该是干净的UE 上下行业务数据都通过源小区的数据传送地址走测试记录里对应 0x01001008。抓包时按这个 TEID 过滤看包数是否连续、SN 是否单调递增。判定标准不复杂在 HANDOVER COMMAND 时间点之前这个 TEID 上应该持续有包且 SN 没有跳变。如果出现 SN 跳变说明源侧在切换准备期间就已经有丢包问题不在转发逻辑而在切换前的无线侧或传输侧。这一步是后面所有检查点的基准线基准不干净后面的分析就是无源之水。4.3 检查点二RRC重配置后走双向转发地址第二个检查点定位在 RRCConnectionReconfiguration 发出之后、HANDOVER NOTIFY 之前。这一段是转发的主战场两个方向并存上行方向源侧通过 0x0000115b 对应的转发接收地址收包下行方向目标侧通过 0x01000a09 对应的转发接收地址收包。两个方向的判定逻辑不同——上行看源侧是否把 UE 的数据正确送到 SGW下行看 SGW 下来的数据是否经源侧完整送到目标侧。我通常会为这一段单独写一个判定函数输入是抓包过滤后的包列表输出两个方向的包数、首末 SN、以及 End Marker 是否出现在预期位置。判定函数的核心逻辑是“时间窗内的包数守恒”源侧从 SGW 收到的下行包数应该等于源侧转发给目标侧的下行包数差值只能来自源侧缓存和 End Marker 本身。def check_forwarding_window(pkts_fwd_src, pkts_fwd_tgt): 检查切换窗口内源侧转发与目标侧接收是否守恒 sent [p for p in pkts_fwd_src if p.teid 0x0000115b] # 源侧转发接收 recv [p for p in pkts_fwd_tgt if p.teid 0x01000a09] # 目标侧转发接收 sent_sn [p.sn for p in sent if p.sn is not None] recv_sn [p.sn for p in recv if p.sn is not None] # 目标侧收到的 SN 区间应覆盖源侧发出的区间缺哪一段就丢在哪 missing sorted(set(sent_sn) - set(recv_sn)) return { sent_count: len(sent), recv_count: len(recv), missing_sn: missing[:10], # 只列前 10 个避免日志过长 end_marker_seen: any(p.is_end_marker for p in sent), }这段函数的输入是两组已经按 IP 和端口预过滤的包列表sent 对应源侧转发接收标识recv 对应目标侧转发接收标识。missing_sn 输出的是源侧发了但目标侧没收到的 SN只列前 10 个是为了日志可读实际排查时可以改成全量。end_marker_seen 用来确认源侧是否在窗口内看到了 End Marker它是目标侧关闭转发隧道的依据缺了它目标侧可能一直等下去。4.4 检查点三HANDOVER NOTIFY 后走目标小区数据传送地址第三个检查点定位在 HANDOVER NOTIFY 之后。这时目标侧用户面隧道正式启用数据流量通过目标小区的数据传送地址发送对应 0x01000a08。判定重点是“旧隧道是否按时静默、新隧道是否立即接上”。具体看两个量一是源侧转发接收标识上在 HANDOVER NOTIFY 之后是否还有包理论上应该迅速归零二是目标侧传送标识上是否出现持续递增的 SN且和 Status Transfer 里的 count 衔接得上。如果旧隧道不静默通常是源侧用户面转发定时器过长如果新隧道接不上通常是目标侧没有完成 PDCP 重排序包进来了但没往上送。三个检查点连起来就是一条从“切换前”到“切换中双向”再到“切换后”的证据链。验收时不需要展示整段抓包只要把三个时间窗的包数、SN 区间和 End Marker 位置列成一张小表链路是否走通就一目了然。5. 数据转发测试的避坑清单五类最容易翻车的现象与排查测试做得多了会发现转发链路的故障模式高度集中翻来覆去就那么几类。下面五条是现场和实验室里出现频率最高的每条按现象、原因、解决三个部分写方便对照自己的抓包结果。5.1 现象End Marker 出现在源侧但目标侧没收到原因通常在转发隧道配置上。源 eNB 收到 End Marker 后要按 HANDOVER COMMAND 里带的目标侧转发地址转出去如果这个地址在承载接纳时被配成了目标侧传送地址End Marker 会被发到一个当前还没有接收者的隧道上目标侧自然收不到。另一种情况是转发隧道没启用源侧收到 End Marker 后直接丢弃。解决办法是回到 HANDOVER REQUEST ACKNOWLEDGE 和 HANDOVER COMMAND 两条消息逐承载比对目标侧传送标识和目标侧转发标识是否不同。如果相同说明目标侧没有为转发单独分配端点需要在网络配置里补上或者接受“无转发”的降级模式并相应调整验收标准。5.2 现象转发窗口内包数对上了但目标侧重组后仍缺包这是典型的“抓包位置选错”。在源侧转发出口抓到的包数和在目标侧转发入口抓到的包数中间还隔着传输链路如果只在源侧一处抓看到的是“发出去了”不是“收到了”。测试记录里应当明确标注每个抓包点的位置包数守恒的判定必须在目标侧入口完成。解决办法是在目标侧 S1-U 接口补一处抓包按同一个 TEID 过滤后与源侧出口比对。如果目标侧少包问题在传输链路或目标侧接收缓冲区如果目标侧不少问题在 PDCP 重排序要去看 Status Transfer 里的 count 是否被正确应用。5.3 现象上行转发正常下行转发丢包严重上下行方向不对称多半是速率或缓存不匹配。下行转发是从 SGW 到源侧再到目标侧两跳传输源侧缓存如果只按单跳容量配置切换窗口里就会出现瞬时溢出。上行方向只有一跳相对不容易暴露。解决办法是先看源侧转发出口的丢包是否集中在窗口前段如果是说明缓存不足需要调整源侧用户面转发队列长度如果集中在 End Marker 之后说明源侧在收到 End Marker 后提前关闭了转发通道还有在途包没送出去这时要检查 End Marker 的处理顺序是否是“先转发完在途包再关通道”。5.4 现象TEID 冲突导致两个承载的包混在一起多承载并发切换时如果目标侧分配的转发标识和其他承载的传送标识相同抓包里就会出现两个不同业务的数据挂在同一个 TEID 上。这种现象在单承载测试里不会出现一上多承载就暴露属于典型的“实验室跑得好、现场翻车”。解决办法是在 HANDOVER REQUEST ACKNOWLEDGE 解析完成后做一次全局查重把所有承载的传送标识和转发标识放在一个集合里出现重复立即报警。查重逻辑要覆盖“本承载的转发标识与其他承载的传送标识相同”这类跨类型冲突不能只查同类型内部。5.5 现象切换完成后目标侧仍收到转发地址来的包旧隧道不静默最常见的原因是源侧转发定时器没有随 HANDOVER NOTIFY 触发关闭而是等固定超时。另一个原因是 SGW 侧的下行路径切换滞后还在往源侧发数据源侧只能继续转发。解决办法分两步先看 SGW 侧的下行路径切换是否在 HANDOVER NOTIFY 之前完成如果滞后说明 SGW 的路径切换和 MME 的信令不同步再看源侧转发定时器配置通常的做法是收到 End Marker 后立即停止接收新包只把已缓存的包转发完然后关闭通道而不是等固定时长。6. 验收与答辩用一张检查点表把转发链路讲清楚验收环节最怕的是“抓了一堆包讲不出重点”。我一般会准备一张检查点表把四个地址阶段、对应信令锚点、抓包位置和判定标准放在一页里答辩或交付评审时按时间顺序过一遍比放十张时序图都有效。检查点信令锚点抓包位置判定标准CP1 切换前HANDOVER COMMAND 之前源侧 S1-UTEID 0x01001008 包连续、SN 单调CP2 切换中上行RRCConnectionReconfiguration 之后源侧 S1-UTEID 0x0000115b 收包完整CP3 切换中下行同上目标侧 S1-UTEID 0x01000a09 收包与源侧发出守恒CP4 End MarkerSGW 路径切换前源侧、目标侧 S1-U两侧均出现 GTP-U 类型 254CP5 切换后HANDOVER NOTIFY 之后目标侧 S1-UTEID 0x01000a08 包连续旧隧道归零讲的时候按 CP1 到 CP5 顺序推进每个点只说三件事这个时间窗里应该看到什么、实际看到了什么、差异怎么解释。评委或评审最常追问的是 CP3 和 CP4 的关系因为 End Marker 的转发路径和业务数据的转发路径是重合的要能说清楚“End Marker 是最后一条经源侧转发路径的数据包它后面不应该再有转发业务包只应该有目标侧传送地址上的新包”。有一套讲法我用了很多次先给出切换前、切换中、切换后三张抓包片段每张只截取一个承载的 GTP-U 头标出 TEID 和 SN然后在旁边写上对应信令消息的时间戳。这样即使对方不熟悉 S1 接口也能看懂“地址在什么时候变了、变了之后数据有没有断”。我自己的血泪经验是早期做这套测试时总想把 17 条信令全讲一遍结果讲到第七分钟评委已经走神了真正决定成败的四个地址阶段反而没时间展开。从那以后我每次准备验收材料都强制先把检查点表填满每个检查点配一段不超过 30 秒的讲稿讲稿里只出现一个 TEID 和一个时间戳讲完再展开细节。这套习惯帮我省下了不少返工也希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
