Patent Description:
In recent years, the amount of data in our world has been exploding. Google processes hundreds of Petabytes (PBs) of searching data and Facebook generates over <NUM> PBs of log data per month (survey on big data systems, SCIENCE CHINA Information Sciences, <NUM>). As a result of the explosive global data, the term "big data" has been coined to describe enormous datasets. Compared with traditional datasets, big data can include massive unstructured data which needs to be analyzed in order to gain an in-depth insight from this data, e.g. how to discover potential buys from customers' shopping history records.

McKinsey & Company has a more formal definition of big data as follows: "Big data shall mean such datasets which could not be acquired, stored, and managed by classic database software". This definition includes two connotations:.

Another popular definition of big data, which refers to several "Vs" (as shown in <FIG>):.

In addition, More "Vs" can be defined, e.g.: Veracity deals with uncertain or imprecise data, etc..

Currently, industries are becoming more interested in the high potential of big data due to the potential new business and values, and many government agencies as well as the academia community have announced major plans to accelerate big data research and applications.

It is worth noting that the emergence of Internet-of Things (IoT), which typically refers to, for instance, sensors and devices embedded in the physical world and connected by networks to computing resources, is a major trend driving the growth in big data.

As shown in <FIG>, McKinsey research projects that the number of connected IoT nodes deployed in the world is expected to grow at a rate exceeding <NUM> percent annually. Some of the growth sectors are expected to be utilities, as these operators install more smart meters and smart appliances; health care, as the sector deploys remote health monitoring; retail, which will eventually increase its use of radio frequency identification (RFID) tags; and the automotive industry, which will increasingly install sensors in vehicles.

The value chain of big data can be generally divided into four phases: data generation, data acquisition, data storage, and data analysis (see <FIG>). If we take data as a raw material, data generation and data acquisition are an exploitation process, data storage is a storage process, and data analysis is a production process that utilizes the raw material to create new value. Below, a brief introduction for each of those four phases is presented.

Data generation is the first step of big data. As mentioned earlier, huge amount of data is generated. For example searching entries, Internet forum posts, chatting records, and microblog messages. Moreover, large-scale data, of complex and highly diverse nature, can be generated through distributed data sources. Such data sources include sensors, videos, clickstreams, and/or all other available data sources, especially from IoT/M2M systems.

Data acquisition is the second phase of the big data system. Big data acquisition includes data collection, data transmission, etc. During big data acquisition, efficient transmission mechanisms are needed in order to send data to a proper storage management system to support different analytical applications. The collected datasets may sometimes include a significant amount of redundant or useless data, which unnecessarily increases storage space and affects the subsequent data analysis. For example, high redundancy is very common among datasets collected by sensors for environment monitoring. Data compression technology can be applied to reduce the redundancy.

The third phase, i.e., big data storage, refers to the storage and management of large-scale datasets while achieving reliability and availability of data accessing. Typically, it deals with massive, scalable and generally distributed storage systems. On one hand, the storage infrastructure needs to provide a scalable and reliable information storage service; on the other hand, it must provide a powerful access interface for query and analysis of a large amount of data.

The fourth stage is about data analysis. The analysis of big data mainly involves analytical methods applied to the collected data. Data analysis is the most important phase in the value chain of big data, with the purpose of extracting useful values, providing insights in business operations, etc. Different levels of potential values can be generated through the analysis of datasets in different fields. Therefore, it is worth noting that data analysis is a broad area or concept, which frequently changes and is extremely complex as exampled in <FIG>.

A number of existing data analytics products on the market are briefly discussed below. These products are not necessarily associated with the service layer concept.

Google Analytics is a free web analytics service offered by Google that tracks and reports website traffic. Google Analytics is implemented with "page tags", and relies on the proprietary Google Analytics Tracking Code (currently known as Analytics. js), which is a snippet of JavaScript code that the website owner adds to every page of the website. Then, the tracking code runs in the client browser when the client browses the page if JavaScript is enabled in the browser. The code collects visitor data and sends it to a Google data collection server. The users first register and setup a user account in Google Analytics platform. The details of the user account will also be included in the Analytics. js code so that the data collected by the tracking code could be sent to the correct user account. <FIG> shows the general architecture of Google Analytics.

Currently, Google Analytics provides analytics services for three different application scenarios:.

A step further, in addition to data collected by Google Analytics, it is also possible to find deep/hidden insights when mining the data from multiple sources such as corporate databases, or Customer Relationship Management (CRM) systems. Accordingly, now Google delivers Google Analytics Premium and Google BigQuery integration. By automatically importing logs from Google Analytics Premium to Google BigQuery, users can easily write SQL queries to correlate their website visitor activities with other valuable business data such as point-of-sale records, online purchase history, and user sign-in logs. Using this combined insight into their customers, users can then generate customized Ad Remarketing data for Google AdWords and DoubleClick.

IBM recently announced Watson Analytics, a natural-language-based data analytics product. Watson Analytics offers users the benefit of advanced analytics without the complexity. For instance, it allows non-expert people, to conduct various data analysis assisted by Watson analytics, e.g., from loading data, exploring data, making prediction on data, and enabling effortless dashboard and infographic creation for virtualizing analytical results. In the meantime, it allows users to analyze their uploaded data by just typing questions in human understandable natural language, and a natural language processing agent in Watson Analytics will automatically suggest desirable analytics tasks to the users.

<FIG> shows a snapshot of IBM Watson Analytics. It is worth noting that the targeted customers of this product are human users, and that it is not specifically designed for supporting data analytics in M2M/IoT scenario, which is the focus in this work.

Besides the above Watson analytics, IBM also has another type of product called Watson Developer Cloud, which is a proprietary collection of REST APIs and software development kits (SDKs) that use Artificial Intelligence technology to conduct more complicated analytics tasks. <FIG> shows the available data analytics services provided by Watson Developer Cloud. For example, for the Visual Recognition service, a user may send an HTTP request to an analytics endpoint with an image in the payload based on the API specification provided by Watson Cloud. The Visual Recognition service will analyze the visual appearance of the image by using machine learning technology, and return the user with the analytical results containing a list of the possible content depicted in the image, and a confidence level associated with each of these possibilities.

Microsoft Azure is a cloud computing platform and infrastructure, created by Microsoft, for building, deploying, and managing applications and services through a global network of Microsoft-managed and Microsoft partner hosted datacenters. In particular, Azure provides several different types of services related to data analytics, such as Microsoft Machine Learning Service, Stream Analytics, as well as HDInsight. The architecture of data analytics-related services used by Microsoft Azure is shown in <FIG>, and it is highly related to M2M/IoT scenario since most of data in M2M/IoT systems will be data streams. Below we provide a brief introduction for each of those data analytics services.

Microsoft Azure Machine Learning Service: In general, machine learning uses computers to run predictive models that learn from existing data in order to forecast future behaviors, outcomes, and trends. Azure Machine Learning is a powerful cloud-based predictive analytics service that makes it possible to quickly create and deploy predictive models as analytics solutions. Azure Machine Learning provides tools for creating complete predictive analytics solutions in the cloud: Quickly create, test, operationalize, and manage predictive models and the users do not need to buy any hardware nor manually manage virtual machines. It is worth noting that, this service is still targeted for human professionals to facilitate their machine learning related tasks.

