维也纳大学LTE系统级仿真MATLAB工程：含调度器、信道建模与链路接口的可运行完整实现-优快云博客

本文还有配套的精品资源，点击获取

简介：这个MATLAB资源包来自维也纳大学，提供一套开箱即用的LTE系统级仿真环境，覆盖UE和eNodeB建模、宏微路径损耗计算（macroscopicPathlossMap）、快衰落与阴影衰落建模（fastFadingWrapper、shadowFadingMapClaussen）、多种调度策略（比例公平、轮询、最优CQI、标准LTE调度器）、上下行信道模型（downlinkChannelModel/uplinkChannelModel）、资源块网格管理（resourceBlockGrid）、BLER曲线拟合（blerCurves）、CQI映射（cqiMapper）以及用户移动轨迹生成（straightWalkingModel、ueTrace、sectorTrace）。所有模块均通过runSimulation.m统一调用，simulationResults.m输出吞吐量、覆盖率、调度公平性等关键指标，配套ueSpecificTraces、cellSpecificTraces、schedulerTrace等中间过程追踪脚本，便于调试与结果分析。支持典型宏蜂窝/微蜂窝混合部署场景复现，代码结构清晰、注释完整，经实测可在MATLAB R2018a及以上版本直接运行，无需额外工具箱，适合通信方向本科生课程设计、研究生课题快速验证及LTE系统级仿真方法入门学习。

1. 这不是“跑个demo”，而是一套能真正讲清LTE系统级仿真逻辑的MATLAB骨架

你有没有试过打开一个标着“LTE仿真”的MATLAB工程，点开runSimulation.m，等三分钟弹出一张吞吐量曲线图，然后——就没了？既不知道调度器到底在哪个时刻给哪个UE分配了哪几个PRB，也搞不清阴影衰落是怎么从2D地图映射到每个UE的瞬时信干比上的，更别提想改个调度策略、加个新移动模型，结果发现模块之间耦合得像一锅炖烂的豆角——改一行，报十行错。我带本科生做通信系统课程设计那会儿，翻遍GitHub和IEEE Xplore，90%的所谓“LTE仿真”项目，本质是链路级（link-level）脚本堆砌，顶多加个静态路径损耗，根本谈不上“系统级”（system-level）：没有小区拓扑管理、没有用户空间分布与移动性建模、没有跨层接口（比如CQI反馈如何驱动调度器决策）、没有资源块（RB）粒度的时频二维调度过程追踪。直到我在维也纳大学无线通信组（Institute of Telecommunications）的公开教学资源库中，挖到这个被他们用作《Advanced Wireless Systems》课程实验的MATLAB工程包。它不炫技，不包装，目录结构平实得像教科书目录，但每一个.m文件名背后，都对应着3GPP TS 36.814里白纸黑字定义的系统级仿真关键实体。它不叫“LTE Simulator Pro”，就叫runSimulation.m；它的调度器不藏在某个加密的class里，而是四个清晰命名的函数：proportionalFairScheduler.m、roundRobinScheduler.m、bestCqiScheduler.m、lteScheduler.m——你打开就能看到PF调度里那个经典的log(SINR)/∑log(SINR)公平性因子是怎么实时累加的，也能看到lteScheduler.m里如何严格遵循3GPP的PDCCH盲检规则模拟控制信道开销。它甚至没用任何Simulink或5G Toolbox，纯Script+Function架构，所有信道建模参数（如宏路径损耗指数、阴影衰落标准差、快衰落瑞利分布尺度）全部显式暴露在配置结构体里，而不是硬编码在几百行if-else深处。这套代码的价值，不在于它能跑出多漂亮的PDF报告，而在于它把“系统级仿真”这五个字，拆解成了你能亲手触摸、逐行调试、理解因果的27个独立模块。关键词里的“LTE仿真”不是泛泛而谈，“Matlab通信”意味着零工具箱依赖，“调度算法”是四种可插拔策略的对比实验平台，“信道建模”则覆盖了从公里级宏路径损耗（macroscopicPathlossMap）到毫秒级快衰落（fastFadingWrapper）再到百米级阴影衰落（shadowFadingMapClaussen）的完整尺度链。它适合谁？不是只想要一键出图的速成党，而是愿意花三天时间，把ueTrace.m里那个straightWalkingModel的步长更新逻辑、resourceBlockGrid.m里RB索引到物理资源映射、blerCurves.m中基于3GPP TR 36.814 Table A.2.1.1-1的拟合系数推导，全都掰开揉碎弄明白的人。换句话说，它是一套“可解剖”的LTE系统级仿真教具，而你，就是那个拿着手术刀的解剖者。

