Patent ID: 12192811

DETAILED DESCRIPTION

FIG.1Ais a diagram of an example communications system100in which one or more disclosed embodiments may be implemented. The communications system100may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system100may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems100may 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.

As shown inFIG.1A, the communications system100may include wireless transmit/receive units (WTRUs)102a,102b,102c,102d, a radio access network (RAN)104, a core network106, a public switched telephone network (PSTN)108, the Internet110, and other networks112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs102a,102b,102c,102dmay be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs102a,102b,102c,102dmay 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.

The communications systems100may also include a base station114aand a base station114b. Each of the base stations114a,114bmay be any type of device configured to wirelessly interface with at least one of the WTRUs102a,102b,102c,102dto facilitate access to one or more communication networks, such as the core network106, the Internet110, and/or the networks112. By way of example, the base stations114a,114bmay 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 stations114a,114bare each depicted as a single element, it will be appreciated that the base stations114a,114bmay include any number of interconnected base stations and/or network elements.

The base station114amay be part of the RAN104, 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 station114aand/or the base station114bmay 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 station114amay be divided into three sectors. Thus, in one embodiment, the base station114amay include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station114amay employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

The base stations114a,114bmay communicate with one or more of the WTRUs102a,102b,102c,102dover an air interface116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface116may be established using any suitable radio access technology (RAT).

More specifically, as noted above, the communications system100may 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 station114ain the RAN104and the WTRUs102a,102b,102cmay implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface116using 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).

In another embodiment, the base station114aand the WTRUs102a,102b,102cmay implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface116using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station114aand the WTRUs102a,102b,102cmay implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, 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.

The base station114binFIG.1Amay 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 station114band the WTRUs102c,102dmay implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station114band the WTRUs102c,102dmay implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station114band the WTRUs102c,102dmay utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown inFIG.1A, the base station114bmay have a direct connection to the Internet110. Thus, the base station114bmay not be required to access the Internet110via the core network106.

The RAN104may be in communication with the core network106, 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 WTRUs102a,102b,102c,102d. For example, the core network106may 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 inFIG.1A, it will be appreciated that the RAN104and/or the core network106may be in direct or indirect communication with other RANs that employ the same RAT as the RAN104or a different RAT. For example, in addition to being connected to the RAN104, which may be utilizing an E-UTRA radio technology, the core network106may also be in communication with another RAN (not shown) employing a GSM radio technology.

The core network106may also serve as a gateway for the WTRUs102a,102b,102c,102dto access the PSTN108, the Internet110, and/or other networks112. The PSTN108may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet110may 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 networks112may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks112may include another core network connected to one or more RANs, which may employ the same RAT as the RAN104or a different RAT.

Some or all of the WTRUs102a,102b,102c,102din the communications system100may include multi-mode capabilities, i.e., the WTRUs102a,102b,102c,102dmay include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU102cshown inFIG.1Amay be configured to communicate with the base station114a, which may employ a cellular-based radio technology, and with the base station114b, which may employ an IEEE 802 radio technology.

FIG.1Bis a system diagram of an example WTRU102. As shown inFIG.1B, the WTRU102may include a processor118, a transceiver120, a transmit/receive element122, a speaker/microphone124, a keypad126, a display/touchpad128, non-removable memory106, removable memory132, a power source134, a global positioning system (GPS) chipset136, and other peripherals138. It will be appreciated that the WTRU102may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

The processor118may 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 processor118may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102to operate in a wireless environment. The processor118may be configured to perform any of the methods described below.

The processor118may be coupled to the transceiver120, which may be coupled to the transmit/receive element122. WhileFIG.1Bdepicts the processor118and the transceiver120as separate components, it will be appreciated that the processor118and the transceiver120may be integrated together in an electronic package or chip.

The transmit/receive element122may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station114a) over the air interface116. For example, in one embodiment, the transmit/receive element122may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element122may 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 element122may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element122may be configured to transmit and/or receive any combination of wireless signals.

