CN106465049B - 物联网的周期性管理稳定化 - Google Patents

Abstract

一种在网关上可执行的方法，所述网关能够与机器设备、用户设备和管理器设备进行通信。所述方法包括：从管理器设备接收请求与机器设备相关联的状态信息的第一请求，在此之后网关确定在哪些条件下获取所请求的状态信息以及将所获取的状态信息发送给管理器设备。接着网关基于对请求与机器设备相关联的更新的数据的第二请求的响应，确定机器设备的相关状态信息，第二请求是从使用的设备提供给机器设备的，并且响应是由网关从机器设备接收的，在此之后，包括确定的状态信息的通知从网关提供给管理器设备。

Description

物联网的周期性管理稳定化

技术领域

本公开涉及用于实现能够执行所提出的方法的机器设备、网关和管理器设备的管理的方法和装置。

背景技术

约束应用协议(CoAP)是被设计用于处理受限节点和受限网络中的机器对机器(M2M)应用的专用web传送协议。CoAP在端点之间提供基于请求响应的架构，其中通过用户数据报协议(UDP)在通常被分别称为CoAP服务器和CoAP客户端的实体之间执行通信。

CoAP被设计为易于与超文本传送防议(HTTP)一起工作，以与当前Web集成，同时增加附加的特征(诸如例如组播支持、非常低的开销和针对约束环境的简化性)。可以在http：//tools.ietf.org/html/draft-ietf-core-coap-18上找到关于CoAP的更多信息。

CoAP的一个可用扩展使得CoAP客户端能够观察来自CoAP服务器的可用资源，或者换句话说，允许CoAP服务器将可用资源通知给CoAP客户端，如可以在http：//tools.ietf.org/html/draft-ietf-core-observe-12中看到的。这使得能够在使用CoAP的受限网络中进行服务器发起的通信。

开放移动联盟设备管理轻量级(OMA DM LW)是为M2M网络而开发的轻而紧凑的设备管理协议，其包括用于实现LWM2M的设备的设备管理和服务实现，如在LightweightMachine to Machine Technical Specification，Candidate Version 1.0-10 Dec.2013，OMA-TS-LightweightM2M-V1_0-20131210-C，5.1-5.4节中描述的。设计用于受限网络，OMADM LW可以在UDP和SMS绑定两者上运行。这使得OMA DM LW能够适用于使用CoAP的任何类型的受限设备或网络。

类似于CoAP，OMA DM LW的架构是基于客户端-服务器模型(包括LWM2M服务器和LWM2M客户端两者)的。然而，在OMA DM LW中，LWM2M客户端在将被控制的受限设备中运行，而LWM2M服务器表示具有某种管理能力的节点，其可以是网关(GW)或网络节点。对于典型的物联网(IoT)场景，具有多个客户端、一些服务器以及充当中继或代理的一些节点将是常见的，其中这些节点中的每个节点包括客户端和服务器侧两者。事实上，非常像CoAP，服务器和客户端之间的前沿可能是模糊的，因为所有的LWM2M客户端最可能也是CoAP服务器，并且大多数LWM2M服务器也应当是CoAP客户端。

OMA DM LW引入了用于管理的简单的基于对象的资源模型，其从CoAP继承以在LWM2M服务器和LWM2M客户端之间使用。在这个模型中，LWM2M客户端提供的每条信息都是资源，并且资源在逻辑上被组织为对象。因此，对象定义了资源的分组，例如，对象ID3“设备”包含用于设备相关信息的所有资源。

OMA DM LW为访问对象提供若干接口，其中“信息报告”被提供用于错误报告。该接口允许LWM2M服务器观察资源并且每当在网络中发生改变时被通知(基本遵循发布/订阅范例)。

现有的管理解决方案通常由以下实体组成：

·机器设备(MD)：设备(可以是受限设备)包括一个或多个传感器和/或致动器，其中设备运行一些管理代理(在本文LWM2M协议用于此目的)，管理代理必须提供关于传感器正在感测什么的信息以及报告管理错误和其它相关问题。传感器还可以运行常规CoAP服务器以为用户提供对读数的访问。

·管理器设备：运行管理应用的实体，管理应用负责发送命令、更新固件和MD的其它对象。在实际部署中，管理器设备还可以包含LWM2M服务器。

·网关(GW)：在MD是自身不能够提供足够的互联网连接的受限设备的情况下，在代理和管理器设备之间布置该实体。GW向其MD运行资源目录(RD)并且可能运行接收的消息的缓存(例如诸如镜像代理(MP))。GW还向管理器设备运行一些管理协议(在该示例中为LWM2M)。在每个MD的注册过程(通常在引导MD时被执行)期间，MD注册到GW中的RD。

·用户：最终用户，其能够经由包括CoAP客户端的通信设备请求和接收MD的最新测量。

