节点资源的分配

申请号 CN201980097181.5 申请日 2019-06-07 公开(公告)号 CN113906716A 公开(公告)日 2022-01-07
申请人 瑞典爱立信有限公司; 发明人 阿林达姆·班纳吉; 萨拉瓦南·M;
摘要 公开了一种用于分配雾 节点 的资源的方法(300),其中雾节点被组织成至少一个雾网络。该方法包括:从客户端节点接收 请求 (332);识别用于实现请求的要求(334);确定用于实现请求的客户端节点的 位置 (336);以及根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群(338)。该方法还包括通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化(340)。还公开了一种 控制器 和 计算机程序 产品,其被配置为当在计算机上运行时执行用于分配雾节点的资源的方法。
权利要求

1.一种用于分配雾节点的资源的方法(300),其中,所述雾节点被组织成至少一个雾网络;所述方法包括:
从客户端节点接收请求(332);
识别用于实现所述请求的要求(334);
确定用于实现所述请求的所述客户端节点的位置(336);
根据所识别的要求和所确定的位置,识别能够操作用于实现所述请求的雾节点集群(338);以及
通过使以下至少一个最小化而从所识别的集群中选择其资源要被分配以实现所述请求的雾节点(340):
实现所述请求所需的集群的数量;
实现由所述雾节点接收的请求的总时间;
未实现的由所述雾节点接收的请求的数量。
2.根据权利要求1所述的方法,其中,识别用于实现所述请求的要求包括:
识别所述请求的主要服务,其中,所述主要服务包括由至少一个雾节点提供的实现所述请求所必需的服务(434a);以及
识别能够操作用于提供所述请求的所述主要服务的雾节点(434a)。
3.根据权利要求2所述的方法,其中,识别用于实现所述请求的要求还包括:
识别能够操作用于提供所述请求的次要服务的雾节点,其中,次要服务包括由至少一个雾节点提供的与所述请求的主要服务相关联的服务(434b)。
4.根据权利要求3所述的方法,其中,识别能够操作用于提供所述请求的次要服务的雾节点包括:
识别包含在与所识别的能够操作用于提供所述请求的主要服务的雾节点相同的匹配邻域内的雾节点(434b);
其中,匹配邻域包括根据以下至少一项进行相关的多个雾节点:
其提供的服务的服务请求模式;
其提供的服务的趋势变化模式。
5.根据前述权利要求中任一项所述的方法,其中,确定用于实现所述请求的所述客户端节点的位置包括:
基于环境内的所述客户端节点的历史位置数据估计所述客户端节点的轨迹(436a)。
6.根据前述权利要求中任一项所述的方法,其中,确定用于实现所述请求的所述客户端节点的位置包括:
将所述环境建模为位置图,所述位置图包括表示所述环境内的航路点顶点和表示所述航路点之间的合法路径的边(436a)。
7.根据前述权利要求中任一项所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群包括:
生成包括如下雾节点的至少一个集群(438a):
能够操作用于至少部分地实现所述请求;
在特定时间点在彼此的阈值距离内;并且
能够操作用于彼此协作。
8.根据从属于权利要求至4中任一项时的权利要求7所述的方法,其中,能够操作用于至少部分地实现所述请求的雾节点包括:被识别为能够操作用于提供所述请求的主要或次要服务的雾节点。
9.根据权利要求7或8所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群还包括:
识别在所述客户端节点的阈值距离内的生成集群(438b);以及
基于所确定的位置和用于实现所述请求的时间段,确定所识别的生成集群是否能够实现所述请求(438c)。
10.根据权利要求9所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群还包括:
如果所识别的生成集群不能实现所述请求,则生成新的集群来实现所述请求(438d)。
11.根据权利要求7至10中任一项所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群还包括:
建立集群组,其中,集群组包括能够操作用于协作的多个集群,使得它们形成服务提供链(438e)。
12.根据权利要求7至11中任一项所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群还包括:
对所述集群执行密度度量(438f);以及
解除低于密度阈值的集群(438g)。
13.根据权利要求7至12中任一项所述的方法,其中,根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群还包括:
更新一个或多个生成集群(438h)。
14.根据前述权利要求中任一项所述的方法,其中,从所识别的集群中选择其资源要被分配以实现所述请求的雾节点包括:计算使表示以下至少一个的项的加权和最小化的目标函数(440):
实现所述请求所需的集群的数量;
实现由所述雾节点接收的请求的总时间;
未实现的由所述雾节点接收的请求的数量。
15.根据权利要求14所述的方法,其中,所述目标函数包括:
min w1∑k∈K∑e∈Edxycxy+w2∑k∈K(Tk∈K‑ak‑τk)+w3∑r∈Rdr
其中:
K是包括所述雾节点的服务提供商集合;
E是表示环境中航路点之间的合法路径的边集合;
dxy是客户端节点x与雾节点y之间的沿边的距离;
cxv是客户端节点x和雾节点y在N跳内相遇的概率;
T是指示客户端节点x到达雾节点k所花费的时间量的非负整数;
ak是雾节点k提供服务的时间窗口的开始时间;
τk是客户端节点到达雾节点k与从雾节点k接收服务之间的等待时间;
R是表示雾节点提供的最小服务数量的非负整数;以及
dr是指示服务请求的资源是否已被成功地分配的二元决策变量。
16.根据前述权利要求中任一项所述的方法,还包括:
发起对所选择的雾节点的资源的分配以实现所接收的请求(442)。
17.根据前述权利要求中任一项所述的方法,还包括:
发起对所选择的雾节点的有关信息的高速缓存(444)。
18.根据前述权利要求中任一项所述的方法,还包括:
由所选择的雾节点实现所接收的请求(446)。
19.根据前述权利要求中任一项所述的方法,还包括:
注册新的雾节点(402);以及
将由所述雾节点提供的服务与由其他雾节点提供的相应服务相关联(404)。
20.根据权利要求19所述的方法,其中,将由所述雾节点提供的服务与由其他雾节点提供的相应服务相关联包括:
从服务元数据中提取所述服务的有关信息(404a);
计算所提取的信息与从其他雾节点提供的服务的元数据中提取的信息之间的相似性度量(404b);
将所述服务与由其他雾节点提供的与所述服务的相似性得分最高的服务相关联(404c)。
21.根据权利要求19或20所述的方法,还包括:
为相关联的服务分配密钥并且生成将所分配的密钥映射到由雾节点提供的相关联的服务的散列映射(406)。
22.根据权利要求19至21中任一项所述的方法,还包括:
生成注册雾节点图,其中,顶点表示雾节点,并且其中,顶点通过以下至少一项连接(416):
表示雾节点之间的物理拓扑连接的位置边;
连接提供相同服务的雾节点的服务边;
连接提供相关服务的雾节点的服务联盟边。
23.根据权利要求22所述的方法,还包括:
检测由雾节点提供的服务之间的服务请求模式(410);
检测由雾节点提供的服务之间的趋势变化模式(412);以及
基于检测到的服务请求模式和趋势变化模式,在所述注册雾节点图中生成服务联盟边(414)。
24.根据权利要求23所述的方法,还包括:根据检测到的服务请求模式和趋势变化模式对所生成的服务联盟边进行加权(414)。
25.根据权利要求24所述的方法,还包括:基于施加到雾节点之间的服务联盟边的权重,将雾节点关联到匹配邻域中(418)。
26.根据前述权利要求中任一项所述的方法,还包括:
注册新的客户端节点(420);
监测注册客户端节点的位置(422);以及
从监测位置获知环境内的与注册客户端节点相关联的至少一个轨迹(424)。
27.根据前述权利要求中任一项所述的方法,还包括:
将雾节点位于其中的环境建模为位置图,所述位置图包括表示所述环境内的航路点的顶点和表示所述航路点之间的合法路径的边(426)。
28.根据权利要求27所述的方法,还包括:
生成建模环境的连通性矩阵,所述连通性矩阵表示所述环境的合法路径之间的连通性(428)。
29.根据权利要求27或28所述的方法,还包括:
生成建模环境的路径类型矩阵,所述路径类型矩阵表示所述环境中的所述合法路径的分配类型(428)。
30.根据权利要求27至29中任一项所述的方法,还包括:
生成建模环境的航路点维度矩阵,所述航路点维度矩阵表示穿过所述环境在每个航路点处相遇的合法路径的数量(428)。
31.根据权利要求27至30中任一项所述的方法,还包括:
将建模环境划分为多个区域;以及
将建模环境的区域分配给所述区域内的雾节点(430)。
32.一种包括指令的计算机程序,所述指令当在至少一个处理器上执行时,使所述至少一个处理器执行根据前述权利要求中任一项所述的方法。
33.一种包含根据权利要求32所述的计算机程序的载体,其中,所述载体包括电子信号、光学信号、无线电信号或计算机可读存储介质之一。
34.一种计算机程序产品,包括其上存储有根据权利要求32所述的计算机程序的非暂时性计算机可读介质。
35.一种用于分配雾节点的资源的控制器(500),其中,所述雾节点被组织成至少一个雾网络,所述控制器包括处理器(502)和存储器(504),所述存储器(504)包含能够由所述处理器(502)执行的指令,使得所述控制器能够操作用于:
从客户端节点接收请求;
识别用于实现所述请求的要求;
确定用于实现所述请求的所述客户端节点的位置;
根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群;以及
通过使以下至少一个最小化而从所识别的集群中选择其资源要被分配以实现所述请求的雾节点:
实现所述请求所需的集群的数量;
实现由所述雾节点接收的请求的总时间;
未实现的由所述雾节点接收的请求的数量。
36.根据权利要求35所述的控制器,其中,所述控制器还能够操作用于执行根据权利要求2至31中任一项所述的方法。
37.一种用于分配雾节点的资源的控制器,其中,所述雾节点被组织成至少一个雾网络,所述控制器被适配为:
从客户端节点接收请求;
识别用于实现所述请求的要求;
确定用于实现所述请求的所述客户端节点的位置;
根据所识别的要求和所确定的位置识别能够操作用于实现所述请求的雾节点集群;以及
通过使以下至少一个最小化而从所识别的集群中选择其资源要被分配以实现所述请求的雾节点:
实现所述请求所需的集群的数量;
实现由所述雾节点接收的请求的总时间;
未实现的由所述雾节点接收的请求的数量。
38.根据权利要求37所述的控制器,其中,所述控制器还被适配为执行根据权利要求2至31中任一项所述的方法。