In addition, although the transmit/receive element122is depicted inFIG.1Bas a single element, the WTRU102may include any number of transmit/receive elements122. More specifically, the WTRU102may employ MIMO technology. Thus, in one embodiment, the WTRU102may include two or more transmit/receive elements122(e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface116.

The transceiver120may be configured to modulate the signals that are to be transmitted by the transmit/receive element122and to demodulate the signals that are received by the transmit/receive element122. As noted above, the WTRU102may have multi-mode capabilities. Thus, the transceiver120may include multiple transceivers for enabling the WTRU102to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

The processor118of the WTRU102may be coupled to, and may receive user input data from, the speaker/microphone124, the keypad126, and/or the display/touchpad128(e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor118may also output user data to the speaker/microphone124, the keypad126, and/or the display/touchpad128. In addition, the processor118may access information from, and store data in, any type of suitable memory, such as the non-removable memory106and/or the removable memory132. The non-removable memory106may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory132may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor118may access information from, and store data in, memory that is not physically located on the WTRU102, such as on a server or a home computer (not shown).

The processor118may receive power from the power source134, and may be configured to distribute and/or control the power to the other components in the WTRU102. The power source134may be any suitable device for powering the WTRU102. For example, the power source134may 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.

The processor118may also be coupled to the GPS chipset136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU102. In addition to, or in lieu of, the information from the GPS chipset136, the WTRU102may receive location information over the air interface116from a base station (e.g., base stations114a,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 WTRU102may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

The processor118may further be coupled to other peripherals138, 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 peripherals138may 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.

FIG.1Cis a system diagram of the RAN104and the core network106according to an embodiment. The RAN104may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs102a,102b,102cover the air interface116. As will be further discussed below, the communication links between the different functional entities of the WTRUs102a,102b,102c, the RAN104, and the core network106may be defined as reference points.

As shown inFIG.1C, the RAN104may include base stations140a,140b,140c, and an ASN gateway142, though it will be appreciated that the RAN104may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations140a,140b,140cmay each be associated with a particular cell (not shown) in the RAN104and may each include one or more transceivers for communicating with the WTRUs102a,102b,102cover the air interface116. In one embodiment, the base stations140a,140b,140cmay implement MIMO technology. Thus, the base station140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU102a. The base stations140a,140b,140cmay also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway142may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network106, and the like.

The air interface116between the WTRUs102a,102b,102cand the RAN104may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs102a,102b,102cmay establish a logical interface (not shown) with the core network106. The logical interface between the WTRUs102a,102b,102cand the core network106may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

The communication link between each of the base stations140a,140b,140cmay be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations140a,140b,140cand the ASN gateway215may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs102a,102b,100c.

As shown inFIG.1C, the RAN104may be connected to the core network106. The communication link between the RAN104and the core network106may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network106may include a mobile IP home agent (MIP-HA)144, an authentication, authorization, accounting (AAA) server146, and a gateway148. While each of the foregoing elements are depicted as part of the core network106, 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.

The MIP-HA may be responsible for IP address management, and may enable the WTRUs102a,102b,102cto roam between different ASNs and/or different core networks. The MIP-HA144may provide the WTRUs102a,102b,102cwith access to packet-switched networks, such as the Internet110, to facilitate communications between the WTRUs102a,102b,102cand IP-enabled devices. The AAA server146may be responsible for user authentication and for supporting user services. The gateway148may facilitate interworking with other networks. For example, the gateway148may provide the WTRUs102a,102b,102cwith access to circuit-switched networks, such as the PSTN108, to facilitate communications between the WTRUs102a,102b,102cand traditional land-line communications devices. In addition, the gateway148may provide the WTRUs102a,102b,102cwith access to the networks112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

Although not shown inFIG.1C, it will be appreciated that the RAN104may be connected to other ASNs and the core network106may be connected to other core networks. The communication link between the RAN104the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs102a,102b,102cbetween the RAN104and the other ASNs. The communication link between the core network106and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

The other networks112may further be connected to an IEEE 802.11 based wireless local area network (WLAN)160. The WLAN 160 may include an access router165. The access router may contain gateway functionality. The access router165may be in communication with a plurality of access points (APs)170a,170b. The communication between access router165and APs170a,170bmay be via wired Ethernet (IEEE 802.3 standards) or any type of wireless communication protocol. The AP170ais in wireless communication over an air interface with the WTRU102d. The APs170a,170bmay be configured to perform any of the methods described below.

Group ID for Group Frame Exchange

The devices in a group may be a mix of legacy and new devices; a mix of devices that support different data rate, code, modulation, or transmission schemes (e.g., space-time block coding (STBC) and non-STBC); or devices that are not legacy devices.

When using a group ID, STAs are assigned to a group and are attributed certain group features. The group ID information includes one or more of: a group identification which identifies the group; an address or identifier for each device belonging to the group; an address or identifier for each device belonging to the group that may be recognizable by all the other devices belonging the group; group characteristics, properties, or rules; an order, sequence, or schedule of the group members; or allocation of OFDMA sub-carrier frequencies.

The term “order of the group members” (or “order”) also includes a sequence of the group members or a schedule of the group members. The order of the group members may be specified in any of the following ways: order or sequence information indicating an ascending or descending order; timing information, e.g., a transmission time with respect to a reference time; allocation of frequencies to devices for transmission or reception (e.g., OFDMA sub-carrier frequencies); explicitly specified along with the group ID; implicitly associated with the group ID and specified elsewhere, e.g., with a management frame, control frame, or data frame exchange; or implicitly derived from the group ID using a specified rule or procedure.

Devices to be engaged in a group transmission or group frame exchange are assigned to a group with a group ID. A device may be assigned to or belong to more than one group. The group ID assignment may be made using a data frame, a control frame, or a management frame.

The group ID may be included in any MAC frame field. For example, the group ID may be included in a MAC address field in any data frame, control frame, or management frame for group frame exchange, group management, or group control purposes. For example, the group ID may be included in one or more of the following MAC address fields: transmitting STA address (TA), receiving STA address (RA), source address (SA), or destination address (DA).

The interframe spacing (IFS) between the frames in any of the frame exchange sequences described below may be set or designed as appropriate for system implementation. For example, the IFS in the frame exchange sequences may be set as any of the following time intervals: a multiple of a slot time, Reduced IFS (RIFS), a multiple of RIFS, Short IFS (SIFS), a multiple of SIFS, Point Coordination Function IFS (PIFS), or a multiple of PIFS.

It is noted that although the following embodiments may be described in connection with DL MU-MIMO, DL OFDMA, or DL group transmission, these embodiments may also be applicable to UL MU-MIMO, UL OFDMA, or UL group frame exchange. The following embodiments may be applied to all group transmissions where more than two devices are involved in packet transmissions or frame exchange (e.g., MU-MIMO, Power Saving), although some of the embodiments may be described in terms of MU-MIMO or OFDMA transmissions.

RTS and CTS for Group Frame Exchange

To reserve the medium for a group frame exchange, a device may send an RTS frame (including the group ID) addressed to the group as the first frame of a frame exchange sequence. Any device not associated with the group ID that receives the RTS frame sets its NAV based on the duration field in the RTS frame.

In response to the RTS frame, a recipient device belonging to the group sends a CTS frame addressed to the group ID, in an order with respect to other devices belonging to the group. The order for transmitting CTS frames may be derived by the devices in the group from the order associated with the group ID. Any device not associated with the group ID that receives the CTS frame sets its NAV based on the duration field in the CTS frame. In this way, the NAV may be set for all other devices not belonging to the group ID in the neighborhoods of the devices belonging to the group frame exchange.

A device belonging to the group considers its order associated within the group when setting the duration field of its CTS frame. For example, a device that is second in order for responding with a CTS frame sets the duration field in the CTS frame as the duration value obtained from the RTS frame minus two times the time required to transmit a CTS frame plus its SIFS interval (or other interframe spacing interval).

In general, a device that is Nth in order for responding with a CTS frame sets the duration field in the CTS frame as the duration value obtained from the duration field of the RTS frame minus N×(the time required to transmit a CTS frame+a SIFS interval or other interframe spacing interval) where N is an integer greater than or equal to one. Such an RTS and CTS frame exchange mechanism mitigates the hidden node problem when more than two devices (e.g., one AP and two or more STAs, or three or more STAs) are involved in a group frame exchange sequence. Sending the response frame in sequence has a higher delay in sending the response frames, but has lower system complexity.

FIG.2is a flow diagram of a NAV protection procedure200with RTS and CTS frames for a group frame exchange when the response frames are sent in sequence. The NAV protection procedure200involves an AP or STA0202(referred to hereafter as AP202), a first station STA1204, and a second station STA2206. STA1204is before STA2206in the order associated with the group. It is noted that the procedure200will work with any number of stations.

The AP202sends a RTS frame addressed to the group by including the group ID in the RA field (step210). Any STAs not in the group set their NAV based on the duration field in the RTS frame (step212). STA1204responds first with a CTS frame with the RA field containing the group ID (step214). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step216), if the new NAV value is longer than the NAV value from the RTS frame or if a STA receiving the CTS frame from STA1did not receive the RTS frame from AP0.

Then STA2206sends a CTS frame with the RA field containing the group ID (step218). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step220), if the new NAV value is longer than the NAV value from the RTS frame or from the CTS frame from STA1204or if a STA receiving the CTS frame from STA2did not receive the RTS frame from AP0or the CTS frame from STA1.

The AP202sends a group frame with data and a BAR to STA1204and data and a BAR to STA2206(step230). In an OFDMA implementation, the group frame is transmitted to STA1204and STA2206on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1204and STA2206on the same frequency. Following the same order as with sending the CTS frames, STA1204first sends a response frame to the group ID (step232). Then STA2206sends a response frame to the group ID (step234). The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

FIG.3is a flow diagram of a NAV protection procedure300with RTS and CTS frames for a group frame exchange when the response frames are sent at the same time. The NAV protection procedure300involves an AP or STA0302(referred to hereafter as AP302), a first station STA1304, and a second station STA2306. STA1304is before STA2306in the order associated with the group. It is noted that the procedure300will work with any number of stations.

The AP302sends a RTS frame addressed to the group by including the group ID in the RA field (step310). Any STAs not in the group set their NAV based on the duration field in the RTS frame (step312). STA1304responds first with a CTS frame with the RA field containing the group ID (step314). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step316), if the new NAV value is longer than the NAV value from the RTS frame or if a STA receiving the CTS frame from STA1did not receive the RTS frame from AP0.

