CN111989941A - 用于分流IoT应用消息生成和响应处理的服务层方法 - Google Patents

Abstract

服务层可以被配置为代表IoT应用来分流请求和响应，以便减少底层网络、应用和设备的拥塞和/或开销。服务层可以具有脚本化和生成IoT应用请求的能力，使得请求能够由服务层发起，而IoT应用不必(例如，为了定期地检索传感器读数)重复地重新发布相同的请求。这种脚本化可以由请求发起者发起。服务层可以支持监视和检测重复请求模式以及自身发起脚本化的能力。这种脚本化功能可以使服务层能够代表IoT应用执行操作。因此，可以将IoT应用和设备以及底层网络上的消息传递开销最小化。

Description

用于分流IoT应用消息生成和响应处理的服务层方法

相关申请的交叉引用

本申请要求于2018年2月9日提交的编号为62/628,326的美国临时申请的权益，该申请的内容通过引用全文并入本文。

背景技术

oneM2M标准定义了称为公共服务实体(CSE)的服务层实体。服务层实体的目的是提供可以由不同的“垂直”机器对机器(M2M)系统和应用使用的“水平”服务。oneM2M的CSE支持四个参考点，如图1的示例中所示。Mca参考点与应用实体(AE)对接(interface)。Mcc参考点与同一服务提供者域中的另一个CSE对接。Mcc的参考点与不同服务提供者域中的另一个CSE接口。Mcn参考点与底层网络服务实体(NSE)对接。

发明内容

公开了用于使服务层(SL)能够代表IoT应用来分流(offload)请求和响应的方法和系统，以便减少底层网络、应用和设备的拥塞和/或开销。可以使SL具有脚本化(script)和生成IoT应用请求的能力，使得请求可以由SL发起，而IoT应用不必重复地重新发布相同的请求(例如，定期地检索传感器读数)。这种脚本化可以由请求发起者发起。附加地或可替代地，SL可以支持监视和检测重复请求并发起自身脚本化的能力。SL可以基于既定的响应处理准则的集合来对响应的处理进行脚本化并执行诸如响应的批处理、过滤和聚合之类的操作。这种脚本化功能可以使SL能够代表IoT应用来执行操作。因此，可以最小化IoT应用和设备以及底层网络上的消息传递开销。

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

附图说明

为了促进对本申请的更稳健的理解，现在参考附图，在附图中，相同的元件用相同的附图标记表示。这些附图不应当被解释为限制本申请，而仅仅是示例性的。

图1示出了示例oneM2M体系架构；

图2示出了图示IoT应用、IoT服务层和控制石油管道上的阀门的一个或多个IoT设备之间的示例交互的流程图；

图3示出了图示消息脚本化服务(MSS)的操作的示例流程图；

图4示出了图示脚本化的服务层请求的手动创建的流程图；

图5示出了图示脚本化的服务层请求的手动触发的流程图；

图6示出了图示脚本化的服务层请求序列的手动创建的示例流程图；

图7示出了图示脚本化的服务层请求的自动创建的示例流程图；

图8示出了用于脚本化的SL请求序列的自动创建的示例方法；

图9示出了可以在符合oneM2M标准的网络中实现的消息脚本化服务的体系架构的示例；

图10示出了根据图9中所示以及本文描述的示例oneM2M体系架构的脚本化的请求序列的示例；

图11示出了<transactionManagement>资源的示例；

图12示出了用于消息模板管理的示例用户界面；

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

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

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

图13D示出了其中可以实施图13A的通信系统的方面的示例计算系统的示例框图。

具体实施方式

在oneM2M标准的术语中，NSE向CSE提供底层网络服务，诸如设备管理、位置服务和设备触发。CSE可以包含被称为“公共服务功能”的多个逻辑功能，诸如“发现”和“数据管理&储存库”。oneM2M体系架构可以启用以下类型的节点，如图1中所示：

应用服务节点(ASN)：包含一个CSE并且包含至少一个应用实体(AE)的节点。物理映射的示例：ASN可以驻留在M2M设备中；

应用专用节点(ADN)：包含至少一个AE并且不包含CSE的节点。oneM2M系统的现场域中可以有零个或多个ADN。物理映射的示例：ADN可以驻留在受约束的M2M设备中；

中间节点(MN)：包含一个CSE并且包含零个或多个AE的节点。oneM2M系统的现场域中可以有零个或多个MN。物理映射的示例：MN可以驻留在M2M网关中；

基础设施节点(IN)：包含一个CSE并且包含零个或多个AE的节点。每个oneM2M服务提供者的基础设施域中只有一个IN。IN中的CSE可以包含不适用于其它节点类型的CSE功能。物理映射的示例：IN可以驻留在M2M服务基础设施中；以及

非oneM2M节点(NoDN)：不包含oneM2M实体(既没有AE也没有CSE)的节点。这种节点可以表示附接到oneM2M系统的设备，用于包括管理的互通目的。

oneM2M标准定义了<request(请求)>资源，以使CSE能够以非阻塞方式处理传入的请求。这允许CSE返回它接收到发起者的请求并已开始处理该请求的确认。当CSE完成请求处理后，它可以用结果来更新<request>资源。然后，CSE可以通知请求发起者。附加地或可替代地，发起者可以检索<request>资源以获得结果。CSE对非阻塞请求处理的支持释放了请求发起者的精力来进行其它工作，而不是被阻塞以等待CSE完成请求的处理。<request>资源的创建只能由以非阻塞方式接收和处理请求的CSE允许。在一个示例中，可以不允许请求发起者创建<request>资源。

图2示出了图示IoT应用、IoT服务层和控制石油管道上的阀门的一个或多个IoT设备之间的示例交互的流程图。在这个示例中，IoT应用发送每日请求消息以在特定时间打开/关闭特定阀门以控制油的流量。例如，每天下午1点，可以发送打开某个阀门、然后在下午5点再次将其关闭的请求。这可以要求IoT应用和SL每天每个阀门交换重复的开/关请求和响应消息对的两个集合。

许多类型的IoT部署都涉及SL请求发起者(例如，IoT应用)发送重复请求以控制或采样IoT设备的状态，如图2中所示。这导致在请求发起者和SL之间重复进行请求和响应交换。随着时间的流逝，这些重复和冗余的请求的处理可能导致底层网络、应用、设备和SL的大量累积开销。对于带宽受限且资源受约束的底层网络和设备(例如，电池供电的设备)，尤其如此。重复请求和响应消息传递的开销表示许多IoT部署的可扩展性问题。减少这种开销可以允许IoT部署扩展，以处理增加数量的设备，同时降低部署成本。

使SL能够代表IoT应用来分流请求和响应可以减少底层网络、应用和设备的拥塞和/或开销。本文公开了既可定制又可扩展的机制，以允许IoT应用将请求生成和响应处理分流到IoT SL。

可以使SL具有脚本化和生成IoT应用请求的能力，使得请求可以由SL发起，而IoT应用不必重复地重新发布相同的请求(例如，定期地检索传感器读数)。这种脚本化可以由请求发起者发起。附加地或可替代地，SL可以支持监视和检测重复请求并发起自身脚本化的能力。SL还可以基于既定的响应处理准则的集合来对响应的处理进行脚本化并执行诸如响应的批处理、过滤和聚合之类的操作。这种脚本化功能可以使SL能够代表IoT应用来执行操作。因此，可以最小化IoT应用和设备以及底层网络上的消息传递开销。所公开的SL请求和响应脚本化能力可以启用基于边缘/基于雾的IoT部署。因此，部署在边缘/雾节点上的IoT SL可以能够代表更接近部署IoT设备的网络边缘的IoT应用来执行操作。

本文公开了IoT SL消息脚本化服务(MSS)。MSS可以支持以下能力中的一项或多项能力：

MSS可以将SL请求信息存储在SL scriptedRequest(脚本化的请求)资源中，使得MSS可以使用这个信息来代表请求发起者生成请求；

将请求信息存储在scriptedRequest资源中可以基于来自请求发起者的显式请求，以指示MSS创建scriptedRequest资源；

MSS可以代表请求发起者自动检测重复SL请求的模式并自主创建scriptedRequest资源以存储请求信息。这种自动检测能力可以是可配置的。也可以为选定的请求发起者和/或请求类型启用或禁用自动检测能力；

MSS可以向请求发起者通知它已经自动检测并记录了(一个或多个)重复请求，以及代表发起者自动生成未来请求的提议(offer)。在接收到这个通知后，请求发起者可以回复MSS以接受或者拒绝提议；

使用存储在scriptedRequest资源中的信息，MSS可以从请求发起者分流SL请求的生成，并代表它们触发请求的生成和处理；

对于代表请求发起者生成的请求，MSS可以执行可以基于在scriptedRequest资源中定义的响应准则的响应处理；

如果/当多个scriptedRequest资源彼此链接时，MSS可以代表请求发起者发布自动请求序列；以及

如果/当scriptedRequest资源链接到其它类型的SL资源时，如果/当已经满足由这些其它资源类型定义的触发准则时，MSS可以生成脚本化的请求。

在示例中，一种方法可以包括：从第一实体接收与第二实体通信的多个请求；确定与第二实体通信的多个请求中的两个或更多个请求形成重复请求模式；基于确定与第二实体通信的多个请求中的两个或更多个请求形成重复请求模式而创建脚本化的请求资源，其中脚本化的请求资源使服务层实体能够代表第一实体向第二实体发送脚本化的请求，并且其中脚本化的请求资源包括用于触发一个或多个脚本化的请求的生成的一个或多个条件；以及基于确定已经满足用于触发一个或多个脚本化的请求的生成的条件中的一个或多个条件并且向第二实体发送脚本化的请求。