通常存在可以在MD的传感器上完成的多个管理操作(例如诸如更新固件、改变访问控制策略、改变安全设置和设置报警)。在LWM2M中，在每个设备中存在特定的对象以表示这种类型的信息。该特征继承自CoAP对象和资源；事实上，LWM2M在工作方式上与CoAP几乎相同。该管理器可以使用GET消息或PUT消息来获取或存储关于这些对象中的任何对象的信息并且通过使用Observe命令来设置通知。

管理器设备需要用于管理MD的另一个功能是要知道MD是否被连接。这对于大型IoT部署尤其如此。然而，仅仅为了跟踪各种设备的一般状态通常需要向管理器设备的大量消息开销。

尽管事实上CoAP协议和LWM2M协议两者极其相似，但是它们当前不能够彼此进行通信。管理对象仅仅用于管理目的，而数据平面对象或资源仅仅用于数据或用户平面信息。换言之，当测量信息被提供到CoAP客户端时，管理报告被提供给LWM2M服务器，这不是理想的情况。更具体地，LWM2M在CoAP上运行，其中CoAP定义了多个消息和实体(例如诸如RD和/或MP)以促进与用户的通信。利用其它协议(例如诸如HTTP或简单网络管理协议(SNMP))，通常可以在数据平面和控制平面之间具有明确的区分，但是利用CoAP和LWM2M，使用CoAP来封装所有消息。

这将通常意味着使用CoAP的所有实体将知道彼此，并且将优化协议以发送尽可能少的消息。然而这里不是如此。

通常，CoAP消息将用于数据平面(例如用于获得传感器读数或资源发现)，而LWM2M用于管理命令(例如诸如错误报告)。这两种类型的消息/命令将作为MD中的不同进程(即，分别作为用户进程和管理器进程)运行。

这意味着将存在大量的消息重叠和消息开销。MD被唤醒的事实将例如被通告两次，一次针对用户以及一次针对管理器设备。

当使用标准LWM2M时，管理器设备可以设置当特定的MD被唤醒时将被接收的通知。管理器设备还可以轮询MD中的对象以获知其是否被连接。然而，这是非常低效率的过程，因为每个MD每次醒来时必须发送一个消息，表示它是醒着的，以及因此，在每次这种情况下，管理器设备将针对每个设备接收一个额外的消息。这显然带来可扩展性问题，因为随着部署的MD的数量的增加，将需要部署专用机器以聚合和处理管理信息。也不难得到，在将来管理消息将获得与数据消息一样大，其将甚至进一步增加所有相关实体的工作量。

发明内容

本文的目的是解决或至少减轻以上描述的问题中的至少一些问题。

根据一个方面，提出了一种在网关上可执行的方法，所述网关能够与机器设备、用户设备和管理器设备进行通信。所提出的方法包括：从所述管理器设备接收请求与所述机器设备相关联的状态信息的第一请求；确定在哪些条件下获取所请求的状态信息，并向所述管理器设备发送所获取的状态信息；基于对请求与所述机器设备相关联的更新的数据的第二请求的响应，确定所述机器设备的相关状态信息，所述第二请求是从使用的设备提供给所述机器设备的，以及所述响应是由所述网关从所述机器设备接收的，以及将包括所确定的状态信息的通知提供给所述管理器设备。

所提出的方法的一个优点在于，可以利用已经由机器设备应用于更新用户设备，还用于获得对机器设备的当前状态的更新的目的的常规状态更新，由此减少获得上述信息所需的信令的总量。

根据一个实施例，在确定相关状态之前向机器设备转发第一请求。

在状态报告要有时间限制的情况下，则可以应用定时器，其中以上所述的方法还包括以下步骤：在向所述机器设备转发所述第二请求时启动定时器，以及基于以下来确定相关状态信息：在所述定时器超时之前接收到对所述第二请求的响应的情况下，所述响应的内容，或者在所启动的定时器超时之前没有接收到所述响应的情况下，所述网关已经知道的状态信息。

根据一个实施例，获取所请求的状态信息的条件是从所述管理器设备提供给所述网关的。

一旦在对第二请求的响应中已经接收到状态信息，则它可以根据一个实施例存储在网关上或对网关是可访问的。

根据另一个方面，提出了一种计算机程序，包括当运行在计算机上时使得计算机执行根据以上描述的实施例中的任何一个实施例的方法的代码装置。

根据又一方面，提出了一种计算机程序产品，包括计算机可读代码装置和如上所述的计算机程序，并且所述计算机程序存储在所述计算机可读代码装置上。

根据另一个方面，提供了一种在管理器设备上可执行的方法，所述管理器设备能够经由网关与机器设备进行通信。所述方法包括：向所述网关发送第一请求，所述第一请求请求所述网关基于对第二请求的响应的内容提供与所述机器设备相关联的状态信息，所述第二请求用于请求与所述机器设备相关联的更新的数据，所述第二请求是从使用的设备提供给所述机器设备的，并且所述响应是由所述网关从所述机器设备接收的，以及从所述网关接收包括所请求的状态信息的通知。