Then STA2306sends a CTS frame with the RA field containing the group ID (step318). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step320), if the new NAV value is longer than the NAV value from the RTS frame or from the CTS frame from STA1304or if a STA receiving the CTS frame from STA2did not receive the RTS frame from AP0or the CTS frame from STA1.

The AP302sends a group frame with data and a BAR to STA1304and data and a BAR to STA2306(step330). In an OFDMA implementation, the group frame is transmitted to STA1304and STA2306on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1304and STA2306on the same frequency.

STA1304sends a response frame to the group ID (step332) at the same time that STA2306sends a response frame to the group ID (step334). In an OFDMA implementation, the response frames are transmitted by STA1304and STA2306on their allocated frequencies. Sending the response frames by STA1and STA2at the same time, using MU-MIMO or OFDMA, has a lower delay in sending the response frames, but has a higher system complexity. The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

In the procedures200and300, where the CTS frame addressed to the group ID is sent in response to an RTS in the group frame exchange, a CTS frame addressed to the device transmitting the RTS frame may be used instead, with all the other procedures and rules being the same. The RA field in the CTS frame in this case contains either the special identifier of the device transmitting the RTS frame that may be recognizable by all the devices in the group as part of the group ID, or the MAC address of device that sent the RTS frame.

The RTS frame may include an indication using one or more bits that requires other devices associated with the group ID to respond with CTS frames. In one embodiment, this indication may be in the PHY preamble of the RTS frame.

