CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

61/818,854, filed May, 2, 2013, the contents of which are incorporated by reference herein.

BACKGROUND

[0002] Multi-hop WiFi systems may be used to improve coverage and capacity over a single access point (AP) system. A multi-hop WiFi system may use relay APs and/or relay type stations (STAs) to improve channel conditions for STAs, which otherwise may suffer with bad channel conditions or coverage. In a relay based WiFi system, a STA receiving management frames (e.g., beacon frames, probe response frames, etc.) from a relay AP may not have adequate information of the overall relay path. The STA, for example, may not have information about the link between the root AP and the relay AP. A root AP may not have information about the link between, for example, a relay AP and a destination STA. SUMMARY OF THE INVENTION

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] Systems, methods, and instrumentalities are disclosed for a station to determine a link quality. For example, a station (STA) may determine the quality of a path that includes a relay node by determining a link quality associated with each link in the path. The STA may receive a transmission indicating that a transmitting entity is a relay node. The transmission may be a beacon frame, a short beacon frame, a probe response frame, etc. A relay device (e.g., a WTRU) may be a dedicated relay or other device (e.g., a station acting as a relay, an access point (AP) acting as a relay, or a non-station such as a station acting as an AP acting as a relay). The transmission may indicate a first link quality associated with a link between the relay node and a root access point (AP). The root AP may be a destination node associated with data to be transmitted by the STA. The STA may determine a second link quality associated with a link between the (STA) and the relay node, e.g., the STA may estimate the second link quality by measuring a metric of the transmission. The STA may determine a total link quality associated with a combined link from the STA to the relay node to the root AP.

[0005] The STA may select an entity to associate with based on the total link quality.

The STA may use the total link quality to determine whether to send data to the root AP via the relay or to send data to the root AP directly. For example, the STA may determine whether the total link quality satisfies a requirement (e.g., whether the total link quality is better than the quality of a link between the STA and the root AP, whether the total link quality is above a threshold such as a SNR threshold, etc.). The STA may select to associate with the relay node in order to transmit to the root AP when the total link quality satisfies the requirement.

[0006] The indication that the transmitting entity is a relay node may be explicit or implicit. An exemplary explicit indication that the transmitting entity is a relay node may be an explicit signal via an information element. An exemplary implicit indication that the transmitting entity is a relay node may be the first link quality being present in a frame of the transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0008] FIG. 1A depicts an exemplary communications system.

[0009] FIG. IB depicts an exemplary wireless transmit/receive unit (WTRU).

[0010] FIG. 1C depicts exemplary wireless local area network (WLAN) devices.

[0011] FIG. 2 depicts an example of relay architecture in IEEE 802.1 lah.

[0012] FIG. 3 depicts an example of a downlink relay (e.g., from an AP to a STA) with explicit ACK.

[0013] FIG. 4 depicts an example of an uplink relay (e.g., from a STA to an AP) with explicity ACK.

[0014] FIG. 5 depicts an example

[0015] FIG. 6 depicts an example

[0016] FIG. 7 depicts an example

source node.

[0017] FIG. 8 depicts an example of relay path selection in case of one or more relay nodes and a source node.

[0018] FIG. 9 depicts an example of a frame format of a transmission, where a Frame

Control field bit may indicate whether the Link quality between Relay and Root-AP is present.

[0019] FIG. 10 depicts an example of a frame format of a transmission, where the

Link quality between Relay and Root-AP may be provided by an information element (IE).

[0020] FIG. 1 1 depicts an example of a frame format of a flow control notification frame that may signal the address of a relay node.

[0021] FIG. 12 depicts an example of a frame format of a flow control notification element format of the exemplary flow control element illustrated in FIG. 1 1.

[0022] FIG. 13 depicts an example of a simplified flow control notification element format.

[0023] FIG. 14 depicts an example of a frame format of a flow control notification frame that may signal the address of the destination node.

[0024] FIG. 15 depicts an example of a frame format of a flow control notification element format of the exemplary flow control element illustrated in FIG. 14. [0025] FIG. 16 depicts an example of transmission opportunity (TXOP) operation with explicit ACK.

[0026] FIG. 17 depicts an example of TXOP operation with implicit ACK.

DETAILED DESCRIPTION

[0027] A detailed description of illustrative embodiments will now be described with reference to the various figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application. In addition, the figures may illustrate one or more message charts, which are meant to be exemplary. Other embodiments may be used. The order of the messages may be varied where appropriate. Messages may be omitted if not needed, and, additional messages may be added.

[0028] FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed features may be implemented. For example, a wireless network (e.g., a wireless network comprising one or more components of the communications system 100) may be configured such that bearers that extend beyond the wireless network (e.g., beyond a walled garden associated with the wireless network) may be assigned QoS characteristics.

[0029] 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.

[0030] As shown in FIG. 1A, the communications system 100 may include at least one wireless transmit/receive unit (WTRU), such as a plurality of WTRUs, for instance WTRUs 102a, 102b, 102c, and 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 1 12, though it should 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.

[0031] The communications systems 100 may also include a base station 1 14a and a base station 114b. Each of the base stations 114a, 1 14b 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 1 10, and/or the networks 112. By way of example, the base stations 1 14a, 1 14b 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 1 14a, 1 14b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0032] 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 1 14a 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 1 14a 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.

