5G下行数据传输流程图：时序+协议栈+物理层映射可视化-开发者社区

简介：本资源是一份面向5G通信初学者与网络协议学习者的图形化教学材料，聚焦5G NR下行数据传输全流程解析，帮助读者直观理解用户面协议栈分层机制及各层封装逻辑。内容以清晰图示为核心，完整呈现从应用层HTTP GET请求出发，经TCP、IP、SDAP、PDCP、RLC、MAC至物理层的逐级封装过程，并结合CU-DU分离架构（CU承载SDAP/PDCP，DU承载RLC/MAC/PHY）说明协议栈部署关系，特别标注TCP头部20字节结构、IPv4头部字段功能及关键参数含义。资源为单个PDF文件，大小874KB，排版紧凑、图文并茂，适合作为课堂补充材料或自学速查手册。目前已有270人学习下载，内容覆盖协议栈分层原理、头部字段作用、端到端数据流向等核心知识点，可有效辅助理解5G NR用户面数据传递本质。

1. 为什么画不清5G下行数据传输流程？不是不会，是缺一张「带时序+协议栈+物理层映射」的图

你手头可能有3GPP TS 38.300的PDF，翻到第6章“Data transmission procedures”，密密麻麻全是文字：“The gNB transmits PDSCH carrying DL-SCH data… the UE performs HARQ feedback on PUCCH…”——但合上文档那一刻，脑子里还是没画面：PDCP包怎么变成MAC CE？MAC CE又怎么塞进PDSCH的RE里？调度指令（DCI）和实际数据（TB）在时频域上到底错开几个slot？

这篇笔记不讲标准原文，只做一件事：用Python+Matplotlib从零生成一张可复现、可修改、可嵌入技术文档的5G下行数据传输流程图。它必须同时体现三层关键信息：

时间维度：TDD帧结构（如30kHz子载波间隔下1ms slot + 14个OFDM符号）；
协议栈映射：PDCP SDU → RLC AM PDU → MAC PDU → PDSCH TB → 物理层RE；
控制与数据耦合：DCI 1_0在slot n调度PDSCH在slot n+k，HARQ反馈在slot n+k+4回传。

适合两类人：

协议工程师：需要向客户/跨部门同事快速说清“为什么下行时延卡在4ms”；
高校学生/初学者：拒绝背诵“PDCP加密→RLC分段→MAC加头→PHY调制”，而是看见数据包在每一层被“切、包、贴、填”的真实动作。
图不是装饰，是调试黑匣子的入口——当你发现UE上报的CQI突降，这张图能帮你立刻定位：问题出在MAC层调度失败，还是PHY层信道估计偏差？

2. 用Matplotlib构建5G下行流程图：从坐标系定义到协议栈分层渲染

2.1 定义时频二维坐标系：Slot + OFDM符号是所有图形的锚点

5G TDD帧结构是图形的骨架。我们以典型配置为例：子载波间隔30kHz（对应1ms/slot，14符号/slot），一个无线帧10ms=10个slot。图形横轴为时间（slot编号），纵轴为OFDM符号索引（0~13）。关键约束必须硬编码：

PDCCH占用前1~3个符号（取决于CORESET配置）；
PDSCH从第2个符号开始（避开PDCCH）；
HARQ反馈在PDSCH结束后的第4个slot（3GPP规定最小RTT）。

import matplotlib.pyplot as plt import numpy as np # 参数定义（严格对应3GPP TS 38.211 Table 4.3.2-1） SUBCARRIER_SPACING = 30 # kHz SLOT_DURATION_MS = 1.0 # ms SYMBOLS_PER_SLOT = 14 FRAME_DURATION_MS = 10.0 # ms # 创建时频网格：横轴slot，纵轴symbol slots = np.arange(0, 10) # 1帧=10slot symbols = np.arange(0, SYMBOLS_PER_SLOT) # 绘制基础网格（无数据，仅坐标系） fig, ax = plt.subplots(figsize=(12, 6)) ax.set_xlim(-0.5, 9.5) ax.set_ylim(-0.5, SYMBOLS_PER_SLOT - 0.5) ax.set_xticks(slots) ax.set_yticks(symbols) ax.grid(True, linestyle=':', alpha=0.7) ax.set_xlabel('Slot index (0~9)') ax.set_ylabel('OFDM symbol index (0~13)') ax.set_title('5G NR Downlink Time-Frequency Grid (30kHz SCS)')

提示：SUBCARRIER_SPACING和SYMBOLS_PER_SLOT必须匹配——30kHz对应14符号，而120kHz对应14符号但slot时长缩短为0.125ms。若用错参数，整个时序关系会崩塌。

2.2 分层绘制协议栈：用不同颜色区块表示PDCP/RLC/MAC/PHY处理阶段

