订阅和通知服务的制作方法

对于相关申请的交叉引用

本申请要求优先权权益于在2016年7月14日提交的题为“SUBSCRIPTION AND NOTIFICATION SERVICE(订阅和通知服务)”的美国临时专利申请No.62/362,266，该申请的内容由此通过引用并入于此。

背景技术

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

M2M服务层是一种类型的服务层的示例，其特别针对为M2M类型的设备和应用提供增值服务。最近，若干行业标准组织(例如，oneM2M功能架构)一直在开发M2M服务层，以解决与将M2M类型的设备和应用集成到诸如因特网/Web、蜂窝、企业和家庭网络的部署中相关的挑战。

M2M服务层可以向应用和设备提供对服务层支持的面向M2M的能力的集合的访问。一些示例包括安全性、计费、数据管理、设备管理、发现、配置和连接管理。这些能力通过应用编程接口(API)提供给应用，这些API利用M2M服务层定义的消息格式、资源结构、资源表示和函数调用。例如，M2M服务层可以保持大量M2M数据，M2M应用可以基于其访问权限来检索或订阅所述大量M2M数据。基于订阅的数据访问可能比基于检索的数据访问更有效，因为在对订阅的资源进行期望的改变之前，它不向M2M应用引入任何消息。然而，成本是M2M应用需要首先进行订阅才能从M2M服务层接收自动通知。

oneM2M是提供技术规范的标准，所述技术规范解决了对可以容易地嵌入在各种硬件和软件中的公共M2M服务层的需求，并且可以被依赖来将现场中的各种设备与全球的M2M应用服务器连接。

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

oneM2M开发了图3中所示的面向资源的架构(Resource Oriented Architecture：ROA)。在ROA架构中，资源是架构中的唯一可寻址元素，具有可通过RESTful方法(如创建、检索、更新和删除)进行操纵的表示。使用统一资源标识符(URI)可以使这些资源可寻址。资源可以包含子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其子资源的引用。子资源的生命周期受父资源生命周期的限制。每个资源都支持一组存储资源信息的“属性”。

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

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

SUB CSF根据访问控制策略(ACP)管理对资源的订阅，并且将相应的通知发送到资源订户想要接收它们的地址。AE或CSE是订阅资源订户。AE和CSE订阅其他CSE的资源。订阅托管CSE在对资源进行修改时向资源订户指定的一个或多个地址(或通知目标)发送通知。资源订阅的范围包括跟踪订阅资源的属性和直接子资源的更改和操作。它不包括跟踪子资源的属性的更改。每个订阅可以包括通知标准，其指定发送哪些通知、何时发送通知和如何发送通知。这些通知标准可以与oneM2M的通信管理和递送处理(CMDH)策略结合使用。订阅在CSE资源结构中表示为资源<subscription>。

总之，SUB CSF支持的功能如下：oneM2M功能架构：1)包含ID；2)订阅资源的能力；3)订户发送通知的请求；4)缓存丢失的通知的请求；5)接收通知的请求率限制；或5)通知目标被从CSE中删除。

更详细地，可以按照资源订阅请求来完成资源订户ID的包括、托管CSE-ID和订阅的资源地址。它还可以包括其他标准(例如，感兴趣的资源修改和通知策略)以及发送通知的一个或多个地址。

能够通过单个订阅订阅单个资源，或者当多个资源被分组并表示为单个组资源时，通过单个订阅订阅该多个资源。当订户订阅一组资源时，相同的事件通知标准用于该组中的所有资源；反过来，托管CSE可以每当发生对个体(非全部)资源的改变时生成通知。

订户可以请求托管CSE批量发出通知消息而不是一次发送一个通知消息。订户可以指示应该将多少通知消息一起批处理。

订户可以请求托管CSE由于不可用连接(例如，到订户)的时段而缓存丢失的通知。在连接变得可用后，托管CSE可以向订户发送最新的待处理通知或所有待处理通知。订户可以指示其接收通知的速率限制。并且，通知目标可以请求托管CSE将其从用于接收通知的目标列表中移除。

在oneM2M中，订户可以是AE或CSE，而托管节点必须是CSE。例如，作为订户的IN-AE可以订阅由IN-CSE(即，托管节点)托管的资源。图4示出了根据oneM2M规范的示例过程，其中，IN-AE1对IN-CSE上的资源(例如，<subscribed-to-resource>)进行订阅。为此，IN-AE1发出CREATE请求以在<subscribed-to-resource>下创建<subscription>资源(即步骤A)；IN-AE1可以在此步骤中指示eventNotificationCriteria和多个notificationURI。eventNotificationCriteria示出IN-AE1感兴趣于关于<subscribed-to-resource>的哪些事件。可以将通知发送到如notificationURI(即，本示例中为订户的notificationURI1和另一通知目标的notificationURI2)所示的订户(例如，IN-AE1)或通知目标。作为托管CSE的IN-CSE将在从步骤A接收到订阅请求之后首先创建<subscription>作为<subscribed-to-resource>的子资源。之后，当事件发生并且满足步骤A中包含的eventNotificationCriteria时，IN-CSE将自动分别向订户和通知目标发送两个通知(即步骤E和步骤F)。请注意，步骤A中的订阅请求可能包含多个notificationURI，这意味着订户正在请求将来的通知发送到多个通知目标。在这种情况下，eventNotificationCriteria是相同的并适用于所有notificationURI。尽管未在图中示出，但是当使用batchNotify属性时，oneM2M支持托管CSE执行批量通知，其中，托管CSE可以在一个消息中向同一notificationURI发送多个通知。

技术实现要素：

在M2M/IoT域中，资源订阅提供了在订阅资源上发生改变时接收自动通知的机制。传统的M2M服务层(例如，oneM2M)支持将订阅通知发送到节点列表(例如，通知目标)。订阅实体可以包括或不包括为通知目标。传统的M2M服务层不包括对关于过去通知的信息的访问，这当订户不在通知目标中时可能是有问题的。另一个问题可能是服务层也不知道有关通知目标的情境信息。基于上述问题，可能存在效率低下，例如向不可用或过载的通知目标发送不必要的通知。

本文公开了用于订阅和通知服务的方法和系统。例如，所公开的主题可以允许基于通知目标状态动态改变通知行为，以减少丢失的或不必要的通知的数量，或者支持以不同的粒度访问通知历史信息，等等。

