1. 多用户场景从单用户思维到系统级思维的转变做5G网络仿真的人刚开始最容易踩的坑就是把多用户场景当成单用户场景的简单重复。我有段时间跑仿真每次只模拟一个用户信道质量拉满资源随便分跑出来的吞吐量数据漂亮得很。结果一到多用户场景数据掉得惨不忍睹调度器频繁切换用户间互相抢资源延迟和吞吐量双双失控。那时候我才意识到无线网络仿真的难点从来不在“信号怎么传”而在“资源怎么分”。所谓多用户场景是指在一个仿真环境中同时存在多个终端用户这些用户共享同一套无线接入网络资源包括时频资源块、功率、天线端口、回传带宽等等。在5G网络仿真里多用户场景不是简单地把用户数目从1改成10它涉及调度算法设计、干扰建模、资源分配策略、业务模型差异化、移动性管理等一整套联动机制。任何一个环节没有建模到位最终跑出来的统计指标都会失真。这个系列博客我已经写到了第17篇前16篇主要覆盖了从信道建模、帧结构配置、波束管理到毫米波传播特性等相对基础的内容。到了多用户场景这一篇实际上是从“链路级仿真”向“系统级仿真”跨越的分水岭。如果你之前一直在做单用户链路仿真这篇内容会帮你把视角往上拉一个层次理解真实网络环境下系统容量和用户体验之间的博弈。这篇文章适合正在做5G网络仿真研究的在校学生、刚进入通信算法岗位的工程师以及准备用仿真数据支撑论文或项目报告的从业者。我会从多用户场景的建模思路讲起拆解核心关键点然后用可复现的实操流程带你跑通一个典型的多用户仿真案例最后整理我认为最值得收藏的排坑经验。2. 多用户场景仿真的设计思路先建模再仿真2.1 多用户场景到底在仿真什么如果要用一句话概括多用户场景仿真的本质那就是在资源受限的前提下如何让多个用户公平且高效地共享无线信道。这里的“资源受限”体现在三个层面缺一不可。第一是时频资源受限。5G使用OFDM正交频分复用技术时域上分为多个时隙slot频域上分为多个子载波时域和频域交叉形成一个资源块网格resource grid。每个资源块RBResource Block是调度的最小单位而系统总的资源块数量是固定的——比如100 MHz带宽在30 kHz子载波间隔下只有273个资源块。用户多了以后每个用户能分到的RB数量必然下降这就产生了资源竞争的根源。第二是功率资源受限。基站的总发射功率是固定的典型宏基站是40W到80W对应46 dBm到49 dBm。功率分配给哪个用户、给多少直接影响该用户的信噪比。多用户场景下不能简单地把功率均分因为靠近基站的用户和小区边缘用户的信道增益差距可能达到20 dB以上均分功率对边缘用户是非常不公平的。第三是干扰环境复杂化。多用户同时传输用户间干扰不仅来自相邻小区同一小区内如果使用了空间复用不同用户的数据流之间也会产生干扰。在TDD制式下还有交叉时隙干扰。这些干扰叠加在一起使得每个用户的SINR信干噪比都比单用户场景下明显恶化。仿真中如果忽略了干扰建模结果会过于乐观这在业界被称为“乐观偏差”。2.2 系统级仿真与链路级仿真的本质差异很多刚开始接触5G网络仿真的朋友会混淆链路级仿真和系统级仿真。链路级仿真关注的是“一个链路在给定信道条件下的误码率、吞吐量”它把物理层的调制编码、信道估计、均衡等细节建模得非常精细仿真步长甚至到采样级别。系统级仿真则把视角放大关注“整个网络中有多个用户时系统总吞吐量、用户公平性、切换性能等整体指标”它不需要对物理层做逐比特的精细建模而是用链路级仿真预先算好的“SINR到吞吐量映射表”来加速计算。我自己的经验是多用户场景仿真必须建立在系统级仿真框架上。如果你试图在一个纯链路级仿真器里强行塞入几十个用户计算复杂度会指数级上升跑一次仿真可能要好几天而且大量物理层细节对最终的调度决策没有直接帮助属于浪费算力。业界成熟的方案是采用“抽象建模”的思路物理层的影响通过MCS调制编码方案查表来折算系统层则聚焦于调度、资源分配和干扰协调等核心逻辑。这里有一个重要的设计原则叫做“时间尺度分离”。物理层的信道变化发生在毫秒甚至微秒级而调度决策通常发生在毫秒级的TTI传输时间间隔粒度用户移动和业务到达则发生在秒级。在仿真设计中要将不同时间尺度的事件分开处理避免在一个循环里同时处理所有事件否则代码会变得极度低效且难以调试。2.3 多用户场景的性能评价指标选型设计多用户场景仿真第一件事不是写代码而是明确用什么指标来评价系统性能。不同指标反映不同维度的权衡我建议至少同时跟踪以下三类指标。系统吞吐量system throughput是最直观的指标单位是Mbps或Gbps反映整个小区或者整个网络在一段时间内成功传输的数据总量。但吞吐量高不代表用户体验好如果系统只服务于信号质量好的近点用户边缘用户可能完全得不到服务此时吞吐量指标会虚高。用户公平性指标通常用Jain公平性指数来度量公式是所有用户吞吐量之和的平方除以用户数乘以吞吐量平方和。Jain指数取值范围是0到1越接近1表示越公平0.8以上可以认为公平性可接受低于0.6就说明调度策略有明显偏向性。时延指标在5G的URLLC超可靠低时延通信场景下尤其重要通常统计用户面时延的累积分布函数关注的是5百分位、50百分位和95百分位值。在多用户场景下时延的尾部表现往往比平均值更能反映问题——如果95百分位时延突然飙高说明某些用户在调度中被长期饿死了。还有一个容易被忽略的指标是切换成功率handover success rate和切换时延。多用户场景伴随用户移动时切换事件会频繁发生切换过程中的数据中断直接影响用户体验。在仿真中切换失败往往表现为用户吞吐量出现长时间掉零排查时需要把切换日志和调度日志对应起来看。3. 多用户场景仿真的核心技术点拆解3.1 用户生成模型位置、数量和移动性多用户场景仿真中用户的生成方式直接决定了仿真结果是否可信。最常规的做法是泊松点过程PPPPoisson Point Process布点用户在小区覆盖范围内随机分布用户之间的位置相互独立。这种模型数学上优雅仿真上也容易实现真实网络中的用户在宏观尺度上确实近似服从随机分布。但纯PPP模型忽略了用户的空间聚集性。真实的城市环境中用户在办公楼、商场、地铁站等热点区域明显聚集。如果仿真场景是城市宏站覆盖建议采用泊松簇过程PCPPoisson Cluster Process来建模热点区域即先按照PPP生成若干簇中心再在每个簇中心周围生成聚集的用户。我在一个密集城区场景中对比过这两种模型相同用户总数下PCP模型的小区边缘用户占比更高系统平均吞吐量下降了大概15%但公平性指标反而提升了——因为边缘用户增多后调度器被迫更加公平地分配资源。用户移动模型同样值得仔细选择。静止用户适合用随机游走模型模拟小幅位置抖动车辆用户要使用道路约束模型不能让车在建筑物上跑行人用户我推荐随机路径点模型速度设置为3km/h左右转向概率调高一些。移动模型最大的影响在于信道的时间相关性——用户移动越快信道的相干时间越短调度器面对的信道反馈越“过时”资源分配的准确性就越差。用户数目是个需要根据仿真目标反复斟酌的参数。单小区场景我个人经验是用户数从5个到50个之间能比较完整地观察到从资源充裕到资源紧张的全过程。低于5个用户调度器几乎没有竞争压力体现不出算法的差异高于50个用户资源块严重不足所有算法都趋向于轮询同样难以区分优劣。如果做多小区场景建议每小区15到30个用户起步这样小区间干扰的效应才能充分体现。3.2 调度器设计多用户场景的核心引擎调度算法是基站MAC层的核心模块也是多用户仿真中最能体现“算法设计”含量的部分。3GPP标准本身不规定具体的调度算法只定义了调度结果需要满足的控制信令格式这给算法研究留下了很大的空间。最简单的调度算法是轮询调度RRRound Robin。系统按顺序把资源块轮流分配给每个用户不考虑任何信道条件差异。RR的优点是极端公平每个用户获得相同的资源份额但缺点也很明显——信道质量差的用户分到资源块也传不出多少数据系统总吞吐量被拉低。在仿真中RR常被用作公平性对比的基准线。最大载干比调度Max-SINR走向另一个极端每次调度都把资源块分配给当前SINR最高的用户能够最大化系统总吞吐量。但这种贪婪策略会让边缘用户几乎没有机会获得资源公平性极差。在仿真中Max-SINR用来标定吞吐量上界。在实际系统中最常用的是比例公平调度PFProportional Fair。PF的核心思想是对每个用户计算一个优先级值等于当前可达到的瞬时速率除以该用户的历史平均速率然后选择优先级最高的用户进行调度。这个公式的精妙之处在于它同时考虑了信道条件和公平性——信道好的用户更容易被调度但历史速率高的用户优先级会自然下降给其他用户创造机会。我在仿真中实现PF的时候重点调的是历史平均速率的遗忘因子遗忘因子太大公平性滞后太小则调度过于短视饿死边缘用户。经验值一般是0.001到0.01之间对应100到1000个TTI的滑动窗口。除了这三种基础调度器现代5G系统还会引入比例公平的变种比如考虑时延约束的调度算法、协同调度多用户的MU-MIMO配对算法等。多用户配对的核心是在调度时选择信道正交性好的用户组合同时服务多个用户利用空间维度提高频谱效率。3.3 多天线与波束赋形空间维度上的资源复用5G NR最核心的物理层革新之一就是大规模天线阵列Massive MIMO。在4G时代基站通常是8天线或16天线而5G普遍配置了32、64甚至128天线阵元。天线数增多的直接后果是波束变窄能量更加集中。在多用户场景中基站可以用多个波束同时服务多个用户这叫多用户MIMOMU-MIMO。在仿真中建模MU-MIMO需要注意三个关键参数。第一是天线阵列配置常见配置是8行8列双极化共128个天线阵元仿真中要明确阵元间距通常为半个波长这决定了波束的方向图第二是信道估计误差理论上的完美信道状态信息CSI在仿真中往往高估MU-MIMO的增益建议给信道估计结果加上一定的误差误差大小可以设置为接收信噪比的函数第三是用户配对准则通常采用基于最大信道相关性最小化或者遍历容量最大化的准则。还有一个非常影响结果准确性的细节是码本的选择。基于码本的波束赋形基站和用户之间需要交互预编码矩阵指示PMIPMI的选择粒度直接关系到波束成形的精度。如果码本粒度太粗波束方向对准不精确用户间干扰增加多用户MIMO的增益会被严重削减。3GPP在Rel-15中定义了两级码本结构type I和type IItype II码本的波束粒度更细增益更高但反馈开销也更大仿真中需要根据系统开销预算来权衡。波束管理在高频段尤其关键。毫米波频段的路损随距离增加非常迅速基站必须通过波束扫描在初始接入阶段找到每个用户的最佳波束方向并在用户移动过程中持续进行波束追踪和切换。仿真中一个常被忽略的细节是波束切换的时延——真实的波束切换需要经历测量、上报、判决和执行四个阶段总时延在毫秒量级。如果仿真中把波束切换视为瞬时完成会高估用户在波束边界区域的体验。3.4 干扰协调多小区场景的胜负手当仿真场景扩展到多小区时干扰协调就成了不可回避的问题。相邻小区的用户在小区边缘区域会受到强烈的邻区干扰这种干扰在频率复用因子为1的5G网络中尤其突出——因为所有小区共用全部频谱资源。经典的ICIC方案是部分频率复用FFRFractional Frequency Reuse。核心思想是把小区中心的用户可以复用全部频谱而小区边缘用户只使用全部频谱中的一部分相邻小区之间在边缘区域使用正交的频段避免边缘用户互相干扰。这种方案的实现成本低但频谱效率会有一定损失因为边缘区域的频谱无法全网复用。更先进的方案是协调波束赋形CoMPCoordinated Multi-Point多个基站协同计算预编码向量使得信号在目标用户处建设性叠加的同时在干扰用户处进行零陷。CoMP在仿真中建模比较复杂因为它需要使用联合信道信息进行矩阵分解计算对仿真器的计算资源要求很高。在系统级仿真中有一种简化的CoMP建模方法只考虑协作集中的小区间交换调度信息和信道状态信息然后用加权SINR公式来近似协作增益效果不错而且计算速度比完整CoMP模型快一个数量级。对做仿真的人来说一个建议是先把无协作的干扰模型跑通观察小区边缘用户吞吐量的分布然后逐步加上ICIC或CoMP对比性能提升。这也是论文中比较常见的分析框架。我自己的经验是边缘用户吞吐量的5百分位值是最能直观反映干扰协调效果指标比平均值更有说服力。4. 实操流程用仿真工具搭建一个多用户下行场景4.1 仿真工具选型与评估市面上的5G仿真工具大致能分成三类。第一类是全协议栈仿真器比如NS-3的5G-LENA模块、OMNeT的Simu5G框架它们能模拟从物理层到应用层的完整协议栈适合做端到端性能评估第二类是系统级抽象仿真器比如MATLAB 5G Toolbox加上自定义的调度算法适合聚焦某个关键技术做算法级的性能对比第三类是学术界通用的参考仿真器比如维也纳大学的Vienna 5G System Level Simulator它是开源的MATLAB代码在网上很容易找到适合作为研究基线进行二次开发。如果你的目的是快速验证一个调度算法的想法我推荐用MATLAB 5G Toolbox加自定义调度器的方式。MATLAB提供了完整的NR物理层收发链路、信道模型和资源网格管理函数你可以把精力集中在MAC调度逻辑上。如果你的目的是评估一个完整网络架构下的多用户性能比如切换、回传、端到端时延那么NS-3的5G-LENA模块更合适毕竟MATLAB仿真器对传输层以上协议的支持相对薄弱。我在这里用MATLAB 5G Toolbox来演示多用户下行场景的搭建因为它的API设计和信道模型更贴近3GPP规范对新手来说不容易犯错。整个流程包括配置网络拓扑、创建用户、配置信道模型、实现PF调度器、运行TTI循环、收集统计数据这几个环节。4.2 网络拓扑与基本参数配置下行多用户场景的仿真配置核心任务是定义一个基站、若干个用户以及它们之间的信道链路。以典型的3GPP TR 38.901 UMa城区宏站场景为例基站高度25米用户高度1.5米载波频率3.5 GHz带宽100 MHz子载波间隔30 kHz。在代码层面首先用nrCarrierConfig来定义载波参数carrier nrCarrierConfig; carrier.NSizeGrid 273; % 100MHz带宽下30kHz子载波间隔对应273个RB carrier.SubcarrierSpacing 30; % 子载波间隔kHz carrier.NSlot 0; % 起始时隙号 carrier.NFrame 0; % 起始帧号接下来定义基站和用户的位置。基站坐标设为(0, 0, 25)用户位置用PPP模型在半径500米的范围内随机生成。这里我用了一个固定随机数种子保证每次跑仿真结果可复现这是仿真中非常重要的习惯。rng(42); % 固定随机种子确保实验结果可复现 numUsers 10; angle 2 * pi * rand(numUsers, 1); radius 500 * sqrt(rand(numUsers, 1)); % sqrt保证面积均匀分布 userPositions [radius .* cos(angle), radius .* sin(angle), ones(numUsers, 1) * 1.5];这里使用sqrt(rand)而不是rand是为了让用户在圆形区域内均匀分布。如果直接用随机半径用户会更多地聚集在圆心附近导致仿真结果偏向“近点用户”做性能评估时会有偏差。这个细节值得记下来真的很影响最终结果。然后是信道配置。MATLAB 5G Toolbox中的nrTDLChannel可以用来配置抽头延迟线信道模型但TDL模型适合链路级仿真。系统级仿真更适合使用nrCDLChannel它支持多天线信道矩阵建模并且可以配置空间一致性参数。CDL模型Clustered Delay Line是3GPP定义的标准空间信道模型其中CDL-D和CDL-E分别对应非视距和视距场景。对于UMa多用户下行建议使用CDL-D并设置用户间的信道一致性参数使得相邻用户间的信道存在一定的相关性这更接近真实场景。4.3 比例公平调度器的代码实现调度器是多用户场景中最核心的代码模块。我实现一个基于PF算法的下行调度器每个时隙对所有用户计算PF优先级然后按优先级顺序分配资源块。% 假设sinrMatrix维度为 [numUsers, numRBs]表示每个用户在每个RB上的SINR % avgRate维度为 [numUsers, 1]表示每个用户的历史平均速率 % pfWindow为遗忘因子对应的窗口长度TTI数 pfLambda 1 / (200); % 遗忘因子窗口长度200个TTI avgRate zeros(numUsers, 1); scheduleResult zeros(numRBs, 1); for tti 1:numTTI % 根据SINR计算每个RB上用户可达速率简化版用香农公式 instantRate log2(1 db2pow(sinrMatrix)) * numRBs / 1e3; % 单位Mbps % 计算PF权重 pfMetric instantRate ./ max(avgRate, 1e-6); % 逐RB调度找到该RB上PF权重最大的用户 for rb 1:numRBs [~, scheduledUser] max(pfMetric(:, rb)); scheduleResult(rb) scheduledUser; end % 计算当前TTI每个用户的实际速率 currentRate zeros(numUsers, 1); for rb 1:numRBs user scheduleResult(rb); currentRate(user) currentRate(user) instantRate(user, rb); end % 更新历史平均速率指数加权移动平均 avgRate (1 - pfLambda) * avgRate pfLambda * currentRate; end这段代码有几个实现上的关键点。第一用户某个RB上的SINR如果过低该RB的log2结果可能为负需要做下限保护防止负速率进入统计。第二历史平均速率的初始化不能为0否则首个TTI里所有用户的PF权重都趋近无限大调度结果没有区分度。第三逐RB调度的计算复杂度是O(numRBs * numUsers)当RB数和用户数同时增大时计算量增长很快实测中50个用户、273个RB的场景单次TTI调度时间大约在2到3毫秒跑1000个TTI需要几秒钟可以接受。这是我经过多次迭代后才得到的写法。最初我用的是“先按PF权重排序再按顺序分配RB”的方式结果发现排序方案在高负载时会导致资源分配不均——因为一个用户被分配到一个RB之后剩余的PF权重没有及时更新导致这个用户在后续RB分配中仍然占据排序高位又获得了大量RB。后来改成逐RB实时计算权重的方案公平性指标提升了不少。4.4 业务模型与仿真循环多用户场景中的业务模型决定了每个用户请求数据的模式。在仿真中常用的业务模型有三种满缓冲模型Full Buffer、FTP模型和视频流模型。满缓冲模型假设每个用户始终有无限多的数据待传输调度器只需要考虑信道条件和公平性这个模型简化了仿真适合作为基线场景。但是真实网络中用户不是一直在满载荷传输的所以需要用更贴近实际的业务模型来验证算法在流量波动下的表现。我在这篇实操中采用混合业务模型70%的用户用满缓冲模型模拟持续下载业务30%的用户用FTP模型模拟突发短报文业务FTP的数据包大小设为512KB平均到达间隔服从均值为1秒的指数分布。混合业务模型能更真实地反映调度器在服务混合流量时的资源分配策略——满缓冲用户会占用大量资源突发用户需要及时响应如何平衡这两类需求是多用户场景的核心挑战。仿真主循环的时间粒度设为1个时隙slot在30kHz子载波间隔下对应0.5毫秒。每个时隙内需要执行的操作依次是生成或更新用户业务量、根据信道更新每个用户的SINR矩阵、运行调度算法分配RB、更新用户队列长度和速率统计、记录日志。这里要特别注意业务量生成和调度的先后顺序必须先生成新到达的业务包再调度否则新到达的包会多等一个时隙时延指标会系统性偏高。信道更新频率需要谨慎处理。如果每个时隙都重新生成信道系数仿真能捕捉到信道快速衰落的变化但计算量非常高。如果每隔太长周期才更新一次信道调度器决策所依赖的SINR信息是过时的会降低调度准确性。我在实践中使用两个信道更新周期大尺度衰落包括路径损耗和阴影衰落每100个时隙更新一次小尺度衰落包括快衰每个时隙更新。这种分尺度更新的做法兼顾了精确度和计算效率是我强烈推荐的一种工程化取舍。4.5 数据统计与可视化仿真跑完以后最关键的一步是把原始日志整理成有说服力的统计结果。我通常会输出四类数据所有用户在仿真周期内每100个TTI的平均吞吐量、用户吞吐量的累积分布函数CDF曲线、Jain公平性指数随时间的演化、以及用户面的时延直方图。吞吐量的CDF曲线是最有价值的可视化方式。它能够直观地展示系统在“边缘用户”和“中心用户”之间的性能分布差异。比较不同方案时不要把多条CDF曲线叠加在一张图上就完事建议再标出5百分位值和50百分位值的具体数值这两个值分别对应边缘用户体验和中等用户体验是论文或报告中最重要的两个数。Jain公平性指数的计算要放在滑动窗口上做而不是统计整个仿真周期的平均值。整个周期的整体公平性指数掩盖了算法在不同时段的动态调整过程。我习惯每100个TTI计算一次公平性指数输出一条随时间的演化曲线。你会很直观地看到Max-SINR调度器在一开始也许还能保持一定的公平性但随时间推移指数迅速下降而PF调度器的指数会稳定在一个较高的水平。代码中统计模块可以用一个结构体简化输出stats.throughputPerUser userTotalRate / totalTTIs * 1000; % 转换为Mbps stats.jainIndex (sum(stats.throughputPerUser)^2) / ... (length(stats.throughputPerUser) * sum(stats.throughputPerUser.^2));5. 多用户仿真常见问题与排障实录5.1 调度器空转用户永远等不到资源一个很典型的问题是仿真运行到某些TTI时某个用户始终没有被调度器选中其队列积压越来越严重时延指标暴涨。排查这类问题的第一步是确认这个用户的SINR是不是异常低如果SINR低于-5 dB该用户在所有RB上的最快速率都趋近于0调度器按照PF公式计算时会发现给这个用户分配RB也传不了多少数据自然倾向于不调度它。解决思路有两类。一类是修改调度器增加最小调度频次约束例如在每个调度周期内保证每个用户至少被调度一次另一类是优化系统通过功率控制或干扰协调改善边缘用户的SINR。仿真中做算法对比时应该将这两种方案都实现分别观察吞吐量和公平性指标的变化。我发现很多论文只改调度算法不优化SINR分布结论就会有偏差。5.2 多用户MIMO的信道相关性陷阱在多用户MIMO仿真中一个常见的陷阱是为了简化建模直接为每个用户独立生成信道矩阵忽略了用户间信道的空间相关性。这会对MU-MIMO的用户配对结果产生严重影响——在真实系统中如果两个用户的位置非常接近它们的信道方向大概率是高度相似的基站无法通过空间区分这两个用户MU-MIMO的配对增益会大打折扣。如果仿真中忽略了这种相关性配对成功率会异常高系统吞吐量虚高。解决办法是配置信道模型时启用空间一致性参数。在MATLAB的nrCDLChannel中这个参数被叫做SpatialCorrelation对同一个小区内的用户设置一个相关距离内的用户信道具有较高的空间相关性。我之前用独立信道跑出来的数据MU-MIMO增益是30%启用空间一致性建模后增益降到了12%左右这个数字更接近实测报告的统计结果。5.3 仿真时间过长从参数层面做减法多用户场景仿真时间失控是最常见的工程问题。当用户数超过30个、RB数超过200个、仿真时长超过数千个TTI时MATLAB仿真脚本的运行时间可能出现指数级增长。我调试过的最离谱的一次单次仿真跑了将近6个小时后来定位到是统计日志模块在循环内部反复写文件磁盘IO成了瓶颈。先检查代码中是否有在循环内部做顺序数组拼接的操作。在MATLAB里循环内a[a,new_value]这种操作会导致数组反复重新分配内存性能极差。解决办法是预先分配数组空间在仿真开始前先初始化一个numTTI×numUsers的矩阵在循环内部只做赋值操作。仅此一项优化我的仿真速度提升了约5倍。其次是批量处理赋值。对每个用户单独循环计算信道矩阵的代码尽量改成矩阵运算。MATLAB的向量化优化非常明显同样的信道更新计算向量化版本比普通for循环版本快10倍以上。这里的前提是理解MATLAB的运算原理用矩阵思维替代循环思维。最后是仿真时长的合理配置。如果只是对调度算法做对比分析不需要把仿真跑到几万TTI。我建议先跑500个TTI做小规模预验证确认没有bug后再跑5000到10000个TTI做正式实验。5000个TTI在30kHz子载波间隔下对应2.5秒模拟时间对于观察调度器的稳态行为已经足够了。5.4 仿真结果无法复现“结果可复现”是做科学研究的基本要求但在多用户场景仿真中经常被忽略。问题通常出在随机性管理上——随机用户位置、随机信道、随机业务到达这些随机事件都需要有独立的随机数流。MATLAB的rng函数控制的是全局随机数生成器但如果你的代码中有并行计算工具箱parfor每个worker进程会有独立的随机数流这时需要在每个worker中单独设置rng种子。另一个容易忽略的地方是不同模块的随机数使用顺序会改变全局随机数流的状态。比如你调整了业务模型的代码即使不涉及位置和信道用户位置和信道系数也会因为随机数序列被消费的顺序变化而改变。解决方法是使用RandStream对象为位置、信道、业务三个模块分别创建独立的随机数流这样任意一个模块的代码改动不会影响其他模块的结果。6. 多用户场景仿真的一些经验分享做多用户场景仿真时间久了我有一个很深的感受仿真的精度不是越高越好而是越“够用”越好。很多人在细节上纠结太久比如信道的快衰模型要不要精确到每个路径分量CSI反馈要不要量化到每个比特这些细节确实重要但如果它们不是你的研究重点过高的精度只会拖慢仿真速度、增加排障难度。把精力集中在调度算法、资源分配、干扰协调这些核心问题的建模上才是多用户场景仿真最值得投入的方向。我个人在做多用户仿真时通常遵循“三步走”的方法第一步用最简化的场景跑通流程——5个用户、满缓冲业务、RR调度器确认代码能运行、指标能统计第二步把场景逐步复杂化——增加用户数、更换业务模型、实现PF调度器每加一个复杂度就跑一轮完整的验证测试确保前一步的结果没有被破坏第三步才进入正式的实验配置跑对比方案、生成统计图表。这个过程看起来慢实际上是最快的方法因为多用户场景的调试复杂度是指数级增长的不做好前两步直接跳进完整场景出了bug定位会非常痛苦。关于多用户场景我最后还想分享一个小技巧在仿真中引入“快照”机制。每隔一定TTI数量将当前所有用户的位置、信道参数、调度统计信息保存到一个文件中。当你发现某个异常结果时可以直接从快照恢复现场逐TTI地回放调度过程定位问题发生的确切时刻。没有快照机制时我排一个随机出现的bug经常要重跑好几次仿真有了快照之后大多数问题只需要一次复现就能定位。这个技巧当初是为了调试一个偶尔出现的负吞吐量问题而想出来的后来成了我所有仿真项目的标配。