A service layer-based approach for efficient analysis of IoT data

Abstract

Methods, systems, and apparatus that enable a service layer (SL) to support analysis of Internet of Things (IoT) data and enable shared access to information generated by the analysis. Analysis management services can allow SL entities to configure analysis functions for many different IoT data sources and organize the results in a customizable manner. The SL can support the coordination of analysis of IoT data from multiple independent sources and the organization of the results of the analysis.

Description

Background Art

[0001] IoT Service Layer (SL) is a technology specifically targeted at providing value-added services to IoT devices, IoT applications and IoT data. Recently, several industry standard bodies (e.g., oneM2M, ETSI, OCF and LWM2M) are developing IoT SL to address the challenges associated with integrating IoT devices, applications and data into deployments of Internet / Web, cellular, enterprise and home networks.

[0002] IoT SL can provide applications and devices with access to a set of IoT-oriented capabilities. Some examples include security, billing, data management, device management, discovery, provisioning, and connectivity management. These capabilities are available to applications via APIs that leverage the message formats, resource structures, and resource representations supported by IoT SL.

[0003] From the perspective of the protocol stack, SL usually sits above the application protocol layer and provides value-added services to the applications it supports. Therefore, SL is usually classified as a "middleware" service. Figure 1 An exemplary service layer between application protocols and applications is shown.

[0004] From a deployment perspective, IoT SL can be deployed on various types of network nodes, including Figure 2 Servers, gateways, and devices shown.

[0005] oneM2M TS-0001oneM2M functional architecture defines the IoT SL. The SL provides “horizontal” services that can be utilized by different “vertical” IoT systems and applications (such as e-health, fleet management and smart home). Figure 3 As shown, the architecture of oneM2M SL defines a public service entity (CSE) that supports four reference points. The Mca reference point is connected to the application entity (AE) interface. The Mcc reference point is connected to another CSE interface within the same service provider domain, and the Mcc' reference point is connected to another CSE interface in a different service provider domain. The Mcn reference point is connected to the underlying network service entity (NSE). The NSE provides underlying network services to the CSE, such as device management, location services, and device triggering. The CSE contains multiple logical functions called "public service functions (CSF)", such as "discovery", "data management, and repository". Figure 4 The diagram illustrates the CSF supported by oneM2M.

[0006] The oneM2M architecture is a distributed architecture and supports the deployment of IoT services in a distributed manner between the following types of nodes. An Application Service Node (ASN) is a node that contains one CSE and contains at least one Application Entity (AE). Example of physical mapping: ASN may reside in an IoT device. An Application Dedicated Node (ADN) is a node that contains at least one AE and does not contain a CSE. Example of physical mapping: Application Dedicated Node may reside in a constrained IoT device. An Intermediate Node (MN) is a node that contains one CSE and contains zero or more AEs. Example of physical mapping: MN may reside in an IoT gateway. An Infrastructure Node (IN) is a node that contains one CSE and contains zero or more AEs. The CSE in an IN may contain CSE functions that are not applicable to other node types. Example of physical mapping: IN may reside in an IoT service infrastructure. A Non-oneM2M Node (NoDN) is a node that does not contain a oneM2M entity (neither AE nor CSE). Such a node represents a device attached to the oneM2M system for interworking purposes, including management. Possible configurations of interconnections between various entities supported within the oneM2M system are as follows: Figure 5 shown.

[0007] Figure 6 A non-roaming reference architecture with service-based interfaces within the control plane is shown. Figure 7 Depicts the 5G system architecture for a non-roaming scenario, using reference point representations to show how various network functions interact with each other. Mobility management and session management functions are separated. A single N1 NAS connection is used for both registration management and connection management (RM / CM), and for SM-related messages and procedures for the UE. A single N1 termination point is located in the AMF. The AMF forwards SM-related NAS information to the SMF. The AMF handles the registration management and connection management parts of the NAS signaling exchanged with the UE. The SMF handles the session management part of the NAS signaling exchanged with the UE.

[0008] In 5G networks, 3GPP TS 23.501, System Architecture for the 5G System; Stage 2, Network Data Analysis (NWDA) is defined as a network function that represents the network analysis logical function managed by the operator. NWDA provides network data analysis specific to the network slice to the PCF. The PCF's subscription to NWDA is at the network slice level, and NWDA does not need to know the current subscribers using the slice. NWDA notifies / publishes slice-specific network status analysis information to the (one or more) PCFs that subscribe to the slice. This information is not subscriber-specific. The PCF uses this data in its policy decisions.

[0009] The NWDA reference point is located between the Network Data Analysis (NWDA) and the PCF. According to 3GPP TS 23.502, Procedures for the 5G System; Stage 2, the PCF can obtain analysis data from the NWDA through a request / response model or a subscription / notification model. Figure 8-Figure 10 These message flows are shown.

[0010] In 5G networks, two types of DSF are defined: Unstructured Data Storage Network Function (UDSF) and Structured Data Storage Function (SDSF). Fig.11 As shown, the 5G system architecture allows network functions to store or retrieve their unstructured data in or from the UDSF. The UDSF belongs to the same PLMN where the network function is located. The control plane NFs can share the UDSF to store their corresponding unstructured data, or can each have their own UDSF (for example, the UDSF may be located near the corresponding network function). UDSF is an optional feature that supports the storage and retrieval of information as unstructured data by any network function.

[0011] like Fig.12 As shown, the 5G system architecture allows NEF to store structured data in SDSF for internal and external network exposure by NEF. SDSF belongs to the same PLMN where the network exposure function (NEF) is located. SDSF is an optional function that supports the storage and retrieval of information as structured data through NEF. Summary of the invention

[0012] Disclosed herein are methods, systems, and apparatus that can enable a service layer (SL) to support analysis of IoT data and can enable shared access to information generated by the analysis. The analysis management service described herein can allow a SL entity to configure analysis capabilities for many different IoT data sources and organize the results in a customizable manner that allows for easier access and more refined authorization. The SL can support an analysis management service (AMS) that can coordinate the analysis of IoT data from multiple independent sources and organize the results of the analysis.

[0013] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] A more detailed understanding may be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings, in which:

[0015] Figure 1 An exemplary protocol stack supporting a service layer is illustrated;

[0016] Figure 2 illustrates exemplary IoT SLs deployed on various types of network nodes;

[0017] Figure 3 illustrates an exemplary oneM2M architecture;

[0018] Figure 4 illustrates an exemplary oneM2M public service function;

[0019] Figure 5 illustrates an exemplary configuration supported by the oneM2M architecture;

[0020] Figure 6 An exemplary 5G system service-based architecture is illustrated;

[0021] Figure 7 An exemplary non-roaming 5G system architecture is illustrated with reference points;

[0022] Figure 8 An exemplary NWDA subscription service is illustrated;

[0023] Fig. 9 An exemplary NWDA notification service is illustrated;

[0024] Fig.10 An exemplary NWDA request / response flow is illustrated;

[0025] Fig.11 An exemplary data storage architecture for unstructured data from any NF is illustrated;

[0026] Fig.12 illustrates an exemplary data storage architecture for structured data from NEF;

[0027] Fig.13 illustrates exemplary analytics management service deployment options;

[0028] Fig.14 An exemplary analytics management service flow chart is illustrated;

[0029] Fig.15 illustrates an exemplary AMS use case;