协议栈不是垂直堆叠，而是时间偏移+数据膨胀的过程：

PDCP层处理最慢（含加密/完整性保护），通常跨多个slot；
RLC层分段快，但需等待完整SDU；
MAC层打包最“忙”：要插入CRC、填充比特、添加MAC头，还要响应DCI；
PHY层调制最快，但受信道条件制约（CQI影响MCS选择）。

我们用横向色块模拟各层处理耗时，并标注关键事件点：

# 定义各层处理起止slot（示意性，实际依赖UE能力与配置） pdcpl_start, pdcpl_end = 0, 2 # PDCP加密耗时2slot rlc_start, rlc_end = 1, 3 # RLC分段在PDCP输出后启动 mac_start, mac_end = 2, 4 # MAC打包需等待RLC PDU并解析DCI phy_start, phy_end = 3, 5 # PHY调制在MAC PDU就绪后开始 # 绘制协议栈色块（y方向压缩，突出时间轴） ax.barh(y=12, width=pdcpl_end-pdcpl_start, left=pdcpl_start, height=0.8, color='skyblue', alpha=0.7, label='PDCP: Ciphering') ax.barh(y=10, width=rlc_end-rlc_start, left=rlc_start, height=0.8, color='lightgreen', alpha=0.7, label='RLC: Segmentation') ax.barh(y=8, width=mac_end-mac_start, left=mac_start, height=0.8, color='gold', alpha=0.7, label='MAC: Multiplexing & CRC') ax.barh(y=6, width=phy_end-phy_start, left=phy_start, height=0.8, color='coral', alpha=0.7, label='PHY: Modulation & Mapping') # 标注关键事件点（DCI调度、PDSCH传输、HARQ反馈） ax.scatter([2], [1], s=100, c='red', marker='X', label='DCI 1_0 received (slot 2)') ax.scatter([3], [3], s=100, c='blue', marker='o', label='PDSCH transmission (slot 3)') ax.scatter([7], [1], s=100, c='purple', marker='^', label='HARQ ACK (slot 7)') ax.legend(bbox_to_anchor=(1.05, 1), loc='upper left') plt.tight_layout() plt.show()

逻辑说明：

barh的y值代表协议层抽象位置（非物理符号），width是该层处理持续时间；
scatter点坐标(slot, symbol)对应实际物理层事件发生时刻（如DCI在slot2 symbol0~2接收）；
颜色选择遵循通信行业惯例：蓝色系表高层（PDCP/RLC），暖色系表底层（MAC/PHY）。

2.3 叠加物理层资源映射：用热力图显示PDSCH在RE上的实际填充

纯色块不够“硬核”。真正让工程师信服的，是看到1个TB如何填满PDSCH的Resource Blocks。我们模拟一个典型配置：

分配273 RB（100MHz带宽），起始RB index=0；
每RB含12子载波 × 14符号 = 168 RE；
PDSCH占slot3的symbol2~13（共12符号），总RE数 = 273 × 12 × 12 = 39312；
假设TB大小为30000 bits，经LDPC编码后约60000 bits，需全部映射。

# 模拟PDSCH RE填充热力图（简化：只画1个RB的12符号） rb_count = 1 symbol_range = np.arange(2, 14) # PDSCH symbols in slot3 subcarrier_range = np.arange(0, 12) # 12 subcarriers per RB # 创建RE占用矩阵：1=占用，0=空闲（如DMRS、CRS位置） re_grid = np.ones((len(symbol_range), len(subcarrier_range))) # 插入DMRS（type1，symbol2,6,10,14 -> 这里取symbol2,6,10） dmrs_symbols = [0, 4, 8] # index in symbol_range for s_idx in dmrs_symbols: re_grid[s_idx, [0,1,2,3,8,9,10,11]] = 0 # DMRS占4+4=8 SCs # 绘制热力图 fig, ax = plt.subplots(figsize=(8, 4)) im = ax.imshow(re_grid, cmap='Blues', aspect='auto', extent=[-0.5, 11.5, 13.5, 1.5]) # y轴倒置：symbol0在底部 ax.set_xlabel('Subcarrier index (0~11)') ax.set_ylabel('OFDM symbol index (2~13)') ax.set_title('PDSCH Resource Element (RE) Allocation in 1 RB') ax.set_yticks(np.arange(2, 14)) plt.colorbar(im, ax=ax, label='RE occupied (1) / DMRS (0)') plt.show()

参数说明：

re_grid的shape=(12,12)对应12符号×12子载波；
DMRS位置按38.211 Table 6.2.2-1设置（type1，端口数1，密度2）；
热力图中白色区域即DMRS，蓝色区域为数据RE——这直接决定吞吐量上限。

3. 关键时序关系可视化：DCI调度、PDSCH传输、HARQ反馈的精确对齐

