5G NR下行数据端到端信令流解析：从HTTP到OFDM

简介本资源是一份面向5G通信初学者与网络协议学习者的图形化教学材料聚焦5G NR下行数据传输全流程解析帮助读者直观理解用户面协议栈分层机制及各层封装逻辑。内容以清晰图示为核心完整呈现从应用层HTTP GET请求出发经TCP、IP、SDAP、PDCP、RLC、MAC至物理层的逐级封装过程并结合CU-DU分离架构CU承载SDAP/PDCPDU承载RLC/MAC/PHY说明协议栈部署关系特别标注TCP头部20字节结构、IPv4头部字段功能及关键参数含义。资源为单个PDF文件大小874KB排版紧凑、图文并茂适合作为课堂补充材料或自学速查参考。目前已有270人下载学习内容源自专业技术文档提炼无冗余文字所有图示均标注来源编号如Figure 212–214便于对照理解协议栈演进与数据流向。1. 5G NR 下行数据传输流程图解不是协议栈截图而是能跑通的端到端信令流还原你手头有一份标着“5G NR in BULLETS”的 PDF页码 248–250里面嵌了 7 张带编号的流程图Fig. 212–220但打开后发现全是静态示意图——没有可交互节点、没有协议字段点击展开、没有字段值动态填充、更没有和真实抓包如 Wireshark 中的 gNB→UE 流量对齐的映射关系。这不是教学挂图而是一份可工程复现的下行数据路径拆解说明书它把从 HTTP GET 发出那一刻起到 UE 物理层射频口输出 OFDM 符号为止中间经过 UPF、CU、DU、F1/NG-U 隧道、GTP-U 封装、SDAP 映射、PDCP 加密、RLC 分段、MAC 调度、PHY 编码的每一层头部增删、隧道嵌套、QoS Flow→DRB 绑定、TEID 查表逻辑全用图形文字锚定在 3GPP TS 38.415 / 38.425 / 29.281 的具体条款里。它不讲“5G 有多快”只解决一个硬问题当你在 gNodeB 的 CU 日志里看到PDCP SN127, MAC-I0x8a3f...怎么反向定位这个包来自哪个 PDU Session、对应哪个 HTTP 请求、走的是哪条 GTP-U 隧道、为什么被调度在 Slot #3 的 Symbol 2–13这份资源就是给现场优化工程师、协议栈开发岗、信令回溯分析员准备的「黑匣子解码手册」——不是让你背协议是让你在 real trace 里一眼认出哪个字段改错了。2. 从 HTTP GET 到 GTP-U 封装五层封装链的逐层剥离与字段溯源2.1 应用层触发HTTP GET 如何启动整个下行链路用户在浏览器输入http://example.com/index.html并回车触发 HTTP GET 请求。关键点在于这不是单个 TCP 包而是 TCP 连接建立后的第一个应用层有效载荷。Wireshark 中你会看到SYN → SYN-ACK → ACK三次握手紧接着一个 TCP segmentPayload GET /index.html HTTP/1.1\r\nHost: example.com\r\n...提示实际部署中HTTP/2 或 QUIC 会改变上层行为但本图解严格基于 HTTP/1.1 TCP 场景。若你的核心网启用了 HTTP/2 ALPN 协商需额外解析 TLS 扩展字段不在本流程覆盖范围内。该 TCP segment 的源端口Source Port由客户端随机生成如 54321目的端口Destination Port固定为 80HTTP。这个五元组{SrcIP, DstIP, SrcPort, DstPort, Protocol6}是后续所有 QoS Flow 匹配的原始依据。2.2 TCP/IP 封装20 字节头部里的生存逻辑TCP 头部Fig. 213和 IP 头部Fig. 214不是装饰。它们携带的字段直接决定数据能否被正确路由、重组、校验# 从真实 PCAP 提取 TCP 头部hexdump -C tcp_pkt.bin | head -n 1 00000000 45 00 00 40 00 01 40 00 40 06 00 00 c0 a8 01 02 |E............| 00000010 c0 a8 01 03 d8 41 00 50 00 00 00 00 00 00 00 00 |.....A.P........| 00000020 50 02 20 00 00 00 00 00 00 00 00 00 00 00 00 00 |P. .............|前 4 字节45 00IPv4 Version (4) IHL (5 → 5×420 bytes header)字节 12–1300 06Protocol 6 → TCP字节 20–21d8 41Source Port 0xd841 55361十进制字节 22–2300 50Destination Port 0x0050 80字节 24–2700 00 00 00Sequence Number 0SYN 包字节 28–3100 00 00 00Acknowledgement Number 0SYN 包注意TCP Sequence Number 在数据传输阶段才开始递增SYN 包的 Seq0 是初始序列号ISN实际值由 OS 随机生成。Wireshark 默认显示相对序号Relative Seq需右键 → Protocol Preferences → TCP → 取消勾选 Relative sequence numbers 查看绝对值。2.3 UPF 的 SDF 匹配用五元组查表定位 PDU Session当 IP 包到达 UPFUser Plane FunctionUPF 不转发原始 IP 包而是执行Service Data Flow (SDF) 匹配。匹配依据来自 SMF 下发的 SDF Template典型模板如下JSON 表示{ sdfId: sdf-001, pduSessionId: ps-12345, qosFlowId: qfi-9, sdfFilter: { srcIpv4: 192.168.1.2, dstIpv4: 192.168.1.3, srcPort: 55361, dstPort: 80, ipProto: 6, direction: DOWNLINK } }UPF 对每个入向 IP 包提取五元组与所有 SDF Filter 比较。一旦匹配成功如上例则绑定pduSessionId ps-12345绑定qosFlowId qfi-9启动对应 PDU Session 的 GTP-U 隧道TEID 已预分配关键参数说明direction: DOWNLINK表明此 SDF 仅用于下行匹配上行流量需另一套 SDF Filter通常 src/dst 互换。若匹配失败UPF 丢弃该包并上报 SMF —— 这是现网中“网页打不开但 ping 通”的常见根因。2.4 GTP-U 封装双 IP 头 PDU Session Container 的嵌套结构UPF 将原始 IP 包作为 payload封装进 GTP-U 隧道。此时出现外层 IP 头Outer IP UDP 头 GTP-U 头 内层 IP 头Inner IP TCP HTTP的七层结构Fig. 218。GTP-U 头核心字段字段名长度值示例作用Version3 bit010(2)GTP versionPT (Protocol Type)1 bit1标识 GTP-U非 GTP-CE (Extension Header)1 bit0无扩展头除非启用 PDU Session ContainerS (Sequence Number)1 bit1启用 Sequence Number 字段用于乱序检测N (N-PDU Number)1 bit0不启用 N-PDU NumberMessage Type8 bit0xFF(Echo Request) or0x00(G-PDU)0x00表示承载用户数据TEID32 bit0x12345678Tunnel Endpoint ID唯一标识 PDU SessionSequence Number16 bit0x0001用于接收端排序当 S1当启用 PDU Session ContainerFig. 215/216GTP-U 头末尾追加 4 字节容器字段值说明PDU Type0x00Downlink PDU0x01 UplinkPPP (Paging Policy Presence)0x00不携带 Paging Policy IndicatorRQI (Reflective QoS Indicator)0x01启用 Reflective QoSUE 可据此反向设置上行 QoSQFI (QoS Flow Identifier)0x09直接携带 QFI9绕过 CU 的 SDAP 映射查表实战技巧Wireshark 中过滤 GTP-U 下行包用gtpv1.message_type 0x00 ip.src UPF_IP查看 PDU Session Container 需安装 3GPP 插件或手动解析 offset。默认 GTP-U 头长 12 字节启用 Container 后为 16 字节。3. CU-DU 分离架构下的 SDAP/PDCP 处理从 QoS Flow 到 DRB 的映射决策3.1 SDAP 层QoS Flow ID 到 DRB 的绑定逻辑gNodeB CU 收到 GTP-U 包后首先解析 TEID 和 PDU Session Container 中的 QFIQoS Flow Identifier。SDAP 层根据QFI-to-DRB 映射表由 RRC 重配置消息下发执行绑定QFI | DRB ID | DRB Type | QoS Profile ----|--------|----------|------------ 1 | 1 | MCG DRB | 5QI8 (Video Streaming) 5 | 2 | SCG DRB | 5QI9 (GBR Voice) 9 | 1 | MCG DRB | 5QI5 (IMS Signaling)注意同一 QFI 可映射到不同 DRB如 QFI9 在 NSA 架构下可能走 SCG DRB但本图解基于 SAStandalone场景所有 DRB 均为 MCG 类型。SDAP 层可选择是否添加 SDAP header若reflectiveQoSEnabled trueRRC 配置则添加 1 字节 SDAP header0x09QFI9供 UE 反向推导上行映射若reflectiveQoSEnabled false则不加 header仅靠 CU 内部状态机维护映射。关键区别不加 SDAP header 时UE 无法获知下行 QFI上行 QoS 必须由网络显式配置通过 QoS Rule加 header 后UE 可自动应用 Reflective QoS减少信令开销。3.2 PDCP 层加密、完整性保护与序列号管理PDCP 层处理流程严格遵循 3GPP TS 38.331完整性保护使用KRRCint密钥 COUNTHFN 8 | PDCP SN计算 MAC-I附加在 PDCP header 末尾4 字节加密使用KRRCenc密钥 相同COUNT加密 payload不加密 headerHeader 压缩对 VoLTE 等语音流启用 ROHC但 HTTP 数据包默认禁用rohc.profiles.enabled falseSN 分配PDCP SN 为 12/18 bit取决于 RRC 配置本例采用 12-bit SN0–4095当前值0x007F 127。PDCP header 结构12-bit SN字段长度值说明D/C1 bit1Data PDU0 Control PDUR1 bit0ReservedR1 bit0ReservedR1 bit0ReservedR1 bit0ReservedR1 bit0ReservedR1 bit0ReservedR1 bit0ReservedSN12 bit0x007FPDCP Sequence Number 127加密后payload原 TCP/IP 包被混淆但 header 中的 SN 和 D/C 位明文可见 —— 这是基站侧日志中PDCP SN127的来源。3.3 F1 接口 GTP-U 封装从 PDU Session Tunnel 到 DRB Tunnel 的切换CU 将 PDCP PDU 转发至 DU 时不再使用 NG-U 接口的 PDU Session Container而是切换为F1-U 接口专用的 NR RAN ContainerFig. 220。关键变化TEID 不再标识 PDU Session而是标识DRB ID如 DRB1 → TEID0x10001, DRB2 → TEID0x10002GTP-U Message Type 仍为0x00G-PDU但 NR RAN Container 替换 PDU Session ContainerNR RAN Container 至少包含drb-Identity1 byteDRB ID1–32pdcpsn-Size1 bytePDCP SN 长度12 or 18 bitpdcpsn2 or 3 bytes当前 PDCP SN 值这意味着NG-U 隧道是 per PDU SessionF1-U 隧道是 per DRB。一个 PDU Session 可含多个 QoS Flow映射到多个 DRB因此需多个 F1-U 隧道。血泪经验若 CU 配置了 3 个 DRB但 DU 侧只建立了 2 条 F1-U 隧道如因 F1 Setup Response 丢失则第三个 DRB 的数据将堆积在 CU 缓冲区导致 TCP 重传超时 —— 此时需检查F1AP: F1 Setup Failure或GTP-U: Error Indication。4. DU 侧 RLC/MAC/PHY 处理从逻辑信道到 OFDM 符号的物理落地4.1 RLC 层AM 模式下的分段与重传控制DU 收到 F1-U 包后PDCP PDU 交由 RLC 层处理。下行采用 AMAcknowledged Mode核心动作分段Segmentation若 PDCP PDU MAC PDU size如 3840 bytesRLC 拆分为多个 RLC PDUARQ 状态管理维护VR(R)Receive state variable、VR(S)Send state variable、VR(MS)Max SendStatus ReportUE 定期发送 Status PDU指示哪些 RLC SN 已接收ACK、哪些丢失NACK。RLC AM header12-bit SN字段长度值说明D/C1 bit1Data PDURF1 bit0No resegmentationP1 bit0No poll requestFI2 bit00First and last segmentE1 bit0No extensionSN12 bit0x007FRLC Sequence Number与 PDCP SN 独立注意RLC SN 与 PDCP SN 无数学关系只是各自独立计数器。RLC 层负责将 PDCP PDU 拆成适合 PHY 传输的块并保证可靠交付。4.2 MAC 层逻辑信道映射与 HARQ 调度MAC 层核心任务是将 RLC PDU 映射到逻辑信道Logical Channel再调度到传输信道Transport ChannelRLC PDU 来源逻辑信道LCID用途SRB1/2 (Signaling)DCCH0x01RRC 信令DRB1 (Data)DTCH0x02用户数据DRB2 (Data)DTCH0x03用户数据MAC PDU 结构包含MAC header含 LCID、Length 字段一个或多个 MAC SDU即 RLC PDUPadding可选调度器根据 CQIChannel Quality Indicator、PHRPower Headroom Report、BSRBuffer Status Report选择PRB 数量如 50 PRBMCSModulation and Coding Scheme如 QPSK, 16QAMTTITransmission Time Interval如 1 ms slot调度信息通过DCI (Downlink Control Information)信令下发UE 在 PDCCH 上盲检。4.3 PHY 层OFDM 符号生成与射频输出最终MAC PDU 进入 PHY 层经历CRC 添加24-bitLDPC 编码Base Graph 1 or 2Rate Matching打孔/重复Scrambling用 cell ID 和 slot number 初始化ModulationQPSK/16QAM/64QAM/256QAMLayer Mapping Precoding多天线OFDM 符号生成IFFT CP 添加输出为时频域资源格Resource Grid1 subframe 1 ms 14 OFDM symbolsNormal CP1 RB 12 subcarriers × 1 symbol 180 kHz × 66.7 μs典型分配50 RB × 14 symbols 700 RE/slot玄学提示若 UE 报告CQI15最高但实际吞吐量仅 10 Mbps大概率是 MAC 层调度器未分配足够 PRB而非 PHY 问题 —— 此时应抓取MAC CE: BSR和DCI 1_0/1_1解析调度指令而非盯着PHY: BLER。5. 避坑指南5G 下行流程中 5 个高频翻车点与排查路径5.1 现象HTTP 页面加载超时但 ping 通且 TCP 三次握手成功原因UPF 未匹配到 SDF Filter导致 GTP-U 封装失败IP 包被丢弃。SMF 未下发 SDF Template或模板中direction错设为UPLINK。解决在 UPF 日志中搜索SDF_MATCH_FAIL或NO_SDF_FOUND用tcpdump -i any port 2152确认 UPF 是否发出 GTP-U 包检查 SMF 的 PDU Session Establishment Request 中sdfList字段是否包含正确的五元组。5.2 现象Wireshark 显示 GTP-U 包正常但 UE 侧无 TCP ACK原因CU 的 SDAP 层未正确映射 QFI 到 DRB或 DRB 未激活RRC Reconfiguration 未完成。CU 日志中出现SDAP_QFI_NOT_FOUND或DRB_NOT_ACTIVE。解决在 CU 日志中搜索sdap和drb关键字确认 RRC Connection Reconfiguration 消息已送达 UE 并收到RRCReconfComplete检查rrcSetupComplete中srb-ToAddModList和drb-ToAddModList是否完整。5.3 现象PDCP 层日志显示INTEGRITY_FAILURE原因CU 和 UE 的KRRCint密钥不一致或COUNT同步丢失如 UE 重同步后 CU 未重置 HFN。常见于 RRC 连接重建后密钥未更新。解决比对 CU 和 UE 的securityAlgorithmConfig在 RRCSetupComplete 和 SecurityModeCommand 中检查keyChangeIndicator是否为true确认 CU 的HFN是否在重建后重置为 0。5.4 现象MAC 层调度频繁但 PHY 层 BLER 30%原因CQI 上报失真UE 误判信道质量或调度器使用了过高的 MCS如要求 256QAM 但实际信道仅支持 16QAM。解决抓取 UE 的CQI_ReportPUCCH/PUSCH与实际 SINR 对比在 gNodeB 日志中搜索mcsSelection和targetCodeRate强制调度器降 MCS如maxMcsDl12对应 16QAM验证。5.5 现象F1-U 接口 GTP-U 包持续发送但 DU 侧无 PHY 输出原因DU 的 F1-U 隧道 TEID 配置错误如 CU 发送 TEID0x10001DU 期望 0x20001或 DU 的 DRB 配置缺失drb-ToAddModList为空。解决在 CU 日志中搜索f1u_send和teid在 DU 日志中搜索f1u_recv和teid_mismatch比对 CU 的F1SetupRequest与 DU 的F1SetupResponse中drb-SetupList是否一致。6. 验证技巧用 Wireshark gNodeB 日志交叉定位下行断点6.1 构建三层时间戳对齐从应用层到 PHY 层要准确定位瓶颈必须将三个平面的时间戳对齐平面时间戳来源对齐方法典型偏差应用层PCAP 中 TCP timestamp optionTSval记录SYN包的TSval作为 t0±1 ms网络层UPF 的syslog或tcpdump -tt记录 GTP-U 包到达 UPF 的tv_sec.tv_usec±5 msNTP 同步后无线层gNodeB CU 日志中的PDCP_TX_TIME日志格式2023-10-01 12:34:56.789±10 ms需校准 syslog 时钟对齐后计算各段延迟t_UPF - t_TCP 100 ms → UPF 处理瓶颈CPU 过载或 SDF 匹配慢t_CU - t_UPF 50 ms → CU PDCP/SDAP 处理慢密钥运算或缓冲区满t_DU - t_CU 20 ms → F1-U 传输延迟光模块故障或路由环路6.2 Wireshark 过滤链快速定位 GTP-U 封装异常在 UPF 出口抓包tcpdump -i eth0 port 2152 -w upf_gtp.pcap用以下 Wireshark display filter 逐层筛查# 1. 筛选所有 GTP-U 下行包排除 Echo gtpv1.message_type 0x00 # 2. 筛选含 PDU Session Container 的包E1 且有 Container gtpv1.message_type 0x00 gtpv1.extension_header 1 (gtpv1.pdu_type 0x00) # 3. 筛选特定 TEID 的包如 0x12345678 gtpv1.message_type 0x00 gtpv1.teid 0x12345678 # 4. 筛选内层 IP 目的地址为 UE 的包验证封装正确性 gtpv1.message_type 0x00 ip.dst 192.168.100.10若第 2 步无结果说明 UPF 未启用 PDU Session Container需检查 SMF 配置pduSessionContainerRequiredtrue若第 4 步无结果说明内层 IP 地址被错误修改UPF NAT 配置错误。6.3 CU 日志字段速查表关键字段与含义日志关键词示例值含义关联协议层SDAP_MAP_QFIQFI9 - DRB1SDAP 层 QFI 到 DRB 映射SDAPPDCP_ENC_STARTSN127, COUNT0x0000007FPDCP 加密起始含 SN 和 COUNTPDCPF1U_SEND_TEIDTEID0x10001, DRB1F1-U 发送TEID 对应 DRBF1-URLC_AM_SEGSN127, SO0, E0RLC 分段SOSegment OffsetRLCMAC_SCHEDRB50, MCS12, TBS3240MAC 调度参数TBSTransport Block SizeMAC从那以后我每次分析下行卡顿都强制走一遍这三步① PCAP 中确认 GTP-U 是否发出② CU 日志中PDCP_ENC_START是否记录③ DU 日志中MAC_SCHED是否触发。只要其中一步缺失就不用往下查 PHY —— 问题一定在前序环节。希望帮到你。本文还有配套的精品资源点击获取