2. 系统级仿真的核心骨架：为什么必须是“宏-微-快”三级衰落 + 跨层接口？

系统级仿真（System-Level Simulation, SLS）和链路级仿真（Link-Level Simulation, LLS）的根本分水岭，不在于代码长短，而在于是否建模了空间维度上的用户分布、时间维度上的移动性、以及网络维度上的资源竞争与反馈闭环。维也纳大学这套工程，正是以极其克制的代码量，精准锚定了SLS的三大支柱：空间信道建模、动态调度决策、跨层信息流。我们先看最底层的信道——它绝不是一句“SNR = P_tx / (PL * SF)”能概括的。这套代码强制你面对一个现实：真实蜂窝网络里，一个UE收到的信号强度，是三个不同物理尺度、不同时间常数的衰落效应叠加的结果。第一级是宏路径损耗（Macroscopic Path Loss），它由macroscopicPathlossMap.m实现。这个函数不是简单调用一个公式，而是构建了一个二维地理网格（默认1000m×1000m），对网格内每个坐标点，根据预设的eNodeB位置、天线高度、UE高度、载波频率（默认2GHz），计算自由空间损耗、地物绕射损耗（使用COST-231 Hata模型扩展）、以及建筑穿透损耗。关键点在于，它输出的不是一个标量，而是一个[X, Y]维度的矩阵pathLossMap，也就是一张“信号热力图”。这意味着，当你把UE放在(350m, 420m)时，它查表得到的路径损耗值，和放在(351m, 420m)时是不同的——这是空间连续性的基础。第二级是阴影衰落（Shadow Fading），由shadowFadingMapClaussen.m负责。Claussen模型是维也纳大学团队提出的经典方法：它假设阴影衰落具有空间相关性，即相距很近的两个点，其阴影衰落值相似。该函数生成一个与pathLossMap同尺寸的shadowFadingMap，但不是随机高斯噪声，而是通过二维高斯滤波器（kernel size由相关距离决定，如10m）对白噪声进行平滑，从而模拟出“一片楼群造成的整体信号减弱”这种宏观遮挡效应。第三级才是快衰落（Fast Fading），由fastFadingWrapper.m封装。它在每次调度周期（TTI=1ms）开始时，为每个UE-eNodeB链路独立生成一个复高斯随机变量（服从瑞利分布），代表多径引起的毫秒级信号幅度剧烈波动。注意，fastFadingWrapper并不直接生成随机数，而是调用PregeneratedFastFading.m——后者预先生成了足够长的快衰落序列（例如10^6个样本），避免了实时生成带来的计算开销和随机种子不可重现问题。这三级衰落不是简单相乘：TotalChannelGain = 10^(-pathLoss_dB/10) * 10^(-shadowFading_dB/10) * |fastFading_complex|^2。这个公式背后，是物理层（快衰落）与网络层（宏/阴影衰落）的时间尺度分离原则：快衰落变化太快（毫秒级），调度器无法跟踪，所以调度决策基于慢变的平均信道状态（即宏+阴影后的平均SINR）；而宏/阴影衰落又太慢（秒级），可以视为在一次完整仿真（几秒到几十秒）内恒定，因此可以预先计算好地图。这种“三级衰落+时间尺度分离”的设计，正是系统级仿真区别于链路级仿真的灵魂所在。再看跨层接口，这是让整个系统“活起来”的关键。cqiMapper.m就是一个典型桥梁：它接收来自downlinkChannelModel.m计算出的瞬时SINR（已包含所有三级衰落），然后根据3GPP定义的CQI表格（Table 7.2.3-1 in TS 36.213），将SINR映射为一个整数CQI值（1-15）。这个CQI值，不是仅供显示，而是被ueSpecificTraces.m实时记录，并作为proportionalFairScheduler.m的输入——调度器据此评估每个UE的瞬时信道质量。而调度器的输出（分配给某UE的PRB集合），又会反馈给uplinkChannelModel.m，用于计算上行ACK/NACK反馈的可靠性，进而影响重传机制。你看，cqiMapper就像一个翻译官，把物理层的模拟量（SINR）翻译成MAC层能理解的数字指令（CQI）；schedulerTrace.m则像一个监控探头，把调度器的每一次决策（时间戳、UE ID、分配RB数、CQI值、历史吞吐量）都记下来。没有这些接口，你的仿真就是一堆孤立的数学公式；有了它们，它才成为一个有输入、有处理、有反馈、有记忆的动态系统。这就是为什么维也纳大学的代码目录里，ueSpecificTraces.m和cellSpecificTraces.m的存在感，丝毫不亚于eNodeB.m——它们不是附属品，而是系统级仿真的“神经系统”。

