首页
/
行业洞察
/
正文
INDUSTRY INSIGHT · 深度
块级DFT预编码OQAM:融合FBMC与SC-FDMA的上行波形方案
📅 2026/10/18 5:03:09
✍️ 爱科研究院
👁 阅读 3,247
说实话做上行波形的人这几年都有点“精神分裂”一边是终端厂商天天吵着PAPR太高、功放回退太多、电池撑不住一边是频谱资源越来越碎、又希望调制方式能把每一Hz都榨干还要求URLLC场景下时延不能拖后腿。我这次折腾的方案就是想把滤波器组多载波FBMC的偏移正交幅度调制OQAM和单载波频分多址SC-FDMA这两条技术路线缝合起来做一个“块级DFT预编码的OQAM系统”。写这篇东西的初衷很朴素把我从仿真到硬件原型验证中遇到的问题、踩过的坑、以及最后拿到的一组对比数据整理出来给正在做波形选型和物理层算法验证的同行一个参考。1. 拆开两个“旧”波形到底是谁缺了谁1.1 FBMC-OQAM谱效率漂亮但终端很不舒服FBMC-OQAM这个方向其实一点都不新学术界聊了十几年。它的核心思路是用一组高选择性的原型滤波器把每个子载波频谱压得非常窄再通过OQAM实部虚部错开半个符号周期的技巧让相邻子载波之间可以重叠却不互相干扰。这样做的好处非常直接不需要循环前缀CP就能把多径时延扩展吸收掉带外泄漏极低可以在非连续频谱碎片上部署。单从频谱利用率角度讲它比CP-OFDM天然多出大约百分之六到七的吞吐还不算保护带的节省。但问题非常现实FBMC-OQAM本质上还是多个子载波在时域叠加叠加的结果就是时域信号的峰值很高。我实测下来QPSK子载波数300CCDF取10^-3峰值平均功率比PAPR通常在10.5~11dB之间和CP-OFDM一个水平比单载波系统高出4dB以上。这个数字对基站无所谓对手机终端就很要命功放为了不进入饱和区只能把工作点往回退相当于发射机的大部分效率被浪费掉电池寿命和覆盖能力一起受损。除此之外FBMC-OQAM的滤波器组重叠也会带来处理时延。原型滤波器长度一般取重叠因子K乘以符号周期K4的时候滤波器要跨越4个OQAM符号周期发射和接收各有一段滤波边缘延迟。多径信道下还要做复杂的干扰消除同步偏差比OFDM敏感得多这也是它一直停留在论文里的原因。1.2 SC-FDMA把功放喂饱了却把谱优势丢了SC-FDMA准确说LTE和5G NR上行用的DFT-S-OFDM则走了完全相反的路。它在发射端先把一组QAM复数符号做一次DFT预测编码再映射到子载波上做IFFT。这样时域信号在统计特性上更接近单载波包络起伏被大幅度抑制PAPR比OFDM低3dB以上功放回退可以明显减小。LTE当年选择它作为上行波形最重要的原因就是照顾终端功耗和发射功率这个决策到今天依然正确。但DFT-S-OFDM的短板同样明显它离不开循环前缀每个符号都要付出大约7%的时间开销在深度频率选择性信道里DFT扩展会把频率选择性衰落扩散到整个数据块上接收端均衡后噪声增强比较明显。而且这种波形本质上还是OFDM的亲戚带外泄漏依然需要比较大的保护带子载波映射的灵活性也不够好。换句话说它缺的不是功率效率而是频谱层面能挤出来的那一部分效率以及对非连续频谱场景的适应能力。1.3 融合的切入点在OQAM正交网格上做DFT扩展既然FBMC-OQAM有谱效率、缺功率效率SC-FDMA有功率效率、缺谱灵活性最自然的想法就是把SC-FDMA里的DFT预编码环节搬到OQAM发射机里数据符号先经过DFT扩展获得“单载波化”的频域分布然后再拆成实部虚部交错序列映射到连续的子载波上最后经过合成滤波器组形成发送波形。滤波组取代循环前缀DFT预编码压制时域峰值OQAM交错保住子载波正交性三者各干各的事。这里有个容易误解的点这不是简单地把DFT-S-OFDM的IFFT换成滤波器组而是整个调制网格都变了。OQAM每个子载波每半个符号周期只传一个实值符号相邻子载波在同一时刻分别承载实部和虚部这种“时频网格”上的正交条件需要专门的滤波器设计和均衡策略不能拿OFDM那套直接套。2. 发射机与接收机怎么搭一个块级DFT预编码的OQAM系统2.1 发射链路从QAM符号块到滤波器组输出的完整信号流以我搭建的仿真发射机为例信号流是这样一个顺序数据比特先做信道编码和交织然后映射成QPSK或16QAM的复数符号流。每B个复数QAM符号凑成一个预编码块做B点DFT。这一步和DFT-S-OFDM一样作用是把这个块里的每个符号“摊”到整个块频带上。把DFT输出的B个频域复数符号按本地映射方式分配到B个连续活动子载波上其他子载波置零。进入OQAM调制环节。每个子载波上的复数频域符号被拆成实部和虚部在相邻两个OQAM实符号位置上分别发送时间上错开T/2。这样B个复数符号变成了2B个实值符号但整个块的时间长度仍然是B乘一个OFDM符号周期T。所有子载波上的实值符号经过合成滤波器组也就是把每个符号乘以原型滤波器的频移版本再叠加起来得到基带发送信号。如果把发射链路用一句话概括DFT预编码管“压低PAPR”OQAM拆分管“保住子载波正交”滤波器组管“去掉CP并且压低带外辐射”三者顺序不能颠倒。我最初试过把DFT放到OQAM拆分之后去做发现行不通因为实值序列的DFT结果在频域里会引入共轭对称约束白白浪费一半频谱。所以DFT必须在QAM复数域完成这是整个系统成立的前提。2.2 接收链路频域均衡、虚部干扰消除与逆DFT的先后次序接收端的设计决定了这个方案能不能真正落地。基本流程是分析滤波器组把接收信号分解回时频网格然后做信道估计和均衡再提取实值符号最后通过逆DFT还原QAM符号。其中最关键的一步是频域均衡FDE要放在逆DFT之前。原因和DFT-S-OFDM一致信道在每个子载波上的增益不同均衡要先针对各子载波做一次幅度相位补偿然后再通过逆DFT把预编码块合并否则3dB功率增益和频率分集特性都会丢掉。我试过先逆DFT再做时域均衡结果在TDL信道下性能差了接近2dB教训相当深刻。OQAM部分还有一个绕不开的“固有干扰”问题。在无信道失真时相邻子载波和相邻符号对当前时频点的干扰是纯虚部的因为实部判决时把它们投影掉就行。但多径信道会破坏这种精巧的正交结构让虚部干扰泄漏到实部判决里。这个问题的处理手段有几种最常见的是在数据块里嵌入辅助导频辅助导频本身发送一个纯虚符号专门用来吸收相邻位置的干扰接收端再根据信道估计重构干扰并扣除。实测下来加上辅助导频并做一次迭代干扰消除之后EVM能稳定控制在5%以内。2.3 一组可直接用于仿真的具体参数下面这组参数是我用来跑链路仿真的基准配置取值贴近5G NR上行场景方便和现有波形做横向对比参数取值系统带宽5 MHzFFT点数512子载波间隔15 kHz符号周期T66.67us活动子载波数300DFT预编码块尺寸B4 / 8 / 16调制方式QPSK、16QAM原型滤波器重叠因子K4对比时也测了K3原型滤波器系数K4典型值[1.0, 0.97196, 0.7071, 0.23515]信道模型AWGN、TDL-C时延扩展约300ns关于表格里的原型滤波器系数需要说明一下这组经典系数来自重叠因子为4的常规设计直接在仿真里使用即可。K4时滤波器长度是4T带外抑制最好但延迟和实现复杂度也最高。我在延迟敏感场景下会切到K3代价是邻近子载波泄漏大概增加5~8dB换来大约三分之一滤波延迟的下降。这个取舍没有标准答案取决于系统是追求ACLR还是追求单跳时延。3. 三项硬指标的实测数据PAPR、谱效率、时延3.1 PAPR的CCDF对比3dB改善来自哪里PAPR是最直观的指标我自己跑CCDF曲线互补累计分布函数时对四个波形做了统一配置QPSK、300个子载波、随机数据符号、CCDF纵轴取10^-3处读数。波形方案PAPR10^-3QPSKPAPR10^-316QAMCP-OFDM10.6 dB10.9 dBFBMC-OQAM10.8 dB11.2 dBDFT-S-OFDMSC-FDMA7.0 dB7.8 dBDFT预编码OQAM本方案7.3 dB8.6 dB本方案比原生FBMC-OQAM在QPSK下低了3.5dB和DFT-S-OFDM只差0.3dB基本保住了SC-FDMA的核心优势。16QAM下差距拉到0.8dB原因也不难理解高阶调制下每个符号本身的瞬时功率波动就更大DFT扩展能压制的只是“多子载波叠加”那部分峰值压制不了星座点自身的包络变化。这也是所有单载波类波形的共性。为什么DFT扩展能把PAPR降下来直观理解是这样OFDM/FBMC里每个子载波独立承载一个符号时域信号是几百个独立随机变量求和按中心极限定理趋近高斯分布自然容易出现大尖峰而DFT预编码等于先把一批符号打散到整个频带时域上每个瞬间都同时包含所有数据符号的贡献信号的包络就接近单载波调制的特性峰值被概率性地拉低。需要注意一个细节映射方式对PAPR影响很大。我用的是本地连续映射也就是B个DFT输出放到B个连续的物理子载波上兼容性好、便于频域调度如果换成均匀交织映射PAPR还能再低0.5dB左右但调度和复用就很麻烦实用性差。除非有专门的多用户交织需求否则不建议为了零点几dB牺牲调度灵活性。3.2 去掉CP省出来的谱效率算一笔细账谱效率提升不需要复杂的推导直接算开销就行。15kHz子载波间隔下OFDM正常CP大约4.69us每个符号总长度约71.4usCP占比约6.6%再加上保护带、调度空隙整体波形开销在7%~10%之间。FBMC-OQAM没有CP代价是滤波器重叠但重叠是多径容限的一部分不占有效符号速率块传输时只需要在数据块的边缘预留少量已知符号做滤波收敛实际开销可以控制在1%~2%。我按5MHz带宽、64QAM、编码速率0.5的配置估算过同样10ms的无线帧CP-OFDM大约能传9.3ms的有效数据本方案大约能传9.8ms净吞吐提升接近5.4%。如果再把带外泄漏带来的保护带节省算进去比值会更可观。在碎片化频谱场景里FBMC-OQAM类波形的优势不会被CP开销吃掉这正是当初选它做底座的核心理由。开销项CP-OFDMDFT-S-OFDM本方案循环前缀开销约7%约7%无块边界/滤波收敛开销无无约1%~2%带外泄漏抑制能力一般需保护带一般需保护带优秀保护带可大幅缩减3.3 端到端时延拆解滤波器长度没想象中可怕说到FBMC很多人的第一反应是“滤波器那么长时延肯定高”。这其实有点被放大了。OQAM的实符号间隔是T/2也就是33.3us滤波器总长度即便到4T也只是266us而且这部分不是全部变成端到端时延只有滤波边缘的建立和收尾阶段会计入额外延迟。我用B8、K4的配置拆解过端到端基带时延块内调度时间约B×T533us发射端滤波边缘约(K-1)T/2100us接收端滤波边缘约100us再加均衡和逆DFT处理约50us合计约0.78ms。这个数字和5G NR一个1ms时隙长度相比并不吃亏。如果切到B4、K3块内时间降到267us两端滤波边缘降到约67us总时延可以压到0.4ms以内已经能满足相当一部分低时延业务的需求。时延和PAPR之间存在直接交换B越大DFT扩展效果越好但块内累积时延越高B越小时延越低但预编码增益也会削弱。B4时PAPR只比B8高0.6dB左右多数场景我都用B4或B8B16只在信道特别差、需要更强频率分集时才用。4. 从仿真到硬件原型之前必须先跨过的那些坑4.1 原型滤波器系数的截断与重叠因子选择滤波器设计是FBMC类方案绕不过去的第一道坎。仿真的第一版我直接用了无限精度浮点系数指标很好看但一转到定点模型问题立刻冒出来系数截断到16位以后带外泄漏ACLR性能掉了近10dB视窗内的干扰水平也不稳定。原因是原型滤波器每个抽头都在参与整个频段的成形系数量化误差会直接反映为频谱波形的微小纹波OQAM的正交性对这些纹波相当敏感。建议从一开始就把滤波器系数按目标位宽量化后再做性能评估。重叠因子K的选择也要提早考虑K4适合频谱受限场景K3适合时延受限场景不要指望一个滤波器打天下。如果系统需要在两种模式间切换滤波器系数表建议做成LUT直接切换避免在线计算滤波器值硬件实现能省不少逻辑资源。4.2 OQAM固有干扰在非理想信道下的处理辅助导频的用法与功率补偿OQAM在多径信道下的虚部干扰泄漏是所有这类系统最麻烦的问题。只有AWGN信道下实虚干扰才完美正交一旦信道在相邻时频位置间引入了相位差虚部就会污染实部判决。辅助导频法是最实用的手段在数据符号周围放置特定的纯虚导频符号让它去“吸收”相邻数据的干扰接收端重构干扰后减掉。这样做的代价是每个辅助导频占掉一个虚部自由度大约造成3%~5%的导频开销。实战里最容易犯的错是忘记给辅助导频做功率补偿。干扰项的大小取决于信道响应和原型滤波器重叠系数如果不按对应子载波的信道增益对辅助导频功率做归一化边界子载波的EVM会突然恶化1~2dB看起来像滤波器的锅实际上是辅助导频功率配比不对。我后来把辅助导频的功率设为数据集上按信道响应动态缩放问题就消失了。4.3 相位噪声、多普勒和定时偏差这三个“隐形杀手”FBMC-OQAM比OFDM更怕相位噪声。在OFDM里相位噪声主要转化为公共相位误差和少量ICI在OQAM里相位噪声会破坏实虚正交性让相邻符号的原始干扰从“纯虚部”变成“实虚混合”而且这种污染很难通过线性均衡完全消除。我测试了相位噪声电平-90dBc/Hz1kHz的场景16QAM下EVM直接翻倍。对策是接收端必须加公共相位误差跟踪环最好辅助导频本身带有已知相位参考以便逐符号修正残余相位。多普勒频移则是另一个维度。DFT预编码块越大块内信道时间变化越明显会造成子载波间干扰。我在模拟350km/h移动场景时发现B16的块已经出现明显性能损失把B降回8配合接收端的一阶信道插值BLER就恢复到了可接受范围。定时偏差对无CP系统的影响也很直接OFDM的CP能吸收一部分定时误差这里只能靠精确同步和滤波器边缘的已知符号来兜底因此同步模块的设计余量要给足。4.4 接收机兼容性能复用多少现有OFDM基带模块如果要在现有基带芯片里塞进这套接收机好消息是大部分FFT/滤波基础设施能复用的。分析滤波器组可以用多相滤波结构实现归根到底是一堆FFT和复数乘积累加真正的差异在于OQAM的实虚维度取舍、均衡器和逆DFT之间的顺序这两处必须重新设计。我的经验是把接收机分成两大块一块是“波形无关”的通用处理AGC、同步检测、信道估计接口直接沿用现有框架另一块是“OQAM相关”的时频解映射和干扰消除单独做成可配置模块。这样在协议演进时改动范围可以限定在物理层基带的一个子系统内风险比推倒重来低很多。5. 仿真验证的完整链条和一个结论5.1 仿真链路配置信道模型、均衡方案和统计方法我的仿真环境分三层浮点链路负责算法验证定点模型负责评估量化和时延第三层是硬件描述语言实现来的寄存器级模型只验证一小段关键流程。链路配置沿用前面表格里的基准参数信道模型加了AWGN和TDL-C两种其中TDL-C的时延扩展取300ns用来模拟市区常规环境。均衡方案固定为MMSE频域均衡加辅助导频干扰消除。PAPR统计采用至少100万个随机符号块每个块独立随机生成避免数据相关性和块边缘效应对CCDF尾部造成偏差。这里要特别提一句统计PAPR时滤波边缘的瞬态符号必须去掉否则会高估峰值出现的概率前几版仿真数据就是这样“虚胖”的。5.2 四个波形的关键指标排出座次汇总一下几个典型配置下的仿真对比数据指标CP-OFDMDFT-S-OFDMFBMC-OQAMDFT预编码OQAMPAPR10^-3QPSK10.6dB7.0dB10.8dB7.3dB波形开销约7%约7%约1%约1%~2%带外泄漏ACLR相对值基准基准2dB基准-20dB基准-18dBAWGN下16QAM链路损失0.1dB0.2dB0.3dB0.4dBTDL-C下16QAM EVM均衡后4.7%5.1%6.9%5.4%端到端基带时延估算1.0ms1.0ms0.85ms0.78msB8,K4这张表已经能说明问题DFT预编码OQAM牺牲了与最高谱效率方案之间零点几个dB的链路余量换来了PAPR的大幅下降和可接受的带外特性同时它保留了FBMC无CP的谱优势又把时延控制到了比OFDM类方案更低的水平。对上行链路来说这三项组合起来的综合性价比是四个方案里最均衡的。5.3 我自己在验证过程中反复踩的几个低级坑第一个坑是块边界符号处理。OQAM信号是重叠结构数据块的最后一个符号会“拖”到下一个块的时间窗口里。如果直接在块边界把信号截断PAPR统计和频谱模板都会异常。正确做法是在块边界加已知填充符号让滤波器有完整的建立和收敛过程。我第一次做的时候偷懒没填ACLR实测和仿真对不上查了整整两天才发现是这个问题。第二个坑是DFT尺寸和子载波映射不一致。DFT点数必须等于映射到连续子载波上的个数中间若插入了置零子载波预编码矩阵就被破坏了接收端逆DFT之后会出现周期性误差。这个问题在OFDM时代不存在所以很容易惯性犯错。第三个坑从仿真转硬件的时候才暴露定点化后逆DFT和均衡模块的中间结果位宽不同导致部分子载波出现固定的偏置误码率曲线在高SNR下出现地板。后来把所有中间变量统一成同一标度再加了饱和保护地板就消失了。这类问题只有在定点RTL验证阶段才会浮出水面所以建议算法团队一定要提前做定点模型别等全部浮点跑完了再回头。5.4 关于这个方案我最后想说的话做完整套验证之后我的态度比较明确这套DFT预编码OQAM方案不打算去和OFDM抢主舞台它的身位在上行链路、在功率受限的终端、在频谱碎片化场景里。FBMC-OQAM给的是谱效率和灵活性SC-FDMA给的是功放友好和调度兼容DFT预编码把两者接在一起代价是接收机要做额外的一层干扰处理但整体复杂度并没有失控。给已经在电气和射频层做波形评估的同行一个具体建议别急着把仿真链路调得无比漂亮先跑通PAPR和时延的联合曲线分清哪种参数组合能同时守住“PAPR不超过8dB”和“单跳基带时延不超过0.5ms”两条线再决定要不要往硬件方向深入。就我目前的实测数据看B4、K3、本地映射这套配置是可以同时摸到这两条线的少数几组参数之一。
📌 标签:
工业官网
设计趋势
AI 建站
SEO
获取完整报告 →
RELATED ARTICLES
推荐阅读
2026/10/18 4:58:09
【AI开发】Skill 介绍与实践 —— 用 C++ 实现简易 skill 并接入 TaoToken
2026/10/18 4:58:09
Java城堡游戏项目实战:从面向对象设计到命令模式扩展
2026/10/18 4:58:09
Linux启动过程全解析:从GRUB到systemd的排障实战
2026/10/18 6:03:13
Playwright Trace Viewer:自动化测试的完整证据链
2026/10/18 6:03:13
C语言strlen函数深度解析:原理、陷阱与性能优化
2026/10/18 6:03:13
AI智能体项目实战记录(05):RAG项目实战之向量知识库milvus部署
2026/10/18 6:03:13
PCA 的降维陷阱:数学最优,现实灾难
2026/10/18 6:03:13
技嘉网卡驱动下载,用对方法十分钟就能恢复网络
2026/10/18 5:58:12
基于Matlab的储能优化配置:灵活性供需不确定性建模与求解
2026/10/18 0:02:43
OpenResearch实战:Claude Code、Codex、OpenCode、Cursor 工作流搭建与故障排查
2026/10/18 0:02:43
知识管理核弹:用Obsidian构建第二大脑的工程化方案(TaoToken 统一 Key 接入版)
2026/10/18 0:02:43
金融AI落地指南:从调研报告到技术选型与工程实践
2026/10/18 0:02:43
OpenResearch实战:Claude Code、Codex、OpenCode、Cursor 工作流搭建与故障排查
2026/10/18 0:02:43
知识管理核弹:用Obsidian构建第二大脑的工程化方案(TaoToken 统一 Key 接入版)
2026/10/18 0:02:43
金融AI落地指南:从调研报告到技术选型与工程实践
2026/10/17 10:15:50
我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频
2026/10/16 18:46:48
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证
2026/10/16 18:46:46
2026 大模型集体涨价:用 Python 做企业 Token 成本测算与选型避坑(附配置)