CN112805981A - 用于服务层的主题和数据的动态代理和管理的框架 - Google Patents

Abstract

本文中描述了用于服务层中的数据代理服务的框架的方法和装置。第一装置可以从第二装置接收包括第一信息的第一信号，所述第一信息表明与主题指标相关联的发布意向。第一装置可以从第三装置接收包括第二信息的第二信号，所述第二信息表明与所述主题指标相关联的订购意向。第一装置可以基于所述发布意向和订购请求生成主题事例。第一装置可以发送包括表明所生成的主题事例的声明消息的第三信号。第一装置可以从第三装置接收包括针对所生成的主题事例的订购请求的第四信号。第一装置可以向第三装置发送包括与所生成的主题事例相关联的通知和发布事例的至少一个第五信号。

Description

用于服务层的主题和数据的动态代理和管理的框架

相关申请的交叉引用

本申请要求2018年11月28日提交的美国临时专利申请号62/772,493的权益，该申请通过引用的方式被全文合并在本文中。

背景技术

数据是基于数据生产者设定和配置而不是基于消费者使用或含义来组织的。在许多情况下，数据的含义和使用对于多个消费者是共同的。但是消费者无法提出基于兴趣(或者数据被消费的方式)来组织信息的方式，所述信息随后可以由其他消费者使用并且服务层平台随后可以为之提供数据管理。

通过标签和/或语义描述传达的数据含义通常可以由生产者或其他实体指派，并且通常与各项单独的资源驻留在一起，因此共同含义是分布式的。因此，在服务层中需要改进的数据代理(brokerage)服务。

发明内容

提供本发明内容部分是为了以简化形式介绍将在后面的具体实施方式部分中进一步描述的概念当中的一部分。本发明内容部分不意图标识出所要求保护的主题内容的关键特征或必要特征，也不意图被用来限制所要求保护的主题内容的范围。此外，所要求保护的主题内容不受限于解决在本公开内容的任何部分中提到的任何或所有缺点的限制。

在本文中描述了用于服务层中的数据代理服务的框架的方法和装置。根据一个实施例，第一装置可以从第二装置接收包括第一信息的第一信号，所述第一信息表明与主题指标相关联的发布意向。第一装置可以从第三装置接收包括第二信息的第二信号，所述第二信息表明与所述主题指标相关联的订阅意向。第一装置可以基于所述发布意向和订阅请求生成主题事例。第一装置可以发送包括表明所生成的主题事例的声明消息的第三信号。第一装置可以从第三装置接收包括针对所生成的主题事例的订阅请求的第四信号。第一装置可以向第三装置发送包括与所生成的主题事例相关联的通知和发布事例的至少一个第五信号。

附图说明

为了促进对于本申请的更稳健的理解，现在将参照附图，其中相同的单元由相同的附图标记指代。这些附图不应当被解释为限制本申请，而是仅仅意图是说明性的。

图1是描绘出oneM2M服务层的oneM2M分层模型的图示；

图2是支持通用服务功能(CSF)的初始集合的示例性oneM2M服务层的图示；

图3是用于消息交换和操作的示例性规程的图示；

图4是用于一般资源发现的示例性规程的图示；

图5是一个示例性使用实例的图示；

图6是系统图示；

图7是系统图示；

图8是用于服务层中的主题和数据代理处理的各个阶段的逻辑表示的示例性规程的图示；

图9是用于通过与代理者的直接登记来提供消费者/生产者角色的示例性规程的图示；

图10是用于由登记者向代理者提供消费者/生产者信息的示例性规程的图示；

图11是用于基于明确请求的主题创建的示例性规程的图示；

图12是用于基于声明的主题创建的示例性规程的图示；

图13是用于基于一般订阅的主题创建和发布的示例性规程的图示；

图14是用于基于长期资源发现或查询的主题创建和发布的示例性规程的图示；

图15是用于明确长期发现或查询请求的示例性规程的图示；

图16是用于明确事例发布的示例性规程的图示；

图17是用于主题广告的示例性规程的图示；

图18是用于发现的示例性规程的图示；

图19是主题访问控制策略(ACP)的图示；

图20是支持数据代理通用服务功能(CSF)的示例性oneM2M服务层的图示；

图21是用于代理管理的示例性图形用户界面(GUI)的图示；

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

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

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

图22D是可以在其中具体实现图22A的通信系统的各个方面的示例性计算系统的方块图。

具体实施方式

在本文中描述了用于服务层中的数据代理服务的框架的方法和装置。本文中所描述的框架可以提供基于主题的数据管理，其目标是使得数据更容易发现、消费和广告。服务层平台可以使用基于主题的数据代理来组织和曝光数据，其方式与数据被消费并且将数据含义嵌入到消费者的方式一致。本文中所描述的框架可以向RESTful服务层提供一个基于主题的Pub/Sub代理的覆盖层，其中使用现有的服务层机制作为自动产生主题和主题事例的触发，并且可以确定发布或订阅意向、确定广告兴趣等等。

数据生产者可以将数据作为常规资源或者所声明的资源(同步)直接存储在服务层。数据消费者可以通过发现/查询来发现数据。为了消费更新后的数据，消费者可以订阅单独的资源。当多于一项资源提供相同的信息时，可能需要单独发现和订阅每一项资源。消费者还可以重复发现/查询请求。这对于发现提供相同信息的新资源可能也是有用的。可以为数据指派通过标签和/或语义描述来传达的含义。通常还可以由生产者指派含义，从而反映出所意图的含义。还可以由其他实体来指派含义，但是这可以由不同实体以不同方式进行，并且含义通常与单独的资源驻留在一起。

本文中所描述的方法和装置是针对以动态地适配于发现/查询或订阅请求、适配于新声明的数据等等的方式来发布数据的服务层服务。所述服务可以将数据组织在感兴趣的主题中，并且可以允许数据生产者和消费者松散地耦合并且独立地操作。在本文中描述了包括从服务层动作和信息确定兴趣和广告范围的广告服务。本文中描述了为受约束的物联网(IoT)设备提供数据存储、预处理和安全性的附加价值服务。本文中描述了用主题信息扩展发现范围并且将其重定向到系统参与者的服务。此外还描述了基于参与者的强度来提供对于发布和通知消息的仲裁以及保持参与者的活跃度的状态。

下面是本文中使用的术语的缩写列表：

AE——应用实体

ACP——访问控制策略

CSE——通用服务实体

CSF——通用服务功能

IoT——物联网

M2M——机器对机器通信

RDF——资源描述框架

URI——统一资源标识符

下面是本文中使用的术语的定义列表：

通用服务实体(CSE)：用于通用服务功能的集合的实例化的oneM2M术语。

寄主节点：寄放各种资源的M2M服务节点。所寄放的资源可以由其他M2M实体访问和订阅。

M2M实体：现场和基础设施域中的参与在M2M通信中的任何节点。

M2M服务节点：寄放支持用于M2M通信的一项或多项服务能力的服务层的网络节点。

始发者：发起针对RESTful操作的请求消息的实体。例如其中始发者正尝试通过RETRIEVE来实施资源发现的CSE。

服务层：位于M2M应用与提供数据传输的通信HW/SW之间的软件中间件层。该层跨越不同的工业部门为M2M应用提供通常所需要的功能。

接收者：接收到具有RESTful操作的请求消息的实体，该实体对所述请求消息进行处理并且发送相应的响应消息。

图1是描绘出oneM2M服务层的oneM2M分层模型100的图示。已经针对健康护理行业、能源行业和汽车行业开发了允许机器/设备彼此通信的M2M解决方案。下一步的优化是提供将来自不同行业的机器和事物整合在相同的平台上的解决方案。为此目的，oneM2M发起了定义用于独立于工业门类在应用之间交换和共享数据的水平平台的单个标准集合。类似于操作系统，oneM2M通过创建一个分布式软件层提供了一种用于与不同的技术互工作的框架。该分布式软件层被实施在位于M2M应用(例如应用层101)与提供数据传输的通信HW/SW(例如网络服务层103)之间的通用服务层102中。

图2是支持通用服务功能(CSF)200的初始集合的示例性oneM2M服务层的图示。所述服务层由CSF赋予功能。如图2中所示，一组CSF可以被实例化为通用服务实体(CSE)201上的一个群组。CSF及其功能的实例可以包括以下各项：

应用和服务层管理CSF 202：可以提供对于AE和CSE的管理。

发现CSF 203：可以基于一些过滤标准来搜索关于应用和服务的信息。

登记CSF 204：可以提供使得AE(或者其他远程CSE)与CSE进行登记的功能。这样可以允许所述AE(或者远程CSE)使用所述CSE的服务。

通信管理/递送处理CSF 205：可以提供与其他CSE、AE和NSE的通信。该CSF可以决定在什么时间用哪一个通信连接来递送通信，以及在必要并且允许的情况下决定缓冲通信请求，从而可以在后来的某个时间转发所述通信请求。

群组管理CSF 206：可以提供对于群组相关请求的处理，并且允许M2M系统支持例如多个设备、应用等上的批量操作。

安全性CSF 207：可以为服务层提供安全功能，比如包括识别、授权和认证的访问控制。

数据管理和储存库CSF 208：可以提供数据存储和媒介功能(例如收集数据以供聚合，重新格式化数据，以及存储数据以供分析和语义处理)。

位置CSF 209：可以提供允许AE获得地理位置信息的功能。

服务计费和记账CSF 210：可以为服务层提供计费功能。

设备管理CSF 211：可以提供对于M2M网关和M2M设备上的设备能力的管理。

网络服务曝光、服务执行和触发CSF 212：可以管理与下方网络的通信以用于访问网络服务功能。

订阅和通知CSF 213：可以提供允许订阅事件并且在该事件发生时得到通知的功能。

oneM2M架构可以使得CSE 201通过Mca参考点214、Mcc(和Mcc’)参考点215和Mcn参考点216接口到其他实体，其中包括但不限于：应用实体(AE)217；其他CSE；以及网络服务实体(NSE)218(也就是下方网络)。

图3是用于消息交换和操作的示例性规程300的图示。图3的示例性规程可以管控oneM2M中的信息交换，并且可以是基于使用请求和响应消息。在一个实例中，始发者301可以向接收者302发送请求消息310。接收者302可以向始发者301发送响应消息311。规程300可以应用于AE与CSE之间(通过Mca参考点)以及CSE之间(通过Mcc参考点)的通信。取决于消息所载送的操作，这些规程可以通过RESTful方法在标准化资源表示中操纵信息，比如CREATE(创建)、RETRIEVE(取回)、UPDATE(更新)和DELETE(删除)。请求和响应消息都可以被规定，并且包含强制性、可选或有条件参数。下面的表1提供了带有描述的请求参数列表。

表1：请求参数列表

上面的其中一些请求参数可以被使用在本文中所描述的发现操作中。

下面的表2提供了带有描述的响应参数列表。

表2：响应参数列表

资源发现是实体(例如图3的始发者)可以用来搜索包含在属性和资源中的关于应用和服务的信息的处理。在oneM2M中，资源发现的始发者可以是AE或CSE，并且可以把将在该处开始搜索的接收者CSE处的根资源作为目标。

搜索结果的内容可以通过匹配特定的搜索参数而取决于一些过滤标准(例如基于资源类型、资源创建时间、资源尺寸等等)。其他过滤标准参数(例如限制)连同一些操作参数(例如发现结果类型)可以在将搜索结果的内容提供回到始发者的方式中扮演角色。发现操作(例如CRUD发现操作)受限于接收者CSE处的访问控制策略，也就是说受限于始发者是否具有“DISCOVER(发现)”访问权。

提供在表3中的搜索参数列表在针对匹配所提供的过滤标准与具有其他角色的过滤标准(比如规定标准使用的类型或者返回结果的方式)之间作了区分。可以通过关系操作组合这些参数从而创建复合搜索标准。

表3：资源发现过滤标准

在oneM2M中，可以使用RETRIEVE方法来实施资源发现，其中使用filterUsage向接收者CSE表明在资源发现操作与一般取回操作之间作出区分。

图4是用于一般资源发现的示例性规程400的图示。始发者(CSE的AE)401和接收者CSE 402可以被认证和登记(步骤410)。始发者401可以向接收者CSE 402发出以资源<CSEBase>/<ae01>的特定子代资源为目标的资源发现请求(步骤411)。接收者CSE 402可以对所述请求进行处理，并且可以返回所发现的资源的适当列表(步骤412)。接收者CSE 402可以根据所发现的资源的DISCOVER特权来限制发现结果，并且可以根据其自身的本地策略改变过滤标准。如果无法返回所发现的资源的完全列表，接收者CSE 402可以警告始发者401(例如用标志)。接收者CSE 402可以发送资源发现响应(步骤413)，所述资源发现响应可以包括与过滤标准匹配的资源的地址列表。如果需要的话，取回所述地址所指向的资源可以是始发者401的责任。