脚本化的请求可以被服务层实体用来代表第一实体将信息自动传送给第二实体。服务层实体可以配置有一个或多个策略，该一个或多个策略使服务层实体能够确定与第二实体通信的多个请求是否形成重复请求模式。该方法还可以包括：基于在服务层实体处确定与第二实体通信的请求中的两个或更多个请求形成重复请求模式，从第一实体接收自动创建脚本化的请求资源的指令。该方法还可以包括向第一实体发送脚本化的请求资源已经被创建的指示以及脚本化的请求资源的标识符。该方法还可以包括：从第一实体接收对更新脚本化的请求资源的条件的请求；基于对更新脚本化的请求资源的条件的请求，更新脚本化的请求资源的条件。该方法还可以包括：从第二实体接收对脚本化的请求的响应；在服务层实体处并基于脚本化的请求资源中识别出的一个或多个响应参数来处理响应；以及向第一实体发送经处理的响应。

在示例中，一种方法可以包括：从第一实体接收创建脚本化的请求资源的请求，该脚本化的请求资源使服务层实体能够代表第一实体向第二实体发送脚本化的请求，创建脚本化的请求资源的请求包括用于触发脚本化的请求的生成的一个或多个条件的指示；在服务层实体处创建脚本化的请求资源；在服务层实体处确定已经满足用于触发脚本化的请求的生成的一个或多个条件；在服务层实体处并且响应于确定已经满足用于触发脚本化的请求的生成的一个或多个条件而生成脚本化的请求；以及向第二实体发送脚本化的请求。

创建脚本化的请求资源的请求可以包括一个或多个参数，用于确定已经满足用于触发脚本化的请求的生成的一个或多个条件，该一个或多个参数包括以下一个或多个：由第一实体发送的请求的类型、第一实体的标识符、第二实体的标识符、要发送给第二实体的响应的类型以及用于脚本化的请求资源的到期条件。该方法还可以包括：基于脚本化的请求，从第二实体接收一个或多个响应；以及在服务层实体处并基于在脚本化的请求资源中识别出的一个或多个响应参数来处理一个或多个响应。处理一个或多个响应可以包括以下中的至少一个：批处理一个或多个响应、聚合一个或多个响应、以及过滤一个或多个响应。该方法还可以包括向第一实体发送一个或多个经处理的响应。创建脚本化的请求资源的请求可以包括模式标识符，该模式标识符指示服务层实体可以用来创建脚本化的请求的模式的位置。生成脚本化的请求可以包括检索由模式标识符识别出的模式。

在示例中，一种方法可以包括：从第一实体接收创建多个脚本化的请求资源的请求，多个脚本化的请求资源中的每一个使服务层实体能够代表第一实体向多个设备中的设备发送脚本化的请求，创建多个脚本化的请求资源的请求对于脚本化的请求资源中的每一个包括用于触发脚本化的请求的生成的一个或多个条件的指示；在服务层实体处创建多个脚本化的请求资源，该多个脚本化的请求资源中的至少一个包括到多个脚本化的请求资源中的另一个的链接；在服务层实体处确定已经满足用于触发与脚本化的请求资源中的第一个相关联的脚本化的请求的生成的一个或多个条件；响应于确定已经满足用于触发与脚本化的请求资源中的第一个相关联的脚本化的请求的生成的一个或多个条件而生成与脚本化的请求资源中的第一个相关联的脚本化的请求；向多个设备中的第一设备发送与脚本化的请求资源中的第一个相关联的脚本化的请求；从第一设备接收基于与脚本化的请求资源中的第一个相关联的脚本化的请求的一个或多个响应；确定脚本化的请求资源中的第一个包括到脚本化的请求资源中的第二个的链接；以及生成与脚本化的请求资源中的第二个相关联的脚本化的请求。

该方法还可以包括向多个设备中的第二设备发送与脚本化的请求资源中的第二个相关联的脚本化的请求；从第二设备接收基于与脚本化的请求资源中的第二个相关联的脚本化的请求的一个或多个响应；确定脚本化的请求资源中的第二个包括到脚本化的请求资源中的第三个的链接；以及生成与脚本化的请求资源中的第三个相关联的脚本化的请求。该方法还可以包括在服务层实体处并基于在脚本化的请求资源中识别出的一个或多个响应参数来处理基于与脚本化的请求资源中的第一个相关联的脚本化的请求的一个或多个响应。创建多个脚本化的请求资源的请求还可以包括多个模式标识符，该多个模式标识符中的每一个指示服务层实体可用来创建脚本化的请求的模式的位置。基于与脚本化的请求资源中的第一个相关联的脚本化的请求来处理一个或多个响应可以包括以下中的至少一个：批处理一个或多个响应、聚合一个或多个响应、以及过滤一个或多个响应。该方法还可以包括向第一实体发送一个或多个经处理的响应。

图3示出了图示消息脚本化服务(MSS)的操作的示例流程图。在这个示例中，IoT应用创建第一脚本化的SL请求资源(例如，如步骤1和步骤2中所示)，这导致MSS代表它创建请求，该请求被发送到IoT设备以在每天下午1点打开阀门(例如，如步骤5、步骤6和步骤7中所示)。同样，IoT应用创建第二脚本化的SL请求资源(例如，如步骤3和步骤4中所示)，这导致MSS创建请求以使IoT设备每天下午5点关闭阀门(例如，如步骤9、步骤10和步骤11中所示)。基于IoT应用的偏好，它可以可选地配置它创建的脚本化的SL请求资源，以使MSS向它通知它接收到的针对脚本化的请求的响应(例如，如步骤8、步骤12、步骤16和步骤20中所示)。虽然在这个示例中未示出，但MSS还可以检测重复请求的模式并代表请求发起者自主地创建脚本化的SL请求。

虽然下面示出的示例具体地提到了IoT SL和IoT应用之间的重复消息交换，但是所公开的方法和系统也可以应用于IoT SL或IoT SL和IoT设备的两个或更多个实例之间的重复消息交换。应注意的是，MSS和/或IoT服务层可以驻留在IoT设备上。在这种场景中，IoT设备可以是IoT应用。

SL可以支持能够从请求发起者分流SL请求的生成和处理的消息脚本化服务(MSS)。例如，如果/当传感器的响应包括超过由请求发起者指定的阈值的值时，SL可以代表应用定期地检索传感器的值并向应用发送通知。

MSS可以支持允许SL请求发起者用要被脚本化的一个或多个SL请求来配置MSS的能力。一旦配置完成，请求者就可以手动触发MSS以按需方式生成(一个或多个)脚本化的请求，而不必向SL发送实际请求。请求者还可以用脚本化的请求生成准则来配置MSS，以允许MSS自身自动触发并基于是否/何时满足指定的准则来生成(一个或多个)请求。示例准则可以包括时间表(schedule)信息或可以引用一个或多个SL托管的资源的状态的逻辑表达式。

MSS可以支持自动检测重复请求的模式的能力。当检测请求的模式时，MSS可以检测触发请求的生成的条件(例如，时间表、事件等)。使用这个信息，MSS可以对这些请求进行脚本化，使得未来的请求可以由MSS代表请求发起者来生成和处理。MSS对请求的这种自动检测和脚本化可以由策略驱动。MSS可以被配置有定义脚本化规则的策略，这些脚本规则控制MSS是否/何时执行自动请求脚本化。

MSS可以向请求发起者通知它已经检测到(一个或多个)重复请求并且创建了(一个或多个)脚本化的请求。在这个通知中，MSS可以包括基于(一个或多个)脚本化的请求来代表请求者自动生成(一个或多个)未来的请求的提议。通过响应这个通知，请求发起者可以接受或者拒绝MSS的提议。如果被接受，那么MSS可以基于MSS已记录在脚本化的请求中的请求信息来代表请求者自动生成请求。

MSS可以支持允许请求者查询和发现由MSS支持的一个或多个脚本化的SL请求的能力。一旦被发现，请求者就可以手动触发MSS以基于脚本化的请求生成请求。MSS可以基于请求者是否对脚本化的请求具有适当的访问特权来限定请求者对脚本化的请求的发现和触发。

MSS可以支持将多个脚本化的请求彼此链接在一起的能力。如果/当多个脚本化的请求链接在一起时，MSS可以代表请求者发布脚本化的请求序列。

MSS可以支持将脚本化的请求链接到其它类型的SL资源的能力。在这样做时，如果/当已经满足由这些其它资源类型定义的准则时，MSS可以触发脚本化的请求的生成。例如，脚本化的请求可以链接到以下类型的SL资源中的一个或多个。如果/当发生以下情况时，这可以导致MSS触发脚本化的请求的生成和处理：

已经满足SL订阅资源的事件通知准则；和/或

已经满足SL事务资源的执行准则。

在代表请求者生成请求之后，MSS可以代表请求者执行脚本化的响应处理。这种响应处理可以基于一个或多个响应处理策略。MSS可以支持各种响应处理策略，诸如响应的过滤、批处理和聚合。通过支持这些响应处理能力，MSS可以为其请求发起者提供更高级别的自动化和分流。MSS可以通过减少必须跨网络传输的不必要和重复的响应的数量来分流网络。例如，可以返回满足由应用定义的某些准则的响应，并且不满足准则的其它响应可以由SL过滤并且不返回给请求发起者。

MSS可以支持由一种或多种类型的资源组成的API，该API可以用于用关于SL请求的脚本化的信息来对MSS进行编程。在一个示例中，MSS可以支持scriptedRequest资源。这个资源的每个实例都可以定义脚本化的SL请求，MSS可以使用该脚本SL请求来代表请求者生成重复请求。与SL请求相关的附加信息可以存储在这个资源中，诸如何时应当生成请求以及应当如何处理对该请求的响应。可以将这个资源的多个实例链接在一起以形成MSS可以代表一个或多个请求者重复生成的SL请求原语序列。

