CN107431722B - M2m通信的动态事件订阅 - Google Patents
M2m通信的动态事件订阅 Download PDFInfo
- Publication number
- CN107431722B CN107431722B CN201580077676.3A CN201580077676A CN107431722B CN 107431722 B CN107431722 B CN 107431722B CN 201580077676 A CN201580077676 A CN 201580077676A CN 107431722 B CN107431722 B CN 107431722B
- Authority
- CN
- China
- Prior art keywords
- recipient
- notification
- event
- removal
- subscription
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
- H04L65/1093—In-session procedures by adding participants; by removing participants
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
- H04W4/08—User group management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
公开了灵活且安全地实现移除事件通知接收者的系统和方法。更具体地,公开了M2M通信系统中能够移除通知接收者的节点的操作方法的实施例。在一些实施例中,该节点的操作方法包括向一个或多个接收者发送事件的通知。该一个或多个接收者通过订阅发起者订阅事件的通知,并且该一个或多个接收者与订阅发起者不同。该方法还包括:接收来自接收者的移除请求,基于接收者的移除策略确定是否允许移除作为事件通知的接收者的接收者,以及一旦确定允许移除作为事件通知的接收者的接收者,移除作为事件通知的接收者的接收者。
Description
技术领域
本公开涉及机器对机器(M2M)通信,尤其涉及M2M系统中的事件订阅。
背景技术
机器对机器(M2M)通信和物联网(IoT)预计在未来几年将有快速增长。为了实现这一增长,已经出现oneM2M作为M2M和物联网的一套标准。具体地,oneM2M将M2M通信的公共服务层进行了标准化。设计oneM2M并非为了取代现有的部门或行业M2M技术,而是与现有的部门和行业M2M技术协同工作,以扩大其覆盖面。因此,oneM2M被认为是整个M2M生态系统的互操作性推动者。
在当前的oneM2M架构中,可以在托管公共服务实体(CSE)上针对事件创建订阅,使得关于该事件的通知被发送到某个其他实体(称为接收者)而不是创建该订阅的实体(简称订阅发起者)。也可以针对订阅指定多于一个接收者。然而,当这些接收者表示他们不感兴趣接收事件的通知或容易管理大量的通知接收者时,目前的oneM2M架构在移除通知接收者方面缺乏灵活性。
发明内容
本文公开的系统和方法涉及订阅机器对机器(M2M)通信系统中的事件通知。在一些实施例中,公开了灵活且安全地实现事件通知接收者的移除的系统和方法。更具体地,公开了M2M通信系统中的节点执行的能够移除通知接收者的操作的方法的实施例。在一些实施例中,该节点的操作的方法包括向一个或多个接收者发送事件的通知。该一个或多个接收者通过订阅发起者订阅事件的通知,并且该一个或多个接收者与订阅发起者不同。该方法还包括从接收者接收移除请求,基于接收者的移除策略确定是否允许移除作为事件通知的接收者的所述接收者,以及一旦确定允许移除作为事件通知的接收者的所述接收者,移除作为事件通知的接收者的所述接收者。在一些实施例中,移除策略由订阅发起者定义。按照这种方式,可以以安全的方式控制接收者的移除,同时还为订阅发起者提供灵活性和控制。
在一些实施例中,该方法还包括一旦确定不允许移除作为事件通知的接收者的所述接收者,拒绝移除作为事件通知的接收者的所述接收者。
在一些实施例中,移除策略指示在允许移除接收者之前是否需要订阅发起者的批准。在一些实施例中,移除策略指示在允许移除所述接收者之前不需要订阅发起者的批准,并且确定是否允许移除作为事件通知的接收者的所述接收者包括:在没有来自订阅发起者的输入的情况下,确定是否允许移除作为事件通知的接收者的所述接收者。在其他实施例中,移除策略指示在允许移除接收者之前需要订阅发起者的批准,并且确定是否允许移除作为事件通知的接收者的所述接收者包括:请求订阅发起者批准移除作为事件通知的接收者的所述接收者,并且一旦接收到来自订阅发起者的批准,确定允许移除作为事件通知的接收者的所述接收者。
在一些实施例中,移除策略包括在允许移除作为事件通知的接收者的所述接收者之前必须满足的一个或多个定义的标准。此外,在一些实施例中,所述一个或多个定义的标准包括事件发生的一天中的时间和/或接收者的地理位置。
在一些实施例中,接收者的移除策略还包括:用于将接收者自动添加回来作为事件通知的接收者的一个或多个标准,并且该方法还包括:在移除作为事件通知的接收者的所述接收者之后,一旦确定满足用于将接收者自动添加回来作为事件通知的接收者的一个或多个标准,将接收者添加回来作为事件通知的接收者。
在一些实施例中,所述一个或多个接收者包括多个接收者,并且针对多个接收者中的至少两个接收者中的每一个定义单独的移除策略。
在一些实施例中,该方法还包括:在向接收者发送通知之前,基于接收者的通知策略确定是否要向接收者发送所述通知,并且向接收者发送所述通知包括:一旦基于接收者的通知策略确定要将通知发送给该接收者,向该接收者发送所述通知。此外,在一些实施例中,接收者的通知策略基于一个或多个定义的标准。在一些实施例中,所述一个或多个定义的标准包括一天中的时间和/或接收者的地理位置。
在一些实施例中,该方法还包括:在向所述一个或多个接收者发送事件的通知之前,从订阅发起者接收对事件的通知的订阅,其中所述订阅是针对所述一个或多个接收者的对事件的通知的订阅,并且所述订阅包括接收者的移除策略。
在一些实施例中,所述方法还包括:接收创建包括所述一个或多个接收者的组的请求,利用针对组的组标识符来响应创建组的所述请求,并且接收具有作为所述通知的接收者的标识符的所述组标识符的所述事件的通知,其中向所述一个或多个接收者发送事件的通知包括:响应于接收具有作为所述通知的接收者的标识符的所述组标识符的所述事件的通知,向所述组中的所述一个或多个接收者发送所述事件的通知。此外,在一些实施例中,发送给组中的所述一个或多个接收者的事件的通知包括组标识符。在一些实施例中,移除作为事件通知的接收者的所述接收者包括:移除作为事件通知的接收者的所述接收者,但不是从所述组移除。
在一些实施例中,所述一个或多个接收者是所述组中的多个接收者的子集,并且该方法还包括:接收具有作为不同事件的通知的接收者的标识符的所述组标识符的所述不同事件的通知、以及针对所述不同事件的通知的一个或多个策略,接收不同事件的通知,并且根据针对上述不同事件的通知的一个或多个策略,向所述组中的多个接收者的子集发送不同事件的通知。此外,在一些实施例中,该方法还包括:接收针对所述组中针对所述不同事件的通知的接收者的一个或多个通知策略,其中针对所述组(42)中针对所述不同事件的通知的接收者(38)的所述一个或多个通知策略标识所述组(42)中不去接收所述不同事件的通知的所述多个接收者(38)中的至少一个。
还公开了M2M通信系统中的能够移除通知接收者的节点的实施例。
在阅读与附图相关联的实施例的以下详细描述之后,本领域技术人员将清楚本公开的范围并且认识到其附加方面。
附图说明
并入本说明书中并且形成其一部分的附图示出了本公开的几个方面,并且与描述一起用于解释本公开的原理。
图1示出了目前由oneM2M标准定义的机器对机器(M2M)架构;
图2示出了由图1的M2M架构支持的配置;
图3A和图3B示出了根据本公开的一些实施例用于提供灵活移除事件通知的接收者的M2M系统的两个示例;
图4示出了根据本公开的一些实施例的图3A的M2M系统的操作;
图5是示出根据本公开的一些实施例更详细地应用图4的移除策略步骤的流程图;
图6A和图6B示出了根据本公开的一些实施例的根据图5的过程来处理来自接收者的移除请求的公共服务实体(CSE)的操作;
图7是示出根据本公开的一些实施例的在一些实施例中用于将先前移除的接收者自动添加回来作为事件通知的接收者的自动加回特征的流程图;
图8是示出了根据本公开的一些实施例的CSE应用通知策略、并且作为通知策略的结果向接收者发送或不发送事件通知的的操作的流程图;
图9A和图9B示出了根据本公开的一些实施例的图3B的M2M系统的操作;
图10是示出根据本公开的一些实施例更详细地应用图9B的移除策略步骤的流程图;
图11A和图11B示出了根据本公开的一些实施例的组管理服务器根据图10的过程处理来自接收者的移除请求的操作;
图12是示出了根据本公开的一些实施例的组管理服务器应用通知策略、并且作为通知策略的结果向组中的接收者发送或不发送事件通知的操作的流程图;
图13示出了根据本公开的一些实施例的图3B的M2M系统使用相同的组标识符(ID)来实现附加订阅(即,除了例如图9A和图9B的订阅之外)的操作;
图14示出了根据本公开的一些其它实施例的图3B的M2M系统的操作;
图15A和图15B示出了根据本公开的一些实施例的移除过程的两个示例;
图16是根据本公开的一些实施例的节点的框图;
图17示出了根据本公开的一些其它实施例的节点;以及
图18示出了根据本公开的一些其它实施例的节点。
具体实施方式
下面阐述的实施例呈现使本领域技术人员实践实施例的信息并且示出实践实施例的最佳模式。在根据附图阅读以下描述以后,本领域技术人员将理解本公开的构思并且将认识到本文未具体给出的这些构思的应用。应当理解的是,这些构思和应用落入本公开和所附权利要求的范围内。
机器对机器(M2M)通信的公共服务层由oneM2M准备、批准和维护的一组标准定义。这些标准在本文被称为oneM2M标准。值得注意的是,尽管本文描述的实施例聚焦于oneM2M,但是本公开不限于oneM2M标准或者实施oneM2M标准的系统。相反,本文公开的系统和方法可以在任何合适的M2M系统中实现。
图1中示出了目前由oneM2M标准定义的M2M架构10。如图所示,M2M架构10包括场域12和基础架构域14。如oneM2M标准所定义的,场域12由M2M设备、M2M网关、感测和启动设备以及M2M区域网络组成,而基础架构域14由应用基础架构和M2M服务基础架构组成。场域12通常包括多个节点(未示出),每个节点包括应用实体(AE)16、公共服务实体(CSE)18和网络服务实体(NSE)20中的一个或多个。oneM2M标准,特别是oneM2M技术规范(TS)0001版本1.6.1,定义AE 16如下:
应用实体是应用层中实现M2M应用服务逻辑的实体。每个应用服务逻辑可以驻留在多个M2M节点中和/或在单个M2M节点上驻留多于一次。应用服务逻辑的每个执行实例被称为“应用实体”(AE),并用唯一的AE-ID标识(见第7.1.2节)。AE的示例包括车队跟踪应用的实例、远程血糖监测应用、功率计量应用或控制应用。
oneM2M标准,特别是oneM2M TS 0001版本1.6.1,定义了CSE 18如下:
公共服务实体表示M2M环境的一组“公共服务功能”的实例化。这样的服务功能通过Mca和Mcc参考点暴露给其他实体。参考点Mcn用于访问底层网络服务实体。每个公共服务实体都用唯一的CSE-ID标识(见第7.1.4节)。
CSE提供的服务功能示例包括:数据管理、设备管理、M2M服务订阅管理和定位服务。CSE提供的这种“子功能”可以在逻辑上和信息上概念化为公共服务功能(CSF)。在CSE中实现服务功能的规范性资源可以是强制性的或可选的。
CSE 18提供的一些公共服务功能(CSF)可以包括:例如应用和服务层管理、通信管理/传送处理、数据管理和存储库、设备管理、发现、组管理、位置、网络服务曝光/服务执行和触发、注册、安全服务计费和会计,以及订阅和通知。oneM2M标准,特别是oneM2M TS 0001版本1.6.1,定义NSE 20如下:
网络服务实体从底层网络向CSE提供服务。这些服务的示例包括设备管理、位置服务和设备触发。不考虑NSEs的特定组织。
以类似的方式,基础架构域14还包括AE 16、CSE 18和NSE 20。
AE 16和CSE 18之间的通信流过Mca参考点,使AE 16能够使用CSE 18支持的业务,并进一步使CSE 18与AE 16通信。两个CSE 18之间的通信流过Mcc参考点,并使CSE 18能够使用另一个CSE 18支持的服务。CSE 18和NSE 20之间的通信流过Mcn参考点,使CSE 18能够使用NSE 20提供的传输和连接服务以外的支持服务。符合oneM2M标准且位于不同M2M服务提供商域的基础架构节点(IN)中的两个CSE 18之间的通信流过Mcc’参考点。流过Mcc’参考点的通信使得驻留在服务提供商的基础架构域14中的IN的CSE 18能够与驻留在另一服务提供商(未示出)的基础架构域中的IN的CSE 18通信。
如在oneM2M TS 0001版本1.6.1中所描述的,由图1的M2M架构10支持的配置在图2中示出。如图所示,场域12可以包括应用服务节点(ASN)22、应用专用节点(ADN)24、中间节点(MN)26和非oneM2M设备节点(NoDN)28。如图所示,每个ASN 22是包括一个CSE 18和至少一个AE 16的节点。虽然在场域12中示出了多个ASN 22,但场域12可以包括零个或多个ASN22。在一些实施例中,ASN 22驻留在M2M设备中。M2M设备是支持M2M通信的任何设备。M2M设备的一些示例是水表或比重计。然而,这些是非限制性的示例。M2M设备的具体类型将根据具体应用而变化。每个ADN 24是包括至少一个AE 16但不包括CSE 18的节点。虽然在场域12中示出了多个ADN 24,但场域12可以包括零个或多个ADN 24。在一些实施例中,ADN 24驻留在受约束的M2M设备(例如,具有受约束的存储器、电池和处理能力的M2M设备,例如传感器)中。每个MN 26是包含一个CSE 18和零个或多个AE 16的节点。虽然示出了多个MN 26,但是场域12可以包括零个或多个MN 26。在一些实施例中,MN 26驻留在M2M网关中。在oneM2M中,M2M网关是至少包括MN的实体和应用编程接口(API)的物理设备。每个NoDN 28是不包含任何AE 16并且不包含任何CSE 18的节点。NoDN 28表示附接到M2M系统的设备,用于互通目的,包括管理。
基础架构域14是特定M2M服务提供商的域。基础架构域14包括IN 30。IN 30是包含一个CSE 18和零个或多个AE 16的节点。目前,在oneM2M中,每个M2M服务提供商确切只有一个IN 30。IN 30中的CSE 18可包括不适用于其他节点类型的CSE功能。
在当前的oneM2M架构中,可以在具有订阅和通知功能的CSE 18上创建针对事件的订阅。此CSE 18在本文中更具体地称为托管CSE。订阅标识或定义例如当事件的实例发生时(例如,当温度超过定义的阈值时通知接收者)要实时接收事件通知的一个或多个接收者。可以创建订阅,使得接收者是除了创建订阅的实体(这在本文中被称为订阅发起者)之外的实体。也可以针对订阅指定多于一个接收者。
目前的oneM2M架构的一个问题是,订阅和通知功能缺乏使接收者能够表明他不再对事件的通知感兴趣的灵活性,或者以安全的方式移除作为事件通知的接收者的接收者的灵活性。这在订阅发起者与接收者不同时尤为重要。这与大多数常规订阅系统(例如,电子邮件订阅)相反,常规订阅系统中,接收者自己订阅一个或多个邮件列表,因此,如果需要,他们可以容易地从一个或多个邮件列表中取消自身的订阅。相反,在接收者不是订阅发起者的当前oneM2M架构中,如果没有联系订阅发起者,接收者不能取消订阅。具体来说,接收者必须联系订阅发起者,并要求订阅发起者从订阅中移除接收者。此外,不支持订阅发起者在事件通知的接收者想要停止接收通知的时候能指明将应用什么权限/动作/策略(在此简称为策略,甚至更具体地称为移除策略)。这些策略(如果可用)将允许通知的源基于订阅发起者提供的策略(例如,在事件订阅的创建或更新时)对来自通知的接收者的传入的移除请求采取动作。最后,当使用组来标识接收者列表(通过组标识符(ID))时,或者当接收者被单独列出(不经由组ID)时,需要能在这两种情况下应用上述内容。
目前,允许接收者停止接收事件通知的唯一方法是订阅发起者修改现有订阅以移除该接收者。虽然这样做是有效的,但是由于它需要每当接收者希望被移除时都需要订阅发起者参与,并且需要接收者通过离线手段与订阅发起者进行通信,要求订阅发起者修改订阅来移除接收者,因此这种方法可能是很笨拙的。这对于来说是不实际的,因为在M2M通信中,任何时候和所有应用中都认为没有人为干预。此外,它缺乏灵活环境中为满足可将消费者相关应用扩展到工业应用的不同的M2M应用所需的所有动态方面。
当前的oneM2M订阅和通知功能的另一个问题是它不支持使用组来定义通知的接收者。在某些情况下,接收者数量相当大,因此,更改和修改订阅的信令开销相当大,并且还需要处理生成通知的实体(托管CSE中针对事件的订阅和通知功能)存储大量的通知接收者。
本文公开了解决这些问题的系统和方法。一些实施例解决了上述两个问题,而其他实施例解决了上述问题中的一个或另一个。在这方面,图3A和图3B示出了根据本公开的一些实施例的用于提供灵活移除事件的接收者的M2M系统32的两个示例。更具体地,在图3A的实施例中,M2M系统32包括订阅发起者34、CSE 36和一个或多个接收者38。订阅发起者34是作为在CSE 36处创建的针对事件的订阅的发起者的实体。例如,订阅发起者34可以是例如应用实体或另一CSE。如本文所使用的,“事件”是与M2M系统相关并由M2M系统检测的交互或发生。例如,对于CSE 36,事件是与CSE 36相关并且由CSE 36检测的交互或发生。例如,CSE 36可以监测传感器的输出(例如,来自温度传感器的温度读数),并且事件可以被定义为该温度升高到定义的温度阈值之上。请注意,这只是一个示例。事件将根据具体应用而有所不同。所述订阅具有事件通知的一个或多个接收者38。此外,如下所述,所述订阅包括与移除作为事件通知的接收者的接收者38有关的一个或多个策略(本文称为移除策略)和/或与向接收者38发送事件通知有关的一个或多个策略(本文称为通知策略)。在一些实施例中,允许订阅发起者34根据需要更新所述一个或多个策略。值得注意的是,诸如“所述订阅包括一个或多个策略”、“针对订阅的策略”、“与订阅相关联的策略”等短语以及类似短语在本文可互换使用。所有这些短语意味着由订阅发起者34提交的一个或多个策略在执行关于订阅或订阅事件的动作时(例如,发送事件通知和/或确定是否允许移除接收者时)被应用。
移除策略使得事件通知的源(在该示例中是CSE 36)能够处理来自接收者38的移除请求以确定是否允许移除接收者38。如果是,则移除作为事件通知的接收者的接收者38。此外,移除策略给订阅发起者34提供了很大灵活性来控制接收者38的移除。例如,通过移除策略,订阅发起者34可以要求或不要求通知的源(在该示例中是CSE 36)在移除接收者38之前获得订阅发起者34的批准。另外或备选地,移除策略可以基于一个或多个其他标准,例如一天中的时间、接收者38的地理位置等。
以类似的方式,在一些实施例中,可以使用一个或多个通知策略来给予订阅发起者34在控制在什么情况下接收者38接收事件通知方面的灵活性。通知策略可以基于任何合适的标准,例如一天中的时间、接收者38的地理位置等。
在图3B的实施例中,除了订阅发起者34、CSE36以及一个或多个接收者38之外,M2M系统32还包括组管理服务器40。在该示例中,创建组42并将组42标识为事件通知的接收者。订阅发起者34可以再次定义与移除作为事件通知接收者的接收者38有关的订阅策略,和/或与向组42中的接收者38发送通知有关的订阅策略。组管理服务器40可以是独立服务器,或者实现为CSE(例如,IN的CSE)内的CSF。
图4示出了根据本公开的一些实施例的图3A的M2M系统32的操作。如图所示,订阅发起者34与CSE 36通信以创建接收者38对事件的订阅(步骤100)。值得注意的是,接收者38是与订阅发起者34不同的实体。在创建订阅时,订阅发起者34还创建或提交一个或多个针对订阅的策略。这些策略包括与移除作为事件通知接收者的接收者38有关的一个或多个移除策略,和/或与向接收者38发送事件通知有关的一个或多个通知策略。如果存在多个接收者38,则策略可以包括可适用于所有接收者38的一个或多个策略和/或可适用于各个接收者38的一个或多个策略(例如,针对不同接收者38的不同策略)。CSE 36将所述一个或多个策略与事件和订阅绑定(步骤102)。在一些实施例中,事件具有唯一事件标识符(事件ID),并且订阅具有唯一订阅标识符(订阅ID)。因此,策略与事件ID和订阅ID相关联。CSE 36向订阅发起者34发送响应以确认订阅的创建(步骤104)。虽然未示出,订阅发起者34保持订阅所需的绑定。
此后,当事件发生时,CSE 36应用通知策略(如果有的话)来确定是否向接收者38发送事件的通知(步骤106)。注意,步骤106是可选的(即,在所有实施例中不是必需的)。通知策略通常是由订阅发起者34创建的、由CSE 36用来确定事件的通知是否应被发送给接收者38的策略。通知策略可以是特定于特定接收者38的,或者可以例如通常可适用于针对该特定订阅的事件通知的所有接收者38(如果有多个接收者38的话)。通知策略可以基于任何合适的标准,例如一天中的时间和/或接收者38的地理位置。例如,通知策略可以是仅在当天的某些时间和/或仅当接收者38位于特定地理区域时才向接收者38发送事件的通知。
假设事件的通知将被发送给接收者38,则CSE 36向接收者38发送该事件的通知(步骤108)。该过程可以以这种方式继续,使得针对多次事件发生的通知继续被发送给接收者38。
在这个示例中,在某一时刻,接收者38希望事件的通知停止。这样,接收者38向CSE36发送移除请求(步骤110)。在一些实施例中,发送给接收者38的至少一个以及可能所有的通知包括事件ID和订阅ID,并且移除请求包括事件ID和订阅ID。响应于接收到移除请求,CSE 36应用移除策略以确定是否允许移除作为事件通知接收者的接收者38(步骤112)。移除策略可以是特定于接收者38的,或者可以通常适用于针对订阅的事件的所有接收者38。
移除策略通常是由订阅发起者34创建的策略,CSE 36应用该策略确定是否允许移除作为每个订阅的事件通知的接收者的接收者38。移除策略可以是特定于具体接收者38的,或者可以例如通常适用于针对该具体订阅的事件通知的所有接收者38(如果存在多个接收者38)。移除策略可以例如指示在允许移除之前是否需要订阅发起者34的批准。另外或备选地,移除策略可以基于任何合适的标准,例如一天中的时间和/或接收者38的地理位置。例如,移除策略可以是这样的,即始终需要订阅发起者38的批准。作为另一示例,移除策略可以是仅在一天中的某些时间和/或仅当接收者38位于特定地理区域中才需要订阅发起者38的批准但在其他情况下不需要。
通过应用移除策略,CSE 36确定是否允许移除接收者38,如上所述。结果,如果允许移除,则将接收者38作为事件通知的接收者移除,否则不作为事件通知的接收者移除。可选地,将响应发送给接收者38以指示移除请求已经被接受(因而接收者38已被移除)或被拒绝(因而接收者38尚未被移除)(步骤114)。虽然未示出,但是应当注意,在一些实施例中,如果订阅发起者34针对这样的事件向CSE 36订阅,则可以可选地向订阅发起者34通知接收者的移除。
图5是根据本公开的一些实施例更详细地示出图4的步骤112的流程图。对于这个讨论,该过程由CSE 36执行。然而,应当注意,该过程更通常可以由通知的源执行。如图所示,为了应用移除策略,在一些实施例中(即,可选地),CSE 36确定移除策略是否不允许在任何条件下移除接收者38(步骤200)。如果不是,则该过程进行到步骤214(下面讨论)。如果该策略确实允许至少在某些条件下移除接收者38,则CSE 36确定是否满足除订阅发起者34批准之外的任何移除策略要求(步骤202)。可以使用任何合适的要求。然而,在一些具体实施例中,这些要求可以基于如上所述的诸如一天中的某个时间和/或接收者38的地理位置等标准。如果不满足这些要求(如果有的话),则过程进行到步骤214(下面讨论)。否则,CSE36确定移除策略是否需要来自订阅发起者34的批准(步骤204)。
如果不需要订阅发起者34的批准,则该过程进行到步骤210(下面讨论)。然而,如果需要订阅发起者34的批准,则CSE 36向订阅发起者34发送批准移除作为订阅的事件通知的接收者的接收者38的请求(步骤206)。该请求可以包括例如标识接收者38的信息(例如,接收者ID)、标识事件的信息(例如,事件ID)和/或标识订阅的信息(例如,订阅ID)。然后,CSE 36响应于该请求确定是否接收到来自订阅发起者34的批准(步骤208)。如果否,则该过程进行到步骤214(下面讨论)。
如果在步骤204中不需要批准,或者如果在步骤208中接收到订阅发起者34的批准,则CSE 36移除作为针对订阅的事件通知的接收者的接收者38(步骤210)。因此,接收者38将不再接收来自CSE 36的针对该订阅的事件的通知。可选地,CSE 36向接收者38发送响应以通知接收者38:接收者38作为事件通知的接收者已被成功地移除(步骤212)。虽然未示出,CSE 36也可以向订阅发起者34发送消息以通知订阅发起者34接收者38已被移除。
如果在步骤200中确定移除策略不允许在任何条件下移除接收者38,或者如果在步骤202中不满足移除策略要求,或者如果在步骤208中未接收到订阅发起者34的批准,则CSE 36将接收者38保持为事件通知的接收者(即,CSE 36不移除接收者38)(步骤214)。可选地,CSE 36向接收者38发送响应以通知接收者38该移除请求被否定或被拒绝(步骤216)。虽然没有示出,CSE 36也可以向订阅发起者34发送消息,以通知订阅发起者34接收者38的移除请求已被拒绝或接受。
图6A和图6B示出了根据本公开的一些实施例的根据图5的过程的CSE 36处理来自接收者38的移除请求的操作。具体地,图6A示出了移除策略不需要来自订阅发起者34的批准的情况,而图6B示出了移除策略确实需要来自订阅发起者34的批准的情况。如图6A所示,如上所述,CSE 36接收来自接收者38的移除请求(步骤300)。CSE 36然后针对接收者38应用移除策略。具体地,CSE 36验证与接收者38和事件相关联的移除策略(步骤302)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。在此示例中,移除策略不需要来自订阅发起者34的批准,并且满足所有其他移除要求(如果有)。因此,CSE 36移除作为事件通知的接收者的接收者38(步骤304)。此外,在该示例中,CSE 36向接收者38发送指示移除请求被接受的响应(步骤306),并且向订阅发起者34发送移除接收者38的通知(步骤308)。在一些实施例中,该通知包括接收者38的ID、事件ID和订阅ID。
相反,在图6B中,如上所述,CSE 36接收来自接收者38的移除请求(步骤400)。CSE36然后针对接收者38应用移除策略。具体地,CSE 36验证与接收者38和事件相关联的移除策略(步骤402)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。在此示例中,移除策略确实需要来自订阅发起者34的批准。因此,CSE 36向订阅发起者34发送批准请求(步骤404)。所述批准请求是请求来自订阅发起者34的对移除作为事件通知的接收者的接收者38的批准。所述批准请求标识接收者38、事件和订阅。订阅发起者34通过接受或许可请求(即,给予批准)或通过拒绝该请求(即,不予批准)来响应该批准请求(步骤406)。如果订阅发起者34给予批准,则CSE 36移除作为事件通知的接收者的接收者38,或者如果订阅发起者34没有给予批准,则不移除作为事件通知的接收者的接收者38(步骤408)。在该示例中,CSE 36向接收者38发送指示是接受还是拒绝移除请求的响应(步骤410)。
图4至图6A和图6B的实施例涉及移除作为事件通知的接收者的接收者38。图7是示出了根据本公开的一些实施例的在一些实施例中用于自动地将先前移除的接收者38添加回来作为事件通知的接收者的自动加回功能的流程图。更具体地说,在接收者38作为事件通知的接收者被移除之后的某个时刻,CSE 36确定是否执行接收者38的自动加回(步骤500)。该确定可以通过任何合适的标准进行。所述标准可以是特定于事件的(例如,如果事件是由仪表监测的温度升高到第一阈值之上,则自动加回标准可以包括例如温度升高到高于第一阈值的第二阈值之上)。另外或备选地,自动加回的标准可以基于诸如一天中的时间或地理位置等标准。接收者38的自动加回的标准可以包括在例如与接收者38和事件相关联的移除策略中。如果CSE 36确定接收者38不被自动添加回来,则该过程结束。然而,如果CSE36确定接收者38将被自动添加回来,则CSE 36将接收者38添加回来作为事件通知的接收者(步骤502)。这可以在要求或不要求订阅发起者34的批准的情况下完成。
如上所述,在一些实施例中,CSE 36可以应用与接收者38和事件相关联的通知策略来确定是否向接收者38发送事件的通知。在这方面,图8是示出CSE 36应用通知策略、并且作为通知策略的结果向接收者38发送或不发送事件通知的操作的流程图。如图所示,在该示例中,CSE 36检测事件的发生(步骤600)。CSE 36确定与接收者38和事件相关联的通知策略是否满足(步骤602)。如果满足,则CSE 36向接收者38发送该事件的通知(步骤604)。否则,CSE 36不向接收者38发送事件的通知(步骤606)。
图3A和图4-8聚焦于非基于组的实施例,现在讨论转向基于组的实施例。具体地,这些实施例涉及图3B的M2M系统32,其中组管理服务器40用于创建接收者38的组42。在一些实施例中,订阅发起者34与组管理服务器40通信以创建组42,然后使用组42作为订阅事件的通知的接收者来订阅由CSE 36托管的事件。更具体地说,在一些实施例中,订阅发起者34利用组管理服务器40来创建接收者38的组42,其中接收者38的组42包括多个接收者38。组42具有可用于引用组42中的接收者38的组ID。订阅发起者42以及其他订阅发起者可以创建多个组42,其中每个组42具有其自己的组ID。
订阅功能被扩展以允许定义组(例如,组42)作为订阅事件的通知的接收者。组42的组ID指向组管理服务器40。组管理服务器40将组42中的接收者列表38与组42的组ID相关联地存储。
组42中的每个接收者38存储组42的组ID(例如,可以在发送给接收者38的第一通知中将其传送给接收者38)。接收者38可以使用组ID来例如请求将作为事件通知的接收者的接收者38移除(如果接收者38希望如此)。在一些实施例中,与该组ID相关联的订阅发起者34设置的访问控制和策略控制谁可以提交这些请求(即使在对任何此类请求采取行动之前)。
在事件订阅创建时,订阅发起者34提交适用于组42中所有接收者38(可能更一般地被称为成员)的策略。值得注意的是,组42中的所有成员并不是最初都被配置为实际接收者38。例如,订阅发起者34提交的策略最初可以指示仅组42中成员的子集将是订阅事件的通知的实际接收者。托管事件的CSE 36存储策略并将策略绑定到事件、订阅和组ID。在一些实施例中,一旦CSE 36发起事件的第一通知,CSE 36便包括可用于事件和组ID的策略。值得注意的是,由于在订阅中指示的接收者38是组ID,所以CSE 36向组管理服务器40发送通知。组管理服务器40向接收到的策略分配策略ID、存储该策略,并将其绑定到事件和组ID。组管理服务器40将策略ID返回给发起通知的托管CSE 36,该CSE 36又存储策略ID并将其绑定到事件、策略、订阅和组ID。如果订阅发起者34在事件订阅刷新中稍后更新策略,则策略ID使得托管该事件的CSE 36能够更新策略。所述策略不包括在由组管理服务器40发送给通知的接收者38的通知中。相反,所述策略仅由组管理服务器40使用。
订阅发起者34(通过订阅刷新)对于事件的策略的任何改变都将被事件托管CSE36推送到组管理服务器40。可以使用任何合适的技术将策略改变推送给组管理服务器40。例如,为了这个目的,CSE 36可以定义和使用特殊通知。作为另一示例,可由组管理服务器40创建并保持可扩展标记语言(XML)(或类似的)文档以存储策略。该XML文档可以通过策略ID引用。然后,可以由托管事件的CSE 36使用开放移动联盟(OMA)XML文档管理(XDM)技术来更新此XML文档。
以类似于上述讨论的方式,组42中的接收者38可以提交要作为事件通知的接收者被移除的请求。在基于组的实施例中,移除请求被发送给组管理服务器40而不是CSE 36。然后可以由组管理服务器40应用移除策略,以便以与上面关于非基于组的实施例所描述的类似的方式来确定是准予还是拒绝该移除请求。
图9A和图9B示出了根据本公开的一些实施例的图3B的M2M系统32的操作。如图所示,订阅发起者34与组管理服务器40通信,以创建包括接收者38的组42,其中该接收者38在本示例中为rec-1和rec-2(步骤700)。此时,订阅尚未创建。因此,接收者38可以被称为组42的成员、预期接收者38或目标。组管理服务器40响应于请求而创建组42,并向订阅发起者34发送包括组42的组ID的响应(步骤702)。
订阅发起者34然后与CSE 36通信以创建对由CSE 36托管的事件的订阅,其中组ID被提供作为针对订阅的接收者38的标识符(步骤704)。此外,在一些实施例中,当创建订阅时,订阅发起者34还提交针对组42的策略(例如,移除和/或通知策略)。在一些实施例中,所述策略是针对组42中各个接收者38的策略(即,策略分别应用于接收者38)。然而,在一些实施例中,一个或多个(或甚至全部)策略是可用于组42中的所有接收者38的一般策略。订阅发起者34将事件与组ID和订阅绑定(步骤706),并且CSE 36将策略与事件和订阅绑定(步骤708)。CSE 36可以响应订阅发起者34以确认已经创建了订阅(步骤710)。
在某个时刻,一旦发生事件,CSE 36向组管理服务器40发送该事件的通知(步骤712)。在一些实施例中,针对在创建订阅之后的第一通知,CSE 36还向组管理服务器40提供针对订阅的策略。这些策略可在通知中提供或单独提供。组42的组ID被包括在通知中。对于还提供策略的第一通知,组管理服务器40向策略指派策略ID,并向包括策略ID的CSE 36发送响应(步骤714)。CSE 36将策略ID与事件、订阅、组ID和适用的策略绑定(步骤716)。如上所述,策略ID使得CSE 36能够在订阅发起者34随后改变策略的事件中更新策略。组管理服务器40将策略与事件、事件相关信息、组ID和策略ID绑定(步骤718)。
一旦从CSE36接收到事件的通知,组管理服务器40使用组ID来标识对应组42中的接收者38。在该示例中,组42中的接收者38是rec-1和rec-2。值得注意的是,尽管未示出,但在一些实施例中,通知策略可以由订阅发起者34定义。如果通知策略被定义,则组管理服务器40应用该通知策略来确定组42中的哪些成员/接收者将接收该通知。在该示例中,组管理服务器40将事件的通知发送给组42中的接收者38(rec-2)(步骤720)。在一些实施例中,发送给接收者38的事件的第一通知还包括组42的组ID。在这种情况下,如果需要,接收者38(rec-2)存储组ID以便稍后使用(步骤722)。例如,接收者38(rec-2)可以随后使用组ID来请求作为接收者的移除。在一些实施例中,接收者38(rec-2)可以向组管理服务器40发送响应以确认通知的接收(步骤724)。以同样的方式,组管理服务器40将事件的通知发送给组42中的接收者38(rec-1)(步骤726)。在一些实施例中,发送给接收者38的事件的第一通知还包括组42的组ID。在这种情况下,如果需要,接收者38(rec-1)存储组ID以便稍后使用(步骤728)。在一些实施例中,接收者38(rec-1)可以向组管理服务器40发送响应以确认通知的接收(步骤730)。除了标识组42,组ID使接收者38(rec-1)能够与组管理服务器40通信,以便在它希望作为事件通知的接收者被移除的情况下发起请求。该过程可以以这种方式继续,使得针对事件的附加发生向接收者38发送附加通知。
在该示例中,在某一时刻,组42中的接收者38中之一(rec-2)希望作为事件通知的接收者被移除。这样,接收者38(rec-2)向组管理服务器40发送移除请求(步骤732)。该移除请求包括组42的组ID以及事件的标识符(事件ID)。值得注意的是,事件ID可以被包括在事件的每个通知或第一通知中。组管理服务器40然后应用与组ID和事件相关联的移除策略,以确定是否移除作为事件通知的接收者的接收者38(rec-2)(步骤734)。详细情况如上关于针对非基于组的实施例的CSE 36所述。例如,在一些示例中,移除策略指示是否需要来自订阅发起者34的批准来移除作为事件通知的接收者的接收者38(rec-2)。另外或备选地,根据移除策略,可以考虑其他标准(例如,一天中的时间、接收者38的地理位置等)。重要的是,即使允许移除,接收者38(rec-2)作为事件通知的接收者被移除,但不从组42中移除。这在例如订阅发起者34针对多个订阅使用相同的组42的情况下可能是特别有益的。可选地,组管理服务器40向接收者38(rec-2)发送响应以指示移除请求是被接受还是拒绝(步骤736)。
图10是根据本公开的一些实施例更详细地示出图9B的步骤734的流程图。对于该讨论,该过程由组管理服务器40执行。如图所示,为了应用移除策略,在一些实施例中(即可选地),组管理服务器40确定移除策略是否不允许在任何条件下移除接收者38(步骤800)。如果不是,则该过程进行到步骤814(下面讨论)。如果该策略确实允许至少在某些条件下移除接收者38,则CSE 36确定是否满足除订阅发起者34的批准之外的任何移除策略要求(步骤802)。可以使用任何合适的要求。然而,在一些具体实施例中,这些要求可以基于如上所述的诸如一天中的某个时间和/或接收者38的地理位置等标准。如果不满足这些要求(如果有的话),则过程进行到步骤814(下面讨论)。否则,组管理服务器40确定移除策略是否需要来自订阅发起者34的批准(步骤804)。
如果不需要订阅发起者34的批准,则该过程进行到步骤810(下面讨论)。然而,如果需要订阅发起者34的批准,则组管理服务器40向订阅发起者34发送批准移除作为针对订阅的事件通知的接收者的接收者38的请求(步骤806)。该请求可以包括例如标识接收者38的信息(例如,接收者ID)、标识事件的信息(例如,事件ID)和/或标识订阅的信息(例如,订阅ID)。组管理服务器40然后响应于该请求确定是否接收到来自订阅发起者34的批准(步骤808)。如果不是,则该过程进行到步骤814(下面讨论)。
如果在步骤804中不需要批准,或者如果在步骤808中接收到来自订阅发起者34的批准,则组管理服务器40移除作为针对订阅的事件通知的接收者的接收者38,但不将接收者38从组42移除(步骤810)。结果,接收者38将不再接收来自组管理服务器40的针对订阅的事件的通知,但是接收者38保留在组42中。同样,如果相同的组42用于多个订阅,这可能是特别有益的。可选地,组管理服务器40向接收者38发送响应以通知接收者38:接收者38作为事件通知的接收者已成功地被移除(步骤812)。虽然未示出,组管理服务器40还可以向订阅发起者34发送消息以通知订阅发起者34接收者38已被移除。
如果在步骤800中移除策略被确定为不允许在任何条件下移除接收者38,或者如果在步骤802中不满足移除策略要求,或者如果在步骤808中没有接收到来自订阅发起者34的批准,则组管理服务器40将接收者38保持为事件通知的接收者(即,组管理服务器40不移除接收者38)(步骤814)。可选地,组管理服务器40向接收者38发送响应以通知接收者38该移除请求被否定或被拒绝(步骤816)。虽然没有示出,但组管理服务器40还可以向订阅发起者34发送消息以通知订阅发起者34来自接收者38的移除请求已经被拒绝。
图11A和图11B示出了根据本公开的一些实施例的根据图10的过程的组管理服务器40处理来自接收者38的移除请求的操作。图11A和图11B的过程与图6A和图6B的过程相同,但是其中组管理服务器40处理移除请求而不是CSE 36。具体地,图11A示出了移除策略不需要来自订阅发起者34的批准的情况,而图11B示出了移除策略确实需要来自订阅发起者34的批准的情况。如图11A所示,组管理服务器40接收来自接收者38的移除请求,如上所述(步骤900)。组管理服务器40然后对接收者38应用移除策略。具体地,组管理服务器40验证与接收者38和事件相关联的移除策略(步骤902)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。在此示例中,移除策略不需要来自订阅发起者34的批准,并且满足所有其他移除要求(如果有)。因此,组管理服务器40移除作为事件通知的接收者的接收者38,但不将其从组42中移除(步骤904)。此外,在该示例中,组管理服务器40向接收者38发送指示移除请求被接受的响应(步骤906),并且向订阅发起者34发送移除接收者38的通知(步骤908)。移除的通知标识接收者38、组42、事件和订阅。
相反,在图11B中,组管理服务器40接收来自接收者38的移除请求,如上所述(步骤1000)。组管理服务器40然后对接收者38应用移除策略。具体地,组管理服务器40验证与接收者38和事件相关联的移除策略(步骤1002)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。在此示例中,移除策略确实需要来自订阅发起者34的批准。因此,组管理服务器40向订阅发起者34发送批准请求(步骤1004)。所述批准请求是请求来自订阅发起者34的批准以移除作为事件通知的接收者的接收者38。批准请求标识接收者38、组42、事件和订阅。订阅发起者34通过接受或授予请求(即,给予批准)或通过拒绝该请求(即,不予批准)来响应该批准请求(步骤1006)。组管理服务器40然后在订阅发起者34给予批准的情况下移除作为事件通知的接收者的接收者38,或者在订阅发起者34没有给予批准的情况下不移除作为事件通知的接收者的接收者38(步骤1008)。在该示例中,组管理服务器40向接收者38发送指示是接受还是拒绝移除请求的响应(步骤1010)。
图9A和9B至图11A和11B的实施例至少部分地涉及移除组42中作为事件通知的接收者的接收者38中之一。如上文关于非基于组的实施例(特别是图7)所讨论的,在一些实施例中,可以提供自动加回功能以将先前移除的接收者38自动添加回来作为事件通知的接收者。在这方面,组管理服务器40可以例如执行图7的处理以确定是否将先前移除的接收者38添加回来作为事件通知的接收者。
如上所述,在一些实施例中,组管理服务器40可以应用与组42和事件相关联的通知策略以确定是否将事件的通知发送给组42中的特定接收者38。在这方面,图12是示出根据本公开的一些实施例的组管理服务器40应用通知策略、并且作为通知策略的结果向组42中的接收者38发送或不发送事件通知操作的流程图。如图所示,在该示例中,组管理服务器40检测事件的发生(步骤1100)。组管理服务器40将索引(i)设置为1(步骤1102),然后确定组42中的接收者i是否满足通知策略(步骤1104)。如果通知策略被满足,则组管理服务器40向接收者i发送该事件的通知(步骤1106)。否则,组管理服务器40不向接收者i发送事件的通知(步骤1108)。组管理服务器40确定组42中的最后接收者38是否已被处理(步骤1110)。如果是,则过程结束。如果否,则计数器i递增(步骤1112),并且该过程返回到步骤1104并重复。以这种方式,组管理服务器40根据与组42中的接收者38和事件相关联的通知策略,选择性地将事件的通知发送给组42中的接收者38。
如上所述,在一些实施例中,订阅发起者34可以使用相同组42(即,相同的组ID)来创建对由相同CSE 36(或不同的CSE)托管的事件的多个订阅。在这方面,图13示出了根据本公开的一些实施例的图3B的M2M系统32能够使用相同的组ID来进行附加订阅(即,除了例如图9A和图9B的订阅之外)的操作。值得注意的是,在该示例中,附加订阅是针对由同一CSE36托管的事件,但附加订阅可以是针对由另一CSE托管的事件。
如图所示,订阅发起者34与CSE 36通信以创建对由CSE 36托管的事件的附加订阅,其中,组ID被提供为针对附加订阅的接收者38的标识符(步骤1200)。此外,在一些实施例中,当创建订阅时,订阅发起者34还提交针对组42的策略(例如,移除和/或通知策略)。再次,至少在一些实施例中,所述策略是针对组42中各个接收者38的单独策略。订阅发起者34将事件与组ID和订阅(步骤1202)绑定,并且CSE 36将策略与相应的事件和附加订阅绑定(步骤1204)。CSE 36可以响应订阅发起者34以确认已经创建了订阅(步骤1206)。
在某个时刻,一旦事件发生,CSE 36向组管理服务器40发送针对事件的通知(步骤1208)。从此时开始,该过程如上所述进行,使得事件的通知被发送给组42中的接收者38。此外,如上所述,如果需要,接收者38可以针对特定事件请求移除,并且这些请求由组管理服务器40根据相应的通知策略来处理。
图14示出了根据本公开的一些其它实施例的图3B的M2M系统32的操作。具体地,在图9A和图9B的实施例中,订阅发起者34与组管理服务器40通信以创建组42。然而,在图14的实施例中,CSE 36与组管理服务器40通信以创建组42。否则,操作与上面关于图9A和图9B描述的操作相同。
如图所示,订阅发起者34与CSE 36通信以针对接收者38的组42创建对事件的订阅(步骤1300)。此时,尚未利用组管理服务器40创建组42。因此,订阅发起者34提交针对订阅的接收者38列表。如上所述,订阅发起者34还可以提交针对接收者38的策略(例如,通知和/或移除策略)。CSE 36与组管理服务器40通信以创建组42(步骤1302)。作为响应,组管理服务器40向CSE 36返回组42的组ID(步骤1304)。
从此时开始,该过程如上面关于图9A和图9B的步骤708-730所述进行。特别地,CSE36将策略与事件、组ID和订阅绑定(步骤1306)。CSE 36响应订阅发起者34以确认已经创建了订阅(步骤1308)。虽然未示出,订阅发起者34保持针对所创建的订阅所需的绑定信息。在某个时刻,一旦发生事件,CSE 36向组管理服务器40发送该事件的通知(步骤1310)。在一些实施例中,针对在创建订阅之后的第一通知,CSE 36还向组管理服务器40提供针对订阅的策略。这些策略可在通知中提供或单独提供。组42的组ID被包括在通知中。对于还提供策略的第一通知,组管理服务器40向策略分配策略ID,并向包括策略ID的CSE 36发送响应(步骤1312)。CSE 36将策略ID与事件、绑定到订阅和组ID绑定(步骤1314)。如上所述,策略ID使得CSE 36能够在订阅发起者34随后改变策略的事件中更新策略。组管理服务器40将策略与事件、事件相关信息、策略ID和组ID绑定(步骤1316)。
一旦从CSE36接收到事件的通知,组管理服务器40使用组ID来标识对应组42中的接收者38。在该示例中,组42中的接收者38是rec-1和rec-2。值得注意的是,虽然未示出,但是在一些实施例中,通知策略可以由订阅发起者34定义。如果通知策略被定义,则组管理服务器40应用该通知策略来确定组42中的哪些成员/接收者将接收该通知。在该示例中,组管理服务器40将事件的通知发送给组42中的接收者38(rec-2)(步骤1318)。在一些实施例中,发送给接收者38的事件的第一通知还包括组42的组ID。在这种情况下,如果需要,接收者38(rec-2)存储组ID以便稍后使用(步骤1320)。在一些实施例中,接收者38(rec-2)可以向组管理服务器40发送响应以确认通知的接收(步骤1322)。以同样的方式,组管理服务器40将事件的通知发送给组42中的接收者38(rec-1)(步骤1324)。在一些实施例中,发送给接收者38的事件的第一通知还包括组42的组ID。在这种情况下,如果需要,接收者38(rec-1)存储组ID以便稍后使用(步骤1326)。在一些实施例中,接收者38(rec-1)可以向组管理服务器40发送响应以确认通知的接收(步骤1328)。该过程可以以这种方式继续,使得针对事件的附加发生向接收者38发送附加通知。
虽然未示出,如上所述,在某个时刻,组42中的接收者38之一可能希望作为事件通知的接收者被移除。当发生这种情况时,接收者38向组管理服务器40发送移除请求。移除请求由组管理服务器40处理,结果是接收者38作为事件通知的接收者被移除或不被移除,但仍保留在组42中。
图15A和图15B中示出了移除过程的两个示例。具体地,图15A示出了移除策略不需要来自订阅发起者34的批准的情况,而图15B示出了移除策略确实需要来自订阅发起者34的批准的情况。如图15A所示,组管理服务器40接收来自接收者38的移除请求,如上所述(步骤1400)。移除请求通常是移除作为事件通知的接收者的接收者38的请求。在一些实施例中,移除请求包括组ID、事件的事件ID、订阅标识符和接收者38的标识符。组管理服务器40然后对接收者38应用移除策略。具体地,组管理服务器40验证与接收者38和事件相关联的移除策略(步骤1402)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。
在此示例中,移除策略不需要来自订阅发起者34的批准,并且满足所有其他移除要求(如果有)。因此,组管理服务器40移除作为事件通知的接收者的接收者38,但不将其从组42中移除(步骤1404)。作为响应,组管理服务器40向接收者38发送指示接收者38作为事件通知的接收者已被移除的响应(步骤1406)。此外,在该示例中,组管理服务器40向CSE 36发送接收者38作为事件通知的接收者已经被移除的通知(步骤1408)。除了标识移除的接收者和事件之外,所述通知还标识订阅(例如,包括订阅ID)和组42(组ID)。CSE 36然后向订阅发起者34发送接收者38作为事件通知的接收者已被移除的通知(步骤1410)。除了标识移除的接收者和事件之外,所述通知还标识订阅(例如,包括订阅ID)和组42(组ID)。在该示例中,订阅发起者34向CSE 36发送响应以例如确认通知的接收(步骤1412),并且CSE 36向组管理服务器40发送响应以例如确认通知的接收(步骤1414)。
相反,在图15B中,组管理服务器40接收来自接收者38的移除请求,如上所述(步骤1500)。组管理服务器40然后对接收者38应用移除策略。具体地,组管理服务器40验证与接收者38和事件相关联的移除策略(步骤1502)。在该示例中,验证包括确定是否需要来自订阅发起者34的批准。此外,验证可以包括确定是否满足一个或多个附加的移除标准,如上所述。
在此示例中,移除策略确实需要来自订阅发起者34的批准。因此,组管理服务器40例如经由CSE 36向订阅发起者34发送批准请求(步骤1504)。所述批准请求是请求来自订阅发起者34的批准以移除作为事件通知的接收者的接收者38。批准请求标识接收者38、组42、事件和订阅。订阅发起者34通过接受或授予请求(即,给予批准)或通过拒绝该请求(即,不予批准)来响应该批准请求(步骤1506)。组管理服务器40然后在订阅发起者34给予批准的情况下移除作为事件通知的接收者的接收者38,或者在订阅发起者34没有给予批准的情况下不移除作为事件通知的接收者的接收者38(步骤1508)。在该示例中,组管理服务器40向接收者38发送指示是接受还是拒绝移除请求的响应(步骤1510)。
在上面关于图3A和3B至图15A和15B所描述的实施例中,策略有时用于控制通知和/或接收者的移除。值得注意的是,针对每个订阅/事件和/或每个接收者38,可以由订阅发起者34独立地配置策略。在其他实施例中,策略可以在接收者38之间和/或事件订阅之间重复使用。
如上所述,订阅发起者34关于针对个人接收者38或组42的特定事件提供的策略对CSE 36(非组实施例)或组管理服务器40(基于组的实施例)关于发送所述事件的通知和/或处理来自所述接收者38的移除请求所采取的操作提供完全的控制。例如,这些策略可以控制目标是否应该接收事件的通知,和/或如何处理从事件通知的接收者38发起的移除请求。所以策略是非常灵活的,以便完成不同的目标。值得注意的是,在一些实施例中,如果订阅发起者34没有提交针对任何或所有接收者38的策略,则可以应用预定义的默认策略。
订阅发起者34提供的策略可以包括例如策略适用于该位置内的目标的地理位置(因此,例如,针对接收者38的策略可以说,如果接收者38位于一个地理区域内,则接受来自接收者38的移除请求,但是如果接收者38位于另一个地理区域中则拒绝)。可以使用任何合适的技术来获得接收者38的地理位置。作为另一示例,策略也可以使用一天中的时间作为输入,其中策略可以在一天中的特定时间内应用于特定目标,并且另一策略适用于一天中的另一时间。重要的是,地理位置和一天中的时间只是个示例。根据需要或期望,另外或备选地,还可以使用其他输入/标准。因此,根据具体情况,针对每个目标提供的策略可以是有条件的,并且可以应用多于一个策略。因此有完整的灵活性。
关于基于组的实施例描述的另一特征是:相同的组42可以用于多个订阅。此外,通过策略,组42的不同子集可以接收不同事件的通知。例如,可以定义针对组42订阅的第一事件的组42的策略,使得组42的第一子集接收第一事件的通知,以及可以定义针对组42订阅的第二事件的组42的策略,使得组42的第二子集(不同于第一子集)接收第二事件的通知。使用策略来控制组42的哪些成员接收特定事件的通知的一个优点是:即使组42中的某些成员与某些事件不相关,也可以在不同的上下文(事件)中使用相同的组42。作为创建新组的替代,同一组42可以重用于新的事件订阅,但是针对新事件订阅的配置策略可以包括:例如,该事件通知不被发送给组42的某些成员的策略(或者相反地,将该事件通知仅发送给组42的某些成员的策略)。这允许重用相同的组42,而不需要创建新组,从而获得优化。
图16是根据本公开的一些实施例的节点44的框图。根据本公开的一些实施例,节点44可以是或可以实现订阅发起者34、CSE 36、接收者38或组管理服务器40。节点44包括一个或多个处理器46或处理器电路(例如,一个或多个中央处理单元(CPU)、专用集成电路(ASIC)或现场可编程门阵列(FPGA))、存储器48和一个或更多个通信接口50。通信接口50可以包括蜂窝接口52(例如,能够与蜂窝通信系统的无线电接入网络进行通信的接口或无线电)和/或网络接口54(例如,有线或无线接口,诸如光纤接口、以太网接口或WiFi接口)。在一些实施例中,订阅发起者34、CSE 36、接收者38或组管理服务器40的功能以存储在存储器48中并由处理器46执行的软件来实现。
在一些实施例中,提供一种包括指令的计算机程序,所述指令当由至少一个处理器执行时使得该至少一个处理器执行根据本文所述的任何一个实施例的节点44的功能。在一个实施例中,提供了包含上述计算机程序产品的载体。所述载体是电子信号、光信号、无线电信号或计算机可读存储介质(例如,诸如存储器48的非暂时计算机可读介质)之一。
图17示出了根据本公开的一些其它实施例的节点44。这里,节点44实现CSE 36。在该示例中,CSE 36以软件实现并且包括订阅接收模块56,可选地(即,在一些实施例中)包括组创建模块58、事件通知模块60,以及可选地(即,在一些实施例中)包括接收者移除模块62。如上所述,订阅接收模块56用于使诸如订阅发起者34之类的订阅发起者能够创建对由CSE 36托管的事件的订阅。在一些基于组的实施例中,组创建模块58用于与组管理服务器40通信,以创建针对订阅由CSE 36托管的事件的接收者38的组42,如上所述。事件通知模块60用于向适当的接收者发送事件的通知。值得注意的是,在基于组的实施例中,从CSE 36的角度看,接收者是组42,在这种情况下,如上所述,通知被发送给组管理服务器40而非各个接收者38。可选地(即,在一些实施例中),CSE 36还包括用于处理从接收者38接收到的移除请求的接收者移除模块62,如上所述。
图18示出了根据本公开的一些其它实施例的节点44。这里,节点44实现组管理服务器40。在该示例中,组管理服务器40以软件实现,并且包括组管理模块64、事件通知模块66和接收者移除模块68。组管理模块64用于提供与创建组相关的功能(例如,创建组42,包括响应于创建组42的请求而将组ID分配给组42)。如上所述,事件通知模块66用于向组42中的接收者38发送通知。如上所述,接收者移除模块68用于处理从接收者38接收到的移除请求。
贯穿本公开使用以下缩写词。
AE应用实体
AND应用专用节点
API应用编程接口
ASIC专用集成电路
ASN应用服务节点
CPU中央处理器
CSE公共服务实体
CSF公共事务功能
FPGA现场可编程门阵列
ID标识符
IN基础架构节点
IoT物联网
M2M机器对机器
MN中间节点
NoDN非oneM2M设备节点
NSE网络服务实体
OMA开放移动联盟
TS技术规范
XDM可扩展标记语言文档管理
XML可扩展标记语言
本领域技术人员将认识到对本公开的实施例的改进和修改。所有这些改进和修改被认为落入本文公开的构思和所附权利要求的范围内。
Claims (21)
1.一种在机器对机器M2M通信系统(32)中的公共服务实体CSE节点(34,36)执行的能够移除通知接收者(38)的操作的方法,包括:
向一个或多个接收者(38)发送事件的通知,所述一个或多个接收者(38)通过订阅发起者(34)订阅所述事件的通知,并且与所述订阅发起者(34)不同;
接收来自所述一个或多个接收者(38)中的接收者(38)的移除请求,所述移除请求是移除作为事件通知的接收者的所述接收者(38)的请求;
基于针对所述接收者的移除策略,确定是否允许移除作为所述事件通知的接收者的所述接收者(38);
确定移除策略是否需要来自订阅发起者(34)的批准,其中所述移除策略指示在允许移除接收者(38)之前需要订阅发起者(34)的批准,并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括:请求订阅发起者(34)批准移除作为事件通知的接收者的所述接收者(38),以及一旦接收到来自订阅发起者(34)的批准,确定允许移除作为事件通知的接收者的所述接收者(38);以及
一旦确定允许移除作为事件通知的接收者的所述接收者(38),移除作为事件通知的接收者的所述接收者(38)。
2.根据权利要求1所述的方法,还包括:一旦确定不允许移除作为所述事件通知的接收者的所述接收者(38),拒绝移除作为所述事件通知的接收者的所述接收者(38)。
3.根据权利要求1所述的方法,其中所述移除策略指示在允许移除所述接收者(38)之前是否需要所述订阅发起者(34)的批准。
4.根据权利要求1所述的方法,其中所述移除策略指示在允许移除所述接收者(38)之前不需要所述订阅发起者(34)的批准,并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括:在没有来自订阅发起者(34)的输入的情况下,确定是否允许移除作为事件通知的接收者的所述接收者(38)。
5.根据权利要求1所述的方法,其中,所述移除策略包括在允许移除作为事件通知的接收者的所述接收者(38)之前必须满足的一个或多个定义的标准。
6.根据权利要求5所述的方法,其中所述一个或多个确定的标准包括以下中的至少一个:事件发生的一天中的时间和接收者(38)的地理位置。
7.根据权利要求1所述的方法,其中,所述接收者(38)的移除策略还包括:用于将所述接收者(38)自动添加回来作为所述事件通知的接收者的一个或多个标准,并且所述方法还包括:
在移除作为事件通知的接收者的所述接收者(38)之后,一旦确定满足用于将所述接收者(38)自动添加回来作为所述事件通知的接收者的所述一个或多个标准,将所述接收者(38)添加回来作为所述事件通知的接收者。
8.根据权利要求1所述的方法,其中所述一个或多个接收者(38)包括多个接收者(38),并且针对所述多个接收者(38)中的至少两个接收者中的每一个定义单独的移除策略。
9.根据权利要求1所述的方法,其中所述一个或多个接收者(38)包括多个接收者(38),并且所述移除策略是针对所述多个接收者(38)的全部或子集定义的公共移除策略。
10.根据权利要求1所述的方法,还包括:
在向接收者(38)发送所述通知之前,基于接收者(38)的通知策略确定是否要向接收者(38)发送所述通知;以及
向接收者(38)发送所述通知包括:一旦基于所述接收者(38)的通知策略确定要将通知发送给所述接收者(38),向所述接收者(38)发送所述通知。
11.根据权利要求10所述的方法,其中,所述接收者(38)的所述通知策略基于一个或多个定义的标准。
12.根据权利要求11所述的方法,其中所述一个或多个定义的标准包括以下中的至少一个:一天中的时间和接收者(38)的地理位置。
13.根据权利要求1-12中任一项所述的方法,还包括:在向所述一个或多个接收者(38)发送所述事件的通知之前:
从所述订阅发起者(34)接收对所述事件的通知的订阅,其中,所述订阅是针对所述一个或多个接收者(38)的对所述事件的通知的订阅,并且所述接收者(38)的移除策略与所述订阅相关联。
14.根据权利要求1-12中任一项所述的方法,还包括:
接收创建包括所述一个或多个接收者(38)的组(42)的请求;
用针对所述组(42)的组标识符来响应创建组(42)的所述请求;以及
接收具有作为所述通知的接收者(38)的标识符的所述组标识符的所述事件的通知;
其中,向所述一个或多个接收者(38)发送所述事件的通知包括:响应于接收具有作为所述通知的接收者(38)的所述组标识符的标识符的所述事件的通知,向所述组(42)中的所述一个或多个接收者(38)发送所述事件的通知。
15.根据权利要求14所述的方法,其中,发送给所述组(42)中的所述一个或多个接收者(38)的所述事件的通知包括所述组标识符。
16.根据权利要求14所述的方法,其中,移除作为所述事件通知的接收者的所述接收者(38)包括:移除作为所述事件通知的接收者的所述接收者(38),但不从所述组(42)中移除。
17.根据权利要求14所述的方法,其中所述一个或多个接收者(38)是所述组(42)中的多个接收者(38)的子集,并且所述方法还包括:
接收具有作为不同事件的通知的接收者(38)的标识符的所述组标识符的所述不同事件的通知、以及针对所述不同事件的通知的一个或多个策略;以及
根据针对所述不同事件的通知的所述一个或多个策略,向所述组(42)中的多个接收者(38)的子集发送不同事件的通知。
18.根据权利要求17所述的方法,还包括:接收针对所述组(42)中针对所述不同事件的通知的接收者(38)的一个或多个通知策略,其中针对所述组(42)中针对所述不同事件的通知的接收者(38)的所述一个或多个通知策略标识所述组(42)中不接收所述不同事件的通知的所述多个接收者(38)中的至少一个。
19.一种机器对机器M2M通信系统(32)中能够移除通知接收者(38)的公共服务实体CSE节点(44),包括:
一个或多个通信接口(50);
至少一个处理器(46);以及
存储器(48),包含由所述至少一个处理器(46)执行的软件,由此所述CSE节点(44)操作用于:
经由所述一个或多个通信接口(50)向一个或多个接收者(38)发送事件的通知,所述一个或多个接收者(38)通过订阅发起者(34)订阅所述事件的通知,并且与所述订阅发起者(34)不同;
经由所述一个或多个通信接口(50)接收来自所述一个或多个接收者(38)中的接收者(38)的移除请求,所述移除请求是移除作为事件通知的接收者的所述接收者(38)的请求;
基于针对所述接收者(38)的移除策略,确定是否允许移除作为所述事件通知的接收者的所述接收者(38);
确定移除策略是否需要来自订阅发起者(34)的批准,其中所述移除策略指示在允许移除接收者(38)之前需要订阅发起者(34)的批准,并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括:请求订阅发起者(34)批准移除作为事件通知的接收者的所述接收者(38),以及一旦接收到来自订阅发起者(34)的批准,确定允许移除作为事件通知的接收者的所述接收者(38);以及
一旦确定允许移除作为事件通知的接收者的所述接收者(38),移除作为事件通知的接收者的所述接收者(38)。
20.一种机器对机器M2M通信系统(32)中能够移除通知接收者(38)的公共服务实体CSE节点(44),包括:
用于向一个或多个接收者(38)发送事件通知的装置,所述一个或多个接收者(38)通过订阅发起者(34)订阅所述事件的通知,并且与所述订阅发起者(34)不同;
用于接收来自所述一个或多个接收者(38)中的接收者(38)的移除请求的装置,所述移除请求是移除作为事件通知的接收者的所述接收者(38)的请求;
用于基于针对所述接收者(38)的移除策略来确定是否允许移除作为所述事件通知的接收者的所述接收者(38)的装置;
用于确定移除策略是否需要来自订阅发起者(34)的批准的装置,其中所述移除策略指示在允许移除接收者(38)之前需要订阅发起者(34)的批准,并且确定是否允许移除作为所述事件通知的接收者的所述接收者(38)包括:请求订阅发起者(34)批准移除作为事件通知的接收者的所述接收者(38),以及一旦接收到来自订阅发起者(34)的批准,确定允许移除作为事件通知的接收者的所述接收者(38);以及
用于一旦确定允许移除作为事件通知的接收者的所述接收者(38)移除作为事件通知的接收者的所述接收者(38)的装置。
21.一种计算机可读存储介质,存储有计算机程序,所述计算机程序当在至少一个处理器上执行时使所述至少一个处理器执行根据权利要求1-18中任一项所述的方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/IB2015/051713 WO2016142741A1 (en) | 2015-03-09 | 2015-03-09 | Dynamic event subscriptions for m2m communication |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107431722A CN107431722A (zh) | 2017-12-01 |
CN107431722B true CN107431722B (zh) | 2021-01-08 |
Family
ID=52727190
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201580077676.3A Active CN107431722B (zh) | 2015-03-09 | 2015-03-09 | M2m通信的动态事件订阅 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20170048646A1 (zh) |
EP (2) | EP3754504B1 (zh) |
CN (1) | CN107431722B (zh) |
WO (1) | WO2016142741A1 (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016126021A1 (ko) * | 2015-02-06 | 2016-08-11 | 엘지전자 주식회사 | 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치 |
US10070411B2 (en) * | 2015-06-15 | 2018-09-04 | Intel Corporation | Batch notification in oneM2M environments |
US10819780B2 (en) * | 2015-12-24 | 2020-10-27 | Mcafee, Llc | Protected data collection in a multi-node network |
KR102524674B1 (ko) * | 2016-12-14 | 2023-04-21 | 삼성전자주식회사 | 전자 장치 및 그의 알림 서비스 제공 방법 |
CN110557744B (zh) * | 2018-05-31 | 2022-08-19 | 华为技术有限公司 | 订阅事件的方法与网络功能网元 |
US12028430B2 (en) | 2018-11-28 | 2024-07-02 | Beijing Boe Technology Development Co., Ltd. | Event notification method, server device, apparatus and computer storage medium |
CN111245875B (zh) | 2018-11-28 | 2022-03-04 | 京东方科技集团股份有限公司 | 事件通知方法、设备、装置和计算机存储介质 |
WO2023092504A1 (zh) * | 2021-11-26 | 2023-06-01 | Oppo广东移动通信有限公司 | 订阅控制方法、装置、计算机设备及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1953426A (zh) * | 2005-10-19 | 2007-04-25 | 国际商业机器公司 | 用于管理订阅的发布/订阅系统和方法 |
CN102457938A (zh) * | 2010-10-18 | 2012-05-16 | 中兴通讯股份有限公司 | 终端接入限制的方法及系统 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102014144A (zh) * | 2009-09-04 | 2011-04-13 | 华为技术有限公司 | 一种终端数据上报方法和装置 |
CN102255931B (zh) * | 2010-05-21 | 2017-04-05 | 山东金佳园科技股份有限公司 | 一种物联网架构下统一的通知方法及系统 |
US8943132B2 (en) * | 2011-09-12 | 2015-01-27 | Telefonaktiebolaget L M Ericsson (Publ) | Systems and methods for optimization of subscriptions to resource changes in machine-to-machine (M2M) systems |
US9324055B2 (en) * | 2011-12-08 | 2016-04-26 | Microsoft Technology Licensing, Llc | Techniques to manage remote events |
US9680787B2 (en) * | 2013-02-15 | 2017-06-13 | Blackberry Limited | Electronic message distribution lists |
US20160119270A1 (en) * | 2014-10-28 | 2016-04-28 | International Business Machines Corporation | Stakeholder notification |
-
2015
- 2015-03-09 CN CN201580077676.3A patent/CN107431722B/zh active Active
- 2015-03-09 WO PCT/IB2015/051713 patent/WO2016142741A1/en active Application Filing
- 2015-03-09 US US14/437,252 patent/US20170048646A1/en not_active Abandoned
- 2015-03-09 EP EP20179671.1A patent/EP3754504B1/en active Active
- 2015-03-09 EP EP15711876.1A patent/EP3268861B1/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1953426A (zh) * | 2005-10-19 | 2007-04-25 | 国际商业机器公司 | 用于管理订阅的发布/订阅系统和方法 |
CN102457938A (zh) * | 2010-10-18 | 2012-05-16 | 中兴通讯股份有限公司 | 终端接入限制的方法及系统 |
Non-Patent Citations (1)
Title |
---|
RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification;A. B. Roach;《Internet Engineering Task Force,IETF》;20020601;1-4节 * |
Also Published As
Publication number | Publication date |
---|---|
EP3754504B1 (en) | 2022-03-02 |
CN107431722A (zh) | 2017-12-01 |
EP3268861A1 (en) | 2018-01-17 |
WO2016142741A1 (en) | 2016-09-15 |
US20170048646A1 (en) | 2017-02-16 |
EP3754504A1 (en) | 2020-12-23 |
EP3268861B1 (en) | 2020-07-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107431722B (zh) | M2m通信的动态事件订阅 | |
CA2787935C (en) | System and method for location privacy and location information management over wireless systems | |
US10015684B2 (en) | Method and apparatus for managing specific resource in wireless communication system | |
US10375021B2 (en) | Method and apparatus for processing request for stopping notification receipt in wireless communication system | |
US10129852B2 (en) | Method for broadcasting to unspecified entity in wireless communication system and device for the same | |
US20170311303A1 (en) | Method for guaranteeing operation of control message in wireless communication system and device for same | |
US10142805B2 (en) | Method for managing child resource of group member in wireless communication system and device for same | |
US20150012598A1 (en) | Techniques to generate mass push notifications | |
CN112567684B (zh) | 支持核心网络中订阅事件的方法、设备和计算机可读介质 | |
CN108141447B (zh) | 服务层注册 | |
US20170238279A1 (en) | Method for processing notification message in wireless communication system and apparatus therefor | |
US20170257726A1 (en) | Method for processing request message in wireless communication system and apparatus therefor | |
CN113892279A (zh) | 资源订阅方法、设备、服务器以及计算机存储介质 | |
EP2866379B1 (en) | Method and device for enabling or disabling server in wireless communication system | |
CN112930689B (zh) | 用于批量订阅的过滤器 | |
CN105101412A (zh) | 通知消息的发送方法及装置 | |
US10271296B2 (en) | Method for changing schedule information in wireless communication system and device therefor | |
US20120167179A1 (en) | Flexible multimedia priority services | |
US11134365B2 (en) | Resource link management at service layer | |
US20180373772A1 (en) | Method for maintaining synchronization of resources in wireless communication system, and apparatus therefor | |
US11470034B2 (en) | Method and apparatus for receiving and transmitting periodic notification in machine to machine system | |
WO2023217746A1 (en) | Authorizing federated learning | |
JP2014186696A (ja) | Push配信ゲートウェイサービスシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |