WO2016172360A1 - Dynamic directional relaying - Google Patents

Abstract

Methods and devices for dynamic directional relay communications. In some embodiments, data may be received by a relay device from a source device during a first transmission period and data may be transmitted from the relay device to a destination device during a second transmission period. The durations of the first transmission period and second transmission period may be of variable lengths. The durations of the first and second transmission periods may be set dynamically. In some embodiments, a relay setup request may be transmitted to an access point (AP), wherein the relay setup request indicates an initial prioritized list of relay devices. A relay setup response may be received by the destination device, wherein the relay setup response indicates a final prioritized list of relay devices. The source device may communicate with the destination device via a particular relay device, based upon the final prioritized list.

Description

DYNAMIC DIRECTIONAL RELAYING

CROSS REFERENCE TO RELATED APPLICATIONS

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

Application No. 62/150,651 which was filed on April 21, 2015, the contents of which is hereby incorporated by reference herein.

BACKGROUND

[0002] A wireless local area network (WLAN) in an Infrastructure Basic

Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (ST As) associated with the AP. The AP may typically have access, or interface, to a Distribution System (DS), which may connect the BSS to other wired/wireless networks that may carry traffic outside of the DS. Traffic to STAs that originates 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 also be sent through the AP, where a source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. This traffic between STAs within a BSS may be considered peer-to-peer traffic. The peer-to-peer traffic may also be sent directly between the source and destination STAs with a direct link setup (DLS) using an Institute of Electrical and Electronics Engineers (IEEE) 802. l ie DLS or an IEEE 802. l lz tunnelled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may have no AP, and STAs within the IBSS may communicate directly with each other. This mode of communication may be referred to as an "ad-hoc" mode of communication.

[0003] The IEEE 802.11s standard may define how wireless devices can interconnect to create a WLAN mesh network, which may be used for static topologies and ad-hoc networks. An IEEE 802.11s mesh network device may be referred to as a Mesh Station (MSTA). MSTAs may form mesh links with one another, over which mesh paths can be established using a routing protocol. The IEEE 802.11s protocol may extend the IEEE 802.11 MAC standard by defining an architecture and protocol that may support both broadcast/multicast and unicast delivery using radio-aware metrics over self- configuring multi-hop topologies.

[0004] The IEEE 802.1 lad standard may include Very High Throughput using the 60 GHz band due to the available wide bandwidth spectrum at 60 GHz that is available. The IEEE 802. Had standard may support up to 2 GHz operating bandwidths with data rates that may reach up to 6 Gbps. Since propagation loss at 60 GHz may be more significant than at the 2.4 GHz and 5 GHz bands, beamforming may be used as a means to extend the coverage range. Another feature of the IEEE 802. Had standard may be the addition of a scheduled channel access mode in addition to contention-based access. This may allow an AP and a STA to gain predictable access to the channel. Further, in addition to the IBSS, the IEEE 802. Had standard may include the concept of a Personal Basic Service Set (PBSS) as an ad-hoc network. Similar to the IBSS, the PBSS is a type of IEEE 802.11 LAN in which STAs communicate directly with each other. However, unlike the IBSS, in the PBSS one STA may assume the role of the PBSS control point (PCP).

SUMMARY

[0005] Embodiments described herein may include methods, systems, and apparatuses for relay communications. The embodiments may include: transmitting, by a source device, forward link data to a first relay device in a first transmission period, wherein the first relay device is ranked high on a predetermined priority hst known to the source device and a destination device, and wherein the source device is aligned with the first relay device to receive the forward link data in a second transmission period; upon not receiving an acknowledgment from the first relay within a first two consecutive relay periods, transmitting, by the source device, the forward link data in the first transmission period to a second relay device before the end of a second two consecutive relay periods, wherein the second relay device is ranked below the first relay device in the predetermined priority hst, and wherein the source device is aligned with the second relay device at the start of the second two consecutive relay periods; receiving, by the source device, an acknowledgment from the second relay device; and receiving, by the source device, a null data frame indicating a successful transmission of the forward link data from the second relay device to the destination device in the second transmission eriod.

[0006] Other embodiments may include: transmitting, by a relay device, a first grant message to a source device at the beginning of a first two consecutive relay periods, wherein the first grant message indicates a maximum duration available for a transfer of forward link data in a first transmission period; receiving, by the relay device, the forward link data from the source device in the first transmission period within the first two consecutive relay periods; transmitting, by the relay device, a second grant message to a destination device within the first two consecutive relay periods, wherein the second grant message indicates that a connection between the relay device and the destination device is active and should not be changed by the destination device; transmitting, by the relay device, first reverse link data to the source device before the end of a second two consecutive relay periods; transmitting, by the relay device, the forward link data to the destination device in a second transmission period before the end of a third two consecutive relay periods; receiving, by the relay device, second reverse link data from the destination device in the second transmission period before the end of the third two consecutive relay periods; and transmitting, by the relay device, a third grant frame to the source device before the end of the third two consecutive relay periods, wherein the third grant message indicates that a connection between the relay device and the source device is active and should not be changed by the source device.

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 wherein:

[0008] Figure 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented; [0009] 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 1A;

[0010] Figure 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in Figure 1A;

[0011] Figure 2 is a signal diagram illustrating example frame exchange rules with a variable first transmission period and second transmission period (Mode 1);

[0012] Figure 3 is a signal diagram illustrating example frame exchange rules with a variable first transmission period and second transmission period (Mode 2);

[0013] Figure 4 is a message sequence chart illustrating an example reverse link optimization procedure;

[0014] Figure 5 is a table illustrating an example relay setup request frame action field format;

[0015] Figure 6 is a table illustrating an example relay setup response frame action field format;

[0016] Figure 7 is a signal diagram illustrating an example bidirectional data transfer (example implementation 1);

[0017] Figure 8 is a signal diagram illustrating an example bidirectional data transfer (example implementation 2);

[0018] Figure 9 is a message sequence chart illustrating dynamic relay selection in an example procedure for relay (RDS) selection by a source device (S-REDS);

[0019] Figure 10 is a table illustrating an example modified RLS request frame action field format;

[0020] Figure 11 is a table illustrating an example modified RLS announcement frame action field format;

[0021] Figure 12 is a message sequence chart illustrating dynamic relay selection in an example procedure for RDS selection by AP/PCP; [0022] Figure 13 is a message sequence chart illustrating an example procedure for autonomous channel access by S-REDS with multiple RDSs;

[0023] Figure 14 is a table illustrating an example relay setup response frame action field format;

[0024] Figure 15 is a table illustrating an example relay switch request frame action field format;

[0025] Figure 16 is a table illustrating an example relay switch response frame action field format;

