WO2017083388A1

WO2017083388A1 - Methods and apparatuses directed to cooperative communications

Info

Publication number: WO2017083388A1
Application number: PCT/US2016/061138
Authority: WO
Inventors: Benoit Pelletier; Aata EL HAMSS; J. Patrick Tooher
Original assignee: Idac Holdings, Inc.
Priority date: 2015-11-10
Filing date: 2016-11-09
Publication date: 2017-05-18

Abstract

Methods, apparatuses, systems, devices, and computer program products directed to achieving high reliability using cooperative communications, including D2D communications, are provided. In an embodiment, a wireless transmit/receive unit (WTRU) may cooperate in uplink transmission of feedback information. The WTRU may cooperate with one or more other WTRUs to increase coverage for, and/or enhance reliability of, transmission of the feedback information for/of such other WTRUs by, for example, relaying, forwarding or otherwise transmitting the feedback information for/of such other WTRUs to a base station.

Description

METHODS AND APPARATUSES DIRECTED TO COOPERATIVE COMMUNICATIONS

CROSS REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62/253,583, filed 10-Nov-2015, which is incorporated herein by reference.

BACKGROUND

[0002] Field

[0003] This application is related to wireless communications.

[0004] Related Art

[0005] Work on next generation of mobile communication (5G) has already started, and many applications proposed to be part of 5G can require high reliability. Indeed, 5G targets new applications, such as control of critical infrastructure and communications between vehicles to traffic safely, which can require connectivity with very high-reliability (e.g., 99.999% link reliability). 5G is being designed to support multiple RATs, including one or more new RATs targeting higher frequencies than its/their predecessors (e.g., > 6 GHz), and to support evolution of current wireless technologies (e.g., Long Term Evolution (LTE), high-speed packet access (HSPA), Wi-Fi, etc.). Other technologies that may be considered for 5G include cooperative communications. Such cooperative communications, including device-to-device (D2D) communications, as described herein along with the other teachings herein may provide the sought- after high reliability.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref ") in the Figures indicate like elements. Also, a ref. followed by the term "(alt.)" indicates that the item that it refers to may be an alternative to, or alternate of, another item referred to by the same ref. (with or without the term "(alt.)"), and wherein:

[0007] Figure 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented; [0008] Figure IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in Figure 1 A;

[0009] Figures 1C, ID and IE are system diagrams of example radio access networks and example core networks that may be used within the communications system illustrated in Figure 1A;

[0010] Figure 2 illustrates an example environment in which embodiments may be practiced or implemented;

[0011] Figure 3 is a flow diagram illustrating an example procedure for engaging in cooperative communications;

[0012] Figure 4 illustrates an example of a procedure to facilitate and/or enable feedback- information relaying;

[0013] Figure 5 is a flow diagram illustrating an example procedure for engaging in cooperative communications;

[0014] Figure 6 illustrates example overlay transmission techniques for feedback-information relaying;

[0015] Figure 7 illustrates example architecture of a wireless transmit/receive unit configured for engaging in cooperative communications;

[0016] Figure 8 is a graph illustrating example gains that may be realized using cooperative communications in accordance with embodiments herein;

[0017] Figure 9 illustrates an example of an aggregated feedback message;

[0018] Figures 10A and 10B illustrate examples of an aggregated feedback message; and

[0019] Figures 11 A and 1 IB illustrate examples of an aggregated feedback message.

DETAILED DESCRIPTION

[0020] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and/or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and/or inherently (collectively "provided") herein. [0021] Example Communications System

[0022] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. An overview of various types of wireless devices and infrastructure is provided with respect to Figures 1A-1E, where various elements of the network may utilize, perform, be arranged in accordance with and/or be adapted and/or configured for the methods, apparatuses and systems provided herein.

[0023] Figure 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. Example communications system 100 is provided for the purpose of illustration only and is not limiting of the disclosed embodiments. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0024] As shown in Figure 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0025] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node- B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0026] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0027] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0028] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0029] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0031] The base station 114b in Figure 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 1 14b may not be required to access the Internet 110 via the core network 106.

[0032] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in Figure 1 A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology. [0033] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Figure 1 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0035] Figure IB is a system diagram of an example WTRU 102. Example WTRU 102 is provided for the purpose of illustration only and is not limiting of the disclosed embodiments. As shown in Figure IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0036] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Figure IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0037] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0038] In addition, although the transmit/receive element 122 is depicted in Figure IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0039] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0040] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The non-removable memory 106 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0041] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0042] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0044] Figure 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. As shown in Figure 1C, the RAN 104 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104. The RAN 104 may also include RNCs 142a, 142b. It will be appreciated that the RAN 104 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0045] As shown in Figure 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0046] The core network 106 shown in Figure 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0047] The RNC 142a in the RAN 104 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0048] The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0049] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0050] Figure ID is a system diagram of the RAN 104 and the core network 106 according to another embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0051] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MTMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0052] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in Figure ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0053] The core network 106 shown in Figure ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0054] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0055] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like. [0056] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0058] Figure IE is a system diagram of the RAN 104 and the core network 106 according to another embodiment. The RAN 104 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 106 may be defined as reference points.

[0059] As shown in Figure IE, the RAN 104 may include base stations 170a, 170b, 170c, and an ASN gateway 172, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 170a, 170b, 170c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 170a, 170b, 170c may implement MIMO technology. Thus, the base station 170a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 170a, 170b, 170c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 172 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like. [0060] The air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 106. The logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0061] The communication link between each of the base stations 170a, 170b, and 170c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 170a, 170b, 170c and the ASN gateway 172 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0062] As shown in Figure IE, the RAN 104 may be connected to the core network 106. The communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 106 may include a mobile IP home agent (MTP-HA) 174, an authentication, authorization, accounting (AAA) server 176, and a gateway 178. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0063] The MIP-HA 174 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 174 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 176 may be responsible for user authentication and for supporting user services. The gateway 178 may facilitate interworking with other networks. For example, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers. [0064] Although not shown in Figure IE, it will be appreciated that the RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks. The communication link between the RAN 104 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104 and the other ASNs. The communication link between the core network 106 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0065] Figure 2 illustrates an example environment 200 in which embodiments may be practiced or implemented. Example environment 200 is provided for the purpose of illustration only and is not limiting of disclosed embodiments. As shown in Figure 2, example environment 200 includes a base station 202, a WTRU 204a, a WTRU 204b and a WTRU 204c. As would be understood by a person of skill in the art, example environment 200 may include additional elements not shown in Figure 2.

[0066] The base station 202 may be any of the base stations 114 (Figure 1A), Node-Bs 140 (Figure 1C), eNode-Bs 160 (Figure ID) and base stations 170 (Figure IE), for example. The base station 202 may include functionality similar to, and/or different from, the base stations 114, Node- Bs 140, eNode-Bs 160 and base stations 170, as well. For example, the base station 202 may include functionality to support anticipated features of 5G and to implement the procedures, techniques, etc. included herein.

[0067] Each of the WTRUs 204a, 204b and 204c may be any of the WTRUs 102 (Figures 1A- 1E), for example. Each of the WTRUs 204a, 204b and 204c may include functionality similar to, and/or different from, the WTRUs 102, as well. The WTRUs 204a, 204b and 204c may include functionality to support anticipated features of 5G and to implement the procedures, techniques, etc. included herein.

[0068] The WTRUs 204a, 204b and 204c may engage in communications with one another using device-to-device (D2D) communications. The D2D communications may be direct, e.g., via a D2D link between two of the WTRUs 204a, 204b and 204c. Alternatively, the D2D communications may be indirect, e.g., via D2D links connecting one of the WTRUs 204a, 204b and 204c to the other two of the WTRUs 204a, 204b and 204c.

[0069] Direct communications in example environment 200 between the base station 202 and each of the WTRUs 204a, 204b and 204c depends on whether such WTRUs 204a, 204b and 204c are in-coverage (within coverage range) or out-of-coverage with respect to the base station 202. Any of the WTRUs 204a, 204b and 204c in-coverage with respect to the base station 202 may cooperate with any of the other WTRUs 204a, 204b and 204c (whether such are in-coverage or out-of-coverage with respect to the base station 202) to increase coverage and/or reliability and/or to relay, forward or otherwise receive and transmit information of/for such other WTRUs 204a, 204b and 204c. Using D2D communications, for example, any of the WTRUs 204a, 204b and 204c in-coverage with respect to the base station 202 may serve as a relay to support uplink and/or downlink transmissions.

[0070] In the example shown, all of the WTRUs 204a, 204b and 204c are in-coverage with respect to the base station 202, and the WTRUs 204a and 204c have respective D2D (e.g., radio) links with the WTRU 204b. The WTRUs 204a and 204c may receive from the base station 202 downlink transmissions having respective data and/or control information traffic ("traffic") Dl, D2. The WTRU 204b may also receive the downlink transmissions and/or monitor the downlink transmissions for the traffic Dl, D2. Although not shown, the WTRU 204b, in its role as a relay for communications from the base station 202, may relay, forward or otherwise receive and transmit the transmissions/traffic Dl, D2 to their appropriate destinations.

