51学通信

深度解析 3GPP TS 38.300：5.3 Uplink (上行链路 Part 1 - 传输方案与核心信道)

21分钟阅读

好的，在全面剖析了5G下行链路的“四大基石”和“四大程序”之后，我们现在将视角翻转180度，聚焦于通信链路的另一端——上行链路。UE是如何在gNB的指挥下，将自己的声音和数据，高效、有序、清晰地传递给网络的？这正是本篇文章要探讨的核心。

深度解析 3GPP TS 38.300：5.3 Uplink (上行链路 Part 1 - 传输方案与核心信道)

本文技术原理深度参考了3GPP TS 38.300 V18.5.0 (2025-03) Release 18规范中，关于“5.3 Uplink”的核心章节，具体涵盖5.3.1至5.3.3节。本文旨在为读者深入剖析5G上行链路的基石——多天线传输方案、数据信道（PUSCH）的处理流程，以及承载所有上行反馈的控制信道（PUCCH）。

前言：小明心声的“上天”之路

我们的主角小明，正和远方的家人进行一场高清视频通话。他不仅在流畅地接收对方的画面（下行），同时，他手机的摄像头和麦克风也在捕捉他的音容笑貌，并将这些数据实时地上传到网络中（上行）。对于手机这个电量和功率都极其宝贵的设备来说，上行传输的设计面临着比下行更严峻的挑战。

为了让小明的“心声”能够清晰、高效、省电地“上天”，5G NR的上行物理层设计同样凝聚了无数智慧：

  • 它如何选择最合适的“发声方式”，既能保证声音洪亮，又不过于“嘶吼”浪费体力？（上行传输方案）

  • 他发送的数据包，又是如何被精心“打包”和“加密”，以确保安全、可靠地送达？（PUSCH物理层处理）

  • 当他需要向网络反馈“我听清楚了”（HARQ-ACK）或者“现在的信号质量很好”（CSI）时，又是通过哪条“专属热线”来传递这些简短而关键的信息？（PUCCH）

导师老王再次拿起画笔，准备为小玲和小明揭示这条“上天之路”的秘密。今天，我们就将聚焦于5.3节的前半部分，深入上行链路的核心信道和传输方案。

与gNB强大的多天线阵列和发射功率相比，UE的天线数量和发射功率都非常有限。因此，上行多天线传输的设计，更加注重效率和灵活性。

Two transmission schemes are supported for PUSCH: codebook based transmission and non-codebook based transmission.

5G上行PUSCH支持两种核心的多天线传输方案：

1.1 基于码本的传输 (Codebook based transmission)

这是上行多天线传输的主要模式。在这种模式下，gNB扮演着“指挥家”的角色。

For codebook based transmission, the gNB provides the UE with a transmit precoding matrix indication in the DCI. The UE uses the indication to select the PUSCH transmit precoder from the codebook.

场景代入：

  1. gNB测量“声场”：gNB通过测量UE发送的上行探测参考信号（SRS - Sounding Reference Signal），来感知上行信道的状况。

  2. gNB下发“乐谱”：gNB根据测量结果，从一个3GPP标准化的“预编码码本（Codebook）”中，为UE挑选出一个最合适的预编码矩阵（PMI）。这个码本就像一本包含了各种“发声姿势”的指导手册。gNB会将选定姿势的编号（TPMI - Transmitted Precoding Matrix Indicator），通过下行的DCI信令发送给UE。

  3. UE按“谱”发声：UE收到DCI中的TPMI后，就像看到了指挥家的手势，它从自己存储的同一本码本中，找到对应编号的预编码矩阵，并用它来处理即将发送的PUSCH数据和DMRS。

基于码本的传输，决策在gNB侧，执行在UE侧，实现了网络对UE上行多天线行为的精确控制。

1.2 非基于码本的传输 (Non-codebook based transmission)

这是一种更灵活、但通常性能稍逊的补充模式。在这种模式下，UE拥有了更大的“自由发挥”空间。

For non-codebook based transmission, the UE determines its PUSCH precoder based on wideband SRI field from the DCI.

