最近在做5G小基站DU侧的FPGA实现，OFDM符号同步用了循环前缀相关法，仿真时AWGN信道没问题，但拿到现网多径环境下一测试，时延谱一大同步偏差就飙到好几个采样点，解调性能掉得厉害。领导让我先别急着换算法，从工程实现上找兜底方案。我想到的是加粗同步搜索窗、做多径能量合并，或者用双滑动窗互相校验，但不确定哪个性价比高。有没有实际在基站或直放站项目里调过同步的工程师，说说你们遇到多径时延大的时候，除了换算法，在FPGA工程上是怎么做鲁棒性兜底的？比如AGC策略、同步位置后处理、还是联合CPE估计一起弄？
6 个回答
先别急着动AGC和同步搜索窗，个人感觉你这个问题大概率出在相关峰被多径扯平了，而不是窗不够宽。最便宜的兜底是先把同步位置的输出做一级中值滤波，连续取三到五个符号的粗同步结果，取中间值再去触发FFT窗口。多径时延大时相关峰会抖，但通常不会连续好几个符号都往同一个方向偏，中值滤波能干掉大部分单点跳变。这个改动在FPGA里就是几级移位寄存器和比较器，资源几乎为零，建议先上这个看眼图有没有改善。如果还不行，再考虑把同步位置和信道估计的时延谱峰值对齐，用信道估计输出的最强径位置去修正同步点，这个要动一下后续模块的接口，但比换算法省事多了。你目前滑动窗用的是固定长度还是自适应的？
既然领导不让换算法，那就把工程兜底拆成两段来想：一段是让同步偏差不要发生，另一段是让偏差发生之后不影响解调。第一段里，AGC是很多人忽略的坑，大时延下如果前端增益被强径压得太狠，弱径的循环前缀相关贡献就全部淹没在量化噪声里，你算出来的相关峰实际只反映了最强径的位置，偏差自然大。可以试着把AGC的收敛目标从峰值功率改成平均功率，或者加一个慢环路，让增益在小数点后两位的精度上慢慢调，别让瞬时峰值把增益拽下去。第二段里，同步位置出来后别直接硬切FFT窗，把窗的起点往后挪几个采样点，宁可丢一点循环前缀的抗干扰余量，也要保证FFT窗不跨过符号边界。多径时延大时CP本来就被污染了，硬保CP前段没意义，反而容易把下一个符号的头部卷进来。另外你说的双滑动窗互相校验，我做过类似的东西，但实际效果取决于两窗的间距怎么设，间距小于最大时延扩展就是白做，建议你拿信道探测数据先扫一遍典型时延谱再定参数。你现网测试时有没有同时抓过信道估计的时延谱？那个数据对定参数很关键。
你这个问题我猜很多做小基站DU的人都撞过，循环前缀相关法在多径下的本质缺陷是：它把CP和OFDM符号尾部的相关性当成一个单峰来检测，但多径信道下每个径都会贡献一个自己的相关峰，这些峰在时延域上叠加，主峰旁边会出现一堆旁瓣，甚至主峰本身会被拉宽、削平。你看到同步偏差好几个采样点，大概率是检测器锁到了某个强旁瓣上，而不是真正的首径或能量重心。
既然不让换算法，工程上最有效的兜底其实是把同步问题和信道估计联合起来做闭环。具体思路是：粗同步仍然用CP相关，但只用来确定一个粗略的搜索区间，区间宽度覆盖最大时延扩展加保护裕度；然后在这个区间内用已知的参考信号或DMRS做细同步，用信道估计输出的时延谱找到能量最强的径或者首径位置，用这个位置去修正FFT窗起点。这个做法在5G NR里其实很自然，因为PSS/SSS和DMRS本来就是现成的，而且信道估计模块你已经有了，不需要新增大的IP。关键是FPGA里的时序安排：粗同步结果要能缓存几个符号的IQ数据，给细同步留出处理时间，这个存储开销在DU侧通常能接受。
你提到的多径能量合并，我个人觉得性价比不高，因为CP相关本身就是在合并所有径的能量，问题不是能量不够，而是能量分布不均匀导致的峰形畸变。与其在时域上做加权，不如把精力放在同步位置的后处理上。具体说，可以做一个滑窗能量重心计算，在粗同步峰附近取一个窗口，窗口长度约为最大时延扩展，然后计算窗口内相关能量谱的重心位置作为最终同步点。这个重心对多径分布不敏感，比直接取峰值鲁棒得多，而且实现上就是一组乘加和累加器，比双窗校验更可控。
最后提醒一个容易忽略的点：同步偏差大不一定全是同步模块的锅，也可能是前端下变频或滤波器的群时延在宽带信号下不恒定，导致不同频率分量到达时间不一致。你可以在测试时把信号带宽降一半看偏差是否成比例缩小，如果是，那问题可能出在模拟前端而不是数字同步。这个排查只要改一下测试配置就能做，建议先试。你们DU用的是哪个厂商的射频前端？群时延指标看过没？
其实个人感觉你先别急着上双滑动窗，那个调参够你折腾一周。多径时延大时CP相关峰被拉平，最便宜的兜底是把同步结果先过一级中值滤波，取连续三五个符号的中间值再触发FFT窗，FPGA里就是几级移位寄存器的事。这个能干掉大部分单点跳变，先看眼图有没有改善再说别的。你滑动窗现在用的是固定长度还是自适应的？
说一个很多人忽略的坑：AGC。大时延下如果前端增益被强径压得太狠，弱径对CP相关的贡献全淹没在量化噪声里，你算出来的峰实际只反映最强径，偏差自然大。可以把AGC收敛目标从峰值功率改成平均功率，或者加个慢环路，让增益在小数点后两位的精度上慢慢调，别让瞬时峰值把增益拽下去。另外同步位置出来后别硬切FFT窗，把窗起点往后挪几个采样点，宁可丢一点CP的抗干扰余量，也要保证窗不跨符号边界。多径时延大时CP前段本来就被污染了，硬保没意义。这个改动在工程上比加搜索窗见效快，你试过看AGC的实时增益曲线吗？
做小基站DU的同步兜底，我建议把问题拆成两段想：让偏差不发生，和发生之后不影响解调。第一段里，除了AGC，还有个容易忽略的点是滑动窗长度要跟着时延谱自适应。固定窗在时延扩展大时，窗口前段全是噪声、后段又截断多径尾巴，相关峰自然糊。可以粗同步后先估一下信道时延扩展，动态把搜索窗从CP长度扩展到CP加最大时延扩展，FPGA里就是查表换一组累加器系数，代价不大。第二段才是关键，同步位置出来后别直接信它，拿信道估计结果做校验：在粗同步给出的区间内搜DMRS或参考信号的时延谱，找首径或能量重心，用这个位置去修正FFT窗起点。这个闭环在5G NR里其实很自然，因为PSS/SSS和DMRS本来就要做信道估计，等于把同步从开环变成带反馈的，多径再大也能咬住。代价是同步模块和信道估计模块之间要多拉一根总线，时序上要留几个符号的流水延迟，但比换算法省事多了。另外建议你在仿真里加一个两径信道模型，第二径延迟设成CP长度的百分之七八十，先复现一下现网现象，确认到底是峰选错还是窗跨边界，再决定动哪块。你们现在同步模块和信道估计是分开跑的，还是已经能共用中间结果了？
发表回答
登录后可在本页底部提交回答