企业官网建设流程全解析

简介：面向OFDM系统的资源分配优化场景，这里提供一套基于贪婪算法的Matlab实现与说明文件。资源定位于无线通信方向的学生与算法研究者，适合已经掌握OFDM基础、希望借助实际代码理解贪婪算法在子载波分配和功率控制中局部最优决策策略的读者。压缩包共2个文件，核心是一个m脚本，完成初始化、按信噪比排序的贪心选择、功率迭代分配以及误码率或吞吐量评估等流程；另一个txt文档补充理论背景与代码使用说明，可辅助快速上手。整个包体仅896B，轻量精简，便于下载后直接运行和二次修改。该资源已有180人学习，具有一定实践参考价值。通过研读代码，读者可以直观看到贪婪算法如何在多子载波环境下权衡资源，并在此基础上结合其他优化策略进一步改善系统性能。

1. 在OFDM里用贪婪算法，先要弄清楚资源分配在解决什么问题

很多人看到"贪婪算法"第一个反应是它有一个固定现成的函数，但放到OFDM场景里，它并不是某个工具箱里可以直接调用的小工具，而是一种逐比特、逐子载波的资源分配策略。OFDM系统把整个频带切成几十到上千个正交子载波，不同子载波上的信道增益和噪声方差都不一样，基带处理侧就需要决定：每个子载波用几比特调制，分配多少发射功率，才能在目标误码率下拿到尽量高的吞吐量。

贪婪算法处理的正是这个离散化的资源分配问题。它从0比特开始，每一轮只挑"增加1比特所需额外功率最小"的那个子载波，把它的调制阶数提高一级，重复直到总速率达标或总功率用完。这种做法的复杂度远低于穷举和动态规划，结果又接近最优，所以常被拿来做链路级仿真、吞吐量基准和预研阶段的快速验证。

这篇文章从OFDM的IFFT/FFT原理讲起，给一个能在Matlab里直接跑通的最小实现，再讲三个关键参数怎么调、两个常见坑在哪里，最后用两个低成本方法验证算法没有写错。适合正在做物理层仿真、通信算法毕设或5G预研的人参考。

2. OFDM资源分配为什么要用贪婪算法：从注水定理到离散比特表

2.1 先看OFDM的基带模型：子载波、信道增益和噪声

OFDM调制的基本做法是，发送端把频域符号序列通过IFFT变成时域波形，接收端用FFT再解回来，配合循环前缀抵消符号间干扰。只要保护间隔足够长、子载波间正交性保持得好，这N个子载波就可以拆成N个并行的窄带子信道来独立处理。所谓ofdm原理里的"并行传输"，本质是让每个子载波自己在频域上衰落，而不是整个宽带信号一起深衰落。

接收端在第k个子载波上拿到的信号可以写成：

y_k = H_k x_k + n_k

这里H_k是第k个子载波上的复信道增益，包含了路径损耗、阴影和频率选择性衰落；n_k是零均值复高斯噪声，实部和虚部方差各为sigma2/2。因为子载波之间已经解耦，资源分配就变成：在每个子载波上根据|H_k|^2和噪声方差，决定用几比特调制以及给多大功率。

OFDM的IFFT/FFT这一层解决的是怎么把数据放到并行子载波上，真正决定每个子载波能承载多少比特的，是信道估计给出来的H_k和噪声方差。因此在做贪婪算法之前，先要把这部分输入准备好。同步、循环前缀、频偏估计都正常工作时，剩下的问题才是纯资源分配。

2.2 注水定理是理论下限，离散比特却让问题变成组合优化

如果允许每个子载波使用任意连续速率，并且目标是在总功率约束下最大化总速率，经典结论是注水定理。最优功率分配是：

p_k = max(mu - sigma2 / |H_k|^2, 0)