3. 核心模块深度解析：从UE移动轨迹到资源块网格的全链路拆解

现在，我们把镜头拉近，沿着一次完整的仿真流程，逐个拆解那些看似平淡无奇、实则暗藏玄机的.m文件。起点是straightWalkingModel.m——别小看这个“直线行走模型”，它是整个时空仿真的基石。它不生成复杂的曼哈顿轨迹或随机游走，而是让UE以恒定速度v（默认1m/s）沿指定方向角theta（默认0°，即正东）匀速移动。关键在于它的输出：一个N_timesteps × 2的矩阵positionHistory，每一行是(x, y)坐标。这个矩阵被ueTrace.m读取，并在每个TTI（1ms）时刻，调用macroscopicPathlossMap.m和shadowFadingMapClaussen.m查表，得到该时刻的路径损耗和阴影衰落值。这里有个极易被忽略的细节：ueTrace.m内部有一个interpolatePosition标志位。当UE在两个离散TTI时刻之间移动的距离小于网格分辨率（如1m）时，它会启用线性插值，确保信道参数随位置连续变化，而非阶梯状跳变。这种对“运动连续性”的尊重，是保证仿真结果物理可信度的前提。接下来是eNodeB_sector.m和eNodeB.m。前者定义单个扇区（通常120°），包含天线增益模式（如经典的余弦平方模型）、下倾角、发射功率；后者则是一个容器类，管理多个扇区（如典型的三扇区宏站），并提供getSINR方法——这才是真正的“信道计算器”。它接收UE位置、当前TTI、以及所有干扰源（其他eNodeB扇区）的位置和功率，综合计算出该UE在目标扇区下的SINR。计算过程严格遵循香农容量公式变形：SINR = P_signal / (P_interference + P_noise)，其中P_noise由热噪声功率谱密度（-174 dBm/Hz）和系统带宽（默认10MHz）决定。downlinkChannelModel.m和uplinkChannelModel.m则在此基础上，加入快衰落和编码调制效率（MCS）的影响，最终输出BLER（误块率）。而blerCurves.m的作用，就是把理论SINR映射到实际BLER。它不采用简单的查表，而是基于3GPP TR 36.814的拟合公式：BLER = 1 / (1 + exp(a * (SINR - b)))，其中a和b是针对不同MCS等级（QPSK, 16QAM, 64QAM）和码率（1/3, 2/3）预设的系数。你可以打开这个文件，看到一个清晰的switch case结构，对应着3GPP标准中的每一个MCS索引。最后，我们来到整个系统的“心脏”——resourceBlockGrid.m。它不是一个简单的二维数组，而是一个精心设计的状态机。它初始化一个N_RB_DL × N_slots_per_frame（下行资源块数×每帧时隙数）的网格，每个单元格存储着{allocated_to_UE_ID, MCS_index, RB_type}等元数据。RB_type尤其重要：它可以是PDSCH（数据信道）、PDCCH（控制信道）、PHICH（HARQ确认信道）或RS（参考信号）。lteScheduler.m在分配资源时，必须首先查询此网格，避开已被PDCCH占用的控制区域（通常前1-3个OFDM符号），才能将PRB分配给UE。resourceBlockGrid.m还提供了getAvailableRBs方法，返回当前TTI所有空闲RB的索引列表，供调度器选择。这解释了为什么proportionalFairScheduler.m的代码里，总能看到availableRBs = rbGrid.getAvailableRBs();这样的调用——调度器的“智能”，是建立在对底层资源状态精确感知的基础之上的。再看fifoQueue.m，它看起来只是一个先进先出队列，但却是ueSpecificTraces.m实现历史吞吐量统计的关键。每当一个UE成功接收一个TB（传输块），ueSpecificTraces.m就会调用fifoQueue.push(tb_size_bits)，并将队列中最老的一个TB大小弹出。这样，队列始终维持最近N个TTI的吞吐量历史，proportionalFairScheduler.m计算公平性因子log(throughput)时，用的就是这个滑动窗口的平均值。这种设计，让PF调度器真正实现了“长期公平”，而非瞬时公平。所有这些模块，最终被runSimulation.m这个“总指挥”串联起来。它定义了仿真总时长、TTI步进、用户数、基站部署等顶层参数，然后在一个巨大的for t = 1:N_TTI循环中，依次调用：ueTrace.updatePosition() → eNodeB.getSINR() → cqiMapper.mapToCQI() → scheduler.schedule() → rbGrid.allocate() → downlinkChannelModel.calculateBLER() → ueSpecificTraces.record()。这个循环，就是LTE系统在数字世界里的一次真实心跳。而simulationResults.m，则是这场心跳监测的最终报告员，它从所有Traces对象中提取数据，计算出平均吞吐量、边缘覆盖率（如RSRP < -110dBm的UE占比）、Jain’s Fairness Index等核心KPI。你看到的每一个指标，都不是凭空而来，而是这27个模块协同工作的必然产物。