scriptedRequest资源可以支持但不限于以下中的一个或多个：

(1)MSS可以用来获取被用于创建由scriptedRequest资源描述的有效SL请求的模式的模式标识符。这个模式可以包括诸如请求中元素的排序、哪些元素是必需元素和可选元素、每个元素的值的数据类型定义等信息。

(2)MSS可以用来生成和发布由scriptedRequest资源描述的SL请求的一个或多个参数，诸如但不限于：

(a)请求的类型；

(b)发起者指定的请求内容或指向内容存储位置的链接；

(c)请求发起者的标识符；

(d)请求的一个或多个指定目标；

(e)发起者期望的响应的类型；

(f)请求的到期时间；以及

(g)(一个或多个)目标将要执行请求的时间。

(3)MSS可以将其用作用于触发由scriptedRequest资源描述的SL请求的生成和发布的条件的准则，诸如但不限于：

(a)控制MSS何时触发由scriptedRequest指定的请求的生成和发布的时间表信息；

(b)可以引用一个或多个SL托管的资源的状态的逻辑表达式。SL可以使用这个表达式来限定是否触发由scriptedRequest指定的请求的发布；以及

(c)描述在接收到某些响应或响应类型的情况下MSS是否应当停止触发SL请求的生成和发布的表达式。

(4)MSS在执行由scriptedRequest指定的请求时可以向其返回(一个或多个)响应或(一个或多个)通知的一个或多个指定的响应目标；

(5)允许基于在scriptedRequest资源中指定的信息来(例如，由应用)手动触发MSS以生成SL请求的机制；

(6)允许(例如，由应用)手动启用/禁用MSS生成由scriptedRequest资源指定的SL请求的机制；以及

(7)控制MSS如何处理对脚本化的请求的响应的一个或多个指定的响应规则。一些示例规则可以包括以下内容：

(a)将对请求的响应一起批处理；

(b)过滤对请求的响应；

(c)聚合对请求的响应的内容。这可以包括处理响应的内容；以及

(d)脚本正在按指定的方式运行的定期的“心跳”确认。

MSS可以支持以下能力：允许请求者通过利用SL可以代表请求者发布和重新发布的一个或多个请求对SL进行手动编程来对他们自己的请求进行脚本化。一旦进行了脚本化，请求者就可以手动触发MSS以按需生成(一个或多个)请求。此外，请求者可以配置准则，如果/当已经满足指定的准则时，MSS可以使用该准则来触发(一个或多个)请求的生成。MSS还可以允许请求者发现、更新或删除脚本化的请求。

在一个示例中，请求者(例如，IoT应用、设备或另一个SL实例)可以创建由MSS托管的scriptedRequest资源。可以手动创建此scriptedRequest资源。一旦创建了scriptedRequest资源，请求者(或另一个请求者)就可以使用它来触发MSS以生成并发布一次或多次请求。一旦被触发，MSS就可以代表请求者来发布请求并使用在scriptedRequest资源中指定的信息和准则来处理响应。以这种方式生成请求和处理响应可以减少请求者需要发送和接收的消息的数量，尤其是对于请求和响应本质上是重复的情况。图4示出了图示脚本化的服务层请求的手动创建的流程图。

在步骤1处，请求者(例如，IoT应用)向MSS发送请求以创建scriptedRequest资源，其目的是使MSS代表请求者生成并向IoT设备发送每天下午1点打开阀门的脚本化的请求。该请求可以被配置有诸如但不限于以下的信息：

(1)MSS可以用来获取用于创建由scriptedRequest资源描述的有效SL请求的模式的模式标识符；

(2)MSS可以用来生成和发布由scriptedRequest资源描述的SL请求的一个或多个参数，诸如但不限于：

(a)请求的类型；

(b)发起者指定的请求内容或指向内容存储位置的链接以插入到请求中；

(c)请求发起者的标识符；

(d)请求的一个或多个指定的目标(例如，资源、应用、设备或服务)；

(e)发起者想要作为回报的响应的类型(例如，成批的、未成批的、聚合的、未聚合的、经过滤的、未经过滤的)；

(f)其后MSS停止生成脚本化的请求的到期时间；

(g)(一个或多个)目标将要执行请求的时间；以及

(h)可以被包括在请求中的安全密钥或授权令牌，以便脚本化的请求的接收者可以确定MSS被授权代表发起者向接收者发送请求。

(3)MSS可以将其用作用于触发由scriptedRequest资源描述的SL请求的生成和处理的条件的一个或多个执行准则，诸如但不限于：

(a)控制MSS何时触发由scriptedRequest指定的请求的生成和发布的时间表信息；

(b)可以引用一个或多个SL托管的资源的状态的逻辑表达式。MSS可以使用这个表达式来限定是否触发由scriptedRequest指定的请求的生成和发布；

(c)MSS应当生成由scriptedRequest资源描述的SL请求的指定次数；

(4)当执行由scriptedRequest指定的请求时，MSS应向其返回(一个或多个)响应的一个或多个指定目标；

(5)控制是否启用/禁用scriptedRequest资源以及MSS是否应当尝试基于该scriptedRequest资源来处理和发送请求的指示符；

(6)一个或多个指定的响应准则，以控制MSS应当如何处理由scriptedRequest资源指定的请求的响应的处理，诸如但不限于：

(a)基于以下中的一个或多个将响应一起批处理：

(i)将要一起批处理成为单个批处理响应的响应的最大数量；以及

(ii)将响应一起批处理成单个批处理响应的最大持续时间；

(b)基于以下中的一个或多个对请求的响应的过滤：

(i)仅返回导致错误的对请求的响应；以及

(ii)仅返回包含具有与指定值和运算符(诸如<、>、<＝、＝>、＝、！＝)匹配的值的数据的响应。

(c)基于以下中的一个或多个来聚合响应：

(i)将要聚合在一起成为单个聚合响应的响应的最大数量；以及

(ii)将响应聚合在一起成为单个聚合响应的最大持续时间；以及

(iii)要执行的聚合的类型，诸如：

A.在指定的持续时间内，针对指定的聚合准则来分析每个接收到的响应中的一个或多个响应元素并找到满足聚合准则的(一个或多个)响应。例如，在指定的持续时间内，找到具有为特定元素定义的最小值的接收到的响应；

B.在指定的持续时间内，对具有匹配指定准则的(一个或多个)元素的响应的数量进行计数；

C.在指定的持续时间内，执行跨越所有接收到的响应的累积操作。例如，在响应中执行一个或多个元素的累积和或平均；以及

D.在指定的持续时间内，跨所有接收到的响应执行累积级联。例如，如果响应包含串值，那么聚合响应可以是这些串的逗号分隔组合。

在步骤2处，MSS创建scriptedRequest资源并将响应返回给请求者，通知请求者资源已成功创建。

在步骤3处，请求者将请求发送到MSS以创建scriptedRequest资源，其目的是使MSS代表请求者生成并向IoT设备发送每天下午5点关闭阀门的脚本化的请求。该请求被配置有与步骤1中所描述的类似的信息。

在步骤4处，MSS创建scriptedRequest资源并将响应返回给请求者，通知请求者资源已成功创建。

在步骤5处，MSS监视在每个scriptedRequest资源中指定的执行准则，以确定是否/何时满足其生成脚本化的请求的适当条件。在这个示例中，准则是基于时间表的(例如，在下午1点，MSS检测到已满足其触发生成脚本化的请求以打开阀门的适当条件)。在准则基于依照一个或多个其它SL托管的资源的状态而定的逻辑表达式的情况下，MSS可以监视这些资源的状态，以确定其集体状态是否/何时满足用于生成脚本化的请求的准则。附加地或可替代地，MSS可以由可以向MSS发送触发请求的应用来触发。

在步骤6处，一旦被触发，MSS就使用scriptedRequest资源中指定的信息来生成脚本化的请求。MSS可以执行诸如但不限于以下的操作：

(1)获取由scriptedRequest的模式标识符指定的模式，并使用这个模式来确定例如脚本化的请求中要求哪些信息元素、元素的适当次序及其数据类型。

(2)对于模式中指定的每个元素，MSS首先尝试找到scriptedRequest资源中指定的对应属性名称。如果找到的话，那么MSS将属性中指定的值指派给MSS正在生成的脚本化的请求内的对应元素。典型类型的元素的一些示例可以包括：

(a)请求的类型；

(b)发起者指定的请求内容或指向内容存储位置的链接；

(c)请求发起者的标识符；

(d)请求的目标或目标组的标识符；

(e)目标应当执行请求的时间；

(f)目标应当认为请求已到期并且不执行它的时间；

(g)需要响应的时间；

(h)请求的优先级；以及

(i)所请求的响应的格式

(3)对于在模式中指定的MSS无法找到匹配的scriptedRequest资源属性的任何元素，MSS可以指派值(如果适用的话)。这些值的指派可以基于MSS本地策略或MSS从监视先前的请求中学习到的知识以及这些请求中这些元素的值。例如，MSS可以向请求中的元素指派值，诸如但不限于：

(a)请求的唯一标识符；

(b)请求是否可以以阻塞或非阻塞方式被服务；和/或

(c)任何先前提到的scriptedRequest属性；

(4)对于在scriptedRequest资源内指定的每个目标，MSS生成请求并将其单独地或者作为组请求发送给目标。

在步骤7处，请求由目标接收并处理。然后目标向MSS返回响应。

