多用户场景只要一加进5G网络仿真整个工作性质就变了之前搞单用户链路仿真调完信道模型就算完事现在做无线网络仿真里的多用户场景等于同时协调十几个甚至上百个用户抢频谱、抢功率、抢时隙各种调度、干扰、移动性问题一起涌过来。这篇博文就围绕5G网络仿真里的多用户场景展开从建模思路、工具选型到实操参数一步步讲清楚适合正在跑系统级仿真、或者刚把课题从物理层算法转向网络层协议的同学参考。先说结论多用户场景仿真最大的坑不是“用户多”而是“用户一多原先被忽略的因素全部变显著”。单用户时你根本感知不到的调度延迟、反馈开销、用户间干扰在几十个用户同时在线时直接决定仿真能不能收敛、结果可不可信。所以这篇的主要内容就是把这些因素挨个拆开讲清楚每个环节为什么要这样建模给出可以直接落地的参数配置和排查方法。1. 多用户场景为什么是5G仿真里的“硬骨头”1.1 单用户仿真看着简单多用户才接近真实网络单用户链路仿真本质就是“点对点通信”一个发射机、一个接收机、一条信道所有问题都集中在波形、编码、信道估计这些物理层细节上。这种仿真跑起来快、指标清晰适合验证某个调制方案或编码算法。但真实的5G网络从来不是这样运作的一个小区下面同时挂着几十上百个活跃用户基站侧的资源块有限必须决定“先给谁发、发多少、用什么调制方式”这就是无线网络仿真和链路仿真最根本的思维差异。我刚接触系统级仿真时犯过一个典型错误把单用户模型直接复制成多用户结果发现每个用户的吞吐量直线下降但下降幅度跟用户数完全不成比例。原因很直接——多用户场景下资源要切分控制信道要占用反馈要上报用户之间还存在相互干扰。这些开销在单用户仿真里压根不存在一旦引入多用户场景就全部浮现出来就好像你在KTV包间一个人唱得很爽结果突然把你挪到大堂里背景噪声、别人抢麦、音响分区全来了。所以在开始配置仿真器之前必须建立一个基本认知多用户场景仿真的核心不是把“一个用户”复制成“N个用户”而是把“资源竞争”“干扰耦合”“移动变化”这三个因素建模出来。这也是这个场景最花时间的地方。1.2 多用户场景必须建模的四个维度在5G网络仿真里搭多用户场景我习惯先从四个维度梳理需求缺一个后面都会出问题。第一个是业务维度。5G三大场景eMBB、uRLLC、mMTC业务特征完全不同eMBB是大流量高吞吐典型代表是视频流和文件下载数据包大、持续时间长uRLLC注重极低时延和高可靠包很小但必须优先调度mMTC是大规模连接但每个设备数据量极低比如抄表类传感器。仿真多用户场景时这几种业务往往共存你不可能让所有用户都跑FTP下载否则仿出来的只是“多点复制版的单用户”不是真实网络。第二个是空间维度。用户的物理分布直接决定路损、阴影衰落和干扰水平。用户聚在小区中心路损小但是互相之间调度竞争严重用户散布在小区边缘干扰情况又完全不同。实际仿真中常用的分布有均匀随机分布、热点聚集分布、街区分布几种扰动因素包括用户密度和用户距离基站的最小/最大距离。第三个是时间维度。用户不会永远钉在某一处也不会一直有数据要传。有的仿真需要用户到达/离开模型有的需要业务按会话随机起止移动用户的接入与切换更是时间维度的关键事件。如果所有用户从头到尾静止且一直满缓冲下载那仿的就是个理想化的上界对边缘用户调度和切换算法的验证价值非常有限。第四个是干扰维度。这个维度在多用户场景里比前三个更容易被忽略。对同一小区用户大家共用同一段频谱靠资源的正交性避免相互干扰但邻区用户或者相邻波束之间的干扰是避免不了的。多用户仿真如果开着“完美正交”的假设干扰为零SINR算出来会虚高最终吞吐量指标几乎一定偏大。这也是后面第4章实操部分我一直强调SINR建模不能省的原因。这四维度建议在写仿真脚本前先用一个表格列清楚每项具体是什么模型、什么参数、什么取值范围后面遇到结果异常时排查起来会快得多。2. 工具选型跑多用户场景的仿真平台怎么挑2.1 主流仿真工具横向对比市面能跑5G多用户场景的仿真平台不少但各自侧重点差异很大。我用过的几款简单列个对比供参考工具开源情况多用户支持信道模型学习曲线最擅长的事NS-3 5G-LENA开源完善含调度/HARQ/移动性3GPP TR 38.901陡峭需掌握C和NS-3架构系统级协议级仿真调度算法改进Vienna 5G SLS部分开源完善小区化网络布局3GPP TR 38.901中等MATLAB为主系统级大规模网络仿真标准化验证MATLAB 5G Toolbox商业支持多用户但偏链路/小规模3GPP TR 38.901简化版中等物理层处理、算法原型验证OMNeT Simu5G开源完善3GPP及自定义中等偏陡网络层到应用层全栈仿真Sionna开源支持可微仿真射线路损/自定义中等需Python/深度学习基础结合神经网络的无线仿真与优化从表格能看出来不同工具侧重点确实很明显。如果你要研究MAC层调度算法或者协议交互NS-3的5G-LENA模块几乎是避不开的选择如果更关注大规模网络布局、频率规划这类系统级问题Vienna SLS这类基于MATLAB的仿真平台更顺手如果只是验证一个信道估计或者预编码算法MATLAB 5G Toolbox的链路级仿真更轻便。2.2 不同目标对应不同选择别被工具绑架我见过不少同学一上来就纠结“哪个仿真器最强”其实这是伪命题。做多用户场景仿真工具不是越复杂越好而是跟你的研究/工作目标匹配最好。如果你的目标是验证某个调度策略的提升效果比如对比轮询、比例公平这类调度算法那绕不开NS-3/Simu5G这类带完整MAC层协议栈的仿真器因为调度器就是MAC层实现的。用MATLAB去仿真调度一是要自己写大量协议逻辑二是仿真速度很慢几十个用户跑上百个子帧时间开销和内存开销都吃不消。如果目标是评估某个物理层算法在多用户场景下的性能比如用户配对/波束管理方案那么链路级仿真配合一定的多用户复用也能完成MATLAB更适合因为物理层处理可以精细建模包括导频、解调、信道估计误差这些细节。如果目标是做网络级容量评估比如一个宏站覆盖范围内不同用户密度条件下小区吞吐量变化那Vienna SLS这类系统级仿真器最合适运算效率和统计粒度都明显更好。我自己做调度和资源配置类的内容主力是NS-3的5G-LENA模块部分物理层验证会回落到MATLAB上去跑。两个工具配合使用各取所长比死磕一个工具效率高得多。3. 多用户场景的核心机制调度、干扰与移动性3.1 调度算法怎么选RR、PF还是Max C/I多用户场景绕不开资源调度调度算法决定每个时隙哪些用户占用哪些资源块。最常见的三种算法轮询调度Round Robin, RR、最大载干比Max C/I、比例公平Proportional Fair, PF。RR算法简单粗暴所有用户循环排队按顺序轮流分配资源。用户信道质量好坏无所谓人人有份。优点是实现最简单绝对公平缺点是资源利用率很低明明某个用户信道极差还非要发那么多数据白白浪费资源块同时小区总吞吐量会被很差的那几个用户拖累。Max C/I算法恰恰相反每次调度都把资源优先分给SINR最高的用户这个用户往往离基站最近、信道最好。这样计算出的理论峰值速率最优但边缘用户可能长时间得不到服务所谓“饿死边缘”现象就在这种算法下出现。PF算法是工程上最常用的折中方案。它的调度优先级计算为当前可达到的瞬时速率除以该用户的平均历史速率。瞬时速率高的用户有优势历史平均速率低的用户也有补偿这样既照顾了信道好的用户又不会让边缘用户长期没资源。这个算法不需要全局信息每个用户维护自己的历史吞吐量即可实现复杂度低所以NS-3和大多数系统级仿真器里PF是默认调度器。用公式表达一下PF调度器在每个TTI的选择逻辑# 调度优先级计算示意 priority instantaneous_rate[user] / average_rate[user] # 历史平均速率用指数移动平均递推 # alpha取值一般在0.01 ~ 0.1之间 average_rate[user] (1 - alpha) * previous_average_rate[user] alpha * scheduled_rate[user]如果你打算在仿真里对比调度算法注意保持所有其它配置完全一致只切换调度器类型否则结果差距说不清楚是调度算法带来的还是其它参数变动带来的。3.2 干扰建模与SINR计算多用户场景里SINR是个核心中间变量几乎所有吞吐量判断都建立在它的基础上。SINR的全称是信干噪比等于有用信号功率除以干扰功率加噪声功率。在多用户场景中干扰部分逐步变复杂同一时刻同频复用的邻区用户是干扰源相邻波束的泄漏信号也是干扰源甚至移动用户从小区A边缘切换到小区B的过渡过程中两个基站同时下发数据也会引发干扰。具体计算时UE收到的总功率包含来自服务基站的信号功率以及所有其它基站/其它用户带来的干扰功率。仿真器在计算SINR时会根据天线方向图、下行发射功率、路损和阴影衰落算出每个基站/每个波束到UE的接收功率再把非服务信号全部归入干扰项。这个细节看起来简单但对仿真结果影响很大。我举个实际例子如果只用热噪声计算SNR而忽略邻区干扰SINR可能比真实情况高3至5dB对应吞吐量甚至会高出一倍左右。所以跑多用户仿真时必须确保“干扰扇区/小区”已经在拓扑里创建出来且跟服务小区频率相同否则SINR虚高的问题会让你后面所有结论都站不住脚。至于基站侧的功率控制一般系统级仿真会为每个PRB设置下行发射功率比如按总功率除以RB数均匀分配。波束成形场景下每根天线阵元的增益和方向图叠加到UE接收功率计算中这时的干扰建模还要额外考虑波束的“空间选择性”否则波束增益带来的好处会被高估。3.3 用户移动性模型怎么搭真实网络里用户大概率在移动多用户仿真如果所有用户静止只能算个静态快照。移动模型常见的有随机游走、随机路点、曼哈顿模型几类。随机游走最简单每步随机选择一个方向和一个速度移动一小段时间后重新随机随机路点在随机游走基础上增加了“目标点”的概念用户先随机选一个目标跑到之后再选下一个曼哈顿模型则模拟城市道路场景用户只沿网格状街道移动适合城区宏站场景。移动性对多用户仿真带来的影响是连锁的用户位置变化导致路损变化SINR跟着变调度结果随之改变切换流程开始触发切换带来信令开销和中断时延时延指标又开始波动。所以如果你仿真时明确不关心移动性问题可以关掉切换或让移动速度极低但要清楚这相当于人为限制了一个场景边界如果你关心移动场景下的吞吐量和切换连续性那要把移动模型、切换门限、延迟触发时长这几个参数一起配置。关于移动速度一个小建议3km/h行人速度和60km/h车行速度跑出来的结果差异远比多数人想象的大。因为高速移动带来的多普勒效应会让信道估计误差变大这在小规模仿真里反映在SINR波动上在大规模多用户仿真里会直接影响调度器的决策质量。如果你要仿车辆场景务必把信道模型参数里的用户速度对应上不要用默认的静止配置。4. 实操过程跑一个16用户的5G多用户仿真4.1 场景定义与参数配置表直接给出一套我常用来做对标测试的16用户场景配置你可以把它当作基线后续按需修改。这套配置覆盖了混合业务、不同移动速度、非全缓冲流量三种典型因素比较好暴露问题。参数项配置值小区拓扑1个宏站3个扇区载波频率3.5 GHz (FR1)系统带宽100 MHz子载波间隔30 kHz用户总数16个活跃用户用户分布均匀随机分布在每个扇区覆盖范围内距离基站35m~300m移动速度8个3km/h行人8个60km/h车载移动模型随机路点方向变化最小距离控制业务类型8路FTP下行(50MiB文件)4路视频流(4Mbps/路)4路urllc小包(500B/20ms)调度器比例公平PFHARQ开启最大重传4次信道模型3GPP TR 38.901 UMa 非视距仿真时长模拟时间30s重复5次随机种子这套配置的典型用途是观察PF调度在混合业务条件下的资源分配行为、不同移动性分组对小区吞吐量贡献的差异、以及uRLLC业务的时延尾部分布。你跑通之后再去掉某些配置做对比实验比如全换成分组非实时业务或者全换成静止用户就很容易看出每个因素对结果的贡献。4.2 先算一下理论容量心里有个数有经验的做法是仿真之前先手算一遍理论容量上界避免被仿真结果带偏。以这套配置为例100MHz带宽、30kHz子载波间隔对应273个资源块。一个资源块有12个子载波每个时隙14个OFDM符号在某一个时隙内每个RB一共是168个资源单元。用256QAM每个RE承载8比特配合编码速率为0.925的极高端配置单个RB单时隙的理论容量约为168×8×0.925≈1243比特。再算上时隙长度约0.5ms单RB理论速率约为2.4Mbps左右。这个数值是物理上界的粗略估算实际仿真中还要扣除控制信道、导频开销、HARQ重传以及低阶MCS所以单用户偶发速率大概率远低于此但如果你看到某个用户在好信道条件下长期跑出4Mbps以上基本说明仿真器里的资源映射或信道估计有问题需要回头检查配置。这种预算是多用户仿真里非常有用的“健康度校验”强烈建议养成习惯。小区总吞吐量上界则可以把273个RB全部用于数据传输按平均每个RB的效率打个折比如50%~70%的平均效率100MHz小区总吞吐量应该在1.5Gbps到2Gbps附近。如果你的多用户仿真结果远低于这个范围先查是不是控制信道开销配得太高或者调度器收敛有问题而不是急着改业务源。4.3 仿真运行与结果指标怎么看以NS-3为例运行这类场景的基本流程是创建仿真拓扑设置信道和物理层参数配置MAC调度器挂载应用层流量启动仿真收集扇区级和用户级的统计数据。关键节点里要重点检查几个指标小区聚合吞吐量、各用户平均感知吞吐量、uRLLC业务端到端时延、以及调度器分配的RB比例。下面是一段NS-3中配置PfFfMacScheduler和流量实例的参考片段# 以NS-3 5G-LENA模块配置为例命令/配置片段 # 设置载波带宽与子载波间隔 --frequency3.5e9 --bandwidth100e6 --subcarrierSpacing30 # 选择调度器 --schedulerns3::PfFfMacScheduler # 配置下行流量 ./waf --run scratch/multi-user-sim --numUe16 --schedulerns3::PfFfMacScheduler --simTime30 --rngSeed7跑完之后不要只看一个平均数。我习惯把用户级数据落地成CSV表格按用户ID、移动速度分组、业务类型做汇总。这样做一轮下来你会看到低速用户平均吞吐量基本稳定但高速用户的吞吐量方差明显更大uRLLC业务的平均时延可能很漂亮但P99时延往往高得吓人——这就是尾延迟只看平均值根本发现不了。公平性指标也是重点。多用户场景中如果只有一个长期占用资源的用户小区吞吐量很好看但其它用户几乎没数据传输这显然不代表真实性能。量化工具是佳尼斯公平指数取值0到1之间简单理解就是数值越接近1各用户获得的资源越均匀。PF调度器在理想条件下能让公平指数稳定在0.9以上如果你跑完发现这个指数掉到了0.6甚至更低去检查是不是有某个用户始终拿不到调度机会大概率是移动模型或信道极差导致的饥饿问题。5. 常见问题与排查技巧实录5.1 多用户仿真典型问题速查表这里整理了几个我多次踩过、也见过别人反复踩的典型问题做成速查表方便对照。现象常见原因排查思路用户数从8增加到16小区总吞吐几乎不涨资源块已满瓶颈在MAC调度或FTP文件早被调度完进入空闲统计RB利用率确认是不是资源不足检查应用层是否还有待传数据某个用户吞吐量长期趋近于0该用户信道质量极差或配置文件里漏配了业务UE在切换洞口反复失败打印该用户SINR轨迹查看切换事件看是不是卡在切换失败→重建的死循环uRLLC业务时延均值正常但P99极高高优先级业务被eMBB大包堵住调度器没按QCI区分优先级核对调度器是否启用QoS感知的优先级队列看RB分配是否按QCI分层SINR整体偏高吞吐结果离谱干扰源没建出来或仿真初始化时邻区未分配载波检查全部eNodeB/扇区是否激活且同频打印接收端干扰功率值仿真内存随用户数急剧膨胀甚至OOM每用户每TTI的记录数据全量落盘存储爆炸关掉过度日志按周期聚合输出而不是每TTI一导出行不同随机种子结果差异很大用户分布/信道衰落随机性太强统计样本不够增加仿真时长或者多做几组种子并对结果取置信区间不要只跑一次5.2 避坑心得与调试技巧结合多次调试实战我总结了几个适用于多用户场景仿真调试的通用技巧供大家参考。第一个技巧是“先少后多先静态后动态”。不要在第一次跑就上几十个用户加高速移动否则出问题根本定位不到源头。我的习惯是先用3个用户、所有用户静止、全用同一种业务跑通流程验证信道和调度基本正常然后逐步增加用户数观察每增加一批用户小区吞吐量和公平性如何变化最后再引入移动模型一步一步拆开验证。这套流程虽然多花一点时间但从全局看是最省时间的方式。第二个技巧是“日志种子两手抓”。NS-3这类仿真器的日志系统很强大但全量日志在几十个用户并发时会产生巨量文件磁盘经常被撑爆。我通常的做法是普通运行只保留用户级统计和应用层摘要日志只有怀疑某个具体用户时才临时把物理层/MAC层对应模块日志打开限定打印那个用户的记录。另外随机种子一定要在实验记录里写清楚同一组参数至少跑3到5个不同种子用均值和方差说话。只跑一次出来的数字不管是高是低都不一定可靠。第三个技巧是“变化只动一个变量”。在研究多用户场景时这句尤其重要。很多人喜欢一次性改掉调度器、移动模型、业务类型、用户数量几个参数结果是结果差异很大却完全归因不清哪个改动导致的。我自己的习惯是对照实验一次只改一个参数其余全部保持不变。比如先改调度器从RR到PF对比吞吐量和公平指数变化再改移动模型看看在同一个PF调度下差异如何。这样才能得到可写进论文或报告里的干净结论。另外关于仿真时长多用户场景比单用户需要更长的仿真时间才能让系统进入稳态。业务模型如果是非满缓冲、有到达和离去的仿真前期的瞬态行为会明显影响平均指标。所以仿真时间不要设太短至少要让每个用户完成多次业务会话再停止否则你会得到一组充满“启动效应”的数据。判断是否进入稳态的办法很简单把小区吞吐量按时间画成曲线如果曲线后半段围绕一个稳定均值波动则可以认为进入稳态否则加长仿真时长或调整预热期。实际操作中我还习惯在每次仿真结束后把配置参数和结果摘要一起存到一个带时间戳的目录里文件名直接写成“16UE_pf_uma_30s_seed7”这样的格式。这样过了几周回来看数据还能一眼知道对应的是什么场景、什么随机种子不用费劲翻历史日志。这个习惯虽然简单但每次实验多了以后会发现真的能救命。多用户场景仿真的排查很多时候难点不在于某一行配置错误而是几十个参数之间相互影响导致错误被掩盖、被放大、或者被别的现象“吸收了”。把每次实验的配置档案做扎实就是在跟这种复杂度打交道时最值得投入的一件事。