[0030] Fig.16 An exemplary communication with analytical functionality is illustrated;

[0031] Fig.17 An exemplary new AMS strategy is illustrated;

[0032] Fig.18 illustrates exemplary new IoT device data;

[0033] Fig.19 illustrates an exemplary AMS processing of AF results;

[0034] Fig. 20 illustrates an exemplary AMS result storage structure;

[0035] Fig.21 illustrates an exemplary result content annotation with AF results;

[0036] Fig. 22 An exemplary result content replication is illustrated;

[0037] Fig.23 An exemplary result content link is illustrated;

[0038] Fig.24 An exemplary access AMS result is illustrated;

[0039] Fig.25 illustrates an exemplary oneM2M AMS architecture;

[0040] Fig.26 An exemplary graphical user interface is illustrated;

[0041] Fig. 27 An exemplary AMS deployed in a 5GC is illustrated;

[0042] Fig.28 An exemplary communication with analytical functionality is illustrated;

[0043] Fig.29 illustrates exemplary displays (e.g., graphical user interfaces) that may be generated based on the methods and systems disclosed herein;

[0044] Fig. 30A illustrates an exemplary machine-to-machine (M2M) or Internet of Things (IoT) communication system in which the disclosed subject matter may be implemented;

[0045] Fig. 30B The diagram shows that Fig. 30A An exemplary architecture for use within an M2M / IoT communication system as shown in;

[0046] Fig. 30C The diagram shows that Fig. 30A An exemplary M2M / IoT terminal or gateway device for use in the communication system shown in; and

[0047] Fig.30DThe diagram shows Fig. 30A An exemplary computing system for various aspects of a communication system. DETAILED DESCRIPTION

[0048] In large-scale IoT deployments, huge amounts of data will be collected and stored. Big data analytics methods are used to generate meaning from raw data. Some types of big data analytics include historical data analysis, image classification or recognition. Generating value from the large amounts of data collected will require the ability to analyze the data efficiently.

[0049] IoT service layer capabilities focus on the collection and storage of data and access to that data. Providing data analytics requires a lot of external processing. For example, performing image recognition on photos from a security camera in oneM2M SL would require creating a container for each container storing those images. <subscription>resource. Then, as each image is stored in the oneM2M SL, a notification will be sent to the dedicated oneM2M application which will analyze that image. The results will then be written back to the location which also needs to be configured.

[0050] The above describes one type of configuration required for using image recognition functions with images stored in the SL. If multiple cameras are used, then the configuration must be repeated for each source of image data. If different "owners" of the camera need to perform the same type of analysis, then additional repeated configurations are added to the system. If there is no native support for data analysis in the IoT service layer, then the system designer or user needs to deal with a large number of repeated configurations. For example, consider a scenario in which the data analysis function is interested in a specific type of data. In this scenario, the service layer needs to be configured to know the type of data that each analysis function is interested in so that the service layer can forward the data to each interested data analysis function. Similar problems exist in the 3GPP 5G Core (5GC) network. 5GC network functions have access to a large amount of data about network activity or UE activity. A process is needed to define how the 5GC NF can be configured to provide selection information to the NWDAF.

[0051] Disclosed herein are methods, systems, and apparatus that can enable a service layer (SL) to support analysis of IoT data and can enable shared access to information generated by the analysis. The analysis management service described herein can allow SL entities to configure analysis functions for many different IoT data sources and organize the results in a customizable manner that allows easier access and more refined authorization. The SL can support an analysis management service (AMS) that can coordinate the analysis of IoT data from multiple independent sources and organize the results of the analysis. The AMS can be configured with multiple analysis functions that can analyze IoT SL data from multiple sources. The AMS can be configured with policies that customize the analysis performed on IoT data by specifying the configuration of an analysis function (AF) for each source or source group of IoT data. The AMS can be configured with policies that define how the results are stored in the IoT SL so that the results can be easily accessed. The AMS can be configured to inspect the new data as it arrives at the IoT SL and determine whether the new data should be sent to the AF. The AMS can provide a method for accessing the results of data analysis that efficiently accesses related data. The AMS may be configured to provide authorization to data having certain detected characteristics without granting authorization to the original data source. The AMS may be configured to provide pre-processing of selected data before storage in the IoT SL.

[0052] Fig.13 Figure 2 shows an exemplary AMS deployment option. Fig.13 As shown, the AMS 101 may be supported as a service within an IoT SL hosted on a server, gateway, or device. Fig.14 An exemplary architecture of an AMS is illustrated. The AMS 101 may be configured with policies (AMS policies 102) that define how to configure analysis functions, select IoT data to be sent to analysis processing, and how to make the results of analysis processing available to IoT entities. AMS policies will be described in more detail herein. As IoT data 110 arrives at the SL from the sensor, the AMS 101 may monitor the IoT data 110. At step 110, the IoT data arrives at the SL, which is a trigger to start an action (103) of comparing information about the data with the AMS policies to determine what to do next (103). Accessing the AF results 112 is an entity attempting to access the stored data. Once the data is stored, access has a pair of new APIs that can be used (e.g., request 171-request 175 disclosed below). The AMS 101 may compare information about the IoT data 110 with the AMS policies 102 to determine (at box 103) whether the IoT data should be sent to an analysis function (AF) 111. The AF 111 may be viewed as a service that performs analysis on data sent by the IoT SL and provides the results back to the SL. The AF may be a NWDA as described herein. Network Data Analysis (NWDA) is defined as a network function that represents a network analysis logic function managed by an operator. The AMS 101 may receive results from one or more AFs 111. The AMS policy 102 may define how the results (e.g., AF data 105) from the AF 111 are stored and made available to SL entities. The receipt and storage of AF data 105 is described in more detail herein.

[0053] Fig.15 An exemplary AMS 101 use case is provided. In this use case, a video camera is positioned in or around a building. The video camera, and perhaps other sensors, are used for security in the building. The sensors (including the camera) send data to the SL, where the data is stored. The desired result is to identify all persons entering and leaving the building. Persons entering should be identified by name or ID. Users of the SL data want to be able to quickly see who has entered the building, see who is remaining in the building, and find the identities of the persons remaining in the building. The AMS policy 102 is configured to analyze the data captured from all web camera images. (One or more) AFs analyze the image to determine if there is a person in the image, whether the person is entering or leaving, and who is remaining in the building (the implementation of this AF is not described in depth, but is within the capabilities of current image recognition services). The AMS policy 102 also defines how the AF results are stored so that images are grouped in a way that allows access to each of these desired categories (e.g., images with "recognized" persons are in a single location).

[0054] The AMS 101 may be configured with policies that define how to configure the analysis function 111, select which IoT data to send to the analysis process, or how to make the results of the analysis process available to the IoT entity. These rules may be defined via AMS policy attributes, such as those suggested in Table 1. In one example, the AMS policy may be stored in a SL resource. The SL resource may be created, retrieved, updated, or deleted by the AMS 101 or the SL entity, or both.

[0055] Table 1 - Analytics Management Service (AMS) Strategy

[0056]

[0057]

[0058]

[0059] The following attributes (device (e.g., data creator), user (e.g., profile using analyzed data), data type, metadata, or data schema) describe how the SL may select data to send to the AF 111. These attributes may be used as oneM2M attributes.

