CN109313587B - 用于在服务层处使能数据分析服务的方法 - Google Patents

Abstract

在服务层处的公共数据分析服务(DAS)被设计使用底层现有/未来数据分析技术或者工具并且利用统一接入方法将它们提供给需要那些数据分析操作的服务层实体。通用操作框架/接口设计用于使能DAS和DAS内的操作细节。可以使用包括服务层请求/响应消息中的新参数的用于与DAS交互的有关程序。

Description

用于在服务层处使能数据分析服务的方法

相关申请的交叉引用

本申请要求于2016年4月25日提交的美国临时专利申请序列号62/326,881的权益，其公开内容通过引用而并入，如同完整在此阐述。

背景技术

在最近几年中，在我们世界中的数据量正在激增。谷歌处理几百拍字节(Petabyte，PB)的搜索数据并且脸书生成每月超过10PB的日志数据(大数据***调查，survey on big data systems，中国科学信息科学，SCIENCE CHINA InformationSciences,2015)。作为激增的全球数据的结果，术语“大数据”已经被创造以描述庞大的数据集。与传统数据集相比，大数据可以包括大量非结构化数据，其需要被分析以便从该数据获得深入见解，例如如何从客户的购物历史记录中发现潜在购买。

麦肯锡公司具有大数据的更正式定义，如下：“大数据应当指通过经典数据库软件不能获得、存储并且管理的这种数据集”。该定义包括两种含义：

-符合大数据的测量/标准的数据集规模正在改变并且随着时间或者随着技术进步而增长。目前，大数据通常从几太字节(Terabyte)到几拍字节。

-在不同应用中符合大数据的标准的数据集规模彼此不同。

参照几个“V”(如图1所示)的大数据的另一种流行定义：

-巨量性(Volume)意味着：随着大量数据的生成和收集，数据规模变得越来越大，例如，如在早些的示例中提及的，由互联网公司生成的数据可以容易达到每天十PB。

多样性(Variety)指示各种类型的数据，其包括半结构化数据和非结构化数据，诸如，音频、视频、网页和文本以及传统明确定义的结构化数据像数据库表。

-即时性(Velocity)意味着大数据的时效性，特别地，数据收集和分析等必须快速并且以及时方式完成，以便最大化大数据的商业价值。

-价值(Value)意味着存在于该数据中但以非常低密度隐藏的有用知识/见解。

此外，更多“V”可以被定义，例如：真实性(Veracity)应对不确定的或者不精确的数据等。

当前，由于潜在的新的业务和价值，各行各业正在对大数据的高潜力更感兴趣，并且许多政府机构以及学术界已经宣布了加速大数据研究和应用的主要计划。

值得注意的是，物联网(IoT)的出现是驱动大数据的增长的主要趋势，物联网(IoT)通常指的是例如嵌入在物理世界并且通过网络连接到计算资源的传感器和设备。

如图2所示，麦肯锡研究预计在世界中部署的连接的IoT节点的数量被期望以每年超过30％的速率增长。期望增长部门中的一些是公用事业，因为这些运营商安装更多智能仪表和智能家电；医疗保健，因为该部门部署远程健康监测；零售，其将最终增加射频识别(RFID)标签的使用；以及汽车行业，其将在车辆中越来越多地安装传感器。

大数据的价值链可以一般被分成四个阶段：数据生成、数据采集、数据存储和数据分析(参见图3)。如果我们把数据作为原料，则数据生成和数据采集是开发过程，数据存储是存储过程并且数据分析是利用原料创造新价值的生产过程。在下面呈现了针对这四个阶段中的每一个的简要介绍。

数据生成是大数据的第一步骤。如早些提及的，大量数据被生成。例如，搜索条目，网络论坛帖子，聊天记录以及微博消息。而且，复杂且高度多样性质的大规模数据可以通过分布式数据源被生成。这种数据源包括尤其是来自IoT/M2M***的传感器、视频、点击流和/或所有其它可用的数据源。

数据采集是大数据***的第二阶段。大数据采集包括数据收集、数据传输等。在大数据采集期间，需要有效传输机制以便向适当的存储管理***发送数据以支持不同的分析应用。收集到的数据集有时可能包括大量的冗余的或者无意义的数据，其不必要地增加了存储空间并且影响随后的数据分析。例如，高冗余度在由用于环境监测的传感器收集的数据集中是非常普遍的。数据压缩技术可以被应用以减少该冗余度。

第三阶段，即大数据存储，指的是大规模数据集的存储和管理，同时实现数据存取的可靠性和可用性。典型地，它处理大量的、可扩展的并且普遍分布式的存储***。一方面，存储基础架构需要提供可扩展的且可靠的信息存储服务；另一方面，它必须为大量数据的查询和分析提供强大的接入接口。

第四阶段是关于数据分析。大数据的分析主要涉及应用于收集到的数据的分析方法。数据分析是大数据的价值链中的最重要阶段，目的是为了提取有用价值，提供业务运作的见解等。不同水平的潜在价值可以通过数据集在不同领域的分析来生成。因此，值得注意的是，数据分析是宽泛的范围或者概念，其频繁改变并且极其复杂，如在图3中示例。

下面简要讨论市场上的大量现存数据分析产品。这些产品未必与服务层概念相关。

谷歌分析(Google Analytics)是由谷歌提供的免费网络分析服务，其跟踪并且报告网站流量。谷歌分析利用“页面标签”实现，并且依赖于专有谷歌分析跟踪代码(当前称为Analytics.js)，其是网站所有者将其增加到网站的每页的JavaScript代码的片段。然后，如果在浏览器中启用JavaScript，则当客户端浏览该页时，跟踪代码在客户端浏览器中运行。该代码收集访问者数据并且将其发送给谷歌数据收集服务器。用户在谷歌分析平台中首先注册并且设置用户账号。用户账号的细节也将被包括在Analytics.js代码中，使得由跟踪代码收集的数据可以被发送到正确的用户账号。图4示出谷歌分析的通用架构。

当前，谷歌分析为三种不同的应用场景提供分析服务：

1)网站和网络应用，其使用上面提及的analytics.js收集在网站或者网络应用上的用户行为数据(如图4所示)；

2)移动应用，其利用由谷歌分析提供的API或者样本代码收集与在安卓或者iOS平台上运行的移动应用有关的各种数据；

3)其它应用场景，谷歌分析也为任何实体(例如IoT设备)提供测量协议以将数据发送到谷歌分析服务器。

更进一步，除了由谷歌分析收集的数据之外，当从诸如企业数据库或者客户关系管理(CRM)***的多个源挖掘数据时找到深入/隐藏的见解也是可能的。因此，现在谷歌交付了Google Analytics Premium和Google BigQuery集成。通过从Google AnalyticsPremium到Google BigQuery集成自动导入日志，用户可以容易写入SQL查询来将他们网站访问者活动与其它有价值业务数据(诸如销售点记录、在线购物历史和用户登陆日志)相关。使用对他们的客户的这种组合的见解，用户可以然后生成针对谷歌关键字广告(GoogleAdWords)和双击(DoubleClick)的定制广告再营销数据。

IBM最近宣布沃森分析(Watson Analytics)，基于自然语言的数据分析产品。沃森分析给用户提供不复杂的高级分析的益处。例如，它允许非专家人员进行由沃森分析辅助的各种数据分析，例如从加载数据、研究数据、对数据做出预测并且启用用于虚拟化分析结果的容易的仪表盘(dashboard)和信息图创建。同时，它允许用户通过仅仅以人类可理解的自然语言键入问题来分析他们上传的数据，并且沃森分析的自然语言处理代理将给用户自动提议令人满意的分析工作。

图5示出了IBM沃森分析的简况。值得注意的是，该产品的目标客户是人类用户，并且它不被具体设计用于支持M2M/IoT场景中的数据分析，这是该工作的焦点。

除了上述沃森分析之外，IBM还具有另一种类型的产品，被称为沃森开发者云(Watson Developer Cloud)，其是使用人工智能技术进行更复杂分析任务的REST API和软件开发包(SDK)的专有集合。图6示出由沃森开发者云提供的可用数据分析服务。例如，针对视觉识别服务，用户可以基于由沃森云提供的API规范利用有效负荷中的图像将HTTP请求发送到分析端点。视觉识别服务将通过使用机器学习技术来分析该图像的视觉外观并且给用户返回分析结果，其包含图像中描绘的可能内容的列表以及与这些可能性中的每一个相关的置信度。

微软Azure是由微软创建的云计算平台和基础架构，以用于通过微软管理的全球网络和微软参与者托管的数据中心来构建、部署并且管理应用和服务。具体地，Azure提供与数据分析有关的多种不同类型的服务，诸如微软机器学习服务、流分析以及HDInsight。由微软Azure使用的与数据分析有关的服务的基础架构在图7中示出，并且它与M2M/IoT场景高度有关，因为M2M/IoT***中的大部分数据将是数据流。在下面，我们提供针对这些数据分析服务中的每一个的简要介绍。