根据一个实施例，第一请求还包括向所述网关指示所述网关在哪些条件下要获取所请求的状态信息的指令。

更具体地，指令可以被配置为指示网关在从所述机器设备接收到响应的情况下，从所述响应获取所请求的状态信息，或在未接收到所述响应的情况下，从所述网关的存储器获取与所述机器设备相关联的状态信息。

根据另一个方面，提出了一种计算机程序，包括当运行在计算机上时使得计算机执行根据在管理器设备上可执行的方法的实施例中的任何一个实施例的方法的代码装置。

根据又一方面，提出了一种计算机程序产品，包括计算机可读代码装置和如上所述的计算机程序，并且所述计算机程序存储在所述计算机可读代码装置上。

根据另一个方面，提出了一种能够与机器设备、用户设备和管理器设备进行通信的网关，其中所述网关包括用于执行以下操作的装置：从所述管理器设备接收请求与所述机器设备相关联的状态信息的第一请求；确定在哪些条件下获取所请求的状态信息，并向所述管理器设备发送所获取的状态信息；基于对请求与所述机器设备相关联的更新的数据的第二请求的响应的内容，确定所述机器设备的相关状态信息，所述第二请求是从使用的设备提供给所述机器设备的，以及所述响应是由所述网关从所述机器设备接收的，以及将包括所确定的状态信息的通知提供给所述管理器设备。

网关还包括用于向所述机器设备转发所述第一请求的装置。

在网关将时限应用于向管理器设备报告状态的情况下，以上提出的方法还包括用于执行以下操作的装置：在向所述机器设备转发所述第二请求时启动定时器，以及基于以下来确定相关状态信息：在所述定时器超时之前接收到对所述第二请求的响应的情况下，所述响应的内容，或者在所启动的定时器超时之前没有接收到所述响应的情况下，所述网关已经知道的状态信息。

通常，网关还包括用于存储在对第二请求的响应中接收的状态信息的装置。

根据又一方面，提出了一种能够与机器设备、用户设备和管理器设备进行通信的网关。网关包括处理器和存储器，其中存储器包括指令，当由处理器执行时使得网关执行以下动作：从所述管理器设备接收请求与所述机器设备相关联的状态信息的第一请求；确定在哪些条件下获取所请求的状态信息，并向所述管理器设备发送所获取的状态信息；基于对请求与所述机器设备相关联的更新的数据的第二请求的响应的内容，确定所述机器设备的相关状态信息，所述第二请求是从用户设备提供给所述机器设备的，以及所述响应是由所述网关从所述机器设备接收的，以及将包括所确定的状态信息的通知提供给所述管理器设备。

根据另一个方面，提出了能够与机器设备和网关进行通信的管理器设备。管理器设备包括用于执行以下操作的装置：向所述网关发送第一请求，所述第一请求请求所述网关基于对第二请求的响应的内容提供与所述机器设备相关联的状态信息，所述第二请求用于请求与所述机器设备相关联的更新的数据，所述第二请求是从使用的设备提供给所述机器设备的，并且所述响应是由所述网关从所述机器设备接收的，以及从所述网关接收包括所请求的状态信息的通知。

根据一个实施例，所提出的装置将向所述网关指示所述网关在哪些条件下要获取所请求的状态信息的指令包括在第一请求中。

所提出的装置可以被配置为将指令提供到网关，在从所述机器设备接收到响应的情况下，从所述响应获取所请求的状态信息，或在未接收到所述响应的情况下，从所述网关的存储器获取与所述机器设备相关联的状态信息。

根据另一个方面，提出了能够与机器设备和网关进行通信的管理器设备。管理器设备包括处理器和存储器，其中存储器包括指令，其当由处理器执行时使得管理器设备执行以下操作：向所述网关发送第一请求，所述第一请求请求所述网关基于对第二请求的响应的内容提供与所述机器设备相关联的状态信息，所述第二请求用于请求与所述机器设备相关联的更新的数据，所述第二请求是从使用的设备提供给所述机器设备的，并且所述响应是由所述网关从所述机器设备接收的，以及从所述网关接收包括所请求的状态信息的通知。

附图说明

现在将关于附图来更详细地描述实施例，在附图中：

图1是示出了用户和管理器设备如何可以经由网关从机器设备获取信息的信令方案。

图2是示出了在机器设备中执行的用于处理源自用户设备的请求的方法的流程图。

图3是示出了在网关中执行的用于处理源自用户设备的请求和用于基于所述请求来更新管理器设备的方法的流程图。

图4是示出了能够执行图2的方法的根据第一实施例的机器设备的框图。

图5是示出了能够执行图2的方法的根据第二实施例的机器设备的框图。

