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.

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: 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 research discovery rights of resources in a specified relationship to those matching a filter, or to request group formation based on the result.

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: Methods are proposed to integrate MQTT Server functionality into the oneM2M CSE, as well as to interconnect such CSE-based MQTT Servers into a network organized around a topic structure based on resource address. Methods can dynamically allocate, assign and deliver an identifier that can be used as the AE-ID by the AE, CSE and MQTT Server. The MQTT Server can be internetworked into the M2M Service Layer such that an MQTT Server is available in every Service Layer node that hosts a CSE.

Abstract: Service layer multicast communications management may be achieved via indication by entities of multicast capabilities during service layer registration and self-subscription by the entities to the service layer. The service layer, or a managing application in communication with the service layer, may then maintain resources for multicast configurations, dynamically create multicast groups, and notify members via their self-subscription of the entities in the groups. The service layer may then further fan-out multicast messages, thereby allowing the originator of the multicast message to access recipients in multiple underlying networks without the need to configure communications directly. Fan-out may include unicasts to entities lacking multicast capabilities. Self-subscription may also be used, for example, in granting access control to a third party application.

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: 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 method and apparatus for distributed services and data in a machine-to-machine (M2M) communication network are disclosed. A network server, an M2M gateway, and M2M devices include an M2M service capability layer for supporting M2M service capabilities, respectively. Reference points may be defined for interactions between network service capability layers, between gateway service capability layers, between a gateway service capability layer and a device service capability layer of an M2M device, between M2M device applications, and/or between a network, gateway, or device service capability layer and an M2M application. The network server may be split into a control server and a data server at a service capability layer to provide service capabilities for control functions and service capabilities for data functions, respectively. The data server may be configured to interact with another data server to push or pull data or resources either directly or indirectly via the control server.

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: The application is at least directed to a charging system for a service domain residing on a network node. The charging system includes a service domain charging management function on the node storing charging policies for the service domain. The charging system also includes a service domain on-line charging system on the node receiving a service request from the service domain charging management function. The charging system also checks the credit for the requested service before granting the service. The charging system also includes a service domain off-line charging system on the node receiving charging events from the service domain charging management function and producing service domain charging data records. The application also is directed to a method for granting service to a requestor.

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: Access control for RESTful operations may be provided to a centralized semantic graph store. In addition, operations may be provided over semantic triples distributed in a resource tree database. In an example, an system may use semantic descriptors distributed in hierarchical resource trees mechanisms for maintaining semantic descriptors relationship information. The mechanisms enable semantic queries to be performed within the context of specific graphs by using specific sets of sematic descriptors together. The mechanism which uses the formation of a group for semantic operation purposes also enables the use of the group resource in order to fan out semantic requests to members of the group, including members located on different service entities.

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: 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: 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: Presented herein is a messaging system architecture that is referred to as an “Open Message Bus” (OMB). The OMB is a messaging system infrastructure that facilitates connectivity and communication between services. The OMB backbone may offer infrastructure services that can be leveraged by all services that connect to the OMB.

Abstract: Methods, systems, and devices may be used to annotate and store “semantics of normal resources” (hereinafter resource semantics). These methods, systems, and devices may be a part of a functional architecture for semantics support and allow for semantics based query. Also methods, systems, and devices associated with a semantics child resource may be created within a resource in order to represent semantics 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.