CN116506502A - 通信网络中的服务层消息模板 - Google Patents

Abstract

本公开涉及通信网络中的服务层消息模板。实施例介绍了服务层消息模板的概念，该模板可以是请求模板或响应模板。消息模板可以被创建并存储在服务层处。每个消息模板可以包含请求或响应参数及其值的集合。一旦放置到位，应用就能够将不包括包含在消息模板(即，请求模板)中的请求参数的请求发送到服务层；代替地，可以发送消息模板标识符。由于请求参数包括在消息模板中并存储在服务层处，因此可以减少服务层与应用(或另一服务层)之间的通信开销。

Description

通信网络中的服务层消息模板

本申请是申请日为2018年9月14日、申请号为201880059461.2、发明名称为“通信网络中的服务层消息模板”的发明专利申请的分案申请。

相关申请的交叉引用

本申请要求于2017年9月15日提交的美国临时专利申请No.62/558,940的权益，该申请通过引用整体并入本文。

背景技术

许多标准机构，诸如例如oneM2M、欧洲电信标准协会(ETSI)和开放连接基金会(OCF)，正在开发M2M/IoT服务层，该服务层定义了用于在应用之间，甚至在来自不同行业的应用之间交换和共享数据的单一水平平台。

M2M/IoT服务层可以向应用和设备提供对服务层所支持的面向M2M/IoT的能力(M2M/IoT服务)集合的访问。此类能力可以经由应用编程接口(API)对应用可用。例如，M2M/IoT服务层可以维护大量的M2M/IoT数据，这些数据可以被应用发现、检索和/或订阅(只要那些应用具有适当的访问权限)。服务层可以提供的M2M/IoT服务的其它示例包括安全性、收费、设备管理、供给和连接性管理。

oneM2M标准以“公共服务实体(CSE)”的形式实现其服务层。oneM2M服务层的目的是提供可以被不同的“垂直”M2M系统和应用利用的“水平”服务。oneM2M CSE支持四个参考点。Mca参考点与应用实体(AE)接口。Mcc参考点与同一服务提供商域内的另一个CSE接口，并且Mcc参考点与不同服务提供商域中的另一个CSE接口。Mcn参考点与基础网络服务实体(NSE)接口。NSE向CSE提供基础网络服务，诸如设备管理、位置服务和设备触发。CSE可以包含称为“公共服务功能(CSF)”的多个逻辑功能，诸如“发现”和“数据管理和存储库”。

在oneM2M中，其Mca、Mcc和Mcc的参考点已采用了请求/响应模型。例如，AE可以向CSE发送请求消息以访问其资源或服务。oneM2M提供了若干高级特征，用于根据各种参数来处理请求消息并生成对应的响应消息。此外，每个响应消息可以包含各种响应参数。这些参数可以在多个请求和响应消息中重复，可能导致大尺寸的请求/响应消息。

发明内容

如背景技术中所描述的，服务层请求消息可以包含请求参数的集合，这增加了请求消息的尺寸并降低了服务层与应用(或另一服务层)之间的通信效率。类似地，服务层响应消息可以包含多个响应参数，这些参数进而扩大了响应消息。此外，来自相同或不同应用的请求消息可以包含具有相同值的相同请求参数，这是冗余的。而且，从服务层到请求者的响应消息也可以包含冗余的响应参数。特别地，在IoT服务层中，由于太多的请求参数，请求消息会变大，并且不可避免地引入高开销，并且在底层网络的通信容量有限时(诸如3GPP窄带IoT和其它低功耗广域网技术)管理起来变得笨重。

本文描述的是在通信开销和其它相关度量方面，尤其是对于带宽有限的底层网络(诸如低功率广域网)，提高由大请求和响应消息造成的服务层与应用(或另一服务层)之间的通信效率的方法和装置。

根据一个方面，可以采用服务层消息模板，其可以包括请求模板或响应模板。消息模板可以被创建并存储在服务层处。每个消息模板可以包含请求或响应参数及其值的集合。一旦放置到位，应用就可以将不包括包含在消息模板(即，请求模板)中的请求参数的请求发送到服务层；代替地，可以发送消息模板标识符。由于请求参数包括在消息模板中并存储在服务层处，因此可以减少服务层与应用(或另一服务层)之间的通信开销。

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

附图说明

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

图1是图示由oneM2M指定的网络体系架构的图；

图2图示了智能计量用例，其中每个智能计量器作为用户装备(UE)使用低功率广域接入技术，诸如3GPP窄带物联网(NB-IoT)与服务器通信；

图3图示了应用与服务层之间的交互；

图4示出了其中多个应用(例如，图2中的智能计量器上的智能计量器应用)与同一服务层交互的示例；

图5图示了用于在减小其尺寸方面充分利用请求模板来优化服务层请求消息的方法的一种实施方式；

图6图示了用于在减小其尺寸方面充分利用响应模板来优化服务层响应消息的方法的一种实施方式；

图7图示了用于消息模板管理的总体方法；

图8图示了由请求者使用独立请求发起的用于请求模板创建的方法；

图9是图示与图8的方法相关的示例的图；

图10图示了当发送常规请求时由请求者发起的用于请求模板创建的方法；

图11图示了用于创建由服务层发起的请求模板的方法并且使用分开的通知消息将创建的请求模板的标识符发送回请求者；

图12示出了其中服务层接收三个连续的常规请求的示例，这些请求使用一些相似的请求参数；

图13图示了用于创建由服务层发起的请求模板的方法并且在常规响应中将创建的请求模板的标识符背负(piggyback)给请求者；

图14图示了由服务层发起的用于主动请求模板创建的方法；

图15图示了用于响应模板创建的过程；

图16图示了用于消息模板指派和发现的方法，其中示出了三种可能的情况；

图17图示了用于在服务层注册过程期间创建/指派消息模板的简化且更轻量的方法；

图18图示了用于检索消息模板的方法；

图19图示了用于充分利用请求模板的方法；

图20图示了用于充分利用请求和响应模板的方法；

图21图示了用于使用专用消息来更新消息模板的方法；

图22图示了当请求者向服务层发送请求消息时用于并发地更新消息模板的方法；

图23图示了用于使用专用消息来删除消息模板的方法；

图24图示了当请求者向服务层发送请求消息时并发地删除消息模板的方法；

图25图示了用于在一个请求消息中充分利用多个请求模板的方法；

图26图示了当转接服务层不支持与模板相关的功能时使用请求模板用于多跳服务层通信的方法；

图27图示了当目的地服务层不支持与模板相关的功能时用于在多跳服务层通信中使用请求模板的方法；

图28图示了当转接服务层和目的地服务层均支持模板相关功能时用于在多跳服务层通信中使用请求模板的方法；

图29图示了当请求者不支持与模板相关的功能时用于在多跳服务层通信中使用请求模板的方法；

图30图示了用于创建消息模板策略的方法；

图31图示了用于将消息模板与消息模板策略相关联或反过来的方法；

图32图示了用于检索/更新/删除现有的消息模板策略的方法；

图33图示了messageTemplate资源的结构的一个示例；

图34图示了操作<messageTemplate>资源(例如创建/检索/更新/删除<messageTemplate>资源)的方法；

图35图示了messageTemplatePolicy资源的结构；

图36图示了操作<messageTemplatePolicy>资源(例如创建/检索/更新/删除<messageTemplatePolicy>资源)的方法；

图37图示了用于在服务层(例如oneM2M CSE)处进行消息模板管理的用户界面的一个实施例；

图38图示了用于在服务层(例如oneM2M CSE)处进行消息模板策略管理的用户界面；

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

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

图39C是可以在图39A和39B所示的通信系统内使用的诸如M2M/IoT/WoT设备、网关或服务器之类的示例通信网络装置的系统图；以及

图39D是其中可以实施图39A和图39B的通信系统的节点或装置的示例计算系统的框图。

具体实施方式

oneM2M标准以“公共服务实体(CSE)”的形式实现服务层。oneM2M服务层的目的是提供可以被不同的“垂直”M2M系统和应用利用的“水平”服务。CSE支持四个参考点，如图1中所示。Mca参考点与应用实体(AE)接口。Mcc参考点与同一服务提供商域中的另一个CSE接口，而Mcc参考点与不同服务提供商域中的另一个CSE接口。Mcn参考点与底层网络服务实体(NSE)连接。NSE向CSE提供底层网络服务，诸如设备管理、位置服务和设备触发。CSE包含多个称为“公共服务功能(CSF)”的逻辑功能，诸如“发现”和“数据管理和存储库”。

oneM2M体系架构启用以下类型的节点，如图1中所示：应用服务节点、应用专用节点、中间节点、基础设施节点和非oneM2M节点。

