CN108353094B - 用于m2m服务层的跨资源订阅 - Google Patents

Abstract

订户向资源主机发出用于请求订阅多个资源的消息。此消息可以指示这些资源的标识符，每个单独的资源均有事件通知准则，并且定义跨资源通知准则，诸如时间窗口类型和时间窗口大小。当在时间窗口内发生目标资源上的预期变化时，资源主机向订户或其指定的通知目标发出跨资源通知。

Description

用于M2M服务层的跨资源订阅

相关申请的交叉引用

本申请要求于2015年11月16日提交的标题为“Cross-Resource SubscriptionFor M2M Service Layer”的美国临时专利申请No.62/255,649的权益，在此其内容通过引用并入在本文。

背景技术

服务层

图1图示支持服务层100的示例性协议栈。如图1中所示，从协议栈角度看，服务层100可以位于应用协议层上方并且向应用或者向另一服务层提供增值服务。因此，服务层常常被分类为“中间件”服务。例如，图1示出IP网络栈与应用之间的示例性服务层。

M2M服务层是专门为M2M类型设备和应用提供增值服务的一种类型的服务层的示例。近来，若干行业标准组织(例如，oneM2M-TS-0001，oneM2M功能架构V2.3.0(在下文中被称为oneM2M))一直在开发M2M服务层以解决与将M2M类型设备和M2M类型应用集成到诸如因特网/Web、蜂窝、企业和家庭网络的部署中相关联的挑战。

M2M服务层可以提供应用和设备对由服务层支持的面向M2M的能力集合的访问。几个示例包括安全、计费、数据管理、设备管理、发现、提供和连接管理。这些能力经由利用如由M2M服务层所定义的消息格式、资源结构、资源表示和函数调用的应用编程接口(API)对应用可用。例如，M2M服务层可以维护大量的M2M数据，所述M2M数据可由M2M应用基于其访问权限来检索或者订阅。基于订阅的数据访问可能比基于检索的数据访问更高效，因为在所订阅的资源的期望变化发生之前它不会向M2M应用引入消息。

oneM2M服务层架构

oneM2M提供了解决对公共M2M服务层的需要的技术规范，所述公共M2M服务层可被容易地嵌入在各种硬件和软件内，并且可依靠其将现场中的各式各样的设备与全世界的M2M应用服务器连接。

如图2中所示，oneM2M公共服务层支持一组公共服务功能(CSF)(例如，服务能力)。一组一种或多种特定类型的CSF的实例化被称为可被托管在不同类型的网络节点(例如，基础设施节点(IN)、中间节点(MN)、应用服务节点(ASN))上的公共服务实体(CSE)。CSF向应用实体(AE)或其它CSE提供一组服务。

图3图示oneM2M功能架构：面向资源架构(ROA)。在ROA架构中，资源是在架构中具有可经由诸如Create、Retrieve、Update和Delete的RESTful方法操纵的表示的唯一可寻址元素。这些资源使用统一资源标识符(URI)成为可寻址的。资源可以包含也可以是唯一可寻址的子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其子资源的引用。子资源的使用寿命受父的资源使用寿命限制。每个资源支持存储该资源的信息的一组“属性”。

CSE(例如，CSE 109)可以注册到另一CSE(例如，CSE 111)。例如，M2M网关(例如，MN-CSE/CSE 109)将其自身注册到M2M服务器(例如，IN-CSE/CSE 111)并且M2M服务器成为M2M网关的注册者CSE。同样地，当IN-AE注册到IN-CSE时，IN-CSE被称为IN-AE的注册者CSE。CSE 111可以为注册的AE 103或AE 118创建<application>资源。

在图3中，应用实体(AE)101以及AE 118或AE 117和AE 103分别指代可以驻留在基础设施域107或场域(field domain)105中的不同的M2M应用。根据oneM2M-TS-0011-Definitions-Acronyms-V0.7.0，场域107“由M2M设备、M2M网关、传感与驱动(S&A)设备以及M2M区域网络构成”，然而基础设施域105“由应用基础设施和M2M服务基础设施构成”。AE101可经由Mca接口108访问和利用CSE 109中的CSF。此外，CSE 109提供一套CSF并且CSE109可经由Mcc接口110与另一CSE 111进行通信。CSE 109也可经由Mcn接口112从底层网络利用网络服务实体(NSE)113。

根据oneM2M功能架构基线，oneM2M参考点包括Mca 108、Mcc 110、Mcc'114和Mcn112。Mca参考点108(也被称为Mca接口)指定AE(例如，AE 101)与CSE(例如，CSE 109)之间的通信流。Mca参考点108允许AE 101使用由CSE 109提供的服务，并且用于CSE 109与AE 101进行通信。Mcc参考点110指定两个CSE(例如，CSE 109和CSE 111)之间的通信流。Mcc参考点110允许CSE 109使用CSE 111的服务以便提供所需功能。经由Mcc参考点110提供的服务依赖于由CSE 109和CSE 111支持的功能。

Mcc'参考点114指定oneM2M兼容并且驻留在不同的M2M SP域中的基础设施节点中的两个CSE之间的通信流。因此，它允许驻留在M2M服务提供商的网络域中的基础设施节点105的CSE 111与驻留在另一M2M服务提供商115的网络域中的另一基础设施节点(未示出)的CSE进行通信以使用其服务，并且反之亦然。Mcn参考点112指定CSE 109与底层NSE 113之间的通信流。Mcn参考点112允许CSE 109使用由底层NSE 113提供的服务(除传输和连接服务以外)以提供所需功能。

已经在oneM2M功能架构基线中定义了几个CSF，所述几个CSF包括注册(REG)CSF、应用和服务层管理(ASM)CSF、设备管理(DM)CSF、数据管理和储存库(DMR)CSF、通信和消息递送处理(CMDH)CSF、服务计费和计算(SCA)CSF等。例如，CSE(例如，M2M服务器)提供REGCSF，使得AE可首先将其自身注册到CSE，以便利用CSE提供的其它CSF。此架构允许多个AE独立地向同一CSE注册。在注册成功之后，CSE为每个AE创建单独的资源(例如，<application>资源)。常规oneM2M功能架构基线缺少用于支持不同应用之间关系的功能。

oneM2M订阅和通知CSF

oneM2M功能架构定义一组CSF，其可以由诸如M2M服务器的CSE提供给其它CSE或AE。所定义的CSF之一是订阅和通知(SUB)，所述SUB提供和跟踪资源上的变化(例如，资源的删除)的订阅有关的通知。

SUB CSF管理对资源的订阅，服从访问控制策略(ACP)，并且向资源订户想要接收它们的地址发送相应的通知。根据oneM2M，ACP应由CSE使用来控制对如oneM2M ROA架构中所规定的资源的访问。ACP被设计来适应不同的访问控制模型，诸如访问控制列表、基于角色的访问控制或基于属性的访问控制。<accessControlPolicy>资源被规定来支持各种ACP，其包括特权和selfPrivileges属性，所述特权和selfPrivileges属性表示定义哪些M2M实体具有在规定的上下文内执行某些操作的特权的一组访问控制规则，并且由CSE用于对具体资源作出访问决定。AE或CSE是订阅资源订户。AE和CSE订阅其它CSE的资源。订阅托管CSE在对资源作出修改时向由资源订户指定的地址发送通知。资源订阅的范围包括跟踪订阅资源的属性和直接子资源的变化和操作。它不包括跟踪子资源的属性的变化。每个订阅可以包括规定哪些通知被发送以及何时且如何发送的通知准则。这些通知准则可以与oneM2M的通信管理和递送处理(CMDH)策略相结合地工作。

订阅在CSE资源结构中被表示为资源<subscription>。

由SUB CSF支持的功能如下：

·每资源订阅请求包括资源订户ID、托管CSE-ID和订阅资源地址。它也可以包括其它准则(例如，感兴趣的资源修改和通知政策)以及要将通知发送到的地址。

·经由单个订阅来订阅单个资源或者在它们被分组并表示为单个组资源时经由单个订阅来订阅多个资源的能力。当订户对一组资源进行订阅时，相同的事件通知准则被用于该组中的所有资源；进而，每当单独的(非全部)资源的变化发生时托管CSE可以生成通知。