[0033] The base stations 1 14a, 1 14b may communicate with one or more of the

WTRUs 102a, 102b, 102c, 102d over an air interface 1 16, 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).

[0034] 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 1 14a 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).

[0035] 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 1 16 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0036] In other embodiments, the base station 1 14a 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.

[0037] The base station 114b in FIG. 1A 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 1 14b 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 FIG. 1 A, the base station 1 14b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 1 10 via the core network 106.

[0038] 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 FIG. 1A, it should 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.

[0039] The core network 106 may also serve as a gateway for the WTRUs 102a,

102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 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 1 12 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 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.

[0040] 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 FIG. 1A may be configured to communicate with the base station 1 14a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

[0041] FIG. IB depicts an exemplary wireless transmit/receive unit, WTRU 102.

WTRU 102 may be used in one or more of the communications systems described herein. As shown in FIG. IB, the WTRU 102 may include a processor 1 18, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0042] 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 1 18 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 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 1 18 and the transceiver 120 as separate components, it should be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0043] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) 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 should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0044] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO 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.

[0045] 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.

[0046] 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 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only 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).

[0047] 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 ( Zn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0048] 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 1 16 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 should be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0049] 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.

[0050] FIG. 1C illustrates exemplary wireless local area network (WLAN) devices.

One or more of the devices may be used to implement one or more of the features described herein. The WLAN may include, but is not limited to, access point (AP) 102, station (STA) 1 10, and STA 112. STA 1 10 and 1 12 may be associated with AP 102. The WLAN may be configured to implement one or more protocols of the IEEE 802.11 communication standard, which may include a channel access scheme, such as DSSS, OFDM, OFDMA, etc. A WLAN may operate in a mode, e.g., an infrastructure mode, an ad-hoc mode, etc. [0051] A WLAN operating in an infrastructure mode may comprise one or more APs communicating with one or more associated STAs. An AP and STA(s) associated with the AP may comprise a basic service set (BSS). For example, AP 102, STA 110, and STA 1 12 may comprise BSS 122. An extended service set (ESS) may comprise one or more APs (with one or more BSSs) and STA(s) associated with the APs. An AP may have access to, and/or interface to, distribution system (DS) 1 16, which may be wired and/or wireless and may carry traffic to and/or from the AP. Traffic to a STA in the WLAN originating from outside the WLAN may be received at an AP in the WLAN, which may send the traffic to the STA in the WLAN. Traffic originating from a STA in the WLAN to a destination outside the WLAN, e.g., to server 118, may be sent to an AP in the WLAN, which may send the traffic to the destination, e.g., via DS 116 to network 1 14 to be sent to server 1 18. Traffic between STAs within the WLAN may be sent through one or more APs. For example, a source STA (e.g., STA 1 10) may have traffic intended for a destination STA (e.g., STA 1 12). STA 110 may send the traffic to AP 102, and, AP 102 may send the traffic to STA 112.

[0052] A WLAN may operate in an ad-hoc mode. The ad-hoc mode WLAN may be referred to as independent basic service set (IBBS). In an ad-hoc mode WLAN, the STAs may communicate directly with each other (e.g., STA 1 10 may communicate with STA 1 12 without such communication being routed through an AP).

[0053] IEEE 802.1 1 devices (e.g., IEEE 802.1 1 APs in a BSS) may use beacon frames to announce the existence of a WLAN network. An AP, such as AP 102, may transmit a beacon on a channel, e.g., a fixed channel, such as a primary channel. A STA may use a channel, such as the primary channel, to establish a connection with an AP.

[0054] STA(s) and/or AP(s) may use a Carrier Sense Multiple Access with Collision

Avoidance (CSMA/CA) channel access mechanism. In CSMA/CA a STA and/or an AP may sense the primary channel. For example, if a STA has data to send, the STA may sense the primary channel. If the primary channel is detected to be busy, the STA may back off. For example, a WLAN or portion thereof may be configured so that one STA may transmit at a given time, e.g., in a given BSS. Channel access may include RTS and/or CTS signaling. For example, an exchange of a request to send (RTS) frame may be transmitted by a sending device and a clear to send (CTS) frame that may be sent by a receiving device. For example, if an AP has data to send to a STA, the AP may send an RTS frame to the STA. If the STA is ready to receive data, the STA may respond with a CTS frame. The CTS frame may include a time value that may alert other STAs to hold off from accessing the medium while the AP initiating the RTS may transmit its data. On receiving the CTS frame from the STA, the AP may send the data to the STA.

[0055] A device may reserve spectrum via a network allocation vector (NAV) field.

For example, in an IEEE 802.11 frame, the NAV field may be used to reserve a channel for a time period. A STA that wants to transmit data may set the NAV to the time for which it may expect to use the channel. When a STA sets the NAV, the NAV may be set for an associated WLAN or subset thereof (e.g., a BSS). Other STAs may count down the NAV to zero. When the counter reaches a value of zero, the NAV functionality may indicate to the other STA that the channel is now available.

