简介这是一份面向移动通信学习者的MATLAB仿真资源围绕长期演进LTE下行链路单输入单输出SISO场景完整覆盖物理层传输、信道建模、资源分配、多用户调度与干扰处理等系统级仿真核心环节。目前已有330人浏览学习压缩包共40个m文件、约35KB按功能拆分为参数设置、信道估计、调制解调、正交频分复用收发、加解扰、循环冗余校验、速率匹配与误码率统计等模块均可独立运行或联合调用适合熟悉LTE基础原理并希望上手系统仿真的读者也可作为课程设计与毕业设计的参考资料。通过研读主控脚本与各功能函数可以理解从发端编码、物理信道映射到收端估计解码的完整链路流程对比链路级与系统级仿真的差异并利用数据速率统计与可视化脚本分析调度和信道条件对网络性能的影响。1. 先说清楚这个 SISO.zip 里的 LTE 仿真包到底能帮你仿真什么每一位刚拿到这类 LTE 仿真包的工程师第一反应都是先找 README翻半天目录然后陷入“链路级和系统级到底先跑哪个”的纠结。这个 SISO.zip 的标题已经把答案写在脸上了SISO单发单收配置 下行链路它同时覆盖链路仿真和系统级仿真两条线。SISO 是 LTE 物理层里天线配置最简单的一种没有层映射的复杂度、没有预编码矩阵选择却是把整条收发链路从比特到误块率走通的最佳起点下行链路则因为资源分配、调度和 CQI 反馈都集中在基站侧仿真时你只需要关心一个发射端和一个接收端的行为排查问题不会陷入多方互动的泥潭。这篇文章不打算复述 LTE 协议而是直接告诉你这个包怎么拆、怎么改参数、跑出来的数字怎么看以及那些让你怀疑人生的坑分别在哪儿。2. 链路仿真在下行链路 SISO 场景下做了什么一条完整的 PHY 处理链2.1 发射端 TTI 处理CRC 附着、Turbo 编码与速率匹配的顺序不能乱LTE 下行链路每个子帧1ms的传输块要从 MAC 层到达物理层首先做 CRC 附着。这里最常见的理解偏差是CRC 不只是加 24 比特校验位它的多项式选择和传输块大小决定了接收端能用什么方式做错误检测。仿真包里这一步通常封装成一个函数输入是传输块二进制向量输出是附着了 CRC 的比特序列。你不需要自己实现多项式除法但必须知道这个函数的输出长度等于传输块长度加 24这个长度直接决定了后续编码块分割有没有发生。Turbo 编码是下行共享信道DL-SCH的主力编码方案码率 1/3内部包含两个递归系统卷积码分量交织器是 QPP 交织。在 SISO 仿真的发射端实现里编码后的比特流长度约等于输入长度的三倍但这里有个关键点速率匹配会用循环缓冲的方式从编码比特里挖出实际传输的比特数。你可别以为码率就是固定 1/3实际码率由调制阶数和资源块数量共同决定比如 MCS 选了 16QAM、分配了 20 个 RB那传输块对应的码率可能是 0.5 甚至更高。速率匹配的顺序在实现层面是子块交织 → 比特收集 → 比特选择。仿真代码里这一步往往是一个看似不起眼的矩阵索引操作但它是整个发射端最容易出数值越界的地方原因很简单传输块大小TBS和资源块数量NPRB的组合如果超过了协议表的边界索引就会取到空值。我拿到新仿真包的第一件事就是把 TBS 表和 MCS 表的映射关系打出来核对一遍这一步十分钟能做完却能在后面省下几天的排错时间。发射端的最后两步是加扰和调制。加扰序列用长度 31 的 Gold 序列生成初始化种子跟小区 ID、RNTI 和时隙号绑定。仿真里如果跳过加扰直接发调制符号大多数情况下 SNR 曲线不会差太多但你一旦进入多小区系统级仿真加扰缺失会让小区间干扰模型完全失真所以别图省事省略这一步。调制的映射关系是标准的 QPSK/16QAM/64QAM 星座图注意 64QAM 在 LTE 里要求更高的 SNR 才能达到同样的 BLER这在选择 MCS 时是个硬约束。# 发射端 TTI 处理的最小流程等价于包内 trunk 函数的逻辑 def tx_processing(transport_block, crc_poly, mcs, n_prb, cell_id): # 步骤1: CRC附着返回 tb 24bit 校验 tb_crc attach_crc(transport_block, crc_poly) # crc_poly 通常为 0x1864CF # 步骤2: Turbo 编码码率1/3输出三个校验流的交织结果 encoded turbo_encode(tb_crc) # 长度约为 3*(len(tb_crc)4) # 步骤3: 速率匹配按 mcs 对应的调制阶数和 n_prb 计算可用比特数 mod_order get_mod_order(mcs) # 2(QPSK)/4(16QAM)/6(64QAM) available_bits n_prb * 12 * 7 * 2 * mod_order # 14个OFDM符号携带数据 rm_bits rate_match(encoded, available_bits) # 循环缓冲取出 # 步骤4: 加扰Gold序列初始化依赖 cell_id 与子帧号 scrambled scrambling(rm_bits, cell_id, subframe_no) # 步骤5: 调制映射到复数星座点 symbols modulate(scrambled, mod_order) return symbols这段代码里的available_bits计算值得你停下来核对。n_prb * 12是一个 RB 在频域上的子载波数7是常规循环前缀下一个时隙的 OFDM 符号数2是一个子帧有两个时隙mod_order是每个符号的比特数。这样算出来的比特数是理论上的数据容量上限实际实现还要减去 DMRS解调参考信号占用的资源单元所以当你发现仿真吞吐量比理论峰值低 10% 到 15% 时先查这部分有没有修正比怀疑信道模型更靠谱。2.2 OFDMA 资源映射SISO 下没有层映射但资源网格的索引依旧容易出错SISO 配置的层数固定为 1所以发射端不需要做层映射和预编码直接就是把调制符号依次填入资源网格。资源网格的维度是 12 个子载波乘以一个子帧的 14 个 OFDM 符号每个 RB 对应一组这样的网格。填入顺序是先频域后时域还是先时域后频域不同仿真包的习惯不一样你必须去查配置里symbol_order这个字段设成frequency_first时同一个 OFDM 符号内的子载波按顺序填设成time_first时先填完一个子载波在 14 个符号上的所有位置。这个顺序直接影响接收端解映射的代码是否对称。我见过不少人在发射端和接收端用了不同的映射顺序结果整条链路的 BER 永远是 0.5最后排查半天发现是索引不匹配。SISO.zip 这类包里通常会在配置文件的physical_layer段暴露这个参数你在改写发射端代码时要同时检查接收端的deMapping实现是否与之配套。DMRS 在资源网格中的位置也值得单独讲一句。下行链路 SISO 的 DMRS 通常占用每个 RB 的第 1 和第 5 个 OFDM 符号索引从 0 计数时是 0 和 4在子载波维度上间隔摆放。接收端做信道估计时插值算法会根据 DMRS 的位置重建整个资源网格的信道响应所以你在修改 DMRS 密度时要意识到删掉一半 DMRS 会带来约 1.5dB 的信道估计误差这个数字在链路预算里是肉眼看得到的。2.3 接收端最小闭环LS 信道估计加上 MMSE 均衡先别上卡尔曼滤波下行链路接收端最朴素但可靠的组合是先做同步和循环前缀移除然后 FFT 到频域提取 DMRS 位置的接收符号用 LS最小二乘估计出 DMRS 处的信道响应再通过插值得到所有数据位置的信道响应最后用 MMSE 均衡恢复出发射符号。你不需要一开始就实现复杂的时域信道估计或者迭代接收机那些是给多天线和高速移动场景准备的。LS 估计的公式就是接收符号除以已知的 DMRS 符号实现起来只有一行复数除法。但这里有个落地的细节DMRS 序列本身是伪随机序列仿真代码里生成 DMRS 的模块必须和发射端加扰模块用的是同一个cell_id否则估计出来的信道完全错误。系统级仿真里如果存在多个小区每个小区用不同的cell_idUE 侧需要根据自己所在小区的cell_id来生成对应的 DMRS 副本。你看这个坑在链路级仿真里不存在一上系统级就冒出来了。MMSE 均衡的核心是这个公式W H^H * (H * H^H N0 * I)^(-1)其中H是信道矩阵在某个子载波上的值N0是噪声功率谱密度。SISO 下H是一个复数标量所以均衡退化成维纳滤波器系数H* / (|H|^2 N0)。仿真包里往往有一个equalizer_type的开关选ZF还是MMSE在高 SNR 时几乎没区别但是在低 SNR 区MMSE 比 ZF 能多出 2 到 3dB 的增益。如果仿真目标是把 BLER 曲线拖到 1% 以下你必须用 MMSE。# 接收端每个子载波上的 MMSE 均衡参数来自信道估计模块 def mmse_equalize(rx_symbol, h_est, n0, mod_order): # rx_symbol: 接收到的频域复数符号 # h_est: 当前子载波的信道响应估计值SISO下为标量 # n0: 噪声功率从 SNR 配置换算得到 mmse_weight np.conj(h_est) / (np.abs(h_est)**2 n0) equalized rx_symbol * mmse_weight # 软解调输出 LLR 而非硬判决Turbo 解码器依赖软信息 llr soft_demod(equalized, mod_order, n0*mmse_weight) return llr这段代码里最容易被新手忽略的是soft_demod里噪声项为什么要乘mmse_weight。MMSE 均衡后残留噪声不再是白噪声它的功率和均衡系数成正比如果不做这个修正LLR 会被过度放大或缩小Turbo 译码的性能直接崩掉。这个就是所谓的“匹配滤波”细节仿真包基本都实现了但你一旦自己改均衡器类型就要把这个修正也带走否则你会得到一个比预期差 5dB 的曲线然后怀疑整个仿真包都是错的。3. 从链路级走向系统级SISO 下行链路的抽象逻辑与信道建模差别3.1 链路级仿真的最小闭环一个发射机、一个接收机、一条信道链路级仿真的本质是把物理层的收发信机当成一个黑盒输入是调制编码方案、资源块分配和信道实现输出是 BLER、吞吐量或者 PER。SISO.zip 里的链路级仿真代码通常围绕一个子帧或者一个 TTI 循环运转每次迭代生成一个传输块经过你刚看到的发射端处理送进信道模型再由接收端恢复最后比对传输块是否通过了 CRC 校验。链路级仿真不需要考虑小区间干扰、调度延迟或者用户分布因为这些是它的上层抽象关心的事。信道模型在链路级里通常是 TDL抽头延迟线模型比如 EPA、EVA、ETU 三种典型场景分别对应低、中、高延迟扩展。这些模型的抽头数量和时延是 3GPP 标准里固定好的仿真代码里一般直接查表实现。你需要关心的是每个抽头的多普勒频移因为用户移动速度决定了多普勒频移进而决定信道随时间变化的快慢。EVA 模型在 30km/h 下的信道相干时间大约只有几毫秒这意味着一个子帧里的 14 个 OFDM 符号经历的信道可能已经有明显变化接收端必须依赖 DMRS 插值去跟踪。链路级仿真输出的最常见中间量是 BLER-SNR 曲线。做这条曲线时你要注意仿真点数怎么取SNR 间隔 1dB 太粗0.2dB 太密合理的做法是先在 0 到 20dB 范围内做粗扫找到 BLER 从 0.9 跌到 0.01 的区间再在这个区间内以 0.5dB 间隔加密。每个 SNR 点至少要跑 1000 个传输块BLER 要降到 0.01 时统计置信度才够只跑几十个传输块得出的 0 和 1 没有任何意义。3.2 系统级仿真为什么不能直接跑全物理层抽象的必要性如果你把系统级仿真也做成每个 TTI 都跑一次完整的 Turbo 编解码那么一个 57 小区的网络每毫秒要处理几十个用户的物理层收发计算量是任何普通工作站都扛不住的。系统级仿真的核心思想是把链路级仿真已经得到的 BLER 曲线或者吞吐量查找表抽象成一个接口系统级只负责调度、干扰计算和信道大尺度衰落不碰具体比特。这就是 SISO.zip 这类包同时包含链路级和系统级的原因先用链路级仿真生成“CQI 到 BLER”的映射表然后在系统级仿真里UE 上报 CQI调度器根据 CQI 选择 MCS再从链路级表里查到这个 MCS 在当前 SNR 下的 BLER决定这个传输块是否传输成功。这个抽象省掉了物理层的比特级计算代价是牺牲了时间分集和信道估计误差带来的细节但这两个因素在系统级的研究问题里本来就是次要变量。系统级仿真的空间尺度也完全不同。链路级关心的是几微秒到几毫秒的时间粒度系统级用的是 15 分钟甚至更长的“drop”快照机制来模拟用户的移动和信道大尺度变化。每个 drop 里用户位置固定阴影衰落固定只有快衰落按多普勒频谱在子帧粒度上更新。SISO.zip 里的系统级代码通常会有一个外层循环是 drop内层循环是子帧你在配置里看到的nDrops 100和nSubframes 200指的就是这两层循环次数。3.3 下行链路 SISO 系统级仿真的链路抽象接口CQI、MCS 和 BLER 查找表下行链路的系统级仿真流程可以概括成四步第一基站给每个用户分配资源块第二用户在对应资源块上测量 SINR第三用户将 SINR 映射成 CQI信道质量指示上报第四基站参考 CQI 选择 MCS 并在下一个 TTI 调度传输。SISO 场景下 CQI 上报不需要考虑预编码和秩所以 4 比特 CQI 表的映射规则相对直白CQI 值与 SINR 的对应关系可以用 BLER 仿真校准得到通常是选择 BLER 不超过 0.1 的最高 CQI。这里有个系统级仿真特有的细节叫 CQI 上报延迟。UE 在第 n 个子帧测得 SINR上报给基站基站第 n8 个子帧才能使用这个信息做调度。在低速场景下这个延迟可以忽略因为信道变化相对缓慢但用户移动速度达到 120km/h 时8 毫秒里信道已经明显变化基站使用的 MCS 可能已经过时。如果你的系统级仿真结果在高速场景下吞吐量骤降先不要怀疑调度算法去核查 CQI 延迟参数有没有设置对这比任何调度优化都更影响结果。# 系统级仿真配置片的典型写法YAML/类XML风格重点看接口层的参数 system_level: drops: 100 # 快照数每个drop内用户位置固定 subframes_per_drop: 200 # 每个drop内的子帧数200ms仿真时间 cqi_report_period: 10 # 每10个子帧上报一次CQI即10ms周期 cqi_delay: 8 # 上报到调度生效的延迟单位子帧 scheduler: proportional_fair link_abstraction: table_file: bler_table_siso_dl.csv # 链路级仿真生成的查找表 snr_min: -5.0 snr_max: 25.0 snr_step: 0.5配置里的bler_table_siso_dl.csv就是链路级和系统级之间的桥梁。这个文件的每一行通常是某个 SNR 和某个 MCS 组合对应的 BLER 值系统级仿真在调度时直接查表用随机数和 BLER 值比大小来决定传输成败。如果你直接用下载包里自带的表而没有用你自己的信道模型重新生成那么链路级和系统级的信道假设必须一致——比如链路级用的是 ETU 信道而系统级用的路损模型假设了郊区场景这个组合就是不匹配的结果会体现出莫名其妙的吞吐量偏高或偏低。4. 把 SISO 下行链路仿真跑起来配置文件结构与必调参数4.1 配置文件的分层结构与修改顺序几乎所有正经的仿真包都会把链路级和系统级的配置分开因为两套仿真对参数的需求差异太大。链路级配置文件的核心参数是信道模型、MCS、RB 数和 SNR 扫描范围系统级配置则更关注小区布局、用户数、调度器类型和 CQI 参数。SISO.zip 的常见做法是提供两个入口脚本链路级一个系统级一个你直接修改对应的配置文件就行。我第一次跑这类仿真时犯过一个低级错误直接修改了系统级配置里的snr_range以为这能把仿真出来的吞吐量曲线拉直结果链路级模块调用的还是它自己配置里的 SNR 范围。链路级和系统级共用了同一个全局配置文件但各自的模块只认自己的配置段。所以你在动手前先打开配置文件确认[link_level]和[system_level]这两个段的边界改参数时不要跨段操作。修改顺序有讲究。先改链路级的信道模型和 MCS跑通一版 BLER 曲线再改系统级的小区半径和用户数跑通吞吐量曲线。如果一上来就同时改 10 个参数结果异常时你根本没法定位是哪个参数造成的。我通常会把链路级仿真当作系统级仿真的前置步骤链路级表生成之后冻结链路级配置只调整系统级参数这样问题边界最清晰。4.2 必调参数MCS、信道延迟剖面、UE 速度与衰落粒度链路级仿真最值得你手动调的四个参数如下。第一个是 MCS它决定了调制阶数和 TBS 的索引直接决定一条 BLER 曲线的位置MCS 越大曲线越靠右你需要看的是曲线形状而不是位置。第二个是信道延迟剖面EPA 剖面下信道平坦ETU 剖面下频率选择性很强同一条 MCS 在 ETU 下的 BLER 曲线会比 EPA 下陡一些但平台区也高一些这反映的是频率分集在实际信道里的收益。第三个是 UE 速度它决定多普勒频移低速下信道时间相关性高BLER 曲线会表现为明显的分集阶数高速下曲线会变得平滑但整体性能下降。第四个是 SNR 扫描点数和范围这影响仿真的运行时间和曲线分辨率。系统级仿真里还有两个参数容易被人忽略。一个是scheduler_granularity按 RB 粒度调度比按子带粒度调度计算量大几倍结果差异却不大对于 SISO 下行链路按子带调度加 PF比例公平算法就能给出接近真实的平均吞吐量。另一个是harq_max_retx这个参数控制 HARQ 最大重传次数设置为 4 是标准做法设置为 0 会让 BLER 直接影响到 RLC 层导致重传和时延异常其实这不是物理层仿真的目标。市面上的仿真包在衰落信道的更新方式上有两类实现一类是每个子帧都重新生成信道系数另一类是每 N 个子帧更新一次并在其间插值。后者的N值直接决定仿真速度和信道时间相关性的准确度。对于 30km/h 的 UE载波频率 2GHz 时最大多普勒频移约 55Hz信道相干时间大约 18ms所以每隔 5 个子帧更新一次信道足以保持精度太多只会白白增加计算量。4.3 一次完整的运行流程从链路级到系统级的命令和产物先跑链路级仿真命令通常是进入link_level目录后运行主脚本配置好 SNR 扫描范围和传输块数量输出会是一个 CSV 或 MAT 格式的文件内容是每条 MCS 在对应 SNR 下的 BLER。拿到这个表后你需要做一步质量校验把 BLER 曲线画出来看看有没有非单调的区域或者下降斜率忽大忽小的点如果有大概率是仿真次数不足导致的统计抖动而不是算法出问题加密传输块数即可。然后跑系统级仿真。系统级不会直接输出实物吞吐量而是输出每个 UE 在每个子帧的调度记录包括分配的 RB、MCS 和是否 ACK。最方便的聚合指标是用户平均吞吐量总 ACK 的传输块大小之和除以仿真时长。SISO.zip 里的工具脚本一般能直接从日志里提取这个数但你要注意日志里的成功传输是按传输块计数的如果启用了 HARQ一个传输块可能对应多次尝试吞吐量计算只算第一次成功传输的 TBS不算重传。# 链路级仿真命令行示例Windows 下用批处理或 PowerShell 同理 cd link_level python run_link_simulation.py --config siso_dl_etu_30kmh.yaml --snr_range -5 25 1.0 # 输出: bler_table_etu_30kmh.csv行SNR列MCS # 系统级仿真指定用上面生成的链路级表 cd ../system_level python run_system_simulation.py --config siso_dl_pf_scheduler.yaml \ --link_table ../link_level/bler_table_etu_30kmh.csv # 输出: scheduler_log.csv每行是一个TTI的调度决策和ACK/NACK跑完系统级仿真的第一件事不是看吞吐量平均值而是看调度器的资源分配公平性用日志算每个 UE 分到的 RB 数方差如果方差过大可能不是调度器的问题而是你的用户分布不均匀——有的 UE 始终在小区边缘CQI 低到几乎拿不到调度机会。这种时候把用户分布参数里的最小路径损耗约束调大一点让所有 UE 至少有一个可用的 SINR 下限比折腾调度器更有用。5. 仿真常见问题与避坑SISO 下行链路仿真的五个经典翻车点5.1 现象高 SNR 下吞吐量为零但星座图是清晰的这是最恼人的问题之一BLER 曲线在 SNR 超过 20dB 时仍然显示所有传输块都失败去看接收星座图却干净得可以直接做教材。问题根源几乎总是同步偏移接收端不知道 OFDM 符号的起始位置在移除循环前缀时多切了一个采样点。原因通常是仿真代码里噪声功率归一化时没有考虑过采样率导致 N0 偏大MMSE 均衡权重被过分压低。解决方法是先做整数倍采样偏移搜索对接收序列做自相关找到符号边界然后对比发射端的符号起始点。另一个更隐蔽的原因是发射端和接收端的 DMRS 生成函数用了不同的cell_id接收端把干扰当作有用信号来估计信道星座图看着清晰数据却全部解错。将发射端和接收端的cell_id打印出来核对一遍是五分钟可以完成的排查却是我见过最高频的翻车原因。重要提示是链路级仿真里cell_id可以随便选但发射端和接收端必须一样系统级仿真里每个小区用自己的cell_idUE 必须知道自己所在小区的 ID。5.2 现象系统级仿真中 UE 吞吐量随车速提高出现悬崖式下跌用户移动速度从 3km/h 调到 30km/h 再到 120km/h平均吞吐量不是平缓下降而是在某个速度段突然掉一截。这个现象的根源是 CQI 延迟与信道相干时间的比值穿越了一个阈值CQI 上报延迟 8ms当信道相干时间小于 16ms 时基站拿到的 CQI 已经和实际信道脱节至少一个周期MCS 选择的错误率陡增。解决方法是检查两件事第一系统级仿真的cqi_delay参数是否设成了 0如果设成 0 会人为消灭这个效应第二如果延迟确实是 8ms考虑用外插预测器用最近两次 CQI 的历史差值预测当前信道的 CQI这是 3GPP 相关研究里常用的手段实现成本很低能挽回约 5% 到 10% 的吞吐量损失。还有一种原因是链路级表本身是在低多普勒条件下生成的你在系统级里用了高速场景却复用了那张低速的 BLER 表。链路级表必须按 UE 速度分档生成0 到 3km/h 一档、30km/h 一档、120km/h 一档三张表对应的 BLER 曲线差异显著尤其在 MCS 较高时。给系统级仿真配置动态的链路级表是仿真从入门迈向合格的标志。5.3 现象BLER 曲线在中高 SNR 区域出现多处跳变曲线不光滑BLER 曲线在 10dB 附近上下抖动不是单调下降甚至像锯齿。原因几乎肯定是传输块数量太少BLER 等于 0.01 需要至少 100 个错误的传输块才能得到稳定的估计值如果你的仿真停在第一个 100 个错误块就提前终止那么在高 SNR 区错误块原本就稀少统计结果必然抖动。解决方法是给仿真澄清一个终止准则要么固定跑完 N 个传输块要么采样到足够的错误块数二选一。我习惯把错误块数阈值设成 200 到 500这样 BLER 在 0.01 附近的置信区间才能收窄到可以接受的范围。如果传输块数量已经很大还是有跳变再去检查信道实现是否在每个 SNR 点都重新生成了一次。有的仿真代码实现了一个信道实例然后在 SNR 循环里复用这会让 SNR 点的性能差异被同一个信道异常实现主导曲线自然不光滑。每个 SNR 点独立刷新信道种子这是常识级别的要求但代码里经常被忽略。5.4 现象仿真吞吐量比理论频谱效率峰值高出 10% 以上如果你的 SISO 下行链路仿真吞吐量超过了香农容量对应的数值或者超过了 3GPP 仿真约定中给出的峰值频谱效率那肯定有参数设置错误。最常见的元凶是资源映射时没扣除 DMRS 和控制信道的开销前面算过理论比特数用n_prb * 12 * 7 * 2 * mod_order但这是 PDSCH 满载才有的值实际每个 RB 里 DMRS 占了大约 1/7 的资源单元PDCCH 还会占掉前 1 到 3 个 OFDM 符号。如果系统级仿真里调度器按满 RB 分配而物理层按实际可用 RE 计算 TBS中间就产生了虚高。另一个常见原因是链路级 BLER 表的 SNR 轴和系统级 SINR 轴没有对齐。链路级仿真里的 SNR 是每 RE 的符号能量除以噪声功率系统级仿真的 SINR 可能包含了小区间干扰、可能扣除了导频功率两个定义不在一个坐标系里查表时选错就查到了更高的 MCS。解决方法是统一两者的参考点规定链路级表的横轴是每 RE 的 SINR系统级在查表前也把干扰和噪声折算成每 RE 的 SINR并在代码里加一行断言确保这个值在链路级表的覆盖范围内。5.5 现象仿真运行太慢一个系统级场景要跑三天SISO 下行链路系统级仿真的计算瓶颈往往不在信道生成而在调度器内部的 RB 分配循环。如果调度器对每个 TTI 都做全用户全 RB 的暴力搜索复杂度是 O(用户数×RB 数)看起来不大但乘以 100 个 drop 乘 200 个子帧就变得可观了。首先要检查衰落信道的更新间隔前面说过 5 个子帧更新一次就够如果代码每子帧更新浪费了约 80% 的时长。其次检查 CQI 表是否被重复计算每个 TTI 重新读 CSV 并解析比在仿真启动时一次性加载内存慢一个数量级。最后一个建议是减少 drop 的重复度。如果你的 100 个 drop 里用户位置和阴影衰落基本没变那你实际上在重复仿真同一个场景drop 数量减到 20 个就能达到同样的统计精度。与其盲目增加 drop 数不如先画出吞吐量随 drop 数累计均值的变化曲线稳定了就收手这个习惯能让你的仿真时间缩短一半以上。6. 进阶技巧把链路级曲线收进仿真检查表让每一版改动都有回归依据有一个很值得养成的习惯把链路级 BLER 曲线固定下来作为回归测试的基线。每当你修改了系统级代码的任何部分比如调度器、干扰模型或者 HARQ 逻辑跑完系统级仿真后回到链路级重跑一遍同一组配置对比这次的 BLER 曲线和基线有没有偏移。如果偏移超过 0.5dB大概率是你动代码时不小心改到了物理层共用的模块或者链路级表文件的路径被覆盖了。这个回归流程成本很低却能让你的仿真结果具备可追溯性不再出现“上一版结果还行这版突然不对”的玄学问题。我处理这类 LTE 下行链路仿真项目时最后一步几乎都是同一件事把仿真输出的文件清单梳理一遍按“链路级表 系统级日志 聚合脚本”三件套归档文件名里带上信道模型、速度和日期。这套习惯拯救过我好几次两周前生成的表因为中间动过一次信道参数系统级结果怎么都对不上仿真论文的曲线回看归档才发现链路级表是用旧的 ETU 配置生成的重新生成一张表就解决了。验证仿真结果合理性的最后一个技巧是比对一个参考点下的理论值1 个 RB 对应 180kHz 带宽SISO 下行用 64QAM 时峰值频谱效率约 4.5 到 5bps/Hz实际能跑到理论值的 70% 到 80% 就算健康。如果差太多就回头查 MCS 选择、控制信道开销或者 CQI 延迟这三项十有八九是它们出了问题。希望这篇避坑与实操笔记帮到你愿你的仿真曲线早日光滑、你的吞吐量早日收敛到理论值附近。本文还有配套的精品资源点击获取
简介这是一份面向移动通信学习者的MATLAB仿真资源围绕长期演进LTE下行链路单输入单输出SISO场景完整覆盖物理层传输、信道建模、资源分配、多用户调度与干扰处理等系统级仿真核心环节。目前已有330人浏览学习压缩包共40个m文件、约35KB按功能拆分为参数设置、信道估计、调制解调、正交频分复用收发、加解扰、循环冗余校验、速率匹配与误码率统计等模块均可独立运行或联合调用适合熟悉LTE基础原理并希望上手系统仿真的读者也可作为课程设计与毕业设计的参考资料。通过研读主控脚本与各功能函数可以理解从发端编码、物理信道映射到收端估计解码的完整链路流程对比链路级与系统级仿真的差异并利用数据速率统计与可视化脚本分析调度和信道条件对网络性能的影响。1. 先说清楚这个 SISO.zip 里的 LTE 仿真包到底能帮你仿真什么每一位刚拿到这类 LTE 仿真包的工程师第一反应都是先找 README翻半天目录然后陷入“链路级和系统级到底先跑哪个”的纠结。这个 SISO.zip 的标题已经把答案写在脸上了SISO单发单收配置 下行链路它同时覆盖链路仿真和系统级仿真两条线。SISO 是 LTE 物理层里天线配置最简单的一种没有层映射的复杂度、没有预编码矩阵选择却是把整条收发链路从比特到误块率走通的最佳起点下行链路则因为资源分配、调度和 CQI 反馈都集中在基站侧仿真时你只需要关心一个发射端和一个接收端的行为排查问题不会陷入多方互动的泥潭。这篇文章不打算复述 LTE 协议而是直接告诉你这个包怎么拆、怎么改参数、跑出来的数字怎么看以及那些让你怀疑人生的坑分别在哪儿。2. 链路仿真在下行链路 SISO 场景下做了什么一条完整的 PHY 处理链2.1 发射端 TTI 处理CRC 附着、Turbo 编码与速率匹配的顺序不能乱LTE 下行链路每个子帧1ms的传输块要从 MAC 层到达物理层首先做 CRC 附着。这里最常见的理解偏差是CRC 不只是加 24 比特校验位它的多项式选择和传输块大小决定了接收端能用什么方式做错误检测。仿真包里这一步通常封装成一个函数输入是传输块二进制向量输出是附着了 CRC 的比特序列。你不需要自己实现多项式除法但必须知道这个函数的输出长度等于传输块长度加 24这个长度直接决定了后续编码块分割有没有发生。Turbo 编码是下行共享信道DL-SCH的主力编码方案码率 1/3内部包含两个递归系统卷积码分量交织器是 QPP 交织。在 SISO 仿真的发射端实现里编码后的比特流长度约等于输入长度的三倍但这里有个关键点速率匹配会用循环缓冲的方式从编码比特里挖出实际传输的比特数。你可别以为码率就是固定 1/3实际码率由调制阶数和资源块数量共同决定比如 MCS 选了 16QAM、分配了 20 个 RB那传输块对应的码率可能是 0.5 甚至更高。速率匹配的顺序在实现层面是子块交织 → 比特收集 → 比特选择。仿真代码里这一步往往是一个看似不起眼的矩阵索引操作但它是整个发射端最容易出数值越界的地方原因很简单传输块大小TBS和资源块数量NPRB的组合如果超过了协议表的边界索引就会取到空值。我拿到新仿真包的第一件事就是把 TBS 表和 MCS 表的映射关系打出来核对一遍这一步十分钟能做完却能在后面省下几天的排错时间。发射端的最后两步是加扰和调制。加扰序列用长度 31 的 Gold 序列生成初始化种子跟小区 ID、RNTI 和时隙号绑定。仿真里如果跳过加扰直接发调制符号大多数情况下 SNR 曲线不会差太多但你一旦进入多小区系统级仿真加扰缺失会让小区间干扰模型完全失真所以别图省事省略这一步。调制的映射关系是标准的 QPSK/16QAM/64QAM 星座图注意 64QAM 在 LTE 里要求更高的 SNR 才能达到同样的 BLER这在选择 MCS 时是个硬约束。# 发射端 TTI 处理的最小流程等价于包内 trunk 函数的逻辑 def tx_processing(transport_block, crc_poly, mcs, n_prb, cell_id): # 步骤1: CRC附着返回 tb 24bit 校验 tb_crc attach_crc(transport_block, crc_poly) # crc_poly 通常为 0x1864CF # 步骤2: Turbo 编码码率1/3输出三个校验流的交织结果 encoded turbo_encode(tb_crc) # 长度约为 3*(len(tb_crc)4) # 步骤3: 速率匹配按 mcs 对应的调制阶数和 n_prb 计算可用比特数 mod_order get_mod_order(mcs) # 2(QPSK)/4(16QAM)/6(64QAM) available_bits n_prb * 12 * 7 * 2 * mod_order # 14个OFDM符号携带数据 rm_bits rate_match(encoded, available_bits) # 循环缓冲取出 # 步骤4: 加扰Gold序列初始化依赖 cell_id 与子帧号 scrambled scrambling(rm_bits, cell_id, subframe_no) # 步骤5: 调制映射到复数星座点 symbols modulate(scrambled, mod_order) return symbols这段代码里的available_bits计算值得你停下来核对。n_prb * 12是一个 RB 在频域上的子载波数7是常规循环前缀下一个时隙的 OFDM 符号数2是一个子帧有两个时隙mod_order是每个符号的比特数。这样算出来的比特数是理论上的数据容量上限实际实现还要减去 DMRS解调参考信号占用的资源单元所以当你发现仿真吞吐量比理论峰值低 10% 到 15% 时先查这部分有没有修正比怀疑信道模型更靠谱。2.2 OFDMA 资源映射SISO 下没有层映射但资源网格的索引依旧容易出错SISO 配置的层数固定为 1所以发射端不需要做层映射和预编码直接就是把调制符号依次填入资源网格。资源网格的维度是 12 个子载波乘以一个子帧的 14 个 OFDM 符号每个 RB 对应一组这样的网格。填入顺序是先频域后时域还是先时域后频域不同仿真包的习惯不一样你必须去查配置里symbol_order这个字段设成frequency_first时同一个 OFDM 符号内的子载波按顺序填设成time_first时先填完一个子载波在 14 个符号上的所有位置。这个顺序直接影响接收端解映射的代码是否对称。我见过不少人在发射端和接收端用了不同的映射顺序结果整条链路的 BER 永远是 0.5最后排查半天发现是索引不匹配。SISO.zip 这类包里通常会在配置文件的physical_layer段暴露这个参数你在改写发射端代码时要同时检查接收端的deMapping实现是否与之配套。DMRS 在资源网格中的位置也值得单独讲一句。下行链路 SISO 的 DMRS 通常占用每个 RB 的第 1 和第 5 个 OFDM 符号索引从 0 计数时是 0 和 4在子载波维度上间隔摆放。接收端做信道估计时插值算法会根据 DMRS 的位置重建整个资源网格的信道响应所以你在修改 DMRS 密度时要意识到删掉一半 DMRS 会带来约 1.5dB 的信道估计误差这个数字在链路预算里是肉眼看得到的。2.3 接收端最小闭环LS 信道估计加上 MMSE 均衡先别上卡尔曼滤波下行链路接收端最朴素但可靠的组合是先做同步和循环前缀移除然后 FFT 到频域提取 DMRS 位置的接收符号用 LS最小二乘估计出 DMRS 处的信道响应再通过插值得到所有数据位置的信道响应最后用 MMSE 均衡恢复出发射符号。你不需要一开始就实现复杂的时域信道估计或者迭代接收机那些是给多天线和高速移动场景准备的。LS 估计的公式就是接收符号除以已知的 DMRS 符号实现起来只有一行复数除法。但这里有个落地的细节DMRS 序列本身是伪随机序列仿真代码里生成 DMRS 的模块必须和发射端加扰模块用的是同一个cell_id否则估计出来的信道完全错误。系统级仿真里如果存在多个小区每个小区用不同的cell_idUE 侧需要根据自己所在小区的cell_id来生成对应的 DMRS 副本。你看这个坑在链路级仿真里不存在一上系统级就冒出来了。MMSE 均衡的核心是这个公式W H^H * (H * H^H N0 * I)^(-1)其中H是信道矩阵在某个子载波上的值N0是噪声功率谱密度。SISO 下H是一个复数标量所以均衡退化成维纳滤波器系数H* / (|H|^2 N0)。仿真包里往往有一个equalizer_type的开关选ZF还是MMSE在高 SNR 时几乎没区别但是在低 SNR 区MMSE 比 ZF 能多出 2 到 3dB 的增益。如果仿真目标是把 BLER 曲线拖到 1% 以下你必须用 MMSE。# 接收端每个子载波上的 MMSE 均衡参数来自信道估计模块 def mmse_equalize(rx_symbol, h_est, n0, mod_order): # rx_symbol: 接收到的频域复数符号 # h_est: 当前子载波的信道响应估计值SISO下为标量 # n0: 噪声功率从 SNR 配置换算得到 mmse_weight np.conj(h_est) / (np.abs(h_est)**2 n0) equalized rx_symbol * mmse_weight # 软解调输出 LLR 而非硬判决Turbo 解码器依赖软信息 llr soft_demod(equalized, mod_order, n0*mmse_weight) return llr这段代码里最容易被新手忽略的是soft_demod里噪声项为什么要乘mmse_weight。MMSE 均衡后残留噪声不再是白噪声它的功率和均衡系数成正比如果不做这个修正LLR 会被过度放大或缩小Turbo 译码的性能直接崩掉。这个就是所谓的“匹配滤波”细节仿真包基本都实现了但你一旦自己改均衡器类型就要把这个修正也带走否则你会得到一个比预期差 5dB 的曲线然后怀疑整个仿真包都是错的。3. 从链路级走向系统级SISO 下行链路的抽象逻辑与信道建模差别3.1 链路级仿真的最小闭环一个发射机、一个接收机、一条信道链路级仿真的本质是把物理层的收发信机当成一个黑盒输入是调制编码方案、资源块分配和信道实现输出是 BLER、吞吐量或者 PER。SISO.zip 里的链路级仿真代码通常围绕一个子帧或者一个 TTI 循环运转每次迭代生成一个传输块经过你刚看到的发射端处理送进信道模型再由接收端恢复最后比对传输块是否通过了 CRC 校验。链路级仿真不需要考虑小区间干扰、调度延迟或者用户分布因为这些是它的上层抽象关心的事。信道模型在链路级里通常是 TDL抽头延迟线模型比如 EPA、EVA、ETU 三种典型场景分别对应低、中、高延迟扩展。这些模型的抽头数量和时延是 3GPP 标准里固定好的仿真代码里一般直接查表实现。你需要关心的是每个抽头的多普勒频移因为用户移动速度决定了多普勒频移进而决定信道随时间变化的快慢。EVA 模型在 30km/h 下的信道相干时间大约只有几毫秒这意味着一个子帧里的 14 个 OFDM 符号经历的信道可能已经有明显变化接收端必须依赖 DMRS 插值去跟踪。链路级仿真输出的最常见中间量是 BLER-SNR 曲线。做这条曲线时你要注意仿真点数怎么取SNR 间隔 1dB 太粗0.2dB 太密合理的做法是先在 0 到 20dB 范围内做粗扫找到 BLER 从 0.9 跌到 0.01 的区间再在这个区间内以 0.5dB 间隔加密。每个 SNR 点至少要跑 1000 个传输块BLER 要降到 0.01 时统计置信度才够只跑几十个传输块得出的 0 和 1 没有任何意义。3.2 系统级仿真为什么不能直接跑全物理层抽象的必要性如果你把系统级仿真也做成每个 TTI 都跑一次完整的 Turbo 编解码那么一个 57 小区的网络每毫秒要处理几十个用户的物理层收发计算量是任何普通工作站都扛不住的。系统级仿真的核心思想是把链路级仿真已经得到的 BLER 曲线或者吞吐量查找表抽象成一个接口系统级只负责调度、干扰计算和信道大尺度衰落不碰具体比特。这就是 SISO.zip 这类包同时包含链路级和系统级的原因先用链路级仿真生成“CQI 到 BLER”的映射表然后在系统级仿真里UE 上报 CQI调度器根据 CQI 选择 MCS再从链路级表里查到这个 MCS 在当前 SNR 下的 BLER决定这个传输块是否传输成功。这个抽象省掉了物理层的比特级计算代价是牺牲了时间分集和信道估计误差带来的细节但这两个因素在系统级的研究问题里本来就是次要变量。系统级仿真的空间尺度也完全不同。链路级关心的是几微秒到几毫秒的时间粒度系统级用的是 15 分钟甚至更长的“drop”快照机制来模拟用户的移动和信道大尺度变化。每个 drop 里用户位置固定阴影衰落固定只有快衰落按多普勒频谱在子帧粒度上更新。SISO.zip 里的系统级代码通常会有一个外层循环是 drop内层循环是子帧你在配置里看到的nDrops 100和nSubframes 200指的就是这两层循环次数。3.3 下行链路 SISO 系统级仿真的链路抽象接口CQI、MCS 和 BLER 查找表下行链路的系统级仿真流程可以概括成四步第一基站给每个用户分配资源块第二用户在对应资源块上测量 SINR第三用户将 SINR 映射成 CQI信道质量指示上报第四基站参考 CQI 选择 MCS 并在下一个 TTI 调度传输。SISO 场景下 CQI 上报不需要考虑预编码和秩所以 4 比特 CQI 表的映射规则相对直白CQI 值与 SINR 的对应关系可以用 BLER 仿真校准得到通常是选择 BLER 不超过 0.1 的最高 CQI。这里有个系统级仿真特有的细节叫 CQI 上报延迟。UE 在第 n 个子帧测得 SINR上报给基站基站第 n8 个子帧才能使用这个信息做调度。在低速场景下这个延迟可以忽略因为信道变化相对缓慢但用户移动速度达到 120km/h 时8 毫秒里信道已经明显变化基站使用的 MCS 可能已经过时。如果你的系统级仿真结果在高速场景下吞吐量骤降先不要怀疑调度算法去核查 CQI 延迟参数有没有设置对这比任何调度优化都更影响结果。# 系统级仿真配置片的典型写法YAML/类XML风格重点看接口层的参数 system_level: drops: 100 # 快照数每个drop内用户位置固定 subframes_per_drop: 200 # 每个drop内的子帧数200ms仿真时间 cqi_report_period: 10 # 每10个子帧上报一次CQI即10ms周期 cqi_delay: 8 # 上报到调度生效的延迟单位子帧 scheduler: proportional_fair link_abstraction: table_file: bler_table_siso_dl.csv # 链路级仿真生成的查找表 snr_min: -5.0 snr_max: 25.0 snr_step: 0.5配置里的bler_table_siso_dl.csv就是链路级和系统级之间的桥梁。这个文件的每一行通常是某个 SNR 和某个 MCS 组合对应的 BLER 值系统级仿真在调度时直接查表用随机数和 BLER 值比大小来决定传输成败。如果你直接用下载包里自带的表而没有用你自己的信道模型重新生成那么链路级和系统级的信道假设必须一致——比如链路级用的是 ETU 信道而系统级用的路损模型假设了郊区场景这个组合就是不匹配的结果会体现出莫名其妙的吞吐量偏高或偏低。4. 把 SISO 下行链路仿真跑起来配置文件结构与必调参数4.1 配置文件的分层结构与修改顺序几乎所有正经的仿真包都会把链路级和系统级的配置分开因为两套仿真对参数的需求差异太大。链路级配置文件的核心参数是信道模型、MCS、RB 数和 SNR 扫描范围系统级配置则更关注小区布局、用户数、调度器类型和 CQI 参数。SISO.zip 的常见做法是提供两个入口脚本链路级一个系统级一个你直接修改对应的配置文件就行。我第一次跑这类仿真时犯过一个低级错误直接修改了系统级配置里的snr_range以为这能把仿真出来的吞吐量曲线拉直结果链路级模块调用的还是它自己配置里的 SNR 范围。链路级和系统级共用了同一个全局配置文件但各自的模块只认自己的配置段。所以你在动手前先打开配置文件确认[link_level]和[system_level]这两个段的边界改参数时不要跨段操作。修改顺序有讲究。先改链路级的信道模型和 MCS跑通一版 BLER 曲线再改系统级的小区半径和用户数跑通吞吐量曲线。如果一上来就同时改 10 个参数结果异常时你根本没法定位是哪个参数造成的。我通常会把链路级仿真当作系统级仿真的前置步骤链路级表生成之后冻结链路级配置只调整系统级参数这样问题边界最清晰。4.2 必调参数MCS、信道延迟剖面、UE 速度与衰落粒度链路级仿真最值得你手动调的四个参数如下。第一个是 MCS它决定了调制阶数和 TBS 的索引直接决定一条 BLER 曲线的位置MCS 越大曲线越靠右你需要看的是曲线形状而不是位置。第二个是信道延迟剖面EPA 剖面下信道平坦ETU 剖面下频率选择性很强同一条 MCS 在 ETU 下的 BLER 曲线会比 EPA 下陡一些但平台区也高一些这反映的是频率分集在实际信道里的收益。第三个是 UE 速度它决定多普勒频移低速下信道时间相关性高BLER 曲线会表现为明显的分集阶数高速下曲线会变得平滑但整体性能下降。第四个是 SNR 扫描点数和范围这影响仿真的运行时间和曲线分辨率。系统级仿真里还有两个参数容易被人忽略。一个是scheduler_granularity按 RB 粒度调度比按子带粒度调度计算量大几倍结果差异却不大对于 SISO 下行链路按子带调度加 PF比例公平算法就能给出接近真实的平均吞吐量。另一个是harq_max_retx这个参数控制 HARQ 最大重传次数设置为 4 是标准做法设置为 0 会让 BLER 直接影响到 RLC 层导致重传和时延异常其实这不是物理层仿真的目标。市面上的仿真包在衰落信道的更新方式上有两类实现一类是每个子帧都重新生成信道系数另一类是每 N 个子帧更新一次并在其间插值。后者的N值直接决定仿真速度和信道时间相关性的准确度。对于 30km/h 的 UE载波频率 2GHz 时最大多普勒频移约 55Hz信道相干时间大约 18ms所以每隔 5 个子帧更新一次信道足以保持精度太多只会白白增加计算量。4.3 一次完整的运行流程从链路级到系统级的命令和产物先跑链路级仿真命令通常是进入link_level目录后运行主脚本配置好 SNR 扫描范围和传输块数量输出会是一个 CSV 或 MAT 格式的文件内容是每条 MCS 在对应 SNR 下的 BLER。拿到这个表后你需要做一步质量校验把 BLER 曲线画出来看看有没有非单调的区域或者下降斜率忽大忽小的点如果有大概率是仿真次数不足导致的统计抖动而不是算法出问题加密传输块数即可。然后跑系统级仿真。系统级不会直接输出实物吞吐量而是输出每个 UE 在每个子帧的调度记录包括分配的 RB、MCS 和是否 ACK。最方便的聚合指标是用户平均吞吐量总 ACK 的传输块大小之和除以仿真时长。SISO.zip 里的工具脚本一般能直接从日志里提取这个数但你要注意日志里的成功传输是按传输块计数的如果启用了 HARQ一个传输块可能对应多次尝试吞吐量计算只算第一次成功传输的 TBS不算重传。# 链路级仿真命令行示例Windows 下用批处理或 PowerShell 同理 cd link_level python run_link_simulation.py --config siso_dl_etu_30kmh.yaml --snr_range -5 25 1.0 # 输出: bler_table_etu_30kmh.csv行SNR列MCS # 系统级仿真指定用上面生成的链路级表 cd ../system_level python run_system_simulation.py --config siso_dl_pf_scheduler.yaml \ --link_table ../link_level/bler_table_etu_30kmh.csv # 输出: scheduler_log.csv每行是一个TTI的调度决策和ACK/NACK跑完系统级仿真的第一件事不是看吞吐量平均值而是看调度器的资源分配公平性用日志算每个 UE 分到的 RB 数方差如果方差过大可能不是调度器的问题而是你的用户分布不均匀——有的 UE 始终在小区边缘CQI 低到几乎拿不到调度机会。这种时候把用户分布参数里的最小路径损耗约束调大一点让所有 UE 至少有一个可用的 SINR 下限比折腾调度器更有用。5. 仿真常见问题与避坑SISO 下行链路仿真的五个经典翻车点5.1 现象高 SNR 下吞吐量为零但星座图是清晰的这是最恼人的问题之一BLER 曲线在 SNR 超过 20dB 时仍然显示所有传输块都失败去看接收星座图却干净得可以直接做教材。问题根源几乎总是同步偏移接收端不知道 OFDM 符号的起始位置在移除循环前缀时多切了一个采样点。原因通常是仿真代码里噪声功率归一化时没有考虑过采样率导致 N0 偏大MMSE 均衡权重被过分压低。解决方法是先做整数倍采样偏移搜索对接收序列做自相关找到符号边界然后对比发射端的符号起始点。另一个更隐蔽的原因是发射端和接收端的 DMRS 生成函数用了不同的cell_id接收端把干扰当作有用信号来估计信道星座图看着清晰数据却全部解错。将发射端和接收端的cell_id打印出来核对一遍是五分钟可以完成的排查却是我见过最高频的翻车原因。重要提示是链路级仿真里cell_id可以随便选但发射端和接收端必须一样系统级仿真里每个小区用自己的cell_idUE 必须知道自己所在小区的 ID。5.2 现象系统级仿真中 UE 吞吐量随车速提高出现悬崖式下跌用户移动速度从 3km/h 调到 30km/h 再到 120km/h平均吞吐量不是平缓下降而是在某个速度段突然掉一截。这个现象的根源是 CQI 延迟与信道相干时间的比值穿越了一个阈值CQI 上报延迟 8ms当信道相干时间小于 16ms 时基站拿到的 CQI 已经和实际信道脱节至少一个周期MCS 选择的错误率陡增。解决方法是检查两件事第一系统级仿真的cqi_delay参数是否设成了 0如果设成 0 会人为消灭这个效应第二如果延迟确实是 8ms考虑用外插预测器用最近两次 CQI 的历史差值预测当前信道的 CQI这是 3GPP 相关研究里常用的手段实现成本很低能挽回约 5% 到 10% 的吞吐量损失。还有一种原因是链路级表本身是在低多普勒条件下生成的你在系统级里用了高速场景却复用了那张低速的 BLER 表。链路级表必须按 UE 速度分档生成0 到 3km/h 一档、30km/h 一档、120km/h 一档三张表对应的 BLER 曲线差异显著尤其在 MCS 较高时。给系统级仿真配置动态的链路级表是仿真从入门迈向合格的标志。5.3 现象BLER 曲线在中高 SNR 区域出现多处跳变曲线不光滑BLER 曲线在 10dB 附近上下抖动不是单调下降甚至像锯齿。原因几乎肯定是传输块数量太少BLER 等于 0.01 需要至少 100 个错误的传输块才能得到稳定的估计值如果你的仿真停在第一个 100 个错误块就提前终止那么在高 SNR 区错误块原本就稀少统计结果必然抖动。解决方法是给仿真澄清一个终止准则要么固定跑完 N 个传输块要么采样到足够的错误块数二选一。我习惯把错误块数阈值设成 200 到 500这样 BLER 在 0.01 附近的置信区间才能收窄到可以接受的范围。如果传输块数量已经很大还是有跳变再去检查信道实现是否在每个 SNR 点都重新生成了一次。有的仿真代码实现了一个信道实例然后在 SNR 循环里复用这会让 SNR 点的性能差异被同一个信道异常实现主导曲线自然不光滑。每个 SNR 点独立刷新信道种子这是常识级别的要求但代码里经常被忽略。5.4 现象仿真吞吐量比理论频谱效率峰值高出 10% 以上如果你的 SISO 下行链路仿真吞吐量超过了香农容量对应的数值或者超过了 3GPP 仿真约定中给出的峰值频谱效率那肯定有参数设置错误。最常见的元凶是资源映射时没扣除 DMRS 和控制信道的开销前面算过理论比特数用n_prb * 12 * 7 * 2 * mod_order但这是 PDSCH 满载才有的值实际每个 RB 里 DMRS 占了大约 1/7 的资源单元PDCCH 还会占掉前 1 到 3 个 OFDM 符号。如果系统级仿真里调度器按满 RB 分配而物理层按实际可用 RE 计算 TBS中间就产生了虚高。另一个常见原因是链路级 BLER 表的 SNR 轴和系统级 SINR 轴没有对齐。链路级仿真里的 SNR 是每 RE 的符号能量除以噪声功率系统级仿真的 SINR 可能包含了小区间干扰、可能扣除了导频功率两个定义不在一个坐标系里查表时选错就查到了更高的 MCS。解决方法是统一两者的参考点规定链路级表的横轴是每 RE 的 SINR系统级在查表前也把干扰和噪声折算成每 RE 的 SINR并在代码里加一行断言确保这个值在链路级表的覆盖范围内。5.5 现象仿真运行太慢一个系统级场景要跑三天SISO 下行链路系统级仿真的计算瓶颈往往不在信道生成而在调度器内部的 RB 分配循环。如果调度器对每个 TTI 都做全用户全 RB 的暴力搜索复杂度是 O(用户数×RB 数)看起来不大但乘以 100 个 drop 乘 200 个子帧就变得可观了。首先要检查衰落信道的更新间隔前面说过 5 个子帧更新一次就够如果代码每子帧更新浪费了约 80% 的时长。其次检查 CQI 表是否被重复计算每个 TTI 重新读 CSV 并解析比在仿真启动时一次性加载内存慢一个数量级。最后一个建议是减少 drop 的重复度。如果你的 100 个 drop 里用户位置和阴影衰落基本没变那你实际上在重复仿真同一个场景drop 数量减到 20 个就能达到同样的统计精度。与其盲目增加 drop 数不如先画出吞吐量随 drop 数累计均值的变化曲线稳定了就收手这个习惯能让你的仿真时间缩短一半以上。6. 进阶技巧把链路级曲线收进仿真检查表让每一版改动都有回归依据有一个很值得养成的习惯把链路级 BLER 曲线固定下来作为回归测试的基线。每当你修改了系统级代码的任何部分比如调度器、干扰模型或者 HARQ 逻辑跑完系统级仿真后回到链路级重跑一遍同一组配置对比这次的 BLER 曲线和基线有没有偏移。如果偏移超过 0.5dB大概率是你动代码时不小心改到了物理层共用的模块或者链路级表文件的路径被覆盖了。这个回归流程成本很低却能让你的仿真结果具备可追溯性不再出现“上一版结果还行这版突然不对”的玄学问题。我处理这类 LTE 下行链路仿真项目时最后一步几乎都是同一件事把仿真输出的文件清单梳理一遍按“链路级表 系统级日志 聚合脚本”三件套归档文件名里带上信道模型、速度和日期。这套习惯拯救过我好几次两周前生成的表因为中间动过一次信道参数系统级结果怎么都对不上仿真论文的曲线回看归档才发现链路级表是用旧的 ETU 配置生成的重新生成一张表就解决了。验证仿真结果合理性的最后一个技巧是比对一个参考点下的理论值1 个 RB 对应 180kHz 带宽SISO 下行用 64QAM 时峰值频谱效率约 4.5 到 5bps/Hz实际能跑到理论值的 70% 到 80% 就算健康。如果差太多就回头查 MCS 选择、控制信道开销或者 CQI 延迟这三项十有八九是它们出了问题。希望这篇避坑与实操笔记帮到你愿你的仿真曲线早日光滑、你的吞吐量早日收敛到理论值附近。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
