CN111201804B - 启用数据连续***的方法、装置和计算机可读存储介质 - Google Patents

Abstract

数据生成器可以被配置为与M2M/IoT***协商并发起数据连续***。该服务可以用于由数据生成器生成的特定数据集或所有数据集。M2M/IoT***可以被配置为自主决定启动针对数据生成器的数据集的数据连续***。数据生成器可以直接与聚合器SL交互以存储其聚合数据集，并且还可以被配置为更新和删除该数据集中的条目，并在该聚合数据集上启动数据服务。本地SL可以被配置为管理与聚合器SL的所有交互，并且本地SL可以被配置为将数据生成器的请求重新定向到聚合器SL，包括在聚合数据集上启动数据服务的请求。

Description

启用数据连续***的方法、装置和计算机可读存储介质

相关申请的交叉引用

本申请要求于2017年10月23日提交的美国临时申请No.62/575,990的权益，该申请的内容通过引用整体并入本文。

背景技术

面向资源的体系架构(ROA)提供了一种在分布式***中共享数据的解决方案。该体系架构基于资源的概念以及我们如何与这种资源交互。资源可以是可以公开的任何内容，从传感器读数到视频剪辑、到业务流程等等。这些资源可以托管在“资源托管”实体上，并且可以由“资源查询”实体访问。ROA中的资源可以具有以下一般特性：

它们在分布式***中具有唯一的地址。典型地，这是统一资源标识符(URI)的形式。URI使资源可寻址，使得客户端可以访问和操纵资源。资源可能具有多个URI(即多个地址)，但是URI只能引用一个唯一的资源。URI可以提供有关资源的位置以及甚至如何访问资源的信息；

它们具有表示形式(representation)，该表示形式可以提供给定时间点的资源状态的视图。当客户端从服务器检索资源时，资源的表示形式将被提供给客户端；

表示形式可以具有与其它资源的“链接”。应用可以通过从一种状态转换到另一种状态来进行。应用检索资源表示形式(资源A的状态)，其包括与其它资源的“链接”。到下一个状态的过程受这些“链接”的影响，这类似于人类用户通过跟随网页的链接来浏览web；以及

