Method for enabling data analytics services at service layer

Abstract

The present invention relates to a method for enabling data analytics services at a service layer. A common data analytics service (DAS) at the service layer is designed to use underlying existing / future data analytics techniques or tools and provide them to service layer entities that need those data analytics operations with a uniform access method. A generic operation framework / interface is designed to enable the DAS and the operational details within the DAS. Procedures for interacting with the DAS including new parameters in service layer request / response messages can be used.

Description

[0001] This application is a divisional application of the invention patent application filed on April 25, 2017, with application number 201780036159.0 and entitled "Method for Enabling Data Analysis Services at the Service Layer".

[0002] Cross-references to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62 / 326,881, filed April 25, 2016, the disclosure of which is incorporated herein by reference in its entirety. Background Technology

[0004] In recent years, the amount of data in our world has been exploding. Google processes hundreds of petabytes (PB) of search data, and Facebook generates over 10 PB of log data per month (survey on big data systems, SCIENCE CHINA InformationSciences, 2015). As a result of this surge in global data, the term "big data" has been coined to describe massive datasets. Compared to traditional datasets, big data can include vast amounts of unstructured data that need to be analyzed to gain in-depth insights, such as how to discover potential purchases from a customer's shopping history.

[0005] McKinsey & Company offers a more formal definition of big data, as follows: "Big data refers to datasets that cannot be obtained, stored, and managed using traditional database software." This definition includes two meanings:

[0006] - The size of datasets that conform to big data measurement / standards is changing and growing over time or with technological advancements. Currently, big data typically ranges from a few terabytes to a few petabytes.

[0007] - The size of datasets that meet the standards for big data varies across different applications.

[0008] Refer to several "V"s (such as Figure 1 Another popular definition of big data (as shown):

[0009] - Volume means that as large amounts of data are generated and collected, the data scale becomes larger and larger. For example, as mentioned in the earlier example, the data generated by Internet companies can easily reach 10 PB per day.

[0010] Variety indicates the various types of data, which include semi-structured and unstructured data such as audio, video, web pages and text as well as traditional well-defined structured data like database tables.

[0011] Velocity means the timeliness of big data, in particular, data collection and analysis must be done quickly and in a timely manner in order to maximize the business value of big data.

[0012] Value means the useful knowledge / insights that exist in the data but are hidden in very low density.

[0013] In addition, more "V"s can be defined, for example: Veracity should deal with uncertain or inaccurate data, etc.

[0014] Currently, due to the potential of new business and value, all walks of life are more interested in the high potential of big data, and many government agencies and academia have announced major plans to accelerate big data research and application.

[0015] It is worth noting that the emergence of the Internet of Things (IoT) is a major trend driving the growth of big data, which generally refers to sensors and devices embedded in the physical world and connected to computing resources through networks.

[0016] As shown in Figure 2 , McKinsey research estimates that the number of connected IoT nodes deployed in the world is expected to grow at a rate of more than 30% per year. Some of the sectors expected to grow are utilities, as these operators install more smart meters and smart appliances; healthcare, as the sector deploys remote health monitoring; retail, which will eventually increase the use of radio frequency identification (RFID) tags; and the automotive industry, which will increasingly install sensors in vehicles.

[0017] The value chain of big data can be generally divided into four stages: data generation, data collection, data storage and data analysis (see Figure 3 ). If we take data as raw materials, data generation and data collection are development processes, data storage is a storage process and data analysis is a production process that uses raw materials to create new value. A brief introduction to each of the four stages is presented below.

[0018] Data generation is the first step of big data. As mentioned earlier, large amounts of data are generated. For example, search entries, web forum posts, chat logs, 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 from IoT / M2M systems, videos, click streams, and / or all other available data sources, among others.

[0019] Data collection is the second phase of big data systems. Big data collection includes data gathering, data transmission, etc. During big data collection, efficient transmission mechanisms are needed in order to send data to the appropriate storage management system to support different analytics applications. The collected data sets can sometimes include a large amount of redundant or meaningless data, which unnecessarily increases storage space and affects subsequent data analysis. For example, high redundancy is very common in data sets collected by sensors for environmental monitoring. Data compression techniques can be applied to reduce this redundancy.

[0020] The third phase, i.e., big data storage, refers to the storage and management of large-scale data sets while achieving reliability and availability of data access. Typically, it deals with large, scalable, and generally distributed storage systems. On one hand, the storage infrastructure needs to provide scalable and reliable information storage services; on the other hand, it must provide a powerful access interface for querying and analyzing large amounts of data.

[0021] The fourth phase is about data analysis. Analysis of big data mainly involves the analysis methods applied to the collected data. Data analysis is the most important phase in the value chain of big data, with the aim of extracting useful value, providing insights for business operations, etc. Different levels of potential value can be generated through analysis of data sets in different fields. Therefore, it is worth noting that data analysis is a broad range or concept that frequently changes and is extremely complex, as exemplified in Figure 3

[0022] A large number of existing data analysis products on the market are briefly discussed below. These products are not necessarily related to the service layer concept.

[0023] ​Google Analytics is a free web analytics service offered by Google that tracks and reports website traffic. Google Analytics is implemented using "page tags" and relies on a proprietary Google Analytics tracking code (currently called Analytics.js) that is a piece of JavaScript code that website owners add to every page of their website. Then, if JavaScript is enabled in the browser, the tracking code runs in the client's browser when the client browses the page. The code collects visitor data and sends it to Google's data collection servers. The user first registers and sets up a user account in the Google Analytics platform. The details of the user account are also included in the Analytics.js code so that the data collected by the tracking code can be sent to the correct user account. Figure 4 A general architecture of Google Analytics is shown.

[0024] Currently, Google Analytics provides analytics services for three different application scenarios:

[0025] 1) Websites and web applications that use the Analytics.js mentioned above to collect user behavior data on the website or web application (as shown in Figure 4

[0026] 2) Mobile applications that use APIs or sample code provided by Google Analytics to collect various data related to mobile applications running on Android or iOS platforms;

[0027] 3) Other application scenarios, Google Analytics also provides measurement protocols for any entity (e.g. IoT devices) to send data to the Google Analytics server.

[0028] Further, in addition to the data collected by Google Analytics, it is also possible to find deep / hidden insights when mining data from multiple sources such as enterprise databases or customer relationship management (CRM) systems. Therefore, Google now delivers Google Analytics Premium and Google BigQuery integration. By automatically importing logs from Google Analytics Premium to Google BigQuery integration, users can easily write SQL queries to correlate their website visitor activity with other valuable business data such as point-of-sale records, online shopping history, and user login logs. Using this combined insight into their customers, users can then generate custom ad retargeting data for Google AdWords and DoubleClick.

[0029] ​IBM recently announced Watson Analytics, a natural language based data analytics product. Watson Analytics gives users the benefits of sophisticated analytics without the complexity. For example, it allows non-expert personnel to perform various data analytics assisted by Watson Analytics, such as from loading data, exploring data, making predictions on data, and enabling easy dashboard and infographic creation for visualizing the results of the analytics. At the same time, it allows users to analyze their uploaded data by simply typing questions in human understandable natural language, and Watson Analytics' natural language processing agent will automatically suggest satisfactory analytics jobs to the user.

[0030] Figure 5 A brief overview of IBM Watson Analytics is shown. It is worth noting that the target customers of this product are human users, and it is not specifically designed to support data analytics in M2M / IoT scenarios, which is the focus of this work.

[0031] In addition to the above Watson Analytics, IBM has another type of product, called Watson Developer Cloud, which is a proprietary collection of REST APIs and software development kits (SDKs) for more complex analytics tasks using artificial intelligence techniques. Figure 6 Available data analytics services provided by Watson Developer Cloud are shown. For example, for the visual recognition service, a user can send an HTTP request to the 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 techniques and return to the user the analysis results, which contain a list of possible content depicted in the image and a confidence level related to each of these possibilities.

[0032] 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 data centers and Microsoft-partner-hosted data centers. Specifically, Azure provides multiple different types of services related to data analytics, such as Microsoft Machine Learning Service, Stream Analytics, and HDInsight. The infrastructure of the services related to data analytics used by Microsoft Azure is shown in Figure 7 and it is highly relevant to M2M / IoT scenarios, since most of the data in M2M / IoT systems will be data streams. In the following, we provide a brief introduction to each of these data analytics services.

[0033] Microsoft Azure Machine Learning Service: Generally, machine learning uses computers to run predictive models that learn from existing data in order to predict future behavior, outcomes, and trends. Azure Machine Learning is a powerful cloud-based predictive analytics service that enables fast creation and deployment of predictive models as analytic solutions. Azure Machine Learning provides tools for creating complete predictive analytics solutions in the cloud: fast creation, testing, implementation, and management of predictive models, and users do not need to purchase any hardware or manually manage virtual machines. Notably, the service is still targeted at human professionals to facilitate their machine learning related tasks.

[0034] Microsoft Azure Stream Analytics: The Stream Analytics service provides low-latency, highly available, scalable complex event processing on streaming data in the cloud. Azure Stream Analytics is a cost-effective real-time event processing engine that helps unlock deep insights from data. Microsoft Azure Stream Analytics can easily set up real-time analytic processing on data streams from devices, sensors, websites, social media, applications, infrastructure systems, and the like (similar products developed by other companies include SQL Stream and IBM InfoSphere Streams, among others). For example, with a few clicks in the Azure portal, a user can create a Stream Analytics job by specifying the input source of the streaming data, the data analytic processing tasks expressed in a SQL-like language, and the output sink for the results of the Stream Analytics job. In contrast to the previous machine learning service, which is more focused on traditional ways of predictive analytics in batch processing, i.e., data is first collected together before being processed, the stream analytics paradigm emphasizes on doing on-the-fly data analytic operations, i.e., data is analyzed as they flow through the data analytic engine.

