NOMA与OFDMA仿真对比:原理、代码与避坑指南

发布时间:2026/10/22 3:12:31

NOMA与OFDMA仿真对比:原理、代码与避坑指南 简介面向无线通信与5G/NOMA研究方向学生、科研人员的MATLAB仿真资源围绕NOMA非正交多址接入与OFDMA正交频分多址的对比及融合展开帮助理解功率域复用、子载波分配、多用户检测与系统误码率评估。压缩包共13个文件以.m脚本为主体配合1个.mat数据文件总体约156KB涵盖OFDM收发、NOMA/OFDMA编解码、Turbo编译码及BER仿真等模块代码结构清晰便于直接运行和调整参数。已有381人学习下载对入门级到中高级研究人员均有参考意义。通过主仿真脚本可快速复现两种接入方案的误码率对比曲线结合数据生成与编码模块深入掌握用户配对、功率分配及干扰管理的关键设计同时为在OFDMA子载波上叠加NOMA用户的混合方案提供了可扩展的仿真框架适合作为论文验证或课程设计的起点。1. 这一包仿真代码其实是在算一张通信资源的账拿到「NOMA-OFDMA-SIM」这个压缩包不用急着解压看代码。先想清楚标题在问什么同一段频谱到底按 OFDMA 那种“一个用户一块子载波、互不打扰”的方式分还是按 NOMA 那种“大家一起发、在功率上做文章”的方式叠前者是 LTE 时代一路走来的成熟方案后者是 5G 时代被反复拿出来做对比研究的多址候选。这个 zip 包里的仿真核心就是让你在同一个无线信道模型下把两种方案的频谱效率、用户公平性、接收机复杂度放在一组曲线上做对比。适合谁用一类是正在做无线通信课程设计或者毕设的学生另一类是想评估 NOMA 值不值得往自己系统里引的工程师。压缩包能回答的不只是“谁快谁慢”而是“凭什么快、在什么条件下快、快的那部分是从哪里挤出来的”。2. 正交与功率域OFDMA 和 NOMA 的底层逻辑2.1 OFDMA 的“频率独占”思路为什么在密集场景吃亏OFDMA 的核心是正交。系统把整段带宽切成一堆互相正交的子载波再把子载波分组分配给不同用户。对接收机来说每个用户只需要在自己那块频带上做解调用户之间不存在能量上的互相干扰所以接收机里的干扰消除模块可以做得非常简单。基站调度器要做的决策也只是“谁在哪个资源块上发”是个纯粹的二维分配问题时间维和频率维。但在用户密集、业务突发明显的场景里这种正交隔离逻辑会带来隐性浪费。一个用户分到了资源块但实际数据不多这块频谱就处于半空置状态另一个用户数据积压严重却只能等下一个调度周期。更麻烦的是边缘用户它的信道增益低要在同样的频段上达到目标速率就得占用更大比例的功率和带宽这会把整个小区的频谱效率往下拉。OFDMA 的优势是“可控、干净”代价是“当信道差异大时资源做不到充分的共享”。2.2 NOMA 的叠加与 SIC近端用户替远端用户多干一道活NOMA 走的是另一条路功率域非正交。发射机在同一个子载波上把两个或多个用户信号按不同功率系数叠加后一起发出去对时间、频率资源不做独占而是让用户在功率维度上共享资源。为什么这样做能成立关键在接收端做 SIC也就是串行干扰消除。用一个两用户的例子来说明。信道质量差的用户称为远端用户分配较大的功率信道质量好的用户称为近端用户分配较小的功率。接收端解码顺序按照功率从大到小排功率越大的信号越容易被先解出来。远端用户功率高直接把自己信号解出来把近端信号当成噪声就行近端用户功率低但它信道条件好它先把功率高的远端用户信号解出来、从接收信号中减掉再解自己的信号。所以说近端用户替远端用户多干了一道“解码再减掉”的活付出的是接收机复杂度和能耗换来的是同一块频谱上两个人都在发。这个 SIC 过程的数学表达很简单远端和近端的信干噪比都能写成一个闭式公式。仿真里只要把公式写对结果就成功了一大半。2.3 一张表看清两种方案的本质选择把两个方案放在同一张表里看逻辑会更清楚。对比项OFDMA功率域 NOMA资源分配维度时间 频率正交隔离频率为底 功率叠加非正交每资源块服务用户数通常 1 个多个常见 2 个接收机复杂度低只需传统解调高需要 SIC 迭代反馈与调度开销需要精确信道质量反馈需要的是用户排序和功率分配信息对信道差异的偏好不希望差异太大边缘难调度差异越大功率区分越容易越有利性能瓶颈资源闲置和调度时延功率分配是否合理、SIC 误差传播这张表能解释为什么仿真标题里 NOMA 总是和 OFDMA 放一起对比两者不是简单的替代关系而是两种资源使用哲学的差异。OFDMA 用正交换取简单NOMA 用干扰换取频谱复用。当你的仿真场景是信道差异大的多用户小区NOMA 往往能压过 OFDMA反过来在信道对称、用户公平性要求苛刻的场景OFDMA 仍然更稳妥。仿真真正要做的事就是把这种边界条件摸清楚。3. 跑通 NOMA-OFDMA 对比仿真代码结构与第一次运行3.1 拿到压缩包后先按功能把手里的文件归类这类仿真包解压之后通常不会只有一个孤零零的脚本而是若干个文件互相调用。别急着双击其中一个运行先把文件按职责分类第一类叫主脚本负责设置仿真参数、循环扫描信噪比、调用子函数、最后画图第二类是信道生成部分一般是一个函数输入用户数和信道类型输出信道系数数组第三类是发射机处理逻辑做符号映射、功率分配、叠加编码第四类就是接收机设计实现 SIC 解码流程并计算误比特率或吞吐量第五类是 OFDMA 对照组它的地位经常被低估但恰恰是这个对照组设置了性能比较的基准线。动代码之前我建议先打开主脚本把里面几个关键变量的赋值找出来SNR 扫描范围、蒙特卡洛次数、用户数、子载波数、功率分配系数。这几个数决定了整个仿真的工作点。特别是蒙特卡洛次数如果写的是 100 这种量级跑出来的曲线会抖得像心电图后面所有对比结论都站不住脚。先把这些参数记下来再去看实现细节。3.2 一个最小可运行的 NOMA 仿真脚本与逐行说明与其去猜包里的代码怎么写的不如先照着下面这段最小脚本建立一个自己的“试验台”。这个脚本是我常用的两用户 NOMA 与 OFDMA 对比框架删掉了所有不必要的绘图细节只保留容量计算逻辑。% 主仿真参数 SNRdB 0:2:20; % 信噪比扫描范围单位 dB nTrial 5000; % 蒙特卡洛次数想曲线平滑就至少 5000 P 1; % 归一化发射总功率 a [0.8, 0.2]; % NOMA 功率分配系数远端 0.8近端 0.2 % 预分配结果数组 rateNoma zeros(size(SNRdB)); rateOfdma zeros(size(SNRdB)); for i 1:length(SNRdB) sumN 0; sumO 0; for t 1:nTrial % 生成两用户瑞利衰落信道独立同分布 h (randn(1,2) 1i*randn(1,2)) / sqrt(2); % 按信道增益升序排列h(1) 是远端弱用户h(2) 是近端强用户 [h] sort(abs(h), ascend); % 噪声功率由目标 SNR 换算得到 N0 P * 10^(-SNRdB(i)/10); % NOMA远端用户直接把近端信号当噪声 sinr1 (abs(h(1))^2 * P * a(1)) / (abs(h(1))^2 * P * a(2) N0); % NOMA近端用户 SIC 后只剩自己的信号和噪声 sinr2 (abs(h(2))^2 * P * a(2)) / N0; sumN sumN log2(1 sinr1) log2(1 sinr2); % OFDMA 对照带宽、功率都均分给两个用户 sumO sumO 0.5*log2(1 (abs(h(1))^2 * P/2) / N0) ... 0.5*log2(1 (abs(h(2))^2 * P/2) / N0); end rateNoma(i) sumN / nTrial; rateOfdma(i) sumO / nTrial; end % 绘图部分横轴 SNRdB纵轴归一化频谱效率 plot(SNRdB, rateNoma, r-o, SNRdB, rateOfdma, b-s); legend(NOMA, OFDMA); xlabel(SNR (dB)); ylabel(Sum Rate (bps/Hz)); grid on;这段代码里最容易绕晕的是sort那一步。信道系数生成后我取模值再做升序排列确认索引 1 是弱用户、索引 2 是强用户。为什么必须做这一步因为 NOMA 的功率分配与 SIC 解码顺序都依赖于信道排序排反了整个系统就失去意义。NOMA 的吞吐量计算上面远端用户的信干噪比分母里有近端用户的功率项因为对远端来说近端信号就是干扰近端用户信干噪比的分母只有噪声对应它在 SIC 成功后把干扰完全消除的理想状态。OFDMA 对照那两行带宽减半所以谱效率乘了 0.5功率均分所以每用户发射功率是 P/2这个必须和 NOMA 保持相同的总功率预算否则对比就不公平。3.3 对照组 OFDMA 的仿真设计有三种常见口径OFDMA 对照有很多写法不同写法直接影响结论方向。第一种最常见就是我上面用的带宽均分、功率均分这是“等资源池”口径大家总功耗一样NOMA 额外付出的复杂度换来的收益一目了然。第二种是带宽均分、功率按信道倒置分配也就是好的信道少给功率、差的信道多给功率这其实是在帮 OFDMA 做公平性优化对比对象变成了“功率分配更优的 OFDMA”。第三种是 OFDMA 也实现频率选择性调度把每个子载波分配给当前信道最好的用户这在多用户场景里会让 OFDMA 的频谱效率大幅提升。我一般会把第一种作为默认口径因为它是中性的比较基准。做敏感性分析时再跑第二种和第三种看 NOMA 的相对增益会不会被调度算法吃掉。如果你拿到的 zip 包里 OFDMA 对照组写的是全体用户挤在一起但各自解调互不干扰那就有问题——这不是 OFDMA是把 NOMA 的叠加信号直接当正交信号解性能会差到离谱属于明显的实现错误。4. 仿真参数怎么定信道模型与工作点选择4.1 瑞利信道与归一化功率仿真里最容易虚高的两个设置信道模型是整个仿真的地基也是最容易被低估的参数。包里的仿真绝大多数默认用瑞利衰落因为它是无线多径传播最经典的统计模型括号里的系数(randn 1i*randn)/sqrt(2)保证了信道增益的平均功率为 1这种归一化让后面所有功率计算都能在“相对功率”的基础上进行。但瑞利模型默认所有用户经历相同的大尺度衰落这在某些场景下会掩盖真实差异。如果目标是评估“用户距离基站不同远近”的 NOMA 场景就需要在大尺度上做手脚给远端用户乘一个更小的路径损耗系数让两个用户的接收功率拉开差距。我见过不少翻车案例信道全部用小尺度瑞利、不加大尺度差异跑出来的结果里 NOMA 的增益很小甚至看不出来然后作者硬是把功率分配系数调到 0.95 去补。这种调参方式本质上是掩盖模型缺陷。正确做法是先在信道模型里把差异建出来再让功率分配器去适应这个模型而不是反过来用极端功率分配系数硬撑出优势。归一化功率这里也有个经典坑。仿真里总功率 P 取 1但功率分配系数 a 的维度必须和 P 协调。a 是比例两个用户的功率是P*a(1)和P*a(2)所以必须满足 a(1)a(2)1含义是“对总功率的切分”。如果代码里写成了P*a(1)和P*a(2)但a(2)0.3而a(1)0.8两个功率加起来是 1.1P总功率预算悄悄多了 10%曲线整体上移。这种错误特别隐蔽因为人眼很难从曲线上判断 10% 的偏差还是靠代码审查才能抓住。我建议在初始化阶段就写一行断言if sum(a) ~ 1, error(功率分配系数必须归一化); end一劳永逸。4.2 用“和速率 vs SNR”作为试验台的工作参数仿真工作点的选择也就是扫哪些参数、参数范围取多少取决于你手头要回答的问题。如果目的是复现文献结论或者验证 NOMA 的基本性质最常见的工作台是“和速率对 SNR”横轴 0 到 30 dB步长 1 或 2 dB。在低 SNR 区噪声占主导SIC 能把干扰消掉但消不掉噪声NOMA 不如 OFDMA 的现象属于正常随着 SNR 升高NOMA 的和速率会逐渐超过 OFDMA这个交点大概在哪个 dB 数出现往往是评审人最喜欢问的问题。蒙特卡洛次数对标曲线的稳定性。5000 次是及格线10000 次能让曲线平滑到不用额外滤波。低于 1000 次时单次信道实现的随机性还没被平均掉曲线毛刺会让人误判趋势。如果你时间紧只能跑 1000 次至少要在代码里把随机数种子固定下来保证两次跑的结果一致否则改一个参数重新跑一遍曲线形状大变没法做对比。子载波数与用户数的关系也要注意。NOMA 的叠加增益来自每资源块上的多用户复用所以典型设置是“64 个子载波、每 2 个用户一组、共 32 组”用户数固定为 2 的仿真只能证明双用户场景的结论4 用户时 SIC 顺序变长误差传播影响会被放大这时候再看孙景频谱效率NOMA 的收益曲线会往下弯。这本身是个有价值的结论但它需要单独一组仿真来说明不要试图用双用户结果外推。4.3 仿真里常用的性能指标不止和速率一个维度做对比仿真时除了横纵轴直接画和速率我建议至少再补两个维度的评估。第一个是公平性指标最常用的是 Jain 指数它反映系统里各用户速率的均衡程度取值在 0 到 1 之间。NOMA 的和速率高但近端用户可能吃得盆满钵满远端用户只分到一点残羹Jain 指数就会显著低于 OFDMA。只报和速率、不报公平性评审人一眼就能看出这是在用系统级指标掩盖用户级矛盾。第二个是中断概率定义是用户速率低于某个门限的概率它比平均速率更能反映用户在真实业务下的感知。这两个指标不用每次仿真都跑而是作为“全面评估”的补充。我在做这类对比时固定下来的一套习惯动作是先扫和速率找到性能交点再在交点的 SNR 处画 Jain 指数最后对功率分配系数扫一遍。三张图放在一起系统的全貌就出来了。第 6 章里会具体展开功率系数扫描这个技巧这里先记住一个原则单条曲线只是结论的起点三条曲线才是可信的论据。5. 避坑NOMA-OFDMA 仿真的五个高频翻车点5.1 现象功率分配系数之和大于 1和速率曲线整体虚高第一次跑通两用户 NOMA 仿真我看到 20 dB 处和速率比 OFDMA 高了快一倍当时觉得这个方案简直无敌。后来逐行审查代码才发现两个功率系数加起来等于 1.15总功率预算超了 15%。这个问题在公式推导里几乎不可能出现但在脚本实现里极其常见因为矩阵赋值时 a(2) 被反复修改过最早的归一化约束在修改中失效了。解决方法是把功率分配写成一个独立的函数每次调用内部重新归一化禁止在外部直接修改系数值。function a normalizePowerCoeffs(aRaw) a aRaw / sum(aRaw); % 强制归一化确保总功率等于 P if any(a 0) error(功率分配系数不能为负); end end这段代码虽然只有三行但能挡住两类最隐蔽的错误一是系数没有归一化二是某个系数被写成负数。负功率在物理上不存在但脚本里如果前面的计算出了负的中间变量很容易带进来。加上这个函数之后所有功率分配入口统一从这里走问题从根源上被切断。5.2 现象SIC 解码顺序写反近端用户误码率反而高于远端SIC 解码顺序由信道增益排序决定功率分配顺序由同一个排序决定。两者必须保持一致近端用户先解出远端用户的信号并减去再解自己的。如果你的代码里排序用了降序把强信号当成了高功率用户那近端的 SIC 第一步就会失败——它试图先解一个功率比自己低但干扰更强的信号信干噪比根本达不到解码门限减不掉然后带着一个强干扰去解自己的信号误码率直接崩溃。最迷惑的是系统级误码率曲线看起来只是稍微变差不会出现明显报错让人怀疑是信道模型的问题。排查方法很简单在仿真循环里打印出两次解码后的星座图或者信干噪比如果近端解码的信干噪比低于远端排序几乎可以肯定是反的。5.3 现象蒙特卡洛次数不足曲线毛刺让性能交点判断产生偏差和速率曲线在交点附近的斜率往往很缓两三条曲线缠在一起。这种场景下如果蒙特卡洛次数只有 200随机起伏会掩盖真实的性能交点你看到的可能是 NOMA 交叉点偏左 1 dB 或者偏右 1 dB结论就完全不同。更麻烦的是在交点附近跑两遍结果不一样一旦有人复现就对结果失去信心。处理方案不是简单地加大次数而是先用较小次数找出交点大致位置然后在交点附近加密扫描并用 10000 次数重跑把原来的粗扫曲线替换成局部精确曲线。这个做法节省时间也能让结论更扎实。5.4 现象只画和速率不提用户公平性仿真结论被评审一票否决NOMA 的和速率优势很大尤其是信道差异被拉得很开的时候。但看细节就会发现远端用户速率可能被压到 OFDMA 下的一半近端用户速率高出两倍平均值好看不代表每个用户都好。只报和速率的仿真报告在评审环节几乎必被问到一个问题用户间的公平性是否符合要求如果你的功率分配策略里没有对远端用户速率做最低门限保护NOMA 的“优势”在实际系统中可能不可接受。对应的做法是画一条公平性曲线或者直接设定“远端用户速率不低于 OFDMA 下的速率”作为约束条件在这个约束下再做功率分配。5.5 现象信道模型没做路径损耗NOMA 增益被完全淹没上面 2.1 节提到过NOMA 的功率区分能力依赖于用户间信道差异。如果仿真里所有用户都用同样的瑞利分布且不加大尺度衰落两个用户的平均功率差异接近零SIC 能依赖的只有小尺度衰落的瞬时差异。这种模型下跑出来的结果NOMA 的和速率增益常常只有 5% 左右很难说明问题。验证方法很直接算一下远端用户和近端用户的平均接收功率比值如果比值接近 1说明信道差异不够需要加入距离相关的路径损耗项。6. 进阶扫一遍功率分配系数找到公平与效率的平衡点两用户 NOMA 的功率分配系数只有一个自由度设定 a(1) 后a(2) 自动等于 1-a(1)。这个自由度看起来简单却是系统真正的调节旋钮。a(1) 偏大远端用户舒服了近端用户 SIC 后残留的干扰也小但近端自己的功率被压缩近端速率下降a(1) 偏小远端用户速率撑不住系统公平性崩掉。扫系数就是在效率与公平之间描出一条曲线然后用这条曲线去对应你的系统目标。具体做法是在固定 SNR 下让 a(1) 从 0.51 到 0.95 按 0.01 步进扫描每次重跑蒙特卡洛循环记录两个关键值和速率与远端用户速率。然后把两条曲线画在同一个图上横轴是 a(1)。你会看到一个典型形态和速率曲线有一个峰通常落在 0.7 到 0.85 之间具体位置取决于信道差异程度远端用户速率则随 a(1) 单调上升。二者的交点也就是“和速率下降前远端用户速率已经足够高”的折中位置就是实际系统里推荐的功率分配工作点。我习惯在这个扫描基础上再叠一层约束如果项目目标是保证边缘用户体验就先把远端速率不能低于某个绝对门限写入代码在满足门限的系数区间内选和速率最大的那一个点。如果没有明确目标函数就选和速率峰右侧刚进入缓降区的位置这样系统对信道估计误差的敏感度最低。仿真不是找数学最优解而是找工程上最稳的工作点这个经验我在好几个项目里都验证过。功率系数扫描虽然要多跑几十轮蒙特卡洛但换来的是对这个系统行为习惯的完整认知——手上有这张曲线图后续无论评审问什么你都能直接从图上指一个点给结论。希望帮到你。本文还有配套的精品资源点击获取
延伸阅读