在第一示例性方法中，服务层通过主动地或响应于订户的请求创建新的通知资源来记录发布通知。订户和通知目标可以访问所创建的通知资源以获得关于过去通知的信息。订户还可以自由停止或更改通知记录。在第二示例性方法中，服务层保持已发布通知的统计信息。订户可以访问这样的通知统计信息。基于该信息，订户可以请求服务层移除现有通知目标或添加新的通知目标。在第三示例性方法中，例如在发出通知并将其发送到通知目标之后，服务层在特定条件下向订户发送通知确认消息。

在第四示例性方法中，订户直接与通知目标交互以请求它们计算通知统计信息或将通知确认发送回订户。在第五示例性方法中，服务层可以在完全执行订阅请求之前联系通知目标，以使通知目标知道订户和相应的订阅。此外，通知目标可以主动或被动地将其情境状态信息报告给服务层，使得服务层知道其最新状态并且可以确定发送未来通知的有效方式。

附图说明

可以通过以下结合附图通过示例给出的描述来获得更详细的理解，在附图中：

图1示出了具有服务层的示例性IP网络堆栈；

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

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

图4示出了根据oneM2M规范的示例性方法，其中，IN-AE1对IN-CSE上的资源进行订阅；

图5示出了用于智能医疗保健用例的示例性系统；

图6示出了这里讨论的示例性方法的概述，例如其中，订户首先指示其对服务层记录通知、计算通知统计信息，以及在订阅请求期间确认通知的要求；

图7示出了用于订阅和通知服务的方法的示例性概要；

图8示出了用于记录和访问关于过去通知的信息的示例性方法；

图9示出了停止或更改通知记录的示例性方法；

图10示出了用于保持和访问通知统计信息的示例性方法；

图11示出了用于从服务层向订户发送通知确认的示例性方法；

图12示出了订户直接请求通知目标计算通知统计信息的示例性方法；

图13示出了订户从通知目标请求通知确认的示例性方法；

图14示出了用于在通知目标和订户之间以及在通知目标和服务层之间实现认知的示例性方法；

图15示出了示例性增强订阅和通知(eSUB)CSF；

图16示出了示例性<notification>资源；

图17示出了示例性<notifTarget>资源；

图18示出了示例性用户界面；

图19示出了可以基于这里讨论的方法和系统生成的示例性显示器(例如，图形用户界面)；

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

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

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

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

具体实施方式

本文公开了用于订阅和通知的机制，其可以包括：基于通知目标状态动态地改变通知行为，以便减少丢失或不必要的通知的数量或者支持以不同粒度访问通知历史信息，等等。所公开的订阅和通知服务可能对订户、服务层或通知目标产生影响。如本文所讨论的，传统M2M服务层(例如，oneM2M)中的资源订阅和通知机制具有诸如以下的问题：1)订户或通知目标没有方式或者以低效的方式来访问关于过去生成的通知的信息；或者2)通知目标不知道订阅，并且服务层不知道通知目标的情境信息。这些问题可能会导致不必要的通知，并使资源订阅和通知机制效率低下。在一个示例中，通知可以是当满足事件通知标准的订阅资源发生变化时由M2M服务层生成的消息；通知消息被发送给订户或通知目标以向它们通知该改变。

图5示出了智能医疗保健场景，其中，收集来自患者的身体传感器151的健康数据。健康数据可以被上载到M2M服务器153(或者可选地，本地存储在与患者相关联的移动设备152上)，M2M服务器153可以被称为托管节点。通过设备155，患者的监护人可以对健康数据进行订阅160，以便作为通知目标的患者的医生、护理人员、亲属和保险公司的相关设备(分别是设备156、157、158和159)等接收关于患者健康数据的变化的自动通知161。例如，如果患者目前正在家中接受治疗，则患者心率的突然增加可能是医生要知道的至关重要的内容。

在该智能医疗保健场景中，对资源订阅和通知可能存在以下要求：1)要求(Req)1：每当感兴趣的事件发生时，验证通知由M2M服务器153发出并且被通知目标(例如，设备156-159)接收(监护人-设备155可能请求此要求)；2)要求2：发送到每个通知目标和被每个通知目标成功接收的通知量(监护人-设备155可能请求此要求)；3)要求3：当通知目标没有连接到因特网或M2M服务器153时，不使得设备156(例如，医生设备)丢失任何通知；4)要求4：接收关于患者(或甚至一些选定的患者)的通知，没有其他未知的患者或个人(例如，可能仅适用于医生设备)；5)Req5：预期每个发送的通知由通知目标接收(这可以通过M2M服务器153被请求)。可能需要Req5，因为如果没有接收到每个通知，则可能浪费带宽，导致开销，并且显著影响通知有用性。

作为服务层技术的oneM2M在支持诸如医疗保健场景中的上述五个要求之类的要求方面具有有限的能力。例如，在传统的oneM2M中，诸如AE的订户不知道通知目标是否发出并成功接收到通知。另外，无论订阅来自哪个订户，传统oneM2M中的通知目标都被动地从服务层接收通知(例如，响应消息)。

传统M2M服务层中的订阅或通知机制(例如，oneM2M)可能具有以下问题。第一个问题可能是虽然M2M服务层(例如，M2M服务器153)可以自动生成通知，但是它不向订户(例如，设备155)或通知目标(例如，设备156)提供对关于在过去发布的通知的信息的任何访问。由于订户(例如，设备155)可能想要知道所有或选择的通知目标是否确实发出和接收了紧急通知，因此无法访问过去的通知可能是一个问题；此外，离线通知目标(例如，设备156)可能想要在其变为在线之后知道并获得任何丢失的通知。例如，在智能医疗保健场景中，设备155想知道设备156是否已经成功接收到关于患者的突然心率增加的通知。该第一个问题涉及Req1-Req3的上述要求。

第二个问题可能是M2M服务层不知道关于通知目标的情境信息(例如，它们的可用性、它们的新IP地址等)。例如，这种不知道可能导致从M2M服务层到过载的通知目标的不必要的通知。该第二个问题涉及Req3-Req5的上述要求。

应理解，执行诸如图6-图14的本文所示步骤的实体可以是逻辑实体。这些步骤可以存储在诸如图20C或图20D所示的那些的设备、服务器或计算机系统的存储器中，并在所述设备、服务器或计算机系统的处理器上执行。在一个示例中，下面使用关于M2M设备的交互的进一步细节，图6-图14的的订户173或通知目标175可以驻留在图20A的M2M终端设备18上，而图6-图14的服务层171可以驻留在图20A的M2M网关设备14上。

