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: 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: 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: 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: Authentication of a user or a wireless transmit/receive unit may be based on an obtained measure of authentication strength, which may referred to as an assurance level. For example, a user, via a WTRU, may request access to a service controlled by an access control entity (ACE). The user may be authenticated with a user authenticator and assertion function (UAAF), producing a result. A user assertion may be provided that includes the user authentication result, a user assurance level, and/or a user freshness level. The WTRU may be authenticated with a device authenticator and assertion function (DAAF), producing an associated result. A device assertion may be provided that may include the device authentication result, a device assurance level, and/or a device freshness level. The assertions may be bound together to receive access to a service or resource.

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: 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: An IoT E2E Service Layer Security Management system supports methods/procedures to allow an application to establish, use, and teardown an IoT SL communication session that has application specified E2E security preferences and that targets one or more SL addressable targets (e.g. an IoT application, device, or gateway SL addressable resource). E2E SL Session based methods/procedures achieve a required overall E2E security level, by allowing IoT SL instances to influence and coordinate hop security for a multi-hop communication path spanning across multiple intermediary nodes. Methods/procedures reduce overhead, simplify and obviate the need for E2E service level nodes (initiation/termination nodes) from having to perform security service negotiation, in order to establish secure hop-by-hop security associations aligned with an E2E security requirement.

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: 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: Authentication of a user or a wireless transmit/receive unit may be based on an obtained measure of authentication strength, which may referred to as an assurance level. For example, a user, via a WTRU, may request access to a service controlled by an access control entity (ACE). The user may be authenticated with a user authenticator and assertion function (UAAF), producing a result. A user assertion may be provided that includes the user authentication result, a user assurance level, and/or a user freshness level. The WTRU may be authenticated with a device authenticator and assertion function (DAAF), producing an associated result. A device assertion may be provided that may include the device authentication result, a device assurance level, and/or a device freshness level. The assertions may be bound together to receive access to a service or resource.

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: Multi-RAT UEs currently have 2 independent paths to authenticate with HSS (either via the MME or the 3GPP AAA Server causing repeated authentication messages to HSS. The use of one unified authentication path between the UE and HSS for Small Cell and Wi-Fi authentication is described. First, a new 3GPP EPC-TWAN interworking architecture has the MME manage all the authentication requests from multi-RAT UEs. Second, new unified authentication procedures are added, which allow the ISWN-based multi-RAT UE to be authenticated directly with the HSS, irrespective of its current access network (TWAN or HeNB). Third, new fast re-authentication procedures for Inter-RAT handover scenarios are done. Finally, the needed extensions to the various standard protocol messages to execute the authentication procedures are described.

Abstract: Methods and procedures allow devices interwork with various types of service layers by updating the device to support the protocol of the M2M/IoT service layer that is being communicated with. Devices can coordinate/initiate download of a service layer API that is compatible with the service layer the device is attempting to use. A service layer can coordinate the autonomous update of a device with the proper service layer API which allows the device to then communicate and use services supported by the service layer component to the device. A service layer can detect a device or application lacking proper service layer functionality and can trigger a management entity to update the device or application with the service layer API required such that the device can then register to the service layer and use its services. A device or application can be customized or optimized to the service layer that it is registered to and using.

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: Methods, apparatus and systems for managing an exposure of a network to a wireless transmit/receive unit (WTRU) are disclosed. One representative method includes receiving, by an access point (AP) of the network, information associated with the WTRU; and selectively exposing, by the AP, the network.

Abstract: An authentication assurance level associated with an entity, for instance a user equipment, may be computed periodically or in response to an event. The authentication assurance level is compared to an authentication threshold. Based on the comparison, it is determined whether a fresh performance of at least one authentication factor needs to be performed. Thus, appropriate authentication factors and functions may be invoked on a periodic basis to maintain a certain authentication assurance level, which is referred to herein as the assurance threshold. The authentication assurance level may change, for instance decay, over time and may be refreshed periodically.