CN111164573A - 启用雾服务层并应用于智能运输*** - Google Patents

Abstract

公开了使用分层级雾节点部署的雾服务层体系架构，该分层级雾节点部署包括雾节点与云节点的共存和交互。该体系架构还包括每个雾节点中托管的功能、能力或服务的列表。一个或多个雾管理过程可以在雾节点之间(或在雾和云之间)运行，并且可以包括雾能力发现过程、雾连接核实过程和雾能力状态报告过程。此外，雾节点可以被配置为使用本文所描述的一个或多个雾服务过程彼此交互以获得特定服务。

Description

启用雾服务层并应用于智能运输***

相关申请的交叉引用

本申请要求于2017年10月6日提交的编号为62/568,955的美国临时申请的权益，该申请的全部内容通过引用并入本文。

背景技术

术语“云”和“云计算”在信息技术(IT)领域中已经变得非常流行。在IT或通信中，云是指服务或提供功能的集合并且被远程托管的节点，具体而言是在IP网络中(诸如互联网上)。云计算是指在位于互联网上的云节点或服务器上供应计算资源。云或云中的计算资源包括硬件和软件资源、存储、通信、分析等。照此，云计算启用对这些资源的远程操纵、配置和访问。这个概念的益处之一是易于服务部署和供应。作为示例，应用或服务提供商(provider)可以要求获取和管理一些计算资源来推出服务。在没有云计算的情况下，可能需要必须满足某些硬件要求(诸如存储器、计算和网络能力)的服务器。而且，还可能需要特定的软件元件，诸如操作***和用于运行期望应用的其它软件工具。照此，主要关注于应用逻辑以及实际服务的服务提供商可能还需要获取和管理所提及的资源。与平台相关的任何问题都会减慢实际服务的推出速度。照此，服务供应与这些资源的可用性和可管理性紧密相关。

使用云计算的服务提供商可以求助于“云服务提供商”或提供远程托管应用所需的所有这些资源和相关软件平台的实体。应用提供商可以简单地提交对于托管服务的资源需求(例如，并行计算、CPU性能、通信、存储等)，而不必担心如何管理、配置这些资源或是否对其进行虚拟化。在这个示例中，“云即服务”的概念变得明显–只要网络连接可用，远程实体就会提供所有需要的资源来托管和运行所需的任何类型的服务。

发明内容

本文公开了使用雾计算用于增强的服务供应的方法和***。雾计算涉及使用类云功能，这些功能托管在称为雾的节点的边缘处。雾节点具有计算和其它资源，包括存储、计算、分析、启用多种IoT协议(诸如CoAP、HTTP等)的处理的能力、以及其它服务(诸如处理和响应安全应用消息(诸如通过IEEE WAVE消息发送的消息)以及使用接入技术支持发送和接收功能的能力)。雾节点可以提供本机(native)服务，诸如跟踪、图像处理、控制致动器等。可以将这些服务水平地提供给其它雾节点，或者垂直地提供给在雾上运行的应用实例。雾节点一起提供雾服务层，该雾服务层还与被假设为监督雾操作的云实体进行交互。

使用分层级(hierarchical)雾节点部署公开了雾服务层体系架构，该分层级雾节点部署包括雾节点与云节点的共存和交互。该体系架构还包括每个雾节点中托管的功能、能力或服务的列表。一个或多个雾管理过程可以在雾节点之间(或在雾和云之间)运行并且可以包括雾能力发现过程、雾连接核实过程和雾能力状态(status)报告过程。

雾节点可以被配置为使用本文描述的一个或多个雾服务过程彼此交互以获得特定服务。描述了雾服务过程的两大类。雾服务供应的过程包括在雾节点之间执行的过程，目的是基于对雾功能的先前发现向彼此提供服务。虽然这些过程可以由应用层触发，但过程集中在雾交互上，以使服务跨雾和在雾中水平地可用。用于应用的雾支持服务可以包括与应用层具有更紧密交互的过程，该过程进而使用雾服务层跨雾区域水平地动态激活或重定位其服务。

提供本发明内容是为了以简化的形式介绍一系列概念，这些概念将在下面的具体实施方式中进一步描述。本发明内容不旨在识别所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或所有缺点的限制。

附图说明

为了促进对本申请的更稳健的理解，现在参考附图，在附图中，相同的元件用相同的附图标记表示。这些附图不应当被解释为限制本申请，而仅仅是说明性的。

图1示出了示例基本云计算模型；

图2示出了用于智能交通控制的示例雾计算场景；

图3示出了雾节点及其通信的示例层级结构；

图4示出了雾计算在智能运输(smart transport)***中的示例使用；

图5示出了每个区域的雾和云节点连接的示例；

图6示出了示例雾服务层体系架构；

图7示出了示例本地雾节点能力、功能和服务；

图8示出了雾能力发现的示例过程；

图9示出了雾连接核实的示例过程；

图10示出了雾能力状态通知的示例过程；

图11A-11C示出了雾服务请求的示例过程；

图12示出了雾服务操作推荐的示例过程；

图13A-13B示出了由于移动性而进行雾应用实例化的示例过程；

图14A-14B示出了在雾节点中用于云触发的应用实例化的示例过程；

图15示出了用于应用实例化的示例直接F2F过程；

图16示出了经由云进行应用用户情境重定位的示例过程；

图17A-17B示出了用于具有直接雾对雾信令的应用用户情境重定位的示例过程；

图18示出了使用预定路线跨雾区域行驶的示例车辆；

图19A-19B示出了基于预测的移动性来准备应用服务的示例雾服务层交互；

图20示出了CSEBase的示例资源树；

图21示出了具有oneM2M检索操作的雾能力发现过程的示例实施方式；

图22示出了利用oneM2M更新操作对雾能力状态报告过程的示例实施方式；

图23示出了用于支持应用实例化的示例增强型资源；

图24示出了用于实例化(instantiate)本地雾节点处的应用的示例oneM2M更新消息；

图25示出了示例监视器，该示例监视器示出了雾节点和云的层级结构以及相关联的性能指标；

图26示出了可能的显示选项的示例；

图27A示出了其中可以实现一个或多个所公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信***的示例***图；

图27B示出了可以在图27A中所示的M2M/IoT通信***内使用的示例体系架构的示例***图；

图27C示出了可以在图27A中所示的通信***内使用的示例M2M/IoT终端或网关设备的示例***图；以及

图27D示出了其中可以实施图27A的通信***的各方面的示例计算***的示例框图。

具体实施方式

图1示出了基本的云计算概念，其中服务提供商使用基于web的API在云上部署服务。云提供商定义这些API并且还拥有提供用于部署服务或应用所需资源的云平台。一旦部署，诸如智能电话之类的设备就可以访问云(或互联网)上的服务或应用。

云计算服务的示例是智能电话上可用的语音识别和语音命令。用户可以发出语音命令，诸如“找出在我附近的餐馆”，然后将其发送到云(例如，发送到云中的具体应用或服务器)以进行分析。然后将结果发送回设备，该设备根据需要向用户显示餐馆列表。

虽然云计算改变了使用计算和部署服务的方式，但确实要求始终保持连接才能正常工作。而且，由于云是远程的，因此存在与在设备和云之间来回发送数据相关的延迟问题。此外，随着物联网(IoT)的出现，可以看到数百万个“事物(thing)”的部署，预计设备生成的数据将大大增加。照此，将延迟和带宽视为将云计算用于IoT应用或其它对延迟敏感的应用(例如与公共安全相关的应用)的阻碍(setback)。引入了“雾计算”的概念来解决与云计算相关联的缺点。

顾名思义，雾是“地面上的小云”。但是，就计算情境而言，雾节点是具有类云功能的节点，但它更靠近生成数据的边缘，因此与云相比，它的远程性更小。雾节点在能力方面与云类似。例如，它们具有计算、存储、通信和启用服务和应用在网络边缘处的部署的其它能力。由于雾节点靠近数据源，因此与云应用相比，雾节点有望托管对延迟更敏感的服务。对于更多的智能事物和机器，减少延迟被视为关键，因为它可以实现缩短从数千甚至数百万个事物生成的数据的接收、分析和响应的时间。

由于比云节点更接近设备，因此雾计算还有望减少将数据发送到某个点进行处理和分析所需的总体所需带宽。例如，来自使用蜂窝网络的传感器的数据将需要被无线发送到无线电网络，然后数据穿过核心网络，然后进入互联网领域并最终在过程中通过一系列IP路由器到达云服务器。鉴于雾节点，数据可能仅需要通过一种介质或一跳被转发，并且作为示例可以使用雾节点与传感器之间的无线链接。雾节点然后可以处理数据并且可以作为响应而发送命令(例如，以控制石油钻机中的油的流动)。

已经描述了雾节点的优点，重要的是要提到雾节点并非旨在替代云节点。雾节点可以与云共存，但是它们可以以水平方式跨网络部署。在垂直方向上，雾还可以部署在“事物”和云之间，从而形成雾级别的层级结构，其中在每个级别都可以水平部署雾节点。因此，雾被视为“填补云和边缘之间的间隙”的计算资源，并且通过这样做还可以覆盖宽的(水平)区域，以满足可以稀疏部署的所有设备的服务需求。为了解释云和雾如何可以共存，考虑智能城市用例，其中可以在区域中部署雾节点以监视电或其它公用事业甚至交通的使用。特定社区(neighborhood)中的雾节点可以能够从传感器和计量器接收数据、根据社区的数据对其进行分析并对其进行响应。类似地，可以在其它区域中使用其它雾节点来接收该位置的数据并相应地对其进行响应。但是，可能需要整体考虑来自所有社区以及整个城市的数据(例如，执行大数据分析)。因此，雾节点可以进而将原始或经处理的数据进一步转发到雾层级结构，并最终转发到云。在云中，可以实现***视图、可以执行大数据分析、并且可以将操作建议发送回最低雾节点，以确保在本地级别和***级别两者均获得最优性能。图2示出了针对智能交通控制场景的雾和云节点的示例部署。

如图2中可以看到的，雾节点连接到街道上的交通信号灯和相机。这些实体将数据发送到雾节点，雾节点根据需要处理数据。由于交通信号灯和相机具有一些计算和存储资源，因此这些节点可以被称为雾实体(FE)。FE将数据发送到雾节点(FN)，FN可以充当FE在数据和服务方面的融合点。照此，可以将FN 3和FN 4视为本地雾节点(LFN)，它们充当应用的雾服务层。LFN(或一般而言是FN)可以连接到可以在雾部署层级结构中更高级别处部署的其它FN。例如，LFN 3(示为FN 3)和LFN 4(示为FN 4)可以进而连接到可以被视为更高级别的FN的FN 1。此外，LFN 3(示为FN 3)可以直接连接到云节点。因此，在智能交通场景中，可以存在几个级别的雾层级结构以及潜在到云的连接。应注意的是，也可以存在提供不同服务的少量云节点。例如，可以部署城市交通服务云以提供交通和运输服务，以监督包含大量LFN、FN和FE的整个区域。类似地，可以部署汽车制造商云以从广阔区域的汽车收集数据。数据可以由部署在广阔区域中的LFN和FN提取，并且汽车可以经由这些LFN和FN发送与传感器或其它车载设备相关的信息。应注意的是，车辆本身可以包含计算和通信资源，因此可以被视为FN或移动的FE。

重要的是应注意雾节点为云场景带来了更多的动态性。即，雾节点可以根据需要动态部署，而且，对于每个雾节点，可以相应地缩放资源。预计雾节点比云具有更少的资源，从而促进了更静态部署的情况(即，云是可以在资源中扩展的中央节点，但是不期望云能够(至少不经常)移至不同区域)。例如，与雾节点相比，预计云节点上将有更多的存储空间，但是雾节点也可以在一定程度上扩展存储资源。

最后，必须提及的是，雾节点既可以进行东西向的通信(在同一级别的雾节点之间)，也可以进行南北向的通信(在部署中垂直分层的节点(包括云)之间)。图3示出了雾节点和云之间的这种水平和垂直通信的示例。

本文公开了用于使用雾计算来增强服务供应的方法和***。雾计算涉及使用类云功能，这些功能托管在称为雾的节点中的边缘处。雾节点具有计算和其它资源，包括存储、计算、分析、启用多种IoT协议(诸如CoAP、HTTP等)的处理的能力、以及其它服务(诸如处理和响应安全应用消息(诸如通过IEEE WAVE消息发送的消息)以及使用接入技术支持发送和接收功能的能力)。雾节点还可以提供本机服务，诸如跟踪、图像处理、控制致动器等。可以将这些服务水平地提供给其它雾节点，或者垂直地提供给在雾上运行的应用实例。雾节点一起提供雾服务层，该雾服务层还与被假设为监督雾操作的云实体进行交互。

云节点是具有云或雾能力的节点(参见下面的雾节点)，它管理部署层级结构中较低的其它雾节点的操作。它还与服务提供商进行交互，并具有服务层协定，并且可以授权来自雾节点的与托管在雾节点上的应用有关的请求。应注意的是，术语“云”可以用于指代云节点。此外，云可以监督和管理不同雾节点之间的交互，这些雾节点共同为应用启用雾服务层。

雾区域是在服务方面雾节点或本地雾节点负责或覆盖的区域。假设节点已连接到识别出的区域内的IoT设备并且可以与IoT设备进行通信以获得数据。因此，它服务于部署IoT设备的区域。应注意的是，为区域提供服务的雾节点不一定意味着雾节点直接为IoT设备提供服务，而是与其它节点或应用层一起获得、分析并共享(来自这些IoT设备的)数据。但是，这也不排除雾节点可以充当网关或为IoT设备提供存储服务。

雾实体是具有雾节点的能力的子集的节点。而且，雾实体可以连接到本地雾节点(参见下文)，因此成为本地雾节点的数据和服务的来源。此外，雾实体还可以从本地雾节点请求并消耗(consume)数据或服务。应用层(在本地雾节点之上)不会直接“看到”雾实体，而是能够以透明方式经由本地雾节点使用其数据或服务。在本文所述的智能运输用例中，雾实体可以是传感器、相机、交通信号灯或具有基本(相对小的)计算和存储资源的任何IoT设备。而且，可以将雾实体部署在本地雾节点之后或下方。

雾节点是具有任何雾资源(诸如计算、存储、通信、分析等)的节点。雾节点可以具有这些资源中的至少一个，并且还可以具有在雾节点上运行的其它软件或服务。对于本文所述的智能运输用例，可以在比本地雾节点高的级别上部署雾节点。可以存在若干级别的雾节点部署，而云节点处于最高级别。还假设雾节点可以连接到至少一个本地雾节点，并且前者还管理至少一个本地雾节点。

本地雾节点是具有许多能力和服务的雾节点，这些雾节点与其它LFN和云一起创建为授权的应用提供服务的雾服务层。而且，本地雾节点可以连接到位于本地雾节点的服务区域中的多于一个雾实体(FE)。这些(FE)进而成为由本地雾节点消耗的数据和服务源。应注意的是，本地雾节点是具有本文所讨论的特点的雾节点的特定实例化或类型。

本地雾节点还可以向与其连接的雾实体提供服务和数据。本地雾节点与其它邻近的本地雾节点一起对托管在本地雾节点上的应用显示为雾服务层。这些应用只能与本地雾节点进行通信和对接，因此可能没有被配置为直接与雾实体对接。在智能运输用例中，本地雾节点可以位于雾实体与雾节点或云节点之间。可以假设本地雾节点由在雾部署层级结构中比本地雾节点高一级的雾节点或云节点管理。照此，本地雾节点可以连接到多个雾实体以及一个雾或云节点。路边单元可以充当本地雾节点或可以托管其一些逻辑功能。取决于场景和目标，车辆可以充当雾实体和/或本地雾节点。

预计可以在城市-家庭、办公室、街道、汽车等中部署数以百万计的各种类型的机器、传感器、计量器(光、速度、水等)。所有这些“事物”都可以生成大量需要某种分析和操作的数据。例如，射频识别(RFID)可以用于检测被授权的驾驶员的存在，然后致动器可以用于打开或关闭私人停车场的大门等。目前，大多数交通信号灯都使用具体的周期进行操作，用于在不同的颜色之间进行切换。情况常常是，交通信号灯实际上是绿色的但街道上可能没有任何汽车。然而，在该街道的交叉路口，一排汽车可能正在等待面对它们的交通信号灯从红色变为绿色。照此，基于时间的交通信号灯操作可能不是最优的。通过安装相机和传感器，交通控制***可以使用这些额外的信息来实时改变灯的操作，使得不会不必要地积聚交通。应注意的是，车辆检测环目前被用于检测交叉路口的车辆，但这些要求在人行道上安装硬件。利用IoT设备和大数据，可以避免此类安装并且这些新的数据源可以替代并帮助提供有关交通(信号灯)控制的更多见解。因此，我们可以看到，通过部署更多的“事物”和更多的数据，可以使用该数据实现对周围环境的更好的理解和感知。进而，可以做出更好的决定来改善服务集。应注意的是，这个用例适用于智能运输场景，但是，一般而言从许多传感器、机器和“事物”中实时提取数据、并与可从中受益的实体共享此数据、执行分析和相应地进行响应的构思是可以应用于任何用例的操作增强，因此它不仅限于运输***。然而，以智能运输作为示例来反映雾计算的益处。

