论文笔记：一种云边协同计算模型

文章来源：2019 IEEE Transactions on Industrial Information 下载链接在这里

注：本文描述过程中的中继节点=边缘节点

云-边协同计算模型

这篇文章考虑了一个两跳的网络框架，从边缘移动设备（Mobile Device) 经过一跳，到达中继节点（Relay)，再经过一跳可以到达计算接入终端（Computational Access Points)

这篇文章考虑了K个中继节点（具有一定的计算能力，也可以认为是边缘节点），M个云端计算终端。当边缘节点的计算资源不足时，边缘节点就可以接入云端来获得更充足的计算资源。论文认为每个任务都包含 L bits 的数据，根据data-partition model in 这篇文章 ，也就是把一个任务分解成了N个独立的子任务。

整个计算过程建模如下：移动设备首先给中继节点发送任务，中继将任务分解成N个子任务，或者依据某些负载策略继续向CAP发送

以第k个relay节点与第m个CAP为例，根据香农定理可以得知从MD到第k个中继节点的数据传输率，也就是公式（1)

其中B指的第一跳网络中的带宽，P_D指的是发送功率，信道增益服从一个正态分布，环境噪声被认为是高斯白噪声，这样就可以得到传输时延与传输所消耗的能量。传输时延是L bits 与传输率的比值，而传输能耗就是传输时间乘以发送功率。

当中继节点收到任务后，他会将任务分成N个子任务。每个子任务的数据量大小是l_n，用x_nm来表示第n个子任务是否被分配到第m个CAP上。这可以视为一个任务是否在边缘节点被完成处理的指示。

作者构建了一个矩阵X来表示任务卸载策略，这个矩阵的维度是N×（M+1），m=0代表的是任务在边缘端已经完全被处理。但是为了更加有效地利用计算资源，每个子任务都只能被一个计算节点所计算，也就是该矩阵中的每一行，只有一个元素为1

接下来是计算时延模型与计算耗能模型，分为两种情况，一种是完全在边缘段处理，即完全被第k个中继所计算：

如果是完全在边缘段处理，则有:

计算时间是CPU计算单个字节需要的cycle数目乘以单个任务的字节数云模型计算，再除以CPU-cycle的频率（多少cycle/s），得到总的计算时间。计算耗能则是这个时间乘以一个定义为单位时间耗能的常量。

另一种情况是子任务被分发到云端处理，模型建立如下:

首先考虑的仍然是数据传输速率，运用香农公式，可得式（8),B_n代表的是分配到子任务n的带宽，下标的含义是第二跳网络中，第k个中继节点向第m个CAP卸载的第n个子任务。

所有的子任务的带宽和是固定的，也就是说，一个task被分配到的带宽是有限的。

与第一条网络定义的传输时延与传输功耗类似，定义了第二跳网络的传输时延与功耗如公式（10）,（11)

由于云端计算节点电力十足,不考虑能耗!所以不考虑其计算能耗，只考虑其计算时延，可以类似公式(6)定义云端的计算时延，与边缘段不同的地方在于云端的CPU-cycle frequency不同。

对于在CAP中的第m个计算节点完成所分配任务的总体时延，分类讨论为m=0与m≠0两种情况。即：

所有子任务中在边缘节点进行计算的计算时延+其余子任务第二跳的传输时延+其余子任务在云端的计算时延

这个模型中，不同的CAP收到的子任务数可能是不同的，但是不同的子任务必须是一个接一个到来的，也就是公式(12)中的各个子任务的传输时延与云端计算时延之和。同时，作者考虑了并行计算的情况，也就是最后完成所分配任务的云端CAP所导致的时延才是从中继节点到云端节点的总的时延T_RA

从中继节点到云端节点的整个功耗包括在中继处理子任务的功耗+第二跳传输功耗

模型的cost/objective function是时延与功耗的一个线性函数，λ是一个用于调整权重的参数，建立出来的优化问题如下：

之后作者把这个问题分成了三个子问题去解，我在之后的学习中会写，这篇笔记关注这个文章的模型。

（编辑：成都站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!