4. 四种调度算法实战对比：从轮询到比例公平的性能跃迁

调度算法是系统级仿真的“大脑”，它决定了有限的无线资源（PRB）如何在众多UE之间分配，直接决定了网络的吞吐量、公平性和用户体验。维也纳大学的工程包之所以珍贵，在于它没有只给你一个“黑盒调度器”，而是提供了四种截然不同、且完全开源的实现，让你能亲手运行、对比、理解每一种策略的内在逻辑与外在表现。我们按复杂度递增的顺序，逐一剖析。

4.1 轮询调度器（roundRobinScheduler.m）

这是最朴素、最公平的起点。它的核心思想是“人人平等，轮流坐庄”。代码逻辑异常简洁：维护一个全局计数器nextUEIndex，初始为1。每次调度时，它从availableRBs列表中，按顺序分配固定数量的RB（如2个）给UE(nextUEIndex)，然后nextUEIndex = mod(nextUEIndex, N_UE) + 1。它的优势是极致的简单与绝对的时域公平——每个UE在相同的时间间隔内，获得完全相同的调度机会。但致命缺陷在于完全无视信道状态。想象一个场景：UE1位于基站正下方，SINR高达30dB；UE2在小区边缘，SINR只有5dB。轮询调度器会给它们分配同样数量的RB。结果是，UE1能用64QAM高效传输，而UE2可能只能用QPSK，甚至因BLER过高而频繁重传。最终，系统总吞吐量被UE2严重拖累，而UE1的潜力被白白浪费。simulationResults.m的输出会清晰显示：轮询调度的“平均吞吐量”很低，但“吞吐量标准差”也很小——大家都不怎么样，但都很稳定。这是理解“信道感知调度”必要性的最佳反面教材。

4.2 最优CQI调度器（bestCqiScheduler.m）

如果说轮询是“平均主义”，那么最优CQI就是“精英主义”。它的哲学是：“把最好的资源，给最能用好的人”。算法逻辑是：遍历所有UE，计算其当前CQI值（由cqiMapper提供），选择CQI最高的UE，然后将所有availableRBs分配给它。这带来了惊人的峰值吞吐量——系统总吞吐量在所有算法中最高。但代价是灾难性的公平性。simulationResults.m会显示一个极端的“长尾分布”：少数几个中心UE占据了90%以上的资源，而边缘UE可能在整个仿真过程中，一次都没被调度过，其吞吐量为0。Jain’s Fairness Index会跌至0.3以下（1.0为绝对公平）。这在现实中是不可接受的，因为它违背了蜂窝网络的基本服务承诺——为所有注册用户提供基本连接保障。

4.3 比例公平调度器（proportionalFairScheduler.m）