Microsoft Azure Stream Analytics: The Stream Analytics service provides low latency, highly available, scalable complex event processing over streaming data in the cloud. Azure Stream Analytics is a cost effective real-time event processing engine that helps to unlock deep insights from data. Microsoft Azure Stream Analytics makes it easy to set up real-time analytic processing on data streaming from devices, sensors, web sites, social media, applications, infrastructure systems, and more (similar products developed by other companies include SQLstream and IBM InfoSphere Streams, etc.). For example, with a few clicks in the Azure portal, a user can author a Stream Analytics job by specifying the input source of the streaming data, a data analytic processing task expressed in a SQL-like language, and the output sink for the results of this job. Compared to the previous Machine Learning Service (which focuses more on the traditional way for conducting predictive analytics in terms of batch processing, i.e., the data first gets collected together before getting processed), streaming analytics paradigm emphasizes more on conducting data analytics operation on-the-fly, i.e., the data gets analyzed as they flow through the data analytics engine.

Microsoft HDInsight: Apache Hadoop is an open-source software framework written in Java for distributed storage and distributed processing of very large data sets on computer clusters built from commodity hardware (see more details in a later section). It is the de-facto large-scale data processing infrastructure for big data related applications. Accordingly, many companies build their various data analytics related services on top of Hadoop framework (i.e., the Hadoop system is the backend infrastructure). Also, in order to facilitate those professionals who intend to work with Hadoop, many companies provide cloud based Hadoop distribution in the sense that it deploys and provisions Apache Hadoop clusters in the cloud, providing a software framework designed to manage, analyze, and report on big data-related tasks with high reliability and availability, such as Microsoft HDInsight (i.e., users do not need to buy any hardware nor manually manage virtual machines or any other resources, they just need to realize those by utilizing services provided by HDInsight Service provided by Microsoft Azure cloud platform).

Besides the above data analytics services provided by the major software companies (although some of them are not directly designed for M2M/IoT scenario), there are also some IoT-oriented platforms which may be equipped with certain data analytics capabilities.

The Intel IoT Platform is an end-to-end reference model and family of products from Intel, which works with third party solutions to provide a foundation for seamlessly and securely connecting devices, delivering trusted data to the cloud, and delivering value through analytics. In particular, Intel provides a cloud-based analytics system for IoT that includes resources, provided by the Intel IoT Developer Kit, for the collection and analysis of sensor data. Using this service, IoT developers have the ability to jump-start data acquisition and analysis without having to invest in large-scale storage and processing capacity.

<FIG> shows the general architecture of Intel IoT Analytics, in which its IoT Developer Kit allows users to configure the edge devices (e.g., Intel's Galileo/Edison devices) and send data to the centralized cloud platform where data analytics tasks can be conducted. The developers may also access and configure its IoT analytics account in the cloud through laptop.

<FIG> shows the user dashboard of Intel IoT analytics, in which a user may conduct different analytics related tasks, for instance, monitoring the data sent from the sensors (or other edge devices), configuring or controlling the edge devices.

Other companies such as Cumulocity, Xively, Keen. io, etc. provide services or products similar to the Intel IoT platform. It is worth noting that most of those services and products are all based on proprietary solutions in the sense that each of those companies has their own Developer Kits, API specifications and documentations, etc..

Apache Hadoop is an open source framework for distributed storage and processing of large sets of data on commodity hardware. Hadoop enables businesses to quickly gain insight from massive amounts of structured and unstructured data.

Numerous Apache Software Foundation projects make up the services required by an enterprise to deploy, integrate and work with Hadoop. Each project has been developed to deliver an explicit function and each has its own community of developers and individual release cycles. <FIG> shows the overview of Apache Hadoop ecosystem.

As mentioned earlier, Hadoop ecosystem is the de-facto large-scale data processing infrastructure for big data related applications and many companies build their various data analytics related services or products on top of the Hadoop framework. For example, a company can provide weather prediction services to its users, where the services are exposed to the users through a simple RESTful interface. Users may just send Hypertext Transfer Protocol (HTTP) requests to the service portal to obtain weather predictions, without knowing any details about how this prediction is done (in these cases, the company may utilize Hadoop infrastructure on the back-end for processing massive data in order to make weather predictions).

A typical Machine-to-Machine (M2M) system architecture is shown in <FIG>, in which an M2M area network <NUM> provides connectivity between M2M end devices and M2M gateways (GWs) <NUM>. Examples of M2M area networks include personal area network based on technologies such as IEEE <NUM>, Zigbee, Bluetooth, etc. The M2M end devices communicate with the M2M GW, and eventually with the M2M Server <NUM>, allowing interaction and/or interfacing with external networks and application systems. A large percentage of M2M devices are resource-constrained entities that provide services such as reporting sensory information (e.g. humidity, temperature, etc.) or function as controllers (e.g. a light switch). However there are also a number of resource-rich entities e.g., home appliances with power supply, cellphones, vehicles, as well as other industry equipment.

From a protocol stack perspective, a service layer <NUM> is typically situated above the application protocol layer <NUM> and provides value added services (e.g. device management, data management, etc.) to applications <NUM> (see <FIG> for illustration) or to another service layer. Hence a service layer is often categorized as 'middleware' services.

An example deployment of an M2M/IoT service layer, instantiated within a network, is shown in <FIG>. In this example, a service layer instance is a realization of the service layer. A number of service layer instances are deployed on various network nodes (i.e. gateways and servers) for providing value-added services to network applications, device applications as well as to the network nodes themselves. Recently, several industry standard bodies (e.g., oneM2M oneM2M-TS-<NUM>, oneM2M Functional Architecture-V-<NUM>. <NUM>) have been developing M2M/IoT service layers to address the challenges associated with the integration of M2M/IoT types of devices and applications into the deployments such as the Internet, cellular, enterprise, and home networks.

An M2M service layer can provide applications and devices access to a collection of M2M-oriented service capabilities. A few examples of such capabilities include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via Application Program Interfaces (APIs) which make use of message primitives defined by the M2M service layer.

The goal of oneM2M is to develop technical specifications which address the need for a common service layer that can be readily embedded within hardware apparatus and software modules in order to support a wide variety of devices in the field. The oneM2M common service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities), as shown in <FIG>. An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) <NUM> which can be hosted on different types of network nodes (e.g. Infrastructure Node (IN) and Middle Node (MN), and Application-Specific Node (ASN)). Such CSEs are termed IN-CSE, MN-CSE and ASN-CSE respectively as defined in oneM2M-TS-<NUM>, oneM2M Functional Architecture-V-<NUM>. The CSEs <NUM> provide the service capabilities to other CSEs as well as to Application Entities (AEs) <NUM>. Typically, AE <NUM> represents an instantiation of application logic for end-to-end M2M solutions and examples of the AE <NUM> can be an instance of a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application, etc..

Initially, oneM2M service layer was developed to be compliant to the Resource-Oriented Architecture (ROA) (oneM2M-TS-<NUM>, oneM2M Functional Architecture-V-<NUM>. <NUM>) design principles, in the sense that different resources are defined within the oneM2M ROA RESTful architecture (as shown in <FIG>). A resource is a uniquely addressable element in the architecture and can be manipulated via RESTful methods such as Create, Retrieve, Update, and Delete. These resources are addressable using Uniform Resource Identifiers (URIs). A resource may contain child resource(s) and attribute(s).