[0056] The devices in a WLAN, such as an AP or STA, may include one or more of the following: a processor, a memory, a radio receiver and/or transmitter (e.g., which may be combined in a transceiver), one or more antennas (e.g., antennas 106 in FIG. 1), etc. A processor function may comprise one or more processors. For example, the processor may comprise one or more of: a general purpose processor, a special purpose processor (e.g., a baseband processor, a MAC processor, etc.), a digital signal processor (DSP), 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 one or more processors may be integrated or not integrated with each other. The processor (e.g., the one or more processors or a subset thereof) may be integrated with one or more other functions (e.g., other functions such as memory). The processor may perform signal coding, data processing, power control, input/output processing, modulation, demodulation, and/or any other functionality that may enable the device to operate in a wireless environment, such as the WLAN of FIG. 1. The processor may be configured to execute processor executable code (e.g., instructions) including, for example, software and/or firmware instructions. For example, the processer may be configured to execute computer readable instructions included on one or more of the processor (e.g., a chipset that includes memory and a processor) or memory. Execution of the instructions may cause the device to perform one or more of the functions described herein.

[0057] A device may include one or more antennas. The device may employ multiple input multiple output (MIMO) techniques. The one or more antennas may receive a radio signal. The processor may receive the radio signal, e.g., via the one or more antennas. The one or more antennas may transmit a radio signal (e.g., based on a signal sent from the processor).

[0058] The device may have a memory that may include one or more devices for storing programming and/or data, such as processor executable code or instructions (e.g., software, firmware, etc.), electronic data, databases, or other digital information. The memory may include one or more memory units. One or more memory units may be integrated with one or more other functions (e.g., other functions included in the device, such as the processor). The memory may include a read-only memory (ROM) (e.g., erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), etc.), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and/or other non-transitory computer-readable media for storing information. The memory may be coupled to the processer. The processer may communicate with one or more entities of memory, e.g., via a system bus, directly, etc.

[0059] A WLAN in infrastructure basic service set (IBSS) mode may have an access point (AP) for the basic service set (BSS) and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or another type of wired/wireless network that may carry traffic in and out of the BSS. Traffic to STAs may originate from outside the BSS, may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within the BSS may be sent through the AP where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be peer-to-peer traffic. Such peer-to-peer traffic may be sent directly between the source and destination STAs, e.g., with a direct link setup (DLS) using an IEEE 802.1 le DLS or an IEEE 802.1 lz tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may have no APs, and the STAs may communicate directly with each other. This mode of communication may be an ad-hoc mode.

[0060] Using the IEEE 802.11 infrastructure mode of operation, the AP may transmit a beacon on a fixed channel, e.g., the primary channel. This channel may be 20 MHz wide, and may be the operating channel of the BSS. This channel may also be used by the STAs to establish a connection with the AP. The channel access in an IEEE 802.1 1 system may be Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). In the infrastructure mode of operation, each STA may sense the primary channel. If a STA detects that the channel is busy, the STA may back off. One STA may transmit at any given time in a given BSS.

[0061] In various countries around the world, dedicated spectrum may be allocated for wireless communication systems such as WLANs. The allocated spectrum (e.g., below 1 GHz) may be limited in the size and channel bandwidth. The spectrum may be fragmented. The available channels may not be adjacent and may not be combined for larger bandwidth transmissions. WLAN systems, for example built on the IEEE 802.1 1 standard, may be designed to operate in such spectrum. Given the limitations of such spectrum, the WLANs systems may be able to support smaller bandwidths and lower data rates compared to HT and/or VHT WLAN systems (e.g., based on the IEEE 802.1 In and/or 802.1 lac standards).

[0062] Spectrum allocation in one or more countries may be limited. For example, in

China the 470-566 and 614-787 MHz bands may allow IMHz bandwidth. In addition to 1MHz bandwidth, a 2MHz with IMHz mode may be supported. The 802.1 lah physical layer (PHY) may support 1, 2, 4, 8, and 16 MHz bandwidths.

[0063] The 802.1 lah PHY may operate below 1 GHz. The 802.1 lah PHY may be based on the 802.1 lac PHY. The 802.1 lac PHY may be down-clocked (e.g., to

accommodate the narrow bandwidths required by 802.1 lah). The 802.1 1 ac PHY may be down-clocked by a factor of 10. Support for 2, 4, 8, and 16 MHz may be achieved by the 1/10 down-clocking. Support for the 1 MHz bandwidth may use a PHY with a fast Fourier transform (FFT) size of 32.

[0064] In 802.1 lah, one or more STAs (e.g., up to 6000 STAs including devices like meters and sensors) may be supported within a basic service set (BSS). The STAs may have different supported uplink and downlink traffic requirements. For example, the STAs may be configured to upload (e.g., periodically upload) data to a server resulting in uplink traffic. The STAs may be queried and/or may be configured by the server. When a server queries and/or configures a STA, the server may expect that the queried data arrive within a setup interval. The server, or an application on the server, may expect a confirmation for a configuration performed (e.g. , within a certain interval). These traffic patterns may be different than traditional WLAN systems traffic patterns. In 802.1 lah systems, one or more (e.g., two) bits may be used in the PLCP header of the frame. The one or more bits may indicate the type of acknowledgment expected as a response (e.g., early acknowledgement (ACK) indication) to a packet. The ACK indication (e.g., two bit ACK indication) may be signaled in the signal (SIG) field. The ACK indication may be one or more of the following: 00: ACK, 01 : block ACK (BA), 10: No ACK, 1 1 : a frame that is not ACK, BA or clear to send (CTS).