在oneM2M中，订户可能是AE或CSE，然而托管节点或转接节点必须是CSE。例如，作为订户的IN-AE可以对由IN-CSE(即，托管节点)托管的资源进行订阅。在另一示例中，MN-CSE具有作为订户的IN-AE想要订阅的一些资源；但是IN-AE的订阅请求必须通过其IN-CSE(即转接节点)以到达MN-CSE。

图4图示根据oneM2M规范的示例流程，其中订户132(例如，IN-AE)对托管CSE 131上的资源(例如，IN-CSE/<subscribed-to-resource>)进行订阅。为此，在步骤134处，订户132发出CREATE请求以在<subscribed-to-resource>下创建<subscription>资源。订户132可以在步骤134处指示eventNotificationCriteria和多个notificationURI。eventNotificationCriteria示出关于<subscribed-to-resource>的哪些事件是订户132感兴趣的。可将通知发送到如notificationURI所指示的订户132或通知目标(例如，针对订户132的notificationURI1和针对此示例中的另一通知目标的通知目标133的notificationURI2)。在步骤135处，作为托管CSE的托管CSE 131在步骤134处接收到订阅请求之后最初创建<subscription>作为<subscribed-to-resource>的子资源。在步骤136处，托管CSE 131可以提供订阅响应，所述订阅响应可以指示步骤134的订阅请求的成功或失败。在步骤137处，发生满足eventNotificationCriteria(例如，在步骤134中提供的准则)的事件。随后，当事件发生并满足eventNotificationCriteria时，托管CSE 131在步骤138和139处分别向由相应的notificationURI所指示的订户132和通知目标133自动地发送两个通知。如果步骤134中的notificationURI包含其URI，则通知目标133可以是订户自身。此外，步骤134的订阅请求可以包含多个通知URI，这意味着订户132正在请求要发送到多个通知目标的将来通知。在这种情况下，eventNotificationCriteria是相同的并且适用于所有notificationURI。尽管在图4中未示出，然而当使用pendingNotification(sendAllPending)时，oneM2M支持托管CSE 131执行批量通知。托管CSE 131可以在一个消息中向同一notificationURI发送多个通知。

发明内容

在M2M/IoT域中，订阅提供用于订户接收资源上的变化的自动通知的机制。常规M2M服务层(例如，oneM2M)针对每个请求原语支持订阅单个资源(被称为单个资源订阅)。然而，不支持在感兴趣的多个资源发生变化时生成通知(被称为跨资源订阅)。在单个请求中支持订阅多个资源(例如，目标资源)可能是更高效的。为了处理此问题，本公开公开了支持跨资源订阅的机制。

在示例中，订户向资源主机发出请求订阅多个资源的消息。资源主机具有在本地维护的所有这些资源。此消息可以指示这些资源的标识符，每个单独的资源均有事件通知准则，并且定义跨资源通知准则，诸如时间窗口类型和时间窗口大小。当在时间窗口内发生目标资源上的预期变化时，资源主机向订户或其指定的通知目标发出跨资源通知。

在另一示例中，订户可以向第一资源主机发出用于请求对多个资源的订阅的消息。第一资源主机可能不具有可以在第二资源主机、第三资源主机等中维护的所有这些资源。第一资源主机可以联系其它资源主机以订阅每个单个资源(目标资源)。第一资源主机可从其它资源主机接收单独的通知并且生成跨资源通知并将它发送到订户。新的资源和属性用于实现所提出的包括时间窗口机制的跨资源订阅解决方案。

本发明内容被提供来以简化形式引入对在下面在具体实施方式中进一步描述的构思的选择。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，它也不旨在限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中指出的任何或所有缺点的限制。

附图说明

图1图示支持服务层的示例性协议栈；

图2图示示例性公共服务实体(CSE)和公共服务功能(CSF)；

图3图示示例性oneM2M服务层功能架构(ROA)；

图4图示示例性oneM2M一般订阅和通知流程；

图5图示示例性智能建筑物场景；

图6图示示例性oneM2M订阅机制；

图7图示示例性基本跨资源订阅；

图8图示示例性高级跨资源订阅；

图9图示现有跨资源订阅的示例性更新；

图10图示现有跨资源订阅的示例性删除；

图11图示用于生成跨资源通知的周期性时间窗口机制的示例性流程图；

图12图示用于生成跨资源通知的滑动时间窗口机制的示例性流程图；

图13图示示例性时间窗口机制；

图14图示到oneM2M ROA中的示例性新增强订阅和通知(eSUB)CSF；

图15A图示oneM2M中的示例性跨资源订阅；

图15B图示oneM2M中的示例性跨资源订阅；

图15C图示oneM2M中的示例性跨资源订阅；

图16图示示例性常规资源结构，其中订阅是相关资源的子项；

图17图示用于跨资源订阅和通知系统的示例性资源结构；

图18图示用于订户(例如oneM2M AE)的示例性用户界面；

图19图示用于资源主机(例如oneM2M CSE)的示例性用户界面；

图20A是可以实现所公开的主题的示例机器到机器(M2M)或物联网(IoT)通信系统的系统图；

图20B是可以在图20A中图示的M2M/IoT通信系统内使用的示例架构的系统图；

图20C是可以在图20A中图示的通信系统内使用的示例M2M/IoT终端或网关设备的系统图；以及

图20D是可以具体实现图20A的通信系统的各方面的示例计算系统的框图。

具体实施方式

在常规oneM2M架构中，订户可仅对单个资源进行订阅并且一旦该单个资源存在预期变化就接收到自动通知(在本文中也被称为“单个资源订阅”或“单个资源通知”)。本文中所公开的是跨资源订阅和跨资源通知(有时可互换地使用)，其中订户对多个资源进行订阅并且通知条件基于对多个资源(在本文中被称为“目标资源”)的依赖性。如oneM2M中所定义的目标资源的示例是<container>资源。订户基于与目标资源相关联的匹配准则接收通知。

图5图示各种类型的传感器被部署用于监测诸如温度(例如，温度传感器147)和烟雾(例如，烟雾传感器148)的建筑物环境信息的智能建筑物场景。来自这些传感器的读数可以被存储在本地M2M网关144处。可以在台式计算机或智能电话上的M2M应用141不一定对每个单独的传感器读数感兴趣，而是想要在“温度高于25℃”并且“检测到烟雾”时接收到自动通知。这是本公开中的跨资源订阅的示例。跨资源订阅可以被认为是自动通知取决于两个或更多个资源而不是仅仅单个资源的订阅。换句话说，当发生多个资源的变化时会生成通知。在此示例中，自动通知取决于两个资源(例如，温度读数和烟雾读数—目标资源各一个)，而不是单个资源，并且被称为跨资源通知。在另一示例(在图5中未示出)中，当1)对第一资源执行检索操作并且2)在大致相同的时间对第二资源执行删除操作时，订户(例如，M2M应用141)可以订阅以得到通知。

如参考图5所描述的，来自传感器的读数可以被存储在本地M2M网关144处，所述本地M2M网关144可以被称为资源主机。作为订户的M2M应用141对M2M网关144处的资源进行订阅。因为oneM2M中的现有oneM2M资源订阅机制仅支持订阅单个资源或具有相同事件通知准则的一组资源(例如，在多个温度传感器指示华氏90度的温度之后通知)，所以M2M应用141按照惯例需要向M2M网关144进行两次单独的订阅(参见图6)。图6图示可以试图实现图5的用例的示例性常规oneM2M订阅机制。在步骤151处，M2M网关144接收关于温度传感器读数(例如，“温度高于25℃”)的订阅请求。在步骤152处，M2M网关144接收关于烟雾传感器读数(例如，“检测到烟雾”)的另一订阅请求。在步骤153处，M2M网关144确定在温度传感器上发生感兴趣事件，并且在步骤154处，随后关于该事件向M2M应用141发送通知。在步骤155处，M2M网关144确定在烟雾传感器上发生感兴趣事件，并且在步骤156处，随后关于该事件向M2M应用141发送通知。在步骤157，M2M应用141分析步骤154的通知和步骤156的通知以确定是否发生感兴趣事件(“温度高于25℃”并且“检测到烟雾”)。常规oneM2M系统的使用在M2M应用141处引入额外通知(例如，步骤154和步骤156)和开销(例如，更多处理)。每当温度传感器或烟雾传感器具有变化时M2M应用141将从M2M网关接收单独的通知；它然后依靠其自身的智能来确定是否发生了预期事件。关于常规组订阅，应该理解的是，oneM2M仅支持按相同的事件通知准则订阅所有组成员并且因此它不能支持此用例。例如可在具有两个成员(例如，温度传感器和烟雾传感器)的M2M网关144处创建<组>资源，但是M2M应用不能创建<组>/<订阅>资源(换句话说，针对组的订阅机制)以实现如本文中所讨论的用例(例如，“温度高于25℃”并且“检测到烟雾”)，因为它必须是相同类型的(例如，第一温度传感器和第二温度传感器高于25℃)。按照惯例，M2M应用141不能为每个成员资源指示不同的事件通知准则并且不能指示将如何基于现有oneM2M组订阅生成跨资源通知。