Recently, oneM2M has started developing an M2M Service Component Architecture (as shown in <FIG>), to consider deployments that are not RESTful based. This architecture is primarily suitable for the infrastructure domain where the CSE <NUM> is viewed as a set of service components. It largely re-uses the existing service layer architecture shown in <FIG> but within the service layer it organizes various M2M services and multiple services into service components. In addition to existing reference points, the service-oriented architecture (SOA) architecture introduces the inter-service reference point Msc. Communication between M2M Service Components (passing over the Msc reference point) utilizes a web service approach, which is the most popular technology for building SOA-based software systems. Document <CIT> discloses a M2M Service Layer that is expanded to access the services of third parties and exchange data with these third parties. The M2M Service Layer is then able to act as a proxy between M2M Devices and the third party services. The M2M Service Layer is able to present a single/consistent interface, or API, to the M2M Device and hide the details of the third party service provider from the M2M Device.

The invention is defined in the appended claims, preferred embodiments are defined in the appended dependent claims. The claimed invention relates to case <NUM> subsequently described, while cases <NUM>, <NUM> and <NUM> subsequently described do not belong to the claimed invention, but are examples useful for understanding the invention.

A common Data Analytics Service (DAS) at service layer is designed to use underlying existing/future data analytics technologies or tools and provide them to service layer entities that need those data analytics operations with uniform access approach. A general operation framework/interface design can enable DAS and the operation details within DAS. Related procedures for interacting with DAS can include new parameters in service layer request/response messages.

A general operation framework for enabling DAS defines how DAS works at service layer. The operation details and functionality design inside DAS allows different types of data analytics capabilities (such as basic data statistics, information extraction, image processing, etc.) to be added into DAS and exposed to the clients of DAS (i.e., AEs or CSEs) through uniform interfaces exposed by DAS.

In particular, for a given type of underlying data analytics operation added or plugged into DAS, a Service Type Profile (STP) is defined to specify the detailed information of its corresponding uniform interface and access information.

A number of procedures for interacting with DAS are described. These procedures are typically applicable to four different cases/scenarios:.

The new service DAS can be embodied as a new CSF at Service Layer for providing a common data analytics service. A new oneM2M resource has also been defined for representing the STP.

A User Interface is also described for supporting real-time monitoring and configuration in DAS.

Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

A more detailed understanding may be had from the following description, given by way of example in conjunction with accompanying drawings wherein:.

There are already different types of data analytics services available on the market. In particular, since data analytics is a broad concept, in the sense that it may refer to different forms/types of analytical tasks/operations, these existing data analytics services may provide different functionalities. In addition, some of these analytics services are specifically designed for facilitating manual operation for human users, while others are focused on automatic analytic processing in the context of e.g., M2M/IoT systems.

The existing oneM2M service layer does not have a capability for enabling a "common data analytics service". In particular, the following discusses the potential issues and shortcomings when such a common data analytics service is missing from the service layer and the needs for such a service.

Today, most endpoints (AEs/CSEs) cannot extract intrinsic information from data accessible in the service layer (especially for the unstructured data such as images, documents/logs, etc.), which poses a need for a common data analytics service at service layer.

On the one hand, as introduced above, various types of data, such as semi-structured and unstructured data (such as audio, video, webpage, and text) or structured data (such as those stored in database tables), can co-exist in a system. This is especially true in the context of M2M/IoT systems (which is a major trend driving the growth in big data). It is predicted that more than <NUM>% of data generated from M2M/IoT systems will be unstructured data, such as images captured by outdoor monitoring cameras.

On the other hand, M2M/IoT systems are normally constituted of different types of endpoints, such as apps/devices/desktops inside the M2M systems or from Internet, etc. Therefore, different endpoints may not have the same capability to understand a piece of data generated by an IoT device. For example, some endpoints cannot have data analytics capability/engine especially for the resource-constrained nodes. <FIG> shows a use case illustrating this issue.

As shown in <FIG>, a wireless traffic monitoring camera <NUM> at Exit <NUM> of <NUM>-<NUM> highway (with speed limit of <NUM> mph) is capturing an image and storing it in a <contentInstance> resource at the MN-CSE (Gateway) <NUM>. Since such an image is a piece of unstructured data, the smartphone (or any other endpoint or service entity e.g., AE/CSE), may be able to access this <contentInstance> resource, but it has no way of really understanding the information in this image, e.g., the current weather is sunny or the current road traffic is very light (the travelling speed could be over <NUM> mile per hour), etc. It is worth noting that without certain data analytics processing (for instance, the image processing in this case) over this image, such intrinsic information cannot be derived directly. Unfortunately, most of the M2M/IoT endpoints or the service layer entities are not equipped with such data analytics capability by themselves. Furthermore, there is no such common data analytics service defined at the service layer. As a result, from service layer perspective, it can be seen that a lot of potential value is buried in the raw data stored in the service layer and cannot be utilized in an efficient way to serve service layer entities.

In addition, instead of expecting AEs to have their own data analytics capabilities, it is desirable for service layer to enable a "common" data analytics service, which not only simplifies the function design requirements on various endpoints and AEs, but also beneficial for resource or capability sharing.

Even if the service layers can plug-in external data analytics capabilities, there is no uniform interface to allow endpoints (AEs and CSEs) to access various data analytics services unless they follow the respective proprietary API specifications.

Although there are different types of data analytics services available on the market, most of those services and solutions are proprietary solutions in the sense that each of those solutions have their own Developer Kits, API specifications and documentations, etc. However, in general the service layer endpoints (AEs/CSEs) will not know the proprietary interface to access the 3rd party data analytics services. Since the horizontal service layer (such as oneM2M) aims to provide common service functions (CSFs), it is necessary to expose a uniform operation interface to service layer entities by providing a common data analytics service. In other words, no matter how service layer is enabled with different types of data analytics capabilities (either to leverage the existing external data analytics services as underlying technologies or to plug-in certain data analytics modules in a CSE), all those internal details need to be encapsulated or hidden from service layer entities (e.g., AEs/CSEs). For example, it could add more flexibility to adopt any third party data analytics services without worrying about the intricacies of each of these services. (This is the similar methodology of how service layer leverages the existing/underlying Device Management technologies).

In addition, there is no available procedure design regarding to how to enable (configure, use, control, etc.) data analytic service in the context of M2M/IoT systems.

Mechanisms from both data analytics and data communications can enable data analytics capability in M2M/IoT systems. For example, assuming the service layer is already enabled with a common data analytics service, there are still issues regarding how to interact with this service in terms of procedure design (e.g. how to access, configure and control this service, etc.). This is because M2M/IoT systems rely heavily on efficient communication procedures to realize certain functionalities. However, this is not the major focus of the service providers focusing on data analytics. Therefore, new procedures need to be designed in order to efficiently support the interactions between the common data analytics service and the users/clients of this service.

As mentioned previously, the service layer needs data analytics capabilities due to the intrinsic characteristics of big data in M2M/IoT systems. Therefore, a data analytics service function is added at service layer in order to meet such need.

Examples are described in the context of oneM2M to illustrate the detailed methods and procedures. However, these ideas are not limited to oneM2M and can be generalized to any service layers having similar functionalities or needs.