以下讨论用于订户和通知目标访问关于过去通知的信息的不同手段以及支持通知目标状态认知的方法。图6示出了与第一问题相关联的示例性方法的概述。在步骤181，服务层171(例如，M2M服务器153)可以从订户173(例如，监护人-设备155)接收订阅请求。订阅请求181可以指示对服务层171记录通知、保持通知统计信息以及确认关于通知目标175(例如，医生-设备156)的通知的要求。在步骤182，服务层171接收事件的指示。在可以响应于步骤182的步骤183，服务层171向通知目标175发送通知。步骤184至步骤185(这将在本文中更详细地讨论)涉及基于在步骤181中发送的来自订户173的要求的服务层动作。在步骤184，存在通知的记录。在步骤185，计算与通知相关联的统计信息。在步骤186，确认发送给订户173的通知。在步骤187或步骤188，分别从订户173或通知目标175访问过去的通知或通知统计信息。

继续参考图6，总而言之，这里讨论的方法可以包括其中订户173首先指示其对服务层记录通知、计算通知统计信息以及在订阅请求期间确认通知的要求。当事件发生时，服务层171可以进行动作(例如，记录通知)，并且通知消息被发出。如果服务层171记录通知或保持通知统计信息，则订户173或通知目标175可以主动访问它们。

在第五种方法中，订户171直接请求通知目标175计算通知统计信息或在其从服务层171接收一个或多个通知消息时发送通知确认。图7示出了方法流程的示例性摘要。订户173首先根据哪个服务层171将联系通知目标175以确认来自订户的订阅请求来指示其对订阅确认的要求(步骤191)；这使得通知目标175知道订阅(步骤192)。在步骤192，服务层171接收事件的指示。在可以响应于步骤182的步骤193，服务层171向通知目标175发送通知。然后，通知目标175可以将其状态或情境信息报告给服务层171，这可以包含在响应消息中(步骤195)或在单独的消息中(步骤196)；这(步骤195或步骤196)使服务层171能够知道通知目标175的状态。

参考与图6的步骤184相关联的方法，尽管在oneM2M中托管CSE可以缓存丢失的通知，但是托管CSE不将它们暴露给订户173或通知目标175，因此订户173或通知目标175不知道已经丢失了通知。换句话说，订户173或通知目标175可能不会在传统的oneM2M系统中主动从托管CSE检索或删除丢失的通知。

参考与图6的步骤185相关联的方法，oneM2M不支持计算和向用户173或通知目标175暴露通知统计信息。参考与图6的步骤186相关联的方法，oneM2M不支持向订户173发送通知确认。传统的oneM2M不支持订户173或通知目标175之间的直接交互。此外，参考图7，传统的oneM2M不支持订户173或通知目标175之间的认知。

以下讨论用于访问与通知相关联的信息的方法。订户173或通知目标175可能想要出于各种目的访问关于先前通知的信息。这里的方法可以独立地工作或对于与订阅和通知相关联的服务一起工作。

图8示出了用于记录和访问关于过去通知的信息的示例性方法。总之，对于该方法，服务层171可以主动记录每个发布的通知以供稍后由订户173和通知目标175检索。或者，订户173可以请求服务层171记录所选择的通知(例如，将所有通知记录到特定通知目标175，记录已成功接收通知消息的通知目标的列表)。它通常可以以下列方式工作。首先，订户173在订阅请求中指示其对记录通知的要求。随后，每当服务层171发出通知时，服务层171根据来自订户173的要求确定是否需要记录该通知。如果答案为是，则服务层171创建用于记录该通知的新资源。该新资源可以称为通知资源。通知资源具有关于所发布的通知的一些属性(例如，其生成时间、其生成条件、对相应订阅的引用、已成功接收该通知的通知目标的列表等)。最后，订户173或通知目标175可以访问由服务层171创建并保持的这种通知资源。服务层171可以使用特定访问控制策略来授权订户173、通知目标175或其他服务层实体是否可以访问这些通知资源。对于订户173，对通知资源的访问可以允许其知道通知目标175已经发出并成功接收了多少通知。对于通知目标175，服务层171提供的特征为通知目标175提供了稍后检索当通知目标175离线或不可用时(例如，由于其地址改变或失去与服务层171的连接而导致通知目标175变得不可达)丢失的通知的机会。另外，在检索并且知道关于过去通知的信息之后，如果订户173在一时间段内没有接收到通知，则订户173可以向服务层171发送请求以移除通知目标175，使得服务层171将来不再发送更多通知，这可以避免或减少不必要的通知。此外，订户173可以向服务层171发送请求消息以停止记录通知或改变应该如何记录通知。

继续参考图8，下面是用于记录和访问关于过去通知的信息的示例性逐步讨论。在步骤201，订户171可以向服务层171发送订阅请求消息。除了诸如事件通知标准之类的信息之外，该消息可以包含复合参数“notifRecordReq”，其由若干其他参数或字段组成。复合参数包括多个字段——每个字段是参数，如表1中所定义和所示。该参数可以告知服务层171应当何时、如何记录发布的通知或应当记录哪些发布的通知。表1定义了“notifRecordReq”。例如，订户173可以在步骤203之后用服务层171更新其资源订阅。在这种资源订阅更新中，订户173也可以包括“notifRecordReq”。每当服务层171接收到新的“notifRecordReq”时，服务层171可以用于确定要记录的未来通知。如果订户173没有提供关于通知记录要求的足够信息，则服务层171可以基于其本地策略决定记录通知。在步骤202，服务层171可以接受该请求并相应地创建订阅资源。在步骤203，服务层171向订户173发送响应以向其通知创建的订阅资源。在步骤204，发生事件，其满足步骤201中提供的事件通知标准。

继续参考图8，在步骤205，服务层171发出通知消息，该通知消息被发送到通知目标175。在步骤206，通知目标175发回响应。在步骤206，根据与步骤201的“notifRecordReq”相关联的信息，服务层171确定是否创建新的通知资源以记录在步骤206中发送的通知消息。例如，如果notifRecordReq要求记录每个通知消息，服务层171可以为任何发布的通知创建通知资源。每个创建的通知资源可以具有属性，诸如发布通知消息的时间、触发通知消息的通知条件、与通知消息相关联的订阅资源、已成功接收通知消息的通知目标175的列表或者丢失通知消息的通知目标175的列表，等等。每个创建的通知资源可能具有到期时间；当到期时间到期时，将自动删除创建的通知资源。一旦创建了通知资源，订户或通知目标就可以检索它。例如，图8中的步骤208示出了通知目标175检索该创建的通知资源。