可以使用服务层授权机制来控制对于寄放在服务层中的资源和/或服务的访问。授权可以涉及允许得到认证的登记者基于静态地置备的授权策略和所指派的角色来访问寄放在服务层中的资源和服务。授权策略可以包括定义给定的服务层登记者是否被允许访问寄放在服务层中的受保护资源或服务的规则集合。

服务层访问控制策略(ACP)可以定义哪些服务层登记者被允许访问哪些资源和服务，以及它们可以被允许在给定的资源或服务上实施哪些操作。在本文中所描述的实施例中，在与服务层授权相关联的授权功能之前要进行认证。

oneM2M定义了用来支持授权的<accessControlPolicy>资源。<accessControlPolicy>资源包括代表一个访问控制规则集合的privileges(特权)和selfPrivileges(自身特权)属性，从而定义哪些实体(由accessControlOriginators定义)具有在规定的情境内(由accessControlContexts定义)实施特定操作(由accessControlOperations)的特权，并且由CSE使用来对于特定资源做出访问决定。

一旦被配置，这些特权从服务层的角度看来通常是静态的。服务层不会动态地即时创建、更新或删除特权。

对于特定的特权属性，访问控制规则定义哪一个AE/CSE被允许进行哪一项操作，因此对于访问控制规则集合，如果某一项操作被集合中的一条或多条访问控制规则允许，则所述操作被允许。对于不属于<accessControlPolicy>资源类型的资源，用于这样的资源的通用属性accessControlPolicyIDs包含将该资源链接到<accessControlPolicy>资源的标识符的列表。

自身特权属性代表针对<accessControlPolicy>资源自身的访问控制规则集合。

表示在特权和自身特权属性中的访问控制规则集合由下面描述的3元组构成：

accessControlOriginators：被授权访问与该授权策略相关联的资源的服务层登记者集合(例如CSE-ID或AE-ID的列表)；

accessControlContext：oneM2M定义了下面三种类型的授权情境：accessControlTimeWindows(期间允许请求的时间窗口)；accessControlLocationRegions(登记者在访问资源时被允许处于的位置)；accessControlIpAddresses(被允许访问资源的登记者的IP地址)；

accessControlOperations：每一个得到授权的服务层登记者被授权实施的操作集合。oneM2M定义了以下操作：RETRIEVE，CREATE，UPDATE，DELETE，DISCOVER，NOTIFY。

accessControlPolicyIDs是许多oneM2M资源的通用属性。该属性包含<accessControlPolicy>资源的标识符列表。被索引的定义在<accessControlPolicy>资源中的特权属性决定谁被允许出于特定目的(例如取回、更新、删除等等)访问包含该属性的资源。oneM2M定义了将被应用的特定规则，例如某种资源类型是否不具有accessControlPolicyIDs属性定义，某种资源类型是否具有accessControlPolicyIDs属性定义但是accessControlPolicyIDs属性未被设定等等。

发布-订阅(Pub/Sub)软件系统可以使用这样的数据分发模型，其中数据不像点对点或客户端-服务器模型中那样被直接发送到特定接收者。相反，生成信息的实体(被称作“生产者”)使用种类或类别(被称作“主题”)来发布数据。类似地，对一个或多个主题表达出兴趣的实体(订阅者)仅接收感兴趣的消息，而不与发布者直接交互并且可能不具有关于发布者的知识。

消息主题可以提供一种用来广播异步事件通知的轻量型机制，并且可以允许软件组件连接到主题以便发送和接收这些消息。为了广播消息，比如发布者之类的组件可以简单地将消息推送到主题。虽然类似于消息队列，但是消息主题的不同之处在于，消息主题在没有排队或者只有非常少的排队的情况下传送消息，并且将消息立即推出到所有订阅者。除非例如由订阅者设定了消息过滤策略，否则订阅主题的所有组件都接收到所广播的每一则消息。

存在两种常见形式的消息过滤：基于主题和基于内容。在基于主题的系统中，消息被发布到主题或者被命名为逻辑信道。基于主题的系统中的订阅者接收到被发布到他们所订阅的主题的所有消息，并且一个主题的所有订阅者都接收到相同的消息。发布者负责定义订阅者可以订阅的消息的种类。在基于内容的系统中，如果消息的属性或内容与订阅者所定义的约束匹配，则这些消息被递送到订阅者。订阅者负责对消息进行分类。

一些系统支持二者的混合：发布者将消息张贴到主题，订阅者将基于内容的订阅登记到一个或多个主题。

Pub/Sub消息传送系统的优点是松散耦合和可缩放性。发布者松散耦合到订阅者，并且所有发布者都被允许保持忽视系统拓扑并且独立于彼此进行操作。在许多RESTful系统使用的传统的紧密耦合的客户端-服务器范例中，当服务器处理未在运行时客户端无法将消息张贴到服务器，并且除非客户端正在运行否则服务器也无法接收消息。许多pub/sub系统不仅将发布者和订阅者的位置解耦，而且还将其在时间上解耦。

与传统的客户端-服务器交互相比，通过并行操作、消息高速缓存、基于树或基于网络的路由等等，消息传送Pub/Sub为更好的可缩放性提供了机会。但是在某些类型的紧密耦合或高容量环境中(比如企业)，随着系统规模扩大以及服务器共享pub/sub基础设施，这一好处可能会变小。

在企业环境之外，通过使用接受更高时延和缺少递送保证以交换使得即使是低端web服务器也能将消息同步到大量订阅者节点的能力的协议，pub/sub范例已证明其达到远超出单个数据中心的容量的可缩放性。

图5是一个示例性使用实例500的图示。在图5的示例性使用实例中，M2M网关501可以从多个M2M应用502接收发现请求510。比如由于飓风所导致的紧急事件要求来自救援组织的迅速动作并且后果具有高风险。为了优化救援服务，需要向一组多样的紧急服务提供者提供关于例如水平面和道路可通过性之类的量度的最新信息。在图5的实例中，可以从多个M2M应用502接收针对水平面和道路可通过性的发现请求510。

此外，所需要的信息是非常具体(例如5英里半径内的可通过道路，没有具体目的地)、动态和异类的。假设来自公共域(例如公用设施服务、城镇)和紧急服务(例如应急车辆位置和速度)的数据也是可用的。但是在这样的情况下，其他利害攸关者(例如市民、公司等等)可以使得附加的数据来源可用。

举例来说，救援组A可以将5英里半径作为救援或医疗服务的目标。为了确定区域内的可通过道路，可用的指标很少，因此任何可能的指示都是有用的。举例来说，任何车辆的速度都是道路可通过性的良好指标，并且可以从车辆和摄影机全部二者获得信息。类似地，在该事例中可以由城镇提供街道水平面，比如公园和公共设施中的环境监测系统。该数据由于被用于不同的目的，因此可以被分开存储。

假设一个利益相关方(例如团队A的紧急协调员)已识别出应当在资源发现中使用的信息类型和发现过滤器，例如可以从区域内的交通摄影机以及车辆的位置和速度获得相关的道路可通过性信息，则可以随着相关车辆改变周期性地重新进行发现请求。此外，可以由其他应用基于来自不同用户的请求而发送新的发现请求(例如来自其他救援组织或者来自市民)，尽管所请求的数据的目的和含义可能与早前的发现中相同。这也可能要求其他用户首先确定将产生该信息的相关信息类型和发现过滤器。此外，来自替换来源的数据可能需要被再次重新解释，例如必须重新评估可以互换使用来自不同传感器(例如utilityWaterSensorX和environmentWaterSensorY)的水平面的事实。