[0035] Microsoft HDInight: Apache Hadoop is an open source software framework written in Java for distributed storage and distributed processing of very large data sets on clusters of commodity software-built computers (see later section for more details). It is the actual large-scale data processing infrastructure for big data related applications. Therefore, many companies built their various data analysis related services on top of the Hadoop framework (i.e., the Hadoop system is the backend infrastructure). Moreover, to help those professionals who aim to work with Hadoop, many companies provide cloud-based Hadoop distribution from the perspective of deploying and provisioning Apache Hadoop clusters in the cloud, thus providing a software framework designed for high reliability and availability to manage, analyze and report big data related tasks, such as Microsoft HDInight (i.e. users do not need to buy any software nor need to manually manage virtual machines or any other resources, they just need to implement these by utilizing the services provided by the HDInsight service offered by the Microsoft Azure cloud platform).

[0036] In addition to the above data analysis services provided by major software companies (although some of them are not directly designed for M2M / IoT scenarios), there are also some IoT oriented platforms, which can be equipped with certain data analysis capabilities.

[0037] Intel IoT Platform is an end-to-end reference model and product family from Intel that works with third-party solutions to provide a foundation for seamlessly and securely connected devices, deliver trusted data to the cloud, and deliver value through analytics. Specifically, Intel provides a cloud-based analytics system for IoT, which includes resources provided by Intel IoT Developer Kit for collection and analysis of sensor data. Using this service, IoT developers have the ability to quickly start data collection and analysis without having to invest in large-scale storage and processing capabilities.