<FIG> shows a general operation framework of the DAS <NUM>. In this example, DAS <NUM> is provided by a CSE <NUM> as a common service function and it can conduct certain data analytics operations on the targeted/interested (raw) data per the request from various entities (e.g., AEs or other CSEs). Since DAS <NUM> is a common service at service layer, it is likely that those raw data to be analyzed are stored in the existing <contentInstance> resources defined by oneM2M, for example. Accordingly, the CSE hosting the data to be analyzed is called "Data Hosting CSE" <NUM> and the CSE hosting DAS is defined as "DAS Hosting CSE" <NUM>. In addition, those entities needing data analytics operations provided by DAS are defined as "DAS Clients" <NUM>. In a more general sense, it is worth noting that one CSE node can be as both Data Hosting CSE <NUM> and DAS Hosting CSE <NUM> if the raw data to be analyzed is co-located with DAS <NUM>. In the meantime, the interactions between those entities can happen in mcalmcc/mcc' reference points as shown in <FIG>.

In addition, DAS <NUM> can be equipped with various analytics capabilities. Data analytics is a broad area, and many types of data processing operations can be categorized as a "data analytics service". For example, in a simplistic case, a basic data statistics service may be used for doing mathematical data aggregation operations on a set of raw data (e.g., sensor readings), such as MAX, MIN, AVERAGE, etc. Another example, image processing operation can be provided by DAS when an AE requires to derive useful information from an image if this AE does not have such a capability. Information extraction technology is used when it is required to extract useful data items from a JSON document, a log record, or a webpage, etc. Therefore, on one hand, those different types of data analytics operations will be the common service that DAS <NUM> can leverage the existing various data analytics technologies/tools as plug-ins or export to certain external service portals for providing those data analytics operations. On the other hand, DAS <NUM> itself may provide a common data analytics service to its DAS clients <NUM> by providing uniform interfaces (as shown in <FIG>) and hiding the underlying intricacies of DAS <NUM> from them. It is worth noting that by providing such a feature, the service layer entities (e.g., AEs/CSEs) will just need to interact with DAS <NUM> as a client <NUM> of DAS <NUM>, instead of having to deal with all the underlying details of a proprietary data analytics application.

It is understood that the functionality illustrated in <FIG>, may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a node or apparatus of an M2M network (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in <FIG> or <FIG> described below.

<FIG> shows a high-level operation flow between the several entities as defined in <FIG>. <FIG> includes four main stages. Each of those four stages may include one or more service layer request/response messages, and those details will be illustrated later when the related procedures are described.

In <FIG>, first a DAS client <NUM> initializes a request to DAS hosting CSE <NUM> for certain data analytics operations on its targeted/interested data (shown by Stage <NUM> in <FIG>). Then, a data ingestion process (Stage <NUM> in <FIG>) inputs the data to be analyzed into DAS <NUM>. Typically, the corresponding Data Hosting CSE <NUM> will deliver the raw data to the DAS hosting CSE <NUM>. Alternatively, it is also possible that the DAS client <NUM> may first retrieve the raw data by itself and include it in the payload of request sent to DAS hosting CSE <NUM>. In this case, the Stages <NUM> and <NUM> are combined together. During Stage <NUM>, which normally happens inside DAS <NUM>, DAS <NUM> selects appropriate underlying analytics technologies for conducting specific data analytics operations requested by the DAS clients <NUM>. The working details of those underlying data analytics technologies can be hidden or abstracted from DAS clients <NUM>. Lastly, once the DAS <NUM> works out the analytical results, it can deliver the results to the DAS client <NUM> via the uniform interface (Stage <NUM> in <FIG>).

Overall, the DAS <NUM> adopts the existing underlying technologies and expose a uniform interface to service layer entities. A general architecture design and procedure design to support interaction process between DAS <NUM> and its clients <NUM> from a M2M/IoT network perspective is described below.

<FIG> shows the functionality design inside DAS <NUM>. It is understood that the functionality illustrated in <FIG>, may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a node or apparatus of an M2M network (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in <FIG> or <FIG> described below.

As can be seen, different data analytics capabilities can be added into DAS <NUM> so that various data analytics operations, such as basic data statistics, image processing, information extraction, etc., can be conducted.

Various approaches for adding those underlying data analytics capabilities into DAS <NUM> can be used. If there are already external analytics service portals which can provide data analytic services, the portal access information can be registered or added in DAS <NUM>. Accordingly, once DAS <NUM> receives an analytics request from its client <NUM>, it can use these external service portals in order to obtain the analytical results.

Alternately, if there are available plug-in analytics modules, such modules can be directly plugged into DAS <NUM>, so that data analytics operations can be directly executed locally by the corresponding CSE <NUM> that is running DAS <NUM> (especially for those low-cost lightweight data statistics operation).

Accordingly, DAS <NUM> can be deployed/realized in/by various types of CSEs, e.g., ASN-CSE, MN-CSE (like a Gateway) and IN-CSE (which could be hosted in a cloud). Accordingly, DAS implemented by different CSEs may have variant capacities/capabilities (e.g., the one deployed in the cloud could be more powerful than that deployed on a Gateway).

As mentioned earlier, no matter how the underlying technologies are added into DAS <NUM>, DAS <NUM> will expose them to its clients with uniform service layer APIs. Accordingly, for each type of data analytic service, a Service Type Profile (STP) <NUM> is defined to specify the detailed information related to Application Programming Interface (API). In other words, if a DAS <NUM> has multiple types of data analytics capabilities <NUM>, <NUM> and <NUM> supported by different underlying technologies (in either plug-in or external approach), each of them will have a corresponding STP <NUM>. Typically, an STP <NUM> is published by DAS <NUM> so that the potential clients of DAS <NUM> can discover the available data analytics capability provided by a DAS <NUM>.

In general, the working methodology of DAS <NUM> is as follows: <NUM>) various analytics service capabilities could be offered by a DAS <NUM> by utilizing underlying data analytics tools/technologies; <NUM>) for each type of data analytic capability, a STP <NUM> is defined, which specifies details about this analytics capability e.g., where it is, when it is available, how long it will take for data analytics operation, what it can identify/analyze, and service access details in terms of input/output parameters, i.e., the format of the APIs that the client should use to access the service (i.e. the structure of service layer request/response messages), etc. Overall, how clients discover/refer to the STPs <NUM> of a DAS <NUM> and how to access corresponding DAS <NUM> through uniform APIs (e.g., to send data analytics request and to receive analytical results, etc.) will normally happen over the mcalmcc/mcc' reference points and the detailed procedures will be introduced later.

An internal interface converter <NUM> of the DAS <NUM> can use the STPs <NUM> to convert information from clients <NUM> to the information used for APIs of analytics capacities <NUM>, <NUM>, and <NUM>.

Table <NUM> gives a typical definition for a STP <NUM>, which can be used for describing three major/popular types of data analytics operations, such as basic data statistics, text/information extraction, or image processing.

A number of exemplary procedures are described for interacting with DAS <NUM> and those procedures are applicable for four different cases or scenarios.

Case <NUM> (raw data retrieved by the client): The client <NUM> will first obtain its targeted/interested raw data to be analyzed, and then send it to DAS <NUM> for analyzing.

<FIG> illustrates a procedure for interacting with DAS <NUM> for Case <NUM> and the detailed descriptions are discussed as follows.