[0026] Figure 17 is a signal diagram illustrating an example of autonomous RDS selection by S-REDS and destination device D-REDS (channel access initiated by RDS, no re-transmissions);

[0027] Figure 18 is a signal diagram illustrating another example of autonomous RDS selection by S-REDS and D-REDS (channel access initiated by RDS, with re-transmissions);

[0028] Figure 19 is a signal diagram illustrating another example of autonomous RDS selection by S-REDS and D-REDS (with end-to-end ackno wle dgem ent s) ;

[0029] Figure 20 is a signal diagram illustrating another example of autonomous RDS selection by S-REDS and D-REDS (data transmission initiated by S-REDS);

[0030] Figure 21 is a message sequence chart illustrating an example procedure for assisted channel access by AP/PCP;

[0031] Figure 22 is a signal diagram illustrating an example of variable channel allocation for source-relay (first transmission period) and relay- destination (second transmission period) transmissions;

[0032] Figures 23A, 23B, 23C, and 23D are signal diagrams illustrating an example of variable channel allocation for source-relay (first transmission period) and relay-destination (second transmission period) transmissions;

[0033] Figure 24 is a signal diagram illustrating an example of dynamic first and second transmission periods (mode 2, delayed B-ACK);

[0034] Figure 25 is a signal diagram illustrating an example of dynamic relay selection (relay controls channel access); [0035] Figure 26 is a signal diagram illustrating an example of dynamic relay selection (source controls channel access); and

[0036] Figure 27 is a diagram illustrating example transmissions where there are multiple simultaneous (or substantially simultaneous) active relays.

DETAILED DESCRIPTION

[0037] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. 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.

[0038] As shown in FIG. 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.

[0039] 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 other 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, 114b 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.

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

[0041] 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).

[0042] 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).

[0043] 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).

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

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

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

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

[0048] 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 114a, which may employ a cellular -based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology. [0049] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. 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 /touchp ad 128, non-removable memory 130, 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.

[0050] 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 FIG. 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.

[0051] 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. [0052] 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.

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

[0054] 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 /touchp ad 128 (e.g., a liquid crystal display (LCD) display unit or organic hght-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 /touchp ad 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 130 and/or the removable memory 132. The nonremovable 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).

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

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

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

[0058] FIG. 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 an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0059] The RAN 104 may include eNode-Bs 140a, 140b, 140c, 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 140a, 140b, 140c 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 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0060] Each of the eNode-Bs 140a, 140b, 140c 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 FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0061] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. 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.

[0062] The MME 142 may be connected to each of the eNode-Bs 140a,

140b, 140c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 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 142 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.

[0063] The serving gateway 144 may be connected to each of the eNode

Bs 140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 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.

[0064] The serving gateway 144 may also be connected to the PDN gateway 146, 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.

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

[0066] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 and APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102 d.

[0067] As introduced above, the IEEE 802. Had standard may include procedures for using relays to transfer data from source to destination nodes. Both Amplify and Forward/Full-duplex and Decode and Forward/Half-Duplex modes may be covered. Further, two types of relaying operation may be supported in IEEE 802. Had: Link Switching and Link Cooperating. The 802. Had standard may allow for the use of a single relay node between the source and the destination relay nodes, which may be referred to as a Source- Relay End-point directional multi-gigabit (DMG) Station (S-REDS) and a Destination-Relay End-point DMG Station (D-REDS), respectively. The 802. Had standard may require that a direct link between the S-REDs and D- REDS is first established. Only when the direct link between the end nodes is disrupted, the relay link through the RDS is utilized. Different frame exchange rules for Full-Duplex/ Amplify and Forward, Half-Duplex/Decode and Forward utilizing Data Sensing time, and first transmission periods and second transmission periods may be specified.

[0068] The IEEE 802. Hah standard may include the concept of relaying for omni-directional transmissions. The procedure may allow the AP and the STA to exchange frames with one another through a relay. The relay may be an entity that logically consists of a Relay AP and a Relay STA.

[0069] Relays may enable STAs to use higher order modulation and coding schemes (MCSs) and reduce the time STAs have to stay in Active Mode. This may improve battery life of stations. Relay stations may also provide connectivity for STAs located outside the coverage area of the AP. That being said, there is an overhead cost on overall network efficiency and an increased complexity with the use of relay stations. To limit this overhead, the relaying function may be limited to two hops only. However, according to the 802. Hah standard, the outlying STA may associate with the Relay AP in the relay station and not the root AP. This may increase the time required to transition the STA from one relay station to another or to the root AP. Additionally, the 802. Hah standard may allow only STA-AP data transfer via a Relay. Direct STA to STA links using a Relay station may not be possible.

[0070] Next Generation 60 GHz (NG60) is a study group within the

IEEE 802.11 working group that will consider significantly increasing the data rates in the 60 GHz frequency band in a backwards compatible way to IEEE 802. Had standard. Wireless backhaul from building to building and wireless access with roaming devices are two of the usage models being considered by the NG60 study group that may rely on relaying for either improving reliability or enabling mobility, depending on the specific scenario.

[0071] Dynamic link-switching period scheduling is discussed herein.

Relaying may allow a source relay endpoint (S-REDS) to transmit frames to a destination relay endpoint (D-REDS) with the assistance of another DMG STA, which may be referred to as a relay DMG STA (RDS). The relay operation, in a link-switching mode, may include a first transmission and a second transmission period, which may be specified in the last "Relay transfer parameter set" element sent from the S-REDS. It may be beneficial to set the first transmission period and the second transmission period dynamically for efficient utilization of resources.

[0072] Reverse-link optimization is discussed herein. The RDS, as described above, may be chosen after the relay link setup (RLS) procedure is complete. In conventional methods, there may be no mechanism to switch the direction of data transfer during a relay operation, which may be similar to a "reverse-link" operation between a source and destination pair of STAs.

[0073] Dynamic relay selection is discussed herein. For a link-switching type relay operation, a relay may come into effect when a direct link between the S-REDS and D-REDS is broken. This may be determined as having occurred, for example, via lack of reception of an ACK. During the time when the direct link is working, the relay node may not participate in data transfer. If the relay node moves away at this time, it may optionally execute a "relay teardown" procedure. At this point, the S-REDS and D-REDS may need to perform the overall relay setup procedure again (or another mechanism must be employed) to determine a new node to act as a relay node. It may be beneficial to have a prioritized backup relay node list to hasten the relay selection procedure.

[0074] An end marker for first a transmission period and second transmission period is discussed further herein, which may be used, for example, in the context of dynamic hnk-switching period scheduling. Two example modes, referred to as mode 1 and mode 2, are discussed relating to the implementation of a dynamic first transmission period (first period) and a dynamic second transmission period (second period).

