Abstract: Methods, system, and apparatuses may support end-to-end (E2E) quality of service (QoS) through the use of service layer (SL) sessions. For example, an application can communicate with a targeted device based on application specified schedule, latency, jitter, error rate, throughput, level of security, and cost requirements.

Abstract: A Data Producer may be configured to negotiate and initiate a Data Continuity service with an M2M/IoT system. This service may be for specific data sets or all data sets generated by the Data Producer. The M2M/IoT system may be configured to autonomously decide to start a Data Continuity Service for a data set of a Data Producer. The Data Producer may interact directly with an Aggregator SL to store its aggregated data set, and may also be configured to update and delete entries in this data set and start a data service on this aggregated data set. A Local SL may be configured to manage all interactions with an Aggregator SL, and the Local SL may be configured to retarget requests from the Data Producer to the Aggregator SL, including a request to start a data service on the aggregated data set.

Abstract: An IoT/M2M service layer may be provided with the capability to protect user privacy. This functionality may allow the IoT/M2M service layer to anonymize user data, particularly when user data is shared with third party consumers. A privacy policy service may enable the IoT service layer system to generate anonymization (e.g., privacy) policies based on inputs such as legal obligations, subscriber privacy preferences, and an authorization level of the data consumer. Data anonymization policies may be output from the privacy policy service and may be sent to a data anonymization service, where raw data may be anonymized based on the one or more data anonymization policies. The output from the data anonymization service function may be a privatized (e.g., anonymized) version of data that may prevent the data consumer from discovering one or more identifying characteristics of a user.

Abstract: The present application describes a method and apparatus for managing a service in a service layer. In particular, a method describes a computer readable storage medium including instructions for managing a service in a service layer where the instructions are executed by a processor. The executed instructions cause the processor to receive a request to manage, via a service enabler function of the service layer, a change of state of the service including adding, removing, activating, or deactivating the service. The request may include a service description. The executed instructions also cause the processor to evaluate, via the service enabler function, the service description comprising identifiers of one or more services to manage. The executed instructions further cause the processor to identify one or more service capabilities in the service layer to assist in managing the one or more services identified in the service description.

Abstract: Profile based services and content can assist with the backward and forward compatibility of conventional service layers or the like. Using a profile to manage content and access to services offered may reduce the overhead or processing associated with providing those value added services by service layers.

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, devices, and systems for migration or sharing of existing M2M service layer sessions are disclosed. In one embodiment, a Session Migration and Sharing Function (SMSF) performs the migration or sharing of a M2M service layer session. Various forms of service layer session context may be used to enable the migration and sharing of M2M service layer sessions.

Abstract: Methods, systems, and apparatuses 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. An analytics management service may allow SL entities to configure analytics functions for many different IoT sources of data and organize the results in a customizable manner. The SL may support coordinating the analysis of IoT data from multiple independent sources and organizing the results of the analysis.

Abstract: Methods, system, and apparatuses may support end-to-end (E2E) quality of service (QoS) through the use of service layer (SL) sessions. For example, an application can communicate with a targeted device based on application specified schedule, latency, jitter, error rate, throughput, level of security, and cost requirements.

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: 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: An IoT E2E Service Layer Security Management system supports methods/procedures to allow an application to establish, use, and teardown an IoT SL communication session that has application specified E2E security preferences and that targets one or more SL addressable targets (e.g. an IoT application, device, or gateway SL addressable resource). E2E SL Session based methods/procedures achieve a required overall E2E security level, by allowing IoT SL instances to influence and coordinate hop security for a multi-hop communication path spanning across multiple intermediary nodes. Methods/procedures reduce overhead, simplify and obviate the need for E2E service level nodes (initiation/termination nodes) from having to perform security service negotiation, in order to establish secure hop-by-hop security associations aligned with an E2E security requirement.