在步骤8处，当从(一个或多个)目标接收针对给定脚本化的请求的(一个或多个)响应时，MSS可以检查用于生成脚本化的请求的scriptedRequest资源中指定的响应准则，以确定如何处理(一个或多个)响应。基于响应准则，MSS可以执行诸如但不限于以下的操作：

(1)在将成批的响应集合返回给请求者之前，通过将它们级联成单个消息来将指定数量的个体响应一起批处理(例如，级联在一起)；

(2)在将成批的响应集合返回给请求者之前，通过在指定的持续时间或时间表上将它们级联成单个消息来将个体响应一起批处理(例如，级联在一起)成为单个消息；

(3)通过处理响应并将其级联成单个响应并将响应返回给请求者来将指定数量的个体响应聚合在一起；

(4)在将响应返回给请求者之前，通过在指定的持续时间或时间表中处理响应并将其级联成单个响应来将个体响应聚合在一起；以及

(5)过滤响应并且仅在已经满足某些过滤条件的情况下才将响应返回给请求者。过滤条件可以包括但不限于以下：

(a)仅返回导致错误的对请求的响应；和/或

(b)仅返回包含具有与指定的条件运算符(诸如<、>、<＝、＝>、＝、！＝)匹配的值的一个或多个元素和值的响应。该值可以是显式值，或者是对可以使用当前值的资源的引用。

在步骤9处，MSS监视在每个scriptedRequest资源中指定的准则，以确定是否/何时满足其生成脚本化的请求的适当条件。在一个示例中，准则是基于时间表的(例如，在下午5点，MSS检测到已满足其触发关闭阀门的脚本化的请求的生成的适当准则)。

步骤10-12可以与步骤6-8相同。

步骤13-16可以与步骤5-8相同。

步骤17-20可以与步骤9-12相同。

在步骤21处，请求者(例如，IoT应用)将请求发送到MSS，以删除scriptedRequest资源，以便在下午1点打开阀门以停止MSS代表其生成脚本化的请求。附加地或可替代地，当请求者从SL除名(dis-enroll)或取消注册时，或者当MSS检测到scriptedRequest的一个或多个目标不再可用或响应时，或者当MSS检测到执行标准已到期(例如，发布了最大数量的请求、时间表已到期等)时，MSS可以删除scriptedRequest资源。当scriptedRequest资源被请求者删除并且MSS具有其尚未接收到响应的未完成(outstanding)请求时，MSS可以取消请求并丢弃可能接收的任何响应。可替代地，MSS可以在删除scriptedRequest之前阻塞删除请求，直到所有未完成的请求都已经完成并处理了响应为止。

在步骤22处，MSS返回针对删除请求的响应，指示其已经删除了scriptedRequest资源，因此将不再为其生成脚本化的请求。

步骤23-24可以与步骤21-22相同。

在一个示例中，请求者可以通过更新scriptedRequest资源来手动触发SL以生成脚本化的请求。因此，MSS可以代表请求者生成脚本化的请求。

虽然对于由MSS生成的每个脚本化的请求，手动触发可能需要在请求者和MSS之间发送请求消息，但是仍可以实现成本节省，因为可以使这些触发请求比正常请求小，从而仍然可以优化网络带宽使用率。此外，还可以实现脚本化的请求的其它益处，诸如应用和设备逻辑的简化、批处理、聚合和响应的过滤。图5示出了图示脚本化的服务层请求的手动触发的流程图。

在步骤1a(可选)处，请求者(例如，IoT应用)向MSS发送(一个或多个)请求，以发现与一个或多个指定的查询准则匹配的(一个或多个)scriptedRequest资源。例如，找到可以用于打开/关闭特定阀门的scriptedRequest资源。

在步骤1b(可选)处，请求者向MSS发送创建(一个或多个)scriptedRequest资源的请求，其目的是使MSS代表请求者生成并向IoT设备发送打开和关闭阀门的脚本化的请求。

在步骤2处，请求者发送触发MSS生成针对指定的scriptedRequest资源的脚本化的请求的手动请求。可以经由针对scriptedRequest资源的属性或虚拟子资源的RESTfulUPDATE(更新)操作来实现这种触发请求。MSS可以将UPDATE操作解释为它应当生成脚本化的请求的指示。除了UPDATE中的触发指示外，请求者还可以包括附加信息，以修改scriptedRequest中的某些属性(例如，目标)。这可以允许scriptedRequest资源被重新使用和适配，而不是生成单独且独立的scriptedRequest资源。

在步骤3处，一旦被触发，MSS就使用scriptedRequest资源中指定的信息来生成脚本化的请求。

在步骤4处，请求由目标接收并处理。然后目标将响应返回给MSS。

在步骤5(可选)处，当从目标接收到针对给定脚本化的请求的响应时，MSS可以检查用于生成脚本化的请求的scriptedRequest资源中指定的响应准则，以确定如何处理响应。

步骤6-9可以与步骤2-5相同。

在一个示例中，请求者(例如，IoT应用)可以创建托管在SL上的scriptedRequest资源序列。一旦创建了scriptedRequest资源序列，请求者或另一个请求者就可以使用它来触发SL生成并发布请求序列。一旦被触发，SL就可以代表请求者发布请求序列，并使用scriptedRequest资源中指定的信息和准则来处理响应。以这种方式生成请求和处理响应可以减少在请求者和SL之间流动的消息的尺寸和数量，尤其是对于请求和响应本质上是重复的情况。图6示出了图示脚本化的服务层请求序列的手动创建的示例流程图。

在步骤1-6处，请求者(例如，IoT应用)将请求发送到MSS以创建三个scriptedRequest资源，用于分别代表请求者向IoT设备1、2和3发送脚本化的请求。除了被配置有相应的SL请求参数之外，scriptedRequest资源还可以被如下配置：

(1)设备1的scriptedRequest资源可以被配置有指向设备2的scriptedRequest资源的链接。MSS可以使用这个链接来检测脚本化的请求序列关系。

(2)设备2的scriptedRequest资源可以被配置有指向设备3的scriptedRequest资源的链接。MSS可以使用这个链接来检测脚本化的请求序列关系。

(3)设备3的scriptedRequest资源可以不被配置有链接。

在步骤7处，MSS监视在每个scriptedRequest资源内指定的准则，以确定是否/何时满足其生成脚本化的请求的适当条件。在这个示例中，最终满足了用于与设备1相关联的scriptedRequest的准则。

在步骤8处，MSS使用在设备1的scriptedRequest资源中指定的信息来生成脚本化的请求。

在步骤9处，请求由设备1接收并处理。设备1向MSS返回响应。

在步骤10(可选)处，当从设备1接收到针对脚本化的请求的响应时，MSS可以检查在用于生成脚本化的请求的相同scriptedRequest资源中指定的响应准则，以确定如何处理响应。

在步骤11处，MSS检查设备1的scriptedRequest资源，以查看其是否与其它scriptedRequest资源具有任何脚本化的请求序列关系。MSS通过检查以查看是否在设备1的scriptedRequest资源中配置了指向另一个scriptedRequest资源的链接来完成这个操作。在这个示例中，它找到与设备2的scriptedRequest资源的脚本化的请求序列关系。基于此，MSS触发针对设备2的脚本化的请求的生成。

在步骤12处，请求由设备2接收并处理。设备2向MSS返回响应。

步骤13(可选)可以与步骤10相同。

在步骤14处，MSS检查设备2的scriptedRequest资源，以查看其是否与其它scriptedRequest资源具有任何脚本化的请求序列关系。MSS通过检查以查看是否在设备2的scriptedRequest资源中配置了指向另一个scriptedRequest资源的链接来完成这个操作。在这个示例中，它找到与设备3的scriptedRequest资源的脚本化的请求序列关系。基于此，MSS触发针对设备3的脚本化的请求的生成。

在步骤15处，请求由设备3接收并处理。设备3向MSS返回响应。

步骤16(可选)可以与步骤10相同。

步骤17(可选)可以与步骤7相同。

步骤18-26可以与步骤8-16相同。

在一个示例中，在检测到来自请求者的重复请求后，MSS可以支持自主创建scriptedRequest资源的能力。MSS可以利用MSS策略内定义的规则来确定其处理的请求是否重复。在检测到重复请求后，MSS可以创建scriptedRequest资源并将重复请求信息记录在资源内。MSS可以通知请求者以告知他们已创建scriptedRequest。反过来，请求者可以决定是否批准MSS代表他们开始生成脚本化的请求。如果获得批准，那么SL可以代表请求者来发布脚本化的请求并使用scriptedRequest资源中指定的信息和准则来处理响应。可以基于MSS策略以及基于来自请求者的输入来配置响应准则。图7示出了图示脚本化的服务层请求的自动创建的示例流程图。

在步骤1a(可选)处，MSS被配置有一个或多个策略，该一个或多个策略指定MSS将其用来检测限定由MSS进行自动脚本化的请求的规则。规则可以包括诸如但不限于以下的信息：

在重复请求之间允许的定时变化的最大量。如果超过了时间的变化，那么请求不被认为是脚本化的候选；以及

指定的请求元素(例如，目标、标签、操作、内容等)的列表。为了让请求被认为是重复的并且是脚本化的候选，这个列表中每个元素的值可以需要在检测到的序列中的所有请求中都匹配。

在步骤1b(可选)处，MSS可以支持允许请求者选择加入/退出由MSS进行的自动脚本化的请求处理的能力。当选择加入时，请求者可以为MSS配置通知地址，针对该地址MSS可以向其发送脚本化的请求通知。如果请求者选择加入，那么MSS可以监视从请求者接收的请求，以确定是否存在机会让MSS执行自动脚本化的请求处理。当请求者选择加入时，它可以指示它仅针对以某些目的地为目标的请求选择加入。如果请求者选择退出，那么MSS可以不监视从请求者接收的请求。

