这个课题我前前后后做了大半年组里讨论最多的问题就是无人机在移动边缘计算里到底是当空中基站用还是当边缘服务器用。这两个身份对应的信道模型、能耗方程和约束条件完全不同最后我们把落点放在了后者——多无人机携带边缘计算资源在5G异构网络里为大范围移动用户提供任务卸载服务同时把无人机的三维部署位置、用户的卸载决策、计算与无线资源分配放在一个框架里联合优化。说白了这方向要解决的就一件事让大量用户的任务尽可能在离他们最近的“空中算力”上完成而不是全部涌向核心网。对正在做通信方向研究、想找切入点做毕业设计、或者对网络资源优化感兴趣的开发者来说这个题目几乎包含了异构组网、任务卸载、无人机部署、凸优化、启发式算法和强化学习的全套核心要素非常值得认真做一遍。做之前先想清楚一个问题你要的到底是“让任务跑得快”还是“让整张网省电”这个选择会直接影响目标函数怎么写、算法怎么选、代码怎么组织。后面我会把我在实际建模、推导、编码、调参过程中走过的路和踩过的坑都摊开讲。1. 场景与问题无人机MEC解决的是哪类痛点1.1 5G异构网络里的计算瓶颈5G网络并不是一张均匀的网宏基站、微基站、终端设备、回传链路层层叠加形成典型的异构网络。终端设备虽然支持5G但算力始终是硬伤。实时视频分析、沉浸式渲染、高精度仪表数据融合这类任务放到手机或普通的物联网终端上根本跑不动。如果全部走回传送到中心云回传链路会被打满端到端时延也会被业务链路拖垮。移动边缘计算的出发点就是把算力下沉到离用户最近的边缘节点上。理论上任何有计算能力的节点都可以承担一部分任务难点在于“让谁来算、怎么转发、能省多少”。这个决策就是任务卸载而卸载决策的质量直接决定了时延、能耗和业务成功率。1.2 无人机做边缘服务器优势到底在哪地面边缘服务器有两大硬伤。第一是固定部署遇到演唱会、应急保障、野外作业这种临时高密度用户场景地面节点的覆盖和容量往往来不及调整。第二是地物遮挡地面终端到地面基站很容易被楼宇、树木挡成非视距链路信道质量大幅度下降。无人机把这两个问题同时缓解了。无人机可以按需飞到用户密集区域的上空它和用户之间形成稳定的视距链路的概率比地面链路大得多而且不需要预先铺设基础设施。携带边缘计算资源的无人机本质上就是一朵“可以移动的算力云”在热点区域临时部署、任务结束再回收韧性很强。1.3 “联合部署与调度”难在哪很多人第一次看这类题目会以为把“无人机部署优化”和“任务调度优化”分开做就行。实际上不行。无人机飞到不同的位置用户到无人机的信道质量就变了卸载速率跟着变每个无人机上堆积的任务量也完全不一样反过来任务调度结果决定了每个无人机的负载情况负载又反推无人机应该待在哪。这两组变量是强耦合的。再加上卸载决策是离散变量无人机位置、算力、带宽是连续变量整个优化问题本质上是混合整数非凸规划。用户数量一上来解空间指数爆炸“联合优化”四个字就成了这个课题真正的分水岭。2. 数学建模的落地过程参数怎么设、公式怎么推2.1 场景与变量设计建模第一步不是堆公式而是把场景约束写清楚。我采用的是最典型的单时隙静态模型用户位置在一次决策周期内不变但可以是任意空间分布。用户集合记为U无人机集合记为M地面基站集合记为B。每个用户有一个待处理任务任务由三个参数描述输入数据量D_i计算密度C_i最大容忍时延τ_i。这三项是任务卸载建模的地基。数据量决定传输开销计算密度决定服务器CPU消耗最大容忍时延决定卸载是否可行。C_i的单位是cycles/bit不同类型任务差异很大图像识别通常取100到200 cycles/bit的区间工业控制类可以取更高。无人机作为边缘服务器时每架无人机有一个CPU频率上限和悬停功率。用户可以选择本地计算、卸载到无人机、卸载到地面基站三个路径。决策变量主要为无人机三维位置坐标、用户卸载目标选择、无人机与基站的算力资源分配、无线带宽分配。2.2 空对地信道模型的计算细节空对地信道是整个模型里最容易被忽略、却又最影响结果的部分。地面基站到用户的信道通常直接用瑞利或莱斯衰落但无人机到用户之间不能简单套地面模型因为无人机高度不同视距概率会发生变化路径损耗指数也不一样。常用模型是这样的逻辑先根据用户与无人机之间的仰角计算视距概率再按视距和非视距分别计算路径损耗。典型表达式为P_LoS 1 / (1 a·exp(-b·(θ - a)))其中θ是用户到无人机的仰角a、b是环境参数。城市环境里a通常取9.61、b取0.16这是业内用得比较多的一组参数。路径损耗按视距和非视距分别计算再对两种状态做期望处理得到平均路径损耗。我第一次复现的时候直接把自由空间损耗套进去结果时延小得离谱。后来改成视距概率模型再叠加地面基站的3D距离路径损耗系统时延曲线才变得和预期一致。这个细节强烈建议一开始就定好。2.3 任务卸载的三条路径表达式三条路径的时延和能耗模型要分开写。本地计算时延是t_local C_i D_i / f_i其中f_i是用户的本地CPU频率。这个最简单没有传输开销但耗的是用户设备自己的电算力还受限。卸载到无人机时延分两段上行传输时延加服务器计算时延。上行速率按香农公式r_i B_i · log2(1 P_i·h_i / (N0 I))其中B_i是分配到的带宽P_i是用户发射功率h_i是信道增益N0是噪声功率I是干扰项。时延表达式为t_uav D_i / r_i C_i D_i / f_e其中f_e是无人机分配给该用户的计算资源。卸载到地面基站同理区别在信道模型和服务器频率。能耗上用户侧主要看发射功率乘传输时间无人机侧主要看悬停功耗加计算功耗。无人机计算功耗可以按动态功耗模型P_comp κ · f_e³来计算κ是有效开关电容系数工程上一般取10⁻²⁸量级数值处理时小心别因为量级差太大溢出。2.4 优化问题如何形式化目标函数可以设为时延与能耗的加权和也可以设为能效即成功处理的任务数据量与总能耗的比值。这两种形式我都试过加权和形式好调试能效形式更贴近真实约束但目标函数非凸程度更高。统一的约束条件包括每个任务必须在最大容忍时延内完成分配给所有用户的算力之和不能超过服务器容量带宽总和受限无人机不能重叠部署且要保持在服务区域内。这里有个容易漏掉的约束——如果流量过高无人机算力不足任务可能被拒绝需要引入任务接受率指标。最终优化问题可以写成P0: minimize w1·T_total w2·E_total subject to 时延约束、算力约束、带宽约束、位置约束其中w1、w2是权重系数。调节权重可以模拟不同业务优先级比如时延敏感业务把w1调大能耗敏感把w2调大。这个权重也是后期画帕累托前沿的关键。3. 求解思路交替优化、凸近似、启发式与强化学习的组合拳3.1 块坐标下降法的基本框架混合整数非凸规划直接用求解器硬解用户一多就完了。工程上最常用的路线是块坐标下降法也叫交替优化。思路很简单把变量分成块固定一块优化另一块两块轮流迭代直到目标函数变化量小于阈值。放到这个项目里就是先固定无人机位置优化卸载决策和资源分配再固定卸载决策和资源分配优化无人机位置反复迭代。每一轮都是凸优化子问题或离散优化子问题比直接联合解容易太多。需要说明的是这个算法不能保证全局最优多启动几个初始点取最好结果是比较务实的操作。我通常取5到10组随机初始部署点每组都跑完整交替优化最后保留目标函数最小的那组结果。3.2 无人机部署子问题的求解路线无人机位置优化子问题是非凸的因为目标函数里信道增益对位置变量的表达式是复杂非线性函数很难直接求全局最优。我试过几条路线。第一条是把非凸项做一阶泰勒展开用连续凸近似不停迭代逼近局部最优解。这种做法收敛快缺点是要推一堆梯度表达式编码容易错。第二条是用粒子群算法、灰狼算法这类启发式算法去搜实现简单不依赖梯度但收敛慢用户规模上来后明显吃力。第三条是做网格采样加插值粗搜再用局部搜索精调适合无人机数量少、区域网格比较规则的情况。实际项目里我推荐主用连续凸近似配上粒子群做多初始点选取。连续凸近似的核心步骤是引入辅助变量把分式项拉平再做凸化处理。处理过程中要注意每次迭代之后更新辅助变量否则子问题会一直对着同一个近似目标求解迭代半天得不到实质改进。3.3 任务调度子问题的求解路线固定无人机位置后任务调度子问题包括两部分卸载目标选择以及算力、带宽分配。卸载目标选择是整数变量常见做法是把它先松弛成0到1之间的实数再把凸松弛问题求出的最优解投影回整数空间。这么做简单但会带来少量性能损失用户很多时可以接受。如果不想做松弛可以用匹配理论。把用户看作任务请求方无人机和基站看作服务提供方按信道质量和剩余算力做偏好排序然后跑双边匹配算法。相比贪心算法匹配理论能避免大量用户涌向同一个无人机的情况负载更均衡。算力、带宽分配子问题在固定匹配关系后通常是凸的可以直接用CVX这类凸优化工具箱求解。子问题求解时需要注意算力分配不均会造成“木桶效应”最慢的无人机拖累整个系统。我通常会在目标函数里加一个负载均衡惩罚项效果很好。3.4 用户规模变大以后怎么办当用户规模从几十个涨到几百个传统的交替优化迭代一轮的计算量都会变得很吃力更不要说多初始点。这个阶段有两种主流路线。一种是做问题分解把用户按地理位置或信道相似度聚成多个簇每个簇分配一个或两个无人机形成大小可伸缩的子问题。这种聚类预处理方法实现简单效果稳定尤其适合用户位置存在明显聚集特征的场景。另一种是深度强化学习。训练阶段非常耗时但推理阶段只要一个神经网络前向计算速度很快比较适合在线决策。实际项目里我经常把两套方案做成对比交替优化作为标杆方案提供近似最优解强化学习方案负责展示实时决策的可行性这样论文和汇报材料里的对比维度也更完整。4. Matlab与Python的代码实现细节4.1 混合编程的架构选择这个课题的代码命门是Matlab和Python如何分工。我的做法是Matlab负责系统建模、交替优化、CVX资源分配、仿真结果对比Python负责深度强化学习环境搭建、训练和可视化。两边通过文件接口交换数据而不是强行混编这样互不干扰调试也方便。选Matlab做优化部分是因为CVX用起来太顺手了凸优化子问题的建模几行就写完比在Python里手写求解器舒服得多。Python侧则是因为PyTorch做DRL网络训练生态更成熟。这套分工是实验室里比较常规的方案强烈建议沿用。4.2 Matlab侧的核心模块实现Matlab代码我习惯分成四个模块系统参数初始化、信道计算、优化循环、结果记录。信道计算最关键代码写清楚之后后续所有公式都依赖它。无人机到用户的信道增益计算核心逻辑类似这样function h compute_uav_channel(user_pos, uav_pos, fc, env_params) % user_pos: 用户二维坐标点集 % uav_pos: 无人机三维坐标点集 % env_params: 环境参数 a,b 以及视距/非视距损耗均值 d_2d sqrt((user_pos(:,1)-uav_pos(1)).^2 (user_pos(:,2)-uav_pos(2)).^2); theta atan2(uav_pos(3), d_2d); % 仰角 p_los 1 ./ (1 env_params.a * exp(-env_params.b * (theta - env_params.a))); pl p_los .* env_params.pl_los (1 - p_los) .* env_params.pl_nlos; h 10.^(-pl ./ 10); end这里仰角用atan2计算保证在无人机直接悬停在用户头顶时仰角趋近90度视距概率接近1符合物理直觉。信道增益单位是线性值后面带公式里直接用。资源分配子问题用CVX实现时常见写法是这样的cvx_begin quiet variables f_alloc(M,1) B_alloc(M,1) minimize( sum(w_t .* (D ./ rate) w_e .* kappa .* f_alloc.^3) ) subject to sum(f_alloc) f_uav_max; sum(B_alloc) B_max; f_alloc 0; B_alloc 0; % 每个任务时延约束 D ./ rate C .* D ./ f_alloc tau_max; cvx_endcvx_begin后面的quiet建议保留不然控制台输出几百行求解日志找问题很痛苦。时延约束里的倒数项在CVX里会被识别为凸函数一般的求解器都能处理但初始化时要确保f_alloc的初值不让约束变成除零。4.3 Python侧的DRL训练流程Python侧的任务是训练一个决策网络输入当前用户位置、任务属性、信道增益、无人机当前负载等信息输出每个用户的卸载比例或卸载目标选择。我选用PPO算法它在连续动作空间和离散动作空间混合场景下比DQN稳定。环境封装的核心接口是这样的class MECEnv: def __init__(self, user_num, uav_num, task_generator): self.user_num user_num self.uav_num uav_num self.task_generator task_generator def reset(self): self.users self.task_generator.generate_users() self.uav_pos self.init_uav_pos() return self.build_state() def step(self, action): # action 拆分为卸载目标选择与带宽分配指数 reward, info compute_reward(self.users, self.uav_pos, action) next_state self.build_state() return next_state, reward, False, info奖励函数我这里直接设成负的加权时延和能耗再把惩罚项加上。任务超时给一个较大的负奖励避免网络学会“放弃任务”来刷低时延。对无人机电量告急的情况也会引入额外惩罚这样训练出来的策略不会把某个无人机当成永动机往死里用。训练时有个容易被忽略的点奖励的数值量级不能太大也不能太小。如果时延单位是毫秒能量单位是焦耳两者数值差了好几个数量级梯度更新就翻车。我的做法是先分别归一化到0到1区间再加权数值永远控制在一个稳定范围内。4.4 实验设计与结果呈现仿真对比环节至少要做这几组方案本地计算所有任务不上传作为时延下界参照。地面MEC只卸载到地面基站无人机不参与体现无人机增益。随机部署无人机加就近卸载一个通用下界参照检验优化算法的提升幅度。固定无人机位置的调度优化把部署优化带来的增益单独剥出来。联合优化方案交替优化与DRL各跑一遍。画图时别只画时延平均值要把任务成功率、用户公平性和能效一起画。收敛曲线建议画目标函数值随交替迭代次数的变化观察算法在第几轮收敛这个信息对后续调参很有用。如果发现收敛曲线剧烈震荡大概率是辅助变量更新步长过大需要降低更新因子。能效对比图我习惯用柱状图加误差棒每个点跑10次取平均值和标准差。实验前固定随机种子不然每次跑出来的曲线都不一样组内其他同学复现时会很崩溃。5. 实战中的坑与排查清单5.1 模型层面的边界陷阱建模阶段最容易翻车的就是边界情况。用户位置生成时如果不限制服务区域随机分布会散到几十公里外导致所有用户信道增益都低到离谱整个优化结果没有参考意义。我一般把用户用二维高斯混合模型画成几个热点簇再叠加均匀噪声这样分布既有聚集性又有随机性比较接近真实场景。无人机数量也不是越多越好。仿真扫一遍无人机数量从2到8的曲线就能看到边际收益递减前两架增益明显后面新增无人机的收益越来越小还会引入额外干扰和能耗。这个饱和点直接决定最终报告里推荐的无人机数量。5.2 算法层面的常见问题交替优化收敛慢或陷入很差局部最优通常有两个原因。一是初始点位太差无人机落在服务区边缘。我的解决办法是用K-means把用户聚成M簇把簇中心初始化成无人机位置然后再做微调。二是两个子问题的迭代步长不匹配部署更新的步长过大导致目标函数来回震荡。调步长要观察每一步的目标值变化而不是死守固定学习率。连续凸近似方案里泰勒展开点如果离真实解太远近似误差大迭代会飘。我的经验是每次更新后限制位置变化的半径防止变量跳得太猛。这个约束在数学上叫信赖域约束实战中极其好用。5.3 代码实现层面的典型问题CVX求解有时候直接报“不可行”多半不是求解器的问题而是约束设置自相矛盾。常见情况是任务最大容忍时延设得太小而无人机算力不足以在这么短时间算完所有任务。排查时先把时延约束放宽逐个加回去看哪一项触发不可行。DRL训练不收敛是另一个高频问题。如果奖励曲线一直上不去先检查状态表征是否包含了必要信息比如每个无人机的剩余算力。很多情况下网络学习不到规律是因为状态里缺了关键变量。其次检查奖励放缩系数奖励跨度过大时梯度爆炸明显加梯度裁剪和奖励归一化基本能稳住。还有一个隐藏很深的细节PyTorch的DRL训练默认用float32但环境里的信道计算涉及大量累乘数值稍微大一点就可能溢出变成inf。建议在环境内部统一用float64只在输入网络前把数据转成float32。5.4 问题排查速查表现象可能原因解决思路时延结果偏低到不合理信道模型用了纯自由空间损耗改回视距概率加路径损耗模型交替优化收敛慢无人机初始点位置太差用聚类中心做初始化迭代过程剧烈震荡部署更新步长过大加信赖域约束或调小更新半径CVX报infeasible时延或算力约束相互冲突放宽约束后逐一排查定位冲突项收敛曲线平滑但结果差目标函数权重失衡归一化时延和能耗后再加权DRL奖励长期不变奖励稀疏或状态缺关键变量检查奖励信号和状态空间设计训练中loss出现NaN梯度爆炸或数值溢出加梯度裁剪统一精度计算用户增加后运行时间暴涨整数松弛后仍走穷举匹配改用匹配理论或聚类预处理这张表基本是我从项目启动到结题过程中踩坑的浓缩版。遇到问题先对着表自查比自己瞎调参高效得多。5.5 一个不够顺手的调试技巧最后分享一个平时不爱提的土办法把目标函数拆成一部分一部分验证。比如先不管能耗只优化时延跑通之后再把能耗项加回来。任何联合优化项目第一版代码能跑出比随机方案更差的结果都不用慌多半是某个子问题的约束没写对。用这种“加法式排错”每一步都能定位到问题出处。如果实在找不到问题把中间变量打印下来和手算的小规模算例对比。我做了一个用户数3、无人机数1、地基站数1的极简算例手算所有时延和分配量然后让代码跑同样的输入逐项核对。这套流程看起来笨但对工程排错的效率极高。6. 最后说几点个人体会这个项目最折磨人的不是算法推导而是“联合”两个字。把部署模块和调度模块分开各自调通之后一旦合并数据传输、变量更新顺序、边界判断全都要重排。我的建议很明确——先固定无人机在用户簇质心把调度模块完整跑通、画图、确认指标合理再放开位置变量用交替优化一点一点加。这样每一步都能确认新增的那块逻辑没有引入新问题。另外建议所有结果曲线都保存一次原始数据不要只留图。后面改参数、换思路需要重新对比时能直接调数据而不是重新跑一遍。仿真代码会在你改第三次模型时彻底变成另一个工程有历史数据在手心里有底很多。这个课题后期还可以往两个方向扩展一是给无人机加上能量约束和动态飞行轨迹从单时隙静态优化升级成多时隙动态规划二是在地面基站和无人机之间引入协同缓存把热点内容提前推到边缘节点。任何一个方向做下去工作量都会上一个量级但对应的科研价值和实际应用价值也都更大。先把联合部署与调度这个主流程跑扎实后面扩展才站得住。