[0065] Relay functionality (e.g., as introduced in IEEE 802.1 lah) may enable more efficient power usage. Relay functionality may reduce the transmit power consumed at the STA. Relay functionality may improve wireless link conditions of STAs. A bi-directional relay may include one or more (e.g., two) hops. One transmit opportunity (TXOP) may be shared for the relay (e.g., for explicit ACK exchange). A shared TXOP may reduce the number of channel contentions. The frame control field may include a relayed frame bit (e.g., for TXOP operation). The neighbor discovery protocol (NDP), ACK, and/or SIG fields may include a relayed frame bit (e.g., for TXOP operation).

[0066] A relay may receive a frame (e.g., a valid frame). The relay may respond to the received frame with an ACK (e.g., in TXOP sharing operation). One or more of the following may apply if a relay receives a valid frame. If the relay receives the relayed frame bit set to 1, the ACK may be implicit in next-hop transmission after short inter- frame space (SIFS). The relay may respond with an ACK after SIFS with the relayed frame bit set to 1 and may continue with next-hop data transmission after SIFS. The relay may respond with an ACK after SIFS with the relayed frame bit set to 0; the relay may not use the remaining TXOP.

[0067] A relay may set a relayed frame bit to 1. For example, if a relay receives a more data bit set to 0, the relay may set a relayed frame bit to 1.

[0068] A flow control mechanism at the relay may be provided. A support to use probe request for relay discovery may be provided, which may include information on AP- STA link budget. A STA may initiate a discovery process. The STA may select a relay based on one or more received probe responses. A relay entity may include a relay STA (R- STA), a relay AP (R-AP), etc. An R-STA may be a non-AP STA. An R-STA may be a station acting as an AP. The R-STA may have one or more capabilities including for example, 4 address support (e.g., capable of transmitting and/or receiving a {To DS = 1, From DS = 1 } frame to and/or from the root AP it is associated with), support for receiving and/or forwarding frames from the R-AP, etc.

[0069] An R-AP may be an AP. The R-AP may have one or more capabilities, including, for example, 4 address support, a support for forwarding and receiving frames to/from a R-STA, and ability to indicate that it is a R-AP (e.g., by setting a bit or indicating root-AP address and/or service set identifier (SSID) in a beacon). One or more of the following may apply for the R-AP, e.g., relating to 4 address support. The R-AP may send and/or receive {To DS = 1, From DS = 1 } frames to and/or from an associated STA (e.g., based on the associated STA's capability). The R-AP may be capable of receiving a 4 address frame. The R-AP may forward a frame with 3 addresses to an associated STA.

[0070] FIG. 2 depicts an example of an IEEE 802.1 lah relay architecture. A relay

AP may include a root AP's SSID in beacons and/or probe response frames. An aggregated MAC service data unit (A-MSDU) format may be used between the root AP and the relay AP (e.g., for frame delivery). A message (e.g., a reachable address message) may be used to update the forwarding tables.

[0071] FIG. 3 depicts an example of a downlink relay from an AP (e.g., as a source) to a STA (e.g., as a destination) through a relay node. An explicit ACK may be used. A source AP may send a downlink data frame with early ACK indication bits. The early ACK indication bits in the downlink data frame may be set to 00). A relay may send an ACK back to the source AP with early ACK indication bits set to 1 1 for next outgoing frame. The relay, in SIFS time, may send the data with a different MCS and the early ACK indication bits may be set to 00. The relay may buffer the frame (e.g., data frame). The frame may be buffered until it is delivered (e.g., successfully delivered) or reaches a predetermined number of retries (e.g., a retry limit). The destination STA, in SIFS time, may send an ACK with early ACK indication bits set to 10. When the source AP receives the ACK from the relay node, the source AP may remove the data frame from its buffer and may defer MAX_PPDU + ACK +2* SIFS before next event.

[0072] FIG. 4 depicts an example of an uplink relay from a STA (e.g., as source) to an AP (e.g., as a destination) via a relay node. An explicit ACK may be used. As depicted in FIG. 4, the STA may send, to a relay, an uplink data frame with early ACK indication bits. The early ACK indication bits may be set to 00. The relay may send an ACK and may set the early ACK indication bits to 1 1 for next outgoing frame. The relay, in SIFS time, may send the data frame with a different MCS and may set the early ACK indication bits to 00. The relay may buffer the frame (e.g., data frame). The frame may be buffered until the frame is delivered (e.g., successfully delivered) or reaches a predetermined number of retries (e.g., a retry limit). The destination AP, in SIFS time, may send an ACK with early ACK indication bits set to 10. Upon receiving the ACK frame from the relay node, the STA may remove the data frame from its buffer and may defer MAX_PPDU + ACK +2* SIFS before next event (e.g., after the receipt of the ACK from the destination AP).