[0071] The WTRUs 204a and 204c may transmit feedback information C 1 , C2 to the base station 202 and/or to the WTRU 204b via the D2D links. The WTRU 204b may cooperate with the WTRUs 204a and 204c to increase coverage for, and/or enhance reliability of, transmission of the feedback information CI and/or C2 by, for example, relaying, forwarding or otherwise transmitting to the base station 202 the feedback information CI and/or C2 received by the WTRU 204b. As described in detail herein, the WTRU 204b may receive the feedback information CI and/or C2 via the D2D links and/or from the transmissions from the WTRUs 204a and 204c to the base station 202 ("WTRU-to-BS transmissions"). The WTRU 204b may transmit the received feedback information CI, C2 (individually or in some aggregate form) to the base station 202. In some instances, the WTRU 204b may demodulate and/or decode the transmissions received via the D2D links and/or the WTRU-to-BS transmissions from the WTRUs 204a and 204c, and then may modulate and/or encode the signal/information obtained from the received transmissions for its transmission to the base station 202.

[0072] As would be understood by a person of skill in the art based on the teachings herein, the cooperative communications (including the D2D communications) according to this disclosure are not limited by the example communications described herein with respect to example environment 200.

[0073] For simplicity of exposition herein, the terms "relay WTRU" or its abbreviation "RU" refer to a WTRU that may relay, forward or otherwise receive and transmit transmissions/traffic (data and/or control information) destined for, or sourced from, another WTRU. And the terms "feedback relay WTRU" or its abbreviation "FRU" refer to a relay WTRU that may relay, forward or otherwise receive and subsequently transmit to a base station (or other network element) feedback information for, and/or of, another WTRU. The terms "source WTRU" may be used herein to refer to a WTRU from which traffic, including feedback information, may be sourced. In the example environment 200, for instance, the WTRU 204b may be (i) a RU for the WTRUs 204a and 204c and/or (ii) a FRU for feedback information for/of the WTRUs 204a and 204c.

[0074] In addition to above, the terms "feedback source WTRU" and its abbreviation "FSU" refer to a WTRU that transmits its feedback information to a base station (or other network entity), potentially relayed via a FRU. The terms "potential FRU" may refer to a WTRU that may be considered as candidate for operating as a FRU. The terms "potential source WTRU" may refer to a WTRU that may be considered as candidate for operating as a FSU. The terms "time repetition pattern for transmission" and its abbreviation "T-RPT" refer to a set of sub-frames used by a specific WTRU for transmitting data. The T-RPT may be defined over the transmission occasion pattern. It may indicate resources for transmission of each MAC PDU. For multiple MAC PDUs, it may indicate transmission interval(s) between them. The abbreviation "D2DSS" refers to D2D Synchronization Signals used by a WTRU to obtain time and frequency synchronization. The terms "physical downlink control channel" and "enhanced physical downlink control channel" along with their respective abbreviations "PDCCH" and "ePDCCH", unless recited separately, are collectively referred to herein as the "physical downlink control channel" and/or the abbreviation "PDCCH". The terms "physical uplink control channel" and "enhanced physical uplink control channel" along with their respective abbreviations "PUCCH" and "ePUCCH", unless recited separately, are collectively referred to herein as the "physical uplink control channel" and/or the abbreviation "PUCCH".

[0075] High reliability in current cellular systems may depend on a hybrid automatic repeat request (HARQ) protocol. According to such protocol, HARQ is carried out using a combination of high-rate forward error-correcting (FEC) coding and automatic repeat request (ARQ) error- control. Efficiency of HARQ relies on supporting a robust binary feedback. Unfortunately, FEC coding cannot protect efficiently single bit feedback provided by the HARQ protocol. For the same reasons, FEC coding cannot protect efficiently other low-bit count types of feedback information (or low-bit count data), as well.

[0076] A natural and perhaps naive approach to improve reliability of feedback information (e.g., HARQ feedback/information, CSI information and other types of feedback information) being received in current wireless systems is to simply increase the transmission power of the feedback channel. This approach, however, is inefficient, has undesired interference consequences and, in power-limited operations or under other conditions, cannot be used or, if used, fails to achieve the goal of improved reliability.

[0077] This disclosure is drawn, inter alia, to methods, apparatuses, systems, devices, and computer program products directed to achieving the sought after high reliability using cooperative communications, including D2D communications, as described herein (along with other teachings herein). In an embodiment, a FRU may cooperate in uplink transmission of feedback information. The FRU may cooperate with one or more other WTRUs to increase coverage for, and/or enhance reliability of, transmission of the feedback information for/of such other WTRUs by, for example, relaying, forwarding or otherwise transmitting to a base station the feedback information for/of such other WTRUs.

[0078] In an embodiment, a RU in a cell may be selected as a FRU, and a set of WTRUs may be associated to the FRU. The selection as a FRU and/or the association of the set of WTRUs to the FRU may be based on various criteria. The criteria may include, for example, radio link quality, buffer status, etc. In an embodiment, the FRU may receive the feedback information of the WTRUs via communications (e.g., messages transmitted) over D2D links and/or from WTRU-to-BS transmissions from the WTRUs.

[0079] In an embodiment, the FRU may determine the feedback information for and/or of the WTRUs based, at least, in part, on any of (i) communications from a base station, (ii) communications from the WTRUs, and (iii) communications over D2D links between the FRU and the WTRUs. The feedback information received or otherwise obtained from any individual WTRU may be as small as a single bit, and may be, for example, un-encoded, decoded, non (channel) coded and/or non-FEC protected feedback information. [0080] In an embodiment, the FRU may aggregate or otherwise combine the feedback information from one or more of the WTRUs to form aggregated feedback information. The FRU may form one or more aggregated feedback messages using the aggregated feedback information. The FRU may encode the aggregated feedback message using channel, FEC, etc. coding. In an embodiment, the FRU may transmit to the base station one or more codewords that include the feedback information, aggregated feedback and/or aggregated feedback message.

[0081] Among the methodologies and/or technologies provided herein are those that carry out (i) selection or otherwise determination of a FRU, (ii) determination of one or more communication channels over which the feedback information is transmitted by each of one or more WTRUs and/or received by a FRU, and (iii) determination of which scheme(s) and/or modes of various schemes and/or modes by which a FRU may transmit to a base station feedback information, aggregated feedback, aggregated feedback messages, etc.

[0082] For simplicity of exposition, the methodologies and/or technologies provided herein may be described in the context of HARQ feedback (e.g., any of acknowledgement and non- acknowledgement (collectively "HARQ-ACK"))). It should be understood that the methodologies and/or technologies provided herein are not limited to HARQ feedback, but also applicable to other types of feedback information and/or traffic, including data and/or control information. The methodologies and/or technologies provided herein are described in the context of uplink transmission of feedback information. It should be understood that the methodologies and/or technologies provided herein may also apply for downlink transmission of traffic and/or feedback information. In such case, a FRU may relay, forward or otherwise transmit the traffic and/or feedback information from a network node to a WTRU ("feedback destination WTRU" or "FDU").

[0083] Provided herein are methodologies and/or technologies for initiating the use of a WTRU as a FRU. In an embodiment, a base station may indicate (e.g., send an indication) to a WTRU to use at least one of the various feedback schemes. Such various feedback schemes may include (i) a scheme under which the WTRU is configured for WTRU-to-base station transmission of feedback information (e.g., HARQ-ACK); (ii) a scheme under which the WTRU is configured for WTRU-to-base station and WTRU-to-FRU-to-base station transmission of feedback information (e.g., HARQ-ACK); and (iii) a scheme under which the WTRU is configured for WTRU-to-FRU- to-base station transmission of feedback information (e.g., HARQ-ACK). [0084] The feedback schemes may be semi-statically and/or dynamically configured. In an embodiment, the base station 202 may use higher layer signaling to indicate to the WTRU 204 which feedback scheme to use. The configuration may be specific to at least one of: serving cell, subframe set, logical channel, priority, radio bearer, subframe size, allocation type (for example based on whether spatial multiplexing is used).

[0085] In an embodiment, the indication may be sent on a dynamic basis. The indication, for example, may be transmitted in a downlink assignment that includes a field carrying the indication of the feedback scheme to use for feedback of transmissions assigned by that downlink assignment. The WTRU 204 may be configured to expect such downlink assignment to have the field carrying the indication of the feedback scheme, and upon receiving such indication may configure itself to use the indicated feedback scheme for feedback of transmissions assigned by the downlink assignment.

