US20060092871A1 - Communication method for wireless LANS - Google Patents
Communication method for wireless LANS Download PDFInfo
- Publication number
- US20060092871A1 US20060092871A1 US11/201,258 US20125805A US2006092871A1 US 20060092871 A1 US20060092871 A1 US 20060092871A1 US 20125805 A US20125805 A US 20125805A US 2006092871 A1 US2006092871 A1 US 2006092871A1
- Authority
- US
- United States
- Prior art keywords
- frame
- block ack
- qsta
- data
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims description 63
- 238000004891 communication Methods 0.000 title claims description 42
- 230000005540 biological transmission Effects 0.000 claims abstract description 129
- 230000003111 delayed effect Effects 0.000 claims abstract description 72
- 230000004931 aggregating effect Effects 0.000 claims description 42
- 230000004044 response Effects 0.000 claims description 25
- 238000001514 detection method Methods 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 claims 1
- 238000012545 processing Methods 0.000 description 22
- 230000002441 reversible effect Effects 0.000 description 18
- 230000002776 aggregation Effects 0.000 description 12
- 238000004220 aggregation Methods 0.000 description 12
- 238000000926 separation method Methods 0.000 description 7
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 6
- 238000011084 recovery Methods 0.000 description 6
- 239000003999 initiator Substances 0.000 description 5
- 239000012634 fragment Substances 0.000 description 4
- 238000013467 fragmentation Methods 0.000 description 4
- 238000006062 fragmentation reaction Methods 0.000 description 4
- 108700026140 MAC combination Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 101100268879 Drosophila melanogaster Ack-like gene Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001771 impaired effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000005764 inhibitory process Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W74/00—Wireless channel access
- H04W74/08—Non-scheduled access, e.g. ALOHA
- H04W74/0866—Non-scheduled access, e.g. ALOHA using a dedicated channel for access
Definitions
- the present invention relates to a communication apparatus and method which perform media access control on the basis of the carrier sense information of a physical layer and the carrier sense information of a MAC layer.
- Media access control is control for causing a plurality of communication apparatuses which perform communication while sharing the same media to decide how to use the media in transmitting communication data. Owing to media access control, even if two or more communication apparatuses transmit communication data by using the same media at the same time, there is less chance of the occurrence of a phenomenon (collision) in which a communication apparatus on the receiving side cannot separate communication data. Media access control is also a technique for control-ling access from communication apparatuses to a media so as to minimize the chance of the occurrence of a phenomenon in which, despite the presence of communication apparatuses having transmission requests, the media is not used by any of the communication apparatuses.
- IEEE 802.11 is a typical technical standard for wireless LANs, and uses CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance).
- CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
- a period (Duration) until the end of a sequence comprising one or more frame exchanges following the frame is set.
- a communication apparatus which is irrelevant to the sequence and has no transmission right waits for transmission upon determining a virtual occupied state of the media. This prevents the occurrence of collision.
- IEEE 802.11 defines that the state of a media is determined on the basis of such a combination of virtual carrier sense on a MAC layer and physical carrier sense on a physical layer, and media access control is performed on the basis of the determination.
- IEEE 802.11 using CSMA/CA has increased the communication speed mainly by changing the physical layer protocol.
- IEEE 802.11 With regard to the 2.4 GHz band, there have been changes from IEEE 802.11 (established in 1997, 2 Mbps) to IEEE 802.11b (established in 1999, 11 Mbps), and further to IEEE 802.11g (established in 2003, 54 Mbps).
- IEEE 802.11a With regard to the 5 GHZ band, only IEEE 802.11a (established in 1999, 54 Mbps) exists as a standard.
- IEEE 802.11 TGn (Task Group n) has already been established.
- HCCA HCF Controlled Channel Access
- Jpn. Pat. Appln. KOKAI Publication No. 2002-314546 refers to QoS in the IEEE 802.11e standard, and discloses a method of assigning priorities to communications between communication apparatuses in a wireless network.
- a protocol on a MAC layer conforms to CSMA/CA matching the existing specifications.
- a temporal parameter associated with CSMA/CA e.g., an IFS (Interframe Space) or backoff period needs to match that in the existing specifications.
- a Block Ack technique introduced in recently drafted IEEE 802.11e/draft 5.0 (enhancement of QoS in IEEE 802.11) is available.
- the Block Ack technique can consecutively transmit a plurality of MAC frames without any backoff, and hence can reduce the backoff amount to some degree.
- a physical layer header cannot be effectively reduced.
- both the backoff amount and the physical layer header can be reduced.
- an improvement in efficiency is greatly limited. Even if the length of a PHY layer frame can be increased, another problem arises, i.e., a reduction in error tolerance.
- the present invention has been made to solve the above problems, and has as its object to provide a method for a communication apparatus which can coexist with an existing apparatus and can improve the substantial communication throughput by eliminating overhead accompanying the transmission of a plurality of frames by making a frame format more efficient.
- a communication method including generating a physical frame in which: one of a data frame, an acknowledgement frame, and an acknowledgement request frame, and a transmission permission frame which is used in place of a normal Ack frame associated with a delayed Block Ack, and permits a destination terminal to perform piggyback transmission, are aggregated; and transmitting the physical frame to the destination terminal.
- FIG. 1 is a block diagram showing the arrangement of a communication apparatus according to an embodiment of the present invention
- FIG. 2 is a view showing the format of a Block Ack Request frame defined in IEEE 802.11e/Draft 10.0;
- FIG. 3 is a view showing the format of a Block Ack frame defined in IEEE 802.11e/Draft 10.0;
- FIG. 4 is a view showing an example of an immediate Block Ack sequence
- FIG. 5 is a view showing an example of a delayed Block Ack sequence
- FIG. 6 is a view showing an example of the aggregation of a plurality of MPDUs
- FIG. 7 is a view showing another example of the aggregation of a plurality of MPDUs
- FIG. 8 is a view showing the format of a Compressed Block Ack
- FIG. 9 is a view showing an example of a Compressed Block Ack sequence
- FIG. 10 is a view showing the format of an IAC (Initiator Aggregation Control) frame
- FIG. 11 is a view showing an example of piggyback transmission using IAC frames
- FIG. 12 is a view showing a case wherein an explicit Block Ack Request is transmitted upon occurrence of a transmission error
- FIG. 13 is a view showing a case wherein an IAC frame is added to an explicit Block Ack Request
- FIG. 14 is a view showing a case wherein errors have occurred in some of frames transmitted in the uplink direction
- FIG. 15 is a view showing a case wherein errors have occurred in some of frames transmitted in the downlink direction
- FIG. 16 is a view showing another case wherein errors have occurred in some of frames transmitted in the downlink direction
- FIG. 17 is a view a case wherein errors have occurred in some of frames transmitted in both the uplink direction and the downlink direction;
- FIG. 18 is a view another case wherein errors have occurred in some of frames transmitted in both the uplink direction and the downlink direction;
- FIG. 19 is a view showing a case wherein a timeout has occurred in Compressed Block Ack transmission in the uplink direction;
- FIG. 20 is a view showing another case wherein a timeout has occurred in Compressed Block Ack transmission in the uplink direction;
- FIG. 21 is a view showing a case wherein errors have occurred in all MPDUs aggregated and transmitted in the downlink direction from an HC;
- FIG. 22 is a view showing another case wherein errors have occurred in all MPDUs aggregated and transmitted in the downlink direction from an HC;
- FIG. 23 is a view showing a case wherein a Block Ack Request is contained in the last portion of a physical frame in which a plurality of data are aggregated;
- FIG. 24 is a view showing how frames are exchanged when piggybacking is performed by using the delayed Block Ack Policy
- FIG. 25 is a view showing piggybacking operation applied to the delayed Block Ack technique
- FIG. 26 is a view showing another example of piggybacking operation applied to the delayed Block Ack technique
- FIG. 27 is a view showing a case wherein only a busy is detected in a delayed Block Ack sequence
- FIG. 28 is a view showing a case wherein errors have occurred in some of data transmitted in the uplink direction
- FIG. 29 is a view showing a case wherein errors have occurred in some of data transmitted in the downlink direction
- FIG. 30 is a view showing a case wherein a timeout has occurred in the uplink direction
- FIG. 31 is a view showing the format of an MRAD frame
- FIG. 32 is a view showing an example of frame exchange in an immediate Block Ack sequence to a plurality of destinations
- FIG. 33 is a view showing another example of frame exchange in an immediate Block Ack sequence to a plurality of destinations
- FIG. 34 is a view showing still another example of frame exchange in an immediate Block Ack sequence to a plurality of destinations
- FIG. 35 is a view for explaining aggregation to a plurality of destinations and reception buffer management
- FIG. 36 is a view for explaining aggregation to a plurality of destinations and reception buffer management.
- FIG. 37 is a view for explaining aggregation to a plurality of destinations and reception buffer management.
- FIG. 1 is a block diagram showing the arrangement of a communication apparatus according to the first embodiment of the present invention.
- a communication apparatus 1 is an apparatus configured to communicate with another communication apparatus through a wireless link, and includes processing units 2 , 3 , and 4 respectively corresponding to a physical (PHY) layer, MAC layer, and link layer. These processing units are implemented as analog or digital electronic circuits in accordance with implementation requirements. Alternatively, the processing units are implemented as firmware or the like to be executed by a CPU incorporated in an LSI.
- An antenna 5 is connected to the physical layer processing unit (“processing unit” will be omitted hereinafter) 2 .
- the MAC layer 3 includes an aggregation processing device 6 for MAC frames.
- the aggregation processing device 6 includes a carrier sense control device 7 and retransmission control device 8 , and performs transmission/reception of Block Ack (acknowledgement for a plurality of MAC frames) frames (to be described in detail later), retransmission control based on Block Ack frames, and the like.
- Block Ack acknowledgement for a plurality of MAC frames
- the physical layer 2 is designed to be compatible with two types of physical layer protocols.
- the processing unit 2 includes a first-type physical layer protocol processing device 9 and a second-type physical layer protocol processing device 10 for the respective types of protocol processing.
- the first-type physical layer protocol processing device 9 and second-type physical layer protocol processing device 10 often share circuits and are not necessarily independent of each other in terms of implementation.
- the first-type physical layer protocol is assumed to be a protocol defined in IEEE 802.11a
- the second-type physical layer protocol is assumed to be a protocol using a so-called MIMO (Multiple Input Multiple Output) technique using a plurality antennas on each of the transmitting side and the receiving side.
- MIMO Multiple Input Multiple Output
- the MIMO technique is therefore a technique directed to further increase the throughput of IEEE 802.11.
- the link layer 4 has a normal link layer function defined in IEEE 802.
- the technique to be used to increase the transmission rate is not limited to MIMO. For example, a method of increasing the occupied frequency band may be used or may be combined with MIMO.
- Block Ack As a technique of improving the transmission efficiency at the MAC (Media Access Control) layer, a Block Ack technique has been proposed.
- a given terminal transmits QoS (Quality of Service) data at minimum frame intervals called SIFS (Short Interframe Space) for a given channel use period (TXOP: Transmission Opportunity).
- SIFS Short Interframe Space
- TXOP Transmission Opportunity
- the terminal transmits a Block Ack Request to the receiving terminal at an arbitrary timing to request its reception status.
- the receiving side converts the reception status into information in the bitmap format on the basis of the Starting Sequence Number (Block Ack Starting Sequence Control) determined by the Block Ack Request, and returns the information as a Block Ack.
- a Block Ack technique is known as a technique of improving the transmission efficiency at the MAC (Media Access Control) layer.
- a given transmitting terminal transmits QoS (Quality of Service) data at minimum frame intervals called SIFS (Short Interframe Space) for a given channel use period (TXOP: Transmission Opportunity).
- SIFS Quality of Service
- TXOP Transmission Opportunity
- the transmitting terminal transmits a Block Ack Request to the receiving terminal to request its reception status at an arbitrary timing.
- the receiving side converts the reception status into information in the bitmap format on the basis of the Starting Sequence Number (Block Ack Starting Sequence Control) determined by the Block Ack Request, and returns the information as a Block Ack.
- FIGS. 2 and 3 respectively show the formats of a Block Ack Request frame and Block Ack frame which are defined in IEEE 802.11e/Draft 10.0. Both the frames shown in FIGS. 2 and 3 are MAC frames, each having the MAC header defined in IEEE 802.11.
- the MAC header is comprised of a Frame Control field, Duration field, Receiver Address field, and Transmitter Address field.
- a BAR Control (Block Ack Request Control) 20 has a 4-bit TID (Traffic Identifier) field. QoS data exists for each priority (TID) and is assigned a unique sequence number and fragment number. For this reason, a reception status in the Block Ack in FIG. 3 also needs to be prepared for each priority.
- TID field of the BAR Control 20 in the Block Ack Request is used to designate such a priority.
- a Block Ack Starting Sequence Control 21 in the Block Ack Request in FIG. 2 is comprised of a 4-bit Fragment Number field and 12-bit Starting Sequence Number field.
- the Starting Sequence Number is used by a receiving terminal to generate a Block Ack Bitmap by tracing back a reception status, on the basis of a relative reception status from a sequence number corresponding to the Starting Sequence Number.
- a BA Control 30 in the Block Ack in FIG. 3 contains a 4-bit TID field.
- a Block Ack Starting Sequence Control (Block Ack Starting Sequence Number) 31 indicates the Starting Sequence Number of the reception status indicated by a Block Ack Bitmap 32 in the Block Ack.
- the size of a Block Ack Bitmap is a fixed length of 1,024 bits, which makes it possible to notify a reception log corresponding to data of a maximum of 64 MSDUs (MAC Service Data Units).
- MSDUs MAC Service Data Units
- the process of partitioning a MSDU or MMPDU (MAC management protocol data unit) into smaller MAC level frames, MPDUs (MAC Protocol Data Units), is called fragmentation.
- One MSDU or MMPDU shall be divided into a maximum of 16 MPDUs with a Fragmentation Threshold. Note that an FCS (Frame Check Sequence) for error detection is added to each of the MAC frames shown in FIGS. 2 and 3 .
- FCS Fragmentation Threshold
- FIGS. 4 and 5 each show an example of a Block Ack sequence in an HCCA (HCF Controlled Channel Access).
- the HC (Hybrid Coordinator) shown in each drawing is a QoS access point (QoS-AP) in IEEE 802.11e and serves as an entity which performs bandwidth management including the allocation of TXOPs to QSTAs (QoS stations) and performs downlink (the downlink direction from the HC to the QSTA) data transmission.
- the assignment of a TXOP to the QSTA is performed on the basis of a QoS CF-Poll frame (QoS Contention Free-Poll: a QoS-compatible polling frame which is transmitted from the HC to the QSTA to grant transmission opportunity).
- QoS CF-Poll QoS Contention Free-Poll: a QoS-compatible polling frame which is transmitted from the HC to the QSTA to grant transmission opportunity.
- the HC assigns a channel use period (TXOP period 1 ) to QSTA 1 by transmitting a QoS CF-Poll frame 40 to it.
- QSTA 1 can transmit any frame in TXOP period 1 .
- QSTA 1 transmits QoS Data frames 41 at SIFS intervals in a burst manner, and then transmits a Block Ack Request frame 42 at the end of the transmission of the data frames. Thereafter, QSTA 1 receives a Block Ack frame 43 from QSTA 2 .
- TXOP period 1 assigned to QSTA 1 expires, the HC acquires TXOP period 2 .
- the HC also transmits QoS Data 44 to QSTA 1 in a burst manner.
- the HC transmits a Block Ack Request 45 , and receives a Block Ack 46 from QSTA 1 .
- the Block Ack Requests 42 and 45 request the destination to return the relative reception status designated by a Block Ack Starting Sequence Control value.
- FIG. 4 shows an example of an immediate Block Ack sequence. In this case, the terminal which has received the Block Ack Requests 42 and 45 must return the Block Acks 43 and 46 after the SIFS intervals without fail.
- FIG. 5 shows an example of a delayed Block Ack sequence.
- the terminal Upon receiving a Block Ack Request 50 , the terminal returns an Ack frame defined in IEEE 802.11 (called a Normal acknowledgement in IEEE 802.11e/Draft 10.0) 51, and transmits a Block Ack 52 after a lapse of an arbitrary period.
- the data transmitting terminal Upon receiving the Block Ack 52 at last, the data transmitting terminal returns a Normal acknowledgement 53 , thereby completing the delayed Block Ack sequence.
- the receiving side is notified of QoS data subjected to the Block Ack technique by using an Ack Policy field in a QoS Control field of a MAC header extended for IEEE 802.11e.
- the Ack Policy field allows to designate the Normal ack scheme defined in IEEE 802.11, the Block Ack scheme defined in IEEE 802.11e, the No acknowledgement scheme which does not require ACK response, or the like.
- Each embodiment of the present invention is directed to a communication apparatus designed to aggregate a plurality of MPDUs (MAC Protocol Data Units) in a PSDU (PHY Service Data Unit) to transmit a single PPDU (PHY Protocol Data Unit).
- MAC Protocol Data Units MAC Protocol Data Units
- PSDU PHY Service Data Unit
- a PPDU corresponds to a physical frame (PHY frame) containing a PHY header, a PHY trailer and PSDU which contains plurality of MPDUs.
- the overhead of the MAC layer and the overhead of the PHY layer must be reduced. As shown in FIGS. 6 and 7 , these overheads can be reduced by transmitting a plurality of MPDUs upon aggregating them into one PSDU.
- header information 61 which indicates in octets the length of each MPDU containing a MAC header to an FCS exists in the head of a PSDU 60 in which a plurality of MPDUs are aggregated.
- the header information 61 will be referred to as a “MAC super frame header” hereinafter.
- a CRC (Cyclic Redundancy Check) 62 for detecting an error in the header 61 itself is added to the MAC super frame header 61 . “0” is written in an MPDU Length field corresponding to a portion in which no MPDU exists. In addition, if the CRC calculation for the MAC super frame header 61 is incorrect, the reception of all the MPDUs is regarded as failed.
- a terminal Upon receiving a physical frame having the arrangement shown in FIG. 7 , a terminal checks the CRC of an MPDU separation 71 . If the first MPDU separation 71 has been successfully received, the terminal extracts succeeding MPDU and calculates an FCS. If the FCS calculation result is correct, it is determined that the MPDU has been successfully received. If the FCS calculation result is incorrect, the reception of the MPDU is regarded as failed.
- the terminal then checks the CRC of a next MPDU separation 72 upon skipping a portion indicated by the MPDU length of the MPDU separation 71 . If the MPDU separation is incorrect, the terminal consecutively skips and performs a CRC check on an octet basis. If the result is correct, the FCS for the MPDU following the MPDU separation is calculated to determine whether or not the MPDU has been successfully received.
- FIG. 8 shows the frame arrangement of an extended Block Ack.
- a Block Ack frame has a bitmap having a fixed length of 1,024 bits in consideration of fragmentation. Since the overhead of a fragment is generally large, in order to achieve a high throughput, it is preferable not to fragment an MSDU.
- the extended Block Ack frame shown in FIG. 8 therefore includes a Compressed Block Ack Bitmap 80 corresponding to 64 MSDUs on the premise that no fragmentation is performed.
- 1 bit corresponds to the reception status of 1 MSDU.
- the size of the Compressed Block Ack Bitmap 80 can be reduced to 1/16 that of a conventional Block Ack frame.
- a Block Ack frame with the Compressed Block Ack Bitmap 80 will be referred to as a “Compressed Block Ack” hereinafter.
- the Compressed Block Ack Bitmap 80 of a Compressed Block Ack may have a variable length in accordance with the number of MPDUs aggregated into one physical frame.
- TXOP period 1 QSTA 1 transmits, to QSTA 2 , a physical frame 91 in which MPDUs with sequence numbers “1” to “3” are aggregated, and QSTA 2 returns the reception statuses of the MPDUs in a physical frame 93 as a Compressed Block Ack 92 to QSTA 1 after a lapse of a SIFS.
- the HC transmits the physical frame 93 to QSTA 1 , and QSTA 1 returns the reception statuses of the MPDUs in the physical frame 93 as a Compressed Block Ack 94 to the HC after a lapse of a SIFS.
- the HC transmits a QoS CF-Poll frame 97 to QSTA 2 to assign TXOP period 3 to QSTA 2 .
- QSTA 2 transmits a physical frame 95 to the HC.
- the HC then returns the reception statuses of the MPDUs in the physical frame 95 as a Compressed Block Ack 96 to QSTA 2 after a lapse of a SIFS.
- Each embodiment of the present invention allows a Compressed Block Ack to be returned even if no Block Ack Request is contained in a physical frame. This will be referred to as an “Implicit Block Ack Request” hereinafter.
- a Block Ack Request frame may be aggregated at the end of a physical frame, and the receiving side may return a Compressed Block Ack in accordance with the information indicated by the Block Ack Request frame.
- the MAC efficiency can be improved by transmitting a plurality of MPDUs upon aggregating them, and performing selective repeat retransmission control using the above Compressed Block Ack (and Implicit Block Ack Request) technique.
- the MAC efficiency is improved by aggregating a plurality of MPDUs and then piggybacking the MPDUs in the opposite direction on a partial response from a destination.
- Application methods for the immediate Block Ack and delayed Block Ack techniques defined in IEEE 802.11e/Draft 10.0 will also be described below.
- a communication apparatus piggybacks at least one data frame on a Block Ack frame in immediate Block Ack transmission.
- the initiator side of data transmission transmits a transmission permission frame, which permits a destination terminal to piggyback a plurality of data frames, upon aggregating the control frame (Block Ack Request frame, or Block Ack frame) with a data frame.
- Such communication apparatus of the first embodiment searches a physical frame returned from a destination, when operating as a transmitting terminal. If Block Ack frame is not contained, the apparatus determines that a timeout has occurred. When a timeout associated with a Block Ack has occurred, the receiving side selects either the method of transmitting all the previously transmitted data frames as retransmission targets in the next piggyback allowable period or the method of piggybacking a Block Ack Request.
- the MAC efficiency can be improved by piggybacking a plurality of MPDUs in the opposite direction (from a destination to a transmission source) on a partial response frame from the destination.
- a destination terminal can only return a response frame to a data frame to a data transmitting terminal which has acquired a TXOP.
- a frame like the one having the arrangement shown in FIG. 10 which is used to give a transmission permission to the destination terminal to allow it perform piggyback transmission.
- IAC Intelligent Aggregation Control
- the IAC frame 100 has the same MAC header as that defined in IEEE 802.11, which is comprised of a Frame Control field, Duration field, Receiver Address field, and Transmitter Address field.
- the transmission source terminal When the destination terminal is to be assigned a transmission time for piggybacking, the transmission source terminal extracts an arbitrary period of time from the currently held TXOP period. The transmission source is not permitted to extend the assigned TXOP period itself.
- An RDTID (Reverse Direction Traffic Identifier) field 107 designates a TID as a piggyback target.
- An MCS Feedback field 108 is used to set a transmission rate in accordance with a propagation path environment (mainly used for link adaptation).
- a 4-octet FCS is added to the tail of the IAC frame 100 according to the IEEE 802.11 standard.
- FIG. 11 is a view showing how a plurality of MPDUs are aggregated and a piggyback permission is given to a destination terminal when an IAC frame is to be used.
- the example shown in FIG. 11 is a frame sequence in the case of HCCA.
- EDCA Enhanced Distributed Channel Access
- the HC transmits, to QSTA 1 , a physical frame 112 in which an IAC frame 110 and a plurality of data frames 111 with sequence numbers “1” to “14” are aggregated.
- QSTA 1 Upon receiving the physical frame 112 , QSTA 1 returns a Compressed Block Ack 113 after a lapse of a SIFS period. Since piggyback transmission is permitted by the IAC frame 110 , QSTA 1 transmits a physical frame 115 in which data 114 in the uplink direction to the HC are aggregated.
- the number of MPDUs which can be piggybacked on a Compressed Block Ack to the HC by QSTA 1 is determined within the range of duration indicated by Reverse Direction Limit or Reverse Direction Grant given by the HC. Reverse Direction Limit or Reverse Direction Grant is adjusted within the range of TXOP period 1 of the HC.
- the HC When QSTA 1 transmits the physical frame 115 in which the Compressed Block Ack 113 and the data 114 with sequence numbers “1” to “4” in the uplink direction are aggregated, the HC returns a Compressed Block Ack 116 to QSTA 1 after a lapse of a SIFS, thereby finishing TXOP period 1 .
- TXOP period 2 the HC transmits, to QSTA 2 , a physical frame 119 in which an IAC frame 117 and data frames 118 with sequence numbers “1001” to “1004” are aggregated.
- using an IAC frame makes it possible to intentionally permit a destination terminal to perform piggyback transmission.
- the MAC efficiency can be improved by causing a destination terminal which has obtained a piggyback transmission permission to perform piggyback transmission of data frames and the like.
- FIGS. 12 and 13 each show a sequence example in a case wherein after the HC transmits, to QSTA 1 , a physical frame 123 in which an IAC frame 121 and a plurality of data frames 122 with sequence numbers “1” to “4” are aggregated, a busy 124 is detected by carrier sense within a SIFS plus 1 slot time, and the FCS calculation result indicates that all the MPDUs are incorrect.
- a wireless channel when power larger than a predetermined value is detected, a wireless channel is regarded as being used (busy).
- IEEE 802.11e/Draft 10.0 standard when the HC detects a busy a SIFS after transmitting a QoS CF-Poll frame at the time of channel access by HCCA, and the FCS calculation result indicates that a received frame is incorrect, the HC retransmits a QoS CF-Poll frame to acquire a TXOP period again, a PIFS after the channel is set in an idle state.
- the HC When the HC detects a busy after transmitting a data frame, and the FCS check indicates an error, the HC retransmits the data frame after a lapse of a SIFS.
- poll frame transmission it is unknown whether or not a TXOP period has been properly acquired by destination terminal.
- data frame transmission the transmission source has already acquired a TXOP period, and hence can transmit (or retransmit) an arbitrary frame after a lapse of a SIFS.
- a Compressed Block Ack (and piggybacked data) in the direction from QSTA 1 to the HC is present, and the HC determines by FCS calculation that all the MPDUs are incorrect.
- a timer which counts the duration until a Compressed Block Ack is received causes a timeout.
- the HC detects from this timeout that no Compressed Block Ack has been received, and transmits a (explicit) Block Ack Request a SIFS after the wireless channel becomes idle.
- the HC can transmit this Block Ack Request because it can be interpreted that the HC is on the initiator side of piggyback transmission, and has acquired a TXOP.
- Block Ack Starting Sequence Control value of the Block Ack Request the sequence number “1” of the first transmitted MPDU is designated.
- the HC transmits a Block Ack Request 125 an IAC frame is not aggregated in the same physical frame. For this reason, QSTA 1 only returns an acknowledgement to the data previously received from the HC by using a Compressed Block Ack 126 . This is because since no IAC frame is present, QSTA 1 is not permitted to perform piggyback transmission.
- the communication apparatus When operating as a transmitting terminal, the communication apparatus according to the first embodiment determines, in accordance with the remaining period of the channel use period (i.e., the TXOP) assigned to the transmitting terminal, whether or not to transmit, to the destination terminal, a frame for permitting the terminal to return a partial response frame upon aggregating the frame and a plurality of MPDUs.
- the remaining period of the channel use period i.e., the TXOP
- TXOP period 1 of the HC expires, and the next TXOP period 2 starts after a lapse of a PIFS time.
- TXOP period 2 the HC transmits, to QSTA 2 , a physical frame 129 in which an IAC frame 127 and data frames 128 with sequence numbers “1001” to “1004” are aggregated.
- TXOP period 1 held by the HC is sufficient, and hence permits QSTA 1 to perform piggyback transmission, by transmitting a physical frame 132 in which an IAC frame 130 and Block Ack Request 131 are aggregated.
- QSTA 1 is permitted by the IAC frame 130 to perform piggyback transmission, and can transmit data frames 134 in the uplink direction to the HC by piggybacking them on a Compressed Block Ack (corresponding to the MPDUs with sequence numbers “1” to “4” which were transmitted first by the HC).
- the HC transmits a Compressed Block Ack 136 to the data frame 134 from QSTA 1 after a lapse of a SIFS, and then finishes TXOP period 1 .
- the HC can therefore selectively control permission/inhibition of piggybacking with respect to a destination terminal in accordance with the scheduling state on the side where a TXOP is acquired.
- FIG. 14 shows an example of operation to be performed when errors have occurred in some of a plurality of aggregated MPDUs upon uplink transmission from a QSTA to the HC.
- the HC transmits an IAC frame 140 and data frames 141 with sequence numbers “1” to “4” upon aggregating them into one physical frame 142 .
- QSTA 1 transmits a plurality of data in the uplink direction to the HC upon piggybacking them on a Compressed Block Ack 143 to the data frames 141 from the HC.
- an FCS calculation result indicates that errors have occurred in the Compressed Block Ack and an MPDU 144 with sequence number “4” from QSTA 1 .
- the transmitted MPDUs are regarded as retransmission targets as long as there is no normal Compressed Block Ack in the physical frame which has caused the busy state. For this reason, it is necessary to prompt the retransmission of a Block Ack from the destination by transmitting a Block Ack Request in accordance with the IEEE 802.11e/Draft 10.0 standard.
- QSTA 1 After a lapse of a SIFS, QSTA 1 reflectively transmits the same contents as those of the previously transmitted Compressed Block Ack (without changing any of the contents), and piggybacks data in the uplink direction on the basis of the Reverse Direction Grant (or Reverse Direction Limit) information in the IAC frame.
- QSTA 1 has detected by the Compressed Block Ack 146 from the HC that the transmission of a MPDU 150 with sequence number “4” has failed, and hence piggybacks the MPDU 150 as a retransmission target on a Compressed Block Ack 149 to the HC.
- the HC transmits a Compressed Block Ack 151 to the MPDU 150 with sequence number “4” retransmitted from QSTA 1 , thus finishing TXOP period 1 .
- TXOP period 1 acquired by the HC is short, and the HC does not have time enough to prompt frame transmission from QSTA 1 , the HC can finish the TXOP period by transmitting a Compressed Block Ack without aggregating a Block Ack Request nor an IAC.
- the HC may detect the presence/absence of an acknowledgement frame on the basis of error detection at a specific frame position in a physical frame returned from a destination terminal.
- transmitting and receiving terminals have mutually recognized that a Compressed Block Ack is returned upon piggybacking of a plurality of data thereon, and the Compressed Block Ack is always aggregated in the head portion of a physical frame.
- the transmitting terminal can cause a timeout with respect to a partial response frame, i.e., can regard that the reception of a Compressed Block Ack has failed, without searching the remaining MPDUs.
- an FCS up to the second MPDU is calculated to determine whether or not the Compressed Block Ack has successfully been received. Assume that an IAC frame is always aggregated in the head of a physical frame, and a Compressed Block Ack is aggregated at the first position in the remaining portion (i.e., next to the IAC frame in the same physical frame). In this case, if an FCS calculation result on the second MPDU indicates an error, the terminal which has received the physical frame regards that the reception of the Compressed Block Ack has failed.
- FIGS. 15 and 16 each show an example of retransmission to be performed when errors have occurred in MPDUs in a physical frame in the downlink direction from an HC to a QSTA.
- the HC has transmitted an IAC frame and a plurality of MPDUs with sequence numbers “1” to “4” upon aggregating them, and errors have occurred in MPDUs 152 and 153 with sequence numbers “1” and “4”.
- the HC detects by carrier sense during a PIFS that the wireless media is idle, the HC acquires TXOP period 2 , and transmits an IAC frame 157 and data frames 158 with sequence numbers “1” and “4” as retransmission targets upon aggregating them.
- QSTA 1 transmits a Compressed Block Ack 159 indicating that the frames with sequence numbers “1” and “4” retransmitted by the HC have been successfully received.
- TXOP period 2 then expires. In this case, there is an IAC frame in the physical frame, but piggyback transmission for QSTA 1 is not permitted.
- the HC acquires TXOP period 3 , during which the HC transmits data to QSTA 2 , after carrier sense in a PIFS. If TXOP period 1 assigned to the HC is sufficient as shown in FIG. 16 , the HC can transmit retransmission data frames 160 in the downlink direction from the HC to QSTA 1 and an IAC frame 161 , together with the Compressed Block Ack 156 to QSTA 1 to the HC, upon aggregating them. In this case, the MAC efficiency is higher than that in the example shown in FIG. 15 .
- FIGS. 17 and 18 each show an example of retransmission to be performed when error have occurred in MPDUs in both downlink and uplink physical frames.
- the HC transmits an IAC frame and data frames with sequence numbers “1” to “4” in the downlink direction to QSTA 1 upon aggregating them. Assume that the data frames with sequence numbers “1” and “4” are incorrect.
- QSTA 1 transmits data frames 171 with sequence numbers “1” and “4” in the uplink direction to the HC upon piggybacking them on a Compressed Block Ack 170 to the HC.
- an FCS calculation result indicates that errors have occurred in MPDUs of the MPDUs in the uplink direction to the HC which have sequence numbers “2” and “3”.
- TXOP period 1 in FIG. 17 is short, and hence the HC cannot afford to retransmit the incorrect MPDUs. Therefore, the HC finishes the TXOP by transmitting a Compressed Block Ack 172 to the data in the uplink direction from QSTA 1 .
- the HC upon acquiring a TXOP period again (TXOP period 2 ) after a lapse of a PIFS, the HC transmits an IAC frame 173 and MPDUs 174 with sequence numbers “1” and “4” as retransmission targets to QSTA 1 upon aggregating them.
- QSTA 1 transmits an acknowledgement to the downlink data from the HC as a Compressed Block Ack 175 upon piggybacking retransmission MPDUs within the range of the transmission permission time given by the IAC frame 173 .
- QSTA 1 piggybacks a new MPDU with sequence number “5” on the Compressed Block Ack 175 to the HC, in addition to the MPDUs with sequence numbers “2” and “3” as retransmission targets.
- the HC transmits a Compressed Block Ack 176 to the data from QSTA 1 , and finishes TXOP period 2 .
- TXOP period 1 held by the HC is relatively long, and hence the HC transmits an IAC frame 180 , a Compressed Block Ack 181 , and data frames 182 with sequence numbers “1” and “4” which need to be retransmitted, upon aggregating them, after a lapse of a SIFS since the reception of the uplink data from QSTA 1 .
- QSTA 1 transmits the MPDUs with sequence numbers “2” and “31” which need to be retransmitted and a new MPDU 184 with sequence number “5” upon piggybacking them on a Compressed Block Ack 183 to the MPDUs with sequence numbers “1” and “4”.
- Method of improving the retransmission quality may include setting the upper limit of the number of MPDUs which can be continuously transmitted to the total window size, setting an upper limit for the number of times of continuous transmission including retransmission, and adjusting the value of Reverse Direction Grant (or Reverse Direction Limit) of IAC.
- FIGS. 19 and 20 each show an example of retransmission to be performed when errors have occurred in all the data in the uplink direction from a QSTA to an HC.
- the HC transmits an IAC frame 190 and data frames 191 with sequence numbers “1” and “2” upon aggregating them.
- QSTA 1 transmits data frames 193 with sequence numbers “1” and “2” in the uplink direction upon piggybacking them on a Compressed Block Ack 192 for notifying the successful reception of the MPDUs.
- an FCS calculation result indicates that all the data in the uplink direction from QSTA 1 to the HC are incorrect (sequence numbers “1” and “2” in FIG. 19 )
- the HC finishes TXOP period 1 without generating any Compressed Block Ack.
- QSTA 1 transmits data frames to the HC, and then sets a timer for the reception of a response frame. If a busy is detected within an (SIFS+1 slot) time after the transmission of the physical frame, QSTA 1 resets the timer, and performs FCS calculation for each received MAC frame.
- This slot time is used to tolerate a physical processing error, and varies depending on physical transmission specifications. In contrast, if no busy is detected even after a lapse of an (SIFS+1 slot) time since physical frame transmission, the transmitted data frames are regarded as recovery targets. Obviously, if an FCS calculation result on a MAC frame indicates that the frame is incorrect, the transmitted data frame is regarded as a retransmission target regardless of whether a busy is detected. Referring to FIG. 19 , the HC which holds TXOP period 1 receives the Compressed Block Ack 192 from QSTA 1 , and acquires TXOP period 2 after a lapse of a PIFS.
- TXOP period 2 the HC transmits an IAC frame 194 and data frames 195 with sequence numbers “1001” and “1002” upon aggregating them.
- QSTA 1 regards the MPDUs with sequence numbers “1” and “2”, which have been transmitted in the uplink direction, as recovery targets.
- TXOP period 2 shown in FIG. 19 since a response frame which becomes a factor for a busy state is not transmitted even after a lapse of an (SIFS+1 slot) time since the transmission of data frames 196 with sequence numbers “1” and ““2” in the uplink direction from QSTA 2 to the HC, the data frames 196 are regarded as retransmission targets.
- the HC After a lapse of a SIFS, the HC transmits, to QSTA 1 , an IAC frame 201 and a Compressed Block Ack 202 to the Block Ack Request frame 200 upon aggregating them. Since the HC has not successfully received any MPDU of data from QSTA 1 which is located after the Block Ack Starting Sequence Control value of the Block Ack Request frame 200 , all the bits of the Compressed Block Ack Bitmap of the Compressed Block Ack 202 are set to 0. When the HC transmits the IAC frame and Compressed Block Ack together, QSTA 1 recognizes the presence of the two MPDUs whose transmission has failed, and retransmits them to the HC.
- QSTA 1 may directly retransmit only the data frame in the next allocated transmission period instead of transmitting a Block Ack Request.
- a delay allowable time delay bound
- a data frame 203 is directly retransmitted as shown in FIG. 20 .
- selectively transmitting a Block Ack Request or directly retransmitting all the data frames can improve the MAC efficiency as well as meet QoS requirements.
- this embodiment can be implemented not only by the method of performing recovery processing when an HC gives a piggyback permission to a QSTA as shown in FIG. 19 but also by a method of performing recovery processing at the first of the acquisition of a TXOP in an EDCA period or at the beginning of the acquisition of a TXOP by a QoS CF-Poll from the HC.
- the HC performs bandwidth management including the allocation of TXOPs to QSTAS.
- the piggyback technique can also applied to a case wherein QSTA 1 is to completely acquire a TXOP and arbitrarily transmit an arbitrary MAC frame within the period.
- the HC aggregates, for QSTA 1 , the IAC frame 201 with the Compressed Block Ack 202 .
- the HC also serves as an entity which performs scheduling for piggybacking.
- QSTA 1 is preferably made to immediately retransmit a data frame from the viewpoint of a delay allowable time (delay bound)
- the IAC frame 201 is aggregated with the Compressed Block Ack 202 as in the example shown in FIG. 19 .
- the HC recognizes that QSTA 1 needs to perform retransmission processing.
- the HC also recognizes that the QSTA needs to perform retransmission, when bits representing a reception failure and reception success are alternately arranged in the Compressed Block Ack Bitmap of a Compressed Block Ack to a QSTA, or when the Block Ack Starting Sequence Control value of a Block Ack Request is different from that of a Compressed Block Ack (on the data transmitting side, all MPDUs with lower sequence numbers than the Block Ack Starting Sequence Control value of the Compressed Block Ack are regarded as those whose transmission has failed).
- the HC transmits an IAC frame for permitting a QSTA to perform piggybacking in accordance with the determination made by the scheduler device of the HC.
- an IAC frame may be transmitted in advance to the QSTA to give it a margin for retransmission by piggybacking.
- FIGS. 21 and 22 each show an example of retransmission to be performed when errors have occurred in all the MPDUs aggregated and transmitted from an HC through a downlink.
- the HC transmits an IAC frame 210 and data frames 211 with sequence numbers “1” to “4” to QSTA 1 upon aggregating them.
- QSTA 1 cannot understand the MPDUs in the physical frame transmitted by the HC at all, and cannot determine whether or not the frame contains any MPDU addressed to itself.
- the HC in performing channel access by HCCA, when no response is returned from a destination after an HC transmits the first frame (data or QoS CF-Poll) in a given TXOP period, the HC needs to transmit a frame again after performing carrier sense in a PIFS. In the example shown in FIG. 21 , therefore, the HC acquires TXOP period 2 after a lapse of a PIFS, and transmits a Block Ack Request 212 to make a QSTA set a NAV. In addition, in the example shown in FIG.
- an IAC frame 213 is aggregated with the Block Ack Request 212 .
- QSTA 1 piggybacks a plurality of data 215 in the uplink direction to the HC on a Compressed Block Ack frame 214 to the MPDUs with sequence numbers “1” to “4” which QSTA 1 has failed to receive in TXOP period 1 .
- the HC finishes TXOP period 2 by transmitting a Compressed Block Ack 216 to QSTA 1 .
- the Compressed Block Ack Bitmap of the Compressed Block Ack frame 214 which is transmitted by QSTA 1 to the HC in TXOP period 2 is filled with 0s to express that QSTA 1 has failed to receive all the MPDUs.
- the scheduling processing unit of the HC can improve the MAC efficiency by determining whether or not to transmit an IAC frame to the QSTA, in consideration of a delay allowable time (delay bound) and the like.
- a terminal upon receiving a physical frame in which a plurality of data are aggregated without any Block Ack Request, a terminal returns reception statuses of the MPDUs as a Compressed Block Ack after a lapse of a SIFS.
- the present invention can also be applied to even a case wherein a physical frame in which a plurality of data are aggregated contains a Block Ack Request at the end as shown in FIG. 23 .
- the basic operation without using Implicit Block Ack Request like FIG. 9 is the same as that in the case wherein a physical frame contains no Block Ack Request, a retransmission example in this case will be described with reference to FIG. 23 .
- the HC transmits an IAC frame 230 , a plurality of data 231 with sequence numbers “1” to “4”, and a Block Ack Request frame 232 with a Block Ack Starting Sequence Control value of “1” upon aggregating them.
- QSTA 1 has not successfully received the data 231 with sequence numbers “1” and “4” and the Block Ack Request frame 232 . Since QSTA 1 has not received any Block Ack Request from the HC, QSTA 1 cannot transmit any Compressed Block Ack. However, QSTA 1 stores in advance reception information such as the Block Ack Starting Sequence Control value “2” and the Compressed Block Ack Bitmap “110 .
- TXOP period 1 QSTA 1 transmits data frames 233 with sequence numbers “1” to “3” and a Block Ack Request 234 with a Block Ack Starting Sequence Control value of “1” upon aggregating them.
- the HC does not successfully receive the Block Ack Request 234 , the HC returns no Compressed Block Ack. If the data frame transmitting side detects a busy within an (SIFS+1 slot) time, but there is no Compressed Block Ack frame addressed to itself in the received physical frame, the transmitted frames are regarded as retransmission targets.
- the HC transmits an IAC frame 235 and a Block Ack Request frame 236 for prompting QSTA 1 to retransmit the Compressed Block Ack upon aggregating them.
- QSTA 1 transmits a Block Ack Request frame 238 to the HC upon piggybacking it on a Compressed Block Ack 237 indicating that the MPDUs with sequence numbers “1” and “4” are incorrect.
- the HC then transmits an IAC frame 239 , a Compressed Block Ack 240 to the Block Ack Request from QSTA 1 , MPDUs 241 with sequence numbers “1” and “4” for retransmission, and a Block Ack Request frame 242 upon aggregating them.
- QSTA 1 transmits a Compressed Block Ack 243 as an acknowledgement. If piggybacking is permitted by an IAC frame and data to be transmitted to the HC exists in a transmission queue, the data is also transmitted together. As described above, whether or not to permit QSTA 1 to perform piggybacking is determined in accordance with determination made by the scheduling processing device of the HC.
- the MAC efficiency can be improved by transmitting a plurality of MPDUs upon aggregating them and transmitting data in the opposite direction upon piggybacking it on a partial response frame from the destination.
- This embodiment has been described mainly on the basis of HCCA which is a contention-free QoS access control scheme.
- the present invention can also be applied to contention-based EDCA.
- a terminal which has acquired a TXOP serves as an entity of scheduling and adjusts the amount of frames piggybacked and transmitted from a destination terminal by using an IAC frame.
- a QSTA which has acquired a TXOP upon receiving a QoS CF-Poll frame from an HC permits a destination terminal to perform piggyback transmission by suing an IAC frame.
- These scheduling operations depend on the delay allowable time (delay bound) and the like represented by QoS data.
- the second embodiment of the present invention is directed to delayed Block Ack transmission, in which a Normal acknowledgement frame for allowing the transmission of a Block Ack to be postponed is replaced with the IAC frame described in the first embodiment. More specifically, a communication apparatus according to the second embodiment of the present invention transmits a plurality of data frames and then uses an IAC frame from a destination terminal to another destination in place of a Normal acknowledgement to a delayed Block Ack. After a lapse of a predetermined period of time, the destination terminal transmits the Block Ack frame and a plurality of data upon aggregating them.
- a delayed Block Ack like the one shown in FIG. 5 can be used.
- the delayed Block Ack technique first of all, an Ack response (Normal acknowledgement) to a Block Ack Request is returned. After a lapse of an arbitrary period of time, a Block Ack frame is transmitted, and an Ack response (Normal acknowledgement) to the frame is returned.
- the delayed Block Ack technique if Normal acknowledgement frame can not be received after a lapse of a predetermined period of time since the transmission of a Block Ack Request or Block Ack, the transmission of the corresponding frames is regarded as failed.
- the second embodiment of the present invention is directed to piggyback transmission using the delayed Block Ack technique.
- FIG. 24 shows how frames are exchanged when piggybacking described in the second embodiment of the present invention is performed by using the conventional delayed Block Ack Policy defined in IEEE 802.11e.
- the HC upon acquiring TXOP period 1 , the HC transmits an IAC frame 244 and data frames 245 with sequence numbers “1” and “2” upon aggregating them.
- QSTA 1 transmits data 247 in the uplink direction upon piggybacking it on a Compressed Block Ack 246 to the data frames 245 from the HC within the period assigned by the IAC frame 244 .
- the HC transmits a Normal acknowledgement frame 248 defined in IEEE 802.11 to notify the reception of the delayed Block Ack procedure.
- QSTA 1 regards the data frame (or a Block Ack Request frame) as a retransmission target.
- TXOP period 2 in FIG. 24 as in the case of TXOP period 1 , when the delayed policy is used for a Compressed Block Ack from the HC to QSTA 2 , the TXOP expires after a Normal acknowledgement 249 is transmitted to QSTA 2 .
- TXOP period 3 the HC transmits, to QSTA 1 , a data frame 250 with sequence number “3” in the downlink direction and a Compressed Block Ack 251 with a Block Ack Starting Sequence Control value of “1” whose transmission is delayed in TXOP period 1 upon aggregating them, and QSTA 1 transmits a Normal acknowledgement frame 252 , thereby completing one delayed Block Ack sequence.
- TXOP period 3 in FIG. 24 a Compressed Block Ack 253 with a Block Ack Starting Sequence Control value of “3” to the downlink data from the HC is piggybacked on the Normal acknowledgement frame 252 .
- the MAC efficiency inevitably decreases due to the use of the Ack frame defined in IEEE 802.11.
- the second embodiment of the present invention therefore realizes a mechanism for solving such a problem.
- the delayed Block Ack Policy is mainly applied to the transmission of a Compressed Block Ack from an HC to a QSTA
- the present invention can be applied to both uplink transmission and downlink transmission.
- FIGS. 25 and 26 each show a basic embodiment of the present invention concerning its application to the delayed Block Ack technique.
- the Normal acknowledgement frame defined in IEEE 802.11 is transmitted in a normal state. Instead of this operation, however, an IAC frame to another destination is transmitted after a lapse of a SIFS.
- An IAC frame can be used for various applications by setting 1 in each bit of the IAC Mask field shown in FIG. 10 . In this case, in order to indicate that the transmission of a delayed Block Ack is allowed, a 1-bit identification flag is prepared in the IAC Mask field.
- the HC transmits, to QSTA 2 , data frames 255 with sequence numbers “1001” and “1002”, the destination MAC address of an IAC frame 254 to be simultaneously aggregated has been set to QSTA 2 .
- the HC sets an extended flag in the IAC Mask field of an IAC frame to 1, which indicates that a delayed Block Ack has been accepted (to which negative logic can be obviously applied).
- QSTA 1 recognizes in advance that the delayed Block Ack Policy is applied to a Compressed Block Ack returned from the HC. Assume that QSTA 1 detects a busy state in the wireless channel within an (SIFS+1 slot) time after the transmission of data in the uplink direction to the HC.
- the HC in FIG. 25 transmits data to QSTA 2 a SIFS after the reception of a physical frame from QSTA 1 .
- the transmitted frame is regarded as a retransmission target. Therefore, a frame by which the HC notifies the QSTA of the acceptance of a delayed Block Ack needs to be transmitted after a lapse of a SIFS.
- QSTA 1 Upon detecting a busy a SIFS after the transmission of the frame to the HC, QSTA 1 resets the timer.
- the HC transmits data 256 with sequence number “3”, an IAC frame 257 to QSTA 1 , and a Compressed Block Ack 258 with a Block Ack Starting Sequence Control value of “1” to QSTA 1 upon aggregating them a SIFS after the reception of a frame in the uplink direction from QSTA 2 .
- the Compressed Block Ack 258 is an acknowledgement frame to MPDUs with sequence numbers “1” and “2” transmitted first by QSTA 1 .
- the destination of the IAC frame 257 is QSTA 1 , setting a flag in the IAC Mask notifies that delayed Block Ack transmission of data in the uplink direction from QSTA 2 is accepted.
- transmitting the Compressed Block Ack also serves as transmitting the Ack frame defined in IEEE 802.11. That is, when the HC transmits data with sequence number “3” and a Compressed Block Ack based on the delayed policy, and the destination (QSTA 1 in the example shown in FIG. 25 ) then returns a Compressed Block Ack according to the immediate policy, it is regarded that a Normal acknowledgement frame to the Block Ack is received as defined in IEEE 802.11e/Draft 10.0.
- an IAC frame is also aggregated, and it is notified by using the frame that the delayed Block Ack technique is accepted.
- the Normal acknowledgement frame defined in IEEE 802.11 is transmitted to finish the TXOP period.
- the HC transmits a Normal acknowledgement frame 261 to QSTA 2 to notify that the delayed Block Ack is accepted.
- the HC transmits a Compressed Block Ack 262 based on the delayed policy and a downlink data 263 to QSTA 1 upon aggregating.
- a Compressed Block Ack from QSTA 1 also serves as a Normal acknowledgement (an Ack to a Block Ack).
- an IAC frame to another destination is regarded as an Ack response to a delayed Block Ack. Therefore, when an IAC frame is used as a Normal acknowledgement in the delayed Block Ack technique as shown in FIGS. 25 and 26 , the MAC efficiency can be improved as compared with a case wherein the conventional delayed Block Ack Policy defined in IEEE 802.11e/Draft 10.0 is used.
- FIGS. 27 to 30 each show how frames are exchanged in the execution of retransmission due to errors.
- the basic operation in this case is the same as that in the first embodiment of the present invention.
- the HC transmits downlink data 271 with sequence numbers “1” and “2” to QSTA 1 .
- the HC detects only a busy 272 .
- the HC transmits a Block Ack Request frame 274 and IAC frame 273 to QSTA 1 upon aggregating them.
- QSTA 1 When the immediate Block Ack Policy is applied to a Compressed Block Ack from QSTA 1 to the HC, QSTA 1 transmits a Compressed Block Ack 275 a SIFS after the reception of the Block Ack Request frame 274 from the HC.
- QSTA 1 transmits the Compressed Block Ack 275 with a Block Ack Starting Sequence Control value of “1” and data 276 in the uplink direction to the HC upon piggybacking them.
- the HC uses an IAC frame 277 addressed to QSTA 2 to notify that the application of the delayed Block Ack Policy is accepted, as in the example shown in FIG. 25 .
- transmitting only the Compressed Block Ack can also serve as transmitting the Normal acknowledgement defined in IEEE 802.11, as described above.
- QSTA 1 completes the delayed Block Ack sequence by transmitting a Normal acknowledgement 278 .
- FIG. 28 shows an example of operation to be performed when errors have occurred in some of the MPDUs in the uplink direction from a QSTA to an HC.
- errors have occurred in a Compressed Block Ack 280 from QSTA 1 to the HC and data 281 with sequence number “2” in the uplink direction.
- the HC cannot receive any Compressed Block Ack from QSTA 1 .
- the HC therefore transmits a Block Ack Request 282 .
- An IAC frame 283 is aggregated in the Block Ack Request 282 transmitted by the HC.
- the destination of the IAC frame 283 is QSTA 1 , and 1 (0 in the case of negative logic) is set in the flag in the IAC Mask field.
- QSTA 1 Upon receiving the IAC frame 283 , QSTA 1 confirms that the delayed policy is properly applied to data with sequence numbers “1” and “2” transmitted by itself. QSTA 1 then retransmits the Compressed Block Ack 283 with a Block Ack Starting Sequence Control value of “1”. After a lapse of a SIFS, the HC transmits an IAC frame 284 and data 285 with sequence numbers “1001” and “1002” to QSTA 2 upon aggregating them. At this time, the value of the flag in the IAC Mask field of the IAC frame 284 is kept at 0 which is the initial value (1 in the case of negative logic). This is because the notification of the acceptance of the delayed Block Ack Policy for data from QSTA 1 has already been completed.
- the HC transmits downlink data (sequence number “3”) 286 and a Compressed Block Ack 287 based on the delayed policy with a Block Ack Starting Sequence Control value of “1” to QSTA 1 .
- QSTA 1 makes a Compressed Block Ack 288 to sequence number “3” from the HC also serve as a Normal acknowledgement frame to the Block Ack.
- QSTA 1 retransmits data frame 289 with sequence number “2”, whose transmission has failed, upon piggybacking.
- FIG. 29 shows an example of retransmission to be performed when errors have occurred in some of MPDUs aggregated in a physical frame in the downlink direction.
- QSTA 1 since the immediate policy is applied to Compressed Block Ack transmission from a QSTA to an HC, QSTA 1 returns a Compressed Block Ack 290 to indicate that an error has occurred in an MPDU with sequence number “1” from the HC, and the HC retransmits an MPDU 291 with sequence number “1”.
- TXOP period 2 the HC transmits data frames 292 with sequence numbers “1001” and “1002” and an IAC frame 293 to QSTA 2 upon aggregating them.
- QSTA 2 transmits, to the HC, a Compressed Block Ack 294 based on the immediate policy and data 295 in the uplink direction upon piggybacking them.
- the HC sets 1 in the flag in the IAC Mask field of an IAC frame 297 aggregated with the data.
- QSTA 2 confirms that the delayed policy is applied to a partial response from the HC to the uplink data transmitted by QSTA 2 .
- FIG. 30 shows a case wherein errors have occurred in all data in the uplink direction from a QSTA to an HC, and the HC cannot return a Compressed Block Ack.
- QSTA 1 since QSTA 1 is permitted by an IAC frame from the HC to perform piggyback transmission, QSTA 1 piggybacks data (sequence numbers “1” and “2”) 300 in the uplink direction on a Compressed Block Ack 301 .
- an FCS calculation result indicates that all the data frames transmitted from QSTA 1 are incorrect, the HC does not return Compressed Block Ack.
- the HC then performs downlink transmission to QSTA 2 within the range of TXOP period 1 .
- the flag in the IAC Mask field of an IAC frame 302 to QSTA 2 remains the initial value “0” (“1” in the case of negative logic).
- QSTA 1 is monitoring the physical frame transmitted from the HC, and checks the flag in the IAC frame 302 . However, since the value remains 0, QSTA 1 determines that the application of the delayed policy to the Compressed Block Ack has failed, and regards the transmitted data frames 300 as retransmission targets.
- QSTA 1 piggybacks a Block Ack Request 306 on a Compressed Block Ack (Block Ack Starting Sequence Control value of “3”) 305 to the data 303 from the HC.
- QSTA 1 may directly aggregate the data with sequence numbers “1” and “2” as retransmission targets.
- the scheduling processing device of QSTA 1 selects whether to piggyback the Block Ack Request 306 or directly aggregate the frames as retransmission targets.
- the HC Assume that after a lapse of a SIFS since the reception of a frame from QSTA 1 , the HC is to transmit data to another QSTA. In this case, the HC sets 1 (0 in the case of negative logic) in the flag in the IAC Mask field of an IAC frame. This makes QSTA 1 recognize that Compressed Block Ack return based on the delayed policy is applied, on the HC side, to the Block Ack Request (or data) transmitted by itself.
- the MAC efficiency can be improved by efficiently applying the piggyback technique to the delayed Block Ack technique.
- the delayed policy is applied to a Compressed Block Ack from an HC to a QSTA (i.e., uplink data from a QSTA), and the immediate policy is applied to a Compressed Block Ack from a QSTA to an HC (i.e., downlink data to a QSTA).
- the present invention allows the delayed policy to be applied to Compressed Block Acks in both the uplink and downlink directions.
- the present invention can be applied to a method in which, upon acquiring a TXOP by EDCA, a terminal having an access right plays a leading role in executing the delayed Block Ack technique using an IAC frame.
- the present invention can be applied to a case wherein a Block Ack Request is to be aggregated with the end of a physical frame (explicit Block Ack Request), as in the first embodiment. In this case, if an FCS calculation result indicates that the Block Ack Request is incorrect, the data receiving side does not transmit Compressed Block Ack. Thereafter, the data transmitting terminal requests the receiving side to retransmit a Compressed Block Ack, by, for example, retransmitting a Block Ack Request frame.
- the third embodiment of the present invention is directed to the application of the immediate Block Ack technique and delayed Block Ack technique in a case wherein a plurality of MPDUs are aggregated and transmitted to a plurality of destinations.
- IFS Interframe Space
- aggregating MAC frames addressed to a plurality of different destinations into one physical frame makes it possible to reduce these overheads and improve the MAC efficiency.
- FIG. 31 shows an example of a MAC frame containing information associated with a plurality of destinations. Aggregating a MAC frame 310 like this frame in the head of a physical frame allows a physical frame receiving terminal to immediately determine whether or not there is any MPDU addressed to itself exists.
- the MAC frame 310 like the one shown in FIG. 31 will be referred to as an “MRAD (Multiple Receiver Aggregation Descriptor) frame” hereinafter.
- the MAC frame 310 has a conventional MAC header 311 defined in IEEE 802.11 which includes “Frame control”, “Duration”, “Receiver Address”, “Transmitter Address”, and the like.
- the MAC frame 310 includes a Number of receivers field 312 indicating the number of destinations of MPDUs aggregated in the physical frame, a Receiver Address Info field 313 indicating destination MAC address information, and Length field 314 for designating, in octets, an information size to be occupied for each destination.
- the example shown in FIG. 31 exemplifies information up to “Receiver Address Info 3 ”.
- the number of pieces of information is not limited to this, and an arbitrary variable length can be set. That is, the number of destinations is arbitrarily set.
- FIG. 32 shows an example of frames which are exchanged when the immediate Block Ack Policy is applied.
- the HC Upon acquiring a TXOP, the HC transmits an MRAD frame 320 , an IAC 321 and data frames (sequence numbers “1” and “2”) 322 to QSTA 1 , and an IAC 323 and data frames (sequence numbers “1001” and “1002”) 324 upon aggregating them into one physical frame 325 .
- Using the information of the MRAD frame 320 allows terminals other than QSTAs 1 and 2 to freely perform processing such as shifting to the power saving mode.
- Offset times from the end of the transmission of a physical frame from the HC are written in the IAC frames 321 and 323 addressed to QSTAs 1 and 2 to designate the timings at which QSTAs 1 and 2 respond.
- the Response Period Offset field in the example shown in FIG. 10 is used.
- QSTA 1 successfully receives an IAC frame addressed to itself, it aggregates uplink data 327 with a Compressed Block Ack 326 to the HC within the range of piggyback transmission allowable time, and transmits the resultant data, as shown in FIG. 32 .
- QSTA 2 transmits Compressed Block Ack 328 and uplink data 329 to the HC upon aggregating them.
- the example in FIG. 32 shows that all data frames 329 transmitted by QSTA 2 are incorrect.
- the HC transmits an MRAD frame 330 and an IAC 331 and Compressed Block Ack frame 332 to QSTA 1 upon aggregating them a SIFS after the end of frame transmission by QSTA 2 . Since all the data from QSTA 2 are incorrect, the Compressed Block Ack frame from the HC to QSTA 2 is not aggregated. In this case, if the HC does not permit QSTA 2 to perform frame transmission in the opposite direction (uplink), the Receiver Address Info field of the MRAD frame 330 does not contain the MAC address of QSTA 2 .
- the Number of receivers field is 1, and only the MAC address of QSTA 1 and length information are written. If the HC is to permit QSTA 2 to perform transmission, it aggregates an IAC frame addressed to QSTA 2 , sets “Number of receivers” to 2 , and adds the MAC address of QSTA 2 .
- QSTAs 1 and 2 check the Receiver Address Info field in the MRAD frame aggregated in the physical frame from the HC. If each QSTA detects no MAC address of its own, the QSTA regards the transmitted frame as a recovery target. In the example shown in FIG. 32 , QSTA 2 determines that it has failed to receive an immediate type Compressed Block Ack to transmitted data with sequence numbers “1” and “2”, and performs appropriate recovery operation.
- FIGS. 33 and 34 each show an application example of the delayed Block Ack Policy.
- the HC transmits an IAC 331 and data frame (sequence number “1”) 332 to QSTA 1 , and an IAC 333 and data frame (sequence number “1001”) 334 to QSTA 2 upon aggregating them into one physical frame 335 .
- QSTAs 1 and 2 recognize the timings of transmission to uplinks on the basis of the respective pieces of IAC frame information, respectively piggyback uplink data 338 and 339 on Compressed Block Acks 336 and 337 .
- the HC can regard a frame for giving a permission to perform transmission in the opposite direction (permits a terminal having no TXOP to perform transmission) as a Normal acknowledgement frame to a Block Ack Request frame by delayed Block Ack transmission defined in IEEE 802.11e/Draft 10.0.
- the HC aggregates an IAC frame 340 to QSTA 1 , QSTA 2 , and QSTA 3 and data (sequence number “2001”) 341 in the downlink direction to QSTA 3 and transmits the resultant data.
- Both Reverse Direction Grant and Response Period Offset of the IAC frame to each of QSTAs 1 and 2 are set to 0. That is, the HC does not permit QSTAs 1 and 2 to perform transmission in the uplink direction.
- a flag indicating the acceptance of the delayed Block Ack technique is set ON.
- each of QSTAs 1 and 2 confirms that the delayed Block Ack Policy is applied to the data transmitted by itself.
- QSTA 3 transmits a Compressed Block Ack 342 to the data (sequence number “2001”) from the HC and data 343 in the uplink direction upon aggregating them.
- the HC transmits IAC frames 344 to QSTAs 1 , 2 , and 3 and Compressed Block Acks 345 to QSTAs 1 and 2 .
- the Compressed Block Ack 345 is a Block Ack based on the delayed policy to data in the uplink direction from QSTAs 1 and 2 .
- values are set in Reverse Direction Grant and Response Period Offset of the IAC frame 344 to each of QSTAs 1 and 2 to allow each QSTA to transmit at least the Normal acknowledgement frame defined in IEEE 802.11.
- a flag is set in the IAC Mask field of QSTA 3 to notify the acceptance of the delayed Block Ack technique. As shown in FIG.
- the HC transmits Normal acknowledgement frames 346 defined in IEEE 802.11 which are prepared for the respective destinations and aggregated. That is, an aggregation of Normal acknowledgements is performed for a plurality of destinations.
- Buffer management on the receiving side in a case wherein data addressed to a plurality of destinations are aggregated will be described with reference to FIGS. 35 and 36 .
- an MRAD frame 350 an IAC 351 to QSTA 1 , data frames 352 and 353 with sequence numbers “1” and “2”, an IAC 354 to QSTA 2 , and data frames 355 and 356 with sequence numbers “1001” and “1002” are aggregated and transmitted.
- a format like the one shown in FIG. 6 may be used to aggregate a plurality of frames.
- an FCS calculation result indicates that an error has occurred in the MPDU 352 with sequence number “1”.
- QSTA 1 transmits a Compressed Block Ack 360 with a Block Ack Starting Sequence Control value of “2”
- QSTA 2 transmits a Compressed Block Ack 361 with a Block Ack Starting Sequence Control value of “1001”.
- the sequence number of the first MPDU which has been successfully received is used as the Block Ack Starting Sequence Control value of the Compressed Block Ack.
- QSTA 2 has successfully received all frames, and hence performs reception buffer management by setting the sequence number “1001” as a proper Block Ack Starting Sequence Control value.
- sequence number “1001” As a proper Block Ack Starting Sequence Control value.
- all MAC frames having lower sequence numbers than the Block Ack Starting Sequence Control value must be released from the reception buffer and forwarded to the upper layer. For this reason, QSTA 2 in FIG. 36 releases MAC frames with sequence numbers “999” to “1002” from the reception buffer 363 and forwards them to the upper layer.
- a format containing no IAC frame can also be used.
- an FCS calculation result indicates that an error has occurred in the data with sequence number “2” to QSTA 2 .
- an FCS calculation result on the data frame with sequence number “1001” to QSTA 2 is correct, it cannot be determined up to which MPDUs to QSTA 1 are aggregated. For this reason, even if a Compressed Block Ack is returned, no MAC frame can be released from the reception buffer.
- reception buffer management is performed by determining the sequence number of the second MPDU (i.e., the MPDU having the new destination) as a proper Block Ack Starting Sequence Control value for the next destination.
- MAC frames are classified according to the priorities of traffic events and a Block Ack Request and Block Ack frame are required for each priority.
- the BAR (Block Ack Request) field of the Block Ack Request frame in FIG. 2 and the BA (Block Ack) Control field of the Block Ack in FIG. 3 each include a 4-bit TID (Traffic Identifier), in which a number 0 to 15 is written.
- TID Traffic Stream Identifier
- RDTID Reverse Direction Traffic Identifier
- the RDTID field of an IAC frame is used by a transmitting terminal which has acquired a TXOP to designate a priority to a MAC frame to be piggybacked when permitting a destination terminal to perform piggyback transmission.
- a sequence number must be independently assigned to a MAC frame for each TID.
- the QoS data receiving side therefore preferably manages the reception buffer for each priority.
- all MAC frames having lower sequence numbers than the Starting Sequence Number (Block Ack Starting Sequence Control) indicated by a Block Ack Request frame are released from a reception buffer.
- reception buffer management since a Block Ack Request frame is prepared for each TID, reception buffer management must be done for each priority (TID).
- TID priority
- the description of the reception buffer management which has been made with reference to FIGS. 35 and 37 is about the case wherein MAC frames addressed to a plurality of destinations, with a single priority (one kind of TID), are aggregated into a physical frame.
- the present invention can be applied to a case wherein MAC frames addressed to a plurality of destinations, with a plurality of priorities, are aggregated into a single physical frame. Referring to FIG.
- the IAC frame to QSTA 1 following the MRAD, the IAC frame to QSTA 1 , the data frames with sequence numbers “1” and “2”, the IAC frame to QSTA 2 , and the data frames with sequence numbers “1001” and “1002” are aggregated in the order named.
- an IAC frame with a high priority (the value of the TID is arbitrarily set) to QSTA 1
- data frames with sequence numbers “1” and “2” an IAC frame with an intermediate priority to QSTA 1
- data frames with sequence numbers “1” and “2” data frames with sequence numbers “1” and “2”
- an IAC frame with a high priority (the value of the TID is arbitrarily set) to QSTA 2
- data frames with sequence numbers “1001” and “1002” an IAC frame with an intermediate priority to QSTA 1
- data frames with sequence numbers “1001” and “1002” are aggregated in the order named.
- the sequence number of the MPDU is regarded as a proper Starting Sequence Number (Block Ack Starting Sequence Control). All MAC frames having lower sequence numbers than the Starting Sequence Number are then released from a corresponding buffer prepared for each priority in the receiving terminal and forwarded to the upper layer.
- a physical frame need not necessarily contain any IAC frame, as shown in FIG. 37 .
- the sequence number of the second MPDU is used for the management of a reception buffer prepared for each priority in the destination terminal of the MPDU. That is, all MAC frames having lower sequence numbers than the proper Block Ack Starting Sequence Control are released from the reception buffer and forwarded to the upper layer.
- This embodiment has exemplified the case wherein in downlink transmission from an HC (QoS access point) to a QSTA (QoS station), MAC frames addressed to a plurality of destinations are aggregated and transmitted.
- a QSTA may serve as an entity of transmission as long as a TXOP is given by a QoS CF-Poll frame.
- destination candidates include, for example, terminals which can directly communicate with each other between QSTAs through DLS (Direct Link Set-up), in addition to access points.
- DLS Direct Link Set-up
- the present invention can also be applied to contention-based EDCA as well as HCCA which is a contention-free QoS access control scheme.
- a terminal which has acquired a TXOP serves as a start point of data transmission to a plurality of destinations.
- the permission of piggyback transmission to a destination by an IAC frame is also realized by the scheduling processing device of a terminal which has acquired a TXOP.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Abstract
A physical frame is generated and transmitted to a destination terminal. In this physical frame, one of a data frame, an acknowledgement frame, and an acknowledgement request frame, and a transmission permission frame which is used in place of a normal Ack frame associated with a delayed Block Ack, and permits the destination terminal to perform piggyback transmission, are aggregated.
Description
- This application is based upon and claims the benefit of priority from prior Japanese Patent Application No. 2004-318487, filed Nov. 1, 2004, the entire contents of which are incorporated herein by reference.
- 1. Field of the Invention
- The present invention relates to a communication apparatus and method which perform media access control on the basis of the carrier sense information of a physical layer and the carrier sense information of a MAC layer.
- 2. Description of the Related Art
- Media access control (MAC) is control for causing a plurality of communication apparatuses which perform communication while sharing the same media to decide how to use the media in transmitting communication data. Owing to media access control, even if two or more communication apparatuses transmit communication data by using the same media at the same time, there is less chance of the occurrence of a phenomenon (collision) in which a communication apparatus on the receiving side cannot separate communication data. Media access control is also a technique for control-ling access from communication apparatuses to a media so as to minimize the chance of the occurrence of a phenomenon in which, despite the presence of communication apparatuses having transmission requests, the media is not used by any of the communication apparatuses.
- In wireless communication, since it is difficult for a communication apparatus to monitor transmission data while transmitting the data, media access control (MAC) which is not premised on collision detection is required. IEEE 802.11 is a typical technical standard for wireless LANs, and uses CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). According to CSMA/CA in IEEE 802.11, in the header of a MAC frame, a period (Duration) until the end of a sequence comprising one or more frame exchanges following the frame is set. In this period, a communication apparatus which is irrelevant to the sequence and has no transmission right waits for transmission upon determining a virtual occupied state of the media. This prevents the occurrence of collision. On the other hand, a communication apparatus which has a transmission right in this sequence recognizes that the media is not used except for a period during which the media is actually occupied. IEEE 802.11 defines that the state of a media is determined on the basis of such a combination of virtual carrier sense on a MAC layer and physical carrier sense on a physical layer, and media access control is performed on the basis of the determination.
- IEEE 802.11 using CSMA/CA has increased the communication speed mainly by changing the physical layer protocol. With regard to the 2.4 GHz band, there have been changes from IEEE 802.11 (established in 1997, 2 Mbps) to IEEE 802.11b (established in 1999, 11 Mbps), and further to IEEE 802.11g (established in 2003, 54 Mbps). With regard to the 5 GHZ band, only IEEE 802.11a (established in 1999, 54 Mbps) exists as a standard. In order to develop standard specifications directed to further increase communication speeds in both the 2.4 GHz band and the 5 GHz band, IEEE 802.11 TGn (Task Group n) has already been established.
- In addition, several access control techniques designed to improve QoS (Quality of Service) are known. For example, as a QoS technique of guaranteeing parameters such as a designated bandwidth and delay time, HCCA (HCF Controlled Channel Access) which is an extended scheme of a conventional polling sequence is available. According to HCCA, scheduling is performed in a polling sequence in consideration of required quality so as to guarantee parameters such as a bandwidth and delay time. Jpn. Pat. Appln. KOKAI Publication No. 2002-314546 refers to QoS in the IEEE 802.11e standard, and discloses a method of assigning priorities to communications between communication apparatuses in a wireless network.
- When the same frequency band as that in the existing specifications is to be used in realizing an increase in communication speed, it is preferable to assure coexistence with communication apparatuses conforming to the existing specifications and to maintain backward compatibility. For this reason, it is basically preferable that a protocol on a MAC layer conforms to CSMA/CA matching the existing specifications. In this case, a temporal parameter associated with CSMA/CA, e.g., an IFS (Interframe Space) or backoff period needs to match that in the existing specifications.
- Even if an attempt to increase the communication speed in terms of physical layer succeeds, the effective throughput of communication cannot be improved. That is, when an increase in the communication speed of the physical layer is realized, the format of a PHY frame ceases to be effective any more. An increase in overhead due to this may hinder an increase in throughput. In a PHY frame, a temporal parameter associated with CSMA/CA is permanently attached to a MAC frame. In addition, a PHY frame header is required for each MAC frame.
- As a method of reducing overhead and increasing throughput, a Block Ack technique introduced in recently drafted IEEE 802.11e/draft 5.0 (enhancement of QoS in IEEE 802.11) is available. The Block Ack technique can consecutively transmit a plurality of MAC frames without any backoff, and hence can reduce the backoff amount to some degree. However, a physical layer header cannot be effectively reduced. In addition, according to aggregation introduced in initially drafted IEEE 802.11e, both the backoff amount and the physical layer header can be reduced. However, since the length of a physical layer frame containing MAC frames cannot be increased beyond about 4 kbytes under the conventional limitation on the physical layer, an improvement in efficiency is greatly limited. Even if the length of a PHY layer frame can be increased, another problem arises, i.e., a reduction in error tolerance.
- The present invention has been made to solve the above problems, and has as its object to provide a method for a communication apparatus which can coexist with an existing apparatus and can improve the substantial communication throughput by eliminating overhead accompanying the transmission of a plurality of frames by making a frame format more efficient.
- According to an aspect of the present invention, there is provided a communication method including generating a physical frame in which: one of a data frame, an acknowledgement frame, and an acknowledgement request frame, and a transmission permission frame which is used in place of a normal Ack frame associated with a delayed Block Ack, and permits a destination terminal to perform piggyback transmission, are aggregated; and transmitting the physical frame to the destination terminal.
-
FIG. 1 is a block diagram showing the arrangement of a communication apparatus according to an embodiment of the present invention; -
FIG. 2 is a view showing the format of a Block Ack Request frame defined in IEEE 802.11e/Draft 10.0; -
FIG. 3 is a view showing the format of a Block Ack frame defined in IEEE 802.11e/Draft 10.0; -
FIG. 4 is a view showing an example of an immediate Block Ack sequence; -
FIG. 5 is a view showing an example of a delayed Block Ack sequence; -
FIG. 6 is a view showing an example of the aggregation of a plurality of MPDUs; -
FIG. 7 is a view showing another example of the aggregation of a plurality of MPDUs; -
FIG. 8 is a view showing the format of a Compressed Block Ack; -
FIG. 9 is a view showing an example of a Compressed Block Ack sequence; -
FIG. 10 is a view showing the format of an IAC (Initiator Aggregation Control) frame; -
FIG. 11 is a view showing an example of piggyback transmission using IAC frames; -
FIG. 12 is a view showing a case wherein an explicit Block Ack Request is transmitted upon occurrence of a transmission error; -
FIG. 13 is a view showing a case wherein an IAC frame is added to an explicit Block Ack Request; -
FIG. 14 is a view showing a case wherein errors have occurred in some of frames transmitted in the uplink direction; -
FIG. 15 is a view showing a case wherein errors have occurred in some of frames transmitted in the downlink direction; -
FIG. 16 is a view showing another case wherein errors have occurred in some of frames transmitted in the downlink direction; -
FIG. 17 is a view a case wherein errors have occurred in some of frames transmitted in both the uplink direction and the downlink direction; -
FIG. 18 is a view another case wherein errors have occurred in some of frames transmitted in both the uplink direction and the downlink direction; -
FIG. 19 is a view showing a case wherein a timeout has occurred in Compressed Block Ack transmission in the uplink direction; -
FIG. 20 is a view showing another case wherein a timeout has occurred in Compressed Block Ack transmission in the uplink direction; -
FIG. 21 is a view showing a case wherein errors have occurred in all MPDUs aggregated and transmitted in the downlink direction from an HC; -
FIG. 22 is a view showing another case wherein errors have occurred in all MPDUs aggregated and transmitted in the downlink direction from an HC; -
FIG. 23 is a view showing a case wherein a Block Ack Request is contained in the last portion of a physical frame in which a plurality of data are aggregated; -
FIG. 24 is a view showing how frames are exchanged when piggybacking is performed by using the delayed Block Ack Policy; -
FIG. 25 is a view showing piggybacking operation applied to the delayed Block Ack technique; -
FIG. 26 is a view showing another example of piggybacking operation applied to the delayed Block Ack technique; -
FIG. 27 is a view showing a case wherein only a busy is detected in a delayed Block Ack sequence; -
FIG. 28 is a view showing a case wherein errors have occurred in some of data transmitted in the uplink direction; -
FIG. 29 is a view showing a case wherein errors have occurred in some of data transmitted in the downlink direction; -
FIG. 30 is a view showing a case wherein a timeout has occurred in the uplink direction; -
FIG. 31 is a view showing the format of an MRAD frame; -
FIG. 32 is a view showing an example of frame exchange in an immediate Block Ack sequence to a plurality of destinations; -
FIG. 33 is a view showing another example of frame exchange in an immediate Block Ack sequence to a plurality of destinations; -
FIG. 34 is a view showing still another example of frame exchange in an immediate Block Ack sequence to a plurality of destinations; -
FIG. 35 is a view for explaining aggregation to a plurality of destinations and reception buffer management; -
FIG. 36 is a view for explaining aggregation to a plurality of destinations and reception buffer management; and -
FIG. 37 is a view for explaining aggregation to a plurality of destinations and reception buffer management. -
FIG. 1 is a block diagram showing the arrangement of a communication apparatus according to the first embodiment of the present invention. Acommunication apparatus 1 is an apparatus configured to communicate with another communication apparatus through a wireless link, and includesprocessing units antenna 5 is connected to the physical layer processing unit (“processing unit” will be omitted hereinafter) 2. TheMAC layer 3 includes anaggregation processing device 6 for MAC frames. Theaggregation processing device 6 includes a carriersense control device 7 andretransmission control device 8, and performs transmission/reception of Block Ack (acknowledgement for a plurality of MAC frames) frames (to be described in detail later), retransmission control based on Block Ack frames, and the like. - The
physical layer 2 is designed to be compatible with two types of physical layer protocols. Theprocessing unit 2 includes a first-type physical layerprotocol processing device 9 and a second-type physical layerprotocol processing device 10 for the respective types of protocol processing. The first-type physical layerprotocol processing device 9 and second-type physical layerprotocol processing device 10 often share circuits and are not necessarily independent of each other in terms of implementation. - In this embodiment of the present invention, the first-type physical layer protocol is assumed to be a protocol defined in IEEE 802.11a, and the second-type physical layer protocol is assumed to be a protocol using a so-called MIMO (Multiple Input Multiple Output) technique using a plurality antennas on each of the transmitting side and the receiving side. Using the MIMO technique makes it possible to expect an increase in transmission capacity almost proportional to the number of antennas without changing the frequency band. The MIMO technique is therefore a technique directed to further increase the throughput of IEEE 802.11. Note that the
link layer 4 has a normal link layer function defined in IEEE 802. The technique to be used to increase the transmission rate is not limited to MIMO. For example, a method of increasing the occupied frequency band may be used or may be combined with MIMO. - According to IEEE 802.11e/Draft 8.0, as a technique of improving the transmission efficiency at the MAC (Media Access Control) layer, a Block Ack technique has been proposed. In the Block Ack technique, a given terminal transmits QoS (Quality of Service) data at minimum frame intervals called SIFS (Short Interframe Space) for a given channel use period (TXOP: Transmission Opportunity). Thereafter, the terminal transmits a Block Ack Request to the receiving terminal at an arbitrary timing to request its reception status. The receiving side converts the reception status into information in the bitmap format on the basis of the Starting Sequence Number (Block Ack Starting Sequence Control) determined by the Block Ack Request, and returns the information as a Block Ack.
- Prior to the detailed description of the embodiments of the present invention, existing techniques for Block Acks and buffer management on a receiving terminal of Block Acks will be described. According to IEEE 802.11e/Draft 10.0, a Block Ack technique is known as a technique of improving the transmission efficiency at the MAC (Media Access Control) layer. In the Block Ack technique, a given transmitting terminal transmits QoS (Quality of Service) data at minimum frame intervals called SIFS (Short Interframe Space) for a given channel use period (TXOP: Transmission Opportunity). Thereafter, the transmitting terminal transmits a Block Ack Request to the receiving terminal to request its reception status at an arbitrary timing. The receiving side converts the reception status into information in the bitmap format on the basis of the Starting Sequence Number (Block Ack Starting Sequence Control) determined by the Block Ack Request, and returns the information as a Block Ack.
-
FIGS. 2 and 3 respectively show the formats of a Block Ack Request frame and Block Ack frame which are defined in IEEE 802.11e/Draft 10.0. Both the frames shown inFIGS. 2 and 3 are MAC frames, each having the MAC header defined in IEEE 802.11. The MAC header is comprised of a Frame Control field, Duration field, Receiver Address field, and Transmitter Address field. - A BAR Control (Block Ack Request Control) 20 has a 4-bit TID (Traffic Identifier) field. QoS data exists for each priority (TID) and is assigned a unique sequence number and fragment number. For this reason, a reception status in the Block Ack in
FIG. 3 also needs to be prepared for each priority. The TID field of theBAR Control 20 in the Block Ack Request is used to designate such a priority. - A Block Ack Starting
Sequence Control 21 in the Block Ack Request inFIG. 2 is comprised of a 4-bit Fragment Number field and 12-bit Starting Sequence Number field. The Starting Sequence Number is used by a receiving terminal to generate a Block Ack Bitmap by tracing back a reception status, on the basis of a relative reception status from a sequence number corresponding to the Starting Sequence Number. - Like the
BAR Control 20 inFIG. 2 , aBA Control 30 in the Block Ack inFIG. 3 contains a 4-bit TID field. A Block Ack Starting Sequence Control (Block Ack Starting Sequence Number) 31 indicates the Starting Sequence Number of the reception status indicated by aBlock Ack Bitmap 32 in the Block Ack. According to IEEE 802.11e/Draft 10.0, the size of a Block Ack Bitmap is a fixed length of 1,024 bits, which makes it possible to notify a reception log corresponding to data of a maximum of 64 MSDUs (MAC Service Data Units). The process of partitioning a MSDU or MMPDU (MAC management protocol data unit) into smaller MAC level frames, MPDUs (MAC Protocol Data Units), is called fragmentation. One MSDU or MMPDU shall be divided into a maximum of 16 MPDUs with a Fragmentation Threshold. Note that an FCS (Frame Check Sequence) for error detection is added to each of the MAC frames shown inFIGS. 2 and 3 . -
FIGS. 4 and 5 each show an example of a Block Ack sequence in an HCCA (HCF Controlled Channel Access). The HC (Hybrid Coordinator) shown in each drawing is a QoS access point (QoS-AP) in IEEE 802.11e and serves as an entity which performs bandwidth management including the allocation of TXOPs to QSTAs (QoS stations) and performs downlink (the downlink direction from the HC to the QSTA) data transmission. The assignment of a TXOP to the QSTA is performed on the basis of a QoS CF-Poll frame (QoS Contention Free-Poll: a QoS-compatible polling frame which is transmitted from the HC to the QSTA to grant transmission opportunity). - Referring to
FIG. 4 , first of all, the HC assigns a channel use period (TXOP period 1) toQSTA 1 by transmitting a QoS CF-Poll frame 40 to it.QSTA 1 can transmit any frame inTXOP period 1. In the example shown inFIG. 4 ,QSTA 1 transmits QoS Data frames 41 at SIFS intervals in a burst manner, and then transmits a BlockAck Request frame 42 at the end of the transmission of the data frames. Thereafter,QSTA 1 receives aBlock Ack frame 43 fromQSTA 2. WhenTXOP period 1 assigned toQSTA 1 expires, the HC acquiresTXOP period 2. InTXOP period 2, the HC also transmitsQoS Data 44 toQSTA 1 in a burst manner. At the end ofTXOP period 2, as inTXOP period 1 assigned toQSTA 1, the HC transmits aBlock Ack Request 45, and receives aBlock Ack 46 fromQSTA 1. The Block Ack Requests 42 and 45 request the destination to return the relative reception status designated by a Block Ack Starting Sequence Control value.FIG. 4 shows an example of an immediate Block Ack sequence. In this case, the terminal which has received the Block Ack Requests 42 and 45 must return theBlock Acks -
FIG. 5 shows an example of a delayed Block Ack sequence. Upon receiving aBlock Ack Request 50, the terminal returns an Ack frame defined in IEEE 802.11 (called a Normal acknowledgement in IEEE 802.11e/Draft 10.0) 51, and transmits aBlock Ack 52 after a lapse of an arbitrary period. Upon receiving theBlock Ack 52 at last, the data transmitting terminal returns aNormal acknowledgement 53, thereby completing the delayed Block Ack sequence. Note that the receiving side is notified of QoS data subjected to the Block Ack technique by using an Ack Policy field in a QoS Control field of a MAC header extended for IEEE 802.11e. The Ack Policy field allows to designate the Normal ack scheme defined in IEEE 802.11, the Block Ack scheme defined in IEEE 802.11e, the No acknowledgement scheme which does not require ACK response, or the like. - Each embodiment of the present invention is directed to a communication apparatus designed to aggregate a plurality of MPDUs (MAC Protocol Data Units) in a PSDU (PHY Service Data Unit) to transmit a single PPDU (PHY Protocol Data Unit). Note that a PPDU corresponds to a physical frame (PHY frame) containing a PHY header, a PHY trailer and PSDU which contains plurality of MPDUs.
- In order to achieve a high throughput in a wireless LAN, the overhead of the MAC layer and the overhead of the PHY layer, such as a frame interval and random backoff period, must be reduced. As shown in
FIGS. 6 and 7 , these overheads can be reduced by transmitting a plurality of MPDUs upon aggregating them into one PSDU. In the example shown inFIG. 6 ,header information 61 which indicates in octets the length of each MPDU containing a MAC header to an FCS exists in the head of aPSDU 60 in which a plurality of MPDUs are aggregated. Theheader information 61 will be referred to as a “MAC super frame header” hereinafter. A CRC (Cyclic Redundancy Check) 62 for detecting an error in theheader 61 itself is added to the MACsuper frame header 61. “0” is written in an MPDU Length field corresponding to a portion in which no MPDU exists. In addition, if the CRC calculation for the MACsuper frame header 61 is incorrect, the reception of all the MPDUs is regarded as failed. - Referring to
FIG. 7 , in the front portion of each of the aggregated MPDUs, information indicating the length of a corresponding MPDU exists. In addition, a CRC for detecting an error in the MPDU length information is added to it. A combination of MPDU length information and a CRC will be referred to as an “MPDU separation”. Upon receiving a physical frame having the arrangement shown inFIG. 7 , a terminal checks the CRC of anMPDU separation 71. If thefirst MPDU separation 71 has been successfully received, the terminal extracts succeeding MPDU and calculates an FCS. If the FCS calculation result is correct, it is determined that the MPDU has been successfully received. If the FCS calculation result is incorrect, the reception of the MPDU is regarded as failed. The terminal then checks the CRC of anext MPDU separation 72 upon skipping a portion indicated by the MPDU length of theMPDU separation 71. If the MPDU separation is incorrect, the terminal consecutively skips and performs a CRC check on an octet basis. If the result is correct, the FCS for the MPDU following the MPDU separation is calculated to determine whether or not the MPDU has been successfully received. - Assume that, in each embodiment of the present invention, for a partial response to a physical frame in which a plurality of MPDUs are aggregated, an extended one of the Block Ack frame defined in IEEE 802.11e is used.
FIG. 8 shows the frame arrangement of an extended Block Ack. According to IEEE 802.11e/Draft 10.0, a Block Ack frame has a bitmap having a fixed length of 1,024 bits in consideration of fragmentation. Since the overhead of a fragment is generally large, in order to achieve a high throughput, it is preferable not to fragment an MSDU. The extended Block Ack frame shown inFIG. 8 therefore includes a CompressedBlock Ack Bitmap 80 corresponding to 64 MSDUs on the premise that no fragmentation is performed. 1 bit corresponds to the reception status of 1 MSDU. The size of the CompressedBlock Ack Bitmap 80 can be reduced to 1/16 that of a conventional Block Ack frame. A Block Ack frame with the CompressedBlock Ack Bitmap 80 will be referred to as a “Compressed Block Ack” hereinafter. Note that the CompressedBlock Ack Bitmap 80 of a Compressed Block Ack may have a variable length in accordance with the number of MPDUs aggregated into one physical frame. -
FIG. 9 shows an example of transmitting a plurality of MPDUs upon aggregating them. In each embodiment of the present invention, upon receiving a physical frame in which a plurality of MPDUs are aggregated, a terminal (STA and HC) returns a Compressed Block Ack to the transmission source after a lapse of a SIFS which is the minimum frame interval even if no Block Ack Request is contained in the physical frame. For example, first of all, the HC assignsTXOP period 1 toQSTA 1 by transmitting a QoS CF-Poll frame 90 toQSTA 1. InTXOP period 1,QSTA 1 transmits, toQSTA 2, aphysical frame 91 in which MPDUs with sequence numbers “1” to “3” are aggregated, andQSTA 2 returns the reception statuses of the MPDUs in aphysical frame 93 as aCompressed Block Ack 92 toQSTA 1 after a lapse of a SIFS. In the succeedingTXOP period 2, the HC transmits thephysical frame 93 toQSTA 1, andQSTA 1 returns the reception statuses of the MPDUs in thephysical frame 93 as aCompressed Block Ack 94 to the HC after a lapse of a SIFS. InTXOP period 3, the HC transmits a QoS CF-Poll frame 97 toQSTA 2 to assignTXOP period 3 toQSTA 2.QSTA 2 transmits aphysical frame 95 to the HC. The HC then returns the reception statuses of the MPDUs in thephysical frame 95 as aCompressed Block Ack 96 toQSTA 2 after a lapse of a SIFS. Each embodiment of the present invention allows a Compressed Block Ack to be returned even if no Block Ack Request is contained in a physical frame. This will be referred to as an “Implicit Block Ack Request” hereinafter. However, as in IEEE 802.11e/Draft 10.0, a Block Ack Request frame may be aggregated at the end of a physical frame, and the receiving side may return a Compressed Block Ack in accordance with the information indicated by the Block Ack Request frame. - The MAC efficiency can be improved by transmitting a plurality of MPDUs upon aggregating them, and performing selective repeat retransmission control using the above Compressed Block Ack (and Implicit Block Ack Request) technique.
- In the first embodiment of the present invention, the MAC efficiency is improved by aggregating a plurality of MPDUs and then piggybacking the MPDUs in the opposite direction on a partial response from a destination. Application methods for the immediate Block Ack and delayed Block Ack techniques defined in IEEE 802.11e/Draft 10.0 will also be described below.
- More specifically, a communication apparatus according to the first embodiment piggybacks at least one data frame on a Block Ack frame in immediate Block Ack transmission. For this purpose, the initiator side of data transmission transmits a transmission permission frame, which permits a destination terminal to piggyback a plurality of data frames, upon aggregating the control frame (Block Ack Request frame, or Block Ack frame) with a data frame. Such communication apparatus of the first embodiment searches a physical frame returned from a destination, when operating as a transmitting terminal. If Block Ack frame is not contained, the apparatus determines that a timeout has occurred. When a timeout associated with a Block Ack has occurred, the receiving side selects either the method of transmitting all the previously transmitted data frames as retransmission targets in the next piggyback allowable period or the method of piggybacking a Block Ack Request.
- The MAC efficiency can be improved by piggybacking a plurality of MPDUs in the opposite direction (from a destination to a transmission source) on a partial response frame from the destination. According to the IEEE 802.11e/Draft 10.0 standard, however, a destination terminal can only return a response frame to a data frame to a data transmitting terminal which has acquired a TXOP. Consider, therefore, a frame like the one having the arrangement shown in
FIG. 10 , which is used to give a transmission permission to the destination terminal to allow it perform piggyback transmission. - Assume that a data transmission source is regarded as an initiator terminal, and a
frame 100 inFIG. 10 will be called an “IAC (Initiator Aggregation Control) frame”. As shown inFIG. 10 , theIAC frame 100 has the same MAC header as that defined in IEEE 802.11, which is comprised of a Frame Control field, Duration field, Receiver Address field, and Transmitter Address field. - An
IAC Mask field 101 following the MAC header designates the application purpose (RTS, MIMO feedback, or piggyback transmission permission) of theIAC frame 100 with the bitmask format. A Next PPDU (PLCP Protocol Data Unit)Size 102 indicates, in octets, the length of following PPDU to be transmitted next by the transmission source. A Next PPDUDefault MCS field 103 represents a physical transmission rate in the transmission of following PPDU. A ReverseDirection Limit field 104, ReverseDirection Grant field 105, and Response Period Offset 106 are provided to assign the destination terminal a transmission permission time required for piggybacking. When the destination terminal is to be assigned a transmission time for piggybacking, the transmission source terminal extracts an arbitrary period of time from the currently held TXOP period. The transmission source is not permitted to extend the assigned TXOP period itself. An RDTID (Reverse Direction Traffic Identifier)field 107 designates a TID as a piggyback target. AnMCS Feedback field 108 is used to set a transmission rate in accordance with a propagation path environment (mainly used for link adaptation). A 4-octet FCS is added to the tail of theIAC frame 100 according to the IEEE 802.11 standard. -
FIG. 11 is a view showing how a plurality of MPDUs are aggregated and a piggyback permission is given to a destination terminal when an IAC frame is to be used. The example shown inFIG. 11 is a frame sequence in the case of HCCA. However, the present invention can also be applied to EDCA (Enhanced Distributed Channel Access) which is a contention-based QoS access control scheme. Referring toFIG. 11 , upon obtainingTXOP period 1, the HC transmits, toQSTA 1, aphysical frame 112 in which anIAC frame 110 and a plurality of data frames 111 with sequence numbers “1” to “14” are aggregated. Upon receiving thephysical frame 112,QSTA 1 returns aCompressed Block Ack 113 after a lapse of a SIFS period. Since piggyback transmission is permitted by theIAC frame 110,QSTA 1 transmits aphysical frame 115 in whichdata 114 in the uplink direction to the HC are aggregated. The number of MPDUs which can be piggybacked on a Compressed Block Ack to the HC byQSTA 1 is determined within the range of duration indicated by Reverse Direction Limit or Reverse Direction Grant given by the HC. Reverse Direction Limit or Reverse Direction Grant is adjusted within the range ofTXOP period 1 of the HC. WhenQSTA 1 transmits thephysical frame 115 in which the CompressedBlock Ack 113 and thedata 114 with sequence numbers “1” to “4” in the uplink direction are aggregated, the HC returns aCompressed Block Ack 116 toQSTA 1 after a lapse of a SIFS, thereby finishingTXOP period 1. InTXOP period 2, the HC transmits, toQSTA 2, aphysical frame 119 in which anIAC frame 117 anddata frames 118 with sequence numbers “1001” to “1004” are aggregated. IfQSTA 2 has no data in the uplink direction to the HC, i.e., data to be piggybacked,QSTA 2 returns only a CompressedBlock Ack 120 to the data from the HC regardless of whether Reverse Direction Grant (or Reverse Direction Limit) is given. Referring toFIG. 11 , the two TXOP periods are separated from each other by a PIFS (PCF Interframe Space). - According to the first embodiment, using an IAC frame makes it possible to intentionally permit a destination terminal to perform piggyback transmission. The MAC efficiency can be improved by causing a destination terminal which has obtained a piggyback transmission permission to perform piggyback transmission of data frames and the like.
- Several sequence examples in a case wherein errors have occurred in physical frames will be described below with reference to FIGS. 12 to 23.
-
FIGS. 12 and 13 each show a sequence example in a case wherein after the HC transmits, toQSTA 1, aphysical frame 123 in which anIAC frame 121 and a plurality of data frames 122 with sequence numbers “1” to “4” are aggregated, a busy 124 is detected by carrier sense within aSIFS plus 1 slot time, and the FCS calculation result indicates that all the MPDUs are incorrect. - According to the IEEE 802.11 standard, when power larger than a predetermined value is detected, a wireless channel is regarded as being used (busy). According to the IEEE 802.11e/Draft 10.0 standard, when the HC detects a busy a SIFS after transmitting a QoS CF-Poll frame at the time of channel access by HCCA, and the FCS calculation result indicates that a received frame is incorrect, the HC retransmits a QoS CF-Poll frame to acquire a TXOP period again, a PIFS after the channel is set in an idle state. When the HC detects a busy after transmitting a data frame, and the FCS check indicates an error, the HC retransmits the data frame after a lapse of a SIFS. In poll frame transmission, it is unknown whether or not a TXOP period has been properly acquired by destination terminal. In data frame transmission, the transmission source has already acquired a TXOP period, and hence can transmit (or retransmit) an arbitrary frame after a lapse of a SIFS.
- Assume that, in the case shown in
FIGS. 12 and 13 , a Compressed Block Ack (and piggybacked data) in the direction fromQSTA 1 to the HC is present, and the HC determines by FCS calculation that all the MPDUs are incorrect. In this case, in the HC, a timer which counts the duration until a Compressed Block Ack is received causes a timeout. The HC detects from this timeout that no Compressed Block Ack has been received, and transmits a (explicit) Block Ack Request a SIFS after the wireless channel becomes idle. The HC can transmit this Block Ack Request because it can be interpreted that the HC is on the initiator side of piggyback transmission, and has acquired a TXOP. As the Block Ack Starting Sequence Control value of the Block Ack Request, the sequence number “1” of the first transmitted MPDU is designated. In the example shown inFIG. 12 , when the HC transmits aBlock Ack Request 125, an IAC frame is not aggregated in the same physical frame. For this reason,QSTA 1 only returns an acknowledgement to the data previously received from the HC by using a CompressedBlock Ack 126. This is because since no IAC frame is present,QSTA 1 is not permitted to perform piggyback transmission. - When operating as a transmitting terminal, the communication apparatus according to the first embodiment determines, in accordance with the remaining period of the channel use period (i.e., the TXOP) assigned to the transmitting terminal, whether or not to transmit, to the destination terminal, a frame for permitting the terminal to return a partial response frame upon aggregating the frame and a plurality of MPDUs.
- As shown in
FIG. 12 , when the HC receives the CompressedBlock Ack 126 fromQSTA 1,TXOP period 1 of the HC expires, and thenext TXOP period 2 starts after a lapse of a PIFS time. InTXOP period 2, the HC transmits, toQSTA 2, aphysical frame 129 in which anIAC frame 127 anddata frames 128 with sequence numbers “1001” to “1004” are aggregated. - In contrast to this, in the example shown in
FIG. 13 ,TXOP period 1 held by the HC is sufficient, and hence permitsQSTA 1 to perform piggyback transmission, by transmitting aphysical frame 132 in which anIAC frame 130 andBlock Ack Request 131 are aggregated. Upon receiving thephysical frame 132,QSTA 1 is permitted by theIAC frame 130 to perform piggyback transmission, and can transmitdata frames 134 in the uplink direction to the HC by piggybacking them on a Compressed Block Ack (corresponding to the MPDUs with sequence numbers “1” to “4” which were transmitted first by the HC). The HC transmits aCompressed Block Ack 136 to thedata frame 134 fromQSTA 1 after a lapse of a SIFS, and then finishesTXOP period 1. - The HC can therefore selectively control permission/inhibition of piggybacking with respect to a destination terminal in accordance with the scheduling state on the side where a TXOP is acquired.
-
FIG. 14 shows an example of operation to be performed when errors have occurred in some of a plurality of aggregated MPDUs upon uplink transmission from a QSTA to the HC. First of all, the HC transmits anIAC frame 140 anddata frames 141 with sequence numbers “1” to “4” upon aggregating them into onephysical frame 142. After a lapse of a SIFS,QSTA 1 transmits a plurality of data in the uplink direction to the HC upon piggybacking them on aCompressed Block Ack 143 to the data frames 141 from the HC. In the example shown inFIG. 14 , an FCS calculation result indicates that errors have occurred in the Compressed Block Ack and anMPDU 144 with sequence number “4” fromQSTA 1. - In the first embodiment, even if it is detected that the channel is busy a SIFS after a plurality of MPDUs are aggregated and transmitted, the transmitted MPDUs are regarded as retransmission targets as long as there is no normal Compressed Block Ack in the physical frame which has caused the busy state. For this reason, it is necessary to prompt the retransmission of a Block Ack from the destination by transmitting a Block Ack Request in accordance with the IEEE 802.11e/Draft 10.0 standard.
- In the example shown in
FIG. 14 , the HC has not been able to receive a Compressed Block Ack to theMPDUs 141 with sequence numbers “1” to “4” which the HC has transmitted toQSTA 1. Within the range ofTXOP period 1, therefore, the HC aggregates (piggybacks) aBlock Ack Request 147 on aCompressed Block Ack 146 toQSTA 1, thereby requestingQSTA 1 to retransmit the Block Ack. In addition, the HC transmits anIAC frame 145 for giving transmission permission toQSTA 1 upon aggregating it in a singlephysical frame 148. After a lapse of a SIFS,QSTA 1 reflectively transmits the same contents as those of the previously transmitted Compressed Block Ack (without changing any of the contents), and piggybacks data in the uplink direction on the basis of the Reverse Direction Grant (or Reverse Direction Limit) information in the IAC frame. Referring toFIG. 14 ,QSTA 1 has detected by the CompressedBlock Ack 146 from the HC that the transmission of aMPDU 150 with sequence number “4” has failed, and hence piggybacks theMPDU 150 as a retransmission target on aCompressed Block Ack 149 to the HC. The HC then transmits aCompressed Block Ack 151 to theMPDU 150 with sequence number “4” retransmitted fromQSTA 1, thus finishingTXOP period 1. - If
TXOP period 1 acquired by the HC is short, and the HC does not have time enough to prompt frame transmission fromQSTA 1, the HC can finish the TXOP period by transmitting a Compressed Block Ack without aggregating a Block Ack Request nor an IAC. - In addition, the HC may detect the presence/absence of an acknowledgement frame on the basis of error detection at a specific frame position in a physical frame returned from a destination terminal. Assume that transmitting and receiving terminals have mutually recognized that a Compressed Block Ack is returned upon piggybacking of a plurality of data thereon, and the Compressed Block Ack is always aggregated in the head portion of a physical frame. In this case, if an FCS calculation result indicates an error in the first MPDU, the transmitting terminal can cause a timeout with respect to a partial response frame, i.e., can regard that the reception of a Compressed Block Ack has failed, without searching the remaining MPDUs.
- When an IAC frame is aggregated in the head of a physical frame from the HC in addition to a Compressed Block Ack as in the example shown in
FIG. 14 , an FCS up to the second MPDU is calculated to determine whether or not the Compressed Block Ack has successfully been received. Assume that an IAC frame is always aggregated in the head of a physical frame, and a Compressed Block Ack is aggregated at the first position in the remaining portion (i.e., next to the IAC frame in the same physical frame). In this case, if an FCS calculation result on the second MPDU indicates an error, the terminal which has received the physical frame regards that the reception of the Compressed Block Ack has failed. That is, if both the transmitting and receiving terminals recognize in advance the position where a Compressed Block Ack is to be aggregated, an FCS calculation result on the corresponding portion can be used as information for determining the success/failure of the reception of the Compressed Block Ack. -
FIGS. 15 and 16 each show an example of retransmission to be performed when errors have occurred in MPDUs in a physical frame in the downlink direction from an HC to a QSTA. Assume that the HC has transmitted an IAC frame and a plurality of MPDUs with sequence numbers “1” to “4” upon aggregating them, and errors have occurred inMPDUs QSTA 1 transmits data (with sequence numbers “1” to “4”) 155 in the uplink direction fromQSTA 1 to the HC upon piggybacking them on aCompressed Block Ack 154 indicating that the MPDUs with sequence numbers “1” and “4” are incorrect. When a SIFS has elapsed since the reception of the physical frame fromQSTA 1, the HC transmits aCompressed Block Ack 156 to the data in the uplink direction, thereby finishingTXOP period 1. If the HC detects by carrier sense during a PIFS that the wireless media is idle, the HC acquiresTXOP period 2, and transmits anIAC frame 157 anddata frames 158 with sequence numbers “1” and “4” as retransmission targets upon aggregating them. After a lapse of a SIFS,QSTA 1 transmits aCompressed Block Ack 159 indicating that the frames with sequence numbers “1” and “4” retransmitted by the HC have been successfully received.TXOP period 2 then expires. In this case, there is an IAC frame in the physical frame, but piggyback transmission for QSTA1 is not permitted. The HC acquiresTXOP period 3, during which the HC transmits data toQSTA 2, after carrier sense in a PIFS. IfTXOP period 1 assigned to the HC is sufficient as shown inFIG. 16 , the HC can transmit retransmission data frames 160 in the downlink direction from the HC toQSTA 1 and anIAC frame 161, together with the CompressedBlock Ack 156 toQSTA 1 to the HC, upon aggregating them. In this case, the MAC efficiency is higher than that in the example shown inFIG. 15 . -
FIGS. 17 and 18 each show an example of retransmission to be performed when error have occurred in MPDUs in both downlink and uplink physical frames. Referring toFIG. 17 , the HC transmits an IAC frame and data frames with sequence numbers “1” to “4” in the downlink direction toQSTA 1 upon aggregating them. Assume that the data frames with sequence numbers “1” and “4” are incorrect. In this case, after a lapse of a SIFS since the reception of the physical frame from the HC,QSTA 1 transmits data frames 171 with sequence numbers “1” and “4” in the uplink direction to the HC upon piggybacking them on aCompressed Block Ack 170 to the HC. Referring toFIG. 17 , an FCS calculation result indicates that errors have occurred in MPDUs of the MPDUs in the uplink direction to the HC which have sequence numbers “2” and “3”. -
TXOP period 1 inFIG. 17 is short, and hence the HC cannot afford to retransmit the incorrect MPDUs. Therefore, the HC finishes the TXOP by transmitting aCompressed Block Ack 172 to the data in the uplink direction fromQSTA 1. Referring toFIG. 17 , upon acquiring a TXOP period again (TXOP period 2) after a lapse of a PIFS, the HC transmits anIAC frame 173 andMPDUs 174 with sequence numbers “1” and “4” as retransmission targets toQSTA 1 upon aggregating them.QSTA 1 transmits an acknowledgement to the downlink data from the HC as aCompressed Block Ack 175 upon piggybacking retransmission MPDUs within the range of the transmission permission time given by theIAC frame 173. Referring toFIG. 17 ,QSTA 1 piggybacks a new MPDU with sequence number “5” on the CompressedBlock Ack 175 to the HC, in addition to the MPDUs with sequence numbers “2” and “3” as retransmission targets. Thereafter, the HC transmits aCompressed Block Ack 176 to the data fromQSTA 1, and finishesTXOP period 2. - In the example shown in
FIG. 18 ,TXOP period 1 held by the HC is relatively long, and hence the HC transmits anIAC frame 180, aCompressed Block Ack 181, anddata frames 182 with sequence numbers “1” and “4” which need to be retransmitted, upon aggregating them, after a lapse of a SIFS since the reception of the uplink data fromQSTA 1.QSTA 1 transmits the MPDUs with sequence numbers “2” and “31” which need to be retransmitted and anew MPDU 184 with sequence number “5” upon piggybacking them on aCompressed Block Ack 183 to the MPDUs with sequence numbers “1” and “4”. Lastly, the HC returns aCompressed Block Ack 185 toQSTA 1, and finishesTXOP period 1. In this case, if the error rate of the wireless media is high and retransmission is repeatedly executed in both the downlink and uplink directions, the fairness of data transmission may be impaired. Method of improving the retransmission quality may include setting the upper limit of the number of MPDUs which can be continuously transmitted to the total window size, setting an upper limit for the number of times of continuous transmission including retransmission, and adjusting the value of Reverse Direction Grant (or Reverse Direction Limit) of IAC. -
FIGS. 19 and 20 each show an example of retransmission to be performed when errors have occurred in all the data in the uplink direction from a QSTA to an HC. Referring toFIG. 19 , the HC transmits anIAC frame 190 anddata frames 191 with sequence numbers “1” and “2” upon aggregating them. After a lapse of a SIFS,QSTA 1 transmits data frames 193 with sequence numbers “1” and “2” in the uplink direction upon piggybacking them on aCompressed Block Ack 192 for notifying the successful reception of the MPDUs. At this time, if an FCS calculation result indicates that all the data in the uplink direction fromQSTA 1 to the HC are incorrect (sequence numbers “1” and “2” inFIG. 19 ), since the HC does not know the presence of the data fromQSTA 1, the HC finishesTXOP period 1 without generating any Compressed Block Ack. According to the IEEE 802.11e/Draft 10.0,QSTA 1 transmits data frames to the HC, and then sets a timer for the reception of a response frame. If a busy is detected within an (SIFS+1 slot) time after the transmission of the physical frame,QSTA 1 resets the timer, and performs FCS calculation for each received MAC frame. This slot time is used to tolerate a physical processing error, and varies depending on physical transmission specifications. In contrast, if no busy is detected even after a lapse of an (SIFS+1 slot) time since physical frame transmission, the transmitted data frames are regarded as recovery targets. Obviously, if an FCS calculation result on a MAC frame indicates that the frame is incorrect, the transmitted data frame is regarded as a retransmission target regardless of whether a busy is detected. Referring toFIG. 19 , the HC which holdsTXOP period 1 receives the CompressedBlock Ack 192 fromQSTA 1, and acquiresTXOP period 2 after a lapse of a PIFS. InTXOP period 2, the HC transmits anIAC frame 194 anddata frames 195 with sequence numbers “1001” and “1002” upon aggregating them. At the start ofTXOP period 2,QSTA 1 regards the MPDUs with sequence numbers “1” and “2”, which have been transmitted in the uplink direction, as recovery targets. InTXOP period 2 shown inFIG. 19 , since a response frame which becomes a factor for a busy state is not transmitted even after a lapse of an (SIFS+1 slot) time since the transmission ofdata frames 196 with sequence numbers “1” and ““2” in the uplink direction fromQSTA 2 to the HC, the data frames 196 are regarded as retransmission targets. The HC finishesTXOP period 2, and then acquiresTXOP period 3 after a lapse of a PIFS. InTXOP period 3, the HC transmits anIAC frame 197 anddata frames 198 with sequence numbers “3” and “4” toQSTA 1 upon aggregating them. TheIAC frame 197 allowsQSTA 1 to piggyback aBlock Ack Request 200 on aCompressed Block Ack 199 to the data frames with sequence numbers “3” and “4”. According to the IEEE 802.11e/Draft 10.0 standard, in performing immediate Block Ack transmission, when each QoS data with an Ack Policy Block Ack at SIFS intervals, and Block Ack frame can not be received from the destination even after a lapse of a predetermined period of time since the transmission of a Block Ack Request frame, a Block Ack Request is retransmitted. In the example shown inFIG. 19 , sinceQSTA 1 has received no Compressed Block Ack to the data transmitted in the uplink direction to the HC,QSTA 1 piggybacks the BlockAck Request frame 200 on the CompressedBlock Ack 199 to prompt the HC to transmit a Compressed Block Ack frame. After a lapse of a SIFS, the HC transmits, toQSTA 1, anIAC frame 201 and aCompressed Block Ack 202 to the BlockAck Request frame 200 upon aggregating them. Since the HC has not successfully received any MPDU of data fromQSTA 1 which is located after the Block Ack Starting Sequence Control value of the BlockAck Request frame 200, all the bits of the Compressed Block Ack Bitmap of the CompressedBlock Ack 202 are set to 0. When the HC transmits the IAC frame and Compressed Block Ack together,QSTA 1 recognizes the presence of the two MPDUs whose transmission has failed, and retransmits them to the HC. - As shown in
FIG. 20 , when a data frame transmitted fromQSTA 1 to the HC needs to be recovered,QSTA 1 may directly retransmit only the data frame in the next allocated transmission period instead of transmitting a Block Ack Request. According to the IEEE 802.11e/Draft 10.0 standard, since a delay allowable time (delay bound) is provided for QoS data, when it is known from the viewpoint of scheduling that QSTA1 cannot afford to retransmit a data frame upon reception of a Compressed Block Ack from the destination, as shown inFIG. 19 , adata frame 203 is directly retransmitted as shown inFIG. 20 . According to this embodiment, when data frames need to be recovered, selectively transmitting a Block Ack Request or directly retransmitting all the data frames can improve the MAC efficiency as well as meet QoS requirements. - In addition, this embodiment can be implemented not only by the method of performing recovery processing when an HC gives a piggyback permission to a QSTA as shown in
FIG. 19 but also by a method of performing recovery processing at the first of the acquisition of a TXOP in an EDCA period or at the beginning of the acquisition of a TXOP by a QoS CF-Poll from the HC. In the first embodiment of the present invention, the HC performs bandwidth management including the allocation of TXOPs to QSTAS. Obviously, however, the piggyback technique can also applied to a case whereinQSTA 1 is to completely acquire a TXOP and arbitrarily transmit an arbitrary MAC frame within the period. - In
TXOP period 3 inFIG. 19 , the HC aggregates, forQSTA 1, theIAC frame 201 with the CompressedBlock Ack 202. When the HC holds a TXOP, the HC also serves as an entity which performs scheduling for piggybacking. WhenQSTA 1 is preferably made to immediately retransmit a data frame from the viewpoint of a delay allowable time (delay bound), theIAC frame 201 is aggregated with the CompressedBlock Ack 202 as in the example shown inFIG. 19 . In the example shown inFIG. 19 , since all the bits of the Compressed Block Ack Bitmap of the CompressedBlock Ack 202 toQSTA 1 are 0, the HC recognizes thatQSTA 1 needs to perform retransmission processing. In this case, the HC also recognizes that the QSTA needs to perform retransmission, when bits representing a reception failure and reception success are alternately arranged in the Compressed Block Ack Bitmap of a Compressed Block Ack to a QSTA, or when the Block Ack Starting Sequence Control value of a Block Ack Request is different from that of a Compressed Block Ack (on the data transmitting side, all MPDUs with lower sequence numbers than the Block Ack Starting Sequence Control value of the Compressed Block Ack are regarded as those whose transmission has failed). In this case, the HC transmits an IAC frame for permitting a QSTA to perform piggybacking in accordance with the determination made by the scheduler device of the HC. Alternatively, since Reverse Direction Grant (or Reverse Direction Limit) designated by an IAC frame need not be completely consumed on the QSTA side, an IAC frame may be transmitted in advance to the QSTA to give it a margin for retransmission by piggybacking. -
FIGS. 21 and 22 each show an example of retransmission to be performed when errors have occurred in all the MPDUs aggregated and transmitted from an HC through a downlink. Referring toFIG. 21 , the HC transmits anIAC frame 210 anddata frames 211 with sequence numbers “1” to “4” toQSTA 1 upon aggregating them. Assume that errors have occurred in all the MPDUs including the IAC frame due to collision on a wireless channel or a high bit error rate. In this case,QSTA 1 cannot understand the MPDUs in the physical frame transmitted by the HC at all, and cannot determine whether or not the frame contains any MPDU addressed to itself. For this reason, even if the HC transmits an IAC frame,QSTA 1 transmits no data in the uplink direction. According to the IEEE 802.11e/Draft 10.0 standard, in performing channel access by HCCA, when no response is returned from a destination after an HC transmits the first frame (data or QoS CF-Poll) in a given TXOP period, the HC needs to transmit a frame again after performing carrier sense in a PIFS. In the example shown inFIG. 21 , therefore, the HC acquiresTXOP period 2 after a lapse of a PIFS, and transmits aBlock Ack Request 212 to make a QSTA set a NAV. In addition, in the example shown inFIG. 21 , anIAC frame 213 is aggregated with theBlock Ack Request 212. With this operation,QSTA 1 piggybacks a plurality ofdata 215 in the uplink direction to the HC on a CompressedBlock Ack frame 214 to the MPDUs with sequence numbers “1” to “4” whichQSTA 1 has failed to receive inTXOP period 1. Referring toFIG. 21 , the HC finishesTXOP period 2 by transmitting aCompressed Block Ack 216 toQSTA 1. Also, the Compressed Block Ack Bitmap of the CompressedBlock Ack frame 214 which is transmitted byQSTA 1 to the HC inTXOP period 2 is filled with 0s to express thatQSTA 1 has failed to receive all the MPDUs. Alternatively, as in the example shown inFIG. 22 , if all the data transmitted from the HC through the downlink are incorrect, only aBlock Ack Request 220 is transmitted after a lapse of a PIFS. Since theBlock Ack Request 220 has no IAC frame aggregated,QSTA 1 only transmits aCompressed Block Ack 221. The HC retransmits data frames 222 with sequence numbers “1” to “4” inTXOP period 3 acquired by the HC. That is, the retransmission timing of downlink data can be quickened as compared with the example shown inFIG. 21 . Therefore, the scheduling processing unit of the HC can improve the MAC efficiency by determining whether or not to transmit an IAC frame to the QSTA, in consideration of a delay allowable time (delay bound) and the like. - In the first embodiment of the present invention, upon receiving a physical frame in which a plurality of data are aggregated without any Block Ack Request, a terminal returns reception statuses of the MPDUs as a Compressed Block Ack after a lapse of a SIFS. The present invention can also be applied to even a case wherein a physical frame in which a plurality of data are aggregated contains a Block Ack Request at the end as shown in
FIG. 23 . Although the basic operation without using Implicit Block Ack Request likeFIG. 9 is the same as that in the case wherein a physical frame contains no Block Ack Request, a retransmission example in this case will be described with reference toFIG. 23 . - Referring to
FIG. 23 , upon acquiringTXOP period 1, the HC transmits anIAC frame 230, a plurality ofdata 231 with sequence numbers “1” to “4”, and a BlockAck Request frame 232 with a Block Ack Starting Sequence Control value of “1” upon aggregating them. Assume that at this point of time,QSTA 1 has not successfully received thedata 231 with sequence numbers “1” and “4” and the BlockAck Request frame 232. SinceQSTA 1 has not received any Block Ack Request from the HC,QSTA 1 cannot transmit any Compressed Block Ack. However,QSTA 1 stores in advance reception information such as the Block Ack Starting Sequence Control value “2” and the Compressed Block Ack Bitmap “110 . . . ” as the reception status of one physical frame in the past. InTXOP period 1,QSTA 1 transmits data frames 233 with sequence numbers “1” to “3” and a Block Ack Request 234 with a Block Ack Starting Sequence Control value of “1” upon aggregating them. In this case, if the HC does not successfully receive the Block Ack Request 234, the HC returns no Compressed Block Ack. If the data frame transmitting side detects a busy within an (SIFS+1 slot) time, but there is no Compressed Block Ack frame addressed to itself in the received physical frame, the transmitted frames are regarded as retransmission targets. The HC transmits anIAC frame 235 and a BlockAck Request frame 236 for promptingQSTA 1 to retransmit the Compressed Block Ack upon aggregating them.QSTA 1 transmits a BlockAck Request frame 238 to the HC upon piggybacking it on aCompressed Block Ack 237 indicating that the MPDUs with sequence numbers “1” and “4” are incorrect. The HC then transmits anIAC frame 239, aCompressed Block Ack 240 to the Block Ack Request fromQSTA 1,MPDUs 241 with sequence numbers “1” and “4” for retransmission, and a BlockAck Request frame 242 upon aggregating them. At the end ofTXOP period 1,QSTA 1 transmits aCompressed Block Ack 243 as an acknowledgement. If piggybacking is permitted by an IAC frame and data to be transmitted to the HC exists in a transmission queue, the data is also transmitted together. As described above, whether or not to permitQSTA 1 to perform piggybacking is determined in accordance with determination made by the scheduling processing device of the HC. - According to the first embodiment of the present invention, the MAC efficiency can be improved by transmitting a plurality of MPDUs upon aggregating them and transmitting data in the opposite direction upon piggybacking it on a partial response frame from the destination. This embodiment has been described mainly on the basis of HCCA which is a contention-free QoS access control scheme. Obviously, however, the present invention can also be applied to contention-based EDCA. In the case of EDCA, a terminal which has acquired a TXOP serves as an entity of scheduling and adjusts the amount of frames piggybacked and transmitted from a destination terminal by using an IAC frame. In the case of HCCA as well, a QSTA which has acquired a TXOP upon receiving a QoS CF-Poll frame from an HC permits a destination terminal to perform piggyback transmission by suing an IAC frame. These scheduling operations depend on the delay allowable time (delay bound) and the like represented by QoS data.
- The second embodiment of the present invention is directed to delayed Block Ack transmission, in which a Normal acknowledgement frame for allowing the transmission of a Block Ack to be postponed is replaced with the IAC frame described in the first embodiment. More specifically, a communication apparatus according to the second embodiment of the present invention transmits a plurality of data frames and then uses an IAC frame from a destination terminal to another destination in place of a Normal acknowledgement to a delayed Block Ack. After a lapse of a predetermined period of time, the destination terminal transmits the Block Ack frame and a plurality of data upon aggregating them.
- According to IEEE 802.11e/Draft 10.0, if it is difficult to return a Block Ack frame a SIFS after the reception of a Block Ack Request frame, a delayed Block Ack like the one shown in
FIG. 5 can be used. According to the delayed Block Ack technique, first of all, an Ack response (Normal acknowledgement) to a Block Ack Request is returned. After a lapse of an arbitrary period of time, a Block Ack frame is transmitted, and an Ack response (Normal acknowledgement) to the frame is returned. In the delayed Block Ack technique, if Normal acknowledgement frame can not be received after a lapse of a predetermined period of time since the transmission of a Block Ack Request or Block Ack, the transmission of the corresponding frames is regarded as failed. The second embodiment of the present invention is directed to piggyback transmission using the delayed Block Ack technique. -
FIG. 24 shows how frames are exchanged when piggybacking described in the second embodiment of the present invention is performed by using the conventional delayed Block Ack Policy defined in IEEE 802.11e. Referring toFIG. 24 , upon acquiringTXOP period 1, the HC transmits anIAC frame 244 anddata frames 245 with sequence numbers “1” and “2” upon aggregating them.QSTA 1 transmitsdata 247 in the uplink direction upon piggybacking it on aCompressed Block Ack 246 to the data frames 245 from the HC within the period assigned by theIAC frame 244. In this case, when the delayed Block Ack Policy is to be used for a response from the HC, the HC transmits aNormal acknowledgement frame 248 defined in IEEE 802.11 to notify the reception of the delayed Block Ack procedure. When theQSTA 1 cannot successfully receive a Normal acknowledgement frame due to an error,QSTA 1 regards the data frame (or a Block Ack Request frame) as a retransmission target. InTXOP period 2 inFIG. 24 , as in the case ofTXOP period 1, when the delayed policy is used for a Compressed Block Ack from the HC toQSTA 2, the TXOP expires after aNormal acknowledgement 249 is transmitted toQSTA 2. InTXOP period 3, the HC transmits, toQSTA 1, adata frame 250 with sequence number “3” in the downlink direction and aCompressed Block Ack 251 with a Block Ack Starting Sequence Control value of “1” whose transmission is delayed inTXOP period 1 upon aggregating them, andQSTA 1 transmits aNormal acknowledgement frame 252, thereby completing one delayed Block Ack sequence. InTXOP period 3 inFIG. 24 , aCompressed Block Ack 253 with a Block Ack Starting Sequence Control value of “3” to the downlink data from the HC is piggybacked on theNormal acknowledgement frame 252. When piggybacking is to be performed by using the delayed Block Ack technique in the above manner, the MAC efficiency inevitably decreases due to the use of the Ack frame defined in IEEE 802.11. The second embodiment of the present invention therefore realizes a mechanism for solving such a problem. Although a case wherein the delayed Block Ack Policy is mainly applied to the transmission of a Compressed Block Ack from an HC to a QSTA will be mainly described, it is obvious that the present invention can be applied to both uplink transmission and downlink transmission. -
FIGS. 25 and 26 each show a basic embodiment of the present invention concerning its application to the delayed Block Ack technique. Referring toFIG. 25 , when the transmission of a Compressed Block Ack to data in the uplink direction fromQSTA 1 is to be delayed, the Normal acknowledgement frame defined in IEEE 802.11 is transmitted in a normal state. Instead of this operation, however, an IAC frame to another destination is transmitted after a lapse of a SIFS. An IAC frame can be used for various applications by setting 1 in each bit of the IAC Mask field shown inFIG. 10 . In this case, in order to indicate that the transmission of a delayed Block Ack is allowed, a 1-bit identification flag is prepared in the IAC Mask field. - When the HC transmits, to
QSTA 2, data frames 255 with sequence numbers “1001” and “1002”, the destination MAC address of anIAC frame 254 to be simultaneously aggregated has been set toQSTA 2. In the second embodiment of the present invention, when performing transmission toQSTA 2, the HC sets an extended flag in the IAC Mask field of an IAC frame to 1, which indicates that a delayed Block Ack has been accepted (to which negative logic can be obviously applied).QSTA 1 recognizes in advance that the delayed Block Ack Policy is applied to a Compressed Block Ack returned from the HC. Assume thatQSTA 1 detects a busy state in the wireless channel within an (SIFS+1 slot) time after the transmission of data in the uplink direction to the HC. In this case, ifQSTA 1 has successfully received the IAC frame aggregated in the physical frame, and the flag in the IAC Mask field in the IAC frame, which indicates that a delayed Block Ack is accepted, is set to 1 (0 in the case of negative logic),QSTA 1 recognizes that the transmission of the delayed Block Ack is accepted on the destination side. - In this case, the HC in
FIG. 25 transmits data to QSTA 2 a SIFS after the reception of a physical frame fromQSTA 1. According to the IEEE 802.11e/Draft 10.0 standard, if no busy state is detected in a wireless channel within an (SIFS+1 slot) time after the transmission of a Block Ack Request or data, the transmitted frame is regarded as a retransmission target. Therefore, a frame by which the HC notifies the QSTA of the acceptance of a delayed Block Ack needs to be transmitted after a lapse of a SIFS. Upon detecting a busy a SIFS after the transmission of the frame to the HC,QSTA 1 resets the timer. Even if the destination of an IAC frame in a physical frame which causes a busy state is other thanQSTA 1, when the flag in the IAC Mask is set to 1,QSTA 1 confirms that a Compressed Block Ack is returned, according to the delayed Block Ack Policy. If the flag in the IAC Mask remains 0 (1 in the case of negative logic), it is determined that the establishment of a delayed Block Ack sequence has failed. So, the QSTA should retransmit the data or Block Ack Request frame. - Referring to
FIG. 25 , the HC transmitsdata 256 with sequence number “3”, anIAC frame 257 toQSTA 1, and aCompressed Block Ack 258 with a Block Ack Starting Sequence Control value of “1” toQSTA 1 upon aggregating them a SIFS after the reception of a frame in the uplink direction fromQSTA 2. The CompressedBlock Ack 258 is an acknowledgement frame to MPDUs with sequence numbers “1” and “2” transmitted first byQSTA 1. Although the destination of theIAC frame 257 isQSTA 1, setting a flag in the IAC Mask notifies that delayed Block Ack transmission of data in the uplink direction fromQSTA 2 is accepted. According to the IEEE 802.11e/Draft 10.0 standard, although it is necessary to return a Normal acknowledgement to a Block Ack frame, in the second embodiment of the present invention, when a Normal acknowledgement frame and a Compressed Block Ack to data in the downlink direction from an HC are to be aggregated, transmitting the Compressed Block Ack also serves as transmitting the Ack frame defined in IEEE 802.11. That is, when the HC transmits data with sequence number “3” and a Compressed Block Ack based on the delayed policy, and the destination (QSTA 1 in the example shown inFIG. 25 ) then returns a Compressed Block Ack according to the immediate policy, it is regarded that a Normal acknowledgement frame to the Block Ack is received as defined in IEEE 802.11e/Draft 10.0. - As shown in
FIG. 25 , if there is data to be transmitted to another destination, an IAC frame is also aggregated, and it is notified by using the frame that the delayed Block Ack technique is accepted. When there is no downlink data as in the example shown inFIG. 26 , the Normal acknowledgement frame defined in IEEE 802.11 is transmitted to finish the TXOP period. In the example shown inFIG. 26 , after aframe 260 fromQSTA 2 is received, since there is no data to be transmitted after a lapse of a SIFS, the HC transmits aNormal acknowledgement frame 261 toQSTA 2 to notify that the delayed Block Ack is accepted. WhenTXOP period 1 expires andTXOP period 2 starts, the HC transmits aCompressed Block Ack 262 based on the delayed policy and adownlink data 263 toQSTA 1 upon aggregating. As shown inFIG. 25 , a Compressed Block Ack fromQSTA 1 also serves as a Normal acknowledgement (an Ack to a Block Ack). In the second embodiment of the present invention, when there are data to be transmitted at SIFS intervals in a predetermined TXOP period, an IAC frame to another destination is regarded as an Ack response to a delayed Block Ack. Therefore, when an IAC frame is used as a Normal acknowledgement in the delayed Block Ack technique as shown inFIGS. 25 and 26 , the MAC efficiency can be improved as compared with a case wherein the conventional delayed Block Ack Policy defined in IEEE 802.11e/Draft 10.0 is used. - FIGS. 27 to 30 each show how frames are exchanged in the execution of retransmission due to errors. The basic operation in this case is the same as that in the first embodiment of the present invention. First of all, as shown in
FIG. 27 , the HC transmitsdownlink data 271 with sequence numbers “1” and “2” toQSTA 1. In this case, if an error has occurred in a response frame transmitted byQSTA 1 after a lapse of a SIFS, the HC detects only a busy 272. After a lapse of a SIFS, the HC transmits a BlockAck Request frame 274 andIAC frame 273 toQSTA 1 upon aggregating them. When the immediate Block Ack Policy is applied to a Compressed Block Ack fromQSTA 1 to the HC,QSTA 1 transmits a Compressed Block Ack 275 a SIFS after the reception of the BlockAck Request frame 274 from the HC. In the example shown inFIG. 27 ,QSTA 1 transmits the CompressedBlock Ack 275 with a Block Ack Starting Sequence Control value of “1” anddata 276 in the uplink direction to the HC upon piggybacking them. Assuming that the delayed policy is applied to a Compressed Block Ack from the HC to the QSTA, the HC uses anIAC frame 277 addressed toQSTA 2 to notify that the application of the delayed Block Ack Policy is accepted, as in the example shown inFIG. 25 . Assume that when the frame transmission in the uplink direction fromQSTA 2 to the HC ends, the remainder ofTXOP period 1 held by the HC is small, and the HC transmits a Compressed Block Ack based on the delayed policy toQSTA 1 from the viewpoint of scheduling. Since there is a delayed Compressed Block Ack in the physical frame received from the HC,QSTA 1 completes the delayed Block Ack sequence by returning the Normal acknowledgement frame defined in IEEE 802.11. At this time, in the second embodiment of the present invention, as in the example shown inFIG. 25 , if the HC has transmitted downlink data in response to a delayed Compressed Block Ack, and the immediate policy is applied to a Compressed Block Ack fromQSTA 1 to the HC, transmitting only the Compressed Block Ack can also serve as transmitting the Normal acknowledgement defined in IEEE 802.11, as described above. In the example shown inFIG. 27 , since the physical frame transmitted by the HC at the end ofTXOP period 1 contains no aggregated data,QSTA 1 completes the delayed Block Ack sequence by transmitting aNormal acknowledgement 278. -
FIG. 28 shows an example of operation to be performed when errors have occurred in some of the MPDUs in the uplink direction from a QSTA to an HC. In the example shown inFIG. 28 , errors have occurred in a CompressedBlock Ack 280 fromQSTA 1 to the HC anddata 281 with sequence number “2” in the uplink direction. The HC cannot receive any Compressed Block Ack fromQSTA 1. The HC therefore transmits aBlock Ack Request 282. AnIAC frame 283 is aggregated in theBlock Ack Request 282 transmitted by the HC. The destination of theIAC frame 283 isQSTA 1, and 1 (0 in the case of negative logic) is set in the flag in the IAC Mask field. Upon receiving theIAC frame 283,QSTA 1 confirms that the delayed policy is properly applied to data with sequence numbers “1” and “2” transmitted by itself.QSTA 1 then retransmits the CompressedBlock Ack 283 with a Block Ack Starting Sequence Control value of “1”. After a lapse of a SIFS, the HC transmits anIAC frame 284 anddata 285 with sequence numbers “1001” and “1002” toQSTA 2 upon aggregating them. At this time, the value of the flag in the IAC Mask field of theIAC frame 284 is kept at 0 which is the initial value (1 in the case of negative logic). This is because the notification of the acceptance of the delayed Block Ack Policy for data fromQSTA 1 has already been completed. AfterQSTA 2 transmits data to the HC, the HC transmits downlink data (sequence number “3”) 286 and aCompressed Block Ack 287 based on the delayed policy with a Block Ack Starting Sequence Control value of “1” toQSTA 1.QSTA 1 makes aCompressed Block Ack 288 to sequence number “3” from the HC also serve as a Normal acknowledgement frame to the Block Ack. In addition, when piggybacking is permitted by an IAC frame,QSTA 1 retransmitsdata frame 289 with sequence number “2”, whose transmission has failed, upon piggybacking. -
FIG. 29 shows an example of retransmission to be performed when errors have occurred in some of MPDUs aggregated in a physical frame in the downlink direction. In the example shown inFIG. 29 , since the immediate policy is applied to Compressed Block Ack transmission from a QSTA to an HC,QSTA 1 returns aCompressed Block Ack 290 to indicate that an error has occurred in an MPDU with sequence number “1” from the HC, and the HC retransmits anMPDU 291 with sequence number “1”. InTXOP period 2, the HC transmits data frames 292 with sequence numbers “1001” and “1002” and anIAC frame 293 toQSTA 2 upon aggregating them.QSTA 2 transmits, to the HC, aCompressed Block Ack 294 based on the immediate policy anddata 295 in the uplink direction upon piggybacking them. In transmitting data to QSTA 1 a SIFS after the reception of the frame fromQSTA 2, the HC sets 1 in the flag in the IAC Mask field of anIAC frame 297 aggregated with the data. When the flag in theIAC frame 297 addressed toQSTA 1 is set to 1,QSTA 2 confirms that the delayed policy is applied to a partial response from the HC to the uplink data transmitted byQSTA 2. -
FIG. 30 shows a case wherein errors have occurred in all data in the uplink direction from a QSTA to an HC, and the HC cannot return a Compressed Block Ack. Referring toFIG. 30 , sinceQSTA 1 is permitted by an IAC frame from the HC to perform piggyback transmission,QSTA 1 piggybacks data (sequence numbers “1” and “2”) 300 in the uplink direction on aCompressed Block Ack 301. At this time, if an FCS calculation result indicates that all the data frames transmitted fromQSTA 1 are incorrect, the HC does not return Compressed Block Ack. The HC then performs downlink transmission toQSTA 2 within the range ofTXOP period 1. In this case, the flag in the IAC Mask field of anIAC frame 302 toQSTA 2 remains the initial value “0” (“1” in the case of negative logic).QSTA 1 is monitoring the physical frame transmitted from the HC, and checks the flag in theIAC frame 302. However, since the value remains 0,QSTA 1 determines that the application of the delayed policy to the Compressed Block Ack has failed, and regards the transmitted data frames 300 as retransmission targets. When the HC transmitsdata 303 with sequence number “3” and anIAC frame 304 toQSTA 1 upon aggregating them afterward,QSTA 1 piggybacks aBlock Ack Request 306 on a Compressed Block Ack (Block Ack Starting Sequence Control value of “3”) 305 to thedata 303 from the HC. Alternatively, as in the first embodiment,QSTA 1 may directly aggregate the data with sequence numbers “1” and “2” as retransmission targets. The scheduling processing device ofQSTA 1 selects whether to piggyback theBlock Ack Request 306 or directly aggregate the frames as retransmission targets. Assume that after a lapse of a SIFS since the reception of a frame fromQSTA 1, the HC is to transmit data to another QSTA. In this case, the HC sets 1 (0 in the case of negative logic) in the flag in the IAC Mask field of an IAC frame. This makesQSTA 1 recognize that Compressed Block Ack return based on the delayed policy is applied, on the HC side, to the Block Ack Request (or data) transmitted by itself. - As described above, according to the second embodiment of the present invention, the MAC efficiency can be improved by efficiently applying the piggyback technique to the delayed Block Ack technique. Note that in the second embodiment, the delayed policy is applied to a Compressed Block Ack from an HC to a QSTA (i.e., uplink data from a QSTA), and the immediate policy is applied to a Compressed Block Ack from a QSTA to an HC (i.e., downlink data to a QSTA). Obviously, however, the present invention allows the delayed policy to be applied to Compressed Block Acks in both the uplink and downlink directions.
- In addition, as in the first embodiment, the present invention can be applied to a method in which, upon acquiring a TXOP by EDCA, a terminal having an access right plays a leading role in executing the delayed Block Ack technique using an IAC frame. Furthermore, the present invention can be applied to a case wherein a Block Ack Request is to be aggregated with the end of a physical frame (explicit Block Ack Request), as in the first embodiment. In this case, if an FCS calculation result indicates that the Block Ack Request is incorrect, the data receiving side does not transmit Compressed Block Ack. Thereafter, the data transmitting terminal requests the receiving side to retransmit a Compressed Block Ack, by, for example, retransmitting a Block Ack Request frame.
- The third embodiment of the present invention is directed to the application of the immediate Block Ack technique and delayed Block Ack technique in a case wherein a plurality of MPDUs are aggregated and transmitted to a plurality of destinations. When only MAC frames addressed to the same destination are to be aggregated and transmitted, overheads like IFS (Interframe Space) and random backoff occur every time the destination changes. In contrast to this, aggregating MAC frames addressed to a plurality of different destinations into one physical frame makes it possible to reduce these overheads and improve the MAC efficiency.
-
FIG. 31 shows an example of a MAC frame containing information associated with a plurality of destinations. Aggregating aMAC frame 310 like this frame in the head of a physical frame allows a physical frame receiving terminal to immediately determine whether or not there is any MPDU addressed to itself exists. TheMAC frame 310 like the one shown inFIG. 31 will be referred to as an “MRAD (Multiple Receiver Aggregation Descriptor) frame” hereinafter. As shown inFIG. 31 , theMAC frame 310 has aconventional MAC header 311 defined in IEEE 802.11 which includes “Frame control”, “Duration”, “Receiver Address”, “Transmitter Address”, and the like. TheMAC frame 310 includes a Number ofreceivers field 312 indicating the number of destinations of MPDUs aggregated in the physical frame, a ReceiverAddress Info field 313 indicating destination MAC address information, andLength field 314 for designating, in octets, an information size to be occupied for each destination. The example shown inFIG. 31 exemplifies information up to “Receiver Address Info 3”. However, the number of pieces of information is not limited to this, and an arbitrary variable length can be set. That is, the number of destinations is arbitrarily set. -
FIG. 32 shows an example of frames which are exchanged when the immediate Block Ack Policy is applied. Upon acquiring a TXOP, the HC transmits anMRAD frame 320, anIAC 321 and data frames (sequence numbers “1” and “2”) 322 toQSTA 1, and anIAC 323 and data frames (sequence numbers “1001” and “1002”) 324 upon aggregating them into onephysical frame 325. Using the information of theMRAD frame 320 allows terminals other than QSTAs 1 and 2 to freely perform processing such as shifting to the power saving mode. Offset times from the end of the transmission of a physical frame from the HC are written in the IAC frames 321 and 323 addressed to QSTAs 1 and 2 to designate the timings at which QSTAs 1 and 2 respond. As this offset time, the Response Period Offset field in the example shown inFIG. 10 is used. WhenQSTA 1 successfully receives an IAC frame addressed to itself, it aggregatesuplink data 327 with aCompressed Block Ack 326 to the HC within the range of piggyback transmission allowable time, and transmits the resultant data, as shown inFIG. 32 . Likewise, following the frame transmission byQSTA 1,QSTA 2 transmits CompressedBlock Ack 328 anduplink data 329 to the HC upon aggregating them. At this time, the example inFIG. 32 shows that alldata frames 329 transmitted byQSTA 2 are incorrect. When the immediate Block Ack Policy is applied, the HC transmits anMRAD frame 330 and anIAC 331 and CompressedBlock Ack frame 332 toQSTA 1 upon aggregating them a SIFS after the end of frame transmission byQSTA 2. Since all the data fromQSTA 2 are incorrect, the Compressed Block Ack frame from the HC toQSTA 2 is not aggregated. In this case, if the HC does not permitQSTA 2 to perform frame transmission in the opposite direction (uplink), the Receiver Address Info field of theMRAD frame 330 does not contain the MAC address ofQSTA 2. The Number of receivers field is 1, and only the MAC address ofQSTA 1 and length information are written. If the HC is to permitQSTA 2 to perform transmission, it aggregates an IAC frame addressed toQSTA 2, sets “Number of receivers” to 2, and adds the MAC address ofQSTA 2. - In the third embodiment of the present invention, when the HC transmits a physical frame within
TXOP period 1, QSTAs 1 and 2 check the Receiver Address Info field in the MRAD frame aggregated in the physical frame from the HC. If each QSTA detects no MAC address of its own, the QSTA regards the transmitted frame as a recovery target. In the example shown inFIG. 32 ,QSTA 2 determines that it has failed to receive an immediate type Compressed Block Ack to transmitted data with sequence numbers “1” and “2”, and performs appropriate recovery operation. -
FIGS. 33 and 34 each show an application example of the delayed Block Ack Policy. Referring toFIG. 33 , the HC transmits anIAC 331 and data frame (sequence number “1”) 332 toQSTA 1, and anIAC 333 and data frame (sequence number “1001”) 334 toQSTA 2 upon aggregating them into one physical frame 335. QSTAs 1 and 2 recognize the timings of transmission to uplinks on the basis of the respective pieces of IAC frame information, respectivelypiggyback uplink data Block Acks - When the delayed policy is used, there is no need to transmit a Compressed Block Ack immediately after transmission by a QSTA. Instead, as in the second embodiment, the HC can regard a frame for giving a permission to perform transmission in the opposite direction (permits a terminal having no TXOP to perform transmission) as a Normal acknowledgement frame to a Block Ack Request frame by delayed Block Ack transmission defined in IEEE 802.11e/Draft 10.0. In this case, the HC aggregates an
IAC frame 340 toQSTA 1,QSTA 2, andQSTA 3 and data (sequence number “2001”) 341 in the downlink direction toQSTA 3 and transmits the resultant data. Both Reverse Direction Grant and Response Period Offset of the IAC frame to each of QSTAs 1 and 2 are set to 0. That is, the HC does not permit QSTAs 1 and 2 to perform transmission in the uplink direction. A flag indicating the acceptance of the delayed Block Ack technique is set ON. Upon receiving this physical frame, each of QSTAs 1 and 2 confirms that the delayed Block Ack Policy is applied to the data transmitted by itself. Thereafter,QSTA 3 transmits aCompressed Block Ack 342 to the data (sequence number “2001”) from the HC anddata 343 in the uplink direction upon aggregating them. Referring toFIG. 33 , the HC transmits IAC frames 344 to QSTAs 1, 2, and 3 and CompressedBlock Acks 345 to QSTAs 1 and 2. The CompressedBlock Ack 345 is a Block Ack based on the delayed policy to data in the uplink direction from QSTAs 1 and 2. In this case, values are set in Reverse Direction Grant and Response Period Offset of theIAC frame 344 to each of QSTAs 1 and 2 to allow each QSTA to transmit at least the Normal acknowledgement frame defined in IEEE 802.11. In addition, a flag is set in the IAC Mask field ofQSTA 3 to notify the acceptance of the delayed Block Ack technique. As shown inFIG. 34 , when the remainder of TXOP period held by the HC becomes small, the HC transmits Normal acknowledgement frames 346 defined in IEEE 802.11 which are prepared for the respective destinations and aggregated. That is, an aggregation of Normal acknowledgements is performed for a plurality of destinations. - Buffer management on the receiving side in a case wherein data addressed to a plurality of destinations are aggregated will be described with reference to
FIGS. 35 and 36 . Consider a case wherein anMRAD frame 350, anIAC 351 toQSTA 1, data frames 352 and 353 with sequence numbers “1” and “2”, anIAC 354 toQSTA 2, anddata frames FIG. 6 may be used to aggregate a plurality of frames. - Assume that, as shown in
FIG. 36 , an FCS calculation result indicates that an error has occurred in theMPDU 352 with sequence number “1”. By using the offset value designated by theIAC 351,QSTA 1 transmits aCompressed Block Ack 360 with a Block Ack Starting Sequence Control value of “2”, andQSTA 2 transmits aCompressed Block Ack 361 with a Block Ack Starting Sequence Control value of “1001”. For aggregated data containing no Block Ack Request (implicit Block Ack Request), the sequence number of the first MPDU which has been successfully received is used as the Block Ack Starting Sequence Control value of the Compressed Block Ack. Referring toFIG. 36 , assume that MPDUs with sequence numbers “0” and “4095” have already been stored in areception buffer 362 ofQSTA 1, and MPDUs with sequence numbers “999” and “1000” have already been stored in areception buffer 363 ofQSTA 2. In the third embodiment of the present invention, when an FCS calculation result on an IAC frame is correct, and an FCS calculation result on a data frame following it is correct, the sequence number of the data frame is regarded as proper sequence number information for reception buffer management. In the example shown inFIG. 36 ,QSTA 1 transmits a Compressed Block Ack to the HC, but keeps the MAC frame stored in thereception buffer 362. On the other hand,QSTA 2 has successfully received all frames, and hence performs reception buffer management by setting the sequence number “1001” as a proper Block Ack Starting Sequence Control value. According to the IEEE 802.11e/Draft 10.0 standard, all MAC frames having lower sequence numbers than the Block Ack Starting Sequence Control value must be released from the reception buffer and forwarded to the upper layer. For this reason,QSTA 2 inFIG. 36 releases MAC frames with sequence numbers “999” to “1002” from thereception buffer 363 and forwards them to the upper layer. - As shown in
FIG. 37 , a format containing no IAC frame can also be used. In the example shown inFIG. 37 , an FCS calculation result indicates that an error has occurred in the data with sequence number “2” toQSTA 2. In this case, even if an FCS calculation result on the data frame with sequence number “1001” toQSTA 2 is correct, it cannot be determined up to which MPDUs toQSTA 1 are aggregated. For this reason, even if a Compressed Block Ack is returned, no MAC frame can be released from the reception buffer. That is, in the third embodiment of the present invention, if FCS calculation results on two consecutive MPDUs having different destination addresses are successful, reception buffer management is performed by determining the sequence number of the second MPDU (i.e., the MPDU having the new destination) as a proper Block Ack Starting Sequence Control value for the next destination. - According to the IEEE 802.11e/Draft 10.0 standard, MAC frames are classified according to the priorities of traffic events and a Block Ack Request and Block Ack frame are required for each priority. The BAR (Block Ack Request) field of the Block Ack Request frame in
FIG. 2 and the BA (Block Ack) Control field of the Block Ack inFIG. 3 each include a 4-bit TID (Traffic Identifier), in which anumber 0 to 15 is written. Note that assigning a numerical value from 0 to 7 to the TID indicates that the MAC frame is transmitted by prioritized QoS, i.e., EDCA, whereas assigning a numerical value from 8 to 15 to the TID (which is called TSID: Traffic Stream Identifier) indicates that the MAC frame is transmitted by parameterized QoS, i.e., HCCA. A TID is also used for an RDTID (Reverse Direction Traffic Identifier) of the IAC frame of the Compressed Block Ack inFIG. 8 or of the IAC frame inFIG. 10 . The RDTID field of an IAC frame is used by a transmitting terminal which has acquired a TXOP to designate a priority to a MAC frame to be piggybacked when permitting a destination terminal to perform piggyback transmission. According to the IEEE 802.11e/Draft 10.0 standard, a sequence number must be independently assigned to a MAC frame for each TID. The QoS data receiving side therefore preferably manages the reception buffer for each priority. In transmission based on the Block Ack technique defined in IEEE 802.11e, all MAC frames having lower sequence numbers than the Starting Sequence Number (Block Ack Starting Sequence Control) indicated by a Block Ack Request frame are released from a reception buffer. In this case, since a Block Ack Request frame is prepared for each TID, reception buffer management must be done for each priority (TID). The description of the reception buffer management which has been made with reference toFIGS. 35 and 37 is about the case wherein MAC frames addressed to a plurality of destinations, with a single priority (one kind of TID), are aggregated into a physical frame. In this embodiment, the present invention can be applied to a case wherein MAC frames addressed to a plurality of destinations, with a plurality of priorities, are aggregated into a single physical frame. Referring toFIG. 35 , following the MRAD, the IAC frame toQSTA 1, the data frames with sequence numbers “1” and “2”, the IAC frame toQSTA 2, and the data frames with sequence numbers “1001” and “1002” are aggregated in the order named. Assume, however, that following an MRAD, an IAC frame with a high priority (the value of the TID is arbitrarily set) toQSTA 1, data frames with sequence numbers “1” and “2”, an IAC frame with an intermediate priority toQSTA 1, data frames with sequence numbers “1” and “2”, an IAC frame with a high priority (the value of the TID is arbitrarily set) toQSTA 2, data frames with sequence numbers “1001” and “1002”, an IAC frame with an intermediate priority toQSTA 1, and data frames with sequence numbers “1001” and “1002” are aggregated in the order named. In this case, if an FCS calculation result on a given IAC frame is correct and an FCS calculation result on the succeeding MPDU is correct on the assumption that an IAC frame is aggregated before each destination and each priority, the sequence number of the MPDU is regarded as a proper Starting Sequence Number (Block Ack Starting Sequence Control). All MAC frames having lower sequence numbers than the Starting Sequence Number are then released from a corresponding buffer prepared for each priority in the receiving terminal and forwarded to the upper layer. Alternatively, assume that a physical frame need not necessarily contain any IAC frame, as shown inFIG. 37 . In this case, if FCS calculation results on two consecutive MPDUs are correct and the two MPDUs have different destination addresses or different priorities, the sequence number of the second MPDU is used for the management of a reception buffer prepared for each priority in the destination terminal of the MPDU. That is, all MAC frames having lower sequence numbers than the proper Block Ack Starting Sequence Control are released from the reception buffer and forwarded to the upper layer. - This embodiment has exemplified the case wherein in downlink transmission from an HC (QoS access point) to a QSTA (QoS station), MAC frames addressed to a plurality of destinations are aggregated and transmitted. However, a QSTA may serve as an entity of transmission as long as a TXOP is given by a QoS CF-Poll frame. When the QSTA serves as an entity of transmission, destination candidates include, for example, terminals which can directly communicate with each other between QSTAs through DLS (Direct Link Set-up), in addition to access points. Obviously, the present invention can also be applied to contention-based EDCA as well as HCCA which is a contention-free QoS access control scheme. In EDCA, a terminal which has acquired a TXOP serves as a start point of data transmission to a plurality of destinations. In addition, the permission of piggyback transmission to a destination by an IAC frame is also realized by the scheduling processing device of a terminal which has acquired a TXOP.
- Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described herein. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents.
Claims (9)
1. A communication method comprising:
generating a physical frame in which:
one of a data frame, an acknowledgement frame, and an acknowledgement request frame, and a transmission permission frame which is used in place of a normal Ack frame associated with a delayed Block Ack, and permits a destination terminal to perform piggyback transmission, are aggregated; and
transmitting the physical frame to the destination terminal.
2. A communication method comprising:
receiving a physical frame in which:
one of a data frame, an acknowledgement frame, an acknowledgement request frame, and a transmission permission frame which is used in place of a normal Ack frame associated with a delayed Block Ack, and permits a destination terminal to perform piggyback transmission, are aggregated; and
detecting notification of the normal Ack associated with the delayed Block Ack on the basis of the transmission permission frame.
3. A communication method comprising:
generating a physical frame in which a transmission permission frame for permitting piggyback transmission and data frames for a plurality of destination terminals are aggregated; and
transmitting the physical frame to said plurality of destination terminals,
wherein after data in an opposite direction is received from the destination terminal, a confirmation notification indicating that transmission of a partial response is performed by a delayed type is replaced with a transmission permission frame to the destination terminal.
4. A communication method comprising:
receiving a physical frame in which a transmission permission frame for permitting piggyback transmission and data frames for a plurality of destination terminals are aggregated;
transmitting a data frame to a transmission source terminal of the physical frame upon piggybacking the data frame on a partial response frame; and
transmitting a plurality of MAC frames to a plurality of destination terminals again to a plurality of destination terminals upon aggregating the MAC frames within a continuous transmission permission period currently held by a terminal which has transmitted a physical frame to said plurality of destination terminals,
wherein destination information contained in plural destination control information contained in the physical frame is checked, and if an address of a receiving terminal of the physical frame is not contained, it is determined that application of a delayed policy to a partial response to a piggybacked and transmitted data frame has failed.
5. A communication method comprising:
receiving a physical frame in which MAC frames which are addressed to a plurality of destination terminals and have a plurality of priorities are aggregated;
storing MAC frames of a received physical frame in a reception buffer prepared for each priority; and
managing, on a premise that a control information frame is aggregated in a head portion of a MAC frame for each destination and each priority, the reception buffer by using sequence number information of a data frame following the control frame if an error calculation result on the control frame is correct, and the data frame has been successfully received.
6. A method according to claim 1 , wherein the piggyback transmission comprises transmitting, from the destination terminal to a transmission source, a physical frame in which an acknowledgement frame and at least one MAC frame are aggregated.
7. A method according to claim 1 , further comprising determining, in accordance with a remaining period of a channel use permission period, whether or not to aggregate the transmission permission frame in the physical frame.
8. A method according to claim 1 , further comprising:
determining, after a lapse of a minimum frame time since transmission of the physical frame, whether or not an acknowledgement frame is contained in a physical frame returned from the destination terminal; and
requesting a retransmission of the acknowledgement frame when the acknowledgement frame is not contained.
9. A method according to claim 1 , wherein the presence/absence of the acknowledgement frame is determined on the basis of error detection at a specific frame position in a physical frame returned from the destination terminal.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/646,580 US8274992B2 (en) | 2004-11-01 | 2009-12-23 | Communication method for wireless lans |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004318487A JP4331088B2 (en) | 2004-11-01 | 2004-11-01 | Communication apparatus and communication method |
JP2004-318487 | 2004-11-01 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/646,580 Division US8274992B2 (en) | 2004-11-01 | 2009-12-23 | Communication method for wireless lans |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060092871A1 true US20060092871A1 (en) | 2006-05-04 |
Family
ID=36261733
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/201,258 Abandoned US20060092871A1 (en) | 2004-11-01 | 2005-08-11 | Communication method for wireless LANS |
US12/646,580 Active 2026-10-30 US8274992B2 (en) | 2004-11-01 | 2009-12-23 | Communication method for wireless lans |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/646,580 Active 2026-10-30 US8274992B2 (en) | 2004-11-01 | 2009-12-23 | Communication method for wireless lans |
Country Status (3)
Country | Link |
---|---|
US (2) | US20060092871A1 (en) |
JP (1) | JP4331088B2 (en) |
CN (2) | CN101610260B (en) |
Cited By (93)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050135295A1 (en) * | 2003-10-15 | 2005-06-23 | Walton Jay R. | High speed media access control and direct link protocol |
US20050135416A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Wireless LAN protocol stack |
US20050135284A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control |
US20050135291A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Method, apparatus, and system for multiplexing protocol data units |
US20050135403A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Method, apparatus, and system for medium access control |
US20050135318A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control with legacy system interoperability |
US20050270975A1 (en) * | 2004-06-02 | 2005-12-08 | Arnaud Meylan | Method and apparatus for scheduling in a wireless network |
EP1698109A1 (en) * | 2003-12-22 | 2006-09-06 | Intel Corporation | Bi-directional wireless lan channel access |
US20060274844A1 (en) * | 2003-08-27 | 2006-12-07 | Walton J R | Frequency-independent spatial processing for wideband MISO and MIMO systems |
US20070014237A1 (en) * | 2004-04-23 | 2007-01-18 | Yasuyuki Nishibayashi | Communication apparatus, communication system and communication control program |
US20070058605A1 (en) * | 2005-09-12 | 2007-03-15 | Arnaud Meylan | Scheduling with reverse direction grant in wireless communication systems |
US20070086419A1 (en) * | 2005-10-18 | 2007-04-19 | Samsung Electronics Co., Ltd. | Method for allocating transmission period in a wireless communication system |
US20070086532A1 (en) * | 2005-10-19 | 2007-04-19 | Tilo Ferchland | Device for transmitting and receiving |
US20070115905A1 (en) * | 2005-11-04 | 2007-05-24 | Nokia Corporation | Mechanism for multicast and/or broadcast acknowledgements |
US20070115821A1 (en) * | 2005-10-26 | 2007-05-24 | Samsung Electro-Mechanics Co., Ltd. | Method for transmitting wireless data using piggyback |
US20070147284A1 (en) * | 2005-09-21 | 2007-06-28 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US20070186134A1 (en) * | 2006-01-24 | 2007-08-09 | Samsung Electronics Co., Ltd. | Method and system for generating block ancknowledgements in wireless communications |
US20070183392A1 (en) * | 2006-02-08 | 2007-08-09 | Kabushiki Kaisha Toshiba | Radio communication device, radio communication method, and radio communication program |
US20070230408A1 (en) * | 2006-03-28 | 2007-10-04 | Solomon Trainin | Wireless communication device and method for communicating voice over a wireless network using bidirectional multiple receiver aggregation |
US20070237120A1 (en) * | 2006-03-29 | 2007-10-11 | Cisco Technology, Inc. | Voice over internet protocol favoring aggregating technology in a WLAN |
EP1856813A2 (en) * | 2005-03-07 | 2007-11-21 | Airgo Networks, Inc. | Block ack protocols for wireless packet network |
WO2007139455A1 (en) * | 2006-05-30 | 2007-12-06 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for reducing the amount of messages sent in a communication network |
WO2007143472A2 (en) * | 2006-06-05 | 2007-12-13 | Qualcomm Incorporated | Method and apparatus for providing beamforming feedback in wireless communication systems |
US20080002615A1 (en) * | 2005-06-17 | 2008-01-03 | Tetsu Nakajima | Wireless communication apparatus and method |
WO2008041033A1 (en) | 2006-10-06 | 2008-04-10 | Nokia Siemens Networks Gmbh & Co. Kg | A method of acknowledging data |
US20080130538A1 (en) * | 2006-12-05 | 2008-06-05 | Qualcomm Incorporated | Enhanced management frame aggregation in a wireless network system |
US20080150675A1 (en) * | 2006-12-26 | 2008-06-26 | Kabushiki Kaisha Toshiba | Radio communication apparatus and radio communication method |
US20080159205A1 (en) * | 2006-12-25 | 2008-07-03 | Masahiro Sekiya | Wireless communication apparatus |
US20080165713A1 (en) * | 2004-05-28 | 2008-07-10 | Yasuyuki Nishibayashi | Wireless communication apparatus and wireless communication method |
US20080181251A1 (en) * | 2004-08-11 | 2008-07-31 | Yasuyuki Nishibayashi | Communication apparatus and communication method |
US20080316978A1 (en) * | 2007-06-19 | 2008-12-25 | Levi Ronen | Transmit and receive transition accelerator |
US20090141668A1 (en) * | 2006-05-11 | 2009-06-04 | Nortel Networks Limited | Media access control protocol for multi-hop network systems and method therefore |
US20090252143A1 (en) * | 2008-04-04 | 2009-10-08 | Qualcomm Incorporated | Methods and apparatus for delayed block acknowledgement in a wireless local area network (wlan) |
US20090252110A1 (en) * | 2008-04-02 | 2009-10-08 | Qualcomm Incorporated | Method and appartus for extended reverse direction grant in a wireless local area network (wlan) |
US20090290655A1 (en) * | 2004-05-07 | 2009-11-26 | Qualcomm, Incorporated | Transmission mode and rate selection for a wireless communication system |
US20100002646A1 (en) * | 2004-10-19 | 2010-01-07 | Yasuyuki Nishibayashi | Communication apparatus and method |
EP2154805A1 (en) * | 2007-08-21 | 2010-02-17 | Huawei Technologies Co., Ltd. | A method and a device of distributing tfis and distinguishing feedback information |
US20100046520A1 (en) * | 2006-09-05 | 2010-02-25 | Tsuneo Nakata | Packet recovery method, communication system, information processing device, and program |
US20100074198A1 (en) * | 2007-03-05 | 2010-03-25 | Yuichi Morioka | Setting of network allocation vectors in a wireless communication system |
US20100184723A1 (en) * | 2007-04-27 | 2010-07-22 | Stephen Micheal Henry | Carbohydrate-lipid constructs and their use in preventing or treating viral infection |
US20100202347A1 (en) * | 2009-02-12 | 2010-08-12 | Qualcomm Incorporated | Method and apparatus for acknowledging successful reception of a data transmission for multi-access compatibility in a wireless communication system |
US20100208579A1 (en) * | 2003-06-23 | 2010-08-19 | Intel Corporation | Adaptive use of a transmit opportunity |
US20100332935A1 (en) * | 2006-04-12 | 2010-12-30 | Aware, Inc. | Packet retransmission |
US20110069670A1 (en) * | 2009-09-18 | 2011-03-24 | Electronics And Telecommunications Research Institute | Data transmission apparatus and method in wireless communication system |
US20110223952A1 (en) * | 2004-01-29 | 2011-09-15 | Qualcomm Incorporated | Distributed hierarchical scheduling in an ad hoc network |
US8050249B1 (en) * | 2004-04-26 | 2011-11-01 | Marvell International Ltd. | Methods for reducing contention and/or handling channel access in a network |
CN102256368A (en) * | 2010-05-18 | 2011-11-23 | 英特尔公司 | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
CN102299778A (en) * | 2007-08-21 | 2011-12-28 | 华为技术有限公司 | Feedback method and method and device for distinguishing feedback information |
US20120039257A1 (en) * | 2009-05-08 | 2012-02-16 | Sony Corporation | Communication appartus, communication method, computer program, and communication system |
US8223790B1 (en) * | 2007-04-30 | 2012-07-17 | Avaya Inc. | Method and apparatus performing no back-off forwarding |
US20120213308A1 (en) * | 2010-08-25 | 2012-08-23 | Qualcomm Incorporated | Managing acknolwledgement messages from multiple destinations for multi user mimo transmissions |
US20120230200A1 (en) * | 2011-03-08 | 2012-09-13 | Qualcomm Incorporated | Providing multiple retransmission policies for a single data stream by mapping differentiated services code point (dscp) bit fields to media access control protocol data unit (mpdu) bit fields |
WO2013033533A1 (en) * | 2011-09-02 | 2013-03-07 | Qualcomm Incorporated | Improved fragmentation for long packets in a low-speed wireless network |
US20130089047A1 (en) * | 2011-10-11 | 2013-04-11 | Qualcomm Incorporated | Multi-user transmission during reverse direction grant |
US20130107703A1 (en) * | 2011-10-28 | 2013-05-02 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US20130107824A1 (en) * | 2011-10-28 | 2013-05-02 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US8448035B2 (en) | 2007-06-08 | 2013-05-21 | National University Corporation Nagoya University | Communication system adapting for car, communication apparatus adapting for car, and communication method adapting for car |
US8495473B2 (en) | 2004-10-12 | 2013-07-23 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
WO2013130837A1 (en) * | 2012-02-29 | 2013-09-06 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US20140036775A1 (en) * | 2012-08-06 | 2014-02-06 | Qualcomm Incorporated | Apparatus and methods for frame control design |
US20140146736A1 (en) * | 2012-11-28 | 2014-05-29 | Electronics And Telecommunications Research Institute | Method of grouping stations in multi-transmission |
KR20140105427A (en) * | 2011-12-09 | 2014-09-01 | 엘지전자 주식회사 | Method for transmitting and receiving frame in wireless local area network system and device for supporting same |
US8832515B2 (en) | 2012-02-29 | 2014-09-09 | Qualcomm Incorporated | Block acknowledgement mechanism including sequence number acknowledgement and retry bit |
US8873494B2 (en) | 2011-10-28 | 2014-10-28 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US20140362715A1 (en) * | 2010-02-16 | 2014-12-11 | Electronics And Telecommunications Research Institute | Apparatus and method for broadband wireless local area communication |
US20140369338A1 (en) * | 2005-04-04 | 2014-12-18 | Interdigital Technology Corporation | Method and system for improving responsiveness in exchanging frames in a wireless local area network |
US20150036673A1 (en) * | 2013-07-30 | 2015-02-05 | Qualcomm Incorporated | Systems and methods for communicating multi-destination traffic in a wireless network |
US20150103791A1 (en) * | 2012-01-11 | 2015-04-16 | Intel Corporation | Device, system and method of communicating aggregate data units |
US20150146700A1 (en) * | 2013-11-22 | 2015-05-28 | Qualcomm Incorporated | Channel access deferral mechanism |
US20150188686A1 (en) * | 2009-06-23 | 2015-07-02 | Lg Electronics Inc. | Method of performing link adaptation procedure |
US9191977B2 (en) | 2011-10-28 | 2015-11-17 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9226308B2 (en) | 2003-10-15 | 2015-12-29 | Qualcomm Incorporated | Method, apparatus, and system for medium access control |
US9253290B2 (en) | 2012-02-29 | 2016-02-02 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
KR20160025805A (en) * | 2014-08-28 | 2016-03-09 | 영남대학교 산학협력단 | Packet processing apparatus of wireless lan and the method thereof |
US9338732B2 (en) | 2011-10-28 | 2016-05-10 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9363707B2 (en) | 2011-12-29 | 2016-06-07 | Qualcomm Incorporated | Systems and methods for generating and decoding short control frames in wireless communications |
US20160165635A1 (en) * | 2014-12-04 | 2016-06-09 | Intel Corporation | Apparatus, system and method of dynamic allocation using a grant frame |
US9402243B2 (en) | 2011-10-28 | 2016-07-26 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
WO2016176595A1 (en) * | 2015-04-29 | 2016-11-03 | Interdigital Patent Holdings, Inc. | Triggered transmission opportunity and multiple user ack procedures in wlan systems |
US20160330764A1 (en) * | 2014-01-02 | 2016-11-10 | Lg Electronics Inc. | Method and apparatus for transmitting uplink frame in wireless lan |
WO2017043189A1 (en) * | 2015-09-11 | 2017-03-16 | ソニー株式会社 | Information processing device, communications system, information processing method, and program |
US20170141842A1 (en) * | 2014-03-29 | 2017-05-18 | Intel IP Corporation | Methods and arrangements for power efficient reverse direction communications |
US20170201298A1 (en) * | 2016-01-11 | 2017-07-13 | Intel Corporation | Multiuser multiple-input and multiple-output setup frame |
US9781627B2 (en) | 2013-04-08 | 2017-10-03 | Qualcomm Incorporated | Systems and methods for generating and decoding short control frames in wireless communications |
US9814085B2 (en) | 2011-10-28 | 2017-11-07 | Qualcomm, Incorporated | Systems and methods for fast initial network link setup |
US9900871B1 (en) * | 2017-01-05 | 2018-02-20 | Lg Electronics Inc. | Method for transmitting uplink frame in wireless LAN system and wireless device using the same |
US10771199B2 (en) | 2008-04-02 | 2020-09-08 | Qualcomm Incorporated | Methods and apparatus for reverse link acknowledgement in a wireless local area network (WLAN) |
US11044195B1 (en) | 2008-08-21 | 2021-06-22 | United Services Automobile Association (Usaa) | Preferential loading in data centers |
WO2022152157A1 (en) * | 2021-01-13 | 2022-07-21 | 华为技术有限公司 | Communication method and apparatus |
US11510197B2 (en) * | 2019-02-07 | 2022-11-22 | Plantronics, Inc. | Systems and methods for managing wireless packet communications by assigning separate resources for sequential transmission attempts |
US11659439B2 (en) | 2015-11-30 | 2023-05-23 | Sony Corporation | Information processing apparatus, communication system, information processing method, and program |
US11750329B2 (en) * | 2020-01-04 | 2023-09-05 | Nxp Usa, Inc. | Apparatus and method for block acknowledgement management in multi-link communication systems |
EP4181441A4 (en) * | 2020-07-31 | 2023-11-08 | Huawei Technologies Co., Ltd. | Bit block transmitting method and apparatus |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8879448B2 (en) * | 2006-12-22 | 2014-11-04 | Samsung Electronics Co., Ltd. | Apparatus for controlling power of WiMedia media access control device and method using the same |
US7813296B2 (en) * | 2006-12-27 | 2010-10-12 | Telefonaktiebolaget L M Ericsson (Publ) | Adapting transmission and reception time in packet based cellular systems |
JP5076566B2 (en) * | 2007-03-09 | 2012-11-21 | 沖電気工業株式会社 | Wireless communication system, wireless communication apparatus, and transmission right arbitration method |
JP2008270951A (en) * | 2007-04-17 | 2008-11-06 | Mitsubishi Electric Corp | Data communication device |
JP2009088915A (en) * | 2007-09-28 | 2009-04-23 | Sony Corp | Wireless transmission device, wireless transmission method, wireless communication system, and program |
JP2009278354A (en) * | 2008-05-14 | 2009-11-26 | Sony Corp | Communication device, communication method, program and communication system |
US20100046367A1 (en) * | 2008-08-20 | 2010-02-25 | Qualcomm Incorporated | Power and resource efficient appdu based approach with scheduled data transmission times for wlan |
CN101841512A (en) * | 2009-03-20 | 2010-09-22 | 天际微芯(北京)科技有限公司 | Uplink and downlink communication method of identifier in EOC network |
WO2010108257A1 (en) * | 2009-03-23 | 2010-09-30 | Research In Motion Limited | Systems and methods for allocating and transmitting uplink data block transmissions with piggy-backed ack/nack bitmap |
JP5378525B2 (en) | 2009-09-04 | 2013-12-25 | 株式会社東芝 | Communication system and radio |
JP2011109252A (en) * | 2009-11-13 | 2011-06-02 | Canon Inc | Communication device, control method of communication device, and program |
JP5783575B2 (en) * | 2010-02-02 | 2015-09-24 | マーベル ワールド トレード リミテッド | Power saving function in communication devices |
KR101758909B1 (en) * | 2010-02-18 | 2017-07-18 | 엘지전자 주식회사 | Method and apparatus of transmitting reception acknowledgement in wireless local area network |
US9236975B2 (en) * | 2010-03-08 | 2016-01-12 | Broadcom Corporation | Mobile subscriber information transmission over multiple uplink frames |
US8867459B2 (en) * | 2010-03-08 | 2014-10-21 | Broadcom Corporation | Mobile subscriber information transmission over multiple uplink frames |
US8855088B2 (en) | 2010-12-22 | 2014-10-07 | Intel Corporation | Reverse protocol for low latency wireless applications |
KR101237454B1 (en) * | 2011-02-24 | 2013-02-26 | 서울대학교산학협력단 | Data transmission method using ACK transmission opportunity in wireless network |
US20130034061A1 (en) * | 2011-08-02 | 2013-02-07 | Broadcom Corporation | Reverse direction protocol implementation |
JP5713844B2 (en) * | 2011-08-25 | 2015-05-07 | 株式会社東芝 | Wireless communication apparatus and interference avoidance method |
US9516524B2 (en) * | 2011-10-25 | 2016-12-06 | Mediatek, Inc. | Transmitter assisted quality of service measurement |
CN103188146B (en) * | 2011-12-31 | 2017-04-26 | 华为技术有限公司 | Sending and receiving method and device of continuous data package |
US8971247B2 (en) * | 2012-05-25 | 2015-03-03 | Qualcomm Incorporated | Methods, devices, and systems for efficient retransmission communications |
JP6062690B2 (en) * | 2012-09-03 | 2017-01-18 | 日本放送協会 | Wireless communication apparatus and program |
US9492741B2 (en) | 2013-05-22 | 2016-11-15 | Microsoft Technology Licensing, Llc | Wireless gaming protocol |
US10045367B2 (en) * | 2014-10-03 | 2018-08-07 | Qualcomm Incorporated | Uplink data fragmentation for multi-user networks |
JP6437653B2 (en) * | 2014-12-01 | 2018-12-12 | エルジー エレクトロニクス インコーポレイティド | Method and apparatus for recovering from error without retransmission of data frame in wireless LAN |
JP6699205B2 (en) * | 2016-02-02 | 2020-05-27 | ソニー株式会社 | Base station device, communication terminal, communication system, program, frame transmission method and data structure |
ES2907589T3 (en) * | 2017-01-09 | 2022-04-25 | Wilus Inst Standards & Tech Inc | Wireless communications method using a TXOP and wireless communications terminal using said method |
JPWO2021006064A1 (en) * | 2019-07-10 | 2021-01-14 | ||
EP4090082A4 (en) * | 2020-01-10 | 2023-10-11 | Nippon Telegraph And Telephone Corporation | Terminal, base station, communication method, and communication program |
WO2022144964A1 (en) | 2020-12-28 | 2022-07-07 | 日本電信電話株式会社 | Transmission station and reception station |
US20240098819A1 (en) * | 2020-12-28 | 2024-03-21 | Nippon Telegraph And Telephone Corporation | Transmitting station and receiving station |
WO2022163265A1 (en) * | 2021-01-27 | 2022-08-04 | ソニーグループ株式会社 | Communication device and communication method |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5329531A (en) * | 1993-03-06 | 1994-07-12 | Ncr Corporation | Method of accessing a communication medium |
US20030135640A1 (en) * | 2002-01-14 | 2003-07-17 | Texas Instruments Incorporated | Method and system for group transmission and acknowledgment |
US20050135284A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control |
US20050165950A1 (en) * | 2004-01-09 | 2005-07-28 | Masahiro Takagi | Communication apparatus, communication method, and communication system |
US20050226273A1 (en) * | 2004-04-07 | 2005-10-13 | Lu Qian | Multiple receiver aggregation |
US20050270975A1 (en) * | 2004-06-02 | 2005-12-08 | Arnaud Meylan | Method and apparatus for scheduling in a wireless network |
US20060056443A1 (en) * | 2004-09-10 | 2006-03-16 | Zhifeng Tao | Frame aggregation in wireless communications networks |
US7031287B1 (en) * | 2000-07-14 | 2006-04-18 | At&T Corp. | Centralized contention and reservation request for QoS-driven wireless LANs |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6327254B1 (en) | 1997-10-14 | 2001-12-04 | Lucent Technologies Inc. | Method for bandwidth sharing in a multiple access system for communications networks |
US7352770B1 (en) * | 2000-08-04 | 2008-04-01 | Intellon Corporation | Media access control protocol with priority and contention-free intervals |
US20020159418A1 (en) | 2000-11-02 | 2002-10-31 | Sharp Laboratories Of America, Inc. | Quality of service using wireless lan |
JP3770399B2 (en) | 2001-07-06 | 2006-04-26 | シャープ株式会社 | Communication management method, communication management program, recording medium recording communication management program, communication system, communication apparatus, and central management apparatus |
JP4047836B2 (en) | 2004-04-02 | 2008-02-13 | 株式会社東芝 | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION CONTROL PROGRAM |
JP4086304B2 (en) | 2004-04-23 | 2008-05-14 | 株式会社東芝 | Communication apparatus, communication system, and communication control program |
JP4012172B2 (en) | 2004-05-28 | 2007-11-21 | 株式会社東芝 | Wireless communication apparatus and wireless communication method |
JP4440037B2 (en) | 2004-08-11 | 2010-03-24 | 株式会社東芝 | Communication apparatus and communication method |
JP4130648B2 (en) | 2004-10-19 | 2008-08-06 | 株式会社東芝 | Communication apparatus and communication method |
JP4364165B2 (en) | 2005-06-17 | 2009-11-11 | 株式会社東芝 | Wireless communication device |
JP4284353B2 (en) | 2006-12-26 | 2009-06-24 | 株式会社東芝 | Wireless communication device |
-
2004
- 2004-11-01 JP JP2004318487A patent/JP4331088B2/en not_active Expired - Lifetime
-
2005
- 2005-08-11 US US11/201,258 patent/US20060092871A1/en not_active Abandoned
- 2005-11-01 CN CN2009101345817A patent/CN101610260B/en active Active
- 2005-11-01 CN CNA2005101186704A patent/CN1770774A/en active Pending
-
2009
- 2009-12-23 US US12/646,580 patent/US8274992B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5329531A (en) * | 1993-03-06 | 1994-07-12 | Ncr Corporation | Method of accessing a communication medium |
US7031287B1 (en) * | 2000-07-14 | 2006-04-18 | At&T Corp. | Centralized contention and reservation request for QoS-driven wireless LANs |
US20030135640A1 (en) * | 2002-01-14 | 2003-07-17 | Texas Instruments Incorporated | Method and system for group transmission and acknowledgment |
US20050135284A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control |
US20050165950A1 (en) * | 2004-01-09 | 2005-07-28 | Masahiro Takagi | Communication apparatus, communication method, and communication system |
US20050226273A1 (en) * | 2004-04-07 | 2005-10-13 | Lu Qian | Multiple receiver aggregation |
US20050270975A1 (en) * | 2004-06-02 | 2005-12-08 | Arnaud Meylan | Method and apparatus for scheduling in a wireless network |
US20060056443A1 (en) * | 2004-09-10 | 2006-03-16 | Zhifeng Tao | Frame aggregation in wireless communications networks |
Cited By (232)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100208579A1 (en) * | 2003-06-23 | 2010-08-19 | Intel Corporation | Adaptive use of a transmit opportunity |
US8630168B2 (en) * | 2003-06-23 | 2014-01-14 | Intel Corporation | Adaptive use of a transmit opportunity |
US20060274844A1 (en) * | 2003-08-27 | 2006-12-07 | Walton J R | Frequency-independent spatial processing for wideband MISO and MIMO systems |
US7894538B2 (en) | 2003-08-27 | 2011-02-22 | Qualcomm Incorporated | Frequency-independent spatial processing for wideband MISO and MIMO systems |
US8582430B2 (en) | 2003-10-15 | 2013-11-12 | Qualcomm Incorporated | Method and apparatus for wireless LAN (WLAN) data multiplexing |
US8483105B2 (en) | 2003-10-15 | 2013-07-09 | Qualcomm Incorporated | High speed media access control |
US20090323646A1 (en) * | 2003-10-15 | 2009-12-31 | Qualcomm Incorporated | Method and apparatus for wirless lan (wlan) data multiplexing |
US9072101B2 (en) | 2003-10-15 | 2015-06-30 | Qualcomm Incorporated | High speed media access control and direct link protocol |
US20050135403A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Method, apparatus, and system for medium access control |
US8233462B2 (en) | 2003-10-15 | 2012-07-31 | Qualcomm Incorporated | High speed media access control and direct link protocol |
US20050135295A1 (en) * | 2003-10-15 | 2005-06-23 | Walton Jay R. | High speed media access control and direct link protocol |
US8774098B2 (en) | 2003-10-15 | 2014-07-08 | Qualcomm Incorporated | Method, apparatus, and system for multiplexing protocol data units |
US8842657B2 (en) | 2003-10-15 | 2014-09-23 | Qualcomm Incorporated | High speed media access control with legacy system interoperability |
US20050135291A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Method, apparatus, and system for multiplexing protocol data units |
US20050135284A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control |
US20050135318A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | High speed media access control with legacy system interoperability |
US8472473B2 (en) | 2003-10-15 | 2013-06-25 | Qualcomm Incorporated | Wireless LAN protocol stack |
US8462817B2 (en) | 2003-10-15 | 2013-06-11 | Qualcomm Incorporated | Method, apparatus, and system for multiplexing protocol data units |
US8284752B2 (en) | 2003-10-15 | 2012-10-09 | Qualcomm Incorporated | Method, apparatus, and system for medium access control |
US9137087B2 (en) | 2003-10-15 | 2015-09-15 | Qualcomm Incorporated | High speed media access control |
US9226308B2 (en) | 2003-10-15 | 2015-12-29 | Qualcomm Incorporated | Method, apparatus, and system for medium access control |
US20050135416A1 (en) * | 2003-10-15 | 2005-06-23 | Qualcomm Incorporated | Wireless LAN protocol stack |
EP1698109A1 (en) * | 2003-12-22 | 2006-09-06 | Intel Corporation | Bi-directional wireless lan channel access |
US8903440B2 (en) | 2004-01-29 | 2014-12-02 | Qualcomm Incorporated | Distributed hierarchical scheduling in an ad hoc network |
US20110223952A1 (en) * | 2004-01-29 | 2011-09-15 | Qualcomm Incorporated | Distributed hierarchical scheduling in an ad hoc network |
US20070014237A1 (en) * | 2004-04-23 | 2007-01-18 | Yasuyuki Nishibayashi | Communication apparatus, communication system and communication control program |
US8228889B2 (en) | 2004-04-23 | 2012-07-24 | Kabushiki Kaisha Toshiba | Communication apparatus, communication system and communication control program |
US8050249B1 (en) * | 2004-04-26 | 2011-11-01 | Marvell International Ltd. | Methods for reducing contention and/or handling channel access in a network |
US8355372B2 (en) | 2004-05-07 | 2013-01-15 | Qualcomm Incorporated | Transmission mode and rate selection for a wireless communication system |
US20090290655A1 (en) * | 2004-05-07 | 2009-11-26 | Qualcomm, Incorporated | Transmission mode and rate selection for a wireless communication system |
US20080165713A1 (en) * | 2004-05-28 | 2008-07-10 | Yasuyuki Nishibayashi | Wireless communication apparatus and wireless communication method |
US8284753B2 (en) | 2004-05-28 | 2012-10-09 | Kabushiki Kaisha Toshiba | Wireless communication apparatus and wireless communication method |
US8401018B2 (en) | 2004-06-02 | 2013-03-19 | Qualcomm Incorporated | Method and apparatus for scheduling in a wireless network |
US20090252145A1 (en) * | 2004-06-02 | 2009-10-08 | Qualcomm Incorporated | Method and Apparatus for Scheduling in a Wireless Network |
US20050270975A1 (en) * | 2004-06-02 | 2005-12-08 | Arnaud Meylan | Method and apparatus for scheduling in a wireless network |
US7903632B2 (en) | 2004-08-11 | 2011-03-08 | Kabushiki Kaisha Toshiba | Communication apparatus and communication method |
US20080181251A1 (en) * | 2004-08-11 | 2008-07-31 | Yasuyuki Nishibayashi | Communication apparatus and communication method |
US7869418B2 (en) | 2004-08-11 | 2011-01-11 | Kabushiki Kaisha Toshiba | Communication apparatus and communication method |
US7680148B2 (en) | 2004-08-11 | 2010-03-16 | Kabushiki Kaisha Toshiba | Communication apparatus and communication method |
US20100046437A1 (en) * | 2004-08-11 | 2010-02-25 | Yasuyuki Nishibayashi | Communication apparatus and communication method |
US20100046540A1 (en) * | 2004-08-11 | 2010-02-25 | Yasuyuki Nishibayashi | Communication apparatus and communication method |
US9547608B2 (en) | 2004-10-12 | 2017-01-17 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US9069718B2 (en) | 2004-10-12 | 2015-06-30 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US11543979B2 (en) | 2004-10-12 | 2023-01-03 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US10579291B2 (en) | 2004-10-12 | 2020-03-03 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US8607126B1 (en) | 2004-10-12 | 2013-12-10 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US10409510B2 (en) | 2004-10-12 | 2019-09-10 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US9286251B2 (en) | 2004-10-12 | 2016-03-15 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US9898220B2 (en) | 2004-10-12 | 2018-02-20 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US8495473B2 (en) | 2004-10-12 | 2013-07-23 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US11010073B2 (en) | 2004-10-12 | 2021-05-18 | Tq Delta, Llc | Resource sharing in a telecommunications environment |
US7848330B2 (en) | 2004-10-19 | 2010-12-07 | Kabushiki Kaisha Toshiba | Communication apparatus and method |
US20100002646A1 (en) * | 2004-10-19 | 2010-01-07 | Yasuyuki Nishibayashi | Communication apparatus and method |
EP1856813A2 (en) * | 2005-03-07 | 2007-11-21 | Airgo Networks, Inc. | Block ack protocols for wireless packet network |
EP1856813A4 (en) * | 2005-03-07 | 2011-12-07 | Airgo Networks Inc | Block ack protocols for wireless packet network |
US11259204B2 (en) * | 2005-04-04 | 2022-02-22 | Interdigital Technology Corporation | Method and system for improving responsiveness in exchanging frames in a wireless local area network |
US20140369338A1 (en) * | 2005-04-04 | 2014-12-18 | Interdigital Technology Corporation | Method and system for improving responsiveness in exchanging frames in a wireless local area network |
US8503339B2 (en) | 2005-06-17 | 2013-08-06 | Kabushiki Kaisha Toshiba | Wireless communication apparatus and method |
US7852791B2 (en) | 2005-06-17 | 2010-12-14 | Kabushiki Kaisha Toshiba | Wireless communication apparatus and method |
US20080002615A1 (en) * | 2005-06-17 | 2008-01-03 | Tetsu Nakajima | Wireless communication apparatus and method |
US20110064065A1 (en) * | 2005-06-17 | 2011-03-17 | Tetsu Nakajima | Wireless communication apparatus and method |
US9198194B2 (en) | 2005-09-12 | 2015-11-24 | Qualcomm Incorporated | Scheduling with reverse direction grant in wireless communication systems |
US8600336B2 (en) * | 2005-09-12 | 2013-12-03 | Qualcomm Incorporated | Scheduling with reverse direction grant in wireless communication systems |
US20070058605A1 (en) * | 2005-09-12 | 2007-03-15 | Arnaud Meylan | Scheduling with reverse direction grant in wireless communication systems |
US20070147284A1 (en) * | 2005-09-21 | 2007-06-28 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US8619658B2 (en) * | 2005-09-21 | 2013-12-31 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US9681377B2 (en) | 2005-09-21 | 2017-06-13 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US11470552B2 (en) | 2005-09-21 | 2022-10-11 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US11849393B2 (en) | 2005-09-21 | 2023-12-19 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US10631244B2 (en) | 2005-09-21 | 2020-04-21 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US10375635B2 (en) | 2005-09-21 | 2019-08-06 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US10873907B2 (en) | 2005-09-21 | 2020-12-22 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US10117179B2 (en) | 2005-09-21 | 2018-10-30 | Interdigital Technology Corporation | Method and apparatus for transmission management in a wireless communication system |
US8068476B2 (en) * | 2005-10-18 | 2011-11-29 | Samsung Electronics Co., Ltd. | Method for allocating transmission period in a wireless communication system |
US20070086419A1 (en) * | 2005-10-18 | 2007-04-19 | Samsung Electronics Co., Ltd. | Method for allocating transmission period in a wireless communication system |
US7596365B2 (en) * | 2005-10-19 | 2009-09-29 | Atmel Germany Gmbh | Device for transmitting and receiving |
US20070086532A1 (en) * | 2005-10-19 | 2007-04-19 | Tilo Ferchland | Device for transmitting and receiving |
US20070115821A1 (en) * | 2005-10-26 | 2007-05-24 | Samsung Electro-Mechanics Co., Ltd. | Method for transmitting wireless data using piggyback |
US20070115905A1 (en) * | 2005-11-04 | 2007-05-24 | Nokia Corporation | Mechanism for multicast and/or broadcast acknowledgements |
US7904777B2 (en) * | 2006-01-24 | 2011-03-08 | Samsung Electronics Co., Ltd. | Method and system for generating block acknowledgements in wireless communications |
US20070186134A1 (en) * | 2006-01-24 | 2007-08-09 | Samsung Electronics Co., Ltd. | Method and system for generating block ancknowledgements in wireless communications |
US20070183392A1 (en) * | 2006-02-08 | 2007-08-09 | Kabushiki Kaisha Toshiba | Radio communication device, radio communication method, and radio communication program |
US8045529B2 (en) * | 2006-02-08 | 2011-10-25 | Kabushiki Kaisha Toshiba | Terminal station radio communication device, based station radio communication device, radio communication device, radio communication method, and radio communication program |
US20070230408A1 (en) * | 2006-03-28 | 2007-10-04 | Solomon Trainin | Wireless communication device and method for communicating voice over a wireless network using bidirectional multiple receiver aggregation |
US9615325B2 (en) | 2006-03-28 | 2017-04-04 | Intel Corporation | Access point and method for aggregate MPDU (A-MPDU) and power-save multi-poll (PSMP) operation |
US8654748B2 (en) * | 2006-03-28 | 2014-02-18 | Intel Corporation | Access point and method for aggregate MPDU (A-MPDU) and power-save multi-poll (PSMP) operation |
US20120127982A1 (en) * | 2006-03-28 | 2012-05-24 | Solomon Trainin | Access point and method for aggregate mpdu (a-mpdu) and power-save multi-poll (psmp) operation |
US8125941B2 (en) * | 2006-03-28 | 2012-02-28 | Intel Corporation | Wireless communication device and method for communicating voice over a wireless network using bidirectional multiple receiver aggregation |
US7769044B2 (en) * | 2006-03-29 | 2010-08-03 | Cisco Technology, Inc. | Voice over internet protocol favoring aggregating technology in a WLAN |
US20070237120A1 (en) * | 2006-03-29 | 2007-10-11 | Cisco Technology, Inc. | Voice over internet protocol favoring aggregating technology in a WLAN |
US8407546B2 (en) | 2006-04-12 | 2013-03-26 | Tq Delta, Llc | Packet retransmission and memory sharing |
US9094348B2 (en) | 2006-04-12 | 2015-07-28 | Tq Delta, Llc | Packet retransmission |
US10484140B2 (en) | 2006-04-12 | 2019-11-19 | Tq Delta, Llc | Packet retransmission and memory sharing |
US20100332935A1 (en) * | 2006-04-12 | 2010-12-30 | Aware, Inc. | Packet retransmission |
US8468411B2 (en) * | 2006-04-12 | 2013-06-18 | Tq Delta, Llc | Packet retransmission |
US11362765B2 (en) | 2006-04-12 | 2022-06-14 | Tq Delta, Llc | Packet retransmission using one or more delay requirements |
US20110002331A1 (en) * | 2006-04-12 | 2011-01-06 | Aware, Inc. | Packet retransmission and memory sharing |
US9485055B2 (en) | 2006-04-12 | 2016-11-01 | Tq Delta, Llc | Packet retransmission and memory sharing |
US9749235B2 (en) | 2006-04-12 | 2017-08-29 | Tq Delta, Llc | Packet retransmission |
US10498495B2 (en) | 2006-04-12 | 2019-12-03 | Tq Delta, Llc | Packet retransmission |
US10833809B2 (en) | 2006-04-12 | 2020-11-10 | Tq Delta, Llc | Techniques for packet and message communication in a multicarrier transceiver environment |
US12101188B2 (en) | 2006-04-12 | 2024-09-24 | Tq Delta, Llc | Multicarrier transceiver that includes a retransmission function and an interleaving function |
US10044473B2 (en) | 2006-04-12 | 2018-08-07 | Tq Delta, Llc | Packet retransmission and memory sharing |
US8595577B2 (en) | 2006-04-12 | 2013-11-26 | Tq Delta, Llc | Packet retransmission |
US8645784B2 (en) | 2006-04-12 | 2014-02-04 | Tq Delta, Llc | Packet retransmission and memory sharing |
US20090141668A1 (en) * | 2006-05-11 | 2009-06-04 | Nortel Networks Limited | Media access control protocol for multi-hop network systems and method therefore |
US9438445B2 (en) | 2006-05-11 | 2016-09-06 | Blackberry Limited | Media access control protocol for multi-hop network systems and method therefor |
US8576882B2 (en) * | 2006-05-11 | 2013-11-05 | Blackberry Limited | Media access control protocol for multi-hop network systems and method therefore |
US9742528B2 (en) | 2006-05-30 | 2017-08-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement for reducing the amount of messages sent in a communication network |
WO2007139455A1 (en) * | 2006-05-30 | 2007-12-06 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement for reducing the amount of messages sent in a communication network |
US20080045153A1 (en) * | 2006-06-05 | 2008-02-21 | Qualcomm Incorporated | Method and apparatus for providing beamforming feedback in wireless communication systems |
WO2007143472A2 (en) * | 2006-06-05 | 2007-12-13 | Qualcomm Incorporated | Method and apparatus for providing beamforming feedback in wireless communication systems |
US8542589B2 (en) | 2006-06-05 | 2013-09-24 | Qualcomm Incorporated | Method and apparatus for providing beamforming feedback in wireless communication systems |
WO2007143472A3 (en) * | 2006-06-05 | 2008-02-21 | Qualcomm Inc | Method and apparatus for providing beamforming feedback in wireless communication systems |
US9379852B2 (en) * | 2006-09-05 | 2016-06-28 | Nec Corporation | Packet recovery method, communication system, information processing device, and program |
US20100046520A1 (en) * | 2006-09-05 | 2010-02-25 | Tsuneo Nakata | Packet recovery method, communication system, information processing device, and program |
US8208379B2 (en) | 2006-10-06 | 2012-06-26 | Nokia Siemens Networks Gmbh & Co. Kg | Method of acknowledging data |
WO2008041033A1 (en) | 2006-10-06 | 2008-04-10 | Nokia Siemens Networks Gmbh & Co. Kg | A method of acknowledging data |
GB2442551B (en) * | 2006-10-06 | 2009-01-07 | Siemens Ag | A method of acknowledging data |
US20080130538A1 (en) * | 2006-12-05 | 2008-06-05 | Qualcomm Incorporated | Enhanced management frame aggregation in a wireless network system |
US20080159205A1 (en) * | 2006-12-25 | 2008-07-03 | Masahiro Sekiya | Wireless communication apparatus |
US20080150675A1 (en) * | 2006-12-26 | 2008-06-26 | Kabushiki Kaisha Toshiba | Radio communication apparatus and radio communication method |
US20100074198A1 (en) * | 2007-03-05 | 2010-03-25 | Yuichi Morioka | Setting of network allocation vectors in a wireless communication system |
US10027507B2 (en) * | 2007-03-05 | 2018-07-17 | Sony Corporation | Setting of network allocation vectors in a wireless communication system |
US20100184723A1 (en) * | 2007-04-27 | 2010-07-22 | Stephen Micheal Henry | Carbohydrate-lipid constructs and their use in preventing or treating viral infection |
US8223790B1 (en) * | 2007-04-30 | 2012-07-17 | Avaya Inc. | Method and apparatus performing no back-off forwarding |
US8448035B2 (en) | 2007-06-08 | 2013-05-21 | National University Corporation Nagoya University | Communication system adapting for car, communication apparatus adapting for car, and communication method adapting for car |
US7826429B2 (en) * | 2007-06-19 | 2010-11-02 | Intel Corporation | Transmit and receive transition accelerator |
US20080316978A1 (en) * | 2007-06-19 | 2008-12-25 | Levi Ronen | Transmit and receive transition accelerator |
CN102299778A (en) * | 2007-08-21 | 2011-12-28 | 华为技术有限公司 | Feedback method and method and device for distinguishing feedback information |
EP2154805A1 (en) * | 2007-08-21 | 2010-02-17 | Huawei Technologies Co., Ltd. | A method and a device of distributing tfis and distinguishing feedback information |
EP2154805A4 (en) * | 2007-08-21 | 2010-11-17 | Huawei Tech Co Ltd | A method and a device of distributing tfis and distinguishing feedback information |
US10771199B2 (en) | 2008-04-02 | 2020-09-08 | Qualcomm Incorporated | Methods and apparatus for reverse link acknowledgement in a wireless local area network (WLAN) |
US9450711B2 (en) | 2008-04-02 | 2016-09-20 | Qualcomm Incorporated | Method and apparatus for extended reverse direction grant in a wireless local area network (WLAN) |
US20090252110A1 (en) * | 2008-04-02 | 2009-10-08 | Qualcomm Incorporated | Method and appartus for extended reverse direction grant in a wireless local area network (wlan) |
US20090252143A1 (en) * | 2008-04-04 | 2009-10-08 | Qualcomm Incorporated | Methods and apparatus for delayed block acknowledgement in a wireless local area network (wlan) |
US9203560B2 (en) * | 2008-04-04 | 2015-12-01 | Qualcomm Incorporated | Methods and apparatus for delayed block acknowledgement in a wireless local area network (WLAN) |
US11044195B1 (en) | 2008-08-21 | 2021-06-22 | United Services Automobile Association (Usaa) | Preferential loading in data centers |
US11683263B1 (en) | 2008-08-21 | 2023-06-20 | United Services Automobile Association (Usaa) | Preferential loading in data centers |
US20100202347A1 (en) * | 2009-02-12 | 2010-08-12 | Qualcomm Incorporated | Method and apparatus for acknowledging successful reception of a data transmission for multi-access compatibility in a wireless communication system |
US8804611B2 (en) | 2009-02-12 | 2014-08-12 | Qualcomm Incorporated | Method and apparatus for acknowledging successful reception of a data transmission for multi-access compatibility in a wireless communication system |
US8929286B2 (en) * | 2009-05-08 | 2015-01-06 | Sony Corporation | Communication appartus, communication method, computer program, and communication system |
US10516466B2 (en) | 2009-05-08 | 2019-12-24 | Sony Corporation | Communication apparatus, communication method, computer program, and communication system |
US20120039257A1 (en) * | 2009-05-08 | 2012-02-16 | Sony Corporation | Communication appartus, communication method, computer program, and communication system |
US9847826B2 (en) | 2009-05-08 | 2017-12-19 | Sony Corporation | Communication apparatus, communication method, and communication system |
US10903891B2 (en) | 2009-05-08 | 2021-01-26 | Sony Corporation | Communication apparatus, communication method, and communication system |
US9712336B2 (en) | 2009-05-08 | 2017-07-18 | Sony Corporation | Communication apparatus, communication method, computer program, and communication system |
US10153822B2 (en) | 2009-05-08 | 2018-12-11 | Sony Corporation | Communication apparatus, communication method, computer program, and communication system |
US9191174B2 (en) * | 2009-06-23 | 2015-11-17 | Lg Electronics Inc. | Method of performing link adaptation procedure |
US20150188686A1 (en) * | 2009-06-23 | 2015-07-02 | Lg Electronics Inc. | Method of performing link adaptation procedure |
US9450726B2 (en) | 2009-06-23 | 2016-09-20 | Lg Electronics Inc. | Method of performing link adaptation procedure |
US20110069670A1 (en) * | 2009-09-18 | 2011-03-24 | Electronics And Telecommunications Research Institute | Data transmission apparatus and method in wireless communication system |
US8649324B2 (en) * | 2009-09-18 | 2014-02-11 | Electronics And Telecommunications Research Institute | Data transmission apparatus and method in wireless communication system |
US10361770B2 (en) * | 2010-02-16 | 2019-07-23 | Electronics And Telecommunications Research Institute | Apparatus and method for broadband wireless local area communication |
US20140362715A1 (en) * | 2010-02-16 | 2014-12-11 | Electronics And Telecommunications Research Institute | Apparatus and method for broadband wireless local area communication |
US10812175B2 (en) | 2010-02-16 | 2020-10-20 | Electronics And Telecommunications Research Institute | Apparatus and method for broadband wireless local area communication |
US11411636B2 (en) | 2010-02-16 | 2022-08-09 | Electronics And Telecommunications Research Institute | Method for wideband short-range wireless communication using a directional antenna |
KR101422985B1 (en) * | 2010-05-18 | 2014-07-23 | 인텔 코포레이션 | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
CN102256368A (en) * | 2010-05-18 | 2011-11-23 | 英特尔公司 | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
WO2011146204A3 (en) * | 2010-05-18 | 2012-04-19 | Intel Corporation | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
US20150003239A1 (en) * | 2010-05-18 | 2015-01-01 | Michelle X. Gong | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
US20110286402A1 (en) * | 2010-05-18 | 2011-11-24 | Intel Corporation | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
WO2011146204A2 (en) * | 2010-05-18 | 2011-11-24 | Intel Corporation | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
US8855063B2 (en) * | 2010-05-18 | 2014-10-07 | Intel Corporation | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
US9661648B2 (en) * | 2010-05-18 | 2017-05-23 | Intel Corporation | Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network |
US10033485B2 (en) * | 2010-08-25 | 2018-07-24 | Qualcomm Incorporated | Managing acknowledgement messages from multiple destinations for multi user MIMO transmissions |
US20120213308A1 (en) * | 2010-08-25 | 2012-08-23 | Qualcomm Incorporated | Managing acknolwledgement messages from multiple destinations for multi user mimo transmissions |
US20120230200A1 (en) * | 2011-03-08 | 2012-09-13 | Qualcomm Incorporated | Providing multiple retransmission policies for a single data stream by mapping differentiated services code point (dscp) bit fields to media access control protocol data unit (mpdu) bit fields |
US9438384B2 (en) * | 2011-03-08 | 2016-09-06 | Qualcomm Incorporated | Providing multiple retransmission policies for a single data stream by mapping differentiated services code point (DSCP) bit fields to media access control protocol data unit (MPDU) bit fields |
KR101903998B1 (en) | 2011-09-02 | 2018-10-04 | 퀄컴 인코포레이티드 | Improved fragmentation for long packets in a low-speed wireless network |
CN103858373A (en) * | 2011-09-02 | 2014-06-11 | 高通股份有限公司 | Improved fragmentation for long packets in a low-speed wireless network |
EP2827523A1 (en) * | 2011-09-02 | 2015-01-21 | Qualcomm Incorporated | Improved fragmentation for long packets in a low-speed wireless network |
WO2013033533A1 (en) * | 2011-09-02 | 2013-03-07 | Qualcomm Incorporated | Improved fragmentation for long packets in a low-speed wireless network |
US9179476B2 (en) * | 2011-10-11 | 2015-11-03 | Qualcomm Incorporated | Multi-user transmission during reverse direction grant |
US20130089047A1 (en) * | 2011-10-11 | 2013-04-11 | Qualcomm Incorporated | Multi-user transmission during reverse direction grant |
US8873494B2 (en) | 2011-10-28 | 2014-10-28 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US20130107703A1 (en) * | 2011-10-28 | 2013-05-02 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9338732B2 (en) | 2011-10-28 | 2016-05-10 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9445438B2 (en) * | 2011-10-28 | 2016-09-13 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9402243B2 (en) | 2011-10-28 | 2016-07-26 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9191977B2 (en) | 2011-10-28 | 2015-11-17 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US20130107824A1 (en) * | 2011-10-28 | 2013-05-02 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9271317B2 (en) * | 2011-10-28 | 2016-02-23 | Qualcomm Incorporated | Systems and methods for fast initial network link setup |
US9814085B2 (en) | 2011-10-28 | 2017-11-07 | Qualcomm, Incorporated | Systems and methods for fast initial network link setup |
KR20140105427A (en) * | 2011-12-09 | 2014-09-01 | 엘지전자 주식회사 | Method for transmitting and receiving frame in wireless local area network system and device for supporting same |
US9577744B2 (en) * | 2011-12-09 | 2017-02-21 | Lg Electronics Inc. | Method for transmitting and receiving a frame in a wireless LAN system, and apparatus for supporting the method |
KR101597472B1 (en) | 2011-12-09 | 2016-02-24 | 엘지전자 주식회사 | Method for transmitting and receiving frame in wireless local area network system and device for supporting same |
US20140286226A1 (en) * | 2011-12-09 | 2014-09-25 | Lg Electronics Inc. | Method for transmitting and receiving a frame in a wireless lan system, and apparatus for supporting the method |
KR20140105428A (en) * | 2011-12-09 | 2014-09-01 | 엘지전자 주식회사 | Method for transmitting and receiving a frame in a wireless lan system, and apparatus for supporting the method |
US20170118602A1 (en) * | 2011-12-09 | 2017-04-27 | Lg Electronics Inc. | Method for transmitting and receiving a frame in a wireless lan system, and apparatus for supporting the method |
KR101603450B1 (en) | 2011-12-09 | 2016-03-14 | 엘지전자 주식회사 | Method for transmitting and receiving a frame in a wireless lan system, and apparatus for supporting the method |
US9363707B2 (en) | 2011-12-29 | 2016-06-07 | Qualcomm Incorporated | Systems and methods for generating and decoding short control frames in wireless communications |
US20150103791A1 (en) * | 2012-01-11 | 2015-04-16 | Intel Corporation | Device, system and method of communicating aggregate data units |
US20160080113A1 (en) * | 2012-01-11 | 2016-03-17 | Intel Corporation | Device, system and method of communicating aggregate data units |
US9712284B2 (en) * | 2012-01-11 | 2017-07-18 | Intel Corporation | Device, system and method of communicating aggregate data units |
US9325455B2 (en) | 2012-01-11 | 2016-04-26 | Intel Corporation | Device, system and method of communicating aggregate data units |
US9219578B2 (en) * | 2012-01-11 | 2015-12-22 | Intel Corporation | Device, system and method of communicating aggregate data units |
WO2013130837A1 (en) * | 2012-02-29 | 2013-09-06 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US9301196B2 (en) | 2012-02-29 | 2016-03-29 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US9019822B2 (en) | 2012-02-29 | 2015-04-28 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US9253290B2 (en) | 2012-02-29 | 2016-02-02 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US8832515B2 (en) | 2012-02-29 | 2014-09-09 | Qualcomm Incorporated | Block acknowledgement mechanism including sequence number acknowledgement and retry bit |
US9432879B2 (en) | 2012-02-29 | 2016-08-30 | Qualcomm Incorporated | Apparatus and methods for block acknowledgment compression |
US20140036775A1 (en) * | 2012-08-06 | 2014-02-06 | Qualcomm Incorporated | Apparatus and methods for frame control design |
US10178582B2 (en) * | 2012-08-06 | 2019-01-08 | Qualcomm Incorporated | Apparatus and methods for frame control design |
US20140146736A1 (en) * | 2012-11-28 | 2014-05-29 | Electronics And Telecommunications Research Institute | Method of grouping stations in multi-transmission |
US9781627B2 (en) | 2013-04-08 | 2017-10-03 | Qualcomm Incorporated | Systems and methods for generating and decoding short control frames in wireless communications |
US20150036673A1 (en) * | 2013-07-30 | 2015-02-05 | Qualcomm Incorporated | Systems and methods for communicating multi-destination traffic in a wireless network |
US20150146700A1 (en) * | 2013-11-22 | 2015-05-28 | Qualcomm Incorporated | Channel access deferral mechanism |
US9907070B2 (en) * | 2013-11-22 | 2018-02-27 | Qualcomm Incorporated | Channel access deferral mechanism |
US9854605B2 (en) * | 2014-01-02 | 2017-12-26 | Lg Electronics Inc. | Method and apparatus for transmitting uplink frame in wireless LAN |
US20160330764A1 (en) * | 2014-01-02 | 2016-11-10 | Lg Electronics Inc. | Method and apparatus for transmitting uplink frame in wireless lan |
US20170141842A1 (en) * | 2014-03-29 | 2017-05-18 | Intel IP Corporation | Methods and arrangements for power efficient reverse direction communications |
KR20160025805A (en) * | 2014-08-28 | 2016-03-09 | 영남대학교 산학협력단 | Packet processing apparatus of wireless lan and the method thereof |
KR101708977B1 (en) | 2014-08-28 | 2017-02-21 | 영남대학교 산학협력단 | Packet processing apparatus of wireless lan and the method thereof |
US20160165635A1 (en) * | 2014-12-04 | 2016-06-09 | Intel Corporation | Apparatus, system and method of dynamic allocation using a grant frame |
US9775170B2 (en) * | 2014-12-04 | 2017-09-26 | Intel Corporation | Apparatus, system and method of allocation using a frame |
US10194461B2 (en) | 2014-12-04 | 2019-01-29 | Intel Corporation | Apparatus, system and method of dynamic allocation using a grant frame |
WO2016176595A1 (en) * | 2015-04-29 | 2016-11-03 | Interdigital Patent Holdings, Inc. | Triggered transmission opportunity and multiple user ack procedures in wlan systems |
US11082167B2 (en) | 2015-04-29 | 2021-08-03 | Interdigital Patent Holdings, Inc. | Triggered transmission opportunity and multiple user ACK procedures in WLAN systems |
US10869218B2 (en) | 2015-09-11 | 2020-12-15 | Sony Corporation | Information processing devices and communication system for controlling transmission of acknowledgement and data |
WO2017043189A1 (en) * | 2015-09-11 | 2017-03-16 | ソニー株式会社 | Information processing device, communications system, information processing method, and program |
CN108029039A (en) * | 2015-09-11 | 2018-05-11 | 索尼公司 | Information processing equipment, communication system, information processing method and program |
US11659439B2 (en) | 2015-11-30 | 2023-05-23 | Sony Corporation | Information processing apparatus, communication system, information processing method, and program |
US11805442B2 (en) | 2015-11-30 | 2023-10-31 | Sony Corporation | Information processing apparatus, communication system, information processing method, and program |
US20170201298A1 (en) * | 2016-01-11 | 2017-07-13 | Intel Corporation | Multiuser multiple-input and multiple-output setup frame |
US10972157B2 (en) | 2016-01-11 | 2021-04-06 | Intel IP Corporation | Multiuser multiple-input and multiple-output setup frame |
US9900871B1 (en) * | 2017-01-05 | 2018-02-20 | Lg Electronics Inc. | Method for transmitting uplink frame in wireless LAN system and wireless device using the same |
US11510197B2 (en) * | 2019-02-07 | 2022-11-22 | Plantronics, Inc. | Systems and methods for managing wireless packet communications by assigning separate resources for sequential transmission attempts |
US11750329B2 (en) * | 2020-01-04 | 2023-09-05 | Nxp Usa, Inc. | Apparatus and method for block acknowledgement management in multi-link communication systems |
EP4181441A4 (en) * | 2020-07-31 | 2023-11-08 | Huawei Technologies Co., Ltd. | Bit block transmitting method and apparatus |
WO2022152157A1 (en) * | 2021-01-13 | 2022-07-21 | 华为技术有限公司 | Communication method and apparatus |
Also Published As
Publication number | Publication date |
---|---|
CN1770774A (en) | 2006-05-10 |
CN101610260B (en) | 2013-05-29 |
JP2006129393A (en) | 2006-05-18 |
JP4331088B2 (en) | 2009-09-16 |
CN101610260A (en) | 2009-12-23 |
US8274992B2 (en) | 2012-09-25 |
US20100189056A1 (en) | 2010-07-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8274992B2 (en) | Communication method for wireless lans | |
US7746861B2 (en) | Communication apparatus and method | |
US7680148B2 (en) | Communication apparatus and communication method | |
US7743310B2 (en) | Communication apparatus, communication system, communication method, and communication control program | |
US7990995B2 (en) | Wireless communication apparatus and wireless communication method | |
US20190174484A1 (en) | Method for transmitting a response request frame and a response frame in a multi-user based wireless communication system | |
KR101871093B1 (en) | Method and device for receiving frame | |
JP5148275B2 (en) | Method and system for controlling access to a wireless communication medium | |
EP1571773A2 (en) | Communication apparatus, communication method, and communication system | |
JP4374001B2 (en) | COMMUNICATION DEVICE, COMMUNICATION METHOD, AND COMMUNICATION SYSTEM | |
KR20220162757A (en) | RTA Packet Replication in Time and Frequency | |
WO2020037990A1 (en) | Conflict detection method and device for achieving data transmission | |
JP4314294B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION CONTROL PROGRAM | |
WO2008012789A1 (en) | Method for reduced latency wireless communication having reduced latency and increased range and handoff performance between different transmitting stations |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KABUSHIKI KAISHA TOSHIBA, JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NISHIBAYASHI, YASUYUKI;TAKAGI, MASAHIRO;ADACHI, TOMOKO;AND OTHERS;REEL/FRAME:017087/0712;SIGNING DATES FROM 20050823 TO 20050830 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |