★ FEATURED ARTICLE 1. 从EPC到5G核心网为什么用户面被单独拎了出来前几篇我们聊过5G的空口波形、双连接切换也聊过服务化架构里那些“网元之间互相调用API”的控制面设计。但有个问题我一直觉得值得单独写一篇就是用户的数据包在5G网络里到底是怎么一步步从手机走到互联网的。也就是这次要聊的5G网络数据包转发模型。先说个背景。4G时代的EPCEvolved Packet Core里用户面功能其实是分散的SGW负责“管隧道”PGW负责“绑地址、做QoS”两头各干各的而且部署位置被捆在核心网机房里。到了5G3GPP把用户面彻底集中成唯一一个网元——UPFUser Plane Function控制面则由AMF、SMF这些网元通过服务化接口来管。这个“控制面和用户面彻底分离”的变化才是理解5G转发模型的前提。1.1 一张扁平IP承载网解决不了的事很多人第一次接触5G转发模型时会有个直觉不就是把IP包从基站送到核心网再送出去吗跟4G甚至WiFi有什么区别区别主要在两处。第一5G的网络切片要求同一张物理网络上同时承载不同QoS等级的业务车联网的低时延消息、普通手机的视频流、海量物联网的零星字节不能挤在同一个转发策略里。第二边缘计算要求流量在靠近用户的地方就被“截胡”而不是全部绕回中心机房。这两件事都逼着转发模型从“一条路走到黑”变成“多条路按策略走”而策略由控制面的SMF下发用户面的UPF执行。这就是所谓的“转发模型”它从来不是路由器路由表的问题而是控制策略和转发执行怎么配合的问题。1.2 控制面与用户面分离带来的模型变化在5G里控制面网元SMF通过N4接口用PFCP协议去指挥UPF“建会话、下发转发规则”。注意这里不是传统网络里那样逐跳路由而是控制面告诉你这个PDU会话对应哪个QoS流、走哪个隧道出口、是否要做测量上报。UPF本质上是“执行器”它不自己脑补路由只听SMF的规则。这对排错人员其实是个好消息你在N3接口看到一个GTP-U隧道一定能在SMF侧查到对应的PDU会话上下文你在UPF里看到一个QoS Flow的计费量也能反查到是哪个切片、哪个DNN的流量。控制面和用户面分离后转发路径变长了但每一跳都可以用“控制面会话ID”串起来反而更容易定位。2. 一条业务数据包的完整旅程从手机到互联网我们把“数据包转发模型”落到一条真实的业务流上看比如你在手机上打开一个网页。这条流要经过UE、gNB、UPF最后到达外部数据网络。每一跳做的封装和解封装都不一样搞懂这一段后面所有概念都不会飘。2.1 空口上的每一步封装数据从应用层下来先是IP包在SDAP层被贴上一个QFI标签告诉基站“这个包属于哪个QoS流”。然后PDCP层做加密和头压缩RLC层做分段和重传管理MAC层调度资源PHY层把比特变成无线帧。这四层在空口上是层层递进的但对转发模型来说真正值得记住的是SDAP层它决定了包要映射到哪个数据无线承载DRB。举个例子浏览器流量一般是承载在DRB1上VoNR语音承载在DRB2上。两者在空口上各自排队、各自调度。基站的MAC调度器看到DRB2有包会给它更优先的时频资源看到DRB1的包就按普通数据排队。所以QoS的第一步其实是“包在空口上被塞进哪条DRB队列”。2.2 N3隧道IP包被套进GTP-U包在空口被正确接收后gNB把PDCP/RLC头拆掉还原出原始的IP包。然后把这个IP包封装进GTP-U隧道外面再套UDP和IP发给UPF。这条gNB到UPF的链路接口叫N3。GTP-U在这里扮演的角色相当于快递包裹的“外包装箱”箱子上写着收件方TEID里面装的是用户的真实IP包。为什么非要套隧道而不是直接路由因为gNB和UPF之间跑的可能是运营商内部承载网这里已经有大量的普通数据流。如果不套隧道用户的IP地址直接暴露在承载网上移动性管理和QoS策略都无从下手。套上GTP-U之后承载网只需要关心“这个TEID的包怎么走”用户IP反而变成内容。2.3 N6出口与AF业务流的交汇UPF收到GTP-U包后解封装看策略。如果UPF当前配置了本地分流或者边缘出口它可能直接通过N6接口发给本地数据网络比如边缘CDN服务器或企业园区网关。否则就发给中心数据网络大多数时候是互联网出口。这里有个关键点UPF在N6接口看到的包已经是“干净的、原始的用户IP包”。也就是说从UE到UPFIP包是乘客GTP-U是车厢从UPF到DN车厢被卸掉乘客直接上路。所以你在N6侧抓包抓到的就是普通IP flow你在N3侧抓包抓到的是GTP-U封装的IP flow。二者通过TEID和QFI相互对应。3. 三种“管子”三种尺子PDU会话、QoS流与DRB转发模型里最容易让人蒙圈的是三个概念PDU会话、QoS Flow、DRB。它们都叫“管道”但管道的层级完全不同。理不清这三层后面看信令流程和抓包都会一头雾水。3.1 它们到底是什么关系我习惯用一个比喻PDU会话是你通信运营商给你开的一条“专线”从你的手机一直到UPF出口它有自己独立的上下文和IP地址QoS Flow是专线里按业务划分的“服务等级通道”车联网消息、视频流、普通网页各自走各自的等级通道每个通道都有一个QFI编号DRB则是空口这一段承载这些等级的“物理车道”。三层不是一对一而是一对多和多对一。一个PDU会话里会建立多个QoS Flow一个QoS Flow可能被映射到某一个DRB上多个QoS Flow也可以复用同一个DRB。复用的规则由SDAP层根据基站配置决定通常是把QoS要求相近的流合并到同一个DRB减少空口逻辑通道数量。这一步的意义在于空口资源调度靠DRB、核心网转发靠QoS Flow、会话管理靠PDU Session三者各自独立演进通过映射关系关联起来。你在信令里看到的“PDU session establishment”“QoS Flow setup”“DRB setup”对应的是三层各自的建立过程缺一不可。3.2 映射规则错乱时会发生什么我在某商用项目上踩过一个典型问题VoNR语音的QoS Flow被错误映射到了默认DRB上结果话音包和普通数据包挤在一个队列里通话时延抖得没法听接通率却很高。这种问题从空口指标上看不出异常因为MAC调度正常BLER也正常但从转发模型的角度看是“标签贴错了车”。排查方法在gNB侧看SDAP映射配置在核心网看SMF下发的QoS规则两边一对比发现QFI到DRB的映射表被某次配置变更覆盖了。这类问题最好的规避方式是把“QFI→DRB映射”纳入配置基线管理每次变更后自动校验。4. 隧道不神秘N3/N9上的GTP-U细节与TEIDGTP-U隧道是5G转发模型里连接gNB和UPF的“大动脉”。很多人在实验室里能调通业务但一到排查就抓瞎原因就是没仔细看过GTP-U头。这里我把值得关注的字段摊开讲一讲。4.1 GTP-U头里值得注意的字段GTP-U头的标准结构里首先看Message Type0xFF表示G-PDU也就是真的业务数据0x01/0x02是Echo Request/Response用于路径保活。真正转发业务时你看到的大部分包Message Type都是255。然后是TEID隧道端点标识符。同一个隧道两端各有一个TEID上行从gNB发出时使用UPF分配的TEID下行从UPF发出时使用gNB分配的TEID。所以看TEID时一定要分清方向不能只看数值。再往下是扩展头。5G的GTP-U常带PDU Session Container扩展头里面有个关键的QFI字段标识这个包属于哪个QoS Flow。抓包里如果看不到QFI要么是抓包工具解析版本太老要么是基站/UPF配置了不带扩展头的模式。这在实际运维中是个常见坑你想按QFI做流控结果发现抓包里全是裸GTP-U就得先去查配置。4.2 TEID怎么保证“不串线”TEID其实就是一个32位整数它由接收端分配用于区分同一对IP地址上的不同隧道。如果没有TEIDgNB和UPF之间同一时间跑几百上千个用户的业务光靠外层IP地址完全没法区分谁是谁。TEID的分配遵循“谁接收谁分配”的原则UE发起会话时gNB为下行方向分配自己的TEID并告诉UPFUPF也为下行方向分配自己的TEID并告诉gNB。每一侧的TEID在各自的接收方向上唯一即可。所以排查隧道问题时要看三元组“对端IP 本端IP TEID”。同一组IP上不能出现重复TEID如果出现大概率是某侧网元在会话删除后没有及时回收TEID属于实现级bug。另一个需注意的是GTP-U的重传和乱序。因为UDP承载GTP-U本身不保证顺序但很多数据面实现会使用带序列号的扩展头。我只在实际项目里遇到过由于UE切换时两个隧道瞬间并发导致UPF侧出现轻微乱序的情况TCP不受影响UDP语音流偶尔会有十几毫秒抖动。最终是靠在UPF侧开启按序递交缓冲解决。5. UPF不是一台路由器的升级版本地分流与边缘部署把UPF单纯理解成“一台高性能路由器”是很多初学者的误区。路由器做的是“根据路由表把包从A口转到B口”而UPF做的是“根据控制面下发的规则决定这个包进隧道、出隧道、还是被本地截胡”。两者的差别在边缘部署场景体现得最明显。5.1 UPF越往下沉转发模型越偏“边缘”5G转发模型里UPF的位置不是固定的。它可以部署在中心机房也可以下沉到地市、园区甚至可以和基站同机房。UPF越往下沉业务流量到互联网的路径越短时延越小但UPF的覆盖范围越有限。下沉的代价是“同一用户的会话可能在不同UPF之间移动”。典型场景一辆测试车从城东开到城西中心UPF是唯一的锚点但边缘UPF跟着车走。这时锚点UPF负责保持会话IP不变边缘UPF负责就近出口两个UPF之间的N9隧道就要承担数据转发。N9接口和N3一样使用GTP-U但意义不同N9是UPF之间的接力隧道N3是gNB到UPF的接入隧道。5.2 ULCL和本地分流的工作过程边缘场景里最核心的机制是ULCLUplink Classifier中文一般叫上行分类器。它的职责是在UPF上把上行流量“分流”一部分匹配本地业务规则的包直接送去本地数据网络剩下的照旧发给中心UPF再走向大网。举个例子某园区部署了本地视频服务器园区里的5G终端访问这个服务器的流量走的是“UE→gNB→边缘UPF→本地服务器”完全不经过中心UPF。终端访问外部互联网的流量则走“UE→gNB→边缘UPF→N9隧道→中心UPF→互联网”。从终端的角度看IP地址始终没变因为它和中心UPF之间的PDU会话是保持的边缘UPF只是帮它“岔开了一部分流量”。这个模型对转发排错影响很大。遇到用户反馈“访问内网快、访问外网断”时第一反应不是查基站信号而是先确认流量在UPF上是否被ULCL分流规则匹配到了错误的方向。我这几年处理过的案例里相当一部分边缘业务故障是ULCL规则里IP前缀配置过宽把外网流量也引到了本地出口导致N6出口路由不全。6. 切换瞬间的数据转发看不见的包序与End Marker5G转发模型平时看起来很简单一到切换就露出真面目。UE从一个基站换到另一个基站时原来缓存在旧基站的数据怎么办新基站的数据怎么接上核心网怎么知道新路径这些全部由转发模型的“延续性”机制来处理。6.1 Xn切换中的直接与间接转发Xn接口切换是最常见的场景。源gNB通过Xn接口给目标gNB发切换请求目标gNB准备好资源后UE在目标侧接入同时源gNB把还没发完的下行数据通过Xn转发路径发给目标gNB。这个转发可以直接在源gNB和目标gNB之间走直接转发也可能因为中间隔着无法直连的传输网就绕到UPF走一圈间接转发此时N3流量会在UPF和目标gNB之间多跑一段。无论哪种转发核心目标是同一个不让下行数据因为切换中断太久。如果丢包TCP会自己重传问题不大如果乱序则可能触发TCP快速重传甚至性能下降。6.2 End Marker机制背后的道理为了在切换时避免乱序标准做法是源gNB发完缓存数据后给UPF发一个End Marker包。这个包不是业务数据它只代表“源侧的转发结束了”。UPF收到End Marker后会把它转发给目标gNB目标gNB看到End Marker之前的数据继续按序投递等收到End Marker说明源侧数据已经发完可以开始直接投递新路径到本侧的数据了。这段逻辑乍一看很绕原理其实和交通管制里的“清空路口”一样最后一辆旧方向的车必须留下标记否则新方向的车一进来新旧车流就在路口混在一起了。所以你在抓包里看到GTP-U带End Marker标志时不要当成业务包它是切换流程的“清除栅栏”。实测中的经验End Marker包在“源gNB到UPF”这一段大概率能看到但有些商用基站实现里如果Xn直接转发可用End Marker不一定产生。排查时不能因为没抓到End Marker就断定切换处理有问题。7. 实战在抓包里还原一次5G转发全程理论聊这么多最终还是要落地到抓包和排错。这里我分享一套自己常用的排查路径从抓包点选择到关键字段判断基本能覆盖大多数转发问题。7.1 抓包点怎么选数据面抓包主要在两个位置一是gNB侧N3口能看到UE的上行原始包被封装成GTP-U发出去也能看到从UPF下来的下行GTP-U包。二是UPF侧N3/N6口N3口对应上行进入封装、下行解封装N6口对应最原始的IP流。如果你在实验室里同时抓这两个点建议用“同一条业务流”做关联先在手机/终端上发起持续大包ping或下载保证有稳定的流量然后两端同时抓包再按外层IP、TEID、QFI逐层匹配。7.2 抓包里的几类关键线索实际打开抓包文件时我建议按三层过滤来看第一层先看外层IP和UDP端口。GTP-U固定用UDP 2152上下行的外层流方向是反的。上行源端口一般是不定端口、目的端口2152下行相反。如果看到大量非2152的UDP包先怀疑承载网VXLAN或分段路由的问题。第二层看GTP-U的TEID和Message Type。正常业务流里Message Type应该是255如果在业务过程中看到很多Echo Request/Response说明隧道保活机制在起作用但一般占比极小。如果Echo包太多可能要检查网元间链路是否抖动。第三层看扩展头里的QFI。同一个业务的上下行QFI应该一致如果不一致问题多半出在SMF下发的QoS规则或者gNB的SDAP映射上。另外你可以用QFI做统计如果某个QoS Flow的速率远超其配置带宽则说明业务被错误映射到了高优先级通道。7.3 常见转发问题与特征对照问题现象抓包特征大概率原因视频卡顿下行掉速N3口下行包乱序多TCP重传明显UPF侧按序递交缓冲未开启或N9转发路径绕远语音断续通话质量差语音QFI的包在N3上被标记成普通数据QFISDAP映射表配置错误QoS Flow映射到错误DRB业务时断时续间隔性全断某隧道在一段时间内无任何GTP-U业务包TEID回收异常或会话上下文被删除边缘内部快、外网不通UPF N6口到互联网方向的包有去无回ULCL分流规则过宽外网流量被引到本地出口切换掉线但信号正常切换前后N3隧道出口IP变化且无End Marker间接转发路径配置缺失或UPF侧路径更新失败这套对照表只解决“定位方向”的问题具体原因还是要结合控制面信令确认。但有了抓包特征通常能把问题从“整个网络都慢”缩小到“某一段转发路径异常”。最终想提醒一点5G转发模型说到底是“标签 隧道 策略”的组合。标签是QFI隧道是GTP-U和TEID策略是SMF下发给UPF的转发规则。任何一个循环变得复杂时回到这三件事之上基本不会迷路。这一篇先把用户面转发模型讲透了下一篇我打算写N4接口上SMF和UPF之间的PFCP交互以及会话建立时转发规则是怎么一步步下发到UPF的。
阅读完成 · 觉得有帮助？