说明书全文

节点资源的分配

技术领域

[0001] 本公开涉及一种用于分配雾节点的资源的方法,其中雾节点被组织成至少一个雾网络。本公开还涉及一种控制器以及一种计算机程序和一种计算机程序产品,其被配置为当在计算机上运行时执行用于分配雾节点的资源的方法。

背景技术

[0002] 雾计算是指计算向网络边缘的扩展,其便于终端设备与云计算数据中心之间的计算、存储和联网服务的操作。因此,雾计算可以被认为是云计算的补充,并且被预测为有益于包括移动/可穿戴计算物联网(IoT)和大数据分析在内的不同领域。雾计算提供的一些优点包括减少等待时间、增加吞吐量、整合资源、节省能源以及增强安全性和隐私性。例如,在大数据分析中,在网络边缘处生成大量的数据。雾计算支持边缘分析,其可以减少大数据分析的延迟并且降低数据传输和存储的成本。
[0003] 雾计算可能是开发智能城市范式的关键组成部分,该范式设想使用信息和通信技术(ICT)开发、部署和促进可持续发展实践以便应对日益严峻的城市化挑战。该ICT框架的核心是由使用无线技术和云来传输数据的互联对象和机器组成的智能网络。基于云的IoT应用实时地接收、分析和管理数据以帮助市政当局、企业和公民做出更优的决策。传统的云计算体系结构无法满足这种规模上的庞大IoT部署的要求,因此,设想雾计算来解决包括以下各项在内的问题:等待时间、网络带宽保护、安全问题和操作可靠性、对不同环境条件的适应以及更接近于相关位置存储数据和采取决策的能。在一些情况下,接近于收集数据的设备分析数据的能力可以使解决时间问题和级联系统故障之间有所区别。不断增长的运输成本和处理速度也推动了雾计算的采用,其中计算能力分布在边缘网络、数据中心和公共云上。雾计算开始在智能城市、互联汽车、无人机和其他应用中开展。在雾计算环境中运行IoT应用的关键挑战是资源分配和任务调度。雾计算研究仍处于起步阶段,并且仍需要对映射到当前研究的雾基础设施、平台和应用的要求的基于分类的调查。
[0004] 应当理解,接近于IoT传感器数据被收集的位置分析IoT传感器数据具有以下优点:最小化等待时间;卸载来自核心网络的大量网络流量;以及在其被生成的网络内维护潜在敏感数据。由于IoT设备及其可用资源的多样性,资源在雾环境中是最动态和异构的。被称为雾设备的所有设备负责执行其自身的应用的计算。雾计算旨在使用任何雾设备上的可用空闲资源,使得雾计算相对于设备自身的应用总是处于第二优先地位。一般而言,可用于雾计算的资源量是动态的,但是可通过分析雾节点资源的长期活动来预测。该预测是有用的,因为在执行雾任务期间,执行该任务的雾节点的资源状态可能例如由于从雾节点负责的应用接收到请求而改变。这不同于云的情况,在云的情况下,可以知晓哪些资源当前可用以及它们是否专用于基于云的应用请求。因此,作为雾节点内动态协作的一部分的资源分配和调度比云中的资源分配和调度更具挑战性。
[0005] 雾计算的重要特征例如有低等待时间和位置感知、广泛的地理分布、移动性、紧密邻近的多个节点、无线接入的主导作用、流传输和实时应用的显著存在以及异构性。体现这些特征中的一些特征的一个示例用例是涉及以下四个雾网络的智能城市的情况:智能建筑物、智能运输、互联汽车和智能停车场。这些网络在图1所示的智能城市环境中可用。资源分配涉及选择和连接来自不同网络的不同雾节点以及使用其知识和资源执行任务。这样的任务可能包括通过考虑包括交通、可用停车场、约会的建筑物和楼层等各种因素决定约会的停车地点。
[0006] 雾计算体系结构是分级体系结构,其中,来自下层的数据级联到上层并且最终级联到最上面的云层,如图2所示。在南北和东西两个方向上都可以进行数据传输。在智能城市范式中可以存在多个云,这些云可以连接到唯一的或公共的雾节点以收集用于不同目的的数据。雾节点连接到包括传感器、执行器等IoT设备。在雾网络中可以存在由不同制造商开发的IoT设备和雾节点,并且不对它们收集的数据提供标准注释。由不同供应商提供的雾节点之间的语法、标记和操作的变化可能会使网络中的资源分配任务额外地复杂化。发明内容
[0007] 本公开的目的在于提供一种至少部分地解决上述一个或多个挑战的方法、装置和计算机可读介质。
[0008] 根据本公开的第一方面,提供了一种用于分配雾节点的资源的方法,其中雾节点被组织成至少一个雾网络。该方法包括:从客户端节点接收请求;识别用于实现请求的要求;以及确定用于实现请求的客户端节点的位置。该方法还包括:根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群;以及通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。
[0009] 根据本公开的示例,雾节点可以包括由开放雾联盟(Open Fog Consortium)提供的与雾计算相关的术语表中所定义的节点:“实现雾计算服务的允许其与其他雾节点互操作的物理和逻辑网络元件。雾节点可以是物理的、逻辑的或虚拟的雾节点,并且可以是嵌套的(例如,物理雾节点上的虚拟雾节点)”。由开放雾联盟发布的开放雾参考体系结构被包括在IEEE标准1934‑2018中。根据本公开的示例,雾节点可以是包括云层面和雾层面的通信网络的一部分。云层面可以包括一个或多个单独的云,雾层面可以包括一个或多个单独的雾网络。雾层面以及其中的一个、一些或所有雾网络可以包括一个或多个分级层,其例如包括地区、区域、本地和端点层。根据本公开的示例,雾节点之间的通信可以基于消息排队遥测传输(MQTT)协议。
[0010] 根据本公开的示例,可以在与客户端节点通信的雾节点处接收从客户端节点接收的请求。客户端节点可以连接到雾节点作为其一部分的通信网络。该请求可以指定需要提供一个或多个服务的任务。
[0011] 根据本公开的示例,识别用于实现请求的要求可以包括:识别请求的主要服务,其中主要服务包括由至少一个雾节点提供的实现请求所必需的服务;以及识别可操作用于提供请求的主要服务的雾节点。
[0012] 根据本公开的示例,识别要求的步骤可以包括:识别实现请求所必需的多个主要服务。
[0013] 根据本公开的示例,识别用于实现请求的要求还可以包括:识别可操作用于提供请求的次要服务的雾节点,其中次要服务包括由至少一个雾节点提供的与请求的主要服务相关联的服务。
[0014] 根据本公开的示例,识别可操作用于提供请求的次要服务的雾节点可以包括:识别包含在与所识别的可操作用于提供请求的主要服务的雾节点相同的匹配邻域内的雾节点。根据这样的示例,匹配邻域可以包括根据以下至少一项进行相关的多个雾节点:其提供的服务的服务请求模式和/或其提供的服务的趋势变化模式。
[0015] 根据本公开的示例,确定用于实现请求的客户端节点的位置可以包括:基于环境内的客户端节点的历史位置数据估计客户端节点的轨迹。
[0016] 根据本公开的示例,确定用于实现请求的客户端节点的位置可以包括:将环境建模为位置图,该位置图包括表示环境内的航路点顶点和表示航路点之间的合法路径的边。
[0017] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群可以包括:生成至少一个集群,该集群包括可操作用于至少部分地实现请求、在特定时间点在彼此的阈值距离内并且可操作用于彼此协作的雾节点。
[0018] 根据本公开的示例,可操作用于至少部分地实现请求的雾节点可以包括被识别为可操作用于提供请求的主要或次要服务的雾节点。
[0019] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群还可以包括:识别在客户端节点的阈值距离内的生成集群;以及基于所确定的位置和用于实现请求的时间段确定所识别的生成集群是否可以实现请求。
[0020] 根据本公开的示例,阈值可以是绝对的或相对的,即,它可以指定集群的参考位置在客户端节点的阈值距离内,或者它可以要求选择最接近的生成集群。
[0021] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群还可以包括:如果所识别的生成集群不能实现请求,则生成新的集群来实现请求。
[0022] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群还可以包括:建立集群组,其中集群组包括可操作用于协作的多个集群,使得它们形成服务提供链。
[0023] 根据本公开的示例,由于集群的动态性质以及其中的雾节点的可能移动性,该链可以确保跨特定地理区域和在特定时间段内提供服务。
[0024] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群还可以包括:对集群执行密度度量;以及解除低于密度阈值的集群。
[0025] 根据本公开的示例,根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群还可以包括:更新一个或多个生成集群。
[0026] 根据本公开的示例,还可以在更新集群之后更新组的建立。发明内容部分还将指示可以存储特定时间处的集群分布副本并且将其与时间戳相关联。
[0027] 根据本公开的示例,从所识别的集群中选择其资源要被分配以实现请求的雾节点可以包括:计算使表示以下至少一个的项的加权和最小化的目标函数:实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量。
[0028] 根据本公开的示例,该目标函数可以包括:
[0029] min w1∑k∈K∑e∈Edxycxy+w2∑k∈K(Tk∈K‑ak‑τk)+w3∑r∈Rdr
[0030] 其中:
[0031] K是包括雾节点的服务提供商集合;
[0032] E是表示环境中航路点之间的合法路径的边集合;
[0033] dxy是客户端节点x与雾节点y之间的沿边的距离;
[0034] cxy是客户端节点x和雾节点y在N跳内相遇的概率;
[0035] T是指示客户端节点x到达雾节点k所花费的时间量的非负整数;
[0036] ak是雾节点k提供服务的时间窗口的开始时间;
[0037] τk是客户端节点到达雾节点k与从雾节点k接收服务之间的等待时间;
[0038] R是表示雾节点提供的最小服务数量的非负整数;以及
[0039] dr是指示服务请求的资源是否已被成功地分配的二元决策变量。
[0040] 根据本公开的示例,服务提供商集合K还可以包括除雾节点之外的服务提供商,例如云服务提供商。
[0041] 根据本公开的示例,该方法还可以包括:发起所选择的雾节点的资源的分配以实现所接收的请求。
[0042] 根据本公开的示例,该方法还可以包括:发起对所选择的雾节点的有关信息的高速缓存。根据这样的示例,信息的高速缓存可以使得能够快速执行用于实现所接收的请求的服务。
[0043] 根据本公开的示例,该方法还可以包括:由所选择的雾节点实现所接收的请求。
[0044] 根据本公开的示例,该方法还可以包括:注册新的雾节点;以及将由该雾节点提供的服务与由其他雾节点提供的相应服务相关联。
[0045] 根据本公开的示例,将由雾节点提供的服务与由其他雾节点提供的相应服务相关联可以包括:从服务元数据中提取该服务的有关信息;计算所提取的信息与从由其他雾节点提供的服务元数据中提取的信息之间的相似性度量;以及将该服务与由其他雾节点提供的与该服务的相似性得分最高的服务相关联。
[0046] 根据本公开的示例,相似性得分的示例可以包括基于属性的相似性、结构相似性等。
[0047] 根据本公开的示例,该方法还可以包括:为相关联的服务分配密钥并且生成将所分配的密钥映射到由雾节点提供的相关联的服务的散列映射(hash map)。
[0048] 根据本公开的示例,该方法还可以包括:生成注册雾节点图,其中顶点表示雾节点并且其中顶点通过以下至少一项连接:表示雾节点之间的物理拓扑连接的位置边;连接提供相同服务的雾节点的服务边;和/或连接提供相关服务的雾节点的服务联盟边。
[0049] 根据本公开的示例,连接提供相同服务的雾节点的服务边可以是连接其服务被分配有相同密钥的雾节点的边。
[0050] 根据本公开的示例,该方法还可以包括:检测由雾节点提供的服务之间的服务请求模式;检测由雾节点提供的服务之间的趋势变化模式;以及基于检测到的服务请求模式和趋势变化模式在注册雾节点图中生成服务联盟边。
[0051] 根据本公开的示例,该方法还可以包括:根据检测到的服务请求模式和趋势变化模式对所生成的服务联盟边进行加权。
[0052] 服务请求模式的示例可以包括一起频繁请求的服务、按顺序频繁请求的服务等。趋势变化模式的示例可以包括服务请求趋势中的相关位置特定变化。
[0053] 根据本公开的示例,该方法还可以包括:基于施加到雾节点之间的服务联盟边的权重将雾节点关联到匹配邻域中。
[0054] 根据这样的示例,基于施加到雾节点之间的服务联盟边的权重将雾节点关联到匹配邻域中可以包括:在注册雾节点图中创建服务联盟边权重的邻接矩阵;对矩阵的列进行归一化;对矩阵进行平方;对矩阵的列进行平方并且归一化;将低于阈值的矩阵条目设置为零;以及重复对矩阵的列进行平方并且将低于阈值的矩阵条目设置为零的过程,直到矩阵被变换为近幂等矩阵。基于施加到雾节点之间的服务联盟边的权重将雾节点关联到匹配邻域中还可以包括:从变换后的矩阵的最终权重中逐行提取集群。
[0055] 根据本公开的示例,该方法还可以包括:注册新的客户端节点;监测注册客户端节点的位置;以及从监测位置获知环境内与注册客户端节点相关联的至少一个轨迹。
[0056] 根据本公开的示例,还可以监测注册雾节点的位置以用于获知频繁行进的轨迹。
[0057] 根据本公开的示例,该方法还可以包括:将雾节点位于其中的环境建模为包括表示环境内的航路点的顶点和表示航路点之间的合法路径的边的位置图。
[0058] 根据本公开的示例,该方法还可以包括:生成建模环境的连通性矩阵,该连通性矩阵表示环境的合法路径之间的连通性。
[0059] 根据本公开的示例,该方法还可以包括:生成建模环境的路径类型矩阵,该路径类型矩阵表示环境中的合法路径的分配类型。
[0060] 根据本公开的示例,路径的类型可以与路径上的最大或平均速度相关联。根据本公开的示例,单个路径在一天的不同时间可以具有不同的类型。
[0061] 根据本公开的示例,该方法还可以包括:生成建模环境的航路点维度矩阵,该航路点维度矩阵表示穿过环境在每个航路点处相遇的合法路径的数量。
[0062] 根据本公开的示例,该方法还可以包括:将建模环境划分为多个区域;以及将建模环境的区域分配给该区域内的雾节点。
[0063] 根据本公开的示例,可以将建模环境的每个区域下载到该区域内的“区域”雾节点。
[0064] 根据本公开的示例,某些方法步骤可以在通信网络的云层面中执行,而某些方法步骤可以在通信网络的雾层面中执行。可以在通信网络的云层面中执行的步骤的示例包括:注册雾节点和客户端节点;生成散列映射、雾节点图、建模环境和估计轨迹;以及形成集群。可以在通信网络的雾层面中执行的方法步骤的示例包括接收请求和从集群中选择雾节点以用于实现请求。
[0065] 根据本公开的另一方面,提供了一种包括指令的计算机程序,该指令当在至少一个处理器上执行时使该至少一个处理器执行根据本公开的前述任一方面或示例中的方法。
[0066] 根据本公开的另一方面,提供了一种包含根据本公开的前述方面的计算机程序的载体,其中该载体包括电子信号、光学信号、无线电信号或计算机可读存储介质之一。
[0067] 根据本公开的另一方面,提供了一种计算机程序产品,包括非暂时性计算机可读介质,其上存储有根据本公开的前述方面的计算机程序。
[0068] 根据本公开的另一方面,提供了一种用于分配雾节点的资源的控制器,其中雾节点被组织成至少一个雾网络。该控制器包括处理器和存储器,该存储器包含可由处理器执行的指令,使得该控制器可操作用于:从客户端节点接收请求;识别用于实现请求的要求;确定用于实现请求的客户端节点的位置;以及根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群。该控制器还可操作用于通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。
[0069] 根据本公开的示例,该控制器还可操作用于执行根据本公开的前述任一方面或示例中的方法。
[0070] 根据本公开的另一方面,提供了一种用于分配雾节点的资源的控制器,其中雾节点被组织成至少一个雾网络。该控制器被适配为:从客户端节点接收请求;识别用于实现请求的要求;确定用于实现请求的客户端节点的位置;以及根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群。该控制器还被适配为通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。
[0071] 根据本公开的示例,该控制器还被适配为执行根据本公开的前述任一方面或示例中的方法。附图说明
[0072] 为了更好地理解本公开,并且更清楚地示出可以如何实施本公开,现在将以示例的方式参考以下附图,其中:
[0073] 图1示出了智能城市环境;
[0074] 图2示出了雾计算体系结构;
[0075] 图3是示出用于分配雾节点的资源的方法中的过程步骤的流程图
[0076] 图4a至图4d是示出用于分配雾节点的资源的方法的另一示例中的过程步骤的流程图;
[0077] 图5是示出控制器中的功能模框图
[0078] 图6是示出控制器的另一示例中的功能模块的框图;
[0079] 图7示出了街道网络的区域到区域雾节点的分配;
[0080] 图8是示出部署的雾层和云层之间的交互的消息交换图;以及
[0081] 图9是示出客户端节点和部署的雾层和云层之间的交互的消息交换图。