[0038] Figure 8 A general architecture of Intel IoT Analytics is shown, where its IoT Developer Kit allows users to configure edge devices (e.g. Intel's Galileo / Edison devices) and send data to a centralized cloud platform where data analysis tasks can be performed. Developers can also access and configure the IoT Analytics account in the cloud through a laptop.

[0039] Figure 9 A user dashboard of Intel IoT Analytics is shown, where users can perform tasks related to different analytics, e.g. monitoring data sent from sensors (or other edge devices), configuring or controlling edge devices.

[0040] Other companies, such as Cumulocity, Xively, Keen.io, etc., provide services or products similar to the Intel IoT Platform. Notably, most of those services and products are based on proprietary solutions from the perspective of each of these companies having their own development tools, API specifications and documentation, etc.

[0041] Apache Hadoop is an open source framework for distributed storage and processing of large data sets on commercial hardware. Hadoop enables businesses to gain insights from large amounts of structured and unstructured data quickly.

[0042] Many Apache Software Foundation projects make up the services that enterprises need to deploy, integrate, and work with Hadoop. Each project is developed for a specific function and each has its own community of developers and individual release cycles. Figure 10 An overview of the Apache Hadoop ecosystem is shown.

[0043] As mentioned earlier, the Hadoop ecosystem is the actual large-scale data processing infrastructure for applications related to big data, and many companies build their services or products related to various data analytics on top of the Hadoop framework. For example, a company can provide weather forecast services to its users, where the services are exposed to the users through a simple RESTful interface. A user can simply send a hypertext transfer protocol (HTTP) request to the service portal to get a weather forecast without knowing any details about how the forecast is done (in these cases, the company can utilize the Hadoop infrastructure on the backend to process big data in order to make the weather forecast).

[0044] A typical machine-to-machine (M2M) system architecture is shown in Figure 11 The M2M area network 1102 provides connectivity between M2M end devices and M2M gateways (GWs) 1104. Examples of M2M area networks include personal area networks based on technologies such as IEEE 802.15, Zigbee, Bluetooth, etc. The M2M end devices communicate with the M2M GWs and, ultimately, with a M2M server 1106, 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 acting as controllers (e.g., light switches). However, there are also a number of resource-rich entities, e.g., home appliances with power supply, mobile phones, vehicles, and other industrial devices.

[0045] From a protocol stack perspective, the service layer 1202 is typically located above the application protocol layer 1206 and provides value-added services (e.g., device management, data management, etc.) to the applications 1204 (see Figure 1 1 1 for an illustration of the Figure 12 ) or to another service layer. Thus, the service layer is often classified as a "middleware" service.

[0046] An example deployment of M2M / IoT service layers instantiated within a network is shown in Figure 13 . In this example, a service layer instance is an implementation of a service layer. Multiple service layer instances are deployed on various network nodes (i.e., gateways and servers) for providing value-added services to network applications, device applications, and to the network nodes themselves. Recently, multiple industry standard organizations (e.g., oneM2M oneM2M-TS-0001, oneM2M Functional Architecture-V-2.3.0) have been developing M2M / IoT layers to address challenges associated with M2M / IoT type of devices and applications integration into deployments such as the Internet, cellular networks, enterprise networks, and home networks.

[0047] The M2M service layer can provide applications and devices with access to a collection of M2M-oriented service capabilities. A number of examples of these capabilities include security, billing, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via an application programming interface (API) that uses message primitives defined by the M2M service layer.

[0048] The goal of oneM2M is to develop technical specifications that address the need for a common, M2M service layer that can be embedded within various hardware and software devices, and applications that will work within a variety of industries. The oneM2M common service layer supports a group of common service functions (CSFs) (i.e., service capabilities) as shown in Figure 14 An instantiation of a set of one or more specific types of CSFs is referred to as a common service entity (CSE) 1402, which can be hosted on different types of network nodes (e.g., infrastructure nodes (INs) and middle nodes (MNs), as well as application specific nodes (ASNs)). These CSEs are referred to as IN-CSE, MN-CSE, and ASN-CSE, respectively, as defined in oneM2M-TS-0001, oneM2M Functional Architecture-V-2.3.0. The CSE 1402 provides service capabilities to other CSEs as well as to application entities (AEs) 1404. Typically, an AE 1404 represents an instantiation of application logic for an end-to-end M2M solution, and examples of AEs 1404 can be instances of a transportation fleet tracking application, a remote blood glucose monitoring application, an electricity metering application, or a control application.

[0049] Initially, oneM2M service layer was developed to conform to the Resource Oriented Architecture (ROA) (oneM2M-TS-0001, oneM2M Functional Architecture-V-2.3.0) design principles (as shown in Figure 15 ). Resources are the only addressable elements in this architecture and can be manipulated via RESTful methods such as create, retrieve, update, and delete. These resources are addressable using Uniform Resource Locators (URLs). A resource can contain child resource(s) and attribute(s).

[0050] Recently, oneM2M has started developing an M2M service component architecture (as shown in Figure 16 ) to consider deployments that are not RESTful based. This architecture is first suited to the infrastructure domain where a CSE 1402 is considered as a set of service components. It mainly reuses the existing service layer architecture shown in Figure 15 , but within this service layer, it organizes various M2M services and multiple services into service components. In addition to the existing reference points, a service oriented architecture (SOA) architecture introduces an inter-service reference point Msc. Communication between M2M service components (over the Msc reference point) utilizes network service methods, which is the most popular technology for building SOA based software systems. SUMMARY

[0051] A common data analytics service (DAS) at the service layer is designed to use underlying existing / future data analytics techniques or tools and provide them to service layer entities that need those data analytics operations using a uniform access method. A generic operation framework / interface design can enable the DAS and the operation details within the DAS. The related procedures for interacting with the DAS can include new parameters in the service layer request / response messages.

[0052] A generic operation framework for enabling the DAS defines how the DAS works at the service layer. The operation details and functionality design within the DAS allows different types of data analytics capabilities (such as basic data statistics, information extraction, image processing, etc.) to be added to the DAS and exposed to the clients (i.e., AE or CSE) of the DAS through the uniform interface exposed by the DAS.

[0053] In particular, for a given type of underlying data analytics operation added to or plugged into the DAS, a service type profile (STP) is defined to specify the details of its corresponding uniform interface and access information.

[0054] Several procedures for interacting with DAS are described. These procedures are typically applied to four different situations / scenarios:

[0055] Scenario 1: The DAS client first obtains the raw data it is interested in analyzing and then sends it to the DAS for analysis.

[0056] Scenario 2: The client will directly request DAS to perform some kind of data analysis operation, and DAS will retrieve the target / interesting raw data to be analyzed on behalf of the client.

[0057] Scenario 3: Considering the large / massive scale of data in the context of the big data scenario in this case, instead of moving the data to a DAS for processing, the data analysis processing is moved to a DAS closer to the target data.

[0058] Case 4: A subscription-based paradigm for interacting with DAS is defined to take into account the typical characteristics of M2M / IoT systems.

[0059] The new service DAS can be represented as a new CSF at the service layer to provide public data analytics services. A new oneM2M resource has also been defined to represent STP.

[0060] It also describes the user interface for supporting real-time monitoring and configuration in DAS.

[0061] This summary is provided to introduce, in a simplified form, some concepts that will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the disadvantages pointed out in any part of this disclosure. Attached Figure Description

[0062] A more detailed understanding can be obtained by referring to the accompanying drawings and the following description, which is given by way of example, wherein:

[0063] Figure 1 This is a diagram illustrating the definition of big data.

[0064] Figure 2 This is a graph illustrating the growth of the Internet of Things (IoT).

[0065] Figure 3 This is a diagram illustrating the value chain of big data.

[0066] Figure 4 This is a diagram illustrating the general architecture of Google Analytics.

[0067] Figure 5 This is a diagram illustrating a simplified overview of IBM Watson Analytics.

[0068] Figure 6 is a diagram illustrating RESTful analytics services provided by IBM Watson Developer Cloud.

[0069] Figure 7 is a diagram illustrating the architecture of data analytics related services used by Microsoft Azure.

[0070] Figure 8 is a diagram illustrating the general architecture of Intel IoT Analytics services.

[0071] Figure 9 is a diagram illustrating the user dashboard of Intel IoT Analytics services.

[0072] Figure 10 is a diagram illustrating an overview of the Apache Hadoop ecosystem.

[0073] Figure 11 is a diagram illustrating M2M system / network architecture and services.

[0074] Figure 12 is a diagram illustrating an exemplary protocol stack supporting the service layer.

[0075] Figure 13 is a diagram illustrating an example illustrating M2M / IoT service layer deployment within a network.

[0076] Figure 14 is a diagram illustrating the Common Service Functions (CSFs) in the oneM2M service layer.

[0077] Figure 15 is a diagram illustrating the resource-oriented architecture of the oneM2M service layer.

[0078] Figure 16 is a diagram illustrating the oneM2M service component architecture.

[0079] Figure 17 is a diagram illustrating a use case illustrating highway images (unstructured data) stored in the service layer.

[0080] Figure 18 is a diagram illustrating the general operational framework of the Data Analytics Service (DAS) service.

[0081] Figure 19 is a diagram illustrating the high-level operational flow of the DAS service.

[0082] Figure 20 is a diagram illustrating the operational details and functional design of the DAS service.

[0083] Figure 21is a flow diagram illustrating a first procedure for interacting with a DAS service.

[0084] Figure 22 is a flow diagram illustrating a second procedure for interacting with a DAS service.

[0085] Figure 23A to 23B is a flow diagram illustrating a third procedure for interacting with a DAS service.

[0086] Figure 24A to 24B is a flow diagram illustrating a fourth procedure for interacting with a DAS service.

[0087] Figure 25 is a diagram illustrating new DAS CSFs for the oneM2M service layer.

[0088] Figure 26 is a diagram illustrating STP oneM2M resources.

[0089] Figure 27 is a diagram illustrating DAS oneM2M resources.

[0090] Figure 28A to 28B is a diagram illustrating a GUI interface for monitoring a DAS service.

[0091] Figure 29A is a diagram of an M2M / IoT / WoT communication system comprising a communication network.

[0092] Figure 29B is a diagram of the illustrated M2M service layer in the field of providing services for M2M applications, M2M gateway devices and M2M terminal devices and communication networks.

[0093] Figure 29C is a diagram of an exemplary device that can be used to implement any of the network nodes described herein.

[0094] Figure 29D is a block diagram of a computer system or server that can be used to implement any of the network nodes described herein. DETAILED DESCRIPTION

[0095] There are different types of available data analytics services on the market. In particular, as data analytics is a broad concept from the perspective that it can refer to different forms / types of analysis tasks / operations, these existing data analytics services can provide different functionalities. Moreover, some of these analytics services are specifically designed to facilitate manual operations by human users while others focus on automated analysis processing in the context of e.g. M2M / IoT systems.

[0096] The existing oneM2M service layer lacks the capability to enable "public data analytics services." Specifically, the potential problems and drawbacks when such public data analytics services are lost from the service layer, as well as the needs for such services, are discussed below.

[0097] Today, most endpoints (AE / CSE) cannot extract intrinsic information from data accessible at the service layer (especially for unstructured data such as images, documents / logs, etc.), which creates a need for public data analytics services at the service layer.

[0098] On the one hand, as introduced above, various types of data, such as semi-structured and unstructured data (such as audio, video, web pages, and text) or structured data (such as those stored in database tables), can coexist in a system. This is especially true in the context of M2M / IoT systems, which are a major trend driving the growth of big data. It is predicted that over 70% of the data generated from M2M / IoT systems will be unstructured data, such as images captured by outdoor monitoring cameras.

[0099] On the other hand, M2M / IoT systems typically consist of different types of endpoints, such as applications / devices / desktop computers within the M2M system or from the Internet. Therefore, different endpoints may not have the same ability to understand a single piece of data generated by an IoT device. For example, especially for resource-constrained nodes, some endpoints may lack data analytics capabilities / engines. Figure 17 The illustration shows how this problem is used.

[0100] like Figure 17 As shown, wireless traffic monitoring camera 1702 at exit 28 of I-276 (with a speed limit of 65 mph) is capturing images and storing them at MN-CSE (gateway) 1704. <contentinstance>resource. Since this image is a piece of unstructured data, the smartphone (or any other endpoint or service entity, e.g. AE / CSE) can be able to access this <contentinstance>resources, but it cannot really understand the information in that image, e.g., that the current weather is sunny or that the current road traffic is very good (speed of travel can exceed 50 miles per hour). Notably, this intrinsic information cannot be directly derived without some kind of data analysis processing of the image (e.g., image processing in this case). Unfortunately, most of the M2M / IoT endpoints or service layer entities are not equipped with such data analysis capabilities themselves. Moreover, there is no such common data analysis service defined at the service layer. Thus, from the service layer perspective, one can see that a lot of potential value is buried in the raw data stored in the service layer and cannot be used in an efficient way to serve the service layer entities.

[0101] Moreover, instead of expecting the AEs to have their own data analysis capabilities, the service layer expects to be able to enable "common" data analysis services that not only simplify the functional design requirements for various endpoints and AEs but also benefit from resource or capability sharing.

[0102] Even if the service layer can plug in external data analysis capabilities, there is no uniform interface that allows the endpoints (AEs and CSEs) to access various data analysis services unless they follow the respective proprietary API specifications.

[0103] While there are different types of data analysis services available in the market, most of those services and solutions are proprietary solutions in the sense that each of those solutions has their own development tools, API specifications, and documentation, etc. However, typically, the service layer endpoints (AEs / CSEs) will not know the proprietary interfaces to access third party data analysis services. Since a horizontal service layer such as oneM2M aims to provide common service functions (CSFs), it is necessary to expose a uniform operation interface to the service layer entities by providing common data analysis services. In other words, enabling the service layer with different types of data analysis capabilities (either by plugging in some data analysis module in the CSE or by using existing external data analysis services as underlying technology) needs to seal or hide all those internal details from the service layer entities (e.g., AEs / CSEs). For example, it can add greater flexibility to utilize any third party data analysis services without worrying about the complexity of each of those services. (This is a similar approach of how the service layer can utilize existing / underlying device management technology).

[0104] Moreover, there is no available programming related to how to enable (configure, use, control, etc.) data analysis services in the context of M2M / IoT systems.

[0105] Mechanisms from both data analytics and data communication can enable data analytics capabilities in M2M / IoT. For example, assuming that a service layer has been enabled with a common data analytics service, there are still issues about how to interact with this service in terms of programming (e.g., how to access, configure, and control the service, etc.). This is because M2M / IoT systems heavily rely on efficient communication procedures to achieve certain functionalities. However, this is not the main focus of a service provider that is focused on data analytics. Therefore, new procedures need to be designed in order to effectively support the interaction between the common data analytics service and the users / clients of this service.

[0106] As mentioned before, the service layer needs data analytics capabilities due to the inherent characteristics of big data in M2M / IoT systems. Therefore, data analytics service functionalities are added at the service layer in order to meet this need.

[0107] Examples are described in the context of oneM2M to illustrate detailed methods and procedures. However, these concepts are not limited to oneM2M and can be generalized to any service layer with similar functionalities or needs.

[0108] Figure 18 A general operation framework of DAS 1802 is shown. In this example, DAS 1802 is provided by CSE 1804 as a common service functionality and it can perform certain data analytics operations on target / interesting (raw) data according to requests from various entities (e.g., AE or other CSE). Since DAS 1802 is a common service at the service layer, those raw data to be analyzed are, for example, stored in existing data repositories defined by oneM2M, such as DS 1806, or other data repositories. <contentinstance>It is possible that the resource is hosted in a different CSE. Thus, the CSE hosting the data to be analyzed is referred to as the "data hosting CSE" 1806 and the CSE hosting the DAS is defined as the "DAS hosting CSE" 1804. Furthermore, those entities that need the data analysis operations provided by the DAS are defined as "DAS clients" 1808. In a more general case, it is worth noting that if the raw data to be analyzed is co-located with the DAS 1802, then one CSE node can act as both the data hosting CSE 1806 and the DAS hosting CSE 1804. Meanwhile, the interaction between those entities can occur over the mca / mcc / mcc' reference points as Figure 18 shown.

[0109] Furthermore, the DAS 1802 can be equipped with various analysis capabilities. Data analysis is a broad range and many types of data processing operations can be classified as "data analysis services". For example, in a simplified case, basic data statistical services can be used to do mathematical data aggregation operations such as max, min, average, etc. on a set of raw data (e.g. sensor readings). Another example, when an AE needs to obtain useful information from an image, image processing operations can be provided by the DAS if the AE does not have such capabilities. Information extraction techniques are used when it is needed to extract useful data items from JSON documents, log records, or web pages, etc. Thus, on one hand, those different types of data analysis operations will be the common services that the DAS 1802 can utilize existing various data analysis techniques / tools as plug-ins or output to certain external service portals for providing those data analysis operations. On the other hand, the DAS 1802 itself can provide common data analysis services to its DAS clients 1808 by providing a uniform interface (as Figure 18 shown) and hiding the underlying complexity of the DAS 1802 from it. It is worth noting that by providing such a feature, a service layer entity (e.g. AC / CSE) will only need to interact with the DAS 1802 as a client 1808 of the DAS 1802 instead of having to deal with all the underlying details of a proprietary data analysis application.

[0110] It is understood that the functionality shown in Figure 18 may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, one of the nodes or devices (e.g., servers, gateways, devices, or other computer systems) of the M2M network such as those illustrated in Figure 29C or Figure 29D .

[0111] Figure 19 shows the high level operation flow between the multiple entities as defined in Figure 18 . Figure 19 includes four main phases. Each of the four phases can include one or more service layer request / response messages, and those details will be explained later when describing the relevant procedures.

[0112] In Figure 19 , first, the DAS Client 1808 initiates a request to the DAS Hosting CSE 1804 for certain data analytics operations on its target / interesting data (shown as Phase 1 in Figure 19 ). Then, a data ingestion process (Phase 2 in Figure 19 ) feeds the data to be analyzed into the DAS 1802. Typically, the corresponding data hosting CSE 1806 will deliver the raw data to the DAS Hosting CSE 1804. Alternatively, it is also possible that the DAS Client 1808 can first retrieve the raw data by itself and include it in the payload of the request sent to the DAS Hosting CSE 1804. In this case, Phase 1 and 2 are combined together. During Phase 3, which typically occurs within the DAS 1802, the DAS 1802 selects the appropriate underlying analytics techniques to conduct the specific data analytics operations requested by the DAS Client 1808. The details of the work of those underlying data analytics techniques can be hidden from or abstracted from the DAS Client 1808. Finally, once the DAS 1802 derives the analytics results, it can deliver the results to the DAS Client 1808 via a unified interface (Phase 4 in Figure 19 ).

[0113] Overall, the DAS 1802 leverages existing underlying techniques and exposes a unified interface to the service layer entities. The following describes the generic architectural design and procedures that support the interaction process between the DAS 1802 and its clients 1808 from the M2M / IoT network perspective.

[0114] It should be understood that Figure 19 the functions shown in Figure 29C or Figure 29D can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of and executed on the processor of a node or device (e.g., a server, gateway, device, or other computer system) of an M2M network, such as one of those shown in

[0115] Figure 20 The functional design within the DAS 1802 is shown. It should be understood that Figure 20 the functions shown in Figure 29C or Figure 29D in the form of software (i.e., computer-executable instructions) stored in memory of one of those illustrated in FIG. 18 and executed by a processor of a node or device of the M2M network.

[0116] As can be seen, different data analytics capabilities can be added to the DAS 1802 so that various data analytics operations can be performed, such as basic data statistics, image processing, information extraction, etc.

[0117] Various methods for adding those underlying data analytics capabilities to the DAS 1802 can be used. If there already exists an external data service portal that can provide data analytics services, then portal access information can be registered or added in the DAS 1802. Thus, once the DAS 1802 receives an analytics request from its client 1808, it can use those external service portals in order to obtain the analytics results.

[0118] Alternatively, if there are available plug-in analytics modules, then these modules can be directly plugged into the DAS 1802 so that data analytics operations can be directly performed locally by the corresponding CSE 1804 that is running the DAS 1802 (especially for those low-cost light-weight data statistics operations).

[0119] Thus, the DAS 1802 can be deployed / implemented in / by various types of CSEs (e.g., ASN-CSE, MN-CSE (like a gateway), and IN-CSE) (which can be hosted in the cloud).

[0120] As mentioned earlier, regardless of how the underlying technologies are added to the DAS 1802, the DAS 1802 will expose these technologies to the DAS's clients using a uniform service layer API. Thus, for each type of data analytics service, a service type profile (STP) 2002 is defined to specify the details related to the application programming interface (API). In other words, if the DAS 1802 has multiple types of data analytics capabilities 2004, 2006, and 2008 supported by different underlying technologies (whether in a plug-in approach or an external approach), each of them will have a corresponding STP 2002. Typically, the STP 2002 is published by the DAS 1802 so that the underlying clients of the DAS 1802 can discover the available data analytics capabilities provided by the DAS 1802.

[0121] Generally, the working methodology of the DAS 1802 is as follows: 1) various analytics service capabilities can be provided by the DAS 1802 by exploiting underlying data analytics tools / technologies; 2) for each type of data analytics capability, an STP 2002 is defined, which specifies details related to this analytics capability, e.g., where it is, when it is available, how long the data analytics operation will take, what it can identify / analyze, and service access details in terms of input / output parameters, i.e., the format of the API that the client should use to access this service (i.e., the structure of the service layer request / response messages), etc. Overall, how the client discovers / references the STP 2002 of the DAS 1802 and how to access the corresponding DAS 1802 through a unified API (e.g., sending a data analytics request and receiving the analytics results, etc.) will generally occur on the mac / mcc / mcc’ reference point and detailed procedures will be introduced later.