在图8中，在步骤208，假设例如通知目标175离线一时间段，当通知目标175重新在线时，它可以主动从服务层171检索任何丢失的通知。由于通知目标175可能不知道是否存在正在创建的通知资源，则它可以仅向服务层171发送资源发现请求，以询问例如是否在过去的时间间隔内为其(通知目标175)发布了通知。如果通知目标离线并且没有接收到步骤205，则它不知道在步骤207中是否创建了通知资源。通知目标175还可以提供额外的发现标准(例如，发现任何已发布但未成功接收的通知消息，其通过特定通知条件被触发)。在步骤209，服务层171可以向通知目标175发送响应消息。响应消息可以包含已经发布但尚未被通知目标175成功接收的多个通知消息，或者满足通知目标175在步骤208指示的发现标准的通知消息列表。在步骤210，订户173发送主动检索(或删除)由服务层171创建的通知资源的请求。该步骤类似于步骤208。不同之处在于在步骤210，订户173可以在订户173从服务层171发现通知资源之后并且在一些条件下(例如，相应的通知消息被所有或优选的通知目标175成功接收)请求删除通知资源以减少服务层171处的存储。在步骤211，服务层171向订户173发送响应。如果步骤210中的请求是检索通知资源，则步骤211将类似于步骤209，并且响应可以包含多个通知消息。如果步骤210中的请求是删除通知资源，则步骤211中的响应可以仅通知删除请求的结果(例如，批准或拒绝)。

表1.复合参数notifRecordReq

图8示出了订户173可以请求服务层171记录通知。订户173还可以请求服务层171停止或改变通知记录，如图9所示。可以理解，其他实体也可以在它们拥有访问权限时请求停止或更改通知记录。限制访问可能有不同的原因，例如某些隐私问题。

继续参考图9，在步骤221，订户173向服务层171发送请求消息以停止记录通知。该消息可以仅指示相应或相关联的订阅。或者，订户173可以包括参数，例如无效notifRecordTimeDuration，其作为指示停止通知记录的消息中的notifRecordReq(例如，[-20，-10])的一部分。在步骤222，服务层171向订户173发送响应，该响应指示步骤221中的请求是被批准还是被拒绝。在步骤223，订户173还可以向服务层171发送请求消息，以改变应该如何记录未来通知。该消息可以包含参数“notifRecordReq”的新值。如果先前停止了通知记录，则步骤223处的该请求可以间接地恢复通知记录。所记录的通知资源可以被订户173主动删除或者因为每个通知资源具有相关联的到期时间而到期。在步骤224，服务层171向订户173发送响应，该响应指示步骤223中的请求是被批准还是被拒绝。

以下讨论用于在服务层171保持通知统计信息的方法和系统。服务层171可以保持关于在时间窗口期间发出的过去通知的统计信息而不是每个单个通知。注意，时间窗口可以是基于发布通知消息的时间的实时窗口，或者是仅包含固定数量的通知消息的虚拟时间窗口。统计信息的示例可以包括时间窗口中发布的通知的平均数量、通知目标175在时间窗口中成功接收的通知的数量、在时间窗口中通知目标175的连续不成功通知的最大数量或者特别通知目标175的不成功通知尝试次数，等等。订户173可以请求服务层171在订阅请求期间计算通知统计信息的一个或多个参数。然后，每当发出新通知并将其发送到通知目标175时，服务层171可以继续重新计算通知统计信息。一旦服务层171生成通知统计信息，订户173就可以检索它并基于通知统计信息，它可以决定移除通知目标175(例如，如果通知目标175已经丢失了最近发出的全部或高百分比的通知)或者添加新的通知目标175(例如，如果通知目标175的全部或高百分比不能接收到任何通知)。这样，将从订户173向服务层171发送单独的请求消息以调整(移除或添加)通知目标175。在另一示例中，服务层171可以基于来自订户173或其他实体的请求对于特定订阅执行通知统计信息的一次性按需计算；如果对通知统计信息的请求非常少，则这种按需通知统计信息计算可能更有效。

图10示出了用于保持和访问通知统计信息的示例性方法。在步骤231，订户173向服务层171发送订阅请求消息。步骤231的请求可以包括诸如事件通知标准之类的信息以及参数“notifStatReq”。该notifStatReq参数可以包括用于要计算或保持的通知统计信息的指令。表2定义了notifStatReq。订户173可以在步骤233之后通过服务层171更新其资源订阅。在资源订阅更新中，订户173可以包括“notifStatReq”，即使它包括在步骤231中。每当服务层171接收新的“notifStatReq”，服务层时171将用它来计算未来的通知统计信息。在步骤232，服务层171接受该请求并相应地创建订阅资源。在步骤233，服务层171向订户173发送响应，该响应提供关于订阅资源的创建的信息。响应消息还可以包括“notifStatInfo”的地址，尽管将在步骤237中(重新)计算它，使得订户173能够在步骤238中使用该地址直接检索“notifStatInfo”。

在步骤234，发生满足步骤231中提供的事件通知标准的事件。在步骤235，服务层171向通知目标175发送通知消息。在步骤236，通知目标175发回响应。在步骤237，服务层171根据由参数“notifStatReq”指示的订户173的要求(重新)计算通知统计信息。计算的通知统计信息保持在新参数“notifStatInfo”中，该新参数可以被创建为新的资源或作为新属性添加到在步骤232中创建的订阅资源。或者，服务层171例如如果它具有足够的存储则可以保持所有计算的通知统计信息，而不仅是最新的。

在步骤238，订户173从服务层171检索(或如果它不知道“notifStatInfo”的地址则发现)“notifStatInfo”。在步骤239，服务层171向订户173发回响应(例如，“notifStatInfo”的值)。在步骤240，订户173可以基于通知统计信息决定移除或添加任何通知目标175。在示例中，如果通知目标175已经丢失了在当前时间窗口内发出的通知的全部或阈值百分比，则订户173可以决定移除通知目标175。在另一个示例中，如果通知目标的全部或者阈值百分比无法在当前时间窗口内接收任何通知，可以添加新通知目标175。在步骤241，订户173可以根据在步骤240中做出的决定向服务层171发送请求以调整(例如，移除、添加或否则调整)通知目标175。在步骤242，服务层171发送结果(例如，接受或拒绝调整)给订户173。

表2.notifStatReq的定义

