Abstract: Embodiments concern a dynamic authorization framework. Security Classification Process (SCP) is the process of classifying raw data, information extracted from raw data, content or code from security-value perspective. Security Achievability Determination Process (SADP) is a process based on a SV/SC that has been assigned, the RHE may determine the Security Requirements and how the security requirements may be achieved. During the Security Achievability Listing Process (SALP), the RHE uploads onto the Resource Listing Entity (RLE) the URI of the resource, the SAM associated with the resource and optionally a digital certificate associated with the resource. During the SAM Assessment Process (SAMAP) process, a Client evaluates the security mechanisms that must be carried out in order to meet the SAM that was provided as part of the Discovery Process (DP). Based on the SAM obtained from the RLE, the Client may initiate a Security Achievability Enabling Process (SAEP).

Abstract: A naming scheme for IoT Devices can address the problem that the existing naming schemes of the IoT devices do not support device discovery and group operation efficiently. An IoT Device Name Service (IDNS) can be in charge of how the device name is generated from the location and other context information; updated due to the location change or context variation; and discovered. The IoT Devices can be routed by their names using a Name Routing Protocol (NRP). With the name scheme and NRP, the IoT Devices do not need to implement the full protocol stack to enable the direct communication between them.

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: 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 subscription and notification may include dynamically changing notification behavior based on notification target status or support access to notification history information.

Abstract: The application is directed to an apparatus for allocating address space. The apparatus includes a non-transitory memory operably coupled to a processor configured to perform the step of locating a router on a network. The processor also performs the step of sending a router solicitation message including an address allocation flag to the router to reserve the address space. The processor also performs the step of receiving a router advertisement message based upon the router solicitation message including an address space option. Further, the processor performs the step of saving the address space provided in the router advertisement. The application is also directed to a computer-implemented apparatus for communicating address space between routers. The application is also directed to a computer-implemented apparatus for reallocating assigned IP address space. The application is also directed to an apparatus for registering a node with a router.

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.

Abstract: Wireless channels and timeslots are allocated in a distributed and reactive manner by network devices. A source device sends to neighbor devices a track discovery request indicating a destination and data bandwidth/channel and timeslot requirements. The neighbors conditionally forward the message until it reaches the destination device. The forwarded message includes information about the devices traversed by the message. Messages will not be forwarded if the recipient lacks sufficient resources to accommodate the data bandwidth requirements. The destination selects a path to be a communications track based upon characteristics of the one or more paths by which the request was received, and sends a reply back to the source device along the selected path. Once established, tracks may be kept alive, updated, and/or repaired via messaging among the devices along the track.

Abstract: It is recognized herein that existing approaches to M2M/IoT networks do not realize Network Functions Virtualization (NFV). In particular, existing M2M service layers (e.g. oneM2M) are not built, managed, or operated in accordance with NFV practices. In an example embodiment, an M2M apparatus assigns various roles to various common service entities, such that common service functions can be pooled together with one another. The roles can be migrated among common service entities to ensure that the pools are managed and controlled efficiently. Further, pool members can exit and join one or more pools.

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: Mechanisms for subscription and notification may include dynamically changing notification behavior based on notification target status or support access to notification history information.

Abstract: Multicast messaging may be managed in a machine-to-machine/Internet of things context, such as a CoAP network, via the inclusion of server selection criterion in multicast request messages and/or resource directory registration management. Server selection criteria may be explicit or implicit. An explicit criterion may be expressed, for example, as an IP address, a server identifier relative to a group context, or a Bloom filter. An implicit criterion may, for example, relate to the context of the request or the requestor, and include such information as data accuracy, data type, application, operating system, network location, geolocation, resource creation time, and resource update time. Server selection criteria may be maintained by a resource directory and/or via a user interface.

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 lightweight and extensible information model for machine-to-machine systems is disclosed. A service layer information management architecture uses three categories of atomic objects, subjects, actions, and descriptions. Information for use within the model is built using the atomic information objects. Application programming interfaces are used to perform operations and information processing by different nodes. Common service functions are used in the model as instances of a generic common service information model.

Abstract: A cloud-based DNS-SD architecture may link together separate LANs to form a virtual discovery zone from a service discovery perspective that includes a cloud based DNS-SD server separate from regular Internet DNS, and asleep node handling, among other things. In an example, a cloud based DNS-SD server is separate from the regular Internet DNS servers. This cloud DNS-SD server may run as a private Infrastructure as a Service (IaaS) specifically for service discovery in the virtual discovery zone.

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 lightweight and extensible information model for machine-to-machine systems is disclosed. A service layer information management architecture uses three categories of atomic objects, subjects, actions, and descriptions. Information for use within the model is built using the atomic information objects. Application programming interfaces are used to perform operations and information processing by different nodes. Common service functions are used in the model as instances of a generic common service information model.

Abstract: CoAP network nodes may leverage context awareness to take autonomous action to adjust network operations. Context-aware procedures may be pre-configured, established by management entities, or negotiated between nodes, and include parameters for the monitoring and evaluation of data, as well has triggers for taking action. By monitoring requests to observe a resource, a node may determine when a resource should transition to multicast or unicast notification, and dynamically manage multicast group membership based on observation registrations and/or cancellations. By monitoring resource requests, a proxy may determine when to proactively refresh a cached representation of a resource. By monitoring timeouts and/or retransmissions, a client may dynamically adjust a timeout value to optimize communications.

Abstract: The present application describes a computer-implemented device on a network including a non-transitory memory having instructions stored thereon for registering a node with a router on the network. The device also includes a processor, operably coupled to the non-transitory memory, configured to execute the instructions of receiving, from the node over the network, a solicitation with context information including a registration start time request. The processor is also configured to execute the instructions of evaluating, at the router, whether to accept the solicitation based upon neighbor space and the received start time request. The processor is even further configured to execute the instructions of sending, to the node, an advertisement including an approved registration start time based upon the determining step.