[0086] In an embodiment, the feedback scheme may be implicitly determined by the WTRU 204. The implicit determination may depend on at least one of: the subframe (either the subframe of the downlink assignment, the subframe of the HARQ-ACK feedback, etc.), the serving cell ID, whether the WTRU has physical uplink control channel (PUCCH) resources on a (e.g., serving) cell, a carrier frequency, a total number of serving cells configured and/or activated, a channel type (licensed or unlicensed), etc. For simplicity of exposition, unless recited separately, the terms "physical uplink control channel" and "enhanced physical uplink control channel" along with their respective abbreviations "PUCCH" and "ePUCCH" are collectively referred to herein as the "physical uplink control channel" and/or the abbreviation "PUCCH".

[0087] Provided herein are methodologies and/or technologies for WTRU-triggered use of FRU(s). A WTRU 204 may determine that it might not reliably transmit feedback information to a base station. After making the determination, the WTRU 204 may transmit to the base station a message informing the base station that it has begun a process of identifying an appropriate FRU. Alternatively, the WTRU 204 may transmit to the base station a message informing the base station that it might not reliably transmit its feedback information. The base station, in turn, may begin the process of FRU identification and/or configuration.

[0088] The WTRU 204 may determine whether to use a FRU based on various information. This information may include, for example, one or more of the following:

[0089] measurements taken on (e.g., pre-configured) reference signals; [0090] measurements taken on reference signals tied to a downlink assignment (for example, assuming channel reciprocity);

[0091] power required for uplink transmission, for example for transmission of the feedback information (a power limited WTRU, for example, may decide to use a FRU);

[0092] available resources for the feedback information (for example, a WTRU may decide to use a FRU when it determines that multiple subframes (possibly repeated transmissions) may be needed to transmit HARQ-ACK and fewer transmissions of HARQ-ACK may be needed when using a FRU);

[0093] pathloss to the base station 202 and/or to one or more potential FRUs; and

[0094] proximity detection based on discovery signals from one or more potential FRUs.

[0095] Referring now to Figure 3, a flow diagram illustrating an example procedure 300 for engaging in cooperative communications with one or more FSUs is shown. In Figure 3, blocks with dotted lines indicate the features set forth therein may be optional. The procedure 300 may be implemented in a WTRU (e.g., a potential FRU). Pursuant to procedure 300, the WTRU may be configured to support uplink relaying for the FSUs.

[0096] The WTRU may receive from a network (e.g., a base station) a request to report potential source WTRU candidates to the network/base station (302). The WTRU may determine, e.g., based on various criteria, one or more potential source WTRU candidates to report back to the network/base station (304). Alternatively, the WTRU may autonomously determine potential source WTRU candidates to report to the network/base station (302/304 (alt.)). After determining the potential source WTRU candidates, the WTRU may report (e.g., a list of) the source WTRU candidates to the network (306).

[0097] The WTRU may receive, from the network, a FSU configuration including a list of FSUs (308). As 302, 304, and 302/304 (alt,) are optional, the list of FSUs may include FSUs determined by the network based on other information. Alternatively, the list of FSUs may include at least one FSU that corresponds to one of the source WTRU candidates reported by the WTRU.

[0098] Following receipt of the FSU configuration, the WTRU may configure itself based on the FSU configuration to operate as a FRU for the listed FSUs (310). The WTRU may, for example, configure itself to monitor downlink control information to determine uplink resource allocated to the FSUs. The WTRU may configure itself for monitoring the downlink control information using identities associated with the FSUs. These identities may be, for example, radio network temporary identifiers (RNTIs) associated with the FSUs. The identities associated with the FSUs may be received from any of the network and the FSUs (not shown). Alternatively, the FSU configuration list may include the identities associated with the FSUs.

[0099] In an embodiment, the WTRU may receive, from the network, an indication from which to determine a feedback scheme; and may configure the WTRU in accordance with the feedback scheme (not shown). The indication may be an explicit indication of the feedback scheme or an implicit indication of the feedback scheme. In an embodiment, the WTRU may receive information to provision itself with various feedback schemes, including the indicated transmission scheme (not shown).

[0100] Details of various other embodiments, and features of, along with alternatives, additions and complementary features to the procedure 400 are provided herein, such as follows.

[0101] Provided herein are methodologies and/or technologies by which FRUs are determined. Determination of a FRU may be carried out, in one embodiment, using a network-based selection procedure. Alternatively, a distributed mode selection procedure may be used.

[0102] Provided herein are methodologies and/or technologies for network-based (or assisted) selection of FRUs. In an embodiment, a FRU may be selected by the network (e.g., base station) using information provided by one or more WTRUs. Each potential FRU and/or source WTRU may send a list of potential candidates to the network/base station. For example, a potential FRU may send the list of potential source WTRU candidates to the network/base station. In another example, a potential source WTRU may send list of potential FRUs to the network/base station. The network/base station may then collect the information from possibly more than one FRU and/or source WTRU and further select one or more FRUs.

[0103] In an embodiment, each potential FRU and/or source WTRU may be configured to autonomously determine and send the list without receiving any explicit command from the network. The report may be performed (e.g., triggered and/or sent) periodically with a period size. The period size may be (pre)-configured in the potential FRU and/or source WTRU and/or signaled via RRC or higher layer signaling. In an embodiment, the potential FRU and/or source WTRU may be aperiodically triggered by the network/base station to report its list of candidates. Downlink control information (DCI), e.g., a DCI format, may be used for such purpose. The DCI format (e.g. a DCI format used to assign downlink resources or grant uplink resources), for example, may include a field used to (e.g., aperiodically) trigger the potential FRU and/or source WTRU to report its list of candidates. Such a trigger may include parameters on how to determine the list (e.g. resources in which the potential FRU and/or source WTRU may make required measurements or transmissions). Such a trigger may include parameters on how to report the list (e.g. uplink resources to be used by the one, or more, WTRU to indicate its (their) list to the network/base station).

[0104] In an embodiment, a potential FRU and/or source WTRU may report (or start reporting) the information after receiving an explicit request from the network/base station. The request sent by the network/base station might be in broadcast, multicast or unicast mode.

[0105] In determining the list of candidates, a potential FRU and/or source WTRU may consider any of the following criteria.

[0106] D2D WTRU Capability

[0107] A potential FRU and/or source WTRU may consider only WTRUs with D2D capability. For example, a potential FRU and/or source WTRU may listen to a sidelink channel and collect IDs of WTRUs that are using the sidelink channel. Alternatively, a potential FRU may indicate its potential status as a FRU, possibly in a transmission on the sidelink channel (e.g. via discovery transmission or other). A source WTRU may listen to the sidelink channel to collect the IDs of the potential FRUs that are transmitting an ability to be used as an FRU.

[0108] Measurements

[0109] Measurements performed by a potential FRU and/or source WTRU may include measuring the quality of D2D links in proximity. For example, a potential FRU and/or source WTRU may calculate a block error rate (BLER) of VoIP packets or the discovery packets received from the D2D WTRUs. Alternatively, a potential FRU and/or source WTRU may measure the quality of D2D synchronization signals. The quality may be a measure of the signal interference to noise ratio (SINR) of a synchronization or pilot signal. In an embodiment, the measurement may be pathloss for at least one D2D transmission. The transmission power used for transmissions may be fixed and/or known by receiving WTRUs. The receiving WTRUs may determine the pathloss from the transmitting WTRU, possibly by using the known transmission power and calculated received power.

[0110] WTRU Status

[0111] Potential FRUs that are available for relaying may be configured to broadcast a notification (e.g., a message) in a sidelink channel. This notification, which may be as small as a single bit, may depend on various statuses and/or states, such as buffer status and/or battery state, of the potential FRU. The buffer status may include all buffers or only a set of configured buffers (e.g. configured for high reliability traffic). Alternatively, the notification may depend on the potential FRU's ability to reliably transmit (e.g. transmit control information) to the base station. For example, the potential FRU may determine that it is not power limited and may reliably transmit aggregated PUCCH to the base station; in such a case, it may indicate availability for relaying.

[0112] The potential FRU and/or source WTRU may request respective uplink grants from the network/base station to send their lists. The potential FRU and/or source WTRU may also use the scheduled grants for WAN traffic. After receiving the reports, the network/base station may select the FRU for the source WTRU. The network/base station may inform the source WTRU of the selected FRU and/or may configure source WTRU to use the selected FRU. Whether the network/base station informs and/or configures the source WTRU, however, may depend on configured feedback scheme and/or method for forwarding the feedback information to the FRU. As an example, if the WTRU needs to establish a sidelink link with the FRU in accordance with the configured feedback scheme, then the WTRU may need to be aware of the identity of the FRU, in which case the network/base station may configure the source WTRU with the FRU identity.