应用服务节点(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中，其Mca、Mcc和Mcc的参考点已采用了请求/响应模型。例如，AE可以向CSE发送请求消息以访问其资源或服务。oneM2M提供了若干高级功能，用于处理请求消息并经由一些新参数生成对应的响应消息，如表1中所述。此外，每个响应消息包含一些响应参数，如表2中所列出的。注意的是，这些参数可以在多个请求和响应消息中重复，并且可以导致大尺寸的oneM2M请求或响应消息。

表1：oneM2M中的请求参数的摘要(改编自oneM2M-TS-0001oneM2M功能体系架构-V3.7.0)

表2：oneM2M中的响应参数的摘要(改编自oneM2M-TS-0001oneM2M功能体系架构-V3.7.0)

为了更好地理解本文描述的技术方案所针对的技术问题，提出了一种用例以进行说明。图2图示了智能计量用例，其中每个智能计量器作为用户装备(UE)使用低功率广域接入技术(诸如3GPP窄带物联网(NB-IoT))与IoT服务层所在的服务器通信，用于存储和管理来自各种UE的计量器数据；服务器可以由电力公司部署。例如，可以在每个UE上运行智能计量器应用，以周期性地将计量器读数发送到服务器。此外，多个智能计量器(例如，部署在同一社区中)可以以相同的方式(例如，报告频率、服务器应如何处理请求消息等)向服务器报告其读数。照此，每个智能计量器可以重复地向服务器发送类似的请求消息，并且多个计量器也可以在不同时间向服务器发送类似的请求消息。结合图3和4进一步对这两个方面进行抽象和讨论。

图3图示了应用和服务层之间的交互。在这个示例中，应用(例如，图2中的智能计量器上的智能计量器应用出现错误！找不到参考源。)重复地向服务层发送请求消息。每个请求消息包含请求参数的集合；同样，对应的响应消息包含响应参数。此外，应用可以在某个持续时间期间从服务层请求相同的服务/资源；因此，每个重复的请求消息都包括相同的请求参数集。

图4示出了另一个示例，其中多个应用(例如图2中智能计量器上的智能计量器应用)与同一服务层进行交互。在这种场景中，虽然三个(或更多个)应用可以访问不同的服务/资源，但它们可以指示服务层以相同的方式处理其请求消息。例如，它们可以向服务层指示：相同的请求消息到期时间、相同的结果到期时间等。因此，来自每个应用的请求消息可以包含相同的请求参数集。

在对上述用例所说明的问题进行技术解决之前，仅仅是为了便于描述而在本文定义某些术语。以下术语可以具有以下含义：

服务层可以被描述为应用和应用协议层之间的协议层。服务层存储资源并提供服务，这些资源和服务暴露给应用和其它服务层，并可以由应用和其它服务层访问和操纵。

请求/响应模型可以是服务层和应用之间(或两个服务层之间)的交互模型。在这个模型中，应用(或另一服务层)将请求消息发送到服务层，服务层进而将响应消息发送回应用(或另一服务层)。

请求消息可以是从应用(或另一服务层)发送到服务层以请求由服务层提供的服务的消息。服务层处理收到的请求消息，并将响应消息发送到请求消息的始发者。请求消息也可以从服务层发布到另一个应用。

请求参数可以是请求消息中包括的参数，该参数指示服务层何时/如何处理请求消息、如何维护生成的结果、何时/如何发送回响应消息等。

响应消息可以是由于接收和处理请求消息而从服务层发送到应用(或另一服务层)的消息。响应消息也可以从应用发布到服务层。

响应参数可以是响应消息中包括的参数。例如，当请求者请求从服务层检索资源时，由服务层生成的响应消息可以包括“content”参数以包括检索出的资源的表示。

消息模板(MT)可以是用于描述请求消息的请求模板或用于描述响应消息的响应模板。请求模板存储在服务层和/或请求者侧的存储器中，并且可以由应用发现和检索；响应模板也可以存储在服务层和/或请求者侧。消息模板可以由服务层、应用和/或其它服务层管理。MT可以采用保持模板的参数值的任何核实数据结构的形式，诸如表、可扩展标记语言(XML)文档或任何其它适当的机器可读数据结构或文档。

请求模板(REQT)包含一些常见的请求参数及其在请求中重复使用的给定消息的值。应用或另一服务层可以充分利用请求消息模板来生成优化的请求，其中一旦将常见的请求参数的子集包括在模板中，就可以将其省略。

响应模板(RSPT)描述应当如何生成响应消息以及响应消息的外观。响应模板可以与请求模板或请求相关联；照此，当服务层使用请求模板来处理接收到的优化的请求时，它知道应当使用哪个响应模板来生成响应消息。此外，服务层可以在请求者侧创建响应模板以包含将从服务层重复地发送到请求者的响应参数；服务层可以通过省略那些重复的响应参数来使用这种响应模板来生成优化的响应；请求者将这种响应模板存储在本地并且可以使用它从接收到的优化的响应中恢复原始响应消息。注意的是，响应模板可以被用于回复包括或不包括请求模板的请求。

消息模板标识符(MTID)可以是存储在服务层的消息模板(该模板可以是请求模板或响应模板)的通用资源标识符或数字标识符。

请求模板标识符(RQTID)可以是存储在服务层的请求模板的通用资源标识符或数字标识符。

响应模板标识符(RSTID)可以是存储在服务层的响应模板的通用资源标识符或数字标识符。

消息模板管理可以包括以下任务：创建消息模板、检索消息模板、充分利用消息模板、更新消息模板、删除消息模板、将消息模板与一个或多个消息模板策略相关联等。

消息模板策略可以包括用于描述或限制消息模板的适用性的条件(例如，是否/何时将哪个消息模板应用于哪个请求者用于哪个目标资源)。

常规请求可以是在服务层或应用层中原生定义和支持的请求消息。常规请求用于包含服务层指定的请求参数的集合。常规请求不充分利用任何请求模板。

优化的请求可以是通过充分利用请求模板来增强的请求消息。一般而言，通过包含请求模板标识符并移除那些包括在请求模板中的请求参数，在请求者侧制定优化的请求。因此，优化的请求比常规请求短。

常规响应可以是在服务层或应用层中原生定义和支持的响应消息。常规响应被用于包含服务层指定的响应参数的集合。常规响应不充分利用存储在请求者侧的任何响应模板。

优化的响应可以是通过充分利用响应模板来增强的响应消息。一般而言，通过包含响应模板标识符并移除那些包括在响应模板中的响应参数，在服务层侧制定优化的响应。因此，优化的响应比常规响应短。

对于本描述的其余部分，除非明确说明，否则消息模板可以指或者请求模板或者响应模板。同样，除非明确说明，否则消息模板标识符(MTID)可以指或者请求模板标识符(RQTID)或者响应模板标识符(RSTID)。

在下面的描述中，描述用于充分利用消息模板的机制。然后，将描述用于消息模板管理的总体过程，然后描述可以执行的每个消息模板管理任务的实施例，诸如消息模板创建、消息模板指派和发现、消息模板检索、消息模板使用、消息模板更新、消息模板删除。

仅仅为了便于描述，在以下描述中，请求消息被描述为从应用(或另一服务层)发布到服务层。但是本文描述的概念、机制和实施例可以直接应用于服务层向应用发送请求消息并且相应地将响应消息从应用发送到服务层的场景。

图5图示了用于在减小请求模板的尺寸方面充分利用请求模板来优化服务层请求消息的方法的一种实施方式。注意的是，图5中的请求者可以是应用或另一服务层；此外，每个步骤可以涉及若干子步骤，下面的描述将对此进行详细描述。注意的是，请求模板中包含的请求参数可以没有特定次序。

参考图5，在步骤1中，请求者请求创建请求模板(REQT)。可替代地，服务层可以主动创建一些REQT。该请求可以包括用于通常将出现在请求中的信息元素的默认值。可以基于这些默认值来构建REQT。当请求者以后使用REQT时，如果在指示将使用REQT的请求中未提供不同的值，那么服务层可以采用默认值。

在步骤2中，服务层创建REQT、REQT标识符，并将其本地存储在实现服务层的网络装置的存储器中。

在步骤3中，为了让不是REQT创建者的请求者能够充分利用所创建的REQT，请求者需要知道其内容(例如，哪些请求参数已包括在REQT中)，以便优化要发送到服务层的未来请求消息。照此，请求者需要发现和检索REQT及其相关联的标识符。可替代地，并且在图中未示出，服务层可以主动地将一个或多个REQT指派给请求者。

在步骤4中，在检索REQT或者为REQT指派或通知REQT之后，请求者使用它来生成优化的请求，该请求将包括REQT的标识符并排除REQT中已经包含的那些参数。对于REQT中未包括的任何请求参数，请求者仍然需要将它们包括在优化的请求中。由于优化的请求包含的参数少于常规请求，因此其尺寸得以减小，并且与服务层的通信开销也将减少。

在步骤5中，请求者将优化的请求发送到服务层。注意的是，优化的请求包含REQT的标识符，该标识符已用于在步骤4中生成优化的请求。该请求还可以提供作为REQT的一部分的信息元素的值。值的存在可以被请求者用来指示关于REQT的默认值应当被提供的值覆盖。

在步骤6中，服务层接收优化的请求并根据REQT对其进行处理。具体而言，服务层首先使用优化的请求中包含的REQT标识符来定位适当的REQT；然后，它使用请求参数和REQT中包含的其它信息连同优化的请求中的其它参数/信息来以假定用来处理常规请求的方式处理接收到的优化的请求。然后，如果服务层不支持响应模板，那么服务层生成常规响应并将其发送回请求者；如果支持响应模板，那么服务层可以充分利用响应模板来生成优化的响应(参见图5)。

注意的是，虽然图5中所示的整个过程导致在服务层和请求者之间创建/发现/检索请求模板的更多消息传递(与没有消息模板的单个请求/响应相比)，但如果请求者将重复地向服务层发送相同类型的请求和/或消息模板将被多个请求者使用，那么可以节省很多。这是因为所有后续请求(或来自多个请求者的请求)都可以利用REQT。

图6图示了用于在减小响应模板的尺寸方面充分利用响应模板来优化服务层响应消息的方法的一种实施方式。注意的是，图6中的请求者可以是应用或另一服务层；此外，图6中的每个步骤可以涉及若干子步骤。注意的是，响应模板中包含的响应参数可以没有任何特定次序。

参考图6，在步骤1中，请求者请求创建响应模板(RSPT)。可替代地，服务层也可以发起创建一些RSPT。来自请求者的请求可以提供响应参数、RSPT标识符或应当被用于构建RSPT的完整响应。例如，请求者可以指示在构建RSPT时应当采用哪些响应参数。

在步骤2中，服务层创建RSPT、RSPT标识符，并将其本地存储在实现服务层的网络装置的存储器中。

在步骤3中，服务层在请求者处发送相同的RSPT和标识符，以便请求者可以使用它来正确地处理将来要接收的任何优化的响应。

在步骤4中，请求者在本地存储RSPT。

在步骤5中，服务层在处理接收到的请求时根据请求者已经知道的RSPT生成优化的响应。优化的响应可以包括所使用的RSPT的标识符。与常规响应相比，优化的响应不包括那些已经包括在RSPT中的参数/信息并且消息尺寸将减小。注意的是，请求者发出的接收到的请求可以在将请求发送到服务层时明确地请求服务层创建和/或使用特定的RSPT；可以通过在请求消息中包括RSPT标识符或“USE RSPT”标志来指示使用RSPT的请求。

在步骤6中，服务层将优化的响应发送到请求者。优化的响应包括RSPT标识符。优化的响应省略了RSPT中包括的那些响应参数，但包含RSPT标识符。为了覆盖在RSPT中定义的值，响应可以包括在RSPT中指派了默认值的一些参数的值。

在步骤7中，请求者接收优化的响应、使用RSPT标识符定位对应的RSPT，并使用响应参数和RSPT中包含的信息来处理优化的响应。

现在将描述用于消息模板管理的方法。根据一个方面，请求者(即，应用或另一服务层)可以在服务层处发起消息模板的创建。一旦创建了消息模板，就可以将其指派给同一个或其他请求者或由其发现。在请求者发现或被指派了适当的消息模板之后，可以使用它来生成优化的请求(或响应)，其中一些请求(或响应)参数将被省略并由消息模板标识符代替。然后，可以以RESTful方式操作消息模板(即，检索消息模板、更新消息模板和删除消息模板)。

图7图示了用于消息模板管理的整体方法，该方法基于关于图5和图6描述的内容并与其一致。图7中所示的概念之一是，可以将由请求者或服务层创建的消息模板指派给其他请求者、由其他请求者发现和/或使用。

参考图7，在步骤1中，创建消息模板并将其存储在服务层；这可以由请求者1或服务层本身发起。可以如图5和图6中所述的那样创建消息模板。

在步骤2中，将创建的消息模板指派给请求者2(或还有请求者1)和/或由其发现。注意的是，服务层可以将由请求者1创建的消息模板指派给请求者2(反之亦然，虽然未在图中示出)。注意的是，在发现或被指派消息模板之后，请求者2(或请求者1)可以订阅消息模板，以便在消息模板被更新(在步骤5中)或被删除(在步骤6中)时接收自动通知。在此，对于指派了消息模板的请求者，意味着：1)将消息模板及其标识符给予请求者；2)如果模板是请求模板，那么请求者被授权和/或被约束使用指派的消息模板来生成优化的请求，或者如果它是响应模板，那么从优化的响应中生成常规响应。

