2025, Vol. 57
2. 山东浪潮科学研究院有限公司 山东 济南 250101;
3. 浪潮智慧科技有限公司 山东 济南 250101
2. Shandong Inspur Science Research Institute Co., Ltd, Jinan 250101, China;
3. Inspur Smart Technology Co., Ltd, Jinan 250101, China
随着5G人工智能时代的到来，新型网络业务不断出现，对算力的需求急剧增加，高算力和低时延的应用场景越来越多样化，其中包括物联网、车联网、云游戏、AR/VR等。在这种背景下，边缘计算的概念得以提出。边缘计算将算力和存储资源部署在网络边缘，为用户提供就近的云计算服务环境和能力。同时，随着万物互联愿景的进一步推进，联网终端和设备数量将以指数级速度增长。
算力需求和算力供给的飞速增长，使得算力供需之间的不平衡问题愈加凸显。特别是边缘计算节点，由于它们均是面向特定场景建设的，计算负载的潮汐效应往往更加明显。为更加高效地利用网络边缘的海量分布式计算资源，推动分布式边缘计算与网络的深度融合，云边端协同网络的概念被提出。通过云、边、端协同，利用计算能力强大的云服务器资源和低访问时延的边缘服务器资源，将计算从终端和云转移到边缘，实现算力下沉，提供更加合理、高效的端设备任务处理方案。同时，算力网络[1]旨在提供泛在网络连接和算力服务，并实现算力资源灵活调度。
作为云边端协同网络的关键技术，计算卸载具有重要的地位。资源有限的终端设备通常将自身任务卸载至云端以及边缘服务器，当前，关于计算卸载的研究工作主要以延迟最小化、能耗最小化和系统效用最大化等[2-5]作为优化目标，采用非线性规划、启发式算法、博弈论、马尔可夫决策过程(Markov decision process, MDP)和强化学习(reinforcement learning, RL)[6-8]等多种方法对任务卸载过程进行仿真建模，以制定最优卸载方案。但是不难发现，现有多数方案主要从仿真模拟算法的角度出发，而对具体系统场景下的设备算力与网络实时感知、任务灵活卸载等方面的技术研究较少。
在云边端协同网络环境中，计算卸载面临着一些挑战。首先，由于云边端设备广泛分布，实时感知算力和网络状态成为一大挑战；其次，由于云边端网络中节点算力、网络链路等信息动态变化，卸载策略需要具备灵活调整的能力；最后，如何有效地利用云边端网络状态信息来准确、高效地制定并执行计算卸载策略，同时构建协同系统具有重要意义。现阶段算力网络的落地主要关注提供透明化的云端服务，对端设备的泛在计算能力模式还处于概念探索阶段，这也制约了对云边端协同的更深入探讨。
针对上述问题，本文的主要贡献可归纳为以下三个方面。1) 提出了一个面向云边端协同网络的任务卸载框架FreeOffload，利用算力与网络状态感知功能和卸载策略执行功能，实现异构端设备任务的动态、灵活卸载。2) 基于eBPF技术，面向云边端协同网络，实现了对其状态的感知，提供了网络的资源表示、资源度量与通告等方案；面向异构端设备的任务卸载，可以根据网络实时拓扑信息，动态地调整卸载策略，实现云边端的负载均衡。3) 在实验方面，搭建了FreeOffload框架的原型系统，从算力感知、端设备任务卸载方案可行性，以及性能开销等角度进行了评估。结果表明，FreeOffload方案能够在引入较小开销的情况下高效地实现任务卸载。
1 相关工作 1.1 计算卸载云边端协同网络是云、边、端深度融合的新兴范式，以优势互补的方式放大云计算与边缘计算的价值。其中，计算卸载技术正呈现出从云计算卸载向边缘计算卸载方向发展的明显趋势。在这一背景下，文献[9]对边缘计算的计算任务卸载技术进行了研究，并从卸载决策、资源分配和系统实现三个方面进行了全面分析总结。文献[10]对移动边缘计算中的任务卸载进行了深入建模，将其视为一个以降低整体能耗为目标的优化问题，并基于此目标提出了一种基于群智能优化技术的高能效任务卸载算法。针对时延敏感的计算卸载问题，文献[11]综合考虑了用户对任务执行延迟的容忍度以及计算和通信约束下的网络状态，提出了一种集中式迭代重定向卸载算法，以提高计算卸载效用。文献[12]研究了云边端协同架构中具有任务依赖性的边缘计算卸载策略，将该问题形式化为混合整数优化问题，最小化所有物联网设备的平均能耗和时间延迟，所提算法利用任务优先级队列和基于深度强化学习的方法来获得有效的计算卸载策略。文献[13]探索了基于区块链的计算卸载方法，利用区块链技术确保任务卸载过程中的数据完整性。
1.2 eBPF技术及其应用eBPF[14]是一种可以在Linux内核中运行用户程序，而不需要修改内核代码或加载内核模块的技术，具有全覆盖、无侵入、可编程的技术特点，在网络优化、安全监控、性能监控等场景中有着广泛应用。文献[15]基于eBPF实现了一种开源网络，在Linux内核动态插入网络控制逻辑，提供了网络互通、服务负载均衡等解决方案。文献[16]则从嵌入式物联网设备固件热修复的角度出发，利用eBPF虚拟机的高效性与安全性来执行漏洞补丁代码，对实时系统进行修复。
针对云边端网络中节点算力变化大、链路状态波动性强等特点带来的实时感知困难问题，本文选择利用eBPF技术具备的系统观测能力强、额外运行开销低、限制执行等特性，进行网络中节点算力状态、网络链接等信息的收集与度量，并将用户态eBPF虚拟机改造为灵活、易于使用、与操作系统无关的第三方库(e虚拟机)，用于异构嵌入式设备的任务卸载策略执行。本文重点关注改变嵌入式端设备的计算卸载行为，以实现灵活、可配置的任务卸载。
2 FreeOffload框架设计 2.1 概览在云边端协同网络中，一体化已成为重要的发展趋势。基于云边协同，将终端设备的服务作为边缘节点的负载。通过控制边缘节点、云端影响终端来实现三者的协同。
围绕前文所讨论的算力与网络状态感知和端设备任务卸载等问题，本文提出了FreeOffLoad框架，其主要包括基于eBPF的算力与网络状态实时感知模块和异构端设备任务灵活卸载策略执行模块两部分，整体框架如图 1所示。
|
图 1 FreeOffload方案整体框架 Fig. 1 The architecture of FreeOffload |
FreeOffload框架首先利用eBPF技术在云端和边缘节点上进行Linux内核函数跟踪，以收集网络信息和算力信息。随后，基于所得数据构建算力资源拓扑图，用于表示计算资源状态与分布，其中具有计算能力的设备表示为节点，网络链路表示为边。基于该拓扑图，本文设计了计算资源和网络资源协同的负载均衡机制，可综合考虑用户需求，制定灵活的端设备任务实时卸载策略。在端侧，首先将任务卸载到边缘节点或者云端执行(如图 1中步骤①)，当出现资源负载不均衡或任务执行无法满足用户需求时，eBPF虚拟机执行由云端或者边缘节点下发的eBPF任务卸载策略代码(如图 1中步骤②)，以对用户透明的方式实现动态地将任务重新卸载到最合适的执行位置，从而匹配算力供给与需求(如图 1中步骤③)，提升系统整体资源利用率。
2.2 算力与网络状态感知模块 2.2.1 资源表示根据算力模型应当面向服务这一特征，本文提出面向任务处理能力的设备算力表示方案，即针对不同类型的任务请求，用于处理任务的同一设备的算力度量结果可能发生变化。考虑了不同任务请求下设备的算力度量具有差异性的计算模型才能够将任务合理分配到执行设备。
为了实现设备资源实时算力与任务执行能力的映射，本方案设计了两种类型的原子任务：CPU密集型原子任务和IO密集型原子任务。这两种类型的任务每隔一段时间就由端设备发送处理请求到其连接的边缘节点或云端服务器，待处理完成后将结果返回至端设备。在上述过程中，收集边缘节点的任务处理时延以及端设备、边缘节点之间的链路传输时延，用以评估边缘节点和云端节点为不同类型的端任务提供的计算能力，实现云边端协同网络中算力/网络延迟的面向服务映射。
2.2.2 资源度量与通告对云边端协同网络算力资源与网络状态进行标识和度量，将相关信息同步到系统是实现算力感知、构建算力资源拓扑图的重要途径。为此，FreeOffload开展了云边设备内核层面和网络拓扑层面的信息收集与聚合，如图 2所示。
|
图 2 基于eBPF的算力与网络状态感知 Fig. 2 eBPF-based perception of computing resources and network |
在内核信息采集方面，eBPF系统探针被无侵入式地部署在系统底层，用以采集云端与边缘节点的系统运行、资源状态、网络传输等信息。具体来说，主要使用kprobes、uprobes、tracepoints等类型的探针，收集包括CPU性能指标、内存性能指标、磁盘性能指标等关键算力信息。根据Linux网络协议栈结构，eBPF网络探针分别被设置在传输层、网络层、数据链路层等位置的hook点，对不同网络环境下的网络通信报文、带宽、平均响应时间等数据进行采集，以支持对云边端网络的链路关系与通信状态进行分析。值得注意的是，由于eBPF字节码的跨平台特性，该资源感知方案也是跨平台的。
在网络拓扑分析阶段，根据两种类型的eBPF探针采集的指标数据生成算力节点数据。利用网络流量进行关联分析与存储，进一步形成完整的节点间网络拓扑关系数据，构建出算力资源拓扑图。
如图 3所示，使用YAML格式的文件来进行算力资源拓扑图的表示。其主要由两部分组成：表示算力资源的节点与表示网络链路的边。对于节点，Name表示节点名称，ComputingPower表示该设备节点拥有的算力情况，包括CPU、Memory、Storage等方面，Security表示该设备是否具有任务运行时安全防护能力，Resource表示设备的资源使用/任务执行情况，Capability则表示设备的原子任务处理能力。对于边，StartNode表示起始边缘节点，EndNode表示终点边缘节点，BandWidth表示链路带宽，Latency表示原子任务时延。
|
图 3 YAML格式的算力资源拓扑图表示 Fig. 3 Topology of computing resources in YAML |
在云边端实验平台中，云端节点定期收集并更新所有其他节点的算力资源与网络链路信息，包括边缘节点与端设备节点。在边缘，将计算节点分组，并在组内设置“中心”节点，实时收集组内成员的算力与网络信息。当边缘节点进行端设备任务卸载策略制定时，首先查询组内是否具有满足需求的节点，若有则进行卸载，由组内“中心”节点向其他组或者云端进行查询，确定任务卸载的最终地址。
2.3 端设备任务重卸载模块 2.3.1 任务重卸载机制云边端协同网络整体状态的动态性对任务卸载提出了更高的要求，传统的静态任务卸载方案[12]无法实时地对这种变化进行观测，也无法对任务卸载策略进行动态调整，并重新设置任务的执行位置。因此，本文提出了一种适用于端设备的任务卸载功能更新方案，如图 4所示。
|
图 4 基于eBPF的端设备任务卸载执行方案 Fig. 4 eBPF-based task offloading scheme for end devices |
该方案中，可依据云边端网络中各节点的算力信息与链路状态，并基于eBPF框架编写端设备任务卸载策略代码，将任务卸载至合理的边缘节点或者云端，无须重启程序或系统。具体来说，使用语言编写自定义任务卸载策略，提供相应配置信息，再结合特定任务卸载程序的代码上下文，策略C代码将会被编译成字节码。在经过验证器的合法性验证之后，该代码将插桩到特定函数入口位置，从而在运行时改变端设备任务卸载行为。
为了实现任务策略动态执行的自动化，本文设计了两种eBPF策略代码的触发方式，包括固定代码触发和动态代码触发。
1) 固定代码触发。通过在函数入口插桩实现对函数执行流的拦截。在该框架内，函数入口hook点可以由设备厂商在开发固件的时候手工加入，也可以由开发者给出需要插桩的关键函数列表，然后通过在固件编译阶段插桩。hook点拦截成功后，会进入对应的处理函数，尝试执行策略代码。该方法适用于嵌入式实时系统和Linux系统。
2) 动态代码触发。针对嵌入式实时操作系统，可基于设备CPU所支持的硬件调试原语，用于实现函数执行流的拦截。当硬件调试寄存器中的地址匹配后，会触发一个硬件中断异常，由Debug Monitor对中断异常进行处理，将中断时的CPU寄存器状态压栈，然后加载策略代码。针对嵌入式Linux系统，采用PLT hook方式对端设备上任务卸载相关函数进行拦截，当目标函数被调用时，自定义函数将加载执行eBPF策略，从而改变端设备任务卸载行为。
2.3.2 卸载策略制定在云边端协同网络中，端设备和边缘节点的计算资源往往是有限的，而且计算能力通常各不相同。边缘节点上计算负载状况是动态变化的，致使负载不均衡现象时有发生。任务卸载策略优化是云边端协同网络中的重要问题。
本文对端设备上的任务进行建模，同时考虑了不同任务的处理需求定义了任务属性，包括是否安全敏感、是否紧急、完成任务所需的算力等。这些任务属性通过YAML格式表示，如图 5所示。如果一个任务是安全敏感的，就意味着它无法在不具备安全防护能力的边缘节点上执行；如果一个任务是紧急的，那么它应当尽量被安排在边缘节点上执行，而不是在云端执行；不同的任务类型影响着边缘节点上的算力资源建模，而任务的算力需求则决定着某一个节点能否承担该任务。
|
图 5 YAML格式的任务属性表示 Fig. 5 Task attributes in YAML |
根据上述对端设备任务属性的描述与分析，从用户的需求出发，考虑任务的安全敏感性和紧急程度，本文提出了任务卸载过程中的指导性策略，用于辅助任务卸载地址的选择。
1) 任务紧急且安全敏感时，首选有安全防护能力且处理能力强的边缘节点，次选云端节点。
2) 任务紧急但不安全敏感时，首选处理能力强的边缘节点，次选云端节点。
3) 任务不紧急但安全敏感时，选择云端节点，因为云端具有更强的防护能力。
4) 任务不紧急且不安全敏感时，选择可用的边缘节点，以最大化资源利用率。
结合面向用户需求的任务卸载策略和基于eBPF的算力资源拓扑图，可设计出端设备任务卸载目标节点选择算法，算法伪代码如下。
算法1 任务卸载目标节点选择算法。
输入：算力资源图CR-map，任务所在节点edgefrom，待卸载任务task。
输出：任务卸载目标节点nodetarget。
1) 解析task，获取Sensitive、Urgent、Demand等属性；
2) for node ∈ CR-map do
3) 根据任务类型Type更新node算力；
4) if node具备任务执行能力
5) 将node加入集合S；
6) end for
7) if Sensitive and Urgent
/*根据task属性设置卸载策略*/
8) for node ∈ S do
9) if node到edgefrom Latency更低
10) nodetarget←node
11) end for
12) else if Sensitive and not Urgent
13) nodetarget←云端
14) else if Urgent and not Sensitive
15) for node∈S do
16) if node到edgefrom Latency更低
17) nodetarget←node
18) end for
19) else
20) nodetarget←集合S中任意一个节点
3 原型实现与实验评估 3.1 原型实现本文实现了FreeOffload框架的原型，其中包括算力与网络状态感知模块和端设备任务重卸载模块。把算力与网络状态感知模块部署到搭建的云边端实验测试平台中，并将任务重卸载模块作为系统模块集成到嵌入式Zephyr[17]操作系统与Linux操作系统中。在两个不同配置的设备(STM32F429和Raspberry Pi 3b)上，均运行了集成任务卸载模块后的系统，结果表明，这些设备上任务卸载模块的所有功能均可以正常使用。
3.2 实验评估本节从云边端协同网络状态感知方案的可行性、FreeOffload重卸载方案的可用性、性能开销三个方面展开了实验评估。实验环境方面，搭建了由单个云服务器节点、四个边缘计算节点，以及两个终端设备组成的测试系统，其中边缘节点使用定制化虚拟机进行模拟，终端设备分别与边缘节点和云节点相连。具体的硬件配置及相关软件版本如表 1所示。
|
表 1 实验环境配置 Tab. 1 Experiment environment |
算力资源表示方案是面向服务的，不同的任务类型意味着整个云边端协同网络系统不同的状态，因此先给出一般情况下不同类型的任务处理请求示例，然后应用状态感知模块的功能进行算力度量与建模，最后观测云边端协同网络中节点算力状态信息变化。
鉴于在云边端协同网络相关工作中并未有标准的真实任务数据集，于是选取视频格式转换、web请求等作为实验任务，并划分为CPU密集型和IO密集型，如表 2所示。
|
|
表 2 不同类型的卸载任务 Tab. 2 Different offloaded tasks |
根据算力与网络状态感知方案章节描述的方法，在不同类型任务的情况下对云边端协同网络进行节点算力建模，实验结果如图 6所示。
|
图 6 不同任务下的设备相对算力表示 Fig. 6 Representation of the relative device computing resources with different tasks |
可以看到，在云边端协同网络中，当端设备需要处理不同的任务时，不论是云、边还是端，提供的算力都在不断地变化，且与任务类型呈现出较强的相关性，CPU频率较高的设备更适合处理CPU密集型任务，而RAM较大的设备处理IO密集型任务更有优势。
3.2.2 卸载方案可行性分析1) 代码编写难度。在FreeOffload框架下编写卸载策略代码是容易的，因为eBPF是类C的代码，而嵌入式物联网设备的操作系统(包括以Linux为代表的分时操作系统和以Zephyr OS为代表的实时操作系统)和其使用的开源第三方库通常均由C语言实现。此外，编写策略代码时开发者无须关心具体的二进制固件或程序信息，只要分析算力资源实时情况和相关程序源码，然后在源码层面编写额外的替换代码逻辑即可。嵌入式物联网设备使用的数据传输协议多种多样，本文选择了具有代表性的协议类型，将这些协议的名称、功能、协议实现程序/代码、策略代码行数等信息整理在表 3中。从表 3中可以看出，这些协议均可以通过不超过50行的eBPF策略代码来完成connect类型函数的hook，任务卸载策略代码编写难度较小。
|
|
表 3 不同数据传输协议及策略代码长度 Tab. 3 Different data transmission protocols |
2) 卸载方案有效性。通过不断增加边缘节点1(简记为edge1，其余类似)上的任务负载(类型为任务1)，并将这些任务属性设置为安全敏感的(只有节点edge1和edge3是具有安全防护能力)，然后观测云边端协同网络中边缘节点与云端服务器的CPU利用率变化情况，可以测试出本文所提出的FreeOffload方案的可行性。由图 7可知，随着edge1的工作负载数量不断增加，CPU利用率不断上升。当达到设定的任务重卸载策略触发临界点时(CPU利用率70%)，edge1将辅助下发端设备任务卸载策略以减轻设备运行压力。由于这些任务是安全敏感的，所以edge2与edge4不能被用于执行任务，只有云端服务器和edge3能够作为任务卸载目的地。又因为edge3节点本身运行压力较小，算力资源丰富，所以根据提出的任务卸载目标节点选择算法，节点edge1上的任务不需要交由云端执行。因此，可以观测到只有边缘节点edge3的CPU利用率发生了明显上升，符合预期。这说明边缘节点edge1能够感知自身工作负载与周围算力资源情况，利用FreeOffload框架将端设备任务处理调整到其他合适的边缘节点，从而使负载均衡化。
|
图 7 云边网络中节点CPU变化情况 Fig. 7 CPU variation in nodes of the cloud-edge network |
1) eBPF资源监测高效性测试。在Linux系统资源感知方面，比较受欢迎的工具有sar、collectl等，因此可将本文实现的基于eBPF的资源感知方案与之做对比，以体现eBPF在资源感知方面的性能优势。从表 4中可以看到，传统的监测工具通常在用户态运行，在长时间对系统资源进行监控的情况下，引入更多的上下文切换和系统调用会导致相对较高的开销。而eBPF程序在内核中执行，减少了用户态和内核态之间的频繁切换，在监测30 min的情况下，系统调用数量分别是collectl与sar的41.5%、26.0%。
|
|
表 4 不同资源感知方案下的系统调用数量比较 Tab. 4 Comparison of system call numbers for different resource-aware schemes |
2) 策略代码执行给应用程序带来的开销。为了直观呈现启用FreeOffload卸载给应用程序造成的延迟，在Linux系统上用视频格式转换任务(任务1)和web访问请求任务(任务4)进行端到端的应用测试。
具体应用场景与卸载方案可行性相同，但是这里关注的目标是在卸载不同类型任务的情况下，对比是否使用FreeOffload框架对端设备任务发送造成时延，结果如图 8所示。
|
图 8 FreeOffload框架对设备任务发送造成的时延 Fig. 8 Latency caused by FreeOffload framework on device task transmission |
当任务较为复杂时，应用FreeOffload方案会给设备的任务发送带来10%~20%的开销，而在任务相对简单时，FreeOffload的开销一般低于10%，这在对应的任务场景下是完全可以接受的。
3) FreeOffload框架下的任务卸载方案高效性。为了测试启用FreeOffload方案后对云边端协同网络中端设备任务处理效率的影响，可将本文方案与传统边缘计算任务卸载策略进行比较，测量在不同调度策略下的任务执行时间，包括从任务发起到任务执行结果返回。其中，本地处理策略指由端节点处理所有任务，而贪婪处理策略指端节点随机选择有处理能力的节点执行任务。
如图 9所示，以音频处理任务(任务2，属性设置为紧急且安全敏感)为例，实验测试了在不同的任务卸载策略下，端节点1上的任务执行时间变化与分布情况，可以看出，本地处理策略在任务数量较少时，执行时间较短，而随着任务数量的增加，由于设备自身计算资源不足，执行时间变长；使用贪婪处理策略时，遍历云边端协同网络中的节点以寻找有处理能力的节点进行计算，与本地处理策略相比，能够在一定程度上减少任务执行时间，但是由于任务属性的要求，仍然需要消耗大量时间在寻找处理节点上；而本文提出的FreeOffload方案，在算力资源感知能力的加持下，能够为任务快速准确地选择处理节点，从而极大地降低任务执行时间，提高计算效率。
|
图 9 任务卸载策略对任务执行时间的影响 Fig. 9 Impact of strategies on task execution time |
本文提出了面向云边端协同网络的eBPF赋能任务卸载方案FreeOffload，能够帮助实现云边端协同网络中端设备任务的灵活、可配置式卸载，有利于边缘节点和云计算任务的负载均衡，提高整个系统的资源利用率。其中，算力与网络状态感知模块利用eBPF技术，实现了资源表示、资源度量与通告等关键功能；端设备任务重卸载模块根据算力与网络信息变化动态调整卸载策略，弥补了云边端协同网络中异构端设备任务卸载策略固化的不足，实现了云边端设备的负载均衡。通过原型实现与实验环境搭建，证明了FreeOffload方案的可行性，能够在引入较小开销的情况下灵活、高效地实现任务卸载。
在未来的工作中，鉴于算力网络相关技术的发展，研究本文方案在云网融合、计算调度等方面任务卸载的应用将会具有一定的价值。
| [1] |
何涛, 杨振东, 曹畅, 等. 算力网络发展中的若干关键技术问题分析[J]. 电信科学, 2022, 38(6): 62-70. HE T, YANG Z D, CAO C, et al. Analysis of some key technical problems in the development of computing power network[J]. Telecommunications science, 2022, 38(6): 62-70. (  0) |
| [2] |
CHEN Y, ZHANG N, ZHANG Y C, et al. Energy efficient dynamic offloading in mobile edge computing for Internet of Things[J]. IEEE transactions on cloud computing, 2021, 9(3): 1050-1060. DOI:10.1109/TCC.2019.2898657 ( 0) |
| [3] |
QU G J, WU H M, LI R D, et al. DMRO: a deep meta reinforcement learning-based task offloading framework for edge-cloud computing[J]. IEEE transactions on network and service management, 2021, 18(3): 3448-3459. DOI:10.1109/TNSM.2021.3087258 ( 0) |
| [4] |
赵梦远, 郝万明, 杨守义, 等. 多用户多边缘的公平卸载及优化策略研究[J]. 郑州大学学报(理学版), 2022, 54(5): 16-21. ZHAO M Y, HAO W M, YANG S Y, et al. Research on multi-edge fair offloading and optimization strategy for multi-user[J]. Journal of Zhengzhou university (natural science edition), 2022, 54(5): 16-21. DOI:10.13705/j.issn.1671-6841.2021391 ( 0) |
| [5] |
张秋平, 孙胜, 刘敏, 等. 面向多边缘设备协作的任务卸载和服务缓存在线联合优化机制[J]. 计算机研究与发展, 2021, 58(6): 1318-1339. ZHANG Q P, SUN S, LIU M, et al. Online joint optimization mechanism of task offloading and service caching for multi-edge device collaboration[J]. Journal of computer research and development, 2021, 58(6): 1318-1339. ( 0) |
| [6] |
LI Y, ZHANG X, SUN Y K, et al. Joint offloading and resource allocation with partial information for multi-user edge computing[C]//2022 IEEE Globecom Workshops. Piscataway: IEEE Press, 2022: 1736-1741.
( 0) |
| [7] |
XIONG X, ZHENG K, LEI L, et al. Resource allocation based on deep reinforcement learning in IoT edge computing[J]. IEEE journal on selected areas in communications, 2020, 38(6): 1133-1146. DOI:10.1109/JSAC.2020.2986615 ( 0) |
| [8] |
BAEK J, KADDOUM G. Heterogeneous task offloading and resource allocations via deep recurrent reinforcement learning in partial observable multifog networks[J]. IEEE Internet of Things journal, 2021, 8(2): 1041-1056. DOI:10.1109/JIOT.2020.3009540 ( 0) |
| [9] |
谢人超, 廉晓飞, 贾庆民, 等. 移动边缘计算卸载技术综述[J]. 通信学报, 2018, 39(11): 138-155. XIE R C, LIAN X F, JIA Q M, et al. Survey on computation offloading in mobile edge computing[J]. Journal on communications, 2018, 39(11): 138-155. ( 0) |
| [10] |
MAHENGE M P J, LI C L, SANGA C A. Energy-efficient task offloading strategy in mobile edge computing for resource-intensive mobile applications[J]. Digital communications and networks, 2022, 8(6): 1048-1058. DOI:10.1016/j.dcan.2022.04.001 ( 0) |
| [11] |
WANG M Z, WU T, MA T, et al. Users′ experience matter: Delay sensitivity-aware computation offloading in mobile edge computing[J]. Digital communications and networks, 2022, 8(6): 955-963. DOI:10.1016/j.dcan.2022.08.005 ( 0) |
| [12] |
TANG T T, LI C, LIU F G. Collaborative cloud-edge-end task offloading with task dependency based on deep reinforcement learning[J]. Computer communications, 2023, 209: 78-90. DOI:10.1016/j.comcom.2023.06.021 ( 0) |
| [13] |
XU X L, ZHANG X Y, GAO H H, et al. BeCome: blockchain-enabled computation offloading for IoT in mobile edge computing[J]. IEEE transactions on industrial informatics, 2020, 16(6): 4187-4195. ( 0) |
| [14] |
STAROVOITOV A. Net: filter: rework/optimize internal BPF interpreter′s instruction set[EB/OL]. (2014-03-28)[2023-04-10]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8.
( 0) |
| [15] |
ISOVALENT. Cilium GitHub repository[EB/OL]. (2023-03-17)[2023-04-10]. https://github.com/cilium/cilium.
( 0) |
| [16] |
HE Y, ZOU Z H, SUN K, et al. rapidpatch: firmware hotpatching for real-time embedded devices[C]//31st USENIX Security Symposium. Boston: USENIX Association, 2022: 2225-2242.
( 0) |
| [17] |
Zephyr. A proven RTOS ecosystem, by developers, for developers[EB/OL]. (2023-02-19)[2023-04-10].https://zephyrproject.org/.
( 0) |
| [18] |
FFmpeg. A complete, cross-platform solution to record, convert and stream audio and video[EB/OL].(2022-05-14)[2023-04-10].https://ffmpeg.org/.
( 0) |
| [19] |
EasyDarwin. Open source, high performance, industrial rtsp streaming server[EB/OL]. (2017-03-07)[2023-04-10].https://github.com/EasyDarwin/EasyDarwin/.
( 0) |