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: Existing approaches to security within network, for instance one M2M 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: A node availability estimation service can be used at a service layer of an M2M/IoT network. Value-added services can leverage this node availability information to improve the operation intelligence, quality of service, communication overhead as well as energy efficiency for M2M/IoT systems. A Real-time Data Collection (DC) component can collect real-time data from input sources at service layer (e.g., other existing CSFs). A Data Processing for Estimating Node Availability component (DP) can execute data processing for estimating node availability based on the data collected by DC. A Node Availability Service Provisioning component (SP) can store the estimated node availability results from DP and expose them to service clients in terms of “node availability estimation services”.

Abstract: Existing resource reservation techniques are inefficient for M2M communications. In an example embodiment described herein, a system comprises a service layer server that resides on a service layer and a control plane node that resides on an access network, wherein the service layer server communicates with the control plane node via a control plane interface. The control plane interface can be used to configure quality of service (QoS) policies (rules) that are based on an object that is being addressed. In this context, for example, an object may be a memory location or value. For example, the service layer may configure one or more QoS rules for the access network based on the object by sending a QoS provisioning message that includes one or more parameters to the control plane node. The control plane node may determine the object that is identified in the one or more QoS rules, and the QoS rules may be distributed to one or more routers that may be used to access the object.

Abstract: Described herein is a Network and Application Management Service (NAMS), which is a new service for the service layer (SL). In accordance with an example embodiment, the NAMS collects, consolidates, and processes information from applications, underlying networks, and other services.

Abstract: A variety of mechanisms to perform End-to-End authentication between entities having diverse capabilities (E.g. processing, memory, etc.) and with no prior security associations are used. Security provisioning and configuration process is done such that appropriate security credentials, functions, scope and parameters may be provisioned to an Entity. Mechanisms to distribute the security credentials to other entities which could then use the credentials to perform an End-to-End authentication at the Service Layer or the Session Layer and using Direct or Delegated modes are developed.

Abstract: Mechanisms support machine-to-machine service layer sessions that can span multiple service layer hops where a machine-to-machine service layer hop is a direct machine-to-machine service layer communication session between two machine-to-machine service layer instances or between a machine-to-machine service layer instance and a machine-to-machine application. Mechanisms are also disclosed that illustrate machine-to-machine session establishment procedures for oneM2M Session Management Service supporting multiple resources.

Abstract: The present application is directed to a method for registering with a service layer. The method includes the step of forming a registration group of one or more applications. The method also includes a step of receiving a request to join the registration group, from the one or more applications based upon a review of criteria. The method also includes a step of receiving a registration preference from the one or more applications. Further, the method includes the step of performing service discovery on a network based upon the registration preference of the one or more applications in the registration group. The present application is also directed to a device for registering with a service layer. The present application is further directed to a computer-implemented method for moving from a current service layer to a new service layer.

Abstract: Disclosed herein are a variety of devices, methods, and systems for providing virtualization for IoT systems so that IoT physical resources can be flexibly and efficiently shared. Virtualization requests may be processed based on a context-aware approach and various means are disclosed for determined whether and how to virtualize a resource.

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: An evolved resource directory may provide filtered and prioritized search results to a client's search query for resources. For example, in a network comprising servers and a resource directory, the resource directory registers a plurality of URIs received from the servers. The resource directory may determine an initial ranking of the plurality of URIs based on measuring cross-links between each of the plurality of URIs and identifying contexts of the plurality of URIs. The initial ranking is stored in a ranked database. In response to a client's search query, the resource directory may determine a real-time ranking for the plurality of URIs stored in the ranked database. The real-time ranking may be determined based on checking a sleep status for each of the servers and/or by partially balancing traffic loads of the servers. The resource directory, based on the real-time ranking and/or the initial ranking, may then generate a ranked list of the filtered and prioritized URIs.

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: The present application is directed to a computer-implemented apparatus for negotiating service layer attributes. The apparatus includes a non-transitory memory including instructions stored thereon for a negotiation service layer for negotiating a service attributes. The apparatus also includes a processor, operably coupled to the non-transitory memory. The processor is configured to perform the instruction of reviewing a negotiable service layer attribute received from a negotiatee. The processor is also configured to perform the instruction of sending a negotiation request to the negotiatee based upon the reviewed attribute. The processor is also configured to perform the instruction of receiving an offered suggestion from the negotiatee. Another aspect of the application is directed to a networked system including a computer-implemented negotiatee and a computer-implemented negotiator for negotiating service layer attributes.

Abstract: Various mechanisms are disclosed for a service domain charging system that can interact with underlying networks. A service domain charging architecture is defined with several logical functions. Service-based charging types may be and applied to existing event, session, online, and offline charging mechanisms. Service domain charging messages may be exchanged over the X, Y, Z reference points. An E reference point may be used for interfacing with a service domain billing system, and a B reference point may be used between a service domain billing system and underlying network's billing system.

Abstract: An method for M2M communications and an M2M node are disclosed. The M2M node provides a communication management function for communication between a first service layer in a first network and a second service layer in a second network. The M2M node receives a first message from a first application in the first service layer. The first message encapsulates a second message. The M2M node determines based on at least a first attribute identifying an expiration time after which the communication management function does not facilitate communication, that the communication management function is available to process the first message. The M2M node determines based on at least a second attribute defining an access control list identifying applications in the first service layer for which the communication management function may provide processing, that the communication management function is available to process the first message from the first application.

Abstract: Mechanisms support machine-to-machine service layer sessions that can span multiple service layer hops where a machine-to-machine service layer hop is a direct machine-to-machine service layer communication session between two machine-to-machine service layer instances or between a machine-to-machine service layer instance and a machine-to-machine application. Mechanisms are also disclosed that illustrate machine-to-machine session establishment procedures for oneM2M Session Management Service supporting multiple resources.

Abstract: Methods and systems providing application layer support for one or more sleeping nodes in constrained networks are contemplated. Embodiments contemplate inserting sleep information in a header option or payload of an application layer message. The application layer message may be conveyed in a hypertext transfer protocol (HTTP) or a constrained application protocol (CoAP). Embodiments contemplate communicating the application layer message to a server, which may serve as a caching and/or buffering proxy.

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: Various mechanisms are disclosed for a service domain charging system that can interact with underlying networks. A service domain charging architecture is defined with several logical functions. Service-based charging types may be and applied to existing event, session, online, and offline charging mechanisms. Service domain charging messages may be exchanged over the X, Y, Z reference points. An E reference point may be used for interfacing with a service domain billing system, and a B reference point may be used between a service domain billing system and underlying network's billing system.