下面的是关于常规oneM2M订阅的多个问题的讨论。实现跨资源订阅和通知(如本文中所讨论的)的尝试可以引入从订户到资源主机的额外订阅请求消息。这些尝试也可以引入从资源主机到订户的额外通知消息。使用常规oneM2M的资源主机没有确定跨资源通知的能力。在订户处需要额外处理和开销。换句话说，订户首先需要维护关于单独的订阅之间的关系和依赖性的逻辑。然后它需要分析每个收到的单独的通知以确定是否发生真正感兴趣的事件。最后，如果单独的通知在传输过程中丢失了，则订户也许不能够知道已经在资源主机中发生了感兴趣事件。如果丢失传输被重传，则当与如本文中所讨论的跨资源订阅和通知相比时，经重传的消息可以向通信信道添加显著更多的消息。

在本文中关于跨资源订阅和跨资源通知所公开的是，订户可以订阅多个资源。通知条件基于对多个资源(被称为目标资源)的依赖性并且接收到的通知基于目标资源上的预期变化。

注意，订户一般地被假定为通知目标，但是可能不是。如果订户不是通知目标，则除了通知将被从资源主机发向具体通知目标而不是订户之外，本文中所描述的流程将是类似的。

在下面讨论的是用于基本跨资源订阅的流程。对于基本跨资源订阅，订户向资源主机发出请求对多个目标资源的订阅的单个消息。资源主机在本地维护这些目标资源。当目标资源在时间窗口内满足准则时，资源主机向订户(或所指定的通知目标)发出跨资源通知。

应理解的是，执行图7至图12中图示的步骤的实体是示例逻辑实体，所述示例逻辑实体可以被以存储在诸如图20C或图20D中图示的那些的设备、服务器或计算机系统的存储器中或者在该设备、服务器或计算机系统的处理器上执行的软件(例如，计算机可执行指令)的形式实现。也就是说，可以以存储在诸如图20C或图20D中图示的设备或计算机系统的计算设备的存储器中的软件(例如，计算机可执行指令)的形式实现图7至图12中图示的方法，当由计算设备的处理器执行所述计算机可执行指令时，执行图7至图12中图示的步骤。在示例中，利用下面关于M2M设备的交互的进一步细节，图35的AE 741可以驻留在图20A的M2M终端设备18上，然而图35的CSE 732和Sscl 742可以驻留在图20A的M2M网关设备14上。

图7图示用于基本跨资源订阅的示例性流程。M2M实体161是资源主机(例如，oneM2M IN-CSE)并且M2M实体162是订户(例如，oneM2M IN-AE)。在步骤164处，M2M实体162向M2M实体161发送请求消息。此请求消息是针对跨资源订阅，其向M2M实体161通知M2M实体162对多个资源(例如，目标资源)的变化感兴趣并且期望在满足准则时接收到单个通知。以下参数可以被包括在步骤164的消息中：listOfTargetResources、listOfEventNotificationCriteria、numOfTargetResourcesForNotification、timeWindowType和timeWindowSize。listOfTargetResources是M2M实体162感兴趣的多个目标资源(例如，目标资源的标识符)的列表。参见表1中的示例。listOfEventNotificationCriteria是针对目标资源的事件通知准则的列表。一个事件通知准则适用于listOfTargetResources中的每个资源。每个事件通知准则与如oneM2M中所定义的eventNotificationCriteria类似。如果所有目标资源具有相同的事件通知准则，则此参数仅包含适用于所有目标资源的一个事件通知准则。numOfTargetResourcesForNotification是M2M实体162期望在满足准则(例如，发生目标资源上的变化)的情况下接收到通知的目标资源的数目。默认情况下，此参数的值等于包括在listOfTargetResources中的目标资源的数目。在这种情况下，当发生目标资源上的变化并且满足准则时由M2M实体161生成通知。numOfTargetResourcesForNotification的值可以小于包括在listOfTargetResources中的目标资源的数目。在这种情况下，当发生目标资源上的变化并且满足准则时M2M实体162可以生成通知。timeWindowType指示M2M实体161可以使用来确定跨资源通知的时间窗口的类型(例如，周期性时间窗口或滑动时间窗口)。timeWindowSize是当在此时间窗口期间发生目标资源上的变化并且满足准则时向M2M实体161报警以向M2M实体162发送通知的时间窗口持续时间。在本文中对timeWindowType和timeWindowSize进行更详细的讨论。

表1：示例参数

继续参考步骤164，设想了如果M2M实体162具有对M2M实体161的先前建立的单独的订阅，则M2M实体162可以在步骤164中包括先前建立的单独的订阅的URI以请求跨资源订阅。此外，上面关于步骤164所描述的listOfEventNotificationCriteria到listOfTargetResources的映射具有其它映射选项，诸如用(targetResource,eventNotificationCriteria)元组的列表替换listOfEventNotificationCriteria和listOfTargetResources。另外，另一示例可能是用指配给单个事件通知准则的目标资源的列表，例如：(targetResource1,targetResource2,targetResource3,eventNotificationCriteria1)、(targetResource4,targetResource5,eventNotificationCriteria2)等替换listOfEventNotificationCriteria和listOfTargetResources。

在步骤165处，M2M实体161处理步骤164的跨资源订阅请求消息。如果M2M实体162不具有对目标资源(例如，完整的listOfTargetResources)的访问权限，则M2M实体161可以拒绝所接收到的跨资源订阅请求消息。如果请求被批准，则M2M实体161可以为M2M实体162创建listOfTargetResources、listOfEventNotificationCriteria、numOfTargetResourcesForNotification和timeWindow的记录。换句话说，如果来自M2M实体162的每个跨资源订阅请求被M2M实体161批准，则M2M实体161创建本地订阅资源以维护这个批准的跨资源请求。稍后在oneM2M的上下文中对关于这种资源结构的细节进行讨论。

在步骤166处，M2M实体161向M2M实体162发送响应。该响应可以包括在步骤165中创建的本地订阅资源的统一资源标识符(URI)以及步骤164的请求消息的成功的指示。在步骤167处，M2M实体161观察到目标资源上的事件发生。在步骤168处，M2M实体161执行时间窗口算法以确定它是否需要向M2M实体162发送通知。如关于步骤164所提及的，如果在通过参数timeWindowSize设计的时间窗口内发生所有或一些目标资源的变化(数目由参数numOfTargetResourcesForNotification规定)，则将生成通知。在作为资源主机的M2M实体161中实现的这种时间窗口机制使得能实现跨资源订阅的智能，否则如果使用了单个资源订阅，则跨资源订阅可以被强加于订户(例如，M2M实体162)。

继续参考图7的步骤168，公开了只有当在目标资源的数目(通过numOfTargetResourceForNotification来表示)上满足准则时才可以生成通知。这可以被认为是逻辑与操作。如在下面所讨论的其它更高级操作也可以由M2M实体161应用。在这种情况下，M2M实体162可以在步骤164中向M2M实体161请求并指示操作类型。如果任何目标资源在时间窗口内具有预期变化(例如，满足准则)，则M2M实体161生成跨资源通知。其它操作可以包括下列的：如果目标资源都在时间窗口内没有预期变化，则M2M实体161生成跨资源通知；如果目标资源的数目在时间窗口内具有预期变化并且目标资源的另一数目在同一时间窗口内没有预期变化，则M2M实体161生成跨资源通知；如果目标资源的数目连续地在几个时间窗口内具有预期变化，则M2M实体161生成跨资源通知；以及如果目标资源的数目连续地在几个时间窗口内没有预期变化，则M2M实体161生成跨资源通知。另一示例可以是listOfTargetResources和listOfEventNotificationCriteria两者是两个有序列表。所以，如果满足针对第一numOfTargetResourcesForNotification目标资源的事件通知准则，则M2M实体161生成跨资源通知；或者如果满足第一某个数目的事件通知准则，则M2M实体161生成跨资源通知。

