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: Described herein are complete lifecycle management processes for IoT/M2M devices. In an example, devices are commissioned and de-commissioned in a given system without requiring a user/human administrator. A delegated life-cycle management process is described, wherein devices rely upon a delegatee, which may have more computing and battery resources than the devices, to perform complete or partial lifecycle management operations on behalf of the devices. The delegatee may be a trusted entity that may belong to the same domain as the devices. Further, a Trust Enabling Infrastructure (TEI) is described herein, which may belong to a different trusted domain than the given device and its delegatee.

Abstract: Methods, devices, and systems are disclosed for an M2M Interest Function. An M2M Interest Function may receive requests from users to publish the users' personal interests in particular data identify relationships and patterns in the data. Associated data may then be stored in a single best location for such data based on various criteria rather than on separate M2M Gateways or M2M Servers. This location may be provided to users interested in such data. Relationship and association data may be provided to M2M gateways.

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: 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: 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: 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: Some underlying networks such as Low-Power Wide-Area Networks (LPWAN) have limited communication bandwidth and strict requirements on maximum message size. 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. In some cases, the RRCP is not transmitted between SL entities, thereby reducing SL message sizes to cater to the constraints of underlying networks.

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: 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: Described herein are complete lifecycle management processes for IoT/M2M devices, which are commissioned and de-commissioned in a given system without requiring a user/human administrator. A delegated life-cycle management process is described, wherein devices rely upon a delegatee, which may have more computing and battery resources than the devices. Further, a Trust Enabling Infrastructure (TEI) is described herein, which may belong to a different trusted domain than the given device and its delegatee. A device in response to powering on for the first time, registers with a trust enabling infrastructure (TEI) and generates one or more credentials based on the registration with the TEI so as to define a trust relationship with the TEI. After the registration, the device receives one or more security components and policies from the TEI and installs the one or more security components so as to define a secure environment.

Abstract: An Authorization Verification Service (AVS) is disclosed that may be provided by an IoT/M2M service layer to registrants of the service layer for Dynamic Context Aware Authorization. The AVS may allow the IoT/M2M service layer entities to define dynamic limits for authorizing access to services or data. The limits may be set, for example, in terms of the number of allowed accesses. When an IoT/M2M registrant makes a request for data or services for which it has dynamic context aware authorization, the AVS may maintain records of the remaining accesses available.

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: 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: Methods, devices, and systems are disclosed for an M2M Interest Function. An M2M Interest Function may receive requests from users to publish the users' personal interests in particular data identify relationships and patterns in the data. Associated data may then be stored in a single best location for such data based on various criteria rather than on separate M2M Gateways or M2M Servers. This location may be provided to users interested in such data. Relationship and association data may be provided to M2M gateways.