在运输***的情境(context)中，重要的是应注意如何可以充分利用雾以及由雾节点提取和共享的数据来改进服务。考虑当今的导航***，例如智能电话上的导航应用。这些应用中的许多应用基于车辆的速度来计算交通状况。更准确地说，车辆速度是基于从这些车辆中驾驶员的智能电话获得的速度测量确定的。该方法存在一些限制。首先，这种确定并不表示整个驾驶员集合，因为计算仅取决于那些正在积极使用该应用的驾驶员。否则，应用本身不会发送速度读数。而且，向其发送这个信息的应用服务器需要一些时间才能得出相对准确的信息。照此，这些应用无法实时考虑可能会导致减速的危险，诸如从卡车上掉落的物品。而且，这些应用可能不会立即反映出立即减慢交通的车辆故障。照此，显然，使用来自驾驶员的子集的速度信息没有给出交通状况的准确和实时描述。因此，来自相机、传感器和路边单元(RSU)的其它数据确实可以在提供实时交通状况方面有所作为。

图4描绘了图示雾计算在数据提取、共享和分析中的重要性的示例用例。针对自动驾驶汽车的场景解释这个用例，这被视为实现智能运输***概念的关键。但是，应当指出的是，这只是个示例，因此所要解决的问题和解决方案也适用于其它不使用自动驾驶汽车的情况。

如图4右上方所示，考虑能够自动驾驶的主体车辆。使用这个自动驾驶汽车的乘客可能期望到达特定目的地，因此，运输被视为针对用户的服务。作为运输服务的一部分，用户还可能需要获取其它服务，诸如在特定服务点(例如咖啡店)停车、在目的地找到停车位以及获取有关突发紧急服务的通知。

在服务点停车：

首先，用户可能希望在起始位置和目的地之间的某个服务点停车。服务点可以是咖啡店或加油站，或向用户提供感兴趣的服务的其它地方。假设服务点是咖啡店，则用户可能希望花费最少可能的时间来喝杯咖啡，并且可能希望使用咖啡店的驾驶通过服务(drivethrough service)。通常，重点放在到达特定服务点所花费的时间上，而不需要了解很多服务点本身正在发生的事情。例如，为了开车去咖啡店，交通负荷可以是平均的，但是，特定的咖啡店可能比另一个咖啡店忙得多。照此，在特定的咖啡店中，将(例如驾驶通过的)本地服务点会花费长时间的“拥堵”因素考虑在内可以帮助确定更好的路线并减少通勤的总时间。雾节点可以提供特定的地方或服务点的本地信息，该信息可以用于确定最佳路线。照此，自动驾驶汽车的路线计算不仅受其它汽车的数量和速度的限制，而且还取决于用户的服务需求以及提供这些服务的点及其周围的交通负荷。照此，继续以咖啡店为例，因为距离较近的咖啡店可能忙得多并因此使通勤时间更长，所以多驾驶两个街道代替驾驶进入靠近的咖啡店实际上可以减少总体驾驶时间。雾节点可以提供这个额外信息以增强运输服务。

因此，观察图4，咖啡店可以具有连接到雾节点的相机和传感器。这个节点可以在本地确定拥塞程度并且可以与其它雾节点实时共享这个信息。智能交通应用可以使用这个信息来建议满足用户要求的服务点，同时减少总的行驶时间。

在目的地找到停车位：

作为智能运输服务的一部分，用户可能希望了解在目的地停车的可用性。对于自动驾驶汽车场景，评估停车位的可用性可以是重要的，以便车辆可以决定特定的车位并驶向该车位。应注意的是，这个用例也适用于非自动驾驶场景。例如，使用智能运输服务的驾驶员可能还希望跟踪目的地停车位的可用性。在这种情况下，更快到达目的地并不是唯一的目标。例如，绕街区来找到靠近特定建筑物的停车位可能比实际将停在一两个街区之外要花费更多的时间。照此，从雾节点获得这个信息可以为驾驶员提供相关的实时信息，这将使驾驶和运输***在时间方面更加高效。

在图4中，雾节点可以位于建筑物上，并连接到相机和传感器，使得雾节点可以确定停车位的可用性以及针对具有特殊服务需求的可能停车位等。这个信息可以与其它雾节点共享，并最终与自动驾驶汽车(或正在使用智能运输应用/服务的驾驶员)共享，以便做出最佳决定并将时间最小化。

关于突发紧急场景的通知：

在可能派遣公共安全服务人员的地方或建筑物中可能发生紧急情况(例如火灾)。消防车、救护车等可以具有到达目的地的预先知道的路径。但是，也向同一目的地驾驶的车辆不知道将发生拥堵。在当前的智能导航***中，建筑物火灾和交通状况之间通常没有链接。这些是可以考虑的更具预测性的条件类型，并且可以通知在这些区域中驾驶的车辆并从事故区域重新定向。这个动作将对驾驶员(或自动驾驶汽车)和公共安全人员都有帮助。

如图4中所示，公共***门(例如消防车服务部门)可以具有雾节点，该雾节点知道紧急事件和这些事件的位置。当派遣消防车时，雾节点可以与邻近的雾节点共享这个信息，然后邻近的雾节点可以广播这个信息，使得自动驾驶汽车避开某些路线。这将避开道路上的拥堵，并且当交通从该位置转移时，可以使消防车更快地到达目的地。

上面示出的示例源自全方位部署的许多“事物”的可用性–几乎每个交叉路口的相机、速度传感器、温度传感器和其它检测器(例如，湿滑的道路)、报告停车位的可用性的其它传感器、可以从车辆发送或接收安全消息的RSU。这种部署产生大量数据，从中可以提取有用信息并将其共享给授权方，以增强(无论是与智能交通控制相关还是一般而言与智能运输相关的)服务供应，以及更好的公共安全服务。因此，雾计算被视为用于与许多应用实时地提取和共享数据的关键促成因素，本文公开的智能运输***是这些应用中的一种应用。

自动驾驶汽车有望在未来几年内成为现实。重要的是要根据交通状况的变化实时地维持安全速度。例如，一个区域中的危险可能造成其周围的车辆减速。但是，如果没有提前通知接近该区域的其它车辆，则许多汽车会进入该区域，其中许多车辆将需要在短时间段内减速或执行突然停车。这是不安全的，并且实际上可能造成该地区中的更拥挤的交通。最好采取积极主动的方法，并通知其它接近该区域的自动驾驶汽车以修改其速度。这使驾驶更加安全，并维持车辆不断进出上述区域，从而减少了总体交通。雾节点之间的此类操作推荐不仅限于速度信息，但是自动驾驶汽车的速度信息示出了此类过程如何增强雾计算所提供的任何服务。

云计算呈现了新的业务模型，该业务模型基于对实际资源使用收费，通常称为“随用随付”。保持这一点对于雾计算也可以是重要的。由于雾使动态环境能够用于部署服务，因此只有在服务提供商实际使用雾服务层时才对其收费是合理的。因此，服务提供商实际上可能并未在所有雾节点中实例化其服务和应用，而是当确实有用户希望使用其服务时，他们才这样做。

在驾驶和智能运输的情境中，应用层可以知道用户或车辆位置以及目的地和通往目的地的路线。由于我们可以假设雾节点部署在不同的区域，因此我们也可以假设服务或应用可以具有在由部署的雾节点服务的这些雾区域中的一些区域中的实例。但是，用户(例如，正在使用智能运输应用的用户)可能正在移动到由不同的雾节点服务的新区域，该新区域当前尚未在潜在的新雾节点上实例化智能传输应用。为了启用跨区域的服务连续性，源雾节点中的应用实际上可以请求源雾节点触发在相邻源雾节点或邻近的雾节点中的应用的实例化。照此，当用户移入该区域时，该服务将保持可用，而无需用户了解这个实时实例化。以这种方式，仅当用户实际消耗服务时，应用提供商才对于使用雾资源进行支付，而用户仍可以无缝访问该服务，尽管存在移动。除了在目标雾化节点中实例化应用之外，还可以使应用了解正在移入这些雾化区域的用户的用户情境，使得服务可以被无缝访问，而无需用户意识到由于移动性而引起的实例化或缺少服务。

另一个相关的用例是车辆中的乘客正在使用流式传输服务观看电影的用例。应用提供商知道车辆的目的地和路线。由于车辆在一个雾节点的区域下停留了一段时间，因此可能没有必要在一个雾节点中播放完整的电影。代替地，可以在直至目的地的整个车辆路线上准备数据(在这种情况下为视频流)。可以请求这些区域中的雾节点提前实例化应用，并且还可以为应用提供足够的信息以预测车辆可能处于托管雾节点的覆盖范围之内的时间以及应当在将数据递送给车辆之前缓冲多少数据。在这个用例中，假设雾节点具有与其连接的RSU，数据经由该RSU被发送到车辆。

用于雾计算的OpenFog参考体系架构根据需求提出了雾计算的概念，该需求解释了雾计算中各种参与者的角色，诸如芯片制造商、个体雾节点开发人员、雾节点网络的***集成商以及应用提供商(在雾节点上托管应用或服务)。该文档还呈现了使用雾的一些用例，其中之一是智能运输。作为总体描述的一部分，并且无论是什么用例(智能运输、智能电网等)，OpenFog参考体系架构都讨论了雾计算所需的重要功能，即，计算、存储、通信和分析。还讨论了雾节点之间以及雾和云节点之间的通信需求。但是，OpenFog参考体系架构没有描述实际启用雾节点之间的此类通信的任何过程。

还讨论了根据不同用例(其中一些与智能运输或交通场景有关)的雾计算概念，以及雾计算的优点，诸如减少延迟以及实时数据共享和分析等。但是，尚未定义示出雾节点的***可以如何进行交互以提取和共享数据的过程的集合。例如，参见以下内容：(i)M.Chiang和T.Zhang的“Fog and IoT:An Overview of Research Opportunities”，(ii)A.Jain和P.Singhal的“Fog computing:Driving force behind the emergence of edgecomputing”，以及(iii)X.Masip-Bruin、E.Marín-Tordera、G.Tashakor、A.Jukan和G.J.Ren的“Foggy clouds and cloudy fogs:a real need for coordinated management offog-to-cloud computing systems”。

因此，本文描述了当前缺少但与实现雾计算的概念和优点相关的过程，例如，使得能够从“事物”中提取数据、处理数据、共享数据并相应地响应数据的过程。应再次注意的是，虽然本公开呈现了针对智能交通应用用例的这些主题，但是问题和相关联的解决方案适用于可以受益于雾计算的所有其它用例。

为了提取、分析和共享跨雾节点的相关数据，重要的是定义雾节点通过其执行管理过程的方法，以使广泛的雾服务集合可用于部署层级结构中的若干垂直雾/云节点和其它雾/云节点。这些管理过程中的一些包括：

雾能力发现：雾节点通过其发现雾部署层级结构中不同级别的邻近的雾节点或其它雾或云节点的能力的方法。由于缺少这些过程，因此也缺少雾能力的定义。因此，雾能力的过程和定义(及其发现)目前均未指定。

雾可达性核实：雾节点通过其核实雾节点是否仍然可达的方法，以便在需要时向这些雾节点发送数据或从这些雾节点接收数据。

关于“事物”的状态的雾报告：雾节点经由其报告受其控制的“事物”的状态并从中可以提取相关数据的方法。例如，安装在特定街道十字路口的相机可以停止工作，并且其它雾节点或控制雾节点上的垂直应用可能需要更新有关这个状态，以便其它数据源可以用于维护服务可用性。类似地，需要定义报告从特定数据源或“事物”中恢复数据的过程。

在图5的示例中，假设在称为雾区域的每个区域或位置部署了本地雾节点(LFN)。而且，在这个位置，LFN连接到其它雾节点。考虑区域并因此考虑LFN，我们可以假设LFN连接到其它雾实体，或者也可以直接地连接到“事物”(例如，相机、速度传感器、交通信号灯等)或经由雾实体间接地连接到“事物”。照此，每个LFN被视为为智能运输***提供“服务层”的主要雾实体。

将这些图与所描述的问题联系起来，每个LFN可能需要执行雾管理程序以发现其邻居(即，LFN)的能力，以确保邻居仍然是可达的并向邻居通知“事物”的运行状态。例如，为了提供***范围的服务，可能需要管理过程以使雾区域1中的LFN与雾区域2中的LFN进行交互以发现能力、确保可达性并共享由这些LFN控制的“事物”的通知。

在运行管理过程之后(例如，雾节点发现了彼此的能力)，这些节点然后可以从其它雾节点接收服务或提供服务。当前，没有定义任何过程来指定这些雾节点如何彼此提供或接收服务或者向云提供或接收服务。照此，可以定义以下过程：

(1)雾服务请求的必要过程：雾节点中的功能如何在本地交互，以及雾节点如何彼此交互以提供或接收服务。例如，将使一个节点能够从处于邻近的雾节点控制下的相机请求视频馈送的雾节点的消息和行为是什么？

(2)支持跨雾节点的应用的需求的过程。这与雾节点与应用实体或雾节点与云之间的交互有关，目的是为应用层提供特定服务，诸如在雾节点上进行实时应用实例化、跨雾节点的应用层情境传送以及改进服务供应的其它过程。

参考图5，在LFN发现其它LFN的能力之后，一个区域中的LFN可能需要从另一个LFN获得雾服务(例如，来自特定街道中的速度传感器和相机的原始或经处理的数据)。需要启用此类交互以便在执行管理过程之后启用服务供应的过程。

公开了使用雾计算用于增强的服务供应的方法和***。雾计算涉及使用类云功能，这些功能托管在称为雾的节点的边缘处。雾节点具有计算和其它资源，包括存储、计算、分析、启用多种IoT协议(诸如CoAP、HTTP等)的处理的能力以及其它服务(诸如处理和响应安全应用消息(诸如通过IEEE WAVE消息发送的消息)以及使用若干接入技术支持发送和接收功能的能力)。雾节点可以提供本机服务，诸如跟踪、图像处理、控制致动器等。可以将这些服务水平地提供给其它雾节点，或者垂直地提供给在雾上运行的应用实例。雾节点一起提供雾服务层，该雾服务层还与被假设为监督雾操作的云实体进行交互，如以下示例解决方案中所讨论的：

(1)具有分层级雾节点部署的雾服务层体系架构，包括与云节点的共存和交互。该体系架构还可以包括托管在每个雾节点中的功能、能力或服务的列表。

(2)在雾节点(例如，FN和LFN)之间或在雾和云之间运行的雾管理过程。管理过程与雾节点的操作有关，因此与雾服务层有关。这些过程被视为雾操作的“控制平面”，包括：

(a)雾能力发现过程：使雾节点和云能够发现彼此的能力，其中能力包括计算、存储、分析和不同类型的IoT设备及其当前位置。其它能力可以是由雾节点本机提供的服务，诸如跟踪、经由不同的接入技术的发送和接收功能、处理和响应经由IEEEWAVE发送的安全应用消息等。因此，发现已经成为跨雾节点和面向应用的服务供应的前提条件，然后该应用可以请求与具体地理位置或服务点(例如建筑物、车辆等)相关的数据和服务。

(b)雾连接核实：这个过程允许雾节点周期性地核实它们的相互可用性。一旦核实后，雾节点就可以使用已通过核实的连接来链接和共享雾服务，以便维护水平雾服务层。

(c)雾能力状态报告：雾节点使用这个过程向其它雾节点或云报告其能力状态的变化，其中能力是本文描述的任何示例。该报告可以遵循显式(explicit)或隐式(implicit)事件订阅。

(3)雾服务过程：按照能力发现过程，则雾节点可以彼此交互以获取特定服务。本文呈现的雾服务过程分为两大类。以下是这些服务组的总结，下面将详细描述。

(a)用于雾服务供应的过程：这些是在雾节点之间执行的过程，目的是基于先前发现的雾能力向彼此提供服务。虽然这些过程可以由应用层触发，但是这些过程集中在雾交互上，以便跨雾和在雾中水平地提供可用服务。一旦将服务托管在雾节点上，如果需要，就也可以垂直提供服务或数据，或者可以由雾节点自身本机消耗服务或数据。

(i)雾服务请求过程：定义雾节点包括被提交给另一个雾节点的详细雾服务描述(FSD)的过程。目标雾节点可以使用FSD从指定的位置取出边缘数据、根据FSD对其进行处理，然后将其发送到源雾节点。

(ii)雾服务推荐过程：允许雾节点为构成雾服务层的雾节点集的整体增强操作建议参数。例如，可以在一系列雾节点之间广播具体消息，以控制自动驾驶汽车的速度，以便在由这些雾节点控制的区域中维持恒定的交通流。

(b)用于应用的雾支持服务的过程：这些是与应用层之间具有更紧密的交互的过程，应用层进而使用雾服务层跨雾区域水平地动态激活或重新定位其服务。

(i)雾应用实例化：这个过程允许应用基于由应用层跟踪的用户移动性而在其它雾节点上动态实例化同一应用的实例。这使得能够降低应用提供商的成本，该应用提供商仅在需要时(例如，在实例化应用时)对雾资源进行支付并因此仅在用户需要时才使用雾资源。

(ii)雾应用用户情境重定位：这个过程可以遵循实例化过程，或者至少假设应用实例已经在用户要移动到其区域中的目标雾节点上运行。然后，应用使用雾服务层将用户情境传送到目标雾节点上的目标应用实例上。然后，目标应用实例继续为用户提供服务，从而在移动期间实现全方位的无缝服务可用性。