微软Azure机器学习服务：通常，机器学习使用计算机运行从现有数据学习的预测模型以便预测未来行为、结果和趋势。Azure机器学习是强大的基于云的预测分析服务，其能够快速创建并且部署预测模型作为分析解决方案。Azure机器学习提供用于在云中创建完整预测分析解决方案的工具：快速创建，测试，实施并且管理预测模型，并且用户不需要购买任何硬件也不需要手动管理虚拟机。值得注意的是，该服务仍然是针对人类专业人员以促进他们机器学习有关的任务。

微软Azure流分析：流分析服务在云中对流数据提供了低延迟、高可用性、可扩展的复杂事件处理。Azure流分析是成本高效的实时事件处理引擎，其帮助从数据解锁深入见解。微软Azure流分析能够容易建立对来自设备、传感器、网站、社交媒体、应用、基础架构***等的数据流(由其它公司开发的类似产品包括SQL流和IBM InfoSphere流等)的实时分析处理。例如，利用Azure门户的几次点击，用户可以通过指定流数据的输入源、以类似SQL语言表达的数据分析处理任务以及针对流分析工作的结果的输出汇聚点来创建流分析工作。与之前的机器学习服务(其更集中于用于在成批处理方面进行预测分析的传统方式，即数据在被处理之前首先被收集在一起)相比，流分析范例更强调进行运行中的数据分析操作，即数据随着他们流过数据分析引擎而被分析。

微软HDInight：Apache Hadoop是以Java编写的开源软件框架以用于非常大的数据集在从商用软件构建的计算机簇上的分布式存储和分布式处理(参见稍后部分中的更多细节)。它是与大数据有关的应用的实际上大规模数据处理基础架构。因此，许多公司在Hadoop框架之上构建了它们的各种数据分析有关的服务(即，Hadoop***是后端基础架构)。此外，为了有助于旨在利用Hadoop工作的那些专业人员，许多公司从它在云中部署并且供给Apache Hadoop簇的角度来讲提供基于云的Hadoop分布，从而提供被设计用于高可靠性和可用性地管理、分析并且报告与大数据有关的任务的软件框架，诸如微软HDInight(即用户不需要购买任何软件也不需要手动管理虚拟机或者任何其它资源，他们仅仅需要通过利用由微软Azure云平台提供的HDInsight服务提供的服务来实现这些)。

除了由主要软件公司(尽管他们中的一些未直接设计用于M2M/IoT场景)提供的以上数据分析服务之外，也存在一些面向IoT的平台，其可以装备有某种数据分析能力。

英特尔IoT平台是端对端参考模型并且来自英特尔的产品族，其利用第三方解决方案工作以为无缝地并且安全连接的设备提供基础，递送可信的数据到云，并且通过分析递送价值。具体地，英特尔为IoT提供基于云的分析***，其包括由英特尔IoT开发工具提供的资源，以用于传感器数据的收集和分析。使用该服务，IoT开发者具有快速启动数据采集和分析的能力而不必投资大规模存储和处理能力。

图8示出英特尔IoT分析的通用架构，其中，它的IoT开发工具允许用户配置边缘设备(例如英特尔的伽利略(Galileo)/爱迪生(Edison)设备)并且将数据发送到其中可以进行数据分析任务的集中式云平台。开发者还可以通过膝上型电脑接入并且配置云中的IoT分析账户。

图9示出英特尔IoT分析的用户仪表盘，其中用户可以进行与不同分析有关的任务，例如，监测从传感器(或者其它边缘设备)发送的数据，配置或者控制边缘设备。

其它公司，诸如Cumulocity、Xively、Keen.io等，提供与英特尔IoT平台类似的服务或者产品。值得注意的是，从这些公司中的每一个具有他们本身的开发工具、API规范和文档等的角度来讲，由此那些服务和产品中的大部分都是基于专有解决方案。

Apache Hadoop是用于大数据集在商业硬件上的分布式存储和处理的开源框架。Hadoop使得业务能够从大量的结构化数据和非结构化数据中快速获得见解。

许多的Apache软件基础项目组成了由企业需要的服务，以利用Hadoop部署、集成并且工作。每个项目均是为了明确的功能而被开发且每个具有其本身的开发者的社区和个体发布周期。图10示出Apache Hadoop生态***的概述。

如早些提及的，Hadoop生态***是与大数据有关的应用的实际上大规模数据处理基础架构，并且许多公司在Hadoop框架之上构建他们的与各种数据分析有关的服务或者产品。例如，公司可以向其用户提供天气预报服务，其中，这些服务通过简单的RESTful接口向用户公开。用户可以仅仅将超文本传输协议(HTTP)请求发送到服务门户以获得天气预报，而不知道与该预报如何完成有关的任何细节(在这些情况中，公司可以利用后端上的Hadoop基础架构来处理大数据以便做出天气预报)。

在图11中示出了典型的机器对机器(M2M)***架构，其中，M2M区域网络1102提供M2M端设备和M2M网关(GW)1104之间的连接性。M2M区域网络的示例包括基于诸如IEEE802.15、Zigbee、蓝牙等技术的个人区域网络。M2M端设备与M2M GW通信，并且最后与M2M服务器1106通信，允许与外部网络和应用***交互和/或对接。大百分比的M2M设备是资源受限实体，其提供服务，诸如报告感觉信息(例如湿度、温度等)或者用作控制器(例如灯开关)。然而，还存在多个资源丰富实体，例如具有电源的家用电器、移动电话、车辆以及其它工业设备。

从协议栈角度，服务层1202典型位于应用协议层1206之上并且将增值服务(例如设备管理、数据管理等)提供给应用1204(参见用于图示的图12)或者提供给另一个服务层。因此，服务层通常被分类为“中间件”服务。

在图13中示出了在网络内实例化的M2M/IoT服务层的示例部署。在该示例中，服务层实例是服务层的实现。多个服务层实例被部署在各个网络节点(即网关和服务器)上以用于将增值服务提供给网络应用、设备应用以及提供给网络节点本身。最近，多个工业标准组织(例如oneM2M oneM2M-TS-0001,oneM2M Functional Architecture-V-2.3.0)已经正在开发M2M/IoT层来解决与M2M/IoT类型的设备和应用集成到诸如因特网、蜂窝网络、企业网络和家庭网络的部署中关联的挑战。

M2M服务层可以给应用和设备提供对面向M2M的服务能力的集合的接入。这些能力的多个示例包括安全、计费、数据管理、设备管理、发现、供给以及连接性管理。经由使用M2M服务层定义的消息原语的应用编程接口(API)使这些能力对应用可用。

oneM2M的目标在于开发技术规范，其解决对可以容易嵌入在硬件装置和软件模块内以便支持本领域中的各种设备的公共服务层的需要。oneM2M公共服务层支持一组公共服务功能(CSF)(即服务能力)，如图14所示。一组一个或者多个特定类型的CSF的实例化被称为公共服务实体(CSE)1402，其可以托管在不同类型的网络节点上(例如，基础架构节点(IN)和中间节点(MN)，以及应用特定节点(ASN))。这些CSE分别被称为IN-CSE、MN-CSE和ASN-CSE，如在oneM2M-TS-0001、oneM2M Functional Architecture-V-2.3.0中定义。CSE1402将服务能力提供给其它CSE以及提供给应用实体(AE)1404。通常，AE 1404表示用于端对端M2M解决方案的应用逻辑的实例化，并且AE 1404的示例可以是运输队跟踪应用、远程血糖监测应用、电能计量应用或者控制应用的实例。

起初，从不同资源在oneM2M ROA RESTful架构内定义的角度来讲，oneM2M服务层被开发以符合面向资源的架构(ROA)(oneM2M-TS-0001、oneM2M FunctionalArchitecture-V-2.3.0)设计原则(如图15所示)。资源在该架构中是唯一可寻址的元素，并且可以经由RESTful方法，诸如创建、检索、更新和删除，操作。这些资源使用统一资源***(URL)而是可寻址的。资源可以包含(一个或多个)子资源和(一个或多个)属性。

最近，oneM2M已经开始开发M2M服务组件架构(如图16所示)，以考虑不是基于RESTful的部署。该架构首先适合于其中CSE 1402被视为一组服务组件的基础架构域。它主要再用图15中示出的现有服务层架构，但是在该服务层内，它将各种M2M服务和多个服务组织成服务组件。除了现有参考点之外，面向服务的架构(SOA)架构引入服务间参考点Msc。(通过Msc参考点的)M2M服务组件之间的通信利用网络服务方法，其是用于构建基于SOA的软件***的最流行技术。

发明内容

在服务层处的公共数据分析服务(DAS)被设计成使用底层现有/未来数据分析技术或者工具并且利用统一接入方法将它们提供给需要那些数据分析操作的服务层实体。通用操作框架/接口设计可以使能DAS和DAS内的操作细节。用于与DAS交互的有关程序可以包括服务层请求/响应消息中的新参数。

用于使能DAS的通用操作框架定义DAS在服务层处如何工作。DAS内的操作细节和功能性设计允许不同类型的数据分析能力(诸如基本数据统计、信息提取、图像处理等)被增加到DAS并且通过由DAS公开的统一接口向DAS的客户端(即AE或者CSE)公开。

