Wireless LAN (IEEE 802.11 class of protocol suite)
In these notes, I will explain the MAC protocols used in constructing wireless LANs
using the IEEE 802.11 class of protocol suites. Specific protocols, such as the 802.11,
will be discussed because these have been standardized and these are used world-wide.
At this point, it is important to note the following assumption made in the design of the
CSMA/CD protocol to construct a wired LAN: signal from any computer in a network
can reach all computers in the network. In a wired LAN, this assumption must hold for
computers to be able to reach each other and for the collision detection mechanism to
work.
However, in a wireless LAN, the above assumption may not hold. That is, signal from a
computer may not reach all the computers in the network. Hence, at the MAC level, we
do not go for collision detection. Another consequence of signal not reaching all the
computers in a network is that computers in a network may not be able to communicate
directly. For two computers to be able to communicate, service of another computer in
the network or a fixed infrastructure, namely, an Access Point (AP), is used.
C: Computer, AP: Access Point
Router
IEEE
802.11
protocol
C
To the rest of the
network
Access
Point
Radio
range of the
AP
C
AP
Figure WL1: Elements of a wireless LAN (WLAN)
A wireless LAN using an Access Point (AP) is shown in Figure W1. An AP is the main
part of the infrastructure to support a wireless LAN. An AP is connected to a router,
which in turn is connected to the rest of the network and the Internet. One of more APs
1
may be connected to the same router as shown in the figure, or different APs may be
connected to different routers. The APs as well as user computers are equipped with an
identical radio interface commonly known as the IEEE 802.11 standard interface. The
IEEE 802.11 standard specifies both the PHY (physical) and the MAC layers for
constructing a wireless LAN. The PHY layer defines the air interface between two IEEE
802.11 equipped devices and the MAC layer defines the medium access control protocols
to access the shared medium.
(There are a variety of the IEEE 802.11 protocol, such as 802.11a, 802.11b, 802.11g, and
802.11e. Protocols such as the 802.11, 802.11a, 802.11b, and 802.11g differ only in their
PHY part, thereby supporting different levels of bandwidth, whereas all their MAC
protocols follow the same principle. On the other hand, the 802.11e MAC, which has
been designed to support multimedia applications, is different from the above protocols.
In these notes, we will not discuss the 802.11e protocol for lack of time. However, once
one understands the 802.11 MAC protocol, it is easier to understand the more complex
802.11e protocol.)
Different modes of operation of IEEE 802.11 MAC protocol
Before discussing the details of the IEEE 802.11 MAC protocol, it is useful to
understand the different modes of operation of the protocol as classified below.
Modes of IEEE
802.11 MAC
Distributed Coordination
Function (DCF) mode
With Hand-shake
Point Coordination
Function (PCF) mode
Without Hand-shake
Figure W1: Different modes of operation of MAC protocol in a WLAN
PCF mode of operation
In this mode of operation, an AP acts as the central controller for all the computers lying
within the radio range of the AP. The AP decides who transmits when. Thus, there is no
2
contention among computers for medium access. The AP can, but not necessarily, follow
a round-robin policy to assign time slots to individual computers, thereby guaranteeing a
certain amount of bandwidth to each computer. Because of this guarantee of allocation of
bandwidth, this mode of operation can support real-time traffic. However, if the amount
of traffics generated by different computers widely vary, this mode is not suitable. This is
due to the fact that the AP may allocate bandwidth to a computer which may not have
much data to transmit. Finally, the IEEE 802.11 standard says that implementation of the
PCF mode of operation is optional.
DCF mode of operation
In this mode of operation, the presence of an AP is not essential. For example, computers
can communicate among themselves using the DCF mode of operation without the
assistance of an AP. In such a case, we say that the computers have formed an ad hoc
network, where there is an absence of infrastructure, such as APs. However, to construct
a wireless LAN with the capability to connect to the Internet, it is essential to have an AP
which is connected to a router as shown in Figure W1. Whether or not there is an AP, in
the DCF mode of operation all the computers compete for medium access, because there
is no central controller—if there is an AP, it does not act as a central controller. Because
of contention among computers for medium access, there is no guarantee of bandwidth
and there is no bound on message delay. Thus, the DCF mode of operation is not suitable
for real-time traffic. Rather, data delivery is made on a best effort basis—the network
makes an effort to deliver data across the wireless medium, but there is no guarantee of
bandwidth or bound on delay. Finally, the IEEE 802.11 standard says that
implementation of the DCF mode of operation is mandatory, that is, the DCF mode of
operation must be supported by a network card claiming to implement IEEE 802.11.
Note: We have said that the PCF mode is optional, whereas the DCF mode is mandatory.
If an AP implements both the modes, the following is a scenario in which both the modes
can be used alternatively. For example, the network can run in the PCF mode for T1
seconds, followed by the DCF mode for T2 seconds, followed by the PCF mode for T1
seconds, and so on. In this manner, all, or, some, computers get a guaranteed bandwidth
during the PCF mode, whereas all the computers compete for bandwidth in the DCF
mode. Those computers without data to be transmitted will not compete for medium
access during the DCF mode, thereby allowing those computers with data to enter the
contention phase.
PCF
DCF
PCF
DCF
PCF
…….. Time
Figure W2: Alternative use of PCF and DCF modes
3
DCF with hand-shake
In this mode, a sender obtains permission from an intended receiver before transmitting a
packet to the receiver. This is achieved by the sender transmitting a Request To Send
(RTS) packet to the intended receiver, and the receiver granting permission by
transmitting a Clear To Send (CTS) packet back to the sender. The intended receiver may
refuse to grant permission by remaining silent, i.e. not transmitting a CTS packet back to
the sender. The sequence of RTS and CTS control packets is known as the process of
hand-shake. An intended receiver can refuse to receive a packet from the sender for a
variety of reasons, such as lack of buffer and lack of interest in communicating with the
sender, to name a few. This mode of operation is preferred where the network traffic is
high or if the packet to be transmitted is a long one. In either case, if hand-shake is not
used, the packet will collide with another packet at the receiver with high probability.
Thus, it is recommended to use the hand-shake mode of DCF when traffic is very high in
the network or a packet is very long. The flip side of using hand-shake is the extra
overhead of exchanging RTS/CTS control frames. Essentially, before transmitting a long
packet, a sender not only informs the intended receiver about the upcoming transmission,
but also both the sender and the intended receiver inform their neighbors—via the RTS
and CTS control frames—about the upcoming transmission so that the neighbors do not
initiate their own transmissions while the packet is being transmitted and acknowledged.
(The idea of data packet acknowledgement at the MAC level will be explained in a later
part of this section.)
DCF without hand-shake
In this mode of operation, a sender does not take permission from an intended receiver
before transmitting a data packet. That is, RTS/CTS control frames are not exchanged
between a sender and a receiver before the sender transmits a data packet. Rather, the
sender just transmits the packet when certain medium sensing conditions are satisfied.
These conditions will be explained in a later part of these notes. Thus, there is no
coordination between a sender and a receiver prior to a data packet being transmitted.
This lack of coordination increases the probability of packet collision. If data traffic is
low or packets are short, then this mode of data transmission avoids the overhead due to
hand-shaking.
Note: The two modes of DCF operation, namely with hand-shake and without handshake, are not mutually exclusive. Rather, both coexist, and the two modes can be
selected on a packet basis. For example, the dotRTSThreshold variable in the MAC
management database can be used to choose a certain mode of operation. The
dotRTSThreshold variable is initialized with an integer value representing a
threshold packet length in bytes. If the length of a data packet is equal to or greater than
the dotRTSThreshold value, then the MAC layer chooses the “with hand-shake”
mode. On the other hand, if the packet length is smaller than the dotRTSThreshold
4
value, then the “without hand-shake” mode is chosen to transmit the data packet. This
situation has been further explained in Figure W3. Figure W3 shows that a wireless LAN
can alternatively operate in the PCF and DCF modes, and within the same DCF mode
duration, a computer can successively transmit two data packets in the “without handshake” and the “with hand-shake” modes.
PCF
DCF
PCF
DCF
PCF
}
With hand-shake
Without handshake
…….. Time
mode of operation of the
same computer
Figure W3: Alternative use of PCF and DCF modes and consecutive appearances of
“with hand-shake” and “without hand-shake” modes in the same DCF period.
Problems in a wireless LAN
There are three problems in a wireless LAN, which are not found in wired LANs. These
problems are as follows:
- Hidden terminal problem
- Exposed terminal problem
- Inability to detect collision.
Hidden terminal problem
Assume that all the computers have identical radio ranges. This assumption is not
necessary for the problem to occur. Rather, the problem becomes more frequent in the
absence of this assumption. Thus, for simplicity of our explanation, we make this
assumption. Let there be three computers A, B, and C as shown in Figure W4. Their
relative locations and radio ranges have also been shown in Figure W4. The figure shows
that A and B are within each other’s radio ranges, and B and C too are within each
other’s radio ranges. Thus, the direct communications that can happen are between A and
B and between B and C. However, A and C are outside each other’s radio ranges. Now,
assume that C is transmitting to B as shown in the figure. Since C is far away from A, A
is unaware of the fact that there is an on-going transmission between B and C. Because of
this unawareness, A can potentially start its transmission to B or another computer (not
shown in the figure), thereby disturbing C’s transmission to B. This disturbance happens
because C is hidden from A. Thus, a hidden terminal problem occurs when a computer
(A) starts its transmission while being unaware of a far-away located computer’s (C’s)
5
transmission to A’s neighbor (B). In other words, the problem can occur if two computers
(A and C) have a common neighbor (B), but the two computers can not hear each other’s
signals.
Because users, and, hence their computers, are mobile in a wireless LAN, the hidden
terminal problem occurs in a wireless LAN. Suitable measures are taken in the IEEE
802.11 MAC protocol to address this problem.
Tx
A
B
C
Figure W4: Illustration of the hidden terminal problem
Exposed terminal problem
Referring to Figure W5, assume that the pairs of computers (D, A), (A, B), and (B, C) are
Neighbors in the sense that D and A are within each other’s radio ranges. Let A be
transmitting a data packet to D. Because of the broadcast nature of this transmission, the
same signal also reaches computer B. However, B is not an intended receiver of A’s
signal. We also know that C is not receiving A’s signal. Thus, it is possible for B to start
transmitting a data packet to C without disturbing the ongoing transmission from A to D.
However, B does not initiate its transmission, because it is unaware of D’s location. B
does not know if its transmission to C will cause a collision at D. Hence, B does not
initiate its transmission while being exposed to A’s signal. This is called the exposed
terminal problem. In other words, a computer does not start transmitting if it senses that
there is an ongoing transmission. Researchers are investigating this issue so that network
performance is improved by allowing an exposed terminal to transmit subject to the
condition that it does not disturb an ongoing transmission.
Tx
D
A
B
C
6
Figure W5: Illustration of the exposed terminal problem
Inability to detect collision
Ideally, a sender should detect collision at a receiver, because it is the collision at the
receiver that matters. In a wired LAN, collision is detected at the sender’s end by
assuming that signals from all computers can reach all other computers. However, this
assumption does not hold in a wireless LAN as it has been explained in the context of the
hidden terminal problem. Another reason for the difficulty in not being able to detect
collision is that many wireless devices use half duplex transceivers to simplify transceiver
design. That is, a half-duplex wireless device turns on its transmitter and receiver in an
alternating manner.
As an example, GSM phones use half-duplex transceivers, and this is facilitated by
skewing the up-link (transmitting) channel and the down-link (receiving) channel by
three time slots so that the transceiver can switch its mode from a transmitter to a receiver
and vice versa.
Thus, in a wireless LAN, because of the difficulty in detecting collision, MAC protocols
do not rely upon collision detection. Rather, the principle of collision avoidance is
utilized.
Transmit condition and virtual carrier sensing
Before a computer can transmit anything—data or control packets—it is essential to
detect idleness of the medium. In a wired LAN, it was sufficient to detect idleness by
sensing the physical medium. However, in a wireless LAN, because of the hidden
terminal problem, it is not enough to sense the medium to know whether or not the
medium is idle. In addition to carrier sensing at the PHY level, the WLAN MAC protocol
uses the concept of virtual carrier sensing to tackle the hidden terminal problem.
In virtual carrier sensing, a computer monitors the transmission of all control packets that
it can receive, utilizes the duration information contained in those packets, and infers
whether or not the medium is idle at its intended receiver.
Thus, the medium is said to be idle if the PHY level carrier sensing mechanism detects no
carrier and it is inferred from the virtual carrier sensing mechanism that the intended
receiver within its radio range is not receiving data.
7
Transmit condition
Medium is idle
Absence of carrier
detected by the carrier
sensing mechanism at
the PHY level.
and
The virtual carrier sensing
mechanism tells that the
medium is free.
Figure W6: Condition for medium idleness
Virtual carrier sensing is implemented by using two concepts as listed below:
-
-
Control frames (or, packets)
o Request-To-Send (RTS) frame
o Clear-To-Send (CTS) frame
Network Allocation Vector (NAV): This is a scalar, integer variable held by
each computer.
Suppose that a computer A wants to transmit data to another computer B. Before
transmitting the data frame, A transmits an RTS frame to B. The major fields of an RTS
frame are: A’s and B’s addresses and a duration field. The duration field tells B the
length of time for which the medium is likely to remain busy due to A’s data transmission
and B’s acknowledgement. An RTS frame is a point-to-point frame in the sense that only
B should respond (a CTS frame) to the RTS frame. Also, an RTS frame is a broadcast
frame in the sense that all those receiving this frame are supposed to extract the duration
field out of the packet to update its NAV, but the unintended receivers do not send back a
response (a CTS frame). By transmitting an RTS frame, computer A achieves two
objectives as outlined below:
-
Computer A requests permission from B.
Computer A informs all its neighbors of a likely data transmission within a
certain time interval so that the neighbors do not transmit anything within the
said interval.
If, or when, B receives the RTS frame, it decides whether or not to receive a data frame
from A. In case B wants to receive a data frame from A, it responds back to A by
transmitting a CTS frame. Contained in the CTS frame will be A’s address and the
8
duration for which the medium is likely to remain busy around B. All computers, except
A, receiving the CTS frame extract the duration value and update their NAV variables.
Neighbors of A will receive A’s RTS and neighbors of B will receive B’s CTS. All
computers, except the pair A and B, receiving an RTS or a CTS shall not initiate a
transmission in the period denotes the duration fields of the RTS/CTS frames.
Computers update and interpret their NAV variables as follows.
- Each computer has its own NAV with an initial value of 0.
- NAV represents for how long the medium is likely to remain busy.
- The unit of time information in NAV is microseconds.
- NAV is decremented by 1 with the elapse of each microsecond of real time.
- When NAV = 0, it is no more decremented.
- NAV is updated using the duration field in a received control frame as
follows:
o NAV = Max(NAV, duration value received in a control frame)
- NAV = 0 means no pre-announced transmission is going on in the vicinity.
- Idle medium is defined as absence of carrier AND NAV = 0.
Timing relationship between RTS and CTS
The hand-shake mechanism using RTS and CTS control frames has been illustrated in
Figure W7. In Figure W7 we assume that computer A wants to send a data frame to
computer B, C is a computer within the radio range of A, and D is a computer within the
radio range of B. We also assume that D is out of range of A, and C is out of range of B.
The four frames, namely RTS, CTS, DATA, and ACK, are separated by a time interval
known as Short InterFrame Space (SIFS). The idea behind this spacing is to maintain a
logical association between these frames. Because of propagation delay and the delay
involved in computing a response to a frame, there is a need to have an allowed time gap
between logically related frames. For example, when a station, say, B, has successfully
received an RTS, it should be given an opportunity to respond back with a CTS without
any disturbance from other computers. This is achieved by allowing B to make a decision
within SIFS interval and send back a CTS. It may be noted that no other computer within
A’s and B’s transmission range should transmit a packet during the SIFS gaps in Figure
W7. This is achieved by having the computers sense the medium to be idle for more than
the SIFS interval. (These intervals are known as PIFS—Point InterFrame Space—and
DIFS—Distributed IFS.)
An important thing in Figure W7 is the concept of acknowledgement (ACK) sent from B
to A. If B receives the DATA frame successfully, it sends back an ACK to A. It is useful
to recall that there is no such ACK mechanism in the CSMA/CD protocol for Ethernet.
The reason for including an ACK at the MAC level in wireless LANs and not having it in
the MAC protocol for wired LAN is that the bit error rate (BER) in case of high quality
wired LAN is very low, whereas the BER in a wireless environment is comparatively
very high. For example, the BER on a fiber link is as low as 10 -12 whereas it is 10-5 on a
9
wireless link. If the concept of ACK is not used at the MAC level in a wireless LAN,
upper level protocols will have to handle the resulting packet loss. Because of the longer
timeouts involved in upper-level protocols and the possibility of loss of retransmitted
packets from the upper-level protocols, handling packet loss at the upper-level is much
more expensive than the cost involved at the MAC level where the probability of packet
error is high. However, if the probability of packet error is extremely low at the PHY
level, handling packet error is left to the upper-level protocols due to the extra cost of
running the ACK mechanism at the MAC level.
Value of “duration” in RTS
A
SIFS
RTS
DATA
Value of “duration” in CTS
B
SIFS
SIFS
CTS
ACK
Value of NAV of C
C
Value of NAV of D
D
Time
Figure W7: The hand-shake mechanism using RTS/CTS
Note: Two computers, by exchanging RTS and CTS frames, inform their neighbors to
not initiate a transmission during the period reserved by the RTS/CTS frames. Thus, the
neighbors refrain from initiating their own transmissions during the said period and help
in avoiding potential collisions. Hence, the RTS/CTS mechanism works to achieve the
goal of collision avoidance.
10
DCF mode of operation with hand-shake
In the following, we give a flow-chart representation of the DCF protocol with handshake. We have already explained the basic concepts used in the protocol, such as the
idea of RTS/CTS. We will present the protocol in two parts in the form of a sender’s
behavior (Figure W8) and a receiver’s behavior (Figure W10).
11
F: a new data frame to be transmitted
i = 0, CW = CWmin
NAV = 0?
End of backoff
Idle medium for
DIFS interval?
No
Random
Backoff
Yes
Send an RTS
Start a timer
CTS is received
Timeout
Cancel timer
Send DATA (F)
Start a timer
ACK is received
Wait for fairness to
others
Cancel timer
Wait for a random
interval
Timeout
i = i+1
CW = CWmin*2i
(At some point, CW
saturates at CWmax.)
i: Retry count, CW: Contention Window
CWmin: Minimum value of CW (typical value is 32)
CWmax: Maximum value of CW (typical value is 256)
DIFS: Distributed Interframe Space
SIFS < DIFS  Important note
Figure W8: Hand-shake mode of DCF operation (Sender’s behavior)
The random backoff protocol (the dotted box in Figure W8)
The backoff mechanism in the WLAN protocol works differently from the backoff
mechanism in CSMA/CD protocol for Ethernet as follows.
-
Choose a random number in the range [0, CW]. A variable, called Backoff
Time Counter (BTC) is initialized with the chosen random number. The unit
of time represented by the BTC variable is denoted by aSlotTime, where
12
-
-
aSlotTime accounts for propagation time and transceiver switching time
(switching time between transmitter and receiver and vice versa.)
BTC is decremented by 1 if the channel is idle for aSlotTime.
Stop decrementing the BTC if the medium is busy.
Resume decrementing the BTC after finding the channel to be idle for DIFS
interval. Thus, whenever the channel is found to be busy, decrementing of
BTC is done after finding the channel to be idle for DIFS interval immediately
after the busy period ends. Once the channel is idle for at least DIFS interval,
subsequent decrement is done for each idle period of aSlotTime interval. (See
Figure W9 for an illustration.)
BTC = 0 means that the backoff process has finished.
A computer remains in the backoff state for at least BTC time units of real-time and
during this period the medium is idle. In Figure W9, we give an example of how BTC is
decremented by computer B. We assume that the channel remains busy due to activities
of computers A and C. Here, the focus is on how BTC decrements and not on who should
transmit when. The random initial value of BTC is assumed to be 5.
Note: The reader may note an important relationship between SIFS and DIFS in the form
of SIFS < DIFS. In the DCF mode, a computer senses the medium to be idle for at least a
DIFS period. Thus, even if the computer finds the medium to be idle for SIFS period
between frames in the sequence {RTS, CTS, DATA, ACK}, it does not initiate a
transmission in order to not disturb an ongoing communication. Thus, the relationship
SIFS < DIFS is very important. A recommended equality relationship between SIFS and
DIFS is: DIFS = SIFS + 2*aSlotTime (This relationship will be made clearer in a later
part of these notes.)
13
Ch. Busy (A)
Ch. Busy (C)
Time
DIFS
DIFS
X
B
BTC =
5
4
X
3
X
2
X
2
2
1
0
If the channel is busy, it has to remain idle for DIFS interval
for BTC to be decremented by 1.
X = aSlotTime
If the channel is idle for at least DIFS interval, it has to remain
idle for aSlotTime interval for BTC to be decremented by 1.
Figure W9: Illustration of how BTC decrements from a random initial value of 5.
14
Remain
silent.
Receive an RTS
NAV = 0?
No
Receive a DATA frame
Yes
Channel is idle
for SIFS and the
computer is ready
to receive?
No
Ch. idle for
SIFS?
No
Yes
Yes
Send an ACK
Send a CTS
Note: The above two fragments of flow-charts can be easily merged.
Figure W10: Hand-shake mode of DCF operation (Receiver’s behavior)
15
DCF mode of operation without hand-shake
The DCF mode of operation without hand-shake is a special case of the DCF mode of
operation with hand-shake. In this mode, RTS and CTS frames are not exchanged
between two computers before the sender transmits its DATA frame. A receiver must
respond to a correctly received DATA frame with an ACK frame. The idea of NAV is
still used in this mode of operation. This is because of the fact that even if a computer
does not use the hand-shake mode, it must update its NAV if it receives an RTS or a CTS
frame from another computer.
A network card may implement both the modes of DCF operation and dynamically
decide what mode to use on a frame basis.
Note: A computer may wish to broadcast a DATA frame to all its neighbors. By
broadcast, we mean all the neighbors are the DATA frame’s intended receivers. For a
DATA frame to be broadcast, we need to remember two points as follows:
-
A DATA frame is broadcast in the DCF without hand-shake mode.
Receivers of a broadcast frame do not send back ACK frames.
Thus, though broadcast operation is a desirable one, there is no guarantee of its reliability
at the MAC level, i.e., there is no guarantee that all the neighbors of the sender will
receive a copy of a broadcast frame. A broadcast frame is distinguished from a point-topoint DATA frame by using an appropriate addressing mechanism in the header of
DATA frame.
PCF mode of operation
In the PCF mode of operation, an Access Point (AP) is a key element in a WLAN. The
AP controls the channel by alternating between the PCF mode and the DCF mode. For an
AP to be in full control of the channel, it grabs the channel as follows:
-
The AP senses the medium to be idle at the beginning of a contention-free
(CF) period for a PIFS (PCF InterFrame Space) interval. The PIFS interval
has an important relationship with the other two intervals, namely, SIFS and
DIFS, in the form of:
SIFS < PIFS < DIFS.
This is how we interpret the above relationship. Frames in the sequence {RTS,
CTS, DATA, ACK} maintain a gap of SIFS. By having SIFS < PIFS, the AP lets
an ongoing transmission to be completed before grabbing the channel. By having
PIFS < DIFS, we make sure that another computer is prevented from acquiring
the channel, thereby giving priority to the AP to grab the channel. This happens
because in the DCF mode of operation, a computer must observe the channel to
16
be idle for at least DIFS interval. In terms of equality relationships, recommended
values of SIFS, PIFS, and DIFS are as follows:
PIFS = SIFS + aSlotTime
DIFS = SIFS + 2*aSlotTime
-
-
If an AP finds that the medium is idle for a PIFS interval, it transmits a
Beacon frame. A Beacon frame contains a CFPMaxDuration field (CFP:
Contention-Free Period.) This value communicates the length of the CF
period to all stations. Essentially, this value tells the user computers the
maximum duration for which the AP will be controlling the medium.
Computers receiving a Beacon frame update their NAV value with the
CFPMaxDuration value. Consequently, user computers are prevented from
taking control of the medium until the end of the CF period. This is because
for a user computer to access the medium, first its NAV must reach 0.
After transmitting a Beacon frame, the AP waits for at least one SIFS interval
and next transmits one of the following frames:
o DATA frame
o CF Poll frame
o Data+CF Poll frame
o ACK frame
o CF End frame
The above frame types have been explained in the following.
-
-
DATA frame:
o This frame contains user data from the AP to a particular station.
o Upon correctly receiving the DATA frame, a user computer sends
back an ACK frame to the AP after an SIFS interval.
o If the AP does not receive an ACK, it can retransmit the frame after a
PIFS interval.
o An AP can also transmit broadcast and multicast DATA frames to all
the users or a subset of the users, respectively.
o Broadcast and multicast frames are not ACKed.
CF Poll frame (explained in Figure W11):
o An AP sends this frame to a computer granting the computer
permission to transmit a single DATA frame to any destination—the
AP or another user computer.
o Receiver of the above DATA frame sends back an ACK to the polled
computer (This is the computer that sent out the DATA frame.)
o If the polled computer has no DATA frame, it must send a null DATA
frame.
o If a polled station does not receive an ACK, it can not retransmit its
data frame unless it is polled again.
17
User 1
AP
User 2
User 1
AP
CF Poll
CF Poll
SIFS
DATA
ACK
DATA
SIFS
SIFS
The polled user sends data to
another user.
SIFS
ACK
The polled user sends data to the AP.
Figure W11: CF Poll frame
-
DATA + CF Poll (See Figure W12.)
User 1
AP
User 2
DATA+
CF Poll
SIFS
ACK
DATA
SIFS
ACK
The polled user receives data from the AP
and sends data to another user.
Figure W12: DATA+CF Poll frame
18
-
CF End: This frame identifies the end of the CF period. This is sent by an
AP when one of the following happens:
o The AP has no data to transmit and no computer to poll. This can
happen before the pre-announced CFPMaxDuration value expires.
Thus, the AP can prematurely terminate its CF period by transmitting a
CF End frame. When the user computers receive this frame, those
reset their NAV to 0.
o The CFPDurRemaining time expires. This variable is initialized with
the value of CFPMaxDuration that was broadcast in a Beacon frame.
As time passes, CFDurRemaining is decremented and its value
represents the remaining time for which the AP will be in control of
the channel.
A computer joining a WLAN with an AP
In this part of the notes, we explain how a computer joins a wireless network with an AP.
(There is no need for such a protocol in a wired LAN, because by plugging in a new
computer to a wired LAN, your computer automatically becomes a part of the LAN.) A
station can join a WLAN in one of two ways:
-
by passive scanning
by active scanning
Passive Scanning: A station listens to each channel for a specific period of time. (A
channel can be considered as a certain carrier frequency. All the computers and the AP
transmit on the same carrier frequency. If the radio ranges of two APs overlap, they use
different channels.) Initially, a computer does not know if there is a nearby AP and the
channel used by the AP. Thus, it has to listen to each channel for a certain interval.
Listening to a channel means waiting to receive a Beacon frame transmitted on the
channel. After the computer receives a Beacon frame, the computer can negotiate a
connection with the AP by proceeding with the authentication and association processes.
Active Scanning: In this mode of joining a WLAN, a computer sends a Probe frame to
an AP by using the broadcast mechanism, and waits for a Probe Response from the
nearby AP. A Probe Response frame identifies the presence of a network. Once a
computer receives a Probe Response frame, it can negotiate a connection with the AP by
proceeding with the authentication and association processes.
19
Comparison of CSMA/CD MAC for LAN and CSMA/CA MAC for WLAN
Finally, we compare the CSMA/CD and CSMA/CA protocols for Ethernet LAN and
wireless LAN, respectively. The comparison will focus on the important concepts
involved in the design of those protocols.
CSMA/CD
(Ethernet
LAN)
CSMA/CA
(Wireless
LAN)
Collision
Detection
Yes
No
In wireless networks, in general,
it is not possible to detect collision.
ACK of
data frames
No
Yes
In a wireless network, it is important
to ACK data frames because of the
high BER (bit error rate).
No
Yes
An AP in a WLAN is a central controller.
Multi-mode
Data transmission
No
Yes
PCF and DCF (with/without hand-shake)
Sensitivity to
data frame length
No
Yes
Short packet: DCF without hand-shake
Long packet: DCF with hand-shake
Fairness
Yes
Yes
Rate of
transmission
High
Low
Achieved using a random wait after
successfully transmitting a data frame.
The low rate in WLAN is due to the
unreliable characteristic of wireless medium
Real-time
traffic support
No
(best effort)
Yes
Features
Possible use of
a central controller
Comments
An AP in the PCF mode can support
time-sensitive traffic.
20