[0122] The internal interface translator 2010 of the DAS 1802 can use the STP 2002 to translate information from the client 1808 into information for the APIs of the analytics capabilities 2004, 2006, and 2008.

[0123] Table 1 gives a typical definition of the STP 2002, which can be used to describe three main / popular types of data analytics operations, such as basic data statistics, text / information extraction, or image processing.

[0124] Table 1: Parameters of a service type profile (STP)

[0125]

[0126] A number of exemplary procedures for interacting with the DAS 1802 are described and these procedures can be applicable to four different cases or scenarios.

[0127] Case 1 (raw data retrieved by the client): The client 1808 will first obtain the raw data to be analyzed that it targets / is interested in, and then send it to the DAS 1802 for analysis.

[0128] Figure 21 The procedure for interacting with the DAS 1802 that illustrates Case 1 is shown and described in detail as discussed below.

[0129] Pre-conditions. Data-1 is on CSE-1 (as a data hosting CSE 1806) <contentinstance>A piece of data stored in the resource and AE-1 (as DAS client 1808) is interested in Data-1. At the same time, there exists a DAS 1802 (hosted by CSE-2 as DAS hosting CSE 1804) available in the system and it publishes its STP 2002 to announce its available data analytics capabilities. For easy illustration, we consider an exemplary scenario where DAS client 1808, DAS hosting CSE 1804, data hosting CSE 1806 are assumed by different entities, namely respective AE-1, CSE-2 and CSE-1 (but in fact, as mentioned earlier, DAS client / DAS hosting CSE / data hosting CSE can also be assumed by the same CSE).

[0130] In Figure 21 Step 1, based on the interest of AE-1, AE-1 sends a request to CSE-1 for retrieving Data-1. Note that this step can be performed multiple times when AE-1 intends to collect multiple data (e.g. digital sensor readings) from different locations in order to perform a "basic data statistics" (e.g. compute the average of multiple temperature readings) provided by DAS 1802. For easy presentation without losing generality, we only illustrate the case where only one piece of data needs to be analyzed (which is more general for the case where e.g. information extraction or image processing type of data analytics operations are performed on a text document or image). More generally, if multiple pieces of data need to be collected from multiple locations, e.g. from multiple CSEs, multiple data analytics operations can be performed by DAS 1802, e.g. to compute the average of multiple temperature readings, the average of multiple humidity readings, etc. <contentinstance>Resource Retrieval can be repeated multiple times for more than one original data.

[0131] In Figure 21 Step 2, Data-1 is returned from CSE-1 to AE-1. Step 1 and Step 2 are standard resource retrieval operations. Alternatively, it is also possible that AE-1 can have its own local data that needs to be analyzed. In this case, the resource retrieval operations (Step 1 and Step 2) can be skipped.

[0132] In Figure 21 Step 3, after obtaining Data-1, AE-1 finds that in order to understand or derive valuable information in Data-1, it needs appropriate data analysis operations. Therefore, AE-1 finds the STP published by CSE-2 and identifies the appropriate data analysis operations provided by CSE-2. Such STP publication and discovery process can be done by using any existing service discovery mechanism.

[0133] In Figure 21 Step 4, AE-1 sends a data analysis request to CSE-2 along with Data-1 in the payload of the data to be analyzed according to the interface specification as specified in the selected STP. Specifically, by referring to the "Input_Parameters" data entry as defined in the selected STP file (see Table 1 for more details), the request message sent in this step can be constructed as follows: In general, in addition to the original data (e.g. image) to be analyzed which it normally carries in the payload (which needs to conform to the format as specified by the "Raw_Data_Format" entry in the STP), this message can include the following two mandatory data analysis related parameters:

[0134] CSE_ID (cse_id): This data field indicates which CSE's DAS 1802 will handle this data analysis request.

[0135] Analytics_Type (a_t): This data field indicates which type of data analysis operation the client requests. For example, it can be an image processing operation or an information extraction operation or a basic data statistics operation, etc.

[0136] In addition, for each type of analysis service (as specified by the Analytics_Type entry), it can also include the following different data entries:

[0137] When Analytics_Type = "Basic Data Analysis":

[0138] Statistical_Operation (s_o): This parameter indicates which type of data statistical operation it needs, which is selected from the Supported_Statistical_Operations entry as defined in the STP. For example, the DAS 1802 can support standard data aggregation such as maximum, minimum, average, median, etc.

[0139] When Analytics_Type = "Information Extraction":

[0140] Selected_Targeted_Information (s_t_i): For data analytics services that support text-related information extraction, it can attract useful information such as temperature values or location information from various types of documents (e.g., XML or JASON based documents). Thus, this parameter indicates which target 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.

[0141] When Analytics_Type = "Image Processing":

[0142] Interested Object(s) (i_o): This parameter indicates which potential object(s) the client is interested in for this image processing operation. Note that the interested object(s) are selected from the identifiable objects entry as defined in the selected STP.

[0143] Selected_Analytical_Aspects (s_a_a): For a certain interested object, this parameter specifies which analytical aspect or result will be provided and it is selected from the Analytical_Aspects entry in the STP. For example, for a sky object, the analytical aspect can be weather-related (e.g., sunny, cloudy, etc.) or visibility-related. Thus, based on this parameter, it indicates which analytical result will be returned by the DAS 1802.

[0144] In step 5 of Figure 21 , the CSE-2 performs the desired data analytics operation as needed by the AE-1 and derives the analytics result.

[0145] In step 6 of Figure 21 , the DAS 1802 returns the analytics result to the AE-1. In this step, the parameters included in the response message will conform to the "Output_Parameters" as defined in Table 1. For example, the message can include:

[0146] Successes Flag (s_f): This data field indicates whether the required data analysis operation has derived any analysis results. The value of this parameter can be 0 (failure) and 1 (success). When the value is 0, it basically means that there can be no returned analysis results, e.g., the DAS 1802 did not identify any object of interest in the raw data (e.g., when the client sends an image of an apple to the DAS 1802 and requires an analysis operation defined by the STP in which the only identifiable objects are road traffic and sky).