具体实施方式

[0082] 雾计算推动从在云计算核心中处理计算和数据存储到在网络边缘处理计算和数据存储的转变。代替将所有收集到的数据发送到云,雾计算建议在叶节点或边缘处处理数据。该思想也被称为‘边缘分析’。本地数据处理有助于减轻云计算的某些弱点,并且还提供新的优点,例如更强的上下文感知、实时处理、更低的带宽要求等。这其中的许多优点取决于雾节点的位置感知和适当资源的分配。因此,可以预期这样的雾网络体系结构,即,其使用一个或协作的多个终端用户雾客户端或近用户边缘设备来在辅助诸如车辆、人工代理、无人机等的互联系统时执行大量的存储、通信和控制、配置、测量和管理。雾无线电接入网络(RAN)还可以通过上下文感知恢复和通过雾RAN节点之间的动态协作来在有意义的通信中发挥作用。如上文针对其他示例雾应用所述,资源分配挑战是根据互联系统的位置、能力和特定需要来识别和组合(RAN)雾节点以执行所请求的任务。本公开的示例寻求解决这一挑战。
[0083] 不同的雾节点或系统可以彼此协作以共同支持应用。例如,多个雾系统可以针对一个或多个用户或应用共享数据存储和计算任务。不同的雾节点或系统还可以协作以充当彼此的备份。考虑到本地动作交互期间的发散性和全局配置一致性,解决雾联网中的振荡使资源分配任务复杂化。理解雾节点用以执行实现请求所需的资源动作的动态上下文可以有助于资源分配。
[0084] 本公开的示例提出了一种方法,该方法首先通过考虑雾节点的固有特征和互联系统的要求来理解来自雾联网的所需节点。这种理解源于基于实现请求的要求确定上下文,以及源于对可以在雾联网中表示不同环境的不同雾节点进行聚类以在所选择的雾节点集群内引发协作动作。因此,在所选择的雾节点组内执行资源分配和任务调度以采取本地动作来实现互联系统请求。本公开的示例提供了一种端到端解决方案,其可以通过被配置为表示环境以及在雾联网中执行动态聚类以发起协作动作并响应来自互联系统的请求的内聚模块来实现。内聚模块可以包括服务注册、图表示、理解上下文知识、分布式网络原型定位(localization)和形成。可以使用这样的模块实现的用于找到相关雾节点的动态聚类和高速缓存预取可以确保执行雾节点之间的上下文感知的动态协作以完成响应来自互联系统的请求的本地动作。
[0085] 本公开的示例使雾节点能够在动态环境中协作地工作。资源分配和任务调度可以由所选择的具有上下文感知的雾节点动态地完成,以执行由互联系统请求的本地动作。理解执行步骤的次序(显式上下文)允许通信网络的雾层面执行由互联系统请求的所需任务。本公开的示例可以被概括为三个步骤:
[0086] 可以执行动态聚类以在处理用于特定决策(执行互联系统所需的本地动作)的上下文感知的动态协作时仅包括来自雾联网的特定雾节点。
[0087] 由已通过对所需本地上下文的理解而识别的所选择的雾节点组按顺序次序执行任务。
[0088] 端到端模型执行上下文感知的资源分配和任务调度以执行动态地实现来自互联系统的请求的本地动作。
[0089] 所提出的方法的示例利用了对雾联网中的语义和上下文的理解,并且生成了一种解决方案,该解决方案可以被扩展为在工业IOT、智能城市和智能家居、制造4.0等的任何新环境中使用。
[0090] 图3是示出用于分配雾节点的资源的方法300中的过程步骤的流程图,其中雾节点被组织成至少一个雾网络。雾节点可以是包括云层面和雾层面的通信网络的一部分。云层面可以包括一个或多个单独的云,雾层面可以包括一个或多个单独的雾网络。雾层面以及其中的一个、一些或所有雾网络可以包括一个或多个分级层,其例如包括地区、区域、本地和端点层。该方法可以在网络的云层面、雾层面进行,或者可以在云层面和雾层面之间共享。参考图3,在第一步骤332中,该方法包括从客户端节点接收请求。在步骤334中,该方法包括识别用于实现请求的要求,并且在步骤336中,该方法包括确定用于实现请求的客户端节点的位置。在步骤338中,该方法包括根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群。最后,在步骤340中,该方法包括通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。可以在与客户端节点通信的雾节点处接收从客户端节点接收的请求。客户端节点可以连接到雾节点是其一部分的通信网络。该请求可以指定需要提供一个或多个服务的任务。
[0091] 图4a至图4d示出了示出用于分配雾节点的资源的方法400的另一示例中的过程步骤的流程图,其中雾节点被组织成至少一个雾网络。方法400的步骤示出了可以实现和补充方法300的步骤以便实现上述和附加功能的一种方式。对于以上图3的方法,雾节点可以是包括云层面和雾层面的通信网络的一部分。云层面可以包括一个或多个单独的云,雾层面可以包括一个或多个单独的雾网络。雾层面以及其中的一个、一些或所有雾网络可以包括一个或多个分级层,其例如包括地区、区域、本地和端点层。该方法可以在网络的云层面、雾层面进行,或者可以在云层面和雾层面之间共享。以下描述提供了方法400的概述,并且随后是对某些步骤和经由其可以实现这些步骤的功能模块的更详细的讨论。
[0092] 首先参考图4a,方法400包括在步骤402中注册新的雾节点,并且在步骤404中将由该雾节点提供的服务与其他雾节点提供的相应服务相关联。雾节点可以与诸如传感器、执行器等的IoT设备相关联。雾节点可以与雾节点可通过其提供服务的一个或多个资源相关联。将由雾节点提供的服务与由其他雾节点提供的相应服务相关联包括:在步骤404a中从服务元数据中提取该服务的有关信息;在步骤404b中计算所提取的信息与从由其他雾节点提供的服务元数据中提取的信息之间的相似性度量;以及在步骤404c中将该服务与由其他雾节点提供的与该服务的相似性得分最高的服务相关联。示例相似性得分包括基于属性的相似性、结构相似性等,如下面进一步详细讨论的。
[0093] 方法400还包括在步骤406中为相关联的服务分配密钥,并且在步骤408中生成将所分配的密钥映射到由雾节点提供的相关联的服务的散列映射。在步骤410中,方法400包括检测由雾节点提供的服务之间的服务请求模式,并且在步骤412中,该方法包括检测由雾节点提供的服务之间的趋势变化模式。下面更详细地讨论服务请求和趋势变化模式。
[0094] 方法400还包括在步骤414中基于检测到的服务请求模式和趋势变化模式生成注册雾节点图的服务联盟边并且对该服务联盟边进行加权。
[0095] 参考图4b,方法400还包括在步骤416中生成注册雾节点图,其中顶点表示雾节点并且其中顶点通过以下至少一项连接:表示雾节点之间的物理拓扑连接的位置边;连接提供相同服务的雾节点的服务边;和/或连接提供相关服务的雾节点的服务联盟边(如在步骤414中所生成和加权的)。在一些示例中,连接提供相同服务的雾节点的边可以是连接其服务被分配有相同密钥的雾节点的边。
[0096] 方法400还包括基于施加到雾节点之间的服务联盟边的权重将雾节点关联到匹配邻域中。这可以包括:在注册雾节点图中创建服务联盟边权重的邻接矩阵;对矩阵的列进行归一化;对矩阵进行平方;对矩阵的列进行平方并且归一化;将低于阈值的矩阵条目设置为零;以及重复对矩阵的列进行平方并且将低于阈值的矩阵条目设置为零的过程,直到矩阵被变换为近幂等矩阵。基于施加到雾节点之间的服务联盟边的权重将雾节点关联到匹配邻域中还可以包括:从变换后的矩阵的最终权重中逐行提取集群,每个集群包括匹配邻域。
[0097] 方法400还包括:在步骤420中注册新的客户端节点(其可以例如包括诸如车辆、人工代理、无人机等的互联系统);在步骤422中监测注册客户端节点的位置;以及从监测位置获知环境内的与注册客户端节点相关联的至少一个轨迹。在方法400的一些示例中,还可以监测注册雾节点的位置以用于获知频繁行进的轨迹。
[0098] 方法400还包括在步骤426中将雾节点位于其中的环境建模为包括表示环境内的航路点的顶点和表示航路点之间的合法路径的边的位置图。方法400还包括在步骤428中生成环境的矩阵。这些矩阵包括:建模环境的连通性矩阵,该连通性矩阵表示环境的合法路径之间的连通性;建模环境的路径类型矩阵,该路径类型矩阵表示环境中的合法路径的分配类型;以及建模环境的航路点维度矩阵,该航路点维度矩阵表示穿过环境在每个航路点处相遇的合法路径的数量。路径类型矩阵的路径类型可以与路径上的最大或平均速度相关联。路径类型可以随时间改变:单个路径在一天的不同时间可以具有不同的类型。下面更详细地讨论矩阵生成。
[0099] 方法400还包括在步骤430中将建模环境划分为多个区域并且将建模环境的区域分配给该区域内的雾节点。可以将建模环境的每个区域下载到该区域内的“区域”雾节点。
[0100] 方法400还包括在步骤432中从客户端节点接收请求,并且如图4c所示,识别用于实现请求的要求。可以在与客户端节点通信的雾节点处接收从客户端节点接收的请求。客户端节点可以连接到雾节点是其一部分的通信网络。该请求可以指定需要提供一个或多个服务的任务。
[0101] 识别用于实现请求的要求的步骤434可以包括在步骤434a中:识别请求的一个或多个主要服务,其中主要服务包括由至少一个雾节点提供的实现请求所必需的服务;以及识别可操作用于提供请求的主要服务的雾节点。识别要求还可以包括在步骤434b中识别可操作用于提供请求的次要服务的雾节点,其中次要服务包括由至少一个雾节点提供的与请求的主要服务相关联的服务。如步骤434b所示,识别可操作用于提供请求的次要服务的雾节点包括识别包含在与所识别的可操作用于提供请求的主要服务的雾节点相同的匹配邻域内的雾节点。如上所述,匹配邻域包括根据以下至少一项进行相关的多个雾节点:其提供的服务的服务请求模式和/或其提供的服务的趋势变化模式。
[0102] 方法400还包括在步骤436中确定用于实现请求的客户端节点的位置。这可以包括在步骤436a中基于环境(其可以是步骤436的建模环境)内的客户端节点的历史位置数据估计客户端节点的轨迹。
[0103] 在步骤438中,方法400包括根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群。在图4d中示出了该过程步骤中可能涉及的子步骤。
[0104] 参考图4d,在第一子步骤438a中,步骤438包括生成包括可操作用于至少部分地实现请求、在特定时间点在彼此的阈值距离内并且可操作用于彼此协作的雾节点的至少一个集群。可操作用于至少部分地实现请求的雾节点可以包括被识别为可操作用于提供请求的主要或次要服务的雾节点。步骤438还包括在子步骤438b中识别在客户端节点的阈值距离内的生成集群,并且在子步骤438c中基于所确定的位置和用于实现请求的时间段来确定所识别的生成集群是否可以实现请求。阈值距离可以是绝对的或相对的,即,它可以指定集群的参考位置在客户端节点的阈值距离内,或者它可以要求选择最接近的生成集群。
[0105] 如果所识别的生成集群不能实现请求,则步骤438包括在子步骤438d中生成新的集群来实现请求。步骤438还包括在子步骤438e中建立集群组,其中集群组包括可操作用于协作的多个集群,使得它们形成服务提供链。由于集群的动态性质以及其中的雾节点的可能移动性,该链可以确保跨特定地理区域和在特定时间段内提供服务。步骤438然后包括:在子步骤438f中对集群执行密度度量;在子步骤438g中解除低于密度阈值的集群;以及在子步骤438h中更新一个或多个生成集群。还可以在更新集群之后更新组的建立。在一些示例中,可以存储特定时间处的集群分布副本并且将其与时间戳相关联。
[0106] 再次参考图4c,在识别出可操作用于实现请求的雾节点集群之后,方法400包括通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。该选择步骤可以包括计算使表示以下至少一个的项的加权和最小化的目标函数:实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量。
[0107] 该目标函数可以包括:
[0108] min w1∑k∈K∑e∈Edxycxy+w2∑k∈K(Tk∈K‑ak‑τk)+w3∑r∈Rdr
[0109] 其中:
[0110] K是包括雾节点的服务提供商集合;
[0111] E是表示环境中航路点之间的合法路径的边集合;
[0112] dxy是客户端节点x与雾节点y之间的沿边的距离;
[0113] cxy是客户端节点x和雾节点y在N跳内相遇的概率;
[0114] T是指示客户端节点x到达雾节点k所花费的时间量的非负整数;
[0115] ak是雾节点k提供服务的时间窗口的开始时间;
[0116] τk是客户端节点到达雾节点k与从雾节点k接收服务之间的等待时间;
[0117] R是表示雾节点提供的最小服务数量的非负整数;以及
[0118] dr是指示服务请求的资源是否已被成功地分配的二元决策变量。
[0119] 服务提供商集合K还可以包括除雾节点之外的服务提供商,例如云服务提供商。
[0120] 方法400还包括:在步骤442中发起对所选择的雾节点的资源的分配以实现所接收的请求;在步骤444中发起对所选择的雾节点的有关信息的高速缓存;以及在步骤446中由所选择的雾节点实现所接收的请求。
[0121] 应当理解,示例方法400展示了可以组合本公开的特征的一种方式。在其他示例中,可以改变诸如某些步骤的次序等的细节。
[0122] 如上所述,方法300和400在包括多个雾节点的通信网络中执行。这些方法的步骤可以在通信网络的云层面、雾层面中执行或在云层面和雾层面之间共享。本公开提供了一种被适配为执行上述方法的任何或所有步骤的控制器。该控制器可以是其元件在通信网络的云层面和雾层面之间划分的逻辑功能。
[0123] 图5是示出可以例如在从计算机程序550接收到合适指令时实现根据本公开的示例的方法300和/或400的示例控制器500的框图。参考图5,控制器500包括处理器或处理电路502,并且可以包括存储器504和接口506。处理电路502可操作用于执行方法300和/或400的一些或所有步骤,如上面参考图3和图4a至图4d以及下面参考图7至图9所述。存储器504可以包含可由处理电路502执行的指令,使得控制器500可操作用于执行方法300和/或400的一些或所有步骤。该指令还可以包括用于执行一个或多个电信和/或数据通信协议的指令。该指令可以以计算机程序550的形式存储。在一些示例中,处理器或处理电路502可以包括一个或多个微处理器微控制器以及其他数字硬件(其可以包括数字信号处理器(DSP)、专用数字逻辑等)。处理器或处理电路502可以由任何类型的集成电路来实现,例如专用集成电路(ASIC)、现场可编程阵列(FPGA)等。存储器504可以包括适用于处理器的一种或多种类型的存储器,例如只读存储器(ROM)、随机存取存储器高速缓冲存储器、闪存设备、光学存储设备、固态盘、硬盘驱动器等。
[0124] 图6示出了可以例如根据从计算机程序接收的计算机可读指令执行本公开的方法300和/或400的示例的控制器600的另一示例中的功能单元。应当理解,图6所示的单元是功能单元,并且可以以硬件和/或软件的任何适当组合来实现。这些单元可以包括一个或多个处理器并且可以被集成到任何程度。
[0125] 参考图6,控制器600包括:接收模块602,用于从客户端节点接收请求;要求模块604,用于识别用于实现请求的要求;位置模块606,用于确定用于实现请求的客户端节点的位置;集群模块608,用于根据所识别的要求和所确定的位置识别可操作用于实现请求的雾节点集群;以及选择模块610,用于通过以下方式从所识别的集群中选择其资源要被分配以实现请求的雾节点:使实现请求所需的集群的数量、实现由雾节点接收的请求的总时间和/或未实现的由雾节点接收的请求的数量中的至少一个最小化。控制器600还可以包括接口
612。根据控制器600的不同示例,控制器600还可以包括用于执行如以上图4a至图4d的描述中所阐述的附加步骤的功能模块。这样的模块或其输出可供图6所示的模块参考以便执行它们的功能。下面更详细地讨论这种单元的示例。
[0126] 再次参考图4a,注册新的雾节点、将所提供的服务与其他服务相关联、分配密钥以及生成散列映射(步骤402至408)可以由散列映射生成器模块来执行。在智能城市模型或其他雾计算用例中,可能有多个制造商开发了IoT设备和雾节点。在这些制造商之间,可能使用不同的语法来描述相同的信息,从而产生不一致性。为了解决这个问题,当在云中注册雾节点及其相关联的IoT设备时,从设备元数据和数据表中提取其服务的关键词。散列映射生成器模块内的云端应用对所有相似类型的服务进行散列映射并且生成唯一密钥。例如,智能车辆的OBU(车载单元)可以提供可由不同制造商标记为‘location’(位置)或‘coordinates’(坐标)或‘position’(定位)或‘point’(点)、‘X‑Y values’(X‑Y值)、‘GPS location’(GPS位置)等的位置数据。类似地,温度传感器可以根据制造商将值表示为‘temp’或‘temperature’或‘tmp’(温度)。基于云的应用应当将相似类型的标签分组到同一组中。因此,‘temp’、‘temperature’和‘tmp’应当被分组到同一类别中。例如,处理‘environment’(环境)相关的数据的所有雾节点可以被分组到同一类别中,并且该类别在散列映射中被给予唯一密钥,例如248000。在环境雾中,处理‘temperature’(温度)数据的IoT设备或最低级别雾节点可以被给予唯一密钥248001,处理CO2数据的节点可以被给予密钥248002,等等。上述服务关键词形式在以下算法的上下文中被分组和考虑。这可以通过基于属性、基于结构和基于实例的相似性度量来实现。
[0127] 服务匹配算法
[0128]
[0129]
[0130] 将新服务与在分组特定类别的项时获得与该新服务的最大匹配得分的现有服务合并。该模块的结果是散列映射,其中由雾节点提供的服务被分组在一起并且分配有唯一密钥。
[0131] 现在参考图4b,生成注册雾节点图并且将雾节点关联到匹配邻域中的步骤可以由混合图生成器块来执行。在云中,雾网络分级结构被存储为其中雾节点和相关IoT设备作为按照其服务用其唯一密钥表示的顶点的图。
[0132] 该混合图中有三种类型的边:
[0133] ‑第1类型边是未加权边并且连接分级雾节点(顶点)以表示其物理拓扑。
[0134] ‑第2类型边连接具有相同唯一密钥的顶点。
[0135] ‑第3类型边(即,联盟边)是加权边,其中权重表示两个顶点(雾节点)之间的联合得分。
[0136] 在实际情况中,当发生服务请求时,如果两个雾节点一起提供数据/服务,则它们的联合得分增加。例如,天气雾节点和交通雾节点可能具有高联合得分,因为它们可能经常一起提供服务;交通状况取决于当前的天气状况(下雨、有雾、雾霾等)。智能车辆可以一并获取天气信息和交通信息以决定到达目的地的预期通勤时间。利用该表示法,可以实现不同雾节点集合之间的更简单的相关性,以理解相关的雾节点来解决与位置相关的某些问题。
[0137] 该模块的结果是具有上述3种类型的边的雾网络分级结构的图,该图可以帮助识别相关的雾节点,如下面进一步详细讨论的。这可以在没有上下文但具有较早知识的情况下完成。
[0138] 联盟边查找器块可以通过在混合图中形成联盟边来实现图4a的步骤410至414。该模块可以在混合图中启用联合得分内的动态上下文发现。联盟边及其得分以两种不同的方式形成:通过找到a)服务请求模式和b)变化模式。
[0139] a.服务请求模式:在训练阶段期间,该块检测来自客户端的服务请求的到达模式。将会有一些通常被一起或顺序地呼叫的雾服务。例如:在雨天,交通状况服务请求和天气状况服务请求可以大约同时到达。可以基于该关联来创建顶点之间的联盟边。
[0140] b.变化模式:云服务器端应用通过趋势分析自动地发现服务的关联,而无需来自客户端的明确服务请求。从所注册的不同类型的独特雾服务中,其检测趋势的相关的、位置特定的变化,并且因此发现一起变化的相关联服务。也可以基于该关联来创建顶点之间的联盟边。
[0141] 在混合图生成器块内,可以存在邻域选择块,其运行以下呈现的算法以将邻居分组到匹配邻域中,这可以有助于生成上下文感知的动态聚类、资源分配和最终的任务调度(图4a的步骤418)。
[0142]
[0143]
[0144] 注册新的雾节点(图4b的步骤420)可以由注册模块执行。为了访问智能城市或其他范例中的雾联网服务,应当首先对客户端设备(智能车辆、智能家居、IoT设备等)进行注册并且颁发唯一注册密钥。为了解决定位问题,了解客户端的位置和移动性模式是有帮助的。可以存在移动客户端和静态客户端。可以使用轨迹估计器模块来估计移动客户端的移动(图4b的步骤424)。该模块基于某些参数考虑移动客户端的位置。在本公开中,考虑由三个参数组成的移动性矢量:移动客户端的位置纬度、位置经度和速度。
[0145]
[0146] 路线估计基于受访段的位置踪迹。随着时间的推移,受访段被固定成一种模式并且由IoT设备规律地遵循。这些模式可以从历史数据和为环境(这里选取某一位置处的特定街道)分配的最大速度限制中获知。还有一些随机因素可能导致既定模式的例外情况,例如高速公路上的交通流量可能因事故或紧急情况而改变。这样的例外情况仍然可以在一段时间后或从先前节点的平均速度模式中获知或适应。这些随机因素可能不会有助于预测节点的位置,但是可以在自适应位置数据传输中加以考虑。该模块的结果是注册客户端的频繁行进的轨迹集合。
[0147] 对环境建模并且生成表示该环境的矩阵(图4b的步骤426和428)可以由街道网络创建器(SNC)和街道网络原型来实现。城市网络中客户端的移动性并不是完全随机的。已经证明,人类轨迹表现出高度的时间和空间规律性,每条轨迹的特征在于与时间无关的特有行进距离和返回到一些高度频繁出现的位置的显著概率。研究表明,尽管驾驶员的行进历史具有多样性,但是驾驶员仍遵循简单的可重复模式。
[0148] SNC模块考虑移动客户端的移动性框架来执行将实现客户端节点的请求的本地动作,即使客户端的位置和速度可能随时间改变。随机航路点(RWP)模型被广泛用于模拟为移动自组织网络设计的协议。每个移动客户端在相关球形空间(地球表面)内从(0,2π]中均匀地随机选取随机方向并且均匀地移动到随机目的地d,并且以其值均匀地选自区间(0,Vmax)的速度v行进。在每次移动之后,每个客户端暂停随机的一段时间。目的地d是平均值为μ的指数分布随机变量。在时间t,移动客户端的位置彼此独立。
[0149] 然而,对于智能城市街道网络中的实际移动客户端的移动,客户端设备并不是在具有任意暂停时间、任意速度分布和方向的开放场中行进。存在根据本地拥塞和控制机制限制其移动性的移动约束。SNC模块适合于任何用于新的、扩展的移动性建模的互联系统,特别是用于具有实际约束的街道网络。
[0150] 城市街道网络可以被表示为具有V个顶点的集合和E条边的集合 的图G(V,E)。该图G由具有相应位置数据和交通信息的城市地图数据发展而来。权重函数为每条边分配非负权重以表示长度。具有多条边的弯曲街道的长度被计算为直边
的总和。从源节点n1到目的地节点nd的路径实际上是被表示为顶点序列(n1,n2,n3,...,nd,)的边序列(n1,n2),(n3,n4),...,(nd‑1,nd)。如果街道是直线并且顶点vi∈V是街道的端点,则单条边ei∈E表示单条街道。因此,直的街道具有两个端点。如果街道由一条或多条曲线组成,则可以将其表示为具有其相应顶点的多条边。
[0151] 在SNC原型中,移动客户端执行一些基本步骤以到达目的地:
[0152] 1、确定目的地。
[0153] 2、选择到达目的地最近的顶点。
[0154] 3、选择该街道段的平均速度。
[0155] 4、每当需要时在端点处暂停。
[0156] 5、一旦到达端点,就选择下一顶点并且发起朝向目的地的下一移动。
[0157] 6、重复2至5,直到到达目的地。
[0158] 该系统解决了移动传感器网络应用中网络流量和定位性能之间的权衡问题。基于位置的无线移动跟踪应用可以容忍客户端位置的固定不确定性。位置不确定性基于街道端点而变化。该模块的结果识别互联系统及其动态性,从而帮助整个系统理解互联系统的当前位置,并且在街道网络原型和分布式街道网络的支持下帮助解决互联系统要求。
[0159] 街道网络原型从街道网络中提取信息。街道图元数据可以用于组装具有城市中存T在的所有n条街道的街道矩阵S=[s1,s2,...,sn] (这里,T表示矩阵的转置)。维度为n×n的相对稀疏矩阵C持有关于街道之间的连接的信息。如果cij∈C保持值1,则这表示街道si和sj彼此连接。
[0160] 环境中可能有不同类型的街道,包括高速公路、商业街道、住宅街道、小巷等,所有这些街道在任何给定时间都可能或多或少地拥塞。客户端在每种类型的街道上的平均速度彼此不同。因此,根据街道的最大平均速度来对街道进行分类。维度为m×1的矩阵持有街道的类型。基于最大平均速度针对街道和街道段动态地分配特定类型。该类型不是固定值,而是‘动态地’分配的,因为单条街道在不同的时段可能经历不同的平均速度。例如,城市街道可能在早晨和傍晚拥塞,但是在午后和夜间相对畅通。这些模式可以从历史数据和分配给街道的最大速度限制中获知。诸如事故和紧急情况等的随机事件也可能改变街道上的交通状况。这些仍然可以在一段时间之后或从先前客户端的平均速度模式中获知。在自适应位置数据传输中可以考虑这些随机因素。
[0161] G的每个顶点是街道段的端点之一。因此,每个顶点可以被认为是一个交汇点。每个顶点的维度d描绘了在该交汇点处相遇的街道的数量。因此,可以针对所有顶点的维度生T成矩阵D=[d1,d2,...,dv]。如果di=2,则该顶点是弯曲街道段的连接点。如果di>2,则其可以是带有交通信号的道路交叉口。
[0162] 每个客户端的移动的特征在于不重叠的时间段T1,T2,...,Tn。在每个时段Ti期间,客户端以某一平均速度Vi在长度为Li的街道i上行进。对于一般情况,可以认为Ls、Vs的值是相互独立的。因此,Ti=Li/Vi也是相互独立的。这里,移动客户端的目的地不是随机选择的,而是从最后街道的端点处具有不同概率的互联街道中识别的。
[0163] 客户端的平均速度可以被设置为最大速度限制,或者根据当前街道的街道类型,与具有零平均值和预定义标准偏差的高斯分布值求和。可以假设,如果客户到达交叉路口并且下一条要行进的街道已满,或者如果在其前方有另一个客户端以较低的速度移动(例如,由于交通拥塞),或者如果存在交通信号(均匀延迟),则客户端可以改变其速度。当到达交叉路口时,客户端以某种概率暂停从区间[0,tpmax]中均匀选择的有限时间tp。该概率线性地取决于该街道段的度数d。如前所述,如果di=2,则该顶点是弯曲街道段的连接点,并且在该顶点处停下或客户端速度显著降低的概率应当低。如果di>2,则其可以是带有交通信号的道路交叉口。d的值越大,表示在该顶点处以有限的停止时间暂停的概率越高。
[0164] 再次参考图4b,将建模环境划分为多个区域并且将建模环境的区域分配给该区域内的雾节点的步骤430可以在分布式街道网络模块中实现。
[0165] 除了可以存储街道矩阵的集中式云存储之外,可以分布街道网络以用于更快的更新和计算。因此,可以基于街道图客户端、边和平均交通量将整个城市街道地图划分为多个雾区。每个区域由区域雾控制,该区域雾包含街道地图子集并且处理在该区域中漫游的客户端的位置数据和服务。街道图的顶点和边在云层面的主街道网络中具有唯一的ID和名称。在区域子集中使用相同的ID和名称以便于区域之间的握手(handshaking)。采用分布式地图和位置聚合的益处可以如下:减少等待时间;在城市扩展时容易将新区域纳入系统中;节点分级结构中的通信可以应用区块链或类似技术来确保安全性。将区域分配给区域雾节点在图7中示出。
[0166] 雾节点之间的通信可以遵循任何合适的通信协议。在本公开的一个示例中,雾节点之间的通信使用消息排队遥测传输(MQTT)协议。MQTT是为功率受限设备和低带宽、高等待时间网络设计的轻量、开源型发布/订阅消息传输协议。MQTT与数据无关,并且提供带宽效率和连续的会话感知,因此有助于最小化对IoT设备的资源要求。MQTT还确保递送的可靠性和完整性,并且是需要从互联网上的后端服务器监控或控制的小型设备的大型网络的理想选择。MQTT模块可以在雾节点之间建立有效的通信以执行实现来自互联系统的请求的本地动作。
[0167] 以下处理流程示出了上述功能模块可以如何协作来实现方法300、400的示例。
[0168] 1、将可用街道地图数据转化为街道网络图G(V,E)。
[0169] 2、街道网络图的学习阶段。
[0170] ‑开发矩阵‑街道矩阵、连通性矩阵、类型矩阵、维度矩阵
[0171] 3、移动节点轨迹的学习阶段。从一段时间(训练阶段)内的数据中学习节点的行进模式。训练数据用于从每个客户端的行进历史中提取模式。图案包括频繁遵循的轨迹(街道集合)。
[0172] 4、一旦互联系统上运行的客户端应用发出对一个或多个服务的请求,该请求就会穿过雾到达云,在云中,从混合图中发现所请求的服务的唯一id。通知相应的雾节点。
[0173] 本公开提出了一种新的动态聚类方法来对相关雾节点进行分组以执行实现互联系统的请求所需的本地动作。该聚类方法考虑雾的固有特征,包括低等待时间和位置感知、广泛的地理分布、移动性、紧密邻近的超大量节点、无线接入的主导作用、流传输和实时应用的强大存在以及异构性。
[0174] 5、上下文感知动态聚类:由客户端(互联系统)请求的服务与相关联的服务分组在一起。这种上下文发现基于混合图中的联合得分执行。云端设备从互联客户端接收位置数据并且使用机器学习启发法来提取轨迹模式。使用所提取的模式和最近的数据,它预测客户端的下一位置。如果客户端是移动的,则沿其已知轨迹提供所请求的和相关联的服务的雾节点被动态地聚类。
[0175] 步骤5.1:聚类模块以数据流的速率操作并且创建将某一时空点处的在欧几里德距离(Euclidian distance)意义上接近的数据样本合并的集群。
[0176] 步骤5.2:每当新的服务请求到达时,算法搜索最近的集群。一旦找到,就评估最大距离标准以决定请求是否适合在集群内实现。
[0177] 步骤5.3:如果足够适合,则更新该集群以负责在实现所接收的请求时要提供的服务;如果不适合,则利用服务请求信息创建新的集群并且使用其时间戳作为集群创建时间。
[0178] 步骤5.4:该阶段分析集群的分布。从其中对象的当前数量来考虑集群的密度,并且将其用于通过基于密度的融合来创建最终集群。
[0179] 步骤5.5:对集群执行密度度量,这允许算法找到任意形态的集群。集群可以有三种不同的类型:密集集群、半密集集群和低密度集群。每种类型之间的差异是基于本地发现的动态阈值而确立的。
[0180] 步骤5.6:所谓一个集群连接到另一个集群的情况是在它们之间存在集群链,使得该链中的每个集群可以与该链中的相邻集群协作。互联集群的集合被称为组。
[0181] 步骤5.7:递归地分析集群组。一旦一个集群被创建,就会依次分析组中的其余集群。
[0182] 步骤5.8:一旦查明集群分布,就将集群分布副本存储为快照,未来可能会对该快照进行核查以提取关于系统演化的更多信息。快照的存储遵循根据若干采样时间堆叠过去快照的金字塔时间方案。
[0183] 步骤5.9:为了维护最新的模型,应当给予新传入的数据更大的权重。在所提出的算法中,利用取决于当前时间t和上次分配时间tk的衰减函数对集群进行加权。函数可以用于模拟阻尼窗口上的老化过程。
[0184] 步骤5.10:该阶段分析集群密度检查中的变化。评估集群以查明其密度是否低于低密度阈值。如果是这种情况,则集群被解除并且不再被考虑。一旦以这种方式进行了过滤,就会对剩余的有效集群进行分析以寻找组。对于每个组,递归地执行局部密度分析以找到所有可能的集群。
[0185] 步骤5.11:局部地,所提出的算法检查每个集群以确定其密度是否已经降低到半密集阈值以下。如果是这种情况,则解除该集群,并且利用其统计信息创建低密度集群。此更新可以在集群内创建新的低密度区域,从而改变集群的形式,甚至随着数据的演化而使其分裂为两个或更多个集群。
[0186] 步骤5.12:如果在组内,一些低密度集群已经增长为半密集集群,则可以使用融合动作将原本分离的两个集群进行组合。
[0187] 6、高速缓存预取:来自该动态聚类的信息可以用于帮助预取可用于更快地执行互联系统所需的本地动作的本地雾高速缓存。
[0188] 上述处理流程可以适应新客户端的出现或动态轨迹。例如,如果从新客户端接收到服务请求,则可以执行上下文感知搜索以将该请求与现有的已注释服务相关联。如果客户端沿新的轨迹移动,则当前雾可以与其邻域雾通信以生成动态集群和高速缓存预取。
[0189] 图8是示出根据本公开的示例的部署的雾层面和云层面之间的交互的消息交换图。图8示出了用于执行方法400的步骤402至430的消息交换,其涉及注册新的雾节点、位置监测和轨迹提取、环境建模、生成散列映射、生成联盟边以及生成雾节点的混合图。
[0190] 图9是示出根据本公开的示例的客户端节点和部署的雾层面和云层面之间的交互的消息交换图。图9示出了用于执行方法400的步骤432至446的消息交换,其涉及从客户端节点接收请求、识别提供请求的主要服务和次要服务的雾节点、确定用于实现请求的位置、动态聚类、高速缓存预取以及由所选择的雾节点提供所请求的服务。
[0191] 下面的讨论更详细地考虑方法400的步骤440,在该步骤中,选择用于分配给接收到的请求的雾节点。
[0192] 优化问题包括雾服务提供商集合和客户端集合。实现客户端请求包括两个阶段:服务发现和通过雾提供所发现的服务。来自在服务发现和解决定位问题时识别的相关联服务的知识丰富了所请求的服务。为每个请求分配两个时间窗口:指定何时可以开始服务发现的服务发现时间窗口;以及指示何时可以向客户端递送服务的服务递送时间窗口。服务时间或持续时间也与每个请求和递送相关联。服务持续时间指示执行服务递送将花费多长时间。每个请求分配有所识别的集群内的可行雾服务提供商集合。
[0193] 优化任务是将所请求的服务最优地递送到请求客户端。如果沿路线遵守时间窗口和容量约束,并且以相应的递送时间服务每个请求,则任务是有效的。目的在于最小化下述成本函数。
[0194] 由于雾服务提供商节点的数量是有限的,因此可能会发生某些请求无法分配到雾的情况。这些请求被安置在虚拟请求库中。
[0195] 该问题的目标是最小化包括以下三个分量的加权和:
[0196] 1)跨客户端轨迹探索的集群服务的数量(即,沿客户端轨迹递送服务所需的协作集群的数量);
[0197] 2)客户端和服务提供商服务请求所花费的总时间;
[0198] 3)未实现的雾服务请求的总数量。
[0199] 这三个项分别由系数w1、w2和w3加权。通常,为w3分配高值以服务尽可能多的请求。
[0200] 存在来自客户端的n个请求和m个雾服务提供商。在城市雾网络图中定义该问题,其中:
[0201] R={1,...,n}是提出请求的移动节点集合(并且因此是请求集合)。
[0202] D={1,...m}是服务递送雾节点集合。
[0203] K是所有服务提供商的集合(其可以包括雾服务提供商和云服务提供商两者)。在预设的讨论中,仅考虑雾服务提供商,因此|K|=m。
[0204] i是集合R中的请求。
[0205] k是集合K中的提供商(因此在本示例中是集合D中的雾节点)。
[0206] Ki是可以服务请求i的提供商集合(因为一个提供商可能无法服务所有的请求)。
[0207] 是可以由雾节点k服务的请求节点(或请求)集合。
[0208] 是可以由雾节点k服务的递送雾节点集合。
[0209] 对于所有i和k:
[0210] 对于移动图G(V,E)中的每条边e,分配了客户端x与提供商y之间的距离dxy>0和行进时间txy>0。
[0211] 每个提供商具有服务时间si和时间窗口[ai,bi]。服务时间表示向客户端提供服务所需的时间,时间窗口指示提供商何时将在服务递送区域(服务递送雾节点的区域)中。对位置i的访问可以发生在时间ai和bi之间。客户端可以在时间窗口开始之前到达递送节点,但是可能需要等待延迟时间τ。
[0212] 在下面提出的数学模型中使用了四种类型的决策变量。cxy是移动地图中在N跳内遇到客户端x和提供商y的概率的连续变量。R是表示雾提供商中存在的最小服务数量的非负整数。T是指示客户端到达提供商以获得服务所花费的时间量的非负整数。最后,d是指示是否为客户端成功地安置了服务请求的二元决策变量。该数学模型是:
[0213] min w1∑k∈K∑b∈Edxycxy+w2∑k∈K(Tk∈K‑ak‑τk)+w3∑r∈Rdr
[0214] 目标函数最小化可用集群服务、服务请求所花费的时间总和以及未服务请求的数量的加权和。以上描述已经在智能城市范式的上下文中呈现了方法的示例。这种范式中的示例雾联网系统可以包括智能建筑物、智能运输、互联汽车、智能停车场等。所呈现的示例已经通过考虑包括交通、可用停车场、建筑物和楼层以及其他相关特征在内的各个方面展示了来自不同雾系统的不同雾节点可以如何互联以及它们的资源如何用于解决诸如要停放在哪个建筑物内之类的问题。还可以设想所提出方法的其他用例,下面给出了一些简要的示例。
[0215] 智能医疗保健和灾难管理:
[0216] 实时健康监测和诊断是医疗保健行业的重要组成部分。在紧急情况或灾难期间,需要将患者从一个地点运送到另一个地点,同时提供连续的监测和远程诊断。上下文感知的雾资源分配和任务调度可以为此目的提供不间断的和改进的优质服务,如下所示:
[0217] ‑注册:来自城市中所有雾网络的雾设备(包括智能家居雾、交通系统雾、车辆雾、天气雾、血库雾、医院雾等)首先在云中注册。客户端被分配唯一的注册密钥。系统中可以有移动客户端和静态客户端。
[0218] ‑轨迹估计器:该模块学习IoT客户端频繁遵循的轨迹的模式。这些模式可以从历史数据和为环境分配的速度限制中获知。
[0219] ‑街道网络创建器:一旦轨迹估计器已经获知客户端的移动性模式,街道网络创建器模块就开发街道网络模型以便于跟踪客户端在城市街道网络中的移动性。
[0220] ‑基于街道图客户端、边和平均交通量将街道网络分配到多个雾区中。每个区域由区域雾控制,该区域雾包含街道地图子集并且处理在该区域中漫游的客户端的位置数据和服务。
[0221] ‑散列映射生成器:使用服务匹配算法从雾设备的服务元数据和数据表中生成城市范式中的所有相似类型的雾服务和其唯一密钥的散列映射。相似的服务被分组在一起并且分配有唯一密钥。
[0222] ‑联盟边查找器:联盟边查找器模块通过服务请求模式分析和变化模式分析生成联盟边。联盟边被提供给混合图生成器。
[0223] ‑混合图生成器:该模块生成并且存储具有三种类型的边的雾网络分级结构图。该模块运行Neighborhood_Selection(邻域选择)算法以将雾节点分组到匹配邻域中。
[0224] ‑在紧急情况期间,需要有效率地将患者从一个地方移动到另一个地方。当从智能救护车发起服务请求时,发现相关联的服务并且将其分组在一起。
[0225] ‑该请求首先获得唯一的服务ID。聚类模块获取能够服务所请求的服务的雾节点的信息。
[0226] ‑聚类模块从互联客户端接收位置数据并且使用机器学习启发法提取轨迹模式。使用所提取的模式和最近的数据,它预测客户端的位置。
[0227] ‑沿客户端的已知轨迹提供必要服务的雾节点被动态地聚类。
[0228] ‑根据混合图中的联合得分执行上下文发现以从不同的雾网络中发现相关联的服务。例如:救护车可能需要获得到达医院的最快路线。在这种情况下,需要交通系统雾和天气雾的协作,因为这些雾节点在混合图中具有高联合得分。
[0229] ‑交通系统雾提供关于当前交通状况、街道状况、方向、沿相同方向移动的车辆数量等的信息。天气雾提供关于天气(下雨、下等)的信息。救护车根据接收到的天气和交通信息决定最佳轨迹。
[0230] ‑一旦决定了救护车的预期轨迹,就可以将信息提供回交通系统雾。交通雾发起警报通知以通知其他车辆给救护车让路。
[0231] ‑如果从救护车提出请求,则医院雾系统可以协作以发现可获得所需治疗和床位的附近医院的最佳选择。相应地,可以进行远程监测和诊断。车辆雾与血库雾协作以发现特定群体的血液可用性。
[0232] 以上用例讨论示出了可以如何执行基于从混合图中发现的上下文的动态雾资源分配和任务调度的另一示例。由救护车将危重病人沿尽可能最快的路线运送到合适的医院是通过本地雾系统之间的协作来执行的。相关的雾系统被分组在一起并且被安置为即时共享信息。自适应雾系统学习上下文、安置相关资源并且相应地调度任务以用于执行实现请求所需的本地动作。
[0233] 智能制造和维护:
[0234] 目前IoT在制造业中的应用已经很普遍。由于与制造相关联的非常复杂的工艺和固有波动,企业正不断地寻求提高其成品率以降低成本和增加利润率。预测性维护防止不必要的维修、最大化有效资产寿命并且显著地减少严重故障和停机时间。这样可以节约成本,同时提高投资回报和客户满意度。预测性维护已经成为制造业维护的关键部分。行业正在部署这样的过程,即,通过在出现重大问题之前检测潜在故障来使其设备的可靠性达到最大化。包括例如生产雾、维护雾、质量保障雾、废物管理雾、运输雾、交通系统雾等的雾之间的上下文感知的协作可以帮助顺利地运行复杂的制造过程。此外,可以高效地解决包括故障检测、停机时间预测、维护规划、成本节约型物流和供应链规划在内的定位问题。
[0235] 智能采矿:
[0236] 具有雾计算的IoT可以用于通过跟踪远程位置处的矿工和车辆并且使用实时数据和分析监控车辆的状态来帮助显著地提高采矿产量。采矿车辆配备有嵌入式传感器,其使得能够基于实时车辆和地形数据进行安全和路线优化。可以随时间变化收集资产监控信息以帮助对关键机器和其他资产进行预测性维护。矿井工人还可以与健康监测设备连接,从而允许对身体状况和疲劳进行实时评估并且在发生事件或事故的情况下发送警报。
[0237] 采矿业中的不同雾系统(包括车辆雾、交通系统雾、天气雾、采矿仪器雾、维护系统雾、健康记录雾等)可以协作以解决定位问题。这种上下文感知的协作可以帮助采矿企业顺利地开展采矿作业,同时确保工人的安全措施并且具有高效的物流管理。
[0238] 因此,本公开的各方面和示例提供了允许高效地实现客户端请求的分配雾节点的资源的方法。雾系统在系统管理方面提出了若干挑战;服务被划分为多个微级服务并且跨边缘设备和云分布。对执行微服务的雾体系结构的适当管理是雾计算领域中的重要挑战。服务安置和服务组合是在大规模、微型服务管理体系结构中面临的两项重大难题。
[0239] 本公开提出了基于关系动态地聚类附连到雾节点的微服务的可缩放系统和方法。根据雾网络中的上下文感知的雾资源分配和任务调度对提供给终端用户的服务进行分组。
本公开的示例利用来自不同的现有雾网络的知识自动地聚合雾节点。所聚合的集群用于快速且高效地执行实现从互联系统接收的服务请求所需的本地动作。因此,本公开的示例提供了任务分配、资源调度和决策方面的改进的精度以及雾节点之间的改进的协作,这可以在包括车辆移动、无人机飞行等的多种用例中发挥作用。
[0240] 本公开的方法可以以硬件或作为在一个或多个处理器上运行的软件模块来实现。这些方法还可以根据计算机程序的指令来执行,并且本公开还提供了一种其上存储有用于执行本文所述的任何方法的程序的计算机可读介质。体现本公开的计算机程序可以存储在计算机可读介质上,或者它可以例如是信号的形式(例如,从互联网网站提供的可下载数据信号),或者它可以是任何其他形式。
[0241] 应当注意,上述示例说明而非限制本公开,并且本领域技术人员将能够在不脱离所附权利要求的范围的情况下设计许多替代实施例。词语“包括”不排除存在权利要求中所列元件或步骤之外的元件或步骤,“一”或“一个”不排除多个,并且单个处理器或其他单元可以实现权利要求中所述的若干单元的功能。权利要求中的任何附图标记不应被解释为限制其范围。
QQ群二维码
意见反馈