[0075] In mode 1, the first transmission period and the second transmission period may be of variable lengths in each transmission cycle instead of two fixed lengths. The durations of the two periods may depend not only the amount of data that needs to be transmitted and the respective channel qualities between the node pairs, but also on the number of retry attempts required to successfully transmit the available data on each hop. The maximum number of retries may be limited by a pre-configured maximum retry limit. After successful transmission on the second hop between RDS (R) and D-REDS (D), or after the maximum number of retries has been exhausted, the RDS in this mode may send a message to the S-REDS (S) to indicate that it is ready to accept new data on the first hop from the S-REDS. Accordingly, the RDS may send a Null-Data frame to the S-REDS to indicate that it has completed its second hop transmission to D-REDS. An example illustration of this procedure is shown in Figure 2.

[0076] In this procedure, multiple retry attempts may be configured on the first and second hops (i.e., S→R and R→D, respectively) with the condition that re-transmission attempts continue until either the data PDUs are successfully received by the one-hop neighbor, or a retry count limit is reached. After the data PDUs are successfully received or the retry count limit is reached, transmission on the other hop may be attempted. In this way the first transmission period and the second transmission period lengths may be completely variable. The end of the first transmission period may be signaled when the RDS receives all transmitted packets correctly or when the retry limit is reached. The RDS may then begin transmitting towards the D-REDS. Similarly, the end of the second transmission period may occur when the RDS receives a block ACK (BA) frame 202 from the D-REDS. This BA frame 202 may indicate that all transmitted data PDUs were correctly received or that the retry limit is reached on all outstanding data PDUs. The RDS may then send a Null-Data frame 204 to the S-REDS to continue with the next first transmission period. If the RDS does not detect the start of a packet transmission from S-REDS within a Short Inter-frame Spacing (SIFS) duration after sending the Null-Data frame 204, it may repeat the Null-Data frame transmission to S-REDS.

[0077] In mode 2, the first transmission period and the second transmission period may also be of variable lengths in each transmission cycle instead of two fixed lengths. In mode 2 however, this may be accomplished by delaying transmission of the Block ACK (BA) frame 302 by the RDS (R) to the S-REDS (S), in response to a received Block ACK Request (BAR) frame 304, until after completing transmission on the second hop between the RDS and the D-REDS (D). Here, the S-REDS may transmit a BAR 304 to the RDS after transmitting multiple data Packet Data Units (PDUs). Instead of immediately responding with a BA 302, the RDS may interpret the BAR 304 as an indicator that the first transmission period is over and may begin transmitting the data PDUs on the second hop to the D-REDS. The Delayed Block -ACK procedure of the IEEE 802.11 standard may enable such separation of the BAR 304 and BA 302 messages. After all data PDUs have been successfully transmitted or when a maximum retry limit is reached on the second hop (RDS to D-REDS), the RDS may send the BA 302 to the S- REDS in response to the previously received BAR 304. In mode 2, the BA response 302 to the S-REDS may act as a signal to the S-REDS that transmission on the second hop is over and that the RDS is ready to receive further data PDUs. An example of this procedure is shown in Figure 3.

[0078] The BA 302 addressed to the S-REDS may be configured by the

RDS in various ways. In one example, the BA 302 may acknowledge receipt of all data PDUs that were correctly received by the RDS. Any data PDUs that were not transmitted successfully on the second hop to the D-REDS may not be signaled to the S-REDS. In a second example, the RDS may signal all data PDUs that were not successfully received on either the first or the second hop to the S-REDS. The S-REDS may then re-transmit all indicated data PDUs to the RDS. In some implementations, the RDS may switch from one mode to the other autonomously and/or transparently to the other nodes involved in the transaction.

[0079] Reverse link extensions for relay are discussed further herein, and may be used, for example, in the context of reverse-link optimization. Various procedures for relay selection for reverse link and channel access for bi-directional data transfer are discussed.

[0080] With regards to relay selection for the reverse link, procedures for optimizing reverse link setup are discussed further herein. In an example scenario, a forward link between a S-REDS and a D-REDS is assumed to already be established. In this example procedure, steps which may be followed by the D-REDS to establish an indirect link to the S-REDS via a RDS are described. An example of such a procedure is shown in Figure 4.

[0081] After a relay link between the S-REDS and D-REDS is established, the D-REDS (STA 3 in Figure 4) may send a Relay Setup Request frame to the AP/PCP. An example of Relay Setup Request frame contents are shown in Figure 5. The Relay Setup Request frame may contain a RDS Order field, which may convey to the AP/PCP a prioritized list of RDSs identified during initial relay link setup between the S-REDS and D-REDS. It should be noted that the RDS order proposed by the D-REDS may be different from an order sent by the AP/PCP earlier during link setup between the S-REDS and D-REDS.

[0082] The AP/PCP may accept the proposed priority list of RDSs by the

D-REDS, or may change it. The final list of RDSs (i.e. either accepted or as changed by the AP/PCP) may be included in a Relay Setup Response message sent by the AP/PCP to the S-REDS, D-REDS and the RDS. Receipt of the Relay Setup Response message by the three nodes establishes the reverse link from D-REDS to S-REDS via the identified RDS. An example of Relay Setup Response frame contents are listed in Figure 6.

[0083] Channel access procedures for bi-directional traffic transfer between a pair of end nodes (S-REDS and D-REDS) through a relay (RDS) are discussed herein. Figure 7 shows an example bi-directional channel access procedure. This procedure may use the variable relay period mechanisms described herein. Use of the variable relay period mechanisms may allow for more efficient utilization of channel resources and may enable packet retransmissions in the case of packet drops. Moreover, this procedure may incorporate elements of a dynamic relay selection procedure as further described herein. This may allow the procedure to function with multiple relays (RDSs) between the S-REDS and D-REDS that may be chosen dynamically by the S-REDS and D-REDS based on certain pre-defined rules.

[0084] These procedures may address the problem of coordinating channel access for bi-directional data transmission between a S-REDS and a D-REDS through a RDS (relay) during a scheduled access period (e.g., a Service Period (SP) as defined in the IEEE 802. Had specifications). Not only may there be a need to coordinate channel access between the two directions in which data is transferred (e.g., S-REDS to D-REDS and D-REDS to S- REDS), but there may also be a need for mechanisms for switching autonomously from one RDS to another in the case of failure due, for example, to directional transmission and reception.