[0147] Analytical_Result (a_r): This data field stores the data analysis results, if available. As mentioned earlier, each of the analysis results can be associated with a confidence level within the data analysis operation of the image processing type. Alternatively, the analysis results can be carried in the payload, if required.

[0148] In step 7 of the procedure of Figure 21 , once the AE-1 obtains the analysis results from the CSE-2, it can use it for further purposes.

[0149] The procedure in Case 1 also applies to scenarios in which, for example, the DAS client 1808, the DAS hosting CSE 1804, and the data hosting CSE 1806 are located in different nodes or at least the proximity between the DAS hosting CSE 1804 and the data hosting CSE 1806 is greater than the proximity between the DAS client 1808 and the data hosting CSE 1806 (i.e., it makes sense for the DAS client 1808 to retrieve data from the data hosting CSE 1806 without incurring unnecessary communication costs).

[0150] It should be appreciated that the entities performing the steps illustrated in Figure 21 are logical entities, which can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a network apparatus or computer system, such as those illustrated in Figure 29C or Figure 29D . That is, the method(s) shown in Figure 21 may be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a network apparatus, such as the apparatus or computer system illustrated in Figure 29C or Figure 29D , which computer-executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in Figure 21 . It should also be appreciated that the method(s) shown in Figure 21 Any of the sending and receiving steps illustrated in the figure can be performed by the communication circuitry of the device under control of the processor of the device and computer-executable instructions (e.g., software) executed by the processor.

[0151] Case 2 (Raw data retrieved by DAS 1802): The client will directly ask the DAS 1802 to perform some data analytics operation and the DAS 1802 will retrieve on behalf of the client the raw data to be analyzed of interest / target.

[0152] Figure 22 The procedure for interacting with the DAS 1802 is illustrated for Case 2 and is discussed in detail as follows.

[0153] Pre-conditions (same as Case 1). Data-1 is on CSE-1 (as a data hosting CSE 1806) <contentinstance>One piece of data stored in the resource and AE-1 (as a DAS client 1808) is interested in Data-1. At the same time, there exists a DAS (hosted by CSE-2 as a DAS hosting CSE) available in the system and it publishes its STP to announce its available data analytics capability.

[0154] In Figure 22 Step 1 of the procedure for Case 2, AE-1 first discovers the STP published by CSE-2 and identifies the desired data analytics operation.

[0155] In Figure 22 Step 2 of the procedure for Case 2, AE-1 sends the data analytics to CSE-2 according to the interface specification as specified in the selected STP. Specifically, by referring to the "Input_Parameters" as defined in the selected STP file (see Table 1 for more details), the request message sent in this step can be interpreted as the same as Step 4 in Case 1. Furthermore, there can be another additional parameter defined as follows:

[0156] URI_of_Data_To_Be_Analyzed (data_uri): This URI indicates where the DAS can retrieve the data to be analyzed. Note that, while the example shown in Figure 22 illustrates the case where only one piece of data (i.e., Data-1) is analyzed by the data analytics request, it is possible that the requested data analytics operation can retrieve multiple pieces of data from different locations (especially when the data analytics type is a basic data statistical operation, as discussed earlier). In this case, this parameter will include a list of URLs.

[0157] In addition, AE-1 can also send the relevant access information so that the DAS can successfully access Data-1, such as the access and control related information.

[0158] In Figure 22 Step 3 of the procedure for Case 2, CSE-2 also sends a request to CSE-1 for retrieving Data-1.

[0159] In Figure 22 Step 4 of the procedure for Case 2, Data-1 is returned from CSE-1 to CSE-2. Like Step 1 and Step 2 of the procedure defined for Case 1, Step 3 and Step 4 here are also standard resource retrieval operations.

[0160] Figure 22 Steps 5-7 of the procedure for Case 2 are the same as Steps 5-7 of the procedure defined for Case 1.

[0161] Case 2 is more applicable to scenarios where the proximity between the DAS hosting CSE 1804 and the data hosting CSE 1806 is less than the proximity between the DAS client 1808 and the data hosting CSE 1806 (i.e. there is no need for the DAS client 1808 to retrieve data from the data hosting CSE 1806 in order to avoid unnecessary communication cost).

[0162] It is to be understood that the entities performing the steps illustrated in Figure 22 Figs. 1-8 are logical entities, which can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of, and executing on, a network apparatus or computer system such as those illustrated in Figure 29C Figs. 1-8. That is, the steps illustrated in Figure 29D Figs. 1-8 are performed by the network apparatus or computer system in response to the software (i.e., computer-executable instructions) stored in the memory of the network apparatus or computer system and executing on the processor(s) of the network apparatus or computer system. Figure 22 The method(s) illustrated in Figure 29C Figs. 1-8 can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a network apparatus such as the apparatus or computer system illustrated in Figure 29D Figs. 1-8, which software, when executed by the processor(s) of the apparatus, performs the steps illustrated in Figure 22 Figs. 1-8. It is to be understood that any transmitting and receiving steps illustrated in Figure 22 Figs. 1-8 can be performed by the communication circuitry of the apparatus under control of the processor(s) of the apparatus and the computer-executable instructions (e.g., software) that the processor(s) execute.

[0163] Case 3 (Raw data discovered and retrieved by DAS): Similar to Case 2, AE-1 (as DAS client 1808) will directly ask CSE-2 (as DAS hosting CSE) to perform some data analytics on the raw data to be analyzed. However, the difference here is that in this case, the data analytics operation can be moved and performed at a closer DAS hosting CSE 2302 (which is closer to the raw data to be analyzed) instead of at the original DAS hosting CSE 1802 (i.e. CSE-2) which receives the request from AE-1 (note that "closer" basically implies less communication overhead, so it can not necessarily mean closer geographical location). It is worth noting that from a big data perspective, this procedure will be fully consistent with the current data analytics processing paradigm, i.e. trying to move the computation processing to where the data is stored instead of moving the data to the computation.

[0164] Figure 23A to 23B Fig. 8 illustrates the procedure for interacting with a DAS in Case 3. In this example scenario, we assume that CSE-2 1804 and CSE-3 2302 are located at different locations and CSE-3 2302 is closer to CSE-1806 than CSE-2 1804. Note that in Case 3, the DAS client 1808 is not aware of the location of the data hosting CSE 1806. Figure 23A to 23B most of the steps are the same as in Case 2 Figure 22 Here, only the differences between the two cases are discussed (as highlighted in the green rectangular boxes). As shown in Figure 23A to 23B , since CSE-3 2302 is closer to the raw data to be analyzed, steps 3 and 4 are defined for CSE-2 1804 to forward the data analytics request from AE-1 1808 to CSE-3 2302. Thus, the data items carried in the request messages of steps 2 and 4 in Case 3 Figure 23A to 23B will have almost the same messages as defined for step 2 in Case 2 Figure 22 . Not only that, for step 4 in Case 3 Figure 23A to 23B , there can be another additional parameter as defined below:

[0165] Original_CSE_ID (original_cse_id): this data field indicates which original DAS is the one that receives this data analytics request (i.e. CSE-2 in this example).

[0166] After CSE-3 2302 derives the analytics result, it is returned to CSE-2 1804, which further forwards the result to AE-1 1808 (as shown in steps 7-9 in Case 3 Figure 23A to 23B ). Moreover, for step 9 in Case 3 Figure 23A to 23B , there can be another additional parameter as defined below:

[0167] Task_Execution_CSE_ID (execution_cse_id): this data field indicates which actual DAS is the one that does the data analytics processing for this request (i.e. CSE-3 2302 in this example).

[0168] Thus, based on this data item, AE-1 1808 can understand that although it sends the request to CSE-2 1804, the request has actually been processed by CSE-3 2302. Alternatively, for future similar requests from AE-1 1808, it can directly contact CSE-3 2302 or alternatively, it can still send the request to the neighboring DAS (i.e. CSE-2 1804 in this example) and let the DAS make the decision where the request should be forwarded to.

