Abstract: A caching entity may store a cached copy of a service layer resource. An original hosting entity may maintain a registry of the corresponding cached resources. Optionally, the original hosting entity may set cache parameters to govern the lifetime of the cache on a caching entity. The caching entity may keep storing the cached copy of the resource and the original hosting entity may obtain statistics about the cached resource. By knowing the statistics, e.g. how many times a resource is retrieved on each caching entity, the original hosting entity may better manage the resource.

Abstract: Internet of Things (IoT) configurable event and action sequencing mechanisms for interconnecting various IoT events together to achieve an event and action sequencing process that may efficiently enable complex uses of the data available in IoT systems.

Abstract: The concept of a service layer message template is introduced, which may be a request template or a response template. Message templates may be created and stored at the service layer. Each message template may contain a set of request or response parameters and their values. Once in place, an application can send a request to the service layer that does not include the request parameters contained in the message template (i.e. request template); instead, a message template identifier may be sent. Since request parameters are included in the message template and stored at the service layer, communication overhead between the service layer and the application (or another service layer) may be reduced.

Abstract: Methods, systems, and devices may be used to support freshness-based processing of requests. Freshness-based processing may involve the service layer examining the age of stored content (e.g., resource representation) that it hosts and determining whether it is fresh enough to satisfy a retrieve or discovery request with a specified freshness requirement. If not fresh, the service layer can contact an application to refresh the content. In addition, freshness-based processing can also involve the service layer examining the semantic state of a command oriented update request to determine whether its state is fresh or not with respect to prior commands processed by the service layer. For example, the service layer may compare stored content associated with controlling a particular application (e.g. door is locked) and against the semantic content of an update request (e.g., unlock door) to determine whether it is the same (e.g., stale) or not (e.g., fresh).

Abstract: A lightweight and extensible information model for machine-to-machine systems is disclosed. A service layer information management architecture uses three categories of atomic objects, subjects, actions, and descriptions. Information for use within the model is built using the atomic information objects. Application programming interfaces are used to perform operations and information processing by different nodes. Common service functions are used in the model as instances of a generic common service information model.

Abstract: It is recognized herein that current approaches to traffic steering in M2M systems lack capabilities, particularly with respect to traversing value added services in an operator's network. As described herein, nodes or apparatuses at a machine-to-machine (M2M) service layer can leverage value added services that are deployed in an operator's network. The M2M service layer may add metadata to downlink traffic so that the metadata can be used to assist with steering and processing data in the operator's value added services (VASs) network. By of example, the M2M service layer can use a control plane interface to push polices into a network operator's VASs network, and to allow functions in the VASs network to extract information from the M2M service layer.

Abstract: Internet of Things (IoT) event objects can be tailored to specific device types and capabilities. An IoT event object can use a flexible definition of an event that can be reconfigured. An IoT event object allows for the ability to set different triggering conditions and priorities. Individual event definitions can be extended to create more complex events. A Notification Handler supports sending a request or command in response to an event that requires action.

Abstract: A labeled data generation service provides an Internet-of-Things (IoT) system with a capability whereby users may configure how the system gathers, processes, and generates labeled data instances by: collecting and processing the data into a format required by supervised learning algorithms; generating expected outputs from data available in the IoT system; supporting the linking of collected inputs with generated expected outputs; forming labeled data instances; cleaning the labeled data set appropriately; sending the labeled data set to target nodes; and/or communicating with target nodes regarding improving the data processing and labeling processes, as required.

Abstract: Methods and apparatus are described for configuring desired network capabilities in a service-based network, including a method for a UE to initiate a network capability based registration to configure its desired network capabilities, a method for UEs to initiate a network capability based registration update when UEs are already registered to the network and want to dynamically re-configure their network capabilities, and a method for a network capability based UE configuration update, which allows NFs or ASs to initiate updating the network capabilities in a network slice for the UE.

Abstract: An apparatus can monitor interactions between IoT devices and IoT applications. Based on the monitoring, the apparatus may identify an interaction between a given IoT device and a given IoT application that can be adjusted. In an example, the apparatus may generate a recommendation or instruction in response to identifying the interaction. A first instruction may indicate a change in behavior for one of the IoT device or the IoT application. The apparatus may send the instruction to the one of the IoT device or the IoT application, for example, so as to cause the one of the IoT device or the IoT application to change the respective behavior, thereby adjusting the interaction between the IoT device and the IoT application.

Abstract: IoT service layer capabilities may be employed to automate and simplify the service enrollment process for IoT service subscribers/enrollees. These capabilities enable virtualization of a service subscriber and the physical IoT devices, applications, data and authorized users of the subscriber into a software profile that is representative of the subscriber. Once virtualized, a service subscriber may then delegate the complexities and burden of service enrollment to an automated IoT service enrollment software function.