**SRI（SRS Resource Indicator）**字段会指示UE使用哪个SRS资源进行探测，并根据这个探测结果自行决定预编码方式。这种模式下，UE的自主性更高，但由于gNB无法精确获知UE最终使用的预编码，可能会影响多用户配对和干扰抑制的效果。因此，它更多地用于一些特定场景或作为Codebook模式的补充。

1.3 上行MIMO的车道线：DMRS与层数

与下行类似，上行空间复用也依赖于DMRS来充当“车道线”。

DMRS based spatial multiplexing is supported for PUSCH. Up to 8, 12, 16, and 24 orthogonal UL DMRS ports are supported for type 1, type 2, enhanced type 1, and enhanced type 2 DMRS respectively. For a given UE, up to 4 or up to 8 layer transmissions are supported.

  • 上行层数：根据UE的能力（天线数量），一个UE最多可以支持4个传输层。这意味着小明的手机在信号极好的情况下，理论上可以通过4根天线同时发送4个独立的数据流，上行峰值速率提升4倍。而最新的规范版本甚至开始支持8层上行传输，进一步提升上行能力。

  • 码字：与下行类似，上行1-4层传输使用1个码字，5-8层传输使用2个码字。

1.4 灵活的传输时长与跳频

Transmission durations from 1 to 14 symbols in a slot is supported.

Two types of frequency hopping are supported, intra-slot frequency hopping, and in case of slot aggregation, inter-slot frequency hopping.

  • 灵活时长：5G上行传输的粒度非常灵活，可以是1-14个符号中的任意长度（即所谓的“mini-slot”），为低时延业务提供了保障。

  • 频率跳变：为了获得频率分集增益，对抗频率选择性衰落，PUSCH支持在时隙内或时隙间进行跳频传输。这就像在不同车道间快速切换，以躲避拥堵路段。

2. “上行数据包的铠甲”：PUSCH物理层处理 (5.3.2)

小明视频通话的上行数据包，在离开手机前，同样需要经历一套与下行PDSCH类似但略有不同的“武装”流程。

The uplink physical-layer processing of transport channels consists of the following steps:

这个流程与5.2.2节的下行流程高度对称：

  1. Transport Block CRC attachment

  2. Code block segmentation and Code Block CRC attachment

  3. Channel coding: LDPC coding

  4. Rate matching

  5. Scrambling

  6. Modulation: 上行支持的调制阶数略有不同，例如当开启transform precoding时，支持π/2 BPSK，同时最高支持到256QAM。

  7. Layer mapping, transform precoding (enabled/disabled by configuration), and pre-coding: 这是与下行最大的不同。在上行链路中，UE在层映射之后，可以选择性地插入一个**transform precoding (DFT)**模块。

    • 开启 DFT-s-OFDM：如果开启了transform precoding，那么输出的波形就是低PAPR的DFT-s-OFDM。

    • 使用 CP-OFDM：如果禁用了transform precoding，输出的就是CP-OFDM。

    这个开关由gNB通过RRC信令和/或DCI进行控制。

  8. Mapping to assigned resources and antenna ports

通过这套严谨的流程，UE确保了其上行数据传输的可靠性、安全性，并能在功耗和性能之间取得灵活的平衡。

3. “上行反馈专属热线”：PUCCH物理上行控制信道 (5.3.3)

在视频通话中，小明的手机不仅需要上传音视频数据（走PUSCH），还需要持续地向gNB发送各种简短但至关重要的控制信息。这些信息就通过**PUCCH（Physical Uplink Control Channel）**这条“专属热线”来承载。

Physical uplink control channel (PUCCH) carries the Uplink Control Information (UCI) from the UE to the gNB.

PUCCH承载的上行控制信息（UCI）主要包括三类：

  • HARQ-ACK：对下行PDSCH数据包的确认/否认（ACK/NACK）反馈。这是保证下行可靠传输的关键闭环。

  • CSI (Channel State Information)：信道状态信息，包括CQI/PMI/RI，用于gNB进行下行链路自适应。

  • SR (Scheduling Request)：调度请求。当UE有新的上行数据要发送，但gNB没有为它分配PUSCH资源时，UE会发送一个SR，像举手示意一样，告诉gNB“我有话要说，请给我分配资源”。