mu由总功率约束决定。信道好的子载波分到更多功率，信道差的子载波可能不分功率。注水定理给出的是连续容量域的理论解，但在实际OFDM系统里不能直接用，因为调制阶数是离散的：BPSK是1比特，QPSK是2比特，16QAM是4比特，64QAM是6比特，不可能给某个子载波分配3.7比特。

一旦限制每个子载波只能从有限集合里选调制阶数，这个问题就从凸优化变成了组合优化。做一个最简单的估计：64个子载波，每个子载波有7种可能（0到6比特），组合数是7^64，穷举完全不可行。更麻烦的是，不同调制阶数达到相同目标误码率所需的SNR并不相同，存在一个门限，分配时不能只看信道增益，还要看每一级调制对应的SNR增量。

这时候如果硬套连续注水，再四舍五入到离散调制阶数，会带来两个问题：一是舍入方向不好控制，二是总功率约束容易在边界上被破坏。比较稳妥的做法是把问题重新表述为：在总速率和总功率约束下，选择一组离散比特数和对应发射功率，使总发射功率最小，或使总速率最大。

2.3 贪婪算法的选型理由：为什么不是穷举或动态规划

贪婪算法的思路非常直接：从所有子载波都是0比特开始，每次扫描所有还能再增加1比特的子载波，计算"给它加这1比特需要额外付出多少发射功率"，然后选出额外功率最小的那个子载波加1比特。这个过程重复到达到目标速率，或者总功率预算耗尽。

这个过程本质上是一种以边际成本递增为原则的调度。因为每次加的都是当前全局最小的代价，前几步的分配质量非常高。随着比特数增多，每个子载波的边际代价也在上升，系统会自动避开信道较差的子载波，把比特集中到信道好的子载波上。这跟注水定理刻画的方向是一致的。

几种典型方法对比如下：

在实际工程里，N经常是64、128甚至更大，动态规划的内存和时间开销都很难接受；而贪婪算法每一轮只需要扫描一次N，总共扫描target_bits轮，复杂度在毫秒级。再加上实现简单，调试时可以直接观察每个子载波的比特分配过程，所以它成了OFDM资源分配里最常见的一套基准方案。

这里还有一个很容易被忽略的点：贪婪算法给出的是比特分配，不是直接给出发射功率。发射功率在分配完成后需要按各子载波所需SNR来反推，或者做整体功率归一化。这部分在下一章的Matlab实现里会一起处理。

3. 用Matlab把贪婪比特和功率分配写成可运行的最小实现

3.1 构造OFDM子载波信道和噪声的仿真输入

写Matlab实现时，第一步不是堆代码，而是把输入参数定义清楚。我在工程里一般先确定N为子载波数，H为复数信道增益向量，sigma2为每子载波上的噪声功率。信道可以是频率选择性衰落的仿真结果，也可以是实测估计值；噪声功率则取决于带宽、接收机噪声系数和子载波间隔。

下面这段代码生成一个最简单但能说明问题的输入：

N = 64; % 子载波数 H = (randn(1,N) + 1j*randn(1,N)) / sqrt(2); % 复高斯信道，平均功率为1 sigma2 = 0.1; % 每个子载波上的噪声功率 snr = abs(H).^2 / sigma2; % 无发射功率时的等效SNR

这里的H是频域信道估计结果，每个元素是复数，abs(H).^2才是功率增益。randn生成的实部和虚部各自除以sqrt(2)，是为了让E[abs(H)^2] = 1，方便后续门限参数和发射功率保持同数量级。sigma2取0.1，意味着在平均信道增益为1时，一个单位发射功率能得到10dB左右的SNR。

在实际仿真里，H来自信道估计模块，而不是随机生成；但输入格式是一样的。snr这个变量在调试时很有用，可以一眼看出哪些子载波本来就差，哪些子载波有潜力被贪婪算法选中。

3.2 贪婪比特加载主循环：按边际信噪比逐步加比特

接下来是核心循环。我采用一种非常常见的离散比特加载模型：达到某误码率所需SNR门限近似为：