[0073] FIG. 5 depicts an example of a relay operation using an implicit ACK. As depicted in FIG. 5, a source node may send a downlink data frame with response frame bits set to 11. The response frame bits set to 1 1 may indicate to STAs that another data frame may follow. Within SIFS time, the source node may receive a PHY SIG field with the response frame bits set to 00. The source node may check a PAID subfield in the PHY SIG field. A relay may send the data frame with a different MCS. The relay may set the response frame bits to 00 and may set the PAID subfield to that of the STA. The destination node may send an ACK with response frame bits set to 10. [0074] In IEEE 802.11 ah, a short beacon frame format may be supported. A frame control type and/or a subtype indication for the short beacon may be provided. FIG. 6 depicts an example of a short beacon frame format. The short beacon may include one or more of the following fields: compressed SSID, timestamp, change sequence, time of next full beacon, access network options, and/or a 3 bit BW field included in the FC field. The compressed SSID field may be computed as a cyclic redundancy check (CRC) of an SSID. The CRC may be computed using the same function as may be used to compute the FCS of MPDUs. The timestamp field may be 4 bytes long. The timestamp field may contain the 4 least significant bits (LSBs) of the AP timestamp. The change sequence field may be 1 byte long. The change sequence field may be incremented whenever critical network information changes. The time of next full beacon field may indicate a time of a next full beacon frame. The time of next full beacon field may be indicated as the higher 3 bytes of the 4 LSBs of the AP timestamp at the next full beacon frame. The time of next full beacon field may be present in the short beacon frame, if an AP transmits full (e.g., long) beacon frames periodically. The beacon frame may include an access network options field in the short beacon frame.

[0075] In IEEE 802.1 1, carrier oriented WiFi may provide one or more of the following: fairness between BSS center and BSS edge users, improved BSS edge

performance, OBSS interference coordination, higher spectral efficiency and utilization, or cellular offload.

[0076] An IEEE 802.1 1 High Efficiency WLAN (HEW) system may provide an increase in the real-world data throughput achieved by IEEE 802.1 1 users in dense networks with large numbers of users and devices (e.g., Wi-Fi hotspots, office buildings, etc.).

Systems and methods to enhance 802.1 1 PHY and MAC in 2.4 and 5GHz performance may also be provided. Enhancing performance may include one or more of the following:

improving spectrum efficiency and area throughput, improving real world performance in indoor and/or outdoor deployments (e.g., in presence of interfering sources, dense heterogeneous networks, in moderate to heavy user loaded APs).

[0077] One or more metrics may be considered by a STA when selecting an AP for association (e.g., in a non-relay based WiFi network). The metrics may include the received signal strength, path loss, or link quality of the AP (e.g., the AP that may transmit the beacon frame or probe response frame).

[0078] Relays, and associated functionalities, may be used to serve STAs (e.g., STAs that may suffer from poor link budgets when communicating directly with the AP). IEEE 802.1 lah may provide relays, and/or relay type STAs (e.g., to address the potential for poor link budget issues in case of macro type coverage of STAs). The relays may also be used in other WLAN variants.

[0079] When a relay is being used, the received signal strength, path loss, or link quality, of the relay (e.g., R-AP, R-STA, etc.) that transmits the beacon frame, or probe response frame, may not provide sufficient information of the overall relay path (e.g., from source node to the destination node). FIG. 7 depicts an example of relay path selection by a STA. The STA may receive a beacon or a probe response frame from the relay node (e.g., via path VI). The link quality between the STA and the relay node may be better than the link quality between the STA and the root-AP (e.g., via path Ul). The path loss between the relay node and the root AP (e.g., via path V2) may be larger than the path loss between the STA and the root AP. Selecting the relay node based on the received beacon and/or probe response frame quality may result in a relay path which may exhibit a path loss and/or link quality worse than a direct path.

[0080] FIG. 8 depicts an example of relay path selection with a root AP connected to more than one (e.g., two) relays. The source node (e.g., STA) may receive a transmission (e.g., a beacon frame, a short beacon frame, or a probe response frame) from a relay node 2 (e.g., via path V3). The link quality between the STA and the relay node 2 may be better than the link quality between the STA and a relay node 1 (e.g., via path VI). The path loss between the AP and relay node 2 may be larger than the path loss between the AP and relay node 1. Selecting the relay node based on the link quality of the received transmission may result in a relay path via relay node 2 which may exhibit a path loss and/or link quality worse than a relay path via relay node 1. An efficient AP discovery mechanism may allow the STA to find the relay path that may include a consideration of the total link quality.

[0081] In a WLAN architecture based on relays, a relay node may receive a data frame from a source node and may reply with an ACK to the source node. The relay node may send the data frame to a destination node. When the destination node receives the data frame from the relay node, the destination node may reply with an ACK to the relay node. The path between the relay node and the destination node may not be reliable (e.g., may have temporary outages). When the link between the relay node and the destination node experiences adverse conditions, the data frames from the source node may be buffered at the relay node. The buffered data frames may cause a buffer management issue (e.g., buffer overflow). The source node may not know the link quality of the relay path between the relay node and the destination node. The source node may continue to transmit data to the relay node, which may increase the congestion at the relay node. A flow control mechanism (e.g., an efficient flow control mechanism) at the relay node may prevent path unreliability.

[0082] When a relay node is used, the channel access contention may be reduced by sharing one transmit opportunity (TXOP) for the relay. Such sharing of a TXOP may be provided in IEEE 802.1 lah. By sharing the TXOP, the source node (e.g., the initiator of the TXOP reservation) may reserve the TXOP for a time interval. The reserved TXOP may take into consideration the worst case of the link between the relay node and the destination node. The reserved TXOP may be longer (e.g., much longer) than the actual time duration of the transmission from the source node to relay node and the relay node to the destination node. A relay-shared TXOP may be truncated (e.g., efficiently truncated) when actual transmission ends early at the relay node.

