Patent Application
20160330788
The present application claims the benefit of the Singapore Patent Application No. 201309710-0 filed on 31 Dec. 2013, the entire contents of which are incorporated herein by reference for all purposes.
Embodiments relate generally to mobile radio communication devices and methods for controlling a mobile radio communication device.
In wireless communication, a mobile station (which may for example be referred to as a station or STA) may communicate with an access point (AP).
According to various embodiments, a mobile radio communication device may be provided. The mobile radio communication device may include: a receiver configured to receive data; an access point identification circuit configured to determine whether the received data is received from or sent to an access point corresponding to the mobile radio communication device; and a response indication deferral setting circuit configured to set a response indication deferral parameter based on the determination of the access point identification circuit.
According to various embodiments, a method for controlling a mobile radio device may be provided. The method may include: receiving data; determining whether the received data is received from or sent to an access point corresponding to the mobile radio communication device; and setting a response indication deferral parameter based on the determining.
In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments are described with reference to the following drawings, in which:
Embodiments described below in context of the devices are analogously valid for the respective methods, and vice versa. Furthermore, it will be understood that the embodiments described below may be combined, for example, a part of one embodiment may be combined with a part of another embodiment.
In this context, the mobile radio communication device as described in this description may include a memory which is for example used in the processing carried out in the mobile radio communication device. A memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
In an embodiment, a “circuit” may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus, in an embodiment, a “circuit” may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor (e.g. a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor), for example a MCU (microcontroller unit) or CPU (central processing unit). A “circuit” may also be a processor executing software, e.g. any kind of computer program, e.g. a computer program using a virtual machine code such as e.g. Java. Any other kind of implementation of the respective functions which will be described in more detail below may also be understood as a “circuit” in accordance with an alternative embodiment.
According to various embodiments, the SIG field may include an indication of a short acknowledgement for a null data packet type PS poll.
According to various embodiments, the SIG field may include an indication of at least one of a normal acknowledgement or a short acknowledgement.
According to various embodiments, the SIG field may include an indication of an acknowledgement for speed frame exchange.
According to various embodiments, the SIG field may include an indication of a duration for a network allocation vector.
According to various embodiments, the SIG field may include an indication of a type of a null data packet, wherein the indication may include an indication of 3 bits, if a channel bandwidth of 1 MHz is used for communication.
According to various embodiments, the SIG field may include an indication of a type of a null data packet, wherein the indication may include an indication of 4 bits, if a channel bandwidth of more than 2 MHz is used for communication.
According to various embodiments, the SIG field may include a relay bit indicating that ready to send indication is required to be relayed.
According to various embodiments, the SIG field may include an indication of whether frame forwarding time required by a relay is included in the ready to send duration.
According to various embodiments, the SIG field may include an indication of whether a null data packet frame or a normal frame is provided.
According to various embodiments, the SIG field may include an indication of a short acknowledgement for a null data packet type PS poll.
According to various embodiments, the SIG field may include an indication of at least one of a normal acknowledgement or a short acknowledgement.
According to various embodiments, the SIG field may include an indication of an acknowledgement for speed frame exchange.
According to various embodiments, the SIG field may include an indication of an acknowledgement for TXOP sharing. TXOP sharing may be performed across the Relay (3 parties are involved: non-AP STA, Relay and AP). Relay may include two entities: Relay STA and Relay AP.
According to various embodiments, the SIG field may include an indication of a duration for a network allocation vector or an inactivity period, where inactivity period may refer to a duration time that there is no transmissions between the STAs or a sleep duration for the STA to reschedule its doze/awake cycle or a flow suspend duration for flow control. Short ACK may include a Duration Indication field and Duration field. It will be understood that Short ACK is equivalent to NDP ACK,
According to various embodiments, the SIG field may include an indication of a type of a null data packet, wherein the indication may include an indication of 3 bits, if a channel bandwidth of 1 MHz is used for communication.
According to various embodiments, the SIG field may include an indication of a type of a null data packet, wherein the indication may include an indication of 4 bits, if a channel bandwidth of more than 2 MHz is used for communication.
According to various embodiments, an exceptional case may occur as follows: A null data packet of ACK is the response frame to a null data packet type of PS-Poll. Various embodiments may make use of NDP Type indication and other fields in SIG to infer that the following frame for NDP PS-Poll shall be NDP Modified ACK.
According to various embodiments, the first data unit may be a null data packet type PS-Poll and at least one of the fields in the PHY header indicates that the following response data unit is a null data packet type ACK and the null data packet type ACK is different from other null data packet type ACK (and for example used only for the null data packet type PS-Poll).
According to various embodiments, at least a field may indicate whether the response data unit is at least one of a normal response data type or a null data packet type.
According to various embodiments, the normal response data unit may be or may include at least one of normal ACK, normal Block ACK or a polling response frame
According to various embodiments, the field may include at least 2 bits and only one value of the field is used to indicate all the short data response units including at least one of the following: a null data packet format of ACK, a null data packet format of short response frame to null data type PS-Poll, a null data packet format of CTS, and a null data packet format of Block Ack frame.
According to various embodiments, the indication may include at least three bits. According to various embodiments, a first value of the field may indicate that no response data unit is intended to follow the first data unit. According to various embodiments, a second value of the field may indicate the intended response data is a null data packet type. According to various embodiments, a third value of the field may indicate the intended response data having the size equal to or smaller than normal ACK. According to various embodiments, a fourth value of the field may indicate the intended response data having the size equal to or smaller than normal Block Acknowledgement but larger than normal ACK. According to various embodiments, a fifth value of the field indicates the intended response data unit having the size other than the four values listed above.
According to various embodiments, the field may include two bits (i.e. 4 values). According to various embodiments, a first value of the field may indicate that no response data unit is intended to follow the first data unit. According to various embodiments, a second value of the field may indicate the intended response data is a null data packet type. According to various embodiments, a third value of the field may indicate the intended response data having the size equal to or shorter than a pre-determined value but larger than the size indicated in the second value. According to various embodiments, a fourth value of the field may indicate the intended response data unit having the size larger than the size indicated by the third value.
According to various embodiments, the PHY header may include an indication of a response data unit for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the type of the response data unit may be a normal response data type for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the response data unit may be a normal ACK and its Duration field for NAV setting may protect the following transmission in one TXOP.
According to various embodiments, the type of the response data unit may be a null data packet type for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the response data unit may be a null data packet ACK or a null data packet format of short response frame to null data type PS-Poll and its Duration field for NAV setting may protect the following transmission in one TXOP.
According to various embodiments, the first data unit itself may be a null data packet type PS-Poll and the response data unit is a null data packet response frame to null data type PS-Poll.
According to various embodiments, the first data unit may be at least one of a null data packet type ACK or a null data packet type response frame responding to a null data type PS-Poll, and two or more bits in at least two fields of the first data unit may indicate that there is no response data unit intended to follow the first data unit.
According to various embodiments, the Duration Indication field set to 0 and the Duration field set to 0 may indicate that there is no response data unit intended to follow the first data unit.
According to various embodiments, the first data unit may be a null data packet type ACK or a null data packet type response frame responding to a null data type PS-Poll, and two or more bits in at least two fields of the first data unit may indicate that the response data unit is a type with the size larger than that of a normal data unit. A normal data unit is a data unit that is not a null data packet. A null data packet is a PPDU without Data field.
According to various embodiments, the Duration Indication field set to 1 and the Duration field set to 0 may indicate that the response data unit is a type with the size larger than that of a normal data unit.
According to various embodiments, the PHY header may include an indication of a duration for a network allocation vector.
According to various embodiments, the nonzero valid duration of first data unit may be set to protect at least the transmission of the response data unit, indicating the duration of at least one response data unit.
According to various embodiments, the intended receiver may defer at least one of its transmission or channel access for at least a duration based on the indication for the type of the response data unit.
According to various embodiments, the type of the response data unit may be a null data packet frame.
According to various embodiments, the type of the response data unit may be a normal frame with the size equal to or short than that of a normal ACK.
According to various embodiments, the type of the response data unit may be a normal frame with the size equal to or smaller than that of a normal Block ACK but larger than that of a normal ACK.
In the following, short frames, for example for IEEE 802.11-based Networks, will be described. Examples of short frame are Short Ack (acknowledgement), Short CTS (clear to send), Short Block Ack, NDP (null data packet) type PS-Poll (power save poll), NDP probe request, NDP sounding, short beamforming report Poll frame and Short MAC (medium access control) header.
Active STAs (stations) with TIM (traffic indication map) bit on may be allowed to poll the AP after receiving the beacon with TIM. A low power/Non-TIM STA may be allowed to transmit PS-Poll to its associated AP (access point) after wakeup without listening to the beacon. Due to the fact that PS-Poll may be widely used for power saving and low power operation, short frame format of ACK and PS-Poll may improve transmission efficiency and reduces power consumption.
In the following, NDP Type Indication will be described.
According to various embodiments, methods to indicate the types of NDP frame in SIG may be provided. More than 8 NDP frames may be provided. Furthermore, a method to indicate the type of NDP frames may be provided.
SIG may mean SIGNAL field of PPDU (physical protocol data unit).
S1G PPDU (i.e. the PPDU format for IEEE 802.11ah) may include:
The Data field may carry the PSDU(s) (Physical layer Service Data Unit).
The null data packet (NDP) may include:
The null data packet (NDP) frame has no Data field.
One of PPDU formats that includes PSDU could be:
The Data field may carry the PSDU(s).
For example, for 8 types of NDP frames, a 3-bit NDP-T (NDP Type) field within the SIG bits may be provided. When the AP/STA receives a NDP frame the AP/STA may proceed to obtain the NDP-T field to know the type of NDP frame. If there are more than 8 types (for example assuming less than 16 (in other words: <16)) of NDP frames, a 4-bit NDP-T field within SIG bits may be provided. However, some NDP type frames may have used up all the bits in the SIG and may not support 4-bit NDP-T field, e.g. NDP type PS-Poll uses up all the bits as shown in the following example (for example like illustrated in Table 1).
According to various embodiments, the following options for NDP-T indication may be provided:
In Option 1, a re-design of the fields in NDP type frames may be provided so that 4-bit NDP-T field may be supported in all NDP type frames.
In Option 2, 3-bit NDP-T plus one extended reserved bit that can be accommodated in some NDP types may be used to differentiate more than 8 types of NDP frame, like will be described in more detail below.
In Option 3, some NDP types may not be supported for 1 MHz case, and may be defined 3-bit NDP-T for channel bandwidth equal to 1 MHz and 4-bit NDP-T for channel bandwidth greater or equal to 2 MHz, like will be described in more detail below.
According to various embodiments, for Option 2, 3-bit NDP-T and one extended bit may be used to indicate NDP types. For example, assuming short ACK/CTS has at least one reserved bit and one 3-bit value (e.g. 0b111) may be reserved to identify both short ACK and CTS. By extending one reserved bit (with the same position) in both short ACK and CTS as the extended type identification, it may be possible to determine whether it is a short ACK or short CTS.
According to various embodiments, the protocol to handle NDP-T Field in Option 2 may be as follows: If the AP/STA receives the NDP frames after identifying this NDP frame, the AP/STA may proceed to identify the NDP-T fields so that it can know which NDP type the received frame is. When AP/STA identifies that the NDP-T field value is the defined case for extended indication, it may check the reserved bit (used as extended type identification bit) to further determine which NDP type the frame is.
According to various embodiments, for Option 3, 3-bit NDP-T may be used for 1 MHz channel bandwidth and 4-bit NDP-T may be used for 2 MHz channel bandwidth.
In the 1 MHz case, e.g. NDP sounding may not be applicable. Then 3-bit NDP-T may not be required to cover NDP sounding case, which may mean the NDP-T field value for NDP sounding is not in the range of [0,7]. Assuming that there are 6 NDP types for 1 MHz case, the value 0-5 (0b000-0b101) may be used for 3-bit NDP-T.
In the 2 MHz case, NDP sounding and other NDP type frames that are not supported in 1 MHz may be differentiated with a 4-bit NDP-T value (e.g. large than 7). For example, if there are 2 NDP types (short beamforming report Poll frame and NDP sounding) only defined for 2 MHz case. The value 0-5 (0b000-0b101) may be used for 4-bit NDP-T to indicate 6 NDP types that is supported in 1 MHz case, and the value of (0b1000-0b1001) for 4-bit NDP-T to indicate 2 NDP types that are defined only for 2 MHz case.
According to various embodiments, the protocol to handle NDP-T Field in Option 3 may be as follows: If the AP/STA receives the NDP frames after identifying that it is a NDP frame, the AP/STA may determine that it is for 1 MHz or >=2 MHz channel and proceed to identify the NDP-T fields so that it can know which NDP type the received frame is. For 1 MHz channel, it may only be needed to check 3-bit NDP-T field. For channel bandwidth>=2 MHz, it may be needed to check 4-bit NDP-T field.
In the following, Short Ack for NDP Type PS-Poll according to various embodiments will be described. According to various embodiments, a design of short Ack for NDP type PS-Poll frame may be provided. Short Ack and NDP type PS-Poll may have been accepted into IEEE specification framework (IEEE 802.11-1137-10-00ah-specification-framework-for-tgah, Mingyong Park, “IEEE 802.11ah Specification Framework”). In Section R.4.4.2.1.A thereof, it is specified that the draft specification shall support the following short ACK format with SIG fields that are the same as those in normal SIG: CRC (4 bits) and Tail (6bits—TBD), and the short ACK SIG shall include an ACK ID field (bits TBD) which use partial FCS and the information from the scrambling seed in the SERVICE field of the frame being acknowledged for the computation of the ACK ID for short ACK frames.
However, upon receiving NDP type PS-Poll frame from the STA, the AP may send a response frame to STA as follows:
(1) Normal DATA/ACK, which requires no change for the protocol;
(2) Short ACK, which requires some modification since there is a very short checksum of the received frame (CRC 4 bits for SIG) and no scrambling seed can be used to compute ACK ID field;
(3) Short Response Frame, which requires that a new rule/protocol shall be defined.
Hence, according to various embodiments, the following options may be provided:
In Option 1, the AP may respond to NDP type PS-Poll with normal ACK.
In Option 2, the AP may respond to NDP type PS-Poll with short ACK but with modification. ACK ID may be computed differently. It will be described in more detail below how to compute ACK ID according to various embodiments.
In Option 3, the AP may respond to NDP type PS-Poll with a new Short Response Frame.
More details on option 2 will be given in the following, where short Ack with modification will be described.
In the following, Short Ack SIG Design according to various embodiments will be described.
For example, an event that there are two concurrent transmissions of NDP type PS-Poll: A->AP (which for example may mean a transmission from STA A to AP) and B->AP (which for example may mean a transmission from STA B to AP) will be described. Both A and B may expect short Ack from AP. Suppose that AP can only receive a strong signal from A and respond to A's NDP PS-Poll with short Ack that can reach B. B receives AP's short Ack, which should carry identification of STA e.g. partial AID information in short response frame SIG so that the possibility of this false short Ack case should be zero. The example of such false short Ack occurs at one AP is shown in
The above examples show that including transmitter and receiver address/identification (for example to an ACK ID (identifier)) according to various embodiments may be helpful to avoid the false short Ack.
Following the same structure of short Ack for non-NDP type frames in Table 2, short Ack for NDP type PS-Poll may have the field ACK ID as the identifier for pairing frame exchange i.e. short Ack for NDP type PS-Poll frame.
However, the design of ACK ID may be different (for example different from the example as shown in Table 2), as will be described in more detail in the following.
When the AP uses short Ack as the response frame for the received NDP type PS-Poll, the following information (wherein some information may be included in NDP type PS-Poll) may be used to compute the identifier for the pairing frame exchange i.e. short Ack for NDP type PS-Poll:
According to various embodiments, four options for the short Ack SIG format may be provided, like will be described with reference to Table 3 to Table 6.
According to various embodiments, in Option 1 (compare Table 3 for SIG fields), the fields of RA (receiver address) and TA (transmitter address) may be defined, RA and TA bits may be used as the identifier for pairing frame exchange i.e. short Ack for NDP type PS-Poll.
The probability of exact same RA and TA of short Ack for NDP type PS-Poll may be low due to the design of RA, which may be based on (partial) AID of the STA that sends NDP type PS-Poll and/or CRC bits of NDP type PS-Poll to identify the receiver of Short Ack, and the design of TA, which may be based on partial FCS and Scramble Seed of received beacon frame or RA bits (and possibly CRC bits) of NDP type PS-Poll to identify the transmitter of Short Ack.
According to various embodiments, in Option 2 (compare Table 4 for SIG fields), ACK ID may be defined and used as the identifier for pairing frame exchange i.e. short Ack for NDP type PS-Poll. One combined field i.e. ACK ID in SIG to replace RA and TA fields may be designed, but may have different length. It is to be noted that while computation of ACK ID in short Ack for the received frame other than NDP type is based on partial FCS (frame check sequence) and scrambling seed of received frame, computation of ACK ID in short Ack for NDP PS-Poll may be based on the methods shown in the following for ACK ID computation.
The design according to various embodiments may ensure a low duplication probability of RA and TA bits or ACK ID for NDP type and ACK ID for non-NDP type frame, due to the difference between the two computation methods. The identification in SIG bits may be used to differentiate two types of short Ack.
According to various embodiments, in Option 3, the same structure as the short Ack for non-NDP type may be used but may have a re-defined DURATION field (if it is defined) or use some reserved bits in current short Ack design (if DURATION field is not defined). The newly defined/redefined field may be ACK ID Ext.
ACK ID and ACK ID Ext fields may be used as the identifier for the pairing frame exchange, where ACK ID may be the resulting bits based on partial FCS and scramble seed of received beacon frame or RA bits of NDP frame being acknowledged, and some TA bits of NDP frame being acknowledged. E.g. 9 RA bits and 3 MSB (most significant bits) of TA field for 12 ACK ID bits, and ACK ID Ext is some (remaining) TA bits of NDP frame being acknowledged. E.g. 6 LSB (least significant bits) of TA field for 6 DURATION/ACK ID Ext bits. If more bits can be used for ACK ID Ext, CRC bits of the received NDP type frame can be used that is being acknowledged. According to various embodiments, other bit arrangement may be provided, dependent on whether to place the above bits into the fields of ACK ID/ACK ID Ext.
According to various embodiments, ACK ID may be used to refer to the combination of ACK ID and ACK ID Ext bits/fields without causing any ambiguity.
According to various embodiments, Option 4 may follow the same field structure as the short Ack for non-NDP type. ACK ID may be the identifier for the paring frame exchange, 12-14 bits. ACK ID may be a function of RA and TA bits of NDP type frame. ACK ID may be a function of RA bits of NDP type frame and resulting bits based on partial FCS and scramble seed of received beacon frame. CRC bits of NDP frame may be used as the input for the function to compute ACK ID as well if there is enough bit space.
In the following, ACK ID Computation according to various embodiments will be described.
According to various embodiments, ACK ID may be computed for short Ack as the response to NDP type PS-Poll, for example using STA's information:
According to various embodiments, ACK ID may be computed for short Ack as the response to NDP type PS-Poll, using SIG bits of NDP type PS-Poll, based the example in Table 1:
ACK ID may be computed for short Ack as the response to NDP type PS-Poll, using the beacon information:
If the RA field of NDP type PS-Poll is based on the above beacon information, due to limited bit space (e.g. 9 bits) for RA field in SIG, RA bits may be expanded into more bits using the beacon info or combined with CRC bits in SIG of the received frame to form an ACK ID. For example, if the number of ACK ID bits is larger than the number of CRC bits and RA bits of NDP type PS-Poll that are used to construct ACK ID field, ACK ID based on CRC bits may be obtained and expanded RA bits (e.g. (scrambled) partial BSSID or the computation results that is based on partial FCS and scrambling seed of the received beacon frame).
When partial BSSID is used for RA field of NDP type PS-Poll frame, expanded RA bits may be computed using some more extra bits of BSSID other than partial BSSID used in NDP PS-Poll. For example, if partial BSSID uses 9 bits, then expanded RA bits (assuming 12 bits) may be obtained by adding three more BSSID bit into partial BSSID. The method may be applicable to scrambled PBSSID as well, as long as scrambling bits are also expanded and known to both AP and STA.
The method may also be applied to the computation results that are based on partial FCS and scrambling seed of the received beacon frame.
For the ACK ID computation for Option 2 according to various embodiments, the field structure may be shown as in Table 4. If RA field of NDP type PS-Poll is not based on partial FCS and Scrambling Seed of the received beacon frame, which are used for ACK ID computation, AP and STA may have to store the info of partial FCS and Scrambling Seed of the beacon frame or the resulting bits (ACK ID) based on the information. The complexity or the cost of this scheme may be higher than Option 1.
The AP may use some or all the following bits in SIG of NDP type PS-Poll (SIG field structure is assumed as in Table 1) to compute ACK ID in short Ack as the response to the received NDP type PS-Poll sent by STA:
For example, ACK ID may include or may consist of some of RA bits and all TA bits of NDP type frame. For example, 14 bits for ACK ID may be considered. For example, the NDP PS-Poll frame structure as in Table 1 with RA=9-bit PBSSID and TA=9-bit PAID may be assumed:
According to various embodiments, the bit-rotating approach of PBSSID bits based on AID value may be used for ACK ID based on scrambled PBSSID bits of NDP type frame. According to various embodiments, the bit-rotating approach of PBSSID bits based on AID value can be used for ACK ID based on TA bits of NDP type frame and resulting bits based on partial FCS and scramble seed of received beacon frame. According to various embodiments, the bit-rotating approach of PBSSID may be generalized as the indexing method where the index is based on some of known AID bits (all these bit positions should be known to both engaging AP and STA) and there may be an array of NDP PS-Poll RA (PBSSID) bits that are permutated by some bit arrangements that are also known to both AP and STA. In the example shown above, the indexing may use 3-bit PBSSID-LSB and the bit-rotation method may be used so that the complexity is low due to that both AP and STA don't need to remember the array of permutated PBSSID.
In the following, identifying ACK ID that is based on bit-rotation will be described. According to various embodiments, to decode ACK ID, the STA
(1) Set test counter as zero;
(2) Test whether 8-bit ACK ID-MSB matches the RA (8-bit PBSSID-LSB) bits in NDP PS-Poll previously sent and waits for acknowledgement;
(3) If matched, test counter is 3-bit AID-MSB and then go to (7). If not matched, decide whether test counter is 7.
(4) If the test counter is 7, declare ACK ID as invalid and end the decoding.
(5) Otherwise, increase the test counter and go to (6).
(6) Rotate (e.g. right-shift) the 8-bit ACK ID-MSB and go to (2) to continue the test.
(7) Obtain 6-bit PAID-LSB from 6-bit ACK ID-LSB and recover 9-bit PAID from 3-bit PAID-MSB and 6-bit PAID-LSB.
(8) Test whether PAID value is valid. If PAID bits are valid, ACK ID is valid. Otherwise, declare ACK ID as invalid.
CRC bits may be masked (bitwise XOR) with some bits of the identifier for pairing frame exchange (e.g. RA/TA/ACK ID bits), i.e. short response frame that acknowledges NDP type PS-Poll. Some of the identifier may be embedded inside CRC mask bits. CRC bits may be computed same as for Short Ack in but mask with some extra bits that are not in the short response frame SIG.
The indexing method (for example including bit-rotation) may be masked and a CRC mask may be used to generate ACK ID with a shorter length. For example, 14-bit ACK ID (option 4) may be considered and it may be assumed that PAID (partial AID) is used as TA for NDP PS-Poll. 9-bit PBSSID and 5-bit PAID-MSB may be used to construct ACK ID for short response frame SIG, and 4-bit PAID-LSB may be used to mask 4-bit CRC. When STA receives response frame SIG for its NDP PS-Poll, it may unmask CRC with its 4-bit PAID-LSB and compare the result with expected CRC bits that can be computed by the STA according to its NDP PS-Poll SIG being acknowledged. If matched, the short frame may be possible for itself and for further processing.
According to various embodiments, the CRC mask and indexing method may be combined to further relax the requirement on the number of ACK ID bits. 12-bit ACK ID (option 4) may be considered and it may be assumed that PAID is used as TA for NDP PS-Poll. 10-bit PBSSID may be used that is expanded by the AP and may also be known by the STA, and 5-bit PAID-MSB may be used to construct ACK ID for short response frame SIG, and 4-bit PAID-LSB may be used to mask 4-bit CRC. For example:
In the following, an example will be described in which 12-bit ACK ID is acquired through CRC mask and bit-rotation that includes the information of partial AID (PAID). Firstly the AP may construct SIG with the following bits to compute CRC before CRC mask:
To decode the SIG bits, firstly the STA may check type indication and then may unmask 4-bit CRC mask with its own 4-bit PAID-LSB. After unmasking, the STA may compute whether unmask CRC is correct for the SIG bits. If the CRC result is correct, the STA may proceed to decode ACK ID for scrambled PBSSID which is the first 10-bit of ACK ID. It may determine whether the rotated scrambled PBSSID is matched with its own pre-computed scrambled PBSSID after rotating these rotated scrambled PBSSID with the times that is the value of 3rd-5th bits of its own PAID-MSB. For example, if the value of 3rd-5th bits of its own PAID-MSB is 5, then scrambled PBSSID bits may be right-shifted 5 times by STA (while AP should left-shift 5 times scrambled PBSSID bits). If the above matches, the STA may obtain 11th-12th bits of ACK ID and may verify against its own 1st-2nd bits of PAID-MSB. If the above matches, the ACK ID may be correct and the STA consider it has been acknowledged positively.
In the following, Differentiating Short Acks for NDP Type and Non-NDP Type frames according to various embodiments will be described. According to various embodiments, short Acks for NDP type and non-NDP type may be differentiated through the identification bit(s) in SIG.
ACK ID based on the scheme according to various embodiments may be used to identify short Ack frame to reduce the probability of a false short Ack that may be accepted by a transmitter B 506 if
Even if B 506 has a much shorter transmission range than AP1504 and there is no protection for NDP PS-Poll, the probability of exact same ACK ID for NDP type PS-Poll is very low due to the good design of ACK ID.
But the duplication probability of ACK IDs for NDP type and non-NDP type frame may be not low due to the computation methods for these two kinds of ACK ID are different:
(1) Computation of ACK ID in short Ack for the received frame other than NDP type may be based on partial FCS and scrambling seed of received frame.
(2) Computation of ACK ID in short Ack for NDP PS-Poll may be based on partial FCS and scrambling seed of received beacon or RA bits and/or CRC bits of received NDP type PS-Poll frame, as described above.
Further, short Ack for NDP type (PS-Poll) frame may be differentiated from short Ack for non-NDP type frame using some identification bits in SIG so that the probability of confusing other data transmission may be low.
I. Upon receiving NDP type PS-Poll, AP may set the identification bits in short Ack to indicate that the frame is for NDP type PS-Poll, as the response to the PS-Polling STA.
II. Upon receiving short Ack, PS-Polling STA may identify the identification bits that signal the response frame is a short Ack for NDP type frame. It is to be noted that it is assumed the probability of duplicate identifier e.g. ACK ID for NDP type response to NDP type frame is fairly low due to the method for ACK ID computation according to various embodiments.
III. Once AP/STA receives short Ack, in addition to CRC checking, it may proceed with the related protocol as follows:
a. If AP/STA that is involved in the process using NDP type PS-Poll and short Ack receives other AP's short Ack for non-NDP type PS-Poll, it may identify whether it is a short Ack for NDP type frame.
i. If it is a short Ack for non-NDP type frame, AP/STA may discard.
ii. If it is a short Ack for NDP type frame, AP/STA may identify whether it is addressed to itself by using the identifier e.g. ACK ID field and/or other fields to determine whether the short Ack is addressed to it. If it is not addressed to itself, it may discard.
b. If AP/STA that is involved in the process using non-NDP type frame and short Ack receives other AP's short Ack for NDP type PS-Poll, AP/STA may identify whether it is a short Ack for non-NDP type frame.
i. If it is a short Ack for NDP type frame, AP/STA may discard.
ii. If it is a short Ack for non-NDP type frame, AP/STA may identify whether it is addressed to itself by using the identifier e.g. ACK ID field and/or other fields to determine whether the short Ack is addressed to it. If it is not addressed to itself, it may discard.
The method to differentiate short frame (e.g. short Ack) for NDP type and non-NDP type using some SIG bits according to various embodiments may be applied to other short frame similarly, if the design approaches of some of the fields are different.
In the following, Short CTS SIG Design will be described. In a Short CTS, the SIG field may include:
Short CTS may also be used as AP assisted medium synchronization frame, and short CTS frame reserves a time interval for a STA that is scheduled to wake up at the slot boundary (or TWT, i.e. Target Wake Time), with the SIG including RA field i.e. the address of the STA that is scheduled to wake up at the slot boundary.
Short CTS may consider CTS ID to address the receiver. For the case of RTS/CTS, CTS ID may be determined based on Partial FCS and scramble seed information from RTS. For the case of CTS-to-Self, CTS ID may be obtained from partial TA of the transmitter to address both TA and RA. It may be assumed that Short CTS uses RA field to address the receiver. This may create a problem whether we should differentiate the above 3 kinds of short CTS since the duplicate probability of CTS ID may be high.
If CTS ID and RA are unified for the above two cases, then only PAID or partial STA's MAC address is possible, since there may be no preceding frame before AP sends medium synchronization frame. When PAID or partial STA's MAC address is used, the duplicate probability is high due to they are not unique among different APs and there are many STAs that may have the same CTS ID or RA field. Another duplicate case is that CTS ID for CTS-to-self may confuse 3rd party STAs doing RTS/CTS handshaking based on short CTS, when partial TA bits are used as CTS ID that is same as that in short CTS for RTS/CTS handshaking.
Type indication may be provided, wherein one bit (TBD) or some reserved case for a field (e.g. BW (bandwidth)) in SIG is used to differentiate two types of short CTS: short CTS as the medium synchronization frame and short CTS for RTS/CTS handshaking and CTS-to-self. For example, notice that BW=1, 2, 4, 8, 16 MHz, only 3 bits are required. 3 unused cases may occur for 3-bit BW and can use one such unused case to indicate that short CTS is used as the medium synchronization frame. Further, unused case may be used for short CTS used as CTS-to-self. There may be a need to define one field to indicate whether short CTS is from AP. There may be one bit defined to differentiate whether short CTS is from its AP. If the frame is a broadcast synchronization frame (not addressed to a particular STA), we can set DURATION field value as 0.
Two design options for short CTS SIG may be provided as follows.
Option 1 may be as follows: Short CTS is designed only for >=2 MHz. Define the following fields in SIG: RA and TA, in addition to the fields that may include Type Indication, BW, DURATION, CRC, Tail. E.g. RA is 9 bits, TA is 9 bits. We can define one field to indicate whether short CTS is from AP. For AP, when AP responds to the STA's RTS, use PAID as RA and use Partial BSSID or the computation resulting bits based on Partial FCS and scramble seed information from RTS as TA; when AP sends CTS-to-itself, use a reserved PAID (e.g. 0) as RA and use Partial BSSID as TA; when AP responds to the STA with medium synchronization frame, use PAID as RA and use Partial BSSID as TA; when AP broadcasts medium synchronization frame, use reserved PAID e.g. 0 as RA and use Partial BSSID as TA. For STA, when STA responds to AP's RTS, use PAID as TA and use Partial BSSID or the computation resulting bits based on Partial FCS and scramble seed information from RTS as RA; when STA sends CTS-to-itself, use its PAID as TA and use Partial BSSID as RA. The handling of short CTS should include the step to identify whether the frame is from AP and decide whether it is addressed to itself. There may be one bit defined to differentiate whether short CTS is from AP
Option 2 may be as follows: Short CTS is designed such that is same for 1 MHz and >=2 MHz case, by embedding the PAID information into CRC bits and CTS ID. If BW field is not used for medium synchronization frame, re-define 3-bit BW for 3-bit PAID-MSB (1st-3rd bit of PAID). Use bit-shifted PBSSID as CTS ID. Note that bit-shifted PBSSID is the value of PBSSID right or left-shifted X times, where X is the value of 2-bit PAID-MSB (4th and 5th bit of PAID). Mask (bitwise XOR) CRC with 4-bit PAID-LSB (6rd-9th bit of PAID). The above methods of CRC mask and bit-rotation operation have been described above. The handling protocol for CTS ID is similar to that for ACK ID that is based on CRC mask and bit-rotation as described above.
a) When the frame is a broadcast synchronization frame (not addressed to a particular STA), we can set DURATION field value as 0 and set PAID as 0 to compute CTS ID. The approach can be applied to the case of short CTS for CTS-to-self, where the STA/AP will set its partial MAC address as CTS ID and the STA use its PAID to do CRC mask and bit-rotation while the AP use 0 as PAID to do CRC mask and bit-rotation. Note that in these cases, the STA with the same partial MAC address may be required to send non-NDP CTS frame rather than short CTS. This can be done when the STA perform authentication/association or through other frame exchange between AP and STA.
b) When the frame is a synchronization frame addressed to a specified STA, the DURATION field value may be set as the estimated time interval reserved for that STA and use the STA's PAID to compute CTS ID. The approach can be applied to the case of short CTS for RTS/CTS handshaking.
c) The problem with this design is that direct RTS/CTS handshaking between two STAs may not be supported, as PBSSID may mix up with the PAID, if it is unable to tell the difference between two CTS IDs from the STA and the AP respectively. In this case, we can avoid this duplicate case by reserving the PAID value that is same as PBSSID. This reserved PAID value is not assigned to any STA. Alternatively, if AP allocates the PAID value that is identical to PBSSID to a STA, AP should request the STA to send normal CTS rather than NDP short CTS.
In the following, Ack Indication according to various embodiments will be described.
In the following, without causing ambiguity, normal frame may refer to the frame format in the current IEEE 802.11 standard (IEEE 802.11-2012). For example, normal ACK/BA refers to the ACK/BA in the current 802.11 standard.
IEEE 802.11-1137-11-00ah-specification-framework-for-tgah, Mingyong Park, “IEEE 802.11ah Specification Framework” specifies that the SIG shall include 2-bit Ack Indication (00: Ack; 01: BA; 10: No Ack; 11: a frame that is not ACK, BA or CTS) in SIG and the definition of value (b11) for response frame type is used to indicate the presence of a frame that is not ACK, CTS or BA immediately following current transmission.
One of the key issues for 2-bit Ack Indication (assume Ack Indication is the field(s) that are used to indicate the response frame) is that some frame that is currently transmitted may have different response types following it. One example is that PS-Poll may allow a few options such as short Ack, normal ACK with timer indication and active polling response (assume that active polling response is sent immediately after SIFS (Short Interframe Spacing)). Therefore, this kind of frame may incur the difficulties in determining the response type for the Ack Indication at the unintended STAs due to the ambiguity of using the accepted 2-bit Ack Indication. If the STA decides 2-bit Ack Indication for its PS-Poll that is being transmitted, the peer STA (for example the AP in this case) may follow the indication to give the right response type. This may mean that the AP may not have the freedom to decide which type of response frame it can send as the reply. It is to be noted that polling response has to be of fixed size in order to make the unintended STA set the NAV (network allocation vector) or deferred channel access time correctly without ambiguity.
The process of determining the response type when there are multiple options could be either that the AP broadcasts its capability of handling the response types if there are multiple options in the beacon frame or negotiates with the STAs through some management frames e.g. authentication/association frames. After that, the STA may follow the decision made earlier to send the frame with the indicated response type. Upon receiving the frame with the response type indication, the AP may respond according to the type without ambiguity.
The key issue may be that the draft specification does not include enough options to support all these different response types. As only short Ack, normal BA, no Ack and long response other than ACK, BA and CTS are supported in 2-bit Ack Indication, when both short Ack/short BA and normal ACK/normal BA are used in the network or different networks, an issue may be encountered on how to set a proper network allocation vector (NAV) or deferred channel access time for the unintended STA, namely 3rd party STA.
NAV may be an indicator, maintained by each STA, of time periods when transmission onto the wireless medium (WM) is not initiated by the STA regardless of whether the STA's clear channel assessment (CCA) function senses that the WM is busy. The current 802.11 standard may set up some protection mechanism which attempts to update the NAV of all receiving STAs prior to the transmission of a frame that might or might not be detected as valid network activity by the PHY (physical, for example physical layer) entities at those receiving STAs.
In the current IEEE 802.11 standard, a STA that receives at least one valid frame within a received PSDU may update its NAV with the information from any valid Duration field within that PSDU for all frames where the new NAV value is greater than the current one, except for those where the RA is equal to the MAC address of the STA.
As shown in
An unintended STA that detects the SIG correctly shall defer transmission until after the expected response (if present). As the data rate of the response frame is usually the same as that of the frame that elicited the response, if the frame size of response frame is known, the 3rd party STA is able to defer its channel access according to the Ack Indication field of the received frame. For the case of the response frame that is short frame such as short Ack and short BA, the duration for deferred channel access at the 3rd party STA is fixed and the same for the same channel bandwidth. For the case of the response frame that is normal frame such as normal ACK and normal BA, the duration for deferred channel access can be calculated based on the ACK(14 bytes)/BA length (32 bytes) and expected transmission rate (equivalent to the data transmission rate), which is usually the same as the frame that elicited the response. The expected data rate is dependent on the preamble type (1M Hz or >=2M Hz) and MCS (Modulation and Coding Scheme) of the received frame etc. For the case of Ack Indication set to No Response, the deferred channel access time is zero (the STA may start the transmission SIFS time after the response frame with a necessary backoff).
The general protocol/procedure for handling Ack Indication can be summarized as follows:
o) If a short frame is used, its duration is fixed.
o) If a normal frame is used, the duration can be calculated based on the length (e.g. the length of BA is 32 bytes) and expected transmission rate (equivalent to the data transmission rate).
o) If the response type is not ACK, BA or CTS, the duration can be regarded as (aPPDUMaxTime+2*aSIFSTime+aPHY-RX-START-Delay), as shown in the case of speed frame exchange.
Including 2-bit Ack Indication (00: short Ack/short BA; 01: normal BA; 10: No Ack; 11: a frame that is not ACK, BA or CTS) in SIG may not be sufficient to support different options for the response type to PS-Poll. If the response to PS-Poll is short Ack or polling response, we can set 2-bit Ack Indication in the SIG of PS-Poll as the value b00 and b11 respectively.
If normal ACK has the same length as polling response, we can define 2-bit Ack Indication (00: short Ack/short BA; 01: polling response/normal ACK; 10: No Ack; 11: a frame that is not ACK, BA, CTS and polling response). Normal BA is used only in TXOP, where the value b11 can be used to indicate.
The solution to solve the problem of insufficient bits for Ack Indication or ambiguity caused by 2-bit Ack Indication can combine the techniques or the steps in various embodiments.
There may be several advantages for the design according to various embodiments. The Ack indication according to various embodiments may provide sufficient protection against hidden terminals (to the intended receiving STA) and prevents unintended STAs from waiting for EIFS when no Ack is required. SIG may be more reliable than MAC header. The Ack indication may be quickly verified by SIG CRC (it is not required to decode the whole MPDU (MAC protocol data unit)).
When only four choices (including short Ack and normal BA (block acknowledgement)) are considered, the 2-bit Ack Indication may achieve the goal. But since short BA may also be accepted, it may be likely that both short BA and normal BA will be used. It may also be noted that the introducing of short ACK cannot exclude the use of normal ACK in some cases such as speed frame exchange, for example as described in IEEE 802.11-1137-11-00ah-specification-framework-for-tgah. The draft specification may include the concept of speed frame exchange based on the use of More Data field and 2-bit Ack Indication (b11) that indicates the presence of the frame immediately following current transmission (The meaning of “immediately following current transmission” may be that the following frame transmission occurs immediately after SIFS, which is the allowed shortest inter-frame space, rather than DIFS). This may mean that normal ACK may be used for speed frame exchange, as short Ack doesn't have 2-bit Ack Indication.
The unintended STA that can decode SIG and MAC header correctly can set its NAV or deferred channel access time to (aPPDUMaxTime+2*aSIFSTime+aPHY-RX-START-Delay) if a data frame is used as the response frame immediately after the previous data frame which carries the 2-bit Ack Indication value as b11. However, for the unintended STA that can decode SIG correctly but decode MAC header wrongly, it is not able to identify whether there will be a frame of either normal ACK or short ACK immediately following current transmission. Upon receipt, the unintended STA can set its NAV or deferred channel access time to a duration corresponding to a short Ack or normal ACK if a frame is used as the response frame immediately after the previous data frame which carries the 2-bit Ack Indication value as b00. For the case of short ACK, NAV or deferred channel access time can be set as (short ACK duration+2*aSIFSTime+aPHY-RX-START-Delay). For the case of normal ACK, NAV or deferred channel access time can be set as (normal ACK duration+2*aSIFSTime+aPHY-RX-START-Delay). In the above both cases, the unintended STA cannot identify whether there will be a normal ACK or short Ack immediately following current transmission based on 2-bit Ack Indication, which is used to represent both short Ack and normal ACK. It is to be noted that short frame/normal frame duration (e.g. short Ack/normal ACK duration) refers to transmission time of short frame/normal frame.
Due to that normal ACK and short BA may be used as well, an unintended STA, after receiving and decoding SIG correctly, may not be able to calculate the accurate response duration by the response type and/or the expected response transmission rate. This issue may be solved.
As normal ACK and normal CTS have the same size, the value of 2-bit Ack Indication used to indicate for normal ACK can be also used for normal CTS. This can be applied to poll response if it has the same size as that of normal ACK.
When short frame (STF+LTF1+SIG only, without MAC header, namely NDP frame, e.g. short Ack) is used, if the type of the frame immediately following short frame is indicated in short frame, 2-bit Ack Indication protocol may be applied to the Access Point (AP) and STA.
According to various embodiments, Ack Indication may be provided to remove the ambiguity, like will be described in more detail below.
According to various embodiments, processing as will be described in the following may be provided. Currently, there may be 4 reserved bits in SIG. One reserved bit (defined as Immediate Following Frame Indication, i.e. IFFI) may be used to instruct the intended STA that a short frame (e.g. short Ack/short BA) shall be used immediately following current transmission, where IFFI=0 indicates a short frame (e.g. short Ack/short BA) immediately following current transmission and IFFI=1 indicates a normal frame (e.g. normal Ack/normal BA) immediately following current transmission. We can include 2-bit Ack Indication for four options e.g. 00: Ack; 01: BA; 10: No Ack; 11: a frame that is not ACK, BA or CTS.
According to various embodiments, processing as will be described in the following may be provided. According to various embodiments, it may not be required to change current draft specification for the definition of 2-bit Ack Indication but a rule may be set on how to set the NAV or deferred channel access time for 3rd party STA i.e. the unintended STA: upon decoding 2-bit Ack Indication correctly, 3rd party STA shall set NAV or deferred channel access time to the duration corresponding to that for normal frame (e.g. normal ACK, which has a frame size larger than NDP ACK) although channel access time is wasted in this case. 3rd party STA can set its NAV or deferred channel access time based on the length of normal frame (e.g. the length of ACK is 14 bytes) and expected transmission rate (equivalent to the data transmission rate). However, Ack Indication becomes not very useful as the NAV or deferred channel access time is set as (ACKTxTime+2*aSIFSTime+aPHY-RX-START-Delay) upon receiving current transmission, which is a bit better than that via EIFS protection rule, where EIFS=aSIFSTime+DIFS+ACKTxTime. It is to be noted that those unintended STAs that want the more efficient channel access have to continue to receive the immediate frame following current transmission and it is obvious that they cannot benefit from the NAV or deferred channel access time setting rule.
According to various embodiments, processing as will be described in the following may be provided. According to various embodiments, it may not be required to change the current draft specification for the definition of 2-bit Ack Indication but a rule may be set on how to set the NAV or deferred channel access time for 3rd party STA. Upon decoding 2-bit Ack Indication correctly, 3rd party STA shall set NAV or deferred channel access time to the duration corresponding to short frame (e.g. short ACK duration+2*SIFSTime+aPHY-RX-START-Delay) and should continue to receive the next frame immediately following the current transmission (in this case STA consumes more power but channel access time is improved, early Ack indication becomes not effective). This suggests that 3rd party STA may have to receive the SIG of the immediately following frame; otherwise, when normal ACK is used, the unintended STA that starts to sense the channel after the duration equal to the value of NAV or deferred channel access time is not able to decode normal ACK so that they may have to apply EIFS to set NAV. Once the SIG of the frame (e.g. either normal ACK or short Ack) immediately following current transmission is received, 3rd party STA can set its NAV or deferred channel access time correctly by checking whether the frame is normal frame, and if the frame is short frame, it can set the NAV or deferred channel access time by looking into Length/Duration and MCS in SIG; otherwise it is straightforward to know the fixed duration of NDP frame.
According to various embodiments, processing as will be described in the following may be provided. According to various embodiments, 2-bit Ack Indication may be re-designed, i.e. 3-bit Ack Indication may be used instead. Various embodiments may include 3-bit Ack Indication (e.g. 000: short frame e.g. short Ack/BA/CTS; 001: normal Ack/CTS; 010: normal BA; 011: No Ack; 100: Polling response; 101: a frame that is not ACK, BA, CTS and Polling response; 110-111 Reserved) in SIG so that the presence of response frame type (e.g. normal frame or short frame) immediately following current transmission can be easily identified without ambiguity.
Alternatively if a unified frame format for normal ACK and polling response, which have the same length, may be provided, 3-bit Ack Indication (e.g. 000: short frame e.g. short Ack/BA/CTS; 001: normal Ack/CTS/Polling Response; 010: normal BA; 011: No Ack; 100: a frame that is not ACK, BA, CTS and Polling response; 101-111 Reserved) may be included.
According to various embodiments, processing as will be described in the following may be provided. According to various embodiments, 2-bit Ack Indication may be re-designed, i.e. include 2-bit Ack Indication (00: short frame e.g. short Ack/short BA/short CTS; 01: normal Ack; 10: No Ack; 11: a frame that is not ACK, BA or CTS) in SIG, by combining the indication for short Ack/short BA and excluding the use of normal BA (but we can allow to use normal BA in TXOP (Transmit Opportunity) where the preceding frame immediately followed with normal BA should set Ack Indication to b11, for example when normal BA is not with a fixed length or is transmitted with a rate different from the received frame that elicited the response).
In the following, a method for fast frame forwarding according to various embodiments will be described.
In the current IEEE 802.11 standard, when the data packets are long, the RTS/CTS messages may be used to reserve the media for transmission. However, it is performed within one hop.
When relay is introduced, if the current design is used, two RTS/CTS transactions may be required. The overhead could be heavy and it may also lower down the media transmission efficiency. According to various embodiments, various RTS/CTS message exchange methods are provided to protect two-hop transmissions that involves relay.
For example, and without loss of generality, it may be assumed that the STA is two hops away from the AP.
According to various embodiments, processing as will be described in the following may be provided. One of the relaying scenarios considered in the 802.11ah standard is that both AP and station can hear each other. However, to save transmission power of STA, a relay station may be used by STA for uplink data forwarding. In such scenario, the STA may send RTS to AP directly but the reserve media duration includes both transmission durations required by STA and relay. After receiving the CTS from AP, waiting for a short duration such SIFS, STA started to transmit data packet to relay, with relay indication in the data frame, either in the MAC frame control header or in the SIG. Relay may forward the packet to AP using the reserved channel time by STA using the RTS/CTS.
When the relay station receives RTS from STA, it may check the TA and RA field of the RTS and know whether the STA is served by the relay at the moment.
The STA may use some bits in the SIG/FC to indicate whether frame forwarding time required by relay is included in the RTS duration. If time is included, the relay station of the STA which sends the RTS shall update its NAV and also aware that it is required to use the reserved media to forward data frame from STA to AP if CTS is sent out by the AP to confirm the media reservation. It may not be allowed to use the reserved time to transmit frames other than the frame from STA that shall be forwarded to the AP later.
The relay station may verify whether the CTS received is the one replied to the RTS send by its subordinate STA. If CTS is a full CTS, the relay can derive the CTS is for the RTS sent by its subordinate STA earlier. If CTS is a short CTS, the station shall verify the CTS ID in short CTS to determine whether it is the one reply to the RTS from its STA.
According to various embodiments, processing as will be described in the following may be provided. The STA sends RTS to the relay and the relay further send an RTS to AP. For example, after receiving RTS from relay, AP reply with CTS to relay and relay further send CTS to STA. Most of the fields such as source and destination address, or CTS ID (when short CTS is used) can be reused. One bit in the RTS from STA to relay may indicate that a relaying of RTS may happen. The destination address in the RTS can be either the MAC address of relay or the MAC address of the AP. The source address in the RTS from relay to AP may be the MAC address of relay or the MAC address of STA. When short CTS is used, for the CTS from AP to STA, a relay bit may be set so that relay station will send the CTS to STA.
According to various embodiments, processing as will be described in the following may be provided. In case STA can hear from AP directly, RTS/CTS procedure defined as described in the following may be used. The STA may send RTS to relay first and relay may send a second RTS to AP. After receiving RTS from relay stations, the AP may send CTS to media. After receiving the CTS, the STA may send data over the reserved media.
According to various embodiments, processing as will be described in the following may be provided. In case STA can hear from AP directly, the RTS/CTS procedure defined as described in the following may also be used. STA may send RTS to relay first and relay may send CTS with relay bit to AP. After receiving CTS from Relay stations, AP may send CTS message to media. The CTS sent by the AP can be the same one as received from relay. After receiving the CTS, the STA can send data over the reserved media.
To realize the above described embodiments, it may be necessary to define one Relay bit or indication in RTS SIG/Frame Control field in MAC header to indicate that this RTS is required to be relayed to AP or being replied by Relay e.g. with (short)CTS.
The CTS sent can be a short CTS or other format with transmitted address and receiver address. Ack Indication in RTS (from STA to Relay) SIG may be set to a specified value e.g. b00 (indicating a short CTS frame is the immediate response).
For short CTS from Relay to AP, one IRFI (Immediate Response Frame Indication; the function may be similar to ACK Indication or IFFI) field may be defined to indicate where there will be a short frame following Short CTS. IRFI=0 may indicate there will be a short frame (e.g. short CTS) following Short CTS. IRFI=1 indicates there will be a Data frame (non-NDP) following Short CTS. For CTS from relay to AP, IRFI is set to 0. Duration is set to the Duration field value in RTS-SIFS-Short CTS duration. CTS ID may be based on the scrambling seed and FCS of received RTS and/or STA's AID and/or Partial BSSID or AID of Relay as well as AP's BSSID. For example, bitwise XOR operation on the computation results of the scrambling seed and FCS of received RTS, partial BSSID of Relay and partial BSSID of AP can create CTS ID carrying three parties' information.
Once STA receives Short CTS (sent by Relay), if IRFI=0, STA may defer channel access after SIFS+Short CTS Duration. Once AP receives Short CTS (sent by Relay) and if IRFI=0 and CTS ID is matched, AP will send short CTS.
For Short CTS from AP to Relay/STA, IRFI may be set to 1 and Duration may be extended according to its knowledge on the data rate between AP and Relay.
In the following, response frame indication in SIG and speed frame exchange using short Ack according to various embodiments will be described.
The draft specification IEEE 802.11-1137-11-00ah-specification-framework-for-tgah, Mingyong Park, “IEEE 802.11ah Specification Framework” includes 2-bit Ack Indication (00: Ack; 01: BA; 10: No Ack; 11: a frame that is not ACK, BA or CTS) in SIG. The definition of value (b11) response frame type may indicate the presence of a frame that is not ACK, CTS or BA following current transmission.
According to various embodiments, modification for the above may be provided. For example, Ack Indication for Short Ack can be used for other NDP frames as they have the same size for same Bandwidth, and Ack Indication for ACK can be used for CTS (CTS has the same size as ACK). However, an issue may be encountered on how to set a proper Ack indication and NAV (defer channel access) when both short Ack/BA and normal ACK/BA are possible to be used in the networks. When only short Ack and BA are used, the use of 2-bit Ack Indication in the draft specification can achieve the goal. The draft specification considers only normal BA. Since short BA is accepted in the draft specification, it is likely that both short BA and normal BA will be used. The design of short ACK can't exclude the use of normal ACK in some cases such as speed frame exchange. Due to that normal ACK and BA may be used as well, an unintended STA when receiving and decoding SIG correctly may not be able to calculate the accurate response duration by the response type and/or the expected response transmission rate.
According to various embodiments, various options may be provided, like will be described in more detail below.
According to various embodiments, an option which may be referred to as Option A may be provided as follows: 2-bit Ack Indication may be included in SIG to indicate the following frame type/size:
According to various embodiments, an option which may be referred to as Option B may be provided as follows: Include 2-bit Ack Indication in SIG to indicate the following frame type/size:
According to various embodiments, an option which may be referred to as Option C may be provided as follow: Use 3-bit Ack Indication:
According to various embodiments, an option which may be referred to as Option D may be provided as follows. Various embodiments do not require to change current draft specification for the definition of 2-bit Ack Indication but we need to set a rule on how to set the NAV or deferred channel access time for 3rd party STA i.e. the unintended STA: upon decoding 2-bit Ack Indication for normal frame such as ACK correctly, 3rd party STA shall set NAV or deferred channel access time to the duration corresponding to that for normal frame (e.g. normal ACK, which has a frame size larger than NDP ACK) although channel access time is wasted in this case. 3rd party STA can set its NAV or deferred channel access time based on the length of normal frame (e.g. the length of ACK is 14 bytes) and expected transmission rate (equivalent to the data transmission rate). However, Ack Indication becomes not very useful as the NAV or deferred channel access time is set as (ACK duration+aSIFSTime) upon receiving current transmission, which is a bit better than that via EIFS protection rule, where EIFS=aSIFSTime+DIFS+ACK duration. It is to be noted that those unintended STAs that want the more efficient channel access have to continue to receive the immediate frame following current transmission and it is obvious that they cannot benefit from the NAV or deferred channel access time setting rule.
According to various embodiments, an option which may be referred to as Option E may be provided as follows. Various embodiments do not require to change the current draft specification for the definition of 2-bit Ack Indication but we need to set a rule on how to set the NAV or deferred channel access time for 3rd party STA. Upon decoding 2-bit Ack Indication for normal frame such as normal ACK correctly, 3rd party STA shall set NAV or deferred channel access time to the duration corresponding to short frame (e.g. short ACK duration+SIFSTime) and should continue to receive the next frame immediately following the current transmission (in this case STA consumes more power but channel access time is improved, early Ack indication becomes not effective). This suggests that 3rd party STA may have to receive the SIG of the immediately following frame; otherwise, when normal ACK is used, the unintended STA that starts to sense the channel after the duration equal to the value of NAV or deferred channel access time is not able to decode normal ACK so that they may have to apply EIFS to set NAV. Once the SIG of the frame (e.g. either normal ACK or short Ack) immediately following current transmission is received, 3rd party STA can set its NAV or deferred channel access time correctly by checking whether the frame is normal frame, and if the frame is short frame, it can set the NAV or deferred channel access time by looking into Length/Duration and MCS in SIG; otherwise it is straightforward to know the fixed duration of NDP frame.
In the following, handling Ack indication according to various embodiments will be described:
3rd party STA may set its NAV (defer channel access) upon receiving Ack Indication in SIG:
In the following, speed frame exchange using short Ack according to various embodiments will be described. According to various embodiments, an approach based on NDP frames for speed frame exchange may be provided. The current problem for speed frame exchange may be that NDP frames such as short Ack reloads 2-bit Ack Indication.
According to various embodiments, as a first option, the duration field in Short Ack SIG may be set to indicate whether there will be data frame following current transmission:
According to various embodiments, as a second option, if a duration field in Short Ack SIG (for NDP PS-Poll) is not defined or allowed to be used, one available bit (Immediate Response Frame Indication, IRFI) may be defined to indicate whether there will be data frame following current transmission.
According to various embodiments, as a third option, if both duration and IRFI fields are available, the following may be applied:
According to various embodiments, as a fourth option, 2-bit Ack Indication may be defined (or may not be reloaded).
Uplink data indication or MoreData bit may be used indicate uplink buffered data and can be used as the first frame for speed frame change. According to various embodiments, uplink data indication or MoreData bit may be used to indicate whether there is uplink data in PS-Poll which can be used as the first frame for speed frame change.
According to various embodiments, setting NAV or deferred channel access time to defer channel access may be provided as will be described in the following.
According to various embodiments: in the first option, if IRFI is not defined:
According to various embodiments, in the second option, if IRFI is defined, the duration field may not be used and the following may apply:
According to various embodiments, in the third option, the following may apply:
According to various embodiments, in the fourth option, the duration field may not be required.
According to various embodiments, channel access upon receipt of short Ack may be provided as described in the following.
According to various embodiments, in the first option, a 3rd party STA may defer channel access after the period of time=(equal to) DURATION field value in Short Ack SIG upon receiving Short Ack.
According to various embodiments, in the second option, the 3rd party STA may defer channel access after aPPDUMaxTime+aSIFSTime upon receiving Short Ack with IRFI=1, or start channel access immediately for the case of IRFI=0.
According to various embodiments, in the third option, the 3rd party STA may defer channel access after the period of time=(equal to) DURATION field value in Short Ack SIG upon receiving Short Ack with IRFI=1, or start channel access immediately for the case of IRFI=0.
According to various embodiments, in the fourth option, the same as that in speed frame exchange using normal ACK may be applied.
According to various embodiments, other NDP frame as the response frame may include the fields of More Data and IRFI. The procedure using this kind of NDP CTS may be similar to that for using short Ack.
In the following, enhancement to TXOP sharing for two-hop relay according to various embodiments will be described.
When there is an upper limit of TXOP time, if the duration that is larger than this upper limit can be used as reserved cases as well. For the duration that is smaller than the smallest possible value (e.g. SIFS or SIFS+NDP ACK) can be used as reserved cases. Thus, the reserved cases of Duration field that are used for equivalent ACK Indication are indicated by the most or least significant bits of Duration field.
In another embodiment for equivalent ACK Indication, we can make use of the following reserved values to indicate equivalent ACK Indication for No Response and Long Response with unknown duration for early ACK indication. For example, Duration Indication=0 and Duration=0 indicates the equivalent ACK Indication of No Response and Duration Indication=1 and Duration=0 indicates the equivalent ACK Indication of Long Response with unknown duration.
In this case, the least significant bit of Duration is reserved for equivalent ACK Indication.
The reserved values that are smaller than or equal to floor(SIFS/TU) (where floor(x) is the floor function, indicating the largest integer not greater than x)) can be used to indicate other cases e.g. the following response frame is CTS (CTS-to-self). The reserved case may be extended to the duration that is smaller than (SIFS+NDP ACK)/TU, as the shortest frame length is NDP frame and SIFS is the shortest inter-frame space. For example of 1 MHz, if NDP frame is 6 OFDM symbols and each OFDM symbol is 40 microsecond, the shortest frame duration is 560 microsecond (taking into account the preamble which is 320 microsecond). Thus, if TU is 160 microseconds, we have four reserved cases 0, 1, 2 and 3. If (SIFS+NDP ACK)/TU is round up, we can have one more reserved value which is 4. In this case, the 2 least significant bit of Duration is reserved for equivalent ACK Indication when Duration Indication is set to 1.
In addition to the above embodiment for equivalent ACK Indication, we can also reverse the values of Duration field that are smaller than a minimum wakeup timer value and use them to indicate the equivalent ACK Indication. For example, if minimum wakeup timer is at least 2 with a time unit TU e.g. 1 millisecond, we can reserve the case of Duration=1 and Duration=1 as well to indicate e.g. the following immediate response frame is CF-End. In this case, the least significant bit of Duration is reserved for equivalent ACK Indication when Duration Indication is set to 1.
According to various embodiments, methods and devices may be provided wherein after AP transmits DATA to the RELAY and receipt of ACK (Duration field is set to X) from the RELAY, the AP removes frame from buffer and defers before next event a time of (X*TU-ACK-SIFS) where TU is time unit for Duration field of ACK and ACK indicates ACK frame duration time before next event. If NDP ACK/Modified ACK is used, the deferred time is the Duration field value of the transmitted DATA-NDP ACK-SIFS. If DATA is a baseline (802.11-2012) frame format with Duration/ID field, the Duration field setting in AP for DATA frame is based on the data rate between AP and RELAY as well as RELAY and STA. X may also be set according to DATA transmission time between RELAY and STA for the relayed DATA frame+ACK+2*SIFS. The similar approach may be applied to NDP ACK/Modified ACK. This change may improve the accuracy of NAV setting or deferred channel access time for the STA. The unintended STA is able to set an accurate NAV or deferred channel access time so that it may be able to save the power further. The above method is also valid for uplink TXOP sharing for two-hop relay.
If DATA is without Duration field (e.g. DATA is with a short MAC header) but with LENGTH/DURATION in PHY SIG field, the LENGTH/DURATION in SIG field and data rate between RELAY and the intended receiver can be used to determine the Duration field value of ACK sent by RELAY. In downlink TXOP sharing for two-hop relay, after AP transmits DATA to the RELAY and receipt of ACK (Duration field is set to X) from the RELAY, AP removes frame from buffer and defers before next event for a time of (X*TU-ACK-SIFS) where TU is time unit for Duration field of ACK and ACK indicates ACK frame duration time. If NDP ACK/Modified ACK is used, the deferred time is the Duration field value of the transmitted DATA-NDP ACK-SIFS. The Duration field setting in RELAY for ACK is based on the data rate between RELAY and STA and the information on LENGTH/DURATION in PHY SIG fields. X should be set according to DATA transmission time between RELAY and STA for the relayed DATA frame+ACK+2*SIFS. The similar approach applies to NDP ACK/Modified ACK.
In the following expressions for the duration, without causing ambiguity, we can denote the duration for the transmission of maximum size of PPDU i.e. aPPDUMaxTime by MAX_PPDU, the duration for the transmission of ACK frame by ACK and aSIFSTime by SIFS.
For speed frame exchange based on NDP ACK as described herein, since Duration field is available for NDP ACK/Modified ACK, we can (1) set Duration Indication field to 0 which means the Duration field is used for the duration for frame transmission and Duration field is used to indicate the channel access reservation time for the transmission following current NDP ACK/modified ACK, e.g. to indicate there will be an immediate frame following NDP ACK. If the frame duration is known from immediate previous frame, Duration field for NDP ACK is set to (the corresponding duration indicated in the immediate previous frame-NDP ACK-SIFS)/TU (TU is the time unit for Duration field when Duration Indication=0). If the frame duration is unknown, Duration field is set to SIFS/TU (i.e. an equivalent value based on Time Unit for Duration field) in NDP ACK/modified ACK. A Duration field value corresponding to the duration of SIFS (or a non-zero value smaller than SIFS) has a special meaning here. It is indicated that there will be an immediate following frame (SIFS after current NDP ACK/Modified ACK). To know the exact transmission, the unintended STA has to listen to the immediate next frame or defer channel access for NDP ACK+2*SIFS after receiving the frame that elicited the NDP ACK frame. A Duration field value of 0 means there is no immediate following frame. (2) Duration Indication field is set to 1 which means a wakeup timer and there is no immediate frame following current NDP ACK/Modified ACK, and Duration field is set to the sleep duration for the STA being acknowledged.
3rd party STA upon receiving Short Ack/modified short Ack:
If Duration field (or Duration bits that can be unmasked from other fields in NDP ACK/Modified ACK) is available for short Ack/modified short Ack, we can let
o) Duration=0 is equivalent to No Response (equivalent to Ack Indication bits=10);
o) Duration=SIFS/TU is equivalent to Long Response with unknown length/duration (equivalent to Ack Indication bits=11), suitable for DATA without Duration field; Long Response means the response data unit is a data frame;
o) Duration>SIFS/TU is equivalent to long Response with known length/duration (Ack Indication bits=11) indicates channel access reservation time for the transmissions following current short Ack/modified short Ack, suitable for DATA with Duration field;
o) Duration=0 is equivalent to No sleep time;
o) Duration>0 indicates a wakeup timer.
The reason why we can set Duration Indication to 0 and Duration to a value<=SIFS/TU to indicate the equivalent indication of Ack Indication bits set to 11 (long response with unknown duration) is that the STA is only allowed to access the channel after SIFS upon receiving the frame such as NDP ACK or ACK. Thus, any value smaller or equal to SIFS/TU is not meaningful to the receiving STA or not allowed in the baseline (IEEE 802.11-2012). We can reserve all these values to represent the special indication. For example, if SIFS=4*TU, any value of 1, 2, 3 and 4 can be used to indicate the equivalent indication of Ack Indication bits set to 11.
Table 7 shows the usage of Duration Indication and Duration fields for NDP ACK/Modified ACK, illustrating the equivalent indication of ACK Indication bits based on the Duration Indication and Duration fields of NDP ACK. The NDP (Modified) ACK frame with the reserved value for the Duration field that is smaller than SIFS/TU can be used to indicate other NDP frames (e.g. when Duration Indication is set to 0). When SIFS is 160 millisecond and TU is 40 millisecond, there are at least 3 reserved values (1,2,3) that can be used to indicate other NDP frames. For example, a NDP (Modified) ACK with the Duration Indication field set to 0 and the Duration field set to 1 can be used to indicate a null data packet of CF-End that is used to truncate the TXOP. In this case, ACK ID of this NDP frame can be computed as if the transmitter were the intended recipient. Alternatively, ACK ID of this NDP frame can be computed based on the partial AID (PAID) of the transmitter STA or the partial BSSID of the AP with which the transmitter STA is associated. The intended receiver should regard this special NDP frame as the truncation of the current TXOP. 3rd party STA should regard this special NDP frame as a CF-End frame.
In the example shown in
In the above uplink TXOP sharing for two-hop relay with Explicit ACK, RELAY may have the buffered frame to transmit or retransmit before STA sends DATA for it to relay to AP. Based on buffered frame status, RELAY may decide to respond to DATA by ACK with ACK Indication bits set to 10 (no response) or NDP ACK with Duration Indication set to 0 and Duration set to 0, which means no TXOP sharing for two-hop relay. Upon receipt of the above ACK or NDP ACK, AP may select other STAs in the earlier Relay discovery procedure as the RELAY candidates for the STA and send the unsolicited relay selection request to the STA. Once the STA picks the RELAY, the procedure could be similar to the path setup request for the current RELAY. In this situation, RELAY may send its frame other than DATA that was just received from STA. If RELAY wants to relay the DATA to AP immediately, it can follow the abovementioned steps in the previous paragraph and store its backoff state for its buffered frames before relaying the DATA from the STA. The approach is also valid for uplink TXOP sharing for two-hop relay with Implicit ACK and downlink TXOP sharing for two-hop relay with Explicit/Implicit ACK.
In the following, a relay protocol according to various embodiments will be described.
In the following, relay flow control according to various embodiments will be described.
To suspend frame transmissions to Relay, a Relay may send a unicast or broadcast Relay Flow Suspend action frame, and Suspend Duration>0.
To restart frame transmissions to Relay, a Relay may send a unicast or broadcast Relay Flow Resume action frame.
In R.4.5.C of IEEE 802.11-1137-15-00ah-specification-framework-for-tgah, Mingyong Park, “IEEE 802.11ah Specification Framework” (which may be referred to as the “draft specification” herein), the draft specification may define a flow control mechanism at the relay.
When a Relay receives a valid frame, the Relay may respond with:
An ACK after SIFS with Relayed Frame bit set to 0, and does not continue to use the remaining TXOP.
A relay may set Relayed Frame bit to 1 only if it has received a More Data bit set to 0.
The above may be provided for relay flow control and TXOP sharing for two-hop Relay.
According to various embodiments, the Duration Indication and Duration field of NDP ACK issued by the Relay upon receiving the frame to be relayed may be redefined, i.e. Duration Indication=(equal to) 1 may indicate the Duration subfield value equal to a Suspend Duration in the response NDP ACK frame issued by the Relay. This definition implies that Duration for NAV setting is 0 or deferred channel access for the STA receiving the NDP ACK frame with a Suspend Duration indication.
To suspend frame transmissions to Relay, a Relay may send a unicast or broadcast NDP ACK, by setting Duration Indication to 1 to indicate a valid non-zero Suspend Duration that is indicated by the Duration field of NDP ACK, STAs shall not transmit data frames to the STA with the matching ACK ID for the amount of time indicated in Duration field of NDP ACK. STAs may resume normal procedure for data frame transmission when the amount of time as indicated in Duration field of NDP ACK has expired.
To restart frame transmissions to Relay, a Relay may send a unicast or broadcast NDP ACK, by setting Duration Indication=0 to indicate a Resume Normal Procedure Action can be done, STAs may start to transmit data frames to the STA with the matching ACK ID.
According to various embodiments, an equivalent broadcast address for NDP ACK may be defined, for example ACK ID=all 1's or all 0's or a reserved case defined as broadcast address. ACK ID could be set to the value of partial BSSID for the broadcast, with other fields or an indication to indicate the NDP ACK is a broadcast frame.
If the ACK ID computation results are identical to the broadcast address for NDP ACK, there is an ambiguity on whether the responding NDP ACK frame is for the frame to be relayed.
The Relayed Frame field of NDP ACK may be set to 1 to differentiate the following two cases (Alternatively, the Relay may determine whether it is the recipient STA of the received frame by checking the information (e.g. Address 1 and/or Address 2) in the MAC header):
NDP ACK includes Duration Indication and Duration field. The usage of the Duration Indication and Duration fields of NDP ACK may be defined for the Relay flow control when Relayed Frame field of NDP ACK is set to 1: Duration Indication=1 indicates a Suspend Duration in the response NDP ACK frame by the Relay. To suspend frame transmissions to Relay, a Relay may send a NDP ACK, by setting both Relayed frame and Duration Indication fields to 1 to indicate a valid non-zero Suspend Duration that is indicated by the Duration field of NDP ACK, the STA may not transmit data frames to the Relay or the amount of time indicated in Duration field of NDP ACK. The STA may resume normal procedure for data frame transmission when the amount of time as indicated in Duration field of NDP ACK has expired.
Flow Control may be extended to a general case of data frame transmission between two STAs. Flow Control field may be included in NDP ACK frame. Upon receiving the data frame, the responding STA may set the both Flow Control and Duration Indication fields to 1 and the Duration subfield to a nonzero value equal to Flow Suspend duration in the response frame NDP ACK to indicate the Flow Suspend duration such that the STA that elicited the response frame is not allowed to transmit to the responding STA. If Relayed Frame field is set to 1, the responding STA is a Relay; otherwise the responding STA is a non-Relay STA.
The alternative option to implement the flow control may be as follows:
Upon receiving the data frame, the responding STA may set the Duration Indication field to 1 and the Duration field to a reserved value for the indication of the response frame of being FLOW SUSPEND in the response frame NDP ACK to indicate the inactivity duration during which the STA that elicited the response frame is not allowed to transmit to responding STA. The FLOW SUSPEND frame is transmitted SIFS after receiving NDP ACK by the STA which elicited the response frame. An advantage of this embodiment is that the responding STA will send out the FLOW SUSPEND frame SIFS after it transmits NDP ACK. In this case, the responding STA is not required to contend the channel access DIFS and if necessary, some back-off time after transmitting the response frame, which reduces the waiting time of the STA which elicited the response frame. It is to be noted that the STA eliciting the response frame may go to sleep without receiving the flow control signaling if the responding STA does not indicate in the preceding frame exchange.
In the following, TXOP sharing for two-hop relay according to various embodiments will be described.
According to various embodiments, devices and methods may be provided wherein after AP transmits DATA to the RELAY and receives ACK (Duration field is set to X) from the RELAY, AP removes frame from buffer and defers before next event a time of (X*TU-ACK-SIFS) where TU is time unit for Duration field of ACK and ACK indicates ACK frame duration time before next event, or until a valid PHY-RXSTART.indication, whichever comes first. If NDP ACK/NDP Modified ACK is used, the deferred time is the duration value equal to X*TU-NDP ACK-SIFS. If DATA is a baseline (802.11-2012) frame format with Duration/ID field, the Duration field setting in AP for DATA frame is based on the data rate between AP and RELAY as well as RELAY and STA. X can also be set according to DATA transmission time between RELAY and STA for the relayed DATA frame+ACK+2*SIFS for the case of using ACK. The similar approach applies to the case of using NDP ACK/NDP Modified ACK. This change may improve the accuracy of NAV setting or deferred channel access time for the STA. The unintended STA is able to set an accurate NAV or deferred channel access time so that it may be able to save the power further. The above method is also valid for uplink TXOP sharing for two-hop relay.
If DATA is without Duration field (e.g. DATA is with a short MAC header) but with LENGTH/DURATION in PHY SIG field, the LENGTH/DURATION in SIG field and data rate between RELAY and the intended receiver can be used to determine the Duration field value of ACK sent by RELAY. In downlink TXOP sharing for two-hop relay, after AP transmits DATA to the RELAY and receives ACK (Duration field is set to X) from the RELAY, AP removes frame from buffer and defers before next event for a time of (X*TU-ACK-SIFS) where TU is time unit for Duration field of ACK and ACK indicates ACK frame duration time, or until a valid PHY-RXSTART.indication, whichever comes first. If NDP ACK/NDP Modified ACK is used, the deferred time is the Duration field value of the transmitted DATA-NDP ACK-SIFS. The Duration field setting in RELAY for ACK is based on the data rate between RELAY and STA and the information on LENGTH/DURATION in PHY SIG fields. X should be set according to DATA transmission time between RELAY and STA for the relayed DATA frame+ACK+2*SIFS. The similar approach applies to NDP ACK/NDP Modified ACK.
According to various embodiments, devices and methods may be provided which use NDK ACK/NDP Modified ACK in the TXOP sharing for two-hop relay procedure to further improve the efficiency.
In the example shown in
In the example shown in
In the example shown in
In the above procedure of TXOP sharing for two-hop Relay, the STA that transmitted the data frame for relaying elicited the response from the Relay may set its NAV or deferred channel access time and/or RID value properly.
For the case of frame transmission with Duration, the STA may set a correct RID value when ACK_INDICATION of the received frame is 3. For example shown in
For example shown in
Therefore, the Duration for NAV setting and NAV and RID update rule in TXOP sharing for two-hop relay is as follows:
In response to the relayed frame, the relay STA may set Duration to the transmission time between the relay and the next hop STA for the relayed frame that elicited the response.
The STA that elicited the response from the relay may set the NAV based on the Duration field of the response frame+the response (NDP ACK or ACK)+2*SIFS and reset the RID value to zero.
Whether to proceed with TXOP sharing for two-hop relaying, we may setup the following rule:
When AP is busy in transmission or other operation (NAV counter is nonzero), the Relay is not able to forward to the AP the frame received from the non-AP STA if the Relay has its nonzero NAV counter. Similarly, when a non-AP STA is busy in transmission or other operation (NAV counter is nonzero), the Relay is not able to forward to the non-AP STA the frame received from the AP if the Relay has its nonzero NAV counter. In this situation, the Relay may respond with (NDP) ACK with equivalent ACK_INDICATION value or ACK_INDICATION set to No Response to stop TXOP sharing for two-hop relaying. The Relay shall not update its NAV counter when it receives the frame for TXOP sharing for two-hop relaying.
Another embodiment may be as follows:
A non-AP STA starts a frame exchange by sending a Short Data frame addressed to the relay STA with TXVECTOR parameter ACK_INDICATION (assume that the TXVECTOR parameter ACK_INDICATION is the defined parameter that is used to indicate the response frame) set to NDP Response. The relay STA may set the Duration Indication field to 1 and Duration field to 0 in the NDP ACK frame that is transmitted to the non-AP STA to indicate Long Response. In addition it shall set the Relayed Frame field of the NDP ACK frame to 1.
When the direction of the frame is from the AP to the non-AP STA, the AP starts a frame exchange by sending a Short Data frame addressed to the relay STA with the TXVECTOR parameter ACK_INDICATION set to NDP Response. The relay STA shall set the Duration Indication field to 1 and the Duration field to 0 in the NDP ACK frame that is transmitted to the AP to indicate Long Response. In addition it may set the Relayed Frame field of the NDP ACK frame to 1.
In the following, ACK indication and NAV setting for speed frame exchange and TXOP will be described.
After a successful reception of a frame requiring acknowledgment, transmission of the (NDP) ACK frame shall commence after a SIFS, without regard to the busy/idle state of the medium. However, whether or not to continue the speed frame exchange may be based on the NAV setting in the STA.
For whether to proceed with speed frame exchange, we may setup the following rule:
If the responding STA receives a frame (e.g. short data frame without Duration field in MAC header) from its peer STA in speed frame exchange with ACK_INDICATION set to 3 (i.e. Long Response) in RXVECTOR parameter, if NAV counter is nonzero due to the other reception that it has received at the earlier time, the responding STA shall not transmit a data frame as the response frame (i.e. Long Response). Instead, the responding STA may transmit an NDP ACK with an (equivalent) ACK_INDICATION value equal to 0 (No Response) or transmit an ACK with ACK_INDICATION field set to 0 (No Response) to stop further frame exchange. The responding STA may not update its NAV counter upon receiving the frame for speed frame exchange.
In the following, NAV and equivalent ACK Indication setting for Speed frame exchange (SF) will be described.
If NDP ACK is used as the immediate response frame by the responding STA for the preceding frame that elicited the response in SF,
In the following, SF (speed frame) using NDP frames (1 MHz) will be described.
When 1 MHz NDP PS-Poll is used, as there is no Duration field in 1 MHz NDP PS-Poll, there may be the question what ACK Indication field value shall the response frame set. It may be dependent on whether the response frame is DATA or NDP Modified ACK.
If UDI is set to 0 or 1 in NDP PS-Poll, when the response frame is DATA, ACK Indication field value may be set to any value. If UDI=0, ACK Indication=1 (NDP ACK) or 2 (ACK). If UDI=1, ACK Indication is set to 3 (Long Response). Duration field of DATA can be set to SIFS+NDP ACK (1 MHz). The duration of NDP ACK should consider the rounding effect.
For SF,
1. If UDI is set to 1 in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=Long Response shall be set. If the duration for UL transmission can be predicted, AP may set the Duration field for NAV setting.
2. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, a value equivalent to ACK Indication=No Response shall be set if there is no buffered frame delivery to the STA from an AP (More Data is set to 0 in NDP Modified ACK).
3. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=Long Response (e.g. Duration Indication=1 and Duration=0) shall be set if there is buffered frame delivery to the STA from an AP (More Data is set to 1 in NDP Modified ACK). However, a better method for NDP ACK frame is that Duration Indication shall be set to 0 and Duration shall be set to the value for NAV setting that covers the transmission of buffered frame delivery to the STA, i.e. buffered frame duration+SIFS.
However, if there is no speed frame exchange,
1. If UDI is set to 1 in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=No Response shall be set if there is no buffered frame delivery to the STA from an AP (More Data is set to 0 in NDP Modified ACK). For RAW operation, the frame of NDP PS-Poll and NDP Modified ACK is finished within a small slot duration that does not allow the transmission of uplink data from STA to its AP. The uplink frame is scheduled in a different RAW that allows a larger slot duration.
2. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=No Response (e.g. Duration Indication=0 and Duration=0) shall be set if there is buffered frame delivery to the STA from an AP (More Data is set to 1 in NDP Modified ACK). The STA either shall keep awake if the buffered frame from AP will be delivered soon or can go to sleep if the buffered frame from AP will be delivered at a different schedule time that is known to the STA (e.g. the STA is aware of the RAW operation indicated in RPS IE and can identify its downlink data delivery).
In the following, SF using NDP frames (>=2 MHz) will be described.
When >=2 MHz NDP PS-Poll is used, as there is UDI with Duration value in NDP PS-Poll, what ACK Indication field value shall the response frame set? It is dependent on whether the response frame is DATA or NDP Modified ACK.
When UDI is a nonzero positive value, if the response frame is DATA, ACK Indication field value shall be set to 3 (Long Response) though the uplink data is known. If More Data field in DATA frame is set to 0, Duration field of DATA can be set to either UDI value (converted to the corresponding time unit)+SIFS or 0. If More Data field in DATA frame is set to 1, Duration field of DATA can be set to UDI value (converted to the corresponding time unit)+SIFS or Downlink data duration for next frame+UDI value (converted to the corresponding time unit)+2*SIFS.
If the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=Long Response with known duration shall be set, e.g. Duration Indication=0 and Duration=UDI value (converted to the corresponding time unit)+SIFS or Downlink data duration+UDI value (converted to the corresponding time unit)+2*SIFS, since the uplink data duration is given by UDI field value of NDP PS-Poll.
For SF,
1. If UDI is set to a nonzero positive value in NDP PS-Poll, when the response frame is NDP Modified ACK, if UDI is a Duration value for NAV setting, Duration Indication is set to 0 and Duration is set to UDI value (converted to the corresponding time unit)+SIFS if there is no buffered frame delivery to the STA from an AP (More Data is set to 0 in NDP Modified ACK), or Downlink data duration+UDI value (the corresponding time unit)+2*SIFS if there is buffered frame delivery to the STA from an AP (More Data is set to 1 in NDP Modified ACK). Otherwise, if UDI is not a Duration value for NAV setting, Duration Indication is set to 1 and Duration is set to 0 (equivalent ACK Indication=Long Response) regardless of whether there is buffered frame delivery to the STA from an AP. If the duration for UL transmission can be predicted, AP may set the Duration field for NAV setting.
2. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, a value equivalent to ACK Indication=No Response shall be set if there is no buffered frame delivery to the STA from an AP (More Data is set to 0 in NDP Modified ACK).
3. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, Duration Indication is set to 0 and Duration is set to Downlink data duration+SIFS if there is buffered frame delivery to the STA from an AP (More Data is set to 1 in NDP Modified ACK).
However, if there is no speed frame exchange,
1. If UDI is set to a nonzero positive value in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=No Response shall be set if there is no buffered frame delivery to the STA from an AP (More Data is set to 0 in NDP Modified ACK). For RAW operation, the frame of NDP PS-Poll and NDP Modified ACK is finished within a small slot duration that does not allow the transmission of uplink data from STA to its AP. The uplink frame is scheduled in a different RAW that allows a larger slot duration.
2. If UDI is set to 0 in NDP PS-Poll, when the response frame is NDP Modified ACK, a reserved value equivalent to ACK Indication=No Response (e.g. Duration Indication=0 and Duration=0) shall be set if there is buffered frame delivery to the STA from an AP (More Data is set to 1 in NDP Modified ACK). The STA either shall keep awake if the buffered frame from AP will be delivered soon or can go to sleep if the buffered frame from AP will be delivered at a different schedule time that is known to the STA (e.g. the STA is aware of the RAW operation indicated in RPS IE and can identify its downlink data delivery).
Speed frame (SF) exchange allows an AP and non-AP STA to exchange a sequence of uplink and downlink PPDUs separated by SIFS. This operation combines both uplink and downlink channel access into a continuous frame exchange sequence between a pair of STAs. The objective of this operation is to minimize the number of contention-based channel accesses, improve channel efficiency by reducing the number of frame exchanges, and reduce STA power consumption by shortening Awake times.
One of the various embodiments for the rule of speed frame exchange will be described in the following.
An AP may send any frame as the initial frame of a SF exchange. An AP may set the ACK Indication field of the PLCP Signal field to Normal Response or NDP Response for the initial frame of a SF exchange.
A non-AP STA may send a trigger frame or a (NDP) PS-Poll frame as the initial frame of a SF exchange. A non-AP STA shall set the ACK Indication field of the PLCP Signal_field to Long Response in a frame that initiates an SF exchange if the initial frame is not a NDP PS-Poll frame.
A STA sending an immediate response that is not an NDP frame to a frame that had the More Data field set to 1 shall set the ACK Indication field to Long Response. A STA sending an immediate response NDP (Modified) ACK frame to a frame that had the More Data field set to 1 shall set the Duration Indication field to 1 and Duration field to 0 to indicate Long Response or set the Duration field for NAV setting for a SF exchange.
A non-AP STA sending an immediate response that is an ACK frame or a BlockAck frame after receiving a frame that had the More Data field set to 0 shall set the ACK Indication field to No Response. A non-AP STA sending an immediate response NDP ACK frame after receiving a frame that had the More Data field set to 0 shall set the Duration Indication and Duration fields to 0 to indicate No Response.
An AP sending an immediate response that is an ACK frame or a BlockAck frame after receiving a frame that had the More Data field set to 0 shall set the ACK Indication field to Long Response if it will send a data frame SIFS time after the end of the immediate response transmission or No Response if it will not send a data frame SIFS time after the end of immediate response transmission. An AP sending an immediate response that is either an NDP ACK after receiving a frame that had the More Data field set to 0 or an NDP Modified ACK after receiving an NDP PS-Poll that had UDI field set to 0 shall set the Duration Indication and Duration fields to 0 to indicate No Response if it will not send a data frame SIFS time after the end of the NDP (Modified) ACK frame transmission, or the Duration Indication field to 1 and Duration field to 0 to indicate Long Response if it will send a data frame SIFS time after the end of the NDP (Modified) ACK frame transmission (1 MHz).
A STA that receives a frame with a unicast MAC address in the Address 1 field that matches its MAC address, or a unicast AID in the Address 1 field matching to its AID and a unicast MAC address in Address 2 field matching its AP's BSSID, or a NDP (Modified) ACK frame with a matching ACK ID within SIFS after the transmission of a frame accepts the reception as an acknowledgement for the its immediately previous transmission.
A STA sending an immediate response that is not an NDP (Modified) ACK and has the More Data field set to 1 and the ACK Indication field set to Long Response shall transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame if the More Data field was set to 0 in the frame most recently received from the STA, and set the Duration field to an estimated time to protect the remaining transmissions if there is a Duration field in the response frame.
A STA sending an immediate response that is an NDP ACK frame and had the More Data field set to 1 shall transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame in which the Duration Indication field shall be set to 0 and the Duration field shall be set to an estimated time to protect the remaining transmissions if the More Data field was set to 0 in the frame most recently received from the STA in a SF exchange.
An AP sending an immediate response that is an NDP Modified ACK frame and has the More Data field set to 1 shall transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame in which the Duration Indication field shall be set to 0 and the Duration field shall be set to an estimated time to protect the remaining transmissions if the UDI field was set to 0 in the NDP PS-Poll frame (>=2 MHz) most recently received from the non-AP STA in a SF exchange.
A STA sending an immediate response that is not an NDP (Modified) ACK and had the More Data field set to 1 and the ACK Indication field set Long Response shall not transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame in which the Duration field shall be set to a value equal to the time that is set by the Duration field in the frame that elicited the response, minus aSFISTime and a duration for the response frame transmission if there is a Duration field in both the response frame and the frame that elicited the response, or if there is a Duration field in the response frame and there is a NAV setting in the beginning of TXOP, if the More Data field was set to 1 in the data frame most recently received from the STA in a SF exchange.
A STA sending an immediate response that is an NDP ACK frame shall not transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame in which the Duration Indication field shall be set to 0 and the Duration field shall be set to a value equal to the time that is set by the Duration field in the frame that elicited the response, minus aSFISTime and a duration for the response NDP ACK frame transmission if there is a Duration field in the frame that elicited the response or if there is NAV setting in the beginning of TXOP, if the More Data field was set to 1 in the data frame most recently received from the STA in a SF exchange.
An AP sending an immediate response NDP Modified ACK frame shall not transmit a frame to the STA that elicited the response, SIFS after the transmission of the response frame in which the Duration Indication field shall be set to 1 and the Duration field shall be set to 0 to indicated Long Response, if the UDI field was set to a nonzero value in the NDP PS-Poll frame most recently received from the non-AP STA in a SF exchange.
Without the setup of Block Ack, a STA shall not use (NDP) BA for a SF exchange. With the set up of Block Ack, in response to the received frame with the More Data field set to 0 from the other STA that elicited the response in a SF exchange, a STA sending an immediate response that is not an NDP (Modified) ACK and had the More Data field set to 1 and the ACK Indication field set to Long Response shall continue to transmit its frames, until the last frame with the More Data field set to 0 and the ACK Indication field set to either Normal Response to request a (NDP) BA frame or NDP
Response to NDP Response to request a NDP ACK frame, SIFS time after each transmission of the response frame in which the Duration field shall be set to a value equal to the time that is set by the Duration field in the frame that elicited the response, minus aSFISTime and a duration for the response frame transmission if there is a Duration field in both the response frame and the frame that elicited the response, or if there is a Duration field in the response frame and there is a NAV setting in the beginning of TXOP.
A STA sending an immediate response with the More Data field set to 1 and the TXVECTOR parameter ACK_INDICATION set to No Response shall transmit a frame to the STA that elicited the response within the current TXOP, but not SIFS after the transmission of the response frame.
A STA either sending an immediate response that sets the More Data field 0 and the TXVECTOR parameter ACK_INDICATION set to No Response shall not transmit a frame within the current TXOP to the STA that elicited the response.
A non-AP STA shall remain in the Awake state until the end of the current TXOP if it receives a frame with the More Data field set to 1 from either the AP addressed to itself or a NDP ACK (Modified) frame with a matching ACK ID.
A non-AP STA may transition to the Doze state if it receives a frame with the More Data field set to 0 either from the AP addressed to itself or in a NDP (Modified) ACK frame with a matching ACK ID.
In a TXOP, in order to disallow the peer STA (e.g. B) sending data frame as the long response, a STA (e.g. A) may send its data frame with ACK_INDICATION set to NDP frame (or Normal Response) to solicit a NDP ACK (Normal ACK) as the response frame for its transmitted data frame. Even if STA B responds with a NDP ACK frame with the More Data field set to 1 to indicate that it has buffered frame for STA A, STA A may send its data frame with ACK_INDICATION set to NDP frame (or Normal Response) to continue to solicit a NDP ACK (or Normal ACK) frame instead of a data frame as the long response from STA B. This means the More Data field in the response frame transmitted by STA B is ignored by the TXOP holder/initiator (STA A). In this case, STA A continues to transmit its data frames without allowing the transmission of data frame from STA B as the response frame in the speed frame exchange.
When there are multiple frame transmissions for speed frame exchange in a TXOP that is limited by a value, the speed frame exchange may be stopped in order to limit the transmission within the TXOP limit. For example, when a data frame is requested as the long response frame, the responding STA may ignore the ACK INDICATION setting in the received frame that elicited the response, and transmit a shorter response such as NDP ACK. In this NDP ACK frame, Duration Indication field is set to 0 and Duration field is set to 0, indicating there will no more frame transmission within this TXOP.
In the following, duration and NAV setting for TXOP will be described.
Duration/NAV setting for the normal frame in current 802.11 with Duration field still can follow the convention.
When RTS/CTS or other protection mechanism for channel access protects a TXOP, even if TXOP holder transmits the frame with a short MAC header that has no Duration field for NAV setting, the TXOP responder can still set the Duration field in the response frame (e.g. NDP ACK) after receiving the frame because the MCS and LENGTH (number of the OFDM symbols or number of bytes, dependent on Aggregation bit in SIG field) in the SIG field of the frame can be used to determine the value of Duration field in the response frame.
If the remaining NAV before the transmission of the frame is X and the duration for the frame is Y, the Duration field should be set as ceil((X-SIFS-Y)/TU), where TU is the time unit for Duration field when Duration Indication is 0 and ceil(x) is the ceiling function of x that is used to round up for the setting of Duration field and NAV. X, SIFS and Y are assumed with the same time unit. Otherwise, they should be converted before the Duration field is set.
Y may be obtained by dividing the length of the frame by the data rate corresponding to the MCS value in the SIG field of the frame and round up the time unit used for Duration setting.
The above method can be used for TXOP with multiple frame transmissions.
According to various embodiments, a SIG Field Design and associated Protocol or procedures (for example ACK (Acknowledgement) indication, ACK indication for Speed frame exchange, NDP (Null Data Packet) type indication) may be provided.
According to various embodiments, the following SIG field designs may be provided:
For 1 MHz, the following fields may be provided: MCS, Aggregation bit, Length, Ack Indication, NDP Indication, CRC, and Tail.
For >=2 MHz, the following fields may be provided: Length/Duration, MCS, BW, PAID, Ack Indication, NDP Indication, CRC, and Tail.
The fields may be defined as follows:
According to various embodiments, TXOP truncation/termination, flow control, NAV setting and RID update, speed frame exchange, and/or TXOP sharing for two-hop relaying may be provided, for example using a SIG field design.
According to various embodiments, a communication method may be provided. The communication method may include: at least one of sending a first data unit comprising a physical layer (PHY) header or receiving a first data unit comprising a PHY header; wherein the PHY header comprises one or more fields to indicate whether a response data unit is intended to follow the first data unit, and to indicate the type of the response data unit, when a response data unit is intended to follow the first data unit; wherein the type of the response data unit can be used to estimate the duration of the response data unit.
According to various embodiments, the first data unit is a null data packet type PS-Poll and at least one of the fields in the PHY header indicates that the following response data unit is a null data packet type ACK and the null data packet type ACK is different from other null data packet type ACK and used only for the null data packet type PS-Poll.
According to various embodiments, at least a field indicates whether the response data unit is at least one of a normal response data type or a null data packet type.
According to various embodiments, the normal response data unit is at least one of normal ACK, normal Block ACK or a polling response frame
According to various embodiments, the field comprises at least 2 bits and only one value of the field is used to indicate all the short data response units including at least one of the following: a null data packet format of ACK, a null data packet format of short response frame to null data type PS-Poll, a null data packet format of CTS, and a null data packet format of Block Ack frame.
According to various embodiments, the indication comprises at least three bits; a first value of the field indicates that no response data unit is intended to follow the first data unit; and a second value of the field indicates the intended response data is a null data packet type; a third value of the field indicates the intended response data having the size equal to or smaller than that of normal ACK; a fourth value of the field indicates the intended response data having the size equal to or smaller than that of normal Block Acknowledgement but larger than that of normal ACK; and a fifth value of the field indicates the intended response data unit having the size larger than the size indicated by the fourth value listed above.
According to various embodiments, the field comprises two bits; a first value of the field indicates that no response data unit is intended to follow the first data unit; a second value of the field indicates the intended response data is a null data packet type; a third value of the field indicates the intended response data having the size equal to or shorter than a pre-determined value but larger than the size indicated in the second value; and a fourth value of the field indicates the intended response data unit having the size larger than the size indicated by the third value.
According to various embodiments, the PHY header comprises an indication of a response data unit for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the type of the response data unit is a normal response data type for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the response data unit is a normal ACK and its Duration field for NAV setting protects the following transmission in one TXOP.
According to various embodiments, the type of the response data unit is a null data packet type for at least one of speed frame exchange or TXOP sharing.
According to various embodiments, the first data unit itself is a null data packet type PS-Poll and the response data unit is a null data packet response frame to null data type PS-Poll.
According to various embodiments, the first data unit is at least one of a null data packet type ACK or a null data packet type response frame responding to a null data type PS-Poll, and two or more bits in at least two fields of the first data unit indicate that there is no response data unit intended to follow the first data unit.
According to various embodiments, the Duration Indication field set to 0 and the Duration field set to 0 indicates that there is no response data unit intended to follow the first data unit.
According to various embodiments, the first data unit is a null data packet type ACK or a null data packet type response frame responding to a null data type PS-Poll, and two or more bits in at least two fields of the first data unit indicate that the response data unit is a type with the size larger than that of a normal data unit.
According to various embodiments, the Duration Indication field set to 1 and the Duration field set to 0 indicate that the response data unit is a type with the size larger than that of a normal data unit.
According to various embodiments, the intended receiver defers at least one of its transmission or channel access for at least a duration based on the indication for the type of the response data unit.
According to various embodiments, the type of the response data unit is a null data packet frame.
According to various embodiments, the type of the response data unit is a normal frame with the size equal to or short than that of a normal ACK.
According to various embodiments, the type of the response data unit is a normal frame with the size equal to or smaller than that of a normal Block ACK but larger than that of a normal ACK.
According to various embodiments, devices and methods may be provided for RID (Response Indication Deferral) setting and resetting, which may further improve the design of 802.11ah communication protocol.
In the following, RID update according to various embodiments will be described. RID is the secondary virtual carrier sensing mechanism used by third party devices which relies only on PHY header information (which includes the Response Indication) in addition to the primary NAV virtual carrier sensing mechanism. The NAV mechanism is based on information carried in the MPDU in the current IEEE 802.11 standard though the Duration field in the SIG field for 802.11ah PPDU may be used for NAV setting. The information in MPDU is less reliable than the information in PHY header since PHY header uses robust coding. RID mechanism provides a reliable virtual carrier sensing method for S1G STAs and APs that replaces the Enhanced Inter Frame Space (EIFS) mechanism in the current 802.11 standard.
There may be two virtual carrier sensing (CS) schemes (NAV and RID) in S1G STA (i.e. in 802.11ah STA). RID is Response Indication Deferral that may be based on the SIG field RESPONSE_INDICATION or the RXVECTOR parameters' RESPONSE_INDICATION of the received frame. For S1G STAs, the CS mechanism combines the NAV state, RID state and the STA's transmitter status with physical CS to determine the busy/idle state of the medium. The NAV and RID may be thought of as counters, which count down to 0 at a uniform rate.
The NAV may maintain a prediction of future traffic on the medium based on duration information that is announced in RTS/CTS (ready to send/clear to send) frames prior to the actual exchange of data. The duration information may also be available in the MAC headers of all frames sent during the CP (Contention Period) other than short MAC frames and PS-Poll frames with a Duration/ID field that contains an AID value, and SIG field of (Modified) NDP ACK frame. (Modified) NDP ACK may also contain a Duration field for NAV setting.
NAV may be based on the “Duration” field of the received frame.
The STAs may update their NAV with the received Duration field only when the new NAV value is greater than the current NAV value.
A Frame with short MAC header format may have no Duration field.
Response Indication Deferral (RID) may be applicable to S1G STAs. RID may begin immediately after the reception of a frame with RXVECTOR parameter RESPONSE_INDICATION that has a value of No Response, NDP Response, Normal Response and Long Response.
The Virtual CS (carrier sensing) mechanism may be based on both NAV and RID, and if the STA obtains both REVECTOR parameter RESPONSE_INDICATION and the Duration field from the single reception, the STA may reset RID to zero.
The medium condition at the MAC may be determined as busy if PHY_CS (Physical layer Carrier Sensing) indicates busy or the NAV counter has a non-zero value or the RID counter has a non-zero value or STA transmitter status is equal to “transmitting”, i.e. Medium is BUSY=(PHY_CS==BUSY) OR (NAV !=0) OR (RID !=0) OR (STA transmitter status==transmitting). When NAV count is zero and RID count is nonzero, NAV count is not used to determine the channel status (either busy or idle). This may happen when the short MAC header without a Duration field is received or when only the SIG is received but MAC frame is not decoded.
The RID counter may be updated with the new RID value derived from the reception without a Duration field or may be reset for the reception with a Duration field. The S1G STA may reset its RID counter if it is the intended receiver of any of the frames within the received PSDU or it receives a valid Duration field in at least one MPDU in the received PSDU. The RID counter may be updated at the moment the PHY-RXSTART.indication primitive is issued for the current PPDU and it may start at the end of the current PSDU which is calculated based on the RXVECTOR parameter's LENGTH.
An S1G STA that receives a frame that is not an NDP MAC frame may update its RID counter based on the values of the RXVECTOR parameters FORMAT, PREAMBLE_TYPE, RESPONSE_INDICATION, AGGREGATION, MCS, PARTIAL_AID, COLOR, UPLINK_INDICATION, and CH_BANDWITH of the received frame. An S1G STA that receives an NDP MAC frame may update its RID counter based on the values of the RXVECTOR parameter FORMAT, PREAMBLE_TYPE and the RESPONSE_INDICATION value defined for the type of the received NDP MAC frame. The S1G STA may reset its RID counter if it is the intended receiver of any of the frames within the received PSDU or it receives a valid Duration field in at least one MPDU in the received PSDU.
The RID counter may be updated at the moment the PHY-RXSTART.indication primitive is issued for the current PPDU and it may start at the end of the current PSDU which is calculated based on the RXVECTOR parameter's LENGTH.
The PHY layer may filter out a PPDU according to a PHY receive procedure. If so, frames in the PPDU may not be received by the MAC and may have no effect on the NAV. A MAC frame may not be received correctly. NAV and RID counts may be used to determine idle channel status.
Unless NAV count is larger than both the current RID count and the new RID value derived from the reception, there may be not enough protection on channel access due to a new RID count with a smaller value than the current RID count.
When the STA decodes SIG fields, there may be some cases as follows:
Case 1: STA fails to decode MAC header;
Case 2: STA decodes MAC header but without Duration field;
Case 3: STA decodes MAC header with Duration field; and
Case 4: STA does not decode MAC frame for the sake of power saving.
In the example illustrated in
At time t1, AP1 sends frame DATA 1 (2302) to STA2 with RESPONSE_INDICATION in SIG field equal to Long Response (3) without the Duration value, which is overheard by STA1. At time t2>t1(but before the RID count of STA1 reaches zero), after receiving a frame DATA 2 (2304), AP2 sends a NDP ACK frame (2306) to STA3 with TXVECTOR parameter RESPONSE_INDICATION set to No Response (0) and a Duration value equal to 0 for NAV setting, which is overheard by STA1. As STA1 receives the NDP ACK frame with the Duration field value equal to 0, following an RID reset rule, its RID value may be reset. If RID is reset upon STA1 receiving the NDP ACK frame from AP2, the earlier transmission attempt of DATA 4 (2308) by STA1 may corrupt the transmission of the frame DATA 3 (2310) by STA2 if STA1 can't sense the channel correctly during STA2's transmission. In this case, the AP1 can't decode the received frame of DATA 3 properly (like indicated by crossed box 2312) due to the concurrent transmissions of DATA 3 from STA2 and DATA 4 from STA 1. In this case, the RID value at the STA1 may be reset due to a Duration value of the reception of the NDP ACK frame by OBSS (AP2) transmission and the STA1's early channel access may corrupt the transmission of the frame DATA 3 within the same BSS (AP1).
In the above example, assume that STA2 is associated with AP1, STA1 and STA3 are associated with AP2. Assume the transmissions and conditions are the same as shown in
In the example illustrated in
At time t1, AP1 sends frame DATA 1 (2502) to STA2 with RESPONSE_INDICATION in SIG field equal to Long Response (3) without the Duration value, which is overheard by STA1. At time t2>t1(but before the RID count of STA1 reaches zero), AP2 sends a frame DATA 2 to STA3 with TXVECTOR parameter RESPONSE_INDICATION set to NDP Response (1) but without a Duration value for NAV setting, which is overheard by STA1. As STA1 receives the frame DATA 2 (2506) without the Duration field value, following an RID update rule, its RID value may be updated (in 2508) with the new RID value, regardless of whether the new RID value is smaller than the current RID value. If RID is updated upon STA1 receiving the frame DATA 2 from AP2, the earlier transmission attempt of DATA 4 (2510) by STA1 (after the expiration of the current RID value that is used jointly with NAV count and other conditions to determine the channel is not busy) may corrupt the transmission of the frame DATA 3 (2512) by STA2 if STA1 can't sense the channel correctly during STA2's transmission. In this case, the AP1 can't decode the received frame of DATA 3 properly (like indicated by a crossed box 2514) due to the concurrent transmissions of DATA 3 from STA2 and DATA 4 from STA1. In this case, at the STA1, the larger RID value set by the old reception of the frame DATA 1 is updated with a small RID value derived from the new reception of the frame DATA 2 by OBSS (AP2) transmission so that the early channel access corrupts the transmission within the same BSS (AP1) of the frame DATA 3.
In the above example, assume that STA2 is associated with AP1, STA1 and STA3 are associated with AP2. Assume the transmissions and conditions are the same as shown in
According to various embodiments, the new RID value may be calculated upon the SIG field is received, based on the RXVECTOR parameters' PREAMBLE TYPE, RESPONSE_INDICATION, AGGREGATION, MCS, and CH_BANDWITH. The RXVECTOR parameter RESPONSE_INDICATION may be determined by at least one of the following: RESPONSE_INDICATION subfield in the SIG field (e.g. of non-NDP MAC frame) and NDP MAC frame type. Therefore, the RID update or reset may be done either when a valid SIG field is received or when a valid MAC header is received.
If the STA chooses only receive the SIG field but not to receive the MAC frame, the RID update or reset may be done upon the SIG field is received and the new RID value is calculated. In this case, the new RID value starts at the end of the received SIG field.
If the STA is able to receive the MAC frame, it may determine to update/reset the RID value after decoding MAC frame successfully (e.g. frame checksum is verified as correct and security checking is passed if required.). In this case, the new RID value may be calculated at the end of the received PPDU. The new RID value starts at the end of the received PPDU.
According to various embodiments, there may be an Uplink indication in SIG (>=2 Mhz) field. As an uplink frame SIG field carries PBSSID information in the RXVECTOR parameter PARTIAL_AID (>=2 MHz), a STA may identify whether the received frame is from other STA within the same BSS. As a downlink frame SIG field carries COLOR information (>=2 MHz) in the RXVECTOR parameter COLOR, a STA may identify whether the received frame is from its AP. Thus, it may be feasible for the STA to detect that the received frame is from the same BSS (Basic Service Set) and maintain a status on whether the RID value is regarded as derived from the reception elicited from the same BSS for the case that SIG (>=2 MHz) includes the information of UPLINK, COLOR and PARTIAL_AID. Once the RID count reaches zero, whether the immediate preceding received PPDU that is used to set the RID count is either from or to its AP is not required to keep track of.
Since NDP MAC Frames (e.g. NDP ACK) have a Duration field for NAV setting, if the STA can identify the NDP frame is from its own BSS, it may follow the same RID update rule as non-NDP MAC frame (>=2 MHz). For example, the STA may receive both MAC frame and its response NDP ACK frame. However, if the STA cannot identify whether it is from its own BSS, it should regard the NDP frame either as the frame from its own BSS or as the frame from OBSS. In general, NDP MAC frame is preferred as from the recipient STA's own BSS, if the STA cannot determine. Similarly, as 1 MHz S1G PPDU has no available information in PHY header for the STA to identify whether it is from the STA's BSS, the STA may regard such received PPDU as from its own BSS.
It is to be noted that the STAs update their NAV with the received Duration field only when the new NAV value is greater than the current NAV value. These apply to the following embodiment, regardless whether the STA updates its NAV with the received Duration field for NAV setting from the transmission from OBSS or its own BSS.
In other words, according to various embodiments, a mobile radio communication device may set (or reset) an RID parameter based on whether data received is received from its AP or not.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to reset the response indication deferral parameter based on the determination of the access point identification circuit 2104.
According to various embodiments, the received data may include or may be or may be included in a physical protocol data unit.
According to various embodiments, the received data may include or may be or may be included in at least one frame within a physical layer service data unit.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to reset the response indication deferral parameter to zero if the access point identification circuit 2104 determines that the received data is received from or sent to the access point corresponding to the mobile radio communication device 2100, and if furthermore the mobile radio communication device 2100 obtains both RXVECTOR parameter RESPONSE_INDICATION and the Duration field from the received data. Other RXVECTOR parameters such as FORMAT, PREAMBLE TYPE, AGGREGATION, MCS, and CH_BANDWITH are also used to determine the value of new RID count. It will be understood that, in order to simplify the description, the text may be omitted here and only RESPONSE_INDICATION parameter may be used as an example, like described above.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to replace the current response indication deferral parameter with a new response indication deferral value if the access point identification circuit 2104 determines that the received data is received from or sent to the access point corresponding to the mobile radio communication device 2100, and if furthermore there is no duration field in the received data.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to update the response indication deferral parameter if the access point identification circuit 2104 determines that the received data is not received from or sent to the access point corresponding to the mobile radio communication device 2100, and if furthermore the new response indication deferral parameter for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current response indication deferral parameter.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to reset the response indication deferral parameter if furthermore there is a valid Duration field for channel access reservation (NAV setting) in the MPDU.
According to various embodiments, the access point identification circuit 2104 may be configured to determine whether the received data is received from or sent to an access point corresponding to the mobile radio communication device based on whether a received PPDU is an NDP MAC frame.
According to various embodiments, the response indication deferral setting circuit 2106 is configured to leave the response indication deferral parameter un-updated if the access point identification circuit 2104 determines that the received data is not received from or sent to the access point corresponding to the mobile radio communication device 2100, and if furthermore the new response indication deferral parameter for the RXVECTOR parameter RESPONSE_INDICATION is smaller than or equal to the current response indication deferral parameter.
According to various embodiments, the response indication deferral setting circuit 2106 may be configured to reset the response indication deferral parameter if furthermore there is a valid Duration field for channel access reservation (NAV setting) in the MPDU that has a value larger than the response indication deferral parameter.
According to various embodiments, the response indication deferral parameter may include or may be or may be included in a response indication deferral count.
According to various embodiments, the mobile radio communication device may include or may be or may be included in a station according to IEEE 802.11ah.
According to various embodiments, the method may further include resetting the response indication deferral parameter based on the determining.
According to various embodiments, the received data may include or may be or may be included in a physical protocol data unit.
According to various embodiments, the received data may include or may be or may be included in at least one frame within a physical layer service data unit.
According to various embodiments, the method may further include resetting the response indication deferral parameter to zero if it is determined that the received data is received from or sent to the access point corresponding to the mobile radio communication device, and if furthermore the mobile radio communication device obtains both RXVECTOR parameter RESPONSE_INDICATION and the Duration field from the received data.
According to various embodiments, the method may further include replacing the current response indication deferral parameter with a new response indication deferral value if it is determined that the received data or sent to is received from the access point corresponding to the mobile radio communication device, and if furthermore there is no duration field in the received data.
According to various embodiments, the method may further include updating the response indication deferral parameter if it is determined that the received data is not received from or sent to the access point corresponding to the mobile radio communication device, and if furthermore the new response indication deferral parameter for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current response indication deferral parameter.
According to various embodiments, the method may further include leaving the response indication deferral parameter un-updated if it is determined that the received data is not received from or sent to the access point corresponding to the mobile radio communication device, and if furthermore the new response indication deferral parameter for the RXVECTOR parameter RESPONSE_INDICATION is smaller than or equal to the current response indication deferral parameter.
According to various embodiments, the response indication deferral parameter may include or may be or may be included in a response indication deferral count.
According to various embodiments, the mobile radio communication device may include or may be or may be included in a station according to IEEE 802.11ah.
In the following, an embodiment (which may be referred to as embodiment 1) will be described.
When the STA identifies that the reception is addressed to itself, it shall reset its RID counter as long as it is the intended receiver of the PPDU or any of the frames within the received PSDU.
The following is an embodiment of RID setting and resetting for a STA that is the 3rd party of the reception, without considering the Duration field in the reception.
1. When the STA identifies that the reception is the transmission either from or to its AP (i.e. from its own BSS), the STA shall replace the current RID count with the new RID value.
2. Otherwise,
a. if the new RID value for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current RID count, the RID count shall be updated;
b. if the new RID value for the RXVECTOR parameter's RESPONSE_INDICATION is smaller than or equal to the current RID count, the RID count shall not updated.
In this embodiment, the STA is not required to keep track of whether the immediate preceding received PPDU is either from or to its AP (i.e. from its own BSS). The STA could identify whether the received PPDU is either from or to its AP, based on the RXVECTOR parameters' UPLINK, COLOR and PARTIAL_AID or the MAC header of the received PPDU (if applicable).
It is to be noted that PHY header information such as COLOR and PARTIAL_AID are not globally unique. The frame from overlapping BSS with matching COLOR and PARTIAL_AID information received at the STA may be wrongly regarded as the transmission from its own BSS. It is noted that either Address 1 (A1) or Address 2 (A2) of the valid MAC header may contain the BSSID of the access point: The information of the correctly decoded MAC header can be used to further identify whether the received frame is actually the transmission from its own BSS.
The above RID update rule may not protect the OBSS transmission sufficiently. When the immediate preceding reception for the current RID value before update is due to OBSS transmission, if the new RID value derived from the most recent reception that is from the STA's own BSS (but not addressed to the STA) always replaces the current RID count with the new RID value, the OBSS transmission that is longer than a period of time protected by the new RID count value is likely corrupted by the STA's early attempt on channel access due to its new RID count becomes shorter after update.
This can be illustrated in
In the following, an embodiment (which may be referred to as embodiment 2) will be described.
The following is an embodiment of RID setting and resetting.
When the STA identifies that the reception is addressed to itself, it shall reset its RID counter as long as it is the intended receiver of the PPDU or any of the frames within the received PSDU.
1. If the STA obtains both RXVECTOR parameter RESPONSE_INDICATION and the Duration field from the single reception, the STA shall reset the RID count to zero.
2. When the STA identifies that the reception is the transmission either from or to its AP (i.e. from its own BSS), if there is no Duration field, the STA shall replace the current RID count with the new RID value.
3. Otherwise,
a. if the new RID value for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current RID count, the RID count shall be updated;
b. if the new RID value for the RXVECTOR parameter's RESPONSE_INDICATION is smaller than or equal to current RID count, the RID count shall not updated.
If the RID count is zero, the RID count is always set by the new reception and is set to zero if Duration field is available from the reception.
In this embodiment, the STA is not required to keep track of whether the immediate preceding received PPDU is either from or to its AP (i.e. from its own BSS). The STA could identify whether the received PPDU is either from or to its AP, based on the RXVECTOR parameters' UPLINK, COLOR and PARTIAL_AID or the MAC header of the received PPDU (if applicable).
If there is a Duration field for NAV setting in the received PPDU, the RID value is reset at the STA regardless of the reception is from its own BSS or OBSS transmission. There are some open issues, e.g. when the RID value before update is derived from the reception due to OBSS transmission, if a new RID value is received from the STA's own BSS, according to the rule, the RID will be replaced by a new RID value; furthermore, if there is a Duration field for NAV setting in the received PPDU, the current RID count shall be reset. This creates the similar issue as shown in
In the following, an embodiment (which may be referred to as embodiment 3) will be described.
The following is an embodiment of RID setting and resetting.
1. When the STA identifies that the reception is the transmission either from or to its AP (i.e. from its own BSS),
a. if there is no Duration field, the STA shall replace the current RID count with the new RID value;
b. if the STA obtains both RXVECTOR parameter RESPONSE_INDICATION and the Duration field from the single reception, the STA shall reset the RID count to zero.
2. Otherwise,
a. if the new RID value for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current RID count, the RID count shall be updated; furthermore, if the STA also obtains a Duration field from the reception, the STA shall reset the RID count to zero.
b. if the new RID value for the RXVECTOR parameter's RESPONSE_INDICATION is smaller than or equal to current RID count, the RID count shall not updated; furthermore, if the STA also obtains from the reception a Duration field that is larger than the current RID count, the STA shall reset the RID count to zero.
When an OBSS transmission is received, if the new RID value for the RXVECTOR parameter RESPONSE_INDICATION is larger than the current RID count, the RID count shall be updated. Furthermore, if the STA also obtains a Duration field from the single reception, the STA shall reset the RID count to zero. This is because the NAV count set by the Duration field of OBSS transmission is always more accurate than the updated RID count and thus can be used to override (reset) the RID count.
When OBSS transmission is received, if the new RID value for the RXVECTOR parameter's RESPONSE_INDICATION is smaller than or equal to current RID count, the RID count shall not updated. Furthermore, if the STA also obtains from the reception a Duration field that is larger than the current RID count, the STA shall reset RID count to zero. This could happen when there is an OBSS transmission with a small RID value but with a larger Duration field for NAV setting to protect the following multiple transmissions. The small RID value is accounted for the elicited response that may be a NDP response. In this case, if the current RID value that is larger than the new RID value is due to the transmission within the STA's own BSS, the RID update rule justifies the reason why the RID count shall not be updated by the new RID value but it shall be instead reset as the Duration field can protect a period of time that is longer than the current RID count. On the other hand, if the new reception is due to an OBSS transmission with a small RID value and a small Duration field for NAV setting, and the current RID value that is larger than the new RID value and the NAV count set by the Duration field in the received PPDU is due to the transmission within the STA's own BSS, the RID count shall not be updated by the new RID value and shall not be reset, as the Duration field cannot protect a period of time that is longer than the current RID count.
In this embodiment, the STA is not required to keep track of whether the immediate preceding received PPDU is either from or to its AP. The STA could identify whether the received PPDU is either from or to its AP, based on the RXVECTOR parameters' UPLINK, COLOR and PARTIAL_AID or the MAC header of the received PPDU (if applicable).
In the following, an embodiment (which may be referred to as embodiment 4) will be described.
The following is another embodiment of RID setting and resetting.
A STA shall keep track of whether the received PPDU is either from or to its AP (i.e. within the same BSS). Once the RID count reaches zero, the status on whether the received PPDU is either from or to its AP is unknown.
When the STA identifies that the reception is addressed to itself, it shall reset its RID counter as long as it is the intended receiver of the PPDU or any of the frames within the received PSDU.
When the STA identifies that the reception is the transmission from/to (in other words: either from or to) its AP, if the immediate preceding reception that sets the current RID count that is not zero during RID update is either from or to its AP (i.e. from its own BSS)
Otherwise,
if the new RID value for the RXVECTOR parameter's RESPONSE_INDICATION is smaller than or equal to current RID count, the RID count shall not updated; furthermore, if the STA also obtains a Duration field from the reception that is larger than the current RID count, the STA shall reset the RID count to zero.
In this embodiment, the STA is required to keep track of whether the immediate preceding received PPDU is either from or to its AP. The STA could identify whether the received PPDU is either from or to its AP, based on the RXVECTOR parameters' UPLINK, COLOR and PARTIAL_AID or the MAC header of the received PPDU (if applicable). The STA regards all the received PPDUs that are neither from nor to its AP as transmitted from one OBSS.
In the following, an embodiment (which may be referred to as embodiment 5) will be described.
The following is another embodiment of RID setting and resetting.
A STA does not keep track of whether the received PPDU is either from or to its AP (i.e. within the same BSS).
When the STA identifies that the reception is addressed to itself, it may reset its RID counter as long as it is the intended receiver of the PPDU or any of the frames within the received PSDU.
When the STA identifies that the reception is the transmission from/to its AP
Otherwise,
In the following, an embodiment (which may be referred to as embodiment 6) will be described.
The following is another embodiment of RID setting and resetting.
A STA does not keep track of whether the received PPDU is either from or to its AP (i.e. within the same BSS).
When the STA identifies that the reception is addressed to itself, it shall reset its RID counter as long as it is the intended receiver of the PPDU or any of the frames within the received PSDU.
When the STA identifies that the reception is the transmission either from or to its AP,
Otherwise,
A member PPDU is a PPDU received by a STA and which was transmitted by a STA that is a member of the same BSS as the receiving STA. The S1G STA shall classify a received PPDU as a member PPDU if it is an NDP CMAC frame, or an S1G_1M PPDU, or a PPDU for which the PREAMBLE_TYPE is either S1G_LONG_PREAMBLE or S1G_SHORT_PREAMBLE and either of the conditions below is satisfied:
It will be understood that “STA's AP” means that the AP with which the STA is associated. The STA is allowed to commence the data transmission with its AP only after it is associated with the AP.
The method based on PHY header information is only applicable to >=2 MHz case.
If the STA updates RID value only based on PHY header information of the received PPDU, then
(1) if the received PPDU is an NDP MAC frame, the received PPDU frame is regarded as from the receiving STA's own BSS.
(2) if the received PPDU is a larger than or equal to 2M Hz S1G PPDU,
(2a) when it is a non-NDP-MAC frame, the received PPDU frame is identified as the receiving STA's own BSS transmission, if it is a downlink frame with the RXVECTOR parameter COLOR matching to its own BSS's COLOR, or
(2b) if it is an uplink frame with the RCVECTOR parameter PARTIAL_AID matching to its AP's partial BSSID.
Because the parameters of PARTIAL_AID and COLOR obtained from the received PPDUs are not globally unique, the STA that has identified a PPDU as from its own BSS based on PARTIAL_AID and/or COLOR may additionally use the information contained in a valid MAC header (i.e., A1 and/or A2 fields) from an MPDU carried in the received PPDU to further determine whether the received PPDU is from its own BSS. That is, if A1 or A2 field contains the MAC address of a STA that is known at the receiving STA and is associated with the AP of the receiving STA, the received PPDU shall be further identified as a PPDU that is not from its own BSS.
If the STA update RID value based on PHY header information and MAC header information of the received PPDU, then the device shall decode MAC frame to obtain Address 1 (A1) and/or Address 2 (A2) of the MAC header. If either Address 1 (A1) or Address 2 (A2) contains the full MAC address of its AP, the STA shall identify the received PPDU is from its own BSS. Otherwise, the STA shall identify the received PPDU from other BSS.
1 MHz S1G PPDU is considered as the receiving STA's own BSS transmission if the valid MAC header information (A1 and/or A2) of the received PPDU is not further made use of.
All the embodiments of RID setting and resetting exclude the case of receiving CF-End frame. When the STA receives a CF-End frame or other similar frame that is used to terminate the TXOP (Transmission Opportunity), if the frame is received with a Duration field, the STA shall follow the rule for receiving the frame. For example, the STA shall reset its NAV and RID counts if it receives the CF-End frame with a Duration field. However, if the STA only receives the preamble and SIG field of the PPDU frame of CF-End and other similar frame to terminate the TXOP, it may only update its RID count based on the above RID setting and resetting rules.
An S1G STA that receives a PPDU that is identified as a frame received from or sent to its AP before decoding the MAC header of the MPDU carried in the received PPDU shall not reset its RID counter when the PHY-RXSTART .indication primitive corresponding to that PPDU is received. Because the information of RXVECTOR parameters i.e. PARTIAL_AID and COLOR values obtained from received PPDUs are not globally unique, an S1G STA that has classified the PPDU as a PPDU received from or sent to its AP based on PARTIAL_AID and/or COLOR before decoding the MAC header may find that the received PPDU is in fact from other BSS. When the RID count is larger than the Duration field value of the valid MAC header in the MPDU carried in the received PPDU, the MAC layer function is not able to recover the correct RID counter if the RID counter is reset upon PHY-RXSTART .indication primitive corresponding to that PPDU is received.
The steps for the STA when receiving a PHY-RXSTART.indication primitive corresponding to a received PPDU may be shown as the flow chart.
1. When receiving a PHY-RXSTART.indication primitive in 2602 corresponding to a received PPDU, the STA can calculate the new RID value, RID_n, as shown in the flowchart in 2604.
2. It (for example the STA) may compare it with RID_o, which is the current RID count, as shown in the flowchart in 2606. If the current RID count is larger than the new RID value, then go to step 3 (2610 in
3. In 2610, it (for example the STA) may determine whether the received PPDU is either a 1 MHz PPDU (carrying at least one non-NDP MAC frame) or an NDP MAC frame. If No, the PHY optionally filters out the PPDU based on the GID, MU[0-3] NSTS, UPLINK_INDICATION and ID fields of SIG or SIG-A and the contents of the PHYCONFIG_VECTOR. For example, the STA may perform PHY filtering in 2612 based on some rules for PARTIAL_AID (e.g. (UPLINK_INDICATION==1 && PARTIAL_AID==the value of RXVECTOR parameter PARTIAL_AID for a frame that is not a control frame that is addressed to an AP)∥(UPLINK_INDICATION==0 && PARTIAL_AID==the value of RXVECTOR parameter PARTIAL_AID for a frame that is not a control frame that is sent by an AP and addressed to a STA associated with that AP or is sent by a DLS or TDLS STA in a direct path to a DLS or TDLS peer STA or is set to a group of STAs with a common multicast AID and a common BSSID)∥PARTIAL_AID==0), and then may go to step 6 (2614 in
4. If it is an NDP MAC frame, go to step 5 (2624 in
5. In 2624, it (for example STA) may check whether there is a Duration field for NAV setting. If Yes, then go to step 11 (2628 in
6. In 2614, it (for example the STA) may check whether the received PPDU has been filtered out by the PHY filtering. If Yes, then go to step 7 (2620 in
7. In 2620, it (for example the STA) may check whether the received PPDU is a transmission from its own BSS. If Yes, then go to step 13 (2630 in
8. In 2616, it (for example the STA) may check whether the received PPDU is a valid MAC frame. If Yes, then go to step 9 (2622 in
9. In 2622, the STA may check whether either Address 1 (A1) field or Address 2 (A2) of the MAC header of the received PPDU equals to its AP's BSSID (MAC address). If Yes, then go to step 5 (2624 in
10. In 2608, replace RID_o with RID_n. Then go to step 3 (2610 in
11. In 2628, RID_o is reset to 0.
12. In 2632, there is no change (i.e. no update).
13. In 2630, RID_o is replaced by RID_n.
14. In 2626, RID_o is set to EIFS.
In the following, examples of where the RID update rules according to various embodiments may be implemented in an access point/wireless device
The access point 2802 may include a TX (transmit) frame buffer 2810, a TX data processor 2812, a TX spatial processor 2814, a first TX/RX (receive) unit 2816 coupled to a first antenna 2818, a second TX/RX unit 2836 coupled to a second antenna 2837, further TX/RX units coupled to further antennas (like illustrated by dots 2826), a scheduler 2820, a controller 2822, a channel estimator 2824, a memory 2828, an RX frame buffer 2830. an RX data processor 2832, and an RX spatial processor 2834. It will be understood that each of the elements of the access point 2802 are optional; for example, only one TX/RX unit and only one antenna may be provided.
Each terminal device may include a first TX/RX unit 2840 coupled to a first antenna 2838, a second TX/RX unit 2856 coupled to a second antenna 2866, further TX/RX units coupled to further antennas (like indicated by dots 2864), and RX spatial processor 2842, and RX data processor 2844, an RX frame buffer 2846, a channel estimator 2848, a controller 2850, a memory 2852, a scheduler 2854, a TX spatial processor 2858, a TX data processor 2860, and a TX frame buffer 2862. It will be understood that each of the elements of the terminal device are optional; for example, only one TX/RX unit and only one antenna may be provided.
While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201309710-0 | Dec 2013 | SG | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SG2014/000631 | 12/31/2014 | WO | 00 |