snr_req(b) = gamma * (2^b - 1)

gamma是SNR gap，反映编码调制和误码率距离香农极限的差距。从b-1比特提升到b比特，所需额外SNR增量为：

inc_snr(b) = gamma * 2^(b-1)

这个增量是线性的，意味着越往上加比特，边际代价越贵，正好符合贪婪算法想要的"递增边际成本"。

主循环代码如下：

% 参数定义 target_bits = 128; % 目标总比特数，可以改成你想仿真的负载 max_bits = 6; % 单个子载波最大比特数，对应64QAM gamma = 2.0; % SNR gap，未编码QAM常用1.5~2.5 b = zeros(1,N); % 每个子载波当前分配的比特数 % 预计算从0到max_bits每一步所需SNR增量（线性值） inc_snr = @(b_new) gamma * 2.^(b_new - 1); % 先确认目标速率不可能超过上限 if target_bits > N * max_bits error('目标比特数超过全部子载波最大承载能力'); end % 贪婪主循环 while sum(b) < target_bits extra_power = inf(1,N); % 存放每个子载波加1比特的额外功率 for k = 1:N if b(k) < max_bits % 额外功率 = 额外SNR / (信道增益 / 噪声功率) extra_power(k) = inc_snr(b(k)+1) / (abs(H(k)).^2 / sigma2); end end [~, idx] = min(extra_power); % 找最小边际功率的子载波 b(idx) = b(idx) + 1; % 给它加1比特 end

这段代码的逻辑是：每次循环先扫描所有子载波，计算如果给某个子载波加1比特，发射功率要额外增加多少。信道好、当前比特数低的子载波，extra_power就小，更容易被选中。min(extra_power)取了全局最小值，所以这个算法严格遵循"每次做代价最小的提升"。

inc_snr(b_new)这个函数要特别注意：当b_new=1时，它表示从0比特跳到1比特需要的SNR，是gamma；当b_new=6时，它表示从5比特跳到6比特需要的SNR，是32*gamma。这个指数增长关系是自然的，因为64QAM比QPSK需要高得多的SNR才能维持相同误码率。

如果目标速率定得过高，比如target_bits = N*max_bits，那么每个子载波都会被填满，贪婪算法实际上没有选择空间，结果就是平均分配。这种情况不会报错，但说明负载已经逼近系统容量边界，继续提高速率需要更大的调制阶数或者更低的gamma。

3.3 比特分配完成后的功率归一化与BER验证

贪婪算法输出的b只是比特分配，还需要计算每个子载波需要多少发射功率。功率的计算根据SNR门限反推：

p_k = snr_req(b_k) * sigma2 / |H_k|^2

如果总功率超过预算，就把所有子载波功率按相同比例缩放。缩放后会有一部分子载波达不到门限，实际误码率会升高，所以工程上一般会预留功率余量，不要让分配结果总是顶在功率上限上。

snr_req = @(bb) gamma * (2.^bb - 1); % 所需SNR，线性值 P_alloc = snr_req(b) .* sigma2 ./ (abs(H).^2); % 实际所需发射功率 P_budget = 128; % 总功率预算 if sum(P_alloc) > P_budget scale = P_budget / sum(P_alloc); P_alloc = P_alloc * scale; fprintf('[警告] 总功率超限，已等比缩放为原来的 %.2f%%\n', scale*100); end % 显示前8个子载波的分配结果，用于核对 for k = 1:8 fprintf('子载波%2d: 比特=%d, 功率=%.4f\n', k, b(k), P_alloc(k)); end

这套功率计算方式有一个隐含假设：每个子载波独立解调，子载波之间没有互干扰。只要OFDM的循环前缀设置合理，这个假设成立。如果后面要做的不是单用户点对点链路，而是多用户OFDMA调度，那么还需要在贪婪循环之前先做子载波分配，不能直接用这套代码处理多用户竞争。

