Abstract: A method and apparatus are described for supporting a two-stage device-to-device (D2D) discovery using a D2D interworking function (IWF). A D2D IWF component may be configured to perform mapping between an application running on an application server and a third generation partnership project (3GPP) network, and provide a set of application programming interfaces (APIs) to allow discovery to be provided as a service to D2D applications. An application identifier may be mapped to a 3GPP identifier. Further, a method and apparatus are described for performing client-server discovery. A first wireless transmit/receive unit (WTRU) may be configured for a listen-only operation, and a second WTRU may be configured to transmit beacons. The first and second WTRUs may perform a radio access network (RAN) discovery procedure at an access stratum (AS) layer. A method and apparatus for performing charging for D2D service using a D2D IWF are also described.

Abstract: Device-to-device (D2D) cross link power control systems and methods may be disclosed. For example, a device such as a UE or WTRU may determine whether it may have simultaneous transmissions where at least one of the transmissions may include a cross link transmission. The device may further determine whether a total transmit power of the simultaneous transmissions may exceed a maximum transmit power of the device. If the device may have simultaneous transmissions and such transmissions may exceed the maximum transmit power, the device may reallocate power based on a priority or priority setting. The device may further determine a maximum cross link power, a maximum device power, and a cross link transmit power level such that the device may further control the power for transmissions based thereon.

Abstract: A wireless transmit/receive unit (WTRU) may receive from a network resource allocation information for device to device (D2D) communication. The WTRU may select, from the received resource allocation information for a transmission time interval (TTI), resources for a D2D channel. The WTRU may transmit, with use of the selected resources, data directly to another WTRU.

Abstract: Device-to-device (D2D) cross link power control systems and methods may be disclosed. For example, a device such as a UE or WTRU may determine whether it may have simultaneous transmissions where at least one of the transmissions may include a cross link transmission. The device may further determine whether a total transmit power of the simultaneous transmissions may exceed a maximum transmit power of the device. If the device may have simultaneous transmissions and such transmissions may exceed the maximum transmit power, the device may reallocate power based on a priority or priority setting. The device may further determine a maximum cross link power, a maximum device power, and a cross link transmit power level such that the device may further control the power for transmissions based thereon.

Abstract: A method and apparatus are described for supporting a two-stage device-to-device (D2D) discovery using a D2D interworking function (IWF). A D2D IWF component may be configured to perform mapping between an application running on an application server and a third generation partnership project (3GPP) network, and provide a set of application programming interfaces (APIs) to allow discovery to be provided as a service to D2D applications. An application identifier may be mapped to a 3GPP identifier. Further, a method and apparatus are described for performing client-server discovery. A first wireless transmit/receive unit (WTRU) may be configured for a listen-only operation, and a second WTRU may be configured to transmit beacons. The first and second WTRUs may perform a radio access network (RAN) discovery procedure at an access stratum (AS) layer. A method and apparatus for performing charging for D2D service using a D2D IWF are also described.

Abstract: Systems and methods are provided for adapting communication parameters to a variety of link conditions, traffic types and priorities. For example, WiFi transmission parameters (e.g. retry limit, AIFS, CW size, MCS order and/or CCA threshold) may be adapted to channel congestion levels, channel errors and/or traffic priority levels. Parameter adaptation may be coordinated across layers (e.g. between MAC and PHY layer parameters). Congestion levels may be detected, for example, using a smoothed queue size and/or channel busy time. Traffic may be transmitted using adapted parameters, such as reduced retry limits for a high congestion level and increased retry limits for priority traffic in response to channel error. Feedback may support parameter adaptation. For example, feedback may be provided by a receiver and/or within a sender, such as a sender MAC and/or PHY layer or a parameter adapter providing feedback (e.g. spoofed NACK packet) to a sender application, transport and/or network layer.

Abstract: The present application is at least directed to an apparatus on a network. The apparatus includes a non-transitory memory having instructions stored thereon for online charging of an event. The apparatus also includes a processor that is operably coupled to the non-transitory memory. The processor is configured to execute the instructions of receiving, from an M2M gateway, a rating request message for service layer online charging. The processor is also configured to execute the instructions of determining a rating scheme to charge for the event. The processor is further configured to execute the instructions of calculating an amount of service units based on the rating request message and determined rating scheme. The processor is even further configured to execute the instructions of sending, to the M2M gateway, a rating response based upon the calculated amount of service units.

Abstract: Systems and methods are provided for adapting communication parameters to a variety of link conditions, traffic types and priorities. For example, WiFi transmission parameters (e.g. retry limit, AIFS, CW size, MCS order and/or CCA threshold) may be adapted to channel congestion levels, channel errors and/or traffic priority levels. Parameter adaptation may be coordinated across layers (e.g. between MAC and PHY layer parameters). Congestion levels may be detected, for example, using a smoothed queue size and/or channel busy time. Traffic may be transmitted using adapted parameters, such as reduced retry limits for a high congestion level and increased retry limits for priority traffic in response to channel error. Feedback may support parameter adaptation. For example, feedback may be provided by a receiver and/or within a sender, such as a sender MAC and/or PHY layer or a parameter adapter providing feedback (e.g. spoofed NACK packet) to a sender application, transport and/or network layer.