[0113] A base station (e.g., an eNode-B in an LTE system) may send a multicast request to a set of WTRUs (e.g., potential source WTRUs) to start a procedure for selecting a FRU. The multicast request may be sent, for example, via a multicast control channel (MCCH) or via any of a PDCCH and PDSCH using a common RNTI. Following reception of the multicast request, the WTRUs may start measuring link quality using for example one or more of (i) qualities of D2DSS signals received from other WTRUs (e.g., potential FRUs); (ii) BLERs of D2D discovery messages received from other WTRUs; and (iii) BLERs of D2D communication messages received from other WTRUs.

[0114] After performing its measurements, each (or any) potential FRU and/or each (or any) potential source WTRU may select N candidates (potential source WTRU and/or potential FRUs, respectively) for its list. N may be pre-configured or signaled from the network. Alternatively, N may be autonomously determined by the potential FRU/potential source WTRU and indicated to the network/base station. The potential FRU/potential source WTRU may provide its list to the network/base station by reporting the N candidates using an uplink shared channel if the WTRU is already scheduled with a grant. The potential FRU/potential source WTRU may request uplink resources to transmit a new list of N candidates, e.g., based on some triggers. For example, when a possibly configurable number of candidates in the list (e.g. at least 1) has changed, the potential FRU/potential source WTRU may request resources to transmit a new list to the network/base station. In an embodiment, the potential FRU/potential source WTRU may be configured with periodic PUCCH resources on which it may report the list of N candidates regularly. In an embodiment, the potential FRU/potential source WTRU may (e.g., periodically) report the changes to the list and not the complete list of N candidates. The potential FRU/potential source WTRU, for example, may report any new candidate to be added to the list, and may indicate any candidates to remove from the list.

[0115] Following the responses from the potential FRU and/or potential source WTRUs, the network/base station may select the FRU. The network/base station may indicate the selection to one or more of the WTRUs. The network/base station may, for example, send a control command via a DCI format to a selected one and, if needed, to all potential FRU and/or all potential source WTRUs. Figure 4 illustrates an example of a procedure to facilitate and/or enable feedback- information relaying in accordance with the above approach.

[0116] Provided herein are methodologies and/or technologies for autonomously selection of one or more FRUs by WTRUs. In an embodiment, a base station may send to a WTRU a list of candidates to consider as possible FRUs. The WTRU may filter or otherwise not consider candidates on the list if the WTRU does not detect presence of such candidates (e.g., the candidates that the WTRU fails to detect are proximate to the WTRU or that are unreachable). By monitoring the discovery and/or communication messages, for example, the WTRU may remove from the list the candidates that are out of its coverage.

[0117] In an embodiment, the WTRU may use its own list. This list may be constructed based on measurements, for example. The WTRU may adopt a distributed procedure to generate the list. Pursuant to the distributed procedure, each participating WTRU may be configured to one or more of the following.

[0118] Send an announcement on D2D channel to indicate the support of feedback relaying service. Such an indication may also include a qualitative element. For example, a participating WTRU may indicate that it may be used as a FRU. It may also indicate any of: its feedback performance (for example, its ability to transmit to the base station); its available power for feedback and/or aggregated feedback; its available resources for feedback and/or aggregated feedback; its available payload for feedback and/or aggregated feedback; and a period of time for which it may operate as a FRU; whether it will use a RU, another FRU, or multiple other RUs and/or FRUs) to deliver the feedback information (e.g., in a multi-hop manner).

[0119] Set a timer with a pre-configured period to enable sensing process.

[0120] Listen to the other announcements in order to decode the conveyed information.

[0121] Compare its conditions with other candidates based on received announcements. For example, a participating WTRU may compare any of: channel quality and/or performance of its uplink feedback transmissions; its available power for feedback and/or aggregated feedback; its available resources for feedback and/or aggregated feedback; its available payload size for feedback and/or aggregated feedback; a period of time it is available for feedback and/or aggregated feedback; and a number of hops (or RUs or FRUs) to the base station.

[0122] Renounce or continue sending the announcement of supporting feedback relay feature depending on the comparison output. For example, a participating WTRU may determine that it has less resources available for aggregated feedback than another WTRU, therefore it may determine that the other WTRU may be a better candidate, and it may stop indicating its ability as a FRU. In an embodiment, a first participating WTRU may indicate to neighboring participating WTRUs that a second WTRU is a better FRU candidate, upon or responsive to determining in a comparison that the second WTRU might have better capabilities for aggregated feedback. In an embodiment, a first WTRU may indicate to a second WTRU that it will no longer indicate ability to be a FRU given that the second WTRU has better feedback capabilities. This may ensure that two WTRU do not simultaneously determine that the other is a better candidate, which may result in both WTRUs autonomously and simultaneously stop indicating support for being a FRU.

[0123] Provided herein are methodologies and/or technologies, including procedures and/or triggers, for selection and/or re-selection of the FRUs. In an embodiment, the feedback source WTRU (FSU) may be configured to select or reselect a FRU based on one or more of the following triggers:

[0124] Timer

[0125] In an embodiment, the FSU may be configured with a feedback relay selection timer. The feedback relay selection timer may be started when a new FRU is selected. When the timer expires, the FSU may be configured to perform another FRU selection procedure. In an embodiment, the FSU may be configured to perform FRU selection at fixed instant of time periodically (e.g., independently of a time at which the FSU selected a FRU). For example, this time may be based on a modulo operation of a system frame number (SFN) value or based on other common timer or count value.

[0126] Buffer

[0127] In an embodiment, the FSU may be configured to perform FRU selection/reselection based on a status of a buffer. As an example, the FSU may be configured to perform FRU selection/reselection when the buffer is empty and then gets new data and/or an amount of data in buffer satisfies (e.g., exceeds or falls below) a threshold. Such threshold may be pre- configured or dynamically configured. In another example, the FSU may be configured to perform FRU selection/reselection based on a status of a special buffer or a specific radio bearer. For example, the FSU may be configured with a buffer associated to a logical channel (or radio bearer) for which it may take advantage of a FRU (e.g. a high-reliability logical channel or bearer). FRU selection/reselection may be based on the status of this special buffer.

[0128] Radio measurement

[0129] The FSU may be configured to perform FRU selection/reselection based on one or more radio measurements. For example, the FSU may be configured to perform radio measurements to the FRU and determine to perform FRU selection/reselection when the quality of the radio link to the FRU satisfies (e.g., falls below or above) a threshold. Such threshold may be pre- configured or dynamically configured.

[0130] Handover (e.g.. to a Different Cell)

[0131] The FSU may be configured to perform FRU selection/reselection, for example, when it performs a handover. In an embodiment, the FSU may receive in a handover message from the network an explicit indication to change to a given FRU or to perform FRU selection/reselection.

[0132] Explicit message

[0133] The FSU may be further configured to perform FRU selection/reselection upon or responsive to reception of a specific indication from the network (e.g. from RRC or L1/L2 signaling). [0134] Provided herein are methodologies and/or technologies for configuring for use of, and/or using, multiple FRUs. A FSU may be configured to use multiple FRUs. For example, a FSU may transmit its feedback information (e.g., HARQ-ACK) on resources that multiple FRUs can receive. In an embodiment, one or more of the multiple FRUs may transmit the FSU's HARQ-ACK feedback message.

[0135] The FSU may use different FRUs per different HARQ-ACK feedback. The FRU selection per HARQ-ACK feedback may be explicitly indicated (possibly to both the FSU and FRU). For example, the FRU selection for a HARQ-ACK report may be indicated semi-statically (e.g. via higher layer signaling) or dynamically (e.g. within control information assigning downlink transmission)

[0136] In an embodiment, the selection of a FRU may be determined by the FSU (and possibly by the FRU) based on at least one of:

[0137] Subframe number, for example, if subframe sets assigned to different FRUs;

[0138] FRUs having an appropriate amount of (e.g., most) available battery power remaining;

[0139] FRUs (e.g., most) recently used;

[0140] a period of time since last being used as a FRU;

[0141] Best instantaneous channel quality, e.g., any combination of FSU to FRU channel quality, or FRU to base station channel quality (for example, the FRU with the most ACKs for its own downlink transmissions may be selected as having the best channel from (and/or to) the base station);

[0142] Random selection of a FRU from a list of possible FRUs; and

[0143] FRU with fewest required hops to a base station.

[0144] Provided herein are examples of actions by FSU(s), including actions by the FSUs upon and/or responsive to selection/reselection of FRU(s). In an embodiment, upon reselection to a second FRU from a first FRU, a FSU or the second FRU may be configured to send a release indication to the first FRU. This message may be carried over a PC5 interface (i.e. directly), for instance.

[0145] Alternatively, the FSU may send a message to the base station informing that it is no longer making use of the first FRU (potentially indicating a change to the second or another FRU, as applicable). The base station may be configured to transmit an explicit release or disconnect message to the first FRU. Upon reception of this message, the first FRU may be configured to stop monitoring for the FSU and stop relaying the information from that FSU.

