Abstract: Some services offered by M2M service layers will have contact information that will be used in order to interact with applications. For example, a service layer may need to send notification messages to an application. To do this, the service layer relies on stored contact information to know how to reach the application. If the device hosting the application moves and the application changes its contact information, then the contact information that is in the service layer is stale. As a result, these services will be inefficient, or in some cases, fail altogether. Embodiments described herein provide systems and methods to enable mechanisms to update stale contact information in M2M service layers.

Abstract: A batch of CRUD operations can be coupled with the resource discovery operation and directly conducted on the matched resources, without initiating new CRUD requests. New functionality at the Originator and Receiver can differentiate the resources for which criteria matching is applied from the resources included in the discovery/filtering results. Enhanced functionality at the Originator and Receiver can combine discovery with RESTful operations targeting a resource set different than but related the discovered resources. Other enhancements may be used to request discovery of resources in a specified relationship to those matching a filter, or to request group formation based on the result.

Abstract: Methods and procedures allow devices interwork with various types of service layers by updating the device to support the protocol of the M2M/IoT service layer that is being communicated with. Devices can coordinate/initiate download of a service layer API that is compatible with the service layer the device is attempting to use. A service layer can coordinate the autonomous update of a device with the proper service layer API which allows the device to then communicate and use services supported by the service layer component to the device. A service layer can detect a device or application lacking proper service layer functionality and can trigger a management entity to update the device or application with the service layer API required such that the device can then register to the service layer and use its services. A device or application can be customized or optimized to the service layer that it is registered to and using.

Abstract: An IoT E2E Service Layer Security Management system supports methods and 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 and procedures described herein 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. The methods and procedures described herein reduce overhead, simplify and obviate the need for E2E service level nodes (initiation and 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.

Abstract: Two methods are described to enable the communication between two service layer entities that do not have registration relations. In the first method, service layer entities employ a retargeting table that stores the service layer entity to retarget the message in order to deliver the message to the destination. In a second method, an infrastructure node in a service provider employs a retargeting chain table that stores a chain of entities that can retarget the message to the destination.

Abstract: Mechanisms for service layer charging correlation are disclosed. Embodiments can include a Service Domain Charging Correlation Function (SD-CCF), which is responsible for interacting with underlying network and correlating charging information at service layer. Charging correlation information can be used to enable and facilitate the service layer charging correlation.

Abstract: A service layer may be configured to offload requests and responses on behalf of IoT applications in order to reduce congestion and/or overhead on underlying networks, applications and devices. The service layer may be enabled with the capability to script and generate IoT application requests such that the requests can be initiated by the service layer without the IoT application having to re-issue the same request repeatedly (e.g., to periodically retrieve a sensor reading). This scripting may be initiated by request originators. The service layer may support the capability to monitor and detect repetitive request patterns and initiate the scripting itself. This scripting functionality may enable the service layer to perform operations on behalf of IoT applications. As a result, the messaging overhead on IoT applications and devices as well as underlying networks can be minimized.

Abstract: A registration procedure may allow one active and multiple inactive SL registrations to be created at different service layer entities for an application entity without adding significant overhead and burden to an application entity.

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: 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: 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 and systems may be used to synchronize time across multiple IoT related entities, such as a network of resource constrained sensor and actuator type devices, IoT gateways, IoT cloud services, or IoT applications.

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. A service layer may be an M2M/IoT Service Layer, and compatibility may refer to compatibility regarding different versions or releases of the oneM2M Service Layer.

Abstract: Distributed Service Layer Transactions (DSLTs) may be supported by a DSLT service at a service layer of a communications network to offload applications from the burden of managing the processing of DSLTs.

Abstract: In a machine-to-machine/Internet-of-things environment, end-to-end authentication of devices separated by multiple hops is achieved via direct or delegated/intermediated negotiations using pre-provisioned hop-by-hop credentials, uniquely generated hop-by-hop credentials, and-or public key certificates, whereby remote resources and services may be discovered via single-hop communications, and then secure communications with the remote resources may be established using secure protocols appropriate to the resources and services and capabilities of end devices, and communication thereafter conducted directly without the overhead or risks engendered hop-by-hop translation.

Abstract: Mechanisms for discovering ad hoc Service Layer Entities (aSLEs) either deployed in ad hoc or switched from normal operation mode to ad hoc mode can support an IoT service in a distributive self-organized system.

Abstract: Service Layer adaptation may be realized through one or more adaptation rules that are programmed by server administrators in a structured but flexible manner. As part of integrating the adaptive control into its operations, a Service Layer may be configured to provide the capability to receive requests in which an adaptation rule may be specified, to provide indications through response codes returned to requestors that the Service Layer is not able to process a request due to a reduced functional state, and to send a request for more server resources or move an application, a service, or a service instance to another platform.

Abstract: Methods and systems may be used to synchronize time across multiple IoT related entities, such as a network of resource constrained sensor and actuator type devices, IoT gateways, IoT cloud services, or IoT applications.

Abstract: Enhancements to the device management functionality within service layer architecture of a Gateway node are described. The SL application registration procedure can be enhanced for devices in support of device management. Functionality can be added to the service layer to initiate automated request notification for DM purposes. Lightweight SL Transport Protocol bindings can support sending multiple DM commands called DM Action Scripts with a specific focus on the Constrained Application Protocol (CoAP) Protocol.

Abstract: An M2M entity may retrieve data such that the representation of the data may consistently be returned in a form that can be dynamically specified in order to reduce complexity and overhead required by a requestor or consumer of the data. The semantic descriptions of the data that exist in the service layer may be used in order to provide desired results to the requestor or consumer of the data.