Precondition. Data-<NUM> is a piece of data stored in a <contentInstance> resource on CSE-<NUM> (as Data Hosting CSE <NUM>) and AE-<NUM> (as a DAS Client <NUM>) is interested in Data-<NUM>. In the meantime, there is a DAS <NUM> available in the system (hosted by CSE-<NUM>, which is the DAS Hosting CSE <NUM>) and it has published its STPs <NUM> to advertise its available data analytics capabilities. For easy illustration, we consider the example scenario in which DAS Client <NUM>, DAS Hosting CSE <NUM>, Data Hosting CSE <NUM> are acted by different entities, i.e., AE-<NUM>, CSE-<NUM> and CSE-<NUM> respectively (but in fact, as mentioned earlier, DAS Client /DAS Hosting CSE/Data Hosting CSE can also be acted by the same CSE).

In step <NUM> of <FIG>, based on AE-<NUM>'s interest, AE-<NUM> sends a request to CSE-<NUM> for retrieving Data-<NUM>. Note that, this step may be executed multiple times when AE-<NUM> intends to collect multiple data (e.g., numerical sensor readings) from different places in order to conduct "basic data statistics" provided by DAS <NUM> (e. g, calculate the average value of multiple temperature readings). For easy presentation and without losing generality, we only illustrate the case where only one piece of data needs to be analyzed at a time (which is more common for the case where information extraction or image processing type of data analytics operations are executed on e.g., a text document, or an image. More generally, Step-<NUM> could be repeated multiple times if need to retrieving more than one piece of raw data from multiple places, e.g., from multiple <contentInstance> resources on multiple CSEs).

In step <NUM> of <FIG>, Data-<NUM> is returned from CSE-<NUM> to AE-<NUM>. Step <NUM> and Step <NUM> are normal resource retrieval operation. Alternatively, it is also possible that AE-<NUM> may have its own local data that needs to be analyzed. In such a case, a resource retrieval operation (Step <NUM> and Step <NUM>) may be skipped.

In step <NUM> of <FIG>, after getting Data-<NUM>, AE-<NUM> finds that in order to understand or derive the valuable information in Data-<NUM>, it needs an appropriate data analytics operation. Accordingly, AE-<NUM> discovers the STPs published by CSE-<NUM> and identifies an appropriate data analytics operation provided by CSE-<NUM>. Such a STP publishing and discovery process can be done by using any existing service discovery mechanism.

In step <NUM> of <FIG>, AE-<NUM> sends a data analytics request to CSE-<NUM> according to the interface specification as specified in the selected STP, along with Data-<NUM> in the payload, which is the data to be analyzed. In particular, by referring to the "Input_Parameters" data entry as defined in the selected STP file (See Table <NUM> for more details), the request message sent in this step could be constructed as follows: Typically, in addition to the raw data to be analyzed (e.g., an image) which is normally carried in the payload (which needs to be complaint to the format as specified by "Raw_Data_Format" entry in the STP), the message may include the following two mandatory data analytics related parameters:.

In addition, for each type of analytics service (as specified by Analytics_Type entry), it may also include the following different date entries:
When Analytics_Type=" basic data statistics service":
Statistical_Operation (s_o): this item indicates which type of data statistics operations it requires, which is selected from the Supported_Statistical_Operations entry as defined in the STP. For example, the normal data aggregation can be supported by a DAS <NUM>, such as Max, Min, Average, Median, etc..

When Analytics_Type=" information extraction":
Selected_Targeted_Information (s_t_i): For a data analytics service supporting text-related information extraction, it can attract the useful information, e.g., the temperature value or location information from various types of documents, e.g., XML or JASON based documents. Accordingly, this item is to indicate which targeted information can be extracted by using this service, e.g., "time", "location", "temperature", etc., which is selected from the Targeted_Information entry as defined in the STP.

When Analytics_Type=" image processing":.

In step <NUM> of <FIG>, CSE-<NUM> conducts the desired data analytics operation as required by AE-<NUM>, and works out the analytical results.

In step <NUM> of <FIG>, DAS <NUM> returns the analytical results to AE-<NUM>. In this step, the parameters included in the response message will be compliant to the "Output_Parameters" as defined in Table <NUM>. For example, the message may include:.

In step <NUM> of <FIG>, once AE-<NUM> obtains the analytical results from CSE-<NUM>, it can leverage it for further purposes.

The procedure design in Case <NUM> is also applicable to the scenario in which e.g., DAS client <NUM>, DAS Hosting CSE <NUM> and Data Hosting CSE <NUM> are located in different nodes or at least the proximity between DAS Hosting CSE <NUM> and Data Hosting CSE <NUM> is larger than that between DAS client <NUM> and Data Hosting CSE <NUM> (i.e., it makes sense for DAS client <NUM> to retrieve data from Data Hosting CSE <NUM> without incurring unnecessary communication cost).

It is understood that the entities performing the steps illustrated in <FIG> are logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a network apparatus or computer system such as those illustrated in <FIG> or <FIG>. That is, the method(s) illustrated in <FIG> may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a network apparatus, such as the apparatus or computer system illustrated in <FIG> or <FIG>, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in <FIG> It is also understood that any transmitting and receiving steps illustrated in <FIG> may be performed by communication circuitry of the apparatus under control of the processor of the apparatus and the computer-executable instructions (e.g., software) that it executes.

Case <NUM> (raw data retrieved by DAS <NUM>): The client will directly ask DAS <NUM> for certain data analytics operation, and DAS <NUM> will, on behalf of the client, retrieve the targeted/interested raw data to be analyzed.

Precondition (same as Case <NUM>). Data-<NUM> is a piece of data stored in a <contentInstance> resource on CSE-<NUM> (as Data Hosting CSE) and AE-<NUM> (as a DAS client <NUM>) is interested in Data-<NUM>. In the meantime, there is a DAS available in the system (hosted by CSE-<NUM>, which is the DAS Hosting CSE) and it has published its STPs to advertise its available data analytics capabilities.

In step <NUM> of <FIG>, AE-<NUM> first discovers the STPs published by CSE-<NUM> and identifies a desired data analytics operation.

In step <NUM> of <FIG>, AE-<NUM> sends a data analytics request to CSE-<NUM> according to the interface specification as specified in the selected STP. In particular, by referring to the "Input_Parameters" as defined in the selected STP file (See Table <NUM> for more details), the request message sent in this step could be constructed as same as the Step <NUM> in Case <NUM>. More than that, there could be another additional parameter as defined below:
URI_of_Data_To_Be_Analyzed (data_uri): This URI indicates where DAS can retrieve the data that is to be analyzed. Note that, although the example shown in <FIG> illustrates the case in which there is only one piece of data (i.e., Data-<NUM>) to be analyzed by a data analytics request, it is also possible that the required data analytics operations may retrieve multiple piece of data from different locations (especially when the data analytics type is basic data statistics operation, as discussed earlier). In that case, this parameter will include a list of URIs.

In addition, AE-<NUM> may also send related access information so that DAS can successfully access Data-<NUM>, such as access control related information.

In step <NUM> of <FIG>, CSE-<NUM> further sends a request to CSE-<NUM> for retrieving Data-<NUM>.

In step <NUM> of <FIG>, Data-<NUM> is returned from CSE-<NUM> to CSE-<NUM>. As same as Step <NUM> and Step <NUM> of the procedure defined for Case <NUM>, the Step <NUM> and Step <NUM> here are also the normal resource retrieval operation.

Steps <NUM>-<NUM> of <FIG> are the same as Steps <NUM>-<NUM> of the procedure defined for Case <NUM>.