[0083] An information element (IE) or a field indicating a link quality between a relay and a root AP may be transmitted in a transmission sent by the relay, such as a R-AP (e.g., in order to allow the end-STA to determine the total link quality of the relay path). The transmission may be a beacon frame, a short beacon frame, or a probe response frame. The compressed SSID of the root AP may be used in the transmission.

[0084] FIG. 9 depicts an example frame format of a transmission, where one bit in the frame control field of the transmission may indicate that the transmitter is a relay node (e.g., instead of a root AP). The transmission may be a short beacon frame. A transmission indicating that the transmitter is a relay node may be a beacon frame or a probe response frame (e.g., the short beacon frame or probe response frame may include similar fields as described in the example of the short beacon frame). When the frame control field is set to a value of 1, the transmitter may be a relay node. When the frame control field is set to a value 0, the transmitter may be a non-relay node. As depicted in FIG. 9, a bit in the frame control field of the transmission may indicate the presence of the link quality between relay and root- AP field in the transmission. The frame control field bit set to a value of 1 may mean that the field is present and a value of 0 may mean that the field is absent. A reserved bit in the frame control field may be used to indicate the presence of the link quality between relay and root- AP field. The link quality present field or relay indicator field may be implicitly signaled (e.g., by methods such as CRC masking, scrambler initiation seeds values, relative phase changes in SIG fields, or pilot values or patterns in the PLCP header). The link quality presence bit or relay indication bit in the frame control field may indicate that the link quality between relay and the root AP may be included in the transmission. One or more octets may be used for the link quality between relay and root-AP field. The link quality between relay and root-AP field may represent 64 to 4096 levels of link quality in the units of dB. The link quality between relay and root-AP field may indicate the link quality (e.g., path loss, packet error/loss rate, transmission latency and etc.) between a relay node and a root-AP. A link quality (e.g., an incremental link quality) estimate may be incremental to that indicated for the overall AP to STA link quality.

[0085] FIG. 10 depicts an example frame format of a transmission, where the link quality between the relay and root-AP may be signaled (e.g., explicitly signaled) by an IE (e.g., a link quality between relay and root-AP IE). The transmission may be a short beacon frame. A transmission signaling the link quality between the relay and root-AP may be a beacon frame or a probe response frame (e.g., the short beacon frame or probe response frame may include similar fields as described in the example of the short beacon frame). The IE may be included in the transmission (e.g., a beacon frame, a short beacon frame, or a probe response frame). Explicit or implicit indication of the link quality presence bit or relay may not be used. The IE may include one or more of the following: an octet element ID sub- field, an octet length sub-field, or one or more octets that may provide link quality between relay and root-AP sub-fields. The link quality may represent multiple levels (e.g., 64 to 4096 levels) of link quality in the units of dB.

[0086] A STA upon receiving a transmission (e.g., a beacon frame, a short beacon frame, or a probe response frame) may check a certain field or IE in the transmission to determine if the transmitter of the transmission is a relay node. The STA may check the link quality present or relay indicator field (e.g., if the link quality presence bit is present). If the link quality present or relay indicator field bit is set to 1, the STA may know that the Link quality between relay and root-AP field is included in the transmission.

[0087] A source node (e.g., a STA with traffic to transmit) may determine one or more link qualities. For example, a source node may determine a quality of each link in a relay path (e.g., to determine whether to use a relay instead of direct transmission to a destination node, to determine which relay to use if multiple relays are available, etc.).

Determining one or more link qualities, such as determining a total link quality associated with a combined link from a STA to a relay node to a root AP, may include one or more of the following. The STA may check whether the link quality between relay and root-AP IE is included in the transmission (e.g., the STA may perform this check with or without checking for a link quality present or relay indicator field). If the link quality between relay and root- AP IE is included in a transmission, such inclusion may indicate that the transmitter of the transmission is a relay node. The STA may receive a transmission (e.g., a beacon frame, a short beacon frame, or a probe response frame) that may indicate a link quality between the relay node and the root-AP, e.g., which may be denoted as QAP-Reiay A field or an IE in the received transmission may indicate the link quality. The STA may determine (e.g. , estimate) the link quality between the relay node and itself. The STA may determine the link quality based on the received transmission transmitted from the relay node, e.g., which may be denoted as QsTA-Reiay The STA may determine (e.g., calculate) a total link quality of the indirect path (e.g. , STA to relay to root-AP), e.g., Q _{R ELAY PATH} , as Q _{RELAY path} = QsTA-Reiay + QAP -Relay The indirect path may be a combined link. The STA (e.g., a scanning STA) may consider the relay node as a candidate (e.g., for association), if the total link quality QRelay path satisfies a requirement. The STA may select an entity to transmit to (e.g., a relay node or root-AP) based on the total link quality. The selected entity may be the relay node when the total link quality satisfies the requirement (e.g. , is above a threshold requirement, for example if the total link quality of the combined link is better than a quality associated with a direct link with a root AP and/or is better than a total link quality associated with another relay node).