3.1 DCI 1_0调度PDSCH：K0时延与slot边界对齐的硬约束

DCI 1_0中的k0字段（0~16）定义了从DCI所在slot到PDSCH首个slot的时延。这是图形中最易画错的环节：

若k0=0，PDSCH与DCI同slot（但需避开PDCCH符号，故从symbol2开始）；
若k0=1，PDSCH在DCI后1个slot；
实际网络中k0常设为1或2，留出gNB处理时间。

我们在图中用双向箭头+标注显式标出k0：

# 在slot2（DCI）与slot3（PDSCH）间画k0=1箭头 ax.annotate('', xy=(3, 1), xytext=(2, 1), arrowprops=dict(arrowstyle='<->', color='black', lw=1.5)) ax.text(2.5, 1.3, 'k0=1', ha='center', va='bottom', fontsize=10, fontweight='bold') # 同样标出HARQ RTT：PDSCH结束slot到ACK slot的时延 pdsch_end_slot = 3 harq_ack_slot = 7 ax.annotate('', xy=(harq_ack_slot, 1), xytext=(pdsch_end_slot, 1), arrowprops=dict(arrowstyle='<->', color='purple', lw=1.5)) ax.text((pdsch_end_slot+harq_ack_slot)/2, 1.3, 'HARQ RTT=4', ha='center', va='bottom', fontsize=10, color='purple')

为什么k0不能为负？
因为DCI必须先于PDSCH传输——这是物理层确定性要求。若图中出现DCI在PDSCH之后，说明调度逻辑已违反3GPP强制约束，必然导致UE解码失败。

3.2 PDSCH与HARQ反馈的slot偏移：从理论值到实测偏差

3GPP规定最小HARQ RTT为4个slot（TS 38.321 Sec 5.4.2），但实际网络中常出现5~6slot延迟，原因有三：

gNB侧HARQ buffer排队（高负载时）；
UE侧PDSCH解码耗时超预期（低SNR场景）；
上行资源调度延迟（PUCCH资源不足）。

我们在图中用虚线框+文字标注区分理论与实测：

# 理论HARQ窗口（slot7） ax.add_patch(plt.Rectangle((6.5, 0.5), 1, 1, fill=False, edgecolor='purple', linestyle='--', lw=1.5)) ax.text(7, 0.2, 'Theoretical\nHARQ ACK', ha='center', va='bottom', fontsize=9, color='purple') # 实测HARQ窗口（slot8，用红色虚线框） ax.add_patch(plt.Rectangle((7.5, 0.5), 1, 1, fill=False, edgecolor='red', linestyle=':', lw=1.5)) ax.text(8, 0.2, 'Measured\nHARQ ACK', ha='center', va='bottom', fontsize=9, color='red')

注意：实测窗口右移意味着gNB需延长HARQ buffer保留时间，否则会误判为NACK。这对缓冲区设计是硬指标。

3.3 多TB并行传输的时序叠加：避免slot内符号冲突

单UE可同时接收多个TB（通过DCI中的ndi翻转识别），但所有TB必须共享同一PDSCH时频资源。图形中需体现：

TB1和TB2的PDSCH在相同slot、相同RB、相同symbol范围；
区分靠不同RV（Redundancy Version）和MCS；
HARQ反馈合并为1个ACK/NACK。

# 在slot3绘制两个TB的PDSCH色块（重叠） ax.barh(y=3, width=1, left=3, height=0.6, color='blue', alpha=0.5, label='TB1') ax.barh(y=2.5, width=1, left=3, height=0.6, color='darkblue', alpha=0.5, label='TB2') ax.text(3.5, 2.8, 'TB1+TB2\nin same PDSCH', ha='center', va='center', fontsize=9)

关键洞察：TB数量增加不提升峰值速率（RE总数不变），但提升调度灵活性——例如TB1传控制面数据（低MCS），TB2传用户面数据（高MCS）。

4. 避坑：5G下行流程图绘制中踩过的5个真实坑

4.1 现象：PDCCH和PDSCH在图中重叠，导致UE解码失败

原因：PDCCH必须占用slot前1~3个符号，而PDSCH起始符号未避让。常见错误是把PDSCH起始设为symbol0，忽略PDCCH占用。
解决：严格按CORESET配置计算PDCCH符号数。若CORESET包含symbol0~2，则PDSCH必须从symbol3开始。代码中用pdsch_start_symbol = max(3, pdcch_end_symbol + 1)硬约束。

4.2 现象：HARQ反馈点画在PDSCH slot内，与3GPP规定冲突

原因：误将“PDSCH传输slot”当作“HARQ处理完成slot”。实际上UE需经历：PDSCH接收→信道估计→LDPC译码→CRC校验→生成ACK/NACK→等待PUCCH资源→发送。
解决：HARQ反馈点必须落在pdsch_slot + k1，其中k1≥4。图中用ax.scatter([pdsch_slot + 4], [1], ...)确保合规。