在步骤2-10处，请求者开始发布在每天下午1点检索由IoT设备托管的传感器的值的重复请求。

在步骤11处，请求者第三次执行检索请求时，MSS检测到重复请求模式。检测可以基于如步骤1a中所述的MSS策略内配置的规则。

在步骤12处，基于重复请求模式的检测，MSS创建scriptedRequest资源。

在步骤13-15处，MSS完成对第三请求的处理并将响应返回给请求者。在对请求者的响应中，MSS可以可选地包括它代表请求者创建了scriptedRequest资源连同URI或者scriptedRequest资源的某个标识符的指示。然后，请求者可以针对URI或标识符给予批准。

在步骤16(可选)处，在接收到包括创建了scriptedRequest资源的MSS指示的响应或通知之后，请求者可以检索和/或更新scriptedRequest资源以执行诸如但不限于以下中的一个或多个的操作：

提供批准以允许MSS代表其对请求进行脚本化。可以通过激活scriptedRequest资源来给予批准(例如，经由在资源中配置和启用/禁用属性)；以及

基于请求者的偏好，更新MSS在scriptedRequest资源中配置的一些设置。例如，配置响应准则、配置请求到期定时器等。

在步骤17(可选)处，代替如步骤15中定义的那样在对请求者的响应中返回指示，MSS可以向请求者发送通知请求，以通知它MSS代表请求者创建了scriptedRequest资源。可以在请求者选择加入时(例如，在登记、注册等期间)配置请求者的通知目标地址。在通知内，MSS可以包括scriptedRequest信息，诸如scriptedRequest资源的表示或标识符。请求者可以使用这个信息来确定哪个请求已被脚本化，以及是否希望MSS代表它来对这个请求进行脚本化。如果给予批准，那么请求发起者可以停止生成请求并让MSS代表它生成请求。

在步骤18(可选)处，为了选择加入并批准MSS使其代表请求者生成脚本化的请求，请求者可以向MSS返回通知响应。在响应中，请求者可以包括批准信息以及对MSS在scriptedRequest资源中配置的设置的一些更新。例如，配置响应准则、配置请求到期定时器等。

在步骤19处，MSS监视scriptedRequest资源内指定的准则，以确定是否/何时满足其生成脚本化的请求的适当条件。在这个示例中，准则是基于时间表的(例如，在下午1点，MSS检测到已满足其触发脚本化的请求的生成的适当准则)。

在步骤20处，一旦被触发，MSS就使用scriptedRequest资源中指定的信息来生成脚本化的请求。

在步骤21处，请求由目标接收并处理。然后目标向MSS返回响应。

在步骤22处，当从目标接收到针对给定脚本化的请求的响应时，MSS可以检查用于生成脚本化的请求的scriptedRequest资源中指定的响应准则，以确定如何处理响应。

步骤23-26可以与步骤19-22相同。

在步骤27处，请求者向MSS发送删除scriptedRequest资源以停止MSS代表其生成脚本化的请求的请求。附加地或可替代地，当请求者从SL除名或取消注册时，或者当MSS检测到scriptedRequest的一个或多个目标不再可用或响应时，MSS可以删除scriptedRequest资源。

在一个示例中，MSS可以支持在检测到来自一个或多个请求者的重复的请求序列后自主创建scriptedRequest资源序列的能力。MSS可以利用SL策略中定义的规则来确定其处理的请求是否是重复请求序列。在检测到重复请求序列后，MSS可以创建个体scriptedRequest资源来存储序列中的每个请求的信息。MSS可以使用scriptedRequest资源的链接属性将各个scriptedRequest资源链接在一起。在这个属性内，MSS可以存储序列中下一个scriptedRequest资源的标识符。MSS可以可选地通知(一个或多个)请求者，以通知他们已创建scriptedRequest资源序列。(一个或多个)请求者可以批准MSS代表他们生成请求序列。如果给予批准，那么MSS可以代表(一个或多个)请求者发布请求序列并使用scriptedRequest资源中指定的信息和准则来处理响应。

MSS可以支持检测序列请求的模式，其中各个请求源自多于一个请求者。因此，MSS不仅可以对来自个体请求者的请求序列进行脚本化，而且还可以对源自多个请求者的请求序列进行脚本化。

图8示出了用于自动创建脚本化的SL请求序列的示例方法。

在步骤1a(可选)处，MSS被配置有一个或多个策略，该一个或多个策略指定MSS将其用来检测限定MSS进行自动脚本化的重复请求序列的规则。规则可以包括诸如但不限于以下的信息：

在重复的请求序列的相继迭代中的最大定时变化量。如果超过了时间的变化，那么序列可以不被认为是进行脚本化的候选；以及

指定的请求元素的列表(例如，目标、标签、操作、内容等)。对于被认为是重复的并且是脚本化的候选的请求序列，这个列表中的每个元素的值可能需要在请求序列的相继迭代中跨对应的请求进行匹配。

在步骤1b(可选)处，MSS可以支持允许请求者选择加入/退出请求序列的自动脚本化的能力。如果请求者选择加入，那么MSS可以监视从请求者以及其它请求者接收的请求，以确定是否存在机会让MSS对重复的请求序列执行自动脚本化。如果请求者选择退出，那么MSS可以不监视从请求者接收的请求。

在步骤2-8处，一个或多个请求者开始发布重复的请求序列。

在步骤9处，MSS检测重复的请求序列。检测可以基于如步骤1a中所述的MSS策略内配置的规则。基于对重复的请求序列的检测，MSS为序列中的每个请求创建scriptedRequest资源。

在步骤10(可选)处，MSS可以向(一个或多个)请求者发送通知请求，以通知他们MSS代表他们创建了一个或多个scriptedRequest资源。可以在(一个或多个)请求者选择加入时(例如，在登记、注册等期间)配置(一个或多个)请求者的通知目标地址。在通知内，MSS可以包括scriptedRequest信息，诸如一个或多个scriptedRequest资源的表示或标识符。请求者可以使用这个信息来确定哪个(哪些)请求适用于(一个或多个)scriptedRequest资源以及是否希望MSS代表它对请求进行脚本化。

在步骤11(可选)处，为了选择加入并批准MSS代表其生成脚本化的请求，请求者可以将通知响应返回给MSS。在响应中，请求者可以包括批准信息以及MSS在(一个或多个)scriptedRequest资源中配置的设置的一些更新。例如，配置响应准则、配置请求到期定时器等。

在步骤12处，MSS监视scriptedRequest资源中指定的准则，以确定是否/何时满足其生成脚本化的请求序列的适当条件。在这个示例中，准则可以基于时间表(例如，在下午1点，MSS检测到已满足其触发序列中的第一脚本化的请求的生成的适当准则)。

在步骤13处，MSS使用在序列中的第一scriptedRequest资源中指定的信息来生成针对设备1的脚本化的请求。

在步骤14处，请求由设备1接收并处理。设备1向MSS返回响应。

在步骤15(可选)处，当从设备1接收到针对脚本化的请求的响应时，MSS可以检查在用于生成第一脚本化的请求的对应scriptedRequest资源中指定的响应准则，以确定如何处理该响应。

在步骤16处，MSS检查设备1的scriptedRequest资源，以查看其是否与其它scriptedRequest资源具有任何脚本化的请求序列关系。MSS可以通过检查以查看在设备1的scriptedRequest资源中是否配置了指向另一个scriptedRequest资源的链接来完成这个操作。在这个示例中，它找到与设备2的scriptedRequest资源的脚本化的请求序列关系。基于此，MSS启用触发器以生成针对设备2的脚本化的请求。一旦被启用，在触发针对设备2的脚本化的请求的生成之前，MSS将等待要满足的适当的触发条件(即，时间等于下午1:05)。在针对设备2生成脚本化的请求之后，MSS禁用设备2的触发器，直到为设备1处理下一个脚本化的请求为止。

在步骤17处，请求由设备2接收并处理。设备2向MSS返回响应。

步骤18(可选)可以与步骤10相同。

在步骤19处，MSS检查设备2的scriptedRequest资源，以查看其是否与其它scriptedRequest资源具有任何脚本化的请求序列关系。MSS通过检查以查看是否在设备2的scriptedRequest资源内配置了指向另一个scriptedRequest资源的链接来完成这个操作。在这种情况下，它找到与设备3的scriptedRequest资源的脚本化的请求序列关系。基于此，MSS启用触发器以生成针对设备3的脚本化的请求。一旦被启用，在触发针对设备3的脚本化的请求的生成之前，MSS将等待要满足的适当的触发条件(例如，时间等于下午1:08)。在为设备3生成脚本化的请求之后，MSS禁用设备3的触发器，直到为设备2处理下一个脚本化的请求为止。

在步骤20处，请求由设备3接收并处理。设备3向MSS返回响应。

步骤21(可选)可以与步骤10相同。

步骤22(可选)可以与步骤9相同。

步骤23-31可以与步骤13-21相同。

在一个示例中，scriptedRequest资源可以被用于为IoT设备、服务和应用构建RESTful API。每个API可以由MSS托管的scriptedRequest资源集合组成。API内的每个scriptedRequest资源可以用于定义由API支持的操作。例如，可以为IoT灯开关设备定义API。当灯开关注册时，MSS可以代表灯开关自动创建scriptedRequest资源。例如，可以定义打开灯的scriptedRequest资源，并且可以定义关闭灯的另一个scriptedRequest资源。IoT应用可以使用这个API。IoT应用可以发现这些资源并使用这些资源与灯开关进行交互，而无需构建和发送请求以完成此操作。例如，为了打开灯，IoT应用可以发送触发请求(例如，对scriptedRequest资源的触发器属性的更新)。当接收到更新请求时，MSS然后可以生成针对IoT灯开关的请求原语。从MSS生成的请求可以包括IoT灯开关所需的所有必要的请求参数。但是，IoT应用可以不需要知道这些参数中的任何参数。IoT应用发送给SL的请求可以只是对scriptedRequest资源的触发器属性的更新请求。因此，可以提高从IoT应用的角度来看的抽象级别，并使抽象级别更加简单和高效(例如，更小的消息)。