在步骤169处，假定来自步骤168的判定为是，则M2M实体161向M2M实体162和通过通知URI规定的其它实体发送通知。

图8图示示例性高级跨资源订阅。图8是M2M实体162(例如，oneM2M IN-AE)仍然向M2M实体161(例如，oneM2M IN-CSE)进行跨资源订阅、但是M2M实体161不托管任何目标资源的场景。替代地，每个目标资源被托管在不同的M2M实体(例如，作为示例在图8中示出的M2M实体163和M2M实体160(例如，oneM2M MN-CSE))中。在类似于图7中的步骤164的步骤171处，图8中的M2M实体162向M2M实体161发送跨资源订阅请求消息。设想了M2M实体161可以具有M2M实体163和M2M实体160上的原始资源的地址，或者M2M实体162可以直接地发现其地址并且经由参数listOfTargetResources通知M2M实体161。

继续参考图8，在步骤172处，M2M实体161处理订阅请求。并且它发现步骤171中指示的目标资源未被托管在本地。结果，它需要联系其它资源主机。假定了步骤171包含对在M2M实体163和M2M实体160处维护的两个目标资源的请求。M2M实体162(订户)可以使用oneM2M中所定义的现有资源发现流程来发现在M2M实体163或M2M实体160处维护的本地资源。在此步骤171中，对于被M2M实体161批准的来自M2M实体162的每个跨资源订阅请求，M2M实体161可以创建本地订阅资源以维护已批准的跨资源请求。在本文中在oneM2M的上下文中对关于这种资源结构的细节进行更详细的讨论。

在步骤173处，M2M实体161向M2M实体163发送对单个目标资源的单个资源订阅请求(例如，如oneM2M中所定义的订阅请求)。针对此目标资源的事件通知准则来自步骤171。notificationURI可以是M2M实体161。在步骤171中，M2M实体161可以指示这个订阅是针对M2M实体162的跨资源订阅；或者M2M实体161可以不指示关于M2M实体162的跨资源订阅的任何信息。如果存在跨资源订阅的指示，则M2M实体161可以在这个消息中包括M2M实体162的标识符。

继续参考图8，在步骤174处，M2M实体163向M2M实体161发送响应。如果在步骤173中包括M2M实体162的标识符，则M2M实体163可以在M2M实体162上(或者与M2M实体161一起)执行授权并且基于授权结果向M2M实体161发送成功或失败的响应。否则，M2M实体163可以仅仅在M2M实体161上执行授权并且向它发送响应。在步骤175处，M2M实体161向M2M实体160发送对单个目标资源的单个资源订阅请求(例如，如oneM2M中所定义的订阅请求)。针对此目标资源的事件通知准则来自步骤161。notificationURI可以链接到M2M实体161。在步骤171中，M2M实体161可以指示这个订阅是针对M2M实体162的跨资源订阅；或者M2M实体161可以不指示关于M2M实体162的跨资源订阅的任何信息。如果存在跨资源订阅的指示，则M2M实体161可以在这个消息中包括M2M实体162的标识符。

在步骤176处，M2M实体160向M2M实体161发送响应。如果在步骤175中包括M2M实体162的标识符，则M2M实体160可以在M2M实体162上(或与M2M实体161一起)执行授权并且基于授权结果向M2M实体161发送成功或失败的响应。否则，M2M实体160可以仅仅在M2M实体161上执行授权并且向它发送响应。在步骤177处，M2M实体161向M2M实体162发送响应以指示步骤171的结果，这可能是成功或失败。在步骤178处，在M2M实体163处发生目标资源上的事件。在步骤179处，M2M实体163向M2M实体161发送通知。M2M实体161可以缓冲这个通知并且在稍后的时段(诸如在步骤182处)做附加处理。在步骤180处，在M2M实体160处发生目标资源上的事件。在步骤181处，M2M实体160向M2M实体161发送通知。M2M实体161可以为步骤182中的稍后处理缓冲这个通知。假定了步骤179和步骤181的通知响应于与满足的准则匹配的步骤178和步骤180的事件。准则可以在步骤171中被最初提供给M2M实体161，然后随后被单独地分发给M2M实体，诸如M2M实体160和M2M实体163。在类似于图7中的步骤165的步骤182处，图8的M2M实体161执行时间窗口机制以确定是否应向M2M实体162发送通知。如果在如步骤171中所规定的已指定的时间窗口期间接收到来自步骤179和步骤181的通知，则M2M实体161生成通知并且将该通知发送到M2M实体162(步骤183)。在本文中对关于时间窗口机制的细节进行讨论。在步骤183处，M2M实体161将通知发送到M2M实体162。步骤183的通知消息可以包含在步骤178和180中发生的事件。或者步骤183的通知消息可以只是用于基于应用相关的但是由M2M实体161确定的预配置规则触发动作的指示。例如，M2M实体162可以向传感器发送命令(或者接收命令)以打开水。步骤183中的通知可以与火灾事件的检测相关联。

在下面对关于图8的一些附加考虑事项进行讨论。在图8中，可能存在单个资源订阅请求(例如，步骤173或步骤175)失败的实例。在这种情况下，来自M2M实体162的跨资源订阅也将失败，其可以被包含在步骤177的响应消息中。如果步骤173首先失败，则M2M实体161可以不联系M2M实体160而是替代地向M2M实体162发送失败响应。如果步骤173成功，但是步骤175不成功，则M2M实体161可以向M2M实体162发送失败响应(例如，在步骤177中)。此外，在步骤173和174处创建的与M2M实体163相关联的订阅可以是无效的(例如，删除)。如果步骤173和步骤175两者均成功，但是M2M实体163(或M2M实体160)处的目标资源稍后变得不可用或者现有订阅变得无效，则M2M实体161可以移除其在本地创建的针对M2M实体162的跨资源订阅并且发送失败响应。此外，M2M实体161可以使对其它资源主机(例如，M2M实体160)的现有单个资源订阅无效。

继续参考图8，另一考虑事项是关于步骤172。在步骤172中，M2M实体161可以出于任何数目的原因而拒绝M2M实体162的跨资源订阅请求。一个原因可以是请求会将处理或存储器增加至特定阈值以上。另一原因可以是不能满足特定服务质量。一般地这些原因可以是请求不符合特定准则，所述原因可以包括太复杂或不能/不太可能在特定时间窗口内适合。结果，可跳过步骤173-步骤176(并且步骤178-步骤183不会发生)。M2M实体161可以仅仅使用步骤177来向M2M实体162发送包括失败的通知的响应消息。

图9图示用于更新现有跨资源订阅的示例性消息流。现有跨资源订阅可以由原始订户(或其它合格的实体)更新。例如，可移除目标资源或可添加新目标资源。另外，可改变事件通知准则或时间窗口大小。在步骤191处，作为原始订户的M2M实体162向M2M实体161发送用于跨资源订阅的更新消息，以便更新根据图7或图8中的流程而创建的现有跨资源订阅的属性，例如。步骤191的更新消息可以包括以下参数：subscriptionID、listofTargetResource、eventNotificationCriteria、numOfTargetResourcesForNotification、timeWindowType或timeWindowSize。subscriptionID可以被认为是将被更新的现有跨资源订阅的URI。listOfTargetResource可以被认为是所有新目标资源的列表。listOfTargetResource也可以简单地指示要删除的现有目标资源或要附加的新目标资源。eventNotificationCriteria可以被认为是新事件通知准则。如果存在要添加的任何新的目标资源，则eventNotificationCriteria指示针对这些新目标资源的通知准则。numOfTargetResourcesForNotification可以被认为是用于生成通知的所需目标资源的新数目。timeWindowType是新时间窗口类型。timeWindowSize可以被认为是用于确定通知的时间窗口的新大小。