特别地，针对增加到或者***到DAS的给定类型的底层数据分析操作，服务类型简档(STP)被定义以指定其对应统一接口的详细信息和接入信息。

描述了用于与DAS交互的多个程序。这些程序通常应用于四种不同的情况/场景：

情况1：DAS的客户端首先获得其目标/感兴趣的待分析的原始数据并且然后将其发送到DAS以用于分析。

情况2：客户端将直接要求DAS进行某种数据分析操作并且DAS代表客户端检索目标/感兴趣的待分析的原始数据。

情况3：考虑到在该情况中的大数据场景的上下文中的大/巨大数据规模，代替移动数据到某个DAS以用于处理，数据分析处理被移动到更靠近该目标数据的DAS。

情况4：用于与DAS交互的基于订阅的范例被定义以便考虑M2M/IoT***的典型特征。

新服务DAS可以被体现为在服务层处的新CSF以用于提供公共数据分析服务。新的oneM2M资源也已经被定义以用于表示STP。

还描述了用于在DAS中支持实时监测和配置的用户接口。

提供本发明内容以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不局限于解决在本公开的任何部分中所指出的任何或所有缺点这样的限制。

附图说明

可以结合附图从通过以示例的方式所给出的以下描述得到更详细的理解，其中：

图1是图示大数据的定义的图。

图2是图示物联网(IoT)增长的图。

图3是图示大数据的价值链的图。

图4是图示谷歌分析的通用架构的图。

图5是图示IBM沃森分析的简况的图。

图6是图示由IBM沃森开发者云提供的RESTful分析服务的图。

图7是图示由微软Azure使用的与数据分析有关的服务的架构的图。

图8是图示英特尔IoT分析服务的通用架构的图。

图9是图示英特尔IoT分析服务的用户仪表盘的图。

图10是图示Apache Hadoop生态***的概述的图。

图11是图示M2M***/网络架构和服务的图。

图12是图示支持服务层的示例性协议栈的图。

图13是图示对网络内的M2M/IoT服务层部署进行图示的示例的图。

图14是图示oneM2M服务层中的公共服务功能(CSF)的图。

图15是图示oneM2M服务层面向资源的架构的图。

图16是图示oneM2M服务组件架构的图。

图17是图示对在服务层中存储的高速公路图像(非结构化数据)进行图示的使用情况的图。

图18是图示数据分析服务(DAS)服务的通用操作框架的图。

图19是图示DAS服务的高级操作流的图。

图20是图示DAS服务的操作细节和功能设计的图。

图21是图示用于与DAS服务交互的第一程序的流程图。

图22是图示用于与DAS服务交互的第二程序的流程图。

图23A至图23B是图示用于与DAS服务交互的第三程序的流程图。

图24A至图24B是图示用于与DAS服务交互的第四程序的流程图。

图25是图示用于oneM2M服务层的新的DAS CSF的图。

图26是图示STP oneM2M资源的图。

图27是图示DAS oneM2M资源的图。

图28A至图28B是图示用于监测DAS服务的GUI界面的图。

图29A是包括通信网络的M2M/IoT/WoT通信***的图。

图29B是为M2M应用、M2M网关设备和M2M终端设备和通信网络提供服务的场域中的所图示的M2M服务层的图。

图29C是可以用于实施本文所述的网络节点中的任一个的示例性设备的图。

图29D是可以用于实施本文所述的网络节点中的任一个的计算机***或者服务器的框图。

具体实施方式

在市场上已经存在不同类型的可用的数据分析服务。具体地，由于数据分析从它可以是指不同形式/类型的分析任务/操作的角度来讲是广泛的概念，所以这些现有的数据分析服务可以提供不同功能。此外，这些分析服务中的一些具体地被设计以有助于人类用户的手动操作而其它在例如M2M/IoT***的上下文中集中于自动分析处理。

现有oneM2M服务层不具有用于使能“公共数据分析服务”的能力。具体地，下面讨论了当这种公共数据分析服务从服务层丢失时的潜在问题和缺点以及针对这种服务的需要。

今天，大部分端点(AE/CSE)从服务层可访问的数据(尤其是针对非结构化数据，诸如图像、文档/日志等)中不能提取内在信息，这具有对在服务层处的公共数据分析服务的需要。

一方面，如上面引入，各种类型的数据，诸如半结构化数据和非结构化数据(诸如音频、视频、网页和文本)或者结构化数据(诸如在数据库表中存储的那些)，可以共存在***中。这在M2M/IoT***(其是驱动大数据增长的主要趋势)的上下文中更是如此。预测到从M2M/IoT***中生成的超过70％的数据将是非结构化数据，诸如由户外监测相机捕获的图像。

另一方面，M2M/IoT***通常由不同类型的端点组成，诸如M2M***内的或者来自因特网的应用/设备/台式电脑等。因此，不同端点可能不具有理解由IoT设备生成的一条数据的相同能力。例如，尤其是对于资源受限节点，一些端点不能具有数据分析能力/引擎。图17示出图示该问题的使用情况。

如图17所示，在I-276高速公路(具有65mph的限速)的出口28处的无线交通监测相机1702正在捕获图像并且将它存储在MN-CSE(网关)1704处的<contentInstance>资源中。由于这种图像是一条非结构化数据，所以智能手机(或者任何其它端点或者服务实体，例如AE/CSE)可能能够访问该<contentInstance>资源，但是它不能真实理解该图像中的信息，例如，当前天气是晴朗或者当前道路交通是非常好的(行进速度可以超过每小时50英里)等。值得注意的是，在没有对该图像的某种数据分析处理(例如在该情况中的图像处理)的情况下，这种内在信息不能被直接得到。不幸地，大部分的M2M/IoT端点或者服务层实体本身未装配有这种数据分析能力。而且，不存在在服务层处定义的这种公共数据分析服务。因此，从服务层的角度来看，可以看到许多潜在价值被埋藏在在服务层中存储的原始数据并且不能以有效方式被用来服务服务层实体。

此外，代替期望AE具有它们本身的数据分析能力，服务层期望能够使能“公共”数据分析服务，其不仅简化对各种端点和AE的功能设计要求而且对资源或者能力共享有益。

即使服务层可以***外部数据分析能力，但是不存在允许端点(AE和CSE)接入各种数据分析服务的统一接口，除非它们遵循相应的专有API规范。

虽然在市场上存在不同类型的可用的数据分析服务，但是那些服务和解决方案中的大部分在那些解决方案中的每一个具有他们本身的开发工具、API规范和文档等的角度来讲是专有解决方案。然而，通常，服务层端点(AE/CSE)将不知道接入第三方数据分析服务的专有接口。由于横向服务层(诸如oneM2M)旨在提供公共服务功能(CSF)，所以必须通过提供公共数据分析服务来将统一操作接口公开于服务层实体。换言之，利用不同类型的数据分析能力来无论如何使能服务层(或者利用现有的外部数据分析服务作为底层技术或者在CSE中***某种数据分析模块)，需要从服务层实体(例如AE/CSE)密封或者隐藏所有那些内部细节。例如，它可以增加更大灵活性来利用任何第三方数据分析服务而不需要担心这些服务中的每一个的复杂性。(这是服务层如何利用现有/底层设备管理技术的类似方法)。

此外，不存在与如何在M2M/IoT***的上下文中使能(配置，使用，控制等)数据分析服务有关的可用程序设计。

来自数据分析和数据通信二者的机制可以使能M2M/IoT中的数据分析能力。例如，假设已经利用公共数据分析服务使能了服务层，仍然存在关于在程序设计方面如何与该服务交互(例如如何接入、配置并且控制该服务等)的问题。这是因为M2M/IoT***严重地依赖于有效通信程序来实现某种功能。然而，这不是集中于数据分析的服务提供商的主要焦点。因此，需要设计新程序以便有效支持公共数据分析服务和该服务的用户/客户端之间的交互。

如之前提及的，服务层由于M2M/IoT***中的大数据的内在特征而需要数据分析能力。因此，在服务层处增加了数据分析服务功能以便满足这种需要。

在oneM2M的上下文中描述了示例以图示详细方法和程序。然而，这些理念不限于oneM2M并且可以推广到具有类似功能或者需要的任何服务层。

图18示出DAS 1802的通用操作框架。在该示例中，DAS 1802由CSE 1804提供作为公共服务功能并且它可以根据来自各种实体(例如AE或者其它CSE)的请求而对目标/感兴趣的(原始)数据进行某种数据分析操作。由于DAS 1802是服务层处的公共服务，所以那些待分析的原始数据例如被存储在由oneM2M定义的现有<contentInstance>资源中是可能的。因此，托管待分析的数据的CSE被称为“数据托管CSE”1806并且托管DAS的CSE被定义为“DAS托管CSE”1804。此外，需要由DAS提供的数据分析操作的那些实体被定义为“DAS客户端”1808。在更一般的情况下，值得注意的是，如果待分析的原始数据与DAS 1802处于同一位置，则一个CSE节点可以作为数据托管CSE 1806和DAS托管CSE 1804二者。同时，那些实体之间的交互可以发生在mca/mcc/mcc’参考点，如图18所示。

