[文献阅读]联合任务卸载和资源分配的能量约束移动边缘计算[IEEE transactional mobile computing]

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档


一、摘要

考虑边缘节点能量约束的任务卸载和资源分配
为了维持终端用户满意的体验质量( Quality of Experience,QoE ),移动设备( Mobile Devices,MDs )可以根据分配的计算量(例如, CPU / GPU循环和存储)和无线资源(例如,带宽)将任务卸载到边缘服务器。任务卸载会导致额外的MEC能耗,这不可避免地违背了MEC的长期能量预算。
考虑到这两个挑战,我们提出了一个长期MEC能量约束下的在线联合卸载和资源分配( JORA )框架,旨在保证终端用户的QoE。为了实现这一点,我们利用李雅普诺夫优化来利用长期QoE最大化问题的最优性。通过构造能量赤字队列来引导能量消耗,可以实时地解决该问题。
在此基础上,我们提出了集中式分布式的在线JORA方法。此外,我们证明了我们提出的方法能够在满足长期MEC能量约束的情况下实现接近最优的性能。


二、现状问题

  1. 变化的计算配置:MEC计算配置需要根据不同时间段的任务计算需求进行调整。较大的计算配置可以提供满意的用户体验质量(QoE),但可能超出MEC能量预算限制。
  2. 网络带宽不足:将任务卸载到附近的边缘服务器时,带宽资源不足会导致较长的任务传输延迟。然而,为了任务卸载的数据传输,即使为移动设备(MDs)分配了大量带宽资源,边缘服务器的有限带宽资源可能也无法满足所有MDs的需求。
  3. 长期MEC能量约束:如果边缘服务器在当前时间段消耗过多的能量,将无法为后续时间段提供足够的能量。这种时间耦合的MEC能量约束要求我们了解未来的任务需求信息以维持卸载性能,但通常很难或几乎不可能获得这些信息。

三、研究框架

3.1 研究内容

移动设备与边缘服务器
操作时间线被离散化为持续时间为D的时间槽T = {0, …, T-1}。这个持续时间与任务卸载和资源分配的更新时间尺度相匹配。图1展示了一个由以下两个层级组成的边缘计算生态系统:MD层和边缘服务器层。

  • 边缘服务器(Edge Server)层:边缘服务器的位置固定在地面上,当MD设备在边缘服务器的通信范围内时,边缘服务器m可以为MD设备提供卸载服务。由于MD设备的移动性,每个边缘服务器可能在不同的时间槽为不同的MD设备提供服务。
  • MD(移动设备)层:每个设备在每个时间槽生成一个计算密集型任务,可以在MD设备上本地执行,也可以卸载到附近的边缘服务器上。
    研究的两个问题
    此外,任务卸载需要满足长期MEC能量预算Ebgt_m。在长期MEC能量约束下
  1. i)任务卸载问题:应该将哪些任务从MD设备卸载到边缘服务器上?
  2. ii) 资源分配问题:应该从边缘服务器向任务分配多少资源?

3.2 研究框架

研究框架

  • JORA:已知任务所有信息,包含任务、计算、通信三个子模型 【非凸,实际不可解】
  • Online JORA:使用李雅普诺夫模拟能量亏空队列【实时性】
  • JORA-中心式:在已知各移动设备当前任务信息,采用马尔可夫状态转移概率计算最优函数
  • JORA-分布式:将各移动设备视为非合作信息不对称式博弈

3.3 模型介绍

3.3.1 JORA

  • Task Model(任务模型):主要考虑任务的计算需求和数据量。
    目标:通过合理的任务卸载和资源分配,满足任务的计算需求和数据传输需求,以提高用户体验质量(QoE)。
  • Computation Model(计算模型):主要考虑计算资源的分配和配置。
    目标:通过合理的计算资源分配和配置,满足任务的计算需求,提高任务的处理效率和性能。
  • Communication Model(通信模型):主要考虑带宽资源的分配和配置。根据任务的数据量和传输需求。
    目标:减少任务传输延迟,确保任务及时完成。

3.3.2 Online JORA

论文针对长期的MEC能源约束,旨在保证最终用户的QoE。利用Lyapunov优化方法来探索长期QoE最大化问题的最优解。通过构建能量亏空队列来引导能量消耗,可以实时地解决这个问题。
在这里插入图片描述

3.3.3 JORA-中心式

在这里插入图片描述
JORA-C通过计算每个策略的效用函数值,并根据转移概率选择最优策略,以最大化系统的效用函数值。JORA-C的目标是在满足长期移动边缘计算的能量约束条件下,实现任务卸载和资源分配的最优性能。

李亚普诺夫函数用于判定非线性系统的稳定性: 如果函数V : D — R 是一个连续可微分函数并且V(0) = 0 ,并且在集合 D - {0} 中有 V(x) > 0,x = 0 是渐近稳定的,非线性系统内部是稳定的。
在这里插入图片描述

3.3.4 JORA-分布式

在这里插入图片描述

JORA-D允许每个移动设备(MD)根据自身的利益进行任务卸载和资源分配决策。JORA-D的目标是在满足长期移动边缘计算的能量约束条件下,实现任务卸载和资源分配的最优性能。
候选策略集通过选择新策略进行更新,直到达到最优策略。如果分布式算法在Id次迭代后收敛。分布式算法的计算复杂度似乎与集中式算法相似。允许每个MD根据自身的利益进行决策,从而实现更快的收敛和更好的性能。
在这里插入图片描述
公式中的max f(Atd)和min f(Atc),分别表示由提议的分布式策略Atd和集中式策略Atc实现的最差和最优JORA解。较小的PoA意味着在最坏情况下的均衡状态下,即f(Atd),与集中优化的解即f(Atc)更接近。PoA的下限为1。


四、常见任务卸载和资源分配方法 总结

4.1 MEC 任务卸载方法

在这里插入图片描述

4.2 MEC 资源分配方法

在这里插入图片描述

提示:这里对文章进行总结:
首次阅读,如有错误,恳请批评指正,谢谢
参考文献:

  1. Joint Task Offloading and Resource Allocation for Energy-Constrained
    Mobile Edge Computing
  2. 移动边缘计算卸载技术综述
  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Transactional和synchronized是实现事务控制和同步的两种机制。 @Transactional是Spring框架提供的注解,用于实现事务控制。它通过AOP(面向切面编程)实现,在方法执行完成后才提交事务。而synchronized是Java关键字,用于实现同步。它可以确保同一个对象的同步方法或代码块在同一时间只能被一个线程执行,以避免多线程并发访问时的数据竞争问题。 然而,这两个机制不能一起使用,因为@Transactional注解事务是通过AOP实现的,而synchronized是通过锁机制实现的。当@Transactional注解的方法执行完成后才提交事务,而synchronized代码块是在一个事务内执行的。因此,如果在一个方法中同时使用@Transactional和synchronized,会出现第一个线程释放锁后但是事务还未提交,第二个线程就进入同步代码块获取到未提交的数据库数据的情况。这样可能会导致数据一致性的问题。所以,在使用事务控制和同步的时候,需要注意避免同时使用@Transactional和synchronized。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [关于@Transactional和synchronized使用的问题](https://blog.csdn.net/YXXXYX/article/details/127325870)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值