简介这份资源面向通信工程、无线网络方向的学习者与研究者聚焦LTE系统级仿真中的下行链路建模帮助理解从eNodeB到UE的完整交互流程。包内共40个文件以m脚本文件为主涵盖物理层编码调制、信道估计与均衡、资源映射、调度与链路自适应等模块压缩包约35KB结构紧凑便于逐模块研读。内容围绕PDSCH与PDCCH信道处理、路径损耗与多径衰落等信道模型、时频资源块分配、基于CQI反馈的多用户调度以及邻区干扰处理展开并涉及链路级与系统级仿真的差异对比。SISO单输入单输出配置简化了模型适合作为理解LTE下行链路基本原理的入门实践。目前已有330人学习下载读者可借助脚本参数配置、初始化流程与结果分析代码快速搭建仿真环境评估调度算法、信道编码与功率控制策略对网络容量、覆盖及服务质量的影响。1. 从一份 SISO.zip 说起LTE 下行链路仿真到底能跑出什么很多人第一次拿到SISO.zip这种包解压看到一堆.m文件就懵了——commlteSISO.m、lteTbChannelCoding.m、OFDMTx.m、Equalizer.m名字都认识但连起来不知道从哪下手。我当初也一样以为 LTE 链路仿真得先搭个完整的系统级平台结果翻完README.m才发现这套代码的重心其实在链路级它把下行共享信道PDSCH从传输块生成、CRC 校验、Turbo 编码、速率匹配、加扰、调制、层映射、RE 映射、OFDM 发送一路做到接收端的信道估计、均衡、解调、解扰、译码最后用 BER 和吞吐量告诉你这条链路在 AWGN 或衰落信道下到底能跑多好。它解决的不是“整个蜂窝网络怎么调度”的问题而是“单条下行链路在给定参数下误码率多少、吞吐量多少”的问题。适合谁通信专业做课设或毕设的学生、刚转行做物理层仿真的工程师、以及需要一套可读可改的 LTE 下行参考链来验证自己算法的人。SISO 在这里指单输入单输出天线配置最简反而让基带处理流程看得最清楚。你把它跑通一遍再去看 MIMO 或系统级调度心里就有底了。2. 拆开 commlteSISO主脚本怎么串起整条下行链路2.1 主脚本的调用骨架与参数入口这套代码的入口是commlteSISO.m但它本身不干活真正干活的是commlteSISO_params.m、commlteSISO_initialize.m和commlteSISO_step.m三个文件。我一般把这种结构叫“参数-初始化-步进”三段式参数文件定义带宽、调制阶数、码率、信道类型、SNR 范围初始化文件根据参数预计算所有常量表比如 Turbo 码的交织索引、速率匹配图案、ZC 序列步进文件才是每个子帧真正执行的处理链。先看参数文件里几个必须改对的地方% commlteSISO_params.m 关键参数摘录 prms.NRB 25; % 资源块数25 对应 5 MHz 带宽 prms.CellRefP 1; % 小区参考信号端口数SISO 固定为 1 prms.NSubframe 10; % 仿真子帧数至少 10 才能看到平均 BER prms.Modulation 16QAM; % 调制方式可选 QPSK/16QAM/64QAM prms.Rate 1/2; % 目标码率影响 TBS 和速率匹配 prms.SNRdB 0:2:20; % SNR 扫描范围步长 2 dB 够用 prms.ChannelType AWGN; % 信道类型可选 AWGN 或 EPA/EVA/ETUNRB决定带宽25 个 RB 是 5 MHz50 是 10 MHz100 是 20 MHz。CellRefP在 SISO 里必须是 1改成 2 或 4 会直接报错因为后面ChanEstimate_1Tx.m只处理单端口。NSubframe别设太小我见过有人设成 1结果 BER 曲线抖得像心电图因为每个子帧的 HARQ 冗余版本不同样本太少统计没意义。SNRdB的步长建议 2 dB1 dB 太密跑得慢5 dB 太疏看不出瀑布区拐点。2.2 从传输块到 OFDM 符号发送端处理链发送端的核心在commlteSISO_step.m里按顺序调用genPayload.m、CRCgenerator.m、lteTbChannelCoding.m、lteRateMatching系列、lteScramble.m、Modulator.m、REmapper_1Tx.m、OFDMTx.m。我挑几个容易翻车的环节说。传输块大小不是随便定的它由lteTbChannelCoding.m根据NRB、调制阶数和码率查表得到。比如 25 RB、16QAM、码率 1/2 对应 TBS 大概是 4384 比特。这个值会传给CRCgenerator.m加 24 位 CRC然后进 Turbo 编码器。Turbo 编码的输出是三路系统比特、第一校验、第二校验码率 1/3。要得到目标码率 1/2就得靠lteCbRateMatching.m做打孔或重复。% lteTbChannelCoding.m 中的 Turbo 编码调用片段 tbs lteTbChannelCoding(prms, tbsBits); % tbsBits 是 genPayload 生成的原始比特流 % 输出 tbs 包含 CRC 附加、码块分割、Turbo 编码、速率匹配后的比特这里有个坑码块分割。当 TBS 超过 6144 比特时lteCblkSegParams.m会把传输块切成多个码块每个码块独立加 CRC 和 Turbo 编码。如果你只跑小 TBS 没发现问题一旦把NRB调到 100、64QAMTBS 轻松过 7 万比特分割逻辑不对就会导致译码端lteCbRateDematching.m对不上号BER 直接 0.5。加扰用lteScramble.m它依赖小区 ID 和子帧号生成伪随机序列。小区 ID 在prms.NCellID里设默认是 0。如果你做多小区干扰仿真这个值必须每个小区不同否则加扰序列一样干扰就变成相干叠加结果完全失真。调制用Modulator.m支持 QPSK、16QAM、64QAM内部就是查星座表没什么好说的但要注意它输出的符号是归一化的平均功率为 1后面OFDMTx.m不会再调功率。RE 映射由REmapper_1Tx.m完成它把 PDSCH 符号放到资源网格里同时避开 CRS 占用的 RE。CRS 的位置由CSRgenerator.m生成InterpolateCsr.m和gridResponse_averageSlot.m负责在接收端做信道估计时插值。OFDM 发送OFDMTx.m做 IFFT 和加 CPIFFT 点数由带宽决定25 RB 对应 512 点50 RB 对应 1024 点100 RB 对应 2048 点。CP 长度分常规和扩展prms.CyclicPrefix控制常规 CP 下第一个符号的 CP 比其他符号长这个细节在OFDMTx.m里用ExpungeFrom.m处理。2.3 接收端信道估计、均衡与译码的闭环接收端从OFDMRx.m开始去 CP、FFT、提取资源网格。然后ChanEstimate_1Tx.m用 CRS 做最小二乘估计InterpolateCsr.m在频域和时域插值gridResponse_averageSubframe.m做子帧级平均降噪。我一般会先跑 AWGN 信道验证这条链因为 AWGN 下信道估计应该接近理想如果 BER 还很高说明估计或均衡有问题。均衡用Equalizer.mSISO 下就是单抽头迫零或 MMSE。代码里默认是 MMSE需要噪声功率估计这个值从AWGNChannel.m或MIMOFadingChan.m的输出里拿。如果你把信道类型改成 EPAMIMOFadingChan.m会生成多径衰落系数Equalizer.m就得处理频域选择性这时候gridResponse_interpolate.m的插值精度直接影响性能。解调DemodulatorSoft.m输出软比特LLR然后lteDescramble.m解扰lteCbRateDematching.m做速率解匹配lteTbChannelDecoding.m做 Turbo 译码。Turbo 译码是迭代的默认迭代 6 次可以在prms.MaxIter里改。迭代次数越多性能越好但越慢我一般 AWGN 下 4 次就够衰落信道下 8 次。% commlteSISO_step.m 接收端核心调用顺序 rxGrid OFDMRx(rxWaveform, prms); chEst ChanEstimate_1Tx(rxGrid, prms); chEst InterpolateCsr(chEst, prms); eqSym Equalizer(rxGrid, chEst, prms); llr DemodulatorSoft(eqSym, prms); descrambled lteDescramble(llr, prms); rateMatched lteCbRateDematching(descrambled, prms); decoded lteTbChannelDecoding(rateMatched, prms);最后CRCdetector.m检查译码后的传输块 CRC 是否正确zReport_data_rate.m统计吞吐量zVisualize.m画 BER 曲线。commlteSISO_test_timing_ber.m是个测试脚本跑一遍能输出不同 SNR 下的 BER 和吞吐量我建议第一次跑就用它别自己从头搭循环。3. 参数怎么设从 AWGN 到衰落信道的配置清单3.1 带宽、调制与码率的组合约束LTE 下行链路仿真里NRB、调制阶数、码率、TBS 四者是绑死的。你不能随便说“我要 20 MHz 带宽、64QAM、码率 0.9”因为 TBS 表里最大也就 75376 比特20 MHz、64QAM、码率约 0.75。lteTbChannelCoding.m内部查的是 36.213 协议里的 TBS 表超出范围会报错或截断。我整理了一个常用组合表跑仿真时直接对照NRB带宽调制码率近似 TBS适用场景255 MHzQPSK1/31256覆盖受限场景255 MHz16QAM1/24384常规链路验证5010 MHz16QAM2/312576中等负载5010 MHz64QAM3/421384高吞吐验证10020 MHz64QAM3/443816峰值速率测试注意码率不是直接设的而是通过prms.Rate给目标值实际码率由 TBS 和可用 RE 数反推。如果你设Rate0.5但 TBS 表里没有正好 0.5 的项代码会选最接近的。这个“最接近”的逻辑在lteCbRateMatching.m里打孔图案会变所以别指望实际码率精确等于你设的值。3.2 信道模型选择AWGN、EPA、EVA、ETU 的区别prms.ChannelType控制用哪个信道。AWGN 最简单只加高斯白噪声没有多径适合验证基带链本身。EPAExtended Pedestrian A是低时延扩展最大多径时延 410 ns适合低速移动。EVAExtended Vehicular A时延扩展到 2510 ns适合中速。ETUExtended Typical Urban最大5000 ns适合高速。选信道不是拍脑袋要看你的仿真目的。验证编译码性能用 AWGN验证均衡和信道估计用 EPA 或 EVA验证高速场景用 ETU。MIMOFadingChan.m里实现了这些模型的多径抽头系数和多普勒频移。多普勒频移由prms.DopplerFreq设比如 70 Hz 对应 300 km/h2.6 GHz 载波。如果你不设默认是 0那就变成静态多径没有时间选择性信道估计的时域插值就退化成简单平均。% MIMOFadingChan.m 中 EPA 模型的部分抽头配置 switch prms.ChannelType case EPA delays [0 30 70 90 110 190 410] * 1e-9; % 秒 powers [0.0 -1.0 -2.0 -3.0 -8.0 -17.2 -20.8]; % dB doppler prms.DopplerFreq; case EVA delays [0 30 150 310 370 710 1090 1730 2510] * 1e-9; powers [0.0 -1.5 -1.4 -3.6 -0.6 -9.1 -7.0 -12.0 -16.9]; case ETU delays [0 50 120 200 230 500 1600 2300 5000] * 1e-9; powers [-1.0 -1.0 -1.0 0.0 0.0 0.0 -3.0 -5.0 -7.0]; end这些抽头系数来自 36.101 协议别自己改。改了之后Equalizer.m的 MMSE 权重计算会失配BER 曲线会莫名其妙抬高。我见过有人把 EPA 的时延改成微秒级结果 CP 长度不够符号间干扰直接让 BER 卡在 0.3 下不去。3.3 SNR 扫描与 BER 统计的实操细节SNR 定义是每资源粒子能量与噪声功率谱密度之比Es/N0不是 Eb/N0。AWGNChannel.m里根据prms.SNRdB计算噪声方差加到接收波形上。这里有个容易忽略的点噪声方差的计算依赖带宽和采样率如果你改了NRB但没改采样率噪声功率就错了。% AWGNChannel.m 中噪声功率计算 SNR_linear 10^(prms.SNRdB/10); signalPower mean(abs(rxWaveform).^2); noisePower signalPower / SNR_linear; noise sqrt(noisePower/2) * (randn(size(rxWaveform)) 1j*randn(size(rxWaveform))); rxWaveform rxWaveform noise;这段代码假设信号功率已知但实际中rxWaveform是发送端输出的功率归一化过。如果你在发送端加了功率控制或预编码信号功率变了噪声功率就得跟着调。我一般会在加噪声前重新测一次signalPower别用理论值。BER 统计要跑够子帧数。prms.NSubframe10在 SNR 低时 BER 可能只有几个错误统计不收敛。我一般 SNR 低于 5 dB 时跑 100 个子帧高于 15 dB 时跑 10 个就够因为错误太少跑多了浪费时间。commlteSISO_test_timing_ber.m里有个自适应停止逻辑可以设prms.MaxErrors100错误数到了就停。4. 避坑与排查跑不出瀑布曲线的五个血泪经验4.1 BER 卡在 0.5 不下降现象跑 AWGN 信道SNR 从 0 扫到 20 dBBER 始终在 0.5 附近完全没有瀑布区。原因最常见的是加扰序列对不上。lteScramble.m和lteDescramble.m用的伪随机序列初始值依赖prms.NCellID和子帧号。如果发送端和接收端的NCellID不一致或者子帧号在步进过程中没同步解扰后的比特就是随机的。另一个可能是 CRC 校验没通过但代码没报错直接拿错误比特去统计 BER。解决先检查prms.NCellID在发送和接收调用中是否一致。然后在lteDescramble.m后面加一句assert(isequal(size(descrambled), size(scrambled)))确认维度对得上。最后在CRCdetector.m输出为 0 时打印警告别让错误静默传播。4.2 信道估计后均衡输出全是零现象Equalizer.m输出的符号幅度接近零解调后 LLR 全是极大值译码直接失败。原因ChanEstimate_1Tx.m依赖 CRS 位置而 CRS 位置由CSRgenerator.m根据NCellID和NSubframe生成。如果你改了NCellID但没重新初始化 CRS 表或者InterpolateCsr.m的插值范围超出了实际 CRS 分布估计出的信道响应就是零。另一个可能是REmapper_1Tx.m把 PDSCH 映射到了 CRS 占用的 RE 上接收端提取的 CRS 被数据污染。解决在ChanEstimate_1Tx.m里加断点看chEst的幅度是否非零。如果是零检查CSRgenerator.m的调用参数。然后在REmapper_1Tx.m里确认 PDSCH 的 RE 索引避开了 CRS 索引这个逻辑在prms.PDSCHRE里预计算别手动改。4.3 Turbo 译码迭代不收敛现象lteTbChannelDecoding.m跑完迭代后 CRC 仍然错误BER 比理论值高一个数量级。原因速率解匹配的打孔图案和发送端不一致。lteCbRateMatching.m和lteCbRateDematching.m必须用同一套lteIntrlvrIndices.m生成的交织索引。如果你在发送端改了码率但没更新交织表解匹配时软比特的位置就全错了。另一个可能是DemodulatorSoft.m输出的 LLR 符号反了LTE 里比特 0 对应正 LLR比特 1 对应负 LLR反了之后 Turbo 译码会往错误方向收敛。解决在lteCbRateMatching.m和lteCbRateDematching.m里打印交织索引的前 10 个值确认一致。然后在DemodulatorSoft.m里检查星座映射表QPSK 的 LLR 计算是real(rxSym)还是-real(rxSym)对照协议 36.211 的星座图。4.4 吞吐量统计比理论值低很多现象zReport_data_rate.m输出的吞吐量只有理论峰值的一半甚至更低。原因prms.NSubframe设得太小或者zReport_data_rate.m把控制信道开销也算进去了。LTE 下行里 PDCCH 占前 1-3 个 OFDM 符号CRS 占每个 RB 的固定 RE这些都不承载用户数据。如果你用NRB * 12 * 14 * 调制阶数 * 码率算理论值没扣掉开销对比就会觉得实际吞吐量低。另一个可能是 HARQ 冗余版本没轮换每次重传都用同一个版本增益出不来。解决在zReport_data_rate.m里把 PDCCH 和 CRS 的 RE 数扣掉再算。HARQ 版本在prms.RV里设默认是[0 2 3 1]循环别改成固定值。4.5 换信道模型后代码报维度错误现象把prms.ChannelType从AWGN改成EPAMIMOFadingChan.m报矩阵维度不匹配。原因MIMOFadingChan.m输出的多径信道系数维度依赖prms.NRxAnts和prms.NTxAnts。SISO 下这两个都是 1但如果你在参数文件里不小心把NRxAnts改成 2Equalizer.m就会按 2 接收天线处理维度对不上。另一个可能是prms.DopplerFreq没设默认空数组MIMOFadingChan.m里做多普勒滤波时出错。解决确认prms.NTxAnts1和prms.NRxAnts1。在MIMOFadingChan.m开头加assert(prms.NTxAnts1 prms.NRxAnts1, SISO only)。DopplerFreq至少设 0别留空。5. 进阶技巧用 zVisualize 和 timing_ber 做自动化验证5.1 把 BER 曲线和吞吐量曲线画在一张图里zVisualize.m默认只画 BER但你可以改几行让它同时输出吞吐量。我一般会在commlteSISO_test_timing_ber.m跑完后把zReport_data_rate.m的结果存到results结构体里然后调zVisualize时传进去。% 在 commlteSISO_test_timing_ber.m 末尾添加 results.ber berVec; results.throughput tputVec; results.snr prms.SNRdB; zVisualize(results, both); % 自定义选项同时画 BER 和吞吐量然后在zVisualize.m里加一个case both用yyaxis left画 BER对数坐标yyaxis right画吞吐量线性坐标。这样一眼就能看出瀑布区对应的吞吐量拐点比看两个图方便。5.2 用 timing_ber 做参数扫描的批量跑法commlteSISO_test_timing_ber.m本身是个脚本但你可以把它包成函数外层用parfor并行扫参数。比如固定 SNR10 dB扫NRB从 25 到 100看吞吐量怎么变。nrbList [25 50 75 100]; tputResults zeros(size(nrbList)); parfor idx 1:length(nrbList) prms commlteSISO_params(); prms.NRB nrbList(idx); prms.SNRdB 10; prms.NSubframe 50; [ber, tput] commlteSISO_test_timing_ber(prms); tputResults(idx) tput; end disp(table(nrbList, tputResults, VariableNames, {NRB, Throughput_Mbps}));注意parfor里每个 worker 要独立调commlteSISO_params()别共享prms结构体否则并行写冲突。commlteSISO_initialize.m里的常量表也要每个 worker 重新生成因为 Turbo 交织索引依赖NRB。5.3 验证译码正确性的一个笨办法但管用如果你怀疑 Turbo 译码有问题但又没有标准参考可以用一个笨办法把lteTbChannelDecoding.m的输入软比特直接换成发送端的编码比特硬判决跳过信道和均衡。如果这样译码 CRC 还错那问题就在编译码本身如果对了问题在信道估计或均衡。% 在 commlteSISO_step.m 里临时加一个旁路开关 if prms.BypassChannel llr 2 * (txBits - 0.5); % 把 0/1 比特转成 ±1 LLR else llr DemodulatorSoft(eqSym, prms); end这个开关我每次调新链路都会加跑通了再关掉。虽然土但能省很多排查时间。从那以后我每次拿到新的链路仿真代码都强制先跑一遍旁路验证确认编译码闭环没问题再去调信道和均衡。希望帮到你。本文还有配套的精品资源点击获取 LTE下行链路仿真实战：SISO链路从参数配置到BER瀑布曲线避坑指南
简介这份资源面向通信工程、无线网络方向的学习者与研究者聚焦LTE系统级仿真中的下行链路建模帮助理解从eNodeB到UE的完整交互流程。包内共40个文件以m脚本文件为主涵盖物理层编码调制、信道估计与均衡、资源映射、调度与链路自适应等模块压缩包约35KB结构紧凑便于逐模块研读。内容围绕PDSCH与PDCCH信道处理、路径损耗与多径衰落等信道模型、时频资源块分配、基于CQI反馈的多用户调度以及邻区干扰处理展开并涉及链路级与系统级仿真的差异对比。SISO单输入单输出配置简化了模型适合作为理解LTE下行链路基本原理的入门实践。目前已有330人学习下载读者可借助脚本参数配置、初始化流程与结果分析代码快速搭建仿真环境评估调度算法、信道编码与功率控制策略对网络容量、覆盖及服务质量的影响。1. 从一份 SISO.zip 说起LTE 下行链路仿真到底能跑出什么很多人第一次拿到SISO.zip这种包解压看到一堆.m文件就懵了——commlteSISO.m、lteTbChannelCoding.m、OFDMTx.m、Equalizer.m名字都认识但连起来不知道从哪下手。我当初也一样以为 LTE 链路仿真得先搭个完整的系统级平台结果翻完README.m才发现这套代码的重心其实在链路级它把下行共享信道PDSCH从传输块生成、CRC 校验、Turbo 编码、速率匹配、加扰、调制、层映射、RE 映射、OFDM 发送一路做到接收端的信道估计、均衡、解调、解扰、译码最后用 BER 和吞吐量告诉你这条链路在 AWGN 或衰落信道下到底能跑多好。它解决的不是“整个蜂窝网络怎么调度”的问题而是“单条下行链路在给定参数下误码率多少、吞吐量多少”的问题。适合谁通信专业做课设或毕设的学生、刚转行做物理层仿真的工程师、以及需要一套可读可改的 LTE 下行参考链来验证自己算法的人。SISO 在这里指单输入单输出天线配置最简反而让基带处理流程看得最清楚。你把它跑通一遍再去看 MIMO 或系统级调度心里就有底了。2. 拆开 commlteSISO主脚本怎么串起整条下行链路2.1 主脚本的调用骨架与参数入口这套代码的入口是commlteSISO.m但它本身不干活真正干活的是commlteSISO_params.m、commlteSISO_initialize.m和commlteSISO_step.m三个文件。我一般把这种结构叫“参数-初始化-步进”三段式参数文件定义带宽、调制阶数、码率、信道类型、SNR 范围初始化文件根据参数预计算所有常量表比如 Turbo 码的交织索引、速率匹配图案、ZC 序列步进文件才是每个子帧真正执行的处理链。先看参数文件里几个必须改对的地方% commlteSISO_params.m 关键参数摘录 prms.NRB 25; % 资源块数25 对应 5 MHz 带宽 prms.CellRefP 1; % 小区参考信号端口数SISO 固定为 1 prms.NSubframe 10; % 仿真子帧数至少 10 才能看到平均 BER prms.Modulation 16QAM; % 调制方式可选 QPSK/16QAM/64QAM prms.Rate 1/2; % 目标码率影响 TBS 和速率匹配 prms.SNRdB 0:2:20; % SNR 扫描范围步长 2 dB 够用 prms.ChannelType AWGN; % 信道类型可选 AWGN 或 EPA/EVA/ETUNRB决定带宽25 个 RB 是 5 MHz50 是 10 MHz100 是 20 MHz。CellRefP在 SISO 里必须是 1改成 2 或 4 会直接报错因为后面ChanEstimate_1Tx.m只处理单端口。NSubframe别设太小我见过有人设成 1结果 BER 曲线抖得像心电图因为每个子帧的 HARQ 冗余版本不同样本太少统计没意义。SNRdB的步长建议 2 dB1 dB 太密跑得慢5 dB 太疏看不出瀑布区拐点。2.2 从传输块到 OFDM 符号发送端处理链发送端的核心在commlteSISO_step.m里按顺序调用genPayload.m、CRCgenerator.m、lteTbChannelCoding.m、lteRateMatching系列、lteScramble.m、Modulator.m、REmapper_1Tx.m、OFDMTx.m。我挑几个容易翻车的环节说。传输块大小不是随便定的它由lteTbChannelCoding.m根据NRB、调制阶数和码率查表得到。比如 25 RB、16QAM、码率 1/2 对应 TBS 大概是 4384 比特。这个值会传给CRCgenerator.m加 24 位 CRC然后进 Turbo 编码器。Turbo 编码的输出是三路系统比特、第一校验、第二校验码率 1/3。要得到目标码率 1/2就得靠lteCbRateMatching.m做打孔或重复。% lteTbChannelCoding.m 中的 Turbo 编码调用片段 tbs lteTbChannelCoding(prms, tbsBits); % tbsBits 是 genPayload 生成的原始比特流 % 输出 tbs 包含 CRC 附加、码块分割、Turbo 编码、速率匹配后的比特这里有个坑码块分割。当 TBS 超过 6144 比特时lteCblkSegParams.m会把传输块切成多个码块每个码块独立加 CRC 和 Turbo 编码。如果你只跑小 TBS 没发现问题一旦把NRB调到 100、64QAMTBS 轻松过 7 万比特分割逻辑不对就会导致译码端lteCbRateDematching.m对不上号BER 直接 0.5。加扰用lteScramble.m它依赖小区 ID 和子帧号生成伪随机序列。小区 ID 在prms.NCellID里设默认是 0。如果你做多小区干扰仿真这个值必须每个小区不同否则加扰序列一样干扰就变成相干叠加结果完全失真。调制用Modulator.m支持 QPSK、16QAM、64QAM内部就是查星座表没什么好说的但要注意它输出的符号是归一化的平均功率为 1后面OFDMTx.m不会再调功率。RE 映射由REmapper_1Tx.m完成它把 PDSCH 符号放到资源网格里同时避开 CRS 占用的 RE。CRS 的位置由CSRgenerator.m生成InterpolateCsr.m和gridResponse_averageSlot.m负责在接收端做信道估计时插值。OFDM 发送OFDMTx.m做 IFFT 和加 CPIFFT 点数由带宽决定25 RB 对应 512 点50 RB 对应 1024 点100 RB 对应 2048 点。CP 长度分常规和扩展prms.CyclicPrefix控制常规 CP 下第一个符号的 CP 比其他符号长这个细节在OFDMTx.m里用ExpungeFrom.m处理。2.3 接收端信道估计、均衡与译码的闭环接收端从OFDMRx.m开始去 CP、FFT、提取资源网格。然后ChanEstimate_1Tx.m用 CRS 做最小二乘估计InterpolateCsr.m在频域和时域插值gridResponse_averageSubframe.m做子帧级平均降噪。我一般会先跑 AWGN 信道验证这条链因为 AWGN 下信道估计应该接近理想如果 BER 还很高说明估计或均衡有问题。均衡用Equalizer.mSISO 下就是单抽头迫零或 MMSE。代码里默认是 MMSE需要噪声功率估计这个值从AWGNChannel.m或MIMOFadingChan.m的输出里拿。如果你把信道类型改成 EPAMIMOFadingChan.m会生成多径衰落系数Equalizer.m就得处理频域选择性这时候gridResponse_interpolate.m的插值精度直接影响性能。解调DemodulatorSoft.m输出软比特LLR然后lteDescramble.m解扰lteCbRateDematching.m做速率解匹配lteTbChannelDecoding.m做 Turbo 译码。Turbo 译码是迭代的默认迭代 6 次可以在prms.MaxIter里改。迭代次数越多性能越好但越慢我一般 AWGN 下 4 次就够衰落信道下 8 次。% commlteSISO_step.m 接收端核心调用顺序 rxGrid OFDMRx(rxWaveform, prms); chEst ChanEstimate_1Tx(rxGrid, prms); chEst InterpolateCsr(chEst, prms); eqSym Equalizer(rxGrid, chEst, prms); llr DemodulatorSoft(eqSym, prms); descrambled lteDescramble(llr, prms); rateMatched lteCbRateDematching(descrambled, prms); decoded lteTbChannelDecoding(rateMatched, prms);最后CRCdetector.m检查译码后的传输块 CRC 是否正确zReport_data_rate.m统计吞吐量zVisualize.m画 BER 曲线。commlteSISO_test_timing_ber.m是个测试脚本跑一遍能输出不同 SNR 下的 BER 和吞吐量我建议第一次跑就用它别自己从头搭循环。3. 参数怎么设从 AWGN 到衰落信道的配置清单3.1 带宽、调制与码率的组合约束LTE 下行链路仿真里NRB、调制阶数、码率、TBS 四者是绑死的。你不能随便说“我要 20 MHz 带宽、64QAM、码率 0.9”因为 TBS 表里最大也就 75376 比特20 MHz、64QAM、码率约 0.75。lteTbChannelCoding.m内部查的是 36.213 协议里的 TBS 表超出范围会报错或截断。我整理了一个常用组合表跑仿真时直接对照NRB带宽调制码率近似 TBS适用场景255 MHzQPSK1/31256覆盖受限场景255 MHz16QAM1/24384常规链路验证5010 MHz16QAM2/312576中等负载5010 MHz64QAM3/421384高吞吐验证10020 MHz64QAM3/443816峰值速率测试注意码率不是直接设的而是通过prms.Rate给目标值实际码率由 TBS 和可用 RE 数反推。如果你设Rate0.5但 TBS 表里没有正好 0.5 的项代码会选最接近的。这个“最接近”的逻辑在lteCbRateMatching.m里打孔图案会变所以别指望实际码率精确等于你设的值。3.2 信道模型选择AWGN、EPA、EVA、ETU 的区别prms.ChannelType控制用哪个信道。AWGN 最简单只加高斯白噪声没有多径适合验证基带链本身。EPAExtended Pedestrian A是低时延扩展最大多径时延 410 ns适合低速移动。EVAExtended Vehicular A时延扩展到 2510 ns适合中速。ETUExtended Typical Urban最大5000 ns适合高速。选信道不是拍脑袋要看你的仿真目的。验证编译码性能用 AWGN验证均衡和信道估计用 EPA 或 EVA验证高速场景用 ETU。MIMOFadingChan.m里实现了这些模型的多径抽头系数和多普勒频移。多普勒频移由prms.DopplerFreq设比如 70 Hz 对应 300 km/h2.6 GHz 载波。如果你不设默认是 0那就变成静态多径没有时间选择性信道估计的时域插值就退化成简单平均。% MIMOFadingChan.m 中 EPA 模型的部分抽头配置 switch prms.ChannelType case EPA delays [0 30 70 90 110 190 410] * 1e-9; % 秒 powers [0.0 -1.0 -2.0 -3.0 -8.0 -17.2 -20.8]; % dB doppler prms.DopplerFreq; case EVA delays [0 30 150 310 370 710 1090 1730 2510] * 1e-9; powers [0.0 -1.5 -1.4 -3.6 -0.6 -9.1 -7.0 -12.0 -16.9]; case ETU delays [0 50 120 200 230 500 1600 2300 5000] * 1e-9; powers [-1.0 -1.0 -1.0 0.0 0.0 0.0 -3.0 -5.0 -7.0]; end这些抽头系数来自 36.101 协议别自己改。改了之后Equalizer.m的 MMSE 权重计算会失配BER 曲线会莫名其妙抬高。我见过有人把 EPA 的时延改成微秒级结果 CP 长度不够符号间干扰直接让 BER 卡在 0.3 下不去。3.3 SNR 扫描与 BER 统计的实操细节SNR 定义是每资源粒子能量与噪声功率谱密度之比Es/N0不是 Eb/N0。AWGNChannel.m里根据prms.SNRdB计算噪声方差加到接收波形上。这里有个容易忽略的点噪声方差的计算依赖带宽和采样率如果你改了NRB但没改采样率噪声功率就错了。% AWGNChannel.m 中噪声功率计算 SNR_linear 10^(prms.SNRdB/10); signalPower mean(abs(rxWaveform).^2); noisePower signalPower / SNR_linear; noise sqrt(noisePower/2) * (randn(size(rxWaveform)) 1j*randn(size(rxWaveform))); rxWaveform rxWaveform noise;这段代码假设信号功率已知但实际中rxWaveform是发送端输出的功率归一化过。如果你在发送端加了功率控制或预编码信号功率变了噪声功率就得跟着调。我一般会在加噪声前重新测一次signalPower别用理论值。BER 统计要跑够子帧数。prms.NSubframe10在 SNR 低时 BER 可能只有几个错误统计不收敛。我一般 SNR 低于 5 dB 时跑 100 个子帧高于 15 dB 时跑 10 个就够因为错误太少跑多了浪费时间。commlteSISO_test_timing_ber.m里有个自适应停止逻辑可以设prms.MaxErrors100错误数到了就停。4. 避坑与排查跑不出瀑布曲线的五个血泪经验4.1 BER 卡在 0.5 不下降现象跑 AWGN 信道SNR 从 0 扫到 20 dBBER 始终在 0.5 附近完全没有瀑布区。原因最常见的是加扰序列对不上。lteScramble.m和lteDescramble.m用的伪随机序列初始值依赖prms.NCellID和子帧号。如果发送端和接收端的NCellID不一致或者子帧号在步进过程中没同步解扰后的比特就是随机的。另一个可能是 CRC 校验没通过但代码没报错直接拿错误比特去统计 BER。解决先检查prms.NCellID在发送和接收调用中是否一致。然后在lteDescramble.m后面加一句assert(isequal(size(descrambled), size(scrambled)))确认维度对得上。最后在CRCdetector.m输出为 0 时打印警告别让错误静默传播。4.2 信道估计后均衡输出全是零现象Equalizer.m输出的符号幅度接近零解调后 LLR 全是极大值译码直接失败。原因ChanEstimate_1Tx.m依赖 CRS 位置而 CRS 位置由CSRgenerator.m根据NCellID和NSubframe生成。如果你改了NCellID但没重新初始化 CRS 表或者InterpolateCsr.m的插值范围超出了实际 CRS 分布估计出的信道响应就是零。另一个可能是REmapper_1Tx.m把 PDSCH 映射到了 CRS 占用的 RE 上接收端提取的 CRS 被数据污染。解决在ChanEstimate_1Tx.m里加断点看chEst的幅度是否非零。如果是零检查CSRgenerator.m的调用参数。然后在REmapper_1Tx.m里确认 PDSCH 的 RE 索引避开了 CRS 索引这个逻辑在prms.PDSCHRE里预计算别手动改。4.3 Turbo 译码迭代不收敛现象lteTbChannelDecoding.m跑完迭代后 CRC 仍然错误BER 比理论值高一个数量级。原因速率解匹配的打孔图案和发送端不一致。lteCbRateMatching.m和lteCbRateDematching.m必须用同一套lteIntrlvrIndices.m生成的交织索引。如果你在发送端改了码率但没更新交织表解匹配时软比特的位置就全错了。另一个可能是DemodulatorSoft.m输出的 LLR 符号反了LTE 里比特 0 对应正 LLR比特 1 对应负 LLR反了之后 Turbo 译码会往错误方向收敛。解决在lteCbRateMatching.m和lteCbRateDematching.m里打印交织索引的前 10 个值确认一致。然后在DemodulatorSoft.m里检查星座映射表QPSK 的 LLR 计算是real(rxSym)还是-real(rxSym)对照协议 36.211 的星座图。4.4 吞吐量统计比理论值低很多现象zReport_data_rate.m输出的吞吐量只有理论峰值的一半甚至更低。原因prms.NSubframe设得太小或者zReport_data_rate.m把控制信道开销也算进去了。LTE 下行里 PDCCH 占前 1-3 个 OFDM 符号CRS 占每个 RB 的固定 RE这些都不承载用户数据。如果你用NRB * 12 * 14 * 调制阶数 * 码率算理论值没扣掉开销对比就会觉得实际吞吐量低。另一个可能是 HARQ 冗余版本没轮换每次重传都用同一个版本增益出不来。解决在zReport_data_rate.m里把 PDCCH 和 CRS 的 RE 数扣掉再算。HARQ 版本在prms.RV里设默认是[0 2 3 1]循环别改成固定值。4.5 换信道模型后代码报维度错误现象把prms.ChannelType从AWGN改成EPAMIMOFadingChan.m报矩阵维度不匹配。原因MIMOFadingChan.m输出的多径信道系数维度依赖prms.NRxAnts和prms.NTxAnts。SISO 下这两个都是 1但如果你在参数文件里不小心把NRxAnts改成 2Equalizer.m就会按 2 接收天线处理维度对不上。另一个可能是prms.DopplerFreq没设默认空数组MIMOFadingChan.m里做多普勒滤波时出错。解决确认prms.NTxAnts1和prms.NRxAnts1。在MIMOFadingChan.m开头加assert(prms.NTxAnts1 prms.NRxAnts1, SISO only)。DopplerFreq至少设 0别留空。5. 进阶技巧用 zVisualize 和 timing_ber 做自动化验证5.1 把 BER 曲线和吞吐量曲线画在一张图里zVisualize.m默认只画 BER但你可以改几行让它同时输出吞吐量。我一般会在commlteSISO_test_timing_ber.m跑完后把zReport_data_rate.m的结果存到results结构体里然后调zVisualize时传进去。% 在 commlteSISO_test_timing_ber.m 末尾添加 results.ber berVec; results.throughput tputVec; results.snr prms.SNRdB; zVisualize(results, both); % 自定义选项同时画 BER 和吞吐量然后在zVisualize.m里加一个case both用yyaxis left画 BER对数坐标yyaxis right画吞吐量线性坐标。这样一眼就能看出瀑布区对应的吞吐量拐点比看两个图方便。5.2 用 timing_ber 做参数扫描的批量跑法commlteSISO_test_timing_ber.m本身是个脚本但你可以把它包成函数外层用parfor并行扫参数。比如固定 SNR10 dB扫NRB从 25 到 100看吞吐量怎么变。nrbList [25 50 75 100]; tputResults zeros(size(nrbList)); parfor idx 1:length(nrbList) prms commlteSISO_params(); prms.NRB nrbList(idx); prms.SNRdB 10; prms.NSubframe 50; [ber, tput] commlteSISO_test_timing_ber(prms); tputResults(idx) tput; end disp(table(nrbList, tputResults, VariableNames, {NRB, Throughput_Mbps}));注意parfor里每个 worker 要独立调commlteSISO_params()别共享prms结构体否则并行写冲突。commlteSISO_initialize.m里的常量表也要每个 worker 重新生成因为 Turbo 交织索引依赖NRB。5.3 验证译码正确性的一个笨办法但管用如果你怀疑 Turbo 译码有问题但又没有标准参考可以用一个笨办法把lteTbChannelDecoding.m的输入软比特直接换成发送端的编码比特硬判决跳过信道和均衡。如果这样译码 CRC 还错那问题就在编译码本身如果对了问题在信道估计或均衡。% 在 commlteSISO_step.m 里临时加一个旁路开关 if prms.BypassChannel llr 2 * (txBits - 0.5); % 把 0/1 比特转成 ±1 LLR else llr DemodulatorSoft(eqSym, prms); end这个开关我每次调新链路都会加跑通了再关掉。虽然土但能省很多排查时间。从那以后我每次拿到新的链路仿真代码都强制先跑一遍旁路验证确认编译码闭环没问题再去调信道和均衡。希望帮到你。本文还有配套的精品资源点击获取