Case <NUM> is more applicable to the scenario in which the proximity between DAS Hosting CSE <NUM> and Data Hosting CSE <NUM> is smaller than that between DAS client <NUM> and Data Hosting CSE <NUM> (i.e., it does not need DAS client <NUM> to retrieve data from Data Hosting CSE <NUM> in order to avoid unnecessary communication cost).

Case <NUM> (Raw Data Discovered and Retrieved by DAS ): Similar to Case <NUM>, AE-<NUM> (as DAS client <NUM>) will directly ask CSE-<NUM> (as DAS Hosting CSE) for certain data analytics raw data to be analyzed. However, the difference here is that in this case, a data analytics operation can be moved and executed at a nearer DAS Hosting CSE <NUM> that is closer to the raw data to be analyzed, instead of at the original DAS Hosting CSE <NUM> (i.e., CSE-<NUM>) that receives the request from AE-<NUM> (note that, "nearer" basically implies less communication overhead, so it could but not necessarily mean a nearer geo-location). It is worth noting that, from a big data perspective, this procedure is well aligned with the current data analytics processing paradigm, i.e., trying to move computing processing to where data is stored, instead of moving data to computing.

<FIG> illustrates a procedure for interacting with DAS in Case <NUM>. In this example scenario, we assume that CSE-<NUM><NUM> and CSE-<NUM><NUM> are located in different places and CSE-<NUM><NUM> is nearer to CSE-<NUM><NUM> than CSE-<NUM><NUM>. Note that, most of steps of <FIG> in Case <NUM> are as same as steps of <FIG> in Case <NUM>. Here, only the difference between these two cases are discussed (as highlighted in green rectangle). As shown in <FIG>, the Step <NUM> and Step <NUM> are defined for CSE-<NUM><NUM> to forward a data analytics request from AE-<NUM><NUM> to CSE-<NUM><NUM> since CSE-<NUM><NUM> is closer to the raw data to be analyzed. Accordingly, the data items carried in the request message of Step <NUM> and Step <NUM> of <FIG> in Case <NUM> will have almost the same message as defined for Step <NUM> of <FIG> in Case <NUM>. More than that, for the Step <NUM> of <FIG> in Case <NUM>, there could be another additional parameter as defined below:.

Accordingly, based on this data item, the AE-<NUM><NUM> may understand that its request in fact has been processed by CSE-<NUM><NUM>, although it sent to the request to CSE-<NUM><NUM>. Alternatively, for future similar requests from AE-<NUM><NUM>, it can directly contact CSE-<NUM><NUM>, or alternatively it still can send requests to the adjacent DAS (i.e., CSE-<NUM><NUM> in this example), and let DAS to make decision where the requests should be forwarded to.

In addition, it is worth noting that although we illustrate the procedure with "proximity"-related consideration, i.e., to move the data analytics operation from the original DAS Hosting CSE <NUM> to another DAS Hosting CSE <NUM> which is nearer to the Data Hosting CSE. However, the procedure can also be used for any other scenarios (not necessarily taking "proximity" as a major metric). For example, as long as one DAS Hosting CSE <NUM> needs to delegate certain analytics operations to other peer DAS Hosting CSEs, the procedure are all applied (e.g., for load balancing, security issue, task migration etc. purposes).

Case <NUM> (Subscription-Based DAS): It is identified that there could be some unique aspects when doing data analytics operations in the context of M2M/IoT systems. For example, a stream of data could be generated by sensors or devices along time, which could be of interest to AEs or CSEs. For example, a traffic evaluation AE may intend to continually analyze the images generated by an outdoor camera on a highway. Similarly, in some situations, a client may request a data analytics operation at DAS before the raw data to be analyzed become available. Accordingly, Case <NUM> focuses on a subscription-based paradigm for interacting with DAS.

<FIG> illustrate the procedure for interacting with DAS in Case <NUM>. Note that, most of steps in Case <NUM> are as same as steps in Case <NUM>. Here, only the differences between these two cases are discussed (as highlighted in blue rectangle). For example, instead of the DAS client <NUM> being interested in a specific piece of data, in this case, AE-<NUM> may be interested in a whole <container-<NUM>> resource on CSE-<NUM><NUM>. In particular, client will be interested in new available data input into the container and require periodical data analytics operations on this data. In the meantime, the data items carried in the request message of Step <NUM> of <FIG> will have almost the same message as defined for Step <NUM> of <FIG> in Case <NUM>. More than that, there could be additional parameter as defined below:.

In addition, the Steps <NUM>-<NUM> of <FIG> in Case <NUM> just illustrate a normal subscription operation initialized by CSE-<NUM><NUM>(i.e., the DAS Hosting CSE) in order to make notifications to CSE-<NUM> about the new available data in the <container> resource. Accordingly, in Step <NUM> of <FIG>, for each received notification, it is up to CSE-<NUM><NUM> to decide whether to retrieve the new data for analyzing by referring to the analytics frequency or schedule as specified by AE-<NUM><NUM> in Step <NUM> of <FIG>. If CSE-<NUM><NUM> decides to analyze the new data, it will further retrieve the new data from CSE-<NUM><NUM> and the remaining procedure is similar to the previous cases.

The above process is using a traditional service subscription approach for DAS access. Alternatively, AE-<NUM><NUM> may also leverage oneM2M <subscription> resource to achieve the same purpose. For example, during Step <NUM> of <FIG>, AE-<NUM><NUM> can create a <container> resource on DAS Hosting CSE <NUM> in order to store analytical results. In the meantime, it also creates a <subscription> resource under this <container> resource. Accordingly, on the DAS side, as same as Step <NUM> of <FIG>, it can conduct the desired data analytics operations based on AE-<NUM>'s needs and then put those analytics results as <contentInstance> resources into the <container> resource, which will further trigger notifications to be sent to AE-<NUM><NUM>(e.g., according to certain notification criteria set by AE-<NUM><NUM>).

It is understood that the entities performing the steps illustrated in <FIG> are logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a network apparatus or computer system such as those illustrated in <FIG> or <FIG>. That is, the method(s) illustrated in <FIG> may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of a network apparatus, such as the apparatus or computer system illustrated in <FIG> or <FIG>, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in<FIG> It is also understood that any transmitting and receiving steps illustrated in <FIG> may be performed by communication circuitry of the apparatus under control of the processor of the apparatus and the computer-executable instructions (e.g., software) that it executes.

oneM2M is currently in the process of defining capabilities supported by the oneM2M service layer. These capabilities are referred to as Capability Service Functions (CSFs). The oneM2M service layer is referred to as a Capability Services Entity (CSE). Accordingly, the DAS could be regarded as a CSF implemented by a CSE, as shown in <FIG> (Alternatively, it can also be part of the existing Data Management and Repository (DMR) CSF defined in oneM2M TS-<NUM>). Accordingly, the procedure as well as the new parameters mainly happen on mca and mcc/mcc' reference point as illustrated in <FIG>. It should be that, different types of M2M nodes can implement DAS, such as M2M Gateway, M2M Server, M2M Devices, etc. In particular, depending on the various/different hardware/software capacities for those nodes, the functionalities/capacities of DASs implemented by those nodes may also be variant.

It is understood that the functionality illustrated in <FIG>, may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, a node of an M2M network (e.g., a server, gateway, device, or other computer system), such as one of those illustrated in <FIG> or <FIG> described below.