[0169] Furthermore, it's worth noting that while we've illustrated this procedure using considerations related to "proximity"—specifically, moving a data analytics operation from the original DAS-hosted CSE 1804 to another DAS-hosted CSE 2302 that is closer—this procedure can also be used in any other scenario (where "proximity" doesn't have to be the primary metric). For example, this procedure can be applied whenever a DAS-hosted CSE 1804 needs to delegate a certain analytics operation to another equivalent DAS-hosted CSE (e.g., for load balancing, security, task migration, etc.).

[0170] It should be understood that the implementation Figure 23A to 23B The entities in the steps illustrated are logical entities, which can be in network devices or computer systems (such as...) Figure 29C or Figure 29D This is implemented in the form of software (i.e., computer-executable instructions) stored in the memory of the network device or computer system and executed on the processor. That is, Figure 23A to 23B The methods(one or more) shown can be used in network devices (such as in...) Figure 29C or Figure 29D The software (i.e., computer-executable instructions) stored in the memory of the device or computer system illustrated in the figure is implemented in the form of software, which executes when executed by the processor of the device. Figure 23A to 23B The steps are shown in the diagram. It's also important to understand... Figure 23A to 23B Any of the sending and receiving steps illustrated in the diagram can be performed by the device's communication circuitry under the control of the device's processor and computer-executable instructions (e.g., software) executed by the processor.

[0171] Scenario 4 (Subscription-Based DAS): This scenario identifies unique aspects that may arise when performing data analytics operations within the context of an M2M / IoT system. For example, sensors or devices may generate data streams over time, which an AE (Agent) or CSE (Content Execution System) might be interested in. For instance, a traffic assessment AE might aim to continuously analyze images generated by outdoor cameras on highways. Similarly, in some scenarios, clients may request data analytics operations at the DAS before the raw data to be analyzed becomes available. Therefore, Scenario 4 focuses on a subscription-based paradigm for interacting with the DAS.

[0172] Figure 24A to 24B The diagram illustrates the procedure for interacting with the DAS in scenario 4. Note that most of the steps in scenario 4 are the same as those in scenario 2. Here, only the differences between the two scenarios are discussed (as highlighted in the blue rectangle). For example, in this scenario, instead of DAS client 1808 being interested in a specific piece of data, AE-1 might be interested in the entire CSE-1 1806. <container-1>Resources are interested. In particular, the client will be interested in new available data input into the container and needs periodic data analytics operation on that data. At the same time, in Figure 24A to 24B The data items carried in the Request message of Step 2 of Case 2 will have almost the same message as defined for the message of Step 2 of Figure 22 Case 1. Not only that, there can be another additional parameter as defined below:

[0173] Subscription-based operation flag (s_o): With this flag, the DAS Hosting CSE 1804 will know that the DAS Client 1808 is requiring a subscription-based DAS operation. So, with this flag in this step, it means that actually AE-1 makes a subscription to the analytics results to CSE-2.

[0174] Analytics Schedule or Frequency (s_f): This data field indicates the schedule or frequency that the client expects the DAS to do data analytics operation on new data. This is because it is possible that new data can be available at <container>Resources become available at a faster pace (e.g., 10 new data generated in a minute dictated by the sampling frequency of the sensing device), while AE-1 can only aim to have a lower analysis frequency (e.g., once an hour) for data analytics operations on the new data.

[0175] Further, steps 3-6 in case 4 Figure 24A to 24B Steps 3-6 of the procedure of <container>Notifications regarding new available data in the resources. Therefore, in Figure 24A to 24B In step 7, for each received notification, CSE-2 1804 refers to... Figure 24A to 24B In step 2, the analysis frequency or schedule specified by AE-1 1808 determines whether new data should be retrieved for analysis. If CSE-2 1804 decides to analyze new data, it will further retrieve new data from CSE-1 1806, and the remaining procedures are similar to those before.

[0176] The above procedure is using a traditional service subscription method for DAS access. Alternatively, the AE-1 1808 can also utilize oneM2M. <subscription>resources to achieve the same purpose. For example, during step 2 of Figure 24A to 24B AE-1 1808 can create a <container>Resources are provided for storing analysis results. Meanwhile, it is located within... <container>resources are created under <subscription>resources. Thus, on the DAS side, and Figure 24A to 24B Step 10 is the same as for AE-1, it can perform the desired data analysis operations based on the needs of AE-1, and then pass those analysis results as <contentinstance>Resource put in <container>In the resource, this will further trigger a notification to be sent to AE-1 1808 (e.g., according to some notification criteria set by AE-1 1808).

[0177] It should be understood that the entities performing the steps illustrated in Figure 24A to 24B FIG. 1 1 are logical entities, which can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a network device or computer system, such as those illustrated in Figure 29C or Figure 29D FIG. 1 1, and executed on the processor of the network device or computer system. That is, the method(s) shown in Figure 24A to 24B FIG. 1 1 can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a network device, such as the devices or computer systems illustrated in Figure 29C or Figure 29D FIG. 1 1, which, when executed by the processor of the device, perform the steps illustrated in Figure 24A to 24B FIG. 1 1. It should also be understood that any transmitting and receiving steps illustrated in Figure 24A to 24B FIG. 1 1 can be performed by the communication circuitry of the device under control of the processor of the device and computer-executable instructions (e.g., software) executed by the processor.

[0178] 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 Service Entity (CSE). Thus, the DAS can be considered as a CSF implemented by the CSE, as shown in Figure 25 Alternatively, it can also be part of the existing Data Management and Repository (DMR) CSF defined in oneM2M TS-0001 ). Thus, this procedure and the new parameters mainly occur at the mca and mcc / mcc' reference points, as shown in Figure 25 It should be that different types of M2M nodes can implement the DAS, such as M2M gateways, M2M servers, M2M devices, etc. In particular, depending on the various / different hardware / software capabilities for those nodes, the functionality / capabilities of the DAS implemented by those nodes can also be different.

[0179] It should be understood that the functionality illustrated in Figure 25 FIG. 1 1 can be implemented in the form of software (i.e., computer-executable instructions) stored in the memory of a node (e.g., server, gateway, device, or other computer system) of an M2M network, such as one of those illustrated in Figure 29C or Figure 29D FIG. 1 1, and executed on the processor of the node of the M2M network.

[0180] Two new oneM2M resources are defined in order to enable DAS. In particular, since a service type profile is defined as a potential client exposing to DAS, it is called <stp>The new resource of Figure 26 is used to describe the STP 2002, which is shown in <stp>resources, the client can easily understand which data analysis operations are available. At the same time, this <stp>A resource can be exposed at different CSEs in the network in order to facilitate discovery by DAS clients. In particular, an "accessPortalAddress" attribute defined in this resource indicates how to actually access the corresponding DAS for this STP 2002 (i.e. where to send a request message to the DAS hosting CSE 1804). Thus, using the resource shown in Figure 27 Figure 1 1, a DAS client can discover the DAS hosting CSE 1804 and the STP 2002, and then send a request message to the DAS hosting CSE 1804 to access the DAS. <das>a new resource, which is typically hosted as a child resource of the DAS Hosting CSE 1804, and the URI of this resource will be included in the corresponding <stp>the previously mentioned accessPortalAddress attribute of the resource. As a result <das>Just an access portal, so it can just include common attributes for service layer resources, which are not shown in Figure 27 the middle. Thus, all requests of the DAS client (and typically stored in <contentinstance>The raw data (i.e. the data to be analyzed in the resource) will be sent to the address specified by the "accessPortalAddress" attribute and these requests can use a CREATE or UPDATE request as defined in the service layer (an UPDATE is recommended as no new resource will be created when sending a data analysis request to the DAS). Furthermore, <stp>The resource structure is defined based on the STP 2002 and <stp>The meaning of the attributes of the resources are the same as those introduced in Table 1.

[0181] An interface such as a graphical user interface (GUI) can be used to assist a user in controlling and / or configuring functions related to enabling data analytics. As introduced above, the new DAS common services are used for the service layer. In particular, in order for a human administrator to monitor how those DAS services are running, Figure 28A A GUI 2802 is shown for inspecting the overall system view. For example, a human can be allowed to inspect a particular type of data analytics operation that is run by the DAS, e.g., image processing or information extraction, etc. (e.g., by entering the particular type of data analytics operation that the user intends to inspect, such as Figure 28A shown or alternatively, let the user select an option from a variety of data analytics operations via a drop down). In addition, the human administrator can monitor whether the underlying data analytics components are working properly. At the same time, since each type of data analytics operation is exposed through the STP 2002, the GUI 2802 also allows the administrator to inspect the details of the STP 2002, such as service availability and statistics related to the confidence interval of the analysis results, especially for those dynamic changing data items in the STP 2002. In addition, it also allows the administrator to inspect which clients have accessed and used them in order to understand the utilization of the various types of data analytics operations provided by the DAS. For example, Figure 28B An output panel interface 2804 is shown when the administrator chooses to inspect the image processing type of the STP 2002, where the details of the STP 2002 have been displayed to the user for their reference. It should be understood that the interfaces 2802 and 2804 can be produced using displays such as those shown in Figure 29C to 29D described below.

[0182] Exemplary M2M / IoT / WoT communication system for data analytics services

[0183] The various techniques described herein can be implemented in connection with hardware, firmware, software or in combinations thereof, as appropriate. Such hardware, firmware, and software can reside within all or a portion of an apparatus located at a node in a communication network. Such apparatus can operate singly or in combination with each other to implement the methods described herein. As described herein, the terms "apparatus," "network apparatus," "node," "device," and "network node" can be used interchangeably.

[0184] A service layer can be a functional layer within a network service architecture. The service layer is typically above the application protocol layer such as HTTP, CoAP, or MQTT and provides value-added services to client applications. The service layer also provides an interface to the core network of lower resource layers such as, for example, the control layer and transport / access layer. The service layer supports multiple categories of (service) capabilities or functions including service definition, service runtime enablement, policy management, access control, and service clustering. Recently, multiple industry standard organizations, such as oneM2M, have been developing an M2M service layer to address challenges associated with integrating M2M-type devices and applications into deployments such as the Internet / Web, cellular networks, enterprise networks, and home networks. The M2M service layer can provide applications of individual devices access to a collection of the above-mentioned capabilities or functions (which can be referred to as a CSE or SCL) that the service layer supports. Several examples include, but are not limited to, security, charging, data management, device management, discovery, provisioning, and connectivity management that can be commonly used by individual applications. These capabilities or functions are provided to various applications via APIs that use message formats, resource structures, and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that can be implemented by hardware and / or software and provides the (service) capabilities or functions exposed to individual applications and / or devices (i.e., the functional interface between these functional entities) so that they use these capabilities or functions.

[0185] Figure 29A is a diagram of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments can be implemented. Generally, M2M technologies provide building blocks for the IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform can be a component or node of the IoT / WoT, and the IoT / WoT service layer, among others. The communication system 10 can be used to implement the functionality of the disclosed embodiments and can include functional and logical entities such as: an M2M area network, 1104 an M2M gateway, an M2M server, a service layer 1202, a common service entity (CSE) 1402, an application entity (AE) 1404, a camera 1702, a gateway 1704, a data analytics service (DAS) 1802, a DAS hosting CSE 1804 and 2302, a data hosting CSE 1806, a DAS client 1808, a service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logical entities that create interfaces such as interfaces 2802 and 2804.

[0186] As Figure 29A As shown, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 can be a fixed network (e.g., Ethernet, fiber optic, ISDN, PLC, etc.), a wireless network (e.g., WLAN, cellular, etc.), or a heterogeneous network. For example, the communication network 12 can include a multi-access network providing content such as voice, data, video, messaging, and broadcasting to multiple users. For example, the communication network 12 can 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), and Single Carrier FDMA (SC-FDMA). Furthermore, the communication network 12 can include other networks, such as, for example, a core network, the Internet, sensor networks, industrial control networks, personal area networks, converged personal networks, satellite networks, home networks, or enterprise networks.