在一个示例中，MSS可以为常见的现成的商业可用设备支持RESTful API的(一个或多个)库。这些RESTful API可以基于scriptedRequest资源。当IoT设备、服务或应用登记、注册或连接到IoT SL时，MSS可以基于设备、服务或应用的类型对这个库执行查找，以找到匹配的API。如果找到匹配的API，那么MSS可以实例化在API中定义的对应scriptedRequest资源。在这些实例化的scriptedRequest资源中的每一个中，MSS可以配置信息，诸如目标。此后，这些scriptedRequest资源可以用作用于应用的API，以发现IoT设备、服务或其它应用并与IoT设备、服务或其它应用通信。

本文公开的消息脚本化服务(MSS)和过程可以被支持作为oneM2M公共服务实体(CSE)的新的oneM2M MSS公共服务功能(CSF)。CSE的MSS CSF可以被其它CSE和/或应用实体(AE)暴露和使用。可替代地，MSS功能可以被结合到现有的oneM2M CSF中(例如，通信管理/递送处理)。在一个示例中，本文公开的服务层(SL)可以是oneM2M CSE，本文公开的请求者可以是oneM2M AE或CSE，并且本文公开的MSS可以是oneM2M MSS CSF。

图9示出了用于消息脚本化服务的体系架构的示例，如可以在符合oneM2M标准的网络中实现的。

本文公开了oneM2M<scriptedRequest>资源类型。<scriptedRequest>资源可以是新的资源类型。附加地或可替代地，可以将<scriptedRequest>资源的公开的属性和子资源添加为对现有oneM2M<request>资源的增强。

当注册商(resigstrar)CSE检测到来自其作为脚本化的候选的注册用户(registree)AE或CSE之一的请求模式时，它可以创建一个或多个<scriptedRequest>资源。这些资源可以被用于存储注册商CSE代表注册用户AE或CSE生成脚本化的请求所需的必要信息。附加地或可替代地，AE或CSE可以创建<scriptedRequest>资源。

为了支持脚本化的请求功能，可以为oneM2M<scriptedRequest>资源定义表1中指定的子资源和表2中指定的属性，或者将其添加到现有的oneM2M<request>资源中。

表1：提出的<scriptedRequest>子资源

表2：提出的<scriptedRequest>资源属性

表3：响应处理条件

CSE的MSS CSF可以在响应中包括oneM2M scriptedRequestID响应参数。该参数可以用于向请求者指示已经为与这个响应对应的请求创建了<scriptedRequest>资源。这个参数可以被配置有<scriptedRequest>资源的资源标识符。在接收到包括这个参数的响应之后，请求者可以更新<scriptedRequest>资源以提供其批准，以允许MSS CSF代表其起动脚本化请求。可以通过将<scriptedRequest>资源的scriptedRequestEnable属性设置为TRUE来给予批准。请求者还可以更新<scriptedRequest>资源中的其它属性，以重新配置由MSS CSF指派的默认设置中的一些设置。例如，请求者可以重新配置scriptedRequestCriteria。

具有MSS CSF的注册商CSE可以支持让其注册用户AE和CSE指定他们是否批准其注册商CSE代表其生成脚本化的请求的能力。

注册商CSE可以支持允许其注册用户配置scriptedRequestEnable属性的能力。可以在注册时或此后的某个时间配置这个属性，以启用或禁用注册商CSE代表注册用户对请求进行脚本化。可以为<AE>或<remoteCSE>资源定义这个属性。通过将这个属性设置为TRUE值，注册用户AE或CSE可以批准其注册商CSE监视其请求并寻找代表其对请求进行脚本化和分流的机会。同样，将这个属性设置为FALSE可以通知注册商CSE不要尝试代表其对请求进行脚本化和分流。

