简介本资源是一份面向5G通信初学者与网络协议学习者的图形化教学材料聚焦5G NR下行数据传输全流程解析帮助理解用户面协议栈各层协同机制及实际数据封装过程。内容以清晰图示含图212用户面协议栈、图213 TCP头、图214 IPv4头为核心逐层拆解从HTTP应用请求出发经TCP、IP、链路层至物理层的完整下行路径并结合CU-DU架构说明PDCP/SDAP与RLC/MAC/PHY的功能划分兼具理论严谨性与形象可读性。资源为单个PDF文件大小874KB内容精炼、图文并茂适合作为协议栈入门补充读物或课堂辅助教具。目前已有270人学习下载读者可直接获取完整的分层流程图示、关键字段功能注释如序列号、窗口大小、DSCP、ECN等、典型端口与协议编号说明以及gNodeB内部功能单元划分示意有效降低5G协议抽象理解门槛。1. 这不是一张PPT是5G下行数据流的“解剖动图”从HTTP GET到UE天线每层封装、每个隧道、每个TEID都可追溯你有没有试过对着3GPP协议栈文档发呆——PDCP、SDAP、GTP-U、F1、NG-U……名词堆成山但就是串不起来“用户点一下网页数据到底怎么飞进手机”的完整链路这份《5G NR in BULLETS》第212–220图系不是教科书插图而是一套可逐帧拆解的下行数据流动态逻辑图谱。它把一次HTTP GET响应的完整旅程从应用层TCP/IP包出发经UPF映射QoS Flow、打GTP-U隧道穿核心网、在CU/DU间按DRB分发、经PDCP加解密、RLC分段重传、MAC调度、物理层编码调制最终落进UE接收机——全部用分层堆叠箭头流向头部字段标注的方式固化下来。它不讲“应该怎样”只画“实际怎样”比如为什么GTP-U在NG-U接口带PDU Session Container而在F1接口换成了NR RAN Container为什么外层IP头DSCP能被UPF设置而内层IP头DSCP由服务器决定为什么同一个PDU Session下多个QoS Flow共用一个TEID却靠SDAP头区分。适合正在调试gNodeB用户面转发、分析UPF GTP-U丢包、或给新人讲清CU-DU分工的一线工程师。如果你手头正跑着真实5G测试环境这张图就是你抓包时Wireshark里每一层展开的对照表。2. 从HTTP GET到GTP-U隧道下行数据包的七层“穿衣”过程与关键字段实录2.1 应用层发起HTTP GET触发的TCP/IP包生成逻辑用户浏览器发出GET /index.html HTTP/1.1请求后服务端响应内容HTMLCSSJS被切分为多个TCP段。每个段由TCP层添加标准20字节头部图213关键字段含义如下# TCP头部结构Wireshark导出字段名与协议栈对应关系 Source Port: 80 # 服务器HTTP端口固定 Destination Port: 54321 # UE侧随机端口由UE TCP栈分配 Sequence Number: 0x1a2b3c4d # 初始序列号用于乱序重排与丢包检测 Acknowledgement Number: 0x98765432 # UE上一个SYN-ACK的seq1确认已建立连接 Data Offset: 5 (20 bytes) # 指明TCP头长度无选项时为5*420字节 Window Size: 65535 # UE通告的接收窗口控制发送速率 Checksum: 0x5a5a # 校验TCP头数据伪IP头防传输错 Urgent Pointer: 0 # 本例未启用紧急数据 Flags: 0x18 (ACK, PSH) # PSH标志置位要求立即交付给应用层提示PSH标志是下行数据流的关键信号——它告诉UE TCP栈“别缓存立刻交给浏览器渲染”这直接影响网页首屏时间FCP。若在gNodeB抓包发现大量PSH未及时送达UE需检查PDCP重排序缓冲区或RLC AM模式下的重传超时RTO设置。2.2 网络层封装IPv4头注入与DSCP优先级传递链TCP段被送入IP层添加20字节IPv4头图214。此处出现第一个“双IP头”雏形内层IP头由服务器生成外层IP头由UPF添加。# 内层IPv4头原始业务流由Web服务器生成 Version: 4 # IPv4协议 Header Length: 5 (20 bytes) Total Length: 1500 # IP包总长含TCP头数据 Identification: 0xabc1 # 分片标识同一TCP流分片共享此ID Time to Live: 64 # Linux默认TTL每经一跳减1 Protocol: 6 # 协议号6 TCPRFC 790 Header Checksum: 0x3f4e # 仅校验IP头不包含数据 Source IP Address: 203.0.113.5 # Web服务器公网IP Destination IP Address: 192.0.2.100 # UE在5GC分配的IPv4地址由SMF下发 # 外层IPv4头GTP-U隧道封装由UPF生成 Source IP Address: 10.10.20.1 # UPF本地地址核心网内部路由 Destination IP Address: 10.10.30.5 # gNodeB CU NG-U接口地址 DSCP: 0x28 (CS4) # UPF根据QoS Flow的5QI映射如5QI8→DSCPCS4 ECN: 0x01 (ECT(1)) # 显式拥塞通知由UPF根据队列水位设置注意DSCP字段是QoS策略落地的唯一载体。若UE侧测得网页加载延迟高但gNodeB空口调度正常必须回溯检查UPF是否将5QI9视频流错误映射为DSCP0BE导致核心网路由器将其与背景流量同等对待。3GPP TS 23.501 Table 5.7.2-1定义了5QI到DSCP的强制映射关系不可自定义。2.3 核心网隧道化GTP-U头结构与PDU Session Container字段解析UPF将IP包封装进GTP-U隧道图215这是5G用户面区别于4G EPC的关键——每个PDU Session独占一个GTP-U隧道TEID即Session ID。# GTP-U头部3GPP TS 29.281定义固定8字节基础头可选扩展 Version: 1 # GTPv1-U协议 Protocol Type: 1 # GTP非GTP Extension Header Flag: 1 # 启用扩展头携带PDU Session Container Sequence Number Flag: 1 # 启用序列号用于乱序检测 N-PDU Number Flag: 1 # 启用N-PDU编号用于AM模式重传 Message Type: 0xff (GPDU) # G-PDU消息类型 Length: 0x05d8 # 后续总长度含扩展头IP包 Tunnel Endpoint Identifier (TEID): 0x12345678 # 全局唯一由SMF分配并通知UPF/gNodeB Sequence Number: 0x0000a1b2 # 本隧道内递增gNodeB用其检测丢包 N-PDU Number: 0x05 # 本PDU在DRB上的编号F1接口才用 # PDU Session Container扩展头3GPP TS 38.415定义紧随基础头后 PDU Type: 0x00 # 0Downlink, 1Uplink下行方向标识 QoS Flow Identifier (QFI): 0x08 # 5QI8对应的QFI值1-64范围 Paging Policy Indicator (PPI): 0x00 # 0不触发寻呼1触发RRC INACTIVE态必需 Reflective QoS Indicator (RQI): 0x01 # 1启用反射QoSUE据此自动配置上行QoS关键逻辑TEID只标识PDU Session不区分QoS Flow。真正承载QoS语义的是QFI字段。这意味着——即使同一PDU Session内存在语音5QI5和信令5QI7两个QoS Flow它们共享TEID但QFI不同gNodeB CU收到后必须查QFI表才能将数据分发到对应DRB。若CU侧QFI映射表未同步如SMF未推送最新QoS规则所有下行包将被丢弃且无告警。3. CU-DU协同分发SDAP/PDCP处理与F1接口GTP-U隧道切换机制3.1 CU侧SDAP层QoS Flow到DRB的映射决策点gNodeB CU收到GTP-U包后先解析PDU Session Container中的QFI再查本地QoS Flow-to-DRB映射表由RRC重配置消息下发。SDAP层有两种工作模式无SDAP头模式CU直接将PDCP SDU按QFI映射到DRB不添加SDAP头。适用于QoS Flow与DRB 1:1绑定场景如eMBB。带SDAP头模式CU添加1字节SDAP头图219其中Bit 0-5为QFIBit 6-7保留。此模式启用Reflective QoS——UE收到下行包后解析SDAP头QFI自动为上行同QFI流量申请相同QoS参数无需SMF再次介入。# SDAP头结构RFC 38.324定义 # Byte 0: # Bit 7-2: QFI (0-63) # Bit 1: R (Reflective QoS indicator, 1enabled) # Bit 0: RDI (RDI flag, 1reporting required) sdap_header bytes([ (qfi 0x3f) 2 | # QFI左移2位填入Bit7-2 (1 if reflective_qos_enabled else 0) 1 | # Bit1R 0 # Bit0RDI0本例不启用上报 ])血泪经验某次外场测试中UE频繁触发QoS Flow修改失败Cause #32抓包发现CU侧SDAP头R位为0。根因是RRC重配置消息中reflectiveQosEnabled字段未正确置位。解决方案在CU配置文件中强制开启sdap.reflective_qostrue并验证RRC消息中sdap-ConfigIE是否携带reflectiveQos参数。3.2 PDCP层安全处理完整性保护与加密的执行边界PDCP层对SDAP PDU或直连IP包执行两阶段处理完整性保护用KgNB_int密钥计算MAC-I32bit附加在PDCP头后加密用KgNB_enc密钥对PDCP头MAC-ISDU进行流加密EEA1/EEA2/EEA3。# PDCP头结构SRB用1字节DRB用2字节 # DRB 2字节头示例图219隐含 # Bit 15-12: DC (Data/Control, 0data) # Bit 11-8: ROHC头压缩指示本例ROHCoff设0 # Bit 7-0: COUNT (12bit SN 4bit HFN本例SN0x123, HFN0x04 → 0x1234) PDCP_Header b\x12\x34 # 2字节SN0x123, HFN0x04 MAC_I b\x5a\x6b\x7c\x8d # 4字节完整性校验码 Encrypted_Payload encrypt(kgNB_enc, PDCP_Header MAC_I sdap_payload)玄学排查点若UE上报securityModeFailure但KgNB密钥已通过NAS信令正确分发大概率是CU与UE的COUNT值不同步。常见原因CU侧PDCP SN重置逻辑异常如RRC重建后未清零SN或UE侧HFN更新时机错误应在每个RRC重建完成时1。验证方法在CU和UE侧同时抓取PDCP头COUNT字段比对是否严格递增且初值一致。3.3 F1接口隧道切换从“per PDU Session”到“per DRB”的GTP-U重构CU将PDCP PDU转发至DU时GTP-U隧道发生本质变化图220NG-U接口GTP-U隧道按PDU Session建立TEIDSession ID扩展头为PDU Session ContainerF1接口GTP-U隧道按DRB建立TEIDDRB ID扩展头换为NR RAN Container。# F1接口GTP-U头关键差异对比图215与图220 # 基础头不变但扩展头内容替换为 # NR RAN Container3GPP TS 38.425定义 # Bit 0-5: DRB ID (1-32) # Bit 6-7: Reserved # Next Extension Header Type: 0x00 (no further extension) # Extension Header Length: 0x01 (1 byte) nr_ran_container bytes([ (drb_id 0x3f) # DRB ID填入低6位 ])翻车现场某实验室部署中CU向DU发送的F1 GTP-U包被DU静默丢弃。Wireshark显示GTP-U头Message Type0xffGPDU正确但DU日志报invalid NR RAN Container length。定位发现CU侧NR RAN Container长度字段写为0x02误将1字节容器当2字节而DU严格按TS 38.425要求校验长度0x01。修复CU GTP-U封装模块中extension_header_length字段硬编码为0x01禁止动态计算。4. 下行数据落地MAC调度、物理层编码与UE侧接收链路验证4.1 DU侧MAC层逻辑信道映射与TB构造规则DU收到F1 GTP-U包后剥离GTP-U头提取PDCP PDU送入MAC层。MAC层执行逻辑信道映射根据DRB ID查表将PDCP PDU映射到对应逻辑信道如DRB1→LCID3映射到DL-SCHTBTransport Block构造将多个PDCP PDU或单个大PDU按TTI1ms打包为TB添加MAC头含LCID、Length字段HARQ进程调度为每个TB分配HARQ进程ID0-15记录在PHICH/PDCCH中。# MAC子头结构针对一个PDCP PDU # LCID: 0x03 (DRB1) # Length: 0x05d8 (1500字节与GTP-U内层IP包长一致) mac_subheader b\x03\x05\xd8 # TB mac_subheader pdcp_pdu padding (to fit TBS)避坑MAC层丢包的三大隐形杀手现象1UE侧TCP吞吐量骤降50%但空口RSRP/SINR正常。原因MAC层TB大小超过当前TBSTransport Block Size。TBS由MCS调制编码方案和RB数资源块数查3GPP TS 38.214 Table 5.1.3.1-1确定。若CU误将MCS从28256QAM降为10QPSK但RB数未增TBS从27000B暴跌至3000B导致PDCP PDU被截断。解决检查CU侧调度器输出的MCS/RB配置用lte_tbs_calculator.py工具验证TBS是否≥PDCP PDU长度。现象2Wireshark在DU侧看到MAC PDU但UE侧无对应PDCP包。原因MAC头LCID错误。例如DRB2应配LCID0x04但CU误配0x05对应SRB2DU将包送入控制面丢弃。解决比对CU配置的DRB-LCID映射表与DU侧rrc.drb_config参数是否一致。现象3UE上报大量harq_feedback_nack但基站未重传。原因HARQ进程ID冲突。CU为不同TTI的TB重复分配同一HARQ IDDU无法区分新传与重传。解决强制CU按TTI模16分配HARQ IDID tti_index % 16确保16个进程轮转使用。4.2 物理层编码从TB到OFDM符号的全流程转换MAC层输出的TB送入PHY层经历CRC添加24bit CRC多项式0x1021附于TB末尾码块分割若TB 8448bit按3GPP TS 38.212 Section 5.1.2分割为多个码块CB每CB加24bit CRCLDPC编码每个CB经LDPC基图BG1/BG2编码码率1/3或2/3速率匹配按目标码率截取比特填入PRBPhysical Resource Block加扰与调制用小区ID加扰QPSK/16QAM/64QAM/256QAM调制层映射与预编码多天线场景下映射到各层经PMI预编码RE映射将OFDM符号填入时频资源格Resource Grid。# 关键参数验证脚本Python伪代码需接入PHY SDK def validate_phy_encoding(tb_bytes): crc24 calculate_crc24(tb_bytes) # 3GPP TS 38.212 Annex B.1.1 tb_with_crc tb_bytes crc24 if len(tb_with_crc) 8448 * 8: # 8448bit 8448*867584bits cb_list code_block_segment(tb_with_crc) # 分割CB-CRC ldpc_encoded [ldpc_encode(cb, bgBG1, rate1/3) for cb in cb_list] else: ldpc_encoded [ldpc_encode(tb_with_crc, bgBG1, rate1/3)] # 验证ldpc_encoded总长是否匹配调度器下发的TBS assert sum(len(x) for x in ldpc_encoded) scheduled_tbs_bits注意LDPC编码是计算密集型操作。某次实测中DU PHY模块在256QAM100MHz带宽下单TTI编码耗时超200μs超时阈值150μs导致调度器丢弃该TTI。解决方案启用LDPC硬件加速引擎并验证phy.ldpc_hw_acceleratorenabled配置生效。4.3 UE侧接收链路从天线到应用层的全栈解码验证UE天线接收OFDM符号后反向执行PHY→MAC→PDCP→SDAP→IP→TCP流程PHY解调信道估计、FFT、解调、LDPC译码需BER 1e-5MAC解复用解析MAC头LCID提取PDCP PDUPDCP解密用KgNB_enc解密校验MAC-IKgNB_intSDAP解析读取QFI确认QoS Flow归属IP重组按IPv4 Identification字段重组分片TCP重组按Sequence Number排序提交给Socket缓冲区。# UE侧关键日志字段供问题定位 # PHY层rx_rsrp-95, rx_sinr18.2, bler0.002 (合格) # MAC层harq_ackACK, drb_id1, lc_id0x03, pdu_len1500 # PDCP层integrity_checkPASS, cipher_checkPASS, sn0x1234 # SDAP层qfi0x08, reflective_qos_appliedTRUE # IP层ip_id0xabc1, ip_ttl63 (经一跳衰减), ip_proto6 # TCP层tcp_seq0x1a2b3c4d, tcp_flagsACK, tcp_window65535终极验证技巧在UE侧启动tcpdump -i any port 80 -w http_downlink.pcap同时在UPF侧抓GTP-U包。用tshark -r http_downlink.pcap -T fields -e tcp.seq -e tcp.len提取TCP序列号与长度再用tshark -r upf_gtpu.pcap -Y gtpv1.teid0x12345678 -T fields -e gtpv1.length提取GTP-U负载长度。若两者序列号严格连续、长度总和一致则证明下行链路全栈无丢包、无乱序。这是验收5G数据面性能的黄金标准。5. 避坑指南5G下行数据流调试中高频踩坑的5个真实场景与根治方案5.1 现象Wireshark在UPF侧看到GTP-U包gNodeB CU侧无对应包原因UPF与gNodeB CU间的NG-U接口路由不通或防火墙拦截UDP 2152端口。更隐蔽的原因是——UPF生成的外层IP头中Destination IP地址填写错误如填成gNodeB DU地址而非CU地址导致包被路由到错误设备。解决在UPF执行ip route get 10.10.30.5CU NG-U地址确认下一跳为直连网关在CU侧执行tcpdump -i any udp port 2152 -w ng_u_debug.pcap确认是否收包若CU收不到登录UPF检查upf.ng_u_dst_ip配置项确保其值为CU的NG-U接口IP非DU或SCTP地址若CU收到但丢弃在CU内核日志dmesg | grep gtp中查找gtp_rx: invalid TEID确认TEID是否在CU维护的隧道表中ip link show gtp0查看隧道列表。5.2 现象gNodeB CU侧有PDCP包DU侧无对应F1 GTP-U包原因CU与DU间的F1接口GTP-U隧道未建立或CU侧F1隧道配置指向错误DU IP。常见于CU-DU分离部署时CU配置的DU地址是管理面IP而非F1-C用户面IP。解决在CU执行ip link show f1gtp0确认F1 GTP-U隧道状态为UP检查CU配置文件中f1.du_user_plane_ip是否为DU的F1-U接口IP通常与F1-C不同网段在DU侧执行tcpdump -i any udp port 2152 -w f1_debug.pcap确认是否收包若DU收到但日志报invalid nr-ran-container检查CU侧GTP-U封装代码中NR RAN Container长度字段是否恒为0x01见3.3节。5.3 现象UE侧TCP吞吐量极低1Mbps但空口调度正常MCS高、RB多原因PDCP层重排序缓冲区溢出。当CU侧PDCP SN跳跃过大如因重传导致SN0x1000后突然跳到0x2000UE PDCP按SN顺序等待0x1001~0x1fff的包缓冲区填满后丢弃后续包。解决在UE侧读取PDCP统计cat /proc/net/pdcprx关注reordering_buffer_full计数在CU侧检查PDCP SN生成逻辑确保SN严格单调递增禁用随机跳变调大UE侧PDCP重排序缓冲区修改UE内核参数echo 2048 /sys/module/pdcprx/parameters/reorder_buffer_size需root权限终极方案CU启用PDCP状态报告Status Report定期向UE同步已发送最高SNUE据此清理过期缓冲区。5.4 现象UE能上网但视频卡顿Wireshark显示TCP重传率20%原因QoS Flow映射错误。UPF将视频流5QI8错误映射到低优先级DRB如DRB2而DRB2的RLC AM模式重传次数上限maxRetxThreshold设为4次低于视频容忍阈值需≥8次。解决在UPF侧检查SDF模板匹配结果upf show sdf-match-result ue-ip确认视频流匹配的QFI0x08在CU侧检查QFI-to-DRB映射cu show drb-mapping qfi0x08确认映射到DRB1高优先级检查DRB1的RLC配置cu show rlc-config drb1确认maxRetxThreshold8且t-Reassembly35ms视频推荐值若DRB1已配置正确检查CU侧是否启用了RLC UM模式UM模式无重传强制设为AM模式cu set rlc-mode drb1 modeAM。5.5 现象HTTP页面加载完成但部分图片不显示Wireshark显示TCP FIN包后仍有GTP-U包到达原因TCP连接关闭时序问题。服务器发送FIN后UPF仍转发剩余GTP-U包因GTP-U隧道未立即拆除CU继续解密并提交给UE TCP栈但UE已关闭Socket导致包被内核丢弃tcp_drop计数上升。解决在UPF侧启用GTP-U隧道优雅关闭配置upf.gtpu.graceful_shutdown_timeout50005秒在CU侧监听GTP-U隧道拆除消息GTP-C Delete PDP Context Request收到后立即停止向PDCP提交新包在UE侧调整TCP TIME_WAIT时间echo 30 /proc/sys/net/ipv4/tcp_fin_timeout加速Socket回收应用层规避浏览器启用HTTP/2多路复用避免频繁建连断连。6. 进阶验证用三台设备构建闭环测试环境实现从HTTP请求到UE屏幕的端到端时延测绘6.1 测试拓扑与设备角色定义要真正吃透下行数据流必须亲手搭建可测量的闭环环境。我一般用三台设备构建最小可行系统ServerUbuntu 22.04虚拟机运行Nginx http-server提供静态HTML图片资源UPF/CU/DU基于Open5GS srsRAN的轻量级5G核心网与基站CU/DU分离部署UEAndroid 13手机Root Termux tcpdump 自研时延打点App。关键设计Server侧在HTTP响应头中注入X-Start-Timestamp: 1712345678.123456微秒级时间戳UE App在WebView.onPageFinished()回调中读取该头并记录System.nanoTime()作为结束时间。两端时间差即为端到端时延含网络终端处理。6.2 时延分解测量表定位瓶颈在哪个协议层在Server、UPF、CU、DU、UE五点部署时间戳采集汇总为下表。以下载1MB HTML为例理论空口时延10ms测量点时间戳位置典型时延异常阈值定位方法Servertime.time_ns()at HTTP response start0ms基准—无UPFgettimeofday()on GTP-U packet ingress1.2ms5msupf trace gtpu-ingressCUktime_get_ns()after GTP-U decap2.8ms10msperf record -e sched:sched_switch -p $(pidof cu)DUktime_get_ns()after MAC TX queue4.5ms15msdu log levelDEBUGUESystem.nanoTime()at TCP recv()18.3ms50msadb shell cat /proc/net/dev表格解读若CU到DU时延突增至12ms超阈值说明CU侧PDCP处理慢或F1接口拥塞若UE侧时延达65ms但空口RSRP正常大概率是UE TCP栈接收缓冲区小net.ipv4.tcp_rmem需调大echo net.ipv4.tcp_rmem 4096 65536 8388608 /etc/sysctl.conf。6.3 抓包联动分析法Wireshark 5G协议栈日志交叉验证单一抓包无法定位跨层问题必须联动分析。我的标准动作是Server侧tcpdump -i eth0 port 80 -w server.pcapUPF侧tcpdump -i any udp port 2152 and ip[36:4] 0x12345678 -w upf.pcap过滤TEIDCU侧tcpdump -i any udp port 2152 and ip[36:4] 0xabcdef01 -w cu.pcapCU-F1隧道TEIDUE侧tcpdump -i any port 80 -w ue.pcap。然后用Wireshark的File → Merge合并四文件用Statistics → IO Graph绘制各点吞吐量曲线。重点观察Server到UPF若曲线平滑但UPF到CU断崖下跌问题在UPF-GTP-U封装或路由CU到DU若CU侧有包而DU侧无检查F1隧道TEID是否匹配DU到UE若DU侧TX曲线正常但UE侧RX曲线缺失检查UE天线连接或RF校准。6.4 从那以后我每次调试5G下行都强制走一遍“三层时间戳”Server打点、UPF打点、UE打点——这三处时间戳成本几乎为零Server加一行HTTP头UPF改一行日志UE用现成API却能瞬间把模糊的“网络慢”转化为精确的“CU处理耗时超标”。曾经为定位一个200ms的网页加载延迟我们花了三天在Wireshark里翻包最后发现是CU侧PDCP加密模块的AES-NI指令未启用启用后延迟直降180ms。现在我所有5G项目启动时第一件事就是让Server、UPF、UE三方同步NTP并在关键路径插入微秒级打点。这不仅是技术习惯更是对“数据流不可见即不存在”这一铁律的敬畏。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 22:45:25 · 阅读 1.2k 5G下行数据流全链路解析：从HTTP GET到UE天线
简介本资源是一份面向5G通信初学者与网络协议学习者的图形化教学材料聚焦5G NR下行数据传输全流程解析帮助理解用户面协议栈各层协同机制及实际数据封装过程。内容以清晰图示含图212用户面协议栈、图213 TCP头、图214 IPv4头为核心逐层拆解从HTTP应用请求出发经TCP、IP、链路层至物理层的完整下行路径并结合CU-DU架构说明PDCP/SDAP与RLC/MAC/PHY的功能划分兼具理论严谨性与形象可读性。资源为单个PDF文件大小874KB内容精炼、图文并茂适合作为协议栈入门补充读物或课堂辅助教具。目前已有270人学习下载读者可直接获取完整的分层流程图示、关键字段功能注释如序列号、窗口大小、DSCP、ECN等、典型端口与协议编号说明以及gNodeB内部功能单元划分示意有效降低5G协议抽象理解门槛。1. 这不是一张PPT是5G下行数据流的“解剖动图”从HTTP GET到UE天线每层封装、每个隧道、每个TEID都可追溯你有没有试过对着3GPP协议栈文档发呆——PDCP、SDAP、GTP-U、F1、NG-U……名词堆成山但就是串不起来“用户点一下网页数据到底怎么飞进手机”的完整链路这份《5G NR in BULLETS》第212–220图系不是教科书插图而是一套可逐帧拆解的下行数据流动态逻辑图谱。它把一次HTTP GET响应的完整旅程从应用层TCP/IP包出发经UPF映射QoS Flow、打GTP-U隧道穿核心网、在CU/DU间按DRB分发、经PDCP加解密、RLC分段重传、MAC调度、物理层编码调制最终落进UE接收机——全部用分层堆叠箭头流向头部字段标注的方式固化下来。它不讲“应该怎样”只画“实际怎样”比如为什么GTP-U在NG-U接口带PDU Session Container而在F1接口换成了NR RAN Container为什么外层IP头DSCP能被UPF设置而内层IP头DSCP由服务器决定为什么同一个PDU Session下多个QoS Flow共用一个TEID却靠SDAP头区分。适合正在调试gNodeB用户面转发、分析UPF GTP-U丢包、或给新人讲清CU-DU分工的一线工程师。如果你手头正跑着真实5G测试环境这张图就是你抓包时Wireshark里每一层展开的对照表。2. 从HTTP GET到GTP-U隧道下行数据包的七层“穿衣”过程与关键字段实录2.1 应用层发起HTTP GET触发的TCP/IP包生成逻辑用户浏览器发出GET /index.html HTTP/1.1请求后服务端响应内容HTMLCSSJS被切分为多个TCP段。每个段由TCP层添加标准20字节头部图213关键字段含义如下# TCP头部结构Wireshark导出字段名与协议栈对应关系 Source Port: 80 # 服务器HTTP端口固定 Destination Port: 54321 # UE侧随机端口由UE TCP栈分配 Sequence Number: 0x1a2b3c4d # 初始序列号用于乱序重排与丢包检测 Acknowledgement Number: 0x98765432 # UE上一个SYN-ACK的seq1确认已建立连接 Data Offset: 5 (20 bytes) # 指明TCP头长度无选项时为5*420字节 Window Size: 65535 # UE通告的接收窗口控制发送速率 Checksum: 0x5a5a # 校验TCP头数据伪IP头防传输错 Urgent Pointer: 0 # 本例未启用紧急数据 Flags: 0x18 (ACK, PSH) # PSH标志置位要求立即交付给应用层提示PSH标志是下行数据流的关键信号——它告诉UE TCP栈“别缓存立刻交给浏览器渲染”这直接影响网页首屏时间FCP。若在gNodeB抓包发现大量PSH未及时送达UE需检查PDCP重排序缓冲区或RLC AM模式下的重传超时RTO设置。2.2 网络层封装IPv4头注入与DSCP优先级传递链TCP段被送入IP层添加20字节IPv4头图214。此处出现第一个“双IP头”雏形内层IP头由服务器生成外层IP头由UPF添加。# 内层IPv4头原始业务流由Web服务器生成 Version: 4 # IPv4协议 Header Length: 5 (20 bytes) Total Length: 1500 # IP包总长含TCP头数据 Identification: 0xabc1 # 分片标识同一TCP流分片共享此ID Time to Live: 64 # Linux默认TTL每经一跳减1 Protocol: 6 # 协议号6 TCPRFC 790 Header Checksum: 0x3f4e # 仅校验IP头不包含数据 Source IP Address: 203.0.113.5 # Web服务器公网IP Destination IP Address: 192.0.2.100 # UE在5GC分配的IPv4地址由SMF下发 # 外层IPv4头GTP-U隧道封装由UPF生成 Source IP Address: 10.10.20.1 # UPF本地地址核心网内部路由 Destination IP Address: 10.10.30.5 # gNodeB CU NG-U接口地址 DSCP: 0x28 (CS4) # UPF根据QoS Flow的5QI映射如5QI8→DSCPCS4 ECN: 0x01 (ECT(1)) # 显式拥塞通知由UPF根据队列水位设置注意DSCP字段是QoS策略落地的唯一载体。若UE侧测得网页加载延迟高但gNodeB空口调度正常必须回溯检查UPF是否将5QI9视频流错误映射为DSCP0BE导致核心网路由器将其与背景流量同等对待。3GPP TS 23.501 Table 5.7.2-1定义了5QI到DSCP的强制映射关系不可自定义。2.3 核心网隧道化GTP-U头结构与PDU Session Container字段解析UPF将IP包封装进GTP-U隧道图215这是5G用户面区别于4G EPC的关键——每个PDU Session独占一个GTP-U隧道TEID即Session ID。# GTP-U头部3GPP TS 29.281定义固定8字节基础头可选扩展 Version: 1 # GTPv1-U协议 Protocol Type: 1 # GTP非GTP Extension Header Flag: 1 # 启用扩展头携带PDU Session Container Sequence Number Flag: 1 # 启用序列号用于乱序检测 N-PDU Number Flag: 1 # 启用N-PDU编号用于AM模式重传 Message Type: 0xff (GPDU) # G-PDU消息类型 Length: 0x05d8 # 后续总长度含扩展头IP包 Tunnel Endpoint Identifier (TEID): 0x12345678 # 全局唯一由SMF分配并通知UPF/gNodeB Sequence Number: 0x0000a1b2 # 本隧道内递增gNodeB用其检测丢包 N-PDU Number: 0x05 # 本PDU在DRB上的编号F1接口才用 # PDU Session Container扩展头3GPP TS 38.415定义紧随基础头后 PDU Type: 0x00 # 0Downlink, 1Uplink下行方向标识 QoS Flow Identifier (QFI): 0x08 # 5QI8对应的QFI值1-64范围 Paging Policy Indicator (PPI): 0x00 # 0不触发寻呼1触发RRC INACTIVE态必需 Reflective QoS Indicator (RQI): 0x01 # 1启用反射QoSUE据此自动配置上行QoS关键逻辑TEID只标识PDU Session不区分QoS Flow。真正承载QoS语义的是QFI字段。这意味着——即使同一PDU Session内存在语音5QI5和信令5QI7两个QoS Flow它们共享TEID但QFI不同gNodeB CU收到后必须查QFI表才能将数据分发到对应DRB。若CU侧QFI映射表未同步如SMF未推送最新QoS规则所有下行包将被丢弃且无告警。3. CU-DU协同分发SDAP/PDCP处理与F1接口GTP-U隧道切换机制3.1 CU侧SDAP层QoS Flow到DRB的映射决策点gNodeB CU收到GTP-U包后先解析PDU Session Container中的QFI再查本地QoS Flow-to-DRB映射表由RRC重配置消息下发。SDAP层有两种工作模式无SDAP头模式CU直接将PDCP SDU按QFI映射到DRB不添加SDAP头。适用于QoS Flow与DRB 1:1绑定场景如eMBB。带SDAP头模式CU添加1字节SDAP头图219其中Bit 0-5为QFIBit 6-7保留。此模式启用Reflective QoS——UE收到下行包后解析SDAP头QFI自动为上行同QFI流量申请相同QoS参数无需SMF再次介入。# SDAP头结构RFC 38.324定义 # Byte 0: # Bit 7-2: QFI (0-63) # Bit 1: R (Reflective QoS indicator, 1enabled) # Bit 0: RDI (RDI flag, 1reporting required) sdap_header bytes([ (qfi 0x3f) 2 | # QFI左移2位填入Bit7-2 (1 if reflective_qos_enabled else 0) 1 | # Bit1R 0 # Bit0RDI0本例不启用上报 ])血泪经验某次外场测试中UE频繁触发QoS Flow修改失败Cause #32抓包发现CU侧SDAP头R位为0。根因是RRC重配置消息中reflectiveQosEnabled字段未正确置位。解决方案在CU配置文件中强制开启sdap.reflective_qostrue并验证RRC消息中sdap-ConfigIE是否携带reflectiveQos参数。3.2 PDCP层安全处理完整性保护与加密的执行边界PDCP层对SDAP PDU或直连IP包执行两阶段处理完整性保护用KgNB_int密钥计算MAC-I32bit附加在PDCP头后加密用KgNB_enc密钥对PDCP头MAC-ISDU进行流加密EEA1/EEA2/EEA3。# PDCP头结构SRB用1字节DRB用2字节 # DRB 2字节头示例图219隐含 # Bit 15-12: DC (Data/Control, 0data) # Bit 11-8: ROHC头压缩指示本例ROHCoff设0 # Bit 7-0: COUNT (12bit SN 4bit HFN本例SN0x123, HFN0x04 → 0x1234) PDCP_Header b\x12\x34 # 2字节SN0x123, HFN0x04 MAC_I b\x5a\x6b\x7c\x8d # 4字节完整性校验码 Encrypted_Payload encrypt(kgNB_enc, PDCP_Header MAC_I sdap_payload)玄学排查点若UE上报securityModeFailure但KgNB密钥已通过NAS信令正确分发大概率是CU与UE的COUNT值不同步。常见原因CU侧PDCP SN重置逻辑异常如RRC重建后未清零SN或UE侧HFN更新时机错误应在每个RRC重建完成时1。验证方法在CU和UE侧同时抓取PDCP头COUNT字段比对是否严格递增且初值一致。3.3 F1接口隧道切换从“per PDU Session”到“per DRB”的GTP-U重构CU将PDCP PDU转发至DU时GTP-U隧道发生本质变化图220NG-U接口GTP-U隧道按PDU Session建立TEIDSession ID扩展头为PDU Session ContainerF1接口GTP-U隧道按DRB建立TEIDDRB ID扩展头换为NR RAN Container。# F1接口GTP-U头关键差异对比图215与图220 # 基础头不变但扩展头内容替换为 # NR RAN Container3GPP TS 38.425定义 # Bit 0-5: DRB ID (1-32) # Bit 6-7: Reserved # Next Extension Header Type: 0x00 (no further extension) # Extension Header Length: 0x01 (1 byte) nr_ran_container bytes([ (drb_id 0x3f) # DRB ID填入低6位 ])翻车现场某实验室部署中CU向DU发送的F1 GTP-U包被DU静默丢弃。Wireshark显示GTP-U头Message Type0xffGPDU正确但DU日志报invalid NR RAN Container length。定位发现CU侧NR RAN Container长度字段写为0x02误将1字节容器当2字节而DU严格按TS 38.425要求校验长度0x01。修复CU GTP-U封装模块中extension_header_length字段硬编码为0x01禁止动态计算。4. 下行数据落地MAC调度、物理层编码与UE侧接收链路验证4.1 DU侧MAC层逻辑信道映射与TB构造规则DU收到F1 GTP-U包后剥离GTP-U头提取PDCP PDU送入MAC层。MAC层执行逻辑信道映射根据DRB ID查表将PDCP PDU映射到对应逻辑信道如DRB1→LCID3映射到DL-SCHTBTransport Block构造将多个PDCP PDU或单个大PDU按TTI1ms打包为TB添加MAC头含LCID、Length字段HARQ进程调度为每个TB分配HARQ进程ID0-15记录在PHICH/PDCCH中。# MAC子头结构针对一个PDCP PDU # LCID: 0x03 (DRB1) # Length: 0x05d8 (1500字节与GTP-U内层IP包长一致) mac_subheader b\x03\x05\xd8 # TB mac_subheader pdcp_pdu padding (to fit TBS)避坑MAC层丢包的三大隐形杀手现象1UE侧TCP吞吐量骤降50%但空口RSRP/SINR正常。原因MAC层TB大小超过当前TBSTransport Block Size。TBS由MCS调制编码方案和RB数资源块数查3GPP TS 38.214 Table 5.1.3.1-1确定。若CU误将MCS从28256QAM降为10QPSK但RB数未增TBS从27000B暴跌至3000B导致PDCP PDU被截断。解决检查CU侧调度器输出的MCS/RB配置用lte_tbs_calculator.py工具验证TBS是否≥PDCP PDU长度。现象2Wireshark在DU侧看到MAC PDU但UE侧无对应PDCP包。原因MAC头LCID错误。例如DRB2应配LCID0x04但CU误配0x05对应SRB2DU将包送入控制面丢弃。解决比对CU配置的DRB-LCID映射表与DU侧rrc.drb_config参数是否一致。现象3UE上报大量harq_feedback_nack但基站未重传。原因HARQ进程ID冲突。CU为不同TTI的TB重复分配同一HARQ IDDU无法区分新传与重传。解决强制CU按TTI模16分配HARQ IDID tti_index % 16确保16个进程轮转使用。4.2 物理层编码从TB到OFDM符号的全流程转换MAC层输出的TB送入PHY层经历CRC添加24bit CRC多项式0x1021附于TB末尾码块分割若TB 8448bit按3GPP TS 38.212 Section 5.1.2分割为多个码块CB每CB加24bit CRCLDPC编码每个CB经LDPC基图BG1/BG2编码码率1/3或2/3速率匹配按目标码率截取比特填入PRBPhysical Resource Block加扰与调制用小区ID加扰QPSK/16QAM/64QAM/256QAM调制层映射与预编码多天线场景下映射到各层经PMI预编码RE映射将OFDM符号填入时频资源格Resource Grid。# 关键参数验证脚本Python伪代码需接入PHY SDK def validate_phy_encoding(tb_bytes): crc24 calculate_crc24(tb_bytes) # 3GPP TS 38.212 Annex B.1.1 tb_with_crc tb_bytes crc24 if len(tb_with_crc) 8448 * 8: # 8448bit 8448*867584bits cb_list code_block_segment(tb_with_crc) # 分割CB-CRC ldpc_encoded [ldpc_encode(cb, bgBG1, rate1/3) for cb in cb_list] else: ldpc_encoded [ldpc_encode(tb_with_crc, bgBG1, rate1/3)] # 验证ldpc_encoded总长是否匹配调度器下发的TBS assert sum(len(x) for x in ldpc_encoded) scheduled_tbs_bits注意LDPC编码是计算密集型操作。某次实测中DU PHY模块在256QAM100MHz带宽下单TTI编码耗时超200μs超时阈值150μs导致调度器丢弃该TTI。解决方案启用LDPC硬件加速引擎并验证phy.ldpc_hw_acceleratorenabled配置生效。4.3 UE侧接收链路从天线到应用层的全栈解码验证UE天线接收OFDM符号后反向执行PHY→MAC→PDCP→SDAP→IP→TCP流程PHY解调信道估计、FFT、解调、LDPC译码需BER 1e-5MAC解复用解析MAC头LCID提取PDCP PDUPDCP解密用KgNB_enc解密校验MAC-IKgNB_intSDAP解析读取QFI确认QoS Flow归属IP重组按IPv4 Identification字段重组分片TCP重组按Sequence Number排序提交给Socket缓冲区。# UE侧关键日志字段供问题定位 # PHY层rx_rsrp-95, rx_sinr18.2, bler0.002 (合格) # MAC层harq_ackACK, drb_id1, lc_id0x03, pdu_len1500 # PDCP层integrity_checkPASS, cipher_checkPASS, sn0x1234 # SDAP层qfi0x08, reflective_qos_appliedTRUE # IP层ip_id0xabc1, ip_ttl63 (经一跳衰减), ip_proto6 # TCP层tcp_seq0x1a2b3c4d, tcp_flagsACK, tcp_window65535终极验证技巧在UE侧启动tcpdump -i any port 80 -w http_downlink.pcap同时在UPF侧抓GTP-U包。用tshark -r http_downlink.pcap -T fields -e tcp.seq -e tcp.len提取TCP序列号与长度再用tshark -r upf_gtpu.pcap -Y gtpv1.teid0x12345678 -T fields -e gtpv1.length提取GTP-U负载长度。若两者序列号严格连续、长度总和一致则证明下行链路全栈无丢包、无乱序。这是验收5G数据面性能的黄金标准。5. 避坑指南5G下行数据流调试中高频踩坑的5个真实场景与根治方案5.1 现象Wireshark在UPF侧看到GTP-U包gNodeB CU侧无对应包原因UPF与gNodeB CU间的NG-U接口路由不通或防火墙拦截UDP 2152端口。更隐蔽的原因是——UPF生成的外层IP头中Destination IP地址填写错误如填成gNodeB DU地址而非CU地址导致包被路由到错误设备。解决在UPF执行ip route get 10.10.30.5CU NG-U地址确认下一跳为直连网关在CU侧执行tcpdump -i any udp port 2152 -w ng_u_debug.pcap确认是否收包若CU收不到登录UPF检查upf.ng_u_dst_ip配置项确保其值为CU的NG-U接口IP非DU或SCTP地址若CU收到但丢弃在CU内核日志dmesg | grep gtp中查找gtp_rx: invalid TEID确认TEID是否在CU维护的隧道表中ip link show gtp0查看隧道列表。5.2 现象gNodeB CU侧有PDCP包DU侧无对应F1 GTP-U包原因CU与DU间的F1接口GTP-U隧道未建立或CU侧F1隧道配置指向错误DU IP。常见于CU-DU分离部署时CU配置的DU地址是管理面IP而非F1-C用户面IP。解决在CU执行ip link show f1gtp0确认F1 GTP-U隧道状态为UP检查CU配置文件中f1.du_user_plane_ip是否为DU的F1-U接口IP通常与F1-C不同网段在DU侧执行tcpdump -i any udp port 2152 -w f1_debug.pcap确认是否收包若DU收到但日志报invalid nr-ran-container检查CU侧GTP-U封装代码中NR RAN Container长度字段是否恒为0x01见3.3节。5.3 现象UE侧TCP吞吐量极低1Mbps但空口调度正常MCS高、RB多原因PDCP层重排序缓冲区溢出。当CU侧PDCP SN跳跃过大如因重传导致SN0x1000后突然跳到0x2000UE PDCP按SN顺序等待0x1001~0x1fff的包缓冲区填满后丢弃后续包。解决在UE侧读取PDCP统计cat /proc/net/pdcprx关注reordering_buffer_full计数在CU侧检查PDCP SN生成逻辑确保SN严格单调递增禁用随机跳变调大UE侧PDCP重排序缓冲区修改UE内核参数echo 2048 /sys/module/pdcprx/parameters/reorder_buffer_size需root权限终极方案CU启用PDCP状态报告Status Report定期向UE同步已发送最高SNUE据此清理过期缓冲区。5.4 现象UE能上网但视频卡顿Wireshark显示TCP重传率20%原因QoS Flow映射错误。UPF将视频流5QI8错误映射到低优先级DRB如DRB2而DRB2的RLC AM模式重传次数上限maxRetxThreshold设为4次低于视频容忍阈值需≥8次。解决在UPF侧检查SDF模板匹配结果upf show sdf-match-result ue-ip确认视频流匹配的QFI0x08在CU侧检查QFI-to-DRB映射cu show drb-mapping qfi0x08确认映射到DRB1高优先级检查DRB1的RLC配置cu show rlc-config drb1确认maxRetxThreshold8且t-Reassembly35ms视频推荐值若DRB1已配置正确检查CU侧是否启用了RLC UM模式UM模式无重传强制设为AM模式cu set rlc-mode drb1 modeAM。5.5 现象HTTP页面加载完成但部分图片不显示Wireshark显示TCP FIN包后仍有GTP-U包到达原因TCP连接关闭时序问题。服务器发送FIN后UPF仍转发剩余GTP-U包因GTP-U隧道未立即拆除CU继续解密并提交给UE TCP栈但UE已关闭Socket导致包被内核丢弃tcp_drop计数上升。解决在UPF侧启用GTP-U隧道优雅关闭配置upf.gtpu.graceful_shutdown_timeout50005秒在CU侧监听GTP-U隧道拆除消息GTP-C Delete PDP Context Request收到后立即停止向PDCP提交新包在UE侧调整TCP TIME_WAIT时间echo 30 /proc/sys/net/ipv4/tcp_fin_timeout加速Socket回收应用层规避浏览器启用HTTP/2多路复用避免频繁建连断连。6. 进阶验证用三台设备构建闭环测试环境实现从HTTP请求到UE屏幕的端到端时延测绘6.1 测试拓扑与设备角色定义要真正吃透下行数据流必须亲手搭建可测量的闭环环境。我一般用三台设备构建最小可行系统ServerUbuntu 22.04虚拟机运行Nginx http-server提供静态HTML图片资源UPF/CU/DU基于Open5GS srsRAN的轻量级5G核心网与基站CU/DU分离部署UEAndroid 13手机Root Termux tcpdump 自研时延打点App。关键设计Server侧在HTTP响应头中注入X-Start-Timestamp: 1712345678.123456微秒级时间戳UE App在WebView.onPageFinished()回调中读取该头并记录System.nanoTime()作为结束时间。两端时间差即为端到端时延含网络终端处理。6.2 时延分解测量表定位瓶颈在哪个协议层在Server、UPF、CU、DU、UE五点部署时间戳采集汇总为下表。以下载1MB HTML为例理论空口时延10ms测量点时间戳位置典型时延异常阈值定位方法Servertime.time_ns()at HTTP response start0ms基准—无UPFgettimeofday()on GTP-U packet ingress1.2ms5msupf trace gtpu-ingressCUktime_get_ns()after GTP-U decap2.8ms10msperf record -e sched:sched_switch -p $(pidof cu)DUktime_get_ns()after MAC TX queue4.5ms15msdu log levelDEBUGUESystem.nanoTime()at TCP recv()18.3ms50msadb shell cat /proc/net/dev表格解读若CU到DU时延突增至12ms超阈值说明CU侧PDCP处理慢或F1接口拥塞若UE侧时延达65ms但空口RSRP正常大概率是UE TCP栈接收缓冲区小net.ipv4.tcp_rmem需调大echo net.ipv4.tcp_rmem 4096 65536 8388608 /etc/sysctl.conf。6.3 抓包联动分析法Wireshark 5G协议栈日志交叉验证单一抓包无法定位跨层问题必须联动分析。我的标准动作是Server侧tcpdump -i eth0 port 80 -w server.pcapUPF侧tcpdump -i any udp port 2152 and ip[36:4] 0x12345678 -w upf.pcap过滤TEIDCU侧tcpdump -i any udp port 2152 and ip[36:4] 0xabcdef01 -w cu.pcapCU-F1隧道TEIDUE侧tcpdump -i any port 80 -w ue.pcap。然后用Wireshark的File → Merge合并四文件用Statistics → IO Graph绘制各点吞吐量曲线。重点观察Server到UPF若曲线平滑但UPF到CU断崖下跌问题在UPF-GTP-U封装或路由CU到DU若CU侧有包而DU侧无检查F1隧道TEID是否匹配DU到UE若DU侧TX曲线正常但UE侧RX曲线缺失检查UE天线连接或RF校准。6.4 从那以后我每次调试5G下行都强制走一遍“三层时间戳”Server打点、UPF打点、UE打点——这三处时间戳成本几乎为零Server加一行HTTP头UPF改一行日志UE用现成API却能瞬间把模糊的“网络慢”转化为精确的“CU处理耗时超标”。曾经为定位一个200ms的网页加载延迟我们花了三天在Wireshark里翻包最后发现是CU侧PDCP加密模块的AES-NI指令未启用启用后延迟直降180ms。现在我所有5G项目启动时第一件事就是让Server、UPF、UE三方同步NTP并在关键路径插入微秒级打点。这不仅是技术习惯更是对“数据流不可见即不存在”这一铁律的敬畏。希望帮到你。本文还有配套的精品资源点击获取