下面讨论的是从服务层171到订户173的通知确认。除了记录通知或计算通知统计信息之外，另一种方法是让订户173访问关于过去通知的信息。当向一个或所有通知目标发送通知时，服务层171可以主动向订户173发送通知确认。基本上，在通知目标175成功接收到通知消息之后，服务层171可以向订户173发送通知确认消息以向其通知该通知消息。如果存在多个通知目标，则可以多次发送相同的通知消息。为了减少通知确认消息的数量，服务层171可以在向所有通知目标发送相同的通知消息之后仅向订户173发送一个通知确认消息。此外，当已经将特定数量的通知消息发送到一个或所有通知目标时，订户173可以请求服务层171发送通知确认消息。与上述方法类似，订户173可以基于来自通知确认的信息来调整(例如，移除、添加或否则调整)通知目标。

图11示出了用于从服务层171向订户173发送通知确认的示例性方法。在步骤251，订户173向服务层171发送订阅请求消息。除了诸如事件通知标准之类的信息之外，步骤251的消息可以包括：参数“notifConfirmReq”。该notifConfirmReq参数告知服务层171应该与订户173确认哪些通知。表3定义了该复合参数。订户173可以在步骤253之后用服务层171更新其资源订阅。在资源订阅更新中，订户173也可以包括“notifConfirmReq”，即使它包括在步骤251中。每当服务层171接收到新的“notifConfirmReq”时，服务层171可以使用它来确认将来的通知。在步骤252，服务层171接受该请求并相应地创建订阅资源。在步骤253，服务层171向订户173发送响应以向其通知创建的订阅资源。

参考图11，在步骤254，发生事件，其满足步骤251中包含的事件通知标准。在步骤255，服务层171向通知目标175发送通知消息。在步骤256，通知目标175发回响应，其告知服务层171成功接收到在步骤255的通知。在步骤257，服务层171存储通知消息并基于“notifConfirmReq”确定是否需要向订户173发送通知确认。在步骤258，服务层171向订户173发送通知确认消息。该消息可包含已成功发送到通知目标的一条或多条通知消息。

在步骤259，订户173将响应发送回服务层171；步骤259的响应只是简单地告诉服务层175成功接收到步骤258的通知确认。在步骤260，订户173可以决定移除或添加通知目标175。在关于移除通知目标175的示例中，如果通知目标175已经丢失了在时间窗口内发出的全部或阈值百分比的通知，则可以移除通知目标175。在关于添加通知目标175的示例中，如果全部或高百分比的其他通知目标在当前时间窗口内不能接收任何通知，则可以添加通知目标175。在步骤261，订户173根据在步骤260中作出的决定向服务层171发送请求以调整通知目标。在步骤262，服务层171将结果(例如，接受或拒绝调整)发送给订户173。

表3.notifConfirmReq的定义

先前的方法向服务层171引入新特征，并依赖于它来向订户173或通知目标提供对于关于通知的信息的访问。以下公开了订户和通知目标之间的直接交互。这些交互可以被认为是应用级交互，因为订户173和通知目标在大多数情况下将是应用。然而，该替代方法可能无助于服务层171避免发送不必要的通知，并且可能不提供用于通知目标175检索丢失的通知的指令。订户173和通知目标175之间的直接交互可以包括：1)订户173请求通知目标175计算关于其从服务层171接收的通知的统计信息，并且可以将计算的统计信息主动地报告回订户173或被动地报告等待订户173检索；并且，2)订户173请求通知目标175为其从服务层171接收的每个或多个通知发送通知确认。

图12示出了订户173直接请求通知目标175计算通知统计信息的示例性方法。在步骤270，假设已在订户173和服务层171之间完成订阅请求。在步骤271，订户173向通知目标175发送请求消息，以通知它需要计算哪种通知统计信息。在该消息中，包含参数notifStatReq以指示订户173对通知统计计算的要求。在表2中定义notifStatReq。在步骤271，通知目标175将响应发送回订户173。在步骤271的该消息中，通知目标175可以包括将在步骤274中计算的通知统计信息的URI，因此订户173可以稍后主动检索通知统计信息(例如，在步骤277中)。在步骤273，当在服务层171处对订阅资源发生感兴趣事件时，服务层171向通知目标175发送通知消息。

在步骤274，通知目标175根据在步骤271中接收的notifStatReq(重新)计算通知统计信息。计算的通知统计信息可以存储在复合参数或占位符中，称为“notifStatInfo”。在步骤275，通知目标175将所计算的统计信息报告给订户173。在该消息中，通知目标175可以包括通知统计信息的URI，使得订户173可以稍后主动检索通知统计信息(例如，在步骤277中)。

继续参考图12，在步骤276，订户173将响应作为确认发送回通知目标175。在步骤277，订户173使用从步骤272或步骤275获得的通知统计信息的URI从通知目标175主动检索通知统计信息。在步骤277，通知目标175将响应发送回订户173。

图13示出了订户173从通知目标175请求通知确认的示例性方法。主要思想是，一旦通知目标175从服务层171接收到一个或多个通知消息，它将向订户173发送通知确认消息。在步骤280，假设已在订户173和服务层171之间完成订阅请求。在步骤281，订户173向通知目标175发送消息，请求它在从服务层171接收到通知消息时发回通知确认。该消息可以包括参数notifConfirmReq，以指示订户173对通知确认的要求。已在表3中定义notifConfirmReq。对于该示例，存在一个通知目标175，notifConfirmReq的“listOfNotifTargetsForConfirm”字段将是在该步骤中接收消息的通知目标175。在步骤282，通知目标175向订户173发送响应消息作为确认。在步骤283，当在服务层171处对订阅资源发生感兴趣事件时，服务层171向通知目标175发送通知消息(例如，事件通知消息)。在步骤284，通知目标175向订户173发送通知确认。该消息可以类似于图11中的步骤258。通知目标175可以在它从服务层171接收到一个通知或多个通知之后发出该消息，在接收的参数notifConfirmReq中指定该通知。在步骤285，订户173将响应作为确认发送回通知目标175。

这里描述的问题是服务层171不知道关于通知目标的状态。以下公开了与保持服务层171知晓相关联的方法和系统。总之，首先，服务层171在从订户173接收到新的订阅请求之后，检查相应的通知目标并使它们知道要创建的这个新订阅；在该过程期间，通知目标175可以要求服务层171将其从该新订阅中移除或者指示服务层171应当如何适当地向其发送通知。这有助于解决关于订阅的通知目标175的缺乏知晓。其次，在创建新订阅之后，通知目标可以主动向服务层171报告它们的状态(例如，可用性、预期通知速率等)，并将它们的状态捎带在对于服务层171的响应消息中；反过来，服务层171可以根据通知目标的最新状态来调整应该如何发送未来通知。