[0146] Figure 5 is a flow diagram illustrating an example procedure 500 that may be implemented in a FRU for engaging in cooperative communications with one or more FSUs. The FRU may be configured by the network to support uplink feedback relaying for the FSUs. The FSU selected for such configuration may be based on candidates suggested by any of the FRU and FSUs. For example, the FRU may autonomously determine one or more source WTRU candidates; and reporting a list of the source WTRU candidates to the network. The network may select one or more of the candidates as the FSUs.

[0147] The FRU may monitor a downlink control channel to determine uplink resources allocated to the FSUs (502). The uplink resources allocated to the FSUs may include allocations for any of WTRU-to-BS and D2D transmissions. The uplink resources allocated to each FSU may be any of time, frequency and code resources.

[0148] The FRU may derive or ascertain the uplink resources allocated to the FSUs from downlink control information for the FSUs carried on the monitored downlink control channel. For example, the FRU may ascertain the uplink resources allocated to the FSUs from uplink grants (e.g., in downlink control information) for the FSUs carried on, and received in connection with monitoring, the downlink control channel. Alternatively and/or additionally, the FRU may determine downlink assignments for the FSUs by monitoring the downlink control channel, and then may derive the uplink resources allocated to the FSUs based on the downlink assignments for the FSUs. The FRU may use configured, known and/or agreed upon relationships between downlink assignments and uplink resource allocations to derive the uplink resource allocations. The FRU, for example, may derive the allocated uplink resources for any of the FSUs as (e.g., by applying) an offset in at least one of time, frequency and code from the corresponding downlink assignment for the FSU. In an embodiment, the FRU may use identities associated with the FSUs (e.g., RNTIs) or other differentiating information when monitoring the downlink control channel to discriminate (e.g., descramble) the downlink control information associated with the FSUs from other downlink control information. The identities associated with the FSUs may be RNTIs assigned to the FSUs. Although not shown, the FRU may receive the identities associated with the FSUs from any of the network and the FSUs. A FSU configuration list including the identities associated with the FSUs may be used, for instance. [0149] The FRU may ascertain the uplink resources allocated from downlink control information for the FRU carried on the monitored downlink control channel. The FRU, for example, may receive one or more indications (e.g., a list) of the uplink resources allocated to the FSUs specified by the network in downlink control information for the FRU, and received in connection with monitoring, the downlink control channel. The indications may be explicit. Alternatively, the indications may be specified as indices or other references from which to derive the uplink resources allocated to the FSUs. Akin to above, the FRU may use its identity (e.g., RNTI) or other differentiating information when monitoring the downlink control channel to discriminate the downlink control information associated with the FRU from other downlink control information.

[0150] After determining the uplink resources allocated to the FSUs, the FRU may monitor such resources (504). The FRU may obtain feedback information (e.g., in messages) received on the monitored uplink resources (506). The feedback information may be decoded from messages from the FSUs received on the monitored uplink resources. Alternatively, the feedback information may be obtained without decoding the messages. The feedback information obtained from the monitored resources may include non-FEC protected feedback information from each of the FSUs. The non-FEC protected feedback information from each of the FSUs may be as small as a single bit.

[0151] The FRU may encode the feedback information using FEC and/or other like-type coding (508) in connection with generating a FEC protected feedback message. The FRU may aggregate or otherwise combining the non-FEC protected feedback information from each of the FSUs prior to encoding the feedback information. In an embodiment, the FRU may, prior to encoding the feedback information, adapt the feedback information to include un-encoded feedback information of the WTRU. The FRU may, for example, aggregate or otherwise combine the non-FEC protected feedback information from each of the FSUs along with un-encoded feedback information of the WTRU.

[0152] The FRU may transmit the resulting FEC protected feedback message to a base station or network element (510). The resulting FEC protected feedback message may be transmitted using UL resources allocated to the WTRU for transmitting the resulting FEC protected feedback message. The FRU may monitor its downlink control information using its identity (or a special identity (i.e. RNTI) used for this purpose) to determine the UL resource allocated to the WTRU for transmitting the resulting FEC protected feedback message. [0153] The resulting FEC protected feedback message may include a header indicating the FEC protected feedback message includes the feedback from the FSUs and/or the FRU, if applicable.

[0154] Details of various embodiments, and features of, along with alternatives, additions and complementary features to the procedure 500 are provided herein, such as follows.

[0155] Provided herein are methodologies and/or technologies for transferring feedback messages to a FRU. In an embodiment, a FRU may monitor an uplink control channel of a WTRU, may decode ACK/NACK bit(s), and may relay the bit(s) to the base station. In an embodiment, the FRU may be configured to autonomously determine which uplink resources are currently used by the FSU (or equivalently "the WTRU"). In an embodiment, the base station may provide the FRU with an indication of the resources to be monitored.

[0156] In an embodiment, the FRU may be configured to monitor the downlink control signaling directly to determine the resources which will be used for HARQ protocol feedback transmission (502). The FRU may decode all uplink HARQ feedbacks (506) and transmit them to the base station (510). For example, in an LTE system, the FRU may continuously monitor a PDCCH to be aware of the assignment of HARQ feedback resources (502). HARQ feedback might be carried on a physical uplink shared channel (PUSCH) or a PUCCH depending on whether or not the FSU is scheduled with an uplink grant. The FRU may process the entire PDCCH (504). The FRU may be configured with the RNTIs of the FSU to enable descrambling of DCI.

[0157] In an embodiment, the base station may send to the FRU a list or other indication of uplink signaling resources that may be used for HARQ feedbacks by associated FSUs. This approach has an advantage that the FRU does not waste power and time in processing control messages of each FSUs to discover them, but monitors directly HARQ resources specified by the base station (502, 504). For example, in LTE systems, the base station (eNode-B) may be configured to send a downlink control information message to the FRU indicating (e.g., a list of) the resources to be monitored. The DCI message may indicate for each resource the corresponding type (whether it is on PUCCH or PUSCH) plus the indication within the physical channel. For acknowledgements carried on PUCCH, the indication may include any of: the phase rotation, a cover sequence, a resource block allocation, a PUCCH format, and the like. In case of HARQ feedback configured to be on PUSCH, the indication may include any of: a resource-block index, SC-FDMA symbol, modulation and cording rate, antenna port. [0158] In an embodiment, a FSU may use a direct link with the FRU (e.g. D2D link) to transmit its HARQ acknowledgement (for example, in addition to using the WTRU-to-base station link). The FSU, for instance, may autonomously select a D2D resource and may exchange signaling with the FRU to inform it about the scheduling assignment. As an example in LTE systems, the FSU may use unscheduled D2D communication. The FSU may select on its own the resource from a set of configured resources without being scheduled by the base station (eNode-B).

[0159] In an embodiment, the base station may assign the D2D resource between the FSU and the FRU to be used for HARQ acknowledgement. The base station may configure a special D2D resource pool for carrying only the feedback information or feedback control information. The resource pool periodicity may be small to support the latency requirement of the HARQ feedback. Thus, the FRU may forward it quickly.

[0160] In an embodiment, the FSU may not transmit any HARQ-ACK feedback to the base station and may only send its HARQ-ACK transmissions to a FRU (e.g. via D2D link(s)). The resources on which a FSU may transmit HARQ-ACK to the FRU may be semi-statically configured by a base station via higher layer signaling. Alternatively, the resources on which a FSU may transmit HARQ-ACK to a FRU may be dynamically indicated, possibly in a DCI assigning downlink resources. For example, an ACK-NACK Resource Indication field may have codepoints indicating to a FSU to use specific resources on a D2D link for HARQ-ACK feedback. Alternatively, the FSU may be indicated (possibly semi-statically) by a FRU the resources to use for HARQ-ACK feedback using that FRU.

[0161] A FSU may use a different power control scheme than the one used for uplink transmission to the base station, to reach and/or communicate with a FRU. The FSU may be configured to transmit with fixed power control scheme. The value for the fixed power control scheme may be signaled from the network or pre-configured in the FSU. Alternatively, the FSU may use the same power control scheme used for uplink transmission. As another alternative, the FSU may use a different power control scheme. For example, open loop power control (OLPC) may be adopted. Pathloss for the FSU-to-FRU channel may be calculated during the measurements. The OLPC parameters may be pre-configured in the FSU. Closed loop power control may also be used. The FSU may receive closed loop power control parameters in a downlink assignment from the base station. Alternatively, the FRU may transmit closed loop power control parameters to the FSU indirectly (e.g., via the base station) or directly (e.g. via a D2D link). [0162] Provided herein are methodologies and/or technologies for FRUs to forward feedback information. In an embodiment, a FRU may use the same resources used by a FSU to transmit the feedback information. For example, in LTE system, a FSU may be scheduled with a PUSCH grant to transmit data and HARQ feedback. Once the FSU starts transmitting, the FRU may decode the acknowledgement in the first OFDM symbol(s)/subframe(s) dedicated to HARQ feedback, and may start transmitting it in the remaining symbols in parallel with the FSU. Figure 6 illustrates an example of this overlay technique for PUSCH transmissions. It is understood that such overlay technique may be applicable to PUCCH transmissions, as well. Example details for configuring the FSU for overlay transmission may be found in U.S. Patent No. 9,054,760, which is incorporated herein by reference.