The RTS frame may carry the group ID information in either the PHY preamble or in MAC layer fields following the MAC address fields. In these scenarios, the RA field of the RTS frame may contain a broadcast ID or a general group ID representing all group transmissions (e.g., MU-MIMO or OFDMA). Also, if the PHY preamble of the RTS frame is modified, then the legacy signal (L-SIG) transmit opportunity (TXOP) protection as defined in IEEE 802.11n may be used for setting the NAV of legacy devices, because the legacy devices may not understand or decode the modified PHY preamble of the RTS frame. Alternatively, a legacy format frame (e.g., CTS to self) may be sent before the RTS frame to set the NAV appropriately.

There are three options for the TA field of the RTS frame addressed to a group ID, as shown inFIG.4. A first option of the RTS frame400includes a frame control field402, a duration field404, a RA field406that includes the group ID, a TA field408that includes the group ID, and a frame check sequence (FCS) field410.

A second option of the RTS frame420includes the frame control field402, the duration field404, the RA field406, a TA field422that includes the address of the device transmitting the RTS frame, and the FCS field410.

A third option of the RTS frame440includes the frame control field402, the duration field404, the RA field406, a TA field442that may be empty or contains no address, and the FCS field410.

FIG.5shows a CTS frame500, including a frame control field502, a duration field504, a RA field506containing the group ID, and a FCS field508.

Response Frames in Group Frame Exchange

Devices in the group that received data in the DL group transmission may include the group ID in the RA field of their response frames, such as ACK or block ACK, or any other type of response frame allowed or required by the MAC protocol. The response frames set the NAV of all the devices except the ones belonging to the group. Alternatively, the devices sending the response frames may include the individual MAC address of the intended recipient device (the device that sent the data or other frames, such as BAR, which required these response frames to be sent) in the RA field of their response frames such as ACK or block ACK.

In a first option (e.g., as shown inFIG.2), the response frames from the responding devices in the group may be sent in a specific order. The order for transmitting the response frames may be derived by the devices in the group from the order information associated with the group ID, or the order information provided by the initiating device in earlier frames. The order information may also be specified as timing information, e.g., a transmission time with respect to a reference time. In a second option (e.g., as shown inFIG.3), the response frames from the responding devices in the group may be sent at the same time, for example, by using MU-MIMO or OFDMA.

A device belonging to the group considers its order associated with the group in setting the duration field of its response frame, such as ACK or block ACK. In general, the duration fields in the response frames are set to protect the desired group frame exchange sequence.

The responding devices may obtain scheduling information for sending response frames from the group ID information associated with the group members or from the BAR frame sent by the device. The scheduling information for sending response frames may include one or more of: an order, allocated frequencies, or time information. The time information may include the time to begin transmission or information from which the time to begin transmission may be derived.

In general, a device that is Nth in order for responding with an ACK frame to an initiating device transmits an ACK frame at a delay of (N−1) times the time required to transmit an ACK frame plus N times a SIFS interval (or other interframe spacing interval), after the frame from the initiating device to which the ACK frame is a response. In other words, the delay in ACK frame transmission of a responding device which is Nth in order for responding is (N−1)×(transmit time of an ACK frame)+N×(SIFS or other interframe spacing interval), where N is an integer value greater than or equal to one.

CTS to Group ID for Group Frame Exchange

To reserve the medium for a group frame exchange, a device may send a CTS frame addressed to the group ID as the first frame of a frame exchange sequence. Any device not associated with the group ID that receives the CTS frame sets its NAV based on the duration field of the CTS frame. In this way, the NAV may be set for all other devices not belonging to the group in the neighborhoods of the devices belonging to the group frame exchange.

The device may optionally send the CTS to group ID frame more than once sequentially, to increase the chance that all devices in the BSS receive it. The number of repetitions of sending the CTS to group ID frame may be an operational system parameter. The CTS to group ID mechanism mitigates the hidden node problem when more than two devices (e.g., one AP and two or more STAs, or three or more STAs) are involved in a group frame exchange sequence.

FIG.6is a flow diagram of a NAV protection procedure600with a CTS frame sent to a group ID for a group frame exchange when the response frames are sent in sequence. The NAV protection procedure600involves an AP or STA0602(referred to hereafter as AP602), a first station STA1604, and a second station STA2606. STA1604is before STA2606in the order associated with the group. It is noted that the procedure600will work with any number of stations.