功率归一化之后，可以做一次完整的调制加噪解调来验证BER。具体做法是对每个子载波根据b(k)选择调制阶数，发射功率乘以信道，加上复高斯噪声，再除以信道增益完成均衡，最后判决。这里需要Communication Toolbox的qammod和qamdemod，也可以用自定义映射函数代替。第一次跑通时不要急着看平均BER，先把每个子载波的调制阶数、发射功率和接收SNR打印出来，和分配结果互相印证。

4. 把贪婪算法调稳的3个参数和2个易踩的坑

4.1 参数1：单次步进的SNR门限

贪婪循环里的inc_snr函数决定了每加1比特需要多高的SNR，它由gamma放大。gamma取得越大，比特增长需要的功率就越贵，同样总功率下分配的总比特数就越少，误码率也更低；gamma取得过小，看起来吞吐上去了，但实际调制阶数根本无法支撑目标误码率，BER直接飘红。

未编码QAM在误比特率10^-4左右时，gamma一般在1.5到2.5之间。如果系统里加了LDPC或Turbo编码，gamma可以适当下调，因为编码增益会降低对SNR门限的要求。我一般先把gamma设为2.0跑一轮，再用实际调制解调循环测BER，如果BER低于目标，则每轮降低0.1重新仿真，直到BER接近目标，这样得到的gamma就是当前链路条件下的工程值。

不要试图从一本书里抄一个固定的gamma在所有场景里用。gamma会随目标BER、编码方式、调制阶数轻微变化，但在大多数方案设计阶段，取一个固定近似值做资源分配相对排名是够用的。

4.2 参数2：目标速率与子载波最大比特数

max_bits决定了调制阶数的上限。WiFi、LTE这类系统通常支持到64QAM，也就是6比特；新的标准里也有256QAM，对应8比特。max_bits设得越高，每个子载波能堆的比特越多，但高调制阶数对SNR和相位噪声更敏感，还需要更高的功率来支撑，同时峰值平均功率比也会变大，功放的线性回退要求更高。

target_bits的选择更直接。它应该落在系统能支持的速率区间内，也就是0到N*max_bits之间。如果太接近上界，贪婪算法会发现所有子载波都已经加满比特，最后几轮只能往已经很差的子载波上继续堆，边际功率高得离谱。此时观察P_alloc会发现个别子载波功率异常大，这不是算法bug，而是负载率设置过高。

调试时可以加一条保护判断：如果所有子载波都到max_bits，但sum(b)仍然小于target_bits，说明目标速率超出能力，直接报错并提醒降低target_bits或增大max_bits。

这里有一个值得说的细节：贪婪算法并不保证每个子载波的功率都低于某个单载波功率限制。如果系统对单载波有功率上限，需要在循环里增加约束条件，把超过上限的子载波排除掉。加了这种约束后，算法复杂度不变，但某些边缘子载波会被迫放弃。

4.3 参数3：信道估计误差的裕度

真实系统里，H是由导频信号估计出来的，信道估计本身有误差，而且信道在时变。贪婪算法特别依赖信道排序的准确性，因为它会把比特集中到看起来SNR最高的几个子载波上。如果估计值偏高，实际分配功率就不够，那些子载波的实际BER就会恶化；如果估计值偏低，又会让信道好的子载波闲置。

处理办法是在计算extra_power时给信道增益乘一个惩罚系数：

% 对信道估计误差做保守修正 H_eff = H * (1 - est_error); % est_error=0.1 表示认为估计值偏高10% extra_power(k) = inc_snr(b(k)+1) / (abs(H_eff(k)).^2 / sigma2);

est_error这个裕度参数一般取5%到15%。它不改变贪婪算法的结构，只是让排序略微偏向信道更稳的子载波。加入这个修正后，性能波动会变小，尤其在做衰落信道下的蒙特卡洛仿真时特别明显。

有时也可以在噪声功率上做文章，把sigma2增大10%再分配，效果类似。两者结合容易过度保守导致吞吐下降，选一个就行。