[0085] Figure 7 may show a portion of a SP, which may include multiple equally spaced intervals which may be used either for S-REDS to RDS or RDS to D-REDS communications. These intervals may be referred to as Relay Periods. The Relay Period concept may allow for the use of multiple pre- identified RDSs for a pair of end-points (S-REDS and D-REDS). The Relay Periods may also allow for coordinating switching among the multiple pre- identified RDSs for all participating nodes (S-REDS, RDS and D-REDS), where a switching decision is made. The example of Figure 7 illustrates such Relay Periods (e.g. n, n+1, n+2, etc.) as well as the first transmission period and the second transmission period as discussed herein. As discussed earlier, the first transmission period and the second transmission period correspond to the time needed to successfully complete data transmission (i.e., hops) of forward link data between the S-REDS and RDS and between the RDS and D- REDS, respectively. In the example of Figure 7 however, bidirectional data transfers between the participating nodes, including reverse link data from the D-REDS destined for the S-REDS, may be enabled during the first transmission period and the second transmission period.

[0086] In this example, the receiving end node (either S-REDS or D-

REDS) may consider its link to the RDS to be impaired if it does not receive any transmission for two consecutive Relay Periods. Accordingly, the active RDS may be required to utilize its link to an end node (S-REDS or D-REDS) before the start of the Relay Period following two complete consecutive Relay Periods from the beginning of its current communications (transmission or reception) with the other end node (D-REDS or S-REDS). [0087] For a particular link (e.g., between S-REDS and RDS), the RDS may initiate data transfer by sending a Grant frame 702 to the S-REDS. The Grant frame 702 may have an Allocation Duration value T equal to twice the Relay Period minus the time needed to send a Grant frame 702 to the other end node (D-REDS in this case). This value is an indication to the S-REDS of the maximum duration available for data transfer to the RDS.

[0088] The S-REDS may then begin data transmission of forward link data to RDS. Data transmission from the S-REDS to the RDS may involve multiple back-to-back packets or aggregated frames. The end of the data transmission from the S-REDS to the RDS may be signaled by transmitting a BAR frame 704 from the S-REDS to the RDS. The RDS may then send a BA frame 706 with a bitmap indicating reception status of packets since the previous BA transmission. It should be noted that this may correspond to the Immediate Block-Ack variant of the IEEE 802.11-2012 specifications. The RDS may then transmit a Grant frame 708 having an Allocation Duration of T = 0 to the D-REDS. This may signal to the D-REDS that its link to the RDS is still operational, and the D-REDS may thus not switch to another pre-selected RDS for further transmissions. Any required re-transmissions from S-REDS to RDS or reverse direction data packets (i.e., reverse link data) from RDS to S-REDS may then be transmitted following the Grant frame 708 transmission to D-REDS. The duration for these required re-transmissions or reverse direction data packets may be limited by a parameter, Relay Link Refresh Expiry Timer Limit, which may last until the end of the second Relay Period after the current Relay Period.

[0089] In the reverse direction between D-REDS and RDS, a similar procedure may be employed. However, the Relay Link Refresh Expiry Timer Limit value in this case may correspond to the longest silent period on the S- REDS to RDS link. This may refer to the duration after which the S-REDS switches to another pre-selected RDS if no transmissions are received from the current RDS. If the channel allocation contained in the Grant frame 702 is insufficient for the D-REDS to transmit the scheduled data packets (i.e., reverse link data) to the RDS, it may request more channel time by setting More Data = 1 in a MAC Header. The RDS may then allocate more channel time in the next Grant frame to the D-REDS, after sending a Grant frame 708 with zero allocation to the S-REDS to maintain the hnk. In this way two-way communication between the S-REDS and D-REDS through RDS may be possible and channel resource utilization may be optimized.

[0090] In another example procedure, the RDS may be required to initiate data transmission to D-REDS at the start of the 2nd Period. This procedure is shown in Figure 8. In this example, the RDS may immediately start data transmission to D-REDS at the start of 2nd Period, and may send a Grant frame 802 when it wants to allocate channel time to D-REDS.

[0091] Dynamic Relay Selection is discussed further herein, and may be used, for example, in the context of link switching type relay operation. Two different example RDS setup procedures are discussed herein. In a first example, the S-REDS may determine a priority order of primary and secondary RDS nodes. In a second example, the priority order may be determined by the AP/PCP. Further, two example channel access procedures are described herein, which may be used for example in a scenario where there are multiple RDSs for a pair of S-REDS and D-REDS.

[0092] The first example channel access procedure is an autonomous method where all potential RDSs are ready to receive data from the S-REDS during each SP. Here, the S-REDS may switch from one RDS to another without informing the AP/PCP, and is thus referred as an autonomous method. The second example channel access procedure involves coordination with the AP/PCP to inform the chosen RDS for each data transfer sequence, and is thus referred as an assisted method of channel access. Such procedures are discussed in further detail herein.

[0093] In implementations where RDS is selected by S-REDS, all channel measurement reports between the S-REDS and potential RDSs, as well as those between potential RDSs and D-REDS, may be collected by the S- REDS. The S-REDS may then determine a prioritized order of RDSs for communicating with the D-REDS. All of the identified RDSs may be in a ready state to receive data from the S-REDS in each SP allocated for the S-REDS to D-REDS communication.

[0094] An example of such RDS selection procedure is shown in Figure

9. This example may follow device discovery and association steps such as those described herein, and may be followed by a Potential Relay Set Reduction procedure such as described herein. After all potential Relay nodes are identified by an AP/PCP 904, the AP/PCP 904 may allocate channel time for Beamforming training (BF-Training) between a S-REDS 902 and all potential RDSs. At the end of the BF-Training procedure the S-REDS 902 may send a Multi-Relay Channel Measurement Request to the potential RDS 906. The potential RDS 906 may respond to the Multi-Relay Channel Measurement Request with a Multi-Relay Channel Measurement Report.

[0095] The AP/PCP 904 may then allocate channel time for BF-Training between the potential RDS 908 and the D-REDS 910. At the end of the BF- Training procedure, the D-REDS 910 may send a Multi-Relay Channel Measurement Request to the potential RDS 908, and in return may receive a Multi-Relay Channel Measurement Report. The AP/PCP 904 may also allocate time for BF-Training between the S-REDS 902 and the D-REDS 910. At the end of this procedure, the S-REDS 902 may send a Multi-Relay Channel Measurement Request message to the D-REDS 910. The D-REDS 910 may then send a Multi-Relay Channel Measurement Report message. At the end of this sequence of BF-Training procedures, the S-REDS 902 may have received information about the channel conditions between the S-REDS 902 and potential RDS 906, between the D-REDS 910 and potential RDS 908 and between the S-REDS 902 and D-REDS 910. It should be noted that the order in which BF-Training occurs may differ in some implementations; for example, BF-Training between the D-REDS 910 and potential RDS 908 may occur before BF-Training between the S-REDS 902 and potential RDS 906.

[0096] This procedure may be repeated for each potential RDS in the

BSS/PBSS. After the procedure has been completed for all potential RDSs in the BSS/PBSS, the S-REDS 902 may create a list of RDSs, which may be prioritized on the basis of overall end-to-end channel quality or other factors. In some implementations the S-REDS 902 may drop one or more potential RDSs at this stage if the end-to-end channel quality does not exceed some threshold value.