[0060] Devices (e.g., data creators like specific sensors) - AMS 101 can send data to AF 111 based on a specific list of devices or data sources. For example, a list of door sensors can be specified to send sensor states from door 1, door 2, and door 5 to AF 111.

[0061] The User-AMS 101 may send data to the AF 111 based on a general list of devices or data sources. For example, all measurements from my sensors in my apartment may be sent to the AF 111, perhaps to identify if someone is home. This may represent a group of sources based on common properties of the sources, such as they all belong to Profile 1 (which may be a subscriber).

[0062] Data Type - The AMS 101 may send data to the AF 111 based on the type of data present. For example, all temperature sensor data may be sent to the AF 111.

[0063] Metadata - The AMS 101 can send data to the AF 111 based on the metadata that exists. For example, sensors from a parking lot can be sent to the AF 111.

[0064] Data mode - continuous / single shot mode / both / sample range / periodic schedule

[0065] The following attributes (data representation, data destination, data analysis configuration, or data analysis feedback) describe how to communicate with the AF 111. Some of these parameters may not be visible or accessible to the SL entity, but are private between the AMS 101 and the AF 111, which is discussed in more detail herein.

[0066] Data representation - information about the data, an indication that new data is available in the SL (so that the AF can fetch the data independently), or a partial representation of the data including contentOnly (without associated meta information), or some custom representation defined by the AF's interface.

[0067] Data Destination - API for communication between AF and SL

[0068] Data analysis configuration - specify the features to look for (image library, thresholds, etc.)

[0069] Data Analysis Feedback - When data analysis can be improved by confirming detected characteristics, such feedback can be sent here. For example, an AF that recognizes the ID of a person in an image can request confirmation that the ID is correct and adjust the parameters of the AF based on this confirmation.

[0070] Each AMS policy, such as result location, result content, or result accessibility can help define the configuration of how the results are stored. Referring to the result location, it can specify where the results from AF111 are stored. For example, the result location can define the root location for storing results from AF111. The default value can be a child of the AMS policy. It can be specified as the original location of the IoT source data. In another example, the result structure can be specified as fixed or dynamic. If the result structure is fixed, then the policy can specify a specific structure for data storage. If the result structure is dynamic, then the data structure can be generated based on the characteristics detected by AF.

[0071] Regarding the result content, it can specify a copy, an annotation, or a link. If the result content is an annotation, the analyzed original IoT data can be updated to reflect the characteristics detected by AF 111. If the result content is a copy, a copy of the analyzed IoT data can be stored in the result location specified by the root location and the result structure (result location). The copy of the data can be annotated with the characteristics detected by AF 111. If the result content is a link, a reference to the original IoT data can be stored in the result location specified by the root location and the result structure (result location). The stored reference can be annotated with the characteristics detected by AF 111.

[0072] Regarding result accessibility, results from AF 111 can be organized based on data content. Results can be generated by analyzing data from multiple IoT sensors or services. In the context of result accessibility, considerations may include authorization, access methods, and sorting. Authorization-SL entities that do not have access to raw sensor data in the original location can be granted authorization to selected portions of the raw data based on the presence of features detected by AF 111. For example, referring to the above use case, if the image analyzed by AF 111 indicates that employee #1234 has entered a building, then the stored results may include authorization for the employee #1234 to access this particular image without giving access to any other images. Access Method-SL entities can access AF111 results using linked list type operations (such as getFirst, getNext, getPrevious, getLast). These access methods can take into account the authorization of the SL entity. For example, if employee #1234 wants to see the time she entered the building over a period of time, she can request the first result from the "Entry" analysis. This can return the time when employee #1234 first entered the building. Employee #1234 can then request the next result, which may skip all images that she does not allow authorization for and return the next result that she does have authorization to access. Sorting - Results can be sorted chronologically by source of data date, alphabetically by annotation properties, or by other metadata inherent to the SL.

[0073] It should be understood that the implementation of this article (such as Figure 16-Figure 19 ) can be logical entities. These steps can be stored in Fig. 30C or Fig.30D In the example, the interaction of M2M devices is further described below. Fig.16 The IoT device 120 may reside in Fig. 30A On the M2M terminal device 18, Fig.16 The IoT SL 115 can reside in Fig. 30A On the M2M gateway device 14. It is assumed in this article (for example, Figure 16-Figure 19 ) Steps may be skipped, combined, or added between the exemplary methods disclosed.