图6是示出了能够执行图3的方法的根据第一实施例的网关的框图。

图7是示出了能够执行图3的方法的根据第二实施例的网关的框图。

图8是示出了在管理器设备中可执行的用于提供机器设备状态更新的方法的流程图。

图9是示出了能够执行图8的方法的根据第一实施例的管理器设备的框图。

图10是示出了能够执行图8的方法的根据第二实施例的管理器设备的框图。

具体实施方式

提出了一种简要描述的可以被称为周期性管理稳定化过程的方法，用于优化将被分布在管理器设备和在机器设备或M2M设备(其通常是受限设备)中可操作的代理之间的消息的处理。公开的过程可以使用并且利用已经使用的数据平面消息(本文被称为CoAP消息)上的搭载，以便获取关于代理是否是醒着的信息，或知道其它状态信息，其可以从接收的COAP消息中进行解释得到。

现在，MD将通常被布置于自身包含RD的GW之后，因为配置为受限设备的大多数MD自身不具有朝向因特网的任何蜂窝或其它连接功能。每当GW接收经由GW向MD发送的CoAP观察消息(其可以不同于LWM2M观察)时，GW将尝试轮询MD的所请求的资源。如果MD是休眠的，则GW将尝试访问缓存的数据(例如通过将请求转发到镜像代理(MP))，之后用户将从MP获得最新缓存的读数。

为了避免这种类型的轮询，这里充当CoAP客户端的用户将能够观察传感器资源并且当观察的传感器资源改变时获得通知，例如以下在http：//tools.ietf.org/html/draft-ieft-core-observe-12中给出的因特网工程任务组(IETF)示例：

对于具有附接的温度传感器的CoAP服务器，服务器可以揭露参数化资源：

<coap：//server/temperature/critical？above＝45>，如果温度超出指定的值(本文为45℃)，则将其状态改变为当前温度，以及当温度下降到低于该阈值时，则将其状态改变为“OK”；

在以上描述的场景中，当MD的资源的当前状态改变时，CoAP服务器将通知CoAP客户端关于MD的资源的当前状态。因为通常情况下MD布置在某个GW之后，所以该GW将该改变转发给用户。根据观察选项规范，以上提到的观察的对象可以直接可替代地是GW。

作为对以上提到的过程的替代，本文提出了一种方法，其中GW还默认产生要被发送到管理器设备的新的LWM2M通知消息，目的是提醒管理器设备：MD(其包括至少一个传感器)现在是醒着的。默认情况下，GW不知道从CoAP服务器提供到CoAP客户端的消息的内容；然而尽管可能加密，但是管理器设备可以知道MD的CoAP服务器生成至少一个消息并且它因此当前是醒着的。根据替代实施例，可以周期性地生成要发送到管理器设备的通知(聚合GW/RD下的多个资源)。

现在将参考图1来更详细描述以上提出的方法，其描述了配置为处理多个机器设备(每个包括传感器和/或致动器中的一个或多个)、CoAP服务器和LWM2M客户端的网络，其中为了简单起见，这些机器设备(MD)中的仅仅一个(即：正在改变状态的MD 400；500)是特别感兴趣的，并且因此在图中示出。图1还示出了一个本文称为用户设备800的通信设备，包括CoAP客户端801，其能够经由包括CoAP资源目录(RD)601和CoAP镜像代理(MP)602的位于中间的网关(GW)600；700获取关于MD的更新。此外，包括CoAP服务器901的管理器设备900；1000正在发起所描述的过程。在本布置中，虽然关于MD 400；500的传感器/致动器输出来更新用户设备800，但是关于MD 400；500的状态来更新管理器设备900；1000。

如在图1中所示，在MD 400；500的引导期间，管理器设备900；1000通过将创建消息发送到GW 600；700来在GW 600；700中创建新对象(Status_Object)，如以第一步骤1:10指示的。可选地，该消息还可以包含关于如何(即，在哪些条件下)聚合来自MD 400；500的通知(例如PDU的大小、最大增量(Delta)等)的对GW 600；700的指令。在后者情况下，可以应用特定的延迟时间以便收集更多的通知以进行聚合。在创建响应消息中，GW 600；700将包括新对象的位置和MD 400；500的现有状态信息。在本示例中，一系列MD已经在RD(注意：在LWM2M中的注册期间，LWM2M客户端被假定在RD下创建每个设备的条目)及其相应的URN中注册。该创建响应消息被指示为步骤1:20。在给定的示例中，现有三个MD的RD位置是[/jlks78，/83njf，/jfhl9]，其URN为例如[91058，260890，210995]以及其当前状态为[0，0，0])，其中当前状态“0”指示MD为关闭，而设置为“1”的状态指示相应的MD为开启。显然，在给定的示例中，所有三个MD都是初始关闭的。