PF调度器是3GPP LTE标准推荐的核心算法，它试图在吞吐量与公平性之间找到黄金平衡点。其核心公式是：Metric(UE_i) = log(Throughput_i_current) / log(Throughput_i_average)。这里的Throughput_i_average，正是前面提到的fifoQueue维护的滑动窗口平均吞吐量。算法步骤是：1) 对每个UE，计算其Metric；2) 选择Metric最大的UE；3) 分配RB。这个公式的精妙之处在于：对于一个长期吞吐量很低的UE（如边缘UE），其分母很小，Metric值会被放大，从而获得更高的调度优先级；而对于一个长期吞吐量很高的UE（如中心UE），其分母很大，Metric值会被抑制，防止其垄断资源。proportionalFairScheduler.m的代码里，你会看到log(throughput + eps)这样的写法，eps是为了避免对0取对数。实测结果表明，PF调度器的平均吞吐量虽略低于最优CQI，但远高于轮询；其公平性指数（Jain’s Index）通常稳定在0.8-0.9之间，是四种算法中最均衡的。它完美诠释了“牺牲一点峰值，换取整体稳健”的工程智慧。

4.4 标准LTE调度器（lteScheduler.m）

这是最接近真实商用设备的实现。它不仅仅是一个调度逻辑，而是一个完整的“MAC层协议栈”模拟器。它包含了：1) PDCCH盲检模拟：根据UE的C-RNTI和聚合等级（AL），计算其需要监听的PDCCH候选位置，并模拟盲检失败的概率（与PDCCH BLER相关）；2) HARQ进程管理：为每个UE维护4个并行的HARQ进程，跟踪每个TB的传输次数（1st TX, 2nd TX…）；3) 资源分配约束：必须遵守3GPP的RB分配规则，如分配的RB必须是连续的（对于非MIMO传输），且不能跨越控制区域。lteScheduler.m的代码量是四种中最大的，因为它要处理大量协议细节。运行它，你才会真正理解为什么一个“理论上可用”的RB，在实际调度中可能因为PDCCH容量不足或HARQ反馈冲突而无法分配。它的性能通常介于PF和最优CQI之间，但其价值不在于KPI数字，而在于它教会你：真实的LTE调度，永远是在协议约束、硬件限制和算法目标之间的多目标优化。

提示：在runSimulation.m中，只需修改一行代码schedulerType = 'proportionalFair';，即可切换算法。强烈建议你依次运行四种，然后打开simulationResults.m生成的results_summary.txt，重点关注Average Throughput (bps), Edge Coverage (%), Jain's Fairness Index这三个指标的变化。你会发现，这不是一个“哪个更好”的问题，而是一个“在什么场景下，哪种权衡更合适”的工程决策问题。

5. 实操避坑指南：从MATLAB版本兼容到BLER拟合误差的独家经验

作为一个在实验室里用这套代码带过六届学生的“老司机”，我必须坦诚地告诉你：这套代码虽然“开箱即用”，但开箱后，你一定会遇到几个几乎人人都踩过的坑。这些坑，官方文档不会写，Stack Overflow上也找不到标准答案，它们只存在于你深夜调试时的抓狂瞬间和最终解决后的恍然大悟。下面，我把这些血泪经验，毫无保留地分享给你。

5.1 MATLAB版本与工具箱陷阱：R2018a是底线，但“无工具箱”有前提

摘要里说“无需额外工具箱”，这句话完全正确，但有一个至关重要的前提：你必须使用MATLAB R2018a或更高版本。为什么？因为resourceBlockGrid.m中使用了containers.Map类的isKey方法，这个方法在R2017b及更早版本中不存在。如果你强行在R2017a上运行，会在rbGrid.isKey(rbIndex)这一行报错。解决方案只有两个：升级MATLAB，或者手动修改resourceBlockGrid.m，用ismember(keys(rbGrid), rbIndex)替代。我强烈推荐前者，因为R2018a引入的timetable数据类型，对ueSpecificTraces.m中的时间序列分析也至关重要。另一个隐形陷阱是“无工具箱”的解读。代码确实不依赖Communications Toolbox或5G Toolbox，但它隐式依赖Statistics and Machine Learning Toolbox——因为blerCurves.m中的fit函数（用于拟合BLER-SINR曲线）属于该工具箱。如果你的MATLAB没有安装它，blerCurves.m会报错。临时解决方案是：注释掉blerCurves.m中所有fit相关的代码，改为直接使用预设的拟合系数（文件开头就有coefficients = [a, b];的硬编码）。这不会影响仿真逻辑，只是让BLER计算从“自适应拟合”变为“查表”。

