CN107950038B - 用于分析和群聚服务层订阅和通知以提高效率的方法和设备 - Google Patents

Abstract

订阅分析和群聚机制可以把来自不同订户的类似订阅请求群聚，并为其生成聚合通知。订阅分析和群聚机制减少了订阅请求消息和通知消息的数量，进而提高了订阅效率，使得M2M/IoT服务层更加高效且可伸缩。

Description

用于分析和群聚服务层订阅和通知以提高效率的方法和设备

相关申请的交叉引用

本申请要求于2015年5月20日提交的美国临时专利申请序列号62/164,146的权益，其公开内容通过引用整体并入本文。

背景技术

从协议栈角度来看，服务层102通常位于应用协议层104之上，并向应用106提供增值服务。因此，服务层102通常被归类为“中间件”服务。例如，图1示出了IP网络栈和应用106之间的示例性服务层102。

M2M服务层102是专门针对为M2M型装置和应用提供增值服务的一种类型的服务层的示例。最近，多个行业标准组织(例如，在oneM2M-TS-0001、oneM2M功能架构-V-1.6.1中描述的oneM2M)一直在开发M2M服务层以解决与将M2M类型的装置和应用的集成到诸如互联网/Web、蜂窝、企业和家庭网络等部署相关的挑战。

M2M服务层可以向应用和装置提供对由服务层支持的面向M2M能力的集合的访问。一些示例包括安全性、计费、数据管理、装置管理、发现、配置和连接性管理。这些能力经由应用编程接口(API)是应用可访问的，该API使用消息格式、资源结构、资源表示和由M2M服务层定义的函数调用。例如，M2M服务层可以维持大量的M2M数据，M2M数据可以由M2M应用根据它们的访问权限进行检索或订阅。基于订阅的数据访问可能比基于检索的数据访问更有效，因为它不向M2M应用引入任何消息直到对所订阅的资源的期望的改变发生，尽管代价是M2M应用在可以接收来自M2M服务层的自动通知之前需要先订阅。

oneM2M是开发技术规范的新标准，其解决了对可以容易地嵌入在各种硬件和软件中的通用M2M服务层的需求，并且依赖于将现场的各种各样的装置与全球M2M应用服务器相连。

如图2所示，oneM2M公共服务层支持通用服务功能(CSF)(即，服务能力)集合。一个或多个特定类型的CSF的实例的集合被称为公共服务实体(CSE)202，其可以被托管在不同类型的网络节点(例如，基础设施节点、中间节点、应用特定节点)上。

oneM2M正用两种架构方法开发服务层，即图3所示的面向资源的架构300(ROA)和图4所示的面向服务的架构400(SOA)。

在ROA架构300中，资源是具有可以经由诸如创建、检索、更新和删除的RESTful方法来操纵的表示的架构中的唯一可寻址元素。这些资源可以使用统一资源标识符(URI)进行寻址。资源可能包含子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其子资源的引用。子资源的生命周期受父母资源生命周期的限制。每个资源都支持存储资源信息的“属性”集合。

CSE可以注册到另一个CSE。例如，M2M网关(即，MN-CSE)向M2M服务器(例如IN-CSE)注册其自身，并且M2M服务器成为M2M网关的注册器CSE。同样，当IN-AE注册到IN-CSE时，IN-CSE被称为IN-AE的注册器CSE。

正在开发SOA架构400(诸如在M2M-TS-0007、服务组件架构-V-0.7.0中描述的那个)以考虑不是基于RESTful的传统部署。它重用了大部分相同的服务层功能架构。服务层包含各种M2M服务，并且多个服务可以群聚成服务组件。除了现有的参考点之外，还引入了服务间参考点Msc。通过Msc参考点的M2M服务组件之间的通信利用了诸如Web服务消息交换模式(MEP)的web服务方法。

oneM2M功能架构定义了CSF集合，其可以由诸如M2M服务器的CSE提供给其他CSE或AE。一个CSF是订阅和通知(SUB)，其提供关于跟踪资源上的改变(例如资源删除)的订阅的通知。

SUB CSF按照访问控制政策来管理对资源的订阅，并且向资源订户希望接收它们的地址发送对应的通知。AE或CSE是订阅资源订户。AE和CSE订阅其他CSE的资源。订阅托管CSE在对资源进行修改时将通知发送到由资源订户指定的地址。资源订阅的范围包括跟踪订阅资源的属性的改变和操作以及指示订阅资源的子资源。每个订阅都可能包含指定发送哪个通知、何时发送和怎样发送通知的通知政策。

SUB CSF支持每个资源订阅请求包括资源订户ID、托管CSE-ID和订阅资源地址。它还可包括其他判据(例如感兴趣资源修改和通知政策)以及向其发送通知的地址。

SUB CSF还支持经由单个订阅来订阅单个资源的能力，或者当它们被群聚并且被表示为单个组资源时经由单个订阅来订阅多个资源的能力。

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

图5图示了根据oneM2M规范的示例过程，其中作为订户的IN-AE1订阅IN-CSE上的资源(即，<订阅资源>)。为此，IN-AE1发出创建请求以在<订阅资源>下创建<订阅>资源(即图5的步骤1)；IN-AE1可以在这个步骤中指示事件通知判据和多个通知URI。事件通知判据示出IN-AE1感兴趣的关于<订阅资源>的哪些事件。如由通知URI(即本示例中订户的通知URI1和另一个通知接收方的通知URI2)所指示的，通知可以被发送给订户(即IN-AE1)和/或通知接收方。作为托管CSE的IN-CSE在接收到来自图5的步骤1的订阅请求之后将首先创建<订阅>作为<订阅资源>的子资源。之后，当事件发生并且满足包含在步骤1中的事件通知判据时，IN-CSE将自动发送两个通知，分别给由通知URI1和通知URI2指示的订户和通知接收方(即图5的步骤5和步骤6)。应指出，如果步骤1中的通知URI包含其URI，则通知接收方可以是订户本身。另外，图5的步骤1中的订阅请求可以包含多个通知URI，这意味着订户请求将来的通知被发送到多个通知接收方，但是事件通知判据是相同的并且适用于所有的通知URI。图中没有示出，但是oneM2M支持托管CSE执行批量通知，其中托管CSE可以在一个消息中向同一个通知URI发送多个通知。

根据oneM2M规范，如果订户在其订阅请求中指示多个通知URI，则托管节点需要生成多个通知。而且，如果多个订户对相同的资源感兴趣，他们需要做出单独的订阅请求，并且托管CSE将不得不向每个订户或指定的通知接收方发送单独的通知。另外，oneM2M不支持任何功能来分析和/或利用不同订阅请求之间的潜在关系。

根据oneM2M功能架构，“可以将资源通告给一个或多个远程CSE，以通知远程CSE存在原始资源。已通告的资源可以具有来自原始资源的有限的属性集合和有限的子资源集合。所通告的资源包括到由原始资源托管CSE托管的原始资源的链接”。例如，MN-CSE(例如，M2M网关)向IN-CSE(例如，M2M服务器)注册，并且可以向IN-CSE通告其本地资源。被通告的资源可用于促进和加速资源发现。

oneM2M功能架构还指定：

“由原始资源通告的属性和通告的资源之间的同步是原始资源托管CSE的责任。”

“所通告的属性与原始资源具有相同的值，原始资源的通告的属性值与通告的资源之间的同步是原始资源托管CSE的责任。”

但是，oneM2M没有给出关于如何在托管CSE和远程CSE之间执行这种同步的细节。如果资源属性值快速变化，那么这种同步可能非常频繁并且导致高开销。例如，具有集成运动传感器的基于蜂窝的M2M装置向其云中的注册器CSE(即，M2M服务器)通告运动传感器读数。由于运动传感器读数会快速变化，为了维持原始运动传感器读数与所通告的运动传感器读数之间的同步，将导致M2M装置与M2M服务器之间的高通信开销，其可能由于由蜂窝连接提供的有限的带宽变得甚至不可承受。

发明内容

oneM2M提供用于访问由托管节点(例如，M2M服务器)维持的数据或资源的订阅机制。基本上，托管节点上的资源可以由各种订户(例如，M2M网络应用)订阅。例如当资源改变其值并且满足订户的事件通知判据时，托管节点将向订户发送自动通知。当多个订户对相同的资源和事件感兴趣时，首先需要根据oneM2M规范向托管节点发送多个且单独的订阅请求。结果，托管节点需要向这些订户发送多个相同的通知。这样的订阅操作是低效的，因为这些多个订阅请求和对应的通知是相同的并造成开销。

为了解决这个问题，本公开提出了订阅分析和群聚(grouping)机制，其可以把来自不同订户的类似订阅请求群聚，并且为其生成聚合通知(aggregated notification)。本发明的订阅分析和群聚机制减少了订阅请求消息和通知消息的数量，进而提高了订阅效率，使得M2M/IoT服务层更加高效和可伸缩。具体来说，提出了以下想法。

新的订阅分析和群聚架构(A)，其中托管节点分析来自各个订户的订阅请求并将它们群聚成不同的订阅组。然后，托管节点把每个订阅组的聚合通知发送到中转节点，在中转节点进行通知分发，并将单独通知发送给原始订户或指定的通知接收方。

