简介这份资料围绕LTE物理上行控制信道PUCCH符号的产生展开面向从事4G无线通信协议研究、链路级仿真与基带开发的工程师及研究生帮助理解PUCCH的结构、格式与发送方式。包内共32个文件以17个m脚本和7个asv备份文件为核心覆盖PUCCH调制解调、Zadoff-Chu序列生成、循环移位、信道编码与QPSK映射等环节另附4个doc、2个docx与2个pdf参考文档涉及36.211/36.212协议及LTE-A深入解析压缩包约18.13MB。已有339人学习下载。读者可借助脚本对照协议梳理PUCCH Format 1/2/2a/2b的产生流程结合文档理解资源分配、调制方式与解码思路为仿真验证和排错提供可运行的参考实现。1. 从一份“符号产生”需求说起PUCCH 到底在基带里干了什么做 LTE 上行基带的人迟早会撞上 PUCCH。它不像 PUSCH 那样有明确的业务数据要搬也不像 PRACH 那样只在接入时露个脸PUCCH 是那种“平时不显山露水、一旦配错就整条链路掉话”的信道。标题里“物理上行控制信道符号的产生”这句话落到工程上就是一件事把 UCI上行控制信息——SR、HARQ-ACK、CSI——按协议规定的序列生成、加扰、调制、扩频、映射到分配的 RB 上最后吐出一串可以交给 IFFT 的频域符号。很多刚接手的人以为 PUCCH 就是“填几个比特”真跑起来才发现格式不同、序列不同、跳频不同符号产生的路径完全不一样。这篇笔记就按我实际做过的顺序把 PUCCH 符号产生的选型、参数、代码骨架和踩过的坑讲清楚适合正在做上行基带、需要把 PUCCH 从协议文本落到可运行代码的工程师。2. PUCCH 格式选型与符号产生的整体链路2.1 先分清五种格式再谈符号怎么产生LTE 的 PUCCH 不是一种东西协议里定义了 format 1/1a/1b、format 2/2a/2b、format 3后来还有 format 4/5载波聚合场景。符号产生的第一步不是写代码而是确认你面对的是哪种格式因为它们的产生逻辑差异极大。Format 1/1a/1b 走的是“频域序列 时域正交码”的路子。它用一条长度 12 的基序列base sequence做循环移位再叠加一个长度为 4 或 3 的时域正交序列OCC把多个用户的控制信息复用在同一组 RB 上。Format 2/2a/2b 同样用长度 12 的基序列但循环移位后直接承载 QPSK 调制符号不再叠加时域 OCC因为它要传的 CSI 比特更多。Format 3 则是把比特做 DFT 预编码后再映射本质上是把 PUSCH 的那套 SC-FDMA 思路搬过来用来承载更大的 HARQ-ACK 载荷。选型判断的实操标准很简单先看 UCI 比特数。12 比特的 SR/HARQ-ACK 走 format 1a/1bCSI 走 format 2HARQ-ACK 超过 2 比特但没到 format 3 的门限可能走信道选择channel selection再大就走 format 3。这个判断决定了后面所有代码分支。2.2 符号产生的通用流水线不管哪种格式PUCCH 符号产生都可以拆成一条流水线UCI 比特生成与编码HARQ-ACK 可能要做 RM 编码或咬尾卷积编码CSI 做咬尾卷积编码加扰用小区 ID 和时隙号生成的伪随机序列调制QPSK 为主format 1a/1b 的 ACK 用 BPSK/QPSK序列生成与循环移位format 1/2 系列时域正交码扩频format 1/1a/1bDFT 预编码format 3资源映射到分配的 RB 和符号位置跳频处理时隙间跳频或时隙内跳频这条流水线里第 4 步和第 5 步是 PUCCH 区别于 PUSCH 的核心也是最容易翻车的地方。下面用 Python 把 format 1a 的符号产生骨架写出来其他格式可以在此基础上改分支。import numpy as np def gen_base_sequence(group_hop, seq_hop, length12): 生成 LTE PUCCH 长度 12 的基序列简化版实际需查协议表 group_hop: 组跳频编号 u seq_hop: 序列跳频编号 v 返回: 长度 12 的复数序列 # 协议中基序列由 Zadoff-Chu 序列扩展得到这里用查表法示意 # 实际工程中会预存 30 组基序列按 u,v 索引 base_table np.exp(1j * np.pi * np.arange(length) * (np.arange(length) 1) / length) return base_table def cyclic_shift(seq, alpha): 对基序列做循环移位 alpha: 循环移位量由 PUCCH 资源索引和 OCC 决定 n len(seq) shift int(round(alpha * n / (2 * np.pi))) % n return np.roll(seq, shift) def gen_pucch_format1a(ack_bit, sr_flag, cell_id, slot_num, n_pucch, delta_shift1): 生成 format 1a 一个时隙的频域符号 ack_bit: HARQ-ACK 比特0 或 1 sr_flag: 是否携带 SR cell_id: 小区 ID slot_num: 时隙号 n_pucch: PUCCH 资源索引 delta_shift: 循环移位间隔配置 # 1. 确定循环移位量 alpha # format 1a 的 alpha 由 n_pucch 和 OCC 索引共同决定 n_cs n_pucch % 12 alpha 2 * np.pi * n_cs / 12 # 2. 生成基序列并循环移位 base gen_base_sequence(0, 0) shifted cyclic_shift(base, alpha) # 3. 调制ACK 用 BPSK映射到 d(0) # 协议规定 ACK 为 1 时 d(0)1为 0 时 d(0)-1简化 d 1 if ack_bit 1 else -1 if sr_flag: d d * 1 # SR 与 ACK 叠加时的处理实际需按协议表 # 4. 频域符号 d * 循环移位后的序列 freq_symbols d * shifted # 5. 时域 OCC 扩频在后续 IFFT 前的符号级处理 # format 1a 一个时隙有 7 个 SC-FDMA 符号其中 4 个用于数据 # OCC 长度为 4索引由 n_pucch 决定 occ_idx (n_pucch // 12) % 3 occ_table { 0: np.array([1, 1, 1, 1]), 1: np.array([1, -1, 1, -1]), 2: np.array([1, 1j, -1, -1j]) } occ occ_table[occ_idx] # 6. 映射到 4 个数据符号位置示意实际还要考虑参考信号位置 slot_symbols np.zeros((7, 12), dtypecomplex) data_positions [0, 1, 5, 6] # 一个时隙内数据符号的索引 for i, pos in enumerate(data_positions): slot_symbols[pos, :] occ[i] * freq_symbols return slot_symbols这段代码里几个关键点需要说明。gen_base_sequence在真实工程中不会用公式现算而是预存协议定义的 30 组基序列按组跳频编号 u 和序列跳频编号 v 查表因为协议里的基序列是计算机搜索出来的没有简单闭式。cyclic_shift的移位量 alpha 由 PUCCH 资源索引 n_pucch 和循环移位间隔 delta_shift 共同决定delta_shift 是小区级参数配置为 1、2、3 时可用的循环移位数量不同直接影响能复用多少用户。occ_table里的三个正交序列是 format 1/1a/1b 能支持多用户复用的关键OCC 索引由 n_pucch 除以 12 后取模得到这意味着同一个 RB 内最多可以塞 3 个用户每个用户占 4 个循环移位中的一组。参数配置上delta_shift是最容易配错的一个。它决定了循环移位之间的间隔间隔越小能支持的循环移位越多但抗时延扩展能力越差。常见做法是普通城区场景配 delta_shift2高速场景配 delta_shift1 或 3具体要看小区半径和时延扩展预算。2.3 资源映射与跳频的实操细节符号产生完之后要映射到物理 RB 上。PUCCH 的 RB 分配不是连续的而是位于系统带宽两端且时隙间跳频。映射时要注意两个参数N_RB_2format 2 系列可用的 RB 数和N_CS_ANformat 1 系列可用的循环移位数。这两个参数由高层信令配置直接决定了 PUCCH 资源索引到物理 RB 的映射公式。跳频处理上PUCCH 支持时隙间跳频inter-slot和时隙内跳频intra-slot。时隙间跳频是默认行为两个时隙分别映射到带宽两端时隙内跳频则是在一个时隙内的两个 RB 之间跳。做符号产生时跳频是在资源映射阶段处理的不影响前面的序列生成和调制。我一般会在资源映射函数里用一个hop_flag参数控制避免把跳频逻辑散落到各个格式分支里。3. 用 Python 跑通 PUCCH format 1a 符号产生的最小验证3.1 搭建可复现的验证环境验证 PUCCH 符号产生是否正确最直接的办法是看星座图和自相关特性。环境只需要 Python 3.8、NumPy 和 Matplotlib不需要任何通信库。我习惯把验证脚本分成三部分参数配置、符号产生、可视化检查。import numpy as np import matplotlib.pyplot as plt # 参数配置 cell_id 1 slot_num 0 n_pucch 5 delta_shift 2 ack_bit 1 sr_flag 0 # 调用符号产生函数 slot_symbols gen_pucch_format1a(ack_bit, sr_flag, cell_id, slot_num, n_pucch, delta_shift) # 可视化画出 4 个数据符号位置的频域星座 fig, axes plt.subplots(1, 4, figsize(16, 4)) data_positions [0, 1, 5, 6] for i, pos in enumerate(data_positions): axes[i].scatter(slot_symbols[pos, :].real, slot_symbols[pos, :].imag, s20) axes[i].set_title(fSymbol {pos}) axes[i].set_xlim(-1.5, 1.5) axes[i].set_ylim(-1.5, 1.5) axes[i].grid(True) plt.tight_layout() plt.savefig(pucch_format1a_constellation.png)跑完这段你会看到四个数据符号位置上的星座点都落在单位圆上且相位随循环移位量旋转。如果星座点散乱或者幅度不对说明循环移位或 OCC 扩频有问题。这个检查方法比对着协议逐行核对快得多是我常用的第一道筛子。3.2 用自相关验证循环移位是否正确循环移位的正确性可以用自相关来验证。对生成的频域序列做 IFFT 后循环移位会表现为时域上的延迟。如果移位量正确自相关峰值应该出现在预期的延迟位置上。# 取第一个数据符号的频域序列 freq_seq slot_symbols[0, :] # 做 IFFT 得到时域序列 time_seq np.fft.ifft(freq_seq) # 计算自相关 corr np.correlate(time_seq, time_seq, modefull) corr np.abs(corr) peak_idx np.argmax(corr) - (len(time_seq) - 1) print(f自相关峰值位置: {peak_idx}) print(f预期循环移位量: {n_pucch % 12})如果峰值位置和预期循环移位量对不上先检查cyclic_shift函数里的取整逻辑。协议里的循环移位量是连续值但实际实现时只能取离散的整数移位这个取整误差在 delta_shift 较小时会变得明显。我一般会在取整前加一个四舍五入而不是直接截断。3.3 参数扫描delta_shift 对符号的影响delta_shift 改变时循环移位的间隔跟着变直接影响频域序列的相位分布。写一个简单的扫描脚本把 delta_shift 从 1 扫到 3观察星座点相位的变化。for ds in [1, 2, 3]: symbols gen_pucch_format1a(1, 0, 1, 0, 5, ds) phase np.angle(symbols[0, 0]) print(fdelta_shift{ds}, 第一个符号相位{phase:.3f} rad)这个扫描能帮你快速建立参数和结果的对应关系。实际调参时delta_shift 的选择还要结合小区半径和高速场景下的多普勒扩展不能只看星座图好看。4. PUCCH 符号产生的避坑与排查记录4.1 坑一循环移位取整导致用户间干扰现象多个用户的 PUCCH 在同一 RB 上复用解调时误码率明显高于预期星座点有拖尾。原因cyclic_shift函数里用int(round(...))取整时如果 delta_shift 配置为 1相邻用户的循环移位间隔只有 1 个采样点取整误差会让两个用户的序列不再正交。解决在 delta_shift1 的场景下改用更精确的相位旋转而不是整数移位。具体做法是把基序列乘以exp(1j * alpha * n)其中 n 是采样索引这样移位量是连续的不依赖取整。4.2 坑二OCC 索引计算时忽略了 n_pucch 的范围现象format 1a 的 OCC 扩频后某些 n_pucch 值对应的符号功率异常甚至出现全零。原因OCC 索引用(n_pucch // 12) % 3计算但 n_pucch 的有效范围由高层配置的N_CS_AN决定。如果 n_pucch 超出范围取模后的索引可能落到未定义的 OCC 上。解决在符号产生函数入口加一个范围检查n_pucch 必须小于N_CS_AN * 12简化关系。超出范围时直接报错而不是静默取模。4.3 坑三跳频标志没传到资源映射层现象时隙间跳频配置下两个时隙的符号都映射到了同一个 RB跳频没生效。原因符号产生函数只负责生成频域序列资源映射在另一个模块里做跳频标志没有从配置层透传到映射层。解决把跳频标志作为参数一路传到资源映射函数并在映射函数里根据时隙号选择 RB 偏移。我一般会在配置结构体里加一个hopping_mode字段所有涉及资源位置的函数都从这个字段读。4.4 坑四加扰序列的初始化时机不对现象不同子帧的 PUCCH 解调结果不一致某些子帧误码率突然升高。原因加扰序列的初始化用到了时隙号和小区 ID但代码里在多个地方重复初始化导致同一个时隙内不同符号用了不同的加扰序列。解决加扰序列的初始化只在每个时隙开始时做一次把生成的扰码序列缓存起来后续符号复用。不要在符号级循环里反复调用初始化函数。4.5 坑五format 3 的 DFT 预编码点数搞错现象format 3 的符号产生后频谱形状不对带外泄漏明显。原因DFT 预编码的点数应该等于分配的 RB 数乘以 12但代码里误用了固定点数。解决DFT 点数必须动态计算等于n_rb * 12。同时注意format 3 的符号产生里DFT 之后还要做资源映射映射位置和 format 1/2 不同不能复用同一套映射逻辑。5. 把符号产生做成可复用的验证框架5.1 用参数化配置覆盖所有格式做到后面你会发现每种格式单独写一个函数会越来越难维护。更好的做法是把符号产生的公共步骤抽出来用配置驱动分支。下面这个配置结构体是我常用的骨架from dataclasses import dataclass dataclass class PucchConfig: format_type: int # 1, 1a, 1b, 2, 2a, 2b, 3 cell_id: int slot_num: int n_pucch: int delta_shift: int n_rb: int # 分配的 RB 数 hopping_mode: str # inter_slot 或 intra_slot sr_flag: int ack_bits: list # HARQ-ACK 比特列表 csi_bits: list # CSI 比特列表 def gen_pucch_symbols(cfg: PucchConfig): 统一的 PUCCH 符号产生入口按 format_type 分支 if cfg.format_type in [1, 1a, 1b]: return gen_format1_family(cfg) elif cfg.format_type in [2, 2a, 2b]: return gen_format2_family(cfg) elif cfg.format_type 3: return gen_format3(cfg) else: raise ValueError(f不支持的 PUCCH 格式: {cfg.format_type})这个骨架的好处是新增格式时只需要加一个分支函数公共的加扰、调制、映射逻辑可以复用。参数说明上n_rb对 format 1/2 通常固定为 1对 format 3 可以是 1 到 12 之间的值hopping_mode决定资源映射时的 RB 偏移计算方式。5.2 用误码率回环验证符号产生符号产生对不对最终要看解调结果。搭一个简单的回环产生符号 → 加高斯白噪声 → 解调 → 统计误码率。这个回环不需要完整的接收机只需要把符号产生的逆过程实现一遍。def awgn(symbols, snr_db): 加高斯白噪声 snr_linear 10 ** (snr_db / 10) power np.mean(np.abs(symbols) ** 2) noise_power power / snr_linear noise np.sqrt(noise_power / 2) * ( np.random.randn(*symbols.shape) 1j * np.random.randn(*symbols.shape)) return symbols noise def demod_format1a(rx_symbols, n_pucch, delta_shift): format 1a 的简化解调返回 ACK 比特 # 取第一个数据符号做循环移位的逆操作 base gen_base_sequence(0, 0) alpha 2 * np.pi * (n_pucch % 12) / 12 shifted cyclic_shift(base, alpha) # 相关解调 corr np.sum(rx_symbols[0, :] * np.conj(shifted)) return 1 if corr.real 0 else 0 # 回环测试 cfg PucchConfig(format_type1, cell_id1, slot_num0, n_pucch5, delta_shift2, n_rb1, hopping_modeinter_slot, sr_flag0, ack_bits[1], csi_bits[]) tx gen_pucch_symbols(cfg) errors 0 for snr in range(0, 15, 2): rx awgn(tx, snr) ack demod_format1a(rx, cfg.n_pucch, cfg.delta_shift) if ack ! cfg.ack_bits[0]: errors 1 print(fSNR{snr}dB, 解调 ACK{ack}, 误码累计{errors})这个回环能帮你快速定位符号产生里的相位或幅度问题。如果低 SNR 下误码率异常高先检查循环移位的方向是否和解调端的逆操作一致——这是最常见的翻车点移位方向搞反了星座图看着正常但解调全错。5.3 一个容易忽略的细节参考信号符号的位置PUCCH 的参考信号符号位置和 PUSCH 不同。Format 1/1a/1b 在一个时隙的 7 个 SC-FDMA 符号里参考信号占第 2、3、4 个索引从 0 开始是 1、2、3数据占其余 4 个。Format 2/2a/2b 的参考信号占第 1、4 个索引 1、4数据占其余 5 个。做符号产生时参考信号符号不承载 UCI但要用和 data 符号相同的基序列和循环移位生成只是不乘调制符号。我见过有人在参考信号位置也乘了 d结果解调端信道估计直接崩掉。提示参考信号符号的生成可以复用数据符号的序列生成函数但要把调制符号置为 1且 OCC 扩频对参考信号的处理和数据符号不同format 1 的参考信号用长度为 3 的 OCC数据用长度为 4 的 OCC。5.4 验证框架的扩展方向这套框架搭好之后可以往两个方向扩展。一是加进多用户复用场景模拟多个 n_pucch 同时产生符号验证正交性二是加进信道模型比如 EPA/EVA/ETU看符号产生在时变信道下的鲁棒性。我一般会先用理想信道跑通再逐步加损伤这样出问题时能快速定位是符号产生本身的问题还是信道处理的问题。做 PUCCH 符号产生这件事最深的教训是协议文本里的公式看着清楚但落到代码里取整、索引范围、初始化时机这些细节才是决定成败的地方。我现在的习惯是每写一个格式的符号产生先不急着跑完整链路而是用星座图和自相关把序列生成和循环移位单独验证一遍确认无误再往上叠调制和映射。这个习惯帮我省下了大量在整链路里大海捞针的时间。希望帮到你。本文还有配套的精品资源点击获取