更多相关文章

2026/10/22 3:12:31

AI Agent黑箱破解:LangSmith全链路追踪与可视化实践

最近带一个智能客服方向的Agent项目上线,最大的感受不是模型能力不够,而是出了问题根本不知道去哪儿查。Agent跑起来像一个黑箱,用户问了一句,系统调用了好几个工具、改了好几轮上下文,最后给了一个不理想的回答——整…

2026/10/22 3:07:31

AI延迟优化实战:用“永不挂断的电话线”让响应快80%

OpenAI砍掉80%延迟:一根“永不挂断的电话线”,如何让AI快到飞起做了这么久的AI服务,我最怕听到用户说“回复太慢了”。大模型本身已经够聪明,但用户等结果时的那种焦虑,几乎能把所有的好感都磨光。前阵子内部优化一个对…

2026/10/22 3:07:31

从零搭建人脸轮廓识别:关键点检测实战与工程优化

1. 从零搭建人脸轮廓识别:一个视觉项目的完整复盘人脸轮廓识别这件事,听起来像是实验室里的高深课题,但真正动手做一遍就会发现,它的核心逻辑其实很朴素——让计算机在一张脸上找到眼睛、鼻子、嘴巴以及脸部外沿这些关键位置&…

2026/10/22 4:12:36

