Abstract: A system is disclosed for orchestrating services. Service orchestration profiles specify attributes defining desired services. The service orchestration profiles may be distributed amongst nodes and hierarchically related to each other. Service orchestration management functions process the information in the service orchestration profiles in order to determine the desired services and use the information to implement the desired services. The service orchestration management functions may be hierarchically related to each other.

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: 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: Current discovery mechanisms lack capabilities, such as capabilities related to permissions associated with a given registrant for example. In an example embodiment, a registrant of a service layer can communicate with a network node that hosts the service layer. The network node may receive a discovery request for a resource from the registrant. The discovery may request include various context. For example, the context of the discovery request may be indicative of an operation that the registrant intends to perform on the resource, a role that the registrant intends to assume if the registrant accesses the resource, a location in which the registrant intends to access the resource, or a subscription plan that the registrant intends to use if the registrant accesses the resource. Based on the context of the discovery request, the network node may determine whether one or more resources at the service layer satisfy the discovery request.

Abstract: A registrar entity, such as a service layer gateway, obtains the service capabilities requirements or preferences of a new registree entity, such as an application, and only accepts a registration of the registree if the registrar has sufficient remaining service capacities to meet the service capabilities requirements or preferences of the registree entity while ensuring that the provision of support to existing registree entities is not impacted. If the registrar lacks the capabilities to satisfy the requirements or preferences, it may contact a server to identify another registrar which has the capabilities. Updates to requirements or preference may originate at any node, e.g., at a user equipment device or a service.

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: 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: Current discovery mechanisms lack capabilities, such as capabilities related to permissions associated with a given registrant for example. In an example embodiment, a registrant of a service layer can communicate with a network node that hosts the service layer. The network node may receive a discovery request for a resource from the registrant. The discovery may request include various context. For example, the context of the discovery request may be indicative of an operation that the registrant intends to perform on the resource, a role that the registrant intends to assume if the registrant accesses the resource, a location in which the registrant intends to access the resource, or a subscription plan that the registrant intends to use if the registrant accesses the resource. Based on the context of the discovery request, the network node may determine whether one or more resources at the service layer satisfy the discovery request.

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: Resources on a host may be typically organized in a tree structure. In existing service layer technologies, the originators generating data may typically store their resources in default locations in such a tree, resulting in a relatively flat tree structure. As such, it may be beneficial for the service layer to provide assistance to the originators so that the originators can better structure their resources. Additionally, applications consuming the data may prefer data resources to be structured in a certain way, and may only be interested in a small subset of the hosted resources. Therefore, it may be beneficial for such applications to transmit to the service layer the resources that are of interest, and how to structure such resources. Embodiments described herein provide methods and systems to enable solutions to the problems discussed above, among others. Several aspects are introduced to enable such embodiments.

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: 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: 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, systems, and apparatuses associated with the service layer may provide clustering management capabilities for sensor nodes in M2M/IoT SL platforms, via conventional clustering algorithm reselection and performance optimization, which may be based on service layer analytics. Clustering functionality may be adapted not only within the individual network model and optimization goals employed by each conventional clustering algorithm, but the conventional clustering algorithms themselves may be changed or reconfigured using service layer functionality. These re-configurations may be based on analytics indicating that performance of a sensor node is sub-optimal and may occur within a significantly larger time scale when compared to dynamic routing decisions on a per-message basis.

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: 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: 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: 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.