它们通过统一的界面进行操纵。主要思想是，具有良好定义且被广泛接受的语义的少量动词(操作)足以满足大多数应用的要求(例如，参见J.Webber、S.Parastatidis、I.Robinson的“REST in Practice”，O'Reilly，2010)。这些动词用于允许客户端操纵服务器上的资源。例如，客户端可以创建/检索/更新/删除(CRUD)资源。HTTP定义了附加动词(操作)来操纵资源，但是这些动词并不常见(例如，PATCH、TRACE、HEAD、OPTIONS、CONNECT)。

与资源绑定的状态信息构成其元数据。通常，元数据被定义为资源属性。这些属性可以定义资源的特性。定义资源的特性的典型属性列表可以包括，例如：类型、创建时间、上次修改时间、到期时间、访问权限、大小、子资源的数量、父资源、标签/标记和创建者。

资源属性可以定义与绑定到该资源的某个业务逻辑相关的状态信息。例如，如果资源用于存储温度传感器读数，那么一个属性可以是传感器生成的最新读数。

在资源托管实体中，资源可以具有自然的层次结构，其中一些资源是父资源的子资源。最终结果是资源形成资源树。该树内的资源具有父资源，并且可以具有一个或多个子资源。图1中示出了面向资源的体系架构的示例高层概览。

发明内容

数据生成器(应用、服务层等)依赖于服务层来提供三个主要功能：存储其数据、使其数据可供数据消费者随时使用以及提供对存储的数据进行操作的增值服务。遗憾的是，当数据生成器可移动时，它们可能会将其数据存储在M2M/IoT***的不同服务层中。碎片数据存储在不同服务层中的总体影响是服务层难以同时提供这三个主要功能。本文公开了用于增强M2M/IoT***以使其向移动数据生成器提供这些功能的方法和***。

数据生成器可以被配置为与M2M/IoT***协商并发起数据连续***。该服务可以用于由数据生成器生成的特定数据集或所有数据集。M2M/IoT***可以被配置为自主决定启动针对数据生成器的数据集的数据连续***。数据生成器可以直接与聚合器SL交互以存储其聚合数据集，并且还可以被配置为更新和删除该数据集中的条目，并在该聚合数据集上启动数据服务。本地SL可以被配置为管理与聚合器SL的所有交互，并且本地SL可以被配置为将数据生成器的请求重新定向到聚合器SL，包括在聚合数据集上启动数据服务的请求。聚合的数据集可以跟随数据生成器，并且本地SL可以具有聚合数据集。在本地SL发生变化后，当前的本地SL可以从先前的本地SL检索数据集，包括在数据集上运行的所有数据服务。

聚合数据集可以分布在为数据生成器服务的所有本地SL上，并且M2M/IoT***可以在这些本地SL之间维护链接，以帮助查找可能托管聚合数据集的一部分的所有本地SL。对本地SL的针对聚合数据集的任何请求都可能要求本地SL与可能具有可能属于聚合数据集的一部分的数据的先前的本地SL进行递归交互。本地SL可以从数据消费者接收请求，并且可以将该请求传播到具有与聚合数据集相关的数据的本地SL。如果数据消费者已经在聚合数据集上启动的数据服务已从一个本地SL移动到另一个本地SL，那么可以通知数据消费者。

附图说明

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

图1示出了面向资源的体系架构的示例高层概览；

图2示出了支持服务层的示例协议栈；

图3示出了具有分布式M2M/IoT服务的示例M2M/IoT部署；

图4示出了服务层移动性事件的示例原因；

图5示出了示例公共服务功能；

图6示出了示例移动M2M应用；

图7示出了使用方案1的示例移动M2M应用；

图8示出了使用方案2的示例移动M2M应用；

图9示出了使用方案3的示例移动M2M应用；

图10示出了示例数据集和聚合数据集；

图11A示出了提供数据连续性的示例方法，其中所有数据集都在聚合器SL中；

图11B示出了提供数据连续性的示例方法，其中聚合数据集跟随数据产生者；

图11C示出了提供数据连续性的示例方法，其中数据集被存储在具有链接信息的本地服务层中；

图12示出了示例数据连续***请求；

图13示出了使用方法1的示例数据集配置；

图14示出了使用方法1的示例数据集RUD；

图15A和15B示出了使用方法1a在数据集上运行的数据服务的示例；

图16示出了重新定向到聚合器SL的示例；

图17示出了使用方法1b的示例数据集创建；

图18示出了使用方法1b的示例数据集RUD；

图19A和19B示出了使用方法1b在数据集上运行的示例数据服务；

图20示出了使用方法2的示例数据集创建；

图21示出了使用方法3的示例数据集创建；

图22A、22B和22C示出了方法3的示例数据集RUD；

图23A和23B示出了方法3的示例数据服务；

图24示出了使用方法2的来自数据消费者的示例数据服务请求；

图25示出了用于方法3的示例数据消费者检索数据集；

图26示出了示例新数据连续性CSF；

图27A示出了<container>的示例新属性；

图27B示出了<timeSeries>的示例新属性；

图27C示出了<flexContainer>的示例新属性；

图28示出了示例AE注册信息流；

图29A、29B和29C示出了示例CREATE数据集信息流；

图30示出了示例RETRIEVE数据集信息流；

图31示出了示例图形用户界面；

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

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

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

图32D示出了其中可以实施图32A的通信***的各方面的示例计算***的示例框图。

具体实施方式

M2M和IoT的潜在好处使得产生了许多使机器能够相互通信的特定于领域(或纵向市场(vertical))的应用。例如，可以在医疗保健领域、能源领域和汽车领域找到解决方案。这些解决方案已针对这些纵向应用进行了优化，但是无法实现其中来自不同纵向应用的机器和事物相互交互的无所不包的IoT的愿望。

为此，许多标准机构(例如，oneM2M)正在开发服务层，这些服务层定义了单一的水平平台，用于在应用之间(甚至来自不同行业领域的应用之间)交换和共享数据。

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

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

典型的M2M/IoT部署可能具有许多提供各种级别的M2M/IoT服务功能的实体/节点。其中一些实体/节点包括例如托管M2M/IoT服务并由M2M/IoT服务提供商运营的M2M/IoT服务器、托管M2M/IoT服务的M2M/IoT中间节点(或网关)、托管M2M/IoT服务的M2M/IoT设备和通常不托管M2M/IoT服务的“轻型”M2M/IoT设备。

可以驻留在这些实体上或可以通过网络访问这些实体的应用可以利用所提供的M2M/IoT服务。如图3所示，这些M2M/IoT服务可以在本地提供，例如，应用1可以使用M2M/IoT设备1提供的本地M2M/IoT服务来提供数据存储。另外，还可以远程提供M2M服务。例如，应用2可以使用M2M/IoT服务器提供的服务来使其数据可发现。值得注意的是，所示的M2M/IoT服务部署本质上是分层和分布式的，这是oneM2M和ETSI M2M中描述的典型的M2M/IoT服务层。

正在进行许多标准化工作，以定义M2M/IoT服务层(oneM2M、ETSI M2M、OCF)。这些不同的服务层每个都提供一组M2M/IoT服务。其中一些服务是唯一的，在服务层之间提供了一些区别。但是，这些服务中有很多是共同的(例如：数据存储、资源发现、发送通知)。此外，所有这些服务层都可以遵循ROA原则。

预计M2M/IoT***的大量服务用户可能是移动的。这些服务用户既可以使用本地服务，也可以使用远程服务。在一些情况下，服务用户可能要求服务在附近(例如，由于等待时间方面的考虑或由于隐私方面的考虑)。为了在服务用户移动时维持此要求，该用户可能需要改变向其提供M2M/IoT服务的服务层。改变正在提供M2M/IoT服务的服务层可以被称为服务层移动性事件。值得注意的是，服务层移动性并不仅限于服务用户的物理移动。图4示出了可能导致服务层移动性事件的其它因素，包括：

服务层的策略和移动。典型的策略示例包括：一天中的时间(例如，在10AM和12PM之间使用一个服务层，并在其它所有时间使用另一个服务层)、负载(例如，如果服务层上的当前负载超过75％，那么改变提供服务的服务层)，以及服务层能力(例如，连接到SL1的服务用户可以决定切换到SL2，因为后者支持更多服务)；以及

服务层的移动：服务用户可以是固定/静止的，但可以从其附近的移动设备(例如，通过蓝牙)接收M2M/IoT服务。

oneM2M是一个标准开发组织，其目标是创建M2M服务层(例如，参见oneM2M-TS-0001oneM2M功能体系架构-V-2.12.0)。它们将其服务层描述为“分布式软件层—像操作***—其通过提供与不同技术互通的框架来促进统一”(例如，参见OIC核心规范第1部分v1.1.1)。该分布式软件层在位于M2M应用与提供数据传输的通信HW/SW之间的公共服务层中实现。

公共服务层提供了一组标准化的M2M服务，这些服务按功能一起分组为公共服务功能(CSF)。许多实例化的CSF组成了公共服务实体(CSE)。这些服务层(CSE)可以通过Mca参考点与应用(oneM2M术语中的应用实体或AE)交互、通过Mcc(或Mcc的)参考点与其它服务层(CSE)交互，以及通过Mcn参考点与底层网络(oneM2M术语中的网络服务实体或NSE)交互。

图5示出了当前由oneM2M定义的十二个CSF。下面简要描述每个CSF：

应用和服务层管理CSF：提供对AE和CSE的管理。这包括配置、故障排除和升级CSE的功能以及升级AE的能力；

发现CSF：基于过滤条件搜索关于应用和服务的信息；

注册CSF：为AE(或其它远程CSE)提供向CSE注册的功能。这允许AE(或远程CSE)使用CSE的服务；

通信管理/递送处置CSF：提供与其它CSE、AE和NSE的通信。该CSF决定在什么时间以及哪个通信连接来传递通信，并且如果需要并且被允许，那么缓冲通信请求，以便请求可以在以后被转发。

组管理CSF：提供与组相关的请求的处置。使M2M***能够在多个设备、应用等上支持批量(bulk)操作；

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

数据管理和储存库CSF：提供数据存储和中介(mediation)功能(例如，收集数据以进行聚合、重新格式化数据以及存储数据以进行分析和语义处理)；

定位CSF：提供使AE能够获得地理位置信息的功能；

服务收费和计费CSF：为服务层提供收费功能；

设备管理CSF：提供M2M网关和M2M设备上的设备管理能力；

网络服务公开、服务执行和触发CSF：管理与底层网络的通信以访问网络服务功能；以及

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

oneM2M定义了五种共享数据的资源类型。在oneM2M中，这些被定义为内容共享资源：

container(容器)；

contentInstance(内容实例)；

flexContainer(弹性容器)；

timeSeries(时间系列)；以及

timeSeriesInstance(时间系列实例)。

数据管理和储存库CSF负责管理存储在这些内容共享资源中的数据。存储在这些资源之一中的数据可以被认为是数据集。

除了数据存储外，oneM2M还定义了服务用户可能向托管这些内容共享资源的服务层请求的许多增值服务。表1中描述了其中一些服务。

表1：oneM2M提供的增值数据服务

开放连接论坛(OCF)是另一个IoT体系架构，它定义了M2M/IoT设备相互通信的服务层功能。在OCF中，所有交互都是在OIC客户端和OIC服务器之间进行的。OIC服务器存储资源、提供M2M/IoT服务，并根据来自OIC客户端的请求采取行动。资源具有定义的类型和接口。

OCF还为多种数据共享资源类型提供增值服务。例如，OIC服务器可以监视数据共享资源以确保由OIC客户端提供的数据在正确的范围内(例如，在某个最小值和最大值之间)并且与该数据在数据共享资源中的当前值一致(例如，将已经解锁的门的状态改变为：解锁)。

预计大量产生数据的IoT设备可能是移动的，并且可以受益于由M2M/IoT***提供的增值服务。考虑大型在线零售商的跨越许多英亩并且由几层楼组成的运输设施的情况。机器人用于提取包裹并将它们在整个设施中移动。机器人经由物理上最接近它们的任何网关连接到公司网络。它们生成与其观察到的周围环境(其它机器人、人类工作人员、地形、天气状况等)相关的数据，并将该数据提供给M2M/IoT***以进行存储。机器人的移动基于两种主要数据类型进行控制：(1)需要取走哪(个)些物品以及每件物品需要运送到哪里，以及(2)机器人周围的实时情况(例如，当地地形、附近有哪(个)些其它机器人、附近有哪些人等)。

信息类型(1)是相当静态的并且可以从中央应用服务器提供给机器人。

信息类型(2)本质上是动态的并且信息不断变化，要求机器人以低等待时间进行实时响应。

构造M2M/IoT***使得每个机器人连接到的网关可以为机器人实时处理类型(2)的信息会是有益的。网关可以检查机器人的情况，并向其发送命令或建议以指示如何移动。由于该信息可能需要以低等待时间进行处理，因此它可能需要来自网关，而不是来自可能位于远程位置的中央服务器。但是，在部署这种连续的低等待时间体系架构时出现的问题是，随着机器人位置的变化，其连接可能需要从一个网关移动到另一个网关。随着这种移动的发生，新的网关可能需要知道机器人的状态信息。M2M/IoT***体系架构可能需要支持每个机器人的网关获得与机器人相关的数据集的方式。同时，M2M/IoT***还可以允许中央应用服务器使用数据来帮助跟踪和管理机器人机群(fleet)。

因此，由机器人存储的数据可以用于：

网关上的本地应用控制机器人的移动。该应用对延迟非常敏感，并且要求访问数据的等待时间非常低；以及

驻留在互联网中的中央应用服务器通过M2M/IoT服务器访问存储的数据并使用它来跟踪/监视机器人机群。

如图6所示，在时间T1，机器人靠近M2M/IoT网关1，并连接到该网关以使用M2M服务。在时间T2，移动机器人已失去与网关1的连接，并已重新建立与附近的网关2的连接。现在可以通过网关2提供M2M服务。

在这种用例中，机器人预计定期生成数据、将数据存储在M2M/IoT***中，并让M2M/IoT***为该数据提供无缝的增值服务—所有这些都无需考虑机器人是移动的并且可以连接到不同的网关的事实。网关中的本地应用预计始终将数据存储在本地，使得访问这些数据的等待时间不会成为问题。另外，即使机器人移动并从不同的网关接收其M2M服务，中央应用服务器也预计能够检索从机器人产生的所有数据。

关于当前服务层技术(如oneM2M)如何解决上述用例有三种不同的方案：

方案1：来自机器人的应用数据可以存储在本地网关中。这样做时，机器人数据被拆分在两个GW之间，并且每个网关中的数据不会链接在一起。数据来自单个机器人，但存储在M2M/IoT***内的不同节点中(例如，参见图7)。

方案2：来自机器人的应用数据可以存储在M2M/IoT服务器中。这样做时，来自机器人的数据存储在一个节点中，但是网关需要先检索数据，然后本地应用才能处理这些数据以控制机器人(例如，参见图8)。

方案3：来自机器人的应用数据可以存储在本地网关中，并向M2M/IoT服务器通告/公布。这是方案1和方案2的组合—数据仍然被拆分在M2M/IoT***中的节点之间，但是M2M/IoT服务器维持将数据链接在一起的信息(例如，参见图9)。

值得注意的是，本文描述的示例问题和解决方案适用于许多其它用例，诸如其中应用可以使用来自多个传感器的数据来计算用户的“上下文”的虚拟现实用例，以及其中边缘节点网关和中央应用服务器中的应用使用游戏设备生成的数据的游戏用例。

示例用例示出了与M2M/IoT***应如何管理可能经历服务层移动性事件的实体的数据存储相关的两个不同的问题/缺点。

问题1：如果第三方应用(如中央应用服务器)想要恢复M2M/IoT应用生成的所有数据，那么它可能需要检索存储在M2M/IoT***中的数据。第三方应用可能足够智能，例如，以发现所有数据集、检索所有数据集并组合所有数据集。但是，这给M2M/IoT应用带来了管理数据集碎片的负担，这与公共服务层的目标不一致。

问题2：一些M2M/IoT***(如oneM2M)可能会为M2M/IoT应用提供增值服务。此类服务的示例包括：检查缺失的传感器读数、验证时间系列数据的完整性(例如，对于周期性数据，M2M/IoT***可以验证数据在预期时被接收到)、限制存储的读数数量，以及删除比某个时间更老的读数。但是，如果M2M/IoT应用生成的数据集被存储在不同的节点中，并且该信息是碎片化的，那么M2M/IoT***可能无法提供此类增值服务。

例如，考虑来自传感器的数据被存储在M2M/IoT***的不同节点中。在这种情况下，M2M/IoT***很难限制存储的传感器读数的总数。M2M/IoT***可能需要跟踪每个节点中有多少读数，并随着生成新读数以及删除旧读数或旧读数过期来更新该信息。

同样，M2M/IoT***可能很难提供时间系列数据一致性的验证。如果时间系列跨多个节点被拆分，那么每次M2M/IoT应用从一个节点断开并重新连接到另一个节点时，M2M/IoT***都可能检测到时间系列异常。

类似地，M2M/IoT***可能很难提供随时间推移收集到的数据的移动平均值。假设数据生成器正在移动到新的区域，并且服务层正在执行一些操作，这些操作需要先前收集的数据集中的数据。数据生成器可能需要获取先前的数据集以用于新SL处的操作。

在许多用例中，需要聚合存储在不同节点中的来自M2M应用的数据，以使其有用。单独考虑，存储在各个节点中的数据可能是无用的。

值得注意的是，这里提出的问题与数据集成***中已讨论的问题相似。但是，这些问题更多地涉及数据消费者如何与不同的数据集进行交互。本文公开的情况的不同之处在于M2M/IoT***中的问题还包括不同数据集上的提供给数据生成器并且需要处理数据生成器的移动性的潜在服务。

数据生成器(应用、服务层等)依赖于服务层来提供三个主要功能：存储其数据、使其数据可供数据消费者随时使用以及提供对存储的数据进行操作的增值服务。遗憾的是，当数据生成器可移动时，它们可能会将其数据存储在M2M/IoT***的不同服务层中。碎片数据存储在不同服务层中的总体影响是服务层难以同时提供这三个主要功能。本文公开了用于增强M2M/IoT***以使其向移动数据生成器提供这些功能的方法和***。例如，本文公开的是：

一种方法，用于数据生成器与M2M/IoT***协商并发起数据连续***—这可以针对特定数据集或由数据生成器生成的所有数据集；

一种方法，M2M/IoT***可以通过该方法自主决定为数据生成器的数据集启动数据连续***；

一种方法，其中数据生成器直接与聚合器SL交互以存储其聚合数据集，由此数据生成器还可以更新和删除该数据集中的条目并在该聚合数据集上启动数据服务；

一种方法，其中本地SL管理与聚合器SL的所有交互，由此本地SL将所有来自数据生成器的请求重新定向到聚合器SL，请求包括在聚合数据集上启动数据服务的请求；

一种方法，其中聚合数据集遵循数据生成器，由此本地SL具有聚合数据集。在本地SL改变时，当前的本地SL从先前的本地SL检索数据集，包括在数据集上运行的所有数据服务；

一种方法，其中聚合数据集分布在为数据生成器提供服务的所有本地SL上，并且由此M2M/IoT***维护这些本地SL之间的链接，以帮助查找可以托管聚合数据集的一部分的所有本地SL。对本地SL的针对聚合数据集的任何请求都要求本地SL与可能具有属于聚合数据集的一部分的数据的先前的本地SL进行递归交互；

一种方法，本地SL通过该方法接收来自数据消费者的请求，并将该请求传播到所有具有与聚合数据集相关的数据的本地SL；以及

一种方法，通过该方法，如果数据消费者已经在聚合数据集上启动的数据服务已从一个本地SL移动到另一个本地SL，那么通知数据消费者。

另外，本公开还包括用于oneM2M***的过程的实施例，并且还定义了用于配置和监视一些所提议的特征的图形用户界面(GUI)。

数据生成器可以决定将其数据存储到M2M/IoT***中，以利用所提供的M2M/IoT服务。但是，由于服务层移动性事件，数据生成器可能会将其信息存储在M2M/IoT***内的多于一个实体中。例如，图10示出了移动数据生成器在一天中的不同时间将其数据存储在三个不同的本地网关中。生成器在每个本地网关中存储的信息被称为数据集。生成器的所有数据集的组合被称为聚合数据集。值得注意的是，聚合数据集的概念仅适用于这样的数据集，即，如果这些数据集已被存储在单个实体中，那么这些数据集将是单个集合的一部分。因此，例如，如果图10中的数据生成器同时生成温度读数和心率读数，那么可以将它们存储在两个不相关的数据集中，这两个数据集可以不合并到聚合数据集中。

以下实体可以与数据集交互：

数据生成器：生产或更新数据集的功能实体。数据生成器也可以检索数据集、删除数据集或请求M2M/IoT***对数据集执行某个数据服务；

数据消费者：需要/消费数据集中的信息的功能实体。数据消费者可以检索、使用和删除数据集，并且也可以请求M2M/IoT***对数据集执行某个数据服务；

本地服务层：其中数据生成器打算存储其数据集的服务层。典型地，它靠近数据生成器，以减少存储和访问数据时的等待时间问题。数据生成器可以将其信息存储在多个本地SL中，并且特定本地SL中的数据可以被称为数据集。数据生成器具有其中它当前正在接受连接和数据存储服务的当前本地SL；以及其中数据生成器先前已接受连接和数据存储服务的零个或多个过去的本地SL；以及

聚合器服务层：托管数据生成器的聚合数据集的服务层。

另外，以上功能实体可以利用数据集上的数据服务。数据服务是指M2M/IoT***在数据集上提供的增值M2M/IoT服务。一些典型的数据服务示例包括：

限制存储在数据集中的所有数据的总大小；

提供数据集中所有数据的统计信息(例如：均值、中位数、标准差)；

向第三方通知数据集中的数据是否被修改/删除；

提供数据集中最新或最旧的条目；

数据混搭，其中将来自不同来源的数据进行合并以生成用于不同用途的新数据；以及

提取历史数据集以供参考并与当前数据集进行比较。

数据连续***允许数据生成器和数据消费者与聚合数据集进行交互。本文描述了三种在M2M/IoT***内提供数据连续***的方法：

方法1(a/b)：所有数据集都存储在聚合器SL中。在该实现选项中，数据生成器的所有数据集都可以被存储在单个聚合器SL中(例如，参见图11A)。该方法可以由数据生成器或M2M/IoT***实现。在前一种情况下，数据生成器可能知道如何提供数据连续***，并负责确保在聚合器SL中创建了数据集。在下文中，我们将此情况称为方法1a或数据生成器驱动情况。在后一种情况下，数据生成器可能不知道如何提供数据连续***。替代地，数据生成器请求服务，并且M2M/IoT***确保在聚合器SL中创建了数据集。在下文中，我们将此情况称为方法1b或M2M/IoT***驱动(或M2M/IoT SL驱动)情况。

方法2：聚合数据集遵循数据生成器。在这种方法中，数据生成器可以将其数据存储在其当前的本地SL中。M2M/IoT***可以负责将过去的本地SL中的旧数据集传输到新的当前本地SL中。最终结果是当前的本地SL可以具有聚合数据集。但是，与将聚合数据集存储在一个聚合器SL中的方法1不同，在本方法中，聚合数据集从一个本地SL移动到另一个本地SL(例如，参见图11B)。

方法3：聚合数据集由“链接”的各个数据集组成。在这种方法中，数据集只能存储在本地SL中，但是这些数据集中的每一个都具有将各个数据集链接到聚合数据集的信息(例如，参见图11C)。每个数据集都有两个新属性。一个链接到先前或过去的数据集(pastDataSetLink)，另一个链接到后续或将来的数据集(futureDataSetLink)。

数据连续***可以由数据生成器根据请求发起、由M2M/IoT***自主触发，或者由上述某种组合发起。

在一个示例中，由在通信网络的装置上实现的第一服务层实体执行的方法可以包括：从计算设备接收数据连续***请求，其中数据连续***请求包括与计算设备相关联的信息；基于数据连续***请求，确定配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；从计算设备接收执行数据操作的请求，其中执行数据操作的请求识别与第一服务层实体相关联的虚拟资源；以及将对数据的至少一部分执行数据操作的请求重新定向到第二服务层实体。

该方法还可以包括：向计算设备发送将数据的至少一部分存储在第二服务层实体处的指示。将数据的至少一部分存储在第二服务层实体处的指示包括第二服务层实体的标识符。该方法还可以包括：从第二服务层实体接收响应，该响应指示已经对数据的至少一部分执行了数据操作；以及向计算设备发送已经对数据的至少一部分执行了数据操作的指示。计算设备预先配置有与虚拟资源相关联的信息。该方法还可以包括基于配置用于对与计算设备相关联的数据执行数据操作的第二服务层实体，发送与虚拟资源相关联的信息。执行数据操作的请求包括执行与数据相关联的创建、更新、检索或删除操作中的一项或多项的请求。数据连续***请求可以包括对服务层实体(例如，第一服务层实体)维护或存储与计算设备相关联的数据并跟踪该数据在何处被维护或存储的请求。

数据生成器可以使用dataContinuityService请求发起数据连续***。一般过程在例如图12中示出并且在下面进行讨论。

在步骤1中，数据生成器知道其所有或部分数据需要数据连续性。它可以向M2M/IoT***发出dataContinuityService请求(例如，可以向M2M/IoT***中的本地SL发送)。数据生成器可以在请求中包括以下选项：

(1)数据生成器的类型(dataProdType)：这向服务层提供了正在产生数据的设备/实体的类型的指示，并且可以帮助M2M/IoT***确定是否应启用数据连续***。例如，数据生成器可以是起搏器心率监测器或健身腕带心率监测器。

(2)数据集ID(dataSetID)：数据生成器产生的数据集的标识符。如果数据生成器生成多于一种类型的数据(例如，温度读数和心率监测器读数)，那么数据生成器可以选择仅针对数据的子集请求数据连续性。如果未指定或指定为“ALL(全部)”，那么数据生成器可以请求将数据连续性应用于其所有数据。

(3)对于每个数据集，正在产生的数据的类型(dataSetType)：使用相同的示例，数据生成器可以指示其生成温度读数或心率读数。另外，数据生成器可以提供关于数据优先级的指示。

(4)数据连续性实现首选项(dataContPref)：在一些情况下，M2M/IoT服务可能支持一种或多种数据连续性方法。在这种情况下，数据生成器可以请求关于所使用的机制的首选项。可替代地，数据生成器可以提供关于优选选项的一些常规指导。例如，它可以请求导致以下(一项或多项)的服务：低等待时间、高存储能力、易于发现等。如果未指定首选项，那么M2M/IoT***可以从数据连续性支持列表中选择一项。

(5)数据连续性支持(dataContSupp)：数据生成器支持的数据连续性方法列表。一些数据连续性方法可能要求数据生成器的行为有所不同。因此，数据生成器可以指示它是否支持这种新行为。

(6)数据产生设备可移动的指示(dataProdMobInd)：这向M2M/IoT***指示数据产生者可能将数据存储在不同的本地SL中。

(7)聚合器SL的地址(addrAggregatorSL)。这是托管聚合数据集的服务层的地址。数据生成器可以从与M2M/IoT***的先前交互中知道该地址，或者它可以在数据生成器中被预先供给。

(8)存储/访问数据的等待时间(syncingLatency)：这指示数据生成器愿意在数据存储在M2M/IoT***中之前等待多长时间，或者访问先前存储的数据的最大延迟。它可以根据请求类型(创建、删除、检索或删除)可选地被定义。这可能会影响M2M/IoT***选择的数据连续***的类型。例如，有利于方法2或选择更接近数据生成器的聚合器SL。

(9)聚合器SL从本地SL提取信息的频率(pullFrequency)：向M2M/IoT***指示聚合器SL多频繁地需要从本地SL提取数据集，使得聚合数据集保持与本地数据集同步。聚合器SL可以在一段时间与本地SL没有交互之后执行该操作。

(10)最大数据集大小(maxDataSetSize)：数据集中的最大条目数，或数据集的最大大小(以字节为单位)。M2M/IoT***可以使用它来影响所选择的数据连续***的类型。例如，对于大数据集，选择具有大存储容量的聚合器SL。

(11)最大数据集持续时间(maxDataSetDuration)：数据集的最大生存期。M2M/IoT***可以使用它来影响所选择的数据连续***的类型。例如，对于寿命很短的数据集，M2M/IoT***可以决定使用方法2，因为先前的本地SL的数量可能很小。

(12)与数据连续***相关联的调度(dataContinuitySchedule)：一些数据生成器可能只希望特定时间的数据连续***。作为示例，该信息可以允许M2M/IoT***更好地在聚合器SL之间分布数据集。

(13)数据连续***的超时值(dataContinuityTimeout)：如果数据生成器在指定的超时时间内没有活动，那么M2M/IoT***可以终止或暂停数据连续***。

(14)聚合数据集操作(aggDataSetOperation)：在一些情况下，数据生成器可能希望M2M/IoT***在将数据存储到聚合数据集中之前对数据执行操作。例如，数据生成器可以请求将100个读数的平均值存储在聚合数据集中。M2M/IoT***可以计算平均值，并且仅将结果存储在聚合数据集中。可以从标准的操作列表(平均值、方差、最大值、最小值等)中选择操作。可替代地，数据生成器可以在dataContinuityService请求中指定操作的细节。

(15)地理空间指示符(geoSpatialIndication)：向M2M/IoT***提供关于可以在何处托管数据集的位置限制信息。例如，这可能影响聚合器SL的选择。它也可以用于提供关于数据生成器的位置的地理空间限制。例如，如果数据是从某个位置生成的，那么数据生成器可能希望M2M/IoT***使用聚合器SL。

在步骤2中，基于步骤1中提供的输入，M2M/IoT***决定如何处理来自数据生成器的数据。该决定可以基于以下中的一项或多项：

(1)M2M/IoT***支持的数据连续***实现；

(2)数据生成器支持的数据连续***实现(如在步骤1中从dataContinuityService请求接收到的或从数据生成器的订阅简档获得的)；

(3)数据生成器的数据连续***实现首选项(如在步骤1中从dataContinuityService请求接收到的或从数据生成器的订阅简档中获得的)；

(4)由M2M/***的服务运营商定义的策略。例如，该策略可以指示M2M/IoT***必须为所有心率读数提供数据连续性。该策略可以基于以下之一或组合：数据集中的数据的类型、数据生成器的类型、移动性(如果是数据生成器)、数据的优先级等；以及

(5)dataContinuityService请求中提供的任何地理空间限制。

在步骤3中，M2M/IoT***使用dataContinuityService响应向数据生成器通知所选择的的实现。该响应可以提供以下中的一项或多项：

(1)所选择的数据连续***方法(dataContSel)；以及

(2)关于所选择的数据连续***方法的配置细节。例如，这可以包括：

(a)聚合器SL的地址(addrAggregatorSL)。这是托管聚合数据集的服务层的地址；

(b)数据集刷新周期(dataSetRefreshPeriod)：向数据生成器指示每个dataSetRefreshPeriod至少与M2M/IoT***交互一次。这告诉M2M/IoT***数据生成器仍处于活动状态，并且它想使用数据连续***；以及

(c)用于通过本地SL与聚合数据集进行交互的虚拟资源的地址。

在步骤4中，对于那些依赖聚合器SL的方法，M2M/IoT***可以将聚合器SL配置为接受聚合数据集。例如，聚合器SL可以被配置为每pullFrequency秒(如在初始dataContinuityService请求中指定的)从本地SL中提取信息。

在步骤5中，数据生成器使用协商的方法(例如，本文描述的方法1a/b、方法2或方法3)与M2M/IoT***交互。

值得注意的是，dataContinuityService请求可以在注册消息、新的专用消息中携带，或者可以搭载在来自数据生成器的初始数据存储请求中。

聚合器SL的选择可以：(1)由M2M/IoT服务提供商或数据生成器提供，(2)基于策略(例如，所有类型X的数据生成器将使用聚合器SL Y)；(3)基于机器学习(例如，M2M/IoT***可以监视数据生成器使用的本地SL，并选择在等待时间、通信跳数等方面与所有这些最接近的聚合器SL)；(4)基于M2M/IoT***内的关系(例如，如果本地SL注册到另一个SL，那么M2M/IoT***可以选择使用该另一个SL作为聚合器SL)；(5)和/或基于数据生成器在步骤1中提供的信息。例如，本地SL可以根据数据生成器产生的数据集的类型(dataSetType)、数据生成器的移动性(dataProdMobInd)、数据生成器的等待时间要求(syncingLatency)、数据集的持久性或生存期(maxDataSetDuration)、数据集的存储要求或大小(maxDataSetSize)、数据生成器的地理空间要求(geoSpatialIndication)来选择聚合器SL。

作为上述协商的替代方案，数据生成器可以被预先供给使用数据连续***所必需的所有信息。

M2M/IoT***可以使用启发式观察来决定是否启动数据连续***。M2M/IoT***可以监视数据集，以查看数据生成器和数据消费者如何与数据集进行交互。基于这些观察，M2M/IoT***可以决定针对数据集激活数据连续***。例如，M2M/IoT***可以确定与由数据生成器1产生的数据集交互的大多数消费者始终检索存储在不同本地SL中的所有各个数据集。因此，M2M/IoT***可以决定存储/创建聚合数据集，使得这些消费者可以更高效地访问聚合数据。

另外，M2M/IoT***可以依赖于数据生成器的指导来确定何时触发数据连续***。数据生成器可以提供该指导信息作为其注册消息的一部分(或在另一个专用消息中)。示例包括数据生成器的类型、数据连续性实现首选项、所支持的数据连续性方法、数据生产设备可移动的指示、数据生成器在存储/访问数据时可以容许的最大等待时间、最大数据集大小、最大数据集持续时间、与数据连续***相关联的调度、数据连续性超时值，以及数据生成器改变SL的最大速率(maxRateSLChange)。

M2M/IoT***可以使用该信息来更好地确定何时停止/启动数据连续***。例如，当发生以下一种或多种情况时，M2M/IoT***可以决定停止服务并停止在数据集中累积数据：数据生成器已达到最大数据集大小；当数据集被认为是陈旧的(它在***中的时间已超过最大数据集持续时间)；或服务已超时(数据生成器没有任何交互达数据连续性超时值)。

另外，当M2M/IoT***检测到数据生成器可移动(即，它改变其本地SL)时，M2M/IoT***可以决定启动服务。可替代地，这可以基于超过阈值的本地SL的变化率(maxRateSLChange)。

本文公开了针对实现数据连续***的每种方法，关于数据生成器如何与数据集交互的细节。特别地，提供了关于如何创建数据集、数据生成器如何与已创建的数据集交互(以进行检索、更新或删除)以及数据生成器如何可以使用(一个或多个)数据集上提供的数据服务的细节。

在方法1a中，所有数据集都存储在聚合器SL中，并且数据生成器知道数据将存储在聚合器SL中。因此，可以假设：数据生成器从本地SL接收某个连接服务，数据生成器需要M2M/IoT***的数据连续***来用于dataSetID＝ID1的数据集，数据生成器已经与M2M/IoT***协商了方法1并已识别出存储其数据集的聚合器SL，并且使用storeData请求将数据集存储在M2M/IoT***中。例如，在oneM2M实现中，storeData请求可以映射到CREATE请求。

在数据生成器生成数据时，它可以将该数据存储在M2M/IoT***中。当它移动时，数据生成器改变其本地SL(从本地SL1移动到本地SL2)。如图13的示例所示，数据生成器可以连接到本地SL1，并且M2M/IoT***已告知其将所有它的数据集存储在聚合器SL中。

在步骤1中，数据生成器生成新数据并发出针对聚合器SL的storeData请求。该请求首先到达正在为数据生成器提供连接服务的本地SL(SL1)。SL1将该请求转发到聚合器SL。除了要存储的数据之外，StoreData请求还可以包含以下一个或多个参数：

(1)数据连续***的指示(dataContinuityFlag)：用于向本地SL指示该数据是否要使用数据连续***的布尔值。如果为真(TRUE)，那么本地SL使用协商好的方法来提供数据连续性；

(2)聚合数据集标识符(aggDataSetIdentifier)：该标识符允许M2M/IoT***在数据生成器可能产生的多个数据集之间进行区分。在这个示例中，aggDataSetIdentifier＝ID1；

(3)本地SL标识符(localSLIdentifier)：该标识符允许M2M/IoT***知道处置StoreData请求的本地SL。在这个示例中，localSLIdentifier＝SL1；

(4)数据集序列号(dataSetSequenceNumber)：允许M2M/IoT***知道聚合数据集如何被结构化并确定缺失的数据集。聚合器SL可以使用它来帮助确保所有数据都被聚合。它可以用作避免重复和寻找缺失数据的提示；以及

(5)数据集完成指示符(dataSetCompletetInd)：向本地SL指示这是数据集的最后一个条目的指示符。

在步骤2中，SL1将该请求转发到聚合器SL。

在步骤3中，聚合器SL存储数据并发出storeData响应。localSLIdentifier和aggDataSetIdentifier可以与数据一起存储。

在步骤4中，数据生成器接收storeData响应。该响应可以返回更新后的数据集的表示形式。在以后的时间，数据生成器将失去与本地SL(SL1)的连接，并重新连接到本地SL(SL2)。数据生成器可以仍然知道聚合数据集将存储在聚合器SL中。

在步骤5中，数据生成器生成新数据并发出针对聚合器SL的storeData请求。该请求首先到达现在正在为数据生成器提供连接服务的SL2。SL2将该请求转发到聚合器SL。StoreData请求包含aggDataSetIdentifier＝ID1和localSLIdentifier＝SL2。

在步骤6中，SL2将该请求转发到聚合器SL。

在步骤7中，聚合器SL存储数据并发出storeData响应。localSLIdentifier和aggDataSetIdentifier可以与数据一起存储。

在步骤8中，数据生成器接收storeData响应。该响应可以返回更新后的数据集的表示形式。

作为步骤1和步骤5的可替代方案，数据生成器可以在没有localSLIdentifier的情况下发出storeData请求。替代地，本地SL通过dataSetIdentifier的存在来认识到数据连续性的需求，并且可以在将该请求转发到聚合器SL之前自动将其localSLIdentifier包括在storeData请求中。

一旦数据集存储在M2M/IoT***中，数据生成器就可以检索、更新或删除各个数据集或聚合数据集。在下文中，该操作可以被称为检索/更新/删除(RUD)请求。处理步骤如图14所示，附加细节如下所述。可以假设数据生成器正在请求对具有datsSetID＝ID1的数据的RUD操作，并且它通过本地SL(SL3)连接。聚合器SL具有三个数据集(每个本地SL(SL1、SL2和SL3)一个数据集)。

在步骤1中，数据生成器向聚合器SL发出RUD请求。数据生成器可以在请求中包括以下参数：

(1)聚合数据集标识符(aggDataSetIdentifier)：在这个示例中，aggDataSetIdentifier＝ID1；以及

(2)本地SL标识符(localSLIdentifier)：如果数据生成器想要针对聚合数据集的单个数据集，那么它可以包括localSLIdentifier来识别该数据集。例如，当数据生成器连接到本地SL(SL2)时，可以将其设置为“SL2”以针对数据集。可替代地，数据生成器可以忽略该属性，或使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，请求是针对连接到本地SL(SL2)时产生的数据集的检索操作。

在步骤2中，SL3将请求转发到聚合器SL。

在步骤3中，聚合器SL管理请求。请求可能仅影响作为在连接到本地SL(SL2)时产生的数据集的一部分的那些资源(数据)。聚合器SL根据请求准备相关的响应，并将响应发给数据生成器。例如，如果请求是检索，那么聚合器SL可以仅返回从所选择的数据集中检索到的结果。

在步骤4中，RUD响应到达数据生成器。

数据生成器可以请求对数据集运行的数据服务。数据服务的典型示例包括：限制存储在数据集中的条目的数量、监视周期性数据集中是否缺失条目、找到数据集的移动平均值、订阅数据集中的条目被更新、删除时得到通知，等等。继续前面的示例，聚合器SL中的聚合数据集可以包含三个数据集。处理步骤如图15所示，附加细节如下所述：

在步骤1中，数据生成器向聚合器SL发出dataService请求。数据生成器可以在请求中包括以下参数：

(1)聚合数据集标识符(aggDataSetIdentifier)：在这个示例中，aggDataSetIdentifier＝ID1；

(2)本地SL标识符(localSLIdentifier)：如果数据生成器想要针对单个数据集，那么它可以包括localSLIdentifier来识别该数据集。例如，当数据生成器连接到本地SL(SL1)时，可以将其设置为“SL1”以针对数据集。可替代地，数据生成器可以省略该属性，或使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，所请求的数据服务是订阅当某个第三方从数据集1(当数据生成器经由本地SL(SL1)连接时产生的数据)检索一个或多个条目时要被通知；

(3)服务身份：应处理数据的服务的身份；以及

(4)服务配置：配置服务所需的任何信息。

在步骤2中，SL3将请求转发到聚合器SL。

在步骤3中，聚合器SL管理数据服务请求。聚合器SL可以向所请求的数据集(在该示例中为数据集1)提供服务。聚合器SL响应数据服务请求并发起服务。

在步骤4中，dataService响应到达数据生成器。

在步骤5中，第三方应用/实体检索数据集3的条目。不触发数据服务，并且不通知数据生成器。

在步骤6中，第三方应用/实体检索数据集1的条目。触发数据服务，并通知数据生成器。

在方法1b中，所有数据集都可以存储在聚合器SL中，并且数据生成器可以不知道数据将存储在聚合器SL中。数据生成器想要数据连续性，但让M2M/IoT***对此进行管理，包括选择聚合器SL。数据生成器知道它将移动，并因此发出该请求。然后，本地SL可以不在本地存储数据集，而是将该数据集转发到聚合器SL。这种情况与先前情况的不同之处在于数据生成器可能没有预先设置聚合器SL。可以假设：数据生成器从本地SL接收某个连接服务；数据生成器需要M2M/IoT***的数据连续***来用于dataSetID＝ID1的数据集；数据生成器已经确定它应使用方法1b来实现与本地SL的数据连续性，但尚未识别聚合器SL；并且使用storeData请求将数据集存储在M2M/IoT***中。

在数据生成器生成数据时，它可以将该数据存储在M2M/IoT***中。当它移动时，数据生成器可能改变其本地SL(例如，从本地SL(SL1)移动到本地SL(SL2))。

在这种方法中，没有数据集存储在本地SL中。而是，该方法依赖于本地SL将来自数据生成器的与聚合数据集中的任何条目进行交互的所有请求操作重新定向到聚合器SL。数据生成器继续仅与本地SL交互。重新定向由M2M/IoT***透明地处置。如果数据生成器不知道聚合器SL的身份，那么本地SL维护将数据生成器身份和聚合数据集标识符链接到存储聚合数据集的聚合器SL的映射信息。可以为每个数据生成器将该mappingInfo存储为一组列表，例如：

数据生成器的聚合数据集标识符列表。数据生成器和聚合数据集标识符对唯一地识别M2M/IoT***中的聚合数据集；以及

聚合器SL地址列表：对于每个唯一的聚合数据集(由数据生成器和聚合数据集标识符对识别)，可能存在其中存储聚合数据集的对应的聚合器SL。

数据生成器请求操作可以具有允许本地SL知道该请求将重新定向到聚合器SL中的聚合数据集的标志或指示。这可以使用下面描述的选项之一来实现：

选项1：本地SL可以在请求中使用数据生成器身份和聚合数据集标识符(aggDataSetIdentifier)来确定(1)所请求的操作需要被重新定向，以及(2)确定聚合器SL的身份。

选项2：该请求可以具有新的参数以明确地用信号通知该请求需要被重定向(retargetFlag)。本地SL可能仍然需要使用聚合数据集标识符(aggDataSetIdentifier)和数据生成器身份来确定聚合器SL的身份。

选项3：本地SL维护专门用于重新定向的虚拟<virtDataSet>资源。数据生成器可能需要在其希望与数据集进行交互的任何时间针对该虚拟资源。本地SL可能仍需要使用聚合数据集标识符(aggDataSetIdentifier)和数据生成器身份来确定聚合器SL的身份。可以通过以下一种或多种方法使数据生成器知道虚拟<virtDataSet>资源：预先配置；作为数据连续***发起过程(或注册过程)的一部分；响应于与本地SL的初始数据集请求/响应交换(例如，在对本地SL的第一storeData请求期间，SL可以使用关于<virtDataSet>资源的信息进行响应)；和/或响应于与本地SL的专门交换。例如，数据生成器可以请求创建资源以托管聚合数据集。响应于该请求，本地SL可以向数据生成器提供关于<virtDataSet>资源的细节。

选项4：本地SL可以维护专门的资源，这些资源会触发托管服务层，以重新定向与这些资源交互的任何请求。作为与本地SL的初始数据集请求/响应交换的一部分，可以使数据生成器知道该资源。在典型的oneM2M示例中，可以定义特殊的数据共享资源。例如，如果数据生成器发出将数据存储在该数据共享资源中的请求，那么托管SL可以将数据自主地存储在聚合器SL中。

附加地或可替代地，如果数据生成器知道聚合器SL身份，那么：

选项5：数据生成器指示需要数据连续***并提供用于该服务的方法。另外，聚合数据集标识符和聚合器SL ID(或聚合器SL的地址)也可以包含在请求中。

图16示出了根据选项1的预期重新定向的高级视图。重新定向操作在步骤2中示出。在下文中，仅示出选项1。但是，结果可以扩展到其它方法。作为替代，在接收到请求操作(步骤1)之后，本地SL可以向数据生成器立即发出响应，然后采取后续步骤将请求重新定向到聚合器SL。使用选项1的典型调用流程如图17所示。假设数据生成器从本地SL(SL1)移动到本地SL(SL2)。

在步骤1中，数据生成器生成新数据，并向SL1发出storeData请求。storeData请求可以包含以下一个或多个属性：

(1)数据连续***的指示(dataContinuityFlag)：用于向本地SL指示该数据是否要使用数据连续***的布尔值。如果为真(TRUE)，那么本地SL使用协商好的方法来提供数据连续性。

(2)聚合数据集标识符(aggDataSetIdentifier)：该标识符允许M2M/IoT***在数据生成器可能产生的多个数据集之间进行区分。在这个示例中，aggDataSetIdentifier＝ID1。

(3)先前本地SL标识符(priorLocalSLIdentifier)：该标识符允许M2M/IoT***知道处置数据生成器的连接性的最后一个/先前的本地SL。M2M/IoT***可以使用该信息来检索任何映射信息。在这个示例中，priorLocalSLIdentifier＝NULL。

(4)聚合器SL标识符(aggregatorSLIdentifier)：这识别充当聚合器SL的SL。如果数据生成器知道该身份，那么数据生成器可以将该身份包括在storeData请求中。

(5)数据集序列号(dataSetSequenceNumber)：允许M2M/IoT***知道聚合数据集如何被结构化并确定缺失的数据集。聚合器SL可以使用它来帮助确保所有数据都被聚合。它可以用作避免重复和寻找缺失数据的提示。

(6)数据集完成指示符(dataSetCompletetInd)：向本地SL指示这是数据集的最后一个条目的指示符。

在步骤2中，SL1确定应重新定向请求。为了确定重新定向的位置(聚合器SL)，它可以遍历其mappingInfo以查看是否有任何条目对应于请求的数据生成器身份和聚合数据集标识符。如果是，那么它然后可以使用映射信息来确定聚合器SL。附加地或可替代地，它可以使用storeData请求中提供的值(如果数据生成器在该请求中提供了聚合器SL ID)。

在步骤3中，聚合器SL存储数据并发出storeData响应。

在步骤4中，数据生成器接收storeData响应，其包括所选择的聚合器SL ID和可能的新聚合数据集ID(如果它从步骤1中提供的ID改变)。

在以后的时间，数据生成器失去与本地SL(SL1)的连接并重新连接到本地SL(SL2)。

在步骤5中，数据生成器生成新数据，并向SL2发出storeData请求。storeData请求可以包含：aggDataSetIdentifier＝ID1、priorLocalSLIdentifier＝SL1，以及aggregatorSLIdentifier。

在步骤6中，如果SL2(从步骤5中的storeData请求)或从SL2中可用的映射信息中知道聚合器SL的身份，那么处理继续进行步骤8。否则，SL2使用getMappingInfo请求查询先前的本地SL(即SL1)以获得映射信息。该请求可以包括aggDataSetIdentifier和数据生成器身份。

在步骤7中，本地SL1以getMappingInfo响应消息作为响应，该消息包含该数据集的映射信息。

在步骤8中，本地SL2将该请求重新定向到聚合器SL。

在步骤9中，聚合器SL存储数据并发出storeData响应。

在步骤10中，数据生成器接收storeData响应。

作为步骤6和步骤7的替代，M2M/IoT***可以在一个公共服务层中维护所有数据集的映射信息。SL2可以查询该公共SL，以确定所选择的数据集的映射信息。

一旦数据集存储在M2M/IoT***中，数据生成器就可以检索、更新或删除数据集中的特定条目、完整数据集或聚合数据集。在下文中，该操作可以被称为检索/更新/删除(RUD)请求。处理步骤如图18所示，并且附加细节如下所述。假设数据生成器正在对具有aggDataSetIdentifier＝ID1的数据请求RUD操作，并且它通过本地SL(SL3)连接。聚合器SL可以具有三个数据集(每个本地SL(SL1、SL2和SL3)一个数据集)。

在步骤1中，数据生成器向本地SL(SL3)发出RUD请求。数据生成器可以在请求中包括以下属性：

(1)聚合数据集标识符(aggDataSetIdentifier)：在这个示例中，aggDataSetIdentifier＝ID1；

(2)本地SL标识符(localSLIdentifier)：如果数据生成器想要针对单个数据集，那么它可以包括localSLIdentifier来识别该数据集。例如，当数据生成器连接到本地SL(SL2)时，可以将其设置为“SL2”以针对数据集。可替代地，数据生成器可以忽略该属性，或使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，请求是针对聚合数据集的检索；以及

(3)先前本地SL标识符(priorLocalSLIdentifier)：该标识符允许M2M/IoT***知道处置数据生成器的连接性的最后一个/先前的本地SL。M2M/IoT***可以使用该信息来检索任何映射信息。在本示例的这个步骤中，priorLocalSLIdentifier＝NULL。

在步骤2中，SL3遍历其mappingInfo以查看是否有任何条目对应于请求的数据生成器身份和聚合数据集标识符。如果是，那么SL3确定应重新定向该请求，并使用映射信息来确定聚合器SL。请求可以被重新定向到聚合器SL。

在步骤3中，聚合器SL管理请求。该请求影响聚合数据集。聚合器SL根据请求准备相关的响应，并将响应发给数据生成器。例如，如果请求是检索，那么聚合器SL可以返回从聚合数据集中检索到的结果。

在步骤4中，RUD响应到达数据生成器。

数据生成器可以请求对数据集运行的数据服务。继续前面的示例，可以假设聚合器SL中的聚合数据集包含三个数据集。处理步骤如图19所示，附加细节如下所述。

在步骤1中，数据生成器向聚合器SL发出dataService请求。数据生成器可以在请求中包括以下属性：

(1)聚合数据集标识符(aggDataSetIdentifier)：在这个示例中，aggDataSetIdentifier＝ID1；

(2)本地SL标识符(localSLIdentifier)：如果数据生成器想要针对单个数据集，那么它可以包括localSLIdentifier来识别该数据集。例如，当数据生成器连接到本地SL(SL1)时，可以将其设置为“SL1”以针对数据集。可替代地，数据生成器可以省略该属性，或使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，请求的数据服务是“缺失数据”服务，其中SL监视数据集中的条目以确定是否缺失条目，并采取某种补救措施—例如，它通知第三方应用；

(3)先前本地SL标识符(priorLocalSLIdentifier)：该标识符允许M2M/IoT***知道处置数据生成器的连接性的最后一个/先前本地SL。M2M/IoT***可以使用该信息来检索任何映射信息。在这个示例中，priorLocalSLIdentifier＝NULL；

(4)服务身份：应处理数据的服务的身份；以及

(5)服务配置：处理服务所需的任何配置信息。

在步骤2中，SL3将请求重新定向到聚合器SL。

在步骤3中，聚合器SL管理数据服务请求。聚合器SL可以向所请求的数据集(在该示例中为聚合数据集)提供服务。聚合器SL响应数据服务请求并发起服务。

在步骤4中，dataService响应到达数据生成器。

在步骤5中，数据生成器失去与本地SL(SL3)的连接。

在步骤6中，数据生成器尝试将数据条目存储在聚合数据集中，但由于缺乏连接而失败。

在步骤7中，一段时间后，数据生成器重新连接到新的本地SL(SL4)。

在步骤8中，数据生成器将数据条目存储在聚合数据集中。

在步骤9中，聚合器SL确定数据集中的数据条目缺失。聚合器SL通过向第三方应用通知缺失的数据来采取补救措施。

在方法2中，可以在当前本地SL中维护聚合数据集。数据生成器可以始终与其本地SL交互，并且M2M/IoT***可以确保所有先前的数据集都遵循数据生成器。在这个实施例中，可以假设数据生成器从本地SL接收一些连接服务，数据生成器需要M2M/IoT***的数据连续***来用于dataSetID＝ID1的数据集，数据生成器已经协商了使用方法2保证数据连续性，并使用storeData请求将数据集存储在M2M/IoT***中。

当数据生成器生成数据时，它可以将该数据存储在M2M/IoT***中—当它移动时，数据生成器改变其本地SL(从本地SL(SL1)移动到本地SL(SL2))。用于创建数据集的示例调用流程如图20所示。假设数据生成器从本地SL(SL1)移动到本地SL(SL2)。

在步骤1中，数据生成器生成新数据并向本地SL(SL1)发出storeData请求。storeData请求可以包含以下一个或多个属性：

(1)数据连续***的指示(dataContinuityFlag)：用于向本地SL指示该数据是否要使用数据连续***的布尔值。如果为真(TRUE)，那么本地SL使用协商好的方法来提供数据连续性；

(2)聚合数据集标识符(aggDataSetIdentifier)：该标识符允许M2M/IoT***在数据生成器可能产生的多个数据集之间进行区分。在这个示例中，aggDataSetIdentifier＝ID1；

(3)本地SL标识符(localSLIdentifier)：该标识符允许M2M/IoT***知道处置StoreData请求的本地SL。在这个示例中，localSLIdentifier＝SL1；

(4)先前本地SL标识符(priorLocalSLIdentifier)：该标识符允许M2M/IoT***知道处置数据生成器的连接性的最后一个/先前本地SL。M2M/IoT***可以使用该信息来检索任何映射信息。在这个示例中，priorLocalSLIdentifier＝NULL；

(5)数据集序列号(dataSetSequenceNumber)：允许M2M/IoT***知道聚合数据集如何被结构化并确定缺失的数据集。聚合器SL可以使用它来帮助确保所有数据都被聚合。它可以用作避免重复和寻找缺失数据的提示；以及

(6)数据集完成指示符(dataSetCompletetInd)：向本地SL指示这是数据集的最后一个条目的指示符。

在步骤2中，SL1确定数据生成器是否具有先前的数据集。例如，SL1可以使用priorLocalSLIdentifier做出该确定。在这种情况下，由于priorLocalSLIdentifier的值＝NULL，由此SL1确定这是来自该生成器的第一个数据集。

在步骤3中，SL1存储数据并向数据生成器发出storeData响应。

在以后的时间，数据生成器失去与本地SL(SL1)的连接，并连接到本地SL(SL2)。

在步骤4中，数据生成器生成新数据，并向SL2发出storeData请求。storeData请求可以包含：aggDataSetIdentifier＝ID1；localSLIdentifier＝SL2；PriorLocalSLIdentifier＝SL1。

在步骤5中，SL2使用priorLocalSLIdentifier来确定数据生成器是否具有先前的数据集。当priorLocalSLIdentifier＝SL1时，SL2确定先前数据集存储在SL1中。SL2向SL1发出getAggrDataSet请求。getAggrDataSet可以包含数据集标识符(ID1)。

在步骤6中，SL1以getAggrDataSet响应消息作为响应，该消息包含聚合数据集。另外，可以删除SL1上的先前数据集。

在步骤7中，SL2存储聚合数据集以及当前storeData请求中的数据。

在步骤8中，SL2向数据生成器发出storeData响应。

值得注意的是，在后续的storeData请求中，SL2忽略该请求中包含的priorLocalSLIdentifier信息。

作为步骤5和步骤6的替代，M2M/IoT***可以在一个公共服务层中维护所有数据集的映射信息。本地SL2可以查询该公共SL，以确定所选择的数据集的映射信息。

作为附加的增强，作为getAggrDataSet的一部分，SL1还可以传输当前正在SL1上运行的所有正在进行的服务。在传输结束时，这些服务在SL2处重新启动。

一旦数据集存储在M2M/IoT***中，聚合数据集就可以位于当前本地SL中。数据生成器可以通过直接与本地SL进行交互来检索、更新或删除数据集中的特定条目、完整数据集或聚合数据集。

在一个实施例中，数据生成器可以请求对数据集运行的数据服务。由于聚合数据集始终存储在当前本地SL中，因此数据服务也在当前本地SL中运行。

需要解决的一个问题是如何管理在SL上启动的数据服务，然后将聚合数据集移动到另一个SL。作为将聚合数据集从一个SL移动到另一个SL的一部分，任何正在进行的数据服务也应该被移动。

在方法3中，所有数据集都可以存储在本地SL中，并且可以将链接/引用添加到这些数据集。这些链接允许将数据集分组为聚合数据集。M2M/IoT***可以负责在每个本地数据集中创建链接(pastDataSetLink、futureDataSetLink)。对于该方法，可以假设数据生成器已从本地SL接收到某个连接服务，数据生成器需要M2M/IoT***的数据连续***，并且聚合数据集具有dateSetID＝ID1，数据生成器已经协商使用方法4来保证数据连续性，并使用storeData请求将数据集存储在M2M/IoT***中。

当数据生成器生成数据时，它可以在M2M/IoT***中存储该数据—当它移动时，数据生成器改变其本地SL(从SL1移动到SL2)并在SL2中创建新的数据集。创建和链接数据集的过程如图21所示，并在下面进行描述。

在步骤1中，数据生成器生成新数据，并发出针对本地SL(SL1)的storeData请求，该本地SL向数据生成器提供连接服务以及数据存储服务。除了要存储的数据之外，StoreData请求还可以包含以下一个或多个属性：

(1)数据连续***的指示(dataContinuityFlag)：用于向本地SL指示该数据是否要使用数据连续***的布尔值。如果为真(TRUE)，那么本地SL使用协商好的方法来提供数据连续性；

(2)聚合数据集标识符(aggDataSetIdentifier)：该标识符允许M2M/IoT***在数据生成器可能产生的多个数据集之间进行区分。在这个示例中，aggDataSetIdentifier＝ID1；

(3)先前本地SL标识符(priorLocalSLIdentifier)：该标识符允许M2M/IoT***知道处置数据生成器的连接性的最后一个/先前的本地SL。在这个示例中，priorLocalSLIdentifier＝NULL；

(4)数据集序列号(dataSetSequenceNumber)：允许M2M/IoT***知道聚合数据集如何被结构化并确定缺失的数据集。聚合器SL可以使用它来帮助确保所有数据都被聚合。它可以用作避免重复和寻找缺失数据的提示；以及

(5)数据集完成指示符(dataSetCompletetInd)：向本地SL指示这是数据集的最后一个条目的指示符。

在步骤2中，SL1将数据以及提供的属性(aggDataSetIdentifier)存储在数据集中。

在步骤3中，SL1使用priorLocalSLIdentifier来确定先前数据集的存储位置。由于该值被设置为NULL，因此SL1确定这是与数据生成器相关联的第一个数据集，并且可以设置pastDataSetLink＝“NULL”。

在步骤4中，在以后的时间，数据生成器失去与SL1的连接，并连接到SL2。数据生成器可以知道其最后一个数据集存储在SL1中。

在步骤5中，数据生成器生成新数据并发出针对SL2的storeData请求，该请求现在正在向数据生成器提供连接服务和数据存储服务。storeData请求包含aggDataSetIdentifier＝ID1和priorLocalSLIdentifier＝SL1。

在步骤6中，SL2使用priorLocalSLIdentifier来确定先前数据集的存储位置。由于该值被设置为SL1，因此SL2确定应将当前数据集链接到SL1中的数据集。它可以将链接更新到过去的数据集(pastDataSetLink)，以指向SL1中的数据集。

在步骤7中，SL2还更新SL1上数据集中的链接，使得前向链接(futureDataSetLink)指向SL2中的数据集。这是通过updateDataSetLink请求完成的。该请求可以包含以下信息：聚合数据集标识符(aggDataSetIdentifier＝ID1)和到将来数据集的链接(futureDataSetLink＝到SL2中的数据集的链接)。

在步骤8中，SL1更新数据集，使得其“将来的”链接指向SL2中的数据集。

在步骤9中，SL1向SL2发出updateDataSetLink响应。

在步骤10中，SL2向数据生成器发出storeData响应。

一旦数据集被存储在M2M/IoT***中(在本地SL中)，数据生成器就可以发出针对数据集中的数据条目、针对特定本地SL中的一个或多个数据集、或者针对聚合数据集的RUD请求。可能有两种替代方案：

数据生成器与所有本地SL交互以“协调”所请求的操作。例如，如果数据生成器对检索聚合数据集感兴趣，那么它可以在每个本地SL中检索每个单独的数据集，并在检索到所有数据集后对其进行聚合。这是可能的，因为数据生成器知道托管每个数据集的SL。但是，这可能导致某些效率低下的情况，因为数据生成器可能不得不检索距离许多通信跳那么远的本地SL中的数据集；或者

数据生成器与当前本地SL交互，从而提供连接服务和数据存储服务，并且M2M/IoT***负责协调所请求的操作。使用上面的示例，其中数据生成器对检索聚合数据集感兴趣，当前本地SL可以负责检索每个单独的数据集并执行聚合。然后，本地SL可以用聚合数据集对请求者用单个响应来响应。

后一种方法的典型调用流程如图22所示，并在下面进行描述。可以假设数据生成器正在请求对具有aggDataSetIdentifier＝ID1的数据的RUD操作，并且它通过本地SL(SL3)连接，并且数据生成器已经产生了三个数据集(每个本地SL(SL1、SL2和SL3)一个数据集)，并且当前正在从SL3接收连接服务和数据存储服务。

在步骤1中，数据生成器向SL3发出RUD请求。数据生成器可以在请求中包括以下属性：

(1)聚合数据集标识符(aggDataSetIdentifier)：在这个示例中，aggDataSetIdentifier＝ID1；以及

(2)本地SL标识符(localSLIdentifier)列表：如果数据生成器希望针对数据集中的数据条目或特定数据集，那么它可以包括(一个或多个)localSLIdentifier列表以识别(一个或多个)数据集。例如，在数据生成器连接到本地SL(SL2)时，可以将localSLIdentifier设置为“SL2”以针对数据集。可替代地，数据生成器可以省略该属性，或者使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，请求是针对连接到本地SL(SL2)时产生的数据集的检索。

在步骤2中，SL3确定受来自步骤1的RUD请求影响的本地SL。

如果RUD请求仅影响当前本地SL(即SL3)(情况1)，那么在步骤3a中，在SL3处执行操作，并向数据生成器发出响应。

如果RUD请求仅针对单个其它本地SL(例如，SL2)(情况2)，那么：

在步骤3b中，SL3向SL2发出新的RUD请求。

在步骤4b中，SL2执行所请求的操作，并响应SL3；以及

在步骤5b中，SL3使用来自步骤3b的响应，并生成对来自步骤1的请求的RUD响应，该响应被发给数据生成器。

如果RUD请求针对多个本地SL(情况3)：那么

在步骤3c中，SL3向这些本地SL中的每一个发出多个新的RUD请求。

在步骤4c中，每个本地SL执行所请求的操作并响应SL3；以及

在步骤5c中，SL3组合来自步骤3c的所有响应，并生成对来自步骤1的请求的RUD响应，该响应被发给数据生成器。

如果RUD请求针对聚合数据集(即，localSLIdentifier＝“聚合”)(情况4)：

在步骤3d中，SL3使用pastDataSetLink属性确定到先前数据集的链接，并将RUD请求发送到托管SL(pastDataSetLink＝＝到SL2中的聚合数据集的链接)。

在步骤4d中，SL2执行所请求的操作并响应SL3。该响应还包括其pastDataSetLink(＝＝到SL1中的数据集的链接)。

步骤3d：SL3使用pastDataSetLink确定将将来数据集链接到该聚合数据集，并发出另一个RUD请求。这次，RUD请求被发送到SL1。

在步骤4d中，SL1执行所请求的操作并响应SL3。该响应还包括其pastDataSetLink(＝＝NULL)。

在步骤5d中，SL3使用pastDataSetLink(＝＝NULL)作为没有更多数据集链接到该聚合数据集的指示。它组合了所有响应，并生成对来自步骤1的请求的RUD响应，该响应被发给数据生成器。

在情况4中，数据生成器仅提供它向其保存数据集的最后一个SL，而在情况3中，数据生成器提供它向其保存数据集的所有SL的完整列表。对于情况4，SL3可能需要使用pastDataSetLink属性来确定聚合数据集中涉及的本地SL，并且递归地向每个这些本地SL发送新的RUD请求。

一旦数据集存储在M2M/IoT***中(在本地SL中)，数据生成器就可以发起针对数据集中的数据条目、针对特定本地SL中的一个或多个数据集或针对聚合数据集的数据服务。假设数据生成器通过其当前本地SL发起数据服务，并且M2M/IoT***负责确保该服务在正确的本地SL中运行。该过程在图23的调用流程中示出，并在下面进行描述。

在步骤1中，数据生成器向其当前本地SL(SL3)发出dataService请求。数据生成器可以在请求中包括以下属性：

(1)聚合数据集标识符(aggDataSetIdentifier)：例如，aggDataSetIdentifier＝ID1；

(2)本地SL标识符(localSLIdentifier)：如果数据生成器想要针对单个数据集，那么它可以包括localSLIdentifier来识别该数据集。例如，当数据生成器连接到本地SL1时，可以将其设置为“本地SL1”以针对数据集。可替代地，数据生成器可以省略该属性，或使用“聚合”值来指示请求针对的是聚合数据集。在所示的示例中，请求的数据服务是“缺失数据”服务，其中SL监视数据集中的条目以确定是否缺失条目，并采取某种补救措施；

(3)服务身份：应处理数据的服务的身份；以及

(4)服务配置：处理服务所需的任何配置信息。

在步骤2中，SL3管理数据服务请求，并确定受影响的SL。

如果数据服务仅影响当前本地SL(即SL3)(情况1)：那么在步骤3a中，数据服务在SL3开始，并向数据生成器发出响应。

如果数据服务请求仅针对单个其它本地SL(例如，SL2)(情况2)：那么

在步骤3b中，SL3向SL2发出新的数据服务请求；

在步骤4b中，SL2启动所请求的服务，并响应SL3；以及

在步骤5b中，SL3使用来自步骤3b的响应，并生成对来自步骤1的请求的数据服务响应，该响应被发给数据生成器。

如果数据服务请求针对多个本地SL(案例3)：那么

在步骤3c中：SL3向这些本地SL中的每一个发出多个新的数据服务请求；

在步骤4c中：每个本地SL启动所请求的服务并响应SL3；以及

在步骤5c中：SL3组合来自步骤3c的所有响应，并生成对来自步骤1的请求的数据服务响应，该响应被发给数据生成器。

如果数据服务请求针对聚合数据集(即，localSLIdentifier＝“聚合”)(情况4)，那么SL3可能需要使用pastDataSetLink属性来确定聚合数据集中涉及的本地SL。具体处理取决于所请求的数据服务的类型。一些服务是相对静态的。此类服务依赖服务层遍历聚合数据集并执行一次性动作。这些服务在聚合数据集的“快照”上运行。静态数据服务的典型示例包括：确定聚合数据集的最大值、检查聚合数据集中的范围外条目等。可替代地，一些服务可能是非常动态的。当新数据条目添加到聚合数据集时，此类服务依赖服务层来连续监视和执行服务。这些服务不是基于聚合数据集的快照，而是假设聚合数据集随时间而变化(随着新条目被添加以及旧条目被删除和/或到期)。动态数据服务的典型示例包括：确定聚合数据集的运行平均值；当新数据条目存储在聚合数据集中时检查不一致的数据，检查第三方是否已检索到数据集中的任何条目，等等。对于此类动态数据服务，SL3可能需要执行以下一项或多项：

检索聚合数据集中所有数据集的特定属性。例如，在运行平均数据服务的情况下，SL3可能需要检索组成聚合数据集的远程数据集(在示例中为SL1和SL2)每一个中的数据条目的数量和所有条目的总和。这使SL3可以计算运行平均值；以及

订阅当在托管组成聚合数据集的远程数据集的服务层发生某些事件时被通知。因此，例如，如果动态数据服务监视第三方何时检索聚合数据服务中的任何数据条目，那么SL3可能需要订阅SL1和SL2来监视此事件。

对于静态数据服务，该处理类似于SL3处置RUD请求的方式，在此不再赘述。

步骤3d到13d中示出了典型动态数据服务请求的细节(例如，运行平均值)。为了计算运行平均值，SL3可能需要知道每个远程SL中的条目数，以及这些服务层中所有条目的总和。另外，SL3可能还需要知道这些值(数量和总和)中的任何一个是否改变。例如，如果远程SL中的数据集中的数据条目到期，那么这些值可能改变。在这种情况下，条目的数量以及条目的总和都可能改变。因此，SL3可能需要在每个远程SL中检索这些属性，并且需要订阅以在这些属性之一改变时被通知。操作的细节如下所述：

在步骤3d中，SL3使用pastDataSetLink属性来确定到先前数据集的链接，然后将检索请求发送到远程SL(pastDataSetLink＝＝到SL2中的聚合数据集的链接)以获得所需的属性(dataSetNumberEntries、dataSetTotalSum)；

在步骤4d中，SL2执行所请求的操作并响应SL3。响应还包括其pastDataSetLink(＝＝到SL1中的数据集的链接)；

在步骤5d中：SL3将来自SL2的(dataSetNumberEntries,dataSetTotalSum)存储在数据集的本地属性中，使得它们可以被运行的数据服务使用。这些可以存储在数据集的新属性中，其中可以包含：

dataSetPriorSLIdentityList：托管链接到聚合数据集的数据集的服务层的身份列表。对于该示例，dataSetPriorSLIdentityList＝{SL2的身份}；以及

dataSetPriorSLAttributeList：与先前服务层中存储的数据集绑定的并且是运行数据服务所需的属性列表。这可能是复杂的属性。对于所示示例：dataSetPriorSLAttributeList＝{(来自SL2的dataSetNumberEntries的值、来自SL2的dataSetTotalSum的值)}。

在步骤6d中，SL3发出请求，以订阅SL2中的属性(dataSetNumberEntries、dataSetTotalSum)改变时被通知。

在步骤7d中，SL2响应订阅请求。

在步骤8d中，SL3使用从步骤4d中接收到的pastDataSetLink参数来确定链接到该聚合集的其它数据集，并发出另一个检索请求。这次，检索请求被发送到SL1。

在步骤9d，SL1执行所请求的操作并响应SL3。该响应还包括其pastDataSetLink(＝＝NULL)。

在步骤10d中，SL3将来自SL1的(dataSetNumberEntries、dataSetTotalSum)存储在本地属性中。对于所示示例：

dataSetPriorSLIdentityList＝{SL2的身份，SL1的身份}；以及

dataSetPriorSLAttributeList＝{

(来自SL2的dataSetNumberEntries的值，来自SL2的dataSetTotalSum的值)

(来自SL1的dataSetNumberEntries的值，来自SL1的dataSetTotalSum的值)}

在步骤11d中，SL3发出请求，以订阅SL1中的属性(dataSetNumberEntries、dataSetTotalSum)改变时被通知。

在步骤12d中，SL1响应订阅请求。

在步骤13d中，SL3使用来自步骤9d的pastDataSetLink(＝＝NULL)作为没有更多数据集链接到该聚合集的指示。继续运行平均值示例，SL3通过对所有响应求和来确定聚合数据集中的条目的总数和所有条目的总和。另外，SL3可以发送对来自步骤1的dataService请求的响应，该响应被发给数据生成器。

随后，当通知SL3先前数据集中的属性之一已改变时，SL3可以检索新的属性值、更新dataSetPriorSLAttributeList，并且重新评估运行平均值。

值得注意的是，如果SL3具有存储的dataSetPriorSLIdentityList，那么它可以使用dataSetPriorSLIdentityList来确定受影响的SL(在步骤2中)。在这种情况下，当前本地SL无需递归使用pastDataSetLink属性来找到受影响的SL。

数据消费者是与数据集交互但不生成存储在数据集中的条目的任何实体。因此，数据消费者可以检索数据集、删除数据集或在数据集上启动数据服务。值得注意的是，本文未描述方法1(a/b)的数据消费者过程。

方法2的数据消费者过程—在这种方法中，聚合数据集可以始终跟随数据产生者。在一个示例中，聚合数据集始终跟随数据生成者。一旦数据消费者发现SL上的聚合数据集，它就可以向该SL发出检索/删除请求，并且它还可以在聚合数据集上启动一个或多个数据服务。但是，随着数据生成器移动并连接到新的SL，该聚合数据集和在聚合数据集上运行的数据服务都将转移到该新的SL。如果数据消费者已在一个SL上启动数据服务，并且该服务已转移到新的SL，那么可能需要将该转移通知数据消费者。这使数据消费者可以维持对该服务的控制，使得它可以被更新/停止。

这通过下面将进一步描述的图24中的调用流程示出。可以假设数据生成器连接到本地SL(SL1)，并且聚合数据集在SL1处可用。此外，还可以假设数据消费者已在SL1中发现聚合数据集，并已在SL1上启动数据服务。所示的示例服务是监视服务，其中数据消费者请求在数据集中的条目数超过某个阈值(Thresh1)时被通知。

在步骤1中，数据消费者向SL1发出dataService请求。

在步骤2中，SL1启动所请求的服务，并向数据消费者发出dataService响应。

一段时间后，数据生成器失去与SL1的连接，并且连接到SL2。

在步骤3中，将聚合数据集和在该聚合数据集上运行的服务转移到SL2。

在步骤4中，SL2将updateDataService请求发送到数据消费者。该消息可以包括数据服务的标识符以及将托管该服务的新的SL。

在步骤5中，数据消费者更新所请求的数据服务的信息(来自步骤1)，并响应SL2。

在步骤6中，在一段时间之后，数据消费者希望停止数据服务。它向正在管理聚合数据集的当前本地SL发出stopDataService请求。

在步骤7中，本地SL(SL2)停止服务并响应数据消费者。

附加地或可替代地，由于SL1知道服务将被转移到SL2，因此可以由SL1发起步骤4和步骤5中的updateDataService请求/响应交换。

方法3的数据消费者过程。各个数据集可以存储在M2M/IoT***的各种SL中，但是这些数据集中的每个数据集都可以具有允许M2M/IoT***管理聚合数据集的交叉链接。数据消费者可以在本地SL中找到各个数据集中的任何数据集。通过该本地SL，数据消费者可以发出对聚合数据集的检索/删除请求，并且它还可以在聚合数据集上启动一个或多个数据服务。

可以假设数据消费者已在本地SL中找到一个数据集，并且该数据消费者已发出检索或删除整个聚合数据集的请求。由于本地SL不是聚合数据集的当前本地SL，因此当它接收到检索/删除请求时，它可能需要将该请求传播到托管链接到聚合数据集的数据集的过去以及将来的SL。典型的调用流程如图25所示。

可以假设聚合数据集分布在三个本地SL(SL1、SL2和SL3)上。数据生成器连接到SL3，并且这是当前本地SL。还可以假设数据消费者已通过SL2发现了数据，并通过SL2发出了其检索请求或删除请求。为了简单起见，在示例中仅示出了检索请求，但是该处理也适用于删除请求。

在步骤1中，数据消费者向SL2发出检索请求，请求检索aggDataSetIdentifier＝ID1的聚合数据集。

在步骤2中，SL2使用数据集中的链接来递归确定所有受影响的SL。SL2首先使用pastDataSetLink属性来确定到先前数据集的链接，并且然后将检索请求发送到托管SL(pastDataSetLink＝＝到SL1中的聚合数据集的链接)。

在步骤3中，SL1执行所请求的操作并响应SL2。该响应还包括其pastDataSetLink(＝＝NULL)。

在步骤4中，SL2使用pastDataSetLink(＝＝NULL)作为没有更多的先前数据集链接到该聚合集的指示。

在步骤5中，SL2使用futureDataSetLink属性确定到任何将来数据集的链接，并将检索请求发送到托管SL(futureDataSetLink＝＝到SL3中的聚合数据集的链接)。

在步骤6中，SL3执行所请求的操作并响应SL2。该响应还包括其futureDataSetLink(＝＝NULL)。

在步骤7中，SL2使用futureDataSetLink(＝＝NULL)作为不再有将来的数据集链接到该聚合集的指示。它组合了所有响应(从步骤3和步骤6接收)以及它在本地存储的数据集信息，并生成对来自步骤1的请求的检索响应，该响应被发给数据消费者。

一旦数据消费者已(在本地SL中)发现聚合数据集的一部分，它就可以在聚合数据集上发起数据服务。在这种情况下，M2M/IoT***可能必须将服务请求传播到过去和将来的SL、在过去和将来的SL中检索必要的属性，以允许执行所请求的数据服务，并订阅监视过去和将来的SL中的某些事件，以允许执行所请求的数据服务。

本文公开了用于实现对oneM2M体系架构建议的方法/增强的实施例。另外，还公开了一种用于显示和/或配置相关参数和信息的用户界面。所描述的功能可以是新的数据连续性CSF，其处置该处理以处置使得能够与聚合数据集进行交互的任何建议的方法。

图26所示的数据连续性CSF可以在IN-CSE以及MN-CSE和ASN-CSE中找到。该新的CSF支持为本地SL和聚合器SL定义的过程和处理。此外，AE和CSE支持为数据生成器和数据消费者定义的过程和处理。与服务层相关的建议资源和过程可以在CSE中实现。附加地或可替代地，可以在现有的CSF(例如，数据管理和储存库CSF)中实现本文中建议的新功能。

为了实现所描述的数据连续性方法，可能需要将所有请求/响应交换映射到oneM2M CRUDN交换。表2中示出了示例映射：

表2：oneM2M CRUDN交换

/>

/>

新的请求参数—建议以下新的请求参数来实现本文公开的某些功能：

(1)aggDataSetIdentifier：可选参数，用于识别发起者的聚合数据集。发起者可以生成多个数据集。该标识符可以用于区分这些数据集。该标识符可以由发起者分配，并在所有针对聚合数据集的交换中使用。发起者保证其每个数据集都有唯一的标识符。发起者标识符和aggDataSetIdentifier的组合唯一地识别oneM2M***中的聚合数据集。

(2)retargetFlag：用于方法1b的可选参数(M2M/IoT***驱动情况)。它是布尔值，告诉oneM2M***是否应将请求重新定向到聚合器SL；

(3)dataContinuityFlag：用于所有方法的可选参数，用于向当前注册商CSE指示该数据是否要使用数据连续***。例如，它适用于CREATE操作。如果为真(TRUE)，那么当前注册商CSE使用协商好的方法来提供数据连续性；

(4)localSLIdentifier：在所有方法中使用的可选参数。在请求/更新/删除请求中使用它来识别在数据生成器注册到特定CSE时创建的聚合数据集的一部分。聚合数据集可以具有在发起者注册到不同CSE时生成的数据。发起者可以发出具有localSLIdentifier＝CSE1的请求，以告诉托管CSE该请求仅针对数据生成器注册到CSE1时创建的数据集的部分。发起者还可以发出具有localSLIdentifier＝“聚合”的请求，以识别该请求针对的是聚合数据集。在方法1a的创建请求(数据生成器驱动情况)中也使用了该参数，使得聚合器CSE可以记录数据被生产时数据生成器在何处被注册。

(5)priorLocalSLIdentifier：在方法1b(M2M/IoT***驱动情况)和方法2和3中使用的可选参数。它告诉当前注册商CSE有关发起者注册的最后一个CSE的身份。这允许当前注册商CSE查询先前的注册商CSE。

在oneM2M中，数据集被实现为<container>、<flexContainer>或<timeSeries>资源。新属性已被添加到这些资源中，以启用本文描述的功能，如图27所示。<container>、<flexContainer>和<timeSeries>资源可以包含表3中指定的新属性。

表3：用于数据共享资源的新属性

/>

/>

内容实例和时间系列实例资源的新属性(<timeSeriesInstance>和<contentInstance>)-如果<timeSeriesInstance>(或<contentInstance>)资源是聚合数据集的一部分，那么它们可以具有新的localSLIdentifier属性。该属性定义创建<timeSeriesInstance>(或<contentInstance>)时在其上注册数据生成器的CSE。

注册资源的新属性(<AE>和<remoteCSE>)-作为注册过程的一部分，发起者可以发起数据连续***。当oneM2M通过创建<AE>和<remoteCSE>资源来实现注册时，表4列出了启用该初始化的这些注册资源的新属性。

表4：<AE>和<remoteCSE>资源的新属性

/>

数据服务资源的新属性(<subscription>、<container>、<timeSeries>)-当使用方法3时，实现数据服务的每个资源都可能需要维护发起者的先前注册商CSE的属性。例如，如果服务正在运行以限制聚合数据集中内容实例的数量，那么当前注册商CSE可能需要知道在所有先前注册商CSE中存在多少个内容实例。该属性历史可以被存储为数据服务资源的复杂属性的列表。

表5：数据服务资源的新属性

/>

新的虚拟<virDataSet>资源—<virDataSet>是适用于方法1b(M2M/IoT***驱动情况)的虚拟资源。它可以是<CSEBase>资源的子资源。当请求寻址<virDataSet>资源时，托管CSE可以将其用作请求正在针对聚合器SL的指示。托管CSE可以查看附加参数以唯一地识别聚合数据集，并将请求转发到正确的聚合器SL。

基于方法1b的优选实施例的修改后的注册信息流在图28中示出并且在下面进行讨论。假设发起者是AE。

在步骤1中，AE向注册商CSE(CSE1)发出CREATE<AE>请求。<AE>资源包括以下内容：

dataProdType：“心率监测器”；

dataSetID：该AE产生的数据集的标识符(例如，DS001、DS001、DS003)；

dataSetType：dataSetID列表中每个数据集的数据类型(例如，Type1、Type2、Type1)；

dataContSupp和dataContPref：方法1b；以及

dataProdMobInd＝TRUE。

在步骤2中，CSE1确定提供数据连续***的方法。在这个示例中，CSE1选择方法1b，这是AE支持的唯一方法。然后，CSE1为每个数据集选择聚合器CSE，以及可以用于与CSE1交互的虚拟资源的身份(vr001)。在这个信息流中，可以假设Type1的所有数据集存储在CSE10中，并且Type2的数据集存储在CSE11中。然后，CSE创建<AE>资源并设置以下属性：

在步骤3中，可以向IN-CSE通告注册。步骤3是可选步骤，其取决于AE是否要求了向IN-CSE通告其注册。

在步骤4中，CSE1响应CREATE请求。该响应可以包括<virtDataSet>资源的身份。AE可以将该虚拟资源用于与与数据集之一相关的oneM2M***的任何将来交互。

基于方法1b的优选实施例的修改后的CREATE请求信息流在图29中示出并且在下面描述。假设AE已经向CSE1注册，并且它希望为数据集DS001创建内容实例。

在步骤1中，AE向CSE1发出CREATE<container>资源。该资源针对CSE1(vr001)上的<virtDataSet>资源。该请求可以包含以下参数：

dataContinuityFlag＝TRUE；

aggDataSetIdentifier＝DS001；以及

priorLocalSLIdentifier＝NULL

在步骤2中，CSE1使用AE的身份(AE-ID)和聚合数据集标识符(DS001)来确定聚合CSE的地址。该信息位于<AE>资源的addrAggregatorSL属性中。对于这种情况，聚合器CSE为CSE10。

在步骤3中，CSE1将CREATE请求重新定向到CSE10。目标可以被设置为<CSEBase>资源。

在步骤4中，CSE10创建具有以下属性的<container>资源：aggDataSetIdentifier＝DS001。CSE10对CSE1发出CREATE<container>响应。

在步骤5中，CSE1将CREATE<container>响应重新定向到AE。

在步骤6中，AE向CSE1发出CREATE<contentInstance>资源。该资源针对vr001的<container>子资源。该请求可以包含以下参数：

dataContinuityFlag＝TRUE；

aggDataSetIdentifier＝DS001；以及

priorLocalSLIdentifier＝NULL

在步骤7中，CSE1使用AE的身份(AE-ID)和聚合数据集标识符(DS001)来确定聚合CSE的地址。该信息位于<AE>资源的addrAggregatorSL属性中。对于这种情况，聚合器CSE为CSE10。

在步骤8中，CSE1将CREATE请求重新定向到CSE10。

在步骤9中，CSE10创建<contentInstance>资源，并包含以下属性：localSLIdentifier＝CSE1。CSE10向CSE1发出CREATE<contentInstance>响应。

在步骤10中，CSE1将CREATE<contentInstance>响应重新定向到AE。

一段时间后，AE失去与CSE1的连接，并且重新注册到CSE2。作为该重新注册的一部分，IN-CSE可能已向CSE2提供了注册信息流的步骤2中示出的所有信息。可替代地，CSE2可以查询CSE1以找到该信息。后一个选项如下所示。

在步骤11中，AE向CSE2发出CREATE<contentInstance>资源。该资源针对vr001的<container>子资源。该请求包含以下参数：

dataContinuityFlag＝TRUE；

aggDataSetIdentifier＝DS001；以及

priorLocalSLIdentifier＝CSE1。

在步骤12中，CSE2从priorLocalSLIdentifier中观察到AE已先前注册到CSE1。CSE2从CSE1检索<AE>资源。

在步骤13中，CSE2重新创建<AE>资源。

在步骤14中，CSE2使用AE的身份(AE-ID)和聚合数据集标识符(DS001)来确定聚合器CSE的地址(CSE10)。

在步骤15中，CSE2将CREATE请求重新定向到CSE10。

在步骤16中，CSE10创建<contentInstance>资源并包括以下属性：localSLIdentifier＝CSE2。CSE10向CSE2发出CREATE<contentInstance>响应。

在步骤17中，CSE2将CREATE<contentInstance>响应重新定向到AE。

下面描述基于方法1b的用于优选实施例的修改后的RETRIEVE信息流。UPDATE和DELETE请求的过程非常相似。可以假设AE当前已向CSE5注册，并且它希望检索标识符为DS001的整个聚合数据集。该聚合数据集存储在CSE10中的<container>资源中，并且具有在AE向CSE1、CSE2、CSE3、CSE4和CSE5注册时创建的<contentInstance>子资源。

在步骤1中，AE向CSE5发出针对资源vr001的<container>子资源的RETRIEVE请求。该请求包括以下参数：

aggDataSetIdentifier＝DS001；

localSLIdentifier＝“聚合”；以及

priorLocalSLIdentifier＝CSE4

在步骤2中，CSE5使用AE的身份(AE-ID)和聚合数据集标识符(DS001)来确定聚合器CSE的地址(CSE10)；

在步骤3中，CSE5将RETRIEVE请求重新定向到CSE10；

在步骤4中，当localSLIdentifier＝“聚合”时，CSE10检索整个聚合数据集(<container>资源及其所有<contentInstance>子资源)。它准备表示形式并向CSE5发出RETRIEVE<container>响应；

在步骤5中，CSE5将RETRIEVE<container>响应重新定向到AE。

图31示出了示例图形用户界面(GUI)。可以将用户界面添加到AE，例如，以向CSE查询与聚合器数据集(例如，聚合器SL)相关的信息、检查是否为AE激活了数据连续性支持，或为数据连续性提供配置信息(所支持的方法、优选方法、数据生成器类型等)。可以将用户界面添加到CSE，例如，以向另一个CSE查询与聚合器数据集(例如，聚合器SL)相关的信息、查询特定聚合数据集(或所有聚合数据集)的mappingInfo、显示特定聚合数据集(或所有聚合数据集)的链接信息，并且配置用于数据连续***发起的策略。

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

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

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

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

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

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

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

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

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

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

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

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

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

此外，虽然发送/接收元件36在图32C中被描绘为单个元件，但是网络装置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之一的互连接口)连接到这种装置或设备的其它部件、模块或***。

图30是示例性计算***90的框图，该示例性计算***90还可以用于实现网络的一个或多个网络装置，诸如图1、3-26和28-30中所示并且在本文描述的实体，其可以作为M2M网络中的M2M服务器、网关、设备或其它网络装置(诸如图32A和32B中所示的网络装置)操作。

计算***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可以生成并操作图31及其随附的描述中所示并描述的图形用户接口。

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

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

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

ADN 应用专用节点

AE 应用实体

API 应用编程接口

App 应用

ASM 应用和服务层管理

ASN 应用服务节点

BP 分支点

CMDH 通信管理和递送处置

CRUD 创建、检索、更新和删除

CSE 公共服务实体

CSF 公共服务功能

DIS 发现

DMR 数据管理和储存库

HTML 超文本标记语言

HTTP 超文本传输协议

IN 基础设施节点

IoT 物联网

IP 互联网协议

LOC 位置

M2M 机器对机器

MN 中间节点

NSE 底层网络服务实体

NSSE 网络服务公开、服务执行和触发

REG 注册

ROA 面向资源的体系架构

SC 服务能力

SCA 服务收费和计费

SEC 安全性

SL 服务层

SUB 订阅和通知

UDP 用户数据报协议

URI 统一资源标识符

XML 可扩展标记语言

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

/>

/>

/>

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

Claims (20)

1.一种由在通信网络的装置上实现的第一服务层实体在机器对机器/物联网M2M/IoT***中执行的方法，所述方法包括：

从计算设备接收数据连续***请求，其中所述数据连续***请求包括与计算设备相关联的信息；

基于数据连续***请求确定配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

从计算设备接收执行数据操作的请求，其中执行数据操作的所述请求识别与第一服务层实体相关联的虚拟资源；以及

将对数据的至少一部分执行数据操作的请求重新定向到第二服务层实体。

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

向计算设备发送所述数据的至少一部分被存储在第二服务层实体处的指示。

3.如权利要求2所述的方法，其中所述数据的至少一部分被存储在第二服务层实体处的指示包括第二服务层实体的标识符。

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

从第二服务层实体接收响应，所述响应指示已经对所述数据的至少一部分执行数据操作；以及

向计算设备发送已经对所述数据的至少一部分执行数据操作的指示。

5.如权利要求1所述的方法，其中所述计算设备被预先配置有与虚拟资源相关联的信息。

6.如权利要求1所述的方法，还包括：基于配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体，发送与虚拟资源相关联的信息。

7.如权利要求1所述的方法，其中执行数据操作的请求包括执行与所述数据相关联的创建、更新、检索或删除操作中的一个或多个的请求。

8.一种在机器对机器/物联网M2M/IoT***中的装置(90)，所述装置包括处理器(91,81)和存储器(82,93)，所述存储器存储计算机可执行指令，所述计算机可执行指令在由所述处理器执行时实现通信网络(10)的第一服务层实体，并使所述第一服务层实体执行包括以下的操作：

从计算设备接收数据连续***请求，其中所述数据连续***请求包括与计算设备相关联的信息；

基于数据连续***请求确定配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

从计算设备接收执行数据操作的请求，其中执行数据操作的所述请求识别与第一服务层实体相关联的虚拟资源；以及

将对数据的至少一部分执行数据操作的请求重新定向到第二服务层实体。

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

向计算设备发送所述数据的至少一部分被存储在第二服务层实体处的指示。

10.如权利要求9所述的装置，其中所述数据的至少一部分被存储在第二服务层实体处的指示包括第二服务层实体的标识符。

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

从第二服务层实体接收响应，所述响应指示已经对所述数据的至少一部分执行数据操作；以及

向计算设备发送已经对所述数据的至少一部分执行数据操作的指示。

12.如权利要求8所述的装置，其中所述计算设备被预先配置有与虚拟资源相关联的信息。

13.如权利要求8所述的装置，其中所述指令在被执行时还使所述第一服务层实体执行包括以下的操作：基于配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体，发送与虚拟资源相关联的信息。

14.如权利要求8所述的装置，其中执行数据操作的请求包括执行与所述数据相关联的创建、更新、检索或删除操作中的一个或多个的请求。

15.一种包括计算机可执行指令的计算机可读存储介质，所述计算机可执行指令在由在机器对机器/物联网M2M/IoT***中的装置的实现通信网络的第一服务层实体的处理器执行时，使所述第一服务层实体执行包括以下的操作：

从计算设备接收数据连续***请求，其中所述数据连续***请求包括与计算设备相关联的信息；

基于数据连续***请求确定配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体；

从计算设备接收执行数据操作的请求，其中执行数据操作的所述请求识别与第一服务层实体相关联的虚拟资源；以及

将对数据的至少一部分执行数据操作的请求重新定向到第二服务层实体。

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

向计算设备发送所述数据的至少一部分被存储在第二服务层实体处的指示。

17.如权利要求16所述的计算机可读存储介质，其中所述数据的至少一部分被存储在第二服务层实体处的指示包括第二服务层实体的标识符。

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

从第二服务层实体接收响应，所述响应指示已经对所述数据的至少一部分执行数据操作；以及

向计算设备发送已经对所述数据的至少一部分执行数据操作的指示。

19.如权利要求15所述的计算机可读存储介质，其中所述计算设备被预先配置有与虚拟资源相关联的信息。

20.如权利要求15所述的计算机可读存储介质，其中所述指令在被执行时还使所述第一服务层实体执行包括以下的操作：基于配置用以对与计算设备相关联的数据执行数据操作的第二服务层实体，发送与虚拟资源相关联的信息。