[0074] Fig.16 An exemplary method for communicating with the analysis function 111 is illustrated. The AMS 101 supports data (e.g., data associated with the results of utilizing one or more AFs, such as Fig.16 The AMS 101 may be pre-provisioned with the identity of the AF 111 with which it should communicate. In addition, there may be pre-configured AMS policies. The information that appears may be consistent with the configuration method described below.

[0075] At step 121, any particular AF may or may not be dedicated to the IoT SL for which it provides services, so the AMS 101 and AF 111 may establish a relationship between them. Examples of basic message components, such as IoTSL ID or AF ID, are described below. Additional parameters may be provided, which may depend on the deployment. Regarding the IoT SL ID, if the AF 111 supports more than a single IoT SL, then this identifier may be used to authorize messages from the IoT SL 115. If the AF 111 only supports a single IoT SL, then this identifier may not be required. Regarding the AF ID, if the IoT SL 115 supports more than a single AF, then this identifier may be used to authorize messages from the AF 111. If the IoT SL 115 only supports a single AF, then this identifier may not be required. The AF ID may be pre-provisioned or provided as part of the registration process. The IoT SL 115 may store this identifier for authentication and authorization purposes.

[0076] If the AF 111 only supports a single IoT SL, then the registration process can be simplified to simply checking if the AF 111 exists and responds, which in some deployments can be assumed to be always true. Registration can be initiated by either the IoT SL 115 or the AF 111.

[0077] At step 122, the configuration of the desired service performed by the AF 111 is specified by the AMS policy in the IoT SL 115. The IoT SL 115 may have multiple AMS policies configured by different IoT entities to support a variety of different IoT sensors or data sources. These policies may be pre-provisioned into the IoT SL 115, or they may be specified by the IoT SL entity (application or device). The following method for conveying relevant information from an AMS policy (such as the policy defined herein with respect to the relevant AF) is described. In step 122, the configuration information required by the AF is sent to the AF.

[0078] At step 123, the relevant part of the AMS policy is sent to the AF along with the AMS policy ID in the "policy configuration message". This can use the standard protocol of the IoT SL or the standard protocol of the AF or a custom protocol. The AMS service will also send policy changes to the AF when the policy changes. In step 123, the SL sends the AMS policy id to the AF so that the AF can request the required configuration information from the SL. In the figure, m1 (122) and m2 (123) represent method 1 and method 2. Method 3 is mentioned below. Only one method is required, so if step 127 is used, then step 122 and step 123 may not exist. And if step 122 is used, then step 123 and step 127 may not exist. The same is true for step 123.

[0079] At step 124, the AMS policy ID is sent to the AF. The AF can then access the AMS policy from the IoT SL as needed. This is mainly suitable for standard protocols using the IoT SL. Example: If the AF can use the oneM2M protocol, then steps 123 / 124 may be appropriate. However, if the AF is an existing service that is not aware of oneM2M, then step 122 may be more appropriate.

[0080] At step 125, when the IoT data is sent to the AF 111, the message may include relevant information from the AMS policy. This is well suited for very simple analysis, such as threshold or value checks. For example, if an IoT sensor provides a temperature value, then an AMS policy might be established to generate an "overheat" determination, where the determination may be different based on which IoT sensor the data came from. The AMS also sends the policy ID in the message so that the results can be handled correctly. Note Method 1 and Method 2 (step 126) and Method 3 (step 127).

[0081] The use of one of the methods of communicating configuration information may be determined by the capabilities of the IoT SL 115 and the AF 111. The capability may refer to whether the AF can use the SL API (e.g., protocol) or whether the SL must use the AF API (e.g., protocol).

[0082] At step 126, when IoT data is sent to AF 111, the AMS policy may define what data is to be sent. Some options may not apply to some AF and IoT SL deployments. The message sent by the AMS to the AF may have elements such as IoT data to be analyzed, AF configuration, IoT SL ID, or AMS transaction ID. IoT data to be analyzed - this can be a single sensor value that is evaluated independently, i.e. a threshold check, or it can be a single sensor data that the AF analyzes in the context of the history of data that came before this sample, such as time series data, or the AMS may send blocks of historical data in one or more messages, such as partial time series data. AF configuration - this can be expressed as an AMS policy ID or an AF attribute from an AMS policy. IoT SL ID - this is present in the case that the AF 111 supports more than one IoT SL. If the AF 111 supports only one IoT SL, then this value may be ignored or omitted. AMS transaction ID - a value generated by the AMS 101 and sent to the AF 111. The AF 111 may include the AMS transaction ID in the response (step 128). AMS Transaction ID Address Communication can be synchronous and asynchronous, in the asynchronous case, an ID is required so that the SL can tell what the message refers to.

[0083] At step 127, when the results are sent from the AF 111 to the AMS 101, the message from the AF 111 may have data elements such as AF results, AMS policy ID, or AMS transaction ID. AF results - This is the output of the analysis performed by the AF. In some cases, the AF may combine the results with the original data. The exact format of the results is determined by the IoT SL and the AF embodiment. The AF may also send aggregated results based on a periodic schedule or result type. AMS policy ID - This is used to determine how the results are handled. This value may be eliminated if synchronous communication is used between the SL and AF 111, or if the AMS transaction ID is used to determine this information. AMS transaction ID - A value generated by the AMS 101 and sent to the AF 111. The AF 111 may include this in the response (step 128).

[0084] There are two conditions that can trigger the sending of IoT SL data to AF 111. The first is when a new AMS policy is created (see Fig.17 ), and secondly when creating new IoT SL data (see Fig.18 ). Modifications to policies or IoT SL data are also equivalent triggers. In this article, unless otherwise stated, when discussing new data being created, the term modification (update) is assumed to be included.

[0085] Fig.17 An exemplary method for a new or updated AMS policy is illustrated. At step 131, the AMS 101 may receive a request to create or update an AMS policy. At step 132, based on the request of step 131, the AMS 101 may determine whether the requested AMS policy is for a continuous data mode or a periodically scheduled data mode (or another data mode). At step 133, based on the data mode (e.g., the attributes in Tables 1 and 4), the requested AMS policy of step 131 is updated or created, and the updated or created AMS policy is added to a registry of AMS policies that need to be checked each time new IoT SL data is created (continuous) or based on a provided schedule (periodically scheduled). For a periodically scheduled data mode, the schedule may be provided during the request of step 131 or based on a subsequent message from an authorized device (not shown). At step 134, the AMS 101 may discover existing SL data (e.g., IoT data) that matches the IoT data selection information (also referred to herein as criteria or attributes), and may send the appropriate data representation as specified by the data representation information (also referred to herein as criteria or attributes) to the AF 111 specified by this AMS policy. This step 134 may be based on a data pattern, such as a single shot or a range of samples.

[0086] Fig.18 An exemplary method for new IoT device data is illustrated. At step 141, the IoT SL 115 receives new data from a SL entity such as a sensor. At step 142, the AMS 101 evaluates the new data to determine whether it should be sent to one or more AFs based on comparing meta information associated with the new data to the IoT data selection attribute of the AMS policy. At step 143, if the AMS policy indicates that the new data should be sent to a first AF of multiple AFs, then the AMS 101 sends an appropriate data representation. The data representation can be based on content specified by the data representation attribute. The new data can match more than one AMS policy, in which case the new data is sent to each matching AF 111.

[0087] Continue to refer Fig.18 , the IoT SL entity can create new data associated with a specific AMS policy. If the new data is directly associated with the AMS policy, the AMS 101 can send the new data directly to the AF 111 without evaluating the IoT data selection attribute of the policy. If the AMS 101 only sends a portion of the new data, the AMS 101 may be required to maintain the original data until a response is returned from the AF 111. The AMS 101 can then store the data and the annotations provided by the AF or the AMS 101 can remove the new data. If the result is stored, the IoT SL 115 can respond to the IoT entity that the data has been created; or if the result is not stored, it can respond with OK, or once the AMS 101 receives the AMS target data, it can respond with OK.

[0088] Fig.19 Illustrated is an exemplary AMS 101 processing of AF 111 results. The AMS 101 may store results returned from the AF 111 in a configurable manner that allows for specification of a structure for storage, annotation of the data to better understand or discover semantics, or efficient access to data that may have common characteristics but from different sources. For the following description in Table 2, the following message may be sent from the AF 111 to the AMS 101. The first value may represent an identifier of the data being analyzed (e.g., Image 2), and the remaining values ​​may represent detected characteristics (e.g., Image 2, Identified, and ID #2). In some data, no characteristics were detected (e.g., Image 5-Image 8).

[0089] Table 2

[0090]

[0091]

[0092] refer to Fig.19 At step 151, the AMS 101 receives a message, which may include a result from the AF 111. The AMS 101 uses the AMS policy ID to determine that the first AMS policy defines the processing of the result. If the result is a response to a synchronization message between the AMS 101 and the AF 111, then the AMS policy is known. At step 152, the AMS 101 stores the result based on the result location attribute of the first AMS policy. In the restful IoT SL, this can be the target location of the result. In other implementations, this can be a table or a document. Once the root location is determined, the result structure can be further specified as "fixed" or "dynamic". If it is fixed, then the specified root location is where all results may be located. If it is dynamic, then the specified root location will be attached to the information returned in the result from the AF 111. For example, if the image recognition AF provides results in the following ways: 1) Recognized / Unrecognized-AF examines all provided images. If a person is detected in the image, it will try to identify the person in the image; and 2) Identity-If the AF recognizes the image, then the identity associated with the image is returned. In this case, the results can be stored in Fig. 20 The structure shown, where a copy of the analyzed data is stored by the AMS 101 in a structure determined by the detected characteristics. The root is the starting point for all other parts of the overall location. In the case of "dynamic", the final storage location may be (using examples from the text) <root> / <identified> / <id>or | <root> / <unidentified>.

[0093] At step 153, the AMS 101 may determine how to store the results from the AF 111 based on the result content attributes of the AMS policy (such as annotation, copy or link). Step 152 describes "where" to store the results. Step 153 describes "what" to store.

[0094] Regarding annotations, the analyzed data stored in the IoT SL 115 may be updated with annotations based on the results provided by the AF 111. For example, if the images in Table 2 were stored in the structure based on the camera providing the images, the annotations made may be as follows: Fig.21 Annotations (such as annotation 161 or annotation 162) are indicated in text to the right of the image.