图14示出了用于启用在通知目标和订户173之间以及通知目标和服务层171之间的认知的示例性方法。在步骤291，订户173向服务层171发送订阅请求消息。除了诸如通知(例如，事件通知)标准之类的信息，该消息可以包括参数“subConfirmReq”。该subConfirmReq参数告知服务层171应该联系哪个通知目标175以确认订阅请求。表4定义了subConfirmReq。在步骤292，如果subConfirmReq中的subConfirmType不等于零，则服务层171向相应的通知目标发送订阅确认消息。该消息可以包括以下参数或者仅包括步骤291中的订阅请求消息：1)订户173的地址或标识符；2)订阅资源的地址或标识符；3)通知目标17接收通知5的地址；或4)事件通知标准。

在步骤293，通知目标175向服务层171发送回响应。如果通知目标175不愿意接收该订阅的通知，则它可以要求服务层171将其从由订户173在步骤291中提供的通知目标列表中删除。此外，通知目标175还可以在其响应消息中捎带其当前状态(例如，“notifTargetStatus”)。“notifTargetStatus”可以包括关于通知目标175的以下情境信息：1)用于接收未来通知的通知目标175的新网络(例如，IP)地址；2)允许最大通知到达速率(例如，2个通知/秒)；或3)该通知目标175的时间表信息(例如，将在接下来的30天内可用，将在接下来的2天内不可用，等等)。在步骤294，服务层创建订阅资源。在步骤295，服务层171向订户173发送响应以向其通知创建的订阅资源。如果通知目标175在步骤293期间请求被移除，则服务层171可以在该步骤295中包括该通知目标175的地址或标识符。在步骤296，发生事件，其满足步骤291中包含的事件通知标准。在步骤297，服务层171向通知目标175发送通知消息。注意，如果通知目标175在步骤293中指示“允许的最大通知速率”，则如果违反了“允许的最大通知速率”，则服务层171可以不向其发送该通知消息。还要注意，如果该通知是向通知目标175发出的第一通知，则步骤292中的订阅确认消息可替代地包含在步骤297中。在这种情况下，可以跳过步骤292和步骤293。

继续参考图14，在步骤298，通知目标175发送回响应，该响应可以包含通知目标175状态信息(例如，notifTargetStatus)。在步骤299，通知目标175的状态可以改变。例如，其先前用于接收通知的地址变得不可用。在步骤300，通知目标175对于服务层171关于其新状态进行更新。该消息包含“notifTargetStatus”。步骤300可以被认为是主动的，步骤298可以被认为是被动的。步骤298是接收步骤297的结果，而步骤300可以几乎在任何时间发生。在步骤301，服务层171将响应发送回通知目标175。在步骤302，服务层保持每个通知目标175的状态，并相应地调整将来如何将通知发送给它们。

表4.subConfirmReq的定义

以下是用于实现用于订阅和通知的oneM2M架构方法的示例，如本文所公开的。

图15示出了示例性CSF，用于实现对于传统的oneM2M SUB CSF的订阅和通知服务的方法以基于传统的oneM2M功能架构形成增强的订阅和通知(eSUB)CSF 305。该eSUB支持如本文所述的服务层171、订户173和通知目标175之间的过程和处理。eSub可以驻留在IN-CSE、MN-CSE或ASN-CSE中。可以在CSE中实现与服务层171相关的资源和过程，并且订户173可以是AE或CSE(例如，分别是图20A的M2M终端设备18和图20A的网关设备14)。

以下是部署示例。对于在服务层方法处的记录通知，服务层171可以是CSE(例如，IN-CSE)，而订户173可以是AE(例如，IN-AE)或CSE(例如，ASN-CSE)。对于基于在服务层处保持通知统计信息的方法，服务层171可以是CSE(例如，MN-CSE)，而订户173可以是AE(例如，ADN-AE)。对于基于来自服务层的通知确认的方法，服务层可以是CSE(例如，IN-CSE)，而订户173可以是AE(例如，IN-AE)。对于基于通知目标状态认知的方法，服务层171可以是CSE(例如，IN-CSE)，而订户173可以是AE(例如，IN-AE)或CSE(例如，MN-CSE)。如本文所公开的，用于通知目标认知的方法(例如，图14)可以包括从订户获得第一订阅请求以由订户设备接收资源的事件通知，第一订阅请求包括第一参数，其告知应联系哪个通知目标以确认第一订阅请求；基于第一订阅请求，向通知目标发送消息，该消息包括订户的标识符、订阅资源的标识符、接收通知的通知目标的标识符或事件通知标准；并基于第一订阅请求生成资源以记录通知消息。

如图16所示，为了支持这里讨论的方法，公开了新资源(<notification>307)。当通知消息被发布并发送到通知目标175(或在依赖于参数notifRecordReq的其他情况下创建)时，服务层171可以自动创建<notification>资源307。一旦创建<notification>资源307，就可以由订户173或通知目标检索它。订户173还可以删除<notification>307消息。

[notification]资源307具有若干新属性，如图16中所示和表5中所述。注意，<notification>307也可以实现为oneM2M<flexContainer>或<container>资源的类型；这样，图16中所示的<notification>307的属性可以被引入作为<flexContainer>或<container>的新属性。<notification>资源307可以放置在各种位置(例如，<subscription>资源的子资源、<AE>资源的子资源、<remoteCSE>资源的子资源等)。当<notification>307放置在<subscription>资源下作为其子资源时，<notification>307实际记录为此<subscription>资源生成的通知消息。当<notification>307放置在<AE>资源下作为其子资源并且该<AE>资源是订户173时，在这种情况下的<notification>资源307表示从作为订户173的该<AE>生成的<subscription>资源的通知消息。

表5.新<notification>资源的属性

如前所述，当发出通知消息时或取决于在订阅请求期间的notifRecordReq参数所指示的订户173的要求，服务层171可以自动创建<notification>资源。在创建<notification>资源之后，它可以由订户173或通知目标175检索，或者由订户173删除。在表6中列出了对<notification>资源的允许操作。

表6.<notification>资源上的允许操作

根据来自订户173的要求(例如，在订阅请求期间提交的notifRecordReq参数)，服务层171(例如，CSE)在其向通知目标175发出通知时自动确定创建新的<notification>消息。当创建<notification>资源时，服务层171将生成表5中列出的所有其属性。

该过程可用于检索<notification>资源的属性(例如，通过订户173或通知目标)。在10.1M-TS-0001、oneM2M功能架构、V-2.6.0(以下称为oneM2M功能架构)的第10.1.2节中描述通用检索过程。

表7.<notification>RETRIEVE

