简介关于5G NR下行数据传输流程的图形化资料以图文配合方式拆解从应用到物理层的完整封装过程适合5G NR入门学习者、通信工程学生以及网优/协议栈从业人员作为复习材料。内容从CU-DU高层拆分架构讲起说明SDAP/PDCP与RLC/MAC/物理层的承载位置以HTTP GET请求为线索依次梳理TCP头部20字节中的端口、序列号、确认号、窗口、校验和等字段以及IPv4头部中源/目的地址、版本、长度、DSCP、ECN、协议号等要点最后串联出应用层→TCP→IP→链路层→物理层的下行数据流向。压缩包内共1个PDF文件大小约874KB图形配合文字讲解便于离线阅读。已有270人学习下载适合快速建立5G下行传输整体流程视图的读者。网页慢别只盯着无线侧。这个信号在5G NR里要先穿过TCP、IP、GTP-U、SDAP、PDCP五层处理每一层都往包上附加一段头信息最后才能变成空口信号。最反直觉的地方在于数据不是被“传输”过去的而是被逐层套壳、再逐层拆壳。你在浏览器里敲下回车的那一刻一个HTTP GET请求从服务器回传时要经历UPF的包分类、两级不同粒度的GTP-U隧道、QoS Flow到DRB的映射以及PDCP的加密与完整性校验。搞懂这条下行链路的底层逻辑你才能回答为什么SDF模板漏配会导致网页打不开、为什么F1接口的隧道粒度从会话级变成了承载级、为什么空口抓包永远看不到HTTP明文。2. 从HTTP到UPF用户面数据进核心网前的逐层封装2.1 TCP头20字节端口、序列号、窗口一个传输层头管了三件事浏览器发出HTTP GET后应用服务器开始回传网页。但网页数据不是裸着走的每过一个协议层都要加一个头。TCP头是最先加上的标准20字节。资料里的图213把它拆成了一组字段源端口、目的端口、序列号、确认号、数据偏移、窗口大小、校验和、紧急指针。我一般会这么理解这张图TCP头是一个“传输层驾驶舱”。源端口和目的端口回答“这个包要给哪个应用”HTTP默认就走80端口序列号回答“这段数据排在哪个位置”接收端靠它做乱序重排和丢包检测确认号是“我已经收到哪一段”的回执窗口大小是“你还能继续发多少”本质是端到端流控的闸门校验和把头部和载荷一起做误码检查。这些机制在5G链路里依然关键因为空口天然有乱序和高误码TCP的序列号与确认号是应用层感知不到问题的最底层防线。TCP头字段典型长度职责源端口 / 目的端口各2字节标识高层应用HTTP默认80序列号4字节接收端重排序、丢包检测确认号4字节确认已经收到的字节位置数据偏移4位指示TCP头长度窗口大小2字节流控声明发送方愿意接收的字节数校验和2字节头部与载荷的位错误检测紧急指针2字节标记需要高优先级处理的数据注意这个表格里的一个细节数据偏移只有4位所以TCP头长度必须是4字节的整数倍窗口大小只有16位收发双方在高速链路上往往需要开启窗口缩放选项才能把吞吐提上去。这些在5G承载大流量业务时都会成为实际调参点不是纯粹的理论字段。2.2 IP头20字节DSCP和ECN是传输网优先级的早期入口TCP段封装完交给IP层。IPv4的标准IP头也是20字节。核心字段是版本IPv4填4、头长、总长度、DSCP、ECN、协议号、源IP、目的IP。路由器只看目的IP做逐跳转发不关心上层是TCP还是UDP协议号字段用来告知接收方载荷类型TCP的协议号就是6。值得展开的是DSCP和ECN这两个“小字段”。DSCP可以标记这个IP包在路由器排队时的优先级ECN则用于在队列开始拥塞时给对端一个显式信号。它们的共同点是作用于IP网络传输的中间路径属于“转发优先级”而不是“无线优先级”。一个常见误解是“在IP层改了DSCP就能提升5G空口体验”实际上DSCP只影响IP包在承载网路由器里的排队行为一旦包到达gNodeB并被映射到QoS Flow空口侧的调度优先级完全由QoS Flow的5QI参数决定和IP头的DSCP不再直接相关。从端到端的视角看IP头解决的是“这个包怎么从一个IP地址到达另一个IP地址”的问题。到了UPF这一跳这个IP包就进入5G核心网的边界接下来要发生的不再是路由而是分类与隧道封装。2.3 UPF的SDF模板匹配五元组决定PDU Session和QoS FlowIP包穿过传输网到达UPFUser Plane Function用户面功能实体。UPF是用户数据进入5G核心网的第一道门它做的第一件事不是转发而是包检测。UPF从IP包里提取头字段与一组叫SDF模板的规则做比对决定这个包应该进哪条PDU Session、哪个QoS Flow。SDF模板Service Data Flow Template来自哪里来自SMF会话管理功能在PDU Session建立时下发给UPF的那份规则。资料里给了一个最典型的例子用{源IPX、目的IPY、源端口J、目的端口K}的唯一组合把一组TCP/IP包映射到特定的PDU Session和QoS Flow。实际产品里的模板通常会在这个基础上扩展加入协议号甚至DPI识别的应用特征但核心思想不变UPF是分类器不只是转发器。这里有一个必须要分清的层次PDU Session和QoS Flow是两个不同粒度的概念。PDU Session是UE与数据网络之间的“连接容器”一个UE可以建立多条PDU Session对应不同的数据网络QoS Flow是容器内部的“服务等级通道”一条PDU Session里可以有好几个QoS Flow分别承载网页浏览、视频直播、语音通话这类时延和可靠性要求截然不同的业务。如果没有QoS Flow这个概念同一会话里的所有流量只能按最差等级统一处理5G强调的差异化服务就没有承载载体了。3. 两级GTP-U隧道为什么NG-U按PDU Session建隧道F1却按DRB建3.1 TEID只到PDU SessionGTP-U“会话级”标识的设计边界UPF完成分类后把IP包封装进GTP-U隧道。GTP-U隧道头在带扩展头时能达到20字节量级其中最核心的字段是TEIDTunnel Endpoint Identifier隧道端点标识。NG-U接口上GTP-U隧道是按PDU Session建立的所以TEID只能回答“这个包属于哪条PDU Session”回答不了“它属于哪个QoS Flow”。资料里这句话说得很直白隧道按PDU Session建TEID标识PDU Session但不标识QoS Flow。为什么隧道粒度不细化到QoS Flow一个PDU Session里可以有多个QoS Flow如果每个QoS Flow各建一条隧道TEID的分配、维护、释放复杂度会成倍上涨。更关键的是QoS Flow最终映射到哪个DRB是gNodeB根据无线资源状况决定的决策UPF不应该也不需要知道。核心网和无线网在这个环节刻意解耦——隧道只负责把数据送到gNodeB无线侧的承载映射留给gNodeB去做。GTP-U的头部结构里除了TEID还有消息类型、长度、序列号、扩展头类型等字段。这些字段的存在让GTP-U不仅能承载用户数据还能承载路径管理、回显请求这类信令消息。实际抓包时你会看到GTP-U头后面经常跟着一串“扩展头”链Next Extension Header Type逐个指向下一个这种设计保证了基础头结构稳定不变新功能通过扩展头逐代追加老节点遇到不认识的新扩展头类型可以跳过不处理向后兼容性就这么保住了。3.2 PDU Session ContainerQFI、PPI、RQI三个字段管三件事既然TEID识别不了QoS Flow协议栈的解决办法是在GTP-U扩展头里加一个PDU Session Container它的内容在TS 38.415里定义。这个容器不大但每个字段都有明确分工。PDU Type取值为0表示这是一个下行包接收方靠它区分方向QFIQoS Flow Identifier是真正的流标识6位能区分一条PDU Session里的多个QoS FlowPPP/PPI这对字段处理的是“UE睡着了怎么办”的问题——当UE处于RRC Inactive状态上下文还在但连接已挂起下行包到达gNodeB时需要触发寻呼把UE唤醒PPI允许UPF给gNodeB一个提示这个包来自高优先级应用请用更高优先级的寻呼策略让用户更快被叫醒RQIReflective QoS Indicator则标记这个QoS Flow是否采用反射QoS它会影响后面SDAP层是否要带头。PDU Session Container字段含义典型场景PDU Type 0下行方向标识gNodeB侧判断数据方向QFI6位QoS Flow标识区分流、后续映射DRBPPP / PPI是否携带寻呼策略指示UE处于RRC Inactive时影响寻呼优先级RQI反射QoS开关决定SDAP层是否加头、UE是否学习映射另外要注意多UPF链式部署的情况。5G核心网可能串联多个UPF边缘UPF做本地分流中心UPF兜底第一个UPF可能还要用GTP-U隧道把数据转给另一个UPF再由后者转给gNodeB。每一跳GTP-U都是独立隧道有独立的TEID和外层IP地址。一次下行传输在核心网里经过两次GTP-U封装与解封装这也是排查时容易看晕的地方。3.3 双重IP头隧道封装后的报文长什么样GTP-U隧道跑在UDP/IP之上。UDP头只有8字节目的端口固定2152这是GTP-U在IANA注册的端口号。加上这层之后报文的外层结构就完整了整段封装从上到下是这样| 应用数据(HTTP) | TCP | 内层IP | GTP-U头PDU Session Container | UDP | 外层IP | 传输网L2帧 |这里出现了两个IP头。内层IP是UE与应用服务器之间的原始IP头源和目的地址都是用户业务的真实地址外层IP是UPF到gNodeB或UPF到UPF之间传输网的IP头作用是让包在承载网里被路由到正确的基站。两层IP职责完全不同内层IP由用户业务决定外层IP由隧道端点决定。注意外层IP的DSCP由UPF设置运营商可以用它给不同优先级隧道在传输网里排队时的待遇内层IP的DSCP是用户自己设置的传输网一般不会理会它。所以“改DSCP提升5G体验”这种说法先要分清楚改的是哪一层的DSCP。数据到达gNodeB的CU后传输网L2、外层IP、UDP、GTP-U头连同PDU Session Container一起被剥掉。此时QFI已经被解析出来内层IP包带着QoS Flow身份进入CU协议栈。隧道这层使命完成接下来是从IP包到无线承载的转换。4. SDAP、PDCP与F1转发IP包如何变成无线承载4.1 SDAP把QoS Flow放进DRB以及Reflective QoS的反向学习隧道在CU侧终止后内层IP包交给SDAPService Data Adaptation Protocol规范在TS 37.324。SDAP的核心职责只有一个把QoS Flow映射到合适的DRBData Radio Bearer数据无线承载。DRB是空口侧真正承载用户数据的无线通道它有自己的RLC配置、MAC逻辑信道优先级、HARQ参数。一个DRB可以承接多个QoS Flow也可以一个QoS Flow独占一个DRB决策权完全在gNodeB。SDAP头很有意思默认情况下SDAP不加任何头直接把内层IP包透传给PDCP。只有一种情况会加头——开启了Reflective QoS。加了头之后SDAP头里携带QoS Flow信息UE从空口收到这个包就能反推出“这个QoS Flow是从这个DRB下来的”于是UE发上行数据时就知道这个QoS Flow的包应该映射到哪个DRB不需要网络侧再用信令显式下发一张映射表。这种“反向学习”机制的巧妙之处在于省信令但也有限制UE必须真的收到过下行包才能学到映射。如果一个QoS Flow长时间没有下行流量UE根本学不到映射规则。所以Reflective QoS在实际网络里通常是作为增强特性使用核心网会在需要时给SDAP开RQI而不是默认全局开启。SDAP头“时有时无”的原因就在这。4.2 PDCP先算MAC-I再加密校验与保密的顺序不能反SDAP把包按DRB归类后交给PDCP。PDCP是无线协议栈里安全性的锚点做三件事完整性保护、加密、加序列号。完整性保护是计算一个认证码MAC-I附加到包上。接收端用相同密钥和参数重算一遍比对MAC-I一致才认为这个包是真实的、没被篡改过。加密则是对PDCP PDU的载荷做加扰让没有密钥的对端读不懂内容。MAC-I本身以明文形式放在头部信息里不被加密。这里有一个严格顺序先算MAC-I再加密载荷两者顺序不能反。为什么顺序这么敏感如果先加密再算MAC-I接收端就必须先解密才能验证完整性而解密的正确性依赖密钥、序列号等多个状态。一旦验证失败你根本无法区分是密钥配置错误、数据在空口被篡改还是传输误码导致解密结果错乱排查时等于走进死胡同。先算MAC-I再加密接收端可以先用明文算出的MAC-I做校验校验通过才解密。安全失败与解密失败被明确切成两个可独立判断的步骤这是无线协议栈里“先校验后解密”思想的典型落地。PDCP还负责加大序列号。空口链路在载波聚合、双连接场景下可能乱序到达PDCP SN就是接收端重排序的依据。SN长度可配置常见12位或18位。SN越短重排序窗口越小能容忍的乱序范围越窄但头开销小SN越长容忍乱序能力越强代价是每包多几个比特的头开销。这是一个典型的无线配置权衡点也直接影响大流量业务的吞吐表现。4.3 从CU到DUF1接口的隧道粒度切换与NR RAN ContainerPDCP处理完后CU要把PDCP PDU转发给DU。这条路径是F1接口仍然用GTP-U隧道但隧道粒度变了NG-U按PDU Session建隧道F1按DRB建隧道。为什么原因在于SDAP已经完成了QoS Flow到DRB的映射数据在F1接口上已经按DRB聚合好了。隧道跟着DRB走DU收到包时不需要再做DRB查询可以直接把数据交给对应DRB的RLC实体如果F1还按PDU Session建隧道DU侧就要额外做一次DRB映射查询多一跳处理时延。隧道粒度从会话级缩到承载级本质是CU把映射做完之后用隧道粒度把映射结果固化下来。F1隧道的扩展头也换了从PDU Session Container换成NR RAN Container内容由TS 38.425的NR用户面协议定义。这个容器关心的事情和核心网侧完全不同它承载的是CU与DU之间的传输状态反馈比如DU侧RLC的缓存状态、丢包情况。CU侧拿到这些反馈可以做PDCP层的丢包重传控制、调整向DU下发的流量速率。简单说PDU Session Container回答“这个业务是谁、什么优先级”NR RAN Container回答“无线侧把数据传到了什么程度”。DU侧解出NR RAN Container后接手的就是RLC、MAC、PHY这三层。常见的实现思路是RLC根据MAC调度的传输块大小把PDCP PDU切成合适的分段MAC调度器按信道质量和QoS参数分配资源块与调制阶数决定每个时隙塞多少数据同时跑HARQ快速重传PHY把比特流做信道编码、调制映射到对应的时频资源上发射。到这里一个HTTP GET触发的一次下行数据旅程才算完整走完。5. 排查指南下行链路里最容易踩的四个坑做端到端定位时90%的翻车都集中在“层”和“标识”上。这一章按现象到原因的顺序记录四个高频踩坑点。5.1 抓包数错层内外两层IP该看哪个现象在N3接口抓GTP-U包抓到两个IP头。拿内层IP去找UE的真实地址怎么都对不上以为是NAT配置出错。原因GTP-U隧道封装后外层IP是UPF到gNodeB之间传输网的隧道地址内层IP才是用户报文的原始IP头。两个IP头的职责完全不同混在一起看必然对不上。解决先按UDP端口2152过滤出GTP-U流量再展开内层IP看用户业务。判断隧道状态和路由时看外层IP核对用户寻址时看内层IP。改DSCP前同样先确认要改的是哪一层内外层属性完全不一样。# 在N3接口只抓GTP-U隧道流量并保存 tcpdump -i any udp port 2152 -w ng_u_traffic.pcap # 读取时展开到IP层细节 tcpdump -r ng_u_traffic.pcap -nn -v | head -20参数说明port 2152是GTP-U的注册端口用来过滤出核心网隧道流量-w保存pcap文件-r读pcap-nn不做域名和端口反解-v显示更多报头细节。如果N3实际跑在VXLAN或其他叠加网上记得把-i any换成具体物理接口先剥外层隧道再过滤。5.2 拿TEID当QoS Flow标识QFI藏在哪里现象想确认某个QoS Flow的数据有没有走对的DRB结果在GTP-U头里只看到TEID找不到QFI误判为丢包。原因TEID只标识PDU Session这是NG-U隧道按会话级建立的直接结果。QFI藏在GTP-U扩展头里的PDU Session Container中而且这个容器不是每次必现的——当PDU Session只有一个默认QoS Flow时许多实现会省略容器字段。解决先确认PDU Session实际建了几个QoS Flow。多个流时解析GTP-U扩展头找到PDU Session Container读QFI字段只有一个流时记住唯一条QoS Flow走默认映射不用在报头里找不存在的字段。核对SDAP层DRB映射时也以QFI为准不要用TEID代替。5.3 SDAP头时有时无不是设备软件抽风现象同一个QoS Flow的下行包抓包看到有时带SDAP头有时不带第一时间怀疑抓包工具或基站软件有bug。原因SDAP默认不带头只有启用了Reflective QoS的QoS Flow才在下行方向加SDAP头。同一个PDU Session里不同QoS Flow配置各异所以抓包结果看起来忽有忽无实际是不同流的配置差异。解决查该QoS Flow的RQI标志位它由核心网在QoS Flow建立时下发gNodeB据此决定是否加SDAP头。默认承载、尽力而为业务通常不带SDAP头开启了反射QoS的特定流才会带。逐流核对该标志位SDAP头的出现规律就能完全对上。5.4 空口抓包看不到HTTP内容不是没抓到是PDCP加密了现象在DU侧无线协议栈抓包想直接看HTTP响应内容结果净荷全是密文以为采集设备或探针坏了。原因PDCP加密发生在CU侧加密后的PDCP PDU从F1接口传给DUDU的RLC、MAC、PHY全程拿到的都是密文。空口抓包看到的是加密后的比特流理论上不可能还原HTTP正文。解决验证内容正确性的场景去CU的NG-U入口或者PDCP输入侧抓包那里还是明文验证无线传输质量的场景在空口看PDCP序列号连续性和丢包率不要试图解出内容。仿真环境可以在PDCP配置里关加密来观察明文真实网络里关不了只能靠镜像或取密钥解密别指望抓包直接看到应用层。6. 设计取舍CU-DU分离到底换来了什么CU-DU higher layer split让同一份下行数据走了两段不同粒度的隧道NG-U按PDU Session建F1按DRB建。为什么不把整套协议栈放进一个实体一步到位直接发空口答案不是实体装不下而是这套协议栈里不同层的工作性质天然分属两种部署位置。SDAP和PDCP适合集中。PDCP是加密与完整性校验的锚点所有安全状态都和它绑定SDAP的QoS Flow到DRB映射需要跨小区、跨DU保持一致。这两层放到CU多个DU共享同一个CU时UE在DU之间移动无需迁移安全上下文映射决策集中做一次每个DU不用各自维护一套映射模板。RLC、MAC、PHY必须靠近射频。MAC调度器依赖每个时隙的信道状态反馈HARQ重传的往返时间要压缩到毫秒级PHY更是纯实时硬件。这些层放到DU物理位置贴近天线前传时延才可控。CU可以云化部署到中心机房DU必须靠近站址——这不是为了省光纤是协议栈下半段的实时性本质决定的。代价也很实在F1接口被迫引入一套额外的GTP-U隧道和NR RAN Container同一份用户数据在CU和DU之间多一次封装与解封装端到端路径上多一个有状态的转发节点排障时要同时核对NG-U和F1两套隧道状态知识负担明显加重。第一次完整走这条下行链路的抓包流程时我最直观的感受是架构取舍不会只停留在设计文档里它会直接写进每一层封装的字段选择中。从那以后我每次遇到下行速率问题都会强制自己先从UPF的SDF模板开始沿SDF→QFI→DRB→PDCP SN这条路径逐级排查而不是一开始就怀疑无线弱场。希望帮到你。本文还有配套的精品资源点击获取