在步骤192处，M2M实体161使用subscriptionID来查找现有跨资源订阅并且根据步骤191中包括的参数来更新其属性。如果timeWindowType或timeWindowSize被请求改变，则M2M实体161将重置当前时间窗口同时忽略现有事件并且重新启动新时间窗口。如果numOfTargetResourcesForNotification被改变，则M2M实体161可以保持当前时间窗口，但是可以较早(例如，numOfTargetResourcesForNotification被减少)或更晚(例如，numOfTargetResourcesForNotification被增加)生成跨资源通知。

继续参考图9，在步骤193处，M2M实体161可以联系在已更新的跨资源订阅中涉及的一些目标资源驻留的其它资源主机(例如，M2M实体163)。如果M2M实体162请求更新驻留在M2M实体163处的目标资源上的事件通知准则，则M2M实体161可向M2M实体163通知新事件通知准则。如果M2M实体162请求从listOfTargetResouce中移除目标资源并且目标资源位于M2M实体163处，则M2M实体161将联系M2M实体163以删除先前创建的与此目标资源相关联的单个资源订阅。如果M2M实体162请求将新目标资源添加到listOfTargetResource并且此目标资源位于M2M实体163处，则M2M实体161可以联系M2M实体163以在M2M实体163处创建新单个资源订阅。在步骤194处，M2M实体161关于步骤192和步骤193中的更新操作结果向M2M实体162发送响应，诸如指示成功或失败的信息等。

图10图示用于更新现有跨资源订阅的示例性消息流。现有跨资源订阅可以由原始订户(或其它合格的实体)删除。例如，在步骤201处，M2M实体162(例如，原始订户)向M2M实体161发送用于删除根据图7或图8中的流程而创建的现有跨资源订阅的消息。步骤201的此删除消息可以包括subscriptionID，所述subscriptionID可以是将被删除的现有跨资源订阅的URI。在步骤202处，M2M实体161使用subscriptionID来查找要删除的现有跨资源订阅。在步骤203处，M2M实体161可以联系在已删除的跨资源订阅中涉及的一些目标资源驻留的其它资源主机(例如，M2M实体163)，以删除与已删除的跨资源订阅相关联的现有单个资源订阅。在步骤204处，M2M实体161关于步骤202和步骤203中的删除操作结果向M2M实体162发送响应，诸如指示成功或失败的信息等。

在下面讨论的是在确定是否发送跨资源通知时使用的时间窗口机制。在每个跨资源订阅中，涉及多个目标资源并且每个目标资源的事件可以在不同的时间发生。结果，资源主机(例如，M2M实体161)可以根据由原始订户指示的参数timeWindowSize来确定它是否需要向原始订户发出通知。在本文中对时间窗口机制“周期性时间窗口”和“滑动时间窗口”进行讨论。关于周期性时间窗口，时间被划分成具有相同大小的时间窗口。对于每个时间窗口，资源主机在目标资源在时间窗口内满足准则时发出通知。关于滑动时间窗口，每次在生成跨资源通知或目前时间窗口期满之后，时间窗口的开始时间动态地改变。资源主机使用类似的逻辑来发出通知(例如，只有当在时间窗口中发生目标资源的预期事件时)。

注意，可将timeWindowSize设定为零。为了实现具有零值的这种时间窗口，当所指定的事件条件中的一个被触发时，资源主机必须检查是否也满足其它事件通知准则。如果基本上同时地满足条件则发送通知。例如，如果订户在{“event1：(temperature>25)”并且“event2：(smokeSensor＝'Detected')”}发生时想要通知，则订户可以规定零时间窗口以暗示两个事件必须同时发生。

图11图示用于周期性时间窗口的示例性方法。在步骤211处，资源主机(例如，M2M实体161或M2M实体160)创建时间窗口(tWin)和可能为空的事件列表(eList)。在步骤212处，M2M实体161等待目标资源的下一个事件或时间窗口(tWin)的期满。在步骤213处，如果发生目标资源上的新事件，则移动到步骤214；否则如果时间窗口期满则移动到步骤215。在步骤214处，M2M实体161可以将此事件缓冲到eList。在步骤215处，M2M实体161检查eList是否包含目标资源的预期事件(即，满足准则)。如果是，则移动到步骤216；否则，转向步骤217。在步骤216处，M2M实体161可以生成通知并且将它发送到目标，诸如通过notificationURI表示的目标。在步骤217处，M2M实体161移除时间窗口(tWin)并且通过移除所有缓冲的事件来清空eList。在步骤218处，M2M实体161创建新时间窗口并且将其开始时间设定为当前时间。应该理解的是，资源主机不必等到时间窗口的结束才发送通知。一旦在时间窗口内满足准则，资源主机就发送通知。例如，可以在图13的tWin 252中的t14处发送通知。

图12图示用于滑动时间窗口的示例性方法。在步骤220处，资源主机(例如，M2M实体161或M2M实体163)等待目标资源上的下一个事件或发起的时间窗口(tWin)的期满。在步骤220之后，在步骤221处，如果发生目标资源的新事件，则移动到步骤225，所述步骤225是关于在资源上发生的事件的块244的开始；否则如果时间窗口期满则移动到步骤222。步骤222是关于时间窗口期满的步骤的块241的开头。

在块241内，在步骤222处，M2M实体161检查有多少事件被包括在eList中。如果存在多于1个事件(是)，则移动到步骤223；否则(否)，移动到步骤235。在步骤223处，M2M实体161根据缓冲事件列表(例如，eList)的列表中的第二事件来滑动当前时间窗口。换句话说，时间窗口的开始时间将被更新为第二事件的发生时间。注意，如果eList包含仅一个事件，则资源主机只简单地移除当前时间窗口。例如，在图13中，图示270中的指代“滑动时间窗口”的tWin 273具有在时间t4处发生的仅一个事件(事件资源类型281)。在时间t5处，因为存在仅一个事件，所以tWin 273期满并且eList和时间将被重置。然后，当发生新事件(事件资源类型282)时，将在时间t6处重新启动新时间窗口(例如，tWin 274)。如果所有目标资源在时间窗口内不与准则匹配，则也可能发生重置。在步骤2247处，eList中的第一事件将被移除。现在，第二事件变成eList中的第一事件。然后步骤220是下一个步骤。

在步骤225处，M2M实体161检查是否存在已经创建的时间窗口。如果否，则移动到步骤226；否则，如果时间窗口存在则移动到步骤228。在步骤226处，M2M实体161创建将其开始时间设定为当前时间的时间窗口(在本文中被称为tWin)，其开始时间可以大致是接收与预定准则匹配的事件的指示的时间。在步骤227处，M2M实体161创建事件列表(被称为eList)并且将此事件作为第一事件插入到该列表。在eList被创建之后然后可以发生步骤220。在步骤228处，存在已经创建的eList。资源主机将此事件附加到eList的末尾。在步骤229处，M2M实体161检查此事件是否是目标资源的第一事件。如果否，则移动到步骤230；否则，如果是，则移动到步骤233。在步骤230处，从eList中移除相同目标资源的较旧事件。在步骤231处，资源主机检查已移除的较旧事件是否是eList中的第一事件。如果步骤231为是，则移动到步骤232；否则，转向步骤220。在步骤232处，M2M实体161可以根据已更新的eList来滑动时间窗口。换句话说，时间窗口的开始时间被设定为已更新的eList中的第一事件的发生时间。在步骤233处，M2M实体161检查eList是否包含目标资源的预期事件。如果是，则移动到步骤234；否则，转向步骤220。在步骤234处，M2M实体161生成通知并且将它发送到如通过notificationURI表示的通知目标。在步骤235处，M2M实体161移除时间窗口和eList，然后转向步骤220。