[0088] Methods, systems, and instrumentalities are provided to describe relay flow control for relay functionality that may be applicable to 802.1 lah and other 802.1 1 systems (e.g. , HEW). An action frame (e.g., flow control notification frame) may be defined. The relay node may perform flow control on a link between a source node and a relay node. The relay node may perform flow control if the link between the relay node and the destination node worsens. The data frames from the source node may be buffered at the relay node and may lead to congestion and/or buffer overflow (e.g. , as the link worsens, more buffering may be required). The relay node may notify the source node about the flow control. The relay node may notify the source node about the flow control by sending a flow control notification frame. The flow control notification frame may be sent as a unicast frame in uplink and downlink operations. The flow control notification frame may be sent as a broadcast frame in the downlink. A flow control node address may be signaled by the flow control notification frame. The flow control notification frame may signal an address of the relay node in the relay link (e.g., between the destination node and relay node). The relay node, signaled in the flow control notification frame, may experience adverse link quality.

[0089] The flow control notification frame may signal the address of a destination node. The data traffic for an end-STA (e.g., an end-STA that belongs to the relay path experiencing a link problem) may be impacted. [0090] The flow control notification frame may be transmitted as a unicast or a broadcast frame. A transmitter address (TA) field in the MAC header of the frame may be set to a relay node address. The flow control information in the flow control notification frame may refer to the relay node identified by the TA address. FIG. 11 depicts an example frame format of the flow control notification frame. The category field may be set to a value (e.g., as may be specified in a standard) representing a two-hop relay. The action (e.g., two- hop relay action) field may be set to a value (e.g. , a unique value) that may represent flow control notification. The action field may be set as specified in a standard.

[0091] FIG. 12 depicts an example of a flow control notification element. As depicted in FIG. 12, an element ID field may be set to a value (e.g., a unique value) that may represent a flow control notification element. The element ID field may be set as specified in a standard. A length field may indicate the number of octets in an information field (e.g., fields following the element ID and length fields). A flow control duration field for each access category (AC) (e.g., background (BK), best effort (BE), video (VI) and voice (VO)) may indicate the duration of flow control applied at the relay node for the corresponding AC. The time unit of the flow control duration may be M μ8. A flow control data rate field for each AC (e.g., BK, BE, VI and VO) may indicate a data rate (e.g., the maximum data rate) that the end-STA may transmit to the relay node during the flow control duration for the corresponding AC.

[0092] The TA address in the MAC header may indicate (e.g., identify) the relay node for which the received flow control information is applied. Due to the two-hop relay architecture (e.g., where the relay node may be associated with one root-AP), the TA address in the MAC header may provide sufficient information to identify a relay link that may experience congestion or adverse link quality for the uplink case. Using the TA address in the MAC header to identify the relay link may reduce signaling overheads. In the downlink where several end-STAs may be associated with one relay node, the TA address in the MAC header may not identify (e.g., uniquely identify) the relay link between an end-STA and a relay node that may experience congestion and/or adverse link quality. The flow control notification frame may signal the address of the relay node in the relay link that may experience adverse link quality (e.g., in uplink operations). The flow control notification frame may signal the address of a destination node (e.g., in downlink operations). A flow control notification element may be piggybacked onto a data frame or a control frame from the relay node to the source node.

[0093] The flow control notification element, for example, as depicted in FIG. 13 may be used. The flow control notification element as depicted in FIG. 13 may specify a flow control duration and a data rate limit for a combination of the access categories (e.g., instead of providing one for each of the ACs).

[0094] FIG. 14 depicts an example frame format of the flow control notification frame, where an address of a destination node may be signaled in the flow control notification frame. As depicted in FIG. 14, the category field may be set to a value (e.g., as specified in a standard) that may represent a two-hop relay. The action (e.g., two-hop relay action) field may be set to a value (e.g., as specified in a standard) representing flow control notification.

[0095] FIG. 15 depicts an example design of a flow control notification element. As depicted in FIG. 15, the element ID field may be set to a value (e.g., as specified in a standard) that may represent a flow control notification element. The length field may indicate the number of octets in the information field (e.g., fields following the element ID and length fields). The destination node address (e.g., end-STA address) may be set to a 6- bytes MAC address of a destination node (e.g., an end-STA). The flow control notification frame may indicate that the flow control information received may be applied for the relay node identified by the TA address in the MAC header. A flow control duration field for each access category (AC) (e.g., BK, BE, VI and VO) may indicate the duration of flow control that may be applied at the relay node for the corresponding AC. The time unit of the flow control duration may be M A flow control data rate field for each AC (e.g., BK, BE, VI and VO) may indicate a data rate (e.g., a maximum data rate) that the end-STA may transmit to the relay node during the flow control duration for the corresponding AC.