一旦已经在GW 600；700中创建了上述对象，则管理器设备900；1000将观察Status_Object，如在第三步骤1:30中指示的。在给定的示例中，这意味着该消息指示GW600,700：在将另一个通知发送给管理器设备900；1000之前，其将等待至少最小时间间隔(例如10秒)，并且绝不超过最大时间间隔(例如120秒)，即：即使在确定的最大时间间隔内没有MD改变，也将在该时间间隔之后将通知从GW 600；700发送给管理器设备900；1000。应用提出的时间间隔以便至少每120秒保持在管理器设备900；1000上的最新状态信息，以及使得管理器设备900；1000仍然恰好地获得状态更新。在这一点上，每当在由MD表示的资源中的任何一个资源中存在修改时(即，当MD 400；500通过发送CoAP消息来回复CoAP数据请求时)，GW 400；500应当用作为LWM2M消息提供的通知来通知管理器设备900；1000。

在给定的示例中，运行CoAP客户端的用户设备800向GW600；700发出GET请求，在本文中以便从MD 400；500获得最新的温度测量结果，如以步骤1:40所指示的：

coap：//temp1.92738.room1.example.com/temperature。

在这种情况下RD和MP两者共同位于GW 600；700中，所以发现是立即的。GW 600；700简单地将请求转发到MD 400；500，如以步骤1:50所指示的。MD 400；500接收由GW 600；700在步骤1:50中发送的GET请求，并且在可确认的响应上搭载具有请求的温度信息的有效载荷，如以步骤1:60所指示的，并且在另一个步骤1:70中将该信息发送到GW 600；700。GW600；700将该信息转发到用户设备800，如在另一个步骤1:80中所指示的。GW 600；700将不能够读取从MD中的任何一个MD提供的有效载荷的内容，因为通常这样的内容将被加密，但是GW 600；700将在任何情况下能够确定步骤1:70的消息实际上是从特定的MD 400；500接收的，并且因此，仅根据该信息，GW 600；700能够确定该机器设备400；500现在是醒着的。GW600；700将在下一个步骤1:90改变在Status_Object中的MD 400；500状态，因为管理器设备400；500先前在该对象中设置了观察，如以上以步骤1:30所指示的。GW 600；700然后在另一个消息1:100的有效载荷中将MD 400；500新发现的醒着状态通知管理器设备400；500，而其它参数(即RD位置和URN)保持相同(即不变)。

同时，通过在步骤1:50中转发请求，GW可以启动定时器，并且在本示例中，在120秒内没有接收到响应的情况下，与在步骤1:100中发送的消息相对应的响应将发送到管理器设备900；1000，然而这次指示MD 400；500不是醒着的。在后者情况下，没有与步骤1:80相对应的消息将被发送到用户设备800，因为仅当从MD 400；500实际接收到更新时才通知用户设备800。可替代地，在针对向管理器设备900；1000报告没有设置任何最大时间的情况下，不存在来自MD 400；500的响应(即，任何步骤1:70响应)，简单地导致没有消息从GW 600；700提供到管理器设备900；1000。

总而言之，在数据平面中的任何改变(即：在传感器的输出中的更新(使用平面更新))将提供给用户设备(CoAP消息)和管理器设备(LWM2M消息)两者，而管理更新(本文通常为MD的状态更新)将仅仅由GW提供给管理器设备。

以上论述的方法提议使用Status_Object来以压缩方式从MD获得状态信息。这可以容易地在LWM2M规范的基础上实现，因为我们仅需要创建新的对象并相应地设置基本配置参数。

公开的方法还更好地使用CoAP和LWM2M的共同点以及它们两者均使用的实体。

所公开的方法增强了管理可扩展性，因为针对每个RD/GW它需要1个创建消息+1个观察消息，并且需要周期性发起的通知的数量限于类似数量的通知，而不管网络是包括1个MD还是100个MD(MD被布置在GW之后)。相反，在当前的LWM2M规范中，管理意味着在每个LWM2M客户端中设置特定的对象并且需要在GW或其它网络实体中的聚合机制，它还需要在受限设备上更多的计算和消息收发。更具体地，在通常已知的场景中，LWM2M服务器将必须在每个相应的MD本身中写入观察，指示它每次它醒来时通知LWM2M服务器。因为MD通常是功率受限设备，所以期望需要从这些实体发送的消息的数量的减少。当应用如以上提出的方法时这将不是必要的。

此外，通过聚合从GW发送到管理器设备的报告，可以甚至进一步减少需要的信令。

当MD向CoAP客户端发送CoAP响应时，它将同时产生将提供到管理器设备的通知，而不是仅仅一个单个消息。

所提出的方法以恰好的方式使GW实时知道MD是否是醒着的，而不必在相应的LWM2M客户端中设置任何特定的信息。还可以获取该信息，而不管在MD和用户之间使用的任何加密，即：可以获取所需的信息而不需要消息的任何解密，而是简单地通过这样接收它。