在步骤3中，请求者2(或请求者1)从服务层检索消息模板。

在步骤4中，请求者2(或请求者1)使用消息模板(即，请求模板)来生成优化的请求并与服务层进行交互。注意的是，可以共同充分利用多个模板来生成优化的请求。当服务层接收到优化的请求时，它将定位对应的模板并使用它来处理优化的请求。在这个处理中，当请求者2(或请求者1)向服务层发送请求消息时，它可以指示并指导服务层创建响应模板和/或使用响应模板来生成对请求者2(或请求者1)的优化响应。

在步骤5中，消息模板可以由请求者2(或请求者1)或服务层本身更新。例如，可以更新消息模板中包含的参数或信息。如果更新后的消息模板已被多个请求者使用和/或订阅，那么服务层将向这些请求者发送通知，并将更新通知给他们。

在步骤6中，可以由请求者2(或请求者1)或服务层本身删除消息模板。如果删除的消息模板已被多个请求者使用或订阅，那么服务层将向这些请求者发送通知，并通知他们消息模板已被移除。

一方面，请求者可以通过向服务层发送请求消息来主动发起请求模板的创建。在这个步骤之前，请求者可以已经发现服务层支持消息模板功能，例如经由服务发现；为了启用这一点，服务层需要暴露/宣布其消息模板功能，以便请求者可以发现它们。请求者有两种情况将请求模板创建请求发送到服务层。在情况1中，请求者将专用请求模板创建请求发送到服务层；这个请求将包含一些请求参数，包括所需的它们的值。在情况2中，请求者在常规请求中背负请求模板创建指示符(RQTCI)；RQTCI通知服务层如何创建请求模板(例如，哪些请求参数及其值应当包括在要创建的消息模板中)。服务层根据RQTCI指定的内容来创建请求模板。

图8图示了由请求者使用独立请求发起的用于请求模板创建的方法。在步骤1中，请求者将请求模板创建请求发送到服务层，以指示服务层创建请求模板。该消息可以包含以下参数。

·templateType：指示要创建的消息模板的类型为请求模板。

·numOfRequestTemplatesToBeCreated(Nt)：指示要创建的请求模板的数量。请求者可以请求创建多个请求模板；在这种情况下，要包括在每个模板中的请求参数包含在listOfRequestParameters中。

·listOfRequestParameters：指示请求参数的列表，包括它们的值，这些参数将包括在要创建的请求模板中。通常，这些参数及其值将在将来的请求中被重复使用。照此，通过创建包括它们的请求模板，可以在将来的请求中将它们省略，进而减小将来的请求的尺寸。如果numOfRequestTemplateToBeCreated多于一个(即，Nt>1)，那么listOfRequestParameters应当将所有包括的参数划分为Nt个子组，并且每个子组中的参数将被用于创建分开的请求模板。如图9中所示，假设请求消息中最初有Np个请求参数(例如，Np＝15)，并且Nt＝3。在这个示例中，listOfRequestParameters将包含三个参数子组。第一子组包括两个请求参数并且将被用于创建第一请求模板REQT1，第二子组包括接下来的三个请求参数并且将被用于创建第二请求模板REQT2，并且第三子组包括最后两个参数并且将被用于创建第三请求模板REQT3。注意的是，一些请求参数将不包括在请求模板中或在请求模板中使用，如图8中所示。以oneM2M为例，表1中所示的一些请求参数可以包含在请求模板中：Operation、Request Expiration Timestamp、Result Expiration Timestamp、Operational Execution Time、Response Type、Result Persistence、Result Content、Event Category、Delivery Aggregation、Group Request Identifier、Filter Criteria、Discovery Result Type、Security Info等。

·listOfExistingRequestTemplateIDs：指示已创建并存储在服务层处的现有请求模板标识符的列表。这个参数被用于基于现有请求模板创建新的请求模板，因此请求者不需要指示请求参数，而仅需要指示现有请求模板的标识符。如果这个参数包含在步骤1中，那么要创建的请求模板将基于这些现有请求模板以及listOfRequestParameters中指示的任何参数。换句话说，对于Nt＝1的情况，要创建的请求模板将包括那些现有请求模板和listOfRequestParameters中包含的所有请求参数。仍以图9为例，如果listOfExistingRequestTemplateIDs包含三个请求模板REQT1、REQT2和REQT3(如图9中所示)，那么服务层将创建新的请求模板REQT123，该请求模板只能包含这三个现有请求模板的标识符，并且本质上包含来自REQT1、REQT2和REQT3的所有请求参数。通过创建这样的新请求模板，服务层为请求者提供更大的灵活性和更高的效率以充分利用或重用现有请求模板。例如，稍后的请求者可以简单地使用请求模板REQT123生成优化的请求并且只需要告知服务层REQT123的标识符即可；否则，如果不使用这样的新模板，那么请求者需要一起使用REQT1、REQT2和REQT3来生成相同的优化的请求，并且需要将三个标识符(分别用于REQT1、REQT2和REQT3)通知给服务层。如果numOfRequestTemplatesToBeCreated大于一(即，Nt>1)，那么类似于listOfRequestParameters如何将请求参数划分为若干子组，listOfExistingRequestTemplateIDs应当将所有包括的模板标识符划分为Nt个子组，并且每个子组中的模板标识符将被用于创建分开的请求模板。

·listOfAllowedRequestors：指示可以充分利用将在步骤2中创建的请求模板的请求者的列表。这个参数是可选的。

·listOfTargetResources：指示可以应用于在步骤2中创建的请求模板的目标资源的列表。这个参数是可选的。

·MTPList：指示将应用于正在创建的请求模板的现有的消息模板策略的列表。这个参数是可选的。如果包括这个参数，那么可能不需要listOfAllowedRequestors和listOfTargetResources。

仍然参考图8，在步骤2中，服务层从步骤1接收请求模板创建请求，并对其进行处理以生成请求者所需的对应请求模板。服务层可以检查先前是否已经创建了相同的模板；如果是，它可以不创建新模板。创建的请求模板可以具有一些请求参数和其它特性(例如，创建、到期时间、允许的请求者列表、目标资源的列表、作为子级的其它请求模板的列表等)。注意的是，在一个实施例中，如果numOfRequestTemplatesToBeCreated等于1(即，Nt＝1)，那么服务层仅使用listOfRequestParameters中包含的所有请求参数以及listOfExistingRequestTemplateIDs中指示的任何现有请求模板来创建新的请求模板。服务层为创建的请求模板指派标识符。还要注意的是，在一个实施例中，如果numOfRequestTemplatesToBeCreated大于1(即，Nt＞1)，那么服务层将创建Nt个请求模板。每个要创建的请求模板都应基于listOfRequestParameters的子组中包括的请求参数和listOfExistingRequestTemplateIDs的子组中包括的任何现有模板标识符。服务层为每个创建的请求模板指派标识符。一旦被创建，可以包括用于包含模板的参数值的任何合适数据结构的(一个或多个)请求模板就可以被存储在实现服务层的网络装置(例如，服务器、网关、设备)的存储器中。

可以以任何核实形式的数据结构来实现请求模板，诸如表、可扩展标记语言(XML)文档或任何其它核实的数据结构或文档。参考上面的智能计量用例，以下说明可以在那个用例的上下文中创建的模板的示例，假设智能计量器作为AE(即，计量器AE123)在服务器服务层(即，serverCSE)处使用oneM2M协议经由创建contentInstance资源来周期性地报告其读数。下面示出的请求模板可以在服务器处创建，其包含以下九个参数，但是根据用例要求，请求模板中可以包含更多请求参数：

1.操作是创建资源。

2.始发者或请求者是智能计量器，该智能计量器已作为应用注册到服务器，并且指派了标识符AE123。

3.资源将在meterAE123的容器meterContainer234下创建。

4.要创建的资源类型为contentInstance(即，每个报告的读数将存储在不同的contentInstance中)。

5.请求到期时间为1800秒。换句话说，从meterAE123接收到的每个创建请求都将在1800秒之后到期。

6.操作执行时间为600秒。换句话说，服务器需要不迟于600秒处理来自meterAE123的创建请求。

7.响应类型是非阻塞同步情况，在这种情况下，服务器将立即向智能计量器发送ACK，随后再发送响应。

8.如果服务器将请求转发给另一个CSE，那么每个接收到的创建请求的事件类别都设置为“尽力而为”。