此外，DAS 1802可以装备有各种分析能力。数据分析是广泛的范围，并且许多类型的数据处理操作可以被分类为“数据分析服务”。例如，在简化情况中，基本数据统计服务可以用于对一组原始数据(例如传感器读数)做数学上的数据聚合操作，诸如最大、最小、平均等。另一个示例，当AE需要从图像获得有用信息时，如果该AE不具有这种能力，则图像处理操作可以由DAS提供。当需要从JSON文档、日志记录或者网页等中提取有用数据项目时，使用信息提取技术。因此，一方面，那些不同类型的数据分析操作将是DAS 1802可以利用现有各种数据分析技术/工具作为插件或者输出到用于提供那些数据分析操作的某些外部服务门户的常用服务。另一方面，DAS 1802本身可以通过提供统一接口(如图18所示)并且从其隐藏DAS 1802的底层复杂性而向其DAS客户端1808提供公共数据分析服务。值得注意的是，通过提供这种特征，服务层实体(例如AC/CSE)将仅仅需要与DAS 1802交互作为DAS 1802的客户端1808，替代必须处理专有数据分析应用的所有底层细节。

应当理解，图18中示出的功能可以以在M2M网络的节点或者装置(例如服务器、网关、设备或者其它计算机***)(诸如下面描述的图29C或者图29D中图示的那些中的一个)的存储器中存储的并且在M2M网络的节点或者装置的处理器上执行的软件(即计算机可执行指令)的形式实施。

图19示出如在图18中定义的多个实体之间的高级操作流。图19包括四个主要阶段。这四个阶段中的每一个可以包括一个或者多个服务层请求/响应消息，并且当描述相关程序时，稍后将说明那些细节。

在图19中，首先，DAS客户端1808向DAS托管CSE1804初始化用于对其目标/感兴趣的数据的某些数据分析操作的请求(由图19中的阶段1所示)。然后，数据摄取过程(图19中的阶段2)将待分析的数据输入到DAS 1802中。通常，对应的数据托管CSE 1806将递送原始数据到DAS托管CSE 1804。可替换地，DAS客户端1808可以首先由其本身检索原始数据并且将其包括在发送到DAS托管CSE 1804的请求的有效负荷中也是可能的。在这种情况下，阶段1和2组合在一起。在通常发生在DAS 1802之内的阶段3期间，DAS 1802选择适当的底层分析技术来进行由DAS客户端1808请求的特定数据分析操作。那些底层数据分析技术的工作细节可以从DAS客户端1808中隐藏或者提取。最后，一旦DAS 1802得出分析结果，它就可以经由统一接口将该结果递送到DAS客户端1808(图19中的阶段4)。

总的来说，DAS 1802利用现有的底层技术并且将统一接口公开于服务层实体。下面描述支持来自M2M/IoT网络视角的DAS 1802和其客户端1808之间的交互过程的通用架构设计和程序设计。

应当理解，图19中示出的功能可以以在M2M网络的节点或者装置(例如服务器、网关、设备或者其它计算机***)(诸如下面描述的图29C或者图29D中示出的那些中的一个)的存储器中存储的并且在M2M网络的节点或者装置的处理器上执行的软件(即计算机可执行指令)的形式实施。

图20示出DAS 1802内的功能设计。应当理解，在图20中示出的功能可以以在M2M网络的节点或者装置(例如服务器、网关、设备或者其它计算机***)(诸如下面描述的图29C或者图29D中示出的那些中的一个)的存储器中存储的并且在M2M网络的节点或者装置的处理器上执行的软件(即计算机可执行指令)的形式实施。

如可以看到的，不同数据分析能力可以被增加到DAS 1802，使得可以进行各种数据分析操作，诸如基本数据统计、图像处理、信息提取等。

用于将那些底层数据分析能力增加到DAS 1802的各种方法可以被使用。如果已经存在可以提供数据分析服务的外部数据服务门户，则可以在DAS 1802中注册或者增加门户接入信息。因此，一旦DAS 1802从其客户端1808接收到分析请求，它就可以使用那些外部服务门户以便获得分析结果。

可替换地，如果存在可用的***分析模块，则这些模块可以被直接***到DAS1802中，使得数据分析操作可以由正在运行DAS 1802的对应CSE 1804本地直接执行(尤其是针对那些低成本轻量数据统计操作)。

因此，DAS 1802可以被部署/实现在各种类型的CSE(例如ASN-CSE、MN-CSE(像网关)和IN-CSE)(其可以托管在云中)中/由各种类型的CSE(例如ASN-CSE、MN-CSE(像网关)和IN-CSE)(其可以托管在云中)部署/实现。

如早些提及，无论如何将底层技术增加到DAS 1802，DAS 1802将利用统一服务层API将这些技术公开于DAS的客户端。因此，针对每种类型的数据分析服务，服务类型简档(STP)2002被定义以指定与应用编程接口(API)有关的详细信息。换言之，如果DAS 1802具有由不同底层技术(无论是以***方法或者外部方法)支持的多种类型的数据分析能力2004、2006和2008，它们中的每一个将具有对应的STP 2002。通常，STP 2002由DAS 1802公布，使得DAS 1802的底层客户端可以发现由DAS 1802提供的可用数据分析能力。

通常，DAS 1802的工作方法如下：1)各种分析服务能力可以由DAS 1802通过利用底层数据分析工具/技术提供；2)针对每种类型的数据分析能力，定义了STP 2002，其指定与该分析能力有关的细节，例如，它在哪里，它何时可用，数据分析操作要花费多久，它可以识别/分析什么，和在输入/输出参数方面的服务接入细节，即，客户端应当使用其接入该服务的API的格式(即服务层请求/响应消息的结构)等。总的来说，客户端如何发现/参考DAS1802的STP 2002以及如何通过统一API接入对应DAS 1802(例如发送数据分析请求并且接收分析结果等)将通常发生在mac/mcc/mcc’参考点上并且稍后将引入详细程序。

DAS 1802的内部接口转换器2010可以使用STP 2002将来自客户端1808的信息转换成用于分析能力2004,2006和2008的API的信息。

表1给出STP 2002的典型定义，其可以用于描述三个主要/流行类型的数据分析操作，诸如基本数据统计、文本/信息提取或图像处理。

表1：服务类型简档(STP)的参数

描述用于与DAS 1802交互的多个示例性程序并且这些程序可适用于四种不同的情况或者场景。

情况1(由客户端检索的原始数据)：客户端1808将首先获得其目标/感兴趣的待分析的原始数据，并且然后将其发送到DAS 1802以用于分析。

图21图示情况1的用于与DAS 1802交互的程序并且详细描述被讨论如下。

前提条件。Data-1是在CSE-1(作为数据托管CSE 1806)上的<contentInstance>资源中存储的一条数据并且AE-1(作为DAS客户端1808)对Data-1感兴趣。同时，存在在***中可用的DAS 1802(由作为DAS托管CSE 1804的CSE-2托管)并且它公布了其STP 2002来通告它的可用数据分析能力。为了容易说明，我们考虑其中DAS客户端1808、DAS托管CSE 1804、数据托管CSE 1806由不同实体即相应的AE-1、CSE-2和CSE-1担任(但是实际上，如早些提及的，DAS客户端/DAS托管CSE/数据托管CSE也可以由相同CSE担任)的示例性场景。

在图21的步骤1中，基于AE-1的兴趣，AE-1发送请求到CSE-1以用于检索Data-1。注意到，当AE-1旨在从不同位置收集多个数据(例如数字传感器读数)以便进行由DAS 1802提供的“基本数据统计”(例如计算多个温度读数的平均值)时，该步骤可以多次执行。为了容易呈现而不失去普遍性，我们仅仅说明其中一次仅仅需要分析一条数据的情况(其对于其中例如对文本文档或者图像执行信息提取或者图像处理类型的数据分析操作的情况是更普遍的。更普遍地，如果需要从多个位置例如从多个CSE上的多个<contentInstance>资源检索超过一条原始数据则可以多次重复步骤1)。

在图21的步骤2中，将Data-1从CSE-1返回到AE-1。步骤1和步骤2是标准资源检索操作。可替换地，还可能的是，AE-1可能具有需要分析的其本身的本地数据。在这种情况下，可以跳过资源检索操作(步骤1和步骤2)。

在图21的步骤3中，在获得Data-1之后，AE-1发现为了理解或者导出Data-1中的有价值信息，它需要适当的数据分析操作。因此，AE-1发现由CSE-2公布的STP并且识别由CSE-2提供的适当的数据分析操作。这样的STP公布和发现过程可以通过使用任何现有服务发现机制来完成。

在图21的步骤4中，AE-1根据如在选定的STP中指定的接口规范而将数据分析请求连同为待分析的数据的有效负荷中的Data-1一起发送到CSE-2。具体地，通过参考如在选定的STP文件中定义的“Input_Parameters”数据条目(对于更多的细节，参见表1)，在该步骤中发送的请求消息可以被构造为如下：通常，除了其通常在有效负荷(其需要符合如由在STP中的“Raw_Data_Format”条目指定的格式)中携带的待分析的原始数据(例如图像)之外，该消息可以包括以下两个强制数据分析有关的参数：