图13图示用于周期性时间窗口和滑动时间窗口的示例。在此示例中，假定了存在两个目标资源：事件资源类型281和事件资源类型282。所示出的事件资源类型指示一个目标资源在一时间实例(例如，t11、t12、t13、t14、t15)处满足至少一个判据(criterion)。周期性时间窗口是新时间窗口的开始时间通常在固定时间实例或时段处出现的时间窗口机制。如图13中所示，关于图示250(周期性时间窗口)，创建了三个连续的时间窗口(例如，tWin 251、tWin 252和tWin 253)，但是仅tWin 252和tWin 253包含两个资源的事件。结果，在tWin251中没有通知，但是将为tWin252和tWin253生成通知。换句话说，tWin251是没有基于不满足目标资源的准则的触发通知的时间窗口，然而tWin252和tWin 253是具有基于满足目标资源的准则的触发通知的时间窗口。如图13中所示，关于图示270(滑动时间窗口)，生成了四个时间窗口(例如，tWin 271、tWin 272、tWin 273和tWin 274)。注意，每个时间窗口实际上是通过在时间实例(例如，t1、t2、t3、t4、t6、t7)处发生与针对目标资源的判据匹配的事件来发起的。图示270示出了tWin 272和tWin 274包含满足每个目标资源的预定准则的事件并且将生成通知。这里假定了在图13中事件资源类型281和事件资源类型282是触发通知所需的唯一目标资源。

下面的是用于在oneM2M架构中实现跨资源订阅的示例。在下面讨论的是高级架构选项、新资源和属性及对应的呼叫流程。另外关于跨资源订阅相关参数和信息的示例性显示或配置对用户界面进行讨论。

关于oneM2M，可以在CSE(例如，图20A的M2M服务层22)中实现与资源主机(例如，M2M实体161)有关的流程和过程。以及与AE(或如果它是订户则为CSE)中的订户(例如，图8中的M2M实体162)有关的流程和过程。

图14图示关于对现有SUB CSF的跨资源订阅或通知实现所公开的以基于oneM2M形成增强订阅和通知(eSUB)CSF 292的示例。这个新eSUB 292支持与如本文中所描述的资源主机有关的程序和过程。eSUB 292可以驻留在IN-CSE、MN-CSE或ASN-CSE中。

图15图示oneM2M中的跨资源订阅的三个示例性部署。图15A图示订户作为AE(例如，IN-AE、MN-AE、ASN-AE或ADN-AE)同时资源主机是具有eSUB的主机CSE的示例。本文中所讨论的流程被应用于托管CSE 294(资源主机)与AE 296(订户)之间的Mca参考点295。所提出的新资源<xRsrcSub>将驻留在具有eSub(例如，IN-CSE、MN-CSE或ASN-CSE)的托管CSE中。图15B图示订户作为CSE 299(例如，MN-CSE、IN-CSE)同时资源主机是具有eSUB的托管CSE297的示例。本文中所讨论的流程被应用于托管CSE 297与作为订户的CSE299之间的Mcc/Mcc的参考点298。所公开的新资源<xRsrcSub>将驻留在具有eSub的托管CSE(例如，IN-CSE)中。图15C图示订户作为AE(例如，IN-AE)同时其目标资源分布在三个CSE(例如，具有eSUB的托管CSE 303、MN-CSE 305和MN-CSE 307)中的示例。本文中所讨论的流程被应用于具有eSUB的托管CSE与订户AE 301之间的Mca参考点302。在这种情况下，MN-CSE 305和MN-CSE307不支持eSUB，但是仅具有oneM2M中的现有SUB功能。所公开的新资源<xRsrcSub>将驻留在具有eSub的托管CSE 303(例如IN-CSE)中。

为了支持关于图7至图10的流程，例如，在本文中针对oneM2M对新订阅资源(被称为<xRsrcSub>)进行讨论。<xRsrcSub>除了具有eventNotificationCriteria和如表1中所示的几个新属性之外还可以具有现有<subscription>资源的所有子资源和属性(例如，notificationURI)。表1是新属性的示例。因为目标资源通过专用属性listOfTargetResources来表示，所以在<sclBase>资源树下创建<xRsrcSub>的位置并不重要。图17图示如本文中所讨论的跨资源订阅和通知系统的效果的示例。基本上，<xRsrcSub>可以被放置在与oneM2M架构中的常规<subscription>资源不同的各种地方(例如，<AE>的子资源、<CSE>的子资源、<CSEBase>的子资源或<group>的子资源)中。图16图示常规资源结构的示例，其中订阅是相关资源的子项。

表1：新<xRsrcSub>资源的新属性

可以使用<xRsrcSub>资源流程来请求创建针对由listOfTargetResources表示的多个目标资源的修改要通知的新<xRsrcSub>资源。在oneM2M(oneM2M-TS-0001，oneM2M功能架构V-2.3.0—在下文中[1])中的条款10.1.1.1中描述了通用创建流程。表2图示示例性<xRsrcSub>CREATE。

表2：<xRsrcSub>CREATE

这些流程可以用于检索<xRsrcSub>资源的属性和子资源信息。在[1]中的条款10.1.2中对通用检索流程进行了描述。表3是示例性<xRsrcSub>RETRIEVE。

表3：<xRsrcSub>RETRIEVE

这些流程可以用于来更新现有跨资源订阅(例如，<xRsrcSub>资源)，例如，诸如listOfTargetResources的其属性的修改。在[1]中的条款10.1.3中对通用更新程序进行了描述。表4是示例性<xRsrcSub>UPDATE。

表4：<xRsrcSub>UPDATE

这些流程可以用于取消订阅现有跨资源订阅(即，<xRsrcSub>资源)。在[1]中的条款10.1.4.1中对通用删除流程进行了描述。表5是<xRsrcSub>DELETE的示例。

表5：<xRsrcSub>DELETE

在托管CSE收到<xRsrcSub>创建(或<xRsrcSub>更新)之后，它执行如本文中所描述的时间窗口机制以确定是否需要发出通知。只有当在时间窗口内发生目标资源上的预期变化时，托管CSE才向始发者或其指定的通知接收者发出通知。

例如，可以通过添加如表6中所描述的几个新属性来扩展oneM2M中的常规<subscription>资源以支持所公开的跨资源订阅。换句话说，通过使用这些新属性，订户(例如，创建者或<subscription>)可以触发或者启用跨资源订阅。在示例中，假定IN-CSE具有有两个成员<container1>和<container2>的<group>资源(例如，<inCSEBase>/<group>)。如果IN-AE想要在两个容器资源的值超过阈值时接收自动通知，则它可以创建<subscription>作为此<group>资源的子资源并且使用下面的CREATE命令来为新属性设定适当的值。然后如果两个容器资源的值被改变为在timeWindowSize(例如，60秒)内超过阈值，则IN-CSE发出通知。示例CREATE命令：CREATE<inCSEBase>/<group>/<subscription>；净荷：subType＝1(跨资源订阅)、timeWindowType＝1(例如，周期性时间窗口)、timeWindowSize＝60秒。

表6：<subscription>资源的新属性

利用<subscription>资源的所提出的新属性，可以更新用于在oneM2M中创建<subscription>的流程。但是用于检索<subscription>、更新<subscription>和删除<subscription>的流程可以与oneM2M[1]中的现有流程相同。

创建<subscription>

应使用此流程来请求创建针对跨越多个目标资源的修改要通知的新<subscription>资源。在[1]中的条款10.1.1.1中对通用创建流程进行了描述。

表7：修改的<subscription>CREATE

在托管CSE接收到<subscription>创建之后，它执行如本文中所描述的时间窗口机制以确定是否需要发出通知。只有当在时间窗口内发生目标资源上的预期变化时，托管CSE才向始发者或其指定的通知接收者发出通知。

用户界面可以与订户(例如，AE)交互以配置或者显示跨资源订阅的参数，诸如目标资源的列表、事件通知准则的列表和时间窗口大小(参见图18)。图19图示可以基于本文中所讨论的方法和系统生成的示例性显示(例如，图形用户界面)。参考图19，对于资源主机，用户界面321除了显示块322的跨资源订阅参数之外还可以显示目标资源的发生事件信息323(例如，大致实时地)。显示界面321(例如，触摸屏显示器)可以在块322中提供与跨资源订阅相关联的其它文本，诸如表1至表7的参数。在另一示例中，本文中所讨论的步骤中的任一个的进展(例如，发送了消息或者图7至图12的步骤的成功)可以通过显示321来显示。此外，可以在显示界面321上显示图形输出324。图形输出324可以是设备的拓扑、本文中所讨论的任何方法或系统的进展的图形输出等。

图20A是可以实现与跨资源订阅相关联的一个或多个公开的构思(例如，图7至图19和伴随讨论)的示例机器到机器(M2M)、物联网(IoT)或万维物联网(WoT)通信系统10的图。一般地，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关或M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等的组件。

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