新的订阅分析和群聚架构(B)，其中订阅分析/群聚和通知分发都在中转节点处执行。第一中转节点(例如，订户的注册者CSE)接收来自不同订户的订阅请求，并且如果满足某判据则将其聚合。第一中转节点然后将聚合的订阅请求发送到托管节点。当资源发生变化时，托管节点向提供通知分发服务的第二中转节点发送聚合通知，并将通知分发给订户。订户或第一中转可以在其订阅请求中指示第二中转节点的地址。

新订阅分析和群聚服务(SAGS 1002)，其负责聚合相似订阅请求，使用通知URI的列表来配置通知分发服务(NODS 1004)，以及向通知分发服务(NODS 1004)发送聚合的通知。

新通知分发服务(NODS 1004)，其从SAGS 1002接收NODS 1004配置和聚合通知。然后，将聚合通知分发给原始订户。

描述了用于在托管节点的订阅聚合以实现所提出的架构A的新过程。

描述了用于在中转节点的订阅聚合以实现所提出的架构B的新过程。

描述了用于经由其通告资源间接订阅原始资源的新过程。在这种情况下，订户向由中转节点维持的通告资源发送订阅请求。中转节点然后将聚合这些请求，并将聚合的请求发送到原始资源驻留的托管节点。当原始资源变化时，托管节点向中转节点发送聚合通知，中转节点将通知分发给订户。

新的资源和属性作为在oneM2M ROA架构中实现所提出的想法的实施例。

提供本发明内容是为了以简化的形式介绍将在以下详细描述中进一步描述的概念的选择。本发明内容部分不旨在标识所要求保护的主题的关键特征或基本特征，也不旨在用于限制所要求保护的主题的范围。此外，要求保护的主题不限于解决本公开的任何部分中提到的任何或全部缺点的限制。

附图说明

从以下结合附图举例给出的描述中可以得到更详细的理解，其中：

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

图2是公共服务实体(CSE)和公共服务功能(CSF)的图。

图3是oneM2M服务层功能架构(ROA)的图。

图4是oneM2M服务组件架构(SOA)的图。

图5是oneM2M一般订阅和通知过程的图。

图6是具有道路状况订阅的智能交通的图。

图7是具有身体状况订阅的智能健康的图。

图8是相同资源的多个订户的图。

图9是聚合订阅和通知系统的流程图。

图10是订阅分析和群聚架构A的图。

图11是订阅分析和群聚架构B的图。

图12是在SAGS 1002处的新订阅请求的流程图。

图13是在SAGS 1002处的订阅删除请求的流程图。

图14是在SAGS 1002处的订阅更新请求的流程图。

图15是NODS 1004处的操作的流程图。

图16是事件发生并SAGS 1002将聚合的通知或定期通知发送到NODS 1004的流程图。

图17是在托管节点处进行订阅分析和群聚的过程的调用流。

图18是在中转节点处进行订阅分析和群聚的过程的调用流。

图19是通过通告资源的订阅的调用流。

图20是新增加的订阅和通知(eSUB)CSF到oneM2M ROA中的图。

图21是在oneM2M中部署新eSUB的图。

图22是一个实施例的图形用户界面(GUI)的图。

图23A是其中可以实现一个或多个公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信系统的系统图。

图23B是可以在图23A所示的M2M/IoT通信系统内使用的示例架构的系统图。

图23C是可以在图23A所示的通信系统内使用的示例性M2M/IoT终端或网关装置的系统图。

图23D是其中可以体现图23A的通信系统的各方面的示例计算系统的框图。

具体实施方式

图6示出了用户订阅道路状况数据的智能交通场景。在这种场景下，收费公司A部署路边摄像头，其可以向驻留在云中并由M2M服务提供商B运营的M2M服务器报告道路状况。虽然可以从经过车辆接收交通状况信息，但不是这个使用情况的重点。M2M服务提供商B部署M2M服务器602(即，IN-CSE)以向M2M用户C、D和E(例如，安装在通勤者的智能电话上的IN-AE)提供接近实时的道路状况。在这个使用情况中，假设路边摄像头作为M2M装置具有M2M服务层能力(例如数据存储库和管理)。由于由路边摄像头产生生成的大量的视频文件，只有感兴趣的条件或事件(例如，轻度交通拥堵、中等交通拥堵和严重交通拥堵)会被报告给M2M服务器602，并最终基于订阅/通知机制被转发给M2M订户。应指出，路边摄像头可以通过图像处理和分析来总结出这样的交通状况(即轻度拥堵等)。例如，M2M用户C 610通过经由M2M服务器在关于交通拥堵水平上订阅路边摄像头。如果M2M用户C、D和E只与M2M服务提供商B有业务关系，当路边摄像头检测到严重拥塞时，它向M2M服务器发送通知，M2M服务器将把通知中继给M2M用户C 610(尽管如果它维持M2M用户C的URI，路边摄像头也可以直接向M2M用户C发送通知，如果它维持M2M用户C的URI)。另外，通勤者用户在道路状况数据中可能具有相似的兴趣(例如出口拥堵水平)。在这种场景下，M2M用户610，612610、612和614基于订阅/通知机制来访问存储在路边摄像头中的道路状况数据。但道路状况数据本身被视为公开信息，每个人都可以使用，没有太多的隐私问题，但可能会收取一定的使用费。

图7示出了另一种情况，其中老年人702在她/他的身体上具有几个传感器诸如传感器704以监视实时的身体状况。身体状况(特别是检测到的异常)可以通过人的智能装置706(即MN-CSE)报告给M2M服务器(即，IN-CSE)。M2M服务器由M2M服务提供商F708运营。作为M2M装置的智能装置706也具有M2M服务层能力；换句话说，它存储可以由M2M用户710、712、714、716和718订阅的身体状况数据。该人与M2M服务提供商F 708有关系。有一些用户例如该人的监护人、该人的主治医生、该人的虚拟医生(例如Doctor on Demond应用)、该人的保险公司以及该人的健身教练对这个人的身体状况数据感兴趣并订阅它。这些用户与这个人有关系，并且可能对不同类型的身体状况感兴趣，并且他们对身体状况数据的订阅可能不同。在这种场景下，智能装置706中存储的身体状况数据由智能健康生态系统中的不同参与者/用户订阅。此外，对于身体状况数据存在隐私担忧，并且用户对于身体状况数据具有不同的访问权限。另外，M2M用户A710可以发出订阅请求以向多个通知接收方(例如，M2M用户B712、M2M用户C 714等)请求通知。

可以理解的是，图6-7中示出的功能可以实现成软件(即计算机可执行指令)的形式，该软件存储在M2M网络的设备(例如，服务器、网关、装置或其他计算机系统)的存储器中并且在其处理器上执行，例如下面描述的图23C或图23D中所示的那些中的一个。

如在先前的使用情况中所描述的，在终端装置处生成或收集的数据(即，智能运输中的交通状况数据和智能健康中的身体状况数据)由各种应用经由M2M服务器订阅。图8中提炼并描绘了这种基于订阅的数据访问，其中作为M2M用户的三个或更多个M2M应用经由M2M节点1(例如，M2M服务器)向在M2M节点2处生成的数据(例如智能运输中的路边摄像头或智能健康中的身体传感器)订阅。这样的订阅通过M2M节点1路由。

如图8所示，作为订户的每个应用实体802、804和806向M2M节点2 808发出单独的订阅。当感兴趣的事件发生时，M2M节点2 808分别向每个M2M应用发送三个通知。正如早期在智能交通中提到的那样，这些M2M应用(例如安装在通勤者的智能电话上的应用)都对交通负载状况感兴趣并发出几乎相同的订阅请求；换句话说，步骤1、步骤2和步骤3中的订阅请求是相同的。然后，由M2M节点2 808发出的这三个通知也是相同的。换句话说，当M2M应用具有相似的订阅时，多个订阅请求将被发送到M2M节点2 808(即，托管节点)，并且M2M节点2808还经由M2M节点1 810(即中转节点)向M2M应用发送多个通知。中转节点810和托管节点808之间的那些多个订阅请求和通知是低效的，并且特别是当存在大量的M2M应用作为订户时引入额外的开销。此外，现有的oneM2M服务层缺乏功能来分析和利用不同订阅请求之间的关系。

应理解，执行图8中示出的步骤的实体是逻辑实体，该逻辑实体可以实现成存储在例如图23C或图23D中所示的那些的网络节点或计算机系统的存储器中并且在其处理器上执行的软件(即计算机可执行指令)的形式。也就是说，图8中示出的方法可以实现成存储在网络设备的存储器中的软件(即计算机可执行指令)的形式，所述网络设备例如图23C或图23D中示出的设备或计算机系统，该计算机可执行指令当由节点的处理器执行时，执行图8中所示的步骤。还应该理解的是，图8中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路来执行。

为了解决上述问题并优化oneM2M中的现有订阅机制，本公开提出了实现订阅分析和群聚的新架构和方法。基本理念是在托管节点(或中转节点)分析和群聚订户的订阅请求；托管节点随后向中转节点生成聚合的通知，然后中转节点将分发各个通知给原始订户。与现有的oneM2M订阅机制相比，提出的方法减少了订阅请求和通知消息的数量，使得订户和托管节点之间的订阅更加高效。