The AP602sends a CTS frame addressed to the group by including the group ID in the RA field (step610). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step612).

The AP602sends a group frame with data and a BAR to STA1604and data and a BAR to STA2606(step614). In an OFDMA implementation, the group frame is transmitted to STA1604and STA2606on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1604and STA2606on the same frequency.

The STA1604sends a response frame to the group ID (step616). Then STA2606sends a response frame to the group ID (step618). Sending the response frame in sequence has a higher delay in sending the response frames, but has lower system complexity. The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

FIG.7is a flow diagram of a NAV protection procedure700with a CTS frame sent to a group ID for a group frame exchange when the response frames are sent at the same time. The NAV protection procedure700involves an AP or STA0702(referred to hereafter as AP702), a first station STA1704, and a second station STA2706. STA1704is before STA2706in the order associated with the group. It is noted that the procedure700will work with any number of stations.

The AP702sends a CTS frame addressed to the group by including the group ID in the RA field (step710). Any STAs not in the group set their NAV based on the duration field in the CTS frame (step712).

The AP702sends a group frame with data and a BAR to STA1704and data and a BAR to STA2706(step714). In an OFDMA implementation, the group frame is transmitted to STA1704and STA2706on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1704and STA2706on the same frequency.

STA1704sends a response frame to the group ID (step716) at the same time that STA2706sends a response frame to the group ID (step718). In an OFDMA implementation, the response frames are transmitted by STA1704and STA2706on their allocated frequencies. Sending the response frames by STA1and STA2at the same time, using MU-MIMO or OFDMA, has a lower delay in sending the response frames, but has a higher system complexity. The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

In the procedures600and700, where the CTS frame with an RA field containing the group ID is the first packet transmission by a device in a frame exchange sequence, a CTS frame addressed to the device transmitting the CTS frame (i.e., addressed to self) may be used instead, with all the other procedures and rules being the same. The address or identifier used by the device in the RA field of the CTS to represent itself may be the device's MAC address, a newly defined address or identifier that is recognizable by all the other devices belonging the group, or an existing address or identifier that is recognizable by the other devices belonging the group.

Error Recovery in Group Frame Exchange

If a device sends an RTS to group ID frame and does not receive one or more expected CTS frames from the devices in the group, there may be an error. The device may recover from the error by attempting to reclaim the wireless medium or by ignoring the CTS failure.

The device may attempt to reclaim the wireless medium as soon as it detects a failure of an expected CTS reception, after sensing the channel as idle for a certain duration, e.g., PIFS. The device may then restart the procedure by sending the RTS to group ID frame or starting a CTS to group ID NAV protection procedure.

Alternatively, the device waits for the last CTS frame from the group and then attempts to reclaim the wireless medium after sensing the channel as idle for a certain duration, e.g., PIFS. The device then restarts the procedure by sending the RTS to group ID frame or starting a CTS to group ID NAV protection procedure.

The device may ignore the failure of an expected CTS frame reception and continue as if the expected CTS frame was received.

Due to poor communication links, BAR and BA frames may be not be successfully received by the intended recipient devices. If the initiating device does not receive an expected BA frame from a responding device, it may retransmit an updated BAR frame with the latest information to that responding device.

In one option, after the device senses the medium as being idle for a specified period of time after the BA response is expected, the device may retransmit the updated BAR frame if there is enough time remaining in the TXOP of the device. In a second option, the device may retransmit the updated BAR frame in a new transmission opportunity obtained after the completion of the current group frame exchange or group transmission.

Special Notes on Preceding Embodiments

The RTS and CTS frame exchange mechanisms as described above may be applied on all frequency channels, e.g., the primary channel and the secondary channels of an 802.11 BSS. For example, the RTS and CTS frame exchange mechanism may be repeated in each 20 MHz channel used by the system or BSS. This may be useful when there are both 20 MHz and 40 MHz capable devices in operation. Alternatively, if all of the devices operating in the system have a common bandwidth (e.g., 20 MHz, 40 MHz, or 80 MHz), then the RTS and CTS frame exchange mechanism may be carried out once in the common bandwidth.

The AP and STAs may indicate the capability to support one or more aspects of the communication mechanisms for group transmissions using one or more bits in any new or existing frames. For example, the indicator may be used in management frames such as association request, association response, re-association request, re-association response, probe request, probe response, beacon, or secondary or auxiliary beacon frames. In one embodiment, this capability indication may be included in a VHT capability information element which may be included in any of the above-listed frames.

It is noted that although the above embodiments for group transmissions have been described in terms of the RTS and CTS frames, these embodiments are applicable to any other data frame, management frame, or control frame that serves the same or a similar purpose or exhibits the same or similar functionality of the RTS and CTS frames. For example, the RTS frame may be replaced by a different frame (e.g., a newly defined Initiator Control frame) that exhibits the same or a similar functionality of the RTS frame. Similarly, the CTS frame may be replaced by a different frame (e.g., a newly defined Responder Control frame) that exhibits the same or a similar functionality of the CTS frame.

Sounding for Group Frame Exchange