Two new oneM2M resources are defined in order to enable DAS. In particular, since service type profiles are defined to be exposed to potential clients of DAS, a new resource called <STP> is used to describe a STP <NUM>, which is shown in <FIG>. Accordingly, by accessing those <STP> resources, the clients can easily understand which data analytics operations are available. In the meantime, such <STP> resources can be published at different CSEs in the network in order to facilitate discovery of the DAS clients. In particular, the "accessPortalAddress" attribute defined in this resource is to indicate how to really access this corresponding DAS for this STP <NUM> (i.e., where to send the request message to the DAS Hosting CSE <NUM>). Accordingly, a new resource called <DAS> is used shown in <FIG>, which is normally as a child resource of the DAS Hosting CSE <NUM> and the URI of this resource will be included in the previously-mentioned accessPortalAddress attribute of the corresponding <STP> resource. Since <DAS> is just an access portal, it could just include common attributes for service layer resources, which is not shown in <FIG>. Accordingly, all the requests of DAS clients (as well as the raw data to be analyzed which is normally stored in the <contentInstance> resources) will be sent to the address specified by the "accessPortalAddress" attribute and those requests can use either CREATE or UPDATE requests as defined in the service layer (UPDATE is suggested since there will no new resource to be created when sending data analytics requests to a DAS). In addition, the resource structure of <STP> is based on the definition of STP <NUM> and the meanings of attributes of <STP> resource are as same as those introduced in Table <NUM>.

Interfaces, such as Graphical User Interfaces (GUIs), can be used to assist user to control and/or configure functionalities related to enabling Data Analytics. As introduced above, a new DAS common service is used for a Service Layer. In particular, in order for a human administrator to monitor how those DAS services are running, <FIG> shows a GUI <NUM> for checking the whole system view. For example, human could be allowed to examine a specific type of data analytics operation run by DAS, e.g., image processing, or information extraction, etc. (e.g., by inputting the specific types of data analytics operation that the user intends to check as shown in <FIG> or alternatively let users pick options from various data analytics operations via a dropdown). In addition, human administrator could monitor whether the underlying data analytics components are working properly. In the meantime, since each type of data analytics operation are exposed through STPs <NUM>, the GUI <NUM> also allow administrator to examine the details of STPs <NUM>, especially for those dynamically-changing data items in STP <NUM>, such as the service availability and statistical information on the confidence interval of the analytical results. In addition, it also allows the administrator to check for each specific STP <NUM>, which clients have accessed and used them in order to understand the utilization ratio of various types of data analytics operations provided by DAS. For example, <FIG> shows an output panel interface <NUM> when the administrator selected to check an image-processing type of STP <NUM>, in which the details of this STP <NUM> has been displayed to the user for their reference. It is to be understood that interfaces <NUM> and <NUM> can be produced using displays such as those shown in <FIG> described below.

The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms "apparatus," "network apparatus," "node," "device," and "network node" may be used interchangeably.

The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

<FIG> is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system <NUM> in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT/WoT as well as an IoT/WoT service layer, etc. Communication system <NUM> can be used to implement functionality of the disclosed embodiments and can include functionality and logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM>.

As shown in <FIG>, the M2M/ IoT/WoT communication system <NUM> includes a communication network <NUM>. The communication network <NUM> may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network <NUM> may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network <NUM> may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network <NUM> may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

As shown in <FIG>, the M2M/ IoT/WoT communication system <NUM> may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different network nodes (e.g., servers, gateways, device, and the like). For example, the Field Domain may include M2M gateways <NUM> and terminal devices <NUM>. It will be appreciated that any number of M2M gateway devices <NUM> and M2M terminal devices <NUM> may be included in the M2M/ IoT/WoT communication system <NUM> as desired. Each of the M2M gateway devices <NUM> and M2M terminal devices <NUM> are configured to transmit and receive signals, using communications circuitry, via the communication network <NUM> or direct radio link. A M2M gateway <NUM> allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network <NUM> or direct radio link. For example, the M2M terminal devices <NUM> may collect data and send the data, via the communication network <NUM> or direct radio link, to an M2M application <NUM> or other M2M devices <NUM>. The M2M terminal devices <NUM> may also receive data from the M2M application <NUM> or an M2M terminal device <NUM>. Further, data and signals may be sent to and received from the M2M application <NUM> via an M2M service layer <NUM>, as described below. M2M terminal devices <NUM> and gateways <NUM> may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wireline for example.

Exemplary M2M terminal devices <NUM> include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

Referring to <FIG>, the illustrated M2M service layer <NUM> in the field domain provides services for the M2M application <NUM>, M2M gateway devices <NUM>, and M2M terminal devices <NUM> and the communication network <NUM>. Communication network <NUM> can be used to implement functionality of the disclosed embodiments and can include functionality and logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM>. The M2M service layer <NUM> may be implemented by one or more servers, computers, devices, virtual machines (e.g. cloud/ storage farms, etc.) or the like, including for example the devices illustrated in <FIG> and <FIG> described below. It will be understood that the M2M service layer <NUM> may communicate with any number of M2M applications, M2M gateways <NUM>, M2M terminal devices <NUM>, and communication networks <NUM> as desired. The M2M service layer <NUM> may be implemented by one or more nodes of the network, which may comprises servers, computers, devices, or the like. The M2M service layer <NUM> provides service capabilities that apply to M2M terminal devices <NUM>, M2M gateways <NUM>, and M2M applications <NUM>. The functions of the M2M service layer <NUM> may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc..

Similar to the illustrated M2M service layer <NUM>, there is the M2M service layer <NUM>' in the Infrastructure Domain. M2M service layer <NUM>' provides services for the M2M application <NUM>' and the underlying communication network <NUM> in the infrastructure domain. M2M service layer <NUM>' also provides services for the M2M gateways <NUM> and M2M terminal devices <NUM> in the field domain. It will be understood that the M2M service layer <NUM>' may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M service layer <NUM>' may interact with a service layer by a different service provider. The M2M service layer <NUM>' by one or more nodes of the network, which may comprises servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.

Referring also to <FIG>, the M2M service layers <NUM> and <NUM>' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications <NUM> and <NUM>' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layers <NUM> and <NUM>' also enable M2M applications <NUM> and <NUM>' to communicate through networks <NUM> in connection with the services that the service layers <NUM> and <NUM>' provide.

The methods of the present application may be implemented as part of a service layer <NUM> and <NUM>'. The service layer <NUM> and <NUM>' is a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that may contain the connection methods of the present application. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). Further, connection methods of the present application can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource-oriented architecture (ROA) to access services such as the connection methods of the present application.

In some embodiments, M2M applications <NUM> and <NUM>' may be used in conjunction with the disclosed systems and methods. The M2M applications <NUM> and <NUM>' may include the applications that interact with the UE or gateway and may also be used in conjunction with other disclosed systems and methods.

In one embodiment, the logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM> may be hosted within a M2M service layer instance hosted by an M2M node, such as an M2M server, M2M gateway, or M2M device, as shown in <FIG>. For example, the logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM> may comprise an individual service capability within the M2M service layer instance or as a sub-function within an existing service capability.

The M2M applications <NUM> and <NUM>' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications <NUM> and <NUM>'.

Generally, the service layers <NUM> and <NUM>' define a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the service layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a service layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in <FIG> or <FIG> described below.

Further, logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM> can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a Resource-Oriented Architecture (ROA) to access services of the present application.