[0095] With respect to replication, the data remains in its original location and a new copy of the data may be stored based on the resulting location attribute of the AMS policy. Fig. 20 shows an example of using a dynamic structure (not shown with comments, but with Fig.21 An example of a fixed structure is Fig. 22 In addition to creating a copy, the original data can still be annotated.

[0096] Regarding linking, the data can remain in its original location and a link to the data can be stored based on the resulting location attribute of the AMS policy. This has the benefit of not duplicating the data but still having the ability to find everyone in a single location. Fig.23 An example is shown in . In addition to creating links, the original data can still be annotated.

[0097] At step 154, the AMS 101 makes the results from the AF 111 dynamically accessible based on the authorization to access each individual data object or resource. This allows multiple data sources to be analyzed using a single AMS policy while still maintaining the ability to restrict access to appropriate entities. Some examples of access methods are Fig.24 shown.

[0098] In these requests, it is assumed that only "administrators" have access to the raw data from the camera. When the AMS 101 receives the results from the AF 111, the raw resource is annotated with information indicating the analysis results, in these examples "unidentified" or "identified" and "id#". In addition, when the result indicates "identified", the linked or replicated storage method grants authorization to the "identified" SL entity.

[0099] Request 171: Request 171 is made by "Administrator" and therefore has access to all results. When the request targets the root location of the AMS results with " / first" appended, then the response is the first data element in that location.

[0100] Request 172: When the target of the request is an element below the root location of an AMS result appended with " / next", then the response is the data element after the target in that location.

[0101] Requests 173-174: Request 173 is made by "Id#2" and request 174 is made by "Id#4". When the target of the request is the root location of an AMS result with " / first" appended, then the response is the first data element in that location to which the requester has access rights. Therefore, the responses are AF result 174 and AF result 172, respectively.

[0102] Request 175: Request 175 is made by "Id#4". When the target of the request is an element below the root location of an AMS result with " / next" appended, then the response is the next data element after the target in that location for which the requester has access rights. Therefore, the response is AF result 173.

[0103] Request 176: Request 176 was made by "Id#4". The requester was given authorization to access the data through the AMS result, but was not given authorization to access the original data source. Therefore, the response was a permission denied error.

[0104] The "sort" property of an AMS policy can specify specific properties or metadata of the original resource to sort by, for example, "data creation time". The sort will determine the order in which the results are returned. Methods for accessing "previous" and "last" are also supported.

[0105] The following discloses an example of oneM2M (oneM2M TS-0001 oneM2M functional architecture). Within the oneM2M architecture, the AMS 201 may be implemented as follows: Fig.25 A new Common Service Function (CSF) of the Common Service Entity (CSE) is shown. The new CSF can be used to enable AMS 201 support in the oneM2M system.

[0106] In the oneM2M example, AMS 201CSF can support analytical function resources. <af>The properties of a resource may be read-only to the AE or CSE and may be provisioned into the AMS 201 CSF using an out-of-band mechanism such as device management. <af>A resource may support attributes as defined in Table 3, which are selected from the AMS policy attribute definitions associated with AF configuration attributes disclosed herein.

[0107] Table 3- <af>Resource attributes

[0108]

[0109]

[0110] In the oneM2M example, AMS 201CSF can be <amspolicy>Specific data analysis strategy information is maintained in resources. <amspolicy>Resources can be created, updated, and deleted by either AE or CSE. <amspolicy>Resources may support the attributes defined in Table 4, which are based on the AMS policy attributes defined in this document.

[0111] Table 4- <amspolicy>Resource attributes

[0112]

[0113]

[0114]

[0115] In the oneM2M example, AMS CSF can support linking container resources. <linkresource>The attributes of resources can allow SL entities to easily traverse resources from multiple different sources, thereby granting access to limited or specific data without granting access to all data. For example, access to only specific <contentinstance>access, rather than the entire <container>and all subresources. <linkresource>Virtual resources can allow for more flexible navigation of container subresources. <linkresource>Resources can be created, updated, or deleted by either the AE or the CSE. <linkresource>Resources may support attributes as defined in Table 5, which may be accessed based on the AMS access methods defined herein (e.g., Fig.19 ). <linkresource>Can be a child of a content holding resource, such as <container> 、 <timeseriescontainer>or <flexcontainer>This resource can also be used to make access to other resource types more efficient, such as allowing a single <subscription>Used for multiple "subscribed-to" resources.

[0116] Table 5- <linkresource>Resource subresources and properties

[0117]

[0118]

[0119]

[0120] Analysis Management Service GUI - The sample application provides security monitoring services for a building, such as an office building. Fig.26 The left side of the example shows a drop-down selection box that can be used to populate an AMS policy, while the right side shows the result of one of the images being unavailable due to the authorization attributes of the image. This example demonstrates the desired result of using input from cameras located at all "building entrances" to display "unrecognized" people. This user may not be allowed to access the original image, but when an "unrecognized" person is detected, the user will be authorized to view the image. This example shows two "unrecognized" people, and the remaining people detected are not visible.

[0121] In 3GPP embodiments, the AMS may exist within a 5G core network function (5GC NF), such as AMF, SFM, or UPF. It may also exist with the RAN. Each AMS instance may be used to determine which data to send to the NWDAF. The location of the AMS may be instantiated within the 5GC, such as Fig. 27 The dotted line shows the connection between 5GC NF and NWDAF. Of course, AMS can also have Fig. 27 Network functions other than those shown in , such as UDM, AUSF, PCF, etc.

[0122] A 5GC network function supporting AMS functionality may expose an AMS policy creation (AMSPolicyCreation) service. Another NF (e.g., NWDAF) may call the AMS policy creation service to provide an AMS policy (e.g., the policy shown in Table 1) to the 5GC network function. For example, a 5GC NF such as an AMF, SFM, or UPF may support the AMS policy creation service. The NWDAF may call the AMS policy creation service to provide the 5GC NF with a policy describing which data should be sent to the NWDAF. As described herein, the IoT data selection criteria may also include the identity of the (one or more) UEs or the group of (one or more) UEs whose information the NWDAF wants, or the NWDAF may indicate that it wants information related to all UEs or certain types of UEs or only roaming or non-roaming UEs. The data type in the IoT data selection criteria may indicate that the NWDAF expects information about mobility events (registration updates, configuration updates, etc.), session events (e.g., service requests, PDU session requests, etc.), which power saving modes are configured, which communication modes are configured, etc. When NWDAF calls the service, it can also indicate where the data should be sent (e.g., a specific RESTful resource in NWDAF). Note that AMS policy creation can be called by other NFs, such as PCF, or by application functions that expose a management GUI to network administrators.

[0123] When a 5GC NF (e.g., SMF, AMF, or UPF) detects an event or data that matches the criteria indicated in the policy provided when invoking AMS policy creation, the 5GC NF may take action to store the results. How the results are stored depends on the result storage preferences indicated in the AMS policy (e.g., result location, result content, or result accessibility). The AMS policy may indicate where the results should be stored and whether the 5GC NF should provide the results or a link to the results. The policy may also indicate how often the 5GCNF should report updated results to the AMS policy creation caller (e.g., how long to aggregate data before providing it to the AMS policy creation caller).

[0124] The 5GC network function supporting the AMS function may expose an AMS analysis-based configuration (AMSAnalyticsBasedConfiguration) service. Another NF (e.g., NWDAF) may call the AMS analysis-based configuration service to provide updated configuration information to the 5GC NF based on data obtained as a result of calling the AMS policy creation service with the 5GC NF and other 5GC NFs. The AMS analysis-based configuration may be a specialized service based on the NF type. Table 6 shows an example of how various network functions may be configured based on the analysis information.

[0125] Table 6. Example of how NWDAF can configure 5GC network functions.

[0126]

[0127]

[0128] Fig.28 2 shows how, for example, in 5GC, communication between 5GC NF 202 and NWDAF 203 can be performed to implement the functions described herein (e.g., Fig.16 , Fig.19 or Fig. 20 ). Fig.28 The process of providing an example of how a 3GPP 5GC analysis function (e.g., NWDAF 203) can communicate with a 5GC network function 202. At step 221, if the 5GC NF 202 and the NWDAF 203 are not pre-configured to know each other's communication, the 5GC NF 202 can use the NRF to discover the NWDAF 203, or the NWDAF 203 can use the NRF to discover the 5GC NF 202. In step 222, the NWDAF can establish a connection with the 5GC NF (or vice versa).

[0129] Continue to refer Fig.28 In step 223, NWDAF 203 may invoke the AMS policy creation service of 5G NF 202 to configure 5GC NF 202 with a data analysis collection policy, as described herein. In step 224, 5GC NF 202 may send data to NWDAF 203 based on the policy configured in step 223. Fig.28 In this example, 5GC NF 202 may push the collected data to NWDAF 203, but as described herein, other communication models may be used to send data from 5GCNF 202 to NWDAF 203 (e.g., NWDAF 203 may make a request to 5GC NF 202 to retrieve the data, such as Fig.24 In step 225, NWDAF 203 may call the AMS analysis-based configuration service to configure 5GC NF 202 based on the data that has been collected from 5GC NF 202 and other 5GC NFs.

[0130] Table 7 includes abbreviations and Table 8 includes exemplary definitions of terms.

[0131] Table 7 Abbreviations

[0132]

[0133]

[0134] Table 8 Definition

[0135]

[0136]

[0137] Without in any way unduly limiting the scope, interpretation, or application of the claims appearing herein, the technical effect of one or more examples disclosed herein is to provide adjustments to the use or management of analytical processing. The methods, systems, and apparatus disclosed herein may enable a service layer (SL) to support analysis of IoT data more efficiently than conventional systems, and may enable shared access to information generated by the analysis. The analytical management service described herein may allow a SL entity to configure analytical capabilities for many different IoT data sources and organize the results in a customizable manner that may allow for easier access and more refined authorization.

[0138] Fig.29 An exemplary display (e.g., a graphical user interface) that can be generated based on the methods and systems discussed herein is illustrated. A display interface 901 (e.g., a touch screen display) can provide text associated with the analysis of IoT data in box 902, such as the parameters of Tables 1 to 8. In another example, the progress of any step discussed herein (e.g., a message sent or the success of a step) can be displayed in box 902. In addition, a graphical output 903 can be displayed on the display interface 901. The graphical output 903 can be a topology of a device (e.g., IoT device 120), a graphical output of the progress of any method or system discussed herein, etc.

[0139] Fig. 30A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed concepts associated with enabling analysis of IoT data (e.g., Figure 13-Figure 29 and accompanying discussion). In general, M2M technologies provide the building blocks for IoT / WoT, and any M2M device, M2M gateway, or M2M service platform can be a component of IoT / WoT as well as IoT / WoT service layer, etc.

[0140] like Fig. 30A As shown, the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include multiple access networks that provide content such as voice, data, video, messaging, broadcasting, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, the communication network 12 may include other networks, such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0141] like Fig. 30A 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 the end-to-end M2M deployment, and the field domain refers to the regional network usually behind the M2M gateway. The field domain includes an M2M gateway 14 and a terminal device 18. It will be appreciated 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 desired. Each of the M2M gateway device 14 and the M2M terminal device 18 is configured to send and receive signals via a communication network 12 or a direct radio link. The M2M gateway device 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate either through an operator network such as the communication network 12 or through a direct radio link. For example, the M2M device 18 may collect data via the communication network 12 or a direct radio link and send data to the M2M application 20 or the M2M device 18. The M2M device 18 may also receive data from the M2M application 20 or the M2M device 18. In addition, data and signals may be sent to and received from the M2M application 20 via the M2M service layer 22, as described below. The M2M device 18 and the gateway 14 may communicate via various networks, including cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio links, and wirelines.

[0142] refer to Fig. 30B , the M2M service layer 22 (e.g., IoT SL 115 as described herein) in the field domain is shown to provide services for M2M applications 20 (e.g., IoT devices 120), M2M gateway devices 14, and M2M terminal devices 18, as well as the communication network 12. It will be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 can be implemented by one or more servers, computers, etc. The M2M service layer 22 provides service capabilities applied to M2M terminal devices 18, M2M gateway devices 14, and M2M applications 20. The functionality of the M2M service layer 22 can be implemented in various ways, such as as a web server, in a cellular core network, in the cloud, and so on.

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

[0144] Also refer to Fig. 30B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that different applications and verticals can fully utilize. These service functions 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. Basically, these service capabilities relieve the application of the burden of implementing these functions, thereby simplifying application development and reducing costs and time to market. The service layers 22 and 22' also enable the M2M applications 20 and 20' to communicate in relation to the services provided by the service layers 22 and 22' over various networks 12 and 12'.

[0145] In some examples, as disclosed herein, the M2M applications 20 and 20' may include desired applications that communicate using analytics that enable IoT data. The M2M applications 20 and 20' may include applications in a variety of industries, such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and monitoring. As mentioned above, the M2M service layer that runs between the devices, gateways, and other servers of the 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 the M2M applications 20 and 20'.

[0146] The analysis of IoT-enabled data of the present application can be implemented as part of a service layer. The service layer is a middleware layer that supports value-added service functions through a collection of application programming interfaces (APIs) and underlying network interfaces. M2M entities (e.g., M2M functional entities such as devices, gateways, or services / platforms implemented on hardware) can provide applications or services. Both ETSIM2M and oneM2M use a service layer, which can include the analysis of IoT-enabled data of the present application. The oneM2M service layer supports a collection of common service functions (CSFs) (i.e., service capabilities). An instantiation of a collection of one or more specific types of CSFs is called a common service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). In addition, the analysis of IoT-enabled data of the present application can be implemented as part of an M2M network that uses a service-oriented architecture (SOA) or a resource-oriented architecture (ROA) to access services such as the analysis of IoT-enabled data of the present application.