[0187] like Figure 29A As shown, the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of an end-to-end M2M deployment, while the field domain refers to the area network typically located after the M2M gateway. Both the field domain and the infrastructure domain may include various network nodes (e.g., servers, gateways, devices, etc.). For example, a field domain may include M2M gateway 14 and terminal devices 18. It should be understood that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M / IoT / WoT communication system 10 as needed. Each M2M gateway device 14 and M2M terminal device 18 is configured to send and receive signals using communication circuitry via communication network 12 or a direct radio link. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLCs) to communicate via carrier networks such as communication network 12 or direct radio links. For example, M2M terminal device 18 can collect data and transmit it to M2M application 20 or other M2M terminal devices 18 via communication network 12 or direct radio link. M2M terminal device 18 can also receive data from M2M application 20 or other M2M terminal devices 18. Furthermore, as described below, data and signals can be sent to or received from M2M application 20 via M2M service layer 22. M2M terminal device 18 and gateway 14 can communicate via various networks including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wired networks.

[0188] Exemplary M2M terminal devices 18 include, but are not limited to, tablets, smartphones, medical devices, temperature and weather monitors, connected cars, smart meters, gaming consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors, and other actuator-based devices, security devices, and smart outlets.

[0189] Reference Figure 29B The illustrated M2M service layer 22 in the field domain provides services for M2M applications 20, M2M gateway devices 14, and M2M terminal devices 18 as well as the communication network 12. The communication network 12 can be used to implement the functionality of the disclosed embodiments and can include functional and logical entities such as: M2M area networks, 1104 M2M gateways, M2M servers, service layer 1202, common service entity (CSE) 1402, application entity (AE) 1404, camera 1702, gateway 1704, data analytics service (DAS) 1802, DAS hosting CSE 1804 and 2302, data hosting CSE 1806, DAS client 1808, service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logical entities that create interfaces such as interfaces 2802 and 2804. The M2M service layer 22 can be implemented by one or more servers, computers, devices, virtual machines (e.g., cloud / storage farms, etc.), etc., including, for example, the devices illustrated in Figure 29C and 29D It should be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 can be implemented by one or more nodes of a network that can include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities that apply to M2M terminal devices 18, M2M gateways 14, and M2M applications 20. The functionality of the M2M service layer 22 can be implemented in various ways, for example, as a web server, in a cellular core network, in the cloud, etc.

[0190] Similar to the illustrated M2M service layer 22, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for M2M applications 20' and the underlying communication network 12' in the infrastructure domain. The M2M service layer 22' also provides services for M2M gateways 14 and M2M terminal devices 18 in the field domain. It should be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with service layers through different service providers. The M2M service layer 22' can be implemented by one or more nodes of a network that can include servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.), and the like.

[0191] Still referring to Figure 29B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that a variety of applications and verticals can leverage. These service capabilities enable M2M applications 20 and 20' 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 applications from the burden of implementing these functions, thereby simplifying application development and reducing cost and time to market. The service layers 22 and 22' also enable M2M applications 20 and 20' to communicate with the service layers 22 and 22' in relation to the services that they provide through the communication network 12.

[0192] The methods of the present application can be implemented as part of the service layers 22 and 22'. The service layers 22 and 22' are software middleware layers that support value-added service capabilities through a set of application programming interfaces (APIs) and underlying network interfaces. Both ETSI M2M and oneM2M use service layers that can incorporate the connection methods of the present application. The service layer of ETSI M2M is referred to as the Service Capability Layer (SCL). The SCL can be implemented within M2M devices (which is referred to as a Device SCL (DSCL)), gateways (which is referred to as a Gateway SCL (GSCL)), and / or network nodes (which 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 specific 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). Furthermore, the connection methods of the present application can be 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.

[0193] In some embodiments, M2M applications 20 and 20' can be used in conjunction with the disclosed systems and methods. M2M applications 20 and 20' can include applications that interact with UEs or gateways and can also be used in conjunction with other disclosed systems and methods.

[0194] In one embodiment, as shown in Figure 29B the logical entities such as M2M regional network, 1104 M2M gateway, M2M server, service layer 1202, common service entity (CSE) 1402, application entity (AE) 1404, camera 1702, gateway 1704, data analytics service (DAS) 1802, DAS hosting CSE 1804 and 2302, data hosting CSE 1806, DAS client 1808, service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logical entities that create interfaces such as interfaces 2802 and 2804 can be hosted within an M2M service layer instance hosted by an M2M node such as an M2M server, M2M gateway, or M2M device. For example, the logical entities such as M2M regional network, 1104 M2M gateway, M2M server, service layer 1202, common service entity (CSE) 1402, application entity (AE) 1404, camera 1702, gateway 1704, data analytics service (DAS) 1802, DAS hosting CSE 1804 and 2302, data hosting CSE 1806, DAS client 1808, service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logical entities that create interfaces such as interfaces 2802 and 2804 can include separate service capabilities within the M2M service layer instance or as sub-functions within existing service capabilities.

[0195] M2M applications 20 and 20' can include applications in various industries such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As described above, the M2M service layer running across devices, gateways, servers, and other nodes of a system supports functions such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, and legacy system integration and provides these functions as services to M2M applications 20 and 20'.

[0196] In general, the service layer 22 and 22' defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying network interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. The service layer of ETSI M2M is referred to as the Service Capability Layer (SCL). The SCL can be implemented in various different nodes of the ETSI M2M architecture. For example, an instance of the service layer can be implemented within an M2M device (which is referred to as a Device SCL (DSCL)), a gateway (which is referred to as a Gateway SCL (GSCL)), and / or a network node (which 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) also defines an architecture for machine-type communications (MTC). In this 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, a Service Capability Server (SCS) of the 3GPP GPRS architecture, a CSF or CSE of the oneM2M architecture, or some other node of the network, an instance of the service layer can be implemented as a logical entity (e.g., software, computer-executable instructions, etc.) executing on one or more standalone nodes (including servers, computers, and other computing devices or nodes) in the network or as part of one or more existing nodes. As an example, an instance of the service layer or a component thereof can be implemented in the form of software running on a network node (e.g., server, computer, gateway, device, etc.) of a general architecture as illustrated in Figure 29C or Figure 29D

[0197] Further, logical entities such as the M2M area network, the M2M gateway 1104, the M2M server, the service layer 1202, the Common Services Entity (CSE) 1402, the Application Entity (AE) 1404, the camera 1702, the gateway 1704, the Data Analytics Service (DAS) 1802, the DAS hosting CSE 1804 and 2302, the data hosting CSE 1806, the DAS client 1808, the Service Type Profile (STP) 2002, the analytics capabilities 2004, 2006, and 2008, and the logical entities that create interfaces such as the interfaces 2802 and 2804 can be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access the services of the present application. ​

[0198] Figure 29C is a block diagram of an exemplary hardware / software architecture of an M2M network node 30, such as an M2M terminal device 18, an M2M gateway 14, an M2M server, etc. The node 30 can execute or include logical entities such as an M2M area network, 1104 an M2M gateway, an M2M server, a service layer 1202, a common service entity (CSE) 1402, an application entity (AE) 1404, a camera 1702, a gateway 1704, a data analytics service (DAS) 1802, a DAS hosting CSE 1804 and 2302, a data hosting CSE 1806, a DAS client 1808, a service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logical entities that create interfaces such as interfaces 2802 and 2804. The network node 30 can be part of an M2M network as shown in Figure 29A to 29B Figure 29C

[0199] The processor 32 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 can perform functions by executing computer executable instructions of one or more computer programs stored in the memories (e.g., memory 44 and / or memory 46) of the node. For example, the processor 32 can execute instructions for signal coding, data processing, power control, input / output processing, and / or any other functionality desired to be implemented by the M2M node 30. The processor 32 can run application layer programs (e.g., a browser) and / or radio access layer (RAN) programs and / or other communication programs. The processor 32 can also perform security operations such as, for example, authentication, security key agreement, and / or encryption operations, such as at the access layer and / or the application layer.

[0200] Figure 29C ​​​As shown, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). By executing computer executable instructions, the processor 32 can control the communication circuitry to cause the node 30 to communicate with other nodes via the network to which it is connected. Specifically, the processor 32 can control the communication circuitry to perform the transmitting and receiving steps described herein and in the claims. Although Figure 29C The processor 32 and transceiver 34 are depicted as separate components, it is to be understood that the processor 32 and transceiver 34 can be integrated together in an electronic package or chip.

[0201] The transmit / receive element 36 can be configured to transmit signals to, and receive signals from, other M2M nodes including M2M servers, gateways, devices, etc. For example, in one embodiment, the transmit / receive element 36 can be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 36 can support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, for example, the transmit / receive element 36 can be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 36 can be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 36 can be configured to transmit and / or receive any combination of wireless or wired signals.

[0202] In addition, although the transmit / receive element 36 is depicted in the Figure 29C embodiments, the M2M node 30 can include any number of transmit / receive elements 36. In particular, the M2M node 30 can employ MIMO technology. Thus, in an embodiment, the M2M node 30 can include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0203] The transceiver 34 can be configured to modulate information to be transmitted by the transmit / receive element 36 and to demodulate information received by the transmit / receive element 36. As indicated above, the M2M node 30 can be a multi-mode capability. Thus, the transceiver 34 can include multiple transceivers for enabling the M2M node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0204] Processor 32 can access information and store data in any suitable type of memory, such as non-removable memory 44 and / or removable memory 46. For example, as described above, processor 32 can store session context in its memory. Non-removable memory 44 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. Removable memory 46 may include a subscriber identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, processor 32 can access information and store data in memory that is not physically located on M2M node 30, such as a server or home computer. Processor 32 can be configured to control visual indications on the display to reflect the system status or to receive input from the user or to display information about capabilities or settings to the user. A graphical user interface that can be shown on the display can be layered on top of the API to allow the user to interactively perform the functions described herein.