图9示出了示例性实施例的调用流，其中M2M节点2 808接收聚合的订阅请求并将聚合的通知发送到M2M节点1 810。M2M节点1 810聚合来自M2M AE 802、804和806的订阅请求。M2M节点1 810还在接收到来自M2M节点2 808的聚合通知之后将单独的通知发送到M2MAE 802、804和806。

应理解，执行图9所示步骤的实体是逻辑实体，该逻辑实体可以实现成存储在诸如图23C或图23D中所示的那些的网络节点或计算机系统的存储器中并且在其处理器上执行的软件(即计算机可执行指令)的形式。也就是说，图9所示的方法可以用存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，所述网络设备诸如图23C或图23D所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图9中所示的步骤。还应理解的是，图9中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

首先，呈现两个订阅分析和群聚架构选项，即分别在托管节点和中转节点处的订阅分析和群聚。所提出的架构包括两个新服务：SAGS1002和NODS 1004。描述了SAGS 1002和NODS 1004的功能。讨论了托管和中转节点的订阅分析和群聚。对经由通告资源的订阅描述了新过程。

总体而言，本公开中提出的理念可以针对以下场景执行订阅聚合：

多个订户订阅具有相同的事件通知判据的相同的资源。可以聚合来自这些订户的订阅请求，并且也可以聚合对他们的通知。

多个订户订阅具有不同的事件通知判据的相同的资源。可以聚合来自这些订户的订阅请求，并且也可以聚合对他们的通知。

订户订阅资源并给出多个通知接收方。可以聚合对这些多个接收方的通知。

图10示出了本发明的订阅分析和群聚架构，其中提出两个新服务即SAGS 1002和NODS 1004。SAGS 1002驻留在托管节点中，而NODS1004被置于中转节点中。分别来自三个或更多个订户的原始订阅请求(例如，步骤1-3)(直接地或经由中转节点间接地)到达托管节点。应指出，每个订阅请求都有通知应该发送的通知URI。SAGS 1002分析接收到的订阅请求，并将它们分发给不同的组，称为订阅组。例如，如果步骤1-3中的订阅请求对具有相似事件通知判据的相同订阅资源感兴趣，则它们将被放置在相同组中。然后，SAGS 1002可能需要利用关于群聚的订阅请求的信息和每个原始订阅请求的通知URI来配置NODS 1004(即，步骤4)。NODS 1004依靠这样的配置信息能够稍后向订户分发通知(即步骤6-8)；否则，SAGS1002需要在每个聚合通知中包括这样的信息(尤其是通知URI)(即步骤5)，使得NODS 1004能够解释聚合的通知并将其分发给适当的订户(即，图10的步骤6-8)。应指出，原始订阅请求可以通过不同于NODS 1004所在的中转节点。这个架构中每一步骤的细节将在后面的章节中讨论。

为了便于更多的订阅分析和群聚机会，提出每个资源具有互斥的事件通知判据集合，其可以由托管节点预先配置。然后订户将根据这些事件通知判据进行订阅。例如，可以对图6的智能交通使用情况中的交通状况资源配置以下判据。通过遵循那些配置的事件通知判据，与由每个订户发布的随机事件通知判据形成对比，来自订户的类似订阅请求和被群聚的可能性更高、机会更多。

事件通知判据#1：“交通状况”＝“无拥堵”

事件通知判据#2：“交通状况”＝“零星拥堵”

事件通知判据#3：“交通状况”＝“轻度拥堵”

事件通知判据#4：“交通状况”＝“中等拥堵”

事件通知判据#5：“交通状况”＝“严重拥堵”

应指出，即使对于单个订户，如果订户指示多个通知接收方，仍然可以聚合对应的通知。在这种情况下，SAGS 1002用所有通知接收方的地址配置NODS 1004；然后它发送聚合通知给NODS 1004；最后，NODS 1004将通知分发给所有通知接收方。

备选地，订阅请求也可以在中转节点810处群聚，其中订阅请求将通过中转节点被中继转发或路由，如图11所示。首先，托管节点808可以可选地将其资源的事件通知判据发布到中转节点810(图11的步骤0)。然后，订户1006、1008和1010可以发现那些事件通知判据并订阅它们。如果多个订户在相同事件通知判据(即，图11的步骤1、步骤2和步骤3)上订阅相同资源，则中转节点810中的SAGS 1002可把这些订阅请求群聚，然后发送一个单一的但聚合的订阅请求到托管节点808(即步骤4)。SAGS 1002把这样的订阅群聚通知到NODS1004。当感兴趣事件发生时，托管节点808发送常规通知给NODS 1004(即步骤5)。NODS 1004将通知分发给原始订户(即步骤6、步骤7和步骤8)。虽然SAGS 1002和NODS 1004在图11中被示出在相同的中转节点810中，但是SAGS 1002和NODS 1004可以位于不同的中转节点中。下面将描述每个步骤的细节。

应指出，架构B中的SAGS 1002具有与架构A(即图10)中的SAGS 1002类似的功能，具有用于将所聚合的订阅请求发送到托管节点的新功能(即，图11中的步骤4)。架构B中的NODS 1004具有与架构A中相同的功能。

应指出，即使订户在他们的订阅请求中指示不同的事件通知判据，他们的订阅请求仍然可以在它们针对相同的订户对资源时被群聚。

例如，假设三个订户1006、1008和1010对相同的订户对资源(<subscriber-to-resource>)感兴趣。他们向中转节点810发出三个订阅请求。在他们的请求中，订户1指示事件通知判据1，订户2指示事件通知判据2，而订户3指示事件通知判据3。还假设事件通知判据1、事件通知判据2和事件通知判据3是互斥的。

中转节点810分析和群聚这三个请求，并生成包含事件通知判据1、eventNotificationCriter2和事件通知判据3的聚合订阅请求。

当事件发生并且它满足事件通知判据1、事件通知判据2或事件通知判据3时。它向中转节点810发送通知。该通知将包含对应的事件通知判据，中转节点810根据该判据知道接收该通知的订户。当事件通知判据1、事件通知判据2和事件通知判据3彼此不互斥时，中转节点810可以确定几个互斥的事件通知判据，并将它们包括在对托管节点的聚合订阅中。然后，当接收到来自托管节点的通知时，仍然能够找出正确的订户接收该通知。

应理解，执行图10和图11所示的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，所述软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也就是说，图10和图11中所示的方法可以用存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图10和图11中所示的步骤。还应理解，图10和图11中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

以下关于图12-16来描述SAGS 1002和NODS 1004的功能和操作。

SAGS 1002具有一些功能，包括：

图12示出了当SAGS 1002接收到新订阅请求SR(i)时的操作，

图13示出了当SAGS 1002接收到删除现有订阅请求SR(i)的请求时的操作，

图14示出了当SAGS 1002接收到更新现有订阅请求SR(i)的请求时的操作，

图16示出了当事件发生时，并且SAGS 1002需要将聚合的通知发送到NODS 1004的操作。

NODS 1004功能在图15中给出。

图12示出了SAGS 1002在接收到新订阅请求SR(i)时的操作。

在图12的步骤1中，新的订阅请求SR(i)到达。

在图12的步骤2中，SAGS 1002分析SR(i)并获得诸如订阅资源r(i)，事件通知判据enc(i)和通知URI(i)的信息。从接收到的SR(i)中，SAGS 1002还可以知道并记录中转节点810的地址(即tn(i))。

对于SAGS 1002驻留在托管节点中的架构A，中转节点810可以在将其地址转发到SAGS 1002之前将其地址插入到SR(i)，或者订户可以在其订阅请求中包括中转节点810地址。

对于SAGS 1002驻留在中转节点810中的架构B，tn(i)可以是相同的中转节点810或可以由订户在订阅请求中指示的不同中转节点。

在图12的步骤3中，SAGS 1002搜索其本地数据库(即先前创建的所有订阅组)以找到可容纳SR(i)的现有订阅组SG(j)。应指出，本公开中的订阅组被定义为具有相似订阅要求(例如，相同的订阅资源和相同的中转节点810以及相似的事件通知判据等)的订阅请求集合。订阅组的每个成员都是接收到的订阅请求。换句话说，每个订阅组具有三个公共属性：订阅资源、中转节点810和事件通知判据，它们由所有成员订阅请求共享。SAGS 1002可以设置订阅组可以具有的订阅请求的数量的限制。

如果找到SG(j)，则意味着SR(i)具有与SG(j)中的其他请求相同的资源订阅和相似事件通知判据。如果SG(j)仍然可以容纳新的请求，则转到步骤6将SR(i)群聚到SG(j)。如果SG(j)不能再容纳新的请求，则转到步骤4。

如果没有这样的SG(j)，则转到步骤4。

在图12的步骤4中，SAGS 1002搜索其本地数据库(即之前接收但尚未群聚的所有订阅请求)以找到与SR(i)具有相同订阅资源的未群聚订阅请求(USR))、与SR(i)相同的中转节点810以及与SR(i)类似的事件通知判据。

如果找到USR，则意味着可以将SR(i)和ESR群聚在一起来制定新的订阅组。然后到步骤8。

如果没有找到这样的USR，则转到步骤5。

