Abstract: Systems and methods are described to automate managing of relationships between IoT entities (e.g., devices, apps, users) and offloading the burden of managing these relationships from users. A Relationship Management Service (RM Service) is described herein for the autonomous establishment, modification, and tear-down of relationships between IoT entities.

Abstract: A link management service may dynamically configure one or more link-enabling attributes based on a link profile. There may be multiple types of architectures that support the link management service, such as an independent link management and integrated link management.

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: A set of point-of-contact information including a service level identifier, an address, a list of interfaces, and a set of interface selection preferences for each of several entities may be used to facilitate communications among the entities by selecting a preferred interface in accordance with the set. Interface preferences may also be derived from a set of policies. The preferred interface may be resolved in accordance with the preferences of multiple entities. Messages may include an interface type parameter to be used for forwarding of the message, and message forwarding may be resolved in accordance with the parameter and the messages.

Abstract: The provision of fog services may be coordinated by a fog leader adapted to track capabilities and resources available at other fog nodes, and to receive and process requests and policies from entities seeking fog services. For example, the fog leader may divide tasks among several fog nodes according to the capabilities and resources available at various nodes, and do so in a way that is transparent to the requestor and the fog nodes providing the service. The fog leader may request the reservation of capabilities and resources, and confirm and cancel such reservations. Fog services policies may include, for example, periods of time during which capabilities and resources should be reserved.

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: A service layer (SL) function may be used for managing a user profile that is associated with a SL user and using this profile to automatically configure different types of devices connected to an IoT service provider's platform. A SL function may be used to support user data privacy and security when data is imported and exported between gateways or servers temporarily.

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: 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: An IoT/M2M service layer may be provided with the capability to protect user privacy. This functionality may allow the IoT/M2M service layer to anonymize user data, particularly when user data is shared with third party consumers. A privacy policy service may enable the IoT service layer system to generate anonymization (e.g., privacy) policies based on inputs such as legal obligations, subscriber privacy preferences, and an authorization level of the data consumer. Data anonymization policies may be output from the privacy policy service and may be sent to a data anonymization service, where raw data may be anonymized based on the one or more data anonymization policies. The output from the data anonymization service function may be a privatized (e.g., anonymized) version of data that may prevent the data consumer from discovering one or more identifying characteristics of a user.

Abstract: The present application at least describes a computer-implemented method including a step of setting, via a service layer residing on a server outside of an underlying 3GPP network, a trigger in the underlying 3GPP network, where the trigger defines an QoS parameter change in the underlying 3GPP network. The underlying 3GPP network is configured with functionality to send a notification to the service layer upon detecting the QoS parameter change. The computer-implemented method also includes a step of receiving, from the underlying 3GPP network, the notification the detected QoS parameter change has occurred. The computer-implemented method further includes a step of performing, at the service layer residing on the server a service layer operation in response to the received notification.

Abstract: Systems and methods are described herein to automate managing of service layer operations comprised of multiple elementary operations and offloading the burden of performing such multi-step operations from a requesting entity to the service layer. A Request Abstraction Service (RAS) is described herein for the autonomous execution of such multi-step operations. Methods and apparatuses are also described herein for a service layer framework for integrating generic and functional user interfaces as services managed by the SL on behalf of requesting entities.

Abstract: When mobile terminated devices sleep, the devices might not be reachable when needed, for instance when the device is a recipient of data from a third party server. As described herein, a third party application server may inform the network that it has data to send to a particular UE or group of UEs. In an example, the mobile core network (MCN) may use information from the third party server to ensure that the UE is awake when it needs to be. For example, a given UE or group of UEs can be prevented from entering a sleep state before a data transfer is completed.

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: It is recognized herein that capabilities are lacking related to how different users can be authenticated on top of an existing subscription authentication. In some examples, a user¬ centric authentication layer may be supported on top of an existing subscription authentication, such that different users may use the same user equipment (UE) with customized services, and different users of devices can be identified behind a gateway with a 3GPP subscription (without the devices having a dedicated 3GPP subscription). Further, a user identifier may be linked to a subscription to access 3GPP services via non-3GPP access.

Abstract: A new semantic mashup architecture with modular design can comprise separate Semantic Mashup Profiles (SMPs), Virtual Semantic Mashup Resources (VSMRs), and Semantic Mashup Results (SMRSs). This kind of modular design greatly improves the reusability of SMPs, VSMRs, and SMRSs. In addition, this new mashup architecture leverages semantics during each mashup process, which increases the interoperability. Moreover, this new architecture essentially realizes new Semantic Mashup Service (SMS) at the service layer and consequently improves system efficiency.

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, 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: An interworking service entity receives server registration requests including indications of service layer protocols used by each server, maintains a repository of server information, and uses the repository for interworking requests of devices to servers of different protocols based on a server type provided in discovery requests. Other matching information may include, for example, server security protocol, supported services, service territory, availability, capacity, or loading, as device information or preferences, such as supported service, supported interface type, or a supported device type.