[0147] As disclosed herein, the service layer can be a functional layer within a network service architecture. The service layer is typically located above an 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 located at a lower resource layer (such as, for example, a control layer and a 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, several industry standard organizations (e.g., oneM2M) have been developing an M2M service layer to address the challenges associated with the integration of M2M-type devices and applications into deployments such as the Internet / web, cellular, enterprise, and home networks. The M2M service layer can provide various devices with access to the above-mentioned capabilities or functional sets supported by the service layer, and the service layer can be referred to as a CSE or SCL. Some examples include, but are not limited to, security, charging, data management, device management, discovery, provisioning, and connectivity management, which can be used by various applications in common. These capabilities or functions make these various applications available 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 may be implemented by hardware or software, and provides (service) capabilities or functions (ie, functional interfaces between these functional entities) exposed to various applications or devices so that they use such capabilities or functions.

[0148] Fig. 30C is a system diagram of an example M2M device 30, such as, for example, an M2M terminal device 18 (which may include an IoT device 120) or an M2M gateway device 14 (which may include Fig.16 One or more components in ). Fig. 30C As shown in , the M2M device 30 may include a processor 32, a transceiver 34, a transmit / receive element 36, a speaker / microphone 38, a keypad 40, a display / touchpad 42, a non-removable memory 44, a removable memory 46, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. It will be appreciated that the M2M device 30 may include any sub-combination of the foregoing elements while remaining consistent with the disclosed subject matter. The M2M device 30 (e.g., IoT device 120, IoT server 116, etc.) may be an exemplary implementation of the disclosed systems and methods for enabling analysis of IoT data.

[0149] The processor 32 may 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 32 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables the M2M device 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit / receive element 36. Although Fig. 30C The processor 32 and transceiver 34 are depicted as separate components, but it will be appreciated that the processor 32 and transceiver 34 may be integrated together in an electronic package or chip. The processor 32 may execute application layer programs (e.g., a browser) or radio access layer (RAN) programs or communications. For example, the processor 32 may perform security operations such as authentication, security key negotiation, or encryption operations, such as at the access layer or application layer.

[0150] The transmission / reception element 36 may be configured to transmit signals to or receive signals from the M2M service platform 22. For example, the transmission / reception element 36 may be an antenna configured to transmit or receive RF signals. The transmission / reception element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an example, the transmission / reception element 36 may be a transmitter / detector configured to, for example, transmit or receive IR, UV, or visible light signals. In yet another example, the transmission / reception element 36 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmission / reception element 36 may be configured to transmit or receive any combination of wireless or wired signals.

[0151] Furthermore, although the transmit / receive element 36 is Fig. 30C Although depicted as a single element in the figure, the M2M device 30 may include any number of transmit / receive elements 36. More specifically, the M2M device 30 may employ MIMO technology. Thus, in an example, the M2M device 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0152] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and demodulate signals received by the transmit / receive element 36. As described above, the M2M device 30 may have multi-mode capabilities. Thus, for example, the transceiver 34 may include multiple transceivers for enabling the M2M device 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0153] The processor 32 may access information from and store data in any type of suitable memory, such as a non-removable memory 44 or a removable memory 46. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other examples, the processor 32 may access information from and store data in a memory that is not physically located on the M2M device 30, such as on a server or a home computer. The processor 32 may be configured to control a lighting pattern, image, or color on a display or indicator 42 in response to whether an analysis of IoT-enabled data in some examples described herein is successful or failed (e.g., routed to AF or selected AF, etc.), or otherwise indicate the status of the analysis of IoT-enabled data and associated components. The controlled lighting pattern, image, or color on the display or indicator 42 may reflect the diagrams illustrated or discussed herein (e.g., Figure 13-Figure 28 , etc.). Messages and processes that enable analysis of IoT data are disclosed herein. These messages and processes can be extended to provide an interface / API for a user to request information related to the analysis via an input source (e.g., speaker / microphone 38, keypad 40, or display / touchpad 42). In another example, in addition to other content that can be displayed on display 42, there can be a request, configuration, or query for analysis information.

