蜂窝系统级仿真入门：调度算法对比与MATLAB实践

简介一份面向无线通信学习与研究者的MATLAB仿真资源聚焦蜂窝小区调度算法的设计与效果对比适合通信专业学生、算法入门者以及需要搭建蜂窝网络仿真基线的工程师使用。资源包内仅有1个m脚本体积仅约1KB代码轻量但覆盖典型调度策略可直接运行对比最大信噪比、比例公平、最大速率等算法在不同信道条件、QoS需求、资源分配及移动性场景下的性能表现。已有159人浏览学习可作为快速理解调度机制与网络性能权衡的入门起点。通过分析该脚本的结构与输出结果读者能掌握蜂窝仿真中吞吐量、公平性与延迟等关键指标的评估思路并基于现有框架扩展自己的改进算法是兼顾学习效率与实用性的小型示例。1. 拿到 test05_main2_02.rar 之后你的第一份蜂窝调度实验从哪开始一个命名规律极强的压缩包一串像版本号又像流水账的编号背后通常是某个课程大作业或仿真工程里流出来的例程。test05_main2_02.rar 这个包值得花点时间拆开看它对应的是蜂窝小区场景下的调度算法仿真——你在真实基站上不方便改的调度器、不敢随便动的功率参数在这里半小时就能跑出一组吞吐量数据。这类资源能解决一个很实际的问题蜂窝网络里边缘用户和中心用户怎么抢资源、调度器换成比例公平之后整网表现如何与其背理论不如亲自把仿真拉起来看曲线。适合刚开始接触系统级仿真的研究生也适合从网优转向算法验证的工程师。下面按真正动手的顺序来拆从解压识别框架到最小例程跑通再到调度器换参、结果对比和排错。2. 蜂窝仿真资源包落地先识别框架再跑通最小例程2.1 解压之后先别急着点 run识别这是什么仿真框架把 test05_main2_02.rar 解压后第一件事不是双击某个 main 脚本而是看目录结构和文件后缀。蜂窝小区仿真和链路级仿真最大的区别在于仿真对象链路级只关心一条无线链路的误码率、调制编码策略而蜂窝仿真要把整个网络搬进内存——多个基站、每个扇区下挂一批用户、用户之间的干扰关系、调度器在每个时间间隔里决定谁用哪块资源。我一般用下面这套命令快速摸底mkdir -p ~/cellular_sim cd ~/cellular_sim # 解压到独立目录避免污染已有的 MATLAB 工作区 unrar x test05_main2_02.rar # 观察顶层结构和 M 文件数量确认代码量级 ls -la # 统计 M 文件数量判断是完整平台还是精简例程 find . -maxdepth 2 -type f -name *.m | wc -l # 看看入口文件长什么样 find . -maxdepth 2 -type f -name *.m | head -20这套命令做完你对这个包就有基本判断了。.m后缀说明这是 MATLAB 生态的仿真工程大多数高校和研究所的蜂窝调度算法研究也确实跑在 MATLAB 系统级仿真平台上。find统计出来的 M 文件数量很关键如果总数在 50 个以上大概率是完整的系统级仿真框架里面有信道模型、链路自适应、调度器、流量模型这些完整模块如果只有十几个文件那就是裁剪过的精简例程后续你要自己补一些统计脚本。解压时还有一条实操建议路径里不要带中文和空格。MATLAB 对带空格或中文的路径支持一直不太稳尤其老版本跑仿真到一半报找不到文件很常见。2.2 在参数文件里定位调度算法入口确认枚举值写法蜂窝仿真框架里调度器的选择通常不是靠改代码而是改一个字符串枚举参数。常见写法是scheduler_type round robin、proportional fair或best cqi。问题是每个平台的参数名不一样有人叫scheduler有人叫scheduling_type有人把它藏在LTE_params结构体里。先用 grep 把所有出现 scheduler 的地方捞出来# 递归查找调度器参数定义的位置 grep -rn scheduler --include*.m . | grep -v test | head -20grep 输出的每一行都会告诉你文件路径和行号。找到参数定义文件后打开看一下支持的调度器枚举值。这一步很重要因为不同平台的枚举命名差异很大有的平台是RR有的是round robin你直接写rr可能会在仿真启动时报错。看到参数文件的写法后照着它的字符串格式填不要凭记忆写。确认入口之后跑最小例程% 载入默认蜂窝网络参数 setPARAM LTE_params; % 固定调度器为轮询作为后续所有对比实验的基线 setPARAM.scheduler_type round robin; % 7 个基站构成蜂窝拓扑这是最常见的三环布局 setPARAM.nr_of_eNBs 7; % 每个小区撒 20 个用户 setPARAM.nr_of_UEs 20; % 用户分布方式设为均匀撒点 setPARAM.UE_distribution constant; % 先跑 200 个 TTI验证链路是否打通 setPARAM.simulation_time_tti 200; % 进入主仿真循环返回结果结构体 sim_results LTE_sim_main(setPARAM); % 按小区画出平均用户吞吐量确认调度链路真的出数了 bar(sim_results.cell_throughput_per_user); title(每个小区的平均用户吞吐量Mbps);这段代码的关键在前三行LTE_params()把平台默认参数全部载入你只覆盖自己关心的几个字段而不是从头构造一个参数结构。nr_of_eNBs 7表示中心小区加外圈 6 个小区这是蜂窝仿真里最经典的布局UE_distribution constant是让用户均匀撒在小区覆盖范围内比随机撒点更容易复现。simulation_time_tti 200是验证期设置200 个 TTI 在真实业务里只有 0.2 秒但足以让调度器工作起来、让结果结构体有输出。如果 200 TTI 能跑完说明代码路径是通的再把时间往上加。2.3 跑通后先记录基线输出打点、拓扑与收敛性最小例程跑通之后不要急着换调度器。先把你看到的输出和默认行为记录成基线。通常仿真结果结构体里有每用户吞吐量、每小区吞吐量、每个 TTI 的总吞吐量历史有的平台还带每用户的 SINR 和调制编码策略记录。我习惯在跑完第一组数据后画一个调度收敛曲线% 检查吞吐量是否随 TTI 收敛 if isfield(sim_results, throughput_history) plot(mean(sim_results.throughput_history, 1)); xlabel(TTI); ylabel(全小区平均吞吐量Mbps); grid on; end这个图能告诉你两件事一是调度器从冷启动到稳态需要多少个 TTI如果 200 TTI 后曲线还在剧烈波动说明仿真时长不够后面正式实验要加长二是调度器本身是否稳定如果曲线在某个值附近来回震荡但幅度不超过 5%说明信道变化和用户移动导致的结果波动是正常的。基线数据记好后把调度器类型换成proportional fair其他参数完全不动再跑一遍。你会立刻看到小区平均吞吐量和边缘用户吞吐量的相对变化这是整个蜂窝调度仿真的第一个可对比结论。3. 蜂窝小区下的调度算法选型干扰不是噪声是调度出来的3.1 蜂窝调度与单小区调度的本质差异RB 分配决定邻区干扰很多人第一次从链路级仿真转到蜂窝小区仿真时不适应因为蜂窝场景里最关键的干扰项不是热噪声而是相邻小区在同一个资源块RB上的发射功率。这个干扰的大小不是固定的它随你调度器把哪个 RB 分给哪个用户而实时变化。你说某个用户 SINR 低多半不是信道差而是邻区有个大胖子用户正占着同一个频段猛发数据。蜂窝仿真在计算信号与干扰加噪声比时数学上表达为SINR(u) P_signal(u) / (I_intercell(u) N_0)其中 P_signal 是服务基站到用户的接收功率N_0 是热噪声基底I_intercell 是来自所有邻区在同一个 RB 上的干扰功率之和。这个 I_intercell 就是调度出来的——邻区调度器把用户 A 放在 RB 10 上你这里 RB 10 上的干扰就会突跳一下下一帧邻区把用户 A 挪到 RB 20你的干扰热点也跟着挪。所以做蜂窝小区调度算法研究时不能只看自己小区的用户信道质量就做资源分配决策还得估计你的分配结果会对邻区产生多少干扰。这也是蜂窝仿真平台把多小区放在同一个内存空间里迭代的原因每个 TTI每个小区都做一次调度然后把功率和干扰关系同步给邻区再进入下一个 TTI。3.2 三种基础调度器的性能边界RR、Best CQI、PF几乎所有蜂窝调度研究的起点都是这三种调度器。它们的决策逻辑完全不同性能表现也各有边界。调度器决策逻辑小区总吞吐量边缘用户公平性实现复杂度Round Robin轮询所有用户轮流使用 RB不看信道质量中等。低 SINR 用户也拿到资源拖低平均最高。资源在用户间完全平均最低。只需维护一个循环指针Best CQI最大吞吐量每个 RB 分给信道质量最好的用户最高。频谱资源用在刀刃上最差。边缘用户长期饿死低。只需比较 SINR 找到最大值Proportional Fair比例公平按当前速率 / 历史平均速率的比值排序接近 Best CQI。略微损失几个百分点良好。兼顾速率和公平中。需要维护用户历史速率窗口实际仿真中最常见的一个现象是Best CQI 在小区总吞吐量单项指标上碾压其他两者但把用户吞吐量按从低到高排序后底部 5% 的用户几乎颗粒无收。这在真实蜂窝网络里不可接受因为运营商对边缘用户体验有承诺边缘用户的网络质量常常决定投诉率。Round Robin 的做法看起来公平但它不管用户信道质量把大量 RB 分给了处于小区边缘、SINR 很低甚至没法解调的用户结果是资源浪费。所以比例公平成了默认基线它的数学表达是Priority(j, u) R_inst(u, RB_j) / R_avg(u)其中 R_inst 是用户 u 在 RB j 上的瞬时预估速率来自 CQI 上报R_avg 是用户在历史窗口内的平均速率。这个比值让瞬时速率高、历史平均速率低的用户优先拿资源既照顾了信道好的用户又保证历史积累少的用户不会被饿死。3.3 PF 调度器的实现细节把边缘用户偏置写进优先级函数开源蜂窝仿真平台里的 PF 调度器核心通常就一个函数输入每个用户在每个 RB 上的预估速率和历史平均速率输出优先级矩阵然后按优先级把 RB 分出去。改动点是加一个边缘用户偏置。下面是 PF 调度核心的典型实现% 计算 PF 调度优先级 % 输入 % pref_rate: 用户在当前 RB 上的预估速率由 CQI 对照 MCS 表得到 % avg_rate: 用户截至当前 TTI 的历史平均速率 % edge_bias: 边缘用户偏置因子默认 1大于 1 时抬升边缘用户优先级 % geom: 用户几何因子信号比干扰用于判断是否边缘用户 function priority calc_pf_priority(pref_rate, avg_rate, edge_bias, geom) % 基础 PF 比值 priority pref_rate ./ avg_rate; % 几何因子低于阈值的用户视为边缘用户乘上偏置因子 threshold 10; % 10 dB几何因子低于此值视为边缘用户 edge_users geom threshold; priority(edge_users) priority(edge_users) * edge_bias; end这个偏置因子的作用很直接原来是所有用户按 PF 比值公平竞争加了偏置后边缘用户的优先级凭空乘了一个系数调度器会更愿意把 RB 分给他们。edge_bias 取 1 时和原版 PF 完全一致取 1.5 到 3.0 时边缘用户吞吐量明显抬升代价是中心用户和小区总吞吐量小幅下降。参数里最容易忽略的是 threshold 的取值。几何因子阈值取 10 dB 是经验值但这个值跟场景强相关小区半径大、站点稀疏的环境里边缘用户的几何因子可能普遍低于 5 dB密集城区里边缘用户几何因子可能高达 15 dB 还是能获得不错体验。正确做法是先跑一组基线仿真画出用户几何因子的累计分布函数再根据 CDF 曲线找分位点来确定阈值。把这段代码接进仿真平台时注意调度顺序每个 TTI 开始时要先更新所有用户的 R_avg用滑动窗口或指数平均窗口长度通常取 100 个 TTI 左右。窗口太短调度器变成瞬时速率追踪器丢失公平性窗口太长调度器对信道变化反应迟钝边缘用户的智能调度效果出不来。4. 蜂窝仿真调度对比实验参数怎么设才不会白白跑一周4.1 仿真时长、用户数与随机种子的工程权衡调度算法对比实验最怕的不是跑得慢而是跑完发现参数设置没有统计意义。用户数太少结果受个别人的信道位置影响太大TTI 太短调度器还没进稳态随机种子只有一个算法之间几个百分点的差异根本分不清是真实差距还是运气。我常用的做法是分两步验证。第一步固定一个调度器把 TTI 从 200 加到 2000画吞吐量收敛曲线找到波动小于 2% 的最短 TTI 数。第二步保持这个时长把每小区的用户数从 10 个逐步加到 50 个观察结果是否单调变化。实际项目中每小区 30 个用户、1500 到 3000 个 TTI 是研究级仿真的常见配置。TTI 数超过 3000 后结果精度的提升远小于仿真时间的线性增长性价比很低。随机种子在对比实验里尤其重要。蜂窝仿真里用户位置、信道衰落、流量到达都依赖随机数不同种子下同一个调度器的结果差异可能达到 5% 到 8%。单种子对比两个调度器得出来的谁比谁强极可能是噪声。正确做法是每个调度器至少跑 5 个不同种子最后取平均并报告标准差。4.2 业务模型的选择Full Buffer 不是万能的安全牌蜂窝调度仿真里最常见也最容易偷懒的设置是 Full Buffer——所有用户永远有数据要发。这个模型的好处是专一它把流量因素剥掉让你专心观察资源分配的优劣。但坏处是它过于乐观真实网络里用户流量到达是突发的一个用户可能连续几百个 TTI 只上传小包也可能从视频业务瞬间切到文件上传。在调度算法对比实验中我的建议是先用 Full Buffer 跑出算法之间的理论差距再用一个准静态的 HTTP/FTP 轻载模型做敏感度验证。轻载模型会让用户大部分时间处于没有数据可发的状态这反而能把调度器的行为差异放大——有些调度器在空载时会做很多无意义的 RB 扫描有些调度器会通过缓存管理直接跳过空用户这些都只在非满载场景下暴露出来。仿真平台里业务模型一般是一个独立的模块看着业务包队列长度来决定用户是否有数据在缓冲器里等待发送。切换业务模型后要重点看两个方向业务时延和缓冲区溢出率这两个指标在 Full Buffer 模型下根本不存在。它们虽然不是调度对比的核心指标但会提醒你算法的复杂度是否带来额外的调度延迟。4.3 调度算法对比的核心指标不只总吞吐量跑完仿真后结果文件里往往有两三百个字段但调度算法对比只需要盯住四个指标小区平均吞吐量、边缘用户 5% 分位吞吐量、公平性指数Jains fairness index和频谱效率。这四个指标基本可以把一个调度器的性能画像画清楚。% 假设 cell_tput_matrix 是 [用户数 x 时长] 的吞吐量矩阵 % 取每用户在整个仿真期内的平均吞吐量 user_avg_tput mean(cell_tput_matrix, 2); % 边缘用户吞吐量按从低到高排序后取 5% 分位 edge_tput prctile(user_avg_tput, 5); % Jains 公平性指数越接近 1 表示用户间资源分配越均衡 fairness_index sum(user_avg_tput)^2 / ... (length(user_avg_tput) * sum(user_avg_tput.^2)); % 频谱效率系统总吞吐量除以总带宽单位bit/s/Hz spectral_efficiency sum(user_avg_tput) / system_bandwidth_hz;这段代码建议作为独立的统计脚本不要塞进仿真主流程。原因有两个一是你跑对比实验时会反复重放结果文件独立脚本能省去每次进主循环的等待二是统计口径必须统一所有调度器都用同一个脚本算指标避免在不同地方写统计代码导致口径漂移。prctile取 5% 分位是蜂窝系统性能评估的惯例做法对应 3GPP 里说的边缘用户吞吐量——它关注的不是最差的 1% 个例而是覆盖最差的 5% 用户群。采 1% 分位容易被个别极端信道位置带偏采 10% 分位又把边缘用户群和次边缘混在一起5% 是行业里沉淀出来的经验值。fairness_index的取值范围在 0 到 1 之间值越接近 1说明资源在不同用户间的分配越平均。Round Robin 的公平性指数通常在 0.95 以上Best CQI 经常掉到 0.6 以下PF 居中在 0.8 到 0.9 之间。4.4 蜂窝场景下的干扰协调给调度器前面加一道约束当你在普通 PF 调度器上做完基础对比后蜂窝小区算法真正拉开差距的地方在于是否集成了小区间干扰协调。常见的做法是给调度器加一个频率复用约束把整个带宽划分成几份相邻小区使用不同的子带叫做软频率复用或分数频率复用。在仿真代码里实现起来通常是在调度之前对 RB 可用集合做一次过滤% 干扰协调模块根据小区 ID 和用户位置决定可用 RB 集合 % 中心用户可用全部 RB边缘用户只能用本小区分配到的子带 function rbs_allowed icic_permit(cell_id, user_geometry, all_rbs) % 低几何因子的用户视为边缘用户限制其 RB 集合 edge_rb_index mod(cell_id, 3) 1; % 三色复用 if user_geometry 10 % 边缘用户 rbs_allowed all_rbs(mod(all_rbs, 3) mod(edge_rb_index, 3)); else % 中心用户全部可用 rbs_allowed all_rbs; end end把这段约束放在调度器计算优先级之前调度器只能在过滤后的 RB 集合上做分配。边缘用户的频域选择立刻变小但换来的是邻区边缘用户在同一个子带上不再互相干扰。仿真结果通常表现为边缘用户 5% 分位吞吐量继续抬升而小区总吞吐量开始下降因为频域约束牺牲了部分频率选择性调度增益。这个模块是蜂窝调度算法向高层演进的关键一步后面再叠加功率控制和多小区协作调度时都是在这个过滤逻辑上扩展。建议把icic_permit的输出在每个 TTI 存一次日志方便后续排查调度异常。5. 避坑蜂窝调度仿真没有后悔药这五个坑我踩了个遍5.1 边缘用户吞吐量一直为零不是因为调度器而是边界效应现象跑了 7 个小区中心小区用户吞吐量正常外圈小区的边缘用户吞吐量长期为零。第一反应怀疑调度器代码有问题反复查配置也没有错。原因蜂窝仿真的边界没有做 wrap-around环绕处理。外圈小区只受到来自内圈的干扰而它自己对外圈的干扰没有被建模导致外圈小区的 SINR 虚高或失真边缘用户被极度边缘化。7 个小区是最容易踩这个坑的配置因为只有一环邻居边界效应尤其明显。解决要么开启仿真平台的 wrap-around 选项把边界小区首尾相连模拟无限蜂窝拓扑要么只统计中心小区的数据外圈小区信号完全当作干扰源。对比调度算法时建议固定用中心小区统计同时开启 wrap-around。5.2 换调度器之后总吞吐量不升反降是 CQI 上报周期没跟上现象把调度器从 Best CQI 换成 PF 后理论推导说总吞吐量只会小幅下降但仿真结果掉了 30%。原因调度器更新用户速率的周期和 CQI 上报周期不匹配。Best CQI 只要瞬时信道状态准确就能工作得很好PF 依赖历史平均速率做归一化如果 CQI 上报周期太长调度器瞬时速率信息失真PF 的分子分母都在用旧数据算用户优先级排序完全偏离实际信道状态。解决检查参数文件中 CQI 上报周期的设置。让 CQI 上报周期等于或小于调度器的决策周期通常设为 10 个 TTI 以内。同时确认用户历史平均速率的平滑窗口长度与 CQI 上报周期在同个量级二者相差超过 10 倍时PF 调度会出现明显的优先级抖动。5.3 改了调度代码仿真结果却一模一样缓存和预编译在作怪现象在调度器函数里加了一行打印或者改了一个加权因子重新跑仿真结果和之前完全一致连输出文件的 MD5 都一样。原因MATLAB 代码改了但没保存或仿真主脚本用了一个已经打包编译好的 .p 文件预编译加密文件。很多从课程流出的仿真包里部分核心函数是以 .p 后缀存在的你编辑同名 .m 文件根本不会生效。解决在 MATLAB 里用which scheduler_function_name查一下函数实际加载的路径看是不是指向 .p 文件。如果是需要把 .p 文件移走或改扩展名确保同名 .m 文件被加载。另外检查代码编辑器有没有真正保存MATLAB 的编辑器在未保存状态下运行脚本时偶尔会有旧版本缓存。5.4 每次跑仿真结果都在变复现实验报告变成一场赌博现象同一个参数文件同一台电脑连跑三次三次结果都不一样而且差异幅度超过 5%没法判断算法改进是否有效。原因随机种子没有固定。用户位置初始化、信道衰落系数、业务到达时间全部依赖随机数默认种子按当前时间生成每次仿真都是全新场景。解决在参数设置里显式指定随机种子setPARAM.seed 42这样固定下来。对比实验时每个配置至少 5 个种子记录每个种子的结果用均值和标准差做对比。标准差超过均值 10% 时说明仿真时长不够或用户数太少先加时长而不是换算法。5.5 仿真跑到一半崩了路径里的中文和空格是元凶现象第一次跑 200 TTI 正常把仿真时长调到 2000 后中途报错说找不到某个数据文件但文件明明就在工作目录里。原因仿真时长增加后触发结果保存模块这段代码可能是用旧版 MATLAB 写的对路径字符串做了拼接处理。只要工作目录路径里有中文、空格或特殊符号路径拼接就会断成两截。200 TTI 时不触发保存所以没问题时间一长问题就暴露了。解决把整个仿真工程移动到纯英文无空格的路径下比如/home/user/workspace/lte_sim并在 MATLAB 里用cd切到该目录后再跑。另外检查saveas、dlmwrite这类输出函数手动拼接输出路径一定用fullfile而不是字符串加号。6. 让调度对比结果可复现从 5 个随机种子到 CDF 曲线调度算法改进做完之后光有均值对比还不够。审稿人、技术评审、甚至你下一周的自己都会问同一个问题这个提升是稳定的还是某次随机场景撞出来的我的做法是建立一套固定的验证流程每次出结果前先过这一遍。第一步是稳定性检查。每个调度器配 5 个不同随机种子跑 5 次统计结果的相对标准误标准差除以均值。如果相对标准误超过 10%先把仿真时长往上加而不是急着下结论。第二步是画用户吞吐量的 CDF 曲线把对比算法的曲线画在一张图里重点看 5% 到 50% 这段区间是整体右移还是只在局部交叉。整体右移说明算法在所有用户层面都有提升曲线交叉说明有用户变好也有用户变差只是均值碰巧好看。% 多种子稳定性验证 N_seeds 5; for r 1:N_seeds setPARAM.seed 100 r; res(r) LTE_sim_main(setPARAM); end % 用户吞吐量按种子聚合后取均值再计算标准误 user_tput_matrix vertcat(res.user_avg_tput); rel_std_err std(user_tput_matrix) / mean(user_tput_matrix); % 这个值超过 10% 时优先加长仿真时长第三步是输出三步走的结论总吞吐量差多少、边缘用户 5% 分位差多少、公平性指数差多少。这三个数字齐全调度算法的性能画像才是完整的。我现在每次对调度器参数做改动都会先把结果文件名带上参数摘要和随机种子号别等三天后发现两个结果文件分不清哪个是哪个。蜂窝调度仿真这个方向的坑大部分不是算法本身难而是你被仿真平台里的隐藏状态坑了一轮又一轮。把调试路径固定下来后剩下的工作就是大量参数扫描和结果验证。希望帮到你。本文还有配套的精品资源点击获取