(iii)基于预测的移动性模式进行应用准备的雾服务：该过程使应用层能够在预测的移动性模式之前实例化(如果需要)几个雾节点中的应用。而且，雾服务层使重要用户信息能够共享，从而使对应雾节点中的这些实例能够在用户移动到该区域之前准备服务(例如，缓冲视频数据)。一旦位于新雾节点的区域中，应用就仅仅将数据转发给用户，而不必等待用户请求服务。因此，雾服务层启用了主动服务可用性方法，该方法避免服务在用户移动期间被中断。

(4)本文还描述了用于一些雾管理过程的oneM2M实施例，即，用于通过检索操作实现的雾能力发现过程以及通过更新过程实现的雾能力状态报告过程。描述了GUI以示出具有FN和云的LFN的分层级部署以及链接到LFN的FE的类型。

图6示出了示例雾服务层体系架构，该体系架构由形成分层级部署的云和雾节点组成。在最高级别，存在云节点(CN)，它管理所有雾节点并知道它们的存在和能力。云节点(CN)和本地雾节点(LFN)可以使用雾到云接口进行交互。可以部署CN，使得其监视非常大的区域，该区域由若干较小的区域(称为雾区域)组成，每个雾区域由LFN监视。LFN共同提供雾服务层，该雾服务层能够使用雾到雾接口为在LFN上运行的垂直应用提供雾服务以及为彼此提供雾服务。服务可以包括从“事物”中提取数据、执行分析、共享数据等。LFN可以连接到作为具有雾能力的节点的雾实体(FE)。它们的能力可以与LFN的能力相同，或者它们可以是具有雾能力(存储器、计算、图像处理逻辑、有线或无线通信等)的智能相机、智能交通灯或具有雾能力的速度传感器。在智能运输用例中，FE是具有较小雾能力的FN类型，并且可以驻留在服务点(诸如咖啡店)中，并且它们进而可以控制“事物”，诸如相机、传感器，并且可以分别向这些“事物”发送数据或从这些“事物”接收数据。

FE也可以是驻留在其它重要建筑物或部门(诸如消防部门、医院、警察部门等)中的节点。此外，FE可以是基本的IoT设备，诸如传感器、相机、致动器等。照此，这些FE可以知道所报告的事件和可以将救护车、消防车、警车等派遣到的位置。FE可以收集此类信息或数据，并将其发送到与它们有连接的LFN。在LFN上运行的应用层可以仅与LFN进行交互，因此可能不知道可以与LFN连接的FE。FE可以对于雾应用层显示为“事物”。应注意的是，FE还可以托管其本地应用。但是，对于本文讨论的用例，应用层是指驻留在LFN上方的应用层。虽然FE也可以托管应用，但本文公开的应用层是指在LFN上运行的应用层。最后，在一个实施例中，在我们的体系架构中假设LFN本身是雾服务层的主要提供商，并且可以以对使用雾服务层的应用透明的方式使用来自FE或IoT设备的数据或服务。

仅作为示例，图6示出LFN 1连接到两个FE(FE 1a和FE 1b)，而LFN 2连接到一个FE(FE 2a)，并且LFN 3连接到FE 3a和FE 3b。但是，这些仅仅是示例，并不旨在将这种连接限制为所示的数量。应注意的是，在雾节点之间以及雾节点与云之间的接口上运行的实际协议不在本公开的范围之内。

如图4的示例中所示，一个LFN可以具有与其连接的多个FE。每个LFN可以具有其支持的能力或服务的集合。图7示出了LFN可以支持的这些能力或功能的示例。例如，如图7中所示，LFN可以具有以下功能中的一项或多项：

本地雾管理器(LFM)：LFN的一部分，基于雾服务提供商的策略来控制和管理所有功能。LFM授权来自其它LFN或来自LFN上运行的应用的服务请求。照此，LFM监视雾节点的所有资源，并管理如何将服务提供给应用或其它FE、LFN和云。

分析：LFN可以具有分析能力或功能，该分析能力或功能可以使用来自LFN所控制的来源(例如，相机、传感器等)的数据来执行数据分析，或者可以对从其它FE或LFN或云接收的数据执行分析。

相机：LFN或FE可以直接地连接少量或许多相机，或者经由另一个逻辑节点间接地连接少量或许多相机。相机功能表示将数据(例如图像或视频)馈入LFN的所有相机。照此，上面示出的“相机”功能可以表示LFN控制相机或来自相机的实际数据(图像或视频)的方法(例如协议或软件)。而且，相机功能还可以包含可以处理原始数据或可以执行图像处理或者可以处理已经在每个物理相机处潜在地处理过的图像的实体(例如软件)。

传感器：LFN还可以具有与其连接的许多传感器，这些传感器可以通过有线或无线方式发送数据。传感器可以是速度传感器、温度传感器、湿度传感器或任何类型的传感器。传感器可以使用各种协议来发送数据(例如CoAP、HTTP等)。LFN还可以具有能够接收和处理使用不同协议发送的消息的协议处理功能。

协议处理：LFN可以实现充当客户端或服务器或两者的若干协议。例如，LFN可以能够相应地处理CoAP、HTTP或其它协议。LFN还可以支持其它驾驶安全协议，使其能够接收和处理指示发生碰撞、突然停车或道路危险通知等的消息。应注意的是，协议处理功能是实现任何协议(例如CoAP、HTTP、IEEE WAVE)、协议消息和其它应用安全消息的任何功能的通用名称。LFN中可以有若干协议处理功能，以支持各种协议消息处理。虽然图7仅以“安全协议，例如IEEE WAVE”的形式示出了协议处理功能的一种实现，但这并不意味着LFN仅支持这种协议。

其它雾服务：LFN可以支持可以由垂直或其它LFN、FE或云请求或消耗的其它本机服务。例如，LFN可以支持跟踪服务，该跟踪服务被用于使用若干方法来跟踪车辆或人，诸如图像跟踪、使用无线技术的跟踪等。LFN可以支持多种此类本机服务。

致动器逻辑/控制：每个雾节点可以具有致动器逻辑来控制机械对象的操作，诸如门(例如在车库中)、相机朝向、切换交通信号灯等。

雾资源：每个LFN可以具有计算和存储资源以及数据库。

收费：雾节点可以为它们提供给垂直或其它雾节点的服务生成并维护收费记录。例如，雾节点对应用、分析或跟踪服务等的存储使用进行收费。

策略：每个雾节点可以具有策略功能，该策略功能包含必要的策略，以根据服务层协定(SLA)为垂直或其它雾节点授权服务并向其提供服务。例如，策略可以描述可以被提供给在雾节点顶部运行的应用的允许的计算、存储和分析资源。而且，策略可以包含有关允许向其它雾节点或垂直应用提供的服务类型的详细信息。例如，策略功能可以包含针对可能请求使用雾的跟踪服务的应用的雾服务描述。该描述可以指示是否应当使用以下来完成跟踪：视觉或无线感测或两者、可能的位置、与正在跟踪的主体相关的隐私问题(例如，在区域中检测到的人的图像可以以模糊的人脸被提供给公共***门)等。其它雾服务描述可以指示可以处理的请求的数量、是否可以将该服务外包或从其它LFN获得等。策略还可以包含允许托管在LFN上的应用ID的列表。

数据库：LFN可以对其本地使用或被垂直使用具有数据库支持。它可以提供数据库服务，或者它可以使用数据库来保存关于邻近的LFN、它们支持的服务以及支持这些服务的位置等的信息。

通信：每个雾节点可以支持若干通信协议，或者使用不同的介质和协议来进行发送(Tx)和接收(Rx)操作。例如，LFN可以支持以太网连接(例如，使用智能相机或其它FE)，或者无线技术的集合(诸如WiFi、蜂窝、蓝牙等)。应注意的是，Tx/Rx功能可以是不物理地位于LFN的接入点。例如，LFN可以使用有线连接来连接到部署在雾区域中的街道上的RSU。这些接入点可以接收包含安全应用消息的消息(例如WAVE)，并且可以将这些消息发送到LFN用于WAVE协议处理功能以对其进行相应的处理。类似地，LFN可以可选地在处理从相机、传感器等接收的数据之后做出本地决定，并决定将消息发送到区域中的所有车辆。应注意的是，可以将Tx/Rx功能(可选地使用具体技术，诸如WiFi和蜂窝)作为服务提供给在LFN上运行的应用。

其它功能：LFN还可以为与其连接的设备提供路由器和/或网关功能。照此，LFN可以支持必要的IP协议以支持路由器功能或其它相关协议，诸如邻居发现，诸如DHCP、DNS等。

应注意的是，上述功能是可以驻留在如图7中所示的LFN中的逻辑功能，或者它们可以是驻留在“事物”(诸如相机、传感器或其它FE)中的逻辑功能。照此，图7是例示雾节点如何能够提取并共享数据的示例，并且不意味着限制这些功能在特定物理节点中的放置。因此，可以在各个相机上实现相机功能，并且LFN可以与相机进行交互以获取图像和视频数据。而且，相机功能本身可以被视为雾节点或FE。

API可以用于上面示出的一个或多个功能或能力之间的通信。例如，可以是LFN本地的交通评估功能或服务(例如，它不在运行在雾顶部上的应用层的范围内)可以使用来自速度传感器、相机和安全协议处理功能的数据来确定交通状况。照此，这个服务(虽然未在图7中示出)可以使用API从这些源(例如，相机、传感器和安全协议处理功能)请求数据。附加地或可替代地，这些功能可以使用定义明确的接口与定义明确的过程进行交互。

LFN还可以托管应用，或者提供环境和资源用于应用和垂直在在LFN上运行。这些应用(一般称为应用层)在上述雾功能或服务顶部上运行，并且使用LFN的这些服务或能力。应用层可以托管许多使用API的应用，这些应用使用API从LFN或可替代地从LFN控制下的“事物”中获取原始数据或经处理的数据。例如，警察部门的应用可以在需要时从特定街道请求图像数据。LFN从相机功能(或可替代地从部署在识别出的街道或地址中的(一个或多个)相机)获取数据，这些数据可以是原始的或经处理的图像或视频。如果被授权获取这种数据，则LFN将数据转发给应用。作为另一个示例，驻留在LFN上的智能运输应用可以请求区域的特定街道中的交通信息。该请求还可以包含雾服务描述，该雾服务描述指示应当如何提供这个交通信息，例如仅使用计算平均车速的速度传感器或使用视频处理或两者。如果被授权，则LFN可以从部署在指示的(一个或多个)区域中的相机和速度传感器获取数据、相应地处理数据，然后将数据转发给应用。应注意的是，处理数据可以由具有这样做的功能的LFN完成，或者可以由“事物”本身完成。例如，相机可以具有允许它们能够处理图像的雾能力。附加地或可替代地，相机可以将图像和视频数据转发到LFN中的相机功能，然后LFN处理该原始数据并根据需要将其转发到应用层或其它LFN。

可以在雾节点之间或在雾与云之间运行管理过程。管理过程与雾节点的操作相关，因此与服务层相关。从不对实际数据进行操作或共享这些数据的意义上讲，这些过程可能不一定提供服务。这些过程可以被视为雾操作的“控制平面”。而且，这些过程中的一些过程在提供实际服务之前可能是必需的，而其它过程可以用于在执行关键初始管理过程之后核实雾节点的可用性。存在管理下的三个示例过程，即雾能力发现、雾连接核实和雾能力状态报告。以下是对示例过程的简要描述：

(1)雾能力发现：这个过程可以使雾节点和云能够发现彼此的能力。一些示例能力可以包括计算、存储、分析和不同类型的IoT设备及其当前位置，和/或在支持应用实例化方面的能力/约束(例如，某些类型的应用无法在一些雾节点处被实例化)。其它能力可以是雾节点本机提供的服务，诸如跟踪、经由不同的接入技术的发送和接收功能、处理和响应经由IEEE WAVE发送的安全应用消息等。因此，发现可以成为用于跨雾节点供应服务以及向随后可以请求与特定地理位置或服务点(例如建筑物、车辆等)相关的服务和数据的应用供应服务的前提条件。

(2)雾连接核实：这个过程可以允许雾节点周期性地核实其相互可用性。一旦被核实，雾节点就可以使用已核实的连接来请求、链接和共享雾服务，以便维护水平雾服务层。

(3)雾能力状态报告：雾节点可以使用这个过程向其它雾节点或云报告其能力状态的变化，其中能力是上面定义的任何示例。该报告可以遵循显式或隐式事件订阅。

在运行雾能力发现过程之前，可以假设LFN、FE和云已经发现了彼此。作为发现过程的一部分，LFN可以知道其它邻近的LFN的地址。应注意的是，雾到雾(F2F)接口(I/F)或雾到云(F2C)I/F可以是有线的或无线的。LFN的地址可以包括层二(L2)地址和/或IP地址两者。

可以假设在LFN发现其它LFN的能力之前，所讨论的LFN知道其自身的能力以及与其连接的FE及其能力。例如，LFN可以知道每条街道安装的相机的数量、每个相机的能力，诸如：支持静态图像、视频流、面部检测算法、红外能力、热检测等。还应注意的是，这些功能中的一些功能可以在LFN中或相机中实现。LFN还可以知道这些“事物”的位置以及能力、这些事物的身份、来自这些功能的数据的可用性等。

为了发现邻近的雾节点中的能力，LFN可以向其地址已知的目标邻居LFN发送雾能力发现请求消息。在这个消息中，源LFN可以在消息中指示以下参数：LFN ID、LFN地址、由该LFN覆盖的雾区域、该LFN中的能力或服务的列表、当前在该LFN上被实例化并运行的各自由唯一应用ID(例如，表示YouTube的ID等)标识的应用的列表。目标(例如接收方LFN)可以对能力发现请求授权，并以雾能力发现响应消息进行响应，该消息指示该LFN支持的能力或服务的集合。响应还可以包括：LFN ID、LFN地址、由该LFN覆盖的雾区域、该LFN中的能力或服务的列表、当前在该LFN上被实例化并运行的应用的列表以及这些应用的相应唯一应用ID。在这个过程之后，两种LFN都可以更新其关于邻居LFN的本地信息，以包括已发现其服务的LFN和地址信息等。图8示出了雾能力发现过程所涉及的示例步骤。

在步骤1中，LFN 1(源LFN)向其地址可能已被LFN 1知道的LFN2(目标LFN)发送雾能力发现请求。该消息可以包括与源LFN相关的以下信息：LFN ID、LFN地址(例如IP地址或L2地址或两者)、指示源LFN正在服务的区域的雾区域、(可选)源LFN中支持的能力的列表、以及当前正在源LFN上运行的应用的列表。

注意：上面消息中包括的“支持的能力”信息元素可以表示支持的服务和可用于提供数据的“事物”及其部署位置的详细列表。能力的列表的示例是上一节中先前描述的那些能力，诸如相机功能、速度传感器、分析、邻居LFN可用的存储器、具体协议处理功能(例如LFN可以指示其支持安全应用协议或WAVE消息传送)、用于Tx/Rx功能的接入技术、其它本机服务(诸如跟踪服务等)。对于这些能力中的每一个能力，LFN可以包括雾服务描述的详细列表，以详细描述LFN可以递送的数据或服务的确切类型。作为示例，仅出于说明的目的，考虑先前描述的相机功能。针对这个功能的支持的能力可以包括以下项：

名称：这指示这个功能的名称(例如“相机”)。

LFN覆盖的雾区域之下部署每个相机的位置。地址可以是例如地理位置，或者是坐标的形式，或者是具有邮政编码的街道地址。

每个相机可以提供的数据类型(例如图像、视频、红外图像)以及可以对相机数据进行的处理类型(例如面部检测、车牌识别等)。

每个相机是固定的还是可以平移、缩放或倾斜(PTZ)的。如果是固定的，则相机指向的方向(例如，北、南等)或这个相机的倾斜角度等。

作为另一个示例，与速度传感器相关的支持的能力信息元素可以包括以下中的任何一项：

名称：这指示这个功能的名称(例如“速度传感器”)

LFN覆盖的雾区域之下部署每个传感器的位置。地址可以是地理位置，或者是坐标的形式，或者是具有邮政编码的街道地址。

可以计算速度(例如某个时间窗口内的平均速度)的方法、可以计算平均速度的周期性、平均速度信息的历史、可以维持先前平均速度的计算的最大过去时间、可以提供的速度单位(诸如Km/hr、Miles(英里)/hr等)。

雾节点可以在雾能力发现过程期间隐式地订阅有关特定服务或“事物”的状态的通知。通过在雾能力请求消息中包括通知订阅(Notif.Subs.)指示来完成这个隐式订阅。雾能力发现响应消息还可以包括这个隐式订阅的结果，即，指示该订阅是否被接受的通知响应(Notif.Rsp.)。例如，服务/事物通知指示信息元素可以被包括在雾能力发现请求消息中。这向目标LFN指示每当目标LFN中的特定服务/功能/事物的状态改变时都应当发送状态通知。例如，如果在目标LFN控制下的相机停止工作，并且目标LFN意识到这一点，则目标LFN检查要求此类通知的所有源LFN。对于隐式订阅这种通知的每个LFN，如上所述，目标LFN可以发送指示以下内容的通知消息：

受影响的服务或能力或功能的名称，例如速度估计服务。

为其发送这种通知的每个服务的位置

其状态已改变的“事物”(例如速度传感器、相机等)的列表。应注意的是，相同的通知过程可以用于指示服务或事物可用或不可用。

为其发送这种通知的每个“事物”的位置。例如，如果三个相机已经在不同位置停止工作，则每个识别出的相机(或一般而言“事物”)可以与操作状态和位置相关联。