9.令牌请求指示符设置为true，这意味着智能计量器支持令牌请求过程，并且如果接收者在响应中提供了“Token RequestInformation”参数，那么始发者可以尝试令牌请求过程。

以下是包含XML格式的此类值的模板的示例：

<？xml version＝"1.0"encoding＝"UTF-8"？>

<m2m:requestTemplate xmlns:m2m＝"http://www.onem2m.org/xml/protocols">

<op>1</op><！-Operation(op)是CREATE资源>

<to>//example.net/serverCSE/meterAE123/meterContainer234</to>

<！-To(to)指示要在哪里创建新资源>

<fr>meterAE123</fr><！-From(fr)指示始发者ID(即，meterAE123)>

<ty>4</ty><！-要创建的资源类型(ty)是contentInstance>

<rqet>3600</rqet><！-资源到期时间(rqet)是1800秒>

<oet>600</oet><！-操作操作时间(oet)是600秒>

<rt>1</rt><！-响应类型(rt)是非阻塞同步>

<ec>3</ec><！-事件类别(ec)是尽力而为>

<tqi>1</tqi><！-令牌请求指示符(tqi)为true>

</m2m:requestTemplate>.

仍然参考图8，在步骤3中，服务层将请求模板创建响应发送到请求者。这个消息包含所有创建的请求模板的标识符(即，请求模板标识符的列表-RQTID)。

图10图示了在发送常规请求时由请求者发起的用于请求模板创建的方法。在步骤1中，当请求者发送常规请求以访问服务层处的资源或服务时，请求者在这个消息中包含新参数“请求模板创建指示符”(RQTCI)。RQTCI被用于指导服务层除了处理这个常规请求以外还创建请求模板。RQTCI基本上指示图8中的步骤1中包含的所有信息；唯一的例外是RQTCI不需要包含请求参数值，因为它们已包括在常规请求中。本质上，RQTCI用作应当基于请求中包含的并由RQTCI指示/暗示的参数来构建模板的指示。当请求者发出类似的后续请求时，它可以使用模板标识符，而不必再次重新发送相同的参数。当然，在后续请求中需要不同的参数可以被请求者覆盖。覆盖意味着请求者可以指导响应者使用一些与模板中使用的值不同的值。注意的是，这个请求可以包含MTPList，以指示将应用于正在创建的请求模板的现有的消息模板策略的列表。

在步骤2中，服务层处理从步骤1接收到的请求，并生成常规响应。然后，它按照RQTCI所指示的创建请求模板。

在步骤3中，服务层将常规响应发送到请求者。与图8中的步骤3相似，步骤2中创建的请求模板的标识符(即，RQTID)包括在这个响应消息中。

在另一方面，服务层可以在从请求者接收常规请求的同时主动发起请求模板的创建。当服务层观察到多个常规请求使用相似的请求参数时，它可以创建包含那些请求参数的请求模板。然后，服务层需要将创建的请求模板通知给请求者，以便请求者可以利用它来减少常规请求的尺寸并生成优化的请求；服务层有两种情况可以执行这个任务。在情况1中，服务层将专用的请求模板通知发送给请求者；在情况2中，服务层等待来自请求者的下一个常规请求，并在对应的响应消息中背负创建的请求模板的标识符。请求者可以向服务层指示其有能力并且愿意使用请求模板。这个指示可以在注册期间被提供给服务层，或者该指示可以包括在其它请求消息中以向服务层指示请求者愿意将消息模板用于将来的类似请求(如果由服务层指派)。

图11图示了用于创建由服务层发起的请求模板的方法，并且使用分开的通知消息将创建的请求模板的标识符发送回给请求者。

在步骤1-4中，请求者将两个连续的常规请求发送到服务层，并且服务层以两个连续的响应进行响应。从请求者到服务层可以有多于两个常规请求，但是图中未明确示出。请求可以包括请求者愿意和/或能够将消息模板用于将来的相似的请求和/或响应的指示。

在步骤5中，服务层分析这些常规请求并智能地确定请求者在每个常规请求中使用相似或相同的请求参数。然后，它决定创建请求模板(或多个请求模板)。服务层还可以将创建的请求模板与一个或多个现有的消息模板策略相关联。例如，当使用相似请求参数的接收到的连续请求(或非连续请求)的数量等于或大于阈值整数时，服务层决定创建请求模板。然后，如果所有这些请求中使用的请求参数都相同，那么服务层可以简单地创建一个包含所有这些参数的请求模板。如果这些请求使用相似的请求参数但不完全相同，那么服务层可以创建多个请求模板。例如，这些请求中的每个常用请求参数集可以被用于创建请求模板(每个请求中不常用的请求参数也可以被用于创建请求模板)。

图12示出了其中服务层接收三个连续的常规请求的示例，这些请求使用一些如图所示的相似请求参数。对于这个特定场景，服务层可以创建以下请求模板，但是其它模板也是可能的。

·为集合S123中包含的请求参数创建请求模板。

·为集合S12中包含的请求参数创建请求模板。

·为集合S13中包含的请求参数创建请求模板。

·为集合S23中包含的请求参数创建请求模板。

·为集合S12-S123中包含的请求参数创建请求模板。

·为集合S13-S123中包含的请求参数创建请求模板。

·为集合S23-S123中包含的请求参数创建请求模板。

·为集合S1中包含的请求参数创建请求模板。如果请求#1将重复，那么这是有用的。

·为集合S2中包含的请求参数创建请求模板。如果请求#2将重复，那么这是有用的。

·为集合S3中包含的请求参数创建请求模板。如果请求#3将重复，那么这是有用的。

在步骤6中，服务层相应地创建步骤5中确定的请求模板。

在步骤7中，服务层在步骤6中向请求者发送请求模板通知，以将创建的请求模板的标识符(即，RQTID)通知给请求者。可替代地，服务层可以在这个步骤中包括每个创建的请求模板的表示，以便请求者无需采取单独的步骤即可基于RQTID检索创建的请求模板。

在步骤8中，请求者将请求模板通知响应发送回服务层，以指示其是否已成功从步骤7接收到RQTID。

注意的是，在图11中，步骤5和步骤6可以在步骤3和步骤4之间发生。然后，服务层可以在步骤4中背负RQTID；因此，不需要步骤7和步骤8。

图13图示了用于创建由服务层发起的请求模板的方法，并且所创建的请求模板的标识符在常规响应中被背负回给请求者。步骤1至6与图11的步骤1至6相同。

在步骤7中，请求者将新的常规请求发送到服务层。

在步骤8中，服务层接收新的常规请求。它对其进行处理并生成常规响应。服务层在这个常规响应消息中背负步骤6中创建的请求模板的标识符(即RQTID)。

在另一方面，服务层本身(或管理应用)可以主动创建请求模板。然后，请求者可以从服务层发现任何适当的请求模板，并充分利用该模板生成优化的请求并缩短常规请求的尺寸。

图14图示了由服务层发起的用于主动请求模板创建的方法。

在步骤1中，服务层(或其管理应用)可以主动创建一些请求模板而无需考虑来自请求者的任何常规请求消息，而仅基于其能力和可以提供给请求者的服务。以这种方式，请求者需要发现(或被指派)这些请求模板并使用它们与服务层进行交互。换句话说，通过创建这些请求模板，服务层可以指定它仅接受使用这些请求模板中所述的使用请求参数的请求消息；服务层可以丢失对请求模板的约束，以允许请求者通过在其请求消息中向服务层指示新值来覆写某些请求参数的值。注意的是，服务层可以将这些创建的请求模板指派给请求者，这将在下面描述。服务层还可以将创建的请求模板与一个或多个现有的消息模板策略相关联。

在步骤2中，请求者将模板发现请求发送到服务层，以基于消息模板过滤器(MTFilter)发现请求模板。MTFilter可以指示各种搜索条件，诸如：允许请求者使用的请求模板、适用于某些目标资源的请求模板、包含某些请求参数的请求模板、用于某些请求类型的请求模板、请求模板具有的其它特性等。

在步骤3中，服务层根据MTFilter指示的标准搜索本地存储的请求模板。然后，它通过包含与MTFilter匹配的请求模板的列表(即，MTList中的消息模板标识符的列表)向请求者发送模板发现响应消息。虽然未在图中显示，但是请求者可以在它可以将其用于生成优化的请求之前将后续请求发送到服务层以检索发现的请求模板的内容。下文讨论如何检索请求模板。

在又一方面，当请求者向服务层发送常规请求(或优化的请求)时，其背负响应模板指示符(RSTI)以请求服务层执行与响应模板相关的一些任务(例如，为了创建新的响应模板)。如果RSTI确实指示要创建新的响应模板，那么服务层将生成新的响应模板、为它指派响应模板标识符(RSTID)，并将其存储在本地。然后，服务层将常规响应(或优化的响应)发送给请求者。这个响应消息将包括响应模板创建指示符(RSTCI)和RSTID；RSTCI包含服务刚刚创建的响应模板；然后，请求者根据RSTCI创建相同的响应模板、将其标识符设置为RSTID，并将其存储在本地。请求者创建相同的响应模板的原因是：请求者在接收到任何将来的优化的响应消息时需要使用相同的响应模板来恢复原始响应消息。

图14图示了用于响应模板创建的过程。在步骤1中，请求者将请求消息(或者常规请求或者优化的请求)发送到服务层。这个消息可以包含新参数“Response TemplateIndicator”(响应模板指示符，RSTI)，以指示服务层在步骤3中创建响应模板。照此，RSTI也可以包括响应参数及其值，这些参数将包含在响应模板中。这个请求可以包含MTPList，以指示将应用于正在创建的响应模板的现有的消息模板策略的列表。

在步骤2中，服务层处理请求消息并生成常规响应消息。

在步骤3中，如果在步骤1中包含RSTI，那么服务层将创建响应模板。服务层还可以将创建的响应模板与一个或多个现有的消息模板策略相关联，无论请求者在步骤1中是否指示任何策略。要包括在响应模板中的响应参数可以来自RSTI，或者由服务层决定。以oneM2M服务层为例，服务层可以决定在以后的每个响应中使用具有相同值的以下响应参数；照此，可以创建响应模板以包含这些参数。可以包含在响应模板中的oneM2M响应参数包括：Content、From、Result Expiration Timestamp、Event Category等。