CSE_ID(cse_id)：该消息接收器的身份指示哪个CSE的DAS 1802将处理该数据分析请求。

Analytics_Type(a_t)：该数据字段指示客户端请求哪个类型的数据分析操作。例如，它可以是图像处理操作或者信息提取操作或者基本数据统计操作等。

此外，针对每种类型的分析服务(如由Analytics_Type条目指定)，它还可以包括以下不同的数据条目：

当Analytics_Type＝“基本数据分析”时：

Statistical_Operation(s_o)：该项目指示它需要哪个类型的数据统计操作，其选自如在STP中定义的Supported_Statistical_Operations条目。例如，DAS 1802可以支持标准数据聚集，诸如最大、最小、平均、中间等。

当Analytics_Type＝“信息提取”时：

Selected_Targeted_Information(s_t_i)：针对支持文本有关的信息提取的数据分析服务，它可以吸引来自各种类型的文档(例如基于XML或者JASON的文档)的有用信息，例如温度值或者位置信息。因此，该项目指示可以通过使用该服务提取哪个目标信息，例如“时间”、“位置”、“温度”等，其选自如在STP中定义的Targeted_Information(目标信息)条目。

当Analytics_Type＝“图像处理”时：

Interested Object(s)(i_o)：该参数指示客户端针对该图像处理操作对哪个(哪几个)潜在对象感兴趣。注意到，感兴趣的对象选自如在选定的STP中定义的identifiableobjects条目。

Selected_Analytical_Aspects(s_a_a)：针对某个感兴趣的对象，该项目指定哪个分析方面或者结果将被提供并且它选自STP中的Analytical_Aspects条目。例如，针对天空对象，分析方面可以是与天气有关的(例如晴朗、多云等)或者与能见度有关的。因此，基于该参数，它指示哪种分析结果将由DAS 1802返回。

在图21的步骤5中，CSE-2进行如由AE-1所需要的期望数据分析操作并且得出分析结果。

在图21的步骤6中，DAS 1802将分析结果返回到AE-1。在该步骤中，在响应消息中包括的参数将符合如在表1中定义的“Output_Parameters”。例如，该消息可以包括：

Successes Flag(s_f)：该数据字段指示所需要的数据分析操作是否已经导出任何分析结果。该参数的值可以是0(失败)和1(成功)。当值是0时，它基本上意味着可能不存在返回的分析结果，例如DAS 1802在原始数据中未识别到任何感兴趣的对象(例如当客户端发送苹果图像到DAS 1802并且需要由STP定义的其中可识别对象仅仅是道路交通和天空的分析操作)。

Analytical_Result(a_r)：如果可用，该数据字段存储数据分析结果。如早些提及的，分析结果中的每一个可以关联于图像处理类型的数据分析操作内部的置信。可替换地，如果需要可以在有效负荷中携带分析结果。

在图21的步骤7中，一旦AE-1从CSE-2获得分析结果，就可以将它用于进一步的目的。

情况1中的程序设计也适用于其中例如DAS客户端1808、DAS托管CSE 1804和数据托管CSE 1806位于不同节点中或者至少DAS托管CSE 1804和数据托管CSE 1806之间的接近度大于DAS客户端1808和数据托管CSE 1806之间的接近度(即DAS客户端1808从数据托管CSE 1806检索数据而没有招致不必要的通信成本是有意义的)的场景。

应当理解，执行图21中图示的步骤的实体是逻辑实体，其可以以在网络装置或者计算机***(诸如图29C或者图29D中图示的那些)的存储器中存储的并且在网络装置或者计算机***的处理器上执行的软件(即计算机可执行指令)的形式实施。即，图21中示出的(一个或多个)方法可以以在网络装置(诸如在图29C或图29D中图示的装置或者计算机***)的存储器中存储的软件(即计算机可执行指令)的形式实施，该计算机可执行指令在由装置的处理器执行时执行图21中图示的步骤。还要理解，图21中图示的任何发送和接收步骤可以在装置的处理器和该处理器执行的计算机可执行指令(例如软件)的控制下由该装置的通信电路执行。

情况2(由DAS 1802检索的原始数据)：客户端将直接要求DAS 1802进行某种数据分析操作并且DAS 1802将代表客户端检索目标/感兴趣的待分析的原始数据。

图22图示针对情况2的用于与DAS 1802交互的程序并且详细描述被讨论如下。

前提条件(与情况1相同)。Data-1是在CSE-1(作为数据托管CSE 1806)上的<contentInstance>资源中存储的一条数据并且AE-1(作为DAS客户端1808)对Data-1感兴趣。同时，存在在***中可用的DAS(由作为DAS托管CSE的CSE-2托管)并且它公布了其STP来通告它的可用数据分析能力。

在图22的步骤1中，AE-1首先发现由CSE-2公布的STP并且识别期望的数据分析操作。

在图22的步骤2中，AE-1根据如在选定的STP中指定的接口规范而将数据分析发送到CSE-2。具体地，通过参考如在选定的STP文件中定义的“Input_Parameters”(对于更多的细节，参见表1)，在该步骤中发送的请求消息可以被解释为与情况1中的步骤4相同。不仅如此，可以存在如下定义的另一个额外参数：

URI_of_Data_To_Be_Analyzed(data_uri)：该URI指示DAS可以在哪里检索待分析的数据。注意到，虽然在图22中示出的示例图示了其中通过数据分析请求分析仅一条数据(即Data-1)的情况，但是可能的是所要求的数据分析操作可以从不同位置检索多条数据(尤其是当数据分析类型是基本数据统计操作，如早些讨论的)。在这种情况下，该参数将包括URL列表。

此外，AE-1还可以发送有关的访问信息，使得DAS可以成功访问Data-1，诸如访问与控制有关的信息。

在图22的步骤3中，CSE-2还将请求发送到CSE-1用于检索Data-1。

在图22的步骤4中，将Data-1从CSE-1返回到CSE-2。与针对情况1定义的程序的步骤1和步骤2相同，这里的步骤3和步骤4也是标准资源检索操作。

图22的步骤5-7与针对情况1定义的程序的步骤5-7相同。

情况2更适用于其中DAS托管CSE 1804和数据托管CSE 1806之间的接近度小于DAS客户端1808和数据托管CSE 1806之间的接近度(即不需要DAS客户端1808从数据托管CSE1806检索数据以便避免不必要的通信成本)的场景。

应当理解，执行图22中图示的步骤的实体是逻辑实体，其可以以在网络装置或者计算机***(诸如图29C或者图29D中图示的那些)的存储器中存储的并且在网络装置或者计算机***的处理器上执行的软件(即计算机可执行指令)的形式实施。即，图22中图示出的(一个或多个)方法可以以在网络装置(诸如在图29C或图29D中图示的装置或者计算机***)的存储器中存储的软件(即计算机可执行指令)的形式实施，该计算机可执行指令在由装置的处理器执行时执行图22中图示的步骤。还要理解，图22中图示的任何发送和接收步骤可以在装置的处理器和该处理器执行的计算机可执行指令(例如软件)的控制下由该装置的通信电路执行。

情况3(由DAS发现并且检索的原始数据)：类似于情况2，AE-1(作为DAS客户端1808)将直接要求CSE-2(作为DAS托管CSE)对待分析的原始数据进行某种数据分析。然而，这里的不同在于在，这种情况中，数据分析操作可以被移动并且在较近的DAS托管CSE 2302(其更靠近待分析的原始数据)处，而不是在原始DAS托管CSE 1802(即CSE-2)(其接收来自于AE-1的请求)处执行(注意到，“较近”基本上暗示更小的通信开销，所以它可能不一定意味着更近的地理位置)。值得注意的是，从大数据的角度来讲，该程序将与当前数据分析处理范例充分一致，即尝试移动计算处理到存储数据的位置而不是移动数据到计算。

图23A至图23B图示了情况3中的用于与DAS交互的程序。在该示例性场景中，我们假设CSE-2 1804和CSE-3 2302位于不同的位置并且相比于CSE-2 1804，CSE-3 2302更靠近CSE-1806。注意到，在情况3中的图23A至图23B的大部分步骤与情况2中的图22的步骤相同。这里，仅仅讨论这两个情况之间的差别(如在绿色矩形框中突出显示的)。如图23A至图23B所示，由于CSE-3 2302更靠近待分析原始数据，所以针对CSE-2 1804定义步骤3和步骤4以将数据分析请求从AE-1 1808转发到CSE-3 2302。因此，在情况3中的图23A至图23B的步骤2和步骤4的请求消息中携带的数据项目将具有与针对情况2中的图22的步骤2定义的消息几乎相同的消息。不仅如此，针对情况3中的图23A至图23B的步骤4，可以存在如下面定义的另一个额外参数：

Original_CSE_ID(original_cse_id)：该数据字段指示哪个原始DAS是接收该数据分析请求的那个(即在该示例中的CSE-2)。