在一个实施例中，每个能力或服务或功能可以具有其特有的信息。例如，相机的倾斜是相机的特定信息，该信息可能不适用于速度传感器。照此，需要注意的重要一点是，所发现的信息提供了对已部署的“事物”、其位置、可以从中提取的数据的类型、可以对数据执行的处理类型的详细描述。而且应注意的是，这种数据的处理是在LFN中还是在“事物”(以及因此FE)自身中进行都没有关系，因为数据可以来自连接并控制这些数据源的LFN(即“事物”)。这种信息还可以包括支持的服务、数据源或IoT设备的总结。例如，除了(或代替)指示每个相机源的详细信息，LFN还可以包括关于支持的相机或连接到LFN的其它IoT设备的最大数量的信息。

在步骤2中，在接收到发现请求消息后，目标LFN核实是否授权向源LFN提供目标LFN的支持的能力。每个LFN以及因此在这种情况下的目标LFN(即，LFN 2)可以包含指示哪个邻居LFN(由LFN ID表示)被授权获取这个信息的策略。如果这个信息可用，则目标LFN确定源LFN是否被授权发现目标LFN的能力。目标LFN还可以将支持的服务存储在源LFN中。

在步骤3中，如果目标LFN不具有针对源LFN的授权信息，则目标LFN可以随后与云节点联系以请求对源LFN的授权。目标LFN将雾能力发现授权请求消息发送到云。该消息包括源LFN的LFN ID、其雾区域及其LFN地址。

在步骤4中，云可以使用其本地策略和信息来确定授权，并以指示授权的结果的雾能力发现授权响应消息进行响应。

在步骤5中，目标LFN可以在本地存储对源LFN的授权结果。然后目标LFN可以将雾能力发现响应消息发送到源LFN。该消息指示与目标LFN(即，LFN 2)相关的以下信息：LFNID、LFN地址(例如IP地址或L2地址或两者)、指示目标LFN正在服务的区域的雾区域、(可选)目标LFN中支持(并因此获得授权)的能力的列表、以及当前正在目标LFN上运行的应用的列表和可达性定时器。上面已经描述了除可达性定时器以外的这些信息元素。可达性定时器指示源LFN可以用来发送消息以用于确定目标LFN是否仍可达的周期性，如接下来可以呈现的。源LFN存储目标LFN中的支持的服务。

如果源LFN(即，LFN 1)也隐式地订阅了关于目标LFN的服务和/或“事物”的状态的通知，则目标LFN也可以保存这个信息，使得当目标LFN之下的特定能力或服务或事物发生改变时，可以将通知发送到订阅这个通知的所有源LFN。

虽然在以上步骤中未示出，但是目标LFN(即，LFN 2)也可以确认对目标LFN能力的隐式订阅，如本文所述。例如，目标LFN可以包括服务/事物通知确认信息元素以确认经处理的订阅。进而，目标LFN也可以通过在雾能力发现响应消息中包括单独的服务/事物通知指示信息元素来隐式订阅来自源LFN的类似通知。源LFN可能不需要确认这种隐式订阅。但是，源LFN保存这个信息，并在其支持的能力的状态发生改变时通知目标LFN。

为了维持取决于跨雾节点以及跨雾节点和云共享数据的雾服务层的可用性，雾节点可能需要周期性地核实它们的相互连接。因此，本文提出了一种过程，其中雾节点通过该过程执行指示邻居雾节点的可用性的简单的“心跳”或请求-响应握手。重要的是应注意，这个过程可能不指示特定服务的可用性或来自某些“事物”的数据的可用性，而是可能仅向雾节点通知每个雾节点的控制逻辑或本地雾管理器是可达的。基于这种核实，雾节点确定邻居LFN的可达性和可用性，并继续彼此通信以提供雾服务层。

每个LFN可以被配置为向每个邻居LFN发送雾连接核实请求消息。可以周期性地发起该过程，并且LFN可以被配置有这个过程的周期性。云节点或级别高于LFN的任何雾节点可以使用这个信息来配置LFN。可替代地，执行雾能力发现过程(如前所述)的雾节点可以承担起动这个过程的实体的角色。应注意的是，雾节点虽然未发起雾能力发现过程，但也可以用定时器来配置，使得如果未从源雾节点接收到消息，则所讨论的雾节点仍可以发送消息以核实实际先前已发起雾发现过程的源雾节点的可用性。该过程的周期性可以在LFN中被预定义或预配置。可选地，能力发现过程的响应(如前所述)可以包含源LFN向其发送了雾能力发现请求消息的目标LFN所建议的周期性。这在先前被提出作为目标LFN包括在雾能力发现响应消息中的可达性定时器信息元素。LFN使用上述任何选项确定发送雾连接核实消息的周期性，然后将消息发送到目标LFN。雾连接核实的示例过程在图9中示出。应注意的是，当从正在对其执行连接核实的目标雾节点接收到响应时，可以重置周期性定时器(无论是配置还是基于可达性定时器信息元素)。

应注意的是，图9中所示的过程可以在LFN之间、在LFN与不同级别的雾节点之间、或者在LFN与云之间运行。应注意的是，每个LFN可以与其邻居LFN一起运行这个过程。

在步骤1中，LFN使用本文描述的任何方法确定起动连接核实过程的时间或周期性。LFN可以具有定时器，该定时器保护这个过程的起动时间，并且LFN可以在其到期后发送以下步骤2中描述的消息。应注意的是，这个消息还可以包括关于LFN 1的资源使用或可用性的信息。例如，LFN 1可以包括关于一些重要资源(诸如存储器、CPU、电池、负荷级别等)的信息。

在步骤2中，LFN将雾连接核实请求消息发送到目标云、雾节点或邻居LFN。应注意的是，这个消息可以以广播方式发送或被发送到形成特定雾组的节点集合。LFN可以包含它们可以使用的此类广播或组信息。响应(即，下面的步骤3中描述的消息)可以以单播方式发送。

在步骤3中，目标节点接收消息并更新指示其仍可达的源雾节点的可达性。目标节点以雾连接核实响应消息来响应源节点。目标节点可以为可达性定时器建议不同的值。源节点相应地更新这个目标LFN的可达性，并且如果提供了新的可达性定时器值，则源节点将使用这个值来更新这个过程的周期性。应注意的是，这个消息还可以包括关于LFN 1的资源使用或可用性的信息。例如，LFN 1可以包括关于一些重要资源(诸如存储器、CPU、电池、负荷级别等)的信息。

本文描述了用于报告由LFN提供的至少一项服务(例如，跟踪服务或相机服务的红外图像等)的状态或者报告至少一个“事物”(例如，相机、速度传感器、光传感器等)的状态的的示例过程。还包括所讨论的“事物”或服务的位置，例如，如果报告相机已停止工作，则还应当报告相机的位置，以便接收到这个通知的节点可以准确理解雾服务可能如何受到影响。应注意的是，报告状态可以意味着服务或“事物”不再可用，或者服务或“事物”现在可用，或者添加了新服务等。还可以相应地定义其它状态。

图10示出了用于向其它LFN、雾节点或云报告至少一个雾能力的状态的示例过程。应注意的是，虽然已经描述了通知的隐式订阅，但是LFN、雾节点或云也有可能显式地订阅通知。

在步骤1中，云节点、雾节点或LFN可以显式地订阅，以便得到关于某些雾能力的状态的通知。为此，节点可以发送雾能力状态订阅请求，其中指示位置和与该位置相关联的能力描述。照此，雾节点可以包括与期望通知的位置相关联的服务的列表。能力描述描述了期望通知的特定“事物”或服务。LFN ID、LFN地址和雾区域与LFN 2相关联。

在步骤2中，虽然未示出，但接收方LFN使用本地策略来授权请求。接收方LFN(在这种情况下为LFN 1)发送雾能力状态订阅响应”消息，该消息包括列出的每个能力描述的结果。LFN ID、LFN地址和雾区域与LFN 1相关联。

在步骤3中，LFN可以已接收到对于关于其在某些位置的能力的状态的通知的隐式或显式订阅。在检测到服务(例如，跟踪服务)或“事物”(例如，相机停止或恢复其功能)的状态的改变后，源LFN(LFN 1)向已订阅这个通知的目标LFN发送雾能力状态通知。该消息可以包括这个通知相关联的服务的详细信息、位置、实际状态以及这个状态发生改变的时间。再次应注意的是，可以为状态定义不同的值(例如，“工作”、“不工作”、“开”、“关”等)。

在步骤4中，目标LFN(LFN 2、云或雾节点)接收消息并对其进行处理以确定受影响的服务和位置。LFN可以具有正在使用任何受影响的服务的在该LFN上运行的应用或连接到该LFN的其它FE。然后，LFN将关于能力和位置的更新后的状态通知给所有应用或其它FE。目标LFN发送雾能力状态通知确认消息以确认该报告。应注意的是，这个消息的接收可以可选地重置可达性定时器。

应注意的是，在LFN 1处，可以存在LFN上运行的应用，这些应用先前使用其状态已改变的这些能力中的任何能力。而且，当特定位置处的能力或服务的状态改变时，应用可能已使用API来订阅通知。照此，LFN还可以使用API向(一个或多个)应用指示哪些能力已发生状态改变、它们的位置、实际状态以及状态改变的时间。

遵循能力发现过程，雾节点然后可以彼此交互以获取特定服务。例如，雾节点可以使用来自该雾节点的控制之下的相机和传感器的数据。可以对这种信息进行处理以确定交通负荷，然后可以将交通负荷提供给在雾节点上运行的应用(例如，智能运输)，或提供给公共安全应用(诸如救护车服务)，用于检测并选择具有到达目的地的最短时间的路线。雾节点可以提供的另一种类型的服务是它们之间的数据共享。例如，应用可以要求关于在另一个LFN的控制下在特定目的地的停车位的可用性的数据。可以触发托管应用的源LFN，以从目标LFN获取这个服务。目标LFN可以监视停车位的可用性并将该信息提供回源LFN，源LFN进而将其提供给应用。公共安全运输应用的另一个示例是请求雾节点使用其Tx/Rx功能首先接收安全应用消息、确定碰撞的发生，然后将此事件或类似事件报告给安全应用或部门。此外，雾节点可以广播消息以向其它车辆通知事件和位置。然后，车辆可以决定使用其它路线，并有助于公共安全车辆在较少拥堵的情况下到达现场。而且，雾节点可以与邻居雾节点共享这个信息，使得车辆在进入发生事故的雾区域之前主动选择不同的路线。本文讨论了针对某些用例的其它示例和解决方案。但是，重要的是应注意，本文呈现的用于雾计算的解决方案不仅限于智能运输的用例。代替地，这个应用仅仅是示出雾的益处的示例，并且所提出的过程可以应用于所有用例，因为它们专注于雾节点之间的交互以实时提取、共享和分析数据。下面讨论一些示例雾过程：

(1)雾服务供应的过程：这些是在雾节点之间执行的过程，目的是基于雾能力的先前发现向彼此提供服务。虽然这些过程可以由应用层触发，但是这些过程集中在雾交互上，使得服务跨雾和在雾中水平地可用。一旦服务到达雾节点，如果需要，服务或数据就也可以提供给垂直方向，或者可以由雾节点本身本机消耗。

(a)雾服务请求过程：定义过程，通过该过程雾节点包括被提交给另一个雾节点的详细雾服务描述(FSD)。目标雾节点使用FSD从指定位置(或这些位置的FE)取出边缘数据、根据FSD对其进行处理，然后将其发送到源雾节点。

(b)雾服务推荐过程：允许雾节点为构成雾服务层的雾节点的集合的整体增强操作建议参数。例如，可以跨一系列雾节点广播具体消息，以控制自动驾驶汽车的速度，以便在由这些雾节点控制的区域中维持恒定的交通流。

(2)与应用的雾服务相关的过程：这些是与应用层具有更紧密交互的过程，而应用层进而使用雾服务层来跨雾区域水平地动态激活或重定位其服务。

(a)雾应用实例化：这个过程可以允许应用基于用户移动性和由应用层跟踪的其它信息在其它雾节点上动态地实例化同一应用的实例。这使得能够降低仅在需要时(例如，实例化应用，因此仅在用户需要雾资源时才使用雾资源)才为雾资源付费的应用提供商的成本。

(b)雾应用用户情境重定位：这个过程可以遵循实例化过程，或者至少假设应用实例已经在用户要移动到其区域中的目标雾节点上运行。然后，应用可以使用雾服务层将用户情境传送到目标雾节点上的目标应用实例上。然后，目标应用实例可以继续为用户提供服务，从而在移动期间实现全方位且无缝的服务可用性。

(c)基于预测的移动性模式进行应用准备的雾服务：这是使应用层能够在预测的移动性模式之前实例化(如果需要)几个雾节点中的应用的过程。而且，雾服务层使得能够共享重要的用户信息，从而使对应雾节点中的这些实例能够在用户移动到该区域之前准备(例如缓冲视频数据)服务。一旦位于新雾节点的区域中，应用就可以简单地将数据转发给用户，而不必等待用户请求服务。因此，雾服务层启用主动服务可用性方法，该方法避免由于用户移动性而导致服务中断。

雾服务请求过程用在雾节点之间或雾节点与云之间，以请求特定服务。服务可以是来自相机、传感器等的数据，并且数据可以是原始数据或经处理的数据。该服务还可以与分析相关，例如，雾节点可以先前已发现特定的邻居雾节点支持特定的分析解决方案。然后，雾节点可以执行这个服务请求过程以请求这个服务。如果被接受，则雾节点可以将数据转发到目标LFN，然后由目标LFN对数据执行分析并将结果发送回去。其它类型的服务可以包括请求目标LFN提供交通信息，该交通信息可以基于速度传感器读数、图像处理、WAVE消息的处理等。单个服务请求过程可以列出由请求ID标识的多于一个服务。该服务还可以与源LFN期望将数据或服务发送到的地址相关联。这个地址可以包括IP地址、端口号、层2地址、应用层身份等。发出请求的LFN还可以指示用于该服务的协议和/或传输，诸如UDP上的SIP等。

在一个方面，示例方法可以包括：从应用接收提供服务的请求，其中提供服务的请求包括与服务相关联的雾服务描述；基于与服务相关联的雾服务描述，确定第二本地雾节点被配置为提供服务；向第二本地雾节点发送对提供服务的请求的指示；从第二本地雾节点并基于对提供服务的请求的指示接收服务结果；向应用发送服务结果；以及更新存储在第一本地雾节点处的信息，以指示第二本地雾节点被配置为提供服务。

提供服务的请求还可以包括与应用相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。对提供服务的请求的指示可以包括以下中的一个或多个：与第一本地雾节点相关联的标识符、与第一本地雾节点相关联的雾区域的标识符、与应用相关联的标识符以及与执行服务的请求相关联的标识符。存储在第一本地雾节点处的更新后的信息可以包括与第二本地雾节点相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

该方法还可以包括在发送对提供服务的请求的指示之前确定存储在第一本地雾节点处的一个或多个策略是否指示应用被授权接收服务。第二本地雾节点在发送服务结果之前可以确定存储在第二本地雾节点处的一个或多个策略是否指示第一本地雾节点被授权接收服务结果。第二本地雾节点可以被配置为向云节点并且响应于确定在第二本地雾节点处未存储指示第一本地雾节点被授权接收服务结果的一个或多个策略而发送对授权第一本地雾节点接收服务结果的请求。

图11中示出了LFN内部的功能之间以及源LFN和目标LFN之间提供服务的示例交互。再次应注意的是，LFN内的功能实际上可以是不驻留在LFN中的逻辑功能，并且这个示例示出LFN中托管的智能运输服务(STS)仅作为示例。STS表示提供关于交通的信息的服务，诸如但不限于特定街道的交通的视频流、使用速度传感器和图像的交通描述以及可能的安全应用消息、交通预测等。无需说明STS如何计算实际交通数据或信息，调用流即可示出该过程。可以假设具有STS(称为STS 1)的LFN 1先前已经发现在LFN 3处支持STS能力或服务(称为STS 3)。

在步骤1中，托管在LFN的应用层范围中的应用使用定义明确的API来请求服务。该应用可以与用于自动驾驶汽车的智能运输应用相关。该请求可以包括以下的列表：雾服务描述(FSD)和请求ID。雾服务描述包含与每个服务相关联的位置信息。API请求还可以包括请求这个服务的应用的身份。应注意的是，虽然图11示出了使用API从LFN请求服务的雾节点所运行的应用实例，但是在移动设备(诸如智能电话或车载设备)上运行的应用可以使用相同的API集合。照此，应该理解的是，图11无意将此类API的使用限于仅在LFN上运行的应用，并且相同的API适用于在与LFN进行交互的移动设备上运行的任何应用。

在步骤2中，LFN 1中的LFN管理器处理请求，并基于FSD中所包含的位置信息来确定服务是否可以由LFN 1或目标LFN提供。假设LFN 1知道负责在其它位置或雾区域提供服务的LFN。照此，LFN管理器1基于这个本地信息确定LFN 3是提供这个服务的目标LFN。应注意的是，为简单起见，这个调用流仅示出一个目标LFN，但是，该请求可以具有若干位置的FSD，这可以使得LFN 1与多于一个目标LFN联系以提供服务。虽然在这个步骤中未示出，但是LFN 1可以核实其本地策略，以确定(用应用ID标识的)特定应用是否被授权获得这个服务。如果这个信息不可用，则LFN 1可以联系云或雾节点以授权这个请求。这样做的过程与下面的5a和5b类似，但是内容可以有所不同，因为消息也可以包括应用ID，以便云可以执行服务授权。而且，消息名称可以不同。