在图12的步骤5中，SAGS 1002在没有任何订阅聚合的情况下缓存SR(i)。然后处理这个SR(i)的过程就完成了。

在图12的步骤6中，从步骤4，SAGS 1002将SR(i)添加到由SG(j)包含的订阅请求的列表中。由于SG(j)现在被改变，所以SAGS 1002可能需要向对应的NODS 1004发送更新以通知其该改变(即，所添加的SR(i)尤其是其通知URI nu(i))。应指出，步骤9讨论了如何为新创建的订阅组确定适当的NODS 1004。

在图12的步骤7中，SAGS 1002向NODS 1004发送消息以通知其新的SR(i)被添加到SG(j)。基本上，NODS 1004维持SG(j)的所有订阅请求的通知URI。现在，SAGS 1002将SR(i)的通知URI告知NODS1004。然后处理这个SR(i)的过程就完成了。

在图12的步骤8中，SAGS 1002创建包括两个订阅请求SR(i)和USR的新订阅组SG(k)。应指出，SR(i)和USR都具有相同的资源订阅、相同的中转节点810和类似的事件通知判据。该公共中转节点810将被选择为NODS 1004应该驻留的节点。

在图12的步骤9中，SAGS 1002选择SR(i)和USR的公共中转节点810作为节点以托管NODS 1004以服务SG(k)。

应指出，SR(i)可以指示NODS 1004的地址。同样，USR也可以包含NODS 1004地址。假定SR(i)和USR都具有相同的NODS 1004地址；否则它们不会被聚合。换言之，如果订阅请求指示NODS 1004地址，则订阅组内的订阅请求的公共NODS 1004地址将被选择为该订阅组的NODS 1004。

在图12的步骤10中，SAGS 1002向NODS 1004发送消息以通知其新创建的SG(k)。基本上，SAGS 1002将SR(i)和USR的通知URI告知NODS 1004。此类信息将由NODS 1004维持，并由NODS 1004稍后利用以向SR(i)和USR的订户分发通知。

在图12的步骤11中，SAGS 1002结束处理新订阅请求SR(i)。

应理解，执行图12中示出的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，该软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也就是说，图12中所示的方法可以用存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图12中所示的步骤。还应理解，图12中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

图13示出了当SAGS 1002接收到删除现有订阅请求SR(i)的请求时的操作。

在图13的步骤1中，SAGS 1002接收(例如来自订户的)请求以删除现有的订阅请求SR(i)。

在图13的步骤2中，SAGS 1002尝试找到先前规范化并包括SR(i)的现有订阅组SG(j)。

如果找到这样的SG(j)，则转到步骤3；否则，去步骤5。

在图13的步骤3中，SAGS 1002从SG(j)中移除SR(i)。

在图13的步骤4中，SAGS 1002向NODS 1004发送更新以通知其移除SR(i)。基本上，将删除NODS 1004所维持的SR(i)的通知URI。

如果SG(j)在移除SR(i)之后仅包含一个订阅请求，则SAGS 1002可以仅从其本地数据库中删除SG(j)，并且在步骤4中告知NODS 1004移除所有SG(j)信息。

在图13的步骤5中，SAGS 1002等待接收来自NODS 1004的响应。但SAGS 1002将需要删除SR(i)，而不管来自NODS 1004的响应是成功还是失败。

在图13的步骤6中，SAGS 1002从其本地数据库中删除SR(i)。

在图13的步骤7中，SAGS 1002结束处理在步骤1中接收到的请求。

应理解，执行图13所示的步骤的实体是可以用软件(即，计算机可执行指令)的形式实现的逻辑实体，该软件(即计算机可执行指令)被存储在如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也就是说，图13中所示的方法可以用存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图13中所示的步骤。还应理解，图13中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

图14示出了当SAGS 1002接收到更新现有订阅请求SR(i)的请求时的操作。

在图14的步骤1中，SAGS 1002接收更新现有订阅请求SR(i)的请求(例如，改变其通知URI)

在图14的步骤2中，SAGS 1002尝试找到先前公式化并包括SR(i)的现有订阅组SG(j)

如果找到这样的SG(j)，则转到步骤3；否则，到步骤5。

在图14的步骤3中，SAGS 1002根据步骤1中接收到的请求更新SR(i)。

在图14的步骤4中，SAGS 1002将更新的SR(i)作为新的订阅请求并且遵循图12中的所有步骤。然后到步骤10。

在图14的步骤6中，SAGS 1002确定SR(i)是否仍然可以被包括在其当前组SG(j)中。如果答案为是，到步骤9。如果答案为否，到步骤7。

在图14的步骤7中，SAGS 1002从SG(j)中移除SR(i)。

在图14的步骤8中，SAGS 1002向NODS 1004发送更新。基本上，将移除关于NODS1004所维持的SR(i)的信息，例如SR(i)的通知URI。然后到步骤4。

在图14的步骤9中，SAGS 1002确定是否需要向NODS 1004发送更新。例如，如果步骤1中的请求要求更新SR(i)的通知URI，则SAGS1002需要用新的通知URI更新NODS 1004。

如果需要更新，则转到步骤10；否则，到步骤11。

在图14的步骤10中，与步骤8类似。SAGS 1002将更新发送到NODS 1004。

在图14的步骤11中，SAGS 1002结束处理在步骤1中接收到的请求。

可以理解，执行图14中示出的步骤的实体是可以用软件(即，计算机可执行指令)的形式实现的逻辑实体，该软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也即图14中所示的方法可以用存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图14中所示的步骤。还应理解，图14中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

图15示出了NODS 1004的操作。

在图15的步骤1中，NODS 1004从SAGS 1002接收消息。

在图15的步骤2中，该消息可以是聚合通知或NODS 1004配置。如果是前者，则转到步骤5；否则，到步骤3。

在图15的步骤3中，NODS 1004从在步骤1中接收到的消息中提取订阅组信息(即SG(i))，并配置对应的通知组NG(i)。NG(i)包含以下信息或属性：

NG(i)的标识符。

SG(i)包括的所有订阅请求的通知URI的列表。每个通知URI可以被认为是NG(i)的成员。

在图15的步骤4中，NODS 1004将NG(i)的标识符或URI发送到SAGS 1002。SAGS1002将NG(i)的标识符或URI添加为SG(i)的新属性。然后到步骤11。

在图15的步骤5中，NODS 1004分析在步骤1中接收到的聚合通知，并确定其是否包含现有NG(i)的标识符或URI。如果答案为是，则转到步骤6；否则，到步骤8。

在图15的步骤6中，NODS 1004从其本地数据库中定位NG(i)并找到其成员(即原始订户的通知URI)

在图15的步骤7中，NODS 1004将通知内容(如在步骤1中接收到的消息中包含的)分发给每个通知URI。然后到步骤11。

在图15的步骤8中，NODS 1004从接收到的聚合通知消息中提取通知URI信息。

在图15的步骤9中，NODS 1004将通知内容分发给每个通知URI或订户。

在图15的步骤10中，NODS 1004等待来自订户的响应。如果没有响应，NODS 1004可以到步骤9以重新发送通知。

在图15的步骤11中，NODS 1004结束处理在步骤1中接收到的消息。