在CSE-3 2302得出分析结果之后，将该结果返回到CSE-2 1804，其将进一步转发该结果到AE-1 1808(如在图23A至图23B的步骤7-9中所示)。此外，针对情况3中的图23A至图23B的步骤9，可以存在如下定义的另一个额外参数：

Task_Execution_CSE_ID(execution_cse_id)：该数据字段指示哪个实际DAS是针对该请求进行数据分析处理的那个(即在该示例中的CSE-3 2302)。

因此，基于该数据项目，AE-1 1808可以理解虽然它将请求发送到CSE-2 1804，但是该请求实际上已经被CSE-3 2302处理。可替换地，针对来自AE-1 1808的未来类似的请求，它可以直接联系CSE-3 2302或者可替换地，它仍然可以发送请求到邻近的DAS(即在该示例中的CSE-2 1804)，并且让DAS做出请求应当被转发到哪里的决定。

此外，值得注意的是，虽然我们利用与“接近度”有关的考虑来说明该程序，即将数据分析操作从原始DAS托管CSE 1804移动到更靠近数据托管CSE的另一个DAS托管CSE2302。然而，该程序还可以用于任何其它场景(不必将“接近度”取为主要度量)。例如，只要一个DAS托管CSE 1804需要委托某种分析操作到其它同等的DAS托管CSE，就都应用该程序(例如，为了负载平衡、安全问题、任务迁移等的目的)。

应当理解，执行图23A至图23B中图示的步骤的实体是逻辑实体，其可以以在网络装置或者计算机***(诸如图29C或者图29D中图示的那些)的存储器中存储的并且在网络装置或者计算机***的处理器上执行的软件(即计算机可执行指令)的形式实施。即，图23A至图23B中示出的(一个或多个)方法可以以在网络装置(诸如在图29C或图29D中图示的装置或者计算机***)的存储器中存储的软件(即计算机可执行指令)的形式实施，该计算机可执行指令在由装置的处理器执行时执行图23A至图23B中图示的步骤。还要理解，图23A至图23B中图示的任何发送和接收步骤可以在装置的处理器和该处理器执行的计算机可执行指令(例如软件)的控制下由该装置的通信电路执行。

情况4(基于订阅的DAS)：识别到当在M2M/IoT***的上下文中进行数据分析操作时可能存在一些独特方面。例如，传感器或者设备可以随着时间生成数据流，AE或者CSE可能对该数据流感兴趣。例如，交通评估AE可能旨在不断地分析由高速公路上的户外相机生成的图像。同样地，在一些情景中，在待分析的原始数据变得可用之前，客户端可以请求在DAS处的数据分析操作。因此，情况4集中于用于与DAS交互的基于订阅的范例。

图24A至图24B图示情况4中的用于与DAS交互的程序。注意到，在情况4中的大部分步骤与在情况2中的步骤相同。这里，仅仅讨论着两个情况之间的差别(如在蓝色矩形框中突出显示的)。例如，在这种情况下，代替DAS客户端1808对特定一条数据感兴趣，AE-1可能对CSE-1 1806上的整个<container-1>资源感兴趣。特别地，客户端将对输入到容器中的新的可用数据感兴趣并且需要对该数据的周期数据分析操作。同时，在图24A至图24B的步骤2的请求消息中携带的数据项目将具有与针对情况2中的图22的步骤2定义的消息几乎相同的消息。不仅如此，可以存在如下面定义的另一个额外参数：

Subscription-based operation flag(s_o)：利用该标志，DAS托管CSE 1804将知道DAS客户端1808正在需要基于订阅的DAS操作。因此，在该步骤中利用该标志，它意味着实际上AE-1对到CSE-2的分析结果做出订阅。

Analytics Schedule or Frequency(s_f)：该数据字段指示客户端期望DAS对新数据进行数据分析操作的时间表或者频率。这是因为可能的是新数据可以在<container>资源中以更快的节奏变得可用(例如，10个新数据在由感测设备的采样频率决定的一分钟内生成)，而AE-1可能仅仅旨在具有用于对新数据进行数据分析操作的较低分析频率(例如每小时一次)。

此外，情况4中的图24A至图24B的步骤3-6仅仅图示由CSE-2 1804(即DAS托管CSE)初始化的标准订阅操作，以便向CSE-2做出与<container>资源中的新的可用数据有关的通知。因此，在图24A至图24B的步骤7中，针对每个接收到的通知，CSE-2 1804通过参考在图24A至图24B的步骤2中如由AE-1 1808指定的分析频率或者时间表来决定是否检索新数据以用于分析。如果CSE-2 1804决定分析新数据，则其将进一步检索来自CSE-1 1806的新数据并且剩余程序类似于之前的情况。

上述程序正在使用传统服务订阅方法用于DAS接入。可替换地，AE-1 1808还可以利用oneM2M<subscription>资源来实现相同目的。例如，在图24A至图24B的步骤2期间，AE-1 1808可以在DAS托管CSE 1804上创建<container>资源，以便存储分析结果。同时，其在该<container>资源之下还创建<subscription>资源。因此，在DAS侧，和图24A至图24B的步骤10相同，它可以基于AE-1的需要而进行期望的数据分析操作，并且然后把那些分析结果作为<contentInstance>资源放入在<container>资源中，这将进一步触发通知被发送到AE-11808(例如根据由AE-1 1808设置的某种通知标准)。

应当理解，执行图24A至图24B中图示的步骤的实体是逻辑实体，其可以以在网络装置或者计算机***(诸如图29C或者图29D中图示的那些)的存储器中存储的并且在网络装置或者计算机***的处理器上执行的软件(即计算机可执行指令)的形式实施。即，图24A至图24B中示出的(一个或多个)方法可以以在网络装置(诸如在图29C或图29D中图示的装置或者计算机***)的存储器中存储的软件(即计算机可执行指令)的形式实施，该计算机可执行指令在由装置的处理器执行时执行图24A至图24B中图示的步骤。还要理解，图24A至图24B中图示的任何发送和接收步骤可以在装置的处理器和该处理器执行的计算机可执行指令(例如软件)的控制下由该装置的通信电路执行。

oneM2M当前在定义由oneM2M服务层支持的能力的过程中。这些能力被称为能力服务功能(CSF)。OneM2M服务层被称为能力服务实体(CSE)。因此，DAS可以被认为由CSE实施的CSF，如图25所示(可替换地，它也可以是在oneM2M TS-0001中定义的现有数据管理和存储(DMR)CSF的一部分)。因此，该程序以及新参数主要发生在mca和mcc/mcc’参考点，如图25所示。应当是不同类型的M2M节点可以实施DAS，诸如M2M网关、M2M服务器、M2M设备等。特别地，取决于针对那些节点的各种/不同的硬件/软件能力，由那些节点实施的DAS的功能性/能力也可以是不同的。

应当理解，图25中图示的功能性可以以在M2M网络的节点(例如服务器、网关、设备或者其它计算机***)(诸如下面描述的图29C或者图29D中图示的那些中的一个)的存储器中存储的并且在M2M网络的节点的处理器上执行的软件(即计算机可执行指令)的形式实施。

两个新的oneM2M资源被定义以便使能DAS。特别地，由于服务类型简档被定义为公开于DAS的潜在客户端，所以称为<STP>的新资源被用于描述STP 2002，其在图26中示出。因此，通过访问那些<STP>资源，客户端可以容易理解哪些数据分析操作是可用的。同时，这种<STP>资源可以在网络中的不同CSE处公开以便有助于DAS客户端的发现。特别地，在该资源中定义的“accessPortalAddress”属性指示针对该STP 2002如何实际上接入该对应的DAS(即哪里发送请求消息到DAS托管CSE 1804)。因此，使用在图27中示出的称为<DAS>的新资源，其通常作为DAS托管CSE 1804的子资源，并且该资源的URI将被包括在对应的<STP>资源的之前提及的accessPortalAddress属性。由于<DAS>仅仅是接入门户，所以它可能仅仅包括针对服务层资源的公共属性，其在图27中未示出。因此，DAS客户端的所有请求(以及通常被存储在<contentInstance>资源中的待分析的原始数据)将被发送到由“accessPortalAddress”属性指定的地址并且这些请求可以使用如在服务层中定义的CREATE或者UPDATE请求(因为当发送数据分析请求到DAS时将未创建新资源，所以建议UPDATE)。此外，<STP>的资源结构是基于STP 2002的定义的并且<STP>资源的属性的含义与在表1中引入的那些相同。

诸如图形用户界面(GUI)的界面可以用于辅助用户控制和/或配置与使能数据分析有关的功能。如上面介绍，新的DAS公共服务用于服务层。特别地，为了人类管理员监测那些DAS服务正在如何运行，图28A示出用于检查整个***视图的GUI 2802。例如，可以允许人类检查由DAS运行的特定类型的数据分析操作，例如，图像处理或者信息提取等(例如通过输入用户旨在检查的特定类型的数据分析操作，如图28A所示或者可替换地，让用户经过下拉从各种数据分析操作中选择选项)。此外，人类管理员可以监测底层数据分析组件是否正在正常工作。同时，由于通过STP 2002公开每个类型的数据分析操作，所以GUI 2802还允许管理员尤其针对STP 2002中的那些动态改变的数据项目检查STP 2002的细节，诸如与分析结果的置信区间有关的服务可用性和统计信息。此外，它还允许管理员针对每个特定STP2002检查哪个客户端已经接入并且使用它们以便理解由DAS提供的各种类型的数据分析操作的利用率。例如，图28B示出当管理员选择检查STP 2002的图像处理类型时的输出面板界面2804，其中，该STP 2002的细节已经被显示给用户供他们参考。应当理解，界面2802和2804可以使用诸如在下面描述的图29C至图29D中示出的那些的显示器来产生。