[0097] The S-REDS 902 may then send a RLS Request message to each

RDS in the list, including the potential RDS 906. The RLS Request message may include the identities of the S-REDS 902, D-REDS, 910 and the RDSs. An additional field of the RLS Request message may include a Rank of the particular node. This Rank may indicate the potential RDS's ranking in the list prepared by the S-REDS 902. An example of such a modified RLS Request message is shown in Figure 10.

[0098] The RLS Request frame may be forwarded by the potential RDS

906 to the D-REDS 910. The D-REDS 910 may then send a RLS Response message to the RDS 906. The RLS Response message may include a Destination Status Code, or other indication of its acceptance of the potential RDS 906 being used as a Relay between the S-REDS 902 and D-REDS 910. This information may be relayed by the RDS 906 to the S-REDS 902 in the RLS Response message. The potential RDS 906 may also include a Relay Status Code in the relayed RLS Response message to indicate its willingness to participate as RDS for the particular S-REDS 902 and D-REDS 910 pair. If the S-REDS 902 receives a RLS Response message with "Success" indicated in both Destination Status Code and Relay Status Code, it may finalize the particular STA 906 as a RDS for communicating with D-REDS 910.

[0099] Similarly, the S-REDS 902 may determine the Destination

Status code and Relay Status Code for each potential RDS. At the end of this step the S-REDS 902 may finalize the RDSs and create a prioritized list. The prioritized list of RDSs may be sent to the AP/PCP 904 in a Modified RLS Announcement frame. Figure 11 shows the fields which may be included in an example Modified RLS Announcement frame. For example, the Modified RLS Announcement frame may include an ordered list of RDS association identifiers (AIDs) (i.e. Relay AIDs).

[0100] Implementations where an AP/PCP 1204 may select the RDSs and create a prioritized list may be illustrated by the example procedural steps shown in Figure 12. These procedural steps may follow device discovery and association steps such as those described further herein, and may be followed by a Potential Relay Set Reduction procedure such as described herein. After all the potential Relay nodes are identified by the AP/PCP 1204, the AP/PCP 1204 may allocate channel time for BF-Training between a S- REDS 1202 and all potential RDSs.

[0101] At the end of the BF-Training procedure the AP/PCP 1204 may send a BF-Training Report Request to each of the participant nodes in the procedure. Each participating node may then send a BF-Training Report to the AP-PCP 1024, which may include the received signal power. This procedure may be repeated between the D-REDS 1210 and potential RDSs. BF-Training may also be performed between the S-REDS 1202 and D-REDS 1210, if required. If the AP/PCP 1204 has received all of the BF-Training Reports, it may determine the end-to-end channel quality between the S- REDS 1202 and D-REDS 1210, both on the direct hnk and the relayed through the potential RDSs.

[0102] This entire procedure of pair-wise BF-Training may be repeated for each potential RDS. At the end of this procedure the AP/PCP 1204 may have received information about the channel quality between the S-REDS 1202 and D-REDS 1210 for each Potential RDS, both directly and via each of the potential RDSs.

[0103] In implementations involving autonomous channel access by S-

REDS 1202 with multiple RDSs, the S-REDS 1202 and D-REDS 1210 may be aware of the identities of all the RDSs and their respective priority order. Depending on whether the S-REDs 1202 or the AP/PCP 1204 makes the choice of RDSs and their relative priorities, there may be two example methods to convey the choice of RDSs and their relative priorities to all RDSs, the D- REDS 1210, and optionally the S-REDS 1202. In one example, as described earlier, the S-REDS 1202 may choose the RDSs and may inform the RDSs and the D-REDS 1210 via an RLS Announcement message. The RLS Announcement may be modified to also include a Rank field to inform the RDSs and the D-REDS about the relative priority of the RDS. [0104] In another example, where a AP/PCP 1304 chooses the RDS for a particular S-REDS 1302 and D-REDS 1310 pair, the procedure for informing all the nodes may be as shown in Figure 13. Here, the AP/PCP 1304 may send Relay Setup Response messages to the S-REDS 1302, D-REDS 1310 and all chosen RDSs. This Relay Setup Response message may include a field (which may be referred to as RDS order) that reflects the chosen RDSs in the order determined by the AP/PCP 1304. Contents of an example Relay Setup Response frame are shown in Figure 14. By receiving the Relay Setup Response frame, the S-REDS 1302, D-REDS 1310 and aU chosen RDSs may learn of the desired order of the RDSs, as decided by the AP/PCP 1304.

[0105] In such autonomous RDS selection procedures, the S-REDS 1302 may begin transmitting data traffic directly to the D-REDS 1310 if a direct data link is possible between the two following regular channel access procedures. If direct data transfer to the D-REDS 1310 is not possible, or if the direct link between the S-REDS 1302 and D-REDS 1310 fails, then the S- REDS 1302 may switch to the relay link using the highest priority RDS as determined earlier. The D-REDS 1310 may also then switch to the highest priority RDS in the list supplied earlier by the AP/PCP 1304 or the S-REDS 1302, and this switch may be simultaneous or substantially simultaneous with the S-REDS 1302 switch to the relay link using the highest priority RDS. After these switches, if the relay link using a current RDS 1306 is broken either between the S-REDS 1302 and RDS 1306 or a RDS and D-REDS 1310, then the S-REDS 1302 and the D-REDS 1310 may switch to the next listed RDS in the priority order, and the S-REDS 1302 and D-REDS 1310 switches may be simultaneous or substantially simultaneous.

[0106] Various implementations for enabling autonomous channel access coordination are described further herein, including data transmission initiated by RDS, end-to-end acknowledgements, and data transmission initiated by S-REDS.

[0107] An example autonomous Relay switch procedure for scenarios involving data transmission initiated by RDS may be shown in Figure 15. In an embodiment, the S-REDS (S) may initially use RDSl (labeled Rl in the figure) to relay data traffic to D-REDS (D). The next highest priority RDS in its RDS list may be RDS2 (labeled R2 in the figure) in this example. The entire Service Period (SP) may include multiple Relay Periods.

[0108] The service periods may be further categorized as 1st Periods and

2nd Periods, when used for S-REDS to RDS or RDS to D-REDS communications, respectively. As shown in Figure 15, a period may be shorter or longer than a relay period. The relay procedure may begin when the S- REDS sends the first data packets to the RDSl, during the first 1st Period. This corresponds to Relay Period n in the example. If this transmission is successful (indicated by successful ACK 1502 reception), then the 2nd Period would be used for data transfer between RDSl and D-REDS. During this 2nd Period, the D-REDS may orient its reception antenna towards RDSl, the highest priority RDS in its list. If the D-REDS does not receive any data from RDSl in that interval, it may then switch its reception antenna orientation towards the next RDS in its priority list at the start of the next interval (RDS2 in this example). The D-REDS may continue listening towards the chosen RDS for two full Relay Periods before switching to the next available RDS in the prioritized list. This mechanism may allow support for multiple RDSs, and for autonomous synchronized switch between them by the S-REDS and the D- REDS.