传统的服务层技术缺少在这样的情形中从相异的设备集合收集、组织和曝光数据(例如#passabilityCanalStreet、#waterLevelAlgiersWest主题)并且为单独的应用提供最新的状态和含义的能力。采用现有的发现和查询方法导致非常大的请求开销。

用于在服务层曝光数据的现有机制被没有反映出数据被消费的方式的发布者的范例所主导。但是一些IoT部署要求例如由订阅者在网关以及基础设施节点处以动态方式创建用于发布的主题。

本文中描述了用于服务层中的数据代理服务的框架的方法和装置。本文中描述了在发布-订阅主题模型内接收和处理针对管理系统数据的请求的服务层服务。由系统参与者提供的信息可以被用来保持所述发布-订阅系统的拓扑。

可以通过域和主题来配置系统数据，从而允许参与者保持松散耦合并且独立于彼此进行操作。数据配置可以是基于预先配置。替换地或附加地，数据配置可以是基于明确或隐含的请求，所述请求是基于以下各项的至少其中之一：提供全面主题信息的来自其他服务层实体的明确请求；提供全面主题信息的预先配置；用于创建相关联的主题的资源订阅请求和标准；长期查询/发现请求或者资源发现或查询请求的历史；以及表明应当创建相关联的主题的资源声明请求和指标。所述指标包括以下替换方案的其中之一：所声明的资源属性，声明消息参数，声明消息目标，以及所声明的资源的ACP。

本文中描述了用于在发布-订阅主题模型内管理系统数据的服务层方法。所述方法包括由服务层基于服务层事件和触发自动创建主题事例，包括：所声明的资源的更新和相关的同步事件；长期查询/发现设定或者查询/发现的重复；以及相关的订阅事件。

所述方法包括：通过使用基于RESTful消息或者包括在资源声明消息中的指标的发布意向，动态地保持发布者的集合。所述方法包括：通过使用基于包括在长期发现消息中的指标的订阅意向，动态地保持订阅者的集合。

所述方法包括：通过确定用于主题或主题群组的广告范围并且利用几种替换方案发送主题的广告消息来促进系统数据组织，所述替换方案比如有带有广告指标的通知以及带有广告指标的专用RESTful消息。

所述方法包括：在创建经过后处理的主题事例之前，对于来自不同发布者的事例提供附加的处理。

所述方法包括：基于单独主题事例的访问控制策略，导出用于主体的访问控制策略。

所述方法包括：基于发布的强度和发布者的强度，提供对于发布消息的仲裁。

所述方法包括：基于订阅请求的强度和消费者的强度，提供对于订阅和通知的仲裁。

(后文中所描述的)图6到21示出了与用于服务层中的数据代理服务的框架相关联的各个实施例。在这些附图中，各个步骤或操作被示出为由一个或多个节点、装置、设备、服务器、功能或者网络实施。举例来说，所述装置可以单独操作或者彼此组合操作来实现本文中所描述的方法。本文中所使用的术语“装置”、“网络装置”、“节点”、“服务器”、“设备”、“实体”、“网络功能”和“网络节点”可以被互换使用。应当理解的是，在这些附图中示出的节点、设备、服务器、功能或网络可以代表通信网络中的逻辑实体，并且可以采用存储在这样的网络的节点的存储器中并且在所述节点的处理器上执行的软件的形式来实施，所述节点可以包括在后面所描述的图22A或22B中所示出的其中一种架构。也就是说，在图6到21中示出的方法可以采用存储在网络节点的存储器中的软件(例如计算机可执行指令)的形式来实施，所述网络节点比如是图22C或22D中示出的节点或计算机系统，其中可以存储计算机可执行指令，所述计算机可执行指令在由所述节点的处理器执行时实施在附图中示出并且在本文中所描述的步骤。还应当理解的是，在这些附图中示出的任何发送和接收步骤可以由所述节点的通信电路(例如分别是图22C和22D的电路34或97)在所述节点的处理器及其所执行的计算机可执行指令(例如软件)的控制下实施。还应当理解的是，本文中所描述的节点、设备和功能可以被实施为虚拟化网络功能。

图6是用于服务层的主题和数据的动态代理和管理的框架的系统图示600。本文中所描述的实施例是针对一种用于在RESTful系统中部署数据和资源分发Pub/Sub功能的框架。本文中所提出的机制允许数据发布者(例如图6的实例的发布者603、604和605)和订阅者(例如图6的订阅者601和602)在无需知道系统拓扑的情况下保持松散耦合并且彼此独立操作，从而实现更高的网络可缩放性和更加动态的拓扑。图6的订阅者601和602可以访问主题606和607，所述主题可以由策略608管理。

本文中所描述的框架允许RESTful、基于资源的服务层(例如oneM2M)以及Pub/Sub代理者(broker)之间的互工作。在本文中描述了服务层数据代理实体。代理者是出于使得信息可用于其他系统参与者(例如其他实体、用户等等)的目的而收集由IoT系统中的各种节点或实体生成的信息的实体。由代理者提供的服务包括代理者功能。

本文中所描述的技术适用于使用Pub/Sub数据分发模型的代理者，其中将被分发的数据由在本文中被称作“生产者”的实体生成。使得数据可用于在本文中被称作“消费者”的系统中的其他参与者。在发现感兴趣的数据之后，代理者Pub/Sub功能可以允许消费者订阅感兴趣的数据并且相应地得到通知，从而成为订阅者。代理者还可以将数据广告给系统中的其他实体，这是通过关于数据的信息或者可供订阅的数据的特性。

虽然系统中的任何实体都可以具有代理功能，但是本文中所描述的实例是针对被植入在比如网关之类的集中式实体中的代理者。所述代理者可以是或者可以不是用于消费者或生产者的服务层登记者。

在另一个实例中，代理者可以是一个单独的实体，SL实体(例如网关)可以与其进行交互，以便创建/删除主题并且向这些主题发布/取消发布数据。

本文中所描述的实例假设代理者被实施在服务层内，但是本文中所描述的方法可以被使用在其他部署中。数据可以由代理者以多种形式保持，例如资源或资源的拷贝，包括所声明的资源，从多种系统参与者到资源的链接。

生产者可以包括产生数据以用于通过代理者分发的系统中的任何实体。发布者可以包括已被链接到为其产生数据的一个或多个主题的生产者。所述链接处理可以被称作“将发布者添加到主题”。但是由于这是一个可以被隐含或抽象的处理，因此对于有潜力成为发布者的实体可以使用术语“发布者”以取代“生产者”。

消费者可以包括有兴趣利用由代理者保持的数据的系统中的任何实体。订阅者可以包括使用代理者的Pub/Sub功能来订阅感兴趣的数据并且仅被通知关于感兴趣的数据的消费者，而不与发布者直接交互并且可能不具有关于发布者的知识。

图7是用于服务层的主题和数据的动态代理和管理的框架的系统图示700。图7的实例示出了发布者701、702和703；订阅者704和705；代理者710；主题706和707；主题事例708和709；以及RESTful系统中的控制域711和状态域712。在RESTful服务层中，主题706和707可以包括代表用于一个彼此相关的数据对象(被称作“主题事例”，比如图7的主题事例708和709)的总集的容器的资源，所述数据对象例如通过通用的含义、内容类型等等相关。主题事例708可以属于相同的主题707，并且可以由不同的生产者(比如发布者702和703)提供。

在此情境中，主题事例可以包括在SL处通过发布处理变为可用的资源或数据对象。在RESTful服务层中，主题事例可以是资源、资源拷贝、去到资源的链接等等，并且相同的主题(例如主题706)可以包含由不同实体生成的主题事例(例如主题事例709)。

代理者710可以通过发布处理将主题事例曝光于订阅了亲代主题的消费者。图7的示例性系统描绘出其中三个发布者701、702和703可以为两个不同的主题706和707提供主题事例708和709的系统。当对于主题706和707的其中之一生成新的主题事例时，两个订阅者704和705可以得到通知712，但是即使对于相同的主题，基于对于每一个订阅者设定的处理标准(例如事例过滤)，通知712可以是不同的。主题706和707可以像任何其他资源那样被发现，或者受到从代理者710到消费者(例如订阅者704和705)的主动广告。

RESTful服务层主题概念可以不同于在Pub/Sub系统中所使用的概念，其中主题可以提供一种轻量型机制以广播异步事件通知，并且连接端点以便发送和接收这些消息。在这种情况下，主题可以包括同辈消息队列以用于将消息异步广播到系统的不同部分。

域(例如控制域711和状态域712)可以包括被用来结合生产者和消费者以用于进行通信的逻辑构造。系统可以对于其以数据为中心的通信使用一个或多个域，从而在各个域之间提供一定程度的隔离，例如代理者710可以对于每一个域使用不同的端口编号。图7的实例描绘出其中使用两个不同域的系统，一个用于控制信息(控制域711)，另一个用于状态信息(状态域712)。

图8是用于服务层中的主题和数据代理处理的各个阶段的逻辑表示的示例性规程800的图示。图8的实例描绘出为了提供主题Pub/Sub能力而将在RESTful服务层中引入的赋能因素。图8描绘出消费者801、代理者803和生产者804。图8的实例还描绘出请求者802，所述请求者802可以包括系统中的一般参与者，例如生产者、消费者或者具有全部两个角色的实体等等。请求者802还可以包括管理实体，比如另一个代理者等等。

参照图8，在第一阶段中，系统中的实体可以发现彼此及其能力(步骤810)。服务层登记可以被假设为先决条件，并且总体上允许服务层通信。不同的实体可以被发现，并且基于其能力可以作为生产者804、消费者801或者全部二者而成为系统中的参与者。

在第二阶段中，可以在代理者803处创建主题(步骤811)。正如本文中所描述的那样，这可以使用几种方法来实现。在系统实施分布式代理或多个代理者的情况下，该步骤可能涉及代理者之间或者管理实体与代理者之间的附加交互，从而导致创建新的主题。

在第三阶段中，新创建的主题可以由消费者801广告或发现(步骤812)。消费者801可以基于与主题相关的订阅请求和/或策略而在后来成为感兴趣的主题的订阅者。

在第四阶段中，生产者804可以作为发布者被添加到主题，随后他们可以在代理者803处发布事例，并且相应的通知可以被发送给订阅者(步骤813)。生产者804可以被添加到主题。

本文中描述了用于数据代理实体的SL表示。代理功能可以被实施在所述系统的任何SL实体中，或者可以由专用实体提供，服务层可以与所述专用实体进行交互以便创建/删除主题以及发布/取消发布。作为一个SL实体，代理者可以是或者可以不是用于所有消费者和生产者的服务层登记者。代理者可以被部署为比如网关之类的中心实体。为了提供该功能并且为了能够被发现，代理者可以寄放下面的表4中所详述的相关信息。可以替换地作为域描述的一部分对于每个域提供比如生产者和消费者列表之类的一些代理者信息。

表4、代理者信息/描述

在使用多个域的系统中，每一个域可以被描述为如下面的表5中所示。

表5、域

在服务层系统中，消费者可以是有兴趣从代理者接收关于感兴趣的主题的通知的系统中的任何实体。为了提供该功能并且为了能够被发现，消费者(或者其登记者)可以寄放具有如下面的表6中所示的描述信息的资源。比如consumerID和domainList之类的信息可以允许由系统中的其他实体发现，localConsumerPolicy可以由消费者自身使用。advertismentGuidance可以由代理者使用来确定主题的广告范围内的消费者。activeSubscriptionList可以对于本地处理被保持，或者可以被曝光于其他实体，所述其他实体随后可以很容易地发现由单个生产者发布的所有数据。

表6、消费者描述

生产者可以是为代理者处的主题产生数据的系统中的任何实体。生产者可以保持如下面的表7中所描述的本地信息。该信息的其中一些(比如producerID、domainList)可以允许由系统中的其他实体发现。localProduerPolicy可以由生产者自身使用。publicationCandidateList可以由代理者和消费者使用来确定可以由该生产者提供的潜在感兴趣数据。activePublicationList可以对于本地处理被保持，或者可以被曝光于其他实体，所述其他实体随后可以很容易地发现由单个生产者发布的所有数据。

表7、生产者描述

主题资源可以提供用于一个主题事例的总集的容器。在RESTful服务层中，主题事例可以被假设实施为资源或者去到资源的链接。此外，主题资源可以包括为给定的主题提供含义、情境和功能的属性。

代理者可以保持如下面的表8中所描述的主题信息。

表8、主题

虽然本文中所描述的代理者功能可以被实施为从服务层资源拷贝数据并且将其作为事例进行管理的独立式数据库，但是下面的描述假设代理者被实施为使得事例是SL资源或者去到SL资源的链接。属于一个主题的事例具有通过该主题的topicDataType单元所表明的(多种)数据类型。

在一个实例中，事例可以包括被识别为属于相同主题的单独存在的资源(或资源属性)。例如在oneM2M中，登记到网关的每一个应用可以创建一个<AE>资源。如果一个主题被定义为“registeredAEs”，则每一个<AE>资源可以成为该主题的一个事例。每一个事例可以在AE进行登记或者相应的资源被修改时变为可用。在这种情况下，topicDataType是由oneM2M定义的AE数据类型。这种情况可以允许代理者简单地通过保持被用作事例的资源的列表来保持主题。

在另一个实例中，事例可以包括从现有资源类型创建的新资源。被称作“数据变化”的这一处理通常由代理者提供，但是发布者也可以被允许实施这一处理。正如processingCriteria所表明的那样，用于实施数据变换的替换方案包括但不限于以下各项：

(1)添加元数据：在这种情况下，SL资源中可用的信息可以通过预定义的元数据被增强并且作为事例被存储。在前面的AE实例中，代理者可以被processingCriteria指示在接收到<AE>资源事例时(也就是在实施登记时)添加关于其自身位置的信息。这种情况下的数据类型可以是基于AE oneM2M AE数据类型，并且可以包括用于位置信息的字段。

(2)修剪资源信息：在这种情况下，可以通过使用其中一些属性从SL资源创建事例。在前面的AE实例中，每一个事例可以包括所接收到的<AE>资源的AE-ID、创建者和时间标记。所使用的数据类型是从AE数据类型导出的，并且可以包含相关的字段。

(3)事例过滤：在这种情况下，processingCriteria可以表明存储在代理者处的事例可以符合某些过滤规则。举例来说，所述策略可以表明应当仅存储具有最小时间分隔的事例，并且在间隔时间中接收到的事例可以被丢弃。其他类型的事例过滤可以表明例如相继的事例应当是来自不同的发布者，因此来自相同发布者的相继事例可以被丢弃。这种机制可以与ACP相结合使用来仲裁发布者如何被允许访问主题。

(4)内容过滤：在这种情况下，可以基于资源内容对事例进行过滤。在前面的AE实例中，如果AE-ID处在特定范围内，则所述策略可以允许事例创建。

虽然在某些情况下数据变换要求将事例与创建该事例的资源分开存储，但是代理者也可以被实施来使用指向现有资源的指针而无需将内容拷贝到新的位置。举例来说，oneM2M中的代理者实现方式允许基于<container>资源创建主题，并且基于子代<contentInstance>资源创建事例。在这种情况下，发布者可能不需要知晓代理活动。亲代<topic>资源可以使用containerIDReference指向容器，并且每一个事例可以包含相应的<contentInstance>的资源ID。在oneM2M中，除了<container>资源之外，对于内容共享资源也可以采用这种方法，比如flexcontainer和timeSeries。

在一些实施例中，可能会请求通过可能不相容的各种策略(或其他参数)来实施相同的主题。主题资源可以被允许具有子主题(具有与亲代相同的topicID)，从而使得每一个子主题具有满足一个或多个订阅者的需求的参数集合，同时能够被一起发现。新的发布者或订阅者随后可以选择具有可接受的参数的子主题。或者，主题资源可以具有一个或多个事例，并且其中一些参数(例如策略)适用于单独的事例。在后面的实例中，为了简单起见可以在不使用子主题的情况下考虑主题，但是子主题在一些实例中可以是非常有用的，例如用于发现相关的主题、群组订阅等等。

代理策略可以被用来提供关于系统中的各个主题代理功能方面的处理的信息。该信息可以是静态(例如预先置备)、半静态(例如在一段较长时间内对于整个域是通用的)或动态的(例如可以由参与者使用RESTful方法重新配置)。

下面的表9提供了对于所提出的若干策略的描述。下表反映出通过受到影响的功能逻辑划分成各种策略类型，例如如何创建主题，如何确定将被发送出去的广告的范围、类型、定时等等，但是也可以实施用于组织该信息的其他方式。策略可以使用具有可以通过多种方式实施的多个参数或属性的总体上复杂类型的数据或信息。描述列阐明策略的目的和含义，并且提供将被包括在复杂构造中的仅仅少数几个可能参数的实例。下表包括可用于系统中的不同参与者并且可以在初始预先置备步骤期间或者使用明确请求被提供给这些实体的策略，例如策略资源上的RESTful操作。

表9、策略

下面的资源属性可以被用来实现服务层中的主题代理服务：

allowTopic：可以存在于多种资源类型中的属性。如果被实施为布尔量，则该属性例如可以表明(如果为真)所述资源可以被用于可以在代理者处被发布的主题的创建。该属性还可以被实施成使得任何数值都可以表明允许主题的创建，并且所述数值本身可以被使用在创建规程中，例如作为topicDescription数值、作为semanticDescription等等。

createTopicCriteria：可以存在于某种类型的订阅的资源中的属性。该属性可以提供针对基于作为给定订阅的结果而发送的通知来创建主题的标准。

producesTopic：可以存在于多种资源类型中的属性。其数值可以包括使用该资源产生的主题的资源ID(或ID列表)。

arbitrationProposalStrength：可以存在于多种资源类型中的属性。当被包含在订阅资源中时，该属性可以表明对应于订阅的仲裁提议强度。当被包含在用来创建主题事例的其他资源类型中时，该属性可以表明对应于发布的仲裁提议强度。

下面所描述的消息参数可以被用来实现服务层中的主题代理服务：

topicIndicator：被如下使用的消息参数：

当存在于以代理者为目标的声明消息中时，该参数的数值可以提供生产者可以志愿向其进行发布的<topic>的资源ID。

当存在于通知消息中时，该参数的数值可以提供代理者正在广告的<topic>的资源ID。

当存在于具有默认或NULL(空值)数值的其他声明消息中时，该参数可以表明所述声明应当被用于新主题创建。

brokeragePolicy：可以被用来表明将被用于代理相关功能的策略的请求消息参数。

longTermDiscoveryIndicator：用于发现请求消息的参数，可以被用来表明所述请求将由接收者/代理者重复。当存在时，该参数可以提供用于重复、生命跨距、响应选项等等的参数。举例来说，该参数可以将这些参数提供为一个排序列表，提供为单独的从属消息参数，或者提供为包含该信息的资源的资源ID。

subscriptionIndicator：用于长期发现请求消息的参数，也可以被用于主题创建。通过包括该参数，请求者可以表明它请求一旦创建了主题则成为消费者。

brokerageDiscoveryIndicator：用于增强型发现请求消息的参数，可以具有几个数值。当包括该参数时，请求者可以提供由代理者使用来提供附加的发现相关功能的信息。

topicAdvertisementIndicator：可以被用来表明所述消息被用于主题广告的请求消息参数。

relatedTopicsIndicator：可以被用来表明与操作结果相关的主题的响应消息参数。

可以提供比如PUBLISH ACP操作之类的访问控制操作。PUBLISH ACP操作可以包括可以支持特权的增强型ACP，除了比如CREATE、RETRIEVE、UPDATE、DELETE之类的现有操作之外，所述特权还包括PUBLISH操作。资源可以具有ACP，所述ACP可以具有PUBLISH特权，所述PUBLISH特权可以被用来表明该资源可以被发布给代理者。

本文中描述了生产者和消费者发现。当设备加入服务层部署时，所述设备可以实施允许实体之间的通信的服务层登记。在登记之后，服务层资源可用于发现，在发现期间，系统中的实体被识别为消费者和生产者。这一处理导致consumerList和ProducerList被保持在代理者处(参见表4)。有许多种方法用于将系统中的实体指定为生产者、消费者或全部二者。

[明确/志愿]方法：图9是用于通过与代理者的直接登记来提供消费者/生产者角色的示例性规程900的图示。实体可以基于本地策略“志愿”(即使用明确/志愿)成为消费者、生产者或全部二者。举例来说，如图9中所示，可以在常规服务层登记处理期间提供该信息。在图9的实例中，生产者904可以向代理者903发送SL登记消息(步骤910)。消费者901可以向代理者903发送SL登记消息(步骤911)。当如在图9的实例中那样发送SL登记消息时，能力可以具体表明“消费者”、“生产者”、“消费者和生产者”或者“都不是”角色连同相关的参数，例如producerID、domainID、brokerID。或者，实体可以被明确地并且直接地(例如通过RESTful UPDATE消息)添加到保持在代理者处的consumerList和producerList(参见表4)。代理者可以在后来向其他实体(例如另一个SL登记者)发送消费者和生产者信息(或者声明所述信息)。可以使用其他表明角色的明确形式，例如通过使用群组并且随着成员加入或离开每一个群组而向其提供角色。

[声明]方法：在另一个实例中，每当代理者接收到创建所声明的资源的请求时，代理者可以基于策略向始发者指派“生产者”的角色。或者，所声明的资源可以具有指定的属性(例如allowTopic)，从而可以允许代理者对于主题创建考虑所述属性。与此同时，该属性可以被用作关于提供声明的实体可以被指定为生产者的指示。可以通过由代理者基于所声明的资源的ACP指定消费者来对此进行补充。

[能力和策略]方法：代理者可以从设备和应用的策略和其他能力推断出消费者/生产者角色。例如取决于实现方式，能够接收通知的任何设备或应用可以被自动指定为“消费者”，而无需任何其他明确指示。这些策略可以在代理者处被预先配置，通过图形用户界面(GUI)输入等等。

[委派/移除]方法：图10是用于由登记者向代理者提供消费者/生产者信息的示例性规程1000的图示。在其他部署或实现方式中，可以由代理者之外的其他实体收集或推断出关于生产者和消费者的信息。在图10的实例中，不同的登记者可以在登记时间获得生产者/消费者选择。举例来说，生产者1004可以向登记者1002发送包括比如producerID、domainID或brokerID之类的参数的SL登记消息(步骤1011)。消费者1001可以向登记者1002发送比如consumerID、domainID或brokerID之类的参数的SL登记消息(步骤1012)。登记者1002随后可以使用其他相关参数(例如domainID、brokerID)来选择代理者1003，并且使用例如RESTful UPDATE消息之类的消息为代理者1003配置附加的生产者(例如生产者列表)和消费者(例如消费者列表)(步骤1013)。虽然图10的实例描绘出在其他实体(即其他登记者1002)处使用前面的[明确/志愿]方法，但是在配置代理者之前，其他实体还可以使用[声明]和[能力和策略]方法。这种方法还允许在系统中使用分布式代理。

[代理者发现]方法：在另一个实例中，代理者可以在系统中实施常规和重复发现和/或查询请求，并且依赖于结果和策略(例如participantDiscoveryPolicy)来决定将哪些实体添加为生产者和消费者。举例来说，管理归属控制主题域的代理者可以发现寄放使用SAREF本体进行语义描述的资源的实体，并且自动将其添加为生产者和消费者。重复请求可以导致实体被移除或添加到列表。为此目的，代理者可以使用在生产者处可用的任何参数。举例来说，代理者可以使用publicationCandidateList属性来确定是否可以使用可供发布但是尚未被发布的资源。

本文中描述了用于主题创建和事例发布的几种方法，所述方法是基于所使用的下方服务层机制而给出的。在一些实例中，所采用的主题创建方法不需要与所采用的发布方法匹配。举例来说，基于声明创建的主题可以被使用明确请求发起成为发布者并且发布事例的生产者发现。发布者可以被添加到现有的主题。

图11是用于基于明确请求的主题创建的示例性规程1100的图示。在图11的实例中，得到授权的实体可以通过提供特定的输入而请求在代理者处创建主题。图11的规程1100可以由任何请求者使用来在系统中创建新的主题。请求者可以是消费者、生产者或者系统中的任何服务层实体。参照图11，主题请求者1101可以实施初始发现步骤，其中请求者1101发现(例如网关处的)代理者1102的功能、已经在代理者处可用的代理策略等等(步骤1110)。请求者1101可以向代理者1102发送创建主题请求消息(步骤1111)。所述消息可以包括初始创建主题所需的信息，正如表8中所描述的那样。其中一些主题相关信息(比如代理策略)可以已经在代理者处可用。代理者1102可以授权主题创建并且创建主题，例如相关联的<topic>资源(步骤1112)。代理者1102可以向请求者发送创建主题响应，从而确认主题的创建(步骤1113)。所述响应可以包括比如新创建的资源的资源ID之类的信息。

主题可以在代理者处被预先置备，或者本地功能可以允许主题的直接输入和管理。对于提供主题代理作为主要功能的系统，可以设想到可以使用与关于图11的实例所描述的类似的处理来预先置备主题。类似地，代理者功能可以包括具有GUI的管理功能，从而允许将被用于主题创建的信息的直接用户输入。所述预先置备或基于GUI的步骤可以对应于图11中的步骤1111，并且为代理者提供在步骤1112中被用于主题创建的相同信息。可以类似地通过基于GUI的响应来提供响应。

图12是用于基于声明的主题创建的示例性规程1200的图示。在图12的实例中，当数据被声明时，可以触发创建主题的处理，在所述主题中将发布声明数据的后续更新。在该例中，服务层声明规程被利用于主题创建。代理者可以接收例如使用创建请求中的标志或者Annc资源中的属性增强的声明，从而表明所声明的资源可以被用来创建主题。或者可以表明现有的主题。代理者可以对于创建验证主题匹配或适当性，并且可以创建主题。对于所声明的资源的后续更新可以由代理者使用来创建主题事例。

参照图12，生产者1202和代理者1201可以发现彼此及其能力(步骤1210)。生产者1202可以在代理者1201处实施主题发现。生产者1202可以在代理者1201处声明新的数据资源(步骤1211)。在例如oneM2M的RESTful系统中，这可以通过创建由原始资源的寄主自动同步的所声明的资源来实现。对于使得消息触发主题创建有几种替换方案：

(a)所声明的资源可以包括属性allowTopic，从而表明可以基于该资源创建主题。

(b)声明消息(即oneM2M中的创建消息)可以包含参数topicIndicator，其数值表明将要或者可以基于该声明创建主题。

(c)声明消息可以通过其目标(例如<Broker>资源)表明该消息将被用于主题创建。

(d)所声明的资源的ACP可以表明可以由代理者1201基于该资源通过其PUBLISH操作来创建主题。

当创建消息是常规资源类型而不是声明(annc.)类型时，也可以使用前面描述的替换方案a、b、c、d。各种指标(即以<Broker>资源为目标的allowTopic属性、topicIndicator消息参数，PUBLISH ACP操作)可以由代理者1201用作关于将要创建主题的指示。

步骤1211还可以由生产者1202使用来志愿作为用于现有主题的新发布者，并且具有以下替换方案：

消息以现有的<topic>资源为目标(<Broker>资源的子代)；以及消息以<Broker>资源为目标并且包括topicIndicator＝<Topic>。

在前面描述的替换方案中，由于生产者1202不是针对给定主题的现有发布者，因此该消息可以被解释为对于所述主题是志愿的。

参照图12，代理者1201可以例如使用producerPolicy和InstancePublicationPolicy来验证生产者1202作为针对主题的发布者的适当性，以便确定生产者是否可以成为发布者(步骤1212)。代理者1201可以使用topicCreationPolicy来确定topicID、domainID和对应于主题的其他参数的默认值。或者，声明消息可以包括brokeragePolicy消息参数以表明将要使用的策略。代理者1201还可以使用所声明的资源的semanticDescription来进一步确定如何初始地填充新的<topic>资源。代理者1201可以将生产者1202添加到主题的publisherList。如果步骤1211已经表明了主题，则代理者1201可以检查生产者1202成为针对主题的发布者的适当性，例如所述主题的ACP允许生产者1202进行发布。代理者1201还可以验证所产生的事例符合processingCriteria，或者可以对于给定的生产者实行livelinessPolicy。如果适当的话，代理者1201可以将生产者1202添加到主题的publisherList。

参照图12，代理者1201可以向生产者1202确认主题创建是成功的(步骤1213)。对于前面的替换方案a、b和c，这例如可以通过提供对于步骤1211中的请求的成功响应来进行，所述响应作为内容包括新创建的<topic>资源。举例来说，可以通过relatedTopicsIndicator响应参数来提供新创建的资源。此外，基于所述成功响应，代理者1201可以更新<Producer>资源的activePublicationList，或者生产者可以自行实施该动作。

生产者1202可以根据主题参数生成数据(步骤1214)。生产者1202可以取回用于该信息的<topic>资源。

可以由服务层在实体之间同步所声明的数据(步骤1215)。在oneM2M中，所声明的资源同步可以假设由原始资源的寄主(即生产者1202)实施。

代理者1201可以使用所声明的数据来创建新的主题事例(步骤1216)。举例来说，代理者1201可以使用关于所声明的数据的通知来创建新的事例。或者，代理者1201可以实施优化，从而使得更新自动产生新的事例，而无需服务层的明确参与。

在使用基于声明的方法时，比如图12的规程1200，至少一个发布者在主题创建时间可以是已知的。该规程还可以包括一种用于基于声明的事例发布方法。当生产者1202向服务层声明数据时也可以应用该方法(例如步骤1211是从生产者1202到SL1的声明)。该声明随后可以触发SL1向代理者1201发布该数据。

图13是用于基于一般订阅的主题创建和发布的示例性规程1300的图示。对于资源的订阅可以请求由代理者从所请求的通知自动创建主题及其事例。这可以允许其他参与者作为主题发现该信息，而不是提交附加的订阅请求。在图13的实例中，服务层订阅规程可以被利用于主题创建。对于一般资源的增强型订阅请求可以由代理者接收，例如通过接收填充有createTopicCriteria的针对订阅资源的创建请求。连同一般订阅的创建一起，代理者还可以创建主题资源，并且可以将其自身包括在一般订阅通知接收者中。代理者可以从相应的通知生成主题事例。或者，可以由createTopicCriteria表明现有的主题，并且可以被用来将所订阅资源作为生产者添加到所述主题。

参照图13，可以发生系统发现，其中请求者1301可以在代理者1302处发现感兴趣的资源(步骤1310)。可以在代理者1302处从主题请求者1301接收以感兴趣的资源为目标的创建资源订阅请求(步骤1311)。在RESTful系统中，该步骤可以通过包括订阅资源的创建操作来实现。在这种情况下，所提供的订阅资源填充有createTopicCriteria属性。

代理者1302可以使用createTopicCriteria，并且可以相应地创建主题资源(步骤1312)。代理者1302还可以根据订阅资源中的其他参数创建一般订阅。代理者1302可以包括(所订阅的)感兴趣的资源以作为新创建的主题的生产者。代理者1302可以包括订阅请求者以作为新创建的主题的消费者。

代理者1302可以向请求者1301确认订阅创建是成功的，并且可以在响应中包括关于新创建的主题的信息(步骤1313)。这例如可以通过提供针对步骤1311中的请求的成功响应来进行，所述响应可以包括指向新创建的主题的relatedTopicIndicator响应参数。

代理者1302可以使用通知数据来创建新的主题事例(步骤1314)。

可以基于长期资源发现或查询来创建和发布主题。当接收到长期资源发现时，可以触发创建主题的处理。服务层发现规程可以被利用于主题创建。保持在代理者处的主题可以通过由代理者实施重复或长期资源发现(或查询)请求而被创建和更新。长期资源发现请求是资源发现请求的延长，其中代理者在初始发现请求之后继续向请求者提供通知。代理者可以验证请求符合现有的策略并且得到授权，并且可以随后创建相应的主题资源。

用于基于长期资源发现或查询来创建和发布主题的方法包括但不限于以下替换方案：

(A)由已经填充有longTermDiscovery属性的针对主题的明确创建请求触发。代理者可以使用由longTermDiscovery属性提供的发现请求来首先确定规程，随后可以创建主题。

(B)由请求者使用明确长期发现请求触发。这可以包括服务层发现请求，所述服务层发现请求具有表明它是长期的并且应当基于其结果来创建<topic>资源的指示。

(C)由代理者基于过去的发现请求触发。在这种替换方案中，当代理者观察到已经从相同或不同的实体重复接收到相同的发现请求时，代理者将此等同于长期资源发现请求。

对于前面的每一种替换方案，processingCriteria参数可以被用于基于长期发现来管理主题，从而表明由代理者生成的事例可以是：实际的发现结果(即资源的总集)或查询结果；发现结果的特定属性，例如所发现的资源的计数，所发现的资源的所有创建者的列表等等；以及所发现的资源的内容的后处理结果，例如等于从来自所发现的所有<contentInstance>资源的内容导出的平均值的数值。

对于明确的替换方案(A和B)，在基于长期发现管理主题时，processingCriteria参数可以被用来表明由代理者生成的事例可以被创建。

所有长期发现请求方法还可以被用于长期查询，包括语义查询。代理者可以使用附加的主题参数来确定长期发现请求将如何被实施。举例来说，主题的maskList中的信息可以表明消费者希望被提供事例的速率。代理者随后可以选择对发现的重复进行定时以便满足这些要求。

图14是用于基于长期资源发现或查询的主题创建和发布的示例性规程1400的图示。在图14的实例中，可以接收包括longTermDiscovery资源属性的明确创建请求。代理者可以接收表明结果本身应当被用来创建主题的增强型资源发现请求。代理者可以验证请求符合现有的策略并且得到授权，并且随后可以创建相应的主题资源。代理者可以重复发现以便创建后续的主题事例。

参照图14，可以实施系统发现规程，期间请求者1401、生产者1403和代理者1402可以发现彼此及其能力(步骤1410)。请求者1401可以请求创建包括被用于主题创建的信息(例如<topic>资源参数)的主题，其中包括长期发现请求，也就是说资源属性longTermDiscovery包括发现请求(步骤1411)。代理者1402可以验证并且可以授权所述主题创建请求，并且随后可以实施所请求的资源发现或查询，并且随后可以存储结果(步骤1412)。代理者1402可以创建新的<topic>资源，并且可以使用发现请求topicCreationPolicy的结果来确定topicID、domainID和对应于资源的其他参数的默认值(步骤1413)。代理者1402还可以使用所发现的资源的semanticDescription来进一步确定如何初始地填充新的<topic>资源。代理者1402可以用其自身填充主题的publisherList。

代理者1402可以向请求者1401确认主题创建是成功的(步骤1414)。这例如可以通过发送针对步骤1411请求的成功响应来进行，所述响应作为内容包括新创建的<topic>资源。代理者1402可以重复资源发现，并且可以根据主题参数产生数据(步骤1415)。代理者1402可以将结果存储为给定的<topic>资源的事例。代理者1402在重复资源发现时可以使用优化，例如可以基于先前的结果使用受限制的范围，从而为具有消费者驱动的发现提供另外的优点。

主题可以由得到授权的请求者1401使用RESTful方法明确地删除，或者可以由代理者1402基于所提供的参数来删除，例如主题的定时参数中的寿命期或开始/停止时间(步骤1416)。或者，所允许的用于删除的方法可以由本地策略提供，例如longTermDiscoveryPolicy。

图15是用于明确长期发现或查询请求的示例性规程1500的图示。在图15的实例中，代理者可以作为触发接收服务层发现或查询请求，例如RESTful取回操作。参照图15，请求者1501、代理者1502和生产者1503可以实施系统发现(步骤1510)。可以从请求者1501接收SL发现或查询请求消息，其中包括关于它是长期的并且因此将由代理者1502重复和管理的指示(步骤1511)。这样的发现请求可以使用本文中所描述的longTermDiscoveryIndicator消息参数来实施。资源发现或查询请求还可以表明结果本身将被用来创建主题。这一指示可以使用被设定为NULL(空值)或默认数值的topicIndicator消息参数来实施，正如本文中所描述的那样。

代理者1502可以实施初始资源发现或查询(步骤1512)。如果发现消息包括被设定为NULL(空值)的topicIndicator，则代理者1502可以继续<topic>资源创建(步骤1513)。代理者1502对于属性默认值可以依赖于本地策略(例如longTermDiscoveryPolicy、createTopicPolicy)，或者可以使用在发现消息中由brokeragePolicy消息参数表明的策略。或者，代理者可以在检查到所发现的资源具有存在并且被设定为真的allowTopic属性之后继续到步骤1513。代理者随后可以将所接收到的发现请求存储在新创建的资源的longTermDiscovery属性中，并且将其自身存储在publisherList属性中。代理者1502可以例如通过relatedTopicsIndicator响应参数向请求者1501发送响应，其中包括关于新创建的主题的信息(步骤1514)。代理者1502可以重复资源发现和事例创建(步骤1515)。主题可以由得到授权的请求者使用RESTful方法明确地删除，或者可以由代理者基于所提供的参数来删除，例如longTermDiscoveryPolicy(步骤1516)。

发现或查询消息可以是长期的，而不具有主题创建指示，也就是说在所发现的资源中没有topicIndicator消息参数或者没有allowTopic属性存在并且被设定为真。在这种情况下，代理者1502可以在本地存储发现请求并且可以对其进行管理，从而在每次发现重复之后发送结果。图15的规程1500可以在服务层中实施长期发现请求，而无需明确实施主题代理。

或者，可以实施基于发现历史的隐含长期发现。在这种替换方案中，当代理者观察到已经从相同或不同的实体重复接收到相同的发现或查询请求时，代理者确定这是长期资源发现请求。其规程流程类似于在图15中描绘的流程，但是具有以下不同之处：

在步骤1512中，代理者1502可以接收之前已被重复实施的常规资源发现。代理者1502确定该重复可能与针对基于长期历史创建主题的请求相关联，也就是说与包括被设定为NULL(空值)的longTermDiscoveryIndicator和topicIndicator消息参数的创建主题消息相关联。代理者1502还可以使用能够从相关但是不一定完全相同的发现请求的历史集合导出长期发现或查询请求的算法。在这种情况下，可以基于本地策略或明确设定来确定代理者可以使用资源发现历史的方式。代理者随后可以如图15的步骤1513中所描述的那样继续专用主题资源的创建。代理者1502可以将用于导出主题的其中一些或所有发现或查询请求历史存储在associatedDiscoveryHistoryList中，其后来可以被用来为主题发现提供更多情境。在步骤1514中，代理者可以发送针对隐含地触发了主题创建的常规资源发现请求的响应。所述响应可以例如通过relatedTopicsIndicator响应参数包括关于新创建的资源的信息。代理者1502可以依赖于常规主题发现规程以使得消费者发现新创建的<topic>资源。或者，代理者1502可以向在过去重复实施了发现的实体声明新创建的资源。代理者1502还可以如步骤1515中所描述的那样重复资源发现和事例创建。代理者可以使用longTermDiscoveryPolicy来确定如何管理这样的主题的生命周期，例如默认的寿命期。举例来说，长期发现可以仅对于明确请求被允许，仅对于隐含请求被允许，或者对于二者都被允许。对于隐含长期发现，所述策略可以规定默认的寿命期，以及寿命期定时器是随着新接收到的发现请求还是基于资源创建时间而重新开始。

图16是用于明确事例发布的示例性规程1600的图示。在图16的实例中，新的生产者可以为现有的主题提供事例。在发现主题之后，可以确定生产者作为针对所述主题的发布者的适当性。如果适当的话，可以将生产者添加到主题的发布者列表，并且可以向代理者提供事例。图16的规程1600可以被采用来为在没有已知的初始发布者的情况下创建的主题提供发布者，以及将发布者添加到已经具有一个或多个发布者的主题。所描述的方法是可以与本文中所描述的任何主题创建替换方案一起使用的替换方案。所有主题创建方法都可以包括提供生产者的固定/设定列表作为发布者。所述角色可以由生产者通过主题广告、发现或预先置备(例如使用表7中的生产者描述)而发现。

在图16的规程1600中，可以为生产者1602提供关于适当的主题的信息。生产者1602可以确定它是否可以基于所接收到的主题信息来提供主题事例，如果主题是适当的，则生产者1602可以通过RESTful方法(例如UPDATE消息)来提供事例。参照图16，生产者1602可能已经发现了用于发布的适当主题(步骤1610)。这可以通过多种方式实现，例如通过代理者1601处的主题发现，通过代理者1601的主题广告，预先置备等等。生产者1602可以接收主题信息，例如在表8中描述的参数，包括相关联的策略(步骤1611)。该信息可以由生产者1602取回或者由代理者1601广告，或者可以由其他实体或者通过预先置备被提供给生产者1602。关于主题的可用信息可以由生产者1602使用来确定它是否可以满足针对该主题的发布者角色。举例来说，生产者1602可以使用producerPolicy和InstancePublicationPolicy来确定它是否可以成为针对该主题的发布者。生产者1602可以使用InstanceRetentionPolicy和InstancePersistencePolicy来确定它所能够产生的事例是否满足任何其他本地策略和设定。生产者1602可以使用定时参数来确定是否能够以必要的频率和定时产生事例。生产者1602可以使用主题的semanticDescription来进一步确定将要提供的事例是否与主题匹配。

参照图16，生产者1602可以向代理者通知其针对主题进行发布的意向(假设步骤1611中的验证允许)(步骤1612)。这例如可以通过更新主题的发布者列表来进行。代理者1602可以验证生产者1602作为针对主题的发布者的适当性(步骤1613)。除了比如在步骤1611中实施的那些检查之外，代理者1601例如可以验证主题的ACP允许生产者1602进行发布。代理者1601还可以验证它可以对于给定的生产者实施livelinessPolicy。在另一个实例中，系统可以完全依赖于代理者1601来发现生产者1602，并且可以验证其适当性，在这种情况下，步骤1611和1612可以被合并到步骤1613中。

代理者1601可以向生产者1602确认针对主题的发布已得到验证(步骤1614)。这例如可以通过更新activePublicationList来进行。生产者1602可以根据主题参数产生数据(步骤1615)。如果所述处理仅仅依赖于代理者1601来验证主题适当性，则生产者1602在此步骤还可以取回必要的主题信息。

生产者1602可以使用所述数据来创建新的主题事例，例如可以使用RESTful创建或更新消息来提供新的事例(步骤1616)。主题事例创建可以受到instancePublicationPolicy和instanceRetentionPolicy。举例来说，如果instancePublicationPolicy规定了发布速率并且消息过早到达，则明确的发布RESTful消息可能在代理者1601处失败。类似地，instanceRetentionPolicy可以决定哪些事例可以在特定时间可用。

在另一个实例中，由代理者产生的事例可以是基于针对所声明的资源的更新。所述规程类似于在前面关于图12的规程1200描述的基于声明的主题创建的步骤1215和1216中所描述的规程。在生产者可以发现适当的主题之后，它可以在步骤1211中利用以<topic>资源的一个事例为目标的消息来实施资源声明，或者在一种替换方案中是以<Broker>资源为目标并且包括topicIndicator＝<Topic>。代理者可以实施必要的验证，并且确认生产者作为针对给定主题的发布者。

随后，代理者可以在受到instancePublicationPolicy和instanceRetentionPolicy的情况下基于资源声明产生主题事例。举例来说，代理者可以基于instancePublicationPolicy中的发布速率产生新的事例，而不是所声明的资源被同步的速率。类似地，代理者可以使用instanceRetentionPolicy来确定在任何特定时间将使得哪些事例可用。

图17是用于主题广告的示例性规程1700的图示。在图17的实例中，代理者可以通过使用登记到所述域的利害攸关者(消费者和生产者)来促进主题发现。代理者可以通过代表生产者广告数据来促进数据共享。参照图17，生产者和消费者1701可以实施发现(步骤1710)。主题可能已在代理者1702处被创建。为了促进数据共享，代理者1702可以提供用于广告可用主题的服务。每一个主题可以具有确定比如广告的定时、频率和范围之类的参数的advertismentPolicy。此外，为此目的，消费者可能已在由代理者1702使用的localConsumerPolicy和advertismentGuidance参数中包括了广告相关的策略。代理者1702可以基于这些参数确定用于主题的广告范围(步骤1711)。例如假设代理者1702在步骤1712中基于策略决定向登记到特定主题(例如X)的所有消费者广告一个主题集合(例如A、B)，有几种用于实施广告的方法。

举例来说，(a)代理者1702可以向给定的消费者发送常规创建消息(步骤1712)。所述消息可以包含将被广告的资源的整个资源或所选参数，例如<topicA>、<topicB>。在另一个实例中，(b)代理者1702可以向给定的消费者声明主题A和B，也就是说在oneM2M中通过创建<topicAannc>、<topicBannc>。在另一个实例中，(c)代理者1702可以向消费者发送专用广告消息。在RESTful环境中，这些专用消息例如可以被实施为具有topicAdvertisementIndicator消息参数的创建或取回消息。在另一个实例中，(d)代理者1702可以发送通知，例如包括具有<topicA>和<topicB>资源的资源ID的topicIndicator消息参数。

在比如oneM2M之类的实现方式中，常规通知可以仅响应于明确订阅请求才被发送，并且包括由所述订阅规定的特定参数(例如请求ID、通知URI、事件类别)。广告可以使用这些常规通知机制，并且作出修改以实施前面描述的通知消息方法(d)。举例来说，advertisementPolicy可以包括将被用于所有广告通知的特定请求ID、通知URI或事件类别。或者，所述策略可以包括用于例如基于订阅者ID、主题域等等动态地创建这样的参数的规则。此外，通知消息可以包括提供所广告的主题的资源ID的topicIndicator消息参数。

参照图17，在接收到广告之后，消费者1701可以确定它是否应当针对所接收到的信息采取动作，例如通过发起对于<topicX>的订阅，否则它可以忽略所述广告(步骤1713)。在任一种情况下，消费者1701可以决定在本地保持关于系统中可用的主题的信息。

如果所接收到的消息是具有<topic>资源作为有效载荷的常规创建操作或者是声明(前面的方法a和b)，则消费者1701可以选择想要创建本地<topicA>还是<topicAannc>资源(仅实施对于这些类型的资源的特殊处理)。消费者1701可以决定在本地保持关于系统中可用的主题的信息，但是不一定要创建资源。

得到授权的实体可以通过提供特定输入基于明确请求而请求订阅主题。可以由任何请求者使用常规订阅规程来订阅系统中的主题。一旦请求被接受并且订阅被创建，请求者可以成为消费者。除了可用于资源创建的常规标准之外，代理还允许消费者使用主题的maskList中的掩码来规定针对订阅的附加标准。举例来说，订阅者可以使用“publisher＝pubA”作为掩码，从而仅接收可以从特定发布者获得的数据，尽管主题本身可以由几个发布者发布并且因此可用于其他消费者。其他掩码可以表明数据的周期性、定时约束、数值约束等等。鉴于主题可以包含几个事例，这可以等效于具有每次针对多于一项资源的订阅标准。此外还意味着订阅标准可以针对与事例资源之间的关系有关的参数，例如特定的事例生成速率。

当接收到长期资源发现时，可以触发创建对于主题的订阅的处理。这种方法可以由任何请求者在使用基于长期资源发现的主题创建的明确方法时使用，例如通过使用前面关于图14和15所描述的方法。为了还订阅主题，请求者可以在创建请求或发现请求中包括subscriptionIndicator消息参数。一旦请求被接受并且订阅被创建，代理者可以自动为请求者创建主题订阅。因此，请求者可以成为消费者，并且可以由代理者添加到主题consumerList。

图18是用于发现的示例性规程1800的图示。在图18的实例中，代理者可以提供与主题相关的附加价值服务。代理者可以通过增强常规资源发现和查询方法来促进主题发现。由代理者采用来提供该功能的两种方法包括作用域(scoping)和重定向。在图18的实例中，假设代理者也是<topic>资源之外的其他资源的寄主。因此，代理者可以是任何常规资源发现或查询请求的目标。在比如oneM2M之类的SL实现方式中，资源发现请求以及查询可以被设计成以资源树中的资源为目标。接收者可以使用以目标资源为基础的资源树来实施发现或查询，也就是说接收者在搜索中可以包括目标资源的后代。假设<topic>资源可以被存储在专用的树种，例如<domain>资源(参见表5)。这些方法能够以较小的改变被应用于其他资源组织方案。

参照图18，请求者1801可以向代理者1802发送发现或查询请求，所述请求可以包括消息参数brokerageDiscoveryIndicator(步骤1811)。代理者1802可以接收发现或查询请求，并且可以基于消息目标的数值和brokerageDiscoveryIndicator如下继续：

(1)代理资源目标，没有brokerageDiscoveryIndicator。代理者1802可以接收没有brokerageDiscoveryIndicator消息参数的以代理资源(例如<broker>、<domain>、<topic>)为目标的常规发现或查询请求。在这种情况下，代理者1802可以在本地处理该请求(步骤1812)。可以绕过步骤1813，并且在步骤1814中，代理者1802可以准备发现或查询结果，如果请求分别以<broker>、<domain>或<topic>为目标，所述结果可以是基于某个域内的所有可用主题或者某个主题内的可用信息。这可以允许基于使用代理功能保持的信息的查询和发现。举例来说，请求者1801可能对于发现保持特定数目的事例历史、属于给定主题群组等等的主题感兴趣。

(2)代理资源目标，brokerageDiscoveryIndicator＝targetDomain。代理者1802可以接收以代理资源为目标并且brokerageDiscoveryIndicator＝targetDomain的常规发现或查询请求。在这种情况下，在对于请求的初始接收和处理之后(步骤1812)，如步骤1813中所示，代理者1802可以将发现请求重定向到域中的其他实体，即其生产者1803和消费者1804。在接收到相应的结果之后，代理者1802可以聚合响应(步骤1814)。这可以允许将发现和查询分发到代理域中的利害攸关者，而无需请求者单独发现这些实体当中的每一个。对于brokerageDiscoveryIndicator可以实施其他变型，其中使用targetProducers、targetConsumer等数值将目标重定到特定的利害攸关者。

(3)一般资源目标，brokerageDiscoveryIndicator＝includeProducedTopic。代理者1802可以接收以代理资源之外的其他资源为目标的常规发现或查询请求，并且具有brokerageDiscoveryIndicator＝includeProducedTopic。代理者1802可以开始于基于如步骤1812中所示的消息参数的常规发现或查询，并且步骤1813可以被绕过。搜索的范围可以包括目标资源的后代。如果后代资源具有指向<topic>资源的producesTopic属性，则代理者1802可以将所述<topic>资源添加到搜索范围，并且可以在扩大的范围中处理请求(步骤1814)。这可以允许发现和查询产生更有意义的结果。举例来说，可以产生包含交通摄影机读数的<container>资源，其中具有仅包含相关项目“intersection”、“operatorY”等等的标签或语义描述。所述容器可以被使用在前面所描述的使用实例中，以便为道路可通过性主题提供事例，例如具有包括项目“FrenchQuarter”的标签或语义描述的<passability123>。在这种情况下，以常规资源树为目标的资源发现可以能够基于其所产生的主题的描述而不是其自身的属性来发现所述容器。类似地，除了资源树中的资源的语义描述之外，语义查询还能够使用主题的语义描述。

(4)一般资源目标，没有brokerageDiscoveryIndicator。这可以包括传统资源发现或查询实现方式。代理者对于搜索可以使用以目标资源为基础的资源树，也就是说可以在搜索中包括目标资源的后代。步骤1813可以被绕过。

代理者1802可以对请求者1801作出响应，并且可以提供资源发现或查询的结果(步骤1815)。

代理者可以通过保持比如发布者之类的参与者的活跃度状态的记录来提供附加的服务。虽然许多消费者可能仅对事例数值感兴趣，但是一些消费者可能只有在已知生产者会提供数据可靠性的情况下才对这些主题感兴趣。单独的消费者可以不需要分别单独检查发布者的活跃度。

生产者活跃度的确切定义以及计算方法和相关联的参数可以根据实现方式的需求而变化。举例来说，活跃度状态可以断言：

参与者可以进行通信，例如发布者可以被探通；

与参与者的代理通信是活跃的，例如发布者针对任何主题进行发布；以及

与参与者的特定通信是活跃的，例如发布者针对特定主题进行发布。

这些方法当中的每一种可以被用来以更加复杂的方式评估活跃度，例如对于一组生产者进行评估或者包括其他参与者和动作，例如能够接收通知的消费者。

保持生产者的活跃度状态是可以由代理者向感兴趣的消费者提供的附加价值服务。所述状态可以被保持在对应于每一个生产者的主题内，例如作为可以被曝光于订阅者的资源属性。代理者可以提供“复合活跃度”参数，例如通过保持对应于一个群组内的参与者的平均或最长不活跃时间。

为此目的，取决于活跃度参数的含义，代理者可以使用多种机制，例如：

(1)跟踪其与参与者的所有通信。举例来说，发布者可以基于其发现请求(不一定基于主题事例发布)而被视为活跃。

(2)发起与参与者的通信。举例来说，代理者可以发起与参与者的短通信或探通，以便评估其活跃度。

(3)请求参与者保持心搏。举例来说，代理者可以要求参与者提供周期性通知以便保持其活跃度状态。

(4)仅跟踪与参与者的特定通信。举例来说，代理者可以只有在发布者针对特定主题进行发布的情况下才将其视为活跃，或者只有在以订阅者为目标的所有通知都成功的情况下才将其视为活跃。

保持系统中的参与者的活跃度状态可以是由代理者提供的一项重要服务。在RESTful通信中，各种节点通常仅能够作为一对一通信中的端点直接评估通信状态。在针对多对多通信设计的系统中，对于所述系统来说，评估通信状态的代价可能是很高的。此外，代理者可能处于提供更加全面的评估的独有位置。举例来说，传感器可以在不同的速率下提供几种类型的测量。对于改变最慢的测量的订阅者在长时间的暂停之后可能只会错误地评估出有通信问题。如果所有测量都通过相同的代理者发布，则代理者可以通过监测其他测量评估出生产者在功能上是“活跃的”，而无需发起与传感器的任何附加通信。被用于活跃度评估的参数可以由对应于主题的livelinessPolicy提供，并且状态可以被保持。

代理者可以提供对于资源受约束的消费者可能是特别有用的存储和持久性服务。这些消费者不仅通过能够在一个地方访问所有主题相关数据而优化其发现，而且可以使用主题设定(或者创建具有所期望的设定的主题)，从而使得数据代表所述消费者被存储和保持。消费者可以设定表明该存储如何被处理的持久性数值。

主题创建者可以使用instanceRetentionPolicy提供表明数据如何被存储和保持的设定。举例来说，仅有特定数目的最近事例可以被保留，每一个事例可以被保持特定持续时间，来自每一个发布者的每一个事例可以被保持不同的持续时间等等。该策略还可以表明只有在满足发布者活跃度条件的情况下才可以保留更早的事例，或者在任何情况下都可以保留

代理者可以通过使用processingCriteria对于事例采用附加的处理来提供附加价值。为此，代理者可以使用由外部服务提供的算法，或者可以自行实施所述处理。但是代理者可以允许在消费者可以接收数据之前实施该处理，从而优化消费者的功能。

processingCriteria主题属性可以表明当创建新的事例时是否应当由代理者应用任何数据处理。举例来说，可以规定两个或更多发布者在一个窗口内提供相同的内容以使得所述内容成为事例(即应用一致性检查)，或者规定将应用特定的事例过滤(例如通过内容数值、按照时间等等)。由于所涉及的事例可能属于不同的生产者，因此即使有计算资源可用，在生产者处也不总是可以应用该附加价值服务。对于不同的消费者，代理者处的该附加价值服务可以确保跨越各个消费者均匀地进行处理，并且可以提供对于使用数据的潜在大量端点仅进行一次的附加好处。

图19是主题ACP 1900的图示。代理者可以通过提供主题相关的安全性来提供附加价值。这可以减少消费者(例如订阅者1903)与每一个生产者设置ACP的需求。代理者可以实施ACP的代理。一个主题内的主题事例的数据生成的ACP可以由代理者使用，并且可以在配置所发布的主题的ACP时被纳入考虑。在图19的实例中，如果针对特定主题发布的数据包括源自多个来源(例如发布者1901和发布者1902)的数据，则代理者可以利用基于来自各个单独事例的聚合ACP的ACP来配置所述主题。代理者可以生成对应于主题1904的聚合ACP1905，其中可以仅包括在ACP1 1906和ACP2 1907中通用的特权，也就是说跨越主题1904的所有主题事例所通用的特权。该代理服务可以被用来对于任何主题优化安全功能，特别是使用声明作为创建和/或发布方法的那些主题。

代理者可以通过实施用于主题发布和订阅的仲裁系统来提供附加价值。代理者可以提供针对数据代理请求的仲裁，以便差异化对于订阅者的服务质量。在发布侧，仲裁系统可以允许区别对待来自不同发布者的发布。为此目的，代理系统可以使用发布者和/或消费者的participantPriority属性和arbitrationProposalStrength属性来计算总体请求强度数值。

当新的主题事例被发布时，代理者可以使用发布者的participantPriority属性和所提出的主题事例中的arbitrationProposalStrength属性的数值来计算总体发布请求强度。除了所有其他策略之外，发布规程随后可以受到arbitrationPolicy，以使得事例被创建。举例来说，如果arbitrationPolicy规定了最小总体发布请求强度，则不满足所述标准的发布不可被保存为事例。在其他实现方式中，代理者可以只有在接收到太多事例或者要在不同事例之间提供排序的情况下才基于发布请求强度实施仲裁。

当接收到针对主题的新的订阅请求时，代理者可以使用消费者的participantPriority属性和所接收到的订阅中的arbitrationProposalStrength属性的数值来计算总体订阅请求强度。除了所有其他策略之外，订阅规程随后可以受到arbitrationPolicy，以使得订阅被创建。举例来说，如果arbitrationPolicy规定了最小总体订阅请求强度，则不满足所述标准的订阅请求不可被接受。在其他实现方式中，代理者可以只有在需要处理太多通知或者要在订阅之间提供服务质量差异化的情况下才基于订阅强度实施仲裁。

participantPriority和arbitrationProposalStrength参数还可以被实施为消息参数。在另一种实现方式中，代理者可以置备有用于在没有这些明确仲裁参数的情况下计算请求的强度的算法。举例来说，所述算法可以基于其ID、参与者位置等等向参与者指派不同的参与者优先级数值。发布请求可以基于发布者ID、日间时、参与者位置、参与者能力(例如测量准确度)等等被指派不同的arbitrationProposalStrength数值。订阅请求可以基于订阅者ID、参与者协定QoS等等被指派不同的arbitrationProposalStrength数值。

图20是支持数据代理CSF 2000的示例性oneM2M服务层的图示。在图20的实例中，CSF可以包括以下各项：应用和服务层管理CSF 2002；发现CSF 2003；登记CSF 2004；通信管理/递送处理CSF 2005；群组管理CSF 2006；安全性CSF 2007；数据管理和储存库CSF 2008；位置CSF 2009；服务计费和记账CSF 2010；设备管理CSF 2011；网络服务曝光、服务执行和触发CSF 2012；订阅和通知CSF 2013；事务管理CSF 2019；以及语义CSF 2021。图20的实例还示出了通过Mca参考点2014、Mcc(和Mcc’)参考点2015和Mcn参考点2016接口到其他实体的CSE 2001，所述其他实体包括但不限于：AE 2017；其他CSE；以及NSE 2018(即下方网络)。

数据代理功能2020可以被实施为如图20的实例中所示的CSF。该CSF可以被寄放在各种类型的服务层节点上，比如IoT网关和服务，并且可以使用寄放在该CSE 2001上的资源来提供数据代理服务。

在一些实例中，在给定时间并非寄放在CSE 2001上的所有资源都需要被包括在代理服务中。与此同时，并非所有oneM2M资源类型都可以被规定支持数据代理。特别适合于代理服务的oneM2M资源可以包括但不限于：比如container、flexContainer和timeSeries之类的内容共享资源；AE等等。

在oneM2M系统中，本文中所描述的信息单元可以使用下面标识出的几项资源以及现有资源的增强来实施。

可以使用描述代理实体的新的资源类型。举例来说，可以在oneM2M中规定新的<broker>、<publisher>、<subscribers>资源类型，以便描述和识别系统中的各种参与者。所述新的资源类型的属性分别对应于表4、表6和表7中的那些属性。对应于表9中的描述的策略参数可以作为属性被添加到这些资源类型，或者可以被实施为策略资源。

可以使用描述主题和域的新的资源类型。可以在oneM2M中规定新的<topic>和<domain>资源类型，以便描述和识别系统中的这些概念。所述新的资源类型的属性分别对应于表8和表5中的那些属性。对应于表9中的描述的策略参数可以作为属性被添加到这些资源类型，或者可以被实施为策略资源。

可以使用新的资源属性。为了使用新的资源属性来实施所述方法，oneM2M可以规定可以存在于多种资源类型中的以下通用属性：

allowTopic：如果被实施为布尔量，则该属性例如可以表明(如果为真)所述资源可以被用于可以在代理者处被发布的主题的创建。该属性还可以被实施成使得任何数值都表明允许主题的创建，并且所述数值本身可以被使用在创建规程中，例如作为topicDescription数值、作为semanticDescription等等。

createTopicCriteria：可以存在于<subscription>类型的资源中的属性。该属性可以提供针对基于作为给定订阅的结果而发送的通知来创建主题的标准。

producesTopic：表明使用该资源产生的主题的资源ID(或ID列表)的属性。

arbitrationProposalStrength：可以存在于多种资源类型中的属性。当被包含在订阅资源中时，该属性可以表明对应于订阅的仲裁提议强度。当被包含在用来创建主题事例的其他资源类型中时，该属性可以表明对应于发布的仲裁提议强度。

为了使用新的访问控制操作来实施所述方法，可以增强oneM2M<accessControlPolicy>的一些属性。正如前面所描述的那样，oneM2M<accessControlPolicy>资源可以包括代表定义哪些AE/CSE被允许实施哪些操作的一个访问控制规则集合的privileges和selfPrivileges属性。该访问控制规则集合可以包括3元组，所述3元组包括：accessControlOriginators、accessControlContext和accessControlOperations。

如下面的表10中所示，可以利用PUBLISH操作来增强accessControlOperations参数。

名称	描述
		RETRIEVE	取回所寻址的资源的内容的特权
CREATE	创建子代资源的特权
		UPDATE	更新所寻址的资源的内容的特权
DELETE	删除所寻址的资源的特权
		DISCOVER	发现资源的特权
NOTIFY	接收通知的特权
		PUBLISH	发布资源的特权

表10、accessControlOperations中的新参数

以下新的请求参数可以被包括在oneM2M请求中：

topicIndicator：被如下使用的消息参数：

当存在于以代理者为目标的声明消息中时，该参数的数值可以提供生产者志愿向其进行发布的<topic>的资源ID。

当存在于通知消息中时，该参数的数值可以提供代理者正在广告的<topic>的资源ID。

当存在于具有默认或NULL(空值)数值的其他声明消息中时，该参数可以表明所述声明将被用于新主题创建。

brokeragePolicy：可以被用来表明将被用于代理相关功能的策略的请求消息参数。

longTermDiscoveryIndicator：用于发现请求消息的参数，可以被用来表明所述请求将由接收者/代理者重复。当存在时，该参数可以提供用于重复、生命跨距、响应选项等等的参数。举例来说，该参数可以将这些参数提供为一个排序列表，提供为单独的从属消息参数，或者提供为包含该信息的资源的资源ID。

subscriptionIndicator：用于长期发现请求消息的参数，也可以被用于主题创建。通过包括该参数，请求者可以表明它请求一旦创建了主题则成为消费者。

brokerageDiscoveryIndicator：用于增强型发现请求消息的参数，可以具有几个数值。当包括该参数时，请求者可以提供由代理者使用来提供附加的发现相关功能的信息。

topicAdvertisementIndicator：可以被用来表明所述消息仅被用于主题广告的请求消息参数。

以下新的响应参数可以被包括在oneM2M响应消息中：

relatedTopicsIndicator：可以被用来表明与操作结果相关的主题的响应消息参数。

图21是用于代理管理的示例性GUI 2100的图示。所述GUI可以包括用于代理管理的应用编程接口(API)2101，其可以被用来创建主题2102以及代理策略2103。在该例中，所述API可以允许对于将被反映在<topic>资源中的参数以及对于可以通过策略实行的参数提供输入。

图22A是可以在其中实施一个或多个所公开的实施例的示例性机器对机器(M2M)、物联网(IoT)或万维物联网(WoT)通信系统10的图示。通常来说，M2M技术提供用于IoT/WoT的构建块，并且任何M2M设备、M2M网关或M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等等的组件。在图1到21当中的任一幅图中所示出的任何设备、功能、节点或网络可以构成比如在图22A-B中所示出的通信系统的节点。

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

如图22A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域。基础设施域指的是端到端M2M部署的网络侧，现场域指的是通常处于M2M网关后方的区域网络。现场域和基础设施域都可以包括网络的多种不同节点(例如服务器、网关、设备)。举例来说，现场域可以包括M2M网关14和终端设备18。应当认识到，按照希望可以在M2M/IoT/WoT通信系统10中包括任何数目的M2M网关设备14和M2M终端设备18。每一个M2M网关设备14和M2M终端设备18被配置来通过通信网络12或直接无线电链路发送和接收信号。M2M网关设备14允许无线M2M设备(例如蜂窝和非蜂窝)以及固定网络M2M设备(例如PLC)通过运营商网络(比如通信网络12)或直接无线电链路进行通信。举例来说，M2M设备18可以收集数据并且通过通信网络12或直接无线电链路向M2M应用20或M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。此外，可以通过M2M服务层22向/从M2M应用20发送和接收数据和信号，正如后面所描述的那样。M2M设备18和网关14可以通过各种网络进行通信，例如包括蜂窝、WLAN、WPAN(例如ZigBee、6LoWPAN、Bluetooth)、直接无线电链路和有线网络。示例性的M2M设备包括(但不限于)平板设备、智能电话、医疗设备、温度和天气监测器、连接的汽车、智能仪表、游戏机、个人数字助理、健康和健身监测器、灯、恒温器、电器、车库门和其他基于致动器的设备、安全设备以及智能插座。

参照图22B，所示出的现场域中的M2M服务层22为M2M应用20、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’可以由一个或多个服务器、计算机、虚拟机(例如云端/计算/存储场)等等实施。

仍然参照图22B，M2M服务层22和22’提供了一个多样的应用和垂直域可以利用的服务递送能力的核心集合。这些服务能力使得M2M应用20和20’能够与设备进行交互，并且实施比如数据收集、数据分析、设备管理、安全、记账、服务/设备发现等功能。实质上，这些服务能力使得应用免于实施这些功能的负担，从而简化了应用开发并且减少了进行营销的成本和时间。服务层22和22’还使得M2M应用20和20’能够通过与服务层22和22’所提供的服务连接的各种网络12和12’进行通信。

M2M应用20和20’可以包括各种行业中的应用，比如(但不限于)交通运输、健康保健、联网家庭、能源管理、资产跟踪以及安全和监控。正如前面所提到的那样，跨越系统的设备、网关和其他服务器运行的M2M服务层支持例如数据收集、设备管理、安全、记账、位置跟踪/地理围栏、设备/服务发现以及传统系统集成之类的功能，并且将这些功能作为服务提供给M2M应用20和20’。

通常来说，服务层(SL)(比如图22A和22B中示出的服务层22和22’)定义一个软件中间件层，所述软件中间件层通过一个应用编程接口(API)和下方联网接口的集合来支持附加价值服务能力。ETSI M2M和oneM2M架构都定义了服务层。ETSI M2M的服务层被称作服务能力层(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中，还是具体实现在网络的某个其他节点中，服务层的事例可以被实施在逻辑实体(例如软件、计算机可执行指令等等)中，所述逻辑实体执行在网络中的一个或多个独立节点(包括服务器、计算机和其他计算设备或节点)上，或者可以被实施为一个或多个现有节点的一部分。作为一个实例，服务层或其组件的事例可以通过软件的形式来实施，所述软件运行在具有后面所描述的在图22C或22D中示出的一般架构的网络节点(例如服务器、计算机、网关、设备等等)上。

此外，本文中所描述的方法和功能可以被实施为使用面向服务架构(SOA)和/或面向资源架构(ROA)来访问服务的M2M网络的一部分，例如前面描述的网络和应用管理服务。

图22C是网络的节点的示例性硬件/软件架构的方块图，比如图1到21中示出的节点、设备、功能或网络的其中之一，所述节点可以作为比如图22A和22B中示出的M2M网络中的M2M服务器、网关、设备或其他节点进行操作。如图22C中所示，节点30可以包括处理器32、收发器34、发送/接收单元36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移除存储器44、可移除存储器46、电源48、全球定位系统(GPS)芯片组50以及其他外设52。节点30还可以包括通信电路，比如收发器34和发送/接收单元36。应当认识到，在与一个实施例保持一致的同时，节点30可以包括前述单元的任何子组合。该节点可以是实施本文中所描述的通知和与之相关的触发的节点。

处理器32可以是通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)、状态机等等。处理器32可以实施信号编码、数据处理、功率控制、输入/输出处理以及/或者使得节点30能够操作在无线环境中的任何其他功能。处理器32可以耦合到收发器34，收发器34可以耦合到发送/接收单元36。虽然图22C将处理器32和收发器34描绘成分开的组件，但是应当认识到，处理器32和收发器34可以一起被集成在电子包装或芯片中。处理器32可以实施应用层程序(例如浏览器)和/或无线电接入层(RAN)程序和/或通信。处理器32可以例如在接入层和/或应用层实施安全操作，比如认证、安全密钥协定和/或密码操作。

如图22C中所示，处理器32耦合到其通信电路(例如收发器34和/或发送/接收单元36)。处理器32通过执行计算机可执行指令可以控制通信电路，以便使得节点30通过其所连接的网络与其他节点进行通信。具体来说，处理器32可以控制通信电路以便实施在本文中(例如在图1-9中)和权利要求中所描述的发送和接收步骤。虽然图22C将处理器32和收发器34描绘成分开的组件，但是应当认识到，处理器32和收发器34可以一起被集成在电子包装或芯片中。

发送/接收单元36可以被配置来向/从其他节点发送信号或接收信号，所述其他节点包括M2M服务器、网关、设备等等。举例来说，在一个实施例中，发送/接收单元36可以是被配置来发送和/或接收RF信号的天线。发送/接收单元36可以支持各种网络和空中接口，比如WLAN、WPAN、蜂窝等等。在一个实施例中，发送/接收单元36例如可以是被配置来发送和/或接收IR、UV或可见光信号的发射器/检测器。在另一个实施例中，发送/接收单元36可以被配置来发送和接收RF和光信号全部二者。应当认识到，发送/接收单元36可以被配置来发送和/或接收无线或有线信号的任意组合。

此外，虽然发送/接收单元36在图22C中被描绘成单个单元，但是节点30可以包括任何数目的发送/接收单元36。更具体来说，节点30可以采用MIMO技术。因此，在一个实施例中，节点30可以包括两个或更多发送/接收单元36(例如多个天线)以用于发送和接收无线信号。

收发器34可以被配置来对将由发送/接收单元36发送的信号进行调制，并且对由发送/接收单元36接收到的信号进行解调。正如前面所提到的那样，节点30可以具有多模式能力。因此，收发器34可以包括多个收发器以使得节点30能够例如通过多种RAT进行通信，比如UTRA和IEEE 802.11。

处理器32可以从任何类型的适当存储器访问信息并且在其中存储数据，比如不可移除存储器44和/或可移除存储器46。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或者任何其他类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)记忆卡等等。在其他实施例中，处理器32可以从并非物理地位于节点30上(比如位于服务器或家用计算机上)的存储器访问信息并且在其中存储数据。处理器32可以被配置来控制显示器或指示器42上的照明模式、图像或颜色，从而反映节点的状态或节点的配置(例如图1-21中的节点)，特别是与UE通信的下方网络、应用或其他服务。处理器32可以从电源48接收电力，并且可以被配置来配送和/或控制去到节点30中的其他组件的电力。电源48可以是用于为节点30供电的任何适当的设备。举例来说，电源48可以包括一个或多个干电池组(例如镍镉(NiCd)、镍锌(NiZn)、镍金属混合物(NiMH)、锂离子(Li离子)等等)、太阳能电池、燃料电池等等。

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