订户173可以使用<notification>DELETE方法来移除<notification>资源。在oneM2M功能架构中的第10.1.4.1节中描述通用删除过程。

表8.<notification>DELETE

如图18所示，公开了新资源(<notifTarget>315)以保持关于每个通知目标175的状态信息。订户173或通知目标可以请求在服务层171处创建<notifTarget>资源315(例如，托管对应<subscription>资源的CSE)。一旦创建了<notifTarget>资源315，就可以由订户173或通知目标(甚至是其他AE和CSE)来检索/更新/删除它。

<notifTarget>资源315具有若干新属性，如在图17中所示并且在表9中所述，并且它可以放置在各种地方(例如，<订阅>资源的子资源、<AE>资源的子资源、<remoteCSE>资源的子资源等)。当<notifTarget>315被放置在<subscription>资源下作为其子资源时，<notifTarget>315表示与该<subscription>资源相关联的通知目标175。当<notifTarget>315放置在<AE>资源下作为其子资源并且该<AE>资源是订户173时，<notifTarget>资源315表示与来自该<AE>订户173的<subscription>资源相关联的通知目标175。

表9.新<notifTarget>资源的属性

对于<notifTarget>资源，允许包括CREATE、RETRIEVE、UPDATE和DELETE的操作以实现订户173、服务层171和通知目标之间的所公开的交互，如表10中所总结的。

表10.<notifTarget>资源上的允许操作

Create<notifTarget>可以用于创建<notifTarget>资源。

表11.<notifTarget>CREATE

Retrieve<notifTarget>可以用于检索<notifTarget>资源的属性(例如，由订户173或通知目标175)。在oneM2M功能架构的第10.1.2节中描述通用检索过程。

表12.<notifTarget>RETRIEVE

Update<notifTarget>可用于更新<notifTarget>资源的属性和实际数据。

表13.<notifTarget>UPDATE

Delete<notifTarget>可用于删除<notifTarget>资源。在oneM2M功能架构中的第10.1.4.1节中描述通用删除过程。

表14.<notifTarget>DELETE

可以通过添加如表15中所述的若干新属性来扩展oneM2M中的现有<subscription>资源以支持所公开的订阅和通知方法和系统。注意，<notifTarget>和<notification>可以被添加用于<subscription>的新的子资源。或者，可以将这些新属性添加为现有oneM2M<notificationTargetPolicy>资源的新属性或新子资源。

表15.<subscription>资源的新属性

可以通过订阅托管CSE、订户或具有访问控制权的任何其他实体(包括通知目标175本身)的UPDATE操作来保持在notifTargetStatus属性(表15)中捕获的通知目标175的状态(例如，可用性)。用于通知目标175更新其状态(即，notifTargetStatus属性)的附加机制使用下面的新虚拟资源(被建议作为<subscription>资源的子资源)。这些机制可以是彼此的替代或者可以在给定的实现中共存。

<notifTargetStatusReference>：通知目标175可以向<subscription>资源的该虚拟资源发出具有包含其新状态(例如，表15中的“notifTargetStatus”属性的项)的有效载荷的UPDATE操作请求；反过来，服务层171更新该<subscription>资源的“notifTargetStatus”属性。

<notifTargetOnline>：通知目标可以向<subscription>资源的该虚拟资源发出UPDATE操作请求，以通知服务层171它变为在线；反过来，服务层171将该通知目标175标记为在线并且可用于接收通知。

<notifTargetOffline>：通知目标可以向<subscription>资源的该虚拟资源发出UPDATE操作请求，以通知服务层171它变为离线；反过来，服务层171将该通知目标175标记为离线并且不可用于接收通知。

或者，可以使用现有的oneM2M虚拟资源<notificationTargetSelfReference>来实现上述三个新属性。换句话说，通知目标175可以利用包含其新状态的有效载荷向<subscription>资源的<notificationTargetSelfReference>发出UPDATE操作请求。因此，服务层171更新相同<subscription>资源的“notifTargetStatus”属性。

图18示出了示例性用户界面。从订户173(例如，oneM2M AE或M2M终端设备18)的角度来看，可以显示用户界面325并将其用于配置参数，诸如notifRecordReq(对记录通知的要求)、notifStatReq(对计算通知统计信息的要求)、notifConfirmReq(对通知确认的要求)和subConfirmReq(对订阅确认的要求)，并且显示关于notifStatInfo(计算的通知统计信息)和notifTargetStatus(获得的通知目标175状态)的结果。注意，这里已经描述和定义了这些参数。还可以将相同的用户界面325作为应用添加到服务层171(例如，托管CSE或M2M网关设备14)。

图19示出了可以基于本文所讨论的方法和系统生成的示例性显示(例如，图形用户界面)。显示界面901(例如，触摸屏显示器)可以在框902中提供与订阅和通知服务相关联的文本，例如表1至表15的参数的值。在另一个示例中，可以在框902中显示这里讨论的任何步骤的进展(例如，发送消息或步骤成功)。此外，图形输出903可以显示在显示界面901上。图形输出903可以是与订阅和通知服务相关联的设备的拓扑、本文讨论的任何方法或系统的进展的图形输出等。

图20A是示例机器到机器(M2M)、物联因特网(IoT)或物联万维网(WoT)通信系统10的图，其中，可以实现与订阅和通知服务相关联的一个或多个公开概念(例如，图6-图14和随附的讨论)。通常，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网关设备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、蓝牙)、直接无线电链路和有线线路。

参考图20B，现场域中所示的M2M服务层22(例如，如本文所述的CSE或M2M服务器153)为M2M应用20(例如，监护人155或订户173)、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'可以由一个或多个服务器、计算机或虚拟机(例如，云/计算/存储场等)等实现。

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

在一些示例中，M2M应用20和20'可以包括使用订阅和通知服务进行通信的期望应用，如本文所讨论的。M2M应用20和20'可以包括各种行业中的应用，各种行业例如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全和监视。如上所述，跨设备、网关和系统的其他服务器运行的M2M服务层支持诸如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现和遗留系统集成等功能、并将这些功能作为服务提供给M2M应用20和20'。

用于本申请的订阅和通知服务的方法和系统可以实现为服务层的一部分。服务层是一个中间件层，其通过一组应用编程接口(API)和底层网络接口支持增值服务能力。M2M实体(例如，在硬件上实现的诸如设备、网关或服务/平台的M2M功能实体)可以提供应用或服务。ETSI M2M和oneM2M都使用服务层，该服务层可以包括本申请的用于订阅和通知服务的方法和系统。oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型的CSF的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、特定于应用的节点)上。此外，本申请的用于订阅和通知服务的方法和系统可以实现为M2M网络的一部分，该M2M网络使用面向服务的体系结构(SOA)或面向资源的体系结构(ROA)来访问本申请的诸如订阅和通知服务的服务。

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