Abstract: Some underlying networks such as Low-Power Wide-Area Networks (LPWAN) have limited communication bandwidth and strict requirements on maximum message size. It is recognized herein that these requirements may pose a challenge for data or resource exchange between two service layer (SL) entities, for example, because resource representations to be exchanged may have too large a size to be supported by the underlying networks. In some cases, traditional data compression algorithms can be used to alleviate this problem to some degree, but it is recognized herein that there are associated computation costs due to compression and decompression that may not be affordable for constrained IoT devices. Various embodiments described herein address this problem, among others, by defining a Resource Representation Common Part (RRCP) and storing it at the service layer.

Abstract: An M2M Service Layer is expanded to access the services of third parties and exchange data with these third parties. The M2M Service Layer is then able to act as a proxy between M2M Devices and the third party services. The M2M Service Layer is able to present a single/consistent interface, or API, to the M2M Device and hide the details of the third party service provider from the M2M Device.

Abstract: It is recognized herein that current approaches to traffic steering in M2M systems lack capabilities, particularly with respect to traversing value added services in an operator's network. As described herein, nodes or apparatuses at a machine-to-machine (M2M) service layer can leverage value added services that are deployed in an operator's network. The M2M service layer may add metadata to downlink traffic so that the metadata can be used to assist with steering and processing data in the operator's value added services (VASs) network. By of example, the M2M service layer can use a control plane interface to push polices into a network operator's VASs network, and to allow functions in the VASs network to extract information from the M2M service layer.

Abstract: A method of accessing services affiliated with a service provider is disclosed. An issuer performs a bootstrap procedure with the at least one discovered service provider. The issuer performs a discovery procedure to determine available service capability layers (SCLs) supported by the at least one discovered service provider. The issuer transmits a domain name system-based service discovery (DNS-SD) query from the issuer to a DNS-SD M2M service discovery function (MSDF) server. The DNS-SD MSDF server is provisioned with SCL discovery records. The DNS-SD MSDF server is registered with a public DNS registrar entity. The SCL discovery records include, for each SCL, a type of M2M service capabilities supported by each SCL and a class of M2M services supported by each SCL. The issuer receives SCL discovery records from the DNS-SD MSDF server in response to the DNS-SD query.

Abstract: Lightweight, dynamic mechanisms are provided to support service layer interworking and resource extensibility. For example, one mechanism disclosed herein comprises defining a new service layer (SL) resource definition registration procedure that allows for specifying custom attributes of service layer resources to represent third party technology resources. A second mechanism disclosed herein comprises defining a new SL data model mapping registration procedure to map service layer resources to third party data models and to provide a new interworked retargeting indicator to the service layer. Further, a third mechanism disclosed herein comprises defining a SL generic interworking procedure to intelligently retarget requests toward interworked resources based on the interworked retargeting indicator provided by the data model mapping.

Abstract: A Message Flow Management (MFM) service of a service layer (SL) of a communications network enables dynamic control of the rate of particular SL messages that are destined to a target entity, such as an IoT device or application, based on its SL status or other context information.

Abstract: Disclosed are methods and systems for Semantics Node functions which provide semantics support in machine-to-machine systems. In an example, a Semantic node may manage semantics resources capable of being discovered, retrieved, or validated by other devices. In another example, the Semantics Node may be discovered by other nodes, and semantics resources may be discovered with subscription mechanisms.

Abstract: Existing approaches to security within network, for instance oneM2M networks, are limited. For example, content might only be protected while the content is in transit between entities that trust each other. Here, the integrity and the confidentiality of content in an M2M network are protected. Such content may be “at rest,” such that the content is stored at a hosting node. Only authorized entities may store and retrieve the data that is stored at the hosting node, and the data may be protected from a confidentiality perspective and an integrity perspective.

Abstract: Methods, systems, and devices may be used to support freshness-based processing of requests. Freshness-based processing may involve the service layer examining the age of stored content (e.g., resource representation) that it hosts and determining whether it is fresh enough to satisfy a retrieve or discovery request with a specified freshness requirement. If not fresh, the service layer can contact an application to refresh the content. In addition, freshness-based processing can also involve the service layer examining the semantic state of a command oriented update request to determine whether its state is fresh or not with respect to prior commands processed by the service layer. For example, the service layer may compare stored content associated with controlling a particular application (e.g. door is locked) and against the semantic content of an update request (e.g., unlock door) to determine whether it is the same (e.g., stale) or not (e.g., fresh).