图2是当在MD执行时的以上所述的方法的流程图，其中，在第一步骤2:10中，MD接收从用户设备经由网关提供的请求资源(这里为MD)的观察的请求。MD以常规方式处理请求(例如通过提供来自一个或多个传感器的新的结果，通过附接(通常通过将这样的内容搭载在可确认的常规响应上))，如以步骤2:20所指示的，并且将响应发送到GW以在那里进行进一步处理。

图3是示出了在GW执行的相应的方法的另一个流程图。在第一步骤3:10中，由管理器设备发起并且从管理器设备接收监视一个或多个MD的状态的请求。在下一个步骤3:20中，通过确定或协商在哪些条件下将执行MD的监视来完成在步骤3:10发起的过程。在步骤3:20中已经解决了用于获得状态更新的最大时限的情况下，一旦在步骤3:20中已经解决了条件，则可以启动定时器，如以可选的步骤3:30指示的。只要还未达到这样的时限，过程就在步骤3:40继续，其中检查是否已经接收到来自的用户的用于从至少一个MD获得更新的输出的请求。一旦确定已经接收到请求，则向相应的MD路由这样的请求，如在下一个步骤3:50中所指示的。一旦在步骤3:50中已经转发请求，如果当等待响应时将应用时限(如在步骤3:60中所指示的)，以确定GW应当等待来自MD的响应多长时间(如在以下的步骤3:70中所指示的)，则通常启动另一个定时器。一旦从MD接收到响应，则GW更新MD状态，如在步骤3:80中所指示的，并且将响应转发到用户设备，如以步骤3:90所指示的。在下一个步骤3:100中，将MD的当前状态发送到管理器设备。如在图3中所指示的，在步骤3:30的定时器到期的情况下，还执行当前状态到管理器设备的发送。显然，在从MD接收到响应的情况下，状态将被设置为“On”，而在没有响应的情况下，状态将被设置为“Off”。如果在步骤3:70中没有接收到响应，则同样适用。如已经提到的，步骤3:100可以配置为推迟预定的时间间隔，例如在将执行来自多个MD的结果的聚合的情况下。一旦更新已经提供给管理器设备，如果将应用这样的定时器，则过程从步骤3:30重复(通过再次初始启动定时器)，但是在任何情况下，通过等待来自用户设备的另一个请求来继续该过程。

图4示出了MD或MD的至少一部分的一个可能的配置，MD或MD的至少一部分能够执行方法，例如以上参考图2描述的方法。更具体地，图4的MD 400包括至少一个处理器410，其能够执行存储在存储器420中的指令430或代码，使得当执行指令430或代码时执行以上提到的方法。MD 400还包括通信接口440，其配置为基于MD 400和GW 600之间的任何类型的已知的通信标准来实现无线或固定通信。可替代地，通信接口440配置为经由中间节点实现MD400和GW 600；700之间的通信，这不在本文的范围之内。根据一个实施例，存储器420和指令430可以被包括在计算机产品450中，其可以例如是可移动固态存储器(例如闪存存储器，例如诸如光盘，例如诸如致密盘(CD)或数字多功能盘(DVD)或蓝光盘或通用串行总线(USB)驱动器)或适于附接或插入MD上的任何其它类型的存储器装置。

根据另一个实施例，MD 500被配置为包括通信接口510(其可以与图4的通信接口440相对应)、存储器520(其可以与图4的存储器420相对应)以及功能模块(其可以被配置为软件模块、硬件模块或两者的组合)。这里，模块通过通信模块530和响应模块540来表示，通信模块530被配置为执行图2的步骤2:10和2:30，响应模块540被配置为执行图2的步骤2:20。MD 500还包括CoAP服务器550和LWM2M客户端560，它们中的每个能够分别与其它相应的客户端和服务器进行通信，如本文所述的。更具体地，根据以上提出的实施例中的任何实施例，MD被配置为识别从GW接收的请求并且如以上提出的对这样的请求作出响应，使得网络节点(包括GW)和包括管理功能的网络节点(本文称为管理器设备)可以知道MD是否开启。

图6示出了GW或包括GW功能的另一个网络节点(其能够执行方法，例如以上参考图3描述的方法)的一个可能的配置。更具体地，图6的GW 600包括至少一个处理器610，其能够执行存储在存储器620中的指令或代码，使得当执行指令630或代码时执行以上提到的方法。GW 600还包括一个或多个通信接口(这里由通信接口640来表示)，其被配置为经由用户设备800和GW 600，基于GW和管理器设备900、一个或多个MD 400,500以及一个或多个用户设备800(能够访问MD 400,500中的至少一个)之间的任何类型的已知的通信标准来实现无线或固定通信。可替代地，通信接口640被配置为经由一个或多个中间节点实现提到的节点或设备之间的通信，这不在本文的范围之内。根据一个实施例，存储器620和指令630可以包括在计算机产品650中，其可以例如是可移动固态存储器(例如闪存存储器，例如诸如光盘，例如诸如致密盘(CD)或数字多功能盘(DVD)或蓝光盘或通用串行总线(USB)驱动器)或适于附接或插入GW上的任何其它类型的存储器装置。