Abstract: Systems, methods, and instrumentalities are disclosed to perform rate adaptation in a wireless transmit/receive unit (WTRU). The WTRU may receive an encoded data stream, which may be encoded according to a Dynamic Adaptive HTTP Streaming (DASH) standard. The WTRU may request and/or receive the data stream from a content server. The WTRU may monitor and/or receive a cross-layer parameter, such as a physical layer parameter, a RRC layer parameter, and/or a MAC layer parameter (e.g., a CQI, a PRB allocation, a MRM, or the like). The WTRU may perform rate adaption based on the cross-layer parameter. For example, the WTRU may set the CE bit of an Explicit Congestion Notification (ECN) field based on the cross-layer parameter. The WTRU may determine to request the data stream encoded at a different rate based on the cross-layer parameter, the CE bit, and/or a prediction based on the cross-layer parameter.

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: Systems and methods are provided for adapting communication parameters to a variety of link conditions, traffic types and priorities. For example, WiFi transmission parameters (e.g. retry limit, AIFS, CW size, MCS order and/or CCA threshold) may be adapted to channel congestion levels, channel errors and/or traffic priority levels. Parameter adaptation may be coordinated across layers (e.g. between MAC and PHY layer parameters). Congestion levels may be detected, for example, using a smoothed queue size and/or channel busy time. Traffic may be transmitted using adapted parameters, such as reduced retry limits for a high congestion level and increased retry limits for priority traffic in response to channel error. Feedback may support parameter adaptation. For example, feedback may be provided by a receiver and/or within a sender, such as a sender MAC and/or PHY layer or a parameter adapter providing feedback (e.g. spoofed NACK packet) to a sender application, transport and/or network layer.

Abstract: Systems, methods, and instrumentalities are disclosed to perform rate adaptation in a wireless transmit/receive unit (WTRU). The WTRU may receive an encoded data stream, which may be encoded according to a Dynamic Adaptive HTTP Streaming (DASH) standard. The WTRU may request and/or receive the data stream from a content server. The WTRU may monitor and/or receive a cross-layer parameter, such as a physical layer parameter, a RRC layer parameter, and/or a MAC layer parameter (e.g., a CQI, a PRB allocation, a MRM, or the like). The WTRU may perform rate adaption based on the cross-layer parameter. For example, the WTRU may set the CE bit of an Explicit Congestion Notification (ECN) field based on the cross-layer parameter. The WTRU may determine to request the data stream encoded at a different rate based on the cross-layer parameter, the CE bit, and/or a prediction based on the cross-layer parameter.

Abstract: A modular and distributed architecture for data stream processing and analysis is described to incorporate data stream analytics capabilities, called Data Stream Analytics Service (DSAS) in the IoT/M2M service layer. Each service layer node hosting DSAS can be split into two independent modules, Stream Forwarder and Stream Analytics Engine. Stream Forwarder is a light weight processing modules that can be responsible for data preprocessing and routing. Stream Analytics Engine is responsible for performing actual analytics on the data stream. Separating the two functionalities enables the service layer nodes to efficiently distribute stream analytics tasks across multiple nodes.

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: A method and apparatus for neighbor discovery in a wireless communication system are disclosed. A neighbor seeking wireless transmit/receive unit (WTRU) may search for a first signal to discover neighbor WTRUs for peer-to-peer communication. The WTRU may then receive the first signal. Further, the WTRU may generate a report based on the received first signal. Then, the WTRU may send a second signal carrying the report to a cellular wireless network. The first signal may include a beacon for neighbor discovery or a synchronization signal or both. The report may contain at least one neighbor WTRU identity or at least a portion of a time value or both. Further, the report may contain a counter value, including at least a portion of a time value. The counter value may be based on a time source. In addition, the first signal may be received from a synchronization source.

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: A base station may sense, on a cell using unlicensed spectrum, that the unlicensed spectrum is available for transmission. The base station may transmit, after sensing that the unlicensed spectrum is available, consecutive subframes. Each subframe may include a physical downlink control channel and a physical downlink shared channel.

Abstract: Systems, methods, and instrumentalities are disclosed for managing real-time traffic video flows. A node may comprise a processor configured to receive a first real-time video traffic flow. A state variable may be associated with the first real-time video traffic flow at the node and a state variable may be associated with the second real-time video traffic flow at the node. The first real-time video traffic flow may comprises plurality of packets and each packet may comprise a lost packet indicator. The node may be configured to drop a first packet in the first real-time video traffic flow, update the state variable associated with the first real-time video traffic flow at the node to indicate the dropped packet, and update the lost packet indicator for a second packet in the first real-time video traffic flow based on the dropped packet.

Abstract: Visual information may be delivered to streaming-capable devices in a viewing environment, such as a home environment or a commercial environment. The visual information can be adapted to user behavior and/or viewing conditions in such a way as to deliver a satisfactory user experience while conserving network resources, such as bandwidth and/or capacity. Viewing distance and/or ambient light, which may affect viewing conditions in a viewing environment, may be estimated. Bandwidth may be reduced by eliminating details that may not be perceived by the user in the estimated viewing conditions (e.g., by determining a spatial resolution (e.g. a maximum spatial resolution) perceptible under the viewing conditions and not exceeding that spatial resolution).

Abstract: A device may control a video communication via transcoding and/or traffic shaping. The device may include a multipoint control unit (MCU) and/or a server. The device may receive one or more video streams from one or more devices. The device may analyze a received video stream to determine a viewing parameter. The viewing parameter may include a user viewing parameter, a device viewing parameter, and/or a content viewing parameter. The device may modify a video stream based on the viewing parameter. Modifying the video stream may include re-encoding the video stream, adjusting an orientation, removing a video detail, and/or adjusting a bit rate. The device may send the modified video stream to another device. The device may determine a hit rate for the video stream based on the viewing parameter. The device may indicate the bit rate by sending a feedback message and/or by signaling a bandwidth limit.