1. 项目概述与场景解读做无线通信系统仿真这些年我一直觉得有个问题绕不开地面设备的算力、电池、带宽都是有限的但应用需求却越来越大。你让手机本地跑一个实时目标检测功耗和时延直接顶不住让传感器节点处理高精度数据融合算力又不够。于是“计算卸载”这个概念就成了热点——把任务丢给边缘服务器去处理。可问题在于边缘服务器不是哪儿都有尤其在偏远地区、临时部署场景或者灾害应急场景里地面基础设施根本指望不上。这时候无人机就显出了价值。它能飞、能悬停、能看到整个地面终端的分布还可以搭载边缘计算节点作为空中基站或中继节点。换句话说无人机把“算力”带到了离用户更近的地方。但无人机不是万能的它的覆盖范围有限、能量有限、回传链路也有限。更关键的是大量地面终端同时向无人机卸载任务时频谱资源怎么分配谁先传、谁后传如果用传统正交多址OMA的方式每个用户独占一个时频资源块无人机的服务用户数就会被资源块数量锁死。非正交多址NOMA正好是对着这个痛点来的。它允许同一个资源块内容纳多个用户利用功率域的差异来区分不同用户信号接收端通过串行干扰消除SIC逐级解码。这样一根频谱上就能塞下更多用户频谱效率直接上去卸载吞吐量也水涨船高。但NOMA也不是白拿的好处——功率分配怎么定谁配大功率谁配小功率无人机的飞行轨迹又怎么配合用户的分布这些问题就是“性能分析”和“优化”要解决的核心。这个项目标题里的几个关键词我拆开看是这样一层关系UAV是载体负责把边缘计算能力送到用户附近并且动态调整位置来改善信道条件NOMA是接入方式负责让多个用户在同一资源块上同时传输突破正交接入的用户数瓶颈蜂窝卸载是场景目标也就是把地面用户的计算任务通过无人机中继卸载到边缘处理器性能分析与优化则是整个课题的落脚点你不仅要仿真出系统跑起来还要量化评估关键指标再把功率分配、任务比、无人机轨迹这些参数调优。我最初拿到这个题目的时候第一反应是这可以做很浅也可以做很深。浅的做法是搭一个固定位置无人机场景用户均匀分布NOMA配对固定仿真吞吐量和时延画出曲线就收工。深的做法则涉及联合优化——无人机的三维部署位置、NOMA的功率分配系数、用户的卸载任务比、飞行轨迹的动态调度闭环。这个项目代码实现的思路明显偏向后一种因为它要求的不是验证一个固定方案“能不能跑通”而是探索“怎么跑才最优”。这篇文章就是围绕这套完整工作展开的。我会按照我实际做这个项目的过程从系统模型怎么搭、信道怎么建模、NOMA和SIC怎么实现到性能指标怎么选、优化问题怎么建模、算法怎么迭代再到仿真里那些坑和调试心得一条线写下来。适合正在做无人机通信、NOMA或者边缘计算卸载方向的在校同学参考也适合想快速掌握这类仿真思路的进阶玩家。代码实现部分采用的是Matlab这套工具链一方面是因为Matlab在通信系统仿真上生态成熟、自带大量无线通信工具箱函数另一方面是它对参数调整、循环迭代和绘图数据导出支持特别顺手验证算法时能省下不少时间。2. 系统模型与场景设计2.1 场景角色与链路关系把UAV-NOMA蜂窝卸载这个系统画出来看里面主要有三类角色。第一类是地面用户设备UE它们就是产生计算任务的人可能是手持终端用户也可能是部署在现场的传感器节点。它们的特点是位置分布在无人机覆盖的区域内计算能力有限任务有严格时延要求。第二类是无人机UAV它带一个边缘计算单元既能做空中基站接收用户的上行卸载信号也能在中继模式下把数据转发给后端的宏基站或边缘云。第三类是宏基站/边缘服务器它是整个系统的算力底座对时延不敏感的任务最终汇聚到它这里执行。链路关系也不复杂但容易乱我梳理一下。场景里同时存在两条链路用户到无人机的上行接入链路以及无人机到宏基站的回传链路。计算卸载的完整路径是用户把任务数据通过NOMA方式发送给无人机无人机收到叠加信号后做SIC解码恢复出每个用户的任务数据然后无人机决定哪些任务自己算哪些继续通过回传链路转给宏基站算。两条链路的速率都会影响卸载性能单拉一个信道来优化是偏颇的。这里有个很关键的场景设计决策无人机到底是做“空中边缘节点”还是只做“转发中继”。两者的区别直接决定了问题复杂度。如果无人机自己是边缘节点那优化变量里就得加一个“本地计算与回传卸载的任务分割比”如果无人机只是中继那问题退化成纯传输调度问题计算模型可以简化掉。我在这个项目里采用的是前者因为更贴近真实应用——无人机配边缘计算模块已经是当前产业里明确推进的方向带完整边缘节点的场景更有研究价值。无人机的高度也是一个不能拍脑袋定的参数。它直接决定了信道的大尺度衰落视距概率、路径损耗指数以及覆盖半径。高度太低容易被地面障碍物遮挡H越高视距概率越大但相应的路径距离也变长。这个矛盾在仿真模型里体现得非常清楚LoS概率公式里含有高度和水平距离高度高时虽然更容易拿到LoS链路但距离损耗同步增加所以存在一个最优悬停高度。2.2 NOMA用户配对与功率域映射NOMA在同一资源块上叠加多个用户最典型的是两两配对也有一个资源块叠三个用户甚至更多的情况。配对方式对性能影响很大这背后有承载能力的权衡。两两配对实现简单、SIC解码复杂度低、误传风险小但频谱效率提升有限多用户同资源块叠加能进一步提升接入密度但接收端SIC解码链路变长任何一环解码出错都会连带恶化后续用户。从仿真角度讲第一次接触NOMA时最容易犯的错误是直接把所有用户都塞进同一个资源块然后给它们随便分配功率系数。这么做的直接后果是SIC解码后的用户速率分布极不均衡——信道好的用户被排在解码序列最后却只分到很小的功率速率反而更低。标准做法是按下行链路的“信道增益排序”来分配功率信道增益差的用户分更多功率让它排在SIC序列的最前面先解码信道增益好的用户少分功率排后面解码。这个弱用户多分功率的原则本质上是给差信道用户补偿换取整体公平性的提升。功率分配系数确定后所有叠加用户的信号在同一资源块上同相相加形成叠加信号。这里补充一个容易让新手困惑的点NOMA叠加的是调制符号不是比特。每个用户的星座点符号在发送前各自加权后相加接收端看到的是不同幅度的多个星座点重叠这个叠加过程要保证接收端的星座图在数值范围上不溢出所以功率归一化系数得算清楚。2.3 任务模型与资源约束计算卸载的核心是“任务”。仿真里不能只说“用户有任务要传”得把任务建模成可以量化的参数。我在这个项目里用三元组给每个任务建模任务数据量Dbit、计算密度Ccycles/bit即处理1 bit数据所需的CPU周期数、时延上限s。任务数据量决定传输开销计算密度决定执行开销时延上限决定整个卸载决策的可行性约束。无人机自身的计算资源也用MEC服务器模型来表示主要是CPU频率cycles/s和可以同时执行的并行任务槽位。不过要说明一点为了简化仿真复杂度项目里不单独建模任务在无人机上的排队等待过程而是假设无人机总能即时处理接收到的任务。这个假设是学界和工程仿真的常用简化——排队论那套东西可以单开一个专题去讨论但在研究通信资源分配为主的阶段硬塞进来容易把因果链搅乱。还有一个重要的约束是无人机的能量。多旋翼无人机的推进能耗大概占掉总能耗的绝大部分机载边缘计算那点能耗反而占比小。所以轨迹设计里我很关注的一点是无人机不能为了追求信道增益无限靠近某个用户因为这会明显牺牲其他用户的服务质量也增加飞行控制能耗。悬停不动还是沿某条路径巡航这些决策本身就影响了所有用户的路径损耗。3. 通信与计算机制拆解3.1 NOMA叠加编码与原理解释NOMA的核心机制我用一句话概括所有用户在发送端用不同的功率给信号加权然后在同一时频资源上叠加发送接收端从信号最强的用户开始逐级解码每解出一个用户就把它的信号从叠加信号里减掉再解下一个用户这个过程就是SIC。用个生活化的例子三个人同时在你耳边说话音量大小不一样。你先听清最大声的那个把他说的内容记下来然后在脑海里把最大声那个人的声音“减掉”剩下的干扰就少了一些再集中注意力听第二大声的逐个减掉之后最后那个人即便音量最小你也能听清。NOMA的下行和上行SIC逻辑方向是反的但原理一样——通过解码顺序的安排让所有用户都能在叠加干扰中找回自己的信号。3.2 SIC解码流程SIC实现流程我在代码里是这么组织的第一步接收端拿到的信号是各个用户信号与信道增益乘积的叠加。第二步按信道增益排序确定解码顺序。信道增益最强的用户信号在叠加信号里往往占据最大功率最先被解码恢复。第三步解码出来的符号经过解调、信道译码得到该用户的比特数据。第四步将解码得到的用户信号重构重新调制、乘信道增益从接收信号中减去。第五步对剩余信号重复上述过程依次解出其他用户的数据。仿真实现SIC有个容易踩坑的地方理想SIC假设干扰可以完全消除但实际SIC有错误传播。我最初照搬理想SIC模型结果所有用户速率会偏高尤其强用户和弱用户信道差较大的场景下理想SIC带来的误差会被放大。如果你想仿真结果更有说服力建议在SIC解码误差项里加一个残余干扰系数让解码后的残余干扰与信号功率成比例这样更接近实际链路。还有用户配对顺序的选择我之前提过按信道增益排序的原则。为什么不能随便挑因为SIC的可达速率域受解调顺序影响很大。你让信道最差的用户排最后一个解码他既要忍受前面所有用户的干扰又只分到很少的功率速率会非常难看。弱用户先解码、强用户后解码的上行SIC顺序配合非正交叠加是为了让匹配较差信道条件的用户在功率维度得到补偿最终两个用户在可达速率域上都能获得比OMA更好的点。3.3 链路速率与能耗计算给每条链路算速率之前得先明确几个前提参数带宽、信道增益、发射功率、背景噪声功率。对上行NOMA场景用户在同一个带宽资源块上叠加发射无人机作为接收端做SIC解码每个用户在SIC解码顺序确定后其可达速率取决于它解码时尚未消除的干扰。它的干扰项不是所有其他用户的信号而是排在它后面信道更强那部分用户的还没被减掉的信号。这里有个NOMA独有的特性第k个用户的可达速率公式里分子是自己的接收功率分母是噪声加上排在其后用户的干扰功率排在其前的用户的干扰已经被SIC消除掉了。这导致一个直观结论解码顺序越靠前的用户虽然最先解码但要忍受更多干扰解码顺序越靠后的用户干扰越小但它的信号往往被分配了更小的功率。两者的平衡点正是功率分配优化要解决的问题。功耗模型这块我在项目里把无人机的能耗分成推进能耗和悬停能耗两块。当无人机在移动时用推进能耗模型当无人机悬停服务时用悬停能耗模型。这两种模型都与无人机重量、空气密度、旋翼面积相关。如果你不想把无人机动力学细节全揉进通信仿真里可以对能耗做一个简化处理给每单位移动距离一个能量系数悬停则按时间计费这样既不过度复杂又能对比轨迹方案的能耗差异。4. 信道建模与仿真参数配置4.1 空地信道模型与参数无人机通信区别于地面通信的最显著特点就是空对地信道里存在一条稳定的视距链路。我处理空地信道时用的是国际通行的空地信道模型它把信道分成视距和非视距两种状态两种状态出现的概率由仰角决定——无人机飞得越高用户与无人机之间的仰角越大视距概率越高路径损耗指数反而越小。具体参数上视距路径损耗指数设为2.2左右非视距设为3.5左右。载波频率选择在2 GHz附近的典型频段同频干扰和阴影衰落按典型蜂窝场景设置。给用户和无人机建模的三维坐标需要提前定好这里我建议不要在代码里写死而是做成可以批量生成和随机化的输入参数这样后续做蒙特卡洛仿真时只需要换用户坐标样本就能跑出多组统计结果。大气折射、多径反射这些细粒度的效应在这个模型里不单独建但对慢变的大尺度信道增益来说这个简化已经够支撑NOMA性能分析——因为NOMA的功率分配决策对信道比的敏感性远大于对小尺度衰落的敏感性小尺度快速衰落更多影响链路的瞬时误码率而NOMA的资源调度的核心决策基于大尺度信道状态信息。4.2 仿真参数配置参考为了让你复现时有据可依我把项目用的主要仿真参数整理成一张表参数名取值备注说明载波频率2 GHz典型蜂窝频段系统带宽20 MHz每个NOMA资源块用户发射功率23 dBm典型终端发射功率噪声功率谱密度-174 dBm/Hz室温热噪声底无人机高度100-150 m需要参与优化视距路径损耗指数2.2空对地LOS模型非视距路径损耗指数3.5空对地NLOS模型用户数量4-12每资源块配2-4个用户任务数据量0.5-2 Mbit随机生成计算密度500 cycles/bit典型AI推理任务量级无人机CPU频率10 GHz等效共享算力这些参数不是我拍脑袋定的。前四个是常规蜂窝通信仿真的固定底噪参数后几个直接关系到NOMA叠加方式和计算卸载的可行性检查。用户数量从4到12递增可以清晰看出NOMA相对OMA的频谱效率优势无人机高度参与优化时范围100到150米是仿真里验证悬停高度最优性的一个合理区间计算密度500 cycles/bit对应的是轻量级图像处理任务。4.3 初始化与随机性控制仿真代码里随机性控制这一点值得单独说。无论你是做单次仿真看趋势还是做多次蒙特卡洛平均看统计特性随机数种子的设置都是必须的。否则你跑两次出来的曲线对不上调参时无法判断曲线变化是算法改进带来的还是随机噪声带来的。我的做法是在主程序开始用固定随机数种子用户位置生成时基于该种子但每次迭代更新时重新生成信道衰落系数。这样用户位置是稳定的信道瞬时值又能反映随机性。做蒙特卡洛时外层循环跑1000次每次重新生成信道样本但用户位置保持不变优化算法与固定吞吐量基线对比时都在同一组随机样本下测试这样比较才公平。5. 性能指标与仿真验证5.1 指标选择从吞吐量到时延做性能分析不能只看一个指标。我选了三个不同维度的指标来交叉验证系统表现三者的意义不一样系统总吞吐量所有用户卸载速率之和衡量频谱利用效率的核心指标NOMA的优势在这个指标上体现最直接。任务时延卸载计算总时延用户提交任务到无人机/宏基站算完返回结果的全部时间。只优化吞吐量不优化时延很容易得到一个“频率效率高但任务全超时”的畸形方案。卸载成功率或能源效率在一定能耗约束下能成功完成卸载任务的比例这个指标把前面通信域和计算域的考量合到了一起。指标之间是有内在张力的。总吞吐量最大化倾向于让信道好的用户占大权重但计算卸载时延要求却需要优先保证弱用户不被饿死。所以优化目标函数不能是简单的加权求和得合理安排约束条件和目标函数我后面会展开讲。5.2 仿真结果与趋势解读我跑完基础方案后得到的第一组对比结论是这样的同样用户数量下NOMA的系统总吞吐量相比传统OMA提升大概在25%到40%之间用户数越多NOMA的增益越明显。原因也好理解NOMA在同一个资源块上容纳的用户数比OMA多尤其当用户数量超过OMA可分资源块数量时OMA会直接出现无资源可分的情况系统吞吐量出现天花板而NOMA还可以继续叠。另一个有价值的趋势是功率分配系数对系统公平性的影响。当功率分配趋向极端强用户弱功率弱用户强功率时总吞吐量会下降但最弱用户的体验速率会明显提升反之功率分配趋于平均时总吞吐量上升但弱用户可能不达标。这个现象背后是速率域上的帕累托前沿移动找那个拐点附近的解才是联合优化的价值所在。5.3 与OMA基线的对比设计和OMA做对比时要注意OMA本身也有多种资源分配方案最简单的是平均分配常见的是比例公平分配。对比方案不统一会得出错误结论。我做对比时用的是OMA加比例公平资源分配作为基线——这个OMA基线已经很不错了NOMA还要在它之上继续提升吞吐量这样的对比结果更有说服力。对比指标上还要注意归一化设置两种方案的带宽、总发射功率、用户数量保持一致。如果NOMA多占了功率或者OMA少得了带宽对比就没有意义了。6. 优化问题与算法设计6.1 优化变量与目标函数建模现在所有背景铺垫完成优化问题的建模就是整个项目的核心环节。我把这个系统的优化变量梳理了一遍选定了三个最值得优化的维度NOMA功率分配系数、用户卸载任务比、无人机悬停位置坐标。为什么是这三个因为它们分别对应着通信域、计算域和空间部署域的核心决策维度三个变量相互耦合联合优化能体现研究的深度。目标函数定义考虑的是系统能效——单位能耗完成的任务量。约束条件包括每个用户的发射功率上限、无人机总功率带宽限制、每用户时延约束、无人机的覆盖范围约束。任务比分配还有一个隐含约束拆分的任务份数总和必须等于1且非负。6.2 优化算法设计与分析思路这种问题直接做凸优化是不行的目标函数和约束里包含非凸的信道模型、离散的用户配对属于典型的混合整数非线性规划MINLP。直接求全局最优解的计算复杂度不可接受。我更倾向用“分解迭代”的思路把联合优化拆成两个子问题一个负责功率分配和任务比另一个负责无人机位置优化两个子问题交替迭代每一次迭代只优化一方另一部分保持固定。功率与任务比子问题在给定无人机位置时可以转成标准的凸优化问题用内点法或Matlab的fmincon就能求解。无人机位置子问题相对复杂我一开始用的是穷搜网格法在地面区域打上密集网格逐步缩小范围搜索最优悬停位置。这个方案优点是鲁棒、不容易陷入局部极值缺点是大网格下计算量大。后来我把穷搜换成基于交替方向乘子法ADMM的分布式求解框架让每个用户根据自己的本地信道信息先提交一个偏好功率无人机端根据系统全局约束做协调修正。这个改动的思路和很多真实系统的实现是一致的完全集中的算法要求无人机知道所有用户的完整信道状态而分布式算法只需要增量信息交换。其实这里有一个所有优化仿真都绕不开的“检查试验”手段把你的算法解与穷举全局最优解做对比。当用户数较少时比如4个用户直接把所有可能的功率分配离散组合全部算一遍穷举出全局最优值再与你的优化算法结果对比。如果差距在一个可接受范围比如10%以内就说明算法有效如果差的太远排查方向优先看优化变量联合耦合时是否陷入了局部极值。7. 常见问题与调试经验7.1 代码实现的典型问题整理做这类仿真最常见的问题集中在这几类我按踩坑频率列一下第一类问题是SIC解码顺序越界——排序索引和用户编号没对上导致干扰项计算错误最后得到的用户速率出现负数或虚数。这种现象几乎全是索引错位造成的排查时先在SIC模块里单独打印每个用户解码时的接收功率和干扰项做核对。第二类问题是叠加信号功率溢出——用户信号加权叠加后幅度超过了解调器可处理范围。这通常在功率分配系数总和不为1或者忘记做功率归一化时发生。检查方法很简单对叠加信号求方差超过设定阈值就说明归一化系数有问题。第三类问题是信道数据单位不一致。Matlab里dB和线性值混着用是经典坑路径损耗有时用dB表示有时用线性值乘进去。我建议全程维护两条换算函数数值传入时统一转成线性值参与计算只在结果输出时转回dB能省一半的恶果。第四类问题是算法迭代不收敛。常见原因是目标函数中有不可导点比如min/max操作嵌套或者约束条件太紧导致初始点不可行。处理办法是放宽约束或改用罚函数法处理硬约束。第五类问题更有隐蔽性——任务时延约束设置过严导致可行域为空。比如用户离无人机很远时传输速率很低无论怎么优化功率分配卸载时延都超限。这时候如果优化器报不可行不要急着怪算法先检查任务数据量和时延上限取值是否合理。7.2 调试过程中容易踩的隐形坑这类仿真还有一个标量问题就是单用户数下结论的偶然性。我第一次跑优化算法时只用4个用户一组坐标效果很好换成12个用户后性能下滑严重。这是因为用户数量增加后NOMA配对的组合复杂度指数上升功率分配可能出现多个用户的信道差不大、SIC排序不稳定的情况。结论是在不同用户数下都要跑出统计曲线再下结论。另一个隐形坑是无人机位置优化的初始点对结果影响巨大。如果你用的优化器是局部搜索类算法初始无人机位置直接决定了最后收敛在哪个局部最优附近。我的做法是先用粗网格扫描一遍全局取网格中的最佳点为初始值再做精搜索这样可以大幅降低陷入平庸局部极值的概率。信道实现细节上还有一个注意点不要把信道当作常量。用户位置的轻微变化通过路径损耗放大后会导致NOMA功率分配策略大改——信道比只要出现翻倍级别的变化最优功率分配方案就可能从“强用户弱功率”跳变到“强用户强功率”的另一个极端。所以如果你的仿真里用户位置更新了但功率分配却没有重新优化那你得到的指标曲线会有明显的跳跃毛刺。7.3 如何确认仿真结果可信最后说下怎么确认你仿真出来的结果是可信的。第一步做能量守恒检查系统总发射功率应该等于各用户发射功率之和总卸载任务量等于成功解码任务量加上丢失任务量第二步做极端场景验证把NOMA退化成只有单用户时结果应该和OMA完全一致把无人机悬停在所有用户正上方时时延应该显著低于放在边缘时。第三步做参数敏感性分析微调用户数、带宽、高度这些参数结果应该平滑变化而不是剧烈震荡——如果某个输入只变了1%输出却跳了一倍多半是代码里有隐含的离散跳变没建模对。8. 项目扩展与效果提升方向主体研究完成了之后我给这个仿真项目留了几个可以继续扩展的方向这在学术研究和工程实践上都有价值。8.1 动态无人机轨迹与实时任务卸载当前项目里无人机位置是准静态——悬停在一个最优位置服务所有用户。但在真实场景里用户位置会移动任务到达也是动态的。扩展方向是把问题升级为动态规划在时隙粒度上同时优化无人机的移动轨迹和每个时隙的NOMA功率分配。无人机一边飞一边服务每一步动作同时影响当前时隙所有用户的信道和下一时隙的路径损耗连续性。这个方向的技术难点在于把时间维度加进来后问题规模成倍增长。一个可用简化思路是把用户位置预测模型加进来用模型预测控制MPC的思路每个时隙只优化未来一段窗口内的轨迹滚动执行。这样既考虑运动连续性又保持计算复杂度可控。8.2 多无人机协作与小区间干扰协调单无人机覆盖能力毕竟有限扩展多无人机协作是自然方向。多无人机系统里既要处理NOMA组内多用户叠加又要处理无人机之间的同频干扰协调。可以做联合波束成形设计或者把多个无人机组成一个虚拟天线阵列利用空间自由度对抗干扰。这个扩展在Matlab里的代码实现同样可复用现有框架核心改动是把单无人机的信道增益计算替换成多无人机多天线信道矩阵SIC流程里加上空间滤波步骤优化算法改成多无人机之间分布式协调ADMM框架可以平滑扩展。8.3 强化学习辅助的资源调度最后一个方向是用强化学习替代传统的数学优化方法。当问题规模很大、场景随机性很强时数学优化方法每次重算太慢强化学习可以用离线训练、在线决策的方式大幅降低实时计算开销。把功率分配和任务比映射成动作空间把系统能效和时延违例率映射成奖励函数让模型在大量随机场景模拟中学习最优策略。仿真代码里这个方向的改动也不小但思路是顺的Matlab可以搭建环境接口每次仿真输出状态和奖励智能体可以采用DQN或PPO算法离线训练。这个方向做完项目就从“给定参数求最优”升级为“应对未知场景自动决策”应用价值有明显提升。做这类研究项目我个人体会最深的其实不是算法本身而是“先把链路模型搞清楚再谈优化”的顺序。见过太多一上来就盯着优化算法猛调参数的最后发现问题出在最开始的信道建模上。整个项目从系统设计到仿真分析再到优化收敛链路很长但只要每一步都追求可解释、可复现这套方法论在后续任何通信系统仿真项目里都是通用的。最后补一句调试心得做这类仿真时把每一步的中间结果存下来把每一步的关键曲线画出来比事后断点调试高效得多——你不会知道到底是第几个循环里的索引偏移毁掉了你一整晚的仿真时间。