[0163] On the base station side, the received signals from the FSU and FRU may be combined for detection. The base station may use one or more pilot signals for channel estimation.

[0164] In an embodiment, the FSU and the FRU may use distinct pilot symbols and/or signals. The pilot signals from both of the FSU and FRU may be configured to be orthogonal. The FRU may determine its pilot symbol configuration, for example explicitly (i.e. signaled by the network), or implicitly for example based on the FSU pilot configuration or index. Implicit approaches may be advantageous because no addition signaling is needed between the base station and the FRU.

[0165] In an embodiment of implicit determination, the FRU may be configured to use the same pilot signal/symbols as the FSU. This may simplify channel estimation as the base station can perceive the two channels as one (i.e. with multipath/delay spread). In an embodiment, the FRU may use the same pilot configuration used for its regular uplink WAN traffic.

[0166] Provided herein are methodologies and/or technologies for determining uplink resources for relaying feedback information. In an embodiment, the FRU may be granted with an uplink grant to forward feedback information of one or multiple FSUs. The FRU may be configured by the network with an explicit grant configuration (e.g. via a PDCCH, or RRC signaling). Alternatively, the FRU may receive an explicit control signal indicating the resources for transmitting the FSUs' feedback on a dynamic (i.e. TTI by TTI) basis. The FRU may use the indicated resources to relay the feedback information. In an embodiment, the explicit control signal may be a new DCI format transmitted on the PDCCH.

[0167] In an embodiment, the FRU may determine its resources based on control signals associated to the FSU. The FRU, for example, may be configured to monitor or receive the control signal associated to the FSU. To facilitate this, the FRU may be configured, for example, from the network or from the FSU with the FSU's RNTI. The FRU may determine the resources for relaying the feedback information based on the received control signal associated to the FSU. In an embodiment, the FRU may determine the resources as a function of the (e.g. first) control channel element (CCE) used for carrying the FSU's PDCCH for downlink assignment.

[0168] A FRU may be configured to determine the subframes for which the FSU feedback information needs to be relayed. In an embodiment, the FRU may determine when the FSU transmits feedback information based on the FSU's associated downlink control channel. The FRU may monitor the downlink control channel associated to the FSU to determine when the FSU is supposed to receive a downlink assignment. The FRU may derive therefrom when the associated HARQ-ACK feedback is to be transmitted, and in turn, when it is to be relayed.

[0169] In an embodiment, the FRU may be configured with a semi-persistent configuration from the network indicating which subframes/resources to monitor for relaying feedback.

[0170] In an embodiment, when a FSU is transmitting HARQ-ACK via a FRU, the FSU may use a different timing relationship for its HARQ-ACK transmission. For example, the FSU configured with a FRU and assigned downlink resources in subframe n, may transmit HARQ-ACK to the FRU in the appropriate resources in subframe n+ki. k\ may be fixed, or indicated to the FSU, or may depend on a parameter of the downlink transmissions (e.g., k\ may depend on the subframe when the downlink transmission occurs, n). The WTRU may also transmit HARQ-ACK in subframe n+ki using another set of feedback resources. For example ki may be determined by the duplexing type (FDD or TDD) and may use timing to transmit HARQ-ACK to the base station (e.g.

for FDD). The FRU receiving HARQ-ACK in subframe n+ki may decode the feedback value, possibly multiplex it with other HARQ-ACK feedback values (possibly for its own downlink transmissions or that of other source WTRUs) and may transmit the aggregated feedback in subframe n+ki+h. h may be fixed or configured by the base station and may depend on at least one of: whether FDD or TDD is used, the subframe where a FRU received the HARQ-ACK (i.e. subframe n+ki), a subframe where aggregated feedback may be transmitted, etc. A subframe where aggregated feedback may be transmitted may be determined by a set of resources configured by the base station for the FRU. The FRU, for example, may accumulate all relevant HARQ-ACKs it has received since a previous available aggregated feedback subframe, and may multiplex all such accumulated HARQ-ACKs into a next available feedback subframe. [0171] Provided herein are methodologies and/or technologies for encoding relay feedback signals and/or messages. In an embodiment, a FRU may be configured to receive feedback information to relay from one or more FSUs. The FRU may be configured to receive, demodulate and decode one or more feedback messages, and then aggregate the received feedback messages, possibly with its own feedback message, re-encode (possibly using a different code), and then transmit to the network. Figure 7 illustrates example architecture of a FRU configured to carry out this approach as well as (and/or in accordance with) procedure 500 of Figure 5 and/or the approach shown in Figure 6.

[0172] A coding gain may be realized using the illustrated approach as a result of being able to use longer codes. Unlike 1 bit feedback information (e.g. HARQ ACK), coding gains from additional redundancy bits may be realized using the aggregated message containing multiple bits. Figure 8 illustrates example gains that can be obtained from such coding. At least four observations can be made for the simulated cases. First, a coding gain can be observed when the Eb/No is above 3dB. Second, the (63, 36) code can provide a 2dB gain over no-coding at a BER of 10^"3. Third, shorter codes have marginal gains when the Eb/No is above 6dB. Fourth, coding may lead to losses at low Eb/No, depending on the situation. These observations may lead to a conclusion that to support an efficient aggregated feedback mechanism, the coding technique used may be flexible and/or optimized for every situation.

[0173] Note that while a significant coding gain can be obtained with larger number of feedback message bits, the approach may nonetheless be valid for shorter number of feedback bits as at a minimum the communication will benefit from the relay and independent fading gain. Also note that the codes for each scenario may be designed offline, for example based on existing codes. This could be carried out via analysis and simulations, based on a specific target error rate.

[0174] In one example, the FRU may be configured to aggregate the feedback message(s) from the possibly multiple FSUs and its own feedback message. The FRU may be configured to encode the resulting aggregated message. The FRU might be configured to only transmit to the base station a subset of the encoded aggregated message. The FRU may transmit, for example, a set of possibly pre-defined parity bits. In one particular example of this approach, the FRU does not transmit the systematic bits from the encoder, and only transmits one or more of the parity bits. This approach, combined with the FSUs transmitting their feedback messages to the base station, has the potential coding gain benefits when compared to simple repetition and/or retransmission of the systematic bits.

[0175] A FRU configured to relay feedback messages from multiple FSUs may be configured to use a different coding scheme depending on a number of feedback message bits to transmit to the network. In an embodiment, the FRU may be configured with a set of modulation and coding schemes and associated transport formats (herein collectively referred to as transmission scheme) associated to the transmission possibilities or to the number of feedback messages it has to carry. The FRU may determine the transmission scheme based on one or more of the number of feedback relay messages, the total number of feedback bits to transmit, number of FSUs, etc.

[0176] In an embodiment, the FRU may use a semi-static transmission scheme. Such transmission scheme may be configured, for example, via RRC configuration. Alternatively, transmission scheme may be configured (or fixed) based on a number of FSUs for which the FRU provides relay services. In an embodiment, the FRU may use the most appropriate transport scheme based on the aggregated feedback message it has to transmit at a specific subframe. In such cases, the base station may be configured to blindly determine the receive transmission scheme, for example, from a list of possible transport schemes.

[0177] The FRU may be configured to determine the transmission scheme based on the number of feedback bits to transmit. In an embodiment, the FRU may be configured to not use encoding, for example when the number of bits is too low. Table 1 below lists example of transmission schemes in connection with a number of feedback bits to be transmitted.

Table 1 : Example Transmission Scheme Table

[0178] Table 2 below lists a more specific set of transmission schemes in connection with a number of coded bits that may be provided.

Number of feedback bits Transmission Scheme Transport Block Sizes 1 No coding, BPSK 1

2-16 No coding, QPSK 2, 4, 16

17-50 Block Code rate 1/2, QPSK 32, 48, 64, 96

50-100 Convolution Code rate 1/2 QPSK 100, 150, 200

>100 Turbo Code, rate 1/2 QPSK 300

Table 2: Example Transmission Scheme and TBS Table

[0179] In an embodiment, a FRU may be configured to determine to use a L2 signaling scheme (e.g. in a MAC CE) for carrying the aggregated message. This approach may appropriate to use when supporting variable aggregated feedback message sizes, and in general, messages of a larger size notwithstanding that such approach may lead to additional overhead and potential increase in latency over other approaches. In an embodiment, the FRU may be configured to determine to use a MAC CE to carry the aggregated feedback message based on any of (i) whether the number of bits in the aggregated feedback message is above a preconfigured threshold; whether the number of FSUs is above a preconfigured threshold; (ii) whether the FRU is transmitting uplink data in the subframe where the feedback message would be transmitted; and (iii) whether the aggregated feedback message latency requirement can be met with transmission over a MAC CE.