如图20A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域。基础设施域指代端到端M2M部署的网络侧，而场域指代通常在M2M网关后面的区域网络。场域包括M2M网关14和终端设备18。应了解的是，可以视需要在M2M/IoT/WoT通信系统10中包括任何数目的M2M网关设备14和M2M终端设备18。M2M网关设备14和M2M终端设备18中的每一个被配置成经由通信网络12或直接无线电链路发送和接收信号。M2M网关设备14允许无线M2M设备(例如蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过运营商网络(诸如通信网络12或直接无线电链路)来通信。例如，M2M设备18可以收集数据并且经由通信网络12或直接无线电链路将该数据发送到M2M应用20或M2M设备18。M2M设备18也可以从M2M应用20或M2M设备18接收数据。另外，如下所述，可以经由M2M服务层22向M2M应用20发送数据和信号并且从M2M应用20接收数据和信号。M2M设备18和网关14可以经由包括例如蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路的各种网络来通信。

参考图20B，在场域中图示的M2M服务层22(例如，如本文中所描述的托管CSE 294)为M2M应用20、M2M网关设备14和M2M终端设备18及通信网络提供服务。应理解的是，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’可以由一个或多个服务器、计算机、虚拟机(例如，云/计算/存储农场等)或类似物实现。

还参考图20B，M2M服务层22和22’提供各种应用和垂直领域可利用的服务递送能力的核心集合。这些服务能力使得M2M应用20和20’能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全、计费、服务/设备发现等的功能。实质上，这些服务能力使应用摆脱实现这些功能的负担，从而简化应用开发并且减少成本和上市时间。服务层22和22’也使得M2M应用20和20’能够连同服务层22和22’提供的服务一起通过各种网络12和12’来通信。

在一些示例中，如本文中所讨论的，M2M应用20和20’可以包括使用与跨资源订阅相关联的方法来通信的期望应用。M2M应用20和20’可以包括诸如但不限于交通、健康和保健、连接家庭、能源管理、资产跟踪以及安全和监视的各种行业中的应用。如上面所提及的，跨越系统的设备、网关和其它服务器运行的M2M服务层支持诸如例如数据收集、设备管理、安全、计费、定位跟踪/地理围栏、设备/服务发现和传统系统集成的功能，并且将这些功能作为服务提供给M2M应用20和20’。

与本申请的跨资源订阅相关联的系统可以作为服务层的一部分被实现。服务层(例如，托管CSE 294)是通过一组应用编程接口(API)和底层联网接口来支持增值服务能力的软件中间件层。M2M实体(例如，诸如可以通过硬件和软件的组合来实现的设备、网关或服务/平台的M2M功能实体)可以提供应用或服务。ETSI M2M和oneM2M两者都使用可以包含与本申请的跨资源订阅相关联的方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以被实现在M2M设备(其中它被称为设备SCL(DSCL))、网关(其中它被称为网关SCL(GSCL))或网络节点(其中它被称为网络SCL(NSCL))内。oneM2M服务层支持一组公共服务功能(CSF)(即服务能力)。一组一种或多种特定类型的CSF的实例化被称为公共服务实体(CSE)，其可以被托管在不同类型的网络节点(例如，基础设施节点、中间节点、应用特定节点)上。另外，与本申请的跨资源订阅相关联的系统可以作为使用面向服务架构(SOA)或面向资源架构(ROA)来访问诸如与本申请的跨资源订阅相关联的系统的服务的M2M网络的一部分来实现。

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

图20C是诸如例如M2M终端设备18或M2M网关设备14的示例M2M设备30的系统图。如图20C中所示，M2M设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、键区40、显示器/触摸板42、不可移除存储器44、可移除存储器46、电源48、全球定位系统(GPS)芯片组50以及其它外围设备52。应了解的是，M2M设备30可以包括前述元件的任何子组合，同时保持与所公开的主题一致。M2M设备30(例如，M2M实体161、M2M实体160、M2M实体163、M2M实体162、托管CSE 294、AE 296、MN-CSE 305等)可以是执行所公开的用于跨资源订阅的系统和方法的示例性实施方式。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理，或使得M2M设备30能够在无线环境中操作的任何其它功能。处理器32可以耦合到收发器34，所述收发器34可以耦合到发送/接收元件36。虽然图20C将处理器32和收发器34描绘为单独的组件，但是应了解的是，处理器32和收发器34可以被一起集成在电子封装或芯片中。处理器32可以执行应用层程序(例如，浏览器)或无线电接入层(RAN)程序或通信。处理器32可以诸如例如在接入层或应用层处执行诸如认证、安全密钥协定或密码操作的安全操作。

发送/接收元件36可以被配置成向M2M服务平台22发送信号或者从M2M服务平台22接收信号。例如，发送/接收元件36可以是被配置成发送或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在示例中，例如，发送/接收元件36可以是被配置成发送或接收IR、UV或可见光信号的发射器/检测器。在又一个示例中，发送/接收元件36可以被配置成发送和接收RF和光信号。应了解的是，发送/接收元件36可以被配置成发送或接收无线或有线信号的任何组合。

此外，尽管发送/接收元件36在图20C中被描绘为单个元件，然而M2M设备30可以包括任何数目的发送/接收元件36。更具体地，M2M设备30可以采用MIMO技术。因此，在示例中，M2M设备30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置成对将由发送/接收元件36发送的信号进行调制并且对由发送/接收元件36接收的信号进行解调。如上面所指出的，M2M设备30可以具有多模能力。因此，例如，收发器34可以包括例如用于使得M2M设备30能够经由多个RAT(诸如UTRA和IEEE802.11)通信的多个收发器。

处理器32可以从诸如不可移除存储器44或可移除存储器46的任何类型的适合的存储器访问信息并且将数据存储在该适合的存储器中。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其它类型的存储器存储设备。可移除存储器46可以包括订户标识模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它示例中，处理器32可以从物理上不位于M2M设备30上(诸如在服务器或家庭计算机上)的存储器访问信息并且将数据存储在该存储器中。处理器32可以被配置成响应于本文中所描述的一些示例中的跨资源订阅是成功还是不成功(例如，订阅设置、接收到的通知、更新的时间窗口等)而控制显示器或指示器42上的照明图案、图像或颜色，或者以其它方式指示跨资源订阅和关联组件的状态。显示器或指示器42上的控制照明图案、图像或颜色可以反映本文中所图示或讨论的这些图(例如，图7至图19等)中的方法流程或组件中的任一个的状态。本文中所公开的是跨资源订阅的消息和流程。可以扩展这些消息和流程以为用户提供界面/API来经由输入源(例如，扬声器/麦克风38、键区40或显示器/触摸板42)请求相关资源并且请求、配置或者查询资源的跨资源订阅信息以及可以在显示器42上显示的其它事物。

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

处理器32也可以耦合到GPS芯片组50，所述GPS芯片组50被配置成提供有关M2M设备30的当前定位的定位信息(例如，经度和纬度)。应了解的是，M2M设备30可以通过任何适合的定位确定方法来获取定位信息，同时保持与本文中所公开的信息一致。

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

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

发送/接收元件36可以被具体实现在其它装置或设备中，所述其它装置或设备诸如传感器、消费电子产品、诸如智能手表或智能服装的可穿戴设备、医疗或eHealth设备、机器人、工业设备、无人机、诸如汽车、卡车、火车或飞机的交通工具。发送/接收元件36可以经由一个或多个互连接口(诸如可以包括这些外围设备52中的一个的互连接口)连接到此类装置或设备的其它组件、模块或系统。

图20D是例如可以实现图20A和图20B的M2M服务平台22的示例性计算系统90的框图。计算系统90(例如，M2M终端设备18或M2M网关设备14)可以包括计算机或服务器，并且可以主要通过计算机可读指令来控制，所述计算机可读指令可以是软件的形式，可以在任何地方或以任何手段来存储或者访问这种软件。可以在中央处理单元(CPU)91内执行此类计算机可读指令以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称作微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或者协助CPU 91。CPU 91或协处理器81可以接收、生成和处理与所公开的用于跨资源订阅的系统和方法有关的数据，诸如基于满足与多个目标资源相关联的一个或多个判据生成通知。

在操作中，CPU91经由计算机的主数据转移路径(系统总线80)对指令进行预取、解码和执行，并且转移到其它资源和来自其它资源的信息。这种系统总线连接计算系统90中的组件并且定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断并且用于操作系统总线的控制线。这种系统总线80的示例是PCI(外围组件互连)总线。

耦合到系统总线80的存储器设备包括随机存取存储器(RAM)82和只读存储器(ROM)93。此类存储器包括允许信息被存储和检索的电路。ROM 93一般地包含不能被容易地修改的存储的数据。存储在RAM 82中的数据可被CPU 91或其它硬件设备读取或者改变。对RAM82或ROM 93的访问可以由存储器控制器92控制。存储器控制器92可以提供当指令被执行时将虚拟地址转换成物理地址的地址转换功能。存储器控制器92也可以提供使系统内的进程隔离并且使系统进程与用户进程隔离的存储器保护功能。因此，在第一模式下运行的程序可仅访问通过其自身的进程虚拟地址空间映射的存储器；它不能访问另一进程的虚拟地址空间内的存储器，除非已经建立了这些进程之间的存储器共享。

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

由显示控制器96控制的显示器86用于显示由计算系统90生成的可视输出。这种可视输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸板来实现。显示控制器96包括生成被发送到显示器86的视频信号所需要的电子组件。

另外，计算系统90可以包含网络适配器97，所述网络适配器97可以用于将计算系统90连接到外部通信网络，诸如图20A和图20B的网络12。

应理解的是，可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来实现本文中所描述的系统、方法和过程中的任一个或全部，当有机器(诸如计算机、服务器、M2M终端设备、M2M网关设备等)执行时，所述指令执行或者实现本文中所描述的系统、方法和过程。具体地，可以以此类计算机可执行指令的形式实现上述的步骤、操作或功能中的任一个。计算机可读存储介质包括用任何方法或技术实现以便存储信息的易失性和非易失性、可移除和不可移除介质，但是此类计算机可读存储介质不包括信号。如从本文描述中显而易见的，存储介质应该被解释为在美国法典第35条第101节(35U.S.C§101)下的法定主题。计算机可读存储介质包括RAM、ROM、EEPROM、闪速存储器或其它存储器技术、CD-ROM、数字通用盘(DVD)或其它光盘存储器、磁盒、磁带、磁盘存储器或其它磁存储设备，或可用于存储所期望的信息并且可被计算机访问的任何其它物理介质。

在描述如图中所图示的本公开的主题的优选方法、系统或装置—用于跨资源订阅的系统和方法时，为了清楚起见采用了特定术语。然而，所要求保护的主题不旨在限于如此选择的特定术语，并且应当理解的是，每个特定元件包括以类似的方式操作以实现类似的目的的所有技术等同物。

本文中所描述的各种技术可以连同硬件、固件、软件或者(在适当的情况下)其组合一起来实现。这种硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置中。装置可以单独或者彼此相结合地操作以实现本文中所描述的方法。如本文中所使用的，术语“装置”、“网络装置”、“节点”、“设备”、“网络节点”等可以互换地使用。此外，除非在本文中另外规定，否则单词“或”的使用一般是包括性地使用。

本撰写的说明书使用示例来公开本发明，包括最佳模式，并且也使得本领域的技术人员能够实践本发明，包括制造并使用任何设备或系统以及执行任何并入的方法。本发明的可取得专利的范围由权利要求限定，并且可以包括被本领域的技术人员想到的其它示例(例如，跳过步骤、组合步骤或者在本文中所公开的示例性方法之间添加步骤)。如果此类其它示例具有不与权利要求的字面语言不同的结构元素，或者如果它们包括与权利要求的字面语言无实质差异的等同结构元素，则此类其它示例意欲处于权利要求的范围内。

如本文中所描述的方法、系统和装置等可以提供用于跨资源订阅的手段。方法、系统、计算机可读存储介质或装置具有用于接收跨资源订阅的消息的手段，其中消息指示远程设备对要通知的在时间窗口内满足准则的多个目标资源的变化的订阅的请求；确定远程设备被批准用于跨资源订阅；以及生成本地订阅资源以维护跨资源订阅。该方法、系统、计算机可读存储介质或装置具有用于发送包括跨资源订阅的批准的指示的响应消息的手段。该方法、系统、计算机可读存储介质或装置具有用于请求订阅多个目标资源中的第一资源的手段，其中请求包括准则的判据。该方法、系统、计算机可读存储介质或装置具有用于接收满足准则的判据的通知的手段；基于接收到通知确定满足准则；以及基于确定满足准则通知远程设备。该方法、系统、计算机可读存储介质或装置具有用于向显示器发布本地订阅资源的信息的指示的手段。该方法、系统、计算机可读存储介质或装置具有用于向显示器发布用于跨资源订阅的消息的参数的手段。该方法、系统、计算机可读存储介质或装置具有用于向显示器发布在时间窗口的图形表示内满足准则的事件的手段。该装置可以包括公共服务实体。目标资源的资源可以位于远程设备上。消息可以包括时间窗口的类型的指示，其中时间窗口的类型包括串行时间窗口。消息可以包括时间窗口的类型的指示。消息可以包括在满足准则时预期要接收通知的目标资源的数目。消息可以包括针对多个目标资源的事件通知准则的列表。此段落中的所有组合(包括步骤的移除或添加)都是以与详细描述的其它部分一致的方式设想的。

Claims (12)

1.一种用于跨资源订阅的机器到机器M2M装置，所述M2M装置包括：

处理器；以及

与所述处理器耦合的存储器，所述存储器包括可执行指令，当由所述处理器执行所述可执行指令时使所述处理器实现包括以下各项的操作：

接收用于跨资源订阅的消息，

其中，所述消息指示远程M2M设备对订阅的请求，以及指示时间窗口，其中所述时间窗口的类型是周期性时间窗口类型和滑动时间窗口类型中的一个，

其中，所述订阅是要向所述远程M2M设备通知多个目标资源在由所述消息指示的时间窗口内满足准则；

基于所述消息来确定所述远程M2M设备具有访问所述目标资源的特权；以及

基于具有访问所述目标资源的特权，生成用于所述跨资源订阅的本地订阅资源。

2.根据权利要求1所述的M2M装置，其中，所述消息包括针对所述多个目标资源的事件通知准则的列表。

3.根据权利要求1所述的M2M装置，其中，所述消息包括在满足所述准则时预期要接收通知的所述多个目标资源的数目。

4.根据权利要求1所述的M2M装置，所述操作还包括：提供指令来发送包括跨资源订阅的批准的指示的响应消息。

5.根据权利要求1所述的M2M装置，其中，所述目标资源中的至少一个资源位于所述远程M2M设备上。

6.根据权利要求1所述的M2M装置，所述操作还包括：提供对所述多个目标资源中的第一资源的订阅的请求，其中所述请求包括所述准则的判据。

7.根据权利要求6所述的M2M装置，所述操作还包括：

接收满足所述准则的判据的通知；

基于接收到所述通知来确定满足所述准则；以及

基于所述确定满足所述准则来通知所述远程M2M设备。

8.根据权利要求1所述的M2M装置，其中，所述M2M装置包括公共服务实体。

9.一种用于跨资源订阅的方法，所述方法包括：

由机器到机器M2M实体接收用于跨资源订阅的消息，

其中，所述消息指示远程M2M设备对订阅的请求，以及指示时间窗口，其中所述时间窗口的类型是周期性时间窗口类型和滑动时间窗口类型中的一个，

其中，所述订阅是要向所述远程M2M设备通知多个目标资源在由所述消息指示的时间窗口内满足准则，

基于所述消息由所述机器到机器实体确定所述远程M2M设备具有访问所述目标资源的特权；以及

基于具有访问所述目标资源的特权，由所述机器到机器实体生成用于所述跨资源订阅的本地订阅资源。

10.根据权利要求9所述的方法，其中，所述消息包括针对所述多个目标资源的事件通知准则的列表。

11.根据权利要求9所述的方法，其中，所述消息包括在满足所述准则时预期要接收通知的所述多个目标资源的数目。

12.一种计算机可读存储介质，所述计算机可读存储介质具有在其上存储的计算机程序，所述计算机程序可加载到数据处理单元中并且被适配成当由所述数据处理单元运行所述计算机程序时使所述数据处理单元执行根据权利要求9至11中的任何一个所述的方法步骤。

Images