PUCCH的多种“格式”

为了高效地承载不同大小的UCI，并适应不同的场景，NR定义了五种不同的PUCCH格式。

Five formats of PUCCH exist, depending on the duration of PUCCH and the UCI payload size:

老王为小玲画了一张简表来总结：

| 格式 (Format) | 特点 | 主要用途 |

|---|---|---|

| Format #0 | 短PUCCH (1-2符号), 基于序列选择 | 承载1-2比特的小负载UCI (如单个ACK/NACK, SR)，支持多用户复用。 |

| Format #1 | 长PUCCH (4-14符号), 基于序列选择 | 承载1-2比特的小负载UCI，但通过长序列获得更好的覆盖。 |

| Format #2 | 短PUCCH (1-2符号), QPSK调制 | 承载大于2比特的中等负载UCI (如多个ACK/NACK)。 |

| Format #3 | 长PUCCH (4-14符号), BPSK/QPSK调制 | 承载大负载UCI (如完整的CSI报告)，不支持多用户复用。 |

| Format #4 | 长PUCCH (4-14符号), QPSK调制 | 承载中等负载UCI，同时支持有限的多用户复用。 |

这种多样化的格式设计，体现了NR在设计上的精细权衡：

  • 长短结合：短PUCCH时延低，适合URLLC场景；长PUCCH覆盖好，适合小区边缘用户。

  • 负载适配：从1比特的SR到几百比特的CSI报告，都有最高效的承载格式。

  • 复用与性能的权衡：格式0、1、4支持多用户在相同的时频资源上复用，提升了控制信道容量；而格式2、3则追求单用户的传输性能。

UCI的复用与优先级处理

当多种UCI需要在同一时刻发送时，比如UE vừa要反馈HARQ-ACK，又要上报CSI，网络如何处理？

UCI multiplexing in PUCCH is supported when PUCCH transmissions of UCIs coincide in time…

UCI multiplexing in PUSCH is supported when UCI and PUSCH transmissions coincide in time…

  • PUCCH上的复用：如果多个UCI都分配在PUCCH上发送，它们会被一起编码，在一个PUCCH资源上传输。

  • PUSCH上的复用（Piggyback）：如果一个UCI的发送时刻，恰好有一个被调度的PUSCH传输，那么这个UCI通常会“搭便车”，与PUSCH数据一起复用在PUSCH资源上传输，而不是单独占用一个PUCCH资源。这样做可以节省功耗和控制信道开销。

此外，为了支持URLLC和eMBB的共存，NR还引入了UCI的优先级。高优先级的UCI（如URLLC业务的HARQ-ACK）可以抢占低优先级的UCI传输，确保关键业务的反馈得到优先保障。

总结：高效、稳健、灵活的上行设计

通过对5.3节前半部分的深入剖析，我们清晰地看到了5G NR上行链路设计的核心思想：在保证可靠性的前提下，最大限度地为UE省电、提升覆盖，并提供极致的灵活性。

  1. 传输方案：通过码本/非码本模式和DFT-s-OFDM/CP-OFDM的灵活切换，实现了网络控制与UE自主、覆盖与性能之间的平衡。

  2. PUSCH处理：对称于下行的严谨处理流程，确保了上行数据传输的可靠性与安全性。

  3. PUCCH设计：通过长短格式结合、多种负载适配和灵活的复用机制，为所有上行反馈信息构建了一个高效、分层的“专属热线”系统。

在下一篇文章中，我们将继续探讨5.3节的后半部分，聚焦于上行链路的“自适应巡航系统”——上行物理层程序，包括随机接入、链路自适应、功率控制、时序控制和HARQ等，看看UE是如何在实际运行中动态调整自己的“发声”方式的。

FAQ