在步骤4中，服务层决定请求者是否也需要在其一侧创建相同的响应模板。如果是，那么在步骤5中将包含响应模板创建指示符(RSTCI)和响应模板标识符(RSTID)；如果不是，那么请求者可以在以后的时间从服务层发现并检索任何响应模板，并且步骤5将不包含任何RSTCI和RSTID。

在步骤5中，服务层将在步骤2中生成的响应发送到请求者。这个消息可以包含在步骤4中生成的RSTCI和RSTID。此外，这个步骤可以背负任何先前生成的响应模板及其标识符。

在步骤6中，请求者处理从步骤5接收到的响应。如果步骤5包含RSTCI和RSTID，那么请使用RSTCI创建响应模板并将其存储在本地。从步骤5开始，应将创建的响应模板的标识符设置为RSTID。

在另一方面，当服务层首先将其自身注册到服务层时，服务层可以将适当的请求模板指派给请求者，或者服务层使用专用模板指派请求来做这件事。可替代地，请求者可以向服务层发出具有消息模板过滤器(即，MTFilter)的模板发现请求，并指示其查找任何期望的消息模板。在发现或指派了消息模板之后，请求者可以订阅消息模板，以便在将来更新或删除消息模板时接收自动通知。

图16图示了用于消息模板指派和发现的方法，其中示出了三种可能的情况。在情况1中，当请求者向服务层注册自身时，服务层将现有消息模板指派给请求者。在情况2中，服务层使用单独的专用请求消息将现有消息模板指派给请求者。在情况3中，请求者从服务层发现现有的消息模板。这三种情况可以以任何次序执行，并且不需要一起使用。换句话说，1)对于情况1，步骤1和步骤2需要同时执行，但不依赖于其它步骤；2)对于情况2，步骤3和步骤4需要同时执行，但不依赖于其它步骤；3)步骤5和步骤6需要一起进行，但不依赖于其它步骤。

在步骤1中，请求者向服务层发送服务层注册请求(例如，oneM2M中的AE注册或CSE注册)。在这个注册请求中，请求者可以指示以下信息，服务层可以基于此信息为请求者选择并指派更适当的消息模板；此外，服务层还可以充分利用那些信息为请求者创建新的消息模板：

·请求者是否能够使用请求模板、响应模板或同时使用两者？

·请求者是否想要预配置一些消息模板？

·请求者将频繁发送哪些类型的请求(即，CRUD)？

·请求者将大量使用哪些请求和/或响应参数？

在步骤2中，服务层处理来自步骤1的请求，并将服务层注册响应发送给请求者。这个响应包含新参数MTList，以指示服务层指派给请求者的消息模板标识符的列表。

在步骤3中，服务层将模板指派请求发送给请求者。这个请求包含新参数MTList，以指示服务层指派给请求者的消息模板标识符的列表。

在步骤4中，请求者向服务层发送响应。

在步骤5中，与图14上的步骤2相同。

在步骤6中，与图14上的步骤3相同。

图17图示了在服务层注册过程期间用于创建/指派消息模板的简化且更轻量的方法。在步骤1中，请求者通过发送服务层注册请求来向服务层注册。在这个请求中，请求者指示或表述它将在后续请求中重复使用的一些默认请求参数，包括它们的值。

在步骤2中，服务层为请求者创建默认请求模板，以记录这些默认参数。默认模板意味着服务层将基于这个默认模板处理来自请求者的任何将来的请求消息(如果未明确包括消息模板标识符)。默认模板将仅由同一请求者使用。

在步骤3中，服务层将向请求者发送服务层注册响应。除了指示服务层注册是否成功之外，服务层还指示是否已在步骤2中创建了默认模板。

在步骤4中，在服务层注册成功并且默认模板已成功创建之后，请求者向服务层发送优化的请求。这个优化的请求不再需要包含消息模板标识符；而且，这个优化的请求不包含步骤1中已包含的任何默认参数。

在步骤5中，服务层使用在步骤2中创建的请求者的默认模板来处理接收到的优化的请求。

在步骤6中，服务层向请求者发送消息，作为对从步骤4接收到的优化的请求的响应。

根据又一方面，请求者可以使用消息模板标识符(MTID)来从存储消息模板的服务层检索具体的消息模板。请求者可以已经从上述过程之一获得了MTID。

图18图示了用于检索消息模板的方法。

在步骤1中，请求者向服务层发送模板检索请求。这个消息包含要从服务层检索的消息模板的标识符(即，MTID)。

在步骤2中，服务层按步骤1中的MTID所表示的那样定位消息模板，并生成响应以包含这个消息模板的表示。

在步骤3中，服务层将响应发送回请求者。

根据另一方面，在发现请求模板、被指派了请求模板或自己创建了请求模板之后，与包含许多请求参数的常规请求相比，请求者可以使用它来生成具有较小消息尺寸的优化的请求。当服务层收到优化的请求时，它从优化的请求中提取请求模板标识符(RQTID)并使用对应的模板来处理优化的请求。如果由RQTID表示的请求模板位于另一个网络位置(例如，数据库、模板的存储库、另一个服务层等)，那么服务层需要首先从另一个服务层取出请求模板，以便正确处理优化的请求。

图19图示了用于充分利用请求模板的方法。在步骤1中，请求者将优化的请求发送到服务层SL1。这个消息包含RQTID，以指示请求者用来生成优化的请求的请求模板的标识符。为了从常规请求生成优化的请求，请求者基本上从常规请求中移除请求模板中包含的请求参数并将RQTID插入常规请求。

例如，继续上面讨论的智能计量器示例，假设将oneM2M用作服务层，那么图2中从智能计量器到服务器的优化的请求消息可以采用以下形式，其中rqtid123代表上面描述并存储在服务器处的示例智能计量器请求模板：

在这个示例中，pc是数据类型m2m:primitiveContent的Content参数：始发者要提供的资源的属性。cin是数据类型为m2m:contentInstance的<contentInstance>资源的Root元素。这包括请求始发者供应的强制属性(以及这个示例中未示出的可选属性)。在这个示例中，Content参数包括<contentInstance>资源的实例，该资源由两个属性组成：contentInfo(cnf)(其指定base64编码)和content(con)本身。

如果请求模板不可用或未被采用，那么智能计量器将需要将以下常规请求消息发送到服务器。相比之下，虽然优化的请求需要包含RQTID，但它通过移除九个请求参数来减小消息尺寸。

/>

仍然参考图19，在步骤2中，服务层SL1基于RQTID来定位对应的请求模板。如果请求模板存储在另一个服务层SL2处，那么服务层SL1使用步骤3和4来检索请求模板。

在步骤3中，服务层SL1向服务层SL2发送模板检索请求，以检索由RQTID表示的请求模板。

在步骤4中，服务层SL2向服务层SL1发送模板检索响应。这个响应包含检索到的请求模板的表示(即，请求参数)。

在步骤5中，服务层SL1使用来自检索到的请求模板的信息来将优化的请求翻译成常规请求(即，将请求模板中包含的请求参数复制到优化的请求并从优化的请求中移除RQTID)。然后，它处理常规请求并生成常规响应。

在步骤6中，服务层SL1将常规响应发送回请求者。

图20图示了用于充分利用请求和响应模板的方法。在步骤1中，请求者将优化的请求发送到服务层SL1。这个消息包含RQTID，以指示请求者用来生成优化的请求的请求模板的标识符。为了从常规请求中生成优化的请求，请求者基本上从常规请求中移除了请求模板中已包含的请求参数，并将RQTID插入常规请求。此外，优化的请求还包含响应模板指示符(RSTI)。RSTI可以具有以下值，在步骤7中，服务层SL1将基于该值决定是否创建和/或充分利用响应模板：

·RSTI＝“常规响应”–这在步骤7中指示服务层SL1不创建或充分利用响应模板，而是将常规响应发送给请求者。

·RSTI＝“创建新的响应模板”–这在步骤7中指示服务层SL1创建响应模板。在这种情况下，RSTI还指示响应模板中应包含哪些响应参数(包括值)。

·RSTI＝“使用响应模板生成优化的响应”–这在步骤7中指示服务层SL1利用响应模板生成优化的响应。在这种情况下，RSTI还指示将用于生成优化响应的响应模板的标识符(即，RSTID)。

在步骤2中，服务层SL1基于RQTID来定位对应的请求模板。如果请求模板存储在另一个服务层SL2处，那么服务层SL1使用步骤3和4来检索请求模板。

在步骤3中，服务层SL1向服务层SL2发送模板检索请求，以检索由RQTID表示的请求模板。

在步骤4中，服务层SL2将模板检索响应发送到服务层SL1。这个响应包含检索到的请求模板的表示(即，请求参数)。

在步骤5中，服务层SL1使用检索到的请求模板将优化的请求翻译成常规请求(即，将请求模板中包含的请求参数复制到优化的请求，并从优化的请求中移除RQTID)。

在步骤6中，服务层SL1处理常规请求并生成常规响应。

在步骤7中，根据步骤1中包含的RSTI，服务层SL1执行以下动作。

·如果RSTI＝“常规响应”，那么不执行任何操作，仅在步骤8.1中向请求者发送常规响应。

·如果RSTI＝“创建新的响应模板”，那么通过将所有响应参数(包括RSTI中包含的值)复制到响应模板来创建响应模板，并为创建的响应模板指派标识符(即，RSTID)。然后，在步骤8.2中经由参数RSTCI和RSTID将生成的响应模板发送给请求者。

·如果RSTI＝“使用响应模板来生成优化的响应”，那么按照步骤1中RSTI中所表示的那样充分利用响应模板来生成优化的响应。然后，在步骤8.3中将优化的响应发送给请求者。

在步骤8中，服务层使用以下三个步骤之一将响应发送到请求者：

·步骤8.1：服务层SL1向请求者发送常规响应。

·步骤8.2：服务层SL2向请求者发送常规或优化的响应。但是常规响应包含两个新参数RSTCI和RSTID。RSTCI包含在步骤7中创建的响应模板，并且RSTID是其标识符。如果发送优化的响应，那么优化的响应应基于在步骤7中创建并包含在RSTCI中的新响应模板。