[0109] In this procedure, completion of transmission from RDS2 to D-

REDS may be indicated to the S-REDS via a Null-Data transmission 1504 by RDS2. The S-REDS may then send the next data packets to RDS2 for onward transmission to D-REDS. The S-REDS may wait for two full Relay Periods for a Null-Data frame transmission 1504 after the end of the S-REDS to RDS2 data transmission. If a Null-Data frame 1504 is received within that period, the S-REDS may continue using RDS2 as the relay for data frames addressed to D-REDS. If a Null-Data frame 1504 is not received within that period, the S-REDS may switch to the next relay in the priority list at the start of the next Relay Period.

[0110] In some implementations, the S-REDS may switch to any RDS from the priority list at the start of a Relay Period after receiving a Null-Data frame 1504 from the previously selected RDS or another indication of successful completion of data transfer between the RDS and D-REDS. This feature may be used by the S-REDS to determine if any of the RDSs higher in the priority list are available again for relaying data to the D-REDS. In this scenario, the S-REDS may send a Relay Switch Request message to the D- REDS through the current RDS (RDS2 in this example), possibly accompanied by other data frames. This Relay Switch Request message may be relayed by RDS2 to the D-REDS along with the data frames. D-REDS may acknowledge reception of this management frame, and the acknowledgement may be relayed back to S-REDS via the Null-Data frame 1504. For the next transmission the S-REDS may use the RDS included in the Relay Switch Request message to D-REDS. Simultaneously, substantially simultaneously, or subsequently, the D-REDS may also point its receive antenna beam towards the new RDS at the start of the next Relay Period. The Relay Switch Request message may contain additional information, such as switch delay to schedule the switch at a future time. If the transmission to the new RDS fails, the S-REDS and D-REDS may revert back to the last known good RDS for the next transmission, at the start of the following Relay Period.

[0111] If bi-directional data transfer between S-REDS and D-REDS is enabled as discussed further herein, then the D-REDS may respond to the received Relay Switch Request message with a Relay Switch Response message to the current RDS (RDS2 in this example), which may then relay the Relay Switch Response message to the S-REDS. Example formats for the Relay Switch Request and Relay Switch Response frames are shown in Figure 16 and Figure 17, respectively.

[0112] In some implementations, if the value of the Switch Delay field in the Relay Switch Response frame is different than that in Relay Switch Request frame, then the S-REDS may send another Relay Setup Request frame with the new Switch Delay value to match that requested by D-REDS if the S-REDS finds the new Switch Delay to be acceptable. If the proposed Switch Delay value is not acceptable to S-REDS, then it may not respond and may continue using the current RDS. If the D-REDS does not receive a new Relay Switch Request message in response to its Switch Delay change request, then it may continue using the current RDS for subsequent transmissions to the S-REDS. The Switch Delay value may be relative to the current Timing Synchronization Function (TSF) count. The RDS switch procedure may also be initiated by the D-REDS.

[0113] Figure 18 shows another variant of a channel access procedure which may allow for re-transmissions on each segment (S-REDS to RDS and RDS to D-REDS). Data transmission on the first segment (S-REDS to RDS) may be initiated by a Null-Data transmission 1802 by the active RDS (RDSl in this example). If the S-REDS (S) receives an acknowledgement frame 1804 in response signifying successful data transmission (or other indication of successful data transmission), then it may continue using the same RDS (RDSl in this example) for further transmissions. If, however, the S-REDS does not receive an acknowledgement 1804, it may re-transmit the data packet to the same relay (RDSl in this example). Multiple such retransmission attempts may be permissible as long as all data transmissions and re-transmissions, and associated acknowledgement transmissions, are completed within a time period equal to twice the Relay Period (with some time remaining at the end for the relay to initiate transmission on the second hop from RDSl to D-REDS). If the RDS initiates transmission to D-REDS (D) before the end of second Relay Period, this may indicate a valid link to the D- REDS. The D-REDS may continue using the current RDS (RDSl in this example) for further communications with the S-REDS.

[0114] If, on the other hand, data transmission between S-REDS and

RDSl fails (e.g., even after re-transmissions), and if no further retransmissions are possible before the end of the second Relay Period from the start of the transmissions, then the S-REDS may switch to the next relay identified earlier in the prioritized list. Likewise, the D-REDS may also simultaneously, substantially simultaneously, or subsequently switch its reception antenna configuration to point towards the next RDS in its priority list (RDS2 in this example). In this way, a substantially simultaneous switch may be performed from the active RDS to the next available back-up RDS at the start of the third Relay Period since the start of the current data transmissions.

[0115] Further, if data transmission between the Relay and D-REDS fails in the first attempt, then re-transmission may be attempted as long as the total time required for first transmission and any subsequent retransmissions along with associated acknowledgements is less than two Relay Periods. As long as the Relay responds back to the S-REDS within two Relay Periods of the last communication, the link to the Relay may be kept active and the S-REDS may not switch to a back-up Relay.

[0116] An example of power efficient operation of the S-REDS and the

D-REDS is discussed further herein. In this example, if the S-REDS completes its data packet transmission to RDS and receives an acknowledgement, it may enter a sleep state for the next Relay Period. Similarly, the D-REDS may conserve power and enter a sleep state after data transmission from RDS is completed and acknowledged and no further transmission is received within a Short Inter-frame Spacing (SIFS) interval after sending the acknowledgement.

[0117] The S-REDS or D-REDS may exit the sleep state and be ready for frame reception by the start of the next Relay Period following the power save state. The RDSs identified earlier to assist the current S-REDS and D-REDS may remain awake and point their reception antenna beams towards S-REDS during a first T_Wake duration of each Relay Period (which may be during each Service Period assigned to the S-REDS and D-REDS). If no transmission is received from the S-REDS during the T_Wake period from the start of a Relay Period, the RDS may enter the Sleep State for the remaining portion of the Relay Period. AH the RDSs may remain in reception mode for the first T_Wake period in each Service Period, unless they are making transmissions or waiting for acknowledgement from the D-REDS for previously transmitted data packets.