[0154] The processor 32 may receive power from the power source 48 and may be configured to distribute or control power to other components in the M2M device 30. The power source 48 may be any suitable device for powering the M2M device 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.

[0155] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (e.g., longitude and latitude) regarding the current location of M2M device 30. It will be appreciated that M2M device 30 may acquire location information by any suitable location determination method while remaining consistent with the information disclosed herein.

[0156] The processor 32 may also be coupled to other peripherals 52, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripherals 52 may include various sensors, such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, sensors, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, and more.

[0157] The transmit / receive element 36 may be implemented in other devices or equipment, 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 transmit / receive element 36 may be connected to other components, modules, or systems of such a device or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 52).

[0158] Fig.30D is a block diagram of an exemplary computing system 90 on which, for example, Fig. 30A and Fig. 30B The M2M service platform 22 of the present invention. The computing system 90 (e.g., the M2M terminal device 18 or the M2M gateway device 14) may include a computer or a server and may be primarily controlled by computer-readable instructions through any means of storing or accessing these instructions. Such computer-readable instructions may be executed within a central processing unit (CPU) 91 to enable the computing system 90 to work. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor different from the main CPU 91 that performs additional functions or assists the CPU 91. The CPU 91 or the coprocessor 81 may receive, generate, and process data related to the disclosed system and method for enabling analysis of IoT data, such as receiving routing or selection messages related to the analysis.

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

[0160] Memory devices coupled to the system bus 80 include random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuit systems that allow information to be stored and retrieved. ROM 93 generally includes stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses into physical addresses when executing instructions. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0161] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for transmitting instructions from the CPU 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0162] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0163] In addition, the computing system 90 may include a network adapter 97, which may be used to connect the computing system 90 to an external communication network, such as Fig. 30A and Fig. 30B network12.

[0164] It should be understood that any or all of the systems, methods, and processes described herein may be implemented in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium, and when the instructions are executed by a machine (such as a computer, a server, an M2M terminal device, an M2M gateway device, etc.), the systems, methods, and processes described herein are executed or implemented. Specifically, any of the above steps, operations, or functions may be implemented in the form of such computer executable instructions. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, but such computer-readable storage media themselves do not include signals. As can be clearly seen from the description herein, storage media should be interpreted as statutory subject matter. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, tape cassettes, tapes, disk storage devices or other magnetic storage devices, or any other physical medium that can be used to store desired information and can be accessed by a computer. The computer-readable storage medium may have a computer program stored thereon, which may be loadable into a data processing unit and adapted to cause the data processing unit to perform method steps associated with enabling analysis operations of IoT data when the computer program is executed by the data processing unit.

[0165] In describing the preferred methods, systems or apparatus of the subject matter of the present disclosure (enabling analysis of IoT data) as shown in the figures, 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 achieve a similar purpose.

[0166] The various techniques described herein can be implemented in combination with hardware, firmware, software or, where appropriate, a combination thereof. Such hardware, firmware and software can reside in a device located at each node of a communication network. The device can operate alone or in combination with each other to implement the method described herein. As used herein, the terms "device", "network device", "node", "equipment", "network node", etc. can be used interchangeably. In addition, unless otherwise provided herein, the use of the word "or" is generally used inclusively.

[0167] This written description uses examples to disclose the invention, including the best mode, and also enables any person skilled in the art to practice the invention, including making and using any device or system and performing any combined method. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between the exemplary methods disclosed herein). If these other examples have structural elements that are not different from the literal language of the claims, or if they include equivalent structural elements that are not substantially different from the literal language of the claims, then these other examples are intended to be within the scope of the claims.