·步骤8.3：服务层SL1向请求者发送优化的响应，该响应是在步骤7中生成的。这个消息包含在步骤7中用于生成优化的响应的响应模板的标识符。

在步骤9中，请求者处理从步骤8.1、步骤8.2或步骤8.3接收到的响应消息。

如果响应来自步骤8.1(即，没有任何新参数的常规响应)，那么请求者只需将其作为常规响应进行处理即可。

如果响应来自步骤8.2(即，包括RSTCI和RSTID的常规响应)，那么请求者根据RSTCI在本地创建/存储相同的响应模板，并将其标识符设置为RSTID，以便将相同的响应模板存储在服务层SL1处并且请求者具有相同的标识符。

如果响应来自步骤8.3(即，优化的响应)，那么请求者根据RSTID来定位对应的响应模板。然后，它使用响应模板将优化的响应翻译成常规响应(即，将所有响应参数及其值从响应模板复制到优化的响应)。

在另一方面，请求者可以使用消息模板标识符(MTID)来更新存储在服务层的具体消息模板。可以有两种场景。在情况1中，请求者将专用模板更新请求发送到服务层；在情况2中，当请求者对服务层执行任何种类的正常请求时，它同时向服务层发送MTID和消息模板更新指示符(MTUI)；因此，服务层将首先处理来自请求者的正常请求，然后根据MTID和MTUI指定的内容来更新对应的消息模板。如果更新的消息模板已被其他请求者使用和/或订阅，那么服务层需要向这些请求者发送通知，并将更新通知给他们。此外，服务层可以监视来自引用现有模板的请求者的传入请求。基于这种监视，SL可以检测到需要更新现有模板参数值的情况(例如，请求者不断覆写现有模板中的请求参数)和/或可以向模板添加新的公共参数的情况(例如，请求者保持使用现有模板中未包含的新参数)；服务层可以通过更新其现有参数值和/或向模板添加新参数来自动更新现有模板。

图21图示了用于使用专用消息来更新消息模板的方法。在步骤1中，请求者将模板更新请求发送到服务层。该消息包含消息模板的标识符(即，MTID)及其要更新的参数/特性(例如，其允许的请求者、其目标资源、其子请求模板等)。

在步骤2中，服务层根据步骤1中包含的其它信息相应地对由MTID表示的消息模板进行更新。如果更新后的消息模板已被其他请求者使用和/或订阅，那么服务层需要向这些请求者发送通知，并将更新通知给他们。

在步骤3中，服务层向请求者发送模板更新响应，以指示步骤1是否已成功处理。

图22图示了当请求者向服务层发送请求消息时用于同时更新消息模板的方法。在步骤1中，请求者将请求消息(或者常规消息或者优化的消息)发送到服务层。这个消息包含以下信息：

·MTID：要更新的现有消息模板的标识符。

·MTUI：消息模板更新指示符。这个参数告诉服务层：1)

MTID表示的消息标识符需要被更新；2)要更新的消息模板的参数和/或特性。可替代地，这个参数可以指示一些请求参数，这些请求参数包括在这个请求消息中，并且服务层应使用它们来更新由MTID表示的消息模板。

在步骤2中，服务层处理请求消息并生成常规响应(或优化的响应)。然后，在步骤1中，它根据MTUI更新由MTID表示的消息模板。如果更新后的消息模板已被其他请求者使用和/或订阅，那么服务层需要向这些请求者发送通知，并将更新通知给他们。

在步骤3中，服务层将响应发送到请求者，以指示步骤1是否已成功处理。

在另一方面，请求者可以使用消息模板标识符(MTID)来删除存储在服务层处的具体消息模板。存在两种场景。在情况1中，请求者将专用模板删除请求发送到服务层；在情况2中，当请求者对服务层执行任何种类的正常请求时，它同时向服务层发送MTID和消息模板删除指示符(MTDI)；因此，服务层将首先处理来自请求者的正常请求，然后根据MTID和MTDI指定的内容删除对应的消息模板。如果被删除的消息模板已被其他请求者使用或订阅，那么服务层将向这些请求者发送通知，并通知他们消息模板的移除。这里的删除操作可以意味着请求者不再想要使用已删除的消息模板。此外，服务层可以监视现有模板是如何被使用的；如果模板已经有一段时间没有被任何请求者使用或不再相关，那么服务层可以自动删除这个模板。

图23图示了用于使用专用消息删除消息模板的方法。在步骤1中，请求者将模板删除请求发送到服务层。这个消息包含要删除的消息模板的标识符(即MTID)。

在步骤2中，服务层相应地移除由MTID表示的消息模板。如果被删除的消息模板已被其他请求者使用或订阅，那么服务层将向那些请求者发送通知，并通知他们消息模板的移除。

在步骤3中，服务层向请求者发送模板删除响应，以指示步骤1是否已成功处理。

图24图示了当请求者向服务层发送请求消息时用于并发地删除消息模板的方法。在步骤1中，请求者将请求消息(或者常规消息或者优化的消息)发送到服务层。这个消息包含以下信息：

·MTID：要删除的现有消息模板的标识符。

·MTDI：消息模板删除指示符。这个参数告诉服务层删除如MTID所表示的消息模板

在步骤2中，服务层处理请求消息并生成常规响应(或优化的响应)。然后，它删除由MTID表示的消息模板。如果被删除的消息模板已被其他请求者使用或订阅，那么服务层将向这些请求者发送通知，并通知他们消息模板的移除。

在步骤3中，服务层将响应发送到请求者，以指示步骤1是否已成功处理。

在另一方面，鉴于RQTID一般比请求参数的总尺寸短得多的事实，请求者可以在一个优化的请求中包含多个RQTID。然后，服务层将使用这多个RQTID的并集(即，这些RQTID中包括的所有请求参数的组合)来处理优化的请求，并相应地向请求者生成一个响应消息。这个特征允许将多个请求模板一起用作联合模板，并在管理和重用请求模板时提供更大的粒度和灵活性。

图25图示了用于在一个请求消息中充分利用多个请求模板的方法。假设：1)请求者已发现了两个或更多个(图中示出了3个发现的模板)请求模板；2)这些模板中的每一个都不包含任何完全相同的参数，而是请求者将使用的请求参数的子集；3)模板一起包含请求者需要使用的所有请求参数。

在步骤1中，请求者使用这三个请求模板来生成优化的请求，该请求不包含这些模板中的任何请求参数，而是仅包括这三个模板的标识符(即，RQTID1、RQTID2和RQTID3)。

在步骤2中，服务层使用如RQTID1、RQTID2和RQTID3所表示的这三个请求模板中包含的所有请求参数处理优化的请求。然后，它生成响应消息。注意的是，请求模板中包含的请求参数不必按次序。

在步骤3中，服务层将响应消息发送到请求者，以指示步骤1中的优化请求是否已成功处理。

根据另一方面，可以在多跳服务层通信下使用消息模板。假设请求者通过中间的传输服务层将请求消息发送到目标服务层。有两个服务层跃点(即，请求者和转接服务层之间的第一跳，以及转接服务层和目的地服务层之间的第二跳)。例如，请求者将服务层组操作发送到转接服务层，然后该转接服务层将操作扇出到一个或多个目的地服务层(即，组成员)。因而，在以下四种情况下可以充分利用请求模板。

在情况1中，请求者使用请求模板来生成优化的请求，并将其发送到转接服务层，该转接服务层将任何优化的请求简单地转发到目的地服务层，目的地服务层将基于对应的请求模板处理优化的请求；在这种情况下，转接服务层没有与模板相关的功能。

在情况2中，请求者仍然使用请求模板来生成优化的请求，并将其发送到转接服务层，但是转接服务层充分利用其请求模板来处理从请求者接收到的优化的请求并将常规请求转发到目的地服务层；在这种情况下，目的地服务层不具有任何与模板相关的功能。

在情况3中，请求者仍然使用请求模板来生成优化的请求并将其发送到转接服务层，并且转接服务层使用其请求模板处理优化的请求；此外，转接服务层使用另一个请求模板生成新的优化的请求，并将新的优化的请求转发到目的地服务层，目的地服务层将使用对应的请求模板对新的优化的请求进行处理。在这种情况下，转接服务层和目的地服务层都具有与模板相关的功能，但是两个服务层跃点使用不同的请求模板。

在情况4中，请求者将常规请求发送到转接服务层，转接服务层使用请求模板生成优化的请求并将其发送到目的地服务层；在这种情况下，请求者不支持与模板相关的功能。

注意的是，为了更高效地启用上述多跳场景，RQTID可以是可解析的网络地址或标识符(例如，URI)的格式。这种格式的RQTID将使中间或转接服务层以及目的地服务层能够从另一个网络位置取出请求模板并将其存储在本地，进而能够处理优化的请求，即使它们最初没有请求模板的本地副本。

图26图示了当转接服务层不支持与模板相关的功能时用于多跳服务层通信的请求模板的方法。在步骤1中，请求者将优化的请求发送到转接服务层。这个消息包含RQTID，以指示请求者用来生成优化的请求的请求模板的标识符。请求者还可以在这个消息中包含新的指示符，以在步骤2中指导服务层将请求自动转发到另一个服务层。

在步骤2中，转接服务层仅将优化的请求转发到目的地服务层。

在步骤3中，转接服务层将优化的请求发送到目的地服务层。

在步骤4中，目的地服务层接收优化的请求并使用RQTID来定位对应的请求模板。然后，它基于请求模板处理优化的请求并生成常规响应。

在步骤5中，目的地服务层将常规响应发送回转接服务层。

在步骤6中，转接服务层接收常规响应，并且在步骤7中，转接服务层将常规响应转发给请求者。

图27图示了当目的地服务层不支持与模板相关的功能时用于在多跳服务层通信中使用请求模板的方法。在步骤1中，请求者将优化的请求发送到转接服务层。这个消息包含RQTID，以指示请求者用来生成优化的请求的请求模板的标识符。请求者还可以在这个消息中包含新的指示符，以在步骤2中指导服务层在将这个优化的请求转发给另一个服务层之前对其进行处理。

在步骤2中，转接服务层基于RQTID来定位对应的请求模板。然后，它使用请求模板将优化的请求翻译成常规请求(即，将请求模板中包含的请求参数复制到优化的请求，并从优化的请求中移除RQTID)。