在步骤3中，LFN 1(即，LF管理器1)向目标LFN(此处为LFN 3)发送雾服务请求消息。源LFN(此处为LFN 1)可以提供其LFN ID、雾区域和以下各项的列表：雾服务描述、请求ID、源地址(表示应当被用于将数据递送到源LFN的地址)、要使用的期望协议等。应注意的是，此处的“地址”可以意味着IP地址、端口号、层2地址等。虽然图中未示出，但是这个消息还可以包括应用ID，以向目标LFN指示由指定的应用ID触发并供其使用的数据或服务。

在步骤4中，LFN 3检查其本地策略，以确定是否允许源LFN获取这个服务，(如果提供的话)还可选地针对所指示的应用ID。

在步骤5a中，如果LFN 3不具有这个信息，则它可以联系云或雾节点以授权该请求。LFN 3将雾服务授权请求消息发送到云，并指示FSD和相关联的请求ID、源LFN ID以及可选地应用ID(如果在上述请求中接收到的话)的列表。

在步骤5b中，云节点执行授权检查，并以雾服务授权响应进行响应，该响应包括针对每个FSD的授权结果。这个消息还可以包括原因代码，以指示如果不允许特定的FSD则拒绝任何FSD的理由。如果允许并授予特定的FSD，则被接受的FSD可以与实际请求的FSD不同。

在步骤6中，LFN 3核实授权的结果，并且如果没有任何FSD被允许，则LFN 3发送雾服务响应消息，该雾服务响应消息指示结果，该结果的值将被设置为例如“拒绝”或指示请求未被授权的任何其它值。该消息还可以包括原因代码，以描述拒绝的理由。如果发生这个步骤，则过程结束。

在步骤7中，LF管理器3与策略功能(此处为策略3)通信，以记录具有FSD、请求ID、要使用的源地址、协议等详细信息的传入请求。这可以通过向策略功能发送更新策略请求消息来完成。可以认为策略功能是到LFN内的服务或适当功能的服务的分派器。应注意的是，这可以是逻辑功能，该逻辑功能也可以是LFN管理器功能的一部分。该调用流仅示出了针对这个用例的LFN逻辑和行为的可能实施方式的示例。

在步骤8中，策略3功能分析请求，并基于FSD来确定负责处理这个服务的目标能力或功能或服务的列表。可以假设只有一个与STS服务(此处为STS 3)相关的FSD。策略功能联系实体(该实体可以是雾实体本身)或STS(此处为STS 3)的服务或功能。策略功能可以发送服务请求消息(其也可以被实现为雾服务请求消息)，该消息可以包括源LFN的身份标识、应当用于发送数据的地址、请求ID、要使用的协议以及FSD。

在步骤9中，STS 3分析请求，并以下面的列表进行响应：接受的FSD、要使用的对应协议、目标地址(该目标地址是STS 3本身的地址)、请求ID以及与每个FSD对应的结果。

在步骤10中，策略功能保存如STS 3所允许的接受的FSD、请求ID、针对每个请求ID或FSD的源地址和目标地址、要使用的协议以及请求的结果(例如接受)。策略功能可以向LFN 3管理器发送更新策略响应消息，并转发与每个FSD、请求ID和可以从其发送数据的对应目标地址、要使用的协议等相关联的结果。

在步骤11中，LF管理器3向LFN 1发送雾服务响应，该雾服务响应包括以下中的一项或多项的列表：请求ID、FSD、结果、协议和可以从其发送这个服务的目标地址。此时，LFN1和LFN 3以及这些LFN中的对应功能可以知道特定请求的源地址和目标地址两者，该特定请求由请求ID标识并具有相关联的FSD和要用于服务递送的协议。应注意的是，这个步骤可以暗示过程的成功，因此意味着可能尚未执行步骤6(因为这将意味着拒绝整个过程)。

在步骤12中，LF管理器1与策略功能(此处为策略1)进行通信，以通过发送更新策略请求消息来记录来自LFN 3的未决(pending)服务，该更新策略请求消息包括以下中的一个或多个：请求ID(各自与FSD相关联)、用于每个请求的相关联的源和目标地址、以及与FSD相关联的协议的列表。

在步骤13中，策略1功能分析请求，并基于FSD确定负责处理(在这种情况下为接收)这个服务的目标能力或功能或服务的列表。在此，假设仅存在一个与STS服务(此处为STS 1)相关的FSD。策略功能联系用于STS(此处为STS 1)的实体(其自身可以是雾实体)或服务或功能。策略1功能发送服务请求消息(也可以被实现为雾服务请求消息)并且包括目标LFN的身份标识、雾区域、这个服务的源和目的地地址、FSD以及相关联的请求ID和协议中的至少一个。应注意的是，虽然未示出，但是这个消息还可以向STS 1指示从LFN 3接收到这个数据之后该数据的目的地是本地应用。还可以在这个消息中提供应用ID，以用于后续数据递送(如步骤17中所述)。

在步骤14中，STS 1功能分析服务请求并添加/更新其本地信息，以便现在包括所指示的服务以及消息中提供的详细信息(例如，FSD、使用的地址、协议等)。

在步骤15中，STS 1用指示与每个请求ID相关联的结果的服务响应消息进行响应。

在步骤16中，策略1功能用所指示的结果来更新针对每个请求ID的日志，并用更新策略响应消息向LFN 1管理器响应，该更新策略响应消息指示与每个请求ID和FSD等相关联的结果。

在步骤17中，此时，LF管理器1可以知道与来自应用的请求相关联的每个FSD的结果。LF管理器1使用应用服务响应API来向应用通知关于初始服务请求的结果。

在步骤18中，LFN 3(可选地为LFN 3的STS 3功能)从“事物”或其它本地能力接收数据，并根据针对每个请求ID的FSD来处理数据。然后可以使用相关联的源和目的地地址以及所选择的协议将数据递送到目的地。可以发送数据递送消息，该数据递送消息可以包含数据的内容和相关联的请求ID。

在步骤19中，LFN 1(可选地为LFN 1的STS 1功能)接收针对相关联的请求ID的数据。STS 1可以知道这个数据的目的地(例如，在雾节点上运行的应用)。然后，STS 1可以使用众所周知的应用数据递送API将数据及其相关联的请求ID转发到适当的应用。STS 1还可以指示从其接收数据的雾区域和LFN ID。应注意的是，STS 1还可以根据FSD和与FSD相关联的策略以及与发出请求的应用相关联的潜在SLA协议对数据进行一些处理。

公开了可以用来推荐服务操作或与服务供应相关的参数的过程。这个过程可以用于向邻居雾节点通知一个雾节点的选定的操作，以便邻居可以考虑具有类似特点的操作，以便跨雾部署区域提供类似的服务和体验质量。可以受益于这个过程的一个示例用例是具有智能运输服务的雾节点，其可以检测交通状况并确定在其雾区域内自动驾驶汽车使用的最优速度。但是，为了维持进入所讨论区域的交通流恒定且均匀，雾节点随后将操作推荐(在这个示例中为推荐速度)发送给邻居雾节点。进而，邻居雾节点考虑这个信息并且可以基于此信息来微调其操作。例如，邻居雾节点可以确定进入源雾节点的区域的车辆的速度降低。这使得进入和离开发起该推荐的雾区域的交通流均匀。再次应注意的是，这个过程以自动驾驶汽车的推荐速度为例进行了解释，但是，这个过程不仅限于推荐速度。类似地，像先前的过程一样，雾节点可以在发往邻居雾节点的消息中包括FSD，其中FSD被解释为包含针对具体服务的推荐。

在一个示例中，第一设备可以被配置为接收与由第一设备提供的服务对应的数据、基于接收到的数据来更新由第一设备提供的服务的一个或多个参数、并且向第二设备发送关于一个或多个更新的参数的信息，该信息使第二设备更新由第二设备提供的服务的一个或多个参数。

在图12的示例中，LFN可以提供独立于在LFN的应用层范围中运行的智能运输应用的本机智能运输服务(STS)，但是智能运输应用可以使用STS的服务。在这个过程和调用流中，STS可以搜集信息或消耗LFN的其它能力的服务，诸如来自相机和速度传感器功能以及来自LFN的Tx/Rx功能的服务。可以假设STS还能够处理可以通过WAVE消息发送的安全应用消息。在图12所示的调用流中，可以假设STS已请求使用相机和速度传感器功能的服务。

在步骤1a中，相机功能可以接收针对其创建策略的数据，使得必须将服务递送到STS。相机功能可以知道与每个请求ID相关的FSD(类似于图11的步骤13-15中已经描述的内容)。相机功能可以根据FSD来处理数据，并且可以知道与该数据相关联的动作，例如，在这种情况下相机功能应当将经处理的数据发送到STS。

在步骤1b中，类似于步骤1a，速度传感器功能接收已为其创建策略的数据，因此必须将服务递送到STS。速度传感器功能可以知道与每个请求ID相关的FSD(类似于图11的步骤13-15中已经描述的内容)。速度传感器功能可以根据FSD来处理数据，并且可以知道与该数据相关联的操作，例如，在这种情况下，速度传感器功能可以将经处理的数据发送到STS。速度传感器功能然后可以将数据转发到STS，并包括与该数据相关联的请求ID。再次应注意的是，相机或速度传感器功能可以是不位于LFN中的独立FE。

在步骤2a中，相机功能然后可以将数据转发到STS，并包括与该数据相关联的请求ID。再次应注意的是，相机或速度传感器功能可以是不位于LFN中的独立FE。

在步骤2b中，速度传感器功能然后可以将数据转发到STS，并可以包括与该数据相关联的请求ID。再次应注意的是，相机或速度传感器功能可以是不位于LFN中的独立FE。

在步骤2c中，STS功能可以能够接收承载(carry)安全应用的WAVE消息。STS可以接收WAVE消息，该WAVE消息指示例如在道路上检测到的危险或由车辆报告的事故。

在步骤3中，基于在步骤2a、2b和2c中接收到的信息或服务，STS确定有必要通知车辆降低其速度以避免风险并避开交通。该确定基于STS的逻辑。

在步骤4中，STS使用LFN的发送功能，以使用一种或多种接入技术和协议来广播推荐速度。例如，STS使用具有WiFi接入技术能力的RSU来发送WAVE消息。WAVE消息包括推荐速度信息，自动驾驶汽车可以接收该速度信息并相应地调整其速度。

在步骤5中，基于STS和/或LFN的本地策略，STS向邻近的LFN发送雾服务推荐消息-但是该流程出于简化的目的而仅示出一个。应注意的是，这个消息也可以由LF管理器代替STS发送。在这种情况下，STS首先与LF管理器进行通信并提供要包括的必要信息。该消息可以包括FSD、LFN ID和与始发LFN相关的雾区域，其中该FSD进而可以包含针对其包括操作推荐的服务的详细信息。应注意的是，LFN和/或STS可以具有这个消息应被发送到的邻居LFN的列表。可替代地，这个消息可以被发送到云，因此这个步骤考虑了接收方是邻居LFN或者云节点的两种选择。如果发送到云，则云可以基于其策略将推荐操作转发到必要的邻居LFN。

在步骤6中，如果消息被发送到云，则云可以基于本地策略确定哪些邻居LFN应当接收这个消息。云然后可以将雾服务操作推荐消息发送到邻居LFN(在此是LFN 3)。应注意的是，该消息可以被发送到LF管理器，该LF管理器然后经由策略功能如先前已经在图11中描述的那样(例如，步骤7至9)将该消息转发到适当的功能(例如，LFN 3中的另一个STS服务)。如果接收方是LFN，则同样适用于上述步骤5。

在步骤7中，LFN 3通过向云发送回雾服务操作推荐确认消息来确认接收到推荐。

在步骤8中，雾节点或云通过将雾服务操作建议确认消息发送回源LFN来确认接收到推荐。

在步骤9中，LFN还可以向可以从中受益的应用(诸如智能运输应用)发送类似的推荐。LFN可以具有定义应该向哪些应用提供此类推荐的策略。STS可以将应用服务操作推荐消息发送给应用。这可以包括FSD、雾区域和其起源的LFN ID。虽然它起源于LFN，但是如果LFN首先从邻居或从云中接收到这个信息，然后将该信息转发给应用，然后应用知道该信息与另一个雾区域有关并且因此可以根据需要采取必要的决定(例如在进入该区域之前向用户通知此类推荐)，则这个信息是有帮助的。

在步骤10中，应用利用应用服务操作推荐确认消息进行响应，以确认接收到推荐的参数。

公开了使得应用请求与在其它雾节点中实例化同一应用相关的服务，以及在应用层处将用户的情境从一个雾节点中的应用实例移动到另一个雾节点中的应用实例的过程。应注意的是，后者可能是由于主动使用具有服务要求的所有情境和详细信息的服务或应用的用户的移动性造成的。例如，用户可能正在从智能运输应用或导航***接收服务。用户可以已经在LFN 1中发起了这个服务，该服务具有关于期望路径、用户希望停车的期望服务点以及目的地处的期望服务(诸如找到低于一定成本的停车位等)的详细信息。当车辆行驶时，这个信息可以被传递到在邻近雾节点上运行的邻近应用。这是重要的，因为用户可以随时请求对服务(诸如在加油站停车等)的更新。公开了用于以下的过程：实例化其它雾节点中的应用、跨邻近的应用实例以及雾节点来重定位用户应用情境、并且最后雾节点可以由于来自应用层的多个请求而请求服务的实例化。

可以在应用层中做出在雾节点中实例化应用的决定。可以假设当前在源雾节点上运行的应用的实例知道它托管在其上的雾节点的雾区域，从而知道邻居雾节点的雾区域。如果应用被授权接收这个信息，则雾节点可以使这个信息可用。该应用实例还可以经由当前的托管雾节点知道邻近的雾节点是否已经具有正在运行的同一应用的实例。基于用户的移动性，应用可以请求雾服务层在邻近雾节点中实例化同一应用，以便在用户移入该区域时为他提供服务。还存在触发雾节点中的应用实例化的其它理由，并且这样做的决定可以在云上完成，而不是由应用层触发。

公开了当用户从一个雾区域移动到另一个雾区域时应用实例的动态实例化的过程。由于来自在源LFN上运行的应用的请求，可以经由云来完成实例化，并且该应用可以知道用户的移动性和位置。图13示出了示例过程。

在步骤1中，应用可选地使用雾节点的服务来跟踪车辆。该应用可以包含描述每个用户或车辆所需的服务的用户情境。该应用(在这种情况下为智能运输应用)可以意识到车辆正在离开当前托管它(即，该应用)的雾节点的雾区域。

在步骤2中，应用可以请求LFN指示邻近的或相邻的LFN是否已经托管了由应用ID标识的应用的列表的实例。应注意的是，对于这个用例，可能只有一个与智能运输应用相同的应用ID，但是应用可能请求了解其它应用是否也在运行，因为它们通常会共享相同的用户信息(诸如电子邮件地址、用户名等)。应用可以使用应用实例核实请求API，该API可以包括车辆的当前位置、车辆的目的地、以及期望了解在当前位置和目的地之间的任何雾节点中是否已经实例化了同一应用的至少一个应用ID。

在步骤3中，LF管理器分析位置信息和目的地。LF管理器基于车辆及其目的地的位置信息来确定相邻LFN的列表，或者至少确定下一个LFN。LF管理器可以已经知道这些邻居LFN上已在运行的应用的列表。

在步骤4中，基于步骤3中的确定，LF管理器使用API：应用实例核实响应对应用进行响应，该API可以包含以下的列表：LFN、雾区域、以及指示应用是否在对应的LFN ID中被实例化的每个应用ID的结果。

在步骤5中，基于接收到的信息，应用确定在特定LFN(例如，下一个相邻的LFN)中实例化应用，以便为用户或车辆提供服务。该应用使用API：应用实例化请求，该API可以包括以下的列表：目标LFN、以及与期望实例化所指示的应用ID对应的相关联区域。

在步骤6中，LFN 1将雾实例化应用请求发送到云，指示如从应用层接收到的应用ID、LFN ID和目标雾区域的列表。

在步骤7中，云节点核实其策略以授权针对每个应用的请求。

在步骤7a中，如果请求未被接受(例如，对于所有请求的应用或对于所有目标LFN)，则云可以发送雾实例化应用响应，该雾实例化应用响应可以包括例如在这种情况下将被设置为“拒绝”的请求结果。该消息还可以指示拒绝的原因以及是否重试和何时进行重试。

在步骤8中，如果请求被授予和授权，则云节点检索与所允许的每个应用ID相关联的应用软件。这可以在云节点处本地可用，或者云节点可以从主应用服务器获取它。

在步骤9中，云节点联系已针对其授权请求的每个目标LFN。应注意的是，虽然为简单起见，图13仅示出了一个目标LFN 2，但是可以理解的是，可以涉及任何数量的目标实体。云发送雾实例化应用请求消息，该雾实例化应用请求消息包括应用ID(每个ID与应当被实例化的应用软件相关联)以及用于运行或实例化此应用的雾资源(诸如存储器、计算、允许的服务(诸如Tx/Rx功能)、相机数据等)的列表。应注意的是，可以假设云已经具有由应用提供商提供的应用软件。如果不可用，则云也可以联系提供商以获取软件。