A channel sounding mechanism may be used to obtain as full a characterization or estimate of the channel as possible in a group transmission scenario, such as MU-MIMO. Even when MU-MIMO is not used, acquiring knowledge of the channel by a device using sounding mechanisms prior to transmission allows performance optimization for single antenna or multiple antenna systems. One example of this type of sounding mechanism includes a scenario where no MU-MIMO is used, but OFDMA is used in group transmissions.

When using MIMO techniques, the beamformer device (AP or STA) calculates the appropriate steering or beamforming parameters based on an estimate of the transmission channel. This calculation of steering or beamforming parameters may use implicit or explicit feedback mechanisms with the beamformee device.

In the implicit feedback mechanism, the beamformer sends a training request to the beamformees in the group frame exchange. Each beamformee responds with training symbols in a sounding packet or frame, which allows the beamformer to estimate the channel. The channel estimate allows the beamformer to calculate appropriate steering or beamforming parameters, on the assumption that the channel is reciprocal; typically, calibration of radios is used to improve reciprocity. The order in which beamformees in the group frame exchange transmit the sounding frames is determined by the order associated with the group frame exchange or group ID.

In the explicit feedback mechanism, the beamformer device sends training symbols in a sounding frame to the beamformees in the group frame exchange, which allows each beamformee device to estimate the channel. A beamformee device responds, including information on the channel estimate (which may be quantized or modified for feedback) in a sounding response frame. The feedback information on the channel estimate allows the beamformer to calculate appropriate steering or beamforming parameters. The order in which beamformees in the group frame exchange transmit the sounding response frames is determined by the order associated with the group frame exchange or group ID.

Sounding with Implicit Feedback for Group Frame Exchange

In an implicit feedback mechanism, the beamformer device sends a sounding request to all the beamformee devices. The beamformee devices reply to the sounding request with training symbols, in the form of a sounding packet or frame. The sounding frame includes a sufficient number of training symbols or fields in the preamble portion to sound the full dimensionality of the channel. One or more bits in the preamble may be used to indicate whether the packet is a sounding frame. The sounding request frame may contain scheduling information for the sounding frames from the beamformees. The sounding request frame and the sounding frame may be any data frame, management frame, or control frame.

The sounding request frame in the group frame exchange includes a sounding or training request and is addressed to all the beamformee devices associated with the group ID. The training request may be included in a VHT control field sent with the sounding request frame. When a beamformee in the group receives a sounding request frame with a training request, the beamformee responds with a sounding frame. The sounding frame includes training symbols for the beamformer.

The order for transmitting sounding frames may be derived by the beamformee devices in the group from the order information associated with the group ID or the order information provided by the beamforming device in earlier frames (e.g., in the sounding request frame). The sequence of sounding frames may be sent immediately or delayed. When sent immediately, the sounding frame follows the sounding request frame from the beamformer at a delay of a SIFS interval (or other interframe spacing interval). When sent delayed, the sounding frame is sent at a delay of more than a SIFS interval (or other interframe spacing interval) after the sounding request frame from the beamformer.

The interframe spacing (IFS) between the frames (e.g., sounding request, sounding, or sounding response) in the frame exchange sequences may be set or designed as appropriate for system implementation. For example, the IFS may be set as any of the following: a multiple of a slot time, RIFS, a multiple of RIFS, SIFS, a multiple of SIFS, PIFS, or a multiple of PIFS.

FIG.8is a flow diagram of a sounding procedure800with implicit feedback for a group frame exchange. The sounding procedure800involves an AP or STA0802which is the beamformer (referred to hereafter as AP802), a first station STA1804, and a second station STA2806. STA1804and STA2806are both beamformees. STA1804is before STA2806in the order associated with the group. It is noted that the procedure800will work with any number of stations. While the procedure800is described in terms of an AP being the beamformer, this is one example embodiment, and any STA may be the beamformer.

The AP802sends a sounding request frame addressed to the group by including the group ID in the RA field (step810). In one implementation, the sounding request frame may be a RTS frame, and may use a legacy frame format or L-SIG TXOP protection for supporting legacy devices. The sounding request frame may have its RA field include one or more of: the group ID, its individual MAC address, a newly defined address or identifier that is recognizable by all the other devices belonging the group, or an existing address or identifier that is recognizable by the other devices belonging the group.

The sounding request frame may include an indication using one or more bits that requires the beamformee devices associated with the group ID to respond with sounding response frames. In one embodiment, this indication may be in the PHY preamble of the sounding request frame. The sounding request frame may also include the group ID information in either the PHY preamble (e.g., in the VHT-SIG fields) or in MAC layer fields (e.g., in the RA field). In these scenarios, the RA field of the sounding request frame may include a broadcast ID, or a general group ID representing all group transmissions. Also, if the PHY preamble of the sounding request frame is modified, then L-SIG TXOP protection may be used for NAV setting of legacy devices, because the legacy devices may not understand or decode the modified PHY preamble. Alternatively, a legacy format frame (e.g., CTS to self) may be sent before the sounding request frame to set the NAV appropriately.