4.3 现象：RLC分段块跨越slot边界，但未标注分段标识（FI字段）

原因：RLC AM模式中，一个SDU可能被分到多个PDU，首PDU的FI=01（start），中PDU的FI=00（continue），尾PDU的FI=10（end）。图中若只画连续色块，会误导为单PDU。
解决：在RLC色块内添加小图标：左端画[S]，中间画[C]，右端画[E]。用ax.text()在色块内标注。

4.4 现象：PDSCH热力图显示全RE占用，但实际有CRS/PT-RS等预留资源

原因：5G NR取消CRS，但仍有PT-RS（Phase Tracking RS）和SRS（虽为上行，但slot内需避让）。尤其高频段（mmWave）PT-RS密度高。
解决：查38.211 Table 6.4.1-1，按scs和cp-type确定PT-RS符号位置。在re_grid中将对应RE设为0。

4.5 现象：DCI调度箭头指向PDSCH色块中心，而非首个symbol

原因：k0定义的是slot级偏移，但PDSCH实际从该slot的特定symbol开始。箭头终点若落在色块中心，会掩盖symbol级对齐细节。
解决：箭头终点坐标设为(pdsch_slot, pdsch_start_symbol)，并用ax.plot([dcislot, pdsch_slot], [1, pdsch_start_symbol], ...)画斜线，明确指向起始点。

5. 进阶技巧：用动态参数驱动图形，一键生成多场景对比图

5.1 构建参数化绘图函数：把SCS、TDD pattern、MCS都变成输入变量

硬编码参数无法应对真实需求。我们封装核心函数，支持一键切换场景：

def plot_nr_downlink_flow( scs_khz=30, # 子载波间隔 tdd_pattern='2.5ms', # TDD周期：'2.5ms','5ms','10ms' mcs_index=12, # 调制编码方案索引 k0=1, k1=4, # 调度与反馈时延 tb_size_bits=30000 # 传输块大小 ): # 根据scs_khz动态计算symbols_per_slot等 if scs_khz == 15: symbols_per_slot = 14 slot_duration_ms = 1.0 elif scs_khz == 30: symbols_per_slot = 14 slot_duration_ms = 1.0 elif scs_khz == 60: symbols_per_slot = 14 slot_duration_ms = 0.5 else: # 120kHz symbols_per_slot = 14 slot_duration_ms = 0.125 # 计算PDSCH起始symbol（考虑PDCCH开销） pdcch_symbols = 2 if scs_khz <= 30 else 1 pdsch_start_symbol = pdcch_symbols # 计算TB所需RE数（简化：MCS index→code rate→RE需求） code_rate = {12: 0.37, 15: 0.45, 20: 0.67}[mcs_index] re_needed = int(tb_size_bits / code_rate / 6) # 6 bits per 256QAM RE # 绘图逻辑（略，同前文） ... return fig # 生成对比图：30kHz vs 120kHz fig1 = plot_nr_downlink_flow(scs_khz=30, k0=1, mcs_index=12) fig2 = plot_nr_downlink_flow(scs_khz=120, k0=0, mcs_index=15)

参数说明：

scs_khz：直接影响slot时长和符号密度，是5G部署的基石参数；
k0/k1：网络优化关键——k0=0降低时延但增加gNB负荷，k1=4是底线，k1=6更鲁棒；
mcs_index：映射到实际吞吐量，index20（256QAM）比index12（64QAM）提升约30%频谱效率。

5.2 表格化对比：不同配置下的关键指标差异

配置项	30kHz SCS	120kHz SCS	差异分析
Slot时长	1.0 ms	0.125 ms	高频段需更短slot应对相位噪声
符号数/slot	14	14	符号数不变，但每符号时长缩短
PDCCH符号数	2~3	1~2	高SCS下PDCCH更紧凑，释放更多PDSCH符号
最小k0	0	0	理论可行，但120kHz下gNB处理压力大
典型k1	4	4~6	高SCS下UE解码更快，但上行调度更难

实战价值：当客户问“为什么毫米波基站时延更低”，这张表+对应图形就是最直白的答案——不是算法先进，是scs_khz=120把slot压缩了8倍，所有时序自然收紧。

5.3 导出为矢量图：嵌入LaTeX/PPT的技术文档级交付

PNG截图无法缩放，而工程师需要把图放进论文或方案书。用plt.savefig()导出PDF/SVG：

# 导出高清矢量图 plt.savefig('nr_downlink_flow_scs30.pdf', bbox_inches='tight', dpi=300, format='pdf') # PDF保证LaTeX编译无损 # 或SVG用于网页交互 plt.savefig('nr_downlink_flow_scs30.svg', bbox_inches='tight', format='svg')