The present invention relates generally to wireless networks, and in particular, to uplink multi-user multiple-input-multiple-output communication in wireless networks.
In a typical wireless network utilizing a coordination function for coordinating transmissions among wireless stations, such a function may be implemented in one of the wireless stations or a coordinator device such as an access point (AP). The wireless stations may communicate via directional transmissions using sector antennas and beamforming antenna arrays. The coordinator device may use omnidirectional transmissions for broadcasts to all wireless stations in all directions (e.g., 360 degrees range). Alternatively, the coordinator may use quasi-omnidirectional transmissions for broadcasts to a wide range, but not necessarily in all directions. In many wireless area networks (WLANs) such as those according to IEEE 802.11 standards, a coordinator station in infrastructure mode is used for providing contention-free access to a wireless communication medium to support Quality of Service (QoS) for certain applications.
In the absence of a coordinator, to provide contention-free channel time reservation, existing techniques use announcement or information exchange among wireless stations in a network to negotiate/reserve the use of the communication medium. For example, IEEE 802.11e Enhanced Distributed Channel Access (EDCA) provides QoS support for certain applications using announcement or information exchange. EDCA defines four Access Categories (ACs) and introduces service differentiation such that certain data traffic uses higher priority parameters to contend for the communication medium.
Further, a frame structure is used for data transmission between wireless stations such as a transmitter station and a receiver station. In one example, a frame structure in a Media Access Control (MAC) layer and a physical (PHY) layer is utilized, wherein in a transmitter station, a MAC layer receives a MAC Service Data Unit (MSDU) and attaches a MAC header thereto, in order to construct a MAC Protocol Data Unit (MPDU). The MAC header includes information such as a source address (SA) and a destination address (DA). The MPDU is a part of a PHY Service Data Unit (PSDU) and is transferred to a PHY layer in the transmitter to attach a PHY header (i.e., PHY preamble) thereto to construct a PHY Protocol Data Unit (PPDU). The PHY header includes parameters for determining a transmission scheme including a coding/modulation scheme. The PHY layer includes transmission hardware for transmitting data bits over a wireless link. Before transmission as a frame from the transmitter station to the receiver station, a preamble is attached to the PPDU, wherein the preamble can include channel estimation and synchronization information.
EDCA allows contention for transmission opportunities (TXOPs), wherein a TXOP is a time interval when a quality of service (QoS) wireless station (STA) may initiate frame transfer on the wireless medium (e.g., wireless channel). The TXOP may be assigned to the wireless station by a coordinator, or the wireless station may obtain the TXOP by successfully contending for the wireless channel.
The present invention provides a method and system for wireless communication in a wireless network. A wireless station obtains a transmission opportunity period (TXOP) for communicating with an access point (AP) over a wireless communication channel. The wireless station sends an announcement to the AP to share the transmission opportunity period with at least another wireless station, as a multi-user transmission opportunity period for simultaneously transmitting data from said wireless stations to the AP on multiple uplink (UL) spatial streams over the wireless channel.
These and other features, aspects and advantages of the present invention will become understood with reference to the following description, appended claims and accompanying figures.
Embodiments of the present invention provide a method and system for uplink (UL) multi-user multiple-input-multiple-output (MU-MIMO) communication in wireless networks. Embodiments of the present invention allow simultaneously transmitting multiple uplink spatial streams from multiple wireless stations to an access point (AP) during a multi-user transmit opportunity over a wireless medium, such as a shared wireless radio frequency (RF) channel. Embodiments of the present invention are further useful with simultaneously transmitting multiple downlink spatial streams to multiple wireless stations from the AP during a multi-user transmit opportunity over a wireless medium. Embodiments of the invention employ a multi-user transmit opportunity (MU-TXOP) mechanism for a wireless network to support multiple traffic streams for multiple wireless stations simultaneously.
In one embodiment, the present invention provides wireless channel access protocols and a mechanism to establish the UL MU-MIMO transmission. The channel access protocols extend the existing WLAN (IEEE 802.11) standard to support uplink MU-MIMO transmission (i.e., multiple stations sending data frames to an access point).
In one embodiment, the present invention provides a MAC protocol for enabling UL MU-MIMO transmissions. According to an embodiment of the invention, a new frame subtype is provided for IEEE 802.11 standard for QoS CF-Multi-Poll. According to an embodiment of the invention, enhanced RTS/CTS frame exchanges are provided for initiating UL MU-MIMO transmissions. According to an embodiment of the invention, an ultra-high throughput (UHT) control wrapper frame with RTS/CTS frames is provided for initiating UL MU-MIMO transmissions. According to an embodiment of the invention, uplink transmission request (UTR) and uplink transmission indication (UTI) frames are provided for initiating UL MU-MIMO transmissions.
Uplink multi-user MIMO (UL MU-MIMO) protocol allows multiple traffic streams to be transmitted from different wireless stations (STAs) to a single access point (AP) simultaneously via multiple spatial streams, through the use of smart antennas and beamforming technology. Embodiments of the invention provide reduced overhead, backward compatibility, and save on reserved frame subtypes.
All three stations, STA-1 to STA-3, transmit at the same time to the AP through different spatial streams. Control and management frame exchanges are omitted for ease of illustration. The sequential acknowledgement scheme from the AP station shown in
As used herein, the term “UHT-capable device/STA” means a device/STA capable of performing uplink MU-MIMO communication functions. Enabling UL MU-MIMO transmission includes time synchronization, frequency synchronization, power control, enhanced AP capability, and enhanced MAC protocol. Embodiments of the invention focus on a MAC protocol enhancement, which enhance existing IEEE 802.11 MAC protocol, in order to support UL MU-MIMO transmissions. Embodiments of the invention address how a STA informs the AP that the STA has obtained a TXOP and it is willing to share it with other STAs for UL transmission. Embodiments of the invention address how the AP polls desired STAs that have buffered data frames to transmit at the same time.
According to embodiments of the invention, a protocol for enabling UL MU-MIMO transmissions operate in the EDCA mode. Under EDCA operation rules, each STA contends for channel access using a distributed algorithm (i.e., CSMA/CA and a serial of channel access rules). The EDCA operation rules remain the same for UL MU-MIMO as in the current IEEE 802.11 standards, and therefore not detailed further herein.
Initiation Process for UL MU-MIMO Transmission
Process block 202: The owner STA sends an announcement frame to the AP to announce that the STA is willing to share its UL TXOP with other STAs. Because the STA is the owner of the TXOP, it need not request the right for transmission since the STA has the right to transmit already. The purpose of the announcement is to inform the AP that the STA it is willing to share the UL TXOP with other STAs. Along with the announcement frame, additional information including the following is provided to the AP: (1) The requested TXOP duration and (2) The AC of the winning EDCAF (this information provides the AP the maximum TXOP duration that can be granted to the TXOP owner). The announcement frame can also be treated as the TXOP owner's request to the AP to start a UL MU-MIMO transmission. Accordingly, the announcement frame is called an “uplink transmission request” (UTR) herein.
Process block 203: Upon receiving the uplink transmission request, the AP determines from which other STAs (i.e., target STA) the AP will receive uplink frames. The determination can be made based on each STA's request of TXOP duration and their queue size. The queue's size indicates the number of frames in transmission queue 17A (
Process block 204: Once the targeted STAs have been determined, the AP transmits an “uplink transmission indication” (UTI) frame to all targeted STAs with the following information: (1) A list of addresses of STAs that are allowed to transmit in the uplink phase during the MU-TXOP uplink phase and (2) the allowed uplink transmission time for each target STA.
Process block 205: Upon receiving a UTI frame from the AP, all target STAs in the address list start their uplink transmissions of data frames (including data blocks from their queues) immediately after a short turn-around period, such as Short Interframe Space (SIFS) period. The SIFS period is to ensure the STA uplink transmissions to the AP during the uplink phase of the MU-TXOP are synchronized in time so that the AP can correctly decode the data carried in the uplink data frames belonging to each target STA.
In the example shown in
A primary aspect of the general initiation process described above comprises exchange of the UTR and UTI frames. In a preferred embodiment, a UTR/UTI frame exchange protocol includes considerations of the following factors:
Accordingly, a first example implementation of the above initiation process according to the invention includes using an enhanced RTS as the UTR and an enhanced CTS as the UTI. A second example implementation includes using RTS/CTS frames with a UHT Control Wrapper as UTR/UTI frames. A third example implementation includes using a pair of newly created control frames, UTR/UTI. As used herein, the acronyms UTR and UTI also refer to the functions of certain frames (e.g., in the first and second examples) and also refer to concrete frame formats (e.g. in the third example).
Initiation Process for UL MU-MIMO Transmission Using enhanced RTS/CTS with Special Indication as UTR/UTI
According to a first example initiation process for UL MU-MIMO transmission of an embodiment of the invention, an enhanced RTS frame 20 as shown in
Because the enhanced RTS and a legacy RTS share the same frame type and sub-type, in one embodiment the invention provides a mechanism to distinguish between them. The enhanced RTS and a legacy RTS have the same frame format as shown in
The following three example approaches can be used to distinguish the enhanced RTS frame 20 from a legacy RTS frame, according to embodiment of the invention: (1) Using one of the bits in the Frame Control field of the MAC header of the enhanced RTS frame (i.e., overloading by reusing a bit that does not carry any useful information for a RTS frame), (2) Using one of the reserved bits in the Service field of the enhanced RTS frame, and (3) Using one of the available bits in the preamble of the enhanced RTS frame.
Approach #1: Using a Sub-Field in the Frame Control Field of the MAC Header of the RTS Frame
One bit in the MAC header is used to indicate the difference between a legacy RTS frame and an enhanced RTS frame serving as a UTR frame according to an embodiment of the invention. This is accomplished by overloading one of the bits in the Frame Control field of the enhanced RTS frame as shown in
In a legacy RTS frame, many sub-fields in the Frame Control field are irrelevant to RTS. These sub-fields include all fields in the block 22 (6 bits/fields in total) in
When the “More Fragments” sub-field is selected to indicate the UTR function, this sub-field becomes a “UTR” sub-field in a BSS where UL MU-MIMO is in operation. When an RTS is sent from a STA, an UL MU-MIMO-capable AP checks the value of the UTR sub-field. When the value of the “More Fragments” sub-field of the RTS frame is set to 1 by the TXOP owner STA, the RTS frame is interpreted by the AP as a request to the AP to allow an UL MU-MIMO communication for the duration indicated in the “Duration” field of the enhanced RTS frame 20. When the value of said sub-field is set to 0 by the TXOP owner STA, the RTS frame 20 is interpreted as a conventional RTS (i.e., no UL MU-MIMO transmission is requested from the TXOP owner STA).
Approach #2: Using One of the Reserved Bits in the Service Field of the RTS Frame
According to an embodiment of the invention, in this approach, one of the reserved bits in the Service field of the RTS frame 20 is used (which is common to all IEEE 802.11a, IEEE 802.11n, and IEEE 802.11ac frames), to indicate to the AP that an RTS frame is a UTR frame.
Approach #3: Using One of the Available Bits in the Preamble of the RTS Frame
According to an embodiment of the invention, in this approach, one of the fields (bits) in various fields of the preamble of the RTS frame is used to indicate UTR function. These fields include different Signal fields in the RTS frame preambles of different versions of IEEE 802.11 standards.
In both formats in
Accordingly, the aforementioned three approaches can be used to differentiate an enhanced RTS from a conventional RTS frame to indicate that the enhanced RTS is a request by a TXOP owner STA to the AP for UL MU-MIMO transmission during a MU-TXOP. The AP also is informed of which Access Category (AC) in the TXOP owner STA has won the channel access. This is used to determine the maximum duration the TXOP can be. This function is optional since STAs regulate themselves by default to follow the TXOP maximum duration rules (the STAs do not request more than they are allowed). In case the AC information is needed, any two bits in the block 22 of the Frame Control field in
According to the above implementation, the UTR function is achieved by using an enhanced RTS frame, according to embodiment of the invention. Once the AP has successfully decoded the information carried by the enhanced RTS frame, the AP determines the targeted STAs to be included in the UTI indication frame. Using the RTS as the UTR frame implies the immediate reply frame from the AP should be a CTS frame. This is to keep the conventional RTS/CTS frame exchange sequence to reduce any need for hardware design changes. The duration field of the enhanced CTS frame 25, as shown in
To poll multiple STAs for uplink transmission, the CTS frame may include addresses of multiple targeted STAs. However, a legacy CTS frame has only one RA (Receiver Address) field and hence cannot carry multiple addresses. According to embodiments of the invention, said polling function can be achieved by three approaches: (1) Replacing the conventional RA field of the CTS frame with a compressed RA field to represent up to four STAs, (2) Sending a conventional CTS frame followed by a newly created CF-Multi-Poll frame, which contains the MAC addresses of STAs from which the AP is expected to received uplink data from, or (3) Sending the newly created CF-Multi-Poll frame only. These approaches are described in more detail below.
Approach #1: Using a Compressed RA Field of CTS Frame to Represent Up to Four Receiving STAs for UL Mu-Mimo Communication
According to an embodiment of the invention, in this approach, the RA field in the CTS frame is used to represent up to four receivers STAs. The enhanced CTS frame 25 and the Compressed RA field structure therein are shown in
Four receiver STAs are identified as AID1, AID2, AID3, and AID4. The AID (Association Identifier) fields contain the AIDs of the targeted STAs. An AID is a value assigned to a STA by the AP in the association response frame that established that STA's current association. Each AID is 11 bits in length and can be used to identify a unique STA in a BSS. Using this approach, the virtual Compressed RA cannot be the same as the MAC address of any legacy device. Otherwise a matching legacy device will treat this RA as its own MAC address and process the CTS frame. A Compressed RA can be the same as one or more UHT-capable devices since they will process the CTS frame further to determine whether it is a CTS with UTR function or a legacy CTS frame. The devices will use the AIDs in the Compressed RA field to determine whether they are the targeted STAs, not the face value of the RA.
In one embodiment, the following three methods are used to create a unique Compressed RA that is different from any regular MAC addresses of the legacy devices in the BSS. In a first step, always set the U/L Address bit (Bit1) to 1 to indicate a locally assigned address. A locally assigned address is only meaningful within a BSS. Because for every commercial product the U/L address bit will be set to indicate a “universally administered address”, by using this method itself, the compressed RA is made different from most of the MAC addresses of the most legacy devices. In a second step, if the Compressed RA field still matches one or more of MAC addresses of the legacy devices in the BSS, an AP can change the value of the Compatibility Bits to make this Compressed RA a different address. There are four different values to select from. In a third step, if the Compressed RA field still matches one or more of MAC addresses of the legacy devices in the BSS, the AP can switch the order of the AIDs listed in the compressed RA field to make it a different value.
Approach #2: Using Conventional CTS Followed by a Newly Created QoS CF-Multi-Poll Frame for UL MU-MIMO Communication
According to an embodiment of the invention, in this approach, a conventional (legacy or normal) CTS frame is first sent back from the AP to the UTR sender STA with the duration field set to the requested TXOP duration plus any control overheads. Because this conventional CTS does not contain the address list of the targeted STAs, another frame needs to be sent for this purpose according to an embodiment of the invention. In one implementation, a new QoS CF-Multi-Poll frame 32 is employed by the AP, wherein said frame has a Data frame subtype 1101 for polling all the targeted STAs for uplink transmission, as shown in
In the frame 32, the Duration field reflects the requested TXOP plus any overhead (e.g., a SIFS). The RA field contains the MAC address of the UTR sender. The first field of the frame body, the Number of Address field, contains the number of additional receiver addresses (other than the UTR sender STA's address) carried in the frame body. For example, if the value of the Number of Address field equals to 4, then the frame body will contain 4 additional receiver addresses (n=4). The frame 32 may contain other fields in the MAC Header, such as QoS Control and HT/UHT Control fields. Although frame 32 is a data frame, it is transmitted at one of the rates in the BSSBasicRateSet parameter in order to set the NAV of all STAs that are not being polled.
Approach #3: Using the Newly Created QoS CF-Multi-Poll Frame Only (without CTS) for UL MU-MIMO Communication
According to an embodiment of the invention, in this approach, the AP sends out the QoS CF-Multi-Poll frame 32 only as the response to a UTR frame, without sending the CTS frame first. In this case the frame exchange sequence becomes RTS/CF-Multi-Poll/Uplink Data. Although QoS CF-Multi-Poll is a data frame, it is transmitted at one of the rates in the BSSBasicRateSet parameter in order to set the NAV of all STAs that are not being polled.
Initiation Process for UL MU-MIMO Transmission Using RTS/CTS Frames with UHT Control Wrapper as UTR/UTI Frames
A second example initiation process for UL MU-MIMO transmission, according to an embodiment of the invention, includes using RTS/CTS frames with UHT Control Wrapper as UTR/UTI frames. An IEEE 802.11 Control Wrapper frame 42 is shown in
In a HT Control Wrapper frame 42, the Duration/ID field of the Control Wrapper frame is generated by following the rules for the Duration/ID field of the control frame that is being carried. The value for the Address 1 field of the Control Wrapper frame is generated by following the rules for the Address 1 field of the control frame that is being carried. The Carried Frame Control field contains the value of the Frame Control field of the carried control frame. The HT Control field has two formats which are defined in IEEE 802.11n and IEEE 802.11ac, respectively.
The Carried Frame field contains the fields that follow the Address 1 field of the control frame that is being carried, excluding the FCS field. By using a Control Wrapper, a RTS or CTS frame can be wrapped by a HT Control frame, which carries additional information than the original RTS/CTS frame. This eliminates the need to create a new frame format for every existing control frame whenever necessary.
Similar to the HT Control Wrapper, a UHT Control Wrapper is employed for the existing control frames to carry additional information needed by the UHT standard. This information can be carried by a newly created UHT Control Field and wrapped together with the existing control frames.
Similar to approaches above (i.e., for initiation process for UL MU-MIMO transmission using enhanced RTS/CTS with special indication as UTR/UTI), in a RTS+UHT frame 47, the Duration/ID field of the UHT Control Wrapper frame 45 is generated by following the rules for the Duration/ID field of the control frame that is being carried and is set to the requested TXOP duration plus any control overheads. In a CTS+UHT frame 49, the Duration/ID field of the UHT Control Wrapper frame 45 is generated by following the rules for the Duration/ID field of the control frame that is being carried and is set to the granted TXOP duration plus any control overheads.
In order to provide a list to the STAs for uplink transmission, another 2-bit or 3-bit sub-field is utilized, such as the “Number of STA Addresses Present” sub-field, in the UHT Control Field of the CTS+UHT frame is employed. Setting said sub-field to a non-zero value, n, in the UHT Control Field indicates a list of n STA addresses will be present after the UHT Control Field in the UHT Control Wrapper 45. Setting said sub-field to “0” in the UHT Control Field indicates the list of the STA addresses will not present after the UHT Control Field in the UHT Control Wrapper 45. When the “Number of STA Addresses Present” subfield has a non-zero value, a “List of STA Addresses” subfield will follow immediately. The list will have a variable length, depending on the number of STA addresses listed.
Although MAC addresses are used for illustration here, other implementations can also use AIDs to reduce the control overhead. Further, a 48-bit MAC address in the STA address list of a CTS+UHT frame 49 can also be replaced by an 11-bit AID or a 9-bit partial AID in order to reduce control overhead. Further, the TXOP owner STA's address is carried in the Address 1 field of the CTS+UHT frame, such that it is not necessary to be carried in the List of STA Addresses field again. Therefore, with a 2-bit “Number of STA Addresses Present” sub-field, the AP can poll up to 5 STAs for UL MU-MIMO transmission.
Initiation Process for UL MU-MIMO Transmission Using a Pair Of Newly Created Control Frames, UTR/UTI
A third example initiation process for UL MU-MIMO transmission according to an embodiment of the invention, includes using two new control frames, UTR and UTI control frames.
A UTI frame 59 is generated by the AP upon receiving the UTR and sent to the UTR sender, with other receiver addresses in the frame body. In a UTI frame 59, the Duration/ID field indicates the granted uplink TXOP duration plus any control overheads. The RA field contains the MAC address of the UTR sender. The Number of STA Addresses Present field indicates the number of STA addresses to be presented in the List of STA Addresses field. And the List of STA Addresses field contains the MAC addresses of the targeted STAs. Again, to save control overhead, all 48-bit MAC addresses in the List of STA Addresses field can be replaced by the 11-bit AID fields.
As is known to those skilled in the art, the aforementioned example architectures described above, according to the present invention, can be implemented in many ways, such as program instructions for execution by a processor, as software modules, microcode, as computer program product on computer readable media, as logic circuits, as application specific integrated circuits, as firmware, as consumer electronic devices, etc., in wireless devices, in wireless transmitters, receivers, transceivers in wireless networks, etc. Further, embodiments of the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.
Information transferred via communications interface 107 may be in the form of signals such as electronic, electromagnetic, optical, or other signals capable of being received by communications interface 107, via a communication link that carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an radio frequency (RF) link, and/or other communication channels. Computer program instructions representing the block diagram and/or flowcharts herein may be loaded onto a computer, programmable data processing apparatus, or processing devices to cause a series of operations performed thereon to produce a computer implemented process.
Embodiments have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. Each block of such illustrations/diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor create means for implementing the functions/operations specified in the flowchart and/or block diagram. Each block in the flowchart/block diagrams may represent a hardware and/or software module or logic. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc.
The terms “computer program medium,” “computer usable medium,” “computer readable medium”, and “computer program product,” are used to generally refer to media such as main memory, secondary memory, removable storage drive, a hard disk installed in hard disk drive, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as a floppy disk, ROM, flash memory, disk drive memory, a CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Computer program instructions may be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer to read such computer readable information. Computer programs (i.e., computer control logic) are stored in main memory and/or secondary memory. Computer programs may also be received via a communications interface. Such computer programs, when executed, enable the computer system to perform the features as discussed herein. In particular, the computer programs, when executed, enable the processor multi-core processor to perform the features of the computer system. Such computer programs represent controllers of the computer system.
Though the embodiments have been described with reference to certain versions thereof; however, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.
Number | Name | Date | Kind |
---|---|---|---|
5615212 | Ruszczyk et al. | Mar 1997 | A |
5886993 | Ruszczyk et al. | Mar 1999 | A |
6198728 | Hulyalkar et al. | Mar 2001 | B1 |
6795421 | Heinonen et al. | Sep 2004 | B1 |
6807158 | Krishnamurthy et al. | Oct 2004 | B2 |
6813277 | Edmon et al. | Nov 2004 | B2 |
6868072 | Lin et al. | Mar 2005 | B1 |
6925064 | Hester et al. | Aug 2005 | B2 |
7079812 | Miller et al. | Jul 2006 | B2 |
7088702 | Shvodian | Aug 2006 | B2 |
7127254 | Shvodian et al. | Oct 2006 | B2 |
7184767 | Gandolfo | Feb 2007 | B2 |
7197025 | Chuah | Mar 2007 | B2 |
7251235 | Wentink | Jul 2007 | B2 |
7280518 | Montano et al. | Oct 2007 | B2 |
7280801 | Dahl | Oct 2007 | B2 |
7339916 | Kwon et al. | Mar 2008 | B2 |
7356341 | Nanda | Apr 2008 | B2 |
7359398 | Sugaya | Apr 2008 | B2 |
7385943 | Niddam | Jun 2008 | B2 |
7388833 | Yuan et al. | Jun 2008 | B2 |
7400899 | Shin et al. | Jul 2008 | B2 |
7447174 | Joshi | Nov 2008 | B2 |
7447180 | Jeong et al. | Nov 2008 | B2 |
7474686 | Ho | Jan 2009 | B2 |
7480266 | Murty et al. | Jan 2009 | B2 |
7486650 | Trainin | Feb 2009 | B2 |
7539930 | Ginzburg et al. | May 2009 | B2 |
7545771 | Wentink et al. | Jun 2009 | B2 |
7561510 | Imamura et al. | Jul 2009 | B2 |
7570656 | Raphaeli et al. | Aug 2009 | B2 |
7590078 | Nanda | Sep 2009 | B2 |
7623542 | Yonge et al. | Nov 2009 | B2 |
7634275 | Odman | Dec 2009 | B2 |
7664030 | Sugaya | Feb 2010 | B2 |
7664132 | Benveniste | Feb 2010 | B2 |
7680150 | Liu et al. | Mar 2010 | B2 |
7684380 | Odman | Mar 2010 | B2 |
7697448 | Karaoguz | Apr 2010 | B2 |
7787487 | Liu | Aug 2010 | B2 |
7804804 | Sugaya et al. | Sep 2010 | B2 |
7860054 | Benveniste | Dec 2010 | B2 |
7881340 | Farrag et al. | Feb 2011 | B2 |
7924805 | Nishibayashi et al. | Apr 2011 | B2 |
7944897 | Shao et al. | May 2011 | B2 |
7974261 | Lane et al. | Jul 2011 | B2 |
8068449 | Benveniste | Nov 2011 | B2 |
8072961 | Takano | Dec 2011 | B2 |
8089946 | Brommer | Jan 2012 | B2 |
8107424 | Li et al. | Jan 2012 | B2 |
8107993 | Toshimitsu et al. | Jan 2012 | B2 |
8179867 | Seok | May 2012 | B2 |
8194626 | Moorti et al. | Jun 2012 | B2 |
8437317 | Jang et al. | May 2013 | B2 |
8532221 | Liu et al. | Sep 2013 | B2 |
8649358 | Gong et al. | Feb 2014 | B2 |
8976741 | Wentink | Mar 2015 | B2 |
8989106 | Abraham et al. | Mar 2015 | B2 |
20030003905 | Shvodian | Jan 2003 | A1 |
20030137970 | Odman | Jul 2003 | A1 |
20030137993 | Odman | Jul 2003 | A1 |
20030214967 | Heberling | Nov 2003 | A1 |
20040047319 | Elg | Mar 2004 | A1 |
20040214571 | Hong | Oct 2004 | A1 |
20040218683 | Batra et al. | Nov 2004 | A1 |
20040264475 | Kowalski | Dec 2004 | A1 |
20050058151 | Yeh | Mar 2005 | A1 |
20050130634 | Godfrey | Jun 2005 | A1 |
20050135318 | Walton et al. | Jun 2005 | A1 |
20050232275 | Stephens | Oct 2005 | A1 |
20060002428 | Trainin | Jan 2006 | A1 |
20060050742 | Grandhi et al. | Mar 2006 | A1 |
20060166683 | Sharma et al. | Jul 2006 | A1 |
20060176908 | Kwon et al. | Aug 2006 | A1 |
20060193279 | Gu et al. | Aug 2006 | A1 |
20070280180 | Dalmases et al. | Dec 2007 | A1 |
20080159208 | Kloker et al. | Jul 2008 | A1 |
20080279204 | Pratt, Jr. et al. | Nov 2008 | A1 |
20090052389 | Qin et al. | Feb 2009 | A1 |
20090086706 | Huang et al. | Apr 2009 | A1 |
20090092086 | Lee et al. | Apr 2009 | A1 |
20090275292 | Chang | Nov 2009 | A1 |
20090285163 | Zhang et al. | Nov 2009 | A1 |
20090323611 | Singh et al. | Dec 2009 | A1 |
20100002639 | Qin et al. | Jan 2010 | A1 |
20100046453 | Jones et al. | Feb 2010 | A1 |
20100046518 | Takagi et al. | Feb 2010 | A1 |
20100220601 | Vermani et al. | Sep 2010 | A1 |
20100310003 | Lauer et al. | Dec 2010 | A1 |
20110002319 | Husen et al. | Jan 2011 | A1 |
20110064013 | Liu et al. | Mar 2011 | A1 |
20110090855 | Kim | Apr 2011 | A1 |
20110176627 | Wu et al. | Jul 2011 | A1 |
20110235513 | Ali | Sep 2011 | A1 |
20110255618 | Zhu et al. | Oct 2011 | A1 |
20110268054 | Abraham et al. | Nov 2011 | A1 |
20110268094 | Gong et al. | Nov 2011 | A1 |
20110317630 | Zhu et al. | Dec 2011 | A1 |
20120008490 | Zhu | Jan 2012 | A1 |
20120060075 | Gong et al. | Mar 2012 | A1 |
20120082200 | Verikoukis et al. | Apr 2012 | A1 |
20120087358 | Zhu et al. | Apr 2012 | A1 |
20120140615 | Gong | Jun 2012 | A1 |
20120218947 | Merlin et al. | Aug 2012 | A1 |
20120230317 | Kim et al. | Sep 2012 | A1 |
20120314694 | Hsieh | Dec 2012 | A1 |
20130229996 | Wang et al. | Sep 2013 | A1 |
20130259017 | Zhang et al. | Oct 2013 | A1 |
20130286959 | Lou et al. | Oct 2013 | A1 |
20130301551 | Ghosh et al. | Nov 2013 | A1 |
20140010144 | Liu et al. | Jan 2014 | A1 |
20140126509 | You | May 2014 | A1 |
20140269544 | Zhu et al. | Sep 2014 | A1 |
20140328262 | Sampath et al. | Nov 2014 | A1 |
20150071051 | Zhu et al. | Mar 2015 | A1 |
Entry |
---|
IEEE P802.11e/D13.0, “IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment: Medium Access Control (MAC) Quality of Service (QoS) Enhancements,” LAN/MAN Committee, IEEE Computer Society, Jan. 2005, IEEE, New York, NY, pp. i-182, United States. |
IEEE Wireless LAN Edition, “A Compilation Based on IEEE Std. 802.11TM-1999 (R2003) and Its Amendments,” IEEE Press, 2003, pp. i-678, United States. |
Mujtaba, S.A., “TGn Sync Proposal Technical Specification,” IEEE 802.11-04-0889r7, IEEE P802.11: Wireless LANs, Jul. 8, 2005, pp. 1-133, United States. |
Kim, S. et al., “QoS Enhancement Scheme of EDCF in IEEE 802.11e Wireless LANs,” Electronics Letters, vol. 40, No. 17, IEEE, Aug. 19, 2004, pp. 1091-1092, United States. |
IEEE 802.11—2007, “IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific requirements: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” 2007 Revision of IEEE Std 802.11-1999, IEEE Computer Society, Jun. 12, 2007, pp. i-1184, United States. |
International Search Report dated Jan. 9, 2009 for International Application No. PCT/KR2008/004793 from Korean Intellectual Property Office, filed Aug. 19, 2008, pp. 1-2, Seo-gu, Daejeon, Republic of Korea. |
Harada, H., “Unified and Flexible Millimeter Wave WPAN Systems Supported by Common Mode,” IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs), IEEE 802.15-07-0761-10-003c, Sep. 18, 2007, Slides 1-62, United States. |
Mirkovic, J. et al., “A MAC Protocol With Multi-User MIMO Support for Ad-Hoc WLANs”, The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07), IEEE, 2007, pp. 1-5, United States. |
Stacey, R. et al., “DL MU-MIMO Ack Protocol (IEEE 802.11-09/1172r0)”, IEEE, Nov. 16, 2009, pp. 1-8, United States. |
IEEE Computer Society, “IEEE Std 802®-2001 (R2007), IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture”, IEEE, Feb. 7, 2002, pp. i-36, New York, United States. |
Camp, J.D. et al., “The IEEE 802.11s Extended Service Set Mesh Networking Standard”, IEEE Communications Magazine, vol. 46, No. 8, IEEE, Aug. 2008, pp. 1-6, United States. |
Morioka, Y. et al., “Multi-RTS Proposal”, IEEE 802.11-10/1124r01, Sep. 12, 2010, Slides 1-14, IEEE, USA. |
U.S. Non-Final Office Action mailed Oct. 26, 2011 for U.S. Appl. No. 12/455,438. |
U.S. Final Office Action mailed Apr. 12, 2012 for U.S. Appl. No. 12/455,438. |
U.S. Non-Final Office Action mailed Jul. 11, 2013 for U.S. Appl. No. 12/455,438. |
U.S. Notice of Allowance mailed Oct. 21, 2013 for U.S. Appl. No. 12/455,438. |
U.S. Non-Final Office Action mailed Jun. 6, 2012 for U.S. Appl. No. 12/415,981. |
U.S. Final Office Action mailed Dec. 19, 2012 for U.S. Appl. No. 12/415,981. |
U.S. Advisory Action mailed Mar. 8, 2013 for U.S. Appl. No. 12/415,981. |
U.S. Non-Final Office Action mailed Aug. 8, 2013 for U.S. Appl. No. 12/415,981. |
U.S. Final Office Action mailed Jan. 14, 2014 for U.S. Appl. No. 12/415,981. |
U.S. Notice of Allowance mailed Apr. 10, 2014 for U.S. Appl. No. 12/415,981. |
U.S. Non-Final Office Action mailed Jun. 9, 2009 for U.S. Appl. No. 11/589,519. |
U.S. Final Office Action mailed May 12, 2010 for U.S. Appl. No. 11/589,519. |
U.S. Notice of Allowance mailed Jan. 24, 2011 for U.S. Appl. No. 11/589,519. |
U.S. Non-Final Office Action mailed Jun. 27, 2006 for U.S. Appl. No. 11/044,600. |
U.S. Non-Final Office Action mailed Aug. 21, 2007 for U.S. Appl. No. 11/044,600. |
U.S. Final Office Action mailed Jan. 15, 2008 for U.S. Appl. No. 11/044,600. |
U.S. Non-Final Office Action mailed Aug. 7, 2008 for U.S. Appl. No. 11/044,600. |
U.S. Non-Final Office Action mailed Jan. 25, 2007 for U.S. Appl. No. 11/044,600. |
U.S. Advisory Action mailed May 15, 2008 for U.S. Appl. No. 11/044,600. |
U.S. Restriction Requirement for U.S. Appl. No. 13/030,070 mailed Nov. 5, 2013. |
U.S. Non-Final Office Action for U.S. Appl. No. 13/030,070 mailed May 15, 2014. |
U.S. Non-Final Office Action for U.S. Appl. No. 13/177,386 mailed Dec. 17, 2013. |
U.S. Non-Final Office Action for U.S. Appl. No. 12/821,940 mailed May 29, 2012. |
U.S. Final Office Action for U.S. Appl. No. 12/821,940 mailed Aug. 21, 2012. |
U.S. Non-Final Office Action for U.S. Appl. No. 12/821,940 mailed Jun. 24, 2014. |
U.S. Notice of Allowance for U.S. Appl. No. 12/821,940 mailed Oct. 31, 2014. |
U.S. Supplemental Notice of Allowability for U.S. Appl. No. 12/821,940 mailed Dec. 8, 2014. |
U.S. Supplemental Notice of Allowability for U.S. Appl. No. 12/821,940 mailed Dec. 19, 2014. |
U.S. Restriction Requirement for U.S. Appl. No. 13/253,926 mailed Oct. 10, 2013. |
U.S. Non-Final Office Action for U.S. Appl. No. 13/253,926 mailed Nov. 25, 2013. |
U.S. Final Office Action for U.S. Appl. No. 13/253,926 mailed Apr. 29, 2014. |
U.S. Advisory Action for U.S. Appl. No. 13/253,926 mailed Jul. 11, 2014. |
U.S. Notice of Allowance for U.S. Appl. No. 13/253,926 mailed Aug. 15, 2014. |
U.S. Supplemental Notice of Allowability for U.S. Appl. No. 13/253,926 mailed Oct. 15, 2014. |
U.S. Supplemental Notice of Allowability for U.S. Appl. No. 13/253,926 mailed Nov. 26, 2014. |
U.S. Non-Final Office Action for U.S. Appl. No. 14/023,204 mailed Mar. 11, 2015. |
U.S. Non-Final Office Action for U.S. Appl. No. 14/023,195 mailed Aug. 14, 2015. |
U.S. Final Office Action for U.S. Appl. No. 14/023,204 mailed Jul. 23, 2015. |
U.S. Notice of Allowance for U.S. Appl. No. 14/023,204 mailed Oct. 16, 2015. |
Number | Date | Country | |
---|---|---|---|
20140119288 A1 | May 2014 | US |