Abstract: A caching entity may store a cached copy of a service layer resource. An original hosting entity may maintain a registry of the corresponding cached resources. Optionally, the original hosting entity may set cache parameters to govern the lifetime of the cache on a caching entity. The caching entity may keep storing the cached copy of the resource and the original hosting entity may obtain statistics about the cached resource. By knowing the statistics, e.g. how many times a resource is retrieved on each caching entity, the original hosting entity may better manage the resource.

Abstract: IoT twinning groups can be dynamically created. These twinning groups can be activated based on selected triggers. As part of twinning operation, service delivery can be re-directing away from the primary device to the IoT twinning group. Messages originating from members of the IoT twinning group can be processed and forwarded externally as if they came from the primary device. Further, the twinning service can be de-activated based on selected triggers.

Abstract: Methods, systems, and devices may be used for assigning names and bootstrapping of security credentials for Smart Objects inside a Digital Home environment. Methods, systems, and devices for identification and security bootstrapping of a smart object within a digital home environment may include automated assignment of a device level ID and security credential for each smart object in the home using a resource directory.

Abstract: The present application is directed to a system and method for allocating a Track in a 6T1SCH network. The method includes the step of receiving a Track computation request in PCEP from a first PCE proxy on a first Backbone router. The method also includes the step of calculating an optimal Track between a source LLN device and a destination LLN device. Further, the method includes the step of sending a Track assignment message to one or more LLN devices in the optimal Track. The present application also is directed to a system and method for reporting TSCH schedule information to a PCE. Further, the present application is directed to a LLN device.

Abstract: Methods, systems, and devices may be used to support freshness-based processing of requests. Freshness-based processing may involve the service layer examining the age of stored content (e.g., resource representation) that it hosts and determining whether it is fresh enough to satisfy a retrieve or discovery request with a specified freshness requirement. If not fresh, the service layer can contact an application to refresh the content. In addition, freshness-based processing can also involve the service layer examining the semantic state of a command oriented update request to determine whether its state is fresh or not with respect to prior commands processed by the service layer. For example, the service layer may compare stored content associated with controlling a particular application (e.g. door is locked) and against the semantic content of an update request (e.g., unlock door) to determine whether it is the same (e.g., stale) or not (e.g., fresh).

Abstract: The CoAP base protocol can be enhanced to support CoAP streaming. Streaming can use a reserved “/streaming” URI and current CoAP methods can be used towards the “/streaming” location, which will trigger or terminate streaming operations. Streaming can use a new STREAM method. Alternately, the current Observe mechanism can be enhanced to support streaming. Streaming operation can be combined with existing CoAP block transfer operations.

Abstract: Many internet of things (IoT) are “sleepy” and thus occasionally go into a sleep mode. As described herein, nodes in a connected network of nodes may determine that other nodes in the network are sleepy. Further, nodes, such as endpoint devices and routers for example, may process packets in the network based on a reachability state of their neighboring nodes.

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: 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: 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: 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: A service, such as an internet of things service, may have multiple service elements. Each service element may be provided by multiple devices or virtual devices (service element hosts). A service/service element can be managed as a resource at the sendee layer. Service with multiple service elements is supported. Based on a QoS requirement from a client, service element host selection may use the necessary context information to make the decision of selecting a service element host. A client may choose to send the QoS requirement to the sendee host, which in turn forwards it to service element host selection.

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.

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 CoAP resource directory discovers, and creates a map of, autonomic nodes that meet certain security criteria for joining an autonomic control plane. The resource directory shares the map and/or neighbor relationships with the mapped nodes. The mapped nodes interact with the RD and with each other via the autonomic control plane to perform autonomic node and network self-management functions, such as self-configuration, self-protection, self-healing, and self-optimization. In addition, a CoAP option allows the autonomic control plane to be used for alternative routing of critical messages. The autonomic control plane may be observed and adjusted using a graphical user interface.

Abstract: Functionality is added to the CoAP and WebSocket protocols to enable the creation of communication sessions, or connections, at a CoAP layer of a communications network. In one aspect, a connection is created at Client server the CoAP layer using CoAP RESTful messages. In another aspect, new CoAP Options are introduced to request initiation and deletion of a connection at the CoAP layer. In yet another aspect, new CoAP Codes are introduced to request initiation and deletion of a connection at the CoAP layer. In a further aspect, new CoAP Tokens are introduced to request initiation and deletion of a connection at the CoAP layer.

Abstract: Disclosed herein are a variety of devices, methods, and systems for load balancing in the internet of things. Devices and other entities can be grouped together in a load balancing group and traffic for such devices balanced according to load balancing criteria. Groups may be discovered, created, manipulated, and deleted by various entities.

Abstract: The present application is directed to a system and method for allocating a Track in a 6T1SCH network. The method includes the step of receiving a Track computation request in PCEP from a first PCE proxy on a first Backbone router. The method also includes the step of calculating an optimal Track between a source LLN device and a destination LLN device. Further, the method includes the step of sending a Track assignment message to one or more LLN devices in the optimal Track. The present application also is directed to a system and method for reporting TSCH schedule information to a PCE. Further, the present application is directed to a LLN device.

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