[0168] A new analysis management service (AMS) is disclosed herein that can coordinate analysis of IoT data from multiple independent sources and organize the results of the analysis. The methods, systems, and devices described herein can enable analysis of IoT data, among other things. A method, system, computer-readable storage medium, or device has a component for obtaining a message including results from an AF; based on the message, the AMS can store the results based on a result location attribute of a first AMS policy; and based on the stored results, there can then be a specific annotation, copy, or link for storage. A method, system, computer-readable storage medium, or device has a component for receiving a request to create an analysis management service (AMS) policy, wherein the AMS policy includes an indication of Internet of Things (IoT) data selection criteria; based on the request, determining a data pattern for the AMS policy when creating the AMS policy; creating the AMS policy based on the data pattern, wherein the AMS policy is checked based on the data pattern; and adding the AMS policy to a registry of AMS policies. The method, system, and device can have a component for discovering existing service layer data that matches the IoT data selection criteria. The IoT data selection criteria can include the identity of the user equipment. The method, system and apparatus may have a component for sending discovered service layer data to the AF based on the data representation information. Based on the data pattern being a periodically scheduled data pattern, an AMS policy may be checked, wherein the check may be based on a schedule provided in the request. Based on the data pattern being a continuous data pattern, an AMS policy may be checked each time new IoT service layer data is created. Existing service layer data matching the identity of the user equipment may be discovered. The discovered SL data may be used for further processing (e.g., Figure 17-Figure 19 Steps). The AMS policy may include indications of analysis function configuration, etc. (e.g., Tables 1-6). It is contemplated that other information of Table 1 (alone or in combination) may be used in addition to or in place of the data pattern to determine how or whether to update or create an AMS policy or add an AMS policy to a specific group of other AMS policies that may facilitate more efficient processing. A method, system, computer-readable storage medium, or apparatus has a component for receiving a request to create an analysis management service (AMS) policy, wherein the AMS policy includes IoT data selection criteria (which may define how to select an appropriate data source), analysis function configuration (which may define which AFs are to be used and which data are to be sent to these AFs), or result storage (which may define how or where to store analysis results); based on the request, creating an AMS policy; and adding the created AMS policy to a registry of AMS policies. A method, system, computer-readable storage medium, or apparatus has a component for receiving new data; based on the received new data, checking which AMS policy is applied; and based on the applied AMS policy, sending the data to the appropriate AF for analysis and storing the analysis results according to the instructions in the applied AMS policy. A method, system, computer-readable storage medium, or device has components for receiving data (e.g., by a device); in response to receiving the data, determining which AMS policies to apply; determining that a first AMS policy of the AMS policies should be applied to process the data; based on the first AMS policy, sending the data to an analysis function (e.g., for analysis processing), wherein the analysis function generates analysis results; and storing the analysis results according to the first AMS policy. All combinations of this paragraph (including removal or addition of steps) are contemplated in a manner consistent with other portions of the detailed description.< / linkresource> < / subscription> < / flexcontainer> < / timeseriescontainer> < / container> < / linkresource> < / linkresource> < / linkresource> < / linkresource> < / container> < / contentinstance> < / linkresource> < / amspolicy> < / amspolicy> < / amspolicy> < / amspolicy> < / af> < / af> < / af> < / unidentified> < / root> < / id> < / identified> < / root> < / subscription>

Claims

1. A device for operating a public analysis management service AMS in an Internet of Things (IoT) service layer (SL), wherein the IoTSL provides service capabilities as a middleware between application protocols and applications through a set of application programming interfaces, the device comprising: processor; as well as A memory coupled to the processor, the memory comprising executable instructions, the executable instructions, when executed by the processor, causing the processor to perform operations including: receiving a request to create an AMS policy for analyzing IoT SL data, wherein the AMS policy specifies selective analysis to be performed on the IoT SL data by configuring one or more analysis functions AF of an AMS in the IoTSL to analyze the IoT SL data, the AMS being configured with a plurality of AFs to analyze IoT SL data from a plurality of sources, and wherein the AMS policy defines how analysis results received from the one or more AFs are stored in the IoTSL and how the analysis results in the IoTSL are accessed, and wherein the AMS provides authorization based on the analysis results to allow an IoT SL entity that does not have access to an original location of the IoT SL data to access a selected portion of the IoT SL data in the IoTSL; Based on the received request, create the AMS policy; configuring the one or more AFs according to the AMS policy; as well as The analysis is performed based on the configured one or more AFs.

2. The apparatus of claim 1, wherein the AMS policy comprises an analysis function configuration for the one or more AFs.

3. The apparatus of claim 1, wherein the AMS policy includes instructions on how to store IoT SL data received from the one or more AFs.

4. The apparatus of claim 1, wherein the AMS policy comprises IoT data selection criteria including an identity of the user equipment.

5. The apparatus of claim 1, wherein the operations further comprise: determining a data pattern for the AMS policy when creating the AMS policy, wherein the data pattern is for a continuous data pattern; as well as Based on the data mode being a continuous data mode, the AMS policy is checked each time IoTSL data is created.

6. The apparatus of claim 1, wherein the operations further comprise: determining a data pattern for the AMS policy when creating the AMS policy, wherein the data pattern is used for periodically scheduling the data pattern; as well as Based on the data pattern being a periodically scheduled data pattern, checking an AMS policy based on a schedule provided in the request.

7. The apparatus of claim 1, wherein the operations further comprise: Discover existing IoT SL data that matches IoT data selection criteria; as well as Based on the data representation information, the discovered IoT SL data is sent to an AF among the one or more AFs.

8. The apparatus of claim 1, wherein the operations further comprise: Receive IoT SL data; In response to receiving the IoT SL data, determining which AMS policies to apply; Determining that the AMS policy is applied to process the IoT SL data; Based on determining that the AMS policy applies, sending the IoT SL data to an analysis function for analysis, wherein the analysis function generates an analysis result; as well as The analysis results are stored according to the AMS policy.

9. A computer-implemented method comprising: receiving a request for creating an analysis management service AMS policy for analyzing IoT service layer SL data, the IoT SL providing service capabilities as middleware between application protocols and applications through a set of application programming interfaces, wherein the AMS policy specifies selective analysis to be performed on the IoT SL data by configuring one or more analysis functions AF of the AMS in the IoT SL to analyze the IoT SL data, the AMS being configured with a plurality of AFs to analyze IoT SL data from a plurality of sources, and wherein the AMS policy defines how analysis results received from the one or more AFs are stored in the IoT SL and how the analysis results in the IoT SL are accessed, and wherein the AMS provides authorization based on the analysis results, allowing an IoT SL entity that does not have access to the original location of the IoT SL data to access a selected portion of the IoT SL data in the IoT SL; Based on the received request, create the AMS policy; configuring the one or more AFs according to the AMS policy; as well as The analysis is performed based on the configured one or more AFs.

10. The method of claim 9, wherein the AMS policy includes an indication of the configuration of the one or more AFs.

11. The method of claim 9, wherein the AMS policy includes how to store IoT SL data received from the one or more AFs.

12. The method of claim 9, wherein the AMS policy includes IoT data selection criteria including an identity of the user equipment.

13. The method of claim 9, further comprising: determining a data pattern for the AMS policy when creating the AMS policy, wherein the data pattern is for a continuous data pattern; as well as Based on the data mode being a continuous data mode, the AMS policy is checked each time IoT SL data is created.

14. The method of claim 9, further comprising: Discover existing IoT SL data that matches IoT data selection criteria; as well as Based on the data representation information, the discovered IoT SL data is sent to an AF among the one or more AFs.

15. A computer readable storage medium having stored thereon a computer program, said computer program being loadable into a data processing unit and being adapted to cause said data processing unit to perform the method steps of any one of claims 9 to 14 when said computer program is run by said data processing unit.

Images