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: An IoT E2E Service Layer Security Management system supports methods and 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 and procedures described herein 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. The methods and procedures described herein reduce overhead, simplify and obviate the need for E2E service level nodes (initiation and 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: 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: 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: 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: 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: 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: 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: It is recognized herein that current approaches to traffic steering in M2M systems lack capabilities, particularly with respect to traversing value added services in an operator's network. As described herein, nodes or apparatuses at a machine-to-machine (M2M) service layer can leverage value added services that are deployed in an operator's network. The M2M service layer may add metadata to downlink traffic so that the metadata can be used to assist with steering and processing data in the operator's value added services (VASs) network. By of example, the M2M service layer can use a control plane interface to push polices into a network operator's VASs network, and to allow functions in the VASs network to extract information from the M2M service layer.

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 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: In an embodiment, a client proxy provides an operating-system-functions (OS-functions) interface to client applications. The client proxy and each of the client applications resides on a wireless transmit/receive unit (WTRU). The client proxy receives, via the OS-functions interface, respective registrations from each of a plurality of the client applications. Each respective registration indicates a respective keep-alive-message signaling rate for the corresponding registered client application. The client proxy determines an optimal signaling rate based on the respective keep-alive message signaling rates indicated by the respective registrations. The client proxy generates proxy keep-alive signaling messages that collectively convey keep-alive-message information on behalf of the registered client applications. The client proxy transmits the generated proxy keep-alive signaling messages to a network node at the determined optimal signaling rate.

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: In this disclosure, various issues related to data (information) privacy are addressed. For example, in an example embodiment, privacy and confidentiality of data is maintained while being consumed by a third party entity. As described herein, an entity may be able to perform secure and trustworthy operations, such as various computations and algorithmic functions for example, on private data without having direct access to the data, thereby protecting the data.

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: 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: 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 method and apparatus for performing secure Machine-to-Machine (M2M) provisioning and communication is disclosed. In particular a temporary private identifier, or provisional connectivity identification (PCID), for uniquely identifying machine-to-machine equipment (M2ME) is also disclosed. Additionally, methods and apparatus for use in validating, authenticating and provisioning a M2ME is also disclosed. The validation procedures disclosed include an autonomous, semi-autonomous, and remote validation are disclosed. The provisioning procedures include methods for re-provisioning the M2ME. Procedures for updating software, and detecting tampering with the M2ME are also disclosed.

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: Approaches may be used for enabling coordinated identity management between an operator-managed mobile edge platform (MEP) and an external network. A token may be generated in the MEP that may associate a mobile network identity and an external network identity. The token may be negotiated on a per-session basis or on a per-wireless transmit/receive unit (WTRU) identity (WTRU-ID) basis. In an example method performed by a WTRU camped on a small cell network covered by the MEP, an enterprise bring your own device (BYOD) client (EBC) application may establish a secure link with an enterprise BYOD agent (EBA) application running on the MEP using an initial connection procedure. The EBC application may initiate an application-level authentication procedure with an enhanced evolved packet core (EPC) network. The EBC application may generate and provide a token to the EBA application via the established secure link.