[0118] The following description may include end-to-end acknowledgements. Figure 19 illustrates an example procedure for end-to-end acknowledgement with dynamic relaying. Here, the S-REDS may initiate data transmission at the start of the 1st Period (Relay Period n in this example) to the relay hsted top-most in the priority list (which is RDSl in this example). If data transmission to RDSl does not succeed, then S-REDS may switch to the next relay in the list (RDS2 in this example), at the start of the next Relay Period (which is n+1 in this example). After transmitting the data frame, which may be an aggregated packet, the S-REDS may send a Block- Acknowledgement Request frame 1902 to the relay, RDS2. If a Block- Acknowledgement frame 1902 is successfully received, this indicates that the current link is valid. Re-transmissions may be permitted if they can be completed within the Relay Period.

[0119] At the start of the third Relay Period (n+2 in this example) the active relay, RDS2, may forward the data packets to the D-REDS. Additionally, at the start of the third Relay Period, the D-REDS may change its reception antenna configuration to point towards the next listed relay (RDS2 in this example). After sending the data packets, RDS2 may send a Block-Acknowledgement Request 1902 frame to the D-REDS. The D-REDS may respond with a Block Acknowledgement frame 1904. If any retransmissions are required, then they should be completed before the end of the current Relay Period, leaving sufficient time for Block-Acknowledgement Request 1902 and Block -Acknowledgement 1904 frame exchange.

[0120] In the subsequent Relay Period, (Relay Period n+3 in this example), the S-REDS may send a Relay Block -Acknowledgement Request frame 1906 to RDS2. In response, RDS2 may send a Relay Block- Acknowledgement frame 1908 to S-REDS, which may contain end-to-end acknowledgement for each individual data packet originally transmitted by S- REDS to RDS2 for forwarding to D-REDS. Any unacknowledged packets may be re-transmitted by S-REDS to RDS2, and subsequently forwarded to D- REDS by RDS2.

[0121] The S-REDS may transmit new data packets to the active relay,

RDS2, after any required re-transmissions, after determining that these transmissions would finish within the current Relay Period, with time remaining at the end of the Relay Period for Block- Acknowledgement Request 1902 and Block -Acknowledgement 1904 frame exchange.

[0122] Figure 20 illustrates an example procedure for channel access when data transmissions are initiated by the S-REDS. In this example, the 1st Period and 2nd Period may normally alternate in successive Relay Periods, which means that data packets may be transmitted from S-REDS to RDS and from RDS to D-REDS in subsequent Relay Periods. In case of packet reception errors, the S-REDS or RDS may initiate re-transmission, which may require an extra Relay Period.

[0123] If at the end of the second Relay Period the S-REDS does not receive a Block- Acknowledgement 2002 frame from the active relay (RDSl at start in the example), the S-REDS may switch its transmit antenna configuration and repeat the packet transmissions to the next relay in its prioritized list (RDS2 in the example). If a Block-Acknowledgement 2002 is received with some data packets unacknowledged, the S-REDS may initiate re-transmission of the unacknowledged packets if the total transmission time does not exceed twice the Relay Period, with sufficient time remaining at the end of the current Relay Period for a Block -Acknowledgement Request and Block -Acknowledgement frame exchange between the S-REDS and the current active relay. RDSl may initiate packet transmission to D-REDS before the end of the second Relay Period to keep the link to D-REDS active. At the end of the second Relay Period, if it does not receive any transmission from RDSl, D-REDS may reorient its reception antenna configuration towards the next relay in the prioritized list at the start of the next Relay Period.

[0124] In the next Relay Period (Relay Period n+2 in the example),

RDS2 may forward the data packets to D-REDS. D-REDS may respond with a Block -Acknowledgement frame 2002 after receiving the data frame from RDS2. In case of a missing Block- Acknowledgement frame or if there are some data packets that are unacknowledged 2004, RDS2 may not initiate retransmissions that cannot be completed and acknowledged within the current Relay Period. [0125] At the start of the next Relay Period (Relay Period n+4 in this example), S-REDS may transmit the next data frames to RDS2. However, RDS2 may acknowledge only those packets within the aggregated frame that it can accommodate in the transmission to D-REDS along with remaining unacknowledged packets from the previous transmission. The RDS2 may set the packet bits accordingly in the initial transmission and any subsequent retransmissions from S-REDS to limit the data flow until previously received packets are successfully transmitted to D-REDS.

[0126] An example procedure for assisted channel access (assisted by an

AP/PCP 2104) is shown in Figure 21. Here, all channel time allocations are made by the AP/PCP 2104. Additionally, the AP/PCP 2104 may choose a RDS to serve the S-REDS 2102 and D-REDS 2110 pair. Any change in RDS due to link failure may require signaling by the AP/PCP 2104 to reserve channel time through an alternate RDS.

[0127] Here, at the end of channel quality measurement procedure, the

AP/PCP 2104 may send a Relay Setup Response message to the S-REDS 2102, D-REDS 2102 and the chosen or highest priority RDS. In this example, RDSl 2106 is the highest priority RDS. If a link failure is detected between the S- REDS 2102 and RDSl 2106, due to failure to receive an ACK for a data transmission, the S-REDS 2102 may inform the AP/PCP 2104. The AP/PCP 2104 may then notify the RDS next in the priority list (here RDS2 2108), and may also inform the S-REDS 2102 and D-REDS 2110 about the change. The link failure may be indicated in the Relay Setup Request message and the new RDS association identifier (AID) is notified in the Relay Setup Response messages to the S-REDS 2102, RDS 2108, and D-REDS 2110. After the identity of the new RDS 2108 is sent to the three nodes, the next data transfer between the S-REDS 2102 and the D-REDS 2110 may take place using the new RDS (RDS2 2108 in this example) as the Relay. Accordingly, the S-REDS 2102 and the D-REDS 2110 may orient their transmission and reception beams towards RDS2 2108 at the start of the next scheduled data transfer interval. [0128] Implementations involving multiple simultaneous active relays are discussed further herein. Typical relay operations using a single active relay associated with a S-REDS and D-REDS may result in inefficient channel utilization because at any time only one of the two links is utilized and either the S-REDS or D-REDS transmits or receives data. Channel utilization may be improved by using additional relays between the S-REDS and D-REDS.

[0129] Here, the concept of Relay Periods introduced earlier is used. In each Relay Period, the link between the S-REDS and one of the relays (RDS 1 or RDS2) may be active and simultaneously (or substantially simultaneously) the link between the D-REDS and another relay (RDS2 or RDSl) may active. Therefore, in each Relay Period, two links are simultaneously (or substantially simultaneously) active. This mode of operation may be feasible when the mutual interference between the links between the S-REDS and the D-REDS and the two relays (RDSl and RDS2) is negligible. The transmission schedule may be determined by the S-REDS. The amount of data transmitted by S- REDS to RDSl or RDS2 in any Relay Period may be determined not only by the throughput on the S-REDS-RDSl or S-REDS-RDS2 link, but also of that on the second hop from RDSl or RDS2 to D-REDS. Further, this procedure may be implemented using multiple relays between a S-REDS and D-REDS pair over more than two consecutive Relay Periods to maximize channel utilization and throughput considering the mutual interference between the nodes.