Q1：为什么上行传输方案中，gNB需要通过SRS来测量信道，而不是像下行那样由UE直接反馈信道信息？

A1：这是由信道互易性原理决定的。在TDD（时分双工）系统中，上下行使用相同的频段，其无线信道在短时间内是互易的，即gNB到UE的下行信道，与UE到gNB的上行信道非常相似。因此，gNB通过测量UE发送的上行SRS，就可以很好地推断出下行信道的状况，从而为UE选择合适的下行预编码（PMI）。反之，gNB也可以利用这个原理，通过测量上行SRS来为UE选择合适的上行预编码。而在FDD（频分双工）系统中，上下行信道不互易，gNB依然需要测量上行SRS来了解上行信道，为UE选择上行预编码。总而言之，SRS是gNB感知上行信道的“眼睛”。

Q2：什么是调度请求（SR）？它和缓冲区状态报告（BSR）有什么关系？

A2：SR和BSR是UE请求上行资源的两种核心机制，通常协同工作。SR (Scheduling Request) 是一个简单的“举手”信号，它是一个1比特的信息（有或没有），通过PUCCH发送。当UE的缓冲区从空变非空，且当前没有可用的PUSCH资源时，它会发送SR，告诉gNB“我需要资源”。BSR (Buffer Status Report) 则是一个更详细的报告，它告诉gNB每个逻辑信道组（LCG）里具体有多少数据在排队等待发送。BSR通过MAC CE在PUSCH上传输。

关系是：UE发送SR触发gNB为其分配一个小的PUSCH资源，UE再利用这个小的PUSCH资源上报详细的BSR，gNB看到BSR后，才了解UE到底有多少数据要发，从而为其分配一个大小合适的、用于传输真正数据的PUSCH资源。

Q3：UE为什么需要发送PUCCH？它承载的UCI信息为什么不都“搭车”在PUSCH上发送以节省资源？

A3：UE必须要有PUCCH，因为在很多情况下，UE只有控制信息（UCI）要发，而没有数据（PUSCH）要发。例如，gNB只给UE发送了下行数据，UE需要反馈HARQ-ACK，但此时UE并没有上行业务数据。如果没有PUCCH，UE就无法反馈这个关键的ACK信息。虽然在UCI和PUSCH同时发生时，UCI会优先“搭车”（piggyback）到PUSCH上，但PUCCH作为一条独立的、始终可用的上行控制信道，是保证上下行链路闭环控制（HARQ, CSI）正常工作的必要条件。

Q4：PUCCH的多种格式是如何被选择的？

A4：PUCCH格式的选择是由gNB通过RRC信令为UE半静态配置的。gNB会为UE配置一个或多个PUCCH资源集（PUCCH-ResourceSet），每个资源集里包含多个PUCCH资源。每个资源都与一种特定的PUCCH格式、时频位置、序列等参数绑定。当UE需要发送特定类型和大小的UCI时，它会根据3GPP定义的规则，从这些预配置的资源中选择一个来发送。例如，发送SR时可能选择格式0的某个资源，发送一个小的HARQ-ACK Codebook时可能选择格式2的资源，而发送一个大的CSI报告时则选择格式3或格式4的资源。

Q5：在上行传输中，UE如何知道自己应该用多大的功率来发送PUSCH或PUCCH？

A5：UE的上行发射功率是通过一个复杂的闭环+开环功率控制机制来决定的。开环部分：UE会根据一个gNB配置的目标接收功率、以及自己估算的路径损耗（Pathloss，通常通过测量下行参考信号RSRP得到）来计算一个基础发射功率。闭环部分：gNB会持续测量UE上行信号的接收质量，并通过PDCCH上的**TPC（Transmit Power Control）**指令，对UE的发射功率进行“微调”（增加或减小）。这个“开环粗调+闭环精调”的机制，确保了UE的发射功率既能保证gNB侧的接收质量，又不会过高而对邻居小区造成不必要的干扰，同时最大限度地节省了手机电量。我们将在下一篇文章中详细探讨这个过程。

关系图谱