处理器32还可以耦合到其他外设52，其中可以包括提供附加的特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。举例来说，外设52可以包括各种传感器，比如加速度计、生物计量(例如指纹)传感器、电子罗盘、卫星收发器、数字摄影机(用于拍照或视频)、通用串行总线(USB)端口或其他互连设备、振动设备、电视收发器、免提头戴式耳机、

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

图22D是也可以被用来实施网络的一个或多个节点的示例性计算系统90的方块图，比如1-21中示出的节点、设备、功能或网络，所述节点可以作为比如在图22A和22B中示出的M2M网络中的M2M服务器、网关、设备或其他节点进行操作。计算系统90可以包括计算机或服务器并且可以主要由计算机可读指令控制，所述计算机可读指令可以采取软件的形式，不管这样的软件在何处或者通过何种手段被存储或访问。这样的计算机可读指令可以在中央处理单元(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或其他硬件设备读取或改变。对于RAM 82和/或ROM 93的存取可以由存储器控制器92控制。存储器控制器92可以提供地址翻译功能，从而在指令被执行时把虚拟地址翻译成物理地址。存储器控制器92还可以提供存储器保护功能，从而隔离系统内的进程并且将系统进程与用户进程隔离开。因此，运行在第一模式下的程序只能存取由其自身的进程虚拟地址空间映射的存储器；除非在进程之间设置了存储器共享，否则它无法存取另一个进程的虚拟地址空间内的存储器。

此外，计算系统90可以包括负责把指令从CPU 91传达到外设的外设控制器83，所述外设比如有打印机94、键盘84、鼠标95和盘驱动器85。

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

此外，计算系统90可以包含通信电路，比如网络适配器97，所述通信电路可以被用来把计算系统90连接到外部通信网络，比如图22A和图22B的网络10，以使得计算系统90能够与网络的其他节点进行通信。所述通信电路独立地或者与CPU 91相组合可以被用来实施在本文中(例如在图1-21中)和权利要求中所描述的发送和接收步骤。

在描述如附图中所示出的本公开内容的主题内容的优选实施例时，为了清楚起见采用了特定术语。但是所要求保护的主题内容不应被限制到所选择的特定术语，应当理解的是，每一个特定单元包括按照类似方式操作来实现类似目的的所有技术等效方案。

在描述如附图中所示出的本公开内容的主题内容的优选实施例时，为了清楚起见采用了特定术语。但是所要求保护的主题内容不应被限制到所选择的特定术语，应当理解的是，每一个特定单元包括按照类似方式操作来实现类似目的的所有技术等效方案。

Claims (30)

1.一种包括处理器、存储器和通信电路的装置，所述装置通过其通信电路连接到网络，所述装置还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置实施以下操作：

从第二装置接收包括第一信息的第一信号，所述第一信息表明与主题指标相关联的发布意向；

从第三装置接收包括第二信息的第二信号，所述第二信息表明与所述主题指标相关联的订购意向；

基于所述发布意向和订购请求生成主题事例；

发送包括表明所生成的主题事例的声明消息的第三信号；

从第三装置接收包括针对所生成的主题事例的订购请求的第四信号；

向第三装置发送包括与所生成的主题事例相关联的通知和发布事例的至少一个第五信号。

2.根据权利要求1所述的装置，其中，所述装置是服务层实体。

3.根据权利要求1所述的装置，其中，所述第二装置是服务层实体。

4.根据权利要求1所述的装置，其中，所述第三装置是物联网(IoT)设备。

5.根据权利要求1所述的装置，其中，所述第二信号是响应于广告通知而接收的。

6.根据权利要求5所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于策略对所述广告通知进行仲裁。

7.根据权利要求5所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于与第二装置相关联的标识符对所述广告通知进行仲裁。

8.根据权利要求5所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于与第二装置相关联的位置对所述广告通知进行仲裁。

9.根据权利要求5所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于与第二装置相关联的能力对所述广告通知进行仲裁。

10.根据权利要求5所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于日间时对所述广告通知进行仲裁。

11.根据权利要求1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于与第三装置相关联的标识符对所述订购请求进行仲裁。

12.根据权利要求1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于服务质量(QoS)对所述订购请求进行仲裁。

13.根据权利要求1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于心搏消息或者自从接收到第一信号以来的持续时间的至少其中之一来判定第二装置的状态。

14.根据权利要求1所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于心搏消息或者自从接收到第四信号以来的持续时间的至少其中之一来判定第三装置的状态。

15.根据权利要求1所述的装置，其中，所述第五信号是基于访问控制策略(ACP)而发送的。

16.根据权利要求1所述的装置，其中，所述第五信号包括将所述订购请求重定向到第四装置的指示。

17.根据权利要求16所述的装置，其中，所述第四装置是服务层实体。

18.根据权利要求1所述的装置，其中，所述订购请求将由所述装置重复和管理。

19.根据权利要求18所述的装置，还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置还实施以下操作：

基于针对所生成的主题事例的更新向第三装置发送第二至少一个第五信号。

20.根据权利要求19所述的装置，其中，所述更新基于与所生成的主题事例相关联的数据超出预定阈值。

21.根据权利要求1所述的装置，其中，所述装置包括无线通信设备。

22.根据权利要求1所述的装置，其中，所述装置包括用户装备(UE)。

23.根据权利要求1所述的装置，其中，所述装置包括计算设备。

24.根据权利要求1所述的装置，其中，所述装置包括智能电话。

25.根据权利要求1所述的装置，其中，所述装置包括网关。

26.一种包括处理器、存储器和通信电路的装置，所述装置通过其通信电路连接到网络，所述装置还包括存储在该装置的存储器中的计算机可执行指令，所述计算机可执行指令在由所述装置的处理器执行时使得该装置实施以下操作：

从第二装置接收包括第一信息的第一信号，所述第一信息包括发现请求，所述发现请求表明将由所述装置重复和管理该发现请求；

基于所述发现请求，使得发现从第三装置发送的第二信息；

发送包括响应消息的第二信号，所述响应消息包括所发现的第二信息；

基于针对所述第二信息的更新，使得发现从第三装置发送的第三信息；以及

发送包括消息的第三信号，所述消息包括所述第三信息。

27.根据权利要求26所述的装置，其中，所述发现请求包括针对主题事例的订购请求。

28.根据权利要求27所述的装置，其中，所发现的第二信息包括与所述主题事例相关联的数据。

29.根据权利要求28所述的装置，其中，所述第三信息包括针对所述主题事例的更新。

30.一种方法，包括：

从第一装置接收包括第一信息的第一信号，所述第一信息表明与主题指标相关联的发布意向；

从第二装置接收包括第二信息的第二信号，所述第二信息表明与所述主题指标相关联的订购意向；

基于所述发布意向和订购请求生成主题事例；

发送包括表明所生成的主题事例的声明消息的第三信号；

从第二装置接收包括针对所生成的主题事例的订购请求的第四信号；

向第二装置发送包括与所生成的主题事例相关联的通知和发布事例的至少一个第五信号。

Images