在步骤10中，LFN 2确定是否可以使用所需资源来实例化(一个或多个)应用。如果是，则LFN 2使用从步骤9接收的应用软件来实例化应用。实际可用资源也可能与期望资源不匹配。LFN 2可以具有例如可以帮助它基于目标LFN处的可用资源(与要实例化的应用所需的资源相比)来确定是否可以实例化所指示的应用的策略。此外，作为示例，即使可用资源与所需资源不精确匹配(诸如在存储器方面)，如果可用资源与所需资源之间的差异不超出一定阈值(例如，90％)，则LFN也仍可以实例化应用。可以在LFN中配置这个阈值。然后，LFN 2利用可用资源或已经为每个应用确定的资源来实例化(一个或多个)应用。

在步骤11中，LFN 2向云发送雾实例化应用响应消息，该雾实例化应用响应消息可以包含应用ID、对应的实例化结果、以及可选地如果与先前请求的资源不同则用于每个应用的实际资源的列表。

在步骤12中，云节点更新这个LFN 2上的实例化的应用的列表。

在步骤13中，云将雾实例化应用响应发送回源LFN(此处为LFN 1)。该消息可以包括应用ID、目标LFN和雾区域以及实例化请求结果的列表。如果结果为不成功，则消息还可以包括反映操作为何不成功的原因的原因代码，并且还可以包括对稍后重试的指示。

在步骤14中，LFN更新其本地信息，以反映在对应目标LFN上运行的应用ID和状态，以用于将来来自应用层的请求。

在步骤15中，LFN 1中的LFN管理器使用API：应用实例化响应来向应用层指示请求结果、已在其上实例化应用的雾区域和目标LFN ID，以及如果未成功的情况下这种失败或拒绝的原因。这个API还指示对于未实例化的那些应用是否可以再次重试应用。

公开了用于雾节点中的云触发的应用实例化的过程。确定这样做可以基于云处的逻辑和本地策略。再次地，可以在考虑到用例的情况下呈现这个过程，但是，一旦根据任何用例在云中做出了实例化应用的决定，该过程自身就适用于该用例。

在此，我们可以假设云(或更高级别的雾节点)已使用至少一个LFN(在我们的示例中为LFN 1)执行了雾服务请求过程。该服务可以与从LFN 1到云的数据递送以及可能使用WAVE协议发送的安全应用消息的处理相关，其中数据与来自各种源(诸如相机、速度传感器)的交通信息相关。LFN 1可以发送与请求中每个FSD相关的数据。云从LFN 1(也可能还有其它LFN)接收例如指示事故的数据。服务还可以递送示出事故程度的相机图像或视频，从而变得有必要将所有交通从受影响区域转移出去。照此，云节点决定这样做，但首先触发受影响的雾区域邻近的LFN中的应用实例化。

图14示出了由云触发的应用的实例化的示例过程。在这个流程中，可以假设来自LFN 1的被分析的数据触发了云将其它LFN(即，LFN 5)中的应用实例化。应注意的是，可以在若干雾节点中完成应用实例化，但这个示例出于简化目的而仅示出一个目标LFN。在实例化之后，云节点还使用雾服务操作推荐过程(如前所述)来推荐在LFN 1的控制下从受影响的街道或区域的交通转移的广播。

在步骤1中，可以已经假设云已使用先前呈现的雾服务请求过程从LFN 1请求了服务。作为这个服务的一部分，云从LFN 1接收关于事故的数据。对这种数据或服务的分析触发了云，以决定从LFN 1的雾区域的受影响街道转移交通。

在步骤2中，云基于本地逻辑和策略来确定车辆可能采用的潜在新路线。云决定在负责预计将发生交通转移的雾区域的雾节点上实例化LFN 1中正在使用的一个或多个应用。这对于在雾服务层中实现无缝服务可用性是重要的，以便LFN 1的雾区域中正在使用的任何服务在可能发生转移的新区域中均可用。

步骤3可以与图13中的步骤8相同。

步骤4可以与图13中的步骤9相同。

步骤5可以与图13中的步骤10相同。

步骤6可以与图13中的步骤11相同。

步骤7可以与图13中的步骤12相同。

在步骤8中，由于云决定在目标雾节点中实例化应用，因此云可以向LFN 1发送雾应用实例化通知消息。该消息可以包括应用ID和对应的LFN ID以及表示在其上已实例化应用的LFN的雾区域的列表。

在步骤9中，LFN 1用雾应用实例化通知确认消息进行响应以确认接收到通知。

步骤10可以与图13中的步骤14相同。

在步骤11中，LFN 1(可选地，LFN 1中的LF管理器)向关于(由相似的应用ID标识的)同一应用的实例化的每个应用通知关于同一应用在目标LFN和对应的雾区域中的实例化。这可以使用API：应用实例化通知来完成。

在步骤12中，应用经由API：应用实例化通知确认来进行响应，以确认接收到通知。应用现在可以保存反映正在运行由应用ID标识的同一应用的LFN的这个信息。

在步骤13中，由于假设云正在管理所有LFN，因此云决定基于本地策略从受影响的区域转移交通。云使用先前描述的操作推荐过程来包括这个操作所必需的FSD。云将具有所推荐的参数或动作的雾服务操作推荐消息发送到LFN 1。例如，所推荐的参数可以指示在LFN 1的雾区域的全部或具体区域中广播消息，从而通知车辆完全避开某些街道。

在步骤14中，LFN 1用雾服务操作推荐确认消息进行响应，以确认接收到该消息。

在步骤15中，LFN 1考虑到从云接收到的推荐的参数和动作。作为示例，动作可以是广播指示需要避开某些街道或区域的消息。LFN 1使用其发送功能来执行这个操作。

步骤16可以与图12中的步骤9相同。

步骤17可以与图12中的步骤10相同。

用于实例化其它雾节点中的应用的示例过程可以由LFN或由云发起。在应用实例化之后，可以期望将应用用户情境从一个雾节点移动到另一个雾节点，以便实例化的应用为所讨论的正在跨雾区域移动的用户提供服务。

一方面，源LFN可以直接联系目标LFN以实例化应用。可以假设源LFN在本地具有应用软件并且可以将应用软件提供给目标LFN以进行实例化。可选地，情况可以是目标LFN在本地具有应用软件，但是尚未实例化。源LFN可以提供应用ID，然后目标LFN使用该ID来选择对应的应用软件并相应地实例化该应用。

图15示出了使用直接F2F通信在目标LFN处实例化应用的示例调用流。应注意的是，LFN(源或目标)或云可以具有应用软件模板或可以交换应用模板(template)，或者LFN可能已经在本地具有某些应用的模板。照此，术语“应用软件”也可以指模板。

步骤1可以与图13中的步骤1相同。

步骤2可以与图13中的步骤2相同。

步骤3可以与图13中的步骤3相同。

步骤4可以与图13中的步骤4相同。

步骤5可以与图13中的步骤5相同。

在步骤6中，可以例如基于应用ID或基于发出请求的应用或其它本地策略或者由于缺乏与FN或云的连接而将LFN配置为直接联系目标LFN以进行应用实例化。在这种情况下，源LFN向目标LFN发送雾实例化应用请求消息。该消息可能包括源LFN ID和雾区域，以及以下一项或多项的列表：应用ID、可选的每个应用ID的应用软件、以及每个应用ID的描述该应用所需的雾资源的应用要求。

在步骤7中，目标LFN可以联系FN或云以认证请求，因此可以发送雾实例化授权请求消息，雾实例化授权请求消息包括源LFN ID和雾区域，以及以下一项或多项的列表：应用ID、可选的每个应用ID的应用软件、以及每个应用ID的描述该应用所需的雾资源的应用要求。如果源LFN未发送应用软件并且如果目标LFN不具有针对特定应用ID的应用软件，则源LFN还可以包括每个应用ID的应用软件指示。这向云通知目标LFN处需要应用软件。

在步骤9中，云基于本地策略对请求进行授权，并且用雾实例化授权请求消息进行响应，该雾实例化授权请求消息包括以下一项或多项的列表：应用ID、每个应用的授权结果、(如果需要)可选的应用软件(如上所述)、以及可选的每个应用的描述在雾节点上实例化对应应用所需的雾资源集合的应用要求。

在步骤9中，如果目标LFN基于本地策略或信息或者基于上述步骤对请求进行授权，则在假设应用软件可用并且不由源LFN或云提供的情况下，目标LFN可以使用应用ID来检索该应用软件。应注意的是，LFN可以已经具有其从更高级别的FN或云中接收到的应用软件，并且可以基于应用ID对应用软件进行检索。

在步骤10中，目标LFN确定资源是否可用于实例化每个应用。

在步骤11中，目标LFN用雾实例化应用响应消息来响应源LFN。该消息可以包括以下一项或多项的列表：应用ID、每个应用的应用实例化请求的结果、以及用于实例化每个应用的实际雾资源。

步骤12可以与图13中的步骤14相同。

步骤13可以与图13中的步骤15相同。

公开了解决与将应用用户情境从在源雾节点上运行的源应用实例到目标雾节点上运行的目标应用实例的重定位相关的用例的过程。这个情境指示需要随着用户从一个雾区域移动到另一个雾区域而重定位的特定用户的服务的当前状态。在一个实施例中，有两种方法可以在应用层重定位用户情境。在这两种情况下，用户情境的重定位都被认为是由雾服务层提供的服务。重定位应用用户情境的第一个选项是经由云到达目标雾节点。第二个选项是使用雾节点之间的直接过程进行重定位。

应注意的是，虽然下面的解决方案可以涉及用户情境的传送，但是该解决方案也可以传送应用层情境并包括应用层情境。照此，支持服务可以与应用用户情境或者应用情境或两者相关。对使用应用用户情境的解决方案的描述不应当被解释为对解决方案的限制。

公开了用于经由云节点将应用用户情境从源雾节点重定位到目标雾节点的过程。这些过程可以在用户实际移动进入新的雾区域之前执行，并且可以由应用层决定这样做。可以假设应用层跟踪用户并负责在正确的时间做出这个决定。该解决方案在依赖雾服务层来移动应用用户情境的意义上是简单的，并且假设目标应用实例负责分析情境，然后为用户获取必要的服务，就像用户最初在目标雾节点处被服务一样。也就是说，目标应用负责与它在其上运行的目标雾节点进行交互，以便相应地请求必要的雾服务。照此，可以不为用户执行服务传送作为移动性的一部分。图16示出了雾服务的总体过程，该过程根据应用层的请求重定位应用用户情境。

在步骤1中，应用层决定将用户的情境重定位到在目标雾节点上运行的目标应用。该应用可以知道目标雾节点上正在运行同一应用的实例。该应用使用API：应用用户情境重定位请求，该API包含以下中的一个或多个：目标雾ID、目标雾区域、应用ID和仅由应用层理解并且对雾服务层透明的应用容器。

在步骤2中，LFN 1核实是否必须经由云或直接用目标雾来完成重定位。在这种情况下，LFN 1基于其本地策略来确定经由云进行重定位。

在步骤3中，LFN 1向云发送雾应用用户情境重定位请求消息，该雾应用用户情境重定位请求消息指示源LFN ID和雾区域、目标LFN ID和雾区域、应用ID以及包含应用用户情境的应用容器。

在步骤4中，云核实目标应用ID是否在目标雾节点中被实例化，并且还授权请求。

在步骤5中，如果被授权，则云向目标LFN发送雾应用用户情境重定位请求消息，该雾应用用户情境重定位请求消息指示源LFN ID和雾区域、应用ID以及包含应用用户情境的应用容器中的一个或多个。

在步骤6中，目标LFN核实由应用ID标识的应用是否确实在这个LFN中被实例化。

在步骤7中，LFN(例如LF管理器)使用API：应用用户情境重定位通知，该API包括源LFN ID和雾区域、应用ID以及包含用户情境的应用容器中的一个或多个。这个API用于向应用通知存在来自另一个LFN中另一个应用的用户情境传送请求。

在步骤8中，应用以API：应用用户情境重定位确认进行响应，该应用用户情境重定位确认指示应用ID和情境重定位的结果。这指示情境传送的结果，如果成功，则意味着这个应用实例现在可以为其情境已传送的特定用户集合提供服务。

在步骤9中，目标LFN用雾应用用户情境重定位响应消息来响应云，该雾应用用户情境重定位响应消息包括以下中的一个或多个：目标LFN ID和雾区域、应用ID以及应用用户情境的重定位结果。

在步骤10中，云用雾应用用户情境重定位响应消息来响应源LFN，该雾应用用户情境重定位响应消息包括以下中的一个或多个：目标LFN ID和雾区域、应用ID、以及重定位结果。

在步骤11中，LFN 1(例如LFN 1中的LF管理器)使用API：应用用户情境重定位响应来响应应用，该API包含以下中的一个或多个：目标雾ID、目标雾区域、应用ID和应用用户情境重定位的结果。这个过程使得(在目标LFN上的)目标应用负责分析情境并确定应当从目标雾节点请求的服务，以便以无缝的方式使用户的服务需求可用。

图17中示出了使用LFN之间的直接过程从应用实例跨雾节点进行应用用户情境重定位的示例过程。这个过程还支持从源雾节点到用户正在移动进入其雾区域中的目标雾节点的数据或服务转发。

用户可以具有其他用户当前不在请求的具体服务。例如，用户可以有兴趣找出城市的特定街道中的停车位的可用性。照此，在该街道上的停车位处的相机图像或传感器可以将数据发送回雾节点，以指示停车位是否可用。而且，负责感兴趣的街道上的这些“事物”的雾节点还不是用户所在的雾节点。例如，考虑用户当前位于LFN 1下的雾区域1中的情况。用户或车辆正在驶向由LFN 3控制的雾区域3中的目的地或街道。虽然用户尚未进入雾区域3，但是LFN 3可以正在取出数据并将其发送到LFN 1，以便甚至在到达目的地之前就向用户通知停车位的可用性。照此，这个停车信息服务不是一次性的数据共享事件，而是可以随着更多的停车位变得空闲或用尽而实时进行。但是，用户实际上可以开始进入雾区域1和雾区域3之间的雾区域2。此时，应当将用户的应用层情境移动到在LFN 2中运行的应用实例。但是，存在针对这个用户的数据或服务，并且服务需要在LFN 2中继续进行。虽然假定LFN 2中的应用层与LFN进行2交互以获取这个用户所必需的服务，但是这样做所需的时间可能长。例如，由于用户将要离开该区域，因此LFN 2现在需要联系LFN 3以直接获取关于停车的数据，而不是将这个数据发送到LFN 1。接下来呈现的过程使LFN 1在移动性事件期间能够将数据或服务转发到LFN 2。这使得LFN 2中的应用实例可以随后从LFN 2请求服务，并且一旦在LFN 2处服务对于这个用户可用，就停止从LFN 1转发数据或服务。这实现了“先通后断(make before break)”服务切换(handover)并使服务移动性无缝。图17示出了直接在雾节点之间重定位用户情境所需的过程和步骤。

在下面的过程中，假设用户使用也托管在LFN 1上的智能运输应用处于LFN 1下。而且，该应用正在消耗来自LFN 1的服务，该服务已经触发了LFN 1进而使用先前描述的过程从LFN 2和LFN 3获取服务。照此，LFN 1当前正在接收针对特定用户的服务或数据。应注意的是，LFN 1不必知道最终将哪些数据提供给用户。这个信息可在应用层获得，应用层被视为雾服务层的主要消耗者。因此，转发数据的决定由应用层做出并且由雾服务层支持。类似地，重定位用户的应用层情境的决定由应用层基于用户的位置来做出。

在步骤1a中，LFN 1正在从LFN 2接收数据。

在步骤1b中，LFN 1正在从LFN 3接收数据。

在步骤1c中，LFN 1将数据转发到诸如智能运输应用之类的应用。(来自LFN 2和LFN 3两者的)数据被转发到应用。

在步骤2中，应用由于例如从雾区域1到雾区域2的移动性而决定重定位用户的应用情境。应用层可以知道这个用户的服务，这些服务可能是唯一的并且可能需要跨雾节点的“服务移动性”。应注意的是，这也可以是由于用户支付了特定附加款项(premium)(可以针对该附加款项支持该能力)这一事实造成的。该应用使用API：应用用户情境重定位请求，该API的内容已在前面进行了描述。此外，由于该应用要求这个用户具有“服务移动性”，因此该应用可以包括活动请求ID及其对应的FSD的列表。这个列表指示对“服务移动性”的需求。虽然未示出，但是API还可以包括显式的“服务移动性”指示，该指示请求雾节点将与所指示的FSD相关的数据转发到目标雾节点。

在步骤3中，LFN 1核实是否必须经由云或直接与目标雾进行重定位。在这种情况下，LFN 1基于其本地策略来确定直接与目标雾节点进行重定位。

在步骤4中，源LFN将雾应用用户情境重定位请求发送到目标雾节点。该消息可以包含源LFN ID和雾区域、应用ID和应用容器。该消息还可以包含与FSD相关联的请求ID和数据转发指示的列表。数据转发指示向目标通知源雾节点可以支持数据转发作为移动性的一部分。

在步骤5中，目标LFN核实由应用ID标识的应用是否确实在这个LFN中被实例化。

在步骤6中，如果策略不允许这种重定位，则雾节点以雾应用用户情境重定位响应消息进行响应，该消息包括结果(在这种情况下为拒绝)和描述拒绝的理由的原因代码。