4.4 易踩的坑：实虚部功率不匹配

Matlab没有强制区分复数功率和实虚部功率，写代码时很容易把复数信道的功率算错。比如有人想取实部虚部分别计算，会写成real(H).^2 + real(H).^2，忘了第二个应该是imag(H)。这种错误在单路径仿真里可能不明显，因为复高斯信道的实部虚部统计相同，但换成确定性信道模型或实测信道后就完全对不上。

我的习惯是统一用abs(H).^2计算功率增益。如果你确实需要手工检查，可以直接对比：

power1 = abs(H).^2; power2 = real(H).^2 + imag(H).^2; max_abs_err = max(abs(power1 - power2)); % 应接近0

这个检查在写完信道生成代码后跑一次，能省下很多后面排查的时间。

4.5 易踩的坑：把OFDM符号数当成迭代次数

贪婪算法处理的是相干时间内的信道快照。只要信道在连续几个OFDM符号内基本不变，资源分配结果就可以被重复使用，不需要每个符号都重新跑一遍贪婪循环。有些初学者会把主信道矩阵构造成三维，第一维是OFDM符号数，然后在每个符号索引上重新分配，实际上这是在低移动性场景里做了大量无用计算。

正确的做法是先判断信道变化速度。慢衰落下每帧更新一次资源分配，把b和P_alloc当成帧级别的公共变量；快衰落到每个符号信道都剧烈变化时，才需要每符号更新，但那时也意味着信道估计本身可能已经不准了。如果你用的是Simulink做链路级验证，可以对照Simulink中ofdm调制解调模块的使用示例，看它把资源分配放在哪个处理阶段，通常是在每帧的导频估计之后、数据符号调制之前。

5. 怎么验证贪婪算法没写错：用零载荷反推和边缘速率对照

写完贪婪算法后，最容易让人心里没底的是：我选的这个子载波到底对不对？代码里min那一行是不是挑错了方向？这里给两个不依赖第三方库的验证方法，只需要提前知道结果，用来反推算法内部有没有系统性错误。

第一个方法是平坦信道零载荷反推。把信道设置成所有子载波增益完全一致：

H = ones(1,N); sigma2 = 1; target_bits = 128;

在这个条件下，所有子载波初始状态完全相同，那么贪婪算法应该把比特尽可能均匀地分配到64个子载波上。因为每个子载波增加1比特的代价完全一致，循环会均匀打点，128个比特分配到64个子载波上，结果应该是50个子载波2比特，14个子载波3比特，比特数差值最多为1。如果你运行完发现有些子载波是0比特，有些是5比特，说明循环里对SNR或者功率的计算存在不对称误差，去检查abs(H).^2和sigma2能不能对上号。

第二个方法是边缘速率对照。把贪婪算法得到的比特分配和连续注水公式对比，不需要精确相等，但趋势要一致。用Matlab优化工具箱求一下连续条件下的最优功率分布，再换算成等效比特log2(1 + snr)，把结果和贪婪分配画在同一个子载波索引坐标里。信道好的子载波两边都应该有更高的比特数和功率，信道差的子载波两边都应该趋向0。如果发现贪婪算法在一个明显深衰点还是给了4比特，那通常不是算法问题，而是target_bits设置太高导致无路可退，检查一下负载率是不是接近满负荷。

最后可以做一个更严苛的自洽检查：把贪婪算法分出来的P_alloc回代到snr_req公式里，计算出每个子载波的理论SNR，再从Matlab自带调制函数里找对应BER曲线。算出来的BER和目标BER相差一个数量级以内就说明资源分配和调制参数匹配；如果差三个数量级以上，说明gamma和实际调制阶数严重不匹配，别急着怪算法。把gamma往低调一档再跑一遍，同时观察总功率归一化的缩放比例，如果缩放比例小于50%，说明初始分配结果大概率偏乐观，需要保留更多功率余量。

本文还有配套的精品资源，点击获取