5.2 信道建模的“静默错误”：路径损耗地图的坐标系错位

这是最隐蔽、杀伤力最强的坑。当你第一次运行runSimulation.m，发现所有UE的吞吐量都低得离谱（<10kbps），且simulationResults.m显示边缘覆盖率高达99%，直觉告诉你“信号肯定很差”，但你检查macroscopicPathlossMap.m，参数设置明明没问题。问题往往出在坐标系错位。macroscopicPathlossMap.m默认生成的地图，其原点(0,0)在左下角，X轴向右，Y轴向上。但straightWalkingModel.m生成的positionHistory，其坐标系是(0,0)在中心，X轴向右，Y轴向上。如果你不做转换，ueTrace.m在查表时，会把一个本应在(350, 420)的UE，错误地查到了(-350, -420)这个根本不存在的地图坐标上，导致返回的路径损耗值为NaN或极大值。解决方案是：在ueTrace.m的updatePosition函数中，在调用pathLossMap之前，加入坐标系转换：

% 假设地图尺寸为 mapSizeX x mapSizeY
% UE position from straightWalkingModel is relative to center
x_map = position(1) + mapSizeX/2;
y_map = position(2) + mapSizeY/2;
% Now x_map, y_map are in the map's coordinate system (0,0 at bottom-left)

这个错误不会导致程序崩溃，只会让你得到一堆毫无意义的“低性能”结果，排查起来极其耗时。

5.3 调度器的“饥饿”与“假死”：FIFO队列长度与TTI步长的魔鬼关系

proportionalFairScheduler.m的公平性，高度依赖fifoQueue中历史吞吐量的准确性。而fifoQueue的长度N_history，是由runSimulation.m中的historyWindowTTIs参数决定的。一个常见的新手操作是：为了快速看到结果，把仿真总时长设得很短（如100ms），同时把historyWindowTTIs设得很大（如1000）。结果是，fifoQueue在仿真开始的前999个TTI里，一直处于“饥饿”状态——队列不满，averageThroughput无法计算，导致所有UE的Metric都为NaN，调度器陷入“假死”，不再分配任何资源。解决方案是：确保historyWindowTTIs远小于总TTI数（建议historyWindowTTIs <= totalTTIs / 10），并且在proportionalFairScheduler.m的calculateMetric函数开头，加入安全检查：

if length(queue) < 2
    metric = 1; % Default high priority for new UEs
else
    metric = log(currentTP + eps) / log(mean(queue) + eps);
end

5.4 结果分析的终极武器：不止看`simulationResults.m`，更要会“读”Trace文件

simulationResults.m给出的是宏观KPI，但真正的洞见，藏在ueSpecificTraces.mat这些二进制文件里。我教你一个绝招：用MATLAB的load命令加载它，然后用whos查看里面有哪些变量。你会发现traces.throughputHistory是一个N_UE × N_TTI的矩阵。你可以轻松画出任意一个UE的吞吐量随时间变化的曲线：

load('ueSpecificTraces.mat');
plot(traces.throughputHistory(5, :)); % 画第5个UE的吞吐量曲线
xlabel('TTI'); ylabel('Throughput (bps)');
title('UE #5 Throughput vs Time');

这条曲线会告诉你：这个UE是不是在经历周期性的调度（轮询的锯齿波）、还是间歇性的爆发（PF的脉冲式）、或是持续的“失联”（最优CQI的长零段）。这才是系统级仿真最迷人的地方——它不只是给你一个数字，而是给你一个故事，一个关于无线资源如何在时空中流动的故事。我个人在实际操作中发现，最有价值的分析，往往始于对一条“异常”曲线的好奇：为什么这个UE的吞吐量在第5000个TTI突然飙升？顺着这个线索，你可能会发现sectorTrace.m里扇区切换的触发点，或者receivedFeedbackTrace.m里一次关键的ACK反馈，从而真正理解协议交互的微观机制。

本文还有配套的精品资源，点击获取