简介5GLLSimulator_v1.1是面向5G通信链路级仿真的MATLAB平台聚焦物理层与数据链路层性能评估适合研究人员、工程师和通信专业学生使用。压缩包共76个文件以.m仿真脚本为主并含PDF说明文档、C源码、mexw64编译模块和.mat参考数据整体约7.76MB目录按编码、调制、MIMO、信道估计等模块组织便于按需查阅。平台提供预定义场景和自定义场景两种操作模式可模拟OFDM、MIMO、多用户调度、波束赋形等5G关键技术也能灵活设定基站位置、终端分布和频率资源适配城市、农村、室内等不同无线环境。目前已有2295人学习配套用户手册、特性列表及LTE/5G参考曲线数据可帮助快速上手并能基于参考结果对仿真输出进行对比分析为学术研究与系统优化提供支撑。无论是教学演示还是预研验证这套仿真平台都能带来直观的链路级性能洞察。1. 5G链路级仿真平台物理层算法验证的第一道门槛做 5G 物理层算法的人几乎每天都要面对同一个问题手里有一个新想法比如改进的 LDPC 译码器、新的信道估计算法想验证它到底行不行。直接上系统级仿真太慢一个点跑几个小时改成硬件测试又太贵还没到那个阶段。5G链路级仿真平台解决的就是这个中间环节——在点对点的单链路上把发送端基带处理、信道模型、接收端估计与译码串成一条闭环快速输出误块率和误码率曲线。对于做物理层算法、芯片基带验证和协议栈对接的从业者它是起步的第一道门槛绕不开。这个平台的价值在于可控信道模型可选、参数可配、结果可复现同一个算法在不同信噪比下的性能差异一目了然。我接触过的物理层团队里几乎每个人都会维护一套自己的链路级仿真环境因为外部的商用工具要么太封闭要么和实际算法的绑定太深。接下来的内容我按自己做平台的习惯来拆先想清楚它和系统级仿真的边界再把最小闭环搭起来最后把参数和坑讲透。2. 链路级仿真的边界与价值它和系统级差在哪平台由哪些模块组成2.1 链路级 vs 系统级BLER曲线和吞吐量仿真不是一回事链路级仿真和系统级仿真经常被混着提但两者解决的问题完全不同。链路级关心的是给定一个信道条件这条物理链路能传多好输出的是误块率BLER、误码率BER和星座图这类物理层指标。系统级仿真关心的是整个小区里多个用户互相干扰时网络能跑多快输出的是吞吐量、时延和覆盖率分布。这个区别决定了仿真建模的粒度。对比维度链路级仿真系统级仿真仿真对象单链路、点对点多小区、多用户核心指标BLER、BER、吞吐量上限吞吐量、时延、覆盖率是否建模调度不建模或简化必须建模是否建模干扰只建模信道噪声与衰落建模小区间干扰单次仿真代价秒级到分钟级小时级到天级我在实际工作中判断一个算法改动该用哪一级仿真标准很简单如果改动发生在调制、编码、信道估计、均衡这些物理层处理链上用链路级如果改动影响调度、功率控制、波束管理这些高层决策才考虑系统级。链路级仿真做的其实是物理层算法的单元测试系统级才是集成测试。把算法放上系统级之前先用链路级把性能边界摸清楚能省掉大量无效的系统级仿真时间。2.2 平台的最小闭环从发送端到接收端的模块清单一个能用的5G链路级仿真平台无论代码怎么组织底层都是一条完整的收发链路。我把它拆成三部分发送端、信道、接收端。发送端负责把传输块编码成可发射的时域波形信道负责叠加衰落和噪声接收端做逆过程把比特还原出来并统计错误。发送端模块的顺序基本是固定的CRC附加、信道编码、速率匹配、加扰、调制、层映射、资源映射、OFDM调制。接收端是它的镜像OFDM解调、信道估计、均衡、解调、解扰、速率匹配、译码、CRC校验。中间夹着信道模型。每个模块都不复杂难的是把它们按协议参数串起来任何一个环节的配置漂移最终都会反映在曲线上。模块清单看起来很长但核心就一句话发端编码算出来的比特数必须和收端译码前拿到的软比特数对得上。这就是闭环的含义。我之前见过一个平台速率匹配的长度算错了一位导致高信噪比下误码率永远下不去排查了两天才发现是资源映射时少算了导频占用的资源单元。所以搭平台时我习惯先把每个模块的输入输出尺寸打出来核对一遍再开始调算法。2.3 实现选型MATLAB为主Python做辅助选实现语言是搭平台前最实际的问题。我见过用C写的链路级仿真性能确实好但调试成本太高也见过纯Python的灵活但通信生态碎片化协议参数表要自己整理。最终绝大多数人还是选了MATLAB核心原因是5G工具箱里已经把协议处理锚点实现了CRC编码、LDPC编译码、速率匹配、OFDM调制、TDL信道模型这些都有标准接口你只需要组织流程和参数不需要从零实现协议。Python适合做辅助角色比如跑批量参数扫描、画曲线、做统计或者在验证完算法后把结果迁移到更灵活的环境。我自己的习惯是主体仿真链路用MATLAB数据分析和绘图用Python两者之间通过文件交换结果。这样既利用了MATLAB在通信仿真上的成熟度又避开了它在自动化上的短板。至于C定点仿真那是硬件验证阶段的事前期的算法可行性研究不需要碰它。3. 搭建最小闭环从发送端到接收端的可复现流程3.1 参数配置一个结构体管住所有仿真条件链路级仿真第一步是定义参数。参数组织得不好后面调条件时到处改代码改一次错一次。我习惯把所有仿真条件集中在一个结构体里一个文件管住全部输入这样换场景时只需要改结构体不需要碰链路代码。% 仿真参数配置 - 5G链路级仿真最小配置 simParams struct(); simParams.numTB 1000; % 每个SNR点仿真的传输块个数 simParams.snrVec 0:2:20; % 要扫描的SNR范围dB simParams.mcs 10; % MCS索引决定调制阶数和目标码率 simParams.tdlProfile TDL-C; % 信道模型TDL-C典型城区 simParams.delaySpread 100e-9; % 延迟扩展100ns simParams.maxDoppler 30; % 最大多普勒频移30Hz步行速度 simParams.numLayers 1; % 传输层数 simParams.scs 30e3; % 子载波间隔30kHz simParams.numPRB 52; % 分配的物理资源块数 simParams.modulation 16QAM; % 调制方式需与MCS表一致 simParams.targetCodeRate 0.478; % 目标码率由MCS表查得这段配置里有几个参数需要特别说明。snrVec不建议直接用均匀间隔的整数因为链路级曲线在低误码率段变化很陡我一般会在高SNR段加细密的点比如0:1:8再粗扫到20。numTB决定统计方差误块率要估到10^-2至少需要几百个传输块如果想看10^-3以下的曲线每个点要跑到几千块这个参数是仿真耗时的主要来源。delaySpread和maxDoppler直接决定信道的时间色散和频率色散具体取值后面第4章展开说。3.2 发送端流程编码、速率匹配、调制、资源映射的顺序发送端的顺序不能乱因为每一步的输出长度是下一步的输入约束。以MATLAB 5G工具箱为底层时发送端主流程通常长这样function txWaveform nrTx(tbBits, simParams) % 1. 传输块加CRC使用24A多项式得到带校验的比特序列 [tbCrc, crcLen] nrCRCEncode(tbBits, 24A); % 2. LDPC编码根据传输块长度选择BG1还是BG2 ldpcConfig struct(TargetCodeRate, simParams.targetCodeRate); [cwBits, ldpcInfo] nrLDPCEncode(tbCrc, ldpcConfig); % 3. 速率匹配把编码后的比特数对齐到实际可用资源 availableBits simParams.numPRB * 12 * ... simParams.numLayers * simParams.symbolsPerSlot; [rmBits, rmInfo] nrRateMatchLDPC(cwBits, availableBits); % 4. 加扰用小区ID和RNTI生成扰码序列 scrambled nrPDSCH(rmBits, simParams.nCellID, ... simParams.rnti, simParams.numLayers); % 5. 调制按MCS对应的调制阶数映射为复符号 [modSym, modInfo] nrPDSCHModulate(scrambled, ... simParams.mcs, simParams.numLayers); % 6. OFDM调制资源映射和IFFT合成时域波形 [txWaveform, txInfo] nrOFDMModulate(modSym, ... simParams.scs, simParams.initialNSlot); end这段代码里有几个关键点。LDPC编码那一行TargetCodeRate在MATLAB的LDPC接口里是个约定项实际码率由基图矩阵决定写它主要是为了让编码器确定打孔模式。速率匹配的输出长度availableBits必须算准这里乘了symbolsPerSlot这个值是指定传输块占用符号数不是一整个时隙都用。nrPDSCH是加扰接口输出长度和速率匹配输出一致如果长度对不上说明前面的资源计算有误这一步是最容易暴露出错位置的地方。实际调试时我会每一步都打印size()从编码输出一直对到OFDM输出全部对上了再继续。3.3 接收端流程信道估计、均衡、译码的最小实现接收端是发送端的镜像但多了一个不确定环节信道估计。接收端看到的符号是信道响应和发送符号的乘积再加噪声必须先把信道估计出来才能做均衡。最小实现通常用LS估计加线性插值复杂一点用MMSE。下面这个流程能覆盖大部分场景function [bler, ber] nrRx(txWaveform, rxWaveform, simParams) % 1. OFDM解调时域波形转回频域符号 [rxSym, rxInfo] nrOFDMDemodulate(rxWaveform, ... simParams.scs, simParams.initialNSlot); % 2. 信道估计基于DMRS导频做LS估计 [hest, noiseEst] nrChannelEstimate(rxSym, ... simParams.dmrsRef, CDMGroupIDs, 0); % 3. MMSE均衡抑制噪声放大输出均衡符号和CSI [eqSym, csi] nrEqualizeMMSE(rxSym, hest, noiseEst); % 4. 解调软比特输出供译码器使用 [rxSoftBits, rxBits] nrPDSCHDemodulate(eqSym, csi, ... simParams.mcs, simParams.numLayers); % 5. LDPC译码输入软比特输出判定位 [decBits, decInfo] nrLDPCDecode(rxSoftBits, ... simParams.targetCodeRate, simParams.modulation); % 6. CRC校验判断这个传输块是否出错 [blkErr, ~] nrCRCDecode(decBits, 24A); bler blkErr; % 传输块级错误指示 ber sum(decBits ~ txWaveform_tbBits) / length(txWaveform_tbBits); end注意最后一行实际编写时txWaveform_tbBits应该替换为发送端原始的tbBits通过函数参数传进来我这里只是示意。信道估计这步是误差的主要来源hest估得不准均衡后等效信噪比就会损失整条曲线都会偏右。调试时可以先把hest设为理想信道即直接用真实信道响应做均衡这样能把信道估计的影响从链路里隔离出来快速定位问题在估计模块还是译码模块。3.4 主循环与SNR扫描结果怎么统计回来主循环做的事情很机械遍历SNR在每个SNR点跑若干个传输块统计错误块数和错误比特数。但统计方式直接影响曲线质量。误块率的统计口径是传输块错误数除以传输块总数误码率的统计口径是错误比特数除以总比特数两者样本量不同波动特性也不同。% 主仿真脚本固定随机种子保证可复现 rng(42, twister); results struct(); for snrIdx 1:length(simParams.snrVec) snr simParams.snrVec(snrIdx); blockErr 0; bitErr 0; totalBits 0; for tbIdx 1:simParams.numTB % 产生随机传输块 tbBits randi([0 1], simParams.tbs, 1); % 发送端处理 txWaveform nrTx(tbBits, simParams); % 过信道TDL衰落 加噪声 rxWaveform addChannelNoise(txWaveform, snr, simParams); % 接收端处理返回当前块的对错 [isBlockErr, berTmp] nrRx(tbBits, txWaveform, rxWaveform, simParams); blockErr blockErr isBlockErr; bitErr bitErr berTmp * length(tbBits); totalBits totalBits length(tbBits); end results(snrIdx).snr snr; results(snrIdx).bler blockErr / simParams.numTB; results(snrIdx).ber bitErr / totalBits; end这里有两个习惯值得坚持。第一rng(42)必须放在整个扫描之前每个SNR点内部不要再重置种子这样整轮仿真可复现哪个点出问题可以单独重跑。第二numTB不要一开始就设很大先用200个块跑通全流程确认曲线形状合理再放大到上千个块做正式统计。我之前吃过亏一上来就跑10000块跑了两个小时发现发端和收端的速率匹配口径不一致白白浪费了时间。4. 链路级仿真里的关键参数MCS、信道模型和导频密度怎么设4.1 numerology参数SCS、FFT大小和CP长度怎么配对5G的灵活参数设计numerology是链路级仿真里最容易被忽视的一环。子载波间隔SCS决定符号长度和带宽它必须和FFT大小、采样率、CP长度一起配置不能单点设。协议里定义了几组标准组合15kHz对应常规CP30kHz是城区覆盖最常见的配置60kHz以上一般用于高频段和低时延场景。子载波间隔符号长度适用场景常见配置15 kHz66.7 us大覆盖、低频10MHz带宽FFT 102430 kHz33.3 us城区典型配置20MHz带宽FFT 102460 kHz16.7 us工业场景、低时延100MHz带宽FFT 2048120 kHz8.3 us高频毫米波400MHz带宽FFT 4096链路级仿真的带宽通常不用整个载波而是只分配一部分PRB这时仍然要把整套numerology按标准配置好因为CP长度和子载波间隔共同决定了信道延迟扩展的容忍上限。一个原则CP长度必须大于信道的最大延迟扩展否则符号间干扰会直接抬高原地效应。TDL-C信道在100ns延迟扩展下用常规CP完全没有问题但如果配置测试用的大延迟扩展信道就要确认CP是否够长。4.2 MCS与有效码率最容易算错的一个数链路级仿真通常固定MCS因为要比较的是算法在特定编码调制组合下的性能。但MCS不能只看调制阶数更重要的是它隐含的目标码率。调制方式和码率组合起来才是有效码率而有效码率决定了速率匹配后实际传输的比特数。我做平台时MCS相关的参数从来不是手填的而是查表得到。先定MCS索引再从协议定义的MCS表查出调制阶数、目标码率然后用码率和可用资源反推传输块大小。这里有个常见的坑直接把目标码率当成LDPC编码时的码率。实际上LDPC基图有BG1和BG2两套BG1支持1/3到8/9的码率BG2针对小传输块设计传输块长度低于292比特时协议强制用BG2这时有效码率的计算方式不同。仿真里如果选错BG编码输出长度对不上速率匹配的输入系统会报错或者BLER整体偏移好几个dB。4.3 信道模型参数延迟扩展和多普勒怎么影响曲线TDL信道模型是链路级仿真的默认选择它把真实信道抽象成一组抽头每个抽头有独立时延和功率。不同的Profile对应不同场景TDL-A是视距场景TDL-B也是视距但延迟扩展更大TDL-C是非视距典型城区TDL-D和TDL-E对应更强的视距成分。我建平台时最先落地的就是TDL-C因为它覆盖的城区非视距是最常见的性能评估场景。信道参数里delaySpread和maxDoppler是最影响结果的两个值。延迟扩展决定频率选择性衰落的深度延迟扩展越大频域信道起伏越剧烈均衡器需要更强的导频密度才能跟上。多普勒频移决定时间选择性30Hz对应步速300Hz对应高铁场景。仿真时如果只验证算法基线用30Hz足够要验证接收机在高速场景的鲁棒性就需要跑300Hz甚至更高同时把导频在时域上的密度加大。另外TDL模型输出时要按抽头功率做归一化保证信号功率不随信道配置变化否则SNR的定义就失效了。提示配置信道模型时需要同时检查导频模式是否与信道相干时间和相干带宽匹配。经验法则是导频时域间隔小于信道相干时间的一半频域间隔小于相干带宽的一半。用TDL-C配合100ns延迟扩展时频域间隔通常满足要求而超过300Hz多普勒时就要检查时域导频密度。5. 链路级仿真避坑指南5个让结果翻车的常见问题5.1 现象曲线在高SNR段抬不下去出现地板效应误码率曲线在高信噪比段本该陡峭下降却变得平坦像踩到了一块地板。这是链路级仿真里最常见的问题。原因几乎都是噪声功率的定义和信号功率不匹配噪声加多或者加少。信道的抽头输出做了功率归一化而噪声是按信号能量乘以某个系数算的归一化方式一变实际信噪比就不是配置的那个值。解决方法是统一能量口径。我在代码里固定用每资源单元能量EPRE来定义SNR即EsN0加噪声前先算出信号的平均符号能量再按EsN0要求的噪声功率密度加噪声。加完之后还可以在接收端做一次后验信噪比统计如果10dB配置下实测只有7dB说明中间某个环节把信号功率稀释了。先修归一化再谈算法优化。5.2 现象BLER曲线和标准参考曲线对不上整体偏移几个dB曲线形状正常但整体向右偏了2到3个dB。这个现象比地板效应隐蔽因为链路本身没有错只是某个开销没算进去。最常见的原因是导频的开销没有计入有效码率。速率匹配时的可用比特数如果只算了数据资源单元没扣掉DMRS占用的部分实际传输的数据比特就比理论少码率偏低仿真出来的性能会偏乐观。反过来如果导频开销扣重复了性能又偏悲观。排查顺序是先单独验证无信道场景下的编码调制链路用理论BER曲线对齐再逐步引入信道估计观察性能损失是否在预期范围内最后核对速率匹配长度和导频占比。我之前在一个模拟项目X里BLER曲线整整偏了1.8dB最后查出来是symbolsPerSlot里把DMRS符号也算进数据符号了。5.3 现象仿真慢到无法接受一个SNR点跑几小时链路级仿真慢95%的情况是LDPC译码和传输块数量这两个因素。LDPC译码的浮点置信传播迭代在MATLAB里很费时间迭代次数设成50甚至100一个传输块就要跑很久而numTB设得太大每个块都做完整译码时间直接线性累加。解决思路是分阶段先用小numTB200左右跑通流程确认功能正确再把译码迭代上限调低到8到10次性能损失在误块率0.1附近一般可以接受最后考虑用MEX或GPU加速译码器。对于趋势验证减少传输块数比优化译码器更立竿见影。5.4 现象配置的SNR和接收端实测信噪比不符差一个固定倍数配置10dB接收端统计出来却是13dB或7dB这种固定差值。这个差值通常来自调制阶数和每比特能量之间的换算。链路级仿真里如果用EbN0配置噪声但接收端的统计是按符号能量算的两者差一个log10(每符号比特数)的倍数。QPSK差3dB16QAM差6dB64QAM差约7.8dB不换算必然对不上。我的做法是全程统一用EsN0做配置和统计调制阶数的影响只体现在MCS参数里不在SNR口径里。如果协议或参考曲线要求EbN0只在外层做一次换算内部链路不动。这样每个模块的调试基准是一致的不会出现多个换算层叠导致的不确定性。5.5 现象同一套参数跑两次结果不一样说不清差异来源明明什么都没改重跑一次曲线变了这在高SNR段特别明显因为统计方差本身就大。但方差只能解释小波动如果低SNR段也反复横跳就要怀疑随机数流没控制好。MATLAB里默认的随机数流是全局的任何一次rand调用都会推进状态如果把扰码、噪声、随机比特生成顺序改了整个结果就变了。解决方法是固定随机种子并把随机数流的使用顺序固定下来。代码里所有随机数的产生位置在调试阶段保持顺序不变。并行计算时要给每个worker单独的随机流。我习惯在仿真脚本开头写rng(42, twister)并且每个SNR点之间不重置——重置会让每个点的随机序列完全相同掩盖统计独立性。如果两个版本代码的随机流顺序差别过大结果对比就会混入随机因素这一点在算法回归测试时最容易被低估。6. 验证平台正确性用理论曲线和参考结果标定平台搭好之后第一件事不是跑复杂场景而是验证它本身是对的。我的标定流程分三步每一步都能独立定位问题。第一步是AWGN下的理论BER对比把信道换成纯AWGN跑BPSK或QPSK把仿真的误码率和理论公式画在一起。这个对照能覆盖发送端、接收端、SNR定义这整条链路如果这条对不上后面所有信道相关的结果都不值得信任。% 冒烟验证AWGN下QPSK的理论BER与仿真结果对照 EsN0dB 0:2:10; EsN0 10.^(EsN0dB/10); berTheory 0.5 * erfc(sqrt(EsN0/2)); % QPSK格雷映射的理论误码率 semilogy(EsN0dB, berTheory, -); hold on; semilogy(EsN0dB, simBER, o); % simBER为平台仿真结果 grid on; xlabel(Es/N0 (dB)); ylabel(BER);第二步是平坦衰落对照配置TDL信道时把延迟扩展设到接近零等效成只含单抽头的平坦衰落信道理论上性能应介于AWGN和深衰落之间且在块衰落下能近似用瑞利信道的理论曲线框住。如果这一步出现明显偏离问题在信道模型或信道估计而不在编解码链路。第三步才是和标准参考曲线对齐——用固定的MCS和TDL-C配置把BLER0.1处的SNR和协议性能参考点做差值偏差在0.5dB以内说明链路可信超过1dB就要回头查。我调平台这些年最大的教训就是永远先确认链路本身是对的再谈算法优劣。因为链路上的任何一个隐性开销错误都会伪装成算法性能差异让你在错误的方向上浪费几天甚至几周。所以现在每收到一套新改动的代码我先跑AWGN冒烟测试再跑平坦衰落最后才跑目标场景。这个习惯帮我排查掉了至少一半的无效调试。希望帮到你。本文还有配套的精品资源点击获取