注册商CSE可以支持允许其注册用户在注册时或此后的某个时间配置scriptedRequestNotification属性的能力。这个属性可以用于指定路径(例如，/scriptedNotifications)，该路径可以附加到注册用户的pointOfAccess(例如，http://127.25.0.100:80/scriptedNotifications)上，并且注册商CSE可以在其中发送包含对注册用户的请求进行脚本化的提议的通知。如果未使用这个属性，那么注册商CSE可以代替地将这些类型的通知发送到注册用户的pointOfAccess。

具有MSS CSF的注册商CSE可以支持监视来自其注册用户AE和CSE的请求并检测作为脚本化的候选的重复请求和请求序列的能力。如果检测到，并且如果启用了脚本化的请求生成能力(即，注册用户将其scriptedRequestEnableattribute设置为TRUE)，那么注册商CSE可以代表(一个或多个)请求发起者来提议脚本化的未来请求。

具有MSS CSF的注册商CSE可以支持一个或多个可配置的<scriptedRequestPolicy>资源，这些资源可以用于用准则配置MSS CSF。MSS CSF可以使用这些准则来检测作为脚本化的候选的请求的模式。表4中描述了oneM2M<scriptedRequestPolicy>资源的示例。

表4：提出的<scriptedRequestPolicy>资源属性

通过充分利用由<scriptedRequestPolicy>资源定义的策略，注册商CSE可以检测由其注册用户发布的重复请求或请求序列。在检测到后，注册商CSE可以创建一个或多个<scriptedRequest>资源并将资源配置有适当的信息，以使注册商CSE能够代表(一个或多个)注册用户生成脚本化的请求。注册商可以向(一个或多个)注册用户通知它已创建一个或多个<scriptedRequest>资源。可以经由在返回到注册用户的响应中背负scriptedRequestOffer响应参数来发送这个通知。scriptedRequestOffer参数可以包括<scriptedRequest>资源的资源标识符。为了接受注册商的对未来的请求进行脚本化的提议，注册用户可以将<scriptedRequest>资源的scriptedRequestEnable属性设置为TRUE值来启用脚本化的请求。

附加地或可替代地，注册商CSE可以经由它向注册用户的已配置的scriptedRequestNotification发送的显式通知请求将脚本化提议发送到注册用户。

在这个通知内，注册商CSE可以包括<scriptedRequest>资源的一个或多个资源标识符或<scriptedRequest>资源的表示。为了接受脚本化提议，注册用户可以通知响应内提供其批准，或者注册用户可以更新(一个或多个)<scriptedRequest>资源以启用脚本化的请求。

一旦注册用户已经给予批准，注册商CSE就可以基于存储在(一个或多个)<scriptedRequest>资源中的信息开始代表注册用户对请求进行脚本化。

图10示出了根据图9所示和本文描述的示例oneM2M体系架构的脚本化的请求序列的示例。

在步骤1a(可选)处，IN-CSE的MSS被配置有一个或多个<scriptedRequestPolicy>资源，这些资源指定了MSS将其用来检测限定由MSS进行的自动脚本化的重复请求序列的规则。

在步骤1b(可选)处，IN-CSE的MSS支持经由AE的scriptedRequestEnableattribute的配置允许AE选择加入/退出请求序列的自动脚本化的能力。如果AE选择加入，那么IN-CSE的MSS可以监视从AE以及其它AE(假设这些其它AE也选择加入)接收到的请求，以确定IN-CSE的MSS是否存在执行重复请求序列的自动脚本化的机会。如果AE选择退出，那么IN-CSE的MSS可以不监视从AE接收的请求。

在步骤2-8处，一个或多个请求者开始发布重复的请求序列。

在步骤9处，IN-CSE的MSS检测重复的请求序列。如步骤1a中所述，检测可以基于IN-CSE的<scriptedRequestPolicy>资源内配置的规则。基于对重复的请求序列的检测，MSS为序列中的每个请求创建<scriptedRequest>资源。

在步骤10(可选)处，IN-CSE的MSS可以向(一个或多个)AE发送通知请求以通知他们MSS代表他们创建了一个或多个<scriptedRequest>资源。可以在(一个或多个)AE经由设置其scriptedRequestNotification属性而选择加入时(例如，在登记、注册等期间)配置(一个或多个)AE的通知目标地址。在通知内，MSS可以包括<scriptedRequest>信息，诸如一个或多个<scriptedRequest>资源的表示或标识符。AE可以使用这个信息来确定哪个(哪些)请求适用于(一个或多个)<scriptedRequest>资源，以及是否希望MSS代表其对请求进行脚本化。

在步骤11(可选)处，为了选择加入并批准IN-CSE的MSS代表其生成(一个或多个)脚本化的请求，AE可以将通知响应返回给MSS。在响应中，AE可以包括批准信息以及对MSS在(一个或多个)<scriptedRequest>资源中配置的设置的一些更新。例如，配置响应准则、配置请求到期定时器等。

在步骤12处，IN-CSE的MSS监视<scriptedRequest>资源内指定的准则，以确定是否/何时满足其生成脚本化的请求序列的适当条件。在这个示例中，准则是基于时间表的(例如，在下午1点，MSS检测到已满足触发序列中的第一脚本化的请求的生成的适当准则)。应注意的是，虽然在这个示例中未示出，但是还可以基于由CSE托管的其它资源的状态来指定其它准则(诸如条件)。

在步骤13处，IN-CSE的MSS使用序列中第一<scriptedRequest>资源中指定的信息来生成针对ASN/MN-CSE 1的脚本化的请求。

在步骤14处，请求由ASN/MN-CSE 1接收并处理。ASN/MN-CSE 1向IN-CSE的MSS返回响应。

在步骤15(可选)处，当从ASN/MN-CSE 1接收到针对脚本化的请求的响应时，IN-CSE的MSS可以检查在用于生成第一脚本化的请求的对应<scriptedRequest>资源中指定的响应准则，以确定如何处理响应。

在步骤16处，IN-CSE的MSS检查ASN/MN-CSE 1的<scriptedRequest>资源，以查看其是否与其它<scriptedRequest>资源具有任何脚本化的请求序列关系。MSS通过检查以查看是否在ASN/MN-CSE 1的<scriptedRequest>资源内配置了指向另一个<scriptedRequest>资源的链接来完成这个操作。在这种情况下，它找到了与ASN/MN-CSE 2的<scriptedRequest>资源的脚本化的请求序列关系。基于此，IN-CSE的MSS触发针对ASN/MN-CSE 2的脚本化的请求的生成。

在步骤17处，请求由ASN/MN-CSE 2接收并处理。ASN/MN-CSE 2向IN-CSE的MSS返回响应。

步骤18(可选)可以与步骤10相同。

在步骤19处，IN-CSE的MSS检查ASN/MN-CSE 2的<scriptedRequest>资源，以查看其是否与其它<scriptedRequest>资源具有任何脚本化的请求序列关系。IN-CSE的MSS通过检查以查看是否在ASN/MN-CSE 2的<scriptedRequest>资源内配置了指向另一个<scriptedRequest>资源的链接来完成这个操作。在这种情况下，它找到了与ASN/MN-CSE 3的<scriptedRequest>资源的脚本化的请求序列关系。基于此，IN-CSE的MSS触发针对ASN/MN-CSE 3的脚本化的请求的生成。

在步骤20处，请求由ASN/MN-CSE 3接收并处理。ASN/MN-CSE 3向IN-CSE的MSS返回响应。

步骤21(可选)可以与步骤10相同。

步骤22(可选)可以与步骤9相同。

步骤23-31可以与步骤13-21相同。

oneM2M事务可以由可能需要以原子方式相对于彼此执行的oneM2M请求集合组成。例如，所有请求都必须成功执行，或者都不执行。如果请求中的一个或多个请求无法成功执行，那么CSE可能需要回滚成功执行的所有请求，以将这些请求所针对的任何资源的状态返回到执行请求之前的初始状态。因此，CSE确保以原子方式相对于彼此执行请求集合。为了管理请求集合的原子执行，oneM2M定义了<transactionMgmt>资源。<transactionMgmt>资源的示例在图11中示出。支持MSS能力的注册商CSE可以监视和检测注册用户AE或CSE是否执行由请求集合组成的重复事务，这些请求以原子方式经由(一个或多个)<transactionMgmt>资源执行。如果检测到，那么注册商CSE可以代表注册用户提议对重复事务进行脚本化。注册商CSE可以为构成事务的请求集合中的每个请求创建<scriptedRequest>资源。然后，注册商CSE可以创建<transactionMgmt>资源并用<scriptedRequest>资源集合来配置其requestPrimitives属性。使用<transactionMgmt>资源和<scriptedRequest>资源集合，注册商可以对构成事务的请求的重复和原子执行进行脚本化。

<scriptedTransaction(脚本化的事务)>资源可以包括与<scriptedRequest>资源的属性相似的属性。支持MSS能力的注册商CSE可以支持AE创建<scriptedTransaction>资源。支持MSS能力的CSE可以支持监视和检测注册用户AE或CSE是否执行由请求集合组成的重复事务。如果检测到，那么注册商CSE可以提议代表注册用户对重复的请求集合进行脚本化。注册商CSE可以创建<scriptedTransaction>资源，该<scriptedTransaction>资源包括构成事务的各个请求的集合。使用<scriptedTransaction>资源，注册商可以对构成事务的请求的重复和原子执行进行脚本化。

如果/当在目标资源上发生操作时，oneM2M<subscription>资源可以使AE能够订阅目标资源并接收通知。支持MSS能力的<subscription>托管CSE可以监视并检测注册用户AE或CSE每次接收到针对给定<subscription>的通知时是否执行重复请求。例如，在将通知发送给注册用户之后，注册商可以检测到注册用户对一个或多个目标执行操作。如果检测到，那么注册商CSE可以将(一个或多个)请求检测为脚本化的(一个或多个)候选。然后，注册商CSE可以创建<subscription>的(一个或多个)<scriptedRequest>子资源。注册商CSE可以将(一个或多个)<scriptedRequest>资源的scriptedRequestCriteria属性配置为与订阅的相同eventNotificationCriteria。然后，CSE可以通知提议的订户，以代表注册用户对(一个或多个)重复请求进行脚本化。注册商CSE可以在与订阅相关联的通知中背负脚本化提议。可替代地，注册商CSE可以生成包含脚本化提议的单独脚本化的请求通知。脚本化提议可以由(一个或多个)<scriptedRequest>资源的资源标识符或表示组成。当返回通知响应时或通过更新<scriptedRequest>资源，注册商可以接受提议。如果接受，那么注册商CSE可以在每次为订阅生成通知时生成(一个或多个)脚本化的请求。

<subscription>托管CSE也可以允许AE创建<subscription>资源的<scriptedRequest>子资源。如果/当已经满足<subscription>事件准则时，这可以允许AE将<subscription>托管CSE配置为代表其生成定制请求。这可以允许AE将请求生成和响应处理分流到<subscription>托管CSE。

图12示出了用于在服务层(例如，oneM2M CSE)进行脚本化的请求管理的示例用户界面。这个界面可以允许用户或应用经由CSE发起和执行以下示例任务：创建新的脚本化的请求、搜索现有的脚本化的请求、触发脚本化的请求、更新脚本化的请求、以及删除脚本化的请求。

执行图2-8和图10所示步骤的任何实体(诸如服务层、服务层设备、服务层应用、应用实体等)可以是逻辑实体，该逻辑实体可以以存储在被配置用于无线和/或网络通信的装置或诸如图13C或图13D所示的计算机系统的计算机系统的存储器中并在其处理器上执行的软件(即，计算机可执行指令)的形式来实现。即，图2-8和图10中所示的(一个或多个)方法可以以存储在装置(诸如图13C或图13D所示的装置或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实现，其中计算机可执行指令在由装置的处理器执行时执行图2-8和图10中所示的步骤。还应当理解的是，图2-8和图10中所示的任何发送和接收步骤可以在装置的处理器及其执行的计算机可执行指令(例如，软件)的控制下由装置/实体的通信电路系统来执行。

图13A是示例机器对机器(M2M)、物联网(IoT)或万维物联网(WoT)通信系统10的图，其中可以实现一个或多个公开的实施例。一般而言，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台可以是IoT/WoT的部件或装置以及IoT/WoT服务层等。图1-12中任何图中所示的实体中的任何实体都可以包括通信系统的网络装置，诸如图13A-13D中所示的网络装置。

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

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

如图13A中所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域(FieldDomain)。基础设施域是指端到端M2M部署的网络侧，并且现场域是指通常在M2M网关后面的区域网络。现场域和基础设施域都可以包括网络的各种不同网络装置(例如，服务器、网关、设备等)。例如，现场域可以包括M2M网关14和设备18。将认识到的是，根据期望，任何数量的M2M网关设备14和M2M设备18可以被包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M设备18中的每一个被配置为使用通信电路系统经由通信网络12或直接无线电链路来发送和接收信号。

M2M网关14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12之类的运营商网络或者通过直接无线电链路进行通信。例如，M2M设备18可以经由通信网络12或直接无线电链路收集数据并向M2M应用20或其它M2M设备18发送数据。M2M设备18还可以从M2M应用20或M2M设备18接收数据。另外，数据和信号可以经由M2M服务层22被发送到M2M应用20和从M2M应用20被接收，如下所述。M2M设备18和网关14可以经由各种网络进行通信，其中网络例如包括蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。示例M2M设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。

参考图13B，现场域中所示的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'可以由网络的一个或多个网络装置实现，该一个或多个网络装置可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。

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

M2M应用20和20'可以包括各种行业中的应用，诸如但不限于运输、健康和保健、联网家庭、能源管理、资产跟踪以及安全性和监控。如上面所提到的，在系统的设备、网关、服务器和其它网络装置之间运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现以及遗留系统集成之类的功能，并将这些功能作为服务提供给M2M应用20和20'。

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

另外，本文描述的方法和功能可以被实现为使用面向服务的体系架构(SOA)和/或面向资源的体系架构(ROA)来访问服务的M2M网络的一部分。

图13C是网络的装置的示例硬件/软件体系架构的框图，其中装置诸如图1-12中所示的实体之一，其可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置进行操作，诸如图13A和13B中所示的。如图13D中所示，网络装置30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。网络装置30还可以包括通信电路系统，诸如收发器34和发送/接收元件36。将认识到的是，网络装置30可以包括前述元件的任何子组合，同时保持与实施例一致。这种网络装置可以是实现用于分流本文所述的IoT应用消息生成和响应处理的方法(诸如关于图2-8和图10示出和描述的方法操作)的装置。

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

如图13C中所示，处理器32耦合到其通信电路系统(例如，收发器34和发送/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统，以便使网络装置30经由与其连接的网络与其它网络装置通信。特别地，处理器32可以控制通信电路系统，以便执行本文(例如，在图2-8和图10中)和权利要求中描述的发送和接收步骤。虽然图13C将处理器32和收发器34描绘为单独的部件，但是将认识到的是，处理器32和收发器34可以一起集成在电子包装或芯片中。

发送/接收元件36可以被配置为向其它网络装置发送信号或从其它网络装置接收信号，网络装置包括M2M服务器、网关、设备等。例如，在实施例中，发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝等。在实施例中，发送/接收元件36可以是被配置为例如发送和/或接收IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发送/接收元件36可以被配置为发送和接收RF信号和光信号两者。将认识到的是，发送/接收元件36可以被配置为发送和/或接收无线信号或有线信号的任何组合。

此外，虽然发送/接收元件36在图13C中被描绘为单个元件，但是网络装置30可以包括任何数量的发送/接收元件36。更具体而言，网络装置30可以采用MIMO技术。因此，在实施例中，网络装置30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

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

处理器32可以从任何类型的合适存储器(诸如不可移除存储器44和/或可移除存储器46)访问信息，并将数据存储在其中。例如，处理器32可以在其存储器中存储会话上下文，如上所述。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘，或任何其它类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可以从物理地位于网络装置30上(诸如在服务器或家用计算机上)的存储器访问信息，并将数据存储在该存储器中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色以反映装置的状态或配置装置，特别是底层网络、应用或与网络装置通信的其它服务。在一个实施例中，显示器/指示器42可以呈现图13D中所示并在本文描述的图形用户界面。

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

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

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

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

网络装置30可以在其它装置或设备中实施，其中装置或设备诸如传感器、消费电子产品、可穿戴设备(诸如智能手表或智能服装)、医疗或电子卫生设备、机器人、工业装备、无人机、交通工具(诸如小汽车、卡车、火车或飞机)。网络装置30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。

图13C是示例计算系统90的框图，该计算机系统90还可以用于实现网络的一个或多个网络装置，诸如图1-12中所示并在本文描述的实体，该实体可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置操作，诸如图13A和13B所示。

计算系统90可以包括计算机或服务器，并且可以主要由计算机可读指令控制，该计算机可读指令可以是软件的形式，无论在何处，或者通过任何方式存储或访问这样的软件。这种计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行，以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由被称为微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，该协处理器81执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。

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

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

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

由显示器控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示器控制器96包括生成发送到显示器86的视频信号所需的电子部件。结合由CPU 91执行的计算机可执行指令，显示器86可以生成并操作图9D及其随附描述中所示并描述的图形用户界面。

另外，计算系统90可以包含通信电路系统，诸如例如网络适配器97，该网络适配器97可以用于将计算系统90连接到外部通信网络，诸如图13A-13D的网络12，以使计算系统90能够与网络的其它装置通信。单独或与CPU 91组合，通信电路系统可以用于执行本文(例如，在图2-8和图10中)和权利要求中描述的发送和接收步骤。

应该理解的是，本文描述的任何或所有系统、方法和处理都可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式实施，所述指令在由机器(诸如M2M网络的装置，包括例如M2M服务器、网关、设备等)执行时执行和/或实现本文描述的系统、方法和处理。具体而言，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何非瞬态(即，有形的或物理的)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术，CD-ROM、数字通用盘(DVD)或其它光盘存储装置，磁带盒、磁带、磁盘存储装置或其它磁存储设备，或者可以用于存储期望信息并且可由计算机访问的任何其它有形或物理介质。

以下是与可能出现在以上描述中的服务层技术相关的首字母缩写词列表。除非另有说明，否则本文中使用的首字母缩写词是指下面列出的对应术语：

AE 应用实体

CSE 公共服务实体

CSF 公共服务功能

IoT 物联网

M2M 机器对机器

MSS 消息脚本化服务

REST 代表性状态转移

SL 服务层

URI 统一资源标识符

WoT 万维物联网

以下是可以在以上描述中出现的与服务层技术相关的术语和定义的列表。除非另有指定，否则本文使用的术语和定义是指下面列出的相应术语：

本书面描述使用示例来公开本发明(包括最佳模式)，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有与权利要求的字面语言没有差别的元素，或者如果它们包括与权利要求的字面语言无实质差别的等同元素，那么这些其它示例旨在处于权利要求的范围内。

Claims (20)

1.一种由服务层实体实现的方法，该方法包括：

从第一实体接收与第二实体通信的多个请求；

确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式；

基于确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式来创建脚本化的请求资源，其中脚本化的请求资源使服务层实体能够代表第一实体向第二实体发送脚本化的请求，并且其中脚本化的请求资源包括用于触发一个或多个脚本化的请求的生成的一个或多个条件；以及

基于确定已经满足用于触发所述一个或多个脚本化的请求的生成的条件中的一个或多个条件并且向第二实体发送脚本化的请求。

2.如权利要求1所述的方法，其中脚本化的请求被服务层实体用来代表第一实体将信息自动传送给第二实体。

3.如权利要求1所述的方法，其中服务层实体被配置有一个或多个策略，所述一个或多个策略使服务层实体能够确定与第二实体通信的所述多个请求是否形成重复请求模式。

4.如权利要求1所述的方法，还包括：基于在服务层实体处确定与第二实体通信的请求中的两个或更多个请求形成重复请求模式，从第一实体接收自动创建脚本化的请求资源的指令。

5.如权利要求1所述的方法，还包括向第一实体发送脚本化的请求资源已经被创建的指示以及与脚本化的请求资源相关联的标识符。

6.如权利要求1所述的方法，还包括：

从第一实体接收对更新脚本化的请求资源的条件的请求；以及

基于对更新脚本化的请求资源的条件的请求，更新脚本化的请求资源的条件。

7.如权利要求1所述的方法，还包括：

从第二实体接收对脚本化的请求的响应；

在服务层实体处并基于脚本化的请求资源中识别出的一个或多个响应参数来处理响应；以及

向第一实体发送经处理的响应。

8.一种装置，包括处理器和存储器，所述存储器存储计算机可执行指令，所述计算机可执行指令在由所述处理器执行时实现通信网络的服务层实体并且使服务层实体执行包括以下的操作：

从第一实体接收与第二实体通信的多个请求；

确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式；

基于确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式来创建脚本化的请求资源，其中脚本化的请求资源使服务层实体能够代表第一实体向第二实体发送脚本化的请求，并且其中脚本化的请求资源包括用于触发一个或多个脚本化的请求的生成的一个或多个条件；以及

基于确定已经满足用于触发所述一个或多个脚本化的请求的生成的条件中的一个或多个条件并且向第二实体发送脚本化的请求。

9.如权利要求8所述的装置，其中脚本化的请求被服务层实体用来代表第一实体将信息自动传送给第二实体。

10.如权利要求8所述的装置，其中服务层实体被配置有一个或多个策略，所述一个或多个策略使服务层实体能够确定与第二实体通信的所述多个请求是否形成重复请求模式。

11.如权利要求8所述的装置，其中指令在被执行时还使服务层实体执行包括以下的操作：基于在服务层实体处确定与第二实体通信的请求中的两个或更多个请求形成重复请求模式，从第一实体接收自动创建脚本化的请求资源的指令。

12.如权利要求8所述的装置，其中指令在被执行时还使服务层实体执行包括以下的操作：向第一实体发送脚本化的请求资源已经被创建的指示以及与脚本化的请求资源相关联的标识符。

13.如权利要求8所述的装置，其中指令在被执行时还使服务层实体执行包括以下的操作：

从第一实体接收对更新脚本化的请求资源的条件的请求；以及

基于对更新脚本化的请求资源的条件的请求，更新脚本化的请求资源的条件。

14.如权利要求8所述的装置，其中指令在被执行时还使服务层实体执行包括以下的操作：

从第二实体接收对脚本化的请求的响应；

在服务层实体处并基于脚本化的请求资源中识别出的一个或多个响应参数来处理响应；以及

向第一实体发送经处理的响应。

15.一种存储计算机可执行指令的计算机可读存储介质，所述计算机可执行指令在由服务层实体的处理器执行时使服务层实体执行包括以下的操作：

从第一实体接收与第二实体通信的多个请求；

确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式；

基于确定与第二实体通信的所述多个请求中的两个或更多个请求形成重复请求模式来创建脚本化的请求资源，其中脚本化的请求资源使服务层实体能够代表第一实体向第二实体发送脚本化的请求，并且其中脚本化的请求资源包括用于触发一个或多个脚本化的请求的生成的一个或多个条件；以及

基于确定已经满足用于触发所述一个或多个脚本化的请求的生成的条件中的一个或多个条件并且向第二实体发送脚本化的请求。

16.如权利要求15所述的计算机可读存储介质，其中脚本化的请求被服务层实体用来代表第一实体将信息自动传送给第二实体。

17.如权利要求15所述的计算机可读存储介质，其中服务层实体被配置有一个或多个策略，所述一个或多个策略使服务层实体能够确定与第二实体通信的所述多个请求是否形成重复请求模式。

18.如权利要求15所述的计算机可读存储介质，其中指令在被执行时还使服务层实体执行包括以下的操作：基于在服务层实体处确定与第二实体通信的请求中的两个或更多个请求形成重复请求模式，从第一实体接收自动创建脚本化的请求资源的指令。

19.如权利要求15所述的计算机可读存储介质，其中指令在被执行时还使服务层实体执行包括以下的操作：向第一实体发送脚本化的请求资源已经被创建的指示以及与脚本化的请求资源相关联的标识符。

20.如权利要求15所述的计算机可读存储介质，其中指令在被执行时还使服务层实体执行包括以下的操作：

从第一实体接收对更新脚本化的请求资源的条件的请求；以及

基于对更新脚本化的请求资源的条件的请求，更新脚本化的请求资源的条件。

Images