[0180] In an embodiment, the FRU may be configured with a special power offset and coding for transmission carrying a L2 aggregated feedback message such that HARQ retransmissions are minimized or simply not needed. For example, a power boost value may be configured to be applied for uplink transmissions carrying aggregated feedback messages. In an embodiment, the WTRU may be configured to only transmit aggregated feedback messages in a subframe with a configured power boost value.

[0181] Provided herein are methodologies and/or technologies for associating individual feedback messages of an aggregated feedback message to the corresponding FSUs. When a FRU supports multiple FSUs, the aggregated feedback message may carry feedback messages from more than one FSU. Accordingly, the network needs to be able to associate each feedback message from the aggregated feedback message to the respective FSUs. This may be achieved when both the FRU and the network know which FSUs are associated to each feedback information combined into the aggregated feedback message.

[0182] Provided herein are methodologies and/or technologies for indicating FSUs to a network. In an embodiment, the FRU may indicate to the base station (or network) a list of feedback FSUs it is relaying feedback messages from. The FRU and FSUs may be configured to communicate to each other (e.g. via a first set of discovery messages or simple handshake mechanism) before the FRU relays the feedback messages to the network. The FRU may learn the identity of the FRU and may indicate it to the network. The FRU may order the feedback messages in order of connection, for instance. As an example, the last feedback message in the aggregated feedback message may be associated to the last FSU that connected to the FRU. Alternatively, the "position" of this new FSU within the list of FSUs currently connected to the FRU may be indicated to the network.

[0183] Provided herein are methodologies and/or technologies for indicating FSUs to FRUs. In an embodiment, the FRU may be configured by the network with a list of FSUs, and the FRU may be configured to transmit the feedback message for each of the FSUs based on the order listed on the configured list of FSUs. Such a configuration may be semi-static. The FRU, for example, may receive periodic or aperiodic updates to the list, possibly via higher layer signaling. In an embodiment, the configuration may be dynamic. The FRU, for example, may monitor a control channel and may detect and decode a DCI from the base station indicating the set of FSUs for which it should feedback HARQ-ACK in a specific and/or upcoming feedback resource.

[0184] In an embodiment, the control information assigning downlink resources to the FSUs may include an identifier. When transmitting their HARQ-ACK feedback to the FRU, the FSUs may include the identifier. The FRU may use the identifier (possibly in conjunction with other parameters tied to each transmission or to specific FSUs, such as source WTRU ID) to determine the appropriate set of FSUs (and HARQ-ACK bits) the FRU is supposed to transmit.

[0185] Figure 9 illustrates an example of an aggregated feedback message 900. The aggregated feedback message 900 may include the feedback message of the FRU 904 and feedback messages from all associated and/or connected FSUs 906. One issue with using the aggregated feedback message 900 is that it may not be robust to signaling error. If, for example, the network schedules one FSU, but the FSU does not receive the DCI properly, then the network may not be capable of interpreting the aggregated feedback message properly. In a case where the FRU receives the DCI, but fails to receive feedback message (HARQ feedback) from the FSU (such as a result of the FSU not receiving the DCI correctly), then the FRU may be configured to set the corresponding feedback bit to "NACK" or "0" in the aggregated feedback message. That is, for example, to protect against signaling errors, the FRU may be configured (e.g., via RRC or semi-statically) to transmit the full aggregated feedback message, regardless of dynamic DCI/HARQ information being received.

[0186] Figures 10A and 10B illustrate examples of an aggregated feedback message 1000. The aggregated feedback message 1000 may be similar to the aggregated feedback message 900 of Figure 9, except that aggregated feedback message 1000 may include a header 1002. The header 1002 may include, for example, one bit for each of the FSU plus one for the FRU. Each bit in the header 1002 may indicate, for example, whether or not the feedback message for the associated FSU contains valid data. The FRU may be configured to set the invalid feedback message bits to a specific value (e.g. all zeros). This approach allows the FRU to indicate dynamically which of the fields contain data associated to a valid feedback message. For example, if the FRU does not detect a feedback message from one of the FSUs in a subframe, then the FRU may simply set the associated bit in header to zero and set all associated feedback message bits to 0 or padding (e.g., as shown in Figure 10B).

[0187] Figures 11A and 11B illustrate examples of an aggregated feedback message 1100. The aggregated feedback message 1100 may include a header 1102, the feedback message of the FRU 1104 and feedback messages from associated and/or connected FSUs without padding used for missing feedback messages 1106. The FRU may be configured to indicate the presence/absence of feedback messages via the header 1108. For example, if the FRU does not detect a feedback message from one of the FSUs in a subframe, then the FRU may set the associated bit in the header to zero (e.g., as shown in Figure 11B), and/or may not transmit the associated feedback message or padding.

[0188] For the case where each downlink assignment includes an identifier, a FRU may determine the appropriate order it may use to aggregate the FSUs' HARQ-ACKs. In an embodiment, a FRU may determine any lacking HARQ-ACK feedback, based on a missing identifier. In such a case, the FRU may be configured to not attempt to receive any HARQ-ACK feedback from one or more configured FSUs for which no identifier where received on the downlink assignment. The FRU may then use any of the above aggregated feedback messages to transmit information on a lack of a feedback from one or more FSUs, or alternatively, it may include a NACK in an appropriate location (e.g., in the HARQ feedback message corresponding to the appropriate FSUs).

[0189] Provided herein are example FRU initiation and termination related procedures. To terminate feedback messages relaying, a FRU may be configured by the network with an explicit termination command. In an embodiment, the FRU may receive an explicit control signal or termination command indicating the subframe number on which the FRU must stop relaying. In an embodiment, the FRU may be configured to immediately stop relaying after receiving the command from the network and then terminate relaying feedback procedures.

[0190] In an embodiment, the FRU may be configured by the FSU with an explicit command. The FSU may be configured to use D2D (e.g. over PC5 interface) communication /control channel to send the termination command.

[0191] A FRU may be configured to autonomously terminate relaying feedback procedures using one or more of the following approaches:

[0192] The FRU may be configured to autonomously determine when to terminate relaying feedback procedures. In an embodiment, the FRU may monitor the presence/absence of the downlink control channel associated to the FSU. The FRU may be configured to terminate relaying feedback procedures based on an inactivity timer. In an embodiment, if the FRU does not detect control signaling intended to the FSU for a (pre)-configured period of time, the FRU may terminate relaying feedback procedures.

[0193] In an embodiment, the FRU may be configured to terminate relaying feedback procedures based on one or more measurements of the channel to the FSU. In an embodiment, the FRU may terminate relaying procedures when the estimated channel quality (e.g. the estimate may be obtained by measuring the quality of the discovery signal, DMRS, D2DSS or other signal) falls below a (pre-)configured threshold.

[0194] In an embodiment, the FRU may be configured to monitor the D2D transmitted messages (e.g. discovery or other data) of the FSU. If, for example, the FRU does not detect messages (e.g. for a specific duration or period of time), then the FRU may terminate relaying feedback procedures.

[0195] When a FRU terminates a relaying feedback procedure, the FRU may perform one or more of the following:

[0196] stop monitoring the feedback from the FSU;

[0197] stop monitoring FSU associated downlink control channel and release (but not necessarily delete) all information (e.g. RNTI or other) associated to that FSU;

[0198] stop relaying feedback signals associated to the FRU for which termination procedure is triggered; and [0199] indicate to the network that the relaying of feedback information from the FSU has terminated.

[0200] Example Relay/Feedback Relay WTRU Architecture

[0201] A WTRU configured as a RU and/or a FRU may be equipped with specialized hardware, and/or firmware along with applicable software, if any, to receive signals from the one or more FSUs. In an embodiment, the FRU may be have one or more receiver chains tuned to the uplink frequency of the FSUs. The receiver chains may be designed to receive and demodulate (for example, one or more single-carrier OFDM) uplink signals from different FRUs. As compared to a WTRU configured in accordance with LTE (up to and including 3 GPP Release 12 (R12)), the FRU may include additional elements, including one or more of the following: signal-processing elements and logic, one or more additional receiver chains (which may include one or more of a low-noise amplifier, local oscillator, analog-to-digital converters, RF filters (such as duplexer), etc.), logic and processor to encode aggregated feedback information and one or more additional antennas. In one option, hardware for D2D functionality (e.g. as in LTE R12, for example) may be used in part to this end. The FSU may also require special hardware, depending on implementation. For example if the protocol requires support for bi-directional D2D communications, the FSU may then also require special hardware to support D2D functionality, just as described for the FRU.

[0202] Conclusion

[0203] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0204] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" may mean any of a snapshot, single image and/or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described supra; (ii) any of a number of embodiments of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described supra; or (iv) the like. Details of an example WTRU, which may be representative of any UE recited herein, are provided below with respect to Figures 1 A-1E and 2.