[0130] Figure 22 is a signal diagram illustrating an example of variable channel allocation for source-relay (first transmission period) and relay- destination (second transmission period) transmissions. FIGS. 23A, 23B, 23C, and 23D are signal diagrams illustrating an example of variable channel allocation for source-relay (first transmission period) and relay- destination (second transmission period) transmissions. Figure 24 is a signal diagram illustrating an example of dynamic the first transmission period and the second transmission period (mode 2, delayed B-ACK). Figure 25 is a signal diagram illustrating an example of dynamic relay selection (relay controls channel access). Figure 26 is a signal diagram illustrating an example of dynamic relay selection (source controls channel access). Figure 27 is a diagram illustrating example transmissions where there are multiple simultaneous (or substantially simultaneous) active relays.

[0131] Although the solutions described herein consider 802.11 specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0132] Although features and elements are described 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. 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, 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.

^• * *

Claims

CLAIMS What is claimed is:

1. A method for relay communications comprising:

transmitting, by a source device, forward link data to a first relay device in a first portion of a first transmission period, wherein the first relay device is ranked high on a predetermined priority list of the source device and a destination device, and wherein the destination device is directionally aligned with the first relay device to receive the forward link data in a second transmission period;

upon not receiving an acknowledgment from the first relay device within a first two consecutive relay periods of a transmission cycle, transmitting, by the source device, the forward link data in a second portion of the first transmission period to a second relay device before the end of a second two consecutive relay periods of the transmission cycle, wherein the second relay device is ranked below the first relay device in the predetermined priority hst, and wherein the destination device is directionally aligned with the second relay device at the start of the second two consecutive relay periods;

receiving, by the source device, an acknowledgment from the second relay device; and

receiving, by the source device, a null data frame indicating a successful transmission of the forward link data from the second relay device to the destination device in the second transmission period.

2. The method of claim 1, wherein the first transmission period is of a different duration than the second transmission period.

3. The method of claim 1, wherein a duration of the first transmission period and a duration of the second transmission period are determined dynamically.

4. The method of claim 1, wherein a duration of the first transmission period and a duration of the second transmission period are determined by the amount of data to be transmitted in each period.

5. The method of claim 1, wherein a duration of the first transmission period and a duration of the second transmission period are determined by a channel quality between the devices.

6. The method of claim 1, wherein a duration of the first transmission period and a duration of the second transmission period are determined by a number of retry attempts required for successful retransmission.

7. The method of claim 1, wherein the predetermined priority list is determined by the source device by:

collecting at least one channel measurement report relating to channel conditions between the source device and potential relay device;

determining a priority order of the potential relay devices based on the at least one channel measurement report,

transmitting a request message to each potential relay device for relay to the destination device, wherein the request message includes the identities of the source device, potential relay device, and destination device, and

receiving a response message from the destination device via at least one potential relay device, wherein the response message includes an indication of whether the destination device accepts the potential relay device as a relay node, and an indication of whether the potential relay device accepts a role as a relay node.

8. The method of claim 1, wherein the predetermined priority list is determined by an access point (AP) by: determining a beamforming training schedule for pairwise beamforming training between nodes including the source device, the destination device, and at least one relay device;

identifying a list of at least one potential relay device;

collecting at least one beamforming training report indicating received signal power between each pair of nodes during beamforming training;

determining end-to-end channel quality between the source device and the destination device on a direct hnk and via the at least one relay device; determining a priority order for the potential relay devices; and transmitting at least one message to the nodes including the priority order.

9. The method of claim 1, further comprising:

retransmitting, by the source device, the forward link data to the first relay device within the first two consecutive relay periods if the acknowledgment from the first relay device is not received.

10. The method of claim 1, further comprising:

transmitting, by the source device, a request to the destination device via the second relay device directing the destination device to directionally align itself with a new relay device at the beginning a future relay period.

11. The method of claim 10, further comprising:

receiving, at the source device, a reply from the destination device via the second relay device proposing an alternative directional alignment.

12. The method of claim 1, further comprising:

upon the receiving, at the source device, the acknowledgement from the second relay device, powering down the source device until the start of a next relay period.

13. The method of claim 1, further comprising:

upon the successful transmission of the forward link data from the second relay device to the destination device in the second transmission period, powering down the destination device until the start of a next relay period.

14. The method of claim 1, further comprising:

transmitting, by the source device, a first Block-Acknowledgement Request (BAR) to the second relay device;

receiving, by the source device, a first Block Acknowledgement (BA) from the second relay device, wherein the first BA indicates a successful transmission between the source device and the second relay;

transmitting, by the source device, a Relay-BAR to the second relay device; and

receiving, by the source device, a Relay-BA from the second relay device, wherein the Relay-BA indicates a successful transmission of the forward link data from the second relay device to the destination device as determined by an exchange of a second BA and a second BAR between the second relay device and the destination device.

15. A method for relay communications comprising:

transmitting, by a relay device, a first grant message to a source device at the beginning of a first two consecutive relay periods of a transmission cycle, wherein the first grant message indicates a maximum duration available for a transfer of forward link data in a first transmission period; receiving, by the relay device, the forward link data from the source device in the first transmission period within the first two consecutive relay periods;

transmitting, by the relay device, a second grant message to a destination device within the first two consecutive relay periods, wherein the second grant message indicates that a connection between the relay device and the destination device is active and should not be changed by the destination device;

transmitting, by the relay device, first reverse link data to the source device in a second portion of the first transmission period before the end of a second two consecutive relay periods of the transmission cycle;

transmitting, by the relay device, the forward link data to the destination device in a first portion of a second transmission period before the end of a third two consecutive relay periods of the transmission cycle;

receiving, by the relay device, second reverse link data from the destination device in a second portion of the second transmission period before the end of the third two consecutive relay periods; and

transmitting, by the relay device, a third grant frame to the source device before the end of the third two consecutive relay periods, wherein the third grant message indicates that a connection between the relay device and the source device is active and should not be changed by the source device.

16. The method of claim 15, wherein the first transmission period is of a different duration than the second transmission period.

17. The method of claim 15, wherein a duration of the first transmission period and a duration of the second transmission period are determined dynamically.

18. The method of claim 15, wherein a duration of the first transmission period and a duration of the second transmission period are determined by the amount of data to be transmitted in each period.

19. The method of claim 15, wherein a duration of the first transmission period and a duration of the second transmission period are determined by a channel quality between the devices.

20. The method of claim 15, wherein a duration of the first transmission period and a duration of the second transmission period are determined by a number of retry attempts required for successful retransmission.