Any STAs not in the group set their NAV based on the duration field in the sounding request frame (step812). STA1804responds first with a sounding frame with the RA field containing the group ID (step814). In one implementation, the sounding frame may be a CTS frame, with one or more bits indicating that it is a sounding frame, training symbols or fields, and L-SIG TXOP protection for supporting legacy devices. The sounding frame from the STA1804may be sent at a delay or a SIFS interval or more, depending on the implementation. It is noted that any other interframe spacing interval may be used instead of the SIFS. Any STAs not in the group set their NAV based on the duration field in the sounding frame (step816), if the new NAV value is longer than the NAV value from the sounding request frame or if a STA receiving the sounding frame from STA1did not receive the sounding request frame from AP0.

The STA2806sends a sounding frame with the RA field containing the group ID (step818). Similar to the sounding frame sent by STA1804, the sounding frame sent by STA2806may be a CTS frame and include similar information. Any STAs not in the group set their NAV based on the duration field in the sounding frame (step820), if the new NAV value is longer than the NAV value from the sounding request frame or from the sounding frame from STA1804or if a STA receiving the sounding frame from STA2did not receive the sounding request frame from AP0or the sounding frame from STA1.

The AP802sends a group frame with data and a BAR to STA1804and data and a BAR to STA2806(step830). In an OFDMA implementation, the group frame is transmitted to STA1804and STA2806on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1804and STA2806on the same frequency. Following the same order as with sending the sounding frames, STA1804first sends a response frame to the group ID (step832). Then STA2806sends a response frame to the group ID (step834). The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

As noted above, one embodiment may use a RTS frame as the sounding request frame sent by the beamformer and a CTS frame as the sounding frame sent by the beamformees. The protection mechanism for NAV setting when using the sounding frames needs to take into account legacy devices that cannot understand beyond the legacy portion of the packet. For the sounding request frame, there are three options for the NAV protection mechanism: using the legacy packet format, using the L-SIG TXOP protection as defined in IEEE 802.11n, or using a legacy format frame (e.g., CTS to self) sent before the sounding request frame to set the NAV. For the sounding frame, the L-SIG TXOP protection may be used. Alternatively, a legacy format frame (e.g., CTS to self) may be sent before the sounding frame to set the NAV appropriately.

Sounding with Explicit Feedback for Group Frame Exchange

Sounding with explicit feedback for group transmission may be performed by a beamformer device by sending a sounding frame including training symbols. The sounding frame may include: one or more bits indicating that it is a sounding frame; a request for feedback in the form of sounding response frame from the beamformees in the group; scheduling information for the sounding response frames from the beamformees; or a request for other channel measurements, such as channel quality (e.g., Signal to Noise Ratio) in the sounding response frame from the beamformees in the group.

The sounding frame may use the 802.11n L-SIG TXOP protection, so that all devices (including the legacy devices) may set their NAV based on the length and rate parameters included in the L-SIG field. Alternatively, a legacy format frame (e.g., CTS to self) may be sent before the sounding request frame to set the NAV appropriately. The group ID information may be included in the PHY preamble of the sounding frame, e.g., the VHT-SIG fields in the PHY preamble, or in the MAC fields of the sounding frame, e.g., the group ID included in the RA field and the order information implicitly or explicitly associated with the group ID.

The sounding frame and the sounding response frame may be any data frame, management frame, or control frame. For example, the sounding frame may be a RTS frame or a CTS frame. The sounding response frame may have its RA field include any one of: the group ID, a special identifier of the beamformer device that is recognizable by all the devices in the group as part of the group ID, or the individual MAC address of the beamformer. The sounding response frame may be used for responding with channel estimates or channel measurements, such as channel quality (e.g., Signal to Noise Ratio).

The order for transmitting sounding response frames may be derived by the beamformee devices in the group from the order information associated with the group ID, or the order information provided by the beamforming device in earlier frames (e.g., the sounding frame). The sounding response frames may be sent immediately or delayed. When sent immediately, the sounding response frame follows the sounding frame from the beamformer at a delay of a SIFS interval (or other interframe spacing interval). When sent delayed, the sounding response frame is sent at a delay of more than a SIFS interval (or other interframe spacing interval) after the sounding frame from the beamformer and may include a time stamp for the channel estimate or measurements.

FIG.9is a flow diagram of a sounding procedure900with explicit feedback for a group frame exchange. The sounding procedure900involves an AP or STA0902which is the beamformer (referred to hereafter as AP902), a first station STA1904, and a second station STA2906. STA1904and STA2906are both beamformees. STA1904is before STA2906in the order associated with the group. It is noted that the procedure900will work with any number of stations. While the procedure800is described in terms of an AP being the beamformer, this is one example embodiment, and any STA may be the beamformer.

The AP902sends a sounding frame addressed to the group by including the group ID in the RA field (step910). In one implementation, the sounding frame includes one or more bits indicating that it is a sounding frame, training symbols or fields, a request for a sounding response from the beamformees, and L-SIG TXOP protection for supporting legacy devices.