[0205] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0206] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0207] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit (CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0208] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0209] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM")) or non-volatile (e.g., Read-Only Memory (ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0210] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.

[0211] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost vs. efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

[0212] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.). [0213] Those skilled in the art will recognize that it is common within the art to describe devices and/or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity, control motors for moving and/or adjusting components and/or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

[0214] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

[0215] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

[0216] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0217] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0218] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0219] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112, ]f 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

Claims

CLAIMS What is claimed is:

1. A method, implemented in a wireless transmit/receive unit (WTRU), for engaging in cooperative communications with one or more feedback-source WTRUs (FSUs), the method comprising: monitoring downlink control information to determine uplink resources allocated to the FSUs; monitoring the UL resources allocated to the FSUs;

obtaining feedback information received on the monitored uplink resources;

encoding the feedback information using forward error correction (FEC) coding; and transmitting a resulting FEC protected feedback message to a base station.

2. The method of claim 1, wherein obtaining the feedback information comprises: receiving messages from the FSUs on the monitored uplink resources, and decoding the received messages.

3. The method of any of the claims 1-2, further comprising: aggregating the obtained feedback information prior to encoding.

4. The method of any of the claims 1-2, further comprising:

prior to encoding, adapting the feedback information to include un-encoded feedback information of the WTRU.

5. The method of claim 4, wherein adapting the feedback information comprises: aggregating the obtained feedback information along with un-encoded feedback information of the WTRU.

6. The method of any of claims 1-5, wherein transmitting the resulting FEC protected feedback message comprises: transmitting the resulting FEC protected feedback message to the base station using uplink resources allocated to the WTRU for transmitting the resulting FEC protected feedback message.

7. The method of claim 6, further comprising:

monitoring downlink control information using an identity associated with the WTRU to determine the uplink resource allocated to the WTRU for transmitting the resulting FEC protected feedback message.

8. The method of any of the claims 1-7, wherein monitoring downlink control information comprises monitoring any of a physical downlink control channel (PDCCH) and an enhanced PDCCH (ePDCCH).

9. The method of any of the claims 1-8, wherein monitoring downlink control information to determine uplink resources allocated to the FSUs comprises:

monitoring the downlink control information using identities associated with the FSUs to determine the uplink resource allocated to the FSUs.

10. The method of claim 9, further comprising: receiving the identities associated with the FSUs from any of a network and the FSUs.

11. The method of claim 9, further comprising: receiving, from a network, a FSU configuration list including the identities associated with the FSUs.

12. The method of any of the claims 1-8, further comprising:

autonomously determining one or more source WTRU candidates; and

reporting a list of the source WTRU candidates to the network.

13. A WTRU configured for enhancing reliability of network reception of feedback sourced from one or more feedback-source WTRUs (FSUs), the WTRU comprising circuity, including a processor and memory storing instructions executable by the processor, configured to:

monitor downlink control information to determine uplink resources allocated to the FSUs; monitor the UL resources allocated to the FSUs;

obtain feedback information received on the monitored uplink resources;

encode the feedback information using forward error correction (FEC) coding; and transmit a resulting FEC protected feedback message to a base station.

14. The WTRU of claim 13, wherein the circuitry is configured to obtain the feedback information by at least receiving messages from the FSUs on the monitored uplink resources, and decoding the received messages.

15. The WTRU of any of the claims 13-14, wherein the circuitry is further configured to: aggregate the obtained feedback information prior to encoding.

16. The WTRU of any of the claims 13-14, wherein the circuitry is further configured to:

prior to encoding, adapt the feedback information to include un-encoded feedback information of the WTRU.

17. The WTRU of claim 16, wherein the circuitry is configured to adapt the feedback by, at least, aggregating the obtained feedback information along with un-encoded feedback information of the WTRU.

18. The WTRU of any of the claims 13-17, wherein the circuity is configured to transmit the resulting FEC protected feedback message to the base station using uplink resources allocated to the WTRU for transmitting the resulting FEC protected feedback message.

19. The WTRU of claim 19, wherein the circuitry is further configured to:

monitor downlink control information using an identity associated with the WTRU to determine the UL uplink resources allocated to the WTRU for transmitting the resulting FEC protected feedback message.

20. The WTRU of any of the claims 13-19, wherein the circuitry being configured to monitor downlink control information comprises the circuitry being configured to monitor any of a physical downlink control channel (PDCCH) and an enhanced PDCCH (ePDCCH).

21. The WTRU of any of the claims 13-20, wherein the circuitry is configured to:

monitor the downlink control information using identities associated with the FSUs to determine the uplink resource allocated to the FSUs.

22. The WTRU of claim 21, wherein the circuity is further configured to receive the identities associated with the FSUs from any of a network and the FSUs.

23. The WTRU of claim 21, wherein the circuity is further configured to receive, from a network, a FSU configuration list including the identities associated with the FSUs.

24. The WTRU of any of the claims 13-23, wherein the circuity is further configured to:

autonomously determine one or more source WTRU candidates; and

report a list of the source WTRU candidates to the network.

25. The method of any of the claims 1-12 or the WTRU of any of the claims 13-24, wherein the monitored uplink resources comprise resources for (i) device-to-device (D2D) communications between the WTRU and the FSUs, and (ii) transmissions from the FSUs to the base station.

26. The method of any of the claims 1-12 and 25 or the WTRU of any of the claims 13-24 and 25, wherein the obtained feedback information comprises non-FEC protected feedback information from each of the FSUs.

27. The method of any of the claims 1-12 and 25-26 or the WTRU of any of the claims 13-24 and 25-26, wherein the obtained feedback information comprises non-FEC protected feedback information from each of the FSUs, and wherein the non-FEC protected feedback information from each of the FSUs is as small as a single bit.

28. The method of any of the claims 1-12 and 25-27 or the WTRU of any of the claims 13-24 and 25-27, wherein the feedback information comprises hybrid automatic repeat request (HARQ) feedback.

29. The method of any of the claims 1-12 and 25-28 or the WTRU of any of the claims 13-24 and 25-28, wherein the resulting FEC protected feedback message comprises a header indicating the FEC protected feedback message includes the feedback information from the FSUs.

30. The method of any of the claims 4-12 and 25-28 or the WTRU of any of the claims 16-24 and 25-28, wherein the resulting FEC protected feedback message comprises a header indicating the FEC protected feedback message includes the feedback information from the FSUs and the WTRU.

31. A method, implemented in a wireless transmit/receive unit (WTRU), for engaging in cooperative communications with one or more feedback-source WTRUs (FSUs), the method comprising:

receiving, from a network, a FSU configuration including a list of FSUs; and

configuring the WTRU, based on the FSU configuration, to operate as a feedback relay WTRU

(FRU) for the FSUs, including configuring the WTRU to monitor downlink control information to determine uplink resource allocated to the FSUs.

32. The method of claim 31, wherein configuring the WTRU to monitor downlink control information to determine uplink resources allocated to the FSUs comprises:

configuring the WTRU for monitoring the downlink control information using identities associated with the FSUs to determine the uplink resource allocated to the FSUs.

33. The method of claim 32, further comprising: receiving the identities associated with the FSUs from any of the network and the FSUs.

34. The method of any of the claims 31-33, further comprising:

autonomously determining one or more source WTRU candidates; and

reporting a list of the source WTRU candidates to the network.

35. A WTRU comprising circuity, including a processor and memory storing instructions executable by the processor, configured to:

receive, from a network, a FSU configuration including a list of one or more feedback-source WTRUs (FSUs); and

configure the WTRU, based on the FSU configuration, to operate as a feedback relay WTRU (FRU) for the FSUs, including configuring the WTRU to monitor downlink control information to determine uplink resource allocated to the FSUs.

36. The WTRU of claim 35, wherein configuring the WTRU to monitor downlink control information to determine uplink resources allocated to the FSUs comprises:

37. The WTRU of claim 36, wherein the circuity is further configured to: receive the identities associated with the FSUs from any of the network and the FSUs.

38. The WTRU of any of the claims 35-37, wherein the circuitry is further configured to:

autonomously determine one or more source WTRU candidates; and

report a list of the source WTRU candidates to the network.

39. The method of any of the claims 31-34 or the WTRU of any of the claims 35-38, wherein the FSU configuration list includes the identities associated with the FSUs.

40. The method of claim 12 and 34 or the WTRU of claim 22 and 38, wherein at least one of the FSUs corresponds to a respective at least one of the source WTRU candidates.

41. The method of claim 12 and 34 or the WTRU of claim 22 and 38, wherein none of the FSUs correspond to the source WTRU candidates.

42. The method of any of the claims 10-12, 32-33 and 41 or the WTRU of any of the claims 22- 24, 36-37 and 41, wherein the identities associated with the FSUs comprise radio network temporary identifiers (RNTIs) associated with the FSUs.