用于数据分析服务的示例性M2M/IoT/WoT通信***

这里描述的各种技术可以结合硬件、固件、软件或者在适当情况下以其组合来实施。这种硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置。这些装置可以单独地操作或者彼此结合操作以实施这里描述的方法。如本文所述，可以互换使用术语“装置”“网络装置”、“节点”、“设备”以及“网络节点”。

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

图29A是可以实施一个或多个公开的实施例的示例性机器对机器(M2M)、物联网(IoT)、或万维物联网(WoT)通信***10的图。通常，M2M技术为IoT/WoT提供构建模块，并且任何M2M设备、M2M网关、M2M服务器、或者M2M服务平台可以是IoT/WoT以及IoT/WoT服务层等等的组件或节点。通信***10可用于实施所公开的实施例的功能并且可包括功能和逻辑实体，诸如：M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体。

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

如图29A所示，M2M/IoT/WoT通信***10可以包括基础架构域和场域。基础架构域是指端到端M2M部署的网络侧，而场域是指通常在M2M网关之后的区域网络。场域和基础架构域均可以包括各种不同网络节点(例如服务器、网关、设备等等)。例如，场域可以包括M2M网关14和终端设备18。应当理解，根据需要可以在M2M/IoT/WoT通信***10中包括任何数量的M2M网关设备14和M2M终端设备18。每个M2M网关设备14和M2M终端设备18被配置为使用通信电路经由通信网络12或直接无线电链路来发送和接收信号。M2M网关14允许无线M2M设备(例如蜂窝和非蜂窝)以及固定网络M2M设备(例如PLC)通过诸如通信网络12的运营商网络或直接无线电链路来通信。例如，M2M终端设备18可以收集数据并经由通信网络12或直接无线电链路将该数据发送到M2M应用20或其他M2M设备18。M2M终端设备18还可以接收来自于M2M应用20或M2M终端设备18的数据。此外，如下所述，可以经由M2M服务层22将数据和信号发送到M2M应用20或者接收来自于M2M应用20的数据和信号。M2M终端设备18和网关14可以经由包括例如蜂窝、WLAN、WPAN(例如Zigbee、6LoWPAN、蓝牙)、直接无线电链路、以及有线线路的各种网络来通信。

示例性M2M终端设备18包括但不限于平板电脑、智能电话、医疗设备、温度和天气监视器、互联汽车、智能仪表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门、以及其他基于致动器的设备、安全设备、以及智能插口。

参考图29B，场域中的所图示的M2M服务层22为M2M应用20、M2M网关设备14、和M2M终端设备18以及通信网络12提供服务。通信网络12可用于实施所公开实施例的功能性并且可包括功能性和逻辑实体，诸如：M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体。M2M服务层22可以由一个或多个服务器、计算机、设备、虚拟机(例如云/存储场等)等来实施，其包括例如在如下所述的图29C和29D中所图示的设备。应当理解，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'可以由可以包括服务器、计算机、设备、虚拟机(例如云计算/存储场等)等的网络的一个或多个节点来实施。

仍参考图29B，M2M服务层22和22'提供多种应用和垂直元(verticals)可利用的服务递送能力的核心集。这些服务能力使得M2M应用20和20'能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全性、账务、服务/设备发现等的功能。基本上，这些服务能力使应用程序免于实现这些功能的负担，从而简化应用程序开发并且降低成本和上市时间。服务层22和22'还使得M2M应用20和20'能够通过网络12与服务层22和22'所提供的服务有关地通信。

本申请的方法可以作为服务层22和22'的一部分来实施。服务层22和22'是通过一组应用编程接口(API)和底层网络接口来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M这两者使用可以包含本申请的连接方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可以在M2M设备(它被称为设备SCL(DSCL))、网关(它被称为网关SCL(GSCL))、和/或网络节点(它被称为网络SCL(NSCL))之内实施。oneM2M服务层支持一组公共服务功能(CSF)(即服务能力)。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，该公共服务实体可被托管在不同类型的网络节点上(例如基础架构节点、中间节点、应用特定节点)。此外，本申请的连接方法可以作为下述M2M网络的一部分来实施，所述M2M网络使用面向服务的架构(SOA)和/或面向资源的架构(ROA)以接入诸如本申请的连接方法的服务。

在一些实施例中，M2M应用20和20'可以与所公开的***和方法相结合地使用。M2M应用20和20'可以包括与UE或网关相交互的应用并且还可以与其他公开的***和方法相结合地使用。

在一个实施例中，如图29B所示，诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体的逻辑实体可以托管在由诸如M2M服务器、M2M网关、或者M2M设备的M2M节点托管的M2M服务层实例内。例如，诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体的逻辑实体可以包括M2M服务层实例内的或者作为现有服务能力内的子功能的单独服务能力。

M2M应用20和20'可以包括在诸如但不限于运输、健康和保健、互联家庭、能量管理、资产跟踪、以及安全和监视这样的各种行业中的应用。如上所述，跨***的设备、网关、服务器、以及其他节点运行的M2M服务层支持诸如例如数据收集、设备管理、安全、账务、位置跟踪/地理围栏、设备/服务发现、以及遗留***集成的功能并且将这些功能作为服务提供给M2M应用20和20'。

通常，服务层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)的一部分实施。无论是体现在ETSIM2M架构的DSCL、GSCL或NSCL中，在3GPP GPRS架构的服务能力服务器(SCS)中，在oneM2M架构的CSF或CSE中，还是在网络的一些其他节点中，服务层的实例可以作为在网络中的一个或多个独立节点(包括服务器、计算机、以及其他计算设备或节点)执行的逻辑实体(例如软件、计算机可执行指令等等)或者作为一个或多个现有节点的一部分来实施。作为示例，服务层或其组件的实例可以以在具有如下在图29C或图29D中所图示的通用架构的网络节点(例如服务器、计算机、网关、设备等)上运行的软件的形式来实施。

此外，诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体的逻辑实体可以作为下述M2M网络的一部分来实施，所述M2M网络使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来接入本申请的服务。

图29C是诸如M2M设备18、M2M网关14、M2M服务器等的M2M网络节点30的示例性硬件/软件架构的框图。节点30可执行或包括逻辑实体，诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体。设备30可是如图29A至图29B所示的M2M网络的一部分或者是非M2M网络的一部分。如图29C所示，M2M节点30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、键盘40、显示器/触摸板/和/或指示器42、电源48、全球定位***(GPS)芯片组50、以及其他***设备52。节点30还可以包括诸如收发器34和发送/接收元件36的通信电路。应当理解，M2M节点30可以包括先前元件的任何子组合，同时保持与实施例一致。该节点可以是用于实施在这里所描述的功能的节点。

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

如图29C所示，处理器32与其通信电路(例如收发器34和发送/接收元件36)相耦合。通过执行计算机可执行指令，处理器32可以控制通信电路以便使得节点30经由与其相连的网络与其他节点通信。具体地，处理器32可以控制通信电路以便执行在这里和权利要求中所描述的发送和接收步骤。尽管图29C将处理器32和收发器34描绘为单独的组件，但是应当理解，可以将处理器32和收发器34一起集成在电子封装或芯片中。

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

另外，虽然在图29C中将发送/接收元件36描绘为单个元件，但是M2M节点30可以包括任何数量的发送/接收元件36。特别地，M2M节点30可以采用MIMO技术。因而，在实施例中，M2M节点30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如多个天线)。

收发器34可以被配置为调制要由发送/接收元件36发送的信号并解调发送/接收元件36所接收的信号。如上所述，M2M节点30可以具有多模式能力。因而，收发器34可以包括用于使得M2M节点30能够经由例如诸如UTRA和IEEE 802.11的多种RAT进行通信的多个收发器。

处理器32可以从诸如不可移除存储器44和/或可移除存储器46的任何类型的适当存储器访问信息并将数据存储在其中。例如，如上所述，处理器32可以将会话上下文存储在其存储器中。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或者任何其他类型的存储器存储设备。可移除存储器46可以包括订户识别模块(SIM)卡、存储棒、安全数字(SD)存储卡等等。在其他实施例中，处理器32可以从诸如服务器或家庭计算机的并非物理上位于M2M节点30上的存储器访问信息并将数据存储在其中。处理器32可以被配置为控制显示器上的视觉指示以反映***的状态或者获得来自于用户的输入或者向用户显示关于能力或者设置的信息。可以在显示器上示出的图形用户界面可以被分层在API之上以允许用户交互地完成这里描述的功能。

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

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