在步骤7a中，如果重定位被授权，则LFN(例如LF管理器)使用API：应用用户情境重定位通知。除了之前已描述的内容外，该API还可以包括与FSD相关联的请求ID和数据转发指示的列表。数据转发指示向应用通知服务层支持服务移动性作为情境重定位的一部分。

在步骤7b中，应用利用API：应用用户情境重定位确认进行响应，该API可以包括应用ID、重定位结果、以及与FSD相关联的请求ID和数据转发请求的列表。(每个请求ID和FSD的)数据转发请求向雾节点通知是否对请求ID和FSD中的每一个都要求服务移动性。

在步骤8中，LFN 2用对源雾节点的雾应用用户情境重定位响应来响应LFN 1。除了先前描述的内容之外，该API还可以包括请求ID、FSD和数据转发请求信息元素的列表。数据转发请求是针对所指示的请求ID和FSD请求数据或服务转发的指示。

在步骤9中，LFN 1(例如LF管理器)确定应当将在LFN 1处接收的来自LFN 3的数据转发到LFN 2，作为移动性的一部分。应注意的是，这个确定是基于每个请求ID和FSD的数据转发请求指示来完成的。应注意的是，这个示例仅示出了应当转发来自LFN 3的数据。但是，可能存在也可以被转发的来自LFN 2的本地服务或来自其它LFN的其它数据。该示例仅用于说明和简化。

在步骤10中，如先前在步骤1b中所指示的，LFN 1仍继续从LFN 3接收服务。到目前为止，LFN 3可能尚未意识到用户的移动性。LFN 1将数据转发到LFN 2，在那里应用用户情境被重定位。数据也可以被转发到应用。转发的数据被链接到由请求ID标识的特定服务。

在步骤11中，LFN 1(例如LF管理器)用API：应用用户情境重定位响应来响应应用，并指示重定位的结果。该API还可以包括请求ID、FSD和数据转发结果的列表。数据转发结果指示数据转发对于每个请求ID和FSD是否成功或被接受。

在此时，LFN 2中的应用层可以正在从LFN 1例如经由转发获取对于所讨论的用户必要的服务或数据。虽然这有助于无缝移动性和服务供应，但是应用层最终可以请求LFN 2获取类似的服务，以便服务提供商的源成为LFN 2而不是LFN 1。在服务在LFN 2处可用之后，可以终止数据转发过程。接下来的步骤相应地对此进行描述。

在步骤12中，LFN 2直接从LFN 3请求服务，以便最终停止数据转发。

在步骤13中，LFN 3根据雾服务请求过程中所提供的FSD开始向LFN 2递送数据。

在步骤14中，一旦LFN 2开始直接从LFN 3接收数据，LFN 2就将雾服务停用(deactivate)消息发送到LFN 1。该消息可以包括请求类型和请求ID列表。请求类型指示需要停止针对请求ID列表的数据转发。

在步骤15中，基于接收到的请求ID列表，LFN 1确定停止转发与每个请求ID对应的数据。在这种情况下，LFN 1停止将从LFN 3接收到的数据转发到LFN 2。

在步骤16中，LFN 1发送雾服务停用确认消息以向目标LFN通知与请求ID列表对应的数据可能不再被转发。

在步骤17中，基于当前活动的请求和FSD，在LFN 1中可能不再需要来自LFN 3的数据。LFN 1可以向LFN 3发送雾服务停用消息，并且包括请求服务停用的请求ID的列表。

在步骤18中，LFN 3向LFN 1发送雾服务停用确认消息，并确认与请求ID列表对应的服务的终止。

在步骤18之后，应用实例可以正在从LFN 2获取其所需的所有数据或服务，LFN 2进而从其它源直接获取数据并停止经由LFN 1进行任何间接服务供应。

公开了用于涉及与雾的应用层交互的用例的示例过程。应注意的是，虽然该过程呈现了基于预测的移动性模式的支持服务，但是该过程也适用于可能影响雾节点的性能的任何其它预测。例如，LFN、FN或云可以预测具体LFN上负荷状况的增加，因此可以决定实例化其它LFN中的应用等。照此，该过程不仅限于应用层的预测，或由于移动性而做出的预测。可以由LFN、FN或云进行预测，而执行以下呈现的解决方案的过程也可以由LFN、FN或云触发和发起。

在这个用例中，可以假设用户的移动性是已知的。给定这个假设，应用层可以请求雾服务层提前准备特定服务。所准备的服务可以被托管在雾节点中，并因此被托管在预期用户将穿越的雾区域中。例如，乘客可以在车辆中使用视频流式传输应用。车辆的目的地提前已知，并且车辆开始在LFN 1所服务的雾区域1中访问该服务。该应用实例(例如LFN 1中的流式传输应用)请求LFN 1与目标雾节点列表以及在这些雾节点中运行的同一应用的实例传送某些信息，以便由雾服务层向应用层通知预期用户何时到达该雾区域。利用这个信息，该雾节点上的应用实例可以基于估计的到达时间来取出用户可能需要的数据(例如，视频流)。图18示出了作为示例的汽车在特定方向上驾驶以及如何在每个区域部署雾节点的用例。

假设车辆当前位于LFN 1下的雾区域1中并且正在使用流式传输应用。例如，如果用户正在观看电影并且用户当前处于一百分钟长的电影的五分之一处。使用雾服务层，可以估计出三十分钟内用户可以在雾区域2下，而六十分钟内车辆可以在雾区域3下。照此，这个信息可以与分别在雾区域2和雾区域3下的LFN 2和LFN 3中运行的应用实例共享。基于这个估计，LFN 2上的应用层可以从大约第三十五分钟开始取出视频流，而LFN 3上的应用层可以从第六十五分钟开始取出内容等。这个内容可以在本地可用或从主要内容提供商获得。本节介绍了使雾提供估计用户进入某些雾区域的服务的过程，并在驻留在不同雾层中的应用之间共享应用层信息，以便他们可以提前准备内容。图19示出了跨雾服务层启用此类服务的示例过程。

在步骤1中，用户可以已经在使用流式传输应用，该应用还知道用户的位置、目的地和驾驶路线，并因此知道用户可以穿越的雾区域。该应用可以使用雾服务层或与同一雾节点上的其它应用进行交互以获得这个信息。附加地或可替代地，用户可以已经经由应用的图形用户界面提供了这个信息。

在步骤2中，应用与LFN进行交互，以获取预计车辆将通过的区域(在这个示例中为雾区域2和雾区域3)中的每个区域中车辆的平均速度。应注意的是，这个信息可以作为本文所述的雾层服务被获得。

在步骤3中，应用使用API：应用准备服务请求来请求LFN 1为所讨论的服务准备目标LFN和LFN上的应用实例。该API还可以包括请求ID、FSD、车辆的当前位置、其目的地、这个位置(即，雾区域1)的平均速度、应用ID、应用容器、以及汽车可能通过的雾区域以及每个区域对应的平均速度的列表。

在步骤4中，雾节点将雾准备服务请求消息发送到云。该消息可以包括源雾ID、雾区域、请求ID、FSD、车辆的当前位置、其目的地、这个位置(即，雾区域1)的平均速度、应用ID、应用容器、以及汽车可能通过的雾区域以及每个区域对应的平均速度的列表。

在步骤5中，云授权请求并确定应当在其上准备服务的目标雾节点。

在步骤6中，云还知道由应用ID标识的应用是否已在目标LFN中被实例化。如果不是，则云发起应用的实例化，如本文所述。

在步骤7中，云向目标LFN(此处为LFN 2和LFN 3)发送雾准备服务请求消息。该消息可以包括源雾ID、雾区域、请求ID、FSD、车辆的当前位置、其目的地、这个位置(即，雾区域1)的平均速度、应用ID、应用容器、以及汽车可能通过的雾区域以及每个区域对应的平均速度的列表。

在步骤8中，LFN 2使用提供的信息来估计车辆进入其雾区域所需的时间。LFN 2可以使用与LFN 2相关的平均速度，或者它可以首先计算最近的平均速度并使用该信息。可以假设LFN 2具有关于其邻近的雾区域的范围的信息。

在步骤9中，LFN 2(例如LF管理器)使用API：应用准备服务通知向应用实例通知需要为特定用户准备服务。该API还可以为应用提供源雾ID、雾区域、请求ID、FSD、车辆的当前位置、其目的地、进入这个雾区域的估计到达时间以及应用容器。容器包含对雾节点透明的应用层信息，并且这可以包括关于应当准备服务的哪个部分或类型的信息，诸如视频的长度、流的当前时间等。

在步骤10中，应用以API：应用准备服务确认进行响应并且包括结果和请求ID。应用可以在响应之前首先执行步骤12。

在步骤11中，LFN 2用雾准备服务响应消息来响应云。该消息可以包括请求ID和结果。虽然未示出，但是该消息还可以包括目标雾ID、雾区域以及可选地应用ID。

在步骤12中，应用使用接收到的信息(例如，估计的时间、当前位置等)以及FSD和应用容器来取出(例如，缓冲)并为所讨论的用户准备数据或服务。假设当用户进入这个雾区域时用户可以联系应用，然后该应用恢复为用户提供服务。

步骤13：类似于步骤8至步骤11，但交互是在LFN 3和云之间。而且，这个LFN 3中的应用实例采取与步骤12中所述类似的操作。

在步骤14中，云聚合来自为准备服务而联系的每个目标LFN的所有响应。

在步骤15中，云节点将雾准备服务响应消息发送到源LFN。该消息可以包括请求ID和以下的列表：目标雾ID、雾区域以及每个雾节点的请求的结果。

在步骤15中，LFN(例如LF管理器)使用API：应用准备服务响应向应用通知请求的结果。该API还可以包括请求ID和以下的列表：目标雾ID、雾区域以及每个雾节点的请求的结果。

本文描述的过程中的一些可以被实现为oneM2M过程，具体而言，用于雾能力发现和雾能力状态报告的管理过程。

在讨论oneM2M方法中的这些过程之前，可以将每个雾节点(或LFN，或FE)或云实现为具有以下新属性的CSEBase：“lfnID”、“fogArea(雾区域)”和“fogCapabilities(雾能力)”。如本文已描述的，“fogCapabilities”属性包含雾节点的所有能力。例如，能力可以包括连接到雾节点的所有IoT设备或“事物”(例如相机、传感器等)、它们的位置和其它特定能力。其它雾能力还可以包括由雾节点提供的本机服务，诸如跟踪、用于发送和接收功能的支持的接入技术，对特定协议处理的支持等。可替代地，某些能力可以被表示为oneM2M资源，诸如AE、容器或mgmtObj资源。表1示出了CSEBase资源的属性，其中包括“lfnID”、“fogArea”和“fogCapabilities”属性，参考oneM2M技术规范oneM2M-TS-001-V3.5。

表1：CSEBase中的示例属性

图20示出了雾节点、LFN或云中的示例资源树。为简单起见，这个资源树仅示出了上述新属性。

表2示出了可以被包括在“fogCapabilities”属性中的可能的能力参数的示例。应注意的是，“fogCapabilities”属性描述雾节点支持的雾能力的列表。能力包括本文描述的任何能力或服务。应注意的是，在适用的情况下，这还可以包含与能力的位置相关联的位置信息。例如，相机能力可以包括相机以及对应的部署位置以及相机支持的任何其它服务或能力的列表。雾节点的另一种能力可以是分析，因为它驻留在雾节点中而与位置信息不相关联，等等。照此，一些雾能力或服务可以与位置信息相关联，而其它雾能力或服务则与位置信息无关。

表2：“fogCapabilities”属性中的示例参数

应注意的是，表2仅示出了本文描述的能力的小子集，但是，可以包括所描述的所有其它能力，并且还可以定义和包括不同的能力。

可以使用下面的图21中所示的oneM2M检索操作来实现本文所述的雾能力发现过程。可替代地，如果将雾能力表示为oneM2M资源，则也可以使用oneM2M资源发现来发现雾能力。应注意的是，假设在这个过程之前，LFN以及每个CSEBase已经发现了彼此。

可以用oneM2M更新操作来实现本文所述的雾能力状态报告过程。再次地，假设每个LFN以及CSEBase在此之前已经发现了彼此。而且，假设每个LFN以及CSEBase都具有至少一个remoteCSE资源，该资源与邻居LFN的资源和属性对应。例如，LFN 1和LFN 2之前已经彼此注册。LFN 1除了图20中所示的新属性外还可以具有针对LFN 2的remoteCSE资源。这个remoteCSE也可以具有与图20所示的相同属性。同样，LFN 2可以具有针对LFN 1的remoteCSE资源。因此，当一个LFN中的任何能力或服务改变时，LFN可以使用oneM2M的更新操作来更新邻居LFN有关源LFN中的能力和服务的状态。图22示出了利用更新操作对雾能力状态报告的示例实施方式(假设两个CSEBase实体都已经彼此注册)。

oneM2M消息可以用于请求对已经在LFN上运行的应用的实例化或停用(即，取消实例化)。为此，我们首先描述oneM2M技术规范oneM2M-TS-001-V3.5中定义的<software(软件)>资源的新属性。

图23中所示的资源树仅示出了提出的新属性，即，authorizURI、appInstStatus和instDestination。可以假设AE已向表示LFN的CSEBase注册并拥有具有上面所示的新属性的软件资源。照此，AE可以使用oneM2M更新消息以请求CSE来实例化应用或停用已经在LFN上运行的应用。为了实例化应用，AE更新软件资源的authorizURI属性，使得该值指向目标LFN将与之通信的云节点，以便授权实例化请求。而且，AE可以将appInstStatus属性设置为指示例如“实例化”的值。为了停用应用，AE可以发送oneM2M更新消息并将appInstStatus属性更新为指示例如“停用”的值，同时设置authorizURI属性以反映目标LFN将联系以授权停用请求的云节点。表3描述了图23中所示的软件资源的新属性。

表3：软件资源树中的新资源示例

图24示出了示例流程，AE可以通过该流程将oneM2M更新消息发送到表示LFN 1的CSEBase1并相应地更新[software(软件)]资源的属性(如本文所述)，用于将应用实例化到另一个雾节点LFN 2的目的。在图24中，假设“node1”是用于管理目的的oneM2M<node>资源并且可以将其直接放置在CSEBase1之下；可替代地，可以将资源“node1”放置为CSEBase1/remoteCSEforLFN 2的子资源，其中remoteCSEforLFN 2是oneM2M<remoteCSE>资源并且指代LFN 2上的CSE。

为了实例化应用，AE发送更新消息并如上面所解释的那样设置属性的值。AE设置authorizeURI属性的值以指向云节点。因此，LFN 1可以使用该属性的值来联系云节点以进行授权。LFN 1还可以将目标雾节点的地址(即，instDestination属性的值)通知给云节点。然后，云节点可以能够联系目标雾节点以将应用实例化到其上。照此，图24的步骤2然后可以与图13的步骤9、10和11对应。此外，图24的步骤3可以与图13的步骤13对应。

应注意的是，FE也可以像AE一样起作用，因此，上面提出的过程也将适用于与LFN进行通信的FE。

图25和26示出了潜在的GUI外观的示例，用于显示LFN、FN和云的层级结构，以及连接到LFN的FE、资源和服务。

图25示出了已部署的LFN、FN和云的示例层级结构、它们之间的连接以及哪个FN控制某些LFN。此外，在每个LFN旁边，都有显示该LFN运行时的性能级别的计量器。这个性能级别覆盖了LFN的所有资源。例如，它可以是LFN中每个资源性能的平均值。每个FN和云旁边都示出了相同的性能计量器。

除了支持的服务和连接到LFN的FE列表之外，用户可能还希望了解关于LFN的支持的资源及其使用级别的更多信息。于是，用户可以触摸屏幕，具体而言可以触摸感兴趣的特定LFN。例如，用户可能希望核实LFN 1A的详细信息。在触摸LFN 1A的区域之后，可以向用户提供包含与这个LFN相关联的资源、服务和FE信息的显示。图26示出了这个处理可以产生的示例显示。

应注意的是，图26是可能的显示选项的示例，但是，实际显示可以包含这个信息或上面未示出的其它信息的子集。在这个示例中，GUI示出了三类信息–LFN资源、LFN服务和雾实体。资源可以示出每个支持的资源在LFN处的使用百分比，其中两个资源作为示例示出，即，存储器和CPU。LFN资源还可以指示LFN是否支持与特定接入技术相关的资源以及该资源是否被启用的指示。第二类信息是LFN支持的LFN服务，这些服务可能是分析、跟踪、图像处理和致动器控制等。可以为用户提供“查看”按钮选项，该选项可以提供关于每个服务的进一步详细信息。第三类信息可以与LFN连接到的FE相关。可以有连接到LFN的速度传感器、温度传感器、相机等的集合。用户可以使用“查看”按钮来查看关于这些FE的更多详细信息，诸如它们的位置、状态、ID、制造商等。

执行图6、8-19、21、22和24-26中所示步骤的任何实体(诸如服务层、应用实体、云节点、雾实体、雾节点、本地雾节点等)可以是逻辑实体，这些逻辑实体可以以存储在被配置用于无线和/或网络通信的装置或计算机***(诸如图27C或图27D所示的那些装置或计算机***)的存储器中并在其处理器上执行的软件(即，计算机可执行指令)的形式来实现。即，图6、8-19、21、22和24-26中所示的(一个或多个)方法可以以存储在装置(诸如图27C或图27D所示的装置或计算机***)的存储器中的软件(即，计算机可执行指令)的形式实现，其中计算机可执行指令在由装置的处理器执行时，执行图6、8-19、21、22和24-26中所示的步骤。还应当理解的是，图6、8-19、21、22和24-26中所示的任何发送和接收步骤可以在装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下由装置/实体的通信电路***来执行。