根据图7中示出的另一个实施例，GW 700被配置为包括至少一个通信接口(本文通过通信接口710来表示)(其可以与图6的通信信接口630相对应)、存储器720(其可以与图6的存储器620相对应)以及功能模块(其可以配置为软件模块、硬件模块或两者的组合)。本文通过通信模块730(其配置为执行图3的步骤3:10、3:40、3:50、3:70、3:90和3:100)、确定模块740(其配置为执行步骤3:20)、更新模块750(其配置为执行步骤3:80)和定时器模块760(其配置为执行图3的步骤3:30和3:60)来表示模块。虽然在图中未明确指示，但是GW700还通常包括资源目录和代理镜像，或能够提供将如本文描述的那样使用的相应的功能的模块。更具体地，根据以上提出的实施例中的任何实施例，GW被配置为向用户提供更新的MD数据以及，作为接收对发送给MD的请求的响应的结果，还通过应用与本文描述的机制相对应的机制将MD的状态更新提供给管理器设备。图8是示出了在网络节点上可执行的方法的流程图，所述网络节点能够执行管理过程，本文称为管理器设备。在第一步骤8:10中，管理器设备将请求发送给网关，将关于在哪些条件下状态更新的指令提供给网关，指示机器设备的资源的状态将提供给管理器设备。在下一个步骤8:20中，如果适当条件适用，如已经在上面描述的，则管理器设备从网关接收状态更新，并且在下一个最后步骤8:30中，管理器设备可以更新状态，并且如果需要，还可以经由任何合适的呈现装置将状态呈现给例如操作者。该过程可以通过等待另一个状态更新消息而继续，直到从管理器设备提供替代指令为止。根据一个实施例，存储器820和指令830可以包括在计算机产品840中，其可以例如是可移动固态存储器(例如闪存存储器，例如诸如光盘，例如诸如致密盘(CD)或数字多功能盘(DVD)或蓝光盘或通用串行总线(USB)驱动器)或适于附接或插入在管理器设备上的任何其它类型的存储器装置。

图9示出了管理器设备900或包括如以上参考图8描述的管理功能的网络节点的至少一部分的一个可能的配置。更具体地，图9的管理器设备900包括至少一个处理器910，其能够执行存储在存储器920中的指令930或代码，使得当执行指令930或代码时执行以上提到的方法。管理器设备900还包括通信接口940，其配置为基于管理器设备900和GW 600；700之间的任何类型的已知的通信标准来实现无线或固定通信。可替代地，通信接口930配置为经由一个或多个中间节点来实现管理器设备900和GW 600,700之间的通信，这不在本文的范围之内。根据一个实施例，存储器920和指令930可以包括在计算机产品650中。

根据如在图10中示出的另一个实施例，管理器设备1000配置为包括通信接口1010(其可以与图9的通信接口930相对应)、存储器1020(其可以与图9的存储器920相对应)和功能模块(其可以配置为软件模块、硬件模块或两者的组合)。这里通过通信模块1030(其配置为执行图8的步骤8:10和8:20)和更新模块1040(其配置为执行图8的步骤8:30)来表示模块。管理器设备1000还包括能够经由通信接口1010与GW进行通信的CoAP服务器1050。更具体地，根据以上提出的实施例中的任何一个实施例的管理器设备1000被配置为指示GW在哪些条件下接收状态更新；识别从GW接收的更新以及更新状态(如在接收的更新中指示的)。

应当理解的是，在本公开内的模块或单元的选择以及模块或单元的命名仅仅为了示例目的。还应当注意的是，在本公开中描述的模块或单元将被视为逻辑实体，其不必配置为单独的物理实体，但是可以可替代地配置为组合的单元或模块(只要可以获得所描述的功能)。

以上提到的处理器中的任何处理器可以是单个CPU(中央处理单元)，但是还可以包括两个或多于两个处理单元。例如，处理器可以包括通用微处理器、指令集处理器和/或相关芯片集和/或例如ASIC(专用集成电路)的专用微处理器。处理器还可以包括用于缓存目的的板存储器。计算机程序可以通过连接到处理器的计算机程序产品来携带。计算机程序产品可以包括其上可以存储计算机程序的计算机可读介质。例如，计算机程序产品可以是闪存、RAM(随机访问存储器)ROM(只读存储器)或EEPROM。