在步骤3中，转接服务层将常规请求发送到目的地服务层。

在步骤4中，目的地服务层处理常规请求，并将常规响应发送回转接服务层。

在步骤5中，转接服务层接收常规响应，并且在步骤6中，转接服务层将常规响应转发给请求者。

图28图示了当转接服务层和目的地服务层均支持与模板相关的功能时用于在多跳服务层通信中使用请求模板的方法。在步骤1中，请求者将优化的请求发送到转接服务层。这个消息包含RQTID1，以指示请求者用来生成优化的请求的请求模板的标识符。请求者还可以在这个消息中包含新的指示符，以在步骤2中指导服务层在将这个优化的请求转发给另一个服务层之前对其进行处理。

在步骤2中，转接服务层基于RQTID1来定位对应的请求模板。然后，它使用请求模板将优化的请求翻译成常规请求(即，将请求模板中包含的请求参数复制到优化的请求，并从优化的请求中移除RQTID1)。

在步骤3中，转接服务层使用RQTID2表示的另一个请求模板将步骤2中的常规请求翻译成优化的请求(即，从常规请求中移除由RQTID2表示的请求模板中包含的请求参数，然后将RQTID2插入到常规请求)。

在步骤4中，转接服务层将优化的请求发送到目的地服务层。

在步骤5中，目的地服务层接收优化的请求，并使用RQTID2来定位对应的请求模板。然后，它基于请求模板来处理优化的请求并生成常规响应。

在步骤6中，目的地服务层将常规响应发送到转接服务层。

在步骤7中，转接服务层接收常规响应，并且在步骤8中，转接服务层将常规响应转发给请求者。

图29图示了当请求者不支持与模板相关的功能时用于在多跳服务层通信中使用请求模板的方法。在步骤1中，请求者将常规请求发送到转接服务层。请求者还可以在这个消息中包含新的指示符，以在步骤2中指导服务层在将这个优化的请求转发给另一个服务层之前对其进行处理。

在步骤2中，转接服务层使用由RQTID表示的请求模板将常规请求翻译成优化的请求(即，从常规请求中移除由RQTID表示的请求模板中包含的请求参数，并将RQTID插入常规请求)。

在步骤3中，转接服务层将优化的请求发送到目的地服务层。

在步骤4中，目的地服务层接收优化的请求并使用RQTID来定位对应的请求模板。然后，它基于请求模板来处理优化的请求并生成常规响应。

在步骤5中，目的地服务层将常规响应发送到转接服务层。

在步骤6中，转接服务层接收常规响应，在步骤7中，转接服务层将常规响应转发给请求者。

在另一方面，请求者或服务层可以为一个或多个消息模板指定某些适用性策略(称为消息模板策略)。消息模板策略可以应用于多个模板；而且，模板的适用性可以受到多个消息模板策略的约束或定义。服务层可以使用消息模板策略来确定是否/何时为哪个请求者应用模板。消息模板策略可以被定义为模板的一部分，或者被定义为模板之外的分开的信息对象或资源；对于后一种情况，模板和对应的消息模板策略之间的关联将由服务层或请求者建立。照此，因为服务层可以根据为请求者设置的消息模板策略自动定位或识别适当的模板，所以请求者可以生成优化的请求而无需明确指示模板标识符。例如，请求者可以向服务层指定消息模板策略，以指导服务层将指定的模板应用于其所有请求。

图30图示了用于创建消息模板策略的方法。在步骤1中，请求者将消息模板策略创建请求发送到服务，以指示服务层创建消息模板策略。该消息可以包含以下信息：

(a)policyType：指示这个要创建的策略是用于消息模板。

(b)policyElement：它描述策略定义、允许、限制什么等等。策略可以由多个policyElement组成，它们在联合和/或交叉操作中共同定义整个策略。policyElement可以基于或描述以下条件：

·针对服务层本地托管的资源的请求可以使用消息模板

·针对在远程服务层上托管的资源的请求可以使用消息模板

·针对具体类型的资源的请求可以使用消息模板

·来自作为服务层的注册者的请求者的请求可以使用消息模板

·在某个时间窗口内发出的请求可以使用消息模板

·从某些位置发出的请求可以使用消息模板

·针对某些位置的设备的请求可以使用消息模板

·超过某个尺寸阈值的请求可以使用消息模板

·发出的速率超过某个阈值的请求可以使用消息模板。

(c)MTList：这是创建策略将应用到的消息模板标识符的列表。这个参数是可选的。如果这个参数未包括在步骤1中，那么可以应用创建策略的消息模板处于挂起状态，并且可以使用图31中的过程将一个或多个消息模板与创建策略相关联。

在步骤2中，根据步骤1中包含的信息，服务层创建对应的消息模板策略。可替代地，在没有来自请求者的请求的情况下，服务层本身可以主动创建消息模板策略，并将其与任何现有的消息模板相关联。如果步骤1中包含MTList，那么服务层需要更新MTList中包含的那些消息模板，例如，通过将它们与刚创建的消息模板策略相关联。

在步骤3中，服务层向请求者发送消息模板策略创建响应，以指示消息模板是否已成功创建和/或与MTList中指定消息模板的关联是否成功。注意的是，如果步骤1中未包括MTList，那么当请求者(或服务层)发起创建消息模板时，它可以指示现有的消息模板策略并将其与要创建的消息模板相关联。

图31图示了用于将消息模板与消息模板策略相关联或反过来的方法。在步骤1中，请求者将消息模板策略关联请求发送到服务层。这个消息需要包含以下两个参数：

·MTPList：消息模板策略标识符的列表，这些标识符将一起应用于MTList中包含的每个消息模板。

·MTList：消息模板的列表。每个模板的适用性均由MTPList中包含的所有策略均描述。

在步骤2中，服务层将MTPList中的所有策略与MTList中的每个模板相关联。注意的是，服务层可以主动将某些策略与现有的消息模板相关联，而无需接收来自请求者的任何请求；在这种情况下，不需要步骤1。

在步骤3中，服务层向请求者发送消息模板策略关联响应，以指示步骤1中的请求是否已成功处理。

图32图示了用于检索/更新/删除现有的消息模板策略的方法。在步骤1中，请求者将请求发送到服务层以检索、更新或删除现有的消息模板策略。这个消息包含要操作的现有的消息模板策略的标识符(即，MTPID)。

在步骤2中，服务层处理来自步骤1的请求。如果步骤1请求删除现有的消息模板策略，并且如果该策略已经与一个或多个消息模板关联，那么服务层可以更新那些消息模板并将它们与要删除的策略解除关联。

在步骤3中，服务层将响应发送到请求者。如果步骤1请求检索现有的消息模板策略，那么这个消息包含其表示。

在一个实施例中，上述消息模板管理和使用的各个方面可以被实现为oneM2M功能体系架构中的新消息模板管理(MTM)CSF。与时间相关的oneM2M请求参数(例如，RequestExpiration Time、Result Expiration Time、Operational Execution Time、ResultPersistence等)将在请求模板中包含它们的相对值，因为相对值对于不同的请求消息可以保持不变。这个MTM CSF可以驻留在CSE中，并将其服务提供给其它CSE和/或AE。MTM CSF具有与上述方面对应的以下功能。

·MTM CSF可以通过接收和分析来自其它托管CSE的请求来自动生成消息模板(即，<messageTemplate>)。

·MTM CSF将<messageTemplate>资源暴露给其它AE/CSE。换句话说，AE/CSE可以从MTM CSF创建/检索/更新/删除

<messageTemplate>资源。在创建<messageTemplate>资源之后，如果<messageTemplate>是请求模板，那么AE(或CSE)可以检索其表示并进而使用它来生成优化的请求。

上面结合消息模板管理的各个方面描述的功能实体可以如下映射到oneM2M实体：1)服务层映射到oneM2MCSE；以及2)请求者映射到oneM2M AE或CSE。例如，IN-AE1可以在IN-CSE1上创建<messageTemplate1>。稍后，IN-AE1可以基于<messageTemplate1>生成优化的请求，并将优化的请求发送到IN-CSE1。然后，IN-CSE1使用<messageTemplate1>来处理接收到的优化的请求。而且，<messageTemplate1>也可以由其它应用(诸如IN-AE2)使用，以生成针对IN-CSE1的优化请求。

表3中提出了几个新的公共属性。

表3：消息模板管理的新通用属性

表4列出了针对RETRIEVE、UPDATE和DELETE操作的新请求消息参数，基于上述消息模板管理和使用技术，该参数可以被用于支持更高效的RESTful操作。

表4：新请求消息参数的摘要

可以引入新的响应参数MTList，该参数可以包括在AE或CSE注册的响应消息中。例如，当AE/CSE向托管CSE注册时，托管CSE将在其CSEBase下创建<AE>或<remoteCSE>子资源。为了支持第5.3节中提出的消息模板指派，托管CSE为注册的AE/CSE选择适当的消息模板，并将其标识符(即，MTList参数)包括在响应消息中。此外，或可替代地，托管CSE可以将MTList添加为<AE>或<remoteCSE>资源的新属性，以指示MTList中包含的任何模板均适用于<AE>或<remoteCSE>并可由其使用。

可以将RSTCI和RSTID作为两个新的响应参数引入，可以将其包括在从CSE到AE/CSE的任何响应消息中。RSTCI告诉响应消息的接收者创建新的响应模板，并且这个参数包含为了创建响应模板所需的所有信息；创建的响应消息的标识符应被设置为RSTID。

MTList可以作为现有的oneM2M资源(诸如<CSEBase>、<node>、<AE>和<remoteCSE>)的新属性引入。MTList包括消息模板标识符的列表，这些标识符适用于应用(如由<AE>和/或<node>所表示的)或服务层(由<CSEBase>和/或<remoteCSE>所表示的)并且可以被其使用。这个属性是可写的。

messageTemplate可以被用于表示消息模板。AE/CSE可以发现和检索messageTemplate资源；然后它可以将其标识符包含在请求消息中，而无需包含每个单独的请求参数。照此，将减小请求消息的尺寸，进而可以大大减少消息开销。

图33图示了messageTemplate资源的结构的一个示例。<messageTemplate>资源可以包含表5中指定的子资源。