Java+MVC天气预报穿衣搭配APP开发实战解析

简介:一套基于JavaMVC架构的天气预报穿衣搭配APP毕业设计,含PC端与安卓手机端,面向计算机专业毕业设计或课程设计场景。项目采用界面层、业务逻辑层、数据层三层分离的MVC模式,服务器与客户端以XML和JSON交互,覆盖地区…

2026/10/22 4:12:36

Typecho从零搭建实战:轻量博客的可控性与长期运维指南

1. 为什么现在还要亲手搭一个 Typecho 博客?——不是为了怀旧,而是为了掌控感Typecho 这个名字,对很多刚接触建站的朋友来说,可能不如 WordPress 那样耳熟能详;但在我过去八年维护的二十多个个人站点、技术小站和轻量内…

2026/10/22 4:12:36

半边数据结构与欧拉操作:实现多内环扫掠建模核心原理

简介:《三维CAD建模》课程作业定义了半边数据结构,并基于该结构实现五个基本欧拉操作,以及支持带多个内环的二维区域扫掠操作,最终将构建的实体模型进行真实感图形显示,完整覆盖了CAD建模的核心流程。压缩包共18个文件…

2026/10/22 4:12:36

Windows系统安全加固实战:从账号权限到日志审计的核心防线

很多人在学习Windows系统安全的时候,最容易犯的一个毛病就是“东一榔头西一棒槌”。今天看到一篇讲组策略的文章,明天又去研究注册表加固,后天再折腾进程注入防护,学了一段时间之后发现,知识还是碎片化的,遇…

