这个课题我前前后后做了大半年，组里讨论最多的问题就是：无人机在移动边缘计算里，到底是当空中基站用，还是当边缘服务器用。这两个身份对应的信道模型、能耗方程和约束条件完全不同，最后我们把落点放在了后者——多无人机携带边缘计算资源，在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. 最后说几点个人体会
这个项目最折磨人的不是算法推导，而是“联合”两个字。把部署模块和调度模块分开各自调通之后，一旦合并，数据传输、变量更新顺序、边界判断全都要重排。我的建议很明确——先固定无人机在用户簇质心，把调度模块完整跑通、画图、确认指标合理，再放开位置变量，用交替优化一点一点加。这样每一步都能确认新增的那块逻辑没有引入新问题。
另外，建议所有结果曲线都保存一次原始数据，不要只留图。后面改参数、换思路，需要重新对比时能直接调数据而不是重新跑一遍。仿真代码会在你改第三次模型时彻底变成另一个工程，有历史数据在手，心里有底很多。
这个课题后期还可以往两个方向扩展：一是给无人机加上能量约束和动态飞行轨迹，从单时隙静态优化升级成多时隙动态规划；二是在地面基站和无人机之间引入协同缓存，把热点内容提前推到边缘节点。任何一个方向做下去，工作量都会上一个量级，但对应的科研价值和实际应用价值也都更大。先把联合部署与调度这个主流程跑扎实，后面扩展才站得住。