图20C是示例M2M设备30的系统图，示例M2M设备30例如是M2M终端设备18(其可以包括订户173)或M2M网关设备14(其可以包括图5或图6的一个或多个组件)。如图20C所示，M2M设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50和其他外围设备52。应当理解，M2M设备30可以包括前述元件的任何子组合，同时保持与所公开的主题一致。M2M设备30(例如，M2M服务器153、设备155、设备156到设备159、订户173和通知目标175等)可以是执行所公开的用于订阅和通知服务的系统和方法的示例性实现。

处理器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可以被配置为发送或接收无线或有线信号的任何组合。

另外，尽管在图20C中将发送/接收元件36描绘为单个元件，但是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。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储设备。可移动存储器46可以包括用户识别模块(SIM)卡、记忆棒和安全数字(SD)存储卡等。在其他示例中，处理器32可以从物理上不位于M2M设备30上的存储器访问信息并将数据存储在其中，所述存储器例如在服务器或家用计算机上。处理器32可以被配置为响应于本文描述的一些示例中的订阅或通知是成功还是不成功(例如，订阅)来控制显示器或指示器42上的照明图案、图像或颜色，或者否则指示订阅和通知服务及相关组件的状态。显示器或指示器42上的控制照明图案、图像或颜色可以反映本文(例如，图6-图14等等)所示或所讨论的图中的任何方法流程或组件的状态。这里公开了订阅和通知服务的消息和过程。可以扩展消息和过程以为用户提供接口/API以经由输入源(例如，扬声器/麦克风38、小键盘40或显示器/触摸板42)请求订阅和通知资源，并且请求、配置或查询可以在显示器42上显示的资源订阅和通知等。

处理器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)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块和互联网浏览器等。

发送/接收元件36可以体现在其他装置或设备中，例如传感器、消费电子产品、诸如智能手表或智能服装的可穿戴设备、医疗或电子卫生设备、机器人、工业设备、无人机、诸如汽车、卡车、火车或飞机等运输工具。发送/接收元件36可以经由一个或多个互连接口连接到这种装置或设备的其他组件、模块或系统，所述一个或多个互连接口例如是可以包括外围设备52之一的互连接口。

图20D是示例性计算系统90的框图，在该示例性计算系统90上，例如，可以实现图20A和图20B的M2M服务平台22。计算系统90(例如，M2M终端设备18或M2M网关设备14)可以包括计算机或服务器，并且主要可以通过计算机可读指令通过存储或访问这些指令的任何手段来被控制。这样的计算机可读指令可以在中央处理单元(CPU)91内执行，以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其他机器中，中央处理单元91可包括多个处理器。协处理器81是可选处理器，不同于的主CPU 91，其执行附加功能或辅助CPU 91。CPU 91或协处理器81可以接收、生成和处理与所公开的用于订阅和通知服务的系统和方法有关的数据，例如接收订阅请求和指示通知目标状态。

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

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

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

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

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

应当理解，本文描述的任何或所有系统、方法和过程可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式体现，当由诸如计算机、服务器、M2M终端设备或M2M网关设备等的机器执行时，该指令可以执行或实现这里描述的系统、方法和过程。具体地，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质，但是这种计算机可读存储介质本身不包括信号。从本文的描述中可以明显看出，存储介质应该被解释为法定主题。计算机可读存储介质包括RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字通用盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备或者可用于存储所需信息并可由计算机访问的任何其他物理介质。计算机可读存储介质可以具有存储在其上的计算机程序，该计算机程序可以加载到数据处理单元中并且被适配来在数据处理单元运行计算机程序时使数据处理单元执行方法步骤。

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

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

该书面描述使用示例来公开本发明，包括最佳模式，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其他示例(例如，在本文公开的示例性方法之间跳过步骤、组合步骤或添加步骤)。如果这些其他示例具有与权利要求的字面语言没有不同的结构元件，或者如果它们包括与权利要求的字面语言无实质差别的等效结构元件，则这些其他示例意图在权利要求的范围内。

如本文所述的方法、系统和装置等可以提供用于订阅或通知服务的装置。一种方法、系统、计算机可读存储介质或装置具有用于获得(例如，被动地接收或主动检索)第一订阅请求以由订户设备接收资源的事件通知的装置；并基于第一订阅请求生成资源以记录通知消息。该方法、系统、计算机可读存储介质或装置具有用于获得第二订阅请求(例如，后续订阅请求)以基于发现标准检索与通知目标相关联的事件通知的装置；并且当满足发现标准时，发送包括通知消息的响应。该方法、系统、计算机可读存储介质或装置具有用于获得第二订阅请求以基于发现标准检索与通知目标相关联的事件通知的装置，其中，发现标准包括对已经发送但尚未确认为由通知目标获得的请求；并且当满足发现标准时，发送确认第二订阅请求的响应。该方法、系统、计算机可读存储介质或装置具有用于获得第二订阅请求以基于发现标准删除与通知目标相关联的通知的装置；并且当满足发现标准时，发送确认第二订阅请求的响应。该方法、系统、计算机可读存储介质或装置具有用于获得第二订阅请求以基于发现标准删除与通知目标相关联的通知的装置，其中，发现标准包括在一时间段内已发送的消息；并且当满足发现标准时，发送确认第二订阅请求的响应。第一订阅请求可以包括指令一记录在一时间段内发出的每个通知。第一订阅请求可以包括指令以记录在一时间段期间发布、被传递到列表中的通知目标，并且由列表中的条件生成的通知。第一订阅请求包括指令以当对于特定通知目标而言已经失败特定数量时记录通知。一种方法、系统、计算机可读存储介质或装置具有用于获得要创建的通知资源的到期时间的指示的装置。该装置可以是服务层。一种方法、系统、计算机可读存储介质或装置具有用于从订户获得第一订阅请求以由订户设备接收资源的事件通知的装置，该第一订阅请求包括第一参数，其告知应联系哪个通知目标以确认第一订阅请求；基于第一订阅请求，向通知目标发送消息，该消息包括订户的标识符、订阅资源的标识符、接收通知的通知目标的标识符或事件通知标准；并基于第一订阅请求生成资源以记录通知消息。以与详细描述的其他部分一致的方式考虑本段中的所有组合(包括步骤的移除或添加)。