处理器32可以进一步与下述其他***设备52相耦合，所述其他***设备可以包括用于提供附加特征、功能、和/或有线或无线连接的一个或多个软件和/或硬件模块。例如，***设备52可以包括诸如加速度计的各种传感器、生物识别(例如指纹)传感器、电子罗盘、卫星收发器、数字相机(用于照片或视频)、通用串行总线(USB)端口或者其它互连接口、振动设备、电视收发器、免提耳机、蓝牙模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、因特网浏览器等。

节点30可以被实现在其它装置或者设备中，诸如传感器、消费者电子产品、可穿戴设备(诸如智能手表或者智能衣服)、医疗或者电子医疗设备、机器人、工业设备、无人机、交通工具(诸如汽车、卡车、列车或者飞机)。节点30可以经由一个或者多个互连接口(诸如可以包括***设备52中的一个的互连接口)连接到这种装置或者设备的其它组件、模块或者***。可替换地，节点30可以包括以下装置或者设备，诸如传感器、消费者电子产品、可穿戴设备(诸如智能手表或者智能衣服)、医疗或者电子医疗设备、机器人、工业设备、无人机、交通工具(诸如汽车、卡车、列车或者飞机)。

图29D是还可以用于实施诸如M2M服务器、网关、设备、或其他节点的M2M网络的一个或多个节点的示例性计算***90的框图。计算***90可以包括计算机或服务器并且可以主要由下述计算机可读指令控制，所述计算机可读指令可以是软件形式，无论在何处存储这种软件，或者无论通过何种方式访问这种软件。计算***90可执行或者包括逻辑实体，诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体。计算***90可以是M2M设备、用户设备、网关、UE/GW、或者包括例如移动护理网络、服务层网络应用提供商、终端设备18、或者M2M网关设备14的节点的任何其他节点。这种计算机可读指令可以在诸如中央处理单元(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和/或ROM93的访问可以由存储器控制器92控制。存储器控制器92可以提供在执行指令时将虚拟地址翻译为物理地址的地址翻译功能。存储器控制器92还可以提供隔离***内的进程并将***进程与用户进程隔离的存储器保护功能。因而，以第一模式运行的程序只能够访问由其本身的进程虚拟地址空间所映射的存储器，除非已经设置进程之间的存储器共享，否则它不能访问另一进程的虚拟地址空间内的存储器。

另外，计算***90可以包含下述***设备控制器83，所述***设备控制器83负责将指令从CPU 91通信到诸如打印机94、键盘84、鼠标95、以及磁盘驱动器85的***设备。

由显示控制器96控制的显示器86用于显示由计算***90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形、以及视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器、或者触摸面板来实施。显示控制器96包括生成要发送到显示器86的视频信号所要求的电子部件。

此外，计算***90可以包含诸如例如网络适配器97的通信电路，该通信电路可以用于使计算***90连接到诸如图29A和图29B的网络12的外部通信网并且使得计算***90能够与网络的其他节点通信。

用户设备(UE)可以是由终端用户通信所使用的任何设备。它可以是手持电话、装备有移动宽带适配器的膝上型计算机或者任何其它设备。例如，UE可以被实施为图29A至图29B的M2M终端设备18或者图29C的设备30。

应当理解，这里所描述的***、方法、以及处理中的任何一个或全部可以以存储在计算机可读存储介质上的计算机可执行指令(即程序代码)的形式来体现，所述计算机可执行指令当被诸如包括M2M服务器、网关、设备等的M2M网络的节点的机器执行时，执行和/或实施此处所描述的***、方法、以及处理。特别地，如上所述的包括网关、UE、UE/GW、或移动核心网络的任何节点、服务层或网络应用提供商的操作的步骤、操作、或者功能中的任何一个可以以这种计算机可执行指令的形式来实施。诸如M2M区域网络、1104 M2M网关、M2M服务器、服务层1202、公共服务实体(CSE)1402、应用实体(AE)1404、相机1702、网关1704、数据分析服务(DAS)1802、DAS托管CSE 1804和2302、数据托管CSE 1806、DAS客户端1808、服务类型简档(STP)2002、分析能力2004,2006和2008、以及创建诸如界面2802和2804的界面的逻辑实体的逻辑实体可以以存储在计算机可读存储介质上的计算机可执行指令的形式来体现。计算机可读存储介质包括以用于存储信息的任何非暂时(即有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备、或者可用于存储所需信息并且可由计算机访问的任何其他有形或物理介质。

在描述本公开的主题的优选实施例时，如图中所图示，为了清楚起见采用了特定术语。然而，要求保护的主题不旨在局限于所选择的特定术语，并且应当理解的是，每个特定元素包括以类似方式操作以实现类似目的的所有技术等同物。

本书面描述使用示例来公开包括最佳模式的本发明，并且还使得本领域技术人员能够实施本发明，其包括制造和使用任何设备或***并执行任何并入的方法。本发明的专利保护范围由权利要求书限定，并且可以包括本领域的技术人员可以想到的其他示例。如果这种其他示例具有与权利要求书的字面语言并无不同的要素，或者如果它们包括与权利要求的字面语言无实质差异的等同要素，则它们旨在落入权利要求的范围之内。

Claims (16)

1.一种由通信网络的服务层节点执行的方法，所述方法包括：

经由所述通信网络从设备接收对于执行对数据的数据分析操作的请求，所述请求识别能够执行请求的数据分析操作的数据分析能力的类型，所述请求还包括由所识别类型的数据分析能力所需要的一个或多个参数，所需要的参数在针对所识别类型的数据分析能力定义的简档中指定；

将所述接收到的请求转发到所述通信网络的另一个服务层节点，所述另一个服务层节点具有到要对其执行所述请求的数据分析操作的所述数据的更近的接近度；

从所述另一个服务层节点接收所请求的对数据的数据分析操作的结果；以及

向所述设备发送所述结果。

2.根据权利要求1所述的方法，其中，所述接收到的请求还包括要对其执行所述数据分析操作的所述数据。

3.根据权利要求1所述的方法，其中，所述接收到的请求包括与要对其执行所述数据分析操作的所述数据相关联的统一资源标识符，并且其中，所述方法还包括基于所述统一资源标识符来检索要对其执行所述数据分析操作的所述数据。

4.根据权利要求1所述的方法，其中，所述方法由所述服务层节点的数据分析服务来执行。

5.根据权利要求4所述的方法，其中，所述数据分析服务与多个不同类型的分析能力对接。

6.根据权利要求5所述的方法，其中，将所述接收到的请求转换成符合所请求的类型的数据分析能力的应用编程接口的请求是通过与所请求的类型的分析能力对接的所述数据分析服务的接口转换器执行的。

7.根据权利要求5所述的方法，其中，针对所识别类型的数据分析能力定义的所述简档提供到向其发送已转换的请求的所请求的类型的所述数据分析能力的应用编程接口的映射。

8.根据权利要求1所述的方法，其中，所述请求的数据分析操作是根据与所述请求的数据分析操作相关联的订阅通过所述数据分析能力执行的。

9.一种包括处理器和存储器的装置，所述装置还包括在所述装置的所述存储器中存储的计算机可执行指令，所述计算机可执行指令当由所述装置的所述处理器执行时使得所述装置在通信网络的服务层处执行操作，所述操作包括：

经由所述通信网络从设备接收对于执行对数据的数据分析操作的请求，所述请求识别能够执行请求的数据分析操作的数据分析能力的类型，所述请求还包括由所识别类型的数据分析能力所需要的一个或多个参数，所需要的参数在针对所识别类型的数据分析能力定义的简档中指定；

将所述接收到的请求转发到所述通信网络的另一个装置，所述另一个装置操作在所述服务层处并且具有到要对其执行所述请求的数据分析操作的所述数据的更近的接近度；

从所述另一个装置接收所请求的对数据的数据分析操作的结果；以及

向所述设备发送所述结果。

10.根据权利要求9所述的装置，其中，所述接收到的请求还包括要对其执行所述数据分析操作的所述数据。

11.根据权利要求9所述的装置，其中，所述接收到的请求包括与要对其执行所述数据分析操作的所述数据相关联的统一资源标识符，并且其中，所述操作还包括基于所述统一资源标识符来检索要对其执行所述数据分析操作的所述数据。

12.根据权利要求9所述的装置，其中，所述计算机可执行指令还使得所述装置实现所述通信网络的所述服务层的数据分析服务，所述数据分析服务执行所述操作。

13.根据权利要求12所述的装置，其中，所述数据分析服务与多个不同类型的分析能力对接。

14.根据权利要求13所述的装置，其中，将所述接收到的请求转换成符合所请求的类型的数据分析能力的应用编程接口的请求是通过与所请求的类型的分析能力对接的所述数据分析服务的接口转换器执行的。

15.根据权利要求13所述的装置，其中，针对所识别类型的数据分析能力定义的所述简档提供到向其发送已转换的请求的所请求的类型的所述数据分析能力的应用编程接口的映射。

16.根据权利要求9所述的装置，其中，所述请求的数据分析操作是根据与所述请求的数据分析操作相关联的订阅通过所述数据分析能力执行的。

Images