<FIG> is a block diagram of an example hardware/software architecture of a M2M network node <NUM>, such as an M2M device <NUM>, an M2M gateway <NUM>, an M2M server, or the like. The node <NUM> can execute or include logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM>. The device <NUM> can be part of an M2M network as shown in <FIG> or part of a non-M2M network. As shown in <FIG>, the M2M node <NUM> may include a processor <NUM>, non-removable memory <NUM>, removable memory <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display, touchpad, and/or indicators <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>. The node <NUM> may also include communication circuitry, such as a transceiver <NUM> and a transmit/receive element <NUM>. It will be appreciated that the M2M node <NUM> may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the functionality described herein.

In general, the processor <NUM> may execute computer-executable instructions stored in the memory (e.g., memory <NUM> and/or memory <NUM>) of the node in order to perform the various required functions of the node. For example, the processor <NUM> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the M2M node <NUM> to operate in a wireless or wired environment. The processor <NUM> may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor <NUM> may also perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

As shown in <FIG>, the processor <NUM> is coupled to its communication circuitry (e.g., transceiver <NUM> and transmit/receive element <NUM>). The processor <NUM>, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node <NUM> to communicate with other nodes via the network to which it is connected. In particular, the processor <NUM> may control the communication circuitry in order to perform the transmitting and receiving steps described herein and in the claims.

The transmit/receive element <NUM> may be configured to transmit signals to, or receive signals from, other M2M nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit/receive element <NUM> may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element <NUM> may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. It will be appreciated that the transmit/receive element <NUM> may be configured to transmit and/or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element <NUM> is depicted in <FIG> as a single element, the M2M node <NUM> may include any number of transmit/receive elements <NUM>. More specifically, the M2M node <NUM> may employ MIMO technology. Thus, in an embodiment, the M2M node <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals.

As noted above, the M2M node <NUM> may have multi-mode capabilities. Thus, the transceiver <NUM> may include multiple transceivers for enabling the M2M node <NUM> to communicate via multiple RATs, such as UTRA and IEEE <NUM>, for example.

The processor <NUM> may access information from, and store data in, any type of suitable memory, such as the non-removable memory <NUM> and/or the removable memory <NUM>. For example, the processor <NUM> may store session context in its memory, as described above. In other embodiments, the processor <NUM> may access information from, and store data in, memory that is not physically located on the M2M node <NUM>, such as on a server or a home computer. The processor <NUM> may be configured to control visual indications on the display to reflect the status of the system or to obtain input from a user or display information to a user about capabilities or settings. A graphical user interface, which may be shown on the display, may be layered on top of an API to allow a user to interactively do functionality described herein.

The processor <NUM> may receive power from the power source <NUM>, and may be configured to distribute and/or control the power to the other components in the M2M node <NUM>. The power source <NUM> may be any suitable device for powering the M2M node <NUM>.

The processor <NUM> may also be coupled to the GPS chipset <NUM>, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the M2M node <NUM>. It will be appreciated that the M2M node <NUM> may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

For example, the peripherals <NUM> may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

The node <NUM> may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node <NUM> may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals <NUM>. Alternately, the node <NUM> may comprise apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane.

<FIG> is a block diagram of an exemplary computing system <NUM> which may also be used to implement one or more nodes of an M2M network, such as an M2M server, gateway, device, or other node. Computing system <NUM> may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Computing system <NUM> can execute or include logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM>. Computing system <NUM> can be an M2M device, user equipment, gateway, UE/GW or any other nodes including nodes of the mobile care network, service layer network application provider, terminal device <NUM> or an M2M gateway device <NUM> for example. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) <NUM>, to cause computing system <NUM> to do work. In many known workstations, servers, and personal computers, central processing unit <NUM> is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit <NUM> may comprise multiple processors. Coprocessor <NUM> is an optional processor, distinct from main CPU <NUM>, that performs additional functions or assists CPU <NUM>. CPU <NUM> and/or coprocessor <NUM> may receive, generate, and process data related to the disclosed systems and methods for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.

In operation, CPU <NUM> fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus <NUM>. Such a system bus connects the components in computing system <NUM> and defines the medium for data exchange. System bus <NUM> typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus <NUM> is the PCI (Peripheral Component Interconnect) bus.

Memories coupled to system bus <NUM> include random access memory (RAM) <NUM> and read only memory (ROM) <NUM>. Such memories include circuitry that allows information to be stored and retrieved. ROMs <NUM> generally contain stored data that cannot easily be modified. Data stored in RAM <NUM> can be read or changed by CPU <NUM> or other hardware devices. Access to RAM <NUM> and/or ROM <NUM> may be controlled by memory controller <NUM>. Memory controller <NUM> may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller <NUM> may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

In addition, computing system <NUM> may contain peripherals controller <NUM> responsible for communicating instructions from CPU <NUM> to peripherals, such as printer <NUM>, keyboard <NUM>, mouse <NUM>, and disk drive <NUM>.

Display <NUM>, which is controlled by display controller <NUM>, is used to display visual output generated by computing system <NUM>. Such visual output may include text, graphics, animated graphics, and video. Display <NUM> may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller <NUM> includes electronic components required to generate a video signal that is sent to display <NUM>.

Further, computing system <NUM> may contain communication circuitry, such as for example a network adaptor <NUM>, that may be used to connect computing system <NUM> to an external communications network, such as network <NUM> of <FIG> and <FIG>, to enable the computing system <NUM> to communicate with other nodes of the network.

User equipment (UE) can be any device used by an end-user to communicate. It can be a hand-held telephone, a laptop computer equipped with a mobile broadband adapter, or any other device. For example, the UE can be implemented as the M2M terminal device <NUM> of <FIG> or the device <NUM> of <FIG>.

It is understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a node of an M2M network, including for example an M2M server, gateway, device or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above, including the operations of the gateway, UE, UE/GW, or any of the nodes of the mobile core network, service layer or network application provider, may be implemented in the form of such computer executable instructions. Logical entities such as M2M area network, <NUM> M2M gateway, M2M server, service layer <NUM>, Common Services Entity (CSE) <NUM>, Application Entity (AE) <NUM>, camera <NUM>, Gateway <NUM>, Data Analytics Service (DAS) <NUM>, DAS hosting CSE <NUM> and <NUM>, Data Hosting CSE <NUM>, DAS clients <NUM>, Service Type Profile (STP) <NUM>, analytics capacity <NUM>, <NUM>, and <NUM>, and logical entities to create interfaces such as interfaces <NUM> and <NUM> may be embodied in the form of the computer executable instructions stored on a computer-readable storage medium. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computer.

In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claim 1:
A method performed by a service entity (<NUM>) for a service supporting service capabilities through a set of application programming interfaces, APIs, in a network, the method comprising:
receiving, from an application entity (<NUM>) via the network, a request to perform a data analytics operation on data, the request identifying a type of data analytics capability (<NUM>, <NUM>, <NUM>) capable of performing the requested data analytics operation, the request further comprising one or more parameters required by the identified type of data analytics capability, the required parameters being specified in a profile (<NUM>) defined for the identified type of data analytics capability;
forwarding the received request to another service entity (<NUM>) for the service in the network having a closer proximity to the data on which the requested data analytics operation is to be performed;
receiving, from the another service entity (<NUM>), a response to the requested data analytics operation on the data.