应当理解的是，为了简单起见，以上描述的每个节点或设备已经被简化，使得仅仅已经添加与理解描述的技术解决方案相关的功能，而已经省略对于理解所提出的概念不必要的其它常用功能。

还应当理解的是，在本公开内的交互单元的选择以及单元的命名仅仅为了示例目的，并且适于执行以上描述的方法中的任何方法的节点可以以多个替代方式进行配置以便能够执行所提出的程序动作。

还应当注意的是，在本公开中描述的单元将被视为逻辑实体而不必视为单独的物理实体。

所附权利要求的范围不应当受限于如在以上给定的示例中阐述的优选的实施例，而应当被给予与作为整体的描述一致的最宽的解释。

Claims (11)

1.一种在网关上可执行的方法，所述网关能够与机器设备、用户设备和管理器设备进行通信，所述方法包括：

-从所述管理器设备接收(3:10)请求与所述机器设备相关联的状态信息的第一请求；

-确定(3:20)在哪些条件下更新所请求的状态信息，以及在哪些条件下向所述管理器设备发送所获取的状态信息；

-基于对请求与所述机器设备相关联的更新的数据的第二请求的响应，并通过应用所确定的更新所请求的状态信息的条件，确定(3:80)所述机器设备的相关状态信息，所述第二请求是从用户设备接收并由所述网关转发给所述机器设备的，以及所述响应是由所述网关从所述机器设备接收的，以及

-根据所确定的向所述管理器设备发送所获取的状态信息的条件，将包括所确定的状态信息的通知提供(3:100)给所述管理器设备。

2.根据权利要求1所述的方法，其中，在确定相关状态之前：

-向所述机器设备转发(3:50)所述第一请求。

3.根据权利要求1或2所述的方法，还包括：

-在向所述机器设备转发(3:50)所述第二请求时启动定时器，以及

-基于以下来确定(3:80)所述相关状态信息：

-在所述定时器超时之前接收到对所述第二请求的响应的情况下，所述响应的内容，或

-在所启动的定时器超时之前没有接收到所述响应的情况下，所述网关已经知道的状态信息。

4.根据权利要求1所述的方法，其中，获取所请求的状态信息的条件是从所述管理器设备提供给所述网关的。

5.根据权利要求1所述的方法，还包括以下步骤：

-存储在对所述第二请求的响应中接收的状态信息。

6.一种计算机可读存储介质，包括代码装置，当在计算机上运行时，所述代码装置使得所述计算机执行根据权利要求1-5中任一项所述的方法。

7.一种能够与机器设备(400；500)、用户设备(800)和管理器设备(900；1000)进行通信的网关(600)，所述网关(600)包括处理器(610)和存储器(620)，所述存储器(620)包括当由所述处理器(610)执行时使得所述网关(600)执行以下操作的指令：

-从所述管理器设备(900；1000)接收请求与所述机器设备(400；500)相关联的状态信息的第一请求；

-确定在哪些条件下更新所请求的状态信息，以及在哪些条件下向所述管理器设备(900；1000)发送所获取的状态信息；

-基于对请求与所述机器设备(400；500)相关联的更新的数据的第二请求的响应的内容，并通过应用所确定的更新所请求的状态信息的条件，确定所述机器设备(400；500)的相关状态信息，所述第二请求是从用户设备(800)接收并由所述网关(600)转发给所述机器设备(400；500)的，以及所述响应是由所述网关(600)从所述机器设备(400；500)接收的，以及

-根据所确定的向所述管理器设备(900；1000)发送所获取的状态信息的条件，将包括所确定的状态信息的通知提供给所述管理器设备(900；1000)。

8.根据权利要求7所述的网关(600)，其中，所述存储器(620)包括当由所述处理器(610)执行时使得所述网关(600)执行以下操作的指令：

-向所述机器设备(400；500)转发所述第一请求。

9.根据权利要求7或8所述的网关(600)，其中，所述存储器(620)包括当由所述处理器(610)执行时使得所述网关(600)执行以下操作的指令：

-在接收到所述第一请求时启动第一定时器，以及

-仅仅在所述网关(600)在所述第一定时器超时之前接收到所述第二请求的情况下，向所述机器设备(400；500)转发所述第一请求。

10.根据权利要求7所述的网关(600)，其中，所述存储器(620)包括当由所述处理器(610)执行时使得所述网关(600)执行以下操作的指令：

-在向所述机器设备(400；500)转发所述第二请求时启动定时器，以及

-基于以下来确定所述相关状态信息：

-在所述定时器超时之前接收到对所述第二请求的响应的情况下，所述响应的内容，或

-在所启动的定时器超时之前没有接收到所述响应的情况下，所述网关(600)已经知道的状态信息。

11.根据权利要求7所述的网关(600)，其中，所述存储器(620)包括当由所述处理器(610)执行时使得所述网关(600)执行以下操作的指令：

-存储在对所述第二请求的响应中接收的状态信息。

Images