Consider the following two questions about IEEE 802.11 Standard:
1. Carrier Sense is provided by the
physical layer, thus, when MAC layer get a packet to transmit. It will
initiate a carrier sense mechanism, and it took >= DIFS time to
determine that the channel is free, thus, at least we have a delay as
128 us, right?
2. Assuming 4 nodes A,B,C,D working in Ad-hoc mode without
RTS/CTS . First, A has 10 packets (10 MPDU belongs to 1 MSDU) to
transmit to B, Thus, A access the channel, and get it. Thus, A
begin a Packet-SIFS-ACK-SIFS-Packet-SIFS........ sequence. During
that, C got one packet to transmit to D, unfortunately, C sense
the channel is busy, thus, C begin a backoff procedure, which he set
his CWmin = 7, and Backoff time = Random() * a slottime = 3. a slot
means 50 us.
Because, Each MPDU is transmitted with SIFS interval, the Backoff
number cannot be decremented unless at least a DIFS is idle and the
next slot is also idle. Thus C has no chance to transmit until A
finished his own transmission. and After DIFS+ 3 timeslot, C will begin
to transmit. Thus, we conclude that, C has no chance to challenge an
existing transmission.
Then, what happened if there is a transmission failure during the 10
MPDU, it means a back-off procedure will be initiated after an EIFS,
thus, at this time, A and C has the same probability to win the channel
as long as the CWmin is the same.
Another interesting thing is that if node A get another MSDU (~ 5 MPDUs) to
transmit to C during the period it sends the 10 MSDU. So,
" node A still has advantage to access channel,
because A does not generate any back-off procedure if no transmission
failure happens, and A will transmit immediately after an DIFS slot
when last MSDU is finished. So, it seems that as long as a station get the access, it is always has
priority to send than other stations."
This is Wrong!!!
Citing
from 802.11-1999:
"9.2.3.3:
A STA using the DCF shall be allowed to transmit if its
carrier-sense mechanism (see 9.2.1) determines that the medium is
idle at the TxDIFS slot boundary as defined in 9.2.10 after a
correctly received frame, and its backoff time has expired."
The last part (after "and") means:
*Whenever*
you have to wait DIFS,
you have to backoff, too, thus allowing other stations to content for
the medium. So, everyone has equal probability to access the channel.
The only exception is that channel is free when you access it and after
waiting longer than DIFS, it is still free. Then, no backoff, send directly.
To prevent consecutive access as in above example, after a DATA packet
transmission, the sending node automatically backoff after DIFS.
More specific in:
"9.2.5.2.
A backoff procedure shall be performed immediately after the end of every transmission with the More Fragments bit set to 0 of an MPDU of type Data, Management, or Control with subtype PS-Poll, even if no additional transmissions are currently queued. In the case of successful acknowledged transmissions, this backoff procedure shall begin at the end of the received ACK frame. In the case of unsuccessful transmissions requiring acknowledgment, this backoff procedure shall begin at the end of the ACK timeout interval. If the transmission is successful, the CW value reverts to aCWmin before the random backoff interval is chosen, and the STA short retry count and/or STA long retry count are updated as described in 9.2.4. This assures that transmitted frames from a STA are always separated by at least one backoff interval."
More about MPDU, MSDU & PSDU and Overhaed:
MSUD is the packet from upper layer, MPDU = PSDU including everything in MAC, for example: A Packet would like:
PPDU = PSDU +PLCP header + PLCP preamble.
There are only 3 addresses in the MAC header, but the standard says 4. That's because the address is usually omitted unless a Wireless Distribution System is used and packet is for AP-AP communication.
It is interesting that the RTS set its NAV covering to the end of whole RTS-CTS-DATA-ACK process. How about a RTS has not been ACKed with a proper CTS. Then all the nodes around the sending node will wait for such a long idle period, and just wasting the bandwidth?! The standard provides a solution, that the nodes could reset NAV if it does not hears DATA packet at some time. However, it is still seems not perfect because anyway, the NAV settings broadcasted by RTS has to be re-confirmed by a following DATA frame, the first setting in RTS seems always flexible and non-compulsive. Thus, schemes could just say, we set the NAV first to "2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime", then announce the final decision in DATA frame. This is very useful, in case that the sending node cannot be sure how long it takes to transmit without a CTS reply in some scheme
Excerpts from 9.2.5.4
STAs receiving a valid frame shall
update their NAV with the information received in the Duration/ID field,
but only when the new NAV value is greater than the current NAV value
and only when the frame is not
addressed to the receiving STA. Various additional conditions may set
or reset the NAV, as described in
9.3.2.2. When the NAV is reset, a PHY-CCARESET.request shall be issued.
Figure 53 indicates the NAV for STAs that may receive the RTS frame,
while other STAs may only receive
the CTS frame, resulting in the lower NAV bar as shown (with the
exception of the STA to which the RTS
was addressed).
A STA that used information from an RTS frame as the most recent basis
to update its NAV setting is permitted
to reset its NAV if no PHY-RXSTART.indication is detected from the PHY
during a period with a duration
of (2 x aSIFSTime) + (CTS_Time) + (2 x aSlotTime) starting at the
PHY-RXEND.indication
corresponding to the detection of the RTS frame. The
¡°CTS_Time¡± shall be calculated using the
length of
the CTS frame and the data rate at which the RTS frame used for the
most recent NAV update was received.
Figure 53¡ªRTS/CTS/data/ACK and NAV setting
In the 1Mbps or 11M DSSS standard (1999), SIFS are 10us, and aSlottime is 20us. So, the basic reason for those values are CCA has to use 15us and a round-trip time is less than 5us, so the maximum round-trip of propagation delay is 5*300/2= 750m. However, some wireless LAN for outdoor claims coverage as several miles. In that case, it has to change this Slottime value or there are only 2 nodes in the network.
Excerpts from standard:
aSIFSTime and aSlotTime are fixed
per PHY.
aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay +
aRxTxTurnaroundTime.
aSlotTime is: aCCATime + aRxTxTurnaroundTime + aAirPropagationTime
+ aMACProcessingDelay.
The PIFS and DIFS are derived by the following equations, as
illustrated in Figure 58.
PIFS = aSIFSTime + aSlotTime
DIFS = aSIFSTime + 2xaSlotTime
The EIFS is derived from the SIFS and the DIFS and the length of time
it takes to transmit an ACK Control
frame at 1 Mbit/s by the following equation:
EIFS = aSIFSTime + (8xACKSize) + aPreambleLength + aPLCPHeaderLngth+
DIFS
Broadcasting packets is also regarded
as an MPDU, so it also has to obey the carrier sense & backoff.
Excerpts from the standard:
In the absence of a PCF, when broadcast or multicast MPDUs are
transferred from a STA with the ToDS bit clear, only the basic access
procedure shall be used. Regardless of the length of the frame, no
RTS/CTS exchange shall be used. In addition, no ACK shall be
transmitted by any of the recipients of the frame. Any broadcast or
multicast MPDUs transferred from a STA with a ToDS bit set shall, in
addition to conforming to the basic access procedure of CSMA/CA, obey
the rules for RTS/CTS exchange, because the MPDU is directed to the AP.
The broadcast/multicast message shall be distributed into the BSS. The
STA originating the message shall receive the message as a
broadcast/multicast message. Therefore, all STAs shall filter out
broadcast/multicast messages that contain their address as the source
address. Broadcast and multicast MSDUs shall be propagated throughout
the ESS.
There is no MAC-level recovery on broadcast or multicast frames, except
for those frames sent with the ToDS bit set. As a result, the
reliability of this traffic is reduced, relative to the reliability of
directed traffic, due to the increased probability of lost frames from
interference, collisions, or time-varying channel properties.
802.11 radio consumes as much power when it is idle as when it receives transmissions. Briefly, these reasons have to do with By contrast, with a TDMA-style MAC, it is possible to put the radio in standby mode during such intervals. That's a big difference regarding energy consumed by the radio during idle intervals.
IEEE 802.11 MAC standard is weak in solving following issues: (link layer reliability, QoS support?, power conservation)