表5：<messageTemplate>资源的子资源

<messageTemplate>资源可以包含表6中指定的属性。

表6：<messageTemplate>资源的属性

图34图示了操作<messageTemplate>资源(例如，创建/检索/更新/删除<messageTemplate>资源)的方法。始发者可以是CSE或AE，而接收者可以是CSE。分别在表7、表8、表9和表10中给出了详细描述。

如表7中所述，Create<messageTemplate>过程可以用于创建<messageTemplate>资源。

表7：<messageTemplate>CREATE

Retrieve<messageTemplate>过程可以被用于检索现有<messageTemplate>资源的属性，如表8中所述。

表8：<messageTemplate>RETRIEVE

Update<messageTemplate>过程可以被用于更新现有的<messageTemplate>资源，如表9中所述，例如对其listOfAllowedRequestors属性的更新。

表9：<messageTemplate>UPDATE

Delete<messageTemplate>过程可以被用于删除现有的<messageTemplate>资源，如表10中所述。

表10：<messageTemplate>DELETE

新的messageTemplatePolicy资源可以被用于表示消息模板。AE/CSE可以发现和检索messageTemplatePolicy资源。然后可以将其与一个或多个消息模板相关联。根据一个实施例的messageTemplatePolicy资源的结构在图35中示出。

<messageTemplatePolicy>资源可以包含表11中指定的子资源。

表11：<messageTemplatePolicy>资源的子资源

/>

<messageTemplatePolicy>资源可以包含表12中指定的属性。

表12：<messageTemplatePolicy>资源的属性

图36图示了操作<messageTemplatePolicy>资源(例如，创建/检索/更新/删除<messageTemplatePolicy>资源)的方法。始发者可以是CSE或AE，而接收者可以是CSE。分别在表13、表14、表15和表16中给出了详细描述。

Create<messageTemplatePolicy>过程可以用于创建<messageTemplatePolicy>资源，如表13中所述。

表13：<messageTemplatePolicy>CREATE

Retrieve<messageTemplatePolicy>过程可以被用于检索现有的<messageTemplatePolicy>资源的属性，如表14中所述。

表14：<messageTemplatePolicy>RETRIEVE

Update<messageTemplatePolicy>过程可以被用于更新现有的<messageTemplatePolicy>资源，如表15中所述，例如对其templatePolicyElement属性的更新。

表15：<messageTemplatePolicy>UPDATE

Delete<messageTemplatePolicy>过程可以被用于删除现有的<messageTemplatePolicy>资源，如表16中所述。

表16：<messageTemplatePolicy>DELETE

图37图示了用于在服务层(例如oneM2MCSE)进行消息模板管理的用户界面的一个实施例。这个界面允许用户或应用经由CSE发起并执行以下任务：

·创建新的消息模板，

·搜索消息模板，

·显示一个或多个消息模板，

·更新一个或多个消息模板，以及

·删除一个或多个消息模板。

图38图示了用于在服务层(例如oneM2MCSE)进行消息模板策略管理的用户界面。这个界面允许用户或应用经由CSE发起并执行以下任务：

·创建新的消息模板策略，

·搜索消息模板策略，

·显示一个或多个消息模板策略，

·更新一个或多个消息模板策略，以及

·删除一个或多个消息模板策略。

在一个实施例中，上述消息模板管理和使用的各个方面可以被实现为万维网联盟(W3C)物联网(WoT)体系架构中事物描述(TD)的一部分，其中WoT服务对象(servient)被定义为设备、网关和/或服务器内部的逻辑模块，以同时支持客户端和服务器功能。每个WoT服务对象都有TD，该TD描述应当如何访问WoT服务对象的资源。以先前的智能计量器用例为例，服务器将具有或将被实现为WoT服务对象。为了支持消息模板管理，在一个实施例中，提出了以下过程：1)服务器的WoT服务对象在其TD中描述并包括请求模板。这个模板可以与上面给出的示例XML格式模板相同，或者包含更多请求参数。在TD中，WoT服务对象还可以指定这个模板仅适用于智能计量器(或更多智能计量器)；2)作为WoT客户端的智能计量器从WoT服务对象或存储WoT服务对象的TD的其它地方发现并检索TD；3)智能计量器从TD提取模板，并理解模板中包含的每个参数的含义；4)智能计量器使用模板来生成包含模板标识符的优化的请求消息(例如，用于向服务器报告其计量器读数)；5)智能计量器将优化的请求发送给WoT服务对象(即，服务器)；6)WoT服务对象接收优化的请求，并使用对应的模板(如优化的请求中包含的模板标识符所表示的)处理优化的请求；7)WoT服务对象将响应发送到智能计量器。可替代地，智能计量器(或其它计量器、WoT客户、WoT服务对象等)可以通过更新其TD来主动创建模板和/或将模板插入到WoT服务对象的TD中。

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

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

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

如图39A中所示，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设备包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、联网汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的设备、安全设备和智能插座。

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

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

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

一般而言，诸如图39B中所示的服务层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中实施，还是在网络的某个其它节点中实施，服务层的实例都可以被实现为或者在网络中的一个或多个独立节点(包括服务器、计算机以及其它计算设备或节点)上执行的逻辑实体(例如，软件、计算机可执行指令等)，或者被实现为一个或多个现有节点的一部分。作为示例，服务层或其部件的实例可以以在具有下述图39C或图39D中所示的一般体系架构的网络装置(例如，服务器、计算机、网关、设备等)上运行的软件的形式实现。

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

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

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

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

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

此外，虽然传输/接收元件36在图39C中被描绘为单个元件，但是网络装置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可以呈现图31中所示并在本文描述的图形用户接口。

处理器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之一的互连接口)连接到这种装置或设备的其它部件、模块或系统。

图39D是示例性计算系统90的框图，该示例性计算系统90还可以被用于实现网络的一个或多个网络装置，诸如图5-8、10、11、13-32、34和36中所示并在本文进行描述的实体，其可以作为诸如图39A和39B中所示之类的M2M服务器、网关、设备或M2M网络中的其它网络装置进行操作。

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

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

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

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

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

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

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

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

3GPP 第三代合作伙伴计划

AE 应用实体

CSE 公共服务实体

CSF 公共服务功能

IoT 物联网

M2M 机器对机器

MT 消息模板

MTCI 消息模板创建指示符

MTID 消息模板标识符

MTM 消息模板管理

MTP 消息模板策略

MTPID 消息模板策略标识符

MTUI 消息模板更新指示符

NB-IoT 窄带IoT

OCF 开放连接基金会

REST 资源状态转移

REQT 请求模板

RQTCI 请求模板创建指示符

RQTID 请求模板标识符

RSPT 响应模板

RSTCI 响应模板创建指示符

RSTID 响应模板标识符

UE 用户装备

URI 统一资源标识符

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

Claims (14)

1.一种网络装置，包括至少一个处理器和存储器，存储器存储可执行指令，当可执行指令由所述至少一个处理器执行时，实现通信网络的服务，所述服务通过应用编程接口(API)的集合来支持服务能力，并使该服务：

在存储器中存储一个或多个消息模板，所述一个或多个消息模板中的每个消息模板包括与能够由服务从通信网络上的一个或多个设备接收的消息相关联的一个或多个参数，并且具有标识每个消息模板所应用的一个或多个目标资源的一个或多个参数；

接收发现一个或多个消息模板的发现请求，其中所述发现请求包括指示与一个或多个消息模板相关联的资源的消息模板搜索标准，其中所述资源是具有能通过RESTful方法操作的表示的面向资源的体系架构(ROA)中的唯一可寻址元素；以及

发送发现响应，所述发现响应包括与所述消息模板搜索标准匹配的消息模板的列表，其中所述消息模版的列表包括与一个或多个消息模板相对应的一个或多个标识符。

2.如权利要求1所述的网络装置，其中可执行指令还使服务：

接收检索、更新或删除由所述消息模板的列表标识的至少一个所述消息模板的请求。

3.如权利要求1所述的网络装置，其中所述消息模板搜索标准包括所述资源的名称或标识符。

4.如权利要求1所述的网络装置，其中所述一个或多个消息模板包括指示定义所述服务何时应用所述消息模板的一个或多个条件的策略。

5.如权利要求4所述的网络装置，其中所述策略指定一个或多个资源，使得所述服务将所述一个或多个消息模板应用于以所述一个种或多个资源为目标的接收消息。

6.如权利要求5所述的网络装置，其中所述策略通过一个或多个标识符来指定一个或多个资源。

7.如权利要求1所述的网络装置，其中所述服务作为网络协议栈之上的中间件服务来提供。

8.一种用于通过应用编程接口(API)的集合来支持服务能力的服务的方法，该方法包括：

存储一个或多个消息模板，所述一个或多个消息模板中的每个消息模板包括与能够由所述服务从通信网络上的一个或多个设备接收的消息相关联的一个或多个参数，并且具有标识每个消息模板所应用的一个或多个目标资源的一个或多个参数；

接收发现一个或多个消息模板的发现请求，其中所述发现请求包括指示与一个或多个消息模板相关联的资源的消息模板搜索标准，其中所述资源是具有能通过RESTful方法操作的表示的面向资源的体系架构(ROA)中的唯一可寻址元素；以及

发送发现响应，所述发现响应包括与所述消息模板搜索标准匹配的消息模板的列表，其中所述消息模版的列表包括与一个或多个消息模板相对应的一个或多个标识符。

9.如权利要求8所述的方法，其中所述方法还包括：

接收检索、更新或删除由所述消息模板的列表标识的至少一个所述消息模板的请求。

10.如权利要求8所述的方法，其中所述消息模板搜索标准包括所述资源的名称或标识符。

11.如权利要求8所述的方法，其中所述一个或多个消息模板包括指示定义所述服务何时应用所述消息模板的一个或多个条件的策略。

12.如权利要求11所述的方法，其中所述策略指定一个或多个资源，使得所述服务将所述一个或多个消息模板应用于以所述一个或多个资源为目标的接收消息。

13.如权利要求12所述的方法，其中所述策略通过一个或多个标识符来指定一个或多个资源。

14.如权利要求8所述的方法，其中所述服务作为网络协议栈之上的中间件服务来提供。