[0205] The processor 32 can receive power from the power source 48 and can be configured to distribute and / or control power to other components in the M2M node 30. The power source 48 can be any suitable device for supplying power to the M2M node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0206] The processor 32 may also be coupled to a GPS chipset 50 configured to provide location information (e.g., longitude and latitude) about the current location of the M2M node 30. It should be understood that the M2M node 30 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0207] The processor 32 may be further coupled to other peripheral devices 52, which may include one or more software and / or hardware modules for providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 52 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0208] The node 30 can be implemented in other devices or apparatuses, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The node 30 can be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces, such as an interconnect interface that can include one of the peripherals 52. Alternatively, the node 30 can comprise the device or apparatus, such as a sensor, consumer electronics, wearable device such as smart watch or smart clothing, medical or e-health device, robot, industrial equipment, drone, vehicle such as car, truck, train, or airplane.

[0209] Figure 29D is a block diagram of an exemplary computing system 90 that can also be used to implement one or more nodes of an M2M network, such as an M2M server, gateway, device, or other node. The computing system 90 can comprise a computer or server and can be controlled primarily by computer readable instructions, which can be in the form of software, wherever, or by whatever means such software is stored or accessed. The computing system 90 can execute or include a logic entity, such as an M2M area network, 1104 M2M gateway, M2M server, service layer 1202, common service entity (CSE) 1402, application entity (AE) 1404, camera 1702, gateway 1704, data analytics service (DAS) 1802, DAS-hosted CSE 1804 and 2302, data-hosted CSE 1806, DAS client 1808, service type profile (STP) 2002, analytics capability 2004, 2006, and 2008, and logic to create an interface such as interfaces 2802 and 2804. The computing system 90 can be an M2M device, user equipment, gateway, UE / GW, or any other node including, for example, a mobile care network, service layer network application provider, terminal device 18, or M2M gateway device 14. Such computer readable instructions can be executed within a processor, such as central processing unit (CPU) 91, to cause the computer system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 can include multiple processors. Coprocessor 81 is an optional processor that is separate from the main CPU 91 used to perform additional functions or assist the CPU 91. The CPU 91 and / or coprocessor 81 can 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.

[0210] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus 80 communicates data or information between and among the components in computing system 90. System bus 80 is typically implemented as one or more busses, and is often split into several types of busses, such as an address bus, a data bus, and a control bus. These bus types are implemented either as separate busses, or as a signal on the same bus line. For example, data could be transferred on the same bus lines as are used to transfer control signals.

[0211] Memory resources coupled with system bus 80 include random access memory (RAM) 82, and read-only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to both RAM 82 and / or ROM 93 can be controlled by memory controller 92. Memory controller 92 can provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 can 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 only access memory mapped by its own process virtual address space, unless memory sharing between processes has been set up, in which case it can access another process's virtual address space.

[0212] Additionally, computing system 90 can contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drives 85.

[0213] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output can include text, graphics, animated graphics, and video. Display 86 can 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 96 includes electronic components required to generate a video signal to drive display 86. In one embodiment, display 86 is a touch-panel that also functions as an input device.

[0214] Further, computing system 90 can contain communication circuitry, such as, for example, a network adapter 97, that can be used to connect computing system 90 to an external communications network 12, such as, for example, the Internet, and enable computing system 90 to communicate with other nodes of the network. Figure 29A and Figure 29B Further, computing system 90 can contain communication circuitry, such as, for example, a network adapter 97, that can be used to connect computing system 90 to an external communications network 12, such as, for example, the Internet, and enable computing system 90 to communicate with other nodes of the network.

[0215] A user equipment (UE) can be any device used by an end user for communication. It can be a hand-held phone, a laptop computer equipped with a mobile broadband adapter, or any other device. For example, a UE can be implemented as Figure 29A to 29B an M2M terminal device 18 of Figure 29C a terminal device 18 of

[0216] It should be understood that any or all of the systems, methods, and processes described herein can be embodied in a computer- executable program (i.e., program code) stored on a computer-readable storage medium, which when executed by a machine, such as a node of an M2M network including an M2M server, gateway, device, etc., performs and / or implements the systems, methods, and processes described herein. In particular, any of the steps, operations, or functions described above in connection with the operation of a gateway, UE, UE / GW, or any node of a mobile core network, service layer, or network application provider can be implemented in the form of such computer-executable program code. The logical entities such as the M2M area network, 1104 M2M gateway, M2M server, service layer 1202, common service entity (CSE) 1402, application entity (AE) 1404, camera 1702, gateway 1704, data analytics service (DAS) 1802, DAS hosting CSE 1804 and 2302, data hosting CSE 1806, DAS client 1808, service type profile (STP) 2002, analytics capabilities 2004, 2006, and 2008, and logic entities that create interfaces such as interfaces 2802 and 2804 can be embodied in the form of computer-executable program code stored on a computer-readable storage medium. Computer-readable storage media include volatile and non-volatile, 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 include 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.

[0217] In describing the preferred embodiment of the subject matter of the present disclosure, specific terminology is employed for the sake of clarity. However, the claimed subject matter 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.

[0218] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and can include other examples that occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements in common with those recited in the claims or if they do not differ from the recited examples materially.< / stp> < / stp> < / contentinstance> < / das> < / stp> < / das> < / stp> < / stp> < / stp> < / container> < / contentinstance> < / subscription> < / container> < / container> < / subscription> < / container> < / container> < / contentinstance> < / contentinstance> < / contentinstance> < / contentinstance> < / contentinstance> < / contentinstance>

Claims

1. A method performed by a service entity in a network for a service, the service supporting service capabilities through a set of application programming interface (API) functions, the method comprising: The network receives a request from the application entity to perform a data analysis operation on the data. The request identifies the type of data analysis capability capable of performing the requested data analysis operation. The request also includes one or more parameters required by the identified type of data analysis capability, which are specified in a profile defined for the identified type of data analysis capability. The first data hosting entity is determined from among a plurality of data hosting entities in a service that stores the data to be used to perform the requested data analysis operation, wherein each of the plurality of data hosting entities is an element uniquely addressable in a resource-oriented architecture using a Unique Resource Identifier (URI) via a RESTful approach. The received request is forwarded to a second service entity in the network for the service, the second service entity for the service having a closer proximity than the application entity to the first data hosting entity, and wherein the second service entity is configured to request the data from the first data hosting entity; The second service entity receives a response to the requested data analysis operation on the data, wherein the result of the requested data analysis operation is available to the application via the set of APIs.

2. The method according to claim 1, wherein, The received request also includes the data to which the data analysis operation is to be performed.

3. The method of claim 1, further comprising retrieving the data to which the data analysis operation is to be performed based on the URI.

4. The method according to claim 1, wherein, The method is executed by the data analysis service of the service.

5. The method according to claim 4, wherein, The data analysis service interfaces with multiple different types of analytical capabilities.

6. The method according to claim 5, wherein, The process of converting the received request into an application programming interface (API) that conforms to the requested type of data analysis capability is performed by an interface converter of the data analysis service that interfaces with the requested type of analysis capability.

7. The method according to claim 5, wherein, The profile defining the data analysis capabilities for the identified type provides a mapping to the application programming interface of the requested type of data analysis capability to which a transformed request is sent.

8. The method according to claim 1, wherein, The requested data analysis operation is performed through the data analysis capability based on the subscription associated with the requested data analysis operation.

9. An apparatus including a processor and a memory, the apparatus further including computer-executable instructions stored in the memory of the apparatus, the computer-executable instructions, when executed by the processor of the apparatus, causing the apparatus to perform operations at a service, the service supporting service capabilities through a set of application programming interface (API) functions in a network, the operations including: The network receives a request from the application entity to perform a data analysis operation on the data. The request identifies the type of data analysis capability capable of performing the requested data analysis operation. The request also includes one or more parameters required by the identified type of data analysis capability, which are specified in a profile defined for the identified type of data analysis capability. The first data hosting entity is determined from among a plurality of data hosting entities in a service that stores the data to be used to perform the requested data analysis operation, wherein each of the plurality of data hosting entities is an element uniquely addressable in a resource-oriented architecture using a Unique Resource Identifier (URI) via a RESTful approach. The received request is forwarded to a second service entity in the network for the service, the second service entity for the service having a closer proximity than the application entity to the first data hosting entity, and wherein the second service entity is configured to request the data from the first data hosting entity; The second service entity receives a response to the requested data analysis operation on the data, wherein the result of the requested data analysis operation is available to the application via the set of APIs.

10. The apparatus according to claim 9, wherein, The received request also includes the data to which the data analysis operation is to be performed.

11. The apparatus according to claim 9, wherein, The computer-executable instructions also cause the device to retrieve the data to which the data analysis operation is to be performed, based on the URI.

12. The apparatus according to claim 9, wherein, The computer-executable instructions also cause the device to implement a data analysis service for the services of the network, the data analysis service performing the operations.

13. The apparatus according to claim 12, wherein, The data analysis service interfaces with multiple different types of analytical capabilities.

14. The apparatus according to claim 13, wherein, The process of converting the received request into an application programming interface (API) that conforms to the requested type of data analysis capability is performed by an interface converter of the data analysis service that interfaces with the requested type of analysis capability.

15. The apparatus according to claim 13, wherein, The profile defining the data analysis capabilities for the identified type provides a mapping to the application programming interface of the requested type of data analysis capability to which a transformed request is sent.

16. The apparatus according to claim 9, wherein, The requested data analysis operation is performed through the data analysis capability based on the subscription associated with the requested data analysis operation.

Images