Any STAs not in the group set their NAV based on the duration field in the sounding frame (step912). STA1904responds first with a sounding response frame with the RA field containing the group ID (step914). In one implementation, the sounding response frame includes a channel estimate and channel measurements. The sounding response frame from the STA1904may be sent at a delay or a SIFS interval or more, depending on the implementation. It is noted that any other interframe spacing interval may be used instead of the SIFS. Any STAs not in the group set their NAV based on the duration field in the sounding response frame (step916), if the new NAV value is longer than the NAV value from the sounding frame or if a STA receiving the sounding response frame from STA1did not receive the sounding frame from AP0.

The STA2906sends a sounding response frame with the RA field containing the group ID (step918). In one implementation, the sounding response frame includes a channel estimate and channel measurements. Any STAs not in the group set their NAV based on the duration field in the sounding response frame (step920), if the new NAV value is longer than the NAV value from the sounding frame or from the sounding response frame from STA1904or if a STA receiving the sounding response frame from STA2did not receive the sounding frame from AP0or the sounding response frame from STA1.

The AP902sends a group frame with data and a BAR to STA1904and data and a BAR to STA2906(step930). In an OFDMA implementation, the group frame is transmitted to STA1904and STA2906on their respective allocated frequencies. In a MU-MIMO implementation, the group frame is transmitted to STA1904and STA2906on the same frequency. Following the same order as with sending the sounding response frames, STA1904first sends a response frame to the group ID (step932). Then STA2906sends a response frame to the group ID (step934). The response frame may be a block ACK or other response frame type, depending on the frame exchange protocol used.

Error Recovery in Sounding for Group Frame Exchange

If a beamformer device sends a sounding request frame or a sounding frame and does not receive one or more expected responses (either a sounding frame if implicit feedback is used or a sounding response from if explicit feedback is used) from the beamformee devices in the group, then there may be an error. The beamformer device may recover from the error by attempting to reclaim the wireless medium or by ignoring the missing response.

The beamformer device may attempt to reclaim the wireless medium as soon as it detects a failure of an expected response, after sensing the channel as idle for a certain duration, e.g., PIFS. The beamformer device may then restart the procedure by sending the sounding request frame or sounding frame, or sending an updated sounding request frame or sounding frame (to account for the failed frame(s)) if time is available before the beginning of the next expected response.

Alternatively, the beamformer device waits for the last response from the group and then attempts to reclaim the wireless medium after sensing the channel as idle for a certain duration, e.g., PIFS. The beamformer device may then restart the procedure by sending the sounding request frame or sounding frame, or sending an updated sounding request frame or sounding frame (to account for the failed frame(s)).

The beamformer device may ignore the failure of an expected response and continue as if the expected response was received.

Special Notes on Preceding Embodiments

The sounding request frame or sounding frame sent by the beamformer device may have its RA field include one of the following: a group identifier, its individual MAC address, a newly defined address or identifier that is recognizable by all of the other devices belonging to the group, or an existing IEEE 802.11 address or identifier that is recognizable by the other devices belonging to the group.

The sounding frames or sounding response frames sent by the beamformee devices may have the RA field include one of the following: a group identifier, a special identifier of the beamformer device that is recognizable by all of the devices in the group as part of the group identifier, or the individual MAC address of the beamformer.

The sounding request frame (implicit feedback) or sounding frame (explicit feedback) from the beamformer may include an indication using one or more bits that requires the beamformees associated with the group ID to respond with sounding frames (implicit feedback) or sounding response frames (explicit feedback). In one embodiment, this indication may be in the PHY preamble of the sounding request frame or sounding frame from the beamformer.

The sounding request frame or sounding frame from the beamformer may include the group ID information in either the PHY preamble or in MAC layer fields. In these scenarios, the RA field of the sounding request frame or sounding frame from the beamformer may include one of the following: a broadcast ID or a general group ID representing all group transmissions (e.g., MU-MIMO or OFDMA). Also, if the PHY preamble of the sounding request frame or sounding frame from the beamformer is modified, then L-SIG TXOP protection as defined in IEEE 802.11n may be used for NAV setting of legacy devices, because the legacy devices may not understand or decode the modified PHY preamble. Alternatively, a legacy format frame (e.g., CTS to self) may be sent before the sounding request frame or sounding frame from the beamformer to set the NAV.

The sounding mechanisms described above may be applied on all bandwidths of operation and all frequency channels of operation, e.g., the primary channel and secondary channels of an 802.11 BSS. For example, the sounding mechanisms may be applied in each bandwidth of operation used by the system or BSS, for example when there are 20 MHz, 40 MHz, and 80 MHz capable devices in operation. Alternatively, if all the devices operating in the system have a common bandwidth (e.g., 20 MHz, 40 MHz, or 80 MHz), then the sounding mechanisms may be carried out in the common bandwidth used by the system or BSS.

The AP and STAs may indicate the capability to support one or more aspects of the sounding mechanisms for group transmissions by using one or more bits. This indication may be included in any frames, for example, in management frames such as association request, association response, re-association request, re-association response, probe request, probe response, beacon, secondary beacon, or auxiliary beacon frames. In one embodiment, the capability indication may be included in a VHT capability information element (e.g., an IEEE 802.11ac VHT capabilities information field) which may be included in any of the above listed frames.

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. 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.