[0096] Flow control may include one or more of the following. The relay node may monitor the buffer occupancy at the relay node. The relay node may monitor the link quality between the relay and a destination node. The relay node may determine that flow control should be applied (e.g., to mitigate identified congestion). The relay node may send a flow control notification frame to the source node. The flow control notification frame may include flow control parameters, e.g., as described herein. The source node may identify the address of the node where the flow control may be applied (e.g., upon receiving the flow control notification frame). The address may be a relay address (e.g., in uplink operations). The address may be a relay address or an end-STA address (e.g., in downlink operations). The source node may obtain information in a flow control notification element. The source node may take action according to the information in the flow control notification element. If the flow control duration field is received for an AC, the source node may stop transmitting a data frame for a corresponding AC targeted for the destination address (e.g., via the relay node for the duration value in the received flow control notification element). An end-STA may transmit data frames to the root-AP directly without going through the relay node (e.g., if the link quality between the end-STA and the root-AP is acceptable). The source node may limit the data rate for an AC (e.g., a corresponding AC) targeted for the destination address (e.g., via the relay node for the duration value in the received flow control notification element). The source node may limit the data rate if the flow control duration field and the flow control data rate are received for an AC. The flow control restriction may end at the source node (e.g., upon expiration of the flow control duration). The source node may resume transmission (e.g., normal transmission) of data frames to the destination node, e.g., via the relay node.

[0097] A data frame may include an indication of the contention free end (CF-end)

(e.g., to allow the relay node to truncate the unused TXOP). One or more of the following may apply. A reserved bit (e.g., one bit) in a SIGA field may be used (e.g., reused) to indicate the CF-end. The recipient of the data frame may reset a network allocation vector (NAV) at the end of the duration indicated in the MAC header. The data frame may also indicate one or more of the following: a SIFS time, an ACK-time, or a short-ACK_time. A reserved bit in the frame control field of the MAC header may be used (e.g., reused) to indicate the CF-end. The recipient of the data frame may reset a NAV at the end of the duration indicated in the MAC header. The data frame may also indicate one or more of the following: a SIFS time, an ACK-time, or a short-ACK time. The CF-end indication may be signaled (e.g., implicitly signaled). The CF-end indication may be signaled using one or more of the following: CRC masking, scrambler initiation seeds values, relative phase changes in SIG fields, or pilot values or patterns in the PLCP header.

[0098] In the case of a TXOP, two-hop request to send/clear to send (RTS/CTS) may establish and/or may reserve the TXOP for the duration (e.g., entire duration) of relay frame exchanges between a source node, a relay node, and a destination node. The duration to transmit the data frame from the relay node to the destination node may be assumed to be the worst case. The duration to transmit the data frame from the relay node to the destination node may be calculated (e.g., calculated conservatively). The source node may start data transmission after a SIFS time (e.g., following receipt of a CTS frame from the relay node).

[0099] The relay node may process the received data frame from the source node.

The relay node may send an ACK frame (e.g., if the received data frame is decoded correctly and an explicit ACK is used). The STA may not send an ACK frame (e.g., if an implicit ACK is used). The source node may not receive an ACK by a time SIFS time + ACK_Time after sending the data frame (e.g., if an explicit ACK is used and the received data frame is not decoded correctly). The source node may not receive an implicit ACK (e.g., if an implicit ACK is used and the received data frame is not decoded correctly). A data frame with an ACK indication field set to 00 from the relay node may indicate an implicit ACK. The source node may release the TXOP by sending a CF-end frame. The source node may retransmit the data frame. The relay node and/or the destination node may send a CF-end frame upon receipt of the CF-End from the source node.

[0100] The relay node may send the data frame to the destination node. The relay node may set the CF-end indication in the data frame to be 1 or positive and may set the duration field in its MAC header (e.g., if the duration of the data frame plus a SIFS time and an ACK Time or a Short-ACK Time is shorter than the residual of the TXOP). The duration field in the MAC header may be determined (e.g., calculated) using the length of the data frame and a data rate used for the transmission.

[0101] The destination node may process the received data frame from the relay node.

The destination node may send an ACK frame to the relay node (e.g., if the received data frame is decoded correctly). The destination node may check the CF-end indication in the received data frame. The destination node may release the TXOP and may reset the NAV for STAs near the destination node (e.g., if the CF-end indication is positive). The destination node may send a CF-end frame. The destination node may set an ACK indication field (e.g., to 10) in an outgoing ACK frame. The destination node may not send a CF-end frame when the ACK indication field is set to "10" in the outgoing ACK frame.

[0102] The source node may send a CF-end frame after a SIFS time plus time (e.g., necessary time) to cover frames sent by the destination node (e.g., upon receiving a data frame with a positive CF-end indication from the relay node before the current TXOP expires). The frames sent by the destination node may be an ACK frame or an ACK frame plus a CF-end frame. The source node may send the CF-end frame following the duration signaled in the received data frame.

[0103] FIGS. 16 and 17 depict example TXOP operations. FIG. 16 depicts an example of a TXOP operation with an explicit ACK. FIG. 17 depicts an example of a TXOP operation with an implicit ACK. As depicted in FIG. 16, the relay node may send an ACK (e.g., an explicit ACK) to the source node (e.g., after receiving a data frame from the source node). The relay node may send the ACK to the source node before relaying a data frame with a CF-end bit to the destination node. As depicted in FIG. 17, the relay node may send a data frame with a CF-end bit to the destination node (e.g., after receiving the data frame from the source node). The relay node may send the data frame without sending an ACK to the source node.

[0104] Although features and elements are described above in particular

combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. Other than the 802.11 protocols described herein, the features and elements described herein may be applicable to other wireless systems. In addition, the methods described 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, 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, WTRU, terminal, base station, RNC, or any host computer.