可以理解，执行图15中示出的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，软件被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也就是说，图15中所示的方法可以以存储在网络设备的存储器中的软件(即，计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图15中所示的步骤。还应理解，图15中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

图16示出了当事件发生并且SAGS 1002需要向NODS 1004发送聚合的通知时SAGS1002的操作。当SAGS 1002和NODS 1004不是共同定位时，所提出的架构A或所提出的架构B需要该过程。

在图16的步骤1中，发生与托管节点上的订阅资源有关的事件。

在图16的步骤2中，结果是，SAGS 1002需要检查是否存在与该事件相关的任何订阅组，并且如果需要则发送聚合的通知到NODS1004。

如果答案为是，则转到图16的步骤3；否则，到步骤8。

在图16的步骤3中，SAGS 1002处理每个找到的订阅组SG(i)以获得SG(i)的以下信息：

对应的NODS 1004的地址；

SAGS 1002先前已经在NODS 1004中配置的对应的NG(i)的URI的标识符(如果有的话)；

SG(i)包括的所有订阅请求的通知URI。

在图16的步骤4中，SAGS 1002检查SG(i)是否具有先前在NODS1004中配置的对应NG(i)。

如果答案为是，则到图16的步骤5；否则，到图16的步骤6。

在图16的步骤5中，SAGS 1002将聚合的通知发送到与该SG(i)相关联的NODS1004。该消息去往对应的NG(i)的标识符或URI。然后到图16的步骤7。

在图16的步骤6中，SAGS 1002将聚合的通知发送到与该SG(i)相关联的NODS1004。由于SAGS 1002没有在NODS 1004中配置NG(i)，所以该消息将包含SG(i)中包括的所有订阅请求的通知URI。

图16的步骤7，SAGS 1002检查SG(i)是否是在图16的步骤2中找到的最后一个订阅组。

如果答案为是，则意味着图16的步骤2中找到的所有订阅组已经被处理并且转到图16的步骤10；否则，回到图16的步骤3。然后到图16的步骤10。

图16的步骤8，SAGS 1002尝试找到是否存在与图16的步骤1中的事件相关的任何未群聚的订阅请求。

如果答案为是，则转到图16的步骤9；否则，到图6的步骤10。

在图16的步骤9中，SAGS 1002向与图16的步骤8中找到的每个订阅请求相关联的订户发送常规通知。

图16的步骤10，SAGS 1002结束处理在步骤1中发生的事件。

可以理解，执行图16中示出的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也即图16中所示的方法可以以存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图16中所示的步骤。还应理解，图16中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

在图17中，多个订户(例如，M2M应用)在托管节点(例如，M2M网关)处对相同的资源订阅进行订阅。托管节点具有对这些订阅进行群聚的SAGS 1002，在中转节点810中的NODS1004处配置通知组，并且继而在中转节点810向NODS 1004发送聚合通知。NODS 1004最终将分发通知给每个用户。详细的程序如下所述。

在图17的步骤1中，订户1向托管节点发送订购请求。此消息可包含以下参数：

resourceID：表示订户1正在订阅的订阅资源的标识符。

notifURI：表示订户1想要向其发送通知的URI或地址。

eventNotifCriteria：表示触发向notifURI发送通知的条件

aggrgFlag：指示该订阅请求是否可以被聚合。

NODS 1004URI：代表订户1希望将聚合通知发送到的NODS 1004的URI。例如，订户1可以将NODS 1004URI设置成其注册器CSE。

如果aggrgFlag＝FALSE，这意味着订户1不希望订阅聚合，并且继而可能不需要NODS 1004URI。

在图17的步骤2中，订户2向托管节点发送订阅请求。该消息包含与图17的步骤1中的消息相同的参数。

在图17的步骤3中，托管节点中的SAGS 1002聚合在步骤1和步骤3中接收到的订阅请求，因为它们具有相同的资源ID，类似的eventNotifCriteria和相同的NODS 1004URI。结果，SAGS 1002为这两个请求创建一个订阅组。

应指出，为了便于说明，在图17中仅示出了两个订户和两个订阅请求。但是SAGS1002可以聚合更多的订户及其订阅请求。

在图17的步骤4中，SAGS 1002向NODS 1004发送消息(注意在图17的步骤1和图17的步骤2中指示了NODS 1004的地址)以在NODS 1004中创建或更新通知组。该消息可以包含以下参数：

包含在图17的步骤1中的notifURI1。

包含在图17的步骤2中的notifURI2。

可选地，订户1和订户2的标识符。

因此，在图17的步骤5中，NODS 1004创建具有两个成员(即，在步骤1和步骤2中接收到的notifURI1和notifURI2)的通知组。NODS1004为该通知组分发标识符。

在图17的步骤6中，NODS 1004将创建的通知组的标识符发送给SAGS 1002。

在图17的步骤7中，发生满足步骤1和步骤2中的eventNotifCriteria的事件。

在图17的步骤8中，由于发生的事件，SAGS 1002将聚合的通知发送到NODS 1004。该消息针对步骤6中接收到的通知组。换句话说，该消息包括目标通知组的标识符。

应指出，在步骤1和步骤2中已经指示了NODS 1004的地址。

在图17的步骤9中，NODS 1004定位如在图17的步骤5中创建的目标通知组及其成员(即，notifURI1和notifURI2)。

在图17的步骤10中，NODS 1004将聚合的通知转发给notifURI2。

在图17的步骤11中，NODS 1004将聚合的通知转发给notifURI1。

在图17的步骤12中，NODS 1004向SAGS 1002发送响应，以通知其已成功接收通知的notifURI(即订户)的列表或NODS 1004未成功地向其递送通知的notifURI(即订户)的列表。

关于图17有几个选项或替代方案。

注1：订户1和订户2可以经由他们的注册器CSE(例如，图中的中转节点810)发送他们的订阅请求。可选地，两个订户都不在他们的订阅请求中指示NODS 1004URI，但是注册者CSE本身可以将其地址作为NODS 1004URI插入到每个订阅请求中。

应当理解，执行图17中所示的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也即图17中所示的方法可以以存储在网络设备的存储器中的软件(即，计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图17中所示的步骤。还应理解，图17中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

表1.图17中主要消息的格式

订阅分析和群聚也可以在中转节点(如图18中的中转节点2)处执行。在这种情况下，中转节点具有SAGS 1002和NODS 1004两者。为了便于在中转节点处的订阅分析和群聚，托管节点可能需要首先将其事件通知判据发布到中转节点。然后订户将根据这些事件通知判据进行订阅。下面描述详细的过程，其由三个阶段组成：订阅分析和群聚(即，图18的步骤1-10)，向现有订阅组添加新订阅(即图18的步骤11-14)以及通知分发(即图18的步骤15-23)。

在图18的步骤1中，托管节点将其资源和关联的事件通知判据发布到中转节点2，中转节点2可以是托管节点的注册器CSE。该消息包含以下三个参数的列表。

resourceID：可以被订阅的源的标识符。

eventNotifCriteria：与由resourceID表示的资源相关联的事件通知判据。

whiteSubList：允许对由resourceID表示的资源进行订阅的订户列表。

blackSubList：不允许对由resourceID表示的资源进行订阅的订户列表。

用于允许或不允许订户的访问控制判据。应指出，访问控制判据可以基于订户的位置、订户的服务或应用类型等。

在图18的步骤2中，中转节点2维持资源ID列表及其eventNotifCriteria。它向托管节点发送回响应。

在图18的步骤3中，订户1向中转节点2发送订阅请求。除了resourceID、notifURI和eventNotifCriteria之外，该消息还可以包含两个新参数aggrgFlag和NODS 1004URI。应指出，此消息的目的地是中转节点2。

aggrgFlag：用于指示订户1想要聚合这个订阅请求(例如，如果aggrgFlag＝TRUE)或者不想要聚合这个订阅请求(例如，如果aggrgFlag＝FALSE)的标志。

NODS URI代表订户1希望将聚合通知发送到的NODS 1004的URI。例如，订户1可以将NODS 1004URI设置成其注册器CSE。该参数是可选的。

如果aggrgFlag＝FALSE，这意味着订户1不需要订阅聚合，并且不需要NODS URI。

在图18的步骤4中，订户2向中转节点2发送订阅请求。该消息与步骤3相似。应指出，此消息的目的地是中转节点2。

在图18的步骤5中，中转节点2中的SAGS 1002发现步骤3和步骤4中的两个请求都可以被聚合(例如，它们具有相同的resourceID和eventNotifCriteria；并且都在步骤1中接收的whiteSubList中)。然后它聚合两个请求并创建订阅组SG(i)。

在图18的步骤6中，中转节点2 1802中的SAGS 1002向具有NODS 1004的中转节点1810发送消息以创建或更新通知组。该消息包含notifURI1(来自订户1 1006)和notifURI2(来自订户2)。中转节点1 810可能更接近订户或其通知接收方；因此它对于它执行NODS1004是更有效的。

注意，SAGS 1002和NODS 1004可以共同位于相同的中转节点中。例如，M2M网络应用向其注册器M2M服务器发送订阅请求。注册器M2M服务器同时具有SAGS 1002和NODS1004。M2M网络应用甚至不需要指示NODS 1004URI和aggrgFlag；注册器M2M服务器可以聚合他们的订阅请求。

注意，中转节点1可由中转节点2来选择，中转节点2例如由于中转节点2处的高流量负载或中转节点1更接近订户而将其NODS1004委托给中转节点1。步骤6可以同时执行这种NODS 1004委托，并且不需要附加的消息。

在图18的步骤7中，中转节点1中的NODS 1004创建/更新对应的通知组NG(i)。NG(i)有两名成员(即notifURI1和notifURI2)。

在图18的步骤8中，NODS 1004向SAGS 1002发送响应以通知NG(i)的标识符。

在图18的步骤9中，中转节点2 1802向托管节点发送聚合的订阅请求。该消息可包含以下与SG(i)相关的参数。另外，SAGS 1002保持SG(i)和NG(i)之间的映射关系。

resourceID：订户1 1006和订户2 1008所感兴趣的资源的标识符。

eventNotifCriteria：订户11006和订户2 1008的事件通知判据指示。

newNotifURI：指示托管节点808应该将该通知发送到的地址。中转节点2 1802有两个选项来设置这个参数。

选项1：将newNotifURI设置成中转节点2或为订户1 1006和订户2 1008创建的SG(i)的标识符。图18示出了该选项。

选项2：将newNotifURI设置成NODS 1004的地址(即，NODS1004URI)。如果使用该选项，则步骤16将直接从托管节点808到NODS1004。

subscriberList：包含在SG(i)中的原始订户列表。该参数是可选的。

在图18的步骤10中，托管节点向中转节点2发回响应。

如果subscriberList被包括在图18的步骤9中，则托管节点可拒绝一些订户。如果发生这种情况，中转节点2中的SAGS 1002将重复图18的步骤6-8以更新NODS 1004中的NG(i)。

在图18的步骤11中，另一个订户3进行订阅请求，其类似于步骤3和步骤4。

在图18的步骤12中，SAGS 1002发现可以将该请求聚合到SG(i)(例如，具有相同的资源ID和相同的eventNotifCriteria)。因此，它将订户3添加到SG(i)。

在图18的步骤13中，SAGS 1002发送消息以用订户3的notifURI3更新NODS 1004。

在图18的步骤14中，NODS 1004向NG(i)添加notifURI3作为新成员。

在图18的步骤15中，发生与步骤3/4/11中的eventNotifCriteria对应的事件。

在图18的步骤16中，托管节点808向在步骤9中指示的newNotifURI发送通知。

在图18的步骤17中，中转节点2接收该通知并将该通知转发给NG(i)。

在图18的步骤18中，中转节点1 810中的NODS 1004接收该通知。它发现这个通知目标NG(i)，并且因此，它将通知分发给NG(i)的所有成员(即notifURI1、notifURI2和notifURI3)。

在图18的步骤19-21中：NODS 1004分别向三个订户分发通知。

在图中没有示出，但是每个订户可以向NODS 1004发回响应以确认接收到通知。在NODS 1004的响应消息中，每个订户还可以指示新的notifURI用于接收将来的通知。

在图18的步骤22中，NODS 1004向SAGS 1002发送响应以通知其哪个原始订户已经成功接收到通知。

在图18的步骤23中，SAGS 1002将响应发送回托管节点。

可以理解，执行图18所示的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也即图18中所示的方法可以以存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图18中所示的步骤。还应理解，图18中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

表2.图18中主要消息的格式

在现有的oneM2M中，每个通告的资源都有对应的原始资源，并且可以订阅通告的资源。换句话说，M2M实体可以向通告的资源发出订阅请求以获得关于对所通告的资源的改变的通知。但是这个请求不能获得有关事件的通知或对原始资源的更改。图19示出了M2M实体向通告的资源发送订阅请求，但意图是获得关于对原始资源的改变的未来通知的情况。

在图19的步骤1中：托管节点808向中转节点发送修改的资源通告消息。除了原始资源的标识符(即，资源ID)之外，该消息在图19的步骤4中包含以下用于促成订阅的新参数。将添加这些新参数作为在图19的步骤2中创建的所通告的资源的新属性。

eventNotifCriteria：代表通告的资源的事件通知判据。

subPolicy：代表对通告的资源的订阅政策(例如，如在前面部分中定义的whiteSubList和blackSubList)。

subToOriginalResourceEnable：只有当这个参数是TRUE时，原始资源才能通过其在图19的步骤2中在中转节点处创建的通告资源进行订阅。

在图19的步骤2中：中转节点创建对应的通告资源(例如，<rsc1Annc>)。该资源具有三个新的属性subToOriginalResourceEnable、subPolicy、eventNotifCriteria，如图19的步骤1所传递的。

如果subToOriginalResourceEnable＝TURE，则订户可以经由这个通告资源(例如步骤4、步骤5和步骤8)来订阅原始资源。

在图19的步骤3中，中转节点向托管节点发送响应。

在图19的步骤4中，订户1向中转节点发送订阅请求。该消息包含以下参数。

resourceID：以<rsc1Annc>为例。这意味着订阅请求的目标是这个通告的资源(当subType＝ANNOUNCE时)或其原始资源(当subType＝ORIGINAL时)。

eventNotifCriteria：指示与该订阅相关联的事件通知判据。该参数是图19的步骤1中包含的“eventNotifCriteria”的子集。

subType：指示订户是对原始资源的改变感兴趣(当subType＝ORIGINAL时)还是对通告的资源的改变感兴趣(当subType＝ANNOUNCE时)。

notifURI1：指示订户1期望从其接收未来通知的地址。

在图19的步骤5中，订户2 1008向中转节点810发送订阅请求。该消息类似于图19的步骤4。

在图19的步骤6中，中转节点使用在图19的步骤1中接收的子政策来确定是否应当批准来自订户1 1006和订户2 1008的订阅请求(例如，订户1 1006和订户2 1008都在whiteSubList中)。在这个示例中，它批准了这两个请求。然后中转节点发现图19的步骤4和步骤5中的请求具有相同的resourceID和eventNotifCriteria。然后它创建一个订阅组订阅组作为所通告资源的子资源(即<rsc1Annc>/<subGroup1>)。<subGroup1>具有两个成员(即，在图19的步骤4和步骤5中接收到的notifURI1和notifURI2)和虚拟资源“fanout”。将使用虚拟资源“fanout”来触发将通知分发给<subGroup1>的每个成员。

在图19的步骤7中，中转节点用以下参数向托管节点发送常规订阅请求。

resourceID：设置成在图19的步骤4和步骤5中相同的资源ID。

eventNotifCriteria：设置成在图19的步骤4和步骤5中相同的eventNotifCriteria。

notifURI：设置成“<rsc1Annc>/<subGroup1>/fanout”。

在图19的步骤8中，订户3 1010向中转节点发送订阅请求。该消息类似于图19的步骤4，但具有不同的notifURI3。

在图19的步骤9中，中转节点发现图19的步骤8中的请求与图19的步骤4和步骤5中的请求类似。结果，它将notifURI3添加到<subGroup1>。但是由于中转节点810已经在图19的步骤7中向托管节点808发送了订阅请求，所以它将不再发送请求，并且因此节省了其与托管节点808之间的消息开销。

在图19的步骤10中，发生与步骤7中的eventNotifCriteria相对应的事件。

在图19的步骤11中，托管节点808在中转节点810处向“<rsc1Annc>/<subGroup1>/fanout”发送通知。关键字“fanout”用于触发中转节点810将通知分发给<subGroup1>的每个成员(即notifURI1、notifURI2和notifURI3)。

在图19的步骤12中，中转节点810将通知转发给notifURI1。

在图19的步骤13中，中转节点810将通知转发给notifURI2。

在图19的步骤14中，中转节点810将通知转发给notifURI3。

可以理解，执行图19中示出的步骤的实体是可以用软件(即计算机可执行指令)的形式实现的逻辑实体，软件(即计算机可执行指令)被存储在诸如图23C或图23D中所示的网络节点或计算机系统的存储器中并在其处理器上执行。也即图19中所示的方法可以以存储在网络设备的存储器中的软件(即计算机可执行指令)的形式来实现，网络设备诸如图23C或图23D中所示的设备或计算机系统，计算机可执行指令当由节点的处理器执行时，执行图19中所示的步骤。还应理解，图19中所示的任何发送和接收步骤可以在节点的处理器和它执行的计算机可执行指令(如软件)控制下由节点的通信电路执行。

如上所述，现有的oneM2M描述了一种能够实现原始属性和通告属性之间的同步的机制(称为通告同步)。但是并没有详细说明如何实现这种通告同步。以图19中的配置为例，可以将通告同步和资源订阅结合起来。

在替选实施例的步骤1中，托管节点(例如，MN-CSE)向中转节点(例如，IN-CSE)通告其资源(即，原始资源)。

在替选实施例的步骤2中，中转节点810创建对应的通告资源。

在替选实施例的步骤3中，订户1 1006(例如，IN-AE1)在中转节点上订阅所通告的资源。

在替选实施例的步骤4中，托管节点808维持其原始资源与通告资源之间的同步。换句话说，每当对原始资源进行改变时，托管节点808可以向中转节点810发送通知，使得通告资源将与原始资源保持同步。

在替选实施例的步骤5中，中转节点810基于从托管节点808接收到的通知更新所通告的资源。然后，它使用其最新值来为订户1 1006的订阅提供服务。例如，如果通告资源的新值满足由订户1 1006指示的事件通知判据，那么中转节点810向订户1 1006发送通知。

然而，与图19中呈现的解决方案相比，这种通告同步具有一些缺点或缺陷。

首先，oneM2M规范没有给出关于如何实现这种通告同步的细节。

其次，oneM2M规范说：“由原始资源通告的属性与所通告资源之间的同步是原始资源托管CSE的责任。”这意味着托管CSE将确定如何执行通告同步。因此，它独立于资源订阅。换句话说，对通告的资源的订阅是独立于通告同步，且不会受到通告同步的影响。

这种通知同步将需要托管CSE 810保持向中转节点808发送通知，即使没有任何订户对原始资源的新值感兴趣。与图19所示的解决方案相比，此类通知同步会在托管CSE 810和中转CSE之间产生更多的通知和开销。

一些订户可能对事件(例如，在原始资源上存在更新操作)感兴趣。单独使用“通告同步”无法实现此目标，因为“通告同步”不会将此类事件报告给发布的资源。

表3.图19中主要消息的格式

为表4中列出的现有oneM2M<订阅>资源提出三个新的属性。

表4.<订阅>资源的新属性

针对表5中列出的现有oneM2M通告资源，提出三个新的属性。

表5.通告资源的新通用属性

针对订户可订阅的任何资源提出新的公共属性(表6)。

表6.新的公共属性

如上所述，从SAGS 1002到NODS 1004的聚合通知可以包括到每个原始订户的所有notifURI。为了支持该特征，提出当通知是从SAGS1002发送到NODS 1004的聚合通知时，现有的oneM2M通知消息包括以下参数/信息。

notifURIList：指示给每个原始订户的notifURI列表。换句话说，这个列表中的每个项目都是针对不同订户的notifURI。当NODS 1004收到来自SAGS 1002的聚合通知时，它将提取包含在该参数中的所有notifURI，并将通知分发给每个notifURI。

当订户收到通知消息时，需要发回响应。提出这个通知响应消息包含新参数notifURI。新notifURI基本上告知托管节点(或中转节点)接收未来通知的地址。

图20示出了用于基于当前的oneM2M功能架构来实现对现有SUB CSF的建议想法以形成增强型订阅和通知(eSUB)CSF 2002的一个示例性实施例。

这个新的eSUB 2002支持所提出的SAGS 1002和/或NODS 1004服务。它也支持经由通告资源进行订阅。eSUB 2002可以驻留在IN-CSE、MN-CSE和/或ASN-CSE中。图21示出了oneM2M中的eSUB2002的两个示例性部署，其中所提出的eSUB将影响Mcc和Mca参考点上的消息交互。

在图21A中，订户是IN-AE，托管节点是MN-CSE，并且中转节点是IN-CSE，其是IN-AE的注册器CSE。eSUB 2002被包含在MN-CSE和IN-CSE两者中。MN-CSE中的eSUB只支持SAGS1002，而IN-CSE中的eSUB可以支持SAGS 1002和NODS 1004两者。通知接收方是IN-AE。

在图21B中，订户是ADN-AE，托管节点是IN-CSE，并且中转节点是MN-CSE，其是ADN-AE的注册器CSE。IN-CSE是MN-CSE的注册器CSE。eSUB被包含在MN-CSE和IN-CSE两者中。IN-CSE中的eSUB只支持SAGS 1002，而MN-CSE中的eSUB可以支持SAGS1002和NODS 1004两者。通知接收方是ADN-AE。

应当理解，图20-21中示出的功能可以用存储在M2M网络的设备的存储器中并在其上执行的软件(即计算机可执行指令)的形式来实现(例如，服务器，网关，设备或其他计算机系统)，例如下面描述的图23C或23D中所示的那些中的一个。

诸如图形用户界面(GUI)的界面可以用于显示和/或调整与订阅聚合有关的参数和/或结果。图22是示出了界面2202和2204的图。

可以将用户界面2202添加到托管节点(例如，M2M网关)以显示与订阅聚合有关的信息，例如由SAGS 1002和每个组的成员创建的订阅组。

用户界面2204还可以被添加到中转节点(例如，M2M服务器)以显示与订阅聚合和通知分发有关的信息，例如：

订阅组及其成员由SAGS 1002创建

通知组及其成员由NODS 1004创建

有关每个通知组的统计信息(例如成功分发给每个成员的通知数量)。

应该理解的是，界面2202和2204可以使用诸如下面描述的图23C-D所示的显示器来制造。

示例M2M/IoT/WoT通信系统

这里描述的各种技术可以结合硬件、固件、软件或者在适当的情况下其组合实现。这样的硬件、固件和软件可以驻留在位于通信网络的各个节点处的设备中。设备可以单独操作或者彼此组合以实现本文描述的方法。如本文所使用的，术语“设备”、“网络设备”、“节点”、“装置”和“网络节点”可以互换使用。

术语“服务层”是指网络服务架构内的功能层。服务层通常位于应用协议层之上，如HTTP、CoAP或MQTT，并为客户端应用提供增值服务。服务层还提供到较低资源层例如控制层和传输/访问层的核心网络的接口。服务层支持多种类型的(服务)能力或功能，包括服务定义、服务运行时启用、政策管理、访问控制和服务群集。最近，一些行业组织例如oneM2M已经开发了M2M服务层以解决与将M2M类型的装置和应用集成到诸如因特网/web、蜂窝、企业和家庭网络的部署中相关的挑战。M2M服务层可以向应用和/或各种装置提供对由服务层支持的上述能力或功能的合集或集合的访问，其可以被称为CSE或SCL。一些示例包括但不限于安全性、计费、数据管理、装置管理、发现、配置和连接性管理，这些可以被各种应用共同使用。这些能力或功能通过利用由M2M服务层定义的消息格式、资源结构和资源表示的API而被提供给这样的各种应用。CSE或SCL是可以由硬件和/或软件实现并且提供暴露于各种应用和/或装置(即这些功能实体之间的功能接口)的(服务)能力或功能以便使用这些能力或功能的功能实体。

图23A是其中可以实现一个或多个所公开的实施例的示例机器对机器(M2M)、物联网(IoT)或万物网(WoT)通信系统10的图。一般情况下，M2M技术为IoT/WoT提供构建模块，并且任何M2M装置、M2M网关、M2M服务器或M2M服务平台都可以是IoT/WoT的部件或节点或IoT/WoT服务层等。通信系统10可以用于实现所公开的实施例的功能，并且可以包括功能和逻辑实体，例如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE、802、804和806、SAGS 1002、NODS 1004 1004、订户、1006、1008和1010、包括eSUB CSF 2002的CSF、以及产生界面2202和2204的逻辑实体。

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

如图23A所示，M2M/IoT/WoT通信系统10可以包括基础设施域和场域。基础设施域是指端到端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终端装置18还可以从M2M应用20或M2M终端装置18接收数据。此外，如下所述，数据和信号可经由M2M服务层22发送到M2M应用20并从M2M应用20接收。M2M终端装置18和网关14可以经由包括例如蜂窝、WLAN、WPAN(例如Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线的各种网络进行通信。

示例性的M2M终端装置18包括但不限于平板电脑、智能电话、医疗装置、温度和天气监视器、连接的汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、家用电器、车库门和其他基于致动器的装置、安全装置和智能插座。

参照图23B，在场域中示出的M2M服务层22为M2M应用20、M2M网关装置14和M2M终端装置18以及通信网络12提供服务。通信网络12可以用于实现所公开的实施例中的功能并且可以包括功能和逻辑实体，例如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE 802、804和806、SAGS 1002、NODS 1004 1004、订户1006、1008和1010、包括eSUB CSF 2002的CSF和用于产生界面2202和2204的逻辑实体。可以通过一个或多个服务器、计算机、装置、虚拟机(例如，云/存储库等)来实现M2M服务层22等，包括例如下面描述的图23C和23D中所示的装置。应理解的是，M2M服务层22可以根据需要与任何数量的M2M应用、M2M网关14、M2M终端装置18和通信网络12进行通信。M2M服务层22可以由网络的一个或多个节点来实现，该节点可以包括服务器、计算机、装置等。M2M服务层22提供应用于M2M终端装置18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式来实现，例如作为网络服务器、蜂窝核心网、云中等。

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

还参照图23B，M2M服务层22和22'提供了多种应用和垂直可以发挥杠杆作用的集合核心业务传送能力。这些服务能力使得M2M应用20和20'能够与装置交互并且执行诸如数据收集、数据分析、装置管理、安全性、计费、服务/装置发现等功能。实质上，这些服务能力免除了应用实现这些功能的负担，从而简化应用开发并降低成本。服务层22和22'还使得M2M应用20和20'能够通过网络12与服务层22和22'提供的服务相结合地进行通信。

本申请的方法可以被实现为服务层22和22'的一部分。服务层22和22'是通过应用编程接口(API)和底层网络接口集合支持增值服务能力的软件中间件层。ETSI M2M和oneM2M都使用可能包含本申请的连接方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在M2M装置内实现(其中它被称为装置SCL(DSCL))、在网关内实现(其中它被称为网关SCL(GSCL))和/或在网络节点内实现(其中它被称为网络SCL(NSCL))。oneM2M服务层支持通用服务功能(CSF)(即服务能力)集合。一个或多个特定类型的CSF的实例的集合被称为公共服务实体(CSE)，其可以驻留在不同类型的网络节点(例如，基础设施节点、中间节点、应用特定节点)上。此外，本申请的连接方法可以作为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问诸如本申请的连接方法的服务的M2M网络的一部分来实现。

在一些实施例中，M2M应用20和20'可以与所公开的系统和方法结合使用。M2M应用20和20'可以包括与UE或网关交互的应用，并且还可以用于结合其他公开的系统和方法。

在一个实施例中，逻辑实体如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE 802、804和806、SAGS1002、NODS 1004 1004、订户1006、1008和1010、包括eSUB CSF 2002的CSF和用于产生界面2202和2204的逻辑实体可以被托管在由M2M节点例如M2M服务器M2M网关或M2M装置托管的M2M服务层实例内，如图23B所示。例如，逻辑实体如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE802、804和806、SAGS 1002、NODS 1004 1004、订户1006、1008和1010、包括eSUB CSF2002的CSF和用于产生界面2202和2204的逻辑实体可以包括M2M服务层实例内的单独服务能力或者作为现有服务能力内的子功能。

M2M应用20和20'可以包括各个行业的应用诸如但不限于交通、卫生和健康、联网家庭、能源管理、资产跟踪和安全监视。如上所述，装置跨越装置、网关、服务器和系统的其他节点运行的M2M服务层装置的支持诸如例如数据收集、装置管理、安全、计费、位置跟踪/地理围栏、装置/服务发现和旧系统整合的功能，装置装置并且向M2M应用20和20'提供这些功能作为服务。

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

此外，逻辑实体诸如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE 802、804和806、SAGS 1002、NODS 1004 1004、订户1006、1008和1010、包括eSUBCSF 2002的CSF和用于产生界面2202和2204的逻辑实体可以被实现为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问本申请的服务的M2M网络的一部分。

图23C是M2M网络节点30(例如，M2M装置18、M2M网关14、M2M服务器等)的示例硬件/软件架构的框图。节点30可以执行或者包括逻辑实体诸如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE 802、804和806、SAGS 1002、NODS 10041004、订户1006、1008和1010、包括eSUB CSF 2002的CSF和用于产生界面2202和2204的逻辑实体。装置30可以是如图23A-B所示的M2M网络的一部分，或者是非M2M网络的一部分。如图23C所示，M2M节点30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50以及其他外围装置52装置。节点30还可以包括通信电路，例如收发器34和发送/接收元件36。应理解的是，M2M节点30可以包括上述元件的任何子组合，而其余与实施例一致。该节点可以是实现在此描述的SMSF功能的节点。

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

如图23C所示，处理器32耦合到其通信电路(例如，收发器34和发送/接收元件36)。处理器32通过执行计算机可执行指令可以控制通信电路，以便使节点30经由其所连接的网络与其他节点进行通信。特别地，处理器32可以控制通信电路以便执行本文和权利要求中描述的发送和接收步骤。尽管图23C将处理器32和收发器34描述为分离的部件，但是应该理解，处理器32和收发器34可以一起集成在电子封装或芯片中。

发送/接收元件36可以被配置成发送信号到其他M2M节点或接收来自其他M2M节点的信号，所述节点包含M2M服务器、网关、装置等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，例如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是例如被配置为发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF和光信号两者。应理解，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任何组合。

另外，尽管发送/接收元件36在图23C中被描绘为单个元件，但是M2M节点30可以包括任何数量的发送/接收元件36。更具体地，M2M节点30可以采用MIMO技术。因此，在一个实施例中，M2M节点30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

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

处理器32可以访问来自诸如不可移除存储器44和/或可移除存储器46的任何类型的合适存储器的信息并将数据存储在所述存储器中。例如，处理器32可以将会话上下文存储在其存储器中，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储装置。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其他实施例中，处理器32可以访问来自物理上不位于M2M节点30上、诸如在服务器或家用计算机上的存储器的信息并将数据存储在该存储器中。处理器32可以被配置为控制显示器或指示器42上的照明模式、图像或颜色以反映M2M服务层会话迁移或共享的状态，或者获得来自用户的输入或者向用户显示关于节点的会话迁移或共享能力或设置的信息。在另一示例中，显示器可以示出关于会话状态的信息。本公开在oneM2M实施例中定义了RESTful用户/应用API。可以在显示器上示出的图形用户界面可以被层叠在API的顶部以允许用户经由在此描述的基础服务层会话功能来交互地建立和管理E2E会话或者其迁移或共享。

处理器32可以接收来自电源48的电力，且可以被配置成分配和/或控制所述电力到M2M节点30中的其他部件。电源48可以是用于向M2M节点30供电的任何合适的装置。例如，电源48可以包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)，太阳能电池、燃料电池等。

处理器32还可以耦合到GPS芯片组50，GPS芯片组50被配置为提供关于M2M节点30的当前位置的位置信息(例如，经度和纬度)。应理解，M2M节点30可以在保持与实施例一致的同时借助于任何合适的位置确定方法来获取位置信息。

处理器32还可以耦合到其他外设52，外设52可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，外设52可以包括加速度计、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口、振动装置、电视收发器、免提耳机、

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

图23D是也可以用于实现M2M网络的一个或多个节点(例如，M2M服务器、网关、装置或其他节点)的示例性计算系统90的框图。计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令来控制，计算机可读指令可以以软件的形式，无论何处或以何种方式存储或访问这样的软件。计算系统90可以执行或者包括逻辑实体如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2M AE 802、804和806、SAGS 1002、NODS 10041004、订户1006、1008和1010、包括eSUB CSF 2002的逻辑实体以及生成界面2202和2204的逻辑实体。计算系统90可以是M2M装置、用户设备、网关、UE/GW或任何其他节点，例如包括移动护理网络的节点、服务层网络应用提供商、终端装置18或M2M网关装置14。这样的计算机可读指令可以在诸如中央处理单元(CPU)91的处理器内执行，以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单片CPU实现。在其他机器中，中央处理单元91可以包括多个处理器。协同处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助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可以含有负责将指令从CPU 91传达到诸如打印机94、键盘84、鼠标95和磁盘驱动器85的外设的外设控制器83。

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

此外，计算系统90可以包含可用于将计算系统90连接到外部通信网络(例如图23A和图23B的网络12)的通信电路，例如网络适配器97，以使计算系统90能够与网络的其他节点通信。

用户设备(UE)可以是由终端订户进行通信的任何装置。它可以是手持电话、配备有移动宽带适配器的膝上型计算机或任何其他装置。例如，UE可以被实现为图23A-B的M2M终端装置18或者图23C的装置30。

应当理解，本文描述的任何或全部系统、方法和过程可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式来体现，所述指令在由包含例如M2M服务器、网关、装置等的诸如M2M网络的节点的机器执行时实行和/或实现本文描述的系统、方法和过程。具体地，以上描述的任何步骤、操作或功能可以以这种计算机可执行指令的形式来实现。逻辑实体如CSE 202、M2M服务器602、708、中转节点810和1802、托管节点808、M2MAE 802、804和806、SAGS 1002、NODS 1004 1004、订户1006、1008和1010、包括eSUB CSF2002以及用于产生界面2202和2204的逻辑实体可以以存储在计算机可读存储介质上的计算机可执行指令的形式来体现。计算机可读存储介质包括以用于存储信息的任何非暂时性(即，有形或物理)方法或技术实现的易失性和非易失性，可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、快闪存储器或其他存储器技术、CD-ROM、数字多功能光盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储装置，或者可以用于存储所需信息并且可以由计算机访问的任何其他有形或物理介质。

在描述本公开内容的主题的优选实施例中，如附图所示，为了简明，采用特定术语。然而，所要求的主题并非意在限制到如此选择的特定术语，但是应当理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等效物。

本书面描述使用示例来公开本发明，包括最佳模式，并且还使任何本领域技术人员能够实践本发明，包括制造和使用任何装置或系统，以及执行任何并入的方法。本发明的可取得专利的范围由权利要求限定，并且可以包括对本领域技术人员想到的其他示例。如果其他示例具有与权利要求的字面语言没有不同的元素，或者如果它们包含与权利要求的字面语言无实质区别的等同元素，则这些其他示例旨在落入权利要求的范围内。

Claims (12)

1.一种包括处理器和存储器的设备，所述设备还包括存储在所述设备的所述存储器中的计算机可执行指令，所述计算机可执行指令在由所述设备的所述处理器执行时使所述设备：

从托管节点接收与托管节点处的原始资源相关联的资源通告；

创建与原始资源对应的通告资源；

从第一订户接收第一订阅请求，第一订阅请求包括通告资源的标识符、第一事件通知标准和第一通知URI；

从第二订户接收第二订阅请求，第二订阅请求包括通告资源的标识符、第二事件通知标准和第二通知URI；

向托管节点发送聚合订阅请求，所述聚合订阅请求包括通告资源的标识符、第一事件通知标准、第二事件通知标准、第一通知URI和第二通知URI；

从托管节点接收与第一事件通知标准和第二事件通知标准对应的事件的通知；和

向第一通知URI和第二通知URI转发所述通知。

2.根据权利要求1所述的设备，其中所述设备是与托管节点通信的中转节点。

3.根据权利要求1所述的设备，其中通告资源指向所述托管节点处的原始资源。

4.根据权利要求1所述的设备，其中所述通知包括对托管节点处的原始资源的更新的通知。

5.根据权利要求1所述的设备，其中第一事件通知标准与第二事件通知标准相同。

6.根据权利要求1所述的设备，其中所述计算机可执行指令还使所述设备：

响应于接收到第一订阅请求和第二订阅请求，创建包括第一通知URI和第二通知URI的订阅组。

7.一种由设备使用的方法，所述方法包括：

从托管节点接收与托管节点处的原始资源相关联的资源通告；

创建与原始资源对应的通告资源；

从第一订户接收第一订阅请求，第一订阅请求包括通告资源的标识符、第一事件通知标准和第一通知URI；

从第二订户接收第二订阅请求，第二订阅请求包括通告资源的标识符、第二事件通知标准和第二通知URI；

向托管节点发送聚合订阅请求，所述聚合订阅请求包括通告资源的标识符、第一事件通知标准、第二事件通知标准、第一通知URI和第二通知URI；

从托管节点接收与第一事件通知标准和第二事件通知标准对应的事件的通知；和

向第一通知URI和第二通知URI转发所述通知。

8.根据权利要求7所述的方法，其中所述设备是与托管节点通信的中转节点。

9.根据权利要求7所述的方法，其中通告资源指向所述托管节点处的原始资源。

10.根据权利要求7所述的方法，其中所述通知包括对托管节点处的原始资源的更新的通知。

11.根据权利要求7所述的方法，其中第一事件通知标准与第二事件通知标准相同。

12.根据权利要求7所述的方法，还包括：

响应于接收到第一订阅请求和第二订阅请求，创建包括第一通知URI和第二通知URI的订阅组。

Images