图27A是示例性机器到机器(M2M)、物联网(IoT)或万维物联网(WoT)通信***10的图，其中可以实现一个或多个所公开的实施例。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoT/WoT的部件或装置以及IoT/WoT服务层等。图1-26中所示的任何实体都可以包括通信***的网络装置，诸如图27A-27D中所示的网络装置。

服务层可以是网络服务体系架构内的功能层。服务层通常位于应用协议层(诸如HTTP、CoAP或MQTT)之上，并为客户端应用提供增值服务。服务层还提供到位于较低资源层(诸如例如控制层和运输/接入层)的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层，以解决与M2M类型的设备和应用集成到诸如互联网/web、蜂窝、企业和家庭网络的部署中相关联的挑战。M2M服务层可以为应用和/或各种设备提供对由服务层支持的上述能力或功能的集合或组的访问，其中服务层可以被称为CSE或SCL。一些示例包括但不限于安全性、收费、数据管理、设备管理、发现、供应以及连接性管理，这些可以被各种应用共同使用。这些能力或功能经由使用由M2M服务层定义的消息格式、资源结构和资源表示的API对于此类各种应用可用。CSE或SCL是可以由硬件或软件实现的功能实体，并且该功能实体提供暴露于各种应用和/或设备的(服务)能力或功能(即，这些功能实体之间的功能接口)，以便它们使用这样的能力或功能。

如图27A中所示，M2M/IoT/WoT通信***10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以由向多个用户提供诸如语音、数据、视频、消息传送、广播等内容的多个接入网络组成。例如，通信网络12可以采用一种或多种信道接入方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。进一步地，例如，通信网络12可以包括其它网络，诸如核心网络、互联网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或企业网络。

如图27A中所示，M2M/IoT/WoT通信***10可以包括基础设施域和现场域(FieldDomain)。基础设施域是指端到端M2M部署的网络侧，并且现场域是指通常在M2M网关后面的区域网络。现场域和基础设施域两者都可以包括网络的各种不同网络装置(例如，服务器、网关、设备等)。例如，现场域可以包括M2M网关14和设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M设备18可以被包括在M2M/IoT/WoT通信***10中。M2M网关设备14和M2M设备18中的每一个被配置为使用通信电路***经由通信网络12或直接无线电链路来发送和接收信号。

M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M设备18可以经由通信网络12或直接无线电链路向M2M应用20或其它M2M设备18收集数据并且向M2M应用20或其它M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20被接收，如下所述。M2M设备18和网关14可以经由各种网络进行通信，其中网络包括例如蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。示例性M2M设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。

参考图27B，现场域中所示的M2M服务层22为M2M应用20、M2M网关14和M2M设备18以及通信网络12提供服务。将理解的是，M2M服务层22可以根据期望与任何数量的M2M应用、M2M网关14、M2M设备18和通信网络12进行通信。M2M服务层22可以由网络的一个或多个网络装置实现，这些节点可以包括服务器、计算机、设备等。M2M服务层22提供适用于M2M设备18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如作为web服务器、在蜂窝核心网中、在云中等。

类似于所示出的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为现场域中的M2M网关14和M2M设备18提供服务。将理解的是，M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M设备进行通信。M2M服务层22'可以由不同的服务提供商与服务层进行交互。M2M服务层22'可以由网络的一个或多个网络装置实现，其中网络装置可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。

还参考图27B，M2M服务层22和22'提供不同应用和行业可以充分利用的核心服务递送能力集合。这些服务功能使M2M应用20和20'能够与设备进行交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。基本上，这些服务能力免除了应用实现这些功能的负担，从而简化了应用开发并减少了成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过各种网络(诸如网络12)与服务层22和22'提供的服务相关联地进行通信。

M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭(connected home)、能量管理、资产跟踪以及安全性和监控。如上面所提到的，在***的设备、网关、服务器和其它网络装置之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及传统***集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。

一般而言，诸如图27B中所示的服务层22和22'之类的服务层定义软件中间件层，该软件中间件层通过应用编程接口(API)和底层联网接口的集合来支持增值服务能力。ETSI M2M和oneM2M体系架构两者都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在ETSI M2M体系架构的各种不同节点中实现。例如，服务层的实例可以在M2M设备内实现(其中它被称为设备SCL(DSCL))、在网关内实现(其中它被称为网关SCL(GSCL))和/或在网络节点内实现(其中它被称为网络SCL(NSCL))。oneM2M服务层支持公共服务功能(CSF)的集合(即，服务能力)。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，CSE可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。第三代合作伙伴计划(3GPP)还已经定义了用于机器类型通信(MTC)的体系架构。在该体系架构中，服务层及其提供的服务功能是作为服务能力服务器(SCS)的一部分实现的。无论是在ETSI M2M体系架构的DSCL、GSCL或NSCL中实施，在3GPP MTC体系架构的服务能力服务器(SCS)中实施，在oneM2M体系架构的CSF或CSE中实施，还是在网络的某个其它节点中实施，服务层的实例都可以被实现为在网络中的一个或多个独立节点(包括服务器、计算机以及其它计算设备或节点)上执行的逻辑实体(例如，软件、计算机可执行指令等)或者被实现为一个或多个现有节点的一部分。作为示例，服务层或其部件的实例可以以在具有下述图27C或图27D中所示的一般体系架构的网络装置(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现。

另外，本文描述的方法和功能可以被实现为使用面向服务的体系架构(SOA)和/或面向资源的体系架构(ROA)来访问服务的M2M网络的一部分。

图27C是网络的装置的示例硬件/软件体系架构的框图，其中装置诸如图1-26中所示的实体之一，其可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置进行操作，诸如图27A和27B中所示的。如图27D中所示，网络装置30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位***(GPS)芯片组50和其它***设备52。网络装置30还可以包括通信电路***，诸如收发器34和发送/接收元件36。将认识到的是，网络装置30可以包括前述元件的任何子组合，同时与实施例保持一致。这个网络装置可以是实现本文描述的消息模板管理能力和方法(诸如关于图1-26示出和描述的方法操作)的装置。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP内核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般而言，处理器32可以执行存储在网络装置的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行网络装置的各种所需功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理和/或使网络装置30能够在无线或有线环境中进行操作的任何其它功能。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。例如，处理器32还可以执行安全操作，诸如认证、安全密钥协商和/或加密操作，诸如在接入层和/或应用层。

如图27C中所示，处理器32耦合到其通信电路***(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路***，以便使网络装置30经由与其连接的网络与其它网络装置进行通信。特别地，处理器32可以控制通信电路***，以便执行本文(例如，图1-26中)和权利要求中描述的发送和接收步骤。虽然图27C将处理器32和收发器34描绘为分开的部件，但是将认识到的是，处理器32和收发器34可以一起集成在电子包装或芯片中。

发送/接收元件36可以被配置为向其它网络装置发送信号或从其它网络装置接收信号，其它网络装置包括M2M服务器、网关、设备等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。例如，在实施例中，发送/接收元件36可以是被配置为例如发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。将认识到的是，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任何组合。

此外，虽然发送/接收元件36在图27C中被描绘为单个元件，但是网络装置30可以包括任何数量的发送/接收元件36。更具体而言，网络装置30可以采用MIMO技术。因此，在实施例中，网络装置30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置为调制将由发送/接收元件36发送的信号并且解调由发送/接收元件36接收的信号。如上所述，网络装置30可以具有多模式能力。因此，例如，收发器34可以包括多个收发器，用于使网络装置30能够经由多个RAT(诸如UTRA和IEEE 802.11)进行通信。

处理器32可以从任何类型的合适存储器(诸如不可移除存储器44和/或可移除存储器46)访问信息，并将数据存储在该存储器中。例如，处理器32可以在其存储器中存储会话情境，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或任何其它类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从不物理地位于网络装置30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在该存储器中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色以反映装置的状态或对装置进行配置，以及特别是底层网络、应用或与网络装置进行通信的其它服务。在一个实施例中，显示器/指示器42可以呈现图31中所示并在本文描述的图形用户界面。

处理器32可以从电源48接收电力，并且可以被配置为向网络装置30中的其它部件分配和/或控制电力。电源48可以是用于为网络装置30供电的任何合适的设备。例如，电源48可以包括一个或多个干电池(例如，镍-镉(NiCd)、镍-锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。

处理器32还可以耦合到GPS芯片组50，该GPS芯片组50被配置为提供关于网络装置30的当前位置的位置信息(例如，经度和纬度)。将认识到的是，网络装置30可以通过任何合适的位置确定方法获取位置信息，同时与实施例保持一致。

处理器32还可以耦合到其它***设备52，该***设备52可以包括提供附加特征、功能和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，***设备52可以包括各种传感器，诸如加速度计、生物测定(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动设备、电视收发器、免提耳机、蓝牙

模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等等。

网络装置30可以在其它装置或设备中实施，其中其他装置或设备诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子卫生设备、机器人、工业装备、无人机、车辆(诸如小汽车、卡车、火车或飞机)。网络装置30可以经由一个或多个互连接口(诸如可以包括***设备52之一的互连接口)连接到这种装置或设备的其它部件、模块或***。

图27D是示例性计算***90的框图，该计算机***90还可以用于实现网络的一个或多个网络装置，诸如图1-26中所示并在本文描述的实体，其可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置进行操作，诸如图27A和27B中所示的。

计算***90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，计算机可读指令可以是软件的形式，无论在何处，或者通过任何方式可以存储或访问这样的软件。这种计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算***90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，协处理器81执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的***和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。

在操作中，CPU 91取出、解码并执行指令，并经由计算机的主数据传输路径，***总线80，向其它资源传送信息以及从其它资源传送信息。这种***总线连接计算***90中的部件并定义用于数据交换的介质。***总线80通常包括用于发送数据的数据线、用于发送地址的地址线、以及用于发送中断和用于操作***总线的控制线。这种***总线80的示例是PCI(***部件互连)总线。

耦合到***总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路***。ROM 93一般包含不能被容易地修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其它硬件设备读取或改变。对RAM 82和/或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，该地址翻译功能在执行指令时将虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，该存储器保护功能隔离***内的进程并将***进程与用户进程隔离。因此，以第一模式运行的程序只可以访问由其自身进程虚拟地址空间映射的存储器；除非已设置进程之间的存储器共享，否则它无法访问另一个进程的虚拟地址空间内的存储器。

此外，计算***90可以包含***设备控制器83，该***设备控制器83负责将来自CPU 91的指令传送到***设备，诸如打印机94、键盘84、鼠标95和磁盘驱动器85。

由显示控制器96控制的显示器86用于显示由计算***90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示控制器96包括生成被发送到显示器86的视频信号所需的电子部件。结合由CPU 91执行的计算机可执行指令，显示器86可以生成并操作图31及其随附的描述中所描述和示出的图形用户界面。

另外，计算***90可以包含通信电路***，诸如例如网络适配器97，其可以用于将计算***90连接到外部通信网络，诸如图27A-27D的网络12，以使计算***90能够与网络的其它装置进行通信。无论是单独还是与CPU 91组合，通信电路***可以用于执行本文(例如，在图1-26中)和权利要求中描述的发送和接收步骤。

应该理解的是，本文描述的任何或所有***、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，所述指令在由机器(诸如M2M网络的装置，包括例如M2M服务器、网关、设备等)执行时，执行和/或实现本文描述的***、方法和处理。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何非瞬态(即，有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字通用盘(DVD)或其它光盘存储装置、磁带盒、磁带、磁盘存储装置或其它磁存储设备、或者可以用于存储期望信息并且可以由计算机访问的任何其它有形或物理介质。

以下是与可能出现在以上描述中的服务层技术相关的首字母缩写词列表。除非另有说明，否则本文中使用的首字母缩写词是指下面列出的相应术语：

API 应用编程接口

CoAP 受限应用协议

CoRE 受限RESTful环境

CSE 公共服务实体

D2D 设备到设备

DSRC 专用短距离通信

F2C 雾到云

F2F 雾到雾

FN 雾节点

FE 雾实体

GUI 图形用户界面

HTTP 超文本传输协议

IEEE 电气和电子工程师协会

IoT 物联网

IP 互联网协议

IPv6 互联网协议版本6

LFN 本地FN

RSU 路边单元

WAVE 车载环境中的无线接入

WG 工作组

本书面描述使用示例来公开本发明，包括最佳模式，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或***以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有与权利要求的字面语言无差别的元素，或者如果它们包括与权利要求的字面语言无实质差别的等效元素，则这些其它示例意图在权利要求的范围内。

Claims (20)

1.一种由第一本地雾节点执行的方法，所述方法包括：

从应用接收提供服务的请求，其中提供服务的请求包括与服务相关联的雾服务描述；

基于与服务相关联的雾服务描述，确定第二本地雾节点被配置为提供服务；

向第二本地雾节点发送对提供服务的请求的指示；

从第二本地雾节点并基于对提供服务的请求的指示接收服务结果；以及

向应用发送服务结果。

2.如权利要求1所述的方法，还包括更新存储在第一本地雾节点处的信息，以指示第二本地雾节点被配置为提供服务。

3.如权利要求2所述的方法，其中提供服务的请求还包括与所述应用相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

4.如权利要求3所述的方法，其中对提供服务的请求的指示包括以下中的一个或多个：与第一本地雾节点相关联的标识符、与第一本地雾节点相关联的雾区域的标识符、与应用相关联的标识符以及与执行服务的请求相关联的标识符。

5.如权利要求4所述的方法，其中存储在第一本地雾节点处的更新后的信息包括与第二本地雾节点相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

6.如权利要求1所述的方法，还包括在发送对提供服务的请求的指示之前确定存储在第一本地雾节点处的一个或多个策略是否指示应用被授权接收服务。

7.如权利要求6所述的方法，其中第二本地雾节点在发送服务结果之前确定存储在第二本地雾节点处的一个或多个策略是否指示第一本地雾节点被授权接收服务结果。

8.一种包括处理器和存储器的设备，所述存储器存储计算机可执行指令，所述计算机可执行指令在由所述处理器执行时使得所述设备实现第一本地雾节点，该第一本地雾节点被配置为执行包括以下的操作：

从应用接收提供服务的请求，其中提供服务的请求包括与服务相关联的雾服务描述；

基于与服务相关联的雾服务描述，确定第二本地雾节点被配置为提供服务；

向第二本地雾节点发送对提供服务的请求的指示；

从第二本地雾节点并基于对提供服务的请求的指示接收服务结果；以及

向应用发送服务结果。

9.如权利要求8所述的设备，其中指令在被执行时还使得第一本地雾节点执行包括以下的操作：更新存储在第一本地雾节点处的信息，以指示第二本地雾节点被配置为提供服务。

10.如权利要求9所述的设备，其中提供服务的请求还包括与应用相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

11.如权利要求10所述的设备，其中对提供服务的请求的指示包括以下中的一个或多个：与第一本地雾节点相关联的标识符、与第一本地雾节点相关联的雾区域的标识符、与应用相关联的标识符以及与执行服务的请求相关联的标识符。

12.如权利要求11所述的设备，其中存储在第一本地雾节点处的更新后的信息包括与第二本地雾节点相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

13.如权利要求8所述的设备，其中指令在被执行时还使得第一本地雾节点执行包括以下的操作：在发送对提供服务的请求的指示之前确定存储在第一本地雾节点处的一个或多个策略是否指示应用被授权接收服务。

14.如权利要求13所述的设备，其中第二本地雾节点在发送服务结果之前确定存储在第二本地雾节点处的一个或多个策略是否指示第一本地雾节点被授权接收服务结果。

15.一种计算机可读存储介质，包括计算机可执行指令，所述计算机可执行指令在由设备执行时使得所述设备实现第一本地雾节点，该第一本地雾节点被配置为执行包括以下的操作：

从应用接收提供服务的请求，其中提供服务的请求包括与服务相关联的雾服务描述；

基于与服务相关联的雾服务描述，确定第二本地雾节点被配置为提供服务；

向第二本地雾节点发送对提供服务的请求的指示；

从第二本地雾节点并基于对提供服务的请求的指示接收服务结果；以及

向应用发送服务结果。

16.如权利要求15所述的计算机可读存储介质，其中指令在被执行时还使得第一本地雾节点执行包括以下操作：更新存储在第一本地雾节点处的信息，以指示第二本地雾节点被配置为提供服务。

17.如权利要求16所述的计算机可读存储介质，其中提供服务的请求还包括与应用相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

18.如权利要求17所述的计算机可读存储介质，其中对提供服务的请求的指示包括以下中的一个或多个：与第一本地雾节点相关联的标识符、与第一本地雾节点相关联的雾区域的标识符、与应用相关联的标识符以及与执行服务的请求相关联的标识符。

19.如权利要求18所述的计算机可读存储介质，其中存储在第一本地雾节点处的更新后的信息包括与第二本地雾节点相关联的标识符和与执行服务的请求相关联的标识符中的一个或多个。

20.如权利要求15所述的计算机可读存储介质，其中指令在被执行时还使得第一本地雾节点执行包括以下的操作：在发送对提供服务的请求的指示之前确定存储在第一本地雾节点处的一个或多个策略是否指示应用被授权接收服务。

Images