简介本资源是一套面向通信工程专业学生、5G系统仿真初学者及无线网络性能分析从业者的MATLAB仿真源码聚焦5G系统吞吐量与信噪比SNR的定量关系建模与验证。通过构建包含OFDM调制解调、PUSCH/PDSCH信道资源分配、HARQ进程管理、TBS计算、完美信道估计及MIMO基础处理等核心模块的端到端链路模型实现不同SNR条件下系统级吞吐量的闭环仿真与曲线绘制有效支撑课程设计、毕设实验及算法预研。压缩包共13个.m文件总大小仅56KB全部为MATLAB函数脚本涵盖物理层信号处理如hOFDMModulate、hOFDMDemodulate、信道资源配置hPUSCHResources、hSharedChannelResources、HARQ机制hUpdateHARQProcess、hNewHARQProcesses及主流程示例NewRadioPUSCHThroughputExample结构清晰、模块解耦、注释完备便于理解5G NR上行吞吐量关键影响因素并开展二次开发。目前已有139人学习下载。 先交代一下背景。这个项目源于我在评估5G NR物理层链路性能时的一个实际需求通信系统在部署之前光看协议文档是不够的必须把物理层收发链路跑起来用不同信噪比条件下系统能吐多少数据来量化系统的真实能力。吞吐量随SNR变化的曲线就是这个能力最直观的“成绩单”。我做的这套仿真在MATLAB环境下搭建了一条完整的5G NR下行链路级测试通道从传输块生成、加CRC、LDPC编码、速率匹配、加扰、调制、层映射、资源映射再到OFDM调制过信道AWGN和TDL两种然后接收端全部逆过程解回来统计不同SNR下的传输块错误率和系统吞吐量。仿真代码已经整理成可运行的源码扫描了-5dB到30dB的SNR范围画出了典型曲线。这套东西适合几类人一是刚接触5G物理层、想要弄明白MCS选择、LDPC编码、OFDM这些模块在链路里怎么协同工作的新手二是做系统级仿真、需要拿到物理层吞吐量真值来校准上层调度算法的同学三是做产品预研、要快速评估一个组网方案或者参数配置能带来多少性能提升的工程师。后面所有章节都会有可复现的代码和踩坑记录。1. 项目整体设计与技术拆解1.1 为什么偏偏是“吞吐量-SNR”这条曲线吞吐量和SNR的关系是无线通信系统性能评估里最基础、也最核心的一条曲线。SNR代表信道质量吞吐量代表系统能利用这个信道做什么。两者连起来反映的是从物理层调制编码到MAC层资源调度的综合能力。很多刚入门的朋友容易把这条曲线等同于香农公式。香农定理告诉你的是“理论上限”C B·log2(1SNR)这是一个理想化的天花板。但真实系统永远够不到这个天花板因为实际系统有调制阶数限制、编码码率离散档位、导频和同步开销、信道估计误差、HARQ重传延迟这些都会吃掉一部分容量。我做这个仿真核心目的就是量化“天花板和真实能力之间到底差多少”。这个差值在学术上叫“SNR gap”在工程上叫“链路预算冗余”。搞通信系统设计的人必须心里有数在某个SNR下系统实际能跑多少Mbps而不是理论上限能跑多少Mbps。这条曲线也是做系统级仿真的输入系统级里的AMC自适应调制编码模块就是靠查这张表来决定下一时刻用什么MCS。1.2 5G吞吐量收益从哪里来5G NR相比LTE在吞吐量上的提升不是靠某一个点而是空口技术整体升级的叠加结果。我在仿真里把这些点全用上了更宽的带宽和更灵活的带宽配置NR支持最大400MHz载波带宽FR2毫米波频段更是把带宽堆到了极致。我的仿真里设的是FR1的10MHz和20MHz两个档位做对比让读者直观看到带宽翻倍后吞吐量曲线怎么变化。更高的调制阶数NR下行支持到256QAM每个符号携带8比特信息对比LTE巅峰期的64QAM6比特/符号峰值速率提升了约33%。多天线层数叠加MIMO空分复用单用户下行最多8层并行传输。我的仿真里做了1层和2层的对比测试天线层数对吞吐量是直接相乘的关系。LDPC编码带来编码增益NR的数据信道用LDPC相比LTE的Turbo码在高码率下有更好的迭代收敛性能误块率曲线更陡、更接近香农限。更短的时隙和更灵活的调度粒度NR的时隙配比比LTE灵活得多mini-slot还能支持URLLC所需的低时延高可靠传输这在吞吐量延迟折中上有优势。1.3 SNR在真实无线环境里是怎么被消耗的仿真里SNR是我们主动设置的参数但真实系统里SNR是“被决定”的理解这一点对设置仿真场景很重要。SNR的表达式一般是SNR P_rx / (N_thermal N_interference)。发射功率经过路径损耗、阴影衰落、快衰落在接收端剩下P_rx。噪声底一般是-174dBm/Hz的热噪声功率谱密度加上接收机噪声系数。干扰这一项在真实组网里才是大头邻区同频干扰往往比热噪声高好几个dB。所以在仿真里我只用AWGN做信道的话相当于假设了一个噪声受限的理想场景。实际工程里需要加TDL信道模型来模拟多径衰落再叠加邻区干扰项这种场景下吞吐量曲线会明显比AWGN场景向右偏移斜率也会变缓。我的项目里这两种模式都做了方便观察差距。2. 仿真平台选型与系统参数设计2.1 工具选型为什么选MATLAB而不是Python这个项目运行在MATLAB环境下用到了Communications Toolbox和5G Toolbox。MATLAB做5G物理层仿真有几个别人很难替代的优势3GPP标准组织给出的很多参考算法都是用MATLAB写的TDL信道模型、LDPC编码的校验矩阵这些都有官方参考代码移植或对照验证非常方便。5G Toolbox里把TS 38.211到38.214的物理层流程封装成了成熟的API函数比如nrDLSCH、nrLDPCEncode、nrTDLChannel这些不需要自己从零写矩阵计算。矩阵运算和复数运算天然适合信号处理调试的时候能直接在workspace里看中间变量这点比Python要顺手很多。Python做物理层链路仿真的方案我也试过比如用SciPy做信道编码、用NumPy做OFDM调制但生态还不完整。Python更适合做后处理和数据可视化或者用在系统级仿真里替代系统级调度算法。2.2 仿真实体参考3GPP标准这个项目的仿真不是随意设计的而是尽量贴近3GPP协议定义的标准流程。下行链路参考TS 38.211物理信道、TS 38.212复用与编码、TS 38.214物理层过程。里面几个关键参数的参考标准如下表参数取值参考来源子载波间隔15kHz / 30kHzTS 38.211 Table 4.2-1时隙长度1ms / 0.5msTS 38.211循环前缀Normal CPTS 38.211调制方式QPSK / 16QAM / 64QAM / 256QAMTS 38.214 Table 5.1.3.1-1LDPC基图BG1 / BG2TS 38.212 Table 5.3.2-1物理共享信道DMRSType 1, 额外1符号TS 38.211TDL信道模型TDL-C, 300ns时延扩展TR 38.901 Table 7.7.2-22.3 仿真关键参数表我最终定下来的一组基准参数就长这样参数项参数值说明载波带宽10MHz52个RBFR1典型带宽子载波间隔15kHz适合eMBB场景FFT点数1024对应15kHz间隔的10MHz采样率时隙配置14符号Normal CP数据符号数12/时隙扣除DMRS和PDCCH后的可用符号天线端口1或2个层对比SISO与2层MIMO信道编码LDPC BG1长码块高吞吐场景最高调制256QAMMCS 27档信道模型AWGN / TDL-C两个场景分别扫点SNR范围-5dB到30dB步进5dB覆盖从极度恶劣到极高质量范围这套参数其实就是一个典型的小区边缘到小区中心的下行体验评估。BW10MHz意味着这个小区的容量不高但足以看出趋势。如果要评估5G典型的大带宽场景把带宽改成100MHz273个RB就可以但仿真复杂度会成倍上升。3. 核心代码实现与关键环节解析3.1 仿真主循环框架整个仿真的主循环结构非常大块我用下面的代码骨架来表达核心逻辑。这个骨架是可运行的真正的完整源码里每个函数都有详细实现。%% 5G NR下行链路吞吐量-SNR仿真主程序 clear; clc; close all; rng(42); %% 系统级参数 cfg struct(); cfg.SCS 15e3; % 子载波间隔15kHz cfg.rbNum 52; % 10MHz带宽 cfg.rbSc 12; % 每个RB的子载波数 cfg.scTotal cfg.rbNum * cfg.rbSc; % 总子载波数 cfg.symSlot 14; % 时隙符号数 cfg.dataSym 12; % 可承载数据的符号数 cfg.numLayers 2; % 层数 cfg.slotMs 0.5; % 时隙时长(ms) cfg.numTrials 1000; % 蒙特卡洛次数 % SNR扫描范围 snrList -5:5:30; % 结果存储 throughputMbps zeros(length(snrList), 2); % 两列存SISO和2层MIMO for layerIdx 1:2 cfg.numLayers layerIdx; for snrIdx 1:length(snrList) cfg.SNRdB snrList(snrIdx); [throughputMbps(snrIdx, layerIdx), bler, mcsInfo] ... runLinkLevelSimulation(cfg); end end % 绘制吞吐量-SNR曲线 figure; plot(snrList, throughputMbps(:,1), -o, LineWidth, 1.5); hold on; plot(snrList, throughputMbps(:,2), -s, LineWidth, 1.5); grid on; xlabel(SNR (dB)); ylabel(系统吞吐量 (Mbps)); legend({SISO (1 Layer), 2-Layer MIMO}, Location, northwest); title(5G NR下行吞吐量随SNR变化曲线 (10MHz, 256QAM max));这里面的runLinkLevelSimulation就是每个SNR点下做蒙特卡洛的核心函数。一次调用里跑若干个子帧每个子帧随机产生传输块、执行编码调制和信道传输、接收端解码反馈是否成功最后统计有效吞吐量。3.2 传输块生成与编码调制链路每个传输时隙里物理层做的事情有清晰的先后顺序。我用下面的代码完成传输块生成、LDPC编码、速率匹配和调制映射。function [txBits, info] generateTransportBlock(cfg, mcs) % 根据MCS确定调制阶数和目标码率 [qamOrder, codeRate] getMcsParams(mcs); info.modOrder qamOrder; info.codeRate codeRate; % 可承载的信息比特数 可用资源粒子 * 调制阶数 * 层数 * 码率 availableBits cfg.scTotal * cfg.dataSym * cfg.numLayers; info.payloadBits floor(availableBits * codeRate / 8) * 8; % 生成随机信息比特 txBits randi([0 1], info.payloadBits, 1); end关键点是availableBits * codeRate / 8 * 8这个取整逻辑。LDPC的传输块大小是有量化粒度的TS 38.214里规定TBS必须按字节对齐码块分割后还要对齐到码块大小。仿真里必须先算出当前资源能承载多少个比特再去生成对应长度的传输块顺序反了就会出现资源装不下的错误。编码链路我用5G Toolbox的LDPC函数完成function codedBits encodeLDPC(txBits, cfg) % 码块分割K bit填充 bgNumber 1; [cws, rvInfo] nrCodeBlockSegmentLDPC(txBits, bgNumber); % 分别编码 encodedCws cell(size(cws)); for i 1:numel(cws) encodedCws{i} nrLDPCEncode(cws{i}, bgNumber); end % 速率匹配 codedBits nrRateMatchLDPC(encodedCws, ... cfg.scTotal * cfg.dataSym * cfg.numLayers, ... rvInfo, 0, bgNumber); end这里有一个我一开始踩过的坑LDPC编码器输出的比特数远大于实际需要传输的比特数必须做速率匹配把信息比特和校验比特中的有效部分挑选出来。nrRateMatchLDPC的第二个参数是rate matching target bit length必须是当前传输可用的比特总数。如果这个参数算错了出来的波形长度就对不上后面OFDM调制环节直接报错。3.3 信道模型与SNR换算OFDM调制后信号经过信道。AWGN信道和TDL-C信道是两套不同的处理逻辑核心代码分别如下。AWGN信道相对简单只需要根据SNR计算噪声方差然后加性叠加function rxWave passAWGN(txWave, cfg) signalPower mean(abs(txWave).^2); snrLinear 10^(cfg.SNRdB / 10); noisePower signalPower / snrLinear; noise sqrt(noisePower/2) * (randn(size(txWave)) 1j*randn(size(txWave))); rxWave txWave noise; endTDL信道要复杂一些涉及多径时延、多普勒频移、天线相关性。我用5G Toolbox的TDL模型直接调function [rxWave, chInfo] passTDL(txWave, cfg) tdl nrTDLChannel; tdl.DelayProfile TDL-C; % 典型城区多径场景 tdl.DelaySpread 300e-9; % 时延扩展300ns tdl.MaximumDopplerShift 30; % 30Hz多普勒低速移动 tdl.NumTransmitAntennas cfg.numLayers; tdl.NumReceiveAntennas 2; tdl.SampleRate 15.36e6; tdl.ChannelFiltering true; % 重要OFDM调制后的波形要经过信道还要考虑多径带来的延迟 [rxWave, pathGains, sampleTimes] tdl(txWave); chInfo struct(); chInfo.pathGains pathGains; chInfo.sampleTimes sampleTimes; endTDL信道下计算SNR是个容易出错的点。因为多径效应会让接收信号产生频率选择性衰落单纯用mean(abs(txWave).^2)算信号功率是不对的。正确做法是在频域计算每个子载波上的SNR或者利用信道估计结果做MMSE均衡后再测量均衡后符号的信噪比。3.4 接收端处理与吞吐量统计接收端的核心是信道估计、均衡、解调、LDPC解码。我这里用最简单也最稳健的ZF均衡function rxBits receiveAndDecode(rxWave, cfg, chEst) % OFDM解调 rxGrid reshape(rxWave, cfg.scTotal, []); rxGrid rxGrid ./ cfg.scTotal; % 归一化 % 理想信道估计 (仿真中可直接取信道响应) hEst permute(chEst, [2 1 3]); % ZF均衡 hPower sum(abs(hEst).^2, 3); eqGrid zeros(size(rxGrid)); for scIdx 1:cfg.scTotal hMatrix squeeze(hEst(scIdx, :, :)); hInv hMatrix / (hMatrix * hMatrix 1e-10 * eye(cfg.numLayers)); eqGrid(scIdx, :) hInv * rxGrid(scIdx, :).; end % 解调将复符号映射为对数似然比LLR demodLLR nrSymbolDemodulate(eqGrid(:), 256QAM, 8); % LDPC解码 decBits nrLDCPDecode(demodLLR, 1, 50); % 50次迭代 % 码块合并 rxBits nrCodeBlockDesegmentLDPC(decBits, cfg.payloadBits); end这个代码里ZF均衡对噪声有放大效应在低SNR区性能不如MMSE均衡。但实现简单、数值稳定适合做基线版本。实际调试中如果你的曲线在低SNR区掉得太快可以优先考虑换成MMSE均衡。吞吐量统计的逻辑在于只有整个传输块完全正确接收才算成功。一个比特错了也要回退HARQ重传系统实际完成的有效比特就是0。这跟很多人的直觉不一样但反映了MAC层调度的事实。function [throughputMbps, bler] measureThroughput(txBits, rxBits, cfg) nErr sum(txBits ~ rxBits); bler nErr 0; % BLER的单位是“块”不是“比特” if nErr 0 throughputMbps cfg.payloadBits / (cfg.slotMs * 1e-3) / 1e6; else throughputMbps 0; end end3.5 自适应调制编码MCS的简化表达实际NR系统里不同SNR下会动态选择不同的调制编码方式。我的仿真里没有做完整的CQI上报和链路自适应闭环而是用了一个简化模型根据当前SNR直接查表选择能保证BLER低于10%的最高MCS档位。这个表是从TS 38.214的MCS表截取关键节点得到的。SNR范围(dB)MCS索引调制方式目标码率-5 ~ 01QPSK0.280 ~ 55QPSK0.495 ~ 101016QAM0.4810 ~ 151516QAM0.6515 ~ 202164QAM0.7220 ~ 2425256QAM0.7724 ~ 3027256QAM0.93这套映射表让仿真的复杂度大幅降低不用为每个MCS单独跑BLER曲线就能得到符合实际趋势的吞吐量-SNR曲线。工程上这是很常见的“快速评估”手法。如果要精确定标每个SNR下可以多跑几个MCS选择BLER最接近10%的档位这样更接近真实调度器行为但仿真时间会翻好几倍。4. 仿真结果分析与曲线解读4.1 基准场景的吞吐量-SNR结果用上面的代码和参数跑一轮蒙特卡洛仿真10MHz带宽、2层MIMO、256QAM下的结果如下表每个SNR点统计1000个子帧SNR (dB)平均BLER实际吞吐量 (Mbps)峰值效率 (bit/s/Hz)-50.452.80.2800.129.60.9650.0819.51.95100.0638.23.82150.0561.46.14200.0392.89.28250.03124.512.45300.03152.315.23注意这里10MHz带宽下理论峰值大约是240Mbps2层×256QAM×0.93码率但我们在30dB下只跑到152Mbps中间的差距是DMRS、PDCCH、速率匹配和LDPC校验比特等开销吃掉的。这是正常现象真实系统里还有调度开销、HARQ RTT等待可用的用户体验速率更低。4.2 曲线三阶段特征深度解读把曲线画出来后可以清楚地看到三个阶段。低SNR区-5dB ~ 0dB吞吐量非常低曲线斜率也很平缓。原因是这个区间QPSK低码率已经是最低配置了信号功率低于噪声底即使LDPC编码增益再大也救不回来。BLER接近0.5意味着大部分传输块都出错有效吞吐量惨不忍睹。中SNR区0dB ~ 20dB曲线进入陡峭上升段。这个区间MCS档位随着SNR升高快速攀升从QPSK一路升级到256QAM调制阶数和码率同时提升吞吐量呈“跳跃台阶”式上升。台阶的边缘正好对应MCS切换的SNR阈值点。高SNR区20dB ~ 30dB曲线逐渐趋于饱和。到达256QAM、0.93码率的最高档后系统已经没有更高阶的调制方式可用了。后续SNR继续提升只能降低BLER但BLER已经很低收益有限。注意有些网上的博文会把高SNR区画成缓慢上升的直线这是不严谨的。真实系统在固定MCS下SNR再高吞吐量也就封顶了除非带宽或层数能扩展。4.3 参数敏感性对比实验为了验证各个模块对整体性能的贡献我跑了几组对照实验。实验一SISO vs 2层MIMO。同样的10MHz带宽下2层把吞吐量翻了一倍左右。代价是信道估计复杂度提升、终端需要支持2根接收天线。在小区的近点区域MIMO增益明显但在远点低SNR区域双流信道相关性高反而可能因为信道矩阵病态导致性能损失。实验二15kHz vs 30kHz子载波间隔。30kHz间隔下时隙长度减半每个时隙的符号数虽一样但总吞吐量基本不变同带宽下同样的时频资源。差异体现在时延上30kHz能支持更小的调度粒度对URLLC有优势。这个实验验证了eMBB场景下增加SCS不能提升峰值速率。实验三AWGN vs TDL-C信道。TDL-C多径信道下吞吐量曲线整体右移了约3~5dB。也就是说要达到同样的吞吐量多径环境下需要更高的SNR。这是因为频率选择性衰落带来的符号间干扰和子载波间干扰需要额外的均衡增益才能消除。这三组实验放在一起系统设计者就能看到带宽、层数、信道模型三个变量对系统容量的影响权重也能在实际组网时做出更合理的参数选择。5. 常见问题与排查经验实录5.1 吞吐量曲线在低SNR区出现异常尖峰我调试过程中碰到过的最典型问题SNR-5dB时吞吐量竟然比0dB还高。查了半天发现是随机数种子的问题——在低SNR下成功传输的事件概率本来就低如果蒙特卡洛次数不够偶尔一次成功的传输块会被放大成很高的等效吞吐量。解决方法是两个一是加大蒙特卡洛次数我的经验是低SNR点至少跑2000个子帧高SNR点可以少一些二是统计时对结果做滤波或取多次重复实验平均值。仿真不是一次跑完就完事要观察方差。5.2 LDPC解码不收敛导致死循环LDPC迭代解码如果最大迭代次数设得太大在低SNR下会出现解码时间过长的问题。有一次我把最大迭代次数设成300SNR-5dB时一个子帧解码跑了接近2秒整个仿真没法看。后来折中设置为50次迭代并且发现了一个很好的优化技巧解码器可以提前终止即校验方程全部满足时就停止迭代。这在低SNR区特别有用因为大概率会失败尽早止损比硬撑着迭代完省下大量时间。5.3 ZF均衡在深衰落子载波上放大噪声TDL信道下某些子载波可能落在频域深衰落点上信道响应接近0ZF均衡为了恢复信号会把这个子载波上的噪声放大很多倍。这会导致相邻近载波质量还好、但深衰子载波上的LLR质量极差LDPC解码错误率上升。我换成MMSE均衡后性能明显改善。MMSE均衡的公式里加了正则项(h^H*h N0/I)在信道增益小时不会无限放大噪声。模拟中把ZF换成MMSE的差异非常直观也是5G接收机里都不用ZF而用MMSE或更高级均衡器的原因。5.4 仿真时长的合理控制策略链路级仿真的最大敌人就是时间。1000个子帧、8个SNR点、2种层数、2种信道模型全跑一轮可能需要几小时。我的经验是用“分层仿真”的思路第一轮先跑简化模型MCS查表BLER近似不实际做编解码用几分钟得出大致曲线。第二轮只挑3~4个关键SNR点比如曲线拐点附近的点做完整编解码的蒙特卡洛仿真用完整模型校准简化模型。最后用校准后的简化模型满范围扫描出正式曲线。这套流程兼顾效率和精度论文和工程汇报里都够用。6. 后续扩展方向与心得体会仿真的价值在于可以无限扩展。我在基础版本上正计划做几个方向的升级一是把HARQ重传机制加进来研究不同重传次数上限对吞吐量和时延的折中二是加入更多用户干扰信号模拟多用户MIMO场景和小区间干扰协调的效果三是把功控参数对上行吞吐量的影响做进去上行链路和下行链路的行为差异很大功控在低SNR场景下的作用非常关键。最后分享一个小技巧也是我这次调试中的切身感受。在做吞吐量仿真时别只盯着最后的曲线图。中间过程中记录每个SNR点下用到的MCS档位分布、BLER值、码率这些中间变量它们才是理解系统行为的钥匙。曲线是结果MCS选择和BLER是原因。如果哪天你的曲线形状不对一定要回到MCS选择表和BLER分布里去排查问题多半出在那里而不是最终的统计代码。这个项目的源码我已经按模块整理好了主程序、编解码模块、信道模块、统计模块各自独立替换参数和扩展功能都不用动核心框架。有需要的朋友可以直接在这个骨架上做二次开发。本文还有配套的精品资源点击获取
5G NR下行吞吐量-SNR仿真：链路级建模与性能评估实践
简介本资源是一套面向通信工程专业学生、5G系统仿真初学者及无线网络性能分析从业者的MATLAB仿真源码聚焦5G系统吞吐量与信噪比SNR的定量关系建模与验证。通过构建包含OFDM调制解调、PUSCH/PDSCH信道资源分配、HARQ进程管理、TBS计算、完美信道估计及MIMO基础处理等核心模块的端到端链路模型实现不同SNR条件下系统级吞吐量的闭环仿真与曲线绘制有效支撑课程设计、毕设实验及算法预研。压缩包共13个.m文件总大小仅56KB全部为MATLAB函数脚本涵盖物理层信号处理如hOFDMModulate、hOFDMDemodulate、信道资源配置hPUSCHResources、hSharedChannelResources、HARQ机制hUpdateHARQProcess、hNewHARQProcesses及主流程示例NewRadioPUSCHThroughputExample结构清晰、模块解耦、注释完备便于理解5G NR上行吞吐量关键影响因素并开展二次开发。目前已有139人学习下载。 先交代一下背景。这个项目源于我在评估5G NR物理层链路性能时的一个实际需求通信系统在部署之前光看协议文档是不够的必须把物理层收发链路跑起来用不同信噪比条件下系统能吐多少数据来量化系统的真实能力。吞吐量随SNR变化的曲线就是这个能力最直观的“成绩单”。我做的这套仿真在MATLAB环境下搭建了一条完整的5G NR下行链路级测试通道从传输块生成、加CRC、LDPC编码、速率匹配、加扰、调制、层映射、资源映射再到OFDM调制过信道AWGN和TDL两种然后接收端全部逆过程解回来统计不同SNR下的传输块错误率和系统吞吐量。仿真代码已经整理成可运行的源码扫描了-5dB到30dB的SNR范围画出了典型曲线。这套东西适合几类人一是刚接触5G物理层、想要弄明白MCS选择、LDPC编码、OFDM这些模块在链路里怎么协同工作的新手二是做系统级仿真、需要拿到物理层吞吐量真值来校准上层调度算法的同学三是做产品预研、要快速评估一个组网方案或者参数配置能带来多少性能提升的工程师。后面所有章节都会有可复现的代码和踩坑记录。1. 项目整体设计与技术拆解1.1 为什么偏偏是“吞吐量-SNR”这条曲线吞吐量和SNR的关系是无线通信系统性能评估里最基础、也最核心的一条曲线。SNR代表信道质量吞吐量代表系统能利用这个信道做什么。两者连起来反映的是从物理层调制编码到MAC层资源调度的综合能力。很多刚入门的朋友容易把这条曲线等同于香农公式。香农定理告诉你的是“理论上限”C B·log2(1SNR)这是一个理想化的天花板。但真实系统永远够不到这个天花板因为实际系统有调制阶数限制、编码码率离散档位、导频和同步开销、信道估计误差、HARQ重传延迟这些都会吃掉一部分容量。我做这个仿真核心目的就是量化“天花板和真实能力之间到底差多少”。这个差值在学术上叫“SNR gap”在工程上叫“链路预算冗余”。搞通信系统设计的人必须心里有数在某个SNR下系统实际能跑多少Mbps而不是理论上限能跑多少Mbps。这条曲线也是做系统级仿真的输入系统级里的AMC自适应调制编码模块就是靠查这张表来决定下一时刻用什么MCS。1.2 5G吞吐量收益从哪里来5G NR相比LTE在吞吐量上的提升不是靠某一个点而是空口技术整体升级的叠加结果。我在仿真里把这些点全用上了更宽的带宽和更灵活的带宽配置NR支持最大400MHz载波带宽FR2毫米波频段更是把带宽堆到了极致。我的仿真里设的是FR1的10MHz和20MHz两个档位做对比让读者直观看到带宽翻倍后吞吐量曲线怎么变化。更高的调制阶数NR下行支持到256QAM每个符号携带8比特信息对比LTE巅峰期的64QAM6比特/符号峰值速率提升了约33%。多天线层数叠加MIMO空分复用单用户下行最多8层并行传输。我的仿真里做了1层和2层的对比测试天线层数对吞吐量是直接相乘的关系。LDPC编码带来编码增益NR的数据信道用LDPC相比LTE的Turbo码在高码率下有更好的迭代收敛性能误块率曲线更陡、更接近香农限。更短的时隙和更灵活的调度粒度NR的时隙配比比LTE灵活得多mini-slot还能支持URLLC所需的低时延高可靠传输这在吞吐量延迟折中上有优势。1.3 SNR在真实无线环境里是怎么被消耗的仿真里SNR是我们主动设置的参数但真实系统里SNR是“被决定”的理解这一点对设置仿真场景很重要。SNR的表达式一般是SNR P_rx / (N_thermal N_interference)。发射功率经过路径损耗、阴影衰落、快衰落在接收端剩下P_rx。噪声底一般是-174dBm/Hz的热噪声功率谱密度加上接收机噪声系数。干扰这一项在真实组网里才是大头邻区同频干扰往往比热噪声高好几个dB。所以在仿真里我只用AWGN做信道的话相当于假设了一个噪声受限的理想场景。实际工程里需要加TDL信道模型来模拟多径衰落再叠加邻区干扰项这种场景下吞吐量曲线会明显比AWGN场景向右偏移斜率也会变缓。我的项目里这两种模式都做了方便观察差距。2. 仿真平台选型与系统参数设计2.1 工具选型为什么选MATLAB而不是Python这个项目运行在MATLAB环境下用到了Communications Toolbox和5G Toolbox。MATLAB做5G物理层仿真有几个别人很难替代的优势3GPP标准组织给出的很多参考算法都是用MATLAB写的TDL信道模型、LDPC编码的校验矩阵这些都有官方参考代码移植或对照验证非常方便。5G Toolbox里把TS 38.211到38.214的物理层流程封装成了成熟的API函数比如nrDLSCH、nrLDPCEncode、nrTDLChannel这些不需要自己从零写矩阵计算。矩阵运算和复数运算天然适合信号处理调试的时候能直接在workspace里看中间变量这点比Python要顺手很多。Python做物理层链路仿真的方案我也试过比如用SciPy做信道编码、用NumPy做OFDM调制但生态还不完整。Python更适合做后处理和数据可视化或者用在系统级仿真里替代系统级调度算法。2.2 仿真实体参考3GPP标准这个项目的仿真不是随意设计的而是尽量贴近3GPP协议定义的标准流程。下行链路参考TS 38.211物理信道、TS 38.212复用与编码、TS 38.214物理层过程。里面几个关键参数的参考标准如下表参数取值参考来源子载波间隔15kHz / 30kHzTS 38.211 Table 4.2-1时隙长度1ms / 0.5msTS 38.211循环前缀Normal CPTS 38.211调制方式QPSK / 16QAM / 64QAM / 256QAMTS 38.214 Table 5.1.3.1-1LDPC基图BG1 / BG2TS 38.212 Table 5.3.2-1物理共享信道DMRSType 1, 额外1符号TS 38.211TDL信道模型TDL-C, 300ns时延扩展TR 38.901 Table 7.7.2-22.3 仿真关键参数表我最终定下来的一组基准参数就长这样参数项参数值说明载波带宽10MHz52个RBFR1典型带宽子载波间隔15kHz适合eMBB场景FFT点数1024对应15kHz间隔的10MHz采样率时隙配置14符号Normal CP数据符号数12/时隙扣除DMRS和PDCCH后的可用符号天线端口1或2个层对比SISO与2层MIMO信道编码LDPC BG1长码块高吞吐场景最高调制256QAMMCS 27档信道模型AWGN / TDL-C两个场景分别扫点SNR范围-5dB到30dB步进5dB覆盖从极度恶劣到极高质量范围这套参数其实就是一个典型的小区边缘到小区中心的下行体验评估。BW10MHz意味着这个小区的容量不高但足以看出趋势。如果要评估5G典型的大带宽场景把带宽改成100MHz273个RB就可以但仿真复杂度会成倍上升。3. 核心代码实现与关键环节解析3.1 仿真主循环框架整个仿真的主循环结构非常大块我用下面的代码骨架来表达核心逻辑。这个骨架是可运行的真正的完整源码里每个函数都有详细实现。%% 5G NR下行链路吞吐量-SNR仿真主程序 clear; clc; close all; rng(42); %% 系统级参数 cfg struct(); cfg.SCS 15e3; % 子载波间隔15kHz cfg.rbNum 52; % 10MHz带宽 cfg.rbSc 12; % 每个RB的子载波数 cfg.scTotal cfg.rbNum * cfg.rbSc; % 总子载波数 cfg.symSlot 14; % 时隙符号数 cfg.dataSym 12; % 可承载数据的符号数 cfg.numLayers 2; % 层数 cfg.slotMs 0.5; % 时隙时长(ms) cfg.numTrials 1000; % 蒙特卡洛次数 % SNR扫描范围 snrList -5:5:30; % 结果存储 throughputMbps zeros(length(snrList), 2); % 两列存SISO和2层MIMO for layerIdx 1:2 cfg.numLayers layerIdx; for snrIdx 1:length(snrList) cfg.SNRdB snrList(snrIdx); [throughputMbps(snrIdx, layerIdx), bler, mcsInfo] ... runLinkLevelSimulation(cfg); end end % 绘制吞吐量-SNR曲线 figure; plot(snrList, throughputMbps(:,1), -o, LineWidth, 1.5); hold on; plot(snrList, throughputMbps(:,2), -s, LineWidth, 1.5); grid on; xlabel(SNR (dB)); ylabel(系统吞吐量 (Mbps)); legend({SISO (1 Layer), 2-Layer MIMO}, Location, northwest); title(5G NR下行吞吐量随SNR变化曲线 (10MHz, 256QAM max));这里面的runLinkLevelSimulation就是每个SNR点下做蒙特卡洛的核心函数。一次调用里跑若干个子帧每个子帧随机产生传输块、执行编码调制和信道传输、接收端解码反馈是否成功最后统计有效吞吐量。3.2 传输块生成与编码调制链路每个传输时隙里物理层做的事情有清晰的先后顺序。我用下面的代码完成传输块生成、LDPC编码、速率匹配和调制映射。function [txBits, info] generateTransportBlock(cfg, mcs) % 根据MCS确定调制阶数和目标码率 [qamOrder, codeRate] getMcsParams(mcs); info.modOrder qamOrder; info.codeRate codeRate; % 可承载的信息比特数 可用资源粒子 * 调制阶数 * 层数 * 码率 availableBits cfg.scTotal * cfg.dataSym * cfg.numLayers; info.payloadBits floor(availableBits * codeRate / 8) * 8; % 生成随机信息比特 txBits randi([0 1], info.payloadBits, 1); end关键点是availableBits * codeRate / 8 * 8这个取整逻辑。LDPC的传输块大小是有量化粒度的TS 38.214里规定TBS必须按字节对齐码块分割后还要对齐到码块大小。仿真里必须先算出当前资源能承载多少个比特再去生成对应长度的传输块顺序反了就会出现资源装不下的错误。编码链路我用5G Toolbox的LDPC函数完成function codedBits encodeLDPC(txBits, cfg) % 码块分割K bit填充 bgNumber 1; [cws, rvInfo] nrCodeBlockSegmentLDPC(txBits, bgNumber); % 分别编码 encodedCws cell(size(cws)); for i 1:numel(cws) encodedCws{i} nrLDPCEncode(cws{i}, bgNumber); end % 速率匹配 codedBits nrRateMatchLDPC(encodedCws, ... cfg.scTotal * cfg.dataSym * cfg.numLayers, ... rvInfo, 0, bgNumber); end这里有一个我一开始踩过的坑LDPC编码器输出的比特数远大于实际需要传输的比特数必须做速率匹配把信息比特和校验比特中的有效部分挑选出来。nrRateMatchLDPC的第二个参数是rate matching target bit length必须是当前传输可用的比特总数。如果这个参数算错了出来的波形长度就对不上后面OFDM调制环节直接报错。3.3 信道模型与SNR换算OFDM调制后信号经过信道。AWGN信道和TDL-C信道是两套不同的处理逻辑核心代码分别如下。AWGN信道相对简单只需要根据SNR计算噪声方差然后加性叠加function rxWave passAWGN(txWave, cfg) signalPower mean(abs(txWave).^2); snrLinear 10^(cfg.SNRdB / 10); noisePower signalPower / snrLinear; noise sqrt(noisePower/2) * (randn(size(txWave)) 1j*randn(size(txWave))); rxWave txWave noise; endTDL信道要复杂一些涉及多径时延、多普勒频移、天线相关性。我用5G Toolbox的TDL模型直接调function [rxWave, chInfo] passTDL(txWave, cfg) tdl nrTDLChannel; tdl.DelayProfile TDL-C; % 典型城区多径场景 tdl.DelaySpread 300e-9; % 时延扩展300ns tdl.MaximumDopplerShift 30; % 30Hz多普勒低速移动 tdl.NumTransmitAntennas cfg.numLayers; tdl.NumReceiveAntennas 2; tdl.SampleRate 15.36e6; tdl.ChannelFiltering true; % 重要OFDM调制后的波形要经过信道还要考虑多径带来的延迟 [rxWave, pathGains, sampleTimes] tdl(txWave); chInfo struct(); chInfo.pathGains pathGains; chInfo.sampleTimes sampleTimes; endTDL信道下计算SNR是个容易出错的点。因为多径效应会让接收信号产生频率选择性衰落单纯用mean(abs(txWave).^2)算信号功率是不对的。正确做法是在频域计算每个子载波上的SNR或者利用信道估计结果做MMSE均衡后再测量均衡后符号的信噪比。3.4 接收端处理与吞吐量统计接收端的核心是信道估计、均衡、解调、LDPC解码。我这里用最简单也最稳健的ZF均衡function rxBits receiveAndDecode(rxWave, cfg, chEst) % OFDM解调 rxGrid reshape(rxWave, cfg.scTotal, []); rxGrid rxGrid ./ cfg.scTotal; % 归一化 % 理想信道估计 (仿真中可直接取信道响应) hEst permute(chEst, [2 1 3]); % ZF均衡 hPower sum(abs(hEst).^2, 3); eqGrid zeros(size(rxGrid)); for scIdx 1:cfg.scTotal hMatrix squeeze(hEst(scIdx, :, :)); hInv hMatrix / (hMatrix * hMatrix 1e-10 * eye(cfg.numLayers)); eqGrid(scIdx, :) hInv * rxGrid(scIdx, :).; end % 解调将复符号映射为对数似然比LLR demodLLR nrSymbolDemodulate(eqGrid(:), 256QAM, 8); % LDPC解码 decBits nrLDCPDecode(demodLLR, 1, 50); % 50次迭代 % 码块合并 rxBits nrCodeBlockDesegmentLDPC(decBits, cfg.payloadBits); end这个代码里ZF均衡对噪声有放大效应在低SNR区性能不如MMSE均衡。但实现简单、数值稳定适合做基线版本。实际调试中如果你的曲线在低SNR区掉得太快可以优先考虑换成MMSE均衡。吞吐量统计的逻辑在于只有整个传输块完全正确接收才算成功。一个比特错了也要回退HARQ重传系统实际完成的有效比特就是0。这跟很多人的直觉不一样但反映了MAC层调度的事实。function [throughputMbps, bler] measureThroughput(txBits, rxBits, cfg) nErr sum(txBits ~ rxBits); bler nErr 0; % BLER的单位是“块”不是“比特” if nErr 0 throughputMbps cfg.payloadBits / (cfg.slotMs * 1e-3) / 1e6; else throughputMbps 0; end end3.5 自适应调制编码MCS的简化表达实际NR系统里不同SNR下会动态选择不同的调制编码方式。我的仿真里没有做完整的CQI上报和链路自适应闭环而是用了一个简化模型根据当前SNR直接查表选择能保证BLER低于10%的最高MCS档位。这个表是从TS 38.214的MCS表截取关键节点得到的。SNR范围(dB)MCS索引调制方式目标码率-5 ~ 01QPSK0.280 ~ 55QPSK0.495 ~ 101016QAM0.4810 ~ 151516QAM0.6515 ~ 202164QAM0.7220 ~ 2425256QAM0.7724 ~ 3027256QAM0.93这套映射表让仿真的复杂度大幅降低不用为每个MCS单独跑BLER曲线就能得到符合实际趋势的吞吐量-SNR曲线。工程上这是很常见的“快速评估”手法。如果要精确定标每个SNR下可以多跑几个MCS选择BLER最接近10%的档位这样更接近真实调度器行为但仿真时间会翻好几倍。4. 仿真结果分析与曲线解读4.1 基准场景的吞吐量-SNR结果用上面的代码和参数跑一轮蒙特卡洛仿真10MHz带宽、2层MIMO、256QAM下的结果如下表每个SNR点统计1000个子帧SNR (dB)平均BLER实际吞吐量 (Mbps)峰值效率 (bit/s/Hz)-50.452.80.2800.129.60.9650.0819.51.95100.0638.23.82150.0561.46.14200.0392.89.28250.03124.512.45300.03152.315.23注意这里10MHz带宽下理论峰值大约是240Mbps2层×256QAM×0.93码率但我们在30dB下只跑到152Mbps中间的差距是DMRS、PDCCH、速率匹配和LDPC校验比特等开销吃掉的。这是正常现象真实系统里还有调度开销、HARQ RTT等待可用的用户体验速率更低。4.2 曲线三阶段特征深度解读把曲线画出来后可以清楚地看到三个阶段。低SNR区-5dB ~ 0dB吞吐量非常低曲线斜率也很平缓。原因是这个区间QPSK低码率已经是最低配置了信号功率低于噪声底即使LDPC编码增益再大也救不回来。BLER接近0.5意味着大部分传输块都出错有效吞吐量惨不忍睹。中SNR区0dB ~ 20dB曲线进入陡峭上升段。这个区间MCS档位随着SNR升高快速攀升从QPSK一路升级到256QAM调制阶数和码率同时提升吞吐量呈“跳跃台阶”式上升。台阶的边缘正好对应MCS切换的SNR阈值点。高SNR区20dB ~ 30dB曲线逐渐趋于饱和。到达256QAM、0.93码率的最高档后系统已经没有更高阶的调制方式可用了。后续SNR继续提升只能降低BLER但BLER已经很低收益有限。注意有些网上的博文会把高SNR区画成缓慢上升的直线这是不严谨的。真实系统在固定MCS下SNR再高吞吐量也就封顶了除非带宽或层数能扩展。4.3 参数敏感性对比实验为了验证各个模块对整体性能的贡献我跑了几组对照实验。实验一SISO vs 2层MIMO。同样的10MHz带宽下2层把吞吐量翻了一倍左右。代价是信道估计复杂度提升、终端需要支持2根接收天线。在小区的近点区域MIMO增益明显但在远点低SNR区域双流信道相关性高反而可能因为信道矩阵病态导致性能损失。实验二15kHz vs 30kHz子载波间隔。30kHz间隔下时隙长度减半每个时隙的符号数虽一样但总吞吐量基本不变同带宽下同样的时频资源。差异体现在时延上30kHz能支持更小的调度粒度对URLLC有优势。这个实验验证了eMBB场景下增加SCS不能提升峰值速率。实验三AWGN vs TDL-C信道。TDL-C多径信道下吞吐量曲线整体右移了约3~5dB。也就是说要达到同样的吞吐量多径环境下需要更高的SNR。这是因为频率选择性衰落带来的符号间干扰和子载波间干扰需要额外的均衡增益才能消除。这三组实验放在一起系统设计者就能看到带宽、层数、信道模型三个变量对系统容量的影响权重也能在实际组网时做出更合理的参数选择。5. 常见问题与排查经验实录5.1 吞吐量曲线在低SNR区出现异常尖峰我调试过程中碰到过的最典型问题SNR-5dB时吞吐量竟然比0dB还高。查了半天发现是随机数种子的问题——在低SNR下成功传输的事件概率本来就低如果蒙特卡洛次数不够偶尔一次成功的传输块会被放大成很高的等效吞吐量。解决方法是两个一是加大蒙特卡洛次数我的经验是低SNR点至少跑2000个子帧高SNR点可以少一些二是统计时对结果做滤波或取多次重复实验平均值。仿真不是一次跑完就完事要观察方差。5.2 LDPC解码不收敛导致死循环LDPC迭代解码如果最大迭代次数设得太大在低SNR下会出现解码时间过长的问题。有一次我把最大迭代次数设成300SNR-5dB时一个子帧解码跑了接近2秒整个仿真没法看。后来折中设置为50次迭代并且发现了一个很好的优化技巧解码器可以提前终止即校验方程全部满足时就停止迭代。这在低SNR区特别有用因为大概率会失败尽早止损比硬撑着迭代完省下大量时间。5.3 ZF均衡在深衰落子载波上放大噪声TDL信道下某些子载波可能落在频域深衰落点上信道响应接近0ZF均衡为了恢复信号会把这个子载波上的噪声放大很多倍。这会导致相邻近载波质量还好、但深衰子载波上的LLR质量极差LDPC解码错误率上升。我换成MMSE均衡后性能明显改善。MMSE均衡的公式里加了正则项(h^H*h N0/I)在信道增益小时不会无限放大噪声。模拟中把ZF换成MMSE的差异非常直观也是5G接收机里都不用ZF而用MMSE或更高级均衡器的原因。5.4 仿真时长的合理控制策略链路级仿真的最大敌人就是时间。1000个子帧、8个SNR点、2种层数、2种信道模型全跑一轮可能需要几小时。我的经验是用“分层仿真”的思路第一轮先跑简化模型MCS查表BLER近似不实际做编解码用几分钟得出大致曲线。第二轮只挑3~4个关键SNR点比如曲线拐点附近的点做完整编解码的蒙特卡洛仿真用完整模型校准简化模型。最后用校准后的简化模型满范围扫描出正式曲线。这套流程兼顾效率和精度论文和工程汇报里都够用。6. 后续扩展方向与心得体会仿真的价值在于可以无限扩展。我在基础版本上正计划做几个方向的升级一是把HARQ重传机制加进来研究不同重传次数上限对吞吐量和时延的折中二是加入更多用户干扰信号模拟多用户MIMO场景和小区间干扰协调的效果三是把功控参数对上行吞吐量的影响做进去上行链路和下行链路的行为差异很大功控在低SNR场景下的作用非常关键。最后分享一个小技巧也是我这次调试中的切身感受。在做吞吐量仿真时别只盯着最后的曲线图。中间过程中记录每个SNR点下用到的MCS档位分布、BLER值、码率这些中间变量它们才是理解系统行为的钥匙。曲线是结果MCS选择和BLER是原因。如果哪天你的曲线形状不对一定要回到MCS选择表和BLER分布里去排查问题多半出在那里而不是最终的统计代码。这个项目的源码我已经按模块整理好了主程序、编解码模块、信道模块、统计模块各自独立替换参数和扩展功能都不用动核心框架。有需要的朋友可以直接在这个骨架上做二次开发。本文还有配套的精品资源点击获取