2026/10/22 4:12:36

AI日报:从参数竞赛到性价比竞赛,Agent落地与算力成本

今天是2026年10月6日,我照例把最近几天AI圈值得关注的信息重新翻了一遍。这段时间的日报不太好写,因为每天冒出来的新模型、新框架、新观点太多了,如果只做信息堆砌,看的人累,写的人也累。所以我更习惯按“信号”来整理…

2026/10/22 4:07:35

AI天使投资逻辑拆解:从杨致远看早期判断方法论

1. 从一份榜单说起:天使投资在AI赛道到底扮演什么角色前阵子跟几个做早期项目的朋友聊天,话题绕来绕去绕到了"钱从哪来"这件事上。做AI方向的创业者普遍有个感受:项目越早期,越难拿到传统机构的钱,因为机构有…

2026/10/21 4:53:08

金融AI落地指南:从调研报告到技术选型与工程实践

简介:这份PDF报告聚焦2025年金融服务业中国AI现状与趋势,面向金融科技从业者、AI战略规划人员及关注行业数字化转型的研究者,帮助读者把握生成式AI在银行、支付、交易等场景中的落地路径与投资方向。资源包内含1个PDF文件,大小约1…

2026/10/22 0:01:49

电商智能运营体系从0到1:架构设计、落地步骤与避坑指南

前两年我们团队接了一个电商平台的运营中台项目,目标很直白:把过去靠运营拍脑袋做的选品、定价、发券、推活动这些事,逐步用数据算法和自动化流程代替。项目名字内部就叫“电商智能运营体系”。最近有不少朋友问我当时是怎么设计的、踩过哪些…

2026/10/22 0:01:49

若依框架AI代码生成不稳定?用Agent Skill三层结构+五步法搞定

最近一段时间,我一直想把后台管理系统里那些机械重复的增删改查代码交给AI去写。框架用的是若依,按理说这类业务代码模式非常固定,应该是AI最擅长的事情。可真试下来却不是那么回事——你让AI生成一个用户管理模块,它给出的Contro…

还想了解更多?直接咨询顾问

免费诊断 + 免费方案 + 透明报价。

全国咨询热线400-8866-253
免费获取方案
☎咨询二维码 ☎ ↑